TL;DR
The AWAE training provided in the OSWE package is one I recommend to anyone who is even remotely interested in web application security, and especially in code auditing (or white box). Prerequisites in web application development are strongly recommended. The lab environment offers a limited number of complex applications that let you explore various techniques in depth. The confidence to pass the exam will mainly depend on the quality of the audit methodology the student builds.
Introduction
This article will explain the approach I took to prepare for this certification. Keeping a detailed logbook did not seem relevant to me; nevertheless, I will offer you a few temporal markers. I would also point out that the article contains no confidential information regarding the OSWE lab or exam. Finally, this article is purely subjective. It represents my personal point of view and is set within a specific time frame (certifications evolve quickly). That is why I also advise you to consult other reviews.
This article complements my presentation given at Hack2G2, available below:
The slides are also available here.
Why a certification?
Why take a certification?
Having finished my engineering degree in cybersecurity, I wanted to showcase my personal experience, particularly in the field of web application security. Having just passed the OSCP, a certification like the OSWE was a personal satisfaction that I wanted to add to my resume.
Why take one “now”?
It is March 2020. The end of my studies and the reduced activity of my CTF team Aperi’Kube freed up time for me to take the OSCP certification. The lockdown put in place against the global COVID-19 pandemic is still ongoing, and finishing the OSCP left me with a big void. So I decided to dive into technical study shortly after finishing my OSCP certification, in order to capitalize on the knowledge I had gained.
Which certification to choose?
The choice of a technical certification generally depends on several factors:
- The content of the associated training
- Its reputation
- Its difficulty
- Its price
- Other (company needs, client needs …)
Some proprietary certifications have no alternative; in that case the question of choice does not arise. When it comes to cybersecurity (and especially pentesting), there is a multitude of certifications with different characteristics.
To catalog these various certifications, community projects such as Security Certification Roadmap have emerged:
I will not cover all the certifications in this article; a presentation of some organizations was already made in my previous article.
As for me, the choice of the OSWE was mainly a natural continuation of the OSCP certification offered by the same organization. The “white box” approach is also uncommon, which reinforced my choice.
Note: Recently, Offensive Security introduced a more technically accessible “web-200 OSWA” level training. I don’t know the content of this training, but if I had to choose, I would still go for the OSWE for economic and technical reasons, and for its value in the “OSCE3” bundle.
A quick overview of the OSWE
Offensive Security
Offensive Security is an American pentest and forensics company created in 2007. The company notably maintains the pentest distribution Kali Linux (formerly BackTrack), as well as the ExploitDB website, the Google Hacking Database, and the pentest tool Metasploit.
The company offers a range of pentest training, including the OSCP, which is their entry-level certification. In my opinion, this certification is the best known in the pentest world. All of Offensive Security’s certifications are taken through practical exercises, unlike some organizations that opt for multiple-choice questionnaires.
AWAE Course
The certification comes with an “AWAE” (Advanced Web Attacks & Exploitation) training consisting of a PDF of more than 410 pages, as well as more than 10 hours of explanatory videos, all in English. Just like the OSCP, access to these resources is private and unlimited. The training’s content is quantitatively smaller than the OSCP’s; however, its content is technical and relevant.
The training also describes itself as follows: “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.” In other words: AWAE is a code-auditing course. We teach the skills needed to conduct a white box audit pentest on web applications.
AWAE Lab
This training is complemented by a virtual environment, also called the “Lab”. This environment consists of 11 machines. These are directly accessible, without segmentation or a pivoting system like the PWK lab. The machines also offer SSH or RDP access, whose credentials are provided with the training package. Access to the lab is done via an openvpn profile.
Price
The prices initially offered by Offensive Security are in US dollars. The euro prices do not account for potential fees from your bank. As for me, I opted for the Course + 60 days package at 1101 € and had no additional fees. Regarding the lab duration, I recommend 60 days of access at a minimum (I will come back to this duration later in the article).
The addition of recent content has changed the training’s prices since I took the OSWE. I’m listing here the prices that were offered to me. Note also that Offensive Security is gradually changing its offer model, with significantly higher prices for the latest trainings.
| Package | Price ($) | Price (€) |
|---|---|---|
| Course + 60 days of lab access + one OSWE exam | $1299 | 1101 € |
| Course + 90 days of lab access + one OSWE exam | $1499 | 1270 € |
| Retake | Price ($) | Price (€) |
| OSWE exam retake fee | $249 | 211 € |
| Lab Extension | Price ($) | Price (€) |
| 30-day Lab Extension | $359 | 304 € |
| 60-day Lab Extension | $599 | 508 € |
| 90-day Lab Extension | $799 | 677 € |
Training content
The AWAE course Syllabus is freely available on the Offensive Security website. It lists the various topics covered by the training (non-exhaustive list):
- Cross-Origin Resource Sharing (CORS) with CSRF and RCE. The beginning of the course covers client-side attacks and pushes you to develop complex exploits like CSRF/XSS.
- JavaScript Prototype Pollution. One or two NodeJS applications feature a Prototype Pollution vulnerability.
- Advanced Server Side Request Forgery.
- Web security tools and methodologies. Proxy tools like Burp and payload-generation tools like ysoserial are covered during the course. Black box oriented tools like ffuf are not covered. The proposed methodology covers setting up the debug environment.
- Source code analysis. This is a concept covered throughout the training.
- Persistent cross-site scripting. Just like reflected XSS
- Session hijacking. This type of attack relies on logic bugs that are interesting to approach in white box.
- .NET deserialization. The course covers building payloads “from scratch” and then with the help of tools.
- Remote code execution. Blacklist bypasses are also provided for a NodeJS application.
- Blind SQL injections. Tools like SQLmap are forbidden during the exam.
- Data exfiltration. I believe this refers to the outcomes of XSS and SQLi vulnerabilities.
- Bypassing file upload restrictions and file extension filters. Mainly applicable to PHP.
- PHP type juggling with loose comparisons. An interesting vulnerability, sometimes hard to spot in white box.
- PostgreSQL Extension and User Defined Functions. These are specific and advanced SQL injection exploitation techniques providing primitives such as file writing and code execution.
- Bypassing REGEX restrictions. Learning to recognize possible bypasses, notably for path traversal vulnerabilities
- Magic hashes. A specific technical vulnerability, but an interesting one in a white box context. The vulnerability is generally tied to a reduction in entropy that makes exploitation possible.
- Bypassing character restrictions.
- UDF reverse shells. Directly related to PostgreSQL injections
- PostgreSQL large objects. Directly related to PostgreSQL injections
- DOM-based cross site scripting (black box). Very lightly covered during the training
- Server side template injection. This vulnerability is approached rather from a black box perspective.
- Weak random token generation. Here it’s about recognizing entropy reductions or the use of obsolete cryptographic suites.
- XML external entity injection. Vulnerability related to XML parsers, sometimes used for Excel files.
- RCE via database functions. You notably learn to retrieve the xp_cmdshell function from an external dll.
- OS command injection via WebSockets (black box). The websocket approach is combined with other vulnerabilities. Interacting with them using a scripting language makes for a good exercise.
- …
Overall, I found the training content very specific, focused on very particular vulnerabilities. The training is, however, quite incomplete for a pentester wishing to progress in black box pentesting. A “remote debugging” section and the instrumentation of code and databases for debugging are also offered by the training. Although these points are not part of the syllabus, they were very interesting and relevant to my audit methodology.
The lab is a direct support for the course. Indeed, each concept is explicitly addressed through one of the lab machines. Additional exercises then let you deepen the concept on your own on the tested environment. Indeed, each machine generally offers several vulnerabilities, or alternative exploitation methods.
My starting level
As mentioned in the paragraph about my motivations, I am a young, passionate pentester, fresh out of engineering school and just certified in the OSCP. At that precise moment I am 23 years old and had already carried out several pentests, mostly on web environments. I had also taken part in many CTFs (around thirty), mainly with my team Aperi’Kube, and even organized a few. Regarding challenge platforms, I was fairly active on Root-Me, and had just come out of an intensive training run on HackTheBox. Finally, I already had particular ease with scripting and development (python3, PHP, Java), which was useful during my study. Before committing to this certification, I had not identified any “big” gaps other than the .NET environment, which was less familiar to me.
Because of the limited number of reviews from OSWE-certified people, I was apprehensive about this certification. I took advantage of the health situation and my intensive OSCP training to commit to it.
Important: My personal experience is in no way a prerequisite for taking the OSWE. The skills needed to obtain the certification are covered in the course. Prior experience in web pentesting (or CTF) and/or development is strongly recommended but will not exempt you from studying.
My preparation before the AWAE course
Hack The Box
My decision to take the certification did not directly translate into buying the OSWE package, but into training on the Hack The Box lab. For this I subscribed to the VIP offer at 10 £/month (~12 €/month). Access to the VIP offer gives you the old boxes (vulnerable machines), a quieter study environment, more stable machines, and less risk of spoilers from other registered members. The number of machines offering white box auditing is, however, limited compared to the environments used during my OSCP.
The boxes offered on HackTheBox are generally more “limited” in code footprint, and sometimes more complicated than those of the AWAE lab. These boxes are unfortunately the only environments “dedicated” to code auditing that I was able to find. There are several community lists enumerating the boxes relevant for OSWE study:
Just like the AWAE lab, the boxes offered on HTB generally require developing an exploitation “script”. Moreover, I got into the habit of developing exploits for each machine, in order to conform to the exam’s requirements. Generally, several actions are expected, such as compromising an application account and then gaining code execution. Linux/Windows privilege escalation is, however, not expected.
From March 2021 to May 2021, I rooted 4 retired HTB machines, that is, one box every two weeks for 2 months in increasing order of difficulty. I did this study outside my work hours at a less intense pace than my OSCP study. I solved these boxes without the help of Write-Ups (walkthroughs). Given the time-consuming nature of the exercise, I spent the last week reading Write-Ups of code-audit-oriented boxes. This trade-off between the time spent searching and the concept being taught is a parameter that can be hard to gauge. Also, I recommend that people who have not practiced “CTF”-type challenges not use these write-ups to start with, even if it means spending several days on a box.
I have not covered here the “Vuln-Hub” VMs or the code auditing of open source projects, which could have been good candidates as a pre-OSWE training environment. The latter has the advantage of being as close as possible to a real environment. I judged Hack The Box more relevant, because I had already been able to audit some open source projects.
Note-taking
While working on these boxes, I kept a personal wiki up to date to record my commands and techniques in an organized way. I opted for a GIT repository with files in MarkDown format, as well as scripts. Here is an excerpt of the structure:
├── Database
│ ├── PostgreSQL
│ │ ├── awae
│ │ │ └── awae.sln
│ │ ├── awae.c
│ │ ├── awae.dll
│ │ ├── revshell.c
│ │ ├── revshell.dll
│ │ └── so2sql.py
│ └── PostgreSQL.md
├── exploit_skeletton.py
├── Java
│ └── Java.md
├── JavaScript
│ ├── ClientSide
│ │ └── Javascript.md
│ └── NodeJS
│ └── NodeJS.md
├── Logging
│ ├── Databases.md
│ └── PHP.md
├── Microsoft.NET
│ └── Microsoft.NET.md
├── PHP
│ └── Functions.md
├── Scripting.md
├── TypeJuggling
│ ├── loose_comparison.png
│ ├── PHPMagicTricks-TypeJuggling.pdf
│ └── PHP.md
└── Unserialize
├── Microsoft.NET.md
├── NodeJS.md
└── PHP.mdTo be able to navigate and search these notes, I used the VSCode IDE:
This personal note-taking is, in my opinion, essential to progress and obtain the certification. Some pentesters will opt for different tools, such as CherryTree. Access to your wiki as well as to public wikis is allowed at any time, including during the exam.
Among the list of resources in my bookmarks, I would like to share the following, which I found useful for taking this certification:
- PayloadAllTheThings: A database of payloads, bypasses, and methodologies
- HackTricks: A comprehensive wiki describing methodologies by protocol or environment
- PHP.net: PHP documentation
Prior training?
In order to reduce training costs, it can be useful to train beforehand with the goal of minimizing your lab time (and limiting the number of exam retakes). The AWAE training and the AWAE lab are provided at the same time. It is therefore not possible to read the training before the lab-time countdown begins. Unfortunately, I have no particular training to recommend (other than AWAE!), but here are some articles covering part of this training and worth going through beforehand:
- Resources related to PostgreSQL injections
- Resources related to deserialization
- INSOMNIA - PHP Magic Tricks: Type Juggling: Specifics related to “Type Juggling”.
In general, I recommend all the “web” folders of the PayloadsAllTheThings repository.
Course and Lab
After rooting 4 boxes and reading a substantial set of walkthroughs, I signed up for the OSWEE package with 60 days of lab access. Offensive Security offers different training start dates (in order not to overload the shared lab). I was able to get a date on May 30, 2021, a few days after purchasing my package. Just as with my OSCP study, I spread my work across hours from 6 p.m. to midnight on weekdays, and all day on weekends. The training was very time-consuming, and I spent 90% of my weekends studying. Fortunately, the lockdown reassured me about not being able to go out.
Course
I was able to watch the provided videos in their entirety. The PDF course content is only a complement to the video course. I already knew a good part of the training’s content, which is why I regret not having taken the OSWE earlier. I still learned things, notably about the remote debugging environment, and about the .NET environment. I went through the course progressively, at the same time as the lab. Indeed, reading the course without technical support has almost no value, since it doesn’t let you practice or verify the behaviors covered.
Lab
Progression in the lab is particularly slow. Indeed, it only has about ten machines that are particularly long to exploit. I can’t give you a detailed study schedule; it works out to roughly 1 to 2 boxes per week, in the order covered by the course. Each machine has multiple compromise paths, and the course is built so that you can reuse the skills acquired in the following environments. The course suggests additional exercises (“Extra miles”), which I did and which I recommend doing.
Unlike the PWK - OSCP lab, the AWAE - OSWE lab is entirely dedicated to the student; no machine is shared and the environment is completely dedicated to each user. On the other hand, the machines are off by default and have an automatic shutdown mechanism when there is no more traffic. I did not experience any untimely disconnection during my study (over a lunch break, for example). Access to the boxes is explicitly provided in an interactive wiki, generally with SSH and/or RDP access.
I also advise you to get into the habit of using the tools covered by the course, notably on the RDP environment. Indeed, during the exam, it will not be possible to bring the applications back to your local machine.
Exam preparation
My lab was ending in July. One month before the end of this lab, I was able to schedule an exam date for July 7. Weekend slots are rare, so I advise you to schedule your exam date as soon as possible (it is possible to push this date back several times).
Before the exam, I prepared a report template based on the one provided by Offensive Security, but also the one offered by Noraj on his GitHub repository. Creating such a template is a valuable time saver that you should take into account. I also re-read all the rules relating to the exam (exam duration of 47 hours 45 minutes, restrictions on scanners, on SQLmap, professional tools forbidden, automated exploitation forbidden, mandatory proofs in the report…). I also set up backup solutions in case of problems: check your phone credit in case of an internet outage, set up a backup PC if possible, check whether you have a second webcam, etc. Finally, check your stock of energy drinks and/or coffee, and rest the night before your exam.
How the exam unfolds
The OSWE exam lasts 47 hours 45 minutes, to which are added 24 hours dedicated to writing the report. You are of course allowed to take as many breaks as you like.
Proctoring
The exam has recently become “proctored”: you must share all of your screens as well as your webcam throughout the exam (except during report writing). This sharing is done easily thanks to the Janus WebRTC Screensharing plug-in. When the exam starts, the proctor will then ask you to present your ID card, as well as to pan around the room with your webcam. Once the verification process is complete, the proctor will send you the exam terms. They will then contact you if the camera or a screen is lost. Conversely, you will be asked to notify the proctor during your breaks.
It is worth adding a major restriction: it is forbidden to bring the application back locally onto your machine. The white box analysis must therefore be done over RDP access. This restriction was particularly constraining, so it is essential to get used to the tools offered by the training.
OS
The OS used to take the exam is up to you as long as you can satisfy the OpenVPN connection as well as the proctoring. Having studied mostly on ArchLinux, I opted for an ArchLinux host + a Kali and Windows VM for the exam. I advise you to keep the same environment between your study and your exam, and to avoid doing updates the night before the exam. Unlike the OSCP, using the Windows OS seems more relevant to me than a Linux OS.
Grading
To pass the OSWE exam, a score of 85 points minimum is required. These points are awarded based on the compromise level of the different exam boxes. In addition, a complete exploitation script is required for each box. No interaction (other than providing the URL) may take place with the script. This means, for example, that the script must be able to generate serialized objects in any technology before sending it in a request. The use of external libraries (requests, ysoserial.jar, etc.) is allowed, but the script itself must be in a single file. In the case of a particular execution environment (for example, a script written in ruby with an external gem), you are asked to specify the deployment methods for the execution environment.
To this day, the only exam model I have come across in the various OSWE reviews was the following:
| Task | Description |
|---|---|
| ”Authentication bypass” (35 points) | Recovering a privileged application account (for example, using a SQL injection, XSS, …) |
| ”Remote code execution” (15 points) | Gaining code execution on the server |
| ”Authentication bypass” (35 points) | Recovering a privileged application account (for example, using a SQL injection, XSS, …) |
| ”Remote code execution” (15 points) | Gaining code execution on the server |
As you will have understood, discovering the 2 authentication bypasses and one code execution is necessary to obtain the certification. Discovering the 2 RCEs and one bypass is not enough to satisfy the certification conditions.
Just like the lab, all the boxes are riddled with “rabbit holes”. A good methodology, aligned with the exam, will help avoid spending too much time on false leads. The OSWE exam is special because the applications to audit are particularly large and you could spend entire weeks on them.
So I’m going to share the “exam-dedicated” methodology that I was able to prepare beforehand. I started by classifying vulnerabilities into categories, first checking “Which vulnerabilities allow an authentication bypass, without code execution?”. Here is a non-exhaustive list of answers:
- Session mechanisms (custom session cookies?)
- Forgotten-password mechanisms (password reset token)
- Administration mechanisms without access control (administrator account creation, password change …)
- XSS/CSRF (requires a client behind it)
- SQLi if the DBMS doesn’t support stacked queries
- Deserialization (in the case of an application where the only existing gadgets allow account takeover but not RCE)
- Other
The second question is therefore: “Which vulnerabilities allow RCE?”. Once again, here is a non-exhaustive list:
- Code / command evaluation
- File upload
- Deserialization (in some cases)
- SQLi (in some cases)
- Other
As for the technologies, they are varied; during my exam I was confronted with a PHP framework as well as a Java application (the number of exam machines to date being very limited, I will not give more information).
Finally, the number of points is not directly representative of the difficulty of the task.
My run
As a reminder, my exam started on 08/07/2021 at 7 a.m. Here is a detailed summary of my day:
- 7:45 a.m.: Discovery of the first bypass.
- 8:30 a.m. [35 pts]: Exploit script for the first bypass 🙂.
- 8:40 a.m.: Discovery of the first code execution.
- 9 a.m. [50 pts]: Complete script with RCE on Box n°1.
- 12 p.m.: Discovery of the second bypass.
- 3 p.m. [85 pts]: Exploit script for the second bypass. The certification is normally secured at this stage 🙂.
- 5:40 p.m.: Discovery of the second RCE. This is the vulnerability that seemed to take me the longest to identify.
- 6:30 p.m. [100 pts]: Exploit script with RCE on Box n°2.
I was able to use the following day to verify all my proofs and screenshots. I also started writing the report. You will note that the time to write scripts is not negligible, even for an experienced developer.
I finished the exam in less than a day, but I reckon I was very lucky with identifying the vulnerabilities. The 48-hour duration seems necessary to me.
Results
A few days after submitting my report, I successfully received the OSWE certification 🙂.
And after?
The end of the lab and taking the exam once again gave way to a void, but not without a certain fatigue. My evenings were no longer paced by my study, and the global COVID-19 crisis, although still present, gave way to an easing of the various lockdowns. Following that, I changed companies, progressed on Windows environments, and began some light study on the “OSEP” certification (anti-virus evasion and advanced attacks on Windows environments), without however planning to take it in the following months.
Acknowledgments
I thank my family, my friends, and colleagues who contributed in one way or another to obtaining this certification, and more particularly: