Guarding against supply chain attacks—Part 3: How software becomes compromised

Do you know all the software your company uses? The software supply chain can be complex and opaque. It’s comprised of software that businesses use to run operations, such as customer relationship management (CRM), enterprise resource planning (ERP), and project management. It also includes the third-party components, libraries, and frameworks that software engineers use to build applications and products. All this software can be difficult to track and can be vulnerable to attack if not known and/or not managed properly.

In the U.S. Department of Defense’s Defense Federal Acquisition Regulation Supplement, a supply chain risk is defined as “the risk that an adversary may sabotage, maliciously introduce unwanted function, or otherwise subvert the design, integrity, manufacturing, production, distribution, installation, operation, or maintenance of a covered system so as to surveil, deny, disrupt, or otherwise degrade the function, use, or operation of such system.”

If you rely on a web of software providers, it’s important that you understand and mitigate your risk. This Part 3 of our five-part blog series entitled “Guarding against supply chain attacks” illustrates how software supply chain attacks are executed and offers best practices for improving the quality of the software that undergirds your applications and business.

Examples of software supply chain attacks with global reach

Starting in 2012 the industry began to see a marked increase in the number of attacks targeted at software supply chains each year. Like other hacking incidents, a well-executed software supply chain attack can spread rapidly. The following examples weaponized automatic software updates to infect computers in large and small companies in countries all over the world and highlight how they have evolved over time.

  • The Flame malware of 2012 was a nation-state attack that tricked a small number of machines in the Middle East into thinking that a signed update had come from Microsoft’s trusted Windows Update mechanism, when in fact it had not. Flame had 20 modules that could perform a variety of functions. It could turn on your computer’s internal microphone and webcam to record conversations or take screenshots of instant messaging and email. It could also serve as a Bluetooth beacon and tap into other devices in the area to steal info. Believed to come from a nation state, Flame sparked years of copycats. While Flame was a supply chain “emulation” (it only pretended to be trusted), the tactic was studied and adopted by both nation states and criminals, and included noted update attacks like Petya/NotPetya (2017), another nation-state attack, which hit enterprises in over 20 countries. It included the ability to self-propagate (like worms) by building a list of IP addresses to spread to local area networks (LANS) and remote IPs.
  • CCleaner affected 2.3 million computers in 2018, some for more than a month. Nation-state actors replaced original software versions with malware that had been used to modify the CCleaner installation file used by customers worldwide. Access was gained through the Piriform network, a company that was acquired by Avast before the attack was launched on CCleaner users. As Avast says in a blog on the subject, “Attackers will always try to find the weakest link, and if a product is downloaded by millions of users it is an attractive target for them. Companies need to increase their attention and investment in keeping the supply chain secure.”
  • In May 2017, Operation WilySupply compromised a text editor’s software updater to install a backdoor on target organizations in the financial and IT sectors. Microsoft Defender Advanced Threat Protection (ATP) discovered the attack early and Microsoft worked with the vendor to contain the attack and mitigate the risk.

Implanting malware

There are three primary ways that malicious actors infect the software supply chain:

  • Compromise internet accessible software update servers. Cybercrooks hack into the servers that companies use to distribute their software updates. Once they gain access, they replace legitimate files with malware. If an application auto-updates, the number of infections can proliferate quickly.
  • Gain access to the software infrastructure. Hackers use social engineering techniques to infiltrate the development infrastructure. After they’ve tricked users into sharing sign-in credentials, the attackers move laterally within the company until they are able to target the build environment and servers. This gives them the access needed to inject malicious code into software before it has been complied and shipped to customers. Once the software is signed with the digital signature it’s extremely difficult to detect that something is wrong.
  • Attack third-party code libraries. Malware is also delivered through third-party code, such as libraries, software development kits, and frameworks that developers use in their applications.

Safeguarding your software supply chain

There are several steps you can take to reduce the vulnerabilities in your software. (We’ll address the vulnerabilities and mitigation strategies related to people and processes in our next post.):

  • Much like the hardware supply chain, it’s important to inventory your software suppliers. Do your due diligence to confirm there are no red flags. The NIST Cyber Supply Chain Best Practices provide sample questions that you can use to screen your software suppliers, such as what malware protection and detection are performed and what access controls—both cyber and physical—are in place.
  • Set a high standard of software assurance with partners and suppliers. Governmental organizations such as the Department of Homeland Security, SafeCODE, the OWASP SAMM, and the U.K. National Cyber Security Centre’s Commercial Product Assurance (CPA) provide a model. You can also refer to Microsoft’s secure development lifecycle (SDL). The SDL defines 12 best practices that Microsoft developers and partners utilize to reduce vulnerabilities. Use the SDL to guide a software assurance program for your engineers, partners, and suppliers.
  • Manage security risks in third-party components. Commercial and open-source libraries and frameworks are invaluable for improving efficiency. Engineers shouldn’t create a component from scratch if a good one exists already; however, third-party libraries are often targeted by bad actors. Microsoft’s open source best practices can help you manage this risk with four steps:
    1. Understand what components are in use and where.
    2. Perform security analysis to confirm that none of your components contain vulnerabilities
    3. Keep components up to date. Security fixes are often fixed without explicit notification.
    4. Establish an incident response plan, so you have a strategy when a vulnerability is reported.

Learn more

“Guarding against supply chain attacks” is a five-part blog series that decodes supply chain threats and provides concrete actions you can take to better safeguard your organization. Previous posts include an overview of supply chain risks and an examination of vulnerabilities in the hardware supply chain.

We also recommend you explore NIST Cybersecurity Supply Chain Risk Management.

Stay tuned for these upcoming posts as we wrap up our five-part series:

  • Part 4—Looks at how people and processes can expose companies to risk.
  • Part 5—Summarizes our advice with a look to the future.

In the meantime, bookmark the Security blog to keep up with our expert coverage on security matters. For more information about Microsoft Security solutions, visit our website: https://www.microsoft.com/en-us/security/business. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Guarding against supply chain attacks—Part 3: How software becomes compromised appeared first on Microsoft Security.

Article Link: https://www.microsoft.com/security/blog/2020/03/11/guarding-against-supply-chain-attacks-part-3-how-software-becomes-compromised/