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.
CVE Link
Exploit Platform
Product Name