Pepelux

blog

Entradas con la etiqueta Hacking

RootedCon CTF writeup niveles 5 y 6

abr 4

Publicado por Pepelux en Hacking, Retos hacking, Rooted2011 | 2 Comentarios

Esta vez voy a subir la solución de dos retos en lugar de uno sólo, ya que el nivel 5 es fácil fácil (el más fácil de todo el CTF) … como dijo Pablo Catalina, este venía de regalo xDD

Reto 5

Para este reto tenemos que continuar por donde dejamos el anterior, como viene siendo habitual. Así que vamos a ver lo que trae esa imagen de disco:

Tras abrir el CAP con el wireshark vemos que tiene toda la pinta de ser una captura de una red wifi con encriptación WEP:

Por tanto, vamos a lanzar el aircrack-ng a ver si sacamos la clave:

Como se puede ver, la clave es: 01:01:01:01:01:01:01:01:01:01:01:01:01

Y la contraseña para pasar el reto: 01010101010101010101010101

Reto 6

Ya que tenemos la clave WEP (que por cierto, era de lo más sencilla), vamos a obtener el paquete sin cifrar:

Esto nos genera un nuevo fichero, ya descifrado (captura1-01-dec.cap) con 75.325 paquetes, nada menos. Lo abrimos con Wireshark y vemos que hay muchísimos paquetes TCP con basura (SYN, ACK, RST) pero ningún PSH con información útil. Esto supongo que lo harían para generar algo de tráfico y hacer efectivo un ataque con Aircrack-ng y así poder sacar fácilmente la clave WEP, por lo que vamos a aplicar algunos filtros que nos limpien un poco la basura:

Filtro: tcp.flags.push==1

0 resultados

Como comentaba antes, todos los paquetes TCP están de relleno, así que vamos a quitarlos, junto con los ARP e ICMP:

Filtro: !arp && !icmp && !tcp

17.075 resultados

Siguen apareciendo demasiados paquetes, pero ahora vemos algunas cosas interesantes. Parece que hay capturas de VoIP, así que vamos a filtrar esas capturas:

Filtro: ip.src eq 172.23.0.9 || ip.dst eq 172.23.0.9

Bien, pues parece que tenemos un bonito Asterisk tras todas esas tramas de datos y, como Wireshark trae una herramienta muy buena para VoIP, vamos a usarla. Entramos en Telephony -> VoIP Calls:

Tras escuchar cada una de las conversaciones repetidas veces, me quedo con los siguientes detalles:

  1. Alguien llama a un buzón de voz para escuchar los mensajes. Tenemos los sonidos de dos pines que se introducen.
  2. Parece que dejan el número de teléfono que buscamos en un buzón de voz y no se escucha en las conversaciones de voz capturadas.

——————————

Nota: Yo me quedé aquí en este punto cuando el CTF llegó a su fin. El resto de retos los hice ya desde casa, relajado en una buena silla :)

Me quedé atascado porque no le encontré mucho sentido a lo que estaba pasando, es decir, el mensaje decía algo como: ‘… llámame al número de teléfono’ y se cortaba. Luego veremos que el resto del mensaje está en el buzón de voz. La verdad es que no entiendo cómo si alguien deja un mensaje en un buzón de voz, se captura una parte sólo de ese mensaje, pues debería o capturarse todo o no capturarse nada.

Esto me llevó a pensar que era un problema de ruido, así que me dediqué a descargar las voces, convertirlas a WAV y perder mucho tiempo con el Audacity.

——————————

Bien, pues continuando con el reto, parece ser que tenemos que acceder al buzón de voz del usuario para escuchar el número de teléfono que deja como mensaje. Para poder acceder al buzón de un usuario necesitamos 2 cosas. Los datos del usuario (incluida su contraseña) y su PIN. Vamos con ello:

Para extraer los datos del usuario usamos sipdump y sipcrack:

Tras pasar varios diccionarios obtuve las claves de ambos usuarios, que son:

