Your entire SDcard in my webhost ~ Proof Of Concept

Note: I do not care if you want to share or translate the document, but please, quote me ;) . Thanks!

Brief

I have developed a Application for Android which stoles the File List of the SD-Card of the victim.

I do not use any kind of special trick. That is the real problem.

What does the exploit need?

It only needs “Internet” permission, so it is very easy to use in malicious apps (and persuade the user to get into the trap).

How it works…

You can read by DEFAULT the files in the SD-Card, so you only have to read them and send into Internet. I have deployed a webservice in a webhost that I can manage to do this PoC.

Download it here: (pname:poc.SDCard)Proof of Concept - Stealing SD-Card with an Android application

Why am I doing it?

Because I care about your security. I want you that you will experiment HOW EASILY it is. And then…

1) Think twice what kind of information you have in your SDCard

2) Think twice what apps you allow 🙂 The 90% of apps use the “Internet” permission.

Where is the real problem?

The problem is that the Google Developers have say: “Do not store sensitive information into your SDCard! only shared data!” … but the application developers (like Dropbox, whatapps, your camera, …) does not care a bit and they save your files there.

First, the application developers SHOULD care about you. And second, you should care about YOURSELF. If they do not care about you, do not use them.

Can you show us the source-code?

Main function: (yeah… too easy)


private void getFiles(File F) {
 for (File t : F.listFiles()) {
  DATA.add(t.getAbsolutePath()+"\n");
  if (t.canRead() && t.isDirectory()) {
   getFiles(t);
  }
 }
}

Are you storing my data with this App??

Calm. I am only sending your File List (it is a slow app… I know… I did not use Threads) to my webhost. I do not want your data (I could have send it too :P). I promise you that I am going to remove all the uploaded files of the webhost… BUT…. you can delete it too. Just click the button that appears in the app.

Argg!! It goes really slow…

Yes, I know. It gets the list of files, it is put in a string, it is sent to the webhost, and then it shows you the screen…

I promise it works… so start deleting all your data of the SDcard right now ;-).

Special Note: Do you use CyanogenMod or another custom Rom? They save by default a backup of your data as *.img files. Do you know that they contain ALL YOUR DATA OF YOUR ACCOUNTS? It is overLOL!…(this image was taken when I was coding the app…)

cyanogen-mod backups in *.img files

Conclusion

Any application that you have stored could do it. I hope you will learn something about it. Use a sniffer to know what the fuck your apps are sending… (yeah… they could send the data by a SSL channel).

Greets!

and if you have any question, contact me, of course!!

Note: If you see any spell mistakes, you can say me it. I would appreciate it ;) . Thanks!

Advertisements
Your entire SDcard in my webhost ~ Proof Of Concept

Session Fixation with PHP

Hace unos días asistí a un evento de OWASP,  donde se daban cuatro charlas de seguridad web. Una de ellas, realizada por Raúl Siles de Taddong, trataba el concepto de `Session Fixation´. Como hacía unos días que un amigo me había animado a revisar el código de EyeOS, intenté jugar con lo aprendido en la charla.

La vulnerabilidad localizada no es crítica ya que requiere de otra vulnerabilidad para fijar la cookie, y ya ha sido corregida en la última versión. La seguridad en un sistema no es más que el número de capas eficientes en cada proceso interno del software, y en este caso, había más protecciones en el proceso afectado. Lamentablemente, no sólo EyeOS fue/es vulnerable. Raúl Siles encontró vulnerabilidades en SAP, Joomla y otros sistemas, alertando que todavía más páginas están afectadas aún siendo una vulnerabilidad del año 2002.

El objetivo de esta entrada es analizar Session Fixation y cómo hay que tratarlo en PHP correctamente.

How to find a session fixation

Para localizar esta vulnerabilidad basta con observar que la cookie de session (por defecto PHPSESSID) no cambia aunque se loguee, se desloguee, se vuelva a loguear, etc. Lo que cambia son los valores internos, pero no el identificador.

El código fuente normalmente usa la función session_destroy(); pensando que es suficiente para regenerar la cookie, pero esa no es su función.

How to exploit a session fixation

Normalmente será necesario tener un `Cross-Site Scripting´ (XSS) o otra vulnerabilidad (\r\n) para inyectar el código malicioso. El proceso es asignar una session que se conozca y cambiar la fecha/dominio de la cookie para que nunca expire, es decir, que sea permanente (a diferencia de las cookies que expiran al cerrar el navegador). Esto se puede conseguir de diferentes maneras. Una de muy elegante es introducir por XSS el siguiente código:

<meta http-equiv=”Set-Cookie” content=”value=n;expires=date; path=url”>

Hay que jugar con la fecha de expiración y la ruta entre subdominios para obtener el impacto deseado, pero en cada web será diferente.

How to sanitize a session fixation

La función session_destroy(); hace lo mismo que poner a 0 el contenido del fichero que genera en la ruta de sessiones ( “/tmp” por defecto en entornos GNU/Linux). Por lo tanto, la función que hay que utilizar es session_regenerate_id(true); que no borra la session, pero que cambia el identificador, borrando el fichero de la antigua session, ayudando a controlar los ficheros residuales.

PHP facilita el trabajo de las sessiones, comprobando que el nombre de estas no contiene caracteres especiales (valid characters are a-z, A-Z, 0-9 and ‘-,’) y su longitud (cread una carpeta con nombre muy largo e insertaros una cookie de 128 caracteres (el máximo). Saldrá un error y no dejará continuar), pero hay que saberlas configurar.

How to steal sessions

Uno de los errores que ha crecido más en la lista OWASP es el `A6: Security Misconfiguration´. Los administradores de sistema están pensando que los software precocionados están preparados para instalarse y olvidarse. Pues no, empezando por PHP, MySQL, Apache, y cualquier otro que sirva de base para aplicaciones como Joomla, Drupal, etc.

Como se comentó, las sessiones suelen almacenarse en “/tmp” por defecto. Si se esta en un servidor compartido (vhost) lo más normal es que todos tengan acceso a esa partición, pudiendo leer las sessiones de los usuarios ya logueados. Creo que no hace falta comentarlo, pero robar la session es tan preocupante como que se roben los usuarios y las contraseñas. Al final la session es la manera de saber que tiempo atrás hubo una autentificación satisfactoria.

How to maximize the security

Hay dos consejos que considero adecuados aplicarlos:

1) Usar session_regenerate_id(true); en cada petición del usuario al servidor. Esto evitaría ataques `Cross-site request forgery´ (CSRF) tal como comentaba Raúl Siles. EyeOS no era vulnerable porque utilizaban un token interno por ellos que iba cambiando dependiendo del proceso y más variables, pero la session seguía en un nivel inferior.

2) Utilizar la función session_save_path(‘/path’); y session_cache_expire(); para asegurarse del directorio donde las cookies se guardan (OJO: es importante asignar los permisos correctos a esta ruta o sino el problema será el mismo) y reasignar el tiempo de expiración de la cache (defecto es 180) dependiendo de la aplicación.

Conclusions

He tratado el tema bastante por encima. En Taddong hay información muy buena del proceso completo para su detección y explotación. Aunque me haya centrado en PHP, la lógica se aplica a cualquier otro sistema: Si no se regenera la id, el sistema puede verse vulnerado. ¡session_Id con cuidado!

Session Fixation with PHP

Infectando aplicaciones Android

Note: I do not care if you want to share or translate the document, but please, quote me ;) . Thanks!

Resumen

Es posible infectar cualquier aplicación del sistema operativo Android hasta el próximo reboot del smartphone. Esto requiere de  una aplicación maliciosa con un exploit que de permisos root, es decir, se restringe a todo lo inferior a la Gingerbread (<2.3.x) que son más del 90% de dispositivos. Es la misma técnica que se utilizo con el DroidDream, pero en vez de crear nuevas aplicaciones e instalarlas, se aprovechan aplicaciones ya existentes.

DroidDream

El virus DroidDream ha sido el primero en cuestionar la seguridad en Android. Los pasos que hace son los siguientes:

  1. Se instala a través de varias aplicaciones de varios usuarios (unas 30 apps entre 3 usuarios).
  2. Estas apps, ejecutan 2 exploits: exploid y/o rageagainst-the-cage, obteniendo root.
  3. Aún si no se obtiene, se envia el IMEI, ISMI, version de Android, etc. a un webservice del atacante.
  4. Instala una nueva aplicación, la cual se encarga de robar más datos.

Se puede obtener mucha más información en esta dirección (y los enlaces a los que apunta): http://blog.fortinet.com/android-droiddream-uses-two-vulnerabilities/

Lo que interesa es preguntarse: ¿Porque instala una nueva aplicación?

Seguridad by Google y sistema de firmas

Google es capaz de borrar remotamente aplicaciones del móvil (por nuestra seguridad…). Dado que todas las aplicaciones tienen una firma única, Google puede dirigirse a cada una de ellas inequívocamente. Así que la razón por la que instalaron los atacantes una nueva aplicación externa fue justamente para que Google no conociera su firma y no pudiera borrarla.

Poco después, la comunidad XDA-Developers descubrió un parche, tan simple como crear el fichero “/system/bin/profile” a través de la shell. Más información en http://forum.xda-developers.com/showthread.php?t=977154

Volviendo atrás, cuando un programador crea una aplicación, utiliza una clave privada que certifica que esa aplicación es suya y no es modificable por nadie más. Es muy importante guardar bien esa clave privada fuera del alcance de malas manos, sino se puede refirmar una aplicación como si fuera original. Aún así, el sistema Android permite ejecutar cualquier aplicación firmada (hasta modo debug), donde firmada significa que el contenido de “/META-INF/*” que se encuentra en el interior del APK lleva todas las firmas de todos los ficheros incluidos en el APK y se corresponden los hashes SHA1-DIGEST. Un ejemplo:

ejemplo_metaInfEl sistema operativo comprueba en 2 ocasiones que los paquetes esten firmados:

  1. Cuando se INSTALAN del Market o de cualquier otro sitio (consola)
  2. Cuando se reinicia el sistema operativo comprueba que son validos, sino los desactiva

Entonces, ¿y si se mueve directamente a la carpeta de “/data/app/*.apk”? ¡Zas!

Reemplazando aplicaciones existentes

Para hacerlo divertido, vamos a hacer un ejemplo. (En esta ocasión, no explicaré como se hace reversing a aplicaciones Android, pero con apktool, dex2jar y el DDMS de Eclipse hay de sobras.)

Lo primero, escogemos una victima. La aplicación será la Esdeveniments, una cutre aplicación del PSC que sólo tiene un WebView.

  1. La instalamos en el smartphone
  2. La enviamos al pc a través del ASTRO Manager o del DDMS (obtened root en la shell con el OneClick)
  3. Renombramos el APK a ZIP
  4. Abrimos el ZIP, y reemplazamos los icon por calaveras y el main.xml lo editamos (ojo que tendréis que pasar de raw a ascii).
  5. Se vuelve a renombrar como APK, y con el DDMS, se hace push del fichero a /data/app/nombre_original.apk

El resultado es que, aunque el icono del escritorio no cambia (a excepción de volverlo a arrastrar y recrearlo), cuando se abre la aplicación:

Hay que acordarse que para hacer esto, se necesitan permisos root (hacer igual que DroidDream y ejecutar nativamente el exploit), pero se puede automatizar el proceso de forma muy sencilla para hacerse en TODAS las aplicaciones instaladas en el movil. Es muy facil desde una aplicación programar que abra un APK, lo examine, modifique el main.xml, un archivo *.so (si se trabaja con NDK), o cualquier otro recurso, y lo vuelva a empaquetar. Imaginad que hace esto que digo de infectaros todas las aplicaciones… y reiniciáis el móvil :D. Adiós a todas vuestras aplicaciones. (un geek podría volvérselas a poner, o usar el recovery, pero ¿¿acaso no llegarían quejas a los proveedores de móviles??)

Entonces, ¿qué?

La seguridad de Android reside EXCLUSIVAMENTE en no ser vulnerable a un exploit. Aunque aquí se haya mostrado que se puede infectar otras apps, también se puede reprogramar el sistema entero, instalando rootkits que no sois capaces de imaginar. Os animo a pedir a vuestros proveedores (movistar, vodafone, etc) que os ofrezcan las últimas actualizaciones del sistema operativo (GingerBread, 2.3.3), o sino, quien sabe si la próxima vez que abráis la aplicación de Gmail o Facebook sale mi cara 😀

Fe de erratas

Sin querer, aprete al botón de enviar mientras hacia pruebas.Lo siento…

…pude descubrir otra forma de debugging: provocando los errores a posta 😉

Infectando aplicaciones Android