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

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.

Pero en realidad, ¿Qué es un Hacker?

Si existiera un record Guiness para el término menos comprendido y peor usado de todas las culturas en toda la historia de la humanidad, en mi no tan humilde opinión, la palabra "hacker" se llevaría todos los premios y reconocimientos.

Sólo por completitud y con la esperanza de que algún día la comunidad "no-hacker" logre entenderlo, repito aquí la definición más aceptada entre los verdaderos conocedores de la materia. El RFC 1392, "Glosario de usuarios de Internet", define claramente el término "Hacker":

hacker
      A person who delights in having an intimate understanding
      of the internal workings of a system, computers and computer
      networks in particular.  The term is often misused in a
      pejorative context, where "cracker" would be the correct
      term.  See also: cracker.

Como tarea al lector no-técnico, aquí se puede averiguar lo que es un RFC y la razón por la cual, con especial énfasis en este caso en particular, debe considerarse como una fuente autoritativa. Ahora bien, lejos de golpear al hombre caido, abrumandolo con más y más términos rimbombantes como "phisher", "phreaker", "pharmer", "script-kiddie", script-junkie", "lamer", etc, que muy poco aportan a toda esta discusión, el resto de este artículo trato de señalar los errores y posibles razones por las cuales históricamente se ha abusado de este término de forma tan inclemente.

Como siempre, el post/artículo que lo inicio todo, afirma lo siguiente:

"...
       Un hacker es un experto informático especialista
       en entrar en bases de datos ajenas sin autorización alguna
..."

Armados con el nuevo conocimiento adquirido del RFC anterior, se puede ver que esta afirmación es doblemente incorrecta. Por un lado, en el contexto peyorativo, el término correcto debería ser "cracker". Sin embargo, aún haciendo esa corrección, se cae en el segundo error de pensar que un "cracker", por definición, es algún tipo de experto informático, cualidad adecuadamente atribuida, por definición, a un "hacker".




La raíz primordial de la confusión es un básico error de lógica. A pesar de que algunos "crackers" puedan poseer algún tipo de conocimiento que les permita compararse con los "hackers", no los hace miembros de la misma casta. De hecho, en la gran mayoría de casos de "crackers" conocidos, se ha evidenciado su mediocridad y pobre entendimiento de los conocimientos técnicos de los sistemas y redes de computadoras. De aquí que el término correcto en el contexto peyorativo sea "cracker" y no "hacker". Al final, una persona con poco conocimiento, poco entendimiento y gran deseo de importancia lo único que le queda es tratar de llamar la atención para compensar su deficiencia. La forma más simple es utilizar el conocimiento de los verdaderos "hackers" de formas muy "escandalosas" (usualmente ilegales) y esperar que los medios de comunicación inflen su tan golpeado ego. Su poco entendimiento, y mediocres técnicas los hacen terminar en manos de las autoridades y pagar por sus fechorías más temprano que tarde. Pero esto no importa, pues los minutos de "gran fama", para la mente del "cracker", muy bien los valen. Aún así, "crackers reformados" continuan ordeñando el conocimiento que se han robado despues de pagar sus condenas, contribuyendo a que se perpetúe cada vez más el incorrecto uso del término "hacker".

El artículo original continúa de la siguiente manera:

"...
       Generalmente trabajan con seudónimos y compiten entre
       ellos mismos por vulnerar sistemas de seguridad. Existen
       varias clasificaciones, pero la más utilizada actualmente
       es la de hackers sombrero blanco y negro
..."

Con este comentario acabamos de avanzar 10 años en un abrir y cerrar de ojos. La clasificación de hacker y cracker ha quedado muy atras para dar paso a un animal completamente distinto, el "hacker sombrero negro". El nacimiento de este término es nada mas entendible. En los párrafos anteriores dejamos establecido que la capacidad y conocimiento técnico es completamente ortogonal al hecho de ser o no un "cracker". Sin embargo, en un mundo donde la Internet ha permeado la gran mayoría de aspectos de nuestras vidas directa o indirectamente, se abre una posibilidad para la persona de pocos principios morales y éticos que en efecto posee la habilidad técnica de un "hacker". Es un mundo en donde nos vemos obligados a criminalizar las acciones abusivas que permiten ganancias inmorales a las personas que hacen uso poco ético de su conocimiento (Leyes sobre delitos informáticos). A diferencia de una Internet académica en donde habitaban los "hackers", en el mundo de hoy, vivimos una Internet donde se mueven grandes cantidades de dinero a velocidades realmente sorprendentes. Hemos llegado a un mundo en donde el "hacking" se transformó en una ocupación por demás rentable, ya sea por medio de actividades legales o ilegales, en donde son más rentables las últimas que las anteriores. Bienvenidos al mundo de los "criminales informáticos".

Continuando con el artículo original:

"...
      Hacker sombrero blanco (también conocido como hacker ético) 
      Infiltran las redes para mostrar el grado de vulnerabilidad 
      que tienen. Sus motivaciones son inocuas. Generalmente dejan 
      mensajes advirtiendo sobre lo desprotegido que puede estar 
      el sistema.
..."

Suspiro. Sin ánimos confrontacionales, pero con la autoridad que me dan más de una década en el mundo de la seguridad informática, multiples certificaciones internacionales, y miembro élite de los muy pocos en el mundo en haberlas alcanzado, tengo que oponerme fervientemente a la anterior definición. El punto más importante para la definición del "hacker sombrero blanco" reposa en hacer lo que hacen los "hackers" pero con permiso expreso y legal de los dueños del sistema que se infiltra. Lamentablemente no hay nada ético en vulnerar un sistema sin el permiso de sus dueños. Es como si llegaran a tu casa, abrieran la puerta, se durmieran en tu cama, y te dejen una nota alertandote que laves tus sábanas pues cualquiera te las puede dejar sucias. Por más inocua que pueda ser la motivación, estas acciones no dejan de ser un acto inmoral y a la luz de una ley de delitos informáticos, son además unos actos ilegales y criminales.

La definición incorrecta, sin embargo, es convenientemente utilizada por criminales tratando de presentar una imagen "reformada" que buscan justificación para continuar con su conducta delictiva. A pesar de que la anterior afirmación parezca argumentativa, invito a mis lectores a analizar la ley de delitos informáticos del mismo link del artículo original. El lector atento notará inmediatamente que la "motivación" dentro de la mencionada ley no juega ningún papel. Si obtienes acceso a un sistema sin autorización, por la motivación que sea, estas cometiendo un delito y en consecuencia tu única clasificación es de "criminal", o en todo caso, "criminal informático", nada de hacker, nada de blanco y nada de negro. Ni siquiera un sombrero, a lo sumo un traje anaranjado.

Finalmente llegamos a la posiblemente única afirmación mas o menos precisa del artículo:

"...
      Hacker sombrero negro: Son los expertos informáticos
      que intentan causar –y en algunos casos lo logran- daños
      a los usuarios y administradores del sistema. También
      son conocidos como ciberpiratas. Pueden incurrir en la
      extorsión y en actos criminales. Literalmente “roban”
      información y hacen uso de esta a su conveniencia.
..."

Las motivaciones de nuevo, pueden ser muchas más de las que se mencionan en el párrafo anterior. Sin embargo, el punto clave, de nuevo, es que todas estas acciones carecen de la autorización expresa de los dueños del sistema que se vulnera. Cabe destacar que algunos "criminales confesados o reformados" algunas veces intentan pasar aunque sea por "hackers de sombrero negro" en su afán de fama. Vale entonces la pena hacer una distinción adicional. Como habíamos dicho anteriormente, el hacker de sombrero negro, por ser hacker, posee un profundo conocimiento técnico sobre la tecnología que vulnera. En consecuencia, resulta muy difícil creer que los conocimientos del criminal atrapado y condenado sean tan sofisticados que ni siquiera pudieron evitar que lo atraparan. A menos, por supuesto, que ademas de criminal, haya tenido algún deseo morboso de visitar una celda por la parte de adentro y por un periodo alargado. En consecuencia, tampoco los atrapados y condenados, pueden recibir la "condecoración" de "hacker" pues sus conocimientos no han demostrado ser lo suficientemente "élite". En efecto, los verdaderos "hackers" son "invisibles". Ahora bien, la única esperanza de reivindicación para un criminal convicto y confeso es ponerse a estudiar verdaderamente y conocer en profundidad las cosas. Esta capacidad no esta prohibida para nadie, incluso para los criminales menos sofisticados. Sin embargo, requiere de mucho esfuerzo y dedicación, requerimientos que los "media-whores" carecen, pues todo su tiempo lo dedican a llamar la atención.

Es aquí donde radica toda la confusión. Los medios de comunicación se enteran de un evento criminal o "escandaloso" y buscan información. Lamentablemente, nunca hay un "verdadero" hacker disponible pues ellos están "siempre ocupados". Tristemente, los medios de comunicación caen en manos de los charlatanes, embusteros, media-whores, entre otros, cuya desinformación contribuye aún más a la mala utilización del término y obteniendo una pésima fama para los "hackers".

Para finalizar este agrío y áspero "rant", no podemos dejar de mencionar a la piedra en el zapato. En este caso, los sucesos de las vulneraciones de las cuentas de twitter de personalidades importantes Venezolanas por parte de un grupo de individuos que se hacen llamar N33. Como buenos "media-whores", y ávidos de atención, lograron una entrevista aquí. Tal como hemos demostrado en los parrafos anteriores, calificar a estos individuos como "hackers" es un error por demás peligroso. De acuerdo a toda la discusión anterior, el termino indiscutiblemente correcto es "criminal informático". Sin embargo, ¿podría tratarse de un "hacker sombrero negro"? Es decir, ¿Saben algo realmente de lo que están haciendo? o simplemente ¿utilizan las herramientas enlatadas fácilmente accesibles en Internet para cometer actos ilegales? Lamentablemente, no se tiene suficiente información para responder estas preguntas. Sin embargo, vulnerar cuentas de correo electronico o cuentas de twitter no requiere de prácticamente ningún conocimiento en informática o en casi nada en realidad. Lo único que se requiere es saber buscar en Internet o ser lo suficientemente "hala mecate" para que algún "hacker sombrero negro" te diga o "proporcione" las herramientas que necesitas para cometer tus fechorías. Así de simple y poco interesante es el mundo de los "criminalillos" informáticos. Lastima que ese tipo de "noticias" no sean tan interesantes para los medios de comunicación.

Por el bien de las generaciones futuras y como lo diría un verdadero hacker hace varios años atras, Ken Thompson, en su discurso donde recibió el premio Turing:

"...I would like to criticize the press in its handling of the "hackers", the 414 gang, the Dalton gang, etc. The acts performed by these kids are vandalism at best and probably trespass and theft at the worst. It is only the inadecuacy of the criminal code that saves the hackers from very serious prosecution..."

Casi 30 años despues, señor Thompson, lastimosamente, se continúa un manejo inadecuado por parte de la prensa, y a pesar de nuevas leyes y castigos, las fuerzas policiales de la gran mayoría de paises poseen capacidades técnicas tan limitadas que con mucha dificultad logran aprehender a los más mediocres y menos  sofisticados de los criminales informáticos de hoy en día.


Dios nos salve del futuro, pues de continuar los errores de percepción y poco entendimiento de los fenómenos culturales que nos rodean, estaremos criando una "bestia que no podremos controlar".

La certificación Cyber Guardian

Continuando la serie de artículos relacionados a certificaciones de seguridad informática, decidí comentar un poco sobre una certificación relativamente nueva pero por demás interesante y pertinente. Se trata de la certificación "Cyber Guardian" del SANS Institute.

Esta certificación está dirigida a una comunidad muy específica. De acuerdo al sitio web del SANS Institute, el objetivo es:

"... Entrenar personal que forme parte de las fuerzas armadas, departamentos de defensa y otras agencias gubernamentales cuyos roles incluyan el aseguramiento de sistemas, reconocimiento, contra-terrorismo y contra-hacks..."

La visión no podría ser más pertinente en un momento en que vivimos los peores ciber-ataques de nuestra historia. Desde incidentes altamente sofisticados y promocionados por estados como "Stuxnet" hasta simples fechorías del crimen organizado contra entidades financieras y otras organizaciones, la realidad es que no hemos visto nada. Si de algo están de acuerdos los expertos es que las cosas a partir de este momento solo pueden empeorar.

A pesar estar pensada para militares/personal de gobierno, los civiles también están invitados a participar de esta certificación. La idea es reforzar los lazos de cooperación entre los expertos de una manera definitiva y funcional, sin importar las organizaciones para las que trabajan. A diario conocemos que las empresa privadas son víctimas co-laterales en incidentes más grandes cuyos objetivos finales son atacar la infraestructura de los gobiernos. Este año ha visto casos de los más sofisticados entre los que se cuentan RSA, Lockheed Martin, Booz Allen o hasta el del Fondo Monetario Internacional. Esta tendencia solo puede esperarse que continue en ascenso tanto en sofisticación como en efectividad. En consecuencia, los lazos de cooperación para el intercambio de información entre el sector privado y el gobierno se hacen cada vez más importantes.

El camino hacia la obtención de esta certificación comienza con una carta aplicación dirigida al SANS Institute. La aplicación debe contar con los siguientes requisitos:

1) Por lo menos 5 años de experiencia en el área de seguridad de la información.
2) Evaluaciones sobresalientes por parte de tus comandantes (caso militar) / gerentes supervisores (caso civil)
3) Cartas de recomendación de tus comandantes (caso militar) / gerentes supervisores (caso civil)
4) Conseguir la certificación GSEC (GIAC Security Essentials) con un puntaje mayor a 80 o poseer la certificación CISSP (de ISC2).

Estos requisitos no deberían ser ningún problema para un profesional de mediana trayectoria en el mundo de la seguridad informática. El verdadero reto comienza con el camino de certifaciones centrales y electivas.

La certificación requiere que el candidato cumpla con los siguientes requisitos obligatorios:

1) Obtención de la certificación GCIA (GIAC Certified Intrusion Analyst)
2) Obtención de la certificación GCFA (GIAC Certified Forensic Analyst)
3) Obtención de la certificación GPEN (GIAC Penetration Tester)
4) Obtención de la certificación GCIH (GIAC Certified Intrusion Handler)

Con estas cuatro certificaciones centrales, se espera que el candidato domine una sólida base de conocimientos que le permitan ejecutar al menos las siguientes operaciones:

a) Establecer un perimetro de defensa
b) Administrar el perimetro de defensa
c) Identificar amenazas
d) Análisis de vulnerabilidades e intrusiones.
e) Defensa en profundidad y respuesta ante incidentes.
f) Mitigación de riesgos y planificación de misiones.
g) Análisis de amenazas y contra-inteligencia.

Una vez completados los cursos básicos, el candidato debe seleccionar una especialidad ofensiva (Red Team) o defensiva (Blue Team). En este artículo he decidido comentar la especialidad que yo seleccioné (equipo de ofensiva), sin embargo, se puede leer los requisitos para la otra especialidad en la página oficial.

La especialidad ofensiva requiere que el aspirante complete uno de los siguientes cursos con su respectiva certificación:

1) SEC-542 :: Web App Penetration Testing and Ethical Hacking (6 días) y su certificación GWAPT (GIAC Web Application Pentester).
2) SEC-617 :: Wireless Ethical Hacking, Penetration Testing, and Defense (6 días) y su certificación GAWN (GIAC Assesing Wireless Networks)
3) SEC-660 :: Advanced Penetration Testing, Exploits, and Ethical Hacking (6 días) y un artículo académico

En mi caso, yo completé los dos primeros cursos de especialización cuando los requisitos eran distintos. Ese es el precio que hay que pagar por terminar el programa en menos de la mitad de tiempo estipulado (2 años). Con esta especialidad, se espera que el candidato domine las siguientes capacidades:

a) Explotar vulnerabilidades de capa de aplicaciones.
b) Crear y modificar exploits para penetrar redes.
c) Explotar vulnerabilidades en sistemas operativos Windows y Linux.
d) Exploitar equipos de redes y dispositivos embebidos.

Pero esto no es todo. Por si fuera poco esta cadena de certificaciones y cursos altamente especializados, el candidato debe cumplir con un último requisito:


1) Cumplir con todos los requisitos y conseguir la certificación GSE.


Este requerimiento corona la certificación asegurandose que el candidato posee el conocimiento "hands-on" de todas las certificaciones que ha conseguido aprobar. En un artículo anterior ya había comentado lo que significa convertirse en uno de los pocos GSE que existen en el mundo.

Para el momento de escribir de este artículo, me llena de orgullo poder decir que soy el único y primer Cyber Guardian no sólo de Venezuela si no de toda América Latina. El listado de los muy pocos que han logrado conseguir esta prestigiosa certificación se encuentra aquí.

Como siempre los comentarios / preguntas / solicitud de consejos los puedes hacer aquí.

La puerta bien blindada, pero la ventana bien abierta.

Durante mis evaluaciones de seguridad informática, rutinariamente me encuentro con implementaciones que intentan eliminar con mucho esfuerzo  una determinada vía de ataque sin darse cuenta que al mismo tiempo dejan otras rutas completamente desprotegidas. Este tipo de "errores" es usual cuando la seguridad informática se construye a posteriori en lugar de incluirse desde la más temprana etapa de diseño del sistema. En estas situaciones, muy pocas veces es posible proveer una "solución adecuada" y en consecuencia se termina seleccionando la opción que representa el menor de los posibles males.

Este artículo está dedicado a la "nueva moda" de las tarjetas de crédito / débito con chip que han empezado a implementar muchos de los bancos en Latinoamérica y en particular los Venezolanos. Esta fuerte tendencia parece ser indetenible a pesar de que los verdaderos riesgos, ventajas y desventajas de esta tecnología se desconocen con exactitud. Como siempre el twitt que lo inició todo rezaba algo como sigue:

@EnfoqueSeguro en 107.9 "se buhonerizo la clonacion de tjtas en Vzla, se debe migrar a tecnologia chip". Los medios de pago y sus riegos.

Adicionalmente,  se refuerza el mensaje con artículos como éste y éste. Sin embargo, muy pocas personas parecen apreciar que la implementación actual de muchas de éstas mejor llamadas "tarjetas inteligentes" en realidad dejan mucho que desear. Como es de esperarse, los "chips" no pueden ser la panacea que los medios amarillista de seguridad informática intentan pintar y el verdadero "diablo" se encuentra en los detalles (de implementación). El comentario que resume mi argumento es el que sigue:

Ruben Recabarren - Buzz - Public

Interesante como en Vzla la campaña de la tarjeta de crédito "con chip" se ha vendido como una protección al consumidor, cuando la implementación actual (chip + banda magnetica) brinda únicamente cierta protección extra al banco y cero protección extra al consumidor. "Cosas vederes... Que non crederes".


Tengo que aceptar que la anterior entrada plantea mucha información que además de sorprendente, contiene muchas trampas para los que se aventuran a evaluarla superficialmente. Para explicar en profundad mi afirmación es necesario establecer algunos conceptos básicos sobre el funcionamiento de los sistemas de tarjeta inteligente que desarrollamos a continuación.


Advertencia: La siguiente descripción está basada en mi experiencia y conocimiento genérico sobre los sistemas de tarjetas inteligentes. Esta descripción asume que se tienen al alcance todas las ventajas que ofrecen los sistemas "con chip". Sin embargo, yo realmente dudo que las implementaciones de los bancos desarrollen todas estas características, pues cada una trae consigo sus retos y dificultades. En consecuencia, la implementación del banco puede diferir grandemente de esta descripción y obviamente, no puedo verificarla explicitamente. Por un lado, no tengo permiso explícito de las entidades bancarias pertinentes, pero por el otro tampoco acostumbro hacer tales trabajos de consultoría de forma gratuita (lol). Está demás decir que si algún responsable después de leer esta descipción desea realizar una rigurosa evaluación de su implementación para verificar o para retarme a demostrar las debilidades que aquí describo, puede gustosamente utilizar el link de contacto.


=====  Descripción pseudo-técnica, skiddies cortar desde aquí ======


1.- Protección con un PIN. La primera linea de protección se consigue con el viejo y conocido Personal Identification Number. Un número que se supone sólo conoce el usuario de la tarjeta y permite su "activación" al usarse en un punto de venta (POS). A pesar de ser una técnica vieja, detrás de las cámaras, este PIN funciona de una manera muy distinta al PIN de nuestras tarjetas de banda magnetica. En realidad, este PIN sirve de "autenticación" de nuestra persona hacia la tarjeta. Se supone que si alguien que desconoce el PIN intenta usar nuestro plastico, el chip inteligente se rehusará a negociar cualquier transacción. Esto es posible gracias a que el chip es en realidad un microprocesador con la misma lógica que hemos visto en los cuadros que nos piden un password para ingresar a nuestro email o abrir la sesión en nuestro computador personal.

Realmente no hay justificación para no implementar esta característica por parte del banco. En efecto, cualquiera que haya usado las nuevas tarjetas, no necesita hacer ninguna evaluación ni prueba de penetración para verificar que en realidad este mecanismo es utilizado de forma efectiva. Sería el colmo si no fuera así.  Por otro lado, este mecanismo no está libre de fallas, pero afortunadamente no son distintas a las que estamos ya bien acostumbrados: el usuario comparte su PIN de forma consentida o no-consentida (amenazado, atracado, etc), el PIN es observado por alguien surrepticiamente y un grandisimo, el PIN "robado" al usuario con ingeniería social, y un grandisimo etcétera. Ninguna sorpresa por aquí.


2.- Protección mediante un certificado digital de usuario inmerso y protegido por el chip. Esta es la primera característica novedosa y que tampoco es difícil de implementar. Aunque no hay motivos para pensar que no esté implementada, no es posible verificarlo por las razones mencionadas anteriormente. Sin embargo, no implementarla sería casi imperdonable pues los certificados digitales son el corazón mismo de las características de seguridad de estos sistemas. Un certificado digital es lo que nos permite realizar operaciones virtuales con autenticación de origen, integridad, confidencialidad y no-repudiación. La matemática detrás de todo eso esto es fascinante. Sin embargo, la parte importante para los usuarios normales es que debido a la dificultad de factorizar productos de números primos muy grandes, la posibilidad de falsificar transacciones que afirman provenir del dueño de un certificado digital específico es muy pero muy pequeña. Ésto es lo que permite la "no-repudiación" de la transacción. En otras palabras, si existe una transacción hecha con este certificado digital, pues con altísima probabilidad provino desde un chip que almacenaba este certificado digital (no uno "clonado") y que de paso está enlazado a la identidad del usuario legítimo.


Es aquí también donde empiezan las sorpresas. El famoso chip que se supone nos debe proteger, en efecto lo que hace es asegurarle al banco que una transacción firmada con tal certificado realmente vino de mi tarjeta y tiene muy poca probabilidad de haber sido falsificada. Fantástico para el banco, pues ahora puede diferenciar con mayor certeza las transacciones verdaderas (y que debe rechazarte si intentas desconocerlas) de las transacciones posiblemente fraudulentas (y que no le queda mas remedio que deshacer la transacción). ¿Dónde está la protección verdadera para el usuario? La protección viene siempre y cuando nadie pueda extraer esa información del certificado digital. Si alguien puede extraer la denominada "clave privada" del certificado digital de mi tarjeta inteligente, lograría en efecto la "clonación" de la tarjeta con chip. En consecuencia, yo, como usuario, quedaría en exactamente los mismos problemas que antes. Justamente para evitar esta posibilidad, se diseñó el mecanismo de seguridad que describimos a continuación pero que lastimosamente es el menos implementado en la vida real.


3.- Protección mediante un par de certificados digitales extra que identifican a la tarjeta inteligente y al punto de venta legítimo. Este mecanismo básicamente intenta evitar que las tarjetas "con chip" sean coaccionadas a revelar la información de autenticación, descrita en el punto anterior, a un punto de venta diseñado maliciosamente para este fín. La información de autenticación consiste esencialmente en la clave privada, aunque también se intenta evitar "ataques de repetición". El mecanismo de ataque específico es mucho mas complicado de lo que puedo intentar explicar en términos sencillos. Sin embargo, la idea es facil de intuir. Si construyo un punto de venta que manipule maliciosamente a mi chip, bajo ciertas condiciones, podría lograr que revele la información necesaria para clonarlo. Sin embargo, la misma tecnología de certificados digitales que sirve para "identificar" al usuario, sirve a escala más pequeña para autenticar al punto de venta frente a mi chip y al chip frente al punto de venta. Esta modalidad es lo que se conoce como "autenticación mutua". Si alguna de las partes (chip o POS) no reconoce a la otra, simplemente se niegan a conversar y las transacciones no se llevan a cabo. Cuando este mecanismo es implementado adcuadamente, el proceso para que un delincuente logre crear un punto de venta malicioso se vuelve comparable a la dificultad de factorizar productos de números primos muy grandes. Es decir, bien díficil dependiendo del tamaño de los números primos usados. En consecuencia, y sólo en este caso, la información privada del usuario está protegida con efectividad.


Es aquí donde comienzan los peores problemas. Para implementar este mecanismo de forma adecuada, y mantener algún tipo de compatibilidad de cobranza mutua, es necesario establecer un mecanismo para que los chips del banco "A" reconozcan los puntos de venta del banco "B" como de confianza. De lo contrario, los chips del banco A no podrían saber si los puntos de venta del banco B son legítimos o se trata de un delincuente informático tratando de clonar nuestra tarjeta de crédito o débito. Este mecanismo de confianza se puede establecer de muchas maneras, la más sencilla de las cuales es la creación de una autoridad de certificación raíz común. Lamentablemente, la sencillez de esta solución es sólo técnica pues las dificultades empiezan a ser operativas por peleas de poder o prestigio: ¿Qué banco controla la autoridad raíz? Por otro lado, es posible hacer una solución de mayor aceptación comunitaria pero de mayor dificultad técnica: lo que se conoce como autoridades de certificación cruzada. Aún hay otras soluciones salomónicas al estilo de confiarle al proveedor de puntos de venta y tarjetas inteligentes la operación de la autoridad raíz lo cual entrega las llaves del reino a un completo extraño. Esto último acarrea aún más y más problemas de confianza. Adicionalmente, éste último mecanismo de protección es otro que no podemos verificar sin hacer un análisis más profundo o sin permiso explícito. Sin embargo, es evidente que la problemática descrita anteriormente es la candidata perfecta para acortar caminos. El acortar caminos significa, por ejemplo, no utilizar este mecanismo de protección y en consecuencia proveer menos protección efectiva para el consumidor.


=== Fin descripción pseudo-técnica, script kiddies cortar hasta aquí ====


Espero no haber perdido a demasiados lectores con la montaña rusa sobre el funcionamiento de las tarjetas inteligentes. Lo que viene les conviene. Armados con el conocimiento adquirido es posible entender la primera parte de mi afirmación inicial: "...brinda únicamente cierta protección extra al banco..." En efecto, cuando una transacción es realizada a través del chip, el banco tiene todos los argumentos anteriores para sostener que el cliente y no un delincuente informático es responsable de la realización de esa transacción. Es decir, los reclamos a partir de aquí se hacen menos creibles, sobre todo porque los consumidores, primero: no conocen a profundidad las debilidades que sondeamos muy superficialmente en las lineas anteriores; y segundo: no tenemos ninguna forma de verificar que la implementación haya sido hecha correctamente y evaluada por un ente independiente. En mi opinión aquí están fallando mucho los organismos reguladores al permitir que los bancos hagan y deshagan con sus implementaciones sin una verdadera evaluación rigurosa y de calidad. Para muestra, dos botones aunque admitidamente, hay muchos más.

