Servidor comprometido no centro

Este luns recibimos unha chamada da Área TIC da Universidade, xa que detectaran ataques de forza bruta contra sitios web WordPress de Internet dirixidos dende un dos nosos servidores.

A IP correspondía non cun servidor, senon cunha rede virtual na que hai dez servidores, que son os que proven servizos web, así que houbo que identificar a máquina pola nosa parte. Tampouco foi moito problema, xa que tiñamos sospeitas de onde podía estar o problema: no servidor virtual onde se atopan as páxinas persoais, de proxectos e de eventos.

Efectivamente, despois de apagar esa máquina os ataques cesaron por completo, polo que procedemos a illala da rede para analizar o que estaba pasando.

Seguindo as mesmas sospeitas que nos levaron a apagar a máquina, comezamos por analizar os logs de acceso de Apache, para localizar execucións de scripts que non deberan estar aí.

10.1.98.xxx - - [16/Feb/2014:22:44:22 +0100] "POST /xxx/wp-content/themes/project-ar2-master/stylegreen.php HTTP/1.0" 200 5551 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100102 Firefox/16.0"
10.1.98.xxx - - [16/Feb/2014:22:44:22 +0100] "POST /xxx/wp-content/themes/project-ar2-master/stylegreen.php HTTP/1.0" 200 5551 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100102 Firefox/16.0"
10.1.98.xxx - - [16/Feb/2014:22:44:23 +0100] "POST /xxx/wp-content/themes/project-ar2-master/stylegreen.php HTTP/1.0" 200 8422 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100102 Firefox/16.0"
10.1.98.xxx - - [16/Feb/2014:23:18:50 +0100] "GET /xxx/wp-content/themes/project-ar2-master/flotch-style.php HTTP/1.0" 200 324 "http://pinglard.com/pinglord/lordos.php?t=4" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"
10.1.98.xxx - - [16/Feb/2014:23:41:24 +0100] "GET /xxx/wp-content/uploads/function_php.php HTTP/1.0" 500 642 "http://hennexxx.com/the-henxxx/hennexxxtuff.php?t=4" "Opera/9.80 (Windows NT 6.1; WOW64; U; ru) Presto/2.10.289 Version/12.00"

Aclaramos que as xxx varias son para tapar as vergoñas. En calquera caso vemos como, tras executar peticións POST a un script pertencente a un tema de WordPress chamado Project-Ar2, fai unha chamada a un arquivo chamado /xxx/wp-content/uploads/function_php.php que, loxicamente, non debera estar aí.

Este arquivo tratábase dun botnet, moi similar ó que denuncian nesta bitácora. Só que en lugar de tratarse dun plugin falso, o script subiuse usando un exploit dun tema de WordPress.

Esquema que ilustra o funcionamento dun botnet, pertencente á Wikipedia (cc-by-sa Tom-b)

Esquema que ilustra o funcionamento dun botnet, pertencente á Wikipedia (cc-by-sa Tom-b)

Ó citado botnet non lle basta con executarse subindo un código PHP ó servidor, xa que normalmente estes scripts execútanse nun entorno no que están moi limitados en tempo de execución e en permisos. O script en si o que fai é intentar saír deste entorno. No noso caso conseguiuno, engadíndose ó crontab do usuario que executaba PHP. Unha vez executado, o primeiro que fai é borrarse do crontab para non deixar rastro.

Aínda así, executar un binario tampouco é doado, porque é habitual que as particións onde pode escribir ese usuario non teñan permisos de execución, así que o que fixo foi escribir unha biblioteca compartida que reimplementaba algunha función elemental co código malicioso, e executar calquera binario do sistema usando a técnica do LD_PRELOAD.

Determinar que fixo exactamente no sistema non é doado, pero todos os indicios apuntan a que non conseguiu gañar acceso de superusuario, e que de feito parece que nin sequera o chegou a intentar.

Tras pedir as pertinentes desculpas e rematar o análise, volvimos a poñer o servidor en marcha.

Este problema podería haberse evitado, por suposto. Bastaría con ter deshabilitado o cron nos usuarios que executan PHP, ou non permitir o uso de funcións de PHP coma system ou shell_exec, ou usar open_basedir para negar a PHP abrir ou executar arquivos fora da ruta que sirve os arquivos PHP.

Por suposto, aplicamos inmediatamente todas as recomendacións que nos fixemos a nos mesmos, que se unen ó uso do módulo suphp e outras boas prácticas máis básicas que xa viñamos empregando.

Como curiosidade, moitos de vos notastes este luns coma Google pedía un captcha ó utilizar os seus servizos dende o centro. Efectivamente, foi por culpa disto.

2 pensamientos en “Servidor comprometido no centro

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *