ASUS releases diagnostic tool for Windows


[…]Additionally, we have created an online security diagnostic tool to check for affected systems, and we encourage users who are still concerned to run it as a precaution. The tool can be found:


ASUS Live Update Utility: security issues

A threat actor modified the ASUS Live Update Utility, which delivers BIOS, UEFI, and software updates to ASUS laptops and desktops, added a back door to the utility, and then distributed it to users through official channels.[…]

ASUS Live Update has been having some firmware security issues for a while, see:


2 possible ASUS UEFI malware issues?????

Two threads on ASUS issues that might be malicious, but will probably end up to be other kinds of defects. Sorry, no better summary of the issues:

ASUS doesn’t care about Linux [Firmware]

See image in below tweet. A tweet with a bug report about ACPI and TPM2 on ASUS systems.

Linux users: remember that you’re not using a Linux box, you’re using a Windows box, or a Chrome box, and reinstalling an OS, which the OEM doesn’t support, so they won’t be offering you any way to update your firmware with that OS. Unless you’re buying your machine from an OEM that installs Linux. If you are a Linux user, stop buying Windows/Chrome PCs and buy Linux PCs.

Alex at Black Hat: Where the Guardians of the BIOS Are Failing

Black Hat Vegas: Where the Guardians of the BIOS Are Failing
By Alex Matrosov
In our upcoming Black Hat Vegas talk, we will summarize our research about the UEFI firmware protections and our newly-discovered security problems. This talk raises awareness of these security challenges for hardware vendors, BIOS-level security researchers and defenders, and sophisticated stakeholders who want to know the current state of UEFI exposure and threats. The situation is serious but, with the right tools and knowledge, we can prevail.[…]

Intel AMT story, continued

A little bit more (warning: a few of these are related to Intel ME hardware, not Intel AMT firmware):

Rumor has it that OpenAMT can also be used for AMT detection:

AMT advisory from ASUS:

Is Intel’s Management Engine Broken?


Raptor Engineering seeks funds for OpenBMC port

Raptor Engineering is asking for crowdsource funding to help them port OpenBMC to an ASUS system:

“Make coreboot a first-class citizen in the datacenter on modern, blob-free hardware.”

ASUS UEFI Update Driver Physical Memory Read/Write

“A short while ago, slipstream/RoL dropped an exploit for the ASUS memory mapping driver (ASMMAP/ASMMAP64) which was vulnerable to complete physical memory access (read/write) to unprivileged users, allowing for local privilege escalation and all sorts of other problems. An aside to this was that there were also IOCTLs available to perform direct I/O operations (in/out instructions) directly from unprivileged usermode, which had additional interesting impacts for messing with system firmware without triggering AV heuristics.
In addition to the ASMMAP bugs, I also reported the exact same bugs in their UEFI update driver (AsUpIO.sys). This driver is deployed as part of the usermode UEFI update toolset, and exposes almost identical functionality which (as slipstream/RoL pointed out) is likely from an NT3.1 example driver that was written long before Microsoft took steps to segregate malicious users from physical memory in any meaningful way.”

ASUS LiveUpdate of UEFI sent UNauthenticated

[UPDATE: strangely renders parts of the content from Morgan’s blog and hides the URL I put. Alternative URLs provided below.]

Morgan Gangwere posts an article about ASUS, it appears that ASUS’s UEFI updates are not authenticated:

ASUS’ LiveUpdate software is preinstalled on computers shipped by ASUS. It is responsible for delivering updates, new versions of the BIOS/UEFI Firmware and executables for use with ASUS software. Content is delivered via ZIP archives over plain HTTP, extracted into a temporary directory and an executable run as a user in the “Administrators” NT group (“Highest Permissions” task scheduler). There is no verification or authentication of source or content at any point in this process, allowing trivial escalation to NT AUTHORITY\SYSTEM.

Remove the SPACE in these URLs to make them work:
http://teletext /post/145370716258/deadupdate-or-how-i-learned-to-stop-worrying-and

US-CERT vulnerability note on DSL routers

US-CERT has issued a Vulnerability Note (VU#950576) for some DSL routers, excerpted below, see US-CERT note for full details:

DSL routers contain hard-coded “XXXXairocon” credentials

DSL routers by ASUS, DIGICOM, Observa Telecom, Philippine Long Distance Telephone (PLDT), and ZTE contain hard-coded “XXXXairocon” credentials

CWE-798: Use of Hard-coded Credentials

DSL routers, including the ASUS DSL-N12E, DIGICOM DG-5524T, Observa Telecom RTA01N, Philippine Long Distance Telephone (PLDT) SpeedSurf 504AN, and ZTE ZXV10 W300 contain hard-coded credentials that are useable in the telnet service on the device. In the ASUS, DIGICOM, Observa Telecom, and ZTE devices, the username is “admin,” in the PLDT device, the user name is “adminpldt,” and in all affected devices, the password is “XXXXairocon” where “XXXX” is the last four characters of the device’s MAC address. The MAC address may be obtainable over SNMP with community string public. The vulnerability was previously disclosed in VU#228886 and assigned CVE-2014-0329 for ZTE ZXV10 W300, but it was not known at the time that the same vulnerability affected products published by other vendors. The Observa Telecom RTA01N was previously disclosed on the Full Disclosure mailing list.

Impact: A remote attacker may utilize these credentials to gain administrator access to the device.

Solution: The CERT/CC is currently unaware of a practical solution to this problem and recommends the following workaround: Restrict access: Enable firewall rules so the telnet service of the device is not accessible to untrusted sources. Enable firewall rules that block SNMP on the device.

Vendors impacted include: AsusTek, DIGICOM, Observa Telecom, Philippine Long Distance Telephone, and ZTE Corporation.

See CERT VU for full information:

Hacking Team had other bootkits

Vlad Tsyrklevich wrote an excellent aritcle on the 0-day market via analyzing the Wikileak’ed Hacking Team emails:

Most have already read about the UEFI malware that it used, including this Intel ATR analysis:

Beyond this UEFI malware, Vlad’s analysis of the Wikileaks email revealed at least 2 other firmware exploits that Hacker Team appeared to have been using:

08/19/13,  ASUS BIOS device driver LPE, Firefox RCE added

02/24/14, “Apple iOS Remote Forced Access-Point Association”/“Apple iOS Remote Forced Firmware Update Avoidance” no longer available, OpenPAM (used on BSDs) LPE added

See Vlad’s blog for pointers to other email articles on these two entries.

I wish there was a list of former 0-days, at least the firmware subset… I also wish there was a safe place to download the “” and “Z5WE1X64.fd” files listed in the Intel ATR blog.