This tool bypasses Mark of the Web and Smart Screen in order to execute blocked files which usually have been downloaded from internet. It involves crafting LNK files that have non-standard target paths or internal structures. When clicked, these LNK files are modified by explorer.exe with the canonical formatting. This modification leads to removal of the MotW label before security checks are performed, this results in the execution of the locked file bypassing the warnings.
Microsoft Windows is prone to a vulnerability that may allow a file to automatically run because the software fails to handle 'LNK' files properly. Specifically, the issue occurs when loading the icon of a shortcut file. A specially crafted 'LNK' file can cause Windows to automatically execute code that is specified by the shortcut file. The attacker must entice a victim into viewing a specially crafted shortcut. The shortcut file and the associated binary may be delivered to a user through removable drives, over network shares or remote WebDAV shares. An attacker may exploit this issue to execute arbitrary code.
This module creates a file in the specified directory. The file abuses a command injection in ImageMagic, downloading an Impact agent and deploying it in the target system. Because ImageMagick is widely used -specially in web applications-, this module will only provide the file with the attack. The file can then used in multiple ways; for example, uploaded to a web site under test.
This module runs a DHCP server. When requests (DHCPREQUEST or DHCPDISCOVER) are received, it will respond with an offer according to the given configuration, and it will include a string leveraging the GNU Bash Environment Variables Injection vulnerability into the DHCP's 'default-url' option to register a crond script, that'll subsequently download and execute an Impact agent, using the target system's wget. The injection will be tried once per MAC. Keep in mind that a successful attack requires that the attacked hosts have connectivity to Impact's web server after the attack -which might set new network settings in the target-, so consider changing the source agent for the web server module if you're attacking from an agent different from /localagent. Also, if the source agent has multiple network interfaces listed, select the appropriate one for the network you're attacking. If the agent is running in a host with more than one network interface, be sure to select the appropriate one so the module receives and responds in the correct network. This module requires that the pcap plugin be installed.
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.
Microsoft Windows is prone to a vulnerability that may allow a DLL file to be automatically loaded because the software fails to handle LNK files properly. Specifically, the issue occurs when loading the icon of a shortcut file. A specially crafted LNK file can cause Windows to automatically execute code that is specified by the shortcut file. The attacker must entice a victim into viewing a specially crafted shortcut. The shortcut file and the associated binary may be delivered to a user through removable drives. An attacker may exploit this issue to execute arbitrary code. This vulnerability is the result of an incomplete fix for MS10-046 (CVE-2010-2568).
Subscribe to Tools