Las vulnerabilidades más peligrosas en Android
23 mins read

Las vulnerabilidades más peligrosas en Android

Contenido

  • 1 Las vulnerabilidades más críticas y peligrosas en Android
    • 1.1 BlueBorne
    • 1.2 Campo extra
    • 1.3 Identificación falsa
    • 1.4 Janus
    • 1.5 Serialización de ObjectInputStream
    • 1.6 OpenSSLX509Certificate
    • 1.7 Pendiente
    • 1.8 StageFright
    • 1.9 StageFright 2.0
    • 1.10 Kit de herramientas SIM
    • 1.11 Pan tostado
    • 1.12 Capa y daga
  • 2 conclusiones

Como saben, los sistemas operativos son desarrollados por personas. Sin embargo, alguien que ve REN TV está seguro de que Android creó reptilianos, pero esto no es así: hoy en la plataforma móvil de Google se han descubierto muchos errores que solo los representantes de la forma homo sapiens podrían cometer.

Algunos de estos errores son vulnerabilidades completas y se pueden usar tanto para el acceso no autorizado al sistema de archivos del teléfono inteligente como para la distribución de malware.

Según las estadísticas oficiales de Google, hoy Turrón es el más común entre las versiones de Android: la revisión de la plataforma móvil número 7.0 y 7.1 está instalada en el 28.2% de los dispositivos en total. La segunda posición es tomada con confianza por Android 8.0 y 8.1 Oreo con un indicador de 21.5%. En tercer lugar, se reparó la sexta versión de Marshmallow: funciona en el 21.3% de los dispositivos. Android 5.0 y 5.1 Lollipop se instalan en un total de 17.9% de dispositivos, y cierra el grupo de líderes Android 4.4 KitKat con un indicador de 7.6% de usuarios.

Según la información de cvedetails.com, existen 2.146 vulnerabilidades en Android hoy, y la cantidad de errores detectados ha comenzado a crecer exponencialmente desde aproximadamente 2014.

Las vulnerabilidades más críticas en Android

No es tan fácil estimar cuántos de los dispositivos enumerados recibieron parches de seguridad a tiempo que cubren vulnerabilidades, pero claramente no todos. No solo eso: no todas las vulnerabilidades están generalmente cerradas, especialmente en versiones anteriores, cuyo soporte oficial ha sido descontinuado. El problema se ve exacerbado por los fabricantes de dispositivos, que a menudo no tienen prisa por lanzar actualizaciones.

Las vulnerabilidades de Android más críticas y peligrosas

La primera vulnerabilidad de Android se descubrió en octubre de 2008 en el firmware del comunicador HTC T-Mobile G1. Al visualizar páginas web con contenido específico, un error en el software permitió la ejecución de código malicioso que monitorea el uso del teclado del dispositivo. Teóricamente, de esta manera fue posible implementar un keylogger que registra las pulsaciones de los botones y recopila la entrada del usuario cuando navega por la web. Esta vulnerabilidad era un peligro solo para un modelo de comunicador único, pero su presencia demostró claramente: Android no es tan seguro como se pensaba anteriormente.

Con la popularidad del sistema operativo, los entusiastas e investigadores buscaron más y más errores en sus diversas versiones. Por supuesto, dentro del marco de un artículo, no podremos cubrir las dos mil vulnerabilidades descubiertas durante toda la existencia de Android. Por lo tanto, nos centraremos solo en los más interesantes y peligrosos de ellos, y solo en las versiones actualmente relevantes de Android (las que todavía se pueden encontrar en la vida).

La cuarta generación de Android, comenzando con la versión 4.4 de KitKat, resultó ser la más “permeable”. Con él, quizás, comenzaremos nuestra revisión de las vulnerabilidades identificadas en diferentes momentos en esta plataforma.

Blueborne

CVE: CVE-2017-1000251 , CVE-2017-1000250 , CVE-2017-0781 , CVE-2017-0782 , CVE-2017-0785 y CVE-2017-0783
Versiones vulnerables de Android: 4.4.4, 5.0.2, 5.1 .1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0
Para la operación se requiere: el atacante debe estar a una distancia de no más de diez metros del dispositivo vulnerable, y Bluetooth debe estar habilitado en el dispositivo vulnerable
Resultado posible: arbitrario código con privilegios del núcleo del sistema, pérdida de datos

