VIVID CTF Finals 2024

Intro Dhanraj Chavan, Jeetesh Gowder, Mayank Ramnani, Pratham Gupta & Sourabh Rajguru participated in the VIVID CTF finals organized by NCAE. We advanced through the qualifications and competed in the in-person finals held in Augusta, Georgia. The competition spanned four days and featured various events: a jeopardy-style CTF, red team challenges, blue team challenges, and a king-of-the-hill round. We secured 5th place in the finals among 15 teams. They provided us with fully functional Kali Linux and Windows machines, which we could access directly through our web browsers, similar to HackTheBox Pwnbox. Therefore, we don’t have the solver scripts, but we will explain the challenges in detail. ...

Intro Challenges were categorized into common CTF domains—Reverse Engineering, Web Exploitation, Binary Exploits, Cryptography, Digital Forensics, and Networking. One of the hard challenges was, Binary Challenge We began by loading the binary into Binary Ninja to understand what it did and where it might be vulnerable. We found that the binary was protected with common security measures: non-executable stacks, stack canaries, and Address Space Layout Randomization (ASLR). These would make a simple buffer overflow attack much harder. Then, we noticed a function that handled user input in a suspicious way. It read more data than expected and wrote it into a fixed-size buffer. This hinted that we might be able to overwrite important data next to that buffer, maybe something like a function pointer stored in the Global Offset Table (GOT). We needed a memory address leak to get past ASLR. The binary did print out some debugging info, which included a memory address. With that address, we could figure out where libc was loaded in memory. With NX enabled, we couldn’t just put our shellcode on the stack. Instead, we used a ROP chain to call system("/bin/sh") from libc. Hence using a python script using pwntools, First we leak the memory address of puts and using this we get libc’s base address. Using this, we get system and bin sh address using: libc_base = leak - libc.symbols['puts'] system_addr = libc_base + libc.symbols['system'] bin_sh_addr = libc_base + next(libc.search(b'/bin/sh\x00'))) Then to craft the ROP payload, First we find a gadget like pop rdi; ret using ROPgadget Then, push the address of /bin/sh onto the stack so that pop rdi; ret sets rdi to /bin/sh Finally, call system() to run the shell. payload = b'A' * offset payload += p64(rop.chain())

Intro We were given multiple linux and windows machines to attack and gain flags, each challenge set us up for the next few challenges, one of the hard challenges was: Gaining Access to Emails on Windows We had several windows machines in the subnet but we had to access emails of the user “Joe” on one of the machines. We had credentials for one of the windows machines from a previous web challenge based on sql injection which was solved by running sqlmap on the login page. To access any of the windows machines, we had to use Remote Desktop Protocol (RDP). After logging in through RDP, our account didn’t have administrator privileges and we had limited remote tooling. We then started enumeration, we noticed Joe under C:\Users\ but didn’t have access to any of the files. We tried using proxychains first as we had access to another windows machine which was in the same network as this windows machine but after wasting 1 hour on it and making the connection work, even that machine didn’t have access to Joe’s account. Then we noticed one of the applications installed was Mozilla Thunderbird, an email client. The challenge said to find the emails so maybe this might be the way. Thunderbird stores each user’s emails, account details, and saved credentials within their own profile directory, typically found at: C:\Users\<username>\AppData\Roaming\Thunderbird\Profiles\<randomstring>.default\ Thunderbird holds several key files: prefs.js: Configuration and account settings key4.db and logins.json: Encrypted saved passwords .mab / sqlite files: Address books and other metadata Mail/ImapMail: Containing the actual stored emails in MBOX or Maildir-like formats But we still needed Joe’s local password, we found this on the system login log files which were not stored securely as it was in the backups directory. Now we logged in through Thunderbird using Joe’s credentials, then we were able to see his emails but the contents were encrypted. Then using Cyberchef, we decrypted it using the Blowfish decrypt tool. Then we finally got the flag.