Para el user 1001: 0000aa

Para el user 1002: aa0000

Nota: las claves para cada usuario son las mismas a pesar de tener diferente hash, lo cual nos indica que el MD5 usa algún salt.

Para averiguar el PIN, primero extraemos las voces. En el Wireshark vamos a Telephony -> RTP -> Show All Streams. Luego seleccionamos el paquete y damos a Analyze. Después, Save Payload y guardamos con formato AU.

Abrimos con el Audacity y recortamos la parte que nos interesa:

Una vez que hemos recortado los 2 pines que hemos encontrado, los desciframos con Multimon (click para agrandar la imagen):

El pin de pownme es: 987321

El pin de lamde es: 123654

El siguiente paso es conseguir un software para conectar con el Asterisk. Vamos a usar para ello el Twinkle, que está en el repositorio de Debian.

Si te atascas instalándolo, aquí hay un bonito tutorial:

http://openmaniak.com/trixbox_phone.php#twinkle

Nos conectamos a ambos buzones y en el de lamde escuchamos el número de teléfono que buscábamos y que es la clave para pasar al siguiente reto: 666.699.004


Etiquetas: , , , , ,

RootedCon CTF writeup nivel 4

abr 1

Publicado por Pepelux en Hacking, Retos hacking, Rooted2011 | No hay comentarios

Reto 4

Accedemos ahora a la shell de este usuario (pownme) con un su, o simplemente haciendo otra conexión por ssh:

Y vemos lo que tiene en su directorio y a lo que no teníamos acceso:

El fichero comprimido, que descargamos con un scp desde nuestra máquina, parece tener una imagen de un disco que ha sido cifrada con LUKS usando SHA256. Esto lo vemos haciendo un head del fichero o abriéndolo con un editor hexadecimal.

Según la Wikipedia (http://es.wikipedia.org/wiki/LUKS):

——————–

LUKS (de las siglas en inglés, Linux Unified Key Setup) es una especificación de cifrado de disco creado por Clemens Fruhwirth, originalmente destinado para Linux. Mientras la mayoría del software de cifrado de discos implementan diferentes e incompatibles formatos no documentados, LUKS especifica un formato estándar en disco, independiente de plataforma, para usar en varias herramientas. Esto no sólo facilita la compatibilidad y la interoperabilidad entre los diferentes programas, sino que también garantiza que todas ellas implementen gestión de contraseñas en un lugar seguro y de manera documentada.

La implementación de referencia funciona en Linux y se basa en una versión mejorada de cryptsetup, utilizando dm-crypt como la interfaz de cifrado de disco. En Microsoft Windows, los discos cifrados con LUKS pueden ser utilizados con FreeOTFE. Ha sido diseñado para ajustarse a la clave de configuración TKS1 de sistema seguro.

——————–

Pues vamos a tratar de montar esa imagen, de la que por cierto, no tenemos la contraseña ….

Yo nunca había encriptado una unidad por lo que tras documentarme en Google, al final hice:

Una vez tenemos los módulos de crypt, vamos a tratar de montar la imagen. Para ello usaremos loop, que asigna una imagen a un dispositivo, lo que nos permitirá tratarlo como una unidad.

Para ver el primer dispositivo loop libre:

Para usar el dispositivo (con esto asociamos /dev/loop0 con nuestra imagen):

Luego tratamos de montar la imagen (si fuera una imagen normal usaríamos el comando mount, pero al tratarse de un LUKS, debemos usar cryptsetup):

Parece que la imagen está dañada ya que no la reconoce como LUKS. Tras buscar información sobre el formato y compararla con nuestra imagen, vemos claramente que hay una serie de ceros en la cabecera (antes de la palabra LUKS) que no deberían estar, por lo que hacemos una copia de la imagen (por si las moscas) y modificamos esta quitando todos esos ceros:

Para probarlo, desasociamos el dispositivo y lo volvemos a asociar:

Bueno, pues parece que ya tenemos resuelto el primer problema. Ahora queda averiguar cuál es la contraseña. Para ello me creé un pequeño script en Perl:

Lo que hace este script es probar las palabras de un diccionario, parando si consigue montar la unidad. Para ello:

  1. Cargamos el diccionario.
  2. Ejecutamos con un system el cryptsetup usando un pipe y así no tener que meter la contraseña escribiéndola desde la línea de comandos.
  3. Miramos en /dev/mapper si se ha montado el dispositivo, tras lo cual paramos el script y mostramos la última contraseña que se probó, que deberá ser la buena.

Tras unos minutos corriendo con un diccionario de palabras comunes, obtenemos la contraseña, que es: key y que nos sirve para pasar al reto siguiente.

Etiquetas: , , , ,

RootedCon CTF writeup nivel 3

mar 25

Publicado por Pepelux en Hacking, Retos hacking, Rooted2011 | 1 Comentario

Reto 3

Como vimos en el reto anterior, tenemos corriendo un knockd que nos abre un ssh en el puerto 22.

Si no sabes lo que es el port knocking puedes ver cómo funciona aquí: http://es.wikipedia.org/wiki/Golpeo_de_puertos

Como resumen, diré que se trata de un mecanismo de seguridad que oculta ciertos servicios y los abre recibiendo una secuencia mágica de números.

En este caso, todos los puertos que espera knockd son TCP, por lo que para que nos de acceso, le mandaremos la secuencia mágica, para posteriormente conectarnos por ssh:

Accedemos con nuestro usuario y contraseña:

Y analizamos un poco el entorno.

En nuestro directorio no vemos nada de utilidad pero si retrocedemos un directorio, en /home/ hay un segundo usuario cuyo nombre nos incita a entrar :) … su nombre es: pownme

Así que accedemos a su carpeta personal y hacemos un ls -la para ver lo que hay dentro:

Aquí vemos varias cosas interesantes:

  • Un binario que podemos ejecutar con suid de pownme.
  • Un fichero de configuración al que no tenemos acceso.
  • Otro fichero comprimido al que tampoco tenemos acceso.

Todo apunta a que hay que hacer una escalada de privilegios para llegar a ver el contenido de ese fichero comprimido, así que vamos a ver qué hace el binario:

Bueno, pues está claro que se trata de un overflow. Llegados a este punto necesitamos obtener algo de información para ver con qué nos enfrentamos, si tenemos que crear un exploit o simplemente hay que machacar algún dato.

Sacamos algo de información del sistema:

A primera vista ya nos encontramos con varios problemas:

  • Por un lado se trata de una arquitectura de 64 bits.
  • Por otro lado, tenemos activado el randomize_va_space.
  • El binario no tiene permisos de lectura, por lo que no podemos descargarlo a nuestra máquina y usar luego el EDB, IDA Pro o nuestro debugger favorito.
  • No hay ningún depurador instalado en la máquina, por lo que tampoco podemos depurar ahí.

Llegados a este punto sólo nos queda probar a mano:

Tras realizar varias pruebas al final vemos algo interesante introduciendo el usuario seguido de diferentes \x01:

Vemos que ya no da error de permisos pero tampoco saca los datos completos. Así que vamos a probar con \x02:

Y ya, por curiosidad, si ponemos un \x03:

Pues parece hemos sobrescrito en número de líneas a imprimir, a parte de otra cosa, que nos permite ver los datos de otro usuario.

Introducimos el usuario y la contraseña obtenida para pasar el reto: pownme:c@r@m3l0_0.o

———————————————————————————-

Nota: La verdad es que no comprendí muy bien cómo pasé el reto ya que fui probando bytes hasta que ‘de casualidad’ me apareció la contraseña por pantalla.

Ya, por mera curiosidad y, en casita, me descargué el binario (ahora que ya tenemos la contraseña de pownme, es fácil :) y lo abrí con IDA Pro para analizarlo un poco).

Abrimos el binario con el IDA Pro para 64 bits y echamos un ojo al contenido.

>>>> Antes de nada, si meto la pata no me fustiguéis, que los binarios de 64 bits en Linux no son precisamente mi fuerte :P <<<<

Bien, pues de momento nos encontramos una función llamada get_value(), que tras entrar en ella podemos ver:

En la cabecera de la función vemos la inicialización de los parámetros usados, que por comodidad he renombrado:

  • nombreDeUsuario es el parámetro de entrada, donde escribimos el nombre de usuario.
  • bufferValidacion (igual el nombre que le he puesto resulta lioso) es, digamos, el umbral a partir del cual te dice si eres un Bad Boy.
  • UIDUsuario es donde se guarda el resultado de la llamada a _getuid.

Un poco más abajo vemos cómo, tras el _getuid, guarda un 0 si no tenemos permisos o un 1 si los tenemos, es decir, por defecto, con el usuario lamde, nos dejaría un 0 y no podríamos ver los datos de pownme:

Y más abajo aún tenemos la verificación de lo que he llamado bufferValidacion, que tendría el valor con el que sobrescribimos pasados los 12 bytes primeros. Y en caso de ser menor de 3, nos aparece el mensaje de ‘Bad Kid’:

Por último, tenemos la verificación de lo que almacenamos anteriormente en UIDUsuario, que como vimos, era un 0 si no tenemos acceso, y un 1 si lo tenemos:

Como podemos apreciar, si vale 0 nos manda al mensaje de ‘You can’t touch this!’ y, en caso contrario, nos mostrará los datos del usuario.

En resumen, nuestra finalidad es cambiar el valor de UIDUsuario para que nos deje mostrar los datos de pownme, pero saltándonos el filtro de bufferValidacion que nos lleva por otro camino para mostrarnos la frase Bad Kid.

Por tanto, una forma de pasarlo directamente sería introduciendo (clickea en la imagen para ampliar):

donde \x70\x6f\x77\x6e\x6d\x65 es pownme.

———————————————————————————-

Etiquetas: , , , ,

Solucionario reto hacking enise

oct 29

Publicado por Pepelux en eNYe Sec, Hacking, Retos hacking | 10 Comentarios

Como han quitado el reto no me acuerdo muy bien de algunas pruebas pero algunas soluciones serían:

Nivel 1-A

Había que saltarse la siguiente expresión regular: ^\-(?=.*d)(?=.*[a-z])(?=.*[A-Z]).{6,}

Una posible solución es: -o=o o=oo o=oO66

Para resolverlo yo cogí y lo dividí en 3 apartados (en una copia en local) y fui saltando uno a uno los filtros:

(?=.*d) -> se pasa con o=0

(?=.*[a-z]) -> se pasa con o=00

(?=.*[A-Z]).{6,} -> se pasa con o=oO66

Esta es una posible solución, pero hay muchísimas.

Nivel 1-B

Editando el fuente de la página vemos al final un comentario con un texto en base64: cDNwMXQwXzA=

Que en texto plano es: p3p1t0_0

Una web para convertir de base64 a ASCII es: http://home2.paulschou.net/tools/xlate/ aunque hay millones

Nivel 1-C

Yo la pasé con la siguiente inyección:

user: enise
pass: ‘ or ‘a’='a

Nivel 2-A

Nos descargamos el ejecutable y con el PeID vemos que está empaquetado con UPX. Con el OllyDbg quitamos la protección de UPX usando el método de pushad / popad o cualquier otro método, ya que es una protección muy frágil y se puede saltar de muchas formas.

Una vez llegamos al OEP, buscamos en memoria la palabra INCORRECT y al lado está nuestra contraseña: Este3sTuP4$$!

Nivel 2-B

Este no lo pasé pero parece que habían dos carpetas ocultas: bin y log

Nivel 2-C

Yo la pasé con la siguiente inyección:

pass: ‘ or ‘a’='a’#

Nivel 3-A

Yo la pasé con la siguiente inyección:

user: ‘ or 1=1 or ‘a’='a
pass: xx

Nivel 3-B

Aquí había que programar. Si probamos todas las combinaciones por fuerza bruta no terminamos nunca así que acotamos aplicando ingeniería inversa, es decir:

^ es un XOR

<<< 8 desplaza 8 bits a la derecha y rellena con ceros a la izquierda

<<< 4 desplaza 4 bits a la derecha y rellena con ceros a la izquierda

Por tanto,

- nuestro valor final debe ser 436 (en hex = 1B4 y en binario = 110110100).

- al meter 4 bits (1 byte) a la derecha, como desconocemos el valor, tendríamos 16 combinaciones, de 0000 a 1111 en binario. Por tanto el resultado oscila entre 6976 y 6991.

- luego multiplicamos por 3 (siempre lo inverso que el javascript original) y por tant0 las combinaciones se disparan, ya que tenemos que multiplicar cada combinación anterior por 3.

- es decir, iria desde 6976*3 (20928) a 6991*3 (20973).

- después, al meter 8 bits (2 bytes) añadimos de 00 a FF, es decir, 256 combinaciones más.

- valor mínimo: 20928 = 51C0 (en hex) … por tanto 51C000 = 5357568 XOR 77886655 = 83211455.

- valor máximo: 20973 = 51ED (en hex) … por anto, 51EDFF = 5369343 XOR 77886655 = 83204416.

- el valor final está entre 83204416 y 83211455 = 7039 combinaciones posibles.

- dentro de estos valores probamos la contraseña si el resultado es 0.

El script  (en perl) que use es este:

#!/usr/bin/perl
use LWP::UserAgent;

my $p = 83204416;
my $res = 0;

while(1) {
 $res = $p ^ 77886655;
 $res = $res >> 8;
 $res = $res / 3;
 $res = $res >> 4;
 $res = $res ^ 436;
 enviar($p) if ($res eq 0);
 $p++;
}
sub enviar {
 my $dato = shift;
 my $cookie = "PHPSESSID=AQUI_MI_COOKIE";
 my $uri = "http://wargame.inteco.es/level3b.php";
 my $ua = LWP::UserAgent->new();

$ua->agent("Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1");
 @header = ('User-Agent' => $useragent, 'Cookie' => $cookie,  'Connection' => 'keep-alive', 'Keep-Alive' => '300', Content =>  [ password => $dato ]);
 my $response = $ua->post($uri, @header);
}

Nivel 3-C

Este era un fichero Flash. Editando el fuente de la web vemos el fichero SWF. Lo descargamos y con una versión de pruebas de Shothink SWF lo abrimos y echamos un ojo al fuente.

Hay un user/pass para despistar pero al final tenemos un hash con nuestra clave. No pa recuerdo ahora mismo pero era algo así como palillos o alguna palabreja similar.

Etiquetas: , , ,

Reto de hacking Enise

oct 28

Publicado por Pepelux en eNYe Sec, Hacking, Retos hacking | 4 Comentarios

Sólo ha durado 2 días y ha sido algo chapucero (dado que el primer día fallaban 4 de las 9 pruebas y, esto hizo que perdiéramos mucho tiempo tratando de inyectar en páginas que no funcionaban … y al tratarse de un blind, ni te enterabas) pero, al final gané en la Modalidad A. Lo malo es que no puedo optar al premio ya que se me pasó la época universitaria jejeje.

Estimado señor,

Nos ponemos en contacto con usted como potencial ganador del concurso
Wargame celebrado en ENISE. Para poder nombrarle como ganador del evento
necesitamos que nos envíe a la mayor brevedad su nombre completo y
teléfono móvil, además de la acreditación de la matrícula en el último año
de carrera o FP de grado superior. En el momento en el que lo recibamos,
nos pondremos en contacto con usted.

