29 septiembre 2011

Dispositivos IPS vs DDoS de Anonymous

Últimamente los ataques DDoS están ganando cierta importancia en el entorno de seguridad, sobre todo por parte de los ataques que Anonymous lanza contra diferentes compañías u organismos gubernamentales o no gubernamentales. Independientemente de nuestras ideologías o de si estamos a favor o en contra de estos movimientos, nuestro deber como profesionales de seguridad es intentar que la empresa para la que trabajamos no sufra ninguna interrupción en su servicio.

Se me ocurrió escribir este artículo raíz de una experiencia vivida en un cliente con un ataque de denegación de servicio del estilo de los que lanza Anonymous. Después de este ataque pasaron un elenco de comerciales de las diferentes marcas vendiéndonos las excelencias de sus productos y como me pico la curiosidad me puse a investigar que ofrecían los fabricantes para protección contra DDoS. Voy a intentar explicar como se comportan los IPS frente a este tipo de ataques y plantear algunas soluciones.

Para los que no sepáis nada de los ataques que Anonymous suele lanzar, se tratan de unos ataques DDoS mediante un programa llamado LOIC. Para los que no conozcáis LOIC, se trata de un programa para ataques de denegación de servicio, en la que los atacantes se reúnen en un canal IRC, y delegan ciertas partes de la configuración de LOIC al administrador del canal. Cada uno de los usuarios del canal IRC se convierte en un integrante de una botnet. No voy a entrar en detalle, ya que se ha escrito mucho en internet sobre esto. Solo decir que LOIC lo que generan son peticiones HTTP normales, como las que generamos cuando navegamos con cualquier navegador, pero con un volumen de peticiones por segundo importante.



En la práctica…


En una empresa u organismo de considerable tamaño, del tipo de las que Anonymous se fija como objetivo, deberían tener ciertas medidas de seguridad estas suelen ser a grandes rasgos IPS, Firewall y balanceadores. Sobre las labores que suele realizar cada uno se podría hablar largo y tendido, ya que los fabricantes integran de todo en todas partes, no es raro ver un IPS con ACL al mas puro estilo Firewall, y no es raro ver Firewalls con módulos IPS, en cuanto a los firewall de aplicación esto ya si que es un caos, en teoría un SQL Injection y un XSS lo debería parar un IPS, pero los Firewalls de gama alta suelen incluir un modulo de firewall de aplicación por no hablar de los balanceadores, que también suelen incluir protecciones de este tipo.

Aunque no hay un modelo estandarizado de que arquitectura de como se deben colocar los dispositivos en la DMZ, y esto depende de la calidad de estos, y además daría para otro articulo, lo mas aconsejable y lo que recomienda Garner (la gente famosa del cuadrante mágico), es poner IPS->FW->Balanceadores. Hay gente que coloca el IPS detrás del FW, esta solución es igualmente valida, y se suele aplicar cuando los IPS no son de mucha calidad y no pueden analizar mucho volumen de tráfico, y así evitar que analicen el trafico que el FW ya esta bloqueando.

El primer punto que tenemos que tener en cuenta es como detectar este tipo de ataques, teniendo en cuenta que se trata de peticiones HTTP totalmente válidas. Detectarlo no es tarea fácil. Uno de los métodos para detectarlo seria monitorizar el servidor web de alguna forma. O bien porque detectemos una carga inusual de la CPU o porque tengamos monitorizado el numero de peticiones web que se realizan, esto se puede hacer por algun sistema de correlación y sacando los datos del propio log del servidor.

Una vez que habéis detectado un DDoS y trabajáis en una empresa medianamente grande, todos los jefes o altos cargos que tengan nociones de seguridad van a mirar a los IPS. Los IPS, básicamente lo que hacen es buscar paquetes con trazas concretas en el trafico de red. Nos puede servir para detectar cualquier tipo de ataque tipo SQL Injection, XSS.. o también lo podemos usar para mitigar virus como Conficker. Como veis en la imagen anterior de LOIC, en attack options hay una parte que se llama subtittle, si todos la gente que nos está atacando se pusiera de acuerdo en el ataque y pusiese el mismo subtitulo, si que podríamos generar una firma en el IPS para bloquear esas peticiones HTTP, pero si activan la opción de “append random chars to the URL”, pues nos han fastidiado. No hay manera de diferenciar entra peticiones de ataque o peticiones de usuarios lícitos. Lo ideal seria que los IPS nos permitieran contar el número de conexiones, pero la mayoría de los IPS no son capaces de hacer esto. Y además los IPS no se diseñaron para contar conexiones, se diseñaron más para analizar patrones de trafico. Sobre que un IDS/IPS nos permita contar conexiones va a depender del fabricante. De si este a implementado un modulo con ese fin. Lo normal es que no la incluyan, o que no sea muy fiable.

Entrando en materia:
  1. Una de las soluciones que proponía uno de los fabricantes que mas me llamó la atención, es usar un correlador de eventos como detector de DDoS y usar el IPS para bloquearlo. Es decir, con un correlador correlas el log del servidor web con una regla para que cuente las conexiones web de las direcciones IP durante un tiempo determinado y cuando una IP exceda ese número de conexiones, el correlador se comunica con el IPS y bloquea esas direcciones IP. Por supuesto el fabricante ya tenia un módulo programado entre su correlador y su IPS. Pero podría ser una idea aplicable a cualquier empresa que tenga un sistema de correlación y un firewall, no seria difícil programar una serie de scripts que introdujeran reglas en el firewall. O delegar esta labor a los operadores de red si es que la empresa dispone de una línea de operación 24h.
  2. Otro fabricante proponía otra solución, su producto tenía un sistema o algoritmo de aprendizaje. Con lo que la idea era activar el modo aprendizaje una semana en el que se suponía que el tráfico iba a ser normal, el IPS aprendía ese patrón de tráfico. Una vez realizado el aprendizaje se supone que el IPS podría detectar volúmenes o patrones de tráfico anormales. Esta solución no es especifica para Ataques de tipo Anonymous y me resultaba un poco descabellada. No conozco al detalle como funciona el algoritmo de aprendizaje, pero suponer que una semana, o un mes tras otro, el trafico va a seguir siendo parecido me parece poco sensato, y dependería de a qué se dedica la empresa. Lo cierto es que con reglas así podríamos llegar a bloquear tráfico totalmente lícito y normal, con lo que eso supondría para las empresas.
  3. Investigando por la red encontré información de otro fabricante que ofrecía una solución muy parecida al anterior, tenía un sistema heurístico que era capaz de detectar cambios en los patrones del tráfico de red, pero esta vez sin proceso de aprendizaje.
  4. Por otro lado, tenemos snort que sí que permite definir una regla de tipo threshold para contar conexiones. Esto es básicamente lo que comentaba al principio: contar las conexiones. Pero tenemos que tener en cuenta que snort es en su origen un IDS, aunque se pueda configurar para que también haga labores de IPS. No he podido comprobar si la versión comercial de este IPS propone la misma solución.
  5. Mas tarde y hablando con gente del sector e investigando encontré un aparato que casi sin querer hace justo lo que se necesita para parar este tipo de ataques: se trata de un balanceador de carga web. Como ya sabréis la mayoría, un balanceador de carga web se coloca justo delante de los servidores web y lo que hace es gestionar las conexiones web repartiendo la carga entre varios servidores web. Algunos implementan un módulo para no colapsar esos servidores y lo que hace es muy sencillo: cuando el balanceador ve que el número de conexiones está saturando los servidores web, empieza a bloquear las direcciones IP que mas conexiones esté generando. Esto es justo lo que se necesita para bloquear los ataques de LOIC. Además tiene algo de sentido parar este tipo de ataques con estos aparatos, ya que son los que se encargan de gestionar las conexiones web y LOIC al fin y al cabo genera conexiones legítimas. Pero esto tiene sus inconvenientes; explicar a los altos cargos de la empresa de que disponiendo una infraestructura basada en IPS en Firewall, vas a tener que usar además un balanceador de carga para parar un ataque de DDoS.
