[Techtalk] rmserver, should I be worried?

[Brian J. Smith-Sweeney]

I've found that an often quick method of discovering a compromise with a 
RedHat system is to use RPM.  RPM by default keeps MD5 hashes of all the 
binaries it installs, and while it's theoretically possible to modify the 
RPM database in practice I've never seen  a script-kiddie-level attacker 
do so (and if the cracker was obvious enough to leave a process eating up 
that much of your cpu time, they're most likely not terribly skilled)

Common files trojaned include ps,ls,find,su, inetd, 
login,netstat,passwd,lsof, and sshd among others.  My suggestion would be 
to run 'rpm -V' on the packages procps, findutils, util-linux, net-tools, 
and lsof; that will cover most of the binaries I've mentioned.  You could 
also, if you're feeling adventurous, 'rpm -Va' which will verify the md5 
hash of every file from every rpm package on the system.  Remember that 
some of these files (like /etc/passwd) will definitely have changed since 
installation.  Really, you're just interested in any changes to binary 
files.  Check the manpage of RPM for info on how to interpret the output, 
but for a quick example I just ran rpm -Va on my box and got back:

missing    /root/.Xresources
missing    /root/.bash_logout
missing    /root/.bash_profile
missing    /root/.bashrc
missing    /root/.cshrc
missing    /root/.tcshrc
.......T c /usr/share/fonts/default/Type1/fonts.dir
S.5....T c /etc/sysconfig/rhn/rhn-applet
S.5....T   /usr/share/rhn/rhn_applet/rhn_applet.pyc
S.5....T   /usr/share/rhn/rhn_applet/rhn_applet_animation.pyc
S.5....T   /usr/share/rhn/rhn_applet/rhn_applet_dialogs.pyc
S.5....T   /usr/share/rhn/rhn_applet/rhn_applet_model.pyc
S.5....T   /usr/share/rhn/rhn_applet/rhn_applet_rpc.pyc
S.5....T   /usr/share/rhn/rhn_applet/rhn_applet_rpm.pyc
S.5....T   /usr/share/rhn/rhn_applet/rhn_utils.pyc

This tells me that those first few files are no longer on the system, that 
fonts.dir has a different modification time that it used to, and that the 
rest have different file sizes and that their MD5 hashes don't match and 
that their ModTimes are different as well.  File Size, MD5 has, and ModTime 
are the ones you'll want to look out for on the binaries mentioned, in 
addition to M (for Mode differs), which will tell you if the permissions on 
a file have changed.  Often, low-skill crackers will change the permissions 
on a shell binary or something to make it SetUid root as an easy way to 
elevate priveledge.

Also checkout chkrootkit (www.chkrootkit.org).  While you should really run 
it with clean copies of binaries, often it will detect rootkits anyway.

If you haven't killed the process yet (I realize I'm a bit late replying to 
this posting) don't forget about the /proc filesystem.  Proc has lots of 
good info on processes in its root.  They're organized there by process id. 
They'll be at the very least a cwd file, which is a symlink to the working 
directory of the process, an exe file which is a symlink to the process 
binary, and an environ file which will list all environment variables.

I'm also a big fan of using strace on rogue processes; it lets me see what 
they're crunching on so heavily.  Often strace'ing will show that a process 
is looping on get_time_of_day, or stuck attempting to open a non-existent 
file or something.  'strace -p <process_id>' will allow you to trace an 
active process.  Most of it is usually unintelligable to me not being a 
developer and all, but you can get a general idea of what's going on that 
way.

And if you've got another box available, I'd run an nmap scan against it. 
Telnet or Netcat to every open port that nmap reports.  If you find 
something like a command prompt, or telnet or ssh running on a weird port, 
you've got a problem.

Last, but certainly not least, check out:
	http://www.cert.org/tech_tips/win-UNIX-system_compromise.html

They've got some good general information on how to tell if your system has 
been compromised.

hope that helps,
Brian




--On Wednesday, October 09, 2002 02:56:25 PM -0400 Beth Johnson 
<linux.chick at verizon.net> wrote:

> On Tue, 2002-10-08 at 23:27, Jeannette wrote:
>> I just walked past my RH 7.3 box (default (2.4.18-3) kernel, but behind a
>> firewall) at 9:00 PM, and was concerned to hear it grinding away on
>> something .... I ran top, and it said that a process called rmserver was
>> using 98% of the CPU, and had used a total of 214 minutes of CPU time.
>
> A quick google search turns up rmserver as a Real Media server.  Who
> knows if that is the real process or not, but it's [any stuff named
> rmserver is] certainly not part of any Red Hat install set that I know
> of.
>
> Being in /usr/local suggests something that was installed via a method
> alternate to RPM, and a person is much more likely to remember something
> that was installed without RPM I'd think.
>
> I'd certainly consider the box compromised.
>
> regards,
> Beth
> --
>   /\/\    Beth Johnson
>  / o o\   Cosmic Wonderer
> ( / ^^\)  Springfield, MA USA
>  \ M_M/   "Ruling a country is like cooking a small fish--
>            you have to handle it with care."--Lao Tzu
> 	
>
> _______________________________________________
> Techtalk mailing list
> Techtalk at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/techtalk