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,???}/ 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'. "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: "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 , where is the TCP port (decimal) on the target (server) system, and is the TCP port (decimal) on the source (user) system. For example: 23, 6191 The response is of the form , : : where , are the same pair as the query, is a keyword identifying the type of response, and 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, 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 could not be determined, tells why. The following are suggested values of 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 ::= ::= "," ::= ::= | ::= ":" ERROR ":" ::= ":" USERID ":" ":" ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR ::= 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,'+