MOOC Hacking Ético: Actividad final

Dentro del MOOC Hacking Ético impartido por Mondragon Unibertsitatea nos serán dictadas varias tareas que deberemos de publicar en nuestro blog personal, dichas tareas las iré colocando en la categoría MOOC Hacking Ético. (Para ver todas las categorías de mi blog haz clic sobre el engrane que está dentro del hexágono café en la parte superior de la página).

#moocHackingMU

No hay plazo que no llegue, después de 4, casi 5 semanas el MOOC de Hacking Ético ha llegado al final. Obviamente no es que ya sea un experto en seguridad y hacking, hacerse experto en 5 semanas es imposible, pero sí hubo temas de bastante interés y que sirven de punto de inicio para adentrarse de manera más profunda en este mundo de la seguridad informática. Reforcé algunos conocimientos que ya tenía, y aprendí otros tantos más.

El presente artículo presenta desde un punto de vista resumido lo que fue mi estancia en el curso, el trabajo que se realizó, el reto, y algunos otros detalles.

Unidad 1

En esta unidad nos fueron enseñadas algunas herramientas (Ping, Whois y Nmap) que nos permiten obtener información de los servidores. Suponiendo que queremos hacer pruebas de penetración a un servidor remoto podemos comenzar usando algunas de estas herramientas para ir obteniendo información del objetivo.

En esta unidad también se nos encomendó buscar páginas web (sean blogs, foros o páginas de empresas) que traten de temática hacking. Al igual que muchos, considero que la de mejor calidad en español es el foro de elhacker.net, llevo años usándolo como base de conocimiento. Mención especial merece ХабраХабр (HabraHabr), una página de procedencia rusa de la cual destacan algunos de sus tutoriales, DIY’s y HOW-TO’s.

Para concluir esta unidad, incursionamos un poco en la criptografía, generamos nuestro par de llaves GPG, compartimos nuestra llave pública con el resto de participantes e intercambiamos mensajes de correo cifrados. Esta pequeña práctica nos serviría después para resolver el ENIGMA de la unidad 2.

Para profundizar más en lo realizado en esta unidad, dejo los links con cada una de las tareas:

Unidad 2

La primera actividad de esta unidad fue analizar el tráfico de red usando un analizador de protocolos (Wireshark). Si bien yo ya lo había usado antes (para debuggear aplicaciones cliente-servidor que desarrollaba en mi anterior trabajo), estas prácticas me sirvieron para recordar su uso, y ver lo inseguros que son algunos protocolos como Telnet, donde toda la sesión viaja en texto plano (sin cifrar).

En la segunda parte de esta unidad realizamos prácticas con un tipo de ataque muy conocido, me refiero a SQL Injection. Hasta antes del curso mi conocimiento de SQL Injection se limitaba a proteger las aplicaciones Web que desarrollo, pero nunca había tenido la oportunidad de realizar el ataque. Aunque el ataque que se hizo fue en un servidor de pruebas, se siente bien saber lo que hace el atacante cuando intenta vulnerar tus aplicaciones. Ahora sé  como es SQL Injection desde ambas caras de la moneda (atacante y programador).

