[asterisk-users] Root Password not taking

[Matt Watson]

On Thu, Jan 22, 2009 at 1:48 PM, Wilton Helm <whelm at compuserve.com> wrote:

>  There have been a number of answers provided.  The one that was given to
> me when I encountered this same problem was to boot a live CD, mount the
> root file system and delete the password file which would force your normal
> distro boot to request a new root password next time.
>

I'd highly recommend to NOT simply delete your password files (/etc/passwd &
/etc/shadow)... you are deleting a lot more than just your compromised your
root password by deleting these files.  You are also deleting every other
account that is on your system (ie. you should be running Asterisk under its
own account and not as root!).  Of course it depends on what other things
are running on your server, but you cannot reasonably expect your distro to
keep track of every change you have ever done to these and re-create it.  It
might give you a skeleton version like you are suggesting, but you are
certainly going to lose data.


Step 3 was replace a few key executables like ps so I couldn't do
> administrative tasks
>

I can't really speak about your case specifically, but generally replacing
certain executables like ps, netstat, login, w, who, etc. etc. are not done
to prevent administrative tasks - infact, a person that actually knows what
they are doing with a rootkit doesn;t actually want to prevent you from
doing administrative tasks.  Generally they don't want you to know at all
that they have broken into your system.  The reason why these binaries get
replaced is to try and cover their tracks.  for example, they replace 'ps'
so that it will not display certain processes running on the system (making
it harder for you to even notice), the same with netstat, it will not
display network connections to certain IPs, 'login' gets replaced with a
version that has a hard-coded login & password that will grant root access
to your system without knowing (or caring) what the real root password is,
and might also not do a few things that are part of the normal login
process... like writing to UTMP / WTMP so there is no record of the login.


The problem is that you don't know exactly what files have been changed and
> if they have left a trap door or something.  You could fix the root
> password, and even discover and restore a few key files, only to find it
> hacked 5 minutes later because you didn't know everything that had been
> altered.  For that reason, few people will put a system back on line after
> the root password has been compromised.  Re-installation is the only safe
> way.  If some of your directories like /home and /user have separate mount
> points, they don't have to get wiped out in the process.
>

This is getting a little off topic... but there actually are ways of
determining exactly which files have been changed.  Stuff like 'tripwire'
has been around for like a decade and is designed to do exactly this...
everytime you run it, it will tell you every single file that has changed.
It does this by creating hash of every file when you run it and then
compares those hashs to previously stored values.  If the hashes do not
match, then something has changed and gets reported.  Of course hashes can
be defeated, it is however not entirely easy, and way beyond what your
typical script kiddie hacker is going to be capable of doing.  And of
course, that is just what trip wire does... there are plenty of other
intrustion detection systems that I;m sure do things a little differently.
Some other things like FreeBSD used to (maybe still does?) come with some
basic security stuff that was installed by default and emailed you daily
reports about things that changed.  Like any new binaries it found on the
system that were setuid root (ie. cp /bin/bash /var/spool/.myhiddenrootshell
; chown root /var/spool/.myhiddenrootshell ; chmod u+s
/var/spool/.myhiddenrootshell).  Something like FreeBSD's scripts were
intelligent enough to find basic things like that.

That being said, I do agree with you, re-installation in 99% of cases is a
superiour option when compared to trying to restore a compromised system.
Typically its much quicker too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090122/26e4aca7/attachment.htm