Wednesday, 14 September 2011

Hijacking 2 clicks in Google Accounts

This vulnerability was the same as my previous post but more challenging in terms of exploitation. In this, attacker needs to hijack 2 user clicks to complete the desired action.

It starts with Google Products page where you can remove listed service from Google Accounts.

Once user decided to remove any service, for ex. Google Health, the user is presented with following page.

To remove service, user first needs to click the checkbox. After this only the “Remove Google Health” button will be active which when clicked will remove respective service from Google Account.

To exploit this, I used “Fake Captcha” technique which will successfully hijack required 2 clicks and will remove targeted service.  Here is how the attack page looks like.

This page has an invisible iframe which renders remove service page from Google Accounts. The correct answer, in this case ‘30’, is placed over the checkbox from vulnerable page & ‘Submit Answer’ on ‘Remove Google Health’ button.

When an authenticated user clicks on right answer for the provided arithmetic operation, he/she actually clicking the checkbox which enables “Remove Google Health” button.

Now he/she need to complete the process by submitting the answer. Once clicked on “Submit Answer” button, the targeted service will be removed from his/her Google Accounts.

Remove Google Heath, Remove Google Web History and Remove Orkut were vulnerable to this attack.

Google was very quick to patch this vulnerability.

Hope you enjoyed reading this. Suggestions, comments are welcome.

Tuesday, 13 September 2011

Remove Google Books with Clickjacking

Google Accounts has options to remove Google Products. One of them was to remove Google Books permanently.

This action was well protected for CSRF using tokens. However it was possible to render this page in an iframe due to absence of clickjacking protections such as Frame Bursting Code or X-FRAME-OPTIONS header.

To carry a successful clickjacking attack, an attacker needs to place a dummy button on top of “OK” button from vulnerable page.

The page presented to victim looks like this.

When an authenticated user browses to the above page hosted on attacker site, the invisible iframe will be loaded with remove Google Books page having proper anti-CSRF tokens in place. When user clicks on “Click” button, he/she actually clicks on “OK” button on vulnerable page and all the reviews, ratings and libraries of that user will be deleted.

This attack needs only one click and works like CSRF.

Edit: Here is the demo code used for this exploit:


#victim {
opacity: 0;
position: absolute;
top: -640px;
left: -55px;
overflow: hidden;
height: 700px;
<button type="button" class="dummy">Click</button>
<div id=victim>
<iframe src="" border=0 scrolling=no width=350 height=900></iframe>

I would like to thanks Google to choosing this bug for reward.

Monday, 12 September 2011

Using sqlmap for testing HTTPS sites

Update: By default, sqlmap supports SSL. Somehow it didn't worked for my friend. So I tried with --proxy option to find alternate way.

Last week, one of my friends asked me how to use sqlmap against HTTPS sites? I never tried that one but was sure that there will be a way to do it. I quickly checked sqlmap documentation and came across --proxy switch.

Somehow my friend didn't managed to work sqlmap with --proxy switch, So i decided to try it out myself.

The first thing i did was to read sqlmap documentation about --proxy switch.

It's pretty straight to use --proxy switch. It just need to provide proxy details as http://<proxy IP>:<port>. I used burp to test this.

The target site was running on It has a search page which was vulnerable to SQL Injection and that page has used POST method.

To run sqlmap, i used following command:
./ -u "" --data "word=test" --proxy ""

where -u is target URL, --data is POST data and --proxy is burp proxy details.

Lets' run it.

It works and sqlmap detected the back-end database as MySQL 5.0.

Hope you will find this useful.