Our Greatest Vulnerability For the Internet? A Large Scale Compromise of Git Hub Code!

If you wanted to open-up the security of the Internet. Where would you start? Discover a zero-day vulnerability? Scan the Internet for…

Our Greatest Vulnerability For the Internet? A Large Scale Compromise of Git Hub Code!

Our new world is not being built by governments, it is being built in GitHub

If you wanted to open-up the security of the Internet, where would you start? Discover a zero-day vulnerability? Scan the Internet for known vulnerabilities? Well, probably the easiest way is to high-jack a well used Git Hub repository and insert a back door. Then, if unnoticed, your back-door code will be pushed out to every user who uses the code. If it’s a small code responsibility, too, then no-one might notice that you had changed the code.

In our traditional models of software, such as with C++, C# and Java, we sign code with encryption keys, and then check the validity of the code we are integrating with. When we call our modules, we check their signature and know that we can trust the code. But what we are really checking is that the creator of the code has checked it, and signed it with their private key.

In a world with JavaScript, Python and Ruby, this type of checking does not quite happen, and a good deal relies on the owners of Git Hubs to make sure their code is clean. Along with this, the distributors of the software, such as through NPM (‘npm install’) and PyPI (‘pip install’), need to be checking the distributions so that back doors are not introduced within dependencies.

Overall, we have loosened our controls on software to make things easier, but it my come back to haunt us.

Introduction

The world of software is moving quickly towards easy-to-use environments such as Python and JavaScript. For them, there are convenient ways to grab libraries and are languages that grew-up in a Linux world of command lines and pulling code from repositories. For a developer, a “pip install” or running the Node Package Manager (NPM) is just so simple.

Our software world too is opening up with open source code used increasingly to build applications, and these will provide the core of our software security. And problems in these could cause major problems, and lead to large-scale vulnerabilities.

What happens when an insider on a Git Hub turns to the dark side and adds-in a back-door into the code, and which is then rolled-out to all users?

Bitcoin stealing

While JavaScript was often used as a front-end language, with Node.js is it now a core part of many systems, and is often used in Blockchain/Cryptography related applications. And so this week it was discovered that an NPM repository had been modified in order to steal cryptocurrency. The library is event-stream, and is an extremely popular piece of code with around two million downloads per week.

The vulnerability was flagged on 20th November 2018 by Ayrton Sparling from California State University, Fullerton. He found malicious code which tried to steal from a Dash Copay Bitcoin wallet within the flatmap-stream library, and which was distributed from NPM.

It all started on 5 September 2018 when a developer named “right9control” opted to take over the event-steam code and fork it:

The EventStream library aims to make the integration of event streams easier to work with. With this we see objects coming through a stream and defined in a timeline. On 16 September, new code was added with a flat-stream dependency:

Then, on 5 October, the flat-stream code was updated by “hugeglass” in order to include code which extracted Bitcoins from a user’s wallet:

The payload for the malicious code was encrypted, but Jacob Burroughs managed to find the encryption key used.

Conclusions

Developers must thus take care in the complete integration of their code, and make sure they audit both their own code and the code of others. If you run a Git Hub, watch out for those who are editing it, and make sure they are adding trustworthy code.

Along with NPM, we must also make sure that Python’s PyPI and Ruby’s RubyGems are secure from compromise. It is likely that this vulnerability will lead to increased security, and which make take away from some of the freedom that developers enjoy through Git Hub distributions. Luckily there is a good deal of top quality testers around the world, and who can spot bad code.

We have been lucky with this vulnerability, but we might not be so lucky the next time. Should we now look at proper code signing, and have a whitelist of trusted developers that companies would trust? If they identified that new code has been updated by another developer, it would flag-up on their system.

One must worry, too, that we are building large applications which use many small inter-dependencies. Developers perhaps should focus on integrating larger libraries into their code, in order that they can be properly audited.

Postscript

If you are interested, here are some of my Node.js crypto examples:

  • ECDSA with node.js. ECDSA. ECDSA with node.js.
  • EdDSA with node.js. EdDSA. EdDSA with node.js.
  • JSON Web Signatures and JSON Web Tokens. Web Tokens. JSON Web Tokens with node.js.
  • Symmetric encryption with node.js. Crypto. AES with node.js.
  • Hashing with node.js. Hashing. Hashing with node.js.
  • Diffie-Hellman with node.js. DH. DH with node.js.
  • Diffie-Hellman with node.js (random prime). DH. DH with node.js (random prime).
  • ECDH with node.js. ECDH. ECDH with node.js.
  • Ethereum with node.js. Ethereum. Ethereum with node.js.
  • FPE with node.js. FPR. FPE with node.js.
  • Puny with node.js. Puny. Puny character format with node.js.
  • Merkle Tree with node.js. Merkle. Merkle Tree with node.js.