UNIVERSIDAD MARIANO GÁLVEZ DE GUATEMALA

FACULTAD DE INGENIERÍA EN SISTEMAS DE INFORMACIÓN

Y CIENCIAS DE LA COMPUTACIÓN

“TEST DE PENETRACIÓN “PENTESTING” APLICADO EN

ENTORNOS GNU/LINUX EN UNA EMPRESA
GUATEMALTECA”

AMÍLCAR DARÍO DE LEÓN VELÁSQUEZ

GUATEMALA, AGOSTO 2017

 UNIVERSIDAD MARIANO GÁLVEZ DE GUATEMALA
FACULTAD DE INGENIERÍA EN SISTEMAS DE INFORMACIÓN
Y CIENCIAS DE LA COMPUTACIÓN

“TEST DE PENETRACIÓN “PENTESTING” APLICADO EN ENTORNOS

GNU/LINUX EN UNA EMPRESA GUATEMALTECA”

TRABAJO DE GRADUACIÓN PRESENTADO

POR:

AMÍLCAR DARÍO DE LEÓN VELÁSQUEZ

PREVIO A OPTAR AL GRADO ACADÉMICO DE

LICENCIADO EN INGENIERÍA EN SISTEMAS

DE INFORMACIÓN Y CIENCIAS DE LA COMPUTACIÓN

Y TÍTULO PROFESIONAL DE INGENIERO

EN SISTEMAS DE INFORMACIÓN Y CIENCIAS

DE LA COMPUTACIÓN

GUATEMALA, AGOSTO 2017

 AUTORIDADES DE LA FACULTAD Y DEL TRIBUNAL QUE PRACTICO
EL EXÁMEN DEL TRABAJO DE GRADUACIÓN

DECANO DE LA FACULTAD: ING. JORGE ALBERTO ARIAS TOBAR

SECRETARIO DE LA FACULTAD:

ING. HUGO ADALBERTO HERNÁNDEZ SANTIZO

PRESIDENTE DEL TRIBUNAL EXAMINADOR:

ING. OSBERTO ALEJANDRO PINEDA GONZÁLEZ

SECRETARIO: ING. ELADIO ANTONIO GIRÓN HERNÁNDEZ

VOCAL: ING. ERVIN ARTURO CANO ROMERO

III
IV
 REGLAMENTO DE TESIS

ARTÍCULO 8º: RESPONSABILIDAD

Solamente el autor es responsable de los conceptos expresados en el trabajo de

tesis. Su aprobación en manera alguna implica responsabilidad para la
Universidad.

V
 ÍNDICE

INTRODUCCIÓN ......................................................................................................................1

CAPÍTULO 1: ANTEPROYECTO .............................................................................................3

1.1 Antecedentes del Tema .................................................................................................3

1.2 Seguridad de Linux .......................................................................................................3

1.3 Supuestos y Expectativas del Tema ...............................................................................5

1.4 Justificación del Tema...................................................................................................5

1.5 Planteamiento del Problema ..........................................................................................6

1.6 Alcances y Límites de la Investigación Realizada..........................................................7

1.7 Definición de la Muestra ...............................................................................................8

1.8 Hipótesis .......................................................................................................................8

1.9 Diseño o Tipo de Investigación .....................................................................................8

1.10 Variables e Indicadores .................................................................................................9

1.10.1 Variable Independiente ..............................................................................................9

1.10.2 Variable Dependiente ................................................................................................9

1.11 Objetivos de la Investigación ........................................................................................9

1.11.1 General ......................................................................................................................9

1.11.2 Específicos ................................................................................................................9

CAPÍTULO 2: CONCEPTOS Y FUNDAMENTOS ................................................................. 10

2.1 Introducción ................................................................................................................ 10

2.2 Seguridad de la Información ....................................................................................... 10

2.2.1 Confidencialidad ..................................................................................................... 11

2.2.2 Integridad ................................................................................................................ 11

VI
 2.2.3 Disponibilidad ......................................................................................................... 11

2.3 Seguridad Informática ................................................................................................. 12

2.4 Seguridad Informática y Seguridad de la Información ................................................. 12

2.5 Amenazas en Empresas Latinoamérica ........................................................................ 13

2.5.1 Preocupaciones de los encargados de la seguridad en las empresas de Latinoamérica

13

2.5.2 Incidentes de Seguridad registrados ......................................................................... 14

2.6 GNU/Linux ................................................................................................................. 16

2.7 Estadística de uso de sistemas operativos .................................................................... 16

2.7.1 Sistemas Operativos en el Escritorio ........................................................................ 16

2.7.2 Sistemas Operativos en los Servidores ..................................................................... 17

2.7.3 Estadísticas Servidores Web .................................................................................... 18

2.8 Hacking Ético ............................................................................................................. 19

2.9 Test de Intrusión ......................................................................................................... 20

2.10 Tipos de test de intrusión............................................................................................. 21

2.10.1 Pruebas de Caja Negra ............................................................................................. 21

2.10.2 Pruebas de Caja Blanca ........................................................................................... 22

2.10.3 Pruebas Caja Gris: ................................................................................................... 22

2.11 Análisis de Vulnerabilidades versus Test de Intrusión ................................................. 23

2.12 Justificación de una prueba de Intrusión ...................................................................... 24

CAPÍTULO 3: METODOLOGÍA DE TEST DE INTRUSIÓN ................................................. 26

3.1 Introducción ................................................................................................................ 26

3.2 Estándar de Ejecución de Test de Intrusión ................................................................. 26

3.2.1 Fase de Planificación y acuerdos .......................................................................... 27

3.2.2 Fase de Reconocimiento .......................................................................................... 27

VII
 3.2.3 Fase de Modelado de amenazas ............................................................................... 28

3.2.4 Fase de Análisis de vulnerabilidades ........................................................................ 29

3.2.5 Fase de Explotación ................................................................................................. 29

3.2.6 Fase de Post-explotación ......................................................................................... 29

3.2.7 Documentación ....................................................................................................... 29

3.3 Manual de la Metodología Abierta de Pruebas de Seguridad (OSSTMM).................... 31

3.4 Proyecto OWASP ....................................................................................................... 31

3.5 Normativas ISO/IEC ................................................................................................... 32

3.5.1 El Test de Intrusión en un proyecto de ISO 27001 ................................................... 33

3.6 Otros documentos técnicos de soporte a las metodologías ........................................... 34

3.6.1 NIST SP 800-115 .................................................................................................... 34

3.6.2 Consorcio Internacional de Consultores de Comercio Electrónico ........................... 35

3.6.3 SANS Institute ........................................................................................................ 35

3.6.4 Infosec Institute ....................................................................................................... 35

3.7 Metodologías para aplicación del Test de Intrusión ..................................................... 35

CAPÍTULO 4: FASE DE PLANIFICACIÓN ............................................................................ 37

4.1 Introducción ................................................................................................................ 37

4.2 Definición de Alcance ................................................................................................. 38

4.3 Métricas para la estimación de tiempo ......................................................................... 38

4.4 Reunión de Planificación............................................................................................. 39

4.5 Cuestionarios .............................................................................................................. 39

4.6 Especificar Rangos de IP y Dominios .......................................................................... 40

4.7 Relación con proveedores del cliente (terceros) ........................................................... 40

4.7.1 Servicios en la nube ................................................................................................. 40

4.7.2 Proveedores de Servicio de Internet (ISP’s) ............................................................. 41

VIII
 4.8 Definir temas aceptados para pruebas de Ingeniería Social .......................................... 41

4.9 Ataques de Denegación de Servicios ........................................................................... 42

4.10 Objetivos .................................................................................................................... 42

4.11 Establecer líneas de comunicación .............................................................................. 43

4.11.1 Información de Contacto para Emergencias ............................................................. 43

4.11.2 Proceso de reporte de incidentes .............................................................................. 43

4.11.3 Cifrado para el manejo de información .................................................................... 44

4.11.4 Línea de tiempo ....................................................................................................... 44

4.11.5 Ubicaciones físicas .................................................................................................. 44

4.11.6 Manejo de evidencias .............................................................................................. 45

4.11.7 Reuniones de Seguimiento ....................................................................................... 45

4.11.8 Consideraciones Legales.......................................................................................... 45

4.12 Capacidades de respuesta y herramientas tecnológicas de la organización objetivo...... 48

CAPÍTULO 5: FASE DE RECONOCIMIENTO ...................................................................... 50

5.1 Introducción ................................................................................................................ 50

5.2 External Footprinting .................................................................................................. 50

5.2.1 Reconocimiento activo ............................................................................................ 50

5.2.1.1 Importancia del Servicio DNS ................................................................................. 50

5.2.2 Reconocimiento Pasivo ........................................................................................ 52

5.2.3 Herramienta Maltego ........................................................................................... 55

5.3 Reconocimiento Interno (footprinting) ........................................................................ 56

CAPÍTULO 6: FASE DE ENUMERACIÓN ............................................................................. 58

6.1 Introducción ................................................................................................................ 58

6.2 Banners de servidores web .......................................................................................... 59

6.3 Banner Informativo de Servidor de correo ................................................................... 59

IX
 6.4 Enumeración de DNS .................................................................................................. 60

6.5 Enumeración de SNMP ............................................................................................... 60

CAPÍTULO 7: FASE DE MAPEO DE VULNERABILIDADES .............................................. 63

7.1 Introducción ................................................................................................................ 63

7.2 Identificación de vulnerabilidades de manera manual .................................................. 63

7.2.1 Proyecto CVE MITRE............................................................................................. 63

7.3 Identificación de vulnerabilidades con herramientas automatizadas ............................. 65

7.3.1 Herramienta de análisis de vulnerabilidades Nexpose ........................................... 66

7.3.2 Herramienta de análisis de vulnerabilidades Nessus ............................................. 67

7.3.3 Otras herramientas ............................................................................................... 68

CAPÍTULO 8: FASE DE EXPLOTACIÓN .............................................................................. 70

8.1 Introducción ................................................................................................................ 70

8.2 Metasploit Framework ................................................................................................ 71

8.2.1 Herramienta de fuerza bruta para protocolo SSH ..................................................... 72

8.2.2 Herramienta de explotación Samba .......................................................................... 75

8.2.3 FTP Exploit ............................................................................................................. 79

8.2.4 Herramienta de explotación de servicio Unreal ircd ................................................. 81

8.3 Vulnerabilidad Shellshock .......................................................................................... 82

8.4 Vulnerabilidad HeartBleed .......................................................................................... 86

8.5 Buffer Overflows ........................................................................................................ 90

8.6 DoS y DDoS ............................................................................................................... 90

8.7 DoS Prueba de Concepto: GoldenEye ......................................................................... 91

CAPÍTULO 9: WEB APP PENTESTING CON OWASP ......................................................... 94

9.1 Introducción ................................................................................................................ 94

9.2 OWASP Top Ten ........................................................................................................ 94

X
 9.2.1 Cross Site Scripting (XSS) ................................................................................... 97

9.2.2 Inyección SQL ..................................................................................................... 98

9.2.3 Referencia Insegura a Objetos Directos .............................................................. 105

9.3 Escáneres de Vulnerabilidades en Aplicaciones Web ................................................ 106

9.3.1 Acunetix ................................................................................................................ 107

9.3.2 Nikto.................................................................................................................. 108

CAPÍTULO 10: FASE DE POST EXPLOTACIÓN ................................................................ 110

10.1 Introducción .............................................................................................................. 110

10.2 Presencia ................................................................................................................... 110

10.2.1 Archivos ................................................................................................................ 110

10.2.2 Comandos ............................................................................................................. 111

10.3 Persistencia ............................................................................................................... 111

10.4 Escalamiento de Privilegios ...................................................................................... 111

10.4.1 Recolección de información .................................................................................. 112

10.4.2 Explotación ........................................................................................................... 118

10.5 Revisiones automatizadas – Unix-Privesc ................................................................. 119

10.6 Garantizando el acceso: Backdoors ........................................................................... 120

CAPÍTULO 11: FASE DE DOCUMENTACIÓN ................................................................... 121

11.1 Introducción .............................................................................................................. 121

11.2 Resumen Ejecutivo ................................................................................................... 121

11.3 Detalle Técnico ......................................................................................................... 124

11.3.1 Inconvenientes de seguridad .................................................................................. 125

11.3.2 Descripción de vulnerabilidades ............................................................................ 125

11.3.3 Descripción de exploits.......................................................................................... 125

11.3.4 Recomendaciones .................................................................................................. 125

XI
 11.4 Dradis framework ..................................................................................................... 126

CAPÍTULO 12: APLICACIÓN EN ENTORNO REAL .......................................................... 128

12.1 Introducción .............................................................................................................. 128

12.2 Alcance ..................................................................................................................... 129

12.3 Propuesta económica ................................................................................................. 129

12.4 Resumen de Hallazgos .............................................................................................. 130

12.5 Detalle de Hallazgos ................................................................................................. 133

12.5.1 Infraestructura Tecnológica: Interna y Externa....................................................... 133

12.5.2 Aplicaciones Web: Externa.................................................................................... 151

12.6 Conclusiones del Informe .......................................................................................... 161

12.7 Recomendaciones del Informe .................................................................................. 163

CONCLUSIONES .................................................................................................................. 164

RECOMENDACIONES ......................................................................................................... 166

GLOSARIO ............................................................................................................................ 168

REFERENCIAS BIBLIOGRÁFICAS ..................................................................................... 193

XII
 TABLA DE GRÁFICAS

Gráfica 1: Triada de Seguridad de la Información...................................................................... 11

Gráfica 2. Seguridad de la Información y Seguridad Informática ............................................... 13
Gráfica 3: Preocupaciones en materia de Seguridad de la Información en las empresas de
Latinoamérica. .......................................................................................................................... 14
Gráfica 4: Incidentes de Seguridad de la Información en las empresas de Latinoamérica (por
tamaño de empresa) .................................................................................................................. 15
Gráfica 5. Uso de sistemas operativos en aplicaciones de escritorio. Octubre 2016. ................... 17
Gráfica 6. Uso de sistemas operativos, supercomputadoras del mundo. Octubre 2016. .............. 17
Gráfica 7. Uso de servidores web para sitios web. Octubre 2016. .............................................. 19
Gráfica 8. Logo PTES ............................................................................................................... 27
Gráfica 9: Fases de un Test de Intrusión. ................................................................................... 30
Gráfica 10: Logo proyecto OWASP .......................................................................................... 32
Gráfica 11: Uso de la herramienta Dig....................................................................................... 52
Gráfica 12: whois.domaintools.com .......................................................................................... 53
Gráfica 13: Operadores Google Hacking ................................................................................... 55
Gráfica 14: Interfaz gráfica de Maltego. .................................................................................... 56
Gráfica 15: Nmap ejecutándose en Kali Linux. Escaneo a un host GNU/Linux ......................... 57
Gráfica 16: Obtención de banner informativo de Web Server utilizando nmap. ......................... 59
Gráfica 17: enumeración de SMTP............................................................................................ 60
Gráfica 18: enumeración de DNS .............................................................................................. 60
Gráfica 19: Enumeración de SNMP en un dispositivo vulnerable .............................................. 62
Gráfica 20: Búsqueda de identificadores CVE’s. ....................................................................... 65
Gráfica 21: Nexpose. Resúmen de escaneo. ............................................................................... 67
Gráfica 22: Nexpose. Detalle de Vulnerabilidades. .................................................................... 67
Gráfica 23: Nessus Vulnerability Scanner ................................................................................. 68
Gráfica 24: Arquitectura de Metasploit Framework ................................................................... 71
Gráfica 25: Búsqueda de módulo auxiliar en MSF ..................................................................... 73
Gráfica 26: visualización de opciones de módulo auxiliar MSF ................................................. 74
Gráfica 27: configuración de opciones de módulo auxiliar MSF ................................................ 74

XIII
Gráfica 28: modulo auxiliar de login ssh ejecutándose exitosamente ......................................... 75
Gráfica 29: modulo auxiliar smb_version .................................................................................. 76
Gráfica 30: Ejecución del módulo smb_version ......................................................................... 76
Gráfica 31: Referencia técnica de vulnerabilidad pública samba ................................................ 77
Gráfica 32: identificación de exploit usermap_script ................................................................. 78
Gráfica 33: Configuración de parámetros de exploit usermap_script.......................................... 78
Gráfica 34: ejecución exitosa de exploit usermap_script logrando root ...................................... 79
Gráfica 35: búsqueda de exploit para vsftp ................................................................................ 80
Gráfica 36: configuración de parámetros de exploit vsftp .......................................................... 80
Gráfica 37: ejecución exitosa de exploit, logrando root.............................................................. 80
Gráfica 38: Ejecución exitosa de exploit para unreal ircd........................................................... 81
Gráfica 39: identificación de CGI mediante Burp Proxy ............................................................ 82
Gráfica 40: Análisis de código Fuente vulnerabilidad shellshock ............................................... 83
Gráfica 41: Respuesta de script CGI .......................................................................................... 84
Gráfica 42: Envío de petición hacia la herramienta “Repeater”, Burp Proxy .............................. 84
Gráfica 43: Burp Proxy Repeater, Header Original .................................................................... 84
Gráfica 44: Burp Proxy Repeater, Header modificado. .............................................................. 85
Gráfica 45: Ejecución de comando remote. Netcat .................................................................... 85
Gráfica 46: Reverse shell con netcat .......................................................................................... 86
Gráfica 47: heartbleed bug ........................................................................................................ 86
Gráfica 48: filippo.io, verificación de servidor web con TLS/SSL Vulnerable ........................... 87
Gráfica 49: configuración de modulo auxiliar MSF para explotación de Heartbleed .................. 88
Gráfica 50: Explotación exitosa de Heatbleed. Imagen ½ .......................................................... 89
Gráfica 51: Explotación exitosa de Heartbleed. Imagen 2/2 ....................................................... 89
Gráfica 52: funcionamiento básico de un Buffer Overflow ........................................................ 90
Gráfica 53: DDoS ..................................................................................................................... 91
Gráfica 54: Parámetros de configuración GoldenEye ................................................................. 92
Gráfica 55: Ejecución de GoldenEye, Imagen 1/4...................................................................... 92
Gráfica 56: Ejecución de GoldenEye, Imagen 2/4...................................................................... 92
Gráfica 57: Ejecución de GoldenEye, monitoreo de tráfico, Imagen 3/4 .................................... 93
Gráfica 58: Ejecución de GoldenEye, monitoreo de tráfico, Imagen 4/4 .................................... 93

XIV
Gráfica 59: OWASP Top 10, Cross Site Scripting ..................................................................... 97
Gráfica 60: Funcionamiento de XSS Almacenado ..................................................................... 98
Gráfica 61: OWASP Top 10, Inyección ..................................................................................... 98
Gráfica 62: Funcionamiento de Inyección SQL ....................................................................... 100
Gráfica 63: Esquema de funcionamiento Cliente Web, Proxy HTTP y Servidor Web .............. 101
Gráfica 64: Identificando parámetros de entrada en formulario web ........................................ 101
Gráfica 65: Pruebas de fuzzing, insertando una comilla simple ................................................ 102
Gráfica 66: resultado de fuzzing, insertando una comilla simple .............................................. 102
Gráfica 67: Inyección de sentencia SQL en parámetro de entrada ............................................ 103
Gráfica 68: Ejecución exitosa de sentencia SQL ...................................................................... 103
Gráfica 69: Ejecución de SQLMap .......................................................................................... 104
Gráfica 70: Confirmación de parámetro vulnerable a SQLInjection, SQLMap ......................... 104
Gráfica 71: Dump de la base de datos, crackeo de hashes de usuarios vía SQLMap. ................ 105
Gráfica 72: OWASP Top 10, Referencia Insegura a Objetos Directos ..................................... 105
Gráfica 73. Cuadrante mágico de Gartner: test de seguridad de aplicaciones ........................... 107
Gráfica 74: Acunetix en ejecución ........................................................................................... 108
Gráfica 75: Nikto en Ejecución ............................................................................................... 109
Gráfica 76: Archivos Linux, búsqueda de información sensible ............................................... 111
Gráfica 77: Comandos Linux para búsqueda ........................................................................... 111
Gráfica 78: Ejecución de Unix-privesc-check .......................................................................... 120
Gráfica 79: Gráfica de Pie, Resumen Global de Hallazgos ...................................................... 124
Gráfica 80: Ejemplo de principales acciones recomendadas, basadas en tiempos de ejecución. 124
Gráfica 81. Dradis Framework ................................................................................................ 127

XV
 ANEXOS

Anexo 1 - 00 – PT – Cuestionario General Inicial ................................................................ 179

Anexo 2 - 02 – PT – Cuestionario Aplicaciones Web ........................................................... 183
Anexo 3 - 03 – PT – Cuestionario redes Wireless................................................................. 184
Anexo 4 - 04 – PT – Cuestionario acceso físico .................................................................... 185
Anexo 5 - 05 – PT – Cuestionario Ingeniería Social ............................................................. 186

XVI
 INTRODUCCIÓN
Han pasado más de 3 décadas desde que se creó el primer virus informático, el cual, fue
creado sobre la plataforma Unix. Sin embargo, hoy en día, los sistemas tipo Unix no son los más
afectados por éstos; en contraste, los sistemas Windows han tenido mayor facilidad y popularidad
de infección de éstos y otros tipos de códigos maliciosos.

A raíz de este tipo de incidentes, se empezó a generar un interés por la (in) seguridad de
los sistemas. Con el pasar del tiempo, continúa creciendo el número de personas interesadas en la
Seguridad Informática, ya sea defensiva, como ofensiva. A esto, se añade que hoy en día, no es el
malware el único método de afectación a un sistema informático, sino que existen múltiples
vectores de ataque de los cuales un atacante puede tomar ventaja, como las vulnerabilidades a nivel
de red, sistemas operativos o tecnologías web, sin pasar por alto a los usuarios.

Mucho se habla ahora de los “Hackers”, debido a las actividades ilícitas que pueden
mencionarse en los principales noticieros alrededor del mundo; personas con alto conocimiento
técnico que vulneran los sistemas de información de grandes corporaciones, gobiernos, entidades
financieras. Pero existen los “hackers buenos”.

Y es que el término adecuado para Hacker en términos generales es, una persona con altos
conocimientos de informática, capaz de vulnerar sistemas de información. Entonces la pregunta
es, ¿esto es bueno, o es malo?

Un hacker, puede utilizar sus habilidades para el bien, o para el mal. A éstos, en el mundo
de la seguridad informática se les denomina, Hackers de sombrero negro (malos) o hackers de
sombrero blanco (buenos). Los hackers de sombrero blanco, realizan actividades bajo una línea
ética, en donde normalmente el objetivo se basa en identificar vulnerabilidades y materializar su
explotación, previa autorización y en escenarios controlados, en común acuerdo con sus clientes u
organización para la que laboran. No infringen la ley, su motivación es mostrar a las
organizaciones lo fácil que pueden ser comprometidos sus servicios, extraer información, causar
sabotaje, o engañar al humano (sus colaboradores y proveedores).

1
 2

Una de las actividades que realizan estos “Hackers Éticos”, se denomina “Test de
Intrusión”, el cual, como su nombre lo indica, busca realizar una intrusión en los sistemas
informáticos para los cuáles el profesional en cuestión es contratado. El presente trabajo de
investigación, tiene como principal objetivo plantear metodologías y técnicas de Intrusión de
Sistemas, con el fin de demostrar la manera en que un atacante trataría de vulnerar, en la vida real,
los sistemas informáticos de una organización. Todo esto, en un ambiente controlado y con las
respectivas autorizaciones, bajo una línea estrictamente ética.
 CAPÍTULO 1: ANTEPROYECTO
1.1 Antecedentes del Tema
Microsoft Windows, es hoy por hoy el sistema operativo que domina la mayoría de la cuota
de mercado, en cuanto a uso de escritorio respecta. Existen estadísticas a nivel mundial que nos
muestran el comportamiento de uso de los sistemas más utilizados por los usuarios. Los sistemas
de Microsoft, dominan con más del 90% de cuota de mercado a nivel de uso de escritorio (casa y
oficina), mientras que Linux está presente en no más de un 2%, esto de acuerdo a estadísticas de
marketshare.com, correspondientes a enero 2017.

Pero, ¿sucede lo mismo si se evalúan las plataformas de servidores? ¿Los ambientes

virtuales? ¿Las soluciones en la nube? ¿Los servidores web? En contraparte con la cuota de
mercado a nivel de sistemas de escritorio, los sistemas operativos Unix y sus derivados,
específicamente GNU/Linux, son los que dominan el mercado, con una cuota superior al 80%.
Una diferencia bien marcada entre ambas tecnologías, se debe al modelo de desarrollo de esta
última, ya que cuenta con un modelo de desarrollo “abierto” el cuál, dependiendo de su variante,
permite aportes de colaboradores de todas partes del mundo (desarrolladores, testers,
documentadores, etc.), así como de organizaciones privadas o no lucrativas (apoyo económico,
código fuente, etc.), lo cual genera que todo proyecto “abierto” en general pueda ser dotado con
gran cantidad de recursos para su desarrollo. Asimismo, el código fuente, se pone a disposición de
cualquier usuario, quien podría mejorar las herramientas o bien generar copias modificadas a
medida.

1.2 Seguridad de Linux

Es bien sabido que, en el ámbito de la seguridad informática, cualquier sistema, aplicación
(escritorio, web, móvil, etc.), o tecnología en general, está expuesta a diversas amenazas, entre
ellas se puede mencionar, entre otras:

 Infecciones de código malicioso

 Ataques de denegación de servicio
 Explotación de vulnerabilidades
 Ataques dirigidos
 Amenazas día cero

3
 4

En los Sistemas Operativos utilizados en infraestructuras críticas, es bastante más común

encontrar código malicioso, ataques, e intrusión a sistemas Windows. Sin embargo, no existe, en
gran cantidad, estudios técnicos que detallen en profundidad la metodología, y sobre todo técnicas
que podrían utilizarse para la intrusión y explotación de vulnerabilidades en Sistemas Operativos
GNU/Linux. Los aportes generados a partir de esta investigación, se centran no sólo en mostrar
la adecuada ejecución de metodologías para llevar a cabo Test de Intrusión controlados en
plataformas GNU/Linux, sino también que sea documentación de gran calidad técnica, y generada
de Guatemala para el mundo.

Algunos casos de sitios web cuyas tecnologías son abiertas, por mencionar algunos han
sido los sitios repositorios de Fedora (2008), Debian (2003), así como el foro de usuarios de
Ubuntu (2013); este último fue atacado por un grupo de hackers que logró obtener privilegios de
super usuario (root), mediante técnicas que permitieron realizar un defacement1 del sitio y
obteniendo todos los nombres de usuario, contraseñas y correo electrónicos almacenados en los
servidores. Además, las vulnerabilidades día cero (en su momento) heartbleed (vulnerabilidad en
Open SSL), ShellShock (vulnerabilidad en Bash2), así como el hackeo del sitio web de Linux
Mint, en donde atacantes pudieron reemplazar la ISO oficial del sistema operativo por una versión
con malware, y cuyo nivel de criticidad fue catalogado como crítico, debido al enorme impacto
que pudieron generar en las plataformas Linux.
Por tanto, un ataque a este tipo de infraestructuras críticas puede significar grandes
impactos negativos como la baja de servicios, pérdida o robo de información, y por ende tener
consecuencias económicas, legales o incluso de daño de imagen para la organización afectada. Y
es a través de un Test de Intrusión que puede anticiparse a ciertos ataques que podrían generarse
desde personas malintencionadas; este es justamente el beneficio de realizar test de intrusiones,
con los cuales, luego de identificar vectores de ataque específicos, se logra mitigar el riesgo,
siempre y cuando se mantengan de manera periódica las revisiones de seguridad en las plataformas
críticas.

1
Consiste en la intrusión ajena al servidor web por medio de diversas técnicas que aprovechan la vulnerabilidad del mismo o bien a nivel de
programación del sitio web, permitiendo la modificación total o parcial del contenido o configuración.
2
Bourne again shell es un programa informático, cuya función consiste en interpretar órdenes, y un lenguaje de consola en sistemas Linux.
 5

1.3 Supuestos y Expectativas del Tema

Con la presente investigación, se puede plasmar una metodología concreta y pasos a seguir
para llevar a cabo un test de intrusión sobre sistemas GNU/Linux, que hoy en día, para el ámbito
de infraestructuras críticas, son muy utilizados debido a su excelente rendimiento y bajo coste de
licenciamiento.

Asimismo, demostrar que todo sistema informático es vulnerable en algún punto, ya que
la seguridad informática es un proceso que debe estar en mejora continua en las empresas. Decir
que un sistema es 100% seguro es falso, ya que, con el uso adecuado de tecnologías, los
investigadores alrededor del mundo encuentran eventualmente la manera de vulnerar diferentes
tipos de tecnologías. Hoy en día ya es más común ver noticias sobre hacking de vehículos, de IoT
(Internet of Things) o infraestructuras SCADA3.

También se espera que se pueda aprovechar el uso de las herramientas que se utilizan para
hacer las pruebas, ya que en su mayoría son de código abierto, o bien son herramientas propietarias
que han sido catalogadas como las más eficientes y robustas para realizar determinadas actividades
durante las fases de un test de intrusión.

1.4 Justificación del Tema

En los estudios relacionados con la Informática y tecnología, en Guatemala, cuando se
habla de Seguridad Informática y Seguridad de la información, se hace referencia a ISO/IEC
27001, COBIT, CISSP, COSO, CISA entre otros. Estas normativas nos presentan meticulosamente
los procesos, políticas y métricas que deben seguirse por parte de los administradores de sistemas,
acompañados de los demás altos mandos de la organización, para poder garantizar la integridad de
los datos y la seguridad por niveles enfocados principalmente a la Seguridad de la Información.

Sin embargo, aspectos netamente técnicos o metodológicos para la evaluación de

vulnerabilidades que pueden seguirse, no se incluyen en estos marcos de referencia, y en muchos
casos no son practicados, por temas de carácter presupuestario o por falta de visión por parte de
los altos mandos en la organización.

3
Acrónimo de Supervisory Control And Data Acquisition (Supervisión, Control y Adquisición de Datos).
 6

Contar con las políticas y métricas dictadas por cualquiera de las normativas citadas con
anterioridad es una buena práctica, pero para poder tener completo el panorama de Seguridad,
orientándose más específicamente a posibles vectores de ataque, su impacto y riesgo asociado,
debe contemplarse la contraparte técnica, enfocada en el ámbito de la Seguridad Informática, en
donde se pueden encuadrar actividades netamente técnicas como el análisis de vulnerabilidades,
los test de intrusión, el hardening de dispositivos de infraestructura críticos, las mejores prácticas
de configuración recomendados por institutos como SANS o NIST, entre otros.

Por tanto, la justificación de la presente Investigación, nace a partir de la necesidad de

demostrar una metodología tecnológica y herramientas de software con que permitan realizar un
test de intrusión en tecnologías abiertas, específicamente GNU/Linux y tecnologías web, y
demostrar que es posible presentar los hallazgos, el detalle técnico de explicación y a su vez una
recomendación a medida.

1.5 Planteamiento del Problema

Inicialmente se plantea que, las organizaciones en Guatemala, pueden o no, apegarse a
ciertas normativas de mejora continua en términos de Seguridad de la Información. Sin embargo,
la inexistencia o inadecuada aplicación de las mismas, puede traer como consecuencia que estas
organizaciones puedan ser víctimas de una brecha de seguridad. Por un lado, se puede mencionar
que estas normativas (como ISO 27001, COBIT, entre otras) sirven como apoyo para gestionar el
riesgo, y es posible poder identificar brechas en la alineación con las mismas. Un Test de Intrusión
busca materializar la explotación de vulnerabilidades reales en el entorno tecnológico, ya que
muestra resultados reales de cómo un atacante podría aprovechar estas debilidades.

Por otro lado, se tiene la idea que los sistemas operativos Linux son normalmente más
eficientes en términos de rendimiento, y seguros en términos generales, comparados con los
sistemas operativos de Microsoft, en las áreas donde corresponde.

Mediante un Test de Intrusión, se ofrece un enfoque práctico para una adecuada

implementación de las normativas antes mencionadas, ya que estas últimas están alineadas de
manera directa con la Seguridad de la Información, mientras que un Test de Intrusión se alinea
 7

directamente con la Seguridad Informática. Ambos deben coexistir en un escenario ideal, de

mejora continua.

Por lo tanto, en la presente investigación, se hará uso de múltiples metodologías abiertas

para elaborar un Test de Intrusión, como lo es la Metodología de Testeo de Seguridad de Código
Abierto (OSSTMM por sus siglas en Inglés) y el Proyecto Abierto de Seguridad de Aplicaciones
Web (OWASP), además de técnicas y herramientas específicas consideradas para cada una de las
fases, con lo que se plantea tener como resultado, documentación donde se puntualizan hallazgos
de vulnerabilidades específicas que pueden llevar a la organización objetivo tener impactos en
términos de pérdidas económicas, legales o daño de imagen, como si se hubiese tratado de un
ataque real.

Se hace uso de múltiples metodologías ya existentes, debido a que se toman ciertas

actividades o técnicas específicas de cada una, para realizar la aplicación del Test de Intrusión en
ambientes GNU/Linux y de tecnologías web abiertas. La metodología OSSTMM provee
documentación y checklists que proveen un punto de partida para el Auditor de Seguridad; el
Estándar de Ejecución de Test de Intrusión (PETS por sus siglas en Inglés) por su lado provee la
línea base de un test de intrusión, la cuál es la misma en otras metodologías abiertas o
certificaciones de seguridad informática, y por otro lado la metodología OWASP se enfoca
específicamente en tecnologías web.

1.6 Alcances y Límites de la Investigación Realizada

Se elaborará un Test de Intrusión en una empresa mediana (MIMPYME) guatemalteca, la
cual cuenta con al menos 5 sucursales, con conectividad vía internet hacia un centro de datos (Data
Center) principal.

El centro de datos principal cuenta con infraestructura híbrida en cuanto a tecnologías de

código abierto, como GNU/Linux o derivados, equipos de red con sistemas operativos derivados
de Unix, y al menos 2 aplicaciones web que utilicen tecnologías de código abierto como lo son
PHP o Java.
 8

El test de Intrusión se enfocará en identificar vulnerabilidades a nivel de infraestructura,

sistemas operativos y aplicaciones web en tiempo de ejecución. Se excluye el análisis estático de
código fuente, y asimismo no se restringe el hecho que la infraestructura pueda utilizar tecnologías
propietarias, como lo son, por ejemplo, Sistemas Operativos Windows en dispositivos de usuarios
finales; esto último, debido a que este es el escenario común en empresas guatemaltecas.

1.7 Definición de la Muestra

Para la presente investigación, se selecciona una muestra no probabilística, ya que lo que
se pretende es hacer un test de intrusión específico en sistemas GNU/Linux y tecnologías web, el
cual se realizará tanto en un entorno controlado (virtual) como en un entorno productivo en una
empresa seleccionada por el Auditor de Seguridad, la cual cuenta con la infraestructura necesaria
para poder poner en práctica todos los esquemas y técnicas que se obtienen como resultado final
de la investigación. Es decir, no se tomarán muestras representativas de un Universo de empresas,
ni de sistemas, ya que se tiene un objetivo específico.

Dentro del proceso del test de intrusión, existe una actividad donde se confirma el alcance
de los sistemas a explotar, denominada Reunión de Planificación (o mejor conocida por su término
en inglés kick-off) entre el Auditor de Seguridad (investigador) y el equipo técnico de la empresa
seleccionada. De esto se obtiene un número específico de direcciones IP, aplicaciones a ser
evaluados.

1.8 Hipótesis
Los sistemas informáticos de código abierto, específicamente los Sistemas Operativos
GNU/Linux y tecnologías web pueden ser atacados como cualquier otra tecnología propietaria,
mediante la utilización de metodologías, técnicas y herramientas adecuadas.

1.9 Diseño o Tipo de Investigación

La presente investigación tendrá un formato Técnico Documental, con pruebas de campo,
ya que se procederá a realizar la identificación de vulnerabilidades, así como la materialización de
una explotación específica. Por tanto, el producto final, será un documento con especificaciones
técnicas de cómo vulnerar los diferentes activos, su nivel de severidad y las recomendaciones
según sea el caso.
 9

1.10 Variables e Indicadores

1.10.1 Variable Independiente
En base a metodologías existentes, plantear la aplicación de una metodología específica
para la realización de de test de intrusión orientado a evaluar el nivel de seguridad de sistemas
GNU/Linux y tecnologías web abiertas.

1.10.2 Variable Dependiente

1. Identificación de las fases de un test de intrusión.
2. Identificación de los aspectos fundamentales de la presentación de un
informe de test de intrusión.
3. Identificación y materialización de vulnerabilidades en sistemas
GNU/Linux y tecnologías web abiertas.

1.11 Objetivos de la Investigación

1.11.1 General
Seleccionar las metodologías, tecnologías y herramientas idóneas para la identificación de
vulnerabilidades y la explotación de tecnologías de código abierto GNU/Linux y tecnologías web,
en un ambiente controlado, sin poner en riesgo la disponibilidad de la infraestructura a ser
evaluada, bajo una línea de “Hacking Ético”.

1.11.2 Específicos
1. Comprender y llevar a cabo el ciclo de test de intrusión, mediante la correcta
adaptación y puesta en marcha de metodologías y documentación relacionada con el test
de intrusión.
2. Documentar debidamente todos los hallazgos, metodologías y técnicas
utilizadas.
3. Proveer recomendaciones en la mejora continua de la seguridad
informática, realizando un traspaso de conocimientos al personal técnico de la organización
objetivo.
 CAPÍTULO 2: CONCEPTOS Y FUNDAMENTOS
2.1 Introducción
En la actualidad, existen muchos conceptos y términos que giran en torno al campo de la
Seguridad de la Información y la Seguridad Informática. Es importante saber que, aunque ambos
términos no significan lo mismo, están estrechamente ligados, y ambos buscan garantizar la
seguridad de un activo común: LA INFORMACIÓN.

A continuación, se presentan una serie de términos fundamentales que serán de vital

importancia para el desarrollo y entendimiento de la presente investigación, así como algunos
datos estadísticos importantes de los cuáles se basan muchas de las técnicas de intrusión planteadas
en esta investigación. Temas como Seguridad de la Información, Seguridad Informática,
Incidentes de seguridad en empresas de Latinoamérica, tipos de test de intrusión, entre otros, en el
mundo de la seguridad en el campo de la tecnología y sistemas.

De igual forma, se cuenta con una sección de glosario, para poder profundizar en aquellos
términos que puedan presentar cierta dificultad de entendimiento al lector. Es además importante,
tener en cuenta que la mayoría de documentación, bibliografía y términos nativos del campo de
Seguridad Informática, existen primordialmente en idioma inglés, por lo que se ha hecho un mayor
esfuerzo por hacer traducciones funcionales y explicaciones ampliadas de cada uno de ellos.

2.2 Seguridad de la Información

La Seguridad de la Información es el conjunto de medidas preventivas y reactivas de las
organizaciones y de los sistemas tecnológicos que permiten resguardar y proteger la información
buscando mantener la confidencialidad, disponibilidad e integridad de la misma. Para salvaguardar
la INFORMACIÓN, existen tres componentes fundamentales, Confidencialidad, Integridad y
Disponibilidad, denominados CIA (Confidenciality, Integrity, Availability, por sus siglas en
inglés):
 11

Gráfica 1: Triada de Seguridad de la Información

2.2.1 Confidencialidad
Se trata de la cualidad que debe poseer un documento o archivo para que este sólo se
entienda de manera comprensible o sea leído por la persona o sistema que esté autorizado. De esta
manera se dice que un documento (o archivo o mensaje) es confidencial si y solo si puede ser
comprendido por la persona o entidad a quien va dirigida o esté autorizada. En el caso de un
mensaje, esto evita que exista una intercepción de éste y que pueda ser leído por una persona no
autorizada.

2.2.2 Integridad
La integridad es la cualidad que posee un documento o archivo que no ha sido alterado, y
que además permite comprobar que no se ha producido manipulación alguna en el documento
original. Aplicado a las bases de datos sería la correspondencia entre los datos y los hechos que
refleja.

2.2.3 Disponibilidad
Se trata de la capacidad de un servicio, de unos datos o de un sistema, que pueda ser
accesible y utilizable por los usuarios (o procesos) autorizados cuando se requiera.
 12

2.3 Seguridad Informática

La Seguridad Informática, según el instituto SANS (SysAdmin Audit Networking and
Security Instutute), es el área de la informática que se enfoca en la protección de la infraestructura
tecnológica y todo lo relacionado con esta, y especialmente la información contenida o circulante.
Para ello existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes
concebidas para minimizar los posibles riesgos a la infraestructura o a la información. La seguridad
informática abarca todo lo que es software (bases de datos, aplicaciones de escritorio, de web,
archivos), hardware y todo lo que la organización valore (activo) o propicie un riesgo si esta
información confidencial llega a manos de otras personas, porque muchas veces se trata de
información privilegiada, sensible o confidencial.

2.4 Seguridad Informática y Seguridad de la Información

Seguridad Informática y Seguridad de la Información pueden parecer lo mismo, sobre todo
si se tiene en cuenta que el desarrollo y la evolución de la tecnología tienden hacia el modelo de
“digitalizar” y “manejar” cualquier tipo de información mediante un sistema informático. No
obstante, aunque están destinados a vivir en armonía y trabajar conjuntamente, cada una de las
áreas de la Seguridad tiene objetivos y actividades diferentes.

La Seguridad Informática se describe como la distinción táctica y operacional de la

Seguridad, mientras que la Seguridad de la Información sería una línea estratégica de la Seguridad.
Teniendo en cuenta la definición de Seguridad Informática, esta disciplina se encargaría de las
implementaciones técnicas de la protección de la información, el despliegue de las tecnologías
antivirus, firewalls, detección de intrusos, detección de anomalías, detección de vulnerabilidades,
atención de incidentes, entre otros elementos que – articulados con prácticas de gobierno de la
tecnología de información – establecen la forma de actuar y asegurar las situaciones de fallas
parciales o totales, cuando la información es el activo que se encuentra en riesgo.

Por otro lado, la Seguridad de la Información, según ISO 27001, es la disciplina que nos
habla de los riesgos, las amenazas, de los análisis de escenarios, de las buenas prácticas y esquemas
normativos, que nos exigen niveles de aseguramiento de procesos y tecnologías para elevar el nivel
de confianza en la creación, uso, almacenamiento, transmisión, recuperación y disposición final
de la información.
 13

Gráfica 2. Seguridad de la Información y Seguridad Informática

Fuente: http://es.slideshare.net/aurixv/seguridad-informtica-vs-seguridad-de-la-informacin

Es importante entonces, comprender el esquema y las diferencias de Seguridad Informática

y Seguridad de la Información, ya que, en un entorno ideal, ambos deben coexistir. En la presente
investigación, se parte desde un enfoque TÁCTICO/OPERACIONAL, dentro del marco de la
Seguridad Informática, es decir, un enfoque completamente técnico.

2.5 Amenazas en Empresas Latinoamérica

Es importante poder conocer cómo es la situación en materia de Seguridad de la
Información en empresas latinoamericanas. Para esto, ESET Latinoamérica publica anualmente su
Reporte de Seguridad, en el cual se puede apreciar estadísticas interesantes con respecto a la
postura de seguridad, y frecuencia de incidentes desde el punto de vista de organizaciones en la
región.

2.5.1 Preocupaciones de los encargados de la seguridad en las empresas de Latinoamérica

Las preocupaciones de los equipos de seguridad en las empresas, según el Reporte de
Seguridad de ESET 2016, pueden determinarse a través de distintos factores, como las tendencias
en materia de amenazas informáticas o los incidentes de seguridad más comunes. La atención
 14

proactiva de estas inquietudes contribuye a evitar la materialización de los riesgos asociados a la

Seguridad de la Información.

Gráfica 3: Preocupaciones en materia de Seguridad de la Información en las empresas de

Latinoamérica.
Fuente: ESET Security Report 2016

2.5.2 Incidentes de Seguridad registrados

A continuación, se muestran los resultados del informe de ESET Security Report 2016,
donde se centra en conocer los principales incidentes de seguridad que afectaron a las empresas el
año anterior. Para ello, se consideró los eventos indeseados e inesperados más comunes, que tienen
una probabilidad significativa de comprometer las operaciones de las organizaciones y atentar
contra la confidencialidad, integridad o disponibilidad de la información.
 15

Gráfica 4: Incidentes de Seguridad de la Información en las empresas de Latinoamérica (por

tamaño de empresa)
Fuente: ESET Security Report 2016

En la presente investigación, se hace énfasis en lo que es la Explotación de

Vulnerabilidades y Ataques de Denegación de Servicios, ya que son técnicas que son utilizados en
un test de intrusión. De hecho, son parte vital.

Es interesante también, conocer y analizar las preocupaciones que tienen las empresas en
Latinoamérica en materia de seguridad, ya que estas se preocupan por evitar los casos de fraude,
aunque como se pudo ver con anterioridad este tipo de incidentes son los que menos sucede. Los
casos de Phishing, que son los más habituales, luego de las infecciones de malware, son casi los
que menos preocupan a las empresas, delante de los ataques de denegación de servicio.

Asimismo, es importante hacer notar que, tanto el informe de ESET, como informes de
otras firmas de consultoría en la región como Deloitte TTL, a través de Deloitte Technology, Media
and Telecommunications Predictions, Deloitte TTL (2017), indican que, las empresas todavía hacen
inversiones mayoritariamente en soluciones de seguridad tecnológica, como Firewall, IDS’s,
 16

IPS’s, entre otras, pero carecen de personal capacitado para el tema de gestión, análisis e incidentes
de Seguridad Informática. Como consecuencia, el mercado está viendo nacer servicios de
Tecnología y Seguridad “As a Service”, como lo son los SOC (Service Operations Center)
Tercerizados.

2.6 GNU/Linux
Es un sistema operativo que hoy en día tiene mucho auge a nivel de servidores: de
aplicaciones, de correo, de Voz IP, plataformas de servicios en la nube, entre otros. Es un sistema
operativo de código abierto basado en Unix, aunque su principal característica es que, al ser de
código abierto, millones de programadores y voluntarios participan activamente en su desarrollo.
Tiene más de 20 años de vida, y su potencial radica en la combinación de su núcleo Linux
(desarrollado inicialmente por Linus Torvals en los años 80’s) con aplicaciones y complementos
periféricos desarrollados por terceros involucrados con el Software Libre y de Código Abierto.

2.7 Estadística de uso de sistemas operativos

Microsoft Windows, es a la fecha el sistema operativo dominante a muchos niveles, y
aunque la tecnología es muy variante y han perdido oportunidades en determinados campos (como
los dispositivos móviles), han sabido crear e implementar un modelo de negocio muy rentable con
el cual han obtenido resultados económicos gigantescos gracias a sus estrategias de mercadeo.

2.7.1 Sistemas Operativos en el Escritorio

Para poder tener conocimiento sobre las comparativas entre sistemas operativos, a nivel de
escritorio, se puede recurrir a la siguiente gráfica que contiene estos datos:
 17

Gráfica 5. Uso de sistemas operativos en aplicaciones de escritorio. Octubre 2016.

Fuente: http://marketshare.hitslink.com/

2.7.2 Sistemas Operativos en los Servidores

Por otro lado, a nivel de servidores, los sistemas tipo Unix son los que dominan el mercado,
ya que aparentemente son más robustos y muchos de los sistemas tipo Unix tienen una repercusión
económica por ser libres y/o de código abierto. Se puede apreciar la distribución de las 500
supercomputadoras a nivel mundial y los sistemas operativos que utilizan:

Gráfica 6. Uso de sistemas operativos, supercomputadoras del mundo. Octubre 2016.

Fuente: http://www.top500.org/statistics/list/
 18

Linux domina con un 82.6% versus otros sistemas operativos, aunque cabe mencionar que
en esta categoría se encuentran distribuciones GNU/Linux que utilizan el kernel Linux como tal
(sin modificaciones) y esto la diferencia de otras distribuciones que encajan dentro de su propia
categoría, como Red Hat, quienes cuentan con su propia compilación del kernel Linux, o SuSE
Linux.

2.7.3 Estadísticas Servidores Web

La siguiente tabla muestra el porcentaje de uso de los servidores web más utilizados, para
tecnologías web.
 19

Gráfica 7. Uso de servidores web para sitios web. Octubre 2016.

Fuente: http://w3techs.com/technologies/overview/web_server/all

2.8 Hacking Ético

Cuando las organizaciones comenzaban a hacer uso del internet (conocida en sus inicios
como ARPANET), no se tenía mucho conocimiento sobre el ámbito de la seguridad de los sistemas.
En ocasiones, los administradores de los sistemas eran quienes, de alguna forma, se percataban de
pequeños errores o fallas en los sistemas, denominados “bugs”, y trataban de remediarlos con lo
que tenían a la mano.

Al final de los 80’s y principio de los 90’s, las organizaciones comenzaban a sumergirse y
ser parte del internet; empezaba el auge del comercio electrónico, las conexiones B2B (Business
to Business) y poco a poco, fueron dándose casos de personas que “hackeaban” los sitios por
diversión, o con fines ilícitos como robo o fraudes electrónicos.

Sumado a esto, no existía una plataforma educativa formal que instruyera a profesionales
en el ámbito de la seguridad informática, ni mucho menos certificaciones que validaran los
conocimientos adquiridos. Debido al auge que se comenzó a dar, en términos de anti-seguridad
informática, muchos profesionales comenzaron a instruirse por su propia cuenta, y ofrecer sus
servicios externos a organizaciones que podían verse afectadas por intrusiones a sus sistemas. Esta
 20

metodología adoptó el término de “Hacking Ético”, pues ciertamente, para protegerse de un ataque
cibernético, es necesario pensar y actuar tal cual un atacante real lo haría, para así conocer nuestras
propias debilidades, y mejorar continuamente todas las capas de seguridad de nuestra
organización.

Es importante hacer énfasis en la palabra ética, ya que si, por ejemplo, un banco decide
contratar a una persona para violar sus medidas de seguridad, esta persona por lógica debe ser una
persona ética, pues luego de acordar los términos de confidencialidad con el cliente, el profesional
no podría por ejemplo divulgar las fallas en los sistemas que tiene el banco, o publicar contraseñas,
nada de esto, debe apegarse a los lineamientos éticos que demandan sus servicios profesionales.

A este profesional que lleva a cabo todas las evaluaciones de seguridad, se le denomina
“Hacker Ético”, o conocido también como Hacker de Sombrero Blanco (White Hat Hacker). Una
vez que oímos hablar de este tipo de profesionales, no debería de identificársele con la imagen
errónea que los medios de comunicación han creado sobre las personas con conocimientos
avanzados en tecnología: Hackers, ya que normalmente, se les suele asociar con actividades
ilícitas. Incluso, la Real Academia Española (RAE), que recientemente acaba de aceptar
formalmente el término Hacker, hace referencia a su implicación con actividades ilícitas.

2.9 Test de Intrusión

Conocido también como Penetration testing, o simplemente “pentest”, es el proceso de
evaluación activo y continuo, de las medidas de seguridad de la información de una compañía. Las
medidas de seguridad son analizadas activamente para determinar su nivel de debilidad, fallas
técnicas y vulnerabilidades. Los resultados son expresados en una manera compresible en un
informe, el cuál debe ser interpretado tanto por las partes Ejecutivas, Gerenciales, Administrativas
y Técnicas.

Un test de intrusión puede llevarse a cabo de forma independiente o bien como parte de un
proceso de Manejo de Riesgos que puede ser incorporado dentro de un ciclo de vida de desarrollo
(por ejemplo, Microsoft SDLC). Es importante recalcar que la seguridad de un producto o un
entorno de sistemas, no sólo depende de factores que están relacionados al ambiente de TI, ya que
 21

también depende de las mejores prácticas específicas del producto en materia de seguridad. Esto
involucra la apropiada implementación de requerimientos de seguridad, realizar análisis de riesgos,
modelado de amenazas, revisión de código y una medición de la seguridad operativa.

El test de intrusión es considerado una de las formas más agresivas de evaluar la seguridad.
Debe ser llevado a cabo por profesionales calificados y puede hacerse con o sin conocimiento
previo de la red o aplicación objetivo. Este puede utilizarse para medir todos los componentes de
la infraestructura de TI incluyendo aplicaciones, red, dispositivos, sistemas operativos, medios de
comunicación, seguridad física, y psicología humana. Los resultados de un test de intrusión
usualmente consisten en reportes divididos en varias secciones que especifican las debilidades
encontradas en el estado del entorno objetivo, acompañado de medidas de remediación o
recomendaciones para la prevención.

2.10 Tipos de test de intrusión

Existen tres formas de realizar un test de intrusión:

2.10.1 Pruebas de Caja Negra

Conocido como Black Box Test, es una prueba llevada a cabo de manera externa, es decir
desde internet, o en otras palabras no estando dentro de la LAN de la empresa objetivo. No requiere
conocimiento previo de la infraestructura que será testeada, es decir, simula el proceso de un
atacante real. Para el Auditor de Seguridad, podría comenzar simplemente con el nombre de la
empresa, ningún detalle adicional, por lo que, implica una gran cantidad de tiempo para poder
determinar el diseño de la infraestructura a evaluar.

El riesgo puede ser medido de acuerdo a la falla expuesta por la vulnerabilidad en general.
Un Auditor de Seguridad, idealmente identificaría todos los vectores de ataque que podrían causar
que el objetivo sea comprometido. Un test de intrusión Black Box suele ser más costoso que su
contraparte White Box, ya que cabe mencionar que cuando se realiza el pentest tipo Black Box, el
pentester no conoce ni posee ningún dato de la empresa, y debe hacer uso de técnicas varias para
poder hacerse de información útil y comenzar a hacer sus testeos. Los Auditores de Seguridad que
realizan este tipo de test, son denominados Hackers de Sombrero Negro (Black Hat Hackers).
 22

2.10.2 Pruebas de Caja Blanca

Conocido como White Box Test, es una prueba llevada a cabo de manera interna, es decir
dentro de la LAN (Local Area Network). Un Auditor de Seguridad que utiliza este tipo de test de
intrusión posee información sobre el ambiente objetivo, previamente. Se provee información
como: infraestructura de la compañía, tipo de red, implementaciones de seguridad actuales,
direcciones IP, detalles de firewall e IDS, políticas de la compañía, entre otros. Con esto, el Auditor
de Seguridad puede evaluar las vulnerabilidades con el mínimo esfuerzo comparado con el test de
caja negra, y mayor acierto. Este tipo de test provee un valor agregado a la organización ya que
puede eliminar cualquier inconveniente de seguridad interna concerniente a la infraestructura del
entorno objetivo, además de hacer aún más complicado para un atacante tratar de infiltrarse desde
afuera.

Además, el resultado de un pentest tipo White Box puede ser fácilmente integrado dentro
de un ciclo de desarrollo regular para erradicar cualquier posible eventualidad de seguridad en las
etapas tempranas, antes que sean descubiertas y explotadas por atacantes o intrusos externos. El
tiempo, costo y nivel de conocimiento requerido para encontrar y resolver vulnerabilidades, es
relativamente menor comparado con el test de caja negra, desde el punto de vista de tiempo
invertido por parte del Auditor de Seguridad. Los Auditores de Seguridad que realizan este tipo de
test, son denominados Hackers de Sombrero Blanco (White Hat Hackers).

Este tipo de test, a su vez tiene dos variantes: prueba anunciada, y prueba no anunciada.
El primero, notifica al personal de TI sobre las actividades que serán llevadas a cabo, y lo involucra
en ciertas actividades. El segundo, no realiza esta notificación, básicamente para medir la respuesta
del personal de TI con respecto a los incidentes.

2.10.3 Pruebas Caja Gris:

Conocido como Gray Box Test. Se lleva a cabo con información limitada sobre la
infraestructura a evaluar. Normalmente se realiza cuando el Auditor de Seguridad comienza con
un test de caja negra, pero es necesario un poco de información al respecto de algunos sistemas en
particular. Los Auditor de Seguridad que realizan este tipo de test, son denominados Hackers de
Sobrero Gris (Gray Hat Hackers), y también son conocidos por explotar vulnerabilidades con la
autorización de un proveedor/creador de una herramienta de software.
 23

Normalmente esto se hace con fines lucrativos, y en el mejor de los casos pueden
descubrirse vulnerabilidades día cero. A este tipo de hackers, se les denomina Gray Hay Hackers.
Entonces, Gray Box Testing, es la actividad de encontrar vulnerabilidades de un producto o
servicio informático en particular, con la respectiva autorización de la casa matriz.

2.11 Análisis de Vulnerabilidades versus Test de Intrusión

Es importante conocer estos dos términos y sus diferencias, pues, aunque parecen ser lo
mismo, realmente uno es complemento del otro, y en el ámbito de seguridad de TI, podremos
encontrarnos con diferentes prestadores de outsourcing que podrán brindarnos estos dos servicios
por separado, y es oportuno conocer de qué se tratan. Una evaluación de vulnerabilidades
(vulnerability assessment), es un proceso que evalúa los controles de seguridad internos y externos,
identificando amenazas que podría poner los activos de la organización en peligro. Esta evaluación
técnica de infraestructura no sólo identifica los riesgos en la parametrización y políticas de defensa
actuales, sino que también recomienda y prioriza las estrategias de remediación.

La evaluación interna de vulnerabilidades provee medidas para asegurar sistemas internos,

mientras que la evaluación externa demuestra la seguridad de las defensas a nivel de perímetro.
En ambas evaluaciones, cada activo de la red es rigurosamente testeado a través de múltiples
vectores de ataque que permiten identificar amenazas que no han sido tratadas oportunamente.
Dependiendo del tipo de evaluación que se lleve a cabo, se puede realizar oportunamente sets
únicos de procesos de testeo, herramientas y técnicas que llevan a la identificación de
vulnerabilidades en la información de los activos en una forma automatizada. Esto puede lograrse
utilizando una plataforma de manejo de vulnerabilidades que trabaje con bases de datos de
vulnerabilidades actualizadas y que sea capaz de testear diferentes dispositivos en la red mientras
mantiene la integridad de la configuración. La evaluación de vulnerabilidades, puede ser una de
las fases de un ciclo completo de un test de intrusión.

Una diferencia importante entre evaluación de vulnerabilidades y test de intrusión, es que

este último va más allá del nivel de identificar vulnerabilidades, y realiza una serie de acciones
como la explotación, escalamiento de privilegios; además mantiene accesos dentro del sistema
objetivo. Por otro lado, una evaluación de vulnerabilidades provee un análisis detallado de brechas
 24

de seguridad que puedan existir en el sistema sin medir el impacto del sistema. Otro aspecto
diferenciador importante entre ambos términos es que un test de intrusión es considerado mucho
más intrusivo que una evaluación de vulnerabilidades y aplica de forma agresiva todos los métodos
técnicos para explotar el entorno de producción, en caliente. Sin embargo, el proceso de evaluación
de vulnerabilidades identifica de manera cuidadosa, y cuantifica, todas las vulnerabilidades de una
manera no intrusiva.

2.12 Justificación de una prueba de Intrusión

Cuando existe duda que la mitigación de controles como firewalls, Sistemas de Detección
de Intrusiones (IDS’s), monitoreo de integridad de archivos, otros son efectivos, un test de
intrusión completo es ideal. El escaneo de vulnerabilidades identificará vulnerabilidades
individuales; sin embargo, un test de intrusión pretende verificar si estas vulnerabilidades pueden
ser explotadas dentro del sistema objetivo.

Esta percepción, cuando se trata de ambos términos, puede confundirse el significado de

ambos. Un Auditor de Seguridad calificado debe procurar trabajar con el mejor tipo de evaluación
basado en el requerimiento del cliente, más que tratar de decidir por si mismo hacer una evaluación
o la otra. Asimismo, es responsabilidad del cliente revisar en detalle todos los aspectos a evaluar,
y técnicas a utilizar, dentro del programa de evaluación elegido, antes de tomar cualquier decisión
final.

Mediante la aplicación de un test de intrusión es posible identificar las amenazas que

pueden afectar los activos de información de una organización; además, reduce los costos de
seguridad de TI y provee un mejor Retorno en la inversión de Seguridad de TI (ROSI: Return On
IT Security Investment) identificando y resolviendo vulnerabilidades o debilidades en la
infraestructura de TI. Además:
 Se adoptan mejores prácticas de acuerdo a regulaciones legales e
industriales.
 Se hacen pruebas y valida la eficiencia de los controles de seguridad y
protección.
 25

 Da a conocer la perspectiva de seguridad, en términos de vulnerabilidades

de la organización, internas y externas.
 Provee información valiosa para prevenir posibles explotaciones futuras.
 Evalúa la eficiencia de dispositivos de seguridad de red como firewalls,
routers y servidores web.
 Puede ser un factor de evaluación de actualización de la actual
infraestructura de software y hardware, o mejoramiento o rediseño de la red.

Un test de intrusión, tiene naturalmente un costo de inversión más elevado que una
evaluación de vulnerabilidades. En Guatemala, los precios promedian en US$20,000.00, que
puede incluir únicamente una evaluación de vulnerabilidades, como una mezcla entre esta y un
test de intrusión, en cualquiera de sus ramas. La variación del precio depende del alcance de la
Auditor de Seguridad y el número de horas en término de experiencia de los Auditores de
Seguridad.
 CAPÍTULO 3: METODOLOGÍA DE TEST DE INTRUSIÓN
3.1 Introducción
Hoy en día, en internet se puede encontrar cualquier tipo de información o recurso. Para
realizar un test de intrusión, hay miles de sitios web que explican de muchas formas las fases, y
algunas técnicas de cómo realizar cada una de las fases. Sin embargo, aunque puede existir un
lineamiento de qué se debe hacer, y en qué orden, también es cierto que el éxito de un test de
intrusión depende de muchos factores, como lo puede ser la experiencia de los Auditores de
Seguridad, el nivel de compromiso de la organización cliente y su equipo técnico, las
certificaciones con que cuente el Auditor de Seguridad, sin dejar atrás la constante actualización
con temas de seguridad, parches, vulnerabilidades, exploits 4 y técnicas con las que deben estar al
día los Auditor de Seguridad a cargo del test de intrusión, así como una adecuada planificación,
definición de alcance e identificación de todos aquellos activos que sean de carácter importante o
confidencial para la organización.

Sin embargo, como cualquier actividad profesional, es necesario prescindir de una guía
formal que nos dicte las mejores prácticas para poder llevar a cabo un test de intrusión. Existen
diferentes guías, metodologías, o certificaciones que pueden brindarnos esta información. En este
capítulo mencionaremos aquellas que serán tomadas en cuenta para la presente investigación, y
podremos conocer finalmente cómo serán las fases del test de intrusión que se llevará a cabo,
tomando en cuenta la organización objetivo y el tipo de infraestructura que estará siendo sometida
a pruebas: GNU/Linux y aplicaciones Web Java con tecnologías de código abierto.

3.2 Estándar de Ejecución de Test de Intrusión

Por sus siglas en inglés PTES, o Penetration Testing Execution Standard. Consiste en siete
(7) secciones principales. Estas cubren todo lo relacionado con un test de intrusión, desde la
comunicación inicial hasta la inteligencia de recolección y fases de modelado de amenazas donde
los Auditores de Seguridad trabajan tras bambalinas para poder obtener un mejor entendimiento
de la organización que será testeada, a través de la investigación de vulnerabilidades, explotación
y post explotación, donde la habilidad técnica de los Auditor de Seguridad juega un papel
importante conjuntamente con el entendimiento y compromiso adquirido con la organización, y

4
Un programa o código que se aprovecha de un agujero de seguridad (vulnerabilidad) en una aplicación o sistema, de forma qu e un atacante
podría usarla en su beneficio.

26
 27

finalmente, la fase de informes, que captura el proceso completo, en una forma que haga sentido
al cliente y provea lo más valioso del test.

Gráfica 8. Logo PTES

Fuente: http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

Las secciones principales definidas por este estándar son:

3.2.1 Fase de Planificación y acuerdos

En esta primera etapa del test de intrusión, se llevan a cabo reuniones de planificación con
el equipo técnico de la organización cliente, con el objetivo de definir el alcance, se realizan
encuestas de acuerdo a los diferentes tipos de test que se puedan llegar a realizar (red wifi,
ingeniería social, aplicaciones web, etc.), tiempos, técnicas a ser utilizadas, y estrategias de
comunicación. Asimismo, se realizan documentos de confidencialidad que garantizarán a la
organización que la información obtenida como resultado del test de intrusión, será para uso y
análisis exclusivo de ellos y no será compartida con terceras personas. Esta fase, en la presente
investigación es denominada Fase de Planificación.

3.2.2 Fase de Reconocimiento

Esta fase consiste en obtener toda la información necesaria de la organización y los
sistemas objetivos, desde nombres de usuarios, hasta números de IP y realizar los respectivos
 28

diagramas de red para referencia. Es una de las fases más importantes ya que durante las siguientes
fases, que son más intrusivas, se hará uso de la información que sea obtenida en esta fase. Mientras
más minuciosa y detallada se realice esta fase, más probabilidad de efectividad habrá para la fase
de análisis y explotación de vulnerabilidades.

El PTES lleva esta fase a un nivel más alto, denominándolo “Inteligencia”, ya que se basa
en algunos métodos y técnicas militares de inteligencia. De hecho, existe lo que se denomina
Fuentes de Información OSINT (Open Source INTelligence), que hacen referencia a cualquier
información desclasificada y públicamente accesible en Internet de forma gratuita. Para la presente
investigación, debido al alcance y tipo de organización cliente seleccionada, no se profundizará en
OSINT; nos mantendremos apegados a la Fase de Reconocimiento.

3.2.3 Fase de Modelado de amenazas

El PTES no utiliza un modelo específico para determinación de amenazas, pero requiere
que el modelo que se utilice sea consistente en términos de las amenazas que puedan ser
consideradas, sus capacidades, su nivel de criticidad, de acuerdo a cómo se lleve a cabo el test de
intrusión, y la habilidad que dicho modelo pueda ser rápidamente aplicado en futuros test
obteniendo los mismos resultados.
En esta fase, normalmente puede tomarse como punto de partida un análisis FODA de la
organización y básicamente el proceso completo del modelado de amenazas consiste en:
 Recopilar documentación relevante
 Identificar y categorizar activos primarios y secundarios
 Identificar y categorizar amenazas y comunidades de amenazas
 Mapear comunidades de amenazas con sus respectivos activos primarios y
secundarios.

De acuerdo al PTES, deben identificarse y documentarse estos cuatro elementos en todo

test de intrusión; sin embargo, debido a la naturaleza de la presente investigación, esta fase se
considera que será incluida en la fase de Planificación.
 29

3.2.4 Fase de Análisis de vulnerabilidades

Esta fase incluye lo que es el escaneo del objetivo para identificar vulnerabilidades, desde
errores de código, vulnerabilidades día cero5, sistemas desactualizados, carencia de parches. Esta
etapa no es intrusiva, pero la información que se obtenga de en esta fase podrá ser utilizada para
posteriormente explotar las vulnerabilidades encontradas, ya sea con mecanismos que generen el
malfuncionamiento del sistema objetivo, uso de herramientas automatizadas de explotación, o
desarrollo de herramientas de explotación a medida. También se le denomina Mapeo de
Vulnerabilidades.

3.2.5 Fase de Explotación

La explotación, es la fase del test de intrusión donde se hace énfasis en establecer accesos
a un sistema o recurso traspasando las restricciones de seguridad. En la fase anterior, si el análisis
de vulnerabilidades (o enumeración) fue llevado a cabo de manera correcta, esta fase debería ser
como un ataque de precisión. El objetivo principal es identificar el punto principal de acceso hacia
el objetivo e identificar objetivos de alto valor (activos).

3.2.6 Fase de Post-explotación

Una vez que se ha conseguido acceso al sistema en la fase de explotación, es necesario
obtener información sobre otros servicios, sistemas o datos sensibles que pueden ser accedidos
desde el sistema vulnerado.

3.2.7 Documentación
En esta fase debe elaborarse los diferentes informes que deben entregarse al cliente.
Normalmente pueden entregarse dos tipos de informes:
 Ejecutivos: orientados a altos mandos gerenciales con nociones básicas
sobre seguridad informática. No contiene detalles técnicos sino más bien una calificación
de los hallazgos más importantes y su impacto económico en términos de activos de la
organización.

5
Una nueva vulnerabilidad para la cual no se crearon parches o revisiones, y que se emplea para llevar a cabo un ataque. 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.
 30

 Técnicos: orientados al equipo técnico de la organización, que desea

conocer en detalle las vulnerabilidades y las técnicas utilizadas para explotarlas, para así
coordinar su adecuada remediación.

Planificación

Documentación Reconocimiento

Post-Explotación Enumeración

Análisis de
Explotación
Vulnerabilidades

Gráfica 9: Fases de un Test de Intrusión.

Fuente: Metodología PTES

Este estándar ha sido diseñado para proveer tanto a las organizaciones como a los
proveedores de servicios de seguridad un enfoque entendible sobre la elaboración de un test de
intrusión (por ejemplo, en evaluaciones de seguridad). Empezó en 2009 como una discusión entre
varios profesionales del área, ya que había, en términos generales, carencia de una metodología de
test de intrusión en la industria.

Entre las organizaciones involucradas en este proyecto, se puede encontrar representantes

de: Lares Consulting, TrustedSec, Productos AVON, scip AG, InGuardians, SecureState,
RandomStorm, entre otros.
 31

El estándar en sí, no es guía técnica sino más bien una forma de cómo ejecutar un test de
intrusión, al estilo checklist. Sin embargo, se ha creado una guía técnica para acompañar al estándar
en sí mismo.

3.3 Manual de la Metodología Abierta de Pruebas de Seguridad (OSSTMM)

Por sus siglas en inglés, Open Source Security Testing Methodology Manual, es un manual
que combina ambición, estudio y años de experiencia de profesionales en el área de la seguridad.
Los test individuales no son particularmente revolucionarios, pero la metodología en conjunto
representa un estándar de referencia en el área de testeo de seguridad. Dicho manual es un estándar
profesional para el testeo de seguridad en cualquier entorno, desde el exterior al interior. Como
cualquier estándar profesional, incluye los lineamientos, la ética del Auditor de Seguridad, la
legislación sobre el testeo de seguridad y un conjunto integral de test.
Actualmente existen dos versiones de esta metodología, la 2.1, liberada en 2003 y traducida
oficialmente al español y la 3.0 liberada en 2010. Para la presente investigación, se hace uso de la
versión 2.1, ya que esta, en su apéndice, cuenta con plantillas específicas para los diferentes tipos
de test de intrusión, lo cual se ha considerado un excelente complemento para el ciclo del test de
intrusión como tal, por ser del tipo checklist, pero también por ser útil como parte de los informes
técnicos que se entregan al cliente al finalizar el test de intrusión.

3.4 Proyecto OWASP

The Open Web Application Security Project (Proyecto Abierto de Seguridad de las
Aplicaciones Web) es una comunidad mundial libre y abierta enfocada en mejorar la seguridad de
las aplicaciones de software. Su misión es hacer la seguridad de las aplicaciones “visible”, para
que las personas y organizaciones puedan tomar decisiones acerca de los riesgos en la seguridad
de sus aplicaciones, de forma correcta.

OWASP impulsa varias iniciativas y proyectos, siendo uno de ellos el OWASP Top 10,
que es un listado de las vulnerabilidades más recurrentes, identificadas por cientos de profesionales
independientes y empresas que se dedican a auditar la seguridad de las tecnologías Web,
 32

Gráfica 10: Logo proyecto OWASP

Se toma como referencia este listado, para poder realizar los testeos específicos en las
aplicaciones web definidas dentro el alcance para la ejecución de la parte práctica de esta
investigación:

No. Descripción
1 Inyección
2 Pérdida de autenticación y gestión de sesiones
3 Secuencia de comandos en sitios cruzados (XSS)
4 Referencia directa insegura a objetos
5 Configuración de seguridad incorrecta
6 Exposición de datos sensibles
7 Inexistente control de acceso a nivel de funcionalidades
8 Falsificación de peticiones en sitios cruzados (CSRF)
9 Uso de componentes con vulnerabilidades conocidas
10 Redirecciones y re envíos no validados

3.5 Normativas ISO/IEC

Un test de intrusión es un componente esencial de cualquier Sistema de Gestión de
Seguridad de la Información ISO 27001, desde las fases iniciales hasta las fases de mantenimiento
y mejoramiento continuo.

El objetivo de control ISO 27001 A12.6, Gestión de la Vulnerabilidad Técnica, indica: “se
debe obtener información oportuna sobre las vulnerabilidades técnicas de los sistemas de
 33

información en uso; se debe evaluar la exposición de la organización ante esas vulnerabilidades;

y se deben tomar las medidas apropiadas para tratar el riesgo asociado”.

La naturaleza de los activos de la tecnología de información significa que pueden tener

muchas vulnerabilidades técnicas que podrían ser explotadas por atacantes externos. Un ataque
informático apunta a vulnerabilidades identificables en hardware y software en una organización.
Estas vulnerabilidades pueden incluir software no parcheado, contraseñas débiles, sitios web mal
codificados y aplicaciones inseguras.

El punto de inflexión en done se identifica que se debe realizar un test de intrusión, es una
vez que se hayan identificado los activos que serán incluidos en el alcance del Sistema de Gestión
de Seguridad de la Información. Los resultados del test de intrusión identificarán vulnerabilidades
en detalle, conjuntamente con las amenazas que podrían explotarla, y usualmente también
identifica alguna actividad apropiada para su remediación. Las vulnerabilidades y amenazas
identificadas se convertirán en información de punto de partida para una evaluación de riesgo,
mientras que las actividades de remediación serán parte de los controles de la organización.

3.5.1 El Test de Intrusión en un proyecto de ISO 27001

Existen puntos específicos dentro de un Sistema de Gestión de Seguridad de la Información
en donde el Test de Intrusión contribuye significativamente, como parte de:

 Proceso de Evaluación de Riesgos: vulnerabilidades no corregidas en

cualquier dirección IP de cara al internet, aplicaciones web, o aplicaciones o dispositivos
internos, y asociarlos con amenazas identificables.
 Plan de Tratamiento de Riesgos: asegurando que los controles que están
siendo implementados funcionen para lo que han sido diseñados.
 Procesos de Mejoramiento Continuo: asegurando que los controles
continúen funcionando como sean requeridos y que las nuevas amenazas y
vulnerabilidades emergentes sean identificadas y sea posible lidiar con ellas.
 34

3.6 Otros documentos técnicos de soporte a las metodologías

Además de las dos metodologías mencionadas anteriormente, existe una serie de entidades
que proveen recursos de alto nivel, como tutoriales, papers, (documento tipo tutorial de carácter
técnico, de alto nivel, de un tema específico, normalmente de tipo investigativo) guías, e incluso
fragmentos de código, que apoyan determinadas fases del test de intrusión para aumentar la calidad
del test que se llevará a cabo. A continuación, se mencionan las más importantes.

3.6.1 NIST SP 800-115

El NIST es el Instituto Nacional de Estándares y Tecnología (por sus siglas en inglés NIST:
National Institute of Standards and Technology) del gobierno de Estados Unidos y posee un
Laboratorio de Tecnología de Información (ITL: Information Technology Laboratory). NIST, a
través del Centro de Recursos de Seguridad Informática (por sus siglas en inglés CSRC: Computer
Security Resource Center) provee una serie de documentos técnicos, mejores prácticas, marcos de
trabajos e investigaciones de alto nivel, que pueden ser utilizadas en muchos campos específicos
de la Seguridad Informática, como lo son las Publicaciones Especiales, o SP (Special
Publications).

La Publicación Especial 800-115 es una guía técnica para pruebas y evaluación de

Seguridad de la Información, fue publicada en septiembre de 2008 y fue creado con el objetivo de
ser utilizado por agencias federales de los Estados Unidos, pero puede ser utilizado por entidades
no gubernamentales ya que es de libre distribución. El objetivo de esta publicación es proveer
lineamientos para organizaciones que estén planeando realizar pruebas técnicas de seguridad de la
información, analizar resultados, y desarrollar estrategias de mitigación.

Provee recomendaciones prácticas para diseño, implementación e información técnica

sobre el mantenimiento relacionado con pruebas de seguridad y procesos de evaluación, los cuales
pueden ser utilizados para varios propósitos, como encontrar vulnerabilidades en un sistema o red
y verificar su cumplimiento con una política u otros requerimientos. Esta guía no presenta una
metodología de test de intrusión o programa de evaluación como tal, en vez de eso es una
panorámica general de los elementos clave de un test técnico de seguridad y evaluación haciendo
énfasis en técnicas específicas, sus beneficios y limitaciones, recomendaciones y su uso.
 35

3.6.2 Consorcio Internacional de Consultores de Comercio Electrónico

El EC-Council (International Council of Electronic Commerce, o Consorcio Internacional
de Comercio Electrónico) es una entidad líder en el área de cursos sobre Seguridad Informática y
Seguridad de la Información. Provee certificaciones de talla mundial como CEH (Certified Ethical
Hacker) y además es creadora de una metodología de test de intrusión denominada Licensed
Penetration Tester (LPT), la cual se toma como referencia para determinados aspectos del test de
intrusión en la presente investigación.

3.6.3 SANS Institute

El instituto SANS (SysAdmin Audit, Networking and Security Institute) es una entidad
que se especializa en capacitar a profesionales de la Seguridad de la Información y Ciberseguridad.
Provee varios proyectos de pago como recursos en línea gratuitos; algunos de estos últimos son
tomados en cuenta para la presente investigación.

3.6.4 Infosec Institute

El Infosec Institute es otra entidad que se especializa en capacitaciones relacionadas a
Seguridad Informática y Seguridad de la información. Cuenta también con recursos online
gratuitos de alto nivel técnico, los cuáles son utilizados para ciertas técnicas específicas durante el
desarrollo del test de intrusión en la presente investigación.

3.7 Metodologías para aplicación del Test de Intrusión

Esta investigación, se basa puntualmente en las metodologías PTES y OSSTMM. La
PTES provee las fases concretas del test de intrusión, así como una guía técnica de trabajo de
soporte para el estándar en sí. La OSSTMM es una metodología que está orientada más a la
verificación de políticas y buenas prácticas y no contiene guía de trabajo técnica. Sin embargo,
provee plantillas que proveen un valor agregado para el acompañamiento de algunas fases del test
de intrusión, así como soporte para la documentación final que se entrega al cliente. Asimismo, se
utilizan ciertos recursos específicos de NIST, EC-Council, SANS Institute e InfoSec Institute para
realizar determinadas actividades técnicas, ya que su contenido es de alto nivel. Para la parte de
test de intrusión de aplicaciones web, se estará haciendo uso del OWASP Top 10.
 36

Por tanto, las ocho fases del test de intrusión para este trabajo de investigación serán:
1. Planificación
2. Reconocimiento
3. Enumeración
4. Mapeo de vulnerabilidades
5. Explotación
6. Post-Explotación
7. Test de intrusión de Aplicaciones Web
8. Elaboración de informes
 CAPÍTULO 4: FASE DE PLANIFICACIÓN
4.1 Introducción
Un Test de Intrusión, es un proyecto que consiste en un conjunto de actividades que se
encuentran interrelacionadas y coordinadas. Como todo proyecto, debe pasar por varias fases,
desde la incepción de la idea, su diseño, su ejecución y su evaluación. Asimismo, debe contar con
documentación de sustento muy importante, como lo pueden ser las minutas, contratos, convenios
de confidencialidad, y por supuesto su respectivo presupuesto.

En este capítulo, se da inicio a la primera fase formal de un test de intrusión. Es una fase
donde se definen los alcances, y en base a esto se podrá definir los recursos como el tiempo y el
personal, para obtener un costo determinado.

Se menciona la importancia de la reunión de planificación, donde tanto las partes

comerciales, técnicas y de ser posible directivas, deben dar inicio a la discusión de temas que
ayudarán que el test de intrusión obtenga los resultados esperados, de acuerdo a los objetivos del
cliente. Para esto, deberá definirse una serie de cuestionarios que ayudarán al Auditor de Seguridad
a confirmar los tipos de test que se llevarán a cabo, y por supuesto en base a esto generar una
propuesta comercial que satisfaga las necesidades del cliente.

Asimismo, se hace hincapié en la necesidad de considerar la manera de evaluar los

servicios de terceros, si llega a ser necesario, ya que, en algunos escenarios específicos, el cliente
necesita testear la seguridad de ciertas aplicaciones en la nube, que contrata por servicio a
proveedores externos; es importante tomar ciertas medidas para estos casos.

Por último, es importante tener el debido cuidado con los aspectos legales. Básicamente
PTES facilita ciertas directrices genéricas que pueden ser utilizadas en todos los países, pero es
responsabilidad del Auditor de Seguridad alinear estas recomendaciones con las leyes locales
donde se realice el test. Se provee una extensión de estas directrices enfocados en las leyes de
Guatemala, que podrían ser objeto de una investigación específica por parte de un Ingeniero o
Abogado especializados en Derecho Informático, donde a la fecha de redacción de la presente
investigación, existe únicamente algunos artículos del Código Penal y dos iniciativas interesantes

37
 38

que han sido presentadas ante el Congreso de la República. Si el objetivo primordial de ellas es
poder proveer al ciudadano o empresa una base legal para defensa en términos penales cuando un
delito informático sucede. Sin embargo, es importante que el Auditor de Seguridad conozca estas
leyes para poder salvaguardar la legitimidad del test de intrusión del cual estará encargado.

4.2 Definición de Alcance

Definir el alcance es una de las tareas más importantes de un test de intrusión, aunque
también suele ser una de las más incompletas. Normalmente se puede obtener mucha información
técnica sobre cómo obtener acceso a una red, pero se debe dar la importancia a algunos temas que
deben tenerse en cuenta antes del test de intrusión: la planificación. El descuido de las actividades
que se llevan a cabo dentro de la planificación, podrían causar problemas al Auditor de Seguridad,
incluyendo la pérdida o desenfoque del alcance, clientes insatisfechos, e incluso problemas legales.
El alcance de un proyecto define específicamente qué será testeado; por otra parte, el cómo cada
aspecto del test será llevado a cabo se detalla más adelante en la sección de Acuerdos.

4.3 Métricas para la estimación de tiempo

Las estimaciones del tiempo están directamente ligadas a la experiencia del Auditor de
Seguridad en determinadas áreas. Si un Auditor de Seguridad tiene experiencia significativa en
cierto tipo de test, será capaz de determinar por sí mismo en cuánto tiempo podrá realizar dicho
test. Si el Auditor de Seguridad no tiene tanta experiencia en el área, recurrirá a la revisión de test
de intrusión previos que su empresa (firma de Auditores de Seguridad) haya realizado, lo cual es
una manera útil de estimar el tiempo requerido para el proyecto que lleve a cabo. Luego de
determinar el tiempo, es recomendable agregar un de un 10% a un 20% de tiempo.

Este porcentaje adicional de tiempo es absolutamente necesario para cualquier test de

intrusión. Proporciona tiempo de holgura en caso que alguna eventualidad suceda durante el
proceso de testeo. Existen muchos eventos que pueden ocurrir normalmente y que obstaculizan las
pruebas de seguridad. Por ejemplo, un segmento de la red podría caer fuera de servicio, o una
vulnerabilidad significativa puede requerir muchas reuniones a muchos niveles de la gerencia para
determinar la manera de actuar. Ambos eventos consumen tiempo y podrían impactar
significativamente la estimación de tiempo original si no se ha de contemplar un tiempo adicional
para este tipo de situaciones.
 39

4.4 Reunión de Planificación

En esta reunión se definen los alcances del test de intrusión. En muchas ocasiones, esta
reunión sucede luego que los contratos o propuestas económicas ya han sido firmados. Esto es un
error, ya que es altamente probable que sucedan incidentes no planificados, o malos entendidos
debido a que, a nivel comercial, legal o económicamente hablando pudo haberse acordado algo,
pero al discutir ambas partes técnicas (cliente y Auditor de Seguridad) puede existir aspectos no
considerados. De cualquier modo, algunas situaciones especiales pueden darse incluso si la
reunión de planificación se realiza antes de la firma de cualquier contrato, pero serán mínimos o
no deberían tener un gran impacto. Para esta clase de situaciones, y temas de confidencialidad y
seguridad de la información, se realiza un convenio de confidencialidad, entre el cliente y el
Auditor de Seguridad.

El objetivo de la reunión de planificación es discutir la infraestructura, sistemas,

aplicaciones que serán testeados. Los acuerdos y costos no están fuera de los temas que deben
tratarse en esta reunión inicial. Esto se hace de esta forma, porque las discusiones pueden volverse
fácilmente confusas si el objetivo de la reunión no ha sido especificado. Es muy importante que el
Auditor de Seguridad actúe como moderador para mantener las discusiones dentro del tema
principal, previniendo argumentos o ciertos temas fuera de enfoque para otra discusión, cuando
sea necesario.

Primero, debe establecerse explícitamente qué rangos de direcciones IP serán analizados.

Puede ser que el cliente se resista y asuma que es parte de las tareas del Auditor de Seguridad
identificar la red y atacar, para hacer el test lo más cercano a la realidad (desde el punto de vista
de un atacante externo). Esto sería una situación ideal, sin embargo, es necesario tomar en cuenta
ciertas implicaciones legales que están por encima de todo.

4.5 Cuestionarios
Durante la reunión de planificación también es importante que el Auditor de Seguridad esté
preparado con una serie de preguntas clave para poder determinar y medir el alcance que tendrá el
proyecto. Estas preguntas están diseñadas para proveer un mejor entendimiento de qué es lo que
el cliente necesita o espera obtener como resultado luego de realizar el test de intrusión, por qué el
cliente está buscando un servicio del tipo intrusivo para su entorno, y si requerirá o no,
 40

determinados tipos de intrusiones. Las preguntas deben girar en torno a los diferentes tipos de test
de intrusión que se pueden llevar a cabo: de red, de aplicaciones web, de redes inalámbricas, acceso
físico, ingeniería social, e incluso preguntas para las gerencias de la organización.

En esta actividad es oportuno hacer mención de la metodología OSSTMM la cual nos

ofrece una serie de Plantillas que pueden utilizarse en el Test de Intrusión tanto para la fase de
planificación como para la fase de documentación.

4.6 Especificar Rangos de IP y Dominios

Antes de empezar con el test de intrusión, todos los objetivos deben ser definidos. Éstos
objetivos se obtienen del cliente durante la reunión de planificación. Los objetivos pueden ser
direcciones IP, rangos de red, o nombres de dominio proveídos por el cliente. En algunos casos, el
único recurso que el cliente provee es el nombre de la organización, y espera que el Auditor de
Seguridad sea capaz de identificar el resto por sí mismo (Black Box testing). Es importante definir
sistemas como firewall e IDS/IPS, o equipo de red que está entre el Auditor de Seguridad y el
objetivo final, ya que también es parte del alcance. Elementos adicionales como proveedores de
internet, y otros proveedores de servicios (outsourcing) deben ser identificados y confirmar si
entran dentro del alcance.

4.7 Relación con proveedores del cliente (terceros)

Existen algunos casos donde el alcance del proyecto incluye pruebas de seguridad de
ciertos servicios o aplicaciones de terceros. Esto ha ido en aumento en los últimos años, ya que los
servicios “en la nube” son requeridos cada vez más y más. Lo más importante es recordar que,
aunque los permisos sean dados por el cliente, éste no puede actuar en nombre de sus proveedores.
Es necesario obtener un permiso de los proveedores antes de realizar el test a los sistemas que
proveen. No obtener estos permisos, implica siempre la posibilidad de violar la ley.

4.7.1 Servicios en la nube

Lo más complicado de los servicios en la nube es que existen datos de diferentes
organizaciones almacenados en un mismo medio físico. Normalmente la seguridad entre los
diferentes grupos de datos no es muy robusta. Es necesario notificar al proveedor del servicio en
la nube y tener tanto la aprobación del cliente como de su proveedor. Además, es necesario tener
 41

un contacto de seguridad directo con el proveedor de servicios en la nube que pueda ser contactado
por cualquier evento que impacte a otros clientes de su servicio, por alguna vulnerabilidad
descubierta.

4.7.2 Proveedores de Servicio de Internet (ISP’s)

