Hello Hackers,
It's been a while since my last post, and I'm excited to reconnect with you all. Recently, I successfully completed the OSWE course (WEB-300) and earned the certification. Today, I'm eager to share my journey, experiences, and key takeaways with the community.
Whether you're a novice pentester or a seasoned hacker, especially if a significant portion of your work involves web application penetration testing, then the Advanced Web Attacks and Exploitation Course (AWAE) is going to level up your skills. This course uniquely focuses on the intricacies of white box analysis in web application security, delving into the meticulous review of application source code – and yes, all without relying on automated scanners, bypassing the defenses and writing exploit codes.
Join me in discovering the valuable lessons learned, the challenges faced and the things to consider if you are also planning to undertake AWAE course & certification.
I. Preparation
You may already be aware that OffSec now only offers subscriptions for its courses and certifications as 90-day or 1-year bundles. If you are planning to go for the 90-day course and certification, having some preparation ahead of time would certainly help.
Therefore, before you purchase the course, it is recommended that you are well-versed in at least the black-box approach of testing web application vulnerabilities, as it certainly not a beginner-level course. If you lack this expertise, consider starting with Offensive Security Web Assessor (WEB-200) or Burp Suite Certified Practitioner (BSCP).
Furthermore, it would be beneficial to have proficiency in both reading and writing basic web applications across a range of programming languages, including PHP (Laravel and Symfony), Java (Spring and Hibernate), ASP.Net, Python (Flask and Django), and Node.js (Express).
Code Review Projects:
PHP: simple-php-website & Fuel CMS
ASP.Net & C# : SimpleWebAppMVC & Reddnet
Node JS: Employee Database & JS RealWorld Example App
Java: Java Web App – Step by Step & GeoStore
OSWE Like VulnHub VM: SecureCode1
TJ Null's playlist of HTB Boxes for OSWE
Secure Code Review Guide(s) & Challenges:
https://www.sonarsource.com/knowledge/code-challenges/advent-calendar-2022/
https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf
II. The Course & Lab
The course has multiple sample web application, written in different language / framework having unique vulnerability each dedicated in a chapter. The objective is to read the source code, identify the vulnerability and figure out the way to bypass any filtering or defense mechanism put by developer to exploit the vulnerability. And finally develop a script in the language of your choice to automate the entire exploit scenario, mostly getting RCE.
The course states that it is initially based on Python 2.X for writing exploit code, but you are not really limited to that; you may feel free to write exploits in Python 3.
You are also granted access to the OffSec Discord Server, providing an opportunity to interact with fellow students enrolled in the course, as well as Student Mentors who can assist in clarifying doubts related to exercise labs or challenge labs. In my experience, while instant responses to queries might not always be guaranteed, they are addressed whenever someone is available. Therefore, I would recommend utilizing the search function, as it is highly likely that someone else may have encountered and resolved a similar issue.
You can take a sneak peek into the modules for the course by clicking here. Below is a concise list of Content Management Systems (CMS), Programming Languages, and vulnerabilities covered:
- Akount | PHP | SQL Injection & PHP Type Juggling attack
- Manage Engine | Java | SQL Injection (Postgres DB)
- Bass Master | Node JS | Script Injection
- Dot Net Nuke (DNN) | ASP .Net Framework | Deserialization
- ERP Next | Python - Frappe | SQL Injection & Server Side Template Injection (SSTI)
- OpenCRX | Java | External XML Entity (XXE) & HSQLDB
- OpenITCOCKPIT | Black Box | XSS & Command Injection
- Concord | BlackBox | CSRF
- Directus | Type Script| SSRF
- Glucamole Lite | Java Script | Prototype Pollution
III. The Exam
The exam duration spans 47 hours and 45 minutes, during which candidates are assigned the task of exploiting two web applications. The primary objectives include bypassing authentication to gain admin user access and subsequently achieving Remote Code Execution (RCE) access to the server.
An essential requirement is the development of a single exploit script (if the code is in multiple parts, then it needs to be called internally within your main script), in any programming language, to automate the exploitation process (authentication bypass and/or RCE) without requiring user intervention; failure to do so results in zero points.
Each application consists of two Virtual Machines (VMs): a target VM, requiring exploitation to obtain local.txt (post-admin access) and proof.txt (post-RCE) files, and a Debug VM, similar to the target VM with the same code and configuration, with the exception of any application-specific configuration constants and credentials for the web interface and operating system
Access to the Debug VM is facilitated through Remote Desktop Protocol (RDP) or Secure Shell (SSH), with pre-installed tools configured for whitebox analysis. Admin rights are necessary to access/read the local.txt file (worth 35 points), while RCE is required to read the proof.txt file (worth 15 points). The passing threshold is set at 85 points, necessitating the successful resolution of at least 3 out of 4 flags.
My Experience:
I scheduled my exam for 8 PM (Wed) and successfully identified the authentication bypass on the first target machine around 2 AM on the same night, although I encountered a few rabbit holes along the way. Following this breakthrough, I decided to get some sleep and resumed the next day at 9:30 AM (Thru).
Regarding the RCE vulnerability, the exploitable feature was evident on the screen; however, crafting a successful payload took some time. Eventually, I managed to complete the RCE part by 1 PM and spent the next 3.5 hours finalizing the exploit code. Taking a break for 1.5 hours, I resumed work on the second target at around 5 PM, successfully achieving authentication bypass by 7 PM.
Feeling exhausted by this point, I took a break, went for a walk, had dinner, and then rested. The next day, I resumed work at around 9:00 AM (Fri), focusing on drafting the exploit code for authentication bypass on the second VM. The scenario proved to be tricky, and it took me some time to complete the proof-of-concept code by 3:00 PM, including a lunch break.
Unfortunately, my attempts to identify the vulnerability for exploiting RCE on second target were unsuccessful – perhaps due to a filtering mechanism or another rabbit hole; the cause remained unclear.
Nevertheless, I had already secured 50 marks from the first target (35 marks for authentication bypass and 15 marks for RCE) and an additional 35 marks for the authentication bypass on the second target. This brought my total to 85 marks, which was sufficient to pass the exam.
I began drafting the report on the following day (Saturday) at 8:00 AM and successfully completed it by 6:00 PM. After submitting the report, I took the opportunity to rest for the remainder of the day, eagerly awaiting the results.
To my surprise, I received an email stating that I had not passed the OSWE exam, despite securing what I believed to be 85 marks. I was confident in submitting all the flags and relevant screenshots from Burp and the browser, displaying local.txt and proof.txt from the reverse shell as stated in exam objectives.
I reached out to Offsec support and detailed all the completed objectives along with their references in the submitted report. The Offsec team responded promptly, and within 24 hours of raising the query, I received an official response acknowledging a discrepancy. The result was then rectified, confirming that I had indeed successfully passed the OSWE exam.
And thereby, got my OSWE certification!
Exam Tips:
- Read the exam objectives carefully 😉!
- Familiarize yourself with debugging techniques by integrating Visual Studio with the debugging port on the target system. This skill is invaluable and can save you hours of frustration during the troubleshooting process
- The intended way to compromise the target VM requires you to bypass the authentication process to obtain administrative privileges. Only after achieving admin rights should you proceed to exploit another vulnerability to gain Remote Code Execution (RCE) access. If you suspect that a vulnerability could grant RCE access directly from a guest-level entry, it might be a rabbit hole.
- When exploiting the initial authentication bypass vulnerability, concentrate solely on features accessible to guests or normal application users. Additionally, scrutinize the application's routing mechanism to identify hidden endpoints that may not be invoked from the UI when navigating through the application in a browser.
- Bypassing authentication or obtaining RCE may require linking multiple vulnerabilities present across various application features. So, think out of the box!
- It is mandatory to develop a single exploit script capable of exploiting both the authentication bypass vulnerability and triggering RCE without requiring user intervention. Ensure that your code snippets from lab exercises are prepared in advance, to save time during the exam while writing exploit script.
- Make sure to take comprehensive notes during the exploitation process, including screenshots of relevant code snippets and Burp Suite interactions wherever necessary. This proactive documentation will significantly streamline the report drafting phase and save effort later on.
All the best and happy learning!