OSWE vs OSCP: Plus OSWE Certification Guide 2022

OSWE vs OSCP

OSCP is a beginner-friendly course, compared to that of the OSWE, that focuses more on the breadth of knowledge rather than depth. While OSWE is more specialized and advanced.

With OSCP, the goal was to find a vulnerable service, look for a public exploit of that service, tweak the exploit a bit, and repeat until you get root. The process involved a lot of google searches for public exploits on discovered versions of services. While with OSWE, the goal was to discover the vulnerable functionality with the help of the source code, build an exploit for it based on how the source code processes the input, and script the entire exploit chain to gain a reverse shell.

Since I’ve got an extensive background in Software Development and have played tons of CTFs with Source Code Review based challenges, I found OSWE easier than OSCP. I believe the general opinion is otherwise. This may have been because OSCP was my first certification, and I did not have enough exposure to HackTheBox (etc) before starting the course. While with OSWE, I had quite a bit of relevant experience.

However, in terms of knowledge and things I took back home, I would give OSWE the points here, as the skills gained were more practical and much more applicable in a real-world scenario compared to what I learned in OSCP.

OSWE vs OSCP is a common discussion – let’s take a quick look over a Reddit discussions:

Amongst the top upvoted responses were as follows, take from it what you will:

Is OSWE easier than OSCP?

OSWE is an “expert” level certificate. If you compare it to HTB boxes, it will definitely be around Hard/Insane difficulty, while OSCP/PWK would be around Easy/Medium difficulty.

Do I need Oscp for OSWE?

It is not required to have the OSCP certification in order to attempt the OSWE. However, it is recommended to go for the OSCP first, as it would inevitably give you a strong base for your pentest skills. Think of the OSWE as a specialization in Web Applications.

Cracking The OSWE Exam Guide

Ever since I completed the OSCP, I feared I’d miss the thrill of Offsec Certifications; which is why I decided that the OSWE would be a good course to re-live the thrill of learning and trying harder all over again!

Now that I’ve completed the OSWE Certification in the first exam attempt, I decided to write a semi-technical guide for the AWAE Course by Offensive Security. Thus, in this blog, I’ll be going over the certification, my approach, and some tips that hopefully help you in cracking the OSWE Exam!

P.S. Some parts of this blog may be vague – to not disclose excessive details about the course.

Introduction

What is the OSWE certification?

As per Offensive Security, the OSWE Certification (AWAE Course) is described as:

Advanced Web Attacks and Exploitation (WEB-300) is an advanced web application security review course. We teach the skills needed to conduct white box web app penetration tests.

On earning the certification, you would have a clear and practical understanding of white box web application assessment and security. You’d have proven your ability to review advanced source code in web apps, identify vulnerabilities, and exploit them. You would also be able to assist web development teams in creating and maintaining web apps that are secure by design.

How is the course structured?

Back when I registered for the course in Sept’21, the course was being offered for 1299$ with 60 days of lab time, and 1499$ for 90 days of lab time. I had opted for the 60 days lab version, which I believe is ideal for those who work or study full-time. Offensive Security has now launched a subscription-based model, and more information on that can be obtained here.

Just like any other Offensive Security course, I was given a Course Manual, and accompanying video lessons as the preparation material for the course. The material was really important, as it allowed me to build a methodology to tackle the exam labs, taught many new and creative attack vectors, and highlighted the importance of debugging & logging.

I was also given access to a lab environment that had 2 types of labs:

1. Guided Labs: These were pre-existing Open Source Software that already had valid vulnerabilities disclosed, and the discovery of these vulnerabilities was in-line with the aim of the course. These applications were carefully selected to cover a wide variety of development frameworks, programming languages, and unique vulnerabilities. The solution, methodology, and alternate pathways were all provided to us in the material.
2. Un-Guided Labs: These were custom labs created by Offensive Security to give us a better idea of how the exam labs would be structured. This was a key part of evaluating my progress and readiness for the exam. These machines were slightly smaller in scale compared to the guided labs, however, similar in difficulty.

These labs were fairly doable in the 60 days timeframe considering that I had a full-time job on the side. However, now with the new subscription model, I believe time would not be an issue.

What are the pre-requisites?

Offensive Security doesn’t impose any mandatory pre-requisites for this course, however, from a technical standpoint, the course would be much more manageable if you have prior experience in programming (specifically using any MVC based Web Framework), scripting, and Web Security concepts.

If you’re new to Web Development, it would take you additional time to understand the architecture of a web application, and it may be overwhelming to do so during the course due to the wide range of programming languages and frameworks that are covered. Thus, before starting the course, I would recommend you to take up a small project of building a Full-Stack Web Application using an MVC Framework. Some examples of such frameworks are mentioned below:

• Django – Based on Python
• NodeJS (MERN/MEAN Stack) – Based on JavaScript
• Spring – Based on Java
• CakePHP– Based on PHP
• ASP.NET – Based on C#

Scripting wise, from the perspective of this course, you should be able to mimic GET/POST/Websocket requests, and workflows right from your script. The aim of the course is not only to discover vulnerabilities but also to automate the entire exploitation process (from Authentication Bypass to RCE) with a single script that requires no manual interaction. A few important Python libraries that you’d be using throughout the course:

• requests – To initiate GET/POST requests, and set sessions to incorporate complex workflows (For example: Authenticate, upload a file, and visit the uploaded file)
• websocket – To mimic WebSocket connections.
•  (Optional) multiprocessing – I used this library to thread scripts that involved any sort of brute force; this helped me save about 90% time in testing scripts that would otherwise take 20-30 minutes to complete.
• sys/os/subprocess – To execute System/OS level commands, and potentially capture their output, if required.

Is OSWE the next milestone for me?

If you’re a Cyber Security Professional looking to get a jump start into White Box Assessments of Web Applications; or if you’re a Software Engineer looking to expand your horizon on Web Security, this course is for you!

Since this is a fairly new course, the industry-wide recognition of this course doesn’t match that of the OSCP. I’ve seen many Job Descriptions mentioning OSWE as an optional requirement, but never as a mandatory requirement. However, the presence of this badge on your profile will have a good impression on a technical recruiter since this is an advanced-level course. But it may not always be the “wow” factor.

For Software Engineers, this certification would be a very unique add-on, and recruiters would appreciate and acknowledge your ability to write secure code.

I signed up for the course solely for the learning (and also the thrill!).

Preparation Timeline

I began the 60 days of lab access on 12th September and spent the first day reading the introductory portion of the course manual. I jumped right into the labs the following day as the introductory material was straightforward, and mostly comprised of topics that security professionals are generally aware of.

On weekdays, I spent around 4-5 hours on labs, while on weekends, around 6-7 hours. This pace was enough for me to complete the guided labs, their extra miles, and my notes by 9th October. I had to end up pausing my preparation until 18th October, as I got sick. The timing couldn’t have been any worse, right? Luckily, I had enough time remaining for the un-guided labs, so I decided to rest well before getting back to work!

After a short, but seemingly long break, I was back at it, and completed the un-guided labs on 23rd October. I registered for my exam for 29th October as I estimated that I would be done with the revision, notes refining, and a little rest by then. I booked the date quite close to when I completed the course, as I was told that the un-guided labs are very close to what the actual exam format is, thus, having completed those labs, I was ready for the exam.

The Exam

You’re given 48 hours to complete the machines given in the exam, and an additional 24 hours to complete the report where you describe your methodology, exploit, PoC script (that replicates the entire exploit chain), and screenshots to prove that you actually pwned the machines!

I booked my exam for 10 AM, as I was accustomed to waking up at around 9:15 AM. It is ideal that you get a good night’s sleep and preferably set the exam at a time when you can wake up without an alarm. Some people do prefer starting the exam late at night due to the peace and quiet in and around their household. However, I had a headphone on me at all times, so that wasn’t a requirement.

Before the exam, you need to make sure you have these ready:

• HD Webcam
• ID Proof
• Scanned Copy of the ID

The proctored session requires you to provide an ID proof via the webcam, which is why a good quality webcam is required. In my case, the ID wasn’t clearly visible on the webcam, so I had to show a scanned copy of the ID via my shared screen. The verification process starts 15 minutes prior to the exam start, so keep everything ready well in advance!

During the exam, be sure to take breaks whenever you’re stuck, and sleep if required. Don’t hesitate to take breaks because you feel you’ve taken many. I took a break roughly after 2 hours to freshen up, and get a small bite to eat. That helped me come back with a new perspective, allowing me to question my thinking better. This is really important because sometimes, you keep re-iterating the same thought and never question your thought process on why you came to a conclusion.

I had faced something similar during the exam: I was going over the source code for one of the machines, and I had skipped over the actually vulnerable function twice just because I thought “nah, that wouldn’t be it“. The third time, just after I had gotten back from a short break, I questioned my assumption instantly and got through!

Also, don’t forget to take a screenshot of every step you take once you’ve found the intended exploit chain. Once you have all the screenshots, and code snippets all compiled, you can use the additional 24 hours provided to format your report with the information you’ve jotted down during the exam. I kept updating a rough version of the report during the exam itself and kept the formatting for later.

I had submitted the last flag with 15 hours left on the clock; that’s when I took a nice and long break to get into the reporting mode. The report in total took around 10 hours to complete, and I submitted it an hour after my exam ended. The paranoia kept forcing me to re-read the 50 page report until I couldn’t bother reading anymore.

