Day 22 of Advent of cyber 2023!

Backstory:

As the elves work diligently to restore the compromised servers, McSkidy's SOC team detects unusual activity, pinpointing a significant data transfer to an unidentified server previously identified on Day 9. It appears that an insider has illicitly established a malicious backdoor. Seeking assistance, McSkidy has reached out to Detective Frost-eau from law enforcement to collaborate on dismantling the command and control server. Can you aid Detective Frost-eau in this endeavor?

Learning Objectives

  • Understanding server-side request forgery (SSRF)

  • Which different types of SSRF are used to exploit the vulnerability

  • Prerequisites for exploiting the vulnerability

  • How the attack works

  • How to exploit the vulnerability

  • Mitigation measures for protection

Understanding SSRF: A Security Vulnerability

Overview: SSRF, or Server-Side Request Forgery, is a critical security vulnerability where attackers manipulate a web application into making unauthorized requests to internal or external resources on the server's behalf. This can lead to severe consequences such as data exposure, unauthorized actions, and potential compromise of the application.

Implications of SSRF: Leaving web applications vulnerable to SSRF can result in unauthorized access to internal systems, remote code execution (RCE), data breaches, or further compromise of the application's security.

Types of SSRF Attacks:

  1. Basic SSRF: In a basic SSRF attack, the attacker crafts a request from the vulnerable server to internal or external resources, attempting to access files, services, or databases not intended for public access.

  2. Blind SSRF: In a blind SSRF attack, the attacker infers information about the internal network by measuring the server's response time or observing changes in error messages, without directly seeing the response to the request.

  3. Semi-Blind SSRF: In semi-blind SSRF, the attacker does not receive direct responses in their browser or application. Instead, they rely on indirect clues, side-channel information, or observable effects within the application to determine the success or failure of their SSRF requests.

Prerequisites for Exploitation:

  • Vulnerable Input Points: Web applications must have input fields susceptible to manipulation, such as URLs or file upload functionalities.

  • Lack of Input Validation: The application should lack sufficient input validation or effective sanitization mechanisms, allowing attackers to craft malicious requests.

How SSRF Works:

  1. Identifying Vulnerable Input: The attacker locates an input field within the application that can be manipulated to trigger server-side requests, such as a URL parameter in a web form, an API endpoint, or request parameter input like the referrer.

  2. Manipulating the Input: The attacker inputs a malicious URL or other payloads that cause the application to make unintended requests. This could include a URL pointing to an internal server, a loopback address, or an external server under the attacker's control.

  3. Requesting Unauthorized Resources: The application server, unaware of the malicious input, makes a request to the specified URL or resource. This request could target internal resources, sensitive services, or external systems.

  4. Exploiting the Response: Depending on the application's behavior and the attacker's payload, the response from the malicious request may provide valuable information, such as internal server data, credentials, system information, or pathways for further exploitation.

Navigating the API Page: Identifying SSRF Opportunities

Discovery: While exploring the web page, McSkidy stumbled upon a documentation link at the page's bottom. Clicking on this URL redirects to the API endpoint, providing valuable information for potential SSRF attacks.

API Endpoint Exploration: Examining the API page, a notable endpoint is identified: http://MACHINE_IP/getClientData.php?url=http://IP_OF_CLIENT/NAME_OF_FILE_YOU_WANT_TO_ACCESS. This endpoint, taking a URL as a parameter, retrieves files from the specified agent. A crucial observation is that altering the URL parameter allows attempted access to different files.

Exploiting File Access: By experimenting with the URL parameter, McSkidy discovers that modifying it to reference other files on the host, like http://MACHINE_IP/getClientData.php?url=file:////var/www/html/index.php, enables fetching the contents of the targeted file, in this case, index.php.

Understanding File: Scheme: The file: scheme in a URL typically references local files on a system. This SSRF scenario exposes the potential risk of accessing critical files, such as configuration files (config.php) or connection strings, like /etc/passwd, enabling control over the Command and Control (C2) panel.

C2 Panel Access: Exploiting the file: scheme, an attacker gains access to the C2 panel's credentials by retrieving the file containing the password. This breach facilitates successful login to the C2 panel, posing a significant security threat.

Mitigation Measures: SSRF Prevention Strategies

To counter the risks associated with SSRF, the following mitigation measures are recommended:

  1. Strict Input Validation and Sanitization: Employ rigorous input validation and sanitization practices to thwart malicious input attempts.

  2. Allow Lists for Access Control: Implement allow lists to control which domains and IP addresses the application can access, enhancing control over data flow.

  3. Network Segmentation: Apply network segmentation to confine requests solely to authorized resources, limiting the scope of potential SSRF exploits.

  4. Principle of Least Privilege: Adhere to the principle of least privilege, granting minimal permissions necessary for system operations, reducing the impact of potential security breaches.

By incorporating these measures, organizations can fortify their systems against SSRF vulnerabilities and bolster overall cybersecurity.

Question : Is SSRF the process in which the attacker tricks the server into loading only external resources (yea/nay)?

Answer: Yay

Question: What is the C2 version?

Answer: 1.1

Question: What is the username for accessing the C2 panel?

Answer: mcgreedy

Question: What is the flag value after accessing the C2 panel?

Answer: THM{EXPLOITED_31001}

Question: What is the flag value after stopping the data exfiltration from the McSkidy computer?

Answer: THH{AGENT_REMOVED_1001}