Tesis Blanco y Cattafesta

Universidad Nacional del Centro
Facultad de Ciencias Exactas
TRABAJO FINAL DE GRADO

PARA LA CARRERA DE
INGENIERÍA DE SISTEMAS
EVALUACIÓN INTEGRAL DE SEGURIDAD INFORMÁTICA DEL CENTRO

DE DATOS Y COMUNICACIONES
Autores: Blanco, Damián – Cattafesta, Matías Francisco

Directores: Bradaschia Martín Eduardo, Aciti Claudio
Agradecimientos
Queremos agradecer a todos los que nos han acompañado en este largo camino que
hemos recorrido. Sería imposible nombrarlos uno a uno. Familiares, parejas y amigos,
fueron el motor que nos impulsó a mantener la constancia, el esfuerzo y la dedicación, sobre
todo en aquellos momentos en que el horizonte parecía tan lejano. Hoy, con el objetivo
cumplido, no solo les agradecemos, sino que estamos inmensamente felices de poder
compartir con ellos el fin de esta gran etapa de nuestras vidas y queremos invitarlos a seguir
formando parte de los nuevos caminos que nos toque transitar de aquí en adelante.
2
Indice General
1. Introducción 11
1.1. Motivación 15
1.2. Objetivos 15
2. Estado del Arte 17

2.1. Ingeniería Social 17
2.2. Seguridad Física y Biométrica 19
2.3. Criptografía 19
2.4. Informática Forense 20
2.5. Auditorías de Seguridad 21
2.6. Test de Intrusión 25
2.7. Vulnerabilidades y Tipos de Ataque 29
2.8. Herramientas 31
2.8.1. Sistemas Operativos 31
2.8.2. Aplicaciones 33
3. Descripción del problema 37
4. Configuración del Entorno 39

4.1. Red Privada Virtual 39
4.2. Sistema Operativo 41
5. Metodología del Test de Intrusión 43

5.1. Establecimiento de alcance y reglas de juego 43
5.2. Recolección de información 44
5.3. Análisis de vulnerabilidades 45
5.4. Explotación de vulnerabilidades 45
5.5. Post explotación del sistema 46
5.6. Generación de informes 47
6. Fase 1: Establecimiento de alcance y reglas de juego 49
7. Fase 2: Recolección de Información 50

7.1. Objetivos principales 50
7.2. Footprinting Externo 51
7.2.1. Footprinting Externo Pasivo 51
7.2.1.1. Whois 52
7.2.1.1.1. Introducción 52
7.2.1.1.2. Ejecución 52
7.2.1.2. Google Hacking 55
7.2.1.2.2. Ejecución 57
7.2.1.3. Robtex 63
3
7.2.1.3.2. Ejecución 63
7.2.1.4. SHODAN 67
7.2.1.4.2. Ejecución 67
7.2.1.5. Maltego 70
7.2.1.5.2. Ejecución 70
7.2.2. Footprinting Externo Activo 73
7.2.2.1. Netcat 73
7.2.2.1.2. Ejecución 73
7.2.2.2. Whatweb 74
7.2.2.2.2. Ejecución 74
7.2.2.3. BlindElephant 76
7.2.2.3.2. Ejecución 76
7.3. Footprinting Interno 77
7.3.1. Footprinting Interno Activo 77
7.3.1.1. Nmap 77
7.3.1.1.2. Ejecución 77
7.4. Resumen 83
8. Fase 3: Análisis de vulnerabilidades 86

8.1. Herramientas 86
8.2. Vulnerabilidades de desbordamiento de buffer 100
8.2.1. MS06-040: Vulnerabilidad en servicio del servidor permite ejecución de código
remoto 100
8.2.2. Apache 2.2.x < 2.2.15 Múltiples Vulnerabilidades 101
8.2.3. MS03-026: Saturación de buffer de la interfaz Microsoft RPC 104
8.2.4. MS03-039: Saturación de buffer de la interfaz Microsoft RPC 105
8.2.5. MS08-067: Vulnerabilidad en Microsoft Windows Server Service RPC 107
8.2.6. MS06-035: Vulnerabilidad en el Servidor puede permitir la ejecución de código
remoto 108
8.3. Vulnerabilidades de error de formato de cadena 110
8.3.1. MS04-007: Vulnerabilidad de biblioteca ASN.1 110
8.3.2. Servicio SMTP STARTTLS Inyección de comandos de texto sin formato 111
8.4. Vulnerabilidades de Cross Site Scripting 113
8.4.1. Apache HTTP Server: Página de error 403 UTF-7 Encoded XSS 113
8.4.2. Métodos HTTP TRACE / TRACK Permitidos 114
8.4.2.1. Método de solicitud TRACE (RASTREO) 114
8.4.2.2. Opción httpOnly en Cookie 115
4
8.4.3. Servidor HTTP Apache Cookie httpOnly: Divulgación de Información 118
8.5. Vulnerabilidades de denegación del servicio 119
8.5.1. MS09-001: Vulnerabilidad de ejecución de código remoto de Microsoft
Windows SMB 119
8.5.2. MS12-020: Ejecución de código remoto permitida 120
8.5.3. Servidor HTTP Apache Rango de Bytes DoS 123
8.5.4. Vulnerabilidad de Badlock de Samba 124
8.6. Vulnerabilidades de divulgación de la información 127
8.6.1. Divulgación de información de transferencia de zona de servidor DNS (AXFR)
127
8.6.2. POP3: Permite inicio de sesión con texto plano 129
8.6.3. PostgreSQL Cuenta por defecto sin contraseña 132
8.6.4. Detección de páginas de ejemplo de XAMPP 134
8.6.5. Servicio SMTP permite logueo con texto plano 135
8.6.6. Servidor Web: detección de Proxy Inverso 136
8.6.7. Apache Multiviews: Lista arbitraria de directorios 138
8.6.8. Recuperación remota de información del caché del servidor DNS 140
8.6.9. Microsoft Windows SMB Autenticación de Sesión NULL 142
8.6.10. AMQP Autenticación Texto Plano 145
8.7. Vulnerabilidades de versiones deprecadas 146
8.7.1. Detección de versión de sistema operativo Unix sin soporte 146
8.8. Vulnerabilidades del día 0 149
8.8.1. MS17-010: Actualización de seguridad de Microsoft Windows SMB Server 149
8.8.2. Detección de gusano Conficker 152
8.9. Resumen 154
9. Fase 4: Explotación de las vulnerabilidades 157

9.1. Ataques de Inyección de Código 157
9.1.1. Ataque de Cross Site Scripting (XSS) 158
9.1.1.1. Tipo-0 (Basados en el DOM) 160
9.1.1.2. Tipo-1 (Reflejados) 162
9.1.1.3. Tipo-2 (Persistida) 162
9.1.1.4. Implementación de ataque de XSS Reflejado 164
9.1.2. Inyección de Código en servicio SMTP 168
9.2. Explotación sobre Base de Datos 173
9.3. Explotación de Server Message Block (SMB) 180
9.3.1. Autenticación con usuarios nulo y anónimo 180
9.3.2. Explotación vulnerabilidad MS17-010 182
9.4. Resumen 185
10. Fase 5: Post-Explotación 188
11. Conclusión 190
12. Trabajos Futuros 193

5
12.1. Propuesta número 1: Continuar explorando distintas técnicas y herramientas para
el test de intrusión 193
12.2. Propuesta número 2: Extender el test de intrusión existente a otras bandas
(direcciones Ip) dentro del Centro de Datos de la UNICEN 193
12.3. Propuesta número 3: Implementar un Sistema de Gestión de la Seguridad de la
Información (SGSI) para la Universidad 194
13. Bibliografía 195
14. Anexo 197
6
Índice de Figuras
Figura 2-1: Historial de metodologías de auditorías de seguridad 24
Figura 7-1: Respuesta del comando whois para la Ip 131.221.0.3 54
Figura 7-2: Ejecución de whois para la Ip 131.221.0.3 desde
http://whois.domaintools.com 55
Figura 7-3: Fragmento de respuesta del whois para la Ip 131.221.0.3
desde http://whois.domaintools.com 55
Figura 7-4: Fragmento de respuesta del whois para la Ip 131.221.0.3
desde http://whois.domaintools.com 56
Figura 7-5: Ejecución de whois para el dominio e-alternativas.edu.ar 56
Figura 7-6: Ejecución de whois para el dominio unicen.edu.ar 57
Figura 7-7: Directorio interno encontrado desde búsqueda en Google 60
Figura 7-8: Archivos privados encontrados desde búsqueda en Google 60
Figura 7-9: Directorio xgap perteneciente a unicen encontrados desde búsqueda en
Google 60
Figura 7-10: Directorio pipermail perteneciente a unicen encontrados desde búsqueda
en Google 61
Figura 7-11: Búsqueda dentro del dominino unicen.edu.ar para archivos pdf que
contengan la palabra “bradaschia” 61
Figura 7-12: Primer resultado de la búsqueda realizada en 7-11 62
Figura 7-13: Ruta bloqueada para accesos externos 63
Figura 7-14: Pdf con lista de usuarios perteneciente a la Secretaría de Administración 63
Figura 7-15: Información sobre listados de emails 64
Figura 7-16: JBoss log 64
Figura 7-17: Analisis de Robtex para unicen.edu.ar 66
Figura 7-18: Respuesta de Robtex con los host dentro del dominio unicen.edu.ar 66
Figura 7-19: Grafo de red generado por Robtex para el dominio unicen.edu.ar 67
Figura 7-20: Analisis de Robtex para rec.unicen.edu.ar 67
Figura 7-21: Respuesta de Robtex con los host dentro del dominio rec.unicen.edu.ar 68
Figura 7-22: Grafo de red generado por Robtex para el dominio unicen.edu.ar 68
Figura 7-23: Información genera de Shodanl sobre Ip 131.221.0.3 69
Figura 7-24: Información de Shodan sobre el puerto 21 de la Ip 131.221.0.3 70
Figura 7-27: Primera transformación de Maltego partiendo de www.unicen.edu.ar 73
Figura 7-28: NS Records encontrados por Maltego a partir del dominio unicen.edu.ar 73
Figura 7-29: Resultado obtenido luego de aplicar todas las transformaciones de los
NS Records con Maltego 74
Figura 7-30: Resultado obtenido luego de aplicar todas las transformaciones
de las direcciones Ip 131.221.1.0.1-2 con Maltego 74
Figura 7-31: Scan con la herramienta Netcat al puerto 80 del dominio perteneciente
a la UNICEN 76
Figura 7-32: Resultado de la herramienta Whatweb para el DNS www.unicen.edu.ar 77
Figura 7-33: Resultado de Blind Elephant para aplicaciones drupal en el
dominio www.unicen.edu.ar 78
Figura 7-34: Distribución de bandas Ip dentro del Centro de Datos y Comunicaciones 80
Figura 7-35: Distribución de bandas Ip dentro del Centro de Datos y Comunicaciones 80
Figura 7-36: Escaneo de nmap para la banda del Rectorado 81
7
Figura 7-37: Escaneo de nmap para la banda del Rectorado con volcado al
archivo scan_rectorado 82
Figura 7-38: Formateo de archivo generado en la figura 7-37, filtrado sólo los hosts
activos 83
Figura 7-39: Escaneo de nmap con detección de sistemas operativos 84
Figura 8-1: Opciones contenidas en la herramienta Nikto 89
Figura 8-2: Escaneo con la herramienta Nikto para el host 10.254.1.152 90
Figura 8-3: Versiones de descarga disponibles para la herramienta Nessus 91
Figura 8-4: Instrucción sobre cómo descargar Nessus desde la terminal de Kali Linux 92
Figura 8-5: Activación del daemon de Nessus 92
Figura 8-6: Creación de Usuario en Nessus 93
Figura 8-7: Ingreso del código de activación para Nessus 93
Figura 8-8: Configuración de escaneo en Nessus 94
Figura 8-9: Gráfico que contiene la cantidad de vulnerabilidades encontradas en el
escaneo de Nessus, clasificadas por niveles de criticidad 94
Figura 8-10: Reporte de vulnerabilidades de Nessus 95
Figura 8-11: Consulta sobre el estado del servicio postgresql seguido de su inicialización
96
Figura 8-12: Inicialización de la bases de datos de Metasploit 96
Figura 8-13: Ingreso a msfconsole (consola del framework Metasploit) 97
Figura 8-14: Volcado en la base de Metasploit mediante archivo xml de información
de hosts obtenidos con Nmap 98
Figura 8-15: Consulta a la base de Metasploit sobre la información de los host 98
Figura 8-16: Consulta a la base de Metasploit sobre la información de los servicios 99
Figura 8-17: Consulta a la base de Metasploit sobre la información de los servicios del
host 10.254.1.240 100
Figura 8-18: Consulta a la base de Metasploit sobre la información de los
servicios http 100
Figura 8-19: Volcado en la base de Metasploit sobre vulnerabilidades de hosts obtenidos
con la herramienta Nessus 101
Figura 8-20: Reporte de vulnerabilidades persistidas en la base de Metasploit 101
Figura 8-21: Consulta a la base de Metasploit sobre cantidad de vulnerabilidades en
host que utilicen Windows 101
Figura 8-22: Escaneo de Nmap para la Ip 10.254.1.18 103
Figura 8-23: Consulta de cabezados mediante cURL para la dirección 10.254.0.200 105
Figura 8-24: Consulta de cabezados mediante cURL para la dirección 10.254.0.130 106
Figura 8-25: Escaneo con detección de versiones mediante Nmap para el puerto
8080 del host 10.254.0.249 106
Figura 8-26: Ejecución del script de Nmap smb-os-discovery para el puerto 445
en la ip 10.254.1.18 107
Figura 8-27: Ejecución de script obtenido en https://www.exploit-db.com/exploits/97/ 108
Figura 8-28: Ejecución de script de Nmap, el cual verifica si la vulnerabilidad
ms08-067 existe en el puerto 445 de la dirección Ip 10.254.1.18 109
en la ip 10.254.1.18 y 10.254.1.152 111
Figura 8-30: Ejecución del script de Nmap smb-enum-shares para el puerto 445
en la ip 10.254.1.18 113
Figura 8-31: Inicio de conexión con protocolo TLS al puerto 25 de la Ip 10.254.0.160 114
8
Figura 8-32: Escaneo de versiones con Nmap al puerto 80 de las direcciones Ip
10.254.0.200 y 10.254.1.152 116
Figura 8-33: Llamada http con el método trace al host 10.254.0.160 mediante la
herramienta cURL 117
Figura 8-34: Ejecución del script de Nmap http-methods para la dirección ip
10.254.1.160 119
Figura 8-35: Llamada http con el método jeff al host 10.254.1.184 mediante la
herramienta cURL 119
Figura 8-36: Prueba realizada por la herramienta Nessus 121
Figura 8-37: Escaneo de versiones con Nmap al puerto 80 de la dirección Ip
10.254.1.18 122
Figura 8-38: Ejecución del script de Nmap rdp-vulns-ms12-020 para el puerto 3389
en la ip 10.254.0.133 124
10.254.1.18 126
10.254.1.251 127
10.254.1.251 128
Figura 8-42: Ejecución del script de Nmap dns-zone-transfer para el domino
unicen.edu.ar en la ip 10.254.0.3 130
Figura 8-43: Ejecución del script de Nmap dns-zone-transfer para el domino
unicen.edu.ar en la ip 10.254.0.5 131
Figura 8-44: Escaneo de versiones con Nmap a la dirección Ip 10.254.0.152 132
Figura 8-45: Ejecución del script de Nmap nfs-ls para la ip 10.254.0.32
(primer fragmento) 133
Figura 8-46: Ejecución del script de Nmap nfs-ls para la ip 10.254.0.32
(segundo fragmento) 133
Figura 8-47: Ejecución del script de Nmap nfs-showmount para la dirección Ip
10.254.0.32 134
Figura 8-48: Escaneo con Nmap a la dirección Ip 10.254.1.252 135
Figura 8-49: Fragmento de resultado de la figura 8-48 donde se presenta la
información sobre el servicio PostgreSQL 135
Figura 8-50: Página de ejemplo de XAMPP expuesta en el puerto 8080 de la
dirección Ip 10.254.0.249 136
Figura 8-51: Evidencia de implementación del método auth plain 137
Figura 8-52: Evidencia de implementación del método auth login 138
Figura 8-53: Captura de paquetes realizada mediante la herramienta Wireshark 138
Figura 8-54: Ejecución del script de Nmap http-traceroute para la dirección ip
10.254.1.203 139
10.254.1.151 141
Figura 8-56: Vista de directorios para la dirección Ip 10.254.1.151 141
Figura 8-57: Consula del DNS www.exa.unicen.edu.ar en la cache de la
dirección Ip 10.254.0.3 144
Figura 8-58: Escaneo con la herramienta Nmap para la dirección Ip 10.254.1.18,
más escaneo con el script smb-os-discovery para el puerto 445 de la misma Ip 146
Figura 8-59: Ejecución del script de Nmap smb-enum-shares para el puerto 445
9
en la Ip 10.254.1.18 146
Figura 8-60: Ejecución del script de Nmap amqp-info para el puerto 5672
en la Ip 10.254.1.171 148
Figura 8-61: Salida de la herramienta Nessus, la cual muestra los host afectados
separados por la versión de Debian 149
Figura 8-62: Escaneo de versiones (servicios y sistemas operativos) para todos los
puertos de la dirección Ip 10.254.0.32 (primer fragmento) 150
Figura 8-63: Escaneo de versiones (servicios y sistemas operativos) para todos los
puertos de la dirección Ip 10.254.0.32 (último fragmento) 151
en la ip 10.254.1.155 152
Figura 8-65: Ejecución del script de Nmap smb-vulns-ms17-010 para el puerto 445
en la ip 10.254.1.155 154
Figura 8-66: Ejecución de los scripts de Nmap p2p-conficker,
smb-os-discovery, smb-vulns-conficker para el puerto 445 en la ip 10.254.1.152 156
Figura 9-1: Fragmento de código con vulnerabilidad XSS de tipo-0 162
Figura 9-2: Interfaz web que permite la inyección de código html 165
Figura 9-3: Visualización de código inyectado desde un input de usuario,
procesado y embebido en la interfaz de usuario 166
Figura 9-4: Evidencia sobre la posibilidad de inyectar de texto plano en la interfaz
de usuario 167
Figura 9-5: Inyección de texto plano en la interfaz de usuario 168
Figura 9-6: Inyección payload en la interfaz de usuario 169
Figura 9-7: Ejecución del payload inyectado 170
Figura 9-8: Inyección de comando RSET en el archivo s_client.s 173
Figura 9-9: Verificación de ejecución del comando RSET (inyectado) 174
Figura 9-10: Listado de módulos de Metasploit relacionados con PostgreSQL 177
Figura 9-11: Opciones para el exploit postgres_login contenido en Metasploit 178
Figura 9-12: Configuración y ejecución del exploit posgres_login desde la consola
del Framework Metasploit 178
Figura 9-13: Conexión a base de datos postgreSQL seguido de comando
para listar sus esquemas 179
Figura 9-14: Conexión al esquema comedor 179
Figura 9-15: Listado de tablas definidas en el esquema comedor 180
Figura 9-16: Listado de usuarios junto a sus roles 181
Figura 9-17: Conexión al host 10.254.1.18 mediante el protocolo SMB utilizando un
usuario vacio 182
Figura 9-18: Conexión al host 10.254.1.18 mediante el protocolo SMB utilizando el
usuario anónimo 183
Figura 9-19: Conexión e interacción con el host 10.254.1.152 mediante el protocolo
SMB utilizando un usuario vacío 183
Figura 9-20: Configuración para poder utilizar el exploit eternalblue_doublepulsar
desde msfconsole 184
Figura 9-21: Información sobre el exploit eternalblue_doublepulsar (1er fragmento) 185
Figura 9-22: Información sobre el exploit eternalblue_doublepulsar (2do fragmento) 185
Figura 9-23: Configuración del exploit eternalblue_doublepulsar para correr sobre el
host 10.254.1.18 186
Figura 10-1: Creación de nuevo usuario en un servidor de base de datos con
10
motor PostgreSQL 191
1. Introducción
En la década del 80, la Seguridad Informática se basaba casi en su totalidad en la
seguridad física. Las bases de datos y los sistemas informáticos mediante los cuales era
posible extraer información de estas bases, eran resguardados en cuartos cerrados,
fuertemente custodiados y bajo estrictos controles de visitas. En esa época y bajo esas
condiciones, este modelo de seguridad funcionaba. Pero con los años los sistemas
informáticos dejaron de ser herramientas utilizadas únicamente por gobiernos y
corporaciones en cuartos cerrados, y se han vuelto un instrumento de alcance global accesible
a través de Internet, convirtiendo a la información en uno de los activos más preciados tanto
para gobiernos y empresas, como para particulares. [Fir05] [Ste92]
Con la aparición de Internet y su uso globalizado comenzaron a aparecer nuevos
vectores de ataques que permitían explotar vulnerabilidades que fueron surgiendo debido a la
posibilidad (e incluso muchas veces a la necesidad) de “estar conectados”. Es muy útil para
una corporación mostrar información que le permita promocionar sus objetivos o
proporcionar ciertos servicios a personas externas a la misma. Para ello debe tener un
servidor de acceso público. Pero además, también es algo muy común tener herramientas
internas, de uso corporativo, a las cuales solo los miembros pertenecientes a dicha
corporación puedan acceder. Llevando esto a un nivel más de complejidad, se podrían
requerir distintos niveles de acceso a estas herramientas para distintos niveles jerárquicos
dentro de la corporación. [Fir05]
Todos estos requerimientos exigieron a la Seguridad Informática una constante
evolución para satisfacer las necesidades que fueron surgiendo gracias al avance tecnológico.
Con esto, la seguridad se transformó en una amplia rama de la informática, tan amplia que
incluso se tuvo que dividir en subáreas (Ingeniería Social, Test de Intrusión, Informática
Forense, etc), dando lugar a una gran cantidad de profesionales que gracias a sus
investigaciones permiten seguir llevando a la Seguridad Informática a niveles superiores para
hacer frente a las innumerables y cada vez más variadas amenazas. [Pac09]
Como en la mayoría de las áreas relativamente jóvenes, existen muchos grises en la
Seguridad Informática, temas que aún hoy siguen en discusión y definiciones variadas sobre
11
los mismos conceptos. Pero en su mayoría discrepan en pequeños detalles en los que no se va
a profundizar en el presente trabajo. Esto se puede observar, por ejemplo, en la evolución que
han ido teniendo la norma ISO/IEC 27000 y sus familiares en la corta vida que llevan. Esta
familia de estándares tienen como base a la norma BS 7799. A su vez se puede encontrar la
guía Cobit mantenida por la organización ISACA, reconocida por sus múltiples
certificaciones relacionadas a la Seguridad Informática. Para el presente trabajo se utilizará
el sentido común a la hora de tomar decisiones ante conceptos con variadas definiciones.
[ISO27] [Jar120]
Para comenzar a tratar los temas relacionados con la Seguridad Informática, será
primero de suma utilidad saber precisamente a qué se está refiriendo. Una de las definiciones
que más gusta debido a lo concisa que es pero a su vez la gran cantidad de conceptos que
abarca, es la siguiente: “La Seguridad Informática es un conjunto de medidas de prevención,
detección y corrección, orientadas a proteger la confidencialidad, integridad y disponibilidad
de los activos de información.”. [Jar12]
En la primer parte, se define que en principio se debe intentar prevenir la ocurrencia
de un ataque. Para esto existen dos enfoques. El primero es la Precaución, que busca eliminar
por completo el riesgo. Para esto hacen falta elaborar serias políticas de seguridad que
requieren maduración (se va aprendiendo de la experiencia y modificando las políticas) y
educación del personal para respetar estas políticas. Este es un enfoque a largo plazo. El
segundo enfoque es el Proactivo, que está asociado a las medidas para prevenir incidentes a
corto plazo. Como se puede observar, la diferencia entre estos dos enfoques es el plazo.
[Jar12]
Si las medidas preventivas llegasen a fallar, se debe ser capaz de detectar el problema
y de poder tomar medidas correctivas. Y aquí entra el tercer enfoque de la seguridad, el
Reactivo. La mayoría de las personas no toma las mejores decisiones bajo presión, por lo que
es esencial tener un plan de contingencia, una serie de medidas que deban llevarse a cabo
luego de un incidente. [Jar12]
Aquí se toma un punto clave de la Seguridad Informática, el factor humano. “Un
sistema es tan seguro como su eslabón más débil”, por lo que no sirve de nada que se tomen
las mejores medidas técnicas para securizar un sistema si luego no son respetadas y llevadas a
cabo de la mejor manera. Por ejemplo, de nada serviría que se tenga una contraseña de 2048
bits si el usuario la deja anotada en un papel debajo del teclado.
12
La segunda parte de la definición, hace énfasis en los tres pilares fundamentales entre
los cuáles debe mantenerse el equilibrio:
- Confidencialidad: Los datos sólo deben ser accesibles para quienes estén
autorizados. Trata sobre el acceso/lectura.
- Integridad: Asegura que solo quienes tengan autorización pueden modificar el
estado de los datos. Los datos no pueden modificarse solos. Evita tanto la
corrupción intencional como casual de la información. Trata sobre la
alteración/escritura.
- Disponibilidad: Es el contrapeso de la seguridad. Es fácil hacer seguro algo
que no es accesible. Los datos deben estar disponibles cuando alguien
autorizado quiera acceder a ellos ya sea para leerlos como para modificarlos.
Existe otro concepto también importante, que incluso en algunas definiciones se lo
incluye entre los pilares fundamentales:
- Irrefutabilidad (No Repudio): Cuando alguien actúa dentro del sistema, éste
debe garantizar que sea de conocimiento quién, cómo y cuándo hizo qué cosa.
[Jar12] [Fir05]
Siguiendo todas estas definiciones se transita por el buen camino, pero no se garantiza
un sistema 100% seguro, ya que no se debe olvidar que la seguridad es un estado, no una
esencia. Por lo que un sistema no es seguro, sino que está seguro, y este estado puede
cambiar de un momento a otro, aunque si se siguen las buenas prácticas se mantendrá en ese
estado de seguridad la mayor cantidad de tiempo posible.
Dado esto, se ha decidido realizar un Test de Intrusión, tanto de infraestructura como
aplicativo, sobre las redes, servidores y hosts de ciertas áreas de la Universidad. Con esto, se
busca tener una primera evaluación sobre el nivel de seguridad de los distintos componentes
de la red auditados, y además, establecer una serie de técnicas a seguir, así como también
una suite de herramientas que utilizar para realizar auditorías futuras.
De esta forma, no solo se podrá elevar el nivel de seguridad, sino que también, puede
servir como un puntapié inicial para justificar la creación de un departamento o equipo
abocado al área. Además, toda esta información recolectada, y la experiencia adquirida, podrá
ser utilizada como referencia base para futuros trabajos finales que se centren en esta área y
utilicen a la UNICEN como dominio de estudio.
13
Durante la auditoría, se tendrá comunicación constante con los encargados del Centro
de Datos y Comunicaciones, y en caso de que se encuentren vulnerabilidades se deberá
consultar antes de que se realicen pruebas de explotación que puedan poner en riesgo la
integridad de los servidores y los datos dentro de los mismos. Además, debido a las
limitaciones geográficas, se utilizará una Red Privada Virtual (VPN de sus siglas en inglés)
para simular estar dentro de la red del campus universitario y así poder realizar escaneos y
ataques internos. Esto último es importante, ya que por la distribución de las computadoras y
el cableado de las redes dentro del campus, un atacante malintencionado podría hacerse con
el control de los mismos y estar conectado directamente dentro de la red interna.
En este caso, el Test de Intrusión hará principal hincapié en la seguridad de los
servidores del Centro de Datos y Comunicaciones y a las redes y equipos correspondientes a
las bandas del Rectorado y la Unicen.
Una vez finalizada la auditoría, se hará entrega de un informe técnico en el que se
pondrá en manifiesto la identificación del riesgo, la probabilidad de ocurrencia, el impacto en
la organización y la estimación de su gravedad así como las correspondientes
recomendaciones para solucionar los problemas encontrados.
Además, se pretende comenzar a documentar el estado de la seguridad, incluyendo
vulnerabilidades, medidas de resguardo, técnicas, herramientas, etc. Y se espera que toda esta
información sea considerada como referencia para que cuando otros alumnos de la UNICEN
deseen realizar sus trabajos finales de carrera, ya dispongan de una guía que les permita
centrarse con mayor foco en los aspectos que le sean de su interés.
Un aspecto interesante a resaltar, es la carencia de experiencia previa con la que se
cuenta, referente al área de Seguridad Informática. En este caso, la herramienta principal será
el conocimiento adquirido a lo largo de la carrera de Ingeniería de Sistemas para interpretar
conceptos y resolver problemas.
Por lo tanto, en este trabajo final se podrán apreciar los procesos y métodos que
implementa un ingeniero para solucionar problemáticas nuevas y desconocidas para él.
Siguiendo la filosofía “Divide y Conquista” y una metodología similar a la del desarrollo de
software, se dividirá el problema general en varias etapas. El resultado de cada etapa será
utilizado como base para la posterior, y se irán cumpliendo objetivos intermedios de manera
incremental hasta conseguir con éxito el resultado final esperado.
14
Para terminar, es importante aclarar que las evaluaciones de seguridad en si solo
muestran una captura de un momento determinado de la seguridad de la organización.
Únicamente representan un verdadero valor agregado cuando son llevadas adelante de forma
sistemática y continua en el tiempo, y cuando las recomendaciones que surgen de ellas son
implementadas. En otras palabras, para que las evaluaciones de seguridad sean realmente
efectivas, deben ser integradas al Sistema de Gestión de la Seguridad de la Información
(SGSI) de las organizaciones, siendo una entrada mas de su proceso de gestión de riesgos.
[Per13] [ISO27]
1.1. Motivación
Es de gran importancia para el Centro de Datos y Comunicaciones de la UNICEN,

comenzar a investigar sobre diferentes metodologías, técnicas y prácticas para reforzar los
aspectos de la seguridad tanto de su información como de su infraestructura de redes.
Evaluando pros y contras, costos de implementación, puntos de vulnerabilidad e inclusive la
posibilidad de crear un área encargada de gestionar todos los asuntos concernientes a la
Seguridad Informática.
Es por esto que se decidió realizar una Auditoría de Seguridad del Centro de Datos y
Comunicaciones de la Universidad Nacional del Centro (UNICEN), más específicamente un
Test de Intrusión. Este es un test ofensivo, mediante el cual se intentará poner a prueba la
seguridad de los sistemas donde se encuentra toda la información de sus estudiantes, docentes
y transacciones burocráticas y la infraestructura de red de la Universidad, con el fín de volver
la seguridad un aspecto prioritario.
1.2. Objetivos
- Generar un informe sobre los aspectos de Seguridad Informática de los servicios

prestados por el Centro de Datos y Comunicaciones.
- Mediante el Test de Intrusión, vulnerar la seguridad del sistema de información de la
organización para conseguir accesos no autorizados, interrumpir un servicio u obtener
información sensible, entre otros.
15
- Generar un informe técnico en el que se ponga en manifiesto la identificación de
riesgos, la probabilidad de ocurrencia, el impacto en la organización y la estimación
de su gravedad así como las correspondientes recomendaciones para solucionarlo.
- El Test de Intrusión hará principal hincapié en la seguridad de los servidores del
Centro de Datos y Comunicaciones, correspondientes al Rectorado y la Unicen. Con
el resultado final de este test, se evaluará la necesidad de contar con un área o
personal dedicado exclusivamente a la Seguridad Informática.
- Por último, se pretende comenzar a documentar el estado de la seguridad, incluyendo
vulnerabilidades, medidas de resguardo, técnicas, herramientas, etc.
16
2. Estado del Arte
La Seguridad Informática se encuentra en constante evolución. Si bien no es algo
nuevo, ha ido cobrando mayor importancia recién en los últimos años. El ciberespacio no es
real, pero existe, y lo que ocurre en él tiene repercusiones en el mundo real.
Tal es así, que con el correr de los años han ido surgiendo ramificaciones de la
Seguridad Informática especializadas en diversas áreas. En [Pac09], Pacheco y Jara definen
las áreas descritas a continuación.
2.1. Ingeniería Social
Haciendo una analogía con una cadena, se dice que un sistema es tan seguro como su
eslabón más débil. En este caso, ese eslabón, suele ser el ser humano, y es por donde
probablemente se produzca una brecha en la seguridad. Por este motivo es que surge la
Ingeniería Social.
Se puede decir que es un método no técnico para obtener información sobre un
sistema basado en el factor humano y que puede ser utilizado en el contexto de un ataque.
La Ingeniería Social se aprovecha de algunas características propias del
comportamiento humano para obtener información. Principalmente se basa en la teoría de que
el ser humano es bueno por naturaleza y en su necesidad de no querer decepcionar tiende a
intentar ayudar.
Algunas de las características humanas en las que se basa la Ingeniería Social son:
- Confianza: el creer en las personas hace que no se dude de su buena voluntad.
- Ignorancia: la falta de educación promueve la manipulación de los individuos.
- Miedo: las amenazas por incumplimiento pueden doblegar la voluntad.
- Codicia: lleva a aceptar algo en base a una falsa promesa.
- Deber Moral: lleva al cumplimiento por obligación moral.
- Intimidación: simulación de una figura de autoridad.
- Adulación: a todos les gusta que los halaguen.
- Ayuda: ofrecimiento de ayuda para generar confianza.
17
Para que puedan aprovecharse estas características y comportamientos del ser humano
es necesario que se genere un pensamiento más amplio, intentando ver el mundo desde la
perspectiva de un enemigo, una habilidad que puede beneficiar en casi cualquier profesión.
[Sch08]
Para realizar un ataque de Ingeniería Social existen diversos métodos, algunos
sencillos que no requieren conocimientos técnicos y otros más avanzados. Algunos de estos
métodos son:
- Inspección Visual: esta simple técnica está relacionada con los descuidos
típicos de los usuarios, como las páginas web y correos personales abiertos,
documentos cargados, etc. Un término relacionado con esta técnica es
Shoulder Surfing (mirar por encima del hombro), que consta básicamente de
espiar a un usuario mientras usa su computadora, por ejemplo, cuando ingresa
una contraseña.
- Trashing: también conocido como Dumpster. Basado en la conocida frase “la
basura de unos es el tesoro de otros”, consta en la recolección de residuos en
baldes de basura o contenedores, con el fin de encontrar información útil en
documentos descartados, impresiones, anotaciones, etc.
- Programación Neurolinguística: permite conocer la percepción de las otras
personas sobre su realidad, por lo que hace posible conocer datos que ni las
propias personas saben sobre sí mismas. Así, se pueden detectar mentiras,
persuadir de realizar alguna acción, analizar el porqué de un comportamiento,
interpretar información subyacente en un diálogo y mucho más. Para esto se
utilizan técnicas que se basan en la comunicación verbal y no verbal (postura,
gestos, movimientos reflejos, etc).
- Ingeniería Social Inversa: describe una situación en la que la víctima realiza el
contacto inicial y ofrece al atacante la información que éste deseaba. El
atacante logra esto de manera activa, provocando un problema adrede, o de
manera pasiva, esperando que el problema surja. La defensa contra esta
técnica es muy difícil debido a que la víctima es quien inicia el contacto y por
este motivo se eliminan las sospechas.
- Robo de Identidad: es un delito donde una persona utiliza la documentación y
datos identificatorios de otra para realizar operaciones, normalmente
18
financieras, que implican a la vez conductas delictivas. Las leyes no brindan
suficiente protección para los casos de identidad robada y, normalmente, solo
se puede saber qué ocurrió a partir de descubrir sus efectos.
- Phishing: es un método que los ciberdelincuentes utilizan para engañar y
conseguir que se revele voluntariamente información personal, como
contraseñas o datos de tarjetas de crédito. Se puede realizar mediante el envío
correos electrónicos fraudulentos o redirigiendo a un sitio web falso.
2.2. Seguridad Física y Biométrica
La biometría es el estudio de métodos automáticos para el reconocimiento de personas

basado en rasgos de conducta o físicos. En el campo de la seguridad se utilizan métodos
matemáticos y tecnológicos para verificar la identidad de un usuario.
El principal organismo internacional de estandarización biométrica es el subcomité 17
del grupo JTC1 de ISO/IEC. Además, en Estados Unidos se encuentran las organizaciones
ANSI y NIST que tratan el tema en sus estándares ANSI/INCITS 358 o BioAPI y NISTIR
6529 o CBEFF, respectivamente.
Para la identificación se suelen utilizar las huellas dactilares, el reconocimiento facial,
el iris, la retina, la voz o la firma.
Además, la seguridad física incluye el acceso a las instalaciones y la seguridad
perimetral. Aquí entran en juego dispositivos de alarmas, detectores de movimiento,
cerraduras electrónicas, etc. Una técnica muy conocida en el mundo de la Seguridad
Informática es el Lockpicking (del inglés lock, que significa cerradura, y pick, ganzúa), y es la
apertura de cerraduras utilizando técnicas y herramientas especiales que no incluyen la llave
original. Es muy común ver competencias de Lockpicking a modo de diversión y de
demostrar esta habilidad en conferencias de Seguridad Informática como la DEFCON que se
realiza en Estados Unidos o la Eko Party de Argentina.
2.3. Criptografía
Es una rama de la Criptología que se ocupa del estudio de las técnicas de cifrado y
codificado destinadas a alterar las representaciones de los mensajes con el fin de hacerlos
ininteligibles a receptores no autorizados. Es decir, trabaja en pos de cuidar uno de los pilares
19
de la Seguridad Informática, la confidencialidad. Para esto se basa en técnicas y algoritmos
matemáticos.
Se puede clasificar la Criptografía en:
- Criptografía Simétrica: surge del uso de una sola clave para cifrar y descifrar,
denominada clave secreta o secreto compartido. Para enviar un mensaje desde
un emisor a un receptor dado, ambos deben compartir la clave. Aquí surge la
debilidad más importante de este tipo de sistemas, ya que trae aparejada la
necesidad de un mecanismo de gestión y distribución de claves porque estos
algoritmos no los poseen. Como principal ventaja tienen su eficiencia
temporal. Los algoritmos de cifrado simétrico más conocidos son DES, 3DES,
RC5, AES, Blowfish e IDEA.
- Criptografía Asimétrica: estos algoritmos usan dos claves, una pública y una
privada. Si se cifra con una se debe descifrar con la otra. Estos algoritmos se
utilizan para el intercambio de claves y las firmas digitales. Entre estos
algoritmos se pueden encontrar Diffie-Hellman, RSA, DSA y ElGamal. Los
protocolos SSH, TLS y SSL utilizan este tipo de algoritmos.
- Criptografía Híbrida: utiliza tanto cifrado simétrico como asimétrico. A través
del cifrado asimétrico comparte la clave que luego se utilizará para el cifrado
simétrico del mensaje que se desea enviar. Compartir una clave asimétrica no
es seguro, por lo que ésta debería cambiar en cada sesión. PGP y GnuPG
utilizan un cifrado híbrido. [Ash99]
2.4. Informática Forense
Es la aplicación de técnicas científicas y analíticas especializadas a infraestructura

tecnológica que permiten identificar, preservar, analizar y presentar datos que sean válidos
dentro de un proceso legal.
Dichas técnicas incluyen reconstruir el bien informático, examinar datos residuales,
autenticar datos y explicar las características técnicas del uso aplicado a los datos y bienes
informáticos.
Esta disciplina hace uso no solo de tecnologías de punta para poder mantener la
integridad de los datos y del procesamiento de los mismos, sino que también requiere de una
20
especialización y conocimientos avanzados en materia de informática y sistemas para poder
detectar dentro de cualquier dispositivo electrónico lo que ha sucedido. El conocimiento
informático forense abarca el conocimiento no solamente del software sino también del
hardware, seguridad, hacking, cracking y recuperación de información.
La informática forense ayuda a detectar pistas sobre ataques informáticos, robo de
información, conversaciones o pistas de emails y chats. No es de índole preventivo, está
enfocada para utilizarse luego de que el hecho en cuestión suceda.
2.5. Auditorías de Seguridad
Hoy día existen múltiples estándares y metodologías para llevar a cabo auditorías de
seguridad. En su mayoría similares, aunque varían en los detalles, las herramientas y los
procesos. Además, estos estándares se han ido combinando para generar estándares nuevos e
incluso algunos han ido evolucionando con el correr del tiempo. Un ejemplo de esto es el
estándar BS 7799 publicado en 1995 por el BSI Group, que tuvo tanta aceptación que luego
se utilizó como base para elaborar las normas ISO/IEC 27000-series. [Arn07]
Uno de los primeros estándares referidos a la Seguridad Informática es el Trusted
Computer System Evaluation Criteria (TCSEC), también conocido como el Orange Book
(Libro Naranja). Fue creado por el Departamento de Defensa de los Estados Unidos (DoD) a
principio de la década del 80. Define siete conjuntos de criterios de evaluación denominados
clases (D, C1, C2, B1, B2, B3 y A1). Cada clase de criterios cubre cuatro aspectos de la
evaluación: política de seguridad, imputabilidad, aseguramiento y documentación. Los
criterios correspondientes a estas cuatro áreas van ganando en detalle de una clase a otra,
constituyendo una jerarquía en la que D es el nivel más bajo y A1 el más elevado. Todas las
clases incluyen requisitos tanto de funcionalidad como de confianza.[DoD83]
En Mayo de 1990, Alemania, Francia, Países Bajos y Reino Unido publicaron el
Information Technology Security Evaluation Criteria (ITSEC), también conocido como White
Book (Libro Blanco). Estas normas establecen que al Objetivo de Evaluación (OE, sistema
sometido a evaluación) se le debe realizar un examen detallado de sus características de
seguridad, que incluyan pruebas de funcionamiento y Tests de Intrusión. Según el nivel de
confianza deseado para el OE en cuestión, es el grado del examen que se debe realizar. Para
proporcionar diferentes grados de confianza se definen los llamados niveles de evaluación,
21
desde E0 a E6. Los niveles más altos de evaluación exigen exámenes y tests más detallados
del OE. A diferencia de TCSEC, ITSEC no requiere que los OE contengan características
técnicas específicas para alcanzar un determinado nivel de confianza. Por ejemplo, un OE
puede ofrecer características de autenticación o integridad sin proporcionar medidas de
confidencialidad o disponibilidad. Las especificaciones de seguridad de un OE dado deben
estar detalladas en el documento Objetivo de Seguridad, cuyo contenido debe ser evaluado y
aprobado antes de someter el OE a examen. Las evaluaciones basadas en ITSEC únicamente
verifican las características de seguridad descritas en el mencionado documento. [Eur91]
En 1993, en Canadá, el Communications Security Establishment publica el estándar
Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) con el fin de proveer un
criterio de evaluación de productos IT. Es una combinación de TCSEC y ITSEC. [CSE93]
A fines de los años 90 surgen los Common Criteria (CC), que combinan los
estándares TCSEC, ITSEC y CTCPEC, con el fin de unificar criterios. Pero paralelamente en
Europa se comenzó a desarrollar un estándar ISO, con lo que se volvió al problema original
de tener distintos criterios y estándares según el continente. Con el tiempo, el CC evolucionó
a su versión 2.0, y luego de un trabajo colaborativo entre diversas organizaciones se combinó
con el estándar ISO que se estaba desarrollando en Europa para formar, a fines de 1999, el
estándar internacional Common Criteria o también conocido como ISO-15408. [CC99]
Figura 2-1: Historial de metodologías de auditorías de seguridad
Si de estándares referidos a la seguridad se habla, no se pueden dejar de mencionar las

series de normas ISO/IEC-27000 publicadas por la Organización Internacional de
22
Estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC). Esta serie de normas
proporcionan un marco de gestión de la seguridad de la información utilizable por cualquier
tipo de organización, pública o privada, grande o pequeña. La norma 27000 contiene todos
los conceptos y vocabulario necesarios para comprender el resto de las normas de la familia.
La 270001 habla de las certificaciones disponibles para las empresas, organizaciones e
instituciones. La 27002 de las buenas prácticas para la administración o gestión de seguridad
de la información. La norma 27003 muestra algunas de las directrices para la implementación
de un Sistema de Gestión de Seguridad de la Información. La 27004 muestra las métricas
para la gestión de seguridad de la información.[ISO27]
No todos los ataques son de la misma naturaleza por lo que existen diversas
clasificaciones. La siguiente clasificación está realizada desde el punto de vista técnico y
enfocada en lo que se intentará vulnerar [Per13]:
- Ataques al Sistema Operativo: constituyen un punto clásico de la seguridad.
Desde esta perspectiva, la búsqueda de fallas se realizará en lo concerniente al
propio sistema base de todo el resto del software, de tal modo que muchas
veces, independientemente de lo que se encuentre por encima, se podrá
explotar y tomar control del sistema en caso de que sea vulnerable. En la
actualidad se tienen tres líneas principales: los sistemas del tipo Windows, los
del tipo Linux o derivados de UNIX, y los sistemas MAC OSX, los cuales, si
bien están basados en UNIX, a esta altura presentan entidad propia. En el caso
de los primeros, desde su origen fueron objeto de ataques dada su masificación
y la relativa simplicidad con que se pudo acceder históricamente al núcleo del
sistema, incluso, sin contar con su código fuente. Para el caso de Linux la
situación es quizás peor, ya que, al poseer el código fuente, es posible detectar
problemas también a nivel de código. Y en cuanto a OSX, la velocidad con la
que ha acaparado mercado de múltiples plataformas en los últimos años,
sumado a que los controles de seguridad implementados no son suficientes
frente a las amenazas actuales, hacen que el sistema operativo de Apple sea un
blanco cada vez más buscado por los atacantes. Pese a lo que suele creerse, la
estadística de cantidad de vulnerabilidades de Windows no supera anualmente
a las de Linux, en general, la diferencia ha sido la velocidad con la que
aparecían las soluciones en cada caso, llevando aquí Linux la delantera,
23
aprovechando una de las grandes ventajas del código abierto, el
cooperativismo.
Los ataques al sistema operativo también incluyen las
implementaciones que éste realiza de las distintas tecnologías, lo cual puede
incluir bibliotecas externas.
Además, la masificación de los entornos de virtualización en el ámbito
corporativo agregan una nueva capa que también es susceptible de ser atacada,
dejando expuesto a todos los sistemas que corren sobre ella.
- Ataques a las aplicaciones: en este caso, la variedad es mayor. Existen miles y
miles de piezas de software y programas de todo tipo y tamaño. Por supuesto,
entre tantos millones de líneas de código, necesariamente se producen errores.
Para los ataques a las aplicaciones también se tendrá en cuenta la masividad de
uso.
Las aplicaciones amplían entonces la superficie de ataque de un
sistema, por lo que se recomienda siempre evitar la instalación de aquellas que
no se requieran, siguiendo el principio de seguridad que sugiere el
minimalismo. Dependiendo de los privilegios con los que se ejecute cierto
programa, si es comprometido, podría afectar de forma directa al sistema, ya
que se utilizará el mismo nivel de permisos para atacar desde adentro.
- Errores en configuraciones: por más seguro que sea un software, una mala
configuración puede volverlo vulnerable. Esto puede ocurrir incluso en
herramientas de protección como los antivirus, lo que lleva a un concepto muy
común en este rubro, una falsa sensación de seguridad.
Una mala pero frecuente práctica es dejar las configuraciones de
fábrica, lo cual facilita la tarea de los atacantes. Existen múltiples sitios web
donde se encuentran las contraseñas por defecto de aplicaciones y dispositivos.
La solución más efectiva a estos problemas es el hardening. Este
proceso consiste en utilizar las propias características de dispositivos,
plataformas y aplicaciones para aumentar sus niveles de seguridad. Cerrar
puertos que no son imprescindibles, deshabilitar protocolos y funciones que no
se utilicen, cambiar parámetros por defecto y eliminar usuarios que no sean
necesarios son solo algunos ejemplos sencillos de un proceso de hardening.
24
- Errores en protocolos: son los problemas más graves que se pueden encontrar,
aunque los menos frecuentes. Esto implica que, sin importar la
implementación, el sistema operativo, ni la configuración, algo que se
componga de dicho protocolo podría verse afectado. Dentro de esta rama de
errores, también se incluyen los protocolos y algoritmos criptográficos que
tienen un alto nivel de complejidad y pueden producir huecos de seguridad
realmente muy grandes dada la función de protección para la que son
utilizados.
2.6. Test de Intrusión
Una de las pruebas posibles a la hora de evaluar la seguridad de un sistema y/o red es
el llamado Test de Intrusión o Pentesting. Este test evalúa los niveles de seguridad de un
sistema informático o red mediante la simulación, en un entorno controlado, de un ataque por
parte de un usuario malintencionado. Implica un proceso de análisis activo del sistema en
busca de posibles vulnerabilidades que podrían resultar de una mala o inadecuada
configuración de un sistema, defectos en software, o una falla de seguridad en un sistema
operativo o hardware.
Este análisis debe realizarse desde la posición de un atacante potencial, y puede
implicar la explotación activa de vulnerabilidades de seguridad. Los problemas de seguridad
que se encuentren se deben presentar al propietario del sistema junto con una evaluación del
impacto que supondría dentro de la organización, además de una propuesta de mitigación o
una solución técnica.
El propósito de un Test de Intrusión es determinar la viabilidad de un ataque y la
cantidad de impacto de la explotación exitosa, si ocurriese. La mejor manera de demostrar la
fuerza de una defensa es tratando de penetrar en ella.
Dado que los Tests de Intrusión están diseñados para simular un ataque y utilizar
herramientas y técnicas que pueden ser restringidas por la ley, es fundamental obtener el
permiso formal para realizar estas pruebas, que consideren tanto las regulaciones de la ley
como la política de la entidad sobre la cual se realizará la auditoría.
25
Este permiso debe estar previamente acordado, organizado y plasmado en un
documento físico firmado por ambas partes, donde se indicarán cuáles serán las pautas a
seguir, y a partir de allí empiezan a entrar en juego las fases prácticas de un Test de Intrusión.
Dependiendo la bibliografía, se podrán encontrar diferentes metodologías que dividen
el proceso en distintas etapas. A continuación se mencionan algunas de estas bibliografías y
se describen brevemente sus metodologías:
- El Manual de la Metodología Abierta de Comprobación de la Seguridad
(OSSTMM, Open Source Security Testing Methodology Manual) [Her08].
Este manual contiene gran parte de los estándares utilizados en auditorías de
seguridad. Incluye un marco de trabajo que describe las fases que habría que
realizar para la ejecución de la auditoría. OSSTMM supuso el primer
acercamiento a una estructura global del concepto de seguridad. Si bien las
pruebas incluidas y los test que se ejecutan no son especialmente innovadores,
se ha convertido en una auténtica referencia para los organismos que quieren
desarrollar un test de calidad ordenado y eficiente.
Actualmente está conformado por 6 fases: la seguridad de la
información, de los procesos, en las tecnologías de internet, en las
comunicaciones, y también hace referencia a la seguridad inalámbrica y física.
De manera sencilla se identifican una serie de actividades de testeo
específicas por área, sobre las que se comprueban las especificaciones de
seguridad, integradas con las verificaciones realizadas en las revisiones
rutinarias.
Con esta metodología, se realiza un esfuerzo para convertir en
predecible “qué” se debe de probar, “cómo” se puede hacer y “cuándo” es
necesario ejecutarlo. De esta manera se aumenta la calidad del desarrollo, ya
que al seguir esta metodología, se tiene la certeza de que se cumplen unos
objetivos prefijados.
Un aspecto importante de esta metodología, es que no solo se centra en
los aspectos técnicos de seguridad tradicionales, sino que abarca aspectos
sobre los responsables del testeo. Trata de estandarizar las credenciales del
desarrollador a cargo del test, el formato de los resultados, crear un código
ético, un plan temporal de ejecución, etc. Otro aspecto importante es la
26
incorporación del concepto de Valores de Evaluación de Riesgo, que permite
diferenciar y clasificar las diferentes problemáticas.
- ISSAF (Information Systems Security Assessment Framework). [Ois06] Esta
metodología está diseñada para evaluar las redes de trabajo, sistemas y
control de aplicaciones, enfocada en tres fases.
Planificación y preparación: Esta fase comprende los pasos
iniciales para el intercambio de información, planificar y preparar la prueba.
Antes de llevar a cabo la prueba formal, un acuerdo será firmado por ambas
partes. Este constituye la base de acciones y la mutua protección jurídica.
Asimismo especificará la participación del equipo, las fechas exactas, los
tiempos de la prueba, la escalada de privilegios y otros arreglos.
Evaluación: Esta es la fase en donde se lleva a cabo el Test de
Intrusión. En la fase de evaluación en un enfoque por capas deberán ir de
forma secuencial las siguientes tareas:
- Recolección de Información
- Mapeo de la red de trabajo
- Identificación de vulnerabilidades
- Penetración
- Obtención Acceso y Escalada de Privilegios
- Enumeración
- Comprometer Usuarios Remotos y Sitios
- Mantener Acceso
Reportes, limpieza y destrucción de objetos: En el curso de las

pruebas de intrusión en el caso de que una cuestión crítica sea identificada,
debe ser informada de inmediato para garantizar que la organización sea
consciente de ello. Estos puntos deben ser discutidos y se necesitan buscar
contramedidas para resolverlos. Luego de la finalización de todos los casos de
prueba definidos en el ámbito de trabajo, se deberá generar un informe escrito
que describa los resultados detallados de las pruebas junto a recomendaciones
para la mejora. El informe debe seguir una estructura bien documentada,
incluyendo aspectos como el alcance del proyecto, herramientas utilizadas,
27
todas las pruebas realizadas junto a sus salidas (con exclusión de informes de
análisis de vulnerabilidad que pueden ser incluidos como documentos
adjuntos), etc.
- Proyecto abierto de seguridad de aplicaciones web (OWASP, Open Web

Application Security Project) [OWA01] es un proyecto de código abierto
dedicado a determinar y combatir las causas que hacen que el software sea
inseguro. La Fundación OWASP es un organismo sin ánimo de lucro que
apoya y gestiona los proyectos e infraestructura de OWASP. La comunidad
OWASP está formada por empresas, organizaciones educativas y particulares
de todo el mundo. Juntos constituyen una comunidad de seguridad informática
que trabaja para crear artículos, metodologías, documentación, herramientas y
tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.
- Penetration Testing Execution Standard (PTES) [PTE09] define una

metodología basada en 7 fases: Pre-engagement Interactions, Intelligence
Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post
Exploitation, Reporting. En vez de sólo proveer una metodología, también
recomienda herramientas y formas de uso.
- Payment Card Industry Data Security Standard (PCI DSS) [PCI15] define
una guía para el Test de Intrusión que se titula PCI DSS Penetration Guidance
y también provee una serie de definiciones en su Requerimiento 11.3.
Si bien las etapas y los nombres de las mismas varían de metodología en metodología,
son similares en gran parte. Por ejemplo, OSSTMM define 6 etapas, ISSAF 9, OWASP
también 9 y PTES 7. [Kan15] Cambian las fronteras de las etapas, las herramientas
recomendadas y algunos enfoques, pero la esencia del Test de Intrusión se mantiene.
Además, cada pentester, a través de la experiencia, va incorporando variantes propias.
La elección de una metodología va a depender del conocimiento del pentester, de su
experiencia previa y de un análisis sobre el sistema objetivo que se desea poner a prueba.
Los Test de Intrusión pueden llevarse a cabo de manera externa o de manera interna.
Por lo general, un Test de Intrusión suele contemplar ambos escenarios, aunque esto va a
depender del acuerdo con el cliente. En el análisis interno lo que se evalúa son todos aquellos
puntos relacionados con la red interna y la información que circula a todos los niveles. En el
28
caso del análisis externo, todas las pruebas se hacen en forma remota, buscando
vulnerabilidades en la frontera, como por ejemplo, en el firewall o en servidores que estén
brindando servicios de Internet. Se trata de hallar cualquier punto que, una vez explotado,
permite obtener acceso a la DMZ o a la red interna.
Además, según el grado de conocimiento con que el pentester comience la auditoría,
se pueden clasificar los Test de Intrusión en:
- Caja Blanca (White Box): en este, quien solicita el análisis provee quien lo realiza
cierta información relativa a la organización, como por ejemplo bloques de
direcciones IP, credenciales de acceso, estructura de servidores, etcétera.
- Caja Negra (Black Box): el pentester no recibe ningún tipo de información, con lo
cual esta prueba simula el caso más realista desde el punto de vista de un atacante.
- Caja Gris (Grey Box): es un punto intermedio entre los dos anteriores.
2.7. Vulnerabilidades y Tipos de Ataque
En seguridad informática, la palabra vulnerabilidad hace referencia a una debilidad en

un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad,
control de acceso y consistencia del mismo junto a sus datos y aplicaciones.
Para ahondar más en el significado de vulnerabilidad se puede describir el siguiente
ejemplo. Imagine que en un hogar se tiene una computadora personal con una conexión a
Internet, donde además se encuentra configurada una cuenta de correo electrónico a través de
la que se reciben mensajes diariamente. A su vez este dispositivo tiene instalado un antivirus
que es capaz de revisar los mensajes electrónicos, incluidos los archivos que están adjuntos.
Pero el antivirus fue instalado en el momento que se compró y nunca se volvió a actualizar.
Por lo tanto, el equipo es vulnerable a los virus más recientes que puedan llegar mediante el
correo electrónico, ya que el antivirus se encuentra desactualizado y no tiene conocimientos
sobre la existencia de estos nuevos virus.
De todas formas se debe tener en cuenta el siguiente hecho, que exista una
vulnerabilidad no significa que se produzca un daño en el equipo de forma automática. Es
decir, la computadora tiene un punto débil, pero no por eso va a fallar, lo único que ocurre es
que es posible que alguien que ataque el equipo aproveche ese punto débil.
29
Existen un gran número de vulnerabilidades las cuales pueden ser agrupadas en diferentes
categorías, como por ejemplo:
- Vulnerabilidades de desbordamiento de buffer, las cuales se producen cuando un
programa no controla la cantidad de datos que se copian en buffer, de forma que si esa
cantidad es superior a la capacidad del mismo los bytes sobrantes se almacenan en
zonas de memoria adyacentes, sobrescribiendo su contenido original. Se puede
aprovechar para ejecutar código que otorgue privilegios de administrador.
- Vulnerabilidades de condición de carrera (race condition), esto ocurre
principalmente cuando varios procesos acceden al mismo tiempo a un recurso
compartido, por ejemplo una variable, cambiando su estado y obteniendo de esta
forma un valor no esperado de la misma.
- Vulnerabilidades de error de formato de cadena (format string bugs), la principal
causa en estos casos es que se acepte sin validar la entrada de datos proporcionada por
el usuario. Aqui, un ataque puede conducir de manera inmediata a la ejecución de
código arbitrario y a revelación de información.
- Vulnerabilidades de Cross Site Scripting (XSS). En esta categoría se encuentran
ataques que permiten ejecutar scripts desarrollados en lenguajes tales como VBScript
o JavaScript, en una interfaz web. Estos errores se encuentran en aplicaciones que
tenga como objetivo final presentar información mediante un navegador web. Uno de
los usos más comunes de esta vulnerabilidad es aplicar la técnica de phishing (la
víctima ingresa a un sitio que presume seguro, pero dicho sitio contiene código
malicioso inyectado por un tercero).
- Vulnerabilidades de Inyección SQL. El riesgo aquí es que se permita de alguna
manera, la inserción o "inyección" de código SQL invasor dentro del código SQL
programado, a fin de alterar el funcionamiento normal del programa y lograr así que
se ejecute la porción de código "invasor" incrustado, en la base de datos.
- Vulnerabilidades de denegación del servicio, que provocan que un servicio o recurso
sea inaccesible a los usuarios legítimos. Normalmente generan la pérdida de la
conectividad de la red mediante el consumo del ancho de banda de la misma, como
también mediante la sobrecarga de los recursos informáticos del sistema de la víctima.
- Vulnerabilidades de divulgación de la información, las cuales aparecen cuando
información sensible puede ser visualizada por usuarios no autorizados. La integridad
30
de los datos es uno de los pilares de la seguridad, por lo tanto el acceso no autorizado
a ellos presenta un gran peligro para cualquier sistema informático.
- Vulnerabilidades de versiones deprecadas. Muchas veces el software cuenta de
actualizaciones, en las cuales versiones antiguas dejan de tener soporte. En estos casos
cualquier tipo de riesgo encontrado no será solucionado y por lo tanto son puntos
críticos en la seguridad.
- Vulnerabilidades del día 0 (zero day). Una nueva vulnerabilidad para la cual no se
han creado parches o revisiones ya que aún no son conocidas por los usuarios y
creadores. El nombre 0-day (día cero) se debe a que aún no existe ninguna revisión
para mitigar el aprovechamiento de la vulnerabilidad. Estas a veces se usan junto a los
troyanos, rootkits, virus, gusanos y otros tipos de malware, para ayudarlos a
propagarse e infectar más equipos.
2.8. Herramientas
2.8.1. Sistemas Operativos
Hoy día, se puede utilizar cualquiera de los Sistemas Operativos tradicionales para
realizar auditorías de seguridad, ya que para cada necesidad que surge existen aplicaciones en
cada uno de ellos dedicadas a suplirlas. La selección de uno en específico va a depender tanto
de la experiencia como de la preferencia del auditor.
Para el Sistema Operativo Windows, además de poder instalar aplicaciones de manera
individual y a demanda, existen frameworks como Pentest Box (se puede descargar de su
sitio oficial pentestbox.org) que proveen una colección de herramientas para realizar tareas de
seguridad que corren de forma nativa y además son portables. Gracias a estos frameworks se
evita caer en la utilización de máquinas virtuales que a veces generan problemas de
performance, y que además, para usuarios habituales de Windows, los obliga a un cambio
drástico en cuanto a experiencia de usuario.
En Linux, la gama de distribuciones especialmente desarrolladas para fines de
seguridad que podemos encontrar es muy amplia. Entre las más destacadas están:
- Kali Linux: Desarrollado por Offensive Security y sucesor de la famosa
distribución Backtrack. Está basado en Debian y trae más de 600 herramientas
de pentesting preinstaladas. Cuenta con actualizaciones constantes que
31
permiten al auditor trabajar incluso con las amenazas 0-day. (Se lo puede
descargar del sitio oficial de offensive-security:
www.offensive-security.com/category/kali-linux)
- Parrot Security OS: también basada en Debian y desarrollada por una
comunidad de especialistas. Es una distribución ligera y eficiente, que ofrece
gran cantidad de herramientas. (Se lo puede descargar de su sitio oficial
www.parrotsec.org)
- Back Box: esta distribución está basada en Ubuntu con enfoque en
evaluaciones de seguridad y tests de intrusión. Trae una amplia gama de
herramientas, es rápida y fácil de usar. Cuenta con un entorno de escritorio
completo y los repositorios de software de las herramientas se actualizan
regularmente con las versiones más estables. (Se lo puede descargar de su sitio
oficial backbox.org)
Otras distribuciones que se pueden encontrar son Samurai Web Testing Framework,
Pentoo Linux, DEFT Linux, Caine, Network Security Toolkit (NST), BlackArch Linux,
Bugtraq, etc.
Para el Sistema Operativo de Apple, Mac OS X, existe una paquete de instalación
llamado KOSASP [Her16] que incluye un gran número de programas como los que se
encuentran en Kali Linux o Back Box, pero portados para Mac OS X, ordenados y
organizados por categorías. En la instalación permite seleccionar qué herramientas se desean
instalar. Y provee ciertos scripts corriendo por debajo que se encargan ejecutar estas
aplicaciones sin necesidad de compilar, y de ser necesario instalar software de terceros que se
requiera para su funcionamiento.
Muchas veces, debido a limitaciones en el hardware o a las ventajas que provee, se
busca trabajar en entornos virtualizados. [Mar08] Una de estas ventajas es la posibilidad de
realizar snapshots, es decir, realizar capturas de la máquina virtual con sus datos y el estado
de sus dispositivos en un momento dado. Una vez realizada esta captura se puede continuar
trabajando con la seguridad de que en caso de ser necesario, se pueda volver a ese mismo
instante que se capturó. Esto otorga un mayor nivel de seguridad tanto al cliente de la
auditoría como también al pentester que la realiza.
Un ejemplo en el que tomar un snapshot resulta útil, es cuando se quiere instalar o
actualizar una herramienta. Si dicha herramienta o su actualización no terminan siendo
32
favorables, o peor aún, terminan siendo perjudiciales ya que pueden presentar fallas o llevar
al mal funcionamiento del entorno de trabajo, se tendrá la opción de revertir la situación de
forma limpia, sin necesidad de desinstalar o de intentar pisar la versión nueva con una
anterior. Esto otorga la libertad de tomar muchas más iniciativas sin la preocupación por las
consecuencias, minimizando riesgos y maximizando potenciales beneficios.
Además, la utilización de este tipo de entorno permite tener un ambiente controlado,
en el cual cualquier falla, mal funcionamiento o posible exposición a vulnerabilidades, no
podrán trascender más allá de los límites de la máquina virtual.
2.8.2. Aplicaciones
La variedad de aplicaciones existentes para las tareas de Seguridad Informática es

inmensa, por lo que sería imposible siquiera hacer una breve descripción de cada una de ellas.
A continuación se nombran y explican algunas de ellas [Per13], y llegado el momento se
profundizará sobre aquellas que se utilicen en el presente trabajo.
- Aircrack-ng: se trata de un conjunto de software de seguridad inalámbrica que incluye
un analizador de paquetes de redes, un crackeador de redes WEP y WPA/WPA2-PSK
y otro conjunto de herramientas de auditoría inalámbrica.
- Burp Suite: es una herramienta escrita íntegramente en Java que permite realizar Tests
de Intrusión en aplicaciones web, permitiendo combinar técnicas manuales y
automáticas para analizar, detectar, atacar y explotar aplicaciones web. Incluye
elementos tales como un Spider Web, un Intruder, un repetidor de llamadas, con lo
que las peticiones pueden ser automatizadas.
- Hydra: es un crackeador de contraseñas multihilo por fuerza bruta en base a
diccionarios. Puede crackear prácticamente cualquier servicio (Telnet, POP3, SMTP,
IMAP, SMB, SSH V1 y 2, etcétera) usando una conexión directa o proxys, con o sin
SSL.
- John: hace referencia a John The Ripper, una herramienta muy popular, ya que
permite comprobar que las contraseñas de los usuarios son lo suficientemente seguras.
Aplica fuerza bruta para descifrar contraseñas, siendo capaz de romper varios
algoritmos de cifrado o hash, como DES, SHA-1, entre otros.
33
- Maltego: es una aplicación de minería y recolección de información utilizada durante
las fases de recolección de información. La información la obtiene de Internet y la
representa en forma gráfica para que sea más sencillo de analizar. Es una herramienta
muy potente, llena de opciones que pueden ser muy útiles para investigar empresas,
sitios, personas y mucho más. Permite iniciar búsquedas a partir de dominios, IPs,
ubicaciones geográficas, correos, nombres, teléfonos e incluso frases.
- Metasploit: una forma sencilla de definir Metasploit Framework es que se trata de una
herramienta para desarrollar y ejecutar exploits contra un equipo remoto. Sin embargo
esta herramienta dispone de gran cantidad de funcionalidades, las cuales son muy
utilizadas en el día a día por los auditores de seguridad para llevar a cabo sus Tests de
Intrusión, pudiendo realizar no solamente la explotación y post explotación del
sistema, sino también los pasos previos a ellos.
- Nmap: es un programa por consola de comando que sirve para efectuar rastreo de
puertos y se usa para evaluar la seguridad de sistemas informáticos, así como para
descubrir servicios o servidores en una red informática. Identifica puertos abiertos en
una computadora objetivo, determina qué servicios está ejecutando la misma, obtiene
algunas características del hardware de red de la máquina testeada, contribuye a
realizar la labor de fingerprinting determinando qué sistema operativo y la versión
que utiliza dicho ordenador, identifica equipos en una red.
- Sqlmap: es una herramienta muy útil en los Tests de Intrusión que automatiza el
proceso de detección y explotación de fallos del tipo SQL Injection y de esta forma
permite obtener toda la información contenida dentro de los servidores de base de
datos.
- Wireshark: es un analizador de paquetes que permite examinar datos de una red viva o
de un archivo de captura salvado en disco. Analiza la información captada a través de
los detalles y sumarios de cada paquete. Aunque su uso docente está muy extendido,
no solamente se enmarca en el área educativa, sino que en la actualidad se ha
convertido en una herramienta profesional imprescindible para los auditores
informáticos.
- Zaproxy: es una herramienta fácil de usar y que forma parte de las aplicaciones de uso
habitual en el proceso de pentesting para encontrar vulnerabilidades en aplicaciones
web. Está diseñada para ser utilizada por usuarios con diferentes niveles en seguridad
34
y como tal, es ideal para desarrolladores y probadores funcionales que son nuevos en
el hacking ético, además de ser un conjunto de herramientas muy útil para pentesters
de nivel avanzado.
- Zenmap: es una versión gráfica de nmap que facilita su uso, y la interpretación de
resultados de forma visual.
- BlindElephant: analiza el CMS, y tras estudiar la existencia de determinados plugins
en el mismo, muestra en los resultados las posibles estimaciones acerca de la versión
de la plataforma CMS que se está analizando.
- Plecost: similar a BlindElephant, pero para utilizarlo requiere un paso previo en el que
se obtiene un listado de plugins de WordPress.
- JoomScan: lanza una serie de scripts para comprobar la seguridad de un sitio, y
muestra el segmento de direcciones URLs de cada uno de los fallos de seguridad
encontrados.
- Nikto: Es una de las mejores herramientas de auditoría web. Se complementa
perfectamente con nmap y con Nessus. Realiza un escaneo de todo el sitio web,
detectando la versión del servidor, la tecnología utilizada, algunos comportamientos
sospechosos como balanceadores de carga, diversas vulnerabilidades detalladas,
etcétera.
- OpenVAS: Es una suite de software que ofrece un marco de trabajo diseñado para
integrar servicios y herramientas especializadas en el escaneo y gestión de
vulnerabilidades.
- Nessus: es un programa de escaneo de vulnerabilidades. Es gratuito para uso personal
y entornos no corporativos. Su objetivo es detectar vulnerabilidades potenciales en los
sistemas a auditar.
- Buscadores: Google, Bing, Yahoo. Con ciertas técnicas se pueden lograr resultados
muy potentes a la hora de recolectar información. Además existen buscadores
diseñados para buscar dispositivos y sistemas de ordenadores conectados a Internet,
como lo es SHODAN.
- Robtex: es una página web considerada como “La navaja suiza de Internet”. Permite
realizar ciertas partes del procedimiento activo de footprinting de manera pasiva, es
decir, en lugar de preguntar directamente a los servidores la información sobre sus
35
dominios, subdominios, servidores DNS, etcétera, permite obtener dicha información
sin dejar rastro en el objetivo a través de una sencilla página web.
- Comandos útiles: ping, whois, traceroute, dig, nslookup, whatweb, etcétera. Son
scripts que se ejecutan desde la línea de comandos y permiten obtener información de
todo tipo sobre el sistema a auditar.
36
3. Descripción del problema
Generalmente, los sistemas informáticos, ya sean de entidades públicas o privadas,
incluyen tanto datos como infraestructura de red, para hacerlos circular, y de almacenamiento
para persistirlos.
Un ente estatal del campo académico, como la Universidad del Centro de la Provincia
de Buenos Aires, no es la excepción del caso. Cuenta con múltiples sistemas de diversa
índole coexistiendo en una red heterogénea. A través de su infraestructura viaja y es
procesada y almacenada información de todo tipo. Datos de alumnos y docentes, cátedras,
investigaciones, etc. A su vez se puede encontrar información pública, privada e incluso
restringida a cierto grupo específico de personas.
Debido a que es una entidad pública, mucha de su información también lo es por
cuestiones normativas. Esto, en algunos casos, puede ser perjudicial en lo que a seguridad
refiere.
Además, por la distribución física del campus universitario es factible, y en algunos
casos hasta esperado, que se pueda conectar a un punto de acceso a alguna de las redes
internas dentro del mismo. Por ejemplo, a través de las distintas señales de wifi disponibles,
un cable de red, un dispositivo de ruteo o incluso a través de alguna de las computadoras de
las numerosas aulas y oficinas.
Bajo este escenario, es que para los profesionales del Centro de Datos y
Comunicaciones de la UNICEN es de gran realizar investigaciones y evaluaciones sobre
diferentes metodologías, técnicas y prácticas relacionadas a la seguridad informática para
reforzar la integridad, disponibilidad y confidencialidad de los datos sensibles dentro de los
sistemas que se encuentran tanto en los servidores como en los distintos nodos de la red.
Para esto se desea evaluar pros y contras, costos de implementación, puntos de
vulnerabilidad e inclusive la posibilidad de crear un área encargada de gestionar todos los
asuntos concernientes a la Seguridad Informática de la UNICEN.
Se debe considerar además, que al ser una entidad estatal con fines académicos e
investigativos, no cuenta con un presupuesto elevado para tercerizar esta tarea a especialistas
del área. Tampoco tendría sentido hacerlo por dos motivos. El primero es que a pesar de no
contar con especialistas en Seguridad Informática, existen recursos humanos calificados en el
37
manejo de tecnologías de red y sistemas, que con la capacitación necesaria podrían hacerse
cargo del asunto.
El análisis de los mecanismos de protección debe ser una tarea proactiva, permitiendo
encontrar las vulnerabilidades dentro de los mismos y brindar una solución antes de que
alguien se aproveche de esta debilidad. Dado esto, una de las prácticas recomendadas dentro
del campo de la Seguridad Informática, es la de realizar un Test de Intrusión. Dicho test
consiste en llevar a cabo pruebas ofensivas contra los mecanismos de defensa existentes en el
entorno que se está analizando. No solo ayuda a identificar vulnerabilidades potenciales, sino
que también se intenta explotarlas y, así, confirmar su existencia y el impacto real que
podrían tener en la organización.
En la UNICEN, más específicamente en el área del Centro de Datos y
Comunicaciones, no hay ningún departamento o equipo que se esté encargando de estos
aspectos. Por lo tanto, prácticas como estas, que se recomiendan llevar a cabo con una estricta
periodicidad, son realizadas esporádicamente.
38
4. Configuración del Entorno
Antes de comenzar la primer fase de la auditoría, se deberá proceder a configurar el
entorno de trabajo. Esta planificación previa es de suma importancia debido a que
dependiendo de las decisiones que aquí se tomen se podrán potenciar las posibilidades de
éxito o restringirlas.
4.1. Red Privada Virtual
A grandes rasgos, se puede dividir la auditoría de seguridad en dos fases, una externa
y otra interna. En la fase externa se intentarán descubrir vulnerabilidades sobre los puntos de
acceso públicos de la red de la UNICEN. Para ello no se cuenta con limitaciones más que
tener acceso a Internet. Sin embargo, para la fase interna, en la cual se intentarán encontrar
vulnerabilidades en la red privada de la universidad, surgen ciertas limitaciones.
El campus universitario es un lugar muy amplio con numerosas aulas, laboratorios y
oficinas distribuidos a lo largo de sus 53 hectáreas. Cuenta con gran cantidad de
infraestructura de redes, computadoras, routers, wi-fi, cableado, etc. Por lo que es
relativamente fácil tomar el control de alguna computadora dentro del campus, ya sea en una
oficina o en un laboratorio, o incluso lograr conectar una computadora particular a alguna de
las tantas bocas disponibles.
Debido a que no se pudo contar con acceso físico al campus universitario por una
cuestión de locación geográfica, se tuvo que buscar una alternativa para poder simular dichas
condiciones. Ante esta necesidad, se optó por configurar una Red Privada Virtual (VPN por
sus siglas en inglés) a un host perteneciente a la red, el cual se configuró a modo de servidor.
Este host está dentro de la banda subred correspondiente al Rectorado del Campus
(192.168.128.0/19), cuya dirección Ip es 192.168.172.98.
A su vez, se tendrá en modo cliente las computadoras personales en las cuales estará
desplegada la suite de herramientas necesarias para llevar a cabo el Test de Intrusión.
Aquí se hará una intromisión para explicar en qué consiste este tipo de red y cuales
son sus ventajas y usos posibles. Una VPN es una tecnología de red que se utiliza para
conectar una o más computadoras a una red privada utilizando Internet. Las empresas suelen
utilizar estas redes para que sus empleados, desde sus casas, hoteles, etc; puedan acceder a
39
recursos corporativos que, de otro modo, no podrían. Sin embargo, la habilidad para
conectarse de manera remota a una red es solo una de sus funciones.
En conjunto con lo anterior, una implementación correcta de esta tecnología permite
asegurar la confidencialidad e integridad de la información.
Como puede suponerse, a través de una VPN pasa información privada y confidencial
que en las manos equivocadas, podría resultar perjudicial y por lo tanto supone un riesgo en
la seguridad de la red. Esto se agrava aún más si el usuario en cuestión se conecta utilizando
una red Wi-Fi pública sin protección. Afortunadamente, este problema puede ser mitigado
cifrando los datos que se envían y reciben. Para poder lograr este objetivo, se pueden utilizar
los siguientes protocolos:
● IPsec (Internet Protocol Security): permite mejorar la seguridad a través de
algoritmos de cifrado robustos y un sistema de autenticación más exhaustivo. IPsec
posee dos métodos de encriptado, modo transporte y modo túnel. Asimismo,
soporta encriptado de 56 bit y 168 bit (triple DES).
● PPTP/MPPE: tecnología desarrollada por un consorcio formado por varias
empresas. PPTP soporta varios protocolos VPN con cifrado de 40 bit y 128 bit
utilizando el protocolo Microsoft Point to Point Encryption (MPPE). PPTP por sí
solo no cifra la información.
● L2TP/IPsec (L2TP sobre IPsec): tecnología capaz de proveer el nivel de protección
de IPsec sobre el protocolo de túnel L2TP. Al igual que PPTP, L2TP no cifra la
información por sí mismo.
De esta forma se utilizará una herramienta llamada OpenVPN, la cual permite
configurar una red privada para acceder de forma remota y segura, y así evitar grandes
problemas de logística y protección a la hora de realizar el Test de Intrusión.
Algunas de las ventajas principales de OpenVPN son la facilidad de uso, y el hecho
de que es gratuito y multiplataforma. Al ser multiplataforma esta tecnología está disponible
para multitud de sistemas operativos: Windows, Linux, Mac OS X, Android, etc.
Otra de las grandes ventajas de OpenVPN es que ofrece un fuerte cifrado y
protección de confidencialidad, logrando que el tráfico no pueda ser examinado en caso de
ser interceptado. En este caso utiliza un protocolo de seguridad personalizado que
implementa SSL/TLS para intercambios de claves. Es capaz de atravesar traductores de
dirección de red (NATs, por sus siglas en inglés) y firewalls.
40
Este protocolo consta de dos tipos de funcionamientos que proveen la emisión y
recepción de paquetes. Estas implementaciones llevan el nombre de TUN (encapsula IP, capa
3) y TAP (encapsula tramas ethernet, capa 2).
En este caso, se utilizará el controlador TUN que emula una red de punto a punto, y es
utilizado para crear túneles virtuales operando con el protocolo IP. De esta forma serán
encapsulados todos los paquetes que se transporten a través de él como datagramas TCP o
UDP y, a su vez, las computadoras que queden detrás de cada uno de los extremos del enlace
pertenecerán a subredes diferentes.
4.2. Sistema Operativo

