[TriLUG] invisible directories...

[Jeffery Painter]

Well, it appears my /bin/ls is not the same as on another host... this 
looks to be the only major binary I can find... also to note, vsftp 
service had stopped accepting connections... I did not see any errata on 
vsftp for redhat 8...

I reinstalled vsftp from rpm's and it is working again... having a little 
more trouble replacing the trojan ls with a clean copy... will probably 
just reinstall and get my data off of there! :)

thanks,

Jeff Painter
painter at kiasoft.com


------------------------ clean box
[painter at utena bin]$ cat /etc/redhat-release
Red Hat Linux release 8.0 (Psyche)
[painter at utena bin]$ ls -la ls
-rwxr-xr-x    2 root     root        67884 Sep  2  2002 ls

------------------------ hacked
[painter at ipdev bin]$ cat /etc/redhat-release
Red Hat Linux release 8.0 (Psyche)
[painter at ipdev bin]$ ls -la ls
-rwxr-xr-x    1 root     root        42952 Sep  2  2002 ls

definitely something different at least in the file size of these 
executables



On Mon, 21 Apr 2003, Paul D. Boyle wrote:

> Jeff Painter wrote:
> > I'm getting some odd behavior on a linux machine.
> > 
> > I don't think it has been cracked but maybe someone can give me a clue as 
> > to what is going on if it has been attacked.
> 
> The behavior you are describing is very common when a cracker installs
> a trojaned version of '/bin/ls'.  The progam has been modified to not
> find certain files or directories.  You can detect these files/directories
> with other tools which may have not been compromised (e.g. 'find').  You
> can also see these directories in in /proc file system sometimes when
> the cracker leaves an executable running which uses the hidden directory
> as it's cwd (current working directory) (see /proc/<PID>/cwd).
> 
> The first thing to do is use rpm to verify the checksum of your 'ls'
> executable (although I am waiting for the day when 'rpm' itself gets
> trojaned).  If the checksums don't match, then it is safe to assume your
> system has been hacked.  You can also copy the /bin/ls from the suspect
> machine and transfer to a known safe box  and compare the MD5 checksum
> for the /bin/ls on the safe machine with the /suspect/ls executable's
> checksum. 
> 
> If this second verification doesn't indicate anything untoward then
> who knows ... maybe a really sophisticated hack (like a rogue kernel
> module which intercepts system calls which gives compromised output),
> or a legitimate filesystem problem.
> 
> Good Luck,
> 
> Paul
> 
> 
>