The frequency of attacks on third-party libraries and tools used in software development has dramatically increased in recent years.
Typosquatting, dependency confusion, malicious changes in popular dependencies (UAParser.js, coa, node-ipc...), issues in popular dev tools (Codecov, Homebrew, npm...) or incidents (PHP, GitHub...). In this presentation, I will go over many fascinating, recent examples of these attacks, their causes and effects, and recommend to you how to stay secure when 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
https://www.bleepingcomputer.com/news/software/empty-npm-package-has-over-700-
000-downloads-heres-why/
20. 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
Dependency Confusion
46. On Thursday, April 1, 2021, we learned that
someone had gained unauthorized access
to our Bash Uploader script and modified
it without our permission.
47. 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.
51. 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/
52. 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
54. 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/
55. 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.
56. 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
57. 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/
58. 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.
59. This vulnerability existed in the npm
registry beyond the timeframe for which
we have telemetry to determine whether it
has ever been exploited maliciously.
60. 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
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.
63. 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.
64. 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.
65. 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.
68. 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
69.
70.
71. 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
72.
73. 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
74. 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.
75. 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/
76. 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.
77. 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.
78. 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.
79. 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
80. 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.
81. 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
82. 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.
83. 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.
89. Libraries
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
90. Libraries
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
• When not sure do not install
91. 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)
92. • Top 100 packages
• Started on:
1.02.2022
• Packages classified
as critical: ~4000
• Started on:
8.07.2022
Enforcing 2FA
95. What can go wrong
with enforcing 2fa?
https://github.com/untitaker/python-atomicwrites/issues/61
96. atomicwrites
I'd rather just write code for fun and only
worry about supply chain security when
I'm actually paid to do so.
97. 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)
99. Tools
• I will not download and run scripts directly from
the net
100. Tools
• I will not download and run scripts directly from
the net
• I will verify checksums and signatures of
downloaded files
101. 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
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
• I will update frequently what I’ve already
installed
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
106. Infrastructure
• Keep good inventory, especially of what is in
the clouds
• Disable/shutdown what’s unused
107. Infrastructure
• Keep good inventory, especially of what is in
the clouds
• Disable/shutdown what’s unused
• Secure configurations
108. Infrastructure
• Keep good inventory, especially of what is in
the clouds
• Disable/shutdown what’s unused
• Secure configurations
• Frequently update (to fix known issues)
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)
• Monitor, monitor, monitor
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