Skip to content

Latest commit

 

History

History
148 lines (99 loc) · 15.1 KB

thepentest.md

File metadata and controls

148 lines (99 loc) · 15.1 KB

Welcome

Points: 25

Answer: This challenge was used as a way to redirect people to the Pentest Scope page. When you open the page, the answer is not there right away. To find the flag, you need to see the HTML source (view-source). The flag is stored as an HTML comment. This was designed to highlight that sometimes developers will leave messages on comments that can be useful for finding new endpoints, test phases, potential dev keys etc. Flag for this was: bcunivflag{starter_pack_0698093092}

IDOR

Points: 50

Answer: This was a really simple IDOR on the student.gothamedu.org portal. Once you register and login, you can go to the Transcripts page. There you can download your Transcript in the PDF format. The URL to download [the transcript] is: http://student.gothamedu.org/api/download_transcripts/<ID>. With this, you could iterate through the ID and download someone else's transcript. In the CTF Scope, it is mentioned that if you ever have an IDOR, try setting the id to 1 because that will be the victim account set by Gotham University. Doing so will download id 1's Transcript. The flag is in the Transcript once you open the PDF: bcunivflag{IDOR_FUN_48909109}

Race to the first place

Points: 100

Answer: This required exploiting a race condition on the student.gothamedu.org & management.gothamedu.org. Once you get access to the rocket chat of Gotham University, you can find two special/secret links. One of the links is a Trello board. Once you find the board and look up the person on Trello, you also find another page they had for a password. This credential was for the management.gothamedu.org. If you tried logging in with the password, you will realize that it will send a token to the email. Without the OTP you will not be able to logi n.

If you go to student.gothamedu.org, you will notice that it also requires an OTP token. On the challenge hint, we mentioned that both student.gothamedu.org and management.gothamedu.org share the same code. So if you find a vulnerability on the login at student.gothamedu.org, you will also find the same vulnerability on management.gothamedu.org.

Analyzing OTP:

If you look at the OTP token, you will realize it is the last four digit of the server timestamp. The OTP token is generated based on the time the server sent received the request. So there are two ways to exploit: you find what time you submitted the request and generate the OTP based on that. If not, you can send the login request to student.gothamedu.org and management.gothamedu.org at the same time. This will result in your student portal account receiving the same OTP token. This token can then be used to login to management.gothamedu.org. The flag was then at the /pentest/flag endpoint.

Recon 2

Points: 100

Answer: This flag required knowing them email address of all employees on Gotham University. Rocketchat instance (Our Secrets) has the email address of all employees. Once you have the email of all employees, you can bruteforce it on Google calendar to see if you can find any public Google calendar. One user that had their calendar public was [email protected]. In Google Calendar, you can add someone else's calendar to your list to see what time is best for meetings. Go to https://calendar.google.com/calendar/r/settings/addcalendar to add calendars. Once you add the calendar, you can search on it for specific strings. When you search for bcunivflag you will get the flag: bcunivflag{CALENDAR_ACCESS_48091093}

Recon 1

Points: 150

Answer: This is a Recon challenge. This means you do not need to exploit anything and just use publicly available information to get a flag. If you read the hints (cost 1 point), it told you to look for common repository storing applications. There are quite a few but three most popular ones are Github, Gitlab and Bitbucket. These websites are used to store codes for projects and also use automated tools to run them in servers. For this challenge, you need to look into Bitbucket.

The company for this pentest is Gotham University (gothamedu). However, Bitbucket does not have a detailed search result as Github does. So this will require you to do some guess and check. If you had already accessed the rocketchat instance, you would know that it had multiple users on it. You can use that username to generate possible user accounts and try to browse to them. In cases like these looking for gothamedu-{username} is better because most companies and employees follow that template. If you bruteforced the usernames, you would realize gothamedu-nharris is a valid user account.

This user has an it-portal source code on their account that can be accessed by anyone. Going on the commit history at https://bitbucket.org/gothamedu-nharris/gotham-itportal/commits/all, we realize that the last edit was done on a base.html file. Opening that specific commit shows the flag: bcunivflag{SOURCE_CODE_LEAK_490104901}

Storage Access

Points: 150

Answer: Storage access required you to learn something new the day of the event unless you had prior experience with AWS S3 buckets. S3 Buckets are file storage systems by AWS that a lot of companies use to store their user files. In the past, there has been a lot of news coverage on data leakage through misconfigured AWS bucket. In this case, the bucket was using a correct policy but not a valid policy for storing student's PDF. What this did was allow files to be downloaded without a signature if the request originated from files.gothamedu.org/. To exploit it, all you have to do is add a Referer header in your request that has something like http://files.gothamedu.org/file. You could do this with Burp Suite. The flag was in the flag.txt file. It was: bcunivflag{BUCKET_ACCESS_ACL_4890193491898}

Employee Directory

Points: 200

Answer: This required you to use nmap. Once you scanned all the ports, you will see it was running two very interesting services. An LDAP and an SAMBA server. After knowing this, if you tried attacking Samba directly, it won't work because the flag is in the nharris user account and that requires a password. So then you need to check the LDAP.

To attack LDAP, you can use the guest account to search through it. This required guessing what the domain name of the LDAP instance is set to be. In this case it was dc=directory,dc=gothamedu,dc=org. Then you use the ldapsearch command line tool. In order to use this, make sure to install ldap-utils with apt-get install ldap-utils on your system. Your one line command will then be: ldapsearch -h directory.gothamedu.org -x -b "dc=directory,dc=gothamedu,dc=org". Once you hit enter, this will give you information about all users in the LDAP instance. One of the users is nharris and their detail is as follows:

# nharris, itops, directory.gothamedu.org
dn: cn=nharris,ou=itops,dc=directory,dc=gothamedu,dc=org
cn: nharris
givenName: Nathanial
gidNumber: 500
homeDirectory: /home/users/nharris
sn: Harris
loginShell: /bin/sh
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: sambaSamAccount
uidNumber: 1001
uid: nharris
mail: [email protected]
sambaSID: S-1-0-0-29391
sambaNTPassword: 79cccf606041ee7e6881a7f02e718b4b

This gives the directory of the nharris account, their dn info for LDAP auth, email and also some SAMBA details. You can use LDAP to authenticate on SAMBA. In this case, you have the hash of the user password (check sambaNTPassword). Now that you have that, you can use smbclient command line tool to login. SMBClient allows direct login if you have a NT hash of a user password. Use the follwoing command line arguments smbclient -U nharris%79cccf606041ee7e6881a7f02e718b4b --pw-nt-hash //directory.gothamedu.org/nharris. This will log you in and your current directory (pwd) will be \\173.255.210.72\nharris\ which means you are in nharris samba share folder. If you do ls you will find that there is a flag.txt. You can then use mget to get the flag.txt. This will download the flag.txt file to your system. To read it exit out of samba and use cat to read the content. (mget by default downloads the file on current directory that you were in before authenticating to SAMBA)

Account takeover

Points: 200

Answer: This account takeover could be approached in multiple ways. You could either guess it and get the exploit to work or you complete the RCE challenge to exploit it.

Flask uses a secret-key that is in the source code to generate csrf_token and session values. Session values are used to identify the user for that session. If you leak or someone finds your session, it will lead to an account takeover. At student.gothamedu.org, the application used a weak secret-key. The secret-key used was studentportal. If you had already done the RCE, you could use the Flask SSTI to get the secret-key associated with the web app. This would have also given you studentportal.

MITRE's 2018 CTF has the script that you can then use to forge user 1's cookie. In this CTF you had the flag on user 1 account. Once you forged the cookie you should see the flag in the dashboard: bcunivflag{WEAK_KEY_489019485890}.

Our Secrets

Points: 300

Answer: This required reading our most recent blog post on Support system research and exploiting it. When you email [email protected], you get an automated reply from the support system. The support system used was Helpscout. Now, to exploit it you will go to rocketchat and register an account. In the name, you will give the hash of the ticket you submitted. Once done, you reply to the automated reply and wait for a support agent to get back. Once that is done, you should be able to verify the account and login. Once you were logged in, the flag was in the #general channel.

The blog that answers this question is at: https://sites.google.com/securifyinc.com/secblogs/scary-tickets

RCE

Points: 300

Answer: This required you to at first either bruteforce the API endpoints or get them through JIRA. To get access to jira.gothamedu.org:8080, you will need to first access the rocketchat instance. There you have the credentials for Nathanial Harris. Once you are logged in, to JIRA you find multiple endpoints. For /api/admin/student/classes/<string:id> you need a valid API key to see the class details. You will notice then that if you have the wrong API-KEY in the header, it will display it back to you. This was done through render_template_string(errormsg) function on Flask. If the errormsg is not sanitized, this leads to Server Side Template Injection. You can validate this by trying {{2*2}} as the API-KEY and the server will respond with 4. This proves that commands in {{}} are executing server side.

