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

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

Estudiante: ahora en muchas aplicaciones no hay forma de eliminar los permisos.

Profesor: sí, en la nueva versión de Android esto no es así, simplemente hay descripciones de permisos. Pero puede usar el Administrador de permisos de Android, o el administrador de permisos de Android, que le permite ver una lista de todos los permisos para cada aplicación y eliminar específicamente aquellos que considere innecesarios. Pero no sé cómo esto es popular entre los usuarios.

Estudiante: si las etiquetas no coinciden con los permisos que requiere la aplicación, ¿esto conduce a un error grave o todo sigue funcionando bien?

Profesor: Creo que depende de lo que la aplicación esté tratando de hacer y de lo que permita la etiqueta. Por ejemplo, si una aplicación va a enviar Intención y enviar esta intención requiere una cierta etiqueta del tipo DIALPERM, primero se dirige al monitor de enlace, que dice: "desafortunadamente, el sistema no tiene una aplicación que esté lista para recibir su mensaje". Y en respuesta a esta aplicación, está tomando algunos pasos razonables.



De lo contrario, por ejemplo, al acceder a la red. Si no tiene acceso a la red, y va a abrir el socket o le dará el comando para conectarse a la dirección IP, el núcleo le responderá con el mensaje EPERM, "operación no permitida", es decir, no puede hacer esto. ¿Y quién sabe qué va a hacer la aplicación en este caso? Es posible que de alguna manera arroje una excepción de puntero nulo o haga algo así.

Un argumento en contra de esto es que las aplicaciones de Android, al menos inicialmente, no esperaban que algunas de sus llamadas fallaran, porque se les dijo que el manifiesto es todo o nada, es decir, o el usuario aprueba instalando la aplicación o no. Entonces, los desarrolladores de la aplicación escribieron el código correctamente, que se bloquea o hace algo inesperado si se le niega el acceso. Quizás al privar a la aplicación de los permisos de acceso que necesita, provoca una falla en su funcionamiento.

Suponga que tiene una aplicación que necesita acceso a la cámara. Y si le quitas el derecho de acceso, la plantilla de imagen simplemente aparecerá en la pantalla del teléfono inteligente, o tal vez la aplicación se bloqueará. Esto no es muy bueno. Probablemente, sería posible crear un sistema más complejo, que en caso de privación de acceso a la cámara simplemente mostraría una pantalla en negro todo el tiempo. Android no hace esto, pero puedes imaginar situaciones alternativas en las que esto podría suceder.

Entonces, examinamos de dónde provienen estas líneas en las etiquetas de las aplicaciones de Android. Pero, ¿quién define estas líneas, de dónde obtienen el significado? Puede enumerar todo tipo de líneas en el archivo de manifiesto, pero ¿cómo decide qué líneas son importantes, de dónde provienen las líneas de INTERNET o FRIENDVIEW? ¿Quién les da sentido en el sistema?



Veo que no tienes ideas. Creo que ninguna de estas líneas debería ser algo mágico o predeterminado. Casi todas estas líneas son básicamente acuerdos entre dos aplicaciones, cuando una de las aplicaciones está lista para proporcionar algo bajo la protección de alguna línea de Label, y la otra aplicación quiere solicitar permiso para hablar con la aplicación que proporciona este componente.

Por lo tanto, estas etiquetas generalmente están definidas por una aplicación que proporciona algunos servicios. Si tiene permiso DIALPERM, entonces debe estar definido en la aplicación, que define lo que significa marcar un número de teléfono. Aparentemente, la aplicación para hacer llamadas en su teléfono es lo que define esta línea y dice que sí, que esta cosa DIALPERM existe y que mis componentes estarán protegidos por ella. Luego, otras aplicaciones que deseen interactuar con la aplicación que realiza la llamada podrán solicitar este permiso DIALPERM por sí mismas.

Por supuesto, hay algunas cosas integradas, como el permiso para usar Internet, una cámara, etc. Pero puede percibirlos como las aplicaciones de origen del tiempo de ejecución de Android, que es responsable de proporcionar acceso a este recurso y define la línea que protegerá este recurso.

