A supply chain can be easily identified as a sequence of steps that may be handled by multiple vendors which bring a product from raw materials to it final form. An example can be a SDLC where developers use some third party libraries to convert a particular data set into a different form, or just use it to convert some data structure to another. This involvement of the third party library is hence a step in creation of the final product. The library it self could also be using another third party library to perform a function. The developers trust the library to do its function properly since it has been doing so for years maybe. This is an example of how the flow works in some application.
The Dictionary definition of a supply chain attack is as follows:
A supply chain attack is a cyberattack that targets the weakest link in a network by compromising a trusted third-party supplier or service provider. It involves infiltrating a target organization by exploiting vulnerabilities in the supply chain, which can include software, hardware, or services. In Simpler Terms, its an attack on a dependency( usually identified as the weakest link) in the supply chain which can affect the proceeding steps and/or the end user. The effect of compromise of An intermediary can affect all the downstream intermediaries and/or end users depending on the target of the attacker.
This attack works so well due to the fact that one link(consumer) usually places a lot of trust in what it is receiving from the previous link(supplier) and often does not run integrity and security checks on that data. This is especially the case when the vendor who is acting as the supplier is offering a proprietary service. In a situation where an application is fetching some data from a paid API, often times, the developers tend to not sanitise that data before putting it in the works. This poses a huge issue since if even one link in the supply chain is compromised, its effects are visible in all the links downstream. In fact, a lot of times, this attack is used to gain access to a subsystem from where adversaries move laterally as was the case of Target and its HVAC vendor who was placed in their internal network which itself had no additional security in place. This attack is more often than not, surprising to the victims since they are not expecting a breach from inside a process that they set up themselves.
Imagine a popular pizza restaurant that prides itself on using the finest ingredients. To ensure the highest quality, they rely on a trusted cheese supplier who provides them with premium cheese for their pizzas. This cheese supplier is like a critical link in the restaurant's supply chain. Now, let's draw parallels to a supply chain attack:
Identification of Target: In this analogy, the target is the pizza restaurant known for its high-quality pizzas.
Research and Reconnaissance: The attacker (in this case, a devious competitor or a malicious individual) carefully observes the restaurant's supply chain, identifying the cheese supplier as a potential weak point.
Targeting a Supplier: The attacker decides to focus on compromising the cheese supplier, understanding that this could have a significant impact on the quality of the pizzas served by the restaurant.
Infiltration of the Supplier: The attacker devises a plan to infiltrate the cheese supplier. This might involve bribing an employee, impersonating a quality inspector, or finding vulnerabilities in the supplier's operations.
Malicious Payload Injection: Once inside the supplier's operations, the attacker introduces a subtle alteration to the cheese production process. This could involve adding a non-standard ingredient that doesn't meet the restaurant's quality standards.
Distribution of Compromised Products: The tampered cheese is then sent to the pizza restaurant, packaged alongside the regular cheese. Since the cheese comes from a trusted source, the restaurant doesn't suspect anything unusual.
Activation of Malicious Payload: The attacker waits for the right moment to see the impact of their manipulation. This might be when the restaurant starts using the compromised cheese in their pizzas.
Exploitation and Quality Decline: Once the compromised cheese is used, the restaurant's pizzas no longer meet their usual high standards. Customers might notice a drop in quality and start complaining.
Maintaining Persistence (Optional): In this analogy, maintaining persistence would be like the attacker continuing to supply compromised cheese, causing ongoing quality issues for the restaurant.
In this scenario, just as in a real supply chain attack, the target organization (the pizza restaurant) suffers due to a compromise in a trusted link in their supply chain (the cheese supplier). This analogy illustrates how supply chain attacks can exploit vulnerabilities in trusted suppliers to compromise the integrity of a product or service.
Imagine a reputable software development company, Lacey Software, known for producing high-quality applications. Lacey relies on a code repository service called CodeVault, which stores and manages their source code throughout the SDLC. In this analogy, CodeVault serves as a critical link in Lacey's supply chain, analogous to a supplier in a traditional supply chain.
Identification of Target: The target is Lacey Software, known for its reliable and secure software products.
Research and Reconnaissance: An attacker conducts research and identifies CodeVault as a crucial component of Lacey's SDLC. Recognizing the potential impact of compromising this repository, the attacker decides to focus on it.
Targeting a Supplier (CodeVault): The attacker devises a plan to infiltrate CodeVault, understanding that if they can compromise the source code stored there, they can potentially introduce vulnerabilities or backdoors into Lacey's software products.
Infiltration of CodeVault: The attacker exploits a vulnerability in CodeVault's security infrastructure, gaining unauthorized access to the repository.
Malicious Code Injection: The attacker subtly modifies the source code stored in CodeVault, injecting malicious code or backdoors into Lacey's applications.
Integration into SDLC: Not detected by Lacey, the compromised code is integrated into their SDLC. As the development team continues their work, they unknowingly incorporate the tampered code into new versions of their software.
Quality Assurance and Testing: The tampered code, now part of Lacey's software, goes through the testing phase. Since the alterations are subtle, they may not trigger any red flags during the testing process.
Release and Deployment: The compromised software is released to customers. Since Lacey has a strong reputation, users trust the integrity of their products.
Exploitation and Security Breach: The attacker waits for the right moment to exploit the vulnerabilities introduced by the tampered code. This could lead to unauthorized access, data breaches, or other security incidents.
Discovery and Remediation: If suspicious activities are detected, Lacey may eventually discover the security breach. They must then work to identify the compromised code, remove it, and release a patched version of their software.
This section will present the case study of the 3CX Supply chain Attack which happened in April 2023 resulting in 3CX requesting its users to uninstall the desktop application from their devices.
3CX is a popular software-based Private Branch Exchange (PBX) system. It is known for its user-friendly interface and can be hosted on-premises or in the cloud, making it a versatile choice for businesses of all sizes seeking to optimize their communication infrastructure. Hence, it is very popular within the communication industry and the company's customers page boasts huge conglomerates and organisations. This sort of a company is definitely on the radar when someone is looking for a supply chain attack.
Investigation after discovery made it clear that it was 3CX that got internally breached and then the SDLC was tampered with.
According to Mandiant, the cybersecurity firm that helped 3CX investigate the incident, the threat group (tracked as UNC4736) behind the attack stole corporate credentials from the employee's device and used them to move laterally through 3CX's network, eventually breaching both the Windows and macOS build environments. The malware achieved persistence through DLL side-loading via legitimate Microsoft Windows binaries, which made it harder to detect. It also automatically loaded during start-up, granting attackers remote access to all compromised devices over the internet. This is a classic supply chain attack where the product has malicious code present, but since it goes through the DevOps cycle without detection, it is properly packaged and signed by the organisation which leads the product to be trusted across the internet even when it has malicious code present.
The Attack was detected on March 29th by Crowdstrike on 3CX's signed desktop application called 3CXDesktopApp which is a softphone(VoIP) application. It was performing malicious activity like deploying second stage payloads and in some cases, even hands on keyboard activity and sending beacon requests to the adversary's infrastructure.
A threat Actor by the name of Labyrinth Chollima was suspected to be the culprit behind this attack, but eventually Mandiant, the company assisting 3CX with the investigation attributed the attack to UNC4736, a North Korean Threat Actor.
The most standard way of securing a supply chain is to limit the number of vendors present in the supply chain so that more testing and auditing can be individually done on their standards. Not including open-source tooling is yet another way, but it has its downsides since a lot of amazing tools are open source and their code base is available to the public. Some events like eslint-scope being compromised does put doubts in minds of people developing SDLCs as well. In any case, limiting trust to the vendors is highly suggested to prevent a compromised vendor access to sensitive infrastructure or data like in the case of Target and their HVAC Vendor In case of Lacey or the Cheese vendor, quality assurance and testing of the data/raw material provided by the vendor before putting it in the works is something that could have prevented total compromise of the product. Some other textbook ways of securing a supply chain are as follows:
Vendor Risk Assessment and Due Diligence:
Contractual Security Obligations:
Continuous Monitoring and Auditing:
Incident Response and Contingency Planning:
Security Awareness Training and Education: