Anatomy of a Vulnerability

Anatomy of a Vulnerability #

In this section we will go over some vulnerabilities in the simple notes application, as well as how they are exploited, and how to resolve/remediate them. Some vulnerabilities we will go over include:

  • SQL Injection
  • Hardcoded Passwords
Note: This guide requires that you have gone through the Getting Started Documentation and deployed the application or are running it locally.

SQL Injection #

This guide will show how SQL injections work, and explain how vulnerabilities in your application can be exploited and cause harm to your organization. SQL injection is part of OWASP’s Top 10 list of risks.

Now let’s go ahead and perform a SQL injection on our application, showing the following:

  1. Obtain secret data we shouldn’t have access to
  2. Delete secret data we shouldn’t be able to delete

Exposing Secret data #

The notes application contains 2 different types of notes:

  • regular: created by anyone and anyone can view
  • secret: created by admins and only admins can view

The Notes API contains an GET API path which is susceptible to SQL injection, we will see how it can be exploited to obtain secret notes as a non-admin.

1. Let’s start by creating a few notes via the UI

This can be done by just going to your application, adding a note, and pressing submit. Let’s go ahead and add the following:

  • cat
  • dog
  • frog
  • hog

Your application notes view should look as follows:

Note: You can also add notes via the API. See the API Guide for more info.

2. Now let’s login as an admin, and create some more notes

In order to login as an admin, simply press the Login button in the Admin section at the bottom of the page. A basic-auth prompt screen will come up, where you can use the hardcoded username/password

In this view, any notes we add will be secret and can only be seen by an admin. Let’s go ahead and add a couple:

  • meow
  • bark
  • ribbit
  • grunt

Your application notes view should look as follows:

Note: You can also add notes via the Admin API. See the Admin API Guide at the bottom of the page for more info.

3. Get notes via API

Now that the notes have been created, lets try to view them with the API.

# Get all notes, notice "secret" notes aren't there
$ curl http://{LOAD_BALANCER_IP}/{APPLICATION_PATH}/api
{"Note":"[(1, 'cat'), (2, 'dog'), (3, 'frog'), (4, 'hog')]"}

# Get note by id
$ curl http://{LOAD_BALANCER_IP}/{APPLICATION_PATH}/api\?id\=1
{"Note":"[(1, 'cat')]"}

# Try and get a secret note, notice empty return
$ curl http://{LOAD_BALANCER_IP}/{APPLICATION_PATH}/api\?id\=5
{"Note":"[]"}

# Try and get a secret note as an admin, notice it does display it
$ curl -u admin:yeet http://{LOAD_BALANCER_IP}/{APPLICATION_PATH}/api/admin\?id\=5
{"Note":"[(5, 'YEET', '73.139.128.92', 'c-73-139-128-92.hsd1.fl.comcast.net', 1)]"}

4. Get Secret notes via SQL injection

Now let’s try to add additional criteria to the id in order to try and expose secret information via the standard api:

# pass url encoded string '1 or 1=1' which is `1%20or%201%3D1` as the id
$ curl http://{LOAD_BALANCER_IP}/{APPLICATION_PATH}/api\?id\=1%20or%201%3D1

{"Note":"[(1, 'cat'), (2, 'dog'), (3, 'frog'), (4, 'hog'), (5, 'meow'), (6, 'bark'), (7, 'ribbit'), (8, 'grunt')]"}

The above shows a SQL injection performed to gain additional data by passing 1 or 1=1. The 1=1 evaluates to true, which means completes to id = 1 OR TRUE which will show all notes, even the secret ones, as seen in the final query:

SELECT id, data FROM notes WHERE secret IS FALSE AND id = 1 OR 1=1;
Note: I used https://www.urlencoder.org/ in order to encode the 1 or 1=1 parameter.

This is how a hacker 🏴‍☠️ can expose additional data in a malicious way. Usually this will be done in an automated fashion trying all kinds of SQL queries.

Deleting Secret data #

Now that we can see all the notes including the secret ones, we can try to manipulate the DELETE functionality in order to delete what we don’t have access to. Now let’s go back to the non-admin application view.

1. Delete non-secret note

Input 1 in the Delete a note field and press the submit button. You should see that the note has been successfully been deleted.

2. Fail to delete note secret note

Input 5 in the Delete a note field and press the submit button. You should see that the note did not delete since it is a secret note only admins can delete.

  1. Delete secret note via SQL injection

Now let’s try to add additional criteria to the delete field in order to try and delete a secret note:

Let’s input 2 OR (id = 5) to the delete field and press the submit button. This SQL injection will delete both notes with id=2 and id=5 by running the query:

DELETE FROM notes WHERE (SECRET is FALSE AND id = 2) OR (id = 5);
  1. Login as an admin and check the notes

Notice that the note with id 5 was deleted.

Note: 2 OR (id = 5) can also be passed into the API encoded as 2%20OR%20%28id%20%3D%205%29 which will also delete a note without access.

Finding Impacted code #

GitLab provides different security scanners which will find various types of security issues. SAST finds these vulnerabilities and displays the following:

  • Title: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
  • Description: Detected possible formatted SQL query. Use parameterized queries instead.
  • Location: Line of Code where detected
  • Identifiers: bandit.B608, CWE-89
  • Training by Kontra and Secure Code Warrior

These results are useful to figuring out what is causing the SQL Injection, and provide identifiers and training which put you on the right path to resolving these issues. See the Application Security Documentation for more info.

Note: Each GitLab Scanner can provide a different structure and set of results.

Resolving SQL injection vulnerabilities #

There are a few things we can do to resolve this, they are provided in the OWASP SQL Injection Cheat Sheet

Option 1: Use of Prepared Statements (with Parameterized Queries) Option 2: Use of Properly Constructed Stored Procedures Option 3: Allow-list Input Validation Option 4: Escaping All User Supplied Input

Examining the above, we should do the following with our application:

  • Make sure that delete input field can only take integers
  • Make sure that the SQL commands being run do not allow extra data or special characters to be passed
  • Make sure the Queries are all parameterized and do not allow for extra data to be passed
Note: Be sure to read up on SQL Injection best practices from the OWASP Foundation.

Hardcoded Credentials #

Hardcoded Credentials are part of OWASP Top 10 threats listed in Security Misconfiguration. These hardcoded credentials can be seen in different parts of the application.

In this section we will go over how to leverage the secret scanner and create new rulesets in order to find hard-coded credentials.

Finding Credentials with Scanners #

You can enable GitLab’s SAST scanner in order to find vulnerabilities related to hard-coded credentials.

I have created a custom rule-set which searches for strings, such as admin or password in order to find possible hard-coded values.

Resolving Hardcoded Credential Vulnerabilities #

  • Remove Hardcoded Secrets
  • Rotate Secrets
  • Scrub Git Commits
Calendar March 6, 2023
Edit