Disclaimer: If you think you're G0D of Hackers, DO NOT READ THIS. Content provided here does not mean CORRECT, or TRUE TO THE UNIVERSAL LAWS OF Security/Hacking. Take it or leave it. Use it at your 0wn risk. _________________________________________________________________________________ Things to note about Testing for DLL Hijacking Vulnerability by Aung Khant, http://yehg.net Date: Sept 01, 2010 Last Updated: September 06, 2010 ================================================================= DLL Hijacking Vulnerability has been underestimated because of the extreme easiness to find with tools such as DLLHijackAuditKit(Metasploit), DLLHijackAuditor(SecurityXploded). Nevertheless, it is a very cool exploit that blackhats and botnet creators love as they don't need to spend a lot of time or money in developing zero-day exploits. Testing for DLL Hijacking Vulnerability is a stealth art though it is easy to find. It involves some important factors that you, as a bug finder, should not overlook. When testing for DLL Hijacking, 1. Please make sure your Windows is a FRESH installation. Use VMware/VBox snapshot. 2. Always test/verify it against in another copy of fresh Windows. Better, test it against the popular Windows family (Windows XP, Vista, Seven) if you have time. Use VMware/VBox snapshot. 3. Most importantly, your Windows must not be customized, trojanized or virus-infected, such windows copies load a special set of DLL files whenever you open a file or a particular file or a folder. 4. DotNet applications will depend on versions of DotNet (1x, 2x, 3x,..etc) 5. Some applications will depend on Windows versions. 6. Some applications will depend on user privileges. 7. Some applications will depend on the functions you interact. They won't load a particular dll till you do some application functionalities (that cause the application open/load new sub module/application). It's related to file extensions. A media player will not load codec_mp3.dll unless you open a mp3 file. 8. Your testing DLLs might be cached by the Windows, which caused your newer DLLs break or work unexpectedly. Use VMware/VBox snapshot. 9. If your tested application allows third-party addons, carefully determine whether the vulnerability relates to such addons or not. 10. If the AlertBox is used as a part of POC DLL and POC show, this may not be triggered in some applications. A simple execution such as calculator/notepad/ should be used together. So, it's very important to include what platform, versions, settings,..etc you test on in your advisory. DLL Hijacking is a 10-years-old Widnows Design Weakness. But only recently it has become a hot topic (maybe among the security industry) that we cannot ignore for the security of Windows users. Blackhats will (already) take advantage of it to exploit systems at large in building a botnet without any expensive 0 day exploits. DLL Hijacking FAQ: ================= 1. DLL Hijacking vulnerability exists in thousands of windows applications. How can you protect this from being exploited? First, we'll target most popular applications that attackers might look for. Second, the increasing issuing of advisories in this vulnerability class will catch application developers communities and hopefully they won't let it happen again in their future applications. 2. Will DLL Hijacking vulnerability continue to exist? This depends on how much our security community take seriousness and take time to submit information to the affected vendors. We're seeing that many of them have already overlooked this issue as it can be found by anyone with no skills. 3. What makes DLL Hijacking exploitable? Actually, windows applications are modularized and call DLL as part of their routines/functionalities. Maybe from Operating System DLL or their own DLL or their 3rd party DLL and so on. Virtually every application might be DLL Hijackable. Here, what is exploitable and what is not exploitable separate the actual definition of DLL Hijacking. Exploitably Hijackable DLL exists in the same directory as the file that a user will open, which is a scene that makes this vulnerability exploitable. Other than that scene, it shouldn't be regarded as an actual vulnerability. This is what most of the guys in security industry assumes. 4. Should I find such vulnerability in many applications as I can? You should not. It's just a waste of time and your energy. Focus on most popular application types/classes. Submit POC to developers and ask them to release fixes/patches. Save thousands of users' frustration and unhappiness of being exploited. 5. Where can I find DLL Hijacking Archive? Find it in - 1. BugTraq Mailing List 2. Full Disclosure Mailing List 3. http://www.corelan.be:8800/index.php/2010/08/25/dll-hijacking-kb-2269637-the-unofficial-list/ 4. http://www.exploit-db.com/dll-hijacking-vulnerable-applications/ 5. http://inj3ct0r.com/search Do search it before you release advisory but researchers might miss complete "affected extensions" and "dll list". Maybe you can find more. It's not a waste of time to find bugs even if there is an advisory for it. 6. Tell me some ways that attackers can abuse this flaw? DLL Hijacking is very useful in combination with other attack vectors. It's best (ab)used in SET - Social Engineering Toolkit(SET). Scene 1 ======== To make sense for you, note the following constraints: 1. Attacker has some write and read access through other vulnerabilities. 2. Vulnerability Applications are installed in users' writable directories. 3. The OS that vulnerability applications are installed has a Host-based IDS that allows only TRUSTED applications to RUN. Some extreme scanerios that (no) one ever has thought of or people find it ridiculous are as follow: - Attackers can write a malicious dll and file to Disk through other layers such as FTP write Access, Web application flaws like SQL Injection - Attackers can place iso file with a malicious dll, mount it to CD drive , waiting for a logged-in user to open - Attackers can place a file with a malicious dll together with autorun.inf and place it to local and network drives, which caused it auto executable. Scene 2 ======== DLL Hijacking is a very cool feature to be used in Social Engineering. Consider in this social networking world - facebooks, twitter, web chat 1. Attacker pretend as a girl 2. Send a zip fle that contains a girl's webcam pictures/vidoes together with a malicious dll to those who flirt him 7. How can you find a user has XYZ application installed? Several ways. Together with obvisous Social Enginnering technique, an attacker forces a user to visit his site which uses res:// file enumeration : http://ha.ckers.org/weird/res-timing.htm http://ha.ckers.org/weird/res-timing2.cgi to profile what softwares are installed on user machine. References =========== First post about DLL Hijacking: http://www.securityfocus.com/bid/1699/info DLL Preloading: http://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx Remote DLL Hijack Test: http://www.binaryplanting.com/test.htm DLLHijackAuditKit: https://www.metasploit.com/redmine/projects/framework/repository/raw/external/source/DLLHijackAuditKit.zip DLLHijackAuditor: http://securityxploded.com/dllhijackauditor.php SET: http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Social_Engineer_Toolkit_(SET)