Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
General Security Discussions
Testing DLL Search Order Hijacking against security features.
Message
<blockquote data-quote="Andy Ful" data-source="post: 884085" data-attributes="member: 32260"><p>The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the system DLLs from a non-system folder which contains the vulnerable EXE. In this post I use a fake version.dll which normally should be loaded from "%WinDir%\system32", but in fact the fake version.dll is loaded from another location.</p><p></p><p>For many reasons this vector of attack is inefficient for infecting home users (so no worry), but it was used sometimes in the wild to infect enterprises.</p><p>[URL unfurl="true"]https://attack.mitre.org/techniques/T1038/[/URL]</p><p></p><p>The attackers know how to use DLL hijacking for years, so I can freely write something about it (nothing new). This method can be used to skirt around some security features focused on detecting/blocking 0-day malware. Many such features can detect/block only the EXE files and do not detect/block loading malicious DLLs by the EXEs. This method cannot be detected by monitoring the child processes. Such a security feature can see only the safe executable which is digitally signed by a very reputable vendor. The file is allowed to execute or the user can see the misguiding information that the file is safe to run. In this way, the DLL Search Order Hijacking can be used as a poor imitation of malware with the stolen high reputable certificate (without stealing any). </p><p></p><p>I tested several security solutions (AVs, Anti-EXE, and SRP). Some of them could not prevent such 0-day attacks, especially when a kind of reputation service was used only for EXE files. For example, the Hard_Configurator forced SmartScreen feature, could not prevent it up to the ver. 5.0.0.0. I fixed this in the beta version, because it was an easy fix (even if not necessary). I can note, that after informing the InnoSetup vendor about this vulnerability, it was fixed a week ago (InnoSetup installations are used in businesses).</p><p></p><p>How to test if the security feature can be bypassed? In my tests I used a very simple procedure, which can probably have to be slightly modified for other security solutions.</p><p></p><ol> <li data-xf-list-type="ol">Find a signed EXE file (with 0 VirusTotal detection) vulnerable to DLL hijacking (I used Sysinternals Coreinfo tool).</li> <li data-xf-list-type="ol">Find a non-malicious DLL which is detected by Virus Total and(or) when renamed with .exe extension it is detected by reputation service or AI checking. I used a well known AllTheThings.dll (Casey Smith).</li> <li data-xf-list-type="ol">Rename the DLL to one of the system DLLs loaded by the EXE (I used version.dll).</li> <li data-xf-list-type="ol">Put the vulnerable EXE and the fake DLL into one folder (but not the Windows folder).</li> <li data-xf-list-type="ol">Run the EXE and watch if the fake DLL was loaded and executed. In my test I watched for an error message box, when the EXE tried to use the GetFileVersionInfoSizeW function from version.dll, but my fake version.dll did not have such function.</li> </ol><p></p><p>Here are the screenshots for testing SmartScreen (I added MOTW to the Coreinfo.exe, version.dll, and version.exe). Please note: However the DLL Search Order Hijacking allows the malware passing by SmartScreen, you probably never see it in the home environment, because there are much simpler methods of doing it.</p><p></p><p>The below alert is from SmartScreen to be sure that a fake version.dll (renamed to version.exe) is not recognized by SmartScreen.</p><p>[ATTACH=full]240792[/ATTACH]</p><p></p><p>The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool..</p><p>[ATTACH=full]240793[/ATTACH]</p></blockquote><p></p>
[QUOTE="Andy Ful, post: 884085, member: 32260"] The DLL Search Order Hijacking is a well known (but not common) vector of attack. It is often performed via a vulnerable Microsoft EXE file or EXE signed by the well known reputable vendor. A popular way of exploiting this vulnerability is based on loading by the vulnerable EXE, one of the system DLLs from a non-system folder which contains the vulnerable EXE. In this post I use a fake version.dll which normally should be loaded from "%WinDir%\system32", but in fact the fake version.dll is loaded from another location. For many reasons this vector of attack is inefficient for infecting home users (so no worry), but it was used sometimes in the wild to infect enterprises. [URL unfurl="true"]https://attack.mitre.org/techniques/T1038/[/URL] The attackers know how to use DLL hijacking for years, so I can freely write something about it (nothing new). This method can be used to skirt around some security features focused on detecting/blocking 0-day malware. Many such features can detect/block only the EXE files and do not detect/block loading malicious DLLs by the EXEs. This method cannot be detected by monitoring the child processes. Such a security feature can see only the safe executable which is digitally signed by a very reputable vendor. The file is allowed to execute or the user can see the misguiding information that the file is safe to run. In this way, the DLL Search Order Hijacking can be used as a poor imitation of malware with the stolen high reputable certificate (without stealing any). I tested several security solutions (AVs, Anti-EXE, and SRP). Some of them could not prevent such 0-day attacks, especially when a kind of reputation service was used only for EXE files. For example, the Hard_Configurator forced SmartScreen feature, could not prevent it up to the ver. 5.0.0.0. I fixed this in the beta version, because it was an easy fix (even if not necessary). I can note, that after informing the InnoSetup vendor about this vulnerability, it was fixed a week ago (InnoSetup installations are used in businesses). How to test if the security feature can be bypassed? In my tests I used a very simple procedure, which can probably have to be slightly modified for other security solutions. [LIST=1] [*]Find a signed EXE file (with 0 VirusTotal detection) vulnerable to DLL hijacking (I used Sysinternals Coreinfo tool). [*]Find a non-malicious DLL which is detected by Virus Total and(or) when renamed with .exe extension it is detected by reputation service or AI checking. I used a well known AllTheThings.dll (Casey Smith). [*]Rename the DLL to one of the system DLLs loaded by the EXE (I used version.dll). [*]Put the vulnerable EXE and the fake DLL into one folder (but not the Windows folder). [*]Run the EXE and watch if the fake DLL was loaded and executed. In my test I watched for an error message box, when the EXE tried to use the GetFileVersionInfoSizeW function from version.dll, but my fake version.dll did not have such function. [/LIST] Here are the screenshots for testing SmartScreen (I added MOTW to the Coreinfo.exe, version.dll, and version.exe). Please note: However the DLL Search Order Hijacking allows the malware passing by SmartScreen, you probably never see it in the home environment, because there are much simpler methods of doing it. The below alert is from SmartScreen to be sure that a fake version.dll (renamed to version.exe) is not recognized by SmartScreen. [ATTACH type="full" alt="DLLHSmartscreen1.png"]240792[/ATTACH] The below screenshot shows that the fake version.dll is executed after running the CoreInfo tool.. [ATTACH type="full" alt="DLLHSmartscreen2.png"]240793[/ATTACH] [/QUOTE]
Insert quotes…
Verification
Post reply
Top
