Patch Actively Exploited Outlook Flaw ASAP; Deploy Workarounds on Vulnerable Android Phones with Samsung Exynos Chipset; Meaningful Change Unlikely from Healthcare Sector Cybersecurity Hearings

In addition to the widely covered vulnerabilities, some of which are already exploited, I would like to point out CVE-2023-23415. This vulnerability is at least interesting, even if it may not be easy to exploit. A single ICMP error packet leading to remote code execution shouldn't be underestimated, and yet again proves how we are not done finding vulnerabilities in 30+ year old TCP/IP stacks.

The different exploit groups have been out on the internet discussing various ways to exploit this vulnerability. I would look at what folks over at MDSec ActiveBreach and a few others have discussed about various methods to abuse this Outlook feature.

It’s been 20 years since MSFT moved to a monthly patch cycle (aka Patch Tuesday). By now organizations should have ‘well oiled’ processes to handle these monthly patch updates. This batch includes a number of remote code execution as well as two ‘zero days’ being actively used. Exercise your patch process and remediate these vulnerabilities first.

If one critical infrastructure entity is being targeted, assume others in the same business (energy) will also be targets. Moreover CVE-2023-23397 is rather deceptive. While labeled a privilege escalation flaw, it is used to capture NTLM hashes for a pass the hash attack. But it only works for self-hosted exchange. At some point reacting to flaws relating to self-hosted Exchange is going to surpass the cost of using a hosted version, if upsurge not there already. Don’t forget to incorporate Adobe updates as they’ve also released a bunch this week.

This is not only a very nasty bug, but it will also take forever to be patched across the fragmented Android ecosystem. Note that the chip is made by Samsung, but may be used in many phones that are not made by Samsung. Turning off Wi-Fi calling and Voice-over-LTE isn't a viable option for many.

Easy work around (turn off Wi-Fi calling and Voice-over-LTE ) which is needed because Samsung and other Android-based phone vendors have a mixed track record in timeliness of patch availability and a complex ecosystem to push the patches out to.

The Samsung chipset in question here is a very popular one on a very popular set of Android devices globally. This could have wide-ranging impacts in areas of the world in the middle of the conflict. Unfortunately, this will require the device manufacturer to fix, and the workarounds will be less than acceptable for some individuals.

These are serious vulnerabilities that demand immediate attention from both the chipset and mobile device manufacturers. What is interesting is that several of the vulnerabilities have been known by those manufacturers for over 90 days and are now being released before patches are available.

All you need is the device phone number to affect the compromise. That low bar may offset the inconvenience of the workaround. Note this is for devices with the affected Samsung chipset, not just Samsung devices. Pixel users have patches in their March update, you’re going to have to check the OEMs of your android fleet for specifics on when they will have patches. This is a good time to make sure your mobile device management system has sufficient visibility on OS versions and installed updates.

Most of the industry testimony is only about the government setting standards if (a) a “single set of prescriptive security practices” could be defined; and (b) safe harbor from penalties and lawsuits is provided if that magical “single set of prescriptive security practices” is followed. That is like the rest of the world asking the medical world for a “single set of prescriptive medical practices” to cure cancer, or even just bronchitis (known as the scarier RSV these days.)

I worked in this space for many years. Healthcare is a highly regulated industry, much like in the banking sectors of the US. It is not, however, regulated in its IT Security like the banking sector. There need to be more incentives outside of ransomware to strengthen this sector and protect patients and personal information. It is probably time to have better oversight in this area as these systems become more like ICS OT Networks in the IT space. They have a long-life span, and to upgrade operating systems to their latest and greatest, the hardware attached to them starts to lose its longevity. Hate to say I’m for this, as I don’t think regulations like PCI are the sanest, but in place of better action from all in the sector, self-policing, I’m not sure there is a better vehicle.

While I applaud that healthcare officials recognized the need for a minimum standard, other work still needs to be done to be effective in deterring cyberattacks. Many of the organizations that make up the healthcare sector, simply don’t have the resources to implement the minimum set of cybersecurity controls. Work needs to be done to automate both implementation and active monitoring of the minimum standard. This is an area where government can send a demand signal to Industry to automate and simplify compliance to the minimum standard.

HIPAA remains "in the ditch." In an effort not to be prescriptive, the author of the HIPAA security rules asked each covered entity to do a risk assessment. Not only would this effort be replicated across many entities, many would not have the necessary knowledge, skills, abilities, and particularly the experience to do these risk assessments. The result has been all too obvious. Legislators would be an even worse choice to prescribe security for all covered entities, but law would at least remove the uncertainty that now faces the industry.

Let’s see, a four year old vulnerability being actively used to exploit a federal government agency. So much for my previous comment about organizations having established processes for MSFT ‘patch Tuesday.’ There is little cost incurred by the evil-doer to exploit a known vulnerability. Every organization should double-down on their patch management processes to force a change in attacker tactics and techniques.

Time to make sure you didn’t overlook this update. The KEV was due 5/3/22 even though it was added in November 2021. The current CISA alert includes IOCs your threat hunters can leverage. Make sure you’re scanning fully for the software as the FBEC compromise happened because the vulnerable software was in a location the scanner didn’t check, even though it had the signature to recognize the issue.

I have seen doctors use their devices to take pictures and or share data, so I can imagine that photos like this are available on more than just controlled systems. This is a case to follow, just like the report below, where more oversight is requested.

The need to file a lawsuit is unfortunate but not unexpected. As this case winds its way through the court, the question that will be raised: did LVHN exercise a standard of reasonableness in protecting its patient’s health data? It has little to do with what the evil-doer did with the compromised information, but rather, did LVHN have a cybersecurity program in place and was it being effectively managed by the security team.

As more privacy laws come into play, expect increased pressure to not only safeguard consumers data but also be accountable for its loss. Get with your legal team and privacy officer now (before you have an issue) to determine requirements and response plans. Update those plans when new legislation passes. You may need to add some controls to meet current and future requirements.

Just another example of how reusable login credentials are easily obtainable and reusable by criminals.

Login credentials need not and should not ever exist in the clear. Even then MFA would have preserved the integrity of the system. MFA goes beyond essential to mandatory.

From the current information, this is a good example of the right form of communications when an incident happens, vs. trying to keep it quiet.

A reminder to make sure non-production environments are secured. They often include production code and non-obfuscated data. Take steps to ensure you not only know where copies of data are but also your code or other IP, then take steps to verify it remains secure. No unpatched orphans.