Attacks on third-party libraries and tools that are often used while developing software have become dramatically frequent.
Among these attacks, one can find dependency confusion, issues in popular dev tools (Codecov, Homebrew, npm...), typosquatting, incidents (PHP, GitHub...), or malicious changes in popular dependencies (UAParser.js, coa, node-ipc...). I will share a lot of gripping real-life examples of such attacks, their causes and effects, and help you stay secure while developing software.
3. BIO
• Principal Security Consultant @ SecuRing
• Head of Web Security
• Co-author of Security Aware Developer
training
• Ex-developer
https://www.linkedin.com/in/molejarka/
https://twitter.com/molejarka
4. Agenda
• Attacks on libraries
• Attacks on tools
• Attacks on infrastructure
• Summary
11. Interview
I mean no harm to anyone in any
way
https://www.bleepingcomputer.com/news/software/empty-npm-package-has-over-700-000-downloads-heres-why/
12. Interview
Parzhitsky agrees [...] that the unusually high number of
downloads can most likely be attributed to developers
making typos
21. Dependency Confusion
What happens if malicious code is uploaded to npm under
these names?
Is it possible that some of PayPal’s internal projects will start
defaulting to the new public packages instead of the private
ones?
https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
47. On Thursday, April 1, 2021, we learned that
someone had gained unauthorized access to
our Bash Uploader script and modified it
without our permission.
48. This customer was using the shasum that is available on our
Bash Uploader to confirm the integrity of the uploader
fetched from https://codecov.io/bash.
52. Our use of Codecov’s Bash Uploader script was
limited: it was set up on a single CI server used
to test and build some internal tooling […].
We were not using Codecov on any CI
server used for product code.
https://www.rapid7.com/blog/post/2021/05/13/rapid7s-response-to-codecov-incident/
53. While investigation has not revealed evidence of
unauthorized usage of the exposed GPG key, it
has been rotated in order to maintain a trusted
signing mechanism
https://discuss.hashicorp.com/t/hcsec-2021-12-codecov-security-event-and-hashicorp-gpg-key-exposure/23512
55. Homebrew
In the Homebrew/homebrew-cask repository, it
was possible to merge the malicious pull
request by confusing the library that is used in
the automated pull request review script
developed by the Homebrew project.
https://blog.ryotak.me/post/homebrew-security-incident-en/
56. Homebrew
This is due to a flaw in the git_diff dependency of the
review-cask-pr GitHub Action, which is used to parse a pull
request’s diff for inspection.
Due to this flaw, the parser can be spoofed into
completely ignoring the offending lines, resulting in
successfully approving a malicious pull request.
57. Homebrew
By abusing it, an attacker could execute arbitrary Ruby codes
on users' machine who uses brew.
The discovered vulnerability would allow an attacker to inject
arbitrary code into a cask and have it be merged
automatically
58. Second, on November 2 we received a report to our security
bug bounty program of a vulnerability that would allow an
attacker to publish new versions of any npm package using
an account without proper authorization
https://github.blog/2021-11-15-githubs-commitment-to-npm-ecosystem-security/
59. We determined that this vulnerability was due to
inconsistent authorization checks and validation of data
across several microservices that handle requests to the npm
registry.
60. This vulnerability existed in the npm registry beyond the
timeframe for which we have telemetry to determine
whether it has ever been exploited maliciously.
61. However, we can say with high confidence that this
vulnerability has not been exploited maliciously during the
timeframe for which we have available telemetry, which
goes back to September 2020
62. Ruby Gems
An ordering mistake in the code that accepts gem uploads
allowed some gems […] to be temporarily replaced in the
CDN cache by a malicious package
https://github.com/rubygems/rubygems.org/security/advisories/GHSA-2jmx-8mh8-pm8w
63. Ruby Gems
1. An attacker could guess the next version number, and
create a gem with the name sorbet-static-0.5.9996-universal-
darwin and version number 20.
64. Ruby Gems
2. With a crafted invalid gemspec, it was possible to coerce
RubyGems.org to save that gem to S3 without creating a
matching database record.
65. Ruby Gems
3. Later, the real sorbet-static gem would release version
0.5.9996 as usual, and the attacker-controlled file would be
overwritten on S3.
66. Ruby Gems
4. However, if the attacker had already primed the Fastly
CDN cache by requesting their malicious gem, Fastly would
continue to serve the old, malicious package.
69. Yesterday (2021-03-28) two malicious commits were pushed
to the php-src repo [1] from the names of Rasmus Lerdorf
and myself.
We don't yet know how exactly this happened, but
everything points towards a compromise of the git.php.net
server (rather than a compromise of an individual git
account).
https://news-web.php.net/php.internals/113838
70.
71.
72. Something I was not aware of at the time is that
git.php.net (intentionally) supported pushing
changes not only via SSH […] but also via HTTPS.
The latter did not use gitolite, and instead used git-http-
backend behind Apache2 Digest authentication against
the master.php.net user database.
https://news-web.php.net/php.internals/113981
73.
74. It is notable that the attacker only makes a few guesses at
usernames, and successfully authenticates once the correct
username has been found.
While we don't have any specific evidence for this, a possible
explanation is that the user database of master.php.net has
been leaked
75. The master.php.net system, which is used for authentication
and various management tasks, was running very old code
on a very old operating system
/
PHP version, so some kind of vulnerability would not be
terribly surprising.
76. On April 12, GitHub Security began an investigation that
uncovered evidence that an attacker abused stolen OAuth
user tokens issued to two third-party OAuth integrators,
Heroku and Travis-CI, to download data from dozens of
organizations, including npm.
https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/
77. Our analysis of other behavior by the threat actor suggests
that the actors may be mining the downloaded private
repository contents, to which the stolen OAuth token had
access, for secrets that could be used to pivot into other
infrastructure.
78. GitHub contacted Heroku and Travis-CI to request that they
initiate their own security investigations, revoke all OAuth
user tokens associated with the affected applications, and
begin work to notify their own users.
79. We do not believe the attacker obtained these tokens via a
compromise of GitHub or its systems, because the tokens in
question are not stored by GitHub in their original, usable
formats.
80. On April 7, 2022, a threat actor obtained access to a Heroku
database and downloaded stored customer GitHub
integration OAuth tokens.
Access to the environment was gained by leveraging a
compromised token for a Heroku machine account.
https://status.heroku.com/incidents/2413
81. On that same day, the threat actor downloaded data from
another database that stores pipeline-level config vars for
Review Apps and Heroku CI.
Additionally, another small subset of Heroku users had their
Heroku tokens exposed in a config var for a pipeline.
82. On April 15, 2022, Travis CI personnel were informed that
certain private customer repositories may have been
accessed by an individual who used a man-in-the-middle
2FA attack, leveraging a third-party integration token.
https://blog.travis-ci.com/2022-04-17-securitybulletin
83. Upon further review that same day, Travis CI personnel
learned that the hacker breached a Heroku service and
accessed a private application OAuth key used to integrate
the Heroku and Travis CI application.
84. Travis CI immediately revoked all authorization keys and
tokens preventing any further access to our systems. No
customer data was exposed and no further access was
possible.
90. Libraries
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
91. Libraries
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
• When not sure do not install
92. Libraries
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
• When not sure do not install
• Enable 2FA (as a maintainer)
93. Enforcing 2FA
• Top 100 packages
• Started on: 1.02.2022
• Packages classified
as critical: ~4000
• Started on:
8.07.2022
• Top 100 packages
• Started on: 15.08.2022
96. What can go wrong with enforcing 2fa?
https://github.com/untitaker/python-atomicwrites/issues/61
97. atomicwrites
I'd rather just write code for fun and only worry about
supply chain security when I'm actually paid to do so.
98. Libraries
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
• When not sure do not install
• Enable 2FA (as a maintainer)
100. Tools
• I will not download and run scripts directly from the
net
101. Tools
• I will not download and run scripts directly from the
net
• I will verify checksums and signatures of downloaded
files
102. Tools
• I will not download and run scripts directly from the
net
• I will verify checksums and signatures of downloaded
files
• I will install only from official sources
103. Tools
• I will not download and run scripts directly from the
net
• I will verify checksums and signatures of downloaded
files
• I will install only from official sources
• I will update frequently what I’ve already installed
104. Tools
• I will not download and run scripts directly from the
net
• I will verify checksums and signatures of downloaded
files
• I will install only from official sources
• I will update frequently what I’ve already installed
107. Infrastructure
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused
108. Infrastructure
• Keep good inventory, especially of what is in the
clouds
• Disable/shutdown what’s unused
• Secure configurations
109. Infrastructure
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused
• Secure configurations
• Frequently update (to fix known issues)
110. Infrastructure
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused
• Secure configurations
• Frequently update (to fix known issues)
• Monitor, monitor, monitor
111. Infrastructure
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused
• Secure configurations
• Frequently update (to fix known issues)
• Monitor, monitor, monitor
112. 2023?
• Google Assured Open Source Software
• Google Software Delivery Shield
• Widespread MFA adoption
• Built-in detection of typosquatting