John the Ripper

John the Ripper es un programa para crackear contraseñas “hasheadas” en diversos formatos, entre ellos: LM, MD5 y SHA1. MD5 y SHA1 son los formatos con los que guardan Unix y Linux sus contraseñas; LM (DES) es el formato con el que guarda Windows, de forma muy insegura, sus contraseñas.

Resulta que Windows en sus versiones anteriores a NT sólo usaba LM y esto implica, por las características de LM, que las contraseñas tenían que ser divididas en dos partes de 7 caracteres cada una y tranformadas sus letras a mayúsculas. Luego de varias quejas sobre la inseguridad de LM incluyeron NTLM (MD4), que no necesita dividir las contraseñas en dos partes. El problema es que continuaron con el soporte habilitado para LM hasta Windows XP. Aunque si la contraseña es mayor a 14 caracteres, entonces no utiliza LM, sólo NTLM.

Las implicaciones de inseguridad para LM son graves. Si las contraseñas se guardan partidas en dos partes de 7 caracteres y convertidas a mayúsculas, se elimina gran parte de la complejidad para crackear casi cualquier contraseña. Si sólamente se usan letras y números en la contraseña, la cantidad de contraseñas posibles serían: (10 (dígitos del cero al 9) + 27 (letras en mayúscula) ) elevado a la 7. Es decir (10 + 27)^7 = 94,931,877,133 contraseñas posibles. Algo cercano a 95 mil millones de combinaciones diferentes. Cosa que es muy poca para un procesador moderno y menos aún para los de doble núcleo, que puede probar cerca de 90 millones de contraseñas por segundo. Luego considerando que estadísticamente la gente utiliza contraseñas de entre 6 y 8 caracteres, y la gran mayoría utiliza sólo dígitos y letras, entonces muy problemente las contraseñas estarán guardadas usando el formato LM.

Obteniendo contraseñas en Windows

Windows guarda sus contraseñas en formato LM dentro del archivo SAM, el cual sólo puede ser leído por usuarios del sistema con permisos de administrador. Pero también se puede tener acceso a ese archivo por otros medios; lo que comúnmente se hace es iniciar la computadora desde una distribución Linux en Live CD, como Backtrack, y ejecutar dos comandos para obtener el archivo SAM. En ésta página hay un video que muestra cómo se hace.

Una vez obtenido el SAM, utilizamos John the Ripper para obtener la contraseña deseada. En éste sitio podemos encontrar una modificación de John the Ripper que soporta procesamiento paralelo; basta después con bajar y compilar MPICH para poder ejecutar JTR en dos procesos paralelos. Esto aprovechará los dos núcleos de nuestros procesador y reducirá a la mitad el tiempo que hay que esperar para obtener la contraseña.

La manera de ejecutar JTR usando MPICH, para que utilice dos procesos paralelos, es la siguiente:

mpirun -v -np 2 ./john sam.txt

Después de dos horas muy probablemente hayamos obtenido la contraseña de Windows que queremos, aunque la contraseña devuelta estará en mayúsculas, por aquello del LM. Si queremos la contraseña real, que puede contener mayúsculas y minúsculas, se tienen que hacer dos pasos más. En esta página explican cómo obtener finalmente las contraseñas reales. La única condición es contar con un JTR con soporte para formato NTLM. Lo mejor de todo es que todo esto se puede hacer usando el mismo archivo SAM de Windows que habíamos obtenido con anterioridad.

En el caso de Linux, Unix y Vista es más dificil, de hecho, un password en Linux de 8 caracteres ya lo es, y si en lugar de ser de 8 es de 9 resulta muchísimo más dificil.

La mala implementación de TCP/IP en Windows

Segun un boletín publicado de Microsoft, hay un problema en la implementación del protocolo TCP/IP. Para los que no saben, éste es el protocolo gracias al cual se realizan casi todas las conexiones hacia Internet. Este fallo es bastante grave, pues digamos que si hubiera un virus como el Blaster en este momento, podría infectar a todas las computadoras Windows que hay en Internet en minutos.

El problema se debe a la forma en la que el kernel de Windows maneja las estructuras TCP/IP que almacenan los estados de las peticiones IGMPv3 y MLDv2. El kernel de Windows realiza una validación insuficiente al almacenar el estado de las peticiones IGMP procesadas por TCP/IP. Esto podría permitir a un atacante remoto ejecutar código arbitrario por medio de paquetes IGMPv3 y MLDv2 especialmente manipulados enviados a través de la red. Un atacante que explote con éxito esta vulnerabilidad podría tomar control total sobre el sistema.

No sólo eso, sino que también procesa mal las solicitudes ICMP fragmentadas de una forma específica. Las solicitudes ICMP son las que se mandan cuando hacemos ping servidor.com. Este otro fallo en las solucitudes ICMP podría provocar un DoS, o sea, que el servidor deje de responder.

Más información en Hispasec

Vía (Hispasec)

¿Que no hay virus en Mac? Ya veremos…

Esta entrada podría ser polémica para los obtusos recalcitrantes fanáticos de Mac, pero es necesario informar sobre estas situaciones. Sólo mediante el conocimiento de los usuarios se puede evitar una infección en sus sistemas OSX.

Primero que nada, hablemos de la definición de virus de computadora, un virus de computadora es un programa capaz de instalarse en un sistema sin el conocimiento ni permiso del usuario, además es capaz de propagarse a otros sistemas. Dependiendo de su intención y forma de propagarse, pueden clasificarse con nombres oscurantistas como gusanos, troyanos o virus de macro, entre otros nombres. Algunos borraban archivos, dañaban discos duros, recolectaban información privada, o simplemente se propagaban sin hacer daño. ¿Pero todo acaba ahí?

(más…)

Autoridades Certificadoras (Certificados de Seguridad)

Como vimos anteriormente la criptografía asimétrica necesita de cuatro llaves para ser segura, pero siempre podemos dudar de que alguien no es quien dice ser. Para aumentar la seguridad se recurre a certificados de seguridad, los clásicos son VeriSign y Geotrust, que para mi punto de vista son muy caros, pero a veces la seguridad cuesta.

¿Cómo funcionan?

Las conexiones seguras en internet se hacen comúnmente usando el protocolo SSL. Cuando nos conectamos a un sitio seguro, leemos https:// en la barra de direcciones, en ocasiones vemos que sale en color amarillo y hasta aparece un candado. ¿Qué seguridad nos están brindando?, lo veremos a continuación:

Cuando inicias una conexión con un servidor, mediante SSL, se transmite la llave pública del servidor, luego tú también mandas tu llave pública, entonces de manera segura, se ponen de acuerdo para usar un sistema de cifrado simétrico; pero antes de establecer la conexión tú necesitas saber que el servidor pertenece realmente a la empresa que dice ser. Aquí entran las Autoridades Certificadoras, que lo único que hacen es dar de alta al servidor en GeoTrust, éstos a su vez mediante un estudio corroboran la identidad del servidor y, después de estar seguros, le otorgan un certificado de seguridad.

Un certificado de seguridad contiene los datos de la empresa y la llave pública del servidor, además está firmado digitalmente por la Autoridad Certificadora. Como los browsers tienen interconstruidas las llaves públicas de varias Autoridades Certificadoras, pueden revisar la firma digital del certificado, y así corroborar la identidad del servidor.

La firma digital de un certificado es simplemente el hash del certificado, que a su vez está encriptado con la llave privada de la Autoridad Certificadora. Para verificar que la firma es correcta y el certificado es válido, lo que se hace es descrifrar el hash del certificado, usando la llave pública de la Autoridad Certificadora; luego el hash desencriptado se compara con el hash del certificado. El proceso verifica implícitamente que: la Autoridad Certificadora en verdad firmó ese certificado, y que el certificado no ha sido alterado; por lo que se puede confiar plenamente en ese servidor para darle nuestro número de tarjeta de crédito, por ejemplo.

¿Pero realmente ésto nos brinda total seguridad?

Pues no, a pesar de todo el servidor nunca sabrá que quien se conecta a él es quien dice ser; pero definitivamente es mucho más seguro usar el certificado de seguridad que no usarlo.

La criptografía asimétrica (que usamos a medias)

La criptografía asimétrica, como ya hemos hablado en el blog, es la que necesita de dos llaves diferentes, una pública y otra privada. Se basa prácticamente que lo que encriptamos con la privada se desencripta con la pública y lo que encriptamos con la pública se desencripta con la privada, aunque en el primer caso cualquiera puede descencriptar el mensaje, pues la llave pública está a la vista de todos.

Pero realmente ¿Cómo se se supone que se debería usar?

La idea de la criptografía asimétrica es que ambos lados tengan un par de llaves, o sea, ejemplificándolo debería ser así:

Criptografía Asimetrica

Imaginemos que se va a enviar un mensaje, entonces primero la computadora A encripta el mensaje con su llave privada, y después lo encripta con la pública de la computadora B, luego le manda el mensaje; y, cuando la computadora B recibe dicho mensaje, lo desencripta con su llave privada primero (lo cual asegura que él es el destinatario correcto) y el resultado luego lo desencripta con la llave pública del emisor (lo cual asegura que el único que la pudo haber encriptado fué el emisor que nosotros conocemos). Todo esto suponiendo que las computadoras conocen la verdadera llave pública del otro.

De esa manera si alguien intercepta la comunicación no podrá obtener su contenido, y estamos seguros que tanto el emisor como el receptor son quienes dicen ser.

Ahora veamos cómo lo usamos cotidianamente

En el protocolo SSL, por ejemplo, el servidor le manda su llave pública al cliente y el cliente manda su llave pública al servidor, con ellas se ponen de acuerdo para usar algún sistema de criptografía simétrica y la llave que van a usar en él; así se logra que la comunicación de ahora en adelante esté cifrada con una sola llave, y se resuelve el problema que presenta la criptografía simétrica cuando no se sabe si el medio de transmisión es seguro.

¿Por qué no usamos criptografía asimétrica en toda la comunicación? Principalmente porque es muy tardado el proceso de crifrar y descrifrar algo con las llaves públicas y privadas, mientras que los algoritmos de criptografía simétrica son más rápidos.

Ahora ¿Cómo sabemos que el servidor realmente es el servidor con el que nosotros queremos comunicarnos?, ésto no lo podemos saber mediante más criptografía. Lo que se hace para resolver el problema es que se usa un tercero confiable (Autoridad Certificadora) que nos asegura que realmente alguien es quien dice ser; y, ¿cómo funciona una autoridad certificadora? lo veremos después en otro post.

Firmas Digitales

waxseal.jpg

Imagínese la siguiente situación: usted recibe una carta del gobierno ruso en donde se le informa que un familiar muy lejano ha muerto y nadie ha reclamado sus restos; le informan que ellos saben que usted es su familiar más cercano, por lo que si usted quisiera podría mandar el dinero necesario para darle un entierro digno.

(más…)

Encripta tu USB

truecryptMuchos seguramente han perdido ya algún dispositivo de almacenamiento “USB” con información valiosa o quizá con cualquier tontería sin importancia; pero en el primer caso esa información pudo tener un valor personal o un valor inherente y el que la encontró puede sacar ventaja de ello.

¿Hay alguna manera de lograr que quien haya encontrado tu USB no pueda leer nada su contenido? La respuesta es SÍ.

(más…)