Un saludo,

He de decir que si no llegan a fallar los 4 retos, el justo ganador habría sido RoMaN (el cual tampoco habría tenido premio, jejeje. Y bueno, aunque corto, ha sido divertido.

Muchas gracias a los organizadores por este reto (y la próxima vez, a ver si probamos los retos antes xDDD). Enhorabuena al ganador (el que sí que cumple los requisitos)

Etiquetas: ,

Solucionario al reto RootedCON’2010

oct 25

Publicado por Pepelux en eNYe Sec, Hacking, Retos hacking | 2 Comentarios

Ya que Roman ha publicado en su web (http://www.rs-labs.com) los solucionarios al reto RootedCON’2010, he subido a mi web las soluciones que le mandé yo. Las podeis ver aquí: http://pepelux.org/download.php?f=papers/rootedctf_pepelux_es.pdf

Entre más de 1.000 participantes lo hemos terminado 18. La verdad es que ha sido duro, pues fueron 7 retos, 3 de los cuales tenían su miga. Tras 4 días pegado al ordenador, ha sido una experiencia muy buena ya que lo he pasado genial, además de aprender muchas cosas que he tenido que ir estudiando/repasando sobre la marcha.

He intentado escribir el solucionario lo más detallado posible para que se pueda seguir sin problemas, anotanto tanto las soluciones como los ‘malos caminos’ que seguí y los tropezones que me di por el camino.

Agradecer a Roman, a Dreyer y a todos los colaboradores y patrocinadores el excelente trabajo, que no ha defraudado en absoluto. Cada una de las pruebas ha sido un verdadero reto y ninguna de ellas ha defraudado. Además, se han pegado una currada impresionante y el resultado ha sido excelente. Espero que se animen y el año que viene hagan más retos.

A diferencia de otros retos, los datos eran reales, es decir, no se trataba de una simulación de una base de datos sino que había que hackear la base de datos en sí, accediendo al information_schema y teniendo que aplicar conocimientos bastante altos de MySQL, unidos a la perspicacia de cada uno.

Espero que os guste el solucionario. Un saludo

Etiquetas: , , ,

Web challenges from RootedCON’2010 CTF

sep 17

Publicado por Pepelux en Hacking, Retos hacking | No hay comentarios

Si eres un apasionado de los retos de hacking, esta tarde a las 20:00 hora española dará comienzo un nuevo reto creado por RoManSoFt y Dreyer que, conociendo a estos dos personajes, la verdad es que proteme ser muy interesante … y también difícil.

Más info del concuro aquí: http://www.rs-labs.com/noticias/#38

Date prisa que sólo quedan unas horas para que de comienzo :)

Etiquetas: , , ,

Joomla Scan en perl

sep 6

Publicado por Pepelux en eNYe Sec, Escaner web, Exploits, Hacking, Joomla | 13 Comentarios

Tras lanzar la versión 2.1 para windows de JoomlaScan he reescrito el código en perl. Ya está disponible en mi web la versión 1.1, que hace exactamente lo mismo sólo que permite usarlo tanto en Linux como en Windows.

Ante versiones nuevas o modificaciones en la base de datos, podeis hacer un update y se actualiza sólo.

Para descargarlo … click aquí: JoomlaScan v1.1 en perl

Etiquetas: , , , , ,

Joomla Scan v1.2

sep 2

Publicado por Pepelux en eNYe Sec, Escaner web, Exploits, Hacking, Joomla | 20 Comentarios

Acabo de subir a la web un nuevo programa que he terminado (tengo varios a medias siempre :) ). Se trata de JoomlaScan, y lo que hace básicamente es analizar remotamente una web (Joomla, claro!) y detectar la versión que está corriendo. Salvo un par o tres de versiones que no saca exactas, el resto te da con exactitud la versión y revisión que usa, incluidas las betas de la 1.6. Además de esto también saca un listado con los componentes que usa.

