Is this evidence of a hack? - Security

This is a discussion on Is this evidence of a hack? - Security ; Hello, I have noticed that the owner of the file 'ls' is not root and is '122' in group '114', is this normal in Fedora 4? I have not changed it from default... I tried to change ownership back to ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Is this evidence of a hack?

  1. Is this evidence of a hack?

    Hello,

    I have noticed that the owner of the file 'ls' is not root and is '122'
    in group '114', is this normal in Fedora 4? I have not changed it from
    default... I tried to change ownership back to root - but this was not
    permitted... Any ideas?

    I believe that because of this I'm having a problem updating my current
    version of core utils to
    coreutils-5.2.1-48.1.i386.rpm - taken from the fedora updates page and
    I am encountering the following error...

    # rpm -Uvh coreutils-5.2.1-48.1.i386.rpm
    warning: coreutils-5.2.1-48.1.i386.rpm: V3 DSA signature: NOKEY, key ID
    4f2a6fd2

    Preparing... ###########################################
    [100%]
    1:coreutils ###########################################
    [100%]
    error: unpacking of archive failed on file /bin/ls: cpio: rename failed
    - Operat
    ion not permitted

    I am using fedora 4 on intel platform... The same process failed in the
    past when trying to use up2date... There is no version of yum currently
    installed on the box...

    Has anybody encountered this problem before? Any idea how to resolve?

    Best Regards,

    Mark Starmer


  2. Re: Is this evidence of a hack?

    > I have noticed that the owner of the file 'ls' is not root and is '122'
    > in group '114', is this normal in Fedora 4? I have not changed it from
    > default... I tried to change ownership back to root - but this was not
    > permitted... Any ideas?


    What says lsattr `which ls`? Do you use SELinux?


  3. Re: Is this evidence of a hack?

    > I tried to change ownership back to root - but this was not
    > permitted... Any ideas?


    What says lsattr `which ls`? Do you use SELinux?


  4. Re: Is this evidence of a hack?

    markstarmer@markstarmer.co.uk writes:

    >Hello,


    >I have noticed that the owner of the file 'ls' is not root and is '122'
    >in group '114', is this normal in Fedora 4? I have not changed it from
    >default... I tried to change ownership back to root - but this was not
    >permitted... Any ideas?


    Yes, you have been hacked.
    Do
    lsattr
    if the i attribute is set, you have definitely been hacked ( that is why
    root cannot change it. That is the immutable flag. )


    Backup all of your own important files, wipe the disk, and reinstall.
    restore the backup, and then search for suid sgid programs.
    find / -perms +6000 -ls

    MAKE SURE that they are supposed to be suid/sgid.
    (for example no file in a home, tmp,dev,man,share directory should be suid.
    )




    >I believe that because of this I'm having a problem updating my current
    >version of core utils to
    >coreutils-5.2.1-48.1.i386.rpm - taken from the fedora updates page and
    >I am encountering the following error...


    ># rpm -Uvh coreutils-5.2.1-48.1.i386.rpm
    >warning: coreutils-5.2.1-48.1.i386.rpm: V3 DSA signature: NOKEY, key ID
    >4f2a6fd2


    >Preparing... ###########################################
    >[100%]
    >1:coreutils ###########################################
    >[100%]
    >error: unpacking of archive failed on file /bin/ls: cpio: rename failed
    >- Operat
    >ion not permitted


    Yup -- the immuatable attribute.


    >I am using fedora 4 on intel platform... The same process failed in the
    >past when trying to use up2date... There is no version of yum currently
    >installed on the box...


    >Has anybody encountered this problem before? Any idea how to resolve?


    >Best Regards,


    >Mark Starmer



  5. Re: Is this evidence of a hack?

    On 6 Jun 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1149594363.557580.281210@g10g2000cwb.googlegroups. com>,
    markstarmer@markstarmer.co.uk wrote:

    >I have noticed that the owner of the file 'ls' is not root and is '122'
    >in group '114', is this normal in Fedora 4?


    Well, let's start out by disconnecting this box from the network RIGHT NOW.
    No, that is not normal. Which 'ls' are we talking about? '/bin/ls' (and
    indeed _everything_ in /bin/) should be owned by root, and very few items
    in that directory should be a group other than root (there are a few
    exceptions, such as '/bin/mail and /bin/setserial).

    >I have not changed it from default...


    Something sure as hell did

    >I tried to change ownership back to root - but this was not
    >permitted... Any ideas?


    man chattr which is a _really_ bad sign - look at the 'i' flag
    man lsattr and see what extended attributes are set.

    >error: unpacking of archive failed on file /bin/ls: cpio: rename failed
    >- Operation not permitted


    That's a REALLY bad sign. Quick and dirty check 'rpm -Va > files.2.check'
    which _may_ detect bad stuff if rpm and the rpm databases haven't been
    altered. A second check

    /usr/bin/find / -type f -perm -111 -exec /usr/bin/lsattr {} \; > /some.file

    should not show any files with attributes set. (This command will take a
    moderately long time to run - the redirection to a file is so that you can
    then parse the file ignoring the banners and unset files). Again, this
    command assumes that '/usr/bin/find' and '/usr/bin/lsattr' haven't been
    altered.

    The reason the username/group is showing numbers instead of 'root:root' is
    that this file is owned by a user ID _OTHER_THAN_ a person listed in the
    /etc/passwd file. This raises grave concerns - how the fsck did the file
    get into /bin/ which should be owned by root:root, and NEVER be writable
    by anyone except the owner (drwxr-xr-x). Likewise, no one other than root
    should be able to use the chattr and chown commands.

    Has this system been unmaintained and exposed to the world? The package
    you are trying to install (coreutils-5.2.1-48.1) came out ten months ago,
    and there certainly are other packages that should be installed to prevent
    problems.

    >I am using fedora 4 on intel platform... The same process failed in the
    >past when trying to use up2date... There is no version of yum currently
    >installed on the box...


    If things were failing in the past, did anyone investigate why? Things
    really don't randomly fail for no reason at all.

    >Has anybody encountered this problem before?


    Yes - hundreds of times

    >Any idea how to resolve?


    From: CERT Advisory
    Newsgroups: comp.security.announce
    Subject: CERT Summary CS-98.06
    Date: 11 Jun 1998 20:05:13 GMT

    Web Results 1 - 10 of about 482 for CERT Summary CS-98.06. (0.58
    seconds)

    You can find that document on the web. Read section 3.

    Old guy

  6. Re: Is this evidence of a hack?

    Unruh wrote:

    > markstarmer@markstarmer.co.uk writes:
    >
    >>Hello,

    >
    >>I have noticed that the owner of the file 'ls' is not root and is '122'


    > Yes, you have been hacked.


    >
    > Backup all of your own important files, wipe the disk, and reinstall.


    Whoa! Before you wipe the disk, note the size and date of any compromised
    program - use the information to help identify a safe backup!

    C.


  7. Re: Is this evidence of a hack?

    Colin McKinnon writes:

    >Unruh wrote:


    >> markstarmer@markstarmer.co.uk writes:
    >>
    >>>Hello,

    >>
    >>>I have noticed that the owner of the file 'ls' is not root and is '122'

    >
    >> Yes, you have been hacked.

    >
    >>
    >> Backup all of your own important files, wipe the disk, and reinstall.


    >Whoa! Before you wipe the disk, note the size and date of any compromised
    >program - use the information to help identify a safe backup!


    ??? and how is he to do that? His system is comprimized. The tools on his
    system are unreliable.



    >C.



  8. Re: Is this evidence of a hack?

    Unruh wrote:


    >
    >>Whoa! Before you wipe the disk, note the size and date of any compromised
    >>program - use the information to help identify a safe backup!

    >
    > ??? and how is he to do that? His system is comprimized. The tools on his
    > system are unreliable.
    >
    >
    >
    >>C.


    Getting a set of trustworthy tools is trivial - use your choice of live
    distro. Getting correct file size/date information, on the other hand, is
    np-trivial. That problem breaks down as follows:

    1. identify all system-critical files by name, version, date and source.
    2. obtain locate the correct version and date of each of those files,
    according to their respective sources.
    3. compare all files one - to - one, matching on the name, examining for
    differences in name, version and date. Oh, and don't let's forget the
    trivial detail of owner/group/permissions.

    You get going on that, and I'll see you back here in a couple or five days.

  9. Re: Is this evidence of a hack?

    "M. Trimble" writes:

    >Unruh wrote:



    >>
    >>>Whoa! Before you wipe the disk, note the size and date of any compromised
    >>>program - use the information to help identify a safe backup!

    >>
    >> ??? and how is he to do that? His system is comprimized. The tools on his
    >> system are unreliable.
    >>
    >>
    >>
    >>>C.


    >Getting a set of trustworthy tools is trivial - use your choice of live
    >distro. Getting correct file size/date information, on the other hand, is
    >np-trivial. That problem breaks down as follows:


    >1. identify all system-critical files by name, version, date and source.
    >2. obtain locate the correct version and date of each of those files,
    >according to their respective sources.
    >3. compare all files one - to - one, matching on the name, examining for
    >differences in name, version and date. Oh, and don't let's forget the
    >trivial detail of owner/group/permissions.


    >You get going on that, and I'll see you back here in a couple or five days.


    And exactly why would he want to do that? If he wants to do forensics,
    write everything to a DVD(s) but you will find that you never actually look
    at the DVD.

    Note on an rpm system
    rpm -Va |grep '^..5' >/tmp/verify
    will give you a list of the changed files, assuming you trust the rpm
    database, and your rpm binary.


  10. Re: Is this evidence of a hack?

    Unruh wrote:

    > "M. Trimble" writes:
    >
    >>Unruh wrote:

    ....
    > Note on an rpm system
    > rpm -Va |grep '^..5' >/tmp/verify
    > will give you a list of the changed files, assuming you trust the rpm
    > database, and your rpm binary.


    Kindly note: assuming you trust the rpm database.
    ^^^^^^^^

    I'm going from the assumption that since system-critical files are
    compromised, the probability of other files also being compromised is
    sufficiently high that NO files or tools on the system are trustworthy.
    That's the whole point: the OP doesn't KNOW what's been
    compromised/changed/reconfigured/etc., so it's best IMHO to do everything
    possible to obtain absolutely reliable information. Who's to say the
    alleged hacker didn't put in a version of ls that would report erroneous
    information in the interest of hiding his/her/their activity.

  11. Re: Is this evidence of a hack?

    "M. Trimble" writes:

    >Unruh wrote:


    >> "M. Trimble" writes:
    >>
    >>>Unruh wrote:

    >...
    >> Note on an rpm system
    >> rpm -Va |grep '^..5' >/tmp/verify
    >> will give you a list of the changed files, assuming you trust the rpm
    >> database, and your rpm binary.


    >Kindly note: assuming you trust the rpm database.
    > ^^^^^^^^


    >I'm going from the assumption that since system-critical files are
    >compromised, the probability of other files also being compromised is
    >sufficiently high that NO files or tools on the system are trustworthy.
    >That's the whole point: the OP doesn't KNOW what's been
    >compromised/changed/reconfigured/etc., so it's best IMHO to do everything


    Agreed. If that comes back with no problems, I would not trust it. If it
    however tells you that ls, ps, ... have changed, they I would put some
    faith in that.


    >possible to obtain absolutely reliable information. Who's to say the
    >alleged hacker didn't put in a version of ls that would report erroneous
    >information in the interest of hiding his/her/their activity.


    Of course. He did. The question is whether he also hacked the rpm database
    to report back that HIS version of ls is what was originally installed.
    Knowing the rpm database is a different skill than knowing how to install a
    hack of ls.

    Furtehrmore if the rpm came back saying NO files had been changed, you
    would also know that something was wrong with your database, since some
    files ( configuration files, like /etc/passwd) MUST have changed since
    installation.



  12. Re: Is this evidence of a hack?

    On Thu, 08 Jun 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , M. Trimble wrote:

    >Unruh wrote:


    >> Note on an rpm system
    >> rpm -Va |grep '^..5' >/tmp/verify
    >> will give you a list of the changed files, assuming you trust the rpm
    >> database, and your rpm binary.

    >
    >Kindly note: assuming you trust the rpm database.


    It takes a few seconds to see if the database is compromised. Read the
    whole thing below before you moan about it not being a valid test.

    --------rpm -V trick--------------
    OK, bring the box up single user. Move (repeat, MOVE, not copy) /bin/ps to
    some safe place, and copy any other file to /bin/ps

    /bin/mv /bin/ps /bin/ps.original
    /bin/cp /etc/services /bin/ps

    OK, do you see what I've just done? Note: if you are not permitted to move
    /bin/ps, use the '/usr/bin/lsattr /bin/ps' command to see if the -i flag is
    set. If it is, the game is over, You can use 'usr/sbin/chattr -i /bin/ps'
    command to reset the immutable bit, but this was a SURE sign that your box
    is 0wn3d.

    Now use the rpm command to see what happens.

    /bin/rpm -V procps

    and watch that rpm freaks out when it discovers that /bin/ps is not what
    /bin/ps should be. See the rpm man page for an explanation of the flags.

    SM5....T /bin/ps

    Now, before you do _anything_ else, move /bin/ps.original back to /bin/ps.
    When I did this originally, I was so happy that it worked the way it did,
    that I forgot to do the move. Two hours later, I discovered that I could
    not su, strace, etc. And I wasn't root any more. Oops! (I was able to go to
    another virtual terminal and log in there as root). Remember to use the
    MOVE ( /bin/mv ), not copy, command, to avoid messing with the file date
    stamps.

    NOTE: I illustrate this test using /bin/ps, but you can use _ANY_ program
    that a script kiddie is likely to replace. These include /bin/login,
    /bin/ls, /usr/bin/top, /usr/bin/find, /usr/bin/diff, and so on, or even
    /bin/bash itself.

    --------- end snippet of 'rpm -Va trick --------

    >I'm going from the assumption that since system-critical files are
    >compromised, the probability of other files also being compromised is
    >sufficiently high that NO files or tools on the system are trustworthy.
    >That's the whole point: the OP doesn't KNOW what's been
    >compromised/changed/reconfigured/etc.,


    and apparently doesn't want to believe that it has been. Point your
    newsreader at the newsgroups linux.redhat.rpm, comp.os.linux.misc, or
    linux.redhat.misc, and find his posting of 6 Jun 2006 (Message-Id
    <1149606538.340638.226950@j55g2000cwa.googlegroups. com>) with the subject
    "coreutils update: fedora4 - error: unpacking of archive failed - operation
    not permitted" where he posts

    ]I managed to get the problem sorted... It turned out to be the settings
    ]of the file attributes...
    ]
    ]I changed them using
    ]
    Code:
    ][root@ root]# chattr -ais 
    ]
    ]and it fixed my problem after changing the ownership and group back to
    ]root...

    Banging your head against a wall uses 150 calories an hour.

    Old guy

  13. Re: Is this evidence of a hack?

    Unruh wrote:
    > markstarmer@markstarmer.co.uk writes:
    > >I have noticed that the owner of the file 'ls' is not root and is '122'
    > >in group '114', is this normal in Fedora 4? I have not changed it from
    > >default... I tried to change ownership back to root - but this was not
    > >permitted... Any ideas?

    > Yes, you have been hacked.

    Start here:
    http://www.cert.org/tech_tips/win-UN...ompromise.html


+ Reply to Thread