Last week, I passed the Offensive Security Web Expert (OSWE) exam after a few months of preparation. In this blog post, I summarise my experience of taking the course including tips and tricks, tools and plugins that made life easier, and my general approach to white box web application testing.
Overview
The Advanced Web Attacks and Exploitation (OSWE) course is a white box web application pentesting course which, true to Offensive Security's 'Try Harder' mantra, will help you step up your web hacking game. At its core, the OSWE teaches you a structured approach for reviewing source code in a variety of languages, identify vulnerabilities, and develop fully-fledged exploits which leverage these vulnerabilities to gain remote code execution. The updated course covers about 50% more material, including three new core modules to help sharpen your skills (one of which follows a black box approach) and three 'challenge' machines, which are designed to put your vulnerability discovery skills to the test.
There are ten modules in total, each covering a decent breadth of application vulnerabilities, from your classic cross-site scripting and blind SQL injections to more exotic, language-based flaws such as PHP type juggling and loose comparisons, insecure deserialisation, server side template injection and XML external entity attacks. The course is part of the updated OSCE3 (along with OSEP & OSED) and comes bundled with either 60 or 90 days of lab time. Due to work and other commitments, I initially opted for the 90 day option, but ended up extending so I could completely cover the updated material.
Pricing
The pricing for OSWE is along the same vein as the other OSCE3 courses. I purchased 90 days of lab time with a view to complete all of the exercises, extra miles and additional challenge machines. After completing everything, I was left with a week before the exam where I could go back round and look over any chapters and extra miles I felt weaker in. By exam time this was crucial, given the volume of content and the way it is arranged in the PDF. For instance, by the time I completed the extra miles in chapter 10 it had been weeks since I had looked at PHP code.
The course pricing as per the Offsec website is below:
Pre-reqs and prior knowledge
As Offensive Security mention in the course overview, the OSWE is an advanced web application security course. Given that its main focus is around source code review, going in with development experience in Java, PHP, Python or NodeJS is a definite plus. Background knowledge in this is by no means a requirement however, as the course is well-paced and brings you up to speed with understanding each language and its quirks. I felt comfortable going in with a bit of Python scripting experience and a fairly good understanding of Java, without knowing anything too fancy.
Students who come into the course from an OSCP or equivalent background are in a good starting position, given that it already covers basic scripting in Python and Bash. Writing your own proof of concept code is one of the key focuses of OSWE, and whilst the course covers this in Python, you are free to use whichever scripting language you are most comfortable with. The PDF and course materials include several example scripts to demonstrate how particular exploit steps work, and usually start with some skeleton code which you can flesh out during the exercises.
As you get through the course, Offsec gradually takes away the training wheels and you start to get comfortable with writing your exploits from the ground up. I would recommend that rather than copying and pasting any of the provided code written in the PDF, write out each line of code in vi/visual studio code, as this helps with building muscle memory and your own understanding of what the code is doing. By the time you take on the challenge machines, you should be well-versed in the end-to-end vulnerability discovery process.
What will you learn?
In short, a lot. In OSWE, Offensive Security gives you a taste for web application vulnerabilities across a range of application types, as well as a general approach for identifying and exploiting them. The methodology taught by the course is broadly structured into 'authentication bypass' and 'remote code execution', which works well for understanding each application from its unauthenticated and authenticated attack surfaces. As a starting point, I apply the below questions to get started on vulnerability discovery:
- What does the application do?
- Where are the areas for user input?
- Which pages are reachable without authentication?
- Which 3rd party vendor components and libraries are in use?
- Is there password reset functionality?
- Is there an alternative to password-based authentication?
- Is user input used directly within database queries, and if so, how?
I tend to explore the above areas by first walking through the application using Burp Suite to capture requests, and then mapping any interesting endpoints to the source code. From there, you can start delving into the more language-specific flaws based upon the vulnerabilities touched on during the course. Each chapter follows a case study of a real commercial or open-source application, and so you get a decent feel for mapping potential attack vectors to particular languages, application libraries and frameworks. However, in many real world cases, you won't have visibility of the source code to help focus your attention. To cover this, the final module of the course follows a black box testing approach, during which the entire target application is scoped, enumerated and exploited from an unauthenticated context and without access to the source code. I felt that this was a great addition to the original material, and helped with my day-to-day web application engagements which more typically follow this approach.
Something I also found really useful from the course was around how to set up a general debugging environment to help you find vulnerabilities faster. Throughout the exercises, you will get to work with a few different combinations of web servers, databases and application frameworks. Before you get your hands dirty with finding bugs, you can cut the overall time taken by configuring various debugging settings to give you better visibility over what you are testing. In the case of hunting for SQL injections, database logging will show you your payload as each query is executed. Application logging can be configured to identify edge cases for file upload bypasses or payloads in deserialisation attacks. Configuring your machine to act as an SMTP server can show you how out-of-band activities, such as password reset emails are being performed. As the focus is on white box testing techniques, most of these utilities will be available to you. I have found that getting to grips with setting up a complete debugging environment also helps your overall sysadmin knowledge, day-to-day skills as a tester, and any code review projects you do on the side.
Extra miles
Following the explanation of each core topic within the PDF, the OSWE course features 'extra mile' challenges designed to reinforce the core module concepts. These are separate tasks to the exercises which require the student to go above and beyond (see: Try Harder) by exploiting the target application in a way which is more challenging or obscure than the one covered in the walkthrough. In my experience, the best approach was to cover each of the extra mile exercises shortly after finishing the main chapter content. This way, I felt more focused on the application, and already had a fair bit of googling behind me for anything I didn't fully grasp in the PDF. In most cases, solving an extra mile required some additional research on the vulnerability class and sometimes even a new tool or angle of attack. Some of the challenges took literally minutes to complete, whereas others took several days of hammering away at solutions. All in all, doing the extra miles will deepen your understanding of the vulnerabilities and helps refine your code review skills.
Challenge machines
After you've completed the module exercises and tackled the extra miles, that leaves the three challenge machines. These are a great addition to the updated syllabus, as they are a good opportunity to test your vulnerability discovery skills ahead of the exam. As the solutions to the machines are not covered within the course, Offsec leaves it down to the student to discover and exploit the vulnerabilities independently. Two of the three machines follow a white box pentesting approach, where the complete source code of the vulnerable application is provided along with SSH credentials. The third is a black box assessment, and relies on the skills built on in the final course chapter. Without giving away too many details, I would say that all three machines are definitely worth doing, and can help pinpoint weaknesses in your approach. Most importantly, they help with providing that extra confidence to take on the exam.
OSWE exam
As with Offsec's other advanced courses, the OSWE exam is proctored. If you've taken an Offsec exam in more recent years, you'll be familiar with the generally smooth and straightforward proctoring process. Once the formalities are covered, you have 48 hours to hack your way through two custom applications, and a further 24 hours to write and submit your exam report. Your best chance of success is to know the course material thoroughly when going into the exam, and, if you have time, cover all the extra miles and challenge machines.
My main advice for the exam would be to keep things simple and think back to the techniques covered in the course if you get stuck. I found that the 48 hours is enough time to run through the code of both applications, locate the vulnerabilities and craft your exploits. Ideally, package any of the solution scripts you wrote for the exercises ahead of time, so you can easily refer back to them if needed. I kept a Google stopwatch running in the background as I worked to keep track of my progress, making sure that I split the time between the targets evenly. Taking screenshots along the way was also a big help towards keeping track of things I thought were important, as you are expected to reproduce your methodology step by step in the report. As with any Offsec exam, take short breaks often and remember to eat, sleep and rest your eyes from looking at code.
General tips
In no particular order, here are some of the tips and tricks I picked up along the way:
- During the course, script out each of the Python helper scripts referenced in the PDF line by line. If the code is written in Python 2.7 (as with some of the older modules), try porting it to Python 3 on the fly.
- Attempt all of the course extra miles and challenge machines ahead of taking the exam. Once you find one way to obtain auth bypass/RCE, try to find alternate paths.
- Refresh your approach for remote debugging with Visual Studio code. The Remote - SSH plugin can come in really handy for reviewing code without pulling it off the remote machine.
- If you come across any encoded data in Burp Suite, decode it. [Ctrl + Shift + B] is a useful shortcut for decoding base64 encoded strings.
- Once you complete all of the course content, sweep through the videos once again and review the parts you felt weaker on. If you want to brush up on a particular topic, PortSwigger's Web Security Academy is a great place to check out.
- Keep a mental note of particular vulnerabilities and map them to specific programming languages. This makes it easier to rule out attack vectors which are less likely than others for a given application.
- Make use of debugging utilities such as application and database logging, SMTP server configuration and general SSH access.
- Get some practice with scripting your exploits from scratch. If you're using Python, practice using the requests library -- especially when working with sessions.
- As you must include any proof of concept exploit code within your report, I would recommend using the SublimeHighlight plugin for Sublime Text, as it allows you to export your code to RTF to display syntax highlighting.
What's next?
I would recommend the Advanced Web Attacks and Exploitation course to anyone looking to add additional tools and skills to their web testing arsenal. Having experienced a purely black box testing background when it comes to web applications, I now feel more confident in delivering when following a code review or assessing security from a white box angle. As I'm keen to jump back into the Active Directory and internal pentesting side of things, I'm looking next to complete the Evasion Techniques and Breaching Defenses (OSEP) course after a short break.