Para la detección de versión de Joomla me he basaco en un genial script en perl de OWASP, cuyo proyecto se abandonó en diciembre del 2008 y, por lo cual sólo era capaz de detectar hasta la versión 1.5.12.

El método usado consiste en comprobar una serie de ficheros que varían de una versión a otra, así como otros que contienen el ID de la última revisión. En resumen, ralizando muchas verificaciones en varios ficheros se llega a acortar el margen entre versiones hasta dar con la exacta.

Además de eso, me he pegado la gran currada de introducir todos los avisos que hay en securityfocus y que hacen referencia a Joomla, de manera que tras detectar la versión, muestra un listado con los posibles bugs que afectan a esa versión o a cualquiera de los componentes instalados.

El programa al arrancarse comprueba si hay nuevas versiones o actualizaciones de la base de datos, de manera que cada vez que suba un nuevo bug se actualizará sólo.

Podeis descargarlo aquí: JoomlaScan

Aviso: Este programa no es para hackear nada sino para hacer un autoanálisis de nuestras webs en Joomla y no me hago responsable si alguien le da un mal uso …

Etiquetas: , , , , ,

Protección de datos … what is this?

jun 29

Publicado por Pepelux en Exploits, Hacking | 9 Comentarios

Me encanta avisar a las empresas cuando detecto un fallo de seguridad (es una ironía). Realmente me parece una estupidez ya que pueden pasar 3 cosas:

1- Que te ignoren (es lo más habitual)

2- Que te digan que ellos no tienen ningún fallo y que dejes de tocar los co**nes (suele pasar)

3- Que te agradezcan el aviso (esto no suele ocurrir nunca)

No es que me dedique a buscar fallos en webs pero muchas veces se te presentan sólos y la curiosidad te lleva siempre a mirar un poco más allá. Intentando no rebasar los límites de lo legal vas mirando aquí, vas mirando allá, con los ojos como platos por la sorpresa. ‘:-o … No es posible lo que estoy viendo …’

Normalmente me digo a mi mismo … ‘Oh my God!’ y cierro la web para evitar tentaciones, porque si avisas son todo problemas; pero esta vez fue diferente. Esta vez llegué a través de una búsqueda de Google, a una web de una entidad bancaria vinculada a una entidad bancaria, que me mostraba los datos de sus empleados: nombre, apellidos, dni, dirección, teléfonos particulares, mail del trabajo, mail personal, oficina en la que trabajan, cargo que ocupan, número de cuenta bancaria … SI, su número de cuenta bancaria (del director, del interventor, del cajero, …) algo verdaderamente escandaloso, vergonzoso, indignante … vamos, para meter a los ingenieros a picar piedras un mes.

No es que estén los datos de todos los empleados sino que se trata de un club para el personal de la entidad al que se suscriben para hacer viajes y otras cosas. Pues toda esa gente tenía sus datos personales ahí, a la vista de todo el mundo.

Y lo peor de todo no es eso, sino que tras digerir los datos que Google me estaba mostrando, decidí entrar en el directorio raíz donde estaban esos datos y me encontré un File Manager, el cual no pedía ni usuario ni contraseña ni nada de nada. Ale!!! alegría!!!! acceso libre al sistema.

El gestor de archivos te permitía navegar por ciertos directorios y descargar, subir, modificar o borrar archivos libremente. No tuve que exprimir mucho la neurona para averigurar que ese gestor de archivos era de código abierto, un proyecto de sourceforge que, tras descargar el código fuente (del año 2003 la última actualización!, casi nada!) lo analicé y vi que, obviamente, estaba lleno de fallos de seguridad, que, entre otras cosas permitían hacer un LFI y sacar el /etc/passwd, y cualquier archivo del sistema al que se tuviera acceso (todo esto lo probé en local en mi máquina tras bajar los fuentes de sourceforge, eh! no pienses mal :-P ) …

