Thursday, January 11, 2018

Signing Requests to AWS on OWASP Zed Attack Proxy - ZAP

Hello All,

I've written a Help Add On Script for the OWASP Zed Attack Proxy to sign requests to Amazon AWS. You can check it here. Enjoy it!

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

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:

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 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:{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 to the new application folder (teste.war):{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/  

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

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.


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.