Looking up a Flask SSTI cheatsheet will allow you to find a payload to read files. If you read /etc/flag.txt you will get the flag.

Prod Access

Points: 500

Answer: This was the challenge with the highest point on Pentest. This was not because it was hard to exploit but because it was tedious to do so. Let's break it down:

  1. First access

The first vulnerability you needed for this one was on jira.gothamedu.org. When you browse to that it gives connection refused because it is not running on port 80. Instead, the JIRA web app ran on port 8080. One thing to always look out for when testing applications like JIRA are the version number. Most of these applications will have fixed critical vulnerabilities. Knowing the version number and checking if there was a security issue on that specific version is helpful. This instance had v7.3.2#73013-sha1:3d53c97 version running. JIRA versions less than 7.3.5 suffer from a Server Side Request Forgery (SSRF) vulnerability. SSRF allows you to make a request to a website or service from the server's side. Often time when you visit https://google.com you will be visiting through your browser (client), but with an SSRF you can make the server visit https://google.com and show you the details. This JIRA instance is vulnerable to that SSRF.

For this CTF, there was an internal domain: internalservices.gothamedu.org. This had a firewall rule for port 80: 80 ALLOW IN 45.79.85.44. This meant that port 80 would only respond if 45.79.85.44 requested to the server.

  1. Second Access

Once you had access to internalservices web app, you needed to perform some parameter fuzzing to see if you could find any vulnerabilities on it. For example, you could try running a bruteforce with most common parameters on web apps such as index, test, page, debug etc. This web app allowed debug as a parameter. Here is what the web app code looked like for the index file:

<?php


$debug = $_GET['debug'];
$command = 'python ../test.py '. $debug;

echo shell_exec('python ../test.py '.$debug);

?>
<h1>This is an API for ITOps to manage our domains.</h1>

The debug parameter was added to the command string and then executed with shell_exec. To get an RCE you had to first break the command python ../test./py <yourdebug>. A semi-colon can break the command into multiple pieces because the command string will then become: python ../test.py ;<yourcommand>. This will then execute test.py first and then your command. So if you did ?debug=;whoami it will display: www-data. Once you have the RCE the first thing to check is if you can access /etc/passwd. If you try cat /etc/passwd it will not work and you will get a 500 internal server error. This required using $IFS to add whitespace when sending the request to read /etc/passwd. So your command will be ;cat$IFS/etc/passwd.

  1. Third Access

Once you confirm that your RCE works, you can start listing the files. One of the files in the sub-directory where test.py existed was a priv_key file. This was an RSA generated private key for a user. The command to print it out was: cat$IFS../priv_key. This will give the private key:

MIIJKQIBAAKCAgEAuzexPlI2iV4PWLI6QCmP/FCzZjDANkBSy9FMeWumHtEWgujP
3jBA/HrNYHeuyr0TIvNz1mCcNC2IRglaMRHdHgA1VPdywkurWyN/3bmfowngpBim
......
eAk1JEACo34qKUV+Ew2R8Z89qsvU480S9NGyLhhakAgWKgaSRLFB7SHe1EBxTnOk
BPQQYQYwERnOCdlrgx5NlZXDgQH0DpDc5LBGOA1sng41VP/MMue3cBP8cOCpb+WA
zdXs//MQ5tckwAa1xUAS7zkLi4Jm64KCPqda76Efo9EPbwqd90A3n8UCTEyX

If you have a user's private key, there are multiple things you can do. This challenge required using the private key along with git to download source code of Gotham University. Gotham Edu has their Github at https://github.com/gothamedu. Once you have the private key, you can generate a public key from it by using: ssh-keygen -y -f <privatekey location> > <public key export>. This will export a .pub file which is the public key generated based on the private key. Once you generate the public key, change the permission for both the private key and the public key to chmod 600 id_rsa (or whatever you name the private key) and chmod 600 id_rsa.pub (or whaever the .pub is).

Once this is done, using git clone [email protected]:gothamedu/Production.git to download the source code. After this the flag is located at: school_students/app/__init__.py : bcunivflag{SSRF_CAN_BE_BAD_49819919}