SEO

I have a 3-yr-old child whose password is the same as his username
(michael/michael). This is done because he is able to type that in to
log in and play a couple of simple games, tuxpaint, kids.pbs.org, etc.

Of course, such a password is really bad for a machine connected to the
Internet. The only firewall hole I have punched is for ssh, port 22,
and I've set up /etc/pam.d/sshd to have

auth required pam_listfile.so onerr=fail item=user
sense=allow file=/etc/sshd.allow

and /etc/sshd.allow to have only my account:
lenny


This has always worked for me, with my account & strong password
being the only way into the box from the outside.

A few days ago, I noticed that my son's password had been changed. I
figured he must have clicked on a dialog to change it from his desktop,
so I changed it back. A few days later, I noticed bandwidth and cpu
usage spiked from procs running under his ID that I don't recognize. I
noticed that someone had installed priv8, scann, and a couple of other
rootkit/tarballs in his home directory, and is using them to try to get
control of other machines. Luckily, the attacker wasn't able to
compromise anything else on the system -- they weren't able to get a
local root elevation and the system is otherwise (verifiably) intact
(thank you rpm -Va!). I changed his password and can now see attempts
at getting in via ssh fail. No more abnormal activity on the box.

Somehow, my pam.d configs don't seem to work anymore -- sshd allows
any local user in except those excluded in /etc/ssh/sshd_config
explicitly (i.e., root). What would cause this? This all seemed to
stop working when I upgraded from Fedora Core 3 to FC4, and try as I
might to twiddle pam.d settings and restart services, they seem to be
ignored. How can I check to see that pam is working? What else could
be wrong? I'd really like to go back to only allowing myself in from
the outside...

Thanks,
Lenny.

27 Sep 2005 20:34 UTC, Lenny G. typed:
[snip]
> Somehow, my pam.d configs don't seem to work anymore --

If you have no way of knowing what has been changed, it might be a good
idea re-install.

Lenny G. <alengarbage@yahoo.com> wrote:

[Intruders entered via a guessed username/password pair.]

> Luckily, the attacker wasn't able to compromise anything else on the
> system -- they weren't able to get a local root elevation and the
> system is otherwise (verifiably) intact (thank you rpm -Va!).

You sure about that?

1. "rpm -Va" only verifies that a bunch of package-owned files'
md5sums match those on record in the BerkeleyDB files in /var/lib/rpm.
A smart intruder will update the database records to match his meddling.

