Change Healthcare Says Clearinghouse Services are Functional; CISA Red Team Assessment Report; D-Link Tells Users to Replace End-of-Life Routers

Nine. Months. Later. Their clearinghouse service is not the last thing needing service restoration. I'm pretty sure none of us have put nine months as a recovery time objective without considerable management buy-in. I'm sure there were many conversations about the restored service stability, ability to handle the prior workload plus any catch-up work, and the zinger, promises that the compromise would never happen again, all of which result in delays. Work these out, including what evidence is expected, in your tabletop exercises. Don't forget to include exercises where you actually rebuild/recover and operate a system.

What fallout will we see from Change Healthcare? I am not sure the blowback has been strong enough yet in the Medical Sector. Does that say more about Healthcare IT or just Healthcare in general?

This may well have been one of the most expensive breaches in history with much of the cost being borne by customers.

The western world has a serious problem with critical infrastructure. Don't forget Volt Typhoon! Adversaries have persistence TODAY in water, power, healthcare, etc. and can break our first world bubble at any time. If you aren't a critical infrastructure provider, please consider volunteering with Infragard or local cyber civilian reserves (where available). Note: the red team here did not gain access to OT/ICS systems. That's great news!

Red Team, Blue Team, Purple Team, Architect, in the sector, not in the industry, it doesn't matter. I highly recommend reading this report. It doesn't matter if you are early in your career, late in your career, director, or CIO, this is a valuable report. I recommend reading this report if you do nothing else today or next week.

Three takeaways here: First is the importance of defense in depth. Not just EDR but also network layer detection and response. Second is to keep the staff trained and supported with the resources to detect, understand and respond to current threats. Third is management support and understanding of threats for proper risk-based decision making, not supporting updates of known vulnerable software, instead accepting the risk. Where a WAF had been deployed in response to a discovered vulnerability, in the new VDP program, it was never toggled from monitor/learning mode to blocking mode, management should have verified procedures were in place to ensure issues were fully addressed and verified. Take a hard look at your shop in this context, then take steps to avoid a me-too scenario.

These devices are typically installed in the houses of non-IT individuals. I suspect when you're in the US and going to your parents'/relatives' houses, maybe take a look and see if they are running these older devices. If so, Christmas is around the corner.

These are not expensive devices and most users have gotten good value from them. The replacements will offer improvements in value, performance, features, and functions. Much of the cost of replacing them will be in the setup, configuration, and network downtime. (Hopefully the replacements will not have default passwords.)

It's totally legitimate to set EOL dates and not provide updates beyond that point. And it's on us, as consumers, to plan for that. Having a scored CVE for the vulnerability helps make the case for prompt action, even if these devices are under $200 each.

D-Link is at least offering a discount for people who need to switch devices. On the other hand, open source solutions like OpenWRT will often extend the life of these devices by years.

Qualys team continues to find classic amazing bugs in Legacy Software. It not only feels retro, but in this case, it is retro.

Needrestart can be compelled to execute arbitrary scripts, which can be mitigated by changing /etc/needrestart/needrestart.conf to disable interpreter scanners by setting $nrconf{interpscan} to 0 until you deploy the updated packages. In CVE-2024-48990 and CVE-2024-48922 an attacker can run a script which uses environmental varabiles to execute arbitrary code, while CVE-2024-48991 requires exploiting a time-of-use time-of-check race condition. In CVE-2024-11003 attacker-controlled input is fed to Module::ScanDeps triggering CVE-2024-10224. Tip: it took you longer to read that paragraph than it would to deploy the updated needrestart and libmodule-scandeps-perl.

Qualys did not provide a proof of concept exploit, but there is enough detail in their report to assume that an exploit will be released before you read this. This is only a privilege escalation issue, but should still be addressed quickly.

Everything we do in security is bounded by resources (people, time, money), and prioritizing those resources towards maximum RRROI (Risk Reduction Return on Investment) is critical. Since by definition fuzzing starts with an infinite number of possible inputs, creating fuzzing targets to increase the odds of finding vulnerabilities, or in particular to maximize code coverage and reduce, is needed. Using AI techniques seems promising, but my worry is what 'blind spots' are or will be built into the LLM models being used for this? There have been great demonstrations about how AI-based image recognition models can be easily defeated. Increased code coverage should be a good thing, unless the remaining code area is the real vulnerability swamp.

The AI LLMs are both reducing the time to detection and finding flaws not discovered by "human-written" fuzzing tests. While the ultimate goal is to have the LLM generate a suggested patch for flaws found, consider how leveraging the OSS-Fuzz open-source tool in your SQA processes would help you with discovery with nominal impact on the release process, assuming no issues are found.

CVE-2024-44309 is a cookie management flaw, while CVE-2024-44308 impacts the JavaScript core. Note these apply to both iOS 17 & 18. Make sure that you're working to be on devices which can all run iOS 18, it's a lot easier when your fleet is all on the same version. Your Mac users are likely already getting prompts to install 15.1.1 - make sure the updates are actually applied.

Just a reminder that most Apple users should have automatic updates enabled.

While their placement has moved around from a ÒMost DangerousÓ perspective, all of the vulnerabilities were listed last year in the top 40 Ð none of them are new. If you required all code to get a clean run from most modern app vulnerability testing tools before promoting to production systems, you would have known of these in advance of exposure.

What have we learned? In my lifetime thus far, these bugs haven't changed in how dangerous they are, they appear to be static in that sense. Take this into account when you consider we are not making any less software as a species, only more software is being made.

Input sanitization (neutralization) has been a challenge and a successful attack vector for a while. The other vulnerabilities aren't new either, so your security testing (static and dynamic) should already be revealing these weaknesses. The focus has to be on secure coding, taking the time to ensure weaknesses are addressed as early as possible in the SDLC. Use this report to bolster the case that secure development is as important as delivery.