Pwning Electroencephalogram (EEG) Medical Devices by Default

Overall Analysis of Vulnerability Identification – Default Credentials Leading to Remote Code Execution

During internal network testing, a document was discovered titled the “XL Security Site Administrator Reference.pdf.” It appeared to be a guide for the specific configuration of the SQL service running on NeuroWorks Natus. Being that this was a guide, it was extensive and detailed the software in-depth.

Searching “NeuroWorks Natus” online brought up the following website:

Natus^® NeuroWorks^® EEG Software

https://natus.com/products-services/natus-neuroworks-eeg-software

Overall, the software description describes it as a platform that “simplifies the process of collecting, monitoring, trending and managing data for routine EEG testing, ambulatory EEG, long-term monitoring, ICU monitoring, and research studies. NeuroWorks systems are scalable to meet the needs of private practice clinics, hospitals, large teaching facilities and EEG service providers. Natus NeuroWorks is a cutting-edge, single solution for EEG, LTM, ICU, Sleep, and Research Studies, exhibiting an advanced software for clinical excellence.” Additionally, the description highlights some key features of the software.

Figure 1. Key features description summary for Natus NeuroWorks EEG Software

The reality was simple, the software contains a wide array of usage as a baseline for ingesting and managing data collected by various electroencephalogram (EEG) equipment. In addition, the description also states that “The Microsoft SQL-based NeuroWorks database is a powerful tool that simplifies the management of patient, study and laboratory data….”

In short, the software utilizes MSSQL.

Figure 2. Patient connected to EEG equipment, Image Credit: Adobe Stock - romaset

The configuration of the system administrator for the database caught my attention while reading the administration guide further.

Figure 3. XL Security site administrator guide, description of credential usage

There were a few things to note in this section of the guide.

1. NeuroWorks Natus EEG Software sets up a local MSSQL server on the operating system.
2. The MSSQL instance is set up with a default username of ‘sa’ and default password of ‘xltek’.
3. NeuroWorks strongly recommends using the default password for the local SQL server instances.
4. The password is only utilized while creating or modifying databases and/or database tables.
5. MigrateDB is called silently when a new virtual database is created through Natus Database XLDB, and in this case, if the password has been changed, any creation of virtual servers or new database resources will fail.
6. The limitation can be overcome by temporarily altering the password for the system administrator back to the default ‘xltek’ and then setting it back to a stronger password after creating resources.

Normally, default credentials configured with software or hardware aren’t necessarily considered a zero day vulnerability. On paper, one could argue that default credentials “are” a zero day, but this would only apply if the credentials were hardcoded in a way that couldn’t be changed. If a user can rotate credentials, the vulnerability severity is decreased significantly, and is questionable as a legitimate vulnerability in general. In the instance of Neuroworks’ Natus EEG Software, there’s a notable issue at play. First and foremost, the vendor strongly recommends that the credentials packaged with the software remain default.

 Why would this be recommended? Is this a vulnerability?

Well, for non-technical users, and even many technical users, the next section of this text block attempts to dissuade from changing the password, and even downplays the necessity of changing the MSSQL system administration password by using language such as:

“This password is seldom used by Neuroworks, it’s only used while…” and “If the password has been altered, the creation of a new virtual server will fail” (including the modification of tables or database resources as stated in the previous portion of this text).

The other concerning portion of the text is that liability is transferred to the user by acknowledging that this is indeed an issue, but offers an unrealistic workaround that most standard users are not going to take:

“One way to overcome this limitation is to temporarily alter the password for the database user ‘xltek’ to its default ‘xltek’ and then set it back after creating the virtual database.”

Simply put, if the administrator wants to alter or create database resources, the default password needs to be used or it will fail. NeuroWorks acknowledges this as an issue and states to change a strong, new password back to the weak, default password in the instance changes are needed. The language in the beginning portion of the text strongly recommends keeping the default password as it’s “seldom” used. This may be true from an administrator’s perspective, but a threat actor would have an entirely different perspective.

Exploitation of Systems with NeuroWorks Natus EEG Software

It seems that the description of how MSSQL credentials are managed by NeuroWorks indicated that there was a high probability of systems in the environment with misconfigured EEG software that would help a threat actor achieve remote code execution. For the sake of client privacy, the enumeration methodology or hostnames will not be described. Utilizing your imagination and a little bit of CrackMapExec, I assure you that the systems can be discovered. For the sake of this writeup the actual hostname was replaced with EEGHOST.

With several systems discovered, CrackMapExec made it trivial to obtain remote code execution (RCE) on the affected host machine. We knew from the description of the user that the service would have locally configured ‘sa’ user with the password ‘xltek’. Still, the service was only exposed on the local company network, so traffic had to be proxied through another compromised host in conjunction with proxychains.