En esta unidad también se trató de iniciar un debate acerca de la ética hacker en foro del MOOC, ¿qué está bien? ¿qué está mal? ¿cuáles son los límites de un hacker? Se trató de iniciar el debate usando como punto de partida el (ya no tan) reciente hackeo a la empresa italiana ]Hacking Team[. La propuesta del debate era buena, pero creo que no hubo mucha participación, muchos (yo incluido) nos limitamos a colocar una breve respuesta en el hilo del foro y nunca más lo visitamos.

Para concluir esta unidad se nos pidió una actividad de reflexión acerca de lo trabajado en esta semana.

Los links de las tareas de la unidad 2 son los siguientes:

Resolución del ENIGMA

En la semana 2 se nos planteó un ENIGMA que, si lo resolvíamos nos daba acceso al reto final con la pequeña ventaja de tener un poco más de tiempo para organizar nuestro equipo  y por ende, tener más tiempo de preparación.

Para resolver el ENIGMA teníamos que poner en práctica los conocimientos adquiridos en la Unidad 1 – Tarea 3 (criptografía)  y la Unidad 2 – Tarea 2 (SQL Injection). Así que después de leer las instrucciones del mismo, puse manos a la obra.

Instrucciones del ENIGMA

Instrucciones del ENIGMA

La solución fue bastante simple, prácticamente era repetir los pasos de la tarea 2 de la Unidad 2, pero con otra tabla (guestbook) para obtener la clave para descifrar el archivo GPG. El archivo lo descifre con Kleopatra para Windows.

Desafortunadamente no realicé capturas de pantalla con los pasos, o “inyecciones” que iba realizando, pero aún poseo el archivo en texto plano, junto con los resultados de la inyección SQL con la que obtuve la clave de descifrado.

El GPG descifrado y el resultado de la inyección.

El GPG descifrado y el resultado de la inyección.

Me quedé con ganas de que el ENIGMA fuera un poco más difícil, no sé, que se usara un poco más de criptografía y tal vez algo de esteganografía.

Unidad 3: El reto

La formación del grupo

Tras resolver el enigma, solicité audiencia con el Consejo Jedi (que no era más que enviar una solicitud para unirse al grupo de Facebook) y después de ser aceptado me di a la tarea de crear un equipo, mi intención era reunir integrantes de mi país (México) o cualquier ciudad de otro país que estuviera entre UTC -4 y UTC -6, para no tener problemas de zona horaria, ya que yo estoy en UTC -5.

No obtuve gran respuesta y terminé uniéndome a un grupo con integrantes de diversos países que al parecer estaban dentro de la zona horaria indicada anteriormente. Siguiendo con la ambientación de Guerra de las Galaxias elegimos por nombre R2-D2 Hacking Team (en realidad el nombre lo puso la chica que creó el grupo, cuando yo me uní, ya tenía ese nombre).

El representante del grupo ante el Consejo fue elegido entre todos, su nombre es Javier. Después de que él enviara el formulario de inscripción a los miembros del Consejo pasaron algunos días y finalmente se nos hicieron llegar los datos del servidor.

Gracias al nombre del servidor me di cuenta que eramos el equipo 15 (team-0015). Nuestro servidor tenía la IP 178.62.197.222.

Para definir quienes íbamos a defender y quienes a atacar cada integrante eligió por sí mismo a qué se quería dedicar. Yo elegí la defensa.

Comienzo del análisis del servidor y creación del ambiente de pruebas

No soy experto en Linux, por ello estaba consiente de que iba a tener que tocar configuraciones que nunca antes había visto, y no me iba a arriesgar a dejar por accidente inoperable nuestro preciado servidor. Aprovechando que la distribución instalada en el server era Debian (o un derivado de este) procedí a preparar un mini-server local en una Raspberry Pi con Raspbian (basado en Debian) para probar cualquier cambio de configuración en un entorno controlado, y sólo tras comprobar sí funciona realizarlo en el server.

Raspberry Pi de pruebas

Raspberry Pi de pruebas

La primer tarea que realizamos como equipo fue incorporarnos al canal de la plataforma Slack que Javier creo para estar en contacto todos los integrantes. Una vez dentro del canal lo primero que hicimos fue anotar una breve descripción técnica de nosotros, para saber con qué contábamos en el equipo. Esta fue mi descripción:

Hola equipo, les comento acerca de mi: Soy desarrollador Web en PHP sin frameworks, formalmente llevo 5 años en PHP aunque lo conozco desde hace 10. Tambien sé Visual Basic 6, aunque su época gloriosa ya pasó en la empresa hay sistemas heredados que están en ese lenguaje. En mis ratos libres le hago un poco al Arduino y Raspberry Pi. También sé un poquitín de Python. Me interesa mucho el análisis y diseño de malware, de hecho he realizado algunas pruebas de concepto (en VB6). Hablando de seguridad, no sé mucho, realmente solo los temas que nos han dado en el curso.

En configuración de servidores, solo he modificado cosas menores, y que tienen que ver con Apache/PHP

Entonces dimos paso al primer trabajo de defensa, íbamos a empezar a analizar el servidor, ver qué tenía instalado y buscar vulnerabilidades. Manuel (otro integrante del equipo) puso a disposición de todos 3 documentos conjuntos: Análisis del servidor, Plan de Hardening y Plan de Ataque. En el primero teníamos que anotar todo lo que encontráramos (vulnerabilidades, errores de configuración, etc), en el segundo anotaríamos como solucionarlo y en el tercero un plan de cómo iban a ser atacados los demás equipos. Los detalles de mi aporte al análisis del servidor estan en el archivo Analisis Server

Tristemente aquí se comenzó a notar la falta de participación del equipo. No todos llenaron los documentos, de hecho hay a quienes no volví a ver nunca más, ni en el chat, ni en el grupo de Facebook, mucho menos atacando o defendiendo.

Análisis del servidor

Mi aporte al análisis del servidor

Plan de hardening

El plan de hardening lo explicaré de la siguiente forma: a) qué se hizo, b) por qué o para qué se hizo y c) cómo se hizo.

Notas:

  • Los procesos expuestos a continuación son los que yo realicé, así que no representan toda la defensa que tenía el servidor. Otros integrantes habrán añadido otras técnicas de defensa.
  • Todos los procesos los realicé primero en el ambiente de pruebas para comprobar su correcto funcionamiento.

Haz clic en la imagen para verla completa, también puedes descargar el archivo Plan de Hardening

Plan de hardening

Plan de hardening

Inicio de la fase de ataque

Mi tarea principal cuando inicio la fase de ataque fue monitorear el blindaje que le hice al server. Más tardé en entrar al log de accesos de Apache que en descubrir que el parche aplicado a Gitlist solo detenía a los más principiantes. Atacantes con más pericia estaban logrando obtener los archivos trofeo de nuestro servidor insertando de algún modo los comandos en la URL de Gitlist (ls o find para buscarlos y cat para mostrar el contenido del mismo y poderlo copiar). Estimo que 3 atacantes obtuvieron 4 o 5 archivos.

Una nueva y más profunda búsqueda me llevó a la página de descargas de Gitlist 0.5.0, que corregía dicha vulnerabilidad. Para instalarla realicé lo siguiente:

cd /usr/share/wwwroot
mv gitlist none.git
wget https://s3.amazonaws.com/gitlist/gitlist-0.5.0.tar.gz
tar -zxvf gitlist-0.5.0.tar.gz
cp none.git/config.ini gitlist
cp none.git/.htaccess gitlist
mkdir gitlist/cache
chomod 777 gitlist/cache/
rm gitlist-0.5.0.tar.gz
rm -r none.git/

También en esta fase confirmé lo que se empezaba a notar en la fase anterior: la falta de participación del grupo. Aparentemente sólo estábamos trabajando Manuel y yo, él atacando y yo defendiendo.

Después de actualizar Gitlist no tuvimos más intrusiones por esa vía, aunque se apreciaba en los archivos de log que muchos seguían intentándolo. En este punto noté que sobresalían 3 Agentes de Usuario que intentaban explotar el fallo:

  • wget
  • curl
  • libwww-perl

Si bien ya no lograban la intrusión, igual podrían seguir obteniendo datos importantes del servidor, así que me día a la tarea de investigar si se podía bloquear el acceso a la carpeta Gitlist a ciertos agentes de usuario. Tras varios intentos la investigación dio resultado.

Esto fue lo que hice:

