There’s a terrible attack happening against Github right now where attackers are forking legitimate repositories and injecting malware – and then hoping unsuspecting users will download code from the attacker’s repo instead of the original. A researcher estimates this is happening to about 100,000 repos on Github.

As Dan Goodin writes at Ars Technica:

The malicious repositories are clones of legitimate ones, making them hard to distinguish to the casual eye. An unknown party has automated a process that forks legitimate repositories, meaning the source code is copied so developers can use it in an independent project that builds on the original one. The result is millions of forks with names identical to the original one that add a payload that’s wrapped under seven layers of obfuscation. To make matters worse, some people, unaware of the malice of these imitators, are forking the forks, which adds to the flood.

His article continues in great detail about how the attack works and the dangers involved. He also notes how Github is fighting back against this and removing malware repos … but the scale of the attack makes this hard.

A key point to me is that you should only download and execute code from repositories you trust.

This is kind of a 🤦‍♂️ statement, but it’s so easy to just search for code, find a repo, and use the code.

We all need to take the extra moment and figure out: is this repo a fork of another repo? And if so… why? There are perfectly legitimate reasons to fork a repo. Perhaps someone wants to improve the code or offer a new feature in a way the original developer didn’t want to.

But, as this attack shows, there are also malicious reasons for forking a repo.

We need to be sure we trust the source – which may mean doing the detective work to trace back and see if this is the original repo.

I wish the folks at Github all the best in combatting this attack. The ability to easily fork repos is such a key part of Github and the collaborative development of code. It’s unfortunate that it is being abused in this way. 🙁

Can you trust Secure Shell (SSH) when you are behind certain firewalls? That’s the question raised by a post from a friend of mine:

Lies, Damn Lies, and Inspecting SSH Traffic Securely

It seems that because ssh can be used for tunneling services and application traffic several firewall vendors are now implementing “SSH inspection” services that essentially perform a Man-in-The-Middle (MITM) attack on your ssh connection.

When you go to ssh into a server, the firewall pretends it is that server and creates a ssh tunnel with you. The firewall then creates the actual ssh connection to the server and passes your packets from the first tunnel into the second tunnel – while being able to log or inspect the packets in between the two tunnels.

Now, of course with ssh you go through an initial handshake when you first connect to a server that results in the server’s public key being added to your list of known hosts.

If you connect to a server for the first time BEFORE being behind one of these firewalls doing SSH inspection, you would already have the correct public key of the server in your known hosts file. What would happen when the firewall tried to do a MITM is that you would be asked to approve the public key of the server again. (Because you are actually now approving the public key of the firewall.)

You would have to realize that this was wrong and stop your connection!

If you proceeded ahead with the connection and approving the public key, you would now have the firewall as a MITM.

If you connect to a server for the first time AFTER being behind one of these firewalls, well… I’m not sure what you can do. You’re going to see a public key to approve, but it would be from the firewall! You’d have to somehow learn the correct public key of the target server to be able to match it to the fingerprint you are being shown.

I don’t know how well that will work.

The good news for me personally is that I’m not behind these kind of firewalls in my regular networks – although I don’t honestly know what my Internet service providers are using. They could be doing these kind of things.

I don’t consider this a good thing that firewalls are now doing this. We need to trust the security of services like SSH. This decreases overall trust.

Photo credit: El Taller del Bit on Flickr