The severity was chilling. Trivial remote code execution on a medical device via default credentials was likely because of vendor recommendations. This same command was run on several separate Windows machines with the same success.

Simple remote code execution wasn’t enough. How easily could a threat actor drop a Command and Control (C2) beacon and utilize a Windows device with NeuroWorks Natus EEG Software?

What’s displayed above is a simple set of commands. First, the Cobalt Strike beacon is uploaded to a new folder in ‘Temp’ named ‘Events’. This is primarily because as the user ‘nt authority\network service’, the limitations of binary write, and execution are significant. Then, the ‘dir’ command is utilized to ensure the beacon wasn’t detected at rest (static detection) and quarantined. Lastly, cmd.exe in conjunction with the /c switch for command and start, with the full path to the binary, is executed to start the binary and establish a callback to the Cobalt Strike server.

Figure 4. Cobalt Strike beacon from the Windows 10 machine to our C2 Server

It’s important to note that a simple process listing reveals no antivirus or endpoint detection response tooling, which is more common on medical devices than blue teamers like to admit (and is usually a business unit issue that will take many hours to debate).

Surely this isn’t the end. As the current user, being restricted to a local user and a low privileged one, is a bummer. Pivoting the network is the name of the game, thus, PowerUp.ps1 is utilized to discover misconfigurations. The best scenario was that there was a way to become a local admin or NT AUTHORITY\System to dump possible domain users for pivoting. As seen in the above process list, a domain user was active on the system (represented with a replacement EXAMPLEDOMAIN\example_adminuser) for privacy.

Within moments, registry autologon credentials are discovered for a domain user. The domain user also maintained local administrator privileges. Pivoting to another system would now be possible since this user likely had access to some of the other identified machines from earlier enumeration.

Once the beacon was established, the same situation occurred. This new EEG host did not have antivirus and endpoint detection response software and was not discovered. This host appeared to have more instances of user activity, thus, with local administrative privilege on this host as well – credentials were dumped.

At this point, access to two new users was acquired, and other host machines were identified via corresponding logon servers. Pivoting further would undoubtedly be possible, and that’s exactly what the next move was. Repeating the Cobalt Strike jump command afforded access to these hosts. For the sake of not repeating the same steps, this is where the journey ends.

Key Takeaways

• Default credentials, while written off as the vendor in this case as seldom used and unnecessary to change, can lead to the exploitation of active directory environments.
• The way NeuroWorks configures their EEG Software initially leads to a high likelihood of out-of-the box remote code execution.
• If an administrator changes the default password, the software will not function properly, thus the vendor recommends not changing the default password.
• Multiple host machines with the EEG software installed suffered from this vulnerability, allowing an emulated threat actor to obtain remote code execution on each host machine as a local user, and privilege escalate to obtain domain user credentials.
• Depending on the environment, domain users who login to these machines could potentially have their credentials stolen, and with specifically assigned domain permissions – lead to a much larger compromise in the active directory network.
• There’s a high probability of operating systems with Neuroworks Natus EEG Software installed lacking antivirus or endpoint detection response measures, making it a valuable target for threat actors to gain a foothold while trying to maintain network persistence.

Vendor Response and Remediation

The vendor has revised the Administrator Reference document by discontinuing the endorsement of default password usage. Instead, the vendor strongly recommends that all users change default SQL credentials. This requires to update the software to leverage the Credentials Cache feature, introduced in version 8.4 GMA3. The technical service team will provide the revised documentation to customers on request, and in the future, it will be integrated into the Neuroworks software installation package.

The vendor has additionally released a security advisory regarding this threat. You can access the security bulletin at this link: https://natus.bynder.com/m/7cd3bcca88e446d4/original/NeuroWorks-SleepWorks-Product-Security-Bulletin.pdf

Communication Timeline

06/27/2023 - Trustwave disclosed vulnerability to vendor
07/07/2023 - Vendor provides Trustwave with preliminary version of the updated documentation
07/18/2023 - Vendor has provided Trustwave with remediation plan
10/20/2023 - Vendor publishes security bulletin

SpiderLabs Recommendation

NeuroWorks should release an official patch that allows backwards compatibility for the MSSQL version to implement integrated security (Windows authentication) for connecting to the database. This eliminates the need for a locally privileged password altogether and allows users to connect based on active directory permissions that affords them access the service. The possible risk of allowing this is that it requires domain trust, but the reality is that database servers will be more likely to have endpoint detection response protection. A bad actor would have to exploit a domain user with those specific permissions instead of having the ability to execute code on the host machines by default through the MSSQL service.