Analizando SSL ( I de III): Historia

SSL o Secure Sockets Layer es un protocolo que proporciona una comunicación segura al incorporar cifrado mediante el empleo de criptografía.

Historia

SSL 1.0, 2.0, 3.0 


SSL fue desarrollado originalmente por Netscape. La versión 1.0 no fue publicada, la versión 2.0 se publicó en 1995 pero contenía  puntos débiles en la seguridad que llevó a ser substituida por la versión 3.0 en 1996.


Primeras claves débiles y avance hacia TLS


Algunas primeras implementaciones de SSL podían usar claves simétricas con un máximo de sólo 40-bit debido a las restricciones del gobierno de los Estados Unidos sobre la exportación de tecnología criptográfica. Dicho gobierno impuso una clave de 40-bit lo suficientemente pequeña para ser “rota” por un ataque de fuerza bruta por las agencias de seguridad nacional que desearan leer el tráfico cifrado, a la vez que representaban un obstáculo para atacantes con menos medios. Una limitación similar se aplicó a Lotus Notes en versiones para la exportación. Después de varios años de controversia pública, una serie de pleitos, y el reconocimiento del gobierno de Estados Unidos de cambios en la disponibilidad en el mercado de 'mejores' productos criptográficos producidos fuera del país, las autoridades relajaron algunos aspectos de las restricciones de exportación. La limitación de claves de 40-bit en su mayoría ha desaparecido. Las implementaciones modernas usan claves de 128-bit (o más) para claves de cifrado simétricas

TLS 1.0 (SSL 3.1)


En 1999 se introdujeron nuevas mejoras y pasó a denominarse TLS (Transport Layer Security). Se describió en RFC 2246 . y es un estándar IETF y es generalmente usado en protocolos HTTPS, SSH, y otros tipos de comunicaciones cifradas. Ya se puede considerar un protocolo robusto. Actualmente los navegadores ya implementan el soporte para TLS y la utilizan como primera opción. SSL 2.0 está descartado al considerarse vulnerable y sólo se utiliza SSL 3.0 en caso de que el servidor web no sea capaz de completar al handshake TLS del navegador.


TLS 1.1 (SSL 3.2) 


Aparece en abril de 2006 RFC 4346 
TLS 1.1 clarifica algunas ambigüedades y añade cierto número de recomendaciones. TLS 1.1 es muy similar a TLS 1.0. La principal razón de esta nueva versión es un formato modificado para cifrado RSA anterior al uso de 'master secret', que es parte del mensaje de intercambio de claves del cliente (si se usa RSA), para usar PKCS#1 versión 2.1, en detrimento de PKCS#1 versión 1.5 en TLS 1.0. La razón de dicho cambio es para protegerse contra ataques descubiertos por Daniel Bleichenbacher que podían lanzarse contra servidores TLS 1.0, usando PKCS#1 versión 1.5, que podrían fallar de diferentes formas dependiendo de si el formato descifrado fuera correcto o no. Éste también incluye recomendaciones para evitar ataques remotos programados. TLS 1.1 es la última versión aprobada del protocolo TLS


TLS 1.2 (SSL 3.3) 


Versión más reciente de TLS que añade más suites de cifrado a las que ya incorpora TLS 1.1. A fecha de enero de 2011 sólo IE8 bajo Windows 7 y Opera soportan TLS 1.2

Analizando SSL (I  de III) :Historia

Analizando SSL ( II  de III): Aplicaciones y Estructura

Analizando  SSL (III de III): Funcionamiento y ejemplos

SSL y SSlstrip, el arte del cambiazo

¿ Que te han robado la password al acceder a una página https ? No es posible!!... O sí?

¿ HTTP o HTTPS ?

