HTTPS. ¿Seguro que es seguro?

Aunque algunos de vosotros se sientan desazonados ante el título de este post, quiero  ante todo tranquilizaros. No es tan malo como parece. O sí. Todo es según el color del cristal con que se mire. Llevamos años escuchando la frase: “El protocolo HTTPS es seguro”. Pero también llevamos años escuchando que lo peor de la crisis ha pasado…

Voy a intentar destripar este “infalible” protocolo. Como siempre, primero os voy a explicar en qué consiste.

HTTPS son las siglas de HiperText Transfer Protocol Secure. Para los de “nivel medio” de inglés en sus CV, Protocolo Seguro de Transferencia de Hipertexto. Ea, ¿cómo os habéis quedado...? ¿Igual...? Pues intentaremos volver a traducirlo. 

Todos sabéis ya que las páginas web utilizan un lenguaje llamado HTML, y que se puede crear o modificar con un simple editor de texto. Navegar por Internet, de manera predeterminada, es hacerlo de manera abierta, o lo que es lo mismo, la información que va y viene desde la página web que estamos visitando y nuestro PC, se transmite en texto plano y es susceptible de ser escuchada y entendida por métodos no excesivamente complicados (incluso fáciles, diría yo). Así que para poder intercambiar datos sensibles, utilizamos el protocolo HTTPS, que no es otra cosa que aplicar cifrado a la información. Como recordaréis los que hayáis leído mis anteriores post, existen diversos métodos de cifrado, unos más seguros que otros. 

En concreto, HTTPS procede a cifrarse utilizando SSL/TLS, que son unas bonitas siglas que corresponden a Secure Sockets Layer/Transport Layer Security, diferentes sistemas de cifrado que podemos simplificar diciendo que son “razonablemente” seguros, por no decir completamente, algo que ya sabéis que es imposible. 

[Frannoe dixit]

Entonces, ¿a qué viene el título del post? ¿Para crear un flame…? 

[Jose respondere]

Je, je, je… No hombre, después de la última experiencia, no quiero volver a pasar por ello…

Vamos a ver el porqué de mis reparos a la navegación segura bajo HTTPS. La seguridad de este protocolo está basada en un proceso de cifrado robusto, difícilmente o imposible de descifrar, y una relación de confianza con el sitio web donde nos conectamos de forma segura, ya que sólo si confiamos en el sitio que estamos visitando, se generará el tráfico cifrado entre el servidor y nosotros.

Para el cifrado de la información, HTTPS utilizaba de manera predeterminada el conocidísimo RC4, desarrollado por Ron Rivest (coautor de RSA). De este mozo ya os hablé en el post de cifrado de Thunderbird. También os he hablado de RC4 en el post de Wi-Fi, ya que es el algoritmo de cifrado de WEP y WPA/WPA2. Es un algoritmo de cifrado robusto, simple y efectivo. También os comenté que, aunque su código no ha sido liberado nunca, una descripción de éste fue publicada de forma anónima en una lista de correo y después se expandió como la espuma por la web. Esto ha hecho que el certificado haya sido marcado como "DEPRECATED", aunque Ron Rivest ha insistido en que su uso sigue siendo perfectamente válido. Creo que en este caso Ron no va a ganar...

El protocolo funciona aplicando dos protocolos más sencillos, que generan unos arrays de números en los que los valores son colocados de manera aleatoria. El caso es que el año pasado se descubrió que esa aleatoriedad no era lo bastante aleatoria, valga la redundancia. Y eso no es bueno, nada bueno. RC4 continúa usándose, aunque cada vez menos, debido a su velocidad. Claro, a los administradores de páginas HTTPS les interesa un protocolo rápido, que no haga que la navegación sea lenta y que no sobrecargue al servidor. Así que a pesar de la vulnerabilidad, continuó usándose durante todo el año pasado. Hoy en día, en las páginas seguras que yo uso habitualmente, ya está sustituido, pero lo podreis comprobar cada uno en sus propios accesos, como os explicaré más adelante. ¡Ojo! No estoy declarando con esto que sea fácil romper este protocolo. Sólo que existe una probabilidad más alta que con otro. Probabilidad no es igual a posibilidad. La mecánica cuántica establece que existe una probabilidad de que corras contra un muro y lo atravieses, sin que ninguno de tus átomos colisione contra cualquiera de los átomos del muro, apareciendo al otro lado con las narices intactas…. ¿Queréis probar vosotros? A mí es que da la risa floja sólo de pensarlo…

Pasamos a estudiar el otro parámetro de la ecuación. La relación de confianza.  Ésta se establece mediante el uso de certificados de autenticación. Los más antiguos del Blog, recordarán que en la serie que publiqué para montar nuestro propio servidor, creamos nuestro certificado de autenticidad. Claro, servía para nuestros propósitos, ya que no íbamos a autenticarnos ante nadie, excepto ante nosotros mismos. Comentaba entonces, que la única diferencia entre nuestro certificado y el de Google, por poner un ejemplo, era que el nuestro no estaba validado por ninguna entidad validadora de certificación (CA o Certificate Authority). Así, si llegamos a una página web https, y su certificado no es válido, nuestro explorador nos avisará del error del mismo. 

¿Y qué es lo que hace que salten las alarmas en nuestro navegador? Pues que dicho certificado no esté reconocido por una de las entidades en las que confiamos. Y aquí viene el problema. ¿En cuales confiamos? Porque la lista, lamentablemente, se está volviendo infinita. 

Veréis, en el caso de Firefox, Mozilla mantiene una lista de entidades de confianza seguras. A éstas se las denomina Entidades de Certificación Raíz de Confianza.
Podemos verlas accediendo a las preferencias de Firefox->Avanzado->Certificados->Ver Certificados:

Bien, vamos a dar por válidas las Entidades Raíz que nos indica Mozilla. El problemas es que estas Entidades pueden emitir certificaciones para que otras Certificadoras emitan a su vez certificados válidos (parece un trabalenguas, ¿verdad?). Éstas se llaman Entidades Certificadoras Intermedias, y son tan válidas como las Entidades Raiz. Estas Certificadoras intermedias, pueden, a su vez, emitir certificados para otras Entidades Certificadoras, y suma y sigue. Mientras dependan, en el origen, de una Entidad Raíz, nuestro navegador confía en ellas.

Ahora imaginemos una situación que puede llegar a ser real. Imaginar que una persona de dudosa moral, monta una tienda en Internet para la venta de portátiles a mitad de precio. Un chollo, ¿no? Bien, como no nos fiamos un pelo, no vamos a comprar en una página en donde tengamos que poner los datos de nuestra tarjeta de crédito, si ésta no empieza por https, que llevamos años escuchando que es lo que hay que hacer para estar seguros. Pero, ¿qué necesita nuestro chorizo de turno para crear una página https que no haga saltar todas las alarmas en nuestro navegador? Eso que estáis pensando, un certificado validado.

Y, ¿cuánto cuesta obtener un certificado validado? Pues depende del tipo, porque lo puedes obtener desde poco más de 10 €. E incluso menos si nos buscamos una Entidad dos o tres pasos por debajo de una Entidad Raíz. Y si está en un país de esos que tienen “mucho control”, pues mejor que mejor. ¿Por qué no nos vamos a fiar de una Entidad Certificadora China, eh? Ya, para rizar el rizo, podemos incluso conseguir un certificado totalmente válido gratuitamente, por un periodo de prueba de 90 días. 

Así que por poco más de 10 €, alguien puede montar una página donde dejaremos tranquilamente el número de nuestra tarjeta bancaria, CVC incluído. ¿A que mola? Ah!, se me olvidaba… todo esto de forma totalmente segura, encriptada y tal, ¿eh?. No seais mal pensados…

¿Entendéis ahora porqué tengo reparos a la expresión esa de “navegar bajo protocolo https es totalmente seguro”? 

[Frannoe dixit]

¿Y se puede hacer algo?

[Jose respondere]

Algo se puede hacer, si. Aunque siempre tendremos que estar con mil ojos, por si las moscas.

Empezando por el cifrado, podemos desactivar en nuestro Firefox el uso de RC4. Aclaración: Yo lo tengo desactivado. No me interesa entrar en una página https que tenga dicho cifrado. Debería ser trabajo del administrador de dicha página utilizar otro sistema de cifrado. Pero es decisión de cada uno. Quiero decir, que yo ya he comprobado que las páginas potencialmente peligrosas para mí (bancos y compras on-line) no utilizan dicho protocolo. Pero si una página de una compañía del gas o de seguros lo tiene… pues a lo mejor no es tan grave, siempre y cuando no vengan los datos de nuestra cuenta corriente o tarjeta, ¿no?

¿Y cómo sabemos si utiliza un cifrado u otro? Vamos a verlo. Vamos a conectarnos primero a un banco famoso:

 

Vemos el candado en la barra de direcciones, lo que significa que estamos navegando bajo https. Pulsamos en él y nos da cierta infomación:

Pulsando en más información vemos… más información. Paradójico, ¿verdad?  

Y aquí abajo vemos que el protocolo de cifrado no es RC4. ¿Y en esta otra página?

Vaya, pues estos siguen utilizando RC4... Pues eso, que yo paso de esta gente… Para desactivar el RC4 en nuestro Firefox es tan sencillo como acceder a about:config, y buscar RC4. Después, dejaremos en False todas las opciones que nos salgan:

¿Qué ocurrirá ahora si queremos acceder a esa página? Pues en el caso que nos ocupa, ocurre esto: 

 

¿No es pa matarlos? Claro, es que RC4 es más ligero y rápido que AES, así que yo, por defecto, te cuelo el RC4… No, si tontos no son...

Alguien puede pensar que lo siguiente que deberíamos hacer, es verificar la lista de las Entidades Raíz en las que confiamos. Hay que tener cuidado con esto. Si nos cargamos por ejemplo a Verisign, dejaremos de confiar en la mitad de las páginas seguras de Internet. Pero tal vez una buena idea sería eliminar aquellas entidades pertenecientes a países, digamos, oscuros. Cualquier buscador te dará información de las entidades que desees eliminar. No seré yo quien me eche encima al departamento jurídico de una Entidad Certificadora secundaria por deciros que no la aceptéis. Pero a veces me pregunto, ¿qué se me ha perdido a mí en Turquía, por poner un ejemplo?

En definitiva lo que tenemos que hacer es fijarnos en nuestro navegador, que es muy listo y nos dice más cosas de lo que pensamos.

Vamos a acceder, por ejemplo, a VeriSign (https://www.verisign.es)

 

Esto viene a ser una página certificada “de pata negra”, con un certificado del tipo Extended Validation (EV). Para empezar, nos describe en la propia barra de navegación el certificado. Si pulsamos de nuevo en más información, y a continuación en Ver cerfificado, pestaña Detalles, nos adentramos en las entrañas del mismo:

  

Aquí vemos quién es la Autoridad que ha ratificado como correcto dicho certificado, en concreto se trata de una Autoridad Primaria de Certificación o Certificadora Raíz. Claro que certificarse a sí mismo no debería ser ético, pero el caso que nos ocupa es ciertamente peculiar, al tratarse de una Autoridad Primaria. Veamos a nuestros amigos de Google:

Vaya, de momento no aparece en verde, ni especifica a quién pertenece…. Porque es Google, porque si tratara de una página de compraventa, ya estaría con la mosca detrás de la oreja. Además, eso de que alguien se certifique a sí mismo… Salvo que seas una Autoridad Primaria, como que no convence, ¿no?...Más información, please:

Insisto, porque se trata de Google, porque este sería un ejemplo de lo mal que está el tema de los certificados en la web. Así que GeoTrust Global CA (Autoridad Certificadora Raíz) autoriza a Google Internet Authority G2, y ésta es la que certifica a *.google.com, o sea, a sí misma…. Pues qué queréis que os diga… En las Notarías son más serios… Ya la repanocha hubiera sido que la autorizara una entidad China o Coreana… 

[Frannoe dixit]

Pero, ¿hay problema porque Google se certifique a sí mismo?

[Jose respondere]

No, Fran, con Google no hay problema… de momento. Como objeción, puedo decirte que con el dinero que gana Google, bien podía tener un certificado extendido. Eso como mínimo. Pero lo mismo te diría de los bancos. Ahora bien, siendo muy paranoicos, podemos pensar que al ser Google una empresa norteamericana, se puede doblegar ante las presiones de la NSA, por poner un ejemplo. Así, Google podría generar un nuevo certificado para ellos, y entonces no necesitarían romper ningún encriptado, sea RC4 o RSA. Teniendo el certificado original, un ataque Man-in-the-Middle desencriptaría todo el tráfico HTTPS con Google. Jodido,  ¿eh? ¿Lo estarán haciendo ya?... Qui lo sá…

¿Con esto terminamos? No, todavía queda una pequeña cosita. Hay algo que es superior a mis fuerzas. No puedo, soy incapaz de entender porqué configuran por defecto la caché de esta manera. Vamos a ver, Firefox, alma de cántaro… ¿por qué la información de las páginas https se queda cacheada en el disco? Y, ¿qué es lo que estás cacheando exactamente? Venga, hombre, mi hijo de doce años cuando trae una nota y no quiere que me entere, la esconde para que no la encuentre, no la deja guardada en el cajón…

Así que about:config de nuevo, y buscar cache.disk. De las claves que salen, cambiamos a False la clave browser.cache.disk_cache_ssl

Y como recordatorio final, hagamos caso al Firefox, que tan mal hecho no está después de todo. La información que nos da en cuanto a las páginas seguras es esta:

 

El globo terráqueo de color gris indica que el sitio no proporciona ninguna información de su identidad y la conexión a dicho sitio no está cifrado o está cifrado parcialmente, con lo que no puede garantizarse la seguridad. ¿Qué hago yo? Vade retro Satanás...

La señal de advertencia naranja indica que el sitio no proporciona ninguna información de su identidad y la conexión a dicho sitio está cifrada sólo parcialmente, con lo que tampoco está garantizada la seguridad. ¿Qué hago yo? Vade retro, Satanás…

El candado gris nos indica que el propietario del sitio ha comprado un certificado que demuestra que son los propietarios, y el sitio en sí no es falso. El cifrado el correcto, y la página segura. Sin embargo, no nos confirma quién es el propietario del sitio. ¿Qué hago yo? Bueeeno, vaaale… Hay que ser rata para no gastarse el dinero en un certificado completo… Si la página es conocida, adelante. El problema es que la inmensa mayoría de sitios seguros utiliza este tipo de certificado.

Y por último el candado verde nos indica que el sitio ha sido verificado mediante un certificado extendido (EV), que es un tipo de certificado que exige un proceso de verificación de la identidad muy riguroso. Asimismo, nos indica que el sitio está cifrado correctamente. Ojalá fueran así todas las páginas seguras.

Espero que os sirva de orientación.

Wifi hasta el infinito y más allá...

Ahora mismo, tengo activos en mi casa dos smartphones, cuatro tablets, tres portátiles, tres sobremesa, y cuatro consolas de juegos que acceden a mi red inalámbrica. No todos a la vez, pero puedo aseguraros que he llegado a tener hasta siete dispositivos conectados al mismo tiempo, tirando de la red. Y claro, se lía el carajal padre. Porque el pobre no da abasto a servir de señal aceptable todos los rincones de la casa. Al principio era fácil, sólo yo utilizaba el portátil y con que tuviera señal en el salón y mi habitación, me bastaba. Ahora, me exigen que llegue la señal hasta al baño. Y por otro lado, yo mismo me impongo que llegue señal a mi trastero, situado justo bajo mi casa. Y si lo consigo por un lado, me chillan por el otro. Así que, harto de que me chillen, decidí arreglar la situación. La solución era sencilla, o bien montar un nuevo emisor más potente, o bien instalar un repetidor de señal.

En esas estaba, decidiendo por cuál de las opciones me decidía, cuando la que no quiere ser nombrada me dijo que no entraba otro trasto más en casa. Que me las apañara con lo que tenía... Y yo, en un ataque de testosterona, le dije: ...si cariño, lo que tú digas...

Así que, una vez más, me sumerjí entre las cajas de restos informáticos del trastero y encontré dos routers wifi antiguos Speedtouch. Los encendí y descubro que tienen implementada la función WDS. Esto son las siglas de Wireless Distribution System, y consiste en que puedes conectar entre sí varios puntos de acceso inalámbricos, sin necesidad de un cable. El problema que tiene es que en estos aparatos no funciona con encriptación WPA. Tiene que ser WEP. ¡Vaya por Dios! Y yo acabo de escribir un post en el que os cuento que no utilicéis WEP… ¿Con qué cara me pongo yo ahora delante de vosotros? Además, con WDS disminuimos la velocidad en cada salto de access point que montemos… Gran dilema… Bueno, si los conecto con un cable, no pierdo velocidad, pero tengo que montar dos redes distintas… Vaya, pues no sé... bueno, ya veré cómo lo monto, ahora no lo tengo que decidir. Lo que sí tengo que asegurar es la seguridad de la misma. Y aquí es donde entra Radius. Este tema lo voy a dividir en dos post. El primero tratará totalmente de teoría, y en el segundo implementaré todo el rollo que os voy a soltar en este. Quiero que entendáis bien todo lo que vamos a hacer, así que intentaré explicarlo de la manera más sencilla posible.

Empezando por el principio, todos sabemos lo que es una red wifi... o no. Realmente Wi-Fi es una marca registrada. Hace unos años, en concreto en 1999, una serie de empresas se unieron para crear un estandar de conexión inalámbrica. Unos meses más tarde, se certifica la norma IEEE 802.11 bajo una marca, Wi-Fi Alliance, que después se ha usado para nombrar cualquier tipo de dispositivo inalámbrico.

Comparando la norma 802.3 (Ethernet) y la 802.11 (Wi-Fi), encontramos que son exactamente iguales. De hecho, la norma Wi-Fi se creó para sustituir las capas Física y Enlace de datos de la norma Ethernet, por lo que el funcionamiento de ambas es idéntico, a excepción del módo de transmisión de las tramas o paquetes de datos. Por eso es perfectamente compatible el uso en la misma red de dispositivos inalámbricos y de cable.

[Frannoe dixit]
 ¿Capas? ¿Eso qué es?

[Jose respondere]
Pufff.... Eso sí que es una buena pregunta. A ver cómo lo explico para que lo entendáis.

En los años 60 y 70 se produjo un boom en las tecnologías de las comunicaciones. Se crearon muchísimas tecnologías de redes, pero cada una era de su padre y de su madre. Es decir, cada una tenía sus propias normas, protocolos, hardware, etc. Ya en los 80, el cacao era tan grande, que la ISO se sentó a trabajar para crear un modelo de red que guiara a los fabricantes para crear redes compatibles entre sí. Y, después de mucho trabajar, se sacaron de la manga el modelo OSI (Open System Interconnection). El modelo OSI establece una serie de capas, que definen cómo se va relacionando el paquete o trama de una capa a otra. Así, define siete capas, a saber, Física, Enlace, Red, Transporte, Sesión, Presentación y Aplicación. Y en este modelo se han basado todas las arquitecturas de red desde entonces.

Volviendo a las redes inalámbricas, las que todos conocéis son la 802.11b, 802.11g y 802.11n. Si, os aseguro que las conocéis... Cada vez que entráis en vuestro router o access point a la sección de red inalámbrica, véis un desplegable en el que casi todos tenéis seleccionado 802.11 b/g. Los que tengan un aparato más moderno, incluso puede ser que tengan seleccionado 802.11 b/g/n. Pero realmente hay más, aunque no vamos a entrar a conocerlas todas.

La 802.11b fue el primer estándar comercial de Wi-Fi Alliance. Es una revisión del estándar original 802.11a, desarrollado en 1.999, y tiene una velocidad máxima de 11 Mbit/s. Bajo este estándar, el cifrado utilizado es el archifamoso WEP, Wired Equivalent Privacy, o Privacidad Equivalente a Cableado (Ja!). Proporciona un cifrado con claves de 128 bits, y todos sabéis ya que descubrir un clave WEP es más fácil que quitarle un caramelo a un niño.

Avanzando un poco en el tiempo, en el 2003 se liberó un nuevo estándar, usado hasta la saciedad hasta el día de hoy, en el que la inmensa mayoría de los dispositivos inalámbricos están funcionando. Este es el denominado 802.11g. Establece una velocidad teórica máxima de 54 Mbit/s. En este mismo año 2003, la Wi-Fi Alliance libera el cifrado WPA (Wi-Fi Protected Access) y poco tiempo después, WPA2, al publicar la norma 802.11i. Podríamos decir que WPA es una versión de migración desde WEP, mientras que al publicarse la 802.11i, se establece como sistema definitivo WPA2.

Mas recientemente, en 2004, se reunieron de nuevo para desarroyar una nueva norma, 802.11n. Este estándar está implementado desde 2008, aunque no fué definitivamente publicado hasta el 2009 (los fabricantes, que ya saben por donde van los tiros...) Este último estándar establece una velocidad teórica de 300 Mbit/s.

Bien, pues llegamos a un punto en el que estamos ya en una red 802.11g o 802.11n, con cifrado WPA o WPA2. Pero, ¿es seguro este cifrado? Pues no del todo, ya que heredó muchos de los defectos del cifrado WEP. Vamos a verlo un poquito.

Estamos hartos de ver siglas como WPA-PSK con TKIP, WPA-PSK con AES, WPA2-PSK con TKIP... ¿Qué demonios significan estas siglas? Como os he dicho anteriormente, WPA fue creado por la Wi-Fi Alliance para implementar un sistema seguro de encriptación. Fue desarrollado para utilizarse con un servidor de autenticación (aka RADIUS). Claro, eso obligaría a que en cada red doméstica o similar, estuviese presente dicho servidor. Para evitarlo, WPA permite la utilización de una clave precompartida, que es el modo que utilizamos casi en el 100 x 100 de redes domésticas o de pequeño formato. Esto es lo que conocemos como WPA-PSK o WPA2-PSK (Pre-Shared Key).

Una PSK es una clave secreta compartida con anterioridad entre las dos partes de una comunicación, usando un canal seguro. A la hora de autenticarnos ante una red WPA/WPA2-PSK, todos sabemos que debemos introducir la clave de dicha red, y el S.O. se encarga de comunicarse con el punto de acceso y trasmitir dicha clave para establecer la autenticación. Esto en sí mismo es un problema, ya que cualquier atacante capturando tráfico, puede escuchar dicha clave, y mediante ataques de diccionario y/o fuerza bruta, puede descubrir la clave. Lógicamente, cuanto mayor sea la longitud de la clave, más difícil será romperla, entendiendo por difícil que más tiempo se tardará en ser descubierta.

Existen dos tipos de algoritmos de cifrado con PSK. Se denominan TKIP y AES. 

TKIP o Temporal Key Integrity Protocol, funciona de la siguiente manera: el proceso comienza con una clave temporal que tienen tanto el cliente como el punto de acceso. Esta clave temporal es combinada con la MAC Address del cliente, y le agrega un bloque de bits para generar la clave de cifrado. Cada 10000 paquetes (por defecto), se cambia la clave temporal y se vuelve a generar una clave de cifrado. Para cifrar los paquetes, se utiliza el protocolo de cifrado RC4, método de cifrado utilizado también por WEP. RC4 es un método de cifrado simétrico, que tuvo la "desgracia" de ser publicado su algoritmo en una lista de correo por algún "graciosillo". Así que ya no es considerado seguro.
AES (Advanced Encription Standard) es el otro método de cifrado utilizado en WPA/WPA2-PSK. Es el estándar de cifrado actual con clave simétrica. Puede utilizar claves de 128, 192 ó 256 bits de longitud, que se aplican a bloques de datos de 16 bits, ya que este cifrado funciona por bloques. Es un cifrado muy seguro, pero claro, aplicado sobre una PSK, se vuelve vulnerable. Insisto para que quede claro: el protocolo es seguro, pero si nos descubren la clave, estamos vendidos.

Así que ya sabemos que toda red que utilice PSK es vulnerable. Con WPA/WPA2, no tanto como con WEP, pero vulnerable a fin de cuentas.

Para evitar esto, vamos a utilizar el modo WPA/WPA2-ENTERPRISE (que en realidad es el modo "natural" de WPA/WPA2). Este modo, como bien habréis adivinado ya, consta de un servidor que recibe las peticiones de autenticación enviadas por el punto de acceso. A este servidor se le conoce como RADIUS. En principio son las siglas de Remote Authentication Dial-In User Service, y en concreto, se trata de un protocolo de autenticación de usuarios. Muchos de vosotros, sin saberlo, usáis un servidor Radius a la hora de conectaros a Internet. Sí, vuestro proveedor, dependiendo del tipo de autenticación que tengáis habilitada, usará un servidor Radius para verificar vuestros datos y ver si podéis navegar por la red.

El servidor Radius utiliza para su proceso de autenticación la norma 802.1X, y en concreto utiliza un protocolo llamado EAP (Extensible Authentication Protocol). En realidad, EAP no es un protocolo como tal, sino más bien un framework de autenticación. Como tal, provee diversos métodos para realizar dicha autenticación. Veamos los principales:

EAP-TLS. Establece un túnel cifrado para realizar la autenticación mediante TLS (Transpor Layer Security). Para crear dicho túnel, tanto el cliente como el servidor tendrán un certificado privado, así que es un método ciertamente muy seguro. Se envía un certificado del cliente al servidor para la autenticación.

PEAP. Aquí la autenticación se realiza mediante la introducción de un usuario y una contraseña. El problema es que tanto el usuario como la contraseña se transmiten en texto plano, con lo que se pueden captar dichas credenciales.

EAP-TTLS. Aquí se establece un túnel cifrado utilizando un certificado del servidor, y a través de él se transmiten el usuario y la contraseña. 

PEAP-TLS. Autenticación por certificados, pero el certificado del cliente se encripta antes de ser enviado al servidor para su autenticación.

¿Y qué método es mejor? Pues depende de las ganas y las necesidades de cada uno. Me explico. Conectarse mediante usuario y contraseña para algunos puede resultar un trastorno, pero en entornos empresariales es lo más común. Ahora bien, en mi caso, os he comentado que voy a dar acceso a doce dispositivos. ¿Puedo crear para ellos certificados y evitar tener que utilizar usuario y contraseña para conectarme? Pues si, pero tengo el inconveniente de que no podré dar acceso a ningún invitado en un momento puntual. Es algo que tenéis que valorar cada uno de vosotros.

[Frannoe dixit]

¿Y no se pueden implementar los dos sistemas a la vez?

[Jose respondere]

Pues ahí me has pillao con las bragas en los tobillos... Creo que no, pero lo veremos con seguridad en el próximo post...

Antes de despedirme, os voy a enseñar mi nuevo servidor casero:

¿Quién dijo que hace falta mucho sitio para montar un servidor? Este chiquitín mide 166 mm de ancho x 164 mm de profundo x 48 mm de alto... Y tiene 4 GB de RAM, Gráfica GeForce 9300 con salida HDMI, Intel Core 2 Duo y HD de 1 TB. ¿Suficiente...? Me sobra la mitad. 

Nos vemos en el próximo post.

"Esconde" tus cosas importantes o personales....

¿Quien no tiene algo en su ordenador que quiera mantener lejos de miradas indiscretas......?
Casi todo el mundo sabe que renombrando el archivo y poniéndole un simple . delante se nos quedaría oculto, salvo que alguien pulse ctrl+h  y ya lo podría ver tranquilamente, con lo cual no está excento de "curiosos".

Bueno, para ese tipo de "cositas" tenemos un programa que va de lujo en este caso, el programa en cuestión se llama CRYPTKEEPER y como todos sabemos, se puede instalar facilmente desde nuestro querido synaptic o desde la terminal como siempre:

sudo apt-get install cryptkeeper

Antes que nada, tenemos que tener a nuestro usuario en el grupo fuse

sudo adduser TuUsuario fuse

Vamos al lío, ya lo tenemos instalado, nuestro usuario agregado al grupo y queremos empezar a "esconder" nuestras cosas, así que buscaremos el programa en cuestión en Aplicaciones / Herramientas del sistema.

Cuando se inicie, veremos en nuestro panel que nos sale un "candado" o una especie de "caja fuerte" bueno, dependerá del tema de escritorio que tengais instalados, pero vamos, que lo vereis facilmente.
Bien, nos pondremos sobre el, daremos click con el botón izquierdo del ratón y veremos que nos sale un menú muy simple, más simple que el salpicadero de un seat panda vamos, nos encontraremos esto:

• importar carpeta cifrada
• nueva carpeta cifrada

Creo que es fácil la elección ¿no?, pues venga vamos a decirle que queremos crear una nueva carpeta y nos abrirá una ventana como esta

Como podéis ver nos da la opción de darle nombre y de elegir el sitio donde queramos que se nos "aparezca" una vez que decidamos abrirla, en este caso he puesto mi escritorio y continuamos pulsando "adelante"

La siguiente ventana que se nos abrirá es la que nos pide que pongamos la contraseña con la cual queremos encryptar nuestra carpeta, para que así no pueda verla nadie, si no se pone la contraseña no habrá forma de ver su contenido, de echo no veremos ni tan siquiera la carpeta en sí, puesto que no llegará a montarse.

Más de lo mismo, adelante y..... ¡¡¡ya está!!! tenemos nuestra carpeta cifrada y lista para poner lo que nos apetezca dentro y a salvo de curiosos.

Ahora que lo tenemos, sólo nos queda abrirla, nos iremos al "candado" y pulsando botón izquierdo veremos que a parte de lo mencionado anteriormente, de importar o crear carpeta nueva, arriba nos dice que hay un directorio creado, yo he creado uno con el nombre de la distro DMDc, como podréis ver, bueno, y hay otro que fue con el que hice los "experimentos" antes de publicarlo, jejeje, aquí lo veis.

Lo marcamos y nos pedirá la contraseña que pusimos en el momento de crearla.

 

Y ya está, como podéis ver, en nuestro escritorio nos aparecerá la carpeta que he creado para la ocasión, el uso pues como haríamos con cualquier otra carpeta, copiar, pegar, etc etc.
Ahora ya podemos guardar todo lo que nos interesa proteger de miradas indiscretas.

Sobretodo y muy importante, para desmontar (hacer que desaparezca vamos), no olvidaros de ir al "candado" y desmarcarla, puesto que si le dais a salir de CRYPTKEEPER y no la hayais desmarcado, tened en cuenta que se quedará abierta, con lo cual de poco nos servirá todo esto.
Para salir del programa, pulsamos botón derecho y damos a salir.

Y bueno, esto es todo, espero que os guste y os sirva de ayuda.
Un saludo a todo el mundo.

¿Estáis seguros que vuestra Wifi es segura?

Conocéis el dicho de “en casa del herrero, cuchillo de palo”? Pues el más claro exponente de ello soy yo.

Una parte de mi trabajo está dedicada a instalar/mantener/reparar sistemas de pago electrónico. Como podréis imaginar, la seguridad en estos sistemas es primordial. No me cabe en la cabeza que un TPE (terminal de pago electrónico) se pueda conectar al servidor de pago mediante una red Wifi abierta, por poner un ejemplo. Si pasáis por algún comercio de los que haya instalado (perdonar que no ponga nombres, pero el acuerdo de confidencialidad es importante) podréis comprobar que no os conectáis a la red Wifi ni aunque sepáis la clave.

El caso es que venía comprobando últimamente un descenso en la calidad de mi navegación por Internet. Hace ya meses que Frannoe publicó una entrada en la que describía el uso de una aplicación (Wifi Guard) que permitía saber quién estaba conectado a nuestra red (Aqui). Incluso está añadida en el Repo de DMDc. Y yo, tan pancho, sin usarla. Hasta que me cansé. Y me puse a revisar un poco mi instalación. De los equipos de mi mujer no voy a hablar. Ha leído el último post que publiqué y me ha echado una bronca de campeonato. Me ha prohibido hablar de ella en el Blog. Y como yo me casé para que me mandaran… pues eso.

Primero revisé los ordenadores de los niños. En el sobremesa del mayor, que tiene W7 (sin comentarios), encontré bastantes malwares y rootkits. Bueno, procedí a acordarme de los ancestros del Windows, y lo limpié. Ni quise mirar el historial de navegación... Ojos que no ven...

De su portátil estoy tranquilo. Tiene montado Linux. Y pasé al sobremesa de la niña. Ella tiene XP montado, y sólo lo usa para jugar en páginas de juegos on-line. Curiosamente, estaba limpio. Va a ser que el niño navega por sitios oscuros... Me apunto para otra restringir acceso a páginas “oscuras”.

Aún así, la cosa no iba todo lo bien que yo deseaba. Así que acudí al meollo de la cuestión, mi Wifi.

Hace ya unos años que se rompió el router que me dió mi proveedor. Llamé en su momento y después de una discusión de dos horas con el técnico de soporte, les mandé a buscar tréboles de cuatro hojas. Otro día entraré en detalles de cómo hablar con una Help-Desk.

El caso es que tenía otro router monopuesto en casa, así que lo utilicé y le conecté un Access Point para dar servicio Wifi. Hay varios métodos para asegurar una red Wifi. Lo primero de todo, lógicamente, asegurarla con una contraseña. Como ya debéis saber a estar alturas, utilizar encriptación WEP en la clave, es como poner un cerrojo en la puerta por la parte de fuera... 

Así que nos decantamos por encriptación WPA, o WPA2 si nuestro adaptador lo soporta. No es infalible, pero sólo existen ataques de fuerza bruta para desencriptarla, así que con poner una clave larga y complicada, estamos bastante seguros.

Hay muchos manuales por Internet que indican que se oculte el SSID de la red (el nombre que le ponemos a la red). La verdad es que eso no sirve para nada. Cualquier escaneo de redes wifi te mostrará la red, sin nombre, pero podréis ver la BSSID del emisor, que es por donde se atacan.

Por último, hablando de redes domésticas, podemos utilizar una ACL o Access Control List, que no es más que una lista de las MAC Address de los dispositivos a los que damos acceso a nuestra red. Así, si os compráis un nuevo dispositivo (tablet, smartphone, etc) y queréis conectarlo a la red, teneis que saber la MAC Address del dispositivo. 

Como en mi casa entran continuamente aparatos nuevos que voy probando, esto último lo tengo desactivado. Tampoco es la panacea de la seguridad, ya que cualquier atacante con unos conocimientos medios, puede “clonar” la dirección MAC de nuestra tarjeta de red cuando no estemos.

En fin, este no es un manual de configuración de redes Wifi. Os supongo ya enterados de cómo se hace.

Aquí fue donde me acorde del post de Frannoe. Lo ejecuté, y ... et voilà... Allí estaba el culpable. Un bonito ladrón de Wifi. Ea, asunto arreglado. Será hijo de mil p... Tengo un chorizo robándome la Wifi. Entenderme bien, no me molesta que se use mi ADSL. Yo lo hago con la de otros en montones de ocasiones, pero hago un uso responsable. Consulto correo, un par de páginas, y adiós muy buenas. No se me ocurrirá en la vida conectarme a una ADSL ajena para bajarme la última temporada de Big Bang Theory...

La verdad es que me quedé más perplejo que Frannoe con el Metro de W8. ¿ Cómo se me ha colado el mierdecilla este? Mi clave de acceso tiene 47 caracteres, mezcla mayúsculas, minúsculas, números, símbolos, y alguna palabra en bable… No me podía creer que me la hubiesen reventado. ¿Cuánto tiempo ha estado para descubrir la clave?

Podŕia haber acabado con la historia insertando autenticación por RADIUS, pero me parecía excesivo… Tener que montar un servidor para ello, la verdad es que no me apetecía nada. Bueno, pues cambio la clave, y listo. Genero una nueva, más larga y más complicada. ¡Anda, listillo… inténtalo ahora!

Pues a los cinco minutos ya estaba allí otra vez mi amigo… ¡Pero bueno! Este tío qué tiene en su casa, ¿el Deep Blue?

Pues no. El mierdecilla que me robaba la Wifi (y digo me robaba, porque ya lo he echado, dejándole un regalito...), lo hacía gracias a que los desarrolladores no se pueden estar quietos… No conocen la primera ley de la informática: Si funciona, no toques nada. Así que en el 2007 (como véis, bastante reciente), como la cosa iba bien, se dedicaron a desarrollar un nuevo estándar, para “facilitar al usuario la conexión a una red Wireless con encriptación WPA2”... Sin palabras...

A este engendro lo llamaron WPS, que son las iniciales de Wifi Protected Setup. En pocas palabras, WPS es un mecanismo que se encarga de configurar los dispositivos para conectarse a una red wireless, minimizando la intervención del usuario. Define cuatro tipos de configuraciones distintas para realizar el proceso de autenticación: USB, NFC, PBC y PIN. 

USB se refiere a que las credenciales se transfieren al dispositivo a través de dicho puerto.
NFC se refiere al intercambio de información mediante radiofrecuencia. Es decir, acercamos por ejemplo el smartphone al Access Point, y se transfieren las credenciales. El alcance es muy corto, 20-30 cms.
PBC está referido a que el proceso de autentificación se produce al pulsar un botón físico en el Access Point.

Y llegamos al meollo de la cuestión: el PIN (Personal Identification Number).

Pues sí, resulta que con un simple número PIN, podemos conectarnos a nuestra red Wifi. En sí no parecería malo, pero es que salió a la calle con una vulnerabilidad importante; tanto, que a día de hoy sigue sin resolverse, debido a cómo está construído. ¿No es para correrlos a gorrazos?

Esta vulnerabilidad permire conectarse a cualquier red Wifi que tenga activado WPS en unas pocas horas. ¿No os lo creéis? Vale, como soy de la opinión que el movimiento se demuestra andando, vamos a ver en este post cómo averiguar la clave WPA2 de mi Access Point.

ACLARACION: Antes de escribir este post, estuve hablando con Frannoe. Es evidente que a partir de aquí este post se convierte en un manual de crackeo de claves WPA/WPA2. Frannoe me ha hecho ver que no es distinto lo que voy a hacer yo, que lo que se hace en multitud de webs, donde se publican los password por defecto de determinado tipo de routers, o incluso aplicaciones para descubrirlos. Además, yo lo voy a utilizar para enseñaros cómo protegeros de esta vulnerabilidad. Si alguien lo utiliza para lo que no debe, allá su conciencia. Lo que tiene que hacer la gente es leer este blog, y así no hay problemas.

Bien, para saber cómo funciona el procedimiento de "descubrir" la clave, tenemos que conocer cómo funciona el proceso de autentificación. Vamos a ver si soy capaz de explicarlo sin aburriros. Vamos a centrarnos en la última opción de conexión descrita, utilizando el número PIN. A su vez, este sistema se divide en dos, que se pueden defiir como registro interno y registro externo.

En el registro interno, a través de una interface Web, introducimos en el router el número PIN del dispositivo a conectar, y entre ellos se encargan de configurarse adecuadamente. A priori, una excelente idea, y no pongo objeciones a ello. La cagada viene ahora, con el registro externo.

En él, introducimos el número PIN del router en el dispositivo que queremos conectar. El dispositivo se encarga de comunicarse con el router y darle el PIN. El router lo reconoce, y le transmite las credenciales. ¿A que parece bueno? PUES NO. Si lo haces, hazlo bien. Me explico.

El descubrimiento de la clave se realiza con un ataque de fuerza bruta. Como es un número, no necesitamos un diccionario de palabras, se generan los números secuencialmente, y a correr.

[Frannoe dixit]
Pero… ¿de cuantos números estamos hablando?

[Jose respondere]
El código PIN de un dispositivo es de 8 dígitos. Bueno, miento. El octavo dígito es de control, un check-sum de los 7 anteriores.

[Frannoe dixit] ¿8 dígitos? ¿Estamos hablando de un número que va del 0 al 99.999.999? Son 100 millones de combinaciones…. Eso tarda un poco, ¿no?

[Jose respondere]
Un poco no, tarda un huevo... Pero vaya, que seguro que en menos de una semana está listo. Pero no me interrumpas, que sigo.

Aquí viene la cagada de los desarrolladores. Cuando se produce la autentificación PIN, se realiza en dos pasos, dividiendo el PIN en dos grupos de 4 dígitos. Primero se verifica que la primera mitad es correcta, y una vez verificada, se procede a verificar la segunda mitad del PIN...

Estos tíos estaban fumaos, fijo. Acaban de reducir las combinaciones del PIN de 100.00.000 millones a 20.000 e incluso menos... Fijaos bien. Primera parte del código PIN: 4 dígitos (o 10.000 combinaciones, si incluímos el 0000). Segunda parte, 3 dígitos, ya que el último dígito es una suma de control. O lo que es lo mismo, 1000 combinaciones, si incluimos al 0. Hemos pasado de 100.000.000 millones a 11.000... Si yo hago algo parecido en mi trabajo, me corren a gorrazos, amén de mandarme a la p... calle, claro.

[Frannoe dixit]
Entonces, ¿de cuanto tiempo estamos hablando?

[Jose respondere]
Pues mira, esto no es una ciencia exacta. El proceso de autentificación tarda de 0.5 a 3 segundos por clave en condiciones óptimas, ya que una vez verificado el PIN, hay que generar la key que se devuelve al dispositivo, y otros procesos. El caso es que por eso introdujeron un PIN tan bajo, y sólo numérico. Pero echando unos cálculos simples, podemos asegurar que en unas 4-5 horas tenemos el código PIN.

[Frannoe dixit]
Joooder…. Pero el router hará algo si ve que estamos intentando hackear la clave, ¿no?

[Jose respondere]
Hombre... Qué te diría yo para tenerte tranquilo... Pues queee... NO.
El WPS se implantó allá por el 2007. Y esta vulnerabilidad fue descubierta por Stefan Viehböck en el 2011. Ahí tienes 4 años de limbo. Además, lo único que se puede hacer es implementar un tiempo de espera después de cada n intentos fallidos, para hacer más largo el proceso, ya que el PIN del router o Access Point no se puede cambiar... Y eso en los routers y Access Point nuevos. En los antiguos, hay que actualizar el firmware... ¿Conoces a mucha gente que actualice el firmware de su router?

[Frannoe]
¡Pues desactivo el WPS!

[Jose respondere]
¡Coño Fran! ¡¡Te acabas de cargar mis conclusiones!! ¿Ves por qué no quiero que me preguntes en medio de un post?

[Frannoe dixit]
Vaaale, vaaale... Perdona... Pero habías dicho que lo ibas a demostrar, ¿no?

[Jose respondere]
Venga, va... al lío.

¿Qué necesitamos para “descubrir” el PIN de nuestro router o Access Point? Pues una serie de paquetería, pero tampoco para matarse. Alguna está en los repos, y otra hay que bajársela y compilarla o buscar el deb ya compilado. En concreto, tenemos que tener instalado aircrack-ng (que se descarga desde aquí para versiones de 32 bits o de aquí para versiones de 64 bits),  y reaver (que se encuentra en los repos y lo podemos instalar desde synaptic).

Así que pasamos a nuestro router, en el que se supone que tenemos configurada una clave WPA/WPA2 segura:

En esta otra imagen, tenéis la pestaña de WPS. Como se puede apreciar, no existe opción para cambiar el PIN del router, o desactivar esa opción. Sólo podemos desactivar todo el sistema WPS.

Venga, que se hace tarde. Abrimos una consola y ponemos nuestra tarjeta de red en modo monitor. Eso se hace con el comando airmon-ng start wlan0, en mi caso.

Los errores son típicos y tienen fácil solución, pero como he avisado que esto no es un manual de crackeo, no voy a entrar a describir cómo hacerlo funcionar.

Una vez puesta mi tarjeta en modo monitor, pasamos a escanear las redes a las que tenemos acceso. Para ello, desde consola, tecleamos airodump-ng mon0

Bien, ya tenemos los datos que necesitamos para proceder a preguntarle amablemente a nuestro router (como mucho, 11.000 veces), si el código PIN que le mandamos es correcto.

Nos apuntamos la BSSID de la red en cuestión y el canal por el que transmite. Y desde consola, tecleamos reaver -i mon0 -b [BSSID] -c [CANAL] -a

Y vemos cómo va trabajando. El mismo proceso, unas dos horas después, antes de irme a la cama...

Y a la mañana siguiente...

...vemos como nos indica el PIN del router, y la clave WPA para poder conectarnos a la red.

Podéis comprobar que el PIN es 21846267. Eso quiere decir que ha probado 2184 PIN's hasta dar con la primera mitad, y 626 hasta dar con la segunda. Total, 2810 combinaciones. Tiempo, menos de 5 horas. Ya puedes cambiar la clave WPA, que como yo ya sé el PIN, me vuelvo a conectar a los cinco minutos.

Conclusión. ¡¡¡ Desactivar el WPS insensatos!!!