Adobe Flash: Cross-domain policy
The next few posts will be Adobe Flash’s cross-domain behavior. This post will focus on the policy file (crossdomain.xml).

Adobe Flash has the ability to read data cross-domain. A cross-domain read can be accomplished by leveraging ActionScript’s sendAndLoad method (http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary435.html). Obviously, arbitrary cross-domain read would be bad/fun (depending on your point of view). In any case, this would not be good for security. Crossdomain.xml determines if a cross-domain read is allowed in Flash. If the file does not exist, the read is prohibited.

When a Flash movie attempts to make a cross-domain read, Flash makes a request for /crossdomain.xml on the target of the cross-domain read. For example, if an attempt to read http://www.adobe.com/ cross-domain is attempted, Flash will first request http://www.adobe.com/crossdomain.xml.

More information on crossdomain.xml is available here - http://livedocs.adobe.com/flash/9.0/main/00001085.html. Basically, the file can allow specific domains to access content cross-domain. Wildcards are allowed. Allowing arbitrary domains cross-domain access is possible.

When pen-testing a web site, it is helpful to check if crossdomain.xml allows access from a domain where you can author content. I found an example of what appears to be a website compromise that included writing crossdomain.xml. http://gestionaconleaseplan.com/crossdomain.xml appears to have been written by a Turkish hacking group. However, the contents aren’t malicious. The file contains a few HTML tags to format a hacker group’s name and is not a correctly formatted XML file.



The best way to determine if a domain’s contents can be read through Flash is to examine crossdomain.xml. Demos are always nice so I’ve written a small tool to demonstrate if cross-domain read access is allowed for the domain specified. You can try it out here - http://www.securitybughunter.com/tools/crossdomainxml.



More fun with Flash and cross-domain shortly.

Microsoft Office Isolated Conversion Environment now available!

Today Microsoft released the Microsoft Office Isolated Conversion Environment (MOICE) tool or as we call it internally “the wringer”. This is to help mitigate unpatched security bugs in Office document parsing of the Office 97-2003 binary file formats (doc, ppt, pot, pps, xls, xlt, xla).A lot of security work was done as part of the Office 2007 product cycle. As a result, the file parsing in Office 2007 is more robust (and secure) than the previous versions of Office. (I’m not saying the Office 2007 parsers are perfect, but they are generally more robust and secure.) The MOICE tool allows the Office 2007 parsers to run on previous version of Office. Not only does it contain the stronger parsers, but the binary file format parsing runs with a restricted token. If malicious code does try to take advantage of a parsing bug in the wringer, it shouldn’t be able to drop a rootkit (the restricted token should prevent that).

How MOICE works

1. MOICE is associated with the file extensions of concern. Normally Office file extensions are associated directly with the Office application of interest. For example, .doc is associated with winword.exe (Microsoft Word). Using the ASSOC tool included with the MOICE download, the file extension is associated with oice.exe. More on the associating is available in the knowledge base article - http://support.microsoft.com/?kbid=935865.



2. Associated files now open with MOICE. MOICE parses the Office 97-2003 binary file and writes out a new file in the Office 2007 file format.



3. ShellExecute occurs on the Office 2007 file. Since the Office 2007 file extensions are still associated with Office, this opens up the version of Office on the machine.



4. Office opens the 2007 version of the file. The 2007 version of the file is understood because of the converter pack (allowing Office 2003 to read the Office 2007 file format).

Ways to bypass MOICE
By the description above, you might have noticed the way MOICE is invoked is by associating file Office 97-2003 extensions to it. There are other ways that files open in Office. These will bypass MOICE! For example, renaming a .doc file to .rtf will bypass MOICE and result in a .doc file opening in Word. (MOICE doesn’t associate itself with the rtf extension.) Another example of a MOICE bypass is if a file is opened by performing File->Open instead of double clicking the file. Clearly, you don’t want MOICE bypassed when you think you are using it.

How to prevent Office from parsing the document if MOICE is bypassed
Since you cannot guarantee MOICE won’t be bypassed, you must prevent Office from directly opening the file formats you want MOICE to handle. This is done using the File Block feature I previous wrote about here. With File Block enabled, if a file bypasses MOICE and is one of the blocked types, the file will not be opened by Microsoft Office.

Hunting Security Bugs now available in French

