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.
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:
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).
|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:
|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
|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>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.
02 <plugin_name>SMTP Sendmail enumeration</plugin_name>
04 <plugin_created_name>Marc Ruef</plugin_created_name>
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>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.
09 <plugin_request>open|sleep 3|send QUIT\n|sleep 3|close</plugin_request>
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.
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
|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>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.
12 <bug_not_affected>All other mail transfer agents<bug_not_affected>
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>
In the bug_vulnerability_class is
the flaw classified (line 13).
|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.