ASUS LiveUpdate of UEFI sent UNauthenticated

… my first disclosure. Man, it feels weird doing this.

update 6/6/16 I would like to stress something: I’m not saying “Don’t buy an ASUS device” — I see a lot of people who want to lambaste ASUS for this and boycott their hardware. This isn’t what I want people to be doing by any stretch. Stupidly, I like the ASUS hardware I have (it’s nice for the price) and I would rather see a pressure on ASUS as an OEM to stop shipping “value added software” to consumers; If you want to help Microsoft in pushing this mentality, go buy a signature machine from them. Microsoft provides support, but also only ships windows and a few select utilities that are essential to the functioning of the system (think: Radeon/Optimus and nVidia control panels) and fall heavily on the hardware makers (ATI, nVidia, Intel) to provide support for the harware.

Consider an ASUS device all you want. Start putting pressure on Microsoft that consumers want bloat-free devices and start voting with your money. Microsoft’s store has a nice selection which helps show that you value having a clean system more than ASUS does.

My advice to anyone who purchased an ASUS device: Remove LiveUpdate. It’s really that simple. If you’re an IT administrator, find devices making periodic calls to ASUS’s domains and blackhole them, get the user to come and see you.

From the vendor that brought you a
                        vulnerable cloud storage platform comes
                        
           ___              ____  __        __     __ 
          / _ \___ ___ ____/ / / / /__  ___/ /__ _/ /____ 
         / // / -_) _ `/ _  / /_/ / _ \/ _  / _ `/ __/ -_)
        /____/\__/\_,_/\_,_/\____/ .__/\_,_/\_,_/\__/\__/ 
         Because popping SYSTEM /_/ is easy when you trust HTTP

                        Or, "How I learned to stop worrying and
                       execute arbitrary executables from HTTP"

