3 ms·

This really surprised me when I learned of this story on the weekend. Very little discussion, very little reception in IT news. Someone hacked Azure AD[1] and

This really surprised me when I learned of this story on the weekend. Very little discussion, very little reception in IT news. Someone hacked Azure AD[1] and accessed the data of 25+ orgs and the reaction is *crickets*? [1] I'm not exactly sure which Azure component was hacked and the MS communication seems intentionally unclear and obtuse on this. It sounds like the private keys of Azure-internal auth servers were stolen, but technically those private keys were not supposed to work for the accounts/orgs in question, except they did, and, in any case, MS doesn't disclose how the private keys (one? multiple?) of their cloud auth servers were stolen.

coldpie 3y ago
I saw the headline scroll by on my Ars Technica feed[1] but I admit I didn't bother to read it because there's like 10 major security breaches every single day. Just another one to add to the pile, there's more interesting things to read about. [1] https://arstechnica.com/security/2023/07/microsoft-takes-pains-to-obscure-role-in-0-days-that-caused-email-breach/ https://arstechnica.com/security/2023/07/microsoft-takes-pai...
tgv 3y ago
There was one issue where bing search results could be editted for any query by random users with an AAD account, and made to include a script that sends the Azure credentials of the user that happened to use that query to god-knows-where. And it wasn't the only service that was practically open. And another great thing: there were no logs. That's an amazingly big, world-wide security hole, and how much interest did it draw? Hey, look, there's a celebrity scandal over there.
RVuRnvbM2e 3y ago
This is not even the first time this year that Azure AD has been owned sideways. See this mind-blowing blog post from Wiz where they live edited bing.com search results, injected XSS into O365, accessed exabytes of internal MS file storage and more: https://www.wiz.io/blog/azure-active-directory-bing-misconfiguration https://www.wiz.io/blog/azure-active-directory-bing-misconfi... I have no idea how Azure maintains its reputation as a safe enterprise choice. Microsoft really just has an almost impenetrable reputation I guess?
- dmvdoug 3y ago
  I mean, we’re talking about key federal agencies involved as the impacted customer(s), too. Yet it’s like, eh, next story.
dhx 3y ago
Microsoft has published a more technical analysis[1] which was submitted in two of those HN stories mentioned above (which received no interest). Microsoft have two identity services being MSA and AAD. MSA is used for consumer Microsoft accounts for use with products like Xbox. AAD is Azure AD that businesses use. When a client wants to authenticate to a Microsoft service, it asks MSA to sign a token for services accepting MSA tokens, or asks AAD to sign a token for services accepting AAD tokens. Someone has gained access to an "inactive" (but not "invalidated"/revoked) MSA signing key. It's not stated in the analysis whether Microsoft services such as Xbox would have accepted a token signed with an "inactive" MSA signing key, but it sounds like this may have been the case. It's just consumer privacy and security at stake and the attackers apparently weren't interested in that, so the analysis is rather ¯\_(ツ)_/¯ on consumer impact. The problem for Microsoft is that they had incorrectly configured OWA API to accept tokens signed by the MSA identity services even when accessing mailboxes that should require an AAD signed token. So now the attacker could access mailboxes for all business and government users around the world (excluding GCC High, DoD, etc which Microsoft state are not exposed to public networks). Microsoft only found out after one of their diligent customers queried Microsoft on why they were seeing logs for user mailboxes being accessed in unexpected ways. Speculatively (not in the analysis) this may have been noticed as a random IP address outside of allowed subnets accessing mailboxes at odd hours, and the customer checked their AAD configuration to ensure IP subnet restrictions were configured correctly and verified the user was not overseas. The attacker looks to have been quite careless by accessing OWA API from very obvious red flag locations for legitimate users. For example, the attacker could have used a residential ISP subnet in Washington DC to access a GCC hosted mailbox of a government agency with a presence in Washington DC, and only done so in hours that an employee may be working from home in Washington DC. Or the attacker could have gone after soft targets like small to medium businesses that contract to the government, hoping these soft targets wouldn't be monitoring nor have the ear of Microsoft for prompt incident response. Instead, the attacker has used random dedicated hosting providers in places as far as Europe and accessed mailboxes during hours coinciding with business hours half way between the US and Europe. It's possible the attackers thought this attack would be detected quickly, and therefore were always just going for a hit-and-run approach knowing they'd get their data prior to the attack being noticed and blocked. But it does make the attacker look brazen at best, and unsophisticated and careless at worst. [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ https://www.microsoft.com/en-us/security/blog/2023/07/14/ana... [2] https://learn.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc https://learn.microsoft.com/en-us/office365/servicedescripti...

coldpie 3y ago

I saw the headline scroll by on my Ars Technica feed[1] but I admit I didn't bother to read it because there's like 10 major security breaches every single day. Just another one to add to the pile, there's more interesting things to read about. [1] https://arstechnica.com/security/2023/07/microsoft-takes-pains-to-obscure-role-in-0-days-that-caused-email-breach/ https://arstechnica.com/security/2023/07/microsoft-takes-pai...

tgv 3y ago

There was one issue where bing search results could be editted for any query by random users with an AAD account, and made to include a script that sends the Azure credentials of the user that happened to use that query to god-knows-where. And it wasn't the only service that was practically open. And another great thing: there were no logs. That's an amazingly big, world-wide security hole, and how much interest did it draw? Hey, look, there's a celebrity scandal over there.

RVuRnvbM2e 3y ago

This is not even the first time this year that Azure AD has been owned sideways. See this mind-blowing blog post from Wiz where they live edited bing.com search results, injected XSS into O365, accessed exabytes of internal MS file storage and more: https://www.wiz.io/blog/azure-active-directory-bing-misconfiguration https://www.wiz.io/blog/azure-active-directory-bing-misconfi... I have no idea how Azure maintains its reputation as a safe enterprise choice. Microsoft really just has an almost impenetrable reputation I guess?

dmvdoug 3y ago
I mean, we’re talking about key federal agencies involved as the impacted customer(s), too. Yet it’s like, eh, next story.

dhx 3y ago

Microsoft has published a more technical analysis[1] which was submitted in two of those HN stories mentioned above (which received no interest). Microsoft have two identity services being MSA and AAD. MSA is used for consumer Microsoft accounts for use with products like Xbox. AAD is Azure AD that businesses use. When a client wants to authenticate to a Microsoft service, it asks MSA to sign a token for services accepting MSA tokens, or asks AAD to sign a token for services accepting AAD tokens. Someone has gained access to an "inactive" (but not "invalidated"/revoked) MSA signing key. It's not stated in the analysis whether Microsoft services such as Xbox would have accepted a token signed with an "inactive" MSA signing key, but it sounds like this may have been the case. It's just consumer privacy and security at stake and the attackers apparently weren't interested in that, so the analysis is rather ¯\_(ツ)_/¯ on consumer impact. The problem for Microsoft is that they had incorrectly configured OWA API to accept tokens signed by the MSA identity services even when accessing mailboxes that should require an AAD signed token. So now the attacker could access mailboxes for all business and government users around the world (excluding GCC High, DoD, etc which Microsoft state are not exposed to public networks). Microsoft only found out after one of their diligent customers queried Microsoft on why they were seeing logs for user mailboxes being accessed in unexpected ways. Speculatively (not in the analysis) this may have been noticed as a random IP address outside of allowed subnets accessing mailboxes at odd hours, and the customer checked their AAD configuration to ensure IP subnet restrictions were configured correctly and verified the user was not overseas. The attacker looks to have been quite careless by accessing OWA API from very obvious red flag locations for legitimate users. For example, the attacker could have used a residential ISP subnet in Washington DC to access a GCC hosted mailbox of a government agency with a presence in Washington DC, and only done so in hours that an employee may be working from home in Washington DC. Or the attacker could have gone after soft targets like small to medium businesses that contract to the government, hoping these soft targets wouldn't be monitoring nor have the ear of Microsoft for prompt incident response. Instead, the attacker has used random dedicated hosting providers in places as far as Europe and accessed mailboxes during hours coinciding with business hours half way between the US and Europe. It's possible the attackers thought this attack would be detected quickly, and therefore were always just going for a hit-and-run approach knowing they'd get their data prior to the attack being noticed and blocked. But it does make the attacker look brazen at best, and unsophisticated and careless at worst. [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ https://www.microsoft.com/en-us/security/blog/2023/07/14/ana... [2] https://learn.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc https://learn.microsoft.com/en-us/office365/servicedescripti...