La historia reciente de la puerta trasera en la biblioteca NPM más popular ha llevado a muchos a pensar en cuánto confiamos en el código de terceros y cuán audazmente lo usamos en nuestros proyectos (lo que podría sustituir a los usuarios de nuestros productos).
Pero incluso meses antes del "trueno",
Felix Kraus (conocido por los desarrolladores móviles como el creador de Fastlane) habló en nuestra conferencia Mobius 2018 Piter sobre lo similar: la confianza de los desarrolladores móviles en SDK de terceros. Si descargamos el popular SDK de una empresa conocida, ¿está todo bien allí o también puede salir algo mal? ¿Dónde está el vector de ataque y qué debemos pensar al respecto?
Y ahora hemos transcrito y traducido su informe, por lo que debajo del corte puede al menos ver el video original, al menos leer la versión de texto en ruso. Dado que Kraus se dedica al desarrollo de iOS, todos los ejemplos también son de iOS, pero los desarrolladores de Android pueden ignorar ejemplos específicos y también pensar en ello.
Seguridad del SDK
Después de ver qué SDK son más populares en el desarrollo de iOS hoy, decidí investigar qué tan vulnerables son a los ataques de red más comunes. Hasta el 31% de ellos resultaron ser víctimas potenciales de ataques simples de hombre en el medio, lo que significa que el pirata informático inyecta su código malicioso en el SDK.
Pero en general, ¿vale la pena tener miedo? ¿Qué es lo peor que puede hacer con tu SDK? ¿Es todo esto tan serio? Debe comprender que el SDK incluido en el paquete de su aplicación se ejecuta en su alcance, es decir, el SDK obtiene acceso a todo lo que opera su aplicación. Si el usuario permite que la aplicación acceda a datos de geolocalización o, por ejemplo, fotos, estos datos también estarán disponibles para el SDK (no se requieren permisos adicionales). Otros datos a los que se puede acceder desde el SDK: datos cifrados de iCloud, tokens API y, además, todas las vistas UIKit que contienen mucha información diferente. Si un pirata informático intercepta un SDK que tiene acceso a este tipo de datos, las consecuencias, como usted sabe, pueden ser bastante graves. Al mismo tiempo, todos los usuarios de la aplicación se verán afectados al mismo tiempo.
¿Cómo puede suceder esto exactamente? Retrocedamos y hablemos sobre las cosas básicas de la red y su abuso.
Red
Te advierto que mis explicaciones no serán 100% precisas y detalladas. Mi objetivo es transmitir la esencia, por lo que presentaré todo en una forma algo simplificada. Si está interesado en los detalles, le recomiendo que mire mi blog o explore el tema usted mismo.
Como recordará, la principal diferencia entre el protocolo HTTPS y el protocolo HTTP es el cifrado de datos durante la transmisión. La falta de encriptación en HTTP, en general, significa que cualquier host ubicado dentro de la red, si lo desea, puede escuchar y modificar libremente cualquier paquete transmitido a través de ella; Al mismo tiempo, no es posible comprobar si se ha violado la integridad del paquete. Todo esto es cierto para las redes Wi-Fi públicas y las redes Ethernet locales y protegidas con contraseña.
Cuando se usa HTTPS, los hosts de la red también pueden escuchar los paquetes transmitidos, sin embargo, no tienen la capacidad de abrirlos; solo los metadatos del paquete son visibles, en particular, las direcciones de los hosts de envío y recepción. Además, HTTPS proporciona verificación: después de recibir el paquete, puede verificar si ha sufrido cambios durante el viaje.
Anteriormente, todo funcionaba de la siguiente manera. Cuando ingresó "google.com" en la barra de direcciones sin especificar un protocolo, por defecto el navegador envió su solicitud a través de HTTP. Pero dado que el servidor de Google prefiere comunicarse a través de HTTPS, en respuesta recibió un nuevo enlace (redireccionamiento) con el prefijo "https: //". Aquí hay una pantalla de Charles Proxy (una herramienta de monitoreo de tráfico HTTP / HTTPS) que demuestra esto:
Sin embargo, el nuevo enlace se envió a través del protocolo HTTP. Es fácil entender qué puede salir mal aquí: tanto la solicitud como la respuesta se transmiten a través de HTTP, lo que significa que puede, por ejemplo, interceptar el paquete de respuesta y reemplazar la URL de ubicación en él con "http: //". Este tipo simple de ataque se llama SSL Strip. Hasta la fecha, los navegadores ya han aprendido a trabajar de una manera ligeramente diferente. Pero comprender qué es una tira SSL es útil para nosotros aún más.
A veces puedes recordar el modelo de red OSI. La percibí como algo insoportablemente aburrido. Pero más tarde descubrió que, por extraño que parezca, el modelo OSI no existe así e incluso puede ser útil.
No lo consideraremos en detalle. Lo principal que hay que entender: todo consta de varias capas que son responsables de diferentes cosas y al mismo tiempo están en constante interacción entre sí.
Una de las capas está tratando de determinar qué dirección MAC corresponde a una dirección IP específica. Para hacer esto, se realiza una solicitud de transmisión especial, se graba el primer dispositivo respondido y posteriormente se le envían paquetes.
El problema es que el hacker puede responder a la solicitud más rápido: "sí, envíeme todos los paquetes". Esto se llama suplantación de ARP o envenenamiento de caché de ARP. En este caso, el esquema de su interacción con Internet se convierte en esto:
Todos los paquetes ahora pasan a través del dispositivo del hacker, y si el tráfico no está encriptado, podrá leer y escribir. En el caso de HTTPS, hay menos posibilidades, pero puede rastrear a qué hosts está accediendo.
Curiosamente, de hecho, los mismos poderes tienen proveedores de Internet y VPN. Son intermediarios en su interacción con Internet y, de la misma manera, representan una amenaza potencial de falsificación de ARP.
No hay nada nuevo en el enfoque del hombre en el medio en sí. Pero, ¿cómo se aplica exactamente todo esto a los SDK móviles?
Detalles móviles
CocoaPods es una herramienta de gestión de dependencias estándar utilizada en el desarrollo de iOS. El uso de CocoaPods para código fuente abierto se considera prácticamente seguro: generalmente está alojado en GitHub, generalmente se accede a través de HTTPS o SSH. Sin embargo, logré encontrar una vulnerabilidad basada en el uso de enlaces HTTP.
El hecho es que CocoaPods hace posible instalar el SDK con código fuente cerrado, y solo necesita especificar la URL. No hay verificación de que el tráfico se cifrará, y muchos SDK ofrecen una dirección HTTP.
En este sentido, envié varias solicitudes de extracción a los desarrolladores de CocoaPods, y pronto completaron la finalización. Ahora, las nuevas versiones de CocoaPods comprueban el enlace especificado por el usuario y, si no está cifrado, muestran una advertencia. Así que mi consejo es: siempre actualice las versiones de CocoaPods y no ignore las advertencias.
Es aún más interesante considerar cómo procede la instalación de SDK no sensoriales que no provienen de CocoaPods. Tomemos, por ejemplo, la plataforma Localytics.
La página docs.localytics.com no está encriptada. Parece que en este caso esto puede ser descuidado, porque esto es solo documentación. Pero tenga en cuenta que la página, entre otras cosas, contiene un enlace para descargar los archivos binarios. El enlace se puede cifrar, pero esto no garantiza ninguna seguridad: dado que la página en sí se transmitirá a través de HTTP, se puede interceptar y el enlace se puede reemplazar por uno sin cifrar. Los desarrolladores de localytics fueron notificados de esta vulnerabilidad y ya se ha solucionado.
Puede hacer lo contrario: no cambie el enlace a HTTP, pero deje HTTPS, pero reemplace la dirección en sí. Descubrir esto será muy difícil. Mira estos dos enlaces:
Uno de ellos me pertenece. ¿Cuál es de desarrolladores reales y cuál no? Intenta entenderlo.
Chequeo de práctica
Luego decidí probar mis suposiciones intentando en realidad reemplazar el contenido del SDK usando un ataque MITM. Resultó que esto no es tan difícil. Para construir y operar mi circuito, me tomó solo unas horas configurar las herramientas públicas más simples.
Confié la Raspberry Pi habitual para interceptar. Incluido en la red local, podía escuchar el tráfico en ella. En los paquetes interceptados, tuvo que, primero, reemplazar todos los enlaces HTTPS con enlaces HTTP, y luego reemplazar todos los archivos .zip de Localytics iOS con el archivo hack.zip. Todo esto resultó ser simple y funcionó con una explosión.
El archivo trollface.jpg apareció en el archivo resultante y la línea "Modificado por KrauseFx" apareció en el archivo Info.plist. ¿Cuánto se requería para tal ataque? Solo dos condiciones:
- Se las arreglaron para obtener acceso a su red (recuerde que para los proveedores de Internet y VPN esto no es una pregunta en absoluto). ¿A cuántas cadenas de café y hoteles nos conectamos?
- La descarga iniciada no está encriptada.
Usted dice: "pero solo estoy mirando el ícono Seguro en el navegador, lo que significa que estaré bien". Y si estás en Amazon, entonces todo debería estar bien, ¿verdad?
Sugiero considerar el sitio de Amazon. AWS Mobile SDK es su SDK personal, que proporcionan a los desarrolladores para interactuar con el servicio.
El icono "seguro", un sitio conocido, parece no presagiar nada. Pero, por desgracia, solo a primera vista. El enlace para descargar el SDK se indica sin un prefijo (ni https: // ni http: //). Y al mismo tiempo, debe llevar al usuario a otro host. Por lo tanto, el navegador cambiará de HTTPS a HTTP. Como puede ver, ¡aquí la descarga del SDK no está encriptada! Por el momento, la vulnerabilidad ya ha sido reparada por los desarrolladores de Amazon, pero realmente tenía un lugar para estar.
Debo decir que el desarrollo de los navegadores modernos también se lleva a cabo no sin prestar atención a los problemas de seguridad. Por ejemplo, si carga una página usando HTTPS, y cualquier imagen se especifica a través de un enlace HTTP, Google Chrome le notificará el llamado "contenido mixto". Pero esa medida de seguridad no se proporciona para las descargas: los navegadores no rastrean qué protocolo se activa para el enlace de descarga indicado en la página. Por lo tanto, como parte de este proyecto, escribí a los desarrolladores de navegadores con una solicitud para proporcionar un seguimiento del contenido mixto y notificar a los usuarios al respecto.
Robo de datos de ID de Apple
Ahora veamos otro problema. Los usuarios de iPhone deben estar familiarizados con esta ventana emergente regularmente:
A la izquierda, verá la versión original de iOS, a la derecha, mi copia. Sobre cómo es fácil simular una ventana similar,
escribí en mi blog hace unos meses. Le tomó 20 minutos recrear la vista.
El iPhone a menudo solicita datos de autenticación de iCloud y, para el usuario, el motivo de la solicitud generalmente no está claro. Los usuarios están tan acostumbrados que ingresan la contraseña automáticamente. La pregunta de quién solicita la contraseña (el sistema operativo o la aplicación) simplemente no viene a la mente.
Si cree que es difícil obtener la dirección de correo electrónico a la que se adjunta la ID de Apple, entonces exagera: esto se puede hacer tanto a través de la libreta de contactos como a través de los contenedores de iCloud (si tiene acceso a la aplicación iCloud, sobre la cual puede averiguar de UserDefaults de esta aplicación). Y la opción más simple es pedirle al usuario que ingrese personalmente su correo electrónico: en teoría, esto ni siquiera debería sorprenderlo, porque en iOS realmente hay una especie de ventana que solicita no solo una contraseña, sino también un correo electrónico.
Pensé: "¿Qué pasa si tomo este código del formulario de solicitud que tengo y, con la ayuda de la suplantación de identidad del SDK, penetrar en muchas aplicaciones diferentes para robar todas las contraseñas de iCloud con ellos? ¿Qué tan difícil es esta tarea?
Supongamos que tenemos una Mac completamente limpia, sin ninguna VPN o proxy instalado, pero en la misma red tenemos nuestra Raspberry Pi. En Mac en Xcode, tenemos un proyecto de proyecto de iOS abierto que contiene un mínimo absoluto de código: una simple visualización del mapa del área y nada más.
Ahora abra el navegador, vaya a Amazon Web Services. Busque la página de AWS Mobile SDK y siga el enlace de descarga. Desempaquete el binario descargado y arrastre todos los marcos a nuestro proyecto en Xcode. Luego importamos las bibliotecas. Ni siquiera estamos obligados a llamar a ningún código; es suficiente que se descargue. Observo que durante todo el proceso Xcode no dio ninguna advertencia.
¿Qué sucede al volver a compilar la aplicación? La misma copia de la ventana aparece en la pantalla, lo que me solicita que inicie sesión en iTunes Store. Ingreso la contraseña, la ventana desaparece. Al mismo tiempo que veo el registro de la aplicación, veo cómo se muestra la contraseña que ingresé al instante: se completa la intercepción de datos de ID de Apple. Sería fácil enviar estos datos en algún lugar al servidor.
Aquí puede decir: "Bueno, durante el desarrollo notaría inmediatamente este formulario de entrada y entendería que algo está mal". Pero si tiene una audiencia de millones de usuarios, puede hacer que se rastree solo una vez por mil y pasar desapercibido durante las pruebas.
Y de nuevo, ¿cuánto nos llevó llevar a cabo el ataque? Era necesario que nuestra computadora estuviera en la red (y la Raspberry Pi era suficiente). HTTP o HTTP: en este caso no importaba, el cifrado no salvaría la situación. Todas las herramientas de software que utilicé, las más simples, las tomé del acceso público. Al mismo tiempo, soy un desarrollador ordinario, sin mucho conocimiento y experiencia en hacks.
Toma de control de la gerencia
El ejemplo anterior introdujo código malicioso en la aplicación iOS. Pero, ¿qué pasaría si pudiéramos controlar la computadora del desarrollador en general? La capacidad de ejecutar código en su dispositivo, como sabe, le da al hacker un poder tremendo. Podrá activar el acceso remoto a través de SSH, instalar un keylogger, etc. Podrá observarte en cualquier momento, registrar tus acciones, usar el sistema de archivos. También podrá instalar nuevos certificados SSL y usarlos para interceptar todas las solicitudes que realice en la red. En una palabra, alguien tiene la oportunidad de ejecutar código en su computadora, y usted está completamente comprometido.
Pensé, "¿qué SDK de iOS puedo usar para esto?" Hay un servicio que proporciona al SDK el comando curl y un enlace HTTP con salida redirigida al comando sh. Es decir, su terminal descargará y ejecutará el script de shell.
Por sí solo, este método de instalación ya lo pone en riesgo, no lo haga. Pero en este caso, también se utilizó el protocolo HTTP. ¿Qué es posible hacer entonces?
Supongamos que eres un usuario. Vas a la página de documentación oficial. Preste atención al hecho de que la página está encriptada con el protocolo HTTPS, ¡excelente! Copia el comando, ejecútalo en casa. El comando se ejecuta en unos pocos segundos. ¿Qué ha pasado durante este tiempo?
Y durante este tiempo, un mecanismo de ataque simple que involucró a mi Raspberry Pi logró funcionar. El script de shell updateSDK cargado por el usuario contenía una pequeña salpicadura de mi propio código. Y ahora se me permite acceder a su computadora de forma remota a través de SSH, y también tiene un keylogger instalado.
A la izquierda verá "su" terminal, y a la derecha está mi Raspberry Pi, que en tiempo real ya muestra todo lo que ingresa en el teclado. Después de comenzar con Raspberry Pi SSH, inicio sesión con el nombre de usuario y la contraseña que acabo de registrar con el keylogger, y de esta manera obtengo acceso total para controlar su Mac y su sistema de archivos. Y también, probablemente, su empresa empleador tiene acceso a mucho.
En conclusión
¿Qué tan probable es que esto te suceda? Después de todo, los desarrolladores aún intentan usar Wi-Fi seguro, comprar una VPN.
Personalmente, también pensé que tenía cuidado hasta que un día abrí la configuración de mi Mac y descubrí en la historia de más de 200 conexiones a redes Wi-Fi inseguras. Cada una de esas conexiones es una amenaza potencial. E incluso utilizando una red confiable, no puede estar 100% seguro de su seguridad, porque no puede saber si alguno de los dispositivos en esta red se vio comprometido (como acabamos de ver).
Los ataques a través de redes Wi-Fi inseguras son muy comunes. Son fáciles de mantener en lugares públicos, como hoteles, cafeterías, aeropuertos y, por cierto, conferencias :) Imagine a un orador hablando de algún tipo de SDK y, como de costumbre, parte de la audiencia intenta instalarlo en paralelo conectándose al Wi-Fi que se entrega aquí. . Y como dije, es muy fácil abusar de sus derechos sobre un proveedor de la red.
De la misma manera con una VPN, simplemente te entregas al proveedor. ¿Y en quién mejor confiar: el proveedor de VPN o su red local y sus usuarios? Poco claro
En noviembre de 2017, realicé mi investigación y analicé la presencia de las vulnerabilidades enumeradas en los 41 SDK más populares para iOS (sin contar los SDK de Google y Facebook, todos están protegidos).
Como puede ver, el 31.7% de los SDK no pasaron las pruebas. Logré informar sobre casi todos los proveedores sobre los problemas existentes. De uno recibí una respuesta literalmente de inmediato, el problema se resolvió en tres días. Cinco equipos también reaccionaron, pero pasaron un poco más de tiempo en la revisión, aproximadamente un mes. Seven no se molestó en responder mi informe y no ha corregido nada hasta el día de hoy. Permíteme recordarte que no se trata de proyectos poco conocidos. Todos ellos se encuentran entre los SDK más famosos y tienen decenas de miles de usuarios que desarrollan aplicaciones iOS que usan estos SDK, que, a su vez, son utilizados por millones de usuarios de iPhone.
Es importante comprender que los usuarios de aplicaciones cerradas siempre están sujetos a mayores riesgos, mientras que los usuarios de aplicaciones de código abierto usan menos. No puede verificar cómo funciona una aplicación cerrada. Es extremadamente difícil juzgar si tiene soluciones seguras. Puede comparar valores hash y sumas hash, pero al hacerlo podrá verificar el éxito de la descarga. Por el contrario, puede investigar a fondo los productos de código abierto, a lo largo y ancho, lo que significa que puede proporcionar más protección.
Además de los ataques de hombre en el medio, hay otros. Un hacker puede atacar el servidor desde el que se descarga el SDK. También sucede que la empresa que suministra el SDK incluye deliberadamente las llamadas puertas traseras en el código a través de las cuales posteriormente podrá acceder sin autorización a los dispositivos de los usuarios (tal vez el gobierno local requiera la instalación de puertas traseras, y tal vez esta sea la iniciativa de la propia empresa).
Y somos responsables del producto que suministramos. Debemos estar seguros de que no estamos decepcionando al usuario y estamos cumpliendo con el GDPR. Los ataques a través del SDK son graves principalmente porque son masivos: están dirigidos no a un desarrollador, sino a un millón de dispositivos de usuario a la vez. Estos ataques pueden pasar desapercibidos para usted. El código fuente abierto te ayuda a protegerte de esto, con el código cerrado todo es mucho más complicado: úsalo solo cuando puedas confiar en él de manera segura. Gracias por su atencion
Si le gustó este informe, preste atención: el próximo Mobius de San Petersburgo se llevará a cabo del 22 al 23 de mayo, las entradas ya están a la venta y gradualmente se vuelven más caras.