| August 23, 2019

How Existing Cybersecurity Frameworks Can Curb Supply Chain Attacks

Implementing Processes and Controls to Disrupt Attackers

Supply Chain Attacks

Supply chain attacks are a growing concern of any organization today. The goal of this type of attack is to compromise an organization via insecure components in the organization’s supply chain. Rather than attack an organization directly across the network perimeter or by phishing and social engineering of people in the organization, a supply chain attack targets software sources and installation methods. The adversary replaces trusted, benign software with malicious software, thereby gaining access to the victim’s systems. What follows is a review of the history of supply chain attacks as well as an analysis of the security control standards and processes that focus on stopping supply chain attacks.

History

A number of major historical software supply chain attacks have occurred over the years. One early example was the website compromise of kernel.org on August 28, 2011.^[1] This is the site which hosts the Git software repository for the Linux kernel. Due to the distributed nature of the Git revision control system, recovery from this attack was not difficult. In 2016 and 2017, there were two major compromises of single software vendors. One of which was the Transmission bittorrent client’s macOS version. Twice in 2016, Transmission’s site served an infected version of the client. The first, occurring in March of that year, was KeRanger, which turned out to be the first functional ransomware targeting macOS.^[2] The second was Keydnap, which occurred later in August of the same year.^[3] The other single software vendor which was discovered to have been compromised was CCleaner.^[4] According to command and control infrastructure overlap as well as code reuse, this attack has been attributed to APT17.^[5] This assessment demonstrates that nation state adversaries in addition to criminal adversaries are focusing on supply chain compromise as an attack technique in their intrusion set. The specific adversary technique of supply chain compromise is coded as T1195 in Mitre’s ATT&CK framework as an initial access tactic.^[6] About a year after the CCleaner incident, the UNIX connectivity software packages provided by NetSarang Computer, Inc. were found to contain a backdoor dubbed “ShadowPad” in one of the software’s DLLs, nssock2.dll.^[7] Attacks on single software vendors like these demonstrate how critical it is to analyze an organization’s software supply chain for evidence of compromise.

App stores and walled gardens have also fallen victim to supply chain attacks. Examples of this are malicious chrome extensions on the Chrome Web Store, and Android malware appearing in the Google Play Store. A specific example of the former, is the malware family dubbed Nigelthorn which was reported on May 10, 2018.^[8] This malicious extension had the capability to steal information from the victim’s workstation and to mine cryptocurrency. In the Android ecosystem, a recent malware attack was reported on March 29th of this year. This malware, Exodus, is a type of spyware which gives the adversary access to the victim’s mobile phone.^[9]

Throughout the past three years, a large number of open source software package repositories have been found to contain malware of various types. Major repositories include the Arch Linux User Repository (AUR)^[10], Node.js NPM registry^[11], the Ubuntu Snap Store^[12], RubyGems^[13], and the Python package repository PyPI^[14]. It is clear that all of the installation and update pathways for software and library code used in an organization must have security controls applied to them to prevent and mitigate supply chain attacks. What follows is an overview of the policies and procedures to prevent, control, and mitigate a supply chain attack according to the NIST Cybersecurity Framework.^[15] Included are specific case studies and concrete examples of how to use the ReversingLabs A1000 within these processes.

Timeline of Historical Supply Chain Attacks

Figure 1: Timeline of Historical Supply Chain Attacks

Identify

The first core function described by the framework is to identify. This function can be divided into two main components, both of which allow the organization to understand the lay of the land, so to speak. The first is asset management. It is important to map the flow of information and data within the organization^[16] and to catalog any external information systems^[17]. With regards to supply chain, this means understanding how software is updated and where it is used within the organization. As for cataloging external systems, an inventory of where software is updated from is important. The second main component is to understand the business environment. The organization should identify any dependencies specific supply chain components have on the delivery of the organization’s critical services.^[18] This knowledge allows for prioritization of resources where they can be most effective.

Once the lay of the land within the organization is understood, risk assessment of various flavors are applied to the assets. Firstly, each external system in the supply chain should be assigned a trustworthiness value. “Trustworthy information systems are systems that are capable of being trusted to operate within defined levels of risk despite the environmental disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of operation.”^[19] Secondly, threat intelligence gathered from information sharing forums and sources should be applied to the risk assessment process.^[20] If attacks are found in the wild for a particular component in the supply chain, this intelligence needs to be used to adjust the risk assessed for that component. In turn, if the risk rises above a threshold, changes in the organization’s security posture should be made and additional controls should be applied.

Threat Intelligence

Including threat intelligence in an organization’s security processes can be a complex task. A concept that allows this process to be more focused on what is most important to an organization is priority intelligence requirements (PIR). These are directives issued to an intelligence team that help them focus their collections and attention on specific systems and software used by the organization. Understanding the specifics of the organization’s supply chain informs the creation of PIRs specific to the vendors and sources used by the organization.

Protect and Detect

