Core Security CTO Ivan Arce responds to claims by Absolute Software that the research published by our CoreLabs experts at the Black Hat USA 2009 conference was not accurate, and that they weren't given a sufficient chance to respond to the findings prior to the given presentation.
It’s been over a week since the Black Hat USA 2009 conference in Las Vegas concluded but it seems that the dust has not settled over the talk given by Alfredo Ortega and Anibal Sacco at the show about their findings in Absolute Software’s Computrace “persistent agent” as part of their ongoing research on BIOS rootkits. For starters, Alfredo and Anibal had initially planned to give several live demonstrations to help corroborate their findings on real systems in front of the audience at Black Hat, but unfortunately they had to change plans when the presentation (.PDF) was scheduled as a turbo talk with a maximum duration of 20 minutes.
To make matters more confusing, Absolute Software, the involved vendor, wasn’t very responsive prior to the presentation and instead decided to address the report by issuing a press release after the research was released at Black Hat. This delayed PR damage-control response by Absolute seems to have been written following the guidelines of a playbook from a few decades back: “Admit Nothing, Deny Everything, and Make Counter Accusations!” Frankly, these statements – written using baseless language that avoids discussion of the actual findings described at the conference and in the corresponding paper – aren’t very surprising when you consider that they are coming from a software vendor that has now addressed publicly reported security flaws in its products by issuing a dismissive press release – rather offering technical facts to the contrary, patching the problem, or offering any firmware updates fixing the issue. This response might also be interpreted as a telltale sign of the maturity of the vendor’s overall secure development practices. Some other software vendors may have offered the same type of reaction a decade or two ago, and sadly, some others still do…
Nonetheless, the company’s PR denial has muddled understanding of the research, and the entire process that went into reporting it quite a bit, and prompted speculation, doubt and some questions about the Black Hat presentation (PDF) from general and specialized media, as well as from info-sec practitioners. So I figured it would be good to clarify a few things in a blog post and to provide further detail all around. . Before I dig into some technicalities of the findings of Alfredo and Anibal, let me dispel any doubts about the disclosure process that we followed. The vendor was made aware of the report and upcoming presentation several weeks prior to Black Hat by at least three separate sources. Since this issue affected multiple device manufacturers, some of whom for which we had no point-of-contact information for security matters, Core made sure that it first notified CERT/CC, US-CERT and a major computer manufacturer affected by the issue, and ensured that CERT/CC and the device manufacturer had attempted to contact the vendor, just as we had. It is also important to note that the complete description of the vendor’s software including the functionality involved in the CoreLabs research has been available for public review for at least 5 years in one of the vendor’s published patent applications – so the affected feature’s existence and some ways to manipulate it weren’t actually that much of a secret. Incidentally, the patent application provides several paragraphs that help the reader understand the nature of the software pretty clearly:
 The persistent Agent is a low-level undetectable software client that resides on the host computer. The Agent is persistent software and extremely difficult to remove. The Agent incorporates self-healing technology that functions to rebuild the agent software installation even if the agent service is deleted by conventional means. The agent will survive an operating system installation, hard drive format, and even a hard drive replacement. This survivability is critical to the success of asset tracking and theft recovery (and other services that the Agent may also enable, support and/or provide). The self-healing function is not resident within the file system and is more difficult to detect and remove than traditional software. The persistent and self-healing portion of the software is difficult to remove because it is stealthy. The software is normally removed only by an authorized IT administrator with the correct password. The self-healing feature will function to repair an Agent installation in newly formatted and installed operating systems as well as newly imaged systems.
 In another aspect of the present invention, the Agent is programmable to extend its functions beyond what was initially programmed. The Agent communicates with a remoter server, wherein the remoter server sends and programs the Agent by providing the Agent with instructions for next set of tasks. Claim #1 of the patent application is clear as well: What is claimed is:
1. A persistent servicing agent disposed in an electronic device connected to a network to a remote server, to enable, support and/or provide at least one service with respect to the electronic device, comprising: - A driver agent concealed in the electronic device, wherein the driver agent is configured to be persistent against external tampering, including self-healing in the event of tampering; and - A run module configured to automatically initiate operation of the driver agent without user initiation or user intervention. Any experienced info-sec practitioner would likely read Claim #1 and paragraphs 0059, 0060 above and match them perfectly to the very definition of a rootkit. Really, there isn’t much to debate about it. The “persistent agent” is indeed a rootkit, but a legitimate one allegedly designed for a good purpose (asset tracking and theft recovery). However, that may not be immediately evident for any security researcher that happens to stumble upon it when inspecting the BIOS firmware embedded in his or her own computer. Surprise may rapidly turn into paranoia when said discovered firmware, for which there may not exist any configurable settings in the BIOS configuration UI, is found to be an Option ROM module packed with UPX – an executable file compressor commonly used by not very sophisticated malware – that prior to booting the Operating System appears to: -Mount any Windows OS root file system of the attached hard disk. -Install a suspiciously-named service that has no description nor documentation. -Subsequently modify the OS auto-repair feature to prevent its removal. Finding out that the deployed service tries to initiate an outbound TCP connection to a nondescript Web site might finally throw a security researcher into an obsessive conspiracy-theory binge.
Alfredo and Anibal found all of the above (the hard way) on their personal and work-related laptops and on many of their co-worker’s computers – brands and models corresponding to regular off-the-shelf computers that are commonly found in the market- but luckily they didn’t succumb to black helicopter syndrome nor start talking about cattle mutilation cover ups or techno-occultism witchcraft. Rather, they discussed and documented their findings and eventually determined that it was the Computrace “persistent agent.” In sum they found that: -The persistent agent is embedded in BIOS firmware and may be present even if there isn’t any option to enable/disabled or otherwise manage it in the BIOS configuration UI. -The code is an Option ROM and gets executed in BIOS context when a specific device ID is detected although there seem to be other ways to run it depending on the computer’s brand and model. -Upon execution the persistent agent unpacks itself and runs another piece of code that looks for and mounts a root Windows file system on the attached hard disk then drops a PE executable (rpcnet.exe or rpcnetp.exe) in the Windows OS system folder. The BIOS-embedded code has its own small NTFS/FAT file system driver and can deal with BitLocked file systems. -The agent modifies the Windows repair mechanism to prevent the executable from being deleted. -The PE executable is registered as a Windows service named “Remote Procedure Call (RPC) Net” that is automatically started upon OS boot running with SYSTEM privileges. It shows up with no description in the Services Management Console. -Several anti-virus programs do not recognize this executable as malware. -The service regularly attempts to connect to a webserver at search.namequery.com, the domain name is registered by Absolute Software (bingo!) The legitimate purpose of the rootkit can now be established, however, it is clear that its very nature makes it a potential security hazard, should it be found prone to design or implementation flaws that make it likely to be turned into a malicious rootkit by any interested party. This very reality is proven to be possible due to further findings that:
- The Windows service makes its outbound connection in plaintext over HTTP.
- The hostname to connect to is extracted from a Windows registry key whose value is “encrypted” with an XOR obfuscation scheme and thus is trivial to change.
- Figuring out the obfuscation is just elegant but not that relevant because one can redirect the outbound HTTP connection by making the legitimate hostname point to a different IP address in the lmhosts file, the DNS server or by proxying the connection to a different site.
- A more devious attacker could change the hostname and port configuration that is persistent in the BIOS since it is protected by a single-byte XOR mechanism. However, this would require the risky step of re-flashing the BIOS which if it fails may render the computer unusable.
- Not just the configuration could be changed and rewritten in BIOS but in fact the whole Computrace Option ROM could be dumped, unpacked, modified, repacked and re-flashed on any BIOS that does not enforce cryptographically signed updates.
The Computrace Option ROM does not seem to have any meaningful mechanism to prevent tampering and just relies on its host’s BIOS security to do so. -On some computers where there isn’t enough space to host the full agent in BIOS firmware a variation may be found that loads agent code by reading it from the Host Protected Area off the hard disk and running them in BIOS context prior to booting the OS. -On some computers the BIOS configuration option to enable or disable the agent permanently it is possible to reset the permanent setting. Fortunately and in lieu of an official fix for the above problems, we suggest that you use the same weaknesses for the legitimate purpose of mitigating the risk posed by this pre-installed rootkit embedded in BIOS. How you say? Here’s how: -You can determine whether you have the agent in your BIOS or not by dumping the firmware and searching for Computrace’s signature using this Python program from Alfredo and Anibal.
CAVEAT: The program must be run on Linux since it relies on three Linux-based tools and may not work successfully on some motherboards and chipsets. Failed execution will NOT damage your computer.
-Once you’ve dumped your BIOS code you can derive a digital signature using a cryptographically strong hash function and then store it securely for comparison against the same computer’s BIOS to be dumped anytime in the future in order to identify any unexpected changes. -Once activated, you can redirect the outbound connection made by the Windows agent to a web server of your own and build a homebrewed “asset monitoring and tracking” mechanism. Afterwards, should a computer fail to report to your monitoring system it would be suspected of having its agent tampered-with, redirected or removed (or the computer to have gone missing or been re-installed). -Now that you know what to look for, you can configure your endpoint security solution to detect and alert on execution of the Windows based agent. -If you are a more daring individual you may try to dump the BIOS-embedded agent and alter it in a way that renders it both innocuous and detectable by AV, re-pack it and re-flash the BIOS.
CAVEAT: This WILL render your computer unusable if it is done incorrectly.
As a final note, it is worth pointing out that in addition to this and previous research work done by Alfredo and Anibal, more research efforts on BIOS insecurity and exploitation have been presented by other organizations at infosec conferences during the past few years. The combined effect of all these works indicates that the various forms of firmware embedded in commercial off-the-shelf computers, including BIOS firmware, is not immune to software security flaws and that it should be developed and scrutinized at least with the same level of care devoted to operating system and application software security. And with that, I will conclude this overly long blog post at this point.