Software Supply Chain Exploitation - Part 1

Introduction

This post is part one of a series that will be posted on the topic of “Software Supply Chain Exploitation”. With this post (Part 1), we start by providing a high level overview of Software Supply Chain Exploitation including historical case examples of exploitation and tools for exploitation. In subsequent parts in this series we plan to focus more on in-depth technical research including tools and ideally novel approaches.

Tactic – Initial Access

We start by following the standard MITRE ATT&CK Matrix definition for Initial Access here.

Technique – Supply Chain Compromise

We continue by following the standard MITRE ATT&CK Matrix definition for Supply Chain Compromise here.

Sub-Technique – Compromise Software Supply Chain

We continue to follow the sub-techniques, T1195.002 Compromise Software Supply Chain here.

Procedures

• We break the procedures down into three specific categories:Threat Exploitation and Access Method (TAAM) – This is the method of exploitation the threat actor utilizes to gain access via a specific Threat Exploitation and Access Means (TEAM).
• Threat Exploitation and Access Means (TEAM) – This is the means by which the TAAM is deployed to achieve access.
• Tools – The specific tooling used to enable both TAAMs and TEAMs.

Threat Exploitation and Access Method (TAAM)

• Intentionally Developed Malicious Code
  • Any form of malicious compiled or uncompiled malicious code. This could come in any form.
• Intentionally Developed Vulnerable Code
  • Similar to malicious code, but instead a threat actor intentionally introduces vulnerable code that passes undetected by anti-virus / anti-malware. When introducing basic function level vulnerabilities, the code may be detected by code quality scanners. When introducing business logic vulnerabilities these could bypass code quality scanners.
• Unintentionally Developed Vulnerable Code
  • The run of the mill vulnerable code that was introduced by poor software development habits.
• Restricted and Prohibited Code (Environment/Organization Specific)
  • Most public and private environments from small to large have restrictions on the type of software that is prohibited from use by any user or restricted to specific users. This includes “hacker tools” and other types of tools that can enable threat actor tactics, especially discovery, lateral movement, and exfiltration.
• License Violations
  • This is less about access and more about litigation. From a defensive perspective it is important to include this. However, any attacker can think outside of the box on how this could be beneficial.

Introduction to the Supply Chain Cycle (SCC)

Categorically, managing the supply chain lifecycle (design, sourcing, manufacture, distribution, integration, deployment/installation, maintenance and retirement of software) is known as software supply chain management ^{1 2}. We focus primarily on exploitation of sourcing, manufacturing and distribution. There can be crossover from manufacturing and distribution into integration, deployment, and installation depending on several factors. We must also consider that within the overall supply chain for one product that there are multiple sub-supply chains both internal and external to the entity that we seek to exploit.

When building physical hardware this is much simpler to visualize. For example, if you are at the beginning of the supply chain (upstream), you may be the miner that’s mining the raw materials needed to build the boards, the chips, the solder, etc. From there those materials get distributed, manufactured into boards, chips, etc. These components are distributed and manufactured into other components such as motherboards, GPUs, etc. This continues on and on until they are finally sold to consumers, installed and maintained in an environment somewhere. They go through years of maintenance until they are retired. The key takeaway is that there are risks (in our case, opportunities for exploitation) presented within each of the process within these sub-supply chain stages. Some examples of hardware supply chain attacks, some of which cross into the realm of software supply chain attacks, include:

• Installation of a dopant level trojan within a microchip ³.
• Embedding of a rogue microchip (including those capable of receiving/transmitting data out-of-band via the electromagnetic spectrum) on a larger component such as the motherboard ^{4 5 6}.
• Backdooring of firmware on an embedded system (e.g. Motherboard BIOS, GPU BIOS, Hard Drive, etc) within a traditional computing asset such as desktop computers, laptops, servers, smartphones, tablets, routers, switches, wireless access points, internet of things (IoT) devices, and many other personal and commercial use equipment ^{7 8 9 10 11 12}.
• Backdooring of firmware on industrial control systems, satellite control systems, or other mission critical embedded system. Installation of malicious software on the operating system (OS) of a fully assembled computer ¹³.

We can utilize this understanding of the hardware supply chain to better understand the software supply chain and its sub-supply chains.

