A supply chain attack, also called a value-chain or third-party attack, occurs when someone infiltrates your system through an outside partner or provider with access to your systems and data. This has dramatically changed the attack surface of the typical enterprise in the past few years, with more suppliers and service providers touching sensitive data than ever before.

1. BackStabber Special: Software
Supply Chain Attacks
By: Vinay Kumar

2. Agenda
● What are software supply chains
● Instances of supply chain attacks
● Background of Supply Chain Attacks
● Recommendations of improvement

3. Supply Chains In SDLC
● Whole pipeline to deliver the product based on trust.
● The artifacts used are trusted throughout the stages.
● Private being not so private.

4. Supply Chain Attacks
● Inject “Malicious” code into Software Products.
● Definition of Vulnerable and Malicious: Technically, same but depends on
intentions.
● The problem of sources:
○ Multiple resources: A huge boom of OSS and their usage.
○ Not everything is in-house.

5. Supply Chain Attacks: Examples
● NotPetya: A Ransomware but not a ransomware.
● Windows CC Cleaner
● Transitive Dependencies
● A single open-source repository used by many.

6. Background: SCA
● Interesting stats:
○ 50% malicious packages are inherited from other dependency.
○ Version Pinning to vulnerable packages and security patches
delivered on the fly.
○ Highly Active Devs and Maintainers are targeted.
■ Solution: active code analysis.
○ NPM packages: Pretty huge in number:
■ Solution: Static code analysis (not just Lint tests)
■ Machine Learning scope: Use Unsupervised learning to
detect potential anomalies.

7. Background: SCA

8. Background: Injection of malicious code

9. Background: Execution of malicious code

10. Background: Execution of malicious code
● Some stats:
○ 56% start their execution while installation:
■ Python’s “init.py”. Try `python -c "import antigravity"` for a rough idea
○ 41% execute by checking some conditions:
■ They are pretty hard to check by static code analysis
■ Testing them in sandbox is tough as well, because we may not have test cases
identified.
○ 56% utilize type-squatting:
■ Rely on human errors.
■ Some package repositories mark such packages as invalid but they still make it through.
The stats are derived from the research paper here: https://rdcu.be/cgzme

11. Background: objectives of malicious code
● Some observations:
○ Money. (Ransomware)
○ Data exfiltration: reading bash_history , /etc/passwd, ~/.ssh/*
○ Opening backdoors for attackers.
○ Most packages are OS agnostic:
■ MacOS seems to be the most ‘secure’.
■ Linux being highly attractive for such attacks
○ Obfuscation:
■ Hiding functions encrypted.
■ Packages with encrypted deliverables (tarballs) allow attackers to squeeze in code

12. ● Stop arbitrary code execution:
○ Python’s Wheel is an effective tool which stops code execution while importing.
○ NPM is infected with it.
● MFA for all.
● Use Version Pinning but:
○ No Automated Bug/Security patches to the artefact.
○ Specify specific version in dependencies: 2.3.4 and not >= 2.3
● Save Against TypeSquatting:
○ Awareness is a good thing.
● Have a Single Private Feed, not Multiple:
○ Have priority set for such feeds.
○ Scope the packages with Unique IDs so that the same name cannot be taken by attackers.
● Always go for checksum verification.
Recommendations For Improvements

13. ● A review of supply chain attacks
● 3 Way Mitigation for Supply Chain Attacks
● Some Attacks:
○ Remote execution of code
○ CryptoCurrency Package that copies content from the clipboard
● Tool:
○ Snyk: For Dependency checking
● A FOS Library of malicious packages
References

14. Thanks!