Es importante verificar los términos de servicio de los proveedores de internet con su
cliente (Internet Service Provider). Normalmente se le denominan Acuerdos de Nivel de Servicio
(SLA’s por sus siglas en inglés). En muchas situaciones comerciales, el ISP tendrá requerimientos
especiales cuando se presenta un test de intrusión. El Auditor de Seguridad debe verificar
cuidadosamente estos términos antes de lanzar cualquier ataque. Puede haber situaciones donde el
ISP detecte y bloquee cierto tráfico que pueda ser considerado malicioso. El cliente podría aprobar
este riesgo, pero debe ser comunicado adecuadamente antes de proceder. Cuando se trabaja con
proveedores de Alojamiento Web, así como cualquier otro proveedor de servicios, es de igual
forma importante que se determine el alcance y tiempos, y que esto sea comunicado
adecuadamente con dicho proveedor. Asimismo, en la línea de comunicación con el cliente, es
necesario aclarar que el test será realizado con un enfoque exclusivamente en búsqueda de
vulnerabilidades. El test no cubrirá explotación de vulnerabilidades dentro de la infraestructura del
proveedor, que de cualquier forma podría ser un vector de ataque para comprometer la aplicación.

4.8 Definir temas aceptados para pruebas de Ingeniería Social

Muchas organizaciones requerirán pruebas de Ingeniería Social, cuyo vector principal de
ataque es el factor humano. Estas técnicas, especialmente ataques de Phishing6 son muy utilizadas
en la actualidad. Es muy común que la mayoría de temas utilizados para este tipo de ataques sean
los relacionados con sexo, drogas, o simplemente temas de entretenimiento del momento. Algunos
de estos temas podrían no ser aceptados en el ambiente corporativo, por lo que el Auditor de
Seguridad debe obtener la aprobación de los temas que podrán ser utilizados durante este tipo de
pruebas.

6
Es una modalidad de estafa con el objetivo de intentar obtener de un usuario sus datos, claves, cuentas bancarias, números de tarjeta de crédito,
identidades, etc. Resumiendo "todos los datos posibles" para luego ser usados de forma fraudulenta.
 42

Algunas de las pruebas que pueden considerarse en este apartado son:

No Descripción
1 Suplantación de identidad
2 Llamadas telefónicas fraudulentas (vishing)
3 Pruebas controladas de Phishing
4 Pruebas intrusivas de Phishing
5 Intrusión Física
6 Falsificación de correos y sitios web (spoofing)

4.9 Ataques de Denegación de Servicios

Las pruebas de estrés, o Ataques de Denegación de Servicios (DoS, Denial of Service),
deben ser discutidos antes que el test de intrusión empiece. Puede ser un tema en el que muchas
organizaciones se sientan incómodas debido al potencial daño que provee este tipo de ataques. Si
la organización está preocupada únicamente por la integridad y confidencialidad de sus datos, esta
prueba podría no ser necesaria; sin embargo, si a la organización le preocupa la disponibilidad de
sus servicios, entonces un Ataque de Denegación de Servicio debe ser considerado en un ambiente
no productivo, que sea idéntico al ambiente de producción.

4.10 Objetivos
Todo test de intrusión debe estar orientado a objetivos o metas. Es decir, el objetivo de un
test es identificar vulnerabilidades específicas que pueden comprometer la misión y objetivos del
negocio del cliente; no se trata de encontrar sistemas que no están actualizados. Se trata de
identificar riesgos que impactarán a la organización.

Un objetivo para realizar un Test de Intrusión, puede estar directamente relacionado con el
cumplimiento de requerimientos específicos, como el ejemplo anterior de la norma PCI-DSS7. Es
común que el objetivo primario y los objetivos secundarios estén muy relacionados. Por ejemplo,
en el caso de la norma PCI-DSS, obtener las tarjetas de crédito es un objetivo secundario. La

7
Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago.
 43

vinculación de esa información con el negocio es el objetivo principal. Los objetivos son aspectos
que deben cumplirse y atraen la atención de los altos mandos (gerencias, directivos, etc.).

4.11 Establecer líneas de comunicación

Uno de los aspectos más importantes de cualquier test de intrusión es la comunicación con
el cliente. La frecuencia con la que se interactúe con el cliente, y el enfoque con el que se establezca
la comunicación puede hacer una gran diferencia en su percepción y satisfacción por el servicio
contratado. A continuación, se sugieren algunos lineamientos de comunicación que harán que el
cliente se sienta más cómodo sobre las actividades del test de intrusión:

4.11.1 Información de Contacto para Emergencias

En efecto, poder estar en comunicación con el cliente durante una emergencia es vital. Las
emergencias pueden surgir, y es requerido que un punto de contacto haya sido establecido para
atender las emergencias del caso. Debe crearse una lista de contactos. Esta debe incluir
información de contacto para todos los involucrados en el alcance del test. Una vez que haya sido
creada, la lista de contactos de emergencia debe ser compartida con todos los incluidos en dicha
lista. Debe tenerse en cuenta que, en algunos casos, la organización objetivo podría no ser el cliente
(como en el caso de los proveedores de servicios).

4.11.2 Proceso de reporte de incidentes

Es importante discutir las capacidades actuales de la organización para respuesta a
incidentes, antes de comenzar el test de intrusión, por varias razones. Parte del test, no es solamente
verificar la seguridad que la organización tiene, sino también medir y evaluar sus capacidades de
respuesta a incidentes.

Si los acuerdos del test de intrusión (durante la reunión de planificación, definición del
alcance, etc.) pueden ser establecidos sin siquiera notificar al equipo interno de seguridad de la
organización objetivo, significa que se ha detectado una brecha enorme en cuanto a la postura de
seguridad. Es importante también, que antes que de inicio el test de intrusión, algún representante
de la organización está consciente sobre cuándo se realizarán las diferentes actividades del test,
para que el equipo de respuesta a incidentes no realice las llamadas de notificación respectivas a
cada miembro de los grupos de Gerencia o Directivos en horarios convenientes.
 44

4.11.3 Cifrado para el manejo de información

La encriptación no debe ser opcional. La comunicación con el cliente es absolutamente
necesaria como parte de cualquier test de intrusión, y debido a la naturaleza de la información que
se comparte, esta debe ser encriptada, especialmente el informe final. Antes de iniciar el test debe
establecerse una vía de comunicación segura con el cliente. Se debería considerar la comunicación
por correo electrónico cifrado, así como cifrar el informe final. También se recomienda definir si
existe algún tipo de información que debería ser compartida únicamente vía telefónica o en
persona.

4.11.4 Línea de tiempo

Debe establecerse de manera clara la línea de tiempo en la que se estará trabajando. El
alcance define cuando inicia y termina el proyecto, pero los acuerdos definen todas las actividades
que se llevarán a cabo durante este tiempo. La línea de tiempo puede tener cambios conforme se
avanza en el proyecto. Por ello, debe mantener una línea de tiempo rígida no es el objetivo. En vez
de eso, contar con una línea de tiempo al inicio del test permitirá a todos los involucrados
identificar de manera clara las actividades que deben llevarse a cabo y las personas que serán
responsables de cada una. Los diagramas de GANTT son ampliamente utilizados para el manejo
de proyectos ya que permiten ver la asignación de recursos, y sus respectivos avances o retrasos,
o bien herramientas de control de proyectos en línea como Redbooth, Asana o Wrike.

4.11.5 Ubicaciones físicas

Otro aspecto importante que debe ser acordado son las ubicaciones hacia donde los
Auditores de Seguridad deben viajar durante el proyecto. Puede ser tan sencillo como añadir gastos
de transporte, o tan complicado como identificar las leyes que se aplican en determinados países
o estados.

Es común que una organización opere en varias ubicaciones y regiones y algunas

instalaciones serán elegidas para ser evaluadas. En estas situaciones, viajar hacia cada ubicación
de la organización no es recomendable. En cambio, se recomienda evaluar la posibilidad de realizar
conexiones vía VPN8 para realizar test remotos.

8
Red Privada Virtual.
 45

4.11.6 Manejo de evidencias

Cuando se manejan evidencias de un test y las diferentes partes del reporte, es muy
importante tener mucho cuidado con los datos. Es necesario utilizar métodos de cifrado y sanitizar
la computadora con que se realizan las pruebas técnicas, para cada test. Nunca debe almacenarse
los reportes en dispositivos de almacenamiento extraíble. Además, por ningún motivo deben re-
utilizarse los formatos de reportes de otro reporte previo como una plantilla, por motivos que se
puede olvidar eliminar información de test previos o bien porque puede dejar rastros de metadata,
con lo cual, si el reporte es obtenido por personas ajenas, pueden obtener información sensible sin
autorización.

4.11.7 Reuniones de Seguimiento

Durante la ejecución del test de intrusión es importante mantener reuniones periódicas para
retroalimentar al cliente sobre el avance del mismo. Estas reuniones deben enfocarse en tres
aspectos básicos: planes, progreso y problemas.

Los planes son generalmente discutidos para que el test no se lleve a cabo en medio de
actividades especiales para la organización. El progreso no es más que mostrar el avance de las
actividades para que el cliente esté enterado de qué se ha estado trabajando. Los problemas deben
ser discutidos también en estas reuniones, pero de manera breve, ya que las discusiones respecto a
cómo deben ser solucionados normalmente se llevan por separado, en sesiones más técnicas.

4.11.8 Consideraciones Legales

Algunas actividades comunes dentro del proceso del test de intrusión podrían violar
algunas leyes locales. Por esta razón, se recomienda revisar la legalidad de algunas tareas
específicas del test de intrusión, en el área donde se llevará a cabo. Por ejemplo, algunas llamadas
de VoIP capturadas durante el test de intrusión podrían ser consideradas como escuchas telefónicas
en ciertas áreas, y no ser precisamente legales.

Tipos de delitos informáticos reconocidos por la ONU

La Organización de las Naciones Unidas (ONU), a través de su Manual para la prevención
y control de delitos informáticos, Revista Internacional de Política Criminal, Serie M, Núms. 43 y
 46

44 (publicación de las Naciones Unidas, núm. de venta S.94.IV.5), reconoce los siguientes tipos
de delitos informáticos:

1. Fraudes cometidos mediante manipulación de computadoras:

a. Manipulación de los datos de entrada: este tipo de fraude
informático conocido también como sustracción de datos, representa el delito
informático más común ya que es fácil de cometer y difícil de descubrir.
b. La manipulación de programas: consiste en modificar los
programas existentes en el sistema o insertar nuevos programas o rutinas. Es muy
difícil de descubrir y a menudo pasa inadvertida debido a que el delincuente tiene
conocimientos técnicos concretos de informática y programación. Una de las
técnicas utilizadas para realizar este tipo de delito es la ingeniería inversa.
c. Manipulación de los datos de salida: se efectúa fijando un objetivo
al funcionamiento del sistema informático. El ejemplo más común es el fraude del
que se hace objeto a los cajeros automáticos mediante la falsificación de
instrucciones para la computadora en la fase de adquisición de datos.
d. Fraude efectuado por manipulación informática: aprovecha las
repeticiones automáticas de los procesos de cómputo. Es una técnica especializada
que se denomina “técnica del salchichón” en la que “rodajas muy finas”, apenas
perceptibles, de transacciones financieras, se van sacando repetidamente de una
cuenta y se transfieren a otra. Se basa en el principio que 10,66 es igual a 10,65
pasando 0,01 centavos a la cuenta del ladrón N veces.
2. Manipulación de los datos de entrada:
a. Como objeto: cuando se alteran los datos de los documentos
almacenados en forma computarizada.
b. Como instrumento: las computadoras pueden utilizarse también
para efectuar falsificaciones de documentos de uso comercial.
3. Daños o modificaciones de programas o datos computarizados:
a. Sabotaje informático: es el acto de borrar, suprimir o modificar sin
autorización funciones o datos de computadora con intención de obstaculizar el
funcionamiento normal del sistema.
 47

b. Acceso no autorizado a servicios y sistemas informáticos: estos

accesos se pueden realizar por diversos motivos, desde la simple curiosidad hasta
el sabotaje o espionaje informático.
c. Reproducción no autorizada de programas informáticos de
protección legal: esta puede entrañar una pérdida económica sustancial para los
propietarios legítimos. Algunas jurisdicciones han tipificado como delito esta clase
de actividad y la han sometido a sanciones penales. El problema ha alcanzado
dimensiones transnacionales con el tráfico de esas reproducciones no autorizadas a
través de las redes de telecomunicaciones modernas. Al respecto, se considera que
la reproducción no autorizada de programas informáticos no es un delito
informático debido a que el bien jurídico a tutelar es la propiedad intelectual.

Aspectos legales en Guatemala

En Guatemala, actualmente solo lo que es el Código Penal, donde en algunos capítulos se
hace mención a ciertos tipos de delitos, mayormente relacionados con propiedad intelectual o robo
de información.
Código Penal de Guatemala
Específicamente se detalla en el capítulo VII del Código Penal de Guatemala, los siguientes
artículos:
1. Artículo 274: Violación a derechos de autor y derechos conexos.
2. Artículo 274 “A”: Destrucción de registros informáticos.
3. Artículo 274 “B”: Alteración de programas.
4. Artículo 274 “C”: Reproducción de instrucciones o programas de
computación.
5. Artículo 274 “D”: Registros prohibidos.
6. Artículo 274 “E”: Manipulación de información.
7. Artículo 274 “F”: Uso de información.
8. Artículo 274 “G”: Programas destructivos.
9. Artículo 275: Violación a derechos de propiedad industrial.
10. Artículo 276 BIS: Violación a los derechos marcarios.
 48

CERT Guatemala
En 2016, el Ministerio de Gobernación, en conjunto con otras instituciones internacionales,
oficializa el proyecto CERT (Computer Emergency Response Team) el cual tiene como objetivo
poder dotar de profesionales certificados en diferentes áreas de la Seguridad Informática para
incidentes de ciberseguridad que puedan darse en el país.

Inicialmente el CERT dotará de dispositivos tipo sensores a todas las instituciones públicas
y privadas que lo requieran, para monitorear sus principales servicios, enlaces, de ataques y
amenazas en la red. Al igual que la sección de ciberdelitos de la PNC, este proyecto está en fase
inicial y se recomienda estar actualizado con el avance del mismo, de acuerdo con información
publicada en el sitio www.cert.gt.

Sección contra Delitos Informáticos de la PNC

En mayo de 2016, la Policía Nacional Civil anuncia la creación de la sección contra delitos
informáticos, buscando fortalecer las instituciones nacionales, trabajando conjuntamente con la
sociedad civil, academia y sector privado, con el principal objetivo de identificar y castigar a
criminales cibernéticos que participen o promuevan la explotación sexual en línea, y derivados.
Un proyecto financiado por el gobierno británico e implementado por el Fondo de las Naciones
Unidas para la Infancia (UNICEF).

Esta sección, trabaja conjuntamente con la Fiscalía de Delitos Cibernéticos del Ministerio
Público, y en colaboración con el INACIF. Estas entidades cuentan con personal capacitado para
realizar Peritajes Forenses Digitales, mediante los cuales se puede secuestrar el equipo informático
que es encontrado en escenas de crimen (laptops, celulares inteligentes, tabletas, etc.) garantizando
la cadena de custodia para el análisis de la información en los respectivos casos.

4.12 Capacidades de respuesta y herramientas tecnológicas de la organización objetivo

Un test de intrusión óptimo no se basa únicamente en encontrar versiones desactualizadas
de sistemas; también deben evaluarse las capacidades de respuesta a incidentes de la organización.
Algunas de los aspectos que pueden evaluar son:
 49

 Capacidad de detectar y responder a escaneos de recolección de

información.
 Capacidad de detectar y responder a escaneos de análisis de
vulnerabilidades.
 Capacidad de detectar y responder ataques de intrusión.
 Capacidad de detectar y responder a robos de información.

Cuando se evalúan estos aspectos debe recopilarse la información y detalles necesarios.

Por ejemplo, si un escaneo es detectado por el equipo técnico del cliente, el Auditor de Seguridad
debe ser notificado, para determinar si el equipo fue capaz de detectar el tipo y nivel de escaneo
que se realiza.
 CAPÍTULO 5: FASE DE RECONOCIMIENTO
5.1 Introducción
En la fase de reconocimiento, el Auditor de Seguridad realiza la recopilación de toda la
información de su objetivo. Esta fase es una de las más importantes, ya que con los hallazgos que
se realicen, se podrá posteriormente aprovechar alguna vulnerabilidad encontrada, escalar
privilegios, obtener permisos o dar de baja a servicios, entre otras actividades.

Para realizar esta actividad, se tomará como base el documento PENTEST:

RECOLECCIÓN DE INFORMACIÓN, diseñado por el INCIBE (Instituto Nacional de
Ciberseguridad de España S.A) y el CSIRT-CV, ambas, entidades españolas.

5.2 External Footprinting

El external footprinting, es la actividad de reconocimiento externo de la infraestructura
objetivo. Esto quiere decir, que todo análisis sobre una dirección IP, aplicación o sitio web, se hace
desde la internet, de forma externa. Existen 2 tipos de reconocimiento externo: el activo y el pasivo.

5.2.1 Reconocimiento activo

El reconocimiento activo (active footprinting) hace uso de herramientas, o scripts que se
ejecutan desde un dispositivo (del Auditor de Seguridad) directamente hacia la aplicación objetivo.

5.2.1.1 Importancia del Servicio DNS

El servicio DNS, Domain Name System (sistema de nombres de dominio) es un sistema
de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a internet
o a una red privada DNS. Es un servicio esencial para el funcionamiento de las redes de
computadoras. Los sistemas DNS ofrecen gran cantidad de información útil. Este servicio hace
más simple el acceso por parte de usuarios y administradores a los servicios, creando una capa de
abstracción que enmascara las direcciones de red con cadenas de texto, que son más sencillas de
recordar. Además, por regla general, los nombres de los sistemas suelen describir la función que
desempeñan para ayudar a los administradores de sistemas, desarrolladores y usuarios finales a
recordar y acceder a los mismos. La información del protocolo DNS se almacena en registros.

50
 51

El servicio DNS proporciona información fundamental durante la fase de reconocimiento,

gracias a la cual se podrá hacer un primer mapa de la infraestructura de red objetivo.

A continuación, se presentan una serie de herramientas que permiten interrogar a los

servidores DNS para obtener información de éstos registros.