La descripción del bug de ese File Manager lo puedes encontrar en mi web, aquí: sFileManager

Bueno, la entidad en cuestión es la CAM (Caja de Ahorros del Mediterráneo) y el motivo por el que me siento estúpido tras avisar es que sigo esperando una respuesta o un mensaje de agradecimiento que nunca llegará, como viene siendo habitual. Eso sí, la carpeta con los datos la han borrado totalmente parcialmente (al menos los datos del personal y el File Manager han desaparecido … hasta han desaparecido de la caché de Google!!), por lo que deduzco que han recibido mi mail. Al menos me queda la satisfacción de que los pobres empleados de la CAM ya no tienen sus datos personales a la vista de todo el mundo.

Sí, las cosas suceden así, mandas el aviso, que llega al buzón general. Una persona lo lee y no entien nada (puaj! habla de cosas de informática … se lo reenviaré a la empresa que lleva la web). Luego la empresa que lleva el mantenimiento le da una colleja al becario de turno, parchea rápidamente y borra toda evidencia antes de que se entere alguien y llegue la sangre al río. Sólo decir que la web tiene más fallos de seguridad fácilmente detectables pero como no quiero hacer nada ilegal no voy a profundizar ni a dar más detalles. Pero una empresa con tanto dinero … que contraten una auditoría de seguridad, c**o!!!

El mail que les mandé fue este:

Por favor remitan esto urgentemente a su departamento de informática porque me parece algo verdaderamente increible que una entidad como la CAM deje datos personales (de sus empleados) a la vista de todos. Me explico …

Realizando una búsqueda en Google llegué a la siguiente página:
http://webcache.googleusercontent.com/search?q=cache:mRhm4rpYt2AJ:www.elclubcam.com/ficheros/logs/Alta%2520socio+site:elclubcam.com/ficheros&cd=2&hl=es&ct=clnk&gl=es&client=firefox-a

en la que me salen un montón de datos de gente, donde aparecen DNIs, direcciones de email, teléfonos, etc (aquí ya están violando la ley al tener esa información pública en Internet). Siguiendo mi curiosidad me decido a entrar en la web http://www.elclubcam.com y veo un lugar donde pone ‘hazte socio’ y un link a un formulario que, casualmente se asemeja mucho a los datos que me encontré en la página anterior. Cuál es mi sorpresa cuando veo que entre los datos hay números de cuenta, entre otras cosas. Vamos, los números de cuenta, direcciones, teléfonos, mails, dni, apellidos, etc del personal de su empresa, incluída la oficina dónde trabajan!!!

Aparte de esto, entro en http://www.elclubcam.com/ficheros/ y me veo un listado de archivos con un file manager (gestor de archivos), accesible sin usuario y contraseña, y sin que diga nada de acceso restrigido ni información privada ni nada de nada …. y, desde el cual se puede ver todo el contenido privado de la web (es decir, muchos listados con datos personales de empleados). Es más, ese gestor de archivos (público, gratuito, y, con el código fuente en http://onedotoh.sourceforge.net) es del año 2003 y tiene fallos de seguridad que permiten acceder a todo el servidor, es decir, no sólo a la web sino a todo el sistema. (más información aquí: http://www.pepelux.org/download.php?f=exploits/sfilemanager.txt)

Si su departamente informático desea más detalles pueden contactar conmigo. Espero que lo resuelvan rápido o, al menos quiten los datos de sus empleados de Internet ya que, repito, hay hasta datos bancarios!

Un saludo

Rectificación: Bueno, quiero aclarar (ya que me han llegado algunos mails) que esta web creo que la lleva una empresa externa y no la propia CAM, aunque como ya he dicho, creo que si de una u otra forma está vinculada a la entidad, deben prestar cierta atención. No obstante, a pesar de que los datos eran de personal de la CAM, no creo que el equipo informático de esta sean los responsables del ‘descuido’.

Etiquetas: , , ,