Thanks to the ongoing work at Lenovo for their platform support methods, I now have a better understanding of how a security product such as Computrace can survive drive wiping; to then reload itself on a reimaged system.
Lenovo used Windows anti-theft feature to install persistent crapware - Ars Technica. From Peter Bright’s article:
And in its own awful way, it's a feature that makes sense. The underlying mechanism is simple enough; the firmware constructs tables of system information when the machine boots. The operating system then examines these tables to, for example, learn what hardware is installed in the machine and how it is connected. This is all governed by a specification called ACPI, Advanced Configuration and Power Interface. Microsoft defined a new ACPI table, the Windows Platform Binary Table (WPBT), that contains information about a firmware-embedded executable. When it boots, Windows looks for a WPBT. If it finds one, it copies the executable onto the filesystem and runs it.
The primary purpose of WPBT is the automatic installation of anti-theft software. This kind of software typically does a couple of things that require online connectivity: it can phone home to check if it's been reported stolen (and brick or otherwise disable itself if it has), and it can phone home to simply report where it is to aid recovery of lost or stolen hardware.
It's reasonably common (though by no means universal) for stolen hardware to have its disk wiped, thereby removing any anti-theft software and limiting the chance of recovery. WPBT provides a solution: even if the disk is wiped and the operating system reinstalled, the firmware can re-establish the software and report that the laptop was stolen.
So to get up to speed, Lenovo used this feature in certain of their systems BIOS to ensure that their service engine software would “respawn” even if removed by the user. Couple this stealth persistence behavior along with some security issues in that software, you have the makings of a second hurricane landfall of security hurt upon Lenovo.
A Microsoft technical paper detailing the Windows Platform Binary Table (WPBT) can be found. Warning, the following link is a direct DOCX document direct link. Microsoft WPBT DOCX Link. As most of the articles about this paper only contain a link to document itself and not the context, here is a link to the Windows Hardware Dev Center Archive - Windows 10 hardware dev where the paper in question can be located under the Driver Archive section.
If you do have a Lenovo system using this root-kit like methodology, Lenovo has provided a removal tool.
- Lenovo LSE Windows Disabler Tool - Laptops - Lenovo Support (US)
Additional linkage on the topic
- Lenovo once again in hot waters over Lenovo Service Engine BIOS - gHacks Tech News
- Windows Platform Binary Table : sysadmin - Reddit
- Recent Lenovo BIOS rootkit bad enough, also exposes huge security hole to 3rd parties! - Foolish IT
- Lenovo used shady 'rootkit' tactic to quietly reinstall unwanted software - ZDNet
- Lenovo Service Engine (LSE) - Superfish Reloaded II - Borns IT and Windows Blog (GTranslation from German page)
- Lenovo BIOS tool prevents clean installs of Windows by downloading crapware - BetaNews
- Backdoor 'Windows Platform Binary Table' (WPBT) - Borns IT and Windows Blog (via Google Translation)
And previous Lenovo “SuperFish” issues:
- Noodling down in the Bayou for Superfish-like SSL Shenanigans - grandstreamdreams blog
- Lenovo Superfish – Cleanup in Seafood Isle Needed! - grandstreamdreams blog
Knowledge of this functionality support in Microsoft could give those looking to exploit a system another means to provide APT (advanced persistent threat) survivability.
Microsoft’s own WPBT paper (previously linked to above) addresses this threat in the “Security Considerations and Requirements” section.
The primary purpose of WPBT is to allow critical software to persist even when the operating system has changed or been reinstalled in a “clean” configuration. One use case for WPBT is to enable anti-theft software which is required to persist in case a device has been stolen, formatted, and reinstalled. In this scenario WPBT functionality provides the capability for the anti-theft software to reinstall itself into the operating system and continue to work as intended. This functionality is powerful and provides the capability for independent software vendors (ISV) and original equipment manufacturers (OEM) to have their solutions stick to the device indefinitely. Because this feature provides the ability to persistently execute system software in the context of Windows, it becomes critical that WPBT-based solutions are as secure as possible and do not expose Windows users to exploitable conditions. In particular, WPBT solutions must not include malware (i.e., malicious software or unwanted software installed without adequate user consent).
And Microsoft also offers a warning (of sorts). Take it as you will.
Removal of Malware
If partners intentionally or unintentionally introduce malware or unwanted software though the WPBT, Microsoft may remove such software through the use of antimalware software. Software that is determined to be malicious may be subject to immediate removal without notice.
Likewise, knowledge is power, so this can provide forensic security experts with one more area of a system to investigate for incident responses.
I’m sure there are some tools that might exist to examine the area on the BIOS where this specific code could be stored and extract it for analysis; if not then I’m confident they will be developed.
One utility for examining the code in BIOS that came to my mind immediately was RWEverything. I had encountered it before as a tool in extracting the Windows Key from Win 8/8.1 systems. It probably holds true for Win 10 keys as well. Also Nir Sofer’s FirmwareTablesView might help out with viewing the WPBT contents if supported and present.
Curious. Very curious.
Constant Vigilance!
Claus Valca
No comments:
Post a Comment