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

lunes, 2 de julio de 2018

Nuevos ataques contra el protocolo de red LTE (4G) y posible afección a 5G

El protocolo Long Term Evolution (LTE) más conocido como 4G es vulnerable a la interceptación y/o modificación de la comunicación de forma remota


Fuente: https://thehackernews.com/2018/06/4g-lte-network-hacking.html

Muchas compañías de comunicación implementan el protocolo LTE o, como se conoce normalmente, 4G, presente en la mayoría de dispositivos móviles. Las tecnologías provenientes de esta familia (3G, 4G, 5G) se gestan para proveer de mayor seguridad (entre otras cosas más) al antiguo protocolo GSM.

Un equipo de investigadores ha descubierto una vulnerabilidad en el protocolo que podría permitir a los atacantes espiar las comunicaciones que usan el mismo, pudiendo modificar el contenido e incluso redirigirlas a sitios web maliciosos.

Los investigadores han desarrollado tres nuevas técnicas contra esta tecnología que les permiten obtener la identidad de los usuarios, los sitos web visitados y redirigirlos a sitios web maliciosos a través de la suplantación DNS.

Podemos catalogar estas técnicas como "ataques pasivos" y "ataques activos". Interceptar la comunicación y la visualización de los sitios web visitados pertenecen a ataques pasivos. Por otro lado tenemos el ataque de suplantación de DNS conocido como "aLTEr" que permite a un atacante realizar un "MiTM" para interceptar las comunicaciones y redirigir a la víctima al sitio web malicioso utilizando "DNS Spoofing".





La capa de enlace de datos de LTE está cifrada con AES-CTR, pero no está protegida su integridad, lo que permite a un atacante modificar los bits dentro de un paquete de datos cifrados. En los ataques LTE un atacante pretende emular una estación de comunicación real y así tomar el control de la comunicación. El ataque es muy peligroso pero difícil de explotar, ya que necesitamos hardware específico para ello, teniendo un alcance efectivo de casi 2 kilómetros

El futuro 5G

Las futuras redes 5G también se puede ver afectadas. Si bien es cierto que 5G admite el cifrado autenticado esta función no es obligatoria, lo que nos hace pensar que la mayoría de las compañías no tendrán intención de implementarla.

Para protegerse como usuario de estos ataques solo se ha recomendado usar "HTTPS". El peso de la protección contra esta vulnerabilidad depende de las operadoras, que podrían solucionarlo actualizando su especificación de LTE (4G) para que use un protocolo de cifrado y autenticación como AES-GCM o ChaCha20-Poly1205. Sin embargo esto conlleva que las operadoras hagan un esfuerzo financiero y organizativo.

El equipo de investigadores ha liberado un PDF con los detalles técnicos del ataque, disponible en el apartado "Más información".

viernes, 11 de mayo de 2018

Disponible el informe anual del CCN-CERT sobre amenazas y vulnerabilidades en dispositivos móviles

El CCN-CERT (Centro Criptológico Nacional) ha publicado el informe anual sobre las amenazas y vulnerabilidades en dispositivos móviles.

El informe, nos muestra un recorrido por todo lo acontecido a lo largo de 2017 en materia de seguridad en dispositivos móviles. Sin lugar a dudas, y tal y como refleja el propio informe en su introducción, estos sistemas poseen una amplia adopción tanto en el mundo profesional como en el personal. Esto se refleja también en la orientación o tendencias del malware, cada vez más enfocado en el mundo móvil.





Un hecho destacable es la predominancia del sistema operativo Android y la casi completa desaparición del malogrado Windows Phone. Respecto a Android se vuelve a confirmar algo que ya sabíamos y que hemos repetido varias veces desde Una-al-día: la fragmentación de Android. Un fenómeno que no solo fastidia a los desarrolladores de la plataforma de Google, sino que también significa que una larga porción de usuarios podría estar exponiéndose a vulnerabilidades que afectan a versiones sin soporte.

No obstante, respecto a la fragmentación de Android, el informe recoge una interesante iniciativa que intentará paliar los efectos de este fenómeno. Básicamente, se trataría de separar la capa de personalización de los fabricantes del sistema base. Esto, facilitaría que el gigante del buscador pueda ofrecer actualizaciones de forma más rápida a los usuarios, sin tener que esperar meses o de manera indefinida a un parche producido por el fabricante del terminal.

