Skip to main content

Intel Rapid Storage Technology Vulnerability Allows Persistent Malware

(Image credit: Shutterstock)

Researchers from Safe Breach discovered that an older version of Intel’s Rapid Storage Technology (RST) software is vulnerable to DLL hijacking. The flaw could allow a malicious program to be seen as trusted by antivirus engines, thus bypassing their system protection. 

In order to exploit the vulnerability, the attacker needs administrative privileges. However, this may be an easier task than many might think, as the vast majority of Windows systems run with administrative privileges enabled by default, making an attacker’s job that much easier. 

How the Bug was Found

The researchers found the bug by starting to look at Windows services that come with many Windows devices and have a high-level of trust, as that’s often the way malware makers decide on what type of malware to write, too. 

Intel’s RST checks those boxes quite well as it comes with many devices and it also has NT Authority/System-level privileges. This gives RST lower-level access to the device and the Windows OS, but it doesn’t give it network access by default.

Why The Intel RST Bug Exists

Apparently, someone at Intel forgot to remove certain RST commands that are no longer relevant to the software, such as trying to load four different DLL files that no longer exist. 

Intel’s IAStorDataMgrSvc.exe executable belonging to the RST software tries to load the following non-existent DLLs:

An attacker could take advantage of this by creating at least one malicious DLL that uses one of those names. Intel seems to have made it easy for attackers, too, as when RST can’t find the missing DLLs in the folder where they were supposed to be, it starts searching for them in other folders. The attackers could then load the malicious from anywhere in the system. 

Furthermore, the malware would gain persistence, as Intel RST will continue to load the malicious DLL every time it’s restarted. As the DLL libraries are supposed to be used by the “trusted” Intel RST software, that means antivirus engines will also ignore it by default.

Vulnerability Discovery and Mitigation Timeline

Intel has released patches for its RST software, including version series 15.x, 16.x, and 17.x. The specific versions to which you should update are: v15.9.8.x, v16.8.3.x, or v17.5.1.x. Ideally it would be the latter (or newer), as that’s the current software series. If you can’t switch to the newer RST software series, you should at least get the latest patches for your current software.

SafeBreach reported the vulnerability on  July 22nd, 2019 and it took Intel until December 10 to release the patches, but not before asking for a delay until January 14 so that its partners have more time to integrate the patches. 

As the patches have already been issued, it appears that the researchers didn’t want to allow Intel an extension and went public with the vulnerability per the original disclosure agreement between the SafeBreach researchers and Intel.

  • Pat Flynn
    It would be nice to know the names of the DLL files the EXE is looking for. With that info, you should be able to create empty dummy files, then use CACLS to block access to said DLL files preventing it from being overwritten by any trojan. Sort of a preventative method?
    Reply
  • JonDol
    Pat Flynn said:
    It would be nice to know the names of the DLL files the EXE is looking for. With that info, you should be able to create empty dummy files, then use CACLS to block access to said DLL files preventing it from being overwritten by any trojan. Sort of a preventative method?

    That could be indeed useful for some advanced users. I personally use Comodo Security Suite which is quite helpful to prevent DLL hijacking. Using the 'Purge' functionality is removes the trust of no longer existing binary files thus when they pop up again you are required to allow them. You are also required to take action when a trusted binary gets updated. At least, this is how I configured mine thus no need to fiddle with CACLS.
    Reply
  • TreborG2
    Pat Flynn said:
    It would be nice to know the names of the DLL files the EXE is looking for. With that info, you should be able to create empty dummy files, then use CACLS to block access to said DLL files preventing it from being overwritten by any trojan. Sort of a preventative method?
    I believe they blocked them to lessen the pubic ability to openly use said file names .. as well as to limit the script kiddies etc..
    Reply