[Writeup] How i bypassed XFrame options protection at Google Books

Hi There,

This is an long delayed writeup, i had reported this vulnerability around the month of march this year, but didn't realized that the bug was fixed until now.

Let's get started,

Abstract:

Google Books has implemented X-Frame-Options header for protection against ClickJacking attack.
I was able to bypass this protection and clickjack Google Books Dashboard.

Background:

So on one good evening when i was checking out some books on Google i came across this preview page which for some strange reason looked vulnerable to me and i started testing it out.

 While testing the webpage i found that Google allows it's books to be embedded into another webpage by using an embed code.

This is an example embed code  

<iframe frameborder="0" scrolling="no" style="border:0px" src="https://books.google.co.in/books?id=YJKbVzeabJYC&lpg=PP1&dq=web%20application%20hackers&pg=PP1&output=embed" width=500 height=500></iframe>

 By reading the code one could easily tell that the X-Frame-Options header protection will be turned off for the IFrame Source URL to make it framable on another webpage.

The HTTP response headers of the embed code is.

By comparing the framable URL with the original Google eBook URL, I found an interesting parameter output=embed

Original webpage URL 
https://books.google.co.in/books?id=YJKbVzeabJYC&printsec=frontcover&dq=web+application+hackers&hl=en&sa=X&redir_esc=y#v=onepage&q&f=false

 Framable URL
 https://books.google.co.in/books?id=YJKbVzeabJYC&lpg=PP1&dq=web%20application%20hackers&pg=PP1&output=embed

Using this parameter Google was removing X-Frame-Options and making a book framable.

Now the question is will this parameter remove X-Frame-Options from any other webpage and make it framable?

Answer: Yes

HTTP Response of Google books Dashboard

HTTP Response of Google books Dashboard with output=embed parameter

Impact: Just by making 2 clicks on Proof-of-Concept webpage all books from your bookshelf could be deleted.

Reward: $500

Thanks for Reading :)

Read More

[Writeup] How i prevented a bank from getting robbed

This story is about a loophole in an Online Banking website which could have allowed an attacker to steal funds from any customer account. After discovering this issue i immediately got in touch with the bank's security team and coordinated till a patched for this loophole was released. In this writeup i can't share the exact technical details about how i exploited the issue on the target website but i can give you a generalized idea of what went wrong and how it could have been exploited. 

Abstract: 
There was a bug in the forget password module of a netbanking website by exploiting which an attacker could have updated any customer's netbanking account password to his desired value.

To understand the exploit, we first need to understand how password recovery works on the target bank's website.

Here is normal flow of password recovery process which can be initiated by visiting the forget password page:

To recover a forgotten password on the netbanking website a customer has to follow this following process:

Step 1: Identify account using customer id.
Step 2: Submit an OTP( One Time Password) which will be sent via SMS & Email.
Step 3: Set a new password.

After following this process customer's password will be updated.

During my research, I found out that the webpage at "Step 3" was not validating if the customer has completed "Step 2" (OTP Verification).

The Exploit:

To exploit this issue and attacker has to complete "Step 1" -> Generate a Session ID -> Submit this Session ID to "Step 3" endpoint along with the new password which wants to be set for the account.

After making the post request the customer's netbanking password will be updated. Since the customer ID's on the netbanking website were numerical an attacker could have made an script that will reset every netbanking account's password and transfer funds out of it. 

At the end of the day this incident was a good test of my hacker ethics and taught me lessons which i will carry on throught my life. 

Thanks for reading & hack for good :)

Read More

[Vulnerability Report] Persistent XSS at Jotform

Persistent XSS @ Developers section

Vulnerable Service: https://developers.jotform.com

Description: The service mentioned above is vulnerable to Persistent XSS, due to which an attacker is able to steal user cookies which may lead to account hijacking.

Demo XSS thread:
https://developers.jotform.com/forum/post/<Removed>
- Click on "For Testing Purposes" to see the alert message.

Payload: javascript:alert('I_Am_Vulnerable_To_XSS');

Steps of Reproduction:
-Create a new thread & in thread editor click "Add hyperlink" button.
-Now instead of URL, paste payload there.
-"http://" will be automatically added to the payload, you need to remove that.

Proof of Concept:

Bounty:

Read More