BugBounty

von Patrik auf Allgemein

[BugBounty] Decoding a $😱,000.00 htpasswd bounty

tldr;

A Private Bug Bounty Program had a globally readable .htpasswd file. I cracked the DES hash, got access to development and staging environments and was rewarded a shitload of$.

[Tools used]

dirbuster https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project

John http://www.openwall.com/john/

[\Tools used]

Today I want to share something with you that I recently discovered in a private Bug Bounty Program. Due to private program restrictions, I am not allowed to disclose the identifying details of the bug, so I’m just going to share my techniques and how I discovered it.

So, as a first step, I looked for potential vulnerable subdomains using a Google Dork query: site:*.REDACTED.com -www and then looked for interesting stuff. One particular domain caught my attention and so I had a look at it, admin.REDACTED.com. Upon review, the site looked pretty unspectacular and so I decided to use the tool „dirbuster“ to look for the juicy stuff. I was about to give up when I saw the tool discovered a .htpasswd file with an HTTP status 200. With a bit of excitement, I visited the URL and was pretty surprised to the file rendered.

Ohne Titel

 

So what exactly is this? As some of you may know, several webservers offer a mechanism called Basic Authentication. While I now knew the username was us3r, the password was still encrypted… Now, in similar cases, I’ve seen passwords simply being Base64 encoded but here, the encryption didn’t look like anything I was familiar with. After some Googling, I realized it was DES (Data Encryption Standard).. Based on what I read, while DES is now considered insecure and susceptible to theoretical attacks (thanks Wikipedia), there are no trivial methods known for DES cracking. So instead, I used a simple password cracking tool called john with the help of @nijagaw Nico who pointed me to a nice wordlist (Link) to crack it.

Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])

After some time i finally had the encrypted password.

john --wordlist=/Users/Patrik/Downloads/crackstation.txt pw           

Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])

Press 'q' or Ctrl-C to abort, almost any other key for status

0g 0:00:00:04 5% 0g/s 3316Kp/s 3316Kc/s 3316KC/s 09554858..09554972

0g 0:00:00:27 52% 0g/s 2953Kp/s 2953Kc/s 2953KC/s 42333281..42333395

0g 0:00:00:28 54% 0g/s 2971Kp/s 2971Kc/s 2971KC/s 45154098..45154206

0g 0:00:01:56 35% 0g/s 3055Kp/s 3055Kc/s 3055KC/s CFCbu..CF(CC

sasi21033******        (?)

Use the "--show" option to display all of the cracked passwords reliably

Session completed

But what now? The website itself didn’t use any kind of .htaccess and, admittedly, I was a bit lost. However, thanks to the awesome @mongobug, I was able to figure out that each of the following was using Basic Authentication:

  • thestageingstuff.*.domain.com
  • developmentworkshere.*.domain.com
  • quark.*.domain.com
  • devsfavourite.*.domain.com

Additionally, the fun thing was the Username and Password I discovered worked on each and every one of them. In other words,I had access to the company’s development / beta environments.

The next step? Report it to the program owner who responded quickly, and resolved the issue even quicker. Kudos to them.

End of the story 🙂

rawraw (1)

 
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 Bug Bounty

[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.

"--></style></ script >< script > alert ("XSS  ")</ script >

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

 
von Patrik auf Bug Bounty

[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.

"><img src=x onerror javascript=alert(1337)">.jpg

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

https://www.paypal.com/webapps/merchantboarding/webflow/unifiedflow?execution=e1s1

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 🙂