Live data from Hacker News

Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

trustedsec.com

21–30 of 116 posts

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#21
Azure Entra is an example of making a system so complex that nobody can understand it entirely. I'm fairly experienced in access control systems, OIDC, crypto, etc. but I was not able to understand how it all fits together.

Google Cloud is simplistic in comparison. AWS is full of legacy complexity (IAM policies, sigh) but it's fairly self-contained and can be worked around by splitting stuff into accounts.

I have not looked at Oracle cloud yet. Is it any better than MS?

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#22

There's a big tradeoff here though: IT admins really love buying Microsoft. And when the dog tries to complain about the dogfood, the dogfood purchaser tends to not understand very well.

Isn't it an age thing mostly? Younger admins hate Microsoft with a passion it seems to me. Or is just my circle of acquaintances?

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#23
post #6

Bypassing logging feels relatively unimportant compared to some of the recent EntraID vulns we’ve seen

It takes a village of exploits to raise a successful and undetected attack.

Microsoft standpoint is probably: If it's undetected was there really an attack?

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#24
Reminds me of an Azure Support ticket I submitted a few years ago when some developer clicked the "Fix this now" button in Application Insights, which then proceeded to double the scale of an already too-large App Service Plan. [1]

The Audit log showed the service identity of Application Insights, not the user that pressed the button! The cloud ops team changed the size back, and then the mysterious anonymous developer... changed it back. We had to have an "all hands" meeting to basically yell at the whole room to cut that out. Nobody fessed up, so we still don't know who it was.

The Azure Support tech argued with me vehemently that this was by design, that Azure purposefully obscures the identity of users in audit logs!!! He mumbled something about GDPR, which is nonsense, because we're on the opposite side of the planet from Europe.

At first I was absolutely flabbergasted that anyone even remotely associated with a security audit log design could be this stupid, but then something clicked for me and it all started making sense:

    Entra Id logs are an evolution of Office 365 logs.
Microsoft developed Entra ID (original Azure Active Directory) initially for Microsoft 365, with the Azure Public Cloud platform a mere afterthought.

They have a legitimate need to protect customer PII, hence the logs don't contain their customers' private information when this isn't strictly necessary. I.e.: Microsoft's subcontractors and outsourced support staff don't need and shouldn't see some of this information!

The problem was that they re-used the same code, the same architecture decisions, the same security tradeoffs for what are essentially 100% private systems. We need to see who on our payroll is monkeying around with our servers! There is NO expectation of privacy for staff! GDPR does NOT apply to non-European government departments! Etc...

To this day I still see gaps in their logging where some Microsoft dev just "oops" forgot to log the identity of the account triggering the action. The most frustrating one for me is that Deployments don't log the identity of the user. It's one of only three administrative APIs that they have!

[1] As an aside: The plan had a 3-year Reservation on it, which meant that we were now paying for the original plan and something twice the size and non-Reserved! This was something like 5x the original cost, with no warning and no obvious way to see from the Portal UI that you're changing away from a Reserved size.

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#25

Earlier quoted context omitted.

In which one expert called the documentation provided "a pile of shit", which propublica took the liberty of extending to Azure itself

And they weren’t wrong

They still lied, because they didn't say "X is shit" but "Z said that X is shit", however Z apparently never said that.

I have become very cautious of such stories for this very reason. Who gets how much blame has a lot to do with "culture" or momentum. Bashing Microsoft for example is always super fine, but at multiple occasions I found the facts to be much more nuanced.

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#26
post #25

Earlier quoted context omitted.

And they weren’t wrong

They still lied, because they didn't say "X is shit" but "Z said that X is shit", however Z apparently never said that. I have become very cautious of such stories for this very reason. Who gets how much blame has a lot to do with "culture" or momentum. Bashing Microsoft for example is always super fine, but at multiple occasions I found the facts to be much more nuanced.

If a slop engine calls a slop company slop, has anyone really lost?

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#27

IIRC, (& I don't remember if I reported it), but Azure's audit logs don't reflect reality when you delete a client secret from the UI, either. If I remember the issue right, we lost a client secret (it just vanished!) and I went to the audit logs to see who dun it. According to the logs, I had done it. And yet, I also knew that I had not done it. I eventually reconstructed the bug to an old page load. I had the page…

That's crazy and a pretty good point.

The human in the loop doesn't really control what gets done, it only expresses intend to the frontend.

Re: Full Disclosure: A Third (and Fourth) Azure Sign-In Log Bypass Found

#29

Reminds me of an Azure Support ticket I submitted a few years ago when some developer clicked the "Fix this now" button in Application Insights, which then proceeded to double the scale of an already too-large App Service Plan. [1] The Audit log showed the service identity of Application Insights, not the user that pressed the button! The cloud ops team changed the size back, and then the mysterious anonymous develop…

> He mumbled something about GDPR, which is nonsense, because we're on the opposite side of the planet from Europe.

It was also nonsense because the GDPR is crystal clear about where PII may be used. Audit logs are one of those exceptions where the goal of identifying users simply permits storing usernames and associated attributes (certainly in the case of upgrading a paid plan).

This wasn't about the GDPR; you were being told to sod off.

Post reply on HN