Una vez definida la forma de conexión a la red, se debe proceder con la elección del
sistema operativo. Debido a las características que se mencionaron en el capítulo Estado del
Arte, a la experiencia que se contaba con sistemas Linux y luego de realizarse la
investigación correspondiente, se optó por la distribución Kali Linux.
Además de las ventajas técnicas, por su esencia de software libre se puede tener
acceso a múltiples distribuciones y herramientas de manera gratuita, y lo más importante, al
ser código abierto se tendrá mayor control sobre las acciones que se tomen durante la
auditoría, lo cual resulta extremadamente importante para que se resguarde la integridad del
sistema auditado.
Kali Linux es una reestructuración masiva de Backtrack 5, sin embargo, la diferencia
sustancial de ésta nueva distribución es que se cambia el entorno basado en Ubuntu por un
auténtico sistema Debian, específicamente en la distribución Debian Wheezy, lo cual ofrece
un abanico de posibilidades completamente nuevo, proporcionando compatibilidad a más de
300 herramientas para realizar labores de pentesting, cumpliendo los estándares y las
políticas de Debian, y siguiendo las mejores prácticas de uso en dicho entorno. Además, se
realizó una purificación de las herramientas de Backtrack que no funcionaban correctamente
o no cumplían con los estándares de desarrollo seguro y se las removió de Kali Linux.
Cuando se habla de desarrollo seguro se refiere a la creación de productos de software
que cumplan únicamente con las labores o fines para los cuales han sido diseñados y
desarrollados, y que a través de ellos no se pueda realizar otra actividad diferente, maliciosa o
que atente contra la seguridad del equipo donde se está ejecutando. Por ejemplo, no debe
generar desbordamiento de buffer o modificar un archivo del sistema sin que esto esté
41
declarado en los fines de la aplicación. Una de las ventajas del código abierto es poder
controlar estos aspectos, y como se mencionó antes, fue uno de los motivos por los cuales se
decidió elegir un sistema Linux.
Además, por las ventajas mencionadas acerca de trabajar en entornos virtuales en el
ámbito de auditorías de seguridad, y sumado a restricciones que se presentan en el hardware a
utilizar, se decidió instalar Kali Linux sobre una máquina virtual.
Para dicha virtualización se utilizará Virtual Box, ya que por medio de esta aplicación
es posible instalar sistemas operativos adicionales, conocidos como sistemas invitados, dentro
de otro sistema operativo anfitrión, cada uno con su propio ambiente virtual.
Una vez configurado el entorno de trabajo, ya se está en condiciones de avanzar en la
toma de decisiones acerca de la metodología a seguir para realizar el Test de Intrusión y de
esta forma dar comienzo a la auditoría de seguridad del Centro de Datos y Comunicaciones
de la UNICEN.
42
5. Metodología del Test de Intrusión
Como se mencionó en el capítulo Estado del Arte, existen varios estándares que
definen diversas metodologías para llevar a cabo un Test de Intrusión. Cada uno define una
serie de etapas en las cuales se divide la prueba y en cada una se plantean objetivos a cumplir
para poder seguir con las etapas siguientes.
La elección de la metodología va a depender de las características del sistema objetivo
que se desea auditar y de la experiencia previa del pentester.
El caso de estudio en el presente trabajo es una entidad educativa estatal, con una
distribución geográfica bastante particular de los distintos nodos de su red, donde el acceso
físico a la misma es relativamente fácil para cualquier persona que se encuentre dentro del
campus universitario.
Basado en lo mencionado previamente, en el análisis de los distintos estándares y en
el estudio de casos prácticos de Tests de Intrusión, se optó por la siguiente división de etapas:
5.1. Establecimiento de alcance y reglas de juego
Cuando se hace referencia a las reglas de juego se hace una comparación con las
reglas de cualquier actividad recreacional donde se imponen límites de acción, como podría
ser un juego de mesa. Donde las piezas tienen un determinado tipo de movimiento y cantidad
de desplazamientos, etcétera.
El caso del pentesting es similar, ya que al inicio de toda auditoría se debe llegar a un
acuerdo sobre los objetivos que el cliente desea alcanzar, los límites a los que se verá
expuesto el equipo de auditores, es decir, el ámbito de acción, ya que la información que
estará a su disposición será totalmente confidencial. Todo lo acordado deberá ser recogido en
un documento llamado NDA por sus siglas en inglés (non-disclosure agreement, o acuerdo
de confidencialidad en castellano). Este documento debe ser firmado por ambas partes donde
se declare la conformidad entre las mismas. Es importante que sea de esta manera ya que en
el caso de que alguna de las partes tenga alguna queja o reclamo en relación a las vías o
maneras que se están adoptando para realizar la prueba, siempre se pueda recurrir al contrato
para verificar que no se vulnera ninguna norma allí establecida.
43
Suele suceder que en esta etapa el cliente toma conciencia de los peligros a los que se
ve expuesta su organización, e incluso sobre la necesidad de realizar una auditoría de
seguridad cada cierto período de tiempo, atendiendo a las nuevas formas que van encontrando
los posibles atacantes para llegar a su objetivo.
Puede ocurrir que el cliente quiera delimitar el ámbito de la prueba, por lo que se
incorporan ciertas restricciones al test. Estas restricciones, siempre y cuando vayan por el
contrato, deben ser tomadas muy en cuenta por parte del auditor, ya que la información que
se maneja será confidencial.
5.2. Recolección de información
Esta es la primer etapa puramente práctica, donde el equipo de auditores hará uso de
las diversas técnicas como Footprinting, Fingerprinting, Google Hacking, entre otras, para
intentar obtener la mayor cantidad de información sobre la organización que se va a someter
al test.
Otras vías muy comunes de localizar información es en redes sociales (al día de hoy
en dichas redes hay mucha más información de la que debería o se desearía), Ingeniería
Social a los trabajadores de la empresa, o simplemente en blogs dedicados, donde se puede
encontrar información proveniente de personas que por curiosidad o con malas intenciones ya
han estado en la búsqueda de vulnerabilidades de la organización objetivo.
Cuando se centra en personas físicas algunos ejemplos de información que se puede
obtener de ellas son direcciones de correo electrónico, direcciones postales, información
personal, etcétera. Desde la perspectiva corporativa, la información que se buscará obtener
abarca direcciones IP, resolución de nombres DNS, y otros datos no tan técnicos como el
organigrama de la empresa, patrones de las direcciones de correo electrónico, áreas internas,
nombre de gerentes, etcétera
Cuanta más información se obtenga, más posibilidades de ejecutar un ataque exitoso
se tendrá.
Dentro de esta etapa se encuentran dos fases:
- Footprinting Externo: detalla el procedimiento para recolectar información de
forma externa a la organización. A su vez esta fase se encuentra estructurada
en dos fases más:
44
- Footprinting Activo: se destaca por interactuar directamente con la
infraestructura de la empresa objetivo mediante consultas al DNS, análisis de
cabeceras HTTP, enumeración de puertos y sus servicios, etcétera.
- Footprinting Pasivo: recurre a la consulta de la información previamente
indexada por motores de búsqueda, registros públicos, foros, etcétera.
- Footprinting Interno: se centra en las actividades que se pueden realizar una
vez que el atacante haya conseguido acceso parcial a la red interna, donde
intentará volver a conseguir la mayor cantidad de información posible, para
seguir escalando el ataque a otros equipos dentro de la organización.
5.3. Análisis de vulnerabilidades
Luego de que se obtenga toda la información disponible en Internet, y se utilicen las

técnicas adecuadas en la etapa de Recolección de Información, aún queda analizar y organizar
todos los resultados, y a partir de ellos se deriva el descubrimiento de huecos de seguridad,
con los cuales se podrán planificar distintos vectores de ataque.
Además, en esta etapa se realizará el escaneo de redes y puertos a partir de la
información recolectada previamente, como pueden ser las direcciones IPs y los sistemas
operativos utilizados.
También se buscará identificar los distintos servicios corriendo, y un mayor detalle
sobre los sistemas operativos y las aplicaciones, tipos y versiones de servidores, etcétera.
A través de los datos recogidos mediante los escaneos y de forma conjunta con los
recogidos en la fase anterior, se identificarán las vías de acción con más posibilidades de
éxito, conformándose de esta manera el mejor plan de acción, para poder acceder a la
información del sistema.
5.4. Explotación de vulnerabilidades
Esta probablemente sea la etapa que más entusiasmo le genera a los auditores.
Basándose en la información recopilada con anterioridad y fundamentándose en los
conocimientos adquiridos luego de numerosos análisis de vulnerabilidades, se logran superar
las barreras de seguridad que plantean las organizaciones dejando al descubierto las vías por
las cuales un atacante externo puede hacerse con el control del sistema víctima.
45
Sin embargo, en esta etapa también es posible caer en la cuenta de que hubo errores
en las etapas anteriores y se obtendrán los llamados falsos positivos. Esto no solamente
perjudicará en el tiempo utilizado sino que también podría afectar a la veracidad del proceso
que se ha empleado para realizar la recolección de información, con lo cual se pondrá en
riesgo el informe posterior que se le presentará al cliente.
Uno de los elementos más utilizados a la hora de querer tomar el control de un
sistema, es el uso de exploits. El significado de la palabra es aprovechar o explotar, lo cual
trasladándose al ámbito informático se podría concluir que se trata de un conjunto de
acciones, códigos o secuencias de comando con los cuales se quiere aprovechar o explotar
una vulnerabilidad de un sistema informático con el afán de conseguir un comportamiento
beneficioso para el atacante, o lo que es lo mismo, no deseado para la víctima.
Sin embargo, es verdad que un hacker puede lanzar todos los exploits que desee sin
importarle las consecuencias que con ello origine en la organización que está atacando, pero
el equipo de auditores dedicados al hacking ético no puede permitirse ese lujo, porque debe
asegurarse en todo momento de tener el control de las acciones que se estén realizando, por lo
que solamente debería ser lanzado si se dispone la certeza de que se obtendrá un resultado
positivo en la prueba. Es por ello que, aunque la automatización está muy bien vista para la
realización de labores de auditoría, en este caso no se considera una buena práctica, ya que el
uso de herramientas para realizar el lanzamiento automatizado e indiscriminado de exploits,
aunque resulta beneficioso en tiempo, casi nunca posee el completo conocimiento de lo que
realiza cada uno de los exploits y podría generar más daños que beneficios en el sistema
testeado.
Los frameworks más populares para la utilización de exploits son: Metasploit,
Immunity Canvas y Core Impact. El primero se encuentra en el Top Ten de herramientas más
utilizadas para labores de este tipo, y es el que se utilizará en el presente trabajo debido a la
gran calidad que posee su versión gratuita.
5.5. Post explotación del sistema
Una vez logrado el acceso total o parcial al sistema víctima, es imprescindible intentar
mantenerlo en el tiempo. ¿Por qué es importante? Porque es lo que un atacante real haría, no
se conformaría con acceder una sola vez si puede hacerlo en el momento que lo desee.
46
Además, es muy probable que un atacante utilice los equipos de la red que ya ha
logrado controlar para intentar hacerse con el control de nuevos equipos de mayor
importancia dentro de la red, e incluso así, poder escalar permisos.
Esta técnica, por la cual se va obteniendo acceso a los distintos equipos dentro de una
red se conoce habitualmente como pivoteo.
Por último se intentará dejar un backdoor (puerta trasera) para poder ingresar al
sistema cuando se desee sin tener que perder tiempo volviendo a aplicar las técnicas de
hacking que se utilizaron en un primer momento para acceder al sistema.
5.6. Generación de informes
La confección de informes es una parte de fundamental importancia dentro del

proceso del test de intrusión, ya que aquí se informa al cliente sobre cada una de las acciones
y pruebas que se han realizado y los resultados que se han obtenido en cada una de ellas,
documentando todo con capturas de pantalla, recopilación de rutas donde se han encontrado
parámetros vulnerables, etcétera.
Entre toda la información que se comente en el documento final de la auditoría se
deben incluir cada una de las tareas que se ha realizado y todas las técnicas y herramientas
utilizadas, y las formas en que han sido utilizadas, además del tipo de vulnerabilidades que se
ha descubierto con esa herramienta y el nivel de gravedad que supone para la seguridad de la
organización.
A su vez, cada acción (escaneos, análisis, explotaciones, etc) debe de ser
documentada tanto antes de realizarse (explicando su utilidad y tipos de resultados
esperados), como también posteriormente con sus resultados junto a las conclusiones que
pueden obtenerse de ellos.
Se pueden tomar diferentes criterios para presentar los informes o reportes de trabajo
realizados junto con los resultados obtenidos. Se generarán dos informes por separados, los
cuales serán entregados a la autoridad designada al Centro de Datos y Comunicaciones de la
UNICEN. Estos informes serán el técnico y el ejecutivo.
En el informe técnico se recogerá la información con un gran nivel de detalle, es
decir, la lista de vulnerabilidades y posibles soluciones que aportará el equipo de auditores y
47
que va a ser leído por profesionales que, al interpretar los documentos, van a buscar las
soluciones adecuadas para paliar las deficiencias encontradas.
En cambio, en el informe ejecutivo se debe reportar el mismo número de
vulnerabilidades que en el informe anterior, pero sin entrar demasiado en detalle para que se
entiendan claramente los riesgos existentes en la organización. Todo esto complementado a
una lista de recomendaciones, que aunque no tengan carácter técnico haga entender al cliente
la necesidad de subsanar los fallos si lo que se desea es conservar los intereses de la
organización.
48
6. Fase 1: Establecimiento de alcance y reglas de juego
Si bien, en todas las auditorías de seguridad se firman contratos de confidencialidad, o
al menos deberían firmarse, este es un caso particular ya que no es realizada por auditores
profesionales, la entidad a ser auditada no es una empresa privada, y la relación entre
auditores y auditados no es comercial en la que una parte presta un servicio a la otra a cambio
de un pago de dinero.
Debido a lo mencionado, es que se realizó un Acuerdo de Confidencialidad y No
Divulgación de Información aplicable al caso en particular. Dicho acuerdo, fue armado por
los tesistas y luego validado, junto con las modificaciones correspondientes, por un abogado
de la Universidad Nacional del Centro.
Una vez se tuvo el acuerdo de confidencialidad terminado, se reunieron todas las
partes involucradas para firmarlo. En esta reunión, además de los auditores, estuvieron
presentes el Magister Claudio Aciti (Tutor de Tesis), el Ingeniero Martín Bradaschia (Tutor
de Tesis y encargado del Centro de Datos y Comunicaciones) y el Ingeniero Hernán Cobo
(Coordinador de Informática de UNICEN).
Lenguaje legal técnico de lado, en dicho documento se tratan 3 tópicos principales:
1- Confidencialidad: los auditores se comprometen a mantener la
confidencialidad de toda la información, ya sea de la recaudada como parte del
proceso de la auditoría o la provista por parte de los representantes del sistema
auditado.
2- Integridad: se debe mantener en todo momento la integridad de los datos
del sistema auditado. Con esto se quiere decir que no se puede eliminar, dañar,
modificar o alterar cualquier información, sea o no confidencial.
3- Duración: establece el tiempo durante el cual se debe mantener vigente el
cumplimiento de los ítems anteriormente mencionados.
Además, se establecen 3 tópicos más, referidos específicamente a establecer las pautas
a seguir en caso de no cumplir con lo establecido en dicho acuerdo. Estos establecen la
Indemnización, la Jurisdicción y Competencia, y los Domicilios Legales.
El Acuerdo de Confidencialidad y No Divulgación de Información se encuentra en el
Anexo I del presente informe.
49
7. Fase 2: Recolección de Información
La primer fase práctica del Test de Intrusión se centra en la recolección de la mayor
cantidad de información posible sobre el sistema a auditar, tanto de sus componentes de
software como de hardware, e incluso del personal de la entidad. Esta fase, también conocida
como Information Gathering, es el paso más crítico de una prueba de seguridad, debido a que
las fases subsiguientes van a estar basadas en la información con la que se cuente una vez
finalizada la misma. Si la información obtenida no es verídica podemos caer en falsos
positivos, e incluso llegar a callejones sin salida que harán que debamos volver sobre
nuestros pasos, con la pérdida de tiempo y esfuerzo que esto conlleva.
Esta tarea puede llevarse a cabo de muchas maneras diferentes. En esta ocasión se
utilizará el planeamiento propuesto por el Penetration Testing Execution Standard [PTE09] y
la Guía Inteco de Seguridad sobre Information Gathering [Feb11]. Este planeamiento se
divide en 2 etapas: External Footprinting e Internal Footprinting.
La primera consiste en obtener información de forma externa a la organización, ya sea
porque es pública intencionalmente o por error, mientras que la segunda consiste en realizar
estas búsquedas de información desde dentro de la red a la cual se desea realizar el Test de
Intrusión.
7.1. Objetivos principales
Más allá del seguimiento de una metodología y la utilización de ciertas técnicas

específicas, las cuales serán explicadas en detalle más adelante, se han planteado una serie de
objetivos a realizar. Estos buscan asegurar la obtención de información necesaria para poder
continuar con las siguientes etapas de la auditoría. Estos objetivos son los siguientes:
1. Recolectar información pública
2. Identificar host activos
3. Encontrar puertos abiertos y puntos de accesos
4. Fingerprinting (identificar sistemas operativos, aplicaciones y versiones de software
utilizados en los hosts)
5. Encontrar servidores publicados en internet
50
6. Encontrar correos electrónicos e información de usuarios que pueda servir para
planear un ataque de Ingeniería Social
7. Mapeo de la red interna
7.2. Footprinting Externo
Dentro de esta recolección de información de manera externa a la red de la entidad

que se desea auditar, se encuentran dos clasificaciones. Por un lado se agrupan las técnicas y
herramientas que no interactúan de manera directa con la red a auditar, es decir, las menos
invasivas. Estas forman parte del Footprinting Pasivo. Y por otro lado, existen las técnicas y
herramientas más invasivas, que puede dejar rastros que ayuden a identificar al atacante, o al
menos hacer notorio un intento de ataque. Estas forman parte del Footprinting Activo.
7.2.1. Footprinting Externo Pasivo
Aquí se hará uso de una combinación de técnicas y herramientas para obtener, de

forma no invasiva, información pública sobre el dominio en el cual se realiza el Test de
Intrusión.
Para comenzar se hará incapié en el sitio web www.unicen.edu.ar ya que a la hora de
interactuar con la universidad de manera externa. este dominio es el más intuitivo. Además,
por cuestiones preacordadas con los encargados del Centro de Cómputos y Comunicación de
la UNICEN, se analizarán los subdominios www.exa.unicen.edu.ar y www.rec.unicen.edu.ar.
El primer objetivo es conocer las direcciones IP detrás de estos 3 DNS. Utilizando
simplemente el comando ping seguido de estas direcciones se consiguen las siguientes IPs:
Unicen: 131.221.0.3
Rectorado: 131.221.0.4
A partir de estas IPs obtenidas se hará uso de diversas herramientas que permitirán
recolectar la información necesaria para las próximas etapas.
51
7.2.1.1. Whois
7.2.1.1.1. Introducción
El comando whois es un protocolo TCP basado en petición/respuesta utilizado para

efectuar consultas a una base de datos permitiendo determinar el propietario de un nombre de
dominio o dirección IP pública.
7.2.1.1.2. Ejecución
En la figura 7-1 se puede observar el resultado de ejecutar el comando whois sobre la

IP de la Unicen (131.221.0.3) desde la consola.
Figura 7-1: Respuesta del comando whois para la Ip 131.221.0.3

En la respuesta se obtiene información del propietario, datos de contacto, incluyendo
número de teléfono y direcciones. Esta información está disponible públicamente en Internet.
52
Además, whois se puede ejecutar desde múltiples sitios web, obteniendo la
información de manera más detallada y amigable. Por ejemplo, en las figuras 7-2, 7-3 y 7-4
se puede ver una consulta para la misma IP desde la web http://whois.domaintools.com/.
Figura 7-2: Ejecución de whois para la Ip 131.221.0.3 desde http://whois.domaintools.com
Figura 7-3: Fragmento de respuesta del whois para la Ip 131.221.0.3 desde

http://whois.domaintools.com
53
Figura 7-4: Fragmento de respuesta del whois para la Ip 131.221.0.3 desde
http://whois.domaintools.com
Utilizando estas herramientas web la información presentada no solo es más
amigable, sino también, es más amplia. Esto se debe a que, por lo general, tanto las
herramientas web como las aplicaciones que simplifican el camino para obtener la
información, no suelen ser minimalistas. Cuando estas herramientas trabajan sobre una base
de datos, como es el caso del whois, son una ventaja. Pero cuando actúan directamente sobre
el sistema auditado pueden ser un problema, ya que mientras más invasivamente se
comporten, más probabilidades de ser descubiertos tenemos.
En este caso, a través de una búsqueda IP inversa, se obtuvieron los sitios web que
utilizan esta IP. Esto sirve como otro punto de partida para continuar buscando información.
En las figuras 7-5 y 7-6 se observa el resultado de utilizar esta herramienta sobre los
dominios encontrados.
Figura 7-5: Ejecución de whois para el dominio e-alternativas.edu.ar
54
Figura 7-6: Ejecución de whois para el dominio unicen.edu.ar
Aquí se observa cómo, continuando con ésta política no minimalista, se obtiene

información acerca de qué sistema operativo, tipo y versión están corriendo en el servidor
(Apache 2.2.16 Debian).
7.2.1.2. Google Hacking
Es una técnica que utiliza operadores para filtrar información en el buscador de

Google (aunque también se puede realizar en otros buscadores como Yahoo, Bing, etc.). Es
una herramienta utilizada por gran parte de la sociedad mundial, pero que muy pocos conocen
o son conscientes de su verdadero potencial.
55
En este caso se hará uso de los operadores avanzados de Google en su motor de
búsqueda para localizar cadenas específicas de texto dentro de los resultados de búsqueda.
A continuación se describen algunos de los operadores más útiles disponibles para
aplicar filtros a nuestras búsquedas:
site: Este operador filtra por el dominio. Si se desea buscar todo lo relacionado con el
dominio unicen.edu.ar, en Google se realizaría la siguiente consulta “site:unicen.edu.ar”.
Intitle y allintitle: Busca la cadena introducida a continuación del operador en el título de las
páginas web indexadas. Dentro de Google Groups buscará en el título de los mensajes.
Dentro de Google Code buscará en los mensajes dentro de los proyectos (issues). La
diferencia entre intitle y allintitle es:
- intitle:”index of” “backup”: busca “index of” en el título pero no “backup”.
- allintitle: “index of” “backup”: busca todas las cadenas en el título.
inurl y allinurl: Busca la cadena introducida a continuación del operador en el enlace
indexado por el robot de Google. La diferencia entre el operador con el prefijo all y sin él es
la misma que en el operador anterior pero aplicado a las urls.
filetype: Busca documentos con la extensión introducida tras el operador avanzado.
allintext: Busca la cadena introducida en el texto de la página web.
link: Este operador busca páginas que enlazan a la página introducida a continuación
del operador.
daterange: Se limita el resultado de la búsqueda a las fechas publicadas en
determinado rango horario.
cache: Busca el contenido en la caché de google.
info: Google ofrece información del sitio, como la caché, páginas similares a la
introducida, páginas que tengan un enlace a esta, páginas indexadas de ese dominio y páginas
que contengan la cadena introducida.
Estos operadores no se restringen únicamente al contexto web y alguno de los
operadores pueden ser utilizados en Google Images (indexa imágenes), Google Code
(proyectos de software), Google Groups, etcétera.
Hay servidores con búsquedas para ver cómo usarlos. La herramienta SEAT permite
automatizar estas búsquedas utilizando las bases de datos de GHDB, NIKTO, GSDB,
WMAP, URLCHK, NESTEA, y los motores de búsqueda de Google, Yahoo, MSN,
AltaVista, AOL y DMOZ.
56
El abanico de posibilidades es inmenso, y es una técnica que requiere de creatividad
por parte del atacante o auditor.
Se realizó la búsqueda site:unicen.edu.ar “index of” para encontrar servidores web

que permiten la navegación por los directorios del servidor a modo de carpeta. Y se
encontraron varios e-mail, como por ejemplo:
From gabrielacalcaterra en arnet.com.ar Thu Apr 11 16:00:09 2013
From: gabrielacalcaterra en arnet.com.ar (Gabriela Calcaterra)
Date: Thu, 11 Apr 2013 16:00:09 -0300
Subject: [Novedades DerUnicen] eleeciones Director y Secretario Departamento
Message-ID: <[email protected]>
Estimados miembros del Departamento de Derecho Privado,

Debido a algunas consultas que hemos recibido, cumplo en informarles que
todos los integrantes de las respectivas c·tedras que integran el
departamento, esto es, profesores, auxiliares, adscriptos y ayudantes
alumnos tienen derecho y deber de asistir a las reuniones, en especial a la
del prÛximo martes 16 de abril 2013.
Ello no obstante, sÛlo tienen derecho de voz y voto quienes poseen cargo
docentes y auxiliares, es decir, profesores titulares, adjuntos, JTP y
auxiliares diplomados, no asÌ los adscriptos ni los ayudantes alumnos cuya
presencia es sin embargo, muy importante para todos.
Reiterando nuestra expectativa de que podamos estar todos presentes en este
importante acto, les ruego que transmitan esta convocatoria a todos los
integrantes de sus respectivas c·tedras y los saludo cordialmente a travÈs
de Èste, que es mi ˙ltimo mensaje como directora del departamento. Por ello,
aprovecho para agradecer a todos ustedes en nombre propio de la Dra. Mariana
Ronchetti, su participaciÛn y camaraderÌa y el compromiso con que han
acompaÒado cada una de nuestras iniciativas a lo largo de estos aÒos de
tanto crecimiento institucional para nuestro departamento y para nuestra
querida facultad,
Hasta el martes,
Gabriela
57
Además se encontraron los siguientes links para explorar carpetas dentro del servidor.
Si se observa la parte inferior se puede apreciar información sobre el tipo y versión del
servidor, y el puerto por el que se accede.
Figura 7-7: Directorio interno encontrado desde búsqueda en Google
Figura 7-8: Archivos privados encontrados desde búsqueda en Google
Figura 7-9: Directorio xgap perteneciente a unicen encontrados desde búsqueda en Google
58
Figura 7-10: Directorio pipermail perteneciente a unicen encontrados desde búsqueda en Google
Otra búsqueda realizada fue: site:unicen.edu.ar filetype:pdf “bradaschia”. Aquí se

intentó encontrar todos los pdfs que incluyan “bradaschia” dentro del dominio de la
universidad. Como ya ha sido mencionado, esta técnica requiere de creatividad, por lo que
utilizar el nombre del encargado del Centro de Datos y Comunicación obtenido previamente
a través del protocolo whois, es una buena idea para comenzar a investigar.
Otros filetypes posibles son: xls, ppt, doc, vsd, dia.
Figura 7-11: Búsqueda dentro del dominino unicen.edu.ar para archivos pdf que contengan la palabra
“bradaschia”
59
Como se puede observar, se logró obtener un padrón de docentes de la universidad
junto con sus DNI. Si bien esta es información intencionalmente pública, es de valiosa
información para un atacante. Puede ser utilizada, por ejemplo, para un ataque de Ingeniería
Social. Además se puede utilizar para nutrir un diccionario que luego pueda ser usado para
ataques a contraseñas.
Figura 7-12: Primer resultado de la búsqueda realizada en 7-11
Un ejemplo sobre la utilidad de Google hacking puede ser el siguiente caso. En la

figura 7-13 se puede observar como la ruta /sites/default está bloqueada para accesos
externos.
60
Figura 7-13: Ruta bloqueada para accesos externos
De todas formas al buscar site:unicen.edu.ar filetype:pdf “users” se logra acceder a

un pdf que se encuentra dentro de esa ruta. Este archivo contiene información de usuarios y
pertenece a la Secretaría de Administración (figura 7-14). Esto puede estar relacionado con
fallas en la seguridad de los métodos utilizados para almacenar archivos.
Figura 7-14: Pdf con lista de usuarios perteneciente a la Secretaría de Administración
61
La búsqueda site:unicen.edu.ar administrador admin arrojó los siguientes resultados:
http://listas.rec.unicen.edu.ar/cgi-bin/mailman/admin
http://listas.rec.unicen.edu.ar/cgi-bin/mailman/listinfo
Dentro de esos enlaces se encontró información sobre listas de emails como se puede
ver en la figura 7-15.
Figura 7-15: Información sobre listados de emails
site:unicen.edu.ar error|warning: encuentra errores en la página que pueden mostrar

información de la plataforma tecnológica e incluso fallas de seguridad.
Figura 7-16: JBoss log
62
site:unicen.edu.ar login|logon: busca todos los dominios donde exista inicio de
sesión. Esto es útil para luego aplicar técnicas como Cross Site Scripting (XSS), fishing,
ataques a contraseñas, etcétera. Algunos de los resultados son los siguientes:
https://cas.rec.unicen.edu.ar:8443/cas/login
http://niecyt.exa.unicen.edu.ar/es/live/logon.html;jsessionid=cthgdfn5bbq9b
http://aula.fch.unicen.edu.ar/login/index.php
http://www.unicen.edu.ar/pasantias/code/login.php
http://www.ridaa.unicen.edu.ar/examples/jsp/security/protected/index.jsp
http://www.unicen.edu.ar/user
http://mail.vet.unicen.edu.ar/cgi-bin/openwebmail/openwebmail.pl
http://ead.fio.unicen.edu.ar/moodle2/login/forgot_password.php
http://apps.econ.unicen.edu.ar/wordpress/wp-login.php?action=lostpassword
7.2.1.3. Robtex
Robtex es un motor de búsqueda que permite realizar ciertas partes del procedimiento
activo de Footprinting de manera pasiva, es decir, en lugar de preguntar directamente a los
servidores la información sobre sus dominios, subdominios, servidores dns, etc, permite
obtener dicha información sin dejar rastros en el objetivo a través de una sencilla consulta
web.
En las siguientes imágenes se puede observar el resultado de utilizar esta herramienta

sobre los dominios de unicen y el rectorado respectivamente:
63
Figura 7-17: Analisis de Robtex para unicen.edu.ar
Figura 7-18: Respuesta de Robtex con los host dentro del dominio unicen.edu.ar
64
Figura 7-19: Grafo de red generado por Robtex para el dominio unicen.edu.ar
Figura 7-20: Analisis de Robtex para rec.unicen.edu.ar
65
Figura 7-21: Respuesta de Robtex con los host dentro del dominio rec.unicen.edu.ar
Figura 7-22: Grafo de red generado por Robtex para el dominio unicen.edu.ar
Estos son tan solo algunos de los datos que se puede obtener utilizando Robtex. Como
se puede observar, los resultados son extremadamente gráficos y permiten hacer un análisis
profundo de los dominios, hasta incluso poder realizar mapeos de la red.
66
7.2.1.4. SHODAN
Shodan es otro motor de búsqueda que le permite al usuario encontrar tipos

específicos de equipos (routers, servidores, etc.) conectados a Internet a través de una
variedad de filtros. También puede definirse como un motor de búsqueda de banners de
servicios, que son metadatos que el servidor envía de vuelta al cliente. Esta información
puede hacer referencia sobre el software de servidor, opciones que admite el servicio,
mensajes de bienvenida o cualquier otra cosa que el cliente pueda saber antes de interactuar
con el servidor.
Shodan recoge datos sobre todo en los servidores web (HTTP puerto 80), pero
también hay algunos datos de FTP (21), SSH (22) Telnet (23), SNMP (161) y SIP (5060).
A continuación se realizó una búsqueda con esta herramienta para la dirección ip

131.221.0.3, correspondiente a la UNICEN.
En la figura 7-23 puede apreciarse la información básica de sobre esta Ip, como lo
puede ser la organización a la que pertenece y el país donde se encuentra, entre otras.
Figura 7-23: Información genera de Shodanl sobre Ip 131.221.0.3
Si se continúan analizando los resultados, la figura 7-24 especifica la información

correspondiente al puerto 21. Aquí pueden verse valores como datos del servicio que está
expuesto, que en este caso es FTP y el protocolo de transferencia utilizado (TCP).
67
Figura 7-24: Información de Shodan sobre el puerto 21 de la Ip 131.221.0.3
La figura 7-25 indica que el puerto 22 está abierto, contiene el servicio OpenSSH
versión 5.5p1 y utiliza el sistema operativo Debian 6. Adicionalmente se proveen otros datos
como los posibles algoritmos de encriptación, su llave pública, etc.
68
Por último, también se consigue información sobre el puerto 80(http). Para este caso
(figura 7-26), se consiguió información útil como lo puede ser el servidor que se expone
(Apache 2.2.16), el sistema operativo (Debian) y la versión de Php utilizada (5.3.3-7).
69
7.2.1.5. Maltego
Es una programa que recopila información de internet y la representa de forma gráfica

para que sea sencilla de analizar.
La ventaja de utilizar Maltego es que permite focalizar, en caso de desearse, la
recolección de información en base a algún aspecto deseado (topología de la red, ingeniería
social, etc). Estás búsquedas particulares son denominadas transformaciones, y sus resultados
van conformando de forma incremental un grafo visual, en el que cada nodo es un valor
encontrado y consta de un valor y un símbolo que ayuda a diferenciar el tipo de dato
(dominio, usuario, dirección ip, servidor, etc).
Lo primero que se debe hacer es crear una entidad del tipo “dominio” e introducir el
dominio de la UNICEN (www.unicen.edu.ar). Luego se aplica la primer transformación
donde se parte del DNS y se buscan datos del dominio. De toda la información devuelta, se
hará hincapié en la IP del dominio la cual es 131.221.0.3.
70
Figura 7-27: Primera transformación de Maltego partiendo de www.unicen.edu.ar
Las transformaciones aplicadas en base a esta dirección desencadenaron un ciclo de

información en la que siempre se remonta al comienzo. Entonces se realizó una búsqueda a
partir de los 2 NS Records encontrados por el dominio.
Figura 7-28: NS Records encontrados por Maltego a partir del dominio unicen.edu.ar
Realizando todas las transformaciones disponibles sobre estos NS Records se obtuvo

información sobre qué dominios están incluidos en cada uno de ellos.
71
Figura 7-29: Resultado obtenido luego de aplicar todas las transformaciones de los NS Records con Maltego
La última transformación que se decidió realizar fue sobre las direcciones IP

encontradas (131.221.0.1 y 131.221.0.2).
Figura 7-30: Resultado obtenido luego de aplicar todas las transformaciones de las direcciones Ip
131.221.1.0.1-2 con Maltego
Las transformaciones realizadas sobre los siguientes datos no dieron ninguna

profundidad de información a la que no se haya llegado con otras herramientas.
En conclusión, si bien maltego consta de numerosas transformaciones. Se obtuvo la
misma información que aplicando una búsqueda manual con las técnicas antes nombradas.
72
La ventaja de esta herramienta es la rapidez con la que se encontraron estos resultados
y la presentación visual de los mismos. La desventaja es la falta de posibilidad de aplicar
búsquedas creativas o explotar distintos ángulos o acercamientos. Esto hizo que rápidamente
se vuelva al mismo lugar del que se partió, o se llegó siempre a los mismos resultados por
más que se exploren caminos distintos.
7.2.2. Footprinting Externo Activo
Hasta este punto todas las distintas herramientas y técnicas que se utilizaron, son
consideradas como pasivas ya que no se realiza ningún tipo de escaneo o contacto con la
máquina objetivo, pero de todas formas se puede construir un mapa del mismo sin interactuar
con él.
La otra categoría dentro de Footprinting es la activa. Esta misma, como su nombre lo
indica, consiste en la identificación activa de objetivos mediante tareas tales como escaneo de
puertos, identificación de servicios, identificación de sistemas operativos, etc.
7.2.2.1. Netcat
Es una herramienta de red que permite a través de intérprete de comandos y con una
sintaxis sencilla abrir puertos TCP/UDP en un HOST (quedando netcat a la escucha), asociar
una shell a un puerto en concreto (para conectarse por ejemplo a MS-DOS o al intérprete
bash de Linux remotamente) y forzar conexiones UDP/TCP (útil por ejemplo para realizar
rastreos de puertos o realizar transferencias de archivos bit a bit entre dos equipos). En este
caso se utilizó para realizar un escaneo de puertos, desde el 01 al 999 sobre el dominio de la
UNICEN.
El comando ejecutado fue “nc -zv www.unicen.edu.ar 1-999”. En donde nc invoca a
la herramienta Netcat, la opción “z” se utiliza para reportar puertos abiertos, la opción “v” es
para incrementar el nivel de verbosidad en la salida visual del escaneo, www.unicen.edu.ar es
el dominio a escanear y 1-999 el rango de puertos. Para este caso se encontró que dicho
dominio cuenta con los puertos 80 (http) y 21(ftp) abiertos.
73
En la figura 7-31 se puede apreciar el mismo escaneo, pero esta vez para facilitar su
comprensión, se limitó la operación solamente al puerto 80.
Figura 7-31: Scan con la herramienta Netcat al puerto 80 del dominio perteneciente a la UNICEN
7.2.2.2. Whatweb
Es una herramienta escrita en Ruby que permite escanear e identificar instalaciones de

CMS, blogs, foros, etc, en un servidor remoto. Cuenta con cientos de plugins y se puede
ejecutar tanto en modo pasivo como en modo activo (el modo activo brinda más información
a costa de ser menos sigiloso).
La utilización de whatweb es considerada parte de la técnica de fingerprinting de
aplicaciones. Mediante ella se obtendrá información de servidores, sistemas operativos, CMS,
etc.
Al ejecutar el comando whatweb para el dominio www.unicen.edu.ar con la opción v

para obtener toda la información posible, se obtuvieron los resultados que se aprecian en la
figura 7-32.
Esta información si bien es la misma que ya se ha conseguido antes, está presentada
de una forma diferente. Aquellos datos que son considerados de mayor relevancia se
encuentran resaltados en colores llamativos, esto le facilita al usuario para no dejar pasar por
alto información útil.
Adicionalmente, estos resultados se encuentran catalogados y por cada uno se da unas
breve explicaciones técnicas junto a información específica como número de versiones entre
otras cosas.
74
Figura 7-32: Resultado de la herramienta Whatweb para el DNS www.unicen.edu.ar
Por lo tanto, si bien la información puede conseguirse complementando herramientas

como whois, con motores de búsqueda tales como el caso de Shodan. Esta herramienta nos
permite unificar todo en una sola operación y obtener resultados de forma entendible y junto
a una breve explicación de ellos para potenciar su utilidad.
75
7.2.2.3. BlindElephant
Esta herramienta, complementa la técnica de fingerprinting y permite indagar más

profundamente sobre los resultados obtenidos con Whatweb, ya que ayuda a obtener más
información sobre las características y versiones de las aplicaciones web instaladas.
En la figura 7-33 se puede apreciar el resultado de investigar la aplicación Drupal

sobre el dominio correspondiente a la UNICEN. Esta aplicación es un CMS de código
abierto, que como se vió en los resultados de Whatweb, probablemente se encuentre instalada
en el servidor. Según el resultado, es altamente probable que la versión de Drupal instalada
en el servidor es la 6.24.
Figura 7-33: Resultado de Blind Elephant para aplicaciones drupal en el dominio www.unicen.edu.ar
76
7.3. Footprinting Interno
Dentro del Footprinting Interno se ha optado por realizar tareas catalogadas como
activas. Esta denominación nace del grado de intrusión que estas tienen sobre el sistema. Las
herramientas que se describirán a continuación dejan un mayor nivel de rastros e indicios, los
cuales pueden levantar alertas ante los administradores de redes, sobre escanemos masivos de
host y puertos, o paquetes enviados con comportamientos pocos comunes.
7.3.1. Footprinting Interno Activo
7.3.1.1. Nmap
Es un programa de código abierto que sirve para efectuar rastreo de puertos. Esta
herramienta fue creada originalmente para Linux aunque actualmente es multiplataforma y se
usa para evaluar la seguridad de sistemas informáticos, así como para descubrir servicios o
servidores en una red informática. Para ello Nmap envía unos paquetes definidos a otros
equipos y analiza sus respuestas.
Este software posee varias funciones para sondear redes de computadores, incluyendo
detección de equipos, servicios y sistemas operativos. Estas funciones son extensibles
mediante el uso de scripts para proveer servicios de detección avanzados, detección de
vulnerabilidades y otras aplicaciones. Además, durante un escaneo, es capaz de adaptarse a
las condiciones de la red incluyendo latencia y congestión de la misma. Todos los scripts
existentes se encuentran en https://nmap.org/nsedoc/. Como se podrá observar es una
herramienta extremadamente amplia.
Para comenzar se utilizarán las tablas con las divisiones internas de IPs de la
universidad que obtenidas de la wiki del rectorado en la etapa de Footprinting Externo
(utilizando Google Hacking) mediante el siguiente enlace:
- http://www.rec.unicen.edu.ar/wiki/doku.php?id=informatica:red:distribucion_ip
77
Figura 7-34: Distribución de bandas Ip dentro del Centro de Datos y Comunicaciones
Figura 7-35: Distribución de bandas Ip dentro del Centro de Datos y Comunicaciones
78
Sobre esta información, se utilizarán las siguientes bandas de direcciones Ip:
- Unicen: 10.254.0.0/24
- Rectorado Data Center: 10.254.1.0/24
A continuación se muestra un ejemplo detallado sobre su uso sobre la banda de
direcciones Ips pertenecientes al Rectorado. En las etapas posteriores se continuará
demostrando lo efectiva y útil que resulta ser esta herramienta en la auditoría.
Se realizó un escaneo de la red para encontrar hosts activos dentro de la misma. En la
figura 7-36 se puede apreciar el comando ingresado en la terminal de Kali Linux.
Figura 7-36: Escaneo de nmap para la banda del Rectorado
Como se puede apreciar, el comienzo del comando es “nmap” indicando que

utilizaremos dicha herramienta.
Luego se encuentra la opción “-oG” para que la salida esté en un formato apto para
luego aplicar filtros con grep (formato grepeable).
A continuación se indica el rango de IPs correspondientes al rectorado, siguiendo el
valor indicado en la figura 7-34, la banda es “10.254.1.0-255”. Este rango comienza con la ip
10.254.1.0 y finaliza en 10.254.1.0.255.
79
Luego se puede indicar qué puertos de cada host se desea escanear. Si no se
especifican, el escaneo se realizará en una cantidad predeterminada de puertos lo cual no solo
conlleva un alto costo temporal sino que además dejará rastros notorios en la red. Entonces,
con la opción “-p”, se definen los puertos que se desean escanear.
Al escanear una combinación de protocolos (por ejemplo, TCP y UDP), se puede
especificar un protocolo particular, precediendo los números de puerto por T: para TCP, U:
para UDP, S: para SCTP o P: para el protocolo IP. El calificador dura hasta que se
especifique uno nuevo. Por ejemplo, el argumento -p U: 53,111,137, T: 21-25,80,139,8080
escanea tanto los puertos UDP 53, 111, y 137, como también los puertos TCP 21, 22, 23, 24,
25, 80, 139 y 8080. Hay que tener en cuenta que para escanear ambas UDP y TCP, se debe
especificar “-sU” y al menos un tipo de escaneo TCP (como -sS, -sF, o -sT). Si no se declara
calificador de protocolo, los números de puerto se añaden a todas las listas de protocolo.
Los puertos también pueden ser especificados por el nombre de acuerdo a lo que el
puerto hace referencia en los nmap-services. Incluso se pueden utilizar comodines como * y ?
con los nombres. Por ejemplo, para escanear FTP y todos los puertos cuyos nombres
comienzan con "http", se debe utilizar -p FTP, HTTP *.
Para este caso en particular se optó por la opción “-F”, la cual especifica un número
menor de puertos que los predeterminados. Normalmente Nmap utiliza los 1.000 puertos más
comunes para cada protocolo de escaneado. Con -F, esto se reduce a 100.
Por último, la opción “-v” (verbose) es definida para obtener la salida de los
resultados del scan y adicionalmente se agrega otra “v” para indicar que se desea información
extra (extra verbose).
Si bien la salida obtenida contiene una gran cantidad de información. La misma es
demasiado grande y solo queda plasmada dentro de la terminal, por lo tanto, en el momento
que dicha terminal sea cerrada, estos resultados se perderán. Ante esto se agregó una última
parte al comando, la cual vuelca la salida de la operación anterior en un archivo al cual
llamaremos “scan_rectorado”.
Figura 7-37: Escaneo de nmap para la banda del Rectorado con volcado al archivo scan_rectorado
80
Este archivo contendrá líneas como la siguiente, para aquellos hosts que se encuentren
caídos:
- Host: 10.254.1.185 () Status: Down
Y además contendrá líneas como las siguientes para aquellos host que están
levantados:
- Host: 10.254.1.1 () Status: Up
- Host: 10.254.1.1() Ports:22/open/tcp//ssh///, 25/open/tcp//smtp///,
135/filtered/tcp//msrpc///, 179/open/tcp//bgp///, 993/filtered/tcp//imaps///,
1720/filtered/tcp//h323q931///, 5666/open/tcp//nrpe/// Ignored State: closed (93)
En base a esto se puede concluir que el host 10.254.1.1 está levantado. A esta
información se le agrega el conocimiento de que dicha computadora consta de los puertos 22,
25, 135, 179, 993, 1720 y 5666 abiertos junto a la información de qué protocolo tiene cada
puerto y qué funcionalidad cumplen. Como en el caso del puerto 22 que está abierto, tiene el
protocolo TCP y sirve como puerto SSH.
En base a este archivo, en formato “grepeable”, se puede correr el siguiente comando:
Figura 7-38: Formateo de archivo generado en la figura 7-37, filtrado sólo los hosts activos
Primero se ejecuta “cat scan_rectorado” para generar una salida con la totalidad del
contenido del archivo, y como el formato dicha salida “grepeable”, se realiza un grep
(comando de filtrado) por la expresión Up. Esta última operación retornará todas las líneas
en donde se encuentra dicha expresión. Un fragmento de ejemplo puede ser el siguiente:
Host: 10.254.1.224 () Status: Up
Host: 10.254.1.225 () Status: Up
Host: 10.254.1.226 () Status: Up
Host: 10.254.1.227 () Status: Up
Host: 10.254.1.228 () Status: Up
Host: 10.254.1.229 () Status: Up
Host: 10.254.1.230 () Status: Up
Sobre esta salida se implementa el AWK, el cual es un lenguaje de programación
diseñado para procesar datos basados en texto, ya sean ficheros o flujos de datos. Dicho
comando tendrá la opción -F para declarar un campo separador (field separator), eligiendo un
espacio vacío (“ “). Esto separará cada línea en 4 columnas y de esas 4 se imprimirá la
81
segunda ({print $2}), que contiene la dirección Ip. Dejando la entrada anterior, de la siguiente
forma:
10.254.1.224
10.254.1.225
10.254.1.226
10.254.1.227
10.254.1.228
10.254.1.229
10.254.1.230
Por último se volcaran todo esto en el archivo scan_rectorado_hosts_up, y así se
obtiene una lista de todos los host levantados en el rango correspondiente al rectorado, para
posteriormente utilizarlo como una nueva entrada de nmap y poder realizar escaneos de
forma mucho más eficiente.
Tomando como entrada este nuevo archivo (lista de hosts activos) se realizará la
detección de los sistemas operativos (fingerprinting activo) de los mismos a través de la
siguiente instrucción de nmap:
Figura 7-39: Escaneo de nmap con detección de sistemas operativos
Al igual que la instrucción anterior, ésta comienza con “nmap”, haciendo referencia a
la herramienta utilizada, y “-oG” para que la salida sea en formato “grepeable”. Con la
opción “-iL” se indica que el rango de direcciones Ip se encontrará en el archivo
scan_rectorado_hosts_up.
La opción “-O” habilita la detección del Sistema Operativo (también podría usarse la
opción “-A”). Esta detección es más efectiva si al menos se encuentran un puerto TCP
abierto y uno cerrado. Con la opción --osscan-limit se restringe la detección solo a los host
que cumplan este requisito. Esto genera una mejora en los tiempos de escaneo la cual es
efectiva sobre todo cuando se realiza el escaneo sobre una lista larga de hosts.
Como ya se ha mencionado, en etapas posteriores se volverá a hacer uso de nmap
como una de las herramientas principales del Test de Intrusión, y se profundizará en más
posibilidades y configuraciones que la misma permite.
82
7.4. Resumen
A lo largo de este capítulo se ha mostrado una de las maneras de dividir la fase de

Recolección de Información, para poder realizar una captura de datos en forma ordenada.
Además se han enumerado y demostrado ejemplos de uso de las herramientas útiles para esta
tarea. Un factor importante de estas herramientas es que son software libre, en la mayoría de
los casos cuentan con código abierto, son intuitivas y amigables al usuario y mantienen buena
relación prestación/eficiencia.
En la etapa de Footprinting Externo se obtuvo gran cantidad de información pública
partiendo de los sitios web correspondientes a la Unicen y el Rectorado, como se había
acordado previamente con los representantes del Centro de Datos y Comunicaciones.
Entre esta información se pueden encontrar IP’s, DNS, relación entre sitios web,
información sobre personas relacionadas a la UNICEN, etc.
Las direcciones IP’s de los sitios de Unicen (131.221.0.3) y Rectorado (131.221.0.4)
fueron utilizadas como punto de partida para obtener más información a través de las diversas
herramientas y técnicas aplicadas.
Con la herramienta whois se obtuvo el nombre del responsable del área, dirección,
e-mail y teléfono, que pueden ser utilizados en un ataque de Ingeniería Social. También se
utilizaron diversas alternativas web para realizar la tarea del whois, y en comparación los
resultados fueron presentados de manera más amigable al usuario debido a la mayor
capacidad de la representación visual que posee un browser con respecto a la consola de
comandos. Además, los resultados fueron un poco más amplios, ya que por lo general estos
sitios web no suelen ser minimalistas. Por ejemplo, a través de una búsqueda IP inversa, se
obtuvieron los sitios web que utilizan estas IP’s. Esto sirve como otro punto de partida para
continuar buscando información. Incluso se obtuvo la versión del sistema operativo
corriendo, que es parte del fingerprinting.
Mediante la técnica de Google Hacking se encontraron padrones docentes con
documentos de identidad y un pdf con información de usuarios, e-mails, nombres, sector al
que pertenecen y teléfonos, que podrían ser utilizados en un ataque de Ingeniería Social (por
ejemplo phishing) e incluso utilizarse para enriquecer un diccionario de ataque a contraseñas.
También se encontró la posibilidad de explorar directorios a través del browser sin
83
autenticación de ningún tipo. Por último, también se logró enumerar gran cantidad de sitios
web que poseen formularios de inicio de sesión. Esto último aumenta la probabilidad de
efectuar ataques de Cross Site Scripting (XSS), phishing, ataques de contraseñas, etc.
Con Robtex se obtuvo información similar a la obtenida con whois, como IP’s, DNS,
IP’s relacionadas mediante la utilización de Reverse Proxy, etc. Pero además, la información
fue presentada a través de gráficos que permiten visualizar la relación entre los servidores e
IP’s.
Mediante Shodan se lograron enumerar los puertos y servicios expuestos en las IP’s
públicas analizadas, e información de los sistemas operativos, aplicaciones y sus versiones,
enriqueciendo el fingerprinting del sistema auditado..
Maltego brindó información replicada con respecto al resto de las herramientas
utilizadas en el Footprinting Externo Pasivo, pero la representa visualmente de una manera
que permite interpretarla de forma sencilla. Con un simple vistazo a los gráficos se puede
notar la relación entre las URL’s, IP’s, DNS. Y además brinda información no técnica como
nombres de personas, e-mails, ubicaciones geográficas, etc.
Durante el Footprinting Externo Activo se utilizaron herramientas como netcat la cual
brindó información sobre puertos abiertos y servicios corriendo en los mismos. Esta
información ya había sido obtenida de forma pasiva, por lo que no resultó de gran utilidad, al
menos en los casos de uso que se probaron.
La herramienta whatweb fue una de las herramientas que resultaron más útiles para el
fingerprinting, ya que brindó información sobre las aplicaciones corriendo en los diversos
dominios auditados y sus versiones, y luego se utilizó su salida como entrada de
Blindelephant, para complementar aún más esta información. Obteniendo las aplicaciones y
sus versiones, es posible conseguir un listado de vulnerabilidades a las cuales se encuentran
expuestas. Son dos herramientas que se complementan y que expresan resultados amplios de
forma amigable. Un ejemplo de esto es que whatweb en sus resultados tiene un apartado
donde da una breve descripción sobre las aplicaciones encontradas.
En la etapa de Footprinting Interno se logró identificar los hosts activos en la red y
hacer un mapeo de la misma. Gracias a la tabla de IP’s encontrada en una wiki mediante la
técnica de Google Hacking en el Footprinting Externo Pasivo se realizó un escaneo de las
bandas de Unicen y Rectorado previamente habiendo acordado el alcance con los
representantes del Centro de Datos y Comunicaciones.
84
Utilizando esta información como entrada en la herramienta Nmap se identificaron
decenas de hosts activos en dichas bandas, junto con sus puertos abiertos, los servicios
corriendo en los mismos e información de sistemas operativos y aplicaciones.
85
8. Fase 3: Análisis de vulnerabilidades
Una vez completada la fase anterior, se cuenta con una gran cantidad de información
sobre el sistema que se desea auditar. Dicha información está catalogada y priorizada de
cierta forma que permite tener un amplio conocimiento sobre la red informática en cuestión.
Dado que una red informática es un conjunto de dispositivos interconectados entre sí
a través de un medio, que intercambian información y comparten recursos. Es fundamental
comprender cada nodo de dicho sistema para luego intentar buscar puntos débiles y ser
conscientes del impacto que puede llegar a tener un ataque sobre estos.
Por lo tanto, es momento de analizar los datos recolectados en búsqueda de todas las
secciones que pueden ser susceptibles a amenazas. De esta forma se podrá acceder a un
nuevo nivel de conocimiento, en el que no solo se comprenda la red junto a la funcionalidad
y finalidad de cada elemento que la compone. Sino también, tener una comprensión de las
vulnerabilidades a las que esta red está sometida, logrando así, la capacidad de buscar
soluciones que fortalezcan e incrementen en la mayor forma posible su seguridad.
8.1. Herramientas
Las principales herramientas utilizadas en esta fase son las siguientes: Nmap,
Wireshark, Nikto, Nessus, Metasploit.
La primer herramienta mencionada, Nmap, ya ha sido descrita en el capítulo
anterior, por lo que en este capítulo solamente se explicarán los scripts utilizados para
encontrar y justificar vulnerabilidades.
Mediante la herramienta Wireshark (incluida por defecto en la distribución Kali
Linux) podremos analizar la información que transita la red. Aqui se podra ver de qué forma
viajan los paquetes, junto a su nivel de seguridad (cifrado). El objetivo aquí será la búsqueda
de servicios expuestos con seguridad precaria, como lo pueden ser las autenticaciones
mediante texto plano.
Por lo tanto esta herramienta se utilizará como complemento para obtener de forma
más precisa el alcance de las vulnerabilidades existentes debido a la mala implementación de
protocolos de comunicación.
86
Nikto es una herramienta de tipo open source y se encuentra incluida en la
distribución Kali Linux. Su propósito es el escaneo de servidores web en busca de malas
configuraciones y vulnerabilidades, detección de ficheros en instalaciones por defecto, listado
de la estructura del servidor, versiones y fechas de actualizaciones de servidores, tests de
vulnerabilidades XSS, ataques de fuerza bruta por diccionario, reportes en formatos txt, csv,
html, etc.
Esta herramienta realiza tests comprensivos por múltiples ítems, incluyendo más de
6700 archivos de interfaces de entradas comunes (por sus siglas en inglés CGI, Common
Gateway Interfaces) potencialmente peligrosos, chequeos de versiones desactualizadas de
más de 1250 servidores, y problemas de versiones específicas de más de 270 servidores. A su
vez, también realiza chequeos en la configuración del servidor, tales como la presencia de
múltiples índices de archivos, opciones de servidor HTTP, y también intenta identificar
software y servidores webs instalados.
Esta herramienta se utiliza mediante la terminal de linux. A modo introductorio se
puede ingresar el comando nikto -Help para desplegar una descripción de todas las
operaciones que se pueden realizar. Dentro de ellas se tienen la opciones de Tuning.
Figura 8-1: Opciones contenidas en la herramienta Nikto
Estas opciones controlan los tests que ejecuta Nikto contra un objetivo. Por defecto
todos los tests son ejecutados, sin embargo, con la opción -tuning (-T) se puede especificar
cuales de los test deben de ser ejecutados por Nikto en el caso de que sea de interés solamente
ejecutar algunos.
Cada test está identificado por el siguiente listado de argumentos que identifican el
test que debe ejecutar Nikto. La opción -Tunning admite varios argumentos, de esta forma se
87
puede declarar más de uno de los tests definidos. Un escaneo realizado sobre un host está
conformado por la siguiente sintaxis:
nikto -host [hostname or IP] -Tuning [opción]
Figura 8-2: Escaneo con la herramienta Nikto para el host 10.254.1.152
En la figura 8-2 se puede observar el resultado de correr un escaneo con la opción 1.

Esta opción busca archivos de interés y devuelve entradas de logs que pueden considerarse
relevantes.
En este caso, dentro de la información que puede considerarse relevante se encuentran

que la versión PHP expuesta está desactualizada, dando un indicio de que quizá tenga un
riesgo conocido. También se encuentra la vulnerabilidad con clave 877 dentro de la base de
datos de vulnerabilidades de código abierto (OSVDB, Open Source Vulnerability Database,
por sus siglas en inglés), la cual indica que en el puerto 80 hay un servicio que cuenta con el
método HTTP Trace activado (que permite que el cliente envíe datos de la sesión al servidor),
que da lugar a la posibilidad de un ataque de Cross Site Tracing (XST), un subtipo de Cross
Site Scripting en donde si se logra inyectar un script en el html del sitio web expuesto, puede
llegar a robarse información de las cookies.
De todas formas, esto resulta útil si se requiere un escaneo específico sobre una
dirección IP, pero si se quiere realizar un chequeo sobre toda la banda que se desea auditar,
los resultados obtenidos no estarán en un formato cómodo y legible para su análisis. Es por
88
esto que se utilizará Nessus, que usa Nikto y Nmap pero a su vez retorna resultados en
formatos visuales fáciles de interpretar.
Esta herramienta cumple la función de ser un programa de escaneo de

vulnerabilidades en diversos sistemas operativos. Consiste en un demonio (tipo especial de
proceso informático que se ejecuta en segundo plano en vez de ser controlado directamente
por el usuario) llamado nessusd, que realiza el escaneo en el sistema objetivo, y nessus, el
cliente (basado en consola o interfaz gráfica) que muestra el avance e informa sobre el estado
de los escaneos.
Esta herramienta trabaja escaneando los puertos con nmap o con su propio scanner
para buscar puertos abiertos y después intentar varios exploits sobre ellos. Tanto las pruebas
de vulnerabilidad disponibles como también una larga lista de plugins, están escritos en
NASL (Nessus Attack Scripting Language, o Lenguaje de Scripting de Ataque Nessus por sus
siglas en inglés), un lenguaje de scripting optimizado para interacciones personalizadas en
redes.
Nessus no se encuentra dentro de la suite de herramientas que contiene por defecto la