Microsoft Press has translated Hunting Security Bugs to French under the title Chasser les failles de sécurité : Les meilleures pratiques pour tester la sécurité de vos logiciels. Here's a link to the French version on Amazon.fr - http://www.amazon.fr/Chasser-failles-s%C3%A9curit%C3%A9-meilleures-pratiques/dp/2100504762/ref=sr_1_5/171-8599826-6836269.

File Block now available in Office 2003

Many attackers are targeting the Office file formats. Microsoft has shipped several patches to address specific issues. Last week as part of Patch Tuesday updates, Microsoft added the ability to block specific file formats from being opened in Office 2003. This feature was already available in Office 2007. This feature allows registry keys to restrict specific types of files that should be opened for a specific Office application. For example, to prevent Microsoft Word 2003 from opening the .doc and .dot file formats the following DWORD name can be added with the value 1.

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Word\Security\FileOpenBlock\RtfFiles



More information on File Block is available here - http://support.microsoft.com/kb/922850. When an attempt is made to open a blocked file type, the load is aborted and the user is told, "You are attempting to open a file type that is blocked by your registry policy setting." I suspect Microsoft will provide File Block as mitigation in future security bugs against specific file formats.



Later this week, I'll post more information about how this plays together with the upcoming Microsoft Office Isolated Conversion Environment (MOICE) tool.

Cool testing note - Try blocking .doc files (BinaryFiles key) with File Block. Then rename a .doc file to .rtf and try to open the file in Word. File is still blocked! That’s right – the check is on the contents not the file extension.

Bypassing arbitrary URL redirection/relative URL checks

Background: Phishing attacks sometimes attempt to gain a victim’s trust by leveraging web pages that allow arbitrary URL redirection. For example, let’s say the attacker is targeting victims who have accounts with a popular bank named WoodGrove Bank. If the bank’s web site (http://www.woodgrovebank.com/) contains a page that takes a URL as input and redirects to that URL, an attacker could make the input URL the URL of his phishing site. The phishing email might contain a URL that looks like http://www.woodgrovebank.com/redir.aspx?URL=http://www.badguy.com. The second part of this URL (badguy.com) could be obfuscated to confuse the user on where the link will bring the victim. Often victims will look at the first part of a link to determine where they end up. In this case the page finally loaded in the web browser is on badguy.com and could look like a page on woodgrovebank.com. If the user isn’t careful, he might be fooled into disclosing account information to badguy.com.

Common mitigation: When URL redirection functionality is present on a site it is commonly mitigated by one of two methods.

1. Redirection by ID – Instead of taking a URL as input, the site has a list of URLs where redirection is allowed. Instead of passing in the full URL, an identifier is passed in to represent the redirection URL. For example: http://www.woodgrovebank.com/redir.aspx?ID=27 might redirect to http://www.microsoft.com/ie.
   
   
2. Redirection to only relative URLs – If redirection only needs to be supported within the same domain, it is common to check the URL and redirect only if it is on the same domain (a relative URL).

Defeating the security check: The first method of mitigation is good from a security standpoint - the attacker can no longer send in the redirection URL. The second method allows the attacker to control the URL, but places some constraints on the URL. How might a developer implement a check for relative URLs? Perhaps he would verify the URL begins with slash ‘/’. Relative URLs like /accounts/login.aspx would be allowed, but URLs like http://www.badguy.com/ would be rejected. Looks good, but how might this go wrong?

What if a URL looks like //www.example.com? It passes the relative URL test (first char is a slash), but it actually redirects the browser to http://www.example.com/. This works with both server-side redirection (HTTP 30x with Location header) and client-side redirects (setting document.location, window.location.replace, etc).

Test cases to defeat relative URL checks like this include the following:

• //www.example.com
• And of course encoded variations of the cases above.

Works with both Internet Explorer and FireFox.

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.

Similarities in lock picking and testing software security
There are many parallels between lock picking and testing software security. To take advantage of a physical lock or software, it helps significantly to understand the target’s internal implementation details.

A while back Jason Lynn posted a video showing how to make a lock pick shim from a soda can. The shim technique is very effective against combination locks like the one shown below. Jason’s video is mentioned in the first chapter of Hunting Security Bugs, but it hard to find online now. For those searching for it, I've posted a copy I found on my local hard disk here - http://www.securitybughunter.com/videos/JasonLynn%20PopCan%20Shim.avi (7,306 kb). It was encoded using the DivX codec.