Tag Archives: driver

Asus and Gigabyte Software Flaws Unresolved

Update: 31st January 2019
In a follow up to this post; I realized that software installed within my Windows 10 Pro for Workstations system (Version 1803) may be vulnerable to similar issues as the Asus and Gigabyte software.

The software; Creative Sound Blaster Connect for Windows v2.0.0.28)(June 2018) is installed on my system and controls (among other features) the LED lights of my dedicated sound card Sound BlasterX AE-5 Pure edition. The lights are installed on the card and via an extended magnetic chain of 40 LED lights.

This software has the ability to connect to the internet in order to install updates from Creative. In an effort to check if this functionality could be abused to access the software; I took the basic steps of scanning the ports listed within the attached document using Nmap (using another system located on my local network (LAN)). I also checked if these ports were accessible via the internet from outside of my network by probing specific ports (User Specified Custom Port Probe) using the free ShieldsUp service from Grc.com):

The Nmap scans were only the following basic scans:

TCP Connect Scan:
nmap -sT
Stealth Scan (TCP SYN Scan):
nmap -sS
UDP Scan (where applicable):
nmap -sA

The results were; none of the ports were accessible via my local network or via the internet thanks to the software firewall (bundled with my anti-malware software). The firewall gracefully handled each scan and blocked it while only logging the event rather than displaying a notification.

