A Cross-Site Scripting (XSS) vulnerability in the Forum module in Drupal 6.x (prior to version 6.13) allows remote attackers to inject arbitrary web scripts or HTML by requesting a specially crafted tid. Forum module must be active in the attacked Drupal
A Reflected Cross Site Scripting vulnerability was found in the atksearch[contractnumber], atksearch_AE_customer[customer] and atksearchmode[contracttype] variables within the 'Organization Contracts' administration page. This is because the application does not properly sanitize the users input. Vulnerable version is = 1.3.4.
This module exploits an authentication vulnerability in Wordpress 2.5. An attacker, able to register a specially crafted username on a Wordpress 2.5 installation, will also be able to generate authentication cookies for other chosen accounts. This vulnerability exists because it is possible to modify authentication cookies without invalidating the cryptographic integrity protection. The proper way to exploit this vulnerability is to use a Wordpress account which its username starts with the word "admin", for example "admin99".
A weakness has been reported in WordPress which can be exploited to bypass certain security restrictions. The weakness is due to a bug within the password reset functionality when verifying the secret key. This can be exploited to reset the password of the first user without a key in the database (usually administrator) without providing the correct secret key.
This module exploits an authentication vulnerability in OpenSite 2.1. The function init in origin/libs/user.php checks for a matching origin_hash cookie. However, this cookie can be bruteforced in at most 2^32 tries for a known username. Actually, the number of attempts could be significantly reduced knowing that we do not have to check for time in the future, and long past. This works for OpenSite 2.1 and below. It has to be executed against the root directory of OpenSite. The resulting SHA1 cookie has to be used to impersonate the admin on OpenSite putting it on the origin_hash cookie, setting all the others cookies with the default value.
A vulnerability has been reported in MyBB, which can be exploited by malicious users to conduct SQL injection attacks. Input passed via the "birthdayprivacy" parameter to inc/datahandlers/user.php is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code. Successful exploitation requires a valid user account. The vulnerability is reported in MyBB 1.4.x versions prior to 1.4.7. This modules gives to a normal user, admin privileges.
Exploits a vulnerability in the Real VNC server to bypass the password authentication. A compatible VNC client is required. This exploit proxies TCP connections to a remote (or local) VNC server and monitors the list of supported authentication methods of the server. Connecting clients will receive a dummy list consisting of only one authentication method (no password). Unlike other exploits, this module does not deploy any agents.
Before using this module please consider that this is not an actual one-step exploit but a tool that allows our community to confirm if a target infrastructure is vulnerable to Poodle attack by executing a PoC (Proof of Concept). This module is not meant to be used against a victim like most Impact exploits are. Further, to just scan your network for weak ciphers, see the "Test SSL Ciphers" in Impact's Web tab. As this vulnerability is not only a server but a client/server issue, while using this module you should keep in mind that most browsers were or will be updated soon to stop supporting SSLv3 limiting the effectiveness of this PoC. In order to prevent this attack you could disable SSLv3 support either on the browser or server side among other strategies. The target infrastructure for running this PoC should look like this: Victim machine (A.A.A.A) --> Core Impact (B.B.B.B) --> Proxy Server (Optional) (C.C.C.C) --> Vulnerable Server (D.D.D.D) This module has two main operational modes depending on if the network that is allowing the victim to reach the vulnerable server requires a proxy server or not. These operation or "Working" modes are: "Fake Server", if a proxy server is not required; and "Fake Proxy", if a proxy server is required for reaching the vulnerable site. Pre requisites before launching the PoC are: 1- Identify the target infrastructure and related IP addresses. 2- (Optional) Confirm if both the server and the browser allow using SSLv3 by default. 3- Confirm if the server is using publicly signed or trusted certificates. 4- -Optional- Confirm if the server is serving CBC based ciphers by default to encrypt the client/server communication channel. If the RC4 cipher is enabled by default this PoC may not detect the server as vulnerable. Steps for running the "Fake Server" PoC: 1- Instruct the "Victim's Machine" to resolve the vulnerable domain name to the Core Impact IP address. This can be achieved by adding the following line to the "hosts" file on victim's machine: B.B.B.B target.domain.com ...this step emulates an scenario where the attacker has achieved redirection of traffic to him by any mean. 2- On the Core Impact machine execute the "Create New Host" module and specify victim's IP address and operating system (this is the IP of the host running the web browser). You could instead run RPT IG (Rapid Penetration Testing Information Gathering) wizard which will assist you in fingerprinting the target machine. 3- Drag and drop this module against "victim's machine" providing the following parameters (a) set your "target.domain.com" as "HTTPS DOMAIN NAME" and (b) select "Fake Server" as "WORKING MODE". "Proxy settings" are not required on this mode. 4- -Optional- On the victim machine open a vulnerable browser (you can force some browsers to use SSLv3) and log into the target web application using HTTPS to access it (this will create a cookie for it). 5- Now in the victim machine, navigate to http://target.domain.com/ (note you should be connecting with HTTP). 6- The exploit module succeeds in the decryption of some bytes of the request. Steps for running the "Fake Proxy" PoC: 1- Instruct the Victim Machine's browser to use Core Impact IP address as proxy; leave the port already configured. This emulates the scenario where the attacker has been able to redirect HTTP traffic for a browser using a proxy; for example, by spoofing the DNS responses for the proxy's DNS. 2- On the Core Impact machine execute the "Create New Host" module and specify victim's IP address and operating system (this is the IP of the host running the web browser). You could instead run RPT IG (Rapid Penetration Testing Information Gathering) wizard which will assist you in fingerprinting the target machine. 3- Drag and drop this module against "victim's machine" providing the following parameters (a) set your "target.domain.com" as "HTTPS DOMAIN NAME" and (b) set Working mode as "Fake Proxy". Set the proxy settings: Real Proxy: C.C.C.C Proxy Port: the port where the proxy is listening Change the proxy port to whatever is appropriate. 4- -Optional- On the victim machine open a vulnerable browser (you can force some browsers to use SSLv3) and log into the target web application using HTTPS to access it (this will create a cookie for it). 5- Now in the victim machine, navigate to http://target.domain.com/ (note you should be connecting with HTTP). 6- The exploit module succeeds in the decryption of some bytes of the request. Further comments: The first step of the Poodle attack is to perform a downgrade attack. This downgrade attack achieves the negotiation of SSLv3 as the protocol to be used in the connection, but can't affect the ciphers list being negotiated, because in SSLv3 the cipher negotiation is protected by hashing. Due to this fact, if both the server and the client support the RC4 stream cipher, it will be chosen as the connection cipher and the attack will fail. This doesn't imply that the server isn't vulnerable, as the attack would be successful when other client supporting only block ciphers connect. Moreover, RC4 is known to be vulnerable to cryptographic attacks itself. This module doesn't work with proxies requiring authentication. Performance issues in either the client or the server can negatively affect the effectiveness of the attack. In particular, if a single HTTP request is spread in TCP segments taking an order of seconds to pass to the server, this module will fail, as it won't correctly recognized the encrypted packets that comprise the request. Different client implementations might also affect the attack, as can affect how different parts of the HTTP request are divided in SSL packets. This attack, as documented, has been successfully tested against Internet Explorer 11. Further, different versions (even minor versions), impose different rules for cross-origin requests. Depending on the exact rules imposed, it may not be possible to include the cookie in cross domain requests (without abusing a second vulnerability). It may also be possible that the cookie may be included in the requests -and thus decrypted with the attack-, when the attack is carried making the browser believe the Javascript conducting the requests is the same domain, but with the pages requested over the insecure channel (i.e., HTTP instead of HTTPS). The default parameters of this module does just that, but the behavior can be changed using the "ATTACK FROM FAKE DOMAIN" parameter ("false" by default). Troubleshooting: * Ensure that no page from a previous attack is opened. This shouldn't usually be a problem, as the defined timeouts for different requests should mean that no requests should be coming from previous attacks. * Empty the browser cache. * Close any page making requests to the target domain. Unsupported scenarios: * This module doesn't yet support the scenario of attacking in "Proxy Mode" but without a real proxy to connect to. * This module doesn't yet work with Impact's "Fake AP" module, or any other man-in-the-middle modules based on Wi-Fi.
The SSL protocol, as used in Oracle Java, encrypts data by using CBC mode with chained initialization vectors. This weakness allows to decrypt HTTP headers by a chosen plain text attack, thus obtaining browser cookies from the target system's browser corresponding to a given HTTPS server. The cookies could then be used by the user to do a session hijacking attack. This module launches the attack against target systems. This systems must be running a browser with the vulnerable Java version for this exploit to work. This module is capable or retrieving the cookies stored in the browser for a specified target domain. The attack begins with an ARP spoofing attack. If this attack is successful, HTTP traffic from the target system will be intercepted and modified. An HTTP response will be modified so the target's browser loads a Java applet. This applet then is used to launch the chosen plain text attack. For this exploit to work, the cipher suite used by the SSL connection between the target system and the target domain must use the CBC mode. This module only works when the target domain server isn't on the same local network as the target system. This exploit wasn't tested on target domains that resolve to more than one IP address. This module doesn't work when the target domain host is accessed by the target system through a proxy, or if the target domain server closes the SSL connections after every request. Note: The ARP attack will send packets with spoofed MAC addresses. The MAC address prefix can be controlled with a parameter. This value should be changed when the module is run against more than one target at the same time.
Subscribe to Impact