1.
Mateusz Olejarka
Developer in a digital
crosshair, 2022
edition

2.
BIO
• Principal Security Consultant @ SecuRing
• Head of Web Security
• Co-author of Security Aware Developer
training
• Ex-developer

3.
AGENDA
•Attacks on libraries
•Attacks on tools
•Attacks on infrastructure

4.
Attacks on
libraries
https://flickr.com/photos/29233640@N07/

5.
COMPLEXITY https://sambleckley.com/writing/npm.html

6.
FUN FACT
https://www.npmjs.com/package/-

7.
FUN FACT
https://cdn.jsdelivr.net/npm/-@0.0.1/

8.
FUN FACT
https://web.archive.org/web/20201118151234/https://www.npmjs.com/package/-

9.
- STORY
"I mean no harm to anyone in any way“
Parzhitsky told BleepingComputer, stressing the
package was fully compliant with npm's naming
rules at the time of its creation and created as a
test.
https://www.bleepingcomputer.com/news/software/empty-npm-package-
has-over-700-000-downloads-heres-why/

10.
- STORY
Parzhitsky agrees [...] that the unusually high
number of downloads can most likely be
attributed to developers making typos.

11.
ATTACKS ON LIBRARIES
• Typosquatting
• Dependency confusion
• Maintainer’s account takeover
• Phishing
• Expired domain
• Protestware

12.
TYPOSQUATTING
https://www.npmjs.com/package/electorn

13.
TYPOSQUATTING

14.
https://www.linkedin.com/in/andre-eleuterio/
https://www.npmjs.com/~andreeleuterio

15.
https://www.iqt.org/bewear-python-typosquatting-is-about-more-than-typos/

16.
DEPENDENCY CONFUSION

17.
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

18.
UAParser.js

19.
UAParser.js

20.
https://my.diffend.io/npm/ua-parser-js/0.7.28/0.7.29

21.
coa

22.
coa

23.
coa

24.
EXPIRED DOMAIN

25.
EXPIRED DOMAIN

26.
EXPIRED DOMAIN

27.
colors AND faker
https://my.diffend.io/npm/colors/1.4.0/1.4.44-liberty-2

28.
colors AND faker
https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-
breaking-thousands-of-apps/

29.
PROTESTWARE
https://www.npmjs.com/package/node-ipc

30.
PROTESTWARE
https://my.diffend.io/npm/node-ipc/10.1.0/10.1.1

31.
PROTESTWARE
https://api.ipgeolocation.io/ipgeo?apiKey=[cut]
./
../
../../
/
country_name
russia
belarus

32.
PROTEST
WARE
❤
❤

33.
PROTESTWARE
https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/

34.
ATTACKS ON LIBRARIES
• Typosquatting
• Dependency confusion
• Maintainer’s account takeover
• Phishing
• Expired domain
• Protestware

35.
Attacks on
tools
https://flickr.com/photos/danielmee/

36.
ATTACKS ON TOOLS
• Codecov
• Homebrew
• npm
• Ruby Gems

37.
On Thursday, April 1, 2021, we learned that
someone had gained unauthorized access to
our Bash Uploader script and modified it
without our permission.

38.
A customer reported this to us on the morning
of April 1, 2021.
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.

39.
https://gist.github.com/davidrans/ca6e9ffa5865983d9f6aa00b7a4a1d10

40.
The actor gained access because of an error in
Codecov’s Docker image creation process
that allowed the actor to extract the
credential required to modify our Bash
Uploader script.

41.
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/

42.
HCSEC-2021-12 - Codecov Security Event and
HashiCorp GPG Key Exposure
“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

43.
https://news.ycombinator.com/item?id=26819983

44.
HOMEBREW
18.04.2021
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/

45.
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.

46.
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.

47.
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/

48.
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.

49.
This vulnerability existed in the npm registry
beyond the timeframe for which we have
telemetry to determine whether it has ever been
exploited maliciously.
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.

50.
RUBY GEMS
https://github.com/rubygems/rubygems.org/security/advisories/GHSA-2jmx-8mh8-pm8w
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.

51.
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.
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.

52.
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.
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.

53.
Attacks on tools
• Codecov
• Homebrew
• npm
• Ruby Gems

54.
Attacks on
infrastructure
https://flickr.com/photos/quinnanya/

55.
ATTACKS ON INFRASTRUCTURE
• PHP
• Github, Heroku and Travis-CI

56.
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

57.
While investigation is still underway, we have
decided that maintaining our
own git infrastructure is an unnecessary security
risk, and that we will
discontinue the git.php.net server.
Instead, the repositories on GitHub,
which were previously only mirrors, will
become canonical.

58.
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.
Based on access logs, we can determine that the
commits were indeed pushed using HTTPS and
password-based authentication.
https://news-web.php.net/php.internals/113981

59.
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

60.
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.

61.
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/

62.
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.

63.
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.

64.
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.

65.
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

66.
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.

67.
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

68.
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.

69.
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.

70.
https://flickr.com/photos/143106192@N03/

71.
LIBRARIES

72.
LIBRARIES
• Awareness

73.
LIBRARIES
• Awareness
• No typos ;)

74.
LIBRARIES
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies

75.
LIBRARIES
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources

76.
LIBRARIES
• Awareness
• No typos ;)
• Use tools to detect malicious dependencies
• Download from official sources
• When not sure do not install

77.
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)

78.
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)

79.
TOOLS

80.
TOOLS
• I will not download and run scripts directly from the net

81.
TOOLS
• I will not download and run scripts directly from the net
• I will verify checksums and signatures of downloaded
files

82.
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

83.
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 already installed

84.
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 already installed

85.
INFRASTRUCTURE

86.
INFRASTRUCTURE
• Keep good inventory, especially of what is in the clouds

87.
INFRASTRUCTURE
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused

88.
INFRASTRUCTURE
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused
• Secure configurations

89.
INFRASTRUCTURE
• Keep good inventory, especially of what is in the clouds
• Disable/shutdown what’s unused
• Secure configurations
• Frequently update (to fix known issues)

90.
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

91.
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

92.
?
https://www.linkedin.com/in/molejarka/