detailed here<\/a>) which would enable an unauthenticated attacker to access cross-tenant applications and sensitive data, such as authentication secrets. To give you an idea of how bad this is, our team very quickly discovered authentication secrets to a bank. They were so concerned about the seriousness and the ethics of the issue that we immediately notified Microsoft. Did Microsoft quickly fix the issue that could effectively lead to the breach of multiple customers’ networks and services? Of course not. They took more than 90 days to implement a partial fix \u2013 and only for new applications loaded in the service. That means that as of today, the bank I referenced above is still vulnerable, more than 120 days since we reported the issue, as are all of the other organizations that had launched the service prior to the fix.\u201d<\/em><\/p>\nThe Tenable example could be dismissed as an isolated incident if I hadn\u2019t recently heard from multiple security researchers about other security holes they discovered and their talks with Microsoft about the issues. This is a troubling pattern.\u00a0<\/p>\n
\u201cMicrosoft plays fast and loose when it comes to transparency and their responsibilities in cybersecurity. Their pace for remediation is not world class,\u201d Yoran said in an interview. \u201cOnce they patch, they have a history of not disclosing that there ever was a hole. They have a moral responsibility to disclose.\u201d<\/p>\n
Back in the 1990s, a common and true adage among enterprise IT execs was the clich\u00e9d, \u201cYou can never get fired for hiring IBM.\u201d Today, that statement is still true, if you \u00a0swap out Microsoft for IBM.\u00a0<\/p>\n
Here\u2019s why that is such a problem. It seems all but certain that the cybersecurity corner-cuttings that happened in the China attack were done by some mid-level manager. That manager was confident that opting for a slight cost reduction (along with a small boost in efficiency at the expense of violating Microsoft security policy) would not be a job risk. Had there been a legitimate fear of getting fired or even just having their career advancement halted, that manager would have not chosen to violate security policy.<\/p>\n
The sad truth, though, is that the manager confidently knew that Microsoft values margin and market share far more than cybersecurity. Think of any company you believe takes cybersecurity seriously, such as RSA or Boeing. Would a manager there ever dare to openly violate cybersecurity rules?\u00a0<\/p>\n
If this is all true, why don\u2019t enterprises take their business elsewhere? This brings us back to the \u201cyou can\u2019t get fired for hiring Microsoft\u201d adage. If your enterprise uses the Microsoft cloud \u2014 or, for that matter, cloud services at Google or Amazon \u2014 and there\u2019s a cybersecurity disaster, chances are excellent senior management will blame Microsoft. Had you chosen a smaller company that takes security more seriously \u2014 and that company screwed up \u2014 there is a good chance you would be blamed for having taken a chance.\u00a0<\/p>\n
Chris Krebs, former director of the US Cybersecurity and Infrastructure Security Agency (CISA) and now cofounder of Krebs Stamos Group, puts this attack into a broader global context. Krebs said China government attackers were not looking at Microsoft as a software vendor as much as the owner of one of the top three cloud platforms. They see those hyperscale cloud providers as an easy way to access data from a massive number of companies.<\/p>\n
And cloud architectures \u201care insanely complex. You think you know how the cloud works? You don\u2019t,\u201d Krebs said in an interview. But he argued the cloud is a game-changing for cybersecurity for a simple reason: \u201cWhat is so different is that the cloud is effectively the first technology that the (US) government has not been able to roll out itself,\u201d he said. \u201cThey are entirely dependent on the private sector.\u201d<\/p>\n
China knows that only too well.<\/p>\n
Let\u2019s look at what happened with Microsoft and the China attack.<\/p>\n
This is from Microsoft\u2019s explanation:<\/p>\n
The China attackers \u201cacquired an inactive MSA consumer signing key and used it to forge authentication tokens for Azure AD enterprise and MSA consumer to access OWA and Outlook.com. All MSA keys active prior to the incident \u2014 including the actor-acquired MSA signing key \u2014 have been invalidated. Azure AD keys were not impacted. Though the key was intended only for MSA accounts, a validation issue allowed this key to be trusted for signing Azure AD tokens. The actor was able to obtain new access tokens by presenting one previously issued from this API due to a design flaw. This flaw in the GetAccessTokenForResourceAPI has since been fixed to only accept tokens issued from Azure AD or MSA respectively. The actor used these tokens to retrieve mail messages from the OWA API.\u201d<\/em><\/p>\nHow did an expired key still function? Cybersecurity specialists pointed to various possibilities, including whether caching played a role. But they all agreed that Microsoft didn\u2019t sufficiently test its own environment.<\/p>\n
\u201cWhy would an expired driver\u2019s license still work in a bar? It\u2019s because they are not checking expiration dates,\u201d said cryptography expert and Harvard lecturer Bruce Schneier. \u201cWhy do people leave their doors unlocked? People do things. Someone screwed up and someone didn\u2019t notice.\u201d\u00a0<\/p>\n
Michael Oberlaender, who has been CISO for eight enterprises and served on the board of the FIDO Alliance, said it\u2019s likely Microsoft had \u201cautomated code that is running the sites that did not validate the certificates properly. This was not tested right. If that proper signing key validation \u2014 including the scope and function of the key \u2014 is not happening in the PKI key chain hierarchy, then it\u2019s not working as intended.\u201d<\/p>\n
Another security specialist, Prashanth Samudrala, vice president of products at AutoRabbit. argued that the expiration date could have become irrelevant if the initial coding was not executed properly.<\/p>\n
\u201cDuring development, developers often hard code access to their systems for machine identities,\u201d Samudrala said. \u201cThese automated processes can bypass traditional authentication requirements that break security protocols \u2014 Zero Trust mandates or otherwise. And once these scripts are written, they keep going until they are manually shut down.<\/p>\n
\u201cThere\u2019s no way to know for sure what happened with Microsoft\u2019s outdated encryption key,\u201d Samudrala said, \u201cbut this would explain how access could continue after the point of a key expiring. CISOs are becoming increasingly aware of the vulnerabilities posed by all SaaS Applications.\u201d\u00a0<\/p>\n
The expiration problem was not the only issue.\u00a0<\/p>\n
\u201cIt sure sounds like the key was cached somewhere, so it wasn\u2019t being served up \u2014 which would be an opportunity to say \u2018No, that key isn\u2019t supposed to be used anymore,\u2019\u201d said Phil Smith III, senior architect, product manager and distinguished technologist for Open Text Cybersecurity. \u201cIf it\u2019s being used to decrypt data, it might still be needed \u2014depending on the flow, this caching might have been perfectly reasonable.<\/p>\n
\u201cThe bigger errors were mixing consumer and .gov credential processes and then allowing the .gov tokens from the old key to be accepted,\u201d he said. \u201cThis runs into one of the common differences between consumer encryption and corporate versus gov[ernment] encryption: consumer stuff isn\u2019t as controlled, so it\u2019s a lot harder to say \u2018You can\u2019t use this because you left it too long.\u2019 Just because Joe User hadn\u2019t logged since before the key expired doesn\u2019t mean you tell him he can\u2019t now.\u201d<\/p>\n
Smith stressed that a common reaction to a key flaw such as the Microsoft one would be to increase the frequency of key rotation. He argued that such a move might be a bad idea.<\/p>\n
Although \u201cevents like this make the case for rollover in some use cases, it\u2019s just foolish in others \u2014 like re-encrypting huge volumes of data just because it was encrypted a while ago, when there\u2019s no reason for the key to have had any significant risk of exposure. This is like being in a bunker during a war and deciding you should take off all your clothes and run to another bunker just because you\u2019ve been in this one awhile: the risk you\u2019re adding during that run\/rollover is significant and not necessarily worthwhile,\u201d Smith said.<\/p>\n
\u201cThe point is that many standards say, \u2018Roll keys every n<\/em> months\/years\u2019 without regard for the risk involved.,\u201d he said. \u201cIf the keys have been distributed to external endpoints, then sure, there needs to be a rollover strategy, because you don\u2019t have any way to assess how careful those folks are. But this needs to be planned from the beginning: \u00a0\u2018Hey, re-protect this 50TB of data by next month\u2019 isn\u2019t realistic. If keys have only gone to hardened, internal endpoints, risk is lower. If the encryption\/decryption has only taken place remotely \u2014 say, via web services \u2014 then there\u2019s little to no risk, since if someone compromised those servers, you\u2019re already toast.\u201d<\/p>\nBeyond the expired key that still worked, the biggest issue here is that Microsoft violated its own security rules and did not store the keys in an HSM. The most likely reason? Storing anything in an HSM is labor-intensive, costs more and can degrade \u00a0performance.<\/p>\n
There is \u201ca very small bit of latency drop over the network,\u201d Samudrala said. \u201dYes, (HSMs) are expensive and, yes, there is a performance degradation. When you have legacy systems, HSMs could be very, very expensive and eat into a product\u2019s roadmap. Companies seek to use cloud-based key management services rather than HSM. Why? (HSMs) are too damn hard, take a lot of time, a lot of costs, a lot of complexity.\u201d<\/p>\n
The importance of Microsoft\u2019s failure to use an HSM cannot be overstated,\u201d said Oberlaender. \u201cHad they stored and managed in an HSM, this whole (China) thing would not have been possible,\u201d he said, adding that corporate communications disconnects might have played a role. \u201cCommunications often gets blurry in big enterprises, with different entities often not talking with each other.\u201d<\/p>\n
Whatever the reasoning and rationales, Microsoft is starting to be seen as an organization that tolerates sloppy security implementation. Although such a perception is bad for any business, it could be disastrous for Microsoft, specifically because it uses its marketing clout to scream that its environments are ultra-secure for the planet\u2019s largest enterprises.<\/p>\n
If Microsoft doesn\u2019t clean up its act quickly \u2014 and hope that no more massive breaches get disclosed anytime soon \u2014 it\u2019s contract-saving adage could be flipped on its head. Could Microsoft\u2019s brand be to cybersecurity what Uber, Meta and TikTok are to privacy?<\/p>\n
http:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"![](\"https:\/\/images.idgesg.net\/images\/article\/2019\/11\/cso_nw_microsoft_windows_security_secure_laptop_user_by_methodshop_cc0_via_pixabay_2400x1600-100817346-small.jpg\"\/)
<\/p>\n
Credit to Author: eschuman@thecontentfirm.com| Date: Mon, 07 Aug 2023 10:00:00 -0700<\/strong><\/p>\n\n