Puts me in mind of this scathing report from CISA on how a state-sponsored group broke into Microsoft and then into the State Department and a bunch of other agencies. Reads like a heist movie.
What I found most incredible about the story is that it wasn't Microsoft who found the intrusion. It was some sysadmin at State who saw that some mail logs did not look right and investigated.
It’s true, and briefly made the news at the time[1]. The CSRB was also decimiated, and the current DHS deputy secretary, in his confirmation hearing, called for wrecking the agency, as he disagrees with their efforts to maintain election security.
This, exactly. There are so many "cyber experts" working for the U.S. government, and the vast majority are just cogs in a machine constructed by executive leadership who will always prefer inertia over radical changes.
I don't think this is that much to do with executive leadership. Many of those cyber experts only have a job because of Microsoft based tooling and vulnerabilities, and so they will prefer things they know over things they don't know (e.g. implementing permissions across a Linux estate).
The state of cyber-security is a joke given that the entirety of civilization depends on these systems to function. It's like we transferred all our stuff into a boat with a gaping hole in the bilge plugged with a wad of duct tape and started sailing towards the open ocean. Forget putting the cart before the horse, the old mare is still in the barn and cart is about 3 counties over, upended in a ditch.
Yesterday ProPublica and ArsTechnica published a takedown of Azure: "Federal cyber experts called Microsoft’s cloud a “pile of shit,” approved it anyway" ...
In those types of reviews/audits, documentation is the first indicator of whether a security organization has their act together. It's about building a trust relationship between the accreditor and contractor that will have to endure for years, as nation-state level actors throw their resources at finding vulnerabilities. MS couldn't do this or couldn't be bothered to do this. So shit documentation -> shit security processes and operations -> shit security -> shit cloud product in a government context. So the title wasn't that much of a stretch.
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.
It's true, they lied. But, paradoxically, in this case, while they lied about details, the conclusion is still true: Azure is very far from AWS and GCP as far as security is concerned. I have my own suspicions why it is so, but the reasons are not important, what counts is the final conclusion: if you really care for security, you'd better chose one of the other two.
Azure looks worse right now. AWS and GCP still ship plenty of auth bugs, bad defaults, and policy footguns, so if you care about securty the sane move is to assume every cloud will fail in ways the marketing page forgot to mention and build your controls around that, not around a brand ranking.
Every security engineer I know working at Azure is on the verge of self-harm because of the current situation, or is the dumbest IC I've ever met and somebody I think should have never become a security engineer. Sample size ~12.
I am not very close with every one of these engineers, and some no longer work at MSFT, but yes talking to employees in Seattle working on security made me never want to use Azure.
> 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 long, that it was rejected by the database. And the program that submitted the SQL query to the database did not have any logic for handling a query failure, which is why there is no trace of the login attempt in the log or elsewhere.
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.
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 loaded when there were just secrets "A" & "B". When I then clicked the delete icon for "B", Azure deleted secrets "B" and "C" … which had been added since the page load. Essentially, the UI said "delete this row" but the API was "set the set of secrets to {A}". The audit log then logged the API "correctly" in the sense of, yes, my credentials did execute that API call, I suppose, but utterly incorrectly in the sense of any reasonable real-world view as to what I had done.
Thankfully we got it sorted, but it sort of shook my faith in Azure's logs in particular, and a little bit of audit logs in general. You have to make sure you've actually audited what the human did. Or, conversely, if you're trying to reason with audit logs, … you'd best understand how they were generated.
I don't think I would ever accept audit logs in court, if I were on a jury. Audit logs being hot lies is within reasonable doubt.
That's why I'm a great fan of positive confirmation steps before such changes with possibly large implications. The whole change needs to be shown to the user with all changes marked and then you confirm once more that that is what you want and then that and only that gets executed. All these 'video game' interfaces with implicit saves and underwater API calls are super dangerous.
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.
I dunno. It seems kinda bad that core auth log - which should be a primary source of truth during, say, a security audit - seems to work on a best-effort basis?
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.
from my experience it's more of a business guy/executive thing, they see Microsoft as a reliable, low-risk vendor which can speak their language. "nobody ever got fired for buying IBM" type thing
I was gonna say people have been hating on M$FT for decades. It started for me 20+ years ago. I'm glad to see that Azure is creating a whole new cohort of haters - just like good ol' Vista.
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.
This is definitely not it. If you want free use of an OS in CI/CD and testing, use Linux. If you want Docker or Kubernetes, use Linux. No one thinks it's the only option, but you'd have to have a really good reason to pay to use Windows on the server.
That may have been the story, but avoiding paying per-core licensing fees for an operating system is the only sane decision.
Operating systems and other applications that demand per-core licensing fees exist only because the people who buy them do not use their own money for this, so they do not care how much money they are wasting.
Most companies waste huge amounts of money not only for software, but for many other things, because those who have the power to make purchasing decisions have personal interests that are not aligned with what is really optimum for the company, while those who might have the best interests of the company in mind do not have the knowledge that would allow them to evaluate whether such purchasing decisions are correct.
The survival of Windows Server is not justified by any technical advantages. A few such advantages exist, but they do not compensate the huge PITA caused by licensing. I worked at a few companies where Windows Server was used and replacing it with either Linux or FreeBSD was always a great improvement, less by removing the payments for the licensing fees, but by providing complete freedom to make any changes in the environment without the friction caused by the consequences that such changes could have in modified licensing fees.
> It's not often that you see a demo of an actual Azure vulnerability, as they get patched and are gone forever. However, because Microsoft was having trouble replicating this complicated bypass, and asked for a video, I come bearing receipts.
Absolutely savage lol
[If you didn't read the thing, it's one curl command.]
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.
Maybe I can use one of these to get in to my organization azure account from my alma mater. The email was deleted right after I graduated, but Microsoft has been trying to bill me (for a reserved IP or something) for close to a decade. Support is useless of course.
Imagine if Microsoft spend more attention on making Windows suck less and Azure better, because in my eyes it is not as awful as whatever the heck AWS' dashboard is supposed to be. Azure has a rich set of developer libraries for their offerings, and their dashboard isn't nearly as awful as AWS. I've never used GCP so I can't comment on theirs, or their libraries.
It should really horrify everybody that Microsoft is not investing more into Azure considering they host the worlds most known LLM (and used?).
I don't know why you'd believe they've ever been capable of putting out quality software.
A bug in the software is a bug in the process, and the process is the job of leadership. They've never cared about software quality. They'll put out lots of books about it, lots of talks, lots of claims. But they won't actually put out quality software. It's not in their DNA, never was.
It's not their size nor their age that makes this hard for them. Plenty of larger, older companies put out better product ever day. It's just them. Someone in each size class is the best, and someone else is the worst. MS has been the worst the entire time.
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?
> I have not looked at Oracle cloud yet. Is it any better than MS?
At last glance it's far more like infrastructure leasing, with some Oracle twists, such as hosted Oracle databases, than it is full on cloud services. But this was a few years ago.
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.
> There is NO expectation of privacy for staff! GDPR does NOT apply to non-European government departments! Etc...
There is just... not for this. This is literally the case allowed by GDPR, only thing that GDPR requires is making sure those logs can only be accessed by people designated in organisation to parse it
> 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.
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.
This has nothing to do with being within the jurisdiction of the GDPR or not. There are a variety of national laws worldwide which effectively overlap with or subset the GDPR (because most governments do seem to find protection of personal data worthwhile for their citizens), and Microsoft has to deal with those (either at the behest of their customers or because they are required to).
But Microsoft can totally handle applying the GDPR correctly. They have a lot of countries as customer which use Azure in some capacity and where the need for comprehensive audit logging exists. What you were seeing is a bug; or rather a design flaw, marked as WONTFIX. Some customer rep was giving you the two-fingered salute by starting with 'but GDPR…'.
Puts me in mind of this scathing report from CISA on how a state-sponsored group broke into Microsoft and then into the State Department and a bunch of other agencies. Reads like a heist movie.
https://www.cisa.gov/sites/default/files/2024-03/CSRB%20Revi...
What I found most incredible about the story is that it wasn't Microsoft who found the intrusion. It was some sysadmin at State who saw that some mail logs did not look right and investigated.
Don't worry CISA and any other involved regulator were gutted by DOGE.
Is that true or you’re just assuming it’s so?
It’s true, and briefly made the news at the time[1]. The CSRB was also decimiated, and the current DHS deputy secretary, in his confirmation hearing, called for wrecking the agency, as he disagrees with their efforts to maintain election security.
---
[1] https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
Is it false or you’re just assuming it’s so?
https://www.csoonline.com/article/3844047/cisa-cybersecurity...
Thanks for sharing your insight
Ah yes, back when the US actually had cyber defence and experts capable of working in their respective fields.
They're the ones that had the Microsoft tech procured and implemented.
There's a decent chance they're the ones who said "no!" and got overruled.
(See also: quite a few bits of COVID mitigation)
This, exactly. There are so many "cyber experts" working for the U.S. government, and the vast majority are just cogs in a machine constructed by executive leadership who will always prefer inertia over radical changes.
I don't think this is that much to do with executive leadership. Many of those cyber experts only have a job because of Microsoft based tooling and vulnerabilities, and so they will prefer things they know over things they don't know (e.g. implementing permissions across a Linux estate).
The state of cyber-security is a joke given that the entirety of civilization depends on these systems to function. It's like we transferred all our stuff into a boat with a gaping hole in the bilge plugged with a wad of duct tape and started sailing towards the open ocean. Forget putting the cart before the horse, the old mare is still in the barn and cart is about 3 counties over, upended in a ditch.
Worse yet the industry insists you can fix the hole by putting more guard towers with machine gun nests on the deck
Yesterday ProPublica and ArsTechnica published a takedown of Azure: "Federal cyber experts called Microsoft’s cloud a “pile of shit,” approved it anyway" ...
https://arstechnica.com/information-technology/2026/03/feder...
In which one expert called the documentation provided "a pile of shit", which propublica took the liberty of extending to Azure itself
In those types of reviews/audits, documentation is the first indicator of whether a security organization has their act together. It's about building a trust relationship between the accreditor and contractor that will have to endure for years, as nation-state level actors throw their resources at finding vulnerabilities. MS couldn't do this or couldn't be bothered to do this. So shit documentation -> shit security processes and operations -> shit security -> shit cloud product in a government context. So the title wasn't that much of a stretch.
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.
Titles are editorialised and space limited. The first couple lines in the article linked above make the nuance pretty clear.
[edit: 'pretty' instead of 'perfectly']
You are defending not just clickbait, but libelous clickbait.
I doubt this reaches the bar for libel by a long shot.
It's only libelous if it's not true. This vulnerability says otherwise.
It is libelous because it is a claim that "X said Y", not "Y".
Ah, so you're worried about the review team being misrepresented, not that Azure is shit.
In this case, it’s just yet another design-level vulnerability in Microsoft cloud’s services. There isn’t much room for nuance.
It's true, they lied. But, paradoxically, in this case, while they lied about details, the conclusion is still true: Azure is very far from AWS and GCP as far as security is concerned. I have my own suspicions why it is so, but the reasons are not important, what counts is the final conclusion: if you really care for security, you'd better chose one of the other two.
Azure looks worse right now. AWS and GCP still ship plenty of auth bugs, bad defaults, and policy footguns, so if you care about securty the sane move is to assume every cloud will fail in ways the marketing page forgot to mention and build your controls around that, not around a brand ranking.
“Fake but accurate.”
ProPublica has an agenda, and they slant their reporting to push it.
You can like their agenda and support this effort, but it’s not journalism.
What is their agenda?
If a slop engine calls a slop company slop, has anyone really lost?
We lost, for one of us got tricked to bring it here.
Ars just republished it under license
Every security engineer I know working at Azure is on the verge of self-harm because of the current situation, or is the dumbest IC I've ever met and somebody I think should have never become a security engineer. Sample size ~12.
That is quite the indictment.
I am not very close with every one of these engineers, and some no longer work at MSFT, but yes talking to employees in Seattle working on security made me never want to use Azure.
Bloomberg and CNBC don't seem to have reported about this, maybe someone with contacts could make them aware?
> 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 long, that it was rejected by the database. And the program that submitted the SQL query to the database did not have any logic for handling a query failure, which is why there is no trace of the login attempt in the log or elsewhere.
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.
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 loaded when there were just secrets "A" & "B". When I then clicked the delete icon for "B", Azure deleted secrets "B" and "C" … which had been added since the page load. Essentially, the UI said "delete this row" but the API was "set the set of secrets to {A}". The audit log then logged the API "correctly" in the sense of, yes, my credentials did execute that API call, I suppose, but utterly incorrectly in the sense of any reasonable real-world view as to what I had done.
Thankfully we got it sorted, but it sort of shook my faith in Azure's logs in particular, and a little bit of audit logs in general. You have to make sure you've actually audited what the human did. Or, conversely, if you're trying to reason with audit logs, … you'd best understand how they were generated.
I don't think I would ever accept audit logs in court, if I were on a jury. Audit logs being hot lies is within reasonable doubt.
That's why I'm a great fan of positive confirmation steps before such changes with possibly large implications. The whole change needs to be shown to the user with all changes marked and then you confirm once more that that is what you want and then that and only that gets executed. All these 'video game' interfaces with implicit saves and underwater API calls are super dangerous.
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.
This is a great example for educating devs on the dangers of “set” operations vs. “pull/delete” in contexts where data can be edited concurrently.
I would say that the audit log was accurate, though, even though the bad UI design caused unintended consequences.
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.
Microsoft managed to introduce a critical vulnerability in Notepad, so this does not surprise me
Bypassing logging feels relatively unimportant compared to some of the recent EntraID vulns we’ve seen
I dunno. It seems kinda bad that core auth log - which should be a primary source of truth during, say, a security audit - seems to work on a best-effort basis?
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?
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.
from my experience it's more of a business guy/executive thing, they see Microsoft as a reliable, low-risk vendor which can speak their language. "nobody ever got fired for buying IBM" type thing
I figured they were risk averse and picking based on name familiarity.
As a European, you’re on your own there…
I see azure in more European job ads (and .net) than I ever did in California…
Well, as far as my experience, we the old generation despise Microsoft even more
I was gonna say people have been hating on M$FT for decades. It started for me 20+ years ago. I'm glad to see that Azure is creating a whole new cohort of haters - just like good ol' Vista.
Classic to pat yourself on the back, push blame, and have no evidence to show you made any kind of change about it. Classic!
wtf does this even mean? Did you reply to the correct thread?
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.
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.
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.
This is definitely not it. If you want free use of an OS in CI/CD and testing, use Linux. If you want Docker or Kubernetes, use Linux. No one thinks it's the only option, but you'd have to have a really good reason to pay to use Windows on the server.
That may have been the story, but avoiding paying per-core licensing fees for an operating system is the only sane decision.
Operating systems and other applications that demand per-core licensing fees exist only because the people who buy them do not use their own money for this, so they do not care how much money they are wasting.
Most companies waste huge amounts of money not only for software, but for many other things, because those who have the power to make purchasing decisions have personal interests that are not aligned with what is really optimum for the company, while those who might have the best interests of the company in mind do not have the knowledge that would allow them to evaluate whether such purchasing decisions are correct.
The survival of Windows Server is not justified by any technical advantages. A few such advantages exist, but they do not compensate the huge PITA caused by licensing. I worked at a few companies where Windows Server was used and replacing it with either Linux or FreeBSD was always a great improvement, less by removing the payments for the licensing fees, but by providing complete freedom to make any changes in the environment without the friction caused by the consequences that such changes could have in modified licensing fees.
You don't get too far up the career ladder if you don't understand "Nobody ever got fired for buying X".
> It's not often that you see a demo of an actual Azure vulnerability, as they get patched and are gone forever. However, because Microsoft was having trouble replicating this complicated bypass, and asked for a video, I come bearing receipts.
Absolutely savage lol
[If you didn't read the thing, it's one curl command.]
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.
Maybe I can use one of these to get in to my organization azure account from my alma mater. The email was deleted right after I graduated, but Microsoft has been trying to bill me (for a reserved IP or something) for close to a decade. Support is useless of course.
just throw another few on the pile:
https://mastodon.social/@azureshit
Imagine if Microsoft spend more attention on making Windows suck less and Azure better, because in my eyes it is not as awful as whatever the heck AWS' dashboard is supposed to be. Azure has a rich set of developer libraries for their offerings, and their dashboard isn't nearly as awful as AWS. I've never used GCP so I can't comment on theirs, or their libraries.
It should really horrify everybody that Microsoft is not investing more into Azure considering they host the worlds most known LLM (and used?).
I don't know why you'd believe they've ever been capable of putting out quality software.
A bug in the software is a bug in the process, and the process is the job of leadership. They've never cared about software quality. They'll put out lots of books about it, lots of talks, lots of claims. But they won't actually put out quality software. It's not in their DNA, never was.
It's not their size nor their age that makes this hard for them. Plenty of larger, older companies put out better product ever day. It's just them. Someone in each size class is the best, and someone else is the worst. MS has been the worst the entire time.
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?
> I have not looked at Oracle cloud yet. Is it any better than MS?
At last glance it's far more like infrastructure leasing, with some Oracle twists, such as hosted Oracle databases, than it is full on cloud services. But this was a few years ago.
It is shocking how absolutely garbage azure is.
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:
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.
> There is NO expectation of privacy for staff! GDPR does NOT apply to non-European government departments! Etc...
There is just... not for this. This is literally the case allowed by GDPR, only thing that GDPR requires is making sure those logs can only be accessed by people designated in organisation to parse it
> 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.
> 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.
This has nothing to do with being within the jurisdiction of the GDPR or not. There are a variety of national laws worldwide which effectively overlap with or subset the GDPR (because most governments do seem to find protection of personal data worthwhile for their citizens), and Microsoft has to deal with those (either at the behest of their customers or because they are required to).
But Microsoft can totally handle applying the GDPR correctly. They have a lot of countries as customer which use Azure in some capacity and where the need for comprehensive audit logging exists. What you were seeing is a bug; or rather a design flaw, marked as WONTFIX. Some customer rep was giving you the two-fingered salute by starting with 'but GDPR…'.