Cómo convertirse en Tripulante Aéreo Autorizado con un SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)

Las técnicas de SQL Injection fueron descubiertas en 1998. El 25 de Diciembre de 1998 el investigador rfp (rain.forest.puppy) publicaba el famoso ezine en el que hablaba de cómo se podía saltar la seguridad de una aplicación web que validaba usuarios contra una tabla en una base de datos usando consultas SQL con cadenas de texto concatenadas. Acababa de nacer el fallo de seguridad que más impacto ha tenido en la historia de la seguridad web desde que nació la Web.

Figura 1: Cómo convertirse en Tripulante Aéreo Autorizado con un

SQL Injection Level 1 (y saltarse las colas de seguridad de los aeropuertos)

Yo le dediqué años de estudio a las técnicas de SQL Injection, di muchas charlas, publiqué muchos artículos, fueron parte de mi trabajo de doctorado, y acabamos publicando un libro con todo esto que a día de hoy sigue siendo uno de los más vendidos, quizá porque sigue siendo fundamental para un pentester o un developer conocer estas técnicas y sus riesgos.

Figura 2: Libro Hacking de Aplicaciones Web "SQL Injection" 4ª Edición

de Enrique Rando, Chema Alonso y Pablo González en 0xWord

Hoy en día no es tan fácil encontrar estas vulnerabilidades como lo fue hasta el año 2010, donde saber SQL Injection era equivalente a tener siempre comodines en la manga. Aparecía en cualquier sitio. Un SQL Injection, un Blind SQL Injection, uno de errores ODBC, un Remote File Downloading, un Time-Based Blind SQL Injection, un Arithmetic Blind SQL Injection. 

Figura 3: NT Web Technology Vulnerabilitys de rfp

(en la Wayback Machine)

Recuerdo jugar con la web de mis admirados Fernando Alonso y Pedro de la Rosa que tenían unos bonitos SQL Injection en sus páginas web, pero podría enumeraros centenares de ellas que aún tengo en mi cabeza. Una de las veces, en el año 2009, fui invitado a ir a la Yahoo! Security Week a dar una charla de Web Security a los Paranoids de Yahoo! Allí Palako y yo hicimos Live-demos de SQL Injection hasta que recibimos un mensaje en papel que ponía: "Please, no more non-Yahoo! sites live demos". Era tan fácil, estaba por tantos sitios, que casi podías hacer lo que quisieras en cualquier página web del mundo. Si es que servía hasta para ligar.

Bypassing airport security via SQL injection 

Hoy en día, 26 años después, a mí me gusta aún, de vez en cuando, echar un ojo y buscar algún sitio que aún tenga estos bugs clásicos, para ver si siguen existiendo y para sentir que he rejuvenecido y he vuelto a tener 25 años y estoy haciendo un pentest a una web. Busco alguno, lo reporto, y luego publico un post de eso por aquí. Es mi pasión, qué os puedo decir que no sepáis ya.

Figura 4: La plataforma para autorizar KCM

Pero parece que no se han erradicado del todo, y dos investigadores, Ian Carroll y Sam Curry, han encontrado un SQL Injection de libro, Level 1, en la web que controla el sistema de autorización de los Known Crewmembers (KCM) o tripulantes conocidos de las compañías aéreas, que tienen cola de acceso priorizada en los aeropuertos americanos gestionados por la TSA (Transportation Security Administration).

Figura 5: Login con SQL Injection Level 1

El sistema de administración es un portal web de acceso púbico sin VPN, sin Passkeys, sin 2FA, sin control de mensajes de error, sin control de cuentas privilegiadas, sin WAF, y con un SQL Injection de libro que permitía poner un 'or '1'='1  y tener un bonito acceso al panel de administración para poder ver los nombres de usuario y las credenciales, en hash MD5, de todos los usuarios de los sistema, además de los datos de todos los tripulantes. Ahí, ¡a lo loco!

Figura 6: Administración de los KCM

Pero por supuesto, lo mejor es que te podías dar de alta como KCM dentro de la plataforma, y luego, siguiendo las reglas de los KCM acceder a esas colas en todos los aeropuertos americanos gestionados por la TSA.

Figura 7: Prueba de acceso de un nuevo KCM

