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...

22 septiembre 2011

Configuración de servidor VPN PPTP para iOS sobre Linux

Cuando estuve este verano en la BlackHat de Las Vegas, de la que por cierto tengo pendiente contaros mis impresiones, monté una VPN basada en PPTP, como ya hiciera el año pasado para Android, solo que en esta ocasión, iba a ser usada con el iPhone e iPad que me acompañaban con iOS4

Seguí los mismos pasos que en la instalación anterior, pero hubo que modificar alguna cosa para que aquello funcionase.

Es imprescindible saber que existen problemas de compatibilidad y licenciamiento entre las versiones de pptpd, pppd y el kernel de linux para que todas ellas soporten el protocolo punto a punto de Microsoft (MPPE), que se requiere para cifrar los datos y que todo esto funcione como debe.

Hay versiones que no son compatibles entre sí, por lo que hay que descargar el código fuente, parchearlas y finalmente instalarlas. En mi caso uso Centos 5.7 con los siguientes paquetes instalados que no requieren ser modificados:

[root@tutu tmp]# rpm -qa |egrep "kernel|ppp"
kernel-2.6.18-274.el5
ppp-2.4.4-2.el5

Además de tener cargados los correspondientes módulos del kernel:
[root@tutu ~]# lsmod | grep mppe
ppp_mppe               10437  0
ppp_generic            30036  2 ppp_mppe,ppp_async

Lo primero que hice fue instalar poptop, descargándolo de su página oficial y creando un RPM:
mkdir -p ~/rpmbuild/SOURCES/
cd ~/rpmbuild/SOURCES/
wget "http://downloads.sourceforge.net/project/poptop/pptpd/pptpd-1.3.4/pptpd-1.3.4.tar.gz"
tar -zxvf pptpd-1.3.4.tar.gz
chown -R rpm:rpm pptpd-1.3.4
cd pptpd-1.3.4
bash makepackage
sudo rpm -ivh ~/rpmbuild/RPMS/x86_64/pptpd-1.3.4-1.fc12.x86_64.rpm
Una vez instalado, modifiqué tres ficheros de configuración tal que así:
Fichero: /etc/pptpd.conf
option /etc/ppp/options.pptpd
localip 192.168.2.100
remoteip 192.168.2.101-151
Fichero: /etc/ppp/options.pptpd. 
lock
name *
proxyarp
deflate 0
auth
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 8.8.8.8
ms-dns 8.8.4.4
mtu 1450
mru 1450
nobsdcomp
novj
novjccomp
nologfd
nopcomp
noaccomp
debug
Ojo, que esto no se puede incluir en el fichero anterior, uno no está añadiendo el contenido del otro, aquí se puede cambiar los DNS (8.8.8.8 y 8.8.4.4) por los que más rabia os den.
Fichero de usuarios y contraseñas: /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
aramosf         *       G0giAntS!            *
En cuanto al móvil es muy sencillo. Tan solo hay que ir a: Ajustes->General->Red->Vpn y añadir un nombre a la configuración, la dirección IP de nuestro servidor Linux, el usuario y la contraseña, indicar que use la "máxima" encriptación y que envíe todo el tráfico por la VPN. Tal y como muestra la siguiente imagen de ejemplo:

Leer más...

21 septiembre 2011

Vuestros "ETHERNET EXPOSED" - V

Nueva edición de nuestra sección ETHERNET EXPOSED, que pretende descubrir tomas ethernet que se encuentren expuestas en lugares curiosos.

Seguís mandando contribuciones con imágenes que vais encontrando y fotografiando, y con esta serie de posts de "Vuestros "ETHERNET EXPOSED" iremos publicando poco a poco todas ellas, siempre y cuando resulten claras y como no, accesibles. Os animamos a participar, ya que quizás muy pronto podamos ofrecer alguna que otra sorpresa acerca de todo este movimiento, que esperamos que crezca más y más.

Empezamos por el primer aporte, que nos ha enviado "WhileTrue", con el siguiente mensaje:

"Una vez finalizada la NoConName 2011 me gustaría aportaros un par de fotos del "Cosmo Caixa" en las cuales me he dado cuenta que dejaron en un lugar un poco extraño unas tomas ethernet. Creo que es curioso, principalmente porque muchos de los lectores SBD estuvimos presentes en dicho congreso y me extraña que pasara desapercibido."



Como nos comenta WhileTrue, este par de tomas se encontraban a la entrada de una de las salas del complejo. Quizás en los momentos de entrada y salida a la sala, si no hubiese mucha afluencia de público en esos momentos, se podría aprovechar a echar un vistazo a la red...si tuviésemos la suerte de que las tomas nos diesen acceso.

