The default error page in Spring Boot (also know as "Whitelabel Error Page"), when a type error is detected in a parameter configured in a controller, will display the provided value. The page's rendering expands Spring Expression Language (SPEL) expressions found in the page, and it does so recursively. Because of this, a string containing an expression language provided as the value for an URL parameter may be evaluated server side while rendering the page if it's from a different type to the expected for said parameter. The "Whitelabel Error Page" is provided by default, but it can be customized. This attack has only been tested with the default error page. In particular, if SPEL is not used a the templating language for another page, or if the page doesn't print the exception due to type mismatch, the attack is not possible.
This module exploits a remote code execution vulnerability in Joomla. The session handling code is susceptible to PHP Object Injection attacks due to lack of sanitization in some HTTP headers that are saved to the database session backend.
This exploit abuses a persistent cross site scripting vulnerability in Wordpress to install an OS Agent in the server running the Wordpress installation. To do this, it posts a comment with the cross site scripting code for every target selected. The injected code will attempt to install a Wordpress plugin everytime the post comment is rendered, and it will immediately remove itself from the DOM so as to not be visible or execute again until the page containing it is opened again. The attack will be successful when someone visits the page with the attack while being logged in with administrator credentials. The attack should not have any effect on visitors either not logged in or without sufficient permissions to install a plugin. If the comment is queued for moderation, the attack will continue only if it's approved. Because the contents of the comment are quite clearly an XSS attack, it's better to try to avoid the moderation of the comment. The following attack steps are then recommended. Using 'Verification Mode' Use the 'Verification Mode' provided by this module turning it on by means of the 'VERIFICATION MODE ON' parameter. Complete the 'Verification Mode' parameters. Run the module. Verify the post to attack (i.e., open it in a web browser). If the comment appears without the need for moderation, you can directly attack the page. Otherwise, wait until the comment is approved, and then conduct the attack turning the verification mode off. Using 'Web Proxy': Navigate to the Wordpress post you mean to use a target and add a comment. Do not use Impact's 'Web Proxy' module while doing it. If the comment is moderated, wait for the message to be approved. Configure the current scenario to use the same user agent as your browser. Run the 'Web Proxy' module, and configure your web browser to use it. Visit the same post with the proxy configured: the cookies captured with the 'Web Proxy' module will be used for the atack. Also, the same author and author email will be used. Run this module against the blog post URL discovered by the 'Web Proxy'. The target webpage must be a Wordpress post. The module will attempt to read certain values from the comment posting form, for which will make a request to the post first. It will next make a POST against a different URL (the action of said form) to create the comment with the attack code. Keep in mind that, for comments to be automatically approved, the request should be made from the same IP, with the same user agent, with the same author name, and with the same author email. In all cases, you'll need to wait for a logged in administrator to visit the post. The attack will be executed on a 'onmouseover' event on the page with the comment. If you choose to post the attack skipping the use of cookies and other request values to avoid moderation, you should provide an author name and author email in the Advanced paramenters. If not provided, dummy values will be used, reducing even further the chances of a moderation approval. By default on some systems, the owner for the Wordpress plugins directory is different from the one running the HTTP server, so plugin installation works differently from what the current implementation of this module expects. In those cases, the attack will fail even though the vulnerability is present. If the installation of the plugin succeeds, an agent will installed, and both the comment and the plugin will be removed from Wordpress. This module will keep waiting for agent connections until manually stopped.
Subscribe to Known Vulnerabilities