The Canvas Exploit Framework

Immunity Security's Canvas software is designed more as an exploit development and defense-testing tool, rather than as a full-featured penetration-testing tool such as Core Impact. The strength of Canvas is that it provides one of the most flexible and powerful frameworks for exploitation, intrusion detection device testing, and exploit crafting. However, that very flexibility combined with its GUI makes Canvas a little bit harder to use for general penetration testing. Canvas is the framework that provides the highest level of evasion and modification for crafting attacks; it also provides the ability to use MOSDEF, a C compiler written in pure Python. Table 9-2 shows the types of available modules.

Table 9-2. Module types available in Canvas

Module type

Description

Exploits

List of exploits

Command

Command to run on nodes

Tools

Various tools

Recon

Reconnaissance and discovery

DoS

Denial of service

Listener Shell

Start a listener

Server

Server module for Canvas

Import/Export

Import/export information

When you start the Canvas graphical user interface, a user interface such as the one in Figure 9-8 appears. Most penetration-testing tasks can be achieved using this GUI.

The Canvas graphical user interface window

Figure 9-8. The Canvas graphical user interface window

The Canvas GUI is divided into multiple panes that provide information and allow you to perform different tasks. The Current Callback pane displays the current listening interface. The Node Tree pane contains the following data fields: Connected Nodes (exploited nodes that can be use for the command module and bouncing); Knowledge (known hosts and their information); Interface (allows you to choose which interface to use); and the Covertness Bar (allows you to change the covertness level of an attack, but also affects the reliability of attacks).

There are also log and debug windows that display information about the currently running exploit and the exploit's status (whether it is still running, finished, successful, or failed).

In order to be totally unseen (the dream of every hacker), you must be careful with the Covertness Bar; while being covert is useful to evade IDS and even the cleverest administrators, covertness is gained by stretching the protocol. For example, sending 1,000 small packets that will be reassembled on the server, but not by a basic IDS, might evade any signatures on that IDS that are larger than the packet fragment size. The same concept can be applied to other layers: encrypting web pages with JavaScript, DCE-RPC fragmentation (Layer 7 fragmentation), or using a Unicode string instead of ASCII. However, stretching too much (using an excessively high covertness level) will succeed at bypassing the IDS but will also corrupt the communication to the server to the unusable point, so using a high covertness level can hurt, not help you. In reality, using the Covertness Bar involves walking a thin line between the quality of the IDS protocol implementation and the quality of the real service.

The next example presents two cross-site scripts, with and without evasion, so you can see what evasion might look like. First, without evasion:

<script>alert("oups");</script>

Next, with evasion:

&#60;&#115;&#99;&#114;&#105;&#112;&#116;&#62;&#97;&#108;&#101;&#114;&#116;
&#40;&#34;&#111;&#117;&#112;&#115;&#34;&#41;&#59;&#60;&#47;&#115;&#99;
&#114;&#105;&#112;&#116;&#62;

There's nothing very clever here, but if the IDS cannot interpret Unicode characters and the server can, this evasion might work perfectly by slipping the packets undetected past the IDS to be reassembled by the server.

The covertness feature is implemented in the protocol suite, so each protocol has different methods of evasion. Each exploits on a particular protocol benefit from the specific evasion techniques provided from the protocol suite. In other words, the user doesn't pick the evasion technique himself; it is selected for him depending on the protocol and what setting he moves the Covertness Bar to.