Dangerous Connections: How criminals hack IT products via GitHub

[Father]

In this new article, read expert advice on protecting against cyber attacks through third-party code repositories.

At the end of 2023, an article titled "One Attack on the Supply Chain to rule everyone" appeared on the Internet, which described a way to gain access to the GitHub repository infrastructure. It turned out that the logic of one of the most popular resources for developers allows you to bypass the restriction on project management by literally putting a single comma. According to the author, with whom many commenters agreed, the bug compromised the security of literally every product whose code base is stored on GitHub.

This is not the first such story. In September, it became known about the critical vulnerability of GitHub, which could affect more than 4,000 projects. Previously, malicious repositories were reported that stole other people's data, opened hidden access to the system, etc. Experts agree that attacks through GitHub will only grow.

We discussed with experts the most common scenarios of attacks on code repositories and ways to protect against such threats. It turned out that different experts look at this topic differently, which once again proves that the security of the code base is a complex problem, and there is no single, suitable solution for it yet.

What attacks are carried out through the GitHub infrastructure​

According to our interlocutors, inaccurate use of GitHub threatens companies with literally all possible troubles: from data leaks to lawsuits for copyright violations. The reason is that compromising the repository often gives criminals carte blanche for destructive actions.

Anton Basharin
Technical Director of Swordfish Security

If you list all the vulnerabilities, it will take a very long time, since any vulnerability, starting from XSS (cross site scripting) and ending with RCE (remote code execution), can cause serious damage. Banal repainting of the logo in the colors of the Ukrainian flag can bring more negativity these days than stealing confidential information.

Furkat Rakhmonov
iTPROTECT Information Security Engineer

The most dangerous attacks from the point of view of destructive impact on business processes are those that cause disruption of the service or application, data leakage, damage to the company's reputation, or use the company's capacity for distributed computing (for example, mining).

At the same time, the examples of attacks that occur in real practice are quite limited from the point of view of technology. As a rule, we are talking about intercepting control over the repository (repojacking), introducing malicious bookmarks and backdoors into legitimate software, and replacing libraries and open-source components used in the product.

Cyber Media's interlocutors gave different assessments of the malicious potential of these attacks, so we suggest that readers make their own conclusions about how dangerous certain scenarios are in their case.

Taking control of the software repository (repojacking)​

It is not difficult to assess the consequences if an attacker can break into the repository owner's account. In fact, we are talking about a complete loss of control over the IT product.

The most common example of this scenario is redirection vulnerabilities for renamed GitHub repositories. When the repository owner changes the repository name or user name, the service creates a new URL for its repository. Usually, GitHub automatically redirects links to a new URL so that the software that uses the renamed project continues to function.

However, if an attacker manages to restore the old repository URL, for example, by re-registering a user with the same name as the repository owner, redirection no longer works. Links to the old URL become working again, and an attacker can remotely inject malicious code into any software associated with the project.

Anton Basharin
Technical Director of Swordfish Security

This is an extremely rare attack that has never been seen among our clients. In the last 2 years, most of our customers have stopped using repositories, and more often they make a copy and maintain it themselves — in fact, they create a clone (fork) of the repository from github. There are both advantages (there is almost no chance to integrate with malware and other things), and disadvantages (bugfix or component development must be done independently).

Andrey Zhukov
Leading specialist in analyzing the security of the USSB

A relatively new topic that is inherent in the GitHub site. Its operation requires special conditions, which are not always feasible. For example, the developer whose code you use should change their name, have less than 100 likes, and so on.
But in general, the moment is quite insidious and it is quite difficult to protect yourself from this vulnerability. Companies need to be careful if they don't want to lose control of the repository after rebranding on GitHub. It should describe the development processes using the site, the processes of creating a new repository, the life cycle of the old one,and the responsible persons.

Grigory Kononenko
Head of Technical Department at ARinteg

This is a dangerous thing, especially if the interception is implicit. Not only do attackers have access to private (confidential) projects, but the risk of introducing parasitic components also increases.

Injecting malicious code​

This scenario partly continues the previous one: by taking control of the repository, a criminal can create hidden functions (bookmarks) in the product, turning legitimate software into malicious software. In this way, an IT product becomes a means of data theft without the owner's knowledge, a tool for attacking a company's partners-users of its product, ordinary users, and anyone who works with a compromised system.

Anton Basharin
Technical Director of Swordfish Security

This is the most common attack. In fact, for the sake of introducing bookmarks, everything is being started. It is no longer possible to launch a head-on attack on the systems of large companies, so attackers are looking for weaknesses that they find in open source components.

Andrey Zhukov
Leading specialist in analyzing the security of the USSB

Here, I would call supply chain attacks the most likely and popular scenario — when an attacker inserts malicious code into software components. A fairly large-scale cyber attack is hacking companies through a product from SolarWinds. Criminals gained access to all users — large US companies, including government organizations.

Grigory Kononenko
Head of Technical Department at ARinteg

If the company has the right development cycle and conducts a systematic code analysis, then the symptoms of such a scenario will be very pronounced, and modern technologies allow you to automatically identify such vulnerabilities in 90% of cases. This scenario is the last thing to worry about.

