Hacking Book | Free Online Hacking Learning


exploiting elasticsearch vulnerabilities

Posted by chiappelli at 2020-02-27

Markus Manzke is a Security Analyst at 8ack, an AlienVault partner With the rise of inexpensive Virtual Servers and popular services that install insecurely by default, coupled with some juicy vulnerabilities (read: RCE - Remote Code Execution), like CVE-2015-5377 and CVE-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 / 57udp/syn2500 VT - 27 / 56ssss/508 VT - 12 / 56 iBots, also referred to as IptabLex/IptabLes, have been around for quite some time and were well analyzed in May 2014 and again in June 2015 by MalwareMustDie. yf2: VT - 21 / 56 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): 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 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 ( ); 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. In a follow-up blog we'll take a closer look on the botnet-infrastructure itself, and analyze it more deeply. The OTX pulses we created are: ElasticSearch-Botnet C&C-Master DNS-Names ElasticSearch-Botnet C&C-Master IPs ElasticSearch Botnet - Botware Download URLs Footnotes it will be exploited, the question is not IF, but WHEN; scanners are scanning, 24/7 References Shodan: It's the Data, Stupid! A few things about Redis security Elasticsearch CVE-2015-5377 What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability MongoDB 2.2.3 - nativeHelper.apply Remote Code Execution MMD-0025-2014 - ITW Infection of ELF .IptabLex & .IptabLes China #DDoS bots malware Akamai: Threat Advisory: XOR DDoS Appendix Full exploit-code, as seen by our honeypots Domains queried to get C&C - IPs List of servers that hosts various versions of bots (bot-providers) current C&C-IPs from the bots we executed and analyzed Latest Entries Sets arriving - watching Scanners searching for Bittorrent clients ElasticZombie - Inside an ElasticSearch - Botnet Swell on the horizon - watching Scanners searching for Bittorrent clients DDoS-Angriffe auf ukrainische und russische Rechenzentren Gmail + CSP - a short analysis Server-Botnet with massive SSH-Brute-Force-Attacks (EN) Server-Botnetz mit massiven SSH-Brute-Force-Attacken (DE) SHA1-basierte SSL-Zertifikate und Browserwarnungen This is the END Also R.I.P. SSLv3 suPHP might be exploited through Shellshock About the Author Bio: Markus Manzke is a Security Analyst with a German partner of AlienVault's, 8ack.Please follow 8ack on Twitter.