El informe, también dedica un capítulo a explorar las diferentes medidas se seguridad biométrica, como el sistema FaceID de Apple, el escaneo del iris y reconocimiento facial de Samsung o el Intelligent Scan que estrenaron los dispositivos S9 y S9+ del mismo fabricante. 

Otros aspectos destacables del informe son la adopción paulatina de formas adaptadas de inteligencia artificial en estos dispositivos y los sistemas de protección frente a desbloqueos y extracción forense de datos en caso de sustracción o pérdida del terminal. Recordemos la importancia de estas plataformas hace que sean un objetivo muy apetecible para el robo de información sensible, sobre todo en el ámbito de las organizaciones y gobiernos.

A destacar la parte de análisis de las amenazas más destacadas en el sentido del malware que afecta a sistemas operativos móviles, en la que vuelve a ser el protagonista Android, así como la orientación de los objetivos del código malicioso a explotar las capacidades computaciones de estos sistemas para minar criptomoneda.

En resumen, una interesante lectura que glosa lo acontecido en seguridad de sistemas y plataformas móviles durante el pasado año y marca, a su vez, las lineas de tendencia que podría seguir el presente año.



sábado, 28 de octubre de 2017

Las aplicaciones de citas, bajo la lupa de la seguridad

Investigadores de Kaspersky Labs publican un extenso e interesante estudio sobre las medidas de seguridad presentes en las aplicaciones de citas online. 

El estudio abarca un total de 9 plataformas, incluidas las populares Tinder y Badoo, sobre las que se realiza un análisis en diferentes aspectos de la seguridad de las que la mayoría no salen del todo bien paradas.

Tabla resumen de los problemas de seguridad en las distintas aplicaciones de citas.
Imagen tomada de https://securelist.com/dangerous-liaisons/82803/

Una de las principales preocupaciones es que los datos proporcionados por la aplicación permitan a acosadores ir más allá de esta y les permita encontrar a otros miembros de la plataforma en otras redes sociales o incluso en el mundo real. Por ejemplo Tinder y Bumble permiten publicar a los usuarios datos sobre trabajo y estudios, lo que permitiría estrechar el cerco sobre ellos a la hora de localizarlos. Happn, además, guarda un campo 'fb_id' que en ciertos escenarios muestra directamente el identificador en Facebook.


Un problema aun más serio es el relacionado con las capacidades de localización. Dos tercios de las aplicaciones permiten fácilmente localizar a otros usuarios mostrando la distancia entre el atacante y ellos. Eso sí, cada cual con su propia exactitud.


Un perfil de la plataforma mostrando la distancia hasta el usuario.
Imagen tomada de https://securelist.com/dangerous-liaisons/82803/

En cuanto a la seguridad de las comunicaciones, la mayoría de las aplicaciones utilizan, en algún punto, cifrado TLS. Y decimos "en algún punto" porque en ciertas transacciones de datos no es usado. Por ejemplo, Tinder, Paktor, Bumble (Android) y Badoo (iOS) realizan peticiones con fotografías sin cifrar y otra información como localización y datos personales. La aplicación Mamba, además sube datos específicos del dispositivo como su fabricante y modelo. Tanto en esta como en Zoosk, un atacante que esté capturando e inyectando tráfico podría llegar a administrar la cuenta.

Y aun usando HTTPS en el resto de comunicaciones el usuario sigue estando en riesgo, ya que la mayoría de las aplicaciones no comprueban la validez de los certificados. Excepto Badoo, Bumble y Zoosk en su versión Android, las aplicaciones son vulnerables a ataques "Man in the Middle" mediante el uso de certificados no verificados, llegando a interceptar en algunos casos tokens de autenticación y contraseñas. 

Como punto final, en un escenario que afecta especialmente a los usuarios de Android, los datos almacenados en el teléfono por la mayoría de las aplicaciones son susceptibles al acceso por el usuario root. Esto significa que algunas aplicaciones capaces de obtener estos privilegios en el sistema (como por ejemplo algunos troyanos) pueden obtener credenciales de acceso y el listado de los mensajes enviados, entre otra información.

En conclusión, parece que es WeChat la que sale mejor parada, aunque desgraciadamente no es una aplicación de citas como tal. De estas, parece que Badoo y Bumble, en sus versiones para iOS, son las que mayor nivel de seguridad ofrecen.

Aunque el listón no está precisamente alto.



Francisco López


Más información:

Dangerous liaisons






martes, 22 de agosto de 2017

Chip-in-the-middle, o cómo atacar un dispositivo móvil desde dentro

En un estudio convenientemente titulado "Shattered trust" ("Confianza hecha añicos") investigadores de la Universidad Ben-Gurión del Néguev han analizado la posibilidad de instalar componentes maliciosos en las pantallas de teléfonos móviles. 


Configuración final del ataque


La motivación principal para explorar este vector de ataque es que, a diferencia de otros componentes externos del dispositivo, se asume que el código de los controladores internos es seguro y su autenticidad apenas es probada más allá de algunas pruebas de integridad. 

Teniendo en cuenta que las pantallas, como otras piezas de reemplazo no originales, son fabricadas por terceras partes ajenas al fabricante de teléfono, su bajo coste (las hay por menos de 10 dolares), la facilidad de producción en masa, y, por qué no decirlo, la extraña facilidad que tenemos para romperlas, este tipo de ataque es, en palabras de los investigadores, posible y práctico.


Diagrama de la prueba de concepto


Un punto importante es que en el desarrollo se supone cierto que el técnico que reemplaza la pantalla no es un actor malicioso, es decir, simplemente cambia una pantalla defectuosa por la nueva tal como le ha sido distribuida.

Ataque "chip-in-the-middle"

El estudio ha combinado dos técnicas que difieren en enfoque. En primer lugar, instalaron un micro-controlador haciendo uso de los mismo pines usados en la comunicación entre la placa controladora de pulsaciones y la placa principal, en lo que han llamado un ataque "chip-in-the-middle". El posicionamiento de este micro-controlador le permite tanto espiar las pulsaciones del usuario como inyectar pulsaciones propias, controlando incluso la interacción con el teclado.

Hasta aquí el ataque ya cuenta con bastante gravedad, pero es posible llevarlo más allá. Además, el micro-controlador puede ser aprovechado para explotar vulnerabilidades en el sistema operativo. En este caso, se explotó un desbordamiento de buffer en el código del driver del controlador de pantalla, situado en el mismo núcleo de Android, que permitió la ejecución de varios payloads arbitrarios.






Combinando ambas técnicas, los investigadores pudieron comprometer la identidad del usuario y tomar control sobre las acciones y los datos del dispositivo. Estos resultados han sido presentados la semana pasada en la conferencia WOOT'17 celebrada en Vancuver, Canada.

En definitiva, este estudio intenta hacer hincapié en la poca atención que reciben las vulnerabilidades situadas a bajo nivel, como en aquellas en los drivers del sistema. Pero sobre todo pone el foco no solo en las falsificaciones, sino también en otros accesorios y componentes no originales. Aunque su bajo precio y su conveniencia los hacen muy populares, sus componentes internos son en muchas ocasiones de baja calidad y, lo que es peor, quedan fuera de la cadena de confianza del fabricante, lo que los hace vulnerables a la instalación de componentes maliciosos.


Francisco López
flopez@hispasec.com

Más información:

Shattered Trust: When Replacement Smartphone Components Attack [PDF]

https://iss.oy.ne.ro/Shattered.pdf

Canal de Youtube con demostraciones adicionales:
https://www.youtube.com/channel/UChyrYOp3neDyY0vnYj1c1RQ

viernes, 28 de julio de 2017

Lipizzan: el nuevo Malware espía detectado en Google Play

Hace unos días, Google anunciaba el descubrimiento de un nuevo malware para Android. Se trata de una aplicación maliciosa cuya misión es recopilar todo tipo de información personal sobre la víctima para después transmitirla al atacante.


El malware implementa rutinas para capturar datos de las principales aplicaciones de mensajería: WhatsApp, Telegram, Messenger, Skype, GMail, etc.

Además, permite controlar de forma remota la cámara, el micrófono y acceder a los archivos del dispositivo y a su localización.

Aunque no se conoce con seguridad su procedencia, los investigadores de Android Security han encontrado en su código referencias a Equus Technologies, una empresa israelí especializada en el desarrollo de herramientas de vigilancia. De hecho, para la investigación sobre Lipizzan se han utilizado las mismas técnicas que en el estudio de otras infecciones recientes como Chrysaor, desarrollada por NSO Group.

Logo de NSO Group


Cómo infecta Lipizzan

El virus se camufla como una aplicación legítima para realizar backups o para limpiar el sistema, poniendose a disposición del público en distintos markets y repositorios (incluído Google Play). La infección tiene lugar en dos etapas:
  1. Una primera etapa, en la que la víctima descarga e instala la aplicación.
  2. Una segunda, etapa en la que tras comprobar que el dispositivo es vulnerable, descarga las instrucciones necesarias para rootear el dispositivo y controlarlo.

Muestra de la segunda componente:

Media Server [Koodous]

Las últimas variantes del virus cambian el nombre de paquete, y ahora transmiten el exploit de la segunda fase de forma cifrada, lo que dificulta la detección. Además dispone de mecanismos de detección de máquinas virtuales para ocultar su verdadero comportamiento ante los ojos del analista inexperto.

A continuación uno de los ficheros de configuración que recopila alguna información interesante sobre el malware:


Extensiones de los archivos objetivo

"extensions": ["3dm", "3ds", "3fr", "3g2", "3gp", "3gpp", "3pr", "7z",
"ab4", "accdb", "accde", "accdr", "accdt", "ach", "acr", "act", "adb",
"ads", "agdl", "ai", "ait", "al", "apj", "arw", "asf", "asm", "asp", "asx",
"avi", "awg", "back", "backup", "backupdb", "bak", "bank", "bay", "bdb",
"bgt", "bik", "bkp", "blend", "bpw", "c", "cdf", "cdr", "cdr3", "cdr4",
"cdr5", "cdr6", "cdrw", "cdx", "ce1", "ce2", "cer", "cfp", "cgm", "cib",
"class", "cls", "cmt", "cpi", "cpp", "cr2", "craw", "crt", "crw", "crypt5",
"crypt6", "crypt7", "crypt8", "cs", "csh", "csl", "csv", "dac", "db", "db-journal",
"db3", "dbf", "dc2", "dcr", "dcs", "ddd", "ddoc", "ddrw", "dds", "der", "des",
"design", "dgc", "djvu", "dng", "doc", "docm", "docx", "dot", "dotm", "dotx", "drf", "drw", "dtd", "dwg", "dxb", "dxf", "dxg", "eml", "eps", "erbsql", "erf", "exf", "fdb", "ffd", "fff", "fh", "fhd", "fla", "flac", "flv", "fpx", "fxg", "gray", "grey", "gry", "h", "hbk", "hpp", "ibank", "ibd", "ibz", "idx", "iif", "iiq", "incpas", "indd", "java", "jpe", "kc2", "kdbx", "kdc", "key", "kpdx", "lua", "m", "m4v", "max", "mdb", "mdc", "mdf", "mef", "mfw", "mmw", "moneywell", "mos", "mov", "mp3", "mp4", "mpg", "mrw", "mrw", "msg", "myd", "nd", "ndd", "nef", "nk2", "nop", "nrw", "ns2", "ns3", "ns4", "nsd", "nsf", "nsg", "nsh", "nwb", "nx2", "nx1", "nyf", "oab", "obj", "odb", "odc", "odf", "odg", "odm", "odp", "ods", "odt", "oil", "orf", "ost", "otg", "oth", "otp", "ots", "ott", "p12", "p7b", "p7c", "pab", "pages", "pas", "pat", "pcd", "pct", "pdb", "pdd", "pdf", "pef", "pem", "pfx", "php", "pl", "plc", "pot", "potm", "potx", "ppam", "pps", "ppsm", "ppsx", "ppt", "pptm", "pptx", "prf", "ps", "psafe3", "psd", "pspimage", "pst", "ptx", "py", "qba", "qbb", "qbm", "qbr", "qbw", "qbx", "qby", "r3d", "raf", "rar", "rat", "raw", "rdb", "rm", "rtf", "rw2", "rw1", "rwz", "s3db", "sas7bdat", "say", "sd0", "sda", "sdf", "sldm", "sldx", "sql", "sqlite", "sqlite3", "sqlitedb", "sr2", "srf", "srt", "srw", "st4", "st5", "st6", "st7", "st8", "stc", "std", "sti", "stw", "stx", "svg", "swf", "sxc", "sxd", "sxg", "sxi", "sxm", "sxw", "tex", "tga", "thm", "tlg", "txt", "vob", "wallet", "wav", "wb2", "wmv", "wpd", "wps", "x11", "x3f", "xis", "xla", "xlam", "xlk", "xlm", "xlr", "xls", "xlsb", "xlsm", "xlsx", "xlt", "xltm", "xltx", "xlw", "ycbcra", "yuv", "zip"],

