Research The world runs on code. We secure it. Mon, 10 Jun 2024 10:22:46 +0000 en-US hourly 1 https://wordpress.org/?v=6.6.1 https://checkmarx.com/wp-content/uploads/2024/06/cropped-cx_favicon-32x32.webp Research 32 32 GitHub Repos Used for Distributing Malware https://checkmarx.com/blog/github-repos-used-for-distributing-malware/ Mon, 04 Mar 2024 17:48:58 +0000 https://checkmarx.com/?p=91446 Key Points
  • Widespread Malware Distribution on GitHub: Recent discoveries, including Apiiro’s report on over 100,000 infected GitHub repositories, highlight a growing trend of using GitHub for malicious purposes.
  • Diverse Attack Methods: GitHub-based cyber threats employ various sophisticated strategies, including attacks on legitimate repos, social engineering, and exploiting GitHub actions. This variety in attack vectors signifies the adaptability and ingenuity of cyber attackers in exploiting GitHub’s functionalities.
  • Critical Role of Continuous Monitoring in Cybersecurity: The evolving nature of threats on platforms like GitHub underscores the imperative for robust, continuous monitoring solutions.
  • Checkmarx’s Proactive Defense Against Supply Chain Cyber Threats: Checkmarx’s Supply Chain Security solution vigilantly monitors malicious activities, swiftly identifying and alerting on suspicious actions in the open source ecosystem to effectively counteract these cyber threats.

Malicious Repo Confusion Campaign

In light of a recent blog released by Apiiro, the cybersecurity landscape is yet again reminded of the innovative ways attackers exploit platforms like GitHub to host and spread malware. Apiiro’s findings reveal a large-scale malicious repo confusion campaign impacting over 100,000 GitHub repositories, shedding light on the evolving tactics of cybercriminals. Interestingly, part of the attackers’ strategy involved creating fake forks to make their repositories seem legitimate, a tactic we have discussed extensively in relation to repository spoofing.

The attacker took the following steps: they first cloned existing repos and infected them with malware loaders. Next, they uploaded them back to GitHub under identical names, automatically forking each one thousands of times. Finally, they covertly promoted them across the web via forums, discord, etc.

This is not an isolated case. The use of GitHub for malicious purposes has been a recurring theme, as evidenced by several incidents in the past.

Attacks on Legitimate Repos

A notable method of exploiting GitHub involves attacking legitimate repos. A prime example is an incident in mid-2023where attackers, leveraging stolen GitHub personal access tokens, impersonated Dependabot, a well-known dependency update helper tool. These tokens bypassed two-factor authentication, allowing malicious code to be committed under the guise of Dependabot. This code aimed to extract sensitive information and inject malware into JavaScript files.

Nation-State Social Engineering Using GitHub

Another tactic is the use of social engineering. In contrast to the scrutiny typically given to public open-source repositories, GitHub’s private repositories provide a more concealed avenue for attackers. A recent discoveryrevealed how North Korean state actors were using these malicious repos to then integrate into software through social engineering, targeting specific organizations or individuals.

Attacking GitHub Actions for Public Repos

In mid-2023, GitHub user account, pastramahodu, forked nearly 2,000 repositories, with 319,191 total stars combined, as part of a widespread bug bounty hunt attempt for finding misconfigurations in popular project’s CI pipelines. The procedure was most likely automated and created Pull Requests which in some projects triggered the project’s CI pipeline and executed the custom commands. This highlighted the increasing focus on pipeline security as an entry point for supply chain attacks.

Conclusion

The recurring theme across these examples is clear: GitHub, a platform integral to the development community, has become a focal point for cybercriminals looking to exploit the software supply chain. The sophistication and variety of these attacks demonstrate the evolving and persistent nature of these threats. As part of the Checkmarx Supply Chain Security solution, we continuously monitor and detect suspicious activities in the open-source software ecosystem, such as these. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. In the face of these sophisticated attacks, it is more important than ever for developers and organizations to stay alert, regularly review code sources, even from trusted platforms like GitHub, and implement robust security measures.

]]>
image-1-1 image-2-1
Checkmarx Research: A Race Condition in Kubernetes https://checkmarx.com/blog/checkmarx-research-race-condition-in-kubernetes/ Wed, 05 Feb 2020 07:20:46 +0000 https://www.checkmarx.com/?p=30414 Last year, the Checkmarx Security Research Team decided to investigate Kubernetes due to the growing usage of it worldwide. For those who are not too familiar with this technology, you can find more information at the official site here. Kubernetes is an open-source framework written in the Go language, originally designed and developed by Google to automate deployment, scaling, and management of containerized applications.
To understand what we discovered, it’s important to know some of the Kubernetes basics. Kubernetes’ purpose is to orchestrate a cluster of servers, named nodes, and each node is able to host Pods. Pods are processes, running on a node, that encapsulate an application. Keep in mind that an application can consist on a single or multiple containers. This allows Kubernetes to automatically increase resources as the applications require, by creating/deleting more Pods of the same application.
There will be a Master node and Worker nodes on a cluster. The Master node runs the kube-apiserver process that allows the Master to monitor and control the Workers. On the Workers side, the communication with the Master is done by the kubelet process, and the kube-proxy process reflects the networking services of the Pods, allowing users to interact with the applications. The following diagram illustrates the main components of Kubernetes and how they interact.

(source: https://en.wikipedia.org/wiki/Kubernetes)
To look for vulnerabilities in Kubernetes, we needed a lab environment with multiple servers. For this, it was decided to use virtual machines rather than physical ones, because they are much faster to configure every time there is the need to re-create the lab. To automate the lab creation and re-creation process, we used Terraform, Packer and Ansible. The vulnerability that we discovered in Kubernetes was uncovered by this automation process.
While creating the lab, we reused the Packer image without changing the hostname of the servers by mistake, and when we promoted the servers to Kubernetes cluster members, we realized that the cluster was unstable. The CPU load on the Master node was very high and eventually the cluster crashed!
We couldn’t understand what was causing this behavior. Although we had mistakenly configured servers in the cluster with the same hostname, this is a very likely situation in a DevOps process. There was also the attack vector, where a user with enough privileges in a Worker could lead the whole cluster to crash.
When listing the cluster nodes in the Master with the command kubectl get nodes, we only got one member and it was the original Master, although the other nodes were added to the cluster without errors.
After a reboot to the Master node, the cluster remained stable. When testing with two Workers with the same hostname and a different Master hostname, there was also instability in the cluster, and only the first Worker to be added to the cluster was shown in the output of the kubectl get nodes command.
Digging deeper, we were able to understand what was causing this instability. There is a race condition in the update of an etcd key. Etcd is used by the Kubernetes Master to store all cluster configuration and state data. The hostname of the cluster nodes is used to name a key in etcd, in the following format: /registry/minions/HOSTNAME – where HOSTNAME is the actual hostname of the node.
When two nodes share the same hostname, every time they communicate their state to the Master node, etcd updates the referred key. When checking the value of this key periodically, we proved the race condition, since the values of both nodes were shown randomly over time as shown in Figure 1.

Figure 1: Differences between two consecutive key updates
Besides the number of updates increase, on each update, several other keys (events) are also created and should be dispatched by Kubernetes components. This is what caused the cluster instability due to high CPU load on the Master node.
A video demonstrating the vulnerability can be found here. In addition to adding a Worker node with a hostname that already exists, it is also possible to exploit the vulnerability using the option –-hostname-override when adding a node to the cluster.
We validated this behavior against a public Kubernetes service provider, Azure Kubernetes Service (AKS), and we noticed that it adds a prefix to the hostname of the nodes. This behavior is enough to mitigate the described vulnerability.
Following our research, an issue was created in the official Kubernetes GitHub page, recommending two solutions to fix the vulnerability:

  • prevent nodes with a duplicate hostname or –hostname-override value to join the cluster
  • add a prefix/suffix to the etcd key name

Later, the Pull Request 81056 was created to address the vulnerability, following our first recommendation described above. The issue was fixed by rejecting a node joining the cluster if a node with the same name already exists #1711.
Discovering vulnerabilities like the one mentioned in this blog is why the Checkmarx Security Research team performs investigations. This type of research activity is part of our ongoing efforts to improve security for organizations worldwide.

]]>