Open source vulnerabilities are in many applications. While finding them is critical, even more critical is remediating them as fast as possible. Securing your software supply chain is absolutely critical as attackers are getting more sophisticated in their ability to infect software at all stages of the development lifecycle, as seen with Log4j and Solarwinds. Hear from industry experts at our upcoming Meetup to to learn more about 3rd party vulnerabilities, threat research on real data, Red Teaming of your software supply chain and CVE Identification and Contextual Analysis.

2. Enso.security
Vulnerabilities through
DNS

3. About me
Chen Gour-Arie
Co-founder & Chief Architect @ Enso Security
I Live in Tel Aviv
I like to build things
Hacking applications since 2004

4. In this talk:
● Trusting names
● Fails
● Possible impact
● Mitigation

5. Why do we trust names so much?
The global Domain Name
System combined with the CA
backed Public Key Infrastructure is
the most scalable & mature trust
infrastructure the human kind has.
Domain Name
System
Public Key
Infrastructure

6. Why do we trust names?
● Decentralized name system - backed by
government.
● Authenticated by Decentralized
Certificate Authorities - independent
from government.
● Fully open cryptography
Domain Name
System
Public Key
Infrastructure

7. Building trust chian using layers:
Domain Name System
Public Key
Infrastructure
TLS: Authenticate the Server vs the Name
Browser security model -
Origin isolation
Email
validation
Domain validation
Enroll
S/P/IaaS
Enroll
PKI
Authentication, Identity federation and Resource sharing

8. Should we?
Epic Fail*
Nailed it* Fail

9. Reasons for failure
when trusting names
Reasons for failure
- Fails at the authority level
- Fails at DNS management
- Fails anywhere along the
chain

10. Failure - An authority is compromised
A trusted authority is compromised
Domain name system CA
Certificate validation*,
render attacks against
DNS largely ineffective
for web assets.**
- An identifiable and
recordable event
- Can still result in
high impact
breaches
* Especially with proper
extensions such as CSP and
HSTS.
** Other trust chain might not be
well protected .
2011

11. DigiNotar case:
- CA compromised
- DNS only domestically compromise
- Recovery was swift.
After more than 500 fake DigiNotar certificates
were found, major web browser makers reacted
by blacklisting all DigiNotar certificates.

12. Broken CA
Domain Name System
Public Key
Infrastructure
TLS: Authenticate the Server vs the Name
Browser security model -
Origin isolation
Email
validatio
n
Domain validation
Enroll
SaaS &
IaaS
Enroll
PKI
Authentication, Identity federation and Resource sharing

13. Broken Domain Name System
Domain Name System
Public Key
Infrastructure
TLS: Authenticate the Server vs the Name
Browser security model -
Origin isolation
Email
validation
Domain validation
Enroll
SaaS &
IaaS
Enroll
PKI
Authentication, Identity federation and Resource sharing

14. Fails at DNS management
DNS points to an asset out of controls
Dangling Record
Vulnerable
3rd Party*
A Record that points to
an IP no longer
controlled by the domain
owner
CNAME Record that
points to a record or web
resource out of control
A vulnerable web asset
from a 3rd party
operates within our
domain
* Only some vulnerabilities apply.

15. Bad Records
Domain Name System
Public Key
Infrastructure
TLS: Authenticate the Server vs the Name
Browser security model -
Origin isolation
Email
validation
Domain validation
Enroll
SaaS &
IaaS
Enroll
PKI
Authentication, Identity federation and Resource sharing

16. Failures anywhere along the trust chain
Building on layers of trust can
get tricky.
From the underlying
implementation of TLS, to CORS
setting, these chain of trust
could be compromised.

17. Possible impact
The most common: Breached
origin isolation in the web.
The notorious: Compromised
authentication subsystems.

18. Breached origin isolation
“Subdomain takeover”
A CNAME record pointing to an unclaimed web resource (such as
S3 bucket). The attacker can deploy malicious web content, that will
operate within the origin.
Dangling IP
An A record pointing to an IP that is not under the domain control.
XSS(+) in 3rd party integrated using DNS
Becomes XSS and open redirect in the subdomain.

19. Breached origin isolation
A malicious script in sub domain
- Dangling record pointing to a web server
controlled by the attacker
- XSS on 3rd party in the Domain
Impact
The script can read browser data in the sub domain.
The script can issue request from the sub domain - through the
browser.
Number of variables affects the ability to mount an effective
attack

