Ortho's picture

Hello,

First, I'll say I am no Linux guy by any stretch, so if this is a non-issue, I'm sorry for creating a false positive thread.

When I ran chkrootkit on an existing LAMP server we've been running in house (Turnkey LAMP 15.1), it detected a failure within its scan.

So I downloaded a fresh copy, installed it as a temporary VM, did the basic setup, and then installed chkrootkit with apt install, and ran it. It found the following (only including the stuff that is important):

Checking `bindshell'...                                     INFECTED (PORTS:  12321)

Searching for suspicious files and dirs, it may take a while... The following suspicious files and directories were found:  
/usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/file/.htpasswd /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/basic/authz_owner/.htpasswd /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_time/.htpasswd /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest/.htpasswd /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_wrongrelm/.htpasswd /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/noentry/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/.htaccess /usr/lib/python3/dist-packages/fail2ban/tests/files/config/apache-auth/digest_anon/.htpasswd

 

I'm not too worried about the test files within Python, but its the bindshell that concerns me.

Forum: 
Jeremy Davis's picture

TBH, I'm not particularly familiar with chkrootkit nor exactly how it works. Unfortunately, I couldn't find any clear documentation on how it determines whether a "bindshell" exists or not (although keep reading below for my interpretation of the source code). AFAIK a "bindshell" is an open shell which is awaiting connection from a remote host (i.e. an attacker) so is essentially a "trojan" of some sort.

On TurnKey port 12321 is used by Webmin (to be more specific stunnel listens on port 12321 and forwards it to Webmin). It strikes me a bit weird though that it's not also picking up the other stunnel port (12320 - Webshell aka Shellinabox) though?!:

root@lamp ~# netstat -tlnp | grep "stunnel"
tcp        0      0 0.0.0.0:12320           0.0.0.0:*               LISTEN      7495/stunnel4       
tcp        0      0 0.0.0.0:12321           0.0.0.0:*               LISTEN      7495/stunnel4       

FWIW if stunnel (the service is actually named 'stunnel4') is stopped on the server, then the 'bindshell' test passes:

root@lamp ~# service stunnel4 stop
root@lamp ~# chkrootkit bindshell
ROOTDIR is `/'
Checking `bindshell'... not infected

Having a closer look at the source code of chkrootkit (see below grep command output) it appears that it simply checks for services listening on a predefined range of ports (i.e. list of ports separated with '|' in the PORT variable within the 'bindshell' function):

root@lamp ~# grep 'bindshell ()' -A26 /usr/sbin/chkrootkit
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"
   OPT="-an"
   PI=""
   if [ "${ROOTDIR}" != "/" ]; then
     echo "not tested"
     return ${NOT_TESTED}
   fi

   if [ "${EXPERT}" = "t" ]; then
       expertmode_output "${netstat} ${OPT}"
       return 5
   fi
   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)"
   else
      if [ "${QUIET}" != "t" ]; then echo "not infected"; fi
   fi
}

So essentially what it is doing is checking each (predefined) port to see if it's LISTENing. I.e. in the case of port 12321, this is essentially what it's running:

root@lamp ~# netstat -an | egrep "^tcp.*LIST|^udp" |  egrep "[.:]12321[^0-9.:]"
tcp        0      0 0.0.0.0:12321           0.0.0.0:*               LISTEN

FWIW if I substitute port 12320 then I also get a result:

root@lamp ~# netstat -an | egrep "^tcp.*LIST|^udp" |  egrep "[.:]12320[^0-9.:]"
tcp        0      0 0.0.0.0:12320           0.0.0.0:*               LISTEN     

After doing a bit of googling, it seems that port 12321 is a port commonly used by a number of trojans and only one (very old) legitimate application (not considering TurnKey's default use of this port). So it appears that all chkrootkit is doing is checking to see if a list of commonly abused ports are in use. In the case of TurnKey, port 12321 is in use, thus the false positive...

All the other results listed (i.e. under "suspicious files and directories") are tests within fail2ban (a default tool that we include that blocks specific IP addresses for a period of time when they fail authentication). So they too appear to be false positives. If you had any results which were within a path that Apache was reading/using, then that would certainly be cause for concern! But all looks good to me...

I hope that helps put your mind at rest! :)

Ortho's picture

Very interesting, and good to know information. Def. puts the mind at ease.

Jeremy Davis's picture

Glad that helped.

When I get a chance, I might try to recycle some of this content for a blog post. It might be good to run a few other checks/tests on TurnKey and publish the results too. FWIW we do run a few different tests internally, but I've never really considered that that would likely have value to users. Pretty obvious really now that it occurs to me...!

So thank you for asking the question! :)

Add new comment