atk > plugins > how to write manually?

How to write manually?

Many people don't like to use specialized editors to do their work. Sometimes I count myself to this group of people. So I decided to allow users to write their own plugins manually.

Needed software

The plugins are ASCII plain text so you can use the text editor of your desire to create or edit a plugin manually. I recommend for example these two text editors for Windows:

Because ATK is written for Windows it is better you use an ASCII editor that has Windows compatibelity. On Unix and other operating systems the carriage return code is not the same. This could confuse the plugin parsing routine of ATK and cause in a strange behaviour. Crashes, hangs and wrong checking results could result.

Creating or changing a plugin with Notepad.exe is very easy

The design of a plugin and the fields

As described above a plugin is an ASCII text file, containing the information to realize a check. There are different informations available. These are written in an XML or HTML like format into a start and end tag. A start tag is encapsulated in smaller than and bigger than brackets. The follows the data - the plugin name in the example. After the data follows the end tag. The only difference between the start and the end tag is the slash after the first bracket. For example the plugin name is written as follows. The tags are highlighted red and the data is blue.

<plugin_name>This is the name of the plugin</plugin_name>
For better viewing every tag has it's own line. The structure is not relevant but should be done always in the same way.

We will now see which fields are available and how they could be used. The following table shows the different fields and their and meaning. The last column indicate if the field is needed (N) or just recommended (R).
 

Tag Meaning N/R Support
plugin_id The unique ID of the ATK plugin. It is easier to reference to specific checks. N ATK 1.0
plugin_name The name of the plugin. Should be very similar to the file name itself to support easier referencation. N ATK 1.0
plugin_family The name of the plugin family. This field allows grouping of similar checks. Allowed families are: Backdoors, CGI, ... N ATK 1.0
plugin_created_name The name of the creator of the plugin. So everyone could contact the person if some questions about the checks are given. R ATK 1.0
plugin_created_email The mail address of the creator of the plugin. So everyone could contact the person if some questions about the checks are given. R ATK 1.0
plugin_created_web The web site url of the creator of the plugin. So everyone could contact the person if some questions about the checks are given. R ATK 1.0
plugin_created_company The company name of the creator of the plugin. So everyone could contact the person if some questions about the checks are given. R ATK 1.0
plugin_create_date The create date of the first version of plugin. The syntax for dates is always YYYY/MM/DD. Only this way is an easy sorting possible. R ATK 1.0
plugin_updated_name The name of person who updated of the plugin. So everyone could contact the person if some questions about the checks or changes are given. R ATK 1.0
plugin_updated_email The mail address of person who updated of the plugin. So everyone could contact the person if some questions about the checks or changes are given. R ATK 1.0
plugin_updated_web The web site url of person who updated of the plugin. So everyone could contact the person if some questions about the checks or changes are given. R ATK 1.0
plugin_updated_company The company name of person who updated of the plugin. So everyone could contact the person if some questions about the checks or changes are given. R ATK 1.0
plugin_updated_date The create date of the latest version of plugin. The syntax for dates is always YYYY/MM/DD. Only this way is an easy sorting possible. R ATK 1.0
plugin_version Version number of the plugin. Every public plugin starts with version 1.0. Minor versions could be used for internal tests or private use. Changes increment the minor number by one. Complete changes in the access attempt or trigger string increment the major number by one. R ATK 1.0
plugin_protocol Defines which protocol should be used for the check. Possible values are tcp and udp. At the moment just tcp is supported. That is way this field has no impact on the behavior of a plugin. To keep the support in future versions of ATK please fill this field correctly. N ATK 1.0
plugin_port The for the check used destination port number. This is a value between 0 and 65535. Other values could cause an undefined state of the ATK software. See [Stevens 1994] for more details. N ATK 1.0
plugin_request The sentence of request for the check. The single commands are seperated by the pipe symbol ("|"). The following commands are supported:
  • open: Open the socket to the target (SYN/ACK)
  • sleep <seconds>: Pause the plugin for a few seconds
  • send <string>: Send a string to the target
  • close: Close the socket/session to the target (FIN)
N ATK 1.0
plugin_trigger The trigger that should be available in the server response to detect the security flaw if the plugin is trigger/response based (N). Plugins that use other methods to detect the success of an attack (e.g. Denial of Service attack with ICMP ping) don't need this field (-). N/- ATK 1.0
plugin_comment Additional comments for the plugin. For example to tell semething about the background of the vulnerability or name typical false positive reactions. R ATK 1.0
bug_published_name The name of person who published the in the plugin checked bug. So everyone could contact the person if some questions about the vulnerability or check are given. R ATK 1.0
bug_published_email The mail address of person who published the in the plugin checked bug. So everyone could contact the person if some questions about the vulnerability or check are given. R ATK 1.0
bug_published_web The web site url of person who published the in the plugin checked bug. So everyone could contact the person if some questions about the vulnerability or check are given. R ATK 1.0
bug_published_company The company name of person who published the in the plugin checked bug. So everyone could contact the person if some questions about the vulnerability or check are given. R ATK 1.0
bug_published_date Date of the public release of the in the plugin checked bug. The syntax for dates is always YYYY/MM/DD. Only this way is an easy sorting possible. R ATK 1.0
bug_advisory Name, date and URL of the public advisory of the checked bug. So the ATK user could read the original information. R ATK 1.0
bug_affected List of software and releases that are affected by the checked vulnerability. There are no rules to separate the different releases. R ATK 1.0
bug_not_affected List of software and releases that are not affected by the checked vulnerability. There are no rules to separate the different releases. This helps to indicate the version that is not vulnerable. Also false positives or negatives could easier be determined. R ATK 1.0
bug_vulnerability_class Class of the vulnerability. Similar to the family field should this field allow grouping of similar plugins. Allowed values for this field are: Bufferoverflow, Cross Site Scripting, ... N ATK 1.0
bug_description English description of the vulnerability. A good description begins with a short summary of the usability of the vulnerable software. Then describe the security flaw. N ATK 1.0
bug_solution English description how to fix the bug or minimize the security risk of it. The countermeasures could reach from upgrading over firewalling to additional encryption. R ATK 1.0
bug_fixing_time A time value that indicate how long does it approx. need to fix the vulnerability. R ATK 1.0
bug_exploit_availability This field describes the availability of an exploit. Allowed values are: No, maybe, yes, Don't know R ATK 1.0
bug_exploit_url The URL of the exploit. R ATK 1.0
bug_remote This field indicates the possibility to a successfully remote attack. Allowed values are: No, maybe, yes, Don't know R ATK 1.0
bug_local This field indicates the possibility to a successfully local attack. Allowed values are: No, maybe, yes, Don't know R ATK 1.0
bug_severity Severity of the flaw. Allowed values are:
  • Information: Not really a bug. Just something that is good to know (e.g. an open SSH port on tcp/22). Often this flaws could not be eliminated without having a negative impact on the solution itself.
  • Low: A flaw that could lead to (sensitive) data or very limited privilege escalation.
  • Medium: A dangerous flaw that could lead to further enumeration, attacks or limited privilege escalation.
  • High: A very dangerous security flaw that could lead to administrative privilege escalation (e.g. the famous SSH CRC buffer overflow).
  • Emergency: A very popular and dangerous security flaw (e.g. the famous RPC DCOM buffer overflow in Windows that was used by W32.Blaster.Worm).
