Febrero 25th, 2008
Todos habréis oído que las claves WEP que Teléfonica coloca a sus routers no son totalmente arbitrarias. Hace tiempo que pensaba escribir un artículo sobre el tema y cómo conseguir de forma sencilla acceso a las redes así protegidas. Pues bien, ya no lo voy a escribir. El otro día me encontré con un blogger que se me había adelantado… quizás cuando tenga un rato libre haga una revisión de su artículo, hay cosas que creo se podrían mejorar en el método que él expone, pero sin duda lo encontraréis interesante: Romper claves wep de teléfonica
Categorías: interesante, seguridad |
2 comentarios
Febrero 12th, 2008
Para inaugurar la sección de Tipos&Tricks explicaré que son los tuneles SSH y cómo realizarlos.
Bien, imaginemos una situación como la que ilustra el siguiente esquema. Tenemos una máquina cliente que tiene acceso a un servidor SSH remoto. Ese servidor es la puerta de entrada a una red interna y la única máquina de dicha red que puede ser accedida desde internet. Nuestro equipo cliente desea acceder a una aplicación web situada en el servidor web local de la red interna.
La solución clásica al problema sería redireccionar el puerto 80 (web) desde el equipo SSH al servdidor web, lo que haría que ese servicio esté disponible desde Internet. Sin embargo, en esta ocasión no queremos que ese servidor sea accedido desde fuera, ya que es una aplicación dirigida a empleados de la empresa y no es deseable que sea consultada por terceros.
Pues bien, para casos como este y otros similares la solución está en los tuneles SSH. Mediante este mecanismo podemos pedir a un servidor SSH remoto que establezca una conexión entre nuestro equipo cliente y un servicio al que él tenga acceso. Para el caso concreto que hemos descrito, tendríamos que pedir al servidor SSH que nos abriera una conexión entre nuestro equipo y el servicio Web del servidor web interno. Lo que se haría con el siguiente comando:
$ ssh -L 9080:ip.privada.servidor.web:80 usuario@servidor.ssh
Este comando abre una sesión SSH con el host ‘servdior.ssh‘ como usuario ‘usuario‘ (tras poner correctamente la contraseña de inicio de sesión, por supuesto). Simultáneamente, crea un tunel SSH entre el puerto local 9080 y el servicio web remoto que se encuentra en el servidor web de la red privada. A partir de este momento bastará poner en el navegador del equipo cliente la dirección ‘http://localhost:9080/‘ para acceder al servidor remoto, ya que gracias al tunel que hemos creado todo lo enviado por ese puerto llegará hasta esa máquina inalcanzable de manera directa desde Internet.
Este concepto se puede aplicar de muchas maneras posibles y en muy diversas situaciones, y también hay otras opciones adicionales para crear los tuneles, pero no quiero convertir el post en un listado de comandos. Mi intención es que sirva de partida para que exploreis las posibilidades de este mecanismo.
Categorías: Tips&Tricks |
1 comentario
Febrero 11th, 2008
Tengo el blog un poco descuidado y os voy a contar por qué. Podría caer en la tentación de decir que me falta tiempo, lo que es en parte cierto. Mi tiempo libre no es mucho, pero cuando lo tengo no me apetece demasiado ponerme a escribir uno de esos artículos que tengo en la lista de pendientes. Y eso es porque son artículos largos y laboriosos, entre ellos se encuentra un howto sobre cómo realizar ataques de DNS Spoofing a nivel local y una revisión del artículo sobre como romper claves WEP, he recibido algunos comentarios acerca de este último y parece que necesita un enfoque más simple y práctico.
Así que visto lo visto, y cómo no sé cuando tendré tiempo y ganas para escribir esos artículos, he decidio crear una sección llamada Tips & Tricks en donde comentaré (de manera breve) diferentes utilidades, métodos o formas de hacer las cosas que he ido descubriendo a lo largo de estos años y que creo que pueden ser de interés para todos. Posiblemente muchas de ellas ya las conozcáis, pero la idea es crear una recopilación de trucos que nos faciliten o ayuden en nuestro trabajo.
Si tenéis algún truco que queráis compartir, dejad un comentario en este post.
Categorías: Tips&Tricks |
No hay comentarios
Febrero 2nd, 2008
Me alegra anunciar que después de infinidad de papeleo y tiempos de espera, por fin ha salido a la luz el libro que escribí junto a José A. Muñoz: Seguridad de Sistemas en Red. Un libro técnico en el que hemos hecho un largo recorrido a través de las diferentes formas en las que se puede vulnerar un sistema conectado en una red TCP/IP y las contramedidas necesarias para evitar tales ataques. Aunque es un libro en el que se describe de forma teórica los ataques y sus fundamentos (así como las defensas a los mismos), siempre hemos intentando darle un enfoque más práctico añadiendo ejemplos y referencia a utilidades que permitan al lector comprobar por si mismo la fuerza demoledora de tales ataques, así como la efectividad de los mecanismos defensivos que tenemos a nuestra disposición.
De momento el libro no se puede encontrar en librerías, pero me han comunicado que en breve estará disponible en la tienda de la ULPGC. Mi intención inicial era liberar una publicación electrónica a la vez que la publicación impresa, sin embargo, el contrato que he firmado me impide liberar el documento en la red hasta dentro de unos años.
Os dejo el índice del documento, la numeración de las páginas no se corresponde con la de la obra publicada, sino con la del borrador que enviamos a maquetación.
Descargar Índice de Seguridad de Sistemas en Red
Categorías: interesante |
4 comentarios
Enero 25th, 2008
Todos alguna vez nos hemos (o nos han) preguntado: ¿Por qué la batería me dura más en Windows que en Linux? Pues simplemente porque los fabricantes de portátiles se encargan de hacer buenos programas para gestionar la energía bajo Windows. Estas pequeñas joyas que cada compañía hace a medida para su equipo, son capaces de controlar y desactivar todo aquello que no se usa, suspenden el bluetooth, ponen el wifi en modo ahorro, bajan el brillo a medida que se consume la batería, suspenden la energía de los puertos usb que no se están usando, etc, etc. En conjunto todas estos pequeños ahorros de energía producen un ahorro significativo que expande considerablemente la duración de la batería.
En Linux hemos ido siempre un paso por detrás en este sentido, es cierto que existen algunos programas que son capaces de reaccionar a ciertos eventos ACPI, haciendo, por ejemplo, que el portátil se comporte de manera diferente según la batería que nos quede. Pero nunca habíamos tenido una herramienta que nos permitiera identificar con claridad los ‘agujeros negros’ de nuestro equipo, es decir, esos procesos que consumen más de lo que estamos dispuestos a permitir o esas carencias de configuración que hacen que el portátil gaste energía en algo que es innecesario.
Pero estamos de enhorabuena, Intel ha desarrollado y liberado una pequeña herramienta que nos permitirá identificar cuales son los procesos que más energía consumen, además esta pequeña utilidad nos dará consejos sobre como configurar nuestro equipo para hacer un mejor uso de la batería, es más, muchas veces bastará pulsar una tecla para que la aplicación aplique el consejo (eso sí, para hacerlo persistente tendremos que crear un script que ejecute las medidas recomendadas durante el arranque del sistema).
La utilidad se llama PowerTop y si tienes un portátil Intel ya deberías estarla usando (si usas una distribución Debian o similar también puedes descargarla vía apt-get).
Categorías: interesante, linux |
11 comentarios
Enero 14th, 2008
Hoy estaba revisando algunos logs y pensé: ojalá pudiera resaltar con colores algunos patrones, me ayudaría mucho. Por supuesto, la primera idea que se me vino a la cabeza fue usar el grep:
# grep –colour PATRON /var/log/messages
Pero el grep elimina todas las líneas que no contienen el patrón y eso tampoco me interesaba. Busqué en la web un rato y encontré varias utilidades que coloreaban ficheros de logs completos, pero tampoco era lo que quería.
Lo que necesitaba era una utilidad que me resaltara sólo ciertos patrones y que me devolviera el contenido íntegro del fichero de logs. Eso sí que estaría bien. Y diría que hace tiempo me encontré con una utilidad que hacía exactamente eso… pero como no daba con ella y tampoco quería pasarme toda la mañana buscándola, escribí un pequeño script en perl que hacía todo lo que yo necesitaba. No soporta expresiones regulares (de momento) pero es suficiente para lo que yo lo quiero. Os pongo un par de ejemplos de uso:
1. Si lo ejecutamos sin parámetros nos sale una ayuda muy cutre. Básicamente nos dice que necesita al menos un patrón que colorear. El script sólo admite cuatro patrones como máximo (pero es muy sencillo modificarlo para que admita más). Cada patrón será resaltado con un color distinto.
# highlight
ERROR: Necesito al menos un patrón que sobresaltar
Uso: /usr/local/bin/highlight patron [patron2] [patron3] [patron4]
2. Coloreamos el log del iptables para que resalte los patrones ‘SPT=’, ‘DPT=’ y ‘Output’.
# cat iptables.log | highlight SPT= DPT= Output
3. Similar al anterior pero usanto un tail:
# tail -f iptables.log | highlight Input SPT= DPT= src= DST=
Descargar Highlight Script
Categorías: descargas, interesante, linux |
No hay comentarios
Enero 11th, 2008
Esta semana he visto como un importante número de sistemas eran comprometidos de manera sistemática por no haber sido parcheados en su momento. Este tipo de ataques suelen ser realizados por scripts que operan de manera autónoma, comprometen el sistema usando algún bug no parcheado, instalan alguna puerta trasera para permitir su acceso posterior y algún bot que comprometa otras máquinas usando la actual. Nada complicado, ni siquiera se preocupan por conseguir privelegios de administrador. Pero eso no importa, la máquina está comprometida y en cualquier momento el atacante puede acceder a ella para intentar elevar sus privilegios. Por otra parte, nuestra máquina infectada podría estar siendo usada para comprometer otras, lo que ya en sí es un problema importante.
Huelga decir que lo ideal sería tener siempre nuestro sistema actualizado y parcheado, pero me temo que es casi una utopía. En el día a día las cosas no funcionan así, no hay un departamente encargado de la seguridad de los sistemas y habitualmente los administradores tienen tantas cosas que hacer que en lo último que piensan es aplicar un parche a un servicio que funciona perfectamente.
Así pues se hace necesario añadir una nueva capa de seguridad, que aunque no elimina la necesidad de parchear nuestros sistemas cuando es descubierto un nuevo bug, sí que minimiza el impacto de un posible compromiso. Me estoy refieriendo a los cortafuegos. Si nuestra máquina está protegida por un cortafuegos correctamente configurado, éste debería impedir el acceso a nuevos puertos abiertos (puertas trasearas) y además debería cortar cualquier conexión saliente hacia hosts/servicios no permitidos (bot malicioso).
No voy a hablar de arquitecturas de red, de DMZs, ni de la mejor manera de organizar nuestras redes para que sean lo más segura posibles. Y no voy a hablar de esto porque nuestras redes ya están montadas y por mucho que yo os diga no se van a cambiar. Si por el contrario estáis pensando en diseñar vuestra red, hacedme caso e incluid una DMZ, ya me lo agradeceréis.
Bueno, a lo que iba, si tenéis algún servidor con presencia en Internet y no está dentro de una DMZ, lo mejor es protegerlo con un pequeño cortafuegos que sólo permita el acceso a los servicios legítimos y que, además, impida cualquier conexión saliente ilegítima. He escrito un pequeño script IPTables a modo de plantilla (muy sencillo) que os invito a modificar y adaptar a vuestras necesidades. No se trata de un script para servidores que operen como enrutadores, si no para servidores finales que ofrezcan servicios de usuario; y por supuesto, no es un firewall personal, es demasiado restrictivo para eso.
En fin, espero que os sea tan útil como a mí.
Descargar Plantailla IPTables
Categorías: descargas, linux, seguridad |
No hay comentarios
Enero 5th, 2008
El año nuevo me trajo un bonito regalo: una máquina comprometida. Me pidieron lo que se suele pedir en estos casos, buscar como lograron acceso y que medidas tomar para evitar intrusiones futuras. La máquina en cuestión ofrecía servicios de webhosting y no podía desconectarse bajo ningún concepto, tampoco existía una máquina de respaldo para casos como estos. Las copias de seguridad se hacían rigurosamente, pero no es suficiente en esta situación, es necesario que exista una máquina de respaldo lista para entrar en funcionamiento con la última copia de seguridad limpia.
Pero esto es lo que te enseña la experiencia, las cosas no son como dicen en los manuales… ahí estaba mi máquina con signos evidentes de compromiso y yo no podía desconectarla para analizarla con calma. Tampoco podía obtener un volcado del disco para su posterior análisis, se trataba de una máquina remota y, además, la carga adicional del volcado a un medio externo afectaría notablemente al desempeño del sistema.
Bueno, hay que jugar la mano con las cartas que te tocan, así que me puse manos a la obra. Tras un primer vistazo al sistema descubrí un bouncer y varias instancias del eggdrop campando a sus anchas, además todo ejecutado por el usuario ‘www-data’. Aquello olía a script kiddie. Era evidente que la máquina había sido comprometido por el fallo de algún CMS, pero en aquel momento sentía más curiosidad por la personalidad del atacante que por el fallo que le permitió entrar. Escribí unas cuantas reglas IPTables para asegurar mínimamente la máquina y fui a la caza del intruso. Tras tracearle un poco la pista lo encontré en un IRC dejado de la mano de Dios, estaba en un canal rodeado de todos sus eggdrops. Os aseguro que había muchos y cada uno de ellos era señal inequívoca de que una máquina había sido comprometida en algún lado. El servidor IRC no ocultaba la IP, así que tenía todas las direcciones de todas las máquinas comprometidas, supongo que debería haber notificado a los afectados… pero lo que hice fue hablar con mi pequeño intruso. Era un chaval chino con ganas de impresionar a sus amigos y obtener privilegios de operador en algún canal hacker. Estaba conectado a través de un bouncer, así que localizar su IP real me iba a costar mucho trabajo y tiempo… y tediosas negociaciones con administradores negligentes.
Ya conocía al intruso, así que volví a la máquina. Primero había que ver el alcance del ataque. No había indicios de que hubiera conseguido privilegios de root, aunque claro, siendo root nada te impide borrar tus huellas. De todas formas no parecía probable (y sin desconectar la máquina no podía hacer análisis más concienzudos). Había varios bouncers instalados en el sistema, por su fecha y ubicación era más que posible que fueran creados por distintos scripts, así pues podríamos estar hablando de varias webs vulnerables. Eliminé bouncers, eggdrops y una bonita puerta trasera colocada en el cron y fui a por el fallo que permitió entrar al intruso. Identifiqué varias vulnerabilidades que presentaba el sistema y estudié con detenimiento los logs del servidor web. Vi muchos rastreos automáticos de bots bien conocidos y alguno que otro sin precedentes, no me extrañaba nada que la máquina hubiera sido comprometida. Lo que me sigue extrañando es no haber encontrado más malware.
Informé sobre los problemas y di por acabado el trabajo. Pero aún tengo al sistema bajo vigilancia, estoy seguro de que en esa máquina hay más de lo que veo (también es posible que esté paranoico, esa es una de las consecuencias de este trabajo).
Para acabar un dilema, debería lanzarme en una cruzada contra el chaval que ejecutó el bot o debería dejarlo pasar sin una colleja… ninguna de las dos opciones me parece adecuada, pero haré lo que se suele hacer en estos casos (así va el mundo), tomaré la alternativa fácil… lo dejaré pasar.
Felices Fiestas
Categorías: interesante, reflexiones |
3 comentarios
Diciembre 28th, 2007
Hace unos días tuve la desgracia de presenciar como unos datos de importante valor eran sobreescritos por una mala copia de seguridad, perdiéndose para siempre. Esto me llevó a investigar sobre como recuperar la información y lo cierto es que en un sistema de archivos EXT3 esto es una tarea bastante complicada.
Para los sistemas EXT2 existían varias utilidades capaces de recuperar la información (debugfs era una bastante buena), sin embargo, la forma de trabajar de los sitemas EXT3 (rellena con ceros el puntero hacia el archivo borrado) hace que este tipo de utilidades sean inservibles.
Una vez borrado un archivo la información sigue estando ahí, el problema es que no hay forma de localizarla, no podemos saber donde está, ni como está repartida entre los bloques. Simplemente sabemos que sigue estando en alguna(s) parte(s) del disco duro. Esto es un problema mucho mayor de lo que pudiera parecer ya que no sabemos cuando empieza un fichero y acaba otro, o mucho peor, no podemos saber si el fichero está en un grupo de bloques consecutivos o no. Recuperar archivos binarios en estas condiciones es impensable, sin embargo, recuperar archivos de texto es algo un poco más factible. Quizás no podamos recuperar el archivo como tal, pero sí que podemos leer su contenido y ya que los archivos de texto no suelen ser demasiado grandes, es posible que todo esté contenido en el mismo bloque (es decir, no lo encontraríamos disperso por el disco duro).
La estrategia para conseguir esto es volcar todo el texto de la partición afectada en un fichero y luego examinarlo en busca de las partes que nos interesen. Esto lo podemos conseguir con strings:
# strings /dev/sda7 > /ruta/hacia/archivo
Es recomendable almacenar el volcado en una partición distinta a la que queramos recuperar, ya que si no corremos el riesgo de sobreescribir los datos que estamos intentando salvar antes de haberlos leído.
Espero que esto os sea útil, pero lo mejor es tener las copias de seguridad siempre actualizadas.
Categorías: interesante, linux |
4 comentarios
Diciembre 15th, 2007
Parece que todo el mundo sabe que las claves WEP son débiles y que pueden romperse con relativa facilidad, pero lo cierto es que pocos conocen por qué esto es posible y cómo hacerlo.
En mi afán por mostrar los senderos oscuros de las redes y sobre todo porque muchos me lo han pedido, aquí está el tutorial sobre cómo romper claves WEP para uso y disfrute del personal.
Antes que nada un poco de teoría, el protocolo de seguridad WEP trata de incorporar a las redes inalámbricas una seguridad equivalente a la que podemos encontrar en las redes cableadas, de ahí su nombre, Wired Equivalent Privacy (Privacidad Equivalente al Cable). Este protocolo permite cifrar las conexiones entre los clientes y el punto de acceso (AP), protegiendo así la confidencialidad e integridad de los datos.
El protocolo WEP requiere que las estaciones y el AP compartan una clave secreta antes de comenzar la comunicación, éste es uno de sus grandes puntos flacos, hay que comunicar por otra vía la clave a los distintos clientes lo que genera una serie de problemas importantes, entre ellos cabe destacar lo costoso de cambiar la clave, hay que informar a todos los clientes de la nueva lo que, según el número de los mismos, puede que no sea una tarea trivial. Esto lleva a que las claves WEP se cambien con poca frecuencia.
Cuando una máquina quiere conectar con un punto de acceso que use WEP, ésta realiza una petición inicial de asociación al AP, el cual a su vez responde con un texto aleatorio (desafío). El cliente deberá cifrar dicho texto con su clave compartida y enviar la respuesta al AP. Éste descifrará el texto con su propia clave y la compara con la enviada, si son iguales, se le permite el acceso al cliente.
El algoritmo usado para cifrar la comunicación WEP es conocido como RC4. Ya sabemos que una parte de la clave usada en el algoritmo es la clave compartida, pero para impedir que un atacante puede recolectar datos suficientes para romper la clave, una parte de la misma es dinámica y cambia en cada trama. A esta parte se le llama IV (vector de inicialización) y según el estándar debe ser distinta para cada paquete enviado. Por lo tanto, la clave final usada para cifrar/descifrar es la concatenación del IV con la clave compartida. El IV siempre tiene un tamaño de 24bits, ese es el motivo de por qué la clave secreta deberá tener un tamaño de 40bits (en claves de 64bits) o de 104 (en claves de 128bits), aclaro esto porque más de una vez me he enfrentado a la discusión de por qué si la clave es de 128bits sólo se pueden escribir 13 caracteres (13*8=104) y no 16 (16*8=128) como sería de esperar.
El IV es sólo conocido por uno de los extremos, así que es necesario enviarlo sin cifrar al otro. Es decir, junto con los datos cifrado se envía el IV, así el otro extremo puede reconstruir la clave secreta a partir de la que iniciar el proceso de descifrado. Existen varias debilidades asociadas al IV que correctamente explotadas puedan llevar al compromiso de la clave WEP. No quiero seguirme entreteniendo en esto, pero para acabar diré que si se consiguen capturar los suficientes paquetes WEP es posible llevar a cabo un ataque que permitirá recuperar la clave compartida, para los que quieran ampliar información sobre el tema recomiendo el artículo Protocolo de seguridad Wep y si estáis interesado en el criptoanálisis del ataque, nada mejor que el documento liberado por los autores del descubrimiento: Weaknesses in the Key Scheduling Algorithm of RC4
Modo Monitor
Y ahora al tajo, vamos a reventar unas cuantas claves WEP. Para hacer esto es condición indispensable que vuestra tarjeta de red sea capaz de entrar en modo Monitor. Algunas tarjetas son incapaces de entrar en este modo y en otras es posible que no tengáis los controladores adecuados. En cualquier caso, lo primero es saber si la tarjeta puede entrar en modo monitor o no, para averiguarlo escribimos algo parecido a lo siguiente (mi tarjeta de red está en la interfaz eth2, cambiadlo según corresponda)
# iwconfig eth2 mode monitor
# iwconfig eth2
eth2 unassociated ESSID:”" Nickname:”none”
Mode:Monitor Frequency=2.437 GHz Access Point: 72:00:00:00:00:27
Bit Rate:0 kb/s Tx-Power:16 dBm
Retry limit:15 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:9273 Missed beacon:0
Si podéis leer Mode:Monitor en la respuesta al segundo comando, vuestros vecinos pueden ir empezando a temblar.
Método 1: AirSnort
A partir de este punto contamos con varias herramientas que nos permiten llevar a cabo el ataque hacia claves WEP. Si no os queréis complicar la vida, lo más fácil es usar AirSnort, una utilidad que cuenta con una bonita GUI y que nos basta con darle a comenzar para que ella solita haga todo el trabajo. Eso sí, hay que tener paciencia pues para romper una clave hacen falta capturar entre 4,000,000 y 6,000,000 paquetes de datos.
Método 2: aircrack-ng
Para los que queráis esperar un poco menos y nos os importe prescindir de las interfaces gráficas, tenéis el kit aircrack-ng. Éste añade varias mejoras al ataque clásico (FMS) y permite recuperar la clave capturando entre 500,000 y 2,000,000 paquetes de datos. Además incluye una maravillosa utilidad llamada aireplay-ng que permite inyectar tráfico en la red wifi con el objetivo de que se generan más paquetes de datos y así obtener antes la clave, esto es ideal cuando estamos ante una red con poco tráfico.
Veamos como usar el aircrack-ng:
1. Lo primero es capturar todo el tráfico de la red:
# airodump-ng -w datos eth2
airdodump-ng cuenta con muchas opciones entre las que cabe destacar –channel, que nos permite capturar sólo los datos que se emitan por un canal determinado. Recomiendo usarla siempre que podamos.
Lo siguiente es poner el aireplay-ng a funcionar para generar más tráfico de red. Esta utilidad tiene varios modos de ataque y la verdad es que necesitaría otro post para hablar de todas las posibilidades que tiene. En principio voy a comentar un ataque muy efectivo y quizás otro día hable de sus multiples capacidades. El ataque que vamos a usar se llama ARP Injection, y consiste simplemente en enviar peticiones ARP al AP con el objetivo de que responda con nuevos paquetes de datos. Para esto es necesario conocer la MAC de un cliente ya conectado, pues lo que se hace este ataque es reenviar peticiones ARP capturadas con anterioridad a dicho cliente (obviamente el ataque fallará si no hay clientes conectados, aunque aireplay-ng también presenta soluciones a este problema, pero ya hablaremos de eso en otro momento).
# aireplay-ng –arpreplay -b 00:13:F7:64:10:27 -h 00:A0:C5:53:7F:9F -r datos-01.cap eth2
–arpreplay es el ataque de inyección de arp
-b es el BSSID del AP
-h es la MAC del cliente autenticado
-r es el fichero de datos que estamos capturando con el airodump-ng
Y ya por último sólo queda poner a funcionar el aircrack-ng, que será el que trate de encontrar la clave WEP:
# aircrack-ng datos-01.cap
Método 3: aircrack-ptw
Y cómo suele pasar con estas cosas, lo más importante es tener paciencia y suerte. Pero si la paciencia no es mucha, estáis de enhorabuena porque han descubierto nuevos sistemas para atacar las claves WEP, reduciendo el número de paquetes necesarios para recuperla a menos de 80000. Os dejo la url de los autores, la utilidad se llama aircrack-pwt y funciona de forma similar al aircrack-ng, de hecho necesitareis el kit aircrack-ng para realizar el ataque completo.
Pues no os quejaréis, ya sabéis todo lo que necesitáis saber… a disfrutar!
Categorías: seguridad, tutoriales |
2 comentarios
