CrowdStrike Root Cause Analysis; UK's ICO Fines NHS IT Provider Following Ransomware Attack; Consumer Reports Investigates Data Removal Service Efficacy

One of the critical claims, that the issue is not exploitable, has been disputed. In the end, I think this comes down to a public proof showing how the outlines exploit technique works (or doesn't work) against an unpatched CrowdStrike instance.

The root cause analysis shows a long list of mitigations CrowdStrike has put in place. The issues are mostly the usual causes of software errors - new features were tested more to make sure they worked than to make sure they couldn't cause bad things to happen. The two major mitigations (runtime bounds checking and increased test coverage) illustrate this and are what we expect security companies to routinely include in their highly privileged host-based software - especially for software that (as CrowdStrike puts at the top of the Root Cause Analysis) uses powerful on-sensor AI and machine learning models to protect customer systems by identifying and remediating the latest advanced threats. These models are kept up-to-date and strengthened with learnings from the latest threat telemetry from the sensor and human intelligence from Falcon Adversary OverWatch, Falcon Complete and CrowdStrike threat detection engineers. Complex security software requiring frequent update requires high levels of runtime protection and extensive pre-release testing of updates.

The root cause analysis reads like an audit report providing insight as to why the functionality introduced in Channel File 291 back in March wasn't a problem until July. The short version is IPC for detecting malicious actions and had 21 parameters and the file only contained 20, until the interpreter tried to use the missing 21st Ð which was missed in early testing and validation. As with an audit, the issues have been addressed. If you're worried about the risks of a kernel-level plugin, CrowdStrike also published analysis of the Falcon sensor and its limitations/mitigations as a service with that level of access. This would be a good time for OS providers to evaluate the viability of reducing or eliminating kernel level access for third party services.

CrowdStrike has been extremely forthcoming in acknowledging and subsequently releasing technical details of the flaw in their application development and update process. Generally, this type of software bug (memory safety) would be caught during QA testing but was somehow missed. Publishing root cause analysis and hiring not one but two outside security review teams are each calculated steps by CrowdStrike at damage control. It appears to be working.

For most of us, automatic updates are the low risk option. For large enterprises running mission critical applications, not so much. Changes to mission critical applications should be more measured, cautious, and reversible.

In this case the deficiency was in the IT service provider, which is being fined, rather than the NHS. The takeaway is to assess the security practices of your IT solution providers as they are likely using the same practices across customers. Deep dive on how they separate their clients' services and information as well as their own security practices, you're looking for where the weakest links are. Note: if you're the weakest link, you need to address that.

MFA has become the de facto standard for Identity and Access Management (IAM). This is the third such finding in recent months that specifically calls out lack of MFA in holding organizations accountable. While the terminology used by country is different, 'adequate' vice 'reasonable' the legal effect is the same - did not meet a standard duty of care in protection of personal information.

Strong authentication (at least two kinds of evidence, at least one of which is resistant to replay) is an essential and efficient measure. Failure to employ it is reckless, increases risk, and may be subject to penalty. Be certain that universal application is required in all third party agreements.

Good report that points out often the least expensive services are higher quality than the most expensive and that minimizing the personal data you expose is always going to be the most cost-effective tactic.

The challenge is making users aware of just how much information is available online about them, many have accepted that some is there, but are unaware of the full scope of what's available. The people-search sites are data brokers; they are in the business of gathering data about people and selling it to whoever will pay for it. If you've searched for someone on-line and found a link which asks you to pay for the "rest" of the information about someone, that's what we're talking about. Consumer Reports did find that the opt-out function on the people-search sites was more effective (70% gone within one week) than the services who get paid for take-down notices and acknowledges it's a lot more work for users to go to each site and opt-out. They also found that some take-down services were affiliated with a data-broker, and therefore only took down the data for that broker.

The study validates what many of us assumed: 1) some level of collusion between data brokers and data removal services; and 2) lack of effectiveness in 'opt-out' requests. The best defense remains, limit what data you make available on-line and, review data retention policies of institutions you do business with.

Web services listening on loopback have been proliferating and they often have the ability to execute code (intentionally or not). Some under-appreciated attacks like DNS rebinding can be used to attack them despite these browser protections.

We're probably all scratching our heads saying 0.0.0.0 isn't a valid IP address; what's up here? This flaw only affects Mac and Linux systems. Links to 0.0.0.0 were being used instead of 127.0.0.1 to access local services, which should not have worked. The problem is there wasn't consistent guidance in the relevant RFC's on what browsers should do with those IP addresses. This flaw is being addressed by the major browser vendors. It will be blocked with the Chrome/Chromium 128 rollout, Apple is making changes to Webkit and Firefox is working to fix this "at a future date." Mitigations include implementing PNA headers, verifying HOST headers, using HTTPS, and implementing CSRF tokens in applications.

The INC ransomware gang is taking credit for this attack. McLaren was compromised last September by the Alphv/BlackCat ransomware gang resulting in the loss of over 2 million patient records. While this prior experience is likely aiding their recovery, they still have the hard conversations ahead about why this second attack succeeded. Something to factor into your ransomware playbook is that about 80% of organizations who paid the ransom for an initial attack are hit again, often by the same gang.

Two security incidents within a year; it's probably time for a change-up in leadership at the non-profit. Separately, the board should look to add cybersecurity subject matter expertise and make it a core part of its risk management program.

This week I asked a colleague, who practices in the healthcare industry, why this industry continues to be a target of opportunity years into ransomware attacks. His instant response was "because the decisions are being made by doctors." I confess I had not thought of that.

Check the research for affected companies beyond Deye and Solarman. Vulnerabilities included hard coded credentials, account takeover flaws, information leakage and JWT tokens which can be used across platforms. The good news is the discovered vulnerabilities are fixed. It's not clear if the providers will discover and address future flaws themselves or additional discovery like this is needed. The researchers are presenting their research the afternoon of August 9th at Defcon in the IoT Village talks.

Anything that has software and internet access can be a target, hence the need for the Dev team to follow secure software design principles. At least in this case both the researchers and vendor acted responsibly. The researchers, by responsibly reporting the vulnerabilities to the vendor, and the vendor for taking immediate action to fix the vulnerabilities.