Communication Channels

Core Impact's agents communicate using communication channels. Channels provide reliable communication between two agents and, in some cases, data transformations such as encryption.

Different channel implementations are available depending on the network scenario. You must decide which channel to use for communication with an agent before you deploy the agent. This decision is typically made when you set parameters for an attack module (a module that will eventually deploy an agent) or when you set parameters for the deployment of an agent. In addition to selecting the channel, you must also set channel-specific parameters.

A special channel called Crypto is available that provides data encryption and session authentication (see Crypto Channel). This channel is usually layered on top of another transport channel that provides the actual communication.

Allowing for broad testing capabilities, Core Impact will function across IPv6 backbone networks. In the case of dual-stack systems, Core Impact will automatically use only the IPv4 stack for security testing. All Internet services from Core Security to Core Impact, such as product activation and updates, will remain IPv4 based.

TCP Channel

The TCP Channel provides communication using the underlying OS TCP sockets. You can set up a TCP Channel from the source agent to the target, or from the target to the source agent. The latter option is useful for scenarios where packet filtering disallows inbound connections and only allows outbound connections. Depending on the vulnerable application, it is sometimes possible to reuse an existing TCP connection as an agent communication channel. In attack modules, this behavior is typically configured with the Agent Connection/CONNECTION METHOD parameter.

HTTP/s Connect Channel

This feature is now used by default by every client-side exploit when using the "Connect from" agent connection method. It can be overridden on a per-exploit basis if an alternate method is preferred. The HTTP/s Connect Channel enhances the regular TCP channel (using "Connect From") by allowing agents in Windows hosts to use the CONNECT method from the HTTP 1.1 protocol to connect back to the current source agent (usually the console) through a proxy.

A typical use scenario for this feature would be an external penetration test where the tested workstations can only browse the Internet through a proxy.

Technical Details

Proxies that support the CONNECT command allow for tunneling any arbitrary TCP connection through the original HTTP connection.

To start communication, the agent sends the following command to the proxy:

CONNECT host:port HTTP/1.0	

The proxy then connects to the indicated host and port and, if the connection is established, responds with the following:

HTTP/1.0 200 Connection established	

After receiving this response, the agent can use the same open socket as if it were directly connected with the host. The proxy will then transparently forward all data in both directions.

Known Issues and Limitations

• Agents connecting back using a proxy will appear in the Entity View within a host with the proxy's IP address (instead of the actual host's address).
• Most proxies only allow tunneling port 443 (HTTPS). If Agent Connection/PORT is not 443, the proxy will probably deny the connection. Because of the single connection limitation mentioned above, client-side exploits have a default Agent Connection/PORT of 0, which indicates a random port within the valid range (usually 40001 to 60000, but depends on NAT preferences).
• The current payload for this connection method only supports reading IE's configuration from the registry. If the user is not using IE or if IE is not configured correctly, the connection method will fail and default to Connect From.
• Proxies usually keep activity logs which include activity related to the CONNECT command. It is reasonable to assume that the source agent's address will be recorded in this log.

Notes for Exploit Developers

To force the activation of this connection method, set the egg's "WebProxyTunnel" parameter to "yes." Set the same parameter to "no" to force deactivation. Additionally, it is possible to hard-code the proxy configuration within the exploit, reducing the payload's final size by excluding the auto detection code. To hard-code the proxy's address and port set the "proxy_ip" and "proxy_port" parameters to the desired values.

For example, to force this connection method in an exploit hard coding the proxy address to 192.168.1.1 port 80 you can use the following code:

self.egg['WebProxyTunnel'] = 'yes'self.egg['proxy_ip'] = '192.168.1.1'self.egg['proxy_port'] = 80	

The implementation for this connection method can be found in the WebProxyTunnelEgg.py file located in the %ProgramData%\IMPACT\components\modules\classic\site-packages\impact\LibEgg folder.

HTTP Tunnel Channel

The HTTP Tunnel Channel provides communication using the HTTP protocol. Core Impact agents can use this communication channel to connect through an HTTP proxy verifying the presence of a valid HTTP communication.

A typical use scenario for this channel would be an external penetration test where the tested workstations can only browse the Internet through a protocol validating proxy.

Technical Details

Similar to agents using the HTTP Connect channel (see HTTP Connect Channel), these agents will automatically get connection settings from Internet Explorer.

Agents use GET requests to read data from the console and send data back using POST requests. These requests use "application/x-www-form-urlencoded" as their MIME Content-Type. In order for communication through a proxy to succeed, the proxy has to allow GET, POST, and the "application/x-www-form-urlencoded" Content-Type.

Exploits implementing this method use a helper module called "HTTP Tunnel". This module translates between HTTP and the agent protocol in a manner that's transparent to the user.

HTTP Tunnel components

Agents using this method will first connect with their configured HTTP proxy (using IE's proxy settings) and then request an HTTP URL from the HTTP Tunnel. Upon receiving the request, the HTTP Tunnel will translate the HTTP request to the ProxyCall interface and send it to the Core Impact Console.

Crypto Channel

The Crypto Channel provides data encryption and session authentication. Key agreement for communication is performed using RSA and encryption is performed using 256-bit AES.

Each Core Impact workspace has a public-secret-key pair which is used for key agreement in Crypto Channels. Each agent packaged with Crypto will have a copy of the workspace's public-key which will be used to authenticate the Console. This means that only the Console containing the workspace that created the agent will be able to connect to it.

DNS Channel

The addition of the new DNS Channel payload into Core Impact increases the success rate of client-side exploit attempts by using the DNS protocol. DNS provides a number of advantages over other protocols as a communications channel. Most remote exploitation attempts via client-side vulnerabilities aim to attack workstations. Workstations are almost always pre-configured to use an internal DNS server, and this internal DNS server is almost always configured to relay DNS requests for external domains out to the Internet. This means that most internal networks are vulnerable to DNS channeling attacks. Core Impact now leverages this common security design flaw to tunnel the Core Impact agent communications out of the target network and back to the Core Impact host.

DNS also does not require authentication and typically does not need to bypass security controls such as web content filters, whereas HTTP channels often do. Reverse TCP payloads also rely on outbound firewall rules to be mis-configured, and combined with the probability of guessing the open outbound port, the likelihood of the success rate for this payload is reduced dramatically. The new DNS Channel payload is able to bypass all of these security controls in order to escape the internal network. This is an important advance within Core Impact since it means that the chance of successful exploitation is much higher when using the DNS Channel payload, leading to more reliable exploitation. The DNS Channel payload is also smaller than other payloads within Core Impact, allowing it to fit within more exploits without necessarily having to rely on slower more complex techniques such as egg hunters.

Once the agent is installed on the target system, all of the communications back to Core Impact are performed over DNS. All of the features available within the Core Impact agent are made available via the DNS protocol, including an interactive shell, taking screenshots of the victim machine, and installing the pcap plugin to sniff and download network traffic.

There are ways to protect against this type of attack, such as implementing a Split DNS Architecture that will allow organizations to prevent DNS requests from exiting their internal network. This would prevent the DNS probes from leaving the organization and reaching the Core Impact host. Most organizations do not currently use Split DNS (except for larger, more security-aware organizations) and, therefore, this attack has an extremely high success rate. Network IDS systems could also potentially be configured to detect trends of multiple large DNS requests to a single domain.