The vulnerability exists within the GetCookie() endpoint due to unsafe deserialization of AuthorizationCookie objects. The application insecurely decrypts cookie data using AES-128-CBC and subsequently deserializes it via BinaryFormatter without sufficient type validation. The deployed agent will run with SYSTEM privileges. This exploit performs the following steps: Retrieves the ServerID via a SOAP request to the ReportingWebService. Obtains an authorization cookie. Obtains a reporting cookie. Constructs and sends a malicious event payload. Checks the server's response to confirm success

This module exploits a nested PHP array object deserialization in the MagentoFrameworkSessionSessionManager class via the $sessionConfig variable using the /rest/default/V1/guest-carts/abc/order endpoint of Magento Open Source and Adobe Commerce to deploy an agent. First, the module will upload a PHP script in the /pub/media/customer_address/s/e directory of the web application using the /customer/address_file/upload endpoint. The default webroot directory value (/var/www/html/magento/pub/) can be changed using the WEBROOT module parameter. Then, it will trigger the vulnerability using a crafted PHP array object via the /rest/default/V1/guest-carts/abc/order endpoint, that will copy the uploaded PHP script to the given webroot directory. Finally, it will deploy the agent by calling the PHP script in the webroot directory. It's important to notice that the apache user account (www-data) must have write access to the webroot directory for this exploit to work. The deployed agent will run with the apache user account (www-data) privileges.

This module exploits a nested PHP array object deserialization in the MagentoFrameworkSessionSessionManager class via the $sessionConfig variable using the /rest/default/V1/guest-carts/abc/order endpoint of Magento Open Source and Adobe Commerce to deploy an agent. First, the module will upload a PHP script in the /pub/media/customer_address/s/e directory of the web application using the /customer/address_file/upload endpoint. The default webroot directory value (/var/www/html/magento/pub/) can be changed using the WEBROOT module parameter. Then, it will trigger the vulnerability using a crafted PHP array object via the /rest/default/V1/guest-carts/abc/order endpoint, that will copy the uploaded PHP script to the given webroot directory. Finally, it will deploy the agent by calling the PHP script in the webroot directory. It's important to notice that the apache user account (www-data) must have write access to the webroot directory for this exploit to work. The deployed agent will run with the apache user account (www-data) privileges.

This module exploits a Server-Side Request Forgery via the getUiType parameter in the /OA_HTML/configurator/UiServlet endpoint of Oracle E-Business Suite to deploy an agent. First, the module will register an endpoint in the local webserver that will be used in the attack to send a xsl file to the target that will execute system commands to deploy the agent. Then, it will retrieve a required CSRF token via the /OA_HTML/runforms.jsp and /OA_HTML/JavaScriptServlet endpoints. Finally, it will use the Server-Side Request Forgery vulnerability combined with a Carriage Return/Line Feed (CRLF) injection to smuggle a request to the /OA_HTML/help/../ieshostedsurvey.jsp endpoint that will trigger a GET HTTP request to the local webserver, which will, in turn, deliver the xsl file that will deploy the agent. The deployed agent will run with the oracle user account privileges.

This module uses a SQL injection vulnerability in Fortinet FortiWeb to deploy an agent in the appliance that will run with root user privileges. The vulnerability is reached via the /api/fabric/device/status endpoint. The module will first check if the target is vulnerable using the previous endpoint with a generic payload. Then, it will use the vulnerability to upload and write a webshell in disk that will allow the execution of OS commands to deploy an agent. Next, it will use the vulnerability again to upload, write an execute a python script that will give execution permission to the uploaded webshell. Finally, it will send several requests to the webshell to deploy a Core Impact agent. Once the agent is deployed, the webshell and the python script will be erased from the target system.