¿Os acordáis de la famosa película de "Catch me if you can" de Leonardo di Caprio con la escena en la que accede a los aeropuertos vestido de piloto para ir de un lugar a otro? Pues con un SQL Injection de Level 1, hasta mediados de 2024 era así de sencillo. 

Figura 8: Reglas de acceso para los KCM

(lo de las azafatas de la película es opcional)

Hoy en día el bug ha sido corregido, que los investigadores han hecho Responsible Disclosure. Pero no me digáis que no es una historia que te hace caer una lagrimilla al ver ese SQL Injection.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Nuestro nuevo "viejo" libro de Hacking de Aplicaciones Web: SQL Injection 4ª Edición ya disponible

Algunos de los libros que publicamos en 0xWord se han convertido ya en compañeros de viaje de toda mi vida. Libros como Pentesting con FOCA, Hacking Web Technologies, Metasploit para Pentesters, Ataques en redes de datos IPv4 & IPv6, Pentesting con Kali Linux, Máxima Seguridad en Windows o Ethical Hacking, llevan miles y miles de ejemplares vendidos y han servido como parte del material de formación de centenares de cursos. Son libros que cuidamos y, edición tras edición intentamos mejorar, corregir, y dejar actualizado. Y entre ellos está el que hoy sacamos la 4ª Edición. El libro de Hacking de Aplicaciones Web: SQL Injection.

Figura 1: Nuestro nuevo "viejo" libro de Hacking de Aplicaciones Web: SQL Injection 4ª Edición ya disponible

Este libro, que sacamos entre Enrique Rando y yo hace ya una década, lo hemos ido actualizando, con la colaboración de Pablo González, para que siga estando de actualidad y los nuevos pentesters que quieran entrar en este mundo puedan estudiar y aprender con él. Son más de 4.000 ejemplares de este texto que hacemos con tanto cariño.

Figura 2: Libro Hacking de Aplicaciones Web "SQL Injection" 4ª Edición

de Enrique Rando, Chema Alonso y Pablo González en 0xWord

El contenido sigue teniendo la misma base que tenía desde la primera edición, pero con cambios y correcciones - algunas aportadas por los lectores - para hacer más entendibles, reparar un error, o añadir una pequeña explicación extra que deje más claro un concepto que no quedaba claro. 

Figura 3: Índice del libro "Hacking Aplicaciones Web: SQL Injection 4ª Edición"

Y, para entender mejor el objetivo de lo que cuenta el libro, las palabras de Enrique Rando presentándolo en  su descripción:

Si fuera preciso explicar qué es un programa a alguien que no conociera nada en absoluto sobre el tema, quizá habría que comenzar indicándole que es "algo muy complejo". Algo que, aunque no lo parezca, hace muchas cosas y se relaciona con muchas otras componentes para realizar su trabajo. Algo que obedece ciegamente y al pie de la letra las instrucciones de su autor. Y algo a lo que no le preocupan las consecuencias de sus actos.  

 

Complejidad. Ésa es la clave. 

Tanto en el producto como en el proceso de elaboración. Miles de líneas de código. Algoritmos complicados. Entornos de ejecución cambiantes. Presiones para entregar el producto en una determinada fecha. Escasez de medios humanos, materiales y técnicos... Pero esto es sólo el principio: después viene la puesta en producción y su posible exposición al mundo exterior. Un mundo que también es complejo. 

Visto lo visto, no es de extrañar que los programas contengan fallos, errores, que, bajo determinadas circunstancias los hagan funcionar de forma extraña. Que los conviertan en algo para lo que no estaban diseñados. Aquí es donde entran en juego los posibles atacantes. Pentesters, auditores,... y ciberdelincuentes. Para la organización, mejor que sea uno de los primeros que uno de los últimos. Pero para la aplicación, que no entra en valorar intenciones, no hay diferencia entre ellos. Simplemente, son usuarios.

Esperamos que este libro, con el que muchos habéis estudiado, siga siendo un compañero de viaje nuestro y vuestro, que mientras que las vulnerabilidades de SQL Injection sigan existiendo, nosotros seguiremos trabajando en este área tan bonita que es el pentesting.

¡Saludos Malignos!

Autor: Chema Alonso

Contactar con Chema Alonso

La base de datos de WhatsApp en iPhone sigue sin cifrar, y estamos en 2020

Durante muchos años y posts, he escrito recopilando las técnicas que existen para Espiar WhatsApp, y cómo se debe Fortificar WhatsApp a Prueba de Balas. Hemos ido viendo las evoluciones de seguridad de WhatsApp cambiando versión a versión, pero hay una en concreto que en iPhone, sigue siendo una debilidad que Facebook no ha arreglado con el paso de los años.

Figura 1: La base de datos de WhatsApp en iPhone sigue sin cifrar, y estamos en 2020

La característica a la que me refiero, que Facebook no ha arreglado con el paso de los años, tiene que ver con el cifrado de la base de datos de mensajes de chats de WhatsApp en iPhone, donde nos encontramos con que aún, en el año 2020, después de un número ingente de ataques a la privacidad de las personas, sigue sin cifrar. 

Figura 2: Libro de Hacking iOS: iPhone & iPad 2ª Edición

Estas debilidades en iPhone, son las que hemos ido utilizando a lo largo de los años para Hackear iOS: iPhone & iPad, y ésta de hoy es una que debería arreglar WhatsApp y tú deberías tener en cuenta. Las tres partes que recogen la fortificación de WhatsApp que os he recogido las tienes aquí:

- PARTE 1: Cómo evitar que te roben la cuenta de WhatsApp
- PARTE 2: Cómo evitar que te espíen los mensajes de WhatsApp
- PARTE 3: Cómo mejorar la privacidad con WhatsApp

Por supuesto, que un atacante llegue a la base de datos de mensajes de los chats de Whatsapp exige que antes hayan caído otras medidas de seguridad de tu dispositivo, pero no tiene sentido dejar una puerta abierta a un atacante, porque al final, la seguridad de tu WhatsApp queda en manos de otras medidas de seguridad y no aplica los principios de Defensa en Profundidad de cualquier proceso de fortificación de tecnología. Hace ya muchos años, en el año 2015, di una charla que se titulé Tu iPhone es tan (in)Seguro como tu Windows, donde hablaba de cómo la seguridad de tu smartphone - y por ende tu WhatsApp - puede depender del equipo Windows al que te pareas.

Figura 3: Tu iPhone es tan (in)seguro como tu Windows

Para que veas como funciona esto, puedes hacer una prueba muy sencilla con tu terminal iPhone. Basta con que te bajes una aplicación para gestionar tus ficheros de iPhone. En este caso iMazing que hace el trabajo de conectarse a tu iPhone si estás en un equipo en el que hayas confiado. Como se puede ver, cuando conectas un iPhone a tu MacOS o tu Windows para extraer fotos, hacer backup, etcétera, estás dando acceso a tu terminal iPhone a todo programa que corra con privilegios en tu Windows o Mac.

Figura 4: iMazing te extrae todos los ficheros haciendo un backup sin cifrar

Esos programas, antiguamente, se conectaban al sistema de ficheros de tu iPhone o iPad, pero Apple fortifico esta característica, y ya no es posible. La sandbox de aplicaciones es buena, y no se puede meter  mucha mano a las apps tal y como se hacía antes, con programas como iFunBox, pero... ¿quiere decir que esto no se puede hacer?

Figura 5: Acceder a la SandBox de la app de WhatsApp ya no se puede directamente 

Pues no, lo que hacen aplicaciones como iMazing es aprovecharse del pareado de tu equipo de confianza para hacer un backup SIN CIFRAR de tu iPhone al equipo pareado. Es decir, fuerzan una copia de seguridad desde el equipo MacOS o Windows al que conectas tu iPhone y extrae todos los ficheros sin cifrar de tu iPhone para dejarlos en el disco duro del equipo. Y entre ellos tu base de datos de WhatsApp.

Figura 6: Ficheros de iOS copiados al Mac

Así que, desde cualquier equipo pareado en el que confíe tu iPhone se puede extraer todo el sistema de ficheros de iPhone sin cifrar. Una vez que se realice ese backup sin cifrar, tendremos en el disco duro del ordenador la base de datos de WhatsApp, que como he dicho al principio, está sin cifrar también. Encontrar el fichero, es bastante sencillo, ya que es un hash y se puede localizar navegando conocido que se genera a partir de la ubicación del fichero dentro del sistema de archivos de iOS, y ya se puede navegar fácilmente por los backups desde tu MacOS.

Figura 7: Con estos tres ingredientes, tenemos todo

Así que, una vez localizado ese fichero, y sabiendo que ese fichero, llamado ChatStorage.sqlite, es un almacén de base de datos SQLite, lo único que tiene que hacer cualquiera es usar un visor de ficheros SQLite y abrirlo. 

Figura 8: En las tablas de la base de datos están los mensajes

Una vez que abras ese fichero, podrás ver que los mensajes de tus chats de WhatsApp están en texto plano y se pueden ver los mensajes que has enviado y recibido en cada uno de los chats.

Figura 9: Y toda la base de datos de contactos

Lo que quiere decir que la seguridad de tu WhatsApp depende de la seguridad de tu iPhone y, en este ejemplo concreto, de la seguridad de tu Windows, tal y como en el mundo del cibercrimen, de los APTs y de la privacidad personal, hemos visto durante los últimos años.

¿Debería cifrar WhatsApp la base de datos de mensajes en el dispositivo?

Pues si seguimos los principios de fortificación de sistemas informáticos, que dependen de aplicar Mínimo Privilegio Posible, Mínima Superficie de Exposición y Defensa en Profundidad, mi opinión personal está clara: 

Debería haberlo hecho hace años.

Mientras tanto, debes tener un cuidado especial de a qué equipos conectas tu iPhone ya que, aunque tú hagas copias de seguridad cifrada, con programas con iMazing se pueden forzar las copias de seguridad sin cifrar y todos tus archivos - fotos ocultas incluidas - se irán para allá. En este vídeo os explico lo que podéis ver en este artículo, pero contado por mí.

Figura 10: Notas sobre el (No) cifrado de la base de datos de WhatsApp en iPhone

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

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"

SIDU: Un Database Web GUI para escanear servidores

Este domingo por la noche no conseguía dormirme con la vuelta al trabajo por lo que aproveché para revisar algunas cosas en Internet. Esta vez le tocó el turno a los ataques a cadenas de conexión de bases de datos, así que, como ya hiciera tiempo atrás con Chive, con SQL Web Data Administrator, MyLittleAdmin, MyLittleBackup, ASP.NET Enterprise Manager o las aplicaciones Citrix, busqué algún nuevo panel de control de bases de datos por medio de un interfaz web, y di con SIDU, una herramienta que permite gestionar motores de bases de datos MySQL, Postgres, SQLite y CUBRID.

Figura 1: SIDU - Un DB Web GUIO con bugs de XSPA

Encontrar la herramienta publicada en Internet no es difícil. Hay muchas organizaciones que tienen este tipo de aplicaciones en sus sitios web, para poder administrar sus bases de datos, y ésta, en concreto, viene con muchas posibilidades.

Figura 2: Lista de bases de datos a las que se puede conectar para lanzar comandos SQL

Como se puede ver, permite hasta Microsoft SQL Server, por lo que podría ser una víctima propicia para los ataques de Connection String Parameter Polution, pero lo cierto es que necesita un driver especial en los entornos en los que mirado. Pero sí que se pueden hacer otras cosas, como vamos a ver.

Remote XSPA (Cross-Site Port Attacks)

Estas herramientas son propensas a la vulnerabilidad de XSPA (Cross-Site Port Attacks). Al final, una cadena de conexión a una base de datos permite introducir una dirección IP o nombre de dominio de un servidor de bases de datos y un puerto, por lo que si los mensajes de error no han sido controlados, alguien podría manipular estos servicios para valores para escanear servidores. Por supuesto, esta escaneo se puede hacer a tres niveles distintos:

1.- Escanear puertos del propio servidor de bases de datos: Bastaría con manipular el valor del puerto con respecto a localhost. 

2.- Escanear puertos de cualquier servidor de Internet: Esto se podría realizar si el firewall de la infraestructura de red donde está montado el servidor web que hospeda a SIDU no controlar las conexiones de salida. 

3.- Escanear la DMZ: Esto se podría hacer si se averigua la dirección IP local del servidor en el que está hospedado SIDU.

En la última versión, en la 5.3 de SIDU, la vulnerabilidad de XSPA está presente, y basta con hacer unas sencillas pruebas para comprobarlo. En este caso vamos a ver como un puerto está abierto o cerrado según los mensajes de error. Para ello he elegido la web de un diario.

Figura 3: El puerto está cerrado

Cuando el puerto está abierto, tal y como se puede ver arriba, el mensaje de error que se obtiene es un Connection Time-Out, esto es así porque la conexión TCP nunca se abre.

Figura 4: El puerto está abierto

Por el contrario, cuando el puerto está cerrado, el mensaje que se obtiene es completamente distinto. En este caso un "MySQL Gonne Away", porque el puerto TCP se abre pero está esperando el desafío de login de MySQL que nunca llega.

Figura 5: El puerto está abierto y es un MySQL

Si el puerto estuviera abierto, y además hubiera un servidor MySQL en él, se obtendría aún un tercer mensaje de error, informando de que el usuario y la contraseña son incorrectos, con lo que tendríamos el bug de XSPA completo.

SIDU PHP Info: Local IP disclosure

Para poder hacer lo mismo en el servidor local, bastaría con cambiar el puerto con localhost, pero si lo que deseamos es hacerlo con la DMZ, entonces hay que averiguar cuál es la dirección IP de la red local con que se ha configurado el servidor web que hospeda a SIDU. Esto, gracias al propio SIDU es una tarea bastante sencilla.

Figura 6: Conexión a una base de datos SQLlite que no existe

Una de las cosas que trae SIDU, es una conexión para lanzar consultas a bases de datos SQLite que no necesita usuario ni contraseñas. Cuando seleccionas esa opción, no se valida si la base de datos existe o no, así que puedes poner lo que quieras en ella y llegar al panel interno creado para lanzar consultas SQL.

Figura 7: En el menú interno hay acceso a un PHP Info

Lo mejor de todo es que, entre las opciones que han puesto en el menú se encuentra la de lanzar un PHP Info, tal y como se ve en la pantalla.

Figura 8: Acceso a la dirección IP local del servidor que hospeda SIDU

Y por supuesto, con esto llegaríamos a la dirección IP local del servidor web en el que se encuentra hospedado SIDU. Algo bastante sencillo de hacer para cualquier visitante. 

DMZ XSPA (Cross-Site Port Attacks)

Una vez que se tiene la dirección IP local del servidor web, se puede comenzar a escanear el segmento completo, haciendo un barrido a toda la red - en este caso de tipo C - para localizar todos los servidores que allí se encuentran.

Figura 9: Escaneo por puertos de MySQL del segmento de red

Como habría que escanear todos los puertos de todos los servidores, lo suyo sería buscar los well-known más comunes, como el 80 de los servidores web, o el propio puerto de los servidores MySQL de la red.

Figura 10: Connection String Attacks @ DefCON 18

Este tipo de herramientas de administración de bases de datos, donde delegan toda la seguridad en el establecimiento de conexiones, tienen habitualmente los mismos problemas. Os dejo arriba la charla de Connection String Attacks que dimos en DefCON por si te apetece repasar los fallos más habituales, así como los ataques que se pueden hacer.

Saludos Malignos!

Dorking & Pentesting con Tacyt: Las P@ssw0rdS

Dejando a parte la búsqueda de dominios, direcciones IP y puertos de momento - pero solo de momento que regresaremos un poco más adelante otra vez con ellos - en esta segunda parte vamos a ver algunos ejemplos bastante sencillos buscando únicamente nombres de ficheros concretos en los enlaces que hay dentro de las apps de Android. Claro que, mirando dentro de 4.5 Millones de apps y entre unos 50 Millones de enlaces, siempre aparecerán cosas curiosas.

Figura 1: Dorking & Pentesting con Tacyt: Las passwords

Estas búsquedas pueden llevar a resultados inesperados, pues muchos desarrolladores guardan la información sensible de sus sistemas en ubicaciones remotas enlazadas con un hipervínculo - por eso de que no se queden hardcodeadas en el código (sniff) - así que puede aparecer de todo.

¿Dónde pongo las passwords?

Sorprende ver la cantidad de veces que la gente es capaz de pensar que guardar la contraseña de algo en un fichero de texto es una buena idea. Así, basta con hacer una pequeña búsqueda por password o password.txt en los enlaces para descubrir que alguno utiliza este sistema.