In total, I slept for around 9 hours during the exam and managed to submit the final report in 49 hours from the exam start. The machines in the exam were similar to the labs, and covering all of the material in the course manual should be more than enough to be ready for the exam. All that remains is that you have a clear head, a good night’s sleep, and some patience to read through a lot of code!

Note Taking

Shifting gears to how I managed to clear the OSWE Exam from a technical standpoint, a good transition to this blog will be to go over my note taking process.

I used Obsidian as my notes app. This was my first time using the app, but I really loved the way it linked different aspects of my notes together. It is also equipped with a powerful search functionality, due to which I would definitely recommend using this as your primary notes app.

It is also important to keep a backup of your notes, and I used git for this purpose. Every few days, I’d just push the updated notes onto GitHub to have a backup, and a way to go back to old versions, if required.

How did I structure my Notes?

I divided my notes into the following sections:

• Images – Just a folder for all the screenshots that I pasted into Obsidian.
• Labs – Where I stored my methodology, extra-miles, and scripts for each of the labs.
  • I used the following file name syntax for naming the notes for each of the labs: <ProgrammingLanguage> (<ExploitChain: SQL Injection to Deserialization to RCE>) <MachineName> - <IPAddress>. This allowed me to quickly get a glance at the type of vulnerabilities covered for each programming language during the exam. This helps in prioritizing what vulnerabilities you should look for when you attack a target. This does not necessarily reduce the sample space, because there is no guarantee that the exploit chain for the programming language would be similar to what you’ve done in the labs, but it’s always a good place to start!
  • For each Lab, my notes contained the following sections:
    • A section to highlight what I tried, and why that failed/passed – this helped me during the revision phase where I could sort of re-live my methodology without actually having to do the labs.
    • The final steps – spoon-fed so that they can be replicated, if required in the exam.
    • The final scripts – if I wasn’t lazy enough to actually code one for it.
    • A references section – to highlight anything new that I read to complete that machine. The individual links were directly linked to a particular section in the notes. I had this section to go over during the revision phase, and as expected, it wasn’t useful during the exam.
    • A Keywords section – this was solely for the search functionality on Obsidian, I used hashtags to highlight important aspects covered in the lab. This could be used in the exam if I was stuck on a particular exploit chain, I would have a place to refer to. However, I did not use this during my exam.
• Scripts – These were a compilation of common scripts that I felt could be re-used (SQL Injection – Time & Boolean Based Blind – both threaded & non-threaded versions; File Upload, etc.). This helped me greatly during the exam, as I did not have to spend extra time scripting common exploits that I already covered in the labs. I re-used the code and modified it as required.
• Debugging & Logging – As the name suggests, I used this section to note the steps to setup debugging on different frameworks and to enable logging on databases for inspecting queries. This was mostly redundant, as we are provided with a debugging machine that is pre-configured to debug the labs, without any additional configuration. But this is a good section to have and maybe useful if things don’t go as expected. To save some effort, there’s a certain post on the Offsec Forum where someone took the effort to mention the steps to setup debugging on every framework. It’s hard to miss that post.
• Nudges – This was my most visited section during the exam. Here, I noted down the following:
  • All the possible things I may want to check for each language/web framework. It covered important function calls, object initializations, or general keywords that would possibly indicate the presence of a vulnerability.
    • For Instance: readObject & ObjectInputStream – Deserialization (<Reference to a lab that covers this>).
  • The areas that I got stuck at in the labs, or what I did wrong (in a given context).
  • A summary of the methodology for each step of the exploit chain. This contained the possible vulnerabilities/pathways I need to look for at each step of the way (Authentication Bypass, Privilege Elevation, and RCE).

These sections were more than enough for me to revise, and refer to during the exam. I did not feel that anything was missing from the notes, and found the Nudges & Scripts sections the most helpful, as I mostly only opened my notes when I was stuck during the exam to make sure that I didn’t skip over any steps during my initial reconnaissance and discovery phases.

My Methodology?

The course covered a wide variety of vulnerabilities from the OWASP Top 10 list, and in various web frameworks. We also went over various logical vulnerabilities that required creative exploit vectors, and were fun to discover!

Even though most of the vulnerabilities present in the labs/exam are conventional OWASP Top 10 based, the discovery phase is not that straightforward for them. In the next few bullet points, I’ll briefly go over my methodology, keeping in mind that I can’t disclose too much about the same. I will keep it simple because as you progress through the labs, you will start to develop a methodology of your own, and you won’t end up needing assistance! And this methodology can be carried over to actual White Box Assessments!