So: Did you bother to compare /var/lib/rpm/* against a copy stored
on write-protected or offline media? Otherwise, your assurance is a
little fragile -- and being wrong with confidence (about system
security) is often much worse than merely not knowing.

A guy I shave every morning once referred to this query (how do you know
within reasonable certainty that one has _not_ been compromised) as an
"Excellent question." See: http://linuxgazette.net/issue98/moen.html

2a. My recollection is that that check compares the hashes of files
installed from the RPMs, but there's no provision for checking
security-sensitive files that weren't provided by the packaging system.

2b. My recollection is that the check also excludes many (all?) package
configuration files; otherwise, there would be lots of false positives
caused by normal sysadmin-created local machine configuration data.

You have to make a judgement call as to whether you think your system
has been root-compromised. Tough one. It might help to install your
distro onto a second machine and compare all the PAM-related files you
can find, between the hosts.

Personally, if I had any doubt, I'd secure all data files, the names of
installed packages, and a tarball of /etc, rebuild from trusted media,
apply security updates before connecting to public networks, restore
data files, manually rebuild local machine state by reference to (but
not copying files from) the reference tarball of /etc, and finally allow
the users back in with changed passwords and a heart-to-heart chat.

And I'd also install & configure a file-based IDS, rather than just
relying on "rpm -Va" in the future.

--
Cheers, Founding member of the Hyphenation Society, a grassroots-based,
Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed,
rick@linuxmafia.com modern-American-English-usage-improvement association.

Rick Moen <rick@linuxmafia.com> wrote:
> Lenny G. <alengarbage@yahoo.com> wrote:

> [Intruders entered via a guessed username/password pair.]

>> Luckily, the attacker wasn't able to compromise anything else on the
>> system -- they weren't able to get a local root elevation and the
>> system is otherwise (verifiably) intact (thank you rpm -Va!).

> You sure about that?

Yes - it does sound a little as though he has an adore module
installed. He DOES want to boot from a live cd, get chkrootkit,
and run it on the disk, mounted under /mnt.

He wants to avoid his normal init sequence, as the files will have been
doctored to install the module at each boot. A simple ls -lr on the
init scripts can show the trail, but it's generally sysklogd's script
which has had the extra lines added.

> 2b. My recollection is that the check also excludes many (all?) package
> configuration files; otherwise, there would be lots of false positives
> caused by normal sysadmin-created local machine configuration data.

Makes sense. But if it's an adore module the checksums will be correct
anyway. Neither he nor the chechksummer will see the REAL files.

> You have to make a judgement call as to whether you think your system
> has been root-compromised. Tough one. It might help to install your
> distro onto a second machine and compare all the PAM-related files you
> can find, between the hosts.

Only after avoiding his own init sequence!

Peter

Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:

> Yes - it does sound a little as though he has an adore module
> installed. He DOES want to boot from a live cd, get chkrootkit,
> and run it on the disk, mounted under /mnt.

Les, what Peter's saying is that he suspects the intruder used his
remote ssh access to the "michael" account to crack root access (some
privilege escalation or other), and then installed trojan-horse
code as a Linux kernel module -- which, while running in kernelspace
on your system, will not show up in runtime checks and can act to
protect itself against discovery. He therefore suggests booting a
known-uncompromised Linux boot disc (such as a Knoppix disc), mounting
your HD's filesystems to make them accessible, and then -- while you're
sure that _nothing_ from your HD has been loaded into RAM and executed
-- running a pattern-checking "rootkit detector" such as chkrootkit or
rkhunter (or both) to search your HD known instances of intruders' bad
juju.

One of the implications to note from the above is that, unless you're
_really_ good at system administration, your system probably harbours a
number of local vulnerabilities usable for escalation from regular-user
to root authority. When intruders break into your system masquerading
as a legitimate user (e.g., the guy who broke in as michael/michael on
yours), he/she will probably run, in his/her first ten minutes, a canned
toolkit that tries, rapid-fire, a dozen or two recently popular
local-escalation techniques. All he/she needs is _one_ achieving
success, then a rootkit (such as the "LKM" = Linux kernel module-type
rootkit Peter alluded to) goes in to hide his/her presence from you,
from that point forward.

> He wants to avoid his normal init sequence, as the files will have been
> doctored to install the module at each boot. A simple ls -lr on the
> init scripts can show the trail, but it's generally sysklogd's script
> which has had the extra lines added.

And you might want to look there and elsewhere in /etc/init.d/ , to see
if something stands out. As I mentioned before, the "excellent
question" is how much scrutiny of your system is enough, before you
can reasonably decide it's _not_ compromised.

As you'll see if you read my (aforementioned) _Linux Gazette_ article,
installing and diligently configuring a file-based IDS _before_ you
suspect you have an intruder is one way to deal with that problem.

> Makes sense. But if it's an adore module the checksums will be correct
> anyway. Neither he nor the chechksummer will see the REAL files.

What Peter is saying is: _If_ there's an LKM rootkit, then it's in a
perfect position (_if_ and only if you boot through your normal boot
sequence as opposed to booting a Knoppix disc) to make your scrutiny of
your system pointles -- by causing it to lie to you and tell you nothing
bad was found.

That's why he stressed _not_ booting your system as part of checking it.

Me, I still go back to what I was saying previously: If you have _any_
reason to think your system might be compromised, then assume it is and
do a clean rebuild as I outlined earlier. It's painful, but not as
painful as realising that, say, yoru entire system and everything in or
out of or on it has been spied on, interfered with, and/or corrupted by
unauthorised personnel.

Adjust your paranoia to suit local norms. ;-> But don't forget that,
999 times out of 1000, the intruder neither knows nor cares about you or
your affairs: Odds are, the entire process of intrusion was the
activity of completely automated attack scripts strobing up and down
publicly accessible IP addresses. (Thus, don't ever relax your guard
on grounds of "I'm not significant enough to attack.")

--
Cheers, Mark Moraes: "Usenet is not a right."
Rick Moen Edward Vielmetti: "Usenet is a right, a left, a jab,
rick@linuxmafia.com and a sharp uppercut to the jaw.
The postman hits! You have new mail."

"Chiefy" <lgb@non.existent.invalid> wrote in message
news:slrndjjgjo.6m5.lgb@aztec.eclipse...
> 27 Sep 2005 20:34 UTC, Lenny G. typed:
> [snip]
>> Somehow, my pam.d configs don't seem to work anymore --
>
> If you have no way of knowing what has been changed, it might be a good
> idea re-install.

Agreed. The rootkit weasel may have changed your libraries to mis-report
checksums or created libraries that RPM doesn't know about.

Next time, configure your SSH to only allow access to specific accounts, or
to block specific accounts such as your son's. And if you have the chance,
please contact the administrators of the site that the attack is coming
from. They've probably been root-kitted too, or at least may want to slap
the script kiddie for misusing their resources.

On Wed, 28 Sep 2005 07:14:35 +0200, Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:

> Rick Moen <rick@linuxmafia.com> wrote:
>> Lenny G. <alengarbage@yahoo.com> wrote:
>
>> [Intruders entered via a guessed username/password pair.]
>
>>> Luckily, the attacker wasn't able to compromise anything else on the
>>> system -- they weren't able to get a local root elevation and the
>>> system is otherwise (verifiably) intact (thank you rpm -Va!).
>
>> You sure about that?
>
> Yes - it does sound a little as though he has an adore module
> installed. He DOES want to boot from a live cd, get chkrootkit,
> and run it on the disk, mounted under /mnt.

I just want to add my voice, seconding Peter and Rick.

Some years ago when I got my first ADSL connection, I was also
in the process of installing a new OS, and I left the system unguarded
with no firewall for a few hours.

I can't remember how I discovered it, but I remember being frustrated
because I could not find out what was going on. The rootkit had replaced
/bin/ls and /bin/ps and a host of other files, so the foreign processes
and files were not reported, and the replaced files were lied about.

Fortunately, the toolkit was not that advanced (and this was about 1999),
and /proc and /sbin/lsof still worked normally. You can hardly imagine
my surprise and confusion when files and processes began appearing
in /sbin/lsof, and were consistently absent in ps and ls.

After that I have often thought about how rootkits gradually evolve and
become more and more sophisticated, since they are not built from scratch
but they evolve the same ways as other advanced software packages.

So, when I read "thank you rpm -VA", I immediately thought "but how
can you be so sure!" I have come to the same conclusion as the others,
you must boot an independent medium that the potential intruder
has not had any chance to modify, at least not through *this* intrusion.

Of course, your observation that the intruder has later failed to
get in through Michael's account gives some probability that he was
not that sophisticated after all, but you cannot be sure of that.
There seems to be enough incentives for the croocks to become rather
professional, and their automated systems are probably responsible
for the majority of the attacks.

-Enrique

Enrique Perez-Terron <enrio@online.no> wrote:

> So, when I read "thank you rpm -VA", I immediately thought "but how
> can you be so sure!" I have come to the same conclusion as the others,
> you must boot an independent medium that the potential intruder
> has not had any chance to modify, at least not through *this* intrusion.

The Tripwire file-based IDS attempts to provide _some_ protection
against subversion of the IDS itself through a very pervasive
cryptographic signing and verification routine. They _still_ recommend
that you keep the signatures database and other key components on
write-protected media, but even without that it's impressively
tamper-resistant. (Like other such crypto regimes, it only works
properly if you both use it diligently and understand its design and
limitations -- which in its case is quite a chore, indeed.)

> Of course, your observation that the intruder has later failed to
> get in through Michael's account gives some probability that he was
> not that sophisticated after all, but you cannot be sure of that.

Or _more_ sophisticated.

Intruders have a couple of immediate aims, upon breaking into a system:
They want to draw a net of invisibility over their presence (thus,
rootkits), to make it less likely that the administrator and other
legitimate users will notice their presence -- and they want to set up
numerous backdoor methods of re-entry that they can fall back on, if the
legitimate users _do_ notice the intrusion.

Thus, the fact that the "intruder later failed to get in through
Michael's account" could mean he/she (or, more likely, his/her automated
script managing his stable of zombified remote hosts on his/her behalf)
attempted re-entry through Michael's login, failed because you changed
his password, and then immediately crossed _that_ method of entry to the
system off the list, and switched to others in order to lull the admin
back into complacency.

That would be the smart thing a bad guy would do.

The key thing to remember is that, _if_ you decide it's reasonably
likely that a system has been root-compromised, you cannot any longer
trust anything it contains (or does). Changing Michael's password may
have simply reduced the intruder's number of paths into your system to
n-1 for some large value of n.

> There seems to be enough incentives for the croocks to become rather
> professional, and their automated systems are probably responsible
> for the majority of the attacks.

And also remember: _One_ smart, competent author of cracking scripts
can and frequently does sell or give his offerings to thousands of
otherwise inept and brainless intruders. The actual guy who rooted your
system doesn't have to possess Clue One.

On Wed, 28 Sep 2005 23:48:50 +0200, Rick Moen <rick@linuxmafia.com> wrote:

> Enrique Perez-Terron <enrio@online.no> wrote:
>
>> So, when I read "thank you rpm -VA", I immediately thought "but how
>> can you be so sure!" I have come to the same conclusion as the others,
>> you must boot an independent medium that the potential intruder
>> has not had any chance to modify, at least not through *this* intrusion.
>
> The Tripwire file-based IDS attempts to provide _some_ protection
> against subversion of the IDS itself through a very pervasive
> cryptographic signing and verification routine. They _still_ recommend
> that you keep the signatures database and other key components on
> write-protected media, but even without that it's impressively
> tamper-resistant. (Like other such crypto regimes, it only works
> properly if you both use it diligently and understand its design and
> limitations -- which in its case is quite a chore, indeed.)

What about the tripwire binary?

-Enrique

Enrique Perez-Terron <enrio@online.no> wrote:

> What about the tripwire binary?

Going from memory: The Tripwire binary, when started, calculates its
own md5sum and compares it against the one on record in the (signed,
encrypted) signatures database.

The next in a long series of possible questions you would then want to
ask me is how that system defends against an intruder who replaces the
Tripwire binary with one that merely pretends to recheck its md5sum
hash, and reports that it matches and is thus OK even though it isn't.

My recollection of the answer to that is even more vague: At least part
of it is a recommendation that you regularly reverify the integrity of
_all_ the important files using your private key on a different system
(e.g., the place where you receive Tripwire's signed, encrypted reports
via e-mail). Plus they recommend that you keep that binary on
write-protected storage.

The questions and answers go on at considerable length. For instance,
one of the obvious attack vectors would be to sabotage the system
crontab entry that causes Tripwire to generate, encrypt, sign, and
e-mail a report. So, you're admonished that, if you suddenly aren't
receiving reports when they're expected, watch out!