deploy index error

[wireghoul]

root@kali:~/clusterd# ./clusterd.py -i -p -a jboss -v 5 --deploy /root/redteam.war

    clusterd/0.2 - clustered attack toolkit
      Supporting jboss, coldfusion, weblogic, tomcat

[2014-03-06 03:51PM] Started at 2014-03-06 03:51PM [2014-03-06 03:51PM] Servers' OS hinted at windows [2014-03-06 03:51PM] Fingerprinting host 'REDACTED' [2014-03-06 03:51PM] Server hinted at 'jboss' [2014-03-06 03:51PM] Checking jboss version 5.1 JBoss Web Manager... [2014-03-06 03:51PM] Checking jboss version 5.1 JBoss JMX Console... [2014-03-06 03:51PM] Checking jboss version 5.1 JBoss Web Console... [2014-03-06 03:51PM] Checking jboss version 5.0 JBoss JMX Console... [2014-03-06 03:51PM] Checking jboss version 5.0 JBoss Web Console... [2014-03-06 03:51PM] Checking jboss version Any JBoss EJB Invoker Servlet... [2014-03-06 03:51PM] Checking jboss version Any JBoss HTTP Headers (Unreliable)... [2014-03-06 03:51PM] Checking jboss version Any JBoss JMX Invoker Servlet... [2014-03-06 03:51PM] Checking jboss version Any JBoss RMI Interface... [2014-03-06 03:51PM] Checking jboss version Any JBoss Status Page... [2014-03-06 03:51PM] Matched 2 fingerprints for service jboss [2014-03-06 03:51PM] JBoss EJB Invoker Servlet (version Any) [2014-03-06 03:51PM] JBoss JMX Invoker Servlet (version Any) [2014-03-06 03:51PM] Fingerprinting completed. [2014-03-06 03:51PM] Preparing to deploy /root/redteam.war... Traceback (most recent call last): File "./clusterd.py", line 115, in run(options) File "./clusterd.py", line 100, in run auxengine(fingerengine) File "/root/clusterd/src/core/auxengine.py", line 50, in auxengine deployer.run(fingerengine) File "/root/clusterd/src/core/deployer.py", line 47, in run deployer.deploy(fingerengine, fingerprint) File "/root/clusterd/src/platform/jboss/deployers/ejbinvokerservlet.py", line 24, in deploy fp = [f for f in fingerengine.fingerprints if f.version != 'Any'][0] IndexError: list index out of range

[hatRiot]

I fixed the index out of range bug in dev, but I'm not quite sure how to handle a case like this. How did you determine the remote JBoss instance is 5.x?

[hatRiot]

So your case is pretty unique in that clusterd determines that an [EJB/JMX]InvokerServlet is exposed, but can't reliably determine the version of the JBoss server. I'm kind of surprised that it couldn't pull HTTP headers; are they not sent from the server/blocked by intermediary device?

For one, this deployer requires that your payload be a JSP; this is because for 5.x we need to invoke the DFS deployer, and not the regular HttpAdaptor (which is broken in 5.x). So you'll need to do --payload [some.jsp]

As far as remediation, I've added a prompt to these deployers that allows the user to set the version, if they know it (or want to guess it). Let me know if this works for you.

Thanks for the report on this!

[wireghoul]

No luck... wall of text below:

root@kali:~/clusterd# cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = https://github.com/hatRiot/clusterd.git
[branch "master"]
    remote = origin
    merge = refs/heads/master
root@kali:~/clusterd# git pull
WARNING: gnome-keyring:: couldn't connect to: /root/.cache/keyring-wtDYwy/pkcs11: No such file or directory
Already up-to-date.

root@kali:~/clusterd# ./clusterd.py -i REDACTED -p REDACTED -a jboss --deploy ./w3af-webshell.jsp 

        clusterd/0.2 - clustered attack toolkit
          Supporting jboss, coldfusion, weblogic, tomcat

 [2014-03-07 01:14PM] Started at 2014-03-07 01:14PM
 [2014-03-07 01:14PM] Servers' OS hinted at windows
 [2014-03-07 01:14PM] Fingerprinting host 'REDACTED'
 [2014-03-07 01:14PM] Server hinted at 'jboss'
 [2014-03-07 01:14PM] Checking jboss version 3.2 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 3.2 JBoss Web Console...
 [2014-03-07 01:14PM] Checking jboss version 3.0 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 4.2 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 4.2 JBoss Web Console...
 [2014-03-07 01:14PM] Checking jboss version 4.0 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 4.0 JBoss Web Console...
 [2014-03-07 01:14PM] Checking jboss version 5.1 JBoss Web Manager...
 [2014-03-07 01:14PM] Checking jboss version 5.1 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 5.1 JBoss Web Console...
 [2014-03-07 01:14PM] Checking jboss version 5.0 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 5.0 JBoss Web Console...
 [2014-03-07 01:14PM] Checking jboss version 6.0 JBoss Web Manager...
 [2014-03-07 01:14PM] Checking jboss version 6.1 JBoss Web Manager...
 [2014-03-07 01:14PM] Checking jboss version 6.1 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 6.0 JBoss JMX Console...
 [2014-03-07 01:14PM] Checking jboss version 7.1 JBoss Management...
 [2014-03-07 01:14PM] Checking jboss version 7.0 JBoss Management...
 [2014-03-07 01:14PM] Checking jboss version 8.0 JBoss Management...
 [2014-03-07 01:14PM] Checking jboss version Any JBoss EJB Invoker Servlet...
 [2014-03-07 01:14PM] Checking jboss version Any JBoss HTTP Headers (Unreliable)...
 [2014-03-07 01:14PM] Checking jboss version Any JBoss JMX Invoker Servlet...
 [2014-03-07 01:14PM] Checking jboss version Any JBoss RMI Interface...
 [2014-03-07 01:14PM] Checking jboss version Any JBoss Status Page...
 [2014-03-07 01:14PM] Matched 2 fingerprints for service jboss
 [2014-03-07 01:14PM]   JBoss EJB Invoker Servlet (version Any)
 [2014-03-07 01:14PM]   JBoss JMX Invoker Servlet (version Any)
 [2014-03-07 01:14PM] Fingerprinting completed.
 [2014-03-07 01:14PM] Preparing to deploy ./w3af-webshell.jsp...
