Exploit and intrusion automation tools - An introductory FAQ by Mixter http://mixter.net/papers.html August 2001 Security applications -- and code in general -- with the ability to automate the processes of remote network penetration, intrusion, and the necessary information gathering and -evaluation tasks, are starting to become more publicly available, and more sophisticated. On one hand, this FAQ will try to show in what forms and for what purposes we may be going to see intrusion automation software in the near future, hopefully informing and raising awareness for IT security enthusiasts, professionals, and system administrators, and encouraging them to make practical experiences with related security tools as they become available. However, I'm also abusing it as a pre-announcement of the upcoming release [1] of my own intrusion automation software, which I named "NEAT" (Network Exploit Automation Tool). The intention isn't merely self-promotion. I'm doing it this way to publish the tool in a manner as responsible as possible. At the time at which the first intrusion automation tool becomes available to the public, inevitably also falling into the hands of blackhats, it will be important for the admins and the security community to start understanding and using this intrusion automation software at the same time. Finally, as the field of intrusion automation is starting to get more publicity, I'm also hoping to mitigate FUD and misinformation of the media (both intended and accidental), by presenting objective technical viewpoints and full-disclosure perspectives regarding intrusion automation technology. ----------------------------------------------------------------------------- Q: What is the incentive for releasing intrusion automation tools right now? I've been sitting on mine for some time; the reason for thinking about a release now is that closed-source and non-public intrusion automation software is starting to become more widely available right now: 1) In the form of a few private, unreleased underground "kit's", most of them being poorly coded scripts which tie a few exploits and backdoor-installing shell commands together, but which serve their purpose nevertheless. 2) In the form of commercial, closed-source intrusion automation software for security professionals. While I don't oppose these products, they are pretty much certain to fall into the wrong hands eventually, hence making the existence of free-for-all open-source intrusion automation software necessary, to prevent too much work behind closed doors, which might bring an arms-race lead for the blackhats, so to say. [2] 3) We're seeing a general increase in worm-related incidents, since the last few months or so. I'm not going to jump on the C*de-R*d paranoia bandwagon, however, worm scenarios of this type are first examples of simple, static exploit/intrusion automation code in action. For Unix and Non-Unix platforms, we are seeing more nasty things that spread automatically through server vulnerabilities from open SMB shares to buffer overflows, being much more autonomous than the past waves of MS-trojans, for example. My point is that internet worms already contain early, simple "remote exploit automation" features. ----------------------------------------------------------------------------- Q: How could intrusion automation tools possibly be designed? Various designs are possible, here are a few examples I can think of: Example: A single application containing all data and routines necessary for performing known exploits, information gathering methods, and other intrusion methods. Example: A worm, cycling through the automated steps of scanning, remote exploiting, and infecting/replicating. Example: A modular application that only automates one step of the whole process of system penetration and intrusion (like NEAT). Example: An AI that evaluates and choses its targets, attack methods, and "special maneuvers" (like firewall circumvention, IDS evasion, brute force discovery, etc.) based on intelligent guidelines. Example: An extensible application that uses a scripting language and vulnerability database to determine its behavior (like NEAT). To understand what tasks could possibly automated as part of an intrusion, let's take a look at all possible steps of an intrusion: 1. Searching for targets: Host / Network discovery 2. Detecting security measures: Probing for IDS/firewall presence 3. Evading security measures: circumvention/obfuscation techniques 4. Target analysis: port/banner/application protocol scanning 5. Evaluation: determining vulnerabilities and appropriate exploits 6. Attack: using exploits, bruteforcing, and other means of intrusion 7. Privilege elevation: compromising internal security from inside the host 8. Spying: sniffing data, abusing trust relationships, LAN access, etc. This is a basic outline of what is possible. Worms usually automate the steps 1, 4, 5, 6 and 8 in a simple, static way. Network scanners usually only do step 4 (you could argue that NMAP does a little bit of 1-4, however). My tool, NEAT, is primarily designed to automate steps 5 and 6 in a flexible and configurable manner. NEAT could automate steps 4 and 7 as well, though it may be less efficient at it than other smaller tools designated for that. ----------------------------------------------------------------------------- Q: What are future goals of NEAT? Personally, I'd like to aim toward a open database and script language standard or format for professional open-source exploit automation tools, if and when they are starting to be deployed by whitehats. Intrusion and exploit automation tools are at their very beginning right now. In the future, they may be used for periodical security assessments of the own hosts and networks, with automatic vulnerability updates. Ideally, exploit automation tools would eventually "join forces" with full-disclosure resources such as vulnerability mailing lists, the Securityfocus database, MITRE's CVE [3] system, and other free resources. ----------------------------------------------------------------------------- Q: I find this irresponsible. Won't you be starting an arms race? The problem is that this arms race has already begun, by similar tools being privately available for some blackhats, but not for most whitehats. So the "bad guys" may already be leading this arms race. Intrusion automation software, if sophisticated enough, can be an important tool to improve security, not to destroy it. When people start to accept that, the open-source community will move in, improving odds for the whitehats in this arms race. Distribution of professional automation software to a wide community of admins and security conscious people can help them to protect and secure themselves before the bad guys will strike with similar means. ----------------------------------------------------------------------------- Q: What are the benefits of closed-source automation tools? Wide-spread distribution and use of the tools will be initially delayed. Also, more security professionals than blackhats will have them as long as the distribution can be controlled. But there is still a high risk that they will eventually get into the hands of blackhats. ----------------------------------------------------------------------------- Q: What are the benefits of open-source automation tools? They will be available to all the good guys and all the bad guys from day 1. Hence, awareness about them will raise faster, so more whitehats will use them; and rather sooner than later. Therefore, security tests can be done more actively and easier. The less sophisticated "script kiddies" who are high in numbers may need some time to adapt to the new software. ----------------------------------------------------------------------------- Q: And why won't your tool benefit primarily the script kiddies? It won't be just a proof-of-concept tool, but neither designed for foolproof use by unsophisticated people. It has also not gone through a lot of general testing yet, so there is much room for improvement. Eventually, it may become a sophisticated tool indented for professional use -- like remote penetration testing, and securing your own sites by actively breaking into them. I'm NOT going to include any stealth features such as spoofing, shellcode polymorphism, IDS evasion, and such, so that every IDS should be able to detect the standard remote exploits whether they are launched by NEAT or not. Quite possibly, there will also be NEAT specific IDS signatures. Also, I realize that the open-source release is controversial. To understand my perspective, think back to the time when the first network security scanners were released. As far as I know, among the first network scanners were the ISS scanner, designed to check, and attack, a handful of services. ISS [4] was a commercial scanner from the beginning, designed for white-hat use by security professionals. However, many people saw this differently. At that time, scanners like ISS were a new threat to the internet; CIAC, CERT and other organizations released warnings and advisories about it [5]; and it's author may have been seen by some people as grey-hatted renegade coder... I'd like to point out the fact that ISS is and was a commercial tool, with precautions and protection mechanisms in place. However, it leaked to the underground sooner than later -- as I think commercial exploit automation tools will do, too --, and older versions of it count to the most widespread commercial security tools available as pirated software... even today. There was also what I'd see as early roots of the full-disclosure movement, oriented around articles like "Securing your own site by breaking into it", and the earliest open-source scanners like SATAN. Over SATAN -- nowadays a humble, simple, and very outdated tool -- there was even more of a controversy, wave of alerts and advisories, FUD, and media hype. Yet, network scanners, both open-source and commercial, are commonplace today, deployed by all penetration testers, security companies, owners of big networks, security conscious administrators and an army of other open-source geeks. Today, few if any would argue about the many positive effects of having a multitude of open-source security scanners available. ----------------------------------------------------------------------------- Q: What will be the legal details of your release? It will be open-source according to the GPL (as you might have guessed...). NEAT will be (c) by me, and my company, 2XS Security, although I am the single author of it. I'm saying, although the GPL legally disclaims an author's responsibility for what is being done with a program, if anyone wants to point fingers at someone for this release -- point them at me, not at my company. It will also be a noncommercial release, meaning that the program may freely be spread and distributed without permission, unless used in a commercial environment, however. As to the legality of using and possessing NEAT for legal and educational purposes, that may become a problem once the cybercrime treaty is implemented (as well as any other security program, however). I just had to mention it SOMEWHERE. Down with the cybercrime treaty. Of course, GPL means that you can change a program and re-publish it, but please think just a few minutes about it before you change this into a "scriptkiddy-friendly" application loaded with stealth features, which it really isn't right now, and which I hope it won't become. ----------------------------------------------------------------------------- Q: How can automated attacks be prevented and protected against? DDoS attacks and all the related traffic, for example, is much harder to detect. Early intrusion automation tools will facilitate the processes of intrusion, but their remote traffic is identical with the standard exploits, containing all the patterns of known information gathering tricks, and of known exploits. Wide deployment of IDS solutions, especially at backbones and bigger ISPs, can therefore be seen as a viable solution for defense. Smart agents, with easy options for making traffic polymorphic, may appear, but at this time, that's nothing more than speculations. In any case, the easiest prevention against any automation tool will be to run the tool against one's own hosts or networks regularly. ----------------------------------------------------------------------------- Q: Are you saying exploit automation will be "the next big thing" in security? In any case, it is becoming an area of rapid technological development. Simple and early forms of DDoS were around for a long time; approximately since people used to log in to multiple shell accounts manually in order to hit a single target from different sites. I would argue that intrusion automation techniques were around for an equally long time too, if not longer; perhaps since the first scripts for testing a multitude of different exploit techniques were around, such as the first batch scripts written for VMS/VAX in the late 80s. The most important point is how sophisticated, feature-rich and widespread an IT-security related technology becomes, while it's basic concept could be known for a long time, or could have been used implicitly. With the growing interest in both black- and whitehat communities for intrusion automation and generally, more sophisticated intrusion-/ penetration testing tools growing, intrusion automation is predestined to grow more sophisticated and feature-rich in the long run. Calling intrusion automation the "next big danger to the Internet" would be inaccurate and very simplistic, however. Intrusion automation could soon become our friend! Widely available active penetration testing software, automatic patching software and more could drastically improve Internet security globally, taking care of nasty problems such as the DDoS potential of insecure networks as a side effect. Intrusion automation might even be legally deployed in order to beat future worms, by patching de-facto vulnerable hosts or alerting their admins automatically, on the fly... by using fire against fire. ----------------------------------------------------------------------------- References [1] http://mixter.warrior2k.com or http://mixter.void.ru [2] http://www.securityfocus.com/templates/article.html?id=224 [3] http://cve.mitre.org [4] http://packetstormsecurity.org/UNIX/audit/ISS/iss13.tar.gz [5] http://www.cert.org/advisories/CA-1993-14.html