sábado, 25 de enero de 2014

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!

domingo, 19 de enero de 2014

TA14-013A: NTP Amplification Attacks Using CVE-2013-5211

Hace unas dos semanas recibí una nueva alerta del US-CERT sobre el uso del protocolo NTP para realizar DDoS, mediante ataques de amplificación. Para los que no saben/recuerdan lo que es un ataque de amplificación lo pueden refrescar  leyendo http://viviendolared.blogspot.com.ar/2013/07/ta13-088a-dns-amplification-attacks.html , si bien esa entrada trata de un ataque de amplificación utilizando DNS, conceptualmente es lo mismo.

Me llamó poderosamente la atención que se pudiese utilizar NTP para realizar este tipo de ataques, básicamente por no conocer en profundidad las posibilidades del protocolo. El problema esencialmente es que NTP junto con DNS, FTP, HTTP, etc... es de esos protocolos que fueron diseñados en una época en que internet era buena/saludable/ingenua y jamás pensaron que muchas funcionalidades podrían luego ser utilizadas para hacer el mal, JA!

Resulta ser que hay una funcionalidad del protocolo, llamada monlist que nos permite ver las estadísticas de comunicación del demonio NTP con todos los clientes. Por ejemplo, consultando a un pequeño servidor que mantiene sincronizado unos pocos nodos en una LAN podemos ver:

ntpdc -c monlist

Una simple consulta ntpdc -c monlist servidor.ntp.com nos generó el siguiente tráfico:


root@acelga:~# tcpdump -n port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:50:34.121664 IP 172.19.136.12.45612 > 172.19.136.1.123: NTPv2, Reserved, length 192
16:50:34.122140 IP 172.19.136.1.123 > 172.19.136.12.45612: NTPv2, Reserved, length 296
^C
2 packets captured
2 packets received by filter
0 packets dropped


pasado en limpio, con 192 bytes logramos una respuesta de 296 bytes, lo cual realmente no parece ser gran cosa. Pero qué pasa si en lugar de consultar a un pequeño servidor NTP de una LAN consulto a uno un poco mas grande?


root@acelga:~# tcpdump -n port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:00:41.259404 IP 172.19.136.12.37161 > 200.XXX.XXX.XXX.123: NTPv2, Reserved, length 192
17:00:41.259767 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259780 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259785 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259788 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.259792 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260016 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260027 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260031 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260034 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260038 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260042 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260046 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260266 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260275 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260280 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260283 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260287 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260291 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260516 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260526 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260530 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260534 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260538 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260541 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260766 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260776 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260780 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260784 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 440
17:00:41.260788 IP 200.XXX.XXX.XXX.123 > 172.19.136.12.37161: NTPv2, Reserved, length 224
^C
30 packets captured
30 packets received by filter
0 packets dropped by kernel
root@acelga:~#  

Y ahora qué pasó? JA! a partir de una consulta de 192 bytes obtuvimos una respuesta de 12544 bytes (28*440+224), es decir pasamos de un factor de casi 2 a un factor de 65, suena mas interesante, no? Y eso que el servidor consultado solo mostró 170 clientes conectados... seguramente se pueden encontrar en internet servidores con mas clientes aún.

Según la documentación de ntpdc, el comando monlist solo nos devolvería hasta 600 entradas, por lo tanto podríamos asumir un máximo de 12544 bytes*3.5=43904 bytes con una consulta de solo 192 bytes, esto es un factor de 227 aproximadamente, interesting!!!

Haciendo un poco de números si tenemos 100 PCs zombies haciendo spoofing y realizando 1 consulta por segundo son 43904*100=4390400 bytes, aprox 4Mbytes/S de tráfico que retornará a la IP spoofeada, esto sin considerar la posibilidad de hacer mas consultas por segundo, tener mas PCs zombies o mas servidores NTP...

¿Cómo controlo mi servidor NTP para que no sea utilizado para esto?

Por defecto la mayoría de las versiones nuevas de NTP no son vulnerables, porque traen desactivada la opción de consultas de estadísticas, las opciones para evitar dolores de cabeza son:

-Desactivar las consultas de estadísticas
-Controlar las direcciones IP que tienen permitidas dichas consultas

Ambas soluciones se logran editando el archivo /etc/ntp.conf (o el equivalente en tu distribución), y asegurandose de que la opción noquey se encuentra puesta como en las siguientes lineas:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery 

sábado, 18 de enero de 2014

Memcached replicado en Ubuntu 12.04 LTS (haciendo el paquete)

No estaba seguro si ameritaba o no un nuevo post, pero ante la duda así será. La idea de este post es en lugar de hacer una compilación clásica configure && make && make install, crear un paquete que luego podamos transportar sencillamente e instalar en otros servidores similares. Agradezco de antemano a Tomás por la colaboración y la paciencia!

Los pasos que hay que seguir son similares a los del post anterior, (de hecho los pasos del 1 al 4 no cambian, ver http://viviendolared.blogspot.com.ar/2014/01/memcached-replicado-en-ubuntu-1204-lts.html), y por lo tanto comenzaremos a partir del punto 5.

5-Cambios en las reglas de compilación
Para poder crear exitosamente nuestro paquete de memcached con replicación debemos indicarle a dpkg-buildpackage que esta opción debe estar activa y esto lo logramos editando el archivo debian/rules en el directorio de código de fuente obtenido previamente. Es necesario agregar la linea --enable-replication como se indica a continuación (NOTESE la \ al final de la linea previa)


...
config.status: configure
        dh_testdir
        CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) \
                                       --build=$(DEB_BUILD_GNU_TYPE) \
                                       --prefix=/usr \
                                       --mandir=\$${prefix}/share/man \
                                       --infodir=\$${prefix}/share/info \
                                       --enable-replication


6-Generando el .deb
Ahora nos ubicamos dentro del directorio del código de fuente y creamos el paquete.


root@memcached1:~/memcached-1.4.13# dpkg-buildpackage -us -uc -nc
...
...
dpkg-buildpackage: binary and diff upload (original source NOT included)

Si vemos el directorio superior encontramos el archivo memcached_1.4.13-0ubuntu2.1_amd64.deb que se acaba de generar.

root@memcached1:~/memcached-1.4.13# ls ..
memcached-1.4.13                     memcached_1.4.13-0ubuntu2.1.dsc            memcached_1.4.13-0ubuntu2.1_amd64.deb  repcached-2.3.1-1.4.13.patch
memcached_1.4.13-0ubuntu2.1.diff.gz  memcached_1.4.13-0ubuntu2.1_amd64.changes  memcached_1.4.13.orig.tar.gz           tools
root@memcached1:~/memcached-1.4.13#

7-Instalamos el paquete
Ahora sencillamente instalamos el paquete con dpkg -i


root@memcached1:~# dpkg -i memcached_1.4.13-0ubuntu2.1_amd64.deb 
Selecting previously unselected package memcached.
(Reading database ... 75101 files and directories currently installed.)
Unpacking memcached (from memcached_1.4.13-0ubuntu2.1_amd64.deb) ...
Setting up memcached (1.4.13-0ubuntu2.1) ...
Starting memcached: memcached.
Processing triggers for ureadahead ...
Processing triggers for man-db ...
root@memcached1:~#

Y listo, ahora solo nos queda editar el archivo de configuración /etc/memcached.conf con las opciones correspondientes a nuestro entorno y ya tenemos nuevamente memcached replicado de manera mas sencilla y hasta me atrevería a decir mas limpia.
Este mismo paquete generado podemos copiarlo en el servidor memcached2 e instalar memcached con replicación simplemente haciendo dpkg -i memcached_1.4.13-0ubuntu2.1_amd64.deb simpático, no :D?

jueves, 16 de enero de 2014

Memcached replicado en Ubuntu 12.04 LTS

Como parte del despliegue de OpenStack que estamos haciendo hace ya unos meses en el trabajo surgió la necesidad de contar con alta disponibilidad en el servicio de cache provisto por memcached (Memcached es una sencilla pero muy poderosa solución de cache en memoria, utilizada por grandes personajes de Internet como Wikipedia, Youtube, Twitter, etc). En OpenStack, memcached se utiliza principalmente para proveer agilidad a la interfaz web Horizon.

Los siguientes 6 pasos deben ser aplicados a ambos servidores (cabe aclarar que este método solo permite 2 servidores, es una restricción del propio repcached).

1-Preparar el entorno
Debemos instalar una serie de paquetes para poder compilar nuestra propia versión de memcached con replicación.

root@memcached1:~/# apt-get build-dep memcached

2-Obtener el código de fuente
La forma mas sencilla de obtener el código de fuente es:

root@memcached1:~/# apt-get source memcached

3. Obteniendo el código de repcached
Repcached es un parche que aplicamos sobre el código de memcached, que nos da la capacidad de poder replicar nuestra cache en 2 servidores. Obtener el código de https://github.com/usecide/repcached/blob/master/repcached-2.3.1-1.4.13.patch

root@memcached2:~# wget https://raw.github.com/usecide/repcached/master/repcached-2.3.1-1.4.13.patch

4-Aplicar el parche

root@memcached1:~/# mv repcached-2.3.1-1.4.13.patch memcached-1.4.13/
root@memcached1:~/# cd memcached-1.4.13/
root@memcached1:~/memcached-1.4.13# patch -p1 -i repcached-2.3.1-1.4.13.patch

5-Configurar, Compilar e Instalar

root@memcached1:~/memcached-1.4.13# ./configure –enable-replication
root@memcached1:~/memcached-1.4.13# make
root@memcached1:~/memcached-1.4.13# make install

"make install", si todo sale bien nos dejará nuestra versión de memcached en el directorio /usr/local/bin/.

6-Puesta en marcha
Necesitamos una serie de retoques para poner a punto nuestro memcached con replicación.
Primero debemos crear un script de arranque que nos permite iniciar/reiniciar/detener el servicio a gusto y placer y ubicarlo en /etc/init.d/ con el nombre memcachedrep, el archivo se puede obtener de http://pastebin.com/WfxPV81W ; luego es necesario hacer el archivo ejecutable:

root@memcached1:~/memcached-1.4.13# chmod +x /etc/init.d/memcachedrep

Como segundo paso creamos un archivo de configuración para el servicio en /etc/default/ con nombre memcachedrep y escribimos la siguiente linea en él:


DAEMON_ARGS="-m 256 -p 11211 -u root -P /var/run/memcachedrep.pid -d -v -t 4 -x 172.16.254.118"

Siendo:
-m 256: utilizar 256Mb de memoria para almacen.
-p 11211: escucha peticiones en el puerto 11211, TCP y UDP
-u root: usuario con el que ejecutará el demonio
-P /var/run/memcachedrep.pid: archivo que contendrá el PID del demonio en ejecución
-d: lanza memcached en modo demonio
-v: modo verborrágico, nos permitirá ver advertencias y errores en la ejecución
-t 4: cantidad de hilos que utilizará memcached   
-x 172.16.254.118: este parámetro es propio del parche repcached e indica quien es el servidor con el que se replicará. En nuestro caso los servidores son 172.16.254.117 (memcached1) y 172.16.254.118 (memcached2). Por defecto los servidores se sincronizaran utilizando una conexión dedicada en el puerto 11212.

Por último agregamos memcachedrep a los servicios del sistema:

root@memcached1:~/memcached-1.4.13# update-rc.d memcachedrep defaults

7-Probando la replicación
Bien, ahora llega la parte divertida, ya tenemos ambos servidores listos para correr nuestra versión de memcached con replicación. 


Iniciamos memcachedrep en el nodo memcached1:


root@memcached1:~# service memcachedrep start
root@memcached1:~# replication: connect (peer=172.16.254.118:11212)
replication: marugoto copying
replication: close
replication: listen
root@memcached1:~# 


podemos ver que la replicación se encuentra "close", esto se debe a que la instancia de memcached que lanzamos no pudo conectarse con el otro nodo (172.16.254.118 memcached2). Podriamos utilizar solamente este nodo, en caso de que el otro no funcione.
Ahora iniciamos el segundo nodo:

root@memcached2:~# replication: connect (peer=172.16.254.117:11212)
replication: marugoto copying
replication: start

root@memcached2:~#  

Perfecto, ambas instancias están levantadas y conectadas. Podemos verificar que se han conectado con el siguiente comando:


root@memcached2:~# netstat -ntap|grep ESTA|grep 11212
tcp        0      0 172.16.254.118:35734    172.16.254.117:11212    ESTABLISHED 31503/memcached 
root@memcached2:~# 

También podemos ver en el nodo memcached1 un mensaje indicandolo:


root@memcached1:~# replication: accept


Ahora viene la prueba de fuego, cargamos un dato en el nodo memcached1 y lo buscamos en memcached2:

root@memcached1:~# telnet 127.0.0.1 11211
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
set juan 0 0 4
jose
STORED
quit
Connection closed by foreign host.
root@memcached1:~# 

root@memcached2:~# telnet 127.0.0.1 11211
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
get juan
VALUE juan 0 4
jose
END
quit
Connection closed by foreign host.
root@memcached2:~# 

Y así podemos apreciar el efecto de la replicación. Si sumada a la replicación, ubicamos delante de ambos servidores un balanceador TCP como haproxy logramos sencillamente un mecanismo de cache con alta disponibilidad y balanceo de carga.

Lamentablemente el proyecto repcached se encuentra en un estado no muy activo y por lo tanto dificilmente haya novedades al respecto, pero sin lugar a dudas es una buena opción para lograr estos objetivos.