Broken Access Control is one the OWASP top 10. Access control can be defined as an application’s ability to give or take away access to certain types of credentials or data based on the authorization of users. Say for example we have a banking application that allows access to alice’s personal banking information and her account is declared with the id=321. And bob has the id=322 and alice can manipulate the id such that is the numeral 1 is replace with 2 and the application improperly applies the necessary controls then alice could view bobs account information. This is a simple use case with wider implications. 

The impacts can vary from leaked user data like account info above, horizontal or vertical privilege escalation from a low privilege user to admin, logic flaws to manipulate cart transactions, path traversal and RFI.

IDOR

I would like to go over 3 quick examples. The first being IDOR or Insecure Direct Object Reference. Which I have briefly touched on before on my blog. But in short IDOR is a vulnerability in which a user manipulates code and in return is supplied data from an application directly. In this example we will be using DVWS Node. This application has a note taking functionality that can be manipulated to access notes via the GET request that is called to the API. 

We have generated a few notes for our testing purpose. After generating the note and firing up our proxy BurpSuite we captured the requests and started playing around with the application. Notice the Update button, after clicking the button we get an interesting request we can use to manipulate the web application.

We can then manipulate this portion of the get request:

/api/v2/notes/

By adding a 0, 1 or 2 to the end. Which will dump the contents of the notes endpoint of the API. 

/api/v2/notes/0 or /api/v2/notes/1

What is super important in this attack is that we are manipulating the id parameter. To glean useful or relevant information about the contents of the notes. 

Obviously this is a simple attack, but depending on the context it can be incredibly devastating. Maybe the information accessed is actually critical to the upkeep and maintenance of the company or server.

Vertical Privilege Escalation

In the context of access control vulnerabilities vertical privilege escalation is when a user is allowed some functionality that is not otherwise granted to them. So for example say Alice is a normal everyday user but is able to manipulate a portion of the application request to elevated her privilege to delete or modify another user. This is probably one of the more severe attacks due to the ability to fully compromise an application and wreak havoc. 

The PortSwigger website has an amazing series of web application based testing exercises. All focused on the OWASP top 10 and very great for beginners. I will quickly just touch on a small but easy exercise demonstrating the concept of vertical privilege escalation.

In one of the exercises there is a web store with different users and functionalities for each user. The objective is to find the admin panel, browse to the admin panel and then delete the user carlos. So first we need to locate the main page and view the source code. Scrolling through the code we locate a JS script. With our admin panel directory:

/admin-f8pyuv

Taking this and adding to the end of our url we are able to access the admin panel below.

Once in we now have full control of the admin panel and can manipulate aspects of the web application. 

Path Traversal

Is a vulnerability in which information or data on an underlying servers directory structure is accessed due to misconfigured permissions. So for example a .php file is called directly from the URL of a server and displayed by the user if permissions are incorrectly set a user can browse the /etc/passwd file.

For this example I am going to use DVWA to show how this vulnerability can occur. Setting the security level to low and browsing to the file inclusion section.

We will manipulate the application in our proxy. By changing the URL path to our .php file from include.php to /etc/passwd

Whatever way you desire to do this you can do it inline in the URL or via a web proxy. I prefer the web proxy since I can use the Repeater tab to change and configure data on the fly. 

Digging into the code we can see the code is calling directly to the page and not filtering out user supplied input to the applications underlying server via the PHP get method. 

Now that we have broken down some examples of broken access control let’s dive into some steps for remediation. 

Mitigations

For remediation of access control issues there are quite a few things you can implement into the architecture of your web application. I will go over a few that are detailed in the OWASP cheat sheet linked below. If you want a full description of how to do check out the links below.

• Role Based Access Control: access decisions in which the roles and responsibilities are defined by the users function.
•  Discretionary Access Control: restrictions based on the id of a user or membership within a group/s. So this can be credential separation like a low privilege user and admin need to perform different actions.
•  Mandatory Access Control: information is accessed based on the sensitivity, so a need to know basis, admin only has grants access.
• Permission Based Access Control: decision is based on whether or not that user has permission associated with that information or content.

https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls

https://cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html

My second Vulnerable VM nameSpaceS0S is live on VulnHub.
https://www.vulnhub.com/entry/namespaces0s-1,584/

Today’s post will be focusing on different attacks on the XXELab. First, let’s define XXE, what it is, and how it presents itself on a web application. XXE stands for XML External Entity attack and any application that parses XML input may be vulnerable to this type of attack, especially if it parses data without filtering input from the user. This attack can lead to sensitive server side information being disclosed like user password files, logs, software versions, and remote code execution allowing a full compromise of the machine. XXE takes advantage of an entity, an entity is a storage unit of some type. The entity is declared as a system identifier which can then be called within an XML document. Now let’s move onto the XXELabs exercises. 

The Lab

If you have not heard of XXELabs it is an amazing project it is a simple webapp with an XXE vulnerability. You will need a proxy to play with this setup project like BurpSuite or ZAP. I will not go over the installation setup for the proxy or the lab since there are many other websites that detail this. Plus the XXELabs has an amazing setup guide on their GitHub. 

This is the user interface for our vulnerable XML web application. Now let’s fill in the form, capture the request, and attack. 

The Methods

Let’s talk about different XXE methods first. There are a few and I won’t detail the DOS attacks since I am mostly interested in exploiting and exfiltrating data to be used in testing applications in the wild. Since this is where the biggest risk lies for any company. DOS can be a nuisance but it does have its uses for leveraging into a system further and compromising other aspects of the network. 

The 3 types of attacks we will cover in this 2 part series are accessing a local resource, remote code execution, and then in part two we will go over external URL commands using the HTTP module. 

Module Types

When exploiting XML we have a few commonly used modules types we will be using to exploit our victim machines. Most often we will use file: http/s: expect: all will retrieve useful data from the server to the attacking machine. 

The Basics: A string to /etc/passwd

A basic XML response will look something like this the XML parser is executing code onto the remote server. Inside of the POST response we can see we get a call for XML version 1.0. 

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

The XML form below gives us different parameters to inject our code into using the registration form. With fields such as name, telephone number, email address, and password. 

Now lets begin to craft a bit of malicious XML code into our registration form. We will begin by calling a Document Type Definition which defines the document with a list of valid elements and attributes. This is where we will be leveraging our attack.

In this example we will start with a basic “Hello world” attack. By placing the world into an attribute called bar. Calling is in our XML code below with &bar; in the email parameter.

Once we have verified this attack we will move onto placing and expect://id module into the XML code. So moving from a string to an exfiltration attack to gain knowledge about the underlying system. 

Our new code should look something like this:

<!DOCTYPE foo

  [<!ELEMENT foo ANY >

   <!ENTITY xxe SYSTEM “expect://id” >]>

We will be calling the SYSTEM and the expect id of the user who has control over the application. After modifying out code we get the output of the user www-data. 

And then changing the n0ps@email.com with our new attribute. 

Now that we have gone from a simple string replacement to identifying the id of the web application user we will modify our exploit to gain some interesting output about the underlying system. Taking the same code we had from before we will modify it slightly to look like this:

<!DOCTYPE foo [

  <!ELEMENT foo ANY >

  <!ENTITY xxe SYSTEM “file:///etc/passwd” >]>

Run our code in the BurpSuite repeater tab and we should see the output of /etc/passwd file.

In the next article I will show you how to go from XXE to RCE and other fun little tricks in the XXELab. Plus some mitigation techniques!

I have been spending the last few weeks building and deploying vulnerable VMs locally on my machine. Today I happened upon a new CVE Privilege Escalation developed by Arnauec. This takes advantage of “A flaw… found in the Linux kernel before 5.9-rc4. Memory corruption can be exploited to gain root privileges from unprivileged processes. The highest threat from this vulnerability is to data confidentiality and integrity.”
POC code by Arnauec

This is my first vulnerable virtual machine called fishymail. You can download it here load the .vdi up on VirtualBox and give it a try. Feel free to contact me or leave a comment if you have any questions or need some help troubleshooting.