[BugBounty] Sleeping stored Google XSS Awakens a $5000 Bounty

Dear Readers,

Today I want to share a short write-up about a stored cross-site scripting (XSS) issue I found on the Google Cloud Console. I consider it a lucky find. Some of you may remember the tweet I sent to  Frans Rosén  after he discovered a vulnerability on Google Payments:

Screenshot 2016-05-16 at 21:41:38

As it turned out, among the unsuccessful XSS payloads I saved on my Google account, there was one that actually fired. But unexpectedly. When I was originally testing my payloads, I never managed to trigger the execution until recently and inadvertently. But let’s start from the beginning.

As you may know, Google is offering a 60 day  free trial  with a budget of $300 and all that is required is entering (correct) payment information to prove you are not a robot. So, I did that a few weeks ago and started entering XSS payloads in every field I could find … and nothing fired, I failed. A situation I assume we’ve all been in, right? Well, after two months or so, I received an invoice from Google and a notification that my free trial what ending. Wanting to avoid the charges, I quickly logged into my account and deleted my project, which was titled „> <img src = x onerror = javascript: alert (1); … and boom, my payload got Executed!

Screenshot 2016-05-04 at 13:41:51

As it turned out, Google was not filtering the error message once a project which canceled. Astute readers may question why this was not classified as a low level self XSS. This issue was escalated because the Google Cloud Platform can be used by multiple users; if a user creates a project with a malicious XSS payload, that payload could be used against the project administrator to execute malicious javascript (if they delete the project, which seems likely).

For those unfamiliar, and the knowledge hungry, here’s how the payload gets reflected in the content of the site: the first quote and angle bracket, „>“ close the preceding HTML tag which allowed my injected <script> tag to be rendered in the page source. For this POC, I simply used the img src = x payload. Since x is not a valid url, this is designed to fail immediately with a 404 HTTP response, which will then invoke the onerror event to execute a javascript function. However, thanks to @Jobert from HackerOne for noting, that it’s possible this could have returned a 2xx or 3xx redirecting to a 2xx in which case my payload would not have fired. In my testing, I just added the function alert to create a popup but malicious users could have used a cookie stealer  or the Browser Exploitation Framework Project (BEEF) to escalate this issue (I did not have to tell Google did though).

Screenshot 2016-05-04 at 14:06:56

Here’s the video POC I sent in for the Google VRP:


That’s it 🙂

 

Screenshot 2016-05-16 at 21:51:54

raw

 

Thanks to Peter  @yaworsk for editing :-)! Follow him and support him by buying his book ! For more technical writeups have a look at ERNW’s  Insinuator  blog, I blog there now and then about Mobile Security and IPv6.

If you have any questions please feel free to contact me at patrik.fehrenbach (at) it-securityguard.com

 

[BugBounty] Reflected Cross Site Scripting BillMeLater

Dear followers,

i recently found a reflected Cross Site Scripting issue on a Subdomain of BillMeLater (Paypal acquisition) it was possible to break the style attribute and add malicious Javascript Code into the Application.

When ending the previous style and script element it was possible to add a new script element and executing the Payload, the complete URL looks like this now :

http://wwwb.search.billmelater.com/coupons/store/guess/?u=%27%22–%3E%3C/style%3E%3C/%20script%20%3E%3C%20script%20%3E%20alert%20%28%22XSS%20%20%22%29%3C/%20script%20%3E

thefindt

This one only worked in Firefox, Chrome and IE restricted the execution with the anti XSS feature.

The Bug was categorized as „Out of Scope“ for whatever reason.

Hope you enjoyed, if you have any question left, please don’t hesitate to contact me at patrik.fehrenbach(at)it-securityguard.com

 

[BugBounty] Paypal stored XSS + Security bypass

Dear followers,

i recently discovered a stored cross site scripting vulnerability on Paypal’s core site. The scenario is a bit weird, but i hope to explain everything as good as possible.

During my testings i often create accounts with malicious Javascript contet as the Name, Organization etc etc. While testing on Paypal i did the same, i tried to make an account with the username.

But when i tried to fullfill the registration the security module of Paypal showed me an error that there is some kind problem with my request. When i looked at the URL i saw that there was some kind of progress bar

What came first in my mind , it’s the same url you get once logged in into a legimitate accout, so i tried to erease everything after the /webapps/ url, and suddenly i was into my new Paypal account with the malicious Javascript content. I went to the profile settings page and saw that 3 of my javascript snippets were executed. So far so good. Some of you might know that you need a szenario in which users of Paypal could be exploited in order to recieve a bug bounty. So i thought about where i could inject this to other Paypal users. A few months ago i found also a stored cross site scripting issue within a invoice created by paypal. If you look at the landing page of paypal you will see that every invoice you recieve will include the name of the user that send it to you. So, my Username is malicious Javascript, and Paypal allows me to send invoices to every single Paypal user by just knowing their E-Mail. So i went further and created an invoice, and sent it to my second Paypal accout. I logged in to the second one, and the Javascript Prompt appears on my screen.

To summarize the progress :

1. Create an account with the malicious Payload

2. At the point where the Paypal systems stops you from continuing erease the URL till /webapps/ (bypassed the Security restriction)

3. Create an invoice, send it to the victim

4. Victim logs into the the Account and the Payload gets executed

I did a small POC Video which describes the impact :

I hope you enjoyed 🙂

 

[BugBounty] The 5000$ Google XSS

Dear followers,

i recently searched for vulnerabilities on a Google service called tagmanager, this service is used for SEO operations. My main research was to look for any field that could be vulnerable to Cross Site Scripting, but every field was protected against special characters as you can see in the image below. So pretty useless to search on further on this.
mac

So the next thing i saw was that the Tagmanager allowed a user to upload a set of definitions, tags, and Macros in form of a JSON File. json

What i did next was to download the sample JSON file and edited the Name fields of the macros (which were not allowed special characters)

And guess what ? After uploading and overwriting the settings, the Payload got executed.

Here’s the POC Video i sent in

 

Hope you enjoyed! 🙂

10721113_572544522871857_964844342_n

all the best

Patrik