AWAE/OSWE review from a non-developer perspective

Earlier this year I had participated in Advanced Web Application Exploitation course by Offensive Security and after 60 days of lab, I managed to pass the Offensive Security Web Expert exam. By writing this article I would like to provide some more information about this course and certification for people who are considering taking it in the future. I would like to especially share my experience with people who are not software developers.

#whoami

I’m a cybersecurity specialist interested in application security and bug bounty hunting. I have been doing web application security for the last 7 years, so I had quite a strong fundamentals in that area.

However, for the last 2 years amount of time I can spend on hands-on activities has significantly decreased for a number of reasons. Moreover, I have never been particularly good at reviewing source code by myself as it has been some time since I have written web applications on my own.

As a result, before taking the course I had mixed feelings whether it is relevant for me so I was delaying its purchase.

During AppSec Village at Defcon, I won 1st place in some Appsec quiz. As a reward, I got 30 days of AWAE course + exam attempt for free.

And that is how the journey started…

Course content

You can find the exact syllabus of AWAE course on Offensive Security web page, so let me skip that part and jump directly to my thoughts on course content and structure.

1. You do not need to be a software developer to take that training
   Before signing up I have read some articles on the Internet where people wrote how many different Udemy courses on various technologies (JS, Java, DotNet, PHP, etc.) they took before this training.
   Well, as I mentioned before, I am not a software developer and I have not taken any of these training and I still managed to pass the exam and understand the course content. So obviously, it does not hurt to take these training before the AWAE, however, it is definitely not mandatory to be on an expert level in each of these programming languages. If you understand how IF/ELSE works and how MVC works you should be fine.
   At the same time, I would suggest taking some training in Python (if you do not have any experience in that language) as it simply helps you a lot while creating scripts.
2. It is not for the beginners
   If you would like to start your AppSec journey this training is probably not for you. After 30 pages of introduction on how to set up Burp you are jumping directly to some complex logic flaws in the application.
   Before taking this course I would suggest you to have at least 2 years of experience in AppSec area or as a developer. It would be also good if you have some understanding of common web application concepts (session, cookies, XSSes, etc.). It will simply allow you to spend more time on the course materials itself.
3. It is not like OSCP (yet?)
   I passed OSCP a couple of years ago so I will try to compare these two. The way how the course is structured is more or less the same, however lab part is completely different.
   In PWK you have 30+ machines which you can exploit on your own as exam preparation. In AWAE, you get only a few of them. I managed to complete these training boxes over 2 weekends, so amount of hands on exploitation attempts is way smaller.
   Despite not having a lot of time dedicated to this one (no more than 10h per week) I managed to complete the training with all extra-miles and extra boxes in something around 50 days. Summing up, purchasing training with 30 days of lab and passing the exam should be completely manageable.
4. It is all about reading the source code
   90% of this course is about reviewing the source code.
   Don’t get me wrong — it is still extremely satisfying and challenging. However, you need to get used to the fact that you will rather work with debuggers, grep and nano (vim?) than Burp.
5. You will learn a lot — not only how to spot vulnerabilities
   It is not a “follow my steps” kind of training. After going through the basics with the instructor you are supposed to find additional vulnerabilities and write a lot of python code to exploit them.
   After taking this course I refreshed my coding skills in Python I learned an efficient way to review thousands of LOCs and gained a deep understanding on how certain security mechanisms might be bypassed.

Pros:
- Very well selected examples of vulnerabilities which convince you that black box testing won’t cover everything
- You learn a lot by trying and failing until you succeed
- Nicely explained source code review methodology
- You build (refresh) your scripting knowledge

Cons:
- Number of training machines significantly smaller than in PWK (OSCP) training — it is hard to practice on your own once you are done with course content
- Explanation of vulnerabilities in 1–2 apps is not very clear. It took me some time to read materials on the Internet to better understand the root cause of these issues. I’m not sure if this is expected or not, but since 8 other vulnerabilities in the book are explained nicely I guess these two could have also been explained better.

OSWE Exam

For these of you who do not know — OSWE exam is about breaking into two web applications in 48 hours. Obviously first you need to find a vulnerability which will give you the initial foothold and then identify a vulnerability which would result in executing arbitrary code on the box.

OffSec makes a lot of effort to maintain the confidentiality of exam content, so if you expect from this article any information how to solve some challenges from the exam — I do not have any good news for you.

I scheduled this exam on the weekend (starting 11 AM on Saturday). I secured my tranquillity by asking my family to do some activities outside and secured my peace of mind by taking Monday as a day-off at work. Please note that after 48 hours of the exam you have 24 more hours to write and submit a report, so I just wanted to be sure that if things go bad my other responsibilities would not be impacted.

OffSec exams are proctored.
It was the first time for me to participate in an exam proctored over a webcam and to be honest experience was quite weird.

It started with some technical issues to verify my identity so I started the exam at 11:30 instead of 11:00. During the exam itself, I had to refresh the browser tab multiple times as apparently connection was dropping. It is also quite funny that you have to notify proctor whenever you want to go to the toilet and notify him/her 2 minutes later that you are back.

For the entire exam duration, I was reprimanded only once as I wanted to order food with my mobile phone (while my exploits were running) and apparently using the phone was forbidden.

In general, I would say that it was not super painful, but having a feeling that someone is watching you (and what is happening in your home) for 48 hours does not make you feel very comfortable.

About the exam itself.

Day 1:
As mentioned before, on the first day I started at 11:30 AM and only took one 30 minutes long break to eat. I started with spending 3 hours on the first box and without a lot of success, I jumped to the 2nd one. I have not had any major success until 10.30 PM when I managed to find and exploit the 1st vulnerability.

Exploitation itself was relatively easy, but identifying a vulnerability in the code was not that obvious. Not identifying any vulnerability for 11 hours impacted my self-confidence and I started to question the decision about not spending more time in the labs. However, after finding this vulnerability I realized that I spotted it in the first 2 hours, but skipped it as I was looking for some other stuff and went down the rabbit hole.

After gaining an initial foothold on the box, finding second vulnerability took me literally 15 minutes. Exploiting it took some more time as some scripting was required. I managed to complete the first day of the exam (including writing exploit and taking screenshots) at 2:30 AM. I was going to bed feeling quite unwell (I guess spending 15h in front of your PC is not good for you) and having a lot of thoughts in my head on how this second machine could be exploited. The alarm clock was set at 9 AM.

Day 2:
I woke up at 8 AM. I was still feeling unwell, but thankfully this changed a little after taking a shower and having a proper breakfast. Around 8:45 AM I started 2nd day of challenges.

This time I learned my lesson and instead of looking for some extremely sophisticated exploitation attempts I took a simple approach.

If I am not able to exploit (or at least have some promising results) a potential vulnerability in 30 minutes I am moving forward to something else.

This approach worked pretty well. At 11:30 AM I managed to identify first vulnerability and 1 hour later it was exploited successfully. Similarly to the first box, identifying 2nd vulnerability took me literally 15 minutes and I spent 1 hour on creating a script to exploit it. At 14:30 I was already after lunch and done with the exam.

Summing up, I managed to complete the exam in something around 28 hours (including breaks) in total. Later that day I collected some additional screenshots, created a report and submitted it to Offensive Security. 24 hours later I received an email about passing the exam successfully.

My tips for the exam:

1. Take breaks — it is easy to say it now but it was me who was sitting 15 hours non-stop in front of PC…
   To be honest 48 hours is a lot of time. I think it is completely manageable to complete this exam in under 16 hours (w/o writing a report). You just need to pay attention to the details. Not taking breaks makes you worse at spotting these details.
2. Course materials teach you everything you need to pass that exam successfully. Learn how to debug and make sure you complete all the extra-miles and all the lab machines.
3. Save scripts you create during the course for later use.
   It helps a lot if you can copy some more complicated code snippets instead writing them from scratch. You do not want to spend time during the exam to understand why certain command returns an error.
4. Try not to fell into rabbit holes.
   It is pretty obvious OffSec does not require from you to identify some 0-day vulnerabilities in well-established frameworks. If you are not sure if certain native function or validation can be exploited — Google it. You will save a lot of time.

That’s all folks! I hope this review will be helpful to someone!