Esta no es una vulnerabilidad separada, sino un conjunto completo de errores en la pila de Bluetooth de los sistemas operativos modernos, incluido Android. Hay errores graves en el código de la función del sistema l2cap_parse_conf_rsp del kernel de Linux, y se pueden encontrar en todas las versiones del kernel, comenzando con 3.3. Si la protección de desbordamiento de pila CONFIG_CC_STACKPROTECTOR está habilitada en el sistema, su uso conduce a un error crítico en la operación del núcleo.

La vulnerabilidad CVE-2017-1000251 se identificó en un módulo del núcleo llamado L2CAP, que es responsable del funcionamiento de la pila del protocolo Bluetooth. Otra vulnerabilidad en la pila de este protocolo fue designada CVE-2017-0783 . Si el subsistema Bluetooth está habilitado en el dispositivo bajo ataque, se pueden usar para transmitir de manera remota paquetes de información de una manera especial. Dichos paquetes pueden contener código malicioso que se ejecuta en Android con privilegios de kernel del sistema. En este caso, para implementar el ataque, no necesita emparejar previamente los dispositivos o activar el modo de detección en ellos. Es suficiente que el atacante esté a una distancia de no más de diez metros del dispositivo vulnerable.

Dado que los componentes del sistema operativo que interactúan con el protocolo Bluetooth por defecto tienen altos privilegios del sistema, la explotación de estas vulnerabilidades teóricamente le permite obtener un control total sobre el teléfono inteligente y la tableta atacados, incluido el acceso a los datos almacenados en el dispositivo, las redes conectadas y el sistema de archivos. Además, con la ayuda de BlueBorne, es técnicamente posible implementar ataques como man-in-the-middle.

BlueBorne también incluye la vulnerabilidad CVE-2017-1000250 en la pila BlueZ de implementaciones de Linux del Service Discovery Protocol (SDP). La explotación de la vulnerabilidad CVE-2017-1000250 podría conducir a la fuga de datos. Las vulnerabilidades CVE-2017-0781 , CVE-2017-0782 y CVE-2017-0785 se relacionan con el sistema operativo Android en sí, mientras que el uso de las dos primeras aplicaciones maliciosas puede obtener privilegios de kernel en el sistema, y ​​la última permite la fuga de datos.

Para corregir las vulnerabilidades de BlueBorne, Google lanzó una actualización de seguridad el 9 de septiembre de 2017. Además, no temen a los dispositivos que usan el modo Bluetooth de baja energía.

Campo extra

CVE: ninguno
Versiones vulnerables de Android: 2.3, 4.0, 4.1, 4.2, 4.3, 4.4
Para la operación se requiere: una aplicación modificada
Resultado posible: ejecución de código arbitrario

Todas las aplicaciones de Android se distribuyen en formato .APK y son un archivo ZIP con la diferencia de que tienen una firma digital especial. En el interior se encuentran los componentes necesarios para el trabajo, que se extraen durante la instalación de la aplicación, y sus sumas de verificación se verifican con los valores de referencia. Una vulnerabilidad de campo adicional podría permitir a un atacante modificar el contenido de un paquete de instalación de APK sin dañar su firma digital.

Dentro del archivo .APK, se encuentra el archivo classes.dex, que contiene el código compilado de la aplicación y un conjunto de campos de servicio. Entre ellos están:

  • un campo que almacena el nombre del archivo con la extensión;
  • tamaño de archivo
  • Campo de campo adicional, en el que se graba el código ejecutable;
  • una tabla con una lista de las clases utilizadas por él.

Si escribe el valor inicial en el campo de encabezado sin los primeros tres bytes, la longitud del campo Extra Field también cambia, lo que permite agregar código arbitrario allí, por ejemplo, para enumerar las clases utilizadas por la parte troyana de la aplicación. Después de eso, puede agregar al archivo, además de las clases originales.dex, su copia maliciosa, parte del código del cual se almacenará en el campo de campo adicional “extendido” de las clases originales. Al instalar el programa, el sistema leerá el contenido de los campos modificados y, dado que enumeran las clases de las clases modificadas.dex, este archivo se instalará en el dispositivo.

Por lo tanto, la vulnerabilidad permite que el troyano se “enganche” en cualquier aplicación legítima con una firma digital válida , a menos que el tamaño del módulo malicioso esté limitado por el tamaño máximo del archivo classes.dex de 65.533 bytes. La vulnerabilidad se descubrió a principios de julio de 2013 y se corrigió en versiones de Android lanzadas después de esta fecha.

Identificación falsa

CVE: ninguno
Versiones vulnerables de Android: 2.2, 2.3, 4.0, 4.1, 4.2, 4.3, 4.4
Para su funcionamiento se requiere: una aplicación firmada de manera especial con una firma digital
Resultado posible: instalación y lanzamiento de una aplicación maliciosa, pérdida de datos

