Fun and Frustrating. Thos are the words i would use to describe my whole experience with the labs and especially with the OSCP exam. To give an idea, starting from the begining: It was Mark who suggested a while ago that I should attempt the OSCP certification. I made a mental note to try OSCP but due to other considerations and priorities OSCP was set aside. So a couple of months back, I , finally decided to set things in motion. I registered for the PWK course , obtained the VPN credentials and now it was time for starting the labs.
Battle Plan
Before starting the course, I had to analyse my own capabilities. I wish I were the rockstar astronaut ninja. Sadly, I realise that is never a possibility. I have my own strong areas and i do have my own areas where improvement is needed. How does this work out in terms of OSCP?. For one, I was confident of my Linux skills and after doing the course i am even more certain of my Linux prowess. Infact, a funny tidbit from my exam. I was struggling to get access to a machine, and it was late at night and to keep my sanity i was also frequently engaging in friendly banter at IRC channel. So naturally, i felt the need to shout at the channel when i had my first shell break. Arch3y, one of the devs of archstrike, who i had gotten friendly in course of my OSCP preparation was online, was the only one online at the moment. He remarked that now i have 10 hours for privesc to reach the safe zone. Within a span of 40 mins, i was able to privesc. Without delving too much information, this wasn't a vulnerability or scenario that i encountered before in the labs. Thinking back, most of the Linux machines did not pose much of a trouble. The emphasis is on the word, most. (side note : PAIN was a pain.)
So i am pretty confident with Linux privesc but windows on the contrary was a whole new level of a beast. Truth be told, i was fully aware of my difficulties with windows. I have worked mostly with Linux machine (or rather explictly only with Linux). Finally, webapp enumeration is not a new field for me but my level of expertise in webapps is not on par with my Linux skills. So herein, i identified 2 areas where i needed to put additional efforts. So here was my battle plan.
- I am not going to rush into the fray. I decided to go through the course materials slowly, even if most of them are known to me and if i encounter any new areas, i decided to do more research into those . Consequently, I spent 1 month on doing the exercises and not attacking any of the machines in the lab.
- Secondly, the decision was made not to root more than 1 machine a day, if its windows based. I based this decision to mainly conserve my energy and not to have a burnout syndrome. Even at a slower pace, i would be able to do more enumeration and learn more in the process.
- Finally, weekends were off. Unless I had a bright stroke of intelligence on any of the machines, I made it a point to spend time with my wife. This helped me recharge the battery for the next 5 days and in more than one way, helped me rethink and assimilate the concepts I gained during the week.
Lab Experience
Prior to registering the course, I was counting on my Linux experience and experience gained while playing CTF's. My rationale for doing that was based on the higher learning curve usually associated with Linux and CTF's being in similar spirit to OFFSEC labs. Once again the offsec team proved me both right and wrong. While I was attacking individuals machines in CTF, the bigger goal in LABS is to realise that the pentest engagement is made in a network as opposed to single machines. Many times realising the role of a machine in the network gave additional insights and made the exploit lot more easier and also fun. Secondly, even though the use of sniffer modules is not required in the labs, it paid exponentially to notice how different machines communicate with eachother in the network. In other words, the whole labs made me realise the importance of post-exploitation. If compromising a machine is like playing DnD, then post exploit is looting the corpse. (Sorry for the awkward gamer reference).
As I mentioned before, its unrealistic trying to be rockstar-space-ninja. This brings in the importance of working with others. Not for showing the way . But as I realised , it does help a long way to have someone discuss assumptions and approach. I believe the programmer's call it The Rubber Duck debugging. As i begun my lab, soon after, i met my war buddy Butch3R. Luckily, we were not geographically separated much and operated more or less in the same time zone. More importantly, our skills were somewhat complimentary. I think it would be would safe say that we both learned quiet a bit from each other.
A Lot of Mistakes Were Made
The motto of OSCP is Try Harder!. yep, You fail and You try again. Since I am not allowed to discuss the machines or the exams, I will try to be as general and brief as possible without giving away details.
Mistake 1:
Always enumerate. A glance through the exercise might make one feel that getting a reverse or a bind shell followed by privilege escalation is the ideal way to root a machine. There were times when i was tunnel viewed with obtaining a reverse shell that I focused on looking at ways to upload or execute code, all the while missing clear credentials laid open. Moral: always enumerate and enumerate more before going after shells.
Mistake 2:
Always revert. This is probably one of most repeated mantras of PWK labs. There is nothing more annoying than gaining a low privilege shell foothold and finding a suid executable to obtain root shell , only to realise later that it was part of a previous exploit left over by another student. I used to jokingly call this to Butch3R as piggy-back rooting. Moral: Revert before starting, revert again before starting privesc.
Mistake 3:
Linux kernel exploits are not shoot in the dark to win. Kernel exploits are not the first options for privilege escalation. Knowing what a particular exploit does, which filesystems are needed, which files are being used, and what shells do the exploit rely on, saved a lot of valuable time. The offsec forum is filled with enough stories on students trying throw-everything-on-the-wall-until-it-sticks approach for the linux privilege escalation approach. The best advice for kernel exploits is from cyber sun tsu.
If you know your remote environ and you own cross-compiler, you need not fear the execution of a hundred exploits. If you know your own cross-compilers but not the remote environ, for every exploit exploited, you will also have a failed exploit executed. If you neither know your own cross-compiler not the remote environ, you will be executed and your exploit will not.
Mistake 4:
XSS Exploits : know where it runs. Without giving much details, some of the xss exploit were simple and yet confusing and makes one go doh- after successfully exploiting . My typical experience with XSS can be summed up with this conversation I had with Alicia,
A: what are doing?
me: posting this XSS reverse shell code in a page.
5 mins later.....
me: Well i didn't get any connection yet, let me visit the page and check.....
me: Suprise i just got the reverse shell.
A: did you check the originating IP?
me : doh....
A: >.<
Mistake 5:
Know your scripting language and don't mix it up. This one was a personal one time blunder of mine but it kept me awake for 10 hours. During windows privilege escalation, sometimes a series of commands were executed and the next logical step is to automate and abstract the progress. So the plan was to set up a listening server and automatically execute the commands upon connection. Simple enough. Set up a simple ruby listening server, verified the commands and as all best laid plans, upon connection the commands were not executed. After missing a whole night sleep and closer to a walking dead state, I decided to get a second opinion on the script.
Response from Alicia, "Obviously, because you are not sending anything", while the xorond from #archstrike was funnier , "well you got messed up by python" . Well, that doesn't make any sense, it is a ruby script. In my long hours, I have accidentally used python print format inside a ruby script. A very common mistake when one is playing with too many languages but after spending a sleepless night, one more lesson learned.
Mistake 6:
learn to clean up after and exploit : This one is a minor annoyance but still an annoyance. Once an exploit has been successfully performed and before moving onto another machine better remove all traces of the exploits from the compromised machine. This is particularly important if the exploit is in the form of a webpage triggering a reverse shell. There is something inherently irritating about working on a particular machine , all the while getting a reverse shell on the listening server from a previously exploited server just because someone accidentally trigger the exploit you forgot to remove.
Learn to befriend metasploit. In spite of the restriction placed during the exam, in a real life situation , an employer or a prospective client doesn't care about how much fun it was tweaking an exploit to get it work or whether some auto pwner tools were used . At the least, most of them care of getting the engagement done fast. My personal method: most of the windows machine that I encountered in the labs, I attempted them twice, once with metasploit and meterpreter and another time using exploits and netcat. This was really necessary for me as windows was one of the few areas I made a note to myself to improve upon.
Finally, this is one of least discussed yet game changing aspect, network pivoting. Dynamic forwarding with ssh, proxychains and meterpreter portfwd are your friends. It is imperative to know which tools function well with pivoting and which one ones are slow , or generate garbages under port forwarding. Arch3y was gracious enough to offer me a few pointers on that direction. So more learning along the way.
The Dreaded Exam :
I already had a few custom scripts written for various tasks which I had to perform repeatedly. Remember in the beginning part of this blog, while discussing the battle plan, I mentioned that I took a month doing the exercises. Time to confess: I wasn't being exactly truthful when I made that statement. My rationale is the following : If I find myself repeating a series of steps, then write a script to automate it. If I had to perform tasks X, Y and Z, pause identify the common elements for these tasks, script the common components, modify the script with commandline flags for the individual components. So I ended up with a set of small nice scripts and the task remained to make them work with one another.
To sum up , I ended up with a hacked up custom scan script which would give the scan output in the first 1 - 2 hour. I ran this script on all the exam machines so after the first 2 hours i would have a scan on report on all the machine. Then I have my own Linux enumerator script which i could use for privilege escalation. This would save me around 1-2 hours of time should i find myself with a Linux machine. Even though i ended up with Linux boxes as fate would have it i never needed to use my Linux enumerator script. Finally, I also had another script from my PWK exercises for which I was glad I put up additional effort which paid off. (hint: If you are doing PWK course, pay attention to the exercises, they might come handy).
During the exam, in the first few hours , I managed to root 2 machines. The first one was straight forward with slight twists involved. The second one had a lot of red herrings but fortunately , I had my Linux enumerator run on it. So I could analyse the whole picture instead of jumping into conclusion. Now is where the fun and frustration begins. Looking at the scan results, I could already visualize the privilege escalation vector for one of the boxes. So I made a sane call to prioritize this machine over the other 2 exam machines. The evening passed and after a few hours trying every exploits technique and vulnerability methods that I learned in the labs returning negative, frustration started to set it. There is an old german proverb which goes like this : If you are focused on the tree you will miss the forest. That is exactly what happend. This was one of boxes which required a bit of lateral thinking and even verbal clues were dropped all along the machine. Finally, when I figured out, I had a shell. I dropped into irc and shouted that I have 2 and half machine. I didn't want to rush into privesc so I took a 15 mins off. Made myself a cup of hot chocolate , chatted a bit in #offsec channel to maintain my composure. Went back with renewed energy and 3rd machine rooted.
Having rooted 3 machines, I decided to take a nap and get back to the remaining 2. I had a small 3 and a half hour nap primarily due to my state of euphoria. Woke up and went back the other remaining 2 machines. By this time some of my usual buddies were online in irc and since they most of them knew that I had also prepared the lab reports and exercise reports, congratulations were being thrown freely. I swear, at this moment, if #offsec were a bar in real life, there would have been a couple of toasts going up in my name. I finally, decided to stop attacking the machines and focus on writing the report. Two days later, I receive the confirmation email from offsec congratulating me on being OSCP certified.
Conclusion:
There is no conclusion, there is only OSCE now.
But if i had to thank a few people, first there is Mark, the culprit who implanted the OSCP idea into my head. Since Arch is my preferred linux, it was natural to lurk in #archstrike channel. Thus, I had the privilege of getting to know xorond and arch3y , 2 of the devs of archstrike. Apart from the friendly banter at the irc, they were my goto persons in case I wanted to know benchmarked tools and their performances. and there is Alicia from the raptors who is probably the only person willing to laugh at my cesspool of nerd stupidity that i generated during the labs. Finally, there is my wife who was forced to listen to my ramblings about LFI, code injections and reverse shells even though she has no idea what any of them meant.
Add new comment