PWB in the Caribbean, Part 3

In Part 2 of our series of posts on the recent PWB in the Caribbean course, Johnny was desperately seeking an exit from the upcoming pain that is exploit development. However, he didn’t come up with an escape plan quickly enough and his tale continues in this latest diary entry.

“Let me not hack myself for a sec…” Muts

Within minutes, he was tracing through some code. He clicked a few buttons in Immunity Debugger, changed one JMP instruction to a JNZ and bypassed a registration screen in a piece of windows software. (He also explained that he had purchased the software, and explained the ethical dilemma caused by this type of activity). Muts made it look so simple and I was stunned to realize that I actually understood what he was doing. He unfolded the demo with such finesse that even a noob like me understood the concepts. It was like magic.

Muts whisked us over to the Exploit Database and pointed out a Windows remote overflow exploit. With the vulnerable service already loaded on our student VM, he walked through the serviceʼs code in the debugger, explaining how it worked and then directed us to a very basic python script that connected to the service and fed it data. He was fuzzing the application, searching for the vulnerable input vector. It was new stuff for me and it was relatively advanced, but like the simple JMP-turned-JNZ from the previous exercise, I understood what was going on. Muts had this way of making advanced topics actually make sense.

Eventually, the service barfed and Muts flipped back to the debugger. He stepped through the code, revealing exactly what had happened when the buffer finally overflowed. There were familiar terms like “stack” and “EIP” and “NOP sled”. I knew the terms, but I had never actually seen them put to use. Muts flipped over to Metasploit, generated shellcode, encoded it and stuffed it into the ever-growing python fuzzer script.

He launched the script and just like that, he had shell, and much to my surprise, I understood exactly how it happened.

The demo took about a half hour and my posture gradually improved as he rolled through it. I wasnʼt slumped in my chair on the brink of despair anymore. I was sitting upright on the edge of my seat, hungry for more. The rest of the class was fully engaged as well. Then Muts spoke up. “Now, itʼs your turn.” I was thrilled. I so wanted to do this.
Muts was still talking, probably giving us advice, but I didnʼt hear a word he said. I was firing up my debugger, launching the vulnerable service and fuzzing my way through the exercise. I knew this feeling well, but after years of pen testing and years of semi-retirement, I had almost forgotten how this felt. It was amazing. With my environment set up and my adrenaline pumping, I flipped over to the debugger and froze.

“What button did he click in the debugger to set a breakpoint?” I thought.

The details were in the lab guide, so I started flipping through the pages to figure out the finer details I had already forgotten from the demo. At first, it was a color-by-numbers affair, but after a while, things started making more sense as I gained confidence with not only the applied concepts, but the syntaxes and mechanisms of the tools.
Iʼd like to say that everything worked out perfectly for me during this exercise. Iʼd really like to say that. But eventually I hit a brick wall. No matter what I did, I couldnʼt get my shellcode to execute. I doubled checked my offsets and stepped through my exploit in the debugger. Everything looked great until my shellcode began to execute and then.. nothing.

No one else seemed to be having this problem and most of the other students already had shell. I should have asked for help, but pride got the better of me and I feverishly worked through the break to sort out the problem. This was a mistake. My frustration was mounting and the clock was ticking. With the break nearing an end, I let out the faintest squeak of a plea for help and the instructors immediately started tag-teaming the problem to get me through the exercise. I was amazed at their competence. They flew through the debugger and tore through my code and came up with a consensus: I had an “off by one” issue and to make matters worse, Metasploit was, for some unknown reason, producing bad shellcode. It was reproducible and only happened on my machine. After a few tweaks to the work environment, my code executed without modification. My own code produced a shell. Needless to say, I was thrilled!

The instructors were a great encouragement, telling me that “off-by-oneʼs are common” and that they, “hadn’t seen Metasploit do that before,” and that, “I had done really well.” I came away with a great deal of respect for the instructors. They took the time to help one struggling student so that no one would be left behind. They did this time and time again, not just for the “celebrity student” but for anyone that ran into a problem. During each exercise, the full staff was out of their seats, moving through the class looking for opportunities to help.
In my case, their diligence helped me turn a corner. I was really in the pit of despair when I eventually let on that I was struggling, but that didnʼt diminish the excitement I felt when I got that shell, because I knew, for the first time, every detail that made that shell possible. This was not at all like the thousands of shells I had popped thanks to someone elseʼs exploit.

And just like that, all my experience in the field was amplified and became crystallized. I was envious of the students in the class that were just beginning their careers in pentesting because their perspectives on security would have a clarity that mine had been lacking for far too long.

If you would like to experience the thrill of developing your first exploit or are looking to take your exploit skills to the next level, we are running both the Pentesting with BackTrack and Advanced Windows Exploitation courses in beautiful St. Kitts in March. Sign-up today while there are still seats left. No whining later!