Esta vulnerabilidad se descubrió en Android 2.2 y fue relevante hasta la versión 4.4. El error correspondiente a esta vulnerabilidad recibió el número interno 13678484 y fue corregido principalmente por parches que fueron lanzados por los propios fabricantes del dispositivo.

Como ya se mencionó, todos los archivos .APK en Android usan una firma digital. La firma de la aplicación puede estar interconectada con la firma digital del editor del programa. Todas estas firmas utilizan la infraestructura de clave pública PKI (Infraestructura de clave pública). Mediante una firma digital, el sistema operativo determina qué características y privilegios puede tener una aplicación, con qué componentes del sistema operativo puede interactuar, qué funciones del sistema usar, si tiene derecho a descargar e instalar actualizaciones, etc.

Los certificados digitales utilizados durante la verificación de la firma de la solicitud (documentos electrónicos en los que se almacena la clave digital) son emitidos por centros especiales de certificación. Si el sistema confía en la autoridad de certificación, automáticamente confía en todos los certificados emitidos por él que utiliza la aplicación.

Al verificar (validar) una firma digital de una aplicación, el sistema operativo utiliza la clave pública del desarrollador del programa. Para verificar la validez de esta clave, debe verificar el certificado correspondiente de la autoridad de certificación. Esto se llama validación de la cadena de certificados. La vulnerabilidad es que en el proceso de instalación de la aplicación, las primeras versiones de Android no realizaron tal verificación en absoluto.

Como implementación práctica de la vulnerabilidad, se puede citar este ejemplo. Si la aplicación está firmada con dos certificados digitales: genuino y falso, durante su instalación se creará una firma digital utilizando ambos certificados. Como resultado, la aplicación puede, por ejemplo, descargar e instalar actualizaciones maliciosas que no se comprobarán por seguridad si el desarrollador las firma utilizando el mismo certificado no válido.

Janus

CVE: CVE-2017-13156
Versiones vulnerables de Android: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2 La
operación requiere: una aplicación modificada
Resultado posible: instalación y lanzamiento de una aplicación maliciosa, pérdida de datos

Otro número de vulnerabilidad CVE-2017-13156 , que opera con firmas digitales de aplicaciones de Android, solo es relevante para las versiones más recientes del sistema operativo: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1 y 7.1.2. Con Janus, puede incrustar un archivo dex ejecutable en el archivo .APK, al tiempo que conserva la firma digital original de la aplicación. El agujero radica en el sistema de verificación de firma digital basado en JAR, que fue reemplazado por la tecnología Signature Scheme v2 en Android 7.0. Sin embargo, incluso en la séptima y octava generación de Android, la vulnerabilidad puede ser utilizada por aplicaciones antiguas que no utilizan el nuevo método de verificación, así como por algunos programas descargados no del catálogo oficial de Google Play.

ObjectInputStream Serialization

CVE: CVE-2014-7911
Versiones vulnerables de Android: 1.0–4.4.4 La
operación requiere: una aplicación especial o módulo de aplicación
Resultado posible: finalización anormal de procesos críticos del sistema

Esta vulnerabilidad, que afecta a todas las versiones de Android anteriores a la 5.0, ha sido designada CVE-2014-7911 . El error radica en el mecanismo para verificar la serialización de los objetos recibidos por el componente del sistema luni / src / main / java / java / io / ObjectInputStream.

La serialización es la capacidad de algunos objetos para transformarse en una secuencia de bytes a partir de los cuales pueden restaurarse a su forma original (el procedimiento inverso se llama deserialización). El procedimiento de serialización generalmente se usa para guardar datos o transferirlos a otro proceso o transmitirlos a través de la red.

Usando la vulnerabilidad, es posible deserializar cualquier objeto con un constructor abierto sin parámetros, incluso si no cumple con los criterios para la serialización. Si este objeto usa el método de finalización, si se elimina, el recolector de basura llamará a este método, como resultado de lo cual se ejecuta el código almacenado en el objeto. De esta manera, puede atacar los procesos del sistema Android, haciendo que se bloqueen, incluida la eliminación de los procesos críticos del sistema .

Certificado OpenSSLX509

CVE: CVE-2015-3837
Versiones vulnerables de Android: 4.3–5.1 La
operación requiere: una aplicación especial o módulo de aplicación
Resultado posible: ejecución de código arbitrario con privilegios del sistema

Vulnerabilidades OpenSSLX509Certificate, también conocido como CVE-2015-3837 , se ve afectado por las versiones de Android 4.3 a 5.1 inclusive. Con este error, puede aumentar los privilegios de un proceso malicioso.

Un error en el componente del sistema OpenSSLX509Certificate le permite comprometer el proceso del sistema system_server y ejecutar cualquier código con privilegios del sistema (UID 1000). Por lo tanto, es posible, por ejemplo, reemplazar cualquier aplicación instalada previamente (excepto los componentes del sistema operativo), guardando otro programa en su lugar.

Pendiente

CVE: CVE-2014-8609
Versiones vulnerables de Android: 4.0-4.4.4 La
operación requiere: una aplicación especial o módulo de aplicación
Resultado posible: ejecución de cualquier comando en el sistema

Esta vulnerabilidad con el número CVE-2014-8609 se identificó en Android 4.0-4.4.4. El error está contenido en el método addAccount del archivo AddAccountSettings.java (ubicado en src / com / android / settings / accounts /), que forma parte del subsistema de administración de cuentas de la aplicación.

Algunas aplicaciones de Android pueden usar credenciales de usuario para la autorización automática en varios servicios de Internet. En este caso, el usuario solo necesita especificar su nombre de usuario y contraseña una vez, después de lo cual se registran en una sección especial de la configuración del sistema “Cuentas”, a la que accede la aplicación cada vez que necesita autenticarse.

Al crear dicha cuenta, el sistema operativo pasa varios parámetros a la aplicación, entre los cuales se encuentra el parámetro PendingIntent. Debido a un error en la implementación del método addAccount que se llama al registrar una cuenta, el sistema no verifica los valores de este campo, por lo tanto, un atacante puede transferir a PendingIntent prácticamente cualquier comando que se ejecutará con los mismos privilegios que la aplicación de configuración que lo envió: sistema.

Puede crear un comando para eliminar archivos almacenados en el dispositivo o una secuencia de bytes, que el sistema percibirá como un mensaje SMS entrante. Por ejemplo, si se pasa el comando android.intent.action.MASTER_CLEAR en el parámetro PendingIntent, Android realizará un reinicio completo del sistema con la destrucción de toda la información almacenada en el dispositivo.

StageFright

CVE: CVE-2015-1538
Versiones vulnerables de Android: 2.2–5.1.1
Para su explotación se requiere: transferir al dispositivo un archivo MP4 especialmente compuesto
Resultado posible: ejecución de código arbitrario con privilegios del sistema

Esta vulnerabilidad es relevante para todas las versiones de Android desde 2.2 a 5.1.1. El error se detectó en la biblioteca del sistema Stagefright, que proporciona la reproducción de archivos multimedia en formato MP4.

Si es posible entregar un archivo MP4 especialmente diseñado a un dispositivo vulnerable (por ejemplo, en un mensaje MMS), entonces, debido a un error en el controlador SampleTable.cpp, el código arbitrario integrado en este archivo se ejecutará con privilegios del sistema, incluso si el usuario simplemente abre la carpeta, en el que se almacena dicho archivo.

StageFright 2.0

CVE: CVE-2015-6602
Versiones vulnerables de Android: 4.1–5.1.1
Para su explotación se requiere: transferir al dispositivo un archivo MP3 o MP4 especialmente compuesto
Resultado posible: ejecución de código arbitrario con privilegios del sistema

A pesar de la similitud del nombre, esta vulnerabilidad está oculta en otro componente: en la aplicación del servidor de medios, más precisamente en el controlador de etiquetas ID3v2. Versiones vulnerables de Android de 4.1 a 5.1.1.

Para aprovechar la vulnerabilidad, es suficiente entregar un archivo MP3 o MP4 especialmente modificado al dispositivo atacado de cualquier manera. Al leer las etiquetas ID3v2 contenidas en dicho archivo, se produce un desbordamiento del búfer, lo que resulta en la ejecución de código arbitrario integrado en el archivo con privilegios del sistema.

Kit de herramientas SIM

CVE: CVE-2015-3843
Versiones vulnerables de Android: 5.1
Para la operación se requiere: una aplicación especial o módulo de aplicación
Resultado posible: intercepción y sustitución de comandos enviados por la tarjeta SIM al sistema operativo

Android tiene un marco integrado de SIM Application Toolkit (STK) que permite que una tarjeta SIM ejecute un conjunto específico de comandos en el sistema. Así, en particular, se forma el menú SIM del operador.

La vulnerabilidad le permite interceptar los comandos enviados por la tarjeta SIM al sistema operativo, así como reemplazarlos. Una aplicación malintencionada podría pasar un paquete creado especialmente a la clase com.android.stk.StkCmdReceiver. El destinatario no verifica la autenticidad del remitente, mientras que la acción android.intent.action.stk.command no se declara en el manifiesto como protegida, por lo que puede emular el envío de comandos por la tarjeta SIM.

Por ejemplo, si la tarjeta SIM forma un mensaje en la pantalla del dispositivo que confirma las acciones del usuario, contendrá el botón Aceptar. Dichos mensajes se utilizan para confirmar el envío de solicitudes, transacciones, acciones con contactos almacenados en la tarjeta USSD, etc.

Una aplicación maliciosa puede desencadenar la acción android.intent.action.stk.command y mostrar una ventana falsa que contiene texto arbitrario en la parte superior de la pantalla. Cuando se presiona el botón OK, se llama al método sendResponse () con el indicador verdadero, y este evento, se presiona el botón, se envía a la tarjeta SIM que está esperando la respuesta del usuario. En este caso, el evento se procesará como si viniera de un cuadro de diálogo real.

Toastoverlay

CVE: CVE-2017-0752
Versiones vulnerables de Android: 4.0–7.1.2 La
operación requiere: una aplicación con el permiso BIND_ACCESSIBILITY_SERVICE
Resultado posible: obtener el control total sobre una ventana de tipo TYPE_TOAST

Esta vulnerabilidad se descubrió en 2017 y afecta a todas las versiones de Android desde 4.0 a 7.1.2 inclusive. Los desarrolladores cometieron un error en el subsistema de superposiciones: ventanas que se pueden mostrar encima de otros formularios de pantalla.

Una aplicación que utiliza la vulnerabilidad debe declarar solo un permiso en el manifiesto: BIND_ACCESSIBILITY_SERVICE. En condiciones normales, una aplicación debe enviar una solicitud SYSTEM_ALERT_WINDOW para mostrar ventanas del tipo TYPE_TOAST destinadas a mostrar notificaciones del sistema, sin embargo, debido a un error en el controlador de verificación de permisos AOSP de Android, un programa malicioso puede prescindir de tales formalidades. El componente simplemente no realiza la verificación de permisos y la verificación de operación cuando procesa la solicitud SYSTEM_ALERT_WINDOW para TYPE_TOAST.

Como resultado, una aplicación que utiliza la vulnerabilidad puede dibujar sus ventanas sobre otros programas con impunidad y registrar clics en la pantalla. De hecho, toma el control total de la ventana TYPE_TOAST. El contenido que se mostrará en esta ventana depende solo de la imaginación de los creadores de virus.

Capa y daga

CVE: CVE-2017-0752
Versiones vulnerables de Android: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2
Para la operación se requiere: una aplicación con permisos SYSTEM_ALERT_WINDOW y BIND_ACCESSIBILITY_SERVICE
Posible resultado : grabar pulsaciones de teclas (keylogging), fuga de datos

Esta vulnerabilidad es relevante para Android hasta 7.1.2. Debido a un error en el SDK, una aplicación maliciosa que utiliza los permisos SYSTEM_ALERT_WINDOW y BIND_ACCESSIBILITY_SERVICE puede obtener un control casi completo sobre el sistema operativo y el acceso a la información confidencial del usuario, así como grabar pulsaciones de teclas.

En resumen, la esencia se reduce al hecho de que el permiso SYSTEM_ALERT_WINDOW le permite mostrar la “ventana del sistema”, un elemento Ver que aparece encima de cualquier otro elemento de la interfaz, incluso si es una Actividad de una aplicación de terceros. Al mismo tiempo, las actividades superpuestas no se enterarán de esto y continuarán funcionando como si nada hubiera pasado. Cualquier aplicación puede hacer esto si el permiso SYSTEM_ALERT_WINDOW se declara en su manifiesto.

Al colocar varias ventanas del sistema “invisibles” una encima de la otra y procesar clics sobre ellas, un atacante puede crear un keylogger. Y con la ayuda del permiso BIND_ACCESSIBILITY_SERVICE, un programa malicioso puede acceder a otros objetos y datos del sistema operativo almacenados en el dispositivo.

Conclusiones

Como puede ver, hubo muchas cosas interesantes en la historia de Android, y en este artículo solo tocamos la punta del iceberg: las vulnerabilidades más importantes, sensacionales y espectaculares. Es suficiente comenzar a cavar, y se abrirán otras oportunidades pequeñas y grandes para usted.

Leave a Reply

Your email address will not be published. Required fields are marked *