distribución Kali Linux, por ende, se debe descargar e instalar. La descarga se puede realizar
desde el sitio oficial (http://www.tenable.com), seleccionando la versión Debian
correspondiente.
Figura 8-3: Versiones de descarga disponibles para la herramienta Nessus
Una vez que la descarga se ha completado, desde la terminal de Kali-Linux se debe

ejecutar el comando dpkg -i Nessus-5.2.3-debian6_i386.de para comenzar con su instalación.
89
Figura 8-4: Instrucción sobre cómo descargar Nessus desde la terminal de Kali Linux
Al completarse este proceso, ya se está en condiciones de ejecutar el demonio

mencionado anteriormente, que correrá en segundo plano y permitirá realizar los escaneos de
vulnerabilidades.
Figura 8-5: Activación del deamon de Nessus
Para eso se debe ingresar desde un navegador web a la url local

https://127.0.0.1:8834 (aceptando el riesgo de utilizar certificados autofirmados) e ingresar
un usuario y contraseña inicial (el cual debe recordarse cada vez que se quiera volver a
acceder en el futuro).
90
Figura 8-6: Creación de Usuario en Nessus
A continuación se solicitará el ingreso de un código de activación el cual puede

obtenerse desde el sitio de Tenable (compañía que desarrolla Nessus) ingresando tan solo la
dirección de correo, nombre y apellido legítimo del usuario que desee utilizarlo.
Figura 8-7: Ingreso del código de activación para Nessus
Una vez realizado esto, ya se está en condiciones de utilizar la herramienta

seleccionando la opción de nuevo escaneo. Aquí se debe completar la información básica, la
cual consta de un nombre para poder identificarlo, una descripción opcional para documentar
aún más detalles de la operación, la carpeta donde se desea guardar el resultado y por último
y principal las direcciones IP’s que se desean inspeccionar.
Una vez completado el escaneo la herramienta genera un reporte que agrupa los
resultados por hosts y vulnerabilidades, clasificando a estas últimas con niveles de riesgo que
van desde bajo hasta crítico.
De esta forma, quien realice la auditoría obtiene un reporte visual amigable con
algunas de las posibles vulnerabilidades encontradas en el campo de trabajo. No obstante
estos resultados generalmente cuentan de un gran número de falsos positivos, por lo que se
deben analizar una por una y validar que realmente las condiciones estén dadas para poder
explotarlas.
91
Figura 8-8: Configuración de escaneo en Nessus
Figura 8-9: Gráfico que contiene la cantidad de vulnerabilidades encontradas en el escaneo de

Nessus, clasificadas por niveles de criticidad
92
Figura 8-10: Reporte de vulnerabilidades de Nessus
Por último, se utilizará el framework Metasploit, el cual proporciona la infraestructura

necesaria para automatizar tareas rutinarias y complejas. Esto permite que se concentre aún
más en los aspectos únicos o especializados de las pruebas de penetración y en identificar
fallas dentro de su programa de seguridad de la información.
Metasploit es un framework, ya que consta con una suite de herramientas que
cumplen distintos roles y ayudan en numerosas partes del proceso de pentesting. Dado que
este no es el único momento en el que se hará uso de él, se irán explicando sus distintas
funcionalidades a medida que se requieran.
En esta ocasión se comienza por levantar una base de datos PostgreSQL donde se
guardará la información de los hosts a auditar. Esta información será obtenida mediante el
uso de Nmap ya que Metasploit soporta su uso en dos modalidades distintas. Una de estas
modalidades es utilizándolo de forma interna desde su propia consola (msfconsole), y la otra
importando los resultados obtenidos fuera de ella. Por lo tanto, lo primero que se debe hacer
es dirigirse a la carpeta con ruta /etc/init.d/ y de esta forma levantar el servicio postgresql.
Una vez que el servicio esté corriendo, se debe crear una nueva base de datos para
persistir la información. Esto se logra creando una base de datos de Metasploit, mediante el
comando msfdb init.
93
Figura 8-11: Consulta sobre el estado del servicio postgresql seguido de su inicialización
Figura 8-12: Inicialización de la bases de datos de Metasploit
La información que se persistirá en este caso, será obtenida de los siguientes

comandos:
- nmap -oX - 10.254.0.0-255 -F -O --osscan-limit -vv > scan_banda_unicen.xml
- nmap -oX - 10.254.1.0-255 -F -O --osscan-limit -vv > scan_banda_rectorado.xml
Si bien estos comandos que recolectan la información de los hosts levantados en
dichas bandas junto a sus servicios ya han sido descritos anteriormente, en esta ocasión hay
un pequeño cambio. Se ha reemplazado la opción -oG que retornaba los resultados en un
formato grepeable, por -oX la cual lo hará en XML. El motivo de esto es que Metasploit sabe
interpretar este formato para realizar volcados de información en su base de datos.
A continuación se procede a acceder msfconsole. Esta consola es la parte más popular
de framework Metasploit, y por buenas razones. Es una de las herramientas más flexibles.
Cuenta con múltiples funciones que están bien soportadas dentro del marco. Msfconsole
ofrece una práctica interfaz para casi todas las opciones y la configuración disponible en el
Framework. Cada funcionalidad disponible puede accederse desde aquí.
94
Figura 8-13: Ingreso a msfconsole (consola del framework Metasploit)
Desde este entorno el primer paso deberá ser generar una conexión con la base de
datos creada anteriormente. Esta operación se realiza mediante el siguiente comando:
db_connect postgres:[password_del_usuario]@127.0.0.1/msf.
Tras crear la conexión, ya se estarán en condiciones de realizar el volcado de la
información, mediante los archivos XML obtenidos de los escaneos con Nmap. En este caso
el comando a ingresar tendrá el siguiente formato: db_import [archivo xml].
De esta acción se obtienen numerosas ventajas. La primera es la capacidad de tener un
accesos rápido, eficiente y centralizado a la información obtenida en la etapa previa. Ya que
ahora es posible acceder a la información de los hosts y los servicios, con una gran variedad
de comandos y variantes. Para demostrar esto, el primer ejemplo será el comando hosts, el
cual devolverá el listado completo de los hosts importados detallado por dirección ip,
nombre, sistema operativo, propósito (por ejemplo: servidor), etc.
95
Figura 8-14: Volcado en la base de Metasploit mediante archivo xml de información de hosts
obtenidos con Nmap
Figura 8-15: Consulta a la base de Metasploit sobre la información de los host
Otro comando que resulta de gran utilidad es services, el cual tiene el mismo
propósito de hosts, pero en este se desplegará un listado con todos los servicios encontrados
96
por los escaneos de Nmap. El detalle de cada servicio contendrá la dirección del host y el
puerto donde se expone, el protocolo por el cual se puede acceder (tcp, udp), el nombre del
servicio (ssh, smtp, http, https, etc), el estado (abierto, cerrado o filtrado) y en algunos casos
información adicional.
Figura 8-16: Consulta a la base de Metasploit sobre la información de los servicios
Estos comandos presentan variantes y opciones para realizar consultas más

específicas. En la siguiente imagen se puede observar la solicitud de los servicios que están
expuestos en el host 10.254.1.240, lo que permite acceder a información de forma más
específica beneficiando el trabajo de análisis.
Continuando con los ejemplos, en la figura 8-18 se observa la petición de todos los
servicios que contengan http en el nombre o en la información que se han encontrado.
97
Figura 8-17: Consulta a la base de Metasploit sobre la información de los servicios del host
10.254.1.240
Figura 8-18: Consulta a la base de Metasploit sobre la información de los servicios http
Además de escaneos de Nmap, el framework Metasploit también acepta la

importación de escanemos efectuados por Nessus, para ya de esta forma tener un espectro
total de la información de cada host. Para esto se debe primero exportar el reporte generado
por la herramienta en un archivo con extensión nessus. Una vez realizado esto el comando a
ingresar para efectuar el volcado será el mismo que para Nmap, db_import
[archivo_nessus].nessus.
98
Figura 8-19: Volcado en la base de Metasploit sobre vulnerabilidades de hosts obtenidos con la
herramienta Nessus
Aquí tendremos el comando vulns. El cual nos mostrará todas las vulnerabilidades
que tengamos importadas.
Figura 8-20: Reporte de vulnerabilidades persistidas en la base de Metasploit
A modo de finalizar esta demostración se mostrará la siguiente petición, la cual

devolverá el número de vulnerabilidades encontradas de cada hosts registrado con sistema
operativo Windows.
Figura 8-21: Consulta a la base de Metasploit sobre cantidad de vulnerabilidades en host que utilicen
Windows
99
8.2. Vulnerabilidades de desbordamiento de buffer
8.2.1. MS06-040: Vulnerabilidad en servicio del servidor permite ejecución de código

remoto
Factor de Riesgo
Crítico
Descripción
El desbordamiento de búfer en el servicio del servidor en Microsoft Windows 2000
SP4, XP SP1 y SP2 y Server 2003 SP1 permite a los atacantes remotos, incluidos los usuarios
anónimos, ejecutar código arbitrario a través de un mensaje RPC.
Vulnerabilidades
CVE: 2006-3439
BID: 19409
MSFT: MS06-040
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
Evidencia
Para evidenciar esta vulnerabilidad se han ejecutado 2 escaneos con la herramienta
Nmap. El primero ha evidenciado que hay un servicio microsoft-ds expuesto en el puerto 445
de dicho host.
En el segundo escaneo se ha utilizado el script smb-os-discovery, directamente sobre
el puerto 445. Este script intenta determinar el sistema operativo, el nombre de la
computadora, el dominio, el grupo de trabajo y la hora actual sobre el protocolo SMB. Esto
se hace iniciando una sesión con una cuenta anónima. En respuesta a una sesión que
comienza, el servidor devolverá toda la información necesaria como para justificar la
existencia de la vulnerabilidad.
100
Figura 8-22: Escaneo de Nmap para la Ip 10.254.1.18
Solución
Microsoft lanzó una serie de parches para Windows 2000, XP y 2003.
8.2.2. Apache 2.2.x < 2.2.15 Múltiples Vulnerabilidades
Factor de Riesgo
Crítico
Descripción
De acuerdo con su banner auto-reportado, si la versión de Apache 2.2.x que se
ejecuta en el host es anterior a 2.2.13 entonces, incluye una versión empaquetada de la
biblioteca Apache Portable Runtime (APR) que contiene una falla en 'apr_palloc()' que
101
podría causar un desbordamiento (overflow) del heap. Esta vulnerabilidad es crítica y podría
ser explotada a través de alguna aplicación con fines maliciosos.
Además, estas mismas versiones, al ser menores a la 2.2.15 también se ven expuestas
a las siguientes vulnerabilidades de estado crítico.
- Es posible un ataque de inyección de prefijo de renegociación TLS.
(CVE-2009-3555).
- El módulo 'mod_proxy_ajp' devuelve el código de estado incorrecto si encuentra un
error que hace que el servidor back-end sea puesto en un estado de error.
(CVE-2010-0408).
- El 'mod_isapi' intenta descargar el 'ISAPI.dll' cuando encuentra varios estados de
error que podrían dejar call-backs con estados indefinidos. (CVE-2010-0425)
- Una falla en el código de proceso de la sub-petición puede conducir a que la
información sensible sea manejada por un hilo (thread) incorrecto si se utiliza un
entorno de hilos múltiples (multi-threaded). (CVE-2010-0434)
Vulnerabilidades
- CVE-2009-3555: El protocolo TLS y el protocolo SSL 3.0 y posiblemente anterior,
como se utiliza en los Servicios de Microsoft Internet Information Server (IIS) 7.0,
mod_ssl en el servidor HTTP Apache 2.2.14 y anteriores, OpenSSL antes 0.9.8l,
GnuTLS 2.8.5 y anteriores, Mozilla Network Security Services (NSS) 3.12.4 y
versiones anteriores, varios productos de Cisco y otros productos, no asocian
adecuadamente los “apretones de manos” (handshakes) de renegociación con una
conexión existente, lo que permite a los atacantes intermedios insertar datos en
sesiones HTTPS y posiblemente otros tipos de sesiones protegidas por TLS o SSL,
enviando una solicitud no autenticada que es procesada retroactivamente por un
servidor en un contexto posterior a la renegociación, relacionado con un ataque de
inyección de texto plano, también conocido como el problema de Project Mogul.
- CVE-2010-0408: La función ap_proxy_ajp_request que se encuentra en
mod_proxy_ajp.c/mod_proxy_ajp de Apache HTTP Server 2.2.x con versiones
anteriores a 2.2.15 no maneja correctamente ciertas situaciones en las que un cliente
no envía un cuerpo de solicitud (request), lo que permite a atacantes remotos
provocar una denegación de servicio a través de una solicitud creada, relacionada con
102
el uso de un código de error 500 (error interno) en lugar del código de error 400
(solicitud incorrecta) que sería el apropiado.
- CVE-2010-0425: El archivo modules/arch/win32/mod_isapi.c en mod_isapi en el
Servidor HTTP Apache 2.0.37 a 2.0.63, 2.2.0 a 2.2.14, y 2.3.x antes de la 2.3.7,
cuando se ejecuta en Windows, no garantiza que el procesamiento de peticiones se
completa antes de llamar a isapi_unload para un módulo .dll de ISAPI, que permite a
atacantes remotos ejecutar código arbitrario a través de vectores no especificados
relacionados con una solicitud creada, un paquete de restablecimiento y "punteros
huérfanos de devolución de llamada".
Hosts Afectados
10.254.0.130 (puerto 80 /tcp/www)
10.254.0.200 (puerto 80 /tcp/www)
10.254.0.249 (puerto 8080 /tcp/www)
Evidencia
En este caso se utilizará la herramienta cURL, la cual proporciona una biblioteca y
una herramienta de línea de comandos para transferir datos usando varios protocolos. Es una
herramienta muy útil para hacer peticiones HTTP/S, y además consta de múltiples opciones,
entre ellas está la opción -I o --head. La cual retorna información de los encabezados. Los
servidores HTTP cuentan con el comando HEAD, que usa para obtener nada más que el
encabezado de un documento. Cuando se usa en un archivo FTP o FILE, curl muestra solo el
tamaño del archivo y la última modificación.Pero en este caso lo utilizamos para ver la
versiones de los Apaches que corren en dichos hosts.
Figura 8-23: Consulta de cabezados mediante cURL para la dirección 10.254.0.200
103
Figura 8-24: Consulta de cabezados mediante cURL para la dirección 10.254.0.130
Otra forma de averiguar esta información es mediante la herramienta Nmap, aquí se

envía un escaneo sobre el puerto 8080 con la opción -sV la cual activa la detección de
versiones.
Figura 8-25: Escaneo con detección de versiones mediante Nmap para el puerto 8080 del host 10.254.0.249
Solución
Actualizar la versión de Apache a la 2.2.15 o superior.
8.2.3. MS03-026: Saturación de buffer de la interfaz Microsoft RPC
Factor de Riesgo
Crítico
Descripción
La versión de Windows corriendo en el host tiene un error en la función
RemoteActivation en la interfaz RPC, que permite al atacante ejecutar código arbitrario con
permisos de sistema. Una serie de gusanos (Blaster) explotan esta vulnerabilidad.
Vulnerabilidad
CVE: 2003-0352
BID: 8205
MSFT: MS03-026
Host Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
104
Evidencia
Nuevamente se ha utilizado la herramienta Nmap, junto a su script smb-os-discovery,
de esta forma se ha confirmado que la versión de Windows está dentro de las afectadas por
dicha vulnerabilidad
Figura 8-26: Ejecución del script de Nmap smb-os-discovery para el puerto 445 en la ip 10.254.1.18
Solución
Microsoft lanzó parches para las versiones NT, 2000, XP y 2003.
8.2.4. MS03-039: Saturación de buffer de la interfaz Microsoft RPC
Factor de Riesgo
Crítico
Descripción
El host está corriendo una versión de Windows que tiene un error en la interfaz RPC,
que permite al atacante ejecutar código arbitrario y ganar permisos de sistema. Se puede
utilizar un gusano para ganar control del host. Notar que este no es el mismo bug que el
descrito en MS03-026, que puede ser explotado con el gusano MSBlast (o LoveSan).
Vulnerabilidades
CVE: CVE-2003-0715, CVE-2003-0528, CVE-2003-0605
BID: 8458, 8460
MSFT: MS03-039
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
105
Evidencia
A través de la ejecución de un script se pudo llegar al descubrimiento de esta
vulnerabilidad. Dicho script funciona como un escáner que envía nombres UNC (siglas del
inglés que significan Universal Naming Convention, es un método que se usa para identificar
carpetas, archivos y programas en un equipo en red. Una ruta UNC comienza con barras
invertidas \\ seguidas por el nombre del equipo, el nombre del recurso compartido y,
generalmente, el directorio y/o el nombre del archivo) a las solicitudes de activación remotas
y observa los mensajes de error. En base a estos mensajes de error puede darse cuenta de la
situación del host respecto a esta vulnerabilidad. Un tipo de mensajes de error indica que el
sistema es vulnerable, otro tipo diferente indica que el sistema está parcheado. Existe un
tercer tipo que indica que se encuentra DCOM instalado y la herramienta los descarta
silenciosamente. Y por último, un tipo de mensajes que indican que el sistema tiene DCOM
deshabilitado, por lo que no se puede saber si el parche está o no instalado.
Existen dos maneras de que los objetos sean activados remotamente. La primera es a
través de la interfaz ISystemActivator de la infraestructura .NET, y la segunda a través de la
conocida interfaz IRemoteActivation. El script realiza queries a ambas interfaces. Dicho
script se puede encontrar en la web de exploit-db.
Figura 8-27: Ejecución de script obtenido en https://www.exploit-db.com/exploits/97/
Solución
106
8.2.5. MS08-067: Vulnerabilidad en Microsoft Windows Server Service RPC
Factor de Riesgo
Crítico
Descripción
El host se encuentra afectado por una vulnerabilidad que permite la ejecución de
código remoto debido a errores en el manejo de consultas RPC. Un atacante remoto no
autorizado puede ejecutar código arbitrariamente con privilegios de Sistema, mediante el uso
de paquetes de consulta RPC especialmente diseñados.
Eclipsewing es un exploit diseñado por Shadow Brokers el 14/4/2017 con el cual se
puede explotar esta vulnerabilidad.
Vulnerabilidades
CVE: 2008-4250
BID: 31874
MSFT: MS08-067
CERT: 827267
EDB-ID: 6824, 7104, 7132
CWE: 94
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
Evidencia
Se ha ejecutado un scan con la herramienta Nmap, junto a un script específicamente
diseñado para determinar si esta vulnerabilidad está o no presente.
Figura 8-28: Ejecución de script de Nmap, el cual verifica si la vulnerabilidad ms08-067 existe en el
puerto 445 de la dirección Ip 10.254.1.18
107
Solución
Microsoft lanzó una serie de actualizaciones para Windows 2000, XP, 2003, Vista y
2008.
8.2.6. MS06-035: Vulnerabilidad en el Servidor puede permitir la ejecución de código

remoto
Factor de Riesgo
Alto
Descripción
El host remoto es vulnerable a un desbordamiento de montículo (heap overflow), en el
servicio mencionado, que puede permitir a un atacante ejecutar código arbitrariamente con
privilegios de Sistema (SYSTEM privileges). Además, el host también está afectado por una
vulnerabilidad de divulgación de información en SMB que puede permitir al atacante obtener
porciones de la memoria de dicho host. Estas vulnerabilidades son fácilmente explotables con
la herramienta Core Impact.
Vulnerabilidades
CVE: 2006-1314, 2006-1315
BID: 18863, 18891
TRA: 2006-01
MSFT: MS06-035
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
Evidencia
Igual que en casos anteriores, se ha acudido al script smb-os-discovery ejecutado con
la herramienta Nmap, el cual permite determinar la versión del sistema operativo. De esta
forma se puede deducir si es de aquellas que son susceptibles a esta vulnerabilidad.
108
Figura 8-29: Ejecución del script de Nmap smb-os-discovery para el puerto 445 en la ip 10.254.1.18 y
10.254.1.152
Solución
Microsoft lanzó una serie de parches para Windows 2000, XP y 2003.
109
8.3. Vulnerabilidades de error de formato de cadena
8.3.1. MS04-007: Vulnerabilidad de biblioteca ASN.1
Factor de Riesgo
Crítico
Descripción
El host posee la biblioteca ASN.1 que puede permitir a un atacante ejecutar código
arbitrario. Para explotar este error, el atacante necesita enviar un paquete ASN.1
especialmente diseñado con longitudes incorrectas a las publicadas. Se envió un paquete
NTLM mal formado y determinó que el host no está parcheado. Se puede usar Metasploit,
CANVAS o Core Impact para explotar esta vulnerabilidad.
Vulnerabilidades
CVE: CVE-2003-0818
BID: 9633, 9635, 9743, 13300
MSFT: MS04-007
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
Evidencia
Para evidenciar esto se utilizó la herramienta Nmap junto al script smb-enums-shares
el cual enumera las distintas bibliotecas, retornado entre ellas la que causa esta
vulnerabilidad.
110
Figura 8-30: Ejecución del script de Nmap smb-enum-shares para el puerto 445 en la ip 10.254.1.18
Solución
8.3.2. Servicio SMTP STARTTLS Inyección de comandos de texto sin formato
Factor de Riesgo
Alto
Descripción
El servicio SMTP remoto contiene una falla de software en su implementación
STARTTLS que podría permitir a un atacante remoto no autenticado inyectar comandos
durante la fase de protocolo de texto plano que se ejecutará durante la fase del protocolo de
cifrado.
La explotación exitosa podría permitir a un atacante robar el correo electrónico de una
víctima o las credenciales SASL (Simple Authentication and Security Layer) asociadas.
Vulnerabilidades
CVE: 2011-2165, 2011-1506, 2011-1432, 2011-1431, 2011-1430, 2011-0411
OSVDB: 75256, 75014, 73251, 71946, 71854, 71021, 71020
BID: 46767
111
CERT: 555316
Hosts Afectados
10.254.0.160 (puerto 25/tcp/smtp)
Evidencia
El protocolo TLS cifra la comunicación y la protege contra modificación por otras
partes. Esta protección sólo existe si:
- El software está libre de defectos
- Los clientes verifican el servidor TLS certificado, para que no pueda haber
“man in the middle" (servidores generalmente no verifican certificados de
cliente).
El problema es causado por una falla de software. La falla permite a un atacante
inyectar comandos de cliente en un SMTP sesión durante la fase de protocolo SMTP sin
protección, de tal manera que el servidor ejecutará los comandos durante la fase de protocolo
SMTP-sobre-TLS cuando toda la comunicación es supuestamente protegido.
Las órdenes inyectadas podrían usarse para robar el correo electrónico de la víctima o
nombre de usuario y contraseña SASL (Simple Authentication and Security Layer).
En la figura 8-31 se demuestra la posibilidad de comenzar una comunicación
mediante el protocolo TLS. Haciendo uso del kit de herramientas openssl, se establece una
conexión con el puerto 25 del host 10.254.0.160 gracias al comando STARTTLS.
Figura 8-31: Inicio de conexión con protocolo TLS al puerto 25 de la Ip 10.254.0.160
Solución
Póngase en contacto con el proveedor para ver si hay una actualización disponible.
112
8.4. Vulnerabilidades de Cross Site Scripting
8.4.1. Apache HTTP Server: Página de error 403 UTF-7 Encoded XSS
Factor de Riesgo
Alto
Descripción
De acuerdo con su banner, la versión del servidor HTTP Apache corriendo en el host
puede ser utilizada en ataques cross-site-scripting (XSS). Diseñando peticiones especiales se
puede inyectar código encodeado UTF-7 en la página de respuesta 403. Esto es una
vulnerabilidad del navegador web debido a no compluir con el RFC 2616. El servidor
Apache no es vulnerable, pero su mala configuración por default permite explotar este
comportamiento en navegadores vulnerables.
Vulnerabilidades
CVE: (2008-2168) La vulnerabilidad de Cross-site scripting (XSS) en Apache 2.2.6 y
versiones anteriores permite a los atacantes remotos inyectar secuencias de comandos web o
HTML arbitrarios a través de URL codificadas en UTF-7 que no se manejan adecuadamente
cuando se muestra la página de error 403 Prohibido.
BID: 29112
CWE: 79
Hosts Afectados
10.254.0.200 (puerto 80/tcp/www)
10.254.1.152 (puerto 80/tcp/www)
Evidencia
Al ejecutar un escáner sobre el puerto 80 de los hosts, se puede apreciar que las
versiones de Apache expuestas en dichos puertos son previas a la 2.2.6. Esto indica que están
afectados ante esta vulnerabilidad.
113
Figura 8-32: Escaneo de versiones con Nmap al puerto 80 de las direcciones Ip 10.254.0.200 y 10.254.1.152
Solución
Actualizar a versiones de Apache 2.2.8 / 2.0.63 / 1.3.41 o superiores.
8.4.2. Métodos HTTP TRACE / TRACK Permitidos
Factor de Riesgo
Medio
Descripción
El servidor web soporta la ejecución de los métodos HTTP Trace y Track. Estos
métodos son utilizados para debuguear la conexión del servidor web. Normalmente, se utiliza
el método HTTP TRACE para devolver la solicitud HTTP completa al cliente solicitante para
propósitos de depuración de proxy. Un atacante puede crear una página web usando
XMLHTTP, ActiveX o XMLDOM para que un cliente emita una solicitud TRACE y poder
capturar sus cookies. Esto resulta efectivamente en un ataque Cross-Site Scripting.
8.4.2.1. Método de solicitud TRACE (RASTREO)
El método de solicitud de rastreo (trace) es un mecanismo de entrada y exposición de

datos para el protocolo http. Sus usos más comunes son los de depuración (debug) u otras
actividades de análisis de conexión.
La solicitud Trace http, que contiene línea de solicitud (request line), encabezados,
datos de publicación (post data), enviada a un servidor web con soporte de seguimiento, le
114
responderá al cliente la información contenida en la solicitud. Trace proporciona toda la
información sobre qué datos envía un cliente http y qué es lo que está recibiendo el servidor.
Apache, IIS e iPlanet son compatibles con dicho método, según lo definido por el
HTTP / 1.1 RFC y actualmente esto se encuentra habilitado de forma predeterminada. Muy
pocos administradores de sistemas han deshabilitado este método de solicitud ya sea porque
el método no presentaba riesgos conocidos, la configuración predeterminada se consideraba
lo suficientemente buena o simplemente no tenía la opción de hacerlo. [Gro03]
La figura 8-33 muestra un ejemplo de una llamada http con este método mediante la
herramienta cURL:
Figura 8-33: Llamada http con el método trace al host 10.254.0.160 mediante la herramienta cURL
8.4.2.2. Opción httpOnly en Cookie
Esta es una opción de cookies HTTP utilizada para informar al navegador que no
permita el uso de lenguajes de scripting (JavaScript, VBScript, etc.) acceso al objeto
document.cookie (objetivo de ataque XSS normal). La sintaxis de una cookie httpOnly es la
siguiente:
- Set-Cookie: name=value; httpOnly [Gro03]
El método TRACE, aunque aparentemente inofensivo, puede aprovecharse con éxito
en algunos escenarios para robar las credenciales legítimas de los usuarios. Esta técnica de
ataque fue descubierta por Jeremiah Grossman en 2003, en un intento de eludir la etiqueta
httpOnly que Microsoft introdujo en Internet Explorer 6 SP1 para evitar que JavaScript tenga
115
acceso a las cookies. Como cuestión de hecho, uno de los patrones de ataque más recurrentes
en Cross Site Scripting es acceder al objeto document.cookie y enviarlo a un servidor web
controlado por el atacante para que pueda secuestrar la sesión de la víctima. Etiquetar una
cookie como httpOnly impide que JavaScript acceda a ella, protegiéndola de ser enviada a un
tercero. Sin embargo, el método TRACE puede usarse para eludir esta protección y acceder a
la cookie incluso en este escenario.[Owa14]
Vulnerabilidades
CVE: 2003-1567, 2004-2320, 2010-0386
BID: 9506, 9561, 11604, 33374, 37995
CERT: 288308, 867593
CWE: 16, 200
Hosts Afectados
10.254.0.59 (puerto 80/tcp/www)
10.254.0.62 (puerto 80/tcp/www)
10.254.0.130 (puerto 80/tcp/www)
10.254.0.144 (puerto 80/tcp/www)
10.254.0.160 (puerto 80/tcp/www)
10.254.0.200 (puerto 80/tcp/www)
10.254.0.249 (puerto 8080/tcp/www)
10.254.1.152 (puerto 80/tcp/www)
10.254.1.178 (puerto 80/tcp/www)
10.254.1.184 (puerto 80/tcp/www)
10.254.1.234 (puerto 443/tcp/www)
10.254.1.243 (puerto 80/tcp/www)
Evidencia
Para encontrar la evidencia de esta vulnerabilidad se utilizó la herramienta Nmap
junto al script http-methods, el cual averigua qué opciones admite un servidor HTTP
enviando una solicitud de OPTIONS. Luego enumera los métodos potencialmente riesgosos.
Prueba los métodos que no se mencionan en los encabezados OPTIONS de forma individual
y ve si están implementados.
En este script, los métodos "potencialmente riesgosos" son todos excepto GET,
HEAD, POST y OPTIONS. Si la secuencia de comandos informa métodos potencialmente
116
riesgosos, es posible que no sean todos riesgos de seguridad, pero se deben verificar para
asegurarse.
Figura 8-34: Ejecución del script de Nmap http-methods para la dirección ip 10.254.1.160
Adicionalmente, algunos host permiten el uso de métodos HTTP arbitrarios como

puede ser el caso de JEFF. Este método es tratado como si se emitiera un método GET y no
está sujeto a controles de acceso. Esto permite la presentación autorizada de solicitudes GET
con privilegios. Devolviendo información sensible la cual puede ser accedida desde un script
inyectado (XSS) y agravar aún más dicho escenario.Esto se puede evidenciar al realizar un
llamado con el método JEFF (en este caso mediante la herramienta cURL).
Figura 8-35: Llamada http con el método jeff al host 10.254.1.184 mediante la herramienta cURL
Solución
Deshabilitar estos métodos.
117
8.4.3. Servidor HTTP Apache Cookie httpOnly: Divulgación de Información
Factor de Riesgo
Medio
Descripción
La versión del Servidor HTTP Apache corriendo en el host está afectada por una
vulnerabilidad de divulgación de información. Enviando una petición con encabezado HTTP
lo suficientemente grande para exceder el límite del servidor causa que el servidor web
responda un mensaje HTTP 400. Por defecto, el encabezado y valor HTTP son mostrados en
la página de error 400. Cuando esto es usado en conjunto con otros ataques, como por
ejemplo cross-site scripting, puede resultar comprometida la cookie httpOnly.
Vulnerabilidades:
CVE: (2012-0053) El archivo protocol.c en las versiones de Apache HTTP Server que
van desde 2.2.0 hasta 2.2.21 no restringe apropiadamente la información del encabezado
durante la construcción de documentos de error de Bad Request (código 400), lo que permite
a los atacantes remotos obtener los valores de las cookies HTTPOnly a través de vectores que
involucran encabezados largos o mal formados junto con un script web elaborado.
BID: 51706
EDB-ID: 18442
Hosts Afectados
10.254.0.32 (puerto 80/tcp/www 443/tcp/www)
10.254.0.59 (puerto 80/tcp/www)
10.254.0.62 (puerto 80/tcp/www)
10.254.0.130 (puerto 80/tcp/www)
10.254.0.160 (puerto 80/tcp/www)
10.254.0.200 (puerto 80/tcp/www)
10.254.0.249 (puerto 8080/tcp/www)
10.254.1.152 (puerto 80/tcp/www)
Evidencia
Ante esto se implementó un escaneo con la herramienta Nessus de detección de
vulnerabilidades. Dicha herramienta realiza un llamado con el método GET del protocolo
HTTP, en el cual añade una cookie extremadamente larga.
118
Figura 8-36: Prueba realizada por la herramienta Nessus
Solución
Actualizar a la versión de Apache 2.0.65 / 2.2.22 o superior.
8.5. Vulnerabilidades de denegación del servicio
8.5.1. MS09-001: Vulnerabilidad de ejecución de código remoto de Microsoft Windows

SMB
Factor de Riesgo
Crítico
Descripción
El host está afectado por una vulnerabilidad de corrupción de memoria en SMB que
permite a un atacante ejecutar código arbitrario o realizar un ataque de denegación de servicio
contra el host. Explotable mediante Metasploit o Core Impact.
Vulnerabilidades
CVE-2008-4834: El desbordamiento del buffer en el servicio SMB de los sistemas
operativos Microsoft Windows 2000 SP4, XP SP2 y SP3, y Server 2003 SP1 y SP2 permite a
atacantes remotos ejecutar código arbitrario a través de la explotación de un error en los
campos dentro de los paquetes SMB en solicitudes NT Trans. Es también conocida como la
vulnerabilidad SMB Buffer Overflow Remote Code Execution Vulnerability.
CVE-2008-4835: El servicio SMB en Microsoft Windows 2000 SP4, XP SP2 y SP3,
Server 2003 SP1 y SP2, Vista Gold y SP1, y Server 2008, permite a atacantes remotos
119
ejecutar código arbitrario a través de valores no especificados dentro de los campos de los
paquetes SMB en solicitudes NT Trans2, relacionado con la insuficiente validación del
tamaño del buffer. Es también conocida como la vulnerabilidad SMB Validation Remote
Code Execution.
CVE-2008-4114: srv.sys en Microsoft Windows 2000 SP4, XP SP2 y SP3, Server
2003 SP1 y SP2, Vista Gold y SP1, y Server 2008, permite a atacantes remotos causar una
denegación de servicio o generar otros posibles impactos a través de paquetes SMB
WRITE_ANDX con un offset inconsistente con respecto al tamaño del paquete, relacionado
a la insuficiente validación del tamaño del buffer demostrada con una solicitud a
\PIPE\lsarpc. Esta vulnerabilidad también es conocida como SMB Validation Denial of
Service.
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
Evidencia
A través del scan de Nmap que se puede observar en la siguiente imagen, se corrobora
la versión de Microsoft Windows instalada en el host, evidenciando que puede ser tanto
Windows 2003 como 2008, ambos afectados por esta vulnerabilidad.
Figura 8-37: Escaneo de versiones con Nmap al puerto 80 de la dirección Ip 10.254.1.18
Solución
Microsoft lanzó una serie de parches para Windows 2000, XP, 2003, Vista y 2008.
8.5.2. MS12-020: Ejecución de código remoto permitida

Factor de Riesgo
Alto
120
Descripción
Existe una vulnerabilidad de ejecución de código remoto en la implementación de
Remote Desktop Protocol (RDP). La vulnerabilidad es debido a la manera en que RDP
accede a un objeto en memoria que fue inicializado inapropiadamente o que fue eliminado.
Si RDP está habilitado en el sistema afectado, un atacante no autorizado puede
aprovechar esta vulnerabilidad para lograr que el sistema ejecute código arbitrario enviándole
una secuencia de paquetes RDP especialmente diseñados.
Vulnerabilidades
CVE-2012-0002: El servicio RDP (Remote Desktop Protocol) en Microsoft Windows
Server 2008 R2 y R2 SP1 y en Windows 7 Gold y SP1, permite a atacantes remotos causar la
denegación de servicio a través del envío de una serie de paquetes modificados. Esta
vulnerabilidad también se conoce como Terminal Server Denial of Service Vulnerability.
CVE-2012-0152: La implementación de RDP (Remote Desktop Protocol) en
Microsoft Windows XP SP2 y SP3, Windows Server 2003 SP2, Windows Vista SP2,
Windows Server 2008 SP2, R2 y R2 SP1, y Windows 7 Gold y SP1, no procesa los paquetes
de forma apropiada en la memoria, lo que permite a un atacante remoto ejecutar código de
manera arbitraria enviando paquetes RDP modificados que disparen acceso a un objeto que
no fue apropiadamente inicializado o eliminado. Esta vulnerabilidad también se conoce como
Remote Desktop Protocol Vulnerability.
BID: 52353, 52354
MSFT: MS12-020
EDB-ID: 18606
Hosts Afectados
10.254.0.133 (puerto 3389/tcp)
Evidencia
El script rdp-vuln-ms12-020 de la herramienta Nmap realiza un escaneo para
corroborar que el host posee dicha vulnerabilidad.
En el boletín MS12-020 de Microsoft se informa acerca de esta vulnerabilidad y sobre
el lanzamiento de parches para solucionarla. Lo que el script ejecutado hace es fijarse si estos
parches se encuentran instalados, y lo realiza sin necesidad de hacer que el host objetivo sufra
la denegación de servicio.
121
Para esto, primero envía una petición de usuario. El servidor responde con un
identificador de usuario y un canal para ese usuario. Luego envía otra petición de usuario, la
cual el server responde con otra identificación de usuario y otro canal. Luego envía una
petición de unificación de canal indicando como solicitante al primer usuario y como canal
solicitado el del segundo usuario. Si el servidor responde con un mensaje de éxito se
concluye que el servidor es vulnerable.
En caso de que el servidor sea vulnerable se envía una solicitud para deshacer el
comportamiento anterior, así se evita la posibilidad de que se caiga el servidor. El resultado
de la ejecución de este script puede observarse en la figura 8-38.
Figura 8-38: Ejecución del script de Nmap rdp-vulns-ms12-020 para el puerto 3389 en la ip
10.254.0.133
Solución
Microsoft lanzó una serie de parches para Windows XP, 2003, Vista, 2008, 7 y 2008
R2. Para obtener este parche para la versión de Windows 2000 es necesario un contrato de
soporte extendido con Microsoft.
122
8.5.3. Servidor HTTP Apache Rango de Bytes DoS
Factor de Riesgo
Alto
Descripción
La versión del servidor HTTP Apache corriendo en el host remoto se encuentra
afectada por una vulnerabilidad de denegación de servicio. Mediante la realización de una
serie de peticiones HTTP con rangos superpuestos en los encabezados de las peticiones
Range o Request-Range puede lograrse el agotamiento tanto de memoria como de CPU. Un
atacante no autorizado puede explotar esta vulnerabilidad y lograr que el sistema afectado no
de respuesta. El código de explotación está disponible públicamente, se lo puede encontrar
como ApacheKill.
Hosts Afectados
10.254.0.130 (puerto 80/tcp/www)
10.254.0.160 (puerto 80/tcp/www)
Vulnerabilidades
CVE-2011-3192: El filtro de rango de byte en los servidores HTTP Apache 1.3.x,
2.0.x a 2.0.64, y 2.2.x a 2.2.19, permite a atacantes remotos causar la denegación de servicio
a través de la saturación tanto de la memoria como del CPU aprovechando una deficiencia del
encabezado Range que expresa múltiples superposiciones de rangos.
BID: 49303
CERT: 405811
EDB-ID: 17696 18221
Evidencia
A través de la ejecución de un script de la herramienta Nmap se corrobora la versión
de Apache que tiene corriendo el host. Cruzando esta información contra bases de datos de
vulnerabilidades se puede encontrar fácilmente a qué problemas está expuesto un sistema con
dicha versión de Apache instalada. En la figura 8-39 se puede observar el resultado de la
ejecución del script al que se hace referencia.
123
Solución
Actualizar a la versión de Apache HTTPD 2.2.21 o superior. Como alternativa, puede
aplicar una de las soluciones mencionadas en los avisos de Apache para CVE-2011-3192. La
versión 2.2.20 solucionó el problema, pero también introdujo una regresión.
8.5.4. Vulnerabilidad de Badlock de Samba
Factor de Riesgo
Medio
Descripción
La versión de Samba, un servidor CIFS / SMB para Linux y Unix, que se ejecuta en
el host remoto, se ve afectada por una falla conocida como Badlock, que existe en el
Administrador de cuentas de seguridad (SAM) y en la Autoridad de seguridad local (LSAD).
Debido a una negociación de nivel de autenticación incorrecta a través de los canales RPC
(Remote Procedure Call), un atacante que sea capaz de interceptar el tráfico entre un cliente
y un servidor que aloja una base de datos SAM puede explotar esta falla para forzar una
degradación del nivel de autenticación, lo que permite la ejecución de llamadas de red Samba
arbitrarias en el contexto del usuario interceptado, como ver o modificar datos de seguridad
sensibles en la base de datos de Active Directory (AD) o inhabilitar servicios críticos.
124
Existen varios ataques MITM (Man in the Middle) que pueden realizarse contra una
variedad de protocolos utilizados por Samba. Esto permitiría la ejecución de llamadas de red
Samba arbitrarias utilizando el contexto del usuario interceptado. Un ejemplos del impacto
de interceptar tráfico de red de administrador del servidor SAMBA es la posibilidad de ver o
modificar secretos dentro de una base de datos, incluidos los hashes de contraseñas de
usuario o los servicios críticos de apagado. Si el usuario interceptado fue estándar se podrían
modificar permisos de usuario en archivos o directorios.
Además, los servicios de Samba son vulnerables a una denegación de servicio de un
atacante con conectividad de red remota a dicho servicio.
Hosts Afectados
10.254.1.206 (puerto 139/tcp/smb)
10.254.0.32 (puerto 445/tcp/cifs)
10.254.1.180 (puerto 445/tcp/cifs)
10.254.1.204 (puerto 445/tcp/cifs)
10.254.1.205 (puerto 445/tcp/cifs)
10.254.1.207 (puerto 445/tcp/cifs)
10.254.1.208 (puerto 445/tcp/cifs)
10.254.1.251 (puerto 445/tcp/cifs)
Evidencia
A través de la ejecución de un script de Nmap sobre estos hosts se puede corroborar
que la versión de Samba instalada está dentro de las afectadas por dicha vulnerabilidad.
125
Solución
Aplicar los parches proporcionados por el equipo de Samba y SerNet para
EnterpriseSAMBA / SAMBA+.
Las versiones parchadas son (tanto la versión de seguridad provisional como final
tienen los parches): 4.2.10 / 4.2.11, 4.3.7 / 4.3.8 y 4.4.1 / 4.4.2.
Con el lanzamiento de Samba 4.4.0 el 22 de marzo la rama de lanzamiento 4.1 ha
sido marcada DESCATALOGADA (ver Samba Release Planning). Hay que tener en cuenta
que Samba 4.1 y siguientes están por lo tanto fuera de soporte, incluso para arreglos de
seguridad. No habrá lanzamientos de seguridad oficiales para Samba 4.1 y debajo publicados
por el Equipo de Samba o SerNet (para EnterpriseSAMBA). Se recomienda que los usuarios
realicen la actualización a una versión admitida.
Algunos distribuidores pueden optar por enviar las versiones 4.4.1, 4.3.7 y 4.2.10 y
agregar parches de regresión encima de ellos, debido a la gran escala y complejidad de esta
versión. Algunos también pueden retrotraer los parches a versiones anteriores. Lo
recomendable es ponerse en contacto con el proveedor de Samba para obtener más detalles.
Otras posibles mejoras son:
- Mitigación de ataques de hombre en el medio (MITM): Las protecciones de red que
podrían utilizarse son los ataques MITM que incluyen el reconocimiento de DHCP,
ARP Inspection y 802.1x. Se recomienda que los administradores establezcan estas
opciones adicionales, si son compatibles con su entorno de red:
Firma del servidor = obligatorio
Ntlm auth = no
Sin la firma del servidor = obligatorio, los ataques de Man in the Middle siguen
siendo posibles contra el servidor de archivos y el controlador de dominio clásico /
NT4-like / Samba3. Hay que tener en cuenta que esto tiene un gran impacto en el
126
rendimiento del servidor de archivos, por lo que se debe decidir entre el rendimiento
y la seguridad.
Sin 'ntlm auth = no', puede haber clientes que no utilicen NTLMv2, y estas
contraseñas observadas pueden ser forzadas brutalmente usando recursos de
computación en nube o tablas de arco iris.
- Mitigación de ataques de denegación de servicio (DoS): Aplicar reglas de
cortafuegos en el servidor para permitir la conectividad sólo desde direcciones de
confianza.
El protocolo SMB, de forma predeterminada, sólo cifra credenciales y
comandos mientras los archivos se transfieren en texto plano. Se recomienda que en
escenarios confidenciales de seguridad / privacidad el cifrado se use para proteger
todas las comunicaciones.
Samba añadió cifrado en la versión 3.2 en 2008, pero sólo para clientes de
Samba. Microsoft agregó soporte de cifrado SMB a SMB 3.0 en Windows 8 y
Windows Server 2012. Sin embargo, ambos tipos de cifrado sólo protegen las
comunicaciones, tales como transferencias de archivos, después de que la
negociación SMB y los comandos se hayan completado.
El cifrado de Samba / SMB es una buena práctica pero no es suficiente para
protegerse contra estas vulnerabilidades. El cifrado a nivel de red, como IPSec, es
necesario para una protección completa como solución
8.6. Vulnerabilidades de divulgación de la información
8.6.1. Divulgación de información de transferencia de zona de servidor DNS (AXFR)
Factor de Riesgo
Alto
Descripción
El servidor de nombres remoto permite realizar transferencias de zona DNS.
Una transferencia de zona permite que un atacante remoto rellene instantáneamente
una lista de blancos potenciales. Además, las empresas a menudo utilizan una convención de
nomenclatura que puede dar indicaciones sobre una aplicación principal de servidores (por
127
ejemplo, proxy.example.com, payroll.example.com, b2b.example.com, etc.).
Como tal, esta información es de gran utilidad para un atacante, que puede utilizarla
para obtener información sobre la topología de la red y detectar nuevos objetivos.
CVE: 1999-0532
OSVDB: 492
Hosts Afectados
10.254.0.3 (puerto 53 /tcp/dns)
10.254.0.5 (puerto 53 /tcp)
Evidencia
Mediante la utilización de un script a través de la herramienta Nmap se verifica que
los hosts implicados permiten realizar transferencias de zona DNS.
Dicho script envía una consulta AXFR al servidor DNS. El dominio se define en la
línea de comandos a través del argumento dns-zone-transfer.domain, como se puede observar
en las imágenes. Seguido del dominio se debe especificar la IP del host objetivo. Si la
consulta es exitosa, todos los dominios y tipos de dominio se devuelven junto con los datos
específicos de tipo común (SOA/MX/NS/PTR/A).
Figura 8-42: Ejecución del script de Nmap dns-zone-transfer para el domino unicen.edu.ar en la ip 10.254.0.3
128
Figura 8-43: Ejecución del script de Nmap dns-zone-transfer para el domino unicen.edu.ar en la ip 10.254.0.5
Solución
Limitar las transferencias de zona DNS sólo a los servidores que necesitan la
información.
8.6.2. POP3: Permite inicio de sesión con texto plano
Factor de Riesgo
Alto
Descripción
El host está ejecutando un demonio de POP3 que permite inicio de sesión con texto
plano sobre conexiones sin cifrar. Un atacante puede descubrir nombres de usuarios y
contraseñas mediante sniffeo del tráfico al demonio POP3.
Hosts Afectados
10.254.0.152 (puerto 110/tcp/pop3)
Evidencia
Mediante un escaneo con la herramienta Nmap se puede apreciar que el servicio
POP3 está expuesto en el puerto 110, el cual por convención tiene una seguridad de texto
plano.
129
Figura 8-44: Escaneo de versiones con Nmap a la dirección Ip 10.254.0.152
Solución
Contactar al fabricante para solucionar el problema o cifrar el tráfico mediante el uso
de túneles SSL / TLS.
8.6.3. Montaje del usuario compartido NFS
Factor de Riesgo
Alto
Descripción
Se ha podido revelar información potencialmente confidencial, como una lista de
directorios. Un atacante puede explotar este problema para obtener acceso de lectura y
posiblemente de escritura a archivos en el host remoto.
Hay que tener en cuenta que no se requieren privilegios de root para montar los
recursos compartidos remotos, ya que el puerto de origen para montar los recursos
compartidos es superior a 1024.
Hosts Afectados
10.254.0.32 (puerto 2049 /udp/rpc-nfs)
Evidencia
La herramienta Nmap provee dos scripts para detectar recursos compartidos de
archivos en red, nfs-ls y nfs-showmount.
El primero, intenta obtener información útil desde las exportaciones de archivos NFS.
El script empieza enumerando y montando las exportaciones NFS remotas.
130
Esta información también puede ser obtenida de manera manual, utilizando el
comando showmount. Este comando permite mostrar información de montaje para un
servidor NFS, para esto realiza consultas al demonio mount sobre el objetivo remoto por
información sobre el estado del servidor NFS en la máquina objetivo.
El script nfs-showmount es una optimización de dicho comando que muestra mucha
más información, como puede apreciarse en la figura 8-47.
Figura 8-45: Ejecución del script de Nmap nfs-ls para la ip 10.254.0.32 (primer fragmento)
Figura 8-46: Ejecución del script de Nmap nfs-ls para la ip 10.254.0.32 (segundo fragmento)
131
Figura 8-47: Ejecución del script de Nmap nfs-showmount para la dirección Ip 10.254.0.32
Solución
Configurar NFS en el host remoto para que sólo los hosts autorizados puedan montar
los recursos compartidos remotos. El servidor NFS remoto debe evitar las solicitudes de
montaje que se originan desde un puerto no privilegiado.
8.6.3. PostgreSQL Cuenta por defecto sin contraseña
Factor de Riesgo
Alto
Descripción
Es posible conectar al servidor de base de datos remoto PostgreSQL usando una
cuenta sin contraseña. Esto pone en riesgo todos los pilares de la seguridad. Empezando por
la autenticación, al poder ingresar con el usuario mencionado, y una vez dentro de la base de
datos se compromete la confidencialidad e integridad de los datos.
Hosts Afectados
10.254.1.252 (puerto 5432/tcp/postgresql)
132
Evidencia
Utilizando un scan básico de Nmap sobre el host objetivo se verifica que en el puerto
5432 existe una base de datos PostgreSQL. En el próximo capítulo se demuestra cómo se
logró el ingreso a la misma a través del uso de la herramienta Metasploit Framework.
Figura 8-48: Escaneo con Nmap a la dirección Ip 10.254.1.252
Figura 8-49: Fragmento de resultado de la figura 8-48 donde se presenta la información sobre el
servicio PostgreSQL
Vulnerabilidad
CVE-1999-0508: Una cuenta de usuario en un router, cortafuego o algún otro
dispositivo de red tiene una cuenta por defecto, null, en blanco o con ausencia de contraseña.
Solución
Iniciar sesión en el host y configurar una contraseña para cada una de las cuentas
afectadas utilizando el comando ALTER USER. Adicionalmente, configurar el servicio
editando el archivo pg_hba.conf para que requiera autenticación por contraseña para todos los
hosts remotos que tengan acceso legítimo a este servicio y requerir una contraseña local
utilizando la línea local all password.
133
8.6.4. Detección de páginas de ejemplo de XAMPP
Factor de Riesgo
Alto
Descripción
El servidor web remoto pone a disposición scripts de ejemplo de XAMPP, una
distribución de Apache fácil de instalar que contiene MySQL, PHP y Perl. No se recomienda
el acceso a estos ejemplos, ya que algunos son conocidos por revelar información
confidencial sobre el host remoto y otros pueden verse afectados por vulnerabilidades como
los problemas de secuencias de comandos entre sitios. Además, algunas páginas contienen
vulnerabilidades conocidas de secuencias de comandos entre sitios, inyección de SQL e
inclusión de archivos locales.
Hosts Afectados
10.254.0.249 (puerto 8080 /tcp/www)
Evidencia
Una vez descubierta la instalación de XAMPP en el host mediante el uso de escaneos
con la herramienta Nmap, se realizó una consulta a las posibles URLs que se suelen utilizar
para almacenar este tipo de páginas web que provocan la vulnerabilidad antes explicada.
Como puede observarse en figura 8-50, se encontró en el puerto 8080 una página
llamada index, en la cual es posible acceder a información sobre algunos servicios de host.
Figura 8-50: Página de ejemplo de XAMPP expuesta en el puerto 8080 de la dirección Ip 10.254.0.249
134
Solución
Consultar la documentación de XAMPP para obtener información sobre cómo
proteger las páginas de ejemplo, así como otras aplicaciones, si es necesario.
8.6.5. Servicio SMTP permite logueo con texto plano
Factor de Riesgo
Alto
Descripción
El host remoto está ejecutando un servidor SMTP que anuncia que permite
conexiones de texto sin cifrado sobre conexiones no cifradas. Un atacante puede ser capaz de
descubrir nombres de usuario y contraseñas realiza una técnica de sniffing sobre tráfico al
servidor si se utiliza un mecanismo de autenticación menos seguro (es decir, LOGIN o
PLAIN).
Hosts Afectados
10.254.0.160 (puerto 25/tcp/smtp)
Evidencia
Para evidenciar esta vulnerabilidad la primer acción a realizar es intentar autenticarse
con el servidor SMTP mediante los métodos inseguros LOGIN y PLAIN. Para de esta forma
constatar que están disponibles. Para esto se realizará una conexión mediante el protocolo de
red Telnet al puerto 25 de host a analizar.
Una vez establecida la conexión se introducirán los comandos “auth plain” y “auth
login”. En ambos casos el servidor responde con un 334 lo que indica que está esperando el
próximo paso de autenticación, por lo tanto ambos métodos están implementados.
Por último en se introducirán contraseña no válidas. La validez no es un factor
importante ya que lo que se necesita verificar aquí, es en qué formato arribarán al servidor
SMTP.
Figura 8-51: Evidencia de implementación del método auth plain
135
Figura 8-52: Evidencia de implementación del método auth login
Esta última verificación se hará mediante el uso de la herramienta Wireshark. Aquí se
ha definido un filtro para escuchar el tráfico hacia dicho host. De esta forma, en la image
inferior se puede apreciar que tanto para el método PLAIN, como también para LOGIN, las
respuesta se encuentran en formato de texto plano. Por lo tanto si un atacante pudiera
conseguir posicionarse entre el router y dicho host, y de esta forma escuchar el tráfico hacia
este último, sería capaz de capturar todas las contraseñas.
Figura 8-53: Captura de paquetes realizada mediante la herramienta Wireshark

Solución
Configure el servicio para que admita mecanismos de autenticación menos seguros
únicamente a través de un canal cifrado.
8.6.6. Servidor Web: detección de Proxy Inverso

Factor de Riesgo
Medio
Descripción
El servidor web remoto pareciera permitir que cualquier usuario anónimo lo use como
proxy inverso (reverse proxy). Esto puede exponer servicios internos para ser potencialmente
mapeados y encontrarse comprometidos.
136
Un proxy inverso es un tipo de servidor proxy que recupera recursos en nombre de un
cliente de uno o más servidores. Estos recursos se devuelven al cliente como si se originaran
en el servidor web en sí. Contrariamente a un proxy directo (foward proxy), que es un
intermediario para que sus clientes asociados se comuniquen con cualquier servidor, un proxy
inverso es un intermediario para que sus servidores asociados sean contactados por cualquier
cliente. [Apa11]
Hosts Afectados
10.254.1.203 (puerto 8080/tcp/www)
Evidencia
Para evidenciar esta vulnerabilidad se ha acudido a la herramienta Nmap, ejecutando
el script http-traceroute. Este script funciona enviando solicitudes HTTP con valores del
encabezado HTTP Max-Forwards que varían de 0 a 2 y verificando cualquier anomalía en
ciertos valores de respuesta como el código de estado, el servidor, Content-Type y
Content-Length encabezados HTTP y valores corporales como el título HTML. En respuesta
a esto, se ha detectado que el puerto 80 contenga dicha vulnerabilidad y pueda ser utilizado
como reverse proxy.
Figura 8-54: Ejecución del script de Nmap http-traceroute para la dirección ip 10.254.1.203
Solución
Deshabilitar o restringir el acceso al Reverse Proxy.
137
8.6.7. Apache Multiviews: Lista arbitraria de directorios
Factor de Riesgo
Medio
Descripción
El servidor web Apache corriendo en el host tiene una vulnerabilidad de divulgación
de información. Un atacante remoto no autorizado puede explotarla enviando una petición
especialmente diseñada y obtener una lista de directorios.
Vulnerabilidad
CVE-2001-0731: La versión de Apache con multivistas habilitadas permite a
atacantes remotos ver contenido de directorios y bypassear la página index a través de una
URL conteniendo la consulta string “M=D”.
BID: 3009
EDB-ID: 21002
Hosts Afectados
10.254.1.151 (puerto 80/tcp/www)
10.254.1.189 (puerto 80/tcp/www)
10.254.1.232 (puerto 80/tcp/www)
Evidencia
Mediante la herramienta Nmap se realizó un scan en el que se identificó un servidor
HTTP Apache corriendo en el puerto 80.
Además, se pudo obtener la versión de dicho servidor Apache, y consultando en bases
de datos de vulnerabilidades se encontró que se encuentra afectada por lo explicado
anteriormente.
138
Además, para tener mayor certeza, se accedió a la vista de directorios, como se puede
apreciar en la figura 8-56.
Figura 8-56: Vista de directorios para la dirección Ip 10.254.1.151
139
Solución
Actualizar a una versión de Apache superior. Alternativamente se puede deshabilitar
Multiviews.
8.6.8. Recuperación remota de información del caché del servidor DNS
Factor de Riesgo
Medio
Descripción
Uno de los aspectos más críticos de la seguridad de la información es la conciencia.
Uno debe ser consciente de todas las posibles debilidades de seguridad, por intrascendentes
que puedan parecer cuando se estudian de forma aislada. Siendo DNS el "motor invisible"
detrás de casi todos los servicios disponibles en Internet, parece pertinente crear conciencia
sobre una vulnerabilidad de divulgación de información conocida como DNS Cache
Snooping.
El DNS (por sus siglas en inglés Domain Name System, que significan Sistema de
Nombre de Dominios), es una base de datos distribuida y tolerante a fallas. Esta base de datos
contiene, entre otras cosas, información sobre dominios, nombres de host y cómo se
relacionan con las direcciones IP que están asignadas a los diversos sistemas informáticos
que componen Internet.
Al igual que con cualquier servicio basados en directorios, hay dos enfoques
principales para el usuario del sistema DNS:
- El editor, quien quiere hacer que su información esté disponible para que otros la
miren.
- El navegador, que consulta el sistema en busca de información para su uso personal.
Esta dualidad se transpone a la arquitectura DNS como una separación natural de la
funcionalidad, donde a veces un sistema DNS funcionará como un caché y almacenará
información consultada recientemente para optimizar otras consultas locales, y en otras
ocasiones, el sistema proporcionará información sobre los nombres de host y / o IP de los que
es responsable o "autoritativo".
La búsqueda en la caché de DNS (DNS Cache Snooping) es entonces el proceso de
determinar si un Registro de recursos (RR) determinado está (o no) presente en un caché de
DNS determinado. [Gra04]
140
Para este caso, el servidor DNS remoto responde a las consultas de dominios de
terceros que no tienen el bit de recursividad establecido. Esto puede permitir a un atacante
remoto determinar qué dominios han sido resueltos recientemente a través de este servidor de
nombres y, por lo tanto, qué hosts han sido visitados recientemente.
Por ejemplo, si un atacante estaba interesado en saber si su empresa utiliza los
servicios en línea de una institución financiera en particular, podrían utilizar este ataque para
construir un modelo estadístico sobre el uso de la empresa de esa institución financiera. Por
supuesto, el ataque también puede ser utilizado para encontrar socios Business-to-Business
(transmisión de información referente a transacciones comerciales, normalmente utilizando
tecnologías como el intercambio electrónico de datos), patrones de navegación web,
servidores de correo externos y más.
Una aclaración ante todo esto, es que en este caso se trata de un servidor DNS interno
no accesible a las redes externas, los ataques se limitarían a la red interna. Esto puede incluir
empleados, consultores y potenciales usuarios en una red de invitados o conexión WiFi si se
admite.
Hosts Afectados
10.254.0.3 (puerto 53/udp/dns)
10.254.0.5 (puerto 53/udp/dns)
10.254.1.221 (puerto 53/udp/dns)
10.254.1.222 (puerto 53/udp/dns)
Evidencia
Para evidenciar esta vulnerabilidad se aplicará una técnica de DNS cache snooping
basada en la realización de consultas no recursivas sobre el caché de DNS.
La forma más efectiva de husmear una caché de DNS es usar consultas iterativas. Uno
le pide a la memoria caché un registro de recursos de cualquier tipo (A, MX, CNAME, PTR,
etc.) configurando el bit RD (recursión deseada) en la consulta a cero. Si la respuesta se
almacena en caché, la respuesta será válida, de lo contrario, la caché responderá con
información de otro servidor que pueda responder mejor a nuestra consulta o, más
comúnmente, envíe de vuelta el contenido del archivo root.hints.
En la figura 8-57 se ha realizado una consulta al caché de DNS en 10.254.0.3 para la
dirección www.exa.unicen.edu.ar, con el registro A. Ante esto, el servidor devuelve un
registro que contiene una respuesta a la consulta (la sección ANSWER tiene entradas). Dado
141
que se ha realizado una consulta no recursiva, existe la certeza de que el registro ya estaba
almacenado en caché localmente, porque una consulta no recursiva indica a la memoria caché
de DNS que no use la recursión para encontrar una respuesta.
Figura 8-57: Consula del DNS www.exa.unicen.edu.ar en la cache de la dirección Ip 10.254.0.3

Solución
Contactar al fabricante del software del DNS para que repare este problema.
8.6.9. Microsoft Windows SMB Autenticación de Sesión NULL
Factor de Riesgo
Medio
Descripción
Es posible iniciar sesión con una sesión NULL, es decir, sin inicio de sesión o
contraseña. Dependiendo de la configuración, es posible para un atacante remoto no
142
autorizado aprovechar este problema para obtener información sobre el host. En este caso en
particular, fue posible enlazar con el pipe /browser.
CVE-1999-0519: La contraseña de un recurso compartido de NETBIOS/SMB es null,
no existe o está la contraseña por defecto.
CVE-1999-0520: Existe un control de acceso inapropiado para un recurso compartido
de NETBIOS/SMB crítico para el sistema.
CVE-2002-1117: Veritas Backup Exec 8.5 y versiones anteriores requieren que la
clave de registro RestrictAnonymous para Microsoft Exchange 2000 se establezca en 0, lo que
permite la inclusión anónima de la base de datos y recursos compartidos de SAM.
BID: 494
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs)
10.254.1.152 (puerto 445/tcp/cifs)
Evidencia
Con un scan sencillo de Nmap, se descubrió un servicio microsoft-ds abierto en el
puerto TCP 445, que suele ser utilizado por el protocolo SMB (Server Message Block), que
permite compartir archivos, impresoras, etcétera, entre nodos de una red de computadoras que
usan el sistema operativo Microsoft Windows.
Luego, nuevamente con la ayuda de Nmap, se ejecutó el script smb-os-discovery
sobre ese mismo puerto, para obtener más información. Dicho script intenta determinar el
sistema operativo, el nombre de la computadora, dominio, grupo de trabajo y el tiempo actual
sobre el protocolo SMB.
Para esto inicializa sesión con una cuenta anónima (o con una cuenta apropiada si se
ingresa como parámetro). En respuesta al inicio de sesión, el servidor enviará toda la
información mencionada.
Algunos sistemas, como Samba, blanquean su nombre y solo envían el dominio.
Otros sistemas, como algunos embebidos, simplemente envían toda la información. Y por
último, existen sistemas que blanquean varios campos de información, como por ejemplo el
tiempo actual, devolviendo un cero.
143
Figura 8-58: Escaneo con la herramienta Nmap para la dirección Ip 10.254.1.18, más escaneo con el
script smb-os-discovery para el puerto 445 de la misma Ip
Una vez obtenida la información necesaria, se procede a verificar si el host es

vulnerable a la autenticación con cuentas null, blank o sin contraseña. Esto se realiza
mediante el script smb-enum-shares con la herramienta Nmap. En la figura 8-59 se puede
observar las carpetas compartidas, en las que se aprecia el acceso de Lectura en IPC$.
Figura 8-59: Ejecución del script de Nmap smb-enum-shares para el puerto 445 en la Ip 10.254.1.18
En el próximo capítulo se mostrará el inicio de sesión exitoso a través del puerto 445
con una cuenta anónima.
144
Solución
Aplicar los siguientes cambios en los registros:
Establecer (Set):
- HKLM\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous=1
- HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\restrictnullses
saccess=1
Remover BROWSER de:
- HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\NullSessionPi
pes
Reiniciar una vez que el cambio en los registros se haya realizado.
8.6.10. AMQP Autenticación Texto Plano

Factor de Riesgo
Medio
Descripción
El servicio AMQP (Advanced Message Queuing Protocol) soporta uno o más
mecanismos de autenticación que permiten que las credenciales sean enviadas en texto plano.
Utilizando un ataque de Man in the Middle, un atacante puede interceptar paquetes de
conexión y obtener las contraseñas de los usuarios en texto plano, es decir, sin ningún tipo de
cifrado.
Hosts Afectados
10.254.1.171 (puerto 5672/tcp)
Evidencia
Utilizando la herramienta Nmap se ejecutó el script amqp-info, el cual brinda
información sobre el servicio AMQP corriendo en el puerto TCP 5672, como puede
observarse en la imagen.
Los mecanismos de autenticación disponibles son Plain y AMQPlain.
Plain: Autenticación Plana de SASL. Está habilitada por defecto en el servidor
RabbitMQ y clientes, y es también la autenticación por defecto más utilizada en la mayoría
de otros clientes.
145
AMQPlain: es una versión no estándar de Plain definida por la especificación AMQP
0-8. Se encuentra habilitada por defecto en el servidor RabbitMQ, y también en clientes
QPid’s Python.
Figura 8-60: Ejecución del script de Nmap amqp-info para el puerto 5672 en la Ip 10.254.1.171
Solución
Deshabilitar el mecanismo de autenticación por texto plano en la configuración del
servicio AMQP.
8.7. Vulnerabilidades de versiones deprecadas
8.7.1. Detección de versión de sistema operativo Unix sin soporte
Factor de Riesgo
Crítico
Descripción
Según su número de versión autoinformado, el sistema operativo Unix corriendo en
los hosts ya no posee más soporte. La falta de soporte implica que ya no se desarrollen
nuevos parches de seguridad para este producto por parte del fabricante. Como consecuencia,
es probable encontrar vulnerabilidades de seguridad.
146
Hosts Afectados
Figura 8-61: Salida de la herramienta Nessus, la cual muestra los host afectados separados por la
versión de Debian
Evidencia
Realizando un escaneo con la herramienta Nmap, se obtiene la versión del sistema
operativo de los hosts, y corroborando en los sitios oficiales de los distintos distribuidores se
puede verificar que muchos están deprecados, por lo que ya no reciben más soporte.
Con la opción -sV se determina la información de los servicios y versiones. Con la
opción -O se activa la detección del sistema operativo. --allports indica que se realice el
escaneo sobro todos los puertos. --version-all habilita todas las pruebas, lo que genera un
análisis más intensivo y también ruidoso. -vv incrementa la verbosidad, es decir, brinda más
información.
147
En la segunda imagen se observa que a través del puerto TCP 22 que tiene un servicio
SSH se descubre la versión del sistema operativo del host.
Es importante configurar el script de esta manera, ya que dependiendo de los puertos
abiertos y los servicios que estén corriendo, puede variar el método por el cual se encuentra la
versión del sistema operativo.
Figura 8-62: Escaneo de versiones (servicios y sistemas operativos) para todos los puertos de la dirección Ip
10.254.0.32 (primer fragmento)
148
Figura 8-63: Escaneo de versiones (servicios y sistemas operativos) para todos los puertos de la dirección Ip
10.254.0.32 (último fragmento)
Solución
Actualizar a la versión más reciente de cada sistema operativo Unix que tenga soporte
vigente.
8.8. Vulnerabilidades del día 0
8.8.1. MS17-010: Actualización de seguridad de Microsoft Windows SMB Server
Factor de Riesgo
Crítico
Descripción
Microsoft Windows Server Message Block 1.0 (SMBv1) tiene múltiples
vulnerabilidades que permiten la ejecución de código remoto debido al manejo inapropiado
de ciertas solicitudes. Un atacante remoto no autorizado puede explotar estas vulnerabilidades
a través de paquetes especialmente diseñado para ejecutar código arbitrario. Además, también
debido al manejo inapropiado de solicitudes, es posibles para un atacante obtener
información sensible.
EternalBlue, EternalChampion, EternalRomance y EternalSynergy son 4 exploits
desarrollados por el grupo conocido como Shadow Brokers para explotar estas
149
vulnerabilidades. Son considerados Zero Day todavía, ya que a la fecha de elaboración de
este informe recién pasaron 21 días.
Además la vulnerabilidad con código CVE-2017-0148 es aquella que permite la
explotación del actualmente famoso (por las repercusiones mediáticas y el alto grado de
daño) WannaCry.
Vulnerabilidades
CVE: 2017-0148, 2017-0147, 2017-0146, 2017-0145, 2017-0144, 2017-0143
IAVA: 2017-A-0065
OSVDB: 155635, 155634, 155620, 153678, 153677, 153676, 153675, 153674,
153673
BID: 96709, 96707, 96706, 96705, 96704, 96703
MSFT: MS17-010
Hosts Afectados
10.254.1.18 (puerto 445/tcp/cifs )
10.254.1.152 (puerto 445/tcp/cifs )
10.254.1.155 (puerto 445/tcp/cifs )
Evidencia
La primera acción que se realizó fue un escaneo con la herramienta Nmap utilizando
su script smb-os-discovery (el cual ya ha sido explicado con anterioridad). Dichos resultados
permiten ver que en el puerto 445 de estos hosts se encuentra expuesto un servicio que tiene
como sistema operativo Windows Server.
Figura 8-64: Ejecución del script de Nmap smb-os-discovery para el puerto 445 en la ip 10.254.1.155
150
Una vez que la existencia de Windows Server ha sido confirmada, se procede a hacer
uso de un nuevo script, en este caso es smb-vuln-ms17-010. Dicho script intenta detectar si
un servidor Microsoft SMBv1 es vulnerable a una vulnerabilidad de ejecución remota de
código (EternalBlue). La secuencia de comandos se conecta al árbol de comunicación de
interprocesos (IPC) para luego ejecutar una transacción FID en cero y comprueba si se
devuelve el error "STATUS_INSUFF_SERVER_RESOURCES" para determinar si el
destino no tiene parches contra ms17-010. Además, verifica los códigos de error conocidos
devueltos por los sistemas parcheados.
Se aclara que FID (por sus siglas en inglés File ID) es un identificador de archivo que
referencia a un archivo abierto en el servidor. Un FID devuelto de una operación de apertura
o creación, debe ser único dentro de una conexión SMB.
Luego de correr el script, se puede observar en sus resultados que las versiones de
Windows Server que se encuentran en los host identificados, efectivamente son vulnerables.
151
Figura 8-65: Ejecución del script de Nmap smb-vulns-ms17-010 para el puerto 445 en la ip 10.254.1.155
Solución
Microsoft ha publicado un conjunto de parches para Windows Vista, 2008, 7, 2008
R2, 2012, 8.1, RT 8.1, 2012 R2, 10 y 2016.
Para sistemas operativos Windows no compatibles, como Windows XP, Microsoft
recomienda que los usuarios interrumpan el uso de SMBv1 ya que carece de características
de seguridad que se incluyeron en versiones posteriores de SMB. SMBv1 se puede
deshabilitar siguiendo las instrucciones del proveedor proporcionadas en Microsoft
KB2696547. Además, US-CERT recomienda que los usuarios bloqueen SMB directamente
bloqueando el puerto TCP 445 en todos los dispositivos de límite de red. Para SMB sobre la
API de NetBIOS, bloquee los puertos TCP 137/139 y los puertos UDP 137/138 en todos los
dispositivos fronterizos de la red.
8.8.2. Detección de gusano Conficker
Factor de Riesgo
Crítico
152
Descripción
El host remoto parece estar infectado con el gusano Conficker. Dicho gusano posee la
capacidad de permitir al atacante ejecutar código arbitrario sobre el sistema operativo.
Además, el host infectado puede propagar el gusano a otros hosts. El host está infectado por
Conficker.A , Conficker.B o Conficker.C.
Hosts Afectados
10.254.1.152 (puerto 445/tcp/cifs)
Evidencia
Para evidenciar la siguiente vulnerabilidad se recurrirá a la herramienta Nmap, junto a
una combinación de scripts, los cuales son:
- p2p-conficker: Comprueba si un host está infectado según la comunicación entre
pares de Conficker. Cuando un Conficker.C o superior infecta un sistema, abre cuatro
puertos, dos TCP y dos UDP. Los puertos son aleatorios, pero están sembrados en la
semana actual y la IP del host infectado. Al determinar el algoritmo, uno puede
verificar si estos cuatro puertos están abiertos y puede ser escaneados para obtener
más información.
Una vez que se encuentran los puertos abiertos, la comunicación puede iniciarse
utilizando el protocolo personalizado de punto a punto (p2p) de Conficker. Si se
recibe una respuesta válida, se ha encontrado una infección válida de Conficker.
- smb-os-discovery: Este script ya ha sido utilizado y explicado con anterioridad, de
todas formas, la finalidad es descubrir las versiones del Sistema Operativo para luego
ver qué tan vulnerable es ante este tipo de malware.
- smb-vuln-conficker: Este script comenzó formando parte del smb-check-vulns, el cual
hace una revisión sobre las principales vulnerabilidades que pueden afectar a un host
con un servicio smb abierto. En este caso, solo se realizarán algunas pruebas para
verificar la probabilidad del host de estar infectado por un gusano Conficker.
Al correr este escaneo, se obtuvo como resultado que el host efectivamente está
infectado por el gusano, el cual probablemente sea un Conficker.C o inferior. Esta
vulnerabilidad debe de ser informada de inmediato a los responsables del Centro de Datos y
Comunicaciones debido a su criticidad y peligrosidad.
153
Figura 8-66: Ejecución de los scripts de Nmap p2p-conficker, smb-os-discovery, smb-vulns-conficker para el
puerto 445 en la ip 10.254.1.152
Solución
Actualizar el antivirus y realizar un escaneo completo del sistema operativo.
8.9. Resumen
Haciendo uso de los datos obtenidos en la fase de recolección de la información, en
este capítulo se han identificado y analizado vulnerabilidades existentes en el sistema a
auditar. Para esto se ha hecho uso de un conjunto de herramientas, cuyas principales se
describen a continuación.
La primer herramienta es Nmap, la cual fue utilizada mayormente junto a scripts
específicos para verificar que haya condiciones tales que den lugar a vulnerabilidades. Por
ejemplo validar que versiones de servicios o sistemas operativos, estén dentro de aquellas que
ya no cuentan con soporte.
La segunda herramienta es Nikto cuya función es la de escanear servidores web en
busca de malas configuraciones, detección de ficheros en instalaciones por defecto, listar la
estructura del servidor, versiones y fechas de actualizaciones de servidores, realizar tests de
vulnerabilidades XSS, ataques de fuerza bruta por diccionario, reportes en formatos txt, csv,
html, etc.
Siguiendo con la lista de herramientas se encuentra Nessus. Esta herramienta utiliza
Nikto y Nmap pero a su vez retorna resultados en formatos visuales fáciles de interpretar. De
esta forma, Nessus cumple la función de ser un programa de escaneo de vulnerabilidades en
diversos sistemas operativos. Consiste en un demonio (tipo especial de proceso informático
154
que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario)
llamado nessusd, que realiza el escaneo en el sistema objetivo, y nessus, el cliente (basado en
consola o interfaz gráfica) que muestra el avance e informa sobre el estado de los escaneos.
Por último, se utilizó el framework Metasploit, el cual proporciona la infraestructura
necesaria para automatizar tareas rutinarias y complejas. Esto permite que se concentre aún
más en los aspectos únicos o especializados de las pruebas de penetración y en identificar
fallas dentro de su programa de seguridad de la información.
Metasploit es un framework, ya que consta con una suite de herramientas que
cumplen distintos roles y ayudan en numerosas partes del proceso de pentesting. Para esta
fase, se volcaron todos los resultados obtenidos por Nessus y Nmap, para tener acceso de
manera más eficiente (mediante el uso peticiones por parámetros soportadas por el
framework) y así poder realizar análisis complejos de manera sencilla sobre grandes
cantidades de información.
Las vulnerabilidades encontradas se han separado en 6 categorías, las cuales son:
- Vulnerabilidades de desbordamiento de buffer, las cuales se producen cuando un
programa no controla la cantidad de datos que se copian en buffer.
- Vulnerabilidades de error de formato de cadena (format string bugs), la principal
causa en estos casos es que se acepte sin validar la entrada de datos proporcionada por
el usuario.
- Vulnerabilidades de Cross Site Scripting (XSS). En esta categoría se encuentran
ataques que permiten ejecutar scripts desarrollados en lenguajes tales como VBScript
o JavaScript, en una interfaz web.
- Vulnerabilidades de denegación del servicio, que provocan que un servicio o recurso
sea inaccesible a los usuarios legítimos.
- Vulnerabilidades de divulgación de la información, las cuales aparecen cuando
información sensible puede ser visualizada por usuarios no autorizados.
- Vulnerabilidades del día 0 (zero day). Una nueva vulnerabilidad para la cual no se
han creado parches o revisiones ya que aún no son conocidas por los usuarios y
creadores.
Por cada vulnerabilidad se especificaron las siguientes secciones:
- Factor de riesgo, el cual puede tomar los valores crítico, alto, medio y bajo.
155
- Descripción sobre la vulnerabilidad identificada, con el fin de que el usuario
comprenda el riesgo al que puede estar expuesto.
- Evidencia de la vulnerabilidad, donde se demuestra de manera empírica la existencia
de dicha vulnerabilidad.
- Y por último, la solución que el usuario debería implementar para suplir dicha
vulnerabilidad.
En base a las vulnerabilidades encontradas, en el siguiente capítulo se intentará
explotar un subconjunto de ellas para demostrar con un mayor nivel el riesgo e impacto que
estas tienen sobre el Centro de Datos de la UNICEN.
156
9. Fase 4: Explotación de las vulnerabilidades
A esta altura en el proceso de auditoría ya se conocen las principales vulnerabilidades
del sistema objetivo. Esta información es vital para conocer el nivel de seguridad con el que
se cuenta, sus puntos débiles y las acciones que se deben tomar para mejorar cada aspecto
vulnerable.
Por lo tanto, es esta etapa se realizará la explotación de alguna de las vulnerabilidades
encontradas, con el fin de demostrar fehacientemente cómo pueden ser utilizadas
exitosamente por un atacante y terminar causando un daño real a la integridad del sistema
auditado.
En este capítulo se concretarán ataques sobre un subconjunto de las vulnerabilidades
expuestas con anterioridad. Estos ataques contendrán una introducción teórica con la
explicación de las causas de dicha vulnerabilidad, como también, una demostración práctica
donde se apreciará cómo sucede la explotación y el impacto que puede llegar a tener.
Esta etapa sirve, por un lado, para cerciorarse que las vulnerabilidades no entren en la
categoría de falsos positivos. Por otro lado presentar la evidencia concreta de las distintas
explotaciones, genera una motivación innegable en el cliente de la auditoría a corregir todos
los problemas que hacen posibles a dichas vulnerabilidades. Por ejemplo, cambiar
configuraciones, actualizar versiones de software, cerrar o bloquear puertos expuestos, etc.
9.1. Ataques de Inyección de Código
Estos ataques son considerados amenazas a las aplicaciones debido a su impacto y a la

cantidad de vulnerabilidades que explotan. La inyección de código se refiere a la explotación
causada por el procesamiento de datos no válidos. Es utilizada para introducir código en
aplicaciones con el fin de cambiar su comportamiento o flujo de ejecución.
Muchos de estos problemas ocurren gracias a datos de entrada considerados de
manera incorrecta y por desconocimiento de sus efectos. A veces se asume de manera
equivocada cuestiones tales como que en los ingresos de datos los metacaracteres nunca
existirán, que solo se ingresarán los tipos de caracteres solicitados, que no se excederá
determinado tamaño o que los valores de las variables definidas por el servidor nunca serán
modificados.
157
Siguiendo este razonamiento, mientras más expuesto esté el código a ingresos de
datos externos por parte de un usuario, como puede ser un formulario HTML, mayor será el
peligro de que esto ocurra.
Existen una serie de aplicaciones que utilizan el lenguaje HTML pero que no
necesariamente están ligadas a los entornos web, como la recepción y el envío de correos
electrónicos con texto enriquecido, los archivos de ayuda, GUI (Interfaz Gráfica de Usuario,
o por sus siglas en inglés Graphic User Interface), entre otras.
HTML contiene una etiqueta propia que invoca al objeto script. En este caso, el
lenguaje llama a un script (desarrollado en Visual Basic Script, ActiveX, Flash o JavaScript,
entre otros) que realiza una función en particular, extendiendo el potencial del lenguaje. Los
ataques de HTML Scripting tienen por objetivo inyectar código de modo que sea retornado
como parte de la salida (output) de una aplicación, modificando su comportamiento según lo
solicitado.
Por otro lado, cada motor de renderización de HTML agrega funciones extra según el
desarrollador (la ejecución de determinados tipos de scripts, la instalación de plugins,
applets, etc.). Además, cada navegador tiene su propio motor de renderización. Todos estos
recursos le brinda al desarrollador la posibilidad de crear aplicaciones con mejores
funcionalidades y más atractivas. Pero desde el punto de vista de la seguridad, al sumar
funcionalidades, se agrega más código y, entonces, la probabilidad de error se incrementa, lo
que se traduce en un aumento de las posibilidades de explotación. [Jar12]
9.1.1. Ataque de Cross Site Scripting (XSS)
El Cross-Site Scripting o XSS es una técnica de ataque a partir de la cual se fuerza a

un sitio web a ejecutar el código suministrado por un atacante, pero cargándose en el
navegador del usuario. Por esta razón, se dice que es un ataque “del lado del cliente”. El
código puede ser HTML, JavaScript, VBScript, ActiveX, Java, Flash o cualquier tecnología
soportada por el navegador.
En HTML se utilizan caracteres especiales para distinguir el texto que se muestra del
código y el formato. Uno de los caracteres para definir elementos es <, que se incluye en el
comienzo de una marca (tag) HTML. Estos tags pueden afectar el formato de la página o
introducir código para ejecutarse del lado del cliente (será necesario que el navegador tenga
la capacidad de interpretarlos). Los tags de scripting más usados para embeber contenido
158
malicioso son <script>, <object>, <applet>, <embed> y <form>. También puede utilizarse
una nomenclatura alternativa de escritura inline, como: javascript:alert(‘Soy una alerta’).
En particular el tag <script> determina un código de script. Este código puede
encontrarse en cualquier parte de un documento (encabezado y cuerpo), de esta forma:
<script type=”text/javascript”>
function saludarAlMundo()
{
document.write(‘Hola mundo’);
}
</script>
Como también es posible definirlo dentro del tag HTML script o en un archivo
externo. En este caso se hará referencia al recurso donde se encuentre el código. Por ejemplo:
<script type=”text/javascript” src=”miscript.js”></script>
En condiciones normales, el script HTML que se le devuelve a un navegador desde un
servidor web, fue colocado allí por alguien que tiene la autoría de páginas HTML en dicho
servidor, como el webmaster. En el ataque de XSS, el ejecutante logra que el servidor
devuelva un script, sin contar con el nivel de permisos para realizarlo. El punto fundamental
de este tipo de ofensivas es que el atacante no modifica nada en el servidor, sino que solo
inyecta código que luego se ejecuta del lado del cliente. El ataque se lleva a cabo cuando el
código del servidor (server side-code) toma la entrada ingresada por el usuario y la repite de
modo que los datos sean ejecutados como script en el equipo cliente. Es decir que, en los
ataques de XSS, se busca forzar a un sitio web a repetir el código inyectado, de modo que sea
cargado en el navegador del usuario y ejecutado en dicho contexto. [Jar12]
Existen múltiples clasificaciones de ataques de este tipo, las cuales contemplan
distintos aspectos como la finalidad, nivel de persistencia, tipo de inyección, etc. Pero hay
una clasificación principal que engloba todas las demás y separa al Cross Site Scripting en 3
categorías. [Gro07]
- Tipo-0: utilizado para ejecutar código de forma remota con los permisos de otro
usuario.
- Tipo-1: ataque no-persistente o reflejado utilizado en páginas no estáticas.
- Tipo-2: ataque persistente, donde se inyecta código en páginas estáticas.
159
9.1.1.1. Tipo-0 (Basados en el DOM)
Esta vulnerabilidad es conocida como: DOM-Based cross-site-scripting o

cross-site-scripting local.
La diferencia entre el tipo-0 y los otros tipos de ataque, es que el código se inyecta a
través de la URL pero no se incluye en el código fuente de la página. Es decir, el código
nunca llega a la página, solo se ejecuta en el navegador.
En estos casos se le hace llegar una URL maligna a la víctima que tenga alguna
página hospedada en su máquina. Al acceder a dicha URL desde el navegador, el código
podría realizar alguna acción en la página hospedada, y como fue ejecutado en el navegador
de la víctima también se ejecuta con los permisos que tiene la misma en su máquina. Esto
podría llevar a realizar alguna acción remotamente en la página, como si este usuario las
hubiera realizado.
A grandes rasgos: el tipo-0 ejecuta código remotamente en la máquina de un usuario
con los permisos de este usuario. Un ejemplo de esta vulnerabilidad. puede ser la siguiente
página www.vulnerable.com/index.html, cuyo fragmento de código puede verse en la figura
9-1.
Figura 9-1: Fragmento de código con vulnerabilidad XSS de tipo-0
La página anterior se utilizaría para darle la bienvenida a algún usuario por su

nombre, ejemplo: http://vulnerable.com/index.html?nombre=Jose . Esto mostraría algo
como: “Hola Jose Bienvenido a nuestra página”.
La petición: http://vulnerable.com/index.html?nombre=<script>alert();</script>
daría resultado a un XSS.
160
El motivo de esto es el siguiente, el navegador de la víctima visita el enlace, hace una
petición HTTP a vulnerable.com y recibe la página index.html. Después, el navegador
empieza a interpretar el HTML de la página y forma la estructura del documento. El
documento contiene un objeto llamado ‘document’, que contiene una propiedad llamada
‘URL’, y esta propiedad es remplazada por la URL de la página actual, como parte de la
estructura del documento.
Cuando el intérprete llega al código Javascript lo ejecuta y modifica el HTML en
bruto. En este caso, el código hace referencia a ‘document.URL’, por este motivo la cadena
es incluida en el HTML al momento de interpretar el código, después es inmediatamente
interpretada y ejecutada en el contexto de la misma página, aqui es donde se da la condición
de inyección referente a XSS.
En el ejemplo anterior todavía se puede discutir que la inyección si llegó al servidor
(en el ‘?nombre=’ de la petición HTTP), y por lo tanto puede ser detectado como cualquier
ataque XSS. Pero aún así esto se puede arreglar. Por ejemplo, el siguiente ataque:
- http://vulnerable.com/index.html#name=<script>alert();</script>
El numeral (#) le dice al navegador que todo lo que se encuentra después de él es un
fragmento, y no parte de la petición. Los navegadores no mandan los fragmentos al servidor,
así el servidor solamente vería:
- http://vulnerable.com/index.html
Logrando que ni el servidor vea la inyección, esta técnica de evasión evita que los
navegadores envíen la inyección al servidor.
Una técnica muy utilizada para evitar inyecciones al servidor, es la implementación de
funciones que analizan todos los datos que manda el navegador con el fin de que si se
encuentra alguna inyección, se elimine. Este método de protección es inefectivo contra este
tipo de ataques, porque si los datos nunca llegan al servidor estos no pueden ser analizados.
Así se logra el XSS tipo-0. El navegador ejecuta código localmente, código que el
servidor no incrustó en una página, sino que el navegador incrustó él mismo. Así si la víctima
tiene una página vulnerable en su máquina (o en otro servidor), puedes realizar acciones
remotamente como si las hubiera hecho otro usuario.
161
9.1.1.2. Tipo-1 (Reflejados)
En lo que concierne a XSS, es la vulnerabilidad más común que hay, por lo usual se
encuentra en motores de búsqueda. El tipo-1 es una vulnerabilidad no-persistente o reflejada.
Este agujero de seguridad sucede cuando un servidor genera una página instantánea
de resultados de acuerdo a información proporcionada por el navegador (ejemplo: una
búsqueda). Si los datos proporcionados por el navegador no son validados y se incluyen en el
código fuente de la página, hay XSS.
Esta vulnerabilidad es catalogada como no-persistente porque la página con la
inyección solo es visualizada por la víctima. Tampoco es una página que existe o se mantiene
en el servidor (página estática), sólo se genera cuando un usuario proporciona cierta
información a alguna aplicación.
Además, se la llaman vulnerabilidad reflejada porque para realizar un ataque, el
código inyectado primero pasa del navegador al servidor, y luego del servidor a otro
navegador; como si fuera un reflejo.
Comparando con el ataque tipo-0, se pueden distinguir algunas diferencias. En el
tipo-1 el servidor procesa la inyección enviada por el usuario y la incluye en el código de la
página. Pero en el tipo-0 la inyección nunca llega al servidor, no es un ataque tipo reflejo
como el tipo-1. La información sale del navegador y entra al navegador.
9.1.1.3. Tipo-2 (Persistida)
Esta vulnerabilidad permite que se realicen los ataques más peligrosos y poderosos a
las aplicaciones web. Es conocida como vulnerabilidad persistente o almacenada.
La diferencia de este cross-site-scripting a los anteriores, es que la inyección se hace
en una página estática. La información proporcionada por el usuario es almacenada en la base
de datos, en el sistema de archivos o algún otro lugar; después es mostrada a otros usuarios
que visiten la página, por eso se dice que la vulnerabilidad “persiste”.
Aquí se encuentra el poderío del tipo-2, la inyección se quedará siempre en alguna
parte de la web, no estará en una página que se genera cada vez que se pasa información al
servidor. Las posibilidades de esta vulnerabilidad son muy amplias, pudiéndose realizar
desde un robo de cookies o troyanización de navegadores masivos, hasta un deface de la
página.
162
Un ejemplo típico de este tipo de vulnerabilidades son los foros de discusión, los
libros de visita o los tagboards. Si se logra inyectar código en un mensaje de estos sistemas,
todos los usuarios que carguen la página con el mensaje son afectados al fallo.
Una vez que un sitio web se identifica como potencialmente vulnerable, los atacantes
intentarán inyectar código de script en los datos que se van a almacenar en el servidor. El
código malicioso en sí mismo suele ser entregado manualmente por el atacante en los campos
de entrada de las páginas web vulnerables, pero hay casos en que los atacantes construyen
herramientas que inyectan secuencias de comandos de forma automática.
A diferencia de los otros ataques no persistentes, los ataques a vulnerabilidades de
tipo 2 no requieren una fase de ingeniería social, ya que las víctimas de este ataque no
necesitan ser atraídas al hacer click en un enlace creado. Sin embargo, al explotar estas
vulnerabilidades, los atacantes tratarán de atraer a más y más víctimas para visitar la página
web vulnerable, de modo que probablemente envíen mensajes de SPAM o lo promocionen en
sitios de redes sociales.
A modo de ejemplo, se podría plantear un caso en el que un foro contiene dicha
vulnerabilidad. En este caso, un atacante puede abrir un nuevo tema e insertar secuencias de
comandos maliciosas en el título o el cuerpo del tema. [Acu14]
Figura 9-2: Interfaz web que permite la inyección de código html
El contenido de la publicación del foro será almacenado por el servidor. Cuando las
víctimas navegan por temas o buscan determinadas palabras clave, pueden llegar al tema
163
infectado. Cuando el tema se carga, su contenido se enviará al navegador de la víctima y el
payload puede ser ejecutado.
Figura 9-3: Visualización de código inyectado desde un input de usuario, procesado y embebido en la interfaz
de usuario
Alternativamente, los atacantes pueden crear herramientas que publican

automáticamente scripts maliciosos en respuesta sobre temas populares, enviar mensajes
privados a los miembros del foro con contenido malicioso, etc.
Las consecuencias de estos ataques son enormes, ya que permiten la ejecución de
código arbitrario, normalmente con privilegios elevados. Los objetivos típicos de estos
ataques suelen ser el robo de datos y cookies.
9.1.1.4. Implementación de ataque de XSS Reflejado
Al realizar un escaneo sobre los sitios webs que contienen la vulnerabilidad referente
al método HTTP TRACE activado, se llegó al host con IP 10.254.1.184.
Este host contiene una aplicación web llamada Sistema Integral de Gestión de
Pasantías (SIGP). Al ingresar un usuario y contraseña inexistentes, la página vuelve a ser
cargada, pero esta vez se le adiciona un parámetro “data” con un mensaje de error.
164
Figura 9-4: Evidencia sobre la posibilidad de inyectar de texto plano en la interfaz de usuario
Siguiendo la figura 9-4, se puede apreciar que este parámetro se declara

explícitamente en la URL (1), para luego ser desplegado en la interfaz de usuario a modo
informativo (2).
No solo eso, inspeccionando el html que responde esta aplicación web, es posible ver
que el mensaje está plasmado directamente en el DOM (3). Esto indica la existencia de una
vulnerabilidad que da lugar a ataques de Cross Site Scripting.
Una vez identificado este caso, se modifica el valor de “data”, para así comprobar si el
mensaje desplegado en la pantalla es realmente definido por esa variable o si esta es una
desafortunada coincidencia y el propósito de “data” es otro y no tiene ningún impacto en la
definición del DOM de la página.
165
Figura 9-5: Inyección de texto plano en la interfaz de usuario
En la figura 9-5 se le asigna a la variable data el mensaje “Aquí se puede ingresar

código malicioso” (1). Una vez cargada la página, puede apreciarse que el mensaje de la
pantalla está definido por dicha variable (2) y es cargado directamente en el DOM (3).
El siguiente paso (figura 9-6) es inyectar un payload, en este caso será un componente
de tipo botón, el cual al hacer click tomará las cookies del usuario y las mostrará por pantalla.
166
Figura 9-6: Inyección payload en la interfaz de usuario
Payload: <button type=”button” onclick=alert(document.cookie)>Ingresar </button></div><div> (1)
Al cargarse nuevamente la página, dicho botón está incluido en la UI (2), e

inspeccionando el código html, se lo puede observar inyectado en el DOM (3).
Por último, en la figura 9-7, se puede comprobar que al realizar un click en dicho
botón, la alerta con las cookies del documento es desplegada.
167
Figura 9-7: Ejecución del payload inyectado
Cabe destacar que el payload utilizado tiene el fin de demostrar que la vulnerabilidad
existe y es explotable. Un atacante malintencionado puede realizar acciones realmente
dañinas, como robar las credenciales del usuario o modificar el correcto funcionamiento del
sistema.
9.1.2. Inyección de Código en servicio SMTP
La seguridad en la capa de transporte (TLS, por sus siglas en inglés Transfer Protocol
Layer), es un protocolo criptográfico definido por el Grupo de Trabajo de Ingeniería de
Internet (IETF, por sus siglas en inglés Internet Engineering Task Force) utilizado para
garantizar comunicaciones seguras por una red.
Muchas aplicaciones con cliente SMTP no verifican que el servidor TLS esté
certificado. Estos clientes SMTP son vulnerables a ataques tales como la inyección de
comandos. Sus sesiones TLS están encriptadas pero no protegidas, por lo tanto, una falla de
inyección de texto plano puede existir en dichos clientes, la cual se da en la forma que
manejan las respuestas de SMTP sobre TLS del servidor.
SMTP no es el único protocolo vulnerable a estos ataques. Otros ejemplos son POP3,
168
IMAP, NNTP y FTP. Implementaciones de estos protocolos pueden verse afectados por el
mismo defecto.
Existen dos formas en que los protocolos de texto sin formato pueden proporcionar
encriptación con TLS. La primer forma es escuchando en dos puertos: un puerto que es
siempre texto sin formato y un segundo puerto que siempre está encriptado con TLS. La otra
forma es usando un solo puerto en el que la comunicación comience sin cifrar, pero pueda
"actualizarse" a una conexión encriptada TLS utilizando un comando de nivel de aplicación
específico para el protocolo.
HTTP / HTTPS usa exclusivamente el primer enfoque, con los puertos 80 y 443. El
segundo enfoque, llamado STARTTLS, es utilizado por SMTP, XMPP, IMAP y POP3,
aunque varios de estos protocolos también son compatibles con el primer enfoque.
Cuando IETF estandarizó el uso de TLS con IMAP y POP3 en 1999, prescribió el
uso de STARTTLS y dio varias razones por las cuales STARTTLS debería usarse en lugar
de un TLS alternativo. Estas fueron básicamente:
1. Los puertos separados llevan a un esquema de URL separado, lo que significa que el
usuario tiene que elegir entre ellos. El software suele ser más apto que el usuario a la
hora de tomar estas decisiones.
2. Los puertos separados han provocado que los clientes implementen solo dos políticas
de seguridad: “utilizar TLS” o “no utilizar TLS”. La política de seguridad deseable
"utilizar TLS cuando esté disponible" sería engorrosa con el modelo de puerto
separado, pero es simple con STARTTLS.
3. Los puertos separados implican un modelo de "seguro" o "no seguro", que puede ser
engañoso. Por ejemplo, el puerto "seguro" puede ser inseguro porque está utilizando
software criptográfico export-crippled, el cual está limitado a una clave de tamaño
pequeño. De esta manera, el texto cifrado que se consigue con él puede descifrarse
por medio de fuerza bruta. En su caso contrario, el puerto normal podría estar
utilizando un mecanismo SASL que incluye una capa de seguridad.
4. Los números de puerto son un recurso limitado.
El problema es que salvo la cuarta razón, se han encontrado argumentos suficientes

como para desacreditar el resto de estas razones previamente mencionadas.
169
Comenzando por el motivo número uno, el cual no siempre es cierto. A menos que el
software mantenga una base de datos de los hosts que deberían usar TLS, es incapaz de
elegir entre TLS y no TLS en lugar del usuario sin ser susceptible a ataques activos.
De la misma manera, el segundo motivo es discutible ya que "utilizar TLS cuando
está disponible" también es susceptible a ataques activos. Ya que si el software detecta que
TLS no está disponible, no tiene forma de saber si es porque el servidor no lo admite o si un
atacante lo está bloqueando.
Por último, la razón tres puede haber tenido algún sentido en 1999, pero ciertamente
no lo hace hoy. La preocupación de la cifra de exportación se debatió cuando se eliminaron
los controles de exportación en 2000, lo que provocó la desaparición de cifras cifradas por la
exportación. Si bien en ese momento las capas de seguridad SASL eran de lo más viable, en
la actualidad TLS las ha superado.
Entonces, STARTTLS realmente no es mejor que usar un puerto alternativo de TLS.
Pero eso no es todo. Hay varias razones por las que STARTTLS es realmente peor para la
seguridad.
La primera de ellas es que STARTTLS hace que sea imposible finalizar TLS de
forma independiente del protocolo. Resulta trivial terminar un protocolo de puerto
independiente como HTTPS en un software proxy como titus (Totally Isolated TLS
Unwrapping Server, o en su traducción al castellano, Servidor Desempaquetado TLS
Totalmente Aislado ) o en un balanceador de carga de hardware. Tan solo se debe aceptar la
conexión TLS y generar un proxy sobre el texto plano enviado al puerto no-TLS del servidor.
Por otro lado, la terminación de un protocolo STARTTLS requiere que el terminador TLS
comprenda que el protocolo es proxy, por lo que puede vigilar el comando STARTTLS y
solo actualizar a TLS una vez que se envía el comando.
Esto es preocupante ya que es deseable terminar la conexión TLS en servidores
SMTP, IMAP y XMPP dentro del entorno altamente aislado de titus, para que una
vulnerabilidad en la implementación de TLS no pueda comprometer el estado de ellos.
Desafortunadamente STARTTLS hace que esto sea innecesariamente difícil de concretar.
Otra forma en que STARTTLS perjudica la seguridad es agregando complejidad.
Aquí es donde se puede encontrar como ejemplo la vulnerabilidad que se explotará a
continuación, la cual lleva el identificador CVE-2011-0411. Esta vulnerabilidad es causada
por implementaciones de SMTP que no descartan comandos enlazados con el comando
170
STARTTLS. De esta forma se permite inyectar comandos SMTP que serán ejecutados por el
servidor durante la fase de la conexión que se supone que debe estar protegida con TLS.
Es posible demostrar este problema modificando tan solo una línea del código fuente
del comando s_client en OpenSSL. Este comando puede establecer una conexión con soporte
directo TLS, SMTP sobre TLS, o un puñado de otros protocolos sobre TLS. En este caso se
modificará la línea 1129 (con OpenSSL 1.0.0, archivo ubicado en /apps/s_client.c).
Línea original: BIO_printf (sbio, "STARTTLS \ r \ n");
Línea modificada: BIO_printf (sbio, "STARTTLS \ r \ nRSET \ r \ n");
Figura 9-8: Inyección de comando RSET en el archivo s_client.s
De esta forma, el comando s_client envía el comando STARTTLS ("encender TLS")

inmediatamente seguido de un comando RSET. Este comando se utiliza en condiciones
normales para especificar que la transacción del correo debe ser abortada. Cualquier emisor,
receptor y data del correo debe ser abortada, a su vez los buffers y tablas de estado deben
171
limpiarse. El receptor debe enviar “250 OK” de respuesta a este comando sin ningún
argumento. Esto es efectivamente equivalente a un NOOP emitido inmediatamente luego de
un comando EHLO.
Ambos comandos se envían como texto plano en el mismo paquete TCP / IP, y llegan
juntos al servidor. Los "\ r \ n" son los caracteres de retorno y de nueva línea, estos son
necesarios para finalizar un comando SMTP.
Cuando un servidor SMTP tiene la falla de inyección de texto plano lee primero el
comando STARTTLS, cambia al modo SMTP-sobre-TLS y, solo en ese caso, el servidor lee
el comando RSET.
Se debe tener en cuenta que que el comando RSET se transmitió durante la fase
SMTP de texto sin pantalla cuando no hay protección, dado esto, el servidor lee el comando
como si se recibiera a través del canal protegido por TLS.
Figura 9-9: Verificación de ejecución del comando RSET (inyectado)
Por lo tanto, el resultado del comando s_client mostrará dos "250" como respuestas
del servidor SMTP en lugar de uno. El primer "250" es normal y está presente incluso
cuando el servidor no está defectuoso. La segunda respuesta "250" es para el comando
RSET, e indica que el servidor SMTP tiene la falla de inyección de texto plano.
Es importante aclarar que se utilizó el comando RSET ya que es relativamente
inofensivo y cuadra de forma oportuna para ejemplificar este ataque. Pero un atacante real
puede hacer uso de combinaciones de comandos muchos más dañinos, los cuales pueden
generar un flujo de acción no deseado que comprometa sustancialmente la seguridad del
servicio.
172
9.2. Explotación sobre Base de Datos
En lo referente a seguridad a las bases de datos, existen numerosas cuestiones que

pueden llevar a vulnerabilidades explotables por atacantes. Algunos ejemplos de esto pueden
ser los siguientes:
- Privilegios excesivos: Cuando a un usuario se le entregan privilegios de la base de
datos que excedan los requerimientos de su puesto de trabajo, el riesgo que se crea
puede ser innecesario.
- Abuso de privilegios: Muchos de los usuarios pueden llegara a abusar de los
privilegios de acceso de datos legítimos para fines no autorizados. Por ejemplo:
suministrar información confidencial de un cliente, sustraer información de la
compañía para su propio lucro.
- Elevación de privilegios no autorizados: Los atacantes pueden aprovechar las
vulnerabilidades en el software de gestión en la base de datos para convertir los
privilegios de acceso de bajo nivel en acceso de alto nivel. Por ejemplo, sin seguridad
de bases de datos, un atacante podría aprovechar una vulnerabilidad de
desbordamiento de búfer para obtener privilegios administrativos.
- Vulnerabilidades de la plataforma: Las vulnerabilidades en los sistemas operativos
pueden conducir al acceso no autorizado a datos y a la corrupción de los mismos. Las
herramientas de IPS son una buena manera de identificar y / o bloquear ataques
diseñados para aprovechar las vulnerabilidades de la plataforma de base de datos.
- Inyección de SQL: La mayoría de las aplicaciones web desarrolladas hoy en día hacen
uso de una base de datos para ofrecer páginas dinámicas y almacenar información
tanto de los usuarios como de la propia herramienta, el uso de este tipo de lenguaje ha
traído consigo la aparición de numerosas vulnerabilidades. Los Ataques de inyección
SQL implican a un usuario que se aprovecha de vulnerabilidades en aplicaciones web
y procedimientos almacenados para proceder a enviar consultas de bases de datos no
autorizadas, a menudo con privilegios elevados.
- Denegación de Servicio: En internet, un ataque de denegación de servicio (DDOS) es
el que se realiza cuando una cantidad considerable de sistemas atacan a un objetivo
único, provocando que el servicio no de más respuesta. Las técnicas más comunes de
173
DDOS incluyen desbordamientos de búfer, corrupción de datos, la inundación de la
red y el consumo de recursos.
- Vulnerabilidades en los protocolos de las bases de datos: Existe una constante
preocupación por la seguridad de la base de datos: Muchas veces la seguridad se ve
afectada por la configuración de los procesos de conexión. Las vulnerabilidades en
los protocolos de bases de datos pueden permitir el acceso no autorizado a datos, la
corrupción o la disponibilidad. Por ejemplo, SQL Slammer Worm se aprovecha de una
vulnerabilidad de protocolo de Microsoft SQL Server para ejecutar código de ataque
en los servidores de base de datos destino.
- La exposición de los datos de backup: El robo de información y la filtración de datos
confidenciales son noticias del día a día, Algunos ataques recientes de alto perfil han
involucrado el robo de cintas de backup de base de datos y discos duros. Es
importante que todas las copias de seguridad sean cifradas. De hecho, algunos
proveedores han sugerido que los futuros productos DBMS no deberían admitir la
creación de copias de seguridad sin cifrar. El cifrado de base de datos en línea es un
pobre sustituto de controles granulares de privilegios según expertos de seguridad de
base de datos.
- Autenticación débil: La autenticación basada en contraseña es probablemente una de
las funciones más importantes que se usan todos los días, sin embargo no se ha
evolucionado mucho desde los primeros sistemas informáticos de usuarios múltiples,
incluso cuando se desarrollan métodos más seguros. Los esquemas de autenticación
débiles permiten a los atacantes asumir la identidad de los usuarios de bases de datos
legítimos. Algunas de las estrategias de ataque a la autenticación incluyen la fuerza
bruta, la ingeniería social, phishing, etc.
Partiendo de esta última vulnerabilidad comenzará el siguiente caso de estudio. Se ha

detectado que en el puerto 5432 del host 10.254.1.252 hay un servicio que expone una
conexión a una base de datos PostgreSQL. Por lo que se intentará descubrir si hay algún
usuario mal configurado, lo que en este caso significa que no tiene ninguna contraseña o
tiene una contraseña de fábrica. De esta forma con solo saber su nombre se podrá acceder a
dicha base.
174
Haciendo uso de Metasploit, lo primero que se realizará es indagar sobre la existencia
de algún módulo que se encargue de intentar varios casos de autenticaciones en PostgreSQL.
Esta tarea se realiza mediante la invocación del comando search, el cual realiza una
búsqueda en la base de datos de módulos del framework.
Estos módulos son agrupados en las siguientes subcategorías:
- Módulo Auxiliary: Permite la interacción del framework con herramientas
externas como pueden ser escáneres de vulnerabilidades, sniffers, etc.
- Módulo Encoders: Proporciona algoritmos para codificar y ofuscar los
payloads utilizados una vez que un exploit resultó exitoso.
- Módulo Exploit: Aquí es donde se encuentran todos los exploits disponibles en
el framework.
- Módulo Payloads: Proporciona gran cantidad de códigos “maliciosos” que se
podrá ejecutar una vez haya tenido éxito un exploit.
- Módulo Post: Proporciona funcionalidades para la fase de Post Explotación.
- Módulo Nops: Permite realizar y/u obtener operaciones nop para mantener la
consistencia en el tamaño de los payloads.
Dentro de la consola de Metasploit (msfconsole), ingresando el comando search
postgresql, se obtiene la lista de módulos para PostgreSQL. Entre ellas se puede encontrar,
dentro del módulo Auxiliary, el script postgres_login.
Figura 9-10: Listado de módulos de Metasploit relacionados con PostgreSQL
175
En la figura 9-11, se ingresa el comando use seguido de la ruta completa a dicho
script con el fin de activar el uso del mismo. Continuado a esto se utiliza el comando show
options para visualizar los distintos parámetros del script junto a información adicional como
la descripción, si son requeridos u opcionales, etc.
Figura 9-11: Opciones para el exploit postgres_login contenido en Metasploit

Una vez analizados los parámetros, se puede concluir que solo se requiere especificar
el host al que se quiere examinar, lo que en este caso será el mencionado al comienzo de esta
sección (10.254.1.252).
La forma de asignarle un valor a un parámetro es mediante el formato:
set [nombre del parámetro] [valor del parámetro].
En forma adicional también se le debe indicar al exploit que se detenga una vez
conseguido un usuario con quien autenticarse. Dicha tarea se hace configurando el parámetro
STOP_ON_SUCCESS. Al terminar de declarar toda la información necesaria, se debe
ejecutar el script mediante el método run.
Figura 9-12: Configuración y ejecución del exploit posgres_login desde la consola del Framework Metasploit
176
En los resultados se encontró que el usuario postgres no cuenta de contraseña por lo
tanto es posible conectarse directamente a la base con él.
Para finalizar con la explotación de esta vulnerabilidad se ingresará, exitosamente, a
la base de datos utilizando el usuario encontrado. Esto se realiza ingresando el servicio de
conexión de PostgreSQL, el cual tiene el formato “psql -h [host] -p [puerto] -U [usuario]“.
Figura 9-13: Conexión a base de datos postgreSQL seguido de comando para listar sus esquemas
Una vez que se ha establecido la conexión con la base, se puede ingresar el comando
\l el cual desplegará el listado de los diferentes esquemas de base de datos que están presentes
en el servidor. Como se puede observar en la imagen superior existen 28 esquemas, los
cuales pueden llegar a contener información sensible e importante. Un ejemplo de estos
esquemas pueden ser comedor, telefonía e infraestructura. Por lo tanto, se procederá a
conectarse a uno de ellos mediante el comando: \connect [nombre base de datos].
Figura 9-14: Conexión al esquema comedor
177
Una vez realizada esta conexión se puede hacer uso del comando \dt para obtener el
listado de todas las tablas declaradas dentro de dicho esquema. Para comedor el listado
encontrado fue el siguiente:
Figura 9-15: Listado de tablas definidas en el esquema comedor
Luego de haber obtenido conocimiento sobre los distintos esquemas, el siguiente paso
es averiguar con qué privilegios consta el usuario que se está utilizando, y adicionalmente
que otros usuarios hay configurados en dicha base. En este caso se utilizará el comando \du,
el cual mostrará el listado con toda la información requerida.
178
Figura 9-16: Listado de usuarios junto a sus roles
Como se puede observar en la imagen superior, el usuario postgres es un super

usuario, con los siguientes atributos:
- Superuser: Este rol permite sobrescribir todas las restricciones dentro de la base de
datos, a su vez también le otorga la habilidad de crear nuevos usuarios. Un atacante puede
hacer uso de este rol para generar nuevos usuarios y escalar privilegios.
- Create role: Aquí se hace referencia a la habilidad de crear nuevos roles y modificar
y eliminar roles definidos con anterioridad. Un atacante puede utilizar este rol para quitar
permisos a roles existentes y de esta forma impedir que otros usuarios tomen acciones
resolutivas en caso de que un ataque sea llevado a cabo.
- Create DB: Otro permiso peligroso el cual otorga acceso a acciones determinantes
sobre la estructura de las bases de datos, pudiendo generar nuevos esquemas o, de manera
mucho más dañina, eliminar esquemas existentes. Un atacante puede utilizar este rol para
eliminar bases de datos y de esta forma vulnerar la integridad total de la información.
- Replication: Por último el usuario tiene este rol, el cual le permite generar réplicas
de las bases de datos, de esta forma puede generar copias y exportarlas a otras conexiones.
Un atacante puede hacer uso de este rol para robar toda la información existente.
Si se vuelve a hacer mención de las vulnerabilidades más comunes en las bases de
datos descritas al comienzo, aquí se está frente a unos privilegios excesivos.
179
9.3. Explotación de Server Message Block (SMB)
En los hosts 10.254.1.18 y 10.254.1.152 se encontró corriendo Server Message Block

(SMB) en el puerto 445, un protocolo de red que permite compartir archivos, impresoras,
etcétera, entre nodos de una red que usan Microsoft Windows. Este protocolo pertenece a la
capa de aplicación en el modelo OSI. En 1998 se renombró a SMB como Common Internet
File System (CIFS) y se le añadieron características tales como soporte para enlaces
simbólicos, enlaces duros (hard links) y mayores tamaños de archivo.
Estos hosts presentan 2 vulnerabilidades explotables relacionadas a este servicio

corriendo en el puerto 445. Por un lado la autenticación a través de un usuario blank y uno
anónimo, y por otro lado, la famosa vulnerabilidad MS17-010 más conocida como Wanna
Cry.
9.3.1. Autenticación con usuarios nulo y anónimo
En las figuras 9-17 y 9-18 se observa cómo a través de smbclient, se logra conectar
tanto con usuario blank como con un usuario anónimo, sin necesidad de ingresar contraseña.
Figura 9-17: Conexión al host 10.254.1.18 mediante el protocolo SMB utilizando un usuario vacio
180
Figura 9-18: Conexión al host 10.254.1.18 mediante el protocolo SMB utilizando el usuario anónimo
La figura 9-19 muestra cómo se logró conectar directamente al directorio compartido

IPC y la ejecución de algunos comandos intrascendentes con el simple fin de demostrar que
la conexión fue exitosa.
Figura 9-19: Conexión e interacción con el host 10.254.1.152 mediante el protocolo SMB utilizando un
usuario vacío
181
9.3.2. Explotación vulnerabilidad MS17-010
El 12 de mayo de 2017 se registró un ataque a escala mundial, al cual se lo denominó

WannaCry. Este ataque tomó control de un gran número de computadoras , muchas de ellas
pertenecientes a empresas e instituciones internacionales de gran importancia, para luego
encriptar sus datos y extorsionar a sus usuarios con dinero para volverlos a desencriptar.
Para poder acceder a los hosts, WannaCry utilizó la vulnerabilidad denominada
“EternalBlue”, la cual ha sido desarrollada por la Agencia de Seguridad Nacional
Estadounidense y posteriormente filtrada por el grupo “The Shadow Brokers”. Dicha
vulnerabilidad se aprovecha de computadoras que contienen el sistema operativo Windows
(primordialmente Windows 7 y Windows 2008 Server) explotando el protocolo SMB.
El 10 de marzo de 2017, el día posterior a haberse conocido esta falla, la empresa
Microsoft había sacado un parche para mitigar dicha vulnerabilidad, el cual fue denominado
MS17-010. Por ende, los host que fueron víctimas no contaron con esta actualización al
momento del ataque.
En el caso de la auditoría que es llevada a cabo en este informe, cuando la
vulnerabilidad MS17-010 fue encontrada, dada la criticidad de la misma, se le informó de
manera inmediata al personal responsable del Centro de Datos y Comunicaciones, quienes la
corrigieron de inmediato descargando el parche necesario.
Teniendo esto en cuenta, a continuación se mostrarán los pasos necesarios para
explotar MS17-010. Sin poder concretar el ataque ya que los hosts no se encuentran más
afectados por esta vulnerabilidad.
Lo primero a realizar es la descarga del exploit. Esto se hará clonando un repositorio
mediante la herramienta de control de versionado Git, para luego copiar el archivo
etenralblue_doublepulsar.rb (programa escrito en ruby) dentro de la carpeta donde se
encuentran los exploits para windows smb utilizados por el framework Metasploit.
Figura 9-20: Configuración para poder utilizar el exploit eternalblue_doublepulsar desde msfconsole
182
Una vez concluido lo anterior, se cargará el exploit desde el msfconsole mediante el
comando: use exploit/windows/smb/eternalblue_doublepulsar. En las figuras 9-21 y 9-22 se
podrán ver las opciones disponibles para configurar el ataque.
Figura 9-21: Información sobre el exploit eternalblue_doublepulsar (1er fragmento)
Figura 9-22: Información sobre el exploit eternalblue_doublepulsar (2do fragmento)
Realizando un repaso de cada opción tenemos lo siguientes parámetros para

configurar el ataque:
- Available targets (objetivos disponibles): el cual se definirá en 3 ya que el host al que
deberíamos atacar consta con un sistema operativo Windows Server 2003 (x64).
183
- DOUBLEPULSARPATH (ruta a Double Pulsar) y ETERNALBLUEPATH (ruta a
Eternal Blue): estos parámetros vienen configuradas por defecto con la locación del
exploit que se descargó al comienzo.
- PROCESSINJECT (proceso inyectado): hace referencia al nombre del procesos a
inyectarse. El cual como la descripción dice, se cambiará a lsass.exe.
- RHOST: es la dirección Ip del host objetivo, para este caso será 10.254.1.18.
- RPORT: se utilizará para indicar cuál será el puerto con el que se hará el contacto. Al
estar explotando una vulnerabilidad en el servicio SMB, el puerto ya estará por
defecto configurado en 445.
- TARGETARCHITECTURE (arquitectura del objetivo): Los valores para este
parámetro puede ser x86 o x64, haciendo referencia a la arquitectura del procesador
(32 o 64 bits). En este caso, se escogerá x64.
- WINEPATH (ruta de Wine): Wine es una reimplementación de la interfaz de
programación de aplicaciones de Win16 y Win32 para sistemas operativos basados en
Unix. Permite la ejecución de programas diseñados para MS-DOS, y las versiones de
Microsoft Windows 3.11, 95, 98, Me, NT, 2000, XP, Vista, 7, 8 y 10. En este caso
será utilizada para poder soportar una sesión de windows desde nuestra máquina
(unix), dicha sesión será la conexión con la máquina objetivo. Por lo tanto
configuraremos la ruta por defecto de wine.
Figura 9-23: Configuración del exploit eternalblue_doublepulsar para correr sobre el host 10.254.1.18
184
En la parte de la figura 9-23 se puede apreciar que además de los parámetros ya
descritos, también se seleccionó el payload reverse_tcp, utilizado para generar una conexión
con otro ordenador.
Y por último están los parámetros genéricos de todo exploit como por ejemplo el host
que escuchará la conexión, el cual siempre será ordenador desde el que se está realizando la
auditoría y correrá el ataque y el puerto desde donde se lanzará (4444).
El paso final solo será ejecutar el comando exploit. Si el host realmente era vulnerable
y el parche de seguridad no estaba añadido, se podrá tomar acceso de dicho objetivo.
9.4. Resumen
Partiendo de un subconjunto de vulnerabilidades identificadas en la fase de análisis de

vulnerabilidades, en este capítulo se han explotado empíricamente. De esta forma ha quedado
demostrado cómo pueden ser utilizadas exitosamente por un atacante y terminar causando un
daño real a la integridad del sistema auditado.
La primer categoría de ataque que se implementó fue la de inyección de código. Esto
hace referencia a la explotación causada por el procesamiento de datos no válidos. Es
utilizada para introducir código en aplicaciones con el fin de cambiar su comportamiento o
flujo de ejecución.
El primer tipo de vulnerabilidad explotada mediante este tipo de ataque fue del tipo
Cross-Site Scripting o XSS. En este caso se utilizó una técnica de ataque a partir de la cual se
fuerza a un sitio web a ejecutar el código suministrado por un atacante, pero cargándose en el
navegador del usuario. En lo que concierne a XSS, se realizó un ataque catalogado como
tipo-1, no persistente o reflejada.
Este agujero de seguridad sucede cuando un servidor genera una página instantánea
de resultados de acuerdo a información proporcionada por el navegador (ejemplo: una
búsqueda). Si los datos proporcionados por el navegador no son validados y se incluyen en el
código fuente de la página, hay XSS. Para este caso, se logró explotar dicha vulnerabilidad
inyectando un botón cuya acción de click desplegaba una alerta en la página de autenticación
perteneciente al Sistema Integral de Gestión de Pasantías (SIGP).
El segundo ataque de inyección de código fue sobre un servicio SMTP. Para este caso
se partió de la premisa que muchas aplicaciones con cliente SMTP no verifican que el
185
servidor TLS esté certificado. Estos clientes SMTP son vulnerables a ataques tales como la
inyección de comandos. Sus sesiones TLS están encriptadas pero no protegidas, por lo tanto,
una falla de inyección de texto plano puede existir en dichos clientes, la cual se da en la
forma que manejan las respuestas de SMTP sobre TLS del servidor.
En lo que respecta al comando STARTTLS, se explotó la vulnerabilidad identificada
como CVE-2011-0411. Esta vulnerabilidad es causada por implementaciones de SMTP que
no descartan comandos enlazados con el comando STARTTLS. De esta forma se permite
inyectar comandos SMTP que serán ejecutados por el servidor durante la fase de la conexión
que se supone que debe estar protegida con TLS.
Esto se demostró modificando tan solo una línea del código fuente del comando
s_client en OpenSSL. Este comando puede establecer una conexión con soporte directo TLS,
SMTP sobre TLS, para este caso se concateno luego de STARTTLS el comando RSET.
Ambos comandos se envían como texto plano en el mismo paquete TCP / IP, de esta forma,
cuando un servidor SMTP tiene la falla de inyección de texto plano lee primero el comando
STARTTLS, cambia al modo SMTP-sobre-TLS y, solo en ese caso, el servidor lee el
comando RSET.
Cabe destacar que para esta demostración se utilizó el comando RSET ya que se
considera inofensivo. De todas formas un atacante puede concatenar una cadena de
comandos que pueden llegar a alterar el correcto funcionamiento del comando s_client,
generando un comportamiento malicioso.
Continuando con la próxima categoría de ataques, se realizó una explotación sobre
Base de Datos. El tipo de vulnerabilidad que se tomó en este caso fue de autenticación débil.
Los esquemas de autenticación débiles permiten a los atacantes asumir la identidad de los
usuarios de bases de datos legítimos. Algunas de las estrategias de ataque a la autenticación
incluyen la fuerza bruta, la ingeniería social, phishing, etc.
Se detectó que en el puerto 5432 del host 10.254.1.252 hay un servicio que expone
una conexión a una base de datos PostgreSQL. Por lo que se intentó descubrir si hay algún
usuario mal configurado, lo que en este caso significa que no tiene ninguna contraseña o
tiene una contraseña de fábrica. De esta forma con solo saber su nombre se podrá acceder a
dicha base.
Haciendo uso de Metasploit, se utilizó el script postgres_login que se encuentra
dentro del módulo Auxiliary. Mediante este script se encontró la existencia del usuario
186
“postgres”, el cual no cuenta de contraseña por lo tanto es posible conectarse directamente a
la base con él.
Una vez que se ha establecido la conexión con la base, se desplegó el listado de los
diferentes esquemas de base de datos que están presentes en el servidor, los cuales pueden
llegar a contener información sensible e importante. Unos ejemplos de estos esquemas fueron
comedor, telefonía e infraestructura.
Luego de haber obtenido conocimiento sobre los distintos esquemas, el siguiente paso
fue averiguar con qué privilegios consta el usuario que con el que se ingresó, y
adicionalmente que otros usuarios hay configurados en dicha base. En este caso el usuario
utilizado es un super usuario, el cual genera una vulnerabilidad de privilegios excesivos. En
otras palabras si un atacante logra autenticarse con dicho usuario, este mismo tendrá los
privilegios suficientes como para modificar o borrar a otros usuarios, modificar o borrar
tablas o esquemas, etc.
Las últimas explotaciones realizadas fueron sobre hosts (10.254.1.18 y 10.254.1.152)
que exponen puertos con el protocolo de Server Message Block (SMB), el cual es un
protocolo de red que permite compartir archivos, impresoras, etcétera, entre nodos de una red
que usan Microsoft Windows.
La primer vulnerabilidad explotada fue la de “autenticación con usuario nulo y
anónimo”. Nuevamente otro escenario de autenticaciones débiles, las cuales permiten
establecer una conexión a cualquier usuario sin grandes dificultades, lo cual facilita mucho a
un posible atacante que quiera realizar alguna interacción malintencionada con dichos hosts.
Por último, en estos últimos hosts también se había detectado la famosa
vulnerabilidad MS17-010 más conocida como Wanna Cry. Por lo tanto se dió un instructivo
de como preparar y ejecutar un ataque para poder así explotarla.
A modo de conclusión, se realizó un abanico variado con distintos tipos de ataques,
cuyas fuentes de vulnerabilidad provienen de diferentes motivos, como lo son, software
desactualizado, mala configuración de entornos, o incluso errores de desarrollo en
aplicaciones alojadas en los host. Está gran lista de factores a tener en cuenta demuestra una
vez más la importancia que se le debe dar a la seguridad de un sistema o red.
187
10. Fase 5: Post-Explotación
Esta fase del Test de Intrusión se caracteriza por intentar mantener el acceso a los
distintos dispositivos de la red involucrados en la auditoría. Esto se realiza para que, en un
futuro, no haga falta aplicar nuevamente todas las técnicas que se utilizaron en un principio
para lograr el acceso a dichos dispositivos.
Para esto se utilizan diversas técnicas, algunas manuales y otras apoyándose en
herramientas, como por ejemplo Meterpreter. También se pueden utilizar distintos tipos de
malware (software malicioso), como pueden ser troyanos, spyware, virus, etcétera.
En el caso de estudio del presente trabajo final no es de utilidad intentar lograr acceso
a un dispositivo de la red para poder asegurar una vía de entrada a la misma, ya que por lo
explicado en capítulos anteriores, es muy fácil poder conectar un dispositivo propio a alguna
de las bocas de red, conectarse a cualquiera de las señales wi-fi disponibles e incluso tomar el
control físico de alguna de las computadoras de los distintos salones, laboratorios u oficinas.
Además, el ataque a través de la utilización de malware a alguno de los equipos de la
red no está dentro de las posibilidades de la auditoría, ya que sería demasiado riesgoso para la
integridad de los datos y difícil de volver hacia atrás el daño causado.
En la fase de Análisis de Vulnerabilidades, se encontró que el host 10.254.1.152 de la
red se encuentra infectado con el gusano Conficker. Dicho gusano, luego de infectar y
propagarse, desactiva varios servicios de Windows y además genera una conexión con un
servidor desde el cual recibe indicaciones. Dicho comportamiento es una manera de Post
Explotación. Por esto, ni bien se encontró la vulnerabilidad se dio aviso inmediato a los
responsables del Centro de Datos y Comunicaciones para que tomaran las medidas necesarias
ya que era un peligro crítico ocurriendo en tiempo real.
Otro caso interesante que se trató en la fase de Análisis de Vulnerabilidades, en el que
sí vale la pena realizar una técnica de Post Explotación manual es el del host 10.254.1.252,
donde se logró acceso a una base de datos Postgre. Esta explotación es considerada relevante
dentro de la auditoría ya que la información alojada en dicha base de datos también se puede
utilizar para mostrar riesgos, alcanzar objetivos de evaluación, determinar la configuración y
la función de los servicios e inclusive para penetrar aún más en una red de clientes y hosts.
188
De esta forma, el objetivo es conseguir un método para tener acceso inmediato cada
vez que se lo desee. Para esto se creará un nuevo usuario, el cual escalará todos los
privilegios posibles. Esta tarea será posible gracias a que el usuario vulnerado en la
explotación contiene el rol de “superusuario”, el cual lo habilita a crear usuarios nuevos, por
lo tanto se ejecutará el siguiente comando:
- CREATE USER [nombre usuario] WITH PASSWORD [password]
CREATEDB CREATEUSER;
Aquí se creará un usuario con contraseña y los roles requeridos para crear, modificar y
eliminar esquemas de base de datos y usuarios terceros con el mismo nivel de privilegios.
Figura 10-1: Creación de nuevo usuario en un servidor de base de datos con motor PostgreSQL
En la figura 10-1, en el último registro de la primer columna se puede observar el
usuario creado, unicen_pentest. En la segunda columna se pueden apreciar los atributos que
posee este nuevo usuario: Superuser, Create DB, Replication.
Con este usuario, aseguramos el acceso futuro al servidor y a las distintas bases de
datos que allí se hostean. Además, como se puede apreciar, para la Post Explotación realizada
no se utilizó ninguna herramienta adicional, más allá de las posibilidades que brinda Postgre.
Por lo que es importante no olvidar que a veces sólo hace falta utilizar el sentido común.
189
11. Conclusión
Luego de haber realizado una investigación sobre los estándares existentes hoy día
relacionados a la Seguridad Informática, las diversas técnicas y herramientas disponibles, y
las metodologías que se aplican a la hora de llevar a cabo las auditorías, se considera que
haber realizado el Test de Intrusión tanto aplicativo como de infraestructura fue una decisión
acertada para tener una primera imagen del estado de la seguridad del Centro de Datos y
Comunicaciones de la UNICEN.
Durante el proceso se debieron aplicar métodos de aprendizaje adquiridos durante la
carrera de Ingeniería de Sistemas para poder comprender conceptos totalmente nuevos,
analizarlos y poder tomar decisiones en base a esos análisis. Gracias a estos nuevos
conocimientos, se pudo colaborar a la mejora de un aspecto importante como es la seguridad
de la universidad que supo brindar esas herramientas de aprendizaje mencionadas.
Una red como la de UNICEN en la que si bien existe un centro de datos, pero no es
una red centralizada ya que posee muchos nodos independientes de propósitos tanto
específicos como generales, tareas tales como la administración y el mantenimiento de la
seguridad no son sencillas en lo absoluto.
Durante el Test de Intrusión se encontraron diversas vulnerabilidades, algunas de las
cuales eran evitables a través de cambios en la configuración de los servidores tanto http
como de base de datos. Otras tantas también se podrían haber evitado con las
correspondientes actualizaciones del software utilizado y los parches de seguridad que surgen
día a día con la constante aparición de nuevas amenazas..
No obstante, a medida que se fueron encontrando vulnerabilidades consideradas
críticas dado el nivel de facilidad con las que se pueden explotar o el alto grado de daño que
pueden causar, se fue dando aviso a los encargados del Centro de Datos y Comunicaciones de
forma inmediata, para que puedan solucionarlas en el acto.
Por otro lado, un factor que añade complejidad en el campo de la seguridad es el
índole público de mucha de la información, lo cual se encuentra estrictamente ligado a las
características de una institución pública como lo es la UNICEN.
Estrechamente relacionado con esta divulgación de información se encuentra la
facilidad con la que se puede acceder a información sobre las bandas de IP, saber las
190
versiones de los distintos servicios y sistemas operativos. Todo esto tampoco colabora a
mantener la red y sus nodos en un estado seguro.
Si bien estos problemas tienen solución, el escenario ideal sería la precaución, es
decir, intentar evitarlos antes de que ocurran. Por lo tanto, se recomienda que la universidad
cuente con un departamento avocado a realizar tareas como por ejemplo:
- Verificar que el software esté actualizado.
- Verificar que todos los parches de seguridad existentes estén actualizados.
- Verificar que las aplicaciones webs concernientes a la UNICEN no permitan
la posibilidad de ser inyectadas con código javascript (XSS), sql (SQL
Injection), etc.
- Verificar que todo sistema que requiera autenticación (aplicaciones webs,
bases de datos, servicios expuestos de mail, etc) constan de usuarios con
contraseñas adecuadas.
- Verificar que toda la información expuesta públicamente no revele o ayude a
revelar datos sensibles.
- Verificar que acciones tales como autenticaciones, se realicen mediante
protocolos seguros como ssh y no por medios que permitan la comunicación
mediante texto plano.
Estas tareas, al ser realizadas con periodicidad, incrementarían significativamente el
nivel de seguridad de la red ya que limitan la cantidad de puntos críticos que posibles
atacantes pueden explotar. Además, en caso de que un ataque esté siendo llevado a cabo, los
escaneos diarios ayudarán a encontrarlos a tiempo y anularlos, disminuyendo así los daños e
impactos negativos que puedan tener sobre la red en cuestión.
Se recomienda además, conformar un Sistema de Gestión de la Seguridad de la
Información (SGSI), con las políticas que se crean convenientes, como las mencionadas
previamente, y considerar la inclusión de diversos tests al proceso de gestión, como puede ser
el Test de Intrusión realizado en el presente trabajo. Este tipo de prácticas deben realizarse al
menos una vez al año, ya que como se dijo en capítulos anteriores, la seguridad es un estado y
por lo tanto puede cambiar de un momento a otro.
Al finalizar el Test de Intrusión, se presentó un informe técnico detallado sobre las
vulnerabilidades encontradas, sus potenciales riesgos al ser explotadas y cómo solucionarlas.
191
Además se llevó a cabo la documentación de todos los estándares, procesos y
herramientas que se han utilizado y que servirá de puntapié inicial para trabajos futuros.
192
12. Trabajos Futuros
El propósito de esta capítulo es el de enunciar tres posibles trabajos que podría
desprenderse de ésta tesis. Dichas propuestas pueden profundizar aspectos planteados en este
trabajo, como también pueden utilizarlo como base para obtener objetivos nuevos. El factor
común aquí es el de incrementar el nivel de seguridad de la Universidad Nacional de la
Provincia de Buenos Aires.
Dichos trabajos pueden ser continuaciones que profundicen ciertos aspectos o
abarquen aquellos que por cuestiones de alcance no fueron tenidos en cuenta. Otros también
pueden utilizar como ayuda la información recopilada a lo largo de la auditoría y utilizarla
con otros fines, como por ejemplo tareas referentes al área de redes e infraestructura.
12.1. Propuesta número 1: Continuar explorando distintas técnicas y herramientas

para el test de intrusión
La primer propuesta plantea ampliar aún más el nivel de investigación conseguido

hasta este momento. Esto se debe a que si bien auditoría de seguridad que se ha realizado en
esta tesis de grado a abarcado todas las posibles instancias de forma vertical, no lo hace de
manera horizontal. En otras palabras, se han hecho todas las etapas para poder proveer un
resultado concreto para ser entregado a las partes interesadas con un nivel de detalle completo
sobre cada vulnerabilidad y ataques concretados, pero esto no implica que dicha auditoría
haya abarcado todas las técnicas, tipos de vulnerabilidades y métodos de recolección de la
información.
Un área de gran importancia que no ha sido tomada en cuenta es la Ingeniería Social.
Dicha técnica hace referencia a la obtención de información confidencial, accesos y
privilegios a través de la manipulación de usuarios legítimos.
12.2. Propuesta número 2: Extender el test de intrusión existente a otras bandas

(direcciones Ip) dentro del Centro de Datos de la UNICEN
La Segunda propuesta plantea ampliar aún más alcance a nivel de infraestructura de la

auditoría realizada ya que en trabajo se han considerado solo las bandas referentes al
Rectorado y la UNICEN. Pero como se ha expuesto en la fase de recolección de información,
193
el número de bandas excede ampliamente a dichas dos. Entre ellas se encuentran las
pertenecientes a cada Facultad como por ejemplo: Exactas (192.168.0.0/19), Veterinaria
(192.168.32.0/19), Humanas (192.168.192.0/19) y Económicas (192.168.224.0/19).
En ellas quizás se encuentren vulnerabilidades de otro tipo, las cuales lleven a realizar
ataques diferentes a los implementados en este trabajo. También se puede aprovechar la
oportunidad para cambiar el conjunto de herramientas utilizado o profundizar más en técnicas
que no han sido tomadas tan en cuenta, como lo puede ser realizar un sniffing riguroso sobre
la red.
12.3. Propuesta número 3: Implementar un Sistema de Gestión de la Seguridad de

la Información (SGSI) para la Universidad
Por último la tercer propuesta plantea utilizar los resultados obtenidos para lograr
objetivos aún más ambiciosos. En este trabajo se ha realizado una auditoría de seguridad en la
que se han encontrado algunas de las vulnerabilidades de las que adolece el Centro de Datos
de la UNICEN. Junto a estas vulnerabilidades también se han documentado acciones a tomar
para anularlas. El análisis de dichas acciones puede llevar a la definición de comportamientos
bases para definir un Sistema de Gestión de la Seguridad Informática (SGSI), el cual consta
de políticas y procedimientos para administrar sistemáticamente la información sensible de
una organización.
La gestión de la seguridad de la información trata de la protección de los activos de
información frente a posibles infracciones de seguridad. Se refiere a todo tipo de información,
incluidos los formatos tanto electrónicos como de papel. Estos sistemas determinan cómo se
procesa, almacena, transfiere, archiva y destruye la información.
194
13. Bibliografía
[Jar12] “Ethical Hacking 2.0”, Héctor Jara y Federico G. Pacheco, Editorial Fox Andina en
coedición con DÁLAGA S.A., 2012.
[Pac09] “Hackers al descubierto”, Federico G. Pacheco y Héctor Jara. , Editorial Gradi S.A.,
2009.
[Fir05] “Seguridad Informática”, Sebastián Firtman, Editorial MP Ediciones S.A., 2005.
[Per13] “Pentesting con Kali”, Pablo González Pérez, Germán Sánchez Garcés y José Miguel
Soriano, Editorial 0xWORD Computing S.L., 2013.
[Ste92] “The Hacker Crackdown”, Bruce Sterling , 1992.
[Lev96] “Hackers, Heroes of The Computer Revolution”, Steven Levy, 1996.
[Her08] “Open Source Security Testing Methodology Manual (OSSTMM)”, Pete Herzog
(Manager Director de ISECOM), 2008.
[ISO27] Portal con información sobre la serie ISO 27000.
[Gro07] “XSS Attacks, Cross Site Scripting Exploits and Defense”, Jeremiah Grossman,
Robert Hanse, Petko D. Petkov, Anton Rager y Seth Fogie, Editorial Syngress, 2007.
[Acu14] “¿Qué es un XSS persistente?”, ACUNETIX, 2014.
[DoD83] “Trusted Computer System Evaluation Criteria (TCSEC)”, DoD, 1983.
[Arn07] “Introduction to ISO Security Standars”, Arnason & Willett, 2007.
[Eur91] “Information Technology Security Evaluation Criteria”, ITSEC, 1991.
[CSE93] “The Canadian Trusted Computer Product Evaluation Criteria (CTCPEC)”,
Communications Security Establishment.
[CC99] “Common Criteria for Information Technology Security Evaluation v2.1”, CC, 1999.
[Ois06] “Information Systems Security Assessment Framework (ISSAF)”, OISSG, 2006.
[OWA01] “Open Web Application Security Project (OWASP), 2001.
[Kan15] “Comparative Study of Penetration Test Methods”, Yong-Suk Kang, Hee-Hoon
Cho, Yongtae Shin and Jong-Bae Kim, 2015.
[PTE09] “Penetration Testing Execution Standard (PTES)”, 2009
[PCI15] “Information Supplement: Penetration Testing Guidance”, 2015.
[Sch08] “The Security Mindset”, Bruce Schneier, 2008.
[Ash99] “Guía de Gnu Privacy Guard”, Mike Ashley, 1999.
195
[Her16] “K0SASP - Pentesting con Mac OS X”, Daniel Herrero, 2016.
[Feb11] “Guía Inteco de Seguridad sobre Information Gathering”, Borja Merino Febrero,
José Miguel Holguín, 2011.
[Mar08] “Ventajas y Desventajas de la Virtualización”, Isabel Martín, 2008.
[Gro03] “Cross Site Tracing: The new Techniques and emerging threats to bypass current
web security measures using trace and XSS”, Jeremiah Grossman, 2003.
[Owa14] “Test HTTP Methods (OTG-CONFIG-006)”, Guía Test v4 OWASP, 2014.
[Apa11] "Forward and reverse proxies", The Apache Software Foundation, 2011.
[Gra04] “DNS Cache Snooping or Snooping The Cache For Fun and Profit”, Luis Grangeia,
2004.
196
14. Anexo
Acuerdo de confidencialidad
Suscrito entre:
La Universidad Nacional del Centro de la Provincia de Buenos Aires, Damián Blanco y
Matías Francisco Cattafesta
En fecha: ………………………
En la localidad de Tandil.
REUNIDOS
De una parte:
………………. , de DNI ………………, con domicilio en …………………. y CP ……… .
El Sr. ……………… interviene en nombre de La Universidad Nacional del Centro de la
Provincia de Buenos Aires, en la ciudad de Tandil.
A partir de ahora se la llamará Parte Informadora, por el resto del presente documento.
Y de otra:
………………. , de DNI ………………, con domicilio en ……………….. y CP ……. . El
Sr. ………………… interviene en su propio nombre y derecho.
A partir de ahora se la llamará Parte Receptora, por el resto del presente documento.
Ambas partes se reconocen recíprocamente la capacidad legal necesaria para la suscripción
del presente acuerdo, y al efecto,
EXPONEN
I. Que la Parte Receptora, con el fin de realizar su tesis de grado de la carrera,
realizará una auditoría de seguridad sobre algunos de los servicios del datacenter
de la universidad.
II. Que la Parte Informadora ha manifestado su interés en la realización de dicha
tesis, con el fin de colaborar con la Parte Receptora y además obtener un informe
sobre la seguridad de su sistema, con el objetivo de lograr mejorar sus
vulnerabilidades.
III. Que la Parte Informadora, solicita que durante el proceso se mantenga la
confidencialidad e integridad de la información accedida.
IV. Que la Parte Receptora, se compromete a mantener el secreto de toda la
información que de cualquier forma, con anterioridad o con posterioridad a la
firma de este documento, obtenga o haya obtenido del sistema pertinente y de la
parte Informadora, de tal forma que cualquier relación entre las Partes estará
197
sujeta a lo dispuesto en este Acuerdo de Confidencialidad y No Divulgación de
Información, que se regirá conforme a las siguientes
CLÁUSULAS
1-Definiciones:
1.1- “Información Confidencial”: significa toda la información referida a la Parte
Informadora que se le haya proporcionado por cualquier medio (oral, escrito,
electrónico, etc.) a la Parte Receptora, con anterioridad a la firma del presente
Acuerdo o durante su vigencia. Se adhiere además, toda la información a la que se
logre acceder durante el proceso de auditoría. No obstante lo anterior, queda
excluida la información que: (i) sea pública en el momento de facilitarse la
información; (ii) esté en posesión de la Parte Receptora previamente a ser revelada
y libre de cualquier restricción de uso.
1.2- “Integridad de la Información”: se refiere a no (i)borrar; (ii)dañar;
(iii)modificar/alterar de cualquier forma o manera, ninguna información
considerada confidencial o no.
2-Información Confidencial:
2.1- La Parte Receptora tratará y mantendrá toda la información como secreta y
confidencial, y no comunicará dicha información Confidencial, bien directa o
indirectamente, ya sea de modo escrito, oral o por cualquier otro medio, sin el
consentimiento previo y por escrito de la Parte Informadora, a cualquier otra
persona distinta de las personas autorizadas conforme a lo establecido en los
términos del presente Acuerdo.
2.2- No obstante lo establecido en la cláusula 2.1, la Parte Receptora podrá facilitar
la Información Confidencial a aquellos de sus Agentes que estrictamente
necesiten conocer la Información Confidencial, siempre y cuando la Parte
Receptora acredite que dichos Agentes han sido informados con anterioridad
de que la misma es considerada como confidencial y que se encuentran
obligados por un deber de confidencialidad en los términos establecidos en el
presente Acuerdo. La Parte Receptora será considerada en todo momento
como responsable de cualquier acción u omisión por parte de dichos Agentes
que pudiera considerarse como un incumplimiento del presente Acuerdo.
2.3- En caso de que alguna Información Confidencial sea copiada, facilitada o
utilizada de un modo distinto al permitido en el presente acuerdo, la Parte
Receptora lo notificará a la Parte Informadora en un plazo máximo de 72 horas
hábiles contadas a partir de que se tenga conocimiento de tal hecho y, si así lo
solicita la Parte Informadora, la Parte Receptora adoptará las medidas
necesarias, incluyendo el inicio de acciones legales, para subsanar dicho
incumplimiento y/o, si esto no fuera posible, evitar que más información sea
copiada, facilitada o utilizada sin autorización.
2.4- La parte receptora está de acuerdo en que la “Información Confidencial” que
reciba de la otra parte es y seguirá siendo propiedad de ésta última, a usar
dicha información únicamente de la manera y para los propósitos autorizados
en la Cláusula Sexta de este contrato y que este instrumento no otorga, de
198
manera expresa o implícita, derecho intelectual o de propiedad alguno,
incluyendo, mas no limitando, Licencias de uso respecto de la “Información
Confidencial”
3-Duración:
El deber de confidencialidad asumido por la parte Receptora a través de la
suscripción del presente será de carácter vitalicio sin contar con plazo fijo o
determinado de vigencia manteniéndose su obligación durante la totalidad de su vida .
4-Indemnización:
La Parte Receptora indemnizará a la Parte Informadora de cuantos gastos,
responsabilidades, daños y perjuicios se le pudieran irrogar por el incumplimiento por
su parte de cualquier obligación del presente Acuerdo.
5- Jurisdicción y Competencia:
Para el supuesto caso de controversia en cuanto a los alcances del presente, las
partes se someten a la jurisdicción y competencia del Juzgado Federal de Azul
renunciando a cualquier otro fuero y/o jurisdicción.
6- Domicilio Legales:
A todos los efectos legales las partes fijan sus domicilios en los denunciados
ut supra donde serán válidas todas las notificaciones judiciales y extrajudiciales.
En prueba de conformidad se firman cuatro ejemplares de un mismo tenor y a un solo
efecto, en Buenos Aires, a los ___ días del mes de ______ de 200_.
En prueba de conformidad firman las partes
………………………. ……………………..
199

Tesis Blanco y Cattafesta

Cargado por

Copyright:

Formatos disponibles

Tesis Blanco y Cattafesta

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Blanco y Cattafesta

Cargado por

Copyright:

Formatos disponibles

Universidad Nacional del Centro

Facultad de Ciencias Exactas

TRABAJO FINAL DE GRADO

EVALUACIÓN INTEGRAL DE SEGURIDAD INFORMÁTICA DEL CENTRO

Autores:​ Blanco, Damián – Cattafesta, Matías Francisco

2. Estado del Arte 17

3. Descripción del problema 37

4. Configuración del Entorno 39

5. Metodología del Test de Intrusión 43

6. Fase 1: Establecimiento de alcance y reglas de juego 49

7. Fase 2: Recolección de Información 50

8. Fase 3: Análisis de vulnerabilidades 86

9. Fase 4: Explotación de las vulnerabilidades 157

10. Fase 5: Post-Explotación 188

11. Conclusión 190

12. Trabajos Futuros 193

13. Bibliografía 195

14. Anexo 197

Es de gran importancia para el Centro de Datos y Comunicaciones de la UNICEN,

- Generar un informe sobre los aspectos de Seguridad Informática de los servicios

2.1. Ingeniería Social

2.2. Seguridad Física y Biométrica

La biometría es el estudio de métodos automáticos para el reconocimiento de personas

2.4. Informática Forense

Es la aplicación de técnicas científicas y analíticas especializadas a infraestructura

2.5. Auditorías de Seguridad

Figura 2-1:​ Historial de metodologías de auditorías de seguridad

Si de estándares referidos a la seguridad se habla, no se pueden dejar de mencionar las

2.6. Test de Intrusión

Reportes, limpieza y destrucción de objetos​: En el curso de las

- Proyecto ​abierto de ​seguridad de ​aplicaciones web (OWASP, ​Open Web

- Penetration Testing Execution Standard (PTES) ​[PTE09] ​define una

2.7. Vulnerabilidades y Tipos de Ataque

En seguridad informática, la palabra vulnerabilidad hace referencia a una debilidad en

2.8.1. Sistemas Operativos

La variedad de aplicaciones existentes para las tareas de Seguridad Informática es

4.2. Sistema Operativo

5.1. Establecimiento de alcance y reglas de juego

5.2. Recolección de información

5.3. Análisis de vulnerabilidades

Luego de que se obtenga toda la información disponible en Internet, y se utilicen las

5.4. Explotación de vulnerabilidades

5.5. Post explotación del sistema

5.6. Generación de informes

La confección de informes es una parte de fundamental importancia dentro del

7.1. Objetivos principales

Más allá del seguimiento de una metodología y la utilización de ciertas técnicas

7.2. Footprinting Externo

Dentro de esta recolección de información de manera externa a la red de la entidad

7.2.1. Footprinting Externo Pasivo

Aquí se hará uso de una combinación de técnicas y herramientas para obtener, de

El comando ​whois ​es un protocolo TCP basado en petición/respuesta utilizado para

En la figura 7-1 se puede observar el resultado de ejecutar el comando whois sobre la

Figura 7-1:​ Respuesta del comando whois para la Ip ​131.221.0.3

Figura 7-2:​ Ejecución de whois para la Ip ​131.221.0.3 desde http://whois.domaintools.com

Figura 7-3:​ Fragmento de respuesta del whois para la Ip ​131.221.0.3 desde

Figura 7-5:​ Ejecución de whois para el dominio ​e-alternativas.edu.ar

Aquí se observa cómo, continuando con ésta política no minimalista, se obtiene

7.2.1.2. Google Hacking

Autores: Blanco, Damián – Cattafesta, Matías Francisco

Figura 2-1: Historial de metodologías de auditorías de seguridad

Reportes, limpieza y destrucción de objetos: En el curso de las

- Proyecto abierto de seguridad de aplicaciones web (OWASP, Open Web

- Penetration Testing Execution Standard (PTES) [PTE09] define una

El comando whois es un protocolo TCP basado en petición/respuesta utilizado para

Figura 7-1: Respuesta del comando whois para la Ip 131.221.0.3

Figura 7-2: Ejecución de whois para la Ip 131.221.0.3 desde http://whois.domaintools.com

Figura 7-3: Fragmento de respuesta del whois para la Ip 131.221.0.3 desde

Figura 7-5: Ejecución de whois para el dominio e-alternativas.edu.ar

Se realizó la búsqueda site:unicen.edu.ar “index of” para encontrar servidores web

Figura 7-7: Directorio interno encontrado desde búsqueda en Google

Figura 7-8: Archivos privados encontrados desde búsqueda en Google

Otra búsqueda realizada fue: site:unicen.edu.ar filetype:pdf “bradaschia”. Aquí se

Figura 7-12: Primer resultado de la búsqueda realizada en 7-11

De todas formas al buscar site:unicen.edu.ar filetype:pdf “users” se logra acceder a

Figura 7-14: Pdf con lista de usuarios perteneciente a la Secretaría de Administración

Figura 7-15: Información sobre listados de emails

site:unicen.edu.ar error|warning: encuentra errores en la página que pueden mostrar

Figura 7-16: JBoss log

Figura 7-20: Analisis de Robtex para rec.unicen.edu.ar

Shodan es otro motor de búsqueda que le permite al usuario encontrar tipos

Figura 7-23: Información genera de Shodanl sobre Ip 131.221.0.3

Esta herramienta, complementa la técnica de fingerprinting y permite indagar más

Figura 7-35: Distribución de bandas Ip dentro del Centro de Datos y Comunicaciones

Figura 7-36: Escaneo de nmap para la banda del Rectorado

Como se puede apreciar, el comienzo del comando es “nmap” indicando que

Figura 7-39: Escaneo de nmap con detección de sistemas operativos

Figura 8-1: Opciones contenidas en la herramienta Nikto

Figura 8-2: Escaneo con la herramienta Nikto para el host 10.254.1.152

Nessus no se encuentra dentro de la suite de herramientas que contiene por defecto la

Figura 8-3: Versiones de descarga disponibles para la herramienta Nessus

Figura 8-5: Activación del deamon de Nessus

Figura 8-7: Ingreso del código de activación para Nessus

Figura 8-9: Gráfico que contiene la cantidad de vulnerabilidades encontradas en el escaneo de

Por último, se utilizará el framework Metasploit, el cual proporciona la infraestructura

Figura 8-12: Inicialización de la bases de datos de Metasploit

Figura 8-15: Consulta a la base de Metasploit sobre la información de los host

Figura 8-16: Consulta a la base de Metasploit sobre la información de los servicios

Además de escaneos de Nmap, el framework Metasploit también acepta la

Figura 8-20: Reporte de vulnerabilidades persistidas en la base de Metasploit

Figura 8-23: Consulta de cabezados mediante cURL para la dirección 10.254.0.200

Figura 8-27: Ejecución de script obtenido en https://www.exploit-db.com/exploits/97/