5.2.1.2 Dig
Domain Information Groper, es una herramienta muy flexible para interrogar a los
servidores de DNS. Ejecuta búsquedas del DNS y muestra las respuestas devueltas de los nombres
de los servidores que fueron requeridos. Muchos administradores de DNS utilizan Dig para la
resolución de problemas, debido a su flexibilidad, facilidad de uso, y fácil entendimiento de los
resultados devueltos por esta herramienta. Otras herramientas de interrogación suelen tener menos
funcionalidades que Dig. Es una herramienta por línea de comandos que ofrece las siguientes
opciones y modos de uso:
dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m][-p port#] [-q name]
[-t type] [-x addr] [-y [hmac:]name:key] [-4][-6] [name] [type] [class] [queryopt...]

Para información detallada sobre cada parámetro, teclear: man dig, en la consola de Linux.

Con el siguiente parámetro se obtiene la información de los DNS’s del objetivo.

#dig misitio.gt
 52

Gráfica 11: Uso de la herramienta Dig

5.2.2 Reconocimiento Pasivo

El reconocimiento pasivo consiste en utilizar herramientas que no realizan actividades
directamente sobre el dispositivo o equipo objetivo, con lo cual se logra que cualquier mecanismo
de identificación como IDS, IPS o SIEM no detecte la actividad desde la dirección IP del atacante,
puesto que este se vale de servicios en línea.

Algunas de las herramientas utilizadas pueden ser:

5.2.2.1 Herramienta Whois

Es un servicio gratuito en línea que nos permite obtener la información referente a los
propietarios de un dominio o IP pública específicos. La información que puede encontrarse con
esta herramienta, puede ser utilizada por atacantes para utilizarlas en campañas de Phishing u otras
técnicas de Ingeniería Social.
 53

Gráfica 12: whois.domaintools.com

 54

5.2.2.2 Google Hacking

Google es el motor de búsqueda más grande y más utilizado a nivel mundial hoy en día.
Además de proveer una interfaz simple, limpia pero poderosa y efectiva, es capaz de devolver
resultados de búsqueda de configuraciones específicas, extensiones de archivo y tecnologías, entre
otros datos, referentes a una web específica, mediante la utilización de operadores específicos que
filtran información del motor de este.

De esta forma, es posible poder identificar, por ejemplo, vulnerabilidades o agujeros de

seguridad, módulos de administración de un CMS, archivos de backup de bases de datos, banners
informativos de los servidores web, o bien tipos de archivo específicos almacenados en el host
objetivo.

El proyecto Google Hacking, es creado y liderado por Jhonny Long, un experto en

Seguridad Informática quien en su momento utilizó las herramientas que brinda Google para crear
consultas específicas para encontrar vulnerabilidades en sitios web, y a raíz de esto ha hecho varias
publicaciones que profundizan en este tema.
 55

Gráfica 13: Operadores Google Hacking

Fuente: Google Hacking for Penetrations Testers, Volume 2

5.2.3 Herramienta Maltego

Es una aplicación que combina muchas de las herramientas que pueden utilizarse durante
el reconocimiento activo y pasivo, y que permite al Auditor de Seguridad poder centralizar todos
los resultados en un proyecto. Es extremadamente intuitivo, gráfico y cuenta con versiones tanto
 56

para Windows como Linux, aunque provee dos versiones: gratuita (con ciertas restricciones a nivel
de número máximo de hosts escaneados) y versión de pago que incluye soporte y no posee ninguna
restricción.

Gráfica 14: Interfaz gráfica de Maltego.

5.3 Reconocimiento Interno (footprinting)
Footprinting se denomina a la actividad de poder hacer un reconocimiento específico de
los dispositivos en una red, con su versión y parches aplicados. Con esta información, un atacante
es capaz de visualizar un vector de ataque, utilizando código específico para explotar una
vulnerabilidad previamente identificada.

Una de las herramientas que puede utilizarse es nmap, que es una herramienta muy
poderosa para realizar escaneos de red. Su funcionalidad es bastante extensa y permite hacer
muchos tipos de escaneos diferentes, en incluso ataques. Es una herramienta open source y está
disponible para varias plataformas como Windows y Linux. Es importante hacer notar que, para
ciertos tipos de scans, específicamente aquellos que sean externos, es necesario tomar en
consideración las leyes aplicables en el país de ejecución, puesto que muchas veces los scans de
red TCP que cumplen con el 3-way handshake pueden ser contemplados como un delito; para
solventar esta situación es posible realizar escaneos tipo SYN (Syncronize).
 57

Gráfica 15: Nmap ejecutándose en Kali Linux. Escaneo a un host GNU/Linux

 CAPÍTULO 6: FASE DE ENUMERACIÓN
6.1 Introducción
En el capítulo anterior se discutió respecto a la fase en donde se recopila toda la
información que podría ser utilizada para las siguientes fases. Es una actividad muy útil tanto para
test de intrusión tipo White box como Black box.

Una vez que tenemos todo el universo de información obtenida en la fase anterior –
reconocimiento - es necesario empezar con la siguiente fase denominada enumeración, que está
más relacionada con el análisis de la información que se obtiene, con el objetivo de profundizar
aún más en aquellos posibles dispositivos que podrían brindarnos más información con miras a
obtener un vector de ataque que nos permita materializar un ataque.

El objetivo de esta etapa es la obtención de los datos referente a los usuarios, nombres de
equipos, servicios de red, entre otros. A esta altura de la auditoría, se realizan conexiones activas
con el sistema y se ejecutan consultas dentro del mismo.

Dentro de la información que se obtiene en la fase de enumeración, se puede mencionar:

 Banners informativos de servidores FTP, servidores web, etc.

 FQDNs9 y direcciones IP.
 Configuraciones IP de routers y servidores.
 Información acerca del Directorio Activo.
 Nombres de usuarios
 Nombres de recursos compartidos.
 Etcétera.

9
Fully Qualified Domain Name es un nombre que incluye el nombre de la computadora y el nombre de dominio asociado a ese equipo.

58
 59

Existen muchas herramientas tanto gratuitas como de código abierto que nos permiten
realizar estas tareas, entre ellas se puede mencionar:

 Telnet
 HTTPrint
 SuperScan
 Nmap

6.2 Banners de servidores web

Utilizando la herramienta nmap, y uno de sus scripts, es posible obtener la información del
servidor web utilizado en el host objetivo, mediante el siguiente comando:

nmap -sV --script=banner <host_objetivo>

Gráfica 16: Obtención de banner informativo de Web Server utilizando nmap.

6.3 Banner Informativo de Servidor de correo

Es posible identificar el banner informativo de un servidor de correo mediante el siguiente
comando:

Nmap –sV –p <Puerto_servicio> <host>

 60

Gráfica 17: enumeración de SMTP

6.4 Enumeración de DNS

Es posible hacer enumeración de DNS mediante la herramienta nslookup10

Gráfica 18: enumeración de DNS

Además de nslookup, existen otras herramientas incluidas en Kali Linux, como:

 Dnsmap
 Dnswalk
 Fierce

6.5 Enumeración de SNMP

El protocolo SNMP (Simple Network Management Protocol) es utilizado para monitorizar
el rendimiento de los dispositivos cuya configuración se encuentra habilitada para tales motivos.

10 Herramienta en línea de comandos que es utilizada para hacer consultas a los servidores de nombres de Internet de manera interactiva.
 61

Los dispositivos envían hacia un servidor SNMP (nagios, por ejemplo) toda la información de
rendimiento del dispositivo mediante la autenticación de una cadena de string denominada
“community”; es aquí donde radica la vulnerabilidad, en la configuración por defecto.

Si el protocolo SNMP no es deshabilitado, o en su defecto, su community string no es

modificada, un atacante puede obtener acceso a información sensible sobre el dispositivo
vulnerable, y realizar ataques más sofisticados orientados a las versiones de las tecnologías
soportadas en el dispositivo vulnerable.
 62

Gráfica 19: Enumeración de SNMP en un dispositivo vulnerable

 CAPÍTULO 7: FASE DE MAPEO DE VULNERABILIDADES
7.1 Introducción
En este punto se tiene conocimiento de todo el esquema tecnológico de la infraestructura
de la víctima. Se puede contar con un diagrama de red, hasta el detalle de los servicios y aplicativos
que pueden estar en funcionamiento. Con esta información, es necesario identificar si todas estas
tecnologías poseen vulnerabilidades públicas conocidas, y en base a un análisis de su nivel de
riesgo y potencial éxito, un atacante podría aprovecharse de éstas y lograr comprometer la
seguridad de los sistemas de la víctima.

Básicamente se realiza un Análisis de Vulnerabilidades, el cual puede realizarse de dos

formas, de manera manual y automatizada, utilizando herramientas desarrolladas para este
objetivo.

7.2 Identificación de vulnerabilidades de manera manual

Esta forma de identificar vulnerabilidades, consiste en tomar como base la información
recopilada en la fase de Enumeración, y hacer una búsqueda exhaustiva en internet sobre
vulnerabilidades publicadas para la versión de la plataforma en cuestión.

Para lo anterior, existen sitios web que recopilan la información de todas las
vulnerabilidades reportadas en diferentes herramientas de software y/o plataformas, confirmadas
previamente por el fabricante.

7.2.1 Proyecto CVE MITRE

La Corporación MITRE es una organización no lucrativa que tiene bajo su cargo la
operación de varios proyectos de investigación federal de los Estados Unidos. Provee soluciones
prácticas e innovadoras para la mayoría de los retos de los Estados Americanos, incluidos la
ciberseguridad.

Bajo este esquema, MITRE creó el proyecto CVE (Common Vulnerabilities and
Exposures), que es una plataforma donde se registran las vulnerabilidades reportadas para un gran
número de plataformas, y se les asigna un identificador único, de tal forma que, para cualquier

63
 64

referencia, todos los fabricantes de software trabajan sus parches o actualizaciones de seguridad
basándose en estos identificadores CVE’s.

De acuerdo al sitio web oficial, un identificador CVE consiste en:

 Un nombre para cada vulnerabilidad.
 Una descripción estandarizada para cada vulnerabilidad.
 CVE debe verse como un diccionario, no como una base de datos.
 Es una manera de mantener la interoperabilidad y una mejor cobertura de
seguridad en términos generales.
 Gratuito y de acceso público.

El proceso de crear un identificador CVE inicia con el descubrimiento de una potencial

falla de seguridad. A esta información se le asigna un identificador CVE por medio de una
Autoridad de Numeración CVE y se publica en la lista oficial de los identificadores CVE. A esta
lista oficial están suscritos los principales fabricantes de software, para lograr garantizar la
uniformidad y estandarización de dicho proceso.
 65

Gráfica 20: Búsqueda de identificadores CVE’s.

Fuente: cve.mitre.org

7.3 Identificación de vulnerabilidades con herramientas automatizadas

Existen herramientas que realizan escaneos automatizados de vulnerabilidades. Estas
herramientas funcionan básicamente de la siguiente forma:

 Escaneo de identificación (muchas utilizan la herramienta nmap o

alternativas).
 Asociación entre versiones de los servicios identificados y vulnerabilidades
públicamente conocidas (CVE’s)
 Documentación sobre exploits públicamente conocidos (opcional).
 Informes
 66

Existen dos formas básicas de realizar escaneos:

 Con credenciales: desde el punto de vista de un Administrador de Sistemas,
u Oficial de Seguridad, este tipo de escaneos se pueden realizar en ambientes controlado y
los resultados serán bastante detallados y acertados. Además, implican menos carga en la
red o dispositivos escaneados.
 Sin Credenciales: desde el punto de vista de un atacante, quien puede tener
acceso a este tipo de herramientas y tener conocimiento de vulnerabilidades potencialmente
explotables en su objetivo. Este tipo de escaneos puede no ser tan preciso y obtener falsos
positivos, e implica más carga en la red o dispositivos escaneados.

7.3.1 Herramienta de análisis de vulnerabilidades Nexpose

Nexpose es una herramienta de Análisis de Vulnerabilidades líder en el mercado, ya que
es propiedad de Rapid7, empresa que también es fabricante de una de las soluciones más populares
de explotación: metasploit framework (ver Capítulo 8: Fase de Explotación).

Nexpose provee, además de las características estándar previamente mencionadas, las

siguientes funcionalidades:
 Multiplataforma (Windows/Linux Mac).
 Multi arquitectura (x32, x64).
 Gestión de vulnerabilidades a través de módulo de tickets
 Personalización de funciones de usuarios
 Actualizaciones de vulnerabilidad automáticas y actualizaciones de
vulnerabilidad Microsoft Patch Tuesday.
 Programación y alerta de detecciones
 Cumplimiento de PCI DSS (Payment Card Industry Data Security Standard)
 Integraciones API y de terceros abiertas
 Integración con metasploit framework Pro
 67

Gráfica 21: Nexpose. Resúmen de escaneo.

Gráfica 22: Nexpose. Detalle de Vulnerabilidades.

7.3.2 Herramienta de análisis de vulnerabilidades Nessus

Nessus es propiedad de Tenable, y es ampliamente conocido y utilizado, debido a que en
sus orígenes se distribuía por defecto en la distribución Back Track Linux (antecesor de Kali
 68

Linux). Ofrece compatibilidad con entornos virtualizados y en la nube, análisis y reconocimiento

de Malware y Botnets y soporte para aplicaciones web.

Además, cuenta con una versión en la nube, la cual hace muy sencilla las tareas de
administración y colaboración sobre múltiples motores de escaneo, a través de la utilización de
algo conocido como “agente”, el cual es un componente que se instala en los hosts para escanear.
También provee soporte para cumplimiento PCI DSS.

Gráfica 23: Nessus Vulnerability Scanner

7.3.3 Otras herramientas
Existen muchas otras herramientas en el mercado que vale la pena considerar, como son:

 OpenVAS: es una herramienta de código abierto disponible de manera

gratuita, multiplataforma.
 SAINT: es una herramienta propietaria que integra un framework propio de
explotación.
 69

 Retina: un producto líder en la industria, propietario, ofrece manejo sobre

el control de priorización de amenazas para su remediación. Esto es mejor conocido como
control de parches.
 CAPÍTULO 8: FASE DE EXPLOTACIÓN
8.1 Introducción
La fase de explotación se enfoca específicamente en obtener acceso al sistema objetivo
traspasando las restricciones de seguridad. Si la fase anterior, de análisis y mapeo de
vulnerabilidades se llevó a cabo de manera precisa y adecuada, la fase de explotación deberá
resultar en una actividad bien planificada y con resultados certeros y satisfactorios, desde el punto
de vista de un atacante.

El objetivo principal de esta fase es identificar la ruta de acceso principal en el sistema

objetivo e identificar aquellos activos de mucho valor, desde el punto de vista de la información o
accesos que pueden ser obtenidos como resultado de dicha explotación.

Es de mencionar, que no existe una fórmula secreta o estándar para lograr que una
explotación exitosa sobre un sistema. Pueden utilizarse herramientas automatizadas de
explotación, como lo es Metasploit Framework, hasta un script desarrollado a medida en Python,
Ruby o Bash11 para tener éxito en la explotación.

Inicialmente, lo que un atacante desea realizar es acceder al sistema, con el objetivo de

tomar control de tantos activos como le sea posible, y así lograr comprometer la información
almacenada en éstos, infringiendo la seguridad de los sistemas. Sin embargo, también existen
técnicas de sabotaje, que van desde un ataque de denegación de servicios, hasta una explotación
de tipo Buffer Overflow.

Este tipo de explotación, en el caso de un Auditor de Seguridad de seguridad informática

se deja como último recurso, en caso de no haber podido comprometer los activos de la
organización objetivo, o bien incluir en el reporte dicha vulnerabilidad como “potencialmente
explotable”; y desde el punto de vista de un atacante real, puede llevarlo a cabo en cualquier
momento si en caso su motivación es del tipo sabotaje.

11 Lenguajes de programación. Python y Ruby cuentan con soporte multiplataforma, mientras que bash es nativo para sistemas GN U/Linux.

70
 71

8.2 Metasploit Framework

Metasploit Framework (MSF) es la herramienta de explotación de facto en el mercado. Su
núcleo desde su creación ha sido de Código Abierto, permitiendo que miles de hackers alrededor
del mundo puedan contribuir con su desarrollo, desde documentación hasta desarrollo de nuevos
módulos o exploits.

Posteriormente, el proyecto fue adquirido por la empresa Rapid7, manteniendo el núcleo

Open Source, pero creando una versión “Pro” con funcionalidades que le dotan de valor agregado,
como mayor facilidad de utilización de los exploits, integración con su escáner de vulnerabilidades
Nexpose o una herramienta para campañas de Ingeniería Social a través de Phishing.
MSF está disponible tanto para Windows como para Linux, y es una herramienta instalada
por defecto en Kali Linux y otras distribuciones orientadas a las pruebas de intrusión.

Gráfica 24: Arquitectura de Metasploit Framework

 72

El sistema de archivos de MSF está compuesto de la siguiente forma:

 Data: archivos editables utilizados por MSF.
 Documentation: directorio donde se almacena toda la documentación
relacionada con MSF.
 External: librerías de terceros y código fuente.
 Lib: el núcleo base del framework.
 Modules: los módulos actuales cargados en MSF.
 Plugins: plugins que pueden ser cargados durante el tiempo de ejecución.
 Scripts: meterpreter y otros scripts.
 Tools: utilidades de línea de comando útiles.

MSF funciona a través de la implementación de “Módulos”. Existen básicamente 4 tipos

de módulos que pueden ser utilizados:

 Exploits: es código que aprovecha vulnerabilidades específicas del host

objetivo y que posteriormente utiliza “payloads”.
 Payloads: código que se ejecuta remotamente. Normalmente podemos
encontrar reverse-shells o meterpreter.
 Encoders: Los encoders por otro lado, son herramientas que permiten cifrar
u ofuscar el código de payload, para evitar ser detectados por anti virus o IDS/IPS.
 Auxiliaries (módulos auxiliares): es un exploit que NO hace uso de
payloads. Podemos encontrar auxiliares para hacer reconocimiento de hosts objetivos,
ataques de fuerza bruta, identificación y confirmación de vulnerabilidades específicas, etc.

8.2.1 Herramienta de fuerza bruta para protocolo SSH

Uno de los vectores de ataque con los que se recomienda iniciar por defecto son los ataques
de fuerza bruta. Éstos consisten en realizar intentos de log in con una serie de caracteres
(previamente definidos) en los campos de usuarios y contraseña de un sistema o servicio. Si se
configura adecuadamente los parámetros del ataque de fuerza bruta, podría resultar exitoso. Para
 73

realizar este ataque es posible utilizar Metasploit Framework, ya que cuenta con un módulo
auxiliar para testear logins del protocolo SSH.
A continuación, se detalla paso a paso:

1. Iniciar Metasploit framework, y hacer una búsqueda a través del comando

“SEARCH” del módulo auxiliar que nos permitirá hacer intentos de logins en SSH:

Gráfica 25: Búsqueda de módulo auxiliar en MSF

2. Seleccionar el módulo auxiliar, con el comando “USE”, y posteriormente verificar los

parámetros necesarios, con el parámetro “SHOW OPTIONS”.
 74

Gráfica 26: visualización de opciones de módulo auxiliar MSF

3. Diccionario de palabras: durante la fase de recolección de información pudo obtenerse

mucha información útil para generar un diccionario de palabras específico para el objetivo.
Si se cuenta con un diccionario robusto, es posible hacer ataques de fuerza bruta o
diccionario con diferentes herramientas. A continuación, debe configurarse, mediante el
comando “SET”, las siguientes opciones
a. El archivo que contiene los nombres de usuario,
b. El archivo que contiene las contraseñas
c. Host (víctima)
d. Puerto (víctima, por defecto 22)

Gráfica 27: configuración de opciones de módulo auxiliar MSF

 75

4. Ejecutar el módulo auxiliar con el comando “RUN”.

Gráfica 28: modulo auxiliar de login ssh ejecutándose exitosamente

8.2.2 Herramienta de explotación Samba

Samba es una implementación libre del protocolo de archivos compartidos de Microsoft
Windows (antiguamente llamado SMB, renombrado recientemente a CIFS 12) para sistemas de tipo
UNIX. De esta forma, es posible que computadoras con GNU/Linux, Mac OS X o Unix en general
se vean como servidores o actúen como clientes en redes de Windows. Samba también permite
validar usuarios haciendo de Controlador Principal de Dominio (PDC), como miembro de dominio
e incluso como un dominio Active Directory para redes basadas en Windows; aparte de ser capaz
de servir colas de impresión, directorios compartidos y autentificar con su propio archivo de
usuarios.

A continuación, se mostrará la manera de explotar una vulnerabilidad conocida en

determinadas versiones de samba. El módulo seleccionado para Metasploit Framework, explota
una vulnerabilidad conocida en Samba desde la versión 3.0.20 hasta la 3.0.25rc3, cuando este hace
uso de la opción de configuración “username map script”. Si una atacante especifica, a través de
una cadena de texto, un nombre de usuario que contenga metacaracteres especiales, es posible
llegar a la ejecución remota de comandos. No se requiere autenticación para explotar esta
vulnerabilidad ya que la opción en cuestión es utilizada para el mapeo de nombres de usuario
previo a llevar a cabo el proceso de autenticación. Por lo tanto, esta vulnerabilidad es CRÍTICA.

12
Sistema de archivos de Internet común es un protocolo de red que proporciona la fundación para el uso compartido de archivos basado en
Windows y otras utilidades de red.
 76

Como primer punto, es necesario identificar la versión específica de samba instalada. Esto
puede hacerse, como se detalló en capítulos anteriores, por medio de herramientas como nmap o
Nexpose. Existe una forma más de hacer esta identificación, utilizando módulos auxiliares de
Metasploit Framework.

1. Se hace búsqueda de módulos auxiliares o exploits para samba. En este caso, se puede
utilizar como parámetro de búsqueda “smb_version”

Gráfica 29: modulo auxiliar smb_version

2. Se configura la dirección IP objetivo, en el parámetro RHOSTS y ejecutamos el módulo,
el cual arrojará como resultado la versión (si existe) de samba que se está ejecutando.

Gráfica 30: Ejecución del módulo smb_version

3. Con esta información es posible hacer una búsqueda en la web sobre vulnerabilidades para
esta versión específica de samba.
 77

Gráfica 31: Referencia técnica de vulnerabilidad pública samba

https://www.rapid7.com/db/modules/exploit/multi/samba/usermap_script

Una vez se ha identificado el vector de ataque, y confirmado la existencia de un exploit en

Metasploit Framework, es posible realizar la prueba de explotación:
 78

1. Se realiza una búsqueda del exploit dentro de Metasploit Framework:

Gráfica 32: identificación de exploit usermap_script

2. Se configuran los parámetros solicitados por el exploit.

Gráfica 33: Configuración de parámetros de exploit usermap_script

3. A partir de este momento, es posible ejecutar el exploit, y lograr hacer ejecución

de comandos de manera remota.
 79

Gráfica 34: ejecución exitosa de exploit usermap_script logrando root

8.2.3 FTP Exploit

Existen múltiples herramientas que permiten ejecutar servidores de FTP. Una de ellas es
vsftp, la cual es Open Source y tiene ya algún tiempo en el mercado. En la versión 2.3.4, se dio un
incidente de filtración por parte de atacantes a los servidores del repositorio principal, y lograron
subir una versión modificada de esta herramienta, logrando incrustarle un backdoor, de tal forma
que, todos los servidores que corran esta versión de vsftp, son vulnerables.

La funcionalidad básicamente consiste en realizar una conexión vía telnet sobre el puerto
21, y seguidamente ingresar los caracteres “:)” (carita feliz), y con esto ya se logra acceso al
sistema. Existe un módulo de la herramienta Metasploit Framework que automatiza esta tarea.
 80

1. Como primer punto se realiza la búsqueda del exploit en Metasploit Framework:

Gráfica 35: búsqueda de exploit para vsftp

2. Se configuran los parámetros solicitados por el exploit, como la IP objetivo:

Gráfica 36: configuración de parámetros de exploit vsftp

3. Ejecución exitosa del exploit, obteniendo acceso como root

Gráfica 37: ejecución exitosa de exploit, logrando root.

 81

8.2.4 Herramienta de explotación de servicio Unreal ircd

Unreal ircd es un servidor IRC de Código Abierto implementado en miles de redes desde
1999. Soporta Linux, OSX y Windows y es uno de los servidores más utilizados actualmente. Al
igual que sucedió con vsftp, los servidores de los repositorios de Unreal sufrieron una filtración,
que tuvo como resultado la modificación de su código fuente, pudiendo los atacantes incrustar un
backdoor. De tal forma que todas las implementaciones de la versión 3.2.8.1 son vulnerables.
Como resultado, un atacante puede lograr la ejecución remota de comandos, desde el usuario bajo
el cual está corriendo dicho servicio.

El procedimiento de explotación es exactamente el mismo que se utilizó para vsftp, únicamente

utilizando el exploit específico para Unreal ircd:

Gráfica 38: Ejecución exitosa de exploit para unreal ircd

 82

8.3 Vulnerabilidad Shellshock

Bash
Bash (Bourn Again SHell) es el intérprete de comandos más utilizado en GNU/Linux y
muchos otros sistemas basados en UNIX como Android y Mac OS X. Su tarea consiste en
interpretar los comandos que un usuario ejecuta, iniciando y deteniendo procesos, por ejemplo.
Así es como los administradores de sistemas manejan habitualmente sus servidores, aunque sin
dejar de lado a la siempre cómoda interfaz gráfica a base de ventanas.

Shellshock se denomina a la vulnerabilidad identificada en Bash, como CVE-2014-6271,

o GNU Bash Remote Code Execution Vulnerability, identificada en 2015, expuso miles de
servidores Unix y derivados (GNU/Linux), ya que permite a un atacante ejecutar comandos de
forma remota sin requerir autenticación, así como permite en ciertos escenarios tomar control total
del sistema operativo, acceder a información sensible o llevar a cabo ataques más sofisticados a
partir de esta vulnerabilidad. Esta vulnerabilidad, existe técnicamente en sistemas derivados de
Unix desde hace 25 años, pero fue recientemente que pudo ser identificada y explotada de forma
exitosa.

Aunque la vulnerabilidad es sobre bash propiamente, esta puede ser explotada si se cuenta
con una implementación CGI (Common Gateway Interface), ya que mediante CGI, es posible
interactuar con el intérprete de bash, de forma remota. Como primer paso, es necesario identificar
la existencia de scripts CGI (el cual normalmente utiliza en su backend Python o Perl, pero
también es común encontrar implementaciones en Shell o incluso lenguaje C). Esta identificación,
puede realizarse de varias formas, una de ellas es a través del uso de un HTTP Proxy, como lo es
Burp Proxy.

Gráfica 39: identificación de CGI mediante Burp Proxy

 83

Cuando se hace una llamada a un script CGI, el servidor web (en este caso Apache), inicia
un nuevo proceso y ejecuta el CGI. En este punto, se inicia un proceso de Bash y se ejecuta el
script CGI.

Apache necesita trasladar la información al script CGI; para realizar esto utiliza variables
de entorno. Las variables de entorno están disponibles dentro del script CGI, permitiendo que
Apache traslade de manera sencilla todos los encabezados HTTP (entre otra información) hacia el
CGI. Por ejemplo, si se tiene un encabezado HTTP “adeleon” en la petición, se tendrá una variable
de entorno llamada “HTTP_adeleon” disponible en el script CGI.

Para realizar la explotación, es necesario analizar el código fuente de la página

potencialmente vulnerable.

Gráfica 40: Análisis de código Fuente vulnerabilidad shellshock

Se puede observar un script CGI que ejecuta comandos de sistema y los despliega de vuelta
en el sitio web, de manera que se cumple el esquema para lograr explotar la vulnerabilidad
shellshock.
 84

Gráfica 41: Respuesta de script CGI

A continuación, se puede utilizar la herramienta “repeater” de Burp Proxy, con la cuál es

posible hacer reenvíos modificados de una petición HTTP.

Gráfica 42: Envío de petición hacia la herramienta “Repeater”, Burp Proxy

Y se realiza la modificación en el encabezado HTTP, en este caso en el “User-Agent”.

Gráfica 43: Burp Proxy Repeater, Header Original

 85

Gráfica 44: Burp Proxy Repeater, Header modificado.

Shell Iniversa
A continuación, se muestra una prueba de concepto (PoC), en donde en el sistema víctima
se encuentra la herramienta de red NetCat 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).

Por tanto, en esta prueba de concepto, el sistema víctima contiene el componente de Netcat
“cliente”, y, por otro lado, se tiene un Kali Linux (sistema atacante) ejecutando Netcat en modo
“servidor”, a la escucha de peticiones entrantes. Lo que pretende este ejercicio es demostrar la
manera en que es posible llevar a cabo la ejecución de comandos sin requerir de autenticación.

Gráfica 45: Ejecución de comando remote. Netcat

 86

Gráfica 46: Reverse shell con netcat

8.4 Vulnerabilidad HeartBleed

El bug de Heartbleed es una vulnerabilidad crítica descubierta en el software criptográfico
OpenSSL. Esta debilidad permite, en ciertos escenarios, el robo de información sensible en los
protocolos criptográficos SSL/TLS. Estos protocolos proveen comunicación segura y privada a
través del internet para aplicaciones como la web, correo electrónico, mensajería instantánea y
algunas redes privadas virtuales (VPNs).

Gráfica 47: heartbleed bug

Este bug, descubierto en 2014, permite que cualquier con acceso desde internet obtenga
una lectura de memoria de los sistemas protegidos con versiones – vulnerables – de OpenSSL.
 87

Esto compromete las llaves secretas que son utilizadas para identificar los proveedores del servicio
y para cifrar el tráfico, los nombres y contraseñas de los usuarios y en general el contexto actual.
Esto permite que un atacante pueda filtrarse en las comunicaciones, robar datos directamente de
los servicios o usuarios o falsificar servicios o usuarios.

Heartbleed está identificado como CVE-2014-0160. Además, la razón de su nombre radica

en que la vulnerabilidad existe específicamente en la extensión denominada “heartbleed”
(RFC6520), y cuando se explota permite la obtención de contenido en memoria del servidor hacia
el cliente y viceversa.

¿Cómo identificar servidores públicos vulnerables a heartbleed?

Existen varios portales que ofrecen un servicio gratuito de escaneo para identificación de
esta vulnerabilidad.

Filippo.io, es una herramienta que permite la identificación de esta vulnerabilidad, y valida

la misma mediante el envío y recepción de información almacenada en memoria del servidor web,
como respuesta a una petición de menor tamaño.

Gráfica 48: filippo.io, verificación de servidor web con TLS/SSL Vulnerable

 88

Explotación de Heartbleed
Para explotar esta vulnerabilidad, existen módulos auxiliares de Metasploit Framework
disponibles que permiten de una manera sencilla llevar a cabo esta tarea, específicamente el
módulo auxiliary/scanner/ssl/openssl_heartbleed.
Básicamente los parámetros requeridos son:
 RHOSTS: el servidor web que se desea explotar
 VERBOSE: (set verbose true) para visualizar en pantalla todas las
respuestas obtenidas (information leak).

Gráfica 49: configuración de modulo auxiliar MSF para explotación de Heartbleed

 89

Gráfica 50: Explotación exitosa de Heatbleed. Imagen ½

Gráfica 51: Explotación exitosa de Heartbleed. Imagen 2/2

La información obtenida como resultado de la ejecución del módulo auxiliar de Metasploit
Framework, es información que reside en la memoria del servidor. Cada vez que se ejecute el
módulo auxiliar, se obtendrá diferente información (ya que es información aleatoria almacenada
en la memoria del servidor). Por tanto, para sacarle provecho a esta vulnerabilidad, basta con
automatizar la tarea de ejecución y búsqueda de palabras clave como token, user, password, etc. y
con un poco de suerte es posible obtener la información de la llave de descifrado. Si se logra
obtener esto, es posible descifrar toda la información que viaja desde y hacia el servidor.
 90

8.5 Buffer Overflows

Un buffer Overflow, o desbordamiento de memoria en español, es un bug o error a nivel
de programación, es decir código fuente, que, en determinados escenarios, y bajo ciertas
características, podría dar lugar a un acceso a la memoria utilizada por el programa. Estos defectos
a nivel de programación, pueden ser aprovechados por un atacante para lograr ejecución remota
del código, obtención de información sensible o malfuncionamiento del programa (crash).

Un buffer Overflow puede presentarse cuando un programa o un proceso, escribe datos

más allá de los límites del buffer (espacio de memoria designado para su operación) estipulado en
el programa inicial. Como resultado, se obtiene una sobre escritura de la memoria adyacente a la
del buffer original. Los datos sobre escritos pueden incluir otros buffers, variables y datos del
programa.

Un ejemplo básico de un buffer Overflow puede ejemplificarse escribiendo 10 bytes de

datos dentro de “A”, que tiene únicamente 8 bytes disponibles; en este escenario “B” es modificado
como consecuencia.

Gráfica 52: funcionamiento básico de un Buffer Overflow

8.6 DoS y DDoS

Un Ataque de Denegación de Servicios (Denial of Service), es un ataque a un sistema de
computadoras o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos.
Normalmente provoca la pérdida de la conectividad de la red por el consumo del ancho de banda
de la red de la víctima o sobrecarga de los recursos computacionales del sistema de la víctima.
 91

Un Ataque Distribuido de Denegación de Servicio (Distributed Denial of Service), es un

ataque llevado a cabo desde miles de nodos hacia un mismo objetivo. Los nodos suelen ser
computadoras infectadas con malware para llevar a cabo estas tareas, o bien pueden ser usuarios
inexpertos quienes, de manera voluntaria se sincronizan para realizar este tipo de ataquen con
herramientas específicas, como lo es el caso del grupo hacktivista Anonymous.

Según estadísticas de DDoS Survival Handbook, Radarware (2013), demuestran que el

80% de las empresas está pobremente preparado para contraatacar o mitigar un ataque de
denegación de servicios. Este tipo de ataques, afecta muchas aristas en una empresa, permitiendo
la pérdida multimillonaria en muchos términos: sitios online de banca electrónica fuera de servicio,
sitios de venta fuera de servicio, impacto legal, impacto económico, entre otros.

Gráfica 53: DDoS

8.7 DoS Prueba de Concepto: GoldenEye

GoldenEye es un script desarrollado en Python para realizar pruebas de seguridad
orientadas a un ataque de denegación de servicios. Es una herramienta de ataque HTTP, es decir a
nivel de aplicación. El vector de ataque que utiliza es HTTP Keep Alive + NoCache. El script es
de acceso público ya que se encuentra liberado bajo la licencia GNU General Public License
versión 3 (GPLv3).
 92

Gráfica 54: Parámetros de configuración GoldenEye

Gráfica 55: Ejecución de GoldenEye, Imagen 1/4

Gráfica 56: Ejecución de GoldenEye, Imagen 2/4

 93

Gráfica 57: Ejecución de GoldenEye, monitoreo de tráfico, Imagen 3/4

Gráfica 58: Ejecución de GoldenEye, monitoreo de tráfico, Imagen 4/4

 CAPÍTULO 9: WEB APP PENTESTING CON OWASP
9.1 Introducción
The Open Web Application Security Project (Proyecto Abierto de Seguridad de las
Aplicaciones Web) es una comunidad mundial libre y abierta enfocada en mejorar la seguridad de
las aplicaciones de software. Su misión es hacer la seguridad de las aplicaciones “visible”, para
que las personas y organizaciones puedan tomar decisiones acerca de los riesgos en la seguridad
de sus aplicaciones, de forma correcta.

OWASP Foundation genera contenido a disposición de los profesionales de la seguridad

informática, desde guías de mejores prácticas, hasta herramientas que ayudan a identificar
vulnerabilidades en las aplicaciones web. Uno de éstos proyectos se denomina Guía de Testeo
OWASP, la cual a la fecha se encuentra en la versión 4. Esta guía detalla las mejores prácticas
para identificar y mitigar una serie de vulnerabilidades comunes en las aplicaciones web,
independientemente de la tecnología utilizada (Java, ASP, PHP, etc.), aunque existen apartados
específicos de acuerdo a las características propias de estas tecnologías.

El proyecto en sí, es una guía creada por cientos de personas expertas alrededor del mundo.
Existen muchas formas diferentes de testear la seguridad de las aplicaciones y esta guía encapsula
el consenso de expertos líderes sobre cómo deberían ejecutarse todas las pruebas de seguridad,
adecuada y eficientemente.

9.2 OWASP Top Ten

El OWASP Top Ten, es un proyecto que agrupa los diez riesgos más críticos en
aplicaciones Web. Su más reciente versión es la 2017. Se basa en 8 conjuntos de datos de 7 firmas
especializadas en seguridad de aplicaciones, incluyendo 4 empresas Auditor de Seguridad y 3
proveedores de herramientas. Éstos abarcan más de 500,000 vulnerabilidades a través de cientos
de organizaciones y miles de aplicaciones. Las vulnerabilidades del top 10 son seleccionadas y
priorizadas de acuerdo a estos datos de prevalencia, en combinación con estimaciones
consensuadas de explotación, detección e impacto.

94
 95

El objetivo principal del top 10 es educar a los desarrolladores, diseñadores, arquitectos,

gerentes y organizaciones sobre las consecuencias de las vulnerabilidades de seguridad más
importantes en aplicaciones web. El top 10 provee técnicas basadas sobre cómo protegerse en estas
áreas de alto riesgo, y también provee orientación sobre los pasos a seguir.

El top 10 es el siguiente:
Riesgo Descripción
A1 - Inyección Las fallas de inyección, tales como SQL, OS y LDAP, ocurren cuando datos
no confiables son enviados a un intérprete como parte de un comando o
consulta. Los datos hostiles del atacante pueden engañar al intérprete en
ejecutar comandos no intencionados o acceder a datos no autorizados.
A2 – Pérdida de Las funciones de la aplicación relacionadas a la autenticación y gestión de
autenticación y sesiones son frecuentemente implementadas incorrectamente, permitiendo a
gestión de los atacantes comprometer contraseñas, claves, token de sesiones, o explotar
sesiones otras fallas de implementación para asumir la identidad de otros usuarios.
A3 – Secuencia Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables
de comandos en y los envía al navegador web sin una validación y codificación apropiada.
sitios cruzados XSS permite a los atacantes ejecutar secuencia de comandos en el navegador
(XSS) de la víctima los cuales pueden secuestrar sesiones de usuario, destruir sitios
web, o dirigir al usuario hacia un sitio malicioso.
A4 – Referencia Una referencia directa a objetos ocurre cuando un desarrollador expone una
directa insegura referencia a un objeto de implementación interno, tal como un fichero,
a objetos directorio, o base de datos. Sin un chequeo de control de acceso u otra
protección, los atacantes pueden manipular estas referencias para acceder
datos no autorizados.
A5– Una buena seguridad requiere tener definida e implementada una
Configuración configuración segura para la aplicación, marcos de trabajo, servidor de
de seguridad aplicación, servidor web, base de datos, y plataforma. Todas estas
incorrecta configuraciones deben ser definidas, implementadas y mantenidas ya que por
lo general no son tan seguras por defecto. Esto incluye mantener todo el
 96

software actualizado, incluidas las librerías de código utilizadas por la

aplicación.
A6 – Exposición Muchas aplicaciones web no protegen adecuadamente datos sensibles tales
de datos como números de tarjetas de crédito o credenciales de autenticación. Los
sensibles atacantes pueden robar o modificar tales datos para llevar a cabo fraudes,
robos de identidad u otros delitos. Los datos sensibles requieren de métodos
de protección adicionales tales como el cifrado de datos, así como también
de precauciones especiales en un intercambio de datos con el navegador.
A7 – Ausencia La mayoría de aplicaciones web verifican los derechos de acceso a nivel de
de control de función antes de hacer visible en la misma interfaz de usuario. A pesar de
acceso a esto, las aplicaciones necesitan verificar el control de acceso en el servidor
funciones cuando se accede a cada función. Si las solicitudes de acceso no se verifican,
los atacantes podrán realizar peticiones sin la autorización apropiada.
A8 – Un atacante CSRF obliga al navegador de una víctima autenticada a enviar
Falsificación de una petición HTTP falsificado, incluyendo la sesión del usuario y cualquier
peticiones en otra información de autenticación incluida automáticamente, a una aplicación
sitios cruzados web vulnerable. Esto permite al atacante forzar al navegador de la víctima
(CSRF) para generar pedidos que la aplicación vulnerable piensa son peticiones
legítimas provenientes de la víctima.
A9 – Utilización Algunos componentes tales como librerías, los frameworks y otros módulos
de componentes de software casi siempre funcionan con todos los privilegios. Si se ataca un
con componente vulnerable esto podría facilitar la intrusión en el servidor o una
vulnerabilidades perdida seria de datos. Las aplicaciones que utilicen componentes con
conocidas vulnerabilidades conocidas debilitan las defensas de la aplicación y permiten
ampliar el rango de posibles ataques e impactos.
A10 – Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios
Redirecciones y hacia otras páginas o sitios web, y utilizan datos no confiables para
reenvíos no determinar la página de destino. Sin una validación apropiada, los atacantes
validados pueden dirigir a las victimas hacia sitios de phishing o malware, o utilizar
reenvíos para acceder a páginas no autorizadas.
 97

9.2.1 Cross Site Scripting (XSS)

Gráfica 59: OWASP Top 10, Cross Site Scripting

9.2.1.1 Cross Site Scripting (XSS) Almacenado

El cross site scripting almacenado, puede identificarse y materializarse exactamente de la
misma manera que el XSS reflejado; sin embargo, la diferencia radica en que el código JavaScript
inyectado, es almacenado en base de datos. Esta variante, permite que el ataque sea
significativamente más sencillo y más efectivo para el atacante, puesto que no necesita un vector
de ataque directo hacia su víctima.

En un escenario, donde el sitio web vulnerable posee una sección de noticias, comentarios
o blog, en donde todos los usuarios (registrados o no registrados) pueden visualizar los comentarios
de otros usuarios por ejemplo, un atacante podría hacer inyección de código JavaScript, por
ejemplo, y este, al ser almacenado en la base de datos, y ejecutado de vuelta del lado del cliente
(navegador web) podría hacer un re direccionamiento a un sitio malicioso, logrando que la víctima
pueda, entre otras cosas, ser engañada para proporcionar sus credenciales, robar sesiones a través
de las cookies, o bien infectar la computadora con algún tipo de malware.
 98

Gráfica 60: Funcionamiento de XSS Almacenado

9.2.2 Inyección SQL

Gráfica 61: OWASP Top 10, Inyección

 99

Inyección SQL es una técnica maliciosa en donde un atacante realiza inyección de

consultas SQL (Structured Query Language) a través de parámetros de entrada en un sitio web
dinámico. Esta técnica puede tener un impacto severo ya que en determinados escenarios puede
lograrse, entre otros:

 Extracción de información sensible de la base de datos.

 Modificación de registros en la base de datos.
 Escalamiento de privilegios desde la base de datos hacia el sistema
operativo.
 Cargar archivos maliciosos a nivel de sistema operativo.

Este tipo de vulnerabilidad, es muy popular, debido a que hoy en día, muchas empresas
poseen sitios web dinámicos para cubrir diferentes necesidades, desde dar a conocer sus servicios,
noticias, hasta vender artículos en línea o brindar herramientas a sus colaboradores como
Reportería o acceso web a sus diferentes plataformas operativas. Tomando esto en cuenta, es
bastante llamativo para un atacante el poder identificar y materializar una vulnerabilidad de este
tipo ya que el impacto, de tener éxito su ataque, es crítico.

Para proceder con un ataque de este tipo, es necesario primeramente identificar parámetros
de entrada en una aplicación web. Éstos pueden ser parámetros por ejemplo en un formulario, hasta
parámetros dinámicos enviados vía GET o POST.

Una vez identificados dichos parámetros, se requiere realizar, pruebas y validaciones

manuales para confirmar que un parámetro es vulnerable a este tipo de ataques. Esto se logra
principalmente realizando pruebas de fuzzing, que es una actividad donde se insertan caracteres
aleatorios y específicos con el objetivo de verificar el comportamiento del backend, por ejemplo,
errores genéricos del DBMS (Data Base Management System) u obtener resultados de consultas
directamente ejecutados hacia el backend.
 100

Gráfica 62: Funcionamiento de Inyección SQL

Para poder realizar este tipo de ataques, puede utilizarse las siguientes herramientas:
 HTTP Proxy: es una herramienta que se utiliza para interceptar todas las
peticiones (HTTP Request) desde el cliente, hacia el servidor, permitiendo interceptar y
modificar tanto la petición como la respuesta (HTTP Response). Existen muchas
herramientas de este tipo, aunque en la comunidad hacker se utilizan principalmente:
o OWASP ZAP Proxy: una herramienta open Source, desarrollada en
java (multiplataforma). Posee un interceptor de peticiones, un scanner, y ejecución
de algunos ataques predefinidos de fuzzing como SQL Injection, Cross Site
Scripting y (XSS), entre otros.
o Burp Suite Pro: una herramienta de pago, desarrollada en Java
(multiplataforma) que permite la integración con otras herramientas y asimismo la
expansión de funcionalidades mediante la codificación de plug ins vía código
Python o Java. Al igual que ZAP, incluye un interceptor de peticiones, y
herramientas automatizadas para escaneo de vulnerabilidades web y ejecución de
ataques predefinidos.
 SQL Map: es una herramienta de pentesting open Source que automatiza el
proceso de detección y explotación de vulnerabilidades de tipo SQL Injection sobre
servidores de bases de datos. Incluye una amplia gama de funcionalidades que van desde
detección de la base de datos, hasta extracción de información de las mismas, así como
ejecución de comandos de sistema operativo. Soporta múltiples DBMS entre los que se
 101

puede encontrar: MySQL, Oracle, PostgreSQL, Microsoft SQL Server, IBM DB2, SQLite,
Firebird, Sybase, SAP MaxDB, entre otros.

Identificando parámetros vulnerables

Es necesario identificar parámetros de entrada en la aplicación. Independientemente si
éstos viajan vía GET (no recomendado desde el punto de vista de mejores prácticas de desarrollo
seguro) o POST. Para esto es posible realizar dicha identificación, y captura de peticiones, a través
del proxy HTTP, para lo cual se debe configurar el navegador web para comunicarse con el Proxy
HTTP, y posteriormente este realizará la comunicación hacia el backend.

Gráfica 63: Esquema de funcionamiento Cliente Web, Proxy HTTP y Servidor Web

A continuación, debe realizarse la búsqueda de un formulario en el sitio web, ya que en estas

páginas es seguro poder encontrar parámetros de entrada, como se muestra en la imagen a
continuación:

Gráfica 64: Identificando parámetros de entrada en formulario web

 102

En la imagen anterior, podemos ver cómo el campo de texto, solicita un número para
realizar posteriormente una búsqueda en base de datos, y devolver en pantalla, el registro
correspondiente a ese valor, en este caso, devuelve registros de usuarios. Por tanto, ya se ha
identificado un parámetro de entrada, ahora se debe proceder a realizar pruebas de fuzzing para
identificar si dicho parámetro es susceptible a una Inyección SQL:

Gráfica 65: Pruebas de fuzzing, insertando una comilla simple

Gráfica 66: resultado de fuzzing, insertando una comilla simple

En la imagen anterior, se puede apreciar un error genérico del DBMS; en este caso, un
atacante puede identificar que el DBMS utilizado es MySQL, por lo que, inicialmente, puede
enfocar sus intentos de ataque a esta tecnología específica. Seguidamente puede entenderse que el
error hace referencia a una sintaxis errónea en la consulta SQL, lo cual puede suponer que el
backend está procesando de manera correcta la cadena de texto ingresada en el parámetro de
entrada, en este caso la comilla simple.

Explotando parámetro susceptible a Inyección SQL

Una vez hecho lo anterior, es posible intentar introducir sentencias SQL para analizar el
comportamiento de la aplicación, en caso de obtener registros en la respuesta del backend, se puede
confirmar que el parámetro es susceptible a Inyección SQL:
 103

Gráfica 67: Inyección de sentencia SQL en parámetro de entrada

Gráfica 68: Ejecución exitosa de sentencia SQL

Ataques sofisticados y de mayor impacto: SQLMap

En este momento, se puede utilizar la herramienta de ataques automatizado SQL Injection, ya
que esta permite no solo la identificación automatizada de parámetros vulnerables, sino la
realización de ataques más sofisticados.
 104

Gráfica 69: Ejecución de SQLMap

Gráfica 70: Confirmación de parámetro vulnerable a SQLInjection, SQLMap

 105

Gráfica 71: Dump de la base de datos, crackeo de hashes de usuarios vía SQLMap.

9.2.3 Referencia Insegura a Objetos Directos

Gráfica 72: OWASP Top 10, Referencia Insegura a Objetos Directos

Una referencia insegura a objetos directos ocurre cuando un programador expone una
referencia hacia un objeto interno de la aplicación, tales como un fichero, directorio, registro de
base de datos, o una clave tal como una URL o un parámetro de formulario web. Un atacante
podría manipular este tipo de referencias en la aplicación para acceder a otros objetos sin
autorización, a menos que se apliquen diferentes controles de seguridad tales como:
 106

1. Envío de información cifrada.

2. Aplicación de control de accesos como medida de prevención
3. Correcta validación en el backend (para los casos de registros, por ejemplo).

Considérese el siguiente escenario: existe una aplicación de Banca en Línea, en donde un

atacante tiene acceso legítimo a la misma. El atacante se dispone a realizar una transacción que
conlleva a realizar una transferencia de dinero desde su cuenta (legítima) hacia una cuenta de
terceros, o bien un pago de servicios en línea. El atacante puede interceptar las peticiones (vía Burp
Suite Pro o ZAP Proxy, por ejemplo) y realizar una modificación del número de cuenta del emisor
de la transacción (es decir él mismo), y enviar hacia el servidor, una cuenta ajena a él.

Si la transacción de ejecuta satisfactoriamente, el atacante habrá realizado una transacción

desde una cuenta que NO le pertenece, lo que significa que, el backend no está realizando las
validaciones pertinentes de manera correcta. En este escenario, la vulnerabilidad es un hallazgo
crítico para la entidad financiera, ya que el atacante puede estar incurriendo en varios delitos graves
por temas de robo y fraude, y la imagen de la entidad puede verse grandemente perjudicada por
las quejas posteriores que puede recibir de parte de sus clientes.

9.3 Escáneres de Vulnerabilidades en Aplicaciones Web

En el mercado, existe un gran número de herramientas de identificación de
vulnerabilidades para aplicaciones web.

Es de hacer notar que, desde el punto de vista de un Auditor de Seguridad, estas

herramientas deben ser consideradas herramientas de apoyo, más no un punto de partida para
realizar una Auditoría de Calidad, ya que muchos de los resultados obtenidas de estas herramientas
pueden ser falsos positivos, o bien, pueden omitir ciertas vulnerabilidades a nivel de Lógica de
Negocio que un software no puede realizar, sino más bien se requiere del análisis de un humano.

A continuación, se hace referencia a dos de estas herramientas, que son muy comunes en
la comunidad hacker.
 107

9.3.1 Acunetix
Acunetix es un escáner de vulnerabilidades de aplicaciones web (y servidores web) líder
en el mercado. Se encuentra en el cuadrante mágico de Gartner y será utilizado para verificar
ciertas vulnerabilidades específicas.

Gráfica 73. Cuadrante mágico de Gartner: test de seguridad de aplicaciones

Fuente: www. Gartner.com
 108

Gráfica 74: Acunetix en ejecución

9.3.2 Nikto
Nikto es un escáner de servidores web Open Source que realiza diferentes tipos de análisis
incluyendo más de 6700 vulnerabilidades en diferentes plataformas. Al ser una herramienta open
Source y gratuita y que además está incluida en la suite de pentesting por defecto Kali Linux, es
utilizada por muchos Auditores de Seguridad y también por atacantes tanto en la fase de
enumeración como de explotación.

Dentro de sus principales características se puede encontrar:

 Soporte para SSL (Unix/Windows)
 Soporte completo para HTTP
 Verificación de componentes en versiones obsoletas
 Exportación de resultados a texto plano, XML, HTML o CSV
 Identificación de software instalado vía headers, favicons y archivos
 Autenticación de hosts vía NTLM
 Aplicación de pausa a un escaneo específico
 Compatibilidad con Metasploit para explotaciones avanzadas
 109

Gráfica 75: Nikto en Ejecución

 CAPÍTULO 10: FASE DE POST EXPLOTACIÓN
10.1 Introducción
El proceso de post explotación, se lleva a cabo una vez que se ha ganado acceso al sistema
objetivo. En esta fase se revisa la información obtenida en la fase de Recolección de Información
de los sistemas que fueron vulnerados, escalamiento de privilegios, sistema por sistema.
Posiblemente nos encontremos con acceso a información sensible almacenada en el sistema que
fue vulnerado o bien que tenemos acceso a otros sistemas de la red para obtener acceso a más
datos. Cuando un atacante logra comprometer un servidor, luego procedería a realizar otras
actividades que permitan extraer más información o comprometer más dispositivos.

El objetivo de la fase de post explotación es determinar el valor del dispositivo

comprometido ante un ataque, y principalmente mantener el control y el acceso futuro. El valor
del dispositivo se determina mediante el tipo de información que almacena y la utilidad del
dispositivo vulnerado para la expansión o escalamiento de privilegios en un ataque a la red. Es
común ver en una prueba de intrusión, que esta fase no se lleve a cabo, ya que en muchas ocasiones
los clientes no requieren de validar o confirmar métodos para mantener el acceso, sino más bien
identificar vectores de ataque y materializar una explotación específica con el objetivo de vulnerar
sus dispositivos principales o extraer información.

10.2 Presencia
Una vez que se logra comprometer un dispositivo es necesario identificar qué archivos
pueden ser útiles para expandir el ataque y lograr comprometer más dispositivos dentro de la red.

10.2.1 Archivos
Dentro de los archivos Linux debería intentar ubicar:

110
 111

Archivo Descripción / Importancia

/etc/issue Mensaje o identificación del sistema al momento de hacer login.
Mensaje del día (banner). Puede contener información acerca de los administradores del
/etc/motd sistema.
Listado de nombres de usuario, grupos, directorio home y shell (probablemente sea de
/etc/passwd lectura global). Podría también contener hashes de las contraseñas.
/etc/group Grupos de usuarios
Contiene los servidores DNS del sistema. Es un archivo de lectura global el cúal
normalmente puede no lanzar alertas a nivel de IDS, como puede suceder con el archivo
/etc/resolv.conf /etc/passwd
Lista de todos los hashes de las contraseñas de usuarios (requiere privilegio root).
/etc/shadow Extrañendo ésta información es posible intentar realizar cracking de los hashes.
/home/[USERNAME]/.b
ash_history
~/.bash_history
$USER/.bash_history Histórico del shell (bash) del usuario. Éste archivo puede contener contraseñas y otros
/root/.bash_history comandos o contenido sensible.

Gráfica 76: Archivos Linux, búsqueda de información sensible

10.2.2 Comandos
A continuación, se muestra una lista con los principales comandos, y parámetros, que
puede ayudar a un atacante a recolectar información sensible:

Comando Arributos Descripción

Muestra atributos de los archivos o directorios
ls ls -l [directorio o nombre en
dela ubicación
archivo] especificada
Encuentra archivos que coincidan con el
find /etc -name "texto" nombre.
Encuentra archivos que coincidan con los
find / -perm 777 permisos.
Encuentra archivos que son propiedad del
find find / -user root usuario "root".
Encunetra la ubicación de los archivos en la
locate locate ifconfig base de datos.

Gráfica 77: Comandos Linux para búsqueda

10.3 Persistencia
Es posible intentar ejecutar comandos que ayuden a mantener el control una vez que se ha
logrado materializar una explotación a nivel de bash. El comando setsid ‘comando’ ejecuta un
comando como daemon (servicio).

10.4 Escalamiento de Privilegios

Escalamiento de privilegios es el proceso de lograr tener control total sobre el dispositivo
comprometido y posteriormente otros dispositivos. En una red corporativa (interna), uno de éstos
 112

objetivos principales sería el lograr tener control a nivel de Domain Admin (Active Directory de
Windows) o vía LDAP para entornos Linux. Aunque no existe una regla ni un listado exacto para
proceder con esta actividad, ya que puede variar en cada ambiente, se sabe que el proceso de
recolección de información es clave para determinar el camino a seguir. Básicamente la
metodología para escalar privilegios es:

 Recolección de información
 Procesar la información recopilada
 Explotación
 Repetir el proceso (es muy común realizar varias pruebas y fallar muchas
veces).

10.4.1 Recolección de información

Esta actividad tiene como objetivo, obtener la mayor cantidad de información sensible útil
del sistema comprometido.

Enumeración de Sistema Operativo

La distribución y la versión de kernel Linux utilizado son piezas clave de información que
pueden ser utilizados para identificar un ataque viable para lograr el escalamiento de privilegios.
Comúnmente una versión específica del Kernel Linux o distribución puede ser vulnerable debido
al conocimiento público de exploits específicos.

Determinar distribución Linux y versión

cat /etc./issue
cat /etc/*-release
cat /etc/lsb-release
cat /etc/redhat-release
cat /etc./os-release

Determinar versión de kernel – 32/64 bits

cat /proc/version
 113

uname -a
uname -mrs
rpm -q kernel
dmesg | grep Linux
ls /boot | grep vmlinuz-

Listar variables de Entorno

cat /etc/profile
cat /etc/bashrc
cat ~/.bash_profile
cat ~/.bashrc
cat ~/.bash_logout
env

Identificar si existe una impresora configurada

lpstat -a

Enumeración de aplicaciones y servicios

Identificación de servicios en ejecución
ps aux
ps -ef
top
cat /etc/service

Identificar servicios ejecutándose bajo root

ps aux | grep root
ps -ef | grep root

Identificar aplicaciones instaladas

ls -alh /usr/bin/
ls -alh /sbin/
 114

dpkg -l
rpm -qa
ls -alh /var/cache/apt/archivesO
ls -alh /var/cache/yum/
yum list | grep installed
Solaris: pkginfo
Arch Linux: pacman -Q

Identificar versión de aplicaciones más importantes

gcc -v
mysql --version
java -version
python --version
ruby -v
perl -v

Verificación de configuración Syslog

cat /etc./syslog.conf

Verificación de configuración Web Server

cat /etc./chttp.conf
cat /etc./lighttpd.conf
cat /etc./apache2/apache2.conf
cat /etc/httpd/conf/httpd.conf
cat /opt/lampp/etc/httpd.conf

Verificación de configuración PHP

/etc./php5/apache2/php.ini

Verificación de configuración MySQL

cat /etc./my.conf
 115

Identificar tareas programadas

crontab -l
ls -alh /var/spool/cron
ls -al /etc./ | grep cron
ls -al /etc./cron*
cat /etc./cron*
cat /etc/at.allow
cat /etc/at.deny
cat /etc/cron.allow
cat /etc/cron.deny
cat /etc./crontab
cat /etc./anacrontab
cat /var/spool/cron/crontabs/root

Identificar nombres de usuario y contraseñas en texto plano

grep -i user [filename]
grep -i pass [filename]
grep -C 5 "password" [filename]
find . -name "*.php" -print0 | xargs -0 grep -i -n "var $password"
# Joomla
cat /var/apache2/config.inc
cat /var/lib/mysql/mysql/user.MYD
cat /root/anaconda-ks.cfg

Identificar interfaces de red conectadas y otras redes

/sbin/ifconfig -a
cat /etc/network/interfaces
cat /etc/sysconfig/network

Identificar usuarios conectados y hosts

 116

lsof -nPi
lsof -i :80
grep 80 /etc/services
netstat -antup
netstat -antpx
netstat -tulpn
chkconfig --list
chkconfig --list | grep 3:on
last
w

Identificar direcciones IP o MAC en caché

arp -a
route -n
/sbin/route -nee
ip ro show

Identificar configuraciones de red (DHCP, DNS, Gateway)

cat /etc/resolv.conf
cat /etc/hosts
cat /etc/sysconfig/network
cat /etc/networks
iptables -L
iptables -t nat -L
hostname
dnsdomainname

Realizar sniffing
# tcpdump tcp dst [ip] [port] and tcp dst [ip] [port]
tcpdump tcp dst 192.168.1.7 80 and tcp dst 10.2.2.222 21
 117

Identificar puertos abiertos de conexiones locales

netstat -tupan
Realizar conexión vía túnel
ssh -D 127.0.0.1:9050 -N [username]@[ip]
proxychains ifconfig

Identificar usuario actual y usuarios de sistema

id
who
w
last
cat /etc/passwd | cut -d : -f 1 # List users
grep -v -E "^#" /etc/passwd | awk -F: '$3 == 0 { print $1}' # List of super users
awk -F: '($3 == "0") {print}' /etc/passwd # List of super users

Usuarios sudoers
cat /etc./sudoers

Identificar comandos sudo permitidos al usuario en conexión

sudo -l

Identificación de llaves privadas de acceso

cat ~/.ssh/authorized_keys
cat ~/.ssh/identity.pub
cat ~/.ssh/identity
cat ~/.ssh/id_rsa.pub
cat ~/.ssh/id_rsa
cat ~/.ssh/id_dsa.pub
cat ~/.ssh/id_dsa
cat /etc/ssh/ssh_config
 118

cat /etc/ssh/sshd_config
cat /etc/ssh/ssh_host_dsa_key.pub
cat /etc/ssh/ssh_host_dsa_key
cat /etc/ssh/ssh_host_rsa_key.pub
cat /etc/ssh/ssh_host_rsa_key
cat /etc/ssh/ssh_host_key.pub
cat /etc/ssh/ssh_host_key

Identificar archivos de configuración con permiso de escritura en /etc.

ls -aRl /etc./ | awk '$1 ~ /^.*w.*/' 2>/dev/null # Anyone
ls -aRl /etc/ | awk '$1 ~ /^..w/' 2>/dev/null # Owner
ls -aRl /etc/ | awk '$1 ~ /^.....w/' 2>/dev/null # Group
ls -aRl /etc/ | awk '$1 ~ /w.$/' 2>/dev/null # Other
find /etc/ -readable -type f 2>/dev/null # Anyone
find /etc/ -readable -type f -maxdepth 1 2>/dev/null # Anyone

Identificación de archivos de escritura a todos los usuarios

find / -perm 777

10.4.2 Explotación
A continuación, se lista algunos comandos útiles para identificación de posibles vectores
de ataque, así como de scripts de explotación en Kali Linux. Cabe mencionar que, una vez
identificada la versión y arquitectura del sistema operativo, y tener el código fuente de un exploit,
puede ser necesario compilarlo de manera local para ejecutarlo remotamente; esto puede ser útil
en los entornos donde se tiene dependencia de ciertas librerías y no se cuenta con ellas (en el host
comprometido).

Identificación de código exploit

/pentest/exploits/exploitdb/searchsploit "kernel" |grep -i "root"
cat /pentest/exploits/exploitdb/files.csv |grep -i privile
grep -i X.X /pentest/exploits/exploitdb/files.csv |grep -i local
 119

grep -i application /pentest/exploits/exploitdb/files.csv |grep -i local

Identificación de herramientas útiles para carga de archivos
find / -name wget
find / -name nc*
find / -name netcat*
find / -name tftp*
find / -name ftp

10.5 Revisiones automatizadas – Unix-Privesc

Unix-privesc-checker es un script que puede ser ejecutado en sistemas Unix (Solaris 9+,
HPUX 11, GNU/Linux, FreeBSD 6.2, entre otros). Intenta identificar malas configuraciones que
podrían permitir a un usuario local sin privilegios realizar el escalamiento de éstos, ya sea a otros
usuarios o bien logrando acceso a aplicaciones (como las bases de datos).

Está escrito en Shell script para que pueda ser cargado y ejecutado de forma sencilla (sin
requerir des empaquetamiento y compilación, por ejemplo). Puede ejecutarse ya sea como usuario
normal o con usuario super administrador/root, en cuyo caso proveerá mejores resultados ya que
puede acceder a una mayor cantidad de archivos.

La razón de ser de esta herramienta, es para ser utilizada por Auditores de Seguridad en
sistemas que han logrado comprometer, y también por administradores de sistemas que necesitan
verificar malas configuraciones comunes, pero principalmente fue creada para ser una herramienta
práctica para Hackers Éticos una vez que han ganado acceso al sistema con una cuenta sin
privilegios y necesitan hacer escalamiento de privilegios, ya que existen muchas cosas que un
Hacker Ético revisará o intentará identificar. Esta herramienta agrupa todas esas acciones de una
forma automatizada y sencilla.
 120

Gráfica 78: Ejecución de Unix-privesc-check

10.6 Garantizando el acceso: Backdoors

Un backdoor es un tipo de troyano (malware) que permite el acceso al sistema infectado y
su control remoto. Un atacante puede aprovechar esta herramienta y eliminar o modificar archivos,
ejecutar programas, enviar correos masivamente o instalar otras herramientas maliciosas. En un
test de intrusión, la mayoría de ocasiones esta parte de la intrusión se omite debido a que el cliente
no se muestra interesado en verificar cómo un atacante puede mantener el control, sino más bien
cómo identifica posibles vectores de ataque. Sin embargo el uso de backdoors está incluido como
parte del test de intrusión como tal.
 CAPÍTULO 11: FASE DE DOCUMENTACIÓN
11.1 Introducción
Durante la ejecución de todo el Test de Intrusión es imperativo que el Auditor de Seguridad
guarde todas las evidencias de todas las actividades realizadas. Primeramente, por si se da el caso
que alguno de los dispositivos o servicios auditados se ve perjudicado durante el Test de Intrusión;
de esta manera es posible recapitular paso por paso y realizar un análisis de lo sucedido y confirmar
con hechos y evidencias, para confirmar que todo es parte de una actividad controlada.

Asimismo es importante que se guarde evidencia detallada, paso por paso de cada una de
las actividades que resultaron en un ataque exitoso, ya que esto será mostrado posteriormente al
cliente con el objetivo de demostrar claramente su debilidad (a nivel de desarrollo,
configuraciones de equipos de red, servidores, servicios, etc.), y también para lograr medir el
impacto (Crítico, Alto, Medio o Bajo) del mismo. También servirá como soporte para las
recomendaciones de remediación que deben darse.

La elaboración de informes es tan importante como la ejecución de la parte técnica del test
de intrusión, y por ello es necesario que el Auditor de Sistemas tome en cuenta algunas
consideraciones para la elaboración de los mismos ya que esto se convierte en el producto final al
cliente, tanto personal técnico como altos mandos, quienes normalmente autorizan presupuesto, y
necesitan ver resultados tangibles de los servicios adquiridos. Es importante tener en mente en
todo momento que la información contenida en cada informe es estrictamente confidencial y
propiedad del cliente.

El informe debe estar dividido básicamente en dos partes, para lograr comunicar los
objetivos, métodos y resultados del Test de Intrusión, orientados a varios tipos de audiencia
diferentes.

11.2 Resumen Ejecutivo

Esta sección tiene como objetivo dar a conocer las metas específicas del Test de Intrusión
y el resumen de los hallazgos, a nivel global (sin mucho contenido técnico). El público objetivo
para esta sección son básicamente los altos mandos, y toda aquella persona a cargo de la visión

121
 122

estratégica del programa de seguridad, así como cualquier miembro líder de un área de la
organización que pueda resultar impactada con los hallazgos o vulnerabilidades identificadas. Un
resumen ejecutivo debería incluir las siguientes secciones:

11.2.1 Introducción
Debe explicar al lector el objetivo general del Test de Intrusión. Debe detallar los términos
bajo los cuales se realiza dicho Test, es decir un resumen de los aspectos más importantes de la
fase de Planificación, específicamente la definición del alcance. De igual forma debe hacer énfasis
en los mecanismos utilizados para identificar el nivel de riesgo, contramedidas y objetivos de cada
test para que el lector pueda comprender el detalle posterior de cada resultado.

11.2.2 Descripción de la metodología

En esta sección, debe incluirse la metodología utilizada para realizar el Test de Intrusión.
Asimismo, especificar si se siguen los lineamientos de alguna normativa (ISO, COBIT, OWASP,
etc.) para que el lector pueda comprender a cabalidad la línea bajo la cual se realizaron las
diferentes pruebas. Esto es particularmente importante para que el Cliente pueda comprender
cuándo está recibiendo resultados de un Análisis de Vulnerabilidades y cuando está recibiendo
resultados de un Test de Intrusión.

11.2.3 Escala de Riesgo

Para cada hallazgo identificado es necesario asignarle una ponderación o escala de riesgo.
Esta escala puede variar, pero es responsabilidad del Auditor de Seguridad comprender a cabalidad
el entorno donde se realiza el test de intrusión, la lógica del negocio y en base a esto etiquetar cada
hallazgo. Como referencia, es posible utilizar la calculadora de CVSS (Common Vulnerability
Scored System), que es la herramienta utilizada por todos los fabricantes o investigadores de
seguridad, que descubren una vulnerabilidad de algún producto particular.
 123

En consecuencia, debe tenerse una tabla de ponderaciones como la siguiente:

CRITICO Este nivel es el más alto y crítico. Implica pérdidas financieras, legales y de
10 imagen catastróficas.
ALTO En este nivel, se encuentran los hallazgos ALTOS que podrían significar una
7-9 potencial perdida financiera, legal o de imagen.
MEDIO En este nivel, se encuentran los hallazgos que podrían significar una potencial
4-6 pérdida financiera o de imagen limitada.
BAJO En este nivel, se encuentran los hallazgos que no representan ningún impacto
1-3 negativo. Pueden considerarse como informativo o mejor práctica.

11.2.4 Resumen Global de Hallazgos

Esta sección provee una sinopsis general de los hallazgos identificados durante la ejecución
del Test de Intrusión, en un formato estadístico básico. En esta sección se incluyen
representaciones gráficas de los dispositivos testeados, resultados obtenidos, procedimientos,
escenarios de ataque y algunas otras métricas consideradas e incluidas en la fase de Planificación.
 124

Gráfica 79: Gráfica de Pie, Resumen Global de Hallazgos

11.2.5 Resumen de principales acciones recomendadas

Esta sección debe proveer al lector de manera concreta, directa y sencilla, las actividades
necesarias que deben llevarse a cabo para mitigar cada uno de los hallazgos identificados. De ser
posible, debe incluir tiempos estimados y detalle de determinados productos o servicios que
podrían adquirirse de manera adicional para correcta mitigación del hallazgo. Pueden agruparse
como actividades de corto, mediano y largo plazo, para poder dar una idea a los altos mandos, de
un punto de partida para el plan de trabajo que les puede esperar.

Actividades d 1 a 3 Meses
1 Credenciales por defecto
1.1 Se recomienda la verificación y cambio de credenciales por defecto de todos los dispositivos vulnerados.
Se recomienda el diseño e implementación de una política de contraseñas, la cuál debe incluir: cambio de contraseñas cada 6 meses, longitud mínima de 8
1.2 caracteres, utilización de cadena alfanumérica y con caracteres ascii, entre otros aspectos.
2 Servicio ejecutándose como root
2.1 Se recomienda la creación de un usuario específico para cada aplicación, y configurar únicamente los accesos y permisos necesarios para dicha aplicación.
3 Certificado Vencido
3.1 Se recomienda la renovación de todos los certificados vencidos identificados.
Actividades de 3 a 6 Meses
1 Utilización de cifrado débil
Se recomienda la utilización de TLS en versión 1.2. Para aquellos casos donde esto no sea posible, se recomienda deshabilitar las suites de cifrado débiles (ver
1.1 detalle técnico).
2 Falta de Hardening a nivel de aplicación
Se recomienda reportar el hallazgo con el fabricante. Debido a que se tiene conocimiento que la configuración del dispositivo es complicada, y se encuentran
diferentes nodos en varios países, es necesario realizar un análisis de factibilidad y plan de trabajo de la implementación del hardneing, para no afectar las
2.1 operaciones del negocio.
Actividades de 1 Año
1 Implementación de una política de Desarrollo Seguro
Crear un comité multidisciplinario para iniciar las sesiones de análisis para la implementación de una política de desarrollo seguro. Ésta debe contemplar
análisis desde las fases tempranas de desarrollo, a nivel de análisis de código estático, pasando por políticas de cifrado seguro y tests de intrución en el
1.1 ambiente de pre-producción.

Gráfica 80: Ejemplo de principales acciones recomendadas, basadas en tiempos de ejecución

11.3 Detalle Técnico

Esta sección es la que será de principal interés para el personal técnico de la organización,
quienes podrán entender a cabalidad cómo fue realizada cada fase del test de intrusión y cómo
pudieron explotarse las vulnerabilidades encontradas. Asimismo deberá hacerse una presentación
de las técnicas utilizadas, de preferencia presencial y con demostración “en caliente”.

Detalla las vulnerabilidades encontradas, cómo pueden ser explotadas, qué impacto
podrían tener para el negocio, y las recomendaciones que pueden seguir para anular el impacto. El
informe técnico extiende al informe ejecutivo, y consta de las siguientes partes:
 125

11.3.1 Inconvenientes de seguridad

Los inconvenientes de seguridad encontrados durante el test de intrusión deberán ser claros
y detallados, para cada método de ataque utilizado se deberá mencionar la lista de recursos
afectados, sus implicaciones, solicitudes originales y datos de respuesta, datos de envío y respuesta
de ataques simulados, proveer referencias a recursos externos para que el equipo técnico de la
organización pueda remediarlo, y proveer recomendaciones profesionales para arreglar las
vulnerabilidades encontradas en los sistemas objetivo.

11.3.2 Descripción de vulnerabilidades

Provee una lista de las vulnerabilidades encontradas en los sistemas objetivos, cada uno
deberá tener fácilmente su asociación al recurso identificado, por ejemplo, la dirección IP y el
nombre del objetivo.

11.3.3 Descripción de exploits

Provee una lista de exploits verificados y chequeados que funcionaron contra el sistema
objetivo. Es importante mencionar si el exploit es de uso público o privado. Puede ser útil también
proveer el código fuente del exploit y mencionar por cuánto tiempo estará disponible.

Para todo lo anterior, debe incluirse capturas de pantalla, capturas de red, y cualquier
evidencia digital que se posea que confirme la manera en que el Auditor de Seguridad materializó
el ataque.

11.3.4 Recomendaciones
Se hace énfasis en un mejor diseño, implementación y procedimientos de seguridad técnica
y operativa para mitigar la vulnerabilidad de los sistemas comprometidos. Debe incluirse URL’s
de referencia al fabricante, checklists o benchmarks de mejores prácticas; recursos que sean de
utilidad para que el cliente tenga herramientas para realizar la mitigación con el menor impacto
posible.
 126

11.4 Dradis framework

Dradis es un framework de código abierto que permite compartir información de manera
efectiva, especialmente durante procesos de evaluación de seguridad. Es una aplicación web que
provee un repositorio centralizado de información que permite llevar el control de qué se ha hecho
hasta un momento determinado, y qué está pendiente todavía por hacer. Dentro de sus
características se incluyen:
 Fácil generación de informes
 Soporte para documentos adjuntos
 Integración con sistemas y herramientas ya existentes, a través de plugins:
o Nessus
o Metasploit
o Nikto
o Nmap
o VulnDB
o Retina Newtork Security Scanner
o Zed Attack Proxy
o Otros…

Dradis Framework puede ser utilizado para el control y automatización de recolección de

información durante toda la ejecución del test de intrusión, y es útil como herramienta de soporte
para la elaboración del informe final.
 127

Gráfica 81. Dradis Framework

 CAPÍTULO 12: APLICACIÓN EN ENTORNO REAL
12.1 Introducción
Para la puesta en práctica de la investigación se ha seleccionado una corporación
guatemalteca con más de 12 años de existencia, cuyo giro de negocio principal es la venta al detalle
de ropa usada. Actualmente cuenta con más de 60 tiendas en todo el país, además de presencia en
Estados Unidos y Honduras.

La infraestructura cuenta con soluciones híbridas tanto en GNU/Linux como soluciones

propietarias (Microsoft, HP, Cisco, etcétera), y nunca ha llevado a cabo un test de intrusión o un
análisis de vulnerabilidades. Además cuenta con mucho prestigio a nivel de imagen institucional,
por lo cual la ejecución de un Test de Intrusión, por un Auditor de Seguridad externo es bien
recibida.

Sus oficinas centrales y centro de distribución principal se encuentran en Escuintla, donde

reside también su Data Center. Teniendo una red de área local de 250 usuarios y un ambiente de
servidores de 25 virtuales (GNU/Linux y Windows), además de otras soluciones de
telecomunicaciones, entre las que cabe mencionar un core Switch HP, solución telefónica Avaya
(voIP). Dentro de las soluciones de Código Abierto incluidas dentro del alcance se puede
mencionar:

 Servidor DNS Bind

 Firewall IPTables
 Solución de telefonía IP Avaya (Red Hat Enterprise Linux y CentOS)
 Servidores Web Apache Tomcat
 Servidores Fedora Enterprise
 Aplicaciones Web con tecnologías Java Enterprise, NodeJS
 Bases de datos Postgres y MySQL
 Servidor de Reportería JasperReports

128
 129

12.2 Alcance
Se han definido dentro del alcance, los siguientes sistemas e infraestructura:

Auditoría Interna
 Red Interna: 10.0.0.0/8. Para un estimado de 250 usuarios y un ambiente
de servidores estimados de 10 GNU/Linux y 10 MS Windows.

Auditoría Externa
 Tienda en Línea: la cual permite la compra de artículos usados y pago
mediante tarjeta de crédito, debido y depósito bancario, y entrega a todo el país.
 Sistema de Compras y Pago a Proveedores: el cuál permite la correcta
gestión de cotizaciones, compra, adquisición y pago a los más de 500 proveedores que
trabajan de forma directa con la corporación.

12.3 Propuesta económica

Item No horas Costo Total

Test de intrusión Interno (10
VLAN's, 5 Servidores) 150 Q100.00 Q15,000.00
Test de intrusión externo (15
IP's públicas) 150 Q100.00 Q15,000.00
Campaña de Phishing 30 Q100.00 Q3,000.00
Test de intrusión WebApps (5) 240 Q100.00 Q24,000.00
570 Q57,000.00
IVA Q6,840.00
Total Q63,840.00
 130

12.4 Resumen de Hallazgos

A continuación se muestra un resumen gráfico de los principales hallazgos encontrados,
siendo éstos divididos en:
 Auditoría Interna: donde básicamente se hace un análisis de
vulnerabilidades y explotación sobre la infraestructura interna de la corporación.
 Auditoría Externa: donde se realizan pruebas de seguridad sobre las
aplicaciones web que están públicas, y para la cual se toma como base el OWASP Top 10.
 131

Para un total de: 13 Vulnerabilidades identificadas.

 132

Para un total de: 8 vulnerabilidades identificadas.

 133

12.5 Detalle de Hallazgos

12.5.1 Infraestructura Tecnológica: Interna y Externa
NO. 001

HALLAZGO Carpetas Inseguras

NIVEL DE
CRITICO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Es posible acceder a carpetas del sistema, y obtener información sensible. Además, se tienen
permisos de escritura, lo cuál permite poder dejar archivos de cualquier tipo, pudiendo ser
malware. En este caso particular se encontró código fuente y se pudo obtener la URL de un
WS, y obtener acceso a los métodos. Además, se encontró archivo de configuración con
CREDENCIALES EN TEXTO PLANO, obteniendo acceso a la base de datos de SAP. Esta es
información que puede ser utilizada para fraude.
 134

Acceso a carpetas compartidas y archive de configuración con credenciales a SQL SAP.

Conexión a SQL Server

Acceso a SAP Business One

RECOMENDACIÓN DE MEJORA
 135

Se recomienda des habilitación de carpetas compartidas con acceso sin credenciales, y controlar
estos accesos vía Active Directory.
 136

NO. 002

HALLAZGO Configuración por defecto

NIVEL DE
CRITICO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
107.x.x.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó que el servidor Web (tienda en línea) es susceptible a ataques de denegación de

servicio tipo Slow HTTP, por lo que se procedió a materializar dicho ataque, y en efecto el sitio
web estuvo de baja mientras se realizaba el ataque. El ataque fue realizado utilizando
únicamente 1 host (computadora).

Ejecución de Ataque de Denegación de Servicio. Imagen 1/2

 137

Ejecución de Ataque de Denegación de Servicio. Imagen 2/2.

RECOMENDACIÓN DE MEJORA

Se recomienda tunear el servidor apache de acuerdo a las recomendaciones del fabricante.

Además, se recomienda la implementación de una solución de protección en la nube (Web
Application Firewall).
 138

NO. 003

HALLAZGO Falta de Configuración VoIP

NIVEL DE
CRITICO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
Red de Voz
AFECTADOS

DESCRIPCIÓN DETALLADA

Fue posible hacer captura de llamadas de voz, desde un punto de datos, mediante la técnica
ARP Poisoning, (envenenamiento ARP) pudiendo identificar nombres de usuarios del sistema
de compras; posteriormente, mediante un ataque de diccionario se logró acceder a algunas de
estas cuentas.

Captura de llamadas VoIP

Datos obtenidos de los audios:

 Dos nombres de usuario de proveedor (utilizado posteriormente en sistema de
compras).
 Un nombre de usuario de dominio.
 139

 Un NIT de colaboradora.

Búsqueda de NIT de proveedor en Google

Acceso a sistema de compras, ataque de diccionario (contraseña débil)

 140

Acceso a sistema de compras, ataque de diccionario (contraseña débil)

Verificación de NIT de colaboradora, en sistema SAT.

RECOMENDACIÓN DE MEJORA

Se recomienda la implementación del protocolo SIP Seguro y un tuneo a nivel de ACL's en las
VLAN's de la red.
 141

NO. 004

HALLAZGO Configuraciones por Defecto

NIVEL DE
ALTO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Es posible obtener acceso a la red mediante DHCP por medio de la conexión física del equipo
a un punto de datos. Esto puede permitir a un atacante conectar cualquier dispositivo a la red y
obtener acceso inicial que le podría permitir hacer fuga de información o un ataque más
sofisticado.

Asignación de IP a través de DHCP

RECOMENDACIÓN DE MEJORA

Se recomienda deshabilitar el DHCP por defecto, y/o implementar soluciones de NAC con
validación de Active Directory, Versión de sistema operativo, parches, antivirus, etcétera,
para evitar que un atacante pueda conectar cualquier dispositivo en la red.
 142

NO. 005

HALLAZGO Carpetas Inseguras

NIVEL DE
ALTO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Es posible acceder a carpetas del sistema, y obtener información sensible, Esta es información
que puede ser utilizada para fraude. Además, se tienen permisos de escritura, lo cual permite
poder dejar archivos de cualquier tipo, pudiendo ser malware.

Acceso a carpeta compartida con permiso de escritura, información sensible

RECOMENDACIÓN DE MEJORA

Se recomienda des habilitación de carpetas compartidas con acceso sin credenciales, y

controlar estos accesos vía Active Directory.
 143

NO. 006

HALLAZGO Contraseña Insegura

NIVEL DE
ALTO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Credenciales de autenticación de proxy débiles, es posible obtenerlas mediante ataque de

fuerza bruta personalizado.

Acceso a Internet

RECOMENDACIÓN DE MEJORA

Se recomienda la implementación de una política de contraseña segura, que contemple, entre

otras cosas, cambio de contraseña cada 6 meses, longitud mayor a 8 caracteres, alfanumérica,
etcétera.
 144

NO. 007

HALLAZGO Carpetas Inseguras

NIVEL DE
MEDIO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Es posible acceder a carpetas del sistema, y obtener información sensible, Esta es información
que puede ser utilizada para fraude. Además, se tienen permisos de escritura, lo cual permite
poder dejar archivos de cualquier tipo, pudiendo ser malware. Se obtuvo archivo de
configuración con URL de un Web Service local.

Acceso a información sensible

Es posible acceder a carpetas del sistema, y obtener información sensible, Esta es información
que puede ser utilizada para fraude. Además, se tienen permisos de escritura, lo cual permite
 145

poder dejar archivos de cualquier tipo, pudiendo ser malware. En este caso particular se
identificó un archivo de configuración con posibles credenciales sensibles (POS Visa)

Acceso a información sensible

RECOMENDACIÓN DE MEJORA

Se recomienda des habilitación de carpetas compartidas con acceso sin credenciales, y

controlar estos accesos vía Active Directory.
 146

NO. 008

HALLAZGO Configuraciones por defecto

NIVEL DE
MEDIO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó servicio MRTG accesible, lo cual permite conocer información sensible sobre la
red.

Acceso a consola MRGT

RECOMENDACIÓN DE MEJORA

Se recomienda restringir el acceso a esta herramienta, mediante credenciales.

 147

NO. 009

HALLAZGO Configuraciones por defecto

NIVEL DE
MEDIO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
10.10.6.x
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó community string por defecto en dispositivos de red, permitiendo poder obtener
información sobre el sistema.

Acceso a protocolo SNMP de dispositivo X.

 148

Acceso a protocolo SNMP de dispositivo X.

RECOMENDACIÓN DE MEJORA

Se recomienda cambiar el community string por defecto de todos los dispositivos con
protocolo SNMP habilitado.
 149

NO. 010

HALLAZGO Falta de Actualizaciones

NIVEL DE
MEDIO
RIESGO

REFERENCIA CVE-2015-0209, CVE-2015-1791, CVE-2015-0286, CVE-2015-0287,

CVE CVE-2015-0288, CVE-2015-0289

ACTIVOS
Sitio principal corporativo
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó servicio con versión desactualizada de OpenSSL, el cual contiene múltiples

vulnerabilidades conocidas, además de proveer suites de cifrado débiles u obsoletas.

Versión desactualizada OpenSSL

 150

Suites de Cifrado obsoleto

RECOMENDACIÓN DE MEJORA

Se recomienda actualizar a la última versión de OpenSSL para parchar las vulnerabilidades

existentes.
 151

12.5.2 Aplicaciones Web: Externa

NO. 001

HALLAZGO Exposición de Datos Sensibles

NIVEL DE
CRÍTICO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
Tienda en Línea
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó que es posible extraer información de todos los usuarios del sistema sin requerir
autenticación, esto incluye nombre, dirección, email, número de teléfono, NIT, entre otros.

Extracción de Información sensible de clientes 1/3

 152

Extracción de Información sensible de clientes 2/3

Extracción de Información sensible de clientes 3/3

RECOMENDACIÓN DE MEJORA
 153

Se recomienda utilizar validación en el API ya sea con un API Key o a través de la cookie de
sesión.
 154

NO. 002

HALLAZGO Contraseña Insegura

NIVEL DE
CRITICO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
Sistema de Compras
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó que los usuarios tienen una contraseña por defecto débil, la cual es susceptible a
ataques de diccionario, con lo cual fue posible comprometer al menos 2 cuentas. Además, no
se cuenta con una política de contraseña segura.

Contraseña Insegura
 155

Acceso a Sistema de Compras

RECOMENDACIÓN DE MEJORA

Se recomienda generar nuevos usuarios con contraseña aleatoria y confirmación vía correo
electrónico. Asimismo, se recomienda la implementación de una política de contraseña, la cual
incluya, entre otros aspectos: cambio automático de contraseña, longitud mínima y máxima,
uso de caracteres alfanuméricos.
 156

NO. 003

HALLAZGO Incorrecta Autenticación y Gestión de Sesiones

NIVEL DE
ALTO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
Tienda en Línea
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó que no se está cerrando la sesión en el backend, y esto permite que se puedan hacer
peticiones y obtener respuestas válidas.

Obtención de registros, sesión finalizada en cliente (no backend).

 157

Obtención de registros, sesión finalizada en cliente (no backend).

RECOMENDACIÓN DE MEJORA

Se recomienda realizar cierre de sesión en el backend en el momento en que le usuario realiza

la operación cerrar sesión.
 158

NO. 004

HALLAZGO Referencias Inseguras a Objetos Directos

NIVEL DE
ALTO
RIESGO

REFERENCIA
N/A
CVE

ACTIVOS
Tienda en Línea, Sistema de Compras
AFECTADOS

DESCRIPCIÓN DETALLADA

Se identificó que, en la aplicación de tienda en línea, es posible visualizar los pedidos de otros
usuarios. Con esta información un atacante podría realizar fraude.

Modificación de parámetros vía POST

En el sistema de compras, se identificó que es posible visualizar registros de otros

proveedores, entre éstos:
 Órdenes de Pago
 Ordenes de Servicio
 Bitácora de Ordenes de Servicio
Con esta información un atacante podría realizar fraude.
 159

Modificación de parámetros vía POST

Visualización de Orden de Pago de otro proveedor

 160

Visualización de orden de servicio de otro proveedor.

Visualización de bitácora de servicio de otro proveedor

RECOMENDACIÓN DE MEJORA

Para la tienda en línea, se recomienda hacer validación en el backend de los Id’s de pedidos con
la cookie de sesión.
 161

12.6 Conclusiones del Informe

El test de Intrusión Interno se realizó por parte del Auditor de Seguridad, simulando ser un
usuario “proveedor”, quien normalmente tiene acceso a una computadora para usos varios (uso del
sistema de compras, impresión de documentos, etcétera), dentro de la organización. Como primer
punto se identificó que la red de área local provee IP’s por defecto mediante DHCP, y no realiza
ninguna validación de conexión a la red (vía Active Directory, RADIUS, etcétera).

Debido a esta mala práctica fue posible conectar un dispositivo (Laptop con Kali Linux
para intrusión) con acceso a la red. Asimismo se identificó la implementación de diferentes
VLAN’s, sin embargo no se encuentra correctamente configurado los ACL’s de las mismas, por
lo que fue posible acceder a VLAN’s de otros segmentos.

Luego del análisis a los segmentos de servidores, en la red interna, se concluyó que, en
términos generales, los administradores de sistemas realizan de forma correcta las
implementaciones de nuevos servicios, enfocándose específicamente en:
 Cambio de configuraciones por defecto (credenciales, archivos de ejemplo,
etcétera).
 Actualizaciones de los aplicativos (servicios, etcétera).

En cuanto a los análisis externos (direcciones IP externas) únicamente se identificó un

hallazgo relacionado con falta de actualizaciones del servicio de certificados de seguridad
(OpenSSL).

En cuanto al servicio de telefonía IP, se determinó que, sí se cuenta con una VLAN
específica para el servicio de voz sobre IP, de tal forma que esta no esté en un mismo segmento
(VLAN) de datos. Sin embargo fue posible interceptar llamadas desde un punto de red de datos,
mediante la aplicación de la técnica “Envenenamiento ARP”, con lo cual se confirma que es
necesario realizar un correcto tuneo sobre este servicio.

Dentro del análisis de la red local, específicamente los dispositivos de los usuarios, se
identificó que existen carpetas compartidas sin ningún tipo de restricción de acceso y verificación
 162

de autorización. Esto debido a que los usuarios encuentran este tipo de métodos útiles para
compartir información entre colaboradores de la organización. Sin embargo esto no es una buena
práctica, ya que fue posible extraer información sensible.

Dentro del análisis de las aplicaciones Web no se identificó una vulnerabilidad que
permitiese tomar el control de algún servidor o escalamiento de privilegios, pero se encontraron
múltiples fallas a nivel de lógica de negocio.

En el sistema de tienda en línea, se logró extraer toda la información de los usuarios del
sistema incluyendo nombre, apellido, dirección, teléfono, email, NIT, etcétera. Asimismo fue
posible visualizar registros de otros usuarios, tales como los pedidos realizados.

En el sistema de compras se logró burlar la lógica de la aplicación y poder visualizar

registros de otros proveedores como ordenes de servicio, órdenes de compra, contraseñas de pago.

Se concluye que a nivel de aplicaciones web en términos generales, se identifica una

debilidad en el entendimiento por parte del equipo de desarrollo, por la correcta validación de
parámetros en el backend de sus aplicaciones.
 163

12.7 Recomendaciones del Informe

Se recomienda realizar un correcto tuneo de la red de área local, en cuanto a deshabilitar
el DHCP por defecto, e implementar una solución que permita el control de accesos (NAC),
validando aspectos como Active Directory, versión de sistema operativo, Antivirus actualizado,
etcétera. De esta forma se logra controlar los accesos de dispositivos no autorizados a la red.

Asimismo, se recomienda continuar con las buenas prácticas, y política de actualización

de los activos más críticos, como pueden serlo los servidores de producción y sus aplicativos.

Para la red de voz, se recomienda la implementación del protocolo SIP Seguro, y realizar
tuneo de ACL's en las VLAN's, para garantizar que el tráfico no puede ser interceptado; y en caso
que lo fuere, un atacante interceptaría tráfico cifrado.

Se recomienda también realizar una correcta implementación de carpetas compartidas,

mediante la autorización vía Active Directory u otra solución LDAP. Esto reducirá en gran parte,
la posibilidad que un atacante pueda extraer información sensible de algún dispositivo dentro de
la organización.

Como recomendación principal para el equipo de desarrollo se recomiendan capacitaciones

regulares sobre metodologías y técnicas de Desarrollo Seguro. Asimismo se sugiere puedan tomar
como referencia la documentación del proyecto OWASP, la cual incluye múltiples fuentes de
recursos de libre acceso para fomentar las buenas prácticas de desarrollo seguro.

Se recomienda la ejecución de al menos una intrusión interna y externa anual, por parte de
un profesional externo para validar las mitigaciones y asegurarse que se cumple con las mejores
prácticas recomendadas, así como la identificación de nuevas vulnerabilidades. De esta forma
lograr reducir el riesgo de fuga de información o intrusiones no autorizadas que resulten en activos
comprometidos.
 CONCLUSIONES

1. Mediante la selección de las metodologías de Intrusión PTES, OSSTMM y

OWASP, es posible plantear fases específicas para ejecutar en un entorno seguro
un Test de Intrusión orientado a tecnologías GNU/Linux. Además se hace necesario
recalcar que estas metodologías pueden ser utilizadas en ambientes híbridos donde
se encuentren múltiples tecnologías y tipos de dispositivos. Por tanto las
tecnologías GNU/Linux, así como web de código abierto, pueden ser atacadas
como cualquier otra tecnología propietaria.

2. Durante un Test de Intrusión es importante realizar el recabado de evidencias de

toda vulnerabilidad identificada y materializada, debido a que debe documentarse
de manera oportuna para la presentación final con los encargados de la
organización.

3. La transferencia de conocimiento hacia el personal técnico de la organización es

de vital importancia ya que en términos generales existe una deficiencia a nivel de
concientización de Seguridad Informática en la población de profesionales de
Tecnologías de Información, y esto se comprueba a través del estudio Hacking the
Skills Shortage: A study of the international shortage in cybersecurity skills,
McAfee, (2016), en donde recalcan que a nivel global, existe un déficit de
profesionales en el área de Cyberseguridad de 82%.

4. Se concluye asimismo que fue posible evaluar el riesgo de la infraestructura en una

empresa Guatemalteca bajo una línea de Hacking Ético, a través de la adecuada
selección de técnicas y metodologías de Intrusión como PTES, OSSTMM y
OWASP. Con éstos resultados los encargados de la organización pueden elaborar
un plan de trabajo de mitigación de los riesgos asociados. Por lo tanto fue posible
comprobar la hipótesis planteada.

164
 165

5. Mediante la adecuada utilización de técnicas y metodologías de intrusión, es

posible ejecutar de manera satisfactoria un Test de Intrusión en un ambiente
híbrido, el cual puede incluir tecnologías de código abierto.

6. Debe documentarse detalladamente la identificación de cada uno de los hallazgos

y explotación específica donde sea posible, con lo cual se puede proveer
recomendaciones generales y oportunas sobre cómo puede mitigarse el riesgo
asociado a cada uno de los activos vulnerados.
 RECOMENDACIONES

1. Las metodologías PTES, OSSTMM y OWASP seleccionadas para el Test de

Intrusión son metodologías abiertas. Son un buen punto de partida para todo
departamento de Tecnología para poder adentrarse en el mundo de la Seguridad
Informática y de esta manera iniciar procesos de mejora continua en sus nuevas
implementaciones de infraestructura crítica y desarrollo de aplicaciones web
seguras, entre otros.

2. Es necesario que el informe final del Test de Intrusión incluya una sección
Ejecutiva, con datos globales, descripciones en lenguaje natural, fáciles de entender
por directivos de alto nivel (Gerentes Generales, Financieros, Directivos,
etcétera), como también una parte Técnica la cuál será analizada en detalle por el
equipo técnico de la organización, el cual podrá servir como base para plantear una
línea de trabajo de mitigación de las vulnerabilidades identificadas.

3. Debido a la creciente necesidad de servicios profesionales de Seguridad

Informática a nivel global, se hace necesario para toda organización que adquiere
tales servicios, un Test de Intrusión, para aprovechar la adquisición de
conocimientos fundamentales que resultan de la identificación y materialización de
las vulnerabilidades en su infraestructura o aplicaciones.

4. Se recomienda ejecutar un Test de Intrusión de manera periódica, al menos una vez

por año, ya que cada día pueden descubrirse nuevas vulnerabilidades y amenazas,
o se implementan nuevas soluciones tecnológicas. Un test de Intrusión además de
proveer información sobre puntos débiles, debe ser tomado como base para una

166
 167

línea de conocimiento y aplicación de mejoras prácticas por parte del equipo

técnico de la organización.

5. La identificación periódica y manejo adecuado de vulnerabilidades

se vuelve una necesidad, ya que esto permite la ejecución de acciones preventivas
de forma proactiva y no reactiva. Se recomienda ejecutar Análisis de
Vulnerabilidades de forma periódica, por ejemplo una vez al mes, ya que con esto
el personal técnico de la organización puede obtener retroalimentación de forma
recurrente.
 GLOSARIO

Amenaza
Una amenaza informática es toda circunstancia, evento o persona que tiene el potencial de
causar daño a un sistema en forma de robo, destrucción, divulgación, modificación de datos o
negación de servicio (DoS).

Antivirus
Antivirus es una categoría de software de seguridad que protege un equipo de virus,
normalmente a través de la detección en tiempo real y también mediante análisis del sistema, que
pone en cuarentena y elimina los virus. El antivirus debe ser parte de una estrategia de seguridad
estándar de múltiples niveles.

Backdoor
Tipo de troyano que permite el acceso al sistema infectado y su control remoto. El atacante
puede entonces eliminar o modificar archivos, ejecutar programas, enviar correos masivamente o
instalar herramientas maliciosas.

Blacklisting o Lista Negra

La lista negra es el proceso de identificación y bloqueo de programas, correos electrónicos,
direcciones o dominios IP conocidos maliciosos o malévolos.

Bot
Un bot es una computadora individual infectada con malware, la cual forma parte de una
red de bots (bot net).

Botnet
Conjunto de equipos bajo el control de un bot maestro, a través de un canal de mando y
control. Estos equipos normalmente se distribuyen a través de Internet y se utilizan para

168
 169

actividades malintencionadas, como el envío de spam y ataques distribuidos de negación de

servicio. Las botnet se crean al infectar las computadoras con malware, lo cual da al atacante
acceso a las máquinas. Los propietarios de computadoras infectadas generalmente ignoran que su
máquina forma parte de una botnet, a menos que tengan software de seguridad que les informe
acerca de la infección.

Caballo de Troya
Son un tipo de código malicioso que parece ser algo que no es. Una distinción muy
importante entre troyanos y virus reales es que los troyanos no infectan otros archivos y no se
propagan automáticamente. Los caballos de troya tienen códigos maliciosos que cuando se activan
causa pérdida, incluso robo de datos. Por lo general, también tienen un componente de puerta
trasera, que le permite al atacante descargar amenazas adicionales en un equipo infectado.
Normalmente se propagan a través de descargas inadvertidas, archivos adjuntos de correo
electrónico o al descargar o ejecutar voluntariamente un archivo de Internet, generalmente después
de que un atacante ha utilizado ingeniería social para convencer al usuario de que lo haga.

Ciberdelito
El ciberdelito es un delito que se comete usando una computadora, red o hardware. La
computadora o dispositivo puede ser el agente, el facilitador o el objeto del delito. El delito puede
ocurrir en la computadora o en otros lugares.

CISA
Certified Information Systems Auditor (CISA) es una certificación para auditores
respaldada por la Asociación de Control y Auditoría de Sistemas de Información (ISACA)
(Information Systems Audit and Control Association). Los candidatos deben cumplir con los
requisitos establecidos por la ISACA.

CISSP
Certified Information Systems Security Professional, es una certificación de alto nivel
profesional otorgada por la (ISC)2 (International Information Systems Security Certification
 170

Consortium, Inc), con el objetivo de ayudar a las empresas a reconocer a los profesionales con
formación en el área de seguridad de la información.
COBIT
Objetivos de Control para Información y Tecnologías Relacionadas (COBIT, en inglés:
Control Objectives for Information and related Technology) es una guía de mejores prácticas
presentada como framework, dirigida al control y supervisión de tecnología de la información (TI).
Mantenida por ISACA (en inglés: Information Systems Audit and Control Association) y el IT GI
(en inglés: IT Governance Institute), tiene una serie de recursos que pueden servir de modelo de
referencia para la gestión de TI, incluyendo un resumen ejecutivo, un framework, objetivos de
control, mapas de auditoría, herramientas para su implementación y principalmente, una guía de
técnicas de gestión.

COSO
Committee of Sponsoring Organizations of the Treadway Commission (COSO):
iniciativa de 5 organismos para la mejora de control interno dentro de las organizaciones.

Diagrama de GANNT
Es una herramienta gráfica cuyo objetivo es exponer el tiempo de dedicación previsto
para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de esto, el
diagrama de Gantt no indica las relaciones existentes entre actividades.

Encriptación
La encriptación es un método de cifrado o codificación de datos para evitar que los usuarios
no autorizados lean o manipulen los datos. Sólo los individuos con acceso a una contraseña o clave
pueden descifrar y utilizar los datos. A veces, el malware utiliza la encriptación para ocultarse del
software de seguridad. Es decir, el malware cifrado revuelve el código del programa para que sea
difícil detectarlo.

Exploits o Programas intrusos

Los programas intrusos son técnicas que aprovechan las vulnerabilidades del software y
que pueden utilizarse para evadir la seguridad o atacar un equipo en la red.
 171

Falso Positivo
Se refiere a la identificación de una vulnerabilidad, de la cual se posee cierta información,
pero, en el momento de materializarla, ésta no puede ser explotada. Ocurre normalmente con los
resultados devueltos por herramientas automatizadas de escaneo de vulnerabilidades, los cuáles
deben ser analizados y verificados adecuadamente por un Auditor de Sistemas, con el objetivo de
descartarlos, y únicamente entregar información certera de vulnerabilidades confirmadas.

Filtración de datos
Una filtración de datos sucede cuando se compromete un sistema, exponiendo la
información a un entorno no confiable. Las filtraciones de datos a menudo son el resultado de
ataques maliciosos, que tratan de adquirir información confidencial que puede utilizarse con fines
delictivos o con otros fines malintencionados
Firewall
Un firewall es una aplicación de seguridad diseñada para bloquear las conexiones en
determinados puertos del sistema, independientemente de si el tráfico es benigno o maligno. Un
firewall debería formar parte de una estrategia de seguridad estándar de múltiples niveles.

Firma antivirus
Una firma antivirus es un archivo que proporciona información al software antivirus para
encontrar y reparar los riesgos. Las firmas antivirus proporcionan protección contra todos los virus,
gusanos, troyanos y otros riesgos de seguridad más recientes. Las firmas antivirus también se
denominan definiciones de virus.

Greylisting o Lista Gris

La lista gris es un método de defensa para proteger a los usuarios de correo electrónico
contra el spam. Los mensajes de correo electrónico son rechazados temporalmente de un remitente
que no es reconocido por el agente de transferencia de correos. Si el correo es legítimo, el servidor
de origen tratará de nuevo y se aceptará el correo electrónico. Si el correo es de un remitente de
spam, probablemente no se reintentará su envío y, por lo tanto, no logrará pasar el agente de
transferencia de correos.
 172

Gusanos
Los gusanos son programas maliciosos que se reproducen de un sistema a otro sin usar un
archivo anfitrión, lo que contrasta con los virus, puesto que requieren la propagación de un archivo
anfitrión infectado.

Hacking Ético
Es una forma de referirse al acto de una persona usar sus conocimientos de informática y
seguridad para realizar pruebas en redes y encontrar vulnerabilidades, para luego reportarlas y que
se tomen medidas, sin hacer daño.

HeartBleed
Es un agujero de seguridad de software en la biblioteca de código abierto OpenSSL, solo
vulnerable en su versión 1.0.1f, que permite a un atacante leer la memoria de un servidor o un
cliente, permitiéndole por ejemplo, conseguir las claves privadas SSL de un servidor.

IDS
Intrusion Detection System, es un programa de detección de accesos no autorizados a un
computador o a una red. El IDS suele tener sensores virtuales (por ejemplo, un sniffer de red) con
los que el núcleo del IDS puede obtener datos externos (generalmente sobre el tráfico de red). El
IDS detecta, gracias a dichos sensores, las anomalías que pueden ser indicio de la presencia de
ataques y falsas alarmas.

Imagen ISO
Una imagen ISO es un archivo informático donde se almacena una copia o imagen exacta
de un sistema de archivos.

Ingeniería Social
Método utilizado por los atacantes para engañar a los usuarios informáticos, para que
realicen una acción que normalmente producirá consecuencias negativas, como la descarga de
malware o la divulgación de información personal. Los ataques de phishing con frecuencia
aprovechan las tácticas de ingeniería social.
 173

IoT
Internet of Things, Internet de las cosas. Cualquier dispositivo que cuenta con conexión a
internet (carros, lavadoras, etcétera).

IPS
Intrusion Prevention System, es un software que ejerce el control de acceso en una red
informática para proteger a los sistemas computacionales de ataques y abusos. La tecnología de
prevención de intrusos es considerada por algunos como una extensión de los sistemas de
detección de intrusos (IDS), pero en realidad es otro tipo de control de acceso, más cercano a las
tecnologías cortafuegos.

JAVA
Es un lenguaje de programación de propósito general, concurrente, orientado a objetos que
fue diseñado específicamente para tener tan pocas dependencias de implementación como fuera
posible.

Lista blanca o Whitelisting

La lista blanca es un método utilizado normalmente por programas de bloqueo de spam,
que permite a los correos electrónicos de direcciones de correo electrónicos o nombres de dominio
autorizados o conocidos pasar por el software de seguridad.

Keystroke Logger
Es un tipo de malware diseñado para capturar las pulsaciones, movimientos y clics del
teclado y del ratón, generalmente de forma encubierta, para intentar robar información personal,
como las cuentas y contraseñas de las tarjetas de crédito.

Malware
El malware es la descripción general de un programa informático que tiene efectos no
deseados o maliciosos. Incluye virus, gusanos, troyanos y puertas traseras. El malware a menudo
utiliza herramientas de comunicación populares, como el correo electrónico y la mensajería
instantánea, y medios magnéticos extraíbles, como dispositivos USB, para difundirse. También se
 174

propaga a través de descargas inadvertidas y ataques a las vulnerabilidades de seguridad en el

software. La mayoría del malware peligroso actualmente busca robar información personal que
pueda ser utilizada por los atacantes para cometer fechorías.

Negación de servicio (DoS)

La negación de servicio es un ataque en el que el delincuente intenta deshabilitar los
recursos de una computadora o lugar en una red para los usuarios. Un ataque distribuido de
negación de servicio (DDoS) es aquel en que el atacante aprovecha una red de computadoras
distribuidas, como por ejemplo una botnet, para perpetrar el ataque.

OpenSSL
Es una herramienta de software de código abierto, que consiste en un robusto paquete de
herramientas de administración y bibliotecas relacionadas con la criptografía, que suministran
funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro
a sitios HTTPS).

PCI-DSS
El Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (Payment Card
Industry Data Security Standard) o PCI DSS fue desarrollado por un comité conformado por las
compañías de tarjetas (débito y crédito) más importantes, comité denominado PCI SSC (Payment
Card Industry Security Standards Council) y es una guía que ayuda a las organizaciones que
procesan, almacenan y/o transmiten datos de tarjetahabientes (o titulares de tarjeta), a asegurar
dichos datos, con el fin de evitar los fraudes que involucran tarjetas de pago débito y crédito.

Phishing
A diferencia de la heurística o los exploradores de huella digital, el software de seguridad
de bloqueo de comportamiento se integra al sistema operativo de un equipo anfitrión y supervisa
el comportamiento de los programas en tiempo real en busca de acciones maliciosas. El software
de bloqueo de comportamiento bloquea acciones potencialmente dañinas, antes de que tengan
oportunidad de afectar el sistema. La protección contra el comportamiento peligroso debe ser parte
de una estrategia de seguridad estándar de múltiples niveles.
 175

PHP
Es un lenguaje de programación de uso general de código del lado del servidor
originalmente diseñado para el desarrollo web de contenido dinámico. Fue uno de los primeros
lenguajes de programación del lado del servidor que se podían incorporar directamente en el
documento HTML en lugar de llamar a un archivo externo que procese los datos.

Plataformas Críticas
Tiene como principal objetivo aportar soluciones integrales a clientes con requerimientos
tecnológicos exigentes, tales como gran flexibilidad y escalabilidad en temas de crecimiento y
tecnología, disponibilidad de los servicios 24x7 y seguridad garantizada en todas sus aristas
(lógica, física, virtual).

Rootkits
Componente de malware que utiliza la clandestinidad para mantener una presencia
persistente e indetectable en un equipo. Las acciones realizadas por un rootkit, como la instalación
y diversas formas de ejecución de códigos, se realizan sin el conocimiento o consentimiento del
usuario final.
Los rootkits no infectan las máquinas por sí mismos como lo hacen los virus o gusanos,
sino que tratan de proporcionar un entorno indetectable para ejecutar códigos maliciosos. Los
atacantes normalmente aprovechan las vulnerabilidades en el equipo seleccionado o utilizan
técnicas de ingeniería social para instalar manualmente los rootkits. O, en algunos casos, los
rootkits pueden instalarse automáticamente al ejecutarse un virus o gusano o incluso simplemente
al navegar en un sitio Web malicioso.
Una vez instalados, el atacante puede realizar prácticamente cualquier función en el
sistema, incluyendo acceso remoto, intercepción de comunicaciones, así como procesos de
ocultamiento, archivos, claves de registro y canales de comunicación.

Sistema de detección de intrusos (IDS)

Un sistema de detección de intrusos es un servicio que monitorea y analiza los eventos del
sistema para encontrar y proporcionar en tiempo real o casi real advertencias de intentos de acceso
 176

a los recursos del sistema de manera no autorizada. Es la detección de ataques o intentos de

intrusión, que consiste en revisar registros u otra información disponible en la red. Un sistema de
detección de intrusos debe ser parte de una estrategia de seguridad estándar de múltiples niveles.

SCADA
Acrónimo de Supervisory Control And Data Acquisition (Supervisión, Control y
Adquisición de Datos) es un concepto que se emplea para realizar un software para ordenadores
que permite controlar y supervisar procesos industriales a distancia.

SDLC
El ciclo de vida de desarrollo de sistemas (SDLC), o ciclo de vida de desarrollo de software
en la ingeniería de sistemas e ingeniería de software, es el proceso de creación o modificación de
los sistemas, modelos y metodologías que la gente usa para desarrollar estos sistemas de software.

ShellShock
Es una familia de bugs de seguridad en la ampliamente usada Bash de Shell de Unix. Varios
servicios de internet tal como algunas implementaciones de servidores web usan Bash para ciertos
pedidos y procesos, esto le permitía al atacante ejecutar comandos arbitrarios en versiones
vulnerables de Bash, de esta forma el atacante podía ganar acceso no autorizado al sistema atacado.

SIEM
Security Information and Event Management, proporciona un análisis en tiempo real de las
alertas de seguridad generadas por el hardware y software de red. Las soluciones SIEM pueden
venir como software, appliance, o administración de servicios, y también son utilizados para
loguear datos de seguridad y generar reportes para fines de complimiento.

Sistema de prevención de intrusos (IPS)

Un sistema de prevención de intrusos es un dispositivo (hardware o software) que supervisa
las actividades de la red o del sistema en busca de comportamiento no deseado o malicioso y puede
 177

reaccionar en tiempo real para bloquear o evitar esas actividades. Un sistema de prevención de
intrusos debe ser parte de una estrategia de seguridad estándar de múltiples niveles.

SNMP
El Protocolo Simple de Administración de Red o SNMP (del inglés Simple Network
Management Protocol) es un protocolo de la capa de aplicación que facilita el intercambio de
información de administración entre dispositivos de red.

Spam
También conocido como correo basura, el spam es correo electrónico que involucra
mensajes casi idénticos enviados a numerosos destinatarios. Un sinónimo común de spam es
correo electrónico comercial no solicitado (UCE). El malware se utiliza a menudo para propagar
mensajes de spam al infectar un equipo, buscar direcciones de correo electrónico y luego utilizar
esa máquina para enviar mensajes de spam. Los mensajes de spam generalmente se utilizan como
un método de propagación de los ataques de phishing

Vector de ataque
Un vector de ataque es el método que utiliza una amenaza para atacar un sistema.

Vishing
Es una práctica fraudulenta que consiste en el uso del Protocolo Voz sobre IP (VoIP) y de
la ingeniería social para engañar personas y obtener información delicada como puede ser
información financiera o información útil para el robo de identidad. El término es una combinación
del inglés "voice" (voz) y phishing.

Virus
Programa informático escrito para alterar la forma como funciona una computadora, sin
permiso o conocimiento del usuario. Un virus debe cumplir con dos criterios:
Debe ejecutarse por sí mismo: generalmente coloca su propio código en la ruta de ejecución
de otro programa.
 178

Debe reproducirse: por ejemplo, puede reemplazar otros archivos ejecutables con una copia
del archivo infectado por un virus. Los virus pueden infectar computadores de escritorio y
servidores de red.

Muchos de los virus actuales están programados para operar sigilosamente la computadora
del usuario con el fin de robar información personal y utilizarla para cometer delitos. Otros
menoscaban el equipo dañando los programas, eliminando archivos o volviendo a formatear el
disco duro. Aún existen otros que no están diseñados para causar daño, aunque simplemente se
reproducen y hacen manifiestan su presencia presentando mensajes de texto, video y audio, aunque
este tipo de ataques de notoriedad no son tan comunes, puesto que los autores de virus y demás
malware tiene como fin obtener ganancias ilegales.

Vulnerabilidad
Una vulnerabilidad es un estado viciado en un sistema informático (o conjunto de sistemas)
que afecta las propiedades de confidencialidad, integridad y disponibilidad (CIA) de los sistemas.
Las vulnerabilidades pueden hacer lo siguiente:
 Permitir que un atacante ejecute comandos como otro usuario
 Permitir a un atacante acceso a los datos, lo que se opone a las restricciones
específicas de acceso a los datos
 Permitir a un atacante hacerse pasar por otra entidad
 Permitir a un atacante realizar una negación de servicio
 Anexo 1 - 00 – PT – Cuestionario General Inicial

# Pregunta Respuesta Comentarios

1 ¿Por qué necesita hacer un test de intrusión de sus
propios sistemas?
1. Es requerido por un Auditor de Seguridad de
rutina, normativa o estándar.
2. Decisión interna, para determinar las
debilidades de seguridad en el entorno
informático.

2 ¿Se llevará a cabo un tipo de test black-box o White-

box?

3 ¿Cuáles son los objetivos del test de intrusión?

a. Mapeo de vulnerabilidades
b. Demostrar que las vulnerabilidades existen.
c. Probar la respuesta a incidentes.
d. Explotación de una vulnerabilidad en la red,
sistema o aplicación. Obtener acceso
privilegiado, explotar desbordamiento de
memoria (buffer Overflow), ataques de
inyección SQL, etc.
e. Evaluar riesgo de disponibilidad de sistemas.
f. Evaluar riesgo de la seguridad de la
información.
g. Todos los anteriores.

179
 180

4 ¿Cuáles son los sistemas objetivos del test de

intrusión?
a. Aplicación
b. Sitio Web
c. Red
d. Aplicación y Red
e. Wireless
f. Otro (especifique).
5 ¿Se requiere que se ejecuten los siguientes tipos de
test?
a. Test de seguridad física: obtener acceso físico
evadiendo controles de seguridad físicos
(cámaras, biométricos, cerraduras, etc.).
b. Test de Ingeniería Social: obtener información
sensible de uno o más empleados.
6 ¿Qué protocolo de comunicación debe seguirse para
reportar las vulnerabilidades encontradas?
a. Esperar hasta finalizar el test de intrusión para
reportar todas las vulnerabilidades.
b. Reportar vulnerabilidades a medida que se
vayan encontrando.
c. Reportar diaria/semanalmente el status del test
de intrusión.
d. Reportar únicamente hallazgos críticos de
forma inmediata.
7 ¿Se estará realizando el test de intrusión en entorno de
producción?
8 ¿Si el entorno de producción no debe ser afectado, se
cuenta con un entorno similar al de producción donde
se pueda realizar el test de intrusión?
 181

9 ¿Los dueños/socios del negocio están informados

sobre la ejecución del test de intrusión?

Por motivos de comunicación, y para que sepan de la

naturaleza del proyecto, donde el Auditor de
Seguridad actuará como un atacante externo, para
conocer y comprobar posibles debilidades del sistema.
10 ¿En qué horario deben realizarse las actividades del
test de intrusión?
a. Horario hábil
b. Fuera de horario (nocturno)
c. Fines de semana
d. Durante ventanas de mantenimiento del
sistema
11 ¿Está permitido realizar ataques de denegación de
servicio?
a. Si, en entorno de producción.
b. Si, en entorno de pruebas.
c. No está permitido.
12 ¿Se cuenta con plan de recuperación de desastres, o
plan de continuidad del negocio? ¿Se puede obtener
una copia de los mismos?
13 ¿Existen aplicaciones o servicios de terceros, que
deben ser testeados? Detállelos.
14 ¿Actualmente, existen herramientas de monitoreo?
15 ¿Cuentan con un sistema de backups? ¿Los backups
son testeados con regularidad?
16 ¿Cuándo fue la última vez que utilizaron restauración
de backups?
 182

01 – PT – Cuestionario de Red

Rangos de IP que serán testeados y detalle de dichos rangos

IP Comentarios Interna/Externa

Información de los dominios y su configuración

Dominio Comentarios

Información sobre transferencia de zona DNS

Comentarios

Lista de Servidores
Dirección IP Nombres de Sistema Operativo Función
dominio
 183

Anexo 2 - 02 – PT – Cuestionario Aplicaciones Web

Listado de aplicaciones Web (Incluir Web Services si es requerido) #páginas #páginas

# Nombre URL Descripción estáticas dinámicas
1
2
3

¿Se proveerá algún tipo de documentación? ¿Qué tipo de documentación?

¿Se requiere análisis estático del código?

Esto implica en la mayoría de los casos obtener el código fuente, y hacer una revisión
minuciosa de la aplicación web sin ejecutar.

¿Está confirmado que se aprueba el uso de la guía de test OWASP v4? Y la evaluación
de las evaluaciones top 10 del 2013.
 184

Anexo 3 - 03 – PT – Cuestionario redes Wireless

¿Cuántas redes Wireless serán auditadas?

¿Existen redes Wireless para invitados?

¿Tienen autenticación?
¿Qué tipo de encriptación utilizan?
¿Cuál es el rango de cobertura?
¿se requiere análisis de puntos de acceso
no autorizados? (rogué Access points)
¿Se requiere ejecutar ataques Wireless
contra los clientes conectados?
¿Cuántos clientes se conectan a la red
aproximadamente?
 185

Anexo 4 - 04 – PT – Cuestionario acceso físico

¿Cuántas localidades serán evaluadas?

¿La localidad que se evaluará es un área común/compartida?

¿Cuántos pisos/áreas deben ser evaluados?
¿Cuáles son?

¿Se requerirá burlar guardias de seguridad?

¿Son guardias de un proveedor externo?
¿Están armados?
¿Están autorizados a usar la fuerza?

¿Cuántas entradas existen en la localidad?

¿Se permite el uso de herramientas de sabotaje como ganzúas? (lock picking,

considerar aspectos legales).

¿El objetivo de este test es el cumplimiento de alguna normativa/estándar o llevar a

cabo una Auditor de Seguridad?

¿De cuántos metros cuadrados es la localidad?

¿Existe documentación sobre las medidas de seguridad física?

 186

¿El objetivo de este test es el cumplimiento de alguna normativa/estándar o llevar a

cabo una Auditor de Seguridad?

¿Existen cámaras de seguridad?

¿Son propiedad del cliente?
¿Se requiere obtener acceso físico donde se
almacenan las grabaciones de las cámaras?

¿Existe un sistema de alarma?

¿Es una alarma silenciosa?
¿Se activa por movimiento?
¿Se activa con la apertura de puertas o
ventanas?

¿Existen controles de acceso biométrico o huella digital?

Anexo 5 - 05 – PT – Cuestionario Ingeniería Social

¿Se cuenta con una lista de correos electrónicos para hacer la prueba?

¿Se cuenta con una lista de números telefónicos para hacer la prueba?

¿Necesitan que uno de los objetivos sea obtener acceso físico no autorizado? ¿Cuántas
personas serán el objetivo?
 187

Anexo 5 - 05 – PT – Información de contacto

Incluir:
 Todos los Auditores de Seguridad involucrados en el test de intrusión.
 Dos contactos técnicos de la organización objetivo.
 Dos contactos técnicos del proveedor de la organización objetivo (si aplica).
 Un contacto de alto mando de la organización objetivo (Gerente, Directivo, Dueño, Socio).

Nombre Completo
Cargo y descripción de responsabilidad
operativa
Tiene autorización para discutir detalles
de las actividades del test
Celular
Correo Electrónico
Otro medio de contacto
Método de transferencia segura de
información (SFTP o correo cifrado)
¿Contacto 24/7?

Nombre Completo
Cargo y descripción de responsabilidad
operativa
Tiene autorización para discutir detalles
de las actividades del test
Celular
Correo Electrónico
Otro medio de contacto
Método de transferencia segura de
información (SFTP o correo cifrado)
¿Contacto 24/7?
 188

Nombre Completo
Cargo y descripción de responsabilidad
operativa
Tiene autorización para discutir detalles
de las actividades del test
Celular
Correo Electrónico
Otro medio de contacto
Método de transferencia segura de
información (SFTP o correo cifrado)
¿Contacto 24/7?
 189

Anexo 6 - 06 - PT - Autorización Test de Intrusión (formato de ejemplo)

Lugar y Fecha

<nombre_destinatario>
Presente

En Palin, Escuintla, Guatemala, siendo 05 de enero de 2016, <nombre_de_la_empresa_cliente>,

<NIT>, en adelante “La Organización”, cuyo giro de negocio es <giro_de_negocio_del_RTU>,
representada en este acto por <representante>, <CUI_representante>, por una parte; y por la otra,
<nombre_del_Auditor de Seguridad>, <CUI_Auditor de Seguridad>, Y <NIT_Auditor de
Seguridad>, en adelante “El Auditor de Seguridad”, han convenido en lo siguiente:

Dado que las partes han sostenido y/o están sosteniendo conversaciones y reuniones preliminares,
en lo relativo al proyecto TEST DE INTRUSIÓN, La Organización AUTORIZA a El Auditor
de Seguridad a poder hacer un test de intrusión interno y externo en los alcances que se definan en
próximas reuniones de planificación.

Esto implica que, El Auditor de Seguridad podrá hacer escaneos del equipo informático de la
organización para encontrar vulnerabilidades, explotarlas, y documentarlas. Este permiso se
autoriza desde la fecha de emisión de la presente, hasta el <fecha_fin>, o en una fecha preliminar,
bajo común acuerdo de ambas partes. Esta autorización, está orientada a documentar los hallazgos
que del test de intrusión sean obtenidos, para poder hacer recomendaciones y un mejoramiento
continuo de los activos de la organización, en materia de Tecnología de Información.

Asimismo, se establece, que El Auditor de Seguridad, deberá regirse a las cláusulas que se
especifican en el convenio de confidencialidad y no divulgación, el cuál será elaborado en común
acuerdo con La Organización.

<firma_Auditor de Seguridad> <firma_representante>

 190

Anexo 7 – 07 – PT - Acuerdo de Confidencialidad y No Divulgación

En la ciudad de <ciudad>, <departamento>, Guatemala, siendo <dia, mes y año>, entre
<empresa_cliente>, <NIT_Cliente>, en adelante “La Organización”, cuyo giro de negocio es
<giro_de_negocio_RTU>, representada en este acto por <representante>, quien se identifica con
<CUI_Representante>, por una parte; y por la otra, <nombre_del_Auditor de Seguridad>, quien
se identifica con <CUI_del_Auditor de Seguridad>, han convenido lo siguiente:

Dado que las partes han sostenido y/o están sosteniendo conversaciones y reuniones preliminares
en lo relativo al proyecto de TEST DE INTRUSIÓN, acuerdan que toda información ya sea en
forma oral o escrita a través de documentos, y en general, cualquier procedimiento o forma, en
virtud de las cuales se haga posible tomar conocimiento de tal información, tendrá carácter
“confidencial”.

Las partes acuerdan y se comprometen mutuamente en su propio nombre y en quienes representan

a lo siguiente:

 Se entiende por información confidencial, cualquier contraseña, dirección IP, nombre de

equipo o modelo, de toda la infraestructura tecnológica que será evaluada durante el TEST
DE INTRUSIÓN, y cualquier otro componente físico o lógico que se considere como
ACTIVO, y que pudiere ser parte de la seguridad de la información de La Organización.
 Mantener la más estricta reserva y confidencialidad sobre todos los antecedentes que
reciban y no dar a conocer a terceros en forma alguna, ningún antecedente parcial o total
de la Información Confidencial, ni a utilizar esta información para cualquier otro fin que
no sea el de tomar sus propias decisiones en relación a las conversaciones entre las partes.
La parte que haya entregado la Información Confidencial podrá autorizar su divulgación,
sólo previamente y por escrito.
 Proporcionar la información sólo a las personas que sea estrictamente necesario para los
fines previstos en este acuerdo.
 No divulgar ni distribuir bajo forma alguna, directa e indirectamente la información
recibida de ambas partes, e impedir que las personas vinculadas a cada una de ellas y que
en virtud de este acuerdo tengan acceso a tal información, lo revelen o distribuyan por
 191

algún medio, salvo autorización expresa entregada por las partes suscriptoras del presente
acuerdo.
 Devolverse mutuamente la información que hubiere sido intercambiada cuando una de las
partes así se lo solicite a la otra.

Las obligaciones aquí contenidas permanecerán válidas durante los 6 meses siguientes a la fecha
de firma de este documento, quedando una copia en poder de cada representante que aquí firman.

<firma_Auditor de Seguridad> <firma_representante>

 192

Anexo 8 – Carta de Entrega de proyecto, CLIENTE RETAIL

Guatemala, Palín, 16 de noviembre de 2016

Estimados Señores

CLIENTE RETAIL

Presente

Por medio de la presente, hago entrega de los resultados finales del TEST DE INTRUSIÓN, que
se llevó a cabo como parte de la aplicación práctica de la investigación “Test de Intrusión en
entornos GNU/Linux Aplicado en una empresa guatemalteca”.

Las actividades se llevaron a cabo a partir del mes de marzo, hasta noviembre de 2016, realizando
el día 16 de noviembre de 2016 la entrega final de informes y presentación de resultados detallados
con el equipo técnico de CLIENTE RETAIL.

Por consiguiente, hago constar que los entregables finales han sido:

 Informe Técnico y Ejecutivo de la intrusión (en formato digital).

 Presentación de los resultados (en formato digital).

Por lo anterior, se ha finalizado de manera satisfactoria la ejecución del Test de Intrusión.

Sin otro particular

Gerente de Informática Jefe de Infraestructura de TI

CLIENTE RETAIL CLIENTE RETAIL

Amílcar de León
Auditor de Seguridad
 REFERENCIAS BIBLIOGRÁFICAS

Beggs, R. (2014). Mastering Kali Linux for Advanced Penetration Testing. Birmingham,
Inglaterra: Editorial Packt Publishing Ltd.

Chavan, M. (Ed.). (2014). Kali Linux – Assuring Security by Penetration Testing. Birmingham,
Inglaterra: Editorial Packt Publishing Ltd.

De León, A. (2011). Seguridad (GNU)/Linux: malware, vulnerabilidades, protección y otros

recursos. Premio Universitario ESET.

ESET, (2017). La seguridad como rehén: tendencias 2017.

Febrero, B., Holguín, J. (2012). Pentest: recolección de información (information gathering).

INCIBE, INTECO-CERT.

ISECOM, Institute for Security and Open Methodologies, (2010). OSSTMM 3, The Open Source
Security Testing Methodology Manual.

OWASP, 2013. OWASP Top 10 – 2013, los diez riesgos más críticos en aplicaciones web.
Recuperado de:
https://www.owasp.org/images/5/5f/OWASP_Top_10_-_2013_Final_-_Espa%C3%B1ol.pdf

PTES, 2015. The Penetration Testing Execution Standard Guidelines. Recuperado de:
http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines

Shashi, A. (2013). Metasploit Penetration Testing Cookbook, segunda edición. Birmingham,

Inglaterra: Editorial Packt Publishing Ltd.

Tori, C. (2008). Hacking Ético, primera edición. Buenos Aires, Argentina: editorial Rosario.

193