Apps Wrapping IE may inherit security risks IE doesn't contain
I believe a good security tester is not only able to find outright design and implementation flaws, but also recognizes opportunities for defense in depth features and understands how to take advantage of existing defense in depth features in technologies used by the product they are testing. Many applications wrap Internet Explorer, commonly through the WebBrowser Control, but do not take advantage of the defense in depth features provided. This results in the application wrapping IE inheriting security risks not exposed through the IE application.
Remember a few years there were several bugs that allow arbitrary code execution once an attacker could write HTML to the victim’s hard disk? This happened because Internet Explorer saw this content as part of the Local Machine Zone (LMZ) and believed that content there should run with few security restrictions. IE would also examine the first couple hundred bytes of a loaded file, also known as sniffing, to determine if the file contained HTML content. If it did, IE would render the file as HTML. The sniffing behavior allowed Javascript to run in files with names like application.dat.
Finding any place on the local file system that an attacker could force his content to contain HTML script to be written to a file and then coerce the victim to load that file became a very fruitful endeavor. If successful the file would be interpreted as HTML (sniffing behavior) and allow total compromise of the victim’s account (LMZ script behavior).
While IE still contains bugs, the frequency of seeing attacks that take advantage of the LMZ is significantly reduced. The reason? IE now provides an option for the LMZ to more restrictive. Part of the new behavior means script and ActiveX controls no longer run in the LMZ by default. However, to prevent breaking applications that wrap IE and rely on the old LMZ behavior, SP2 made the more restrictive LMZ an opt-in feature.
Example: Defense in depth features introduced in Windows XP SP2
As shown below, in SP2 IE prevents script from running in the LMZ and displays an information bar. In this example, the file c:\Demo\Script.html contains JavaScript that is not executed.
In SP2 IE also prevents the sniffing behavior. The image below shows the file script.dat loaded in IE as text. If this text was sniffed, it would be considered HTML since it begins with an HTML tag.
The contents of script.dat are as follows:
<html>
<body>
<script>alert("I am running script from " + document.location)</script>
</body>
</html>
Example: Program that inherits security risks
Loading the same HTML file in a program wrapping IE that does not take advantage of the defense in depth features, allows the script to execute the example file script.dat is loaded. Executing attacker-supplied script inside the LMZ allows an attacker to take over the current user’s account. Below is an example of an application (Browzar) wrapping IE that runs script in the LMZ.
How to find applications wrapping IE
Opting into the IE defense in depth features is typically done as process level setting. Since applications that wrap IE inherit the less restrictive behavior, a diligent security tester (or attacker) wants to find these applications.
- White box. While I’m a big fan of source code review to find flaws and it can help identify places that might wrap IE, source review alone will often be incomplete when looking for applications that wrap IE. Several COM objects wrap IE so the caller may be unaware his application is using IE when using a COM object like this.
- Black box. MSHTML.DLL is core of the IE rendering engine and is used by any application wrapping IE. One approach to identifying applications wrapping IE is to determine if the targeted application is loading IE with a tool like Process Explorer.One the downfall of this approach is the MSHTML.DLL might be loaded dynamically (either directly or through another DLL) and examining the process through Process Explorer only shows currently loaded modules.
If determining the target application wraps IE isn’t enough to convince the application’s programmer’s to leverage the defense in depth features, you might need to prove than an attacker can take advantage of the wrapped instance of IE. In this case, you want to find the actual IE windows and how an attacker’s data could be loaded. To determine if a control displayed by the application is a wrapped IE control, the Spy++ tool included with Visual Studio can be leveraged. If a control window’s class is Internet Explorer_Server, it is a wrapped IE window.The following image shows the Spy++ once an IE window is identified.
How to opt-in to the defense in depth features
One nice thing about the defense in depth features is opting-in doesn’t require a code change. These features can be controlled on a processes basis through reg keys. For complete details on how to take advantage of these features, please see http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx. An alternative approach to using the defense in depth features is to implement a custom Security Manager.
The example used in the beginning of this post showed how applications ran script in the LMZ if not opted-in to the defense in depth feature. This particular feature is called FEATURE_LOCALMACHINE_LOCKDOWN. To opt an application in, a DWORD registry entry can be made with the name of the process’s executable and the value 1. For example, the image below shows by default, explorer.exe, iexplore.exe, msimn.exe, and wmplayer.exe are all taking advantage of the defense in depth behavior.
0 Comments:
Post a Comment
<< Home