• File Sub-Supply Chain. Any individual file developed internally or externally can be synonymized with a microchip. These individual files can be Commercial off-the-shelf (COTS), Government off-the-shelf (GOTS), or open-source software (OSS). Each file can have its own sourcing (materials), manufacturing (assembly), and distribution (storage and transit) processes. Risk, and thus opportunity for exploitation, is introduced within each of these processes of the file sub-supply chain.
• Software Package Sub-Supply Chain. Files (possibly from a multitude of similar or disparate internal and/or external sources), including dependencies, come together to create a larger archive or “software package”, which can be synonymized with a motherboard. Software packages can also be fully or partially COTS, GOTS, and OSS. Each software package can have its own sourcing (materials), manufacturing (assembly), and distribution (storage and transit) processes. Risk, and thus opportunity for exploitation, is introduced within each of the processes of the software package sub-supply chain, which is compounded from every file sub-supply chain that forms the larger software package sub-supply chain.
• Package of Packages Sub-Supply Chain. Files and/or software packages can come together to form a larger “package of packages” (possibly from a multitude of similar or disparate internal and/or external sources), which can be synonymized to an assembled computer. Examples of a “package of packages” include container images, operating systems, firmware, and large archives of archives (e.g. ISOs). Each package of packages can also be fully or partially COTS, GOTS, and OSS. Each package of packages can have its own sourcing (materials), manufacturing (assembly), and distribution (storage and transit) processes. Risk, and thus opportunity for exploitation, is introduced within each of the processes of the package of packages sub-supply chain, which is compounded from every file and software package sub-supply chain that forms the larger package of packages sub-supply chain.

Even when we look at each of the customers that our target may have, there may be different ways that they tailor the phase(s) within the supply chain cycle to each customer or group of customers, particularly when talking about CI/CD processes and especially when involving security processes like code quality and code security tools. For example, there may be exceptions to policies to omit security processes under certain circumstances.

Targeting the Supply Chain Cycle Processes

• Sourcing (Materials)
  • Sourcing involves gathering all of the raw materials necessary to build the product at the sub-supply chain phase the target organization exists at.
• Manufacturing (Assembly)
  • Manufacturing involving assembling the materials that we have sourced into some form of intermediary or final product.
• Distribution (Storage and Transit)
  • Distribution involves storing and moving the products from one link in the supply chain to another. This may be from a supplier to a manufacturer or a manufacturer to a distributor or distributor to a seller or a seller to a consumer.

Introduction to Threat Exploitation and Access Means (TEAM)

The Threat Exploitation and Access Means (TEAMs) are really the core of the procedures. We can begin mapping the TEAMs back to the TAAMs, and SCC phases. From there we can add a generalized non-environment, non-organization specific qualitative risk assessment (for defender reference; highly recommend conducting your own risk assessment). Finally, we can add in historical examples of the TEAMs and open-source exploitation tools.

TEAM #1: Hosting on illegitimate websites (Data-at-Rest)

• SCC
  • Sourcing
  • Distribution
• TAAMs
  • Intentionally Developed Malicious Code
  • Intentionally Developed Vulnerable Code
• Qualitative Risk: HIGH to EXTREME
• Historic Examples:
  • These are all too common:
    • Fake NordVPN ¹⁴
    • Fake Zoom and Google Classroom during COVID-19 ¹⁵
    • Fake MSI Afterburner ¹⁶
    • Fake Microsoft and Spotify ¹⁷
    • Fake Microsoft DirectX 12 ¹⁸
• Exploitation Tools:
  • There’s a ton of tools for setting up the infrastructure for this. You can use a website cloner for example:
    • https://github.com/Bitwise-01/AnyPhish
    • https://github.com/imthaghost/goclone
• Then serve your malicious executable. Most cloners are built for credential harvesting so you might have to use something like goclone or httrack. You then may have to make some modifications to serve a drive-by-download of your binary. Most actors using this procedure are really performing “Phishing” or “Drive-by Compromise” as their Initial Access tactic. In my humble opinion, this isn’t true supply chain compromise unless you can get a developer to download a dependency from an illegitimate site.

TEAM #2: Hosting on illegitimate code repositories (Data-at-Rest)

• SCC:
  • Sourcing
  • Distribution
• TAAMs
  • Intentionally Developed Malicious Code
  • Intentionally Developed Vulnerable Code
• Qualitative Risk: HIGH to EXTREME
• Historic Examples:
  • This is similar to TEAM #1, except we are talking code repositories like Github, NPM, PyPi, and even mirrors for packages for operating systems. It’d be hard to trick a developer to go to a fake GitHub, but it isn’t as hard to get someone to go to an incorrect mirror. This is especially true for automated systems, especially if you have access to an environment already. You may be able to add an illegitimate repo somewhere in the code or CI/CD pipeline when building infrastructure for example. If you look at some of the mirrors for Debian here, many of them look janky anyways.
