domingo, 30 de enero de 2011

Amenaza Inminente. Parte II.

En el artículo anterior de la serie Amenaza Inminente, obtuvimos muy fácilmente una lista de direcciones IP que nos atacaban inclementemente. Un paso casi inmediato en cualquier respuesta a incidentes de este tipo es tratar de ubicar la localización geográfica de nuestro atacante(s). Para lograr esto con verdadera precisión se requiere correlacionar información de diversas fuentes. Sin embargo, una primera fuente de información es justamente de la dirección IP que comete el ataque.

Existen gran cantidad de scripts que pueden convertir una dirección IP en coordenadas del globo terraqueo. Esta transformación se hace a partir de la información de registro del manejador del bloque de IPs a que correponde la dirección transgresora. Por lo tanto, no siempre se encuentrá actualizada o completa pero no deja de ser un buen punto de partida de todas maneras. A pesar de su gran disponibilidad, muchos de estos programas caen rapidamente en desactualización debido a los cambios constantes que hacen los proveedores de la información de localización para alcanzar mayor eficiencia en su servicio. Lejos de reinventar la rueda, tomamos un script público y lo arreglamos para que funcione con la tecnología actual.

$ ./ips2kml.rb hostile.unique.ips

Nuestro script toma como entrada un archivo con una lista de direcciones IP, y retorna un archivo de extensión kml, con el mismo nombre, para ser usado con los servicios de google-earth. Con este archivo es posible generar todo tipo de gráficas que permiten visualizar la "superficie de la amenaza".



Adicionalmente, se puede extraer facilmente las 10 localidades con mayor actividad hostíl, por ejemplo:

$ grep description hostile.unique.ips.kml | cut -d ">" -f 2 | cut -d "<" -f 1 | sort | uniq -c | sort -gr | head

   1874 Caracas, Distrito Federal, VE
    174 Cúcuta, Norte de Santander, CO
    102 Taipei, T'ai-pei, TW
    102 , , RU
     52 Moscow, Moscow City, RU
     43 Bogotá, Cundinamarca, CO
     33 Buenos Aires, Distrito Federal, AR
     30 São Paulo, Sao Paulo, BR
     27 Seoul, Seoul-t'ukpyolsi, KR
     22 Bucharest, Bucuresti, RO

Como es de esperarse de un ataque planificado, la mayor cantidad de infractores son de la localidad de Venezuela, en donde se recoletó esta información. En un ataque oportunista al azar, no esperamos ver esta distribución tan correlacionada. La idea de nuestros atacantes es usar las computadoras mas "cercanas" en terminos de latencia, para seguir vulnerando más y más equipos. El costo de llevar a cabo este ataque desde una localidad remota simplemente no es aceptable. Por esta razón los creadores de virus/gusanos/malware introducen algoritmos que hacen preferir las direcciones IPs de la misma subred antes de las direcciones más "remotas".

Con esta metodología es posible conseguir aún más estadísticas útiles para tomar decisiones sobre cómo reaccionar ante el incidente. La mayoría de veces estas decisiones giran alrededor de detener la amenaza y continuar con la operación normal. Sin embargo, algo que muchas veces no se puede dar el lujo la organización bajo ataque es investigar más profundamente la amenaza. Los objetivos de esta investigación pueden estar dirigidos a averiguar los métodos, intenciones u objetivos y finalmente hasta el responsable o responsables del ataque. Desarrollar un pequeño laboratorio virtual para abordar estos ambiociosos objetivos será el tema de proximos artículos.

viernes, 28 de enero de 2011

Inseguridad Bancaria Online. Parte II.

En artículos anteriores hemos elaborado superficialmente sobre lo devastador que puede ser la vulnerabilidad de nombres de usuario predecibles. Especificamente señalamos que el alcance del objetivo de nuestro atacante se hace significativamente más sencillo cuando tiene disponible esta vulnerabilidad. Los objetivos pueden ser tan variados como ejecutar un ataque de denegacion de servicios total y muy dificil de detener, o simplemente obtener un par de credenciales que le permitan penetrar mas profundamente en el sistema de la entidad financiera.


Sin embargo, no sólo cuando el sistema obliga al usuario a usar nombres predecibles estamos a merced de nuestro atacante. Algunos sistemas de banca en linea, a pesar de reconocer la importancia de utilizar nombres de usuario arbitrarios, fallan en darse cuenta que también los mensajes de error pueden dejar completamente inefectivo su mecanismo anti-adivinacion de usernames.


Lo único que el atacante requiere para aprovechar esta vulnerabilidad, es que el sistema provea distintos mensajes de error cuando se introduce un usuario válido o inválido. Esta vulnerabilidad es fácil de detectar cuando los mensajes de error anuncian explícitamente que el nombre de usuario es inválido. La razón de este fallo es hasta entendible en cierta manera. Los sistemas de banca en linea tratan de ser lo más amigables posible dando al usuario legítimo la mayor cantidad de información para corregir su error. Esta conveniencia no viene sin su gran costo de riesgo para el sistema de forma global, pues se le otorga la misma información al atacante.

La naturaleza de esta vulnerabilidad es muchas veces tan sútil, que no es necesario que el sistema revele a nuestro atacante explícitamente que el nombre de usuario intentado es inválido. Muchas veces, nuestro atacante puede inferir esta información por la lógica de funcionamiento de la aplicación. Por ejemplo, supongamos que nuestro atacante comienza su ataque de adivinación de nombres de usuario y se encuentra con un sistema como el de la gráfica de la derecha. El mensaje de error del sistema es explícitamente ambiguo con la intención de imposibilitar el ataque.


Sin embargo, si el atacante ingresa un nombre de usuario válido, y cualquier contraseña (muy probablemente incorrecta), el mensaje de error que arroja el sistema es el que se ve en la gráfica de la izquierda. Ahora, por más truco Jedi que intente el sistema, nuestro atacante casi nunca es tan tonto. A pesar de que el error anterior asegure que el nombre de usuario o la contraseña pueda ser el incorrecto, nuestro atacante sabrá que el anterior error sólo se produce cuando se introduce un nombre de usuario incorrecto.

El tema es tan poco entendido entre los desarrolladores, que aún cuando evitan los casos anteriores con mucho trabajo, fallan al dejar distintos códigos de error dentro del código fuente de la página que no son renderizados por el navegador, por ejemplo. A pesar de que estas diferencias no son evidentes para el ojo no entrenado, el atacante avanzado, analizará sin descanso las respuesta de nuestros servidores en busca de estas diferencias casi imperceptibles. Una vez que nuestro atacante encuentre una diferencia confiable - podría ser incluso un distinto tiempo de respuesta del servidor web - entonces empleará todo su arsenal para llevar a cabo sus objetivos.

Por esta y muchas otras razones es tan importante llevar a cabo pruebas de penetración avanzadas que detecten este tipo de errores "no evidentes" antes que nuestros atacantes los encuentren y exploten con éxito.

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

martes, 25 de enero de 2011

La contraseña mas fuerte de todas

Las preguntas rompe hielo siempre me han fascinado. La primera conversación con una persona puede decirnos mucho sobre su carácter. Sin embargo, cuando mis nuevos conocidos se enteran que estoy en el mundo de la seguridad informatica, cualquier cosa puede suceder. Mi pregunta favorita y que he aprendido a esperar casi obligatoriamente en algun momento es: ¿Cómo debo seleccionar mi password para hacerlo irrompible? Adicional a la pregunta recibo una receta complicadísima de mayusculas, minusculas, dígitos, signos de puntuacion, caracteres no imprimibles, etc. a la que debo dar una opinion sobre su fortaleza. A veces pienso que la receta está hecha más para impresionarme con la pregunta rompe hielo que para realmente usarlas; pues me es dificil imaginar un ser humano memorizando algunas de las contraseñas resultantes.

Mi respuesta es tan simple como inesperada. No es muy buen rompe hielo, pero es lo más cercana a lo que he podido entender en este tema: "el password más fuerte de todos es el que no se lo dices a nadie". La cara de confusión no se hace esperar. Luego trato de explicar que en lugar de aplicar la receta complicadisima, se aplique mi simple dogma de no revelar su contraseña a nadie y su password será lo mas fuerte que se puede ser. La confusión se transforma en desilusión y a veces hasta frustración. Este artículo intenta suavizar un poco esas malas impresiones creadas.

Para explicar este tema necesito un poco de matemática sencilla. La matemática debe ser aún peor rompe hielo por eso nunca he intentado hacer esta explicacion en vivo. La primera definición necesaria es cuantificar de alguna forma la fortaleza de un password. Supongamos una contraseña de 8 caracteres. Estos pueden ser letras mayusculas, minusculas, dígitos y signos de puntuación. Para usar una cifra redonda, imaginemos que en total tenemos 100 caracteres para seleccionar cada uno de los caracteres de nuestro password. Para saber cuantos passwords posibles puedo crear con esta estrategia simplemente multiplico las posibilidades de cada uno de los caracteres el número de veces que sea la longitud del password:

Receta #0: Password de 8 caracteres. Sin restricciones especiales.
Fortaleza #0: 100 x 100 x 100 x ... x 100 (ocho veces) = 10^16

El resultado de esta fórmula es el número de intentos que tendría que hacer un atancante para adivinar mi password. Mientras más grande es este número, mas difícil es para mi atacante adivinar mi contraseña. Por lo tanto, este número es una buena medida de la fortaleza de mi password. Nótese que aquí no he utilizado ninguna receta, solo un password de 8 caracteres. Ahora vamos a intentar "fortalecer" mi contraseña con alguna de esas recetas impresionantes. Veamos la fortaleza una receta sencilla:

Receta #1: Asegurar que el password tenga al menos una letra en mayuscula y un numero.
Como las letras mayusculas son sólo a lo sumo 30, y los dígitos son sólo 10, para estimar la fortaleza de esta estrategia, debo cambiar un 100 por 30 y otro 100 por 10 en el producto de la receta anterior (ver nota1). El resultado es:

Fortaleza #1: 30 x 10 x 100 x 100 x ... x 100 (6 veces 100) ~ 10^14

Lo cual es considerablemente mas débil que la estrategia "sin receta". Si este resultado parece increible, calculemos la fortaleza de una receta más complicada.

Receta #2: Asegurar que el password tenga al menos dos mayusculas, al menos dos dígitos y un símbolo especial (!"@#$%...).
Asumiendo que los símbolos especiales son a lo sumo 30 (siendo generosos), la fortaleza nos queda en  (ver nota1):

Fortaleza #2: 30 x 30 x 30 x 10 x 10 x 100 x 100 x 100 ~ 10 ^12

Lo cual de nuevo es menor que la estrategia anterior pero todavía muchísimo menor que la estrategia nula.

¿Que es lo que está pasando?

La explicación es sencilla si recordamos el dogma del principio. Si bien es cierto que al soltar una receta complicadísima no estamos "diciendole el password a nadie", sí se está dando cierta información. Específicamente, se está diciendo que uno de los caracteres de mi password no es cualquier cosa. Por el contrario, uno de ellos es necesariamente una mayuscula, y otro de ellos es necesariamente un dígito, por ejemplo. Mientras más restricciones públicas le ponemos a la contraseña, mas información le otorgamos a nuestro posible atacante. Esta debilidad es muy bien reflejada por la estimación que calculamos utilizando nuestra formula.

¿Quiere decir que puedo poner como password a mi cuenta bancaria "beisbol1" en lugar de "1*e/hIOn"?

Definitivamente no. El problema es que "beisbol1" ya lo sabe nuestro atacante debido a que es una derivación sencilla de una palabra de diccionario, mientras que un password completamente aleatorio no. Por lo tanto, "beisbol1" no cumple nuestro dogma, mientras que "1*e/hIOn" antes de escribirlo por primera vez en este blog si lo cumplía.

Pero, ¿Cómo nos aseguramos que el password que seleccionamos no se lo ha dicho nadie a nuestro atacante? Este tema sí es un poco más complicado, pues tiene que ver con la psiquis humana. El mejor consejo que puedo dar a este respecto es tratar de pensar de la forma en que nadie mas lo ha hecho. Esta es la única manera de fabricar el password mas fuerte de todos. Para mantenerlo fuerte, no hay que ni decirlo a nadie ni tampoco cómo derivarlo.

A pesar que este último punto suene de nuevo demasiado simplista, nuestros atacantes están constantemente capturando passwords para saber cómo pensamos. Armados con este entendimiento de la psiquis humana colectiva, se perfeccionan estrategias para tratar de adivinarlos. Es por eso que la proxima vez que alguien nos llegue con la receta mágica para hacer el mejor password, ya sabremos que esa persona acaba de dañarla al no mantenerla secreta. En consecuencia, hay que mantenerse alejada de ella; no de la persona, de la estrategia.

Como nota anecdótica, algunas amigas celosas siempre tratan de persuadirme para que les diga mis contraseñas. De esta forma, esperan poder saber quien me escribe sms, email, IMs, etc. En una ocasión me dejé persuadir para revelar el pin de mi chip GSM - Sí, mis amigas pueden ser muy persuasivas - La cara de asombro de una de ellas al verme tipear "0000" en mi celular fue poética. La conversación concluyó mas o menos así:

- Pero que clave más mala. 
- Si, pero no puedo hacer nada, no puedo mas que poner 4 digitos.
- Si, pero es que es puros 0s.
- Ehm, si, como cualquier otro número de 4 digitos, es igual de malo.
- Ah, pero es que es muy facil de adivinar!! (frustración)
- Claro, pero sólo porque ya te la he dicho. Te apuesto que antes de decirtela jamas hubieras pensado en que esa era mi clave, mucho menos conociendome como el supuesto "experto en seguridad informatica".
 - (Cara de gracia pero insatisfacción).

Aunque en mi anécdota juega un poco el tema de "contra-inteligencia", pienso que encierra perfectamente la esencia de este artículo. Una vez revelado, el password o cualquier información sobre éste, es igual de malo que el anterior.

---------

Nota1: En realidad el cálculo preciso involucra factores adicionales que tienen que ver con las posiciones de los caracteres de la receta. Por ejemplo, para la primera receta, existen 8 posiciones para colocar la mayuscula y despues 7 posiciones para colocar el dígito. Esto se expresa en números combinatorios como "8 choose 1" y "7 choose 1". El resultado final debe multiplicarse por 56. En la segunda receta es necesario multiplicar por "8 choose 3" y "5 choose 2", y si mi cálculo mental no falla, esto es igual a 560.

domingo, 23 de enero de 2011

Adivinando Nombres de Usuario

Muchos seguramente hemos visto la pelicula: el criminal informático intenta con mucha paciencia millones de combinaciones tratando de adivinar la contraseña de nuestra cuenta de correo/banca en linea/Manejador de Contenido/etc. A, B, C, ... , AA, AB, AC, ... SEU, SEV, SEW, ... Por supuesto, esto puede tomar muchísimo tiempo. Para acelerar el proceso, el criminal informático puede intentar contraseñas de una forma más inteligente, con palabras de diccionario, fechas de cumpleaños, etc. Aún así, esta técnica requiere una buena dosis de suerte y paciencia para ser exitosa.

Sin embargo, el criminal informático siempre encuentra nuevas vías de ataque, incluso en los detalles menos sospechados. De hecho, en muchos casos, el criminal no necesita intentar adivinar nuestra contraseña sino mas bien nuestro nombre de usuario/login/nombre de miembro/etc. Yo me atrevería a decir que esta técnica es incluso más efectiva que la anterior. La razón es simple. Si me pidieran encontrar en un grupo de personas alguien que tenga la misma fecha de cumpleaños que yo, no sería algo facil. Sin embargo, si me piden que encuentre cualquier par de personas con el mismo cumpleaños, mis posibilidades de exito aumentan grandemente. Este resultado sorprendente y contraintuitivo se conoce como la paradoja del cumpleaños.

Exactamente el mismo principio se encuentra detrás de la técnica de adivinar nombres de usuario. En lugar de intentar adivinar la contraseña de un usuario específico, el criminal selecciona cualquier password "frecuente", e intenta todos los posibles nombres de usuario del sistema. Supongamos que en el sistema hay registrados 1 millon de usuarios, ¿cuantos usuarios habrán seleccionado como password la fecha de nacimiento de su hijo 4885? por ejemplo. ¿Que tal si intentamos todos los días del mes más popular de un año? En una poblacion de 1 millon de personas, muy probablemente muchas compartan el cumpleaños. Las posibilidades de éxito del atacante usando un password que se considera debil (fecha de cumpleaños) aumentan considerablemente.

Sólo queda un pequeño detalle por especificar. ¿De dónde saca el atacante los nombres de usuario? Esta tarea puede ser casi tan difícil como adivinar las contraseñas de la técnica de la escuela vieja. Sin embargo, nuestro atacante corre con muchisima suerte en aquellos sistemas que usan nombres de usuarios predecibles. Este tipo de sistemas son lamenteblamente demasiado frecuentes en sistemas de banca en linea como explicamos en nuestro articulo "Inseguridad Bancaria Online, parte I". Si adicionalmente la contraseña es de sólo 4 dígitos, la tentación para el usuario de utilizar su fecha de cumpleaños es demasiado grande, y el atacante obtiene aún más información para seleccionar sus contraseñas fijas. En consecuencia, las posibilidades de conseguir al menos un par de credenciales correctas se incrementan de manera muy considerable.

Pero, ¿Qué puede hacer un criminal informático con tan sólo un par de credenciales de acceso a la banca en linea? La respuesta a esta pregunta será el tema de proximos articulos.

miércoles, 19 de enero de 2011

Inseguridad Bancaria Online. Parte I.

Usualmente recibimos propaganda de nuestras entidades financieras acerca del cuidado que se debe tener de nuestra contraseña para acceder a los portales de banca online. Sin embargo, muy pocas veces se nos advierte que el nombre de usuario/login/etc es tan importante o tal vez más que el tan celosamente guardado "password".

La razón es simple: sin la contraseña, nuestro criminal informático puede no tener acceso a realizar operaciones bancarias en linea a nuestro nombre; sin embargo, con el nombre de usuario, el atacante puede lograr que nosotros tampoco las hagamos.


El problema radica en que ningún sistema bancario en linea puede darse el lujo de permitir infinitos intentos de acceso a una cuenta bancaria. De lo contrario, expondrian a sus clientes a ataques de fuerza bruta para adivinar su contraseña. Por lo tanto, absolutamente todos los sistema de banca en linea que he visto ejecutan algún tipo de bloqueo despues de un numero predeterminado de intentos de accesos incorrectos. En consecuencia, el atacante que conozca nuestro nombre de usuario, solo necesita hacer unos cuantos intentos de ingreso incorrectos para bloquearnos el acceso a nuestra cuenta de banca en linea.

La situación empeora cuando el propio sistema de banca en linea hace que los nombres de usuario sean facilmente predecibles. Esto sucede muy a menudo cuando las entidades financieras deciden utilizar numeros de cuentas de bancos, numeros de tarjetas de debito, etc en lugar de un nombre de usuario arbitrario. La razón es simplemente comodidad a la hora de hacer el rollout de credenciales. Por ejemplo, si el usuario ya tiene su tarjeta de débito y su clave de cajero, puede usar esas mismas credenciales para acceder al sistema de banca en linea. El usuario está automáticamente listo para hacer uso de la fabulosa banca en linea sin necesidad de emitir nuevas credenciales, verificación de identidad, firma de acuerdos, etc. Ésta comodidad no viene sin su alto costo en riesgo no sólo para el usuario final, sino también para la propia entidad financiera.

El resultado inmediato, pero no el único, es una vulnerabilidad de denegacion de servicio al sistema de banca en linea que no requiere más que de un ordenador personal, una conexión a internet de muy poco ancho de banda, y un programa de una docena de lineas de código para llevarse a cabo. Las entidades financieras invierten grandes sumas de dinero en sistemas redundantes, ancho de banda, sistemas de deteccion de inundaciones, etc. pero con esta vulnerabilidad hacen que todos estos sistemas queden completamente inútiles.

Diversas culturas tienen distintas imágenes sobre el futuro apocalíptico. La imagen que a mi se me viene a la mente con este tipo de sistemas es una entidad bancaria colapsada con tickets de soporte de reseteo de credenciales de acceso y una cantidad muy grande de clientes frustrados por no poder llevar a cabo sus transacciones financieras online. A pesar de nunca haber escuchado a alguna entidad financiera aceptar que ha tenido sucesos de esta índole, yo mismo he sido victima de reiterados bloqueos de acceso inexplicables. Estoy seguro que no soy el único tampoco.

La solución definitiva a esta problemática es por supuesto el uso de nombres de usuario que sean dificiles de predecir. Sin embargo, es posible disminuir el impacto de esta vulnerabilidad sustituyendo los bloqueos permanentes por bloqueos temporales. La intención es por supuesto evitar el escenario apocaliptico dando acceso a las victimas despues de un tiempo prudencial, pero previniendo en cierta medida que el criminal informático lleve a cabo un ataque de fuerza bruta contra las credenciales de sus victimas. Esta medida paliativa, por supuesto, se hace imposible de implementar si el espacio de contraseñas es muy pequeño. Por ejemplo, en el caso en que la clave de acceso sea una cadena de 4 digitos.

Otras consecuencias del uso de nombres de usuario predecibles será el tema de próximos artículos.

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