# hacked... SHV4 and SHV5?

## ahuacatlan

I noticed today that my ls command gave a strange error and that color coding in the terminal no longer functioned.

```
ls: unrecognized prefix: do

ls: unparsable value for LS_COLORS environment variable
```

After posting about this and hearing that I may have been hacked, I ran some tests. These are the results:

chkrootkit:

 *Quote:*   

> Checking `ifconfig'... INFECTED
> 
> Checking `pstree'... INFECTED
> 
> Searching for t0rn's v8 defaults... Possible t0rn v8 \(or variation\) rootkit installed
> ...

 

rkhunter:

```
[00:59:36] *** Start scan SHV4 ***

[00:59:36] - File /etc/ld.so.hash... OK. Not found.

[00:59:36] - File /lib/libext-2.so.7... OK. Not found.

[00:59:36] - File /lib/lidps1.so... WARNING! Exists.

[00:59:36] - File /usr/sbin/xntps... OK. Not found.

[00:59:36] - Directory /lib/security/.config... OK. Not found.

[00:59:36] - Directory /lib/security/.config/ssh... OK. Not found.

[00:59:36] *** Start scan SHV5 ***

[00:59:37] - File /etc/sh.conf... WARNING! Exists.

[00:59:37] - File /dev/srd0... OK. Not found.

[00:59:37] - Directory /usr/lib/libsh... WARNING! Exists.
```

Also,

in /var/log/lastlog there are 3 IPs. Two are mine, but one is from the state of Georgia which I do not recognize. Could this be the intruder. There is no other record in sshd logs or any other logs.

How can I figure out how to fix this?

Thanks.

----------

## cach0rr0

You've been hacked. I have seen this sort of exploit before. 

Grab a thumb drive, dump one of the security distributions' .iso onto it (e.g. backtrack4 or similar), boot from the thumb drive, scan for shit

Do not trust your current running kernel. Personally if this sort of thing were to happen to me, I'd boot from a thumb drive, make backups, and blow things away. 

You may be ok with booting from some security distro, and trying to remove compromised files by hand, but I'm far too paranoid to rely on that.

----------

## eccerr0r

I'd agree with the suggestion that blowing everything away to be the best solution.  You never know what things they try to hide to keep people from discovering their machine got hacked.  And they leave booby traps to make it harder to remove.

Technically you could simply boot up with a minimal install cd and reemerge everything to blow away all corrupt files, and make sure your etc-update contains all your changes and not the intruders' changes...

We don't know the method of security exploitation yet.  All we know is that someone was able to login (without a password?).  Would be useful to find out how they got in, in the first place...

```
[00:59:36] - File /lib/lidps1.so... WARNING! Exists. 
```

This is cute.  A 'd' versus a 'b'...  Hackers like hiding stuff in /lib because usually libraries' names are really confusing.  People used to dump files in /dev because nobody looks in /dev ... but with a lot of Un*x putting /dev on a ramdisk makes it an undesirable place to put files they want to keep around...

----------

## cach0rr0

 *eccerr0r wrote:*   

> 
> 
> Technically you could simply boot up with a minimal install cd and reemerge everything to blow away all corrupt files, and make sure your etc-update contains all your changes and not the intruders' changes...
> 
> 

 

Even then I wouldn't trust it. Portage doesn't seem to do terribly well with cleaning up after itself, so if you have some infected lib that isnt part of a package, bam. 

Kernel modules can be especially insidious

asdfasdfasdf yeah i need to cut myself off, I'm already paranoid as it is. 

@OP: 

But yeah, don't trust the system, dont trust the kernel - make your backups, then blow your shit away and install fresh. 

If someone got root, they could have removed rogue entries from the SSH logs - hell, they could have set up their own root shell, on a different port and all that. 

If an attacker got root, assume you are screwed. No exceptions. I'd even zero out the dadgum disk.

----------

