A Quick One: DNS Zone Transfers

Zone transfers are just NOT supposed to work (unless you are a DNS server), however, sometimes you want to show what one can find if they happen to come across a poorly misconfigured one. AboutSecurity told me about a site his buddy has called zonetransfer.me for this purpose specifically. It is a site you can show your customer/class/boss the dangers of zone transfers without setting up your own DNS server to prove your point.

For Windows users its as simple as this (ok DIG is simpler... never mind)

Nslookup

set type=ns <-- get me name servers (NS)

zonetransfer.me <-- gets you the NS associated with this domain 

server ns12.zoneedit.com <-- set the server to this

set type=all <-- grab everything

ls -d zonetransfer.com <-- GO!

Tiff Buffer Overflow in PDF

So teaching the MFIRE class last week in lovely Johannesburg-- a student asked me about the PDF containing the following vulnerability: CVE-2010-0188. This is a buffer overflow using TIF images. To be honest I never encountered one of these in the course of my work-- so off to the research cave I went. Along for the ride I dragged Hidden Illusion-- who is well versed in the PDF exploit jungle. He actually did a write up based on the work as well, you can see it here at his blog. He beat me in the race condition on posting :-)

Information about the PDF as gathered from peepdf

We were actually lucky and found someon else had already written a posting on the exact PDF here. However it did not exactly state how they got to the TIF file... I could see it sitting in stream 122, but when I tried extracting the TIF files I got nothing-- which was starting to anger me. Regardless  I was barking up the wrong tree. Lets take a look at the stream with the TIF.

NOP Sleds Have been removed for brevity

So, when I -first- looked at this I thought BASE64... however my mind was so dead set on trying to extract TIF files I dismissed this entirely. Glenn brought me on track and said 'Nope its base64'.

Mild fail for me :( Lesson Learned: Go With Gut.

I decided to save off the Object to a file so I could easily manipulate the stream.I did this by setting output within peepdf to a file ('set output file ') and then viewing the object again. Don't forget to reset the output to stdout again!  I was trying to use the modify command within peepdf but could not get it to work (so if anyone can explain how to do so would be awesome). Another method I could of used as pdfextract, another tool from Origami in remnux which pulls all streams, js, images, and whatnot from a PDF file.

 So after modifying the stream slightly in a text editor so all that was left was the BASE64 code (so the file starts with 'SU' and ends with the '=') all it took were two more commands:

base64 -d stream122_modified.dmp > decodedStream.bin

xxd decodedStream.bin

Excerpt of Shellcode after decoding

Hooray I was able to see the same thing as was seen in the BugiX blog!

Other interesting streams in the PDF:

Snippet of Object 3

• Obj 144: JS trying to determine the version of Adobe
• Obj 199: References to the shellcode... you can see the the filenames of the files the pdf drops
• Obj 122: The TIF exploit itself
• Obj 3: Calls the TIF exploit

I checked what other objects reference 3 again using peepdf. I wanted to see how this was starting execution, as generally there is an openaction or something along those lines.

Checking to See What Other Objects Reference Object 3

So this document utilizes XFA, which is a open standard for electronic form management. What this is saying is to use XFA and call Object 3 as the template for the form... which just so happens to call our 'exploit.tif'. Groovy.

The more and more I use Remnux, the more and more kick ass I feel it is. I really love PDFStreamDumper too-- its a wonderous Windows land PDF analysis tool. Its just that sometimes its nice being able to inherently do things like base64 decode and view a hex dump with your OS.

And of course thanks Mila for Contagio-- the one stop shop for malware :o) You can grab the specific PDF I analysed above at her site here.

And again thanks Glenn-- this is for you.

Pentesting 101 - Lessons Learned

First off-- -sorry its been a while. Work and life has been crazy! We had the Diamond Jubilee a few weeks back, had family visiting, lotsa work obligations... blah blah blah :)

Anyways, I took part in one of my 'in-depth' first malware/external pens the other day. First off--- so nervewracking! I felt like it took forever (aka more than 1 second) for a meterpreter shell to come back to me, so immediately I thought everything was fail. This brings me to one of the biggest lessons I learned:

BE PATIENT
You are setting up a shell perhaps thousands of miles away, potentially on horrible connections-- so don't freak out if the command which took milliseconds in lab testing took a few seconds in the real world.

HAVE A PROCESS
Your first instinct will be to quickly run things as they come to you in case you lose a connection... This is not good either because you will probably end up forgetting what you did and doing things in a nonsensical way. You need to get in, get good data, and then use that data to get further in. Some things one should think about when creating their process:

• Are you system?
• Have you set up persistence? (in case you lose your primary connection you have a backup)
• Have you dumped hashes?
• Can you grab LSA secrets?
• Have you looked at network information?
• Have you checked the system info?
• Have you checked the IP configuration?
• Do you know if there are administrator accounts? How about domain accounts?

Basically take the above and see where you can get... can you create a new user with administrative priveleges? Did you crack a local admin account? Did you find a AD server? How can you use that to increase your toehold into the network? This process will be different for each company-- but you get the feeling that the basics hold true for almost any pen.

DO NOT RELY ON SCRIPTS
This really holds true for most things computer related. If you are going to use a script-- fine, but be sure you know what it is doing and understand the risks of running it. Will running it trip AV for example? Or worse yet-- drop you connection? I wanted to run a lot of scripts (hey they worked in my lab!), however my coworker (who knows a thing or two about pen testing) said to be careful... scripting can be dangerous. If you have the time-- do it by hand. The best way of ensuring you are getting the results you expect is to run the commands yourself, so drop into a shell and let loose the command line kung fu :) Of course if you have multiple machines in a short time frame this viewpoint may be altered....

OK SO WE GOT YOU... AND HERE IS HOW TO FIX IT
When you are doing a pen test-- you have to remember who this is going to, a client. A client who --sure-- wants you to get into their network, but more importantly wants you to tell them how to make their network more secure. So don't just say, 'We got SYSTEM on your device', say 'We acheived it exploiting this vulnerability (yes metasploit tells you this) and this is how to mitigate this threat.' Believe me that is much more important to them.

SCREENSHOTS ARE YOUR FRIEND
Sometimes its hard to explain technical things-- screenshots can say it all. Saying 'we established an RDP session to the victim's machine' is nice, however, showing a screenshot of the RDP session? Priceless.

Like I said before, each individual has their own way of approaching this. I think it is finding the balance between a cool head and steady fingers at the keyboard :)