viernes, 17 de octubre de 2008

I have the reason (Artica case)

Esta entrada en el blog tiene dos motivos:

1. Recordarme que aveces me da por alegar por pura terquedad.

2. Que cuando se reporta un bug hay de respuestas a respuestas, esta me parecio muy divertida.


El caso es que en la empresa estamos trabajando con una solución llamada artica, la cúal entre muchas cosas integra un sistema de correo con todos los juguetes.

Bueno, el caso es que me puse a mirar un poco los archivos del software y me encontre con uno muy especial llamado: upload.php.

Cuando lo abrí me di cuenta que precisamente era eso, un uploader, lo malo del asunto es que permitia subir archivos a la plataforma y lo segundo mas malo es que en ningun lado se hablaba de el. Como un adulto responsable le escribí al desarrollador principal de artica y para no postear los emails, resumo lo sucedido:

yo:
Que tal dev, me parece que este archivo no deberia estar aqui, se les olvido quitarlo o es un bug?, me podrias confirmar? (siempre pido una confirmación para no sentirme tan loco).

dev:
Querido amigo, te cuento que eso es un archivo viejo que usaba para hacer pruebas, no te preocupes borralo y todo estará bien.

yo:
Hola!, si, yo se que si lo elimino todo estará bien, pero que pasa con las otras personas que no lo han visto?, existe algun archivo README, INSTALL donde lo mencionen?

dev:
NO, no se preocupe, eso ya desaparecio en versiones anteriores, relajese, tomese un tinto, no es para tanto.

yo:
no, no, no, no me entiendes, quiero una respuesta clara, quiero saber que es lo que pasa, acabo de bajar la última versión de artica (artica-postfix-1.2.101718.deb) para debian y el archivo sigue allí. Entonces eso significa que las personas que usen artica sobre debian son vulnerables?, existe algun archivo donde se mencione esto?, deberia haber una advertencia.

dev: (un poco mas alterado)
Que no ohme, seguro cuando hiciste una actualización el archivo se mantuvo ahí y por eso crees que lo estas instalando. Solo borralo y olvida el asunto.

yo:
Hola!, ya realize una instalación desde cero y el archivo apareció :)
nando:/home/nando/Desktop# ls -la /usr/share/artica-postfix/upload.php
-rw-r--r-- 1 root root 713 oct 17 11:13 /usr/share/artica-postfix/upload.php
nando:/home/nando/Desktop#

dev: ...

Como el asunto no podia quedar ahí entre al foro público de artica y publique una entrada, la cual el mismo desarrollador contesto e inmediatamente cerro el topic.
Para mi ya era el colmo, no me daba explicaciones y se hacia el loco con el tema.

Entonces abrí un segundo tema y le dije que pilas, que las cosas no eran así y realmente las comunidades de software libre no funcionan así. Ocultar las cosas no es una buena politica.

El desarrollador muy amablemente devolvio a la vida mi topic y me escribio un último correo diciendome: "Yes you right my script do incremental copies when creating deb packages so it still exists. It is fixed for next version...."

Mi respuesta fue:
...


Y ahi termina la historia.

Seguramente NO se lanzará un advisory acerca de esto y seguramente algunas cuantas maquinas corriendo artica serán atacadas, pero cumpli con hacer mi parte.

Aveces la neglicencia o el simple hecho de no reconocer que se comete un error, hacen que los procesos en comunidad no evolucionen de la mejor forma. Si el desarrollador se hubiera portado mejor, seguro me hubiera motivado a entregarle otros bugs mas interesantes, pero por ahora dejemoslo ahí.

Byte.

martes, 14 de octubre de 2008

! A Crazy WARGAME !

Note: Todo lo que expongo aquí es de manera personal y es producto solo de la frustración de querer divertirme y no poder hacerlo. :p

Todo el mundo conoce lo que son los wargames, que son de varios estilos, que pueden haber wargames de programación, de redes, de seguridad y de cualquier otra cosa, pero casi siempre el enfoque es seguridad informática ó hacking.


El pasado puente se realizó un congreso en Cartagena, donde se presentó un reto informático.

Como siempre la idea es ganar o al menos entender de lo que se trataba y entender como se resuelve. Esta vez, ni lo uno, ni lo otro.


Jugué con un par de amigos de la comunidad dragonjar, pues a través de ellos pude conseguir la entrada (gracias 4v4t4r).

Los objetivos de un wargame casi siempre están claros, lo que casi nunca se expone es el COMO hacerlo, que ahí es donde entra en juego las habilidades de los jugadores. En este wargame no teniamos ninguna de las dos cosas, solo teníamos un poco de información de lo que se trataba.


Entonces el asunto fue algo complicado...

Recursos:
SIN acceso a Internet + Conocimientos propios + Tools y Laptops.

Objetivo:
Penetrar una red wifi conocida (WEP, WPA2), Hacer un deface (en algún lugar, en algún S.O.) y cambiar datos en una base de datos (alguna base de datos, en algún lugar).

Como ven, teníamos algunas limitaciones, pero después de pensarlo mucho, este juego termino por gustarme, ya que me da ideas para cuando programe mis propios wargames y me hace reflexionar acerca de la mente de un atacante.

///////////////

Al inicio del juego no sabíamos por donde empezar y quizás nunca tuvimos la orientación de lo que queríamos encontrar exactamente, esto debe ser lo que siente un script kidie, cuando quiere "hackear" algo, pero finalmente no sabe que o para que.

Es muy diferente a la mentalidad de un atacante con un objetivo fijo donde dice: Voy por una base de datos de usuarios que esta en X maquina y listo, enfoca sus esfuerzos a lograrlo.

Aunque teníamos un QUE, no sabíamos exactamente donde se desarrollaria el Juego.

Después de la charla del ponente que realizó el montaje del wargame, entendimos que su mentalidad era algo diferente, quizás no quería organizar un reto "ganable" o quizás quería demostrar lo bueno que es configurando una red segura.

El punto en cuestión y con lo que no estuve de acuerdo fue cuando mencionó que este wargame estaba diseñado basado en el mundo real, algo que me parecío muy ilógico de lo que había podido analizar hasta ese momento, en fin, el asunto no es criticar, ni decir que estuvo bien o no bien hecho. El asunto es analizar que un reto de estos en un congreso debería estar orientado a motivar a los asistentes para que practiquen y desarrollen habilidades y no a demostrar que tan buenos pueden ser unos productos o que tan "tesos" son los que los implementan.

Jugando el wargame a ciegas ...

1. WEP y WPA


El punto de inicio era fácil, había que romper una llave WEP o WPA para ingresar a la red del juego, sus SSID: e-byte y e-byte2.

Ya todos sabemos las herramientas que existen para crackear llaves, pero también sabemos que estas técnicas tienen limitaciones como por ejemplo el trafico que debe existir en los AP para que la inyección de datos sea efectiva ...

El punto en contra era que ninguno de los dos AP's tenia tráfico inicialmente y encima, tenían instalado un sistema que "baneaba" intentos fallidos, escaneos y etc. Los productos son de aruba, me imagino que en producción deben ser muy buenos, pero son necesarios para un wargame?

Intentamos varias técnicas para conseguir el acceso a los AP.

Acceso físico
  • Intentamos acceder físicamente a los equipos del reto, suponiendo que estaban en un cuarto de operaciones cercano al lugar del evento, pero no fue posible, puesto que estaba todo el tiempo con personas. (el disfraz de camarera no funciono!, tampoco el de señora del aseo)

  • Intentamos desconectar un AP en producción para ubicarlo en nuestro switch, pero el único cable de red que llevábamos no funcionó, luego pensamos en desconectar el AP pero desconectaríamos muchos usuarios reales y esto llamaría la atención.

Ingeniería social
  • Rastreamos el mejor lugar con señal para ubicarnos en este y así tener mas posibilidades, al mismo tiempo el ubicarnos en un mismo lugar, hace que el resto de competidores se sientan intimidados y se ubiquen en lugares aparte, normalmente al otro extremo , lo que les dificulta la conexión para ellos.
  • Intentamos hacer ingeniería social con organizadores y ponentes, pero ninguno tenia información técnica del montaje, sin embargo la información que nos brindaron no solo nos desviaron a nosotros, si no a todos los participantes.

  • Usar camisetas puede parecer un poco lammer, pero dependiendo del escenario logra que las personas se predispongan y por lo tanto muchos ni siquiera intenten jugar ;)