This module uses an authenticated PHP object deserialization vulnerability to deploy an agent in Roundcube Webmail that will run with the same privileges as the webapp. The module will use the given credentials to authenticate against Roundcube Webmail in the target. Then, it will generate a payload for agent deployment and abuse the _from parameter defined in the upload.php file to inject it in the $_SESSION variable. This variable will be processed by the unserialize function in the rcube_session class. Finally, the module will proceed to logout from the webapp to trigger the PHP object deserialization vulnerability and deploy the agent.

This module uses a .NET deserialization vulnerability to deploy an agent in Veeam Backup and Replication that will run with the NT AUTHORITY\SYSTEM user privileges. The module will trigger the vulnerability by crafting a Veeam.Backup.EsxManager.xmlFrameworkDs .NET class type object and sending it to the /VeeamAuthService .NET remoting endpoint using an external .NET executable. The deserialization of the crafted object will execute system commands to deploy the agent.

This module uses a stack-based buffer overflow vulnerability to deploy an agent in Ivanti Connect Secure that will run with the nr user privileges. First, this module will check if the target is an Ivanti Connect Secure appliance. If it is, it will determine if the target is vulnerable by retrieving it's version number using 2 different methods. Then, the module will try to leak the base address of the libdsplibs.so library. To perform this, a random endpoint will be registered in the local webserver. Then, the vulnerability will be used while bruteforcing the base address of the library in order to the execute a cURL command that will send the request to the registered random endpoint. Once the base address of the libdsplibs.so library is obtained, the vulnerability will be used one more time to deploy an agent.

This exploit leverages the CVE-2024-24401 and CVE-2024-24402 vulnerabilities in Nagios XI to fully compromise the system and gain total remote control. The monitoringwizard.php component of Nagios XI version 2024R1.01 is vulnerable to a critical SQL Injection, identified as CVE-2024-24401. Initially, the exploit targets this component, performing an SQL Injection to extract the administrator key (admin key). Before proceeding, it authenticates using an existing user, regardless of their privilege level, ensuring access to the system for subsequent stages. With the administrator key obtained, a new administrator user is created, along with an identity associated with this user, using the newly generated credentials. This identity enables reauthentication and the ability to perform elevated actions. Subsequently, the exploit executes arbitrary commands on the system using the privileges of the newly created administrator. Next, it installs an agent and escalates its privileges to root, exploiting the CVE-2024-24402 vulnerability. During this process, the exploit manages the npcd service binary: first, the original service is stopped, and a backup of the npcd binary is created in the /usr/local/nagios/bin/ directory as npcd.backup. Then, the agent binary is copied to the same directory under the name npcd, replacing the original binary. Finally, the npcd service is restarted to execute the agent. These steps result in a full system compromise, granting the attacker total remote control and the ability to execute arbitrary actions with root privileges.

This module chains 4 vulnerabilities to deploy an agent in a Linux target system that will run with the cups-browsed daemon user privileges. The first vulnerability is cups-browsed which binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker controlled URL. The second vulnerability is in libcupsfilters were function cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker controlled data to the rest of the CUPS system. The third vulnerability is in libppd were function ppdCreatePPDFromIPP2 does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker controlled data in the resulting PPD. The last vulnerability is in cups-filters were foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter. This module will start a fake IPP Server that will be used to deliver the payload to exploit the last 3 vulnerabilities. This will create a fake printer on the system. Then, it will send a packet to the target to exploit the first vulnerability. Finally, the attack chain will be triggered by sending an HTTP request to the CUPS Management Interface to print a test page on the fake printer, which in turn, will execute the commands that will deploy the agent. The url for the CUPS Management Interface can be set with the CUPS_MANAGEMENT_URL parameter. If no value is specified, then http and tcp port 631 will be used. If the final step fails (i.e. if the CUPS Management Interface only listens in the local interface) the module will keep running for a period of time waiting for the target system to create a print job on the fake printer that will deliver the attack to deploy the agent. The wait time (in seconds) can be changed with the ATTACK_TIMEOUT parameter. The default/minimal value is 90 seconds.