Back to list
Internet Explorer file downloading security alerts bypass
Dec 22 2003 06:06PM
Hugo Vázquez Caramés (overclocking_a_la_abuela hotmail com)
Vendor contacted via spanish Microsoft Gold Partner.
Status: No response.
1- File downloading security alerts bypass.
Affected software: Internet Explorer (tested on Win2003 Web Server edition)
Impact:web content/application firewalls filters bypass
code execution on victim's system
When a user tries to download a dangerous file (executable binaries, for example),Internet Explorer warns with a pop-up window like this one:
This warning notices the user of the danger on downloading such kind of file with a brief description of the type of file based on the extension (.exe, .bat, etc).
A Windows Command Script will be detected in this way:
If an attacker tries to rename a file, for example, "virus.exe" to "virus" without extension to avoid the security warning, he will be able to trick the browser, but the file without extension, once saved will not be automatically recognized by the system.
There's a security problem in Internet Explorer (at least on the default version of Windows 2003 Server Web Edition).
If we make a request like this:
we will see that the browser believes that the file is an HTML and not an EXE...
Moreover, we can notice that the original extension (.exe) is not showed.
The trick seems to be in requesting the target file (the one we want to download) as if it was a CGI, and parsing the "desired" extension (.html for example) as a parameter.
This kind of requests can trick the browser. More interesting is the result of a request parsing an encoded final string caracter (%00). Let's see what it happens:
As we can see the browser doesn't show the extension.
Playing a bit I noticed that is possible to combine those two tricks to have something really powerfull: file extension hiding and manipulation (to bypass many web filters) and code/file execution without having to send any kind of suspicious binary.
We can send a link (not all users know the "lnk" extension), without being detected (theoretically ) by many filters (CheckPoint?..., ISA Server?...). To prove that, we make a request to a file called "document" as if it was a CGI, we parse as parameter the ".lnk" extension, and we add an encoded final string (%00) to avoid the browser file type information.
We can see that the browser believes that "document" is "document.lnk" and it does not provide information on the the file type.
The risk of this behaviour is high: web filters probably will not stop a request to a file called "document", the browser adds the extension (.lnk), the user is not warned... and he can be tricked.
Antivirus are useless in this scenario... is a link file a virus?
The result of this attack is that the victim will store the file (document) as document.lnk.
There are a lot of attack vectors. As a proof of concept we can make a link pointing to the system shell (cmd.exe) with some parameters (for example "/c dir"). This is as easy as creating the link in a windows box, and putting the file in the web server without the extension.
Result: comands are executed via a cmd shell.
Summary: the bug detected in Internet Explorer allows the bypass of any security warning in the process of file downloading and it is also possible to hide the information about the file type. A related problem is that traditional content filters, web/application firewalls, antivirus, etc were security is based only on the file extension, can be also bypassed. This vulnerablity could be very dangerous, if exploited by virus/worms to spread itself without being blocked.
2- Bug in the execution process of just downloaded files
Affeceted software: Internet Explorer (tested in Windows 2003 Web Server edition)
Impact: -execution of non allowed binaries in the victim's system
There's a scenario were the last vulnerability ("File downloading security alerts bypass") could allow the execution of files present in the system without the needing of downloading any kind of binary, link, etc.
The problem is that, when exploiting tha last vulnerability, if we make a request to a binary (for example) as if it was a CGI and we directly parse an encoded final string (%00), the browser does not show the extension nor it provides information on the file type. But if the user saves the file, even if it is saved without extension, when the user opens the file from the downloading dialog window, Internet Explorer tries to open the file but adding the extension. This is a dangerous behaviour. If there exists a file with the same name (but WITH THE EXTENSION), it will be executed.
I will try to clarify all this (sorry for my really bad english...). Let's suppose we make a request like this:
(cmd.exe can be an empty file)
If we try to save the file in the system32 directory, it will be saved as "cmd", but if just try to open this file from the downloading dialog window, it will not be opened "cmd", instead it will be opened the system "cmd.exe"...
The main "problem" on exploiting this bug in a real scenario is that nobody saves dowloaded files in "system32"... Anywhere, there are other ways this bug can be exploited. If the attacker knows where a binary is and tricks the user on saving the downloaded file on the same directory, he will be able of executing this binary. This flaw can exploited also with links, so attack vectors increase. If the victim is used to save files in the Desktop, and the attacker knowns that a link exists in the Desktop (almost everyone has some link in the Desktop...), then is possible for the attacker to execute the file that this link is pointing to. In some environments, users create links in the Desktop to have a fast and easy way to access intranet applications without having to validate any time (for example for Lotus). So, the result is that the attacker can execute "something" in the victim's box without being allowed to do it.
THIS REPORT CAN BE READ AT:
Hugo Vazquez Carames
[ reply ]
Copyright 2010, SecurityFocus