The State of OSWE

4 min readSep 11, 2019

Introduction

This document is intended as a resource for those who want to conduct white-box pen-testing engagement or who’re preparing for Offensive Security Web Expert (OSWE) exam. After reading this recipe, you should understand what is required to be successful at the white-box pen-testing process and to hopefully pass the OSWE exam.

Intentions

The intent of a white-box attacker in many cases is to identify potential points of weakness by sifting through a massive amount of codes, making it the most time-consuming type of penetration testing. White-box pen-testing perhaps the most accurate and efficient internal pen-testing type would the organization do since white-box penetration testers can perform static code analysis, making familiarity with source code analyzers, debuggers and similar tools necessary for this type of testing and filling in for the significant blind spots where automated scanners simply cannot check. However, dynamic analysis tools and techniques are also crucial for white-box testers since the static analysis can miss vulnerabilities introduced by misconfiguration of target systems.

What is OSWE?

Advanced Web Attacks and Exploitation (AWAE) is the premier web application security and pen-testing training, upon successful completion of the course and certification exam, you will officially become an Offensive Security Web Expert (OSWE), which demonstrates you have mastered the art of exploiting front-facing web applications.

Offensive Security AWAE Labs

The course serves three main purposes, analyzing the source code, reverse engineering for closed application (decompiling and debugging) and improving thinking to achieve expanded view of standard vectors. The Offensive Security team provides you with PDF, videos, and lab access. My method was to read the section on the PDF, then watch the corresponding video, and then implement it in a lab environment to get a shell. I progressed through the entire thing in about a week.

Regarding the AWAE syllabus, the course covers the following topics in detail:

Tools & Methodologies.
Persistent Cross-Site Scripting
Blind SQL Injection.
Type Juggling.
Authentication Bypass.
Cross-Site Request Forgery.
Data Exfiltration.
Bypassing File Upload Restrictions.
Bypassing REGEX restrictions.
.NET Deserialization.
Session Hijacking.
Source Code Recovery.

Calling out specific types of vulnerabilities in the course can add to the realism of accurate assessments while mitigating some of the professionalism. It can provide valuable results to the pen-tester in real-life scenarios.

The concept of the source code review is pretty straightforward: An attacker wants to sift every single line of code, to perform an action that enables further compromise of the target, and that’s what you’ll find it in the course. Whether attempting to target a website by persistent cross-site scripting, session hijacking, cross-site request forgery or bypassing REGEX restrictions, the complicating factor is to get a shell in the labs.

Best Practices

When hackers stray from being ethically appropriate, they can damage any benefits or findings by affecting the professional image of the pen-tester. Being a hacker who has the right to break into other organization’s assets is a great thing. However, it’s essential to the professionalism that ethics are being made throughout the whole engagement and avoiding immature practice such as messing with the databases through troll strings or images, which could undermine the entire efforts that have been made.

White-box pen-testers are often fallen to the temptation of rabbit holes, which are time sinks that can distract them away from the potential weaknesses. Tracking inherent weaknesses is similar to tracking a rabbit hole; both take a significant effort to explore and may consume lots of time of the overall engagement or exam. Hence, being too cautious or too slow is something with which even expert hackers can struggle in.

The Exam

My exam started at 19:00 PST Sunday. After 30 hours of intensive work, I got nothing, not even a single point. The challenge of not being able to get any aspect of these challenges/systems can draw hackers into trying to defeat the problem, instead of moving on to machines that are bit easier to access and that may contain potential weakness; I’ve faced that a lot in bug bounty life as well. It can be challenging to keep your conciseness need of getting a shell in your mind when facing many rabbit holes or challenges (CTF stuff) of each target encountered. At the same time, the tremendously important this is to prioritize your attack based on the exam points.

I wasn’t involved in any kind of stress as my previous OSCE & OSCP exams since I’ve managed to take some rest every 2 hours, take a nap, take a walk, eat healthy food or anything that’s not related to technology at all.

12:00 PM PST on Thursday, which is 6 hours and 45 minutes before ends of the exam, I’ve got it and finished the exam.

Reporting

The audience, in general, may vary from security analysts to business-oriented owners, and the report needs to enable the totality for the audience to understand the importance of the finding in it. However, in the OSWE exam case, the audience is technically savvy security stuff, which is something good to deal with since you’ll be comfortable in the terminology part.

Technical vulnerabilities, non-technical vulnerabilities, non-exploited vulnerabilities yet aren’t in the Offensive Security team’s scope, but these vulnerabilities can be just a severe or even more impactful to the target, so keep those in your mind while you are conducting white-box pen-testing engagement.

During the reporting phase, as the business owners of the organization might not buy off on engagement activity, the vendor may not be contracted again. Similarly, in the OSWE exam, the Offensive Security team might not buy off your exam report if you didn’t follow the exam rules of engagement.

Resources

- B1twis3 | Hamid Mahmoud