Configurar un HoneyPot en tu aplicación web con Latch

Latch no solo es una aplicación que sirve para abrir y cerrar un pestillo, sino que va mucho más allá. Puede usarse como un Segundo Factor de Autenticación si lo ponemos asociado al login de usuario como en el plugin de WordPress, Moodle, SSH o PrestaShop y si lo tuneas puede ser usado en un esquema de 4-Eyes Verification. Puede ser usado en soluciones como Segundo Factor de Autorización, para permitir o no permitir operaciones en un determinado sistema, como se puede ver en el caso de WordPress in Paranoid Mode - esta tarde Eleven Paths Talk Gratuito sobre este tema -  o como lo puedes probar en Nevele Bank con las operaciones bancarias o con tu cuenta de CajaMar si eres cliente. También puedes usarlo en un esquema de 2-Keys Activation tal y como se usaba en la hucha controlada por biometría y Latch o para proteger el acceso a ficheros seguros.

Figura 1: Configurar una HoneyPot en tu aplicación web con Latch

Se puede usar en sistemas operativos OS X, Windows, Linux o en el mundo IoT y tras ver los concursos de ideas, seguro que se te ocurren nuevas a ti. A mí se me ocurrió montar un entorno de Deception o una HoneyPot para saber lo que hacen los malos en la zona privada de mi plataforma si un día aparece un bug o son capaces de saltarse las protecciones de mi aplicación web. Y no, no hace falta nada adicional. Dejadme que os lo cuente.


Figura 2: Cómo usar Latch en la web de Cajamar
Si un atacante es capaz de obtener unas credenciales robadas por medio de un ataque de Spear Phishing y sabe que son válidas, puede intentar  acceder al sitio correspondiente. Si el sitio tiene un un 2FA o el atacante intuye que puede haber un Latch, esto no será suficiente, pero puede ser que aún así quizás no se rinda tan fácilmente e intente otros métodos para acceder al sistema sin tener que pasar por el login de la aplicación web.

Una base de datos HoneyPot con Latch

Como ya sabéis, con Latch el atacante solo tiene un intento de acceder con las credenciales correctas, ya que el sistema avisa al usuario de que intentaron acceder y/o accedieron con sus credenciales en el sitio protegido. Pero veamos ahora un ejemplo exagerado de lo que podremos conseguir con Latch usando la potencia del interruptor en que se convierte. Si no te has visto alguna de las charlas de Chema Alonso sobre esto, deberías hacerlo. Aquí una que recoge todos los escenarios descritos.


Figura 3: Protección empresarial contra insiders que roban identidades locales
Imaginemos que a pesar de tener el Latch cerrado, la aplicación lo deja entrar porque el atacante no ha usado las credenciales, sino que ha sido capaz de robar una cookie de sesión y hacer un Session Hijacking o ha logrado acceso por medio de una password de aplicación o incluso porque la web permite acceso basado en tokens OAuth como en los ataques de Sappo y RansomCloud. Proteger las cookies contra un ataque de hijacking, los accesos vía Application Password o mediante Tokens OAuth no es algo que se proteja con un 2FA o un Latch puesto en el proceso de login y podría darse un caso en el que el atacante encontrara la forma de llegar a la información y los datos de la parte interna de una aplicación web.

Ahora vamos a cambiar el chip y utilizar Latch de forma más holística dentro de la aplicación, para que sirva no únicamente para bloquear o dejar acceder en el proceso de login, si no que además cambie completamente los datos de la aplicación usando el pestillo para indicar al sistema qué opción debe tomar: La pastilla azul o La pastilla roja. Es decir, el camino de la información falsa o el camino de la información real. Bien, ahora creo que ya sabéis por dónde voy.

Figura 4: Configuración de aplicación Latch para montar el HoneyPot

Cuando Latch esté cerrado, la aplicación estará siempre conectada a la base de datos con la información falsa. Por otro lado, si el Latch está abierto y se inicia sesión, las conexiones a la base de de datos antes de ejecutar los comandos SQL se harán entonces con la base de datos verdadera, obteniendo así la información real. En resumen el pseudocodigo sería algo como:

- Comprobar estado de Latch de AplicaciónWeb
- Si está abierto conectar a base de datos con información real.
- Si está cerrado conectar a base de datos HoneyPot
- Ejecutar consulta SQL con acceso a datos
- Cerrar conexión.

Si un atacante logra robar una sesión y tenemos el Latch cerrado, caerá en la aplicación HoneyPot, y revisando los logs de actividad podremos a posteriori ver cuales son sus intenciones y conocer cómo consiguió el acceso. Tal vez fue un Session Hijacking, tal vez un ataque de CSRF porque no se cerró bien la sesión pero sí el Latch, tal vez un ataque de red... Pero en todos los casos contra la base de datos HoneyPot.

Una pequeña PoC

Veamos ahora una pequeña PoC, de una aplicación donde podremos ver los proyectos de los responsables de una empresa con sus presupuestos (cualquier parecido con la realidad es pura coincidencia). Así es como se ve con el Latch abierto, es decir, información verdadera.

Figura 5: Datos reales a los que se accede con Latch abierto

Si el Latch estuviera cerrado, se vería otro tipo de información preparada, como esta:

Figura 6: Datos que aparecen en la base de datos HoneyPot 

Y aquí vemos un ejemplo preparado de un SQL Injection con el Latch cerrado.

Figura 7: Ataque de SQL Injection a la web con la Base de datos HoneyPot

Mostramos ahora el registro de Logs de lo que está haciendo. Hemos descubierto que el atacante hizo un ataque de SQL Injection para obtener información sobre los presupuestos de PEPITO, y ahora deberíamos investigar cómo lo ha hecho. ¿Será por un CSRF como en el caso de la base de datos atacada desde el iPad del jefe?

Figura 8: Log de acciones de ataque en la HoneyPot

Evidentemente si en la aplicación con la información falsa existe este fallo, lo habrá igualmente con la información real, y además ha sido descubierto dicho bug por un atacante, pero sin arriesgar la información legítima. Ahora podemos arreglarlo lo antes posible para que no vuelva a suceder. Evidentemente una aplicación de empresa debe estar lo suficientemente probada y no dejar en mano de los atacantes descubrir los fallos, pero... las cosas pasan.

En este ejemplo vimos un uso adicional de Latch, no solo de permitir o prohibir el paso, si no de tomar una opción u otra en función de un estado. Esto no solo se aplica en bases de datos, podríamos usarlo para cambiar el tráfico de un host a otro, y tener muchas opciones más si utilizamos la granularidad de las operaciones. Otro caso útil podría ser el login de una web. ¿Por que mostrarlo si podemos bloquear con Latch tan siquiera la publicación del formulario de login? El límite lo pone nuestra imaginación y las ganas de programar. Te recomiendo que leas el artículo de cómo cocinar una aplicación PHP con Latch que explica paso a paso cómo se puede meter Latch en cualquiera aplicación web que tengas.

Autor: Borja Pintos

Cómo montar un sistema de vigilancia en tu casa muy barato y extremadamente sencillo #CCTV

Hace un año compré una alarma barata en la ferretería de mi barrio, que consiste en un detector de movimiento que se comunica de forma inalámbrica con una unidad central, que a su vez está conectada a una línea de telefónica y que puede tener una tarjeta SIM para hacer llamadas. El funcionamiento es sencillo: si se detecta algún movimiento, se manda una señal a la unidad central, que te hace una llamada a los números de teléfono que configures.

Figura 1: Cómo montar un sistema de vigilancia en tu casa
muy barato y extremadamente sencillo

Es un sistema funcional que te permite saber de esta forma que, si recibes una llamada de alarma en el móvil, sabes que algo se mueve en tu casa. Pero por desgracia no sabes si se trata de una mosca que ha pasado por delante del detector o es que realmente ha entrado alguien en tu hogar mientras tú estabas fuera. ¿Qué haces entonces si te pilla de vacaciones? ¿Llamas a la policía o molesta a tu vecino? La intranquilidad te mata y piensas algo como ¡lo que daría por ver lo que pasa dentro de mi casa en esos momentos!

Soluciones para montar un CCTV de andar por casa

Una solución relativamente sencilla, pero cara para los que no tenemos mucho dinero, sería comprar una cámara de vigilancia IP semiprofesional para poder conectarte a distancia desde tu smartphone o ver lo que pasa vía un servidor web. Esto puede tener ventajas en cuanto a usabilidad, pero si recuerdas el artículo que le dedicó Retro-Maligno a la Cámara de Seguridad GM01 tal vez pensar en que puedas acabar desnudo en Internet no sea lo que más desees.

Figura 2: Las imágenes de los usuarios de la GM01 publicadas en Internet

También podrías comprar un sistema de alarma más completo con todos los elementos de cámara y detectores integrado pero esto no es low-cost y si te metes en un lío como Claudio Caracciolo y su sistema de seguridad CCTV comprado por Internet, lo mismo acabas teniendo más problemas que ventajas.

Figura 3: El sistema CCTV que tantos problemas le dio a Claudio

Low-cost (primera premisa) sería utilizar como cámara de vigilancia un smartphone antiguo al que poderse conectar para ver quién hay en casa, pero además debe ser extremadamente sencillo (segunda premisa). De esto hemos visto muchas soluciones con apps como por ejemplo Presence, que está orientado al mundo Apple con iPhone o iPad.

Figura 4: Presence permite usar iPhone & iPads antiguos como sistemas CCTV

Pero como la necesidad agudiza el ingenio, aún podemos ser más imaginativos y explorar algunas alternativas de las de andar por casa, para ver cuál es la más sencilla, tanto que hasta Penny pueda hacerlo y utilizarlo.

Alternativa 1: cámara IP remota

Consiste en instalar en el smartphone una app para funcione como una cámara IP remota a la que conectarse, como puede ser el caso IP Webcam - al estilo de Presence pero sin tener que poseer un dispositivo made in Apple que tan caros salen -.

Figura 5: IP Webcam para Android

Pero para esto hay que abrir el puerto de la cámara IP en el router de casa y utilizar un servicios de DNS dinámico con cliente disponible en tu smartphone (como no-ip o FreeDNS). Eso sin olvidar de ponerle una contraseña de acceso a la cámara y tener mucho cuidado no vaya a ser que acabes como en el caso de la app PAW que dejaba todo tu terminal - y tu micrófono y tu webcam - abiertos a Internet.

Figura 6: Servidores PAW accesibles en Internet con password por defecto

Pensándolo bien, creo que hacer todo esto no sería tan extremadamente fácil para Penny.

Alternativa 2: grabación con almacenamiento en la nube

Otra opción es utilizar una app de grabación de video con almacenamiento en la nube, como es el caso de Alfred o Ivideon.

Figura 7: Ivideon Vídeo Suveillance para Android

Con esta alternativa, te evitas abrir puertos en el router ni configurar ningún DNS dinámico. Además, estas soluciones suelen tienen algunas características interesantes, como la notificación en caso de detección de movimiento, y así nos ahorramos el dispositivo de la ferretería del principio.

Figura 8: Alfred - Home Security Camera para Android

Sin embargo, aunque esta alternativa si es fácil para Penny, estas soluciones suelen tener planes de precios por almacenamiento, sin mencionar el tema de la nube.

Alternativa 3: Skype

Pero una alternativa extremadamente fácil para Penny sería utilizar la misma aplicación de Skype como cámara remota de vigilancia, así de sencillo, que además la tienes para iPhone, Android, para OS X o para Windows.

Figura 9: Skype para Android

Basta con instalar el cliente Skype en el smartphone que queremos utilizar como cámara de vigilancia y crear un usuario específico para ese móvil (por ejemplo, “movil1demichoza”). Pero para que esto funcione como queremos, en el cliente Skype habría configurar (y aquí está la gracia):

- Contestar automáticamente, para que se descuelgue la llamada automáticamente cuando llaman
- Recibir llamadas sólo de los contactos, para que no se pueda contestar automáticamente a cualquiera que llame
- Y por supuesto, tener en la lista de contactos sólo al usuario (o usuarios) desde el que se va a realizar la llamada (es decir, el usuario de Penny), que sería el usuario autorizado

De esta forma, simplemente haciendo una video llamada con Skype, se puede establecer una conexión video y audio con tu casa, sin necesidad de abrir puertos, ni configurar DNS dinámico, ni almacenar nada en la nube. Esto sí es extremadamente sencillo para Penny.

Figura 10: Configuración de Skype para descolgar automáticamente

Low-cost y extremadamente sencillo, pero recuerda que no puedes hacer esto con el móvil que te deje un amigo o la novia para espiarle, eso no estaría bien.

Autor: Zardacho

SCADA: Halcones heridos en tus Infraestructuras Críticas #SCADA #HoneyWell #OSINT

En el presente artículo os voy a contar una parte de mi entretenimiento e inquietudes durante mis ratos libres en  estos últimos meses. Todo empezó con el descubrimiento de herramientas como Zmap y Masscan las cuales ofrecen resultados de escaneo de grandes rangos de direcciones IP en muy poco tiempo. En ese momento me surgió la duda de cuánto de verdad tenían y si los resultados eran fiables o parecidos entre sí, o incluso, porque no, comparados con Nmap y Shodan. Por lo que para validar si realmente que eran datos fiables sin estar repetidos, y sin volverme muy loco, decidí a probarlo sobre un direccionamiento estático eligiendo un proveedor de Internet nacional al azar.

Figura 1: SCADA. Halcones heridos en tus infraestructuras críticas

