Wednesday, March 31, 2010

Links and trojans and zipsploits, oh my!

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

The Difference Between Heap Overflow and Use After Free Vulnerabilities

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

Friday, March 19, 2010

Uh oh! Trojan!

Apparently you cant trust anyone these days.  Including me it seems ;).

In my second exploit tutorial I talked about how to exploit a vulnerability in BigAnt Server 2.52, and I provided a link to the vulnerable application from the Exploit-DB.  On the 27th of February, I noticed that the Exploit-DB download link for the vulnerable application had been removed, with no explanation as to why, so in order to allow people to follow along with the tutorial I found my own copy of the installer that I had myself retrieved from the Exploit-DB, and I made it available to people.

Now I have found out that that this installer includes an added little "bonus", in the form of a Trojan that gets installed as soon as you run the installer (and before you actually install BigAnt Server).

The Trojan runs as both a fake Adobe Update Manager as well as a fake Microsoft Office Startup Agent.  Both processes monitor the other and will restart each other if the process is stopped for any reason.  In order to successfully kill them you can create a batch file which uses taskkill command to stop and then the del command to delete the underlying executables.  Doing it manually via Task Manager and then trying to delete the file in Windows Explorer  wont work, as the program will get restarted before you can delete the file on disk.  I will post a more detailed post in a little while going over in more detail how to remove and (for the brave and interested) how to analyse these files to determine what they do.

If you have already installed this version of BigAnt, either from the Exploit-DB or the version that I provided, you can remove the Trojan files using the method described above.  SysInternals Process Explorer will show you the running processes and you can track down the exact file location from there and kill and delete them via a batch script in order to catch them before one restarts the other.  There are also startup entries in the Registry that start the Trojan files along with the system, but if you delete the executables there will be nothing for those registry entries to start. 

I had actually noticed this Trojan myself after finishing the BigAnt exploit (and Im quoting most of the removal instructions above from memory), however I do so many questionable things on that test system I didnt link it to the BigAnt installer.  I just removed it, with the intention of maybe making a blog entry about it at some later date, and moved on.

So what is the lesson to take away from this?  Beware of things you download from the Internet essentially, especially when visiting computer security related sites.  Im guessing that while the Exploit-DB people take reasonable care in submissions they receive, that they don't perform detailed analysis of submitted files beyond maybe a virus scan (and even now the virus scanner I use did not pick up any problem with the installer itself).   And I didn't perform any additional checks on the file myself, because I was only ever using it on a test virtual machine which I had sandboxed, so I was already treating it as untrusted.

Its not only files that come from security sites you can't trust either.  Seemingly legitimate programs as well as scripts you find on the Internet  and definitely some of the public exploits you may find could all be hazardous to your computer's health. So, when testing out any software from an untrusted location on the Internet, always run it in a sandboxed environment first.