31 Mar 2010
A bit of a housekeeping post here, where I am just going to provide some links for cool stuff I have seen recently and provide some updates on some things mentioned in other blog posts.
First of all... the trojan. Im still planning to write a malware detection and analysis style post using it as an example, but when I actually started writing the thing it started to grow out of all proportion to what I initially expected, and I have been far too busy (lazy) recently to do the thing justice and finish it properly. But its coming soon.
If you were waiting on me to tell you how to get rid of the trojan, stick the commands I have provided below in a batch file and run it from a command line until:
- the adobeupdatemanager.exe, osa.exe and MPSvc.exe processes are dead (you should see ERROR: The process "x" not found in the output from taskkill, and the processes will disappear from Task Manager or tasklist), AND
- the files referenced are gone (they are hidden system files by default so set the appropriate view options in Windows Explorer).
You may need to run it a few times (fast), or run it in a never ending loop (e.g. "for /L %a in (1,0,1) do killtrojan.bat" ) and CTRL-C to kill because the processes can restart each other pretty quickly, and you have to kill the process before deleting the files.
The commands for the batch file:
attrib -S -H "C:\Program Files\Adobe\AdobeUpdateManager.exe"
attrib -S -H "C:\Program Files\Microsoft Office\Office11\OSA.exe"
attrib -S -H "C:\Program Files\Windows Defender\MPSvc.exe"
taskkill /IM adobeupdatemanager.exe /IM osa.exe /IM MPSvc.exe
del "C:\Program Files\Windows Defender\MPSvc.exe"
del "C:\Program Files\Adobe\AdobeUpdateManager.exe"
del "C:\Program Files\Microsoft Office\Office11\OSA.exe"
There are a few registry entries as well which you can track down and delete if you wish (its not strictly necessary if the files are deleted) - but be careful of this if you are not familiar with the purpose of the registry keys in question. Find the appropriate entries by searching for the process name using regedit, and delete as appropriate. Google the entry or key name if you're not sure what it does before you delete.
You can also just nuke the machine from orbit to get rid of the trojan ;)
Second, a (non-trojaned this time) version of the vulnerable version of BigAnt server to use to reproduce my second exploit tutorial? Lincoln tells me that this is such a beast. I haven't tested it myself yet to confirm its vulnerable, which is why I havent linked it from the main tutorial myself yet, but if you're desperate to get going with that you can give that version a bash. If it works for you let me know and I will update the tutorial with the link.
Thirdly, PDF exploiting with Didier Stevens! Now malicious PDF documents are nothing new, but this method does not use an exploit, and instead makes use of inbuilt PDF functionality to run executable content from within a PDF. Very cool. Here and here.
If you read the Offensive Security Blog you may have seen the two part malicious zipfile exploit tutorial from Peter Van Eeckhoutte. If not, its posted here on his blog in one big document. Very cool, and what's more it covers off on a exploit with a lot of bad characters, which is simething I have been intending to do for a while in one of my own tutorials (so it saves me from having to write that myself - Excellent ;) )
Fifthly, this is an interesting looking site I found posted on the Internet Storm Center Diary. Maybe a slightly more up to date replacement for sectools.org?
31 Mar 2010
A little while back I received a question from a blog reader asking about the difference between heap overflows and use after free vulnerabilities, and I thought it would make a good topic for a blog post, so here goes.
Now, to answer this question I am first going to have to explain something about memory management, so prepare yourself for reams of dry theory...
There are two main types of data structures in a process that are used for memory management, the stack and the heap. The stack is a LIFO (last in first out) structure, that is used mainly for storage of local variables and data related to function calls. It works very much like a stack of plates, in that you can only add or remove entries from the top of the "stack". If you want to remove the second "plate" on the stack, you need to remove the one above it first. The stack is a very simple structure, and has its own registers and instructions in the X86 processor and assembly language which are used to manage access to it.
The heap is a memory storage area used by a process to store global variables, or variables too large to be stored on the stack. The heap does not have dedicated registers or instructions in the X86 processr/assembly language, and instead is managed by higher level functions, generally written in the C programming language and included with an Operating System such as Microsoft Windows, or GNU/Linux.
From an exploitation perspective, these differences between the management methods of the stack and the heap make it much more difficult to follow changes to the heap in an assembly level debugger like OllyDbg when compared to following changes to the stack, and it also makes heap based exploits more difficult to develop than stack based exploits. However, this added level of complexity involved in heap management also provides opportunities for different types of exploitable vulnerabilities to occur. So in addition to buffer overflows, which can occur both on the stack and the heap, the heap is also subject to use after free vulnerabilities.
Considering that the use after free vulnerabilities arises because of the additional complexity introduced by the heap management process, we will need to understand how the heap works and how it is managed to understand use after free and heap overflow vulnerabilities, as well as how they differ. We will use the heap management methodology of the Windows Operating System as an example.
In the Windows Operating System, each process has one or more heaps used to store program data, a default process heap and a variable number of globally accessible dynamic heaps that can be created via the HeapCreate() function. Each of these heaps can have arbitrary sized areas of memory allocated for use by a variety of different calls such as malloc(), HeapAlloc(), LocalAlloc(), GlobalAlloc() or RtlAllocateHeap().
There also must be a way to free heap entries, so that the space in the heap can be reused when no longer needed. Functions such as HeapFree() and HeapReAlloc() are used to free or reallocate entries on the heap.
A method is also need to keep track of the allocated space on the heap. This is done by the use of a number of structures located at the beginning of the heap, as well as headers located before each heap entry, that are used to indicate where entries have been allocated within the heap. Both allocated heap entries and free space within the heap have their own types of headers. The various heap management functions mentioned above make use of these structures when assigning and freeing space on the heap, and in a similar vein, heap based exploits make use of these same heap management functions to take control of the CPU by feeding them corrupted heap data.
Specifically, heap overflows work by overflowing areas of heap memory and overwriting the headers of the next area in memory, which might contain either another used heap entry or a free section of the heap (both of which will have a header as described earlier). Then, when a heap management operation (such as allocating a new entry) is made on the area of the heap following the overwritten block, and the mangled header is accessed by the header management function, an exception will occur which under the right conditions can be exploited. As mentioned before, since exploitation of these vulnerabilities involves manipulation of the heap management functions, its important to be aware that if those functions change (such as when safe unlinking support was added in the heap management functions in Windows XP SP2), exploitation of some heap overflow vulnerabilities can become much more difficult (or perhaps impossible).
Use after free exploits operate slightly differently from heap overflows. They require that a heap entry be created (e.g. using HeapAlloc), freed (HeapFree), and then used again after the free operation has been performed. When these supposedly freed heap entries are "used", this can result in an opportunity to take control of execution of the process.
To see an example of a use after free exploit, you can check out this blog entry. In the example, we allocated memory on the heap and assigned a pointer (Element1), freed that heap entry (by setting the parent SpanID object of Element1 to a null value), overwrote that freed entry (via multiple calls to the FOverwrite function), and then accessed the original heap entry by referencing its pointer (var a = Element1.srcElement). This enabled us to take control of the process and execute arbitrary code.
That's a high level overview of the differences between heap overflows and use after free exploits. To learn more, you can check the list of references below.
The Shellcoders Handbook
http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
http://www.cybertech.net/~sh0ksh0k/heap/CSW04%20-%20Reliable%20Windows%20Heap%20Exploits.ppt
http://www.symantec.com/connect/articles/new-way-bypass-windows-heap-protections
http://blogs.technet.com/srd/archive/2009/05/26/safe-unlinking-in-the-kernel-pool.aspx
http://blogs.technet.com/srd/archive/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities.aspx
http://www.blackhat.com/presentations/bh-usa-09/MCDONALD/BHUSA09-McDonald-WindowsHeap-PAPER.pdf
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Marinescu.pdf
http://www.cybertech.net/~sh0ksh0k/heap/XPSP2%20Heap%20Exploitation.ppt
http://cwe.mitre.org/data/definitions/416.html
http://cwe.mitre.org/data/definitions/122.html
