Van Eck Phreaking

jueves, 22 de abril de 2010

Hoy tenemos una entrada digna de los programas de Friker Jiménez:

PRIMER CASO:
Año 1987, Alexei se encuentra tranquilamente en su habitación de un pequeño chalet situado en el distrito de Queens, en Nueva York.

Se dispone a trabajar con su PC, porque tiene que terminar unos documentos muy importantes que tiene que entregar a la embajada de su país. Es un PC corriente, aislado, sin ningún tipo de comunicación con ninguna otra máquina, un ordenador que no se mueve nunca de la habitación más reservada de la casa.
Mientras Alexei está redactando sus documentos con su editor favorito, fuera, en el exterior del chalet, una furgoneta está apostada frente a la calle peatonal. En su interior se encuentran agentes de la NSA, sentados frente a un televisor que muestra exactamente lo mismo que muestra el monitor del PC de Alexei en tiempo real, y en blanco y negro.

SEGUNDO CASO:
Nos dirigimos al siguiente enlace http://www.erikyyy.de/tempest/ , nos descargamos el programa y seguimos las instrucciones del Léeme contenido. Una vez que echamos a andar el programa, cogemos la radio más cercana y sintonizamos una determinada frecuencia (que es parámetro del programa) de AM. Suena en la radio para Elisa, de Beethoven.


Estos dos casos se basan en el mismo principio, ¿Magia?.
No. Electromagnetismo.

Hace cuatro o cinco años, estando en segundo de carrera, escuché por primera vez hablar de TEMPEST, también conocido como van Eck phreaking por el autor del sistema que consagraba la técnica que permitía capturar y revelar los datos que transportan las ondas electromagnéticas producidas por un monitor CRT.

Para conocer como funciona el sistema es necesario conocer como funcionan los monitores CRT (el del tubo de rayos catódicos):
Un haz de electrones es acelerado y dirigido contra un punto de la capa fluorescente de una pantalla, para ello se utiliza un sistema formado por un cátodo situado en un extremo del tubo y un ánodo que envuelve la pantalla del monitor. Con unas bobinas generadoras de campos magnéticos se puede desviar el haz hacia cualquier punto en concreto de la pantalla.
El haz escanea toda la pantalla del monitor de arriba a abajo, y de izquierda a derecha con una determinada frecuencia.
He encontrado un vídeo en youtube que explica todo bastante bien (y así me ahorro explicar el tema de los colores), http://www.youtube.com/watch?v=PXTcne4n8OY .

Cuando la tensión eléctrica varía en un material conductor provoca una onda electromagnética proporcional a la diferencia de potencial. Y a su vez, las ondas electromagnéticas crean una diferencia de potencial en un conductor proporcional a la fuerza de la onda.

La intensidad de un haz determinado (rojo, verde o azul), es responsable de la presencia de dicho color en el píxel, pero es la intensidad total que conforman los haces la que define el brillo (la luminosidad) de un píxel.
La señal relativa a la intensidad de un color que le llega al monitor de la tarjeta de vídeo es del orden de 0V a 1V, sin embargo, dentro del monitor la señal se amplifica antes de proyectarse sobre la pantalla a tensiones muy altas. Como resultado se producen las fuertes ondas electromagnéticas, que nos dan el contraste entre un píxel y su contiguo (recordemos que la diferencia de potencial es la causante de la onda, y que el brillo de un píxel viene determinado por la intensidad total de los haces). De hecho, al formarse simultáneamente los colores, no podemos sacar la información relativa a cada color.

Imaginemos que tenemos un monitor con una resolución de 640x480, y una tasa de refresco de 70Hz. Los tres haces de luz deben volver simultáneamente cuando terminan una línea al inicio de la siguiente, esto sucede 480x70 veces cada segundo. También deben volver al inicio de la pantalla una vez la han recorrido, esto sucede 70 veces por segundo.
Por lo tanto, ya sabemos cuantos píxeles se escriben por segundo, o dicho de otro modo, sabemos que frecuencia hay que filtrar en la señal electromagnética para obtener la información que nos da la diferencia de brillo entre un píxel y su contiguo. Podemos construir con esta información una representación de la imagen original en blanco y negro.
Ya sólo queda construir y ajustar un circuito sabiendo algunos datos adicionales (lo que llega al monitor son los tres canales nombrados más otro de sincronización vertical y horizontal) que filtre la señal, la amplifique y nos permita ver una pantalla situados con una antena y un monitor a bastante distancia. Es cuestión de construirlo e ir ajustando los parámetros para resoluciones y tasas de refresco conocidas.

--------------------
Conozco muy poco sobre los sistemas que giran en torno a TEMPEST, pero sí que suele aparecer como una técnica más a tener en cuenta dentro del área de la seguridad física, de hecho el CNI certifica contra TEMPEST (https://www.ccn.cni.es/index.php?option=com_content&view=article&id=21&Itemid=25).
Se pueden proteger las emisiones de los monitores CRT apantallándolos debidamente.

Está en desuso porque ya casi no quedan monitores de este tipo. Yo he probado personalmente el programa nombrado al principio de la entrada con un monitor TFT de 23 pulgadas y he tenido que acercar bastante la radio a la pantalla, a unos 15 cm, y con la pantalla pequeña del portatil de 12 pulgadas no he logrado escuchar nada. En cambio con el monitor CRT te puedes alejar bastante, lo mejor es que lo probéis.
Tengo un diseño en papel del circuito eléctrico que lleva TEMPEST obtenido en Internet por si a alguien le interesa, yo me lo llegué a proponer para el TFC, pero al final cambié de idea. Hay bastante documentación y vídeos en Internet sobre el tema.
Existen también técnicas para capturar datos a través de otro tipo de emisiones, por ejemplo acústicas, que pueden ser útiles para conocer la longitud de una contraseña tecleada por ejemplo.
Se aceptan todo tipo de comentarios, sobretodo si son críticas constructivas, y sobretodo aclaraciones en la parte de física.

Cazador cazado

domingo, 18 de abril de 2010

Casi todos los días, si no son todos, se me cuelan en la bandeja de entrada algunos correos publicitando páginas web que nos cuentan fórmulas mágicas para adelgazar, o para hacer crecer...el cabello, o donde nos invitan a conocer chicas fáciles dispuestas a complacer nuestras más oscuras perversiones.


Suele ocurrir que el remitente de dicho correo basura pertenece a nuestra lista de contactos, por ello pasa nuestros filtros de spam.
No es que nuestros amigos lo envíen conscientemente, pero el malware instalado en sus máquinas sí lo hacen.

Esta misma tarde estaba revisando el correo cuando me he encontrado con el siguiente correo de una amiga:
"¡Fotos de su puerca en myspace privado!"
Enlace

Creo conocer bien a mi amiga, y cuando he cargado dicho enlace en el navegador he confirmado que sí, que era spam (que decepción ;d).
Como estaba sólo en casa y no tenía nada que hacer, investigué un poco el supuesto enlace, este enlace que me invita mi amiga a visitar, es el siguiente:
http://amigos2010.webcindario.com/

Una vez carga en el navegador, el contenido mostrado difiere poco del que muestra hotmail para acceder a nuestro correo, sin embargo, dejando aparte que la URL es http://amigos2010.webcindario.com, el diseño de la Scam no está muy conseguido, en la esquina inferior izquierda puede leerse 2007 Microsoft Corporation.



Webcindario es un hosting gratuito ofrecido por Miarroba, cualquiera puede registrarse y subir su propias páginas web.

Lógicamente lo primero que hize fue ver el código fuente de la página a ver dónde iban los datos que escribiésemos en el formulario, centrándome en lo siguiente:
form name="f1" method="post" target="_top" action="login.live.php" onSubmit="return WLSubmit(this)"> ........
Fijémonos en action=login.live.php , pués define a donde se envían los campos del formulario, en este caso a login.live.php, es decir a: http://amigos2010.webcindario.com/login.live.php

Suponemos logicamente que el fichero php contiene código PHP que guarda nuestro nombre y password en una base de datos a través de MySQL, o quizás ha optado por lo más cómodo y lo guardará directamente en un fichero txt.
Observación para no perderse: PHP es una tecnología orientada al servidor, lo que implica que cuando el cliente pide el fichero.php al servidor el código PHP contenido en este fichero se ejecuta en el servidor, no se envía al navegador del cliente (aunque se puede escribir mediante PHP contenido que deseemos enviar al navegador).

Lo único que sabemos del fichero php es que devuelve al navegador el siguiente código:
meta http-equiv='Refresh' content='1;url=http://www.hotmail.com'>Resumiendo, una vez que introducimos un nombre y contraseña en el formulario y pulsamos sobre el submit, el navegador se redirige (enviando también los datos del formulario) a login.live.php, el cuál a su vez nos redirige a la hotmail.com verdadera. Acabas finalmente en www.hotmail.com, eso sí, los datos del formulario ya han sido procesados por http://amigos2010.webcindario.com/login.live.php .

Lo primero que he intentado es buscar más posibles ficheros php o txt alojados en la página web, primero he probado con los típicos nombres de fichero que se le podían haber ocurrido al autor de la página:
http://amigos2010.webcindario.com/password.txt
http://amigos2010.webcindario.com/cuentas.txt
http://amigos2010.webcindario.com/pass.txt
http://amigos2010.webcindario.com/admin.php
.........

Como no he dado con nada, he usado OWAP DirBuster que busca nuevos directorios y archivos en una web probando con una lista de palabras que introduzcamos, o a través de fuerza bruta si se prefiere.
Como empezaba el partido de mi atleti ;) he dejado puesto Dirbuster buscando archivos php y txt a través de los nombres contenidos en una lista extensa (la que viene con el mismo programa) en nuestra querida web maliciosa. Al volver me he encontrado con esto:



