infohacking.com
- IE file downloading security warnings bypass
- (spanish)
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
Problem description:
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:
http://server/file.exe?.html
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:
http://site/cmd.exe?%00
(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.