¿Qué significa esto? ¿Qué más está conectado con la etiqueta en Android, además del hecho de que la aplicación lo utiliza cuando necesita solicitar permiso? Resulta que hay varias cosas asociadas con la etiqueta. Además de la cadena, la etiqueta tiene varias propiedades interesantes. En particular, en Android hay 3 tipos de etiquetas. El primero son permisos regulares, el segundo son permisos inseguros y el tercero son permisos firmados.



La aplicación que determina este permiso en primer lugar tiene la oportunidad de seleccionar el tipo y todos los demás campos para la etiqueta, de lo que hablaremos en un segundo. Entonces, ¿qué son estos tipos de etiquetas? ¿Por qué las etiquetas de Android necesitan tipos?

Estudiante: ¿sirven como advertencia al usuario?

Profesor: exactamente. Entonces, ¿por qué no hacer todas las etiquetas de un tipo inseguro? ¿Cuál es la semántica de estos tipos? En pocas palabras, se usa una etiqueta "peligrosa" para permitir una aplicación que podría arruinar algo. Advierte a los usuarios cuando instalan la aplicación cuando la aplicación solicita acceso a un permiso inseguro. Al mismo tiempo, el usuario debe mirar este mensaje y decir: "Sí, estoy listo para dar permiso inseguro a esta nueva aplicación". Si las aplicaciones solicitan una etiqueta del tipo habitual, el usuario no recibe un mensaje sobre la necesidad de dar permiso para esta acción. ¿Qué significan los permisos ordinarios si todas las aplicaciones los reciben? ¿Hay alguna razón por la que deberíamos usar etiquetas de tipo regular?

Un ejemplo de una resolución típica en Android es configurar fondos de pantalla en pantalla. Si tiene una aplicación que va a instalar el fondo de pantalla, puedo, como desarrollador de la aplicación, indicarle en mi manifiesto que solo quiero instalar el fondo de pantalla. Y si hace clic en instalar, no sucederá nada interesante, ya que no necesita otorgarle ningún permiso a esta aplicación.

Estudiante: pero estos permisos generalmente requieren su confirmación, ¿verdad? Si la aplicación quiere cambiar el fondo de escritorio, el sistema le preguntará si desea cambiar el fondo de pantalla.

Profesor: no.

Estudiante: no?

Profesor: no, solo cambiará el fondo de pantalla porque es solo el acceso a la llamada API. Si tengo este permiso, solo hago una llamada a la API.

Estudiante: ¿ tal vez el desarrollador de la aplicación quiere asegurarse de que los usuarios no hagan esto por accidente?

Profesor: sí, creo que esta es una de las razones por las que puede necesitar estos permisos, es el deseo de ayudar al desarrollador a evitar errores. Si le preocupa que su aplicación pueda hacer algo mal accidentalmente o que pueda haber errores que se pueden usar, la existencia de un conjunto de permisos que puede recibir o no reducirá la probabilidad de abuso de su aplicación. Por lo tanto, si tiene una aplicación inofensiva que no necesita instalar ningún fondo de pantalla, no necesitará pedir ningún permiso, porque es mejor para el usuario en cuyo teléfono está instalado. Hasta cierto punto, este es un tipo de privilegio.

Otra cosa es que la existencia de etiquetas del tipo habitual le permite realizar algún tipo de auditoría, tanto del lado del desarrollador como del lado del usuario. Si su teléfono cambia el fondo de pantalla en la pantalla cada segundo, puede ingresar y ver qué aplicación tiene permiso para esto. Incluso si no aprobó la concesión de dicho permiso, aún puede ir y verificar qué aplicación está actualmente comprometida a cambiar el fondo de pantalla.

Por lo tanto, estos permisos comunes parecen ser una buena medida de seguridad o, en mayor medida, una buena oportunidad para auditar la actividad de la aplicación. Por lo general, este tipo de etiqueta no se usa para cosas realmente importantes, como trabajar con datos o acceder a servicios que cuestan dinero.

