lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20031222180620.23867.qmail@sf-www3-symnsj.securityfocus.com>
Date: 22 Dec 2003 18:06:20 -0000
From: Hugo "Vázquez" "Caramés" <overclocking_a_la_abuela@...mail.com>
To: bugtraq@...urityfocus.com
Subject: Internet Explorer file downloading security alerts bypass






#####################################################
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

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:

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/primero.jpeg


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:

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/segundo.jpeg


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...

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/tercero.jpeg


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:

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/cuarto.jpeg


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.

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/quinto.jpeg

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.

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/sexto.jpeg

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/septimo.jpeg

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.


http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/octavo.jpeg

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.


THIS REPORT CAN BE READ AT: 

http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/IE/index.html
      

Hugo Vazquez Carames

www.infohacking.com
---------------------




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