MMD-0034-2015 - New ELF Linux/DES.Downloader on Elasticsearch CVE-2015-1427 exploit26 Jun 2015 This is a tough writing, and will be many information will be added after the initial release. We are pushed to release this as alert of an on-going attack on Elasticsearch host(s), it is a real malware incident report, below is the contents:
Elasticsearch [link] has vulnerability which is now exploited in the wild, this post is one of the attack which aiming the CVE-2015-1427 [link], quoted: a vulnerability in Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted script. Elasticsearch's Groovy dynamic scripting disabled by default from v1.4.3 due to this vulnerability [link], which is a recommendable way to mitigate this on going attack.
In this incident, the attacker is using the shell command to download and execute the malware shell script file, to collect sensitive information of the unix system hosted by Elasticsearch and send it to the remote host, parallel with download+install the ELF malware functioned as the botnet agent backdoor & downloader on the victim's host.It also audits the victim's system with Lynis [link] and send the result to the remote host too.
Attacker IP addresses and its origin;
188.8.131.52 ||AS9293 | 184.108.40.206/24 | HKNET | HK | hknet.com | HKNet Company Ltd/NTT Com Asia Ltd
220.127.116.11||AS9293 | 18.104.22.168/24 | HKNET | HK | hknet.com | HKNet Company Ltd/NTT Com Asia Ltd
22.214.171.124 ||AS4847 | 126.96.36.199/16 | CNIX | CN | chinatelecom.com.cn | China Networks Inter-Exchange
2015-06-18 10:07:54+02:00 to 2015-06-24 12:04:29+02:00
 Script: (filesender1.sh) = dcc78c4a1d940860566830a06331f2a5 5,726 bytes
 ELF : (dnler) = 982dd916fe4111f01233f8c928293383 806,314 bytes
 Script: (filesender1.sh)
The two functions of preparefile() and preparecmdresult() are where it started to perform the malicious actions. The (6) preparefile() is sending the copy of your file that can be grabbed as per listed "filelst" to be copied in to the directory under /tmp that was defined in CHROOT above:
The tarfile() functions is there to (8) archive all of the result of the command line executed output AND the system copied files, and sendfile() functions is for (9) sending them under specific URL in the remote host using cURL or wget with the POST method. By this URL we can see the OS type, hostname and message from the infected server. A botnet scheme indeed:
Those functions listed above is (10) executed in the main() function next lines in the bottom of the script. After the execution the script is (11) downloading lynix (the UNIX server legit audit tool, and run it with saving the audit result that is saved under save malicious directory made in /tmp to the remote host using the sendfile() function. Not only that the script is (12) downloading the ELF malware from the remote host and executing it from the same malicious directory too. And then the script is deleting all of the trace of the directory and files saved during the infection. The code is below:
We don't share the complete code of this script for the security policy, and this script was uploaded to the Virus Total. We haven't seen this before but the similar shell scripts were found plenty in the wild, so this malware can be categorized as a "Shell Backdoor".
 ELF : (dnler) Linux/DES.Downloader
"ip": "188.8.131.52 / 184.108.40.206/24",..geo location is pointing to this area in Hongkong:
"hostname": "No Hostname",
"city": "Hong Kong",
"org": "AS9293 NTT Com Asia Limited"
What is this ELF malware
As a summary, this malware will run under current Elesticsearch's user privilege or permission and check whether it can escalate its privilege (to root). After the self-checking for the current version and comparing to the previous installation, it will continue to run initially, or stopped if the previous running instance was detected, or requesting the update to the motherhost. During the initial installation, it will register an autorun in crontab, And it runs as daemon to then contacting (and keep on contacting regularly) the motherhost via HTTP to poke and requesting a download, and then to decrypt the part of downloaded (GIF in this case..can be changed) data (by DES2) and save it in the work directory to be executed. The dropped data (in this case, this also can be changed) is a shell script as per described in the section above.
We never see this type of ELF malware before, so we are naming it as Linux/DES.Downloader, this threat was detected by Benkow, so to honor his effort, internally in MMD I will refer it as Benloader :)
Some reversing snapshot
Proof of concept of the DES encryption used is as per decrypted in this video:
This downloader is self checking its version after installed first time by comparing the value stored in the infected machine:
To the fellow researchers and malware reversers (only!): The malware is designed to run only one time, to run it again is not that difficult, and I suggest to do what I did, patching the malware ELF binary in 0x0804a14b to not comparing EDX to EDI (by changing the value \39\FA to whatever values you prefer) and that makes the malware can run as initial everytime you executed, since it won't compare the previous version :)
And many more interesting data..
How does it run?
Following by the second request that is getting the response of the "GIF image file" download:
this is the image...
..this is the detail of that GIF:
Looks weird since the fact that GIF terminator 0x3b at offset 807(dec), 5497 bytes from end of file, meaning we have 5k of unknown data in there.
After the initial and GIF downloaded we have the same shell script saved in the malware working directory with the size more or less the same (5,726 bytes) as the unknown blob of data. There is a theory that have not been proved yet about this: So assuming the theory of DES encryption that stated: "Using (xx)DES does not change the string's length but it will be rounded to the next (xx bit)boundary" is correct, and we are all know that XOR decryption is not changing the size of the object too, we can assume that what was in the GIF unknown blob is the encrypted malware shell script version itself. NOTED: This part is to be edited upon proven later on (see the next part)
To PoC the downloaded file (script) was executed, I also seek for the kernel write syscall requesting for writing or copy the file as per described in above shell script. Be noted that during the ELF malware is executed there is no companion script was installed/placed in there. ..And I found the list of the system calls querying the list of files in the shell script and these data is not even hard coded in the ELF binary itself, this those calls were made under the various new PID that can be occurred after shell execution:
After advisory communication with good friends in Emerging Threat [link tributed] (thank to Will, Darien & Travis). we went back to the main() function in the ELF to confirm a XOR decryption loop used to decrypt the 5k blob of unknown binary in the downloaded GIF file, following by the writing the decrypted data to the new file, change the mode of file to the execution mode, as per shown in the below reversed code:
The XOR decrypted data is proven as the shell script backdoor malware described in the first part of the analysis, and thank you for the XOR decrypter script contributed by good friends in Emerging Threat [link tributed]! The PoC of the decrypting process can be seen in the below video.
Detection ratio and sample
The sample is shared in the kernelmode only-->[LINK]
Actor initial investigation
Certification and web trails of the actor exists in the internet, in example:
The information above lead us to the location of the actor which was in the below network under a certain time frame:
220.127.116.11/13We believe he "was" living in the area as per shown in below video. More data to be shared to the law enforcement only.
Feedback from security community (tweets)
AV-Test.org's helps to push rate of ELF AV detection ratio, below is the historical timeline for this ELF malware's detection: