Securing/Hardening Jboss AS 4.2.X & 5.1.0 Part 1

Intro
I have noticed that there seems to be a ton out there on how to exploit the default configurations of Jboss, but no real information on how to secure and mitigate the threats that currently exist. Most of what I will be posting below can be found throughout the jboss community forums and other web forums on this topic. I  had trouble locating a definitive place that contains a HowTo or baseline for securing Jboss. If this does exist I am sure you will All let me know :)

I have yet to see something out there for Jboss and other J2EE applicaiton servers so I decided to do a write-up to help out others in the community that may be struggling to protect the Jboss 4.2.X & 5.1.0 servers. by no means do I take any credit for the information contained within, as I have said most of this information is already out there on the internet and will provide references where applicable, I am putting this together for the administrators out there to have a single place to locate this information and use it as a guideline in hardening their Jboss deployments on Linux.

Finally, although I have thoroughly tested ALL of the below, use of this guide is at your own risk, any and all changes should be tested prior to ever implementing these into a production environment. 

Prior to beginning

First and foremost make sure you have already gone through and hardened your operating system, The best place to start are with the CISecurity benchmarks, locate the one relevant to your operating system.

Note: We will be focusing on Linux deployments

Service Account and Permissions

Create a user service account 

[root@server /]# adduser jboss

make sure the jboss user has ownership of the files under $JBOSS_HOME ie if $JBOSS_HOME is /opt/jboss-4.2.2.GA

[root@server /]# chown -R jboss.jboss /opt/jboss-4.2.2.GA

Modify the startup script so that

• it is set to run as the created user 
• binds to the appropriate IP address rather than 0.0.0.0 or 127.0.0.1
• starts the correct context in our case we will use the "default" context

In our case the startup script will be $JBOSS_HOME/bin/jboss_init_redhat.sh the default script should look like the below

#define where jboss is - this is the directory containing directories log, bin, conf etc
JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss"}

#define the user under which jboss will run, or use 'RUNASIS' to run as the current user
JBOSS_USER=${JBOSS_USER:-"jboss"}

#make sure java is in your path
JAVAPTH=${JAVAPTH:-"/usr/local/jdk/bin"}

#configuration to use, usually one of 'minimal', 'default', 'all'
JBOSS_CONF=${JBOSS_CONF:-"default"}

Following our example we should change the highlighted in yellow to look like the below

# the bind IP Address
JBOSS_HOST="192.168.1.200"
#define where jboss is - this is the directory containing directories log, bin, conf etc
JBOSS_HOME=${JBOSS_HOME:-"/opt/jboss-4.2.2.GA"}

#define the user under which jboss will run, or use 'RUNASIS' to run as the current user
JBOSS_USER=${JBOSS_USER:-"jboss"}

#make sure java is in your path
JAVAPTH=${JAVAPTH:-"/usr/local/jdk/bin"}

#configuration to use, usually one of 'minimal', 'default', 'all'
JBOSS_CONF=${JBOSS_CONF:-"default"}

Further down in the same file locate the start and stop commands used to stop and start jboss, they should look like the below

JBOSS_CMD_START="cd $JBOSS_HOME/bin; $JBOSSSH"
JBOSS_CMD_STOP=${JBOSS_CMD_STOP:-"java -classpath $JBOSSCP org.jboss.Shutdown --shutdown"}

Change the stop command to

JBOSS_CMD_STOP="java -classpath $JBOSSCP org.jboss.Shutdown -S -s $JBOSS_HOST"

Upgrade Underlying components
I wont cover how in this post but, the most commonly overlooked item in securing jboss is that developers and administrators tend to overlook upgrading the modules in use to their latest release for their version. Jboss should be upgraded to the latest release but we know how difficult this can be. In the event you cannot upgrade to the latest release, you should at the very least upgrade to the latest patch release. i.e if you are running the 4.2 AS release you should be running Jboss AS 4.2.3 The components you should upgrade are as follows

• JbossWS
• Support containers list (fairly easy upgrade)
• JbossWeb
• Far more complex to upgrade and not advisable as it's easier to upgrade to the newer Jboss AS version (developers may say otherwise)

The reason I brought up upgrading the components prior to carrying on with the hardening is if you were to upgrade these components afterwards, you would have to start over with hardening Jboss (saves time)

Information Leakage/Disclosure

In this section I will cover off on how to remove those pesky header responses which disclose the version of Jboss and Containers in use. I will also cover how to make you you aren't inadvertently disclosing your machines internal IP through JbossWS.

If we take a look at the below screen cap which was taken from firebug you can see just how much information you leak with the default setup.

in the above example we can see that in the response header 

• Server Field 
• we have an Apache-Coyote server which usually give an indication of Tomcat
• X-Powered-By Field
• a Servlet Container version 2.4
• a Jboss-4.2.2.GA server
• Build and SVNTag number
• Tomcat 5.5

So with the above information alone we can discern that this site is running a Jboss-4.2.2.GA server and that server is running the default Tomcat-5.5 as it's web container (default)

To fix the above we can make some simple changes to the config files.

X-Powered-By:

The best way to modify this is actually not to disable it but to change this to something more meaningful to you . To modify this setting the file(s) are located at

Jboss-4.2.X: $JBOSS_HOME/server/$context/deploy/jboss-web.deployer/conf/web.xml

Jboss-5.X.X : $JBOSS_HOME/server/$context/deployers/jbossweb.deployer/web.xml

Edit the web.xml file and locate the section below, which should be close to the top for both versions

"CustomHeadersFilter"

 <!-- ================== Common filter Configuration ==================== -->
 <filter>
    <filter-name>CommonHeadersFilter</filter-name>
    <filter-class>org.jboss.web.tomcat.filters.ReplyHeaderFilter</filter-class>
    <init-param>
       <param-name>X-Powered-By</param-name>
       <param-value>Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5</param-value>
    </init-param>
 </filter>
 <filter-mapping>
    <filter-name>CommonHeadersFilter</filter-name>
    <url-pattern>/*</url-pattern>
 </filter-mapping>

Change the above highlighted in Yellow to the name of your application and version number, or whatever you like, for the purpose of this we will change this to "CHAMGEME"

 <!-- ================== Common filter Configuration ==================== -->
 <filter>
    <filter-name>CommonHeadersFilter</filter-name>
    <filter-class>org.jboss.web.tomcat.filters.ReplyHeaderFilter</filter-class>
    <init-param>
       <param-name>X-Powered-By</param-name>
       <param-value>CHANGEME</param-value>
    </init-param>
 </filter>
 <filter-mapping>
    <filter-name>CommonHeadersFilter</filter-name>
    <url-pattern>/*</url-pattern>
 </filter-mapping>

Save the file, restart Jboss and now you should see in the header response your version of the X-Powered-By as below in our example.

Now let's do the same thing for the "Server" version. To do so you will need to modify the below file(s) depending on your version of Jboss.

Jboss-4.2.X: $JBOSS_HOME/server/$context/deploy/jboss-web.deployer/conf/server.xml

Jboss-5.X.X : $JBOSS_HOME/server/$context/deploy/jbossweb.sar/server.xml

Locate the Connector "8080" which is the default HTTP Port

Note: the below changes should be applied to all connectors in use otherwise the responses will be different

    <Connector port="8080" address="${jboss.bind.address}"
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true" />

Add:
server="CHANGEME" so that the connector now looks like the below

    <Connector port="8080" address="${jboss.bind.address}"
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true" server="CHANGEME"/>

After changing this a restart will be required in order for this change to take effect. As you can see below we have now modified the Server information in the response header info.

JbossWS
JbossWS will leak the servers Bind Address by default if you do not modify the config. Basically when a webserivce is called the WSDL Endpoint will display ${jboss.bind.address} rather than the host and port of the original request.

Not only is this a problem for information leakage but will likely create problems for external users using this webservice.

Fixing this on Jboss-4.2.X is different than Jboss-5.X so please follow the instructions for your version.

JbossWS on Jboss-4.2.X

To fix this you will need to modify:
$JBOSS_HOME/server/$context/deploy/jbossws.sar/jbossws.beans/META-INF/jboss-beans.xml

Look for the below section in the file which is at the top, notice the comment just above it. I highlighted the property name we care about.

      <!--  If 'webServiceHost' is not set, JBossWS uses requesters protocol host when rewriting the <soap:address>.
    -->
    <property name="webServiceHost">${jboss.bind.address}</property>
    <property name="modifySOAPAddress">true</property>

In this version of jboss given the comment just above the property, the only way to fix this is to comment out that property altogether so that it looks like the below

      <!--  If 'webServiceHost' is not set, JBossWS uses requesters protocol host when rewriting the <soap:address>.
    -->
    <!-- <property name="webServiceHost">${jboss.bind.address}</property> -->
    <property name="modifySOAPAddress">true</property>

JbossWS on Jboss-5.X

To fix this you will need to modify:
$JBOSS_HOME/server/$context/deployers/jbossws.deployer/META-INF/jboss-beans.xml

Look for the below section in the file which is at the top, notice the comment just above it. I highlighted the property name we care about.

      <!--  If 'webServiceHost' is not set, JBossWS uses requesters protocol host when rewriting the <soap:address>.
    -->
    <property name="webServiceHost">${jboss.bind.address}</property>
    <property name="modifySOAPAddress">true</property>

In this version of jboss given the comment just above the property, the only way to fix this is to comment out that property altogether so that it looks like the below

      <!--  If 'webServiceHost' is not set, JBossWS uses requesters protocol host when rewriting the <soap:address>.
    -->
    <!-- <property name="webServiceHost">${jboss.bind.address}</property> -->
    <property name="modifySOAPAddress">true</property>

Upgraded JbossWS?

If you followed my earlier suggestion of upgrading this component to the latest (depends on your version ) than you can change

$JBOSS_HOME/server/$context/deployers/jbossws.deployer/META-INF/stack-agnostic-jboss-beans.xml

Locate the same section but notice the difference in the comment, now you can set the property to "jbossws.undefined.host"

      <!--   If 'webServiceHost' is set to 'jbossws.undefined.host', JBossWS uses requesters host when rewriting the <soap:address>
    -->
    <property name="webServiceHost">jbossws.undefined.host</property>
    <property name="modifySOAPAddress">true</property>

Restart Jboss and now you wont have to worry about inadvertently exposing your internal RFC 1918 address.

Although I have not yet spoken about protecting your consoles I thought it was worth a mention of another blog post I came across while writing this given it talks about information leakage. It discusses information leakage and how you can take what would be deemed a "low" on a vulnerability scan to owned.

The article is by Chris Gates "Carnal0wnage" he discuses how something as simple as a status page being exposed can be used against you. link http://carnal0wnage.attackresearch.com/2012/04/from-low-to-pwned-3-jbosstomcat-server.html

I will discuss later on how to restrict consoles by IP.

Custom Error Pages

The problem of not setting custom error pages is that the default ones generated by Jboss leak some information as per the below, which would undo all of the work done thus far.

example:

So are you can see in Jboss 4.2.2 the default version of JbossWeb is 2.0.1 so having the above would leak that we are utilizing a version of Jboss. We will set these server wide, but the caveat is that these pages will have to reside in the root of each web app.

To fix this change the following file
Jboss-4.2.X: $JBOSS_HOME/server/$context/deploy/jboss-web.deployer/conf/web.xml
Jboss-5.X.X: $JBOSS_HOME/server/$context/deployers/jbossweb.deployer/web.xml

go to the bottom of the page and add the below in yellow just before the "</web-app>" tag

  <error-page>
    <error-code>404</error-code>
    <location>/error/404.html</location>
  </error-page>
  <error-page>
    <error-code>401</error-code>
    <location>/error/401.jsp</location>
  </error-page>
  <error-page>
    <error-code>500</error-code>
    <location>/error/500.html</location>
  </error-page>

For the most part the composition of the file is up to you with the exception of the 401 error page. If you use basic-auth which we will later on the above will break authentication and you will not be able to access the consoles. To fix this you will need to add the below to your 401 error page, the below is an example for the web-console

<% response.setHeader("WWW-Authenticate", "BASIC realm=\"Web-Console\""); %>
<% response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); %>

Reference: http://stackoverflow.com/questions/1225853/avoiding-tomcat-status-report
The above has nicer examples if you scroll down to the last answer

The Favicon Icon
The last item on the list for information leakage (aside from any applications you have built) is to change or remove the favicon. I know it seems like such a minor thing but it will indicate that you are running Jboss.

your options are either to replace or delete them, this is up to you, I suggest you replace them with your own.

Location:
Jboss-4.2.X: $JBOSS_HOME/server/$context/deploy/jboss-web.deployer/ROOT.war/favicon.ico
Jboss-5.X.X: $JBOSS_HOME/server/$context/deploy/ROOT.war/favicon.ico


Securing the Consoles

Later I will discuss removing any un-necessary components or consoles from jboss, but for now I will show you how to secure these.

JMX-Console
The jmx-console is normally required for remote monitoring of Jboss and as such is important to the Operations teams.

Securing this console is also of utmost importance as this very same console has hooks into jboss and allows not only commands to be executed but execution of web apps and even deployment of web apps.

For example there are exploit modules in Metasploit , as well as a tool from Truswave SpiderLabs called Jboss AutoPwn that take advantage of this default setup of the jmx-console. A better explanation of the vulnerability can be found here CVE-2010-0738

I will attempt to show you the common mistake made in securing the jmx-console which normally entails securing only the POST and GET HTTP-METHODS

If you open up the below file (same location for both version)

$JBOSS_HOME/server/$context/deploy/jmx-console.war/WEB-INF/web.xml

Navigate to the bottom and you will see the "security-constraint" section commented out by default, it should look like the below.

   <!-- A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console.
   <security-constraint>
     <web-resource-collection>
       <web-resource-name>HtmlAdaptor</web-resource-name>
       <description>An example security config that only allows users with the
         role JBossAdmin to access the HTML JMX console web application
       </description>
       <url-pattern>/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
     </web-resource-collection>
     <auth-constraint>
       <role-name>JBossAdmin</role-name>
     </auth-constraint>
   </security-constraint>
  -->

In order to start securing the jmx-console you will need to un-comment the above section in your file, if you notice in the sections high-lighted in yellow this security constraint would only apply to those two HTTP-METHODS which still allows HEAD and others that can be used to exploit this console. Rather than list every METHOD, it would just be easier to remove both of those which would make this constraint apply to all. Your new config should look like the below

   <!-- A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console. -->
   <security-constraint>
     <web-resource-collection>
       <web-resource-name>HtmlAdaptor</web-resource-name>
       <description>An example security config that only allows users with the
         role JBossAdmin to access the HTML JMX console web application
       </description>
       <url-pattern>/*</url-pattern>
     </web-resource-collection>
     <auth-constraint>
       <role-name>JBossAdmin</role-name>
     </auth-constraint>
   </security-constraint>
  

Next you will have to actually setup the login-config file for this console such that it will force the login (by default this is already setup with the user: admin and pass: admin

For the most part by default all of the user and role files are located at the below location
$JBOSS_HOME/server/$context/conf/props/

The file we use to change the options for the console auth is

$JBOSS_HOME/server/$context/conf/login-config.xml

In this file you will see the template configurations for all of the components and consoles, for the moment we are concerned with the jmx-console which should look like the below

  <!-- A template configuration for the jmx-console web application. This
    defaults to the UsersRolesLoginModule the same as other and should be
    changed to a stronger authentication mechanism as required.
  -->
  <application-policy name="jmx-console">
    <authentication>
      <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
        flag="required">
        <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
        <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
      </login-module>
    </authentication>
  </application-policy>

If not change the section to look like the above and open up the
$JBOSS_HOME/server/$context/conf/props/jmx-console-users.properties

The file will have two lines, one of which has the default user and password so the format of this file is USERNAME=PASSWORD

# A sample users.properties file for use with the UsersRolesLoginModule
admin=admin

change the password to whatever you like, the longer the better

I.E admin=thisshouldbeareallylongandstrongpassword

no the above isn't considered a "secure" password but it is just an example be smart when selecting this (i will not discuss integrating this with an SSO service but it is possible)

save, restart and test your login, you should have now secured your jmx-console

Web-Console

Jboss-4.2.2

Securing this is similar to the above jmx-console with the exception that this console in Jboss-4.2.2 doesn't seem to respect the configuration within login-conf.xml so instead of walking you through that step I will tell you how to secure this console and potentially update this post later with my findings as to why it doesn't respect the configuration parameters (likely a bug)

as with the jmx-console you will need to un-comment the "security-constraint" section within the web-console's web.xml locate at

$JBOSS_HOME/server/$context/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml

within this file locate the below section

   <!-- A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console.
   <security-constraint>
   <web-resource-collection>
   <web-resource-name>HtmlAdaptor</web-resource-name>
   <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
   <url-pattern>/*</url-pattern>
   <http-method>GET</http-method>
   <http-method>POST</http-method>
   </web-resource-collection>
   <auth-constraint>
   <role-name>JBossAdmin</role-name>
   </auth-constraint>
   </security-constraint>
-->

un-comment and remove the two http-methods "POST" and "GET"

   <!-- A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console. -->
   <security-constraint>
   <web-resource-collection>
   <web-resource-name>HtmlAdaptor</web-resource-name>
   <description>An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application</description>
   <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
   <role-name>JBossAdmin</role-name>
   </auth-constraint>
   </security-constraint>

Removing un-necessary applications

Jboss has quite a few components that for both security and performance should be removed from the application server. To remove them all you really have to do is  either move them to a backup directory outside of the the application installation directory or just delete them.

For Jboss-5.X.X

• Management Console
• $JBOSS_HOME/server/$context/deploy/management
• JMX-Console (If not required)
• $JBOSS_HOME/server/$context/deploy/jmx-console.war
• Hot Deployment Scanner
• $JBOSS_HOME/server/$context/deploy/hdscanner-jboss-beans.xml
• Admin Console
• $JBOSS_HOME/server/$context/admin-console.war
• BeanShell Deployer
• $JBOSS_HOME/server/$context/deployers/bsh.deployer
• JbossWS (If not required)
• $JBOSS_HOME/server/$context/deployers/jbossws.deployer
• $JBOSS_HOME/server/$context/deploy/jbossws.sar

For Jboss-4.2.X

• Management Console
• $JBOSS_HOME/server/$context/deploy/management
• JMX-Console (If not required)
• $JBOSS_HOME/server/$context/deploy/jmx-console.war
• BeanShell Deployer
• $JBOSS_HOME/server/$context/deploy/bsh-deployer.xml
• JbossWS (if not required)
• $JBOSS_HOME/server/$context/deploy/jbossws.sar

Hot Deployment Scanner 4.2.X

In order to disable this you will have to set the "ScanEnabled" flag to false, I will show you how to do this below. 

Edit the $JBOSS_HOME/server/$context/conf/jboss-service.xml

search for "ScanEnabled" or go to line 654 (if it is the default file) if you take a look at the below it should look like that as the default configuration.

      <!--

      <attribute name="URLComparator">org.jboss.deployment.scanner.PrefixDeploymentSorter</attribute>
      -->

      <!-- The FilterInstance specifies a URLLister.URLFilter for scanned
           directories. This DeploymentFilter is initialized with the given
           prefixes, suffixes and matches that define which URLs should be
           ignored.
      -->
      <attribute name="FilterInstance"
         attributeClass="org.jboss.deployment.scanner.DeploymentFilter"
         serialDataType="javaBean">
         <!-- Files starting with theses strings are ignored -->
         <property name="prefixes">#,%,\,,.,_$</property>
         <!-- Files ending with theses strings are ignored -->
         <property name="suffixes">#,$,%,~,\,v,.BAK,.bak,.old,.orig,.tmp,.rej,.sh</property>
         <!-- Files matching with theses strings are ignored -->
         <property name="matches">.make.state,.nse_depinfo,CVS,CVS.admin,RCS,RCSLOG,SCCS,TAGS,core,tags</property>
      </attribute>

      <!-- Frequency in milliseconds to rescan the URLs for changes -->
      <attribute name="ScanPeriod">5000</attribute>

      <!-- A flag to disable the scans -->
      <attribute name="ScanEnabled">true</attribute>

Change the above to false and this should only scan the deploy directory on startup

Encrypting Your Data Source Passwords

Here is a simplistic way to encrypt the password it isn't the best practice way which I will add to an edit to this blog post or as another post at a later date. This utilizes a hardcoded password within the "SecureIdentityLoginModule" this is just better than using the default clear text password that is normally contained. This module uses the blowfish cipher along with a derived key, again not the best solution but is recommended by Jboss. I will explain later what the issue is with this solution

First edit your Data Source file, I will use my test mssql-ds.xml as an example

<?xml version="1.0" encoding="UTF-8"?>

<datasources>
        <local-tx-datasource>
                <jndi-name>MyDefaultDS</jndi-name>
                <connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=blah;charset=UTF-8</connection-url>
                <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
                <user-name>user</user-name>
                <password>strongpassword</password>
                <check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
                <metadata>
                        <type-mapping>MS SQLSERVER2000</type-mapping>
                </metadata>
                </local-tx-datasource>
</datasources>

Delete the user-name and password lines highlighted in yellow and add in the line below highlighted in yellow below.

<?xml version="1.0" encoding="UTF-8"?>

<datasources>
        <local-tx-datasource>
                <jndi-name>MyDefaultDS</jndi-name>
                <connection-url>jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=blah;charset=UTF-8</connection-url>
                <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
                <security-domain>EncryptedDBPassword</security-domain>
                <check-valid-connection-sql>SELECT 1</check-valid-connection-sql>
                <metadata>
                        <type-mapping>MS SQLSERVER2000</type-mapping>
                </metadata>
                </local-tx-datasource>
</datasources>

Next you will need to add the "EncryptedDBPassword" security-domain to the login-config.xml
Note: the naming of the security-domain does not have to be "EncryptedDBPassword" it just has to be unique and match what is contained within the Data Source and login-config.xml files.

Edit: $JBOSS_HOME/server/$context/conf/login-config.xml

Add in the below section at the bottom just before the "</policy>" tag

    <application-policy name="EncryptDBPassword">
        <authentication>
            <login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">
                <module-option name="username">user</module-option>
                <module-option name="password">11a2423091bbb7fda922a0652759a259</module-option>
                <module-option name="managedConnectionFactoryName">jboss.jca:name=MyDefaultDS,service=LocalTxCM</module-option>
            </login-module>
        </authentication>
    </application-policy>

The "managedConnectionFactoryName" MUST match that of your data source file if not you will have AUTH failures I highlighted the line in yellow . Also you must create an Application Policy for EACH Data Source Entry.. so if you have two Data Source entries in one file you still need two application policies, on for each Data Source.

reference: http://www.coderanch.com/t/455897/JBoss/make-data-source-connection-without

In order to generate the encrypted & base64 encoded password, you will need to run the below command from the $JBOSS_HOME directory. The command is different for Jboss-4.2 and Jboss-5.X java must be in your path in order for this to work obviously replace the password with your own which is highlighted in yellow

Jboss-4.2.X Command:

[root@app jboss-4.2.2.GA]# java -cp lib/jboss-common.jar:lib/jboss-jmx.jar:server/default/lib/jbosssx.jar:server/default/lib/jboss-jca.jar org.jboss.resource.security.SecureIdentityLoginModule strongpassword

Jboss-5.1.X Command

[root@app jboss-5.1.0.GA]# java -cp client/jboss-logging-spi.jar:common/lib/jbosssx.jar org.jboss.resource.security.SecureIdentityLoginModule strongpassword

The output you should receive is below

Encoded password: 11a2423091bbb7fda922a0652759a259

Take the output of the above and place that in the login-config.xml file in the password section of your application policy or security-domain

For troubleshooting and more information please use the below reference link which is where the information I posted above came from.

Reference:  https://community.jboss.org/wiki/EncryptingDataSourcePasswords

Issues with the above:

The problem with the :SecureIdentityLoginModule" is that it uses Blowfish with a Key derived from the Phrase "jaas is the way" In other words it's fairly easy to decrypt using the same tools . There is also a github repo out there that contains a tool to do decrypt this so for those pentesters that come across this in your engagements.

Use at your own risk: https://raw.github.com/usefulfor/usefulfor/master/security/JBoss.java

Reference Site: http://usefulfor.com/security/2009/09/24/beware-of-jboss-secureidentityloginmodule/

I do find it funny that everyone complains or finds ways to break the solutions but never provides a better solution or mitigation strategy, so I will try to help with that. Also please note that that above is Recommended by Jboss even though it has this known flaw.


I will end Part 1 here as I could continue on quite a bit more, but I promised a few people I would get this out a week or two ago.

In Part 2 I plan to cover the following:

• Forcing SSL/TLS on your database connections (MSSQL, ORACLE, MYSQL)
• Encrypting your user.properties passwords
• Fixing the issues with the Jboss recommended "Encrypt your Data Source Passwords"

Tweet