Traceback (most recent call last):
  File "./clusterd.py", line 115, in <module>
    run(options)
  File "./clusterd.py", line 100, in run
    auxengine(fingerengine)
  File "/root/clusterd/src/core/auxengine.py", line 50, in auxengine
    deployer.run(fingerengine)
  File "/root/clusterd/src/core/deployer.py", line 47, in run
    deployer.deploy(fingerengine, fingerprint)
  File "/root/clusterd/src/platform/jboss/deployers/ejbinvokerservlet.py", line 24, in deploy
    fp = [f for f in fingerengine.fingerprints if f.version != 'Any'][0]
IndexError: list index out of range

GET -e -d http://REDACTED:REDACTED/
404 Not Found
Connection: close
Date: Fri, 07 Mar 2014 02:15:40 GMT
Server: Apache-Coyote/1.1
Content-Length: 0
Client-Date: Fri, 07 Mar 2014 02:15:42 GMT
Client-Peer: REDACTED:REDACTED
Client-Response-Num: 1

root@kali:~/clusterd# GET -e http://REDACTED:REDACTED/invoker/JMXInvokerServlet/
200 OK
Connection: close
Date: Fri, 07 Mar 2014 02:16:13 GMT
Server: Apache-Coyote/1.1
Content-Type: application/x-java-serialized-object; class=org.jboss.invocation.MarshalledValue
Client-Date: Fri, 07 Mar 2014 02:16:15 GMT
Client-Peer: REDACTED:REDACTED
Client-Response-Num: 1
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1

??sr$org.jboss.invocation.MarshalledValue?????J?
<snip>

[wireghoul]

No luck with dev branch either

 [2014-03-07 02:16PM]   JBoss EJB Invoker Servlet (version Any)
 [2014-03-07 02:16PM]   JBoss JMX Invoker Servlet (version Any)
 [2014-03-07 02:16PM] Fingerprinting completed.
 [2014-03-07 02:16PM] Preparing to deploy ./w3af-webshell.jsp...
 [2014-03-07 02:16PM] Could not reliably determine version, please enter the remote JBoss instance version:  > 5.0
Traceback (most recent call last):
  File "./clusterd.py", line 115, in <module>
    run(options)
  File "./clusterd.py", line 100, in run
    auxengine(fingerengine)
  File "/root/clusterd/src/core/auxengine.py", line 50, in auxengine
    deployer.run(fingerengine)
  File "/root/clusterd/src/core/deployer.py", line 47, in run
    deployer.deploy(fingerengine, fingerprint)
  File "/root/clusterd/src/platform/jboss/deployers/ejbinvokerservlet.py", line 46, in deploy
    if fp.version in ["5.0", "5.1"]:
AttributeError: 'list' object has no attribute 'version'

[hatRiot]

That's what I get for not completely testing the code. Sorry about that.

Can you try pulling again?

[wireghoul]

I expect this should normally work, I haven't been able to deploy a shell on this box with any code at all.

 [2014-03-07 02:26PM] Could not reliably determine version, please enter the remote JBoss instance version:  > 5.0
Invocation Exception
org.jboss.invocation.InvocationException
    at org.jboss.invocation.http.servlet.InvokerServlet.processRequest(InvokerServlet.java:188)
    at org.jboss.invocation.http.servlet.InvokerServlet.doPost(InvokerServlet.java:224)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:662)
 [2014-03-07 02:26PM] Finished at 2014-03-07 02:26PM

The server does specify Jboss 5.0 in the X-Powered by header, so perhaps clusterd should consider using this version.

Cheers, Eldar

[wireghoul]

Just for coverage, this was with JMXdeployer:

 [2014-03-07 02:33PM] Could not reliably determine version, please enter the remote JBoss instance version:  > 5.0
Invocation Exception
org.jboss.invocation.InvocationException
    at org.jboss.invocation.http.servlet.InvokerServlet.processRequest(InvokerServlet.java:188)
    at org.jboss.invocation.http.servlet.InvokerServlet.doPost(InvokerServlet.java:224)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:662)
 [2014-03-07 02:33PM] Finished at 2014-03-07 02:33PM

[hatRiot]

This is an interesting case; it looks like a request to the default interface doesn't return the X-Powered-By header, but a request to the JMXInvokerServlet does. The JBossHeaders fingerprint is what performs that testing, and I'm only checking against the default interface. Are all of the other interfaces undeployed completely?

So typically, as you've noted, there would be a fingerprint for 5.x (since its impossible to differentiate between 5.0 and 5.1 via HTTP headers) that would set the version for the InvokerServlet. Looks like I'll have to add a check to the invoker servlets for a header too.

My guess for the crashing there (as I've tested this on 5.0 and 5.1) is that it requires authentication, or that they're broken in some other way (unwritable directories? getting popped on the wire? just flat-out broken?) Unfortunately the invocation exception doesn't give us too much information. Do you by any chance have access to this box, or is this on a client? Either way, this looks like a fairly locked down JBoss instance.

[wireghoul]

No access to the box, guess we will never know. Thanks for the help.

[hatRiot]

Thanks for the report! Let me know if you find anything else and we can open this back up.