 Deception Toolkit V1999-08-18 |
| Deception Toolkit V1999-08-18 |
DTK 1999-08-18 makes three substantial changes:
We have moved scripts into subdirectories and made provisions for dealing with multiple IP addresses on a single host with different repsonses by IP address. This - when combined with large scale multi-hosting allows us to provision (in the largest example to date) almost a whole class B set of network addresses to deceptions using a small set of hosts to do all the work. These deceptions can be varied by IP address or IP addresses can belinked to generic machine type directories.
thttpd.c has been changed for the first time in more than 5 years - to accomodate nominal headers on returned information. This makes it compatable with browsers that have recently been pushed into the market with non-standard input requirements. Please not that this change does not appear to alter any of the security properties that were in the original mathematical proofs - HOWEVER - this is no longer the proven secure version!
A minor fix was made to tcpget (my version of webget) used in our anonymizer mechanism. The anonymizer - which was added some time recently but not announced formally - provides a mechanism for building an anonymous web mechanism such as the one that operated from the all.net web site. Our anonymizer is actually a bit different from this one for technical reasons to obscure to be believed... This is UNTESTED in the dtk context.
The best move is to take your current /dtk directory and copy it to somewhere else and do a new Configure with the new DTK. You can them merge any customizations back into the /dtk/default directory and they will be reflected whenever no other directory applies. To make a custom directory for a particular inbound IP address (as an example, for 10.0.0.3):
mkdir /dtk/10.0.0.3
Then load any files you would prefer for that IP address into that directory. If DTK wants a file and it is not there, it will look in the default directory, so you only need put replacement files there. For building multi-homed multi-address deceptions, refer to recent DTK mailing list descriptions and instructions.
Previous version changes: It fixes several bugs in the FAKE_OS so that telnetd and Configure do the right thing now. It also fixes the ridiculous way telnetd worked before. It's not perfect of course, but it's better. It updates several of the install things (dtk.*) to reflect various changes in the underlying DTK since those scripts were last visited. It also removes the redundant telnetd directory from the tar file, eliminates more of the directory-dependant stuf (not the make dist or that kind of thing, but that's for maintainers only anyway).
DTK 1999-01-07 also fixes the last impediment to direct use of exec for remote authenticated login. You can now used the 'exec' call in a response file to run /bin/login - so that, for example, a 23.response file might have a line like:
1 !O 1 1 exec /bin/login
This says that once a valid one-time-password shows up in this state on this port, switch the user over to the login program and let them login using a regular UID and password. We could, for example - exec ssh for secure shell login - exec redirector to redirect them through a firewall into an internal machine they are authorized to login to - and so forth. This will only be permitted for the session that has been authenticated by the authentication method specified in the DTK configuration process. As an aside, it might be foolish to exec something like /bin/sh - since this would provide the remote user with root access to your system...
It's all automatic. The new port 23 script file uses the exec/bin/login as the default authenticated access method, while the 'special' version is kept as a comment.
V0.9 introduces the fake operating system name to the configure file and appropriate changes to deceptions to include this deception throughout the distribution. It also does automatic configuration of the secure Web server (thttpd) and generic.c and support for SCO Unix.
Most of it is automatic. For the secure web server to actually provide information, you need to create a directory called "www" in the WORKING_DIR (the directory you select for installation of DTK). To put content in the web server, place it in WORKING_DIR/www (by default /dtk/www) - with the home page called index.html - and with protections and ownerships properly set as follows:
The files must be owned by a user with UID = 100 (WWWAID) The files are accessed by a user with UID = 405 (WWWUID) Files must be protected in mode 644 Directories must be protected in mode 755To change WWWAID or WWWUID modify thttpd.c lines:
#define WWWUID 405 #define WWWAID 100
The protection settings and user IDs are intentionally defined as they are for good reasons, but they may not meet your needs. Note that changing them (or anything else about the server) may change the effectiveness of protection. Normally, the protection requirements should not be altered and the UIDs should be set to those of the non-privileged user authorized to administer the server (WWWAID) and a non-privileged user ID with no other access designed solely for secure remote access to the web server (WWWUID). Do not share WWWUID with user nobody or any other user account, and assure that you have an entry in the password file something like this:
thttpduser:*:405:100:Secure Web Server User:/dev/null:/bin/false
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@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.
It's all automatic in the new distribution.
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.
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 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:
909870941 18619820543f74cd1456b60390f8b939If 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.
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 nowYou 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
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.
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.
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.
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.
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@all.net - complaints and harassment go to nobody@nowhere.org).