cdelafuente-r7 (78)

This is a local file inclusion vulnerability that affects the external links page link.php. When chained with CVE-2023-49084, a SQL injection vulnerability in the pollers.php script, an attacker can achieve remote code execution. It requires to be authenticated with specific permissions to exploit the SQL injection, but if these conditions are met, an attacker can update the database and exploit this vulnerability.

The attack consists in creating an external link entry in the database that points to the Cacti log file and setting all the permissions needed to access it. Then, the attacker just has to inject a stager payload the logs, which will be triggered when the external link page is requested. A Metasploit module exists for this.

Since this vulnerability requires an user account setup with specific permissions, the risk is lowered. However, remote code execution is still considered a serious issue and should be patched as soon as possible. A fix has been released with version 1.2.26.

This is a blind SQL injection in the poller device management page (pollers.php), which can be exploited with time-based techniques. Even if the exploitation is a bit more complex, the attacker can have full control of the database and can read, update, insert and delete anything. For example, the user_auth_realm table can be updated to grant administrative privileges. Also, it is possible to chain this vulnerability with CVE-2023-49084 and get remote code execution. A Metasploit module exists for this.

The risk is reduced because the attacker needs to be authenticated with permissions to access the pollers page. This is granted by setting the Sites/Devices/Data permission in the General Administration section. That being said, even if Cacti is usually not exposed to the internet, it is a serious issue and should be patched as soon as possible. A fix has been released with version 1.2.26.

This is a path traversal vulnerability in Ivanti Avalanche version 6.3.4.153. It is not clear if prior versions are also vulnerable. An unauthenticated attacker can leverage it to access any files under C:\PROGRAM DATA\Wavelink\AVALANCHE\Web webapps\AvalancheWeb\ directory, by requesting the following URL:

http(s)://<domain>/AvalancheWeb//faces/javax.faces.resource/<file>?loc=<directory>

For example, to access the web.xml configuration file, this request can be sent:

http(s)://<domain>/AvalancheWeb//faces/javax.faces.resource/web.xml?loc=../WEB-INF

However, the file extensions allowed to be accessed this way are quite limited. The advisory says only .xml, .html and potentially a few others, depending on the .htaccess rules. That being said, this is still an information disclosure issue that could reveal internal settings and be used by other potential attacks (e.g. the deployment descriptor file web.xml).

The advisory also describes a scenario where one could use a debug feature that performs a memory dump of the Avalanche process for debugging purposes. The memory dump file is stored under a path accessible by this path traversal and could reveal sensitive information the process had in memory when the dump was requested, such as credentials of users that had logged into the application. Note that this feature is only available to users with administrative privileges, which means the attacker needs to be authenticated with these privileges or an administrator has already performed a memory dump and left the file around.

So, it is important to patch this as soon as possible, but I don’t think this is critical.

This vulnerability enables a low-privileged user to escalate privileges in a default Active Directory environment with the Active Directory Certificate Services (AD CS) installed. AD CS servers is Microsoft’s public key infrastructure (PKI) implementation, which enables the issuing of certificates. Since AD CS is coupled with Active Directory, certificates can be used to authenticate against the KDC via the PKINIT Kerberos extension. The identity of a domain computer account is provided by the DNS name in the certificate.

The owner of a computer account has write permission on the computer dNSHostName property. As a result, it is possible to set it to any existing DNS host name in the domain, which will be the DNS host name in the issued certificate. This certificate can then be used to authenticate against the KDC.

In order to achieve privilege escalation, the DNS host name is set to a valid Domain Controller (DC) host name, resulting in a successful authentication as the DC account. Being able to authenticate as the DC account gives enough privileges to impersonate a Domain Administrator.

Here is a common exploitation workflow:

1. Using a low-privileged domain account, create a new computer account in the Active Directory. Note that any domain user is allowed to do so, as long as the user’s ms-DS-MachineAccountQuota property is greater than 0 (set to 10 by default).
   
2. Set the newly created computer dNSHostName attribute to match the DC DNS host name.
   
3. Request a certificate for this computer.
   
4. Authenticate as the DC account with this certificate.
   
5. Request a Service Ticket (TGS) impersonating a Domain Administrator account.
   

This attack has been fully automated in a Metasploit module (still a WIP as time of writing). The resulting TGS can be used by any Metasploit module and external tools to impersonate a Domain Administrator.

Microsoft released a patch on May 10, 2022.

This is an arbitrary code injection vulnerability caused by unsanitized user input in a call to the PHP eval() function.

...
else if($type[0] == "php")
{
    $setting['optionscode'] = substr($setting['optionscode'], 3);
    eval("\$setting_code = \"".$setting['optionscode']."\";");
}
...

To trigger the vulnerability and achieve remote command execution, an attacker will have to create a crafted configuration setting with the payload and send a second request to trigger the execution. A Metasploit module, based on the original PoC, is available.

Note that authentication to Admin CP is required for this exploit to work and the account must have rights to add or update settings. Also, since the user running PHP is usually a non-privileged user, the exploit won’t get you privileged access.

This vulnerability is one of the three Windows RPC related issues that were fixed in Microsoft’s April 2022 Patch Tuesday. Compared to CVE-2022-24492 and CVE-2022-24528, this one does not require user interaction. It also has the highest CVSS score (9.8) and severity (Critical). Unpatched systems that expose port 445/TCP are potentially vulnerable to Remote Code Execution. This is more likely something that would happen on an internal network, since this port is usually not exposed to the Internet (well, it should not). This bug would be very interesting for any attacker that has gained access to the internal network and needs to move laterally.
According to this article, the issue seems to be an integer overflow bug. Patch diffing reveals that many calls to some kind of sanitizing function have been added. This function checks if an integer value is still in the expected range after some arithmetic operations and should avoid a potentially heap buffer overflow. These checks have been added in multiple locations, both on RPC client-side and server-side of the execution flow.

This vulnerability is similar to the Gitea vulnerability identified as CVE-2020-14144 (Gitea is a fork of Gogs). Please refer to this assessment for details. At the time of writing, no mitigation has been implemented in Gogs. So, it is highly recommended to set the DISABLE_GIT_HOOKS configuration setting to true to completely disable this feature and prevent all users (including admin) from creating custom Git hooks. It is a serious security risk.

If a Gitea user is allowed to create Git hooks, which is the default for administrators, code execution on the server through the web interface is possible. Note that this privilege can also be granted to a non-administrative user.

Git hooks are scripts that are executed before or after an event such as push, commit, etc. Allowing a user to create such scripts is potentially dangerous and should be avoided as much as possible.

A new Metasploit exploit module that leverages this insecure setting has been added recently. It enables an attacker to remotely execute arbitrary code if he has access to an account with permission to create Git hooks. For this, it simply creates a new repository, sets a post-receive Git hook containing the malicious code and adds a dummy file to the repository to trigger code execution.

It has been mitigated in version 1.13.0 by setting the Gitea DISABLE_GIT_HOOKS configuration to true by default. This completely disables the Git hook creation feature and prevents all users (including admin) from creating custom Git hooks. Administrators will need to think twice before changing it back to false, since it is a serious security risk.

An exploit module that leverages both this authentication bypass and a directory traversal vulnerability identified as CVE-2021-25282 has been added to Metasploit recently. It allows an attacker to execute commands remotely on the master as the root user.

This module takes advantage of a Maintenance Process Check that is executed every 60 seconds by default. This process reloads and executes all the grains on the master, including custom grain modules in the Extension Module directory. Code execution is achieved by sending a request to the wheel_async client, abusing the directory traversal issue in the path parameter, as described in @kevthehermit’s assessment. A malicious Python script is placed in the Extension Module directory (default is /var/cache/salt/master/extmods/), waiting for the Maintenance Process Check to execute it.

Note that this attack can leave some traces in logs if the log level is set to debug or trace.

This is a post-authentication arbitrary file write vulnerability that has been actively exploited. Now, an exploit module has been added to Metasploit, which leverages both the Server-Side Request Forgery vulnerability identified as CVE-2021-26855 and this arbitrary file write vulnerability. The SSRF is mainly used to retrieve internal information such as the user SID, session ID, canary value, etc. It also allows bypassing authentication to exploit CVE-2021-27065 and creates a custom .aspx web page that embeds a web shell. Once this backdoor is planted, the module uses it to stage the actual payload and execute it.

