Pre-preparations : The spicy middle for a sweet finish.

#!bin/bash Let’s start this part with a bang.

Want to know how we ended up here and what is ctf go to Part 1/4 , Part 2/4

After a lot of trouble, we could finally secure some train tickets to reach our onsite round at Kerala and hence our 26 hours train journey began.

Since this was our very first CTF, we planned to solve challenges during the train journey. We downloaded some images from Vulnhub such as Mr. Robot, Necromancer, BsidesTLV2018. We tried our best to solve the challenges but ended up reading the write-ups for most of them. Nevertheless, we learned a lot of new techniques and different approaches to solving a certain image.

One of the interesting challenges of BsidesTLV2018 was Redirect me….the song in the hint attached to the challenge eventually became our group anthem and our morning alarms :-)

The train exercises helped us to learn how to crack the VM, setting up the network, basic netcat commands, figuring out the IPs of target machines and basic Nmap port scanning.

We reached the hostel one day prior to the beginning of the event and got all the formalities done for the next three days of the amazing event.

The First Day:

The day began with breakfast for the participants after which the registrations for the event began where we got our badges and a goodie bag :).

After this, began the preparations for the CTF. There were 5 parallel sessions — one each for reverse engineering, pwn, forensics, web, and cryptography.

Since our team consists of 5 members, we had decided to split the roles for the CTF, and to make the most out of the sessions, all of us attended a session each.

• Forensics : Though the forensics session did not cover topics relevant to the attack defense style CTF (except network monitoring using Wireshark), the session was intended to serve as a starting point for the beginners to start with the field and covered topics like steganography, memory forensics, use of volatility, hardware hacking and also the use of Wireshark and tcpdump to capture and analyze packets (which would later go on to have astronomical benefits during the CTF as we came to realize later on).
• Crypto: The session covered topics regarding Cryptology and different types of Cryptography. Stream Ciphers were explained in-short followed by a few basic challenges. Then the main part, Block Ciphers, and its types AES, RSA were explained. Identifying the block sizes, mode of ciphers and decrypting the plain text based on the cipher characteristics. Even popular exploits like one byte at a time, bit flipping attacks were covered, followed by RSA based theorems like Fermat’s Little Theorem, Euler’s totient function.
• Web: As the field of web is vast, they began the session with a basic PHP challenge. We later learned about the variety of SQLi injection techniques. The techniques were tried out on the challenges on the Github link. The extension Wappalyzer tells us the language in which the source code is written which fastened our process.
• Reverse Engineering: The RE session, though interesting, began a bit slow. It began with discussions regarding core computer science topics of CPU architectures, Registers and Low-level Assembly programming, stacks. It did gradually speed up the pace with discussions on gdb, radare, gdb-peda. The session ended with a discussion on how to edit binary files to patch them in radare.
• Pwn: In accordance with the interconnection of this topic with RE, this session only began after the RE session. A discussion on Buffer overflow and how to prevent them from using Address Space Layout Randomization(ASLR) and Canary bytes initiated the session. ASLR bypass was also covered along with Global Offsets Table(GOT) and Procedure Linkage Table(PLT).

The Second Day:

On day two, we had a jeopardy style individual CTF event held by VMware along with the organizers as screening tests for Internships at VMware. The challenges were of a very high level as they were supposed to be part of the screening process for the participants. Even though we didn’t have prior experience of onsite CTFs, two of us decided to participate for the CTF.

Since challenges were pretty difficult, we being noobs couldn’t solve any challenge entirely but we almost solved 2 challenges. It was a good experience and we learned how to use the tools, solving challenges in a limited amount of time which would eventually help us in the actual event the next day. If you wish to have a look at the challenges.

After the CTF, we had a mock Attack-Defense CTF. During this, we learned to host the VM, configure the network and VM service, and apply the live patch for the vulnerable services present on our service. As it was just the mock, we were given easily exploitable services. We also thought of a few ideas to automate our exploits and also figured out how to divide the tasks among us.

Then began the long night. Now it was time to think more about how we were actually going to run the exploits on the services present on other team servers. We thought about hosting our own game-server and then host VMs on different laptops and try to exploit and patch the services as part of our practice session. But we failed to do so and also spent a large amount of time doing so. We then decided to just focus on automating the exploits and submission of flags although we ended up not using the scripts the next day, it made our work easy in making the exploits the next day.

We basically made a rough skeleton as we didn’t know what were the exploits would be and how the game-server would work. We knew that each service would have multiple vulnerabilities so we made different functions for each exploit and then numbered the exploits. The automation worked something like this: Exploit 1 runs' on all the team servers and collect the flags if the exploit works, if the exploit 1 doesn’t work on a specific server we run exploit 2 on it and so on. This process ran during each tick, collecting the flags and submitting the flags to the game server. A log file containing all the flags previously submitted was used so that the script doesn’t submit the same flags again and again so as to avoid unnecessary traffic on the network and also to avoid getting banned/disqualified ;).

Writing these scripts and preparing our minds made us confident enough about the fact that we wouldn’t screw up the automation part. Hoping we would figure out the exploits, we went to have a 2-hour long sleep.

For the final part of our Adrenaline filled adventure head over to Part4/4.