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 module uses an Authentication Bypass vulnerability in Magento eCommerce Web Sites and a blind SQL Injection to gain arbitrary code execution on the affected system.
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.
This exploits attacks pPim 1.0 software. By creating a specially crafted link an attacker can run arbitrary commands with the privileges of the web server process.
This module exploits a Remote File Inclusion vulnerability in phpJobScheduler 3.0.
This module exploits a phpBB2 2.0.15 Remote File Inclusion.
osCommerce is prone to an arbitrary-file-upload vulnerability because it fails to adequately sanitize user-supplied input. An attacker can exploit this vulnerability to upload arbitrary code and execute it in the context of the webserver process. This may facilitate unauthorized access or privilege escalation; other attacks are also possible.
Input passed to the IP parameter in mw_plugin.php is not properly sanitised before being used to include files. This can be exploited to include arbitrary files from local and remote resources via directory traversal attacks and URL-encoded NULL bytes. The vulnerable version is 1.2.3 and below.
Report.php fails to sanitize user input data on StartingDirectory parameter when used in an include. The vulnerable version is 10.04.x.
This exploits attacks Mambo 4.6.4 software. A remote file inclusion vulnerability is present in Mambo. /includes/Cache/Lite/Output.php doesn't sanitize the $mosConfig_absolute_path before using it in an include.
Pagination
- Previous page
- Page 15
- Next page