Monday, September 23, 2019

Job Interview Technical Assessment Walkthrough

Hello people,
This is my first post here, in which i will be walking through a series of challenges i had to do in order to pass the technical assessment process of a job i was applying to.

Sorry if there is not much structure or detail to the blog post, but i am literally writing this while on a plane.

#Introduction to the challenges.
This was pretty straightforward: i was given a url which had a log in page and that's it. I was told that there would be 7 flags, and i had to submit my findings withing a week.

Finding the bugs:
Okay so i had a week to do this, but i wanted to impress them, so i put myself the goal to deliver the work within 4 days, i managed to do it in 2.

Flag 1: Improper Access Control on a S3 Bucket - Directory Listing Enabled

Note: Unfortunately, i cannot provide very detailed screenshots, because they use the same platform for everyone that applies there.
This was pretty easy actually, i just viewed the html source code of the web page, which had a reference to a s3 bucket.
I visited the url, and the whole contents of the bucket was being listed, including the flag!

Flag 2: Exposed .git Directory
Okay, so after finding the s3 bucket flag, i launched dirsearch, to perform content discovery on the domain: python3 dirsearch.py -u https://target.com -w raft.txt -x 404,500,403 -e php,html,js

Luckily, it was very quick to give a 200 ok for /.git



I used gitTools to download the contents of the folder, and i then ran: git show
This gave me the login credentials: demouser - password, i logged in and yup, there was the second flag.

Flag 3: 2FA Mechanism didn't have Rate Limiting Implemented
This was super easy as well, they had a "protected area", in which you had to click send code , which would send an OTP to a mobile number ( there was no option to set up / see the current mobile number ), so the first thing that came to my mind was bruteforcing the 2FA code.
I immediately launched Burp Suite, and used Intruder in order to automate the whole process.
After a while, the correct code was found, and the 3rd flag was included in the response.

Flag 4: IDOR - Ability to view other people's documents
When you logged in to the account, there were a few menus, two of which were "View Your Disputes" and "Submit Dispute" - which was disabled.
I checked the source code of the View Disputes page, and there was a javascript callback to a url looking like:
http://target.com/viewdisputes.php?proxy_url=http://127.0.0.1/users.php?userId=1337 ( where 1337 was my user id )
There was another page on the web app, that showed all the users and their ids, so i changed the id to 2600 ( the other user ), and i was able to see his disputes, but the flag was also included in the response.


Flag 5: Server Side Request Forgery
This was the coolest and my most favourite bug.
The same endpoint that was mentioned above, could be used to query the EC2 Instance of the web app, so i did a request similar to: http://target.com/viewdisputes.php?proxy_url=http://169.254.169.254/latest/meta-data and it displayed some very interesting aws stuff, so i went to grab the s3 bucket tokens: http://target.com/viewdisputes.php?proxy_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

This gave me the access key id, the secret token, region name etc.
I copied all the info and used them as configuration material for awscli ( Amazon Web Services Command Line Interface ) , through aws configure.
After that i listed all the s3 buckets that these keys give access to, through: aws s3 ls

This gave me 2 buckets: the initial bucket discovered in the first flag, and another bucket named: view-disputes-flag.
I listed the contents of that bucket and copied the flag to my computer, then viewed it's contents ot get the 5th flag.

Flag 6: Json Web Token Manipulation to Admin User Access
If you read about flag 4, i mentioned the fact that there was a page where you could see the id's of other users. There was also an admin user, with the id of 1.
When you logged in, a jwt cookie was generated ( i noticed the hash starting with ey, so i thought it was jwt, confirmed by pasting it to jwt.io )
The json web token looked like this:

"alg": "HS256",
"typ": "JWT"
}
{
"jti": "5somerandomstuffb",
"fresh": false,
"iat": 1566663044,
"type": "access",
"nbf": 1566663044,
"identity": 1337
}

I modified the identity to 1 ( the id of the admin ) and the alg type to None.
Put the modified value back into the request, forwarded it, and boom - i was logged in as the admin user, which also gave me the 6th flag.

Flag 7: XML External Entity Injection (XXE)
After logging in as an admin, you have the option to Submit Dispute ( which was disabled when you were logged in as a non-admin ) , and there was a sample file so that you could see the structure.
It was a .xml file, so you guessed it - i added an entity that referenced a system call to file:///etc/passwd ( basically i performed a Local File Inclusion through the XML File ), and uploaded the modified file.
The response displayed the contents of /etc/passwd , and in between the lines, there was the 7th flag.


Then i wrote the report, prepared the proof of concept videos for each flag, and sent it to the team.
After reviewing it , they told me they were pretty impressed with the report.

Now i'm currently waiting for the third step of the interview.
Thank you for reading!
./out

No comments:

Post a Comment

Contact Form

Name

Email *

Message *