20. Breached origin isolation
A malicious script on trusted origin
- Dangling record pointing to a web server
controlled by the attacker
Impact
The attacker can issue fetch requests and interact with
the permitting origin - through the browser

21. But of course, there are others.
Dangling NS
Someone builds some trust in another
domain, but ownership changed.
Dangling IP and CNAME
- Whitelisted, dengeling IP Records.
- DNS resolution checks bypass

22. Building trust based on DNS?
Ask: What happens when the
domain switch hands?

23. Reconnaissance and
Remediation
Inventory Assets
Know your domain and the
systems which operate within
it.
Secure design - Protect
origin isolation
Build the right controls to avoid
implementation errors.

24. Inventory Web Assets
Track all records managed in the
DOMAIN.
Eliminate dangling records
Shutdown SSL termination
And consider claiming all referred resources
Find
- Records pointing to abounded IP
addresses
- CNAME records pointing to 3rd
parties

25. Inventory Web Assets
Track all Web Resources in the
DOMAIN.
Find
- Allowed origins in your domain
- 3rd party applications integrated
in the domain
Assess
- Domain and Subdomain
takeover in allowed origins
- Security posture of integrated
3rd parties

26. Extended threat model when
allowing other origins
Ask: what happens when the owner
changes?
Protect Origin Isolation
Use Content-Security-Policy
Block and monitor alien content in your
websites
Use Strict-Transport-Security
Always require HTTPS
Implement compatible server checks
Always check origin and content type
Pay attention to CORS settings
Apply the Principle of Least Privilege to
external origins
Be explicit with cookies
Limit cookies scope (domain and path)
and use safe flags (samesite, secure,
httponly)

27. Conclusion
DNS effects origin isolation
Inventory and systematically check all records
- DNS setting change constantly!
Lead a process to build layers of strong origin
isolation.
Extended threat model
For features that build on domain validation
(including email validation), consider what
happens when the domain switches hands.

28. Enso.security
Discover
Autonomously discover and profile
applications, identify owners and
technology
Measure
Measure coverage and performance of
application security controls
Manage
Automate workflows to enforce a unified,
sustainable AppSec policy across all
assets
Enso - Application Security Posture Management
Software security groups can scale and gain complete visibility and
coordinate their tools, people and processes
Thank you!

29. Enso.security
Check out appsecmap.com

30. DETECTION AND PREVENTION OF
MALICIOUS PACKAGES AND ATTACKS
Jonathan Sar Shalom
Director of Threat Research, JFrog Security

31. Jonathan Sar Shalom
Director of Threat Research, JFrog Security

32. Agenda
32
▪ The software supply chain security problem
▪ Malicious packages infection methods
▪ Common payloads used in malicious packages
▪ Detecting malicious packages
○ Known and unknown
○ Best practices for secure development

33. A technique in which an adversary slips malicious code or an entire
malicious component into a trusted piece of software or hardware.
Software Supply Chain attacks
▪ In modern software development, applications integrate 3rd party code
▪ This code is delivered in a software component through a supply chain
▪ This is a good practice!
▪ Applications trust the 3rd party to supply secure code
▪ In reality this practice involves some danger
○ Vulnerabilities
○ Malicious code
▪ These threats are delivered through the supply chain with the software components
▪ Affecting all end products that depend on them

34. Software Supply Chain attacks
▪ High spread attack
▪ Low effort compared to an
exploitation of a vulnerability
▪ Low technical skills required
▪ There is a trust in the relationship
between parties that can be
abused
Why would an attacker
go for this approach?

35. Backdoor Malicious payload code
Software Supply Chain threat types
Security bug
Intentional
Vulnerability
Malicious
Components
Unintentional
Vulnerability
CVEs
Not a CVE

36. Real life examples
Unintentional bug (CVE) caused by an OSS vendor
Intentional vulnerability(CVE) Intentional
Malicious component (A CVE is usually not assigned)

37. Malicious packages infection methods

38. Infection methods
38
How attackers cause malicious packages to get installed in practice
▪ Typosquatting
▪ Masquerading
▪ Trojan package
▪ Dependency confusion (Namesquatting)
▪ Hijacking

39. Infection methods - Typosquatting
39
▪ Obtaining (or “squatting”) a popular name with a slight typographical error
▪ Applies to many different resources, such as web pages, executable names, and software
package names
▪ A classic example – registering the domain name “gogle.com”
▪ Some maintainers take an active role and reserve “Typosquatting-prone” names