Affected software:          LiveUpdate (any version? 3.3.5 tested)
Vulnerability:              HTTP MITM to SYSTEM execution + more.
CVSS: est. 9.3 CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
   (N.B.: This assumes "Hijack some HTTP" is easy and you're local) 

Timeline:
	2016-04-27      Initial discovery
	2016-04-28      Attempt to contact vendor (security@asus.com - bounce)
	2016-04-28      Disclosure to MSFT MSRC attempting vendor coordination
	2016-05-09      Attempt to contact vendor (via phone; told to go away)
	2016-05-10      Disclosure to CERT/CC (tracked as VU#215055)
	2016-05-11      CERT/CC attempts to contact vendor
	2016-05-24      CERT/CC: No response from vendor
	2016-06-01      CERT/CC: Disclose at will
	2016-06-03      Public disclosure

ASUS is at it again. I was poking around in Fiddler and noticed my new laptop
made some interesting calls out to the web over plain http on a clockwork
schedule. Once I figured out what was going on, my response was pretty clear:

.

Ohhhh shit.

##TL;DR

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.

##THE DETAILS

ASUS ships windows computers with software called LiveUpdate, intended
to provide timely updates of software to users. There is no information
on how long this software has been in the wild, but I can speculate it’s been
since at least the XP days since I Can find BIOS udpates from 2004.

The ASUS LiveUpdate client makes requests over plain, unencrypted HTTP
to the ASUS update servers (liveupdate01.asus.com or dlcdnet.asus.com,
depending on version) and interprets them as XML files (or obfuscated XML)

So if you have a UX303UA device, the current generation of LiveUpdate will try each of the following until it gets a not 404:

• http://liveupdate01.asus.com/pub/ASUS/LiveUpdate/Release/Notebook/UX303UA.ide
• http://liveupdate01.asus.com/pub/ASUS/LiveUpdate/Release/Notebook/UX303UA.idx
• http://dlcdnet.asus.com/pub/ASUS/LiveUpdate/Release/Eee%20Book/UX303UA.ide
• http://dlcdnet.asus.com/pub/ASUS/LiveUpdate/Release/Eee%20Book/UX303UA.idx

These “.idx” files are rather complex, allowing for a variety of updates to be applied, including flashing the BIOS via WinFlash (if installed) and installing drivers. For example, here’s from an ET1602 laptop the entry for an updated ACPI driver:

<item name="ATK0110 ACPI Utility">
  <description l_id="1033" title="ATK0110 ACPI Utility">ATK0110 ACPI Utility</description>
  <description l_id="1028" title="ATK0110 ACPI Utility">ATK0110 ACPI Utility</description>
  <description l_id="2052" title="ATK0110 ACPI Utility">ATK0110 ACPI Utility</description>
  <type> driver </type>
  <hwid version="1043.2.15.37" date="08/13/2004"> ACPI\ATK0110 </hwid>
  <os> WinXP </os>
  <version> 1043.2.15.37 </version>
  <size> 837015 </size>
  <release-date> 1219104000 </release-date>
  <zip-path> pub/ASUS/DigitalHome/DAV/B202/ACPI_V104321537.zip </zip-path>
  <execute> .\AsusSetup.exe </execute>
  <index> 1 </index>
</item>

The neato part is that it can bootstrap itself! This looks to have been at one point called “ASUS Easy Update” and has been around since at least the XP days.

There’s a lot you can do. Remember what I was saying about the BIOS being flashable from this?

This isn’t going to be good…

<item name="BIOS 210">
  <description l_id="1033" title="BIOS 210">To solve the issue which charge speed will be slower when battery capacity is above 60%</description>
  <description l_id="1028" title="BIOS 210">解決當電池容量大於60%時，充電速度變慢的問題</description>
  <description l_id="2052" title="BIOS 210">解决当电池容量大于60%时，充电速度变慢的问题</description>
  <type> BIOS </type>
  <os></os>
  <version> 210 </version>
  <size> 2717731 </size>
  <release-date> 1422628620 </release-date>
  <zip-path> pub/ASUS/nb/X453MA/X453MAAS210.zip </zip-path>
  <execute> X453MAAS.210 </execute>
  <index> 1 </index>
</item>

There is no verification done of the authenticity of this XML file or
the items it points to.

In tandem with a convenient “run once an hour” scheduler task,
LiveUpdate makes repeated, noisy requests to the LiveUpdate HTTP
service. When “Critical” updates are returned, the default behavior is
to automatically install the updates.

This scheduler task is run as any user in the NT Administrators group
that the Task Scheduler deems high enough to be considered the most
privileges.

LiveUpdate pulls updates as ZIP archives, compressed however is
convenient. An executable specified in the index file will be executed
with whatever is useful.

Due to how the executable is launched, there is little chance of an
executable which is not authenticode signed from causing problems. This
executable is run under the user account that is associated with the
task scheduler task. For the purposes of the PoC presented,
SysInternals PSEXEC (authenticode signed) is used to escalate to NT
AUTHORITY\SYSTEM.

With a few fiddler intercepts, we can easily make the LiveUpdate application think we have a legitimate update.

Our fiddler AutoResponder rules:

Let’s push for the UX303UA a totally legitimate system update:

<product name="UX303UA">
  <item name="Garbage File">
    <description l_id="1033" title="Legitimate System Utility">Shoutout to Joey.</description>
    <type> AP </type>
    <os> Win10(64) </os>
    <version> 48 </version>
    <size> 199465 </size>
    <release-date> 1459468800 </release-date>
    <zip-path> pub/ASUS/nb/Apps/LiveUpdate/LiveUpdate.zip </zip-path>
    <execute> update.bat</execute>
    <index> 22 </index>
    <severity> 1 </severity>
    <assistant> SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{FA540E67-095C-4A1B-97BA-4D547DEC9AF4}\DisplayVersion </assistant>
  </item>
</product>

Our payload has a copy of psexec, a fancy whoami and a script to run them. Fiddler says the trap is working:

And we see that LiveUpdate thinks there is a critical update.

And, when LiveUpdate comes along to go “OMG CRITICAL UPDATE RUN IT NAO!!!” we get a little love letter:

Hmm..

…

So there we go, execution as NT AUTHORITY\SYSTEM because of a few HTTP calls.

This content is mirrored in a gist