Skip to content

Latest commit

 

History

History
370 lines (268 loc) · 14.1 KB

02-07-insecure_dependencies_and_configuration.md

File metadata and controls

370 lines (268 loc) · 14.1 KB
Raw

Insecure Dependencies

Common Mistakes

  • Not knowing used version of dependencies (client- and server-side)
    • Includes directly used components and nested dependencies
  • Used software is vulnerable, unsupported, or out of date
    • Includes OS, Web/Application server, DBMS, Applications, APIs, runtime environments and libraries
  • Lack of regular scans and bulletin subscriptions for vulnerabilities
  • Patch Management Process insufficient or missing
  • Component configuration not secured (see Insecure Configuration)

Variable Exploitability

  • Already-written exploits for many known vulnerabilities exist
  • Other vulnerabilities require a custom exploit (e.g. Zero Days)

Variable Impact

  • Full range of weaknesses is possible
    • RCE, Injection, Broken Access Control, XSS, etc.
  • Impact could be minimal, up to host takeover and data compromise

ℹ️ Some of the largest breaches to date have relied on exploiting known vulnerabilities in components (e.g. Equifax)

Risk Rating

Using Components with Known Vulnerabilities

Exploitability Prevalence Detecability Impact Risk
🔶 Average 🔴 Widespread 🔶 Average 🔶 Moderate A9
( 2 + 3 + 2 ) / 3 * 2 = 4.7

Prevention

  • Remove unused dependencies, unnecessary features, components, files, and documentation
  • Continuously inventory component versions and sub-dependencies
  • Continuously monitor CVE/NVD etc. for vulnerabilities
  • Subscribe to email alerts for security vulnerabilities related to components you use (especially when using commercial products)
  • Only obtain components from official sources over secure links
  • Prefer signed packages to avoid including a modified, malicious component
  • Monitor for unmaintained libraries and components
  • Monitor for components that do not create security patches for older versions
  • If patching is not possible, consider deploying a virtual patch
  • Ensure ongoing monitoring, triaging, and applying updates for the lifetime of the application or portfolio
  • Define and enforce the above in a Patch Management Process

OWASP Dependency-Check

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently, Java and .NET are supported; additional experimental support has been added for Ruby, Node.js, Python, and limited support for C/C++ build systems (autoconf and cmake). The tool can be part of a solution to the OWASP Top 10 2017 A9:2017-Using Components with Known Vulnerabilities.

Dependency Check Logo

Exercise 7.1 (:house:)

  1. Open the Sample Report of OWASP Dependency-Check
  2. Recommend an action plan for the assessed application
    • Distinguish between short term and long term actions
  3. Collect potential risks for a corporate-wide rollout of OWASP Dependency-Check in your company
  4. Collect possible mitigations for those risks

💡 If your company does not use any technology that could be assessed by OWASP Dependency-Check, simply perform the exercise pretending it actually could.

Exercise 7.2

  1. Download the /ftp/package.json.bak from your local Juice Shop
  2. Rename it into package.json and run npm audit. Follow the advise given in case of an error and then rerun it
  3. Check any subsequent error messages and get their root cause out of the way so you can run the audit successfully.
  4. After npm audit succeeds, read up on the listed vulnerabilities and use the most promising findings during Exercise 7.4

💡 After completing Exercise 7.4 your could also run npm audit on the (normally off-limits) package.json and /frontend/package.json files...

Insecure Configuration

Common Mistakes

  • Missing appropriate security hardening across application stack
  • Improperly configured permissions on cloud services
  • Unnecessary features are enabled or installed
  • Default accounts and their passwords still enabled and unchanged
  • Overly informative error messages (e.g. revealing stack traces)
  • Latest security features are disabled or not configured securely
  • No proper security headers or directives configured on server
  • Software is out of date or vulnerable (see Insecure Dependencies)

Potential Impact

  • Unauthorized access to
    • system data
    • functionality
  • Complete system compromise
    • e.g. by installing a web shell or backdoor

ℹ️ Especially information leakage from error message can often be useful to attackers in subsequent attacks like Injection or Privilege Escalation.

Risk Rating

Security Misconfiguration

Exploitability Prevalence Detecability Impact Risk
🔴 Easy 🔴 Widespread 🔴 Easy 🔶 Moderate A6
( 3 + 3 + 3 ) / 3 * 2 = 6.0

Web Shells

A web shell is a script that can be uploaded to a web server to enable remote administration of the machine. Infected web servers can be either Internet-facing or internal to the network, where the web shell is used to pivot further to internal hosts.

A web shell can be written in any language that the target web server supports. The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP. Perl, Ruby, Python, and Unix shell scripts are also used. [1]