La infraestructura normal de una empresa debería ser la siguiente:
Requisitos y Conclusiones:
  • Tenemos que tener en cuenta que para parar un ataque de este tipo nuestra infraestructura y ancho de banda debe soportar el volumen de tráfico del ataque, y por infraestructura me refiero a todo aparato por el que vayan a pasar las conexiones.
  • Si usamos un balanceador de carga para parar un ataque de este tipo, tienes que explicarle a los peces gordos de la empresa que aun teniendo IPS y Firewalls, vas a parar el ataque justo antes del servidor. Esto es comparable a decirles que vives en una casa con alambrada y puerta blindada, y al final paras a los malos en la puerta de la cocina.
  • Debe haber muchas otras soluciones de las cuales yo no tengo noticias, así que os ánimo a que expongáis cualquier otra solución que conozcáis en los comentarios.
  • Aunque Snort nos soluciona la papeleta, el que un software de este tipo no tenga un gran fabricante al que echar las culpas cuando falle, suele echar para atrás a las empresas.
---------------

Contribución por Manuel Bermúdez
Leer más...

28 septiembre 2011

Paquete de herramientas de seguridad

HackArmoury es un repositorio de aplicaciones y utilidades de seguridad que como peculiaridad y característica más importante es su facilidad de acceso.

Las malas lenguas dicen que más de una vez algún hacker ha tenido problemas intentando "subir" a un sistema un sniffer, una puerta trasera o un exploit de elevación de privilegios por la limitada conectividad que tiene el equipo comprometido. 

Para facilitar en estas tareas, HackArmoury permite descargar el las utilidades mediante Samba, TFTP, FTP, RSync, SVN, y HTTP y HTTPS, tanto IPv4 como IPv6.

¡¡Ojo!!, es conveniente verificar la integridad de las utilidades, no vayan a "llevar premio" y en una auditoría se haga un 2x1.

La lista de aplicaciones no es muy amplia, pero poco a poco imaginamos y esperamos que vaya creciendo.



Esta web me ha recordado otra realmente práctica y no excesivamente conocida; el live de sysinternals, a la que se puede acceder mediante SMB (\\live.sysinternals.com) y también dispone de un listado de directorio con todas las utilidades: http://live.sysinternals.com/. 


Y para finalizar, recordaros que Nirsoft tiene una herramienta llamada "NirLauncher" que facilita la descarga y actualización de sus propias aplicaciones, así como las de Sysinternals, joeware y piriform.


Leer más...

27 septiembre 2011

La obsolescencia del modelo Unix

Mucho ha llovido ya desde que Ken Thompson y Dennis Ritchie alumbraran en 1969 el sistema operativo Unix, padre de, entre otros, el sistema operativo Linux.

Conceptualmente, el modelo 'Unix' se basa en que, frente a programas multi-función con múltiples funcionalidades en un mismo programa, se apuesta por un amplio juego de comandos especializados que trabajan de forma cooperativa entre si.

Cualquier persona que haya usado durante algún tiempo Linux, le sonará la famosa 'pipe' | que permite concatenar la salida de un comando hacia otro y en base a eso, construir complejos comandos para generar una tarea.

Yo siempre he sido defensor convencido de ese modelo, de hecho en las ocasiones que me ha tocado desarrollar para un entorno Windows (que por norma general promueve justo lo contrario, programas multi-disciplinares y el uso intensivo de hilos), me ha tocado enfrentarme a equipos 'nativos' que han mostrado oposición al modelo que yo defendía.

Generalmente, una vez explicado que desarrollar en modo-Unix tiene la ventaja de aislar los componentes evitando que el fallo de uno tire al resto, y que a la hora de depurar errores, resulta mucho mas sencillo aislar problemas, he terminado por salirme con la mía, y en los casos en los que no, he cedido de muy mala gana.

Pero visto el panorama actual de Linux, me veo obligado a replantearme mis principios. ¿Motivo? hacer las cosas tan modulares no es escalable y desde el punto de vista de la seguridad, un entorno actual Linux es ingobernable.

Dos ejemplos:

Sistema Linux actual, con un entorno gráfico cargado, un navegador, procesador de texto, cliente de mensajería y algunas consolas abiertas:

$ ps aux | wc -l
293

Mismo entorno bajo Windows (evidentemente y por definición NO es idéntico)

>tasklist /svc | find  /c /v "zzzzzzzzzzzzzzzzzzzzzzzzzz"
61

** Este comando lista los procesos y le entrega la salida al comando Find, el flag /c cuenta el total de líneas y el /v excluye toda línea que contenga "zzzzzzzzzzzzzzzzzzzzzzzzzz" con lo que el comando significa: cuenta todas las líneas que no tengan ese patrón lo que a la postre da el total de procesos ya que ninguno se llama así

La diferencia es evidente: 293 procesos VS 61. Absolutamente imposible de gestionar desde el punto de vista de la seguridad. De hecho, tengo muy claro que a día de hoy, en caso de 'rootear' un sistema Linux, mas que plantearse que rootkit es mejor o peor, resulta mucho más fácil buscar un nombre inocuo (chrome-plugin-helper, por ejemplo) y hacer que se entierre entre la maraña de procesos.

Más aun, Windows implementa de una forma bastante efectiva el firmado digital de ejecutables, lo que facilita notablemente discernir que procesos son mas o menos sospechosos.

En el caso de Linux, si bien la mayoría de paquetes van firmados con una clave GPG, esto no está integrado en las herramientas de gestión de procesos con lo que tienes que ir a mano (o hacerte un script, como ya publiqué aquí) para que haga esa comprobación.

En muchas ocasiones se ha intentado portar el modelo de firma digital de ejecutables y módulos del kernel, pero casi todos estos proyectos no han entrado a formar parte del kernel oficial y han quedado obsoletos, como por ejemplo DigSig. Por otra parte existen herramientas como bsign pero simplemente están ahí, no se ha seguido avanzando en el concepto

En definitiva, tengo la impresión de que si bien este modelo tan cooperativo era excepcional en entornos tipo servidor con pocos procesos, en entornos tipo workstation está completamente obsoleto.

Linux ha hecho increíbles avances en áreas de rendimiento y optimización de recursos a nivel kernel pero le falta, a mi parecer, avanzar en otras capas.
Leer más...

26 septiembre 2011

TuentiDump, descargando cuentas de Tuenti

Desde la publicación de los artículos Tuenti y las redes locales inseguras (1 y 2) muchos me comentaron que la solución que habían tomado era cerrar siempre la sesión para invalidar el SessionID que le hubieran podido capturar y, por tanto, que su cuenta quedara expuesta el menor tiempo posible. Como es lógico, sigue siendo un peligro si se está utilizando una red insegura (y/0 que no es de nuestra confianza).

En los anteriores post se vieron opciones como, por ejemplo, robar un SessionID (que por lo tanto no podría ser invalidado) y en la serie Tuenti Security Issues que está realizando Chema Alonso en El lado del mal seguro que se verán más. Sabemos que estas técnicas son más elaboradas y complejas, reduciendo el número de atacantes que las utilizarían, por lo tanto me voy a centrar en un ataque que solo incorpore un ataque MITM y monitorice en busca de SessionIDs (por ejemplo la utilización de aplicaciones como Firesheep, Faceniff, TuentiSniffer, ...).

Hace unos meses (¡mas de los que me hubiera gustado!) dimos en mi universidad una serie de charlas sobre seguridad en redes y servicios web y en una de ellas quise demostrar como el más mínimo descuido puede poner en jaque nuestra cuenta. Para ello, desarrolle la aplicación TuentiDump que monitoriza el tráfico y descarga todo el contenido de la cuenta de Tuenti comprometida, almacenando en una base de datos (SQLite) toda la información (permitiendonos un análisis posterior más cómodo).

La aplicación descarga la información personal del usuario (nombre, apellidos, dirección, teléfonos, email , twitter, páginas web, ...), los mensajes del tablón/wall, las imágenes y su información y los mensajes privados. Hay alguna información cuya obtención no ha sido implementada (tablones y comentarios en imágenes) que es sencillo de añadir pero que en este caso no me ha preocupado.

La descarga y almacenamiento de la información se realiza en tres etapas.
  1. Se realizan todas las peticiones web necesarias guardando en bruto (sin procesar) las respuestas. De esta forma conseguimos reducir al máximo el tiempo en el que el SessionID ha de ser válido.
  2. Se procesa toda la información obtenida en la etapa anterior dejando los datos listos para almacenarlos en la base de datos. Además, en esta etapa se pueden descargar todas las imágenes de la cuenta (para acceder a éstas no es necesario estar autenticado)
  3. Se genera la base de datos y se almacena en ella toda la información.
Ahora bien, lo más importante ... ¿cuanto tiempo tarda?.
En las pruebas que he realizado con mi portatil (algo limitado) la etapa de descarga (que es la crítica) tarda alrededor de 120 segundos (la limitación se encuentra tanto en el equipo como en la conexión). En la universidad y con un equipo más decente conseguí bajar la cifra a 50 segundos (lo más lento es la descarga de los datos de las imágenes, desactivandolo los tiempos se reducen a la mitad).

La aplicación permite elegir el número de hilos, las páginas del tablon (10 elementos por página) y las de imágenes (25 elementos por página) que se procesaran por cada hilo. Es recomendable jugar con estos parámetros para conseguir el máximo rendimiento.

Con respecto a los datos obtenidos, la información más interesante/crítica se suele encontrar en los mensajes privados. Por lo tanto, lo que un atacante seguramente no hubiera visto simplemente suplantando la cookie, ahora sí que queda expuesto.

A continuación podéis ver una captura de TuentiDump descargando mi cuenta de Tuenti, los tiempos completos y la estructura de la base de datos que genera:






Con respecto a la aplicación, no es ninguna maravilla (y claramente Java no era la mejor opción) pero para las pruebas era suficiente. Le he corregido algunos bugs y he publicado su código fuente en:
http://www.ldelgado.es/?tuentidump

Como conclusión decir que con esta aplicación simplemente quería dar cifras a algo ya conocido y mostrar como hasta la más mínima exposición puede comprometer al completo nuestra cuenta y permitir a un atacante analizar, con todo el tiempo que necesite, toda la información contenida en la misma.

-------------------

Contribución por Luis Delgado
Leer más...

25 septiembre 2011

Enlaces de la SECmana - 90

Leer más...

24 septiembre 2011

SbD en el podcast #explícalo de Blogoff

El jueves pasado estuvimos en el podcast #explícalo de Blogoff. Para el que no lo conozca, se trata de uno de los podcasts mas relevantes del panorama hispanohablante.

Anteriormente han participado gente como Antonio Ortiz o el equipo de 'Amazings'

El podcast dura 50 minutos y en el hablamos sobre seguridad en general, Anonymous / LulzSec y eventos de seguridad como Rootedcon.


Explícalo - El podcast de Blogoff en Spreaker



Aprovechando que estamos en la fase de votación de los premios Bitácoras, podéis votar a Blogoff en la sección de mejor podcast

¡¡ Muchas gracias Juan !!
Leer más...

23 septiembre 2011

Una autenticación fuerte para Openvpn



Exponer a internet un servicio es siempre un punto de entrada para todo tipo de amenazas. Por supuesto, el nivel de riesgo dependerá de la configuración del servicio, el grado de actualización del software y las medidas de seguridad que tomemos para utilizar dicho servicio.

En mi caso, para acceder a mi red, utilizo OpenVPN. El objetivo, como comenté en uno de mis primeros posts en Security By Default (no ha llovido ni nada desde entonces), es estar conectado, esté donde esté. Respecto a OpenVPN, poco queda que contar que no hayamos hecho ya. Nos permite tener la conectividad con nuestras redes, a miles de kilómetros, como si estuviéramos en la oficina o en el salón de casa. Nuestro tráfico irá autenticado y cifrado mediante OpenSSL, utilizando una PKI, con certificados, tanto en el cliente como el servidor, para asegurar que somos quienes decimos que somos.

Desde 2004 hasta hace relativamente poco, mi configuración principal de OpenVPN era por TCP, utilizando un mecanismo port-knocking basado en TCP Wrappers que abría durante 20 segundos la posibilidad a establecer conexiones contra el servicio final. Pasados esos 20 segundos, no se permitían conexiones nuevas por lo que el grado de seguridad era de nivel paranoico para arriba. En realidad, los internals de la configuración eran algo más complicados, puesto que, al menos antiguamente, OpenVPN no permitía utilizar TCPwrappers, por lo que utilizaba Xinetd (que sí que los habilita) para publicar el TCP 443 al exterior durante 20 segundos y hacer un bind al TCP 444 que es donde corría realmente el servicio OpenVPN.