40. Infection methods - Typosquatting
40

41. Infection methods - Masquerading
41
▪ Impersonating a well-known package
▪ Duplicating both the code and the metadata
▪ Adding a small piece of malicious code to this duplicate
▪ Essentially building “trojan” packages

42. Infection methods - Masquerading
42

43. Infection methods - Masquerading
43
▪ Comparing the malicious package code with the original package
▪ The only difference from the original package is one line which contains obfuscated malicious code

44. Infection methods - Trojan package
44
▪ Publishing a real functional package
▪ Hiding a malicious code inside it
▪ Usually the malicious code is small and obfuscated

45. Infection methods - Dependency confusion
46
▪ Most package managers do not distinguish between internal packages and external ones
▪ An attacker would find an internal package name and publish it in an external public repository
(such as npm / PyPi)
▪ Default package manager configurations will prefer a high version number regardless to the source
▪ Alex Birsan used this technique to attack tech giants such as Netflix, Apple, Microsoft

46. Infection methods - Dependency confusion
47
From the blog “Malicious npm Packages Are After Your Discord Tokens – 17 New Packages Disclosed”
https://jfrog.com/blog/malicious-npm-packages-are-after-your-discord-tokens-17-new-packages-disclosed/

47. Infection methods - Hijacking
48
▪ Taking over a legitimate known package and pushing malicious code into it
▪ Possible hijacking techniques:
○ Using hacked maintainers’ accounts
○ Injecting hidden or obfuscated malicious code as part of a seemingly legitimate code contribution
▪ A notable example - “ua-parser-js” package:

48. Infection methods - Hijacking - Protestware
49
▪ Hijacking your own project for protest (Protestware)
○ faker & colors
■ The developer added an infinite loop
■ Protest against corporations that use open source but do not give back
○ node-ipc
■ 3 months ago the developer added a code that causes total filesystem corruption
■ Malicious payload runs only on Russian and Belarusian machines
■ Protest against the 2022 Russian invasion of Ukraine

49. Infection methods - Hijacking - Domain takeover
50
▪ npm package can have multiple maintainers
▪ What if the “somedomain.sh” domain expires?

50. Infection methods - Hijacking - Domain takeover
51
▪ Our analysis on the npm ecosystem
▪ 3000+ packages potentially vulnerable

51. Common payloads

52. Common payloads
53
▪ Sensitive data stealers
○ Credit cards
○ Discord user tokens
○ Environment variables
○ Browser-saved passwords and OS passwords
▪ Connectback shell
▪ Download and execute
▪ Cryptominer

53. 54
Common payloads - Sensitive data stealers
54
Stealing credit card information from browsers’ saved data
From “noblesse” malicious package deobfuscated payload code
conn = sqlite3.connect("CCvault.db")
conn.execute("SELECT * FROM credit_cards)
Stealing passwords from browsers’ saved data
login_db = os.environ['USERPROFILE'] + ... +
Login Data'
cursor.execute("SELECT action_url,
username_value, password_value FROM logins")

54. Common payloads - Sensitive data stealers
56
▪ Stealing environment variables
AWS CLI secret access keys are kept in environment variables

55. Common payloads - Connectback shell
57
▪ Connecting back to the attacker’s server
▪ Receiving commands to execute
▪ Sending back the execution results to the server
From “hpid/hipid” malicious packages payload code

56. Common payloads - Download and execute + Cryptominer
58
▪ Utilization of the victim's system resources for cryptocurrency mining
▪ Downloading and executing a cryptominer
From “hpid/hipid” malicious packages payload code

57. Detecting malicious packages

58. Detecting known malicious packages
66
▪ Scanning the project’s dependencies
▪ Detecting installed software and versions (SBoM)
▪ Fetching security information from public repositories
○ Problem - Many repositories don’t save historical data!
■ PyPi - malicious packages are being removed
■ npm - malicious packages are replaced with dummy code
▪ Solution - use a software composition analysis (SCA) tool that detects malicious packages
■ Security auditing tools report vulnerabilities only

59. Detecting a malicious package using Xray
67

60. Detecting unknown malicious packages
68
▪ Automatic heuristic scanners we use in JFrog Xray
○ Infection methods detectors
■ Typosquatting - similarity between names
■ Masquerading
■ Dependency confusion
■ DNS generation
○ Payloads detectors
■ Download and execute
■ Dynamic code evaluation
■ Shell spawning
■ Sensitive files read/write
○ Obfuscation techniques detectors

61. Best practices for secure development
69
▪ Use a software composition analysis (SCA) tool as part of your SDLC
▪ Define policies and automate actions as part of a DevSecOps process
▪ Other useful practices
○ Configure your build system to exclude remote repos for internal packages
■ https://jfrog.com/blog/going-beyond-exclude-patterns-safe-repositories-with-priority-
resolution/
○ Use strict versions for external dependencies for every build
■ https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json
▪ Pyrsia
○ An open-source initiative for creating a secure, distributed p2p packages repository
○ Provides integrity of software components using blockchain
○ Enables organizations to establish a chain of provenance for open source components
○ Read more on pyrsia.io

62. Best practices for secure development
70
▪ Leverage open source tools
○ pypi-scan for typosquatting detection - https://github.com/IQTLabs/pypi-scan
○ piproxy - https://jfrog.com/blog/python-wheel-jacking-in-supply-chain-attacks/
○ Dependency confusion checker - https://github.com/visma-prodsec/confused
○ npm-domain-check - https://github.com/jfrog/npm_domain_check
■ Detect your npm dependencies that can be hijacked with domain takeover
○ jfrog-npm-tools - https://github.com/jfrog/jfrog-npm-tools
■ npm-secure-install - validates versions lockdown
■ package-checker - detects the safest package version to use
■ npm_issues_statistics - analyzes Github issues and alert on unusual activity

63. Questions?
jonathanss@jfrog.com
Find more on https://research.jfrog.com/

64. THANK YOU!

66. Security Researcher
AV Bypass Techniques Book Author
Founder of MalwareAnalysis.co
Red Team Tech Leader @ABInBev
whoami/# Uriel

78. Threat
Intelligence
Red Team
Adversary
Simulation

79. Adversary
Simulation
Blue Team
Better
Security &
Monitoring

83. Reconnaissance
• Developers, QA, DevOps
• Code Repos, Pipeline Products
Credential Access
• Publicly Exposed Credentials, Phishing – Access to Organizational
Computer
• Cookies/Sessions Stealing – Access to a Git repo
• Credentials Dumping – Access to other relevant systems
Discovery & Deploy
• Situational Awareness – Permissions and Controls
• Access to code repositories, commit history
• Discovery of code injection/commit entry-point

95. Enhancing CVE Identification
using Contextual Analysis
Shachar Menashe
Senior Director Security Research, JFrog Security

96. Shachar Menashe
Senior Director Security Research, JFrog Security

97. AGENDA
106
Basic CVE evaluation
Real-world exploitation prerequisites
● Code
● Configuration
● Environment
Tips for deep CVE evaluation
Q&A

98. Basic CVE evaluation
107
▪ Let’s define a basic CVE evaluation as follows
○ Determine all software components in the image
○ Determine version of each software component
○ Populate CVEs based on component name + version
▪ This is the approach taken by almost all SCA tools
▪ Can use public data to achieve this
○ NVD “CPE”
○ GitHub (GHSA) “package”
○ Red Hat OVAL
○ and many more…

99. Basic CVE evaluation
108
▪ If we have the entire container/server image -
How can this be improved?
▪ Let’s look at the hidden data not revealed by the CPE

100. Code Prerequisites?
109
▪ Let’s look at CVE-2021-23337 as an example
▪ Is the vulnerability exploitable in any machine that matches the CPE?
○ (AKA - an “old enough” version of lodash is installed)

101. Code Prerequisites!
110
▪ The answer is NO - there must be 1st party code that -
○ Imports lodash
○ Uses the template function
○ Passes attacker-controlled input to a specific
argument of template
▪ The last condition is extremely non-trivial
▪ In this case the function is explicitly specified in the CVE
(not trivial!)
○ No CVE-formatted field for this
▪ This prerequisite is true for almost all CVEs in libraries
▪ There must exist code that uses the library in a
vulnerable way

102. Code Prerequisites - Examples
111
▪ There could be many code-based prerequisites
▪ Was the vulnerability backport-patched? (custom patch)
▪ Is the vulnerable function called?
○ With specific attacked-controlled/static arguments?
▪ Is there use of a different function which mitigates or negates the vulnerability?
○ Ex. calling a SQL-Injection-Sanitization function before calling a function vulnerable
to SQLi
▪ Is there 1st-party code that inherits a vulnerable class?

103. Configuration Prerequisites?
112
▪ Now, Let’s look at CVE-2021-44521
▪ A daemon (not library) vulnerability
▪ Is the vulnerability exploitable in any machine that matches the CPE?

104. Configuration Prerequisites!
▪ The answer is NO - the Cassandra daemon must run with
a specific configuration (YAML file) -
○ enable_user_defined_functions: true
○ enable_scripted_user_defined_functions: true
○ enable_user_defined_functions_threads: false
▪ The configuration is explicitly specified in the CVE
(extremely rare)
○ Again, no CVE-formatted field
○ Is this a default configuration?
▪ This prerequisite is true for many clients/daemons
○ Default config is usually heavily audited
113

105. Configuration Prerequisites - Examples
114
▪ There could be many configuration-based prerequisites
▪ Was the component built with support for the vulnerable code?
○ ex. Compiler build flags (-DOPENSSL_WITH_RC4)
○ Very common in Linux kernel vulnerabilities
▪ Is the component configured to take advantage of a patch/workaround?
▪ Is the relevant configuration passed via -
○ Environment variables?
○ Command-line arguments?
○ Configuration file?
■ Hardcoded path?
■ Path passed through command line argument?

106. Environment Prerequisites?
115
▪ As a final example, let’s look at CVE-2022-26612
▪ Another daemon vulnerability
▪ Is the vulnerability exploitable in any machine that matches the CPE?

107. Environment Prerequisites!
▪ The answer is NO - the Hadoop daemon must run
specifically under Windows
○ (and not Linux)
▪ In this case, due to different code branches for each
environment
▪ The environment is explicitly specified in the CVE (less
rare)
○ But, no CVE-formatted field
▪ This prerequisite is rarer, since usually the vulnerable
code affects all supported environments
116

108. Environment Prerequisites - Examples
117
▪ There could be many environment-based prerequisites
▪ Are we running the vulnerable OS?
○ Type (Windows / Linux / macOS)
○ Distro
○ Bitness (32 vs 64)
▪ Is the vulnerable process even running?
○ On startup?
○ Triggered by an internal/external event?
▪ Is the daemon’s vulnerable port blocked by a firewall?
▪ Is the specific vulnerable binary from the entire package present?
▪ Does the vulnerable binary have special privileges?
○ Ex. For local privilege escalations, root-SUID

109. False positives due to CVEs
118
▪ Safe to say that in general, a CVE will not be exploitable in the default configuration without any
context
▪ For library vulnerabilities - there must be code that uses the library in a vulnerable way
▪ For client/daemon vulnerabilities - the default configuration and context is audited to a much higher
degree
▪ Therefore - “package is installed” CVE evaluation is extremely prone to FPs

110. Tips for deep CVE evaluation
119
▪ On library vulnerabilities - look for which functions are vulnerable and the values of their args
○ Are the invocations of these functions with these arguments rare? Or a common case?
▪ On client/daemon vulnerabilities - look for the specific configuration of the target, is it a default
configuration?
▪ Vulnerabilities with “High” Attack Complexity (AC) usually means exploitation is context-dependent, try
to understand the specific context
○ A specific function must be called?
○ Attacker needs to know target-specific information? (ex. which endpoint to attack)

111. Questions?
shacharm@jfrog.com

112. Thank you!
For more info - “Xray Contextual Analysis”

113. On July 18, Yalla DevOps 2022, a 1-day, in-person DevOps event will be happening
at the beautiful 5-Star Hilton Tel Aviv. This will be an amazing full day of hands-on
community sessions from industry experts, and you’ll also learn how to level up your
skills with DevOps security practices, modern CI/CD, package management,
software distribution, and device update management. One of the security sessions
will be from Aviram Shmueli, CPO & Co-Founder at Jit who will be sharing on What
Product Security Really Means - From Theory to Practice. We will also have other
speakers from organizations like Microsoft, Riskified, UP9, and many more. We will
then end the day with a wonderful Happy Hour as well.
So don’t miss an amazing day. Scan the QR Code and Register at Yalla-
DevOps.com and use code “Meetup5” for a 5% discount off our published price.

114. s://www.Yalla-DevOps.com
count Code: Meetup5