La siguiente imagen nos la envía Shyish, comentándonos en su e-mail:

"Es de una pantalla informativa de una estación de trenes. Se puede apreciar que, además de tener un par de puertos USB, también está conectada mediante el tipico RJ45 a la red."


Quizás la localización y alcance nos deje poca libertad a la hora de poder juguetear con este punto de acceso ethernet, pero si nos pusiésemos el gorro de "vandalismo" y pegásemos un tirón, quién sabe lo que ocurriría. No vendría mal un poco más de carcasa para tapar alguna que otra conexión.

Nuestro último ETHERNET EXPOSED de hoy corresponde con una nueva contribución por parte de nuestro compañero Lorenzo. Es una suerte que pueda viajar de vez en cuando, ya que siempre nos trae alguna que otra anécdota en forma de instantánea. Ojo a lo siguiente, que va más allá de una simple toma de red, ya que es importante destacar de quién es dicha conexión:

"Te envío un Ethernet Exposed que tuve la oportunidad de "pillar" en una visita que hice a la Universidad de Coimbra en Portugal, en estas vacaciones. Acojonante! El sitio donde estaba era super oscuro y sirve para una máquina de recargas de vaya usted a-saber-el-qué. De hecho si tuviera que estudiar en esa universidad estoy seguro que sea lo que sea que esa máquina recargara, iba a salir muuuuuucho más barato ;D"


 

Tras hacer un pequeño profiling de este sistema que incluye un rótulo SafeQ Recharging Station, se trata de un puesto de recarga de crédito/saldo para este tipo de tarjetas de crédito SafeQ, ideales para bibliotecas y centros de estudio.

De nuevo, muchas gracias a todos por vuestras imágenes, y ¡no dudéis en seguir enviándonos más ETHERNET EXPOSED!
---------------
[+] ETHERNET EXPOSED: Encuentra tomas de red al descubierto
[+] Vuestros "ETHERNET EXPOSED" - I
[+] Vuestros "ETHERNET EXPOSED" - II
[+] Vuestros "ETHERNET EXPOSED" - III
[+] Vuestros "ETHERNET EXPOSED" - IV
[+] Vuestros "ETHERNET EXPOSED" - V
Leer más...

20 septiembre 2011

Seguridad en Instalaciones - Parte 2: Seguridad Electrónica

Podréis encontrar la primera parte en este especial sobre Seguridad Física de Ricardo Ramos en:
+ Seguridad en Instalaciones - Parte 1: Seguridad Física

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

Elementos Activos - Seguridad Electrónica.
Los elementos activos se encargan de monitorizar y/o alertar de una posible intrusión o sabotaje. Éstos se pueden clasificar como sigue:

  • Detección de intrusos en el interior y en el exterior.
  • Control de accesos personas/objetos.
  • CCTV.
  • Avisos.
  • Detección de intrusos en el interior y en el exterior. Sensores.
Los hay de todos los colores y sabores. Se pueden dividir en cuatro categorías en función de la cobertura de detección.

    1. Puntual. Sensor magnético. Se colocan en puertas, ventanas o similar.
    2. Lineal. Láser, infrarrojo. Ideales para zonas angostas.
    3. Superficie. Presión. Se instalan en suelos, vitrinas con objetos valiosos, etc.
    4. Volumen. Microondas, infrarrojos, etc. Cubren amplios espacios, habitaciones, salas, etc.
A continuación se muestra un ejemplo de la tecnología utilizada. Dicha tecnología puede utilizarse en distintas coberturas. Por ejemplo, la tecnología infrarroja podría utilizarse como sensor de tipo lineal o volumétrico.
  • Magnéticos. Sensores muy simples. Dos puntos están en contacto, pasa corriente eléctrica. Cuando se produce una intrusión (abertura de una ventana, por ejemplo), se produce una diferencia de potencial que activa la alarma. Son sencillos de sabotear.
  • Láser. Se suelen colocar en zonas de detección muy determinada, como pueden ser ventanas, puertas, cajas fuertes, pasillos, etc. A mayor número de sensores mayor cobertura de detección. Es común ocultar este tipo de sensores porque su inhabilitación es relativamente sencilla. Son utilizados tanto en interior como en exterior. Requieren de visibilidad entre el transmisor y receptor y por tanto no puede haber obstáculos entre ellos. Le afecta las condiciones climáticas que puedan dificultar la visión entre el transmisor y receptor, como hemos comentado anteriormente.
  • Inducción. Este tipo de sensores mide la alteración de un campo de inducción (o magnético). Detectan el paso de un objeto metálico. El tamaño de dicho objeto irá en función de la calibración del sensor. Estos pueden presentarse en forma de arco de detección, como el que hay en los aeropuertos o pueden instalarse en el suelo, de tal forma que al pasar un vehículo o persona puedan detectar su presencia. Se han utilizado a modo de radar y cuenta la leyenda que los israelíes tiene todo el perímetro de sus fronteras (al menos las más "calientes") rodeado por este tipo de sensores. De tal forma que cualquier persona con un mínimo objeto metálico es detectado de inmediato (mínimo = clavos de los zapatos). Este tipo de sensores, muy a groso modo son dos cables que crean un campo magnético entre ellos. Como se puede observar no sirve ante objetos no metálicos. No les afecta la climatología (exceptuando tormentas eléctricas).
  • Microondas. Basados en el efecto doppler. Suelen cubrir un entorno en forma de óvalo. Se suelen instalar en el interior de zonas cerradas. Sensores muy efectivos pero que se han de calibrar correctamente porque puede llegar a traspasar paredes o muros y provocar falsos positivos al detectar “intrusiones” en zonas aledañas. En el exterior les puede afectar la climatología (niebla densa, lluvia intensa, etc.).
  • Infrarrojos. Miden la radiación electromagnética infrarroja que irradian los cuerpos. Son sensores que se adaptan mejor en estructuras internas porque les afecta, como es lógico las condiciones climáticas. Cuidado al orientar este tipo de sensores hacia ventanas, puesto que la exposición directa del sol puede provocar falsos positivos.
  • Ultrasonidos. También basados en efecto doppler. Capaz de atravesar obstáculos físicos. Les afecta en menor medida los elementos climáticos (comprobar) y pueden cubrir grandes distancias.
  • Vibración. Todos conocemos su utilización a la hora de medir terremotos. También son muy utilizados en cajas fuertes, detectan movimiento (perforación, taladro,…) sobre una superficie.
  • Otros. Temperatura, posición, presión, lumínicos, acústicos y un gran etc.
Un error habitual en los dispositivos sensores es no eliminar u ocultar el típico LED que se enciende cuando se activa. Por ejemplo, el volumétrico qué cuando una persona pasa por delante se activa (detecta a la persona) y podríamos conocer su alcance porque se ilumina el LED. Esta es una información que debería ocultarse. Hay circunstancias que pueden no haberse tenido en cuenta a la hora de instalar y "configurar" los sensores. Un ejemplo, volumétrico (infrarrojos) apuntando a una ventana puede verse afectado por la exposición directa del sol, o en puestas, etc. Por último, decir que nos podemos encontrar sensores de doble tecnología (microondas+infrarojos, por ejemplo), que sólo en caso de que ambas tecnologías detecten, envían la señal de alarma. De esta forma se minimiza la posibilidad de falsos positivos.
  • Sistemas Control de Acceso.
Son sistemas que en función de un criterio definido permiten o impiden el acceso a determinado lugar. Tornos (manuales o automáticos), esclusas, barreras, puertas, lectores de proximidad, biométricos, electromagnéticos, etc.
  • CCTV.
Muy asociado a la defensa perimetral. Todos conocen y saben para qué sirven los circuitos cerrados de televisión. Efectivamente, nos permite observar lo que sucede a nuestro alrededor (el alrededor de la cámara, claro).

Las cámaras pueden ser a color (mayor realismo) o en blanco y negro (mayor definición), alta definición. Las hay adecuadas a la luz diurna, luz artificial, nocturnas, etc. Incluso con la luz de las estrellas pueden obtener imágenes de calidad (made in Israel). Las hay motorizadas o estáticas (las primeras tienen la ventaja de cubrir más amplitud pero a su vez es una desventaja).

Pueden detectar movimiento, mediante el software adecuado, de la imagen y alertar al operador o disparar alguna acción. Como cualquier sensor se ha dimensionar correctamente para no obtener falsos positivos. Si se configura muy sensible puede que salte la alarma con cualquier animal pequeño (un gato, un ave, etc.) si, lo ponemos poco sensible, puede que no detecte un intruso. Así que a afinar.
Un fallo muy común son los ángulos muertos, zonas que las cámaras no cubren. Esto ocurre cuando dos cámaras puestas en un mismo punto apuntan a dos direcciones diferentes. Lo ideal, es que una cámara cubra el perímetro y a la vez a la siguiente cámara (en fila) de esta forma, podremos eliminar los puntos muertos así como cualquier manipulación directa sobre la cámara. Por supuesto, normalmente detrás de una cámara deberá haber un operador, si no como que la cosa no funciona igual (excepto las cámaras con sensor de movimiento). Por último comentar que puede llegar a ser interesante el ocultar las cámaras por cubiertas opacas, con objeto de no revelar información sobre qué puntos "vigilan" dichas cámaras.
  • Avisos.
Es importante poseer un sistema de avisos ante intrusiones o anomalías, para poder dar aviso (en caso necesario) a la amenaza o para coordinar la seguridad de las instalaciones. Para ello existen sistemas de megafonía para dar avisos y/o instrucciones a “gran” escala, interfono, para comunicaciones puntuales y precisas. Otros sistemas acústicos son sirenas, bocinas, silbatos (muy utilizados en la mar). También se pueden contar con señales lumínicas, iconos, pictogramas, etc.

Comentarios finales:

Las medidas, lógicamente, tienen que estar coordinadas entre sí. De esta forma se reducen fallas y se aumentan capacidades. Todo tiene que ir aderezado con su pertinente plan de seguridad, donde se definen las medidas, las actuaciones, plan de contingencia, plan de formación, etc. Importante, este plan debe estar “bendecido” por la dirección. La seguridad es algo muy molesto para el usuario, que si no hay una correspondencia desde las altas instancias se dificultará su cumplimiento.

No se ha mencionado nada sobre sistemas contraincendios, protección eléctrica (grupos autógenos, SAIs,…), protección electromagnética (TEMPEST), (SIGINT), etc.

Por último indicar que se ha pretendido dar un repaso muy genérico de la seguridad física, tratando de abarcar mucho sin profundizar, puesto que el tiempo (y el espacio) es limitado, así como la paciencia del lector.

-------------------
Contribución por Ricardo Ramos
Leer más...

19 septiembre 2011

Resumen de NoConName 2011 #ncn2k11


Al igual que el año pasado, la segunda edición después de la resurrección de la NoConName, la primera de las Cons españolas, organización presidida por José Nicolás Castellano, se ha celebrado en Barcelona. Como ya comunicamos en SbD, tuvimos el placer de estar presentes a lo largo del evento, disfrutando de las charlas e incluso moderando una interesante mesa redonda del segundo día.

En el artículo de hoy, voy a aunar las notas que tomé de cada una de las charlas a las que pude asistir.

Día 1:

  • Show me your Kung Fuzz: Iñaki Rodríguez expuso de una forma muy muy divertida qué es el fuzzing así como diferentes herramientas y entornos a utilizar para lograr fuzzear diferentes aplicaciones, dependiendo del tipo que éstas sean. "La frase" que caló hondo entre todo el público fue: "Cuando los padres de las compañeras de mi hija me preguntan qué es eso del fuzzing al qué me dedico les contesto:  Hacer fuzzing es meterle mierda a una aplicación hasta que revienta".
  • Seguridad en el diseño: desde el principio: En esta charla, Ricardo Rodriguez de la Universidad de Zaragoza, nos hizo una propuesta con modelado UML, para incorporar seguridad a las propias metodologías de desarrollo de aplicaciones para sistemas, evitando el "Fix it later". Nos recomienda lo que muchas veces hemos comentado desde SbD, que es mejor hacer las cosas bien desde el principio, pensando en la seguridad desde el minuto 0.
  • Geolocalización wifi basada en API: El conocido Yago F. Hansen, especialista en seguridad de Diario de un Hacker, relató en una muy entretenida charla las diversas posibilidades que ofrece la geolocalización en el mundo actual. Comenzó hablándonos de las necesidades de saber dónde estamos desde un punto de vista histórico, que desde muy antiguo se hacía un análisis de la posición de las estrellas, la utilización de astrolabios y otras herramientas, hasta llegar al actual protocolo GPS, el A-GPS (con las mejoras que se introducen al GPS para optimizar el Time to First Fix utilizando red de Telefonía móvil en Tierra). Habló igualmente de otras técnicas utilizadas por los dispositivos móviles para identificar mediante GSM/CDMA la celda más cercana a la que estás conectado. Asimismo nos indicó cómo se utiliza la API de Google para, introduciendo como parámetros el LAC, Cell ID, MNC, MCC, nos sitúe en Google Maps con una muy buena precisión. Habló igualmente de la aplicación Signal para Iphone para conocer los datos de los diversos puntos de telefonía de nuestro alrededor, así como de la existencia de troyanos incorporados en juegos y aplicaciones móviles que roban información de geolocalización para ser utilizada en botnets; otros para espiar la localización de la gente como SpyYourWife. Como podéis ver, el tema y la charla en sí, me encantó, además por la gracia y fluencia de Yago exponiendo las cosas, que es un valor añadido.
  • Terminal Hackpplications: Chema Alonso y Juan Garrido Silverhack nos desvelaron a primera hora de la tarde, de una forma muy divertida, las inseguridades de la ejecución de programas en servidores de aplicaciones remotos mediante protocolos como ICA de Citrix o Terminal Server. En este caso utilizaron Excel en un escritorio remoto para ejecutar comandos de sistema, e incluso saltándose políticas de protección de dominio. Fue una charla muy muy muy sorprendente y recomendable que ya fue expuesta en la BlackHat USA de este año. Tiene que haber sido divertido verles dar esta charla en la Defcon en Las Vegas, por las alusiones a sitios americanos… Estoy seguro que tiene que haber habido momentos de sudor frío en la aduana del aeropuerto por saber si salían del país dirección Barajas o si les ponían un traje naranja!
  • Ejercicios de demostración JWID (Joint Warrior Interoperability Demonstration): Pedro Sanchez del conocido blog de seguridad Conexion Inversa, nos habló de ciberguerra, con ejemplos de corte muy militar, mencionando prácticas llevadas a cabo entre grandes superpotencias como China, Israel o USA. CWIX son eventos anuales de la OTAN en los que los asistentes, todos militares, participan en una especie de CTF o wargame simulado con un laboratorio de máquinas virtuales con entornos vulnerables a fin de efectuar lo más parecido a "maniobras militares" pero con un teclado en vez de un fusil.
  • Medical Device Security: State of Art: Shawn Meringer, expuso los actuales riesgos de seguridad en dispositivos médicos como marcapasos, monitores de glucosa, oxígeno, etc,…  poniéndolos como ejemplo de sistemas SCADA conectados a seres humanos, contó cómo podrían integrarse con la red wireless de casa para enviar información en tiempo real al médico. Sin embargo, esos datos, al no ser recolectados de forma directa por el médico, podrían ser interceptados e incluso alterados. Otros riesgos observados por él son la utilización de los mismos ordenadores de propósito específico médico (para analizar datos de los pacientes) para propósitos generales, como mirar hotmail, yahoo o gmail por parte de médicos o secretarias. Asimismo, existe otros riesgos que pueden generar problemas derivados por fallos de suministro eléctrico (en caso de un ataque SCADA que afecte a la ciudad completa o a los sistemas de suministro eléctrico del propio hospital, por ejemplo); ingeniería social por parte de gente que suplantaba la identidad de médicos, empleados maliciosos,… Contó una anécdota en la que por un fallo en el software de los antivirus McAfee que es el que tenían desplegado de forma corporativa en el hospital, hacía que se reiniciaran todos los PCs nada más arrancar, haciendo que nadie pudiera trabajar.


Día 2:

  • Técnicas oscuras para combartir la pedrastia en Internet: Desfortunadamente llegué tarde a esta charla (pillé un poco de atasco entre las sábanas de la cama). Sin embargo, por lo que he leído en Twitter, Juan Antonio Calles y otro compañero de FluProject contaron cómo, desde el gobierno de Colombia, les pidieron ayuda para capturar a un escurridizo pedrasta utilizando el troyano de The Flu Project para controlar remotamente el PC del pedrasta.
  • The Sibyl (La Sibila): Pedro Fortuny, matemático de la Universidad de Oviedo muy amenamente, nos habla sobre la (in)seguridad/debilidad de algunos tipos de hashes, así como la inutilidad de no hacer nada y guardarlo en texto claro. Si la máquina es comprometida, es posible llevarse los hashes y terminarlos reventando con ataques de fuerza bruta o diccionario. Así pues, nos presenta una herramienta, The Sibyl, como mecanismo de autenticación más segura (según sus palabras textuales, "inhackeable") utilizando PKI añadiendo una clave aleatoria RSA de (creo) 160 bits corriendo en un tercer servidor. Además presentaron un módulo PAM para poder integrar la autenticación a otros servidores con The Sibyl.
  • (In)seguridad para jugones: Rafael Rodríguez de Deloitte nos "deleitó" con una genial presentación sobre los mecanismos actuales para vulnerar controles de seguridad en casinos físicos. Entre otras cosas nos detalló cómo se alteraban dispositivos como máquinas tragaperras, ruletas, barajas de cartas, etc,…  así como los riesgos de las máquinas actuales al formar parte de una arquitectura PC interconectadas; también la colaboración de técnicos internos, hasta grandes golpes del estilo Ocean's. Además nos habló de los riesgos del juego online: aplicaciones hechas en Flash, gente compinchada hablando por otro canal…. así como las medidas de seguridad empleadas: operadores humanos, interacción con jugadores, listas negras de jugadores compartidas entre casinos, aplicacaciones cliente nativas con sus propias medidas de seguridad (como fingerprinting hardware, IP, etc,...)
  • Debugging (Exploit) Payloads: Nuestro buen amigo José Selvi, del blog Pentester.es nos ayuda en la problemática sobre qué hacer, cuando al lanzar un exploit, éste no funciona, como le llegó a pasar a él en una auditoría por un problema del idioma de la máquina a atacar. En ese caso, cuando un exploit de metasploit utilizado para Internet Explorer, fallaba con las rutas de una máquina en español. Muy interesante también el trabajo que hizo Jose en descomponer el exploit de Comex para hacer un jailbreak de Ipad mediante la visualización de un fichero PDF. Así pues, lo que hizo fue modificarlo con su propio payload, re-crear un PDF nuevo para que al abrirlo con el Ipad, envíe una shell a una máquina remota con privilegios de root.

  • Retorno de Inversión en la adecuación a la normativa PCI-DSS: Javier Moreno Molinero de Internet Security Auditors nos trajo una conferencia, que por el tipo de tema que es, podría haber sido poco apetecible. Sin embargo, la amena forma de exposición, así como los ejemplos puestos, nos dió las pautas para justificar la compra de un equipamiento nuevo (antivirus, firewalls, etc, etc…), o enseñarnos por qué muchas veces las empresas preferen asumir el riesgo de no protegerse o no cumplir una determinada normativa y finalmente resultar sancionada en caso de una incidencia. En sus ejemplos, salía más rentable prevenir, haciendo lo necesario para certificarse en PCI-DSS, antes que curar.
  • Reversing/Forensic Android: Nuestro colaborador habitual Sebastián Guerrero, dio una excelente conferencia. En ella, detalló qué infraestructura se necesita para analizar aplicaciones Android a través de un emulador, simular el envío de pulsaciones de teclas, para lanzar la ejecución de malware hecho para Android. Identificó de una forma brillante las dificultades que se introducen en los distintos tipos de malware para evitar los análisis, como por ejemplo, hacer que vibre el móvil (si detecta que no ha vibrado, es que se ejecuta en un emulador y el programa no hace nada). Fue muy interesante igualmente la exposición del análisis forense realizado por Sebastián de un malware realizado por una empresa china, en la que incluso el desarrollador publicaba, con su nombre, cómo extraer las conversaciones de audio desde Android porque no le funcionaba!!!!   
A nivel personal, quiero decir que me lo pasé genial en este par de días en los que asistí a la NCN, por primera vez. Además de lo interesante de las charlas, fue para mí muy gratificante desvirtualizar a unos cuantos de vosotros, lectores, y animarme mucho más a mí y al resto de mis compañeros gracias al positivo feedback que manifestasteis.

Quiero dar las gracias a la organización de NCN por la oportunidad, en especial a @jncastellano por el excelente trato recibido estando allí.  

Fue para mí un placer también volver a ver a los ya fieles de estos eventos de seguridad: @ZXLain, @Chemaalonso, @wzzx, @joseselvi, @BBerastegui (que además realizó un SOBRESALIENTE coverage del evento vía Twitter), @mgesteiro, @trufae, etc, etc,… 

Nos vemos en el siguiente sarao, que será pronto!
Leer más...

18 septiembre 2011

Enlaces de la SECmana - 89

Leer más...

17 septiembre 2011

Hackers de leyes

Imagino que mucha gente ya estará al tanto de lo sucedido el jueves pasado y le sonará el hashtag #tablasinde

Para el que no lo sepa, aquí va una explicación breve: El jueves pasado, durante el festival de cine de San Sebastián, David Bravo hizo una demostración pública de una vulnerabilidad que afecta a una ley (la ley Sinde).

Anteriormente, nosotros ya 'auditamos' la ley Sinde y ahora David ha 'liberado un exploit'
 
El planteamiento, muy resumido, consiste en que si la 'Ley Sinde' pretende perseguir a los sitios web donde se almacenan enlaces a contenidos que, puedan ser susceptibles a tener derechos de autor, lo que David hizo fue pedir desinteresadamente a la gente -vía twitter- que emplease la plataforma Google Docs para crear listas con enlaces, y claro, ley en mano, supone que 'las autoridades competentes' deberían proceder al cierre cautelar de ... Google, o al menos, generar una advertencia hacia Google, ya que es ahí donde se almacena el contenido.

Evidentemente la prueba de concepto es demoledora, cualquiera puede crear un documento en esa plataforma, y es virtualmente imposible monitorizar *todos* los documentos.

Lo que me gusta del concepto es que, si cambiamos ley por software, lo que ha hecho David se asemeja mucho a lo que haría un investigador en seguridad: detectar la vulnerabilidad y exponer una prueba de concepto. Simplemente genial
De hecho, desde ya, queda lanzada la petición a la organización de Rootedcon para que contacten con David y 'lo fichen' para la próxima edición

Esperemos que no aparezca ningún iluminado y proponga como 'bugfix' empezar a legislar contra el usuario 
Leer más...

16 septiembre 2011

¿Dónde quieres viajar? Al botón de INICIO

Si bien estamos a punto de dar por concluído este verano, no por ello quiere decir que no podamos seguir buscando posibles destinos para alguna que otra escapada de aquí a final de año. Existen muchas opciones para poder planificar unas vacaciones o elegir un destino en concreto si todavía no lo tenemos claro: podemos acudir a una agencia de viajes como siempre se ha hecho, utilizar los típicos buscadores múltiples de las mejores ofertas entre varias compañías, consultar catálogos según destino para poder "soñar con estar ahí" mientras pasamos páginas...y ahora podríamos encontrar estos mismos catálogos de viajes llevados a su máxima expresión digital.

Con esto no me refiero a pasarlos a PDF, sino de directamente consultarlos con un dedo en pantallas táctiles, bastante grandes y con buena resolución, colocadas en agencias de viajes de alguna que otra cadena de supermercados. Este servicio recopila un buen conjunto de destinos ofrecidos por esta agencia de viajes que pueden ser consultados tanto utilizando el puntero del ratón en su versión web para nuestro navegador:


Así como con un dedo cualquiera de tu mano en esta flamante pantalla táctil de 40/50 y tantas pulgadas:



Esta pantalla se encontraba en una pared para poder ser utilizada como alternativa a los catálogos impresos mientras uno espera a poder ser atendido por el agente comercial disponible. Entre una revista de papel y un "pedazo pantallón", yo creo que puedo hacerme una idea de a qué entretenimiento os hubierais dirigido también.

En este caso, en el lado derecho de dicha pantalla se encontraba una pegatina típica con la licencia y serial para este Windows XP edición Embedded (es decir, versión de Windows XP especial para terminales, puestos de venta, kioskos virtuales...). ¡Nos quitamos la fase de OS fingerprinting!

El puntero de la pantalla táctil respondía a la perfección, pero este mapamundi gigante que ofrece como catálogo, en principio sabe a poco. ¿Cómo salimos de esta pantalla? Si únicamente disponemos de un dedo con el que poder actuar (aquí ni botón derecho, ni combinación ninja-multitáctil ni nada por el estilo), sólo nos quedaba probar...a dejar el dedo pulsado unos segundos y en la misma posición. Et voilá!


Menú contextual, del que confirmamos que lo mostrado en la pantalla no era más que una película Flash. El botón derecho que hemos provocado permitía lo mismo que si hacemos botón derecho con el ratón en cualquier película flash en nuestro navegador: imprimir, opciones de zoom, configuraciones del reproductor Flash, e información sobre el software:


De todas las opciones, la única que podría realizar alguna llamada real al sistema sería la de imprimir, ya que a continuación debería aparecer el típico menú de Windows XP en el que se muestran las Opciones de Impresión (impresoras disponibles en caso de haberlas, número de copias, rango de páginas...), y efectivamente:


Esto además, permite sacarnos del modo pantalla completa que estaba establecido para esta película, dejándonos ver que efectivamente, nos encontramos dentro de una ventana pop-up de Internet Explorer:


Y a partir de aquí, pues a elegir un destino para nuestro viaje...que para eso se puso este terminal táctil ¿verdad? Para escribir, tendríamos que hacer uso de la funcionalidad Teclado en Pantalla de la parte de Accesibilidad.


El inconveniente de todo esto es lo aparatoso de este dispositivo, por lo que el trastear con él se queda en algo anecdótico, con momentos gota de sudor frío y disimulo tanto para "el de la mano" como para "la cámara". Si no tenéis oportunidad de encontrar este servicio táctil en vuestros supermercados más cercanos, podréis consultar su versión online en esta dirección, aunque no sea lo mismo...



Leer más...

15 septiembre 2011

Análisis de un PDF malicioso con peepdf

