Strange command histories in hacked shell history

Bill Vermillion bv at wjv.com
Sat Dec 18 08:08:38 PST 2004


Let me just comment on two items that are in the thread which I
seem to have caused to get a bit long.

On Sat, Dec 18, 2004 at 12:01 , while impersonating an expert on 
the internet, freebsd-security-request at freebsd.org sent this to stdout:


> ------------------------------

> Message: 4
> Date: Fri, 17 Dec 2004 10:51:35 -0500 (EST)
> From: "Jerry Bell" <jerry at syslog.org>
> Subject: re: Strange command histories in hacked shell server

> Did I understand correctly, that anyone can connect to the shell server
> and create an account for themselves?

> I have a somewhat rudimentry hardening guide for FreeBSD at
> http://www.syslog.org/Content-5-4.phtml

> I've tried to keep it up-to-date, but I have yet to incorporate
> IMAC, which think will help out a good bit more.

> I hope you find this a useful.

I do agree with that, espeically the first paragraph " ... no
matter how paranoid your philsophy ..."

I have had one instance of an attempt was I had missed one machine
out of about 8 applying one security patch.  All were patched
within hours, the one that got hit was 2 days later.  You have to
get to any patches as soon as the hole becomes known.

And my machines are pretty accessable to the world being on a
backbone.  One machine was getting about 300,000 spams/day until
I finally took off all MX for that domain. If anyone has problems
they need to perform a whois and use those contacts.  It's one of
those domains whose name alone drives it up the list.

I haven't set the security levels high as that means that any
problems would require driving to the colo - and that's about
1/2 hour at 3AM - and two to three times higher during the daylight
hours.   

...

> Message: 9
> Date: Fri, 17 Dec 2004 22:13:47 -0600
> From: Elvedin Trnjanin <mnsan11 at earthlink.net>

And Elvedin wrote in reply to my post where I wrote:

> >This means that the 'wheel' security really is nothing more
> >than a 2 password method to get to root.

> Precisely. If you don't like this then the way around is to only
> allow a certain group access to su and none for everyone else.

That thought had not crossed my mind. Craig also mentinoed that.
[his comment follows].

> >If the EUID of the orignal invoker is checked, even if they su'ed
> >to a person in wheel, then they should not be able to su to root.

> >I'm asking why is this permitted, or alternatively why is putting a
> >user in the wheel group supposed to make things secure, when in
> >reality it just makes it seem more secure - as there is only one
> >more password to crack.

> One more password to crack is more time which means a better
> chance of catching the cracker in the act. Although I don't know
> why exactly the authors of su did that the way they did but my
> first and best guess would be convenience. The two password
> method is better than a new login session each time you want
> to get to root. Second best guess would be is that they didn't
> figure out that issue or at least think much of it.

One more password to hack does make it harder, but in a paranoid
mode if someone did break a password of a wheel user, then they
have a root password to break.  I'd just as soon them not have that
ability at all.

I'm concerned about some application turning out to have an unknown
hole and someone wandering around before they are found. 

It seems there are tons of attempts on sshd logins in the past few
months, but I'm thinking that if some app breaks then that person
could perhaps su to a local person that is in wheel.

Your idea of changing su to be only executeable root and user in
group wheel may be just what I need. I may be overly paranoid, but
in this day and age you can't be too secure.

The one penetration that I had three years ago on one non-critical
machine was one more than I'd have like to have had.

There are a total of 4 people who have wheel accounts, and 
one person has a set of sudo command so he can edit his own private
set of sendmail aliases, primarly for a large mailing list he
maintains, but other than that it's locked down pretty well.
As above I'm concerned about some unknown hole in an app giving
someone a chance locally.   

> ------------------------------
> Message: 12
> Date: Sat, 18 Dec 2004 11:45:45 +0000
> From: Craig Edwards <brain at winbot.co.uk>

> You could change the permissions on the su binary, so that only
> users in the wheel group can even execute su. that way, when a
> non-wheel user attempts to su to a user in the wheel group, they
> simply get permission denied.

That's one that had not crossed my mind.  I will probably do that.

> The idea of chmod'ing your suid binaries is always good in my
> opinion, and will stop this from happening simply and easily
> without having to change any code.

Which is very good.  The fewer things modified the fewer things to
get missed on system upgrades.

Thanks to all who responded.

Now my only unanswered question has to do with why su was designed
like this originally.  Those reasons are probably lost somewhere in
history.  But now I can ease some of my paranoic worries at least
by changing su.

Bill

-- 
Bill Vermillion - bv @ wjv . com


More information about the freebsd-security mailing list