Archivo de febrero del 2010

Seguridad: Encriptación y Autentificación. Capítulo Tercero -> Certificados y Firmas Digitales

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Certificados y Firmas Digitales

El cifrado de datos es un mecanismo que garantiza que nuestros datos, aun cuando puedan ser interceptados por otros, permanecerán seguros. Por otro lado, los Hash nos dan un mecanismo para poder garantizar la integridad de un mensaje. Fue hace ya tiempo cuando se pensó en una aplicación práctica sencilla de estas dos tecnologías, y comenzó a hablar de Certificados digitales. Pronto fue igualmente necesario el concepto de firma digital, un sistema de autentificar algo.

Una tecnología se crea fundamentalmente pensando en algo. Así, el fundamento del cifrado de datos es simple, que cuando un mensaje sea interceptado no pueda ser leído o comprendido por una tercera persona a la cual no está destinado. Pero esto no impide que el mensaje pueda ser modificado, deteriorado, falseado… Imaginar una carta postal que se escribe con “tinta invisible”. Alguien que la intercepte quizás no pueda leer el contenido real de esta, pero puede coger otra carta, rellenarla con la información que desee y enviarla de nuevo al destino de esta. La pregunta es ¿Como podrá el destino saber si dicha carta ha sido modificada? En el caso de la carta quizás con un sello, una firma… aquí el concepto será el mismo, y podríamos decir que el fundamento de un Hash criptográfico es precisamente la integridad.

A raíz de la necesidad tanto de proteger el contenido de los datos en las comunicaciones, como de autentificar el emisor y el destino, como garantizar la integridad del mensaje, se creó el concepto de “Infraestructura de Clave Pública” (PKI). Este concepto no es más que la aplicación práctica en las comunicaciones de los conceptos que hemos visto anteriormente (y alguno más que veremos en este capítulo): Hash, Cifrado Simétrico y Cifrado Asimétrico.

En este capítulo vamos a intentar comprender básicamente cada uno de los elementos que constituye una infraestructura de clave pública (PKI), y veremos como cada siguiente elemento se hace necesario para el correcto funcionamiento de todo el sistema:

  • Infraestructura básica
  • Certificado: Necesidad de asociación usuario/empresa – Claves
  • Firma: Necesidad de autentificación de todas las partes e integridad


Infraestructura básica

Vamos a intentar aplicar todos los conceptos explicados a un entorno real que deseamos que sea completamente seguro. Para hacer esto tenemos que tener una serie de consideraciones, tendremos que crear una infraestructura en la cual podamos aplicar y hacer viable nuestras necesidades. Hemos dicho que el objetivo será triple a la hora de desear crear un canal de comunicación seguro entre dos partes: El cifrado, la autentificación y la integridad. Empezemos por lo tanto por la primera de las partes, el cifrado.

Lo primero que deseamos es que nuestros datos sean interceptados o no por una tercera persona, esta no pueda acceder a ellos. Hemos dicho que para ello disponemos de dos sistemas muy buenos, el cifrado simétrico y el cifrado asimétrico. Cada uno de ellos tiene ventajas e inconvenientes. ¿Cual es más factible de usar? En principio vamos a pensar que el cifrado asimétrico por una razón muy simple: Además de ser más seguro tan solo requiere de un par de claves (publica y privada) para el número que sea de canales de comunicación a entablar. Realizar esto por medio de un cifrado simétrico sería muy costodo en cuanto a infraestructura, dado que ¿Como crearías una base de datos en la cual se pudiese almacenar cada usuario un número sin fin de keys asociada cada una de ellas a un usuario o entidad diferente? Sería impensable. En cambio mediante el cifrado por clave pública esto podría simplificarse, dado que tan solo es necesario hacer pública una sola key para todos los canales de comunicación posibles, no una para cada canal. En realidad el sistema actual usado es híbrido, pero esto se verá más adelante, para nosotros simplemente decir que se opta de momento por el cifrado asimétrico, en nuestro caso RSA.

Una vez definida la necesidad de un sistema de clave pública y las ventajas que esta nos aporta, aparece el primer problema: Distribución. Hemos explicado que el sistema de cifrado asimétrico es muy eficiente e increíblemente versátil, lo que encripta una key privada lo desencripta la pública, lo que encripta la pública lo desencripta la privada. De ahí la necesidad de que la clave pública sea exactamente eso: Pública. ¿Pero como podemos hacer que cualquier usuario del planeta pueda tener acceso a dicha Key? Aquí es donde comienza a crearse la verdadera PKI, de la necesidad de ir solventando los por menores del camino. La única forma de que cualquier usuario conozca nuestra key pública es disponer de bases de datos en las que se encuentren almacenadas las claves públicas de todos los usuarios. A esto se le conoce como repositorios de claves públicas. Ahora, cualquier usuario puede enviar su clave pública asociada a un correo electrónico, nombre, apellidos… Pero de forma pareja aparece la necesidad de algún control sobre dichas bases de datos. ¿Que sucede si una key ha sido comprometida o ya no es válida? Es necesario por tanto otro Repositorio , en este caso un Repositorio de Revocación de claves públicas. Con estos dos sistemas podríamos garantizar el funcionamiento correcto del cifrado de datos entre dos usuarios. Estos repositorios existen a día de hoy, la mayoría de ellos se encuentran sincronizados con los otros para que todos tengan los mismos datos. Por ejemplo podemos visitar uno de ellos:

Repositorio de Claves Publicas del MIT

En dicho repositorio podemos buscar cualquier cadena de texto, ya sea nombre, apellidos, correo electrónico o ID de la clave:

 

Type bits/keyID     Date       User ID

pub  4096R/B9A35B9C 2009-12-02 Carmen Mendes <cmendes@transnumeric.com>

pub  2048R/F4D68EB5 2009-11-07 María del Carmen Rodríguez Sardiña <mariadelcarmen@gens-osorio.es>

pub  1024D/9BC23DEF 2009-10-15 carmenalves (ola) <carmen.alves.05@formando.gti.pt>
...

Por supuesto si continuamos el link de la KeyID nos topamos directamente con la clave pública de Carmen:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.0

mQENBEuGtJwBCAD0EM6+cVCIrc2t5CLWhrdwPrTbb4ZbTAKuLjAjULl3K+/usQg7JT0Y+qL6
Z/eGB8krZgzzT77bQHKVAw7NeUZGSMDl+kSIT9k5gx/vWxdyuBUeJODkd7IldiGbW5yhGz92
0LGbQ5weF2GT8DewCtawOsO46baygPIgiVR99vArzNyiX+KFnrUaniVbjbiN8KQY9Nvmdvyz
BU77W5SDRc4LbuOv5GCtnPKjlVQE5JApoelpZi2fiJkH/kKcf4ZTc0nSK8e8duHYB+zrKrxO
ICKHWXWgLBV9aZkoCH35oShK3JpSeimnV3yqwqz2zt32p/JNKO02krPNNIUL+AqVivEfABEB
AAG0SmNhcm1lbiByZXF1ZWpvICh1biBhbWlnbyBtaW8gc2UgbXVyacOzIGNvbmdlbGFkbykg
PGZvMjAxMGNhcm1lbkBnbWFpbC5jb20+iQE+BBMBAgAoBQJLhrScAhsjBQkJZgGABgsJCAcD
AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBeKv2mzKxFxS0wCACcC6fWZ9IliyKHI8gZBEl3s9Sd
WWlUJo/PNgbzEoq3N/aiy47+ITo/Qax9+PXYUUOH6Zx+CLb4NMyplSo3cESDlg4O/hzkypP6
9Yj6JflHQcqmWfGsWwqf3kiGSWopd8osKdb5bpvKfXI+JKc8Gj5l64JUa0f6BIPIL3/9/Uci
EhnEyHG0b2gJx/f3bybAG+mpBo3VnV/alTfZbX8qnen3Rqg1TPxEyfJjR6E4QrSkeHb8MJp9
ZGO58IWvWAPADJJoK2alKJMRKjeZKFjqcolr4mgNhRhg3iD77SmL1hskwfCinPXGnmimV/Xl
VH0qTX/4Jem6aTG+9aD8u8r3p4LyuQENBEuGtJwBCADALhMeR4PFXzKcxDUzn5yWbckFrz97
ONCbL1C0G/4Wg8fV3t0Vchzg6aKsEYUZSfTe5Ph0rqLWs1cfjgMxrCRYTfzmCffIWBmXixu7
iDuj6bRshY+9F03xFA0X/GJG1bZ/3JuIYTP804UU1/OsH+cFsyj1CnoUNz1zZ5rvm/76VqL1
vBskTyD7cfEPrSTh5HfBu8EatdI0rCPezyzZeE0IhWYg7OChBK6FzkaIEZifpxI7/KSadPNw
NLO0WdLmFhqLqS/Pwt4oCcMxljB9zoO/KGRyvw4nY6BilItFwaIfOjDbrVqDSnG9RZ8+Cevo
TfPi1j1VsBpc113vMqs0g14hABEBAAGJASUEGAECAA8FAkuGtJwCGwwFCQlmAYAACgkQXir9
psysRcVvjgf9F0o3Q3/MbLMriwe9naCXuy2xcceWyZ9vp6ZPm5zoD1Tt7aWRBeFUhk/T88sa
SqcpVqZSNtsdjJl7oHXVcFKeccIebOs826GIMzWgT6kCl2r79RY4W7b0iaPzljH7ayX7Ce3Z
UM7Z0JhCmjH6aszc/dXd3JkHR9cxiY9A1HWrgGzd2RlNCYOVB1kokteVE9+CXCyJwAelSCLR
GAYl33oyxGDKxngVCdeBRxgCeTU0szL7NXMNi3Y2cQCHCiEwTspKXS+wOtos66vgYLYXdgJs
KvW0gau6bUwBouD7aXZOkubfpZ3J85X6KcLuPAQfJlhtuufimJ3y7/+B09c0TD+Osw==
=PqHr
-----END PGP PUBLIC KEY BLOCK-----

Ana desea enviar un mensaje cifrado a Carmen:

a) Ana accede a un Repositorio de Claves pública para obtener la Clave pública de Carmen, para ello busca en la base de datos por “Carmen”. Es posible que haya más de una (puesto que alguna puede estar revocada)
b) Ana con la clave en su poder verifica que esta key no se encuentre en la lista de Revocación. Dado que no está, considera que la key está en uso y es válida.
c) Ana encripta el mensaje con la clave pública de Carmen y le envía el mensaje
d) Carmen desencripta el mensaje con su clave privada.

De este modo Ana puede enviar un mensaje cifrado a cualquier usuario del mundo que esté usando un sistema de clave publica, sin necesidad siquiera que el emisor use dicho sistema, y con la garantía de que dicho mensaje tan solo podrá ser desencriptado por el poseedor de la key privada pareja a la key pública del repositorio. Este sistema logra el objetivo del cifrado de datos. ¿Pero que sucede ahora con la autenficicación?

En el ejemplo expuesto, Ana no puede asegurar de ninguna forma que la clave pública obtenida del repositorio accedido proceda de “Carmen”. Sí, es posible incluso que en dicho repositorio quedase indicado nombre, apellidos, dirección, DNI… pero dado que son repositorios a los que todos tienen acceso, cualquiera podría introducir datos falsos en ellos. Por ejemplo, podría crear una key publica/privada a nombre de otra persona, de esta forma cuando alguien quisiese enviarle a dicha persona un mensaje, lo encriptaría con mi pública. Aquí es donde nace la necesidad de autentificación, de algún sistema por el cual Ana pueda estar convencida que la clave pública obtenida pertenezca a Carmen. Para esto se opta por dos sistemas diferentes, aunque ambos se basan en la misma premisa: Cadena de confianza.

Imaginar que de algún modo se pudiese dar un punto positivo a una clave pública, de forma que cuantos más puntos positivos tenga una Key pública de un repositorio indicase a terceras personas que dicha key es válida. Así por ejemplo yo podría dar un punto positivo a la clave púplica de mis hermanos, puesto se fehacientemente cual es la que pertenece a cada uno de ellos. De este modo, si una tercera persona desease enviarme un mensaje cifrado a mí, se fiaría en caso de duda más de aquella clave pública que tenga más puntos positivos de personas diferentes. Ahora imaginemos que Ana desea enviar un mensaje cifrado al mismísimo Linus Torvalds (El cual espero no le importe que use su nombre para estos ejemplos) para consultarle un bug crítico en el kernel de linux. Lo primero que haría sería acceder al repositorio y buscar por “Linus Torvalds”, dado que ni siquiera conoce su correo electrónico. El repositorio le devolvería lo siguiente:

Type bits/keyID     Date       User ID

pub  1024D/825D2E82 2008-09-03 Linus Torvalds (Teste) <linus@linux.org>

pub  1024D/D080B7A0 2008-07-26 *** KEY REVOKED *** [not verified]
                               Big Gay Al (kay) <letsseesomelove@love.com>
                               REVOKED KEY (u suck) <FUNBO@T>
                               Linus Torvalds (revoke revoke revoke) <werfsdfasdf@fakefakefake.com>

pub  1024D/006D1B6D 2005-11-11 *** KEY REVOKED *** [not verified]
                               Danilo G. Magrini <danilo.magrini@gmail.com>
                               Danilo G. Magrini <danilomagrini@uol.com.br>
                               Danilo G. Magrini <danilo@onclicksistemas.com.br>
                               Danilo Gustavo Magrini (Linus Torvalds) <danilomagrini@uol.com.br>

pub  1024D/8BC6EDEF 2005-11-10 Danilo Gustavo Magrini (Linus Torvalds) <magrini_sp@superig.com.br>

pub  1024D/76E21CBB 2005-04-23 Linus Torvalds (tag signing key) <torvalds@osdl.org>

pub  1024D/CE904A82 1999-11-21 Linus Torvalds <vnixroot@netscape.com>

pub  1024D/449FA3AB 1999-10-05 Linus Torvalds <torvalds@transmeta.com>

pub  1024R/A86B35C5 1996-06-08 Linus Torvalds <Linus.Torvalds@Helsinki.FI>

 

Ana es una chica lista, pero según el repositorio existen 8 posibles claves públicas supuestamente todas correspondientes al bueno de Linus. Sin dificultad Ana descartaría de forma automática las que están marcadas como Revocadas, lo que deja el listado con 6. La primera se podría descartar dado que aunque el correo podría ser legítimo, pone (Test)… podemos imaginar que fue creados con fines de testeo, además, la fecha de la clave es relativamente nueva. La cuarta la excluimos porque el nombre ni siquiera pertenece al de Linus. De este modo tan solo nos quedarían como posibles las 4 últimas. la quinta no obstante puede leerse como (tag signing key) que podríamos suponer que se trata de una clave tan solo para firmas (esto se verás más adelante), así que de momento la descartamos también. Las otras tres restantes podría parecer legítimas a simple vista. Como Ana quiere asegurarse, quiere ver lo que hemos llamado como “votos positivos” de ellas. Si accedemos a la sexta obtenemos la siguiente información:

pub  1024D/CE904A82 1999-11-21            

uid Linus Torvalds <vnixroot@netscape.com>
sig  sig   CE904A82 1999-11-21 __________ __________ [selfsig]
sig  sig   8061A830 2005-05-30 __________ __________ Dan Mundy <harob02@earthlink.net>

sub  2048g/1EEE5A92 1999-11-21
sig sbind  CE904A82 1999-11-21 __________ __________ []

Los votos positivos que hemos nombrado en realidad son firmas, dado que aun no hemos hablado de ellas tan solo imaginamos que son algo así como voto de confiabilidad. En este caso vemos que tan solo posee una firma creada por él mismo “selfsig” y otra firma (voto) creado por un tal Dan Mundy. Ana, que no es tonta, imagina que una persona como Linus, de tener una clave pública en estos repositorios tendrá seguro bastantes votos de confiabilidad. Luego la rechaza.

Esto deja a Ana con dos opciones, las dos últimas. Ana conoce un poco la vida de Linus y le suena que trabajó o tubo relación con trasmeta.com, luego parece un buen punto de partida. No obstante sabe también que Linus es finlandés, nacido en Helsinki, lo que quiere decir que las dos claves que aparecen podrían ser completamente legítimas. Y en este caso las dos pertenecen a él. No obstante, si nos adentramos en la última de ellas, generada nada más y nada menos que en 1996!!, esto es lo que obtenemos:

pub  1024R/A86B35C5 1996-06-08 __________ 

uid Linus Torvalds <Linus.Torvalds@Helsinki.FI>
sig  sig   A86B35C5 1996-06-08 __________ __________ [selfsig]
sig  sig   2A960705 1997-04-24 __________ __________ H. Peter Anvin <hpa@zytor.com>
sig  sig   29BC0185 1998-01-24 __________ __________ george a. r. hill <9x>
sig  sig   0C00E6AD 1998-08-21 __________ __________ Alexander Smith <Sabin84@usa.net>
sig  sig   CCBEA8D2 1998-09-02 __________ __________ Kenyon Ralph <kenyon@san.rr.com>
sig  sig   ACF5A545 1998-12-17 __________ __________ H. Peter Anvin <hpa@zytor.com>
sig  sig   A4679654 1999-01-30 __________ __________ Drizuid <drizuid@drizuid.net>
sig  sig   F0C36E09 1999-01-30 __________ __________ Drizuid <dark-druid@geocities.com>
sig  sig   29B0C351 1999-06-18 __________ __________ Jens S�lwald <j.suelwald@gmx.de>
sig  sig   FEEFE90B 1999-09-15 __________ __________ []
sig revok  FEEFE90B 1999-09-15 __________ __________ []
sig  sig   6470AB26 2000-03-02 __________ __________ Cedric Blancher <cblancher@cmc.fr>
sig  sig   A4C70528 2000-03-15 __________ __________ Alexander Smith <sentinel@freshshell.de>
sig  sig   A24D8B4E 2000-08-10 __________ __________ C�dric Blancher <cblancher@startem.net>
sig  sig   24901EE8 2001-05-31 __________ __________ Simon A Soanes <simon@nullifynetwork.com>
sig  sig   9CD30D3D 2001-10-09 __________ __________ ZC Wong <zcwong@hotmail.com>
sig  sig   01B45CE2 2001-10-09 __________ __________ ZC Wong <zcwong@hotmail.com>
sig  sig   D925418D 2004-04-18 __________ __________ Kevin W. Peters (Guitarman) <guitarman@ntdf.com>
sig  sig   6422D07C 2004-05-23 __________ __________ Fabian Foerster (Root CA) <fabian_foerster@web.de>
sig  sig   0C877B34 2004-05-23 __________ __________ The Root Networks (Root CA) <root-networks@web.de>
sig  sig   FA81F1E6 2004-06-14 __________ __________ Thomas Shea <lrmm@comcast.net>
sig  sig   AAE6022E 2004-12-28 __________ __________ Karlheinz Geyer (RBOS) <karlheinz.geyer@lhsystems.com>
sig  sig   4D34B354 2004-12-28 __________ __________ Karlheinz Geyer (DKB) <karlheinz.geyer@lhsystems.com>
sig  sig   8061A830 2005-05-30 __________ __________ Dan Mundy <harob02@earthlink.net>
sig  sig3  099A79AC 2005-07-12 __________ __________ Konstantin Vinakovsky <kvinakovsky@earthcam.com>
sig revok  AAE6022E 2005-07-28 __________ __________ Karlheinz Geyer (RBOS) <karlheinz.geyer@lhsystems.com>
sig revok  4D34B354 2005-07-28 __________ __________ Karlheinz Geyer (DKB) <karlheinz.geyer@lhsystems.com>
sig  sig   6BEEAF8D 2008-08-02 __________ __________ Kristoffer Warming <heavyhenning@gmail.com>

 

Ana comprende que efectivamente no solo ese puede ser un correo válido de Linus, sino que también lo es su clave pública. Puede comprobar que tiene una serie de firmas en su clave que de un modo reafirman que dicha clave pertenece a él. Se puede observar que 3 de las firmas (votos) están igualmente revocados, pero aun así parece claro que esta es una clave válida y legítima. La última forma pertenece a 2008, lo que nos puede hacer pensar que la cuenta está aun en activo.

pub  1024D/76E21CBB 2005-04-23 Linus Torvalds (tag signing key) <torvalds@osdl.org>

Pertenece también a él, es un correo que es más que conocido por programadores y otros que frecuentan listas de correos del kernel de linux, lo que sucede es que aparentemente por ese nombre podemos deducir que Linus la usa tan solo para firmar, y no para encriptar (esto se verá como he dicho más adelante)

Llegados a este punto, Ana ha logrado dos objetivos. El primero cifrar los datos y el segundo asegurarse que dichos datos están cifrados efectivamente y tan solo para Linus Tolvards, gracias al anillo de confianza que generan estos votos (que no son sino firmas digitales). Pero aun le queda a Ana un problema. La integridad. Como puede estar Ana convencida que el mensaje que reciba Linus no haya sido modificado por un tercero. Ana desea que en el peor de los casos y que este haya sido modificado, Linus pueda conocer que este ha sido modificado, así pueda contactar de nuevo con Ana y solicitarle de nuevo el envío del mensaje legítimo.

Después de un rato de meditación, Ana recuerda la funcionalidad del Hash criptográfico. Ana no podrá garantizar nunca que el mensaje llegue sin modificación alguna, pero puede garantizar que de ser modificado Linus se percatará de ello. ¿Como? Ana recuerda que si aplica por ejemplo un Hash SHA-1 al mensaje cifrado y envia tanto el hash como el mensaje cifrado, Linus podría verificar si el hash especificado por Ana y si coincide con el Hash real del mensaje. Una tercera persona sino, podría interceptar el mensaje, crear un mensaje nuevo, cifrarlo con la key Pública de Linus y enviárselo en nombre de Ana. No obstante, según este esquema una tercera persona podría igualmente interceptarlo, y como conoce el Hash que ha usado Ana, tan solo tendría que redactar el mensaje, encriptarlo, calcularle el nuevo Hash y enviar los datos a Linus. Es aquí donde aparece la necesidad de la firma digital.

Ana ha comprendido las técnicas de los hackers que quieren modificar su mensaje cifrado (sin saber siquira que hay dentro de dicho mensaje) así que ha descubierto la solución definitiva. Ana, que también tiene usa sistemas de clave pública tiene su propia clave pública y privada:

a) Ana redacta el mensaje y lo encripta usando la clave pública de Linus
b) Ana calcula un Hash SHA-1 al mensaje encriptado y este mismo hash lo encripta con su clave privada (A esto se le llama firma digital)
c) Ana envía tanto el mensaje cifrado como la firma a Linus.
d) Linus accede al repositorio de claves públicas y busca la correspondiente a Ana y a dicha dirección de correo (del mismo modo que hizo Ana). Encuentra la que busca con muchos “votos” a su favor, y con la clave pública de Ana es capaz de desencriptar el hash de Ana. Linus calcula el Hash SHA-1 al mensaje cifrado y verifica que ambos valores coinciden!! Luego el mensaje ha conservado su integridad y tanto Ana como Linus han sido autentificados el uno al otro y establecido un canal seguro cifrado.

Si un tercero intentase de nuevo interceptar el mensaje de Ana, cualquier cambio que produjese en él destruiría el hash del mensaje, Linus al descifrar el Hash de Ana comprobaría que este no coincide con el Hash del mensaje, luego comprende que el mensaje ha sido comprometido y rechaza la comunicación. El atacante podria redactar un nuevo mensaje, cifrarlo, calcularle el hash y firmarlo (encriptarlo con su clave pública), pero entonces Linus sabría perfectamente que la clave pública necesaria para desecifrarlo no correspondería a la Ana!! Sino a la del atacante, con lo que jamás la aceptaría. Es aquí donde radica la importancia del círculo de seguridad, la necesidad de saber fehacientemente que una clave pública pertenece a quien dice pertenecer.

Este esquema PKI es básicamente lo que se lleva a cabo en los sistemas de clave pública PGP/GPG, pero ahora veremos las herramientas para el esquema SSL/TLS.

 

Certíficado Digital

Ahora sí es la primera vez que lo nombramos. Un certificado digital no es más que un documento, un archivo que identifica/asocia a un usuario con su clave pública. Cuando veíamos los repositorios de claves públicas y realizábamos una búsqueda, cada entrada tenía asociada un nombre, descripción, clave pública y firmas (los votos que hablábamos) de verificación de otras personas. Un certificado es lo mismo (con algunos matices).

El esquema PKI anterior (llamado Web of Trust) tiene el problema de la confianza, de la legitimidad. Es un buen paso hacia delante el firmar las claves ajenas para avalar su legitimidad, y está bien para trámites particulares, personales, encriptar archivos, correos a familias y amigos… pero si una organización mundial, un gobierno, un particular o una empresa quieren garantizar que dicha clave pública pertenece sin lugar a dudas a quien dice pertenecer, es necesario un sistema más fiable. Es aquí donde aparece la “Autoridad de Certificación” (CA). Se van a continuar firmando los certificados sí, pero no por cualquier persona o grupo de ellas. Un certificado Digital asocia una serie de datos personales a una clave pública, y será un tercero, llamado Autoridad de Certificación, quien garantice que esos datos corresponden a dicha clave pública. Visto de otro modo, se trata de eliminar todas las firmas y sustituirla tan solo por una, una entidad, empresa, gobierno… cuya firma tendrá mucho más valor que cualquier otra, dado que posiblemente se ha encargado previamente de verificar y asegurar que los datos son correctos.

Los CA de máximo nivel se les llama CA raíces o root. Existen CA que delegan autoridad a otros CA secundarios para permitirles otorgar y firmar otros certificados. Esto se debe a la cadena de confianza. Yo como máxima autoridad certifico a una empresa como CA secundaria de la cual tengo plena confianza, permitiéndole emitir y firmar certificados a ellos mismos. Si cualquiera quiere verificar un certificado emitido por un CA secundario o terciario, se realizará una verificación ascendente, primero al CA superior, el certificado de dicha CA se verificará por el CA por encima… hasta llegar al CA raíz, el cual emite él mismo su propio certificado.

Los CA son los que emiten los certificados, y al firmarlos les otorgan plena legitimidad dado que todos nos fiamos de ellos, dado que son la máxima autoridad de certificación. Podemos decir que los CA son también esas bases de datos de claves públicas/certificados de cada usuario. Pero el CA no es la única autoridad que existe. Por otro lado suele ser necesaria (no obligatoria) la presencia de la “Autoridad de Registro” (RA). El papel de un CA puede acabar aquí, y encargarse tan solo de la emisión y firmado. Muchas veces cuando se desea cotejar/verificar si un certificado es correcto, es el RA quien se encarga de verificar dicho certificado, siendo él el que conecta con el CA. Otra figura menos usada es la “Autoridad de Validación” (VA), la cual tendría un papel similar, verificar si el certificado es válido atendiendo a fechas de tiempo y otros datos. Aun así, como digo, lo normal es ir unificando las autoridades de verificación, y de paso las comunicaciones son más eficientes. Así el mismo CA actúa como RA y como VA. Hace unos años los CA raíces eran muy pocos, lo que hacía muy útil estas autoridades intermedias. Cada vez son más los CA raíces y los sistemas más eficientes, siendo innecesaria la presencia de otras autoridades intermedias. Muchos de los lectores conocerán el nombre de algunos de ellos, actualmente el listado de CA raíces debe de rondar las 90 entidades (sin contar con los CA estatales, como CA de países, aunque estos no suelen considerarse como “universales”. Entre ellos los más importante con diferencia son: VeriSign, Thawte, GoDaddy, GeoTrust, RSA Security Inc (la empresa)…

En los tiempos actuales, no es raro ver como gobiernos, grandes instituciones o multinacionales están considerados también como CA, lo que sucede es que normalmente estos CA no emiten certificados a cualquier persona. Por ejemplo, el gobierno español tiene al menos dos Autoridades de Certificación, la FNMT (certificados CERES) y La dirección General de Policía (Certificados para el DNI-e). Pero estas dos instituciones tan solo emiten certificados a los que tenemos nacionalidad española. Otro ejemplo de esto podría ser Intel o Microsoft. Ambos están considerados como CA raíz, pero no se dedican al negocio de los certificados digitales. Esto le permite a estas grandes multinacionales no depender de terceros, ahorrar costes y gestionar ellos mismos sus propios certificados, aunque evidentemente tan solo usan dichos certificados para ellos mismos, sus servidores, sus empleados quizás… por eso podemos dividir estos dos grandes grupos como aquellos CA comerciales y aquellos que no lo son.

Con esto, el esquema anterior PKI se modifica ligeramente y es el CA, el RA o el VA quien valida o garantiza la legitimidad del certificado.

Hay que destacar que no existen dos certificados, uno que sea público y otro que sea privado. El certificado es tan solo el vehículo de la clave pública. Es cierto que los certificados personales almacenados en el equipo se “guardan” con la clave privada junto a este, lo cual es completamente lógico, puesto que sin clave privada no podríamos firmar o desencriptar. En realidad esto no es del todo cierto, dado que las claves privadas de estos certificados suele estar guardadas en un anillo de seguridad del sistema/equipo. Esto no obstante ocasiona un problema de seguridad importante dado que si alguien se hace con la clave privada, el sistema quedaría completamente expuesto. Es por ello que cuando se requierer una seguridad avanzada, tanto certificados personales como las claves privadas, jamás serán almacenados en un equipo, sino en soportes extraíbles como un pendrive (en el peor de los casos) o una SmartCard (Tarjeta Inteligente) en el caso ideal, o incluso un dispositivo TPM. Esto quiere decir que nuestra clave privada residirá en nuestro DNI-e o tarjeta CERES o… protegida además por un PIN por si es extraviada o sustraída. Cuando se requiere su uso es necesario un lector de tarjetas y el software adecuado para tomar de esta la clave privada y el certificado.

El Certificado no solo indica el nombre y apellido de quien representa, sino que incluye información del CA que lo ha emitido, algoritmos de cifrado y hash que usa, fecha de revocación, validez, tipo de certifiado… toda esta información es necesaria. Por ejemplo el certificado de identificación o cifrado de un servidor no tiene nada que ver con un certificado de cliente que podamos usar nosotros, o el certificado raiz de un CA es diferente a los otros dos. Por otro lado no todos los certificados se emiten para todos los propósitos. Lo normal es emitir los certificados con ciertas características. Por ejemplo, si se desea usar un certificado para cifrar correo electrónico será necesario que el certificado especifique una dirección de correo, y este certificado quedará anclado a él. Otro buen ejemplo es un certificado con unas características concretas para el control de acceso de una empresa o para cifrar datos en un equipo. Así, nuestro DNI-e por ejemplo tiene dos funciones principales, autentificación y firma (hablaremos más detenidamente del DNI-e en otro capítulo).

Vamos a ver unos certificados de ejemplos: Un certificado de un servidor para SSL/TLS (Gmail), un certificado CA raíz (VeriSign) y un certificado personal para identificación SSL/TLS, firma y cifrado de correo que no de datos (Mi Certificado CERES):

Hay que decir que estos datos son totalmente públicos, cualquiera que acceda a gMail o descargue el certificado de gMail podrá verlo. Firefox divide el certificado en dos pestañas. La primera es un resumen sobre el emisor, a quien representa y si el certificado es válido para los propósitos marcados (en este caso el propósitos es para un servidor SSL). Recordar que cada vez que un certificado es usado, lo normal es verificarlo. ¿Cómo? Verificando la firma de la entidad firmante. Podemos ver en la primera pestaña que el emisor es Thawte (que es el CA de dicho certificado), que está a nombre de Google Inc para la web mail.google.com (gMail). Se puede ver también la fecha, que aunque no hemos hablado de ella es importante, ya que cuando se emite un certificado este suele tener un tiempo limitado. Tras el cual, el certificado pasa a ser revocado (anulado) y se emite otro (normalmente antes de que expire) con nuevas claves privadas y públicas, esto se hace por seguridad evidentemente.

La segunda pestaña desglosa completamente el contenido del Certificado. En caso de este certificado, Firefox nos muestra en la parte superior la jerarquía de CA que intervienen en dicho certificado, es decir la cadena de confianza. Así, el certificado de google para mail.googl.com es emitido por el CA “Thawte SGC CA”. Este CA no es un CA raíz, sino un CA secundario. El certificado de este CA a su vez es el que ha sido emitido por el CA raíz “Verisign Class 3 Pubblic…”. Por último se muestra la clave pública contenida en dicho certificado.

 

El primer certificado pertenece a un certificado raíz de VeriSign, el mismo que estaría arriba del todo del certificado de gMail para la web. En este caso el uso que se indica es el de “Status Responder Certificate”. Es decir, tan solo es usado prácticamente para atender a las peticiones OCSP que pueda recibir de sus CA secundarios, es decir… verificar si los certificados están o no revocados. En este caso no se considera un CA dado que el papel de verificación de CA lo realizará el CA que esté a su servicio. Este certificado raíz fue el que emitió/validó el certificado de “Thawate SGC CA”, y es este último quein actuó realmente como CA del certificado de mail.google.com. El certificado CA intermedio será por tanto realmente el que en su descripción de uso rece: “SSL Certificate Authority”, puesto que el certificado Raíz tan solo atiende a peticiones de revocaciones. Se puede observar que efectivamente es un certificado raíz dado que el emisor (Issued By) y el destino del certificado (Issued to) no se encuentran presente, es él mismo emisor y destino, está firmado por él mismo.Si vemos la fecha por otro lado de expiración, vemos un intervalo muy grande, un certificado ahora con más de 14 años de antiguedad, que usa un algoritmo de hash MD2, un hash ya muy antiguo.

Por último tenemos un certificado de CERES. He preferido poner este en vez del DNI-e porque este es más útil, tanto y cuando además de poseer las características de autentificación en internet (Cliente SSL), permite también la firma de correo (Email Signer) y su Encriptación (Email Recipient). Podemos ver que el emisor es la FNMT, y dado que mi navegador tiene instalado el certificado Raíz de estos y considerado fiable, el certificado de CERES lo es también, podemos leerlo arriba: “This Certificate has been verified…” Por motivos de seguridad he eliminado mi nombre, DNI y esas cosillas.

 

Firma Digital

En realidad poco más o menos ya se ha comentado que es y cual es su utilidad. Cuando explicábamos una PKI, exponíamos que cada clave pública se “votaba” para que los otros usuarios pudiesen así garantizar que era legítima. Esto es realmente una firma. Una firma tiene la característica de no repudio, es decir, una vez se ha firmado algo un usuario o una entidad no puede desquitarse de ello, dado que la firma lo identifica a él de forma irreversible, sin que este pueda negar que lo ha hecho.

Las firmas digitales usan de forma conjunta dos tecnologías, la inviolabilidad de un sistema de cifrado asimétrico tipo RSA y la integridad de datos que ofrece un Hash criptográfico como SHA-1 o MD5. Si un usuario desea cifrar un documento o un mensaje para que tan solo podamos ser capaces de descifrarlo nosotros, tan solo tiene que cifrarlo con nuestra clave pública, y tan solo nosotros poseedores de nuestra clave privada podremos descifrarlo. Pero esto puede usarse de manera inversa. Si yo cifro algo con mi clave privada, la clave pública lo descifra. Dado que todos tienen acceso a mi clave pública, todos pueden descifrar aquello que yo cifre con mi clave privada. ¿Pero entonces para que vale esto? Porque un certificado garantiza la asociación de una clave pública a una persona física. Luego quien descifre algo con mi clave pública obtendrá un contenido que tiene la certeza fue cifrado solo por mí. Y por parte del Hash, otorga integridad al mensaje. El proceso es simple:

a) Se calcula un Hash criptográfico al mensaje, documento… a firmar, por ejemplo un Hash SHA-1.
b) Ahora se encripta por medio de nuestra clave privada dicho Hash, lo cual obtenemos un Hash cifrado.
c) A partir de este momento, al documento se le incrusta (adjunta) la firma. El destinatario, se topará con que existe una firma de dicho documento, con su certificado público correspondiente, y por supuesto con las validaciones pertinentes. El destinatario puede descifrar el hash y obtener el Hash que aseguró el remitente que era el idóneo. El destinatario calcula el mismo Hash al mensaje recibido. Si los dos Hash coinciden, el destinatario comprende que el mensaje es legítimo y que no ha sido modificado de ningún modo.

Una forma digital puede usarse para varias tareas. Por ejemplo, evidentemente como sustituto natural de nuestra firma física. No obstante ya hemos hablado que se usa para los certificados. Los certificados que nos emiten los CA deben de estar firmados por estos. La firma de estos en nuestro certificado funciona del mismo modo. Cuando se verifica un certificado, entre otras cosas como comprobar la fecha de validez o las listas de certificados revocados, se verifica que la cadena de confianza es correcta. ¿Esto que implica? Ir verificando uno a uno todos los certificados implicados en un certificado. Esto es verificar la firma del firmante de nuestro certificado, lo cual para ello es necesario verificar que el certificado de este CA está firmado por otra CA que sea igualmente válido… así hasta llegar al CA raíz. Si en cualquier lugar de la cadena falla la verificación, la cadena entera se rompe y el certificado no puede garantizarse como seguro.

Otro uso común es la firma de un código. Esta es una práctica cada vez más expandida en el mundo del software. Un método de proteger un sistema operativo frente a ataques, como pueda tener Windows Vista o Windows 7, es que los drivers deben de estar firmados obligatoriamente por Microsoft (en este caso), de forma que esto garantiza que los drivers no son dañinos y son legítimos. Esto puede verse también en las partes más críticas del sistemas, en las que los archivos o el contenido más sensible para el correcto funcionamiento del sistema se firma de forma que el propio sistema no permite su ejecución si la firma no es válida. El problema que ocasiona esto no obstante es que se puede hacer un uso intensivo de esto para evitar la libertad. Por ejemplo el iPod Touch/iPhone, en el que cualquier contenido que se desee ejecutar, debe de estar obligatoriamente firmado por Apple, si no lo está no se puede ejecutar. Esto implica que (sin JB) tan solo las aplicaciones aprobadas del AppStore pueden ser usadas, al margen de que pudiese ser posible o no instalar otro tipo de aplicaciones, al margen del degradamiento de rendimiento por tener que estar continuamente verificando las firmas. Desde mi punto de vista la diferencia del buen uso y el abuso es la intencionalidad. Proteger con una firma una bios o un bootloader tiene un sentido muy simple, es una parte crucial del sistema y cualquier virus o modificación dañina produciría que el sistema sea inutilizado, lo cual implica que es positivo. Pero debería de ser una opción, no una obligación. Por ejemplo, se dijo mucho sobre los drivers de Windows x64 y que nadie podría crear drivers para ellos dado que todos tienen que estar firmados por Microsoft. Esto no es tampoco tan así. Se pueden instalar drivers firmados por uno mismo si se quiere, lo que pasa es que el sistema nos advertirá sobre la procedencia del certificado y categorizará el driver como no seguro, avisándonos del peligro que ello implica. Pero a fin de cuenta la libertad es del usuario.

Lo habitual por tanto es ver una firma digital como un documento adjunto en un correo (extension p7s), incluida en el mismo cuerpo del mensaje en el caso de usar PKI como PGP/GPGo como un “añadido” a un documento. Al final del todo veremos aplicaciones prácticas de todo ello de todas estas cosas. De cara a un gestor de correos o cualquier otro programa que acepte contenido firmado, simplemente sabrá como interpretarlo y verificar dicho contenido.

 

Visto todo esto podemos hacernos una imagen de lo que es un certificado digital y la firma electrónica:

a) Ana descarga el certificado de Carmen, lo ha descargado del servidor LDAP de la empresa (o de la web de Carmen). Al instalarlo en su equipo (y sin que ella lo sepa) el certificado de carmen es comprobado. Dado que el certificado de Carmen está firmado por VeriSign, el equipo de Ana tan solo tiene que verificar que la firma de VeriSing es válida. Dado que el certificado raiz de VeriSign está incluido en el equipo, el equipo de Ana desencripta la firma de Verisign del certificado de Carmen con la clave pública que se encuentra en el certificado raiz de VeriSign. El equipo de Ana obtiene así el Hash del certificado de Carmen, el cual coincide a la perfección con el propio certificado, luego Ana está convencida de que el certificado que tiene en su poder es sin duda el de Carmen.
b) Ahora que Ana está convencida, redacta el mensaje y lo encripta con el certificado de Carmen y lo firma con su clave privada. Lo envía a Carmen.
C) El mensaje llega a Carmen y lo primero con lo que se topa es la firma. El gestor de correo busca la clave pública perteneciente a dicho correo electrónico accediendo posiblemente al repositorio del CA emisor y el nombre y apellidos de Ana. Carmen no se fia de que sea Ana, pero el certificado que ha encontrado efectivamente tipifica dicho correo electrónico y dichas credenciales, y está emitido y firmado por la FNMT (se verifica la firma de la FNMT, que a su vez verifica el certificado de Ana). Cuando está seguro del certificado de Ana, desencripta la firma con él, dado que la clave pública de Ana desencripta el hash que fue encriptado con la clave privada de esta. Carmen verifica la firma y con su clave privada desencripta el mensaje y lo lee.

Seguridad: Encriptación y Autentificación. Capítulo Segundo -> Cifrado de Datos

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Cifrado de datos

Este no es un término nuevo, y desde tiempos inmemorables es algo que se ha ido haciendo de un modo u otro. Y es que seamos honestos… no nos suele gustar la idea de que puedan invadir nuestra intimidad o interceptar cartas, mensajes, ideas… que van hacia otra persona. Evidentemente esto toma una importancia mayúscula cuando esta información es sensible o de suma importancia. Quzás el primer gran ejemplo de criptografía en el ámbito de las comunicaciones fue sin duda la máquina Enigma.

Para quien no lo sepa, la máquina Enigma fue un dispositivo similar a una máquina de escribir diseñada allá por los años 30, siendo famosa por ser usada por los Alemanes durante la Segunda Guerra Mundial. Era un dispositivo creado con inteligencia. Digamos que poseía tres discos con 26 posiciones cada uno. En cada una de esas posiciones se mapeaba una letra. Cada letra de cada disco a su vez se encontraba conectada con el disco vecino, y dependiendo de la posición inicial de cada uno de los discos, la letra era mapeada de disco en disco en una o en otra. Se diseñaba de tal modo que al presionar una tecla de la máquina, esta quedaba asociada con una letra mapeada del primer disco. En el primer disco la letra se mapeaba a la letra de salida del primer disco (que no correspondía a la de entrada) y en dicha salida se conectaba el segundo disco. El segundo disco tomaba de entrada la salida del primer disco e igualmente que como hacía este, internamente esa letra de entrada la mapeaba a la salida. El tercer disco hacía lo propio, tomaba la letra de salida del segundo y según su posición en dicho momento la transformaba en otra diferente a su salida. Despues de todo esto, un 4 disco (no obligatorio) hacía que existiese un camino de retorno, de forma que se pasase de nuevo por el tercer disco, despues por el segundo y después por el primero. La salida se conectaba a una bombilla que indicaba la letra codificada. Para evitar separaciones de palabra, todo el mensaje era enviado sin espacios.

Posiblemente fue la primera máquina seria para cifrar comunicaciones. Hay que decir que, según dicen, gracias a que la alianza fue capaz de desencriptar la mayoría de las comunicaciones de los alemanes (gracias a que pudieron romper en gran medida el sistema de Enigma) la guerra duró dos años menos de lo que podría haberse alargado. Un buen ejemplo sin duda alguna de criptología.

 

Para nosotros es cosa del pasado. Vivimos en un mundo digital y un mundo en el que las comunicaciones juegan un papel a día de hoy imprescindible. Por lo tanto es de sentido común que existan sistemas que podamos considerar seguros tanto para almacenar datos de forma protegida como para ser capaces de crear canales seguros de comunicación entre dos puntos cualquieras del mundo. Precisamente porque las comunicaciones se han convertido en algo imprescindible y de uso constante, no podemos hacer oídos sordos y pensar erróneamente que nuestros datos no son de la importancia de nadie. Dado que los canales de los que hacemos uso son públicos, nuestra información, nuestros datos están expuestos a todos. Puede que a nadie le importe que otros puedan saber en un momento dado en que blog escribe, que vean las fotos que tienen guardadas o las recetas archivadas. Pero seguro que a nadie le gustaría que humeen en su correo, en sus cuentas bancarias, en todo aquello que pueda ser de índole personal. Lo que pasa es que se presupone que todo es seguro y que no existirá nunca una intervención externa… y esto no es así. Como vimos con el Spoofing o como veremos en otros artícuos como el Sniffing, la intención rara vez encaja con la realidad.

Por todo ello vamos a introducirnos un poquito en los sistemas reales de protección que podemos encontrar a día de hoy. Y digo reales porque posíblemente gracias tan solo al cifrado de datos es posible garantizar una intimidad a la cual tiene derecho todas las personas. No vamos a estudiar la máquina enigma de ningún modo, vamos a ver los dos sistemas de cifrado que disponemos en la actualidad, cada uno con sus pros y sus contras, claro está:

  • Cifrado Simétrico
  • Cifrado Asimétrico

 

Cifrado Simétrico

Un cifrado simétrico no es más que algún sistema por el cual se encripta un contenido aplicándole una clave (o key, del ingles llave) y se desencripta usando la misma clave. Podemos pensar de un modo más específico en una contraseña, pero esta no es más que una particularidad de un cifrado simétrico. Por ejemplo, la máquina enigma era un dispositivo de cifrado simétrico, en el que la key era la posición inicial de los discos y el cableado interno que mapeaba las teclas a los discos. Se usaba por tanto la misma disposición si se deseaba recuperar el mensaje original. En la era digital, nuestras key suelen ser lo que comunmente llamamos “contraseñas”, aunque no todas las contraseñas son para cifrar. Así por ejemplo llamamos contraseña a la cadena de caracteres que debemos de teclear para poder encriptar un documento, pero también llamamos contraseña a la cadena de caracteres que debemos de teclear para acceder a nuestro correo, y no se usa en modo alguno para cifrar nada, solo como método de control de acceso. En cualquier caso, esta key (no usaremos el termino “contraseña”) en los cifrados simétricos sería la misma para encriptar un dato que para desencriptarlo.

Como vimos en su momento con los Hash, podríamos suponer que con el cifrado simétrico lo que sucede es algo similar. A un dato de entrada se le aplica una función que depende de una key para producir una salida. Pero a diferencia de los hash, la encriptación no es un camino único, es decir, la salida puede convertirse bit a bit exactamente igual a la entrada cuando el mensaje se desencripta. Esto implica que la función que sea aplicada a la entrada no será sino una serie de modificaciones que se realizarán a los datos de entrada para ocultarlos. Esas modificaciones dependerán íntegramente de una key.

Según el sistema usado por el sistema de cifrado, se puede clasificar dos tipos de cifrados simétricos: Cifrado de bloques y cifrado de flujo. Pese a que pueda ser más o menos complicada la matemáticas detrás de cada algoritmo de cifrado, no lo es tanto comprender su funcionamiento.

 

Primero veamos el cifrado simétrico de flujo. El cifrado de flujo se pensó idealmente para aquellas tareas en las que se desea cifrar algo que se está generando en tiempo real. Es decir, en un principio pensado para las comunicaciones. Esto tiene su lógica, si deseamos encriptar un archivo de 20MB en disco por ejemplo, conocemos a priori no solo el tamaño completo del archivo, sino también cada uno de sus byte. En cambio cuando los datos a transmitir son en tiempo real (por ejemplo) el modelo anterior no vale, tan solo podemos ir codificando pequeños fragmentos de un todo, fragmentos tan pequeños como bytes o incluso bits. Es decir, cada byte (por ejemplo) que se genera, se encripta y se envía. El fragmento enviado por tanto tiene significado propio, puesto que aunque pertenece a un todo, el mismo byte (en este caso) se desencripta directamente en el destino.

Pese a la complicación que esto pueda parecer, es relativamente simple en concepto. La idea es poder cifrar unidades mínimas de contenido sin que estas dependan de nada más. Pero esto crea un problema… Si la misma key fuese usada para todos los bytes, sin siquiera conocer la key sería muy facil atacar un cifrado en flujo, dado que las unidades codificadas son muy pequeñas, sería fácil encontrar mensajes o partes de estos, patrones… Para evitar esto lo que se hace con los cifrados de flujos es generar también un flujo constante de keys. Esto suena raro… el algoritmo de cifrado simétrico de flujo aplica una serie de operaciones matemáticas “seguras” para generar a su salida un flujo constante de bits, no predecibles claro está, que a su vez son los que son usados para cifrar a su vez el flujo de datos. Vamos a ver un ejemplo sencillo de esto aplicando posiblemente uno de los cifrados más básicos que existe, el cifrado XOR. XOR es una operación lógica que dice lo siguiente:

style=”text-align: justify;”>Si A = B => A XOR B = 0. Es decir, se puede expresar como A XOR A = 0
style=”text-align: justify;”>Si A != B => A XOR B = 1. Es decir, se puede expresar como A XOR 0 = A

Al igual que con los hash, imaginemos una función tal que F (key) = Kflujo

Si tenemos lo anterior en cuenta, ahora imaginemos dos flujos de datos constantes de bits:

Datos para Enviar Mensaje XOR Key Datos Enviados
Mensaje Original: 10100111 0 1011001
Kflujo: 11001011 1 1100100
Mensaje Final: 10100111 1 0111101

Es decir, el flujo constante de datos a enviar se combina mediante una operación XOR con un flujo de datos constantes también generado por una Key inicial gracias a un algoritmo dado. El receptor en nuestro ejempli tan solo tendría que generar el mismo flujo de datos desde la key original y aplicar la misma operacion XOR a los datos recibidos, de ese modo el mensaje original se reconstruiría. De este modo, a partir de un cifrado simple y lleno de problemas como pueda ser un cifrado XOR, se logra que sea consistente gracias al flujo constante de bits derivados de la key original.

No obstante, por regla general los cifrados en flujo son mucho menos robustos que los cifrados en bloques, y estos a su vez pueden actuar como cifrados en flujos, lo que poco a poco deja a los cifrados simétricos de flujo en desuso. No obstante, a día de hoy continúan siendo una fuerte columna vertebral de las comunicaciones, siendo su buque insignia el cifrado RC4. Aunque es un cifrado que ya no podríamos considerar seguro dado a los ataques pertrechados hacia él con relativo éxito, continúa siendo un cifrado extremadamente simple de implementar y de procesar, lo que lo hace ideal para tareas en las que la seguridad a lo mejor no es crucial, pero si importante. Por ejemplo, RC4 es el cifrado que usan las redes WIFI que usan WEP, el algoritmo de cifrado es RC4, y como todos sabemos WEP es un sistema a día de hoy completamente roto. Otros ejemplos de RC4 fue su uso (cada vez menos habitual) en certificados digitales (ya veremos esto más adelante). Y posiblemente los amantes de las redes Torrent podrán ver en muchos de sus clientes la opción de cifrar todo mediante RC4. Como vemos, aunque no nos otorga un grado de seguridad completo, para muchas tareas es bastante útil. En la actualidad existen otros cifrados de flujos más seguros que RC4, como por ejemplo las alternativas eStream. Personalmente no creo que vuelvan a ponerse de moda los cifrados en flujos, y que se continuará con la tendencia de los cifrados en bloque.

 

El cifrado simétrico en bloques difiere en concepto del cifrado en flujo. En este caso no se pretende a priori cifrar bit a bit un contenido, sino aplicar a un bloque de un tamaño preestablecido una serie de transformaciones (evidentemente reversibles) para dar como resultado una salida encriptada de dicho bloque. La pregunta podría estar entonces, que si dicho bloque es pequeño y el cifrado de flujos actúa sobre unidades “grandes”, ambos conceptos podrían ser iguales. Y esto es cierto.

En el caso del cifrado en flujo lo importante es la forma en la que se generará el flujo de keys y el sistema que se realizará para “combinar” los dos flujos. Aquí el sistema es mucho más complejo y sólido normalmente. Normalmente un mensaje que se quiere cifrar es dividido en bloques (de ahí su nombre) de tamaños de 64-256 bits cada uno. Lo ideal por tanto es siempre encriptar un contenido que sea cientos de veces dicho número, con lo que se tendrían cientos de bloques independientes. Cada bloque suele funcionar del mismo modo, las mismas operaciones que se aplican a uno se aplican a otro. No obstante, al igual que sucediese con los cifrados de flujo, lo normal es que la key original tan solo sea key del primer bloque, siendo la key del resto de ellos una key derivada ya no solo de esta, sino del contenido encriptado, lo cual hace ya de por sí complicada su “búsqueda”. La diferencia por lo tanto entre los diferentes cifrados de bloques radicará en esas transformaciones realizadas dentro de los bloques para obtener el resultado.

Normalmente, a estas transformaciones se les denominan “Etapas”, y no es extraño ver cifrados de bloques con varias de ellas. Por ejemplo el Cifrado AES consta de entre 10 a 14 etapas, dependiendo de la longitud de su Key. Al final de todas las etapas de cada bloque, se genera el mensaje cifrado, que en contraposición con el cifrado de flujo, aquí normalmente cada bloque cifrado es dependiente de todo su bloque, no existe una correspondencia bit cifrado – bit descifrado.

Pese a que cada algoritmo es diferente, los cifrados de bloques igualmente tienen diferente modos de operación. Cada uno de ellos no difieren por el tipo de transformaciones aplicadas, sino más bien por las interacciones entre sus bloques. Así por ejemplo, el sistema más sencillo de cifrado por bloques sería aplicar a cada bloque una función matemática tipo Fbloque(Key) = Bloque_Cifrado. Es decir, a cada bloque se le aplicaría siempre la misma key de forma independiente. Este esquema se contempla, y se llama sin ir máss lejos ECB.

Un paso más allá sería algo similar a lo que se ha visto con el cifrado de flujos. En este caso cada bloque no es independiente. En el modo CBC el bloque cifrado se combina mediante una operación lógica XOR con el bloque aun sin cifrar del siguiente bloque, y el resultado será el bloque que, ahora sí, se pasará a cifrar. De este modo simple, se logra una dependencia completa de cada uno de los bloques, haciendo inviable muchos ataques criptográficos.

Aunque existen otros sistemas de funcionamiento de los cifrados de bloques, la mayoría aplican el concepto explicado para CBC (Cifrado de bloques en cadena) pero en diferentes partes. Por ejemplo, se podría realizar la operación XOR en vez de entre el bloque cifrado y el bloque siguiente sin cifrar entre el bloque sin cifrar y el bloque cifrado de un mismo bloque y realizar a continuación otra XOR con el bloque sin cifrar siguiente, y a esto se le llamaría PCBC.

 

Estos modos de funcionamiento que pueden parecer no tener importancia, la tienen y mucha. Un test bastante conocido para comprobar la resistencia de un sistema de cifrado frente a la posible repetición de patrones, es la codificación de una imagen. Una imagen suele tener patrones que se repiten constantemente, es decir, en una imagen suelen existir zonas uniformes que pueden tener el mismo contenido. Luego una imagen es un ejemplo perfecto para atacar a un cifrado. ¿Como se realiza esto? Una imagen no son más que puntos distribuidos uniformemente sobre toda una superficie, cada cual con un color. Si quisiésemos almacenar una imagen en nuestro sistema, el método más simple sería simplemente tomar cada punto de la imagen de forma consecutiva e ir añadiéndolo a un archivo binarios simplemente especificando su color. Esto se comprende mucho mejor con un ejemplo. Pensar en que tenemos una imagen de 5 x 5 pixeles, cada uno de los pixeles está codificado en RGB con 1 byte para cada canal, es decir, que cada punto se representaría en una matriz de (5×3)x5 en la cual cada elemento constituye un byte (un valor entre 0 y 255) . Esta podría ser nuestra imagen expresada como una matriz de puntos:

128 045 135 236 002 237 112 222 012 087 158 255 000 055 099
128 045 135 236 002 237 112 222 012 087 158 255 000 055 099
128 045 135 236 002 237 112 222 012 087 158 255 000 055 099
128 045 135 236 002 237 112 222 012 087 158 255 000 055 099
128 045 135 236 002 237 112 222 012 087 158 255 000 055 099

En un archivo binario esto se almacenaría simplemente un valor tras otro. Para visionar dicha matriz de puntos tan solo tendríamos que conocer esta distribución y aplicarla a la pantalla de nuestro monitor. Sabemos que es una imagen de 5×5 con 3 canales de color, con lo que el PC tan solo debería de tomar los valores de 3 en 3. Cada 3 valores obtendrá el color de cada pixel, y su ubicación dentro de la matriz corresponderá a la ubicación del pixel en la pantalla. Este sistema no obstante no puede aplicarse a los algoritmos de imágenes actuales como JPG, PNG, TIFF… ya que estos de un modo u otro aplican compresión a las imágenes (ya sea con pérdida o sin ella), y no se podría comprobar lo que queremos explicar. Podríamos llamar a esto una imagen RAW, el problema de llamarlo así sería la confusión que ocasionaría con las imágenes RAW de las cámaras de fotos.

Visto esto, veamos la aplicación real. Primero partiremos de una Imagen RAW Fuente creada para tal ejemplo a la que he llamado egocéntricamente “Theliel”, “Alma Oscura” era muy largo para este propósito:

Evidentemente la imagen mostrada aquí no es una imagen RAW (Entendiendo RAW no como imagen de las cámaras de fotos), es una conversión a png para que el navegador pueda mostrarla. ¿Pero que es lo que sucede cuando la codificamos con un algoritmo como AES-256 (el cual veremos más adelante)? Para ello se ha realizado dos simples conversiones, una usando el método ECB y otra usando el método CBC:

La primera pertenece a la codificación ECB, mientras que la segunda imagen corresponde a la codificación CBC. Ambas imágenes hablan por si mismas. Si se accede a las versiones grandes, se puede comprobar aun mejor que incluso cuando se está codificando con AES-256 (un cifrado muy fuerte), cuando se realiza en ECB la imagen puede ser adivinada, incluso el texto es completamente legible. La imagen no es del todo clara, pero se puede apreciar perfectamente el contorno de la manzana de Apple. Esto nos plantea lo que a mi parecer es uno de los grandes problemas de la seguridad, y es que el problema no radica ya en encontrar sistemas que sean seguros, sino en el uso que se den de ellos. Que exista el método ECB no implica que sea una buena opción usarlo. El resultado de un cifrado en ECB de cada bloque es el mismo si el bloque a encriptar no varía. En una imagen, no es raro encontrar estos patrones, y dado que podemos representar de una forma gráfica esta encriptación, obtenemos un resultado realmente curioso, como el que hemos mostrado. En contrapartida, al usar CBC, cada bloque tenga o no tenga la misma información, será codificado de forma diferente, dado que la codificación de cada bloque depende del anterior. El resultado es una nube de píxeles de colores sin sentido alguno, quedando la imagen real completamente oculta.

Los cifrados de bloques según lo explicado, no obstante deja algunas incógnitas como que sucede cuando el contenido a cifrar no corresponde a un tamaño múltiplo del tamaño de bloque o que sucede con aquellos bloques que requieren de un bloque anterior (o posterior) y no lo poseen dado que son el primero o el último.

Respecto al primer problema, el tamaño de bloque, se acude a una técnica mas que conocida por la mayoría de los programadores, el Padding. Es decir… rellenar. Si los bloques son por tanto de 64bits y el último bloque tan solo tiene 32, los 32 bits restantes se rellenarían. Esto hace a su vez aparecer un problema añadido… la salida tendrá un tamaño siempre mayor que la entrada, dado que será necesario añadir tantos bits como sea el caso para poder completar el bloque. Y el segundo problema que aparece es con que datos rellenar ese Padding, lo que produce a su vez que sea complicado esclarecer el tamaño REAL del mensaje original. Para esto existen diferentes técnicas más o menos elaboradas, pero decir al menos que rellenarlo todo con simples carácteres “null” (nullo) no sería recomendado.

Respecto al segundo problema, lo normal es que exista una entrada adicional a la Key y al contenido a cifrar en el sistema, que se denomina como vector de inicialización (IV). No obstante, dado que estos vectores no pertenecen al algoritmo dado y normalmente no es dado tampoco como dato de entrada, lo normal es que la propia implementación del algoritmo lo establezca. Otra solución sería no usarlo o suponer que de no expresarlo, el vector de inicialización será una cadena de ceros.

No han sido pocos los cifrados de bloques que han existido y existen. Muchos de ellos buscando siempre ser el mejor en cuanto a seguridad se refiere, otros por ser los más rápidos, otros por ser mejores en otros fines… y se llegó al absurdo de que existían un sin fin de cifrados de bloques que eran usados. Todo ello por supuesto sin contar con el secretismo. Antes se pensaba que cuanto más secreto fuese un cifrado, más invulnerable era. Esto parecía lógico, si nadie sabe como se implementa o como funciona, lograr desencriptarlo sería complicado. El problema no obstante es que un millón de cabezas piensan más y mejor que unas cuantas cabezas de ingenieros que en su día crearon dicho algoritmo.

Así, posiblemente el primer cifrado por bloques que llegó a convertirse en un estándar y publicado como tal fue DES (Estandar de encriptación de datos). DES contaba con una key de 56bits, bloques de 64 bits y un total de 16 rondas. Al margen de lo seguro o no que pudiese ser, hoy por hoy sería impensable un sistema de cifrado con key de 56bits. En el peor de los casos por simple fuerza bruta serían necesarias 256 comprobaciones, y con el hardware actual sería un valor fácilmente alcanzable. En 1998 se creó un hardware “barato” que fue capaz de obtener una key DES por fuerza bruta en tan solo 56 horas, aunque un año más adelante tan solo necesitó 22 horas. Esto hizo replantearse seriamente el uso de DES. Después de esto, se comenzó con el uso del sucesor de DES, llamado Triple DES, publicado en 1998 y que básicamente era igual a DES, pero usaba un conjunto de 3 Key DES de 56 bits cada una. En algunos esquemas estas Keys eran independientes, en otros eran keys derivadas. Y aun que a día de hoy se puede considerar Triple DES como seguro, la realidad es que en 2001 fue publicado oficialmente AES. Al igual que se hiciese con los Hash SHA, el período de estandarización de AES fue de 5 años. 5 años en los que compitieron los mejores algoritmos de cifrado de la época, algunos de ellos conocidos dentro del mundo de la criptografía: RC6, Serpernt, Blowfish… y por supuesto el ganador: Rijndael, que pasaría a ser llamado AES (Estandar avanzado de encriptación). AES se estandarizó con 3 longitudes de key diferente, así existe a día de hoy AES-128 AES-192 y AES-256, con un tamaño de bloque de 128 bits. No obstante, el algoritmo original permitía bloques de diferente tamaños y keys.

AES a día de hoy es completamente seguro. Tal es así, que el gobierno de EEUU aceptó el uso de AES-256 para su uso en su material clasificado como “Alto secreto” y AES-128 AES-192 para su material clasificado como “Secreto”. Es decir… actualmente y posiblemente por muchos muchos años, AES permanecerá como cifrado simétrico estandar y seguro.

El como funciona AES en realidad no es tan complejo si comprendemos el funcionamiento de los cifrados de bloques. Lo único que habría que conocer son las transformaciones que se realizan en los boques, esas 10-14 etapas que se llevan a acabo en cada bloque. En primer lugar lo que AES realiza es generar una subkey de bloque derivada de la key original e interpreta la hilera de bits del bloque (128 bits) como una matriz de 4×4 bytes (1 Byte son 8 bits, 4x4x8 = 128 bits). Una vez se ha creado la estructura básica del bloque, se aplica el cifrado XOR a la matriz entre esta y la subkey de bloque generada. Una vez realizada esta operación, se realizan una series de operaciones en la matriz, como desplazamiento de columnas, mezclado y otras operaciones no lineales. Para acabar se realiza de nuevo una operación XOR con la subkey que corresponda (diferente a la key de la primera XOR). La matriz resultado se envía como bloque cifrado en una sucesión de bytes.

Como vimos en el ejemplo anterior, AES-256 en realidad sí que es extremadamente seguro, pero es necesario siempre un buen uso de dichos cifrados. Para terminar un pequeño ejemplo de un esquema de codificación simétrica, mostrando muchos de los conceptos aquí tratados:


CrypTool 2 Beta


En el esquema se puede observar como existen tres elementos principales de entrada: El archivo a codificar llamado “Original”, la Key usada llamada “Key” y un generador aleatorio de IVs. Los bloques en azul claro corresponderían a los algoritmos de cifrado, en este caso se ha usado AES-256 ECB y CBC y DES ECB. Por último los archivos de salida generados de los procesos aplicados. Se observa no obstante que para los módulos AES no se ha usado una entrada IVs. Lo que sucede es que el vector de inicialización en este caso sería 0x0000000000000000 (8 bytes). DES por el contrario requiere que se incluya, por ello se ha usado un generador aleatorio de IVs, que no es más que un generador aleatorio de valores de 8 bytes en este caso, dado qeu DES requiere un IV de 8 bytes, es decir, del tamaño de cada bloque (64 bits). Cabe destacar que para la desencriptación del archivo cifrado DES sería necesario suministrar exactamente el mismo IVs, de lo contrario no sería posible recuperar el archivo original. Para esto, siguiendo el esquema, sería tan siple como incluir en la entrada del supuesto módilo de desencriptación DES otra salida del mismo generador de IVs.

El cifrado simétrico es seguro cuando se usa un algoritmo y sistema de cifrado correcto.

 

 

Cifrado Asimétrico

El cifrado simétrico es seguro, es cierto… pero estará siempre enfrentado a una serie de ataques que antes o después es posible que sean rotos. Y su principal desventaja no es esa… es la key. El cifrado asimétrico apareció como alternativa a ello. Pero vamos a ver primero la necesidad del cifrado asimétrico, sería absurdo crear un sistema que no tenga una utilidad.

Hemos dicho que el cifrado simétrico tiene dos problemas. El primero de ellos es que está basado en algoritmos de dos sentidos, es decir, prácticamente (por no decir todas) todas las transformaciones que sufre el bloque por las diferentes etapas son funciones invertibles que a través de la misma key se puede reconstruir el mensaje (dato) original. Esto implica que la fortaleza del algoritmo simétrico recaiga tan solo en las transformaciones algebraica que se realizan sobre el bloque. De ahí que prácticamente todos los cifrados simétricos que se han estudiado antes o después se descubren diferentes ataques a sus diferentes etapas. Por ejemplo, para AES existen ataques exitosos en versiones reducidas de este, es decir, AES con menos etapas. Si AES-128 posee 10 etapas, a lo mejor se ha logrado ataques que pueden considerarse una roptura (es decir, que son computacionalmente posibles) para versiones de 6 o 7 etapas tan solo. La idea de estos ataques es ir logrando cada vez más romper cada etapa, de modo que al ir añadiendo una etapa más, el coeste computacional pueda considerarse factible. Si se llega a obtener un ataque a AES-128 en el que el coste computacional obtenido sea de 280 (por ejemplo) se considerará una roptura, frente a 2128 posibilidades iniciales.

El segundo problema al que se enfrenta el cifrado simétrico es la Key. La key es necesaria tanto para cifrar un mensaje como para desencriptarlo. Esto implica que tanto origen como destino tengan que compartir dicha Key. Esto a simple vista puede carecer de importancia, pero esto quiere decir que si queremos realmente una seguridad decente, en el mejor de los casos tendríamos que tener una key diferente de comunicación con cada uno de los usuarios con los que deseamos entablar una comunicación segura, dado que no usaríamos nunca la misma key con otros usuarios, de ser así otros usuarios podrían leer los mensajes que eran destinados para otros. Esto provoca la necesidad de múltiples keys para cada usuario, lo cual es engorroso e inseguro, dado que la comodidad podría implicar usar la misma key en todas las comunicaciones y esto supondría un problema de seguridad.

 

El cifrado simétrico resuelve estas dos cuestiones. La primera de ella haciendo uso de lo que podríamos llamar “Matemática Imposible”. En el cifrado simétrico se logra un algoritmo de cifrado de un único sentido, el cual no es computacionalmente viable el invertirlo. Podemos decir así que existen en realidad dos algoritmos diferentes dentro de un esquema de cifrado asimétrico, un algoritmo que encripta y otro que desencripta. Y al contrario que sucede con las transformaciones o la álgebra aplicada a un algoritmo simétrico, en la criptografía asimétrica esta función suele ser mucho más simple, lo cual no implica que sea más rápida, todo lo contrario. Así por ejemplo el cifrado AES requiere de 10 etapas mínimas para completar el cifrado de un bloque, mientras que el el cifrado RSA esto se limita a una “simple” función, aunque lo que no es simple es la teoría y el cálculo de dicha función. Estas funciones se basan en la premisa de que es imposible invertirlas, así por ejemplo tenemos el problema matemático de la factorización (usado en RSA) y el del logaritmo discreto (usado en ElGamal). Vamos a basarnos por simplicidad y fácil compresión en RSA. Posiblemente hasta los niños más pequeños aprenden a temprana edad que es la factorización de un número. Factorizar un número no es más que encontrar sus factores, es decir, los diferentes números que lo dividen, es decir, aquellos números que al dividirlo dan como resto cero:

Factorización de 20: 1,2,4,5,10 ya que 20 mod 10 = 0 20 mod 5 = 0….

Todos sabemos factorizar un número, el problema radica en dicho método. El problema reside en que la única forma real de obtener los diferentes factores de un número (así como saber si dicho núnero es por ejemplo primo) radica en ir dividiendo dicho número por cada uno de los números desde el 2 (el 1 es factor de todos los números) hasta n-1, siendo n el número a factorizar. Si disponemos de un número relativamente pequeño como el 101, podemos simplemente ir dividiendo este por 2, por 3, por 4… hasta llegar al 99. En realidad a la hora de encontrar los factores no es necesario llegar a dicho número, tan solo es necesario realizar Raiz (n) operaciones. Es decir, en el caso que el número a factorizar fuese 101, en realidad tan solo sería necesario ir probando Raiz (n) = 10 aprox, es decir, después de 10 operaciones podríamos conocer si realmente 101 es primo: 101/2, 101/3, 101/4… 101/10. Esto podría parecer no tener complicación alguna, 10 operaciones podríamos hacerlas incluso a mano. ¿Pero que sucede cuando el número a factorizar es infinitamente mayor? Podríamos pensar que un PC actual podría manejarlo en segundos, pero esto no es así. Existen diferentes algoritmos que intentan dar una opción viable a la factorización sin necesidad de usar divisiones una a una, el problema es que estos algoritmos no son fiables al 100% ni mucho menos, produciendo lo que se conocen como falsos números primos. Aun así, cuando se manejan los números tan ingentes que pronto veremos, ni haciendo uso de estos algoritmos sería posible. Vemos por tanto en este caso, que la matemática detrás de la factorización es más que conocida, es sencilla, pero es computacionalmente imposible para grandes números.

Respecto al segundo problema comentado, la key, en el cifrado asimétrico no existe una sola key, sino dos. Una key se denomina como clave pública y la otra como clave privada. El concepto es simple. Cada una de las claves son complementarias y pueden ser usadas tanto en el algoritmo de encriptado como en el de desencriptado, es decir, lo que encripta una clave lo desencripta la otra. No hay que pensar en clave pública como clave para desencriptar, sino clave que se distribuye a todo aquél con el que deseamos entablar un canal seguro. A diferencia que el cifrado simétrico en el que es necesario una key única para cada canal de comunicación, aquí será la clave pública la que será usada para todos. Este concepto choca al principio, una clave que se da a conocer a todos. Por otro lado la clave privada será el mayor secreto para su dueño, y es aquí donde reside la vulnerabilidad desde mi punto de vista del cifrado asimétrico. Visto esto, es lógico asumir que el par de claves (privada y pública) deben de estar relacionadas de modo alguno, pero sin que pueda suponer un riesto el conocimiento de dicha clave pública.

Estas dos características hacen que el cifrado asimétrico sea a día de hoy posiblemente el sistema más seguro en cuanto a encriptación de datos, y ello puede verse diariamente. Todas las comunicaciones cifradas a día de hoy que requieren de una privacidad importante, están basadas de un modo u otro en cifrado de clave pública (o cifrado asimétrico). No obstante no todo son ventajas. El cifrado asimétrico para empezar requiere de una capacidad de computación muy superior a la del cifrado simétrico para realizar la encriptación o desencriptación, llegando a ser cientos de veces más lento. Por otro lado se requieren por regla general keys de una longitud muy superior a lo que es habitual encontrar en el cifrado simétrico. Por ejemplo AES-256 (Key de 256 bits) frente a RSA, que puede usar Keys de entre 1024-4096 bits. Aunque una Key de 4096 bits (512 Bytes) sea un tamaño irrisorio para las comunicaciones, nadie sería capaz de recordar jamás una clave de 512 caracteres. En contrapartida, con AES-256 (32 Bytes) por un lado no sería complicado recordar una frase de 32 caracteres, pero además no es necesario, dado que generalmente las subkeys usadas son generadas apartir de nuestra “clave” introducida. Pero en el cifrado asimétrico esto no funciona así, no existen keys derivadas, una para encriptar todo el mensaje, una para desencriptar todo el mensaje.

Este problema de keys grandes se une al echo de la necesidad de que una Key pública sea conocida. Si deseamos que alguien encripte un mensaje hacia nosotros, este mensaje deberá de cifrarlo usando nusetra key pública, luego dicho usuario deberá tener acceso a nuestra key pública. Del mismo modo si queremos responder a dicho mensaje, tendremos que o usar la clave publica de dicho usuario para encriptar la contestación o encriptar la contestación con nuestra clave privada, ya que el receptor dispondrá de nuestra clave pública para desencriptarlo o su clave privada. Para que esto pueda ser posible, hace ya mucho tiempo que se establecieron bases de datos de claves públicas, de modo que cualquier persona pued acceder a ellos de forma simple y conocer la clave pública de cualquier persona.

 

Posiblemente los dos algoritmos de cifrado asimétrico más conocidos sean como hemos dicho RSA y ElGamal. Cada uno de ellos se basa en una imposibilidad matemática y por comodidad vamos a explicar como funciona RSA a grandes rasgos.

RSA como hemos dicho se basa en la imposibilidad matemática de factorizar un número grande. El proceso no es muy complejo. Lo primero es generar las claves que serán usadas, tanto la privada como la pública:

  1. Tomar dos números primos, llamados ‘p’ y ‘q’, los cuales por seguridad se requiere que ambos tengan una longitud de bits similar, para garantizar en caso de un posible ataque el “peor de los casos posibles”, y por otro lado que puedan escaparse a los algoritmos conocidos de búsqueda de primos. Estos dos números es normal encontrarlos de al menos 512 bits de longitud, es decir, un número con más de 154 cifras.
  2. Se calcula n = p x q, y acto segido la función Phi de Eulerm definida como Phi (p x q) = (p-1)(q-1). La función Phi de Euler calcula el número de coprimos que existen a un número dado. dos números son coprimos si no tienen ningún factor en común salvo el 1. Es decir, aunque el 10 no es un número primo, el 14 es coprimo de 15, dado que tan solo comparten el factor común uno. Dado que tanto p como q son números primos (ta solo divisibles por 1 y por ellos mismos) poseerán cada uno un número p-1 y q-1 de coprimos cada uno.
  3. Se escoge un número ‘e’ que se encuentre entre en el intervalo 1 < e < Phi(p x q), de modo que e y Phi sean coprimos entre ellos. Si ‘e’ a su vez es primo mejor.
  4. Se calcula ‘d’ en la siguiente función: d x e = 1 (MOD Phi (pxq)). de = 1 MOD Phi(pq) es quizás el principal problema de comprensión en RSA. Esta función recibe el nombre de multiplicación modular inversa, y se calcula de forma simple gracias al método extendido de Euclides. En realidad es tan solo matemáticas aplicadas. NOTA: Los “Iguales” que son especificados en estas igualdades en las que implican operaciones modulares, no son en realidad “Iguales”, sino “Congruentes”, es decir… equivalentes. Escribir “d x e = 1 (MOD Phi (pxq))” siendo ese “Igual” el símblo de congruencia, significa que 1 = dxe MOD Phi, siendo ese Igual un Igual de los de toda la vida.

Después de estos 4 pasos, la clave privada y la clave pública estarán ya creadas. La clave privada corresponderá entonces a la tupla Clave_privada (n, d), mientras que la clave pública a la tupla Clave_pública (n, e). Una vez obtenidas sendas claves tan solo es necesario aplicar la función de encriptación o desencriptación. Por cuestiones de Padding y seguridad, el mensaje es convertido a un número entero ‘m’, menor a ‘n':

me = Cifrado MOD n -> Se obtiene así un valor en Cifrado

Cifradod = m MOD n -> El valor Cifrado será desencriptado por medio de dicha función y se obtendrá m, es decir el mensaje original. Tan solo es necesario deshacer el padding.

Como se pueden ver, en realidad las funciones de encriptado y desencriptado son sencillas. Si quisiésemos llevar esto a un ejemplo real a pequeña escala (con números pequeños):

a) p = 101, q = 103 -> Ambos números son primos, de longitud similar (aunque números muy pequeños).

b) n = p x q = 101 x 103 => n = 10403. Phy (10403) = (101 – 1) (103 – 1) => Phi = 10200

c) 1 < e < Phi => 1 < e < 10200 => e = 13. 13 a su vez es primo y coprimo de 10200. Esto puede comprobarse de forma sencilla gracias al algoritmo de Euclides.

d) d x e = 1 (MOD Phi (p x q)) => d x 13 = 1 MOD 10200. Esta ecuación se expresa del mismo modo como: d-1 = e MOD Phi. Si se aplica el método extendido de Euclides se puede obtener de forma sencilla la identidad de Bezout. El método de euclides no es más en realidad que ir dividiendo dividendo entre divisor. Una vez se realiza la operación, el divisor pasa a ser dividendo y el resto divisor y se realiza otra iteración, hasta que se obtiene un resto de 1. A cada iteración se le calcula sus dos coeficientes para generar así la igualdad de Bezout. En nuestro caso para la iteración 5 (en la cual el resto es 1) del método extendido de euclides estos son 5 y -3923. calcular estos coeficientes se obtienen por sustitución de las iteraciones anteriores. En la iteración 3 se obtienen los coeficientes sustituyendo en esta la igualdad de bezout obtenida en la iteración una y dos. Las iteraciones una y dos a su vez se conocen de antemano:

restoi= Combi = Comb (i-2) + Comb (i-1)

Ronda Divndo. Div. Cociente Resto Sustitución Combinación Coef. 1 Coef. 2
1 10200 13 - 10200 - 10200=10200*1+13*0 1 0
2 10200 13 - 13 - 13=10200*0+13*1 0 1
3 10200 13 784 8=10200-13*784 8=(10200*1+13*0)-(10200*0+13*1)* -784 8=10200*1+13* -784 1 -784
4 13 8 1 5=13-8*1 5=(10200*0+13*1)-(10200*1+13* -784)*1 5=10200*-1+13* 785 -1 785
5 8 5 1 3=8-5*1 3=(10200*1+13* -784)-(10200*-1+13*785)*1 3=10200*2+13* -1569 2 -1565
6 5 3 1 2=5-3*1 2=(10200*-1+13* 785)-(10200*2+13* -1569)*1 2=10200*-3+13*2354 -3 2354
7 3 2 1 1=3-2*1 1=(10200*2+13* -1569)-(10200*-3+13*2354)*1 1=10200*5+13* -3923 5 -3923
8 2 1 2 0=2-1*2 0=(10200*-3+13*2354)-(10200*5+13* -3923)*2 0=10200*-13+13*10200 -13

10200


Pese a la aparente complejidad, si se presta atención al procedimiento realizado rápidamente se comprende como se ha realizado. Una vez obtenido los dos coeficientes, tan solo nos quedaría que d = Phi + Coef. 2 (Resto 1) => d= 10200 – 3923 = > d = 6277. Si deseamos verificar esto: d x e = 1 MOD (Phi(pxq)) => 6277 * 13 = 1 MOD 10200 => 81601 MOD 10200 = 1. Es decir, se cumple.

e) Con esto tendríamos la claves privadas y públicas calculadas:

Clave Privada (n->10403, d->6277), Clave Pública (n->10403,e->13)

Cabe destacar que todo este proceso de 4 fases es tan solo llevado acabo una sola vez, y estas claves serán las que sean usadas durante meses o años sin ningún tipo de problemas. Una vez se tienen estas dos claves, el resto tan solo es aplicar la función de encriptación o la función de desencriptación. Continuando con el ejemplo imaginemos que quisiésemos encriptar la palabra “Casas”, y que estamos usando un sistema simple de translación de dichos valores a ASCII en hexadecimal. Imaginar también que se tiene un Padding que inserta en el mensaje un valor de “0x01″ cada dos caracteres:

Mensaje Original: C -> 0x43 a -> 0x61 s -> 0x73 a -> 0x61 s -> 0x73
Mensaje Con Padding: 43 61 01 73 61 01 73. Es decir, cada dos bytes se incrusta un 01.
Tamaño de la palabra: 2 Bytes. Es decir, se especifica la cantidad de Bytes que se van a tomar para realizar la codificación, en este caso por ejemplo 2. Es decir, se divide el mensaje con el padding incorporado en grupos de 2 bytes, si el número es impar (como en nuestro caso) se añade un byte más de padding al final para rellenar

Codificación 1- >4361, Codificación 2 -> 0173 Codificación 3 -> 6101 Codificación 4 -> 7300

me = Cifrado MOD n ->Se cifrará usando la clave pública. En caso de que se quisiese cifrar con la clave privada, en vez de e se usaría d.

436113 = Cifrado MOD 10403 => Cifrado = 436113 MOD 10403 = 7905
017313 = Cifrado MOD 10403 => Cifrado = 017313 MOD 10403 = 6398
610113 = Cifrado MOD 10403 => Cifrado = 610113 MOD 10403 = 3597
730013 = Cifrado MOD 10403 => Cifrado = 730013 MOD 10403 = 3217

En mensaje cifrado por tanto correspondería a la cadena hexadecimal: “79 05 63 98 35 97 32 17“, algunos de esos valores tendrían representación en ASCII y otros no. El proceso de desencriptación sería similar:

Cifradod = m MOD n

79056277 = m MOD 10403 => m = 79056277 MOD 10403 = 4361
63986277 = m MOD 10403 => m = 63986277 MOD 10403 = 0173
35976277 = m MOD 10403 => m = 35976277 MOD 10403 = 6101
32176277 = m MOD 10403 => m = 32176277 MOD 10403 = 7300

Para poder calcular el módulo a tales cifras exponenciales no servirá una calculadora normal, es necesario recurrir a técnicas concretas para el cálculo de módulos a exponenciales. Un buen punto de partida para poder realizar esto sería: AQUI

Como se puede observar, los resultados obtenidos son exactamente los mismos que los iniciales, la cadena desencriptada correspondería a “43 61 01 73 61 01 73 00″, eliminando el Padding nos quedaría “43 61 73 61 73″ que se traduciría en ASCII de nuevo como “Casa”.

Según el esquema propuesto se puede ver la necesidad del Padding. El Padding en RSA toma una importancia aun mayor, dado que no solo sirve para añadir al final bytes que puedan faltar para rellenar, sino que es importante incluir ciertos bits o bytes (de forma reversible) en el mensaje original, de este modo RSA se hace resistente a ataques conocidos como “textos específicos”, aunque las vulnerabilidades serán tratados en el último capitulo de este artículo. El Padding debe de ser conocido por todos, no debe de ser un secreto.

Como se puede comprobar, RSA (o los algoritmos de clave pública en general) no son en realidad complejos por sus funciones, sino por la carga matemática que hay detrás de ellos. Las funciones en RSA para cifrar son muy simples, 4 variables de las cuales se conocen siempre 3 y dos operaciones, una exponencial y otra modular. La seguridad en cambio radica en que es virtualmente imposible obtener a partir de la clave pública la clave privada. Como hemos visto, la clave privada corresponde a la tupla n y d. Mientras que n es también un valor dado por la clave pública, d es calculado desde la clave privada a la hora de generar las claves. El cálculo de ‘d’ se podría intentar, pero como hemos visto anteriormente, d depende de Phi (p x q) y para calcular Phi (p x q) es necesario conocer ‘p’ y ‘q’. Aquí es donde radica el problema de la factorización. Sabemos que n = p x q y es un dato conocido, pero no conocemos el valor de ‘p’ y el valor de ‘q’ necesario para poder calcular Phi y posteriormente ‘d’. Para poder obtener ‘p’ y ‘q’ sería necesaria la factorización de ‘n’, y esto como hemos dicho no es viable. Es computacionalmente sencillo obtener dos primos con un número de bits muy grande. Es computacionalmente sencillo multiplicar dichos primos entre ellos. Y es computacionalmente imposible revertir el proceso y obtener los factores de dicho producto, es un camino solo de ida, si perdiésemos ‘q’ y ‘p’ sería imposible volver a encontrarlos.

Para aquellos que les pueda interesar RSA, recuerdo bien el programa DisMat, una herramienta para aprendizaje sobre RSA y otras cuestiones igualmente interesantes.

 

RSA no es el único sistema de clave asimétrica que existe. En la otra cara de la moneda tenemos ElGamal, que está basado en algunas asunciones similares pero en principios diferentes. No voy a detallar el funcionamiento de ElGamal por dos razones. La primera porque honestamente se escapa a los conocimientos matemáticos del redactor (es decir, a mi) y no sería ético buscar información sobre ello y plasmarla aquí sin comprenderla. Y por otro lado, aunque ElGamal es un sistema libre (RSA está patentado), su popularidad es relativa, siendo RSA inmensamente más usado y popular. De todos modos ElGamal si podemos decir que aplica otro principio de la “matemática imposible”, llamado como logaritmo discreto. Lo gracioso es que esto lo hemos visto a menos de pasada dentro de RSA. El problema reside en esta ecuación:

a = bx MOD n => x = log discretob (a)

Siendo a, b y n números conocidos y X la incógnita. El problema es poder calcular X. En RSA nos tenemos que enfrentar a esta ecuación, pero en nuestro caso no tenemos que calcular X, tan solo a. En ElGamal, poder obtener la clave privada implicaría resolver dicha ecuación, y esta es imposible de resolver computacionalmente, es decir… en un tiempo razonable, de nada sirve que pueda ser resuelto con un ordenador funcionando durante miles de años.

 

Los algoritmos de cifrado asimétrico como RSA son extremadamente seguros. El echo de que sea “lentos” comparados a los sistemas de cifrado simétrico hace que normalmente se opte por sistemas híbridos de los que serán tratados en los próximos capítulos. Dado que el potencial de computación es limitado estos sistemas suelen estar a salvo de cualquier posible ataque contra el propio sistema (no implica que no sean vulnerables a otros ataques), pero todos sabemos que la capacidad de cálculo de los dispositivos actuales se incrementa exponencialmente cada año que pasa. Esto significa que cada día que pasa se está un poco más cerca de alcanzar el reto computacional que plantean tanto los cifrados simétricos como AES-256 a cifrados asimétricos como RSA-1024. La ventaja de estos segundos, es que están diseñado para trabajar con longitudes muy superiores, mientras que no sucede lo mismo con los cifrados simétricos. Es probable que dentro de X años, AES-128 sea considerado inseguro, o incluso su sistema sea roto, como en su día lo fue RC4. En cambio encontrar una roptura en sistemas como RSA es harto más complicado.

Apple vuelve a la Censura

No es algo novedoso el tema de la Censura, pero lo trágico es que tan solo sea novedoso cuando viene de la mano de Apple.

Una vez más Apple ha decidido mover ficha en su afán de controlarlo todo. No es la primera vez que Apple usa la censura para prohibir una aplicación en su AppStore, pero parece ser que ahora lo quiere realizar como algo indiscriminado. Anteriormente Apple tenía prohibida la publicación de aplicaciones con contenido explícitamente sexual, amén por supuesto de otras tantas aplicaciones que ha vetado por uso incorrecto del idioma, imágenes que podían ser ofensivas para ellos…

No hace ni dos semanas aparecía otra noticia interesante (que no publiqué por cierto). En dicha noticia se hacía eco que programadores de aplicaciones para el Store de Apple estaban siendo presionados para eliminar de este cualquier referencia directa o indirecta hacia la plataforma Android. Así por ejemplo, aplicaciones que en sus descripciones rezaban frases como: “Número uno en Android” “Disponible también para Android” o cuestiones y sugerencias similares han sido punto de mira de Apple, y estos han enviado cartas a sus respectivos desarrolladores instándoles a que modifiquen sus descripciones para que no se aparezca la palabra Android. Es decir.. Android se está convirtiendo en una auténtica pesadilla para Apple (y lo peor aun no le ha llegado), y quiere con la censura evitar siquiera que pueda aparecer el nombre dentro de su cada vez más exclusivo Store.

Hoy Apple ha dado un paso más allá. Parece ser que Apple está dispuesto a eliminar cualquier aplicación que pueda contener ya no contenido explícitamente sexual, sino cualquier tipo de contenido erótico. Es decir, cualquier aplicación que pueda mostrar una chica o un chico en ropa interior o en pose provocadora. Según las cifras se hablan de miles de aplicaciones que podrían estar sujetas a dicha censura. Apple quiere mostrar una cara de seriedad indiscutible con su posiblemente fiasco iPad que saldrá a la venta en breve. Que por cierto, actualmente está en la lista de los peores “inventos” del año”.

Mi postura? Sinceramente no le veo ningún tipo de interés a aplicaciones que puedan tener contenido claramente sexual o simplemente erótico, pero soy igualmente respetuoso para quienes si les interese dicho tipo de aplicaciones. Para mi es una cuestión como la pornografía en Internet. Si bien es cierto que no le tengo ningún tipo de Amor, tampoco le tengo ningún tipo de Odio. Está ahí, quien quiera hacer consumo de ella tiene que tener la misma libertad de elección que puedo tener yo para no hacer consumo de ella, y la censura lo único que logra es matar el espíritu humano. Apple (o cualquier otra compañía) no puede decirme a mí como persona mayor de edad que debo de hacer ver o escuchar (siempre que todo ello sea completamente legal evidentemente). No, no me considero un consumidor de pornografía o sexo de Internet o PCs, pero me parece estupendo e incluso necesaria su existencia.

Si… he dicho necesaria. Es cierto que la vida real es la mejor vida que existe, aquella que está fuera de nuestras pantallas, se puede tocar, sentir… en definitivas vivir. Pero es cierto que no todas las personas son iguales, es cierto que la tecnología puede acercar a muchas personas incluso a dicho mundo real.

Quizás no comparta sus aficiones pero… para todos aquellos consumidores de pornografía, sexo o erotismo virtual tienen y tendrán siempre mi comprensión y mi apoyo. Espero que poco a poco, cada día más, las grandes empresas se den cuenta que el poder no está en la prohibición en la censura en el control, sino en la libertad. Evidentemente una libertad atada a unas leyes que evitan una anarquía y logran una armonía social sostenible. Apple señores no es más que una empresa que no le importa absolutamente nada sus clientes, tan solo el máximo de sus beneficios. Casi todas las empresas quieren lo mismo, no nos engañemos. La diferencia es que algunas de ellas han demostrado que haciendo las cosas bien, se puede ganar tanto o más dinero, véase Google por ejemplo, y eso que raro es el día que no tiene en su contra alguna noticia que la critica.

Apple, como ya sucediese en el pasado, vuelve y volverá a ser su propio verdugo.

Seguridad: Encriptación y Autentificación. Capítulo Primero -> Hash

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 


Hash

A diferencia del Spoofing, si hablamos de encriptación o autentificación se debe de establecer un orden sobre lo que vamos a ir viendo. Esto se debe a que un elemento suele requerir de otro, y este otro de otro… si no se explica adecuadamente cada uno de los elementos, será imposible comprender los que dependan den estos. Y el primero de estos elementos es el hash.

Un hash podemos definirlo como el resultado de una función matemática aplicada a una entrada arbitraria de datos, de forma que el resultado es (idealmente) asociado únicamente a la entrada dada y siempre obteniendo un resultado de longitud finita y concreta para el mismo hash. Es decir, idealmente para los hash criptográficos sería imposible volver a obtener el mismo resultado con otros datos diferentes. La idea es poder convertir la cantidad de datos que sea en un “resultado” de longitud fija (fijada por el propio hash). Veamos un ejemplo muy sencillo de esto. Imaginar uan función hash que realiza lo siguiente sobre números enteros:

Hash = numero1 + numero2 + numero3…. MODULO 100

En dicho ejemplo el hash se calcularía sumando cada numero de entrada dado y se le realizaría la operación Módulo 100. La operación módulo devuelve simplemente el resto de la división, y dado que el divisor es 100, el resto será siempre un número entre 0 y 99:


n1 = 500 n2 = 100 -> Hash = (500+100) MOD 100 = 600 MOD 100 = 0 Hash = 0 (600/100 = 6 y resto 0)

n1 = 1250 n2 = 25 n3 = 5460 Hash = (1250+25+5460) MOD 100 = 6735 MOD 100 = 35 Hash = 35 (6735/100 = 67 y resto 35)

Evidentemente esta función hash sería un tanto absurda desde un punto de vista criptográfico, dado que sería relativamente muy facil obtener el mismo resultado con dos entradas de datos diferentes. Pero sirve para dejar ver más o menos de lo que estamos hablando. En este caso tan solo existen 100 posible resultados, pero se puede observar que si modificásemos cualquier número este podría repercutir en un resultado completamente diferente. Las funciones hash hacen más o menos esto, aunque no con una precisión de 100 posibles valores y de una forma mucho más eficiente, pero la idea es la misma. Pero no solo es útil pensar en criptografía, una función Hash puede tener un valor muy importante simplemente en la detección de errores por ejemplo.

¿Para que sirve esto? Tiene una gran utilidad en muchísimos campos. Podemos decir que existen tres tipos de Hash: Hash checksums, Hash CRC y Hash criptográficos.


CheckSum

Sería el ejemplo más básico de Hash. El concepto apareció de la necesidad de verificar de algún modo la integridad de la transferencia de los datos. Es decir, si estos se habían transmitido de forma alguna de forma errónea. ¿Pero como podemos verificar esto? Podemos tratar los datos de entrada de tal forma que nos de un resultado, de modo que si el resultado es diferente en el destino, los datos son erroneos. Generalmente un CheckSum es una operación matemática basada en sumas. El ejemplo expuesto anteriormente sería un posible ejemplo de checksum. El ejemplo de checksum más simple es el bit de paridad. Imaginar que sea cual sea el bloque de datos de entrada, se le computa la paridad al dato, y esta se le añade al dato final. El checksums en sí mismo es tan solo un bit, un cero o un uno que corresponde a la paridad del dato inicial. Cuando los datos son recibidos por el destino, el destino calcula de nuevo la paridad del bloque y la compara con la paridad recibida. Si coincide los datos son válidos. Evidentemente este checksum tan solo previene contra 1 posible cambio de valor en uno de los bits transmitidos. Vamos a verlo con un ejemplo:

Se desea transmitir la cadena “Casa” desde A hasta B. Imaginar que cada carácter es acompañado con un bit de paridad. Un carácter tiene un valor entre 0 y 255 según la tabla ASCII, es decir, un carácter ocupa 1Byte de datos (8 bits). El carácter “C” equivale al código ASCII x43 (43 en hexadecimal), lo que en binario equivale a “01000011”:

C -> 01000011 -> Se aplica Paridad Par por ejemplo (Hay número par de “unos”? si es asi el resultado es cero, de lo contrario es uno) -> 3 Unos, es impar, bit de paridad par = 1

C -> 01000011 + bit de paridad -> Datos transmitidos: 010000111

De este modo, el destino tan solo tiene que tomar los primeros 8 bits y realizar la misma operación. Si el resultado coincide no hay error o no se ha podido detectar. Si no coincide se ha producido un error y los datos no puede tomarse como válidos. En este caso caso, tan solo se podría detectar con un bit un número impar de errores: 1, 3, 5… dado que si se produce un número par de errores el bit de paridad no cambiaría.


Evidentemente existen Checksums más eficientes, aunque todo depende del uso que se le haga. En cambio todos los días tratamos con este tipo de sistemas, y no hay que profundizar siquiera en la informática. En la mayoría de datos personales que puedan ser sensibles, suele existir un carácter o caracteres de control que verifican que los datos introducidos son válidos. Por ejemplo la letra de nuestro DNI no es más que un checksum, que se obtiene aplicando un módulo 23 al número de la división. Al resultado (entre 0 y 22), se le asigna una letra ya espeificada. Por ejemplo, el Cero es la letra T, el tres es la letra A… de tal forma que si damos o introducimos nuestro DNI de forma incorrecta, es posible verificarlo simplemente comprobando la letra proporcionada y ver si coincide con la que debería de ser. A este ejemplo se le suman los carácter de control de los números de cuenta corriente, de otros datos del DNI, número de la seguridad social… es una forma simple y efectiva de detectar con prontitud cualquier error en los datos tomados.

Otro uso increíblemente extendido es en la verificación de datos en sí mismos, no solo en la transferencia de estos. Así por ejemplo, si se quiere disponer de algún tipo de archivo que pueda tener datos relativamente sensibles como bios, firmwares, datos personales… lo normal es ir aplicando checksums a determinadas partes del archivo incrustando este mismo en las diferentes partes del archivo. De este modo, el software a medida que va procesando el archivo puede ir verificando cada bloque para asegurarse de que el archivo es confiable. Pensar en una bios que se quiere actualizar y por cualquier motivo existe un error en uno solo de sus bits. Es suficiente para que el PC no arranque. Para evitar esto, se distribuye por toda la bios checksums que van verificando bloques menores,

Su uso no obstante se ha ido reduciendo con la aparición de los Hash CRC, los cuales suelen realizar operaciones similares pero de una forma mucho más efectiva. No obstante para pequeños bloques de datos o comprobaciones sencillas suele ser más fácil y barato de implementar Checksums. Entre los Checksums más habituales encontramos Sum8, Sum16, Sum32 o Sum64.


CRC

Se traduce como comprobación de redundancia cíclica. Su objetivo y uso es muy similar al del checksum, de tal modo que no es raro ver lugares en los cuales el nombre de CRC no es más que un tipo de checksum. La necesidad de la verificación de los datos es algo de suma importancia, siendo quizás su máximo exponente la firma digital, de la cual ya hablaremos de ella. Pero no solo la detección de errores es necesaria, a veces es necesaria también la corrección de estos. Aunque un checksum puede usarse para esto, es más normal ver este tipo de correctores como CRC. Aun así, los sistemas de corrección de errores suelen ser costosos en cuanto a rendimiento, precio, implementación… tanto que normalmente no compensa, y es mucho más eficiente simplemente un buen sistema de detección, y si la detección es erronea simplemente se retransmiten de nuevo los datos. Si bien los checksums pueden ser una herramienta muy extendida dentro de los propios archivos, los CRC suelen ser usado de forma mucho más extensa en la transmisión de datos, aplicado normalmente a bloques de datos de un tamaño mayor.

El peor escenario que puede darse en una transmisión de datos o en un error en un archivo, es que este no pueda detectarse, haciendo que los datos sean enviados o procesados como legítimos. Y es esto lo que se debe de evitar a cualquier precio. Por ello, los CRC son usados intensamente en la transmisión de datos sobre internet, telefonía… y por supuesto en la integridad de los datos en un disco duro, CD, pendrive y otros dispositivos. Cuando hablo aquí de integridad no me estoy refiriendo a sistemas de checksums que puedan estar implementados en la misma estructura del archivo, sino sistemas de ingreidad que poseen los propios dispositivos. Gracias a la integración hardware y la simplicidad de como opera un CRC (la mayoría de ellos), la gran mayoría de nuestro hardware implementa funciones CRC en él mismo, sin necesidad de un software. Es decir… todo el proceso es transparente a nosotros.

El funcionamiento de un CRC es simple. A un bloque de entrada se le añade primero los bits correspondiente al CRC, y el nuevo bloque se divide por un polinomio preestablecido. El resto de dicha división binaria será el CRC. Dicho CRC se añade al bloque original y se retransmite. El destino tomará el bloque y lo dividirá por el polinomio generador (que será el mismo que usó el emisor). Si el resto es cero, no hay error de transmisión, o al menos no hay error detectable. La eficiencia radica por lo cual en el polinomio generador usado y evidentemente en el número de bits usados para el CRC. El caso más simple de CRC sería el bit de paridad, que correspondería a un bit de CRC tan solo, y el polinomio generador sería X + 1, el cual se traduciría como “11” como divisor del mensaje de entrada. Un polinomio generador tal como X5+X4+X+3 se traduciría por lo tanto como “110011” y se tendría un CRC de 6 bits.

Aun en los CRC-32, no se puede considerar CRC un hash seguro, no está pensado como resultado único de una posible entrada ni como sistema de ocultación o cifrado de datos, sino como un sistema robusto de detección de errores, y francamente, hace su trabajo a la perfección. Gracias a este tipo de funciones hash, a día de hoy disponemos de medios de comunicación fiables y con una gran tolerancia a fallos. Que no apreciemos este tipo de tecnologías, no implica que las estemos usando constantemente. Para hacernos una idea de la eficiencia de los CRC, un CRC-16 tienes el siguiente índice de detección:

  • Detección del 100% de errores simples (errores que afectan tan solo a un bit)
  • Detección del 100% de errores dobles de bits adyacentes (Si dos bits consecutivos son erróneos)
  • Detección del 100% de los errores para datos de hasta 16 bits.
  • Detección del 100% de todos los errores de dos bits que no estén separados uno del otro exactamente a 216-1 bits
  • Para el resto de posibles errores, se establece tan solo una no detección en un fallo de cada 216

Es decir, un cRC-16 sería capaz de detectar aproximadamente el 99.995% de todos los errores. ¿Esto es mucho o es poco? Esto equivale a que cada 20.000 errores, uno no se detecta. Teniendo en cuenta las comunicaciones ultrarápidas de hoy en día, la cantidad de información que es manejada en segundos es simplemente impresionante, por lo cual podemos afirmar que de cuando en cuando efectamente aparecerán errores no detectados. Esto se subsana también gracias a la fiabilidad cada vez mayor de las propias redes, con menos ruido, con mejores equipos…

Los CRC más comunes son CRC8, CRC16, CRC32… aunque si se desea ver una lista de ellos con sus polinomios generadores tan solo hay que acudir a la Wikipedia, por ejemplo.


Criptografía

En realidad son los Hash que nos van a interesar a nosotros. Este tipo de hash se usan ya no solo como detectores de errores (que pueden valer para ello también). Este tipo de Hash, al igual que los que hemos visto, es u procedimiento determinista que devolverá un resultado de una longitud fija. Pero a diferencia de los CRC o checksums en los que su objetivo principal es la detección de errores, la función de un hash criptográfico va mucho más allá:

  • La imposibilidad de poder encontrar una cadena (un bloque de datos…) cuyo resultado sea un hash dado.
  • La imposibilidad de modificación de la cadena inicial, sin modificar el hash.
  • La imposibilidad de encontrar una segunda cadena que verifique un hash de otra cadena.
  • Un hash que sea computacionalmente eficiente y facil de implementar.

Hay que comprender que con imposibilidad no podemos asegurar que sea imposible, sino que el coste computacional para ello sería tan ingente que de ninguna forma sería factible. Esto evidentemente no es más que la teoría, en la práctica todo no es tan simple.

A diferencia de los CRC o los checksums que pueden comprenderse sin muchas nociones de matemáticas y parten de unos conceptos simples, los hash criptográficos son bastante más complicado de comprender (las matemáticas escondidas detrás de ellos). Cada algoritmo hash tiene sus propios fundamentos, basados en premisas diferentes, siempre intentando cumplir cada una de las premisas dadas. No obstante podemos citar los Hash criptográficos más usados a día de hoy, como pueden ser: MD4, MD5, RIPEMD, SHA-1, SHA-256, SHA-512. Por supuesto existen muchos otros, aunque menos usados. Posiblemente a muchos algunas de esos nombres les sea conocido.

Al cumplir las premisas citadas, los Hash criptográficos suelen ser usados de forma intensiva en los siguientes campos:

  • Comprobaciones de archivos
  • Firmas digitales
  • Tablas Hash
  • Integridad de un mensaje/contenido


Dado que un Hash puede ser usado para detectar errores en el envío y/o recepción de los datos, un Hash criptográfico puede ejercer función de Comprobador de archivos. Mientras que CRC o checksum suelen aplicarse normalmente a porciones de código, tramas en las comunicaciones, pequeños detectores… este tipo de hash en realidad no se diseñan como correctores de errores o para que el contenido sea reenviado si no es correcto. Este tipo de Hash se suelen aplicar sobre un archivo completo (o conjunto de ellos). Para estos Hash, no importa lo grande o pequeño que sea el dato a verificar (pensado especialmente para grandes cantidades de datos en comparación con CRC o checksum claro está).

Comprender su función en este caso es simple. Al contenido original se le apluca un Hash criptográfico el cual se adjunta al software/archivo original. Cuando el receptor lo descarga, tiene acceso a él… solo tiene que calcular el mismo el mismo Hash y comprobarlo con el Hash que ha sido descargado desde la fuenta original. La idea es que sl el hash es el mismo, tenemos la certeza de que el archivo no se ha corrompido por el envío y la recepción ha sido satisfactoria. Por un principio similar, se puede verificar la integridad y veracidad de dicho archivo, que no ha sido modificado por nadie, que es legítimo. Podemos afirmar esto dada las propiedades ya vistas de este tipo de Hash: La imposibilidad de poder encontrar o crear otro archivo que pudiese coincidir con el hash del archivo original, y por otro lado no sería posible modificar el contenido del archivo sin alterar el hash que se calcularía en el destino.

Ver esto es muy fácil con algunos ejemplos. Tan solo tenemos que buscar un software que sea distribuido por razones de seguridad con su hash. En este caso vamos a usar por ejemplo la imagen de Windows 7 x64 Ultimate ENG. Imaginad que no te quieres molestar en ir a la tienda y encuentras un vendedor supuestamente autorizado que te permite descargar una copia de la imagen de Windows 7 (la misma que he expuesto ahi). Pero claro… quieres asegurarte de que la imagen sea legítima, y no sea una imagen modificada a la que se le haya puesto una activación o algún crack para poder instalarla. Solución? Conocer el Hash de la imagen legítima. Me pongo en contacto con Microsoft o investigo un poco para conocer el Hash de la imagen original y lo que obtengo es lo siguiente:

Windows 7 Ultimate x64 ENG: 7600.16385.090713-1255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.ISO
MD5: F43D22E4FB07BF617D573ACD8785C028
SHA-1: 326327CC2FF9F05379F5058C41BE6BC5E004BAA7

Lo único que se debe de hacer en este caso es verificar si los valores que yo obtengo al calcular el hash son esos o difieren. En teoría con el cálculo de uno de ellos es suficiente. Para hacer esto se puede usar por ejemplo la utilidad md5sum sha1sum:

E:\Windows 7 Ultimate Final (EN-DE-JP-AR)>md5sum 7600.16385.090713-1255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso
f43d22e4fb07bf617d573acd8785c028 *7600.16385.090713-1255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso

E:\Windows 7 Ultimate Final (EN-DE-JP-AR)>sha1sum 7600.16385.090713-1255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso
326327cc2ff9f05379f5058c41be6bc5e004baa7 *7600.16385.090713-1255_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso

Si dicha imagen hubiese sufrido cualquier tipo de modificación el resultado sería muy diferente. Por ejemplo, si a la imagen le modifico simplemente el primer bit (que es un “cero”, y lo establezco a “uno” con un editor hexadecimal) y le recalculo el hash MD5, esto es lo que obtengo:

4420bc0022a2ca8a361111b7a4d24ea7

Es decir, modificando tan solo un bit, el hash es completamente diferente. Por los mismos principios sería en la práctica imposible modificar aleatoriamente (o a conciencia) los bits de forma que pudiese obtener el mismo hash. Y he dicho en la práctica por una razón concreta que ahora veremos.

Vamos a suponer el caso concreto del Hash MD5. El Hash MD5 es un hash de 128 bits, lo que significa que cualquier contenido al que se le aplique este hash, se obtendrá una salida de 128 bits, una cadena de 32 caracteres hexadecimales. Es decir, sin entender siquiera de paradojas o estadística, podríamos afirmar que podríamos obtener un máximo de 2128 posibles hash. Esto es un número un tanto ingente, tanto que posiblemente una mente no es capaz de cuantificar, hablamos de 3.4 * 1038 es decir… 34 con 37 ceros a su derecha. Pero aun cuando este número es mentalmente imposible de imaginar, si es posible de imaginar que en el peor de los casos, cada ese número de hash calculados estos se volverán a repetir, lo cual implica evidentemente que sería teóricamente posible encontrar dos archivos exactamente con el mismo hash. Esta afirmación en realidad no rompe los esquemas vistos, dado que no se “rompe” la veracidad al decir que es improbable modificar un archivo para obtener un hash concreto o encontrar ese segundo archivo que verifique dicho hash. Aunque teóricamente esto es posible, aun cuando solo fuese de forma estadística.

Este es por tanto uno de los principales problemas de los hash criptográficos, y a esto se le llama colisión. Al margen de lo bueno o malo que sea el Hash, estadísticamente es posible encontrar dos hash iguales. En este caso concreto visto, aunque es posible teóricamente, en la práctica si el Hash está bien diseñado sería imprácticable. Cuanto tiempo necesitaría un PC en ser capaz de encontrar una colisión? Pues haciendo números muy por encima… 15 * 1010 años en el supuesto de que toda la población mundial tenga un procesador de 4 núcleos trabajando al mismo tiempo en la misma tarea 24 horas al día. Es decir… en el peor de los casos sería virtualmente imposible.

El problema es que esta lógica no es así. Cuando se habla de una colisión en un hash hay que recordar la llamada “Paradoja del cumpleaños”. Cabe señalar de nuevo que es muy diferente encontrar un contenido que verifique un hash concreto a encontrar dos contenidos disferentes que posean un mismo hash. Lo segundo es una colisión. Es cierto que para el primer caso la probabilidad sería la ya citada, pero no para el segundo caso, y aquí aparece lo que puede parecer increible: La paradoja del cumpleaños establece que en una habitación con 23 personas, existe un 50% de probabilidad de que dos personas cumplan años el mismo día, y si fuesen 60 personas la probabilidad sería del 99%. No hay truco, simplemente se busca una coincidencia entre cualquiera de las 23 personas, no una coincidencia concreta dentro de las 22 restantes. Teniendo esto en cuenta, MD5 posee tan solo 232 posibilidades de encontrar una colisión. Es decir, 4294967296 hash calculados de 4294967296 archivos aleatorios, estadísticamente debería de existir alguna colisión, es decir, dos archivos diferentes que poseen el mismo hash. Y es evidente que este número si que es comprensible y relativamente bajo, dado que un PC normal podría generar colisiones de hash MD5 con relativa facilidad, y esto comenzaría a invalidar los puntos en los que se asienta un Hash criptográfico. Es por esto que MD5 ha dejado de considerarse un Hash seguro, y es solo cuestión de tiempo que quede en desuso, a favor de otros Hash más seguros.

En teoría cualquier Hash debería de presentar posibilidad de Colisión, aunque es evidente que si esta probabilidad es computacionalmente imposible, podemos afirmar que no existe colisión (aunque teóricamente exista). Para tener presente esto, pensar que al Hash MD4 es posible encontrarle colisiones con tan solo en 256 hash.

A raiz de las Colisiones, aparecieron las primeras herramientas que han empezado a romper del todo el Hash MD5. A día de hoy existen herramientas capaces de generar dos programas diferentes que satisfagan el mismo Hash MD5, con lo que se rompe la seguridad de MD5 para la verificación de integridad y comprobación de un contenido. Es evidente que esto tiene matices. A día de hoy continua siendo imposible generar un contenido nuevo que satisfaga un hash buscado (lo cual rompería de forma definitiva el Hash). Pero en cambio si es posible producir dos archivos o dos contenidos que satisface el mismo hash. Esto quedó de manifiesto por el doctor Xiaoyun Wang, el cual incluso liberó el código de una aplicación que es capaz de realizar esto (En la cabecera de este artículo se puede encontrar)

SHA-1 es el segundo Hash más usado a día de hoy. A diferencia de MD5 (aunque basado en sus mismos principios) es un hash de 160 bits, al cual se le ha podido establecer un índice de colisiones de 252 en el mejor de los casos. En dicho caso el cálculo de una colisión sería relativamente práctica de llevar a acabo, quizás un año o dos años en poder lograr encontrar dos contenidos que compartan el mismo hash. No obstante se le continúa considerando seguro.

SHA-2 (conocidos como SHA256 y SHA-512) funcionan de forma muy similar a SHA-1, anque en este caso producen salidas de 256 y 512 bits respectivamente. En ambos casos no se conocen colisiones posibles.

Ante todo esto y dado que podemos asumir que tanto MD5 o SHA-1 son algo así como estándares, ya está en marcha el nuevo “concurso” que será seleccionado como sucesor de SHA-1/SHA-2 y que posiblemente será el próximo estandar en Hash dentro de un par de años. Actualmente se ha comenzado la segunda ronda, y a final de este año debería de quedar todo más o menos finalizado. La idea es encontrar un Hash más seguro y que sea muy eficiente su cálculo ,es decir… la velocidad con la que se pueda calcular el hash a un contenido. Se puede acceder a una lista de todos los candidatos de la segunda ronda en la web oficial del NIST (Instituto nacional de estándares y tecnología)

 

El último uso que deberíamos explicar son las Tablas Hash. Antes de entrar en detalle sobre este tipo de prácticas sería más correcto hablar antes de la Sal o Salt (en inglés). Hasta ahora hemos visto funciones de los Hash criptográficos para comprobar la integridad de los archivos, pero ¿que sucede si queremos usar un Hash como una especie de “encriptador” de contenido? Esto podría no tener mucho sentido dado que cualquier persona puede calcular un hash MD5 por ejemplo a cualquier entrada… pero en cambio no es posible partir del hash para obtener el contenido. Esto adquiere mucha más relevancia cuando se usan un hash para proteger detrás de él un contenido pequeño como un nombre de usuario o una contraseña, y es aquí donde aparece el término y la idea de Salt. Salt es un apéndice que se añade a una cadena de entrada para generar un Hash no intuituvo

Dentro de la web, las cookies y otros contenidos que puedan ser sensibles de cara al exterior como nombres y contraseñas puede ser sometido a un hash criptográfico para esconder su “significado” original. Esto nos dará como resultado una salida “única”, con lo que se podría usar dicha salida como contraseña y nombre del usuario de cara a un servidor, en vez del texto plano. Esto incrementa de forma exponencial la seguridad de cualquier base de datos o sistema de control de acceso. Pero como hemos dicho la utilidad de esto podría ser relativa. Vamos a ver esto con 3 ejemplos que ilustrarán la eficacia o no eficacia de un Hash para estos procesos, así como la implicación de Salt:

Imaginemos que hemos robado un archivo que guarda las credenciales de acceso a una importante base de datos. Imaginemos que dichas credenciales pueden ser almacenadas en dicho archivo como texto plano, MD5 y MD5+Salt. Si abrimos ese documento encontraríamos esto para cada una de las opciones:

1º. Nombre: Theliel Contraseña: perico

2º. Nombre: 5A04B2D961488CDA31CD065F259783BE Contraseña: DFE483413E24A5B1506389D36EBFD05C

3º. Nombre: 217B11413677EE9D4806967515D66607 Contraseña: 8E50E5A474DDAF3BC370F87DD97EC7F0

En el primer caso, es evidente que si está configurado como texto plano, las credenciales serán tomadas de forma directa y rápidamente podremos acceder a la base de datos.

En el segundo caso no obstante n oparece que sea posible descifrar absolutamente nada… ¿pero que pasaría si hacemos uso de la inteligencia? Podemos intuir que es un hash, y si buscamos información del sistema podemos incluso conocer que se trata de un Hash MD5. No podemos revertir el MD5 (a priori), pero en cambio si podemos presuponer el nombre de usuario y ver si hay una coincidencia con el hash que tenemos. Dado que el atacante es listo, comenzaría por cotejar en un diccionario que ya tiene el hash. Su diccionario no es más que una lista precalculada con quizás millones de posibles nombres de usuarios a los que ya se les ha calculado el hash correspondiente. Si el hash se encuentra en su diccionario, obtendrá de forma automática le nombre de usuario. Esto mismo se puede aplicar a la contraseña. Que usuarios se probarán primero? Admin, admin, theliel, Theliel… y en este caso, el diccionario encontraría que dicho hash corresponde a la palabra “Theliel”. En caso de la contraseña es exactamente igual, si la palabra o frase empleada en la contraseña existe en su diccionario, obtendrá directamente la contraseña buscada. Es por ello que siempre es importante tener una contraseña alfanumérica de una longitud decente.

En el tercer caso la cosa es más complicada. El atacante agotaría todos sus diccionarios y no lograría encontrar el hash deseado. ¿Por qué? Porque lo que no sabe el atacante es que el programa que codificó el hash usó una Salt, un trozo de datos que simplemente añadió al final del usuario y la contraseña. Así si el usuario escribió el nombre de usuario: “Theliel”, el servidor jamás lo tomó como tal, sino que automáticamente le añadió el Salt “TATA” (en este caso). Es decir, de cara al servidor cualquier dato introducido es concatenado con “TATA”. Así, el servidor no calcularía el hash de “Theliel” o de “perico” (la contraseña), sino de “ThelielTATA” y “pericoTATA”. dicha modificación es seguro que no aparecerá en su diccionario. La única opción del atacante es conocer la Salt usada por dicho servidor, y crear así un programa que automatice el proceso, recalculando todos los hash de su diccionario con la Salt aplicada y así con suerte obtener algún resultado. Esto lo trataremos mejor cuando se vean las diferentes técnicas para romper la seguridad.

Pero volvamos a las tablas Hash. Hemos explicado que la Salt o la importancia que puede tener un hash para “esconder” unos datos, pero ¿qué es una tabla hash? Dado que el índice de colisiones es relativamente alto, podemos presuponer que no será posible dar la casualidad de tener a dos nombres de usuarios que compartan el mismo hash. Si esto es cierto, para un servidor es mucho más seguro no guardar jamas en sus bases de datos el usuario o la contraseña como tal, solo sus Hash. Al introducir los datos el usuario, son sus hash los que alcanzan el servidor y este simplemente tiene que cotejar dicho hash (el usuario) en su base de datos para comprobar si existe una coincidencia. Si existe tal coincidencia verificar el hash de la contraseña con el hash de contraseña ya almacenado. De este modo nuestros datos de sesión no serían jamás enviados como tales. Pero la utilidad de las tablas de hash radica no en la seguridad (que por supuesto también lo es) sino su eficiencia.

Hemos dicho que el servidor debería de verificar si el hash de nombre de usuario existe en su base de datos. ¿Pero como hace esto? Si nuestra base de datos posee 100 registros, en el peor de los casos la base de datos debería de hacer 100 comprobaciones, para acabar en el último registro que sería el que coincidiese con el hash del usuario introducido. Pero aun, si el usuario introducido no se encontrase en la propia base de datos, esta la habría recorrido entera buscando una coincidencia. Este proceso sería muy costoso para los servidores. Ahora bien, partimos de la premisa que el índice de colisión de un hash MD5 es relativamente alta, 4 mil millones aproximadamente. Podríamos calcularle simplemente el módulo a dicho Hash (en función del número de índices que tengamos en la base de datos), el resultado sería un número de 1 a X, siendo X el número de entradas posibles en nuestra base de datos. Es decir, pongamos que nuestra base de datos tiene 100 registros insertados y tiene una capacidad máxima de 997 (por ser un número primo). Es decir, se aplicaría la operación módulo 997 a cada hash de entrada. Esto convertiría todos los hash de entrada en un número que iría desde el 0 al 996. Este número sí podría ser usado como índice, luego el acceso al registro en la base de datos sería inmediato. Por razones de precisión, usar un número de 128 bits no es aconsejable, lo normal es acotar este número a una resolución de 64bits, tomando por ello los 64 bits primeros del hash o los 64 bits últimos de este. En el ejemplo anterior, al Hash “Theliel” se le aplicaría módulo 997, y el resultado sería: 5A04B2D961488CDA31CD065F259783BE -> 5A04B2D961488CDA MOD 997 = 763. Es decir, que el nombre de usuario Theliel sería convertido al índice 763 en la base de datos. De este modo, al introducir “Theliel” en el navegador, se calcularía el Hash, en el servidor se truncaría y daría como resultado un índice. Con este índice el acceso a la base de datos sería directo, “Acceso a elemento 763″. Asociado a dicho índice se podría encontrar por ejemplo el hash de la contraseña y se procedería a realizar una simple comparación, si los dos hash coinciden se obtiene el acceso.

Esto evidentemente multiplica exponencialmente la posibilidad de una colisión, dado que el espacio disponible ahora es de tan solo 997 elementos. Como hemos dicho la posibilidad de colisión dependerá en gran medida de la ocupación del espacio disponible. Por la paradoja del cumpleaños no obstante, se daría el caso que con unos 35-40 elementos introducidos la probabilidad de una colisión sería de un 50%!!. Para evitar esto se acude a tablas muco mucho mayores en relación al indice esperado de ocupación que se tendrá. Es decir, se sacrifica espacio en post de velocidad. En la Wikipedia aparece un ejemplo parejo, en el que se dice que con 2500 elementos introducidos en una tabla de un millón de elementos, la probabilidad de colisión ascendería al 95%. Que hacer en caso de colisión? Primero evitarlas, ya sean con grandes tablas o con crecimiento dinámico de estas. Por otro lado asumir que es posible que exista una colisión, y diseñar el sistema de forma que ante una colisión sea necesaria una segunda búsqueda en los registros afectados para determinar el destino final.

Apple comienza a banear IDs de usuarios que tienen su dispositivo JailBreak

La noticia llega de forma inesperada para muchos… y es que parece ser que Apple en un intento muy agresivo por su parte estaría comenzando o pensando en suprimir aquellos IDs de dispositivos que están JailBreak. Es decir, que si Apple detecta de modo alguno que tu iPhone o iPod Touch ha sido JB podría añadir este a una lista negra e impedir todo acceso al AppStore, siendo claro el resultado de esto, imposibilidad de poder comprar por iTunes canciones o aplicaciones para tu dispositivo.


 

Cortesía de Neowin.net

 



Apple se ha visto presionado por las compañías móviles y por sus propias ganancias. Su objetivo es evitar por todos los medios que el iphone o el ipod touch pueda ser un sistema abierto que ellos, Apple, no pueda controlar. Al margen de si es legal o no sus actuaciones, recordemos que el JB no es un procedimiento ilegal a día de hoy, y posiblemente no lo sea nunca. Luego si no es un proceso ilegal, es posible que Apple legalmente no tenga ninguna autoridad para denegar un servicio a un cliente por un acto legítimo, que en todo caso tan solo rompe las condiciones de la garantía.

Al margen de ello, lo que está claro es que Apple está intentando por todos los medios proteger su gallina de los huevos de oro que cada día que pasa pone menos y menos huevos. El índice de adiciones de aplicaciones en el Store de Apple disminuye considerablemente, el iPad (aun cuando hay que esperar) presagia un varapalo para Apple, El Nexus One comienza a asentarse y demostrar que no solo es un hardware muy superior sino que por un lado o otro otro el iphone irá cayendo poco a poco en el recuerdo. Ante todo esto Apple lo tiene claro, moverse rápido e intentar exprimir lo que queda.

De nuevo vemos una política de empresa completamente restrictiva y que cercena la libertad de los clientes. A fin de cuenta lo único que pretende Apple es el control de sus clientes. Cuando compras un iPhone 3GS no tienes BT, el video es malo, los mms son malos, no tienes acceso al sistema, ni siquiera puedes copiar un archivo. En contraste cualquier dispositivo similar actual permite no solo hacer todo ello, sino que algunos como el Nexus One te permite si lo deseas modificar a voluntad el sistema, sin pérdida de garantía, sin crispaciones, sin tonterías.

A fin de cuenta, todo se ve reflejado en números, y los números dicen que Google aumentó sus beneficios en más de un 50% en el año 2009 frente al 2010.  Es una pena que muchas empresas no comprendan que el cliente es al final quien paga tus facturas, y que por mucho que intentes engañarlos, al final responden.


Es por noticias como estas por las que uno se para a preguntar por qué cometio el error de comprarse un iPod Touch (en mi caso particular) o un iPhone, o cualquier producto de Apple. Ya no es una cuestión siquiera de dinero (Que son los productos más caros), ya no es una cuestión siquera de que sea lo mejor o peor (que no es lo mejor)… se convierte simplemente ya en una cuestión de principios.

Hace unos años cuando adquirí mi iPod Touch estaba contento con la compra, tan solo hay que remitirse a mis post más antiguos. Foros, blogs, investigaciones propias, aprendizaje… comprendía en parte las tonterías de Apple o eso creía. Excusas que se da a uno mismo para no tener que aceptar la inversión de un buen capital en algo que no lo vale. Después de un año, de dos… la perspectiva es muy diferente. Te cansas de las noticias inverosímiles, de los fallos de software y de hardware, de las carencias… pero ya no de las que puedas encontrar tu mismo!! sino en las preguntas de siempre de otros usuarios: no hay modo disco? no puedo enviar un archivo por bt? no puedo….? Y por otro lado veo el mercado que ha expandido para ofrecer productos no solo más baratos sino muy superiores!! y aun así tienes que oír a representantes de Apple escuchar frases como: “Muchas de las veces que se queda colgado un MAC es por culpa de Flash” . “La salida de Windows 7 implicará para nosotros un gran incremento en ventas”, “La garantía queda anulada porque su MAC ha estado expuesto a un ambiente tóxico, ambiente de fumadores”… y tantos otros.

Personalmente me pregunto sinceramente en que momento Apple vendió su alma en post de engañar a algunos cuantos. ¿Hoy? Simplemente otro granito más, A bloquear IDs que tengan dispositivos JB. Que por cierto, personalmente no creo que sea una idea mu positiva, lo que lograrían sería que la comunidad usase más Cydia o la búsqueda de aplicaciones piratas, aumentando aun más la piratería.

Pero esto es así. Apple es así. De cada 100 ideas de Apple, 1 revoluciona el mercado y es una idea grandiosa. Las otras 99 ideas hacen que la opinión publica (al menos la mía y la de muchos otros) piense que se cometió el error una vez en comprar algo con una manzana.

Este blog se creó en sus orígenes precisamente por el iPhone y el iPod Touch, creo que no se puede pedir que sea más imparcial, cuando todo fue para ayudar, alentar y aconsejar positivamente. Pero hace ya tiempo que esos tiempos acabaron, y no hizo falta mucho para darme cuenta de ello.

Por mi parte? Nunca Máis Apple, Nunca Máis.

¿Bajará Apple el precio del iPad?

Cito textualmente de la web de Apple:

“Nuestra más avanzada tecnología en un mágico y revolucionario dispositivo a un precio increible”

Si el iPad es la tecnología más avanzada de la que dispone Apple, si realmente Apple cree que es algo mágico y revolucionario, si realmente cree que es un precio increíble… deja mucho que desear de una empresa así.


Aunque el iPad aun no está en el mercado, no pocos han sido sus detractores. Y es normal. Por un lado la supuesta gran espera (que tampoco lo comprendo) sobre un supuesto TabletPC por parte de Apple y al salir… ha desilusionado prácticamente a todo el mundo. Tan solo hay que mirar las encuentas. Las últimas decían que tan solo un 5% de dichas encuentas estarían dispuestos a comprarlo, mientras que un 72% seguro que no. El resto de personas les gustaría tener más información y a otros no les convence pero esperarán.

Cuando datos estadísticos responden con tal crudeza, los de Cupertino están empezando a temerse una debacle. Hay que tener en cuenta que para Apple lo peor no es unas malas ventas, sino una mala reputación. Apple no puede permitir que se critique un producto de ellos o que se pueda pensar que no es lo mejor del mercado. Pero en este caso el “daño” o no “daño” ya se ha hecho. Si los pronósticos se cumplen (siempre hay que esperar), el iPad será un fracaso en ventas tal y como presuponía Apple. Esto en el mundo Apple viene acompañado con desilusión, que es lo que más dinero hace ganar a la empresa de Jobs.

Pero nos encontramos con algo “inédito”, o al menos una práctica no muy extendida. Apple estaría replanteándose acallar la mala prensa y los malos resultados a golpe de bajada de precios. Es evidente que el precio es algo importante, pero no es la cura. Para empezar los que abogan normalmente por tener un producto de Apple suele ser una clase pudiente, los cuales si el producto convenciera no tendrían problema alguno en adquirirlo. Pero lo peor no es eso… lo peor es que se está jugando con los clientes (o futuros clientes). En palabras de Jobs, es un precio fantástico, 500€ por el modelo más básico. 500€ por un iPod Touch de 8GB de gran tamaño, el cual, ni es un tabletPC, ni es un smartphone, ni una PDA, ni un Netbook… desde mi punto de vista y como ya he dicho, un engendro extraño para intentar exprimir aun más a la gallina de los huevos de oro. Lo peor no es esto siquiera. Lo peor son las grandes limitaciones con las que se cuentan, las más criticadas desde la falta de reproducción HD, el no usar e-ink, el no disponer USB, el ser el software que tiene lo más restrictivo del mundo… es evidente que pagar 500€ por algo así es cuanto menos chistoso.

¿Pero cuanto vale? Yo no creo que sea un problema de precio como ya he dicho. ¿Lo comprarían las personas si costase 100€ menos? Personalmente no las tengo todas conmigo. Si fuese un dispositivo impresionante, aunque fuese caro se compraría. 500€ por algo así es una locura. ¿400€? ¿300€? Personalmente ni aun costando 300€ (200€ menos) pensaría en comprármelo. Por barato que sea, si no satisface ninguna necesidad, ¿para que gastarme el dinero? por 300€ podría encontrar un netbook que se adaptase completamente a mis necesidades.

Pero aun hay un punto mucho peor. Casi con toda seguridad Apple no tomará ninguna medida hasta que el iPad esté en la calle y compruebe en números la recepción. Pero… ¿qué pasará entonces si descubre que no se vende como se tendría que vender? ¿Lo rebajará entonces 100€ o 200€? Como le explicas entonces a los que se lo compraron por 100€ o 200€ más que ahora tiene un precio nuevo? Lo intentaría arreglar entonces con cheques regalos para que los usuarios puedan comprar por el Store de Apple por valor de 200€. Es decir, una bofetada con la mano abierta, como se suele decir, a los primeros compradores, como ya sucedió con el iPhone. Es decir, se dará el caso que un comprador de un día para otro pierda 200€ (o la cuantía por la rebaja de Apple).

Lo que si tenemos claro es que aun por ver que sucede en tiendas, ni es mágico, ni es revolucionario, ni tiene un precio increíble, ni es nada nuevo, ni satisface casi ninguna necesidad. Lo que tenemos claro es que incluso antes siquiera de que salga se está pensando en rebajar el precio. Que por cierto… deja claro el margen de beneficio que pueda tener Apple. Es decir… lo que pagas no vale ni de lejos lo que estás comprando.

Ya veremos que sucede… pero mi opinión es aun más clara. Primero la creencia de algo absurdo que no me serviría ni como posa-vasos costase lo que costase. Segundo, que todo aquel que pudiese plantearse el comprárselo, que esperase unos cuantos meses, no creo que le sentase muy bien que al mes siguiente costase sensiblemente menos.

Seguridad: Spoofing. Índice (Actualizado)

Bienvenidos al tema de Hoy: Spoofing, el arte del engaño.

 

Spoofing es un término genérico que puede ser aplicado a un buen número de cuestiones en la red. Todos ellos comparten la misma premisa, por tanto podemos definir el Spoof o la técnica de Spoofing a la falsificación de unos datos, modificándolos de algún modo para obtener por ello un beneficio.

Lo que vamos a intentar hacer aquí es explicar los diferentes ataques de Spoofing que podemos encontrar a día de hoy, intentando mostrar ejemplos de uso real y por tanto como podemos evitarlos:

Herramientas Utilizadas/Material necesario: (No todo es necesario, dependiendo de la plataforma a usar, de cada Spoofing y de lo que a cada cual le sea más cómodo)

  • Windows 7 x64 Ultimate -> OS principal (General)
  • Debian Squeeze x64 -> OS secundario (General)
  • Firefox 3.7a2pre
  • Thunderbird 3.2a1
  • Servidores Whois RIPE, ARIN, APNIC, LACNIC, afriNIC -> También útil usar la linea de comando “Whois” (IP Spoofing)
  • Servidor Proxy anónimo con soporte SSL -> Cientos en Internet (IP Spoofing)
  • NMAP -> Escaner de puertos (IP Spoofing, MAC Spoofing)
  • Winpcap -> Librerías para Windows para capturar frames (IP Spoofing, MAC Spoofing, Header Spoofing)
  • Wireshark ->Sniffer (IP Spoofing, MAC Spoofing, Header Spoofing)
  • Cuenta de Correos Gmail (IP Spoofing, eMail Spoofing)
  • Cuenta de Correos Live/Hotmail (eMail Spoofing)
  • AirCrack Suite (Linux) (MAC Spoofing)
  • Servidor Web con soporte PHP o hosting con iguales características (Web Spoofing)
  • Cliente FTP: WinSCP, FileZilla… (Web Spoofing)
  • Web Spider: HtTrack, wget… (Web Soofing)
  • Apache, PHP (Web Spoofing)
  • NoScript, Cookie Monster, Firebug-> Extensiones para Firefox (Web Spoofing)
  • User-Agent Switcher, Firebug-> Extensión para Firefox (Header Spoofing)
  • Paros Proxy (Header Spoofing)
  • Ncat (incluido en NMAP) ó NetCat, Telnet… (eMail Spoofer)
  • OpenSSL (eMail Spoofer)
  • hMailServer (eMail Spoofer)
  • Dig (eMail Spoofer)

 

Sobre SMS Spoofing, he decidido posponerlo conjuntamente con la versión PDF. Continuaré con la publicación de artículos, y posiblemente sea al final cuando revise todo el material, lo compacte, lo ordene… y lo lance todo como dios manda.

Seguridad: Spoofing. Capítulo Quinto -> eMail Spoofing

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados para poder pertrechar estos ejemplos  a vosotros, no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

eMail Spoofing

Casi con toda seguridad, conjuntamente con Web Spoofing, es el Spoofing más usado y/o peligroso que podemos encontrarnos estos días. Por otro lado es el Spoofing posiblemente que más personas identifican y tratan con él, aun cuando quizás no sepan que se llame así. Y es que a día de hoy, quien no ha recibido un correo electrónico que parecía venir de él mismo o de cualquier otro usuario, sin que evidentemente fuese dicho usuario quien lo había enviado. Aquí no se debe de confundir eMail Spoofing con virus que usan nuestras cuentas para reenviarse a nusetros contactos. Un virus en nusetro PC que se expande por correo electrónico usando nuestras propias herramientas, no es Spoofing.

¿eMail Spoofing? La técnica de modificar (generalmente) el remitente de un correo electrónico, con el fin de aparentar se un correo electrónico genuino. Esto evidentemente es una suplantación de identidad en toda regla, y es algo completamente ilegal. Para hacerse una idea, clonar una web (Phising) con el objetivo de engañar a alguien para que introduzca unos datos es ilegal porque casi con toda seguridad no tiene derechos de autor para usar el contenido de la web original. Pero nadie puede denunciarte porque una persona sea “estúpida” e introduzca unos datos en una web. En cambio, falsear un correo de forma que el remitente sea suplantado es ilegal. Al menos en españa, es ilegal la suplantación de identidad. Evidentemente el daño que puede causar este tipo de Spoofing es ingente en todos los ámbitos.

Esto crea por ende un debate moral sobre si este tipo de artículos deberían de ser escritos o no. La razón es evidente… de cada 10 personas que puedan leer este artículo, casi con toda seguridad más de la mitad no les importaría poner en práctica lo que aquí se pueda explicar para hacer uso de dichos conocemientos/formas. Similarmente al Phishing, eMail Spoofing es un problema más que real. En la medida que pueda intentaré llevar un compromiso entre lo que es informar y lo que pueda ser dar pautas exactas de como un lector malintencionado podría hacer cosas que no deberían de hacer. Aunque evidentemente no soy el padre ni la madre de nadie. Eso sí… estas prácticas son completamente ilegales y son delito penal. Más vale no jugar con este tipo de técnicas.

Ahora que hablamos de eMail Spoofing, deberíamos de hacer aparecer el término SCAM. En realidad, lo que hemos llamado Phishing anteriormente (a crear una web fraudulenta) lo más correcto es llamarlo SCAM, y llamar Phishing a la suplantación de identidad, generalmente debida al eMail Spoofing. He usado anteriormente Phishing para referirme a la web falsa puesto que el matiz de SCAM es la realización de un Phishing con fines fraudulentos. En mi caso no podría decirse que es un SCAM, dado que tan solo tiene fines didácticos. De cualquier forma ambos términos se suelen cruzar indistintamente, aunque personalmente para mi, la suplantación de identidad por eMail sería realmente el Phishing y el SCAM el Web Spoofing cuando se desea engañar a los usuarios para robar su información. De todos modos visto esto, aquí no voy a hablar de Phishing para no confundir a los lectores, solamente de eMail Spoofing, pero lo explico porque al final de todo hablaremos de Phishing.

Como hemos dicho en otra ocasión, el problema de estos sistemas y/o ataques no reside en que Internet sea más o menos segura, sino en la intención de cada persona. Si diseñas una tecnología basada en la censura y en el recorte de libertades tendrás posiblemente un sistema mucho más seguro… pero que llega a infinitamente menos personas, erradicas la libertad. Internet por ahora (y espero que siempre) es un lugar libre, de tal forma que todo el que quier puede formar parte y construye esa Internet, sin pasar por gobiernos ni leyes absurdas. Esto implica que la mayoría de todos los protocolos en Internet son en su mayoría simples y pensados para ser usados por cualquiera, no están pensados para restringir las libertades, y eso produce que siempre existirán personas que quieran aplicar la tecnología para fines nada éticos o siquiera legales.

Antes de entrar en detalles, hay que comprender como se puede enviar un correo electrónico a Internet. Aunque para muchos un eMail no es más que un texto escrito en el ordenador y enviado a través de nuestro navegador gracias a los portales de Gmail o Live, los correos electrónicos son mucho más que todo ello. SMTP es el responsable de los correos electrónicos, es el protocolo que hace posible este envío de información. La mejor forma de comprender el sistema de eMail, es asimilarlo siempre al correo postal ordinario. Cuando enviamos una carta a un destinatario necesitamos conocer antes que cualquier otra cosa la dirección de dicha persona, su nombre y apellidos, código postal… y del mismo modo escribir un remitente (si queremos) en el sobre. Pues el eMail es exactamente igual, vamos a ver como podrían ser las equivalencias:

 

Correo Ordinario ————————————————–> Correo Electrónico

Destinatario: Nombre y Apellidos ——————————> Destinatario: Nombre y Apellidos (Por ejemplo: Theliel Smith)

Dirección: Calle y Número/bloque —————————–> Dirección: UserID y Realm (Por ejemplo: eMailSpoofing@Theliel.es, eMailSpoofing es el UserID y @Theliel.es el Realm)

Código Postal ——————————————————-> Registro MX en las bases de datos DNS (Por ejemplo: smtp.europe.secureserver.net)

 

Remitente: Nombre y Apellidos ———————————> Remitente: Nombre y Apellidos (Por ejemplo: Sandra Smith)

Dirección Remitente ———————————————–> Dirección: UserID y Realm (Por ejemplo:Sandra@live.com, Sandra es el UserID y @live.com el Realm)

Código Postal Remitente ——————————————> Servidor SMTP (Por ejemplo: smtp.live.com)

 

En realidad como se puede apreciar es simplemente llamar a cada cosa de forma diferente y comprender el esquema básico de esto. Cuando se comprende, se comprende igualmente los fallos de seguridad que podría tener el esquema, pero como digo, no se planeó que fuera un sistema rígido y restrictivo, sino abierto. Esta imagen tomada de la Wiki nos muestra más o menos el proceso:

Anque la jerga pueda ser complicada, es igual que si fuera un correo ordinario. Digamos que Alice quiere enviar un correo ordinario a Bob. Para ello rellena los datos en la carta y la tira al buzón. El cartero la lleva a la oficina postal de su localidad, es decir, la oficina que corresponde al código postal del remitente, que en un correo electrónico correspondería a su servidor SMTP. Una vez en la oficina, esa carta debe de ser procesada para saber su destino. Se comprueban los datos del destino (es decir de Bob), para conocer el destino del código postal escrito en la carta (o la entrada MX en caso de un correo electrónico). El ordenador devuelve al operario la oficina a la que deben de enviar dicha carta, es decir… la dirección de la oficina de correos que se encarga de dicho código postal. En el caso de un corro electrónico el ordenador que procesa dicha información se llama servidor DNS. Una vez que el operario de la oficina postal tiene los datos de a qué oficina enviar la carta (no a que dirección del usuario final) llama al transportista y envía todas las cartas para dicha oficina. En Madrid llegan todas las cartas destinadas a dicha oficina (paso 4 del gráfico). En dicha oficina se verifican las direcciones físicas de los destinatarios para comprobar que no hay errores y el cartero las repartirá de forma correcta. En el caso de un correo electrónico vemos que es exactamente lo mismo, los datos llegan al servidor que gestiona el servicio de correo electrónico del destino, este procesa el correo y lo entrega en la bandeja de entrada de su usuario.

No perdamos de vista el objetivo de esta parte, eMail Spoofing. En el esquema que acabamos de explicar y pensando en la suplantación, ¿Como podríamos modificar el remitente en una carta ordinaria? Es facil, tan solo escribiendo unos datos falsos en el remite de la carta. Con el eMail pasa exactamente lo mismo. ¿Pero entonces es así de simple? Sí y no, como de costumbre.

  • En primer lugar prácticamente ningun programa nos permitiría modificar el remitente del eMail.
  • En segundo lugar en los servidores SMTP existne medidas de seguridad para evitar el SPAM. Siguiendo con la misma analogía, imaginar que yo he puesto de remitente a Julia Robert con residencia en estados unidos. Cuando la carta la recoge el cartero imaginar que mira el remitente y ve algo así. El operario podría automáticamente romper la carta, puesto es imposible que el haya podido recoger una carta del buzón con tal dirección en su oficina postal. Es decir, un método de desechar esos correos fraudulentos sería automáticamente bloquear cualquier remitente que no pertenezca su nombre y apellidos, dirección y código postal de la oficina que recoge la carta. Esta medida es usada casi en el 100% de los proveedores de correo electrónico, de modo que con dicha protección, sería imposible pretender enviar un correo fraudulento usando un servidor SMTP concreto el cual no reconoce el remitente como legítimo.
  • En tercer lugar, la oficina podría ser aun más lista, y simplemente solicitar el carnet de identidad de cada persona que desea enviar una carta. Una vez se presenta el carnet de Identidad, es la misma oficina quien graba el remitente en la carta. Este otro sistema es también ampliamente usado con los correos electrónicos (evidentemente en similitud, no literalmente)

Es decir, aunque el protocolo inicial es simple, a raiz de sus más que normales carencias se han construido filtros y sistemas de seguridad para evitar el uso de la suplantación de identidad. Con todo esto se podría pensar que entonces no es posible realizar un eMail Spoofing, y todos sabemos que no es cierto. ¿Con todas estas medidas es posible realizar eMail Spoofing? Si, y existen 3 formas (que ahora mismo pueda pensar yo). Todas ellas tienen sus pros y sus contras. Antes de entrar en ellas vamos a explicar un poco que es un servidor SMTP relay.

Originalmente, no se contemplaba como hemos dicho problemas de suplantaciones de identidad ni cuestiones similares, y existian los llamados Servidores Relay abiertos. Dado que cualquier persona puede crear un servidor de correos, este servidor de correos se puede configurar como hemos dicho como se desee. Estamos acostumbrados a ver que nuestros servidores SMTP de gmail o de Live requieren de un nombre de usuario o una contraseña. Pero si se desease, podríamos crear un servidor de eMail que no requiriese autentificación de ningún tipo, y simplemente especificásemos remitente y destino (el que quisiésemos). Años atrás, estos relays abiertos eran muy comunes, el problema que tenía por tanto era que cualquier persona podía enviar correos desde estos servidores para crear cantidades ingentes de SPAM. Ante este problema, casi todos los proveedores de eMail actuaron bloqueando en listas negras los correos que proviniesen de ciertos servidores Relay abiertos. Esta fue la primera medida que se comenzó a tomar, y tal es el efecto que a día de hoy no estoy seguro de que quede algún servidor SMTP relay abierto.

Sin embargo, la posibilidad de poder modificar el destinatario de un correo no solo es negativo, muchas veces es una función necesaria. Imaginar por ejemplo cuando tenemos la propiedad de dos cuentas de correos diferentes y preferimos usar un solo servidor SMTP para ambas. Por ejemplo esto lo permite realizar gmail previa verificación de dirección de correo. Otro ejemplo clásico es alguna suscripción a algún servicio, y este servicio envía correos electrónicos directamente a nuestro nombre para que el destinatario pueda siquiere incluso con “responder” alcanzar nuestra dirección. Aun así, existen multitud de ocasiones en las que es deseable poder modificar los remitentes. Ante esta necesidad comenzaron a aparecer los servidores Relay cerrados.

A diferencia de los Relay Abiertos, los Relays cerrados son actualmente los servicios de correo electrónico que con más frecuencia nos son ofrecidos. Muchos quizás no comprendan la diferencia entre un servidor SMTP Relay y no Relay. Cuando usamos el término de Relay, nos referimos a un servidor SMTP que acepta conexiones teóricamente de cualquier usuario. Si pensamos por ejemplo en el servidor SMTP de Gmail: smtp.gmail.com, no deja de ser un servidor Relay, puesto que el mismo servidor SMTP es el que usan todos prácticamente. Lo que sucede es que es un Relay cerrado, con ciertas restricciones. Pero igualmente podemos encontrar servidores SMTP puros, dedicados. El ejemplo más clásico de estos servidores son algunos servidores de correos empresariales o particulares. Normalmente cualquier persona que posea un dominio o un servicio de hosting, puede crear su propio servidor SMTP sin necesidad de un servidor Relay (aunque se puede configurar como tal)

A día de hoy como se ha dicho, la mayoría de los servidores SMTP son relay, y cada uno implementa las medidas que cree necesarias. Por ejemplo, un servidor SMTP relay de una empresa lo normal es que permita el relay local-> local local -> Internet y bloque por defecto cualquier intento de acceso tipo Internet -> Internet Internet -> Local. Es decir, permite a los usuarios dentro de la propia red empresarial a enviar correos, pero dicho servidor relay está bloqueado externamente. Otro ejemplo sería gMail. Gmail permite el acceso local -> local local -> Internet Internet -> Local e Internet -> Internet. Pongo el ejemplo de Gmail a conciencia… si permite todo tipo de usos… ¿no debería de ser un servidor Relay abierto? No. Desde la época de los relay abiertos, muchos proveedores decidieron otra medida, rechazar todos aquellos correos que no realicen proceso de autentificación en su servidor de correos SMTP. Para el servidor destino es facil comprobar esto, tan solo tiene que realizar una conexión a nuestro servidor y comprobar si se requiere o no. La mayoría de los proveedores no permiten circular por sus redes correos que no han sido autentificados, o añadidos a una “lista blanca”. ¿Y que es la autentificación? Ni más ni menos las credenciales que necesitamos para poder enviar o recibir correos. Existen aun muchos servidores SMTP relay los cuales no es necesario realizar una autentificación, pero tienen filtros que impiden el relay de sus servicios Internet – > Internet Internet -> Local. Aunque todo esto suene un poco complicado, todo cobrará sentido más adelante con los ejemplos.

Veamos ahora sí las tres formas que podemos encontrar de eMail Spoofing:

 

Servidor de Email propio:

Como hemos dicho Internet es libre. Tu puedes agradecer a Gmail su servicio gratuito de Internet, pero también te sometes a sus políticas de Spam, a sus restricciones, a sus filtros… a fin de cuentas gMail es tu oficina de correo postal. Pero si internet es libre… ¿puedo construir un servidor de correos yo mismo? Sí. Es decir, es como si pudieses crear tu propia oficina postal. Al ser tu servidor, tu eliges las normas. Internet la construimos todos, el protocolo SMTP es estandar y cualquiera puede usarlo. Por tanto podríamos crear un servidor SMTP en casa y arreglarlo todo de tal forma que prácticamaente podríamos enviar correos desde el remiente que quisiésemos. ¿Por qué? Ya lo hemos dicho, nosotros decimos las normas que queremos. Ojo!! esto no quiere decir que los correos sean completamente anónimos ni mucho más lejos.

Vamos a expandir esto un poco más. Si hemos comprendido el esquema de funcionamiento de un eMail, para crear nuestro propio servidor lo que hay que hacer sería primero crear nusetra “oficina”. Lo segundo para que nuestra oficina sea localizable tener en las bases de datos mundiales nuestro código postal registrado, en nuestro caso, tener registrado nuestro MX en los servidores de DNS. Y nada más.

En realidad no es necesario tener un registro MX si no deseamos recibir correo, el problema de este sistema es que por razones de seguridad y propensión a usar SPAM con estos sistemas muy simples de crear, la mayoría de los servidores destino no permiten correo procedente de aquellos clientes que no posean un registro MX o que procedan de IPs que sean estáticas. Por lo demás todo es muy simple. Tan solo sería cuestión de usar cualquier software servidor de correos, configurarlo y listo. No voy a explicar a hacer esto paso a paso, en este caso tan solo vamos a ver los resultados, pros y contras. En mi caso he usado hMailServer, un servidor de correo gratuito.

Para este primer ejemplo de eMail Spoofing se ha usado el servidor eMail citado. En cada una de las pruebas siempre se han enviado dos copias de los correos con remitentes falsos, una a gmail y otra a live (hotmail). En una de las pruebas se optó por usar una dirección falsa de Hotmail y en el otro caso una dirección falsa de gmail. El tercer test se optó por una dirección prueba test.com.

Los resultados son interesantes, y demuestran puntos a favor y en contra de cada proveedor (gmail y hotmail) a la hora de manejar posibles suplantaciones de identidad. Evidentemente tanto la cuenta de correo theliel@gmail.com y theliel@hotmail.com, no me pertenecen.

 

Prueba 1: Remitente theliel@hotmail.com, destino mis cuentas de gmail y live:

Gmail en este caso si permitió el acceso del correo y este alcanzó la bandeja de entrada.

Hotmail permitió la recepción pero fue filtrado una vez más como Spam -> Ver notas después de las pruebas


Prueba 2: Remitente theliel@gmail.com, destino mis cuentas de gmail y live:

Gmail no permitió siquiera la entrada del correo, dado que verificó que el remitente theliel@gmail.com tan solo podía enviar correos usando el servidor SMTP de gmail, y no uno externo. El correo no llegó a abandonar mi gestor de correos.

Hotmail permitió la recepción del correo, pero en este caso llegó como Spam -> Ver notas después de las pruebas

 

Prueba 3: Remitente theliel@test.com, destino mis cuentas de gmail y live:

Gmail filtró el primer correo como Spam, pero sucesivos correos del mismo destino alcanzaron la bandeja de entrada

Hotmail lo volvió a filtrar como Spam -> Ver notas al final de las pruebas.


Live Spam



Gmail Inbox


En principio se podría pensar que Live tiene un filtrado de Spam mejor que Google. Pero esto esto tiene muchas lecturas. Efectivamente Gmail rechazó de pleno un supuesto correo de gmail (theliel@gmail.com) simplemente presuponiendo que un correo de ellos tiene que provenir de ellos. Pero fracasó en las otras dos pruebas, dando por buenos los correos con los remitentes falsos. Por otro lado Live los categorizó todos como Spam.

Cada proveedor tiene sus propias políticas de que es mejor filtrar o que no. Por ejemplo, es evidente que el correo Theliel@hotmail.com era un remitente suplantado, pero Gmail prefirió no establecerlo a priori como Spam, lo que causa que en ese aspecto debemos de suspender a Gmail. Pero por otro lado bloqueó completamente Theliel@gmail.com. Live por su parte prefirió no bloquear completamente el correo que provenía supuestamente desde sus propios servidores “Theliel@hotmail.com”, lo cual es un punto negativo para Live. No obstante fue capaz de filtrar los otros dos correos falsos.

La política por defecto de Gmail es “Ante la duda, lo permito”. La política de Hotmail es “Ante la duda lo bloqueo”. Esto no solo es una cuestión de políticas por desgracia… sino de dinero. Microsoft con Live presupone que no puedes o no debes de tener un servidor de eMail en tu casa a menos que seas una empresa. En realidad a Microsoft no le importa el remitente del correo, no los detecta como Spam por ello. Si detecta que posees una IP dinámica ellos presuponen que eres un Spammer. Por otro lado, puedes pagar a Microsoft un dinero para que categoricen tu dominio como verificado, para que no sea filtrado como Spam. Esto parece injusto, ya que si Internet es libre, cualquiera podemos querer tener un servidor de Email sin dar cuentas a nadie, y no por ello somos unos Spammers. Google presupone inocencia, y mientras no tenga más datos sobre el origen de dichos correos no lo categoriza como Spam y lo permite, eso sí… bloquea los correos que no proceden de sus servidores y que es de ellos… cosa más que normal.

A todo esto hay que sumarle un gran problema de seguridad respecto al Spam que tiene Live. Quitando alguna que otra dirección, siempre se pasará a la bandeja de entrada (y no se considerará Spam) correos de direcciones que ya se han recibido. Es decir, supongamos que en realidad Theliel@hotmail.com ó Theliel@gmail.com fuese la dirección de un amigo mío y en mi cuenta live ya tuviese algún correo de ellos, ninguno de los dos correos sería filtrado como Spam. Esto es un peligro. Esto es posible pq Live presupone que los correos no marcados como Spam, son remitentes seguros.

En realidad no podemos ni debemos darle un tirón de orejas a ninguno. Cada cual implementa las políticas que creen más acertadas para filtrar la mayor cantidad de Spam posible y no filtrar los correos que crean que son legítimos. Pero como en todo, no hay un sistema que sea realmente mejor que otro.

Este sistema de eMail Spoofing se ha podido ver cuales son sus principales deficiencias. Si bien es algo sencillo y rápido de pertrechar, es muy fácil que cualquier proveedor de servicios pueda detectarnos. Por supuesto, y aunque no haya sido comentado, detectar un usuario este tipo de ataques de eMail Spoofing es muy simple, tan solo tendríamos que acudir a la cabecera del correo entrante:

Delivered-To: xxxxxxx@gmail.com
Received: by 10.103.197.9 with SMTP id z9cs22623mup;
        Sun, 7 Feb 2010 10:54:05 -0800 (PST)
Received: by 10.103.85.4 with SMTP id n4mr3722461mul.128.1265568845523;
        Sun, 07 Feb 2010 10:54:05 -0800 (PST)
Return-Path: 
Received: from localhost (30.Red-79-158-250.staticIP.rima-tde.net [79.158.250.30])
        by mx.google.com with SMTP id u26si17461538mug.45.2010.02.07.10.54.05;
        Sun, 07 Feb 2010 10:54:05 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning Theliel@hotmail.com does not designate 79.158.250.30 as permitted sender) client-ip=79.158.250.30;
From: Theliel 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1
MIME-Version: 1.0
Subject: Test
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Prueba 1

Se puede apreciar perfectamente la IP origen de dicho correo, así como la resolución inversa de ella, que se aprecia claramente como proviene de telefónica. Por otro lado se puede ver el registro de Google sobre si es SPAM o no lo es. Si leemos lo que nos dice, es un aviso. El host citado no está designado como un emisor permitido.

 

Servidor Relay SMTP Sin Autentificación

La segunda opción y posiblemente la más usada a la hora de realizar eMail Spoofing, reside en los servidores Relay. Hemos dicho que prácticamente todos los servidores Relay tienen fuertes medidas de protección para evitar el Spam o la suplantación de identidad. Como hemos dicho a día de hoy continua siendo necesario el papel de los servidores Relay en los cuales NO EXISTE autentificación previa. Lo que sucede es que estos servidores están disponibles normalmente tan solo a grupos de clientes que pagan por usar dichos servicios como servicios de email o de hosting, y normalmente con un número determinado de correos diarios permitidos. Por otro lado, generalmente no se permite su uso externo. El concepto de local o internet se debe de comprender. Si por ejemplo posemos un hosting que nos permite usar su servidor Relay e intentamos hacer uso de él desde nuestro propio equipo, pronto se dará cuenta cualquiera que la conexión es denegada, puesto que nuestro proveedor tan solo permite el uso del Relay en local. ¿Que implica esto? Que no podemos directamente hacer uso de dicho servidor, pero dado que en dicho servidor podemos tener herramientas como SSH, PHP… podemos crear formularios o accesos remotos para poder usar dichos recursos. La idea es claramente poder crear contenido web que nos permita la creación de formularios y otros que llamen a nuestro servidor relay. Dado que el formulario se encuentra en nuestro servidor web, podrá utilizar el servidor Relay de nuestro proveedor.

Esto tiene una ventaja y un inconveniente. Al ser un servidor “abierto” (que no requiere de autentificación) podemos enviar cualquier correo que deseemos en nombre de quien sea sin preocupación alguna, y casi con toda seguridad el correo será entregado y no filtrado como Spam. ¿El problema? Es necesario crear un formulario web para ello o usar SSH para conexión remota o algún sistema similar. Para evitar este tipo de prácticas abusivas de Spam, normalmente existe como he dicho un número finito de correos que pueden ser enviados al día.

Tanto esta sección como la siguiente, realizaremos conexiones directas en terminal para mostrar los ejemplos, esto nos hará comprender de una forma mucho más clara como funciona SMTP y el potencial que tiene. Veamos ahora el uso y conexión de un servidor SMTP Relay sin autentificación. Cualquier respuesta por parte del servidor va antecedida con un código númerico. El resto de texto corre a cargo por el cliente, es decir… tecleado a mano. Recordar que en rojo se resaltará siempre datos modificados por cuestiones de seguridad.

theliel@Anarchy:~$ ncat -C smtp.relay.com 25
220 smtp.relay.relay.com ESMTP
EHLO TEST
250-smtp.relay.relay.com
250-PIPELINING
250 8BITMIME
Mail from:
553 sorry, your mail was administratively denied. (#5.7.1)
mail from: 250 ok
rcpt to: 553 sorry, relaying denied from your location [79.158.250.30] (#5.7.1)
quit
221 smtp.relay.relay.com Goodbye.

Como se puede observar, este servidor relay en concreto tiene una lista negra de hosts que no se pueden especificar como remitentes (a priori). Cualquier intento de crear un remitente gmail, live, hotmail… devolverá el error mostrado. No obstante en principio, cualquier otro host no tan “famoso” es completamente aceptable. Aun así esto no implica nada, ya veremos que el secreto último del Spoofing no se encuentra en la orden “mail from” del protocolo SMTP. Como se puede observar el servidor no solicita ningún tipo de autentificación (vendría listada como se verá más adelante). Por último podemos ver la protección de dicho servidor de no permitir conexiones externas. La IP mostrada es mi IP de telefónica en este momento, y el servidor la rechaza por ser una dirección externa a él. Es decir, para poder usar este servidor relay es necesario usarlo dentro de la misma infraestructura. ¿Como podemos realizar esto? Ya lo hemos dicho, o por medio de PHP y un formulario web por ejemplo, o quizás podamos realizar un telnet al servidor desde dentro del propio servidor mediante una conexión SSH:

-bash-3.2$ telnet smtp.relay.com 25
Trying xxx.xxx.xxx.xxx
Connected to smtp.relay.com (xxx.xxx.xxx.xxx).
Escape character is ‘^]’.
220 smtp.relay.relay.com ESMTP
EHLO TEST
250-smtp.relay.relay.com
250-PIPELINING
250-SIZE 30457280
250 8BITMIME
mail from: 250 ok
rcpt to: <xxx@gmail.com>
250 ok
data
354 go ahead punk, make my day
From: Theliel To: Theliel <xxx@gmail.com>
Subject: Test

Prueba relay
.
250 ok 1265487183 qp 5150 by smtp.relay.relay.com
data
503 MAIL first (#5.5.1)
quit
221 smtp.relay.relay.com Goodbye.
Connection closed by foreign host.

En esta ocasión, el servidor no devuelve un error dado que se está ejecutando en local. El servidor está protegido para que no se acepten identidades (mail from) desde Gmail, pero en cambio, en el mismo cuerpo del mensaje si es posible especificar el remitente con “From”, en el cual si es posible especificar gmail, live o la dirección que se desee. El correo mostrado es entregado a la perfección a la bandeja de entrada de mi cuenta gMail. En este punto hay que recordar algo que se comentó anteriormente. Muchos servidores no aceptan el paso de correos por sus servidores si este no está autentificado. En este caso estamos enviando un correo sin autentificación, lo cual quiere decir que existirán servidores que no permitan la recepción desde este tipo de servidores… este es el ejemplo de live. En realidad es un problema y una falta de respeto por parte de Microsoft, dado que esto es posible usarse con fines legítimos. Por el contrario si pagas a microsoft podrías hacer que el servidor se añadiese a una lista blanca que permitiese su uso sin necesidad de autentificación.

Hay que tener en cuenta que este tipo Spoofing es altamente anónimos. Sí, nuestra IP quedará registrada en el servidor relay, pero ¿qué sucedería si realizáramos la conexión SSH mediante un servidor proxy?

La búsqueda de servidores Relay “abiertos” es algo muy interesante. Permite a los atacantes un alto índice de Spam sin apenas molestarse lo más mínimo aprovechándose de las infraestructuras de terceros. Por otro lado, si se tuneliza el tráfico mediante un servidor proxy, esto brinda un anonimato increíblemente alto. Aquí somos personas de bien, y dado que todo esto tan solo tiene fines didácticos no me importa no tunelizar el tráfico por un proxy. Lo que estábamos comentando es la búsqueda de servidores Relay “abiertos”. ¿Pero como hacerlo? Ya hemos dicho que para que un servidor pueda ser alcanzado, debe de tener un registro MX asociado a él en los servidores de DNS. Estos registros MX nos están diciendo directamente el servidor SMTP “al descubierto” que tienen. Gracias a herramientas como DIG, podemos consultar estos registros e intentar encontrar un relay abierto en dicho servidor:

C:\Users\Theliel>dig gmail.com MX

; <<>> DiG 9.7.0rc2 <<>> gmail.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 85
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com. IN MX

;; ANSWER SECTION:
gmail.com. 3008 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3008 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3008 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3008 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 3008 IN MX 40 alt4.gmail-smtp-in.l.google.com.

Un buen punto de partida sería comenzar por el servidor SMTP con una preferencia menor (supuestamente el primero a usarse). A continuación comprobar si se puede hacer algo con dicho servidor:

C:\Users\Theliel>ncat -C gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP 31si565032vws.79
EHLO TEST
250-mx.google.com at your service, [79.158.250.30]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING

Bingo!! El servidor no responde con ninguna línea de que necesite autentificación, luego a priori podríamos pensar que hemos encontrado un buen objetivo. Si profundizamos un poco más:

250 PIPELINING
mail from: 250 2.1.0 OK 31si565032vws.79
rcpt to: 550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient’s email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596 31si565032vws.79
rcpt to: 250 2.1.5 OK 31si565032vws.79

Con lo que nos muestra, ya podemos hacernos una idea de lo que está pasando. Efectivamente es un servidor relay abierto, pero tan solo permite conexiones local -> local internet -> local. Es decir, podemos falsear como deseemos con él nuestra identidad, pero el destinatario tan solo puede ser un correo “gmail”, es decir, una dirección local. Si llegamos a enviar el correo a nusetra cuenta de gmail, efectivamente el correo es recivido por nuestra bandeja de entrada, dependiendo de la IP desde donde lo hagamos, será filtrado como Spam o no.

Lo importante en este caso no es si el correo se filtra como SPAM o llega, lo importante es ver como con dos simples pasos es posible “apropiarse” de un servidor relay. No es malo, solamente sucede que todo puede ser usado para fines buenos o fines malos. Por último veamos que sucede si hacemos lo mismo con live:

C:\Users\Theliel>ncat -C mx1.hotmail.com 25
220 bay0-mc3-f33.Bay0.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft’s computer network is prohibited. Other restrictions are
found at http://privacy.msn.com/Anti-spam/. Violations will result in use of equipment located in California and other states. Mon, 8 Feb 2010 04:18:2
6 -0800
EHLO
250-bay0-mc3-f33.Bay0.hotmail.com (3.10.0.73) Hello [79.158.250.30]
250-SIZE 29696000
250-PIPELINING
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-AUTH LOGIN
250-AUTH=LOGIN
250 OK

En este caso el servidor con el que hemos dado requiere autentificación, luego tan solo podríamos usarlo en caso de tener unos credenciales válidos. Aun así, se podría comprobar su seguridad, pero por ahora estamos buscando servidores sin autentificación, y en este caso es un palo de ciego (pero si no se intenta, no se puede saber). En teoría, cuando se solicita autentificación se dice… pero que suceed si intentamos forzar aun así?:

mail from:
250 test@hotmail.com….Sender OK
rcpt to:
250 test@live.com
data
354 Start mail input; end with .
From: Theliel
To: Theliel
Subject: TEST

Prueba 10
.
250 mail from IP 79.158.250.30 soft failed sender ID check. Please ensure this IP is authorized to send mail on behalf of [hotmail.com]

Bueno… se ha intentado. Efectivamente contra todo pronóstico, el servidor no nos ha expulsado por no estar autentificado, pero aun así los servidores de MS no permiten usar dicho relay si no se tiene una IP autorizada para ello… y evidentemente la mía no lo es.

Prácticamente cualquier registro MX que veamos puede ser susceptible a ser utilizado por un atacante, el problema es que normalmente tendrán alguna política de restricción. Otras veces podemos comprobar que existen diferentes registros MX. Que un registro MX nos lleve a un servidor SMTP más protegido, no implica que otro pueda no pueda llevarnos a un servidor menos desprotegido. Estos servidores no es que sean todos inseguros, lo que sucede como ya dijimos en su momento, es que siempre se presupone un uso debido de las tecnologías actuales. Aunque aquí pueda mostrar los riesgos que pueden existir, siempre defenderé un Internet limpia y libre. La mejor forma de evitar estos ataques es el conocimiento, por parte de los administradores de sistemas y por parte de los usuarios que pueden ver comprometida su seguridad.

 

Servidor SMTP Con Autentificación

El uso de servidores de correo propios tiene el problema de que casi todo el contenido será marcado como Spam. El uso de servidores Relay sin autentificación tiene el problema de que muchos proveedores filtran dichos correos. Lo ideal por lo tanto sería poder contar con servidores Relay los cuales podamos acceder con autentificación y que no estén filtrados por nadie. El problema de este tipo de servicios es que si te autentificas en un sistema, es mucho menos anónimo, por no decir que estos servidores puedan implementar grandes medidas de seguridad para evitar el Spoofing.

Lo primero que podríamos intentar es realizar lo que se hizo con anterioridad pero usando nuestra cuenta de gmail. El arte del “hacking” es presuponer que en algún momento los programadores metieron la pata, y esa metedura de pata se usa para lograr los fines. Un atacante esta premisa la conoce bien. Podemos presuponer que gmail es completamente invulnerable y no intentarlo, o tener la esperanza de hacer saltar por los aires la seguridad de ellos, buscando un olvido de los programadores. Vamos a presuponer que no conocemos en absoluto el sistema de correos de gmail ni de live, y queremos simplemente investigar un poco. En este caso lo más probable es que una búsqueda por registros MX no nos devuelva nada interesante, y dado que estamos buscando servidores SMTP con autentificación, vamos a tener que usar o partir de algún servidor del cual tengamos unas credenciales.

Primero vamos a ver como se comporta gmail. Necesitamos por lo cual los datos de acceso al servidor SMTP de gmail para ello:

Servidor: smtp.gmail.com, Puertos 25, 465, 587. En teoría, sabemos que el puerto por defecto es 25 y es el puerto por defecto también de STARTTLS. Por otro lado sabemos que normalmente 465 se usa para SMTP sobre TLS, y 587 suele ser usado para lo mismo. Visto esto, lo normal sería intentar acceder por puerto 25 para evitar TLS:

C:\Users\Theliel>ncat -C smtp.gmail.com 25
220 mx.google.com ESMTP 16sm3074639ewy.6
EHLO TEST
250-mx.google.com at your service, [79.158.250.30]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 PIPELINING
mail from:
530 5.7.0 Must issue a STARTTLS command first. 16sm3074639ewy.6

Lo cual nos está indicando claramente que por ese puerto tan solo podremos acceder mediante STARTTLS (un sistema similar a TLS… por así decirlo). Vemamos que obtenemos por los otros dos puertos:

C:\Users\Theliel>ncat -C smtp.gmail.com 465

C:\Users\Theliel>ncat -C smtp.gmail.com 587
220 mx.google.com ESMTP 24sm11618069eyx.6
EHLO TEST
250-mx.google.com at your service, [79.158.250.30]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 PIPELINING
mail from:
530 5.7.0 Must issue a STARTTLS command first. 24sm11618069eyx.6
quit
221 2.0.0 closing connection 24sm11618069eyx.6

En el primer caso se queda esperando… esto es normal. Mientras que STARTTLS inicia una sesión encriptada dentro de la propia sesión ya establecida, TLS/SSL desde el momento de la conexión se realiza una sesión encriptada. Por tanto se queda esperando a recibir los certificados e iniciar el proceso de encriptación del canal. En el segundo caso podemos compronar que el puerto 587 se está usando igualmente para STARTTLS.

Por tanto vamos a intentar conectar al servidor SMTP mediante STARTTLS y mediante TLS. Una vez establecido el canal seguro, deberíamos de poder hablar con el servidor SMTP como hemos estado haciendo anteriormente:

theliel@Anarchy:~$ openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:25
CONNECTED(00000003)
[ELIMINADO POR ACORTAR]
Start Time: 1265640813
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)

250 PIPELINING
EHLO TEST
250-mx.google.com at your service, [79.158.250.30]
250-SIZE 35651584
250-8BITMIME
250-AUTH LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250 PIPELINING
AUTH LOGIN
334 VXNlcm5hbWU6 <- Significa “Usuario”, codificado en base64 -> $echo “dGVzdEBnbWFpbC5jb20=” | openssl enc -base64 -d
dGVzdEBnbWFpbC5jb20= <- Significa “test@gmail.com” condificado en base 64 -> $echo -n “test@gmail.com” | openssl enc -base64
334 UGFzc3dvcmQ6
Y29udHJhc2XDsWFwcnVlYmE=
235 2.7.0 Accepted
mail from:
250 2.1.0 OK 26sm6346727fks.37
rcpt to:
250 2.1.5 OK 26sm6346727fks.37
data
354 Go ahead 26sm6346727fks.37
From: Theliel
To: Theliel <test@live.com>
Subject: Test

Prueba 1
.
250 2.0.0 OK 1265640966 26sm6346727fks.37
quit
221 2.0.0 closing connection 26sm6346727fks.37

Es necesario usar OpenSSL para poder iniciar la sesión y continuar con STARTTLS. En este caso Gmail acepta cualquier origen especificado en “mail from”. Esto podría ser un paraíso para los Spammers. Y es que aunque todo el proceso parezca que funciona perfectamente bien, cuando acudimos a la bandeja de entrada vemos que los servidores de Gmail han modificado el remitente, de forma que coincida con los datos de la autentificación. Es decir, da igual que se especifique en “mail from” ó “from”, gmail usará nuestra verdadera identidad. Luego mediante este servidor no es posible realizar un Spoofing. He optado por la autentificación “LOGIN”, la cual nos muestra por pantalla que introduzcamos el usuario y la contraseña. Tanto las peticiones como las respuestas se deben de hacer en base64

Podemos intentarlo por el puerto 465 y usando TLS:

C:\Users\Theliel>ncat -C –ssl smtp.gmail.com 465
220 mx.google.com ESMTP 23sm11723882eya.3
EHLO TEST
250-mx.google.com at your service, [79.158.250.30]
250-SIZE 35651584
250-8BITMIME
250-AUTH LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250 PIPELINING
AUTH PLAIN
334
AHRlc3RAZ21haWwuY29tAGNvbnRyYXNlw7FhcHJ1ZWJh
235 2.7.0 Accepted
mail from:
250 2.1.0 OK 23sm11723882eya.3
rcpt to: <test@live.com>
250 2.1.5 OK 23sm11723882eya.3
data
354 Go ahead 23sm11723882eya.3
from: Theliel
to: Theliel <test@live.com>
subject: Test

Prueba 2
.
250 2.0.0 OK 1265642518 23sm11723882eya.3
quit
221 2.0.0 closing connection 23sm11723882eya.3

Como podemos comprobar, obtenemos exactamente lo mismo. Aun así me ha servido el ejemplo para mostrar en este caso la conexión mediante SSL (se puede usar si se prefiere openSSL) y como en esta ocasión hemos preferido usar autentificación “PLAIN”. En este caso, se debe de introducir las credenciales en base 64 pero con un formato específico. La mejor forma de llevar a cabo esto es quizás utilizar algún lenguaje de scripting para que nos haga la labor más simple. Se podría componer pasando a base64 primero por un lado el ID, despues la arroba, despues el realm, despues la contraseña… es más comodo hacer lo siguiente en Perl:

“perl -MMIME::Base64 -e ‘print encode_base64(“\000test\@gmail.com\000contraseñaprueba”)'”

Nos quedaría otro método de autentificación por ver, que sería CRAM-MD5, el más seguro. De todos modos dado que que gmail solo permite mediante la creación de una sesión encriptada, no importa usar CRAM-MD5, el cual suele usarse cuando no es posible una comuncación cifrada.

En esta ocasión ninguna de las pruebas realizadas ha tenido ningún tipo de éxito, pero tan solo hemos probado con Gmail. Esto mismo podríamos hacerlo con cualquier servidor SMTP al cuan tengamos acceso. Como último ejemplo vamos a ver que sucedería con Live (hotmail):

ehlo test
250-BLU0-SMTP59.blu0.hotmail.com Hello [79.158.250.30]
250-TURN
250-SIZE 35840000
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-AUTH LOGIN PLAIN
250 OK
auth login
334 VXNlcm5hbWU6
xxxxxxxx
334 UGFzc3dvcmQ6
xxxxxxxx
235 Authentication succeeded
mail from:
250 2.1.0 test@hotmail.com….Sender OK
rcpt to:
250 2.1.5 test@live.com
data
354 Start mail input; end with .
from: Theliel
to: Theliel
Subject: TEST

Prueba 2
.
250 2.6.0 Queued mail for delivery

Bingo!! En un principio se podría pensar que sucede exactamente lo mismo que con gmail. En cambio, si miramos la bandeja de entrada ahora si que nos topamos con una interesante noticia… el mensaje llega correctamente a la bandeja de entrada y con el remitente completamente suplantado!! Vemos aquí un grabe agujero de seguridad por parte de MS, dado que cualquier usuario con una cuenta live unos cuantos conceptos podría suplantar cualquier identidad que quisiese y sin que el correo sea considerado SPAM. Evidentemente no es oro todo lo que reluce y si se mira un poco más a fondo uno comprobaría el origen REAL del correo. Pero en principio pasaría completamente por real.

Como hemos visto, es raro encontrar un sistema que sea completamente confiable y segudo. Cuanto más experimentas y pruebas, te das cuenta que prácticamente los fallos en la seguridad están a la orden del día. Muchos de dichos problemas son más que sabidos, pero quizás se necesitan tal y como están por otros motivos.

 

Hemos visto como un atacante podría crear un servidor de correo. Hemos visto como un atacante podría buscar y utilizar servidores relay. Hemos visto como podemos incluso usar nuestros propios servicios de correo para estos fines. Es decir, por desgracia es muy fácil a día de hoy suplantar una identidad. Esto sumado al Web Spoofing o URL Spoofing, es un arma terrible para los Spammers, Hackers… y toda la prole.

En la creación de esta parte, Email Spoofing, además de los datos suministrados, casi todos los servidores que he puesto a prueba con fines de redacción, antes o después mostraban una vulnerabilidad, un acceso, algo que podría mejorarse considerablemente.

Por tanto… ¿como podemos defendernos ante esta más que visible amenaza? Teniendo los ojos abiertos. No hay una norma… quizás la única es desconfiar, y cuando algo nos hace sospechar acudir a las cabeceras de los correos para ver la verdadera procedencia de este. En el mejor de los casos nos podrá decir el correo original, en el peor de los casos tendremos que conformarmos con la IP del remitente real. El peor escenario? que estén usando contra nosotros un servidor SMTP relay al cual se haya accedido mediante proxy, en cuyo casi no tendríamos prácticamente nada.

Es evidente que no se puede sospechar del 100% de los correos, pero si tener presente que en cualquier momento un correo de nuestra paraje, amigo, familiar… puede que no sea realmente de ellos. Por supuesto hay que tener en cuenta, que las personas no se dedican a esto para molestar, y que el 90% de este uso es con fines de SPAM, a fin de cuentas, tal y como comencé al inicio… ¿Quien no ha recibido alguna vez un correo falso?

Seguridad: Spoofing. Capítulo Cuarto -> Header Spoofing

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

Header Spoofing

En un principio, cuando puse en mente esta serie de artículos, tenía pensado hablar tan solo de Referred Spoofing, pero por extender un poco más esto y que se comprenda mejor, vamos a expandirlo a todo el Header.

En realidad no estoy seguro si el término Header Spoofing existe o no. Ya sabemos que es el Spoofing y ha quedado más o menos claro. Pero que es ¿Header? Header (o Cabecera) pueden ser muchas cosas (Perdonarme y permitirme muchas veces los términos anglosajones, soy un férrimo defensor de nuestra lengua castellana y comprendo que para la mayoría de toda esta jerga existen términos castellanos para ellos. No obstante la costumbre de trabajar con ellos siempre en ingles te crea el hábito).

Una cabecera en una carta sirve para especificar por ejemplo la fecha. En informática un header suele ser lo mismo, una serie de datos que preceden a otros. Nosotros nos vamos a centrar en el header de una web, pero como digo el ámbito es muy grande. Más adelante, en eMail Spoofing por ejemplo veremos el header de un correo.

Cuando accedes desde el navegador a cualquier web, se ponen en marcha una serie de procesos que son completamente transparente para el usuario. Primero peticiones DNS y después el request (o petición) de la web al servidor. Este recuest explicado en simple sería algo así como enviar por ejemplo a google un mensaje que diga: “Quiero acceder a tu buscador”, y google con un response (contestación) contestaría algo así como: “Este es mi buscador…..” y la web se visualizaría. En cada petición que se envía hacia un servidor web, así como en cada respuesta de estos a nuestro PC, existe una cabecera con una serie de datos muy interesantes. Estos datos son preconfigurados por nuestro navegador (en caso de los request) en función de las opciones propias del navegador o de la web que estamos en ese momento visitando. Por su parte, los headers de los response de los servidores están igualmente preconfigurado por los servidores de ellos en función de su configuración o de nuestros propios request.

El secretismo en todo esto está en que a efectos prácticos para el usuario, estos headers no los verá jamás, en cambio, sin darse cuenta, la visualización de una web puede ser completamente diferente, así como otro millar de cosas tan solo por esa cabecera. Luego… que sucedería si modificamos nosotros a voluntad esa cabecera? Si modificamos los request, podemos producir un comportamiento interesante por parte del servidor objetivo. Del miso modo si modificamos el header de un response, estaremos modificando el comportamiento de nuestro propio navegador ante un request. ¿Que utilidad tiene esto?:

  • Acceso a webs sin autorización
  • Acceso a webs alternativas
  • Búsqueda de exploits en Webs
  • Cheats para juegos online
  • Etc…

 

¿Que aspecto tienen? Eso ya lo sabemos… en estas páginas por ejemplo se han publicado headers. Pero vamos a ser más concretos. Vamos a ver cual sería el header de una petición desde mi navegador Firefox a www.google.es:

GET / HTTP/1.1
Host: www.google.es
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100203 Minefield/3.7a1pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.google.es/ig?hl=es
Cookie: PREF=ID=XXXXXX
Cache-Control: max-age=0

Cada una de las etiquetas mostradas (Host, User-Agent, Accept…) tiene su propia utilidad y es igualmente importante. Y todas ellas son establecidas por el navegador que estemos usando. Si realizamos exactamente la misma petición, pero desde Internet Explorer esto es lo que tendríamos:

GET / HTTP/1.1
Accept: */*
Accept-Language: es-ES
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0)
Accept-Encoding: gzip, deflate
Host: www.google.es
Connection: Keep-Alive
Cookie: PREF=ID=XXXXXX

Todas estas etiquetas de la cabecera de request, serán procesadas y/o ignoradas por el servidor destino, y este responderá con uno u otros datos de una u otra forma en correspondencia a estas cabeceras. Hay que decir que aunque estas cabeceras sean especificadas por el navegador, no quiere decir que sean inmutables. Las propias webs que se reciben, formularios que se rellenan… dan instrucciones también al navegador de como deben de solicitar dichos request. Es decir, es un círculo vicioso. El navegador es el primero en establecer una cabecera, y el servidor responde con una web. En dicha web, dependiendo de donde pulsemos o las acciones que llevemos a cabo, nuestro request incluirá información de estado de esta web y el servidor destino responderá del modo acordado a esa petición.

Por otro lado, también tenemos las cabeceras que son enviadas por parte del servidor a nuestro navegador. Su importancia suele ser menor, dado que lo que logran es modificar el comportamiento de nuestro navegador, algo que suele importar menos. No obstante también puede tener su utilidad como veremos más adelante. Vamos a ver los response de las peticiones anteriores:

HTTP/1.1 304 Not Modified
Content-Type: text/html
Date: Fri, 05 Feb 2010 15:40:46 GMT
Set-Cookie: IGTP=LI=1:LM=XXXXXXXXXX; expires=Sun, 05-Feb-2012 15:40:46 GMT; path=/ig; domain=www.google.es
Expires: Fri, 05 Feb 2010 15:40:46 GMT
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Fri, 05 Feb 2010 15:40:46 GMT
ETag: XXXXXXXXXXXXXXXXX
Server: igfe
X-XSS-Protection: 0

Algunas de las cabeceras son ellas mismas descriptivas y no hay que entrar mucho en detalle para comprender que significan o que función realizan, pero no por ello no dejan de ser importantes. Vamos a ver algunas de ellas:

 

-Etiquetas de Metodos y Etiqueta Host

Es la primera etiqueta que aparece, y es la única que podríamos decir que no es una etiqueta. No especifica ninguna cualidad del navegador, sino más bien como se han de obtener los datos, la URI de acceso y la versión del protocolo al que se está accediendo. Mi intención no es dar un repaso completo de cada una de las etiquetas de los headers, para eso tan solo tenemos que acudir a las especificaciones del protocolo. Por tanto vamos a centrarnos tan solo en lo que pueda ser más significativo, los métodos GET y POST. Aunque no sea una definición correcta, podemos decir que GET lo usará el navegador para obtener datos desde un servidor y POST cuando nuestra petición incluye datos que puedan ser significativos para el servidor, por ejemplo los formularios rellenos, credenciales de acceso…

En los dos ejemplos anteriores, la URI es “/”, es decir, se está obteniendo (GET) la ubicación raiz “/” del host especificado en la etiqueta “host”, en este caso “www.google.es”. No obstante la URI podría haber sido algo así como “/es” por ejemplo, para especificar el contenido dentro de “www.google” a recibir. Con esto hemos dicho también el significado de la etiqueta “Host”. Especifica el servidor al cual se desea realizar el acceso. La respuesta de la etiqueta Host por parte de response, podría venir dada pro la etiqueta Server, que especifica el servidor usado. En este caso “igfe” un servidor (software) propio de Google.

En el caso de los response, no aparecerá POST ni GET (entre otros), sino la respuesta a estos. Para ello, se especifica del mismo modo la versión HTTP que usará el servidor y un código que especificará información sobre el site que se ha solicitado. En el ejemplo anterior se contesta con un código 304 -> Not Modified. Es decir, en este caso implicaría que el contenido ha sido encontrado pero no ha sido modificado desde la ultima petición de este, posiblemente porque se ha realizado un refresh de la misma web. Como digo, podemos acudir a las especificaciones HTTP para conocer esto en detalle.

 

-Etiqueta User-Agent

Posiblemente una de las primeras etiquetas Spoofeadas en la historia. El User-Agent es un string, un identificador del navegador que estamos usando. Es una etiqueta fundamental, es la única forma que tiene el servidor de conocer el navegador que estamos usando. Esto es evidente tiene una importancia mayúsculas. ¿Por qué? Es obvio, cada navegador es diferente y usa tecnologías diferentes. Gracias a los User-Agent puedes especificar por ejemplo que tipo de contenido quieres para unos o para otros, puedes simplemente filtrar todas las peticiones de clientes específicos. Es decir, sin que lo sepamos, muchos contenidos que vemos en cada momento está dependiendo exclusivamente de dicho User-Agent. En los dos ejemplos, evidentemente cada User-Agent es completamente diferente.

Normalmente el User-Agent no solo brinda información de la versión del navegador o de su layout, sino incluso del OS que se está usando. En el primer caso, tenemos desde la versión de Firefox, la compilación, la versión del kernel NT (6.1 = Windows 7), incluso el lenguaje de Firefox. En el caso de IE los datos son similares, pero evidentemente referentes a IE.

 

-Etiquetas Accept y Accept Language

La primera especifica los tipos de archivos que aceptará, y si hay más de un tipo especificado, la preferencia de un tipo de contenido respecto a otro. La segunda el lenguaje aceptado, e igualmente que con Accept, si se especifica más de uno cada uno tiene una preferencia diferente. Normalmente esta última etiqueta la podemos nosotros modificar seleccionando otro idioma en las opciones de configuración del navegador. Ojo!! no tiene nada que ver el idioma del navegador, sino el lenguaje solicitado por el navegador. Si el servidor dispone de diferenciación de idiomas nos dirigirá al nusetro, sino, nos devolverá el idioma por defecto que tenga configurado el servidor.

La contestación por parte del servidor en su response de Accept, vendrá dada por la etiqueta Content-Type que especifica precisamente el tipo de contenido que será transferido.

-Etiquetas Accept-Encoding y Accept-Charset

La primera es importante, especifica el tipo de compresión soportada por nuestro navegador. Nuestro navegador envía al servidor una serie de parámetros (las etiquetas) y según estos el servidor podrá seleccionar que web mostrar. Si el servidor está usando compresión y nuestro cliente la soporta, el servidor enviará la información comprimida, ahorrando ancho de banda.

La segunda etiqueta simplemente especifica el conjunto de caracteres que se usará

 

-Etiqueta Cookie

Antes de comenzar… ¿que es una Cookie además de una galleta? Es un pequeño archivo de texto que almacena normalmente unos cuantos datos que son reutilizados después por las webs. Es la única forma que tiene una web de guardar datos en el PC del usuario. Estas Cookies son las que se encargan por ejemplo (normalmente) de mantener una sesión abierta en aquellos sitios que requieren una autentificación, o guardar un pequeño registro sobre algo. Pero por dichos motivos son también un objetivo muy importante. Si una Cookie se usa para que podamos acceder por gmail (por ejemplo), si esa cookie se traspasase a otro usuario, es posible que ese otro usuario pudiese acceder a la misma cuenta de correos que el otro, sin necesidad de conocer las credenciales (usuario y contraseña). Es decir, una cookie puede ser una llave a cualquier sitio que sea necesario autentificarse. Por esta razón, dichas cookies suelen tener una caducidad, así tenemos cookies de sesion (que son eliminadas cuando salimos del navegador) o cookies que son permanentes (o se borran). Por desgracia estas Cookies son usadas demasiado asiduamente para espiarnos o guardar un seguimiento nuestro. Dado que la cookie es accedida también por el servidor, se puede usar para contabilizar las veces que se accede a tal página, realizar seguimientos de las personas… en fin… todo tiene siempre un lado negativo.

Por lo tanto, es otra etiqueta de gran importancia. El navegador especificará la cookie de dicho lugar. Si en dicho momento aun no tiene ninguna cookie almacenada, creará una con el objeto de que pueda ser usada por el servidor si así la requiere. La importancia de poder modificarlas es por tanto muy grande. Las cookies, mientras que suelen estar almacenadas en nuestro PC en archivos, estas no se transmiten como archivos, sino en la cabecera, dentro de la etiqueta Cookie. Es decir, esta etiqueta lo que especifica es el contenido de dicho archivo. Modificar esta etiqueta por tanto implica modificar los datos que contiene la cookie. Evidentemente por motivos de seguridad, estos datos suelen ser ilegibles a simple vista, usando Hashes o algun otro sistema para que la información de estas cookies no sea visible de forma simple (o sea imposible).

 

-Etiqueta Referer

Esta etiqueta es fundamental en muchos aspectos. Lo que realiza esta etiqueta es especificar la web desde la que estamos accediendo a la nueva página. Su uso es claro. El servidor puede actuar de una forma u otra dependiendo de cual era el origen. Un ejemplo muy sencillo a esto es cuando accedemos desde Google images a cualquier imagen y el servidos nos devuelve un error diciendo que la imagen no puede mostrarse porque no se permite su “enlazamiento” desde otro lado. ¿Como sabe el servidor que estamos accediendo desde google? gracias a esta etiqueta.

En cambio, posiblemente el uso más extendido de Spoofing de esta etiqueta sea el del acceso sin autorización a sitios de pago, generalmente páginas pornográficas. Estos sites, suelen permitir con la misma inscripción a un site concreto navegar por otros sites que no son de su propiedad. ¿Pero como sabe ese otro site si el usuario puede o no puede acceder? O ese otro site tiene acceso a la misma base de datos para poder reconocer usuario/contraseña, o simplemente permite el acceso siempre y cuando la etiqueta referer provenga de un site pactado. Es decir, modificando a voluntad una etiqueta referer, es posible acceder a muchos sitios pornográficos de pagos, dado que dichos servidores cotejarán dicha etiqueta por si proviene el usuario de un site con acceso dicho contenido.

 

-Etiqueta Cache-Control

Esta etiqueta la encontramos de forma predominante los response por parte del servidor. En teoría es una orden de como el navegador debe de manejar el caché para dicha página. El caché de un navegador guarda en disco ciertos contenidos de una web para poder acceder a ella más adelante de forma más rápida y eficiente. Pero es evidente que todo el contenido no siembre es bueno cachearlo. Si se cachea y usa el contenido de la caché en vez del deservidor siempre se corre el riesgo de que los datos que estemos visualizando no sean correctos. Un buen manejo del caché podría ser por ejemplo marcar el contenido estático como puedan ser imágenes, scripts… con una duración mayor al que pueda tener por ejemplo un html dinámico con contenido de texto que está casi continuamente cambiando.

Si controlamos el valor de este campo, podríamos obligar a nuestro navegador que cachease el contenido o que no lo hiciese, ambos casos pueden ser útiles en momentos concretos.

 

Aquí tan solo vamos a dar unas pautas de como modificar estas etiquetas. En teoría se puede modificar cualquier cabecera, lo que no quiere decir que pueda ser útil. Por ejemplo, la utilidad de modificar la etiqueta “Accept Language” sería un poco absurdo, dado que puede ser modificada a voluntad en el mismo navegador. Por cuestiones evidentes no puedo poner un ejemplo de Referer Spoofing de una web adulta, pero puedo poner otros ejemplos que pueden extrapolarse a cualquier uso real. Recordar que Spoofing es engañar, modificar… y eso es lo que pretendemos. Vamos a ver ejemplos de Referer Spoofing, Cookie Spoofing y User-Agent Spoofing. Las herramientas que podamos usar para estas prácticas pueden ser más o menos las mismas siempre. Ya que lo que vamos a realizar es modificar estos headers, necesitaremos algo que nos permita interceptar estos datos, y básicamente vamos a encontrar dos formas: La primera con alguna herramienta del mismo navegador web (Bienvenido sea Firefox). La segunda por medio de un Proxy que nos permita modificación “al vuelo”. Para ello vamos a usar algunas extensioens de firefox y como Proxy por ejemplo Paros.

 

User-Agent Spoofing:

Vamos a ver un ejemplo simple de como afecta en el navegador este User-Agent. Lo bueno para muchos es que para aquellas prácticas que están relativamente expandidas existen utilidades para realiza dicha tarea de forma simple. Por ejemplo tenemos herramientas en Firefox que nos permiten especificar directamente que User-Agent queremos usar.Vamos a hacerlo de las dos maneras. Para ello vamos a ver que ocurre cuando llamamos a “www.google.es” con el User-Agent por defecto de mi navegador y que ocurre si invocamos la misma página con el User-Agent del iPhone 3.1.3:

Mi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100205 Minefield/3.7a1pre

iPhone 3.0 User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16

 

Trabajando solo con Firefox (Firebug+User-Agent Switcher):

Ventana de Firebug -> Net -> HTML -> Headers

Configuración User-Agent Switcher

En las dos primeras imágenes podemos comprobar perfectamente como sería una petición básica a www.google.com y como se configuraría un User-Agent dentro de User-Agent Switcher. Firebug es sin duda una herramienta potentísima que puede hacer las delicias de muchos, es una de esas herramientas que cuanto más usas, más aprecias, capaz de hacernos la vida mucho más fácil a los programadores/diseñadores webs.

Google para iPhone y nuevo User-Agent

Al establecer el nuevo User-Agent, el servidor www.google.es considera que la petición se está realizando desde un iPhone, y lo resuelve enviando la web específica para dicho dispositivo. Es tan solo un ejemplo de la importancia de este simple identificativo.

Pero al igual que hemos realizado esto con herramientas de andar por casa (a fin de cuenta una extensión en firefox no deja de ser una extensión), la mejor forma de realizar esto (puesto que no solo nos va a servir para este caso concreto) es la utilización de un servidor proxy que nos intercepte todas las peticiones realizadas:

Paros Proxy, examinando una cabecera
Paros Proxy, modificando una cabecera

Paros Proxy es un software gratuito, sin la complejidad de tener que instalar un servidor proxy completo. Como se muestra en la primera imagen tan solo captura las peticiones que se van realizando, y al finalizar la carga es tan simple como examinar las cabeceras. Una vez localizado el objetivo, es tan facil como poner un “cepo” (trap) a los request, de este modo antes de que sea enviado nuestro request, podremos modificarlo a voluntad.

Aunque no se muestra el resultado final, el efecto es exactamente el mismo que el mostrado anteriormente, salvo que queda de manifiesto el potencial de una herramienta así, dado que con ella podremos modificar no solo el User-Agent, sino lo que deseemos, tanto de los request como de los responses.

 

Referer Spoofing

Ya hemos explicado lo que es, y en User-Agent Spoofing se han dado pautas de como podría realizarse cualquier Header Spoofing. Mi objetivo original era explicar un poco por encima tan solo el Referer Spoofing, y al final será el menos especificado.

En realidad la imaginación es el límite.Cuanto más es usada una etiqueta, más beneficioso podría ser poder controlarla. En este caso hemos dicho que Referer Spoofing se suele controlar para conocer la web de procedencia que nos ha originado en dicho lugar. Mi idea originar era poner una web adulta de ejemplo, pero por cuestiones de edad y de privacidad he decidido no hacerlo. Podría mostrar tan solo imágenes de las propias cabeceras… pero entonces no lograría el objetivo de ver un antes o un después, como hemos realizado con el User-Agent.

Otros ejemplos notables del control de esta etiqueta es para filtrar contenido. Esto es muy usado en blogs y otros sites que no desean que su contenido pueda ser enlazado desde el exterior, mostrando una imagen “falsa” (o mejor expresado, diferente de la esperada) en caso de que sea enlazada con una referencia href. A fin de cuenta, cuando se enlazan imágenes u otros tipo de contenido de forma directa, el ancho de banda corre a cargo de la web original. Por parte de los servidores esto se evita con filtrados en el servidor web, y para evitarlo basta con modificar la etiqueta referer.

 

Cookie Spoofing

Esta etiqueta siempre será objetivo de incesantes ataques. Tal es así que prácticamente todas las cookies actualmente tienen algún tipo de encriptación o modificación para que no se pueda apreciar de forma clara que es lo que realiza.

No obstante, muchas veces este “cifrado” puede ser reversible o se puede inferir por el contenido. Otras veces no importa siquiera el contenido de dicha Cookie, y modificándolo a gusto se pueden obtener resultados igualmente satisfactorios.

Un ejemplo aplicado de esto fue usado por ejemplo en mi Artículo sobre Hammerfest, el cual por cierto tengo que rehacer. ¿Por qué fue necesario Cookie Spoofing para dicho artículo? Hammerfest es un juego Online que tan solo permite 3 cuentas máximas asociadas a un mismo PC. Si intentas crear una cuenta para jugar por encima de dicho número, el servidor te lo impedirá. Para poder hacer esto, el servidor tiene algunas opciones. Una podría ser verificando la IP, pero dado que la mayoría de las IPs son dinámicas, no serviría de mucho. La otra opción es por Cookies. El navegador cada vez que intenta acceder envía su cookie al site. El site coteja el ID de dicha cookie (por así decirlo) en su base de datos. Si ya tiene asociada a ella 3 usuarios no permite más. Aunque se elimine la cookie del navegador no ocurre nada, puesto que nada más conectarse el navegador especificará la cookie que usará (aunque esté vacía), la cual tiene el mismo ID, la cual será cotejada. ¿pero que sucede si cambiamos el ID de la cookie? El servidor pensaría que estamos desde otra máquina, almacenaría la nueva ID y nos daría acceso a otras 3 cuentas más para ser creadas.

En el ejemplo puesto, no es necesario siquiera conocer que tipo de ID está usando el servidor, con modificarlo por un valor arbitrario tendremos suficiente.

La importancia del Spoof de cookies tiene mayor importancia cuando conocemos la cookie de sesión de otro usuario, dado que si usamos sus datos para modificar la nuestra, podremos tener acceso a su sesión. Se puede pensar que es complicado conocer la cookie de otro usuario… pero no es complicado en realidad. Formas de obtener estos datos podrían ser mediante Snifers o XSS. En su momento veremos esto, pero por ahora vamos a verificar que puedo iniciar sesión en Internet Explorer en mi cuenta de Gmail sin pasar por el nombre de usuario y contraseña. Esto se puede hacer en dos fases. La primera “espiando la Cookie de Firefox y dirección una vez la cuenta está abierta, y en la segunda parte simplemente usar dicha cookie en IE. Recordar que la cookie en el PC no deja de ser un archivo, pero se especifica directamente en forma de datos en la misma etiqueta Cookie:

Cookie de Sesión y URL gMail

Evidentemente por motivos de seguridad he emborronado los datos propios. Aquí lo importante tan solo es la URL completa y la Cookie. Imaginar ahora que accedemos a IE, pegamos la URL que tenemos en gMail e interceptamos la Cookie enviada por IE y la modificamos por la que obtenemos en Firefox

Inserción Cookie en IE

Aunque pueda verse un error de certificado, esto no es importante. Dado que Gmail usa HTTPS, cualquier modificación en medio (como la realizada al cambiar la cookie) invalida el certificado. Pero si lo aceptamos, vemos como de forma mágica podemos acceder a gMail sin pasar por el nombre de usuario o contraseñas, ya que estos están embutidos de algún modo en la propia Cookie. Es cierto que quizás no seamos capaces de comprender el Hash usado por Google para proteger dicha información, pero no importa, simplemente copiando y pegando tenemos un resultado impecable.

Pensar no solo en las cookies de sesión. Pensar en que pasaría con aquellas cookies que usamos de forma persistentes. Es decir, podemos activar muchas veces las casillas de “Recordarme en cada Visita”, lo cual lo que realiza es que la Cookie usada no se invalida por cada sesión, sino que tiene a lo mejor una validez de una semana.

Sobre la modificación de Cookies que podamos inferir su contenido para especificar otro, será una cuestión que se abordará mejor cuando hablemos de Hashes.

 

Podríamos añadir muchos otros Spoofing dentro de las Cabeceras. Por ejemplo en todos los ejemplos mostrados se presupone que la utilidad es a la hora de los request, pero también puede ser útil modificar los response para producir en aplicaciones Flash por ejemplo un comportamiento completamente diferente. Por ejemplo imaginar que en un response se configuran los datos de una aplicación Flash para tener más vidas (en un juego). Modificando el response podríamos obtener más vidas.

Otra utilidad que se tiene es para modificar los datos enviados por el método POST al servidor. Con POST normalmente se especifican una serie de valores que son especificados en un formulario previamente. Pero muchas veces los valores que podemos introducir en el formulario son muy limitados en correspondencia a los que podríamos introducir directamente realizando Spoof a la cabecera. O por ejemplo pensar en formularios que dependiendo si los rellena un usuario u otro tiene más o menos campos, puesto que es posible que el sistema de procesarlos el servidor sea la misma forma. En dicho caso podríamos añadir “campos” extras con información arbitraria para obtener permisos administrativos por ejemplo u otros menesteres.

 

Seguridad: Spoofing. Capítulo Tercero -> Web Spoofing

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

ATENCIÓN!! El Phishing creado para este capítulo tan tiene carácter didáctico, no se permite su uso fuera de este ámbito. El Phishing es completamente ilegal.

 

Web Spoofing

Aunque el Phishing no es más que un tipo de Web Spoofing, podemos afirmar sin duda alguna que es la práctica más común. Por Web Spoofing entendemos la modificación o suplantación de una página web que evidentemente no es nuestra. Phishing es la suplantación de una web con fines íntegramente delictivos, para poder obtener datos de usuarios que infelizmente caen en las redes de estas páginas y no son capaces de diferenciar lo uno de lo otro. Es decir, el Phishing es tan solo una singularidad dentro de Web Spoofing, aunque es sin duda su mayor uso.

Aquí tendríamos que hacer una diferencia muy importante. Desde mi punto de vista, el Spoof implica la modificación de algo que es nuestro, como son los casos que hemos visto: IP Spoofing (Modificamos nuestra IP), MAC Spoofing (Modificamos nuestra MAC), Phishing (Modificamos nuestra web)… pero en ningún caso estamos modificando aquello que no lo és. Es decir, no estamos modificando la IP de un usuario, no estamos modificando la MAC de un usuario, no estamos modificando la Web de un usuario. Esto es algo muy importante de entender, con Spoofing tan solo engañamos. Existen técnicas para modificar aquello que no está bajo nuestra “propiedad”, como pueda serlo XSS, envenamientos… técnicas que serán relatadas en otros artículos. Hablemos por tanto tan solo de Spoofing.

Los objetivos de Web Spoofing son claros:

  • Phishing, obtención de credenciales de otros usuarios
  • Reivindicaciones y Mofa
  • Estafa

Como hemos dicho el objetivo principal y sobre lo que vamos a centrarnos principalmente es el Phishing. Para que un ataque de Phishing se lleve a cabo son necesarias 4 fases. Primero un atacante debe de copiar lo más fidedignamente posible la página web que desea suplantar, al menos tan solo en apariencia, no es necesario un plagio completo de todo el site. Segundo, debe de modificar dicha web para que el usuario al introducir sus datos, estos queden almacenados de algún modo para poder recuperarlos el atacante. La tercera fase es realizar un proceso de URL Spoofing y por último utilizar alguna técnica que le permita engañar a los usuarios para acabar en su web falsa.

Redactar sobre Web Spoofing o Phishing es un problema. Mi intención es la de explicar, enseñar y así poder evitar ataques similares. El problema es que igualmente que esto puede servir con fines didácticos, cualquier persona podría adaptar estas letras sin problema alguno para pertrechar un ataque real, al igual que con los Spoofing expresados anteriormente. A diferencia del resto, hoy en día está de moda el Phishing, y la ingenuidad de las personas es aun demasiado alta. Si combinamos esto con las secciones siguientes (En particular con eMail Spoofing) sería dejar demasiado facil a un usuario mal intencionado poder realizar un ataque efectivo. Por ello al menos, voy a omitir todo código php y realizar algunos pequeños cambios para dejar claro que esto tan solo tiene fines didácticos. Aun así se incluirá al final del todo de esta sección, el enlace a una web creada con fines didácticos de lo que podría ser un Phishing en toda regla, y se incluirá del mismo modo un enlace al archivo donde se podrán obtener las identificaciones introducidas.

Para esta ocasión quería basarme en lo que sería un Phishing sobre

, una red social en España. Me puse en contacto con el gabinete legal de ellos y no les pareció una buena idea. Como les comuniqué, es normal, normalmente se es reacio a que puedan leer vulnerabilidades de sus propios servicios. Así que aunque tenga que modificar el artículo ya redactado, será sobre FaceBoock, la red social mayor que existe ahora mismo.

 

Fase 1: Creación de un site igual al del objetivo

Como ya he explicado, en el Phishing no importa recrear la web (que puede ser compleja) completamente, el objetivo es tan solo engañar al usuario que accede a ella. El hábito de un usuario normal es visitar la web e incresar su usuario y su contraseña para acceder. Si nos equivocamos, lo normal será volver a introducir los datos. Es decir, normalmente no nos preocupamos de ir a otros enlaces como “ayudas”, “Ha olvidado la contraseña” ni similares. Dado qeu ese comportamiento se repite para el 99% de los usuarios, tan solo tenemos que hacer creer al usuario que la web que está visitando es realmente ella. Dado que no tenemos por detrás una base de datos original, es evidente que se introduzcan los datos que se introduzcan, jamás logrará el usuario acceder al site, lo cual hace que sea común redirigir a dicho usuario despues de enviar los datos al site original para que no sospeche.

¿Pero como se puede copiar un site?

Dependiendo del grado de exactitud que necesitemos, puede ser más rápido o más lento el proceso:

  • Clonación de un site completamente independiente (físicamente estéticamente claro, no funcionalmente)
  • Creación de un site completamente dependiente al original, exceptuando la página de acceso.

En primer lugar, la clonación de todo un site de forma manual, o incluso a través del propio navegador, no es factible. Con clonar un site me refiero a crear un site con el mismo contenido que el original, enlaces, imágenes… pero accediendo a todo ese contenido de forma local. Es decir, podemos plasmar una imagen en nuestro Phishing, pero esta puede venir desde nuestro propio host donde tenemos alojados el Phishing o cargarla directamente desde el Host original. Crear una clonación tiene sus ventajas, por ejemplo es independiente a cualquier cambio que pueda realizar el site original, dado que scripts, html, imágenes y otros de tu propio site estarán almacenados en tu host, no en el de ellos. Por otro lado, es posible navegar por las diferentes secciones del site sin redirigirse al site original, que de otro modo produciría que un usuario que accediese a otro enlace perder el Phishing.

Pero todo no es positivo. La creación completa (o al menos lo más fiel posible) de un site (una página web) incluye tener en nuestro host muchísima más información, lo que produce un aumento considerable de espacio en disco, de ancho de banda usado y que además, es posible que el site original tenga conexiones más veloces que las nuetras, lo que haría que la navegación por nuestro site sería mucho más lenta para el usuario víctima. Por supuesto, la clonación, no es tan sencilla de llevar a cabo, y la mejor forma de hacerlo suele ser a través de un Web Spider, o quizás sea suficiente con wget.

Un proceso manual incluiría ir buscando uno a uno cada elemento e ir almacenándolos, después editarlos para que cada ruta especificase una ruta relativa a nuestra clonación y así poder montar la web. Pero esto evidentemente no es muy práctico. Yo voy a usar Teleport en Windows para este caso y para el segundo Firefox en Windows. Tampoco voy a detallar paso a paso que hacer, puesto que si se ha llegado aquí, presupongo que uno sabe más o menos moverse por cualquier programa o al menos comprende lo que está haciendo:

El tamaño de todo el site descargado para Tuenti, no llega a los 3MB y son más de 400 archivos. En el caso de Facebook, son más de 5000 archivos y unos 200MB. Esto os da una idea de lo bueno y malo de este proceso. 3MB pueden ser asumibles, 200MB para un Phishing es algo impensable. En contra partida, podemos navegar por gran parte de la web sin abandonar nuestro site clonado. En la siguiente imagen se puede observar esto:

En el ejemplo se puede ver que no solo se está emulando el site principal, sino que se puede navegar por el site y que al menos aparentemente todo muestra ser exactamente igual al original. Como puede verse en la barra de direcciones se conserva incluso la misma estructura de carpetas y archivos, aunque en el ejemplo se está haciendo una exploración en local, es decir, no se ha subido nada a ningun servidor externo.

Hay que tener en cuenta que la clonación jamás será exacta. Podemos extraer imágenes, contenido audiovisual, scripts… pero todo aquello que queda detrás y procesado tan solo por el servidor (como por ejemplo contenido dinámico, php, bases de datos…) no puede ser emulado de ningún modo. Es decir, podemos calcar pixel a pixel si deseamos el aspecto visual, pero nada más.

En el caso de la clonación de FaceBook, es un site demasiado complejo (sin entrar en bases de datos o PHP), 200MB sería demasiado para un Phishing, y más para un ejercicio. Quizás sea más. Quizás nosotros tan solo necesitamos lo fundamental, es decir, la pantalla de inicio de sesión y nada más. El resto del contenido podría ser simplemente enlazado con la web original, y mantener tan solo en nuestros servidores el html principal. De este modo ganamos en velocidad, comodidad, ahorramos en ancho de banda, en espacio… En contrapartida, estamos a merced de lo que haga el site original o peor aun, que la víctima pueda acceder a algún contenido desvinculado de nuestro site falso, lo que produciría que este se quedase fuera del Phishing.

Dependiendo del site, se podría realizar desde Firefox y usar la opción “Guardar Como…”. Como tan solo sería necesario la “cara”, nos basta con guardar únicamente la página HTML, de forma que los enlaces se conserven tal cual están. Haciendo este procedimiento pasamos a tener tan solo 1 archivo html de 30KB, el resto del contenido se cargaría desde la web original de FaceBook, lo cual es una ventaja. El problema es que si modificasen algo en el HTML, el site falso podría dejar de funcionar correctamente:

Como se puede apreciar tanto en la URL como en el destino del enlace seleccionado (aunque no aparezca, se está señalando la imagen grande de arriba “facebook”, y como se ve, no está apuntando a ninguna ruta local, sino al enlace real. Tan solo con dicho html tenemos lo mínimo necesario para poder realizar el Phishing.

Por otro lado, usar la mínima expresión a la hora de crear el Phishing, tiene la ventaja de que las URL señaladas a cada enlace corresponden a las originales, luego todas ellas no incurren en el problema de tener que usar URL Spoofing (Que se verá en la fase 3º). Una vez terminado este sencilo proceso, deberíamos de tener una copia (ya sea completa o parcial) del site objetivo, en este caso ejemplo, de Facebook. Tan solo bastaría subir nuestro site a cualquier hosting o copiarlo a nuestra carpeta principal de nestro servidor web. Si cualquiera accediese a ella en este punto, tendríamos una pantalla de acceso exactamente igual a la original, aunque si introduciésemos culaquier dato o fuesemos a cualquier enlace, nos redirigiría al site original.

 

Fase 2: Modificación

La segunda fase podría considerarse realmente el Web Soofing o Phishing. En realidad podría crearse la web desde cero si por cualquier aspecto no fuese posible “clonar” la web objetivo. El problema que ello tendría que posiblemente en algún detalle esta sería diferente a la original. Cuanto más fidedigna sea la copia, mejor resultado tendrá para un atacante, puesto a fin de cuentas todo objetivo es que el usuario no se de cuenta del engaño.

Pero tal y como hemos llevado el ejemplo, no serviría de nada. El objetivo es que el usuario cuando introduzca los datos en nuestro site falso, estos de alguna manera puedan ser accedidos después por el atacante. Ahora mismo se me ocurren tres formas para hacerlo:

  • Tener una BD debajo del site donde almacenar los nombres de usuarios y contraseñas
  • Tener un motor SMTP debajo del site para enviar por correo al atacante los datos
  • Escribirlos directamente en un archivo en nuestro servidor

El más eficiente de todos para un atacante sería almacenarlo todo en una base de datos, en la cual podría además registrarse fecha/hora o cualquier otra información de utilidad. La desventaja es que el atacante tendría que tener disponible no solo algún tipo de hosting (ya sea local o no), sino que posiblemente soporte para PHP y bases de datos. No voy a explicar como sería este caso por varias razones. Principalmente porque he dicho que por cuestiones de seguridad no voy a transcribir nada en PHP, luego prácticamente cualquiera de los 3 casos lo veríamos igual. Segundo porque tendríamos que estar manejando bases de datos y sería extendernos más de lo necesario.

En segundo lugar tendríamos una solución mucho más cómoda para el atacante. Cada vez que un usuario cometiese el error de caer en la trampa, el atacante recibiría un correo electrónico con las credenciales de dicho usuario. Esto que puede parecer algo muy complejo no lo es en absoluto, tan solo es necesario usar por debajo php para enviar un correo o programar un pequeño motor SMTP con los datos de nusetro correo gmail (por ejemplo) para realizar la tarea. No pensar en una web como algo estático. Cuando un usuario ingresa los datos, dispararía una serie de acciones que acabarían con el envío de un correo al atacante.

En último lugar y el que usaremos aquí consistiría en registrar los datos introducidos por el cliente en un archivo de texto. Principalmente usaremos este método para que aquél que lo desee, al final de estas letras pueda verificar que efectivamente funciona, y que la única diferencia de un Phishing real a este es el fin por el que se ha creado. Aun así como he dicho no se incluirá le código PHP para ello, sería demasiado fácil para quien pueda tener malas intenciones.

Visto esto, tendríamos que pensar como podríamos realizar esto. En mi caso concreto, las modificaciones realizadas al código fuente de mi Facebook.html han sido mínimas:

  • Modificación de la barra de título para dejar claro que es un Phishing didáctico, sustituyendo “Bienvenido a Facebook en Español (España)!” por “ESTE SITE/PHISHING TAN SOLO TIENE FINES DIDACTICOS”
  • Modificación del valor por defecto de “correo electronico” y “Contraseña” por: “Introduce correo de prueba” y “Introduce contraseña de prueba”
  • Renombrar Facebook.html por index.html para evitar la necesidad de apuntar a un html
  • Modificación de la acción que se realizaría al entrar en facebook por mi propio código
  • Creación e incorporación de mi código php, que escribirá los datos introducidos en un archivo de texto y redirigirá al usuario de nuevo a esta entrada

Mi intención es clara, que nadie pueda usar este Phishing didáctico para otros fines.

Sobre cada uno de los pasos realizados, sería entrar en programación html y php, y para ello ya tenemos innumerables libros que nos explican como hacer lo que deseemos hacer. Es decir, no voy a ir ahora explicando como realizar dichas modificaciones, no es el objetivo de estas letras. La cuestión es que al acabar, deberíamos de tener el Phishing completado. A partir de este momento, tan solo se trataría de aplicar diferentes técnicas para poder engañar de forma más fiel al incauto. ¿Por qué? En este momento lo que tenemos creado es lo siguiente:

Automáticamente nos llama la atención la extraña dirección que he usado. Dado que todo el Phishing lo tengo alojado en un hosting, tengo la posibilidad de crearlo en un subdominio o meterlo dentro de la ruta que yo desee. De este modo primero oculo por ahora la ubicación del Phihing, y la segunda la importancia de la fase 3º que aun no hemos hablado de ella. Tan solo verificar por la imagen que el site es tal y como se ha descrito y a su lado un documento de texto con los 3 primeros datos pruena introducidos.


Fase 3º: URL Spoofing

Podríamos dedicar en este mismo artículo un apartado específico para URL Spoofing, dado que no deja de ser un Spoofing más. Pero creo que su ámbito debe de ser también el de Web Spoofing, a fin de cuenta URL Spoofing podría ser perfectamente otra singularidad más de este. Sea como sea he preferido incluirla aquí.

A fin de no entrar en matices técnicos sobre URI, URL o URN, podemos definir de forma simple que una URL (dentro de internet) no es más que la dirección de un recurso, y el URN el recurso en sí. URI por tanto sería el conjunto entre URL y URN. Esto no tiene mayor complicación:

URI: blog.theliel.es/favicon.ico, URL: blog.theliel.es, URN: favicon.ico

Tener en cuenta que aunque a veces se omita el URN no implica que no exista, tal es el caso de los html tipo index.html, en los que su nombre se omite por defecto, pero están presentes igualmente.

Con esto, el término de URL Spoofing queda claro. Sería la técnica de modificar de algún modo o hacer parecer nuestra URL como otra, con el fin normalmente de aproximar al máximo nuestra URL con la de un site original.

Imaginar por ejemplo que tengo alojado el Phishing en:

“http://blog.theliel.es/docencia/66666666666666666666666666666666666″.

Evidentemente cualquier usuario que accediese a mi Phishing lo primero que podría notar extraño es el por qué está intentando acceder a “facebook.com” y en vez de ello está accediendo a un dominio diferente y una extraña sucesión de seises consecutivos. Evidentemente esto choca enormemente y sería complicado que un usuario pudiese percatarse de la trampa. Con URL Spoofing se trataría de modificar lo máximo posible dicha URL para asemejarse lo más posible al original. Y para esto existen numersas técnicas que son usadas por los atacantes:

  • Uso de nombres de archivos y estructuras de carpetas similares al site original
  • Usar dominios o subdominios lo más aproximados posible al original, o al menos ser inteligentes en su elección, uso de los ccTLD
  • Aprovecharse de los IDN (Nombres de dominios internacionales)
  • Ejecución de Scripts en el site para ocultar la verdadera URL del Phishing
  • Usar técnicas de redirección
  • Envenenamientos DNS

Algunas de dichas técnicas son simples, otras tremendamente complejas o costosas. La mayoría de los Phishers (Si es que ese nombre existe) no suelen complicarse tanto la vida, y tan solo se quedan en los dos primeros puntos. Un ataque más sofisticado posiblemente implicaría el uso de los puntos listados más abajo.

Tal y como estamos exponiendo el problema, lo primero sería reconstruir la URL de forma similar a la de la original. Si miramos la URL de tuenti (la de facebook no tiene ninguna “carpeta” anadidad a ella, tenemos que es la siguiente:

“http://www.tuenti.com/?m=login”

luego tan solo tendría que renombrar o mover los archivos en mi servidor a otra carpeta, siendo esta nueva carpeta llamada “?m=login”

blog.theliel.es/?m=login

Así me he evitado una parte, pero aun queda la otra… que es más complicada de eliminar. Lo cual pasaríamos al punto segundo, como poder modificar el dominio, o como podría un atacante intentar engañarnos. El problema es que un dominio no puede modificarse, con lo que la primera opción a la que se recurre es al uso de subdominios con la esperanza de no notar demasiado el cambio. En nuestro ejemplo podríamos intentar hacer alguna variante tal que así:

“http://tuenti.theliel.es/?=login”, “http://acceso.tuenti.theliel.es/?=login”, “http://www.tuenti.theliel.es/?=login”…

creo que se comprende perfectamente la idea. Evidentemente esto no es demasiado profesional cuando se requierer realizar un Phishing perfecto, pero en cambio es el sistema usado la gran mayoría de las veces, y aunque suene ridículo, suele funcionar bastante bien para los atacantes. Existe multitud de trucos a este aspecto. Por ejemplo otra práctica habitual es sustituir el nombre del dominio por su equivalente en IP, dado que a fin de cuenta un nombre de dominio no es más que una IP asociada a ella. Es decir, se puede expresar la dirección real de “facebook” en este caso de cualquiera de estas dos formas:

http://www.facebook.com

http://69.63.189.11

Las dos formas son completamente válidas, solo que con la segunda forma, el nombre queda completamente oculto. Luego una buena forma de ocultar la URL sería usar su equivalente IP. Y por último, otra técnica para intentar “esconder” la URL o al menos hacerla menos visible sería el uso de la sintaxis para introducir autentificación en una web, FTP… la forma que tendría esta tipo de dirección sería algo así:

http://facebook@theliel.es/

http://acceso:facebook@theliel.es/

Cuando se expresa una URL de dicho modo, lo que se está enviando a la web theliel.es que se desea acceder con el nombre de usuario “facebook”. En el segundo caso sería exactamente lo mismo, solo que en este caso el nombre de usuario sería “acceso” y la contraseña “facebook”. La idea de esto no es iniciar sesión en dicho lugar Phishing con credenciales de ningun tipo, sino de nuevo ocultar en la medida de lo posible la URL para que el objetivo no se percate. Se podría construir una URL con los dos métodos anteriormente explicados:

http://facebook@188.121.46.128/

Otra forma común de intentar engañar es con el uso de caracteres que se traducen por otros en la web. Por ejemplo, el caracter “%20″ se traduce en una URL como un espacio. el %20 corresponde al número ascii 0x20, que corresponde al espacio. Es decir, se podría construir la URL de una web, codificada directamente en ASCII, de esa forma se ocultaría también cualquier cosa que no nos gustase

“http://facebook%2E74%68%65%6C%69%65%6C” se podría traducir como “facebook.theliel.es”, claro está que este sería un ejemplo extremo. Esto suele ser muy común más que nada para evitar ver los puntos de separación (Expresados en ASCII como %2E), los espacios (%20), las barras (%2F)….

Otra técnica ampliamente usada es la elección de dominios que puedan llegar a ser confundibles. El dominio no podemos modificarlo, pero que sucede si en vez de registrar theliel.es hubiese registrado el dominio “theliel.com”? Sería ya un paso. Pero y si el dominio registrado es por ejemplo “facebook.co.uk” “facebook.es” (En caso de que facebook.es no estuviese ya registrado), “facebook.org”, “facebook.com.es”… es evidente que el dominio ya se parecería muchísimo más al original, y por consiguiente llamaría menos la atención.Y es que gracias a los dominios ccTLD, aquellos que tienen dos letras tan solo, que son asignados solo uno a cada pais, tienen esta ventaja. ¿Ventaja? Claro. Normalmente registras un dominio. Pero la gran mayoría de TLDs son los ccTLD, si existe uno por cada país, el abanico es mucho más amplio que tan solo los gTLD. Esto quiere decir que aun cuando existan dominios como “facebook.org” “facebook.com” o muchos otros registrados todos a la misma entidad, seguro que tendremos multitud de ellos disponibles en ccTLD. En caso de facebook sin ir mas lejos, creo que tiene registrado a su nombre todos los gTLDs (si no se me escapa alguno), pero ni mucho menos tiene registrados todos los ccTLD. Sería facil mirar alguno que fuese similar.

Para quien no lo sepa, TLD se traduce como Top Level Domain, es decir, la parte más derecha de una URL. Estos se clasifican principalmente en 3. TLDs reservados, TLDs genéricos (gTLD) y TLD de paises (ccTLD). Dentro de los reservados tendríamos .test, .arpa… Dentro de los ccTLD .es, .fr, .gb… Y dentro de los gTLD los clásicos .com, .org, .net…

Una técnica mucho más refinada es aprovecharse del uso de los IDN. Dado que cada país posee un ccTLD, es igualmente razonable que la ICANN no solo permita la escritura o el registro de URL en el alfabeto nuestro, Latino, que posiblemente sea el alfabeto más usado del mundo. Con alfabeto me refiero ni mas ni menos a A B C D… pero incluso en algo tan sencillo como esto, rápidamente recordamos que nosotros tenemos la “eñe”. Sería justo por tanto que la ICANN nos permitiese poder usar la “eñe” en un dominio: “www.coño.es” en vez de “www.cono.es”. Pero esto tan solo es la punta del iceberg. Si se permiten otros alfabetos, podemos pensar que existen URLs en chino, árabe, cirílico…

¿Que importancia tiene esto? Una enorme. Si se permiten caracteres pertenecientes a otros alfabetos, podríamos construir una url incluso IGUAL a una legítima. ¿Como es esto posible? Porque es posible que en un alfabeto una letra tenga la misma representación gráfica que en otro alfabeto, pero en cambio el código UNICODE de dicho caracter sea completamente diferente, con lo que a efectos prácticos ambas direcciones pueden convivir. El mejor ejemplo de esta técnica sería registrar el siguiente dominio:

“fаcebook.com”

A efectos gráficos el nombre es exactamente el mismo!! pero no lo es. La “a” no pertenece a la “a” latina, sino al caracter “a” cirílico. Nuestra “a” corresponde al valor UNICODE U+0061, mientras que la “a” cirílica “а” corresponde al código UNICODE U+0430. Esta técnica es muy sofisticada y como puede apreciarse casi imposible de detectar.

Pero aun podemos complicar más el URL Spoofing y dar un paso más allá. A fin de cuentas el uso de IDN no siempre es posible si no existe algún carácter con correspondencia en un alfabeto u otro o no podemos registrar dicho dominio por la razón que sea. Una solución más compleja pero más versátil sería el uso de Scripts creados en JavaScript, ActiveX, extensiones para firefox… para, de algún modo, evitar que el objetivo de un atacante pueda darse cuenta de la dirección real. Existen 3 prácticas mayoritarias en este aspecto, en los que su efetividad depende más que de cualquier otra cosa del navegador usado y como esté configurado.

La primera sería la clásica apertura de Popups, ventanas emergentes Mediante una simple llamada en JS (No voy a escribir en estos casos código alguno), es posible cerrar la página actual (para que no se pueda leer la URL real) y acto seguido reabrirla sin barra de dirección. Esto la mayoría lo ha visto muchas veces, sobre todos en los tiempos de la hegemonía de Internet Explorer y la publicidad emergente. Gracias a dios, con los navegadores actuales este tipo de prácticas quedan tan solo efectivas para un reducido número de personas.

La segunda opción implicaría haciendo uso de JS algún otro lenguaje, la aplicación de una pequeña “capa” (por así decirlo) a la barra de direcciones. Es decir, literalmente se pegaría una imagen con la URL del sitio original encima de la barra de direcciones de nuestro navegador. De este modo se oculta URL real y aparenta ser la URL legítima. Alguna vez he podido apreciar este tipo de Phishing, pero sinceramente no sabría ahora mismo como crear el código necesario para realizarlo. Pero como hemos dicho, depende enormemente de la configuración de nuestro navegador y de cual usemos.

La tercera opción, es similar a la segunda. En este caso se insertaría un objeto (se llama así) texto en nuestra barra de direcciones, que al tener el fondo blanco y en el texto la URL legítima, a todos los efectos nusetra URL parecería completamente real. Este escenario es peor que el segundo, dado que percatarse de ello sería mucho más complicado. Al final de la sección hablaremos de las medidas a tomar en cada caso.

Llegados a este punto tan solo quedarían dos técnicas para poder realizar un URL Spoofing. Realmente las dos técnicas implicarían algo más que Spoofing. Ya dije que para mi el Spoofing es engaño, modificar algo que tenemos, jugar con nuestras cartas… en cambio las dos técnicas restantes: Redirecciones y Envenenamiento, implicaría cambios más radicales por así decirlo. Sería necesario modificar o inyectar código propio en otro site en el caso de las redirecciones, o modificar el caché DNS de los usuarios. Estas dos cuestiones se tratarán en los envenenamientos y en XSS. En cambio si existe una redirección típica que si podemos comentar aquí, y que por cierto es la más usada. En realidad se aprovecha normalmente de forma conjunta con eMail Spoofing.

En HTML existen formas de poder ir hacia otro lugar, lo conocemos simplemente como enlace. Pero una cosa es el destino al que deseamos llegar y otra el texto del enlace. Así por ejemplo podría escribir:

http://www.facebook.com

http://www.facebook.com

Y aun cuando en las dos direcciones se puede leer exactamente lo mismo, la primera lleva al site original de facebook y la segunda a mi blog. Esto que parece tan simple es usado constantemente, todos los días en millones de correos fraudulentos. Aunque parezca mentira, la gran mayoría de todos los problemas de seguridad existentes son debidos tan solo a la malinformación del usuario, de una mala praxis. Imaginar por ejemplo que en vez del ejemplo mostrado, el segundo enlace en vez de ir a mi blog, fuese a mi Phishing.

 

Fase 4º: El gancho

Aun cuando el atacante tiene todo perfectamente planeado y preparado queda lo más obvio. Que un usuario caiga en la trampa y visite dicho lugar. La forma más simple de producir esto es por medio de eMail Spoofing, que será tratado más adelante. Otros medios usuales es la mensajería instantanea, virus, foros, blogs… Por ejemplo, podría enlazar mi blog a un supuesto enlace a Facebook para promocionarlo, pero la verdad es que iría directo a la trampa. Como digo veremos esto en gran detalle en eMail Spoofing.

 

Llegados a este punto, el atacante comenzaría a recibir nombres y usuarios sin parar de las víctimas, y lo peor de todo es que una vez todo en marcha, el proceso es todo automático. Tan solo la buena educación y el cuidado hacen que este tipo de ataques tenga el menor impacto posible.

Para quien quiera verificar como podría ser un Phshing real, quitando algunos detalles como ya he explicado, puede verlo aquí, así como el documento de texto donde quedarán almacenados los credenciales introducidos:

 

http://theliel.webege.com/DIDACTICO_FACE/

http://theliel.webege.com/DIDACTICO_FACE/fac.txa (es un archivo txt renombrado a txa por razones que ahora no importan)

 

Bueno, pero ahora… ¿como evitar el Phishing?

Evitar el Phishing es algo fundamental estos días de hoy, en los que posiblemente el Phishing se lleve la mayor parte de los actos no civilizados (por así decirlo). Si comprendemos cada paso que debe de dar un atacante para poder realizar un Phishing de forma satisfactoria, podemos ver claramente cada uno de los pasos que podemos realizar nosotros para evitarlo. Es cierto que nosotros como usuarios o como Webmasters, no podemos hacer nada evitar que alguien pueda simplemente copiar un sitio. Es cierto que no podrán montar debajo la base de datos o el código php que sea necesario, pero al menos la apariencia física es imposible de evitar. Por otro lado tampoco podemos evitar que un atacante modifique a su gusto su propio site para intentar que caigamos. Pero a partir de aquí, por listo que pueda ser el atacante, podemos impedir sin mucha complicación cualquier tipo de Phishing, y es aquí donde reside nuestra “defensa”. Al explicar las diferentes técnicas de IP Spoofing o de ganchos, un usuario debería de ser más que capaz por tanto de saber diferenciar un site real de uno que no lo es. Voy a dar algunas indicaciones básicas:

  • Uso de conexiones seguras siempre que sea posible
  • Usar un Navegador que sea fiable
  • Conocer las URL legítimas de los sitios visitados de forma habitual
  • No fiarse de las redirecciones, comprobarlas siempre
  • No permitir por defecto Scripts de ninguna clase
  • No permitir por defecto Cookies de ninguna clase

 

El uso de conexiones seguras a día de hoy es fundamental, sobre todo cuando vamos a ingresar en algúna web que requiera de credenciales. Por regla general soy extremadamente crítico con aquellas web que no usan sistemas de certificados SSL/TLS cuando se trata de datos confidenciales. En caso de Webs como redes sociales parece que aun no está muy implantado el uso de conexiones seguras, pero jamás deberíais acceder a alguna web de banca electrónica si esta no está amparada por un certificado digital que la acredite. De esto hablaremos en otro artículo.

Un navegador fiable es fundamental. Muchas web de Phishing pueden aprovechar agujeros de seguridad o vulnerabilidades de estos por ejemplo para poder modificar la URL que aparezca en nuestro navegador. Cualquier truco es válido a la hora de que el site falso pase por el original. Actualmente el navegador más veloz a la hora de renderizar una web es Chrome (De Google) con mucha diferencia. No obstante Firefox es un navegador mucho más sofisticado y con posibilidades, maduro y con una escalada imparable en su gran uso. También hay que tener en cuenta que actualmente Firefox no soporta multiprocesador, lo cual quiere decir es que en cuanto esté terminado el soporte completo para este, sy velocidad se multiplicará aproximadamente x3, a la par de su seguridad. Si tengo que escoger uno sin duda alguna es Firefox, después Chrome, después Opera, IE y para terminar Safari. Safari es mejor navegador que IE en realidad, pero es mucho más vulnerable también.

No sucede nada por conocer las URL visitadas de forma habitual. Si sabemos que la URL de facebook es “http://www.facebook.com” es esa, no es otra. Aquí hay que explicar algo para aquellos que no lo sepan. Una URL se lee siempre de derecha a izquierda. No estoy hablando de la URI que hablamos más arriba, tan solo de la URL. La otra parte de la URI, la URN si se lee de izquierda a derecha. Como digo una URL se debe de leer de derecha a izquierda, cada sección separada por un punto es un dominio/subdominio. Por ello, se llama TLD a los dominios .es .com .org etc, dado que es lo primero que encontramos si leemos de derecha a izquierda: “Top Level Domain”. De este modo podemos decir que todos los dominios de primer nivel son aquellos que están justo después del primer “.”. “theliel.es” sería un dominio de primer nivel. Es evidente que prácticamente cualquier site estará alojado en un dominio de primer nivel. Esto es un indicativo fundamental. Si hacemos caso a esto, prácticamente ninguna variante de las que hemos hablado con anterioridad sería válida. A esto debemos sumar que ningun site original usaría su IP directamente para acceder a su site. La única razón por la que esta podría ser usada sería ante problemas de DNS, pero esto a día de hoy es prácticamente impensable. Otro motivo por el cual jamás fiarse de una URL dada en IP.

“http://facebook.theliel.es”, “http://facebook@theliel.es”, http://facebook@188.121.46.128/

Los tres ejemplos anteriores, si leemos de derecha a izquierda nos encontramos con el truco. En el primer caso se está accediendo primero a un dominio de primer nive .es, y después a un subdominio de este llamado facebook. Evidentemente facebook nunca sería un subdominio.

En el segundo ejemplo, el primer dominio que nos encontramos es de nuevo “theliel.es”, da igual lo que exista a la derecha, el dominio es ese. Además, dependiendo del navegador que usemos, puede incluso darse cuenta de esta pequeña trampa, pues nos advertirá de que el site al qu ese quiere acceder no requiere de autentificación.

El tercer caso es el mismo que el segundo… tan solo con la modificación del dominio “theliel.es” por su IP. Da igual a quien corresponda la IP, lo mejor no es fiarse, o si se está seguro de la legitimidad de dicha IP, una consulta ping sobre el dominio en cuestión nos devolverá la IP de dicho dominio. Si no coincide listo. Otra opción sería verificar la IP en un servidor Whois y comprobar a quien pertenece dicha IP

Las redirecciones es un problema con mayúsculas. Parece increíble que a estas alturas los usuarios no se fijen en la dirección de destino real, no lo que podemos leer como texto. Antes de seguir un enlace del cual no estamos seguro su procedencia, comprobar el destino del enlace. Cualquier navegador hace esto, tan solo se necesita pasar el ratón sobre el enlace para que nos aparezca (normalmente debajo del navegador) el salto a efectuar. Esta práctica es diaria cuando se intentan realizar ataques de eMail Spoofing. Cuando tratemos esto más adelante se comprenderá mejor.

El uso de Scripts o Cookies es algo normal en internet. Pero dichas cookies y Scripts pueden ser usados de forma maléfica contra nosotros. Es cierto que a día de hoy prácticamente cualquier web requiere aunque sea de pequeños scripts para poder desde visualizar correctamente el contenido a ejecutar cualquier acción. Pero aun así, desde mi punto de vista es mejor prevenir que curar. Soy más partidario de las listas blancas que de las listas negras. Es decir, mis políticas siempre son las mismas: Partir de un sistema completamente cerrado e ir abriendo lo que se va necesitando. En este aspecto, implicaría bloquear por defecto todas las cookies y todos los scripts, e ir habilitando tan solo aquellos que van siendo necesario. Aquellos que conozco y comprendo que son seguro los puedo habilitar de forma indefinida. Esto que parece un chiste, es la causa de que prácticamente cualquier PC del mundo, tenga alguna cookie de seguimiento o espía. Además, gracias a código en JS malicioso y aprovechando vulnerabilidades de webs, de navegadores… aparecen problemas mayores como XSS, URL Spoofing, exploits… La regla siempre debería de ser de bloque total, y solo habilitar cuando sea estrictamente necesario. Si estamos seguros de la “legitimidad” del sitio y nos fiamos, permitimos para siempre dicho script o dicha cookie. Para tal, personalmente uso NoScript y Cookie Monster (Los dos para Firefox)

Evitar el Phishing es algo simple si se tiene algo de cuidado. No hace falta mucho, tan solo conocer que es, como funciona y el objetivo que se busca. Si se sabe todo ello, evitarlo es facil.

 

Para terminar del todo con Web Spoofing, citar un par de detalles más. El Phishing no es el único Web Spoofing que se conoce. Aunque normalmente el objetivo es el explicado, a veces el objetivo no es la obtención de datos de los usuarios, sino que tiene fines reivindicativos, de mofa o incluso de estafa. Por ejemplo si estoy completamente en contra del LHC, una forma de mostrarlo o criticarlo sería crear un site igual que el oficial pero con contenidos de protesta. Si se quiere mofar sobre por ejemplo una ley o algo similar podría realizarse un Web Spoofing para calcar un blog o un site de dicho político en el que se hablase jocosamente sobre ello.

Una última utilización de Web Spoofing sería cuando tan solo se pretende crear un negocio, alguna clase de venta… de algo que no existe. Pongamos por ejemplo que creo un site prácticamente igual y copiado a Amazon. En él publico libros o productos que quiera. El proceso es todo muy similar al original, solo que dicha web tan solo es una mera estafa, o a lo mejor es real, y se aprovecha del nombre, diseño, métodos… de otra que ya existe.

 

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Alma Oscura por Theliel licenciado bajo Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar con el autor.