Exploring the Chainjacking Attack

Several forms of supply chain attack have recently emerged that allow for attackers to insert themselves between developers and the dependencies they utilize. Many forms of attack resemble the classic phishing formula–anticipating human error and using misleading techniques to deploy malicious software.  We’ve seen typosquatting rise in popularity within the context of software dependencies as a means of waging a software supply chain attack. This form of typosquatting is an attack where an attacker mimics the name of an existing package on a public registry. Malicious actors do this hoping that users or developers will accidentally download the malicious package instead of the legitimate one; this is ultimately a form of package typosquatting. Similar attacks are rising in popularity, including a software supply chain attack that puts standard admin tools at risk: chainjacking.

What is chainjacking?

Developers often deploy software and packages to public registries for organizations, projects, and other developers to implement; attackers using chainjacking techniques will emulate typosquatting techniques. However, they use a legitimate former name of a package developer rather than a similar name.

How does a chainjacking attack occur?

To illustrate a chainjacking attack, let’s use an example scenario:
A developer named Leonidas has a GitHub account under the username “Leonidas.” They publish a valid Go package in a repository under “helpingHand.” Anyone who wants to use this package can either download and install it via “go get github.com/Leonidas/helpingHand,” or import it into their code via “import github.com/Leonidas/helpingHand.” A malicious version of this package also exists with the same name but under the username “iAmEvil.” We illustrate the example scenario below:

Pretty hard for a user to mix up these packages by the methods presented above, no? Well, let’s say some time passes, and Leonidas/helpingHand has grown in popularity. To reduce the amount of typing necessary for a developer, Leonidas decides to change their Github username to Leo:

Developers wishing to use this package may use either “github.com/Leonidas/helpingHand” or “github.com/Leo/helpingHand” for the request — redirecting all requests for “github.com/Leonidas/helpingHand” to “github.com/Leo/helpingHand.” However, the username Leonidas is now publicly available to be registered, allowing the malicious attacker to intercept requests from developers seeking the legitimate package. The attacker claims the Github username Leonidas: 

Since the malicious actor has published a package under helpingHand, claiming the username of the legitimate developer breaks the redirect to “github.com/Leo/helpingHand.” This action causes Github now to serve the attacker’s malicious package from “github.com/Leonidas/helpingHand.” This chainjacking attack could compromise any users who utilize the old URL; every new installation of this package could potentially afflict the installing developer’s machine.

This form of cybersquatting attack is not limited to Go repositories. Malicious developers may also deploy chainjacking attacks within iOS, macOS, or other platforms which use Swift or Objective-C. Such attacks can be waged through dependency managers such as Cocoapods. Let’s consider an example Podfile:

source 'https://github.com/Leonidas/helpingHand.git'

platform :ios, '11.0'
inhibit_all_warnings!

target 'HelpfulApp' do
  pod 'HelpingHand', '~> 1.1'
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    puts target.name
  end
end

In this example Podfile, the dependency “helpingHand” is imported from Leonidas’s Github repository, the legitimate developer. However, after Leo relinquishes the username Leonidas and this username is taken by the malicious developer, the chainjacking attack occurs the next time pod install is run by the developer. The act of running this command to download and install new pods results in the installation of a poisoned version of the dependency.

How to mitigate a chainjacking attack?

There are multiple best practices to ensure optimal security when using Github that developers should keep in mind. Github’s recently-introduced popular repository namespace retirement functionality thwarts some opportunities where chainjacking could occur. Github describes the functionality as follows:

“To prevent developers from pulling down potentially unsafe packages, we now retire the namespace of any open source project that had more than 100 clones in the week leading up to the owner’s account being renamed or deleted. Developers will still be able to sign up using the usernames of renamed or deleted accounts, but they will not be able to create repositories with the names of retired namespaces.” 

However, this leaves a significant opportunity for malicious actors to leverage a chainjacking attack. We recommend several measures to help mitigate the risk of a successful chainjacking attack on your organization. First and foremost, ensure code is signed in development and validated in build and production environments to prevent tampering. Requiring digital signatures is an effective method of providing both data integrity and authentication. Though incapable of verifying authentication, requiring checksums is beneficial for ensuring data integrity.

To enable signing for all commits, developers may use the following command:

git config --global commit.gpgsign true

More information on implementing code signing as a means of verifying a committer may be found in this article. This process may be done if the GPG command-line utility is installed.

More broadly speaking, enforcing secure development best practices help prevent more than just chainjacking attacks. These practices include:

• Have commit signing as a mandatory configuration.
• Enable static code scanning and open source scanning across your repositories.
• Before any software is updated, run the changes through a code checking review and signing process by another party; this can guard against unintentional oversights and insider threats.

How Cycode can help

Cycode secures DevOps pipelines and provides full visibility into enterprise development infrastructure. Powered by its knowledge graph, Cycode’s advanced detection capabilities correlate event data and user activity across the SDLC to create contextual insights and automate remediation. Cycode delivers security, governance, and pipeline integrity without disrupting developers’ velocity. The capabilities of Cycode allow for conformance to industry outlined best practices, such as those provided by NIST or Google. Cycode solves the following use cases:

• Centralizing governance and security policies across the SDLC
• Reducing code tampering risks 
• Preventing hardcoded secrets
• Detecting source code leakage
• Securing infrastructure-as-code

Cycode helps establish strong governance over every point of the IaC lifecycle by providing a cross-SCM inventory of your organization’s users, contributors, teams, organizations, and repositories; this governance extends into providing more oversight into changes made to code as a means of further protecting key code. Cycode also helps you automatically audit access privileges to identify and reduce excessive, unused privileges, and implement separation of duties. Furthermore, Cycode helps ensure that strong authentication and secure development practices are in place, which helps apply security best practices for IaC code when using Terraform, Kubernetes, YAML, ARM, and CloudFormation.

Want To Learn More?

A great place to start is with a free assessment of the security of your DevOps pipeline.