Mediante la herramienta de Maltego obtuve los bloques de direcciones IP por su código ASN y por si acaso, lo contrasté con el servicio ipinfo.io. Estos son los valores que obtuve para comenzar la investigación.

Figura 2: Rangos de direcciones IP obtenidos con Maltego

Una vez obtenidas las redes tenía que averiguar cuáles eran dinámicas o estáticas. Para ello creé un sencillo script en Bash - no tengo conocimientos de programación en un lenguaje como Python, de ahí la sencillez - al cual le indicaba en un fichero TXT las direcciones IP para realizar la resolución inversa y descartar así los rangos /24 de aquellas que fueran dinámicas (alguno fue /25).

Figura 3: Script en Bash para seleccionar las direcciones IP

Ahora ya tocaba decidir qué puertos escanear, por lo que decidí recopilar toda la información posible acerca de los sistemas SCADA recurriendo al blog de SCADA Stragne Love. Una vez obtenida información sobre dispositivos y puertos útiles a escanear, descarté los puertos UDP y también algunos puertos TCP que me iban a generar demasiados falsos positivos como por ejemplo el 23 y el 80.

Antes, el descubrimiento de dispositivos SCADA en grandes rangos de direcciones IP era lento pero gracias a las herramientas de hoy en día esto está al alcance de cualquiera. El objetivo, como os podéis imaginar, consistía en descubrir dispositivos SCADA en esos rangos de direcciones IP identificándolos por los puertos especiales que ellos utilizan. Algo que cualquiera puede hacer fácilmente con los recursos que he descrito hasta el momento. Y tras lanzar los escaneos los resultados de Zmap, Masscan, Nmap y ShodanCLI han sido los siguientes:

Figura 4: Resultados obtenidos para el descubrimiento de dispositivos SCADA basándonos en sus puertos

Cuando hablo de "Totales" me refiero a los encontrados por cada herramienta de los cuales los "Únicos" son los que sólo esa herramienta ha encontrado y sumando todos hacen el "TOTAL" de 97 resultados positivos, ahora quedaría analizarlos y descartar falsos positivos. Es decir, algunos dispositivos han sido encontrados por más de una herramienta, y algunos han sido encontrados de forma única por una sola herramienta.

Analizando los resultados

- Shodan: Sorprende el número de resultados ya que esperaba un número más amplio. El tiempo de ejecución ya sabemos que es inmediato y con ShodanCLI además tenemos la opción de descargar un JSON con todos los datos.  Hay que comentar que con búsquedas de más de 1000 resultados hay que indicar el parámetro "--limit=XXXXX", es decir, simplemente tiene que ser un número mayor de los resultados para la descarga total ya que si no se hace eso tan sólo descarga 1000.

Figura 5: ShodanCli

Es recomendable antes de hacer una descarga de los datos, ver con Count los resultados de la búsqueda cli.shodan.io. Una vez descargados los visualizamos en pantalla con parse indicando los datos que queremos ver teniendo como referencia las especificaciones para los desarrolladores de Shodan.

- Zmap: a mi parecer queda bastante mal parado pese a ser el que usan en Censys para escanear todo Internet, aunque también es cierto que por una parte entiendo el uso de Zmap por parte de Censys ya que es increíblemente rápido. La ejecución de Zmap fue de alrededor de 1 hora.

- Masscan y Nmap: Hay que decir que comparten algunos parámetros a la hora de lanzarlos pero que Nmap se puede hacer eterno - unas 60 horas aproximadamente - frente a Masscan que tan sólo necesita unas horas 3 a 6 aproximadamente para obtener unos resultados bastantes buenos.

La conclusión que se obtiene es que no es una buena idea limitarse a una sola herramienta ya que como podéis ver hay información que quedaría sin ser analizada solo por no haber probado todas. Al final, lo único que te requerirá es un poco de más tiempo, pero como se ve en le gráfico de la Figura 4, todas las herramientas han aportado, al menos, un resultado único.

Descubriendo dispositivos vulnerables HoneyWell FALCON

Con la lista de dispositivos SCADA descubiertos en los escaneos y siguiendo la idea de Conquistar el mundo con OSINT & Well-Known bugs, apareció información sobre un uno en concreto de la casa Honeywell que usa el puerto 47808. Buscando datos de él en Google me llamó la atención que hubiera un panel indexado, pero como había descartado el puerto 80  en mis escaneos no me había percatado de que esto pudiera pasar. La casa HoneyWell suele tener estos paneles para administrar sus dispositivos, como ya vimos hace años con los sistemas de aire acondicionado de HoneyWell, así que decidí hacer un poco de hacking con buscadores al uso con un dork concreto que se me ocurrió y di con este modelo concreto.

