Just got back the other day from Melbourne and Ruxcon. Awesome and fantastic ‘con for aussies. 2 days of great talks and copious alcohol.

If you’ve had your head in the sand and not noticed, I presented a talk at Ruxcon!

My talk was based on 2 incidents that happened at work and how they stepped sideways from your normal attacks online. First was a binary delivered in an encoded form that the shellcode operates on after download to restore it to a working format. The second incident was a targeted attack in which the malware binary used shellcode as a function delivery system.

I’m looking to be able to publish the slides shortly plus the samples for the first incident for your own playing around with.

Hopefully I’ll update this again on the weekend and share more on my talk.

Sorry for not posting often. Actually.. I’m not sorry. I’m happy I’m not posting daily purely to have stuff up daily. 😛

I aim to make posts whenever I find something interesting to share, simple or complex.

Today is complex simplicity! 😀

NOP Sleds or NOP Slides.

previously recognized by the opcode 0x90, this has moved on and into bigger and more worldly ways.

Many of you have reviewed exploits and shellcode related to them and you always spot this extra bit of data that gets sprayed like “0x0c0c” or “0x0c0d” or “0x0a0a”. These sweet opcodes serve multiple purposes when used as part of a heap spray. They can facilitate return addresses for where your code should redirect the exploited EIP. They also double as a NOP sled.

I’ve entered these opcodes into a debugger over a blank .exe file with a series of 0x90 opcodes as a filler.

I’ve included the 0c0d and it’s inverted 0d0c variant to demonstrate how it would look if your alignment landed badly. The code corrects itself and will continue the slide.

The intention of a NOP sled is to do no operation yet retain control of EIP. This gives your exploit a larger surface area to land on when dealing with the heap and the difficulty to predict where your shellcode will end up.

The shellcode above shows WORD size nop sleds. The opcode up from the original 0x90 is also usable for a NOP sled. 0x91! This single byte opcode can be used when you know your alignment is out and you don’t care about the contents of EAX or ECX.

Putting the samples on a testbed and looking at them made it quite clear straight away what the problem was. pdf-parser.py from Didier Stevens didn’t support the filters used to encode the data stream. UHOH!

So now what?

“Lets make some decoders!”, I hear you call out.

well screw that! 😛

“Lets steal some decoders!”, you yell at me.

Yeah, ok.

Firstly we need to know what we’re needing to look for, these are standard filters in Adobe products and there should be something in one of the open source projects that we can look at.

After a bunch of time sorting through the crap links from the not so crap links, I stumbled upon “pdfminer” which already had a LZW routine setup in python I could use. Still no RLE decoder though.

One small grace for the first sample, RLE was the last stage to decode. By removing the /RunLengthDecode filter statement, I was able to get the script to parse the file and give me some output!

While the output wasn’t as good as it could have been, the RLE was mostly ineffective at compressing the stream but only in obfuscating it partially. Much of the javascript was readable and it was possible to figure out what the intention was. MAYHEM! and trojans. I was able to immediately spot some well known pdf exploits. Collab.getIcon, Collab.collectEmailInfo, etc.

The 2nd sample had to wait, as it needed a clean decode from the RLE to pass into the FlateDecode filter.

I passed the samples on to others in my team to look at and one of the guys better at python than me ( everyone is better at python than me 😛 ) made a RLE decode function that worked great and we were able to decode the 2 samples.

Once I get his all clear, I’ll see about releasing something for your use/abuse at home. :]

Not much tech in this post, but I think those who’ve been in this position before know what it’s like finding a tool that doesn’t quite meet your needs and finding out you have the ability to modify it to suit. Don’t give up and google is a great tool. Remember to respect the copyrights of what you use, credit them where possible and even let the original author update their tool with your findings.

As you can see there is the original stub that loads WSAStartup to load any references to winsock calls. In this I’ve also hilighted within the small piece of code attached from the shellcode that its another stub but for an XOR encryption. As you can see, the XOR key is right there, 0xF4. There are 2 ways to go from here. We could step through the code to let it decrypt itself or since we know the key for the XOR we can just copy&paste the rest of the shellcode into WinHex and just manually let it decode the whole block.

We click OK and the code should dump out like this.

And at the end of the block we can see another URL that will be downloaded by the shellcode and executed.

This is the video for binaries 2.exe, 3.exe and 4.exe. These aren’t intended to be major indepth tutorials, only a demonstration of how I retrieved the flag from each binary. I’m not the greatest at reversing or making videos. I just like to share whatever I can. :]

After the Capture the Flag event of CSAW, Stephen Ridley released the source and binaries for the challenges on his github at http://github.com/s7ephen/CSAW_2009 . I spent a couple hours and did the challenges and found them to be fun while still quite simple at times. Later challenges are a real challenge for me as they require some coding to load libraries and I’ve not coded anything properly in years. 😀

Here is the first binary solution. I may remake this video at a lower resolution so it will be easier to read.