Mis detractores apuntarán rápidamente la siguiente aparente parcialidad: "...todo esto es asumiendo que los bancos hicieron mal su tarea ¿Acaso no es posible que la hayan hecho bien? ..." Ciertamente, mi argumento inicial también aloja esta posibilidad. Por supuesto, la aloja tan sólo por completitud, pues por motivos y evidencia de primera mano, tengo razones para pensar que ésta dificilmente será la excepción. La segunda parte de mi argumento cobra razón justamente asumiendo el supuesto increible y por demás improbable que la implementación de los bancos es perfecta y que los chips son en verdad " difícil de violentar". El punto en donde se cae toda posible protección para el consumidor es en la triste realidad que hasta ahora todas las tarjetas con chip tienen también, por motivos de compatibilidad, la antigua banda magnetica con la que nos han estado clonando ad nauseam. En efecto, para ejecutar una transacción fraudulenta, el delincuente tendría que ser sumamente estúpido para tratar de entrar por la puerta hipotéticamente "bien cerrada" y blindada (chip) teniendo la ventana (banda magnética) abierta de par en par. Es decir, en la práctica, el delincuente seguirá usando la banda magnetica para clonar tu tarjeta y se reirá afanosamente de tu chip "inteligente".


Dicho en criollo, el riesgo para el consumidor es exactamente el mismo: el delincuente intentará llevar la tarjeta a un lugar fuera de los ojos del propietario y pasar la banda magnetica (no el chip) por la captadora. Al final, ¿A cuantas personas les han intentado clonar su tarjeta delante de sus narices? Ésto usualmente se lleva a cabo en la "oscuridad" y lejos de los ojos supervisores del propietario. En consecuencia, ¿Cuánto te protege realmente que le pidas al cajero que use el chip y no la banda? De todas maneras delante de tus ojos no te la iban a "raspar delincuencialmente". Y si rasparla delante de tus ojos iba a tener éxito, que te la pasen por el chip y luego por la captadora, usando cualquier excusa tonta, tendrá exactamente la misma probabilidad de éxito. Las oportunidades del delincuente siguen intactas. La única diferencia es que ahora, para las transacciones que hagas con tu chip: buena suerte al intentar reclamarlas al banco. Nuestra única esperanza es que la banda magnética desaparezca pronto.

Ahora bien, para los que aspiran que la banda magnética desaparezca en el corto plazo, más malas noticias. Como habíamos explicado anteriormente, la banda magnética es necesaria para los puntos de venta que no cuentan con el lector de tarjetas inteligente moderno. Eliminar la banda magnética implicaría reemplazar todos los puntos de venta del mundo (o al menos del país) por sus contrapartes modernos con lectoras de "chip". De lo contrario, el banco que emita plásticos sin banda magnética quedaría imposibilitado de realizar transacciones en lugares donde todavía no ha llegado la modernización. Dícese, por ejemplo, la tagüarita del Bronx donde compramos la harina pan para deleitar a nuestros anfitriones en el extranjero con un pláto de comida típica Venezolana. Ésto se traduciría, como es de esperarse, en pérdida de transacciones, descontento de clientes, etc. En consecuencia, al menos para el caso de las tarjetas de crédito, es posible que esta implementación (chip + banda) permanezca mucho mas tiempo del que muchos imaginan. En el caso de las tarjetas de débito, su transición total debería ser un poco mas rápida, al menos en Venezuela, pues no existe posibilidad de usarlas en el extranjero debido al control cambiario. Mientras tanto, se puede esperar que el número de transacciones fradulentas siga con la misma tendencia actual, prácticamente sin ningún tipo de impacto verdadero. Lo que muy dificilmente permanecera invariable es el número de reclamos no procedentes que empezará a emitir la entidad bancaria en clara sobre-confianza de su nuevo "sistema de chip con casi nula probabilidad de falsificación". Me pregunto: ¿Cuántas personas han intentado con éxito que les reversen una transacción hecha a través del chip inteligente? Buena suerte con eso y me encantaría si dejaran sus comentarios / experiencias al respecto al final de este artículo.

Supongo que siempre existe la posibilidad de cuando el banco se rehúse a aceptar un reclamo por cobro indebido, puedes intentar apuntarlos a este artículo (lol). Si aún así no te creen pues puedes también apuntarlos a otros como este (doble lol). Finalmente, y en cualquier caso, les deseo mucha pero mucha buena suerte. Al final, ésa parece ser la única verdadera protección que tenemos (not lol). :-(