Figura 6: Paneles web de administración del dispositivo indexados en Google

Busqué a ver si en Internet había información de alguna vulnerabilidad relacionada con este dispositivo y fue sencillo localizar la existencia de dos, por lo que me pensé en buscar información detallada de las mismas. En este momento sentí la responsabilidad de no poder dejar esto así. Había encontrado algo que podría estar mal y quería avisar a los responsables si era así, porque me parecía demasiado sencillo si alguien malo buscaba esto.

Una de las vulnerabilidades hacía referencia a usuarios y contraseñas por defecto en este dispositivo - exactamente igual que en el caso de los sistemas de aire acondicionado de HoneyWell que mencioné antes - y probé a ver si estaban así en estos dispositivos concretos o los responsables habían tenido la precaución de cambiarlas. Que estuvieran indexados en Google era ya un mal síntoma, porque eso significaba que no estaban tomando todas las precauciones posibles.

Figura 7: En la propia página de login ofrecen todos los usuarios

Aquí es cuándo vino mi sorpresa al ver lo excesivamente fácil que era explotar este fallo de fábrica, ya que el panel web trae por defecto dos usuarios creados SystemAdmin y Guest y aunque la contraseña de SystemAdmin había sido cambiada, la password de Guest seguía por defecto.

Figura 8: Se puede entrar como Guest al home del sistema

Podemos navegar por las diferentes secciones para hacernos una idea de lo que hay. También al haber iniciado sesión correctamente como el usuario Guest se podría acceder a la parte de administración y cambiar la contraseña para este usuario.

Figura 9: Cambio de contraseña en el panel de administración

Esto entra dentro de lo normal, pero al analizar la construcción de la web podemos descubrir algo mucho peor. Al entrar en la parte de gestión de la contraseña se genera una dirección URL con el ID de usuario correspondiente en un parámetro por GET y tras revisar el código HTML de la página vemos que la password de ese usuario está en MD5 en un campo. ¿En serio? Sí.

Figura 10: Hash de la contraseña del usuario Guest en el código HTML

Según parece, los dispositivos vulnerables de este modelo tienen una vulnerabilidad que fue descubierta en el año 2014 por la que generan un ID correlativo e idéntico en todos los dispositivos. En los sistemas actualizados esto ya no es así, pero en los vulnerables basta con mover uno adelante o uno atrás y llegar al valor del hash de la cuenta de SystemAdmin que es el primero que se crea y ya tenemos el hash de su password.

Figura 11: Hash de la contraseña del usuario SystemAdmin en el código HTML

De esta misma manera si hay mas usuarios sólo hay que aumentar el ID para obtener el hash MD5, aunque como ya he comentado antes en algunos casos son ID diferentes. Pero mi sorpresa viene al revisar la vulnerabilidad  que indica que incluso puedes llegar a esta url sin estar autenticado. Sin comentarios.

Figura 12: Vulnerabilidad en dispositivo permite llegar a la URL sin estar autenticado

Por lo que directamente se puede acceder a otro sistema igual simplemente cambiando la  dirección IP en la URL sin necesidad de que existan o no las contraseñas por defecto en los usuarios. Lo mejor es que, una vez obtenido ese Hash MD5 se puede hacer uso de la contraseña con un ataque de Pass the Hash como se explica en este artículo, pero como es un valor MD5 sin Salt ni nada, es casi más fácil crackearlo. Podemos hacerlo simplemente mediante una búsqueda en Google.

Figura 13: Hash MD5 crackeado e indexado en Google

O en cualquier web que nos permita introducir un listado de todos los hashes de todos los usuarios, o con el clásico John The Ripper en tu equipo para no leakear ninguna información del estudio en la red, o por ejemplo con Hashcat + diccionario propio y aplicando reglas. Vamos, es un MD5, no es tan complicado.

Figura 14: Crackeando "in house" el MD5

Como he dicho antes, no sería necesario ni obtener la contraseña porque el sistema es vulnerable a ataque de Pass the Hash, pero una vez obtenidas las claves de todos los usuarios el sistema quedaría expuesto a cualquier atacante que quisiera entrar como SystemAdmin.

Figura 15: Acceso como SystemAdmin

Como se ha visto, el ataque es muy fácil. Ese es el verdaderos problema, que ha sido demasiado fácil y tal vez sea un poco exagerado. Llegado a este punto, decidí avisar a todos los afectados por este bug que yo había localizado para que lo arreglaran de alguna forma. Pedí a Chema Alonso que llamara a los que conocía - lo cual agradecieron como en la historia del carnicero - y al resto los avisé vía CNPIC, que tiene un contacto en la web para esto.