Figura 2: Un fichero en Dropbox llamado gmailpushpassword.txt (por si no lo tenías claro)

De esto ya os había hablado en el pasado, y como podéis ver en una cuenta de Dropbox tenemos colgado un fichero con la contraseña de acceso al sistema de Gmail... ¿por qué? A alguien le pareció una buena idea.

Figura 3: Y ahí está la contraseña

Otra de las búsquedas que se pueden realizar es por los servicios de backend que guarden la lista de los usuarios y contraseñas. Para ello, buscando aplicaciones como UserList, Users, AllUsers, o similares, se puede llegar a lugares sorprendentes. En el siguiente ejemplo, tenéis un Users.txt de una app almacenado en el backend.

Figura 4: Una base de datos en un fichero Users.txt

Por supuesto, otra buena alternativa es utilizar una base de datos remota y cargarla en tiempo de ejecución. El uso de las bases de datos Sqlite es muy común, y buscando por dblink, database.db, BBDD, y nomenclaturas similares, es fácil dar con muchas de ellas con información sensible. Buscando por conexiones a bases de datos,  llegué a un app con un enlace a un connexion_mysql con un parámetro sin valor.

Figura 5: Acceso a una contraseña de administrador por medio de un enlace

Este en concreto, por defecto no devuelve nada, pero... como ya sabéis que siempre hay que revisar un poco la zona por si falta algún parámetro, tocando lo suficiente es posible llegar a conseguir la consulta que devuelve el usuario administrador y su contraseña. Como podéis ver, nada complicado para un atacante con hacerse con los datos.

En otro caso, la base de datos no estaba directamente enlazada, había un enlace que llevaba a un servicio que devuelve la ruta en donde se encuentra la base de datos. Más vueltas, para llegar al mismo destino.

Figura 6: Un enlace que da un enlace a una base de datos

La base de datos es pública - para que la pueda cargar la app - y por lo tanto toda la información en ella es accesible... aunque alguna vez nos cueste entender qué es lo que está guardando.

Figura 7: La base de datos

Por supuesto, jugando con nombres como AllUsers, UserList, Usuarios, etcétera, es fácil localizar un montón de servicios de backend desprotegidos totalmente con la lista de cuentas que utiliza el sistema.

Figura 8: Un enlace a una lista de usuarios en backend

Nada Rocket-Science para un atacante. La gestión de las credenciales siempre es un problema que hay que resolver de manera robusta, pero si a una app le das una credencial o le das un enlace a un fichero que publicado en algún lugar de Internet tiene una credencial, asume que se has dado a todo el mundo y que es pública, por lo que deberás pensar en algún mecanismo para protegerte contra ataques.

Figura 9: La lista de usuarios y sus códigos de accesos volcados del tirón

Eso sí, para la tercera entrega me guardo otra de las cosas favoritas como buena idea. Yo la titularía... "¿Oye, y si dejamos las credenciales de acceso a los servicios de tercero directamente configuradas como parámetros?" Este es otro gran problema arquitectónico en las apps cuando tiras de APIs remotas que exigen autenticación y esta se hace por parámetros que van por GET. El resultado es que...

Saludos Malignos!

***********************************************************************************

- Dorking & Pentesting con Tacyt: Dominios, IPs y Puertos

- Dorking & Pentesting con Tacyt: Las P@ssw0rds

- Dorking & Pentesting con Tacyt: Las APIs de terceros
- Dorking & Pentesting con Tacty: Inyección de Comandos

- Dorking & Pentesting con Tacyt: Diapos de RootedCon Valencia 2015

***********************************************************************************

En apps de Android en Google Play te puedes encontrar enlaces locales, a cuentas Dropbox y hasta a contraseñas

Ayer domingo, antes de acostarme decidí jugar un poco con Path 5, nuestro Big Data de apps de Android, para probar una serie de cosas que están rondando por mi cabeza. Como sabéis, en nuestra plataforma guardamos las apps y el entorno de publicación de las mismas para poder analizarlas a golpe de clics y poder realizar búsquedas o filtros que avisen cuando alguna app coincida con el patrón de búsqueda. Una vez que se genera esa lista de apps mediante un RSS, se puede automatizar su post-procesado con paneles de control realizados por Sinfonier, por scripts automáticos que decidan que apps deben ser analizadas con alguna otra plataforma de análisis de malware o directamente que llegue a un equipo HUMINT que revise las apps más sospechosas.

Figura 1: En los enlaces de apps de Android puede salir de todo

Entre las características por las que se pueden realizar búsquedas, están los enlaces o links, que aparecen en la app. Esta función permite localizar, entre otras cosas, cuando una app que aparentemente no tiene nada que ver con tu empresa, tiene enlaces a ella, que puedan estar usándose para hacer phishing y tomar imágenes de la web haciendo hotlinking, o simplemente para abusar de alguna función de los servicios expuestos. A nosotros, nos vino bien para descubrir la infraestructura completa de Shuabang Botnet.

Figura 2: Shuabang con nuevas técnicas en Google Play

Un vistazo rápido a enlaces en las apps de Android

Esta característica de buscar por enlaces de forma rápida y filtrada, nos permite, mediante los servicios de Vigilancia Digital, avisar cuando una nueva app está haciendo algo extraño y no controlado por el equipo de seguridad o de canales electrónicos de la empresa, pero también para detectar familias de adware que hacen uso de los mismos servicios para apuntarse dinero o, por ejemplo, hacer suscripciones ilícitas a servicios SMS de pago o similares como se hizo en la estafa de la linterna molona.

Figura 3: Apps con enlaces a cuentas de usuario de Dropbox

Como ayer era domingo, decidí perder un poco el tiempo a ver qué cosas era la gente capaz de poner en las apps que están publicadas en Google Play a día de hoy, probando cadenas que no deberían estar nunca en una app, pero que comprobado que incluso ponen sus Tokens de autenticación hardcodeados, podrían sorprenderme.

Figura 4: App con un enlace a un servidor local

Por supuesto, el número de enlaces a localhost, o a direcciones internas de la red exponiendo la infraestructura de la empresa es altísimo. Son muchas las que hacen eso a pesar de que todas las prácticas de desarrollo seguro de Android explican claramente que no deberían.

Figura 5: Enlaces remotos para cargar las API Keys

Entre las cosas que me dio por mirar, estaban los enlaces a Dropbox, para ver qué uso estaba dando la gente de este servicio. Curiosamente, muchas, y cuando digo muchas son muchas apps, están cargando sus configuraciones, API Keys, y datos desde ubicaciones públicas en DropBox.

Figura 6: Otro enlace remoto para cargar API Keys

En lugar de hacer un servicio en sus servidores y utilizarlo, ponen un archivo publicado en una carpeta de Dropbox y lo van actualizando.

Figura 7: Un enlace a la password de Gmail en Dropbox

Mirando lo que la gente pone en Dropbox para alimentar sus apps, aparecen las API Keys de servicios, pero uno incluso pone un fichero con la contraseña de una cuenta de Gmail que está utilizando para hacer notificaciones Push según parece, lo que no deja de ser un fallo de seguridad bastante peculiar.

Figura 8: El Fichero con la passwod. Comienza por Money... }:)

Algunas apps, hasta enlazan ficheros user.txt con cuentas de acceso que pueden utilizarse. Tal y como se ve, tienen datos de usuarios de QA y de pruebas, con ninguna complicación en las contraseñas.

Figura 9: Lista de usuarios cargado desde un txt remoto

De todos los enlaces curiosos que encontré, hubo uno que se dedica a mostrar gente que ha sido vista por otras personas en la calle para poder saber quién es. La idea es sencilla, alguien ve a alguien y sube los datos de quién lo ha visto, cuándo y dónde, para que el resto de usuarios puedan darle información correcta de esa persona. Pues bien, la base de datos de esa app es un fichero subido a una cuenta de Dropbox.

Figura 10: Una base de datos en txt publicada en Dropbox. El fichero es muy largo.

Esto de tener la base de datos de la app enlazada no es raro, y de hecho algunas apps tienen ficheros en formato Sqlite con la base de datos que está usando la app enlazada remotamente para que se cargue en periodo de ejecución, y que cualquiera puede descargar de Internet.

Figura 11: Enlaces a base de datos de app en formato Sqlite

Si vas a hacer una app para Android, recuerda que los enlaces es algo que todo investigador va a analizar, así que ten cuidado con qué expones en ellos, ya que lo que pongas ahí será público.

Saludos Malignos!