Don't ask me to do a darn thing, I'm RED HATTING
Sometimes in life, we hear facts, facts that shock us. These facts can be along the lines of "Did you know all the plastic ever manufactured is still on the planet?" Shocking isn't it. Another fact that seems to shock even the most tech-savvy, is that there are on average 84,500 attempted cyber-attacks per day on small businesses within the UK (Hiscox, Hiscox), The average mean cost of a cyber security breach for a small business in 2019 was £11,000 (Official Gov.uk Cyber Security Breaches Survey 2019).
Now that is shocking. However, most breaches are minor and do not cause much damage or inconvenience but what happens when the breach is not so small and could cause the company lots of damage? What if these breaches reveal personal information about consumers and their orders?
Let's look at a couple examples
A couple more to jog your memory, remember the infamous Cambridge Analytica scandal? this compromised the data of 87 million users.
How about a recent settlement, The Information Commissioner’s Office has fined Ticketmaster UK Limited £1.25million for failing to keep its customers’ personal data secure.
Ok, enough with the stats!
An imminent breach was discovered by me and this is how it happened.
Before we move on please see /disclaimer/
It all started on a sunny day shortly after I received the e-mail pictured below, I assumed this was due to have just enrolled RedHat Academy as a requirement for one of my modules at University.
As we can see nothing bad in here, thanks for being chosen for this RedHat!
Opening the underlined hyperlink takes me to a training portal, it does it's authentication through their SSO (Single Sign-On).
I log in with my RedHat account and browse about the website, the portal can be seen below.
Nothing out the ordinary here, I was purely just looking to see what's in it for me.
I head to my profile and find a section where it showed me the e-mail I had just received.
This is what caught my attention. This is just a coincidence o_O
You know what I'm thinking right? Allowed to see the source code, resend button.. hmm! Bug Hunter mode ON! But wait wait wait, Do they have a policy?
- I had no vulnerability found at this stage but I needed to know that I am allowed to proceed.
Turns out RedHat does have a Vulnerability Disclosure Program, but not a Bug bounty program [..] a quick google searched and found a link on HackerOne.
At this stage, it was apparent to me that if I decided to go ahead and try to find something I was not going to get any monetary rewards. I'm cool with that as I previously mentioned in my other articles, I'm in for the learning experience and if I can add any value, why not.
Coming back to the source code of the e-mail, by allowing anyone to see this, makes it so much easier to grab the HTML code and use it for spear phishing attacks, Then I wondered, what is the purpose of this resend button?
Time to summon the interceptor God, I'm talking about Burp Suite! Big congrats to Portswigger Team for building such a fantastic application security testing software.
So at this stage, I just want to see what the requests look like, what parameters there are when I interact with the portal, what happens when I click resend etc.
My initial attack vector was just simply to see if I can edit the source code, place my own website as the hyperlink and resend it to myself. If I could do that successfully then I build from there onwards.
I spent some time trying to achieve this but I couldn't, I tried to blame it on my inexperience however based on what I could see within the requests I started to realize that the template of the e-mail is loaded from within the app and I cannot modify these templates or add my own.
Ok dammit.. nothing yet.. Time to enumerate more!
A couple interesting parameters I noticed were sessionId="abc1234" and emaId="1234" (examples)
So what really happens if I capture a request when I ask the application to show me the contents of my email (with my own emailId) but then I change that value to see if I can access other email's correspondence.
Yep, we're talking about an IDOR (Insecure direct object references).
What is an IDOR vulnerability?
There can be many variables in the application such as "id", "pid", "uid" etc. Although these values are often seen as HTTP parameters, they can be found in headers and cookies. The attacker can access, edit or delete any of other users’ objects by changing the values. This vulnerability is called IDOR.
First, it needs to understand the application flow developed by software developers. All the modules functions and their sub-modules functions need to be understood when the logged-in user into the web/mobile application. It is also important to remember that this vulnerability is as severe as XSS, CSRF in security testing and as a type of vulnerability that is not easily discovered (automatized testing or manual testing).
The IDOR vulnerability is illustrated in the following image between user and server.
Okay, changed the values, sent the request... I get this:
Wow.. so now I see this customers email and can download their attachments, checking the source code of that email reveals no private information about this customer besides their full name.
Each customer had an inbox so every time I would pick a different emailId, I'd get a different inbox, so I played around with this for a while, trying to increase severity of this bug, the contents were all similar, some were revealing significantly more information (payment related).
Moving on, what else is possible to access besides these emails.
I noticed the tab "My Orders" so I clicked there.
Of course, I didn't have any orders, so trying to search for product names like "red hat certification" or some unknown order number revealed no entries found.
I decided to capture a blank request on the Search button to see what parameters are there.
So we can see in_param2=" ", playing with this value, with my first try I managed to find a result.
Perfect! Now capturing the next request will give me a better idea of how this request looks when opening the order tab.
Ok as you can see this allows me to see this particular customer whose order I found playing with the in_param2 value. I can Print Order, View Transaction Details, Cancel/Refund Order, Change billing address, View Full Details.
I decided straight from the beginning I will not try the Cancel/Refund order function but I did try "changing the billing address".
As seen below, I was able to add a new billing address and set it as default. I noticed I wasn't able to remove this address so I left notes for RedHat if they wanted to fix it themselves (I have restored the default billing address).
I tried to find other customer's orders without changing any details to their billing and as expected, I was able to find more customers. The purpose of this was to show RedHat that I can see more than just one customer's details.
I stopped there, one can assume that if this function worked then I could cancel/refund the order as well.
I got in touch with RedHat Security Team, sent them a detailed report with a step by step procedure to reproduce all the above, and I recorded those in a Proof of Concept video just to make it easier for them to identify exactly where and how I found these issues.
[sending null payloads...]
I know my article has many screenshots and a few are obfuscated for obvious reasons. I would love to add the proof of concept video but I agreed with RedHat not to disclose personally identifiable information about their customer base.
Have you got any suggestions or questions for me ? Get in touch!
Thank you for reading my article, Until next time!
Your friendly neighbourhood Hacker.