Lista negra de aplicaciones

"blacklist_apps": ["org.antivirus", "com.antivirus", "com.avast.android.mobilesecurity", "com.cleanmaster.security", "com.avira.android", "com.trustgo.mobile.security", "com.kms.free", "com.kaspersky.kes", "com.kaspersky.lightscanner", "com.cleanmaster.mguard", "com.lookout.enterprise", "com.wsandroid.suite", "com.eset.ems2.gp", "com.symantec.enterprise.mobile.security", "com.qihoo.security",
"org.malwarebytes.antimalware", "com.trendmicro.tmmssuite.mdm", "com.trendmicro.virdroid", "com.bitdefender.antivirus", "com.zimperium.zips", "com.psafe.msuite", "com.sophos.smsec", "com.drweb", "com.drweb.mcc", "com.bullguard.mobile.mobilesecurity", "com.bullguard.mobilebackup", "net.nshc.droidx3", "net.nshc.droidx3web", "com.sophos.appprotectionmonitor", "com.sophos.smsec", "com.sophos.mobilecontrol.client.android", "com.sophos.smenc", "com.comodo.cisme.antivirus", "com.quickheal.platform", "com.mobandme.security.virusguard", "de.gdata.mobilesecurity", "de.gdata.securechat", "com.webroot.security.sme", "com.webroot.secureweb", "com.ahnlab.v3mobileplus", "com.antiy.avlpro", "com.antiy.avl"],


Servidor de contacto

"api_url": "https://vps.equus-tech.com:44001",

Algunas muestras de Lipizzan

Primeras versiones de Lipizzan
Versiones actualizadas de Lipizzan
Las aplicaciones ya se encuentran fuera de Google Play y los pocos usuarios infectados (unos 100) ya han sido debidamente notificados.

Como siempre y como recomendación: sentido común y desconfiar de aplicaciones poco conocidas.

Más información:

Información oficial de los desarrolladores de Google

Repositorio con muestras de Lipizzan

martes, 9 de agosto de 2016

Las vulnerabilidades QuadRooter afectan a más de 900 millones de dispositivos Android

Investigadores de Check Point han presentado un conjunto de cuatro nuevas vulnerabilidades que afectan a prácticamente todos los dispositivos del ecosistema Android. Hasta 900 millones de teléfonos y tabletas podrían verse afectados por estas nuevas vulnerabilidades, ya bautizadas como QuadRooter.

La culpa no siempre va a ser de Google
QuadRooter (¡falta una web dedicada y logo!) es un conjunto de cuatro vulnerabilidades que afectan a dispositivos Android con el conjunto de chips de Qualcomm. Esta firma es el líder mundial de fabricantes de chipsets LTE, con un 65% del mercado. Basta con que un atacante explote alguna de las cuatro vulnerabilidades para que pueda elevar privilegios en el dispositivo y conseguir acceso root en el sistema.

Adam Donenfeld, investigador Senior de seguridad de Check Point, presentó las nuevas vulnerabilidades durante una conferencia en la última Def Con, que acaba de celebrarse. Su investigación, partía de la premisa de que Google no es el único en el que recae la carga de la lucha para proteger a Android. Qualcomm, como proveedor de la mayoría de los chipsets del ecosistema Android, tiene tanta responsabilidad como Google.

Según la firma, los últimos y más populares dispositivos Android del mercado actual usan los chipset de Qualcomm, como:
  • BlackBerry Priv
  • Blackphone 1 y 2
  • Google Nexus 5X, Nexus 6 y Nexus 6P
  • HTC One, HTC M9 y HTC 10
  • LG G4, LG G5 y LG V10
  • Moto X de Motorola
  • OnePlus One, OnePlus 2 y OnePlus 3
  • Samsung Galaxy S7 y Samsung S7 Edge
  • Sony Xperia Z Ultra
Un atacante podría aprovechar estas vulnerabilidades a través de una aplicación maliciosa, que sin necesidad de ningún permiso especial podría explotar los problemas sin levantar sospechas en el usuario.

Las vulnerabilidades residen en los controladores de Qualcomm incluidos con sus chipsets. Estos drivers que se encargan de regular la comunicación entre los componentes del chipset son incluidos en las diferentes versiones de Android que los fabricantes desarrollan para sus dispositivos.

Como los controladores vulnerables están incluidos en los dispositivos desde el fabricante, las vulnerabilidades solo podrán corregirse mediante la instalación de un parche proporcionado por el mismo distribuidor o el fabricante. Que a su vez, solo podrán ofrecer las actualizaciones tras recibir los controladores corregidos por parte de Qualcomm.

Según ha confirmado Qualcomm recibió la notificación de los problemas en abril de 2016, en el mes de julio ya había distribuido los controladores actualizados a los fabricantes, que deberán ser ahora los encargados de distribuir las actualizaciones pertinentes a sus usuarios y distribuidores. Una vez más, los sistemas sin soporte se quedan desprotegidos.

El problema de la cadena de fabricantes, distribuidores
y operadoras, hasta llegar al usuario final
Esta situación pone de relieve los riesgos inherentes en el modelo de seguridad de Android. Actualizaciones de seguridad críticas deben pasar a través de toda la cadena de proveedores antes de que estar disponible al usuario final. Una vez disponibles, son los propios usuarios finales quienes deben instalar estas actualizaciones para proteger sus datos y dispositivos.

Cada una de las cuatro vulnerabilidades afecta a un módulo diferente, con impacto en todo el sistema Android del dispositivo:
  • IPC Router (comunicación entre procesos)
    El módulo ipc_router proporciona comunicación entre procesos para varios componentes Qualcomm, procesos en modo usuario y controladores de hardware.
  • Ashmem (Android Shared Memory)
    Es un driver que facilita el uso compartido de memoria entre procesos. Es el subsistema de asignación de memoria propietaria de Android que permite a los procesos compartir búfers de memoria de forma eficiente. Los dispositivos Android con chipsets Qualcomm usan un sistema ashmem modificado,
  • kgsl (kernel graphics support layer) y kgsl_sync (kernel graphics support layer sync)
    El componente GPU de Qualcomm kgsl es un controlador del núcleo que genera los gráficos mediante la comunicación con binarios en modo usuario. Aunque este controlador incluye muchos módulos, kgsl_sync es el responsable de la sincronización entre la CPU y las aplicaciones

De esta forma la primera de las cuatro vulnerabilidades, con CVE-2016-2059, afecta a IPC router y puede permitir convertir cualquier puerto en  un puerto de control. Con CVE-2016-5340, una vulnerabilidad en ashmem que podría permitir a un atacante montar su propio sistema de archivos, creando un archivo en el directorio raíz llamado "ashmem". El atacante podrá engañar al sistema para que crea que el archivo creado es realmente un archivo "ashmem", cuando en realidad puede ser cualquier archivo.

Por último, dos vulnerabilidades (con CVE-2016-2503 y CVE-2106-2504) por condiciones de carrera que pueden provocar un uso de memoria después de liberarla en KGSL.

Check Point ha publicado una aplicación que permite escanear cualquier dispositivo Android para determinar si está afectado o no por las vulnerabilidades. Disponible desde:

Por el momento y a la espera de parches para evitar estos problemas, que seguramente tardarán mucho en llegar a los usuarios, hay que recordar las recomendaciones habituales. Como instalar las actualizaciones de Android lo antes posible, comprobar cada aplicación que descarguemos (y los permisos que solicita) para comprobar que es legítima, descargar únicamente aplicaciones desde Google Play, usar redes WiFi confiables y usar soluciones de seguridad como Koodous.

Más información:

QuadRooter
New vulnerabilities affecting over 900 million Android devices

QuadRooter: New Android Vulnerabilities in Over 900 Million Devices

Stumping the Mobile Chipset

Stumping the mobile chipset


Antonio Ropero
Twitter: @aropero

martes, 28 de octubre de 2014

"Find my Mobile" de Samsung permite a un atacante bloquear el móvil

Se ha anunciado una vulnerabilidad en la función "Find my mobile" de Samsung que podría permitir a un atacante remoto activar sus funcionalidades, de forma que podría hacer que suene o bloquearlo (con un código arbitrario).
 
La función "Find my Mobile" implementada por Samsung en sus dispositivos es un servicio web que proporciona a los usuarios de dispositivos Samsung características para localizar un dispositivo perdido o robado. Esta utilidad incluida también por otros fabricantes (como Apple o Microsoft), permite hacer sonar el dispositivo remoto, borrar su contenido o bloquearlo de forma remota para que nadie más puede conseguir acceso al dispositivo perdido.

El problema, descubierto por Mohamed A. Baset (@SymbianSyMoh), reside en una vulnerabilidad de Básicamente, el atacante utilizará el ataque CSRF para engañar al usuario para acceder a un enlace o url que contiene peticiones maliciosas o no autorizadas. El atacante podrá llegar a bloquear el móvil del usuario con un código de su elección, lo que forzaría al usuario a realizar una recuperación del código de bloqueo a través de su cuenta Google.

El enlace malicioso tiene los mismos privilegios que el usuario autorizado para llevar a cabo una tarea no deseada en el nombre de la víctima. Las vulnerabilidades de Cross-site Request Forgery (CSRF) permiten a un atacante ejecutar funcionalidades de una web determinada a través de la sesión  activa en esa web de otro usuario.

El investigador ha proporcionado pruebas de concepto en forma de vídeos que detallan como llevar a cabo el ataque y los efectos que puede tener. Se ha asociado el CVE-2014-8346 a esta vulnerabilidad. 




Más incormación:

Vulnerability Summary for CVE-2014-8346

Samsung FindMyMobile Service Vulnerabilities Demonstration

Samsung FindMyMobile Service Vulnerabilities Demonstration Live


Antonio Ropero
Twitter: @aropero

miércoles, 14 de mayo de 2014

Virus de la Policía en Android: Técnicas usadas para bloquear el movil y como eliminarlo

Conocemos el Virus de la Policía que afecta a los ordenadores bloqueando la pantalla y pidiendo dinero para desbloquear el sistema, el comportamiento típico de cualquier "ransomware". Recientemente se ha descubierto una versión para Android. Vamos a mostrar las técnicas usadas por el atacante para forzar que el malware permanezca en primer plano y persista al reinicio del dispositivo. Por último, ofreceremos una forma para eliminarlo del dispositivo.

Si ejecutamos el Virus de la Policía en el emulador de Android, vemos una página web en la que nos pide dinero para desinstalar la aplicación. Al igual que ocurre con la versión de escritorio, sin pagar, es imposible de salir de la aplicación porque siempre vuelve al primer plano y no nos deja suficiente tiempo para desinstalarla a partir del menú "Ajustes" de Android.


Hemos usado "jd-gui" para decompilar la aplicación. Sin embargo, con la ofuscación y las técnicas de anti-decompilación, el decompilador no puede decompilar todas las partes del programa por lo que tenemos que usar Eclipse para depurar la aplicación. Es importante observar que las partes de código mostradas en esta entrada han sido convenientemente tratadas.

Para empezar, analizamos el archivo de configuración de la aplicación "AndroidManifest.xml", que contiene actividades, servicios, permisos usados, identificador de la aplicación (package name), etc. Vemos que el malware tiene el nombre de paquete "com.android". Con el filtro "MAIN", podemos comprobar que la actividad "MainActivity" es la primera que se ejecuta cuando el usuario ejecuta la aplicación. Después, se definen dos receptores "ScheduleLockReceiver" y "ScheduleUnlockReceiver" para ejecutarse en procesos diferentes por la etiqueta ":remote" (se explicarán más detalladamente). Por último el "BootstrapReceiver" es un clase que va a registrarse al evento "BOOT_COMPLETED" del móvil y que se llama durante la inicialización del móvil con la prioridad mas alta "999". De esta forma permite la persistencia al reinicio del móvil. Al tener la prioridad más alta, será una de las primeras clases llamadas durante la inicialización del móvil.


Mirando el código decompilado de la clase "MainActivity", vemos que lanza la actividad "LockActivity" llamando a la función "startActivity". En la actividad lanzada hemos encontrado la función "dispatchKeyEvent" que permite al atacante monitorizar y anular los botones del dispositivo (como HOME, BACK, y MENU) y así evitar que el usuario salga de la aplicación fácilmente.















Esa misma clase va a lanzar en segundo plano el servicio "LockService", que va a programar dos tareas "ScheduleLockReceiver" y "ScheduleUnlockReceiver" a través del "AlarmManager". La primera tarea se ejecuta cada 2 segundos mientras que la segunda tarea se lanza cada 600 segundos. Como la segunda tarea no está implicada directamente en el bloqueo de la pantalla, nos concentramos en la primera tarea.



Cada vez que la tarea se ejecuta, se ejecuta la función "onReceive" y lanza el servicio "LockService" pasando el parámetro "start.event.type" a 2.










Llamando al servicio, se llama a la función "dispatchEvent". Con el tipo de evento 2, fuerza la actividad a lanzarse de nuevo. Y así no permite a otra aplicación pasar al primer plano.





Desinstalar el Virus de la Policía en Android

Como no tenemos acceso a la pantalla, no podemos desinstalar manualmente la aplicación desde el menú "Ajustes/Aplicaciones". Sin embargo, Google proporciona una herramienta llamada "adb" usada por desarrolladores de aplicaciones Android para instalar y desinstalar aplicaciones, grabar logs, etc. Antes de desinstalar una aplicación, necesitamos conocer el nombre del paquete que la identifica. Esta información se encuentra en el archivo de configuración "AndroidManifest.xml". Podemos ver que en este caso el nombre de paquete del ransomware es "com.android".

La utilidad "adb" se encuentra incluida dentro del Android SDK disponible para descarga desde:

Una vez instalado (descomprimirlo) será necesario conectar el dispositivo infectado al ordenador, localizar la herramienta "adb" en la carpeta "/sdk/platform-tools/" y ejecutar el comando:
adb uninstall com.android
con lo que conseguiremos desinstalar el malware.

Más información:

El virus de la policía "evoluciona" e impide el acceso en modo seguro

Nuevas variantes del “virus de la policía”. Ahora para Android

Police Locker land on Android Devices

Java decompiler

Depurar malware Android con Eclipse

Android Debug Bridge

Hash del ransomware:
2e1ca3a9f46748e0e4aebdea1afe84f1015e3e7ce667a91e4cfabd0db8557cbf

una-al-dia (21/06/2011) Vídeo: Troyano secuestra el ordenador en nombre de la policía nacional acusando al usuario de terrorista zoofílico

una-al-dia (28/02/2012) Vuelve el troyano que se hace pasar por la policía: Cómo protegerse (de verdad)

una-al-dia (02/03/2012) El virus de la policía "evoluciona" e impide el acceso en modo seguro

una-al-dia (06/03/2012) Más información sobre el virus de la policía

una-al-dia (09/03/2012) El malware de la policía aprovecha un exploit de Java "in-the-wild" y el secreto su "éxito"

una-al-dia (18/03/2012) WhitePaper: Estudio técnico del troyano de la policía

una-al-dia (24/05/2012) Nuevas versiones del malware de la policía y cómo eludirlas




Laurent Delosières