We are all familiar with the old “I’ve got a Mac book – viruses and hackers can’t get me!” myth, because it is “oh-so-true” that if you’re running anything Apple, security doesn’t apply to you… What’s that? GDPR? ISO 27001? … I have a Mac!
Unfortunately, yet another myth seems to be catching on. MFA. Why oh why we don’t learn from history, and then wonder why history ends up repeating itself? There is no silver bullet to protecting ourselves. Yes, there are heavy precautions we can take to decrease risk and mitigate impact, but this does not remove risk entirely.
Multi-Factor Authentication is undoubtedly a great tool. I like it because I can get away with smaller passwords and tap a push notification and I’m in! Much nicer than forcing a 15+ character password that I’m going to forget when the session expires.
I don’t know what everyone else’s experience is, but recently I’ve been seeing a growing assumption that ‘x account is safe because MFA is enabled’…
We teach ‘don’t click links in emails’, but the same should be taught for browsing the clear web. Even from the most reputable advertising companies, social media sites deliver bad websites from time to time. Whether it’s a credential harvesting, a scam site or straight up malware it’s happened before and will happen again.
Now what I wanted to bring up was the issues surrounding ‘redirect_uri’ session poisoning. This effectively exploits the redirect_uri parameter handled in an oauth (open authorisation) request and leaks a token back to malicious actors who have specified an arbitrary client using various crafted URLs; some of which make use of URL shim bypass vulnerabilities and could theoretically bypass phishing protections such as safelinks.
The saddest of all is that, if the actors are able to craft the link extensively and could evade detection, they could steal the token from the users active session, and this would be invisible to the end user.
I like to compare this to a gated kingdom – your MFA is a double-gate, but if you’ve got an unwatched tunnel underneath your guarded double gate – what would be the point of that double gate?
So, I created an oauth troll with the thoughts that it could be used in a phishing simulation, in order to demonstrate what could potentially happen.
These URLs are shimmed using various providers trusted links – Facebook, Google, Slack all make use of open redirects and shimming (where applicable), but all this one does is log you out of your Office account, rather than steal the tokens.
Example of a safe redirect (1 step):
[https://www.google.com/url?sa=t&url=][https://www.office.com/estslogout?ru=%2F%3Fref%3Dlogout]
https://www.google.com/url?sa=t&url=https://www.office.com/estslogout?ru=%2F%3Fref%3Dlogout
Example of vulnerable open-redirect (2 step shim):
(Step 1)
[www.facebook.com/l.php?u=][https://www.office.com/estslogout?ru=%2F%3Fref%3Dlogout]
www.facebook.com/l.php?u=https://www.office.com/estslogout?ru=%2F%3Fref%3Dlogout
(Right click on follow link and copy link and then you get step 2 shimmed link)
Shim bypass version (Step 2)
[https://l.facebook.com/l.php?u=][https%3A%2F%2Fwww.office.com%2Festslogout%3Fru%3D%2F%3Fref%3Dlogout][&h=AT2BScF7QXZ3EAeMN6GUhmaENbpRC_RFMeSaS84lNm63f_h0xmZEm8MmLWZ-MRBdEnyPSohCsRSWNP3G9yj_4pgjao-seJsBFFGgi4H_d2WkwRo9WhR8cx6_UrYlvLvi]
https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.office.com%2Festslogout%3Fru%3D%2F%3Fref%3Dlogout&h=AT2BScF7QXZ3EAeMN6GUhmaENbpRC_RFMeSaS84lNm63f_h0xmZEm8MmLWZ-MRBdEnyPSohCsRSWNP3G9yj_4pgjao-seJsBFFGgi4H_d2WkwRo9WhR8cx6_UrYlvLvi
In-fact it appears as though you can switch l.facebook.com to lm.facebook.com which is the mobile version. I’m not sure if it’s handled any differently but this was able to be switched after the link shim bypass:
https://lm.facebook.com/l.php?u=https%3A%2F%2Fwww.office.com%2Festslogout%3Fru%3D%2F%3Fref%3Dlogout&h=AT3Eyw1JRpYB7wb8L2ToiEf5DTGoKduj5wxC0g7DU4rRMb1PIjKm0idVq3k-GBsLhlaGJV_B83wyK-moXjZW-WZ7IIBCVLUr_QRczP4JE6Z2OZdnwGY9xQCaUh8XKpyq
Though Facebook are doing a better job of handling these, it seems as though the redirect shim expires in a shorter period of time, meaning it may have already done so.
If you’d prefer to switch this out with your Google account, logout and you can run with:
https://www.google.com/accounts/Logout
Open Authorisation Exploitation – Key Takeaways
There are many more examples of these, but you can find them yourself. Open redirects are everywhere too, you can grab them when you click on hyperlinks just by checking out the network tab on Chromium browsers…
I hope that this has proved beneficial for some people, and points out that just because you’re in the cloud, you aren’t immune from attacks. Some might even say this is easier than hacking your legacy infrastructure – I know I would – all I would have to do is convince your user to click a Facebook link, tell them it’s an embarrassing picture of them with a spoofed email from a colleague, then account access is granted.
Ultimately, I hope that this has shown the need for a SOC despite moving to the cloud. However, it’s not all bad – I believe it is still easier to manage, however it’s just not impenetrable like some people may believe it is.
