Este blog ya no está activo, sigue informándote aquí:

Mostrando entradas con la etiqueta Protocolos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Protocolos. Mostrar todas las entradas

domingo, 22 de enero de 2017

TLS/SSL un link para que dejes de usar SSLv3

Hoy estamos un poco malos por aquí  y no hemos podido subir el vídeo que tocaba para hoy. Así que, puestos a  asustaros un poco mas, os voy a recomendar el siguiente enlace que contiene un gran resumen de vulnerabilidades en el protocolo SSLv3 y algunas de TLS 1.1. Con esto quiero haceros pensar en la cantidad de páginas que estamos visitando y no nos están ofreciendo un certificado adecuado.

Enlace al cheat Sheet de vulnerabilidades en SSL:

Pensad en lo que ganaríais si comprobarais los certificados de las paginas a las que os conectáis.

Sed Buenos ;) 

martes, 20 de diciembre de 2016

Bettercap y los paquetes NTLM

Como ya sabéis hace unas semanas que intento crear un script para mi raspberry con pantalla táctil el cual me ayude a lanzar un ataque MITM en cualquier Wifi que pille en un bar. Bueno, lo primero que mire fue el famoso ettercap pero últimamente me estoy encaminando por usar bettercap que no deja de ser una versión mejorada de ettercap-text-only. Vamos que no tendremos la interfaz gráfica, así que para gustos herramientas.


Los comandos son fáciles, podemos utilizarlo con sslstrip y (de lo que me he enterado hoy) nos permite capturar paquetes NT LAN Manager (NTLM) 

NTLM es un objetivo suculento ya que se trata de uno de los protocolos de seguridad de Microsoft, mas concretamente es un protocolo de autenticación de desafío-respuesta, así es como funciona: 

  1. En primer lugar, el cliente establece una ruta de red al servidor y envía un NEGOTIATE_MESSAGE hacer anunciar de sus capacidades.
  2. A continuación, el servidor responde con un CHALLENGE_MESSAGE que se utiliza para establecer la identidad del cliente. 
  3. Por último, el cliente responde al desafío con un AUTHENTICATE_MESSAGE.
Más información: 
Así, ya os imagináis o que podemos llegar ha hacer si obtenemos los Hashes de esta comunicación ¿No? pues Adam del blog XPN Security nos explica como hacerlo y además lo ha grabado en vídeo.


Toda la demás información la podeis leer en su blog:

Sed Buenos ;) 

miércoles, 1 de julio de 2015

Señores SSLv3 Ha Muerto

Hoy estoy de enhorabuena, no solo puedo centrarme en este tipo de entradas as libres y con mucha mas personalidad sino que por fin el [IETF siglas de Internet Enginnering Task Force] (Organismo que produce documentos técnicos pertinentes que influyen en el diseño de manera que la gente, usa y gestiona Internet)  ha declarado al protocolo SSL 3.0 Muerto, aunque ya era hora porque 20 años de protocolo han dado para mucho. 



Este protocolo nos ha dado muchos dolores de cabeza a los que nos dedicamos a la gestión de vulnerabilidades desde POODLE. Hasta yo he pensado en tener un postit anunciando los días sin una vulnerabilidad en SSLv3. Así que me alegro mucho de que en el RFC 7568 lo proclamen como obsoleto.


"The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. "
"The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols."
Bueno, ahora solo tenemos faena para gestionar el cambio a TLS y a que salgan nuevas vulnerabilidades para esta nueva versión del protocolo.

Fuente:

Sed Buenos y sacad el cava antes de que sea tarde ;) 

jueves, 19 de marzo de 2015

¡RC4 Debe Moir! ¡Yo Pongo Las Antorchas!

Hace unos días hablamos de la futura actualización de OpenSSL. La cual esperábamos con bastante impaciencia ya que, lo que ha estado pasando con el protocolo SSL no tiene nombre. Lo en realidad tiene mas gracia de todos es que aunque consigas que toda una empresa actualice a TLS 1.0 aun tendrás problemas ya que el algoritmo de cifrado de RC4 también está comprometido. Así que, si no tuviste ojo antes de proponer la actualización te tocara revisarlo. 


Por esto,  me ha hecho especial ilusión encontrarme con el trabajo de [Christina Garman], [Kenny Paterson] y [Thyla van der Merwe] sobre porque RC4 debe morir y presentando diferentes tipos de ataques al algoritmo de cifrado. 

"Our attacks enhance the statistical techniques used in the previous attacks and exploit specific features of the password setting to produce attacks that are much closer to being practical. We report on extensive simulations that illustrate this. We obtain good success rates with 226 encryptions of the password. By contrast, the previous generation of attacks required around 234 encryptions to recover an HTTP session cookie."

La verdad es que han dejado fino a RC4 sobre TLS y sobretodo si sois unos apasionados de la criptografia y las matemáticas  os recomiendo mucho que leáis su paper. 

Por si teneis curiosidad os dejo el enlace a la página aquí abajo:

Fuente: 

miércoles, 18 de marzo de 2015

¡Hasta el Patas del Error Tipo 3 de ICMP!

Hoy haciendo un poco de recopilación de información sobre Nmap, después de ver el vídeo del Dino. Mientras estaba hojeando toda la información que he podido, he visto que Nmap utiliza mucho el ICMP error tipo 3. Cansado ya de ver que se repetía en muchos lugares y que en ninguno acaban de explicar porqué se utiliza el error tipo 3, he decidido buscarlo. 


Para empezar, ICMP (Internet Control Messages Protocol) es un subprotocolo de control y notificación de errores de IP (Protocolo de Internet) y se usa para enviar mensajes de error. Así que, solo hace falta buscar una tabla donde me lo expliquen todo.

Aquí la tenéis: 

TIPOCÓDIGODescripciónPreguntaError
30Network Unreachable (red inalcanzable)x
31Host Unreachable (host inalcanzable)x
32Protocol Unreachable (protocolo inalcanzable)x
33Port Unreachable (puerto inalcanzable)x
34Fragmentation needed but no-frag. bit set (es necesaria la fragmentación, pero se ha establecido el bit de no-fragmentar)x
35Source routing failed (ha fallado el encaminamiento exigido en origen: se ha especificado el camino/enrutado que deben seguir los paquetes y uno de los puntos de la ruta no está disponible)x
36Destination network unknown (dirección de destino desconocida)x
37Destination host unknown (host de destino desconocido)x
38Source host isolated (host de origen aislado; este tipo está obsoleto)x
39Destination network administratively prohibited (red de destino prohibida administrativamente)x
310Destination host administratively prohibited (host de destino prohibido administrativamente)x
311Network unreachable for TOS (red inalcanzable para el TOS, el tipo de servicio)x
312Host unreachable for TOS (host inalcanzable para el TOS)x
313Communication administratively prohibited by filtering (comunicación prohibida administrativamente mediante filtrado)x
314Host precedence violation (violación del precedente del host)x
315Precedence cutoff in effect (está actuando el límite de precedente)x


Al poderse identificar claramente que tipo de codigo produce que tipo de error, Nmap puede discernir si el puero al que se le envia el "sondeo" esta abierto, cerrado, filtrado, no filtrado,  etc. También cabe decir que algunos de estos códigos de errors no son utilizados por Nmap ya que no le aportarían la información que el necesita. 

Espero que os haya ayudado a mi almenos me ha servido para distraer un poco a mi curiosidad, que me estaba matando. xD

Fuente: 
Sed Buenos ;)