Curso MIT "Seguridad de sistemas informáticos". Lección 21: Seguimiento de datos, Parte 1

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3
Lección 10: “Ejecución simbólica” Parte 1 / Parte 2 / Parte 3
Lección 11: "Ur / Lenguaje de programación web" Parte 1 / Parte 2 / Parte 3
Lección 12: Seguridad de red Parte 1 / Parte 2 / Parte 3
Lección 13: "Protocolos de red" Parte 1 / Parte 2 / Parte 3
Lección 14: "SSL y HTTPS" Parte 1 / Parte 2 / Parte 3
Lección 15: "Software médico" Parte 1 / Parte 2 / Parte 3
Lección 16: "Ataques de canal lateral" Parte 1 / Parte 2 / Parte 3
Lección 17: "Autenticación de usuario" Parte 1 / Parte 2 / Parte 3
Lección 18: "Navegación privada en Internet" Parte 1 / Parte 2 / Parte 3
Lección 19: "Redes anónimas" Parte 1 / Parte 2 / Parte 3
Lección 20: "Seguridad del teléfono móvil" Parte 1 / Parte 2 / Parte 3
Lección 21: “Datos de seguimiento” Parte 1 / Parte 2 / Parte 3

James Mickens: Genial, comencemos. Gracias por asistir a la conferencia en este día especial antes del Día de Acción de Gracias. Me alegro, muchachos, de que estén tan dedicados a la seguridad informática y estoy seguro de que tendrán demanda en el mercado laboral. Siéntase libre de referirse a mí como fuente de recomendaciones. Hoy hablaremos sobre el seguimiento de infecciones de Taint-tracking, en particular, sobre un sistema llamado TaintDroid, que proporciona este tipo de análisis de los flujos de información en el contexto de los teléfonos inteligentes Android.



El principal problema planteado en la conferencia es el hecho de que las aplicaciones pueden recuperar datos. La idea es que su teléfono contenga mucha información confidencial: una lista de contactos, su número de teléfono, dirección de correo electrónico y todo eso. Si el sistema operativo y el teléfono en sí no son cuidadosos, entonces la aplicación maliciosa puede extraer parte de esta información y enviarla de vuelta a su servidor doméstico, y el servidor podrá usar esta información para todo tipo de cosas desafortunadas, de las que hablaremos más adelante.

En un sentido global, un artículo sobre TaintDroid ofrece una solución: supervisar los datos confidenciales a medida que pasan a través del sistema y esencialmente detenerlos antes de que se transmitan a través de la red. En otras palabras, debemos evitar la posibilidad de pasar datos como argumento para las llamadas al sistema de red. Aparentemente, si podemos hacer esto, entonces esencialmente podemos detener la fuga en el momento en que comienza a suceder.

Quizás se pregunte por qué los permisos tradicionales de Android no son suficientes para evitar que se extraiga este tipo de datos. La razón es que estos permisos no tienen la gramática correcta para describir el tipo de ataque que estamos tratando de evitar. Los permisos de Android generalmente se ocupan de los permisos de la aplicación para escribir o leer algo de un dispositivo específico. Pero ahora estamos hablando de lo que está en un nivel semántico diferente. Incluso si a la aplicación se le otorgó el derecho de leer información o escribir datos en un dispositivo como una red, puede ser peligroso permitir que la aplicación lea o escriba ciertos datos confidenciales en un dispositivo con el que tiene permiso para interactuar.

En otras palabras, con las políticas de seguridad tradicionales de Android, es difícil hablar sobre tipos de datos específicos. Es mucho más fácil hablar sobre si la aplicación está accediendo al dispositivo o no. Quizás podamos resolver este problema utilizando una solución alternativa, lo designaré con un asterisco.



Esta solución alternativa es nunca instalar aplicaciones que puedan leer datos confidenciales y / o acceder a la red. A primera vista, el problema parece estar solucionado. Porque si una aplicación no puede hacer ambas cosas al mismo tiempo, no podrá acceder a datos confidenciales o podrá leerlos, pero no podrá enviarlos a través de la red. ¿Cuál crees que es la trampa?

Todos ya están pensando en el pavo festivo, lo veo en tus ojos. Bueno, la razón principal por la que esta es una mala idea es que esta medida puede interrumpir el trabajo de muchas aplicaciones legítimas. Después de todo, hay muchos programas, por ejemplo, clientes de correo, que de hecho deberían poder leer algunos datos confidenciales y enviarlos a través de la red.

Si solo decimos que vamos a evitar este tipo de actividad, en realidad prohibiremos el trabajo de muchas aplicaciones en el teléfono, lo que probablemente no gustará a los usuarios.
Hay otro problema aquí: incluso si implementamos esta solución, no evitaría la fuga de datos a través de un conjunto de mecanismos diferentes de canales de terceros. Por ejemplo, en conferencias anteriores, consideramos que la memoria caché del navegador, por ejemplo, puede contribuir a la filtración de información sobre un usuario que visita un sitio en particular. Por lo tanto, incluso con la implementación de dicha política de seguridad, no podremos controlar todos los canales de terceros. Un poco más tarde hablaremos de canales de terceros.

La solución propuesta no detendrá la colusión de aplicaciones cuando dos aplicaciones pueden trabajar juntas para romper el sistema de seguridad. Por ejemplo, ¿qué sucede si una aplicación no tiene acceso a la red, pero puede comunicarse con la segunda aplicación que la tiene? Después de todo, es posible que la primera aplicación pueda usar los mecanismos Android IPC para transferir datos confidenciales a una aplicación que tenga permisos de red, y esta segunda aplicación puede cargar esta información en el servidor. Pero incluso si las aplicaciones no están en colusión, entonces puede haber algún truco cuando una aplicación puede obligar a otras aplicaciones a entregar accidentalmente datos confidenciales.



Es posible que haya algún tipo de falla en el programa de correo electrónico debido a que recibe demasiados mensajes aleatorios de otros componentes del sistema. Entonces podríamos crear una intención especial para que Intent engañe al programa de correo electrónico, y obligaría a la aplicación de Gmail a enviar algo importante por correo electrónico fuera del teléfono. Entonces, esta solución alternativa no funciona lo suficientemente bien.

Por lo tanto, nos preocupa mucho que los datos confidenciales salgan del teléfono. Considere lo que, en la práctica, hacen las aplicaciones maliciosas para Android. ¿Hay algún ataque en el mundo real que pueda prevenirse mediante el seguimiento de infecciones de seguimiento de contaminación? La respuesta es si. Los programas maliciosos se están convirtiendo en un problema creciente para los teléfonos móviles. Lo primero que pueden hacer las aplicaciones maliciosas es usar su ubicación o IMEI para anunciar o imponer servicios.

El software malicioso puede determinar su ubicación física. Por ejemplo, no está lejos del campus del MIT, por lo que es un estudiante hambriento, entonces, ¿por qué no visitar mi restaurante con ruedas, que se encuentra muy cerca?

IMEI es un número entero que representa el identificador único de su teléfono. Se puede utilizar para su seguimiento en diferentes lugares, especialmente en aquellos en los que no desea "iluminar". Por lo tanto, en la naturaleza, hay programas maliciosos que pueden hacer tales cosas.

La segunda cosa que hace el malware es robar sus datos personales. Pueden intentar robar su número de teléfono o lista de contactos e intentar cargar estas cosas en un servidor remoto. Esto puede ser necesario para hacerse pasar por usted, por ejemplo, en un mensaje que luego se utilizará para enviar spam.

Quizás lo peor que puede hacer el malware, al menos para mí, es convertir su teléfono en un bot.



Esto, por supuesto, es un problema que nuestros padres no tuvieron que enfrentar. Los teléfonos modernos son tan potentes que pueden usarse para enviar spam. Hay muchos programas maliciosos dirigidos a ciertos entornos corporativos que hacen precisamente eso. Una vez en su teléfono, comienzan a usarlo como parte de una red de spam.

Estudiante: ¿ es un malware dirigido específicamente a hackear el sistema operativo Android, o es solo una aplicación típica? Si esta es una aplicación típica, ¿tal vez podríamos asegurarla con permisos?

Profesor: Esta es una muy buena pregunta. Hay dos tipos de malware. Al final resultó que, es bastante fácil hacer que los usuarios hagan clic en diferentes botones. Le daré un ejemplo que concierne no tanto al malware como al comportamiento descuidado de las personas.
Hay un juego popular, Angry Birds, vas a la App Store y lo buscas en la barra de búsqueda de aplicaciones. El primero en los resultados de búsqueda recibirá el juego original de Angry Birds, y la segunda línea puede contener la aplicación Angry Birdss, con dos s al final. Y muchas personas preferirán descargar esta segunda aplicación, ya que puede costar menos que la versión original. Además, durante la instalación, esta aplicación escribirá que después de la instalación le permitirá hacer tal y tal y tal, y dirá: "¡por supuesto, no hay problema!" Porque recibió los Angry Birds deseados por unos centavos. Después de este "boom", ¡estás enganchado a un hacker!

Pero tiene toda la razón cuando asume que si el modelo de seguridad de Android es correcto, entonces la instalación de malware dependerá por completo de la estupidez o la ingenuidad de los usuarios que le proporcionan acceso a la red, por ejemplo, cuando su juego "Tic Tac Toe" no debería tener acceso a red

Por lo tanto, puede convertir su teléfono en un bot. Esto es terrible por muchas razones, no solo porque su teléfono envía spam, sino también porque, quizás, usted paga por los datos de todas las cartas que se envían desde su teléfono. Además, la batería se agota rápidamente, porque su teléfono está constantemente ocupado enviando correo no deseado.

Hay aplicaciones que utilizarán su información personal para causar daño. Lo que es especialmente malo de este bot es que en realidad puede ver su lista de contactos y enviar spam en su nombre a las personas que lo conocen. Además, la probabilidad de que hagan clic en algo malicioso en esta carta aumenta muchas veces.



Por lo tanto, evitar la extracción de información es algo bueno, pero no evita la posibilidad de piratería. Hay mecanismos a los que debemos prestar atención en primer lugar, porque evitan que un atacante capture su teléfono inteligente al educar a los usuarios sobre lo que pueden hacer clic y no deben hacer clic de ninguna manera.

Por lo tanto, Taint-tracking por sí solo no es una solución suficiente para evitar una situación que amenaza con apoderarse de su teléfono.

Veamos cómo funciona TaintDroid. Como mencioné, TaintDroid rastreará toda su información confidencial a medida que se propaga a través del sistema. Entonces, TaintDroid distingue entre lo que se llama "fuentes de información" Fuentes de información y "sumideros de información". Las fuentes de información generan datos sensibles. Por lo general, estos son sensores: GPS, acelerómetro y similares. Puede ser su lista de contactos, IMEI, todo lo que puede conectarlo, a un usuario específico, con su teléfono real. Estos son dispositivos que generan información infectada, llamados fuentes de datos infectados: fuente contaminada.

En este caso, los sumideros de información son lugares donde los datos infectados no deben filtrarse. En el caso de TaintDroid, el principal absorbedor es la red. Más adelante hablaremos sobre el hecho de que puede imaginar más lugares donde se filtra información, pero la red ocupa un lugar especial en TaintDroid. Puede haber otros sumideros de información en un sistema de propósito más general que un teléfono, pero TaintDroid está diseñado para evitar fugas a la red.

TaintDroid usa un vector de bits de 32 bits para representar una infección de Taint. Esto significa que no puede tener más de 32 fuentes de infección separadas.



Por lo tanto, cada información confidencial tendrá una unidad ubicada en una posición determinada si fue infectada con alguna fuente específica de infección. Por ejemplo, se obtuvo de datos de GPS, de algo de su lista de contactos, y así sucesivamente.

Curiosamente, 32 fuentes de infección en realidad no son tantas. La pregunta es si este número es lo suficientemente grande para este sistema en particular y si es lo suficientemente grande para los sistemas generales que sufren fugas de información. En el caso especial de TaintDroid, 32 fuentes de infección son una cantidad razonable, porque este problema se refiere a un flujo limitado de información.

Teniendo en cuenta todos los sensores que están presentes en su teléfono, bases de datos confidenciales y similares, 32 parece ser la cantidad correcta en términos de almacenamiento de estas banderas infectadas. Como veremos en la implementación de este sistema, 32 es en realidad un número muy conveniente, ya que corresponde a 32 bits, un número entero con el que puede construir estos indicadores de manera efectiva.

Sin embargo, como veremos más adelante, si desea dar a los programadores la capacidad de controlar la fuga de información, es decir, especificar sus propias fuentes de infección y sus propios tipos de fugas, entonces 32 bits pueden no ser suficientes. En este caso, considere agregar un soporte de tiempo de ejecución más sofisticado para indicar más espacio.

Hablando en términos generales, cuando observa cómo fluye una infección a través de un sistema, en un sentido general, ocurre de derecha a izquierda. Daré un ejemplo simple. Si tiene algún tipo de operador, por ejemplo, declara una variable entera que es igual al valor de latitud de su ubicación: Int lat = gps.getLat (), entonces esencialmente lo que se encuentra a la derecha del signo igual genera un valor que tiene algún tipo de límite con su infección



Por lo tanto, se establecerá un indicador específico, que dice: "¡oye, este valor que devuelvo proviene de una fuente confidencial"! Entonces, la infección vendrá desde aquí, en el lado derecho, e irá aquí, a la izquierda, para infectar esta parte del lat. Así es como se ve a los ojos de un desarrollador que escribe el código fuente. Sin embargo, la máquina virtual Dalvik usa este formato de registro en minúsculas para crear programas, y así es como se implementa en realidad la semántica contaminada.

En la tabla de uno de los artículos de la conferencia hay una gran lista de comandos con una descripción de cómo la infección afecta a este tipo de comandos. Por ejemplo, puede imaginar que tiene una operación de movimiento-op que apunta al destino dst y los srs de origen. En una máquina virtual Dalvik, en un motor informático abstracto, esto puede considerarse registros. Como dije, la infección va del lado derecho al lado izquierdo, por lo que, en este caso, cuando el intérprete Dalvik ejecuta instrucciones desde el lado derecho, considera la etiqueta contaminante del parámetro sourse y la asigna al parámetro dst.

Supongamos que tenemos otra instrucción en forma de una operación binaria binaria-op que hace algo así como la suma. Tenemos un destino dst y dos fuentes: srs0 y srs1. En este caso, cuando el intérprete Dalvik procesa esta instrucción, toma la contaminación de ambas fuentes, las combina y luego asigna esta unión al dst de destino.



Es bastante simple La tabla muestra los distintos tipos de instrucciones que verá, pero en una primera aproximación, estas son las formas más comunes de propagación de infecciones en el sistema. Veamos algunos casos particularmente interesantes que se mencionan en el artículo. Uno de esos casos especiales son las matrices.

Suponga que tiene un comando char c que asigna un valor a C. Al mismo tiempo, el programa declara una matriz char upper [] que contendrá las letras mayúsculas "A", "B", "C": char upper [] = ["A "," B "," C "]

Una cosa muy común en el código es indexar en una matriz como esta, usando C directamente, porque, como todos sabemos, Kernigan y Ritchie aprenden que la mayoría de los caracteres son enteros. Entonces, puede imaginar que hay un código char upperC que dice que las versiones en mayúscula de estos caracteres "A", "B", "C" corresponden a los índices específicos en esta tabla: char upperC = upper [C]



Esto plantea la pregunta de qué infección debería obtener C superior en este caso. Parece que en casos anteriores todo fue simple con nosotros, pero en este caso tenemos muchas cosas sucediendo. Tenemos una matriz ["A", "B", "C"], que puede tener un tipo de infección y tenemos este símbolo C, que también puede tener su propio tipo de infección. Dalvik , binary-op. upperC [C] .

, upperC - upper [ ]. - [C]. , , upperC , .

: , taint move op binary op?

: move op. , srs… -, . , , , , , taint. , , .
, srs , , . srs : « , 2 , srs». .

– , taint. , srs0 srs1, taint, :

\

dst :

\

, , 32- , , . , . taints, , .
, , , binary-op. upperC [C] [«», «», «»]. TaintDroid , taint . , . , 32- , «» , .

, taint. — , , ? , taint , , . , , , , . - , .

, . , , - , , . , , – , , . .

, – , , Native methods, - . Native- . , Dalvik , system.arraycopy(), - , C C++. Native method, .

- JNI. JNI, Java Native Interface — C C++ Java. , Java , Java. x86, ARM , .

- taint , Dalvik. Java-, C C++ . , Native-, TaintDroid , Java.

\

, « », , taint. , – . - , . , Dalvik , system.arraycopy(), , taint. arraycopy() : « , , , , ».

? , , . , , Dalvik , , , .

- JNI , . , , , C C++, .

, , . , - , , , . .

26:25

Curso MIT "Seguridad de sistemas informáticos". 21: « », 2


.

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?