Sin embargo, harto de no poderme conectar a través de redes wireless públicas gratuitas, decidí cambiar mi filosofía del seguridad al 100% mientras no exponga el servicio, y cambié la configuración de OpenVPN al puerto 53 UDP. Quisé probar si los portales cautivos de determinadas redes gratuitas en aeropuertos, estaciones, hoteles, etc,… no controlaban correctamente que el tráfico que permitían salir al exterior fuera realmente DNS. Lo que me he encontrado en estos días de pruebas, es que efectivamente se comprueba que el tráfico enviado sea DNS, por lo que hay que buscar otra forma. No parece que haya más remedio que utilizar alternativas como Iodine o DNS2TCP ya comentadas en SbD en posts anteriores. Sin embargo, por lo que he leido, Iodine no utiliza cifrado de ningún tipo en el envío del tráfico, por lo que podría tunelizarse OpenVPN dentro del propio túnel Iodine, para asegurar que todo viaja cifrado.

Así pues, este cambio "para ganar en funcionalidad", me hará perder en "seguridad", estando el servicio abierto permanentemente a Internet por mucho que Iodine pueda configurarse para requerir una contraseña de acceso.

Me diréis: "Oye Lorenzo, pero si tienes montada tu propia PKI y utilizas autenticación con certificado de cliente, alguien tendría que tener tu certificado para poderse autenticar. Es un buen nivel de seguridad tal cual ¿No eres demasiado paranoico?" La respuesta es: "Sí, soy paranoico, pero si pierdo físicamente mi portátil, la sesión está abierta, es 29 de febrero, la luna está en cuarto creciente y el Logroñés vuelve a primera división y ficha a Messi y a Ronaldo, entonces es posible que presionando un botón, el que me ha robado y ha salido corriendo con mi Mac, esté en mi red".

Así pues, y dado que trabajo para un fabricante de soluciones de autenticación fuerte, quise darle una vuelta de tuerca y aprovechar que tengo licencia gratis para utilizar la solución de Swivel  :D

OpenVPN permite, realizar autenticación de doble factor utilizando algo que tienes (el mencionado certificado SSL) y algo que conoces (un usuario/contraseña por ejemplo).
Ya hemos contado en SbD, cómo OpenVPN permite utilizar usuarios de un directorio LDAP, por ejemplo. En este caso y dado que será Pinsafe quien provea autenticación mediante OTC (One-Time-Code como variante de One-Time-Password), integraremos esta autenticación contra un servidor RADIUS.

Este procedimiento serviría para integrar VPN con cualquier servidor RADIUS, aunque en este caso, además tiene la ventaja de que la contraseña a utilizar cambia en cada autenticación.


Cómo se hizo:
  • Parto de una máquina virtual en la que está instalado el servidor RADIUS en el que delegaré el segundo factor de autenticación en la IP 192.168.52.3.
  • Así pues lo primero es configurar en Swivel Pinsafe los parámetros necesarios para permitir que la IP del servidor openVPN pueda hacer consultas Radius utilizando un secreto compartido.
  • En el servidor OpenVPN instalamos el paquete pam_radius. En el fichero de configuración del propio servicio Openvpn (/etc/openvpn/openvpn.conf) añadimos la línea 
       "plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so openvpn"  
  • En el fichero /etc/pam_radius.conf añadimos una línea de la forma: 
     "192.168.52.3    atitelovoyacontar     10" ->  IP del servidor RADIUS // clave compartida // timeout
  • En el fichero /etc/pam.d/openvpn indicamos que este servicio utilizará el módulo pam_radius_auth.so. Para ello añadimos las siguientes líneas en dicho fichero.
      auth required pam_radius_auth.so no_warn try_first_pass
      account required pam_radius_auth.so

  • Reiniciamos el servicio openvpn -> /etc/init.d/openvpn restart
  • En el fichero de configuración del lado cliente, deberemos añadir la línea "auth-user-pass" de manera que antes de efectuar conexión alguna contra el servidor, el programa cliente pida usuario y contraseña (en este caso de un sólo uso) para enviarlo al servidor.
  • Así pues, cuando desde mi Mac me conecto con Tunnelblick, ahora me pide usuario y contraseña, siendo en este caso, de un solo uso.

Leer más...