To further harden the Creative software from possible attack I chose to enable Microsoft’s Windows Defender Exploit Guard. I have attached a table (see link “Creative Processes and Ports” below) of the necessary running processes of the Creative software and which of the memory protections I was able to turn on; in short almost all of them. Windows Defender Exploit Guard is the successor to EMET (originally made available by Microsoft in 2010. Support ended for EMET on the 31st July 2018:

Since my Windows 10 system is fully up to date and I don’t link on links within emails or open suspicious attachments (in addition to using application white listing). Moreover; the software can’t be accessed via the internet or via my local network and now has many layers of in memory defenses enabled the likelihood of any vulnerabilities within the Creative software being exploited is minimized. If a rogue update is downloaded via the internet; it can’t run since only updates digitally signed by Creative are enabled to run (due to the whitelisting mentioned earlier).

While all of the above may be considered an “overreaction”; while exploits against such software are still yet to be seen in the wild; it never hurts to be prepared for the future. In addition, I don’t wish for the seemingly innocuous technology of LED lights being used to compromise my system.

Thank you.

Creative Processes and Ports

Original Post:
In mid-December security researchers from SecureAuth disclosed local elevation of privilege and code execution vulnerabilities within software and drivers (defined) from hardware vendors Asus and Gigabyte.

What is the severity and impact of these vulnerabilities?
ASUS Aura Sync v1.07.22 and previous versions:
For the Asus Aura Sync software; two vulnerable drivers are installed and have the potential to allow local code execution by an attacker.

There are three vulnerabilities within this software:

CVE-2018-18535: affects the Asusgio driver by leaving an exposed read/write method available for model specific registers (MSRs)(defined). This weakness can be leveraged to execute arbitrary code with System level (defined)(ring 0) privileges. Diego Juarez, the security researcher who discovered these vulnerabilities; created proof of concept code to allow insecure access to the MSRs via a stray kernel (defined) function pointer (defined) allowing the bypass of kernel address space layout randomization (KASLR)(defined) which results in a denial of service (DoS) condition in the form of a Blue Screen of Death (BSoD). This would have medium to high impact depending on the criticality of the system that is rendered temporarily unavailable by the BSoD.

CVE-2018-18536: the proof of concept for this vulnerability results in the system rebooting. This was achieved by utilizing the ability to read and write data to IO ports using the GLCKIo and Asusgion drivers. This ability can be used to run code of your choice with elevated privileges. This would have a high to critical severity since any code of the attackers choice could be leveraged for a purpose of their choosing.

CVE-2018-18537: can be used to trigger a system crash. This is achieved by writing 32 bits of data (DWORD)(explanation) to an address of an attackers choice. This can corrupt data and lead to unexpected behavior such as a crash. This would have a low to high depending upon the type of data that became corrupted.

Gigabyte App Center v1.05.21 and previous
Aorus Graphics Engine v1.33 and previous
Xtreme Gaming Engine v1.25 and previous
OC Guru II v2.08
CVE-2018-19320: has the potential to grant the attacker full access to the affected system and is thus medium to high in severity. The proof of concept for this is the same as for CVE-2018-18537 (above). CVE-2018-19322 is very similar to CVE-2018-18636 described above. CVE-2018-19323 is again very similar to CVE-2018-18535 already described above.

Finally CVE-2018-19321 could place an attacker in complete control of the victim system upon exploiting drivers within the Gigabyte App Center; Aorus Graphics Engine, Xtreme Gaming Engine or OC Guru (version numbers listed above). The proof of concept provided crashed the system but would be of medium to high severity due to the potential for further malicious action.

How can I protect my organization or myself from these vulnerabilities?
As per the Asus and Gigabyte advisories; only Asus fixed one of the disclosed vulnerabilities. If you use any of the above affected software, please update it to the most recent version available. In addition; exercise standard caution regarding handling emails, email attachments and the clicking of links (no matter in what form you receive such links). These vulnerabilities are all locally exploitable and thus require you to take an action out of the ordinary to harm your system.

The fact that neither company responded effectively is a concern; especially given how widely used these software applications are across the many hardware products both vendors sell to organisations and individuals.

The relevant advisories from SecureAuth are linked to here (Asus) and here (Gigabyte).

Why am I highlighting the vulnerabilities in these software packages?
I am highlighting these vulnerabilities since they re-demonstrate that any software installed on a system can contain vulnerabilities not just internet facing or widely used applications (making these Asus and Gigabyte applications a lot less likely to be updated by end-users). While this software may be considered innocuous (since it does not directly access the internet (except in the case to check for updates)) and is not used to open files/documents; given the low-level drivers the software uses; they still have the potential to provide an attacker with a means for malicious action.

I am aware of the availability of the Asus Aura Sync software since it is offered as a download for my Asus Rampage VI motherboard. I have not installed it since the motherboard LEDs already work (due to the UEFI firmware controlling them) to my satisfaction without software. Thus I chose not to install the software since I didn’t need it. While my system isn’t affected since the Asus software is not installed; it’s a concern that widely used applications are not being patched.

While I can acknowledge Gigabyte stating it is a hardware company; clearly the drivers and software it distributes to use and optimize/customize those products requires some maintenance from time to time; especially in the case where a vulnerability notification is provided. While Asus resolved one vulnerability it did not resolve the remaining two even when it too was provided with the necessary technical details.

Thank you.

APT28 Group Distributes First in the Wild UEFI Rootkit

Update: 6th February 2019
In mid-January, the IT news website; The Register provided details of an analysis of this threat from the security firm Netscout. They concluded that they believe the malware utilising the UEFI rootkit began as long as 2 years ago:

In addition; the command and control (C2) (defined) infrastructure originating from this threat remains operational but has reduced from 7 servers to 2. The attackers also have further servers and reserved IP addresses ready to use should they need to.

Thank you.

Original Post:
In late September; researchers from the security/anti-malware firm Eset discovered the first UEFI (defined) rootkit (defined) being used in the wild (namely being present on computing devices used by the general public in their professional and personal lives).

The APT group known as APT28 (who we discussed before on this blog) has been named as being responsible for this advanced threat being distributed to victim systems located in the Central Europe, Eastern Europe and the Balkans.

Why should this threat be considered important?
While this threat is so far limited to targeting systems in Central Europe, Eastern Europe and the Balkans; it has the potential to set a precedent to dramatically increase the persistence of malware on selected systems. This is due to the fact that to save time malware removal usually involves re-installing the operating system. More advanced users may choose to re-create the MBR/GPT, replace the boot sector and rebuild the BCD. Even more informed users may replace the hard disk to remove the malware. This new threat is significant since all of these steps would not remove it.

Eset researchers discovered that the LoJack anti-theft software which was installed compromised systems was being leveraged to start the attacker’s malware instead by using the Windows registry (defined) to load files with very similar names to that of the legitimate LoJack software. They also located a kernel (defined) driver (defined) being used to write the systems firmware when required. Since this tool was a legitimate tool; it has a valid digital signature. This is significant; otherwise the attacker’s tool would not have worked on a 64 bit Windows system. Should attempts to write to the firmware fail, the malware uses a 4 year old vulnerability CVE-2014-8273 (a race condition (defined)) to bypass the write lock.

Once the firmware has been updated it replaces the original LoJack software files with hijacked versions designed to enable further persistence on the compromised systems, namely a backdoor (defined).

How can I protect myself against this threat?
While it is less likely a threat of this sophistication will become widespread; the steps below will help to defend you against this and similar threats in the future. How this threat establishes an initial foothold on a system was inconclusive by Eset. However exercising caution on the links you click in emails, IMs and social networking should provide some form of prevention. Keeping your system up to date should also prevent a drive by download (defined). However I will detail more specific defensive steps below:

Eset determined that this threat can be prevented from affecting a system by enabling the Secure Boot hardware security feature (if your system has this feature available; most systems manufactured from 2012 onwards do). Any system with a certified Windows 8 or Windows 10 badge on the outside will have Secure Boot enabled with no action required from you. Secure Boot works even better when paired with Intel BootGuard (corporate users are more likely to use/enable this feature).

If the rootkit had affected the system described above it would have then refused to boot due to Secure Boot being enabled. It’s important to clarify that Secure Boot won’t prevent the infection/tampering but it will prevent that tampering from starting the system for use as normal.

Secure Boot was added to Windows 8.0 in 2012 to prevent unsigned components (e.g. rootkits) from affecting a system so early in the boot process that anti-malware software would be unable to detect or prevent that component from obtaining a privileged level of access over the system.


Keeping the UEFI firmware of your system up to date will assist with resolving known vulnerabilities within the firmware. Patching known firmware vulnerabilities makes your system less vulnerable to low level attacks such as this. Please only install UEFI firmware updates from your system vendor. Check the vendor’s website or contact them to determine if you need a UEFI firmware update and how to install it. If possible/available verify the checksum (defined) of the file you download matches the vendors provided checksum. I use the word available above since not all vendors provide checksums of the firmware updates they distribute which would allow you to verify them.

More recent Intel motherboards (defined) are not vulnerable to the race condition by Eset in their paper (more details available here). These modern chipsets feature a Platform Controller Hub (present in Intel’s Series 5 chipsets and later (available circa 2010 onwards).

If you know of a system affected with such a low level threat you may be able to update the UEFI firmware with a known safe version from the vendor but this is not guaranteed to work. Replacing the hardware will be a more reliable alternative.

Thank you.

WPA2 KRACK Vulnerability: What you need to know

Last Sunday, the early signs of a vulnerability disclosure affecting the extensively used Wi-Fi protected access (WPA2) protocol were evident. The next day, disclosure of the vulnerability lead to more details. The vulnerability was discovered by  two researchers Mathy Vanhoef and Frank Piessens of the Katholieke Universiteit Leuven (KU Leuven) while examining OpenBSD’s implementation of the WPA2 four way handshake.

Why should this vulnerability be considered important?
On Monday 16th October, the KRACK (key re-installation attacks) vulnerability was disclosed. This vulnerability was found within the implementation of the WPA2 protocol rather than any single device making it’s impact much more widespread. For example, vulnerable devices include Windows, OpenBSD (if not already patched against it), Linux, Apple iOS, Apple macOS and Google Android.

If exploited this vulnerability could allow decryption, packet replay, TCP connection hijacking and if WPA-TKIP (defined) or GCMP (explained) are used; the attacker can inject packets (defined) into a victim’s data, forging web traffic.

How can an attacker exploit this vulnerability?
To exploit the vulnerability an attacker must be within range of a vulnerable Wi-Fi network in order to perform a man in the middle attack (MiTM)(defined). This means that this vulnerability cannot be exploited over the Internet.

This vulnerability occurs since the initial four way handshake is used to generate a strong and unique key to encrypt the traffic between wireless devices. A handshake is used to authenticate two entities (in this example a wireless router and a wireless device wishing to connect to it) and to establish the a new key used to communicate.

The attacker needs to manipulate the key exchange (described below) by replaying cryptographic handshake messages (which blocks the message reaching the client device) causing it to be re-sent during the third step of the four way handshake. This is allowed since wireless communication is not 100% reliable e.g. a data packet could be lost or dropped and the router will re-send the third part of the handshake. This is allowed to occur multiple times if necessary. Each time the handshake is re-sent the attacker can use it to gather how cryptographic nonces (defined here and here) are created (since replay counters and nonces are reset) and use this to undermine the entire encryption scheme.

How can I protect myself from this vulnerability?
AS described in this CERT knowledge base article.; updates from vendors will be released in the coming days and weeks. Apple (currently a beta update) and Microsoft already have updates available. OpenBSD also resolved this issue before the disclosure this week.

Microsoft within the information they published for the vulnerability discusses how when a Windows device enters a low power state the vulnerable functionality of the wireless connection is passed to the underlying Wi-Fi hardware. For this reason they recommend contacting the vendor of that Wi-Fi hardware to request updated drivers (defined).

Links to affected hardware vendors are available from this ICASI Multi-Vendor Vulnerability Disclosure statement. Intel’ security advisory with relevant driver updates is here. The wireless vendor, Edimax also posted a statement with further updates to follow. A detailed but easy to use list of many vendors responses is here. Since I use an Asus router, the best response I could locate is here.

Update: 21st October 2017:
Cisco have published a security advisory relating to the KRACK vulnerability for its wireless products. At the time of writing no patches were available but the advisory does contain a workaround for some of the affected products.

The above updates are software fixes but updates will also be made available for devices in the form of firmware updates e.g. for wireless routers, smartphones and Internet of Things (IoT)(defined) devices. For any wireless devices you own, please check with the manufacturer/vendor for available updates with the above CERT article and vendor response list detailing many of the common vendors.

Thank you.

HP audio driver contained keylogger

Late last week it was announced the security firm Swiss security firm ModZero had responsibly disclosed (defined) to HP back in early April 2017 their discovery of an audio driver (Conexant HD Audio) containing a keylogger. The driver is known to be present on 28 HP devices (listed here).

Conexant also creates drivers to Asus, Lenovo and Dell, at this time it is not clear if they use the same driver (security analysts have been unable to discover any other devices using the affected driver).

How can I tell if my HP (or other device) is affected by this vulnerability?
This BleepingComputer article explains how to check for this vulnerability.

Why should this vulnerability be considered important?
The affected audio driver (versions up to and including contained the issue with the issue first being created in December 2015. Thus it has the potential to have gathered a vast quantity of information since this time.

Not only does the driver record key presses (using a low-level keyboard input hook (defined)) but the driver exposes the OutputDebugString and MapViewOfFile APIs (API, defined). The OutputDebugString API enables any running application to capture keystrokes while MapViewOfFile enables any framework or application with access to MapViewOfFile API to do the same.

Since the unencrypted keystrokes are stored in a text file, forensic investigators with access to the log file (stored at C:\Users\Public\MicTray.log) could potentially recover previously saved sensitive data (a reboot or power of the device clears the file). When backups of the affected systems are performed previous versions of this file would contain further captured (and potentially sensitive) information.

Since our keyboards are used to enter all kinds of sensitive information,  emails, chat/instant message conversations, social media posts, credit card numbers etc., this vulnerability could have serious consequences If the log contents were to be obtained by cyber criminals. The file might also contain credentials (usernames/passwords for the above mentioned activities.

From the information disclosed about this vulnerability, there is evidence to suggest the driver uploads/sends the information it gathers within that log to HP, Conexant or anyone else. However if you are creating unencrypted backups within a corporate, small business or consumer environment this file over time will contain more and more information gathered over time. If someone knew you create these backups and knew where to look within them (assuming they are not encrypted), they could gather significant volumes of sensitive information.

How can I protect myself from this vulnerability?
After ModZero disclosed this information to HP, HP made available a driver update (version 10.0.931.90) which removes the keylogging behavior. Moreover, the driver update will be made available via Windows Update for both 2016 and 2015 HP devices. HP Vice President Mike Nash clarified the logging feature of the driver was simply debugging code (defined) inadvertently left within the driver.

If you followed the steps above to check if your device was vulnerable but there is no driver update available, the same BleepingComputer article describes how to mitigate the vulnerability.

Thank you.