Live data from Hacker News

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

trustedsec.com

41–50 of 116 posts

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

#41

Earlier quoted context omitted.

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?

Well, as far as my experience, we the old generation despise Microsoft even more

Classic to pat yourself on the back, push blame, and have no evidence to show you made any kind of change about it. Classic!

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

#42

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?

More an issue of procedures and processes, MS selling turn-key solutions and how things work on big companies

Try managing a directory service even on RedHat and see how it goes.

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

#43
post #32

> Having done a fair bit of logging to databases with various scripts, I believe this was a simple matter of overflowing the SQL column length for a field, causing the entire INSERT to fail. This is a common beginner mistake when you first start to work with databases. I'm not sure if I understand this part. I'm trying to put it into my own words. Is the following correct? The attacker provided an input that was so l…

That was my understanding. You have two services, one validates, another logs. The validation triggers a failure, and requests that to be inserted into the audit database, but the audit log services fails and that apparently doesn't block the validator from sending a response back to the attacker.

Reading through the article I can't help but think that many of these authentication/authorization flows are entirely to complex. I understand that they need to be, for some use cases, but those are probably not the majority.

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

#44
Only watched a little of the video, until I saw one of the requests returned an access token with lots of repeated data. Was very surprised when I base64 decoded that and found it was just "\uDFFF\uDBFF" repeating over and over. Maybe that was data coming from his exploit, seems a bit weird for that to be in an access token anyway. I had the sound muted, so maybe he mentioned that.

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

#45

Earlier quoted context omitted.

> 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…

> This wasn't about the GDPR; you were being told to sod off. Vast misunderstanding of GDPR by the clowns implementing it is also possible; or just "can't be arsed so hide it all"

More generously, they were applying GDPR rules in the correct manner, but to a different scenario: Microsoft customers being supported by Microsoft subcontractors that don't need to know the customer PII to do their job.

Most businesses using a public cloud need to log the activities of their staff accessing their own systems, which has an entirely different set of policies.

A similar example is Azure Application Insights. Microsoft uses it internally, so they keep removing features that log PII to be "GDPR compliant". Again, they're logging the activities of the general public across the entire world population, so GDPR legitimately applies. To them! Not us. Most of our scenarios are internal staff or partner organisations accessing private systems. Not only do we not do business with anyone from Europe, our systems are either privately networked or geo region locked. Europeans can't access anything in our local state government's internal staff portal even if they wanted to! Unless they hack us... but then we would very much like to log that.

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

#46
post #39

Earlier quoted context omitted.

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?

You don't get promoted to positions with power to choose for hating Microsoft.

Depends on the field you are in. There are jobs where you can’t get apps that run on anything but windows.

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

#47

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?

Silicon Valley likes to pretend Microsoft doesn't exist.

I... get it.

The FAANGS needed to scale to a level where paying per-core licensing fees for an operating system was simply out of the question, not to mention the lack of customisability.

As a consequence, they all adopted Linux as their core server operating system.

Then, as their devs made millions in share options, they all scattered and made thousands of little startups... each one of which cloned the assumption that only Linux was a viable operating system for servers.

The mistake here is the same one that caused "Only MongoDB is Web Scale" and "Microservices are necessary for two devs and a PC as our server".

Just because a trillion dollar corporation decides on a thing, it does not mean it applies universally.

Outside of this bizarre little bubble, Windows is everywhere and Windows Server is still about 50% of the overall server market.

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

#48

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?

Europeans bizarrely love Azure.

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

#49

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.

You don't get too far up the career ladder if you don't understand "Nobody ever got fired for buying X".

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

#50

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…

There is so much goofiness happening in those web portals (and also the New Portal, and the Legacy Portal) that issues like this don’t surprise me. Every time I click a button in there I worry that the wrong thing will happen to a different object. Sometimes the display reflects the worst possible outcome, like adding a user to a group will show you the new group membership as just containing that 1 new user and nobody else. Quite a few moments of panic.
Post reply on HN