Microsxxt Azure Global Admin MFA Bypass

Introduction

First of all, you might be getting curious about the post title, especially the “xx” in Microsxxt. Well, I leave it to the reader’s imagination to fill those “xx” with whatever letters they deem fit. For e.g, it can be Microsent, Microshat, Microsext etc., anything that just fits. Second, this blog post is about a vulnerability I found back in July 2020, which was not allocated a CVE ID by the MSRC team, as such I’ve categorised it into my “Not CVE writeups” category. The vulnerability allowed an attacker to completely bypass Azure MFA and login as a Global Admin, if he just had access to the admin’s email account. A Global Admin is the most powerful account in Azure, which in simple terms can be explained as an one-stop catch-all solution for an attacker to compromise an entire Organisation. You can read more about the Global Admin role here and here. The vulnerability was extremely easy to exploit if an attacker has access to just the victim’s email account as you can see from the video below.

MFA Bypass

Table of Contents

The Vendor

I think a lot of people already know about the great Microsxxt and it’s products. But still, I’d like to share my thoughts about the company. Microsxxt is one of the worst companies when it comes to secure coding practices. Their products are so bad at security that many companies have set up specific teams of so-called elite hackers called the “Red Team“, just to exploit the vulnerabilities(some of which are “features”) in Microsxxt products. I mean basically any skid out there can copy a script from the internet and exploit Windows/AD and call themselves an hacker. I’m telling you, if all you’ve done is find ways to exploit Windows/AD and consider yourself an “hacker”, then you’ll get 0 points from me no matter how creative/innovative your exploit might be. Windows and Active Directory are the most exploited software in the whole world because of shitty coding practices followed by some people and I think 10 years from now the situation will still be the same.

I know, I know, people are gonna argue that Windows/AD are very popular products and used by many organisations in the world and I can’t blame Microsxxt because most of the hackers in world are constantly focused on finding vulnerabilities in Windows/AD. Okay fine, I admit that their products are most sought after by hackers worldwide and hackers are desperate to find new vulnerabilities in them. But tell me does it gives their programmers an excuse to ignore secure coding practices? I mean they should be the most responsible people in the world when it comes to secure coding practices if they’ve such a large user base, shouldn’t they? I mean these products are proprietary(not open source) and people are still able to find vulnerabilities in them? I mean they should atleast be worried about the fact that their software is the main reason the entire IT industry have to deal with the ransomware bullshit. But NO, we’ve to silently bear with the shitfuckery of the shitty programmers of the great shitacular Microshit!

Azure Global Admin MFA Bypass

Timeline

21/07/2020 – Reported the vulnerability.

22/07/2020 – Got a Case ID allocated for the vulnerability.

30/07/2020 – Got a mail saying, this vuln is by “design”, and they will not be tracking the vuln further. Case closed.

The Vulnerability

The vulnerability lies in the authentication workflow of Microsxxt Accounts. At the time I submitted the vulnerability, Microsxxt Accounts used to prompt for “Verify your identity” authentication check, which gets triggered if you try to login from a new location(e.g, while using a VPN). This is again a Microsxxt Security “feature” which is used to prevent unauthorized personnel from accessing your account.

Now, when you choose to “Verify your identity” using the email option, which is the only option, you’ll get an email in your Microsxxt Account inbox with the code. But after this, the Azure authentication workflow kicks in prompting you for validating the MFA request. But, as you can see from the above video the Azure MFA request can be easily bypassed, thus allowing an attacker to successfully login as a Azure Global Admin.

Also, at the time of submitting the report, Microsxxt Accounts used to allow password reset by sending a code via email to the same Microsxxt account. This allows an attacker to reset the password for the Microsxxt account if he has access to the same email account. As all of the authentication factors depend upon the same factor , i.e the same Microsxxt Email Account, this can be considered as an security issue.

A few months ago, someone posted an article in Trustwave SpiderLabs Blog, regarding a security issue same as above they found during a Pentest. According to the blog post:-

Now, some of you may argue that just because somebody mentioned in some random blog post(even if it is from a trusted source like Trustwave SpiderLabs Blog), it doesn’t means this is an security issue. Well, then Ladies and Gentlemen, let me introduce you to one of the leading Web Application Security Research companies in the world:- Portswigger. According to their web security guide:-

But still according to MSRC, this issue is by their “design” and the authentication via code from email can be considered as successful MFA and the next prompts for MFA by Azure were just an issue in their “design” and there is no bypass here. When the actual truth is that the next steps in authentication flow that I was able to bypass were the original and intended steps and are the ones still used today.

The Remediation

This issue is already patched by Microsxxt. But the question still remains that how many such easily exploitable issues still remain to be discovered in Azure.

Afterthought

Now, if I by chance found a critical vulnerability in any Microsxxt product in the future, then I’ve decided I’ll give MSRC only 24 hours to fix the issue, after that I’ll publicly disclose the vulnerability. I fully understand that I’ll lose the supposed bounty that I could’ve gotten, but I think it’s a lot better to disclose it publicly and get public recognition rather than getting no bounty/recognition at all. Also, people will come to know that Microsxxt is a shitass corp and doesn’t gives fair credit to real security research! This’ll be a proper lesson for them and in the future they’ll start giving atleast some credit to other Security Researchers like me.

Conclusion

I used to like Microsxxt a lot. Honestly, you can’t completely hate Microsxxt because in the end one have to admit that they had delivered some great products to mankind(alongwith some shitty ones). But the question is, even if their Security business is one of the largest in the world and earns billions of dollars in revenue, what are they doing to make their own products more secure? The events of the past year changed my thoughts on them and recently their roll back of default blocking of macros in Office made me lose hope in them. I’ve given up on Microsxxt and now one of my goals is to somehow make Linux the most used Desktop OS in the world. Linux is already based on some of the best security practices and phishing a Linux user is more difficult than a Windows user. Maybe there would be some new and innovative techniques to exploit Linux users in the future once Linux goes mainstream. But still, I think implementing new security mechanisms in Linux will be a lot easier than relying on one Single Corporation’s mercy to roll out security fixes!

P.S:- This blog post may sound like I’m trying to be funny, but I’m not! I’m dead serious about the shitty security practices of Microsxxt! Also, today is the 30th day since I reported another vulnerability to MSRC. I’ve already warned them that if they don’t come up with a solution within 30 days, then I’ll publicly disclose the vulnerability. I haven’t got a reply from them since I sent that message. This lackadaisical approach towards security is what made me lose hope in Microsxxt. If Microsxxt doesn’t gives a damn about the security of its customers, then why should I? Also, the only case I’ll withdraw this post is when both Trustwave and Portswigger withdraw the articles I mentioned above or Microsxxt MSRC takes back it’s previous decision and grants a CVE ID recognizing this as a legit vulnerability. I want Microsxxt to learn a lesson from this and change their practices and approach towards security.

Leave a Reply

Your email address will not be published.