by Felipe Novais (crwl3y)

OWASP DefectDojo (CVE-2023-48171) Introduction

Have you ever imagined a cybersecurity tool having vulnerabilities? It may sound counterintuitive for people outside of cybersecurity. Yet, this was the case for DefectDojo 1.5.3.0 at the beginning of January 2019.

We’ve implemented DefectDojo 1.5.3.0, the Open Source DevSecOps tool with application vulnerability management capabilities for manual and automated flows. You could do it in the traditional style or your CI/CD DevSecOps pipeline. We were trying to find a security tool to ease the penetration and vulnerability assessment workflow and make our analysts’ lives easier (we love them <3). So, I was tasked with testing the tool to check if it would benefit the team. During the test, I was assigned the role of a Staff User.

During testing, I found features that I, as a Staff User, couldn’t access, and my boss was too busy to give me access or change what I wanted. As a red team operator, I tried to find my way into the system instead of asking or just waiting. This led me to find a Web Privilege Escalation Vulnerability.

Web Privilege Escalation

In the absence of controls to set permissions correctly on which users make changes in web software, a malicious agent can use these vectors to gain a greater access level and use this access to gain some advantage, like accessing other user accounts or content protected by access level. Sometimes, it is a complex test that requires fuzz testing in the inputs to discover the roles or elevate roles by layers. Other times, it is as simple as putting a query string parameter in the URL like this:

GET /system_configurations?isadmin=1

The Misassumption of Trusting the Client

Repeat after me: “Never trust client data.” This phrase is outspoken in the cybersecurity community and even heard during some developer best practices classes. An attacker’s main proxy for getting a foothold in a system is through some input the user can control.

Getting Yourself a Sensei Status in the Dojo

In DefectDojo, a Staff User can create and edit other user roles. However, apparently, it was intended that Staff Users could only create and edit normal users and other Staff Users,

never an omnipotent Superuser. At least, that’s what the interface leads you to believe.

The problem is that this validation was only enforced on the client side through the user navigation on the web browser (the client). The form for user creation/edit to the Staff User does not have a checkbox to set that a user is a Superuser. Still, the server accepts that a Staff User creates or edits the roles to escalate the privilege to or create a Superuser if the input is set directly on the request.

Exploit

As a Staff User, during the submission of a form in create user or edit user, in which the endpoint is POST /user/add or POST /user//edit, respectively, a user can set a field with the name is_superuser to make a change to set or unset and the user to have the Super User role during the creation or change of any user account.

So, even if the form does not show the checkbox so the average Bob does not click it on the browser, the server still accepts that this parameter is set, making it possible to escalate the privileges of a Staff User to a Superuser one.

This change could be made through a web proxy tool with tampering capabilities like Burp Suite or OWASP Zap Proxy or, even simpler, just using the Developer Tools in the browser. The point is that the request would seem something like this simplified HTTP POST representation:

It could be modified to look like this (pay attention to the is_superuser field):

In this way, a malicious agent with a Staff User role could edit itself to grant a Super User role and even lock the other users outside the application. The only thing that prevents the average Bob from taking advantage of this flaw is that the checkbox does not show in create/edit user form.

Impact

Becoming a Super User in the DefectDojo means you can access the Django Admin interface (through the /admin path). And it’s bad news if any user besides the intended Super User could access the System Settings. This way, a user could potentially access other

POST /user/add csrfmiddlewaretoken=<redacted>&username=
<redacted>&first_name=a&last_name=<redacted>&email=
<redacted>=&add_user=Edit+User&is_active=on&is_staff=on

POST /user/add csrfmiddlewaretoken=<redacted>&username=
<redacted>&first_name=a&last_name=<redacted>&email=
<redacted>=&add_user=Edit+User&is_active=on&is_staff=on&is_superuser=on

users’ data, change system-wide configurations to input other malicious data, control integration keys for API, and so on.

Mitigation

Thankfully, the issue was resolved in the same month it was reported, and we received a fast response from the team. So, by that time, it was a hotfix that later was tagged to release version 1.5.3.1. To keep safe from this vulnerability, update DefectDojo to the latest version.

It’s good to see that today, years after the discovery, the software has grown even more and improved its security maturity since the discovery years ago.

Timeline

Jan 09, 2019: Reported the vulnerability to the DefectDojo team. Jan 28, 2019: Pull Request Patch Merged to Master Branch
Feb 04, 2019: Security Advisory Published
Nov 09, 2023: CVE ID Requested.

Nov 16, 2023: Tried to contact the DefectDojo team to coordinate and review the vulnerability disclosure/PoC post.

Links

Pull Request Patch Merged to Master Branch Patch Commit
Security Advisory

References

Web App Privilege Escalation by 21y4d (Zeyad AlMadani) OWASP Guide 03 - Testing for Privilege Escalation