Todos entendemos SSL  y HTTPS como el paradigma de la comunicación segura, y lo es, pero hay que ser cuidadoso. Cuando accedamos vía https a un sitio web debemos estar seguros de que todo va correctamente. ¿Alguna vez te ha salido el warning de este sitio no es de confianza y bla,bla, bla?. ¿Has continuado sin echar un vistazo al certificado?. Esta debe ser la norma, nunca ignorar estos avisos. Pero hay formas mucho más sutiles a la hora de "echar el anzuelo" y son los enlaces y las redirecciones (302) desde http hacia https. ¿Cuando accedes a tu cuenta, tecleas directamente https... en la barra de direcciones o pinchas en algún enlace desde otra página? Cuidadín ahí. Alguien te la puede estar jugando con ssltrip.

SSLSTRIP

Bien, aqui entra en juego SSLStrip, una herramienta creada por Moxie Marlinspike y presentada en la BlackHat2009 que automatiza el proceso de realizar un ataque MitM contra estos 2 tipos de llegada a una conexion SSL (redirecciones o desde un link).

En otras palabras, estamos "escuchando" la redirección o la resolución de un enlace hacia HTTPS y zas! daremos el "cambiazo" y nos beneficiaremos de la poca atención de la victima haciendol@ creer  que está entrando por https cuando en realidad lo hace por http.

Este tipo de ataque es posible en páginas que admiten los dos modos, por ejemplo gmail.

Funcionamiento, a grandes rasgos

La base del ataque es el conocido Man in The Middle (MiTM). Para ello la máquina atacante debe hacer las veces de intermediario y hacer que todo el tráfico entre la victima y su destino pase por él. Ello se hace vía spoofing haciendo creer a victima y destino(router/gateway) que sus respectivas direcciones son la nuestra, así cuando la víctima envíe y cuando el router devuelva lo harán a la dirección del atacante siendo éste, el que después de obtener el tráfico lo redirija a su destino real. El engaño se realiza con el envenamiento de ARP o ARP spoofing.

 Fig1. ARP Spoofing. MiTM

Una vez en marcha, SSLstrip estará atento a las conexiones HTTP (puerto 80) capturándolas y actuando sobre ellas para en el caso de redirección a https (443) deshabilitarlas y devolver de nuevo a la victima tráfico http.Por otro lado con un sniffer capturaremos el tráfico y entre él aparecerá  en texto plano el login/passwd al ir realmente sobre http.

Fig 2. SslStrip dando el cambiazo a redirecciones y links hacia htpps

El cambio con SSLStrip el esquema es el mencionado:
Cliente <---NoSSL----> SSLStrip <--SSL---> Servidor

Con este esquema el navegador no alertará al usuario ya que para él todo es http.

Por tanto, la herramienta proporciona los mecanismos necesarios para que un usuario piense que la conexión se está estableciendo de manera segura, aunque realmente esto no sea así y todo el tráfico hacia la herramienta salga sin cifrar.

Herramientas necesarias (en Linux):

Arpspoof---> Para realizar el envenamiento

ssltrip------> Cambiazo https--->http.
iptables--->Necesitarás crear una regla iptables para redirigir el puerto 80 al puerto donde escucha ssltrip

ettercap---> Sniffer

El procedimiento no es complicado, lo explica el propio Moxie en su página. 

¿Comntarios? ¿Sugerencias?

Disclaimer: El objeto de este post es puramente didáctico por lo que no entro en detalles a nivel de comandos. 

Stuxnet: "Confirmado", el GH está detrás

Según el New York Times, Stuxnet fue creado por el gobierno de Estados Unidos e Israel

New York Times ha venido a confirmar lo que ya se rumoreaba desde hace tiempo: Stuxnet, un gusano que sorprendió a propios y extraños por su extrema complejidad y profesionalidad, ha sido financiado por el gobierno de Estados Unidos de América e Israel, y su objetivo eran las centrales nucleares de Irán.

Desde mediados de 2010, Stuxnet ha marcado un antes y un después en la mitología del malware, acaparando titulares. Técnicamente, es muy avanzado: el uso combinado e inteligente de vulnerabilidades desconocidas hasta el momento para difundirse, el uso de certificados válidos, y unos objetivos muy concretos (el software para controlar ciertos aspectos de las centrales nucleares) hacían pensar que detrás de este código debía existir un despliegue fuera de lo común. Se necesita mucho conocimiento, poder, investigación y tiempo (o sea, mucho dinero en resumen) para desarrollar Stuxnet y esta tarea ya se le reservaba a los gobiernos. Por ejemplo, en octubre ya escribíamos en una-al-día que Stuxnet fue "diseñado y financiado supuestamente por algún gobierno para atacar el plan nuclear Iraní" y Eugene Kaspersky consideraba en esas mismas fechas que Stuxnet "era el prototipo funcional de una ciber-arma, que dará el pistoletazo de salida a una ciber-guerra en el mundo"

Lo que sugiere el New York Times es que Estados Unidos e Israel desarrollaron el gusano para paralizar el plan nuclear iraní. Durante dos años se utilizó una central nuclear de Dimona (al sur de Israel) como laboratorio para examinar y ensayar Stuxnet con el objetivo de sabotear las centrifugadoras nucleares en Irán. En Dimona, los israelitas utilizaron el mismo tipo de centrifugadoras que operan en la central iraní de Natanz, donde se produce el enriquecimiento de uranio. Así consiguieron que fuese tan efectivo: el gusano paralizó la quinta parte de las centrifugadoras de uranio de Natanz. Stuxnet primero modificaba sus parámetros de regulación para destruirlas y luego enviaba señales al sensor para aparentar que todo estaba correcto.

En principio, la información del New York Times viene de "expertos militares y de inteligencia norteamericanos", pero muy probablemente nunca será confirmado oficialmente (aunque todo apunta a que sea cierto).

Fuente: http://www.hispasec.com/unaaldia/4466

Ciberguerra. Cuando el hacker es el Gobierno

¿Estamos preparados para un conflicto? Hoy en día ya no es suficiente la defensa a nivel armamentístico y energético. Hoy toma relevancia especial la defensa ante ciberataques.
¿ Ciberataques ?. WTF!!.

Si, aunque era intuible, una vez conocido el caso del gusano Stuxnet está claro que ya no se puede únicamente identificar a un hacker como un tipo freak, con pocos amigos y que vive 24h tras una pantalla de ordenador. No, ya hablamos de técnicas hacker empleadas por los gobiernos con objetivo de tener estrategias para atacar sistemas industriales y otros relacionados con la defensa de un país. En el caso de stuxnet parece que el origen es israelí y cuyo objetivo (a razón del número de ataques) fue Irán. Plantas nucleares fueron comprometidas por este sofisticado gusano que incluso incluye 2 certificados electrónicos aunténticos, robados de una autoridad de certificación.

Stuxnet ataca equipos con Windows empleando cuatro vulnerabilidades 0-day de este sistema operativo, incluyendo la denominada CPLINK y otra empleada por el gusanoConficker. Su objetivo son sistemas que emplean los programas de monitorización y control industrial (SCADA) WinCC/PCS 7 de Siemens.
Tomando posiciones


Reino Unido anunció el mes pasado una inversión extra de 650 millones de libras esterlinas (758,5 millones de euros) en ciberseguridad, después de que una nueva estrategia de seguridad nacional subrayase este área como una de las mayores amenazas a las que se enfrenta el país.

Alemania  por su parte creará en este año un nuevo centro de guerra cibernética para repeler los ataques de espionaje, anunció el Ministerio alemán del Interior. “Tenemos planeado crear el denominado ‘Centro Nacional de Defensa Cibernética‘ en 2011“, anunció un portavoz a los  periodistas. “Funcionará agrupando las técnicas existentes en el área de la defensa cibernética”.

¿ Y nosotros ? ¿ Como de preparados estamos ?

E imagino que esto es solo la punta del iceberg....

INTECO (Instituto Nacional de las Tecnologías de la Comunicación)

Hoy voy a recomendar este site: INTECO .Se trata del Instituto Nacional de Tecnologias de la Comunicación. El él se puede encontrar información e indicaciones relacionadas con el mundo de la seguridad informática y la información ,  accesibilidad  y web , TV y Prensa. certificaciones, etc. Consta también de plataformas formativas en las áreas de la seguridad de las tecnologías de la información y  en accesibilidad y éstandares web .

