von Patrik auf Allgemein

[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

 
von Patrik auf Allgemein

Geschützt: Digging into the Shopify POS Firmware (Part 1)

Dieser Inhalt ist passwortgeschützt. Um ihn anschauen zu können, bitte das Passwort eingeben:

 
von Patrik auf Allgemein

[Research] – Stop OSX Spotlight from sending your location

Hey dear readers it’s been awhile,

tldr; How to avoid apple from yelling out your location to their servers

Bildschirmfoto 2015-06-15 um 00.51.23

I personally like to use the Searchlight function of OSX, it provides me a fast way to access my files – but this it also sends my geolocation to apple everytime i do a search. This blogpost will be about how to disable or at least prevent the built-in search function “Searchlight” from sending your IP-location to the Apple Servers.

But first have a look at what’s being sent:
GET /search?q=asd&latlng=48.082000,8.640000&geosrc=wifi,155.643824&storefront=143443-4,13&locale=de-DE&time_zone=Europe/Berlin&calendar=gregorian&key=montana4289 HTTP/1.1
Host: api.smoot.apple.com

This request was captured during a Burp session.

What you can see here in the Parameters

  • q is the Query you send to the the Apple Servers
  • latlng is the Latitude and the Longitude of your current (IP) location

I think it’s needless to say that those information should stay private (at least in my opinion). If you want to keep your searches fancy you can stop reading here, preventing the geolocation will change your search experience but you will gain some privacy back 🙂

How To: 

So the first way – Old School /etc/hosts

The /etc/hosts is a local text file that tells the system how to resolve an IP-Address to a Domain. The clue here is to point the Apple domain api.smoot.apple.com to the localhost address of your machine (127.0.0.1) this will tell the system to resolve every request to api.smoot.apple.com to the localhost address, thus leading nowhere. To do so:

1. Open a terminal
2. sudo vim /etc/hosts
3. Enter the following 127.0.0.1 line api.smoot.apple.com
4. Clean the DNS cache sudo discoveryutil mdnsflushcache
5. All set 🙂

Bildschirmfoto 2015-06-15 um 00.58.39

Second Way – Little Snitch

I don’t want to promote anything here, but the Little Snitch software is worth buying. Little snitch helps you to organize every incoming and outgoing connection, you can simply add a rule for the Spotlight search:

You want to disable the locationd Service that tries to connect to gs-loc.apple.com – forever  Bildschirmfoto 2015-06-15 um 01.17.29

you are done 🙂 Privacy saved.

If you enjoy this – give me a feedback as a comment here or drop me an email at patrik.fehrenbach(at)it-securityguard.com if you guys are interested i might do a complete writeup about an OSX hardening.

 
von Patrik auf Bug Bounty

[BugBounty] Papyal XML Upload Cross Site Scripting Vulnerability

Greetings readers, today i want to share with you one of my latest findings on Paypal.com.When creating an invoice Paypal allows the users to upload attachements for the invoices one attachement that they allow is a XML file. What the developer may missed here is that you can actually insert HTML into XML files, the namespace allowing this for XML files is called xmlns and a valid xmlns file would look something like this :

<html>
<head></head>
<body>
<something:script xmlns:something="http://www.w3.org/1999/xhtml">alert(1)</something:script>
</body>
</html>

When i uploaded a file with this content and the ending.xml the intepreter on Paypals site executed the Payload (in this case the alert 1). To fullfill the requirements for a bounty you always have to make such a vulnerability exploitable and therefore a risk for other Paypal Users. In this case it was pretty easy, you could either way send the Link to this file directly (it doesn’t matter wether the user is logged in or not) or you send it with the Invoice and wait for the user to klick on it.

Here is the POC i sent in to the Paypal bug bounty team :

If you have have questions on this particular case please don’t hesitate to contact me at patrik.fehrenbach(at)it-securityguard.com

All the best

Patrik