Nearly half of hospital Windows systems still vulnerable to RDP bugs
Almost half of connected hospital devices are still exposed to the wormable BlueKeep Windows flaw nearly a year after it was announced, according to a report released this week.
The report, called 2020 Vision: A Review of Major IT Cyber Security Issues Affecting Healthcare, comes from CyberMDX, which provides cybersecurity systems for hospitals.
It says that 22% of a typical hospital’s Windows devices are exposed to BlueKeep. The proportion of Windows devices connected to a network that are vulnerable is far higher, at 45%, it adds.
CyberMDX gathers these kinds of metrics via its own platform, which tells it about the machines it’s protecting in the field. It told us that it has analysed a little over a million data points collected from machines across hundreds of facilities.
The BlueKeep bug, first reported in May 2019, is wormable, meaning that an attacker can trigger it without human interaction. An exploit could spread by sending malicious packets via the Remote Desktop Protocol (RDP) to Microsoft’s Remote Desktop Service (RDS).
It affected Windows 7 and Windows Server 2008, and Microsoft issued patches when it first reported the bug. However, as with many patches, it has taken companies a long time to apply, and there is a ‘long tail’ of machines still online and vulnerable.
The problem doesn’t just lie with BlueKeep. According to the CyberMDX report, 25% of connected devices in hospitals are also exposed to another flaw: DejaBlue.
News of DejaBlue surfaced in August when Microsoft patched another two RDP bugs, this time affecting versions of Windows up to and including Windows 10. These bugs, CVE-2019-1181 and 1182, are also wormable.
Like BlueKeep, the bug was exploitable using a maliciously crafted RDP message. The saving grace for some users is the use of Network Level Authentication (NLA), which when turned on requires authentication before an attacker can trigger an exploit. However, if the attacker has valid credentials, they could still mount the attack.
Patching devices is a particular problem in healthcare according to the CyberMDX report, which suggests some devices need specialised toolkits or skill sets when modifying their code. Regulations may also put hurdles in a healthcare company’s way when patching these devices.
Those aren’t the only reasons for poor patching, though. We can look to the UK National Audit Office’s investigation of WannaCry, another worm-based attack that bought the National Health service to its knees in 2017, for some answers. That document said that most affected systems were unpatched boxes still on support contracts.
There was no formal mechanism for checking that recommended patches had taken place when WannaCry hit, the document said. After the attack, it admitted that it needed a way to ensure that organisations acted on the alerts that NHS Digital was sending out, which included applying software patches. So enforcing best practice seems to be a problem for large healthcare bureaucracies.
Jon Rabinowitz, VP of marketing for CyberMDX, confirmed that visibility is an issue for hospitals:
Patching medical devices is a challenge hospitals constantly face. Many hospitals lack the necessary asset visibility to even centrally identify vulnerable devices. Some devices run multiple operating systems and most SIEMs will not be able to properly capture and communicate this information for IT/IS teams.
There’s also the matter of identifying the exact version of the OS running as well as noting what patches and updates have been installed across the device/software lifecycle. This requires a level of granularity that just doesn’t normally exist in the standard structure for hospital IT operations.
The NHS had developed a cybersecurity response plan following government warnings about the possibility of an attack but hadn’t yet implemented it, the NAO report added.
Latest Naked Security podcast
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/wGhEwriWtkU/