Marzo 7th, 2008
De entre todas las utilidades que nos encontramos en el kit aircrack-ng el aireplay-ng es quizá la más complicada de comprender debido a sus múltiples funcionalidades. Con este post pretendo arrojar un poco de luz sobre los modos de uso de esta potente herramienta, se trata de una discusión conceptual, así que no espéreis encontrar un montón de comandos, mi objetivo en este caso es explicar lo que puede y no puede hacer el aireplay-ng.
Para entrar en situación recordemos que el kit aircrack-ng nos trae, entre otras cosas, tres utilidades importantes:
* airodump-ng -> Para capturar datos
* aircrack-ng -> Para encontrar la clave wep en los datos capturados por el airdoump
* aireplay-ng -> Para aumentar la cantidad de tráfico, ya que se necesitan un número mínimo de paquetes para que el ataque tenga éxito.
También sabéis que no todos los paquetes capturados nos valen, sólo aquellos que tengan un IV (vector de inicialización) con información útil. Estos paquetes no son tan frecuentes como desaríamos y es ahí en dónde entra en juego el aireplay-ng.
Vamos por partes, normalmente cuando la cantidad de tráfico capturado es poca pero no nula, para acelerar el proceso de captura de datos se suele usar el modo –arpreplay (-3). En este modo se capturan los paquetes ARP lanzados por un cliente legítimo y se vuelven a inyectar en la red esperando que el punto de acceso nos responda con tramas cuyos IV sean diferentes a los que ya tenemos. Es sin duda el método estándar. Una variación del mismo es el modo –interactive (-2), que hace exactamente lo mismo pero permite elegir al usuario que paquete reinyectar.
Otro método muy útil para cuando existen clientes legítimos conectados es el –deauth (-0). Esto desconecta de la wifi a los clientes legítimos, forzándolos a iniciar de nuevo el proceso de autenticación que es en donde más tramas útiles se capturan. La combinación de este método con el anterior (–arpreplay) suele ser la más efectiva.
Sin embargo, para llevar a cabo este ataque es necesario que nuestro equipo esté asociado a la wifi víctima, ya que si no la inyección de paquetes no será posible (el punto de acceso rechazará cualquier conexión de un equipo que no se haya asociado previamente). Ahí es donde entra en juego el modo –fakeauth (-1). Usándolo podemos conectar un cliente falso a la red wifi y luego reinyectar los paquetes ARP que hayamos capturado. Normalmente los drivers de las tarjetas wifi no nos permiten hacer este tipo de inyección, así pues, la mayoría de las veces tendremos que recurrir a drivers no oficiales para lograr nuestro objetivo.
Por último sólo me queda comentar los modos –chopchop (-4) y –fragment (-5). Estos modos avanzados que en principio no son útiles para romper claves wep, nos pueden permitir crear paquetes especiales que luego podemos usar para forzar que el punto de acceso genere paquetes útiles para nuestros fines. Estos métodos nos son útiles cuando no existen clientes legítimos conectados a la red.
Pues espero que esto ayude a aclarar un poco lo que puede hacer el aireplay-ng. En el próximo artículo le daremos un uso práctico 
Categorías: seguridad |
9 comentarios
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 |
2 comentarios
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 |
12 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 |
4 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
