09 marzo 2009

Con la llegada primero de Ceres-FNMT y posteriormente con el impulso del DNI-E, la administración Española ha ido lanzando una serie de servicios-online que permiten realizar todo tipo de trámites, desde presentar la declaración de la renta hasta consultar el informe de vida laboral de la seguridad social.

Obviamente todos estos trámites van protegidos por sesiones SSL lo que a priori puede parecer un entorno totalmente confiable.

Lo que no todo el mundo sabe es que SSL como tal, no es un protocolo único, mas bien es una enorme familia de protocolos, empezando por que existen 4 versiones (SSL v1, SSL v2, SSL v3 y TLS) además en cada versión se pueden negociar diferentes algoritmos con sus correspondientes longitudes.

Podriamos decir que el mundo SSL es como el mundo de las hipotecas, existen algoritmos AAA fiables y algoritmos subprime inseguros y poco aconsejables.

En concreto, el objeto de este estudio es la parte de los algoritmos simétricos que a la postre, son los que cifran los datos en tránsito.

Unanimemente la comunidad criptográfica considera los algoritmos de cifrado simétrico por debajo de 128 bits como inseguros. No olvidemos que, en la época que EEUU aplicaba fuertes restricciones criptográficas, el limite estaba en 40-bits.

Haciendo uso de la herramienta 'manyssl' (herramienta que permite interrogar que algoritmos acepta en una negociación ssl un servidor) he auditado unos cuantos de los servidores que aparecen listados en el portal del dni-e.

¿El resultado? La totalidad de ellos permiten un mínimo de 2 algoritmos inseguros, pero lo normal es ver disponibles bastantes mas:

Como se puede apreciar en el gráfico, la CMT, el INEM y la Agencia de Protección de Datos, son los menos vulnerables (2 algoritmos) y destaca NIC por sus desnhorrosos 15.

Que un servidor web permita negociar algoritmos SSL inseguros no significa que las transacciones con ellos sean inseguras, ya que lo normal es que tu navegador, cuando se conecte al servidor, negocie algoritmos óptimos.

El problema es que potencialmente esos servidores, que gestionan transacciones importantes, son susceptibles de que alguien se conecte a ellos de forma insegura. En muchos casos soportan incluso SSL v2 que tiene en su haber un horrible bug de tipo 'downgrade' que permite tomar el control de una sesión SSL.

¿Solución? Deshabilitar los algoritmos inseguros y en caso de que alguien intente conectar y no soporte las versiones seguras, advertírselo para que se actualice

El documento completo del estudio con los algoritmos, se puede descargar desde aquí y está en formato OpenOffice
Leer más...

07 marzo 2009

Hackeos memorables: El Twitter de Enrique Dans

Puede parecer muy petulante que auto-incluya en nuestra sección de 'Hackeos memorables' algo que hemos realizado nosotros, pero dada la repercusión que el asunto está tomando, me voy a permitir la licencia.

Recientemente se ha publicado que Twitter en su método de actualización basado en SMS es susceptible de ser 'spoofeado' enviando sms cuyo origen sea el numero de móvil que está asociado a la cuenta.

Lo del SMS Spoofing no es nada nuevo, ya escribimos tiempo atrás un premonitorio artículo sobre la fiabilidad de los SMS y los servicios basados en el numero de origen.

El caso es que una vez en conocimiento del ataque, me decidí a hacer pruebas, lo primero que me hacia falta era un servicio para enviar sms en el que pudiera editar a mi antojo el numero de origen, probé BromaSMS pero este servicio solo se puede emplear en números nacionales (el numero para postear en twitter es un +44 inglés) así que ese servicio no me era útil. Después de pensarlo un poco, recordé que la gente de lleida.net tienen un servicio que permite enviar SMS desde la web, una vez registrado me puse a probar en mi casi-abandonada cuenta Twitter.

Sorprendentemente los updates enviados desde el servicio de LLeida funcionaban, así que después de pensar en las posibilidades del bug, me vino a la cabeza la persona mas pro-twitter de España: Enrique Dans.

Solo me faltaba un detalle, conocer el teléfono que estaba asociado a la cuenta de Twitter. La búsqueda fue sencilla ya que Enrique publica como datos de contacto su teléfono móvil. En principio pensé que el numero ahí publicado solo seria algún tipo de móvil-filtro re-dirigido al verdadero, pero solo había una forma de salir de dudas: haciendo la prueba.

El resultado, como se puede apreciar, fue satisfactorio:


Enrique en su post sobre el tema apuesta por que los operadores de telefonía Españoles filtren ese tipo de mensajes. Yo, desde mi punto de vista, no soy tan optimista, si hicieran eso, servicios como el de lleida (perfectamente legitimo) dejarían de funcionar. En este caso el problema viene de implementar un servicio sustentado en algo tan poco seguro como el numero de teléfono. Yo lo veo análogo a si permitieran updates vía correo-electrónico tomando como elemento validador el correo origen. La solución por tanto pasa por implementar algún tipo de contraseña que tuviera que viajar junto al SMS para dar por buena la actualización.

Solo nos queda agradecer a Enrique por su fair-play y tomarse tan deportivamente el asunto
Leer más...