Encontramos info muy útil a la hora de conocer los tantas veces pasados por alto detalles legales relacionados con el mundo de las Tecnologias de la Infomación
¿Dudas sobre obligaciones de un blog por ejemplo? Aqui  Oooops }:-)
¿O una web? Aqui

Recomendable

II. Capturas con Wireshark en una red WLAN (802.11)

El medio inalámbrico no es un medio tan limitado fisicamente como lo puede ser un cable, y por ello las tarjetas de red Wifi utilizan dos mecanismos más de filtrado de paquetes (además de la MAC como en redes ethernet) : El SSID y el canal.
No describiré en profundidad la estructura de una trama 802.11 pero cabe comentar que se destinan dos bits de la trama para definit 3 grupos (tipos) de paquetes: administración (para la asociación, desasociacion, autenticación...), control (gestion acceso al medio) y datos. Estos a su vez tienen subtipos identificados por 4 bits más ,es decir que por cada tipo tendremos hasta 2⁴ = 16 subtipos.

Generalmente los drivers de las tarjetas inalámbricas transforman el formato de los paquetes 802.11 al formato ethernet (802.3) por lo que no podremos ver la estructura de todos los paquetes WLAN sin intervención. Eso se hace poniendo la tarjeta en modo monitor con lo que seremos capaces de analizar las cabeceras de las tramas 802.11 y con ello no solo de los paquetes de datos, sino también de los paquetes de control y administración.

Desgraciadamente no todas las tarjetas permiten el modo monitor y tampoco todos los sistemas. En Linux tenemos menos problemas y mediante la librería pcap suele poderse.
Winpcap es la versión para windows ya que en éste  con sus drivers (NDIS) no soporta el modo monitor de la tarjeta . Wireshark se apoya en lipcap(Linux) o winpcap (windows) para la captura de tráfico. Otra posibilidad es usar los productos Airpcap de cacetech pero no son gratuitos precisamente.

Modo monitor:
Permite ver las tramas 802.11 y deshabilitar los filtros SSID y canal tipicos de la WLAN lo que nos permite capturar tráfico independientemente del SSID y el canal de tráfico.
En el medio inalámbrico al ser emisiones de radio éstas llegan a cualquier máquina dentro de su radio de alcance por lo  que se asemejaría a una topología HUB en una red cableada.
Modo promiscuo:
Al igual que en ethernet, deshabilita el filtro MAC y nos pernmite capturar paquetes independientemente de la dirección MAC de destino que lleven. Es decir, la tarjeta no descartará el paquete como haría normalmente si no corresponde con su MAC y lo pasa al sistema para su proceso.

El modo monitor es sólo aplicable a medios inalámbricos mientras que el modo promiscuo es posible en ambos.
En capturas WLAN se hace uso del modo promiscuo para poder monitorizar todo el tráfico de  paquetes sin estar asociados a ningún SSID y/o canal en particular.

Sobre la captura, pues similar a la parte ethernet. En este caso como el tráfico no va por un circuito físico no tenemos el problema de la red switcheada y con el modo monitor que nos elimina los filtros de SSID y canal  podremos "sniffar"  todo el tráfico aéreo.


       I.Capturas con Wireshark en una red Ethernet

       II.Capturas con Wireshark en una red Wlan (802.11), o wifi

I. Capturas con Wireshark en una red Ethernet

Primeramente recordemos los tipos de paquetes :

• Unicast. Son los paquetes que se dirigen a una única dirección de red 
• Multicast. Se dirigen al grupo de direcciones 224/4 (el fijado en Ipv4 con el primer bit a 1) es decir englobaría desde la 224.0.0.0 a la 239.255.255.255 
• Broadcast. Se dirigen al todas las direcciones del segmento de red en el que nos encontremos. Para toda la red Ipv4 sería la direccion 255.255.255.255 (FF:FF:FF:FF). Si nos encontrasemos en una red de clase C por ejemplo la 192.168.1.0/24 la direccion de broadcast sería la 192.168.1.255. En una clase A tipo 10.12.1.0/8 broadcast sería 10.255.255.255 

