- Write a working Windows stack overflow exploit for a piece of software they provide
- Write a working remote stack overflow or a format string exploit for a piece of code they provide
- Reverse engineer a win32 binary to bypass it's registration mechanism.
I am going to come back to #2 in a minute, instead let's talk about #3. This was by far the most exciting prospect. This is the kind of stuff that just makes you love your work. alas, the IACRB does not put up any real challenge with their supplied target binary. Some well placed breakpoints in softICE and the whole thing reads like a book. Chances are that when you make your first alteration to the binary and test it, you are going to feel really unsatisfied when you realize it's done and you've already won. They throw no tricks or protection schemes in to really trip you up. My Time to completion: 2 hours
So that brings us back to the Linux exploit. I don't know who wrote the c code that they provide you, but I can tell you this: He is a bastard. They tell you that you can do either the remote buffer overflow or the format string. So, not wanting all the various headaches that format string attacks can bring, I tried the stack overflow first. The vulnerable function in this case is not your standard simple buffer overflowable function. The buffers are both declared at the beginning of int main, and are then passed to the vulnerable function as pointers. This means that you can't overwrite the return pointer of the 'vulnerable function'. Instead you are overflowing towards int main's return pointer. In of itself, this is not a problem. The problem comes in the stack layout for int main. Between the vuln buffer and the saved return pointer is the declaration of a socket file descriptor. This file descriptor has a value of 7, or 0x00000007 . Do you see the problem here? The socket itself is essentially acting as a stack canary. Because what happens is the control loop won't exit until it has read specific input off the socket. so if we overflow the socket fd, it goes to eprform a recv() call on a file descriptor that does not exist, returning an error, which does NOT break the control loop. The result, we never get our terminator input read from the socket, but it will keep going back and trying to read from a socket that it doesn't know where it is anymore. We end up in an endless loop. There is surely someway to beat this scenario. I don't think the IACRB would make that a 'trick question', but I'll be damned if i could figure out how to bypass that bit of nastiness.
So, after lots and lots of wasted time looking at the stack, i moved on to trying the format string. I had some trouble here that was due to my own lack of familiarity with a certain mechanism they use. It is a common c mechanism, so I have little excuse, i just didn't know much about how it operated on the stack. Once I figured that out there were a few tricks I had to use because of the nature of the program itself. There is a lot of backwards-forward flip-flop thinking involved here, but if you can keep your data flow straight in your head you'll do fine. If not, do what i did, use a lot of sheets of scrap paper. At one point during this, i wrote down every variable and it's offset just so I could visually see where everything was on the stack at a glance. This is very important. You are going to want to become intimately aware of where everything is on the stack and how it got there, it will make your life easier. The final challenge was then taking the exploit and pulling it together into a single cohesive exploit with no manual processes. This was of course a job for Perl, and my favourite language performed admirably with just a tiny bit of help from C(I decided to quickly write a statically compiled binary to do one little piece for me. I didn't know how to dot hat part in perl, and so I just fudged it a little bit with C, sue me.) My time to completion: ~ 3 weeks!
All things considered, I found the CEPT Practical Exam to be one of the most worthwhile things I've done. It is by far the best, most relevant, and most rewarding certification I've ever gone after.
Finally, I have to thank Infosec Institute. I had some not so great things to say about the first half of their 2 week course. However, the second half of the course was very good. The instructor in the online videos seemed very competent, and was good at getting ideas across. The labs were, for the most part, well done. It did a fairly good job of preparing me for the CEPT cert, but certainly didn't give you all the answers in advance. Also, the staff at Infosec Institute are great people and very helpful. There were a few complications that arose during the course of ordering, receiving and doing the training. Minh Nguyen and Steve Drabik over there could not have been more helpful in getting these issues sorted out. They were also very patient with the man who kept annoying them every other week ;) . i am already looking at their Expert Penetration Testing: Writing Windows Exploits and their Reverse Engineering classes for the future. Although I am worried about repeating material, especially since Infosec Institute does come with a rather high price tag.
My advice to anyone in the industry who is itnerested in developing these skills more, would be to take the "Advanced Ethical Hacking" course and the CEPT cert. If nothing else, it will be fun.
No comments:
Post a Comment