Figura 16: Control de elementos del sistema

Con un fallo en la seguridad tan fácil de explotar, pienso que se podrían provocar daños reales (económicos o físicos) alterando los valores de funcionamiento ya que los dispositivos donde están instalados pueden ser polideportivos, residencias, fábricas que podrían sufrir una pérdida total o parcial de producción, laboratorios, etcétera.

Figura 17: Control de central térmica

A parte de tener passwords por defecto, de no usar un segundo factor de autenticación en el login, etcétera, lo mejor de todo, es que ninguno de los paneles de administración web usaban HTTPs ni por asomo, así que cualquier dispositivo en la red o atacante haciendo un man in the middle en IPv4&IPv6 podría acceder a las contraseñas con facilidad.

Figura18: Posibilidad de apagar el sistema

Los fallos no son nuevos, y nos agradecieron el reporte para poder solucionarlo, pero es significativo que un fallo tan grave esté más de dos años sin ser descubierto en una implantación funcionando. Creo que los sistemas de pentesting persistente deberían ser obligatorios para todas las industrias y más si son Infraestructuras Críticas de nuestro país, como era el caso de alguno de los sitios.

Autor: Ander Cablallero

Recuperar información eliminada de BBDD SQLite #Forsensics #SQLite #Python

Hace unos años, mientras escribía Hacker Épico, me leía las especificaciones del formato de los ficheros SQLite para ver cómo podía recuperar información eliminada de estos ficheros e incluirlo como parte de uno de los capítulos del libro. Aún estaba lejos de ver el libro terminado, de que llegara el día de la presentación del libro y mucho menos de verlo convertido en un cómic en edición deluxe, pero tenía claro que el libro tenía que aportar investigaciones novedosas para estar al nivel de la trama.

Figura 1: Recuperar información eliminada de una base de datos SQLite

De aquel trabajo de varias semanas, además de los 0days de las cámaras de seguridad que dieron la vuelta al mundo, salió una serie de artículos en Security By Default  dedicados al Análisis Forense de SQLite que dividí en siete partes ([1], [2], [3], [4], [5], [6] y [7]) y una charla sobre ello en Rooted CON 2013 que titulé "Te pique lo que te pique analiza un SQLite". Con todo este trabajo, salió además una herramienta que fue el germen de la web Recover Messages.

Figura 2: RootedCON 2013 "Te pique lo que te pique analiza un SQLite"

Esa mini utilidad realmente es un script en Python que recorre el fichero BTree de la base de datos y detecta aquellas secciones marcadas como libres para obtener su contenido. No es perfecta, ya que al igual que ocurre en un sistema de ficheros, hay muchos elementos externos que afectan a la estructura del archivo, como son la inserción (INSERT) de nuevo contenido o la defragmentación (VACUUM) de la base de datos.

Figura 3: Recuperación de datos de una base de datos SQLite de Skype con RecoverMessages

Debido a su ligero funcionamiento, estas bases de datos son ampliamente usadas en aplicaciones móviles como por ejemplo hace WhatsApp o Twitter para almacenar mensajes. También en aplicaciones de escritorio mucho más complejas, como es el caso de las conversaciones de Skype o las cookies en Firefox. Por eso, se podía utilizar RecoverMessages con Skype, WhatsApp - en la última versión de WhatsApp para iPhone la base de datos sigue sin cifrar - o bases de datos de Twitter.

Figura 4: Estructura general de un fichero SQLite

Pero pese a esas limitaciones y en función al origen del fichero, la herramienta es práctica para encontrar información que tal vez esclarezca un incidente de seguridad durante un proceso de análisis forense que deba realizar un perito, ya que tan solo una cookie recuperada o un trozo de mensaje podría llegar a ser más que suficiente para evidenciar un acontecimiento.

RecoverSQLite y DumpLite

Que no soy un programador experto no es ningún secreto, así que después de una primera versión llamada "recoversqlite.py", con ayuda de mi amigo WiredRat creamos él creó una segunda versión mejorada llamada "dumplite", que además de las páginas libres, era capaz de encontrar bytes borrados entre celdas.

Figura 5: Dumplite en GitHub

El uso es muy sencillo, solo hay que obtener el código de GitHub con gitclone e invocarlo con los parámetros deseados contra el fichero SQLite a analizar. Con la opción -h se muestra la ayuda tal y como se puede ver en esta captura durante una ejecución sobre Kali Linux.

Figura 6: Descarga de dumplite y menú de ayuda de la herramienta

Las propiedades del fichero y sus características se obtienen con el parámetro "-F". Entre las más relevantes, desde una perspectiva de investigación forense, son: (1) El número de páginas libres y (2) La codificación de los textos.

Figura 7: accediendo a la información de un fichero SQLite

Para obtener el contenido de las secciones marcadas como libres, tanto en formato ASCII como en hexadecimal, se usa el parámetro "-u".

Figura 8: Volcado de los datos de la base de datos SQLite obtenidas

Como comentaba anteriormente, tras ejecutar la herramienta se obtienen volcados de información y no se recuperan directamente los registros que hayan sufrido un "DELETE" como si nada hubiera pasado. El trabajo debe realizarse luego para ir conectando los datos volcados entre sí y extraer lo que había allí antes de ser eliminado. Espero que os sea de utilidad y cualquier comentario o Commit será bienvenido.

Autor: Alejandro Ramos (@aramosf), escritor del libro "Hacker Épico"

Paint.NET en metadatos de Internet Information Services #Microsoft #metadata #IIS

Hoy domingo os voy a traer un post con sólo una curiosidad - que hoy ya habrá mucho denso que leer con eso de ser día de elecciones generales - sobre el mundo de los metadatos que descubrimos revisando en Eleven Paths los resultados de un escaneo hecho con Faast, nuestro sistema de Pentesting Persistente. Se trata en este caso de un metadato que aparece en la imagen que se utiliza por defecto en los servidores Microsoft Internet Information Services 8.5 y que apuntan a que ha sido creada con el software Paint.NET, tal y como se dio cuenta nuestro compañero Ioseba Palop que siempre anda con el ojo abierto.

Figura 1: Paint.NET en metadatos de IIS 8.5

Como podéis ver, la imagen es un fichero en formato PNG que, a pesar de lo que muchos puedan pensar, también tiene sus propios metadatos. De hecho, en MetaShield Protector es una de las cosas que miramos en todas las imágenes para poder evitar que se filtre información como los programas que se están utilizando.

Figura 2: Imagen de Microsoft para los servicios IIS 8.5

El que se conozca el software en uso puede abrir un problema de seguridad, al poderse descubrir alguna vez algún fallo relativo a él. No hay que irse muy lejos en el tiempo para ver cómo un software de tratamiento de imágenes se convirtió en la peor pesadilla para la seguridad de las empresas con el 0day de ImageMagick que afectó a tantos servidores GNU/Linux.

En otras ocasiones, el problema de que se conozca el software que está en uso es más reputacional que otra cosa, ya que puede dejar mal a la compañía por su posicionamiento público o peor, que se descubra que se está utilizando una copia pirata del software para la que la compañía no tiene licencia.

El caso de la imagen de IIS 8.5

Si analizamos esta imagen con un editor hexadecimal podemos ver que en la cabecera del fichero ya aparece el nombre del software Paint.Net dentro del mismo.

Figura 3: Head del fichero PNG

Si queremos hacer un análisis más detallado, podemos usar cualquier software de análisis de ficheros PNG, en este caso Inspect PNG de Simon Strandgaard para OS X y está disponible dentro de Mac App Store.

Figura 4: Inspect PNG para OS X

Como se puede ver, dentro de los metadatos es posible acceder al nombre del software que ya habíamos visto. El software en concreto es Paint.Net, una popular herramienta gratuita que es freeware y vive de donaciones.

Figura 5: El software utilizado es Paint.NET v3.5.10 (no es la última versión)

Así que esperamos que los ingenieros de Microsoft que la hayan utilizado, hayan puesto algo de los fondos que normalmente estas compañías destinan para donar a los creadores de software independientes, dentro de las arcas de los creadores de Paint.Net. O mejor, ¿y si se cambiara Paint por Paint.Net en futuras versiones de Windows?

Saludos Malignos!

10 años después descubres que hay que tapar la Webcam #malware #privacidad

Hace 11 años, exactamente en el año 2005 nació el popular RAT (Remote Administration Tool) Poison Ivy. Las herramientas RAT son un tipo de malware creado especialmente para controlar totalmente un equipo desde una consola centralizada. Su evolución natural les llevaría a convertirse en las populares Botnets de equipos Zombie, donde desde un Command & Control Panel se llegan a gestionar millones de equipos infectados. En el año 2005, cuando aparece la primera versión de Poison Ivy, se empiezan a extender las técnicas de Reverse Shell, o lo que es lo mismo, que el llamado "Server" que se instala en la máquina infectada, es quien realiza la conexión al panel de control para recibir las órdenes y no al revés, como se hacía en malware clásico anteriormente.

Figura 1: 10 años después descubres que hay que tapar la webcam

Poison Ivy fue muy popular durante los años en los que  estuvo en plena evolución, hasta llegar al año 2008 donde apareció su última release, la versión 2.3.2. Después vendrían muchos más que copiarían la mayoría de sus funciones. Entre las muchas que traía la herramienta Poison Ivy estaba un módulo de vigilancia que permitía al atacante activar tu Webcam y grabarte en tu intimidad - y este no fue el primero que lo hizo -. Aquí tenéis una captura hecha por la webcam de una persona infectada con Poison Ivy 2.3.2, del año 2008.

Figura 2: Webcam capture en Poison Ivy versión del año 2008

El primer día que yo descubrí que con herramientas como Poison Ivy era tan fácil para un atacante activar tu Webcam la tapé. Desde hace más de una década llevo la Webcam de todos mis equipos tapados, lo que me generó que mucha gente me preguntara desde ese momento por qué lo hacía. Las nuevas herramientas RAT que fueron siguiendo la estela de Poison Ivy fueron añadiendo todas la misma función, y ver ya esa opción entre la lista de posibilidades no sorprende a nadie de este mundo. En la imagen IndSocket y en este otro artículo tienes Incognito RAT que también funciona con equipos Mac OS X infectados e incluso se controlaba desde un iPhone.

Figura 3: Opción de Webcam Capture en IdnSocket RaT

En el año 2011, ya con mi blog abierto, descubrí la existencia de un foro en el que la gente se dedicaba a infectar personas con RATs, capturarles con la Webcam y compartir el material con todos. Las fotos eran brutales, e incluso había vídeos subidos a Youtube - hoy retirados - que mostraban el proceso completo. Si te aburres, abre Youtube y busca vídeos y tutoriales de RAT. Te sorprenderá ver la gran cantidad de esta familia de malware que existe con la capacidad de grabarte en tu casa y hemos visto que hasta vecinos lo usaban para espiar a sus víctimas.

Figura 4: Un caso de espionaje vía Webcam del año 2013 en España

A partir de ahí, sistemáticamente he ido explicando en multitud de ocasiones el riesgo de no taparse la Webcam, además de explicar que el número de fallos que aparecen y que pueden permitir a un atacante infectarte para activar la Webcam es alto. En el año 2011 un bug en Adobe permitía hacer lo mismo.

Figura 5: Security Innovation Day 2014. En esta charla hacemos la demo de infectar a la víctima con un documento Excel y capturar la webcam con Metasploit

En muchas demostraciones, como en el evento de Creo en Internet en el año 2011 o en el Security Innovation Day 2014, he hecho demos con malware que infecta el equipo y activa la Webcam usando Metasploit, que tiene módulos para eso desde hace infinidad de tiempo, e incluso algún ciberespía ruso ha salido retratado en un proceso de doxing con el que le han activado hasta la webcam de su casa - con sus cortinas último nivel de moda -.

Figura 6: Supuesto ciberespía ruso grabado en su casa

Algunos creen que las Webcam con las luces son más que suficientes, porque si se enciende la luz lo ves, pero incluso hay muchos casos que han demostrado cómo es posible llegar a encender la Webcam sin encender la luz. Al final si hay software de por medio hay posibilidad de que haya un bug para saltarse el proceso.

Figura 7: Recomendaciones de la NSA sobre la Webcam y el micrófono en OS X

Otros creen que por tener Linux ya no es necesario tapar la Webcam como si el software fuera diferente en ellos. Lo curioso es que hace años, pudimos ver ya documentos de la NSA que recomendaban a todos los miembros del gobierno que taparan la webcam y el micrófono para evitar este tipo de espionaje.

Figura 8: Equipo de Moxie Marlinspike en Twitter con la Webcam tapada

Entre los hackers esto es muy común desde hace años y en esta foto tomada al equipo de Moxie Marlinspike cuando era responsable de seguridad de Twitter se podía ver que él hacía lo mismo con  la Webcam de su Mac OS X.

Figura 9: Equipo MacBook de Mark Zuckerberg con la Webcam y el micrófono tapado

Ahora la gente ha visto que Mark Zuckerberg también tapa la webcam y el micrófono de su MacBook y ha vuelto la gente a preguntarse si será excesivo o no hacer esto con su equipo, tablet y dispositivo móvil, que el malware para Android también puede hacer estas cosas.

Figura 10: El iPatch de Latch que tapa mi Webcam

Yo llevo mucho tiempo con la mía tapada, e incluso regalamos para los eventos el popular iPatch con Latch para los asistentes, pero tú eres libre de hacer lo que quieras. Eso sí, "Si no tapas tu Webcam, ponte sexy para salir en Internet".

Saludos Malignos!