Copy Link
Add to Bookmark
Report
United Hackers Association 1 Issue 02
|---------------------------------------------------------------------------|
| -=[ United Hackers Association 1 - Magazine, Issue II ]=- |
| September 01, 1998 |
| E-Mail : uha1@gmx.net |
| Homepage : http://come.to/UHA |
|---------------------------------------------------------------------------|
--->>> THIS IS ISSUE 2 !!!
|---------------------------------------------------------------------------|
| 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 you can 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. How To Hack Geocities Webpages & Mailboxes (by AcidMeister)
2. How To Hack Mailcity Webpages & Mailboxes (by AcidMeister)
3. Installing & Hacking From Linux (by AcidMeister)
4. Some Technics Of Hacking NT (by mad55)
5. Exploit in Windows NT (local) (by mad55)
6. Dialing Out Of Unix Systems (by AcidMeister)
7. List Of Dialup Passwords (by AcidMeister)
8. Some things To Do To Keep Safe Once You Get Root (by AcidMeister)
9. How To Hack Your School (THE BASICS) (by AcidMeister)
10. Techniques to Hide One's Identity (by AcidMeister)
11. Trojans (by AcidMeister)
12. Easy hack (by Latvious)
Editor of this Magazine Leader/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 (with subject line = UHA MAGAZINE),
we will review it and if it is a good one we will publish it.
Note : All texts are welcome.
Write about everything you want, but it has to be related with
hacking/cracking/phreaking/carding/virii/computers ...etc. -thanx-
!!IMPORTANT!!
--> If you have any questions, please don't mail us or the authors,
--> just go to our Homepage and post a message in our BBS!!!
!!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. How To Hack Geocities Webpages & Mailboxes
by AcidMeister
ameister@vol.com
July 31, 1998
Get a fucking account at geocities.com, now goto the members section
choose filemanager and login with your login and password, on the next page
you get to, view the source code (the page name should be file_manager.htm.)
On about line 178 you should see something to similliar to this, if you dont
want to count all these lines then put all the html code into notepad and
run a search for passwd, and somewhere around that area you will find the
info you need. A # represents a comment made by me.
<INPUT TYPE="hidden" NAME="member" VALUE="nickom666"> #username
<INPUT TYPE="hidden" NAME="passwd" VALUE="_5gaVFNYeEiYrv=z/kdKK"> #i think it's an encrypted passsword of some sort
<INPUT TYPE="hidden" NAME="fulladdress" VALUE="SiliconValley/Foothills/7281"> #webpage address
<INPUT TYPE="hidden" NAME="subdirectory" VALUE=""> # something you don't need
<INPUT TYPE="hidden" NAME="email" VALUE="acidmeister@hotmail.com"> # e-mail address person subscribed with
<INPUT TYPE="hidden" NAME="geoextras" VALUE="NN1NN"> #don't know don't care
<INPUT TYPE="hidden" NAME="diskspace" VALUE="11"> #don't know don't care
<INPUT TYPE="hidden" NAME="timestamp" VALUE="901868702"> #ehhh a timestamp
</FORM>
<form method="post" action="/cgi-bin/geoguide/geoguide_verify">
<INPUT TYPE="hidden" NAME="member" VALUE="nickom666"> #username ---the information you need
<INPUT TYPE="hidden" NAME="passwd" VALUE="hlxwxe"> #passwd ---the information you need
Now you're goodie hackerz instict, if you have any. Should tell you the
following. If you can get someone to give you that page you can simple open
it and you'll be in their account. Now Ezoons has kept this a secret for a
long time, so let's try not to spread it to every goddamn lamer on earth.
OK let's get on with da hack....
First find a fucking webpage at geocities, that shouldn't be hard, if you
cant't find one then you're not a fucking hacker. Get a fake e-mail account
at mailcity.com or hotmail.com or some other crappy place, give them all fake
info on you. Now e-mail the guy make up some dumbass story, shit i dont know
you're someone who wants to try out this new program, what it does is log
attempts to hack your webpage, tell him inorder to run this program you must
customize specifiacly for his page so tell him to do the following. Log into
his geocities account and once he has logged in, to save that page and send
it to you, the page should be named file_manager.htm. Well thats it once you
get the file just double click it and you'll be directly in his file place on
Feocities. To get into his mailbox you will have to look at the source code
of the file he sends you and filter out the username and password, in the
file_manager.htm file.
Then just login with his username and password, pretty nifty eh.
Thank Ezoons for this, i just wrote this text file out of boredom and to
educate you on the general stupidity of these servers, and also to
encourage you to try things on your own such as reading about a great
exploit on hotmail and then not trying it anywhere else.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
2. How To Hack Mailcity Webpages & Mailboxes
by AcidMeister
ameister@vol.com
July 31, 1998
Get a fucking account at mailcity.com login to
their webpage thingy once you're logged in view the
source on that page the name should be bedit.html, well
if you look down about 17,18 lines you should see
something like this.
<input type=hidden name=storage value="computers">
<input type=hidden name=hpd value="lamer"> #his login
<input type=hidden name=password value="thepassword"> #his password
Noe you're goodie hackerz instict, if you have any.
Should tell you the following. If you can get someone
to give you that page you can simple open it and you'll
be in their account. Now Ezoons has kept this a secret
for a long time, so let's try not to spread it to every
goddamn lamer on earth.
OK let's get on with da hack....
First fidn a fucking webpage at mailcity, at the moment
this can be pretty hard to find, but I'm sure that with
time it will gain popularity, so once you have your
target. Get a fake e-mail account at mailcity.com or
hotmail.com or some other crappy place, give them all
fake info on you. Now e-mail the guy make up some
dumbass story, shit i dont know you're someone who
wants to try out his new program, what it does is log
attempts to hack your webpage, tell him inorder to run
this program you must customize specifiacly for his page
so tell him to do the following. Log into his mailcity
account and once he has logged in, to save that page and
send it to you, the page should be named bedit.html.
Well thats it once you get the file just double click it
and you'll be directly in his file place on mailcity.
To get into his mailbox you will have to look at the
source code of the file he sends you and filter out the
username and password, you know the ones on line 17 & 18.
Then just login with his username and password,
pretty nifty eh. Thank Ezoons for this, i just wrote
this text file out of boredom and to educate you on the
general stupidity of these servers, and also to
encourage you to try things on your own such as reading
about a great exploit on hotmail and then not trying it
anywhere else.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
3. Installing & Hacking From Linux
by AcidMeister
ameister@vol.com
July 01, 1998
All you people that thought you were good hackers, because you could fool
dumb sysadmins, and do a bit of social engineering, or hack something by
following someones carefully prepared text file. Well you're about to get
fucked if you read this text file you will find out that you are a hacker
but, the only thing you can do is use someone elses ideas. So with that in
mind here goes.
I wrote this text file because i know a lot of people who could
benefit from learning to use linux, especially when hacking.
First of all you need to get linux installed on your system so goto
http://www.redhat.com I would suggest you invest $40 in buying the newest
version of RedHat linux this way you will get all the files you want/need
on one cd. If you have a problem with paying that price, then contact me
and i will ship you a copy for half that price, yes only $20! If you are
really cheap (like me :-) you could try and download it, i have gotten it
to work before but it's really not worth the wait, i spent a total download
time of about 3 days to download all the files i wanted, and if one of the
files dosn't work, well you're pretty much fucked. Whatever you decide to
do, weather it's purchasing a copy from me or from redhat.com, or being
cheap :-) and downloading it, you should read the linux documentation
project especially the installation part, it will save you hours of worry.
I will touch down very briefly on what you have to do to install linux, but
not nearly enough for you to understand the installation. Many people will
tell you not to buy RedHat products because they're full of bugs, this is
true, and I couldn't agree more, but the bugs are present if you're trying
to hack teh box, so in this case just get RedHat Linux, since it's by far
the most user friendly and the easiest to install. On the other hand if you
are intending to run a sophisticated webserver do NOT get redhat, get
something like slackware, or debian linux.
If you are planning to use linux to access the net etc... you will
need to read the FAQ on compatability at http://www.redhat.com, i currently
don't know of any distribution of linux that supports winmodem or any other
type of modem that uses windows software to speed it up, these modems are
generally those yukky U.S robotics modems.
From now on I'm assuming you either purchased RedHat linux from me
or from RedHat. O.K lets get started, you will need to partition your
harddrive, to do this goto dos and type in fdisk choose no. 4 to view current
partitions. If you have one large partition that fills your whole harddrive
just reserved for windows then once again you're fucked. You need to back up
all your shit, before performing the steps below. Once everything is backed
up go to dos yet again and type 8in fdisk, now you need to delete your
current partition and set a new primary partition the primary partition
should not fill your whole harddrive, leave as much space as you want
unpartitioned, this unpartitioned space is what you're going to be putting
linux on. So now thats done restore your old windows shit and make sure
everything is working nice and dandy. Now pop in your redhat cd in your
cd-rom drive, and reboot your system. Follow the instructions until you
get to a screen that asks if you wish to use fdisk or disk druid to partition
your harddrive, just choose disk druid, now you need to set up a native linux
partition i recommdn 500 megs, but if you wanna be fancy put about 800 megs.
Now after you have assighned a native linux partition and labeled it / Then
you need to assighn swap space, assighn as much as you see fit mine is about
55 megs. It is also a good idea to label your dos partition i label mine
/dos this is so i can access files in my dos partition while using linux.
Once that is done click on OK and save the partition tables, when you get to
the place where you choose what to install. If you have a partition thats
more than 600 MB then choose the install everything option at the bottom of
the list, if your partition is below 600 MB, then choose everything on the
list except the install everything option. If by some chance you just want
a very basic setup, this is what i used to run, just choose x-windows, DNS
Nameserver, Dial-UP workstation,c++ development, and c development. This
will give you everything youneed to compile programs in ,linux, connect to
your ISP, run x-windows etc....
X-Windows is a graphical interface for linux it's very very nice
it's kinda like windows 95 but it dosn't suck as much, by the way I will be
refeering to windows 95 as winblows, for obvious reasons :-).
Once everything is installed, it will tr to sonfigure x-windows for
you, this is where it actually helps if you know every little chip in your
system, if you don't well tehn just guess, but whatever you do don't install
Metro-X, just install XFree86 x-server it's better, well after all that shit
you will need to install LILO, LILO is a boot manager it allows you to boot
into dos, linux and whatever other O/S's you may have lying around in yuor
system, once all that is set up, you will be asked if you wish to install a
printer or not, figure that part out yourself, it's pretty straight forward,
so I'm not gonna waste my time. I wouldn't recommend configuring a LAN
unless you know your shit about linux.
So once setup is finished , your system will reboot. WOA you just
installed linux and you're still alive it's amazing isn't it. So now you
should be faced with a prompt that says LILO Boot:
you can now press tab for options this will show which operating systems you
can boot into. You should ahve the following two choices dos and linux, now
since this text file covers linux you would want to boot into linux so at
the LILO prompt type in linux or simply press return, since linux is your
default operating system. Now you should see a bunch of services starting,
this indicates that linux is loading.
When you reach the login prompt type in root and use the password
you specefied for the setup program earlier. Finally you have redhat linux
installed on your system, and hopefully you're still alive, you're still
with me RIGHT!!!!! O.K so you have logged in as root, first thing you want
to do us shadow your password file I always do thsi because then at least i
know a little clueless newbie could never get in my system, to do this type
in pwconv. Well thats all you have to do, to me it's a shock that there are
so many unshadowed systems on the net when it's so easy to shadow the
password file, but i guess ignorance is the satan of all god's people. Well
i guess you're like dying to show your friends how k-rad and elite you are,
so I guess well better geton to setting up linux to use the net, in other
words to dial out to your ISP. O.K heres how you do it. When you're at the
prompt type in startx this will start up x-windows. Once x-windows is
started, you should see an interface much like windows 95, to the left
should be a box named control panel, in the center you should see a window
named local-host, this is simply the rootshell just like the one you get
when you login. Now to get the modem set up, in the control panel there
should be a lot of small icons, goto the 6th one down (modem configuration)
choose what com port your modem is on, if you dont know choose SOM 1 it
seems to be the default in most computers in gateways i do believe it's
COM 2, once thats done, goto the 5th icon down in the control panel
(network configuration)and click it, now choose interfaces then goto add,
choose ppp as your interface type. Put in your ISP's phone number, and
your login and password. Then choose customize, click on networking and
click on activate interface at boot time, once this is done goto done and
choose to save the configuration. Well thats it simply reboot by typing in
reboot and listen to your sweet modem's music.
Now that you're connected to your ISP let's go do some surfing, once
you're in x-windows, goto start/applications and click on Netscape Navigator.
Visit http://www.rootshell.com and run a search for scan, once you're
confronted with the search results, go down and find the file named
xenolith.tgz download that file. This is a neat little scanner that scans
sites for volunerabilities, and I'm basiacly gonna give you a lesson in
uncompressing files in linux. Once the file is downloaded goto the dir in
which it resides. Since it's a .tgz file we would uncompress it using the
following method. Type in gunzip -d xenolith.tgz this will give you
xenolith.tar then type in gzip xenolith.tgz this gives you xenolith.tar.gz
then type in zcat xenolith.tar.gz | tar xvf - . This will give you a dir
called xenolith just cd xenolith and read the README files for installation
instructions. I just thought i would include something on uncompressing
files because many people ask me for help on the topic.
Well I'm getting to the place where I have to think about what i
want to put in this text file, well here's something I will include, a
section with some useful command, so here goes. To shutdown your computer
type in shutdown -h now (your message) to reboot simply type reboot. To
compile use gcc filename.c -o filename. To talk to a user type in write
username then on the next line write your message, if you don't want people
to send you messages type in mesg n. Well i sure hop this guide helped you
through getting linux installed if you want to read books on linux and
you're cheap like me goto http://www.mcp.com and sighn up for their personal
bookshelf, and get reading tons of books for free, it's a hackers dream and
all time paradise.
Now just as you thought it was over I'm gonna show you a few hacking
tricks from linux not really how to hack just some useful commands, so here
goes. To telnet to a site type in telnet www.victim.com ,to telnet toa
site on a specific port type in telnet www.victim.com portnumbe. Let's say
i wanted to telnet to port 25 i would type in telnet www.victim.com 25 .
To FTP to a machine type in ftp www.victim.com. To rlogin to a machine,
many of you proably dont know what the hell im talking about so let me
explain. If you place a file called .rhosts in someones home directory and
that file has two plusses like this + + in it you can use the rlogin command
to log into the system using that account without a password. Ring a bell
in your mind? filling with fresh ideas. I use this method whenever I geta
shell account, it assures me that if they by any chance change the passowrd
I can always rlogin into the system assuming that the account has a .rhosts
file in it and the file contains + + then you're in good shape. Assume the
username of the account is lamer. So inorder to rlogin into lamer's account
we would do the follwoing. Type in rlogin www.victim.com -l lamer . This
will telnet us directly into lamer's account where we can start rooting the
system.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
4. Some Technics Of Hacking NT
by mad55
mad55@hotmail.com
August 20, 1998
As it slowly becomes more and more clear to those network people
that tons of security information about Unix can be found, but little to
none is available on windows NT. This paper will walk and
educate someone on the steps involved in some of todays most used windows NT
exploits.
For the remainder of this paper I will refer to a few terms that you should
know...
www.victim.com = The server you are trying to check the exploit on.
Also remember that when I say to type stuff it is case sensative.
These techniques are listed in no particular order, just how my brain was
thinking at the time.
Is it an NT server?
To check if a server is nt there are a few things you can do...
1. Telnet to it on port 21 (ftp) and see if it says nt.
2. Goto http://www.netcraft.com/cgi-bin/Survey/ whats and see what it
says for the server.
3. Check if the server simply says what it is running. (check their page)
4. Try NBTSTAT -A [ip address] and check the response.
If you really want to become familiar with better detection methods, you
should become more familiar with WindowsNT as an operating system.
Common user names:
Administrator
Guest
mail
Password file locations:
\\WINNT\SYSTEM32\CONFIG\SAM
\\WINNT\REPAIR
Ok, so you found an NT server, now what?
Does it have file sharing?
To check if a server has file sharing you do the following...
1. dns www.victim.com and get the IP
2. goto a dos prompt and type: nbtstat -A IPADDRESS
You will get one of 2 things back:
A. Host not found. (if you get host not found, that is not exactly an
accurate error statement. If a router (or the NT server itself) has clossed
of ports 137,138,139.. you will also get this error message. for more on the
ports, check out the NetBIOS paper at the rhino9 site)
or you will get a listing somewhat like thins:
B. NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
TARGET <00> UNIQUE Registered
A DOMAIN <00> GROUP Registered
TARGET <03> UNIQUE Registered
TESTUSER <03> UNIQUE Registered
TARGET <20> UNIQUE Registered
A DOMAIN <1E> GROUP Registered
MAC Address = 00-60-97-35-C1-5C
If you got this then the remote computer has file sharing.
To try and access this file sharing you do one of 2 things.
1. edit the c:\windows\lmhosts (the LMHOSTS file is a flat text file
containing NetBIOS to IP address mappings) and add in a line at the very top
that has the ip address then a space then the first unique name, in this
case target. So the lmhosts would look like this:
Servername(call it whatever you want) ServersIPAddress
Next click your start button then goto find then computer. Then in the Named
box put in the first unique name, the name that you added to the lmhosts
file as the servername. Hit enter and hopefully a little icon of a computer
will show up. Double click this icon. If the filesharing on the target
computer is passworded it will popup a password box. You can either try to
guess the password or brute force it.
The second way to do filesharing is this...
drop to a dos prompt and type
net use \\IPADDRESSOFTARGETCOMPUTER\c$
what this will try to do is connect to the target computers shared drive C.
c$ means drive C. This might prompt you for a password also.
You would be suprised how many people dont have passwords.
A word on ASP Viewing:
Say you goto www.victim.com/secretinfo.asp and it has forms or whatever and
you are wonder hmm whats behind this asp code wonder if there is something
secret in it like passwords or something. To view the code inside a .asp
file you simply do the following:
http://www.victim.com/secrectinfo.asp.
Note: This is patched on newer systems (systems running service pack 2 or
3).
A word on Dumping directorys:
To break out of the wwwroot directory (the web server directory) simply put
in the following: http://www.victim.com/..\.. (this may not work on IIS
3.0/NT 4.0 running service pack 3)
A quick note on the Find File Exploit:
This exploit is often used and works on a vast number of servers, its an
underground favorite.
By going to:
http://www.victim.com/samples/search/queryhit.htm
If it brings up a search page then the server is more than likely wide open
for attack. In this field you can search for files and the deadliest part is
that you can view these files.
So we maybe search for:
\\WINNT\SYSTEM32\CONFIG\SAM - thats the nt password file
\\WINNT\REPAIR - thats the backup nt password file
#filename=*.pwd - thats the frontpage server extensions password file. Which
I will explain how to crack later.
another - any other keywords which might lead to intersting files that they
dont want you to read.
Also play with:
http://www.victim.com/scripts/samples/search/webhits.exe
In depth FrontPage Hacking, mad55/super style:
Well these are the techniques that I know best.
First off you must have frontpage! You cant hack the damn frontpage server
if you dont have frontpage. Get it at www.microsoft.com. Now you must also
understand how to connect to a server to see if it has a password etc...
Here are the steps to do that:
1. File
2. Open frontpage web
3. More Webs
4. Put the server name in the box below where it says "Select a web server
or disk location" then click list webs
Then 1 of 2 things will happen
1. It will say there is an error 505 etc..
2. It will list some folder names in the box below "front page web servers
found at location"
3. Double click one of the folders that it lists. If the Admin is lazy or
just stupid you wont even be prompted for a password and it will list the
remote computers files which from there you can drag and drop your new
hacked page.
First thing to do is find some nt servers. Here are 2 ways:
1. Goto www.yahoo.com or whatever and search for iisadmin
2. Goto www.yahoo.com or whatever and search for _vti_bin/_vti_aut/
Whatever your pleasure they will both return NT servers running IIS and
frontpage server extensions.
Ways of getting into a frontpage server mad55 style:
1. What many people dont know is the fact that most people dont even have
passwords set on there frontpage servers. So if you are bored enough and
lame enough you can goto www.yahoo.com and pull up a list of frontpage
servers and sit there and try to connect to them with no password.
2. Try this out: http://www.victim.com/_vti_pvt/service.pwd if you are lucky
they messed up on file access rights and that will show you whats inside
sevice.pwd which is the frontpage password file. Cracking it will be
explained later.
3. This is by far the best way and the way that works most. As I said before
there is a flaw that lets you search for files on the target computer and
view them no matter what access rights you have. So if this is true why not
view the frontpage password file? We would do this as follows:
http://www.victim.com/samples/search/queryhit.htm
Then once at that page, in the search box we simply put in #filename=*.pwd
and then hit enter and it will hopefully show a list of links to .pwd files.
Save these pwd files for later cracking. Now if a sysadmin was smart they
may have re-named the password file so that it is not .pwd at all. So to
find out where they hide the real password file we must basiclly find the
shadowed password file (bit of Unix for ya). We do the same as before with
the file search flaw except for this time we search for
#filename=#haccess.ctl
Now #haccess.ctl is the file that points to the frontpage password file. The
contents of a default #haccess.ctl file are:
-FrontPage-
Options None
order deny,allow
deny from all
AuthName default_realm
AuthUserFile c:/frontpage\ webs/content/_vti_pvt/service.pwd
AuthGroupFile c:/frontpage\ webs/content/_vti_pvt/service.grp
The second to the last line is the most important. AuthUserFile = the
location of the real password file. So if it is:
AuthUserFile c:/frontpage\ webs/content/_vti_pvt/shadow.pas
We now know that the real password file is in shadow.pas so we would then do
the search file exploit and this time search for #filename=shadow.pas
A normal service.pwd (frontpage password) would look like this:
mad55:jk53kjnb43
Where mad55 is the user name and jk53kjnb43 is the encrypted password.
Those are a few ways to get the frontpage password. Now your asking how do
we decrypt it? First I told people to try l0pht crack to see if it was the same encryption but, it wasnt. It seems that the encryption for frontpage passwords is the same as a passwd
file in unix. So basically you can use any unix passwd crack to crack
frontpage passwords. I think that Microsoft must have done this
because of frontpages unix support. To get the formating right for the unix
passwd crackers you will want to take the frontpage password file
information say:
mad55:jk53kjnb43
and stick it in unix format:
mad55:jk53kjnb43:0:0:comments:/:/bin/bash
Ok so you've broke into www.victim.com and got the user and password. Now
you could be a tard and jump right into frontpage and connect and change the
page and tell everyone how kewl you are and get busted within a week or, you
could use the following techniques.
Here is the information for this example:
Server: www.victim.com
Server IP: 2.2.2.2
User: mad55
Pass: greenman
that all folks,next
mad55
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
5. Exploit in Windows NT (local)
by mad55
mad55@hotmail.com
August 24, 1998
The following describes how any normal (non-administrative) user on a
Windows NT system can
instantly gain administrative control for the entire machine by
running a simple executable program.
You need to have a machine running the retail/free build of Windows NT
4.0, 3.51, or
even Windows NT 5.0 beta -- either Workstation or Server will do.
1. Login on your NT machine: Login as any non-admin user on the
machine (even guest account
will do). You may verify that the logged in user does not possess
admin privilege at this time by trying
to run the "windisk" program from the shell. This should fail since
the user does not have admin
privilege.
2. Copy: After logging in, copy the software (sechole.exe and
admindll.dll) onto your hard disk in any
directory that allows you write and execute access.
3. Run SecHole.Exe : After running the program, your system might
become unstable or possibly
lock up.
4. Reboot the machine if necessary: You will see that the non-admin
user now belongs to the
Administrators group. This means that the user has complete admin
control over that machine -- for
instance, you will be able to run programs like "windisk", create new
users, delete existing users,
install drivers, even format hard disks.
in my opinion:
The sechole exploit is local in scope unless there is a service running
on the system which is running
under a domain account. If it can attach to a service running under a
context other than the local
system, the code could be executed as that user. It is fairly trivial
to replace the DLL which comes
with the exploit to cause it to take other actions. However,the local
user who has just become local admin can obtain the password of the
domain user for the service and
obtain the rights of that user in that manner. The lsa2-fix makes
this more difficult (though not
impossible).
Another area where sechole can be used to cause problems would be if
ordinary users were allowed
to place HTML content directly onto the web server. The #exec
directive causes a HTML page to
execute a command and direct the output to the client, and it is
enabled by default in IIS 4.0. If a
user were to place sechole.exe, the DLL and a web page which invokes
sechole onto a web server,
the IUSR_Machine account would then become admin. I would recommend
disabling this feature for
any web site directories where non-administrative users are allowed
to place files.
The following describes how any normal (non-administrative) user on a
Windows NT system can
instantly gain administrative control for the entire machine by
running a simple executable program.
Note : SecHole is downloadable at our Homepage!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
6. Dialing Out Of Unix Systems
by AcidMeister
ameister@vol.com
For a long time i have been reading man pages and text files on dialing out
of a unix system , i figured sometimes it would be damn nice, to be able to
dial out of those unix systems, that i either couldnt hack, or just those
that i can't root. So here's a couple of ways to dial out of systems.
On some systems you can type in the command 'kermit' (without the '').
If the system has this program type in dial x-xxx-xxx-xxxx you will have to
set up line speed and a bunch of other stuff, but in the end it should work.
This is proably the easiest way to dial out of a unix system. I wouldn't
recommend using this on your own ISP account, since they will discover you're
makiing those bigass long distance bill and proably boot your ass off your
ISP, and bill you for the calls you made...
Another way to dial out of a unix system is to do the following:
First of all we need to locate the L-devices file.
It should be found in the /usr/lib/uucp directory,
but in case it isn't typing:
find / -name L-devices -print
will show you where it is.
If you can't find it then don't worry as we can get
around it, only it will take a bit of trial and error.
If you found the L-devices file then we need to list
it by typing: cat L-devices
If it runs off the screen then type:
cat L-devices | more
This will page the output - space displays the next
page and return will show the next line while q quits.
This file shows us to which serial line (port) the
modems (ACU's) are connected, it also shows when they
can be called and the baud rate.
We are interested in the serial line and the baud rate.
Choose a line with your desired speed and make a note of
the serial line. The speed is shown as 2400,1200,300 etc.
and the serial line as ttynn where nn is a number.
If you couldn't find/list the L-devices file then type:
who am i
This will show which serial line you are on, and as you
are on a modem then it's a fair bet that the others are
not too far away. e.g. If you are on line tty07 then
there's a good chance of a modem being on tty06,tty08 or
thereabouts.
Now we need to make a direct connection to the modem by
typing: cu -sbaud -l/dev/ttynn dir
where baud and ttynn are your desired speed and serial
line respectively.
If you couldn't find/list the L-devices file then this is
where the trial and error I told you about comes in.
When you get it right it should come up with 'Connected'.
5. Now we are talking directly to the modem. As a precaution
at this point I suggest saving the modem's current config
by typing: AT&W
Don't worry if you can't see what you are typing as it is
probably in quiet mode with echo off.
Now restore the factory default settings by typing:
AT&F
Now you can set up the modem as you require it, just as
you would with your own and use it as normal.
When you have finished type: ATZ
to restore the modem back to it's initial state, then
type: ~.
It should come up 'Disconnected' and you should now be
back in your shell.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
7. List Of Dialup Passwords
by AcidMeister
ameister@vol.com
I am not responsible for what you do with these logins
and passwords, i simply picked these up i don't know
where they came from or whos they are, please don't
change the passwords that way we can all be safer by
using someone elses ISP account, now remember im not
telling you to use these it is against the law, and so
i cannot be held responsible for anything you might do..
Well anywayz enjoy... some of them might not work i
don't use them so i wouldnt know...
ISP LOGIN PASSWORD
www.gte.com rb4570 r4570405
www.airmail.net bdillion my1ldr
www.your.net mhoehn system
www.surfshop.com vette80 tessa
www.bellsouth.com suntrade 9311
TELUS snook snook
Florida Tech dgrandey Scar!97
Florida Tech dgrandey Acad!LVI
AOL lanejr monday
www.kih.net jkburk prince
REMEMBER ONE PERSON CAN FUCK IT UP FOR YOU ALL, SO
PLEASE DON'T CHANGE THE PASSWORDS...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
8. Some things To Do To Keep Safe Once You Get Root
by AcidMeister
ameister@vol.com
The first time I rooted a system I was pretty much
FUCKED. You see I never did pay attention to all the
text files on hiding in a unix system, until of course
after that day. Well so I had like rooted a system
finally, but the challenge in being an ethical hacker
is not just getting root it's keeping it, so heres some
hints on keeping safe when you have rooted a system.
All files I metion below this point can be found at
http://www.lordsomer.com . Once you have rooted a
system you have to get zap, this program erases your
presence in the log files, to use first compile zap.c -o
zap then to erase the log use it as follows ./zap
username thats all there is to it. Now that thats done
you will want to insure you keep root in the future.
Goto the site mentioned above and goto the place where
trojans are found get the file that puts a shell on a
port, just compile the file as above and run it, making
sure to put a ./ in front of the filename. Also a
good idea is to place + + in either roots .rhosts file,
or if you're smart, put it in every account on the
system if no .rhosts file exists then make it. This
way you can always rlogin www.victim.com -l username
and get in without a password. Yet another good idea
is to create another account, but with root priviliges
just cd /etc and vi passwd or if the system has a
shadowed password file (you should know where it is)
vi shadow. See if you can pick a place near the middle
of the password file, lets say most usernames are like
bwjensen, fbrack, tsmith, mbraun, then make up a
username such as tbraun or whatever, just use your
imagination. All you have to do is insert this this
line into the passoword file.
tbraun::0:1::/:/bin/bash
Where tbraun is the username the space following it is
the password which in this case isnt there. In this
case it will allow you to login as tbraun, once you
login just type passwd , and put in a secure passowrd.
These techniques will only be helpful to ethical hackers
, NOT CRACKERS, carckers are the people who break into
systems, delete all the files, change the root password
, they're also the people you read about in the
newspapers, so if you can't figure it out on your own
I'll tell you, crackers are the ones that always get
caught, so here's a warning, don't be an asshole and
wreck havoc, don't mess up systems, because you will
only make it worse for yourself when you finally get
caught. Instead use your knowledge to gain knowledge,
and eventually get a job thats pays $550,000 a year by
the way thats not uncommon.
CHANGE THE PASSWORDS THE ACCOUNT WONT LAST SO DON'T BE A DUMBASS, AND A LAMER...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
9. How To Hack Your School (THE BASICS)
by AcidMeister
ameister@vol.com
o.k so u want to be popular at school, or just hack your
school, for fun & profit, well you're reading the right
text file. Your school proably has a dailup to find
this dailup you will need to get a wardialer, goto
http://www.yahoo.com and search for wardialer, you need
to find out your school regular phone number lets sasy
it's 371-2694, what you would do is set the wardialer
to dail every number in that perfix so what we want to
scan is every number in the following rang 371-0000
371-9999, this method will give you a shitload of
carries (computers that are connected to a phone line)
you can do this with businies etc..... you'd be suprised
how many computers are in your little town, these
computers are also extremely easy to hack. Most will
have common logins such as login: root password: root.
Well when you found your schools dialup, you should be
able to find out which number is you schools it may even
tell u at the login like welcome to someschoolname
please login. Well this is where you try some default
logins and passwords if this dosn't work, try every
login with passwords to do with school, or even teachers
names etc.... Well thats about all i can tell you in
this text file there are other ways. But i'm not gonna
cover them here. I need suggestions about what to write
about so if you would please e-mail me some suggestions
to ameister@vol.com, also I love answering e-mails with
questions,comments,suggestions,flames, and/or
deaththerats to ameister@vol.com also for other text
files written by me and also some useful tools and
utilities visit http://www.vol.com/~ameister.
DISCLAIMER:
I'm not responsible forany trouble you get in using
this knowledge I just gave you it's for educational
purposes only thats why it's about hacking your crappy
school.
ExEcUsE ThE SpElLiNg MiStAkEs, I WrOtE ThIs In A HuRrY
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
10. Techniques to Hide One's Identity
by AcidMeister
ameister@vol.com
When the network that is now the Internet was first designed, it was assumed
that all users wanted to be found. No one had reason to hide, and it seemed
sensible that researchers should be able to locate each other. Utilities
were therefore created to facilitate such finding.
Since those early days, the rise of multiple protocols has made finding
people even more convenient. As you will see later in this chapter, the old
days demanded a high level of networking knowledge from the user. Today,
finding or identifying most individuals is trivial. Throughout this chapter,
I examine those techniques, as well as some concepts about wholesale tracing
(tracing many individuals at one time).
You may wonder why this is deemed a security issue.
In truth, it really isn't--not yet. As you read this chapter, however, you
will learn that the Internet is a powerful tool for domestic spying.
Law-enforcement and intelligence agencies already conduct such practices on
the Internet, and for them, the Network is a bonanza. No search warrant is
needed to "study" the activity of someone on the Internet. Likewise, no
warrant is needed to compile lists of individuals who law enforcement
perceive to be involved in illegal (or even seditious) activity. This is not
a joke. If you harbor radical political views, by the end of this chapter,
you may elect to forever keep those views to yourself (or gain a decent
education in cryptography).
Before I begin, I need to make one statement regarding screenshots and
diagnostic network information contained within this chapter. Certain
methods of finding individuals demand the use of search engines.
Unfortunately, to my knowledge, the law has not been adequately settled
regarding the reprinting of an individual's e-mail address without his
consent. Because of this, I cannot provide screenshots of searches because
they necessarily contain the e-mail addresses of users unknown.
Therefore, the searches have to be described rather than illustrated. I do
apologize for this. However, upon reflection, I would not want my e-mail
address published, and I see no reason why anyone else would, either. The
argument is often made that anyone who posts to a Usenet newsgroups has at
least given an implied form of consent. I do not support that view. So, I am
afraid that we shall have to get along as best we can by description as
opposed to screenshot. I have taken pains to explain each step carefully
to provide the utmost clarity. I hope that will suffice.
So, let us begin at the beginning, at the heart of your server. We will
start at home base and work our way outward.
What's in a Name?
There are two forms of user identification that apply to all platforms:
your e-mail address and your IP address. It is often theorized that if one
is obscured, the other can never be found. That is untrue. Without chaining
messages through a series of trusted anonymous remailers (remailers that are
purportedly secure), anonymity on the Internet is virtually impossible.
Anonymous remailers are discussed in Chapter 7,
"Birth of a Network: The Internet."
It is possible, however, to make yourself relatively invisible, and that is
probably what most individuals would like to do. Before I get more specific,
however, there are some utilities you need to know about, as well as methods
of tracing individuals. I'll start with finger.
finger
The finger service is a utility common to the UNIX platform. Its purpose is
to provide information about users on a given system. In practical operation,
finger works like most other services available in UNIX. Figure 13.1
demonstrates the use of Finger32, a popular finger client for the Microsoft
Windows platform.
Figure 13.1.
The finger query process.
Cross Reference: Finger32 is a small application port of the UNIX
utility finger. It is available here:
ftp://hyper.net.au/Win95nt-apps/Finger/Wsfinger/Wsfngr32.zip
The finger service relies on the client/server model, which is a recurring
theme in Internet applications. This model works as follows: machines
running server applications distribute information to clients. Clients are
programs designed to accept and interpret information from server
applications. For example, you use a Web browser (or client) to read
information forwarded by a Web server (the HTTP server).
In any event, the finger client-server relationship works as follows:
On the targeted machine (almost always a UNIX system), there is a server
running called fingerd. This is more commonly referred to as the finger
daemon. Its purpose is to answer requests from finger clients from the void.
The finger daemon can return different information, depending largely on the
configuration of the server and the user's personalized settings. For
example, sometimes an "open" UNIX server (that is, one not running a firewall)
will disallow finger access. This is done by disabling the finger daemon,
removing it from the file /etc/inetd.conf. In this case, the finger service
is never started. Any client-issued finger request forwarded to such a
machine will meet with a blank response (or perhaps, Connection Refused.).
Many organizations, particularly ISPs, government sites, and private
corporations, disable finger services. Each has an interest in preserving
the privacy of its users, and that is usually the reason given for disabling
the service. As you will learn later, however, their motivation may also be
system security.
TIP: Certain vital information about the system can be culled by
fingering system IDs such as root, bin, FTP, and so on. On that account,
some sites will disable finger services altogether. It is thought that
by killing the finger and RPC services, one can restrict the amount of
revealing information available to crackers in the void. To some
extent, this is true.
Cross Reference: An excellent paper written by Dan Farmer and
Wietse Venema addresses this issue:
"Improving the Security of Your Site by Breaking Into It." The
paper is so widely distributed on the Internet. Here is a very
reliable source:
http://www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html.
(This is a government site, so with all probability, this link will
be good for many years to come.)
Some sites do not disable finger services altogether, but instead put
restrictions on what type of information can be accessed. For example,
by default, the finger daemon allows a systemwide finger. Anyone can be
fingered, including special or privileged accounts. When systemwide fingering
is allowed, one can gather information on all users currently logged to the
machine. This is done by issuing the following command at a UNIX command
prompt:
finger @my_target_host.com
The @ symbol has essentially the same effect as the asterisk does in regular
expression searches. When it is used, the user is fingering all users
currently logged to the target machine. This is most useful when targeting
small providers that have few customers, or when conducting such a finger
query late at night. Certainly, fingering a company as large as Netcom in
this manner would be foolish. (The response forwarded by the server would
likely be many pages in length. The only valid reason for doing this would
be to generate a database of Netcom users.) At any rate, some organizations
will disallow such a request, instead forcing the requesting party to specify
a particular user.
Other sites make use of hacked finger daemons, either created in-house or
available as distributions from other sites across the Internet. These are
finger daemons that have enhanced features, including advanced configuration
options.
Cross Reference: One such hacked finger daemon is the Configurable
Finger Daemon, or cfingerd. Written by Ken Hollis, cfingerd
provides security functions not available in garden-variety finger
servers. It is considered to be an excellent replacement to the
standard distribution of finger. It is available free of charge at
ftp://ftp.bitgate.com/pub/cfingerd/.
Cross Reference: For more generalized understanding of the finger
daemon process, I suggest viewing the source for any public-domain
finger client. There is a nice online resource for this at
http://araneus.york.ac.uk/owtwaww/finger.htm.
At any rate, taking you through the process of a finger inquiry will take
just a few moments, but in order for you to exploit the example, you need
a finger client. UNIX users, however, have no need for a finger client,
because this is included in the basic distribution. The same is true of
Windows NT. So this little section is primarily for Windows, Mac, and
OS/2 users. The finger clients are listed in Table 13.1.
Table 13.1. Finger clients for non-UNIX, non-NT users.
Platform
Client
Location
Windows
(All)
WSFinger
ftp://papa.indstate.edu/winsock-l/finger/wsfngr14.zip
Macintosh
Macfinger
ftp://ftp.global.net.id/pub/mac/internet/finger-15.hqx
OS/2
FFEU
http://www.musthave.com/OS2/ftp/ffeu101.zip
For demonstration purposes, I will use Finger32, a popular finger application
for Windows 95. The application is simple to use; it presents the user with a
self-explanatory screen from which you choose your host. (See Figure 13.2.)
Figure 13.2.
The Finger32 opening screen--choosing a host.
When you choose this option, a dialog box appears, requesting a host and
username. (See Figure 13.3.)
Figure 13.3.
Specifying your target.
Providing the target is running a finger server, the return output should
read something like this:
Login name: root In real life: 0000-Admin(0000)
Directory: / Shell: /sbin/sh
Last login Tue Feb 18 19:53 on pts/22
New mail received Wed Feb 19 04:05:58 1997;
unread since Wed Feb 19 03:20:43 1997
No Plan.
This tells you several things, including the directory where root@samshack
resides (/), the shell he or she is using (/sbin/sh), and some details on
last login and mail. (Hard-core hackers will know that it also tells you
that root@samshack.com is using Solaris as an operating system. Note the
0000-Admin[0000] string.)
This information does not appear to be particularly revealing; however,
in 70% of all cases, the field In real life is filled with a name. Worse
still, at some universities, you can get the name, telephone number, dorm
room number, and major of students enrolled there (not that the major
matters particularly, but it provides some interesting background).
The information available on a finger query is controlled primarily by the
system administrator of a given site, as well as what information you provide
on your initial signup. Most new users are not aware of this and provide all
the information they can. Most people have no reason to hide, and many
provide their office telephone number or even their home address. It is
human nature to be mostly honest, especially when the entity they are
providing information to seems benign.
So the process of identification usually either starts or ends with a finger
query. As noted previously, the finger query uses your e-mail address as an
index. This leads us immediately into an area of some controversy. Some
individuals believe that by changing their e-mail address in the Netscape
Navigator or Microsoft Internet Explorer Options panels, they obscure their
identity. This is not true. It simply makes your e-mail address more
difficult to obtain. I will get to this subject momentarily. For now, I want
to continue with finger, offering a little folklore. The following is a
classic Internet story. (If you've ever fingered coke@cs.cmu.edu, skip these
next few paragraphs.)
Years ago, the computer science department staff at Carnegie-Mellon
University had a gripe about their Coke machine. Often, staffers would
venture down to the basement, only to find an empty machine. To remedy this
problem, they rigged the machine, connecting it to the Internet (apparently,
they did this by wiring the machine to a DEC 3100). They could then issue a
finger request and determine the following things:
How many sodas were in each slot
What those sodas were--Coke, Diet Coke, Sprite, and so on
Whether the available sodas were cold
Today, you can still issue a finger request to the Coke machine at CMU.
If you were to do so, you would receive output very similar to the following:
[ Forwarding coke as "coke@l.gp.cs.cmu.edu" ]
[L.GP.CS.CMU.EDU]
Login: coke Name: Drink Coke
Directory: /usr/coke Shell: /usr/local/bin/tcsh
Last login Sun Feb 16 18:17 (EST) on ttyp1 from GS84.SP.CS.CMU.EDU
Mail came on Tue Feb 18 14:25, last read on Tue Feb 18 14:25
Plan:
M & M Coke Buttons
/----\ C: CCCCCCCCCCC.............
|?????| C: CCCCCCCC.... D: CCCCCCCCCC..
|?????| C: CCCCCCCCCCCC D: CCCCCCCC....
|?????| C: CCCCCCCC.... D: CCCCCCCCC...
|?????| C: C...........
\----/ S: C...........
| Key:
| 0 = warm; 9 = 90% cold; C = cold; . = empty
| Beverages: C = Coke, D = Diet Coke, S = Sprite
| Leftmost soda/pop will be dispensed next
--^-- M&M status guessed.
Coke status heuristics fit data.
Status last updated Wed Feb 19 00:20:17 1997
As you can see, there is no end to the information available with a finger
query. The story of this Coke machine was told by Terence Parr, President
and Lead Mage of MageLang Institute (http://www.magelang.com/), at the 1996
Netscape Developer's Conference at Moscone Center in San Francisco.
Reportedly, Parr was demonstrating a Java application that could emulate
this Coke machine hack when suddenly, a former CMU student, Michael Adler,
rose to the occasion. Adler explained the hack in detail, having firsthand
knowledge of the Coke machine in question. In fact, Adler was largely
responsible for adding the temperature index function.
At any rate, many administrators insist on supporting finger, and some have
legitimate reasons. For example, a finger server allows easy distribution of
information. In order for the finger server to support this functionality,
the targeted user (or alias) must have a plan file. (The Coke machine at
CMU certainly does!) This file is discussed in the next section.
The Plan File (.plan)
On most UNIX servers, user directories are kept beneath the /home/ or /usr
directory hierarchies. For example, a user with a username of cracker will
have his home directory in /home/cracker. (This is not set in stone. System
administrators are responsible for where such directories are kept. They
could specify this location as anywhere on the drive, but the typical
placement is /usr or /home.)
Typically, in that home directory are a series of special files that are
created when the user accesses his account for the first time. For example,
the first time he utilizes the mail program Pine, a series of files are
established, including .pinerc, which is the configuration file for this mail
client.
These files are referred to as dot files, because they are preceded by a
period. Most dot files are created automatically. The .plan file, however,
is not. The user must create this file himself, using any text editor
(for example, vi or pico). This file can be closely correlated with
the plan.txt file on a VAX system. Its purpose is to print user-specified
information whenever that user becomes the target of a finger query. So,
if the user saves into the .plan file a text recounting his life history, that
text will be printed to the STDOUT of the party requesting finger information.
The .plan file is one way that information can be distributed via the finger
server. (Note that you, the user, must create that .plan file. This is not
automatically generated by anyone else.) If you examine Figure 13.1 again,
this will seem a bit clearer.
TIP: You may have encountered servers or users that suggest that you
Finger for more info. Usually, this entails issuing a finger request to
an address like info@targethost.com. Most often, the information you
receive (which could be pages of plain text) comes from the .plan file.
There are other reasons that some administrators keep the finger service
operational. Entire programs can be launched by specifying a particular
address to be fingered. In other words, one could (although it is not
recommended) distribute text files this way. For example, you could write an
event handler to trap finger queries aimed at a particular user; if user A
were fingered, the server would send a specified text file to the requesting
party. I have seen more than one server configured this way, although it is
more common to see mail lists designed in this manner.
For whatever reason, then, finger services may be running on the server at
which you have an account. If you have never bothered to check what
information is available there, you can check now by issuing a finger
request to your own account. You can also examine this information (the
majority of it, anyway) by issuing the following command at a shell prompt:
grep your_username /etc/passwd
TIP: This technique will only work on servers that use non-shadowed
password files, or those that are not employing NIS. In those
instances, you may have to issue a command more like this:
ypcat passwd || cat /etc/passwd | grep user_name
This command will print the information the server holds on you in the
/etc/passwd file. Note that this information will be visible even if the
server makes use of shadowed password entries.
So now you know: The names of the majority of Net citizens are there for
the taking. If your system administrator insists on using finger, there
are several things you can do to minimize your exposure:
Use the popular utility chfn to alter the finger information available
to outsiders
If chfn is not available, request that the sysad change your information
Cancel your current account and start a new one
NOTE: If you believe in harsh solutions and you want to discourage
people from repeatedly fingering your account, write a .plan file
that forwards a few megabytes of garbage. This is most useful if
your sysad refuses to assist, chfn is unavailable, and some joker is
trying to clock your movements using finger.
Of course, perhaps you are not concerned with being fingered as much as you
are concerned with who is doing the fingering. If so, you need MasterPlan.
MasterPlan
MasterPlan is an excellent utility. Written by Laurion Burchall and released
in August 1994, this product takes an aggressive approach to protecting your
privacy. First and foremost, MasterPlan identifies who is t
rying to finger
you. Each time a finger query is detected, MasterPlan attempts to get the
hostname and user ID of the fingering party. These variables are piped to
an outfile called finger_log. MasterPlan will also determine how often you
are fingered, so you can easily detect if someone is trying to clock you.
(Clocking refers to the practice where user A attempts to discern
the habits of user B using various network utilities, including finger and
the r commands.)
TIP: The r commands consist of a suite of network utilities that can
glean information about users on remote hosts. I will discuss one of
these, a utility called rusers, in a moment.
Typically, a cracker writes a shell or Perl script to finger (or otherwise
query) the target every specified number of minutes or hours. Reasons for
such probing can be diverse. One is to build a profile of the target; for
example, when does the user log in? How often does the user check mail? From
where does the user usually log in? From these queries, a cracker (or other
nosy party) can determine other possible points on the network where the
user can be found.
Consider this example: A cracker I know was attempting to intercept e-mail
trafficked by a nationally renowned female journalist who covers hacking
stories. This journalist had more than one account and frequently logged
into one from another. (In other words, rather than directly logging in,
she would chain her connections.) This is a common practice by individuals
in the public eye. They may want to hide from overly enthusiastic fans
(or perhaps even legitimate foes). Thus, they preserve at least one account
to receive public mail and another to receive private mail.
By running a probing script on the journalist, the cracker was able to
identify her private e-mail address. He was also able to compromise that
network and ultimately capture all the journalist's mail. The mail was
primarily discussions between the journalist and a software engineer in
England. The subject matter concerned a high-profile cracking case in the
news. (That mail was later distributed to crackers' groups across the
Internet.)
In any event, MasterPlan can help to identify these patterns, at least with
respect to finger queries. The utility is small, and easily unpacked and
configured. The C source is included, and the distribution is known to
compile cleanly on most UNIX systems. (The exceptions are reportedly Ultrix
and the NeXT platform.) One nice amenity for Linux users is that a
pre-compiled binary comes with the distribution. The standard distribution
of MasterPlan is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan.tar.Z
The Linux compiled version is available at
ftp://ftp.netspace.org/pub/Software/Unix/masterplan-linux.tar.Z
As you've now seen, the finger utility is dangerous and revealing. More and
more sites are now disabling finger services, at least with respect to
external queries. For various reasons, however, many providers simply do
not bother to shut it down.
TIP: If you want to see an example of mapping an IP address to a
username dynamically, trying fingering ppp@wizard.com. This host has
apparently aliased out the PPP connections so that the entire list of
users connected via PPP can be examined using the finger command. Thus,
if you receive a message from a user in that domain, but the user
obscured his e-mail address, it could still be culled using the finger
command. By fingering the entire block of current PPP addresses, you can
map the IP to a username and from there, finger the username. By going
through this process, you can easily obtain the e-mail address of a
user in that domain, even if he is trying to hide.
Note that MasterPlan will not prevent someone from fingering you; it will
simply identify that party and how many times the finger request has been
issued.
But all this assumes that your provider allows finger requests from the void.
Suppose for a moment that it doesn't. Does this mean that you are safe and
that you shouldn't worry about your name being revealed? Hardly. It simply
means that a standard finger query will fail to render any information about
you.
Suppose that someone is attempting to finger you and discovers that finger
requests from the void are prohibited. Suppose further that this person is
determined to find your real name and is willing to risk an angry message
from your provider to his own. In such a case, the nosy party will initiate
a Telnet session to your provider's mail server. (This is done by initiating
a Telnet request to port 25.)
In most cases (except those where the provider is paranoid or running a
firewall), a server will accept a Telnet connection to port 25 (the port
that sendmail runs on). Such a connection looks like this:
220 shell. Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997 07:17:18 -0800
TIP: The preceding piece of a started Telnet session was initiated on a
Solaris 2.5 SPARC station 20. Different flavors of UNIX will provide
different strings at the beginning of the session. However, almost all
reveal the operating system and version number.
If the nosy party can get to such a prompt, there is better than an 80
percent chance that he will have your name momentarily. The information is
collected by issuing the following command:
expn username
This command requests that the mail package expand a username into an e-mail
address and real name. This is a feature (not a bug) of the sendmail package.
The response will typically expand into something similar to
username <username@target_of_probe.com> Real Name
The first field will report back the username or user ID that you request to
be expanded. This will be followed by the person's e-mail address and finally,
his "real" name.
Note that the expn function can be disabled by the system administrator,
although few actually do it. There are reasons for this, and the most
probable is that administrators simply fear fiddling with the sendmail
configuration. Sendmail is a notoriously complex and powerful program that
has evolved into a huge package. There are so many options for it that an
entire book could be written just on its configuration. It is for this reason,
no doubt, that sendmail has consistently been the source of holes in Internet
security. So you might wonder why the program is even used at all. That is
easy to explain. Sendmail is the most successful program for transport of
electronic mail ever created. Millions of users all over the world send
mail each day using this program.
In any event, if the expn function is operable, the nosy individual will
still get your real name, if it is available. Unfortunately, even if the
expn function has been disabled, the snooping party can still verify the
existence of your account using the vrfy function. This is academic, however;
if your provider's sendmail system honors Telnet sessions, there is a
greater than 70 percent chance that one or both of these functions is
available.
TIP: You will find that many other versions of sendmail-- which has now
been ported to almost every platform-- will also render this information.
Currently, other than rewriting your account so that your real name does not
appear in the /etc/passwd database, there is no way for you to exercise
control over these remote functions. sendmail issues must be resolved by
root. Moreover, it is highly unlikely that a system administrator will
fiddle with his or her sendmail configuration just to satisfy the needs of
a paranoid user. Thus, the rule of thumb is this: If you intend to remain
untouchable on the Net, you must never, ever allow your real name to fill
that field within the /etc/passwd file.
A Few Words About Cookies
You have seen the message many times. You land on a WWW site and a dialog
box appears. The server at the other end says it wants to set a cookie.
Most users have no idea what this means, so they simply click the OK button
and continue. Other users actually read the dialog box's contents and get a
little worried. (This is especially true when the cookie is going to be set
for sometime into the year 2000. The user may not be sure what a cookie is,
but almost all users balk when that cookie is going to hang around for 3 or
4 years.)
TIP: If you have never seen such a dialog box, you need to set your
options to warn you before cookies are being set. Personally, I prefer
to at least be notified when anything is being written to my hard disk
drive. You should watch all such activities closely, monitoring any
code or other device that is arbitrarily forwarded to your machine.
What are cookies? The cookie concept is very much like getting your hand
stamped at a dance club. You can roam the club, have some drinks, dance,
and even go outside to your car for a few minutes. As long as the stamp is
on your hand, you will not have to pay again, nor will your access be
restricted. But cookies go much further than this. They record specific
information about the user, so when that user returns to the page, the
information (known as state information) can be retrieved. The issue
concerning cookies, though, isn't that the information is retrieved.
The controversy is about where the information is retrieved from: your
hard disk drive.
Cookies (which Netscape calls persistent client state HTTP cookies) are now
primarily used to store options about each user as he browses a page. The
folks at Netscape explain it this way:
This simple mechanism provides a powerful new tool which enables a host
of new types of applications to be written for Web-based environments.
Shopping applications can now store information about the currently
selected items, for fee services can send back registration information
and free the client from retyping a user-id on next connection, sites
can store per-user preferences on the client, and have the client
supply those preferences every time that site is connected to.
Cross Reference: The article from which the previous quote is excerpted,
"Persistent Client State HTTP Cookies," can be found at
http://home.netscape.com/newsref/std/cookie_spec.html.
To understand the way cookies work, please examine Figure 13.4.
Figure 13.4.
Setting cookies.
As you can see, when the remote server is contacted, it requests permission
to set a cookie. (One wonders why some sites set a cookie on their opening
page. Just what state information are they recording? You haven't specified
any preferences yet, so there is essentially nothing to record.) Prior to
the setting of the cookie, however, the user is generally confronted with
the advisory shown in Figure 13.5.
Figure 13.5.
Cookie warning!
TIP: Note that this advisory will only be shown if you choose this
option (Warn on Cookie) in your preferences. In Netscape Navigator,
this option can be toggled in the Network Preferences menu under the
Protocols tab. In Microsoft Internet Explorer, it can be set in the
Options menu under the Advanced tab.
Advocates of cookies insist that they are harmless, cannot assist in
identifying the user, and are therefore benign. That is not true, as
explained by D. Kristol and L. Montulli in RFC 2109:
An origin server could create a Set-Cookie header to track the path of
a user through the server. Users may object to this behavior as an
intrusive accumulation of information, even if their identity is not
evident.(Identity might become evident if a user subsequently fills out
a form that contains identifying information.)
I know many programmers who are exploring techniques for using cookies for
user authentication. This is disturbing. There has not been enough scrutiny
of the privacy issues surrounding cookies, and there needs to be some method
developed to manage them. That is, perhaps some cookies are desirable to a
particular user and some are not. The user may visit certain sites regularly.
If those sites use cookie conventions, the user will unnecessarily be
confronted with a cookie warning each time he visits, unless that cookie
remains on the drive. However, other cookies (from sites that the user may
never visit again) should be easily removed. This is also discussed in
RFC 2109:
User agents should allow the user to control cookie destruction. An
infrequently used cookie may function as a "preferences file" for
network applications, and a user may wish to keep it even if it is the
least-recently-used cookie. One possible implementation would be an
interface that allows the permanent storage of a cookie through a
checkbox (or, conversely, its immediate destruction).
Briefly, to find the cookies on your hard disk drive, search for the file
cookies.txt. This file will contain a list of cookies and their values.
It looks like this:
www.webspan.net FALSE /~frys FALSE 859881600 worldohackf 2.netscape.com TRUE / FALSE 946684799 NETSCAPE_ID
1000e010,107ea15f.adobe.com TRUE / FALSE 946684799 INTERSE 207.171.18.182 6852855142083822www.ictnet.com FALSE / FALSE 946684799 Apache pm3a-4326561855491810745.microsoft.com TRUE / FALSE 937422000
MC1 GUID=260218f482a111d0889e08002bb74f65.msn.com TRUE / FALSE 937396800 MC1 ID=260218f482a111d0889e08002bb74f65comsecltd.com FALSE / FALSE 1293753600 EGSOFT_ID 207.171.18.176-3577227984.29104071
.amazon.com TRUE / FALSE 858672000 session-id-time 855894626.amazon.com TRUE / FALSE 858672000 session-id 0738-6510633-772498
This cookie file is a real one, pulled from an associate's hard disk drive.
You will see that under the GUID, the leading numbers are an IP address.
(I have added a space between the IP address and the remaining portion of
the string so that you can easily identify the IP. In practice, however, the
string is unbroken.) From this, you can see clearly that setting a cookie
may involve recording IP addresses from the target. Now, this does not mean
that cookies are a major threat to your privacy. Many JavaScript scripts
(and Perl scripts) are designed to "get" your IP. This type of code also
can get your browser type, your operating system, and so forth. Following
is an example in JavaScript:
<script language=javascript>
function Get_Browser() {
var appName = navigator.appName;
var appVersion = navigator.appVersion;
document.write(appName + " " + appVersion.substring (0,appVersion.indexOf(" ")));
}
</script>
This JavaScript code will get the browser and its version. Scripts like this
are used at thousands of sites across the Internet. A very popular one is
the "Book 'em, Dan-O" script. This script (written in the Perl programming
language) will get the time, the browser, the browser's version, and the
user's IP.
Cross Reference: The "Book 'em, Dan-O" script was written by an
individual named Spider. It is currently available for download at
Matt's Script Archive, at
http://worldwidemart.com/scripts/dano.shtml.
Cross Reference: One site that will get many of your environment
variables, particularly if you use UNIX, is located at
http://hoohoo.ncsa.uiuc.edu/cgi-bin/test-env. What is interesting is
that it will catch both the PPP-based address
(as in ppp32-vn074.provider.com) as well as your actual IP.
Also, nearly all Web server packages log access anyway. For example,
NCSA HTTPD provides an access log. In it, the IP address of the requesting
party is logged. The format of the file looks like this:
- - [12/Feb/1997:17:20:59 -0800] "GET /~user/index.html i HTTP/1.0" 200 449
The major difference between these devices and the cookie implementation,
however, is that cookies are written to a file on your hard disk drive.
Many users may not be bothered by this, and in reality, there is nothing
threatening about this practice. For example, a cookie can only be read by
the server that set it. However, I do not accept cookies as a rule, no
matter how persistent the server may be at attempting to set one.
(Some programmers provide for this process on every page, hoping that
eventually the user will tire of dealing with dialog boxes and simply
allow the cookie to be set.)
It is interesting to note that some clients have not been preconfigured to
deny cookies. In these instances, a cookie may be written to the drive
without the user's consent, which is really the default configuration, even
for those browsers that support screening of cookies. Early versions of both
Netscape Navigator and Microsoft Internet Explorer shipped with the Deny
Cookies checkbox unchecked. Absentmindedness on the part of the vendors?
Perhaps. If you have a problem denying cookies, for whatever reason, there
is an action you can undertake to prevent these items from being written to
your drive. One is to make the file cookies.txt read-only. Thus, when a
foreign Web server attempts to write to the file, it will fail.
TIP: It has been reported that this can be done in MacOS by first
deleting and then re-creating the cookie file and subsequently
placing it into the Preferences folder.
I recommend denying cookies, not so much because they are an invasion,
but because they leave a trail on your own hard disk drive. That is, if you
visit a page that you have been forbidden to access and it sets a cookie,
the evidence will be in cookies.txt. This breaks down to cache issues as
well: even if your cookies file is clean, your cache will betray you.
NOTE: Although this is a well-known issue, new users may not be aware
of it, so I will explain. To retrieve the sites you have most recently
visited, type about:cache in the Open Location box in Netscape's
Navigator. A new page will appear, showing Web pages you have recently
visited. So, if you browse the Net at work when you are supposed to be
performing your duties, you will want to kill that cache every few
minutes or set its value to 0.
Currently, denying a cookie does not dramatically influence your ability to
access a page, although that may change in the future. At best, the cookie
issue has assisted in heightening public awareness that a remote Web server
can cull your IP address and, in certain instances, your location, your
operating system, your browser, and so forth.
NOTE: If you are uncomfortable with denying cookies from all sites,
perhaps you should check out a program called Cookie Jar. Cookie Jar
allows you to specify what servers you will accept cookies from. The
program was written by Eric Murray, a member of the Sams technical
editorial team. Cookie Jar is located at
http://www.lne.com/ericm/cookie_jar/. The main amenity of Cookie Jar is
convenience. Many sites require that you accept a cookie to access
certain services. Cookie Jar can perform filtering for you.
Public Postings
We will now assume that no one knows who you are. They are about to find out,
however, because you are about to post a message to a Usenet newsgroup.
From the moment you post a message to Usenet, your name and e-mail address
are fair game.
The Usenet news network is somewhat different from other forms of
communication on the Internet. For a start, it is almost entirely public,
with a very few exceptions. Moreover, many Usenet news newsgroups are
archived--that is, the articles posted to such groups are bundled and
stored for later use. I have seen archived messages ranging back to 1992,
some of which are reachable by WAIS, FTP, Telnet, and other, antiquated
interfaces.
TIP: Note that these are private archives and have nothing to do with
search engines. The big search engines generally archive Usenet
messages for a few weeks only. In contrast, private archives (maintained
by non-commercial, special interest groups), especially those that have
listservers in addition to newsgroups, may be maintained for a long,
long time.
Because these messages are kept, your e-mail address (and identity, because
your identity can be traced with it) has a shelf life. Hucksters like list
brokers routinely tap such archives, searching for leads--collections of
e-mail addresses of persons who share a particular interest, such as all
females over 40 years of age who smoke a pipe, have an eye patch, and voted
Republican in the last election. If you think that this level of refinement
is ludicrous, think again. Applying various search spiders (and a number of
personal robots), one can narrow the search to something that specific.
The first step in developing such a list is to capture e-mail addresses. To
do this, any garden-variety search engine will do, although AltaVista
(altavista.digital.com) and DejaNews (www.dejanews.com) have the most
malleable designs. Even though these engines are well known to most users,
I am providing screen captures of their top-level pages, primarily for
reference purposes as I explain Usenet snooping.
Figure 13.6.
The top-level page of AltaVista.
AltaVista is one of the most powerful search engines available on the
Internet and is provided as a public service by Digital Equipment Corporation
(DEC). It accepts various types of queries that can be directed toward WWW
pages (HTML) or Usenet postings. (The Usenet postings are archived, actually.
However, DEC reports that these are kept only for a period of "a few weeks.")
One key point about the AltaVista engine is that it was coded nicely. By
enclosing strings in quotation marks, you can force a case-sensitive, exact
regex (regular expression) match. As a result, you can isolate one page out
of millions that contains the exact string you're seeking. Similarly, you can
isolate all Usenet postings made by a particular author. By taking each of
those postings and analyzing them, you can identify that person's chief
interests. (Perhaps the person is a militia member, for example.)
The DejaNews search engine is a very specialized tool. It is solely a Usenet
robot/spider. The DejaNews archive reportedly goes back to March 1995, and
the management indicates that it is constantly trying to fill gaps and get
older articles into the database. It claims that it is working on providing
all articles posted since 1979. Figure 13.7 shows the top page of DejaNews.
Figure 13.7.
The top-level page of DejaNews.
DejaNews has some more advanced functions for indexing, as well.
For example, you can automatically build a profile on the author of a
Usenet article. (That is, the engine will produce a list of newsgroups
that the target has posted to recently.)
Defeating the archiving of your Usenet messages on both AltaVista and
DejaNews is relatively simple--for direct posting, at least. Either in
the X headers of your Usenet article or as the first line of your article,
issue the following string:
x-no-archive: yes
This will ensure that your direct postings made to Usenet will not be
archived. This does not, however, protect you from third-party postings
that contain your e-mail address. For example, if you belong to a mailing
list and that list is archived somewhere on the WWW (or even at FTP sites),
your e-mail address is already compromised. If your e-mail address appears
in a thread of significant interest (and your reply was sufficiently
enlightening), it is guaranteed that the entire thread (which contains your
address) will be posted somewhere. And it will be somewhere other than Usenet;
perhaps a WWW page or a Gopher server.
Let us continue to suppose that you have no knowledge of how Usenet indexing
works. Let us further assume that although your real name does not appear on
Usenet postings, it does appear in the /etc/passwd file on the UNIX server
that you use as a gateway to the Internet. Now you are a viable target. Here
are some steps that will lead the snooping party not simply to your real name,
but to the front door of your home. The steps are as follows:
1. The snooping party sees your post to Usenet. Your e-mail address
is in plain view, but your name is not.
2. The snooping party tries to finger your address, but as it happens,
your provider prohibits finger requests from the void.
3. The snooping party Telnets to port 25 of your server. There, he
issues the expn command and obtains your real name.
Having gotten that information, the snooping party next needs to find the
state in which you currently reside. For this, he turns to the WHOIS service.
The WHOIS Service
The WHOIS service (centrally located at rs.internic.net) contains the domain
registration records of all Internet sites. This registration database
contains detailed information on each Internet site, including domain name
server addresses, technical contacts, the telephone number, and the address.
Here is a WHOIS request result on the provider Netcom, a popular Northern
California Internet service provider:
NETCOM On-Line Communication Services, Inc (NETCOM-DOM)
3031 Tisch Way, Lobby Level
San Jose, California 95128
US
Domain Name: NETCOM.COM
Administrative Contact:
NETCOM Network Management (NETCOM-NM) dns-mgr@NETCOM.COM
(408) 983-5970
Technical Contact, Zone Contact:
NETCOM DNS Administration (NETCOM-DNS) dns-tech@NETCOM.COM
(408) 983-5970
Record last updated on 03-Jan-97.
Record created on 01-Feb-91.
Domain servers in listed order:
NETCOMSV.NETCOM.COM 192.100.81.101
NS.NETCOM.COM 192.100.81.105
AS3.NETCOM.COM 199.183.9.4
Here, the snooping party has discovered that the provider is in the state
of California. (Note the location at the top of the WHOIS return listing,
as well as the telephone points of contact for the technical personnel.)
This information will help tremendously; the snooping party now proceeds
to http://www.worldpages.com/. WorldPages is a massive database with a
design very similar to the average White Pages. It holds the names, e-mail
addresses, and telephone numbers of several million Internet users.
(See Figure 13.8 for a screenshot of the top-level page of WorldPages.)
Figure 13.8.
The top-level page of WorldPages.
At WorldPages, the snooping party funnels your real name through a search
engine, specifying the state as California. Momentarily, he is confronted
with a list of matches that provide name, address, and telephone number.
Here, he may run into some trouble, depending on how common your name is.
If your name is John Smith, the snooping party will have to do further
research. However, let us assume that your name is not John Smith. Let's
assume that your name is common, but not that common. So the snooping party
uncovers three addresses, each in a different California city: One is in
Sacramento, one is in Los Angeles, and one is in San Diego. How does he
determine which one is really you? He proceeds to the host utility.
The host utility (discussed briefly in Chapter 9, "Scanners") will list all
the machines on a given network and their relative locations. With large
networks, it is common for a provider to have machines sprinkled at various
locations throughout a state. The host command can identify which workstations
are located where. In other words, it is generally trivial to obtain a listing
of workstations by city. These workstations are sometimes even named for the
cities in which they are deposited. Therefore, you may see an entry such as
chatsworth1.target_provider.com
Chatsworth is a city in southern California. From this entry, we can assume
that chatsworth1.target_provider.com is located within the city of Chatsworth.
What remains for the snooper is to reexamine your Usenet post.
By examining the source code of your Usenet post, he can view the path the
message took. That path will look something like this:
news2.cais.com!in1.nntp.cais.net!feed1.news.erols.com!howland.erols.net! Âix.netcom.com!news
By examining this path, the snooping party can determine which server was
used to post the article. This information is then coupled with the value
for the NNTP posting host:
grc-ny4-20.ix.netcom.com
The snooping party extracts the name of the posting server (the first entry
along the path). This is almost always expressed in its name state and not
by its IP address. For the snooping party to complete the process, however,
the IP address is needed. Therefore, he next Telnets to the posting host.
When the Telnet session is initiated, the hard, numeric IP is retrieved
from DNS and printed to STDOUT. The snooping party now has the IP address
of the machine that accepted the original posting. This IP address is then
run against the outfile obtained by the host query. This operation reveals
the city in which the machine resides.
TIP: If this information does not exactly match, the snooping party can
employ other methods to get the location of the posting machine. One
such technique is to issue a Traceroute request. When tracing the route
to a machine that exists in another city, the route must invariably take
a path through certain gateways. These are main switching points through
which all traffic passes when going in or out of a city. Usually, these
are high-level points, operated by telecommunication companies like MCI,
Sprint, and so forth. Most have city names within their address.
Bloomington and Los Angeles are two well-known points. Thus, even if
the reconciliation of the posting machine's name fails against the host
outfile, a Traceroute will reveal the approximate location of the
machine.
Having obtained this information (and having now differentiated you from the
other names), he returns to WorldPages and chooses your name. Within seconds,
a graphical map of your neighborhood appears. The exact location of your home
is marked on the map by a circle. The snooping party now knows exactly where
you live and how to get there. From this point, he can begin to gather more
interesting information about you. For example:
The snooping party can determine your status as a registered voter and
your political affiliations. He obtains this information at
http://www.wdia.com/lycos/voter-records.htm.
From federal election records online, he can determine which
candidates you support and how much you have contributed. He gets
this information from
http://www.tray.com/fecinfo/zip.htm.
He can also get your Social Security number and date of birth. This
information is available at
http://kadima.com/.
Many users are not bothered by this. Among those people, the prevailing
attitude is that all such information is available through sources other
than the Internet. The problem is that the Internet brings these sources of
information together. Integration of such information allows this activity
to be conducted on a wholesale basis, and that's where the trouble begins.
It is now possible (using the techniques described here) to build models of
human networks--that is, it is now possible to identify all members of a
particular class. It is also possible to analyze the relationships between
them. This changes the perspective for intelligence agencies.
Years ago, gathering domestic intelligence was a laborious process. It
required some element, however slim, of human intelligence. (Human
intelligence here refers to the use of human beings to gather information
as opposed to machines or other, automated processes.) Thus, to get the
low-down on the Students for a Democratic Society, for example, intelligence
agencies had to send agents on foot. These agents had to mix with the crowd,
record license plate numbers, or gather names at a rally. Today, those
methods are no longer necessary.
Today, the Internet provides a superb tool to monitor the public sentiment
(and perhaps to identify those who conspire to take up arms). In some
respects, one might concede that this is good. Certainly, if individuals
are discussing violence or crime, and they contemplate these issues online,
it seems suitable that law-enforcement agencies can take advantage of this
emerging technology. However, it should be recognized here that the practice
of building models of human networks via the Internet violates no law. It
amounts to free spying, without a warrant. Put more bluntly, we Americans
do often have big mouths. Some of us would do better to keep quiet.
Before I continue, I want to make one point clear: Complete anonymity on the
Internet is possible, but not legally. Given enough time, for example,
authorities could trace a message posted via anonymous remailer (although,
if that message were chained through several remailers, the task would be
far more complex). The problem is in the design of the Internet itself. As
Ralf Hauser and Gene Tsudik note in their article "On Shopping Incognito":
From the outset the nature of current network protocols and applications
runs counter to privacy. The vast majority have one thing in common:
they faithfully communicate end-point identification information.
`End-point' in this context can denote a user (with a unique ID), a
network address or an organization name. For example, electronic mail
routinely communicates sender's address in the header. File transfer
(e.g., FTP), remote login (e.g. Telnet), and hypertext browsers
(e.g. WWW) expose addresses, host names and IDs of their users.
Indeed, the process starts at the very moment of connection. For example,
workstations connected to a network that is directly wired to the Net all
have permanent addressing schemes. Certainly, an Ethernet spoof will not
carry when crossing the bridge to IP; therefore, fixed stations permanently
strung to the Internet will always have the same IP. And, short of the
operator of such a workstation getting root access (and altering the
routing tables), there is little that can be done in this regard.
Similarly, the average user's IP is dependent solely upon his server.
Consider the exchange that occurs in a dial-up account. (See Figure 13.9.)
Figure 13.9.
A little case study: dynamic IP allocation.
Most servers are now running some form of dynamic IP allocation. This is a
very simple but innovative system. Examine the Ethernet arrangement to the
right of Figure 13.9 (a garden-variety rack of headless workstations).
Each machine on that network can allocate a certain number of IP addresses.
Let's make it simple and say that each workstation can allocate 254 of them.
Think of each address as a spoke in a bicycle wheel. Let's also assume that
the IP address for one of these boxes is 199.171.180.2 (this is an imaginary
address). If no one is logged on, we say that the available addresses (on
that box) range from 199.171.180.3 to 199.171.180.255.
As long as only a portion of these address are occupied, additional addresses
will be allocated. However, what if they are all allocated? In that case, the
first one to be disengaged will be the next available IP. That is, suppose
they are all allocated and you currently occupy 199.171.180.210. As soon as
you disconnect (and if no one else does before the next call), the very next
customer will be allocated the address 199.171.180.210. It is a free slot
(left free because you have disconnected), and the next caller grabs it.
The spokes of the wheel are again fully occupied.
TIP: In practice, the process is more complex, involving more hardware
and so forth. However, here we are just concerned with the address
allocation, so I have greatly simplified the process.
This demonstrates that in dynamic IP allocation, you will likely have a
different address each time you connect. Many individuals who run illegal
BBS systems on the Internet take advantage of this phenomenon.
NOTE: The term illegal here refers to those BBS systems that distribute
unlawful software. This does not have to be warez (pirated software)
either. Certain types of cellular cloning software, for example, are
unlawful to possess. Distribution of such software will bring the
authorities to your door. Likewise, "illegal" BBS activity can be where
the operator and members engage in cracking while logged on. Lastly,
those BBS systems that distribute child pornography are, quite
obviously, illegal.
The dynamic allocation allows users to perform a little parlor trick of sorts.
Because the IP is different each time, an illegal BBS can be a moving target.
That is, even if law-enforcement officials suspect the activity being
undertaken, they are not sure where it is happening without further research.
Typically, this type of setup involves the perpetrators using a networked
operating system (almost always Linux or FreeBSD) that allows remote logins.
(These logins may include FTP, Telnet, Gopher, and so on. It is also fairly
common to see at least sparse HTTP activity, although it is almost always
protected using htpasswd.) It is also common for the operator of such a
board to request that users use SSH, S/Key, or some other, secure
remote-login software so that third parties cannot snoop the activity there.
Typically, the operator connects using the networked operating system and,
after having determined the IP for the night, he mails out the network
address to the members of the group. (This is usually an automated process,
run through a Perl script or some other shell language.) The mailed message
need be no more than a blank one, because all that is important is the source
address.
For the brief period that this BBS is connected, it effectively serves as a
shadowed server in the void. No one would know of its existence unless they
scanned for it. Most often, the operator will kill both finger and the r
services, therefore blocking the prying eyes of third parties from determining
who is logged to the server. Moreover, the operator has usually gained some
privileged access to his provider's network and, having done so, can obscure
his presence in system logs.
For the individuals in these groups, relative anonymity is realized because,
even if an outside party later questions the sysad of the provider, the logs
may be very sparse. Most system administrators are reluctant to kill an
account without adequate proof. True, the logs at any outside network would
show some activity and the IP it originated from, but that is not enough.
If the system administrator cannot say with certainty who perpetrated the
activity, he has no case. Meanwhile, during the period when users are
logged in to this hidden server, they, at least, are shielded in terms of
identity. They can then Telnet back out of that machine (or connect to IRC)
and from there, they have some level of shielding. But what about the
average Joe?
The average user does not implement such schemes. He connects using mostly
client software, on the IBM or Mac platform, and is not looking to provide
services. The difference is considerable. Certainly, anyone using the
configuration described here has more options with regard to sending, say,
fakemail. Because that person controls the server (and the sendmail
application is local), even a simple message sent from the console will
appear differently from one sent from a Windows client. Such a message
cannot be trusted, and only by reviewing the full headers can you
reliably determine where it came from.
TIP: You will recall that in Chapter 9, I discussed this point.
The technique for identifying the source of fakemail involves using
Traceroute. Generally, the second-to-last listing in the Traceroute
results will reveal the actual source. In other words, the
second-to-last line will reveal the provider network, and from that you
can deduce that the user was at least temporarily connected to that
server. A discussion with the sysad at that location should give you
the username--providing, of course, that you can convince the sysad
that there is a reason for him to release such information.
My point is this: During the period when a shadowed server is up, those who
log in from the void are safe and hidden, but only as long as the operator
of the box refuses to provide their identities.
For example, say a kid establishes such a box in California. His friends
from Philadelphia connect to the box and use it as a launching pad. From
there, the folks from Philadelphia Telnet back out and begin cracking some
server in the void. Our boy in California may later have to answer for this
activity. However, if he has erased his logs (and keeps his mouth shut), the
people from Philadelphia will never be found. Which leads to this advice: If
you run such a server, never, ever allow individuals you do not know to use
it. When you destroy the logs, you are sealing your own fate. These
individuals are using an IP address that can be traced to you (unless you
have root access on your provider's box). Thus, if you meet someone on IRC
and he begs you for a shell account, it is best that you refuse until you
know him. Otherwise, it is you and not he who will suffer.
At any rate, because of the inherent design of the Internet, the IP address
is a universal identification index. It has to be, because without it, how
could information be routed across the network? Therefore, be advised that
although you may change your mail address in Netscape Navigator or other
programs containing mail packages, this does not obscure your identity.
True, inexperienced users will be dumbfounded as to the origin of the
message, but anyone familiar with UNIX can trace the message right to its
source.
I imagine that the majority of my readers are not criminals and simply want
to keep their name out of Usenet screens or mailing lists. However, for
those inclined to break the law (who are scouring this chapter for that one,
single answer), I say this: To totally shield yourself from the law (and
other, interested parties), you will need these items:
A cloned cellular telephone or other means of initiating a digital
connection (seizing a circuit, perhaps)
A laptop (loaded with either FreeBSD or Linux)
Credit card numbers stolen from a clean source
A PCICMA modem
A reason for all this
Certain individuals are available for hire to perform various crimes over
the Internet. When they conduct their activity, this is how they do it. The
credit card numbers are usually bought outright from an underground, or a
"clean," source; one that law enforcement can neither readily identify or
reach. Most of these are on microfiche, taken from a financial institution
or other source that has a quantity of numbers. (Note that only those
individuals who are doing high-volume work will buy microfiche. This is
because using microfiche-based numbers is in itself a risk. Later analysis
by law enforcement will reveal that sets of numbers used may have or appear
to have originated from the same source.)
Those involved in this activity generally explain that banks are poor sources
for the numbers, as are Internet service providers, car rental agencies, and
retail chains. It is argued that the best source is from mail-order lists or
department store databases. These are the reasons:
These lists contain many different types of credit cards, not just one.
These card numbers belong to accounts that are underwritten by many
institutions, not just one.
The rightful owners of such credit cards live at locations sprinkled
throughout the United States; therefore, the activity initially
appears to be unconnected.
Law-enforcement agents will initially be dumbfounded as to the seed
source of the numbers, for all these reasons.
Having obtained the numbers, the next step is to choose a provider. Most
individuals who do this on a regular basis have lists of providers that
allow "instant access," where you provide your vitals, your credit card,
your desired login, your password, and so forth. Within minutes, you are
surfing the Net.
Using this technique, you can reliably obtain total anonymity for short
periods of time, periods long enough to perform the desired task. The only
hope that authorities have of catching you is to elicit corroborative
testimony of a coconspirator, or if you establish a pattern of activity
--for example, if spend your nights breaking into machines owned or operated
by security specialists who are also talented hackers.
NOTE: I have not suggested here that any reader undertake the action
described here. If you do so, you do it at your own peril. These
actions amount to crime--or, in fact, a series of crimes. Here, I
have merely explained one technique, and no more. Neither I nor Sams
Publishing advocate, support, or condone such activity.
For my more law-abiding readers (the majority, I hope), there are varying
degrees of anonymity that can be obtained. It depends upon why you want to
hide and the sensitivity of the data you are trafficking. It has been
recognized that there are plenty of legitimate reasons for allowing anonymity
on the Internet. The following is excerpted from "Anonymity for Fun and
Deception: The Other Side of `Community'" by Richard Seltzer: Some
communities require anonymity for them to be effective, because without it
members would not participate. This the case with Alcoholics Anonymous, AIDS
support groups, drug addiction support and other mutual help organizations,
particularly when there is some risk of social ostracism or even legal
consequences should the identity of the members be revealed.
Cross Reference: "Anonymity for Fun and Deception: The Other Side of
`Community'" by Richard Seltzer can be found on the Web at
http://www.samizdat.com/anon.html.
This is a recurring theme in the now-heated battle over Internet anonymity.
Even many members of the "establishment" recognize that anonymity is an
important element that may preserve free speech on the Internet--not just
here, but abroad. This issue has received increased attention in legal
circles. An excellent paper on the subject was written by A. Michael Froomkin,
a lawyer and prominent professor. In "Anonymity and Its Enmities," Froomkin
writes
Persons who wish to criticize a repressive government or foment a
revolution against it may find remailers invaluable. Indeed, given the
ability to broadcast messages widely using the Internet, anonymous
e-mail may become the modern replacement of the anonymous handbill.
Other examples include corporate whistle-blowers, people criticizing a
religious cult or other movement from which they might fear retaliation,
and persons posting requests for information to a public bulletin board
about matters too personal to discuss if there were any chance that
the message might be traced back to its origin.
Cross Reference: "Anonymity and Its Enmities" by Professor Froomkin is
an excellent source for links to legal analysis of Internet anonymity.
Especially for journalists, the paper is an incredible resource. It can
be found on the Web at
http://warthog.cc.wm.edu/law/publications/jol/froomkin.html.
However, not everyone feels that anonymity is a good thing. Some people
believe that if anonymity is available on the Internet, it amounts to
nothing but anarchy. Here is a rather ironic quote, considering the source
is Computer Anarchy: A Plea for Internet Laws to Protect the Innocent by
Martha Seigel:
People need safety and order in cyberspace just as they do in their
homes and on the streets. The current state of the Internet makes it
abundantly clear that general anarchy isn't working. If recognized
governments don't find a way to bring order to the growing and changing
Internet, chaos may soon dictate that the party is over.
You may or may not know why this quote is so incredibly ironic. The author,
Martha Seigel, is no stranger to "computer anarchy." In her time, she has
been placed on the Internet Blacklist of Advertisers for violating network
policies against spamming the Usenet news network. The following is quoted
from the docket listing on that blacklist in regards to Cantor & Seigel,
Ms. Seigel's law firm:
The famous greencard lawyers. In 1994, they repeatedly sent out a
message offering their services in helping to enter the U.S. greencard
lottery to almost all Usenet newsgroups. (Note in passing: they charged
$100 for their service, while participating in the greencard lottery is
free and consists merely of sending a letter with your personal
information at the right time to the right place.) When the incoming
mail bombs forced their access provider to terminate their account,
they threatened to sue him until he finally agreed to forward all
responses to them.
Cross Reference: The Internet Blacklist can be found on the Web at
http://www.cco.caltech.edu/~cbrown/BL/.
I should mention here that Cantor and Seigel are the authors of How To Make
A Fortune On The Information Superhighway (HarperCollins, 1994). For
Internet marketers, this book is purportedly a must-read.
I also understand that a new book by Seigel, How to Make a Fortune on the
Internet (HarperCollins), is forthcoming.
However, all this may be academic. As we move toward a cashless society,
anonymity may be built into the process. In this respect, at least, list
brokers (and other unsavory information collectors) had better do all their
collecting now. Analysis of consumer buying habits will likely become a
thing of the past, at least with relation to the Internet. The majority of
electronic payment services being developed (or already available) on the
Internet include anonymity as an inherent part of their design.
Cross Reference: Dan Fandrich, a prominent programmer and computer
enthusiast in British Columbia, has compiled a comprehensive list of
such systems. That list is located at
http://vanbc.wimsey.com/~danf/emoney-anon.html
Of the systems Fandrich researched, here are a few:
DigiCash
Café
CyberCash
NetBank/NetCash
First Virtual
Fandrich's research demonstrates a few significant points. Some systems
claim to offer "total" anonymity, but they really don't. He observes, for
example, that many systems keep logs of the activity. This represents one
important issue. While individuals are concerned with their privacy, and
banks would like to ensure that privacy, some medium must be reached.
Because if there is total anonymity, how can crimes be adequately
investigated? Certainly, new fraud schemes will arise as a result of these
new technologies. For example, a technique is already known for defeating the
security of smartcards. (I will not be printing that here, I'm afraid.)
In short, complete anonymity on the Internet is becoming less and less easy
to lawfully obtain. However, advanced research in the area of anonymous
payment schemes will probably turn that around dramatically in the next
five years. For, while government agencies are circumspect about Internet
anonymity, the coming age of Internet commerce almost demands it. That is
where the research is going at the moment, and there is no indication of
that trend changing in the near future.
Summary
This chapter discusses a variety of ways you can conceal your identity,
including using utilities such as finger, the r commands, and Master Plan.
The issue of cookies is addressed. Finally, the issue of
anonymity is discussed as it relates to Usenet postings and the WHOIS
service.
Resources
Privacy & Anonymity on the Internet FAQ. L. Detweiler. Many sources on
privacy and anonymity on the Internet. A must for users new to identity
issues on the Net.
http://www.prz.tu-berlin.de/~derek/internet/sources/privacy.faq.02.html
Anonymous Remailer FAQ. Andre Bacard. A not-too-technical description
of anon remailers, how they work, and where they can be found.
http://www.well.com/user/abacard/remail.html
Note: Bacard is also the author of Computer Privacy Handbook
("The Scariest Computer Book of the Year").
The Anonymous Remailer List. Raph Levien. Locations of anonymous remailers
on the Internet.
http://www.cs.berkeley.edu/~raph/remailer-list.html
How-To Chain Remailers. Alex de Joode. A no-nonsense tutorial on how to
chain remailers and, in doing so, send a totally anonymous message.
http://www.replay.com/remailer/chain.html
Privacy on the Internet. David M. Goldschlag, Michael G. Reed, and
Paul F. Syverson: Naval Research Laboratory Center For High Assurance
Computer Systems. A good primer that covers all the aspects discussed
in this chapter.
http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/inet97/index.htm
Anonymous Connections and Onion Routing. David M. Goldschlag, Michael G. Reed
and Paul F. Syverson: Naval Research Laboratory Center For High Assurance
Computer Systems. PostScript. Presented in the Proceedings of the Symposium
on Security and Privacy in Oakland, Calif., May 1997. A quite detailed
analysis of anonymous connections and their resistance to tracing and
traffic analysis. (Also discusses vulnerabilities of such systems. A must
read.)
http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/OAKLAND_97.ps
Special Report: Privacy in the Digital Age. Susan Stellin. CNET article
containing resources on privacy on the Internet.
http://www.cnet.com/Content/Features/Dlife/Privacy/
The Electronic Frontier Foundation. Comprehensive sources on electronic
privacy.
http://www.eff.org/
The Electronic Privacy Information Center (EPIC). Civil liberties issues.
This site is indispensable in getting legal information on privacy and
anonymity on the Internet and elsewhere.
http://epic.org/
Computer Professionals for Social Responsibility--CPSR. A group devoted to
discussion about ethics in computer use.
http://snyside.sunnyside.com/home/
The Anonymizer. A site that offers free anonymous surfing. The application
acts as a middleman between you and the sites you surf. Basically, it is a
more complex proxying service. It allows chaining as well, and your IP is
stripped from their logs.
http://www.anonymizer.com/
Articles and Papers
On Shopping Incognito. R. Hauser and G. Tsudik. Second USENIX Workshop on
Electronic Commerce, November 1996.
http://www.isi.edu/~gts/paps/hats96.ps.gz
The Anonymous E-mail Conversation. Ceki Gulcu. Technical Report, Eurecom
Institute. June 1995.
Control of Information Distribution and Access. Ralf C. Hauser. Technical
Report, Department of Computer Science, University of Zurich. September 1995.
Internet Privacy Enhanced Mail. Stephen T. Kent. Communications of the ACM,
vol.36 no.8, August 1993.
Certified Electronic Mail. Alireza Bahreman, J. D. Tygar. 1994.
ftp://ftp.cert.dfn.de/pub/pem/docs/CEM.ps.gz
E-Mail Security. Dr. John A. Line. UKERNA Computer Security Workshop,
November 15-16, 1994.
ftp://ftp.cert.dfn.de/pub/pem/docs/UKERNA-email-security.ps.gz
Anonymous Internet Mercantile Protocol. David M. Kristol, Steven H. Low, and
Nicholas F. Maxemchuk. 1994.
http://julmara.ce.chalmers.se/Security/accinet.ps.gz
Anonymous Credit Cards. Steven Low and Nicholas F. Maxemchuk and
Sanjoy Paul. 1994.
http://julmara.ce.chalmers.se/Security/anoncc.ps.gz
NetCash: A Design for Practical Electronic Currency on the Internet.
Gennady Medvinsky and B. Clifford Neuman. 1993.
http://julmara.ce.chalmers.se/Security/netcash2.ps.gz
Electronic Fingerprints: Computer Evidence Comes of Age. Anderson, M.R.,
Government Technology Magazine, November 1996.
Achieving Electronic Privacy. David Chaum. Scientific American, pp. 96-101,
August 1992.
Erased Files Often Aren't. Anderson, M.R., Government Technology Magazine,
January 1997.
FBI Seeks Right to Tap All Net Services. Betts, M. ComputerWorld, Vol. XXVI,
No. 23, June 8, 1992.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
11. Trojans
by AcidMeister
ameister@vol.com
August 24, 1998
Trojans are one of the more insidious devices used to circumvent Internet
security: the trojan horse, or trojan. No other device is more likely to
lead to total compromise of a system, and no other device is more difficult
to detect.
What Is a Trojan?
Before I start, I want to offer a definition of what a trojan is because
these devices are often confused with other malicious code. A trojan horse
is
An unauthorized program contained within a legitimate program. This
unauthorized program performs functions unknown (and probably unwanted)
by the user.
A legitimate program that has been altered by the placement of
unauthorized code within it; this code performs functions unknown
(and probably unwanted) by the user.
Any program that appears to perform a desirable and necessary function
but that (because of unauthorized code within it that is unknown to the
user) performs functions unknown (and probably unwanted) by the user.
The unauthorized functions that the trojan performs may sometimes qualify it
as another type of malicious device as well. For example, certain viruses fit
into this category. Such a virus can be concealed within an otherwise useful
program. When this occurs, the program can be correctly referred to as both
a trojan and a virus. The file that harbors such a trojan/virus has
effectively been trojaned. Thus, the term trojan is sometimes used as a
verb, as in "He is about to trojan that file."
Classic Internet security documents define the term in various ways. Perhaps
the most well known (and oddly, the most liberal) is the definition given in
RFC 1244, the Site Security Handbook:
A trojan horse program can be a program that does something useful, or
merely something interesting. It always does something unexpected, like
steal passwords or copy files without your knowledge.
Another definition that seems quite suitable is that given
by Dr. Alan Solomon, an internationally renowned virus specialist, in his
work titled All About Viruses:
A trojan is a program that does something more than the user was
expecting, and that extra function is damaging. This leads to a
problem in detecting trojans. Suppose I wrote a program that could
infallibly detect whether another program formatted the hard disk.
Then, can it say that this program is a trojan? Obviously not if the
other program was supposed to format the hard disk (like Format does,
for example), then it is not a trojan. But if the user was not expecting
the format, then it is a trojan. The problem is to compare what the
program does with the user's expectations. You cannot determine the
user's expectations for a program.
Cross Reference: All About Viruses by Dr. Alan Solomon can be found at
http://www.drsolomon.com/vircen/allabout.html.
Anyone concerned with viruses (or who just wants to know more about
virus technology) should visit Dr. Solomon's site at
http://www.drsolomon.com/.
At day's end, you can classify a trojan as this: any program that performs a
hidden and unwanted function. This may come in any form. It might be a
utility that purports to index file directories or one that unlocks
registration codes on software. It might be a word processor or a network
utility. In short, a trojan could be anything (and could be found in
anything) that you or your users introduce to the system.
Where Do Trojans Come From?
Trojans are created strictly by programmers. One does not get a trojan
through any means other than by accepting a trojaned file that was prepared
by a programmer. True, it might be possible for a thousand monkeys typing
24 hours a day to ultimately create a trojan, but the statistical probability
of this is negligible. Thus, a trojan begins with human intent or mens rea.
Somewhere on this planet, a programmer is creating a trojan right now. That
programmer knows exactly what he or she is doing, and his or her intentions
are malefic (or at least, not altruistic).
The trojan author has an agenda. That agenda could be almost anything, but
in the context of Internet security, a trojan will do one of two things:
Perform some function that either reveals to the programmer vital and
privileged information about a system or compromises that system.
Conceal some function that either reveals to the programmer vital and
privileged information about a system or compromises that system.
Some trojans do both. Additionally, there is another class of trojan that
causes damage to the target (for example, one that encrypts or reformats
your hard disk drive). So trojans may perform various intelligence tasks
(penetrative or collective) or tasks that amount to sabotage.
One example that satisfies the sabotage-tool criteria is the PC CYBORG
trojan horse. As explained in a December 19, 1989 CIAC bulletin
("Information about the PC CYBORG (AIDS) Trojan Horse"):
There recently has been considerable attention in the news media about
a new trojan horse which advertises that it provides information on the
AIDS virus to users of IBM PC computers and PC clones. Once it enters a
system, the trojan horse replaces AUTOEXEC.BAT, and may count the number
of times the infected system has booted until a criterion number
(90)
is reached. At this point PC CYBORG hides directories, and scrambles
(encrypts) the names of all files on drive C:. There exists more than
one version of this trojan horse, and at least one version does not
wait to damage drive C:, but will hide directories and scramble file
names on the first boot after the trojan horse is installed.
Cross Reference: You can find the CIAC bulletin "Information about
the PC CYBORG (AIDS) Trojan Horse" at
http://www.sevenlocks.com/CIACA-10.htm.
Another example (one that caused fairly widespread havoc) is the AOLGOLD
trojan horse. This was distributed primarily over the Usenet network and
through e-mail. The program was purported to be an enhanced package for
accessing America Online (AOL). The distribution consisted of a single,
archived file. Unzipping the archive revealed two files, one of which was
a standard INSTALL.BAT file. Executing the INSTALL.BAT file resulted in 18
files being expanded to the hard disk. As reported in a security advisory
("Information on the AOLGOLD Trojan Program") dated Sunday, February 16, 1997:
The trojan program is started by running the INSTALL.BAT file.
The INSTALL.BAT file is a simple batch file that renames the
VIDEO.DRV file to VIRUS.BAT and then runs it. VIDEO.DRV is an
amateurish DOS batch file that starts deleting the contents of several
critical directories on your C: drive, including
c:\
c:\dos
c:\windows
c:\windows\system
c:\qemm
c:\stacker
c:\norton
When the batch file completes, it prints a crude message on the
screen and attempts to run a program named DOOMDAY.EXE. Bugs in the
batch file prevent the DOOMDAY.EXE program from running. Other bugs
in the file cause it to delete itself if it is run from any drive but
the C: drive. The programming style and bugs in the batch file
indicates that the trojan writer appears to have little programming
experience.
Cross Reference: You can find the security advisory titled
"Information on the AOLGOLD Trojan Program" at
http://www.emergency.com/aolgold.htm.
These trojans were clearly the work of amateur programmers: kids who had no
more complex an agenda than causing trouble. These were both destructive
trojans and performed no sophisticated collective or penetrative functions.
Such trojans are often seen, and usually surface, on the Usenet news network.
However, trojans (at least in the UNIX world) have been planted by
individuals that are also involved in the legitimate development of a
system. These are inside jobs, where someone at a development firm inserts
the unauthorized code into an application or utility (or, in rare instances,
the core of the operating system itself). These can be far more dangerous for
a number of reasons:
These trojans are not destructive (they collect intelligence on systems);
their discovery is usually delayed until they are revealed by accident.
Because most servers that matter run UNIX, some highly trusted (and
sensitive) sites can be compromised. By servers that matter, I mean
those that provide hundreds or even thousands of users access to the
Internet and other key networks within the Internet. These are generally
governmental or educational sites, which differ from sites maintained,
for example, by a single company. With a single company, the damage can
generally travel only so far, placing the company and all its users at
risk. This is a serious issue, to be sure, but is relevant only to that
company. In contrast, the compromise of government or educational sites
can place thousands of computers at risk.
There are also instances where key UNIX utilities are compromised (and
trojaned) by programmers who have nothing to do with the development of the
legitimate program. This has happened many times and, on more than one
occasion, has involved security-related programs. For example, following the
release of SATAN, a trojan found its way into the SATAN 1.0 distribution for
Linux.
NOTE: This distribution was not the work of Farmer or Venema. Instead,
it was a precompiled set of binaries intended solely for Linux users,
compiled at Temple University. Moreover, the trojan was confined to a
single release, that being 1.0.
Reportedly, the file affected was a program called fping. The story goes as
follows: A programmer obtained physical access to a machine housing the
program. He modified the main() function and altered the fping file so
that when users ran SATAN, a special entry would be placed in their
/etc/passwd file. This special entry was the addition of a user named suser.
Through this user ID, the perpetrator hoped to compromise many hosts. As it
happened, only two recorded instances of such compromise emerged. Flatly
stated, the programming was of poor quality. For example, the trojan
provided no contingency for those systems that made use of shadowed passwords.
NOTE: The slackware distribution of Linux defaults to a nonshadowed
password scheme. This may be true of other Linux distributions as well.
However, the programmer responsible for the trojan in question should
not have counted on that. It would have been only slightly more
complicated to add a provision for this.
As you can see, a trojan might crop up anywhere. Even a file originating
from a reasonably trusted source could be trojaned.
Where Might One Find a Trojan?
Technically, a trojan could appear almost anywhere, on any operating system
or platform. However, with the exception of the inside job mentioned
previously, the spread of trojans works very much like the spread of viruses.
Software downloaded from the Internet, especially shareware or freeware, is
always suspect. Similarly, materials downloaded from underground servers or
Usenet newsgroups are also candidates.
Sometimes, one need not travel down such dark and forbidden alleys to find a
trojan. Trojans can be found in major, network-wide distributions. For
example, examine this excerpt from a CIAC security advisory
("E-14: Wuarchive Ftpd Trojan Horse"), posted to the Net in 1994:
CIAC has received information that some copies of the wuarchive FTP
daemon (ftpd) versions 2.2 and 2.1f have been modified at the source
code level to contain a trojan horse. This trojan allows any user,
local or remote, to become root on the affected UNIX system.
CIAC strongly recommends that all sites running these or older versions
of the wuarchive ftpd retrieve and install version 2.3. It is possible
that versions previous to 2.2 and 2.1f contain the trojan as well.
wftpd is one of the most widely used FTP servers in the world. This advisory
affected thousands of sites, public and private. Many of those sites are
still at risk, primarily because the system administrators at those
locations are not as security conscious as they should be.
TIP: Pick 100 random hosts in the void and try their FTP servers. I
would wager that out of those hosts, more than 80% are using wftpd.
In addition, another 40% of those are probably using older versions
that, although they may not be trojaned, have security flaws of
some kind.
C'mon! How Often Are Trojans Really Discovered?
Trojans are discovered often enough that they are a major security concern.
What makes trojans so insidious is that even after they are discovered,
their influence is still felt. Trojans are similar to sniffers in that
respect. No one can be sure exactly how deep into the system the compromise
may have reached. There are several reasons for this, but I will limit this
section to only one.
As you will soon read, the majority of trojans are nested within compiled
binaries. That is to say: The code that houses the trojan is no longer in
human-readable form but has been compiled. Thus, it is in machine language.
This language can be examined in certain raw editors, but even then, only
printable character strings are usually comprehensible. These most often
are error messages, advisories, option flags, or other data printed to
STDOUT at specified points within the program:
my_function()
{
cout << "The value you have entered is out of range!\n";
cout << "Please enter another:"
}
Because the binaries are compiled, they come to the user as (more or less)
point-and-shoot applications. In other words, the user takes the file or
files as is, without intimate knowledge of their structure.
When authorities discover that such a binary houses a trojan, security
advisories are immediately issued. These tend to be preliminary and are
later followed by more comprehensive advisories that may briefly discuss
the agenda and method of operation of the trojan code. Unless the user is a
programmer, these advisories spell out little more than "Get the patch now
and replace the bogus binary." Experienced system administrators may clearly
understand the meaning of such advisories (or even clearly understand the
purpose of the code, which is usually included with the comprehensive
advisory). However, even then, assessment of damages can be difficult.
In some cases, the damage seems simple enough to assess (for example,
instances where the trojan's purpose was to mail out the contents of the
passwd file). The fix is pretty straightforward: Replace the binary with
a clean version and have all users change their passwords. This being the
whole of the trojan's function, no further damage or compromise is expected.
Simple.
But suppose the trojan is more complex. Suppose, for example, that its
purpose is to open a hole for the intruder, a hole through which he gains
root access during the wee hours. If the intruder was careful to alter the
logs, there might be no way of knowing the depth of the compromise
(especially if you discover the trojan months after it was installed).
This type of case might call for reinstallation of the entire operating
system.
NOTE: Reinstallation may be a requisite. Many more of your files might
have been trojaned since the initial compromise. Rather than attempt to
examine each file (or each file's behavior) closely, it might make
better sense to start over. Equally, even if more files haven't been
trojaned, it's likely that passwords, personal data, or other sensitive
materials have been compromised.
Conversely, trojans may be found in executable files that are not compiled.
These might be shell scripts, or perhaps programs written in Perl,
JavaScript, VBScript, Tcl (a popular scripting language), and so forth.
There have been few verified cases of this type of trojan. The cracker who
places a trojan within a noncompiled executable is risking a great deal.
The source is in plain, human-readable text. In a small program, a block of
trojan code would stand out dramatically. However, this method may not be so
ludicrous when dealing with larger programs or in those programs that
incorporate a series of compiled binaries and executable shell scripts
nested within several subdirectories. The more complex the structure of the
distribution, the less likely it is that a human being, using normal methods
of investigation, would uncover a trojan.
Moreover, one must consider the level of the user's knowledge. Users who
know little about their operating system are less likely to venture deep
into the directory structure of a given distribution, looking for mysterious
or suspicious code (even if that code is human readable). The reverse is true
if the user happens to be a programmer. However, the fact that a user is a
programmer does not mean he or she will instantly recognize a trojan. I know
many BASIC programmers who have a difficult time reading code written in
Perl. Thus, if the trojan exists in a scripting language, the programmer
must first be familiar with that language before he or she can identify
objectionable code within it. It is equally true that if the language even
slightly resembles a language that the programmer normally uses, he or she
may be able to identify the problem. For example, Perl is sufficiently
similar to C that a C programmer who has never written a line of Perl could
effectively identify malicious code within a Perl script. And of course,
anyone who writes programs in a shell language or awk would likewise
recognize questionable code in a Perl program.
NOTE: Many Perl programs (or other scripted shell programs) are dynamic;
that is, they may change according to certain circumstances.
For example, consider a program that, in effect, rewrites itself based
on certain conditions specified in the programming code. Such files
need to be checked by hand for tampering because integrity checkers
will always report that the file has been attacked, even when it has
not. Granted, today, there are relatively few dynamic programs, but
that is about to change. There is talk on the Internet of using
languages like Perl to perform functions in Electronic Data Interchange
(EDI). In some instances, these files will perform functions that
necessarily require the program file to change.
What Level of Risk Do Trojans Represent?
Trojans represent a very high level of risk, mainly for reasons already
stated:
Trojans are difficult to detect.
In most cases, trojans are found in binaries, which remain largely in
non-human-readable form.
Trojans can affect many machines.
Let me elaborate. Trojans are a perfect example of the type of attack that
is fatal to the system administrator who has only a very fleeting knowledge
of security. In such a climate, a trojan can lead to total compromise of the
system. The trojan may be in place for weeks or even months before it is
discovered. In that time, a cracker with root privileges could alter the
entire system to suit his or her needs. Thus, even when the trojan is
discovered, new holes may exist of which the system administrator is
completely unaware.
How Does One Detect a Trojan?
Detecting trojans is less difficult than it initially seems. But strong
knowledge of your operating system is needed; also, some knowledge of
encryption can help.
If your environment is such that sensitive data resides on your server
(which is never a good idea), you will want to take advanced measures.
Conversely, if no such information exists on your server, you might feel
comfortable employing less stringent methods. The choice breaks down to
need, time, and interest. The first two of these elements represent cost.
Time always costs money, and that cost will rise depending on how long it
has been since your operating system was installed. This is so because in
that length of time, many applications that complicate the reconciliation
process have probably been installed. For example, consider updates and
upgrades. Sometimes, libraries (or DLL files) are altered or overwritten
with newer versions. If you were using a file-integrity checker, these
files would be identified as changed. If you were not the person who
performed the upgrade or update, and the program is sufficiently obscure,
you might end up chasing a phantom trojan. These situations are rare, true,
but they do occur.
Most forms of protection against (and prevention of) trojans are based on a
technique sometimes referred to as object reconciliation. Although the term
might sound intimidating, it isn't. It is a fancy way of asking "Are things
still just the way I left them?" Here is how it works: Objects are either
files or directories. Reconciliation is the process of comparing those
objects against themselves at some earlier (or later) date. For example,
take a backup tape and compare the file PS as it existed in November 1995
to the PS that now resides on your drive. If the two differ, and no change
has been made to the operating system, something is amiss. This technique
is invariably applied to system files that are installed as part of the
basic operating system.
Object reconciliation can be easy understood if you recognize that for each
time a file is altered in some way, that file's values change. For example,
one way to clock the change in a file is by examining the date it was last
modified. Each time the file is opened, altered, and saved, a new
last-modified date emerges. However, this date can be easily manipulated.
Consider manipulating this time on the PC platform. How difficult is it?
Change the global time setting, apply the desired edits, and archive the
file. The time is now changed. For this reason, time is the least reliable
way to reconcile an object (at least, relying on the simple
date-last-modified time is unreliable). Also, the last date of modification
reveals nothing if the file was unaltered (for example, if it was only copied
or mailed).
NOTE: PC users who have used older machines can easily understand this.
Sometimes, when the CMOS battery fails, the system may temporarily fail.
When it is brought back up, you will see that a few files have the date
January 1, 1980.
Another way to check the integrity of a file is by examining its size.
However, this method is extremely unreliable because of how easily this
value can be manipulated. When editing plain text files, it is simple to
start out with a size of, say, 1,024KB and end up with that same size.
It takes cutting a bit here and adding a bit there. But the situation
changes radically when you want to alter a
binary file. Binary files usually involve the inclusion of special function
libraries and other modules without which the program will not work. Thus,
to alter a binary file (and still have the program function) is a more
complicated process. The programmer must preserve all the indispensable parts
of the program and still find room for his or her own code. Therefore, size
is probably a slightly more reliable index than time. Briefly, before I
continue, let me explain the process by which a file becomes trojaned.
The most common scenario is when a semi-trusted (known) file is the object
of the attack. That is, the file is native to your operating system
distribution; it comes from the vendor (such as the file csh in UNIX or
command.com in DOS). These files are written to your drive on the first
install, and they have a date and time on them. They also are of a specified
size. If the times, dates, or sizes of these files differ from their original
values, this raises immediate suspicion.
Evil programmers know this. Their job, therefore, is to carefully examine the
source code for the file (usually obtained elsewhere) for items that can be
excluded (for example, they may single out commented text or some other,
not-so-essential element of the file). The unauthorized code is written into
the source, and the file is recompiled. The cracker then examines the size of
the file. Perhaps it is too large or too small. The process then begins again,
until the attacker has compiled a file that is as close to the original size
as possible. This is a time-consuming process. If the binary is a fairly
large one, it could take several days.
NOTE: When an original operating-system distributed file is the target,
the attacker may or may not have to go through this process. If the
file has not yet been distributed to anyone, the attacker need not
concern himself or herself with this problem. This is because no one
has yet seen the file or its size. Perhaps only the original author of
the file would know that something was amiss. If that original author
is not security conscious, he or she might not even know. If you are a
programmer, think now about the very last binary you compiled. How big
was it? What was its file size? I bet you don't remember.
When the file has been altered, it is placed where others can obtain it. In
the case of operating-system distributions, this is generally a central site
for download (such as sunsite.unc.edu, which houses one of the largest
collection of UNIX software on the planet). From there, the file finds its
way into workstations across the void.
NOTE: sunsite.unc.edu is the Sun Microsystems-sponsored site at UNC
Chapel Hill. This site houses the greater body of free software on the
Internet. Thousands of individuals--including me--rely on the
high-quality UNIX software available at this location. Not enough good
can be said about this site. It is a tremendous public service.
For reasons that must now seem obvious, the size of the file is also a poor
index by which to measure its alteration. So, to recount: Date, date of last
access, time, and size are all indexes without real meaning. None of these
alone is suitable for determining the integrity of a file. In each, there is
some flaw--usually inherent to the platform--that makes these values easy to
alter. Thus, generating a massive database of all files and their respective
values (time, size, date, or alteration) has only very limited value:
...a checklist is one form of this database for a UNIX system. The file
content themselves are not usually saved as this would require too much
disk space. Instead, a checklist would contain a set of values generated
from the original file--usually including the length, time of last
modification, and owner. The checklist is periodically regenerated and
compared against the save copies, with discrepancies noted. However...
changes may be made to the contents of UNIX files without any of these
values changing from the stored values; in particular, a user gaining
access to the root account may modify the raw disk to alter the saved
data without it showing in the checklist.
There are other indexes, such as checksums, that one can check; these are
far better indexes, but also not entirely reliable. In the checksum system,
the data elements of a file are added together and run through an algorithm.
The resulting number is a checksum, a type of signature for that file
(bar-code readers sometimes use checksums in their scan process). On the
SunOS platform, one can review the checksum of a particular file using the
utility sum. sum calculates (and prints to STDOUT or other specified mediums)
the checksums of files provided on the argument line.
Although checksums are more reliable than time, date, or last date of
modification, these too can be tampered with. Most system administrators
suggest that if you rely on a checksum system, your checksum list should be
kept on a separate server or even a separate medium, accessible only by root
and other trusted users. In any event, checksums work nicely for checking
the integrity of a file transferred, for example, from point A to point B,
but that is the extent of it.
NOTE: Users who have performed direct file transfers using communication
packages such as Qmodem, Telix, Closeup, MTEZ, or others will remember
that these programs sometimes perform checksum or CRC checks as the
transfers occur. For each file transferred, the file is checked for
integrity. This reduces--but does not eliminate--the likelihood of a
damaged file at the destination. If the file proves to be damaged or
flawed, the transfer process may begin again. When dealing with
sophisticated attacks against file integrity, however, this technique
is insufficient.
Cross Reference: Tutorials about defeating checksum systems are
scattered across the Internet. Most are related to the development of
viruses (many virus-checking utilities use checksum analysis to
identify virus activity). A collection of such papers (all of which
are underground) can be found at
http://www.pipo.com/guillermito/darkweb/news.html.
MD5
You're probably wondering whether any technique is sufficient. I am happy to
report that there is such a technique. It involves calculating the digital
fingerprint, or signature, for each file. This is done utilizing various
algorithms. A family of algorithms, called the MD series, is used for this
purpose. One of the most popular implementations is a system called MD5.
MD5 is a utility that can generate a digital signature of a file. MD5
belongs to a family of one-way hash functions called message digest
algorithms. The MD5 system is defined in RFC 1321. Concisely stated:
The algorithm takes as input a message of arbitrary length and produces
as output a 128-bit "fingerprint" or "message digest" of the input. It
is conjectured that it is computationally infeasible to produce two
messages having the same message digest, or to produce any message
having a given prespecified target message digest. The MD5 algorithm
is intended for digital signature applications, where a large file
must be "compressed" in a secure manner before being encrypted with a
private (secret) key under a public-key cryptosystem such as RSA.
Cross Reference: RFC 1321 is located at
http://www.freesoft.org/Connected/RFC/1321/1.html.
When one runs a file through an MD5 implementation, the signature emerges
as a 32-character value. It looks like this:
2d50b2bffb537cc4e637dd1f07a187f4
Many sites that distribute security fixes for the UNIX operating system
employ this technique. Thus, as you browse their directories, you can
examine the original digital signature of each file. If, upon downloading
that file, you find that the signature is different, there is a 99.9% chance
that something is terribly amiss.
MD5 performs a one-way hash function. You may be familiar with these
operations from other forms of encryption, including those used to encrypt
password files.
Some very extreme security programs use MD4 and MD5 algorithms. One such
program is S/Key, which is a registered trademark of Bell Laboratories.
S/Key implements a one-time password scheme. One-time passwords are nearly
unbreakable. S/Key is used primarily for remote logins and to offer advanced
security along those channels of communication (as opposed to using little
or no security by initiating a normal, garden-variety Telnet or Rlogin
session). The process works as described in "S/Key Overview"
(author unknown):
S/Key uses either MD4 or MD5 (one-way hashing algorithms developed by
Ron Rivest) to implement a one-time password scheme. In this system,
passwords are sent cleartext over the network; however, after a
password has been used, it is no longer useful to the eavesdropper.
The biggest advantage of S/Key is that it protects against eavesdroppers
without modification of client software and only marginal inconvenience
to the users.
Cross Reference: Read "S/Key Overview" at
http://medg.lcs.mit.edu/people/wwinston/skey-overview.html.
With or without MD5, object reconciliation is a complex process. True, on a
single workstation with limited resources, one could technically reconcile
each file and directory by hand (I would not recommend this if you want to
preserve your sanity). However, in larger networked environments, this is
simply impossible. So, various utilities have been designed to cope with
this problem. The most celebrated of these is a product aptly named TripWire.
TripWire
TripWire (written in 1992) is a comprehensive system-integrity tool. It is
written in classic Kernhigan and Ritchie C (you will remember from Chapter 7,
"Birth of a Network: The Internet," that I discussed the portability
advantages of C; it was this portability that influenced the choice of
language for the authors of TripWire).
TripWire is well designed, easily understood, and implemented with minimal
difficulty. The system reads your environment from a configuration file.
That file contains all filemasks (the types of files that you want to
monitor). This system can be quite incisive. For example, you can specify
what changes can be made to files of a given class without TripWire reporting
the change (or, for more wholesale monitoring of the system, you can simply
flag a directory as the target of the monitoring process). The original
values (digital signatures) for these files are kept within a database file.
That database file (simple ASCII) is accessed whenever a signature needs to
be calculated. Hash functions included in the distribution are
MD5
MD4
CRC32
MD2
Snefru (Xerox secure hash function)
SHA (The NIST secure hash algorithm)
It is reported that by default, MD5 and the Xerox secure hash function are
both used to generate values for all files. However, TripWire documentation
suggests that all of these functions can be applied to any, a portion of,
or all files.
Altogether, TripWire is a very well-crafted package with many options.
Cross Reference: TripWire (and papers on usage and design)
can be found at
ftp://coast.cs.purdue.edu/pub/tools/unix/TripWire/.
TripWire is a magnificent tool, but there are some security issues. One
such issue relates to the database of values that is generated and
maintained. Essentially, it breaks down to the same issue discussed earlier:
Databases can be altered by a cracker. Therefore, it is recommended that some
measure be undertaken to secure that database. From the beginning, the tool's
authors were well aware of this:
The database used by the integrity checker should be protected from
unauthorized modifications; an intruder who can change the database
can subvert the entire integrity checking scheme.
Cross Reference: Before you use TripWire, read
"The Design and Implementation of TripWire: A File System Integrity
Checker" by Gene H. Kim and Eugene H. Spafford.
It is located at
ftp://ftp.cs.purdue.edu/pub/spaf/security/Tripwire.PS.Z.
One method of protecting the database is extremely sound: Store the database
on read-only media. This virtually eliminates any possibility of tampering.
In fact, this technique is becoming a strong trend in security. In Chapter 21,
"Plan 9 from Bell Labs," you will learn that the folks at Bell Labs now run
their logs to one-time write or read-only media. Moreover, in a recent
security consult, I was surprised to find that the clients (who were only
just learning about security) were very keen on read-only media for their
Web-based databases. These databases were quite sensitive and the information,
if changed, could be potentially threatening to the security of other systems.
Kim and Spafford (authors of TripWire) also suggest that the database be
protected in this manner, though they concede that this could present some
practical, procedural problems. Much depends upon how often the database
will be updated, how large it is, and so forth. Certainly, if you are
implementing TripWire on a wide scale (and in its maximum application),
the maintenance of a read-only database could be formidable. Again, this
breaks down to the level of risk and the need for increased or perhaps
optimum security.
TAMU
The TAMU suite (from Texas A&M University, of course) is a collection of
tools that will greatly enhance the security of a UNIX box. These tools
were created in response to a very real problem. As explained in the
summary that accompanies the distribution:
Texas A&M University UNIX computers recently came under extensive attack
from a coordinated group of Internet crackers. This paper presents an
overview of the problem and our responses, which included the
development of policies, procedures, and sdoels to protect university
computers. The tools developed include `drawbridge', an advanced
Internet filter bridge, `tiger scripts', extremely powerful but easy to
use programs for securing individual hosts, and `xvefc', (XView
Etherfind Client), a powerful distributed network monitor.
Contained within the TAMU distribution is a package of tiger scripts, which
form the basis of the distribution's digital signature authentication. As
the above-mentioned summary explains:
The checking performed covers a wide range of items, including items
identified in CERT announcements, and items observed in the recent
intrusions. The scripts use Xerox's cryptographic checksum programs to
check for both modified system binaries (possible trap doors/trojans),
as well as for the presence of required security related patches.
Cross Reference: Xerox hash.2.5a can be found on the PARC ftp site
(ftp://parcftp.xerox.com/pub/hash/hash2.5a/). This package is generally
referred to as the Xerox Secure Hash Function, and the distribution is
named after Snefru, a pharaoh of ancient Egypt. The distribution at the
aforementioned site was released in 1990, and source is included. For
those interested in hacking the Snefru distribution, the material here
is invaluable. (Also, refer to a sister document about the distribution
and a more comprehensive explanation: A Fast Software One Way Hash
Function by Ralph C. Merkle (there is a full citation at the end of this
chapter in the Resources section).
The TAMU distribution is comprehensive and can be used to solve several
security problems, over and above searching for trojans. It includes a
network monitor and packet filter.
Cross Reference: The TAMU distribution is available at
ftp://coast.cs.purdue.edu/pub/tools/unix/TAMU/.
ATP (The Anti-Tampering Program)
ATP is a bit more obscure than TripWire and the TAMU distribution, but I
am not certain why. Perhaps it is because it is not widely available. In
fact, searches for it may lead you overseas (one good source for it is in
Italy). At any rate, ATP works somewhat like TripWire. As reported by
David Vincenzetti, DSI (University of Milan, Italy) in "ATP--Anti-Tampering
Program":
ATP 'takes a snapshot' of the system, assuming that you are in a trusted
configuration, and performs a number of checks to monitor changes that
might have been made to files.
Cross Reference: "ATP--Anti-Tampering Program" can be found at
http://www.cryptonet.it/docs/atp.html.
ATP then establishes a database of values for each file. One of these values
(the signature) consists of two checksums. The first is a CRC32 checksum, the
second an MD5 checksum. You might be wondering why this is so, especially
when you know that CRC checksums are not entirely secure or reliable, as
explained previously. The explanation is this: Because of its speed, the
CRC32 checksum is used in checks performed on a regular (perhaps daily)
basis. MD5, which is more comprehensive (and therefore more resource and
time intensive), is intended for scheduled, periodic checks (perhaps once a
week).
The database is reportedly encrypted using DES. Thus, ATP provides a flexible
(but quite secure) method of monitoring your network and identifying possible
trojans.
Cross Reference: ATP docs and distribution can be found at
ftp://security.dsi.unimi.it/pub/security.
Hobgoblin
The Hobgoblin tool is an interesting implementation of file- and
system-integrity checking. It utilizes Ondishko Consistency checking. The
authors of the definitive paper on Hobgoblin (Farmer and Spafford at Purdue)
claim that the program is faster and more configurable than COPS and generally
collects information in greater detail. What makes Hobgoblin most interesting,
though, is that it is both a language and an interpreter. The programmers
provided for their own unique descriptors and structural conventions.
The package seems easy to use, but there are some pitfalls. Although
globbing conventions (from both csh and sh/bash) are permissible, the
Hobgoblin interpreter reserves familiar and often-used metacharacters that
have special meaning. Therefore, if you intend to deploy this powerful tool
in a practical manner, you should set aside a few hours to familiarize
yourself with these conventions.
In all, Hobgoblin is an extremely powerful tool for monitoring file systems.
However, I should explain that the program was written specifically for
systems located at the University of Rochester and, although it has been
successfully compiled on a variety of platforms, your mileage may vary. This
is especially so if you are not using a Sun3, Sun4, or VAX with Ultrix. In
this instance, some hacking may be involved. Moreover, it has been observed
that Hobgoblin is lacking some elements present in other file-integrity
checkers, although I believe that third-party file-integrity checkers can be
integrated with (and their calls and arguments nested within) Hobgoblin.
Cross Reference: Hobgoblin and its source are located at
ftp://freebsd.cdrom.com/.20/security/coast/tools/unix/hobgoblin/hobgoblin.shar.Z.uu.Z.
On Other Platforms
You're probably wondering whether there are any such utilities for the
Windows platform. It happens that there are, though they are perhaps not as
powerful or reliable. Most of these tools use checksum integrity checkers
and are, therefore, not as comprehensive as tools that employ MD5. Flatly
stated, the majority for the Microsoft platform are intended for use as
virus scanners.
For this reason, I have not listed these utilities here (a listing of them
does appear in Chapter 14, "Destructive Devices"). However, I do want to
address a few points: It is generally assumed that trojans are a security
problem primarily for UNIX and that when that problem is a Windows problem,
it usually involves a virus. There is some truth to this, and there are
reasons for it.
Until recently, security on IBM compatibles running Microsoft products was
slim. There was no need for complex trojans that could steal (or otherwise
cull) information. Thus, the majority of trojans were viruses encased in
otherwise useful (or purportedly useful) programs. That situation has changed.
It should be understood that a trojan can be just as easily written for a
Microsoft platforms as for any other. Development tools for these platforms
are powerful, user-friendly applications (even VC++ far surpasses C compiling
utilities made by other firms). And, now that the Windows environment is
being used as Internet server material, you can expect the emergence of
trojans.
Summary
People generally equate trojan horses with virus attacks and, while this is
accurate to some degree, it is not the whole picture. True, trojans on the
PC-based operating systems have traditionally been virus related, but on the
UNIX platform, a totally different story emerges. On the UNIX platform,
crackers have consistently crafted trojans that compromise security without
damaging data or attaching unauthorized code to this or that executable.
In either case, however, one thing is clear: Trojans are a significant
security risk to any server as well as to machines networked to that server.
Because PC-based servers are becoming more common on the Internet, utilities
(above and beyond those virus checkers already available) that can identify
trojaned files must be developed.
Resources
Following you will find an extensive list of resources concerning object
reconciliation. Some of these documents are related to the process of object
reconciliation (including practical examples) and some are related to the
process by which this reconciliation is performed. All of them were
handpicked for relevancy and content. These are the main papers available
from the void (some books are sprinkled in as well). I recommend that every
system administrator at least gain a baseline knowledge of these techniques
(if not actually implement the procedures detailed within).
"MDx-MAC and Building Fast MACs from Hash Functions." Bart Preneel and
Paul C. van Oorschot. Crypto 95.
ftp.esat.kuleuven.ac.be/pub/COSIC/preneel/mdxmac_crypto95.ps
"Message Authentication with One-Way Hash Functions." Gene Tsudik. 1992.
IEEE Infocom 1992.
http://www.zurich.ibm.com/Technology/Security/publications/1992/t92.ps.Z
"RFC 1446--1.5.1. Message Digest Algorithm." Connected: An Internet
Encyclopedia.
http://www.freesoft.org/Connected/RFC/1446/7.html
"Answers To FREQUENTLY ASKED QUESTIONS About Today's Cryptography." Paul
Fahn. RSA Laboratories. 1993 RSA Laboratories, a division of RSA Data Security.
http://www.sandcastle-ltd.com/Info/RSA_FAQ.html
"The Checksum Home Page." Macintosh Checksum.
http://www.cerfnet.com/~gpw/Checksum.html
"RFC 1510--6. Encryption and Checksum Specifications." Connected: An
Internet Encyclopedia.
http://www.freesoft.org/Connected/RFC/1510/69.html
"RFC 1510--6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)."
Connected: An Internet Encyclopedia. J. Kohl. Digital Equipment Corporation,
C. Neuman, ISI. September 1993.
http://www.freesoft.org/Connected/RFC/1510/index.html
"Improving the Efficiency and Reliability of Digital Time-Stamping."
D. Bayer and S. Haber and W. S. Stornetta. 1992.
http://www.surety.com
"A Proposed Extension to HTTP: Simple MD5 Access Authentication."
Jeffery L. Hostetler and Eric W. Sink. 1994.
http://www.spyglass.com/techreport/simple_aa.txt
"A Digital Signature Based on a Conventional Encryption Function."
Ralph C. Merkle. Crypto 87, LNCS, pp. 369-378, SV, Aug 1987.
"An Efficient Identification Scheme based on Permuted Kernels."
Adi Shamir. Crypto 89, LNCS, pp. 606-609, SV, Aug 1989.
"An Introduction To Digest Algorithms." Proceedings of the Digital
Equipment Computer Users Society Australia, Ross N. Williams. Sep 1994.
ftp://ftp.rocksoft.com/pub/rocksoft/papers/digest10.tex
"Data Integrity With Veracity." Ross N. Williams.
ftp://ftp.rocksoft.com/clients/rocksoft/papers/vercty10.tex
"Implementing Commercial Data Integrity with Secure Capabilities."
Paul A. Karger. SympSecPr. Oakland, CA. 1988. IEEECSP.
"Trusted Distribution of Software Over the Internet." Aviel D. Rubin.
(Bellcore's Trusted Software Integrity (Betsi) System). 1994.
ftp://ftp.cert.dfn.de/pub/docs/betsi/Betsi.ps
"International Conference on the Theory and Applications of Cryptology."
1994 Wollongong, N.S.W. Advances in Cryptology, ASIACRYPT November
28-December 1, 1994. (Proceedings) Berlin & New York. Springer, 1995.
"Managing Data Protection" (Second Edition). Dr. Chris Pounder and
Freddy Kosten, Butterworth-Heineman Limited, 1992.
"Some Technical Notes on S/Key, PGP..." Adam Shostack.
http://www.homeport.org/~adam/skey-tech-2.html
"Description of a New Variable-Length Key, 64-Bit Block Cipher" (Blowfish).
Bruce Schneier. Counterpane Systems.
http://www.program.com/source/crypto/blowfish.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
12. Easy hack
by Latvious
latvious@hotmail.com
August 27, 1998
here's a great place to hack www.heartland.ab.ca
Hell finger works. For the ports if you want em email me.
(this was found in our public BBS!)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
If you think you are good enough you might want to join UHA, for this
email us : uha1@gmx.net. Also look onto our Homepage into the join-section!
We are also interessted in alliances with other Hacking Groups.
Greetings to gHF, iNsAnE iNc, NuKeM, IHA and all members of UHA.
-=[ United Hacker Association 1 ]=-
Email : uha1@gmx.net
Homepage : http://www.uha1.com (after the uha there is a ONE!)
If www.uha1.com is down go to http://come.to/UHA
************************************ EOF ************************************