El tercer tipo de etiqueta es el permiso de firma. Una propiedad interesante de Android es la capacidad de proporcionar acceso solo a las aplicaciones que están firmadas con la misma firma digital que la aplicación en la que se declara el derecho de acceso. El artículo de la conferencia describe un ejemplo con FRIENDVIEW. Si ver amigos tiene un permiso definido con este tipo de etiqueta, las aplicaciones firmadas con la misma clave de desarrollador podrán obtener el mismo permiso. ¿Cuál es el punto de esta cosa? ¿Por qué no simplemente marcarlos como inseguros? ¿Por qué necesitamos un tercer tipo de etiquetas?

Estudiante: ¿ Facilita que un desarrollador administre sus aplicaciones?

Profesor: si. Es posible que este desarrollador tenga API internas que quiere aislar de los efectos de programas de terceros, pero al mismo tiempo quiere agrupar sus propias aplicaciones para una interacción productiva. Hipotéticamente, los creadores de Facebook podrían escribir varias aplicaciones. Podrían tener una aplicación que precarga el contenido de los servidores de Facebook, otra aplicación mezcla ese contenido, un tercero rastrea su ubicación y todos estos componentes interactúan entre sí. Para tal caso, podrían usar un permiso firmado.

Una de las razones por las que no desea designar esta aplicación como insegura es la siguiente. Si realmente sabe quién puede obtener este permiso, no desea que intervenga el usuario. Debido a que el usuario siempre puede ser engañado al forzar el permiso para dar una aplicación maliciosa, por lo tanto, es mejor que no interfiera en absoluto con la provisión de privilegios internos para algunas aplicaciones. Entonces, en este sentido, es mejor usar permisos firmados.

Las etiquetas también tienen una descripción de los permisos del usuario. Esta es una descripción de lo que implica este permiso. Esta descripción aparece cuando se le solicita que instale una nueva aplicación.



Por lo tanto, el tiempo de ejecución de Android analizará todas las líneas de etiquetas en el manifiesto de la aplicación que va a instalar y mostrará al usuario descripciones de todas estas líneas marcadas, por ejemplo: "le dará a esta aplicación el privilegio de marcar o permitirá enviar SMS en su nombre" y etc.

Una pregunta interesante: ¿qué sucede si una aplicación maliciosa cambia la etiqueta de otra aplicación? Después de todo, estas marcas son solo cadenas de forma libre. Entonces, ¿qué sucede si usted es una aplicación maliciosa que dice: "¡Oh, tengo esta nueva resolución grande! Se llama DIALPERM ". No tiene una etiqueta insegura, y su descripción no da nada. ¿Es esto peligroso?

Estudiante: probablemente no podrá afectar la estructura del nombre de dominio de la aplicación.

Profesor: sí, esto se puede esperar, pero, desafortunadamente, esto no es obligatorio. Por lo general, todas las cadenas de permisos deben tener nombres de dominio de estilo Java, pero no existe una relación estricta entre las etiquetas que define la aplicación y el nombre de la aplicación de estilo Java. No hay nada que obligue a que el nombre de la aplicación de estilo Java esté vinculado a algo, por lo que no tenemos la oportunidad de averiguar si la clave pública del desarrollador que firma la aplicación específica coincide con algo en com.google.something o edu. mit.algo.

Hay un inconveniente en Android, o al menos existía cuando recientemente profundicé en esta pregunta. Entonces, al definir las etiquetas, se sirve el principio "quien vino primero,". Es decir, cuando instala la aplicación, define una etiqueta específica y puede decidir qué tipo de etiqueta es y cuál es su descripción. Para los permisos del sistema, esto probablemente no sea un gran problema, porque los permisos del sistema o las aplicaciones integradas, como un marcador, se definen desde el principio. Pero las aplicaciones que se instalan más tarde no pueden anular los permisos, porque esto se debe al marco.

El problema es que si primero instala una aplicación maliciosa, y luego alguna aplicación importante, la aplicación maliciosa puede distorsionar las etiquetas que luego utilizará la aplicación bien intencionada. El artículo de la conferencia describe un caso en el que un atacante obliga a un usuario a instalar una aplicación maliciosa que cambia el tipo de etiqueta para la aplicación FRIENDVIEW a un tipo normal con una línea descriptiva como "no hay nada interesante". Más tarde, cuando instala el applet FRIENDVIEW, ya no puede anular esta etiqueta, porque ya está definida, y ahora el usuario no podrá evitar que otras aplicaciones usen el permiso de visualización de amigos.

Estudiante: ¿ quizás el sistema podría advertir sobre intentos de cambiar la resolución?

Profesor: en principio, el marco es capaz de esto, pero cuando intenté hacer esto, no se emitieron mensajes. Si instala una aplicación que define una etiqueta que ya está definida, el sistema no hace nada, simplemente ignora la nueva definición de etiqueta y usa la antigua. Quizás este sea el problema, por lo que todo puede salir mal. Como mínimo, el sistema debería decir: "Me niego a instalar esta aplicación porque ya tiene una definición de etiqueta".

Estudiante: ... y pertenece a otra aplicación.

Profesor: sí, e incluso puede pertenecer a otra clave. Entonces, al menos potencialmente, existe la posibilidad de arreglarlo todo. No rastreé este problema, tal vez ya se ha solucionado. En cualquier caso, este es un problema interesante, cuando realmente tiene que hacer un seguimiento de estos nombres y averiguar quién es el propietario de este nombre, y obtener el derecho de cometer tales acciones es realmente muy importante.

Otro problema interesante de Android está relacionado con el receptor de difusión, o el receptor de mensajes de difusión. Crea la capacidad de recibir y responder mensajes de otras aplicaciones, implementando algo como enviar mensajes entre aplicaciones. Primero tengo que describir cómo interactúan estos mensajes con el receptor. Los receptores de difusión se utilizan para una aplicación, que puede anunciar algunos eventos para cualquier otra aplicación en el sistema.



Como sabemos, las intenciones generalmente se dirigen a un componente específico, por ejemplo, un visor de imágenes JPEG. Pero sobre eventos como la carga del sistema o "Mis amigos cercanos", puede anunciar a todas las aplicaciones que le conciernen. Para eso es el receptor Broadcast.

Hay dos cosas que te preocupan. En primer lugar, la autenticación de la fuente del mensaje, es decir, desea saber quién envió este mensaje y si puede confiar en él. En segundo lugar, desea controlar a quién se dirige este mensaje y quién puede recibirlo.

Me parece que los desarrolladores de Android no implementaron estas cosas correctamente. En cualquier caso, en la versión inicial de Android, cuando envía un mensaje de difusión a todos los demás componentes del sistema, estas aplicaciones pueden o no admitir este mensaje. Por lo tanto, si tiene la aplicación Ver amigos, admitirá estos mensajes mediante el uso de los componentes apropiados, como Acción o Fecha / MIME, en su filtro Intención de intención. Pero la mayoría de las aplicaciones siempre pueden admitir todos los eventos de transmisión en el sistema, y ​​puede ver todo lo que sucede en el teléfono o todo lo que se transmite.

Por lo tanto, el marco de Android agregó un argumento adicional para que las aplicaciones indiquen quién puede ver el mensaje de difusión.



, , – , , . , , , , .

, , , , , , . Android, , , , .

, ? , « » , . , ? ?

: ? ?

: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?

, . , , . , . ? , « »?

: , , ?
: . , — . , , « ».



Broadcast receiver, , , . , , , Label.

. Android , . « », . , . , , , .

RPC , RPC-, , . , .

: ?

: , , .

: , …

: , . – . . : « ».

: ?

: .

: , ?

: , , . . , , , . , — . , : « , », , , Dangerous Description.



, : „ , ». , , , , . , Android , .

, , Android. , , . , «», « ». , , .



, , . , , , , , . , Java. , , , , .

Android . - , , , , . «» , RPC . , .

, , . , Android , 5 6 . , , , - «». , , .

, Android , , Apple . , Apple iPhone , .

«», «», , , , , , , . , . , , Android, . , - .

, Android .


.

, . ? ? , 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 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?