[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: chkrootkit infected ports 2881



Thomas Preud'homme wrote:
> I don't think it's that important. chkrootkit seems a little hazardous 
> since there was a bug about chkrootkit killing a random process (in 
> fact one of its test was sending a signal to process 12345, this bug 
> has been corrected).

That anyone could code such a thing was astounding.. until I looked at the part
of chrootkit's code that's responsible for the "INFECTED PORTS" message:

  bindshell () {
  PORT="114|145|465|511|600|1008|1524|1999|1978|2881|3049|3133|3879|4000|4369|5190|5665|6667|10008|12321|23132|27374|29364|30999|31336|31337|37998|45454|47017|47889|60001|7222"

So, rootkits only bind to this small list of high ports? If I were
writing a rootkit, mine wouldn't. I've got a list right here; why would I
choose any of the ports on it? Why is something on port 2881 any
more indicative of a rootkit than something on port 2880? I'd suggest
instead that it's _less_ indicative of a good rootkit!

   OPT="-an"
   for P in `echo $PORT | ${sed} 's/|/ /g'`; do
      if ${netstat} "${OPT}" | ${egrep} "^tcp.*LIST|^udp" | ${egrep} \
  "[.:]${P}[^0-9.:]" >/dev/null 2>&1
      then
         PI="${PI} ${P}"
      fi
   done
   if [ "${PI}" != "" ]
   then
      echo "INFECTED (PORTS: $PI)"

So, the netstat program can be trusted? No rootkit authors will ever
consider replacing it with a version that doesn't show their ports?

And this looks for any processes listening on one of the ports for TCP, or
for any UDP that happens to be using the port whatsoever. That includes
local processes using UDP with that port, but it will also match if the remote
side is using UDP on that port.

Yes, something listening on a strange TCP port is unusual. But only as unusual
as running a ftp client or bittorrent download, or any of a number of other
things.

The UDP part of the check is much less defensible; systems use UDP with random
ports in regular operation. You may have heard of the recent DNS vulnerability
-- the fix for that is to use randomised UDP ports when making queries.

In summary, chrootkit has plenty of false positivies (just check the list
archives), and will only ever have correct positives if rootkit authors are
slower to update than it is, or stupid. When was chkrootkit last updated?
December. The rootkits it's trying to detect? 3 am last night.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature


Reply to: