Copy Link
Add to Bookmark
Report
InfoHax Digest 01
InfoHax Digest, Number 1
Saturday, January 25th 1992
Today's Topics:
welcome.hax
form.0
sysadmin.comments
frm.paper
frm.mentor.paper
shell.tools
phone.trace.evsn
BSD.accnt.files
trace.fakemail.gd
IP.tracing
more.IP.tracing
rfc931
hacker.trkr.tools
hideum.pl
----------------------------------------------------------------------
Date: Fri, 24 Jan 92 18:04:41 -0700
Subject: welcome.hax
*****************************************************************************
WELCOME TO PROJECT: INFOHAX
*****************************************************************************
Project: INFOHAX is an invitation only project to write the most explicit
and complete guide to hacking UNIX systems that has ever been put out. We
are starting with a 150k paper as an outline, filling in all the holes/tricks
and expanding on it substantially.
Project durration is set at 1+ year, with digests comming out once a week,
delphi style, perhaps more often if the traffic warrents it.
***IN ORDER TO GET FURTHER DIGESTS YOU NEED TO SUBSCRIBE TO THE LISTSERV.***
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
we also have a passworded fileserver, Details to follow.
send mail to:
LISTSERV@STORMKING.COM
with
SUBSCRIBE INFOHAX User_Name
in the msg body
if you have not been confirmed, you will be rebuffed.
to access the fileserver send mail to:
LISTSERV@STORMKING.COM
with
HELP
INDEX INFOHAX /silicon_lollipop
in the msg body
for confirmation or to get a copy of the 'outline paper' contact
XXXXXXXXXXXXXX
so far confirmed people are:
XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
XXXXXXXXX XXXXXXXXX XXXXXXXXXX XXXXXXXXXX
some people we havn't heard back from or havn't got confirmations from:
XXXXXXXX
XXXXXXXX
you're in if you wanna be, let us know.
These people have been recomended by someone and need to be voted on:
please vote on a 0-10 scale, 0=NO 5=I_DONT_CARE 10=YES
XXXXXXXX
XXXXXXXX
XXXXXXXX
if anyone has suggestions for additional people, please let me know.
if anyone has strong feelings one way or the other on any of these people,
voice um!
SO HOW DOES THIS WORK?
We're trying to work it like a delphi right now. A delphi is a think tank
technique where you present an idea to work on, and send it out to people
to work on, solve problems, submit info, ask/answer questions, comment on,
etc. in a little less than a week send in what you have so far, and it will
all be bundled into digests and sent out again... the list is moderated so
some sorting/organising can happen before it goes out again. then people
keep working on what they were, but have feedback and fresh material from
everyone else... it's a really powerfull technique, so I hope it works for
us. I think there will be some rough edges to work out, as to the methods,
hopefully this wont take too long.
I put out a form (see below: form.0) to help organise info, and keep
track of things, please use it! the header and tail should be used for
feedback, and discussions, please save bandwidth and nuke the 'DATA:'
section, except for BRIEF extracts of the text being commented on.
Also PLEASE SEND COMMENTS ON DIFFERENT SECTIONS IN DIFFERENT E-MAIL,
that will make sorting sooooo mutch easier, a section name in the
'Subject' field would be nice too...
PLEASE NOTE THAT THE LISTSERV WILL NUKE THE FROM LINE OF YOUR EMAIL,
if you want people to know who wrote what you just sent in, put your
name or handle in the body of the message.
If you're submitting original material, please use the whole thing. We
will assighn a section # to avoid chaos...
Also if you have input on the genneral form of the project, discussions
that don't relate to a particular area, etc. please send a form with a
header/subject line of DISCUSSION these will be collected together at the
begiinning of the digests. The methods/form of the project are totally
variable, and I encourage you to suggest changes, we may throw the delphi
out all together, it's a starting point, nothing more. If you don't like
it say so!
If you see something referenced that you don't understand, ask about it.
If you see a trick mentioned, but not explained, that you know something
about, or have ideas on - even if you don't totally grok it, send in what
you know, or ideas about how it might work. There are alot of little
sections that need to be worked on. If you have something to say about it
do!, even if you're not the person working on it. If you see a section
that you'd like to work on, adopt it. basicly we get alot better info if
people arn't territorial about a section they are working on, and accept
/incorperate input.
In other words we're working under total anarchy! be nice to each other,
cooperate, and lets not have any flame wars...
PROJECT OUTLINE:
the main sections of the original paper follow, after that some additions:
Theory Devices
Network Security Monitoring
Other Network Services Net Monitoring
Accnt Security Accnt Monitoring
File System Security File System Monitoring
Setgid Programs Know your System
Startup Files Improving Your Security
User Utils Pollicies
Programming Utils Countermeasures
Encryption Biblio
additions:
How not to get caught - logging, covering tracks, laundering calls, becoming
invisable to the system, who's on, housecleaning, hiding setuid, trojans,..
Getting in the Door...
Getting Root
Setuid Progs/shells
Passive Snooping
Network Spoofing
Patch Level and Version History
this list is far from complete, please suggest additions!, oh yeah, a large
collection of exploitation type code/scripts at the end.
if anyone would like to start filling in the outline/TOC that would be
great!
This first chapter is on how not to get caught. It will effect all the
other areas of the paper and is going to be revisited/added to as we visit
every other chapter. It's also a good springboard to get folks started in
on other areas. I'm not shure if it's best to hop arround at random doing
different sections in parrallel, or sequentially chapter by chapter...
feedback?
This first digest has the following areas to stimmulate discussion:
sec01: sysadmin.comments - on logging
sec02: frm.paper - what we're expanding on
sec03: frm.mentor.paper - prev work to build on
sec04: shell.tools - proposed tools by calculite, some comments
by tangent
sec05: phone.trace.evsn - info in evading phone traces
sec06: BSD.accnt.files - summary of w/ notes on exploiting
sec07: trace.fakemail.gd - slightly dated, lotta good tricks to tease out
sec08: IP.tracing - discussions on hacker trackers
sec09: more.IP.tracing - more of above
sec10: rfc931 - bad news... need to find ways arround this.
sec11: hacker.trkr.tools - how we get caught...
sec12: hideum.pl - pearl script for nuking /utmp entries
Some areas that need discussion are weather we should include available
material, or just ref it. examples include mentors paper, rfc931, phracks
'hiding out under unix', and another phrack artical on getting lost (title?)
My thoughts are to include it if it's short, or at least stick it on the
file server... feedback?
Obvious areas (in this chapter) that need something written about them are:
UUCP logging evading phone traces
SysV log summary UNIX as outdial
IP spoofing terminal servers and gateways
If you feel you have a specialty area, please list it, and start work on
that area (with a partner or two if there's overlap), though everyone should
comment/contribute to all areas, if possable. This is supposed to be a
democracy, so if you want to change what I'm outlining, please submit your
ideas and the group can hash it out. Don't get overwelmed!, if we took 2wks
on eash major area, this project would take a year, It's probably going to
take more than that... remember, we're basicly writing a BOOK!
we can officially consider this project underway, expect mailings every wk,
perhaps twice a wk when things get going well!
Happy Hacking!
Tangent
-----------------------------------------------------------------------------
------------------------------
Date: Fri, 24 Jan 92 18:14:48 -0700
Subject: form.0
In an attempt to keep things organised from the start I put together a
form for communication. The sole purpose of this is to be able to easily
refer to what's been done, keep track of revisions, and cross ref comments
and pointers to other sections...
Please buffer, and USE this for communication:
--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<----
==============================================================================
Section Name chapter.sec.version 00/00/00
------------------------------------------------------------------------------
DATA:
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
---8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<--snip--8<---
where:
Section Name - is the name of the sevtion within the chapter.
chapter.sec.version - is the overall ref, version starts at 0, and goes up
just like software or OS releases
00/00/00 - is the last revision date
DATA: - is material submitted, or commented on, or exploitation type code (for
this chapter = code, and sec = chapter), etc. another chapter Biblio: - works
the same way. The DATA area is for ORIGINAL material being submitted, or for
REVISIONS (one person ties all replies together, and puts together a revision)
the idea here is to keep the bandwidth down, and avoid the redundancy of
newsgroups...
------------------------------------------------------------------------------
Comments: this is a 'maybe this would be possable' type area, or gen comments
on the DATA sec, you can eithor reply by interspercing comments in the data
via '>'s or put um here, and nuke the data for replies, as everyone will
allready have the data.
Q's: how is this done, anyone know about this, etc... type area...
Biblio: refs to go in the biblio chapter
CrossRef: this ties in to, or could be used in chp#,sec#...
Code/shRef: exploitation type code, or shell scripts for the code chapter, ref
to, code should go in the Data sec of message.
------------------------------------------------------------------------------
OK, so maybe this isn't perfect, not shure how it will work, but it WILL
make life soooo mutch easier a couple of months down the road, and when it
goes to final edit...
If anyone has comments on how to improve this, or do it better, speak up!,
once this is set, we're going to be stuck with it for the whole project.
Also, to make things more clear, the DATA area is what will be eventually
published. The leading, and trailing headers are to keep track of it, and
talk about it(DATA).
------------------------------------------------------------------------------
------------------------------
Date: Fri, 24 Jan 92 18:20:48 -0700
Subject: sysadmin.comments
==============================================================================
Section Name chapter.sec.version 00/00/00
sysadmin.comments 01.01.0 01/21/92
------------------------------------------------------------------------------
DATA:
17) OK, finally, logs. I read every log that grows without bounds,
including daemonlogs that would show unauthorized reboots if not altered.
I never found anything odd in ptydaemonlog or vtdaemonlog, or any unreason-
able reboots, startups, shutdowns, etc., although I kept reading the logs
anyway.
Obviously I reviewed sulog, but I never found anything in there
either, although possibly the fact that I disabled su early on had something
to do with that :).
I also read my own .x11startlog, which would show startup times for
X windows on the console; that was always clean.
The ones that I did find things in were /etc/btmp and /etc/wtmp,
expecially wtmp...I'm not sure how familiar you are with the format of
these, so just to summarize, they give username, tty, time on and time off.
btmp is the bad login attempt log, wtmp the successful login attempt log.
I rather imagine that a dialup cracking attempt by an outsider would tend
to generate more btmp entries, but on my system the interesting stuff was
usually in wtmp. Anyway:
In the log of bad logins, btmp, you look for repeated login attempts
for a single user, especially if they are clustered around the same time,
and especially if there are a large number of login attempts which don't
show any typographical errors in the user name. A third to a half of
legitimate entries--that is, failed logins by authorized users--in btmp
will show typos in entering the username, or sometimes weird character
strings that indicate somebody leaned on the keyboard. Some of them will
show passwords typed in where usernames should be, which is why btmp is
supposed to be readable only by root. I imagine that dialup will show
some 'line noise' failures. My users were on hardwired terminals, so that
didn't appear.
Large numbers of failed entries for a single user in which the user-
name is typed correctly mean either that a legitimate user has forgotten his
password, a legitimate user is typing spastically this morning, or somebody's
trying to crack that account. I'd ask the user if he was doing something
that would have led to all the bad attempts; sometimes the answer was yes,
in which case I could get him a new password or forget it. If it's no,
I know I have a problem.
The other pattern that sometimes occurs is 'sweeps' across large
numbers of usernames, usually typed correctly, clustered at the same time
and originating from the same terminal. This is almost always cracking,
if it shows up in btmp.
What is never anything but cracking is the appearance of login attempts
for reasonable guesses at usernames that don't happen to exist on your system.
The 'sweep' pattern, in our company, could be legitimate if it showed
up in wtmp, the log of successful logins, because certain trusted department
heads were authorized to login as their subordinates and occasionally did so
for administrative purposes. In this case, the sweep usually originates at
a single terminal, generally the department head's, and covers that department
only.
I looked for a string of fairly obvious things in wtmp: simultaneous
logins by the same user, users logged in at unusual times or from unusual
ports, off-console root logins, etc. This actually took the most time, and
is the one I did the most asking about--hey, Rita, did you log in in Ben's
office yesterday? and so forth.
The larger the system and # of users, obviously, the harder this
is to do. I could have started correlating wtmp and btmp entries, but
never got the time to write the script. We also didn't have auditing enabled
because I didn't get a chance to put it up, because I was under pressure to
get the system operational. That was probably a mistake, although it wouldn't
really have changed the final outcome of anything.
I did pin down a major security breach with this procedure, because
I found one more off-console root login than I knew was legitimate, which
neither I nor the assistant administrators could account for. I found the
damage not long after, although it took me, honestly, about two weeks to
figure out why that particular item had been changed (It's not a secret, but
definitely belongs in another letter, so I'll save it).
This approach obviously has a flaw (aside from not having auditing)
in that I obviously wouldn't see a breach that involved someone else logging
in at a user's regular terminal at a reasonable time for that user to be
there, which I strongly suspect happened more than once. Auditing would
have caught anomalous system activity in that case if file permissions
had been changed. It couldn't have caught the falsifying of information
within the scope of the user's normal routine--if someone logged in as
the bookkeeper in the right place at the right time calls up the usual
programs and does everything except enter the numbers straight, there is
no way to pick that up with auditing.
Since I will have auditing up when I go up on the net, the report
we ought to be able to compile on this subject after the experiments ought
to be much more complete, and I'm looking forward to it as it should be
fascinating. Thanks :)
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 18:25:13 -0700
Subject: frm.paper
==============================================================================
Section Name chapter.sec.version 00/00/00
frm.paper 01.02.0 01/21/92
------------------------------------------------------------------------------
DATA:
In general the intruder can cover his own tracks. Detecting Intrusion
therefor depends on on the intruder neglecting to do so, plus the
installation of log keeping. The existence of log keeping should be
somewhat secret to increase the probability that the intruder will
unwittingly reveal his acts and methods.
The best logkeeping consists of writing to a hardcopy device so that
the intruder cannot erase the log.
Sometimes a single slip-up by an intruder will reveal a huge case of
previously unsuspected penetration.
SYSLOG
------
The syslog facility is a mechanism that enables any command to log error
messages and informational messages to the system console, as well as to a
log file. Typically error messages are logged in the file
/usr/spool/log/syslog along with the date, time, and name of the program
sending the message to the program.
Example:
DEC 24 12:10:06 WS1 NNTPXMIT: greet=520 SAMT 19 NNTP server can't talk to you
DEC 24 14:53:37 WS1 LOGIN: root login ttyp3 from WS2.podunk.edu
DEC 25 08:02:03 WS1 LOGIN: root login ttyp4 from wizard.hack.com
DEC 25 08:28:52 WS1 SU: joueuser on /dev/ttyp3
DEC 25 10:23:41 WS1 VMUNIX: /: file system full
DEC 25 11:30:42 WS1 LOGIN: repeated login failures on ttyp3 from
sys1.podunk.edu, daemon
DEC 25 11:45:08 WS1 NNTPD: rnews: inews: comp.foo: no valid newsgroup found
Of particular interest are the messages from the login and su programs.
Wheneverr someone logs in as root login logs this informtion. In general
logging in as root directly, as opposed to using the su program is better
as it is harder to tell which person is actually using the accnt.
Login also logs any case of someone repeatedly trying to log into an
account and failing, 3 consecutive times.
These messages can be used to check for users sharring accounts, as well
as hacking attempts.
SHOWMOUNT
---------
Can be used on a NFS file server to show the names of all hosts that
currently have something mounted from that server.
w/ no options just shows a list of all the hosts.
w/ '-A' shows all the hosts and directory combinations ie:
ws1.cs.podunk.edu:/usr/local
bart.podunk.edu:/var/spool/mail
maggie.podunk.edu:/usr/local
w/ '-D' shows a list of all directories mounted by some host.
Showmount's output is checked for 2 things, first, only machines local
to the systems organization should appear there. Second, only "normal"
directories should be mounted - unusual directories being mounted may
indicate a hacking attempt.
FTP LOGGING
-----------
Some versions of ftp allow administrators to turn on and off logging
information. The standard BSD4.2 does not, but there are publiclly
available patches to the code to enable this feature.
Example:
@ws5.cs.podunk.edu (bsimpson) wed may 30 19:32:11 1990
get /pub/gnu/gcc-11.37.tar.Z
@131.170.8.11 (intruder) wed may 30 22:13:01 1990
get /etc/passwd
put /pub/annoying-msg
jueuser@podunk.edu wed june 6 08:19:16 1990
get /pub/sun-source/faces-1.3.tar.Z
get /pub/gnuemacs-18.55.tar.Z
In the case where lines begin w/ an '@', an anonymous ftp was done. The
password given by the user (they ask for username, sometimes site name /
address - will usually take anything) is in parenthesis after the hostname.
In the case where lines start w/ a username, a normal user has logged on
to transfer files.
Whenever you transfer files with ftp, the manager will know what login
was used, what files were transfered, and to what site.
(use a login, not your own , rename the files, and site hop...)
ACCOUNT MONITORING:
-------------------
Accounts are monitored to check for:
A) users logged in when they shouldn't be (i.e. late at night, when
the're on vacation, etc)
B) users executing commands they wouldn't normally be expected to use.
LAST
----
Last looks back in the wtmp file which records all logins and logouts
for information about a user, a teletype or any group of users and teletypes.
Arguments specify names of users or teletypes of interest. Names of teletypes
may be given fully or abbreviated. For example, LAST 0 is the same as LAST
TTY0. If multiple arguments are given, the information which applies to any
of the arguments is printed. For example "last root console" would list all
of root's sessions, as well as all sessions on the console terminal.
Last displays the sessions of of the specified users and teletypes, most
recent first, indicating the times at which the session began, the duration
of the session, and the teletype the session took place on. If the session
is still continuing or was cut short by a reboot.
With no arguments, last displays a list of all logins and logouts, in
reverse order.
Example:
$ last -4 joeuser
joeuser ttyp1 ws1.cs.podunk.e wed jun 6 10:04 still logged in
joeuser ttyp3 bart.poduke.edu tue jun 5 15:01 - 15:01 (00:00)
joeuser ttyp0 maggie.podunk.e tue jun 5 10:05 - 19:44 (09:38)
joeuser console ws2.cs.poduke.e tue jun 5 09:49 - 10:05 (00:16)
LASTCOMM
--------
Lastcomm gives information about previously executed commands. Without
any arguments it gives information about all the commands recorded durring
the the current accounting files lifetime. If called with no arguments, it
displays information about all the commands recorded durring the current
accounting files lifetime. If called with arguments it only displays
accounting records with a matching command name, user name, or terminal name.
Example:
$ lastcomm
who simsonb ttyp0 0 secs wed jun 6 10:03
mesg joeuser ttyp1 0 secs wed jun 6 10:03
biff joeuser ttyp1 0 secs wed jul 6 10:03
csh F joeuser ttyp1 0 secs wed jul 6 10:03
killercracker intruder ttyp4 7240 secs wed jul 6 08:01
. . .
For each process entry, lastcom displays the following items of
information:
The command name under which the proccess was called
One or more flaggs indicating special information about the process,
the flags have the following meanings:
F The process performed a fork, but not an exec
S The process ran as a set-user-id program
D The process dumped memory
X The process was killed by some signal
The name of the user who ran the process
The terminal which the user was logged onto at the time (if applicable)
The ammount of CPU time used by the process (in seconds)
The date and time the process exited
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 18:34:31 -0700
Subject: frm.mentor.paper
==============================================================================
Section Name chapter.sec.version 00/00/00
frm.mentor.paper 01.03.0 01/21/92
------------------------------------------------------------------------------
DATA:
ls -l will tell you the last time a file was modified, make a note of
this when you tamper w/ a file, and set it back w/ the touch command when
you are finnished, syntax is:
touch hhmmMMdd [file]
Where hh is hour, mm is minute, MM, is month, and dd is the day, [file]
is obvious...
What usually gives away hackers is the files they create on systems. If
you must make files and directories on systems, make use of the hidden file
feature ('.filename'). Also try to hide them in directories that are rarely
ls'd, such as /usr/spool/lp, /usr/lib/uucp, etc.
If you replace a users file with a modified copy, this copy will be owned
by your account and group instead of the account which owned the original.
You can change the group back w/ the chgrp command. syntax is:
chgrp [groupname] [file]
and change the owner back w/ the chown command:
chown [user] [file]
If you do something wrong, assume a note of it was recorded somewhere on
the system. Leave the system and it's files exactly as you found them.
If you think it would go unknowticed, and your expection to ring alot of
bells you can turn off system logging (if you have root).
BSD ERROR LOGGING
-----------------
Type "cat /etc/syslog.pid", this file contains the process number of the
syslog (error logging) program. Kill this process, and you have stopped
error logging. Remember to start it back up when your through.
If you want to see where the error logging messages are sent, type:
cat /etc/syslog.config
Entries are in the form:
#file
Such as:
5/etc/errorlogfile
The number is the priority of the error, and the file is the file that
errors of that level are sent to. If you see an entry with /dev/console as
it's log file, watch out! Errors of that priority are sent to the system
console. Sometimes a list of usernames will follow an entry for errorlogging.
This means that these users will be notified of any errors of that priority
or higher.
There are 9 levels of error priority's, 1 is lowest, 5 is the lever of
errors gennerally caused by hackers - security violations, bad login and su
attemps, attempts to access files w/ out proper permissions..., level 9
is a system crash.
SysV ERROR LOGGING
------------------
The SysV error logging prog is errdaemon, to find it's pid type "ps -uroot"
among roots processes you will find /etc/errdaemon. If you kill it there will
be no more logging till you start it again. By default it writes errors to
the /usr/admin/errorfile.
To get a report of errors type:
errpt [-a] /usr/adm/errfile
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 18:44:10 -0700
Subject: shell.tools
==============================================================================
Section Name chapter.sec.version 00/00/00
shell.tools 01.04.1 01/22/92
------------------------------------------------------------------------------
DATA:
I'll try to write a summary right now. It won't be in the proper format, but
it's not a final submission, either...
BEGIN SHELL SCRIPT SUMMARY
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Something that could come in handy for hacking UNIX systems would be a shell
script that would automate the following:
1) disable logging
2) edit standard logs to remove lines containing the account name that's being
used (when logs don't exist, inform the user)
3) remove information from the utmp file for the account name that's being
used in order to avoid detection
(write privs to utmp requires root privs on anything but a sun)
4) reenable logging when the user is done
(unless you are alone, it might not be a great idea to disable/reenable
logging, might look abit fishy ... how about just nuking log entries
for your username/uid/pid)
and possibly do the following:
1) alert the user when users log on and off
(how about just people w/ privs, or owner of accnt)
2) attempt to exploit known bugs and edit appropriate logs
This script could be uploaded after the user has obtained access to a system
and be executed with possible options to disable functions when they're not
desired.
(other things: set up a working subdir
store + restore .history (if present)
1 key macro to nuke subdir, logout, and suicide process )
END SHELL SCRIPT SUMMARY
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
BEGIN HACK PROGRAM SUMMARY
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Another useful tool would be a program that would connect to port 25 of a
target system and attempt passwords from a dictionary on standard usernames
(guest, anonymous, ingres, new, apply, etc..) and usernames obtained manually
by the user. This would operate much like an /etc/passwd cracker, but would
actually try acct/passwd combinations over the net. NOTE: This should be used
only as a last effort from a safe acct. It will, no doubt, affect logs on
systems that log failed attempts. Possible sources for code: generic net
interface code, MUD 'bot code, telnet source.
A friend of mine wrote a telnet scanner that brought net connections to a crawl,
he just did it sequentially, w/ no delay... a very irate sysadmin dragged him
into his office and very nicely told him to never ever do that again...
a little break between calls is important!
END SUMMARY
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Shannon Robert Madsen / Calculite | mtymp10@ux.acs.umn.edu
"To err is human; to moo, bovine." | "Religion is the opiate of the masses."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 18:52:14 -0700
Subject: phone.trace.evsn
==============================================================================
Section Name chapter.sec.version 00/00/00
phone.trace.evsn 01.05.0 01/24/92
------------------------------------------------------------------------------
DATA:
Don't have mutch for this area yet. some stratagies are:
use a goldbox
use a diverter
radio or cordless phone 1/2 in a bbox, 1/2 a safe distance away.
use call forwarding to forward to a phone in a different babybell's area,
then send it through MCI (refuses to provide call records in court) or to
thriftytell(flat rate service w/ no call detail records)
PLEASE ADD TO THIS!
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 18:57:04 -0700
Subject: BSD.accnt.files
==============================================================================
Section Name chapter.sec.version 00/00/00
BSD.acct.files 01.06.1 01/18/92
------------------------------------------------------------------------------
DATA:
SUMMARY OF BSD ACCOUNTING FILES:
--------------------------------
data kept filename type owner group mode note
----------------------------------------------------------------------------
CPU,memory,i/o /usr/adm/acct binary root system 644 (1)
connect time /usr/adm/wtmp binary root system 644 (2)
disk usage the file system n/a root operator 640 (3)
printer usage /usr/adm/lpacct text daemon daemon 644 (4)
dialout usage /usr/adm/aculog text uucp daemon 644 (5)
console msgs /usr/adm/messages ? root system 664 (6)
shutdown reasons /usr/adm/shutdownlog ? root system 664 (7)
time daemon log /usr/adm/timed.log ? root system 644 (8)
uucp transaction /usr/spool/uucp/LOGFILE ? uucp daemon 664 (9)
uucp file transfer /usr/spool/uucp/SYSLOG ? uucp daemon 664 (10)
network routing /usr/adm/gatedlog ? root system 644 (11)
news connection .../news/nntp/logfile ? news news 644 (12)
----------------------------------------------------------------------------
1)accton(?) turns on accounting, sa(?) used to read, with the '-s' flag will
summerize CPU usage by command, and TRUNCATES /usr/adm/acct to ZERO LENGTH!
all commands executed once or with unprintable chars show up as '***other'
(hmmm..), the system automatically suspends accounting if the file system
that contains the accounting data becomes 95% full. If the machine crashes
or is rebooted, processes that were running are not recorded in the CPU acct
file, you can avoid cpu accounting by having your program sleep indefininatly
upon completion as a program that never terminates does not produce any
accounting record. (sleep(?) is also a good alternative to at and cron for
hiding periodic processes). man acct(5)
4)can also be set via a macro in /etc/printcap
5)records login name, date, time, phone number, and status of all calls made
through a dial out modem via the cu(?), tip(?) and uucp family of commands.
If you are allowed to talk directly to the modem via a dialer entry in the
file /etc/remote then the command 'tip dialer' will circumvent the
accounting process.
6)also messages.N where N is from 0 to 6, usually.
9/10)This is for V7 UUCP, HDB (as in SunOS 4.x) is under /usr/spool/uucp/.Log
/{uucp,uucio,uux,???}/<system name>
8/11/12)These are not standard, though many systems have them. Also, the
filenames are compile time options (or set in config files)...
----------------------------------------------------------------------------
Q's)"owner, group, and mode(octal) of the accounting data files is important
and that any program used to reinitialize these files should be shure to
chown, chgrp, and chmod appropriatly" - so what happens if these are altered?
will a prog that 'unlink argv[0];'s be logged?
what about if the utmp entry is zero'd out?
other tricks?
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 19:29:37 -0700
Subject: trace.fakemail.gd
==============================================================================
Section Name chapter.sec.version 00/00/00
trace.fakemail.guide 01.07.0 01/21/92
------------------------------------------------------------------------------
DATA:
Phil Goetz asked how to trace forged mail. The short answer is: use
log files and talk to other sysadmins so they'll do the same.
A forged messages is injected into the mail system at some point, with
a particular set of header lines. The header lines inserted after that
point will be real. You can verify that the lines are real by checking
the logs on each system to see that they match what's in the message.
When you find a discrepancy, you are close to the insertion point.
Then you can poke around there to determine how the forged message was
inserted into the mail system, and by who. As you'll see, there are
lots of places where it could've come in.
The long answer is specific to the programs involved. My description
covers sendmail and uucp. I encourage people to clean up this
description and add their own ideas, suggestions, and mailer programs.
Look in the message for its message-ID and Received: lines. These will
tell you what systems the message has gone through. Start with the
last system (the recipient's system). Check the sendmail log (or
equivalent) for that message-ID. This will let you map the message-ID
to a queue-ID (generally AAxxxxx or ABxxxxx) which is in every log line
that refers to this message. The log will show the message-ID, a from=
line, and a set of to= lines indicating how it was delivered. If the
log entries are there, you can probably believe the Received: line for
that time, which indicates where the message came from. If it came
from an Internet site, go back to that site and check its logs. If it
came from uucp, sendmail won't know its origin, but you can check the
uucp logs for a line at that time indicating "XQT (...rmail...)". [If
you don't find one, the message was probably inserted onto your system
by running sendmail or /bin/mail manually.]
The system name in the uucp log "XQT" line will tell you part of the
file name of the incoming mail. Probably the message came from that
system, but uucp doesn't check for this, so somebody could've sent you
uucp files containing somebody else's system name. Look back in the
log for files coming in with this system name in the filename. You can
also look in the uucp SYSLOG file, which contains the size of each file
transferred, to help figure out which file contained the message. In
some cases there is no way to unambiguously track the message here
(until uux and uuxqt logging is improved to show the queue ID that it's
executing). But in most cases you'll find where the message came in
from. Contact the site admin for that site, indicate that you received
the message at such and such a time, and have them check their uucp
logs. They should find that the message was transferring at the same
time. If not, it means somebody called your system and claimed to be
them doing uucp; if you have a separate uucp login/password per site,
you'll know that either you or they let the password get out. Change
it. (Note that anyone who is root on their system can read this
password out of their L.sys file.) If you don't have a separate uucp
login/password for each site, fix this! You can't tell when your
password is leaked, which site it leaked through! Also, don't put
phone numbers and uucp logins in email; tell the remote site by phone.
If you don't know their phone number, find it out -- how are you going
to tell them about troubles on your uucp link when your link is broken?
If the other site finds that the same files were moving in their logs
as in your logs, then have them scan back through the log to find an
XQT QUE'D entry for this message. You should know what's in the rmail
command's arguments (since they're in your XQT log message) and the
same arguments will appear in the XQT QUE'D message. That shows you
the date and time when the message entered the uucp queue on their
system. Then their site admin can cross-reference to the sendmail log
to verify that the message exited sendmail at the same time it entered
uucp (if not, the message was inserted manually by someone running a
"uux" command on their system), and trace the sendmail log back. They
can also check the Received: lines in the message to help find it in
the sendmail log, or simply grep for the message-ID.
If the message had come into sendmail via an SMTP connection rather
than via uucp, the Received: line should say "Received: from xxxxx".
If there are two addresses in XXXXX then check both of them; one is how
that site identified itself in the SMTP protocol; the other is what the
host table said about the Internet address where the connection is
coming from. Have the site admin on that/those sites check their logs
and work back from there. If there is no record of sendmail handling
the message on that site, but your sendmail says it was received from
that site, either someone on that site inserted the message (e.g. by
doing "telnet yoursite smtp") or some other site impersonated their IP
address. (A third possibility is that your host table or domain name
cache has been hacked to make the site-they-connected-from appear to
have the name of some other site). Start poking around with what
users and processes were running on their system, and double-check
the name server or hosts file on your system.
Checking the "last" and "lastcomm" and cron logs may also be quite
helpful to find sendmail and uucico and uux runs, either to
disambiguate other log entries or if you lose the trail. It would help
a lot to have an inetd log, too; has anyone hacked this into inetd?
(Inetd is the master daemon that handles incoming connections for a
whole mess of protocols, including telnet, rlogin, ftp, etc -- but not
smtp).
It's harder to trace a forgery that occurs by changing the contents of
an existing message. E.g. the sender sent one version, the recipient
got another. It could have been modified at each site along the way as
it sat in a queue. It may be possible to track this down by checking
the mesasge sizes at each site, but you have to account for the header
lines changing. You could send a second message through the same path,
with the same initial byte count, see what transformations happen
to it along the way, and compare its logged byte counts to the counts
of the forged message.
If you can trace the message all the way back to the sender's site, but
they claim they didn't send it, then the last and lastcomm and cron
logs are useful for seeing who was on the system and what processes
were running. Lastcomm (Unix process accounting) really should be
logging the PID of each process so that its log can be backtraced into
the other log files (sendmail and uucp both log the PID). Perhaps some
other user sent the mail while su'd to that user, or injected it into
the local sendmail daemon by connecting to the SMTP port on the local
machine. Perhaps they used the TIOCSTI ioctl to insert fake 'typing'
into one of the user's windows (perhaps even an iconified window) that
caused the message to be sent "by them". This can be done when nobody
else is logged in, but requires a process left around from some earlier
time -- which should show up in lastcomm logs. Or perhaps someone just
walked by their terminal, popped up a shell window, sent the message,
and destroyed the window. This can be done in seconds if the message
is in a prepared file (e.g. in /tmp), but again you'll find it in the
process logs.
If the user logs into that system via TCP, the TCP connection can be
compromised (e.g. by forging a packet to appear to be from their
workstation or x terminal). The next packet that is sent from the real
TCP connection will cause the connection to reset, but that could
happen hours later, and will just look like temporary network trouble
(the window disappears or the rlogin says "Connection closed"). This
is harder to spot since neither end of the link won't see anything odd
until much later (except that the terminal may get some output
resulting from the mail being sent, like another shell prompt; this
could be disguised by clever use of terminal escape codes so it
overprints the previous shell prompt). Lastcomm showing that the last
thing to run on that pty was the mailer, even if the end of the pty
(its shell terminating) happens much later, is probably your best clue
there. An SMTP tcp connection can also be altered in this way. I have
heard that someone at MIT is logging the first 50 bytes of every packet
that goes through their Internet gateways, and keeping it for days. If
you were really desperate, and the breakin happened at MIT, you could
try locating the person doing the logging. (Needless to say the log is
not available to everyone, since it includes all the login names and
passwords used through the gateway!!!)
Also don't forget that a claimed forgery may be a real message that the
sender wishes to repudiate.
As you can see, tracking a message back through five or ten sites this
way would involve a lot of work and coordination, as well as requiring
quick action so that that the forgery is noticed and traced before each
of those sites' logs are removed. I encourage sites to keep a few
weeks' worth of uucp and sendmail logs so that this kind of forgery can
be more easily traced. Compress them to save space. Suns come with
shell scripts that keep the log files for N days; you can hack these to
alter N, move logs to places where there's more space, compress, or
whatever.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 19:36:13 -0700
Subject: IP.tracing
==============================================================================
Section Name chapter.sec.version 00/00/00
IP.tracing 01.08.0 01/21/92
------------------------------------------------------------------------------
DATA:
>one question: how do you trace someone through the net? in progress/after the
>fact. - needed for current section of paper, thanks.
It is directly related to the method they used to enter the net. For instance
the /var/log/syslog file contains alot of information from folks using
sendmail. There are obviously uucp logs. Some folks run front ends to the
progs run out of inetd, which causes some logging -- to where... I dunno,
depends on how they compiled the software. Best bet is to watch these
directories:
/var/log
/var/adm
>ok, on the logging thing, I was thinking of tracing IP packets... could you
>expand on that a little?
Again, nothing in *standard* unix. Sure, theoretically, I could, and I know
that some sites do, trap and log all IP packets.
>netstat, ofiles, rfc931, and packages that will log
>what it sends all seem to have something to do with it...
Yes, sites *could* run some of this stuff, but to say WHERE they are logging
it is impossible. One would certainly want to do a long ps listing to see
what processes are running. One implementation of RFC931 has a daemon called
authd, but most folks run it out of inetd, so that would go un-noticed. I
personally feel that the easiest way to detect such changes is to do a
comparison to an "out of the box" system. For instance, compare inetd.conf
files -- files created under /var/log and /var/adm, and so on....
>'last' reads some file and tells where the connect to a particular accnt ...
It reads wtmp (on suns /var/adm/wtmp). It logs normal logins, but not things
like rsh. This obviously makes things like rsh HOST sh -i very useful. Also
note that certain versions of utils like xterm and screen don't do logging,
due to the non-writability of utmp on some systems and those apps not being
setuid to a uid that can write to it. Basically, if you come in and even
touch the "login" program, wtmp will have mention of it. Again, not rsh
doesn't.
>also what methods could be used to enter the net (brief, for now)
Well, obviously you need to make it to a node on "the net". This is done
by either:
dialing up a host
dialing up a terminal server*
*= Some terminal servers are WIDE OPEN. Ask some folks about terminus...
There are other ways, but I don't know much more about them. I know there
is a packet radio network and a few sites will actually forward their packets.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 19:47:24 -0700
Subject: more.IP.tracing
==============================================================================
Section Name chapter.sec.version 00/00/00
more.IP.tracing 01.09.0 01/22/92
------------------------------------------------------------------------------
DATA:
Subject: Finding out where someone remotely logged in from
>Suppose a program is running as the login shell under telnetd (or is a
>script run by the login shell, or some such). Is there a good way it
>can discover the remote host from which the login was made?
>The best way I've been able to figure out is to get the tty name (from
>'who am i') and look it up in /etc/utmp. Unfortunately, utmp only
>contains the first 16 characters of the remote host name. It seems to
>me that there should be a good way to do this, since the telnetd could
>just do a getpeername and find out its address. (In fact, either
>telnetd or login *does*, in order to make the entry in utmp.) But
>this information doesn't seem to be easily available to child
>processes.
The quick answer is that you can use either netstat or ofiles.
netstat gives you a list of connections, and you have to pick out the one
that corresponds to the utmp entry, then use netstat -n to get the IP address.
Alternatively, you can use ofiles on the corresponding in.telnetd process
(the parent of the shell), and see where file descriptors 0, 1 and 2 point to.
That's where they're coming from.
--------------------
I have a similar problem only we are using System V and thus our hostname of
origin isn't in /etc/utmp
Is there a way to use netstat (which _does_ show the origin) and associate
the results with individual terminals or users?
[...]
Paul Mc Auley | God is real . . . . . .
--------------------------|
AKA pmcauley@maths.tcd.ie | . . . . . . . . Unless Declared an Integer.
----------------------
Ok, not much of a solution, but at least it works:
I had to do this for a client a couple of years ago. The solution I
used then was (lacking source at their site) as follows:
If you are using inetd (if not, the same _principle_ applies but the
implementation is a trifle more complex), simply write a short programme that
replaces telnetd. This programme does a getpeername() on it's stdin descrip-
tor and squirrels it away somewhere before invoking the _real_ telnet or login
daemon (with any arguments IT was originally called with).
Places to squirrel the information:
1/ In an environment variable. This sometimes works but can allow a
user to `fake' their location and anyway, some telnetd/rlogind programmes
refuse to pass over an inherited environment.
2/ In a file indexed by something. Pick a suitable index - I used
the PID since I already had (fast) routines to trace process parentage that
would allow you to find the highest parent (closest to init) who'se parent
WAS init - this would be the telnet/rlogin daemon (having the same PID as
the new programme). It would be nice to know the tty name that the daemon
will allocate, but unfortunately this hasn't been decided yet (there are
frigs round this but they're unpleasant).
3/ fork/exec - child exec's the real daemon, parent closes it's
descriptors and watches for the PGRP of the child at which point the tty
name is known (hackity hack).
----------------------
> netstat gives you a list of connections, and you have to pick out
> the one that corresponds to the utmp entry, then use netstat -n to
> get the IP address.
> Alternatively, you can use ofiles on the corresponding in.telnetd
> process (the parent of the shell), and see where file descriptors
> 0, 1 and 2 point to. That's where they're coming from.
I've looked into this, and run into some problems:
netstat will truncate a symbolic host name to 16 characters (as does
finger and the entry in utmp). This can be easily overcome with -n,
which causes it to give numeric IP addresses.
Unfortunately, netstat gives no way to associate a particular
connection with the telnetd that it feeds. In fact, all incoming
telnet connections list the same address on "this end" (port 512).
ofiles might be useful, but we don't have it (we're running SunOS
4.1.1), as far as I can tell.
I have found that pstat -u will give all sorts of useful information
about a process, including where internal control blocks are located.
The 'files' field has pointers to the open files table, and pstat -f
will list information about the open files table. But, alas, the peer
address is not listed.
Does anybody know of any other utilities to investigate?
-----------------
RARP can catch IP forgery; encryption systems like Kerberose, simply
ignore forged packets.
------------------
> "any desired IP address" Seems to me that you're limited to using ip
>addresses in the range assigned to the subnet of your local wire.
>Otherwise, you're not going to be able to interact with (or attack) any
>systems (even ones on the local wire). And if you do change the ip address
>to an unused one and then back to the real one when you're done, you will
>have given away your site and genneral location.
This is a common misconception.
Yes, you need to use an address in your sub-net if you wish to receive
any reverse traffic, but not all popular protocols rely on two-way
communications. NFS servers, for instance, perform the requested operation
and then send the reply back; if the reply can't reach the sender, the
operation has still been carried out, so who cares if the reverse
communication isn't possable? Simmilarly, many network time protocols use
one-way datagrams.
----------------
[...]look at the /etc/services file. Each of these services is a possable
security problem.
-----------------
ME: Hmmm, someone tried to break in from 'foo.bar.edu'.
<in e-mail> "Hey, root@foo.bar.edu. Someone tried to crack my
machine from yours. Could you check your logs for
Wed Jan 22 07:00:00 EST? Thanks."
ROOT: <in e-mail> "Someone from baz.bletch.com logged into our guest
account from 04:00:00 to 08:30:00 this morning. Hmm, I think I'm
going to start keeping a closer eye on the use of my guest account
from now on."
ME: "Thanks, root@foo.bar.edu." "Hey, root@baz.bletch.com ..."
--------------
There are many other groups working on reducing internet anonymity: for
example, Athena, the auth-acct list, SAAG, even rfc931-users.
^^^^^^^^^^^^^^ ^^^^
anyone know who these groups are?
--------------
Try tracing this...
telnet to nsf.sun.ac.uk
log into janet pad
connect to {some janet site}
now connect from there ta a certain SPAN node
now patch out to the internet
There are at least 2 of the SPAN-IP gateways (where?)
Try tracing that convaluded mess!
It makes your terminus look like a kindergarden session:
You have involved 3 networks, 2 countries, and about 5 science/networking
agencies. Its a game of hunt the duristiction folks.
-------------
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 19:55:52 -0700
Subject: rfc931
==============================================================================
Section Name chapter.sec.version 00/00/00
rfc.931 01.10.0 01/22/92
------------------------------------------------------------------------------
DATA:
Network Working Group Mike StJohns
Request for Comments: 931 TPSC
Supersedes: RFC 912 January 1985
Authentication Server
STATUS OF THIS MEMO
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for improvements.
This is the second draft of this proposal (superseding RFC 912) and
incorporates a more formal description of the syntax for the request
and response dialog, as well as a change to specify the type of user
identification returned. Distribution of this memo is unlimited.
INTRODUCTION
The Authentication Server Protocol provides a means to determine the
identity of a user of a particular TCP connection. Given a TCP port
number pair, it returns a character string which identifies the owner
of that connection on the server's system. Suggested uses include
automatic identification and verification of a user during an FTP
session, additional verification of a TAC dial up user, and access
verification for a generalized network file server.
OVERVIEW
This is a connection based application on TCP. A server listens for
TCP connections on TCP port 113 (decimal). Once a connection is
established, the server reads one line of data which specifies the
connection of interest. If it exists, the system dependent user
identifier of the connection of interest is sent out the connection.
The service closes the connection after sending the user identifier.
RESTRICTIONS
Queries are permitted only for fully specified connections. The
local/foreign host pair used to fully specify the connection are
taken from the query connection. This means a user on Host A may
only query the server on Host B about connections between A and B.
QUERY/RESPONSE FORMAT
The server accepts simple text query requests of the form
<local-port>, <foreign-port>
where <local-port> is the TCP port (decimal) on the target (server)
system, and <foreign-port> is the TCP port (decimal) on the source
(user) system.
For example:
23, 6191
The response is of the form
<local-port>, <foreign-port> : <response-type> : <additional-info>
where <local-port>,<foreign-port> are the same pair as the query,
<response-type> is a keyword identifying the type of response, and
<additional info> is context dependent.
For example:
23, 6191 : USERID : MULTICS : StJohns.DODCSC.a
23, 6193 : USERID : TAC : MCSJ-MITMUL
23, 6195 : ERROR : NO-USER
RESPONSE TYPES
A response can be one of two types:
USERID
In this case, <additional-info> is a string consisting of an
operating system name, followed by a ":", followed by user
identification string in a format peculiar to the operating system
indicated. Permitted operating system names are specified in
RFC-923, "Assigned Numbers" or its successors. The only other
names permitted are "TAC" to specify a BBN Terminal Access
Controller, and "OTHER" to specify any other operating system not
yet registered with the NIC.
ERROR
For some reason the owner of <TCP-port> could not be determined,
<additional-info> tells why. The following are suggested values
of <additional-info> and their meanings.
INVALID-PORT
Either the local or foreign port was improperly specified.
NO-USER
The connection specified by the port pair is not currently in
use.
UNKNOWN-ERROR
Can't determine connection owner; reason unknown. Other values
may be specified as necessary.
CAVEATS
Unfortunately, the trustworthiness of the various host systems that
might implement an authentication server will vary quite a bit. It
is up to the various applications that will use the server to
determine the amount of trust they will place in the returned
information. It may be appropriate in some cases restrict the use of
the server to within a locally controlled subnet.
APPLICATIONS
1) Automatic user authentication for FTP
A user-FTP may send a USER command with no argument to the
server-FTP to request automatic authentication. The server-FTP
will reply with a 230 (user logged in) if it can use the
authentication. It will reply with a 530 (not logged in) if it
cannot authenticate the user. It will reply with a 500 or 501
(syntax or parameter problem) if it does not implement automatic
authentication. Please note that no change is needed to currently
implemented servers to handle the request for authentication; they
will reject it normally as a parameter problem. This is a
suggested implementation for experimental use only.
2) Verification for privileged network operations. For example,
having the server start or stop special purpose servers.
3) Elimination of "double login" for TAC and other TELNET users.
This will be implemented as a TELNET option.
FORMAL SYNTAX
<request> ::= <port-pair> <CR> <LF>
<port-pair> ::= <integer-number> "," <integer-number>
<reply> ::= <reply-text> <CR> <LF>
<reply-text> ::= <error-reply> | <auth-reply>
<error-reply> ::= <port-pair> ":" ERROR ":" <error-type>
<auth-reply> ::= <port-pair> ":" USERID ":" <opsys> ":" <user-id>
<error-type> ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR
<opsys> ::= TAC | OTHER | MULTICS | UNIX ...etc.
(See "Assigned Numbers")
Notes on Syntax:
1) White space (blanks and tab characters) between tokens is not
important and may be ignored.
2) White space, the token separator character (":"), and the port
pair separator character (",") must be quoted if used within a
token. The quote character is a back-slash, ASCII 92 (decimal)
("\"). For example, a quoted colon is "\:". The back-slash must
also be quoted if its needed to represent itself ("\\").
Notes on User Identification Format:
The user identifier returned by the server should be the standard one
for the system. For example, the standard Multics identifier
consists of a PERSONID followed by a ".", followed by a PROJECTID,
followed by a ".", followed by an INSTANCE TAG of one character. An
instance tag of "a" identifies an interactive user, and instance tag
of "m" identifies an absentee job (batch job) user, and an instance
tag of "z" identifies a daemon (background) user.
Each set of operating system users must come to a consensus as to
what the OFFICIAL user identification for their systems will be.
Until they register this information, they must use the "OTHER" tag
to specify their user identification.
Notes on User Identification Translation:
Once you have a user identifier from a remote system, you must then
have a way of translating it into an identifier that meaningful on
the local system. The following is a sketchy outline of table driven
scheme for doing this.
The table consists of four columns, the first three are used to match
against, the fourth is the result.
USERID Opsys Address Result
MCSJ-MITMUL TAC 26.*.*.* StJohns
* MULTICS 192.5.42.* =
* OTHER 10.0.0.42 anonymous
MSJ ITS 10.3.0.44 StJohns
The above table is a sample one for a Multics system on MILNET at the
Pentagon. When an authentication is returned, the particular
application using the userid simply looks for the first match in the
table. Notice the second line. It says that any authentication
coming from a Multics system on Net 192.5.42 is accepted in the same
format.
Obviously, various users will have to be registered to use this
facility, but the registration can be done at the same time the use
receives his login identity from the system.
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 20:04:46 -0700
Subject: hacker.trkr.tools
==============================================================================
Section Name chapter.sec.version 00/00/00
hacker.trkr.tools 01.11.0 01/24/92
------------------------------------------------------------------------------
DATA:
There are a number of "Hacker Tracker Tools", most have something to
do with rfc931, which is bad news... fortunatly it's not standard yet,
but it is becomming so... the documents below came with some of these
packages, they are worth reading as certain info can be gleaned from
them, such as where they put logs, and the programs names that run
these things. From this it should be able to tell if one of these is
running on a system, and devise ways to spoof them. They also alude to
security holes, that we can tease out... and offer pointers to other
programs in the same class... Shortcommings and weaknesses are also
identified. I havn't collected all of the programs yet, but am doing so.
these docs are chopped extracts from the program docs that come with
the programs. They need to be summerised further... (maybe a chart or
two...)
Programs of this type that I'm awaire of are:
AUTHD: 147.28.0.33 /pub/misc/authd301.tar.Z
KSTUFF: 128.174.5.50 /pub/kstuff-0.18.tar.Z
RARP: 137.208.3.5 /pub/src/datacom/rarpd.tar.Z
OFILES: 128.95.136.1 /pub/misc/ofiles.?
LOG_TCP: 147.28.0.3 /pub/unix/netware/log_tcp.?
LUMBERJACK:(?) 128.218.1.13 /comp.sources.unix/Volume16/lumberjack
ACTIV:(?) 128.256.135.4 /mirrors/unix-c/utils/activ.?
PAUTHD: ftp.lysator.liu.se /pub/daemons/pauthd-1.2.tar.Z
FTPD: wuarchive.wustl.edu /packages/ftpd.wuarchive.shar
also see the 'related software' section of tcp_log docs (below) for
pointers to rshd, rlogind, tftp and authutil.
If anyone knows of others please mention them.
---------------
some news extracts:
There are many anonymous entrances into most systems. Local modem pools
are untraceable without a court order. PC's connected to a local Ethernet
can run their own copy of software and gain access to mutch they shouldn't
Even on those systems wheree we require authentication, there's often
nothing I can do after the fact to trace who attacked you. We don't log
every IP connection made, and on a UNIX system with 30 simultanious users
often the best I can do is say "it was one of those 30" Indeed on a
default SunOS system, even if you tell me while you're being attacked,
'bout all I can do is run NETSTAT and agree with you that someone on the
local machine is doing it--without OFILES or some other non-standard tool,
I don't believe there's a way to trace an IP connection back to the process
that owns it.
-------------
[...]it's still a pain in the neck to figure out which USER made a
connection unless you can run PS and OFILES and so on WHILE the
connection is in progress. But there are tools like rfc931 which solve
this.
[...]it's still a pain in the neck to figgure our which MACHINE generated
a particular TCP packet, since TCP is insecure, unless you run RARP and
various other tools--like secure Ethernets, or Kerberos.
------------------------------------------------------------------------
TCP-LOG:
General description:
--------------------
With this package you can monitor connections to the SYSTAT, FINGER,
FTP, TELNET, RLOGIN, RSH and EXEC network services. Connections are
logged through the syslog(3) facility. A requirement is that daemons
are started by the inetd program or something similar.
The programs are tiny front ends that just report the remote host name
and then invoke the real network daemon. In the most common case, no
changes should be required to existing software or to configuration
files. Just move the vendor-provided daemons to another place and
install the front ends into their original places. Installation details
are given below.
Early versions of the programs were tested with Ultrix >= 2.2, with
SunOS >= 3.4 and ISC 2.2. The first official release has been installed
on a wide variety of systems (BSD, SYSV, Apollo) without modification.
The present release should still run on top of most BSD-style TCP/IP
implementations.
Optional feature:
-----------------
When compiled with -DHOSTS_ACCESS, the front-end programs support a
simple form of access control that is based on host (or domain) names,
internet addresses or network numbers, network daemon process names and
(optionally) netgroups (a NIS, formerly YP, feature). Wild cards are
supported. If a host requests connection to a network daemon, and if
the (daemon, host) pair is matched by an entry in the /etc/hosts.allow
file, access is granted. Otherwise, if the (daemon, host) pair is
matched by an entry in the /etc/hosts.deny file, access is denied.
Otherwise, access is granted. More details are provided in the
hosts_access(5) manual page. This form of access control may be useful
if it can not be implemented at a more suitable level (such as an
internet router).
Major enhancement:
------------------
It has been brought to my attention that AUTHENTICATION BASED ON HOST
ADDRESS TO HOST NAME MAPPING CAN EASILY BE SPOOFED BY PLAYING GAMES
WITH SOME DOMAIN NAME SERVER. A little research led me to the conclusion
that many existing RSHD and RLOGIND implementations do not account for
this potential problem.
The present versions of the front-end programs provide a way to take
care of the problem. After mapping a client host address to a host
name, the front-end programs now verify that the host name maps to the
same host address. The idea is that it is much easier to compromise
the address->name map of some random name server than to compromise the
name->address map that is specific to your domain. If the source is
compiled with -DPARANOID, the front ends justs drop the connection in
case of a host name/address mismatch. Otherwise, the front ends just
ignore the bad host name and use the host address when consulting the
access control files.
Minor enhancements:
-------------------
The host access control files now support more types of wild cards and
(optionally) allow the use of netgroup names. Netgroup support is
usually available on systems with NIS (formerly YP) software.
Related software:
-----------------
Versions of rshd and rlogind, hacked to report the remote user name as
well, are available for anon ftp (ftp.win.tue.nl:/pub/logdaemon.tar.Z).
That archive also contains a tftpd source that logs the remote host
name (nice if you want to know who is interested in your /etc/passwd
file). All those programs have been tested only with SunOS >= 4.0.
Another way to manage access to tcp/ip services is illustrated by the
servers provided with the authutil package (comp.sources.unix volume
22). This has the advantage that one will get the remote username from
any host supporting RFC 931 security. By installing the auth package
(same volume) one supports RFC 931 security too (but YOU WILL HAVE TO
BELIEVE WHAT THE REMOTE HOST TELLS YOU). Eventually one can start
cutting off unauthenticated connections. This is obviously a much more
advanced approach than what my front-end programs provide. The present
package is more suitable for those who lack the resources to install
anything that requires more than just renaming a couple of executables.
Configuration and installation (the easy way):
----------------------------------------------
An advanced installation recipe is given lateron. The "easy way" recipe
requires no changes to existing software or configuration files.
If you don't run Ultrix, you don't need the miscd front-end program.
The Ultrix miscd daemon implements among others the SYSTAT service,
which pipes the output from the WHO command to standard output.
By default, connections are logged to the same place where the sendmail
log entries go. If connections should be logged elsewhere, adjust the
LOG_MAIL macro in the miscd.c and tcpd.c files, and update your syslog
configuration file (usually, /etc/syslog.conf). Most Ultrix versions
do not provide this flexibility, though.
The tcpd program is intended for monitoring connections to the telnet,
finger, ftp, exec, rsh and rlogin services. Decide which services you
want to be monitored. Move the vendor-provided daemon programs to the
location specified by the REAL_DAEMON_DIR macro in the file tcpd.c, and
copy the tcpd front end to the locations where the vendor-provided
daemons used to be. That is, one copy of the tcpd front end for each
service that you want to monitor.
---------------------------------------------------------------------------
AUTHD:
authd - authentication server daemon
tcpuid, tcpuname - find out which user owns a connection
authuser - remote authentication library
authd is an implementation of RFC 931, the Authentication Server under
BSD. RFC 931 provides the name of the user owning a TCP connection. This
helps network security: UNLESS TCP ITSELF IS COMPROMISED, it is
impossible to forge mail or news between computers supporting RFC 931.
It also BECOMES MUCH EASIER TO TRACE ATTACKERS than in the current,
largely anonymous, network. authd requires no changes to current code:
every connect() and accept() is authenticated automatically, with no
loss of efficiency.
tcpuid and tcpuname are the same program, but more suitable for local
use from the command line by a user or system administrator. They show
which local user created a given TCP connection.
authuser is a library encapsulating client use of RFC 931. It talks to a
remote Authentication Server to find out the username on the other side
of a given connection.
Only root can install authd. However, most current systems are insecure
enough that any user can run tcpuid and tcpuname. authuser is meant for
use by any program.
[...]
2. Requirements
authd requires netstat, and it pokes around in several BSD-specific
kernel structures. It is not inherently portable code. Nevertheless, it
has been compiled under Ultrix, SunOS, and Convex UNIX, and it probably
doesn't take much work to get running under pretty much any BSD system.
authuser should compile and run without trouble on any BSD system.
You must be root to install authd. However, authd's sister utilities,
tcpuid and tcpuname, will probably work anyway if /dev/kmem is readable.
Any program can use the authuser library.
3. How to configure authd
You can change CC or CCOPTS in Makefile if you want. If you want authd
to record connections through syslog at LOG_DEBUG, define -DUSE_SYSLOG
in the Makefile.
5. How to install authd
If you don't have privileges, skip this part.
By default, authd, tcpuid, and tcpuname are installed in /etc,
authuser.o is installed as /usr/lib/libauthuser.a, authuser.h is
installed in /usr/include, authuser.3 is installed in /usr/man/man3,
and authd.8, tcpuid.8, and tcpuname.8 are installed in /usr/man/man8.
The binaries are installed setgid to group kmem. If you want to change
these defaults, edit INSTALL.
Then run INSTALL in a root shell; the script will check every action
with you before doing it.
To test tcpuname, make sure it is in your path, and run netstatuid. You
should get a report of all active network connections including
usernames.
To test authuser and authd, run ./test. You should get an ``everything
looks okay'' message.
6. TODO list
fast multiple-connection version of tcpuid/tcpuname, like netstatuid?
should write a few notes on the exact security provided by rfc 931
authd - Authentication Server daemon authd is a daemon implement-
ing the RFC 931 Authentication Server protocol. It should be in-
voked by a network server, such as or for connections to TCP port
113 (auth). The client host gives two numbers separated by a
comma. interprets the numbers as TCP port numbers for the local
and remote sides respectively of a TCP connection between this
host and the client host. It returns a line of the form local-
port, remoteport: USERID: UNIX: username where username is the
name of the user on this side of the specified connection. If
does not have an authentication entry for that connection, it re-
turns a line of the form localport, remoteport: ERROR: UNKNOWN-
ERROR. None. None known. authd version 3.01, February 7, 1991.
Placed into the public domain by Daniel J. Bernstein. Partially
inspired by code written by Vic Abell for ofiles. The authenti-
cation server is more secure than passwords in some ways, but
less secure than passwords in many ways. (It's certainly better
than no password at all---e.g., for mail or news.) It is not the
final solution. For an excellent discussion of security problems
within the TCP/IP protocol suite, see Steve Bellovin's article
``Security Problems in the TCP/IP Protocol Suite.'' authtcp(1),
attachport(1), authuser(3), tcp(4), inetd(8) tcpuid - show the
user id that created a network connection tcpuid prints the
numeric user id of the user who created the network connection
specified by its arguments. Lots, none of which should happen if
the specified connection is valid. None known. tcpuid version
3.01, February 7, 1991. Placed into the public domain by Daniel
J. Bernstein. Partially inspired by code written by Vic Abell
for ofiles. authd(8), tcpuname(8) tcpuname - show the user name
that created a network connection tcpuname prints the username of
nection is valid. None known. tcpuname version 3.01, February
7, 1991. Placed into the public domain by Daniel J. Bernstein.
Partially inspired by code written by Vic Abell for ofiles.
authd(8), tcpuid(8)
------------------------------------------------------------------------
OFILES:
ofiles - show owner of open file or network connection [ ] [ ] [
] [ ] displays the owner, process identification (PID), type,
command and the number of the inode associated with an open in-
stance of a file or a network connection. An open file may be a
regular file, a file system or a directory; it is specified by
its path name. When the path name refers to a file system, will
display the owners of all open instances of files in the system.
An open network connection is specified by the kernel address of
its Protocol Control Block (PCB), as displayed by when its option
is specified. displays information about its usage if no options
are specified. This option selects verbose, debugging output.
This option may be used only on DYNIX hosts. It sets optional
name list and core file paths. is the path to the file from
which should obtain the addresses of kernel symbols, instead of
from is the path to the file from which should obtain the value
of kernel symbols, instead of from This option is useful for de-
bugging system crash dumps. This option specifies that the argu-
ments identify network connections by their hexadecimal, Protocol
Control Block (PCB) addresses. PCB addresses can be obtained via
the option of This option makes it possible to determine the lo-
cal processes that are using network connections in the LISTEN
through ESTABLISHED states. This option specifies that should
print process identifiers only - e. g., so that the output may be
piped to These are path names of files, directories and file sys-
tems; or, if the option has been specified, network connections,
identified by their hexadecimal Protocol Control Block (PCB) ad-
dresses. displays for each for file paths, an interpretation of
the type of name - file, directory or file system; for network
connections, the kernel address linkages, starting with the file
structure and proceeding through the socket structure and the In-
ternet Protocol Control Block (INPCB) structure to the PCB the
login name of the user of the process that has open the identif-
ier of the process that has open a file type explanation: if is
the current working directory of the process if is being used as
a regular file by the process, optionally followed by: if the
process has a shared lock on the file if the process has an ex-
clusive lock on the file if is the root directory of the process
if is a socket the file descriptor number, local to the process
the user command that opened the inode number of the file This
example shows the use of to discover the owner of the open, regu-
lar file,
% ofiles /usr/spool/lpd/lock
/usr/spool/lpd/lock
USER PID TYPE FD CMD INODE
root 110 file/x 3 lpd 26683
This example shows the use of and to identify the local endpoint
of the ``smtp'' network connection. The first column of output
from is the PCB address; it is used as the argument to along with
the option.
% netstat -aA | grep smtp
80f6770c tcp 0 0 *.smtp *.* LISTEN
% ofiles -n 80f6770c
file 80102b64 of socket 80f6758c of INPCB 80f6780c of PCB 80f6770c
USER PID TYPE FD CMD
root 105 sock 5 sendmail
Errors are identified with messages on the standard error file.
returns a one (1) if any error was detected, including the
failure to locate any It returns a zero (0) if no errors were
detected and if it was able to display owner information about
all the specified can't identify SunOS 4.0 stream files, so it
doesn't follow their file structure pointers correctly when read-
ing their inodes. That results in the display of erroneous inode
numbers for stream files. The option limits its search to net-
work connections in the LISTEN through ESTABLISHED states. Since
reads kernel memory in its search for open files and network con-
nections, rapid changes in kernel memory may produce unsatisfac-
tory results. C. Spencer is the original author. Michael Ditto,
Tom Dunigan, Alexander Dupuy, Gary Nebbett and Richard Tobin con-
tributed. Michael Spitzer, Ray Moody, and Vik Lall of the Purdue
University Computing Center converted the program to a variety of
UNIX environments. Vic Abell of the Purdue University Computing
Center added the option. inode(5), mount(1), kill(1), tcp(4).
----------------------------------------------------------------------
RARPD:
* Reverse Address Resolution Protocol server
* Routines that handle network I/O, and process RARP packets.
/* EtherRead reads the packet and checks to see it's the right opcode, etc. */
/* Make sure we're looking for the right kind of Ethernet address. */
* Send a response packet with our addresses in 'source' addresses. rarpPacket
comes in with the target addresses filled in, as well as the sizes, etc. */
/* remember sender's hardware address, so the packet can be returned */
/* fill in reply opcode and source addresses */
* This programs sends a request packet to the rarp server and waits forever
* for a reply, then displays the response packet.
/* An IP prototcol address */
/* An ethernet addresss for broadcast */
/*fill in reply opcode and source and target address*/
/* broadcast a request packet */
/* prints an array a for n characters (as hexadecimal digits) with dots in
* between.
/* prints an array a for n characters (as decimal digits) with dots in
* between.
* test program for Reverse Address Resolution Protocol server
* This programs sends a request packet to the rarp server and waits forever
* for a reply, then displays the response packet.
/* An Ethernet hardware address (3Mbps) */
/* An IP prototcol address */
/* An ethernet addresss for broadcast */
/* broadcast a request packet */
* added support for 3Mbps Ethernets.
* This server uses files (/etc/rarpdb.*) to create a table of mappings
* between Ethernet (hardware) addresses and 32-bit IP protocol (logical)
* addresses.
* It can be expanded to include other kinds of hardware and protocol
* addresses, if needed.
* It provides a service for client machines (usually diskless workstations)
* to return a logical address when given a hardware address.
****************************************************************
* Possible future extensions:
* 1)Fix Our_Ether_Addr to reflect multiple networks. Right now
*gethostid is used, which returns the IP address on the first
*network, not necessarily the 10 Mbit one. (in OpenEthers)
* 2)Change LookUp to use a faster search than sequential.
* 3)Support other kinds of 'hardware' or 'protocol' addresses.
/*interval to wait before checking to see if disk file has been changed*/
/* Main mostly does debug and error-checking things. It calls OpenEthers
to establish the networks, and then calls MainLoop to do the serving. *
/* save ethermask because "select" changes the bits to indicate
which of the bits that were on in readfds correspond to
files that have packets waiting on their net */
/* something to read from this ether */
OpenEthers()
/* OpenEthers goes through all nets on this machine and opens a file for
each Ethernet interface. It builds a pernet table for each file
opened. It calls BringInTable to build a table of address pairs for each
net. It sets up a packet filter for each net for RARP packets. */
/* gethostid really gets the main id and won't work if > 1 net: */
* Routines for reading and searching the table of
* (Ethernet address, IP address) pairs.
/* Parses the input line "line", entering the IP and Ethernet addresses
* found into "tabent". This routine returns:
* 1 if the line was successfully parsed,
* 0 if the line is empty or begins with a comment character (; or #),
* -1 if a syntax error was found in the line.
---------------------------------------------------------------------------
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
------------------------------
Date: Fri, 24 Jan 92 21:27:27 -0700
Subject: hideum.pl
==============================================================================
Section Name chapter.sec.version 00/00/00
unwho.pl toolbox.01.0 01/23/92
------------------------------------------------------------------------------
DATA:
Here's a little program called "unwho" that deletes all entries for a
given user from utmp. You could probably mogrify it trans what you want.
#!/usr/bin/perl
# This assumes your /etc/utmp file looks like ours
$unname = shift;
open(UTMP,'+</etc/utmp');
@mo = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec);
while (read(UTMP,$utmp,36)) {
($line,$name,$host,$time) = unpack('A8A8A16l',$utmp);
if ($name) {
$host = "($host)" if $host;
($sec,$min,$hour,$mday,$mon) = localtime($time);
printf "%-9s%-8s%s %2d %02d:%02d %s\n",
$name,$line,$mo[$mon],$mday,$hour,$min,$host;
if ($name eq $unname) {
seek(UTMP,-36,1);
print UTMP pack('A8a8A16l', "","","",0);
seek(UTMP,0,1);
}
}
}
------------------------------------------------------------------------------
Comments:
Q's:
Biblio:
CrossRef:
Code/shRef:
==============================================================================
-------------------------------------
To join this group or have your thoughts in the next issue, please
send electronic mail to Tangent at the following address;
infohax
The views expressed in InfoHax Digest
are those of the individual authors only.
*********************
End of InfoHax Digest
*********************
[.nook] 27)
