Triggers on chkrootkit 0.45

[Ron Levy]

With the help of some old forum posts I got chkrootkit 0.45 running on my HPUX 11.0 machines. It triggers on a couple of things:

Under suspicious files and directories, it triggers on /usr/lib/.unix95 on all my 11.00 machines.

Under 'bindshell' it calls port 1524 'INFECTED' on only one of my machines.
That machine is primarily used to run a special socket application that runs Oracle client processes that connect to an Oracle DB on another machine.

Where would I go from here to determine whether these are false positives? A netstat -a | grep 1524 gives me nothing on the critical machine. I can't telnet to the port, thank goodness.

[John Morris]

The /usr/lib/.unix95 seems to be a false positive. I got this result on an 11.00 system:

swlist -l file | grep unix95
...
OS-Core.UX-CORE: /usr/lib/.unix95
OS-Core.UXCORE: /usr/lib/.unix95/context.o
OS-Core.UXCORE: /usr/lib/.unix95/makecontext.o

cksum /usr/lib/.unix95/*
4215738026 1636 /usr/lib/.unix95/context.o
1084647186 2292 /usr/lib/.unix95/makecontext.o

The 1524 also seems to be a false positive:

http://www.webhostgear.com/25.html

Important Note: If you see 'Checking `bindshell'... INFECTED (PORTS: 465)' read on.
I'm running PortSentry/klaxon. What's wrong with the bindshell test?
If you're running PortSentry/klaxon or another program that binds itself to unused ports probably chkrootkit will give you a false positive on the bindshell test (ports 114/tcp, 465/tcp, 511/tcp, 1008/tcp, 1524/tcp, 1999/tcp, 3879/tcp, 4369/tcp, 5665/tcp, 10008/tcp, 12321/tcp, 23132/tcp, 27374/tcp, 29364/tcp, 31336/tcp, 31337/tcp, 45454/tcp, 47017/tcp, 47889/tcp, 60001/tcp).

Yours truly,
John Morris
HP SOFTWARE SECURITY RESPONSE TEAM (SSRT)

[Ron Levy]

How could I perform a test to see if I was vulnerable on this port? I'm not running klaxon or anything like that - the primary activities of the machine are the aforementioned socket application and Data Protector 5.1.

It worries me because this machine shows a different pattern than all the others. Of course, it's the only one running the special socket application or Data Protector...