Note that, for this exploit to work, two Exchange Servers are needed. One is the host the module directly sends requests to and the other server is the internal resource the SSRF targets. The Exchange Admin Center (EAC) web interface, usually located at https://<ServerFQDN>/ecp, needs to be accessible on at least one server. Also, the email address of an Administrator on the Exchange server needs to be provided to the module. It is not really something difficult to obtain, as long as you know the name of an admin and the email pattern used internally.

Three modules exploiting this vulnerability have been added to Metasploit:

1. A scanner module that checks if the target is vulnerable to this Server-Side Request Forgery.
   
2. An auxiliary module that dumps the mailboxes for a given email address, including emails, attachments and contact information.
   
3. An exploit module that leverages an unauthenticated Remote Code Execution. This allows execution of arbitrary commands as the SYSTEM user. This module takes advantage of the same SSRF vulnerability and also of a post-auth arbitrary-file-write vulnerability identified as CVE-2021-27065.
   

The auxiliary module (2) leverages this SSRF to retrieve the internal Exchange server name and query the Autodiscover service to retrieve other internal data. All of this is done without authentication through the Exchange Admin Center (EAC), usually located at https://<ServerFQDN>/ecp, so it needs to be accessible. It finally POSTs to the EWS endpoint to dump emails, contacts, etc. Note that this exploit needs at least two Exchange servers to work. One is the host the module directly sends requests to and the other server is the internal resource the SSRF targets.

The exploit module (3) follows the same workflow but retrieves extra information such as the user SID, session ID, canary value, etc. Then, still using the SSRF, the module exploits the arbitrary-file-write vulnerability (CVE-2021-27065) to create a custom .aspx web page that embeds a web shell. Finally, once this backdoor is planted, it uses it to stage the actual payload and execute it. Note that, for this exploit to work, the email address used needs to be the email address of an Administrator on the Exchange server. It is not really something difficult to obtain, as long as you know the name of an admin and the email pattern used internally.

Accellion’s legacy File Transfer Appliance (FTA) is an application to transfer large files securely. It is a 20-year-old product and will reach End of Life on April 30, 2021. Accellion recommends to migrate to kiteworks, its enterprise content firewall platform. According to this post, the SQL injection vulnerability is the starting point of a series of attacks against multiple organizations. This post reports that this vulnerability has been actively exploited since mid-December 2020 and is related to an ongoing ransomware campaign.

This SQL injection vulnerability enables an unauthenticated remote attacker to retrieve data from the database by sending specially crafted requests to the document_root file. Especifically, it has been exploited to retrieve a key that led to the installation of a web shell on the appliance. This web shell was then used to download sensitive data from the FTA internal database.

Due to the nature of this application, the data available is likely to be very sensitive and exploiting this vulnerability would lead to a critical information leak. As an emergency mitigation, external access to any vulnerable FTA should be shut down. However, this won’t block attacks coming from the internal network. It is highly recommended to patch to the latest version and to consider migrating to kiteworks.

Sudo is vulnerable to a local privilege escalation that enables any local user to gain root privileges. This is due to a heap-based buffer overflow when unescaping backslashes in the command’s arguments. This vulnerable code has been introduced in July 2011. According to the advisory, legacy versions from 1.8.2 to 1.8.31p2 and stable versions from 1.9.0 to 1.9.5p1 are vulnerable in their default configurations. Note that the local user password is not required to successfully exploit this vulnerability.

The exploitation is done by invoking “sudoedit -s” command to reach the vulnerable code and do an out-of-bounds write in heap memory. The security researchers were able to exploit this vulnerability and get a shell as root using 3 different methods. One of them, which seems to be the easiest and the most reliable, is demo’ed in this video.

I couldn’t find any PoC available, but there are enough technical details in the advisory to write an exploit. It is a critical bug and sudo should be patched immediately. It is very likely a working exploit will be publicly available soon.

No useful information has been published so far and most of the speculations found online are based on the CVSS 3.0 metrics found in the advisory. That said, the attack vector seems to be Local but can be exploited remotely, which means that some kind of malicious file needs to be placed locally to be scanned by Windows Defender and trigger the vulnerability. After talking about this with @smcintyre-r7 and @bwatters-r7, we can imagine that Remote means this file needs to be sent remotely somehow, for example, using a file upload in a website or an email attachment via Exchange.

Some considerations to keep in mind: Windows defender vulnerabilities get patched immediately and automatically, without user interactions. So, the exploitation window is very short. Finally, even if the exploitation succeeds, the evasion will be problematic, since the anti-virus will probably detect the attack.

SpamTitan Gateway is an anti-spam appliance that protects against unwanted emails and malwares. Versions 7.01, 7.02, 7.03 and 7.07 are vulnerable to Remote Code Execution as root due to improper input sanitization. Note that only version 7.03 needs authentication and no authentication is required for versions 7.01, 7.02 and 7.07.

The attack consists in abusing the SpamTitan Gateway UI SNMP Management Settings feature to inject dangerous SNMPD command directives into the SNMP server configuration file. This is can be done in two steps:

1. Send an HTTP POST request to the snmp-x.php page with a specially crafted community parameter:
   ...[SNIP]...&community=<community>" <ip>\nextend <random name> <payload>.
   This will end up being added to snmp.conf like this:
   …[SNIP]...
rocommunity "<community>" <ip>
extend <random name> <payload>
…[SNIP]...
   
2. Send an SNMP Get-Request to correct OID to trigger the payload.
   

Since a proof o concept and a Metasploit module are available, it is highly recommended to upgrade to the latest available version.

This vulnerability affects Ignition 7 (prior to v7.9.14) and 8 (prior to v8.0.10), an Integrated Software Platform for SCADA systems to do cross-platform web-based deployment. These versions contain multiple vulnerabilities that, when chained together, can lead to preauth remote code execution with SYSTEM user privileges (advisory).

CVE-2020-10644 is one of these vulnerabilities (see also CVE-2020-12004) and is related to an input validation issue that leads to deserialization of untrusted data. By sending a request to the /system/gateway API endpoint and invoking getDiffs() action with a specially crafted payload, it is possible to bypass the validation routine and execute arbitrary code remotely.

This vulnerability is rated as critical, but to successfully exploit this, this must be chained with the two other vulnerabilities, as explained above and in the advisory. A Metasploit module exploiting these vulnerabilities is available here

This vulnerability affects Ignition 7 (prior to v7.9.14) and 8 (prior to v8.0.10), an Integrated Software Platform for SCADA systems to do cross-platform web-based deployment. These versions contain multiple vulnerabilities that, when chained together, can lead to preauth remote code execution with SYSTEM user privileges (advisory).

CVE-2020-12004 is one of these vulnerabilities (see also CVE-2020-10644) and is related to an access control issue that enables an attacker to retrieve sensitive information. The com.inductiveautomation.ignition.gateway.servlets.gateway.functions.ProjectDownload Java class provides several actions that do not require authentication. Particularly one of them, getDiffs(), can be used to access all the project data.

This is a medium risk issue when taken alone. However, as explained above, it can be critical when chained with other vulnerabilities.

The installer component of Cisco AnyConnect Secure Mobility Client for Windows prior to 4.8.02042 is vulnerable to path traversal and allows local attackers to create/overwrite files in arbitrary locations as the SYSTEM user. By successfully exploiting this flaw, a local attacker will be able to execute arbitrary commands with elevated privileges and take full control of the system.

This write-up provides some additional information about practical exploitation than the original advisory. Basically, the attack consists of sending a specially crafted IPC message to the TCP port 62522 on the loopback device, which is exposed by the Cisco AnyConnect Secure Mobility Agent service. This service will then launch the vulnerable installer component (vpndownloader), which copies itself to an arbitrary location before being executed with SYSTEM user privileges. Combining this flaw with DLL hijacking technique, it is possible to execute arbitrary code in the context of the SYSTEM user.

Since two PoC’s (here and here ) and a weaponized Metasploit module are now available, it is highly recommended to update AnyConnect.