N ATK 1.0
bug_popularity The popularity of the flaw. The possible value is between 1 and 10. 1 means that the flaw is just known by a few people. And 10 means that the flaw is very popular (e.g. Microsoft Windows RPC DCOM buffer overflow). R ATK 1.0
bug_simplicity The simplicity of the flaw. How easy is it to exploit the vulnerability. The possible value is between 1 and 10. 1 means that the flaw is very hard to exploit. Just a few people could do this successfully. And 10 means that the flaw is very easy to exploit. For example because there are many tools and exploits available. R ATK 1.0
bug_impact The impact of a successfull exploitation of the flaw. The possible value is between 1 and 10. 1 means that the flaw has a very low impact (e.g. just getting some "useless" data). And 10 means that the flaw has a very large impact (e.g. getting root access). R ATK 1.0
bug_risk The risk of being striked by the flaw. The possible value is between 1 and 10. 1 means that the changes for getting hit by the flaw is very low. And 10 means that the flaw could be exploitet every second. R ATK 1.0
bug_nessus_risk The risk level documented by the open-source Nessus vulnerability scanner. R ATK 1.0
bug_iss_scanner_rating The rating documented by the commercial ISS Scanners. R ATK 1.0
bug_netrecon_rating The rating documented by the commercial Symantec NetRecon vulnerability scanner. R ATK 1.0
bug_check_tool Which vulnerability scanner (e.g. Nessus, ISS Internet Scanner, Symantec NetRecon, GFI LanGuard, SATAN, SAINT) oder attack tool is also able to detect the existence of this vulnerability. R ATK 1.0
source_cve The CAN or CVE number of the vulnerability. So the user could find additional details to the flaw. R ATK 1.0
source_certvu_id The CERT Vulnerability ID. R ATK 2.0
source_cert_id The CERT ID of the vulnerability. R ATK 1.0
source_uscertta_id The CERT ID of the vulnerability. R ATK 2.0
source_securityfocus_bid The SecurityFocus BID (bugtraq id) of the vulnerability. R ATK 1.0
source_osvdb_id The Open Source Vulnerability Data Base (OSVDB) ID. R ATK 2.0
source_secunia_id The Secunia ID of the vulnerability. R ATK 1.0
source_securiteam_url The SecuriTeam.com URL of the vulnerability. R ATK 1.0
source_securitytracker_url The SecurityTracker.com URL of the vulnerability. R ATK 2.0
source_scipid The scipID of the vulnerability. R ATK 1.0
source_tecchannel_id The tecchannel ID of the vulnerability. R ATK 1.0
source_heise_news The Heise News ID of the vulnerability. R ATK 1.0
source_heise_security The Heise Security ID  of the vulnerability. R ATK 1.0
source_aerasec_id The AeraSec ID of the vulnerability. R ATK 1.0
source_nessus_id The NessusID of the vulnerability. R ATK 1.0
source_issxforce_id The ISS X-Force ID of the vulnerability R ATK 2.0
source_snort_id The SnortID of the vulnerability. R ATK 1.0
source_arachnids_id The ArachnIDS ID of the vulnerability. R ATK 2.0
source_mssb_id The Microsoft Security Bulletin ID of the vulnerability. R ATK 2.0
source_mskb_id The Microsoft Knowledge Base Article ID of the vulnerability. R ATK 2.0
source_netbsdsa_id The NetBSD Security Advisory ID of the vulnerability. R ATK 2.0
source_rhsa_id The Red Hat Security Advisory ID of the vulnerability. R ATK 2.0
source_ciac_id The CIAC ID of the vulnerability. R ATK 2.0
source_literature A list of literature for further investigation. R ATK 1.0
source_misc Other sources that could not be listed in the other source fields. R ATK 1.0

The supported fields in an ATK plugin

Example for a banner-grabbing plugin

We want now realize a simple plugin that checks the banner of a Mail Transfer Agent. First we fill some lines that describe the basic data of the plugin itself:

01 <plugin_id>5</plugin_id>
02 <plugin_name>SMTP Sendmail enumeration</plugin_name>
03 <plugin_family>SMTP</plugin_family>
04 <plugin_created_name>Marc Ruef</plugin_created_name>
05 <plugin_created_date>2003/11/10</plugin_created_date>
06 <plugin_version>1.0</plugin_version>
In the first place we specify the plugin_id (line 01). This is field required an defines an unique number with this somebodies reference could be very shure.

The plugin ID is very useful when you talk about a specific plugin and don't wan't to be confused. But for humans it is easier to talk in sentences, so the next needed line describes the plugins name (line 02). This should be a short description what is done. Good examples are "Proxy gopher support detection" or "Monkey Webserver POST Denial of Service". Very bad are too short names as "Apache bug" or too long sentences as "PeopleSoft PeopleTools 8.x IClient Servlet Remote Command Execution if no firewalling is given".

Next is the plugin family given (line 03). All plugins underlies a family. These are used if you want to find a specific plugin, don't know the ID or name. So you could group the plugins by family and just search through a few plugins. Furthermore scanning a host for specific bugs is possible. For example if you found just an open FTP server, you don't have to load all SMTP plugins. Running the plugins from the FTP family would be enough for the first look.

The next tree lines (04 to 06) tell us something about the plugins history. Who created the plugin (line 04), when was it created (line 05) and which version is this (line 06). These information are just recommended.

The plugin working core

Lets look at the core part of the plugin:

07 <plugin_protocol>tcp</plugin_protocol>
08 <plugin_port>25</plugin_port>
09 <plugin_request>open|sleep 3|send QUIT\n|sleep 3|close</plugin_request>
10 <plugin_trigger>Sendmail</plugin_trigger>
We have to define the protocol for the check (line 07). Possible values are tcp and udp. At the moment just tcp is supported. Because of this, the plugin_protocol field has at the moment no impact. In the future icmp and other protocols may be supported.

The next line defines the default destination port of the check (line 08). This value is a suggestion by the software and it could be changed temporarily in the attack editor during software runtime. The default value should be this one which is most useful. For example define 21 for ftp, 22 for ssh, 23 for telnet, 25 for smtp, 80 for http and so on. An official list of port numbers is given out by IANA.

