#Rooted2011 – Día 2 + Día 3
El segundo y tercer día de la Rooted ha tenido de todo. Herramientas, técnicas, ideas, resultados e incluso un pequeño laboratorio, veamos:
- Raúl Siles nos presentó su propuesta para renombrar los conocidos XSS, WCI. Además nos mostró como se enfada la vaca de BeEf.
- Jaime Peñalba nos mostró las bondades de los WarGame. Como las protecciones y normas.
- Sergi Álvarez y Roi Martín presentaron Radare2. La cantidad de funcionalidades y opciones de esta herramienta hicieron que los 50 minutos de charla se quedaran realmente cortos.
- Deloitte, como patrocinador, no quiso quedarse atrás y mostró como con poco dinero y algo más de tiempo podemos ver lo que otros ven gracias al maravilloso mundo de las "ondas".
- Chema Alonso y Alejandro Martín presentaron DUST. Desde aquí os animamos a probarlo y a contribuir enla medida de lo posible. Más información en el lado del mal.
- Alejandro Ramos sabe muy bien que hacer con una buena tarjeta gráfica sin necesidad de utilizar ningún juego.
- Eloi Sanfelix mostró lo "indie" que puede llegar a ser el hacking que realiza sobre hardware.
- José Ramón Palanco con NoSQL Security. [Iniqua FAIL] Por desgracia no pudimos asistir... esperamos los videos!
- David Pérez y José Pico nos mostraron un trailer de su Lab, y en 50 minutos pudimos ver como una llamada al servicio de atención al cliente de un banco se convertía en una llamada al "infierno" (los videos van a ser muy divertidos).
- Joxean Koret nos enseñó la poca seguridad de los sgbd y animó a los asistentes a interesarse por ellos. Unos resultados llamativos...
- Vins Villaplana nos llevó de la mano por la capa 2. Menos mal que alguien se acordó un poco más de las redes y los protocolos... entre tanto malware.
- Gabriel Gonzalez nos mostró su idea titulada Man in Remote. Y que a pesar de parecer del lado oscuro, no es más que una solución para poder gestionar a cualquier otra persona su DNIe
. - Hernan Ochoa nos mostró todo el trabajo realizado para completar su herramienta: WCE v1.0
- [::RF::] mostró algunas ideas que necesitan tu ayuda...
- Marisol Salanova puso la nota discordante y desconectó al público de los ceros y los unos. Interesante viaje por la intimidad pública disponible en la red.
- Rubén Santamarta cerró el congreso mostrando como realizar un "hipotético" ataque sobre sistemas SCADA. Todo un mundo por descubrir...
Nosotros nos quedamos de estas magnificas conferencias, con lo aportado por los ponentes, con las herramientas que nos han presentado y también con la sensación que en la Rooted hasta los patrocinadores asustan con el nivel mostrado. Por todo ello agradecemos a los organizadores que hacen posible el congreso.
¡Nos vemos el año que viene!
#rooted2012
#Rooted2011 – Día 1
El primer día de la Rooted2011 ha tenido de todo... La mañana comenzaba asimétrica, con Antonio Ramos haciendo de David Copperfield (no te pierdas los videos) con un juguete de Gianluca. Menos mal que D'Antonio ha sabido gestionarlo con "seguridad".
¿Te has planteado alguna vez hasta que extremos llega el gobierno Chino? Hoy Jaime Blasco y Pablo Rincón nos han dado muchas pistas, o mejor dicho, evidencias.
Y ahora que lo pienso... ¿Qué hay detrás de la creación de malware? Alberto García de Dios ha dado buena cuenta de este tema... y nos ha dado buenos consejos.
Bueno, menos mal que nosotros no somos de ejecutar cualquier cosa en nuestro PC, como mucho me fio de los PDFs... "Zás, en toda la boca" Jose Miguel Esparza y su peepdf no opinan lo mismo.
No pasa nada, me acabo de crear una cuenta sin privilegios, aunque puedan entrar no van a poder buscarme las cosquillas... José Selvi dice: "Pivoting".
Pero si me pasa algo... la justicia está de mi lado, ¿verdad Jacobo (y su iPrueba)?.
De todas formas, da un poco igual... porque no creo que alguien de dedique a escanear IPs a diestro y siniestro... ups! Global Warfare!! Prefiero no mirar...
¡Felicidades a todos!
UPDATE: Olvidé comentar a los ponentes invitados de los patrocinadores... lo siento!. Tanto por la presentación de la herramienta de Blueliv, especialmente interesante desde mi punto de vista, y con un interfaz de usuario muy interesante. Y por la presentación de Leonardo Amor... gracias a él al llegar a mi casa busqué la IP del espejo del baño.
Por último, agradecer a todos los que nos habeis felicitado por la ponencia (Cloud Malware Distribution) y hacer transmitir la satisfacción de compartir hoy el escenario con estos magnificos ponentes... y lo mejor de todo es lo que nos queda.
Saludos y hasta mañana.
Optimizar entornos de virtualización
Problemática con los sistemas de escritorio 
Los que solemos trabajar de forma más o menos habitual con entornos virtualizados necesitamos una cierta fluidez con estos sistemas, sino el trabajo se puede convertir en un tedio inaguantable.
Los nuevos entornos GNU/Linux de escritorio, como Ubuntu Desktop por ejemplo, vienen preparados para causar al usuario doméstico la mejor percepción de interactividad posible, con un tiempo de respuesta muy pequeño: los programas se abren muy rápido, el cambio de ventanas es instantáneo, trabajar con documentos es bastante fluido, etc. Aunque este comportamiento es perfecto para el uso cotidiano de cualquier usuario normal, puede que no lo sea tanto cuando queramos realizar otros menesteres.
Solución
Usando entornos virtualizados nuestro comportamiento se aproxima más a como trabaja un servidor. Pero, ¿Cuál es la diferencia? La mayor radica en el kernel del sistema operativo. Uno está ajustado para dar una respuesta al usuario lo antes posible (sistema de escritorio) y otro para balancear la carga de manera más equitativa entre todos sus procesos para conseguir un equilibrio (sistema servidor). Esto es debido al planificador de CPU utilizado por cada uno: CFQ y DeadLine respectivamente.
Conocida la teoría, ¿cómo podríamos cambiar el modelo de comportamiento al de un servidor? De una manera muy sencilla. Cambiaremos el kernel estándar por el de servidor. En Ubuntu tan solo tendremos que hacer lo siguiente:
sudo aptitude install linux-server
Con esto instalamos el nuevo kernel y todas las librerías necesarias. También ejecutará dkms para reajustar los módulos que ya tuviéramos en el sistema.
Si utilizamos VirtualBox necesitamos indicarle que hemos cambiado el kernel para que los adapte al nuevo núcleo:
sudo /etc/init.d/vboxdrv setup
Impresiones personales
Como puntilla, la impresiones personales:
En un PC portátil normal (procesador de doble núcleo (P8500) y 2 GB de RAM) antes de aplicar el kernel tipo servidor un maquina virtualizada hacía que no fueran bien ni el sistema virtual ni el físico, sin abrir prácticamente ninguna aplicación en sistema anfitrión. Después, tras en el cambio, el PC puede sin problemas con gestor de correo, varias instancias del navegador web, del Libre Office, terminales, el Wireshark y 2 maquinas virtuales corriendo!!!!
Si alguno probáis el cambio esperamos compartáis vuestras impresiones.
Uso de Payloads con Unicornscan
Como muchos de vosotros ya sabréis, los escaneos de red de tipo UDP tienen varios inconvenientes.
Debido a las características del propio protocolo UDP, aunque un servicio esté activo y escuchando en una máquina en un determinado puerto, esta máquina no contestará a un mensaje UDP si no tiene el formato esperado por el servicio que está a la escucha. Esto no siempre es así, pero la mayoría de las veces, los servicios no contestarán si no hablas con ellos de la forma esperan.
Por este motivo, puede resultar útil que durante un escaneo UDP, nuestra herramienta nos permita enviar un determinado payload de un servicio que conozcamos.
En este caso, trataremos de descubrir un servicio de Voz IP escuchando en el puerto UDP 5070.
Para ello utilizamos la herramienta Unicornscan.
- Paso 1:
Copiamos un payload de SIP de una captura cualquiera (si no la tenemos podremos recurrir a pcapr).
- Paso 2:
Mediante la herramienta awk podemos modificar el texto obtenido para darle el formato esperado. Por ejemplo, si tenemos en el fichero "payload_sip" el contenido capturado, podemos hacer:
cat payload_sip | awk '{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6"\\x"$7"\\x"$8"\\x"$9"\\x"$10"\\x"$11"\\x"$12"\\x"$13"\\x"$14"\\x"$15"\\x"$16"\\x"$17}' >> payload_sip2
cat payload_sip2 | awk '{print "\""$1"\""}' > payload_sip
(Seguro que hay métodos más puristas, lo sé J)
- Paso 3:
Añadimos en el fichero de configuración del Unicornscan nuestro payload para el puerto que queramos. Editamos el fichero /etc/unicornscan/payloads.conf y añadimos nuestra información.
La sintaxis utilizada es la siguiente:
/* Comentario */
udp puerto -1 1 {
"payload_a_añadir---"
};
Donde "-1" hace referencia al puerto origen a utilizar al enviar el paquete UDP. Con "-1" le decimos que puede utilizar cualquier puerto origen. El siguiente "1" es el grupo del payload.
Si quisiéramos descubrir un servicio activo de VoIP en un sistema, pero no conocemos el puerto en el que escucha, podríamos modificar el fichero payloads.conf y modificar la sección:
udp -1 -1 1 {
"nuestro_payload"
};
De esta forma, siempre enviará el mismo payload para el rango de puerto que le indiquemos.
- Paso 4:
Probar si funciona:
Antes:
Después:
Pues parece que sí funciona.
La forma de hacerlo con nmap, para la próxima
Saludos.