Furkat Rakhmonov
iTPROTECT Information Security Engineer

Do not forget that everything also depends on the programming language. For example, if you use Flask, the login/password from the superadmin can be embedded. To protect yourself from such vulnerabilities, you need to analyze the source code, as well as build dependency management processes. You should not even trust your contractor organization, all new software needs to be tested.

Substitution of libraries and open-source components​

Experts have been talking about the risks of open source for a very long time. Back in 2018, it was reported that companies continue to increasingly use open-source modules with known vulnerabilities. At the same time, exploits to such components appear literally within days after the appearance of the PoC.

Andrey Zhukov
Leading specialist in analyzing the security of the USSB

Today's popular programming languages have grown into tens or hundreds of thousands of independent libraries, creating a convenient ecosystem for code reuse. In more or less complex projects, the number of such dependencies can reach hundreds of components. Some components will recursively pull their dependencies. As a result, we have a difficult to control ecosystem of libraries, in which it is quite possible to find untested code in a large and serious project.

Grigory Kononenko
Head of Technical Department at ARinteg

This is a really serious problem, examples of the consequences of which can be increasingly observed in the public field. But again, there are rules for the development cycle that allow you to avoid the consequences, or even the likelihood of such a scenario.

Fixing versioning, caching the component database on an intermediate repository, and legalizing used components in your code base... And this is only the human factor, if you also attach automated control tools to this, then the scenario becomes generally implausible. If the company is serious about development, the probability of such a scenario will be very low.

Anton Basharin
Technical Director of Swordfish Security

It occurs, but it is extremely rare, because the substitution is easily recognized by the signature or checksum. It has long been used to sign distributions with a developer's certificate, which helps protect against spoofing. In a similar way, using the cosign approach, they already make signatures for Docker images.

Deterioration of IT products due to publicly available low-quality components​

Problems in open source code can also occur accidentally. Anyone can update the open-source module, and such commits are reviewed on a case-by-case basis. As a result, bugs, vulnerabilities, or simply inefficient pieces of code end up in third-party IT products, become overgrown with dependencies, and it becomes increasingly difficult to fix the situation.

Anton Basharin
Technical Director of Swordfish Security

This is a problem, but only where DevSecOps, the process that controls such components, is not debugged. On the other hand, there are a lot of components on the Internet where problems are found, but they are not fixed, and developers continue to apply them. Often, there are no alternative solutions, so you either have to accept the risk, or cover the vulnerable method with checks that reduce or completely eliminate the possibility of exploiting the vulnerability.

Andrey Zhukov
Leading specialist in analyzing the security of the USSB

You can note possible problems with licensing when updating the software, or the lack of developer obligations to support the software.

We would recommend evaluating the extent to which the use of open source solutions in the IT infrastructure is really necessary. If there are similar commercial products developed by Russian developers, we recommend using domestic solutions. Otherwise, we recommend developing and regularly updating the list of compensatory measures, using auditing, and building an information security incident management process.

Grigory Kononenko
Head of Technical Department at ARinteg

If the company's motto is "It works, but never mind", then code quality is the last thing to worry about. You can run into improper use of a licensed component and get into heavy fines, you can fill your code with unused functions, you can provide yourself with a car and a small cart of holes by inheritance... This scenario is worth thinking about, but everything is solved by simple rules of accreditation of the code used.

How to protect yourself from attacks on code repositories​

It is noteworthy that the main reason for problems with development processes Cyber Media interlocutors often call the actual low-quality processes. Code checks manually and automatically, implementation of DevSecOps approaches, responsible attitude to product releases — according to experts, these measures remove a significant part of the risks.

Andrey Zhukov
Leading specialist in analyzing the security of the USSB

In 2022, there were many more such repositories, and then absolutely anyone could get "under distribution".

If you are a developer, then you should implement safe code development practices in your processes — static, dynamic code analysis, fuzz testing, testing of third-party and open source components.

If you are a commercial company, we recommend that you make sure that the software is checked for compliance with security requirements when choosing it. If this cannot be confirmed, then conduct acceptance tests in an isolated circuit, taking into account all possible information security risks.

Furkat Rakhmonov
iTPROTECT Information Security Engineer

You should hire an experienced developer, preferably several, and conduct periodic testing with the DevSecOps team, for example, testing the "white box" (Static Application Security Testing), and "black box" (Dynamic Application Security Testing).

Andrey Yefimov
Engineer of the Information Security Department of IMBA IT

To mitigate the risks associated with these vulnerabilities, it is necessary to regularly analyze the third-party dependencies used for vulnerabilities, act in accordance with license requirements, and take measures to ensure the reliability and security of third-party code sources.

Using containerization and virtualization to isolate modules can reduce the risks associated with deterioration of IT products due to the use of these components.

At the same time, when asked which repository is currently considered the most secure, most experts answer: no, everyone has vulnerabilities. Therefore, you should choose a repository based on the community criteria: the more developers use the repository, the more likely they are to find unsafe modules.

You can also make sure that your repository complies with industry security standards: OWASP, ISO 27001, and NIST. Finally, if a company has the ability to create its own platform without external access, this option will be the safest, although expensive.