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.
Unspecified input is not properly sanitised before being returned to the user via a "standard_error_message" template. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site. The vulnerabilities are reported in version 2.12.2, 2.11.5 and 2.10.21. Other versions may also be affected. Once the vulnerability is confirmed by Core Impact, if you want to check this exploit manually, replace the "REPLACE" keyword with "%80".
XAMPP suffers from multiple XSS issues in several scripts that use the 'PHP_SELF' variable. The vulnerabilities can be triggered in the 'xamppsecurity.php', 'cds.php' and 'perlinfo.pl' because there isn't any filtering to the mentioned variable in the affected scripts. Attackers can exploit these weaknesses to execute arbitrary HTML and script code in a user's browser session.
This vulnerability results from an unsanitized input that can be crafted into an attack by manipulating the 'mode' parameter of the xml/media-rss.php script of NextGen Gallery plugin installation. Version 1.5.1 is verified as vulnerable. Older versions are probably affected too, but they were not tested at this time. Currently only Internet Explorer (version 6,7 and 8 with XSS filter disabled) is verified as vulnerable. This is due to the fact that this browser sets the content-type of a document by parsing the content the webserver returns, instead of obeying the proper headers of the document.
Input passed to the "s" parameter in index.php is not properly sanitised before being returned to the user in googleanalytics.php. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site. The vulnerability is confirmed in version 3.2.4. Other versions may be affected.
Input passed to the "dom" parameter in left.cgi and via the URL to virtual-server/link.cgi is not properly sanitized before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site.
The application is prone to a cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied input to the 'query' parameter of the search pages. An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks. vBulletin 4.0.2 is vulnerable. This issue does not affect vBulletin 3.x versions.
Input passed via the URL is not properly sanitised before being returned to the user within the search.php, sendmessage.php, showgroups.php, usercp.php, online.php, misc.php, memberlist.php, member.php, index.php, forumdisplay.php, inlinemod.php, newthread.php, private.php, profile.php, register.php, showthread.php, subscription.php, forum.php, faq.php, and calendar.php script. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site. The vulnerabilities are reported in version 4.0.2. Other versions may also be affected.
This module exploits insecure randomness vulnerability in Typo3, which leads to XSS attacks. This module tries to guess the Typo3 encryptionKey by exploiting its insecure randomness. If guessed, it will install an XSS Agent.Thanks to Chris John Riley for the info about the bug. http://www.c22.cc/TYPO3-InsecureRandomness.txt
Subscribe to Cross Site Scripting (XSS)