Saturday, September 19, 2015

Creating OSX shellcodes

I decided to play around with OS X shellcodes, now this time instead of writing a brand new post about it, I will paste here 3 other posts, which I found really useful to get started.

http://ligocki.tumblr.com/post/5174133459/writing-shellcode-under-mac-os-x-part-0x01

https://filippo.io/making-system-calls-from-assembly-in-mac-os-x/

http://dustin.schultz.io/blog/2010/11/15/mac-os-x-64-bit-assembly-system-calls/

A few highlights:
  • OS X is a nix based system, so essentially shellcode creation is like on Linux, you can use syscalls
  • These days OS X is x64 only, so you need to pass arguments in the registers, the order is: RDI, RSI, RDX, R10, R8 and R9
  • syscalls are done through the syscall command, which is stored in the RAX register
  • You need to add 0x20000000 to the syscall number
I created two NULL byte free shellcodes for OS X x64:

1. A simple /bin/sh code: https://www.exploit-db.com/exploits/38065/
2: A bind TCP shell, listening on port 4444: https://www.exploit-db.com/exploits/38126/

I also posted them on my github page: https://github.com/theevilbit/shellcode

Thursday, September 10, 2015

Offensive Security - Advanced Windows Exploitation (AWE) / OSEE review

Let me start first with my background. I don't do pentesting, vulnerability research or exploit development at all in my day to day life, I work on the defence side. I gathered this knowledge through the OSCP - OSCE trainings and exams, and that is the only place where I really practiced it. I also happened to read many articles from Corelan and FuzzySecurity on exploit development topics. On the other hand I do reverse engineering both on my day to day work, and I also play some CTFs sometimes to practice that skill. This is not strictly related but definitely helps a lot, when it comes to using debuggers, IDA Pro or understanding code, assembly, which is quite helpful.

If you want to take this class: You definitely need experience with writing basic exploits (basic buffer overflow, SEH based) completely on your own, know to use at least Olly/Immunity debugger (although it’s not used in the training, you need good debugging experience), be familiar with IDA and WinDBG a little bit, and understand assembly very well. As noted earlier reverse engineering experience also comes handy.

Now to the course:

This is the most intense, hardest and probably the best security training I ever took. They keep the same topics over the years, but always update the material with new content (if you follow the syllabus content over the years), basically the case studies which used to present the various techniques are pretty new. I will mostly repeat the syllabus above with my experience added:

Day 1 - 1st half: Location independent shellcode, how you can find the base address of kernel32.dll or any other, and how can you resolve the function addresses, this is important these days because of ASLR. If you took any malware analysis class, this should be familiar. This was the easiest part of the training and it’s really for warm up, to get familiar with WinDBG (we didn’t use Olly or Immunity at all). You also start to feel comfortable, that you can easily handle this stuff, and don't know yet that it can change drastically.

Day 1 - 2nd half & Day 2: Through a Firefox exploit we covered the following topics: DEP, ASLR bypass (with memory leak technique), precision heap spraying, bypassing EMET 5.2 with all protections turned ON. The EMET bypass was annoyingly easy. ROP mitigation could be bypassed with locating a single bit in memory, and setting it to zero, with the unhooked version of the kernel functions, which could be found in the same EMET structure. EAF bypass works with an old shellcode… After this day I started to feel tired :)

Day 3: We went through one of the SEP exploits they found last year to cover x86 Windows kernel pool spraying (like heap spraying just in kernel space), and pool overflow. The technique is even harder because if you overwrite something in kernel you easily end up with a BSOD, so you need to be very precise. We also covered token stealing shellcode for privilege escalation. This was quite demanding as we fall behind in time a little bit on the first 2 days. My brain wanted to explode at this point. We also got homework every day, and this was the first evening, when I was just looking on the screen, and my brain literally stopped working, so I just decided to go sleep.

Day 4: x64 kernel exploit, again with memory overwrite. We covered the MS14-058 privilege escalation exploit which was used in the Hurricane Panda campaign last year. The interesting thing was that the public exploit is only available for Win 7 x86, but we did it for Win 8.1 x64 (it works slightly differently as has some more protection). Basically with a well crafted memory overwrite we could give us debugging privileges and inject a shellcode to another SYSTEM level process to get full system access. This day was a bit more relaxed as we were good with time, although the topics still not easy. The hardest part of kernel exploits seem to be to craft your input so precisely that you end up on a vulnerable instruction that will do some memory overwrite for you.

The class had 20 students with 1 lead trainer (ryujin) and 2 assistants (ronin & sickness) who also helped the students, and you could hardly ask anything from any of them, which they couldn't answer right away. They are really sharp people! But, really, would you expect less from Offensive Security trainers? :) This was really great because there was someone always available to help you out, which was needed quite often. In every case we progressed in small steps, they gave a code at each stage, what we had to fill in with some details what we had to figure out ourselves. They also gave you the solutions if you didn’t want to deal with the exploits just to follow the class. It was really important to understand each step, because if you missed something, you could easily fall behind, and it was really hard to catch up. The trainers made all the effort for that not to happen, they were really helpful through the entire course. All the VMs, material, hint website during the training was prepared very well, everything run smoothly. Due to the level of difficulties, we started earlier, finished a bit later, and got also shortened lunch time. They said that this is the first time when someone didn’t left the class :)

The training is definitely useful to better understand exploits, Windows kernel and adds to your reverse engineering knowledge as well.

Side note: Next to us they run their “Advanced Web Attacks and Exploitation” class, where, as usual their covered currently 0-day exploits… and students were really happy about it :)

Preparation to the exam:

I went through the entire material again, did 3 of the extra mile exercises (out of 4), and went through other two kernel exploits developed by ryujin:


With that I felt well prepared for the exam, and scheduled it 3 weeks right after the training.

The exam:

As usual I can't say too much. You have 72 hours to solve 2 challenges, a big one, and a smaller one (which is also not easy). Obviously they can't cover all the topics from the training, but they will cover the most important ones. In one way the exam is much more straightforward compared to OSCP / OSCE, it's much more clear what you need to do, but it's also harder and much more time consuming compared to the other two. Additionally just as in any other Offsec exam, you learn new stuff even during the examination process, as you need to adapt to never before seen challenges, and I think this is a really good thing. I really enjoyed solving both of the tasks.

I started at 11AM, and probably I was in a very good mood, because I could solve the big task in 7 hours!!! I continued with the other one in the next few hours, before I went to sleep. I had a short sleep (although I wanted to have a long one, because I had lot of time), but I was debugging even in dreamland... in the morning I finished the 2nd task, but only in the easy way (there are two ways to solve it, each worth different amount of points), so I went ahead for the harder way. I got too relaxed by that time, so finishing that one took me quite long time, because I stuck at one point, from where I couldn't move on. Luckily after some breaks, I figured out how to proceed, and late afternoon I was done with everything. I put my son to sleep, then my wife, and late evening started the documentation, which I finished 5 hours later, 2AM next day.

I submitted it on Friday, and got my PASS result on Monday - was so happy to receive that email :))

In summary: another great training and exam from Offensive Security, I recommend it to anyone who would like to advance his exploit development skills.