alex@umbc3.UMD.EDU (Alex S. Crain) (12/10/88)
Something of interest to the netlanders..... Ok, here's ths story. I arrive home very late yesterday, and before going to sleep I check for mail on nerwin, my 3b1. Nothing interesting, so I get out of mail and soemthing doesn't feel right, so I start up mail again, but mail responds with No mail for ubluit. since ubluit is not my login, I start to wonder, and when ls comes back with /bin/ls: not a directory I really get worried. I discover that I can get to /usr/* but /bin is gone and /etc dissapears afters minute. I go to reboot the machine, but its too late because / no lnger exists, not evern a boot track. I reboot from the floppy, the hard disk is unmountable, so I shut the thing off and go to bed wondering. Now a couple of things figure in here. On the one side: I've been screwing around with the kernal, and my mailer program had been known to trigger my mistakes, so I might have hosed myself. But its never happened before like this, and usually I just trash the freelist, and my error is *always* "inode > 2^24", which kills the machine instantly. This time, the machine worked for a little while, and faded, losing directories, as if there was /etc/mkfs in background. On the other side... ubluit is a very interesting name to pop out of nowhere. I have no users with that name, nor any user programs, nor have I ever seen anything like that before. I find it very coincidential that it should become my login id just before the machine died. Naturally, I don't have any uucp records. but I don't allow dialins, so all traffic goes via umbc3.umd.edu. umbc3's LOGFILE has an entry uucp uunet (12/9-4:36-13470) daemon X.uunetCvPQ3 XQT (PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin;export PATH;rmail nerwin!alex ) I'm not sure what this says, but I do know that the machine died about 4:30 am on 12/9, and I haven't sent any mail for several days. Can some uucp guru explain exactly what this message means? Normally I'm not very paranoid, and I don't keep a password on root, but in light of all the accusations of software tamering, I can't rule out the possibility of sabatoge. The unixpc is notorius for security loopholes, so I suppose someone could have set a trogen horse in the mailer (why I don't know). I suppose its possible that some things I've said might have pissed off the wrong people. I realize that this is a delicate situation, and I would certainly not accuse anyone without much more evidence then this, which is circumstancial at best. Unfortunatly, nerwin's files are completely gone, so theres nothing there, but I can get to umbc3's files (umbc3 is a VAX running 4.2). Is there anything that I should look at to try tracing nerwins last communications? Thoughts are appreciated... -- :alex Alex Crain Systems Programmer alex@umbc3.umd.edu Univ Md Baltimore County nerwin!alex@umbc3.umd.edu
thad@cup.portal.com (Thad P Floryan) (12/11/88)
Just one quick comment about Alex Crain's dilemma ... that new "user id" under which his system died is suspiciously like a prank. Say it phonetically (i.e. ``ubluit''): You Blew It Unless that's an inside joke in the kernel (like the "Guru Meditation Alert" for a system crash on the Amiga), it would appear someone DID penetrate Alex' system and inflict a trojan horse. Just a thought ... Thad Floryan [thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad]
dtynan@sultra.UUCP (Der Tynan) (12/13/88)
First off, at the moment I don't own a 3B1, nor have I ever seen one, but I
hope to change all that pretty soon :-)
Anyway, if you are running vanilla AT&T rmail (or even smail2.5), then nothing
can creep in via rmail. I have looked at this code, and am pretty confident
there is nothing there that could grab you. However, if you received a Trojan
Horse from somewhere, it could have been kicked off by the incoming mail.
Perhaps there was some keyword in there, that the TH wanted. This could have
come from one of two places. A/ Downloading a 'uuencoded' binary (*always*
a bad idea), or B/ not checking source-code (a quick scan of the code can
usually reveal any nasties). Given the user name (ubluit), I would be *very*
suspicious. However, I am unsure as to how you found the new ID. For example,
if 'mail' can't find your name in /etc/passwd, sometimes it will default to
"???" or some other such name. Did you perhaps, leave yourself logged in
over a period of time? In which case, did anyone have access to the machine?
One other thing to check on umbc3 (the remote machine) is the size of the
file which was transferred. This is available in /usr/spool/uucp/SYSLOG.
Usually, mail is fairly small (1 -> 2k on the average). If the file
transferred is reasonably big, then this is also suspicious. If the disk
is unbootable, it sounds like the superblock was corrupted, as opposed to
just being empty. Usually, a nasty invader will delete all the files, as
opposed to destroying the superblock. It could be possible that your kernel
hacking just bit you, but then again, it's hard to tell. As a final (and
important) note, DO NOT re-initialize or re-format your disk. Unless the
program did a physical format of the disk (which I doubt), your data is
still where it always was. On the disk. Deleting a file only updates the
inode table, and the superblock. The file itself is left on the disk. One
thing I have done it the past, is make a "poor mans backup". To do this,
use 'dd if=/dev/hd', where 'hd' is your hard disk, pipe it through 'vol' or
equivalent, and send it to the disk drive. This will probably take about
60 disks, but it will be worth it. dd shouldn't care whether or not the
hard disk has a valid filesystem. Then, rebuild your hard disk. Now you
have a set of disks, which have all your files (granted, they're scattered
across the disks). You can thus regenerate your most important files. Hope
this helps.
- Der
--
dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers)
{apple,mips,pyramid,uunet}!Tynan.COM!dtynan
--- Send me flames, and I'll give your name and address to Scientology ---jbm@uncle.UUCP (John B. Milton) (12/13/88)
In article <1430@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: >Ok, here's ths story. I arrive home very late yesterday, and before >going to sleep I check for mail on nerwin, my 3b1. Nothing interesting, >so I get out of mail and soemthing doesn't feel right, so I start >up mail again, but mail responds with Just what do you mean by "doesn't feel right"? Was it too slow? > No mail for ubluit. Thad already mentioned the ubluit == You Blew It >since ubluit is not my login, I start to wonder, and when ls comes >back with > > /bin/ls: not a directory Yup, this means trouble. >I really get worried. I discover that I can get to /usr/* but /bin is >gone and /etc dissapears afters minute. I go to reboot the machine, >but its too late because / no lnger exists, not evern a boot track. I >reboot from the floppy, the hard disk is unmountable, so I shut the >thing off and go to bed wondering. It sounds like the disk was being erased from the beginning of /dev/rfp002. Actually it sounds like it was being filled with "ubluitubluitubluit..." > Now a couple of things figure in here. On the one side: > > I've been screwing around with the kernal, and my mailer Like what have you been doing? Patching things with loadable drivers? >program had been known to trigger my mistakes, so I might have hosed >myself. But its never happened before like this, and usually I just >trash the freelist, and my error is *always* "inode > 2^24", which >kills the machine instantly. This time, the machine worked for a >little while, and faded, losing directories, as if there was /etc/mkfs >in background. > ubluit is a very interesting name to pop out of nowhere. I >have no users with that name, nor any user programs, nor have I ever >seen anything like that before. I find it very coincidential that it >should become my login id just before the machine died. Ah, yeh, I would say that. > Naturally, I don't have any uucp records. but I don't allow >dialins, so all traffic goes via umbc3.umd.edu. umbc3's LOGFILE has an >entry Are you absolutely sure? >uucp uunet (12/9-4:36-13470) daemon X.uunetCvPQ3 XQT >(PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin;export PATH;rmail >nerwin!alex ) >I'm not sure what this says, but I do know that the machine died about >4:30 am on 12/9, and I haven't sent any mail for several days. Can >some uucp guru explain exactly what this message means? Sorry, I can't help you out with this one, but this looks like a remote mail uux request. [paranoid, no root pass wrong people delicate] Right now, get a snap shot of ALL the nerwin related uucp files for later analysis. Did you remove write permission from /? When you read your mail, did you use the [Msg] key, type mail directly? Do you have old style UUCP, or HDB UUCP? What commands did you have in your L.cmds/Permissions file? (sorry to speak about your system in the past tense...) Keep that disk! There may still be lots of good info left. It could be mounted as the second disk (um, once I get my board out...) and dumped/examined. What was in your USERFILE? Can you stat the disk from the diagnostics: 1. Boot diags 2. enter s4test 3. enter 6,12 Does it print an page of info, or give you an error? MORE INFO! John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?
alex@umbc3.UMD.EDU (Alex S. Crain) (12/14/88)
I've gotten several replies, none of which are terribly helpful (although I sincerily appreciate the effort.) 1) This sounds a bit wierd, but I'm not really bothered by the fact that my disk was hosed. Fortunately My schoolwork was on another machine, and other then that I haven't really been doing much. I figure that I'll be back to normal by Febuary at the latest, and this gives me a chance to puruse my file structure and move things around a little bit. 2) I can't wait till I get another disk, so I reformatted the one I had. I doubt that I really lost much, because I've been running with between 1 and 6 Mb free for awhile, and the disk was getting seriously fragmented. The idea of picking through 70Mb of fragmented disk blocks is not appealing. 3) I wasn't running any of the obvious security holes with the exception of no root password. Ther are 3 user accounts on my machine, one is root and two are me. Since the machine has no other users (ever) I don't worry about security much. But I do leave protections intack to prevent hosing myself when running multiple gettys. so / is 755, etc. 4) So, my real question was how to trace UUCP mail, if possible. If I got hosed through mail, I would like to find out who did it, if only to publicly identify them and warn future victims. Since I can only sortof read uucp LOGFILEs, I don't really know what to look for. I am certain that If I got hosed by someone other then me, it came through mail. I normally would have blamed myself for this, and let it slide, but between ubluit and the accusations that have passed through this newsgroup lately, I figured that I should say something. BTW: Some time ago, a friend of mine came up with a scheme for loadable system calls by extending the syslocal() facility. It works fine, although some of the new system calls (notably ftruncate()) still have bugs and will occationally barf. It's possible that I could have started a program that used ftruncate(), and then hosed my self, but I'm pretty careful about such things. -- :alex Alex Crain Systems Programmer alex@umbc3.umd.edu Univ Md Baltimore County nerwin!alex@umbc3.umd.edu