Curso MIT "Seguridad de sistemas informáticos". Lección 20: Seguridad del teléfono móvil, Parte 2

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

Antes de comenzar una revisión detallada del sistema, intentemos descubrir algo interesante: ¿por qué estos chicos desarrollaron un diseño modular completamente nuevo para aplicaciones de Android? Hay aplicaciones de escritorio, hay aplicaciones web, ¿por qué tenían que inventar una forma completamente nueva de escribir software? De hecho, en cierto sentido, esto es confuso para el desarrollador. Porque, digamos, estoy acostumbrado a escribir mi pequeño programa en C con la función principal, y ahora lo miro y digo: "¿qué demonios? ¿Qué haré con todo esto? ¿Tengo que definir cuatro tipos de componentes y enviar intenciones, en lugar de usar estructuras C y escribir código en líneas regulares?



¿Cuáles son los pros y los contras de los modelos de aplicación existentes? Tenemos aplicaciones de escritorio e Internet, ¿por qué necesitamos un tercer tipo de aplicación?
Estudiante: pero el modelo ha cambiado por completo, ¿verdad? Creo que no debe confiar tanto en los desarrolladores de aplicaciones de escritorio como en los desarrolladores de aplicaciones para dispositivos móviles. Además, tiene usuarios más experimentados en comparación con el número de usuarios experimentados de aplicaciones informáticas, y desean utilizar un montón de aplicaciones aisladas entre sí.

Profesor: muy posiblemente. Entonces, ¿crees que en el caso de las aplicaciones de escritorio, no deberíamos confiar demasiado en sus desarrolladores?

Estudiante: por supuesto, porque siempre hay un hijo o primo más experimentado que lo ayudará a resolver problemas con los programas de computadora, pero las cosas son diferentes con el teléfono.

Profesor: Por supuesto, es genial que los teléfonos no necesiten un primo para cuidarlos. Pero desde el punto de vista de la seguridad, los programas de computadora tienen una propiedad característica: instalar una nueva aplicación en una computadora puede ser un proceso que consume bastante tiempo. Tal vez esto no sea del todo cierto, porque siempre puedes hacer clic en el archivo ejecutable e iniciar la instalación, pero no creo que las personas instalen regularmente aplicaciones de escritorio. Después de todo, como regla general, tiene un conjunto fijo de software que ejecuta.

En este sentido, una característica distintiva de las aplicaciones web es su fácil lanzamiento. Simplemente vaya al sitio, y no necesita hacer nada más que hacer clic en el enlace, y ahora ya está en algún sitio nuevo bajo el control de alguna nueva aplicación. Así que esta es una propiedad bastante buena de una aplicación web.



Una mala característica de las aplicaciones informáticas es la falta de aislamiento de las aplicaciones. Quizás esto se deba de alguna manera al hecho de que cuando instala una aplicación de este tipo, confía completamente en todo lo que está en su computadora. De hecho, no hay aislamiento entre la aplicación que instala en su computadora portátil y cualquier otro programa o datos que ya esté allí, mientras que en el caso de la aplicación web hay un aislamiento razonable. Mientras confíe en la Política del mismo origen, estará a salvo. Por lo tanto, es lo suficientemente seguro como para ir a un sitio web arbitrario y comenzar a usar su aplicación. Si esta aplicación no aprovecha las vulnerabilidades en su navegador, no interferirá con el funcionamiento de los sitios abiertos en otras pestañas del navegador.



Las aplicaciones web todavía parecen estar en una mejor posición, ya que son fáciles de usar y aisladas. ¿Por qué estos tipos no usan aplicaciones web de Android?

Estudiante: las aplicaciones web parecen contener un sistema operativo, es decir, hay un sistema operativo Firefox, que es esencialmente un sistema operativo de Internet móvil.

Profesor: seguro. Afirmas que estos tipos están realmente equivocados. Se suponía que no debían crear un nuevo sistema operativo Android, sino simplemente crear un navegador web gigante para su teléfono.

Estudiante: al menos Mozilla ha demostrado que esto es posible.

Profesor: bueno, eso es bastante justo. Como mínimo, es más sabio seguir el camino de la creación de aplicaciones web que los sistemas de escritorio, al menos para el teléfono.

Estudiante: dado que está realizando una llamada telefónica desde una aplicación web, debe crear una API completamente nueva para comunicar la interfaz de la aplicación web con el teléfono.

Profesor: seguro. Por lo tanto, las aplicaciones web tienen una limitación que se puede solucionar: la falta de una API para algunos dispositivos móviles. Pero hay menos aplicaciones de este tipo. Por ejemplo, para una cámara o para un navegador GPS, lentamente, pero aún agregan la interfaz adecuada a las aplicaciones web. Pero allí, en las aplicaciones web, probablemente todavía no haya una API para hacer llamadas, enviar mensajes SMS y similares.

Otra desventaja de las aplicaciones web es la incapacidad de establecer un acceso limitado a otras aplicaciones. Hablamos de intenciones implícitas en Android, donde simplemente podría decir: “Quiero ver esta imagen JPEG, pero ¿quién sabe qué aplicación la abrirá? O quiero ver este archivo PDF o compartir esta foto con mi amigo que acabo de tomar con mi cámara, pero no sé qué aplicación de correo electrónico se utilizará ". Entonces, solicitemos al monitor de enlaces que me encuentre algún programa de correo electrónico que envíe esta foto. En un dispositivo Android, esto es fácil de hacer, pero en el caso de las aplicaciones web causará grandes dificultades, ya que cada interacción debe vincularse a una URL específica.



Entonces, si no sabe qué visor de PDF está usando alguien, entonces no sabrá qué URL puede usar para ver su archivo.

Estudiante: ¿ quizás un inconveniente de las aplicaciones web es que JavaScript es muy difícil de leer?

Profesor: sí, lo es, otro inconveniente es que todos están escritos en JavaScript. Por lo tanto, puede que esto no sea muy bueno en términos de rendimiento, puede ser difícil entender lo que está haciendo el programa, puede ser difícil de compilar de manera eficiente, etc.

Volvamos a los programas de computadora. Una característica útil de las aplicaciones de escritorio es la capacidad de compartir archivos. Todos sus archivos están disponibles en todas las aplicaciones porque solo los comparte. Por lo tanto, tiene fácil acceso a cualquier información disponible en la computadora.



Lo que es un poco difícil de implementar en Android es fácil de hacer en aplicaciones informáticas. En el caso de los sistemas operativos de escritorio, si quiero compilar una pieza de software, ejecutaré MAKE, GCC y, posiblemente, algunos otros programas, y todos trabajarán en el mismo código fuente C en el mismo directorio. Esto es mucho más difícil de hacer en Android, donde los datos están asociados con la aplicación principal, que es almacenada por el proveedor de contenido. Por lo tanto, debe jugar con él, primero usando el repositorio de código fuente y luego instalando el compilador de C, el programa MAKE, el ensamblador y más. Es mucho más difícil lograr que trabajen juntos.

Esto se puede hacer sin pasar por algunas de las limitaciones de Android, pero en cualquier caso es más complicado que en los sistemas de escritorio.

Estudiante: Creo que optimizar las aplicaciones web es bastante difícil, están limitadas por el uso de RAM y la potencia de procesamiento.

Profesor: sí, los principios de optimización de aplicaciones web y aplicaciones de escritorio son diferentes. Creo que el inconveniente de las aplicaciones web, al menos en el momento en que diseñaban Android, era que lanzar la aplicación web sin conexión era muy difícil. Si su teléfono detecta una señal de red débil, algunas aplicaciones serán difíciles de iniciar, especialmente si algunas de sus partes se han caído del caché. Sin embargo, creo que, como habrán notado, las aplicaciones web, aunque lentamente, "ponen al día" a Android eliminando las restricciones actuales. Por lo tanto, es muy posible que las aplicaciones web sirvan como un modelo razonable para lanzar una nueva plataforma operativa de teléfonos. Pero hace cinco años no eran lo suficientemente buenos para esto.

Pero incluso a pesar de las deficiencias existentes, ahora será mucho más fácil "empujar" las aplicaciones web al nicho ocupado por Android, en lugar de comenzar a desarrollar un nuevo sistema operativo móvil desde cero. Por lo tanto, creo que aún podemos hablar sobre los éxitos de lo que Android ha hecho, aunque quizás hoy prefiera no hacerlo de esta manera.
Creo que en términos de aislamiento, la seguridad del sistema Android es mucho mayor. Como mencioné, Android se basa en el kernel de Linux para aislar las aplicaciones entre sí. La plataforma Android en realidad establece ID de usuario, por lo que esta aplicación 1 tendrá UID 1001, la aplicación 2 tendrá UID 1002, y el monitor de enlace, que generalmente tiene privilegios de root, tendrá UID 0. Por lo tanto, el kernel de Linux es en gran parte responsable de Separación de aplicaciones entre sí.



Básicamente, la interacción entre los identificadores de usuario se produce a través de intenciones intencionales. Hay muchos más matices sobre cómo el kernel de Linux controla las aplicaciones utilizando el UID, hablaremos de esto un poco más adelante.

Una pregunta interesante: ¿por qué estos tipos eligieron Java? ¿Cuál es el papel de Java en Android? ¿Por qué es necesario? Si escribimos todas las aplicaciones en C en lugar de Java, o, por ejemplo, Assembler, ¿se puede romper algo?

Estudiante: si tiene vulnerabilidades, el uso de estos idiomas puede conducir a una distorsión de los indicadores importantes para el sistema.

Profesor: sí, esto puede suceder, por ejemplo, puede producirse un desbordamiento del búfer en la aplicación. Que mas

Estudiante: puede ocurrir confusión con los permisos.

Profesor: ¿con qué permisos?

Estudiante: con latencia, latencia.

Profesor: echemos un vistazo más de cerca a esto. Entonces, como dijimos, el monitor de enlace comprueba las etiquetas por nosotros y en realidad almacena en el sistema Android una lista de todas las aplicaciones instaladas junto con las etiquetas que corresponden a todas estas aplicaciones. Por lo tanto, es probable que no desee que el monitor de enlaces cometa errores sin importar en qué idioma esté escrito. Por lo tanto, tener un monitor de enlace escrito en un lenguaje de tipo seguro es una buena solución. Me gusta Java porque es un lenguaje de tipo seguro con buenas características. Pero incluso si la aplicación se escribiera en C y se produjeran desbordamientos del búfer, aún no podría dañar las etiquetas en el monitor de enlace. Entonces eso no sería un gran problema.

Estudiante: ¿ tal vez hay algún tipo de sistema que pueda dañar el código escrito en C?

Profesor: sí, por lo tanto, en principio, sería bueno evitar las aplicaciones que hablan directamente al kernel de Linux. En Android, este no es el caso. Las aplicaciones de Android pueden hacer llamadas arbitrarias al sistema si lo desean. De hecho, por razones de rendimiento, las aplicaciones no pueden afectar componentes arbitrarios escritos en C o Assembler, por lo que algunos juegos "hablan" en Java.

Estudiante: Creo que de alguna manera esta es una oportunidad para usar todo el material escrito para Java, es decir, los creadores de Android querían simplificar la creación de aplicaciones para desarrolladores. Y una de las formas más fáciles de hacer esto es hacer posible aprovechar las voluminosas bibliotecas de Java.

Profesor: muy posiblemente. Creo que una de las principales razones para usar Java es la usabilidad. Probablemente estaban más preocupados por la programación y la facilidad de desarrollo, ya que Java tiene poco que ver con la seguridad.

Otra cosa que tiene un lugar aquí, a diferencia de iPnone. El sistema operativo del iPhone también es fácil de desarrollar, pero usa C, y si lo intentas, puedes causar un desbordamiento del búfer. Además, existe una especificidad para un equipo en particular, por lo que es posible que no todos tengan las mismas bibliotecas. Creo que la razón principal por la que los desarrolladores de Android eligieron Java es porque inicialmente no sabían las características de los dispositivos en los que funcionará este sistema operativo. Por ejemplo, los creadores del iPhone sabían con certeza que tendrán un procesador ARM en su teléfono, por lo que precompilaron el software con este modelo en particular. Y este enfoque es más efectivo, porque el consumo de batería es de gran importancia para el teléfono.



El hecho de que los chicos de Android usen Java probablemente sea menos eficiente en términos de ahorro de energía o rendimiento del procesador, ya que está relacionado con el JRE, etc. Pero luego está la ventaja de portar el sistema operativo a dispositivos con diferentes arquitecturas. Por lo tanto, si tiene teléfonos con procesadores MIPS, ARM o x86, la aplicación Java se puede ejecutar en los tres dispositivos. Los desarrolladores de Android querían que su plataforma se usara en cualquier tipo de equipo o teléfono. Entonces, esta es probablemente la razón principal por la que sacrificaron la seguridad por el uso de Java.

Resulta que el entorno de tiempo de ejecución de Java no proporciona ningún beneficio de seguridad especial para las aplicaciones, es solo algo conveniente para los desarrolladores y usuarios. Pero desde el punto de vista del aislamiento, todo depende básicamente del núcleo y del monitor de enlace que controla el funcionamiento de las aplicaciones.

Estudiante: ¿La facilidad de desarrollo no conduce a cierta seguridad de la aplicación? De hecho, al escribir un monitor de referencias en C, hay muchas más formas de cometer errores.

Profesor: sí, tienes toda la razón! De hecho, no debería haber dicho que la facilidad de desarrollo no tiene nada que ver con la seguridad. Esto es completamente estúpido porque quieres hacerlo tan fácilmente como escribir el código correcto. Entonces, en cierto sentido, un sistema para el que puede escribir fácilmente el código correcto solo proporciona más seguridad. En cierto sentido, tiene razón al suponer que los desarrolladores de Android querían evitar errores al escribir el código, por lo que no querían escribirlo en el complejo lenguaje C. Y no sé por qué Apple eligió C como lenguaje de programación al desarrollar su sistema operativo.

Debido a que tal elección crea un problema de desbordamiento de búfer en la aplicación, y si esta aplicación es de gran importancia, entonces es potencialmente vulnerable. No en relación con comprometer otras aplicaciones, pero aún así no desea que su aplicación bancaria se escriba en C.



Estudiante: ¿ Link Monitor escrito en Java o C?

Profesor: En Android, el monitor de enlace está escrito principalmente en Java. Sin embargo, hay algunos "ganchos" para comunicarse con interfaces y aplicaciones externas utilizando código nativo. Pero la mayor parte de la lógica está escrita en Java. Entonces este es en realidad un plan bastante seguro.

Ahora intentemos averiguar para qué más se usan los UID de la aplicación, excepto para separar las aplicaciones entre sí en términos de los procesos que inician. La razón principal para usar el UID es crear la capacidad de compartir el acceso a recursos compartidos e intercambiar datos en el sistema.

Ya hemos visto un mecanismo para esto: enviar intenciones al monitor de enlace. Pero en Android, hay toneladas de cosas que no se están haciendo a través de la intención del monitor de enlace. Probablemente no todo se envía por Intención por razones de rendimiento. No desea llamar al monitor de enlace para cada operación que realice en el sistema, en primer lugar, se trata del acceso a Internet. Si desea acceder a Internet en un dispositivo con Android, simplemente abra el zócalo, como en cualquier aplicación Linux estándar. Una aplicación simplemente puede preguntarle al kernel: "Necesito un socket porque quiero conectarme a esta máquina", así es como se accede a Internet.

A continuación, debe tenerse en cuenta el acceso a los medios extraíbles. SD-, . , , , , , . , . , , Android . , , GPS-, .



«» Android, Linux, /dev/camera. Linux, , , . , - , , Java. C Assembler, Linux, . Java , Java-.

: , , - , ?

: , ! , . ? , №2, ID . Android UID GID , . , . , , , - «android.permission.internet», , .



, . , , , . — Linux Android. , - , - , , Linux. Android GID 3003, . , , . , - . Android - , . , GID UID .

SD-. GID, SD-, , . , . , SD- GID SD-.
, , Android.



, , , . , SQL -, , . — UID , , .

, , , GPS, . GID, . , , dev/camera - GID, , , GID .

, , №2, , UID GID , - .

, SD-? , SD-? , SD- , , . ?

: , , , , .

: . , Android , . , SD- . , , SD- . , Android , , , FAT, - . , , - .

: , ?

: , . , , . , , , , . , .



— , , ? , , DIALPERM, INTERNET, FRIENDVIEW?

: , , ?

: , , , . , , . , . Android , iOS, , iPhone , , , SMS-, JPEG . .

– , , . . , Android , , . , - «», , , , , OK. , , .

, , , Android , — , . , , , . Android, 4.3, , , . , . , , , , . , , API, , .

55:10

MIT « ». 20: « », 3


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

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

Dell R730xd 2 ? 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los EE. UU. 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?