Date: Tue, 29 Jul 1997 15:44:45 -0700 (PDT) From: Vincent Poy <vince@mail.MCESTATE.COM> To: John-David Childs <jdc@denver.net> Cc: security@FreeBSD.ORG, "[Mario1-]" <mario1@PrimeNet.Com>, JbHunt <johnnyu@accessus.net> Subject: Re: security hole in FreeBSD Message-ID: <Pine.BSF.3.95.970729151209.3844n-100000@mail.MCESTATE.COM> In-Reply-To: <Pine.BSI.3.95.970728231717.25484I-100000@milehigh.denver.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jul 1997, John-David Childs wrote:
=)On Mon, 28 Jul 1997, Vincent Poy wrote:
=)
=)> On Mon, 28 Jul 1997, Jonathan A. Zdziarski wrote:
=)>
=)> =)Hrm if you always use kill -9 try the reverse, just a kill or a kill -15
=)>
=)> I did that too. even kill -HUP only kills the master process. I
=)> had to kill the child process manually.
=)
=)That's what the killall script is for :-)
I know =) But as long as I kill the processes, it wouldn't matter
how I killed it anyways.
=)Since I've finally plowed through the dozens (hundreds? ;-) of messages on
=)the subject...
So much I was like always 2 hours behind ;-(
=)None of my FreeBSD systems have ever installed a /root/.rhosts file to my
=)knowledge, unless it's been a zero length file. I'd have to grok the
=)scripts, but I know for a fact that a FreeBSD install wouldn't know to
=)create a /root/.rhosts that had the name of your other machine in it.
=)Some one of your admins did that luser trick (e.g. to enable rsh/rcp).
I know that after I was looking at the machine. It seems like
when the owner had FreeBSD since whatever version came out in 1994,
none of us were running the machines until Summer 1996 so when our
accounts were created, it came with a .rhosts file. Isn't rsh enabled by
default in inetd.conf?
=)Second, my interpretation of the init man page suggests that securelevel 1
=)would PREVENT me from writing to mounted disks at the time the securelevel
=)1 is "invoked". So, for instance, if I used sysctl to change
=)kern.securelevel from 0 to 1 *right now*, my server processes (httpd,
=)sendmail, etc.) would suddenly blow up because they couldn't write to the
=)disks. Thus, the only time one would want to invoke securelevel 1 would be
=)from /etc/rc before the disks are mounted. Correct???
True.
=)(The rest is dribble mostly directed to Vince, but possibly useful to
=)others).
=)
=)Third, Vince stated something to the effect that Jordan Hubbard couldn't
=)hold a candle to this hacker ("wasn't in the same league") and then posted
=)IRC dribble. I'd bet this hacker couldn't hold a candle to Jordan and
=)probably is just an luser with a copy of rootkit. (Just had to get that one
=)off my mind ;)
My apologies to Jordan but I was not saying it was a FreeBSD
problem all by itself. I as well as others know that FreeBSD is known to
be a very solid system. Back in the old days in 1991 before there was
FreeBSD, 386bsd was out but Linux seemed to be better at that time so I
ran it and even then, as long as the user had a shell account, he just ran
vi and then used virecover and he got root on the machine. I tried the
same trick and it worked too. So it isn't always the core of the OS
itself. Remember FreeBSD from 1.0 all the way to 1995 didn't really have
security problems. During 1996 and 1997, FreeBSD security has sent more
than a few dozens worth of things that are vulnerable. mount msdos and
suidperl were among things that lots of people didn't know about before.
Last year, we were watching a hacker telnet into a FreeBSD machine as root
with the letmein password and we tried it and it worked. One can always
write code that would corrupt the system in some way. Remember I did say
that this user complained about perl not working so I upgraded to
perl5.00401 from perl5.003 which already has a security hole as pretty
much everyone knows. After the perl update was when all of this happened.
I could understand how he hacked mercury.GAIANET.NET since he had a
account from there to begin with. But earth.GAIANET.NET, he absolutely
had no access to in the first place. And even if he sniff, he would never
get the root password correct in the first place. I noticed one thing
about 2.1.7R's password encrytion that beats 2.2 and -CURRENT is that if
you had the number 1234567890 for the root password in 2.1.7R, you had to
type the thing the same way 100% or it will say sorry when you try to su.
With 2.2R and above, I have tried and verify this on a complete new
machine that you can change the 0 at the end to any number and you will
still get root access. What I was basically trying to say was that Jordan
is still one of the best in making a fine solid OS but remember that there
is a old saying of breaking something is easier than fixing it. It takes
just 10 seconds for a earthquake to destroy your house but it takes way
more than that to rebuild it.
=)Fourth, you might as well take that machine off the net (turn it off) if
=)you can't get physical access to it for 2-4 months. It's gone gone gone!
The machine has been off even before you wrote that message ;-)
=)If you've been telnetting to it forever with no encryption, tcpwrappers, or
=)router filters, your hacker could have been on your system for weeks or
=)months before acting up and you wouldn't have a clue...
We had always ran tcpwrappers as well as indentd to verify who and
where each person is coming in from as well as constantly check all
processes every few minutes including the ones running in the background.
The router filters would need some time to learn since it is a FreeBSD
based box and I don't want to do anything that will lock everyone out
since that would defeat the purpose of having a filter. Besides, the
hacker didn't know I was logged in to the machine with 10 shells in the
first place since he only saw one of my un-hidden shells and try to write
me there when he was actively talking to jbhunt. I was tracking him down
in another pty which he deleted netstat already and didn't know I can
replace it and track him down so fast and then added a route to reject
all packets from his ppp connection. We even shut down the machine and
disable everything in inetd.conf except telnet since we need to get back
in but that still didn't stop him when he came back from another
connection and just messed netstat up this time by caching netcom's DNS
on his own machine.
=)A few years ago when I was a weenie (ok, I still am compared to Jordan
=)and Nate and... ;-) I challenged (deliberately) some of my more clueful
=)customers to hack me...one of them was root on my system for almost a
=)month before I noticed suspicious activity. Your descriptions of
=)comparing files between machines (e.g. comparing byte sizes/dates of
=)telnetd) suggest that you never ran anything like tripwire/cops to
=)compute checksums of the files. Thus, you'd have NO clue which files
=)really might have been changed. And if you DID run Tripwire before the
=)hacker, and ran it again after the hacker, but didn't compare the result
=)to a known clean OFFLINE copy of the tripwire database (e.g. a
=)paper/floppy copy)...forget it! :)
There would be no way to compare checksums of files anyways since
these machines were both running -CURRENT and each revision of -CURRENT
would have different checksums anyways.
Cheers,
Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
GaiaNet Corporation - M & C Estate / / / / | / | __] ]
Beverly Hills, California USA 90210 / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970729151209.3844n-100000>