05 marzo 2009

Ya lo dice la gente: 'busques lo que busques, está en el Emule', en este caso lo que se ha filtrado a las redes p2p es ni mas ni menos que los datos técnicos del Marine One, el juguete que emplea Obama como Helicóptero.

Por lo visto, una empresa que se dedica a 'monitorizar redes p2p' ha localizado en ... una IP de Iran archivos con toda la información interna del helicóptero, 'Blue prints', mecanismos de uso y tecnología.

Las pistas de esta tremenda metedura de pata parecen apuntar a una de las empresas que colaboran con el ejercito de EEUU llamada Lockheed Martin, según parece alguno de sus empleados usaba algún cliente P2P sin prestar demasiada atención a lo que compartía.

A mi todo esto me recuerda al segundo post de este blog en el que Alejandro ponía sobre la mesa el tipo de cosas que la gente dejaba en el Emule.

En estos tiempos de crisis, bien podría Lorenzo hacerse las americas y charlar sobre DLP

La noticia original, aquí
Leer más...

04 marzo 2009

Spotify comprometido, pero hace unos meses


Otro servicio actual, nuevo, y en boca de todos, que sufre problemas de seguridad, y bastante graves. Recordemos las últimas noticias del servicio de microblogging twitter.

El servicio de música bajo demanda Spotify ha sido comprometido. Es casi imposible acceder a su blog actualmente, seguramente por la avalancha tremenda de visitas que está teniendo la nota de seguridad publicada por ellos, pero podemos leer en thenextweb algo de lo que ha ocurrido.

Principalmente, el fallo se da en los protocolos utilizados por el servicio, los cuales fueron comprometidos por un grupo, pudiendo así obtener contraseñas, datos personales, e incluso los detalles de los pagos por su servicio. Pero el tema aún es más grave.
Ya en diciembre, el programa sufrió una actualización, en la que se anunció un parche para un problema que encontraron. Este arreglo tuvo lugar el 19 de Diciembre. Pues bien, la semana pasada es cuando parece ser que se dieron cuenta de que alguien ya estuvo pasándoselo pipa con el fallo.

Se recomienda cambiar la contraseña si esta se utiliza tambien en otros servicios, en caso de haberse dado de alta antes del 20 de Diciembre, que debido al boom que supuso, estoy seguro de que será más de un par...
Leer más...

IP: el anillo para gobernarlos a todos

Mucho hemos hablado en este blog sobre diferentes tecnologías, productos, buenas prácticas, para proteger las comunicaciones de las organizaciones a nivel IP. Al menos, lo hemos hecho, dando por supuesto que los datos que gestionábamos eran tráfico de red referente a protocolos normales, como la navegación web, el envío y recogida de correo, gestión SNMP, el de intercambio de ficheros mediante FTP o redes P2P incluso,... Y es que el protocolo IP (Internet Protocol) quizá por llevar la palabra "Internet" como parte de su nombre ha sido explotado para bien y para mal a lo largo de la última década.

De hecho, desde hace algún tiempo, en algunas organizaciones, se ha sumado a dicho tráfico el correspondiente a las comunicaciones de voz: la VoIP. En líneas generales, los dispositivos teléfonicos modernos compatibles con esta tecnología permiten efectuar virguerías gracias a la potencia del software de las centralitas. Mediante las mismas, es posible gestionar las extensiones en virtud de una IP en concreto del dispositivo en el que nos encontremos. Si vamos a estar físicamente en una sala de reuniones, se puede configurar la cdntralita para que las llamadas destinadas a las personas convocadas a dicha reunión, sean transferidas a la extensión del dispositivo IP situado en dicha sala de forma automática, o a un buzón de mensajes, a una persona de backup que se designe para contestar las llamadas mientras estás ocupado, y mil combinaciones y opciones más. Dada la naturaleza IP, tanto de los teléfonos como de las centralitas, abre el abanico de ataques a este tipo de tecnología, aunque le dedicaremos un post a esta parte en otra ocasión. Este tráfico telefónico (VoIP) circula de forma "protegida" a través de las redes, tanto internas como externas o sucursales, gracias a mecanismos IP utilizando normalmente VLAN tagging con 802.1Q. Para ello se establece una etiqueta previa a los paquetes que corresponden a dicho tráfico de manera que los elementos que gestionan esas comunicaciones, las conmuten por circuitos virtuales diferentes. En ocasiones es posible utilizar electrónica de red, únicamente y de forma paralela para VoIP, aunque lo más común es compartir el medio físico de la forma explicada anteriormente.
A la lista de novias que le han salido a la tecnología IP se suma ahora (y por los estudios de tendencias a los que he tenido acceso) una de las formas más antiguas de protección: la seguridad física. En el material de estudio del CISSP (entre otras) se dedicaba un capítulo entero a la seguridad física. Entre otras medidas (procedimientos establecidos ante situaciones para hacer frente a ataques de ingeniería social, cerraduras, controles de presencia, RFID, medidas de los muros de las instalaciones, materiales, tipos de extintores, etc...) se hacía referencia a lo más típico en las organizaciones e incluso en algunas ciudades: las cámaras de vigilancia (CCTV). De hecho, y dado que la red IP se considera algo de acceso universal, se pasa de tener una red cerrada de televisión a una red abierta. Esto, unido a las posibilidades de las redes wireless, incluso las de área extensa (como lo que se pretende hacer con WiMAX), se pasa de tener un despliegue de cámaras con cableado independiente (véase la similitud con la electrónica de red específica para VoIP expuesta anteriormente) a utilizar la infraestructura de switches y puntos de acceso inalámbricos junto a cámaras de vigilancia IP. A partir de aquí se abre un nicho nuevo de posibilidades, tanto de optimización y funcionalidad, como de ataques. Para ello, la electrónica de red deberá contar con mecanismos de priorización de este tipo de tráfico (casi al mismo nivel que para VoIP). Igualmente, el resto de los dispositivos que gestionen estos paquetes deberán estar provistos de "inteligencia" para discriminar entre tráfico lícito y malicioso, con una base de reglas sobre ataques (tanto a nivel IP como de aplicación) que exploten vulnerabilidades relacionadas con dichas comunicaciones.

Asimismo, las antiguas máquinas de grabar el video procedente de las cámaras viajan al museo, dejando paso a grandes sistemas digitales de almacenamiento que permitan mantener las evidencias visuales que puedan servir como prueba ante un incidente. Además, estos medios digitales de almacenamiento deberán estar protegidos a nivel físico como lógico de ataques con intentos de lectura, modificación, borrado de la información contenida (garantizando la privacidad de dichos contenidos) o denegación de servicio de la plataforma de almacenamiento en sí misma.

Fabricantes como Axis, Netgear y D-Link proveen tanto de los dispositivos de videovigilancia IP como del software necesario para la monitorización por parte de seres humanos (menos mal que aún seguimos siendo necesarios) y el control del almacenamiento de las grabaciones.

Desde el punto de vista opensource, recomendamos dos implementaciones estables y actualizadas: Motion y ZoneMinder. Ambas permiten integrar cámaras IP (o incluso algunas USB conectadas directamente a la máquina que las gestiona) de naturaleza y fabricante heterogéneo, unificando las grabaciones en una misma plataforma de gestión e incluso optimizando el espacio y rendimiento, de manera que se puede seleccionar que únicamente se grabe a disco cuando las imágenes recibidas contengan algún movimiento únicamente, de manera que las horas inproductivas de datos (cuando no ha habido cambios en lo grabado) no se almacena, ahorrando espacio de almacenamiento.

¿Qué será lo siguiente a integrar dentro del mundo IP?

Leer más...

02 marzo 2009

Vuelve l0pht y con ellos l0phtcrack en su versión 6

Buenas noches, radiomacuto con noticias de la scene hacker.

El que fuera uno de los grupos más importantes de hackers en el panorama internacional ha vuelto a dar señales de vida, nos referimos a l0pht Heavy Industries.

Tras formar parte de la compañía @stake, que fue comprada por Symantec en el año 2004, parece que volverán a las andadas y liberarán una nueva versión de su más famoso producto: l0phtcrack.

l0phtcrack fue pionera como herramienta para realizar ataques de fuerza bruta/diccionario contra archivos contenedores de contraseñas de windows (SAM). El próximo día 11 de Marzo en la conferencia SOURCE Boston se darán a conocer todos los detalles... Esperamos que sea algo más innovador que soporte para tablas Rainbow .



Les mantendremos informados.

Leer más...

Guías de seguridad para redes WIFI

Defender una red Wireless supone un reto bastante notable debido a la capacidad intrínseca de la red para ser detectada de forma incontrolada y la ausencia de limitaciones físicas para aplicar restricciones.

En SbD ya hemos hablado de mecanismos para bastionar entornos WIFI e incluso sobre estrategias de tipo HoneyPot para detectar ataques. Hoy voy a referenciar un par de guías que he encontrado que pueden ser de interés.

La primera viene firmada por parte del NIST y debido a su origen, tiene una naturaleza técnica donde clarifica escenarios y tecnologías disponibles para securizar un entorno Wifi.

Supongo que a cualquiera de nosotros si nos preguntan un escenario para desplegar una red wifi, tenemos claros términos como WPA2 o túneles IPSEC, pero siempre es bueno tener una guía que sirva como marco de referencia a la hora de sentarnos a diseñar.

La otra guía viene de la mano de HP y tiene un perfil mucho mas 'ejecutivo' y aunque lo que se explica en ella ya ha sido muy trillado en otros documentos, si es interesante como introducen el concepto WIDS (IDS para redes WIFI) como herramienta para detectar ataques (obviamente lo hacen promocionando su herramienta)

Tirando de delicious he encontrado un par de proyectos WIDS libres (aunque no he podido probarlos) pero supongo que habrá mas:

En el mundo comercial existen bastantes herramientas, lo que yo echo en falta es un 'snort' que sirva como referente en cuanto a herramientas opensource que actúen como WIDS, ya que los enlaces que he puesto son de proyectos que no se ven 'tan hechos' como sus homónimos comerciales
Leer más...