DeadUpdate; Or, How I learned to stop worrying and execute arbitrary executables from HTTP
… my first disclosure. Man, it feels weird doing this.
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 ([email protected] - 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:
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.
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:
So there we go, execution as NT AUTHORITY\SYSTEM because of a few HTTP calls.
This content is mirrored in a gist
2087
gracieabrams
jimmyeatworldofficial
gummygunk