The plugin_request line is the heart of the plugin (line 09). Here is the routine defined, how to check for the vulnerability. This routine works like a batch-script. ATK processes every single command. The commands are separated by the pipe symbol (|). The following table shows the possible commandos in the request field.
 

Command Description
open Opens a connection to the destination host and the destination port. Every network connection has to start with this command.
sleep <seconds> Lets the plugin sleep for some seconds. The parameter defines how long to sleep in seconds. Possible values are from 0 to n. If no parameter is given, the software sleeps as long as the default sleep value is set (e.g. 3 seconds).
send <datastring> Sends data over an established connection. Newlines are realized with \n. So for example if you want to send the smtp command HELP to the mail server, you have to take "send HELP\n". Typically http requests end with two newlines (\n\n). If no datastring is given, the command sends just one newline over the established connection. This is usefull to prevent connection timeout.
icmp_alive Verifies the ICMP reachability of the target host. Mostly used in denial of service checks.
pattern_exists Checks if the pattern exists in the response. Important part of every trigger based check.
close Close the established connection to the destination host and the destination port. The socket is freed and could be used for another connection attempt. Every network connection has to end with this command.

The possible commands in the plugin_request

After processing the commands given in the plugin_request the target host normally sends back some data. The next line named plugin_trigger (line 10) holds the trigger for the check. If the string in this field can be found in the server reply, the flaw is classified as found.

Information about the vulnerability

Now is time to server additional data about the check and vulnerability:

11 <bug_affected>Sendmail mail transfer agents</bug_affected>
12 <bug_not_affected>All other mail transfer agents<bug_not_affected>
13 <bug_vulnerability_class>Enumeration</bug_vulnerability_class>
14 <bug_description>An attacker who is able to get a direct connection to the port can identify the banner of this mail server as Sendmail. By this knowledge further enumerations and attacks are possible.</bug_description>
15 <bug_solution>A service if not needed should be de-installed or disabled. If this is not possible, an access control list (ACL) with firewalling should be applied to this port. Do not allow the web server to include sensitive data (e.g. web server name and version) into the 404 Not Found report.</bug_solution>
16 <bug_exploit_availability>Yes</bug_exploit_availability>
17 <bug_remote>Yes</bug_remote>
18 <bug_local>Yes</bug_local>
19 <bug_severity>Low</bug_severity>
The lines 11 and 12 list systems, software or versions that are affected or not affected by the bug. It helps prevent false positives and false negatives. This information is also useful for upgrading to know which software version is not vulnerable.

In the bug_vulnerability_class is the flaw classified (line 13).
 

Class Description Example
Buffer overflow Classical bufferoverrun that can lead to Denial of Service or arbirtraty code execution Microsoft Windows RPC DCOM bufferoverflow. This one was exploited by the famous W32.Blaster.Worm in 2003.
Configuration Configuration mistake or weak configuration Forget to disallow directory listing on a web server.
Cross Site Scripting Run active content in the web server context A relatively young and underestimated vulnerability class.
Denial of Service Slow down, restart or freeze a software so legitimate user couldn't use the service anymore Microsoft Windows 9x WinNuke vulnerability. Many bufferoverflows could cause denial of service. But only DoS classification should be done if no arbitrary code could be executed.
Evasion Prevent an Intrusion Detection System (IDS) from detect an attack or intrusion BlackICE PC Protection is not able to prevent Cross Site Scripting if PUT requests are used. See scipID 104 for more details (german).
Format String Insert format strings into a buffer to create a strange behavior of the software
Missing Authentication An authentication should be done but isn't Microsoft IIS 6.0 Admin Interface missing session-keys.
Missing Encryption An encryption should secure sensitive data. But this is not done- BlackICE PC Protection sends sensitive data in clear text over the network during upgrade request. See scipID 295 for more details (german).
Race Condition In a race condition it is possible to get a privilege escalation
SQL Injection It is possible to inject SQL commands over a web site
Symlink A symlink attack may be possible to get a privilege escalation
Unknown The classification of the flaw is not possible
Weak Authentication A weak authentication is realized A weak authentication is given if there is just a username required (e.g. SNMP).
Weak Encryption A weak encryption is realized A weak encryption would be if a proprietary product uses ROT13 for exchange sensitive data.

The possible vulnerability classification

In the lines 14 and 15 is the main information of the plugin given. The bug_description holds the information, what product it is and what is the problem. In the bug_solution are possible countermeasures documented.