Finalmente encontramos la WEP ...

Un punto para el wargame fue que ambas redes WEP y WPA accedían al mismo lugar, entonces intentar romper las dos era perdida de tiempo, pero nunca nadie dijo que este era el escenario, me parece chevere esta implementación, dos accesos que van al mismo lugar dividen los esfuerzos (:p), pero para mi, no es un escenario real.

Al finalizar hablamos con el ponente y nos contó que la llave WPA era algo como:

"%&@·1234567"

Por lo que con HANDSHAKE o sin HANDSHAKE, esa clave nunca se hubiera podido romper.

Obviamente el HADSHAKE nunca se obtuvo, porque nunca se conecto un solo cliente.

Pretendían que rompiéramos WPA2 en día y medio sin conexión a Internet? ;)

2. MAPEANDO, ENUMERACIÓN, SCANNING


Ya dentro de la red sacamos la info que pudimos, vimos algunos equipos conectados y nos dimos cuenta que teníamos asignada una dirección dinámica pero que el gateway no respondía y el mismo gateway era el servidor DNS.

Al principio pensábamos que esa maquina era ficticia, después tendríamos la respuesta.
Escaneamos el resto de las maquinas, todas aparecían con los mismos puertos: 80, 3128, 8080, 8888 y dos de ellas con los puertos de VPN. El problema era que todos los puertos respondían de la misma forma, porque tenían TCPWRAPPERS y ademas cada host tenia un portal cautivo que nunca supimos cual era, o como pasarlo, pues redireccionaba a un mensaje de error de acceso administrativo.

Ahí fue cuando empezamos a llorar... (lol)

Hablando con el ponente, nos explico que en la red donde estabamos habian varios equipos y que podía haber un filtro y un sistema IDS en appliance y ademas un sonicwall antiTODO, pero que si no podíamos pasar eso, entonces él con gusto bajaría el nivel del reto retirando algunos equipos (routers, switchs, appliances).

Agrrrrr... :S

Vuelve y juega la pregunta,

¿La idea era que jugáramos o que viéramos que la implementación era excelente ?
¿Lo era ?

En este punto ya se habían retirado el 98% de los participantes, primero porque no habían podido romper las llaves y segundo, porque sospechaban lo que les esperaba.

Hasta ahí llevábamos el primer punto, entonces decidimos crear un documento y entregarlo por si las moscas. De todos modos seguimos jugando.

Mas adelante el ponente nos contó que lo que pasaba era que tenia un port knocker y que por eso no veíamos nada abierto, entonces intentamos pasar el port knocker pero la secuencia de puertos nunca la supimos y a la pregunta de cual era el cliente para pasarla, nos contesto que el cliente estaba en un archivo en alguna otra de las maquinas, que tenia un nombre raro y concluimos que esas maquinas estaban filtradas con el portal cautivo y de esa forma NUNCA íbamos a poder encontrar los tales archivos clientes.

Para los que entienden del tema, saben que hay scanners que se basan en bases de datos para enumerar directorios y archivos de un servidor web, pero para que sea efectivo el ataque con algo así se requiere:

a. TENER EL PUERTO ESCUCHANDO (no lo teníamos TCPWRAPPERS + PORTAL CAPTIVO)
b. QUE EL NOMBRE BUSCADO ESTE EN LA BD
(no lo creo, el archivo deberia tener una combinación alfa numérica imposible)

3. DIA DE LA DECEPCIÓN ...


Ya cansados de pelear y sin tocar mar por culpa del juego, decidimos esperar las conclusiones.

El ponente explico de una forma muy elocuente el reto, pero nunca respondió técnicamente al COMO pasarlas, pero lo que dejo ver es que todo debía llegar por iluminación, y nosotros aún no llegamos hasta allá :P

La respuesta era algo como: "A uno se le ocurre que la maquina 172.16.55.8 esta en la VLAN 230 ..."

Y estos fueron los tips para pasar el reto:

Jajaja, yo trate de entenderlo un poco más.

Aquí va:

COMO RESOLVER EL RETO INFORMÁTICO - CARTAGENA 2008

1. Crackear una llave WEP o WPA2, cualquiera de las dos lo llevan al mismo lugar, pero tenga en cuenta que no hay clientes en los AP.

2. Una vez adentro, mapear la red, pero todo el tráfico ICMP estaba filtrado, por lo tanto nunca se sabia si estaban activos o no los equipos, el uso de sniffers era obligatorio, pero para ver el trafico, había que envenenar el switch y luego ADIVINAR que la IP 192.168.1.10 (corriendo IPCOP) tenia un servidor portknocker, por lo tanto no se pueden ver los servicios, la solución es encontrar un archivo de configuración cliente en algún lugar de la red y luego descifrarlo para poderlo usar.

El archivo al parecer estaba en la maquina 192.168.1.100 (se obtiene por adivinación), pero para poder alcanzar el archivo tendríamos que hacer spoofing de direcciones IP y luego pasarnos la seguridad de un portal captivo (quizas clonando la MAC) y cuando ya pudíeramos entrar al servidor ADIVINAR el nombre del archivo y la extensión que este usaba.

Después era muy fácil, solo descargarlo, si es que el IPS no lo filtraba. Existen muchísimas soluciones de port knocking, sin Internet es complicado apuntarle a una.

3. Cuando tuviéramos acceso a la maquina .10, teníamos que escanearla y encontrar que estaba abierto el puerto 2000, aunque apareciera filtrado, y luego deducir que ese 2000 era realmente una pasarela (forwarding) para el otro lado B del juego.

Al entrar al lado B, teniamos que caer en cuenta que estabamos en una VLAN con un switch 3com (quitaron el switch cisco) que no tenia IP administrativa, pero de todos modos debíamos hackear el switch o reprogramarle un firmware usando el protocolo TFTP.

El problema es que el acceso desde el TFTP solo se permitia desde una maquina confiable protegida por un Firewall, por lo tanto habia que penetrar esta maquina para poder montarle una imagen y luego hacer que el switch la descargará. (Obviamente habia que saltarse el portal captivo para atacar la maquina ). Pero fácil, ahí estariamos en el switch, supongo que con clave by default. (lol)

Una vez en el switch tendriamos que cambiarnos a una VLAN donde estuvieran los servidores a comprometer .

4. Una vez conectados en la VLAN correcta debíamos escanear las maquinas y encontrar que tenian plugines/ejemplos de tomcat vulnerables, los cuales debíamos explotar y de esa forma tener acceso a la maquina, ya estando allí solo tendríamos que hacer el deface. Y listo, el reto dos estaría cumplido.

5. Luego debíamos pasarnos de VLAN y escanear la red por otro equipo, pasarnos la protección del firewall y entrar a la BD que era MySQL, cambiar los registros correctos y listo, el primer puesto seria nuestro.

Eso fue lo que entendí del reto, de lo que teníamos que hacer, le agradezco a los que montaron este wargame porque me abrió los ojos, porque si hay alguien que para prevenir un deface se tome esas molestias, entonces de seguridad yo no se nada :P

Como vieron era un reto que mezclaba un poco de todo, yo creo que es viable ganarlo, siempre y cuando tengamos unos 15 días para jugar y no 1 día y medio como estaba planteado.
¿Lo que me dejó preocupado es que si ese es un ambiente real entonces que es esto un día despues del congreso?, ¿no importa un deface in the real, real life ?
(Empresa que colaboró en el montaje del wargame - donado por un usuario anónimo)

PD1: Todas las gráficas que aparecen fueron del cierre del juego, NO antes de empezarlo. Las conclusiones que saco son mias y son hipoteticas, puedo estar equivocado, pero es lo que concluí después de escuchar al ponente y de todo lo que analizamos.

PD2: hackerslab, pulltheplug, ngsec, boinasnegras, hasta el reto de la campus se quedo en palotes!

PD3: De todos modos GANAMOS, nos premiaron (a la perseverancia? ), invitación a próximos congresos y la fiesta en Mr. Babilla.

PD4: Me falto contarles que el lado A y el lado B del reto se conectaban usando protocolos X10 que transmiten sobre el cableado eléctrico. la respuesta del ponente a mi sorpresa fué:

" Ah!, no lo vieron?, el tráfico por ahí estaba desencriptado, podían haberlo esnifeado!".

Lastima que no lleve mi plugin de wireshark para X10 y menos el conversor de 110V para el Assus! :P
Sean Legales !!


Como mi hermana ...

Entradas populares