Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [NSE] jboss-vuln-cve2010-0738.nse
From: Patrik Karlsson <patrik () cqure net>
Date: Sat, 16 Jun 2012 10:53:51 +0200

On Sat, Jun 16, 2012 at 5:39 AM, Tiago Natel de Moura <tiago4orion () gmail com
wrote:

Hi list, this is just a script that I created to exploit the CVE-2010-0738
of JBoss.

description = [[
JBoss Enterprise Application Platform is prone to multiple vulnerabilities,
including an information-disclosure issue and multiple
 authentication-bypass
issues. An attacker can exploit these issues to bypass certain security
restrictions to obtain sensitive information or gain unauthorized access
to the application.
this script will attempt to exploit one of these vulnerabilities and get a
reverse shell on the target machine.

This exploit is a rewrite to NSE of the Kingcope's perl exploit (
daytona_bsh.pl).

More information:
http://www.exploit-db.com/exploits/16274/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0738
http://www.securityfocus.com/bid/39710
]]

source:

https://github.com/tiago4orion/nmap-scripts/blob/master/jboss-vuln-cve2010-0738.nse

Here is a sample output:
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache Tomcat/Coyote JSP engine 1.1 (Tomcat 5.5)
| jboss-vuln-cve2010-0738:
|   VULNERABLE:
|   JBoss Application Server Remote Exploit
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE:CVE-2010-0738
|     Description:
|       JBoss Enterprise Application Platform is prone to multiple
|       vulnerabilities, including an information-disclosure issue
|       and multiple  authentication-bypass issues. An attacker can
|       exploit these issues to bypass certain security restrictions
|       to obtain sensitive information or gain unauthorized access
|       to the application.
|
|     Disclosure date: 2010-04-26
|     Extra information:
|       EXPLOIT SUCCESSFULL, REVERSE SHELL AT <reverse_host>:<reverse_port>
|     References:
|       http://www.exploit-db.com/exploits/16274/
|       http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0738
|_      http://www.securityfocus.com/bid/39710


Cheers.
[]'s

--

Tiago Natel de Moura
Consultor de Segurança da Informação
http://www.linkedin.com/in/tiagonatel
http://www.secplus.com.br/
http://github.com/tiago4orion
http://code.google.com/p/bugsec

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Hi Tiago,

This seems to be a very useful script! Thanks for taking the time to write
it!
We do have an existing, more generic, script that checks whether a resource
could be retrieved using different HTTP methods.
It defaults to the jmx-console and first tries a GET and then a HEAD. The
script also provides the possibility to change the path to something else
to test other servers than jboss for the same vulnerability. The name of
the script is http-method-tamper.

I'm not sure what to do here but I suggest the following, but would like
comments from others before we decide how to procede.
- We keep the http-method-tamper as a generic way for testing method
tampering.
- We extend the http-method-tamper script with spidering capabilities and
remove the connection it has to jboss.
- We add code to this new script that allows to do the check in a less
intrusive manner, in the same way as the http-method-tamper does.
- The check is default unless the reverse_host and revers_port arguments
are given, at which point the script does exploitation

Now for some comments on the script;

I would recommend not doing the product checks in the portrule. The reason
being that those fields are only populated if a version scan has been run.
My guess is that they are fetched from the http headers and it would
therefore be better to perform this check within the action method. This
way the script would always run, regardless if a version scan was selected
or not and you would be able to bail if you detect it not to be the product
you expect in the action method. Also, I think it might be worth continuing
when the product cannot be determined as this http header could simply have
been removed on valid targets.

This also applies for the OS check and determining of the appropriate shell
to use. Is there another way of doing it, that doesn't require the version
scan to be run? Ideally it would be determined from a http request to the
server. An alternative would be allowing the user to specify the shell in
an argument or in some way automatically try both. I guess
the Runtime.getRuntime().exec section of the Java code could be put in a
loop first trying cmd.exe and then /bin/sh and testing whether an instance
was properly created?

I think it would be a good idea to explain either in the comments of the
script, or as part of the result, that there is new code deployed to the
server and where. My reasoning behind this is that if you're doing a
pentest you would most likely want to inform you client of the change to
the app server to give them a chance to clean it up.

In general, you should declare parameters when they're used in favor of
putting them all on top initialized with nil.
Out of curiosity, what purpose does the sleep(5) call have, except for
waiting 5 seconds?

Thanks,
Patrik
-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]