####===################===#### #| Keen Veracity 3 [Oct Issue] |# *| Legions Of the Underound |* *| [1][0][1][0][1][0][1][9][8] |* ####===################===#### Transforming Minds... transformation \'trans'fer-ma'shen\vt 1: to create dramatic improvement 2: to make distinctly different 3: to alter, to trans- form 4: to progress from underdeveloped con- dition 5: to become smarter, stronger, tougher Contents: * Introduction | [dex|001] optiklenz * Q&A | [dex|002] web mail * X-Windows Security | [dex|003] runeb * Placing Backdoors Through Firewalls | [dex|004] van Hauser * Detailed Guide to Linux Security | [dex|005] Bronc Buster * HP-UX: A Security Overview, Part Two | [dex|006] tip * Attack on the PKZIP Stream Cipher | [dex|007] Pk * Coordinated TCP Attacks and Probes | [dex|008] Shadow * How to secure your WinGate installation | [dex|009] enema * AT&T/BOC Routing Codes | [dex|010] foneman * Cellular Carrier Codes | [dex|011] Herber * Packet Fragmentation Attacks | [dex|012] Cohen * Novell Netware Administration Exploit | [dex|013] Mnemonic * In the News | [dex|014] sources [optiklenz]------->Introduction From the Editor- Well here it is the release of Keen Veracity III. After a long period of procrastination we are back. We've been away for awhile doing our own thing, but now were ready to put a little more focus, and productive energy on the Legions operation. Particularly because so many changes have occurred, and are still in the process of exposing. One of those changes being the team title after talking with Nami, and an investor we are now going corporate. We are officially registered as "Legions Interactive" as consultants, and an e-commerce solutions provider. This will not transform any of the plans, and designs with Legions of the Underground. Except that more effort will be put into commercial research, and anything that had anything to do with being considered "illegal" has far been washed away. Not only because of potential investors, but because we've never really dealt with anything we thought to be illegal in the first place. No one owns the Internet, and well "password's" just get in the way of things. Who is to tell me or anyone else for that matter where we can or cannot go? Especially in an environment a lot of us are all too familiar with. Though I have these views I am forced to keep them to myself because unfortunately, and infelicitously the government does not agree with my views, and it may just be they can give a rat's ass about yours either. Ultimately I would like to see everyone co-existing, and sharing their data in synchronicity. The definition of "knowledge" is "to know", but how can we know what is kept behind locked doors? How can we learn what is locked out by passwords, and guarded by bull dogs whose only knowledge is the word "attack" or "sit". With my views There is a question of ethics, and the act of crossing the barrier. Information, and data is to be cherished, (for it can only build you not hurt you) cultivated and developed not to be annulled or locked up. Hacking is an expansive applied knowledge in any technical field. Destruction, and the unschooled acts of those who live with out moral are what separates the "hackers"(those who's main purpose of life is to learn, expand, and apply what they learn) from those that just like to "whack off". In conclusion in the midst of all this change LoU will still remain, and continue to produce Keen Veracity amongst other things. We established our presence on the net in '89 as research team, and will continue sharing every bit of data we annex with anyone who will open up to it, and take it for what it is along with following the virtuous, and keen philosophies that is essential to remain "knowledgeable". Knowledge can only be defined by oneself because in standard definition we'd all be characterized as ignorant. Knowledge is, and should be the distinction of happiness and being able to envisage, and pursue what in your heart makes you happy only then will you be able to truly prevail. Remember all data is free, and one should be able to manipulate it at their own inclination as it may very well help in the advancement of technology. If no one ever took it upon themselves to modify things, and creations for the better we would probably still be living in a technologically dark, and weakened era. It is your right to know, and apply what you desire just be aware of how you apply what you know... -optiklenz optiklenz@legions.org Legions Interactive Inc. - http://www.legions.org efNETwork: irc.cs.cmu.edu channel: #legions ^ *=========* ^ * (t)he (s)taff * *=========*------- optiklenz cap n crunch tip icer Bronc Buster sreality Zyklon havoc HyperLogik Defiant Duncan Silver Slfdstrct lothos submit articles to: webmaster@legions.org *=========*----------------------------------------- \\\useless trick of the week/// When a phone user hangs up from a calling card session if the phone is picked up quick enough, and the "*" key is pressed you will be able to continue using the card on the last users time. X-Windows Security <----------[runeb] 1. Motivation / introduction 2. How open X displays are found 3. The local-host problem 4. Snooping techniques - dumping windows 5. Snooping techniques - reading keyboard 6. Xterm - secure keyboard option 7. Trojan X programs [xlock and xdm] 8. X Security tools - xauth MIT-MAGIC-COOKIE 9. Concluding remarks --------------------------------------------------------------------------- 1. Motivation / introduction X windows pose a security risk. Through a network, anyone can connect to an open X display, read the keyboard, dump the screen and windows and start applications on the unprotected display. Even if this is a known fact throughout the computer security world, few attempts on informing the user community of the security risks involved have been made. This article deals with some of the aspects of X windows security. It is in no sense a complete guide to the subject, but rather an introduction to a not-so-known field of computer security. Knowledge of the basics of the X windows system is necessary, I haven't bothered including an introductory section to explain the fundamentals. I wrote some code during the research for this article, but none of it is included herein. If the lingual flow of English seem mayhap strange and erroneous from byte to byte, this is due to the fact that I'm Scandinavian. Bare with it. :) 2. How open X displays are found An open X display is in formal terms an X server that has its access control disabled. Disabling access control is normally done with the xhost command. $ xhost + allows connections from any host. A single host can be allowed connection with the command $ xhost + ZZZ.ZZZ.ZZZ.ZZZ where Z is the IP address or host-name. Access control can be enabled by issuing an $ xhost - command. In this case no host but the local-host can connect to the display. Period. It is as simple as that - if the display runs in 'xhost -' state, you are safe from programs that scans and attaches to unprotected X displays. You can check the access control of your display by simply typing xhost from a shell. Sadly enough, most sites run their X displays with access control disabled as default. They are therefore easy prey for the various scanner programs circulating on the net. Anyone with a bit of knowledge about Xlib and sockets programming can write an X scanner in a couple of hours. The task is normally accomplished by probing the port that is reserved for X windows, number 6000. If anything is alive at that port, the scanner calls XOpenDisplay("IP-ADDRESS:0.0") that will return a pointer to the display structure, if and only if the target display has its access control disabled. If access control is enabled, XOpenDisplay returns 0 and reports that the display could not be opened. E.g: Xlib: connection to "display:0.0" refused by server Xlib: Client is not authorized to connect to Server The probing of port 6000 is necessary because of the fact that calling XOpenDisplay() on a host that runs no X server will simply hang the calling process. So much for unix programming conventions. :) I wrote a program called xscan that could scan an entire subnet or scan the entries in /etc/hosts for open X displays. My remark about most sites running X displays with access control disabled, originates from running xscan towards several sites on the internet. 3. The localhost problem Running your display with access control enabled by using 'xhost -' will guard you from XOpenDisplay attempts through port number 6000. But there is one way an eavesdropper can bypass this protection. If he can log into your host, he can connect to the display of the localhost. The trick is fairly simple. By issuing these few lines, dumping the screen of the host 'target' is accomplished: $ rlogin target $ xwd -root -display localhost:0.0 > ~/snarfed.xwd $ exit $ xwud -in ~/snarfed.xwd And voila, we have a screendump of the root window of the X server target. Of course, an intruder must have an account on your system and be able to log into the host where the specific X server runs. On sites with a lot of X terminals, this means that no X display is safe from those with access. If you can run a process on a host, you can connect to (any of) its X displays. Every Xlib routine has the Display structure as it's first argument. By successfully opening a display, you can manipulate it with every Xlib call available. For an intruder, the most 'important' ways of manipulating is grabbing windows and keystrokes. 4. Snooping techniques - dumping windows The most natural way of snarfing a window from an X server is by using the X11R5 utility xwd or X Window System dumping utility. To get a grip of the program, here's a small excerpt from the man page DESCRIPTION Xwd is an X Window System window dumping utility. Xwd allows Xusers to store window images in a specially formatted dump file. This file can then be read by various other X utilities for redisplay, printing, editing, formatting, archiving, image processing, etc. The target window is selected by clicking the pointer in the desired window. The keyboard bell is rung once at the beginning of the dump and twice when the dump is completed. Shortly, xwd is a tool for dumping X windows into a format readable by another program, xwud. To keep the trend, here's an excerpt from the man page of xwud: DESCRIPTION Xwud is an X Window System image undumping utility. Xwud allows X users to display in a window an image saved in a specially formatted dump file, such as produced by xwd(1). I will not go in detail of how to use these programs, as they are both self-explanatory and easy to use. Both the entire root window, a specified window (by name) can be dumped, or a specified screen. As a 'security measure' xwd will beep the terminal it is dumping from, once when xwd is started, and once when it is finished (regardless of the xset b off command). But with the source code available, it is a matter of small modification to compile a version of xwd that doesn't beep or otherwise identifies itself - on the process list e.g. If we wanted to dump the root window or any other window from a host, we could simply pick a window from the process list, which often gives away the name of the window through the -name flag. As before mentioned, to dump the entire screen from a host: $ xwd -root localhost:0.0 > file the output can be directed to a file, and read with $ xwud -in file or just piped straight to the xwud command. Xterm windows are a different thing. You can not specify the name of an xterm and then dump it. They are somehow blocked towards the X_Getimage primitive used by xwd, so the following $ xwd -name xterm will result in an error. However, the entire root window (with Xterms and all) can still be dumped and watched by xwud. Some protection. 5. Snooping techniques - reading keyboard If you can connect to a display, you can also log and store every keystroke that passes through the X server. A program circulating the net, called xkey, does this trick. A kind of higher-level version of the infamous ttysnoop.c. I wrote my own, who could read the keystrokes of a specific window ID (not just every keystroke, as my version of xkey). The window ID's of a specific root-window, can be acquired with a call to XQueryTree(), that will return the XWindowAttributes of every window present. The window manager must be able to control every window-ID and what keys are pressed down at what time. By use of the window-manager functions of Xlib, KeyPress events can be captured, and KeySyms can be turned into characters by continuous calls to XLookupString. You can even send KeySym's to a Window. An intruder may therefore not only snoop on your activity, he can also send keyboard events to processes, like they were typed on the keyboard. Reading/writing keyboard events to an xterm window opens new horizons in process manipulation from remote. Luckily, xterm has good protection techniques for prohibiting access to the keyboard events. 6. Xterm - Secure keyboard option A lot of passwords is typed in an xterm window. It is therefore crucial that the user has full control over which processes can read and write to an xterm. The permission for the X server to send events to an Xterm window, is set at compile time. The default is false, meaning that all SendEvent requests from the X server to an xterm window is discarded. You can overwrite the compile-time setting with a standard resource definition in the .Xdefaults file: xterm*allowSendEvents True or by selecting Allow Sendevents on the Xterm Main Options menu. (Accessed by pressing CTRL and the left mouse button But this is _not_ recommended. Neither by me, nor the man page. ;) Read access is a different thing. Xterms mechanism for hindering other X clients to read the keyboard during entering of sensitive data, passwords etc. is by using the XGrabKeyboard() call. Only one process can grab the keyboard at any one time. To activate the Secure Keyboard option, choose the Main Options menu in your Xterm window (CTRL+Left mouse button) and select Secure Keyboard. If the colors of your xterm window inverts, the keyboard is now Grabbed, and no other X client can read the KeySyms. The versions of Xterm X11R5 without patch26 also contain a rather nasty and very well known security hole that enables any user to become root through clever use of symbolic links to the password file. The Xterm process need to be setuid for this hole to be exploitable. Refer to the Cert Advisory: CA-93:17.xterm.logging.vulnerability. 7. Trojan X clients - xlock and X based logins Can you think of a more suitable program for installing a password-grabbing trojan horse than xlock? I myself cannot. With a few lines added to the getPassword routine in xlock.c, the password of every user using the trojan version of xlock can be stashed away in a file for later use by an intruder. The changes are so minimal, only a couple of bytes will tell the real version from the trojan version. If a user has a writable homedir and a ./ in her PATH environment variable, she is vulnerable to this kind of attack. Getting the password is achieved by placing a trojan version of Xlock in the users homedir and waiting for an invocation. The functionality of the original Xlock is contained in the trojan version. The trojan version can even tidy up and destroy itself after one succesfull attempt, and the user will not know that his password has been captured. Xlock, like every password-prompting program, should be regarded with suspicion if it shows up in places it should not be, like in your own homedir. Spoofed X based logins however are a bit more tricky for the intruder to accomplish. He must simulate the login screen of the login program ran by XDM. The only way to ensure that you get the proper XDM login program (if you want to be really paranoid) is to restart the X-terminal, whatever key combination that will be for the terminal in question. 8. X Security tools - xauth MIT-MAGIC-COOKIE To avoid unathorized connections to your X display, the command xauth for encrypted X connections is widely used. When you login, xdm creates a file .Xauthority in your homedir. This file is binary, and readable only through the xauth command. If you issue the command $ xauth list you will get an output of: your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b76682f726d42544a684a display name authorization type key The .Xauthority file sometimes contains information from older sessions, but this is not important, as a new key is created at every login session. To access a display with xauth active - you must have the current access key. If you want to open your display for connections from a particular user, you must inform him of your key. He must then issue the command $ xauth add your.display.ip:0 MIT-MAGIC-COOKIE-1 73773549724b7668etc. Now, only that user (including yourself) can connect to your display. Xauthority is simple and powerful, and eliminates many of the security problems with X. 9. Concluding remarks Thanks must go to Anthony Tyssen for sending me his accumulated info on X security issues from varius usenet discussions. I hope someone has found useful information in this text. It is released to the net.community with the idea that it will help the user to understand the security problems concerned with using X windows. Questions or remarks can be sent to the following address: runeb@stud.cs.uit.no ------------------------------------------------------------------------- [van Hauser]--------- Introduction This article describes possible backdoors through different firewall architectures. However, the material can also be applied to other environments to describe how hackers (you?) cover their access to a system. Hackers often want to retain access to systems they have penetrated even in the face of obstacles such as new firewalls and patched vulnerabilities. To accomplish this the attackers must install a backdoor which a) does it's job and b) is not easily detectable. The kind of backdoor needed depends on the firewall architecture used. As a gimmick and proof-of-concept, a nice backdoor for any kind of intrusion is included, so have fun. ----[ Firewall Architectures There are two basic firewall architectures and each has an enhanced version. Packet Filters: This is a host or router which checks each packet against an allow/deny ruletable before routing it through the correct interface. There are very simple ones which can only filter from the origin host, destination host and destination port, as well as good ones which can also decide based on incoming interface, source port, day/time and some tcp or ip flags. This could be a simple router, f.e. any Cisco, or a Linux machine with firewalling activated (ipfwadm). Stateful Filters: This is the enhanced version of a packet filter. It still does the same checking against a rule table and only routes if permitted, but it also keeps track of the state information such as TCP sequence numbers. Some pay attention to application protocols which allows tricks such as only opening ports to the interiour network for ftp-data channels which were specified in a permitted ftp session. These filters can (more or less) get UDP packets (f.e. for DNS and RPC) securely through the firewall. (Thats because UDP is a stateless protocol. And it's more difficult for RPC services.) This could be a great OpenBSD machine with the ip-filter software, a Cisco Pix, Watchguard, or the (in)famous Checkpoint FW-1. Proxies / Circuit Level Gateways: A proxy as a firewall host is simply any server which has no routing activated and instead has proxy software installed. Examples of proxy servers which may be used are squid for WWW, a sendmail relay configuration and/or just a sockd. Application Gateways: This is the enhanced version of a proxy. Like a proxy, for every application which should get through the firewall a software must be installed and running to proxy it. However, the application gateway is smart and checks every request and answer, f.e. that an outgoing ftp only may download data but not upload any, and that the data has got no virus, no buffer overflows are generated in answers etc. One can argue that squid is an application gateway, because it does many sanity checks and let you filter stuff but it was not programmed for the installation in a secure environment and still has/had security bugs. A good example for a freeware kit for this kind is the TIS firewall toolkit (fwtk). Most firewalls that vendors sell on the market are hybrid firwalls, which means they've got more than just one type implemented; for example the IBM Firewall is a simple packet filter with socks and a few proxies. I won't discuss which firewall product is the best, because this is not a how-to-by-a-firewall paper, but I will say this: application gateways are by far the most secure firewalls, although money, speed, special protocols, open network policies, stupidity, marketing hype and bad management might rule them out. ----[ Getting in Before we talk about what backdoors are the best for which firewall architecture we should shed a light on how to get through a firewall the first time. Note that getting through a firewall is not a plug-n-play thing for script-kiddies, this has to be carefully planned and done. The four main possibilities: Insider: There's someone inside the company (you, girlfriend, chummer) who installs the backdoor. This is the easiest way of course. Vulnerable Services: Nearly all networks offer some kind of services, such as incoming email, WWW, or DNS. These may be on the firewall host itself, a host in the DMZ (here: the zone in front of the firewall, often not protected by a firewall) or on an internal machine. If an attacker can find a hole in one of those services, he's got good chances to get in. You'd laugh if you saw how many "firewalls" run sendmail for mail relaying ... Vulnerable External Server: People behind a firewall sometimes work on external machines. If an attacker can hack these, he can cause serious mischief such as the many X attacks if the victim uses it via an X-relay or sshd. The attacker could also send fake ftp answers to overflow a buffer in the ftp client software, replace a gif picture on a web server with one which crashs netscape and executes a command (I never checked if this actually works, it crashs, yeah, but I didn't look through this if this is really an exploitable overflow). There are many possibilities with this but it needs some knowledge about the company. However, an external web server of the company is usually a good start. Some firewalls are configured to allow incoming telnet from some machines, so anyone can sniff these and get it. This is particulary true for the US, where academic environments and industry/military work close together. Hijacking Connections: Many companies think that if they allow incoming telnet with some kind of secure authentication like SecureID (secure algo?, he) they are safe. Anyone can hijack these after the authentication and get in ... Another way of using hijacked connections is to modify replies in the protocol implementation to generate a buffer overflow (f.e. with X). Trojans: Many things can be done with a trojan horse. This could be a gzip file which generates a buffer overflow (well, needs an old gzip to be installed), a tar file which tampers f.e. ~/.logout to execute something, or an executable or source code which was modified to get the hacker in somehow. To get someone running this, mail spoofing could be used or replacing originals on an external server which internal employees access to update their software regulary (ftp xfer files and www logs can be checked to get to know which files these are). ----[ Placing the Backdoors An intelligent hacker will not try to put the backdoors on machines in the firewall segment, because these machines are usually monitored and checked regulary. It's the internal machines which are usually unprotected and without much administration and security checks. I will now talk about some ideas of backdoors which could be implemented. Note that programs which will/would run on an stateful filter will of course work with a normal packet filter too, same for the proxy. Ideas for an application gateway backdoor will work for any architecture. Some of them are "active" and others "passive". "Active" backdoors are those which can be used by a hacker anytime he wishes, a "passive" one triggers itself by time/event so an attacker has to wait for this to happen. Packet Filters: It's hard to find a backdoor which gets through this one but does not work for any other. The few ones which comes into my mind is a) the ack-telnet. It works like a normal telnet/telnetd except it does not work with the normal tcp handshake/protocol but uses TCP ACK packets only. Because they look like they belong to an already established (and allowed) connection, they are permitted. This can be easily coded with the spoofit.h of Coder's Spoofit project (http://reptile.rug.ac.be/~coder). b) Loki from Phrack 49/51 could be used too to establish a tunnel with icmp echo/reply packets. But some coding would be needed to to be done. c) daemonshell-udp is a backdoor shell via UDP (http://r3wt.base.org look for thc-uht1.tgz) d) Last but not least, most "firewall systems" with only a screening router/firewall let any incoming tcp connection from the source port 20 to a highport (>1023) through to allow the (non-passive) ftp protocol to work. "netcat -p 20 target port-of-bindshell" is the fastest solution for this one. Stateful Filters: Here a hacker must use programs which initiates the connection from the secure network to his external 0wned server. There are many out there which could be used: active: tunnel from Phrack 52. ssh with the -R option (much better than tunnel ... it's a legtimitate program on a computer and it encrypts the datastream). passive: netcat compiled with the execute option and run with a time option to connect to the hacker machine (ftp.avian.org). reverse_shell from the thc-uht1.tgz package does the same. Proxies / Circuit Level Gateways: If socks is used on the firewall, someone can use all those stuff for the stateful filter and "socksify" them. (www.socks.nec.com) For more advanced tools you'd should take a look at the application gateway section. Application Gateways: Now we get down to the interesting stuff. These beasts can be intelligent so some brain is needed. active: (re-)placing a cgi-script on the webserver of the company, which allows remote access. This is unlikely because it's rare that the webserver is in the network, not monitored/ checked/audited and accessible from the internet. I hope nobody needs an example on such a thing ;-) (re-placing) a service/binary on the firewall. This is dangerous because those are audited regulary and sometimes even sniffed on permanent ... Loading a loadable module into the firewall kernel wich hides itself and gives access to it's master. The best solution for an active backdoor but still dangerous. passive: E@mail - an email account/mailer/reader is configured in a way to extract hidden commands in an email (X-Headers with weird stuff) and send them back with output if wanted/needed. WWW - this is hard stuff. A daemon on an internal machine does http requests to the internet, but the requests are in real the answers of commands which were issued by a rogue www server in a http reply. This nice and easy beast is presented below (->Backdoor Example: The Reverse WWW Shell) DNS - same concept as above but with dns queries and replies. Disadvantage is that it can not carry much data. (http://www.icon.co.za/~wosp/wosp.dns-tunnel.tar.gz, this example needs still much coding to be any effective) ----[ Backdoor Example: The Reverse WWW Shell This backdoor should work through any firewall which has got the security policy to allow users to surf the WWW (World Wide Waste) for information for the sake and profit of the company. For a better understanding take a look at the following picture and try to remember it onwards in the text: +--------+ +------------+ +-------------+ |internal|--------------------| FIREWALL |--------------|server owned | | host | internal network +------------+ internet |by the hacker| +--------+ +-------------+ SLAVE MASTER Well, a program is run on the internal host, which spawns a child every day at a special time. For the firewall, this child acts like a user, using his netscape client to surf on the internet. In reality, this child executes a local shell and connects to the www server owned by the hacker on the internet via a legitimate looking http request and sends it ready signal. The legitimate looking answer of the www server owned by the hacker are in reality the commands the child will execute on it's machine it the local shell. All traffic will be converted (I'll not call this "encrypted", I'm not Micro$oft) in a Base64 like structure and given as a value for a cgi-string to prevent caching. Example of a connection: Slave GET /cgi-bin/order?M5mAejTgZdgYOdgIO0BqFfVYTgjFLdgxEdb1He7krjVAEfg HTTP/1.0 Master replies with g5mAlfbknz The GET of the internal host (SLAVE) is just the command prompt of the shell, the answer is an encoded "ls" command from the hacker on the external server (MASTER). Some gimmicks: The SLAVE tries to connect daily at a specified time to the MASTER if wanted; the child is spawned because if the shell hangs for whatever reason you can check & fix the next day; if an administrator sees connects to the hacker's server and connects to it himself he will just see a broken webserver because there's a Token (Password) in the encoded cgi GET request; WWW Proxies (f.e. squid) are supported; program masks it's name in the process listing ... Best of all: master & slave program are just one 260-lines perl file ... Usage is simple: edit rwwwshell.pl for the correct values, execute "rwwwshell.pl slave" on the SLAVE, and just run "rwwwshell.pl" on the MASTER just before it's time that the slave tries to connect. Well, why coding it in perl? a) it was very fast to code, b) it's highly portable and c) I like it. If you want to use it on a system which hasn't got perl installed, search for a similar machine with perl install, get the a3 compiler from the perl CPAN archives and compile it to a binary. Transfer this to your target machine and run that one. The code for this nice and easy tool is appended in the section THE CODE after my last words. If you've got updates/ideas/critics for it drop me an email. If you think this text or program is lame, write me at root@localhost. Check out http://r3wt.base.org for updates. ----[ Security Now it's an interesting question how to secure a firewall to deny/detect this. It should be clear that you need a tight application gateway firewall with a strict policy. email should be put on a centralized mail server, and DNS resolving only done on the WWW/FTP proxies and access to WWW only prior proxy authentication. However, this is not enough. An attacker can tamper the mailreader to execute the commands extracted from the crypted X-Headers or implement the http authentication into the reverse www-shell (it's simple). Also checking the DNS and WWW logs/caches regulary with good tools can be defeated by switching the external servers every 3-20 calls or use aliases. A secure solution would be to set up a second network which is connected to the internet, and the real one kept seperated - but tell this the employees ... A good firewall is a big improvement, and also an Intrusion Detection Systems can help. But nothing can stop a dedicated attacker. van Hauser: Detailed Guide to Linux Security ----------[Bronc Buster] Another Paper on Linux Security 13 Aug 98 Last Update 07 Sept 98 Version Beta 0.2 Bronc Buster bronc@shocking.com ------------------------------------------------------------------------ Another paper on Linux Security? Why? Well most of the ones I've seen floating around the net are never complete, only someone's tips or tricks on how to secure a part of it, or to tweak some daemon or process or a quick fix to a problem. They never cover from step one, though going multi-user and going online with users and user processes and all that goes along with it. I want to cover that. I know, no matter how hard I try, I'll end up missing something, but I'm going to try and cover everything I do when I install a system and prepare it for online use, plus cover some free tools that I have found to be very effective. Now if you are totally clueless and don't have any idea about how to use Linux, I'll save you some time and tell you now, just don't go any further. To get any use out of this paper, you have to be an intermediate user, or a new admin who is familiar with Unix as a whole. If you are thinking about going by this list when you are installing your system, READ THIS ENTIRE PAPER FIRST, then start over following it, otherwise you may miss something you might want when you install or when you pick a kernel. I'll say this now before you start. This paper is ongoing, and a work in progress. I want to make a comprehensive paper, so I welcome all suggestions, tips and advice on how to make this paper a better one. ------------------------------------------------------------------------ Contents 1. Installation 2. Boot-Up 3. SUID files and the File System 4. Quotas 5. Logs 6. Access security (remote and physical) 7. Misc. Files 8. Third Party Tools 9. Conclusions ------------------------------------------------------------------------ 1. Installation This is a step every paper I have seen has over looked. Right from install you can manage to cut your problems by at least one-third if you install correctly, installing only what your system needs. Think about it. Ask yourself what is this box going to be doing? Is it going to be on a LAN as a file server of some sort, or sitting on a direct Internet Connection as a web server of some sort, or just sitting on your desk at home running PPP? These are important questions you need to answer BEFORE you start your install. If this system is going to be sitting on a rack as a web server, why would you want to install X-Windows, for example. If you're not going to use it, you'll most likely overlook it in day to day operations, and that's something a hacker is going to look for. Along with this comes SUID programs, programs you might not even know exist, but programs a hacker will head for like a shark for blood. On the other hand, if it's on a LAN, where you're going to be at the console, and an X-Windows server is necessary, look for other components you won't need, like any of the PPP or SLIP components. If you're not sure, go out and buy a book, or if you're really poor, borrow a book. Read up on what each component does and why you need it. If worse comes to worse, when you are installing, read each section before you just go down the line and check off everything. Read the parts which you are unsure of and don't install what you think you don't need. Remember that you can always go back later and add things. The Unix file system can be very complex and very deep, and hackers depend on this when they are hiding programs and backdoors. The better you understand what you have put on your system, the better you will know, later on, what should be there and what shouldn't. This also helps out later on after you have installed, when you are weeding out potential security risks. The less unnecessary stuff on yo4ur system, the less you have to worry about later on, so take the time now, before an install, and go though what you want to install. ------------------------------------------------------------------------ 2. Boot-Up Ok, so you took a couple hours and got a nice clean install, now you're booting up. Hopefully it'll be clean with no errors. If there are errors, there are the first problems you want to try and solve. In Linux (Slackware), there is a directory called '/etc/rc.d' that hold the files that tells the system what to run at boot. This, as you can imagine, is a very important directory, as someone who can write to these files can install a backdoor, or a process that can be harmful to your system. Back to the errors, and editing each of the files for safety. Most people, unless they have experience with Linux, either don't know these files exist, don't know what to do with them, or are to scared to touch them, thinking back to their uninformed windows95 days, where if you touched files that controlled boot-up you might lose everything and have to reinstall the operating system. Fear not, this is Linux! showdown:/etc/rc.d# ls -l total 40 lrwxrwxrwx 1 root root 4 Jun 5 01:31 rc.0 -> rc.6* -rwxr-xr-x 1 root root 396 Oct 2 1995 rc.4* -rwxr-xr-x 1 root root 2273 Oct 17 1996 rc.6* -rwxr-xr-x 1 root root 1244 May 21 1997 rc.K* -rwxr-xr-x 1 root root 3439 Sep 25 1997 rc.M* -rwxr-xr-x 1 root root 5054 Jun 16 1997 rc.S* -rw-r--r-- 1 root root 1336 Jul 9 1997 rc.cdrom -rwxr-xr-x 1 root root 52 Jun 12 12:24 rc.httpd* -rwxr-xr-x 1 root root 2071 Jul 29 14:19 rc.inet1* -rwxr-xr-x 1 root root 2846 Jul 2 20:41 rc.inet2* -rwxr-xr-x 1 root root 735 Jun 30 22:10 rc.local* -rwxr-xr-x 1 root root 5251 Jun 5 09:23 rc.modules* -rwxr-xr-x 1 root root 9059 Aug 23 1997 rc.serial* Now here is a typical '/etc/rc.d/' directory. Each of the 'rc.*' files does something specific, depending on the status of the system. Some of them are self-explanatory, like 'rc.httpd', it's simply starts your HTTPD web server. The 'rc.cdrom' loads your CD-ROM drive, if you have support compiled into your kernel. 'rc.modules' loads modules, if you have any (modules are special drivers or programs that are added at boot-time to the kernel, and are not compiled into the kernel. Modules are uses for older type NICs, sometimes Modems and other old types of hardware.) 'rc.serial' is also used for loading serial devices, like modems, printer and other stuff. Most of the 'rc.*' files that have proper names, like '.cdrom', '.modules', '.serial' and '.httpd' you shouldn't have to mess with, as they are set up automatically by the choices you make when you install and select a kernel to boot off of. Some of the others control the differences between Single Users Mode and Multi User Mode, and some of the others control what daemons load up and what your operating system can do. 'rc.M' controls the system going to Multi User Mode and loads some of the other 'rc.*' files if the are supported, like the 'rc.cdrom', etc. Go through this file carefully! Anything you know for a fact you don't need, EDIT OUT with a '#'. Most likely there won't be too much you have to mess with in this file, but you will in the others. Go down the list in the 'rc.M' file and look at each of the other 'rc.*' files it runs. Then go though each of these files and repeat the process. For example, say you are going through your 'rc.inet2' file and you know you don't need any 'rpc' services and you don't want your portmapper to run, so you want to edit this out so it won't start up. #This is how it looks normally. To edit it out, use the '#' -- snip ---- # Start the SUN RPC Portmapper. if [ -f ${NET}/rpc.portmap ]; then echo -n " portmap" ${NET}/rpc.portmap fi -- snip ---- #Here is the correctly edited version -- snip ---- # Start the SUN RPC Portmapper. #if [ -f ${NET}/rpc.portmap ]; then # echo -n " portmap" # ${NET}/rpc.portmap #fi -- snip ---- It is important to edit it all out, from the starting 'if' all the way down to the corresponding 'fi' at the end, otherwise you'll end up with errors. I could go through each of the files and programs started in each of the 'rc.*' files, but only you know which ones you are going to need, depending on the type of server you are going to run. Just remember, you have to assess what you need to get the job done, and then remove the rest. If you're not sure what each program does, try doing a net search, then reading on what each program does and then assessing if you need them or not. The 'rc.local' file is also an important file in the 'rc.d' directory, it has any files or program you want to add to be started at boot time. You can put any sort of things in here as you will see when I add one a bit later. ------------------------------------------------------------------------ 3. SUID files and the Filesystem Before a single user steps fourth into my system, I make sure I find, and isolate all, I repeat ALL, SUID files on the entire system. First, you need to find all the SUID files. These series of commands will show you where they all are: find / -perm 4000 >> suid.txt find / -perm 4700 >> suid.txt find / -perm 4777 >> suid.txt find / -perm 4770 >> suid.txt find / -perm 4755 >> suid.txt find / -perm 4750 >> suid.txt find / -perm 4751 >> suid.txt find / -perm 4500 >> suid.txt find / -perm 4555 >> suid.txt find / -perm 4550 >> suid.txt find / -perm 4551 >> suid.txt Now all you have to do is take a quick look into `suid.txt' and you'll have the paths to all the SUID files on your system. On some systems, a simple `find / -perm 4000 -print >> suid.txt' or 'find / -perm +4000 -print >> suid.txt' command will do the same thing as all the commands above, but then again I've had a system in which it didn't show all the SUID files for some reason. So to be safe I use a simple script in which it just runs all these commands at once so I don't have to sit around typing them all (call me anal). After you have located all the SUID file, now you have to go though all these files and decide which files you need, and which you want your users to have access to. On my systems, I leave the following files SUID, and `chmod 000' the rest of them. passwd ping traceroute screen su All other files that may be SUID, users have no business using, unless you are going to run some sort of NFS or an X Server. Keep the list of SUID files in your home directory so you can remember later where they are if you need to use one. The rest of these SUID files, I move and put them in the same directory, so I can keep track of them. Mine are in `/usr/local/bin' or in `/bin' so that they stay in the users $PATH. Later on I'll go into replacement programs for some of these that are even more secure. Remember again, it is up to you, the admin, to decide what programs you want users to have access to! ------------------------------------------------------------------------ 4. Quotas I always use quotas! Unless your are a normal ISP, or have some reason to limit the amount of space each user is allowed to use, most people don't bother with quotas. Well that's the wrong attitude and the wrong answer. Quotas can totally save your system from getting trashed and hosed from an ignorant or destructive user. Quotas not only control how much space a user is allowed to use on your system, but it also controls the total number of files (inodes) they are allowed to have as well. Think about a user who makes a loop that makes directory after directory or 1-byte file after 1-byte file? They could not only eat up all the CPU and memory, but fill up your drive. A smart set quota can not only stop this before it happens, but stop someone who might not have any quota from also filling up your hard drive with garbage files. I've tested a Linux 3.0 system (Slack), 2.0.20 kernel, filling its hard drive as full as it could go, and upon crashing when any command is input, it would not boot upon shutting it down and turning it back on. To set up quotas on your system, simply select it when you are installing your system. It will install the quota set, which includes all the programs needed to get them working. Later on you MUST recompile your kernel to support quotas, otherwise they won't work. No, I'm not going to go into how to compile you kernel. They have very long HOW-TO's on how to do it (do a `find' for Kernel-HOWTO.tar.gz). Once quota support is added to your kernel, add these lines to your `/etc/rc.local' file at the end: # Quota support and file checks if [ -x /usr/sbin/quotacheck ] then echo "Checking quotas. This may take some time." /usr/sbin/quotacheck -avug echo " Done." fi # Turning ON quotas if [ -x /usr/sbin/quotaon ] then echo "Turning on quota." /usr/sbin/quotaon -avug fi # Done Once you reboot, `quotacheck' will first check your file system and make sure no one is over quota, along with other house keeps operations, then `quotaon' will turn on quota support for your system. A simple command of `quota user' will give you the quotas for a user, or `quota group' will give you a set quota for a group. To change a quota, issue the command `edquota [user] or [group]'. This will open a temp file with your editor, as specified in your `.profile', and give you power to change a user, or groups quota. For example: showdown:/admin/bronc# edquota tidepool Quotas for user tidepool: /dev/hda1: blocks in use: 279, limits (soft = 10000, hard = 15000) inodes in use: 35, limits (soft = 1300, hard = 1500) From here you can see that this users quota on hda1 is 10megs soft, and 15megs hard. Which simple gives the user a grace period to go over their quota. If they stay over their quota over the grace period (I use 10 days), when they login they can't do anything, except delete files. The same goes for their files, or inodes. You can set a soft and hard limit on these as well. If these are set to `0' then they have no limit (bad idea). You can use quotas in various ways to secure against on system attacks, and your hard drive getting filled up. If you want to get more in depth, try `man quota'. It can tell you it's other functions, how to manually start and stop this service and where the quota information is stored on your system. ------------------------------------------------------------------------ 5. Logs One of the most important parts of being a good system admin is regularly reviewing the systems logs, but if you don't know where they are, or what you are logging what use are they? This is a very important section and I urge you to read it thoroughly! The only way you are going to see if you are being probed for an attack, or if someone has been attacking you is by checking the logs. So where are the logs and how is information sent to them? Well on a Linux system, they are located in a directory called `/var/adm/' or in a directory called `/var/logs' but usually they are linked together. By default, there are only two logs, `syslog' and `messages' but we need to make more. Logs are made from two daemons, `klogd' and `syslogd'. `klogd' intercepts and logs Linux kernel messages, while `syslogd' logs all system messages. These are system daemons which are automatically started by your `rc.*' files upon boot. To configure what you log, you must edit a file called `/etc/syslog.conf', this file tells what `syslogd' is to log, and where it is to put it. Here is how I have mine set up: # /etc/syslog.conf file # for more information about this file, man `syslog.conf' or `sysklogd' # # Modified by Bronc Buster mail.none;*.=info;*.=notice /usr/adm/messages *.=debug /usr/adm/debug *.err /usr/adm/syslog *.=alert root,bronc *.=emerg root,bronc authpriv.*;auth.* /admin/bronc/auth.log authpriv.*;auth.* /var/log/secure mail.info;mail.notice /var/log/maillog daemon.info;daemon.notice /var/log/daemon.log *.* /dev/tty12 # EOF Ok, if you don't know how this file is formatted and what phrases to use here, read up on the man page, `man syslog.conf'. I don't want to go through and waste two or three pages on explaining it. Lets go through my file line by line and see how it works. I wanted to make my logs simple, easy to understand and be specific as to what they have in them. First, my `messages' file was getting full of junk errors from my mail program, so I went and took out all messages associated with mail; i.e. `mail.none'. Then I wanted all messages at the `info' or `notice' level to be placed into it, so I added that into the same line as well. Next, I wanted all `debug' messages, sent to their own file, as well as all `err' (error) messages. Any `alert' or `emerg' (emergency) messages I wanted sent to the console or the terminal I was logged on, so I would know about them as soon as possible. The nest two lines have to do with connections and possible logins. I wanted to have a file that had nothing but who and when, so I could easily check out who logged in and when, and I also wanted an extra copy put in my own home directory so incase someone somehow edited it and took themselves out, I'd still have my own copy plus when I wanted to take a look at it, it was easily viewable. That's what the lines with the `authpriv' and `auth' are doing. The first one puts the log in my directory, the second in the normal logging directory. The next line deals with all the mail messages that I took out of the first `messages' file and puts them in their own log file. Nothing but mail here, so there is nothing else in there to confuse you. The `daemon' line logs all messages regarding the system daemons, and, like the mail line above, nothing else so there is nothing to get confused over. The last line is also a very important one. It sends all logs to /dev/tty12, so even if your logs were to get deleted, from the console you can hit Ctrl-F12 and see the last page of messages so you can get an idea of what happened. These different logs each cover a different aspect of your system, and keep them unscrambled and easy to read through. Remember, the easier the better. If I had another box I could use, I would also pipe all the logs off my box to the other box. With syslog, you have the option of sending all the logs off your box for remote logging. You could put a poor old 386, with Linux, on your network with nothing running but `inetd' and `syslogd' and send all your systems logs over to it with this simple line in your `syslog.conf': # log ALL other boxes IP number # *.* @ Now that your main system logs are secure, what about other log files? You still have `/var/log/wtmp' and `/var/log/utmp', plus each users shell histories. Because on some systems, `cron' archives your system logs, you normally can't `chattr' them, or mess with them much, but you can on the other logs. `chattr' changes a files attributes on an EXT2 file system, like you are using on your Linux system. With this command, you can make a file so it can't be deleted or edited, except to be appended (`man chattr' for more info on this useful command). This magic command can make the `wtmp' and `utmp' file so it can only be appended to, and so it can't be deleted or changed so as to show a user never logged on, or where they logged on from. With this same command, you can also fix all the users shell histories. Normally, any shell histories made by each user, are owned by each user, making them totally useless as a skilled user will first thing, link it to `/dev/null'. By using the `chattr +a' option of the `chattr' command on `wtmp', `utmp' and each users shell histories, you can track down problems quickly. I don't know how many troublesome users I have tracked down simply going into their shell histories and looking for problems they have caused. Like here is an example: --- snip --- gcc smurf.c -o smurf smurf smurf gcc octpuss.c -o octop octop ping ping -s 2000 rm smurf* rm otc* rm .bash_history rm .bash_hirtory vi .bash_history exit logout This, soon removed user, was using denial of service attacks to attack another system, and in return they were attacking us. Users like this can get you, the admin, in hot water and need to be removed as soon as possible. If it wasn't for the fact I `chattr +a' all the users shell histories, I never would have tracked it down to a specific user. When I add a user, I use a modified the `adduser' script so it automatically `chattr +a' their shell histories. To do the same, simply open the `adduser' script with an editor and add these lines at the end: # chattr +a users shell histories if [ -d $HME ]; then chmod 711 $HME cd $HME /bin/touch .bash_history /bin/chown $LOGIN:users .bash_history /usr/bin/chattr +a .bash_history /bin/touch .ksh_history /bin/chown $LOGIN:users .ksh_history /usr/bin/chattr +a .ksh_history /bin/touch .sh_history /bin/chown $LOGIN:users .sh_history /usr/bin/chattr +a .sh_history fi You need to keep close tabs on your log files, they are your eyes and ears of your system. You need to make them secured, easy to read and make sure they cover all aspects of what the system logging daemons can, and are logging. ------------------------------------------------------------------------ 6. Access Security (remote and physical) Access is an often-overlooked part of the total security picture. Both remote and physical access must be dealt with. It takes more than a strong password to keep people off your system, you have to know what files to use to control access even if someone were to get a valid login and password. There are files in your system that can gratefully help and give you stronger control over who connects, as there are also files that don't exist and that you need to make that can also help with local controls as well. Here are the files we are going to cover then we will go onto physical access controls: /etc/suauth /etc/ftpaccess /etc/hosts.deny /etc/hosts.allow /etc/securetty First, `suauth', it is the file that controls who is allowed to use the `su' (Switch User) command. This command, as you know, lets you become a root user, or lets you become any other user for that matter and is SUID, so you want to keep a tight grip on who is allowed to use it. The `suauth' file has a certin format, being: TO:FROM:ACTION Simple looking enough. The `TO' field tells what user you are going to, in this case, say `root'. The `FROM' field controls which user or group is being applied to go `TO' root. The `ACTION' tells what to do in each case. `ACTION's that can be used are, `OWNPASS', `DENY' and `NOPASS'. Here is a clipping out of the `suauth' man page so you can get a better feeling of how these all tie together. # A couple of privileged usernames may # su to root with their own password. # root:chris,birddog:OWNPASS # # Anyone else may not su to root unless in # group wheel. This is how BSD does things. # root:ALL EXCEPT GROUP wheel:DENY # # Perhaps terry and birddog are accounts # owned by the same person. # Access can be arranged between them # with no password. # terry:birddog:NOPASS birddog:terry:NOPASS # On my system, I have done what is in the second example. I edited the `/etc/group' file and added another group called `wheel'. This group is somewhere between the group `users' and `root', and I then added the users to this group that I wanted to be allowed to `su'. In the `suauth' file, I simply told it not to allow anyone to `su' unless they are in the group `wheel'. One down. Need any more help, try `man suauth'. Next is the `ftpaccess' file. This file controls a lot of stuff regarding your ftp services, like who can upload and download, if anonymous connections are allowed and if there are any hosts you don't want connecting at all. Because this file controls so much, I'm only going to get into how to block hosts from connecting, as I am dealing with access control, so for more information on how to set up other features in this file, as always `man ftpaccess'. Now this file has a simple rule set, and is not very picky in where you place things in it. For example, if we were going to add someone to our deny list, we could add it at the very top, the middle or the end and it won't care. I usually add them to the bottom as you want room to keep adding. The format is a very simple one, `deny '. Here is how mine looks: # deny these domains from getting on my FTP site # #deny host path to nasty message # deny *.sekurity.org /etc/msgs/msg.dead deny *.303.org /etc/msgs/msg.dead dent *.tacd.org /etc/msgs/msg.dead deny *.dim.com /etc/msgs/msg.dead deny *.comsite.net /etc/msgs/msg.dead deny su1d.technotronic.com /etc/msgs/msg.dead I think it's very easy to understand the format of this file, except maybe the last part, `/etc/msgs/msg.dead'. This is simply a path to a text file you want to be shown the person who is denied. Anyone connecting and getting access into the system, or getting denied, will show up in your log files (/var/logs/secure) so remember to check them from time to time if you notice any funny activity. The `hosts.deny' and `hosts.allow' files work hand in hand with each other and are, by default, used on almost all-modern versions of Unix. These files work in conjunction with TCP Wrappers, which you are most likely using now if you know it or not. TCP Wrappers, in brief, is a program called `tcpd'. From the man page, it monitors incoming requests for telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other services that have a one-to-one mapping onto executable files. What does that mean? Well in short, it watches programs that are in your `/etc/inetd.conf' file which are the programs that are started by `inetd' when in incoming request asks for an assigned program it watches for. The `tcpd' program is put into the `inetd.conf' file in place of the normal programs and whenever a request for service arrives, the inetd daemon is tricked into running the `tcpd' program instead of the desired server. `tcpd' logs the request and does some additional checks. When all is well, `tcpd' runs the appropriate server program and goes away. If you look at your `/etc/inetd.conf' file a line should like similar to this: smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs Here you can see that my `tcpd' is started, instead of sendmail, when an incoming request it sent to my smtp port. `tcpd' then logs the request and checks your `hosts.deny' and `host.allow' files. The `hosts.*' files do what their names suggest. They allow, or deny connections. Their formats are very easy to use; Connection:IP address. showdown:~$ cat /etc/hosts.deny ALL: 130.85.3.8 ALL: 207.172.56.57 Here I am blocking ALL connections from these two IP numbers. If I wanted I could block the entire class C, or change it to a domain and block that. You can put as many IP in here as you want, or if you are super paranoid, you can even put `ALL:ALL' and deny all connections. If you deny everyone, you can then select hosts to allow connections from. This is when you would use your `hosts.allow' file. It has the same format as the deny file, but unless you deny `ALL:ALL' I've never had to use it. But whose to say what your security needs are. Maybe you only want a select few people to be allowed to connect to your box. If so this is how you would do it. As most of the other files, they can also be tweaked a bit more and have other options. To get more information on them, `man tcpd'. Lastly, we will go over another simple, but surpassingly often overlooked file. The `/etc/securetty' file simply controls where `root' can log in from. As it comes default, it allows root to log in from any tty, local or remote. Here is the default: console tty1 tty2 tty3 tty4 tty5 tty6 ttyS0 ttyS1 ttyS2 ttyS3 ttyp0 ttyp1 ttyp2 ttyp3 That's all it is. If you had no idea what this file did how would you know (`man securetty' maybe)? These are the `/dev/tty's that are on your system, remote and local. The `ttyp*' and the `ttyS*' are remote, and the rest, as you can guess are local at the console. You, I hope, want to keep anyone from logging on as `root' anywhere, except from the local tty's. To do this, simply edit this file and comment out all the remote tty's with the `#' like so: #Keep root from logging on with a remote /dev/tty console tty1 tty2 tty3 tty4 tty5 tty6 #ttyS0 #ttyS1 #ttyS2 #ttyS3 #ttyp0 #ttyp1 #ttyp2 #ttyp3 That's that for remote access security. Now I'll move onto physical access. Now most places your box is going to be will be secure by the nature of place it is. If it is at your ISP, then most likely it is secure. If it's co-located, the people at your ISP most likely know you and know you box, plus if your box is with theirs, I'm sure they don't want anyone back with their machines as much as you don't. If It's on a LAN, keep it locked in your office, or if that's not possible, try and keep it under a desk or on the floor out of the way where no one will notice it. While you can't count on `security through obscurity' online, in physical access you want to use it. My box at my ISP is on the bottom rack next to 4 other machines that look similar to mine, all with no monitors and only keyboards attached (for remote reboots). There are no labels or any identifying marks at all. It is out of the way and very inconspicuous. If someone is going to go into the place your box is stored, you don't want to make it easy to identify, or find for that matter. Make them have to hook up a monitor and check each box until they find yours. Hopefully they will get discouraged or get cough by then. A very important note and common sense: NEVER walk away from the console and leave root logged in, or any user for that matter. Log out, or lock the terminal! As far as other physical security measures, well if it's sitting in your house, what can you do besides lock your doors. If it's at your ISP, you have to rely on them. If it's at work, keep it out of sight or locked up. Just be smart. Keep the console locked. Don't leave a monitor hooked up to it if it's not at your house. If someone wants to get to it, it's not like it's going to be kept in some top-secret lab somewhere, they are going to get to it. If they do, try and make it so the most damage they can do is to simply turn it off. ------------------------------------------------------------------------ 7. Misc. Files Now I am going to cover the other files around the system that don't fall under the other categories I've went through so far. There are only a few, but they are an important few. These files are: /etc/inetd.conf /etc/services /etc/nologin /etc/issue.net and /etc/issue /etc/passwd /etc/shadow /etc/group First, the `inetd.conf' file. This file is the configuration file for your `inetd' daemon. This daemon listens for connections on certain ports for and then decides what service to invoke, if any as told to it by the `inetd.conf' file. As you can imagine, this is an important file as whatever services are in it can be invoked by it. As default, all the services in it are open. I guess the writers of it though we were living in lollypop land and everyone was friendly, but unfortunately it's not. To edit this file, as with the ones before, you use `#'. You're `inetd.conf' file should look similar to this one before being edited: -------- snip --------- # The first 4 services are really only used for debugging purposes, so # we comment them out since they can otherwise be used for some nasty # denial-of-service attacks. If you need them, uncomment them. echo stream tcp nowait root internal echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal time stream tcp nowait root internal time dgram udp wait root internal # # These are standard services. # ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # # Use this one instead if you want to snoop on telnet users (try to use this # for ethical purposes, ok folks?) : # telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetsnoopd # # This is generally unnecessary. The daemon provided by INN will handle the # incoming NNTP connections. nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd # ----- snip ----- smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs # # The comsat daemon notifies the user of new mail when biff is set to y: comsat dgram udp wait root /usr/sbin/tcpd in.comsat # # Shell, login, exec and talk are BSD protocols. # shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L login stream tcp nowait root /usr/sbin/tcpd in.rlogind exec stream tcp nowait root /usr/sbin/tcpd in.rexecd talk dgram udp wait root /usr/sbin/tcpd in.talkd ntalk dgram udp wait root /usr/sbin/tcpd in.talkd # Kerberos authenticated services # # klogin stream tcp nowait root /usr/sbin/tcpd rlogind -k # eklogin stream tcp nowait root /usr/sbin/tcpd rlogind-k -x # kshell stream tcp nowait root /usr/sbin/tcpd rshd -k # # Services run ONLY on the Kerberos server # # krbupdate stream tcp nowait root /usr/sbin/tcpd registerd # kpasswd stream tcp nowait root /usr/sbin/tcpd kpasswdd # # Pop et al # pop2 stream tcp nowait root /usr/sbin/tcpd in.pop2d pop3 stream tcp nowait root /usr/sbin/tcpd in.pop3d # The ipop3d POP3 server is part of the Pine distribution. If you've # installed the Pine package, you may wish to switch to ipop3d by # commenting out the pop3 line above, and uncommenting the pop3 line below. pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap2 stream tcp nowait root /usr/sbin/tcpd imapd # # The Internet UUCP service. # uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico-l # # Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." # tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd # bootps dgram udp wait root /usr/sbin/in.bootpd in.bootpd # # Finger, systat and netstat give out user information which may be # valuable to potential "system crackers." Many sites choose to disable # some or all of these services to improve security. # Try "telnet localhost systat" and "telnet localhost netstat" to see # that # information yourself! # finger stream tcp nowait nobody /bin/sbin/tcpd in.fingerd systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx netstat stream tcp nowait root /usr/sbin/tcpd /bin/netstat-a # # Ident service is used for net authentication auth stream tcp wait root /usr/sbin/in.identd in.identd -w-t1 20 -l # # # These are to start Samba, an smb server that can export filesystems to # Pathworks, Lanmanager for DOS, Windows for Workgroups, Windows95, #Lanmanager # for Windows, Lanmanager for OS/2, Windows NT, etc. # If you're running smbd and nmbd from daemons in /etc/rc.d/rc.samba, #then you # shouldn't uncomment these lines. netbios-ssn stream tcp nowait root /usr/sbin/smbd smbd netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd # # Sun-RPC based services. # # rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd rpc.rstatd # rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd rpc.rusersd # walld/1 dgram rpc/udp wait root /usr/sbin/tcpd rpc.rwalld # # End of inetd.conf. This is a cut down version, but should look very similar to yours. You need to take some of these services out; the ones you don't use and the ones you don't need. Some of them tell you what they are used for, others don't. You need to go through and see what services you need, and what you don't. For a normal server, I have almost all these services edited out, as they are not used or pose security risks. Here are the services I left open in mine: time stream tcp nowait root internal time dgram udp wait root internal ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -i -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd smtp stream tcp nowait root /usr/sbin/tcpd sendmail -bs talk dgram udp wait root /usr/sbin/tcpd in.talkd ntalk dgram udp wait root /usr/sbin/tcpd in.talkd auth stream tcp wait root /usr/sbin/in.identd in.identd -w -t1 20 -l All the other services I don't use, or can do without. These are essential services that are needed for a server that has users on it. These are services they need so they may connect, send mail, and other basic user activities (ftp, telnet, smtp, talk, ntalk), plus a few other to help me verify connections (auth). All the others you can edit out without fear of cutting off users or hurting the system. I also modified my finger service a bit. I usually have it turned off, but for fun I did this: finger stream tcp nowait nobody /bin/cat cat /etc/finger.txt All this does is, instead of returning the normal `finger' information, is echo a file, the file `/etc/finger.txt', back to the person who has fingered your system. You can put whatever you want to be in the `finger.txt' file, so have a bit of fun with it :). The `/etc/services' file lists the ports on your system that have services connected to them. Think of them like a bunch of open windows that you can go through. You want to close all the windows you're not using or watching because most remote exploits are run on ports that are running some obscure service that no one thinks about or uses. If you take a look at this file, you'll see it's quite large. It lists port numbers with the protocol and the service on each port. You can also edit out ports with the `#' in this file. Here is the man pages definition: `services' is a plain ASCII file providing a mapping between friendly textual names for internet services, and their underlying assigned port numbers and protocol types. Every networking program should look into this file to get the port number (and protocol) for its service. Instead of showing you all the ports, I'll show you what ports I have open, and you can see how they correspond to my `inetd.conf'. netstat 15/tcp ftp 21/tcp ssh 22/tcp #Secure SHell telnet 23/tcp smtp 25/tcp mail time 37/tcp timserver time 37/udp timserver whois 43/tcp nicname finger 79/tcp www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol auth 113/tcp tap ident authentication talk 517/udp ntalk 518/udp As you can see, the majority of the ports do not need to be open. You need to run the minimum number of ports to get the job done. If you're not sure if what a port does, try using `man' and checking what the service is. You can even block a port and see how it goes, then, if needed, come back and unblock it later. One note you want to remember. If the service is open in the `inetd.conf' file, then you also want it to be open in this file as well. The next file is `/etc/nologin'. This file may be useful when you need to lockdown the system to find a problem where you need all the users off the system, track down a problem user or stop a hacker in progress. By simply making a file called `nologin', or what is commonly done is `mv'ing the `motd' file, no non-root users will be allowed to log on to the system. The system will let them log on, it will then echo to them whatever is in the `nologin' file, then terminate their connection. The `/etc/issue.net' and the `/etc/issue' files can be important in taking away a good way of getting information on your system. A lot of people will simply telnet to a system and look at the login prompt to see what type of operating system is running. By changing the `issue' file instead of telnet showing this: Welcome to Linux 2.0.35. Showdown login:_ You can make it show whatever you want. Both of these files are plain ASCII files. Simply edit it and put in whatever you want: \__ ^^ __/ X X \ / \/ Welcome to eLe3t mIcRoSoFt uNiX v6.66 Showdown login:_ The `/etc/passwd', `/etc/shadow' and the `/etc/group' files I hope you already know are very important files. They hold the power is the system and tells the system, who is who and who has the power to do what. I hope, as you are the admin of a box, you know how important these files are. You need to insure the passwords are strong, that there are no users with no passwords, there are no other users except root with the UID of 0 and that the permission on the files are set correctly. By default the permissions are correct, so don't change them. The Shadow Suite takes good care of things though security wise, so besides these simple things, you don't have to worry much about them. Take a chance to look through all three of these files and familiarize yourself with them so you can spot a problem if one were to appear. ------------------------------------------------------------------------ 8. Third Party Tools Well this part I threw in because I have found some free tools floating around the net that are extremely useful. Some of these tools are `must gets'. SSH If you are not running SSH, you need to be. SSH uses keys, similar to PGP, to authenticate logins and then encrypts the session both to and from the server. Someone running a network packet sniffer can very easily capture logins and passwords from another unsecured machine on your LAN, but not if you use SSH. Most newer SSH clients support vt100 and all the cool ASCII colors, and such so by getting it, you're not losing anything, but your gaining a piece of mind and some real security. You can get SSH and read more about it at: SSH FAQ's - http://www.uni-karlsruhe.de/~ig25/ssh-faq/ FiSSH, Free SSH Win95/NT client - http://www.massconfusion.com/ssh/ SSH Club FI - http://www.cs.hut.fi/ssh/ Sentry Although still in Beta form, this is a super useful program I now run on all my systems. Here is a clipping from its README file to briefly tell what it does: The Sentry is part of the Abacus Project suite of tools. The Abacus Project is an initiative to release low-maintenance, generic, and reliable host based intrusion detection software to the Internet community. This program listens to ports, you designate, and takes actions depending on different rules you set for it. This is to give you a heads up that someone may be probing your system, or launching DoS attacks against it. It can log the activity, can add the offending hosts to the `/etc/hosts.deny' file, the local system can be automatically re- configured to route all traffic to the target to a dead host to make the target system disappear and it can also be re-configured to drop all packets from the host via a local packet filter. All and all it's a program I think you need to install, understand and use. You can get more information and get Sentry at: Sentry Abacus Project - http://www.psionic.com/abacus/abacus_sentry.html Logcheck This tool is also part of the Abacus Project and is a must get. When used in conjunction with SSH and Sentry, it can keep you easily informed to the happenings around your system. This program, via cron, checks your logs on a timed basis looking for certain key words that can trigger a level of alert. Like Sentry, you set the rules as to what it looks for and what it does, and it's easily configurable. It can do simple things like e-mail you, or echo to your console or even shut down the system depending on what rules you give it. You can get more information and get Logcheck at: Logcheck Abacus Project - http://www.psionic.com/abacus/abacus_logcheck.html Secure Ping v1.0 This is a secure replacement for the normal `ping' program on your system. `ping' is often abused by users trying to icmp other hosts with the feared pings-of-death and the like. This program limits both users and root as to the sizes of packets and the number of packets that can be sent. If someone tried to abuse Secure Ping, it simply tells the user to take a hike and then sends a line to the log files which Logcheck then picks up later and tells you about. You can get more information and get Secure Ping at: Secure Ping - http://www.sy.net/security Smurf Logger v1.1 This program does what its name says. It logs ICMP Smurf attacks. Unlike a normal ICMP Ping logger, this won't fill up your hard drive with meg after meg of logs. It logs repeat attacks with one line. This is also a nice program to have so you can see if your box is getting hit or not, and then take actions to block it at the router level. You can get more information and get Smurf Logger v1.1 at: Smurf Logger - http://www.sy.net/security Tripwire Tripwire is a tool to use just incase your system has been breached. Once installed correctly, with a correct config file, this program will look at all the files on your system, see their sizes and their dates then, whenever you want, will recheck them to see if they match. This is a good way to find out if a file has been tampered with, trojened or backdoored. The only draw back is that you need to keep a read-only floppy in the floppy drive. You can get more information and get Tripwire at: COAST Archives - ftp://coast.cs.purdue.edu/pub/COAST/Tripwire Lsof This handy file checks for files on the system that are open. They can either be legit files that are opened, like eggdrop files, or they can be files that someone `forgot' to close and is eating up 100% CPU. This is another handy file to have in your arsenal. Prudue Unix Tools - ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/ Well I know there are a ton of other programs out there floating all over the net that, and maybe there are some that do a better job then these do, but these are the ones that I use and the ones I have found that work and are easy to use. As new program come out everyday, you have to keep on the lookout for what's new, and look for what's best for your needs. ------------------------------------------------------------------------ 9. Conclusions Well, as you can see by the shear length of this paper that security for an operating system like Linux is not as simple as it may look. This paper has only touched on the basics of a lot of things you must know and get familiar with. This paper, if in depth, could of gone on to be a book (and I could of charged $50, hehehe), but as with all good papers, it's a work in progress. The bottom line is you have to plan what your needs are going to be. You must implement you system to meet your needs, and then you have to be alert. The admin of a system is the bottom line when it comes to security. The admin must stay alert and watch his system, he must watch the security posts and mailing lists and must keep informed when new patches, kernels and programs come out. An admin must also keep their up-streams informed as well, and stay in good contact with them so they may trade valuable information with you so you both know what is going on. Heck, you can go on forever about what a good sys admin has to do to keep a secure system, but you have to start with knowing your system. I hope this paper has helped. ------------------------------------------------------------------------ PLEASE send me suggestions, tips and advice to help make this paper a better one! [EOF] --------------------------------------------------------------------------- [tip]---------HP-UX: A Security Overview, Part Two =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= HP-UX: A Security Overview, Part Two revision01 10sep98 by: tip (tip@legions.org) --------------------------------------------------------------------------- Table of Contents: 1) Introduction 5) The Trusted System: DB Lib Routines 2) The Trusted System: Auditing 6) Other Info Pt 1 3) The Trusted System: ACLs 7) To Be Continued --------------------------------------------------------------------------- 1) Introduction a) This text is designed to complement to general Unix knowledge. All Unix OS's are different in their own right. This text will delve into HP-UX- specific areas. This is not a Unix tutorial, rather a supplement to fundamental Unix knowledge. b) This text will cover HP-UX version 10.x primarily. Specifically, 10.10 and 10.20 will be in mind. 11.0 has been released and I haven't gotten to checking it out yet. 9.x is old, and no longer supported by HP. Thus, the most logical choice (and most popular version of HP-UX) is 10.x. c) I'm not perfect; please notify me of any errors in the document. Also, if you see anything you want added to this file, feel free to send them to me. --------------------------------------------------------------------------- 2) The Trusted System: Auditing Auditing is a feature only available on Trusted Systems. It provides a means to record events and analyze security. Monitoring is done from the command line or through SAM (Systems Administration Manager). Most commonly, SAM is used to do auditing. Auditing commands These are pretty self-explanatory. Check man pages for detailed info. audsys(1m) : start/halt auditing and set/display audit file information audusr(1m) : select user to audit audevent(1m) : change/display event/syscall status audomon(1m) : set audit file monitoring and size parameters audisp(1m) : display audit record What system calls does auditing log? Basically system calls are grouped into event types. Auditing is selective by this event type, not by particular system calls. One thing to note: the event types of admin, login, and moddac are logged by default. See below for which system calls fit under which event type. These are selectable under SAM. event type: system calls: ----------- ------------- admin audevent(1m), audisp(1m), audswitch(2), audsys(1m), audusr(1m), chfn(1), chsh(1), init(1m), passwd(1), privgrp(2), pwck(1m), reboot(2), sam(1m), setaudid(2), setaudproc(2), setdomainname(2), setevent(2), sethostid(2), settimeofday(2), swapon(2) close close(2) create creat(2), msgget(2), mknod(2), mkdir(2), pipe(2), semget(2), shmat(2), shmget(2) delete msgctl(2), rmdir(2), semctl(2) ipcclose shutdown(2) ipccreat bind(2), socket(2) ipcdgram udp(7) ipcopen accept(2), connect(2) login init(1m), login(1) modaccess chdir(2), chroot(2), link(2), newgrp(1), rename(2), setgid(2), setgroups(2), setresuid(2), setuid(2), shmctl(2), shmdt(2), unlink(2) maddoc chmod(2), chown(2), fchmod(2), fchown(2), fsetacl(2), setacl(2), umask(2) open execv(2), execve(2), ftruncate(2), lpsched(1m), open(2), ptrace(2), truncate(2) process exit(2), fork(2), kill(2), vfork(2) removable smount(2), umount(2), vfsmount(2) uevent1 reserved for custom self-auditing programs uevent2 reserved for custom self-auditing programs So what is a self-auditing program? Basically, the amount of data that is audited can become cumbersome; thus self-auditing programs log only one entry decribing their process, after suspending the auditing of their actions. The intent is to limit and thus, optimize the audit data that is logged. Standard processes that are self-audit capable: audevent(1m), audisp(1m), audsys(1m), audusr(1m), chfn(1), chsh(1), init(1m), login(1), lpsched(1m), newgrp(1), passwd(1), pwck(1m). Where are audit logs located? /.secure/etc/audfile1 (primary log) switch size = 5 megs (AFS) /.secure/etc/audfile2 (auxiliary log) switch size = 1 meg (AFS) Warnings are sent when the log file reaches 90%. The Audit File Switch (AFS, as seen above), is basically a defined limit for the primary log file. The File Space Switch (FFS), is the defined limit for the filesystem for which the audit logs reside on. When the AFS limit is reached for the primary log, the audit logs are stopped, and then started on the auxiliary log. If no auxiliary log exists, it keeps on continuing to log on the primary. Now, if both the AFS and FFS limits are reached, it _still_ continues to log. Obviously this will be logged that the limit has been reached. But when does it stop? Basically a system parameter in the kernel, called min_free, stops all audit log activity if that point is reached. Thus, in a nutshell... -----------------> as size of audit logs increase --------------------> primary AFS reached, give warning, switch to: auxiliary log -> when auxiliary AFS is is reached, give warning, and: watch FFS -> when that limit is reached, give warning, and: watch min_free parameter -> when that limit is reached, halt all audit logs, until they are removed --------------------------------------------------------------------------- 3) The Trusted System: ACLs Access control lists are are basically an "extended" set of permissions for files and directories. Two things to note: 1) ACLs are slowly being phased out (11.0 supports them, but this might be the last version that supports ACLs), and 2) ACLs cannot be used on VxFS (Journal Filesystem, also known as JFS). Two commands are integral to ACLs: lsacl and chacl. Basically think of lsacl as the extended equivalent of ls, while chacl is the extended equivalent of chmod and chown. How are ACLs "extended"? While standard Unix has three sets of permissions, ie: -rwxr--r-- 1 oracle dba 523 Nov 22 1996 run1.sh ACLs enables thirteen additional sets of permissions (ACL entries) to be designated, which are stored in the access control list of the file. Suppose you wanted everyone BUT johndoe to read a file. In standard Unix, you'd have to create a group, put everyone in it except johndoe, then modify the permissions on the file accordingly (basically a pain in the ass). With ACLs, simply type: chacl 'johndoe.users=-rwx' Looking at that file with 'lsacl ' you see: (johndoe.users,---)(root.%,rw-)(%.sys,r--)(%.%,r--) filename Note that modifiers in chacl are + (add permission), - (remove permis- sion), etc. How would you know if a file or directory had additional permissions? Do an 'ls -l' or 'll' on the file: -rwxr--r-+ 1 oracle dba 523 Nov 22 1996 run1.sh Note the "+". This indicates there are additional permissions to be seen with lsacl. ACLs are useful to know within HP-UX, as standard file permissions, listings in /etc/group, etc. can be inconclusive in determining the owner- ship of a file or directory. Other commands (primarily system calls; see man pages for more info): getaccess (command): list access rights to a file. chmod -A (command): the -A option preserves ACLs associated with the file. otherwise, they are deleted. cpset (command): install object files in binary directories. does not set a file's optional ACL entries. find -acl (command): the -acl option supports ACLs. getacl/fgetacl (syscall): get ACL information. setacl/fsetacl (syscall): set ACL information. cpacl/fcpacl (syscall): copy ACL/mode bits from one file to another. setaclentry/fsetaclentry (syscall): set/modify/delete one ACL entry in a file. chownacl (syscall): change ACL owner/group info in a file. acltostr (syscall): convert ACL structure to string form. strtoacl (syscall): convert string form to ACL structure. strtoaclpatt (syscall): parse/convert ACL pattern strings to arrays. --------------------------------------------------------------------------- 4) The Trusted System: DB Lib Routines Basically, these routines are used to manipulate information on both the password file (/etc/passwd), and the trusted system database (/tcb/files/ auth). getdvagent(3): get device entry from /tcb/files/auth/devassign getprdfent(3): get system default entry from /tcb/files/auth/system/default getprtent(3) : get term control entry from /tcb/files/ttys getprpwent(3): get /tcb/files/auth password entries getpwent(3c) : get /etc/passwd entries getspwent(3x): get /tcb/files/auth password entries for standard, non-hp format putprpwnam(3): put password entry in /tcb/files/auth putpwent(3c) : put password entry in /etc/passwd putspwent(3x): put password entry in standard, non-hp format --------------------------------------------------------------------------- 5) Other Info Pt 1 nettl: HP-UX's network sniffer The question arises all too often about the availability of a sniffer for HP-UX. A solution that isn't realized by many is the fact that HP-UX comes with one. Here is the basic syntax for nettl. Check the man page for more detailed information on what you need. Start the logging process, logging all (-e, short for -entity) protocol layers/software modules, outputting to /tmp/legions!! (pduin is the inbound protocol data unit, and obviously, pduout is the outbound protocol data unit): nettl -traceon pduin pduout -e all -f /tmp/legions Stop the logging for all (-e): nettl -traceoff -e all Format the log file to make it readable: netfmt -f /tmp/legions.TRC0 > /tmp/legions.txt --------------------------------------------------------------------------- 6) To Be Continued Welps, that's it for now, kinda short. However, Part 3 will delve into NFS diskless clusters, network services, linklevel access, and other fun stuff. --------------------------------------------------------------------------- Attack on the PKZIP Stream Cipher----------[Pk] A Known Plaintext Attack on the PKZIP Stream Cipher Eli Biham (*) Paul C. Kocher (**) (*) Computer Science Department, Technion - Israel Institute of Technology, Haifa 32000, Israel. (**) Independent cryptographic consultant, 7700 N.W. Ridgewood Dr., Corvallis, OR 97330, USA. (415) 354-8004. ABSTRACT: The PKZIP program is one of the more widely used archive/compression programs on personal computers. It also has many compatible variants on other computers, and is used by most BBS's and ftp sites to compress their archives. PKZIP provides a stream cipher which allows users to scramble files with variable length keys (passwords). In this paper we describe a known plaintext attack on this cipher, which can find the internal representation of the key within a few hours on a personal computer using a few hundred bytes of known plaintext. In many cases, the actual user keys can also be found from the internal representation. We conclude that the PKZIP cipher is weak, and should not be used to protect valuable data. SECTION 1: Introduction The PKZIP program is one of the more widely used archive/compression programs on personal computers. It also has many compatible variants on other computers (such as Infozip's zip/unzip), and is used by most BBS's and ftp sites to compress their archives. PKZIP provides a stream cipher which allows users to scramble the archived files under variable length keys (passwords). This stream cipher was designed by Roger Schlafly. In this paper we describe a known plaintext attack on the PKZIP stream cipher which takes a few hours on a personal computer and requires about 13--40 (compressed) known plaintext bytes, or the first 30--200 uncompressed bytes, when the file is compressed. The attack primarily finds the 96-bit internal representation of the key, which suffices to decrypt the whole file and any other file encrypted under the same key. Later, the original key can be constructed. This attack was used to find the key of the PKZIP contest. The analysis in this paper holds to both versions of PKZIP: version 1.10 and version 2.04g. The ciphers used in the two versions differ in minor details, which does not affect the analysis. The structure of this paper is as follows: Section 2 describes PKZIP and the PKZIP stream cipher. The attack is described in Section 3, and a summary of the results is given in Section 4. SECTION 2: The PKZIP Stream Cipher PKZIP manages a ZIP file[1] which is an archive containing many files in a compressed form, along with file headers describing (for each file) the file name, the compression method, whether the file is encrypted, the CRC-32 value, the original and compressed sizes of the file, and other auxiliary information. The files are kept in the zip-file in the shortest form possible of several compression methods. In case that the compression methods do not shrink the size of the file, the files are stored without compression. If encryption is required, 12 bytes (called the _encryption_header_) are prepended to the compressed form, and the encrypted form of the result is kept in the zip-file. The 12 prepended bytes are used for randomization, but also include header dependent data to allow identification of wrong keys when decrypting. In particular, in PKZIP 1.10 the last two bytes of these 12 bytes are derived from the CRC-32 field of the header, and many of the other prepended bytes are constant or can be predicted from other values in the file header. In PKZIP 2.04g, only the last byte of these 12 bytes is derived from the CRC-32 field. The file headers are not encrypted in both versions. The cipher is byte-oriented, encrypting under variable length keys. It has a 96-bit internal memory, divided into three 32-bit words called key0, key1 and key2. An 8-bit variable key3 (not part of the internal memory) is derived from key2. The key initializes the memory: each key has an equivalent internal representation as three 32-bit words. Two keys are equivalent if their internal representations are the same. The plaintext bytes update the memory during encryption. The main function of the cipher is called update_keys, and is used to update the internal memory and to derive the variable key3, for each given input (usually plaintext) byte: update_keys_{i} (char): local unsigned short temp key0_{i+1} <-- crc32(key0_{i},char) key1_{i+1} <-- (key1_{i} + LSB(key0_{i+1})) * 134775813 + 1 (mod 2^{32}) key2_{i+1} <-- crc32(key2_{i},MSB(key1_{i+1})) temp_{i+1} <-- key2_{i+1} | 3 (16 LS bits) key3_{i+1} <-- LSB((temp_{i+1} * (temp_{i+1} xor 1)) >> 8) end update_keys where | is the binary inclusive-or operator, and >> denotes the right shift operator (as in the C programming language). LSB and MSB denote the least significant byte and the most significant byte of the operands, respectively. Note that the indices are used only for future references and are not part of the algorithm, and that the results of key3 using inclusive-or with 3 in the calculation of temp are the same as with the original inclusive-or with 2 used in the original algorithm. We prefer this notation in order to reduce one bit of uncertainty about temp in the following discussion. Before encrypting, the key (password) is processed to update the initial value of the internal memory by: process_keys(key): key0_{1-l} <-- 0x12345678 key1_{1-l} <-- 0x23456789 key2_{1-l} <-- 0x34567890 loop for i <-- 1 to l update_keys_{i-l}(key_{i}) end loop end process_keys where l is the length of the key (in bytes) and hexadecimal numbers are prefixed by 0x (as in the C programming language). After executing this procedure, the internal memory contains the internal representation of the key, which is denoted by key0_{1}, key1_{1} and key2_{1}. The encryption algorithm itself processes the bytes of the compressed form along with the prepended 12 bytes by: Encryption Decryption ---------- ---------- prepend P_{1},...,P_{12} loop for i <-- 1 to n loop for i <-- 1 to n C_{i} <-- P_{i} xor key3_{i} P_{i} <-- C_{i} xor key3_{i} update_keys_{i}(P_{i}) update_keys_{i}(P_{i}) end loop discard P_{1},...,P_{12} The decryption process is similar, except that it discards the 12 prepended bytes. The crc32 operation takes a previous 32-bit value and a byte, XORs them and calculates the next 32-bit value by the crc polynomial denoted by 0xEDB88320. In practice, a table crctab can be precomputed, and the crc32 calculation becomes: crc32 = crc32(pval,char) = (pval>>8) xor crctab[LSB(pval) xor char] The crc32 equation is invertible in the following sense: pval = crc32^{-1}(crc32,char) = (crc32 << 8) xor crcinvtab[MSB(crc32)] xor char crctab and crcinvtab are precomputed as: init_crc(): local unsigned long temp loop for i <-- 0 to 255 temp <-- crc32(0,i) crctab[i] <-- temp crcinvtab[temp >> 24] <-- (temp << 8) xor i end loop end init_crc in which crc32 refers to the original definition of crc32: crc32(temp,i): temp <-- temp xor i loop for j <-- 0 to 7 if odd(temp) then temp <-- temp >> 1 xor 0xEDB88320 else temp <-- temp >> 1 endif end loop return temp end crc32 SECTION 3: The Attack The attack we describe works even if the known plaintext bytes are not the first bytes (if the file is compressed, it needs the compressed bytes, rather than the uncompressed bytes). In the following discussion the subscripts of the n known plaintext bytes are denoted by 1,...,n, even if the known bytes are not the first bytes. We ignore the subscripts when the meaning is clear and the discussion holds for all the indices. Under a known plaintext attack, both the plaintext and the ciphertext are known. In the PKZIP cipher, given a plaintext byte and the corresponding ciphertext byte, the value of the variable key3 can be calculated by key3_{i} = P_{i} xor C_{i}. Given P_{1},...,P_{n} and C_{1},...,C_{n}, we receive the values of key3_{1},...,key3_{n}. The known plaintext bytes are the inputs of the update_keys function, and the derived key3's are the outputs. Therefore, in order to break the cipher, it suffices to solve the set of equations derived from update_keys, and find the initial values of key0, key1 and key2. In the following subsections we describe how we find many possible values for key2, then how we extend these possible values to possible values of key1, and key0, and how we discard all the wrong values. Then, we remain with only the right values which correspond to the internal representation of the key. Subsection 3.1: key2 The value of key3 depends only on the 14 bits of key2 that participate in temp. Any value of key3 is suggested by exactly 64 possible values of temp (and thus 64 possible values of the 14 bits of key2). The two least significant bits of key2 and the 16 most significant bits do not affect key3 (neither temp). Given the 64 possibilities of temp in one location of the encrypted text, we complete the 16 most significant bits of key2 with all the 2^{16} possible values, and get 2^{22} possible values for the 30 most significant bits of key2. key2_{i+1} is calculated by key2_{i+1} <-- crc32(key2_{i},MSB(key1_{i+1})). Thus, key2_{i} = crc32^{-1}(key2_{i+1},MSB(key1_{i+1})) = (key2_{i+1}<<8) xor crcinvtab[MSB(key2_{i+1})] xor MSB(key1_{i+1}). Given any particular value of key2_{i+1}, for each term of this equation we can calculate the value of the 22 most significant bits of the right hand side of the equation, and we know 64 possibilities for the value of 14 bits of the left hand side, as described in Table 1. From the table, we can see that six bits are common to the right hand side and the left hand side. Only about 2^{-6} of the possible values of the 14 bits of key2_{i} have the same value of the common bits as in the right hand side, and thus, we remain with only one possible value of the 14 bits of key2_{i} in average, for each possible value of the 30 bits of key2_{i+1}. When this equation holds, we can complete additional bits of the right and the left sides, up to the total of the 30 bits known in at least one of the sides. Thus, we can deduce the 30 most significant bits of key2_{i}. We get in average one value for these 30 most significant bits of key2_{i}, for each value of the 30 most significant bits of key2_{i+1}. Therefore, we are now just in the same situation with key2_{i} as we were before with key2_{i+1}, and we can now find values of 30 bits of key2_{i-1}, key2_{i-2},...,key2_{1}. Given this list of 30-bit values, we can complete the 32-bit values of key2_{n}, key2_{n-1},...,key2_{2} (excluding key2_{1}) using the same equation. We remain with about 2^{22} lists of possible values (key2_{n},key2_{n-1},...,key2_{2}), of which one must be the list actually calculated during encryption. Table 1: Side Term Bits# BitsPosition #OfValues ------------------------------------------------------------------ Left key2_{i} 14 2-15 64 Right key2_{i+2} << 8 22 10-31 1 crcinvtab[MSB(key2_{i+1})] 32 0-31 1 MSB(key1_{i+1}) 24 8-31 1 ------------------------------------------------------------------ Total Left Hand Side 14 2-15 64 Total RIght Hand Side 22 10-31 1 ------------------------------------------------------------------ Common bits 6 10-15 Total bits 30 2-31 Subsection 3.2: Reducing the number of possible values of key2 The total complexity of our attack is (as described later) 2^{16} times the number of possible lists of key2's. If we remain with 2^{22} lists, the total complexity becomes 2^{38}. This complexity can be reduced if we can reduce the number of lists of key2's without discarding the right list. We observed that the attack requires only 12--13 known plaintext bytes (as we describe later). Our idea is to use longer known plaintext streams, and to reduce the number of lists based on the additional plaintext. In particular, we are interested only in the values of key2_{13}, and not in all the list of key2_{i}, i=13,...,n. key2_{13} is then used in the attack as is described above. We start with the 2^{22} possible values of key2_{n}, and calculate the possible values of key2_{n-1}, key2_{n-2}, etc. using Equation 1. The number of possible values of key2_{i} (i=n-1, n-2, etc.) remains about 2^{22}. However, some of the values are duplicates of other values. When these duplicates are discarded, the number of possible values of key2_{i} is substantially decreased. To speed things up, we calculate all the possible values of key2_{n-1}, and remove the duplicates. Then we calculate all the possible values of key2_{n-2}, and remove the duplicates, and so on. When the duplicates fraction becomes smaller, we can remove the duplicates only every several bytes, to save overhead. Figure 1 shows the number of remaining values for any given size of known plaintext participating in the reduction, as was measured on the PKZIP contest file (which is typical). We observed that using about 40 known plaintext bytes (28 of them are used for the reduction and 12 for the attack), the number of possible values of key2_{13} is reduced to about 2^{18}, and the complexity of the attack is 2^{34}. Using 10000-byte known plaintext, the complexity of our attack is reduced to 2^{24}--2^{27}. Figure 1: bytes key2 list entries 1 2^{22}=4194304 2 3473408 3 2152448 +-----------------------------+ 4 1789183 | The PostScript version of | 5 1521084 | the paper has a graph here | 10 798169 | showing the number of key2 | 15 538746 | values as a function of the | 20 409011 | number of plaintext bytes. | 25 332606 +-----------------------------+ 30 283930 40 213751 50 174471 100 88248 200 43796 300 31088 500 16822 1000 7785 2000 5196 4000 3976 6000 3000 8000 1296 10000 1857 12000 243 12289 801 Fig 1. Decrease in the number of key2 candidates using varying amounts of known plaintext. These results are for the PKZIP contest file and are fairly typical, though the entry 12000 is unusually low. Subsection 3.3: key1 From the list of (key2_{n}, key2_{n-1},...,key2_{2}) we can calculate the values of the most significant bytes the key1's by MSB(key1_{i+1}) = (key2_{i+1} << 8) xor crcinvtab[MSB(key2_{i+1})] xor key2_{i}. !!! We receive the list (MSB(key1_{n}),MSB(key1_{n-1}),...,MSB(key1_{3})) (excluding MSB(key1_{2})). Given MSB(key1_{n}) and MSB(key1_{n-1}), we can calculate about 2^{16} values for the full values of key1_{n} and key1_{n-1}+LSB(key0_{n}). This calculation can be done efficiently using lookup tables of size 256--1024. Note that key1_{n-1}+LSB(key0_{n}) = (key1_{n}-1) * 134775813^{-1} (mod 2^{32}) and that LSB(key0_{n}) is in the range 0,...,255. At this point we have about 2^{11} * 2^{16} = 2^{27} (or 2^{22} * 2^{16} = 2^{38}) possible lists of key2's and key1_{n}. Note that in the remainder of the attack no additional complexity is added, and all the additional operations contain a fixed number of instructions for each of the already existing list. The values of key1_{n-1}+LSB(key0_{n}) are very close to the values of key1_{n-1} (since we lack only the 8-bit value LSB(key0_{n})). Thus, an average of only 256 * 2^{-8} = 1 possible value of key1_{n-1} that leads to the most significant byte of key1_{n-2} from the list. This value can be found efficiently using the same lookup tables used for finding key1_{n}, with only a few operations. Then, we remain with a similar situation, in which key1_{n-1} is known and we lack only eight bits of key1_{n-2}. We find key1_{n-2} with the same algorithm, and then find the rest of key1_{n-3}, key1_{n-4}, and so on with the same algorithm. We result with about 2^{27} possible lists, each containing the values of (key2_{n}, key2_{n-1},...,key2_{2}, and key1_{n}, key1_{n- 1},...,key1_{4}) (again, key1_{3} cannot be fully recovered since two successive values of MSB(key1) are required to find each value of key1). Subsection 3.4: Given a list of (key1_{n}, key1_{n-1},...,key1_{4}), we can easily calculate the values of the least significant bytes of (key0_{n}, key0_{n-1},...,key0_{5}) by LSB(key0_{i+1}) = ((key1_{i+1}-1) * 134775813^{-1})-key1_{i} (mod 2^{32}). key0_{i+1} is calculated by key0_{i+1} <-- crc32(key0_{i},P_{i}) = (key0_{i} >> 8) xor crctab[LSB(key0_{i}) xor P_{i}]. Crc32 is a linear function, and from any four consecutive LSB(key0) values, together with the corresponding known plaintext bytes it is possible to recover the full four key0's. Moreover, given one full key0, it is possible to reconstruct all the other key0's by calculating forward and backward, when the plaintext bytes are given. Thus, we can now receive key0_{n},...,key0_{1} (this time including key0_{1}). We can now compare the values of the least significant bytes of key0_{n-4},...,key0_{n-7} to the corresponding values from the lists. Only a fraction of 2^{-32} of the lists satisfy the equality. Since we have only about 2^{27} possible lists, it is expected that only one list remain. This list must have the right values of the key0's, key1's, and key2's, and in particular the right values of key0_{n}, key1_{n} and key2_{n}. In total we need 12 known plaintext bytes for this analysis (except for reducing the number of key2 lists) since in the lists the values of LSB(key0_{i}) start with i=5, and n-7=5 ==> n=12. If no reduction of the number of key2 lists is performed, 2^{38} lists of (key0, key1, key2) remain at this point, rather than 2^{27}. Thus, we need to compare five bytes key0_{n-4},...,key0_{n-8} in order to remain with only one list. In this case, 13 known plaintext bytes are required for the whole attack, and the complexity of analysis is 2^{38}. Subsection 3.5: The Internal Representation of the Key Given key0_{n}, key1_{n} and key2_{n}, it is possible to construct key0_{i}, key1_{i} and key2_{i} for any i> 8) P_{i} = C_{i} xor key3_{i} key0_{i} = crc32(key0_{i+1},P_{i}) The resulting value of (key0_{1},key1_{1},key2_{1}) is the internal representation of the key. It is independent of the plaintext and the prepended bytes, and depends only on the key. With this internal representation of the key we can decrypt any ciphertext encrypted under the same key. The two bytes of crc32 (one byte in version 2.04g) which are included in the 12 prepended bytes allow further verification that the file is really encrypted under the found internal representation of the key. Subsection 3.6: The Key (Password) The internal representation of the key suffices to break the cipher. However, we can go even further and find the key itself from this internal representation with the complexities summarized in Table 2. The algorithm tries all key lengths 0, 1, 2, ..., up to some maximal length; for each key length it does as described in the following paragraphs. Table 2: Complexity of finding the key itself ----------------------------------------------------------------- Key length 1-6 7 8 9 10 11 12 13 Complexity 1 2^{8} 2^{16} 2^{24} 2^{32} 2^{40} 2^{48} 2^{56} ----------------------------------------------------------------- For l <= 4 it knows key0_{1-l} and key0_{1}. Only l <= 4 key bytes are entered to the crc32 calculations that update key0_{1-l} into key0_{1}. Crc32 is a linear function, and these l <= 4 key bytes can be recovered, just as key0_{n},...,key0_{n-3} recovered above. Given the l key bytes, we reconstruct the internal representation, and verify that we get key1_{1} and key2_{1} as expected (key0_{1} must be as expected, due to the construction). If the verification succeeds, we found the key (or an equivalent key). Otherwise, we try the next key length. For 5 <= l <= 6 we can calculate key1_{0}, key2_{0} and key2_{-1}, as in Equation 2. Then, key2_{2-l},...,key2_{-2} can be recovered since they are also calculated with crc32, and depend on l-2 <= 4 unknown bytes (of key1's). These unknown bytes MSB(key1_{2-l}),..., MSB(key1_{-1}) are also recovered at the same time. key1_{1-l} is known. Thus, we can receive an average of one possible value for key1_{2-l} and for key1_{3-l}, together with LSB(key0_{2-l}) and LSB(key0_{3-l}), using the same lookup tables used in the attack. From LSB(key0_{2-l}) and LSB(key0_{3-l}) and key0_{1-l}, we can complete key0_{2-l} and key0_{3-l} and get key_{1} and key_{2}. The remaining l-2 key bytes are found by solving the l-2 <= 4 missing bytes of the crc32 as is done for the case of l <= 4. Finally, we verify that the received key has the expected internal representation. If so, we have found the key (or an equivalent key). Otherwise, we try the next key length. For l>6, we try all the possible values of key_{1},...,key_{l-6}, calculating key0_{-5}, key1_{-5} and key2_{-5}. Then we used the l=6 algorithm to find the remaining six key bytes. In total we try about 2^{8 * (l-6)} keys. Only a fraction of 2^{-64} of them pass the verification (2^{-32} due to each of key1 and key2). Thus, we expect to remain with only the right key (or an equivalent) in trials of up to 13-byte keys. Note that keys longer than 12 bytes will almost always have equivalents with up to 12 (or sometimes 13) bytes, since the internal representation is only 12-bytes long. SECTION 4: Summary In this paper we describe a new attack on the PKZIP stream cipher which finds the internal representation of the key, which suffices to decrypt the whole file and any other file which is encrypted by the same key. This known plaintext attack breaks the cipher using 40 (compressed) known plaintext bytes, or about the 200 first uncompressed bytes (if the file is compressed), with complexity 2^{34}. Using about 10000 known plaintext bytes, the complexity is reduced to about 2^{27}. Table 3 describes the complexity of the attack for various sizes of known plaintext. The original key (password) can be constructed from the internal representation. An implementation of this attack in software was applied against the PKZIP cipher contest. It found the key "f7 30 69 89 77 b1 20" (in hexadecimal) within a few hours on a personal computer. Table 3: Complexity of the attack by the size of the known plaintext Bytes Complexity ------- ---------- 13 2^{38} 40 2^{34} 110 2^{32} 310 2^{31} 510 2^{30} 1000 2^{29} 4000 2^{28} 10000 2^{27} A variant of the attack requires only 13 known plaintext bytes, in price of a higher complexity 2^{38}. Since the last two bytes (one in version 2.04g) of the 12 prepended bytes are always known, if the known plaintext portion of the file is in its beginning, the attack requires only 11 (12) known plaintext bytes of the compressed file. (In version 1.10 several additional prepended bytes might be predictable, thus the attack might actually require even fewer known plaintext bytes.) We conclude that the PKZIP cipher is weak and that it should not be used to protect valuable information. --------------------------------------------------------------------------- [Shadow]---------Coordinated TCP Attacks and Probes SHADOW Indications Technical Analysis Coordinated Attacks and Probes Updated Oct 05 1998 codebits Executive Summary: This document details attacks and probes that have been recently observed in which multiple attackers are clearly working together toward a common goal from different IP addresses. Often these IP addresses are also physically separated, in different countries or even different continents. There are three obvious purposes for this type of activity: - Stealth. By working from multiple IP addresses the attackers achieve a smaller per-IP signature and are more difficult to detect with conventional means. In addition, stealth is enhanced by the development of new hard-to-detect probing techniques. - Firepower. By coordinating multiple attacking IP addresses, the attackers will be able to deliver more exploits on target in a smaller time window. Target in this case can be one or more sites. Further, the defense technique of blocking an attacker IP or subnet (shunning) will be less effective. We believe that the use of coordinated scans and probes from differing sites represents a new and continuing capability that merits further analysis and tracking. Some of these coordinated probes and scans we are seeing today may be practice runs for future larger scale attacks. - More data. By working from different IP addresses, often entirely different subnets, against the same target it is possible to obtain data that is difficult from a single source IP scan or probe. This data may include shortest route data (i.e. packets from source A arrive faster than from source B), or even potential backdoors (i.e. packets from source A can gain access to hosts that source B can't see). This type of data can be used to optimise future scans, probes, or attacks. Analysis: Multiple different attacks and probes are documented here. The commonality is that the attacker is able to launch the attack from multiple unrelated (or partially related) addresses in a coordinated fashion. Special thanks to Rob Cardoza, Vicki Irwin, and Pedro Vazquez for their help in deciphering this puzzle. =============================== EXAMPLE 1: Coordinated traceroutes These have been reported previously, but they make an excellent example of the general approach. Five different sources all hit the target (a firewall) within minutes of each other. The signature of each hit is nearly identical. Note the use of two entirely different domains within seconds of each other. This will allow them to have timing data for multiple paths. 12:29:30.012086 proberA.39964 > target.33500: udp 12 [ttl 1] 12:29:30.132086 proberA.39964 > target.33501: udp 12 [ttl 1] 12:29:30.252086 proberA.39964 > target.33502: udp 12 [ttl 1] 12:29:30.352086 proberA.39964 > target.33503: udp 12 [ttl 1] 12:29:30.482086 proberA.39964 > target.33504: udp 12 [ttl 1] 12:27:37.712086 proberB.46164 > target.33485: udp 12 [ttl 1] 12:27:55.122086 proberB.46164 > target.33487: udp 12 [ttl 1] 12:27:55.162086 proberB.46164 > target.33488: udp 12 [ttl 1] 12:27:55.182086 proberB.46164 > target.33489: udp 12 [ttl 1] 12:29:26.132086 proberC.43327 > target.33491: udp 12 [ttl 1] 12:29:26.242086 proberC.43327 > target.33492: udp 12 [ttl 1] 12:29:26.372086 proberC.43327 > target.33493: udp 12 [ttl 1] 12:29:26.482086 proberC.43327 > target.33494: udp 12 [ttl 1] 12:27:32.962086 proberD.55528 > target.33485: udp 12 [ttl 1] 12:27:33.072086 proberD.55528 > target.33486: udp 12 [ttl 1] 12:27:33.172086 proberD.55528 > target.33487: udp 12 [ttl 1] 12:27:33.292086 proberD.55528 > target.33488: udp 12 [ttl 1] 12:27:33.422086 proberD.55528 > target.33489: udp 12 [ttl 1] 12:27:30.552086 proberE.com > target.33475: udp 12 [ttl 1] 12:27:30.562086 proberE.com > target.33476: udp 12 [ttl 1] 12:27:30.582086 proberE.com > target.33477: udp 12 [ttl 1] 12:27:30.592086 proberE.com > target.33478: udp 12 [ttl 1] 12:27:30.612086 proberE.com > target.33479: udp 12 [ttl 1] Special note: Recently we began screening for large ICMP packets. Many of the ICMP scans we categorized as Smurf attacks were in excess of 1k. Such packets can be used for maximum transmission unit of a path discovery. Please see page 152 in Stevens' TCP/IP Illustrated for further information.[1] Also note the DF flag will be set.[2] =============================== EXAMPLE 2 Simultaneous Reset Scans During the week of 13 SEP Reset Scans were observed from 14 different internet addresses, primarily ISPs. They are working together and are mapping multiple target sites. This appears to be a long term effort, some of the attackers scan rate is as low as 2 packets/day/ target site, well below commonly set thresholds for scan detectors. Until recently these types of scans were easy to detect due to common "signature acknowledgement numbers" (i.e. the IP packet ACK field was always a fixed number, usually 674719802 or 674711610). The more recent probes have random acknowledgement numbers. We thank DISA for the advice on improving the algorithm[3]. The primary signature here is RESET packets with no other activity from that source (such as an active open (SYN) from the source or the target). 17:40:45.870769 hook.24408 > target1.1457: R 0:0(0) ack 674719802 win 0 17:40:53.025203 hook.33174 > target2.1457: R 0:0(0) ack 674719802 win 0 17:41:12.115554 hook.36250 > target3.1979: R 0:0(0) ack 674719802 win 0 17:43:37.605127 router > hook: icmp: time exceeded in-transit 17:43:43.139158 hook.44922 > target4.1496: R 0:0(0) ack 674719802 win 0 17:42:30.400665 grin.3532 > target1a.1167: R 0:0(0) ack 674719802 win 0 17:42:40.582531 grin.33233 > target2a.1797: R 0:0(0) ack 674719802 win 0 17:44:28.836701 grin.52504 > target3a.1634: R 0:0(0) ack 674719802 win 0 17:47:52.578558 grin.46657 > target4a.2121: R 0:0(0) ack 674719802 win 0 17:47:52.698378 router > grin: icmp: time exceeded in-transit NOTE: When the target site's router replies back to the attacker, they know that host or net does not exist. By locating the places that do not exist, they can take the inverse of the map to target future exploit efforts, scans, probes, or attacks. =============================== EXAMPLE 3 Coordinated Exploits To date the coordinated exploits have neither been large scale nor effectual. The scale at least is certain to change as shown by the recent escalation of reset scans. Some examples of coordinated exploits are shown to illustrate this technique. In addition to the patterns shown below, we have seen UDP 137 (NBTSTAT) scans with similar signatures. Example 3A Searching for Back Orifice This had been seen previously but rarely. In a short time frame three attackers were detected at multiple target locations using the same signature. Two (A and B) are shown here: 04:10:34.355832 dax.no.1534 > TARGETBa.31337: udp 19 04:51:15.261462 cpu.com.1534 > TARGETBb.31337: udp 19 04:54:19.101595 dax.no.1534 > TARGETBc.31337: udp 19 06:51:39.392441 dax.no.1534 > TARGETAa.31337: udp 19 06:52:32.700418 cpu.com.1534 > TARGETAb.31337: udp 19 06:06:52.320331 eb.net.1534 > TARGETAc.31337: udp 19 Example 3B DNS ZONE Here we see an interesting pattern occurring within the same day. SourceA connects first, there is no RESET from the DNS server. SourceB then connects from an entirely different IP subnet to the same DNS server and generates a RESET. 07:15:17.563185 SourceA.56141 > TARGETA.domain: S 5335035:53 35035(0) ack 5335034 win 4128 07:15:17.565758 SourceB.domain > TARGETA.domain: S 4601818:46 01818(0) ack 4601817 win 4128 07:15:17.570577 TARGETA.domain > SourceB.domain: R 4601817:46 01817(0) win 24576 22:11:13.044850 SourceA.18052 > TARGETB.domain: S 5624156:56241 56(0) ack 5624155 win 4128 22:11:13.479834 SourceB.domain > TARGETB.domain: S 4849093:48490 93(0) ack 48490