Al grano :

Red Ethernet compartida (HUB) 

En este tipo de topología no tendremos problema para escucharl el tráfico porque todos los paquetes que llegan al HUB son mandados a todos (broadcast).

A nuestra máquina con Wireshark llegará todo el tráfico y con nuestra tarjeta en modo promiscuo aceptaremos todos los paquetes sean o no dirigidos a nosotros.

Modo promiscuo: Normalmete las tarjetas ethernet operan de modo que si el tráfico que reciben viene marcado con su dirección MAC aceptan el paquete y en caso contrario lo rechazan. El modo promiscuo deshabilita este filtro haciendo que la tarjeta acepte todo el tráfico.


Red conmutada (switcheada)

En este caso el switch se encarga de reenviar el paquete del emisor únicamente por el puerto donde sabe que está el receptor (switch con su tabla arp ya rellenada). Es decir el tráfico es unicast y por tanto no recibiremos el tráfico aunque pongamos la tarjeta en modo promiscuo ya que el switch no nos la va a enviar

Para resolver este problema hay diversos métodos, pero comentaremos solo los que no necesitan de manipulación física de la topología (como por ejemplo pinchar un hub entre el segmento/maquina a monitorizar y el switch, pinchar nuestra máquina al mismo tramo entre host y switch ,etc).

Solución 1 (y más común): Man in The Middle

Se emplea la técnica de envenamiento de ARP (ARP Poisoning) , haciendo las dos máquinas entre las que queremos interponernos crean que nuestra MAC sea la del otro host. 

Aviso: Esta técnica crea mucha confusión en el switch y puede crear estragos en ciertos switches y LANs, utilizar con cuidado.

Ventaja: Muy poco coste, sencilla implementación. 

Desventaja: Confusión en el switch pudiendo provocar sensible pérdida de paquetes en momentos de mucho tráfico.

Solución 2: MAC Flooding.

Se trata de saturar al switch generando muchas peticiones con distintas direcciones MAC con objeto de que se llene la memoria de su tabla ARP (donde almacena el mapeo de MAC<-->Puerto fisico). En esa situación el switch entra en modo “failopen” y pasa a actuar como un HUB. Existen herramientas para hacer flooding como macof , una utilidad que viene con dsniff

                                                                                                                                                                  Ventaja: De nuevo, muy poco coste de implementación.

Desventaja: Afecta al Fullduplex y habrá pérdida de paquetes en situación de mucho tráfico.


En resumen: capturar el tráfico de una red conmutada por MitM o por flooding penaliza el tráfico y puede acarrear problemas de pérdida de paquetes.

       I.Capturas con Wireshark en una red Ethernet

       II.Capturas con Wireshark en una red Wlan (802.11), o wifi

Wireshark , analizando el tráfico de red

Hoy en día, en temas de seguridad y auditoría informática es de vital importancia conocer y analizar el tráfico que circula por nuestra red (o no tan nuestra :D) . Wireshark y su variante Tshark (modo terminal de comandos) es una de las herramientas de uso mas extendido para estos menesteres. Vamos a tratar de ver como funciona en las dos topologias de red mas usuales.

       I.Capturas con Wireshark en una red Ethernet

       II.Capturas con Wireshark en una red Wlan (802.11), o wifi

Anónimos por la red con Tor y Onion Routing

¿Quién no se procupa por su privacidad cuando navega por internet o mas aún cuando utiliza algún sistema de mensajería instantánea ? ¿ Estamos siendo observados ? ¿ Está nuestro tráfico siendo analizado ?. En Internet, es posible para los que te proveen tu conección (ISPs) saber exactamente a qué sitios te conectas, qué día y a qué hora, cuál es el computador desde donde se publicó cada entrada de blog, comentario en foro, qué correo envías, etc.. Es más, en muchos países los ISPs están obligados a mantener esta información registrada durante un tiempo.
Paranoias aparte, nunca está de más en ocasiones contar con un "plus" que nos de cierta tranquilidad sobre nuestro anonimato en la red. Aquí es donde nos puede ayudar Tor y su red "cebollera" (onion routing , o enrutamiento por capas).


La técnica del onion routing se utiliza para ofrecer un cierto nivel de anonimato en las conecciones por Internet.


El onion routing permite, entre muchas otras cosas, navegar por sitios Web sin revelar ningún dato que pueda establecer quién navegó por qué sitio. También puede utilizarse para conectarse a otros servicios como mensajería instantánea o correo. Notablemente, puede ser usado también para establecer un sitio Web y que nadie pueda saber dónde está el sitio Web o quién es su autor.

TOR es un software que ocupa la técnica de Onion Routing.

¿ Cómo funciona el Onion Routing ?


La idea principal es simple: crear una cadena larga entre el origen y el destino, y que esta cadena pase por muchos agentes. Por esto se llama "onion routing", porque se puede ver el sistema como compuesto por muchas capas, como las cebollas (y los ogros). Problema: en principio, es que si hay muchas personas entre el origen y el destino, eventualmente ellos podrían ver lo que yo estoy haciendo.

Solución: es que el tráfico está encriptado entre los nodos.

El segundo problema es ¿cómo saber a quién conectarse? esto se resuelve usando un servidor de directorio. El primer paso es el conectarse a un servidor que tiene una lista de todas las personas a las cuales me puedo conectar:

Para crear la ruta de red privada el cliente Tor va creando incrementalmente un circuito de conexiones encriptadas entre los nodos que actuan como relays. El circuito se extiende un salto cada vez y cada relay solo conoce que nodo le entregó los datos y a qué nodo se los debe pasar. Ningun nodo conoce la ruta completa que el paquete de datos llevará. El cliente Tor negocia un conjunto de claves de encriptacion para cada salto de modo que cada nodo no pueda tracear las conexiones que reenvía. Ahora supongamos que me quiero conectar con algún sitio, lo que pasa a continuación es que, al azar, escojo un camino en esta red.

Una vez el circuito se ha establecido, varios tipos de datos pueden ser intercambiados y varios tipos de aplicaciones pueden apoyarse en la red Tor. Como cada nodo solo ve un salto en su circuito, un mecanismo de analisis de tráfico no podra establecer conexion entre el origen y el destino. Tor trabaja sobre TCP y puede ser usado por cualquier aplicacion con soporte SOCKS.

Si me conecto a otro sitio, la ruta puede cambiar o ser la misma. Para mejor rendimiento, las rutas cuando funcionan se siguen ocupando durante 10 minutos, luego forzosamente cambian:

Lo interesante es que este esquema funciona en ambas direcciones. Es decir, puedo además de conectarme a sitios web en forma privada, ofrecer un sitio web sin revelar dónde estoy en la red (ni en el mundo).

Más adelante, postearé un ejemplo de uso de Tor con Firefox.

Saludos

Fuentes: http://www.torproject.org

               

¿ Es segura su Web ? ¿ Desarrolla aplicaciones seguras ?

Hoy en día una de las preocupaciones de cualquier desarrollador/administrador es tener securizada su web y/o sus aplicaciones.
Una buena praxis sería repasar  el protocolo de pruebas desarrollado por la OWASP (Open Web Application Security Project) desde donde podemos descargar la versión 3 en castellano de La Guia de pruebas OWASP.


Existen diversos roles diferentes que pueden emplear esta guía:

• Los desarrolladores deberían utilizar esta guía para asegurarse de que están produciendo código seguro. Estas pruebas deberían ser parte de los procedimientos normales de comprobación de código y módulos.

• Las personas que realizan pruebas de software deberían utilizar esta guía para expandir el conjunto de casos de comprobación que aplican a los programas. Detectar estas vulnerabilidades en una fase temprana ahorra un tiempo y esfuerzo considerables a posteriori.

• Los especialistas en seguridad deberían utilizar esta guía en combinación con otras técnicas, como un método para verificar que no se ha dejado ningún agujero de seguridad en una aplicación.

Un documento altamente recomendable y a tener en cuenta en el desarrollo y explotación de aplicaciones.