Intro Blue team challenges were comparatively easier than the other days as most of it included analyzing log files, pcap files and firewall configurations. One of the interesting challenges was: Detecting a Brute-Force Attack from Windows Logs We started by looking at the Windows Event Logs. Specifically, we focused on the Security and System logs since they record information about login attempts and network connections. To open these logs, we used the built-in Event Viewer on Windows. The logs contain thousands of entries, making it hard to spot suspicious activity at first glance. We applied filters to look for events that indicated failed login attempts. In Windows, these typically show up as events with certain IDs (for example, Event ID 4625 for failed logins). Once we isolated failed login attempts, we noticed a pattern, a single IP address showing up repeatedly, trying to log in to the system within the same timeframe. Normal users don’t fail logins so many times in a row, especially not that quickly. Within the event details, we found fields that listed the source IP address. This is the address from which the attack attempts were made. By examining related firewall logs or the event’s network information, we also identified the port that was being targeted, 3389 Remote Desktop Protocol (RDP) We counted how many failed login events came from the same IP within a certain time frame. The logs clearly showed many coming in the same second. Then we got the flag after we gave the right answer to the question, State the number of login attempts made using brute forcing? We learned how to use event viewer to find the right logs to analyze and how to read and extract data from log files.

Intro King of the Hill (KotH) Challenges involve a user taking control of a server and leaving their identifier on a specified target server/application. This indicates which user/team has control of the server. Network 1. Team Subnets: Each team has a subnet containing: 1 Boundary Vyos Router at .1 IP, which connects to the Hill Subnet. 5 Kali Linux Systems for offensive actions. 1 Flag Server at .100 IP, where each team needs to place their CTF ID in owner.txt to score points. 2. Hill Subnet (192.168.20.0/24): Contains vulnerable Linux, Windows 10, and Windows 11 flag servers. Also includes a Big Hill server that awards 3 points per poll if captured. Off-limits Hill (VIVID Flag): A restricted flag that incurs penalties if captured. 3. Access Control and Credentials: Each team’s boundary router can be accessed via SSH on port 22 using vividctf:vividctf. Each team’s flag server is accessible via SSH on port 22222 with vividctf:vividctf. Boundary routers block external incoming traffic on ports 22 and 3389 by default. Each team is allowed to sabotage others by modifying configurations, except on their Kali systems. 4. Objective: Teams need to place their CTF ID in the owner.txt file on their own flag server and on as many Hill Subnet flag servers as possible. Points are awarded every 60 seconds based on the contents of owner.txt files in each server. Each team can reach the Hill Subnet as well as other teams’ subnets, enabling cross-network attacks and defenses. Action Plan: 1. Planning and Team Strategy At the outset, we conducted a team discussion to devise an action plan. Roles were distributed as follows: 2 members focused on attacking: Their goal was to target opponent systems and the Hill subnet. 2 members focused on defending: They ensured the security of our subnet and servers. 1 member focused on reconnaissance: This role was crucial for gathering intelligence on other teams and the Hill subnet. 2. Initial Target: Routers Our first target was the boundary routers of other teams. By compromising their routers, we aimed to disrupt their communication and gain a strategic advantage. This step ensured we could manipulate or observe network traffic as needed. 3. Hill Subnet Reconnaissance After running a host scan on the Hill subnet, we discovered multiple machines with active services. To identify the services running on these machines, we executed a service detection scan using the following command: nmap -iL hill.txt -p- -sV 4. Discovery of Unusual Activity During the scan, one machine stood out with over 500 open ports in the range of 32000 to 60000. Nmap failed to identify the specific services on these ports due to the use of decoys, which masked the actual services. 5. Flag Server Review When we obtained access to our flag server, we conducted a thorough review of all the open ports and running services on the machine. We found that there was a Python service running on a randomized port between 40000-60000 which could grant anyone backdoor access to the machine given a correct string input payload. Our assumption was that the initial state of all the flag servers in the competition would be the same, and thus the backdoor would exist on flag servers of all teams. 6. Automated Port Scans Our assumption was proven correct when we did a port scan in the range 40000-60000 on other team’s flag servers, and found one port giving us different output than the others. This was done using the following command: for port in {40000..60000}; do nc 192.168.2.100 $port; done This allowed us to iterate through the ports and look for unexpected responses. 7. Exploiting a Backdoor Once the port was identified, exploiting the backdoor was as simple as crafting a payload that was sent after we established a connection using the above netcat command. The backdoor gave us a limited /bin/sh shell, which we transformed into a full fledged shell with: /bin/bash -i Thus, now we had full access to the flag servers of multiple teams. We also made sure to patch the running backdoor on our flag server so as to not be compromised the same way by other teams. 8. Claiming Flag Servers The scoring system of the competition was based on which team’s flag was in the /root/owner.txt file of each flag server. Initially, we edited the owner.txt file to claim ownership and earn 3 points per minute. However, we couldn’t establish persistence, and an opposing team eventually removed our access by stopping our shell process and patched the backdoor. 9. Web Server Exploitation On further analysis of the flag server, we also discovered a running web server. Nmap scan report for 192.168.2.100 Host is up (0.00048s latency). Not shown: 999 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Node.js Express framework Through reconnaissance and testing, we identified a command injection vulnerability in the web application. Exploiting this vulnerability, we regained access to the machine through this alternative vulnerability. 10. Establishing Persistence This time, so as to not get kicked out of the flag servers by opposing teams, our first goal was to establish persistence. This was done via a few steps: Putting our ssh public key in ~/.ssh/authorized_keys: echo “ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCqIvZaOr0exvLzNtjueoj3qyYydaHFgSgbjn3OqE6XVgydjIP4cIfN2xOxrT56JQODsoBya8HLrRrejNaLw6sK+8+8Vh+J/kp5Qb3J4kmVdosvWhWV/QWlTlmVassAwz0laZHTZucbYtH45zJ9RpjWpgbBCmgc8s5LN+88ZQcob17F0+r/GeBH+3KBzV/CccPV+0nQ2Umr94UDqixDUMEI1oOmi88jV/EUVIgP9l8Wjz0AfcCLKG0mT7EIiQpPsN2GfYQ0lcJBpp2+OIcqwZ7q4DgGQOz1OKgbTemC3XZ6fGsNxtbrdzGvwKo4c3LLm/DKI5hVx826NiWikNNox/9kM1VipqfnOozsQLdN6CjGUarExlsvHb6iP/UHHc537jB3ZiYHKHeE1tbkiBFKOAFHfw8VkY+s7SQCcMLOuID91epMUQoKIp2pXU88wYEQuf7t0J/9/pJRbaK8VI+mVPCSVcZ5K2zSw+J/W3qVpIjnGuqPK8bJa0ftGfqgXBBPkk0= mayank” > ~/.ssh/authorized_keys Changing the root password to something only our team knew Kicking all the other people on the server by terminating their bash processes using the following command: current_pid=$$; for pid in $(pgrep -x bash | grep -v "$current_pid"); do kill -9 $pid; done Doing this on a few flag servers, we now had full exclusive access to multiple flag servers. 11. Locked Permissions and Claiming Flags Upon regaining persistent access, we found that the permissions on owner.txt had been locked using the chattr command, making it read only and preventing us from modifying the file. We discovered this by getting errors when writing to the file even though we were root, the file was owned by root and the file had permissions 0o644. On checking the file using lsattr we confirmed that the write attribute had been removed, thus we needed chattr to add the write attribute back to the file. Additionally, the chattr command was also removed from its original location in the /bin/ directory. This step, likely implemented by the opposing team before we kicked them, was to mitigate our attempts to claim points. However, on searching for the whole chattr binary in the whole filesystem, we found it hidden in a randomly named directory: find / -name chattr 2>/dev/null Output: /var/7cy7grc93q97c/chattr Using the chattr binary, we changed the attributes of the owner.txt file such that we could have write access, and put our flag in the file to start gaining points. We also used chattr to remove write access from the owner.txt file from ours and other flag servers that we pwned just to make it difficult for an opposing team to change this file even if we lose access somehow. But that did not happen. Summary Before the King of the Hill segment of the competition, we were in 11th place. But after the King of the Hill, our team ended up in 5th place. Being fast, constantly monitoring the machines we owned for any suspicious activity, and constantly attacking other teams ensured that we did very well in the part of the competition, leading to substantial gaining of ranks. We learned about conducting reconnaissance, finding vulnerabilities through code review, exploiting servers through known vectors and maintaining persistence after compromising a machine through this competition. ...