• Exploitation Tools:
  • Nothing to note at this time.

TEAM #3: Infiltration/Hi-Jacking and Injection into Legitimate Connections (Data-in-Transit)

• SCC:
  • Sourcing
  • Distribution
• TAAMs
  • Intentionally Developed Malicious Code
  • Intentionally Developed Vulnerable Code
• Qualitative Risk: MEDIUM
• Historic Examples:
  • It’s not that uncommon for Nation States to perform traffic redirection, especially on vulnerable protocols like BGP (e.g. BGP Hijacking), probably for the purpose of data collection and analysis rather than injection. I do not have examples of man-in-the-middle (MITM) for injection into the software supply chain, but if it hasn’t already happened, expect it to happen. Here are some examples of recent BGP Hijacks:
    • “(2020) Russian Teleco Hijacks internet traffic for Google, AWS. Cloudflare, and others” ¹⁹
    • “(2019) Large European routing leak sends traffic through China Telecon” ²⁰
    • “(2018) Who Hijacked Google’s Web Traffic – Data Routes Through Russia, Nigeria, and China” ²¹
    • “(2018) Telegram traffic from around the world took a detour through Iran” ²²
  • Collection (sniffing) and traffic analysis is one thing, however, injecting malicious code into something like a software update isn’t easy. Most protocols starting at Layer 2 have checksums built in. What may be better is performing a secondary attack such as DNS poisoning, so the victim visits a malicious version of a site when they intended to go to the legitimate version (e.g. github.com). While I was writing this, I came across a SANS whitepaper where someone else thought of this exact scenario when combining BGP + DNS Poisoning (look under “3.2.1 Secondary Attacks”) ²³. This could even be combined with TEAM #4 or TEAM #5 below for maximum effectiveness. For example, find the most downloaded packages for the top 10 coding languages and then during the window of time that you have your BGP Hijack + DNS Poisoning online ensure that you are pushing out malicious versions of those packages. Considering the automation of many CI/CD pipelines, lack of heuristic-based antimalware built into the pipeline, and lack of transitive dependency analysis these packages would likely get pulled in and built somewhere. If you had your intel spot on, you could do better targeting.
• Exploitation Tools:
  • There are OSS tools available for conducting MITM attacks.

TEAM #4: Infiltration or Injection into Legitimate Code Repositories, Websites, and other Code Distribution and Storage Mechanisms (incl. Update Servers)

• SCC:
  • Sourcing
  • Distribution
  • Manufacturing
• TAAMs
  • Intentionally Developed Malicious Code
  • Intentionally Developed Vulnerable Code
• Qualitative Risk: HIGH to EXTREME
• Historic Examples:
  • Keep in mind for TEAM #4 and #5 that attackers, most notably Advanced Persistent Threats (APTs), will target the weakest link in the supply chain which they can then use to gain access to subsequent members in the supply chain ^{24 25 26}. This access can then be utilized for Computer Network Exploitation (CNE) or Computer Network Attack (CNA).
    • (2010) Hacked Kaspersky Download Site Redirects Users to Fake Antivirus ²⁷
    • (2011) Kernel.org (Linux Kernel) repository compromised ²⁸
    • (2011) An APT accesses a legitimate South Korean software vendor’s update server and redirects an update to a malicious file leading to the compromise of South Korean social media provider ²⁹
    • (2014) An APT (Dragonfly/EnergeticBear/Havex/CrouchingYeti) Compromised legitimate Industrial Control Systems (ICS) vendor websites and backdoored legitimate software ³⁰
    • (2014) Shylock Trojan used to compromise legitimate websites and redirect visitors to malicious domains where the trojan would be installed on the visiting victims’ machines ³⁰
    • (2017) APT17 (allegedly) uses CCleaner to install malware on unsuspecting victims ³¹
    • (2017) Malicious NPM package “cross-env” uploaded to trick users looking for legitimate “crossenv” ³²
    • (2017) APT28 implants NotPetya disk wiper into Ukrainian tax software (M.E. Doc) update ^{33 34 35}
    • (2018) Node.js package is injected with malicious code used to steal BitCoin ³⁶
    • (2018) Gentoo Linux repository on GitHub compromised and malicious code implanted ³⁷
    • (2018) Malware found in Arch Linux AUR package repository ³⁸
    • (2018) Malicious code found injected into NPM package “event-stream” ³⁹
    • (2018) Github for VestaCP web server control management implanted with malicious script ⁴⁰
    • (2019) Canonical GitHub Account Hacked (Ubuntu Source Code). “Source Code Deemed ‘Safe’”³⁷
    • (2019) Ruby Gem package hijacked ⁴¹
    • Other: PyPi has an ongoing issue with malicious packages using “typo squatting” ^{42 32}
    • Other: List of malicious NPM packages (NPM advisories) ⁴³
• Exploitation Tools:
  • Typosquatting: https://github.com/zntrio/typogenerator
  • Backdoor Docker Images https://github.com/cr0hn/dockerscan (see “Trojanize”)
  • Firmware Exploitation (extract filesystem, inject backdoor, exec at boot via init/systemd): https://github.com/ReFirmLabs/binwalk
  • Note: For most of the package managers you just need to drop your malicious code into the repo, site, etc

TEAM #5: Infiltration or Injection into Legitimate Code Development Environments (e.g. Development Computer, Workspace, Virtual Machine, or CI/CD pipeline)

• SCC:
  • Sourcing
  • Distribution
  • Manufacturing
• TAAMs
  • Intentionally Developed Malicious Code
  • Intentionally Developed Vulnerable Code
• Qualitative Risk: MEDIUM
• Historic Examples:
  • This probably requires the most skill or luck (if you just happen to have landed on a developer box for example). In the event of SolarWinds, the attackers were way downstream in terms of SolarWinds, but they understood that SolarWinds would give them access to a ton of High Value Targets (HVTs). These HVTs likely included other software developments and thus other supply chains. So, do we really know where it ends?
    • SolarWinds ⁴⁴
• Exploitation Tools:
  • Jenkins Attack Framework: https://github.com/Accenture/jenkins-attack-framework
  • Travis CI Exploitation Tools: Nothing yet.
  • SonarQube Backdoor: https://github.com/braindead-sec/pwnrqube
  • Nexus Exploitation Tools: Nothing yet.
  • Jfrog Artifactory Exploitation Tools: Nothing yet.
  • Jira Exploitation: https://github.com/0x48piraj/Jiraffe
  • Git Dumper: https://github.com/arthaud/git-dumper
  • AWS Exploitation:
    • https://github.com/RhinoSecurityLabs/pacu
    • https://github.com/toniblyx/my-arsenal-of-aws-security-tools
    • https://github.com/Voulnet/barq
    • More out there!
  • Azure Exploitation
    • https://github.com/mattrotlevi/lava
    • https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Cloud%20-%20Azure%20Pentest.md
    • https://github.com/hausec/PowerZure
    • https://github.com/fox-it/adconnectdump
    • https://github.com/chryzsh/DarthSidious/blob/master/enumeration/azure-enumeration.md
    • https://github.com/Kyuu-Ji/Awesome-Azure-Pentest
    • More out there!
  • There’s a lot more to this and it really deserves a deeper dive in this series…

TEAM #6: Poor Coding Practices

• SCC:
  • Sourcing
• TAAMs:
  • Unintentionally Developed Vulnerable Code
  • Qualitative Risk: MEDIUM to EXTREME
• Historic Examples:
  • Here I will save us all the mundane, by providing a footnote to NVD. ⁴⁵
  • For developers and defenders, I will say that if you are not using a Code Quality and Code Security scanning tool as part of your pipeline at a minimum, you need to start. There are a ton of OSS and COTS products that complement each other in this task. I highly recommend using multiple.
• Exploitation Tools:
  • Download. Compile. Exploit. ⁴⁶

TEAM #7: Restricted and Prohibited Code

• SCC:
  • Sourcing
• TAAMs:
  • Restricted and Prohibited Code
  • Qualitative Risk: MEDIUM to EXTREME
• Historic Examples:
  • In some environments all you may need to do is bring in a package or package of packages that contains one line of code, file, library, or package that enables activity that is prohibited or restricted for users. Furthermore, if it is available (think nc, etc on Unix/Linux or PowerShell on Windows), it may enable an attacker within an environment. Sometimes a user may unintentionally bring in something that is restricted or prohibited. Other times it could be an insider threat working on behalf of a malicious actor. What’s even more crafty is when a malicious actor can include the restricted or malicious code as part legitimate otherwise allowed code to help them setup their environment later.
• Exploitation Tools:
  • Defender Perspective: Environment and policy specific.
  • Attacker Perspective: Any tool that could enable you or an insider to live off the land later.

TEAM #8: Litigation

• SCC:
  • Sourcing
• TAAMs:
  • License Violations
• Qualitative Risk: MEDIUM
• Historic Examples:
  • There are many out there, especially between small businesses and big tech. Google “software license violation (“sue” or “litigation”) and you will find several recent examples.
• Exploitation Tools:
  • N/A

References