How GOSH Can Help
Why yesterday's massive cyberattack could not have been carried out on GOSH
We woke up on Wednesday, August 3rd to the news of another major hack perpetrated against the users of a number of major blockchain networks. Just as we were finishing up our breakfast, we caught wind that dozens of thousands of GitHub repositories were affected by a malware attack.
Unfortunately, events like these are becoming ever more common. However, this need not be the case. Why? The short answer: The GOSH Docker Extension; a tool purpose built to Secure the Software Supply chain. For the long answer we offer this post; a specific explanation of how the attack that occurred over the last 24 hours could not happen on GOSH.
Cloning repositories is perfectly ok. Cloning them, then adding malicious code to pretend the clone is the original repository isn’t. Picture the scene: a scammer tricks users into installing clones instead of the original repositories and then executes something like:
The result? As you can read here: this single-line instruction, pictured above, further allows remote attackers to execute arbitrary code on the systems of all those who install and run these malicious clones.
Users are then tricked again, this time into installing the packages or compiling from repositories which have very similar names and look just as legitimate as the originals, because they contain all the cloned history, linking back to the original repository’s developer commits.
Sound familiar? It’s because it happened.
Another type of the attack was carried out by submitting a pull request to some known repository with an innocent looking commit like version bump:
Developers are lazy just like everyone else. They love automation. And if such automation does not exist it goes to reason that it will probably not work. And as we have just witnessed — it doesn’t. Lots of the time developer’s signatures are not verified and the code itself is not meticulously reviewed.
It’s called a “LGTM”. Looks good to me → “Merge”.
Some of us have thousands of these in our mailboxes.
GOSH changes all that.
Container Verification
One of the more basic ways GOSH repositories are protected against the attack is through a Decentralized Name Service (DeNS). It is a fast and secure tool to name artifacts in the blockchain in a serverless way. Therefore, when a user is looking for a repository on GOSH, provided they write the name correctly, they can be sure they will see the correct repository. This is because GOSH is a content addressable blockchain. An attacker has absolutely no way to circumvent this link, and no DeNS attack is possible, because there are no servers involved in name resolving. Easy checks can be created within CI/CD or any other Gosh automation scripts (more on that below), moreover the search can be built with security features, such as decentralized developer certification (think NFT) verification.
Likewise, using GOSH means you can easily build an automated check that the repository you build from is a repository from GOSH. The GOSH Docker Extension signs code from commit up to the container image by default. This is one of the advantages of storing git on the blockchain. It is impossible to interject into this flow any other third party code, build, or script.
Signatures
There is one major difference between the worlds of centralized and decentralized cryptography: the latter is built specifically so that developers don’t need to trust anyone to carry out any operation, commit, transaction, or centralized keys’ certificates verification.
On GOSH every commit is signed by a private key. This allows developers to verify the identity of each contributor on any repository in a completely trustless fashion. Developers can verify that they are not building from any repository other than the repository they trust. It is clear whether a repository is cloned or the original, meaning attacks through false attribution won’t work.
Decentralized Autonomous Organizations (DAOs)
A major part of how this last attack was perpetrated is through social engineering. How many times do we accept PRs which we don’t fully understand? Many very routine aspects of code are often left unchecked. However, on GOSH repositories are DAOs. This means repositories do not have a single owner; there are many reviewers of any commit; and that, for a commit to be accepted, the contributors of the repository vote.
Humans make mistakes, but every additional pair of eyes exponentially reduces the vulnerability of code. DAO governance forces at least some members to always participate. And if any member doesn’t understand or doesn’t agree with a change, they can vote against it.
The DAO voting process means third parties that don’t belong to an organization cannot exploit many of the loopholes open today. GOSH doesn’t just secure delivery of code through technical means but also through means of governance.
CI/CD
GOSH allows developers to automate their CI/CD pipeline security. Instead of building conventional install scripts (like Package.json or cargo.toml), developers on GOSH can write Smart Contracts that are also Turing Complete but have an advantage of being Formally Verified, executed by the network consensus, and therefore, immutable.
With the push of a button, repository contributors can Formally Verify their Smart Contracts. This is thanks to the amazing work of GOSH partner Pruvendo. All of the above allows developers to rest easy in the knowledge that there are no bugs anywhere in their software supply chain.
GOSH is the first ever platform to verify the correctness not only of code, but of the whole Software Supply Chain.
To conclude, we hope we have argued clearly why the attacks of August 3rd, 2022 could not have happened, or
would, at least, have been near impossible to carry out on code stored on GOSH.
Security of code always starts at the source. That’s what the GOSH Docker Extension is purpose-built to protect. You too can try it now.
For further news and updates: