Incidente en Cyberhades
El pasado día 22 por la noche, hora costa este norteamericana, recibimos un correo de uno de los lectores (gracias Diego) del advirtiéndonos que el blog (cyberhades) aparecía, según Google, clasificado como un sitio web potencialmente peligroso porque podría contener software malicioso, también conocido como malware. Efectivamente cuando accedí al blog esto es lo que me aparecía:
Captura de pantalla con Firefox
Si accedía con Google Chrome encontraba con la siguiente pantalla:Lo intenté desde IE7 desde un Windows XP SP3 que tengo virtualizado, pero este no me daba ningún tipo de aviso.
Cuando hacía click en “Why was this page blocked?”, me redirigía a Google Advisory:
Según Google Advisory, cyberhades había sido parte de alguna actividad sospechosa en los últimos 90 días. Y de las 190 páginas que habían sido testeadas, ninguna de ellas habían descargado malware al navegador del usuario.
Pero hubo un detalle en el análisis de Google Advisory que me llamó la atención: “This site was hosted on 1 network(s) including AS16276 (OVH)”. Precisamente, un par de días antes, OVH publicó una entrada en la que reconocían que sus infraestructura había sido comprometida. Pues va ser por culpa de eso, me dije yo.
Antes de irme a dormir le mandé un correo a Cybercaronte explicándole el problema y pidiéndole que se pusiera en contacto con los administradores del hosting a ver si ellos sabían de que iba todo esto.
Al día siguiente por la mañana tengo un par de correos de Cybercaronte y uno de los administradores del sistema, donde según parece el único blog con problemas en el hosting es Cyberhades, y que además en el directorio raíz del blog habían dos ficheros con pinta de ser malware. Uno llamado bergpfh.php y el otro wxarfaw.php. El nombre de los mismos ya los delata. Efectivamente y un vistazo rápido a éstos se puede ver el código ofuscado usando Base64. Por curiosidad, rápidamente escribí un pequeño script para decodificar para del código y efectivamente aparecieron funciones como fsockopen y alguna URL “hardcoded”. En lo que se refiere al análisis de los ficheros lo voy a dejar aquí y publicaremos otra entrada con dicha información.
En ese momento la situación ya me preocupó un poco más. ¿Cómo habían llegado esos ficheros allí? Lo primero que pensé fue por algún 0day en alguno de los plugins que usamos (aunque intentamos usar los mínimos) o en el propio wordpress o el nuevo tema que pusimos hace algún tiempo. Después de buscar por varios sitios donde se publican vulnerabilidades y avisos no encontré nada relacionado con ninguna de los plugins o el propio wordpress. Es más miré cual fue el último plugin que se actualizó y éste se actualizó el 17 de julio varios días antes del incidente. El cual deshabilité, pero tampoco pude encontrar información alguna respecto a que el plugin tuviera algún tipo de vulnerabilidad. Siempre cabe la posibilidad que se esté aprovechando un 0day y por lo tanto no haya información del mismo.
Llegados a este punto, lo siguiente era ver si había algún otro fichero malicioso por los directorios del blog, así que me bajé no sólo los ficheros del blog, sino todo el contenido del directorio home de cyberhades del hosting.
El patrón típico de los ficheros con contenido malicioso es que están ofuscados y normalmente usan codificación en Base64 para hacer las funciones y sus parámetros totalmente ilegibles. Por lo que lo primero que hice fue lanzar un comando grep:
grep -i “base64” * -r
Por suerte la salida de este comando sólo mostró los dos ficheros anteriormente nombrados, más otro par de ficheros que hacen uso de funciones en Base64, pero estos son legítimos. También me puse a repasar los directorios uno por uno y a correr un antivirus (ClamAV) por todos los ficheros del blog y éste no reportó nada.
Los ficheros maliciosos habían aparecido en el directorio público del blog el día 20 julio, con lo que también busqué cualquier fichero modificado el día 20 en adelante (luego hice lo mismo, pero a partir del día 19 de julio). Los únicos ficheros modificados eran los logs de acceso, el sitemap, rss, etc. Los que tienen sentido que se modifiquen con las entradas y comentarios básicamente.
Hasta ese momento había localizado los ficheros maliciosos y más o menos interpretado su contenido, pero todavía no sabía como nos los habían colado. Así que el siguiente paso fue mirar los logs que acceso, y de nuevo grep es tu mejor amigo:
grep -i “bergpfh.php” * -r
grep -i “wxarfaw.php” * -r
Y entre la salida de dichos comandos, escupió del fichero ftp.cyberhades.com-ftp_log:
Sat Jul 20 19:52:08 2013 1 64.64.116.74 7564 …/public_html/wxarfaw.php a _ i r [email protected] ftp 1 * c
Sat Jul 20 20:31:23 2013 1 64.64.116.74 7500 …/public_html/bergpfh.php a _ i r [email protected] ftp 1 * c
Y buscando por la IP 64.64.116.74:
Fri Jul 19 23:47:18 2013 0 64.64.116.74 20 …/public_html/ftpchk3.php a _ i r [email protected] ftp 1 * c
Lo primero tenemos que entender el formato del fichero log, que es como sigue:
fecha y hora, tiempo de transferencia en segundos completos, IP, tamaño de la transferencia, fichero, tipo de transferencia (a=ascii, b=binary), flaf (C=comprimido, U=descomprimido, T=tar, _ = ninguno), dirección (i=subida (incoming), o=bajada (outgoing), d=borrado (deleted)), usuario, servicio (ftp en este caso), método de autentificación (0=no autentificado, 1=autentificado), estado (c=completo, i=incompleto).
Por lo que el día 20 de julio (fecha que coincide con la aparición de los ficheros en el FTP), suben los dos ficheros dichosos: bergpfh.php y wxarfaw.php. Lo suben por FTP usando la cuenta [email protected] desde la IP 64.64.116.74, que por lo visto pertenece a pastwellness.com una organización en el estado de Pensilvanya y que probablemente también haya sido comprometida. Pero si miramos en la tercera línea, el mismo usuario desde la misma URL sube un fichero llamado ftpchk3.php (si buscas por Google este fichero es un viejo conocido), el cual no existe. Lo que deduzco que por su tamaño (20 bytes) era un simple fichero puesto ahí para comprobar que se ha ganado acceso al servidor de FTP y una vez subido los otros 2 ficheros, este ftpchk3.php fue borrado, aunque no he podido encontrar ninguna evidencia de los logs.
En estos instantes ya parece que tenemos claro como llegaron los ficheros al directorio del blog. La cuenta [email protected] (ésta es ficticia) ha sido comprometida de alguna forma que no sabemos, ya que ni Cybercaronte ni yo teníamos acceso a la misma. Y a través de esta subieron: el día 19 el ftpchk.php y al siguiente día bergpfh.php y wxarfaw.php.
El siguiente paso era jurarle a Google que ya habíamos limpiado el blog y que todo estaba en orden. La petición la hice a través de Google Webmaster Tools el día 24 por la tarde y el día 25 por la mañana (horario costa este) Google ya no alertaba de peligro alguno y en los informes del Google Webmaster Tools aparece el blog limpio.
Cuando tenga otro rato intentaré publicar otra entrada con el contenido de los ficheros maliciosos.
Muchas gracias a los que nos avisasteis vía email o twitter.
Un abrazo
Buscar
Entradas Recientes
- Posts
- Reemplazando la bateria del AirTag
- OpenExpo Europe décima edición, 18 de mayo: El Epicentro de la Innovación y la Transformación Digital
- Docker Init
- Kubernetes para profesionales
- Agenda: OpenExpo Europe 2022 llega el 30 de junio en formato presencial
- Libro 'Manual de la Resilencia', de Alejandro Corletti, toda una referencia para la gestión de la seguridad en nuestros sistemas
- Mujeres hackers en ElevenPaths Radio
- Creando certificados X.509 caducados
- Generador de imágenes Docker para infosec