gray hat hacking the ethical hackers handbook phần 9 docx

Gray Hat Hacking: The Ethical Hacker’s Handbook 432 First, the attackers copy their attack DLL into the directory where the tool will be run. Remember that these attackers have been granted FILE_ADD_FILE. The attack.dll is coded to do bad stuff in DllMain and then return execution back to the real DLL. Next the attackers create a new file in this directory called [program-name].exe.manifest. In this example, the attacker’s file will be accesschk.exe.manifest. C:\tools>type accesschk.exe.manifest <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="6.0.0.0" processorArchitecture="x86" name="redirector" type="win32" /> <description>DLL Redirection</description> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> </dependentAssembly> </dependency> <file name="user32.dll" /> </assembly> It’s not important to understand exactly how the manifest file works—you can just learn how to make it work for you. You can read up on manifest files at http:// msdn2.microsoft.com/en-gb/library/ms766454.aspx if you’d like. Finally, let’s simulate the administrator running AccessChk. The debugger will show which DLLs are loaded. C:\tools>c:\Debuggers\cdb.exe accesschk.exe Microsoft (R) Windows Debugger Version 6.5.0003.7 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: accesschk.exe Executable search path is: ModLoad: 00400000 00432000 image00400000 ModLoad: 7c900000 7c9b0000 ntdll.dll ModLoad: 7c800000 7c8f4000 C:\WINDOWS\system32\kernel32.dll ModLoad: 7e410000 7e4a0000 C:\tools\USER32.dll ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll ModLoad: 763b0000 763f9000 C:\WINDOWS\system32\COMDLG32.dll ModLoad: 77f60000 77fd6000 C:\WINDOWS\system32\SHLWAPI.dll ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll Bingo! Our attack DLL (renamed to user32.dll) was loaded by accesschk.exe. Attacking Weak File DACLs File DACL attacks are similar to directory DACL attacks. The focus is finding files writable by untrusted or semi-trusted users and used by a higher-privileged entity. Some of the directory DACL attacks could be classified as file DACL attacks but we’ve chosen to call attacks that add a file “directory DACL attacks” and attacks that tamper with an exist - ing file “file DACL attacks.” Enumerating Interesting Files’ DACLs We can again use accesschk.exe to enumerate DACLs. There are several interesting attacks involving tampering with existing files. Write to executables or executable equivalent files (EXE, DLL, HTA, BAT, CMD). Cases of vulnerable executables can be found fairly easily by scanning with a similar AccessChk command as that used for directories. C:\tools>accesschk.exe -w -q -s users c:\ > weak-dacl-files.txt When this command finishes, look for files ending in .exe, .dll, .hta, .bat, .cmd, and other equivalent files. Here are some interesting results potentially vulnerable to tampering: RW c:\Program Files\CA\SharedComponents\ScanEngine\arclib.dll RW c:\Program Files\CA\SharedComponents\ScanEngine\avh32dll.dll RW c:\Program Files\CA\SharedComponents\ScanEngine\DistCfg.dll RW c:\Program Files\CA\SharedComponents\ScanEngine\Inocmd32.exe RW c:\Program Files\CA\SharedComponents\ScanEngine\Inodist.exe RW c:\Program Files\CA\SharedComponents\ScanEngine\Inodist.ini RW c:\Program Files\CA\SharedComponents\ScanEngine\InoScan.dll Let’s look more closely at the DACL, first on the directory. C:\Program Files\CA\SharedComponents\ScanEngine RW BUILTIN\Users FILE_ADD_FILE FILE_ADD_SUBDIRECTORY FILE_APPEND_DATA FILE_EXECUTE FILE_LIST_DIRECTORY FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA FILE_TRAVERSE FILE_WRITE_ATTRIBUTES FILE_WRITE_DATA FILE_WRITE_EA SYNCHRONIZE READ_CONTROL We know that FILE_ADD_FILE means we could launch directory attacks here. (FILE_ ADD_FILE granted to Users on a directory inside %ProgramFiles% is bad news.) How - ever, let’s think specifically about the file tampering and executable replacement attacks. Notice that FILE_DELETE_CHILD is not present in this directory DACL, so the directory Chapter 16: Exploiting Windows Access Control Model for Local Elevation of Privilege 433 PART IV DACL itself does not grant access to directly delete a file and replace it with an .exe of our own. Let’s take a look at one of the file DACLs. C:\Program Files\CA\SharedComponents\ScanEngine\Inocmd32.exe RW BUILTIN\Users FILE_ADD_FILE FILE_ADD_SUBDIRECTORY FILE_APPEND_DATA FILE_EXECUTE FILE_LIST_DIRECTORY FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA FILE_TRAVERSE FILE_WRITE_ATTRIBUTES FILE_WRITE_DATA FILE_WRITE_EA SYNCHRONIZE READ_CONTROL DELETE is not granted on the file DACL either. So we can’t technically delete the .exe and replace it with one of our own, but watch this: C:\Program Files\CA\SharedComponents\ScanEngine>copy Inocmd32.exe inocmd32_ bak.exe 1 file(s) copied. C:\Program Files\CA\SharedComponents\ScanEngine>echo hi > inocmd32.exe C:\Program Files\CA\SharedComponents\ScanEngine>copy inocmd32_bak.exe inocmd32.exe Overwrite inocmd32.exe? (Yes/No/All): yes 1 file(s) copied. C:\Program Files\CA\SharedComponents\ScanEngine>del Inocmd32.exe C:\Program Files\CA\SharedComponents\ScanEngine\Inocmd32.exe Access is denied. DELETE access to the file isn’t necessary if we can completely change the contents of the file! Tamper with configuration files. Pretend now that the EXEs and DLLs all used strong DACLs. What else might we attack in this application? C:\Program Files\CA\SharedComponents\ScanEngine>c:\tools\accesschk.exe -q -v Users inodist.ini RW C:\Program Files\CA\SharedComponents\ScanEngine\Inodist.ini FILE_ADD_FILE FILE_ADD_SUBDIRECTORY FILE_APPEND_DATA FILE_EXECUTE FILE_LIST_DIRECTORY FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA FILE_TRAVERSE FILE_WRITE_ATTRIBUTES Gray Hat Hacking: The Ethical Hacker’s Handbook 434 FILE_WRITE_DATA FILE_WRITE_EA SYNCHRONIZE READ_CONTROL Writable configuration files are a fantastic source of privilege elevation. Without more investigation into how eTrust works, we can’t say for sure, but it’s likely that con - trol over a scan engine initialization file could lead to privilege elevation. Sometimes you can even leverage only FILE_APPEND_DATA to add content that is run by the appli - cation on its next start. TIP Remember that notepad.exe and common editing applications will attempt to open for Generic Read. If you have been granted FILE_APPEND_ DATA and the AccessCheck function returns “access denied” with the testing tool you’re using, take a closer look at the passed-in desiredAccess. Tamper with data files to attack the data parser. The other files that jumped out to me in this weak DACL list were the following: RW c:\Program Files\CA\eTrust Antivirus\00000001.QSD RW c:\Program Files\CA\eTrust Antivirus\00000002.QSD RW c:\Program Files\CA\eTrust Antivirus\DB\evmaster.dbf RW c:\Program Files\CA\eTrust Antivirus\DB\evmaster.ntx RW c:\Program Files\CA\eTrust Antivirus\DB\rtmaster.dbf RW c:\Program Files\CA\eTrust Antivirus\DB\rtmaster.ntx We don’t know much about how eTrust works but these look like proprietary signa- ture files of some type that are almost surely consumed by a parser running at a high privilege level. Unless the vendor is particularly cautious about security, it’s likely that their trusted signature or proprietary database files have not been thoroughly tested with a good file fuzzer. If we were able to use Process Monitor or FileMon to find a repeatable situation where these files are consumed, chances are good that we could find vulnerabilities with a common file fuzzer. Always be on the lookout for writable data files that look to be a proprietary file format and are consumed by a parser running with elevated privileges. “Write” Disposition Permissions of a File FILE_WRITE_DATA Depending on file, possible elevation of privilege. Allows an attacker to overwrite file contents. FILE_APPEND_DATA Depending on file, possible elevation of privilege. Allows an attacker to append arbitrary content to the end of a file. WRITE_DAC Depending on file, possible elevation of privilege. Allows attackers to rewrite the DACL, granting themselves any file privilege. Chapter 16: Exploiting Windows Access Control Model for Local Elevation of Privilege 435 PART IV WRITE_OWNER Depending on file, possible elevation of privilege. Allows attacker to become the object owner. Object ownership implies WRITE_DAC. WRITE_DAC allows attacker to rewrite the DACL, granting any file privilege. GENERIC_WRITE Depending on file, possible elevation of privilege. Grants FILE_ WRITE_DATA. GENERIC_ALL Depending on file, possible elevation of privilege. Grants FILE_ WRITE_DATA. DELETE Depending on file, possible elevation of privilege. Allows attackers to delete and potentially replace the file with one of their choosing. “Read” Disposition Permissions of a File FILE_READ_DATA Depending on the file, possible information disclosure. Allows attacker to view contents of the file. FILE_READ_ATTRIBUTES FILE_READ_EA Depending on the directory, possible information disclosure. These rights grant access to the metadata of the file. Filenames could contain sensitive info such as “layoff plan.eml” or “plan to sell company to google.doc.” An attacker might also find bits of information like usernames usable in a multistage attack. GENERIC_READ Depending on the file, possible information disclosure. This right grants FILE_READ_DATA, FILE_READ_ATTRIBUTES, and FILE_ READ_EA. There are lots of scenarios where read access should not be granted to unprivileged attackers. It might allow them to read (for example): • User’s private data (user’s browser history, favorites, mail) • Config files (might leak paths, configurations, passwords) • Log data (might leak other users and their behaviors) eTrust appears to store data in a logfile readable by all users. Even if attackers could not write to these files, they might want to know which attacks were detected by eTrust so they could hide their tracks. Attacking Weak File DACLs for Privilege Escalation An attack was already demonstrated earlier in the enumeration section. To recap, the primary privilege escalation attacks against files are • Write to executables or executable equivalent files (EXE, DLL, HTA, BAT, CMD). • Tamper with configuration files. • Tamper with data files to attack the data parser. Gray Hat Hacking: The Ethical Hacker’s Handbook 436 What Other Object Types Are out There? Services, registry keys, files, and directories are the big four object types that will expose code execution vulnerabilities. However, several more object types might be poorly ACL’d. Nothing is going to be as easy and shellcode-free as the objects listed already in this chapter. The remaining object types will expose code execution vulnerabilities but you’ll probably need to write “real” exploits to leverage those vulnerabilities. Having said that, let’s briefly talk through how to enumerate each one. Enumerating Shared Memory Sections Shared memory sections are blocks of memory set aside to be shared between two appli - cations. This is an especially handy way to share data between a kernel mode and user mode process. Programmers have historically considered this trusted, private data but a closer look at these object DACLs shows that untrusted or semi-trusted users can write to them. AccessChk could dump all objects in the object manager namespace but could not yet filter by type at the time of this writing. So here’s the easiest way to find all the shared memory sections: accesschk.exe -osv > allobjects.txt Inside the output file, you can inspect each shared section by searching for “Type: Section”. Here’s an example: \BaseNamedObjects\WDMAUD_Callbacks Type: Section RW NT AUTHORITY\SYSTEM SECTION_ALL_ACCESS RW Everyone SECTION_MAP_WRITE SECTION_MAP_READ It’s almost never a good idea to grant write access to the Everyone group but it would take focused investigation time to determine if this shared section could hold up under malicious input from an untrusted user. An attacker might also want to check what type of data is available to be read in this memory section. If you see a shared section having a NULL DACL, that is almost surely a security vul - nerability. For example, I just stumbled across this one on my laptop while doing research for this chapter: \BaseNamedObjects\INOQSIQSYSINFO Type: Section RW Everyone SECTION_ALL_ACCESS The first search engine link for information about INOQSIQSYSINFO was a recent security advisory about how to supply malicious content to this memory section to cause a stack overflow in the eTrust antivirus engine. If there were no elevation of privi - lege threat already, remember that SECTION_ALL_ACCESS includes WRITE_DAC, Chapter 16: Exploiting Windows Access Control Model for Local Elevation of Privilege 437 PART IV which would allow anyone in the Everyone group to change the DACL, locking out everyone else. This would likely cause a denial of service in the AV product. Reference INOQSIQSYSINFO exploit www.milw0rm.com/exploits/3897 Enumerating Named Pipes Named pipes are similar to shared sections in that developers incorrectly used to think named pipes accepted only trusted, well-formed data. The elevation of privilege threat with weakly ACL’d named pipes again is to write to the pipe to cause parsing or logic flaws that result in elevation of privilege. Attackers also might find information dis - closed from the pipe that they wouldn’t otherwise be able to access. AccessChk does not appear to support named pipes natively, but SysInternals did cre - ate a tool specifically to enumerate named pipes. Here’s the output from PipeList.exe: PipeList v1.01 by Mark Russinovich http://www.sysinternals.com Pipe Name Instances Max Instances TerminalServer\AutoReconnect 1 1 InitShutdown 2 -1 lsass 3 -1 protected_storage 2 -1 SfcApi 2 -1 ntsvcs 6 -1 scerpc 2 -1 net\NtControlPipe1 1 1 net\NtControlPipe2 1 1 net\NtControlPipe3 1 1 PipeList does not display the DACL of the pipe but BindView (recently acquired by Symantec) has built a free tool called pipeacl.exe. It offers two run options—command- line dumping the raw ACEs, or a GUI with a similar permissions display as the Windows Explorer users. Here’s the command-line option: C:\tools>pipeacl.exe \??\Pipe\lsass Revision: 1 Reserved: 0 Control : 8004 Owner: BUILTIN\Administrators (S-1-5-32-544) Group: SYSTEM (S-1-5-18) Sacl: Not present Dacl: 3 aces (A) (00) 0012019b : Everyone (S-1-1-0) (A) (00) 0012019b : Anonymous (S-1-5-7) (A) (00) 001f01ff : BUILTIN\Administrators (S-1-5-32-544) The Process Explorer GUI will also display the security descriptor for named pipes. Gray Hat Hacking: The Ethical Hacker’s Handbook 438 Chapter 16: Exploiting Windows Access Control Model for Local Elevation of Privilege 439 PART IV References PipeList download location http://download.sysinternals.com/Files/PipeList.zip PipeACL download location www.bindview.com/Services/RAZOR/Utilities/Windows/ pipeacltools1_0.cfm Enumerating Processes Sometimes processes apply a custom security descriptor and get it wrong. If you find a process or thread granting write access to an untrusted or semi-trusted user, an attacker can inject shellcode directly into the process or thread. Or an attacker might choose to simply commandeer one of the file handles that was opened by the process or thread to gain access to a file they wouldn’t normally be able to access. Weak DACLs enable many different possibilities. AccessChk is your tool to enumerate process DACLs. C:\tools>accesschk.exe -pq * [4] System RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators [856] smss.exe RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators [904] csrss.exe RW NT AUTHORITY\SYSTEM [936] winlogon.exe RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators [980] services.exe RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators [992] lsass.exe RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators [1188] svchost.exe RW NT AUTHORITY\SYSTEM RW BUILTIN\Administrators Cesar Cerrudo, an Argentinean pen-tester who focuses on Windows Access Control, recently released a “Practical 10 minutes security audit” guide with one of the examples being a NULL DACL on an Oracle process allowing code injection. You can find a link to it in the “Reference” section. Reference Practical 10 minutes security audit Oracle case www.argeniss.com/research/ 10MinSecAudit.zip Enumerating Other Named Kernel Objects (Semaphores, Mutexes, Events, Devices) While there might not be an elevation of privilege opportunity in tampering with other kernel objects, an attacker could very likely induce a denial-of-service condition if Gray Hat Hacking: The Ethical Hacker’s Handbook 440 allowed access to other named kernel objects. AccessChk will enumerate each of these and will show their DACL. Here are some examples. \BaseNamedObjects\shell._ie_sessioncount Type: Semaphore W Everyone SEMAPHORE_MODIFY_STATE SYNCHRONIZE READ_CONTROL RW BUILTIN\Administrators SEMAPHORE_ALL_ACCESS RW NT AUTHORITY\SYSTEM SEMAPHORE_ALL_ACCESS \BaseNamedObjects\{69364682-1744-4315-AE65-18C5741B3F04} Type: Mutant RW Everyone MUTANT_ALL_ACCESS \BaseNamedObjects\Groove.Flag.SystemServices.Started Type: Event RW NT AUTHORITY\Authenticated Users EVENT_ALL_ACCESS \Device\WinDfs\Root Type: Device RW Everyone FILE_ALL_ACCESS It’s hard to know whether any of the earlier bad-looking DACLs are actual vulnerabil- ities. For example, Groove runs as the logged-in user. Does that mean a Groove synchro- nization object should grant all Authenticated Users EVENT_ALL_ACCESS? Well, maybe. It would take more investigation into how Groove works to know how this event is used and what functions rely on this event not being tampered with. And Process Explorer tells us that {69364682-1744-4315-AE65-18C5741B3F04} is a mutex owned by Internet Explorer. Would an untrusted user leveraging MUTANT_ALL_ACCESS -> WRITE_DAC -> “deny all” cause an Internet Explorer denial of service? There’s an easy way to find out! Another GUI SysInternals tool called WinObj allows you to change mutex security descriptors. Windows Access Control is a fun field to study because there is so much more to learn! We hope this chapter whets your appetite to research access control topics. Along the way, you’re bound to find some great security vulnerabilities. References www.grayhathackingbook.com WinObj download www.microsoft.com/technet/sysinternals/SystemInformation/ WinObj.mspx 441 CHAPTER 17 Intelligent Fuzzing with Sulley • Protocol analysis • Sulley fuzzing framework • Powerful fuzzer • Process fault detection • Network monitoring • Session monitoring In Chapter 14, we have covered basic fuzzing. The problem with basic fuzzing is that you often only scratch the surface of a server’s interfaces and rarely get deep inside the server to find bugs. Most real servers have several layers of filters and challenge/response mech- anisms that prevent basic fuzzers from getting very far. Recently, a new type of fuzzing has arrived called intelligent fuzzing. Instead of blindly throwing everything but the kitchen sink at a program, techniques have been developed to analyze how a server works and to customize a fuzzer to get past the filters and reach deeper inside the server to discover even more vulnerabilities. To do this effectively, you need more than a fuzzer. First, you will need to conduct a protocol analysis of the target. Next, you need a way to fuzz that protocol and get feedback from the target as to how you are doing. As we will see, the Sulley fuzzing framework automates this process and allows you to intelligently sling packets across the network. Protocol Analysis Since most servers perform a routine task and need to interoperate with random clients and other servers, most servers are based on some sort of standard protocol. The Internet Engineering Task Force (IETF) maintains the set of protocols that form the Internet as we know it. So the best way to find out how a server, for example, a LPR server, operates is to look up the Request for Comments (RFC) document for the LPR protocol, which can be found on www.ietf.org as RFC 1179. [...]... N/A +10: 41414141 (1 094 795 585) -> N/A +14: 41414141 (1 094 795 585) -> N/A Gray Hat Hacking: The Ethical Hacker’s Handbook 456 Analysis of Network Traffic Now that we have found some bugs in the target server, let’s look at the packets that caused the damage If you look in the sulley\audits\niprint_lpr_515 folder, you will find too many pcap files to sort through manually Even though they are numbered,... link them together into what is called a session You can start a request by using the s_initialize function, for example: s_initialize("request1") The only required argument for the s_initialize function is the request name PART IV Sulley Fuzzing Framework Gray Hat Hacking: The Ethical Hacker’s Handbook 444 Primitives Now that we have a request initialized, let’s build on that by adding primitives, the. .. you find that you have complete control over the contents of eip, then it becomes a matter of successfully directing eip to a location from which you can control the program Gray Hat Hacking: The Ethical Hacker’s Handbook 464 shellcode at the time you take control of eip Since the big question to be answered when constructing an exploit is “What is the address of my shellcode?”, finding that address... which the program attempted to read or write It will be PART IV Program received signal SIGSEGV, Segmentation fault 0x08048327 in main () Gray Hat Hacking: The Ethical Hacker’s Handbook 462 Figure 18-1 OllyDbg register display useful to note whether the offending register contains user-supplied values, as we can then assume that we can control the location of the read or write by properly crafting the. .. user input If there is no obvious relationship between the contents of any registers and the input that we have provided, the next step is to determine the execution path that led to the crash Most debuggers are capable of displaying a stack trace A stack trace is an analysis of the contents of the stack at any given time, in this case the time of the crash, to break the stack down into the frames associated... user-supplied data? • Was the program performing a read or write when it crashed? Initial Analysis Why did the program crash? Where did the program crash? These are the first two questions that need to be answered The “why” you seek here is not the root cause of the crash, such as the fact that there is a buffer overflow problem in function xyz Instead, initially you need to know whether the program segfaulted... to assist in patching the software, it is important to gain as detailed an understanding as possible about the nature of the problem It would be nice to avoid this conversation: Researcher: “Hey, your software crashes when I do this…” Vendor: “Then don’t do that!” 4 59 Gray Hat Hacking: The Ethical Hacker’s Handbook 460 In favor of this one: Researcher: “Hey, you fail to validate the widget field in your... understand the exact nature of the problem.” Vendor: “All right, thanks, we will take care of that ASAP.” Whether a vendor actually responds in such a positive manner is another matter In fact, if there is one truth in the vulnerability research business it’s that dealing with vendors can be one of the least rewarding phases of the entire process The point is that you have made it significantly easier for the. .. set the logging level to 5 in order to see more output during the process At this point, the process_monitor.py script is up and running and ready to attach to a process Gray Hat Hacking: The Ethical Hacker’s Handbook 452 Controlling VMware Now that we have our target set up in a virtual machine and saved in a snapshot, we can control it from the host with the vmcontrol.py script We will launch the. . .Gray Hat Hacking: The Ethical Hacker’s Handbook 442 Here is an excerpt from the RFC 11 79 (see reference: www.ietf.org/rfc/rfc11 79. txt): "3.1 Message formats LPR is a a TCP-based protocol The port on which a line printer daemon listens is 515 The source port must be in the range 721 to 731, inclusive A line printer daemon responds to . Gray Hat Hacking: The Ethical Hacker’s Handbook 432 First, the attackers copy their attack DLL into the directory where the tool will be run. Remember that these attackers have. attack the data parser. Gray Hat Hacking: The Ethical Hacker’s Handbook 436 What Other Object Types Are out There? Services, registry keys, files, and directories are the big four object types that. denial-of-service condition if Gray Hat Hacking: The Ethical Hacker’s Handbook 440 allowed access to other named kernel objects. AccessChk will enumerate each of these and will show their DACL. Here are