Check Azure Storage Accounts for Vulnerable Configurations and Shared Keys; Microsoft Vulnerability Tuesday Requires Priority Patching; SAP Business Apps Flaws Require Expedited Patching

This is one of those “ease of startup trumped security” design choices that were made in many products (think hard-coded passwords) and delighted bad guys. Good to see that Microsoft intends to “…move away from shared key authorization” even if it does sound odd to see it called “…part of ongoing experience improvements” Yes, in general it is an “improved experience” over when bad actors can take over storage accounts…

So much for that easy button. If you're using it, turn off Azure Shared Key authorization, use AAD authentication. While it looked like you were just enabling read-only access, you were actually enabling modification/deletion capabilities as well. Expect Microsoft to publish updated guidance on using Azure Shared Storage shared key authorization, as well as configuration changes to make it disabled out-of-the-box.

While I’m glad that this is being highlighted, let’s be clear on this one. It is standard stock behavior from Azure Storage. Yes, it’s a vector in very specific situations but this isn’t unauthenticated RCE. Much like the Omigod issue a few years ago, it’s awareness but not mass scale issues. The bigger issue with this service is we still find open Azure buckets in the wild with sensitive data.

Here’s an example of the tug between enabling functions by default and secure configuration. Vendors typically provide products fully enabled; adversaries take advantage of the default configuration. The CIS Community Defense Model demonstrates that establishing and maintaining a secure configuration (Control 4) protects against the five major attack types, which reinforces the importance of secure configuration. See the CIS Azure Foundations Benchmark for secure configuration recommendations to protect the customer tenant.

The resistance of developers to safe defaults, particularly to "safe out of the box," remains high. While safe defaults may make setup marginally more difficult, changing defaults late breaks things.

One interesting "patch" this month was an update to CVE-2013-3900. This 10-year-old vulnerability allowed attackers to add data at the end of binaries without invalidating the signature. The patch was originally released in 2013, but not applied by default. It was yet again exploited as part of the 3CX software compromise. Microsoft now rolled the patch out to apply by default. Also note that the MSMQ vulnerabilities have already been exploited. MSMQ is a legacy service. After patching: Make sure you still need it, and turn it off if you don't.

While we were discussing the Apple updates, you didn't forget Microsoft was releasing their April bundle of fun, did you? You should be actively deploying these updates, seven of which are marked critical because they can be used to install malicious code without user interaction. Don't forget to turn your attention to any Windows Remote Access Servers, CVE-2023-28220 and CVE-2023-28219 (RCE flaws) affect them and are juicy targets, earning Microsoft's "exploitation more likely" tag.

MSFT instituted Patch Tuesday almost 20 years ago. Given that, all Microsoft product users should have ‘well oiled’ processes to handle these monthly patch updates. This batch includes both highly rated privilege escalation and remote code execution vulnerabilities. Exercise your patch process and remediate these vulnerabilities first before tackling the other 90+ security issues.

One would hope, if not expect, that the number of patches per month would go down with time. One would hope that the quality of the code base would improve with effort. So far, the rate remains constant with tens of patches per month.

SAP and Oracle business apps fit in the same category as Solar Winds did – high market share, lots of privileged data access, fear of disruption slows patching. Modern patch testing approaches, such as spinning up cloud-based test environments can overcome that patching fear.

The top two flaws, affecting the SAP Business Client and SAP Diagnostics Agent, have raw CVSS scores of 10.0; the following three have scores between 9.6 and 9.9. The critical flaws can be exploited without authentication and interact with the diagnostics agents to execute commands on SAP systems. Other flaws in this bulletin can be used to access configurations, disclose passwords, or otherwise impact the system integrity, availability, or confidentiality. Odds are the impacted systems in your environment need an approved downtime window; get that scheduled now so you can finish regression testing and deploy these updates quickly. Don't find out the hard way which of these are being actively exploited.

Buyer behavior is what shifts the balance. I’d like to see this group change that line to say, “it is crucial for technology *buyers* to make Secure-by-Design and Secure-by-Default the focal points of product *selection, evaluation and procurement* processes.” If buyers are willing to buy crappy products, sellers will always sell them.

The guidance is reasonable as it builds off secure by design principles that have been around for well over a decade. I just wonder, do we need another document espousing the virtues of secure software by design? The focus should be on the really, really hard part: measuring compliance to these design principles.