Si cargamos en nuestro navegador http://amigos2010.webcindario.com/amigos.txt vemos la lista de emails con sus password capturados por la página maliciosa, son bastante pocos (una treintena), seguramente haya sido alguien que montó la página copiando la idea de algún tutorial e invitó a mi amiga a visitarla, y a partir de ahí utilizó su mail. Esto último parece lo más probable, pero no me he puesto a investigar más.
Un par de nombres de correos de los que aparecen en el txt son obscenos, así que me hago la idea aproximada de la estrategia utilizada por el autor de la página.

Esto es todo, ya he denunciado la web a miarroba y avisado a los usuarios para que cambien la contraseña. También como ya dije estoy preparando un nuevo blog, micropolaris.blogspot.com, todavía está en construcción, y preveo será muy interesante ;).

ED: La última vez que he mirado el txt (antes de irme a dormir) estaba vacío, lo han limpiado. Mañana miraré de nuevo.
ED2: Ya no están ni el fichero login_live.php ni el fichero txt.
ED3: Ya se ha retirado la web, el nombre de dominio ha quedado libre en webcindario.

Firma Digital

viernes, 2 de abril de 2010

Un lector me ha sugerido que dedique una entrada a los certificados digitales, me ha parecido muy buena idea ya que todo el tema de la criptografía digital suena mucho en los medios ultimamente, sobre todo ahora que tenemos el DNI electrónico.
Voy a intentar explicar a grosso modo todos estos conceptos sin entrar en tecnicismos ni detallar las matemáticas que los describen, es decir, voy a contar qué son o qué hacen, y no el cómo lo hacen.

Vamos al grano, empezaré por lo siguiente:

FUNCIONES DE HASH

Para empezar, una función de
hash, como cualquier función matemática, es una relación entre dos valores, en el que dado un X le corresponde un único valor Y. Una función matemática conocida por ejemplo es la función Raíz de X.
Las funciones de Hash más utilizadas, como MD5 o SHA-1, toman una ristra de bits de cualquier longitud y operan con ella para devolver un valor único llamado hash o resumen, de longitud fija.
Son funciones sin marcha atrás, a partir de un hash dado no se puede llegar a la ristra de bits que lo originó porque la función inversa es muy costosa, no alcanzable computacionalmente en un tiempo aceptable. Además, cualquier cambio mínimo en la ristra de bits tiene como resultado un hash radicalmente distinto.
Una imagen digital, un archivo, un conjunto de archivos, una cadena de caracteres como es un texto pueden ser codificados en el ordenador como una ristra de bits.
Ahora echemos un vistazo a los siguiente ejemplos (sacados de la wikipedia) donde se aplica la función hash MD5 a las frases entrecomilladas:
MD5("Esto sí es una prueba de MD5") = e99008846853ff3b725c27315e469fbc
MD5("Esto no es una prueba de MD5") = dd21d99a468f3bb52a136ef5beef5034
MD5("") = d41d8cd98f00b204e9800998ecf8427e

Resumiendo, una función de hash aplicada por ejemplo sobre un archivo devuelve un resumen que identifica unívocamente a dicho archivo. Por lo que estas funciones son muy utilizadas para garantizar la integridad de los datos. Si de un archivo determinado conocemos su resumen MD5 = af139d2a085978618dc53cabc67b9269, si obtenemos dicho archivo de otra fuente y el resultado de calcular su resumen MD5 no corresponde con lo anterior, entonces el archivo no es el original y ha sido modificado.

Las funciones de
hash tienen otras utilidades ajenas de las que no vamos a hablar en esta entrada, en criptografía también se utilizan para comprobar la validez de una contraseña sin necesidad de almacenar en ningún sitio dicha contraseña. Recordemos que dado un resumen no se puede llegar a la ristra de bits que originó dicho resumen.

Observación : Una función de Hash opera con un conjunto infinito, ya que trabaja con cualquier ristra de bits de cualquier longitud. Sin embargo, el conjunto de posibles resúmenes que se pueden obtener con una función de Hash es finito, limitado por las posibles combinaciones que se pueden formar con una cantidad de dígitos determinada, ya que los resúmenes poseen siempre la misma longitud fija.
Por lo que
necesariamente deben existir colisiones, es decir, dos archivos distintos pueden originar el mismo hash, esto rompe con la idea de que un hash identifica unívocamente un archivo y por tanto garantiza la integridad de éste.
Es una vulnerabilidad inherente de estas funciones, sin embargo, en la práctica esta vulnerabilidad no puede ser aprovechada por el coste computacional que tiene encontrar estas colisiones.
En la actualidad diversos grupos de investigadores encontraron las primeras colisiones para MD5 hace ya algún tiempo, pero para SHA-1 el asunto de encontrar colisiones se vuelve más complicado.


CRIPTOGRAFÍA ASIMÉTRICA VS CRIPTOGRAFÍA SIMÉTRICA
La criptografía simétrica es la criptografía clásica en la que el emisor y receptor comparten la misma clave, la cuál sirve para cifrar y también para descifrar. El problema aquí viene de la necesidad de establecer una comunicación segura (que no pueda ser "escuchada" por terceros) previa para ponerse de acuerdo sobre la clave a utilizar.
En la criptografía asimétrica, aparecida hace unas décadas, existen un par de claves asociadas llamadas clave privada y clave pública. Lo cifrado por la clave pública sólo puede ser descifrado con la clave privada asociada a esa clave pública, y viceversa.
El emisor y receptor tienen cada uno su propio par clave pública-clave privada.
El receptor envía
tranquilamente al emisor su clave pública.
Lo cifrado por el emisor con esa clave pública sólo puede ser descifrado por el receptor, ya que solo él conoce la clave privada asociada, la cuál no da a conocer a nadie, ni siquiera al emisor.

Intercambiando papeles el emisor hace lo mismo con el receptor, le da su clave pública para los datos que el receptor le tenga que enviar.
Se elimina el problema mencionado para la criptografía simétrica, mi clave pública la puede conocer todo el mundo, sirve para cifrar, pero no para descifrar, sólo yo puedo descifrar con mi clave privada lo cifrado por mi clave pública. La criptografía asimétrica por tanto permite establecer una comunicación segura bajo un canal inseguro.

Cifrar con la clave privada también tiene su utilidad. Lo cifrado con la clave privada puede ser descifrado únicamente con la clave pública asociada. Y aquí entra en juego el concepto de firma digital, imaginemos que tanto emisor como receptor poseen un mismo archivo el cuál contiene un documento jurídico.
Si el emisor cifra dicho archivo con su clave privada, y lo envía al receptor, él receptor ahora descifra este archivo cifrado, para ello utiliza la clave pública del emisor. Entonces comprueba que lo obtenido es el archivo original. Como sólo el emisor conoce su clave privada, entonces está claro que fue el emisor el que cifró dicho archivo.
Como en la vida real, estampar mi firma sobre un documento significa realizar una operación sobre éste que sólo yo soy capaz de realizarla. De hecho, la firma digital es más segura, porque cualquiera puede imitar mi firma real observándola cuidadosamente, pero no puede imitar mi firma digital porque yo no doy a nadie mi clave privada.

Como dijimos en la primera parte un resumen o hash identifica unívocamente un archivo, en la práctica y porque el algoritmo criptográfico necesita trabajar con longitudes fijas lo que se hace no es firmar un archivo, sino que firmo el resumen del mismo. El receptor procede entonces a descifrar lo firmado, utilizando mi clave pública y comparando lo obtenido con el resumen del archivo.


CERTIFICADO DIGITAL
Imaginemos que en la vida real tenemos un documento firmado por una persona que firma como Felipe Carreño, de poco sirve dicha firma si no se puede contrastar que la firma estampada es la firma con la cuál dicha persona firma habitualmente. Una firma es una firma, pero hay que identificar de alguna manera al autor de la firma.

De la misma manera, mi interlocutor puede decirme que es Menganito y darme una clave pública para cifrar los mensajes que le envíe o para comprobar su firma en un documento, pero, como sé que dicha clave pública es la de Menganito...

Los certificados vienen a garantizan las claves públicas, es decir, garantizan que una clave pública determinada es la clave pública de Menganito y no la de Fulanito.
Un certificado contiene entre otros los siguientes campos: Sujeto (organización, nombre..) para el cuál se emite el certificado, clave pública de dicho sujeto, y la autoridad que firma y emite dicho certificado, ahora hablamos de esto último.
¿Cómo se garantizan las claves públicas?
A través de la firma digital, una autoridad en la cuál confíamos firma digitalmente un documento que llamamos certificado que dice que tal organización posee tal clave pública.
Por tanto tenemos el certificado por una parte y por otra parte tenemos un campo especial del certificado que consiste en la firma de la autoridad, es decir, el resumen del certificado cifrado con la clave privada de la autoridad.
¿Quién es esta autoridad?
Nosotros somos los que confiamos en la autoridad que firma el certificado. Si confíamos en A y A firma el certificado de B, entonces confiamos en B.

Imaginemos que tenemos un certificado de A y nos presentan un certificado de B en cuyo campo "emitido o firmado por" aparece A.
Miramos la firma que aparece en el certificado de B. Procedemos entonces a descifrar la firma con la clave pública de A (la tenemos en el certificado de A), si lo que obtenemos es el resumen del certificado de B, entonces estamos seguros que A firmó dicho certificado, o lo que es lo mismo, que firmó un documento que relaciona a B con una clave pública determinada.

¿Y quién garantiza la clave pública de la autoridad que firma un certificado?
Vale, hemos dicho que A firma el certificado de B, pero ¿como sé que dicha firma es la firma de A?, o dicho de otro modo, ¿quien me garantiza cuál es la clave pública de A?.
Utilizando el mismo proceso. Confiar en A quiere decir que confiamos en su certificado, el criterio de confianza es nuestro, una razón lógica es que el certificado está firmado digitalmente por una autoridad en la que confiamos.
Los navegadores web, dan un certificado como válido cuando es firmado por una autoridad cuyo certificado está instalado en el navegador. En caso contrario el navegador informa al usuario con la alerta correspondiente, y el usuario decide si seguir navegando por la web.

¿Cómo puedo confiar en el certificado que me presenta una supuesta web de un banco?
Uno debe preguntarse a estas alturas que si él no instaló ningún certificado en el navegador, porque cuando se entra a la web de un banco se le presenta el certificado como válido, es decir, ¿qué autoridad de confianza firma el certificado ofrecido?.
Cuando se instala un navegador web en nuestra máquina, éste viene con una serie de certificados instalados, correspondientes a unas determinadas autoridades.

Imaginemos que el ministerio del Interior, una autoridad conocida por todos, se encargase de emitir certificados a los bancos, y que los navegadores web usados por los usuarios trajesen incorporados cuando se instalan el certificado del ministerio del Interior. Imaginemos también que nos han contratado del Banco Santander para crearles un certificado digital que puedan utilizar para securizar la web del banco.
Entonces generamos un propio par clave pública-clave privada. Nos disponemos a crear un archivo que contiene un documento con el formato de certificado digital, en él va a aparecer como nombre de la
organización el de Banco Santander, nuestra clave pública, y el nombre de dominio del servidor web que se va a securizar con el certificado, entre otras cosas.
Una vez creado el certificado, se le manda al ministerio del Interior el certificado para que lo firme. Éste para emitir(firmar) nuestro certificado nos va a pedir una serie de datos que confirman que nosotros hemos registrado dicho dominio. Si además queremos un certificado de validación extendida, nos va a obligar a demostrar de alguna forma que somos el "Banco Santander".

Es un símil de lo que ocurre en la vida real, confiamos en los datos que aparecen escritos en el DNI de una persona porque confiamos en la autoridad encargada de emitir los DNI.

Con lo aprendido se puede saber más sobre la seguridad en internet, ahora podemos comprender como funciona lo que llamamos un sitio seguro:
Una web segura consiste en una web con la que tengo la garantía de que la información transmitida solo puede ser leída por la organización a la que representa la web, todo gracias al certificado digital.
Cuando en la barra de navegador pone https significa que la información intercambiada con la web viaja bajo un protocolo seguro. Este protocolo exige que el servidor web presente un certificado digital, a partir de ahí la comunicación va cifrada entre web y usuario utilizando la criptografía asimétrica ya vista. En realidad por tema de rendimiento se utiliza una mezcla de criptografía asimétrica para cifrar una clave de sesión y de criptografía simétrica, pero no quiero extenderme demasiado.

El DNI electrónico contiene si no recuerdo mal un par (o dos) clave pública-clave privada con un certificado digital firmado por el ministerio del fomento que garantiza nuestra clave pública. Con el DNI electrónico se pueden firmar documentos sin tener que movernos de casa para ir a firmar papeles. Rompe un poco con la idea de que el par clave pública-clave privada debe generarlo el usuario, porque sólo el usuario debe conocer su clave privada. Se supone que la clave privada generada en el ministerio la genera en algún momento dado la tarjeta al entregárnosla y que manipulando un DNI electrónico tampoco se puede obtener la clave privada que contiene.

------------------------------------------------------

Esto es todo por hoy, supongo que habrá gente que le habrá parecido interesante la entrada y a otros familiarizados con el tema les puede haber parecido un tostón. Prometo traer contenido fresco pronto al blog. A quién les haya servido la entrada, por favor no dudéis en comentar, me ayuda a mantener actualizado el blog ;).