Month: June 2021

Microsoft gave its digital imprimatur to a rootkit that decrypted encrypted communications and sent them to attacker-controlled servers, the company and outside researchers said.

The blunder allowed the malware to be installed on Windows machines without users receiving a security warning or needing to take additional steps. For the past 13 years, Microsoft has required third-party drivers and other code that runs in the Windows kernel to be tested and digitally signed by the OS maker to ensure stability and security. Without a Microsoft certificate, these types of programs can’t be installed by default.

Eavesdropping on SSL connections

Earlier this month, Karsten Hahn, a researcher at security firm G Data, found that his company’s malware detection system flagged a driver named Netfilter. He initially thought the detection was a false positive because Microsoft had digitally signed Netfilter under the company’s Windows Hardware Compatibility Program.

After further testing, Hahn determined that the detection wasn’t a false positive. He and fellow researchers decided to figure out precisely what the malware does.

“The core functionality seems to be eavesdropping on SSL connections,” reverse engineer Johann Aydinbas wrote on Twitter. “In addition to the IP redirecting component, it also installs (and protects) a root certificate to the registry.”

A rootkit is a type of malware that is written in a way that prevents it from being viewed in file directories, task monitors, and other standard OS functions. A root certificate is used to authenticate traffic sent through connections protected by the Transport Layer Security protocol, which encrypts data in transit and ensures the server to which a user is connected is genuine and not an imposter. Normally, TLS certificates are issued by a Windows-trusted certificate authority (or CA). By installing a root certificate in Windows itself, hackers can bypass the CA requirement.

Microsoft’s digital signature, along with the root certificate the malware installed, gave the malware stealth and the ability to send decrypted TLS traffic to hxxp://110.42.4.180:2081/s.

Serious security lapse

In a brief post from Friday, Microsoft wrote, “Microsoft is investigating a malicious actor distributing malicious drivers within gaming environments. The actor submitted drivers for certification through the Windows Hardware Compatibility Program. The drivers were built by a third party. We have suspended the account and reviewed their submissions for additional signs of malware.”

The post said that Microsoft has found no evidence that either its signing certificate for the Windows Hardware Compatibility Program or its WHCP signing infrastructure had been compromised. The company has since added Netfilter detections to the Windows Defender AV engine built into Windows and provided the detections to other AV providers. The company also suspended the account that submitted Netfilter and reviewed previous submissions for signs of additional malware.

Microsoft added:

The actor’s activity is limited to the gaming sector, specifically in China, and does not appear to target enterprise environments. We are not attributing this to a nation-state actor at this time. The actor’s goal is to use the driver to spoof their geo-location to cheat the system and play from anywhere. The malware enables them to gain an advantage in games and possibly exploit other players by compromising their accounts through common tools like keyloggers.

It’s important to understand that the techniques used in this attack occur post-exploitation, meaning an attacker must either have already gained administrative privileges in order to be able to run the installer to update the registry and install the malicious driver the next time the system boots or convince the user to do it on their behalf.

Despite the limitations the post noted, the lapse is serious. Microsoft’s certification program is designed to block precisely the kind of attack G Data first discovered. Microsoft has yet to say how it came to digitally sign the malware. Company representatives declined to provide an explanation.

Last week’s mass-wiping of Western Digital My Book Live storage devices involved the exploitation of not just one vulnerability but a second critical security bug that allowed hackers to remotely perform a factory reset without a password, an investigation shows.

The vulnerability is remarkable because it made it trivial to wipe what is likely petabytes of user data. More notable still was that, according to the vulnerable code itself, a Western Digital developer actively removed code that required a valid user password before allowing factory resets to proceed.

Done and undone

The undocumented vulnerability resided in a file aptly named system_factory_restore. It contains a PHP script that performs resets, allowing users to restore all default configurations and wipe all data stored on the devices.

Normally, and for good reason, factory resets require the person making the request to provide a user password. This authentication ensures that devices exposed to the Internet can only be reset by the legitimate owner and not by a malicious hacker.

As the following script shows, however, a Western Digital developer created five lines of code to password-protect the reset command. For unknown reasons, the authentication check was cancelled, or in developer parlance, it was commented out as indicated by the double / character at the beginning of each line.

function post($urlPath, $queryParams = null, $ouputFormat = 'xml') {
    // if(!authenticateAsOwner($queryParams))
    // 
    //      header("HTTP/1.0 401 Unauthorized");
    //      return;
    // 

“The vendor commenting out the authentication in the system restore endpoint really doesn’t make things look good for them,” HD Moore, a security expert and the CEO of network discovery platform Rumble, told Ars. “It’s like they intentionally enabled the bypass.”

To exploit the vulnerability, the attacker would have had to know the format of the XML request that triggers the reset. That’s “not quite as easy as hitting a random URL with a GET request, but [it’s] not that far off, either,” Moore said.

Dude, where’s my data?

The discovery of the second exploit comes five days after people all over the world reported that their My Book Live devices had been compromised and then factory-reset so that all stored data was wiped. My Book Live is a book-sized storage device that uses an Ethernet jack to connect to home and office networks so that connected computers have access to the data on it. Authorized users can also access their files and make configuration changes over the Internet. Western Digital stopped supporting the My Book Live in 2015.

Western Digital personnel posted an advisory following the mass wiping that said it resulted from attackers exploiting CVE-2018-18472. The remote command execution vulnerability was discovered in late 2018 by security researchers Paulos Yibelo and Daniel Eshetu. Because it came to light three years after Western Digital stopped supporting the My Book Live, the company never fixed it.

An analysis performed by Ars and Derek Abdine, CTO at security firm Censys, found that the devices hit by last week’s mass hack had also been subjected to attacks that exploited the unauthorized reset vulnerability. The additional exploit is documented in log files extracted from two hacked devices.

One of the logs was posted in the Western Digital support forum where the mass compromise first came to light. It shows someone from the IP address 94.102.49.104 successfully restoring a device:

rest_api.log.1:Jun 23 15:46:11 MyBookLiveDuo REST_API[9529]: 94.102.49.104 PARAMETER System_factory_restore POST : erase = none
rest_api.log.1:Jun 23 15:46:11 MyBookLiveDuo REST_API[9529]: 94.102.49.104 OUTPUT System_factory_restore POST SUCCESS

A second log file I obtained from a hacked My Book Live device showed a different IP address—23.154.177.131—exploiting the same vulnerability. Here are the telltale lines:

Jun 16 07:28:41 MyBookLive REST_API[28538]: 23.154.177.131 PARAMETER System_factory_restore POST : erase = format
Jun 16 07:28:42 MyBookLive REST_API[28538]: 23.154.177.131 OUTPUT System_factory_restore POST SUCCESS

After presenting these findings to Western Digital representatives, I received the following confirmation: “We can confirm that in at least some of the cases, the attackers exploited the command injection vulnerability (CVE-2018-18472), followed by the factory reset vulnerability. It’s not clear why the attackers exploited both vulnerabilities. We’ll request a CVE for the factory reset vulnerability and will update our bulletin to include this information.”

This vulnerability has been password-protected

The discovery raises a vexing question: if the hackers had already obtained full root access by exploiting CVE-2018-18472, what need did they have for this second security flaw? There’s no clear answer, but based on the evidence available, Abdine has come up with a plausible theory—that one hacker first exploited CVE-2018-18472 and a rival hacker later exploited the other vulnerability in an attempt to wrest control of those already compromised devices.

The attacker who exploited CVE-2018-18472 used the code execution capability it provided to modify a file in the My Book Live stack named language_configuration.php, which is where the vulnerability is located. According to a recovered file, the modification added the following lines:

function put($urlPath, $queryParams=null, $ouputFormat='xml'){

    parse_str(file_get_contents("php://input"), $changes);

    $langConfigObj = new LanguageConfiguration();
    if(!isset($changes["submit"]) || sha1($changes["submit"]) != "56f650e16801d38f47bb0eeac39e21a8142d7da1")
    
    die();
    

The change prevented anyone from exploiting the vulnerability without the password that corresponds to the cryptographic SHA1 hash 56f650e16801d38f47bb0eeac39e21a8142d7da1. It turns out that the password for this hash is p$EFx3tQWoUbFc%B%R$k@. The plaintext appears in the recovered log file here.

A separate modified language_configuration.php file recovered from a hacked device used a different password that corresponds to the hash 05951edd7f05318019c4cfafab8e567afe7936d4. The hackers used a third hash—b18c3795fd377b51b7925b2b68ff818cc9115a47—to password-protect a separate file named accessDenied.php. It was likely done as an insurance policy in the event that Western Digital released an update that patched language_configuration.

So far, attempts to crack these two other hashes haven’t succeeded.

According to Western Digital’s advisory linked above, some of the My Book Live devices hacked using CVE-2021-18472 were infected with malware called .nttpd,1-ppc-be-t1-z, which was written to run on the PowerPC hardware used by My Book Live devices. One user in the support forum reported a hacked My Book Live receiving this malware, which makes devices part of a botnet called Linux.Ngioweb.

A theory emerges

So why would someone who successfully wrangled so many My Book Live devices into a botnet turn around and wipe and reset them? And why would someone use an undocumented authentication bypass when they already have root access?

The most likely answer is that the mass wipe and reset was performed by a different attacker, very possibly a rival who either attempted to take control of the rival’s botnet or simply wanted to sabotage it.

“As for motive for POSTing to this [system_factory_restore] endpoint on a mass scale, it is unknown, but it could be an attempt at a rival botnet operator to take over these devices or render them useless, or someone who wanted to otherwise disrupt the botnet which has likely been around for some time, since these issues have existed since 2015,” Abdine wrote in a recent blog post.

The discovery of this second vulnerability means that My Book Live devices are even more insecure than most people thought. It adds authority to Western Digital’s recommendation to all users to disconnect their devices from the Internet. Anyone using one of these devices should heed the call immediately.

For many hacked users who lost years’ or decades’ worth of data, the thought of buying another Western Digital storage device is probably out of the question. Abdine, however, says that My Cloud Live devices, which replaced Western Digital’s My Book Live products, have a different codebase that doesn’t contain either of the vulnerabilities exploited in the recent mass wiping.

“I took a look at the My Cloud firmware, too,” he told me. “It’s rewritten and bears some, but mostly little, resemblance to My Book Live code. So it doesn’t share the same issues.”