Millions of program builds vulnerable to Man-in-the-Middle attacks

By: Ming on January 16, 2017

According to a blog post made on 18f, it is a standard to ensure all federal websites and web services to serve only via secured connections (HTTPS). Yet in its recent study, about 6.1% of the domains do not have HTTPS enabled. Package managers have, in the past, deprecate certain commands/features that defaults to HTTP. RubyGems has deprecated source :rubygems in Gemfile due to the insecurity of HTTP, and recommends the explicit use of HTTPS.

In this post, we will highlight the issues of insecure network connection(s) made by open-source libraries during build time. Also, we introduce an open-source monitoring tool, Build Inspector, that can be used to detect insecure network traffic made during the build process. Finally, we analyze the number of affected builds from a sample pool of open-source repositories.

The Issue

Insecure network connection could be intercepted without the victim knowing of the existence of the attacker. Today, there has been several Proof-of-Concepts (PoC) tools, as well as frameworks, that easily enables MitM attacks to be executed. The following are some common ways that leaves developers vulnerable to MitM:

  • Using an outdated version of the Package Manager
  • Specifying to use HTTP in the Package Manager’s dependency file
  • Having one or more dependencies which makes an insecure network connection

Build inspector

Build Inspector is an open-source forensic sandbox) that can be used to monitor various changes such as processes, file changes, as well as network activity. In this section, Build Inspector was extended to detect insecure network activity.

Detecting insecure network connections made by a build is a simple two step process. First, we require the evidence collected by Build Inspector. Next, we run Build Inspector again by specifying the script used to analyze the evidence, and finally getting the results.

Below outlines the process to run Build Inspector on a sample repository, test-repos/ann-pee-am, to detect insecure network connections.

Setup: We include a dependency, slug, in our package.json

  "dependencies": {
    "slug": "0.9.1"

Step 1: We run Build Inspector on this repository, specifying that it is an npm build.

./inspector --npm test-repos/ann-pee-am
****************************** [:] ******************************
* Build Inspector - SRC:CLR -      *
* Security for open-source code.                   *
****************************** [:] ******************************

==> inspector: Bringing machine 'default' up with 'virtualbox' provider...
==> inspector: ann-pee-am@1.0.0 /home/vagrant/repo
==> inspector: └─┬ slug@0.9.1
==> inspector:   └─┬ unicode@0.6.1
==> inspector:     └─┬ bufferstream@0.6.2
==> inspector:       ├── bufferjs@3.0.1
==> inspector:       └── buffertools@2.1.4
==> inspector:
==> inspector: npm WARN ann-pee-am@1.0.0 No repository field.
==> inspector: npm WARN ann-pee-am@1.0.0 No license field.
==> inspector: Done. Your build exited with 0.
Stopping network monitoring ...
Generating file system changes ...
Collecting evidence ...
Rolling back virtual machine state ...
Filtered commands executed:
Hosts contacted: (                                         14.9K (                                         28.1K
File system changes:
[:] Build inspector finished after 138.228244 seconds

Step 2: We run the insecure network connection script against the collected evidence.

./inspector --npm --script=insecure_network_finder
Processing evidence at with script at insecure_network_finder
****************************** [:] ******************************
* Build Inspector - SRC:CLR -      *
* Security for open-source code.                   *
****************************** [:] ******************************

Results: TRUE
[:] Build inspector finished after 1.408074 seconds

From the results above, slug (0.9.1) is tested positive for making insecure network connections during its build process. However upon analysis, slug is not directly responsible for making the insecure network connection. Instead, its transitive dependency, unicode, downloads resources over HTTP, leaving the process vulnerable to Man-in-the-Middle attacks.

Sample Content from GitHub

To further understand how common this issue is today, we ran a script to parse dependency files of various Package Managers from a pool of sample content from GitHub. The script which we ran found 1180 affected libraries, and we have verified that most of them are vulnerable open-source repositories affected by the same Man-in-the-Middle vulnerability as they were either directly downloading various resources via insecure network connections, or through the issue arises from one or more transitive dependencies.

Final Words

Issues like these can be easily mitigated by being aware of its existence, and resolving it by switching out the insecure network protocol to a secured protocol like HTTPS. To be additionally safe, the validity of the certificate can be verified, and the file’s checksum should be verified.

However, it is unlikely for a developer to pick up issues like the one described in this post as issues created by transitive dependencies are often non obvious. On the other hand, transitive issues like these are easily picked up and reported by the SourceClear agent.

In other words, if you are a SourceClear customer, you are already protected.

Blog Home