• Read the source of the application to locate the unauthenticated endpoints. The location of endpoints, and whether they require authentication is variable for each development framework, thus, this is something that would come with practice. Endpoints can also be enumerated via fuzzing the web application, however, this won’t be as thorough (and effective) as exploring the available routes from the source.
• Enable logging/debugging to figure out where the vulnerability is. Explore the logic behind the entire authentication flow (Register, Login, etc.), and think of creative attack vectors that could possibly bypass the logic. This goes hand in hand with fuzzing the available input fields to populate the logs being captured for analysis.
• Once you discover the vulnerable location, you will have to go through the source code to figure out any sanitization/blacklisting/whitelisting that is taking place, debugging sometimes aids in reducing the complexity of this task as you can track where your input goes through and how it gets modified on its way to finally being processed/rendered/stored. This would help you in building an exploit for the discovered vulnerability.
• As you move from the Authentication Bypass to the other stages of the machine, the scope of testing expands with new authenticated endpoints being added to the mix, evaluate these endpoints with the perspective of escalating privileges, or gaining RCE.

What if I’m stuck?

• Look back at your notes, go over your methodology to see if you missed anything. A good way to make sure you covered everything is to make a list of authenticated/unauthenticated endpoints, and write down what you concluded about each of the endpoints.
• Go over the vulnerable keywords for the language that the application is coded in, from your notes.
• Go over the source again, but this time with a fresh mind. Start your methodology from scratch, because in your first iteration, you may have missed over the most obvious things!
• Apply a Black Box testing methodology, and explore logs to see if anything’s out of the ordinary. Debug the application to validate the application flow. There may be times when the main logic for a route is not in the controllers, but in a middleware.
• Found the vulnerability, but unable to exploit it? Look for common payload based bypasses on the interwebs, sometimes, you may get lucky. This is not ideal, as you will be able to dissect why your payload/exploit isn’t working. Stick to the basics if nothing works for you, use debugging to figure out what’s happening to your payload, and why is it behaving the way it is.

What could have been better?

Although this course was really informative and well structured, I believe that some aspects of this course could have been slightly better. These are minor concerns that would not affect the preparation in any way, but would have made things slightly smoother in the entirety.

1. The debugging machines given to us during the Exam were barely usable. With a 2 seconds delay to every action, debugging had become very cumbersome and made the entire experience prone to misclicks – ending up in issues that warranted a machine reset. In the end, I got used to the delay, but I did waste quite a bit of time while debugging in general.
2. The support team had different responses to technical queries relating to my VPN connection. This ambiguity almost cost me my exam attempt. Luckily the issues were resolved on my end, otherwise, I was sure that this would have eaten up a major chunk of my exam time.

Regardless of these minor issues, which I’m sure will fade away as the course matures, the overall experience of the labs and the exam was very positive. The proctors were super friendly and responded instantly to any query that I had.

Resources I referred to?

• hxtps://github.com/carlospolop/hacktricks/tree/master/pentesting-web – My go-to guide for vulnerability discovery methodology.
• hxtps://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/ – For practicing the type of vulnerabilities. This can be used as a preparation resource before signing up for the course.
• hxtps://github.com/wetw0rk/AWAE-PREP

Final Thoughts (Extended)

OSCP

In general, the OSCP exam is well known for its difficulty, and it’s not the exam systems but rather the 24-hours time limit, which makes it challenging. Due to the continuous enumeration and exploitation of machines, the constant debugging of issues, the fatigue quickly builds up, which causes one’s concentration and efficiency to suffer. These eventually lead to more problems later on. To break this circle, the best advice I can give is to have a thorough plan to ensure you’ll always know what to do next, how much time you are willing to sink into a single problem, and document everything you need to do for compromising a host. The exam machines itself were up-to-date systems so that you couldn’t take the easy kernel exploit path like in the case of some of the lab machines. Difficulty-wise, I found that the exam machines were more difficult than the ones in the lab, but not by much. In the end, I managed to complete all the objectives and gain administrative shell access on all target machines. My final exam report was 38 pages long, and the lab report I submitted had 122 pages.

OSWE

Even with its current shortcomings, I can safely recommend the AWAE/OSWE course. If you are willing to sink in the time, then anything the course explains in-depth, it does it exceptionally. It introduces techniques and chains of exploits, that open up new ways to look at vulnerabilities and makes that ticking in the back of your head asking how could this be used later on in unexpected ways. As for the problems I have with the course, I hope future updates to the course will address them. Until then, there are other courses available out there that nicely complement the AWAE course, although in a bit steeper price range. Consider this course as the start of a journey rather than the final goal.

Few closing words for people who are thinking about trying to get OSCP certified. While Offsec advertises its course as not beginner-friendly, I have to disagree. I think the most value of this certification is for people who want to break into InfoSec, like CS students or IT personnel at the beginning of their NetSec career, rather than seasoned pentesters. Definitely, don’t allow yourselves to become disheartened by the fame OSCP has and dive into the deep end. At the end of the day, the course is a test of discipline and determination above all else.

Go up to OSWE vs OSCP

Suggestions

Return to Cybersecurity Academy

Read the latest Cybersecurity News Articles

source

Return to home page

 114,080 total views,  2,647 views today