Intro:

It has been a while since my last blog post, and here we go again. This one will cover a vulnerability I discovered and reported back in April to a private program in HackerOne which I cannot disclose the name, but it is a well known insurance company in the USA.

In short I have not set and prepare for this finding as I am so busy recently with my full time job, nevertheless I spend some of my spare time on my hobby, including research.

Recon phase

As understood above, no time for manual inspection and recon, one online tool I have used before was to subscibe that program domain to Facebook CT (Certificate Transparency), so whenever any new subdomain or new relevant SSL certificate for the app is issued we got Facebook notification, but sometimes this is so noisy and annoying, as you’ll turn your fb full of notifications in a short of time which I sometimes cannot deal with.

Certificate Transparencyis an open framework which helps log, audit and monitor publicly-trusted TLS certificates on the Internet. This tool lets you search for certificates issued for a given domain and subscribe to notifications from Facebook regarding new certificates and potential phishing attacks.

That day, I opened my phone, then my fb notifications, and noticed one potential term producer as part of the subdomain, the subdomain wasn’t new at all but it was the first time I gave it attention as I rarely hack on private programs :(, as by that time I was tinkering on some of the pub/sub strategies for distributing messages, think of Redis, NSQ… I was going on a whole rabbit hole on the distributed systems things but essentially learned a lot. Anyway, the publisher host is sometimes also called producer, and the subscriber is called consumer. This whole definition by itself was enough to bring that host into my attention, let’s call it: producer-something.redacted.com

Manual inspection and exploitation

I opened the host on my phone browser, and it redirects me to another subdomain which is the company’s Oauth endpoint, this makes sense since the subdomain seems to host something sensitive.

This time I tried to open the subdomain on my laptop’s browser, and I’ve noticed the same behavior, the 1st thing I did after was to simply open it in source code view, say: view-source:host while preventing any redirect.

the source code contains a javascript function that was something similar to this:

<script>
			if( window.location.href.indexOf("#access_token")>-1 || window.location.href.indexOf("#code")>-1 || window.location.href.indexOf("#id_token")>-1 ) {	
				window.location.replace( $actual_link );
			} else {
				var url = "https://producer-something.redacted.com";
				url = url + '/?option=oauthredirect&app_name=' + "auth0" + '&redirect_url=' + "https%3A%2F%2Fproducer-something.redacted.com%2Fother-sensitive-content" + '&restrictredirect=true';
				window.location.replace( url );
			}
</script>
  • As can be understood from the above code, there was a validation step before redirecting to the Oauth endpoint.
  • The condition was only checking if the href attributes contains literally one of the three #access_token, #code and #id_token.

To test if we can bypass this client-side validation, I simply validated the condition by requesting: https://producer-something.redacted.com/{one-of-the-three-validation-words-above}, this was indeed enough as a bypass, and the content of the host was shown without any issues containing the sensitive data as simple as it sounds.

It was also possible to bypass the validation by simply deactivating the Javascript through the DevTool, or by using a plugin called quick javascript switcher

But this isn’t practical as all the page contents depend on javascript, so switching off js would actually bypass the restriction but would render nothing.

And later on I found that any resource can be unlocked using the above keywords, like for instance, requesting wp-login.php would redirect to the Oauth first, but appending one of the three keywords wouldn’t, wp-login.php#code for instance.

Bug history and a disclosed report use-case

This is a well known vulnerability, and could be found in the wild, say for example a restricted areas where a huge content size was issued instead of few lines rendering a default 404 page, so always stop by and do some manual code source. This is not always JS related, other languages are vulnerable as well.

A good resource for this is the OWASP-EAR and mainly the research Fear the EAR.

There is a great disclosed report by my friend El Mahdi on this (https://hackerone.com/reports/683957) and was awarded $4k, as a full post-exploitation impact was assessed, and the root underlying cause was a simple yet powerfull EAR bug, shoutout to Mahdi for the disclosure.

Lesson learned and notes

  • Passively monitor assets for new CT is a good habit.
  • Read source code.
  • Observe application changes.
  • Take action, and participate on Private programs :).

Responsible disclosure timeline

  • Bug sumbitted through HackerOne: Apr 25th.
  • Triaged by the program internal team: Apr 25th (same day, :).
  • Bounty rewarded three days later: Apr 28th.