El Informático enmascarado

Motivos por los que hay que tener una política exhaustiva de cortafuegos:

Desde luego, python es versátil, ya lo creo..

(visto en commandlinefu.com)

Supongamos por suponer, que tenemos un iPhone 3G, comprado a Movistar, con su tarifa iphone y su canesú.

Supongamos que esa tarifa nos da acceso a las zonas wifi de telefonica (no se si es una opción o viene de serie)

Cuando entras desde un ordenador normal a una zona wifi de Telefonica, te pide tu tarjeta de prepago, etc. Si entras desde el iPhone, salta a una página ‘especial’ donde te pide el nº de telefono que tienes con la tarifa, para poder navegar. Lo metes, autentica, y tirando millas. Olvidémonos del truco evidente; nuestro objetivo es usar nuestro ordenador, siendo nosotros los dueños de dicho número de móvil.

Si metes la URL a mano en el navegador, y autenticas, el sistema dice que ‘no puede autenticar contra el servidor de tarjetas’. A mi al menos me pasa con firefox, así que no puedes usar la ‘autenticación’ del iPhone desde un ordenador. ¿ pero qué pasa si usamos el navegador Safari ? aaaaaah…..

Testeado con safari de mac. Post publicado desde mi Macbook Pro, usando la Zona Wifi de Telefónica. Y recuerden: todo esto sólo es producto de su imaginación; no le den más vueltas…

En la lista de correo de la Asociación de internautas me pidieron ayer que les explicase el problema que hace poco ha surgido en Debian, y que ha afectado a todas las distribuciones dependientes de ella (Ubuntu, por ejemplo). Como el rollo soltado no me ha quedado mal del todo, lo pego aquí para disfrute del personal.

Nota: no aporto nada que no se haya dicho ya en otros sitios, más completo y con mejores ejemplos. Pero espero que sirva a alguien para entender el alcance del problema.

–

Kriptópolis tiene muy buenos artículos explicándolo en lenguaje técnico-llano, pero intentaré hacer de Isaac Asimov para vosotros.

