Deception Toolkit V0.8

DTK V0.8

Well... someone went and anounced DTK on a widely read location, at which point lots of people started to install it - at which point lots of questions (and improvements) came in. V0.8 mostly reflects those improvements. Like... I fixed a few hard coded fc at all.net entries (I sure don't want email on breakin attempts to your sites)... I added more informative error outputs to the bind calls (so you can tell what port is in use when you get an error)... I fixed a stupid entry in the download.html file (should read 365 - not 507)... you get the idea. I am also including my hacked up version of telnetd from the Linux distribution. Be warned it will likely fail on anything but Linux - is not really trustworth - etc. I also got the usual set of complaints about this being a crude hack that nobody in their right mind would use if it weren't so darned useful - and the occasional thank you from someone who was able to track down the attackers or began to notice all those scans for port 23456 and so forth - you're very welcome - catch a few attackers for me won't you.

Now on to some more interesting things... At least one installation is using the infocon information from DTK on a network with more than 70 computers and running lots of off-the-Internet attacks against them. Nearly real-time coordinated response is now working to a limited extent - takes less than 1% of computing and communications bandwidth under extremely severe attack (several machines on the same LAN running attacks as fast as they can) and generates group responses in less than 30 seconds - I am pushing to get the code for this released ASAP but it is not in this distribution.

The notify.pl script has been fixed for several versions of Unix to reflect the placement of their mail programs.

Many of the response files have now been instrumented with InfoCon information. This provides far better alerts against real attacks than the previous versions. We hope to instrument InfoCon levels for many attacks in the near future.


How to do it:

It's all automatic in the new distribution.


From DTK V0.7

Finally - udplisten.pl now works!!! UDP forgeries are ready to be developed in ernest - and thanks to uidzero and their crew, we are starting to put up credible deceptions for several UDP ports. We are now able to detect tftp /etc/passwd attempts.

DTK Version 0.7 adds improved deceptions for http attacks (port 80) including a nicer .phf form thanks again to uidzero. We have also added UDP deception states to all of our response scripts.

A new program - udptest.pl allows you to send a packet and get one back from a UDP port on a machine. This is useful for testing UDP services - especially one-shot services - and can also be used as a simple port scan.

Please note that the UDP deceptions are highly unstable. In fact, I am considering a very different UDP response file format to allow them to handle binary information that is far more common in UDP datagrams than in TCP datagrams. This will be necessary in order to handle tftp and other similar protocols.


How to do it:

Nothing to it - it's automatically configured when you use Configure. Just use the dtk.rc.local file to get it going and whatever services are not otherwise used will have UDP deceptions.

UDP deceptions are stateless for now, which means that there is only one state in the nnn.response files for UDP. That state is indicated by the string "UDP" as the state code. For example:

# port 1111 - UDP only (non-existent) response
# state input	next	cont	crlf	message
UDP	/passwd/	UDP	1	cat	@fake.passwd
UDP	ERROR	UDP	0	1	:bad input
UDP	NIL	UDP	0	1	:no input

Since this state name is unlikely to be used (and we don't use it) in our state codes, you can have services that operate for both UDP and TCP by simply adding the UDP state codes to the response files.

udptest.pl provides simple UDP tests. HEre is an example of a port scan:

for i in 1 2 ...; do udptest.pl -h 1.2.3.4 -p $i -m "test message";done

From which you get responses like:

UDPtest 1.2.3.4:1 <= test message => recv: Connection refused
UDPtest 1.2.3.4:2 <= test message => recv: Connection refused
...
UDPtest 1.2.3.4:12345 <= test message => 1.2.3.4(12345) said sorry
...

An even more interesting response would be this one:

UDPtest 1.2.3.4:1 <= test message => recv: Connection refused
UDPtest 1.2.3.4:2 <= test message => recv: Connection refused
...
UDPtest 1.2.3.4:12345 <= test message => 7.8.9.5(12345) said sorry
...   

Notice that the response came from a different IP address! A UDP response IP address forgery. Just thought you would want to know...

udptest.pl -? give the help message:

udptest.pl [-? | -h host | -p port | -m message]+

...and then does the default command (why not?):

udptest.pl -h 1.2.3.4 -p 1111 -m "cat /etc/passwd"

Note that udptest send a single UDP datagram and waits for the response - forever... The default is likely to wait a long time before the non-existent host 1.2.3.4 sends you a packet - and it will also send a UDP packet out into the infrastructure - producing almost no real effect.


DTK V0.6

DTK Version 0.6 adds the 'slowly' pragma to 'orders'. Slowly is used to make things happen at a slower rate. This can simulate a slow machine, or be used to intentionally make things that you don't want to happen quickly happen more slowly. It also includes Syslog support and deceptions for Back Orafice and NetBus Windows-based attacks.

V0.6 also adds logging of accesses by IP address and retrieval of roll-up information from these log files via the deception port in a manner similar to that of InfoCon information. This is particularly helpful in rapid remote analysis of incidents across a network. For example, by asking a series of machines for this listing, you can very quickly correlate breadth-first search attacks on a network, find class C and class B networks that are using multiple addresses to attack, and drill-down to gather all the details from the entire network on activities from a particular IP address or set of addresses. The ultimate objective is to determine where an attack is coming from and switch an entire network to deceptions or denial for that IP address untill the attack wanes. Thus even if a machine has a legitimate service on a particular port, it can find out from the rest of the network that a remote host is attacking and switch the legitimate service over to a deception.

V0.6 also adds time-based passwords (also can be used in a use-based mode if desired) and the utility program tbp.pl. TBP allows remote systems to authenticate themselves automatically over time without reuse of the same old passwords. TBP is based on the md5 hashing algorythm which is used to hash a monotonically increasing integer on an IP-address by IP-address basis. The hash is formed from the secret key appended to the time in miliseconds from the beginning of time. When TBP is chosen as the basis for remote authentication, the TBP key is taken from the user and provided to the system components as part of the configuration process. Remote systems get a copy of tbp.pl and run the program to generate a valid key to fetchin information. For example, I just typed tbp.pl and got this string:

If I send this as a response to a request for a TBP hash -AND- the remote system shares my secret key -AND- the time (e.g., 909870941) is further advanced than the current time specified for the IP address I am coming from, I will be authenticated -AND- the time stamp for my IP address will be set to the new value. Thus, authentication reuse is impossible, time always advances, but absolute time within some select set of bound is not required. If desired, time could simply be incremented by 1 on each use, and thus we would have use-based passwords. The scheme also avoids denial of services because the time specified for the IP address is only advanced if the authentication is valid. It has the limitation (feature?) that only pre-specified IP addresses can authenticate themselves with TBPs.

How to do it:

If you place a line like:

!	slowly	10	# ten second delay for each response - we are slow...
in a response file, it will cause a 10 second delay after each input before providing output. Choose another integer (less than the timeout value) and it takes that long. This was motivated by the Teergrubbing FAQ (http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html) which suggests that to reduce SPAM, we could all have our mail recievers send a few million bytes of comment (e.g., the following)
250-This is Sendmail version 8.8.5
250-This is Sendmail version 8.8.5
250-This is Sendmail version 8.8.5
250-This is Sendmail version 8.8.5
250-This is Sendmail version 8.8.5
250-This is Sendmail version 8.8.5
250-This is Sendmail version 8.8.5
...
250 OK to go now
You do this for all known spam hosts. The result os that to the normal mailer, it slows things down but does not block functionality, while to the SPAM site which is connecting to millions of hosts doing the same thing, it would wreak havvoc. It turns out that if you want to avoid spam from a known host it's probably better to simply tell the host that there is no such user (in your reply to the 'mail to ' input, but the idea of slowing things down has virtue, so we put it in.

Syslog support is used by specifying Y (sYslog) as the audit option in the Configure program.

Back Orafice and NetBus deceptions correspond to ports now added to the dtk.rc.local file. On system reboot, this file is normally executed and the deceptions are engaged.

One-time-pad generation improvements are transparent upon use of Configure to configure DTK.

IP address logging is automatic and stored in the IP directory under the directory used for the rest of DTKs activities. This logging uses the same format as is in use for other logging activities. This is not done when SysLog logging is used. Unlike the normal log file, these files are not backed up and cleaned out when a new dtk configuration is loaded. Fetching this information remotely is demonstrated in the 365.response file delivered with DTK.

TBP services are implemented by selecting TBP as the authentication scheme and specifying a password. The DTK_PASSWORD field in response files is then used to require an authentication. To authorize an IP address to do TBP authentication, you must create a file in the installation directory (typically /dtk) with the name TBP.ipaddress where ipaddress is the IP address of the remote host being authenticated. For example, the file TBP.1.2.3.4 would authorize TBP authentication from 1.2.3.4 - if place in the DTK installation directory. Initial file contents can be set to the character 0 (zero) to assure that the first authentication will work. From then on, time will move with the remote system's time. To be useful, you should copy the tbp.pl script and the md5 executable to the remote system to be authenticated. From that system authentication is generated by running tbp.pl - the results of which can be sent for authentication to systems running TBP.


From DTK V0.5

DTK Version 0.5 improves the InfoCon capability by allowing the response file to specify infocon levels directly and adding syslog support as a logging option.

It also adds deceptions for Back Orafice and NetBus Windows attacks amd improves the generation of one-time-pads by not regenerating pads if a one-time-pad already exists.


How to do it:

Infocon levels can be set explicitly from within any response script by prepending I? to the CRLF field where the ? is any digit (0..9). For example, I60 indicates infocon level is set to 6 and CRLF is treated as if it were '0'.

Syslog support is used by specifying Y (sYslog) as the audit option in the Configure program.

Back Orafice and NetBus deceptions correspond to ports now added to the dtk.rc.local file. On system reboot, this file is normally executed and the deceptions are engaged.

One-time-pad generation improvements are transparent upon use of Configure to configure DTK.


From DTK V0.4

DTK Version 0.4 enhances DTK's functionality by providing capabilities for one-time passwords and algorithmic passwords to modify access controls (for example, an authorized user from the Internet can tell a deception to turn off and the real service to turn on), for access controls to be altered by other state transition (such as access being automatically removed to all services for an attacker who has gained a password file), and logging of the last change in the identified threat level (the InfoCon). The InfoCon state, as well as the history of the DTK log file can be remotely fetched using the decption port (365) or other deception services.


From DTK V0.3

DTK V0.3 is a substantially improved and enhanced version of DTK. It enhances previous deception techniques by adding automated programmable response capabilities that permit automated reconfiguration of systems when under attack, remote retrieval of deception logs from networked hosts to allow for big-picture detection and analysis of attack patterns, it includes better installation for more common operating environments, and it has a new database interface to allow logfile information to be placed into and analyzed in a database pogram.

DTK V0.3 is freely available for individual and research use and may be inexpensively licensed for corporate or government use. It can be distributed and redistributed without royalty, provided that all copyright notices are left in tact and no corporate or for-profit use is made of it. There is one non-corporate exception to this free license to use DTK. Anybody that uses it to attack systems or find weaknesses for others to exploit or does anything else with DTK that tends to produce inconvenience for non-attackers, is required to pay a royalty of US$250 per copy to me - including a fee, of course, for each updated copy, backup copy, other copy made, copy seen, used, or whatever else. Crime costs.

Those who use and like DTK for defense are encouraged to send $3 per computer with DTK installed (or more if you really like it a lot) to me (check or money order would do nicely) to support this good work, or to send improvements and updates, deception scripts that detect new attacks, and so forth. If they are useful, we will include them - subject of course to the same copyrights, terms, and conditions used in the rest of DTK.

The official home of DTK is at http://all.net. Comments are invited (send nice things to fc at all.net - complaints and harassment go to nobody@nowhere.org).


New in DTK V0.3

New features in version 0.3 include:
DTK V0.2
Augments DTKv0.1 to add deception for most of the commonly used services (telnet, ftp, smtp, chargen, daytime, NTP, finger, http, gopher, and others). It also has an easier installation procedure and several other enhancements that you can read about below. DTK is increasingly effective at reducing the threat from 90% of today's attackers.

New in DTK V0.2

New features in version 0.2 include: