SafeBreach Labs discovered a vulnerability in Intel(R) Rapid Storage Technology Service.
In this post, we will demonstrate how this vulnerability could have been used in order to achieve defense evasion and persistence by loading an arbitrary unsigned DLL into a service’s signed process that runs as NT AUTHORITY SYSTEM.
Note: In order to exploit this vulnerability the attacker needs to have Administrator privileges.
Intel(R) Rapid Storage Technology
Intel Rapid Storage Technology is a Windows-based application that provides improved performance and reliability for systems equipped with SATA disks for desktop, mobile, and server platforms.
The technology is provided with many Intel chipset based PCs.
In our exploration, we targeted the following Intel(R) Rapid Storage Technology service process: IAStorDataMgrSvc.exe
Besides the fact it’s a signed process and it runs as NT AUTHORITY\SYSTEM, it was interesting because we assumed that this service is probably installed on many Intel-based computers, which means that a vulnerability which affects this kind of service might have a big impact.
When started, IAStorDataMgrSvc.exe tries to load 4 missing DLL files its own directory:
In order to test this vulnerability, we compiled an unsigned arbitrary DLL which writes the following to the filename of a txt file:
- The name of the process which loaded it
- The username which executed it
- The name of the DLL file
We then copied it to the following paths and restarted the Intel RST service:
- C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IoctlLog.dll
- C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IoctlNet.dll
- C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IoctlSim.dll
- C:\Program Files\Intel\Intel(R) Rapid Storage Technology\DriverSim.dll
We were able to load arbitrary DLL files and execute our code within IAStorDataMgrSvc. exe which is signed by Intel Corporation and running as NT AUTHORITY\SYSTEM.
Note: As we will explain in the root cause analysis paragraph, the code tries to load only one of the Ioctl
<Xxx>.dll files. Once it loads one of the files successfully it won’t try to load the rest.
Root Cause Analysis
Once the service is loaded, it loads Intel’s ISDI2.dll library (Intel Storage Driver Interface Dynamic Library).
The ISDI2.dll library is using a LoadLibraryA in two places in order to load the DLL files:
Note: In the screenshot above you can see that it tries to load only one of the Ioctl
The root cause of this vulnerability is that no signature validation is made against the DLL files which the service tries to load (i.e. calling the WinVerifyTrust function).
Because the files do no exit, an attacker can implant arbitrary DLL files and the service will load them.
Potential Malicious Uses and Impact
Below we show two possible ways that an attacker can leverage these vulnerabilities which we discovered and documented above.
Whitelisting Bypass and Defense Evasion
The vulnerability gives attackers the ability to load and execute malicious payloads within the context of an Intel Corporation signed process. This ability might be abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass.
The vulnerability gives an attacker the ability to load and execute malicious payloads in a persistent way, each time the service is being loaded. That means that once the attacker drops a malicious DLL, the service will load the malicious code each time it is restarted.
Affected Products and Versions
Intel Rapid Storage Technology (RST) Service
Code Branch: Mitigation release:
- V17.x v17.5.1.x
- V16.x v16.8.3.x
- V15.x v15.9.8.x
July 22nd, 2019 – Vulnerability Reported to Intel
July 22nd, 2019 – Intel received the report
Aug 7th, 2019 – Intel confirmed the vulnerability
Aug 14th, 2019 – Intel completed an initial assessment
Sep 16th, 2019 – Status update from Intel
Oct 7th, 2019 – Status update from Intel
Oct 22nd, 2019 – Status update from Intel
Nov 2nd, 2019 – Intel issued CVE-2019-14568 and provided a timeline of a fix deployment (December 10th) and affected products list.
Dec 4th, 2019 – Intel asked to delay the public disclosure until January 14th, 2020 in order to allow their business partners sufficient time to integrate the fix into their products.
Dec 10th, 2019 – Intel informed us that they managed to work out mitigation details with the business partner that had requested delay of the disclosure to January. As a result, their advisory was published December 10th, 2019.