nano /etc/apache2/conf.d/gitlists.conf
Añadir a la directiva <Directory /usr/share/wwwroot> lo siguiente:
SetEnvIfNoCase User-Agent$ .*(libwww-perl) keep_out
SetEnvIfNoCase User-Agent$ .*(curl) keep_out
SetEnvIfNoCase User-Agent$ .*(wget) keep_out
Deny from env=keep_out
Guardar y salir, después
service apache2 restart

Posteriormente me dediqué a analizar más a fondo CACTI. Llegué a la conclusión de que los archivos nivel 1 y 2 eran obtenibles vía Gitlist, pero el nivel 3 tendría que ser obtenido de otra forma.

Según la NVD (National Vulnerability Database) CACTI incluye un abanico de vulnerabilidades SQL Injection y XSS, mi objetivo era lograrlas reproducir para saber como proteger la aplicación (recordemos que al momento de intentar actualizarla, apt-get mostraba que estaba en su ultima versión, cosa que no es del todo cierta).

La forma de reproducir dichas vulnerabilidades en CACTI sencillamente escapó a mi nivel de conocimientos. Tras varias jornadas de investigación, no conseguí reproducir ninguna.

Mi intento de ataque

Al saber que Manuel estaba atacando solo y con la defensa del servidor un poco más estable, me decidí a incursionar en el ataque. Con la idea de obtener el mayor número de archivos posible, elaboré un mini-exploit en Python basado en el xploit de @dronesec pero adaptado para el propósito del curso. El código fuente está disponible en un repositorio de Github:

https://github.com/underdog1987/GitList-Exploit/blob/master/xploitGitlistMooc.py

El mini-exploit bastante simple, pero efectivo, me permitió obtener 8 archivos de 4 equipos diferentes en 19 minutos. Lamentablemente estaban repetidos, Manuel obtuvo los mismos archivos el día anterior.

Si analizamos un poco el código, notamos que la shell remota es colocada en /gitlist/cache/git.ignore.php, así que para acceder a ella la URL sería algo como

http://victima.com/gitlist/cache/git.ignore.php?cmd=ls

El presunto infiltrado

Desde que se creó el equipo uno de los integrantes mostró interés en usar técnicas de ingeniería social, infiltrarse en otros grupos para obtener información desde dentro de los mismos. Dichas técnicas no fueron aprobadas por el Consejo Jedi. Desde ese momento dicho participante se me hacía digamos que sospechoso.

Mis sospechas aumentaron cuando estando ya en pleno reto, ese integrante hizo una publicación en el grupo de #comunidadMOOCHackingMU preguntando si alguien lo aceptaba en su equipo, situación que le comenté a Javier (representante del equipo en el Consejo), quien solo se limitó a recordarme que era el que quería usar ingeniería social y que dicha técnica no la aprobó el Consejo.

Infiltrado?

Infiltrado?

Días después Manuel cometió un error, una novatada, como decimos en México: publicó en nuestro grupo de Facebook los archivos obtenidos de otros servidores. Quizá él lo hizo con la mejor intención, quizás quería animar a los demás a comenzar a participar (ya que hasta ese momento seguían sin dar señales de vida). Pero a las pocas horas de que hizo la publicación, el integrante sospechoso abandonó el grupo.

Manuel y yo llegamos a la conclusión de que era un infiltrado, obtuvo nuestros archivos y los llevó a su otro equipo, así ya no gastarían tiempo en intentar obtenerlos.

Por último: Lo bueno, lo malo y lo feo

  • Lo bueno: Puede darme cuenta de como es realmente un ataque a las aplicaciones Web, planeé la defensa desde cero y llevé a cabo un plan -espero que exitoso- de defensa. Conocí parte de las etapas de un ataque: la planeación (inteligencia) y la puesta en marcha del mismo (delivering).
  • Lo malo: La poca participación del que fue mi equipo. Me atrevo a decir que de 8 integrantes, 5 no nos apoyaron, 1 era infiltrado y sólo 2 llevamos a cabo el reto.
  • Lo feo: Muchos equipos hicieron trampa: Servicios abajo, infiltrados, y ataques automatizados estaban a la orden del día.
Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s