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

> 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?

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

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

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

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 <cert-advisory@cert.org>
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

Unruh wrote:

> markstarmer@markstarmer.co.uk writes:
>
>>Hello,
>
>>I have noticed that the owner of the file 'ls' is not root and is '122'
<snip>
> Yes, you have been hacked.
<snip>
>
> 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.

Colin McKinnon <colin.thisisnotmysurname@ntlworld.deletemeunlessU RaBot.com> 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'
><snip>
>> Yes, you have been hacked.
><snip>
>>
>> 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.

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.

"M. Trimble" <user@127.0.0.1> 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.

Unruh wrote:

> "M. Trimble" <user@127.0.0.1> 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.