Our speaker this week, Brad, introduced us as the type of guy that is more on the Dark Arts side of DAtDA. His job focused on exploiting vulnerabilities and revealing them to clients.
Windows uses WinDbg, which is basically Windows’ version of GDB. We got to try it hands on with a program that he developed named FSExploitMe. It’s an ActiveX based exploit that works only on Internet Explorer. Starting it up then attaching WinDbg to the process would allow us to see its effect on the stack/heap. Most of the code looked like Assembly, which was something I learned nearly 2 years ago, so I didn’t remember the registers that well, fortunately, Brad set up a great demonstration with willing volunteers to help demonstrate how a function manipulates the stack.
The main point of vulnerability we focused on was “memory corruption”. That means to access memory in a way that causes an undefined behavior, or unintended behavior. Some examples of this are uninitialized memory, or array index calculations.
Brad introduced talked a little bit about a tool named Metasploit, which is an open-source piece of software that is used for penetration testing in a network. It’s meant for use by professionals to use, but because it’s open-source, anyone can use it.
Metasploit contains a database of “quality-assured” exploits for use, which of course means amateur “hackers” can use it to help them break into restricted systems, but fortunately, the payloads in Metasploit aren’t great at covering tracks, so it’s used mainly for learning how to deliver your own payload.
The stack is a data structure used to hold information. You can push stuff onto it, and pop stuff off the top.
The register EBP points to the base, or bottom of the stack, and the register ESP points to the top/end of the stack, where things are pushed off the stack.
We saw in class a theoretical exploit where memory overflowed into the other variables in the stack, because the data is usually stored sequentially, so if you overflow from the top of the stack, it will invade the space of the variable below it.
The bytes to represent the “jump esp” instructions are ffe4, so giving the address for the byte ffe4 to the module will force a jump to esp. Fortunately, this method won’t work on modern operating systems because they have been patched.
So the basic steps to actually accomplish code execution as seen above, we had to use the “msfPatternString” to find the offset. Then loading byakugan with “!load byakugan” gave us the offset on eip, which ended up being 1028.
Then, we changed the variable back to MakeString(1028/2), we had to divide by two because it would return 2 bytes for every 1 bytes requested. Now we could look for “jump esp” so we could put our shellcode in. The address ended up being 55442437, but we had to enter the bytes in reverse order. Then we had to add in 4 extra bytes because there was a “ret 4” that was popping arguments off the stack. Finally, we could add our shell code in, which was already coded for us, which gave us the calculator.
Windows has a functionality that lets programs use a special heap that gives some extra special debugging info, we enabled it for Internet Explorer.
+hpa : enables page heap
+ust: enables user stack tracing
This creates a registry flag in the registry that basically says to use the special page heap.
The point of this special heap is to help us create a use-after-free exploit, which is what it sounds like. It frees an object, replaces it with our object, which has the same size and allocations, then we position our shell code and use the object, which would end up executing our code. This lesson was also included with the FSExploit files.