samedi 28 avril 2018

Yet Another OSCE Review

Hi,

I did OSCP begining of 2017 and then OSCE a while back in December but since I got people who keep asking me about it, I decided to write a blog. I'll try to make it short as there are many guides that enumerate tons of stuffs already.

It will be more about the feeling and experience than the details.

What to expect?


The OSCE guide has not been updated since around 2008-ish.
So the techniques shown are old and there are no mitigations (but ASLR for the ANI vulnerability, which is easily bypassed with partial overwrite).

You will learn the basics to finding vulnerabilities using a fuzzer such as SPIKE.
Any other fuzzer is authorized during the course though, you could use your own or a public one. They are only interested in your exploits and the process you used to write it.
If you are to use a public one, I'd recommend boofuzz (sulley's fork), it does the job.

Exploitation subjects:
- XSS et SQLi
- Fuzzing with SPIKE
- Plain old SEH overflow exploitation, there are no mitigations at all (no SafeSEH, ASLR or whatnot).
The "hard part" being to find the bad characters.
- Egg Hunting
- AV Bypass
- Encoding
- A cool network attack based on Cisco configuration overwrite


So, are the techniques learnt really that useful nowadays?


Definitely.
It gives a good introduction to exploit writing for people wanting to see what the process looks like.
The process doesn't change, you spend a lot of time figuring out things in the debugger and writing code.

Some techniques are not usable on current Windows like returning to code in the stack directly, nowadays you have to bypass DEP (Data Execution Prevention) unless you're somehow able to return in some controlled area of the JIT (just in time compilation) space.
Nowadays, most memory is at least ASLR (randomization of memory location) and DEP (rendering some memory regions non executable).

BUT, old tricks tend to re-appear again and again on new developed platforms.
IoT and other embedded devices for instance.
The more tricks you have, the better prepared you will be/are.

The stuff that is still quite useful today and will be for a long time:
- the concept of re-using existing code ("jmp esp" in the course, but there are many more)
- memory corruption concepts : RCE!
- fuzzing
- debugging skills
- writing code to attack another piece of code
- looking for bad characters
- root cause analysis

What you don't learn:
- building primitives : read/write/execute primitives are the foundation of modern exploitation
- bypassing mitigations, even though there is an introduction to ASLR

What about the exam, is it that hard?


Depends, for someone who did some exploit writing, it won't be.
For someone just starting out, it will be hell.

The exam is around 48h, so the hardest is managing your time and energy level properly I'd say.
It's very important to sleep, eat, shower and go out during the exam.

There are some exercises I didn't do during the lab time such as writing the described encoder and the AV bypass.
I had to do these during the exam. So tip : do every exercises in the lab.

My exam went something like this:

Day 1

Ok, there are like 4 challenges:
- 2 x 30 boxes
- 2 x 15 boxes
You need 75 points to validate your certification.

- Started hacking the most valuable boxes : 30 x 2 : 6h
- Kept waiting for downloading Linux distros and testing them out, ~5-6h
- Went for a nap (4-5h)
- Polished the hardest exploits : 1h
- Did the AV bypass : ~1/2-1h
- Did the last exploit, lost sooo much time on this. The exploit was already functional, but I forgot connecting in VNC (instead of RDP) to see the result... Don't forget to read the guide!
- I spent a LOT of time making sure I had all the screenshots and extract I needed.
- Went back to sleep

So for exploit writing, I ended up writing a custom encoder, custom ASM payloads, scripts there and there. I had around ~700-900 lines of code (a mix of ASM and Python) by the end of the exam.

Day 2


Wrote the report and sent it out.


I spent a total of around 17-19h on the exam, wrote the report on day 2 and got the confirmation on day 3.

Hardest part? Being tired during the whole exam, that's the really difficult part. It's quite intense.


What tools did I use?


Tooling:
- A lot of virtual machines
- z3 : yup, for my encoder :)
- Immunity Debugger
- mona.py (kudos to c0relan)
- Python
- python libraries : pwntools and requests (for exploit writing)
- boofuzz : for fuzzing
- nasm : for custom payloads

Conclusion


OSCE won't make you a uber-hacker overnight, but you will get to have a first foot into exploit development and see the process from vulnerability to exploit.

It's not as hard as people makes it out to be, but it's not easy either if you're not used to it. Just do it if  you feel like you have an interest in exploitation and in certifications.

This is a fun and interesting course that is well designed and thought out so I'd quite recommend anyone to do it just for the fun of it.

Good luck to anyone planning to pass it.

Cheers,

m_101

Aucun commentaire :

Publier un commentaire