The idea is software should be secure by design, with a default secure configuration out of the box, and the complexity of that secure configuration is not a customer problem. Anything we can do to help customers keep their systems secure moves the bar in the right direction. My concern is this may be accomplishable with COTS systems, even so you have integrations and other business process-related changes create trust relationships which can be exploited. For individual components, like your web or application server, containers, etc. that you're using to deploy application services on top of, you're still going to need to work to secure these; the guidance provides top-down approaches you can leverage here as well.

Security by design does not simply result in more secure software but improves overall software quality and schedule. (We do not miss schedule because we do not write code fast enough but because when we put it all together is does not work right. Manage quality and schedule will take care of itself.)

All good points, and the Google white paper directly comments on the joint government guidance paper for Secure Software by Design and says “Policymaker and industry attention can at times be reactive, with emphasis on addressing threats and vulnerabilities as they arise, rather than ensuring products are secure to start with.” Requiring software to be tested for common forms of vulnerability and results available for evaluation before procurement is a great area for policy makers to be proactive. Doesn’t end the problem, but as in all forms of product safety, moves more responsibility and liability from the buyer to the seller.

They are in effect putting their money where their mouth is by not only encouraging researchers to investigate vulnerabilities and weaknesses, but also by establishing a legal defense fund to support good-faith security researchers who do not have access to legal counsel. With increased support for vulnerability research and disclosure, you need to be on top of your vulnerability management, patching and mitigation; you're not going to hide behind obscurity, "nobody would do that,” or the idea your lawyer is better than theirs. If you don't have a vulnerability disclosure program, it's time.

One must have a process called "vulnerability management" in large part because the quality of free and purchased software is so poor. This is not to suggest that writing quality code is easy but that doing so is efficient.

A nice free service which would allow you to establish the profile is genuine, and they really work at a claimed company without having to pay for their premium service. The feature is still rolling out, so you may not see the options on your profile yet. The LinkedIn help has the steps for the three verification services. Note that the CLEAR verification check requires the name on the ID match your profile: bad news if you don't go by your legal name.

Verified ID may be one of those stealth technologies that we may come to love. The idea is that of Distributed Identity. I am not sure of the privacy implications of this, but for the rest of the users that have little privacy concerns this is one to watch. It's a mix of physical and digital verifications at scale. Should be fascinating. Now can we in the US move away from social security numbers?

Identity management is vital as it underpins authenticating who we are in order to obtain a whole host of online services, both public and private. LinkedIn, rightfully, is adding additional identity verification measures to validate it users and protect against identity fraud.

LinkedIn is one of the more orderly social media sites. Still, one should follow the rule of trusting only those one knows in "meet space," or those vouched for by multiples of such people. That said, these measures by LinkedIn are simply good security, simply "know your customer."

The big reduction in the SS7 attack surface was the shutdown of 2G and 3G networks last fall. Even so, backwards-compatible services in LTE and 5G systems need to be checked for susceptibility to similar attacks. One hopes as more services are rebuilt, rather than repurposed to include 5G, SS7 threats will be behind us and we can focus on current ones.

AT&T operates FirstNet under contract from the US government to the tune of 6.5 billion. The US government getting contract-related documents [security audits in this case] from AT&T isn’t the issue; sharing them with the legislative branch apparently is. Perhaps the letter should have also been sent to the Department of Commerce, who awarded the contract. Having those security audit reports would aid any additional security assessments by CISA and NSA.

SS7. Much like BGP will be, it's time we look at building a more secure parallel network for this. It's far past time as we see much abuse on these older protocols. This is one of those areas in which regulation would force it if the industry doesn't police itself.

Most definitely you need to take the data from the Microsoft guidance and have your threat hunters look for evidence of the BlackLotus campaign. Three things you can do to mitigate risks of a BlackLotus attack include not using domain wide admin level service accounts and restricting local admin privileges to limit installations of trojans/etc., removing the Microsoft 3rd Party UEFI CA from your systems secure boot configuration if it's not required to boot, and keeping your EDR products activated and updated. (If you're a Microsoft Defender shop, this is already in place.)

Useful guidance from MSFT. That said, attention to basic cyber hygiene is equally, and perhaps more important, as the evil-doer needs to already have gained either privileged access or physical access to the device. Let’s not underestimate the importance of protecting devices from being exploited in the first place. For me that starts with Implementation Group 1 of the CIS Critical Security Controls.