How to Prepare for the OSCP with the OWASP

In a previous article we looked at a pivotal vulnerability that any student of the OSCP will spend a good bit of time learning: injections. Be it via cross-site scripting, SQL injections, or command injections, this category of vulns is a dangerous tool used by any hacker, whether their hat be white, black, or a shade in between.

We learned about injections by way of the OWASP Top 10, a regularly updated list of the web's most critical vulnerabilities as enumerated and ranked by infosec professionals. As some of the most commonly exploited vulnerabilities, there is a good overlap between the Top 10 and the content you will face when going through the OSCP course.

Injections are but one of the items that fit in this overlap. It's worth your time both as pre-OSCP course prep and as a well-informed infosec professional to be well acquainted with all of the items on the list. Today, we will cover the three other vulnerabilities from the OWASP Top 10 that you will encounter the most during your OSCP studies: broken access control, vulnerable and outdated components, and security misconfigurations.

Broken Access Control

This category of vulnerability moved up to the first spot on the 2021 revision of the Top 10, so it is definitely a huge issue with security across the internet. It's so bad that OWASP claims that almost 4% of sites tested had some form of broken access control.

That may seem like a low number, but this means that one out of every 25 web applications were vulnerable. Do you use 25 web apps regularly? The number is probably more. Remember that just about everything from email to banking to social media to project planning to online learning is a web app these days.

But let's take a step back and ask: what exactly is broken access control and why is it so critical? A better first question actually might be what is access control? Think about the AAA framework and how it applies to access. The first A, authentication, is basically a login, whether it's via a password, single sign-on, or OAuth. The next A is authorization, or does the authenticated user have access to the requested resource. If you open a file in a shared network drive, the access controls define whether your authenticated user has the necessary read permissions to open that first or not.

The definition of broken access control then becomes clear: an authenticated user can access stuff that they shouldn't be able to. You can open files that you shouldn't be able to or see another user's orders or bank info or other sensitive info. Say for example you login to see the details on your order and the URL of that page is:

www.mywebstore.com/orders?order_number=123.  

What happens then if you change that number to 124 in the URL? If that's not your order, the app should return an error. Try it right now for example with Amazon; their order details page URLs look very similar to an orderID query string. Changing the orderID returns "There’s a problem loading this order," or in other words "Nice try hackerman but no dice!"

Broken access control on a less secure site however would allow you to see another person's order, possibly even modify or cancel it, see their name and address, or if security with mywebstore.com is really REALLY bad, see their credit card info. These attacks are also known as horizontal access control attacks, as you are gaining access to another user's stuff, but not necessarily gaining any elevated permissions within the app.

Another way to play with access control is by role-based attacks, which can lead to vertical access control issues. Vertical in this case refers to moving up and escalating your permissions within the app to a higher level.

Commonly web apps will use a system of role-based access control (RBAC) where users are created and assigned a role with certain permissions. The roles will be ones like user or admin. How the app verifies the authenticated user's role is where the app can be broken. It might be as simple as a role=user URL query string. If you mess around with that value, what happens?

Other apps might set a value like isAdmin=true with a cookie at login. Every request sent after that would pass the cookie back with the admin flag set, which the app interprets as "give this user admin permissions." This process is transparent if you only look at the URL, but it's trivial to intercept, view, and modify those requests with an app like Burp Suite.

If you login as a user, then intercept a request and change isAdmin=false to true, broken access control should give you full admin rights on the app! While many many web apps use much more secure authorization methods, many still don't, hence broken access control's place atop the OWASP Top 10.

For a great real-world example of broken horizontal access control, check out this report on a researcher who found he could simply manipulate API parameters on requests to the Steam store to download thousands of CD keys for any game, even games he had not purchased. Now that's the ultimate Steam Summer Sale!

Vulnerable and Outdated Components

Just about all web apps are not built 100% from scratch, but are built upon a number of language frameworks and third party dependencies. A framework is a foundation in a specific language that developers can use to have a set of prebuilt code libraries and tools, so that they don't have to reinvent the wheel with every project. For example, a Javascript developer would commonly use Node.js or AngularJS. The more well known frameworks are commonly open source with wide community support and active development.

Third party dependencies, when talking about frameworks, are packages installed in a project to add extra functionality to extend the framework. For example, a popular Node.js package is Moments, which has functionality to manipulate and parse dates. A developer working on an app which needs to handle dates a lot can write a bunch of code from scratch, or just install Moments and use it's prebuilt functions to accomplish the same tasks quicker and probably better.

These frameworks and packages are great tools for developers to work smarter not harder. The bad news though: like all code they are susceptible to hackers looking for vulnerabilities to exploit. This is only made worse by how commonly some of these components are used and how the open source code is available for analysis. There is good news. Popular frameworks and packages with active development usually get fixes for security issues.

This is of course assuming that someone is keeping an eye on your framework and package versions and aware of when a vulnerable version of something is running in production. And apart from out of date vulnerable packages, another issue is malware in compromised packages, like the recent issue with ua-parser-js including a crypto miner.

To avoid these issues, use tools like Snyk for dependency scanning to monitor and report on vulnerable packages in your codebase.

Security Misconfigurations

Our third and final OWASP Top item for today is security misconfigurations. This covers any number of issues where typically an admin or engineer gets caught forgetting about some means of security hygiene and fails to harden an application or network device. Basically, they leave a door or window unlocked and it's unusually just a matter of time until someone finds it and lets themselves in.

The most common security misconfiguration: leaving default accounts names and passwords unchanged. How many devices and applications come with a default admin account with the password of "password" or "admin"? We can put some of the blame on the designers who don't force a new secure password on setup, but still, it's trivial to find unsecured applications and devices strewn across the entire internet. Host and network security scanning applications will commonly try logging in with common credentials during a scan, so there's nowhere to hide.

One situation ideal for a bad actor is an IP address leading to the login page for a device or application. Almost always the page is plastered somewhere with the application name or device model and manufacturer. It's only a quick Google search to find what the default login credentials are or that app or device.

It doesn't stop with passwords though. Take a firewall with the login page or it's admin interface accessible from the public internet. Even with super secure passwords, best practice would say that the page shouldn't be publically accessible at all. Access should be limited to inside the LAN for a firewall, with VPN access enabled if remote work on the device is required.

What about a web app that is too chatty, giving away details about the host it's running on? Many web servers use a debug page to give extra info to developers on errors. While helpful to fix issues during development, these pages should be disabled on live production sites. They can give out juicy info, like application paths and other filesystem info (helpful for directory traversal attacks) or libraries in use with version numbers. (which we've already seen can be problematic). Even worse, they could possibly expose environment variables with passwords, API keys, or other secrets.

Cloud infrastructure services like AWS S3 are also just as susceptible to misconfiguration. AWS goes to great lengths to help you configure your S3 buckets securely and keep private files private. Lots of intentional extra steps and warnings come between you and setting a bucket to be public. That doesn't stop a constant flow of leaky buckets hitting the news, like this list shows.

Final Thoughts

The OWASP Top 10 as we've seen covers a multitude of security issues, both relevant to your OSCP studies as well as the tactics and techniques that the bad guys will use to keep us all with plenty of work to do. If you're pursuing your OSCP, you'll run into these three techniques plenty. Once you've tried harder and earned your OSCP, study the other seven well as all ten in total are incredibly relevant to any infosec professional. The bad guys are setting the precedent, it's up to us to keep up!