Feeds:
Entradas
Comentarios

Posts Tagged ‘Criptografía’

Supongo que a estas alturas conoceréis BEAST, y cuáles son sus riesgos.

A continuación, una demo que muestra cómo aprovechar BEAST para comprometer una cuenta de PayPal.

Read Full Post »

La PS3, durante un tiempo bastión inexpugnable, empieza a ver cómo crecen las grietas en sus sistemas de seguridad.

A la publicación de métodos para ejecutar custom firmwares, cargar backups de juegos, y el archiconocido caso PSNgate, se le suma ahora un nuevo episodio: han logrado crackear la seguridad de los juegos de PSN.

Parece que el grupo “Duplex” ha logrado descifrar y crackear los juegos descargables a través de la PSN, que pueden ejecutarse con un CFW 3.55. Aún está por ver qué método han utilizado para lograrlo…

Read Full Post »

La mejor contraseña es aquella más larga

Este mito, sorprendentemente extendido, no es completamente falso, sino que se trata de una verdad a medias. Por supuesto, conviene dejar claro desde un principio que “mejor“, para el contexto que nos ocupa, quiere decir “más segura“; pues podríamos definir otras métricas para establecer la calidad: más fácil de recordar, más graciosa

Por supuesto, es obvio que la mejor contraseña, desde el punto de vista de la seguridad, es aquella que resulta más complicada de romper, violar, obtener de forma fraudulenta, etc. Lo cual nos lleva a otra cuestión: ¿cómo se rompen las contraseñas?

Como caso general, podemos decir que mediante los denominados ataques de fuerza bruta. Cuando éstos se realizan sobre el conjunto de todas las posibles contraseñas, se denominan simplemente ataques de fuerza bruta. Cuando, por contra, se realizan sobre un conjunto definido de pruebas, se denominan ataques mediante diccionario. Así, podemos decir que un ataque mediante diccionario es un caso particular de un ataque de fuerza bruta. A su vez, existen casos particulares de ataques mediante diccionario, cuando la generación del diccionario de ataque se lleva a cabo mediante técnicas concretas, como los generadores de Markov, o la utilización de máscaras o expresiones regulares de generación.

También existen otros casos particulares de los ataques de fuerza bruta, pero diferentes de los ataques mediante diccionario. Un ejemplo sería la utilización de tablas hash precalculadas, como por ejemplo las famosas tablas Rainbow.

Sea como fuere, al final, el ataque suele consistir en probar todas las posibilidades de un conjunto dado, que normalmente es generado mediante algún algoritmo. Además, el ataque puede ir dirigido contra un servicio de autenticación (como comenté hace poco), o contra el almacén de contraseñas, entre otros. El ataque a servicios de red suele conllevar ciertas circunstancias no deseables: es más lento, es muy ruidoso (y, por tanto, fácilmente detectable), y deja muchas huellas. Por otra parte, atacar al almacén de contraseñas (en el caso de que éste sea ininteligible, que debería serlo) requiere el cálculo constante de valores hash para las pruebas.

En cualquier caso, podemos definir dos características que hacen a una contraseña fuerte.

En primer lugar, la contraseña debe ser “no obvia“; esto es, que no pueda encontrarse en un diccionario. Esto incluye diccionarios genéricos, así como diccionarios que pudieran generarse ad-hoc para un determinado caso (por ejemplo, palabras significativas para un determinado individuo, encontradas en los documentos de su disco duro, etc.). Siendo más formales, la contraseña debe contener la mínima información (máxima entropía) posible, o lo que es lo mismo, ser aleatoria (o al menos parecerlo). Esto dificulta también el uso de ataques con generadores de Markov, al no existir un modelo de Markov subyacente en la información aleatoria.

En segundo lugar, la contraseña debe ser “compleja“; esto es, que sea larga (aquí se encuentra la verdad parcial de nuestro mito) y que su alfabeto de generación sea lo más amplio posible. El número de posibles combinaciones de contraseñas, para una longitud y un alfabeto dados, se puede expresar como A^L, siendo A el número de elementos del alfabeto y L la longitud. Así, y para una misma longitud, tenemos que cuanto mayor sea el alfabeto, más combinaciones existirán, y por tanto más compleja será la contraseña.

Es más, se da la circunstancia de que, en ocasiones, un alfabeto más amplio y una longitud menor generan un mayor número de combinaciones. Por ejemplo, las posibles contraseñas en mayúsculas y minúsculas de 5 caracteres son 52^5; mientras que las posibles contraseñas numéricas de 8 caracteres son 10^8. Dado que 52^5 es aproximadamente 380 millones, mientras que 10^8 es exactamente 100 millones, vemos que una contraseña de 5 caracteres con mayúsculas y minúsculas es aproximadamente cuatro veces más compleja que una de 8 caracteres numéricos.

Resumiendo, la seguridad de una contraseña depende principalmente de tres factores:

  • La entropía de la misma, que debería ser máxima. Idealmente, generada de forma aleatoria.
  • La complejidad de la misma, que a su vez depende de…
    • La longitud de la misma, que debería ser lo mayor posible.
    • El alfabeto de generación de la misma, que debería ser lo más complejo posible.

Por supuesto, esto se refiere exclusivamente a las contraseñas en sí mismas. En la seguridad de cualquier sistema intervienen muchos otros elementos potencialmente atacables: claves de cifrado, vulnerabilidades, ingeniería social… así que tampoco conviene confiar ciegamente en una buena contraseña.

Como siempre, espero que os haya resultado interesante.

Read Full Post »

Los computadores cuánticos pueden romper la criptografía moderna

Esta atrevida afirmación, que en alguna ocasión he podido leer y escuchar, está basada muy probablemente en la existencia de ciertos algoritmos como el de Shor.

Poniendo ejemplos concretos, y ya que sale de titular el algoritmo de Shor, hay que hablar de RSA. Este criptosistema de clave pública, presentado en 1977, basa su seguridad en el conocido como “problema de factorización de números enteros“; esto es, la dificultad asociada a la descomposición de un número compuesto en divisores no triviales. Así, existen muchos algoritmos de factorización utilizados habitualmente, si bien todos ellos tienen una complejidad exponencial; lo cual implica que un leve aumento en el tamaño del problema conlleva un aumento muy grande en el tiempo necesario para resolverlo.

En resumen, la seguridad de RSA radica en que resulta sencillo generar claves y operar con ellas en la forma que define el algoritmo (operaciones como multiplicaciones, exponenciaciones, congruencia modular, etc.), pero resulta computacionalmente muy complejo intentar obtener el factor privado de la clave a partir del público y de mensajes del criptosistema (operación de factorización). Si se consiguiera un algoritmo de factorización con una complejidad razonable (por ejemplo, polinómica), un ataque a la criptografía RSA sería mucho más simple.

Y aquí entra en juego el algoritmo de Shor, anunciado en 1995 por Peter Shor. Este algoritmo resuelve el problema de factorización con un coste temporal logarítmico O((log N)3), aunque tiene la pequeña pega de necesitar de un computador cuántico para la ejecución de parte del mismo. Aún cuando hoy en día no existen (o al menos, no se conoce su existencia) computadores cuánticos completos y funcionales, esta tecnología avanza constantemente. De hecho, la gente de IBM demostró en 2001 la corrección del algoritmo de Shor.

Vale, sabemos que el algoritmo de Shor permite factorizar en tiempo logarítmico, sabemos que se ha demostrado su funcionamiento, y que los computadores cuánticos terminarán llegando tarde o temprano. ¿Significa esto la ruptura automática de la criptografía de PKI, y más concretamente en este caso de RSA? Pues no. El hecho de que el algoritmo de Shor permita factorizar números de una forma más eficiente significa exactamente eso: lo hará más rápido. Pero no será instantáneo.

Así, y para el caso de RSA (parece que hay algoritmos equivalentes para DH/ElGamal), el algoritmo de Shor reduciría enormemente la complejidad de lanzar un ataque, pero no acabaría con su seguridad de forma inmediata. Además, debemos tener en cuenta, en primer lugar, que necesitamos de computadores cuánticos para llevar a cabo estos ataques; y que la llegada de este tipo de sistemas estará, con toda seguridad, asociada a la creación de nuevos algoritmos cuánticos criptográficos. De hecho, la criptografía cuántica (que no tiene directamente nada que ver con la computación cuántica) lleva con nosotros, nada más y nada menos, que desde 1984.

Hasta aquí este nuevo mito, que como siempre, espero que os haya resultado interesante.

Read Full Post »

Crackear contraseñas es una necesidad inherente al ser humano. Bueno, a algunos seres humanos…

Hoy en día, con procesadores de varios núcleos hasta en los teléfonos móviles, y con tarjetas gráficas más potentes que los procesadores principales, el crackeo de contraseñas tradicional con un único hilo no tiene demasiado sentido. Necesitamos aplicaciones que aprovechen el paralelismo de las arquitecturas existentes. Y de hecho, ya existen algunas maravillas como pyrit.

Hoy os presento una aplicación de esas características. Hashkill es un crackeador de contraseñas multihilo para Linux, que permite utilizar tanto la CPU como la GPU, para lanzar ataques de fuerza bruta, de diccionario, híbridos o de markov.

La lista de plugins disponibles -es decir, algoritmos que puede crackear- es muy interesante:

Plugins de hashkill

Plugins de hashkill

La instalación es tan simple como ejecutar la siguiente orden, sobre el contenido del paquete descomprimido:

ramiro@cormanthor:~$ sudo ./install.sh

Después, para utilizar la CPU en el ataque lanzaremos “hashkill-cpu”, y para utilizar la GPU lanzaremos “hashkill-gpu”. Los distintos parámetros permiten elegir el plugin a utilizar (algoritmo a atacar), el tipo de ataque, las reglas de generación de las contraseñas (longitud, alfabeto, prefijos, permutaciones…), etc.

Opciones de hashkill

Opciones de hashkill

Aquí tenéis un ejemplo de ataque markov contra un hash MD5, usando las reglas de generación por defecto (longitud de 1 a 8, generación lalphanum), contra una contraseña de 6 caracteres.

Cracking de contraseñas con hashkill

Cracking de contraseñas con hashkill

En mi caso particular, lanzar el ataque con mi CPU (AMD Phenom II 965 X4 Black Edition) supone el cálculo de unos 123 millones de hashes por segundo, con los cuatro núcleos a tope. Lanzar el ataque con mi GPU (NVIDIA GeForce 8300 integrada en la placa) supone el cálculo de unos 28 millones de hashes por segundo, y una ralentización brutal de mi escritorio. :-)

Un software muy interesante, relativamente reciente (junio de 2010) y con mucho futuro por delante (la versión actual es la 0.2.4). Os recomiendo que le echéis un ojo.

Read Full Post »

Con un retraso más que considerable, ya podéis encontrar en vuestro kiosco el número de febrero de la revista @rroba.

Además, este número 161 es, hasta lo que yo sé, el último de la revista @rroba. A pesar de que en sus páginas no se mencione absolutamente nada del tema, y de que ya hubiera rumores de cierre cuando tuvo lugar el cambio de editorial, allá por el número 144; la información que yo tengo indica que el cierre es real y definitivo. Si -como ocurriera hace año y medio- no ocurre algo en el último momento, hasta aquí llega la historia de la publicación más veterana en España sobre Internet y seguridad informática.

Para mí han sido casi cinco años de colaboración con la publicación, en los que he escrito 102 artículos, incluyendo un curso de arquitectura de computadores de 22 entregas y uno de programación en Java de 32 entregas, así como 48 artículos con temática muy variada: desde el hacking puro hasta el análisis de nuevas tecnologías, y pasando por perros verdes como la computación cuántica o la criptografía cuántica. Personalmente, ha sido una experiencia muy enriquecedora, que me ha ayudado a aprender mucho -tanto técnicamente, como en la propia redacción- y me ha reportado muchas satisfacciones.

Ya centrándonos en los contenidos de este número, encontraréis los dos artículos habituales con mi firma.

