Este post consistirá en la realización de un test de penetración para el entorno De-Ice II que podemos encontrar en la página del proyecto Sec-Track. Para el que no sepa que es esto, le remito al primer post de esta serie (los podéis encontrar en la categoría “prácticos” de este blog) o a la página del propio proyecto Sec-Track, el cual es muy recomendable y tiene cosas muy interesantes. Si no habéis realizado la primera parte (De-ICE I) os recomiendo que empecéis por ella, ya que habrá cosas que veremos en este entorno que se explicaron ampliamente en la primera parte.
Es esta ocasión, el escenario es el siguiente:
Una pequeña empresa te contrata para que realices un Test de Penetración avanzado. El administrador de sistemas de dicha empresa dice haber reconfigurado el sistema para hacerlo muy seguro. Espera que usted intente por todos los medios posibles de vulnerar el sistema, pues está seguro de que es invulnerable. Este sistema es un servidor FTP utilizado para crear y restaurar copias de seguridad de los diferentes sistemas. Dice además que no hay información sensible y que dicho sistemas alguna vez fue utilizado por un cliente para transferencias de información, pero que esta ha sido eliminada.
Por mi parte en este post voy a explicar los pasos que yo seguí para resolver el reto, y haré referencia a las explicaciones de Sec-Track cuando lo considere necesario.
Pues nada, manos a la obra. Lo primero, obviamente, es arrancar nuestra máquina virtual con el Live CD correspondiente al entorno. En caso de tener alguna duda de cómo configurarlo, en el proyecto Sec-Track se explica como configurar el entorno para VMWare y Qemu. Para el resto de plataformas de virtualización es muy similar, yo lo tengo instalado en Parallels sin ningún problema.
El ataque o test de penetración lo vamos a realizar desde el punto de vista externo, es decir, no vamos a tener un puesto en la red interna, ni ningún tipo de privilegio como pudiera tener alguna persona perteneciente a la organización.
Lo primero será realizar un escaneo de nuestra red para saber la IP que posee la máquina en cuestión. Si habéis realizado bien todos los pasos en la configuración, el resultado obtenido tendría que ser similar a este:
~#nmap –sP 192.168.1.1-255
Starting Nmap x.xx ( http://nmap.org ) at yyyy-mm-dd hh:mm CET
Nmap scan report for example.org (192.168.1.1) <- router
Host is up (0.0040s latency).
Nmap scan report for 192.168.1.3 <- nuestro ordenador
Host is up (0.00048s latency).
…
Nmap scan report for 192.168.1.110 <- De-ICE II
Host is up (0.0022s latency).
Nmap done: 255 IP addresses (X hosts up) scanned in 15.12 seconds
Este paso en un test real, no deberíamos realizarlo ya que tendríamos la IP del objetivo, pero aquí no está demás para comprobar que todo está bien configurado.
Una vez comprobado que la máquina existe y posee una IP válida, vamos a conectar desde nuestro navegador a su página web para ver que nos puede ofrecer.
En esta ocasión, la página web es bastante escueta. Podemos ver un pequeño encabezado, un pequeño texto y varias direcciones de correo. En este caso, si nos fijamos, todas ellas son de administradores. Al igual que en el primer entorno desarrollado, podemos formar combinaciones con los nombres para tratar de encontrar usuarios válidos para pruebas de acceso que realizaremos posteriormente. A parte de esto, poca información más nos va a dar esta página.
El siguiente paso es ver que nos ofrece el entorno objetivo, es decir, que servicios tiene abierto y accesibles desde el exterior. Para ello vamos a realizar un escaneado de puerto:
~#nmap 192.168.1.110
Starting Nmap x.xx ( http://nmap.org ) at yyyy-mm-dd hh:mm CET
Nmap scan report for 192.168.1.110
Host is up (0.012s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
631/tcp open ipp
Nmap done: 1 IP address (1 host up) scanned in 12.78 seconds
Como podemos ver, la máquina objetivo tiene varios servicios a disposición de los usuarios, y nuestra claro.
También podemos ejecutar la instrucción:
~# nmap -sV -p 21,22,80,631 192.168.1.110
Con ella podemos obtener más información sobre los servicios que están corriendo, como versiones, aplicaciones, etc…
Starting Nmap 5.21 ( http://nmap.org ) at 2010-12-10 10:36 CET
Nmap scan report for 192.168.1.110
Host is up (0.00092s latency).
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.4
22/tcp open ssh?
80/tcp open http Apache httpd 2.2.4 ((Unix) mod_ssl/2.2.4 OpenSSL/0.9.8b DAV/2)
631/tcp open ipp CUPS 1.1
Service Info: OS: Unix
El único puerto sobre el que no hemos podido averiguar datos es el 22, pero bueno, esto de momento, no nos tiene que preocupar.
Lo más normal ahora, sería lanzar un escáner de vulnerabilidades como nessus o alguna herramienta similar o de recolección de información, pero yo en muchas ocasiones, antes de entrar en faena y consumir tanto tiempo, prefiero hacer las pruebas más evidentes, y oye, a veces hasta funcionan. En este caso, la prueba tonta, es conectarse al servidor ftp y probar si se puede acceder anónimamente a él:
~# ftp 192.168.1.110
Connected to 192.168.1.110.
220 (vsFTPd 2.0.4)
Name (192.168.1.110:svoboda): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
Pues nada, parece que ha habido suerte y hemos conectado. Si esto hubiera fallado, tendríamos que habernos puesta ya a la faena y utilizar herramientas para comprobar vulnerabilidades, o hacer ataques de fuerza bruta a ver si podemos entrar o similares. Pero, una vez más, se demuestra que el eslabón más débil de la cadena es el ser humano, en este caso, un administrador confiado o despistado, que no ha inhabilitado el acceso anónimo.
El siguiente paso es explorar el árbol de directorios que está nuestra disposición para ver si encontramos algo útil.
Por mi parte, yo he encontrado dos ficheros útiles localizados en el directorio “/etc”. Estos son:
- core
- shadow
El que más llamó mi atención es el fichero shadow, ya que como imagino sabréis es una forma de almacenar los passwords del sistema en *unix. Tras verlo, lo primero que hice fue bajármelo y utilizar la herramienta “John the Ripper” para ver si conseguía sacar parejas de usuario/contraseña válidos. De todo esto se habló, en el desarrollo del primer entorno.
[Esto último, fue un grave fallo mío, y una pérdida de tiempo por mi parte. Tras terminar de pasarle el primer diccionario y no obtener resultados me puse a revisar el fichero que me había bajado y a buscar los usuarios que previamente habíamos conseguido y formado a través de nuestra visita a la página web. Para mi sorpresa, no encontré ninguna de las combinaciones que había formado. Teniendo en cuenta, que el ftp se utiliza para realizar copias de otros sistemas, probablemente el fichero sea de otro sistema y nos de este. Mi fallo, dejarme llevar por lo evidente. Nota mental: No suponer nada nunca.]
Después de este tiempo perdido, y de la lección aprendida, vamos a examinar el otro fichero interesante que hay, el core. Si abrimos este fichero directamente, obviamente, no veremos nada. Pero para eso tenemos la herramienta “strings” en sistemas *unix.
~#strings core
Con esto podremos ver variables locales, información varia del sistema en el momento del fallo y, al final, encontraremos unas líneas con el formato de un fichero de passwords de *unix. Y esta vez si, con los usuarios que estábamos buscando (no volvamos a cometer el mismo error dos veces). Con esto podemos lanzar al amigo “john” y esperar resultados.
Depende de los diccionarios que empleéis, encontraréis más o menos resultados. Yo el primero que obtuve es el de root, pero desafortunadamente, tras varios intentos de conexión “ssh” me di cuenta de que este no posee acceso remoto. Finalmente, dos diccionarios después, conseguí otro usuario y su password y pude conectar. Una vez dentro del sistema, con el comando “su”, ya podemos hacer superusuario con todos los privilegios que esto conlleva.
El siguiente paso, es explorar el sistema a ver si podemos encontrar algo que merezca la pena. Ya sabéis con “ls –la” o como más os guste.
Tras un rato de buscar, encontramos en “/home/root/.save” un interesante fichero llamado “copy.sh” que cifra a través de “openssl” (podéis ver un artículo en este mismo blog sobre ello) algo que se localiza en “ftp/incoming” y que se salva en este directorio con al extensión “.enc”. En el propio directoria ya existe un fichero con esta extensión, pero si lo listamos, veremos que no podemos entender absolutamente nada. Lo que tenemos que hacer, ya que sabemos como se cifra es descifrarlo con “openssl”:
root@slax:/home/root/.save# openssl enc -d -aes-256-cbc -salt -in customer_account.csv.enc -out customer_account.csv -pass file:/etc/ssl/certs/pw
Tras esto podremos visualizar el fichero en texto plano y ver clientes, y tarjetas de crédito.
El último paso, es garantizarnos el fácil acceso para otras ocasiones. Pero como esto es igual que en el entorno anterior, no vamos a entrar aquí.
Una vez llegado hasta aquí, os recomiendo visitar la página correspondiente a la resolución de este entorno en el proyecto Sec-Track:
- Network mapping, port scanning
- Recopilación de información, escaneo de vulnerabilidades
- Acceso al sistema y elevación de privilegios
- Información confidencial y backdoors
En estos cuatro artículos ellos desarrollan, no solo en entorno como he hecho yo, si no que además, intentan introducir dentro de un marco de metodología, algunas herramientas.
Espero que os sirva. Como siempre, animaros a poner dudas o comentarios. Nos vemos.
