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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
 |
| 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: Las APIs de terceros
- Dorking & Pentesting con Tacty: Inyección de Comandos
- Dorking & Pentesting con Tacty: Inyección de Comandos
***********************************************************************************
Por empezar, almacenar una contraseña en texto plano me parece horroroso, así la base de datos sea super segura. Creo que lo más común es almacenar el resultado de un hash y comparar al momento que el usuario ingresa la contraseña.
ResponderEliminarme dio miedo
ResponderEliminarwow , como siempre la malas practicas que ponen en riesgo la informacion del usuario final
ResponderEliminar