El primero de ellos es la entrega habitual del Curso de Java Útil, trigésimo segunda del curso y segunda dedicada a la aplicación jWadalCrack. En esta entrega, comenzaremos a diseñar una lógica de negocio real para la aplicación, permitiendo la realización de pruebas reales de ruptura de hashes. Además, introduciremos unas nociones iniciales al análisis del rendimiento del proceso de ataque, realizando unas estimaciones iniciales (y algo burdas) de los tiempos de ruptura estimados para ciertos valores de entrada. Lamentablemente, y tras sólo dos entregas dedicadas a jWadalCrack, el programa es poco más que una prueba de concepto y está muy verde. Afortunadamente, en estas dos entregas ha dado tiempo a esbozar los fundamentos de los principales pilares sobre los que desarrollaríamos la aplicación, por lo que no debería de ser muy complicado continuar su desarrollo sin mi ayuda. Creo que esos serán los últimos deberes que os mande. ;-)

El segundo artículo lleva por título Hacking Android, y en él veremos cómo sacar el máximo partido a nuestro hardware, gracias al sistema libre y abierto de Android. Rootear el terminal, instalación de ROMs personalizadas, desbloqueo de hardware no utilizado por el fabricante, instalación del kit de desarrollo, conexión del terminal a bajo nivel, desbloqueo del bootloader, personalización del recovery, flasheo de componentes del firmware… en definitiva, destripar un dispositivo Android desde el primer tornillo hasta el último punto y coma. Como debe ser.

@rroba 161

@rroba 161

Read Full Post »

Un ordenador puede generar números aleatorios

En nuestro anterior mito, ya apuntamos hacia esta interesante -o eso creo- pregunta: ¿puede un ordenador generar números aleatorios?

Seguramente, un primer pensamiento intuitivo apunte a una respuesta afirmativa. Dado que los números aleatorios son muy utilizados en informática, y especialmente en criptografía; parece lógico. Además, todos hemos programado alguna vez usando las típicas funciones random. Bien, pues a pesar de ello, la respuesta es que NO.

Un ordenador es un sistema determinista. Esto quiere decir que tiene una relación directa de causa-efecto, por lo que, dada una misma entrada y un mismo proceso, siempre obtendremos una misma salida… aunque Windows a veces parezca contradecir este principio. Dado un algoritmo determinado, por tanto, si queremos ver cambios en la salida (efecto), tendremos que efectuar cambios en la entrada (causa).

Así, los algoritmos de generación de números “aleatorios” son en realidad, algoritmos de generación de números “pseudoaleatorios. Esto quiere decir que los números que obtenemos no son aleatorios, pero bajo determinadas circunstancias y condiciones, podemos utilizarlos como si lo fueran. Para generar estos números pseudoaleatorios, los algoritmos utilizan entropía externa al sistema, que actúa como semilla de generación para la entrada del proceso.

Esta entropía es captada en sistemas caóticos que, pese a ser deterministas, se ven influidos por un gran número de variables; y cuya modificación, aún siendo leve, puede variar en gran medida el estado del sistema. Los ejemplos más típicos de captación de entropía en ordenadores son la interacción con el usuario (movimiento del ratón, pulsación de teclas, etc.) o con las redes de comunicaciones (flujo de entrada/salida, estado de buffers, etc.). Así, y por poner un ejemplo, al generar una pareja de claves en GnuPG, el sistema instará al usuario a maximizar la interacción con el sistema, para así magnificar los cambios introducidos en la entropía del sistema caótico.

Pero, ¿y si cambiamos un poco la pregunta de nuestro mito?

Un ordenador puede obtener números aleatorios

Bueno, ya sabemos que un ordenador no permite generar números puramente aleatorios, pero que sí permite generar números pseudoaleatorios. Pero claro, ahora no estamos utilizando el verbo “generar”.

Ahora la respuesta es afirmativa. En este caso, la generación de números puramente aleatorios requiere de un dispositivo hardware que, en base a ciertos procesos físicos (desintegración de isótopos, ruido térmico, etc.), permite realizar mediciones aleatorias. Así, en el dispositivo tiene lugar algún tipo de proceso físico intrínsecamente aleatorio, que mediante los sensores apropiados será registrado por el ordenador. En última instancia, la medición efectuada será aleatoria, si bien el ordenador se limitará a realizar una lectura, no tomando parte en ningún proceso de generación.

Y hasta aquí este mito. Como siempre, espero que os haya resultado interesante.

Read Full Post »

Older Posts »

A %d blogueros les gusta esto: