Blog sobre seguridad informática, privacidad, anonimato, hacking ético, programación y sistemas operativos en general.

Visitas al blog!

Ayúdanos a seguir.

Páginas Amigas

sábado, 18 de noviembre de 2017

Configura "DNS 9.9.9.9 Quad9" en cualquier distribución Linux


Quad9 reúne inteligencia de amenazas cibernéticas sobre dominios maliciosos de una variedad de fuentes públicas y privadas, y bloquea el acceso a esos dominios maliciosos cuando su sistema intenta contactarlos. Cuando utiliza Quad9, los atacantes y el malware no pueden aprovechar los dominios maliciosos conocidos para controlar sus sistemas, y su capacidad para robar sus datos o causar daños se verá obstaculizada. Quad9 es una manera efectiva y fácil de agregar una capa adicional de seguridad a su infraestructura de forma gratuita. En nuestros post anterior comentamos sobre ale uso de DNS Quad9 hoy Te enseñaremos a configurar el DNS 9.9.9.9.

Algunas distribuciones Linux basados ​​en systemd-resolved. Para configurar editamos  /etc/resolv.conf

$ sudo nano /etc/resolv.conf











Guarden y cierre el archivo y reiniciamos el servicio...

Comprobamos: $ dig google.com

                          $ host tu dominio


 
Configure Quad9 en Ubuntu 14.04 /16.04 LTS y Debian 8/9 

Editamos /etc/network/interfaces:
$ sudo nano /etc/network/interfaces 


Configure Quad9 en Archlinux, CoreOS Container Linux, Ubuntu 17.10

Por ejemplo de /etc/systemd/network/05-eth0.network (suponiendo que el nombre de la interfaz es eth0):

## READ following man pages ##
# man systemd-networkd
# man systemd-resolved
##
[Match]
Name=eth0
[Network]
DHCP=no
Domains= tu dominio
IPv6PrivacyExtensions=false
# DNS resolvers (safe to mix IPv4 and IPv6)
DNS=9.9.9.9 2620:fe::fe
# IPv4 gateway and primary address.
Gateway=192.168.1.1
Address=192.168.1.2/24
# IPv6 gateway and primary address.
# Gateway=your-router-ipv6
# Address=your-ipv6-here

Configurar Quad9 usando el NetworkManager en Linux


Quad9 9.9.9.9. DNS de protección contra los ataques de phishing



Global Cyber ​​Alliance (GCA), una organización fundada por organizaciones policiales y de investigación para ayudar a reducir el delito cibernético, se ha asociado con IBM y Packet Clearing House para lanzar un sistema público gratuito de servicio de nombres de dominio. El objetivo de este sistema es bloquear los dominios asociados con botnets, ataques de phishing y otros host maliciosos de Internet, principalmente dirigidos a organizaciones que no ejecutan sus propios servicios de listas blancas DNS y de listas blancas.

Llamado Quad9 (después de la dirección de Protocolo de Internet 9.9.9.9 que el servicio ha obtenido), el servicio funciona como cualquier otro servidor DNS público (como Google), excepto que no devolverá las resoluciones de nombre para los sitios que se identifican a través de amenazas. servicios agregados diariamente "Cualquiera en cualquier lugar puede usarlo", dijo Phil Rettinger, presidente y director de operaciones de GCA, en una entrevista con Ars. El servicio, dice, será "confidencial", sin registrar las direcciones que realizan las solicitudes de DNS: "guardaremos solo datos de geolocalización [aproximada]", dijo, con el objetivo de rastrear la propagación de solicitudes asociadas con solicitudes particulares. dominios maliciosos. "Estamos anonimizando los datos, sacrificando el lado de la privacidad".
La inteligencia en dominios maliciosos proviene de 19 amenazas, una de las cuales es X-Force de IBM. Adnan Baykal, Asesor Técnico Principal de GCA, le dijo a Ars que el servicio extrae estos feeds de amenazas en cualquier formato en el que se publiquen, y los convierte en una base de datos que luego se duplica. Quad9 también genera una lista blanca de dominios que nunca se bloqueará; usa una lista de los principales dominios solicitados de un millón. Durante el desarrollo, Quad9 usó Alexa, pero ahora que la lista de los mejores millones de sitios de Alexa ya no se mantiene, Baykal dijo que GCA y sus socios tuvieron que recurrir a una fuente alternativa para los datos.
También hay una "lista de oro": dominios que nunca deberían bloquearse, como los principales sitios de servicios de Internet, como la nube Azure de Microsoft, Google y los servicios web de Amazon. "Nos damos cuenta de que docs.google.com está organizando ataques de phishing", dijo Baykal. "Pero como se trata de un filtrado de DNS, no podemos bloquear esa URL específicamente. Y no queremos bloquear Google por completo".
Los sitios bloqueados, la lista blanca y las listas de oro se convierten luego en un formato de Zona de política de respuesta (RPZ) antes de ser enviados a los clústeres de servidores DNS en todo el mundo mantenidos por Packet Clearing House mediante transferencias de zona DNS. Los clústeres de servidores DNS, que tienen un equilibrio de carga con dnsdist, usan una combinación de servidores Unbound y PowerDNS para entregar respuestas. "Estamos ejecutando dos variantes diferentes detrás de un equilibrador de carga", dijo Baykal, "de modo que si hay un problema con uno, podemos eliminarlo, o si hay una vulnerabilidad crítica, podemos cerrar uno y aplicarle un parche".
A partir de su lanzamiento, había grupos de servidores DNS configurados en 70 ubicaciones diferentes en todo el mundo; Baykal dijo que la organización espera tener 100 sitios en funcionamiento antes de fin de año. Cada clúster tiene al menos tres servidores, explicó Baykal, "y en algunas áreas críticas, como Chicago, tenemos cinco, siete o nueve sistemas detrás del equilibrador de carga". Cada instancia se ejecuta en una máquina virtual, por lo que se pueden aprovisionar servidores adicionales en la infraestructura de Packet Clearing House, según sea necesario. De todos modos, las velocidades de respuesta de DNS serán lo suficientemente rápidas para que la gran mayoría de los usuarios no noten la diferencia.
Si un nombre de dominio está en la lista de bloqueo, el servicio simplemente responde a la consulta con un mensaje "NXDOMAIN" (dominio inexistente). "Romperá las consultas DNS", dijo Rettinger, "pero tiende a funcionar mejor que sumirse en el abismo" -la práctica de reenviar dominios defectuosos a un host controlado por el servicio, como se ha hecho con algunos dominios botnet incautados en el pasado- "porque si te hundes, puedes romper otras cosas".
Dado que las amenazas se actualizarán una o dos veces al día en todo el mundo, es probable que Quad9 no tenga mucho impacto en el malware que usa direcciones DNS que cambian rápidamente para comando y control. Sin embargo, ofrece un nivel básico de protección contra los ataques de phishing que suplantan el dominio y otros ataques basados ​​en la Web que han sido recogidos por los principales feeds de amenazas. Y las organizaciones pueden registrar con bastante facilidad las respuestas de Quad9 para identificar sistemas en sus propias redes que pueden tener malware o podrían haber sido atacados por ataques de phishing al ingresar las respuestas de NXDOMAIN.


El servicio Quad9 es gratuito, pero necesita ser financiado continuamente. GCA es una organización sin fines de lucro, por lo que el crecimiento a largo plazo del servicio se basa principalmente en que el gobierno y la industria sigan financiándolo. GCA fue financiado inicialmente con $ 25 millones en decomiso de activos criminales dirigidos a la organización por el fiscal de distrito de Manhattan Cyrus Vance Jr. Rettinger dijo que GCA está hablando con otros proveedores principales de DNS sobre cómo pueden replicar el servicio de Quad9, sin embargo, existe la posibilidad de GCA puede ser absorbido por la gran infraestructura de Internet.

En el próximo post te enseñare a instalar DNS Quad9 en cualquier Linux

Fuente: Quad9 

miércoles, 1 de noviembre de 2017

¿Por qué ArchLinux?




Hace varios meses hemos estado recibiendo comentarios sobre el por qué de nuestra inclinación a la distribución ArchLinux al momento de hacer publicaciones, vídeos y demás. En un post anterior sobre hardening encontramos un comentario el cual nos decía lo siguiente:

" Buenos días, las pruebas se harán en Archlinux, necesito entender:

¿Porqué Archlinux?
¿La instalación es más compleja que en otras distros, como Debian o Ubuntu?
¿Se asemeja Archlinux a Kalilinux?

Gracias de antemano. "

 A lo largo de este post vamos a responder esas preguntas, pero sobre todo nos extenderemos en la explicación de "Por qué ArchLinux".

¿Por qué ArchLinux?

1. Porque es Rolling Release. Es decir, Arch Linux se actualiza continuamente. No es necesario esperar a que se libere una versión más actualizada para disponer del último software, características de seguridad, etc… De hecho, en nuestra opinión, esta actualización continua es más segura que actualizar, por ejemplo, entre versiones de Ubuntu, donde más de uno se ha encontrado con problemas.

2. Porque es extremadamente ligero. Arch Linux mantiene el principio KISS (Keep It Simple, Stupid), es decir, mantenlo sencillo, estúpido. El principio KISS establece que la mayoría de sistemas funcionan mejor si se mantienen simples evitando así cualquier complejidad innecesaria. De ahí que en Arch Linux tengamos activados solamente los servicios que vamos a utilizar, o no tengamos cantidades ingentes de librerías instaladas que no vamos a utilizar nunca, por ejemplo.

3. Porque es extremadamente personalizable. La instalación de Arch Linux no incluye entorno gráfico, y cuando lo instalas viene con el sistema base, dejándote así elegir por ti mismo instalar las aplicaciones que prefieras.

4. Porque aprenderás muchísimo sobre Linux. Para poder instalar, configurar y mantener Arch Linux, tendrás que “meter la mano” en bastantes archivos de configuración y tirar bastante de la consola. ¡Aprenderás casi sin darte cuenta!

5. Porque dispone de la mejor documentación. La Wiki de Arch Linux es completísima y fácil de seguir. Si tienes alguna duda sobre cómo configurar algo seguro que lo encuentras en la Wiki. Además la Wiki es consultada no solo por usuarios de ArchLinux, es tan amplia la documentación que sirve para todas las distribuciones GNU/Linux, ArchLinux posee la Wiki más completa de todo GNU/Linux.

6. Porque dispone de una comunidad siempre dispuesta a ayudar. Generalmente las comunidades GNU/Linux tienen un problema: Ofenden a los novatos por hacer pregunas "básicas" sin antes documentarse, además de odiar Windows. En ArchLinux no sucede eso, es una comunidad muy unida y dispuesta a resolver cualquier problema, con algunas excepciones, claro.

7. Porque solo tiene cinco repositorios y AUR. Con sus cinco repositorios oficiales (Community, Core, Extra, Multilib, Testing[Opcional]) y AUR, en ArchLinux tienes disponibles cuantos paquetes necesites. No es necesario agregar algún otro repositorio para instalar paquetes que no están en los repositorios oficiales.

8. Porque su gestor de paquetes es pacman. Pacman es tan genial como apt, salvo porque es más sencillo de usar, los comando son más cortas y es muchísimo más rápido.

9. Porque es muy estable. Seguro que Debian es muy estable, pero con todas las ventajas que he mencionado antes, ArchLinux está al 95% del nivel de estabilidad si tomamos a Debian cómo base, ¿Qué más se puede pedir?

¿La instalación es más compleja que en otras distros, como Debian o Ubuntu?

Sí, ya que no dispone de un instalador gráfico oficial pero no es algo del otro mundo, en este post explicamos detalladamente cómo hacerlo.

¿Se asemeja Archlinux a Kali Linux?

Cómo mencionamos antes, ArchLinux se puede moldear a tu antojo y hacerla similar a cualquier otra distribución, sin embargo si deseas una distribución basada en ArchLinux y enfocada al pentesting de inmediato, te recomendamos BlackArch, si deseas ser más profesional y convertir ArchLinux en una distribución de Pentesting, lee este post.

https://blackarch.org/images/slider/ba-slider2.pnghttps://blackarch.org/images/slider/ba-slider.png


El mundo GNU/Linux tiene muchas opciones de todos los colores y sabores, nosotros recomendamos ArchLinux.

Esperamos que esta publicación haya sido de utilidad, cualquier inquietud o sugerencia dejarla en los comentarios en bien, en los medios que indicamos a continuación.
Síguenos en Facebook, Twitter, unete a nuestra charla en Riot (Para charlar con nosotros online) o únete a Telegram.

También puedes dejar su donación a nuestra cuenta Paypal.



jueves, 26 de octubre de 2017

#Linux-Hardening (1): Contraseñas.


Las contraseñas son la clave para un sistema Linux seguro. Aseguran sus cuentas de usuario, sistemas de archivos encriptados, aplicaciones y claves SSH/GPG . Son la principal forma en que una computadora elige confiar en la persona que la usa, por lo que una gran parte de la seguridad consiste simplemente en elegir contraseñas seguras y protegerlas. Una contraseña puede cambiar dráticamente la seguridad de cualquier sistema, asegúrate de elegir la correcta.

Elegir contraseñas seguras.

Cuando la seguridad se basa en una frase de contraseña, debe ser lo suficientemente compleja como para no ser fácilmente adivinada, por ejemplo, que no contenga nada de información personal, o que no pueda ser descifrada usando, por ejemplo, ataques de fuerza bruta. Los principios de las contraseñas fuertes se basan en la longitud y la aleatoriedad . En la criptografía, la calidad de una frase de contraseña se conoce como: seguridad entrópica.

Entre las contraseñas inseguras están aquellas que contienen:
1. Información de identificación personal (por ejemplo, el nombre de su perro, fecha de nacimiento, código de área, videojuego favorito).
2. Sustituciones de caracteres simples en palabras (Ej., s3cur1ty)
3. Palabras o cadenas comunes seguidas o precedidas por números agregados, símbolos o caracteres (p. Ej., linux25102017%)
4. Frases comunes o frases cortas de palabras relacionadas gramaticalmente (por ejemplo, kernel linux), e incluso con la sustitución de caracteres.

La elección correcta para una contraseña es algo largo (8-20 caracteres, dependiendo de la importancia) y completamente aleatorio. Una buena técnica para construir contraseñas seguras y aleatorias es basarlas en los caracteres de cada palabra de una oración. Tome por ejemplo "Somos Security Hack Labs" podría traducirse a 5oS3Ha(|4bS. Este enfoque podría hacer que sea más fácil recordar una contraseña.

5o = Somos, S3 = Security, Ha( = Hack, |4bS = Labs. 

Un mejor enfoque es generar contraseñas pseudoaleatorias con herramientas como pwgen o apg: para memorizarlas, una técnica (para las que se escriben a menudo) es generar una contraseña larga y memorizar una cantidad mínimamente segura de caracteres, anotando temporalmente el total generado cuerda. Con el tiempo, aumente la cantidad de caracteres escritos, hasta que la contraseña esté memorizada totalmente. Esta técnica es más difícil, pero puede proporcionar la confianza de que una contraseña no aparecerá en listas de palabras o ataques de fuerza bruta "inteligente" que combinen palabras y caracteres sustitutos o que pueden ser encontrados en diccionarios para fuerza bruta.

Podemos utilizar las dos herramientas mencionadas anteriormente de la siguiente manera:

* Pwgen.


[root@SecHackLabs shl]# pwgen --help

Usage: pwgen [ OPTIONS ] [ pw_length ] [ num_pw ]



Options supported by pwgen:

  -c or --capitalize

    Include at least one capital letter in the password

  -A or --no-capitalize

    Don't include capital letters in the password

  -n or --numerals

    Include at least one number in the password

  -0 or --no-numerals

    Don't include numbers in the password

  -y or --symbols

    Include at least one special symbol in the password

  -s or --secure

    Generate completely random passwords

  -B or --ambiguous

    Don't include ambiguous characters in the password

  -h or --help

    Print a help message

  -H or --sha1=path/to/file[#seed]

    Use sha1 hash of given file as a (not so) random generator

  -C

    Print the generated passwords in columns

  -1

    Don't print the generated passwords in columns

  -v or --no-vowels

    Do not use any vowels so as to avoid accidental nasty words

Esas son las opciones generales de la herramienta, una buena manera de usarla para obtener una contraseña segura sería la siguiente:

[root@SecHackLabs shl]# pwgen -cnyv 20 100


-c : Incluye al menos una mayúscula en la contraseña.
-n : Incluye al menos un número en la contraseña.
-y : Incluye carácteres especiales en la contraseña.
-v : No usa vocales.
20 : El número de carácteres en la contraseña.
100 : El número de contraseñas generadas.

Nos arrojará contraseñas cómo estas:


* Apg.

[root@SecHackLabs shl]# apg -h

apg   Automated Password Generator
        Copyright (c) Adel I. Mirzazhanov

apg   [-a algorithm] [-r file] 
      [-M mode] [-E char_string] [-n num_of_pass] [-m min_pass_len]
      [-x max_pass_len] [-c cl_seed] [-d] [-s] [-h] [-y] [-q]

-M mode         new style password modes
-E char_string  exclude characters from password generation process
-r file         apply dictionary check against file
-b filter_file  apply bloom filter check against filter_file
                (filter_file should be created with apgbfm(1) utility)
-p substr_len   paranoid modifier for bloom filter check
-a algorithm    choose algorithm
                 1 - random password generation according to
                     password modes
                 0 - pronounceable password generation
-n num_of_pass  generate num_of_pass passwords
-m min_pass_len minimum password length
-x max_pass_len maximum password length
-s              ask user for a random seed for password
                generation
-c cl_seed      use cl_seed as a random seed for password
-d              do NOT use any delimiters between generated passwords
-l              spell generated password
-t              print pronunciation for generated pronounceable password
-y              print crypted passwords
-q              quiet mode (do not print warnings)
-h              print this help screen
-v              print version information

Una buena manera de usar apg es así:

[root@SecHackLabs shl]# apg -a 1 -m 20 -n 20


-a 1 : Genera contraseñas random de acuerdo a los modos de contraseñas.
-m 20 : El mínimo de la contraseña son 20 carácteres.
-n 20 : El número de contraseñas generadas (20). 

El resultado será:



También es muy eficaz combinar estas dos técnicas guardando contraseñas aleatorias largas y complejas con un administrador de contraseñas (Keepassxc es la mejor alternativa y al cual más adelante le dedicaremos un apartado en el blog para explicar sus funcionalidades), que a su vez se accederá con una contraseña que deberá usarse solo con ese fin, evitando sobre todo transmitirla alguna vez en cualquier tipo de red. Este método, por supuesto, limita el uso de las contraseñas almacenadas a los terminales donde la base de datos está disponible para lectura (que, por otro lado, podría verse como una característica de seguridad adicional).




Mantenimiento de contraseñas


Una vez que elija una contraseña segura, asegúrese de mantenerla segura. Tenga cuidado con la manipulación y evite reutilizar contraseñas para que los servidores inseguros no puedan filtrar más información de la necesaria. Los administradores de contraseñas pueden ayudar a administrar grandes cantidades de contraseñas complejas: si está copiando y pegando las contraseñas almacenadas del administrador a las aplicaciones que las necesitan, asegúrese de borrar el buffer de copia o portapapeles cada vez y asegúrese de que no se guarden en ningún tipo de log (por ejemplo, no los pegue en la terminal de comandos, que los almacenaría en archivos como .bash_history).

Como regla, no elijas contraseñas inseguras solo porque las más seguras son más difíciles de recordar. Las contraseñas son un acto de equilibrio. Es mejor tener una base de datos encriptada de contraseñas seguras, protegidas por una clave y una contraseña maestra sólida, que tener muchas contraseñas débiles similares.

Otro aspecto de la fortaleza de la frase de contraseña es que no debe ser fácilmente recuperable desde otros lugares. Si utiliza la misma frase de contraseña para su inicio de sesión y para el cifrado del disco, asegúrese de que /etc/shadow también termine en una partición cifrada o utilice un algoritmo de hash fuerte (es decir, sha-512/bcrypt, no md5) para el hash de contraseña almacenado. Conozca más acerca de los hashes SHA aquí.

Forzando el uso de contraseñas seguras usando pam_cracklib.

pam_cracklib ofrece protección contra ataques de fuerza bruta y ayuda a configurar una política de seguridad aplicable a todo el sistema.

Nota: La cuenta root no se ve afectada por la implementación de políticas con pam_cracklib.

A continuación explicaremos cómo llevar a cabo la implementación de esta política para la creación de contraseñas:

1. Solicitar 2 veces la contraseña en caso de error.
2. 10 caracteres de longitud mínima (opción minlen).
3. Al menos 6 caracteres deben ser diferentes de la contraseña anterior al ingresar una nueva (opción difok).
4. Al menos 1 dígito (opción dcredit).
5. Al menos 1 mayúscula (opción ucredit).
6. Al menos 1 carácter especial (opción ocredit).
7. Al menos 1 minúscula (opción icredit).

Editamos el archivo /etc/pam.d/passwd de la siguiente manera:


#%PAM-1.0
password        required        pam_unix.so sha512 shadow nullok
password        required        pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1

Ahora vemos un ejemplo de los mensajes que nos arroja cada vez que incumplimos uno de los parámetros anteriores y finalmente nos bloquea los intentos:

[shl@SecHackLabs ~]$ passwd
Changing password for shl.
Current password: 
New password: 
Retype new password: 
BAD PASSWORD: is too similar to the old one
New password: 
BAD PASSWORD: it is too simplistic/systematic
passwd: Have exhausted maximum number of retries for service
passwd: password unchanged

Esperamos que esta publicación haya sido de utilidad, cualquier inquietud o sugerencia dejarla en los comentarios en bien, en los medios que indicamos a continuación.
 
Síguenos en Facebook, Twitter, unete a nuestra charla en Riot (Para charlar con nosotros online) o únete a Telegram.

También puedes dejar su donación a nuestra cuenta Paypal.
  

lunes, 23 de octubre de 2017

#Linux-Hardening: Concepto.


Si quieres sentirte seguro, asegura tu sistema. 

Uno de los primeros pasos si queremos adentrarnos en el mundo de la Seguridad Informática más allá de la simple ejecución de scripts y de buscar la manera de vulnerar sistemas (escaneando en busca de fallos o cualquier otro método), es sin duda, asegurar a un nivel apropiado el sistema operativo que vamos a utilizar para realizar nuestras pruebas y trabajos que esto implica. 

Está claro que la mayoría de especialistas en Seguridad Informática toman a GNU/Linux cómo su primera alternativa al momento de introducirse en el mundo del hacking, pentesting y todo lo relacionado, debido a la seguridad que ofrecen los sistemas GNU/Linux por naturaleza pero pese a ello no debemos entrar en la zona de confort y confiarnos en que con solamente usar GNU/Linux estamos seguros, la mayoría de seguridad en un sistema depende de la persona que lo utiliza y de las políticas que utiliza para hacerlo seguro.

Tal y cómo lo propusimos en nuestra sala de chat empezaremos con una serie de post identificados con el título #Linux-Hardening y la etiqueta linux-hardening, todo esto con la finalidad de que todo aquel que siga estos post, una vez finalizada la serie tendrá una seguridad garantizada en su sistema operativo y no solo a nivel de software, sino que también tendrá una mentalidad más centrada y responsable sobre importancia de un sistema seguro y de los riesgos permanentes que hay en la red, a los cuales nos exponemos cada vez que establecemos una conexion.

A lo largo de esta serie de post vamos a tratar diferentes temas, desde el hardening básico hasta el hardening al Kernel GNU/Linux, inclusive el hardening a componentes del hardware.

Conceptos a tener en cuenta.


1. Es posible reforzar la seguridad tanto como para inutilizar su sistema. El truco es asegurarlo sin exagerar.

2. Hay muchas otras cosas que se pueden hacer para aumentar la seguridad, pero la mayor amenaza es, y siempre será, el usuario. Cuando piensas en seguridad, tienes que pensar en capas. Cuando una capa se rompe, otra debe detener el ataque. Pero nunca puede hacer que el sistema sea 100% seguro a menos que desenchufe la máquina de todas las redes, la trabe en una caja fuerte y nunca la use.

3. Sé un poco paranoico, eso ayuda. Y sé sospechoso. Si algo suena demasiado bueno para ser verdad, ¡probablemente no lo sea!

4. El principio de privilegio mínimo: cada parte de un sistema solo debería poder acceder a lo que se requiere para usarlo, y nada más.

5. El sistema que utilizaremos para las pruebas será ArchLinux, pero es muy probable que todas las mejoras de seguridad que se realizaran funcionen en la mayoría de distribuciones GNU/Linux, cuando haya una específica para alguna distribución la marcaremos con el hashtag #SoloPara$(distro), ejemplo: #SoloParaArchLinux.

6. Las fuentes de información serán: https://wiki.archlinux.org/ y experiencias propias.

7. Las publicaciones que se hagan las añadiremos en la sección "Publicaciones" de este post y se actualizará con cada entrega, si deseas estar al tanto guarda este post en los favoritos.

Publicaciones.

Con esto finalizamos este post, el cual tenía cómo finalidad informar el concepto general del hardening y la importancia de este.

Cualquier inquietud o sugerencia dejarla en los comentarios, o bien, en los medios que indicamos a continuación.
Síguenos en Facebook, Twitter, unete a nuestra charla en Riot , únete a Telegram o al IRC en Freenode.

lunes, 16 de octubre de 2017

Comunicado Oficial - ¡Hackean el protocolo WPA2! Todas las redes WiFi en riesgo.


Introducción


Descubrimos debilidades serias en WPA2, un protocolo que asegura todas las redes Wi-Fi protegidas modernas. Un atacante dentro del alcance de la víctima puede explotar estas debilidades usando Key Reinstallation Attacks(KRACKs). Concretamente, los atacantes pueden usar esta nueva técnica de ataque para leer información que previamente se suponía que estaba cifrada de forma segura. Esto se puede abusar para robar información confidencial, como números de tarjetas de crédito, contraseñas, mensajes de chat, correos electrónicos, fotos, etc. El ataque funciona contra todas las redes Wi-Fi protegidas modernas . Dependiendo de la configuración de la red, también es posible inyectar y manipular datos. Por ejemplo, un atacante podría inyectar ransomware u otro malware en sitios web.

Las debilidades están en el estándar Wi-Fi en sí y no en productos individuales o implementaciones. Por lo tanto, es probable que se vea afectada cualquier implementación correcta de WPA2. Para evitar el ataque, los usuarios deben actualizar los productos afectados tan pronto como las actualizaciones de seguridad estén disponibles. Tenga en cuenta que si su dispositivo es compatible con Wi-Fi, lo más probable es que se vea afectado. Durante nuestra investigación inicial, descubrimos que Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys y otros, se ven afectados por alguna variante de los ataques. Para obtener más información sobre productos específicos, consulte la base de datos de CERT (Computer Emergency Response Team)/CC o comuníquese con su proveedor.

La investigación detrás del ataque se presentará en la conferencia sobre Seguridad Informática y comunicaciones (CCS) y en la conferencia Black Hat Europe.

Demostración.

Cómo prueba de concepto, ejecutamos un ataque clave de reinstalación contra un teléfono inteligente Android. En esta demostración, el atacante puede descifrar todos los datos que transmite la víctima. Para un atacante, esto es fácil de lograr, porque nuestro ataque de reinstalación clave es excepcionalmente devastador contra Linux y Android 6.0 o superior. Esto se debe a que Android y Linux pueden engañarse para (re)instalar una clave de cifrado totalmente nula( ver más abajo para obtener más información ). Al atacar a otros dispositivos, es más difícil descifrar todos los paquetes, aunque se puede descifrar un gran número de paquetes. En cualquier caso, la siguiente demostración destaca el tipo de información que un atacante puede obtener al 
realizar ataques de reinstalación de claves contra redes de Wi-Fi protegidas:



Nuestro ataque no se limita a recuperar credenciales de inicio de sesión (es decir, direcciones de correo electrónico y contraseñas). En general, cualquier dato o información que la víctima transmita puede descifrarse. Además, según el dispositivo que se utilice y la configuración de la red, también es posible descifrar los datos enviados a la víctima (por ejemplo, el contenido de un sitio web). Aunque los sitios web o las aplicaciones pueden usar HTTPS como una capa adicional de protección, le advertimos que esta protección extra puede (todavía) pasarse por alto en un número preocupante de situaciones. Por ejemplo, HTTPS se omitió anteriormente en el software de navegadores, en iOS y OS X de Apple, en aplicaciones de Android , en aplicaciones de Android nuevamente, en aplicaciones de respaldo e incluso en aplicaciones VPN.

Detalles


Nuestro ataque principal está en contra del protocolo de enlace (handshake) de 4 vías del protocolo WPA2. Este protocolo de enlace se ejecuta cuando un cliente desea unirse a una red Wi-Fi protegida, y se utiliza para confirmar que tanto el cliente como el punto de acceso poseen las credenciales correctas (por ejemplo, la contraseña precompartida de la red). Al mismo tiempo, el protocolo de enlace de 4 vías también negocia una nueva clave de cifrado que se utilizará para cifrar todo el tráfico subsiguiente. Actualmente, todas las redes Wi-Fi protegidas modernas utilizan el protocolo de enlace de 4 vías. Esto implica que todas estas redes se ven afectadas por (alguna variante de) nuestro ataque. Por ejemplo, el ataque funciona contra redes Wi-Fi personales y empresariales, contra el WPA anterior y el último estándar WPA2, e incluso contra redes que solo usan AES. Todos nuestros ataques contra WPA2 usan una técnica novedosa llamada ataque de reinstalación clave (KRACK):

Ataques clave de reinstalación: descripción de alto nivel


En un ataque de reinstalación de clave, el adversario engaña a una víctima para que vuelva a instalar una clave que ya está en uso. Esto se logra manipulando y reproduciendo mensajes criptográficos de comunicación . Cuando la víctima reinstala la clave, los parámetros asociados, como el número de paquete de transmisión incrementa y el número de paquete de recepción (es decir, el contador de reproducción) se restablecen a su valor inicial. Básicamente, para garantizar la seguridad, una clave solo debe instalarse y usarse una vez. Desafortunadamente, encontramos que esto no está garantizado por el protocolo WPA2. Al manipular los protocolos de enlace criptográficos, podemos abusar de esta debilidad en la práctica.

Ataques clave de reinstalación: ejemplo concreto contra el protocolo de enlace de 4 vías.


Como se describe en la introducción del documento de investigación, la idea detrás de un ataque clave de reinstalación se puede resumir de la siguiente manera. Cuando un cliente se une a una red, ejecuta el enlace de 4 vías para negociar una nueva clave de cifrado. Instalará esta clave después de recibir el mensaje 3 del protocolo de enlace de 4 vías. Una vez que se instala la clave, se usará para cifrar los marcos de datos normales utilizando un protocolo de encriptación. Sin embargo, como los mensajes se pueden perder o descartar, el Punto de acceso (AP) retransmitirá el mensaje 3 si no recibió una respuesta apropiada como acuse de recibo. Como resultado, el cliente puede recibir el mensaje 3 varias veces. Cada vez que recibe este mensaje, reinstalará la misma clave de cifrado y, por lo tanto, reiniciará el número de paquete de transmisión incremental y recibirá el contador de reproducción utilizado por el protocolo de cifrado. Mostramos que un atacante puede forzar estos restablecimientos recolectando y reproduciendo retransmisiones del mensaje 3 del protocolo de enlace de 4 vías. Al forzar la reutilización del nonce de esta manera, el protocolo de encriptación puede ser atacado, por ejemplo, los paquetes pueden ser reproducidos, descifrados y / o forjados. La misma técnica también se puede utilizar para atacar a la clave de grupo, PeerKey, TDLS, y rápido enlace de transición BSS.

Impacto practico


En nuestra opinión, el ataque más extendido y prácticamente impactante es el ataque de reinstalación clave contra el protocolo de enlace de 4 vías. Basamos este juicio en dos observaciones. Primero, durante nuestra propia investigación encontramos que la mayoría de los clientes se vieron afectados por ella. En segundo lugar, los adversarios pueden usar este ataque para descifrar los paquetes enviados por los clientes, lo que les permite interceptar información confidencial, como contraseñas o cookies. El descifrado de paquetes es posible porque un ataque de reinstalación de clave hace que los números de transmisión (a veces también denominados números de paquete o vectores de inicialización) se restablezcan a cero. Como resultado, se usa la misma clave de cifrado con valores nonce que ya se han usado en el pasado . A su vez, esto hace que todos los protocolos de encriptación de WPA2 reutilicen el flujo de claves al encriptar los paquetes. En caso de que un mensaje que reutilice el flujo de claves tenga contenido conocido, se vuelve trivial derivar el flujo de claves usado. Este flujo de claves se puede usar para descifrar mensajes con el mismo valor. Cuando no hay contenido conocido, es más difícil descifrar paquetes, aunque aún es posible en varios casos. En la práctica, encontrar paquetes con contenido conocido no es un problema, por lo que se debe suponer que cualquier paquete puede descifrarse.

La capacidad de descifrar paquetes puede usarse para descifrar paquetes TCP/SYN. Esto permite a un adversario obtener los números de secuencia TCP de una conexión y secuestrar las conexiones TCP. Como resultado, aunque se usa WPA2, el adversario ahora puede realizar uno de los ataques más comunes contra redes Wi-Fi abiertas: inyectar datos maliciosos en conexiones HTTP no cifradas. Por ejemplo, un atacante puede abusar de esto para inyectar ransomware o malware en sitios web que la víctima está visitando.

Si la víctima usa el protocolo de cifrado WPA-TKIP o GCMP, en lugar de AES-CCMP, el impacto es especialmente catastrófico. Contra estos protocolos de encriptación, la reutilización de nonce permite a un adversario no solo descifrar, sino también forjar e inyectar paquetes . Además, debido a que GCMP utiliza la misma clave de autenticación en ambas direcciones de comunicación, y esta clave se puede recuperar si los números se reutilizan, se ve especialmente afectada. Tenga en cuenta que la compatibilidad con GCMP se está actualizando con el nombre Wireless Gigabit (WiGig), y se espera que se adopte a un ritmo elevado en los próximos años.

La dirección en la que los paquetes pueden descifrarse (y posiblemente forjarse) depende del protocolo de enlace que se está atacando. Simplificado, al atacar el enlace de 4 vías, podemos descifrar (y forjar) los paquetes enviados por el cliente. Al atacar el protocolo de enlace de Fast BSS Transition (FT), podemos descifrar (y forjar) los paquetes enviados al cliente. Finalmente, la mayoría de nuestros ataques también permiten la reproducción de tramas unidifusión, difusión y multidifusión. Para más detalles, consulte la Sección 6 de nuestro trabajo de investigación .

Tenga en cuenta que nuestros ataques no recuperan la contraseña de la red Wi-Fi . Tampoco recuperan (ninguna parte de) la nueva clave de encriptación que se negocia durante el protocolo de enlace de 4 vías.

Android y Linux


Nuestro ataque es especialmente catastrófico contra la versión 2.4 y superior de wpa_supplicant, un cliente Wi-Fi comúnmente usado en Linux. Aquí, el cliente instalará una clave de cifrado totalmente cero en lugar de reinstalar la clave real. Esta vulnerabilidad parece ser causada por un comentario en el estándar Wi-Fi que sugiere borrar la clave de cifrado de la memoria una vez que se instaló por primera vez. Cuando el cliente recibe ahora un mensaje retransmitido 3 del protocolo de 4 vías, volverá a instalar la clave de cifrado ahora borrada, instalando efectivamente una clave de cero. Como Android usa wpa_supplicant, Android 6.0 y superior también contiene esta vulnerabilidad. Esto hace que sea trivial interceptar y manipular el tráfico enviado por estos dispositivos Linux y Android . Tenga en cuenta que actualmente el 41% de los dispositivos Android son vulnerables a esta variante excepcionalmente devastadora de nuestro ataque.

Asignados identificadores CVE


Se asignaron los siguientes identificadores y vulnerabilidades comunes (CVE, por sus siglas en inglés) para rastrear qué productos se ven afectados por instancias específicas de nuestro ataque de reinstalación clave:

* CVE-2017-13077 : Reinstalación de la clave de encriptación pairwise (PTK-TK) en el enlace de 4 vías.
* CVE-2017-13078 : Reinstalación de la clave de grupo (GTK) en el enlace de 4 vías.
* CVE-2017-13079 : Reinstalación de la clave del grupo de integridad (IGTK) en el enlace de 4 vías.
* CVE-2017-13080 : Reinstalación de la clave de grupo (GTK) en el protocolo de enlace de grupo.
* CVE-2017-13081 : Reinstalación de la clave de grupo de integridad (IGTK) en el protocolo de enlace de grupo.
* CVE-2017-13082 : aceptación de una solicitud de reasignación de transición rápida de BSS (FT) y reinstalación de la clave de cifrado por parejas (PTK-TK) mientras la procesa. 
* CVE-2017-13084 : Reinstalación de la tecla STK en el protocolo de enlace PeerKey.
* CVE-2017-13086 : reinstalación de la clave de configuración de enlace directo Tunneled (TDLS) PeerKey (TPK) en el protocolo de enlace TDLS.
* CVE-2017-13087 : reinstalación de la clave de grupo (GTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
* CVE-2017-13088 : reinstalación de la clave de grupo de integridad (IGTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).

Tenga en cuenta que cada identificador de CVE representa una instanciación específica de un ataque de reinstalación de clave. Esto significa que cada ID de CVE describe una vulnerabilidad de protocolo específica y, por lo tanto, muchos proveedores se ven afectados por cada ID de CVE individual . También puede leer la nota de vulnerabilidad VU#228519 de CERT/CC para obtener detalles adicionales sobre qué productos se sabe que están afectados.

Herramientas


Hemos realizado secuencias de comandos para detectar si una implementación del protocolo de enlace de 4 vías, el protocolo de enlace de grupo o el protocolo de enlace de transición rápida (FT) es vulnerable a los ataques de reinstalación de claves. Estas secuencias de comandos se lanzarán una vez que hayamos tenido tiempo de limpiar sus instrucciones de uso.

También realizamos un script de prueba de concepto que explota la instalación de la llave (re) all-zero presente en ciertos dispositivos Android y Linux. Este script es el que usamos en el video de demostración . Será lanzado una vez que todos tengan una posibilidad razonable de actualizar sus dispositivos (y tuvimos un cambio para preparar el repositorio de códigos para su lanzamiento). Observamos que la fiabilidad de nuestro script de prueba de concepto puede depender de cuán cerca esté la víctima de la red real. Si la víctima está muy cerca de la red real, la secuencia de comandos puede fallar porque la víctima siempre se comunicará directamente con la red real, incluso si la víctima está (forzada) en un canal de Wi-Fi diferente a esta red.


Preguntas y Respuestas


¿Necesitamos ahora WPA3?

No, afortunadamente las implementaciones pueden parchearse en una forma compatible con versiones anteriores . Esto significa que un cliente parcheado puede comunicarse con un punto de acceso sin parcheo, y viceversa. En otras palabras, un cliente o puntos de acceso parcheado envía exactamente los mismos mensajes del protocolo de enlace que antes, y exactamente en los mismos momentos en el tiempo. Sin embargo, las actualizaciones de seguridad asegurarán que una clave solo se instala una vez, evitando nuestros ataques. De nuevo, actualice todos sus dispositivos una vez que las actualizaciones de seguridad estén disponibles.

¿Debo cambiar mi contraseña de Wi-Fi?

Cambiar la contraseña de su red Wi-Fi no impide (o atenúa) el ataque. Por lo tanto, no tiene que actualizar la contraseña de su red Wi-Fi. En su lugar, debe asegurarse de que todos sus dispositivos estén actualizados, y también debe actualizar el firmware de su enrutador. Después de actualizar su enrutador, puede opcionalmente cambiar la contraseña de Wi-Fi como precaución adicional.

Estoy usando WPA2 con solo AES. ¿Eso también es vulnerable?

Sí, esa configuración de red también es vulnerable. El ataque funciona contra WPA1 y WPA2, contra redes personales y empresariales, y contra cualquier conjunto de cifrado que se use (WPA-TKIP, AES-CCMP y GCMP). ¡Entonces todos deben actualizar sus dispositivos para evitar el ataque!

Usas la palabra "nosotros" en este sitio web. ¿Quienes somos nosotros?

Utilizo la palabra "nosotros" porque eso es lo que estoy acostumbrado a escribir en los documentos. En la práctica, todo el trabajo lo hago yo, siendo yo Mathy Vanhoef. Mi impresionante supervisor se agrega bajo una autoría honorífica al trabajo de investigación por su excelente orientación general. Pero todo el trabajo real se hizo por mi cuenta. Entonces, la lista de documentos académicos del autor no representa la división del trabajo :)

¿Es mi dispositivo vulnerable?

Probablemente. Cualquier dispositivo que use Wi-Fi es probablemente vulnerable. Póngase en contacto con su proveedor para obtener más información.

¿Qué sucede si no hay actualizaciones de seguridad para mi enrutador?

Nuestro ataque principal está en contra del protocolo de enlace de 4 vías, y no explota los puntos de acceso, sino que se dirige a los clientes. Por lo tanto, es posible que su enrutador no requiera actualizaciones de seguridad. Le recomendamos encarecidamente que contacte a su proveedor para obtener más detalles. Sin embargo, en general, puede intentar mitigar los ataques contra enrutadores y puntos de acceso deshabilitando la funcionalidad del cliente (que se utiliza, por ejemplo, en los modos de repetidor) y deshabilitando 802.11r (roaming rápido). Para los usuarios habituales del hogar, su prioridad debe ser la actualización de clientes, como computadoras portátiles y teléfonos inteligentes.

¿Cómo descubriste estas vulnerabilidades?

Cuando trabajé en la versión final de otro artículo, estaba revisando dos reclamos que hicimos sobre la implementación de OpenBSD del enlace de 4 vías. En cierto sentido, estaba desfalleciendo, porque se suponía que debía estar terminando el trabajo, en lugar de mirar el código. Pero allí estaba yo, inspeccionando un código que ya leí cien veces, para evitar tener que trabajar en el próximo párrafo. Fue en ese momento cuando me llamó la atención una llamada particular a ic_set_key . Esta función se invoca al procesar el mensaje 3 del protocolo de enlace de 4 vías, e instala la clave de par al controlador. Mientras miraba esa línea de código pensé: "Ha. Me pregunto qué pasa si esa función se llama dos veces". En el momento en que (correctamente) adiviné que llamarlo dos veces podría restablecer los nonces asociados a la clave. Y dado que el mensaje 3 puede ser retransmitido por el punto de acceso, en la práctica podría llamarse de hecho dos veces. "Es mejor hacer una nota de eso. Otros proveedores también pueden llamar a esa función dos veces. Pero terminemos primero este artículo ... " . Unas semanas más tarde, después de terminar el trabajo y completar otro trabajo, investigué esta nueva idea con más detalle. Y el resto es historia.

El protocolo de enlace de 4 vías fue matemáticamente probado como seguro. ¿Cómo es posible tu ataque?

La breve respuesta es que la prueba formal no asegura que una llave se instale una vez. En cambio, solo garantiza que la clave negociada permanezca en secreto, y que los mensajes de saludo no se pueden falsificar.

La respuesta más larga se menciona en la introducción de nuestro trabajo de investigación : nuestros ataques no violan las propiedades de seguridad probadas en el análisis formal del protocolo de enlace de 4 vías. En particular, estas pruebas indican que la clave de cifrado negociada sigue siendo privada, y que se confirma la identidad tanto del cliente como del punto de acceso (AP). Nuestros ataques no pierden la clave de cifrado. Además, aunque los marcos de datos normales se pueden falsificar si se usa TKIP o GCMP, un atacante no puede forjar mensajes de enlace y, por lo tanto, no puede suplantar al cliente o AP durante los protocolos de enlace. Por lo tanto, las propiedades que se probaron en el análisis formal del protocolo de enlace de 4 vías siguen siendo verdaderas. Sin embargo, el problema es que las pruebas no modelan la instalación de la clave. Dicho de otra manera, los modelos formales no definían cuándo debía instalarse una clave negociada. En la práctica, esto significa que la misma clave se puede instalar varias veces, restableciendo así los contadores de no repetición y repetición utilizados por el protocolo de cifrado (por ejemplo, mediante WPA-TKIP o AES-CCMP).

¿La gente está explotando esto en la naturaleza?

No estamos en condiciones de determinar si esta vulnerabilidad ha sido (o está siendo) explotada activamente en la naturaleza. Dicho esto, las reinstalaciones clave pueden ocurrir espontáneamente sin que haya un adversario presente. Esto puede suceder, por ejemplo, si se pierde el último mensaje de un protocolo de enlace, lo que provoca una retransmisión del mensaje anterior. Al procesar este mensaje retransmitido, las claves pueden volver a instalarse, lo que da como resultado la reutilización del nonce como en un ataque real.

¿Debo usar temporalmente WEP hasta que mis dispositivos estén parcheados?

¡NO! Siga usando WPA2.

¿Se actualizará el estándar Wi-Fi para abordar esto?

Parece que hay un acuerdo de que el estándar Wi-Fi debe actualizarse para evitar explícitamente nuestros ataques. Es probable que estas actualizaciones sean compatibles con versiones anteriores con implementaciones anteriores de WPA2. El tiempo dirá si y cómo se actualizará el estándar.

¿La Alianza Wi-Fi también aborda estas vulnerabilidades?

Para aquellos que no están familiarizados con Wi-Fi, Wi-Fi Alliance es una organización que certifica que los dispositivos Wi-Fi cumplen con ciertos estándares de interoperabilidad. Entre otras cosas, esto garantiza que los productos Wi-Fi de diferentes proveedores funcionen bien juntos.

Wi-Fi Alliance tiene un plan para ayudar a remediar las vulnerabilidades descubiertas en WPA2. Resumiendo, ellos:

 1. Exigir pruebas para esta vulnerabilidad dentro de su red de laboratorio de certificación global.
 2.  Proporcione una herramienta de detección de vulnerabilidades para usar por cualquier miembro de Wi-Fi Alliance (esta herramienta se basa en mi propia herramienta de detección que determina si un dispositivo es vulnerable a algunos de los ataques de reinstalación de llaves descubiertos).
 3. Comunique ampliamente los detalles sobre esta vulnerabilidad, incluidos los remedios, a los proveedores de dispositivos. Además, se recomienda a los vendedores que trabajen con sus proveedores de soluciones para integrar rápidamente los parches necesarios.
 4. Comunique la importancia de que los usuarios se aseguren de que han instalado las últimas actualizaciones de seguridad recomendadas por los fabricantes de dispositivos.

¿Por qué utilizaste match.com como ejemplo en el video de demostración?

Los usuarios comparten mucha información personal en sitios web como match.com. Por lo tanto, este ejemplo resalta toda la información sensible que un atacante puede obtener, y es de esperar que con este ejemplo las personas también se den cuenta mejor del impacto potencial (personal). También esperamos que este ejemplo haga que las personas conozcan toda la información que estos sitios web de citas pueden recopilar.

¿Cómo se pueden prevenir estos tipos de errores?

Necesitamos más inspecciones rigurosas de implementaciones de protocolos. ¡Esto requiere ayuda e investigación adicional de la comunidad académica! Junto con otros investigadores, esperamos organizar talleres para mejorar y verificar la corrección de las implementaciones del protocolo de seguridad.

¿Por qué el nombre de dominio krackattacks.com?

En primer lugar, soy consciente de que los ataques KRACK son pleonasmos, ya que KRACK significa una instalación rápida y, por lo tanto, ya contiene la palabra ataque. Pero el nombre de dominio rima, por eso se usa.

¿Recibió recompensas de errores por esto?

Aún no he solicitado ninguna recompensa por errores, ni he recibido ninguna.

¿Cómo se compara este ataque con otros ataques contra WPA2?

Este es el primer ataque contra el protocolo WPA2 que no se basa en adivinar la contraseña. De hecho, otros ataques contra la red habilitada para WPA2 están en contra de las tecnologías circundantes, tales como Wi-Fi Protected Setup (WPS), o son ataques contra estándares más antiguos como WPA-TKIP. Dicho de otra manera, ninguno de los ataques existentes estaba en contra del protocolo de enlace de 4 vías o en contra de los paquetes de cifrado definidos en el protocolo WPA2. En contraste, nuestro ataque de reinstalación clave contra el protocolo de enlace de 4 vías (y contra otros protocolos de enlace) resalta las vulnerabilidades en el protocolo WPA2.

¿Otros protocolos también se ven afectados por los ataques de reinstalación de claves?

Esperamos que ciertas implementaciones de otros protocolos sean vulnerables a ataques similares. Por lo tanto, es una buena idea auditar las implementaciones del protocolo de seguridad con este ataque en mente. Sin embargo, consideramos que es improbable que otros estándares de protocolo se vean afectados por ataques similares (o al menos así lo esperamos). Sin embargo, ¡todavía es una buena idea auditar otros protocolos!

¿Hay una versión de mayor resolución del logotipo?

Si hay ¡Y muchas gracias a la persona que hizo el logo!

¿Cuándo notificó por primera vez a los proveedores sobre la vulnerabilidad?

Enviamos notificaciones a proveedores cuyos productos probamos a nosotros mismos alrededor del 14 de julio de 2017. Después de comunicarnos con estos proveedores, nos dimos cuenta de cuán generalizadas son las debilidades que descubrimos (solo entonces realmente me convencí a mí mismo de que era de hecho una debilidad del protocolo y no un conjunto de Errores de implementación). En ese momento, decidimos dejar que CERT/CC ayudara con la divulgación de las vulnerabilidades. A su vez, el CERT/CC envió una amplia notificación a los vendedores el 28 de agosto de 2017.

¿Por qué OpenBSD lanzó silenciosamente un parche antes del embargo?

OpenBSD fue notificado de la vulnerabilidad el 15 de julio de 2017, antes de que CERT/CC estuviera involucrado en la coordinación. Muy rápidamente, Theo de Raadt respondió y criticó la fecha límite de divulgación tentativa: "En el mundo de código abierto, si una persona escribe un diff y tiene que sentarse durante un mes, eso es muy desalentador" . Tenga en cuenta que escribí e incluyé un diff sugerido para OpenBSD ya, y que en ese momento la fecha límite de divulgación tentativa era hacia fines de agosto. Cómo compromiso, les permití parchear en silencio la vulnerabilidad. En retrospectiva, esta fue una mala decisión, ya que otros podrían redescubrir la vulnerabilidad mediante la inspección de su parche silencioso. Para evitar este problema en el futuro, OpenBSD ahora recibirá notificaciones de vulnerabilidad más cerca del final de un embargo.

¿Entonces esperas encontrar otras vulnerabilidades de Wi-Fi?

"Creo que recién estamos comenzando". - Master Chief, Halo 1

Recomendaciones de Security Hack Labs.

1. Si es posible, deshabilite su conexión mediante Wi-Fi hasta que se encuentre una solución al problema.
2. Use datos móviles en su celular en lugar de Wi-Fi.
3. Implemente la seguridad en su red haciendo uso de software cómo DNSCrypt, I2P, TOR y VPNs.
4. Mantenga actualizado diariamente el software de su computadora, móvil y router.

Esperamos que esta publicación haya sido de utilidad, cualquier inquietud o sugerencia dejarla en los comentarios en bien, en los medios que indicamos a continuación.
Síguenos en Facebook, Twitter, unete a nuestra charla en Riot (Para charlar con nosotros online) o únete a Telegram.

Fuentes: https://www.krackattacks.com/