martes, 24 de abril de 2012

OWASP Venezuela Latam Tour 2012

Es para mí un placer haber sido invitado a participar en el OWASP Latam Tour 2012 por el capítulo Venezuela.

En mi ponencia de este evento: "WebApp Penetration Testing" estaré abordando distintos temas sobre las pruebas de penetración en aplicaciones web. El siguiente es un temario tentativo:

WebApp Penetration Testing:
- ¿Qué es?
- ¿Qué no es?
- ¿Para que?
- Vulnerabilidades obvias pero catastróficas.
- Vulnerabilidades no-obvias pero igualmente catastróficas.
- Preguntas y Respuestas - Tema libre.

Espero contar con su asistencia!

OWASP LATAM Tour 2012:
Capítulo Venezuela.
Fecha: 26 de Mayo de 2012
Lugar: Av. Urdaneta, Esquina de Mijares, Parroquia Altagracia, Colegio Universitario Francisco de Miranda, Auditorio "Santiago Magariño". Caracas - Venezuela

La entrada es libre pero debes registrarte aquí.

Mas información aquí.

domingo, 15 de abril de 2012

Diversión con CRC. Parte I

En el anterior artículo de esta serie describimos las bases de los algoritmos CRC para verificar errores de transmisión. Adicionalmente, dimos un ejemplo de cómo intentar usarlos para detectar modificaciones maliciosas intencionales sobre nuestras comunicaciones protegidas. Es importante destacar que la anterior discusión es bastante independiente al método de cifrado utilizado. Lease cualquier cifrado por bloques como AES, DES, 3DES, en cualquiera de los modos usuales, OFB, CBC, CTR, etc. En todas estas "modalidades" de encripción, en algún momento, terminamos haciendo "XOR" a nuestro texto en claro, con algún tipo de "cadena pseudo-aleatoria". Los detalles son distintos y las posiciones de inyección en cada caso pueden ser diferentes, pero la idea de ataque descrita aplica exactamente de la misma forma.

En este artículo veremos tan sólo uno de los problemas que implica utilizar CRC para verificar modificaciones maliciosas. Recordemos el objetivo de nuestro atacante, i.e. modificar el texto interceptado de tal forma que el destinatario original no se de cuenta del cambio. El problema planteado al utilizar CRC es que ahora mi atacante necesita también modificar el código CRC si desea tener algún tipo de éxito en su estafa. Ahora bien, si nuestro atacante conociera el contenido completo del texto que está cifrado, su tarea sería muy sencilla.

El primer paso sería calcular el CRC que tiene el mensaje original, calcular el CRC que tendría el mensaje modificado, y tratar al CRC viejo y al nuevo de la misma forma con que se trata a las palabras "sur" y "nor:


Es decir, el viejo CRC viene a jugar el mismo personaje de la palabra "sur" y el nuevo CRC viene a jugar el mismo personaje que la palabra "nor". Exactamente la misma técnica. Despues de lo tan seguido espero que la idea sea más bien obvia: si al texto cifrado, le "quitamos" el texto en claro, mediante una operación XOR, y le agregamos el nuevo (también con una operación XOR), pues es fin del juego. Afortunadamente, esta técnica no le sirve a nuestro atacante, pues él sólo conoce una "parte" del texto en claro, i.e. la palabra "sur". Al no conocer el resto del texto, no tiene forma de calcular el "antiguo CRC" arriba. Aquí es donde viene lo interesante.

Resulta que por las propiedades de CRC, para cualquier par de cadenas de caracteres s1 y s2, el CRC del XOR es el XOR de los CRCs. En lenguaje matemático: CRC(s1 XOR s2) es igual a CRC(s1) XOR CRC(s2)! Esto es, la función XOR es "lineal". Si recordamos el primer artículo de esta serie, tal resultado no debería ser demasiado sorprendente. La suma, se transformó en un XOR pues estamos trabajando con coeficientes módulo 2, y el cálculo del CRC tenía en su corazon una simple determinación del residuo de una división por un polinomio. Es decir, (a + b) / c = ( a / c ) + ( b / c ), todos recordamos las propiedades distributivas de las sumas en la escuela, ¿no?

Bueno, si vamos a ser sumamente estrictos, en realidad esta última comparación no es exactamente correcta en el caso de CRC32, pero está muy cerca. Por cierto, si desean conocer todo y mucho más acerca del CRC, no hay nada mejor que este artículo. Sin lugar a dudas es la referencia más citada en toda la Internet.

Retomando el tema, resulta que nuestro atacante puede abusar esta propiedad de la función CRC, y calcular la modificación que debe hacerle al CRC cifrado directamente, sin conocer el CRC original en lo absoluto. Lo único que requiere es conocer la modificación que se le va a hacer a la cadena original. Si pensamos un poco la cuestion, la siguiente ecuación debería ser cierta:

CRC(texto ori XOR modificación) = CRC(texto original) XOR CRC(modificación)

Sin embargo, como habiamos mencionado antes, para el caso de CRC32 no es del todo así. Para hacer la historía corta, la respuesta final es simplemente que hay que calcular una especie de "CRC homogeneo", para que nuestra ecuación arriba se cumpla y podamos engañar a nuestros enemigos modificando sus mensajes cifrados. El cálculo de este CRC homogeneo que mencionamos no podría ser más sencillo. Lo único que hay que cambiar son los parámetros INITXOR y OUTXOR que describimos en el anterior artículo. Los nuevos valores para estos parametros no son nada mas que "0x00". Así de simple:



Nótese que el cálculo de esta "modificación" del XOR arroja exactamente el mismo resultado que cuando hicimos la modificación del CRC antiguo con el nuevo en nuestro primer intento de ataque. Espero que ni siquiera sea necesario convencerlos de que esto realmente funciona, pues debería ser evidente. Sin embargo, aquí esta la demostración en nuestra consola de python:



Resumen ejecutivo: la utilización de la función CRC para defendernos contra ataques activos sobre comunicaciones encriptadas no es efectiva. En este caso, para realizar una modificación al texto cifrado, lo único que se requiere es el cálculo del "CRC homogeneo" de la modificación que se desea hacer al texto para obtener la modificación que debe hacerse sobre el CRC cifrado y desconocido. Por si ésto fuera poco, en los siguientes artículos exploraremos aún más ataques sobre el uso de CRC en este tipo de situaciones. La diversión apenas comienza!

Inseguridad Bancaria Online. Parte III

Ha pasado considerable tiempo desde que escribí en esta serie de artículos sobre inseguridad bancaria a pesar de ser de los más populares de mi blog. Sorpresivamente, mis lectores más asiduos de esta serie provienen de Rusia y Ukrania lo cual debo confesar fue algo inesperado. Mi ingenuidad me hizo pensar que los administradores de bancos en Latinoamerica serían los más preocupados en leer estas lineas, pero en la práctica no fue así.

Despues de sopesar la pertinencia de esta serie por un largo tiempo, y al ver que otros han seguido empujando el barco en esta linea, decidí darle la bienvenida a mis colegas Rusos y Ukranianos y continuar con esta serie. Eso si, no esperen que aprenda Ruso a corto plazo, así que tendrán que seguir usando google translate.

Uno de los "errores" más frecuentes que veo en los sistemas de banca en linea hoy en día es el de los famosos "teclados virtuales". Para ponernos en la misma página, estos sistemas no son más que reemplazos del teclado físico de nuestra PC (o dispositivo móvil) por uno virtual directamente en el sistema web del banco:



Por cierto, tratar de usar estos teclados virtuales web desde tu dispositivo móvil es particularmente dificil (no intentar en casa). Pero aparte de hacernos la vida más dificil, el objetivo de estos teclados es bien conocido y cuando escuchamos los argumentos de sus implementadores casi que les creemos. La problemática que intentan resolver (al menos en teoría) es la de los famosos "keyloggers".

Los keyloggers son un tipo especial de malware cuyo objetivo es capturar todas las teclas tipeadas en nuestro PC (o dispositivo móvil). En este caso, cuando el cliente de la banca en linea tipea su contraseña en la pagina web del banco, el keylogger instalado en su máquina captura la contraseña y se la envía a nuestro atacante (esto sonará prejuicioso, pero no es un secreto que la mayoría de los destinos de estas contraseñas robadas son Rusa, Ukrania y etc. LOL).


La premisa básica de los teclados virtuales es que si no hay teclas tipeadas en el teclado de la PC, pues no hay password capturado. Hasta ahora todo va bien. Lamentablemente, lo que no se han puesto a pensar los que dan el visto bueno para implementar estos sistemas es ¿qué tan difícil es modificar un keylogger que captura teclas a uno que tome un screenshot de la pantalla del computador? La respuesta es: trivial. Realmente, hace muchos años hice el experimento de pedirle a un colega que midiera el tiempo que le costaría tomar el código fuente de un keylogger de teclas y convertirlo en un keylogger que capturara pantallazos. Para mi sorpresa, el trabajo duró menos de 2 horas. El único cambio requerido fue reemplazar el evento de "pulsar tecla" por el evento de "pulsar boton de mouse". Cuando este evento es escuchado por el nuevo keylogger, se ejecuta la captura de pantalla y listo. Por cierto, para los aventurados a experimentar, les recomiendo utilizar este keylogger hecho en python. El tiempo de transformación debería ser considerablemente menor.

Ahora bien, esta respuesta puede ser una sorpresa para algunos, pero increiblemente no lo es para los desarrolladores de teclados virtuales. En efecto, he visto muchos otros teclados de nueva generación que intentan un gran número de triquiñuelas para complicar la acción de los "screenloggers" como voy a llamarlos de ahora en adelante. Trucos por cierto, uno peor que el otro, pues ninguno ni siquiera se acerca a lograr su objetivo.

Por ejemplo, el primer truco es hacer que las teclas virtuales se "ofusquen" cuando el puntero se posiciona encima para pulsarlo. La idea es que el "screenlogger" tomará la foto de la pantalla cuando el boton está cambiado a un "*" y no cuando está revelando el número que se pulso. Las posiciones de las teclas cambian cuando se visita la página web por primera vez en un intento de prevenir al atacante visitar la página y mirar la posición de las teclas fijas. Lamentablemente, lo único que tiene que hacer el atacante, es esperar a la primera cargada de la página, tomar la foto de la posición de todas las teclas virtuales en ese momento, y luego tomar las posiciones de cuando se ejecutó el click con el mouse.

El siguiente truco es hacerlo aún más incomodo para el usuario. No sólo las teclas cambian de posición cada vez que visitas la página, si no que despues de cada click, las posiciones vuelven a cambiar. Este tipo de teclado no lo he visto (gracias a Dios, porque debe ser sumamente incomodo para el usuario), pero tampoco sería efectivo. Lo que el atacante debe hacer es simplemente agregar unos cuantos eventos más a la escucha de su "super screenlogger" para capturar lo que se deba capturar en el momento que no esta ofuscado.


Espero que mis lectores estén a este punto convencidos que no importa lo que hagan para arreglar estos teclados virtuales, su búsqueda es inutil. Si la PC del usuario ya está infectada, el estado del juego es "Game Over" y el resultado es "Admin 0, Attacker 1". Mi mensaje es: "por favor, dejen de perseguir a los elefantes rosados".


Ahora bien, digamos entonces que despues de esta larga reflexión sobre todo lo que puede hacer mi atacante ¿estaríamos en lo correcto de decir que los teclados virtuales no proveen ninguna seguridad adicional al sistema convencional? La respuesta es NO. En realidad, la utilización de estos teclados virtuales significa un incremento de la inseguridad para el usuario. Es decir, desde el punto de vista de seguridad informática, utilizar un teclado virtual es PEOR que no utilizarlo. Y espero que si no los sorprendí hasta ahora, con esta afirmación haya captado su atención.

La razón por la que la utilización de teclados virtuales aumenta el riesgo del usuario se aleja del ámbito técnico y se monta sobre el ámbito social/cultural y hasta práctico. Imaginemos la terrible situación dibujada en el siguiente monólogo:

- Necesito hacer banca en linea.
- No se, cualquier transacción.
- Estoy en mi oficina, con mucha gente caminando por los pasillos y realmente es muy dificil evitar que los que pasan por ahí vean mi pantalla.
- Si, lo sé, pero no puedo esperar a llegar a mi casa, en donde tengo un cuarto sellado, con una sola computadora, sin nadie alrededor y protegido contra radiaciones electromagneticas (Tempest).
- Tengo que hacer la transacción desde aquí y en ese instante en la oficina del trabajo.
- Ahora bien, abro la página web del banco, y me pongo a teclear mi contraseña en el bendito tecladito virtual.
- Toma el tiempo que me demoré tipeandola.
- Ahora toma el tiempo que te demorarías tipeando la misma contraseñaen el teclado físico.
- El tiempo en tu teclado físico es muchisimo menor, aún más si tu trabajo es justamente con computadoras todo el día, pues estarás acostumbrado a tipear muy rápido!.
- A menos por supuesto que escribas con un sólo dedo sobre el teclado.
- No creo que escribas con un sólo dedo sobre el teclado físico si te la pasas todo el día en frente de la PC!
- Hey, un momento, pero cuando tecleas sobre tu teclado virtual, en efecto! es como si tuvieras UN SOLO DEDO (el puntero del mouse).
- Ahora lo entiendo. El teclado virtual me regreso al estado mental de un niño de 5 años que recien aprende a tipear conscientemente sobre la PC, utiliza un sólo dedo y se detiene a buscar las letras para tipearlas una por una, demorandose largos tiempos para tipear hasta las más simples frases.


En efecto, el tiempo de oportunidad para que alguien que casualmente pasa por ahí, vea tu contraseña mientras utilizas el mouse para tipearla en el teclado virtual es muchisimo mayor al que tendría si utilizas tus 8 o 10 dedos para tipearla en el teclado físico muchísimo más rapido. La técnica de "robar la contraseña de tu víctima mientras la tipea sin que se de cuenta" recibe el nombre de "shoulder-surfing" y es una práctica más bien de los de la escuela vieja. Sin embargo, no deja de ser sumamente efectiva.

Es un largo cuento y un triste desenlace para los que usan esta tecnología que, a pesar de ser muy "bonita" y "vistosa", es sumamente insegura y no debería ser usada en ninguna situación.

En los siguientes artículos de esta serie exploraremos los pésimos hábitos de utilizar Javascript de terceros y hasta el uso de "tarjetas de coordenadas" en los sistemas de banca en linea. Un saludo para mis colegas administradores de banca en linea de Rusia y Ukrania ;) Espero corrijan sus sistemas y que no sufran de estas fallas! No se lo pierdan!

Ver también:
Inseguridad Bancaria Online. Parte I
Inseguridad Bancaria Online. Parte II

sábado, 14 de abril de 2012

Más sobre Passwords y Contraseñas

En el artículo anterior de esta serie comentábamos que la contraseña más fuerte de todas es aquella que no se la dices a nadie.

Sin embargo, queda todavía la pregunta en el aire: ¿Pero como hago para no decirle a nadie mi contraseña? A pesar que parezca tonta, la pregunta es muy pertinente. Muy pocas personas se han puesto a pensar que no importa lo que hagan, su contraseña tiene que ser revelada al menos a un ente más aparte de nosotros mismos. Este ente es, por supuesto, el sistema que nos la pide para autenticarnos.

En realidad, no existe nada técnicamente que nos proteja del administrador incapaz o inmoral, que al final de cuentas termina siendo más o menos lo mismo. Por ejemplo, ¿Cuantas personas utilizan la misma contraseña para ingresar a su correo electronico y al twitter o al facebook o a alguna otra red social? ni que hablemos de las cuentas de bancos y demás. La siguiente pregunta es: ¿Qué le cuesta al administrador de aquel foro insignificante que nos pidio nuestro email y que pongamos una contraseña a intentar esa misma contraseña contra la cuenta de correo que le hemos dado? Absolutamente nada. Si la contraseña que utilizamos en ese foro insignificante es la misma que usamos en el email que pusimos, las cosas se empiezan a complicar. Más aún, lo que realmente debería preocuparnos es lo que pasará cuando a ese foro insignificante lo vulneren y queden todas nuestras contraseñas y correos electrónicos comprometidas y publicadas en Internet.

Parece increible, pero incluso gente que es considerada "conocedora" en estos temas, todavía no hace mucho discutía sobre si era adecuado almacenar las contraseñas de los usuarios en texto claro, o debían, como lo hace la mayoría del mundo civilizado, almacenarlas en modo "ofuscado" utilizando algún algoritmo de "resumen", mejor conocido como "hashing".

Para efectos de este artículo, consideramos un escenario en donde los administradores del sitio a quien le confiamos nuestro password no tienen un pensamiento tan "anticuado" y asumimos que almacenan las contraseñas utilizando alguna función irreversible. Esta es la situación en donde cobran importancia las conocidas "tecnicas de cracking" con las que se intenta descubrir la contraseña de una victima sin saber ninguna otra información acerca de ella. En este análisis trato de demostrar que las creencias de hace algunos años simplemente no aplican a la hora de decidir la contraseña que debemos utilizar para autenticarnos contra cualquier sistema informático.

Una de estas creencias es que una contraseña de fortaleza adecuada tiene al menos 8 caracteres. De hecho hace poco leí un artículo en donde la NASA supuestamente recomendaba que las contraseñas debían tener al menos 8 caracteres y de paso, lanzaban una receta sobre la composición de la contraseña. Justamente lo que habíamos explicado en nuestro anterior artículo que no se debe hacer.

Nuestra primera afirmación es que una contraseña de 8 caracteres (dependiendo del algoritmo resumen que se utilice para almacenarla) ya no es lo suficientemente fuerte como para aguantar a prácticamente ningún atacante sin importar que tan poco sofisticado sea. Quiere decir, lamers, script kiddies, y toda clase de principiantes tienen a su alcance romper este tipo de contraseñas sin mucho trabajo utilizando herramientas enlatadas. Para efectos demostrativos, utilizaremos la herramienta hashcat. Esta herramienta hace uso de los GPUs de nuestras tarjetas de video y ademas provee una gran cantidad de tipos de hashes para crackear. Veamos esta herramienta en acción:


[neo@matrix oclHashcat-0.26]$ ./cudaHashcat64.bin -h
cudaHashcat, advanced password recovery

Usage: cudaHashcat [options] hashlist dict_left|mask_left dict_right|mask_right

...
Hash types:
  -m,  --hash-type=NUM       number correlates to hash-type

    0 = MD5
    1 = md5($pass.$salt)
    2 = md5($salt.$pass)
    3 = md5(md5($pass))
    5 = vBulletin < v3.8.5
  100 = SHA1
  101 = sha1($pass.$salt)
  102 = sha1($salt.$pass)
  300 = MySQL > v4.1
  900 = MD4
 1000 = NTLM
 1100 = Domain Cached Credentials
 1400 = SHA256


En donde se presenta una lista de los hashes más comunmente utilizados en la actualidad. Para aún más hashes, se puede utilizar la versión "plus" de esta herramienta.

Consideremos ahora el caso de los hashes MD5, muy utilizados en el mundo Unix e intentemos valorar el tiempo que nos tomaría "crackear" una contraseña de 8 caracteres (incluyendo números, mayúsculas y minusculas).

Status.......: Running
Input.Mode...: Mask (?1?1?1?1?1?1?1?1)
Hash.Target..: 696ebfe2a8b2c685802a5a33ed4f1bae
Hash.Type....: MD5
Time.Running.: 3 mins, 11 secs
Time.Left....: 3 days, 21 hours
Time.Util....: 191344.7ms/82.1ms Real/CPU, 0.0% idle
Speed........:   650.1M c/s Real,   652.1M c/s GPU
Recovered....: 0/1 Digests, 0/1 Salts
Progress.....: 124393881600/218340105584896 (0.06%)
Rejected.....: 0/124393881600 (0.00%)
HW.Monitor.#1:  0% GPU, 81c Temp
[s]tatus [p]ause [r]esume [q]uit => q

Lo que debe llamar la atención es que mi tarjeta de video (muy viejita ya por cierto), sólo requiere de menos de 4 días para recorrer exhaustivamente todo el espacio posible de contraseñas. El número total de posibilidades es el enorme número 218340105584896. Sin embargo, alcanza una velocidad de 650 millones de cifrados por segundo. Ahora veamos el caso de las contraseñas en el mundo Windows. Asumamos el mismo espacio de contraseñas, 8 caracteres, incluyendo minúsculas, mayusculas y dígitos. En este caso, el algoritmo utilizado es NTLM:

Status.......: Running
Input.Mode...: Mask (?1?1?1?1?1?1?1?1)
Hash.Target..: 504c4894815c8ececaa608268a0f3373
Hash.Type....: NTLM
Time.Running.: 30 secs
Time.Left....: 2 days, 19 hours
Time.Util....: 30571.4ms/19.1ms Real/CPU, 0.1% idle
Speed........:   901.6M c/s Real,   904.1M c/s GPU
Recovered....: 0/1 Digests, 0/1 Salts
Progress.....: 27563950080/218340105584896 (0.01%)
Rejected.....: 0/27563950080 (0.00%)
HW.Monitor.#1:  0% GPU, 61c Temp

Como se puede ver, en este caso sólo necesito de aproximadamente la mitad de tiempo! para conseguir la contraseña. Sin embargo, bajo ciertas condiciones, y por motivos de compatibilidad, Windows almacena la misma contraseña utilizando un algoritmo mucho más débil conocido como LM. En esos casos, el tiempo requerido para romper la contraseña es increiblemente menor. Pero ni siquiera vayamos ahí.

Un detalle que sí vale la pena tomar en cuenta es la diferencia de velocidad para romper las contraseñas en ambos algoritmos. Para el caso de NTLM, la velocidad llega a 900 millones de contraseñas por segundo. En consecuencia, se hace evidente que uno de los verdaderos aspectos a tener en cuenta es el algoritmo utilizado para almacenar la contraseña y no tanto su composición. Realmente, mientras más lento se haga el trabajo de nuestro atacante, mejor protección alcanzaremos.

Para finalizar, quisiera romper un último mito muy arraigado a pesar de que se ha hablado al respecto hasta las nauseas. Lo que quisiera desmentir son las famosas "recetas" y su verdadera contribución hacia la fortaleza de nuestro password. Para hacerlo más fácil, consideremos de nuevo el algoritmo NTLM, una contraseña de 8 caracteres, pero que tiene una sola mayuscula. La máscara para el ataque de fuerza bruta es muy sencilla:

./cudaHashcat-lite64.bin -1 ?l?d -2 ?u -m 1000 --pw-min=8 --pw-max=8 504c4894815c8ececaa608268a0f3373 ?2?1?1?1?1?1?1?1

El comando anterior significa lo siguiente:

-m 1000       ->    tipo de hash. NTLM en este caso.
-1 ?l?d         ->    primer charset, minúsculas y números.
-2 ?u            ->    segundo charset, sólo mayúsculas.
--pw-min=8 ->    intentar passwords de mínimo 8 caracteres
--pw-max=8 ->   intentar passwords de máximo 8 caracteres

Finalmente, ?2?1?1?1?1?1?1?1?1 es la "máscara" y quiere decir que intentemos passwords en donde el primer caracter proviene del charset #2 (?2), es decir, sólo mayusculas (?u), y el resto de caracteres provienen del charset #1 (?1) es decir minúsculas (?l) y números (?d). Pero esta no es nuestra receta de forma correcta, pues nosotros construiremos un password que tenga una mayuscula no sólamente en la primera posición sino en cualquiera de las 8. No hay problema, simplemente el resultado de nuestro experimento lo multiplicaremos por 8 para contar las 8 posiciones donde puede estar nuestra masyúscula. Si leyeron la pequeña nota al pie de página de mi artículo anterior, este factor les debe sonar conocido. En todo caso veamos la velocidad de cracking para esta receta:

Status.......: Running
Hash.Target..: 504c4894815c8ececaa608268a0f3373
Hash.Type....: NTLM
Time.Running.: 2 seconds
Time.Left....: 24 minutes, 32 seconds
Plain.Mask...: ?2?1?1?1?1?1?1?1
Plain.Text...: **ysguca
Plain.Length.: 8
Progress.....: 4025548800/2037468266496 (0.20%)
Speed.GPU.#1.:  1381.2M/s
HWMon.GPU.#1.:  0% GPU, 72c Temp
[s]tatus [p]ause [r]esume [q]uit => q

Descomunal!! en este caso, sólo necesito de 24 minutos para intentar todas las combinaciones. Por supuesto este número hay que multiplicarlo por 8 porque la mayuscula puede estar en cualquier posición. Lo cual nos da unas míseras 3 horas mas o menos. Si ahora hacemos que nuestro password tenga una mayuscula y un dígito, el resultado es:

Status.......: Running
Hash.Target..: 504c4894815c8ececaa608268a0f3373
Hash.Type....: NTLM
Time.Running.: 1 second
Time.Left....: 1 minute, 9 secondsPlain.Mask...: ?2?3?1?1?1?1?1?1
Plain.Text...: **eartka
Plain.Length.: 8
Progress.....: 1277952000/80318101760 (1.59%)
Speed.GPU.#1.:  1141.6M/sHWMon.GPU.#1.:  0% GPU, 55c Temp
[s]tatus [p]ause [r]esume [q]uit => q

Resulta que a este resultado hay que multiplicarlo por 8 y por 7, para contar las 8 posiciones donde puede estar la mayuscula y las 7 posiciones donde puede estar el dígito una vez que la mayuscula haya sido seleccionada. O viceversa, es lo mismo. El resultado es un poquito más de una hora. Como detalle de implementación, se ejecutará el comando de arriba con las siguientes combinaciones de máscaras:

?2?3?1?1?1?1?1?1
?2?1?3?1?1?1?1?1
?2?1?1?3?1?1?1?1
...
?1?2?3?1?1?1?1?1
?1?2?1?3?1?1?1?1

etc. Ésto nos dará 56 mascaras que se demorarán 1 minuto cada una.

Lamentablemente, a pesar de que no queramos entenderlo, mientras más "metainformación" demos a nuestro atacante en la forma de "recetas" para construir nuestros passwords, le estamos haciendo el trabajo increiblemente más fácil. Por otro lado, los verdaderos parámetros para determinar la fortaleza de una contraseña no es tanto su composición, como lo es su longitud y el algoritmo utilizado para protegerla. La composición no es importante pues abandonaremos las recetas y utilizaremos cualquier combinacion de minusculas, mayusculas y numeros de formas no convencionales y más importante aún: "divulgadas a la menor cantidad de personas posible".

Diversión con CRC. Introducción

Una de las áreas probablemente menos trabajadas por los "pentesters" de hoy en día es la criptografía. Sin embargo, poseer habilidades básicas en este tema será cada vez más y más obligatorio para hacer nuestro trabajo de forma adecuada. Este artículo es el primero en una serie dedicada a la criptografía y su aplicación en las pruebas de penetración modernas.

El algoritmo de CRC (Cyclic Redundancy Code) fue standarizado alrededor del año 1975, en la decada que parece ser donde todo lo importante se inventó. El objetivo de sus creadores era contar un código de verificación que permitiera detectar errores de transmisión de datos en las nacientes redes digitales. A pesar de que hoy en día contamos con redes muy confiables en donde errores "ocasionales" no son un verdadero problema, el algoritmo es todavía utilizado con relativa frecuencia y con desastrozas consecuencias para la seguridad.

El punto clave es que los algoritmos de CRC fueron diseñados para detectar modificaciones "no-intencionales." Sus autores nunca pensaron en que tendrían que enfrentarse a una red de redes con atacantes activamente modificando e interviniendo sus comunicaciones. En consecuencia, la utilización de esta clase de algoritmos con la idea de detectar modificaciones maliciosas en nuestra Internet está condenada a ser inefectiva en la mayoría de los casos. El ejemplo más conocido es probablemente el ataque fulminante que recibió WEP en donde la debilidad del CRC32 jugó un papel muy importante. Sin embargo, hay todavía muchos ejemplos vigentes asi que el entendimiento de las debilidades de este algoritmo significa entretenimiento garantizado por todavía un muy buen tiempo :D

La clase de algoritmos CRC están basados en simples operaciones módulo un polinomio (irreducible en muchos casos, aunque primitivo es preferible) en un cuerpo finito, específicamente GF(2). Ésto significa que las sumas se convertien en operaciones "XOR" y los inversos están garantizados cuando el polinomio es irreducible. Básicamente, las operaciones en este cuerpo (o campo) son muy similares (isomorficas de hecho) a las operaciones algebraicas elementales a las que estamos acostumbrados. Pero toda esta teoría es suficiemente aburrida, y esto se supone que sea divertido. La diversión comienza ahora:

Una de las construcciones criptográficas más prominentes en nuestros protocolos de comunicación segura involucra transformar texto claro en cifrado mediante la operación "XOR" del mensaje a proteger con una cadena "aleatoria" y de dificil deducción por parte de nuestro atacante. La razón de usar esta construcción es que nuestras computadoras pueden hacer las operaciones necesarias de forma muy rápida. Por ejemplo, si el mensaje que quiero proteger es "Minas al suroeste" y mi cadena aleatoria es la secuencia de bytes: "506f77735727601cdf3609a8c9d7dc1a9f", entonces lo que tengo que enviar por el canal inseguro es el resultado del siguiente calculo:





A medida que la cadena de cifrado se hace más aleatoria, el trabajo de mi atacante se hace más dificil. Sin embargo, este esquema es muy fácil de vulnerar simplemente aprovechando dos problemáticas muy evidentes: 1) la disponibilidad de la estructura del mensaje y 2) la falta de protección de integridad del texto cifrado. El primer problema estará siempre presente en protocolos estándares y abiertos pues sería inutil pensar que la estructura de mis mensajes permanecera oculta para mi atacante por mucho tiempo.  Sin embargo, el segundo problema es el tema que abordan los "codigos de verificación criptográfica" y es donde se ha intentado utilizar CRC de forma muy poco efectiva. Pero primero veamos cómo mi atacante es capaz de vulnerar el esquema inicial.

Si mi atacante quisiera confundir a mi interlocutor, y modificar el mensaje para que en lugar de decir "Minas al suroeste", dijera, "Minas al noroeste", todo lo que tiene que hacer son unas cuantas simples operaciones con XOR, como siguen:



Ahora, cuando mi interlocutor reciba el texto cifrado modificado por mi atacante, y lo "desencripte" utilizando la cadena aleatoria, obtendra el mensaje "Minas al noroeste" en lugar de obtener el mensaje original.


Nótese que mi atacante no necesitó adivinar la complicada cadena aleatoria. Tódo lo que necesitó fue aprovechar un poco la estructura del mensaje, i.e. la posición donde estaba el mensaje que deseaba modificar, y ese pedazo del texto claro, i.e. "sur". Esto puede parecer un requerimiento demasiado grande, pues el atacante necesita conocer un pedazo del mensaje original ("sur"). Sin embargo, este requermiento no es nada dificil de cumplir en la práctica cuando consideramos lo altamente predecibles que pueden llegar a ser nuestras comunicaciones. Al iniciar una carta, ¿no esperamos siempre un "saludo"? ¿una fecha? ¿una localidad?

Ahora bien, aceptemos por un momento que es imposible eliminar la redundancia de nuestras comunicaciones de tal forma que asumamos que nuestro atacante siempre tendrá un pedazo de información con la cual perpretar este ataque. ¿Acaso no podemos hacer nada para defendernos? Intentemos usar el chequeo CRC. Específicamente, utilizaremos el algoritmo CRC32 que es el más usado. La utilización de este algoritmo en este tipo de situaciones y las formas en que puede abusarse para perpetrar ataques altamente efectivos serán el tema de los siguientes artículos de esta serie. Sin embargo, para terminar esta introducción al tema, veamos cómo se calcula y como se usa el CRC32.

El CRC32 más popular está basado en el polinomio:

x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1

El cual representaremos con la secuencia de bytes: 0xEDB88320. A cada mensaje, le corresponde un código CRC32 cuyo cálculo detallado es un poco involucrado, pero en el corazón del algoritmo está la determinación del residuo de la división de nuestro mensaje por este polinomio, asumiendo coeficientes módulo 2. La mejor forma de describirlo para nosotros los informáticos es un algoritmo. La implementación en python que presento aquí es muy utilizada, y está basada en una tabla cuya generación veremos a continuación:

def CRC(mensaje,INITXOR,OUTXOR):
    r = INITXOR
    for c in mensaje:
        r = crc32_table[(r ^ ord(c)) & 0xFF] ^ (r >> 8)
    r ^= OUTXOR

La función anterior utiliza dos parametros adicionales (INITXOR y OUTXOR) que no hemos mencionado todavía, pero que para el caso CRC32, los valores son simplemente 0xFFFFFFFF en ambos casos. Ahora bien, hace falta conocer los valores de crc32_table. Esta tabla se puede generar utilizando la siguiente función:

def gen_crc_table(CRCPOLY):
    res = [0 for i in xrange(256)]
    for n in xrange(256):
        c = n
        for k in xrange(8):
            if ((c & 1) != 0):
                c = CRCPOLY ^ (c >> 1)
            else:
                c = c >> 1
    return res

Para el caso de CRC32 el parámetro CRCPOLY de la función anterior es simplemente el valor 0xEDB88320 mencionado anteriormente. Esto es todo. Veamos como funciona esto en la consola de python:



Ahora que sabemos como se calcula el código CRC32 para un mensaje, estamos listos para intentar usarlo y prevenir que nuestro atacante envíe a nuestra tropa al campo minado del noroeste. La idea es muy natural, en lugar de enviar sólamente mi mensaje encriptado con mi cadena de bytes aleatoria, lo que voy a enviar es la encripción de la concatenación del mensaje original con el código CRC32 recien calculado. La idea sería que cuando mi atacante modifique el mensaje encritpado, mis interlocutores se den cuenta e ignoren el mensaje falso. El código CRC de mi mensaje es: 0xf60ebe68, pero lo concatenamos al mensaje con los bits menos significativos primero. Esta concatenación la podemos ver en la figura anterior. Por lo tanto, lo que enviaré a la tropa es:

El texto cifrado es básicamente el mismo, pero concatenado con el cifrado del código CRC32 que calculamos. Nuestro atacante puede hacer ahora exactamente el mismo procedimiento anterior. Sin embargo, ahora cuando la tropa obtenga el texto falsificado, tendremos un código CRC32 con que validarlo:



y al calcular el CRC32 del mensaje que modificó mi atacante, encontrará:


El cual no es igual al CRC que enviamos en el texto cifrado. La tropa descartará el mensaje y todos felices. Sin embargo, resulta que por las propiedades del algoritmo de CRC, mi atacante tiene una gran cantidad de posibilidades para atacar este nuevo esquema. El detalle de algunas de estas fórmulas de ataque serán el tema de los siguientes artículos de esta serie.