Windows Exploit development tutorial series--heap spray II-vulnerability warning-the black bar safety net

Hello everyone, welcome back to this part of the tutorial stack injection Part 2. This tutorial will guide you in IE8 on the use of precision heap spraying.
There are two basic scenarios that require you to use very precise heap spray: the
(1)You have to deal with DEP protection case, you will need to perform the process from your ROP chain starts.
(2)you use the Use-After-Free, need to meet the virtual functions of some of the data processing process.
I want to find a deal this two problem examples, but many such vulnerabilities is quite a complex, not necessarily suitable as a tutorial.
It should be understood that the two truth. First, practice hands-on is the best, find the vulnerabilities, put them in the difficulty of separately, to solve some difficulties, try harder, and then reduce the difficulty, the cycle continues to continue. Secondly, this tutorial does not concern a vulnerability analysis, because these tutorials are about writing exploits and how to overcome them when you will face obstacles.
Today we look at MS13-009 this vulnerability, here you can find the metasploit module. If you want to better understand this Chapter of the tutorial content, I strongly recommend the following To add some links to reading material.
Debugging machine:
Windows XP SP3 with IE8
Links:
Exploit writing tutorial part 11 : Heap Spraying Demystified (corelan) - here
Heap Feng Shui in JavaScript (Alexander Sotirov) - here
Post-mortem Analysis of a Use-After-Free Vulnerability (Exploit-Monday) - here
Heap spraying in Internet Explorer with rop nops (GreyHatHacker) - here
CVE-2013-0025 MS13-009 IE SLayouRun (Chinese analysis of ms13-009, you will probably need to load this from the google cache) - here
Description
I think this topic needs some introduction, but you will find many obstacles, your not strange. I will not delve into all the more subtle point, because it will take a lot of time. If here some of the techniques are not familiar, I suggest you read this tutorial series Part 7 for return to programming, and Section 8 portion of the stack injection[Chapter 1: can control EIP] on.
We talk about Use-After-Free, you need to understand what is virtual table. C++language allows a base class define a virtual function. Base class derived class can also define your own function(and virtual functions with the same name) is. Therefore, a virtual function allows derived classes to replace the base class function. The compiler will ensure that whenever the calling object is actually a derived class always calls the replacement. All of this happens at runtime. The virtual table contains a pointer to the base class in the definition of the function pointer. When needed at runtime when the function is called, according to the needs of its derived classes from the virtual tables, select the appropriate pointer. We can see the following graphical representation.
! [](/Article/UploadPic/2017-3/201732174259512. png? www. myhack58. com)
1.1
Use-After-Free vulnerability is usually quite complex, the reason is because the cases vary. Usually the implementation process works like this:
（1）at a time an object is created and associated with a vtable is associated;
（2）The object is a vtable pointer to call. If we release the object when it is before the call, the program will crash when it later tries to call the object, for example: it tries to use the object after it is released - UAF is.
In order to use this problem, we will typically perform the following steps:
（1）at some point create an object;
（2）We on this object after the trigger is released;
（3）to create our own object, the object size as much as possible with the last-created object size close;
（4）the future when the vtable pointer is called, we create a fake object will be used, we gain code execution.
This sounds very complex, but through the examples of the presentation will become simple. First, we will create a reliable heap spray, and then we will focus on ms13-009 on!
Heap the Shellcode
As we explained in Section 8, did, I think from IE8 to obtain reliable spray injection start. To continue our prior do the job, to modify our previous POC. This POC has gone from Part 8 in a version slightly modified. Here the main difference is I’ve added an alloc function, it will be our buffer as input, to adjust the distribution size, so that they match the BSTR specification, we need to subtract 6 to compensate for the BSTR head and tail and divided by 2, because we use unicode unescape it.
! [](/Article/UploadPic/2017-3/201732174259382. png? www. myhack58. com)
Let us use the windbg debugger to see when we perform this injection is what will happen.
! [](/Article/UploadPic/2017-3/20173217430592. png? www. myhack58. com)
! [](/Article/UploadPic/2017-3/20173217430382. png? www. myhack58. com)
The image below is our jet representation. We have filled 150mb of our own data, which 150mb is divided into 150 blocks of 1mb each block is stored as a separate BSTR object. This BSTR object and populate the contain our shellcode and our NOP 0x1000 hex（4096 bytes of the block.
! [](/Article/UploadPic/2017-3/20173217430102. png? www. myhack58. com)
1.2
Until now also very good! Next, we need to realign our heap spray, so that the shellcode variable completely points to 0x0c0c0c0c, which will be our ROP chain starts. Consider if 0x0c0c0c0c is allocated in memory somewhere, because our stack injection, then it must have a specific offset in our 0x1000 block. We have to do is to calculate from the start of the block to 0x0c0c0c0c offset, and as a filling to add to our injection.
! [](/Article/UploadPic/2017-3/20173217430786. png? www. myhack58. com)
If you re-run the above injection, you will notice that 0x0c0c0c0c will not always point to the same heap, but from our 0x1000 hex block to 0x0c0c0c0c the offset will always remain the same. We already have to calculate padding size required for all of the information.
! [](/Article/UploadPic/2017-3/20173217430915. png? www. myhack58. com)
Let us modify the POC and in the debugger, re-run the injection.

[1] [2] [3] [4] next