Brief history of the ATK

In the beginning was the Dante Security Scanner

A long time ago I started to be interested in computer sciences. At the age of 12 I began to programm my own applications and games because I could not afford commercial software for my IBM XT/AT with MS DOS 3.1. As I started coding little tools to handle my operating system more efficient, I get in touch the first time with computer viruses. I was very impressed of the idea of creating a piece of code that would be able to reproduce itself. My obsession for IT security has begun.

Checking a system for potential and existent vulnerabilities became more and more important for me. Thus, it is no surprise I played around with SATAN, one of the first security scanners. From todays point of view SATAN was a very simple tool that was able to detect misconfigurations in hosts. Within a few minutes an administrator was able to get a picture of the network security of his system. Other security applications supported this idea of hardening and fixing a productive host.

As I began working as a security consultant in 2000 the open-source solution Nessus was one of my favourite vulnerability scanners. Fast and reliable was the handling of Renaud Deraisons well known project. Because I was always interested how these security scanners work, I began developing my own solutions. The first public release of such a software was the Dante Security Scanner.

Dante was written in Bash, supported dedicated plugins for checks and provided a handy web frontend. Users were able to connect to a web server that provided the Dante Security Scanner to check their systems or other hosts for known vulnerabilities. Just a bunch of checks were made because the plugin developement was not easy. Too hard was it to create new shell scripts that would be able to detect new flaws. Dante Security Scanner 2.1 was the last version I published but this piece of software was just a test run for my real idea.

The Attack Tool Kit was born

I published many papers on IT security, found a bunch of new vulnerabilities and published advisories, wrote my own security tools and exploits. I did this always in mind to create my own mighty security scanner one day. In August 2003 I began the developement of a tool with the name ATK. The acronym ATK stands for Attack Tool Kit because the software should provide a handy environment to create and start (semi-)automated attacks.

I started my proof-of-concept as a Visual Basic 6.0 project, because my skills with the Microsoft programming language allows me to create software very fast. After a few hours I get my first running version of the whole ATK idea. The user was able to specify a target, to select a specific check and to start the attack. I tought an internal attack editor would be very nice so the auditor would be able to make modifications of the attack during runtime.

This first running version of the ATK was really very handy: No useless icons, no good looking features - Just the core part of the exploiting software. The hardest part of the first steps were the developement of a handy but powerfull scripting language. It should be possible to create a plugin with just a bunch of commands. So I decided to implement commands as like open for opening a connection, sleep to wait a specific time, send for sending data to the target and close to close the established connection. After the request script was run, the ATK compared the responses by the target with the trigger that was saved in every plugin. If there was a match, the attack was successfull and/or the vulnerability was found.

Well, I was impressed by the plugin based architecture many security scanners come with. That is why I also adapted this concept in the Dante Security Scanner project. But in the first phase of the ATK project I took another way. The checks were saved in a single file were a plugin was written on every line. The different fields were seperated by tabs:

1 HTTP 404 enumeration tcp 80 open|sleep 3|send GET /404check.html HTTP/1.0\n\n|sleep 3|close 404 Not Found Enumeration Information The web server responds with an 404 Not Found error message. An attacker may indicate the existence of web documents. He could gather sensitive data. Do not allow the web server to include sensitive data (e.g. web server name and version) into the 404 Not Found report.          Yes Yes Some vulnerability scanner (e.g. Nessus) are able to check this flaw.
2 HTTP Apache tcp 80 open|sleep 3|send HEAD / HTTP/1.0\n\n|sleep 3|close Server: Apache Banner-Grabbing Information An attacker who is able to get a direct connection to the port can identify the banner of this web server as Apache. By this knowledge further enumerations and attacks are possible. 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. And if possible change the welcome banner to confuse an attacker and give him false information.          Yes Yes

Well, I was not really happy with plugin concept of the first running version of the ATK. Creating new plugins by hand (e.g. using an ASCII editor) was not easy - The flat plugin data base was becoming a mess with every new plugin line I wrote. I realized that it would make sense in a long-term thinking to change the plugin handling to a real dedicated plugin based concept. Every check should be saved in a specific ATK plugin file. The change management of the whole plugin repository would be much easier in the future. But this was hard for me. Re-writing the whole plugin interpretation part of the software trew me back a few weeks - But I've never regret this.

<plugin_id>1</plugin_id>
<plugin_name>HTTP Apache enumeration</plugin_name>
<plugin_family>HTTP</plugin_family>
<plugin_by>Marc Ruef <marc.ruef@computec.ch> http://www.computec.ch</plugin_by>
<plugin_create_date>2003/11/06</plugin_create_date>
<plugin_updated_by>-</plugin_updated_by>
<plugin_version>1.0</plugin_version>
<plugin_protocol>tcp</plugin_protocol>
<plugin_port>80</plugin_port>
<plugin_request>open|sleep 3|send HEAD / HTTP/1.0\n\n|sleep 3|close</plugin_request>
<plugin_trigger>Server: Apache</plugin_trigger>
<bug_published_by>Unknown</bug_published_by>
<bug_date_published>Unknown</bug_date_published>
<bug_advisory>Not available</bug_advisory>
<bug_affected>Apache web servers</bug_affected>
<bug_not_affected>All other web server implementations<bug_not_affected>
<bug_vulnerability_class>Enumeration</bug_vulnerability_class>
<bug_description>An attacker who is able to get a direct connection to the port can identify the banner of this web server as Apache. By this knowledge further enumerations and attacks are possible.</bug_description>
<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. And if possible change the welcome banner to confuse an attacker and give him false information.</bug_solution>
<bug_exploit_availability>Yes</bug_exploit_availability>
<bug_severity>Information</bug_severity>
<source_cve></source_cve>
<source_securityfocus_bid></source_securityfocus_bid>
<source_secunia_id></source_secunia_id>
<source_scipid></source_scipid>
<source_tecchannel_id></source_tecchannel_id>
<source_heise_news></source_heise_news>
<source_heise_security></source_heise_security>
<source_nessus_id></source_nessus_id>
<source_snort_id></source_snort_id>

The new idea of separated plugin files also changed my idea of the frontend. In ATK 0.2 the user was able to select a specific ATK plugin file. After clicking this one it was able to see the most important parts of the check.

Creating new plugins became also more and more important. I was too lazy to write them manually with an usual text editor. In ATK 0.2 I created also an attack generator. It was not very nice because too many fields were shown at the same time. The frame was also too big for some resolutions. That is one of the reasons why this oversized attack generator was not included in further versions of the software anymore...

As I started using the Attack Tool Kit in my professional security audits and penetration tests, I was missing the possibility of analyzing attacks during runtime and after they were finished. The ATK said if the vulnerability was found or not. But it was not possible to see why this decision was made internally by the software. Another frame should be made. The attack response shows the response by the target plus other usefull data of the access attempts. Further analysis of the plugin behavior were possible by now so the attack response frame was a good invention I kept also for further version of the ATK.

Back to the listview and the attack generator revisited

Just seeing the name of the ATK plugin in the main frame was sometimes a bit frustrating for me. In some cases I was not able to find a specific test. For example if I had to deal with a web server on port tcp/80 I was not interested in all the other checks for other services and ports. I went back to the listview visualisation were it was possible to sort the plugins by the most important fields. But it was still possible to get a quick overfiew of the plugin by clicking one of them.

As I have seen very early the attack generator would never win a "beautiful software contest". I sorted the fields and put the similar ones together in a frame. Creating and changing plugins became very easy and I developed just a bunch for further beta testing.

As more as I have invested time in the creation of the plugins, I realized that they need to be as efficient as possible. So I wrote special code to delete not needed fields. The plugins were much smaller and faster with this improvement. Also the needed ressources for running the ATK were not so much anymore.

The Attack Tool Kit 1.0 was ready for the public release

The official release of the Attack Tool Kit 1.0 get a few last changes before publishing. I introduced checkboxes so specific plugins could be deactevated. It was now possible to involve just the selected checks in an audit run. Because I was very unhappy with the large attack generator I droped this idea. Furthermore I did an enhancement of the attack editor that would become also a more handy version of the attack generator. And last but not least I spend a lot of time in the configuration handling. Many things of the software behavior should be changeable by the user and these settings should be saved in a file for the next run of the software. The plugin structure has been evolved enormously during the last weeks of developement. In 1.0 were also introduced a new command with the name pattern_exists. This call should be indicate that the pattern matching checking procedure has to start. This final step of most ATK plugins is not automaticly anymore and could be used on every step of an attack. This grants more flexibility and let the speed of many checks increase under some circumstances.

In January 2004, after very exhausting alpha and beta tests, the official version of the Attack Tool Kit has been released. In the first weeks the software was not very successfull. Just a bunch of people took a look at it but did not understand that the ATK is not a security scanner as like Nessus is for example. Running automated security audits was never the idea of the project so it was not a surprise other tools could fulfil this goal much better. As I have published the source code of the ATK 1.0 in March 2004 on planetsourcecode.com, the first success of the project could be seen. Just the excellent votes and many friendly comments about my piece of software gave me new energy to keep my work up.

Faster and better with the Attack Tool Kit 2.x

Just two weeks later I started the developement of ATK 1.1 with many internal enhancements. Also the plugins were optimized and now mostly twice as fast as in ATK 1.0. As in March 2004 over 90 ATK plugins were available. But I thought this enormous improvement should be published as a major release. On 31. August 2004 the Attack Tool Kit 2.0 were published. I have had over 3'000 downloads within the first week after the release. This was awsome! As I have forseen this many users would detect many minor bugs. After receiving some emails with this kind of listings I released two weeks later the ATK 2.1 wit some minor bug fixes.

The success of the ATK 2.1 made me very happy and gave me more energy for writing new plugins. On nearly every work day I have released a new ATK plugin repository - Approximiatly 10 new ATK plugins per day. In September we reached the mark of 250 ATK plugins. A milestone in the history of the project.

Towards the future with the Attack Tool Kit 3.0

I am using the ATK 2.1 nearly every day. Especially in my penetration tests they have a very important part. As I am using my software more and more I detect new things I would like to change or enhance. So I am working on the next release of the Attack Tool Kit. Because there will be some major enhancements this may be the release of ATK 3.0. I do not want to telll too much about the improvements. But there will be many things that make the handling of the tool much easier. Especially the updating of the plugins seems important to me so I try to make a very efficient and fast auto update feature.