El cifrado estándar en la informática se basa, a muy grandes rasgos, en encontrar una estructura que sea extremadamente difícil de ‘adivinar’ por pura suerte o por prueba sistemática. A esto último se le denomina ‘ataque por fuerza bruta’.
Ejemplo: digamos que yo utilizo una clave numérica de dos dígitos como código de alarma de mi casa; eso hace que cualquier persona que pruebe 99 combinaciones (del 01 al 99, o 100, si consideramos el 00) tiene *por pura obligación* que hallar cuál es la clave que he utilizado. Si el código pasa a ser de tres dígitos, entonces las posibilidades van de 000 a 999, y así. En el fondo, nunca buscas ser totalmente indescifrable, sino lo suficientemente difícil para que no merezca la pena intentarlo.
basándonos en ello, volvamos al asunto concreto. Cuando generas llaves de cifrado RSA (clave pública+ clave privada) asociadas entre sí, generas dos conjuntos de información, uno público, que puedes (y quieres) compartir con la gente, y uno privado, que es el que te reservas para tí y el que te otorga la exclusividad del cifrado (privacidad) o firmado (autentificación) de la información. Tu clave pública se relaciona únicamente con tu clave privada, por lo que es teóricamente posible ‘adivinar’ tu clave privada, a partir de probar llaves privadas. La seguridad radica en la gran cantidad de llaves privadas posibles, tanto, que hace que (para los que manejamos ordenadores normales, NSA y similares al margen) se calcule en meses, años, o incluso más, lo que se tardaría en ‘adivinar’ una de esas llaves privadas. Aquí radica lo importante, en la gran cantidad de posibilidades.
Para generar un par de llaves privada/pública, necesitas que sean al azar. Y en la informática, eso del ‘azar’ está jodido de conseguir, puesto que todo se basa en situaciones conocidas: es por ello que se utiliza lo que se llaman ‘fuentes de información aleatoria’, que es recoger información de pulsaciones de teclado, de ratón, accesos a disco, información de red, etc.. Contactos con el mundo real que producen información de forma casual, y por tanto, no predefinida. Tomando valores matemáticos a partir de esa información, consigues crear tus llaves totalmente aleatorias, y por tanto, difíciles de adivinar.
En el caso concreto de debian, esa información aleatoria, se combinaba con el numero de proceso de programa (PID) del que estaba creando las llaves, al fín de meterle ‘un poquito más de aleatoriedad’, creo, de si era este motivo no estoy totalmente seguro.
La cosa es que por error (más bien, por un razonamiento tremendamente erróneo), se eliminó las líneas de código que utilizaban la información aleatoria, dejando únicamente el número de PID como fuente de información aleatoria para crear las llaves.
en Linux, los PID van de 0 hasta 32768, por lo que de las millones o miles de millones de posibilidades, o más, que se esperarían en tus llaves de cifrado, bajamos a únicamente 32768.
Ese número es tremendamente bajo, tanto que hasta hay ya listados ‘pre-creados’ de TODAS las posibles llaves. Es decir, treintadosmil y pico.
Ahora vayamos al asunto práctico:
- Un amigo nos envía un mensaje cifrado. Para ello, coge nuestra llave pública, que conoce, y pasa el mensaje por la misma. Eso hace que sólo con nuestra llave privada se pueda descifrar. En condiciones normales, hay que probar entre muchas, muchísimas combinaciones, para hallar ‘por suerte’ la llave privada que nos dé ese descifrado. Pero en este caso, las combinaciones se reducen a 32000. Muy pocas.
- Nosotros vamos a firmar una información. Para ello, usamos nuestra llave privada, que nadie más tiene, y generamos un código matemático que alerta de si el mensaje ha sido modificado, y ese código lo ‘pasamos’ por nuestra llave privada, para garantizar que somos nosotros, dueños de dicha llave, los que enviamos dicho mensaje. para poder alterar ese mensaje, o crear otro cualquiera haciéndose pasar por nosotros, quien sea necesita de nuestra llave privada. De nuevo, 32000 pruebas y ya la tenemos ‘adivinada’. Demasiadas pocas.
- Una web se identifica con un certificado seguro. Un certiicado web-ssl es básicamente una llave pública criptográfica, que a su vez está firmada por una entidad de terceros (verisign, comodogroup, thawte, etc), garantizando que ellos son ellos, que la conexión que se haga bajo su control será privada, y que nadie la va a interceptar o alterar. De nuevo, sobre 32000 posibilidades únicamente, es extremadamente fácil romper esa seguridad. Por no hablar de la posibilidad, algo mas remota en términos de Internet ‘normal’, de hacerte pasar por un servidor web legítimo, que es lo que los certificados seguros se supone que pueden evitar.
- La misma situación se da con TODO, ABSOLUTAMENTE TODO lo que haga uso de cifrado en TODAS LAS DISTRIBUCIONES basadas en debian y que hagan uso del soporte estándar de cifrado: eso incluye a apache, mysql, servidores de correo varios, ssh (peligrosísimo si los servidores tienen habilitado el loggueo automático por llaves rsa), etc. Curiosamente el pgp/gpg no se ve afectado, porque usan código propio para estos asuntos. Ellos ya tuvieron vulnerabilidades de este tipo (pgp 6, si no recuerdo mal) en el pasado.
Y todo esto no es lo más grave; ni siquiera el riesgo de que una autoridad de certificación hubiese usado debian o una distribución derivada para generar sus firmas autentificadoras de certifcados web.

No; lo más grave, con diferencia es, que por un lado, éste error ha convivido en Debian por mucho más de un año; y por otro, que el error fue motivado por una conversación del tipo:
- oye, que no se qué hace éste código, pero cuando lo pasamos por tal herramienta de programación produce avisos muy feos.
- Vale, pues quítalo, seguramente no valga para nada.

La base de Debian es: somos lentos, somos conservadores, somos sectarios, pero somos SÓLIDOS. Ésto ha tirado por los suelos lo que, por otro lado, era evidente que se trataba de un mito.

Espero haber sido lo suficientemente claro explicando todo esto. En kriptopolis.org tenéis varios artículos y enlaces para quien quiera profundizar en el asunto.
Más información:

Kriptopolis

Se descubre un bug de seguridad en Windows, y se tarda Dios sabe cuánto en arreglarlo: se descubre lo mismo en código abierto (freebsd), y se publica un arreglo en cuestión de horas.

Pero la seguridad en software no tiene relación con que el código sea libre o propietario. Para nada.

FreeBSD, también vulnerable al bug en el generador pseudoaleatorio:
[...]

Sólo existe un consuelo para los usuarios de FreeBSD: mientras los usuarios de Windows XP esperan el correspondiente SP3 (y los de Windows 2000 probablemente ni siquiera puedan contar con alguna solución), en FreeBSD el problema ya dispone del correspondiente parche.
• FreeBSD-SA-07:09, random Security Advisory
• FreeBSD Insecure Random Number Generator Information Disclosure Weakness [Security Focus].

Technorati Tags: Seguridad, Software Libre