How does PyPI eliminate ‘mitmproxy2’ over Code Execution Concerns?

The PyPI repository has removed a Python package called ‘mitmproxy2’ that was an identical copy of the official “mitmproxy” library, but with “artificially introduced” code execution vulnerability. The form ‘mitmproxy’ Python library is a free and open-source interactive HTTPS proxy with over 40,000 weekly downloads.

Copycat Package could mislead devs into Falling for ‘advance’ versions

Previously, Maximilian Hils, who is one of the developers behind the ‘mitmproxy’ Python library, drew everyone’s attention towards a counterfeit ‘mitmproxy2’ package uploaded to PyPI. ‘mitmproxy2’ is necessary “the same as regular mitmproxy but with an artificial RCE vulnerability included.”

How-PyPI-eliminate-‘mitmproxy2’-over-Code-Execution-Concerns-image1

Hils’ main concern as he explained to our experts, was that some software developers might mistake ‘mitmproxy2’ as an advanced version” of ‘mitmproxy’ and inadvertently introduced insecure code in their applications.

Hils discovers this copycat package in what he calls a “happy little accident” while seeking into an unrelated PyPI warehouse concern.

How-PyPI-eliminate-‘mitmproxy2’-over-Code-Execution-Concerns-image2

On examining the differences between ‘mitmproxy2’ and his ‘mitmproxy,’ something important stood out. The former had all the safeguards removed from the API:       

“When you run mitmproxy’s web interface, we expose an HTTP API for that. If you remove all safeguards from that API, everyone on the same network can execute code on your machine with a single HTTP request,” Hils told our experts.

How-PyPI-eliminate-‘mitmproxy2’-over-Code-Execution-Concerns-image3

It isn’t clear either if the user who published the copycat ‘mitmproxy2’ package did so with willful malicious intent or just out of insecure coding practices.

“To be clear, this really isn’t the most malicious thing an attacker could do. It would be much more straightforward to just add some malicious code that gets executed on install right away.”

“The problem is of course if you upload that to PyPI as ‘mitmproxy2’ with a version number that indicates it’s newer/a successor, people will inevitably download that not knowing about the changes.”

Hils thanked PyPI volunteers for swiftly reacting to this report. Within four hours of Hils’ tweet, ‘mitmproxy2’ was taken down.

Whack-a-mole: another Copycat Comes an hours later

While analyzing ‘mitmproxy2’, our experts discovered another package ‘mitmproxy-iframe’ had appeared on the PyPI registry, less than a day after ‘mitmproxy2’ was removed.

Once again, this package is a replica of the official mitmproxy, but with the aforementioned safeguards removed from the “app.py” file, as seen by our experts.

Interestingly, mitmproxy-iframe is also published by the same user, who is behind ‘mitmproxy2’, nowcasting doubts on what the user’s intentions are:

How-PyPI-eliminate-‘mitmproxy2’-over-Code-Execution-Concerns-image3

Because anyone can publish packages to open-source ecosystems, security threats and attacks like malware injection, typosquatting, brandjacking, and dependency confusion have increased rapidly in recent times.

Unless concrete validations are put in place by open-source registries, these “whack-a-mole” situations are bound to repeat themselves. Our experts alerted PyPI of the ‘mitmproxy-iframe’ package before publishing and the package was taken down.

Leave a Reply