The next two core functions in the NIST framework are protect and detect. These are for developing safeguards to ensure the safety of the software supply chain and to detect malicious code that may compromise the organization. The most important aspect of the protect core framework function with regards to supply chain is to log all maintenance, specifically software upgrades.^[21] In addition to the upgrade logs, the results of software testing such as done using the ReversingLabs A1000 should be documented for later analysis or forensics.

ShadowPad Example

Taking a closer look at the ShadowPad supply chain attack mentioned above, the following process can be used to compare a previous known good version of the software to the potential update downloaded from the vendor. This process can be included in an IT department’s change management process, if they have a formal process. It can also be used ad-hoc during an IT department’s process for update testing before organization-wide rollout.

The first step is to obtain the old version which is known good and upload that file to the A1000.^[22] After the analysis is complete, upload the upgrade candidate file.^[23] Then open both analyses and compare them side-to-side, focusing on two main areas of the analysis results: capabilities and indicators. A change in either of these areas is a red flag that further, deeper analysis must be performed before this upgrade is allowed.

Video 1: Side by Side Analysis of ShadowPad nssock2.dll in ReversingLabs A1000

In addition to this side by side analysis, the designation of the file’s threat as well as the results from TitaniumCloud analysis should be examined. In the case of ShadowPad, the file is marked malicious with a threat designation of “Win32.Trojan.Shadowpad” and a wide variety of AV scanner engine detections.

Figure 2: A1000 Threat and TitanumCloud Results

Transmission Example

The NetSarang software packages are Windows PE software, but the A1000’s analysis is not restricted to this file type only. Examining the Transmission bittorrent client for macOS as an example, a similar process can be followed. After the known good and potential upgrade .dmg format files have been uploaded to the A1000, the unpacking functionality is used to drill down to the executable file contained in the install package. In most macOS software installation packages of format .dmg, one must navigate the A1000’s extracted files feature to analyze the executable. Inside the .dmg is a folder with the name of the program. Inside that is a directory with the file extension .app. Then inside that, the binary to analyze is in the Contents/MacOS/ directory.

Video 2: Unpacking macOS Package

Once both samples are unpacked, the capabilities and indicators for each can be compared side by side in the same way used with ShadowPad and Windows PE files.

Video 3: Side by Side Analysis of Transmission in ReversingLabs A1000

Exodus Android Malware Example

Even if you are installing software for the first time, and do not have an older known good file as a reference, these same analysis results can be used to check if a file has the capabilities one expects. In the case of Android apps, check for the expected permissions. In this example, we take a closer look at the Exodus Android spyware found in the Google Play Store on March 29th of this year. Examining the Android capabilities using the A1000, we see a few potentially problematic entries: camera, location services, microphone, and networking. If any of these capabilities are not expected for the app, this is an indication that the file needs to be more closely analyzed before allowing it to be installed.

Figure 3: Exodus Android Spyware Capabilities

In a similar way, the Android app’s requested permissions can be analyzed for suspicious combinations. In the following screenshot we can see that Exodus requests permission to connect to the Internet as well as to read the user’s SMSs. Suspiciously for an app that deals with SMS, it only requests read permission without requesting send permission.

Figure 4: Exodus Android Spyware Permissions

Automation

In any security program, it is essential to have processes that are repeatable and automated. Outlined in the detect core function of the NIST framework, is continuous monitoring. The specific control of malicious code protection in turn describes periodic scans.^[24] In the case of software supply chain analysis, this process can be an automated component of change management. This can include programmatic comparison of the API output from the A1000 in the specific fields checked in the examples above: capabilities and indicators. Any change in the number or type of entries in these fields should trigger an alert and kick off human intervention and deeper analysis.

Hopefully, readers have learned about supply chain security controls that can be put to use immediately using the A1000, even if automating the process is still in the future.

Security Control Standards

The NIST Cybersecurity Framework isn’t the only standard that customers may wish to follow when implementing supply chain security controls using the ReversingLabs A1000. What follows is a chart of standards that pertain to this process specifically.

TYPE	STANDARD	CODE	SECTION	TITLE
Supply Chain	NIST Cybersecurity Framework	ID.SC-4 ^[25]	Supply Chain Risk Management	Suppliers and third-party partners are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual obligations.
Supply Chain	NIST 800-53 (Rev. 4)	SA-12^[26]	System and Services Acquisition	Supply Chain Protection
Supply Chain	ISO/IEC 27001:2013	A.15.2.1 ^[27]	Supplier service delivery management	Organizations shall regularly monitor, review and audit supplier service delivery.
Supply Chain	NERC CIP-013-1	1.2.5 ^[28]	Supply Chain Risk Management	Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System
General	NIST Cybersecurity Framework	DE.CM-4 ^[29]	Security Continuous Monitoring	Malicious code is detected
General	NIST 800-53 (Rev. 4)	SI-3 ^[30]	System and Information Integrity	Malicious Code Protection
General	CIS Controls	8.1 ^[31]	Malware Defences	Utilize Centrally Managed Anti-Malware Software
General	ISO/IEC 27001:2013	A.12.2.1 ^[32]	Controls against malware	Detection, prevention and recovery controls to protect against malware shall be implemented, combined with appropriate user awareness.