Creo que todos somos o deberíamos ser conscientes de la importancia de tener todas nuestras aplicaciones actualizadas constantemente. Justamente de la deficiencia del usuario normal en este aspecto es de lo que se aprovechan los ciberdelincuentes a través de los Exploit Kits.

Cuando un usuario visita cierta página maliciosa el exploit kit se encarga de probar diferentes exploits para, normalmente, instalar algún tipo de código malicioso en su ordenador. Según un estudio de Kaspersky LabSEO Sploit Pack y Crimepack son dos de los exploit kits que han surgido a principios de este año, y las vulnerabilidades de PDF y Java son las más utilizadas en estos kits. Para ver de primera mano este peligro voy a analizar un PDF malicioso descargado de un SEO Sploit Pack, usando peepdf como herramienta de análisis.

El archivo PDF en concreto, llamado kissasszod.pdf y descargado desde hxxp://marinada3.com/88/eatavayinquisitive.php, tenía una tasa de detección muy baja en su momento (4/40). Veamos qué es lo que tiene dentro:

Rápidamente vemos que hay código Javascript en el objeto 8 y que se usa el formulario /AcroForm para ejecutar “algo” al abrir el documento. El siguiente paso sería obtener más información sobre estos objetos y ver qué se quiere ejecutar:

Vemos que el objeto 8 se encuentra dentro del array /XFA del /AcroForm y que el elemento al que se va a hacer referencia, mirando las etiquetas de los diferentes elementos que cuelgan de /Fields, es yomRote[0].grueLox[0].khfdskjfh[0]. Ahora miramos qué hay exactamente en el objeto 8, que contiene código Javascript:


























Las etiquetas que hemos visto bajo el elemento /Fields indican qué elemento estará contenido en el formulario: yomRote[0].grueLox[0].khfdskjfh[0]. Si nos fijamos, los nombres yomRote y grueLox son subforms de la plantilla (template) que contiene el objeto 8. Dentro del subformulario grueLox tenemos un campo (field) llamado khfdskjfh, que a su vez contiene el código Javascript. Por lo que sabemos a ciencia cierta que este código será ejecutado:

En este script se pretende ofuscar la ejecución de la función eval (línea 5), por lo que podríamos sustiuir brtd por eval en el script para verlo un poco más claro. Como se puede ver en la línea 24, se está ejecutando mediante eval lo devuelto por la función oerz. Ésta coge como argumentos el contenido del elemento khfdskjfh (a partir del carácter número 50) y la propia función eval. ¿Pero dónde está el contenido de khfdskjfh? En el objeto 8 se define la estructura del formulario, pero no está definido el contenido de esta variable, que debería encontrarse colgando de un elemento xfa:datasets. Si echamos un vistazo al resto de los objetos del array /XFA...































El objeto 10 es el ganador. En él podemos encontrar el contenido del campo khfdskjfh, que parecen ser dos arrays, el primero, un array de arrays, y el segundo, un array de números. Viendo la función oerz podemos entender qué es lo que se hace con estos arrays. Se le pasa como primer argumento el segundo array, que se almacenará en la variable axzr, y en la variable uyj se guarda el primer array. Posteriormente en yjf se guardan los caracteres cuyos valores decimales van entre 32-48, 65-97, 48-64, 10-11, 13-14 y 97-126 (primer array). Por último, en la variable tash se guarda el resultado final de usar el segundo array (axzr) como array de índices de yjf. Vamos a tener que hacer varias modificaciones en el código porque al Spidermonkey de peepdf no le gusta el código tal y como está. Una vez hechos los cambios se puede ejecutar correctamente:


El resultado es una segunda etapa de código Javascript:

En este segundo código se ejecuta la función _X, que asigna un valor codificado en base64 dependiente de la versión de Acrobat Reader (línea 45) al elemento khfdskjfh (línea 59). Si decodificamos el contenido nos encontramos con una imagen en formato TIFF:











Este punto es el trigger de la vulnerabilidad CVE-2010-0188. Justo antes, se pasa como argumento la shellcode a la función _L, que se encarga del heap spraying. La variable _ET (línea 57) es la que contiene la shellcode escapada, de la que podemos obtener los bytes sin escapar mediante los siguientes comandos:

































Se puede intuir que el objetivo de la shellcode es descargarse desde la URL encontrada algún tipo de malware, aunque no se puede ver ninguna función claramente. En este caso no nos valdrá con el comando sctest, por lo que vamos a obtener un exe con shellcode2exe de Mario Vilas y echar un vistazo en el debugger:




Leer más...