Using network reconnaissance tools, an adversary can identify vulnerabilities that can be exploited and result in the installation of a web shell. For example, these vulnerabilities can exist in content management systems (CMS) or web server software.

Once successfully uploaded, an adversary can use the web shell to leverage other exploitation techniques to escalate privileges and to issue commands remotely. These commands are directly linked to the privilege and functionality available to the web server and may include the ability to add, delete, and execute files as well as the ability to run shell commands, further executables, or scripts. [1]

Shodan

Shodan is a search engine for Internet-connected devices. Web search engines, such as Google and Bing, are great for finding websites. But what if you're interested in measuring which countries are becoming more connected? Or if you want to know which version of Microsoft IIS is the most popular? Or you want to find the control servers for malware? Maybe a new vulnerability came out and you want to see how many hosts it could affect? Traditional web search engines don't let you answer those questions. [2]

Shodan Logo

Shodan gathers information about all devices directly connected to the Internet. If a device is directly hooked up to the Internet then Shodan queries it for various publicly-available information. The types of devices that are indexed can vary tremendously: ranging from small desktops up to nuclear power plants and everything in between.

So what does Shodan index then? The bulk of the data is taken from banners, which are metadata about a software that's running on a device. This can be information about the server software, what options the service supports, a welcome message or anything else that the client would like to know before interacting with the server. [2]

Areas of application for Shodan services

  • Network Security: keep an eye on all devices at your company that are facing the Internet
  • Market Research: find out which products people are using in the real-world
  • Cyber Risk: include the online exposure of your vendors as a risk metric
  • Internet of Things: track the growing usage of smart devices
  • Tracking Ransomware: measure how many devices have been impacted by ransomware [2]

Shodan Query Examples

❌ Search in Banner Data ("Google-style")
nordakademie
# = results with "nordakademie" in banner text
Search in Meta Data with filtername:value
hostname:nordakademie
# = results with "nordakademie" in host name

hostname:nordakademie product:apache -hash:0
# = Apache servers answering with non-empty banners

hostname:nordakademie http.component:php http.status:200
# = available (200 "OK") servers running PHP
Filtering for known vulnerabilities by CVE-ID
http.component:php vuln:CVE-2018-10547
# = Servers running PHP vulnerable to Reflected XSS on some error pages

⚠️ The vuln filter is only available to academic users or Small Business API subscription and higher.

REST and Streaming API

see https://developer.shodan.io/api

Literature Recommendations (optional)

Exercise 7.3

  1. Get an idea of the available Shodan query filters on https://developer.shodan.io/api/banner-specification
  2. Perform some Shodan searches for Internet-connected devices associated with your current employer (e.g. by hostname or ip)
  1. Use Mozilla Observatory to check the rating of at least one SSL configuration of your employer's hosts

ℹ️ Please consider ticking the "Don't include my site in the public results" checkbox before running the online scan!

Prevention

  • Repeatable hardening process
  • Development, QA & Production environments configured identically
    • but with different credentials used in each environment
  • No unnecessary features, components, documentation, and samples
  • Segmented application architecture
  • Sending security directives to clients, e.g. Security Headers
  • Regularly review and update configurations as part of the Patch Management Process (see Insecure Dependencies)

Exercise 7.4 (:house:)

  1. Persist a Stored XSS attack via the Contact Us page (:star::star::star::star:)
  2. Report the vulnerability which makes this XSS possible (:star::star::star::star:)
  1. Report another vulnerability that could be exploited in a Software Supply Chain Attack (:star::star::star::star::star:)

ℹ️ To report anything to the shop, you can use the "Customer Feedback" page. You have to supply as detailed information as possible.

Exercise 7.5 (:house:)

  1. Visit the Support Chat page and talk to the friendly bot
  2. Try asking it for product prices, deluxe membership our coupons
  3. Bully the chatbot until it gives you a coupon code (:star:)
  4. Analyze the source code of the chatbot and kill it (:star::star::star::star::star:)

Exercise 7.6 (optional)

  1. Read up on all vulnerabilities associated with JWT from the npm audit of the Juice Shop's leaked /ftp/package.json.bak
  2. Forge an essentially unsigned JWT token (:star::star::star::star::star:)
  3. Forge an almost properly RSA-signed JWT token (:star::star::star::star::star::star:)
  1. Report at least one of two typosquatting dependencies that the Juice Shop fell for (:star::star::star::star: - :star::star::star::star::star:)

Footnotes

  1. https://www.us-cert.gov/ncas/alerts/TA15-314A ↩ ↩2

  2. https://help.shodan.io/the-basics/what-is-shodan ↩ ↩2 ↩3