Vulnerabilidad en plesk

Hace unos meses leíamos en algunas páginas de noticias sobre seguridad digital artículos sobre una grave vulnerabilidad en versiones de Plesk anteriores a la v10.4. Desde entonces muchas han sido las reacciones que se han ido produciendo y son muchos los servidores que se han visto afectados por este bug. Os voy a explicar los pasos que seguí para eliminar la infección que había recibido un servidor de una asociación con la que colaboro. El servidor en concreto, era un CentOS con la versión de Plesk 10.4 y CentOS.

La evidencia que tuvimos para saber que habíamos sufrido ese ataque fue que algunas de las páginas alojadas en el servidor aparecían marcadas por el navegador y por Google como sospechosas de contener malware. A partir de ese momento empezamos a buscar documentación, y lo primero que hicimos fue actualizar Plesk a la versión 11 del software.

Después de instalar y configurar de nuevo Plesk y de revisar también la configuración de Apache y PHP, teníamos que encontrar el código o los ficheros que el atacante presumiblemente había insertado en el servidor y la forma a través de la cual habría entrado al mismo. Para eso nos descargamos todos los logs de plesk y de apache para encontrar evidencias del ataque.

Errores y logs de accesos a Plesk

1	/usr/local/psa/admin/logs/httpsd_access_log
2	/var/log/sw-cp-server/error_log

Logs del servidor apache en Plesk

1	/var/log/httpd/access_log
2	/var/log/httpd/error_log	

En estos logs empezamos a ver evidencias de peticiones sospechosas al plesk del servidor, así como peticiones del servidor a páginas con dominio .ru. Algunas de estas peticiones tenían la siguiente estructura:

(IP)	 - - [18/Jul/2012:07:42:34 +0200] "GET / HTTP/1.1" 200 565 
"http://(DOMINIO).ru/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; KKman2.0)"

Petición iniciada por nuestro servidor

Y en el log de Plesk

(IP) DOMINIOPROPIO:8443 - [13/Jul/2012:20:30:54 +0200] "GET / HTTP/1.1" 
200 976 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.5 (KHTML, like Gecko) 
Chrome/15.0.1084.56 Safari/546.5"

Petición recibida

También se podían ver trazas de direcciones IP de Dallas, Países Bajos, Turquía, etc. La más repetida era una IP turca desde la cual se realizaban accesos al puerto de plesk del servidor.

(IP TURCA) SERVIDOR:8443 - [05/Jul/2012:15:09:22 +0200] "POST /login_up.php3 
HTTP/1.1" 200 6642 "-" "-"

Encontramos en los dominios infectados un script que generaba aleatoriamente una URL con dominio .ru. Esa URL se registraba y es la que contenía el malware. Por tanto al acceder a las páginas alojadas en el servidor, este realizaba una petición a la página .ru infectada. Después de la actualización de Plesk y de cambiar las claves de acceso al servidor se veían trazas de escaneo de puertos y de intentos de accesos fallidos al servidor.

(IP)	 (IPSERVIDOR):8443 - [14/Jul/2012:02:10:10 +0200] "GET / HTTP/1.1" 200 
976 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; http://nmap.org/book/nse.html)"

Ya solo quedaba limpiar los archivos infectados. Para eso seguimos los pasos que la propia página de plesk indicaba:

cd /var/www/vhosts
grep -l -r “km0ae9gr6m” * > infectados.txt

Todos los ficheros infectados salieron en infectados.txt, y para eliminarlos tuvimos que ejecutar para cada uno de esos ficheros la orden:

sed -i ‘s/\/\*qhk6.*g1c\*\///g’ filename

De esta manera el antivirus ya no saltaba y Google ya no marcaba las páginas como peligrosas de contener código malicioso. Además revisando el servidor veíamos que no habían accesos no deseados al servidor. Para estar más tranquilos, también lanzamos Unhide para asegurarnos que no existía ningún proceso oculto ni ningún rootkit que permitiera el posterior acceso de los atacantes.

Como medida de seguridad, además de proceder al cambio de claves del servidor y de todos los dominios y subdominios (FTP, bases de datos, etc.), cambiamos los puertos por defecto de acceso a plesk, de ftp y ssh, para dificultar los ataques automáticos a estos puertos.