Cours MIT "Sécurité des systèmes informatiques". Conférence 21: Suivi des données, partie 1

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3
Conférence 9: «Sécurité des applications Web», partie 1 / partie 2 / partie 3
Conférence 10: «Exécution symbolique» Partie 1 / Partie 2 / Partie 3
Conférence 11: «Ur / Web Programming Language» Partie 1 / Partie 2 / Partie 3
Conférence 12: Sécurité du réseau, partie 1 / partie 2 / partie 3
Conférence 13: «Protocoles réseau», partie 1 / partie 2 / partie 3
Conférence 14: «SSL et HTTPS» Partie 1 / Partie 2 / Partie 3
Conférence 15: «Logiciel médical» Partie 1 / Partie 2 / Partie 3
Conférence 16: «Side Channel Attacks» Partie 1 / Partie 2 / Partie 3
Conférence 17: «Authentification des utilisateurs», partie 1 / partie 2 / partie 3
Conférence 18: «Navigation privée sur Internet» Partie 1 / Partie 2 / Partie 3
Conférence 19: «Réseaux anonymes» Partie 1 / Partie 2 / Partie 3
Conférence 20: «Sécurité des téléphones portables» Partie 1 / Partie 2 / Partie 3
Conférence 21: «Suivi des données» Partie 1 / Partie 2 / Partie 3

James Mickens: Super, commençons. Merci d'être venu à la conférence ce jour spécial avant Thanksgiving. Je suis heureux, les gars, que vous soyez si dévoué à la sécurité informatique et je suis sûr que vous serez en demande sur le marché du travail. N'hésitez pas à me référer comme source de recommandations. Aujourd'hui, nous allons parler du suivi des infections par Taint-tracking, en particulier d'un système appelé TaintDroid, qui fournit ce type d'analyse des flux d'informations dans le contexte des smartphones Android.



Le principal problème soulevé dans la conférence est le fait que les applications peuvent récupérer des données. L'idée est que votre téléphone contient beaucoup d'informations confidentielles - une liste de contacts, votre numéro de téléphone, votre adresse e-mail et tout ça. Si le système d'exploitation et le téléphone lui-même ne font pas attention, l'application malveillante pourra peut-être extraire certaines de ces informations et les renvoyer à son serveur domestique, et le serveur pourra utiliser ces informations pour tous les types de choses malheureuses, dont nous parlerons plus tard.

Dans un sens global, un article sur TaintDroid propose une telle solution: surveiller les données confidentielles lors de leur passage dans le système, et les arrêter essentiellement avant leur transmission sur le réseau. En d'autres termes, nous devons empêcher la possibilité de passer des données comme argument aux appels système du réseau. Apparemment, si nous pouvons le faire, alors nous pouvons essentiellement arrêter la fuite au moment même où elle commence à se produire.

Vous vous demandez peut-être pourquoi les autorisations Android traditionnelles ne suffisent pas pour empêcher l'extraction de ce type de données. La raison en est que ces autorisations n'ont pas la grammaire correcte pour décrire le type d'attaque que nous essayons d'empêcher. Les autorisations Android traitent généralement des autorisations d'application pour écrire ou lire quelque chose à partir d'un appareil spécifique. Mais maintenant, nous parlons de ce qui est à un niveau sémantique différent. Même si une application a obtenu le droit de lire des informations ou d'écrire des données sur un appareil tel qu'un réseau, il peut être dangereux de permettre à l'application de lire ou d'écrire certaines données confidentielles sur un appareil avec lequel elle est autorisée à interagir.

En d'autres termes, en utilisant les politiques de sécurité Android traditionnelles, il est difficile de parler de types de données spécifiques. Il est beaucoup plus facile de savoir si l'application accède ou non à l'appareil. Peut-être que nous pouvons résoudre ce problème en utilisant une solution alternative, je le désignerai avec un astérisque.



Cette solution alternative consiste à ne jamais installer d'applications capables de lire des données sensibles et / ou d'accéder au réseau. À première vue, le problème semble résolu. Parce que si une application ne peut pas faire ces deux choses en même temps, soit elle ne pourra pas accéder aux données sensibles, soit elle pourra les lire, mais elle ne pourra pas les envoyer sur le réseau. Selon vous, quel est le piège?

Tout le monde pense déjà à la dinde festive, je le vois dans tes yeux. Eh bien, la principale raison pour laquelle c'est une mauvaise idée est que cette mesure peut briser le travail de nombreuses applications légitimes. Après tout, il existe de nombreux programmes, par exemple les clients de messagerie, qui devraient en fait pouvoir lire certaines données sensibles et les envoyer sur le réseau.

Si nous disons simplement que nous allons empêcher ce type d'activité, nous interdirons en fait le travail de nombreuses applications sur le téléphone, ce que les utilisateurs n'aimeront probablement pas.
Il y a un autre problème ici - même si nous implémentions cette solution, cela n'empêcherait pas la fuite de données via un tas de mécanismes différents de canaux tiers. Par exemple, dans des conférences antérieures, nous avons considéré que le cache du navigateur, par exemple, peut contribuer à la fuite d'informations sur un utilisateur visitant un site particulier. Par conséquent, même avec la mise en œuvre d'une telle politique de sécurité, nous ne pourrons pas contrôler tous les canaux tiers. Un peu plus tard, nous parlerons des chaînes tierces.

La solution proposée n'arrêtera pas la collusion des applications lorsque deux applications peuvent travailler ensemble pour briser le système de sécurité. Par exemple, que se passe-t-il si une application n'a pas accès au réseau, mais qu'elle peut communiquer avec la deuxième application qui l'a? Après tout, il est possible que la première application puisse utiliser les mécanismes IPC Android pour transférer des données confidentielles vers une application disposant d'autorisations réseau, et cette deuxième application peut télécharger ces informations sur le serveur. Mais même si les applications ne sont pas en collusion, il peut y avoir une astuce lorsqu'une application peut forcer d'autres applications à divulguer accidentellement des données sensibles.



Il est possible qu'il y ait une sorte de faille dans le programme de messagerie électronique à cause de laquelle il reçoit trop de messages aléatoires d'autres composants du système. Ensuite, nous pourrions créer une intention spéciale pour l'intention de tromper le programme de messagerie, et cela forcerait l'application Gmail à envoyer quelque chose d'important par courrier électronique en dehors du téléphone. Cette solution alternative ne fonctionne donc pas assez bien.

Nous sommes donc très inquiets que des données confidentielles quittent le téléphone. Considérez ce que font en pratique les applications malveillantes pour Android. Y a-t-il des attaques dans le monde réel qui peuvent être évitées en suivant les infections de suivi des souillures? La réponse est oui. Les programmes malveillants deviennent un problème croissant pour les téléphones portables. La première chose que les applications malveillantes peuvent faire est d'utiliser votre emplacement ou IMEI pour annoncer ou imposer des services.

Un logiciel malveillant peut déterminer votre emplacement physique. Par exemple, vous n'êtes pas loin du campus du MIT, donc vous êtes un étudiant affamé, alors pourquoi ne pas visiter mon restaurant à roues, qui est situé tout près?

IMEI est un entier représentant l'identifiant unique de votre téléphone. Il peut être utilisé pour votre suivi dans différents endroits, en particulier dans ceux où vous ne voudriez pas "s'allumer". Ainsi, dans la nature, il existe des programmes malveillants qui peuvent faire de telles choses.

La deuxième chose que fait un malware est de voler vos données personnelles. Ils peuvent essayer de voler votre numéro de téléphone ou votre liste de contacts et essayer de télécharger ces éléments sur un serveur distant. Cela peut être nécessaire pour usurper votre identité, par exemple, dans un message qui sera ensuite utilisé pour envoyer du spam.

Peut-être la pire chose que les logiciels malveillants peuvent faire, du moins pour moi, est de transformer votre téléphone en un bot.



Ceci, bien sûr, est un problème auquel nos parents n'ont pas eu à faire face. Les téléphones modernes sont si puissants qu'ils peuvent être utilisés pour envoyer du spam. Il existe de nombreux programmes malveillants destinés à certains environnements d'entreprise qui font exactement cela. Une fois dans votre téléphone, ils commencent à l'utiliser dans le cadre d'un réseau de spam.

Étudiant: s'agit-il d'un malware qui vise spécifiquement à pirater le système d'exploitation Android, ou s'agit-il simplement d'une application typique? S'il s'agit d'une application typique, peut-être pourrions-nous la sécuriser avec des autorisations?

Professeur: C'est une très bonne question. Il existe deux types de logiciels malveillants. En fin de compte, il est assez facile d'amener les utilisateurs à cliquer sur différents boutons. Je vais vous donner un exemple qui ne concerne pas tant les malwares que le comportement imprudent des gens.
Il y a un jeu populaire Angry Birds, vous allez sur l'App Store et le recherchez dans la barre de recherche d'application. Le premier des résultats de la recherche vous donnera le jeu Angry Birds original, et la deuxième ligne peut contenir l'application Angry Birdss, avec deux s à la fin. Et beaucoup de gens préféreront télécharger cette deuxième application, car elle peut coûter moins cher que la version originale. De plus, pendant l'installation, cette application écrira qu'après l'installation, vous lui permettrez de faire telle ou telle chose et vous direz: «bien sûr, pas de problème!» Parce que vous avez reçu les Angry Birds souhaités pour de simples sous. Après ce «boom» - et vous êtes accroché à un pirate!

Mais vous avez tout à fait raison lorsque vous supposez que si le modèle de sécurité Android est correct, l'installation de logiciels malveillants dépendra entièrement de la stupidité ou de la naïveté des utilisateurs qui lui donnent accès au réseau, par exemple, lorsque votre jeu «Tic Tac Toe» ne devrait pas avoir accès à réseau.

Ainsi, vous pouvez transformer votre téléphone en bot. C'est terrible pour de nombreuses raisons, non seulement parce que votre téléphone envoie du spam, mais aussi parce que vous payez peut-être pour les données de toutes ces lettres qui sont envoyées depuis votre téléphone. De plus, la batterie s'épuise rapidement, car votre téléphone est constamment occupé à envoyer du spam.

Il existe des applications qui utiliseront vos informations personnelles pour causer du tort. Ce qui est particulièrement mauvais avec ce bot, c'est qu'il peut réellement voir votre liste de contacts et envoyer du spam en votre nom à des gens qui vous connaissent. De plus, la probabilité qu'ils cliquent sur quelque chose de malveillant dans cette lettre augmente plusieurs fois.



Donc, empêcher l'extraction d'informations est une bonne chose, mais cela n'empêche pas la possibilité même de piratage. Il existe des mécanismes auxquels nous devons prêter attention en premier lieu, car ils empêchent un attaquant de capturer votre smartphone en informant les utilisateurs sur ce sur quoi ils peuvent cliquer et ne doivent en aucun cas cliquer dessus.

Ainsi, le suivi des souillures à lui seul n'est pas une solution suffisante pour éviter une situation qui menace de saisir votre téléphone.

Voyons comment fonctionne TaintDroid. Comme je l'ai mentionné, TaintDroid suivra toutes vos informations sensibles au fur et à mesure de leur propagation dans le système. Ainsi, TaintDroid fait la distinction entre ce que l'on appelle les «sources d'information» et les «puits d'informations». Les sources d'informations génèrent des données sensibles. Ce sont généralement des capteurs - GPS, accéléromètre et similaires. Cela peut être votre liste de contacts, IMEI, tout ce qui peut vous connecter, un utilisateur spécifique, avec votre vrai téléphone. Ce sont des appareils qui génèrent des informations infectées, appelées sources de données infectées - source Taint.

Dans ce cas, les récepteurs d'informations sont des endroits où les données infectées ne doivent pas fuir. Dans le cas de TaintDroid, l'absorbeur principal est le réseau. Plus tard, nous parlerons du fait que vous pouvez imaginer plus d'endroits où les informations fuient, mais le réseau occupe une place spéciale dans TaintDroid. Il peut y avoir d'autres récepteurs d'informations dans un système à usage plus général qu'un téléphone, mais TaintDroid est conçu pour empêcher les fuites sur le réseau.

TaintDroid utilise un bitvector 32 bits pour représenter une infection Taint. Cela signifie que vous ne pouvez pas avoir plus de 32 sources d'infection distinctes.



Par conséquent, chaque information confidentielle aura une unité située dans une certaine position si elle a été infectée par une source d'infection spécifique. Par exemple, il a été obtenu à partir de données GPS, d'un élément de votre liste de contacts, etc.

Fait intéressant, 32 sources d'infection ne sont en fait pas si nombreuses. La question est de savoir si ce nombre est assez grand pour ce système particulier et s'il est assez grand pour les systèmes généraux qui souffrent de fuites d'informations. Dans le cas particulier de TaintDroid, 32 sources d'infection sont un montant raisonnable, car ce problème concerne un flux d'informations limité.

Compte tenu de tous les capteurs présents dans votre téléphone, des bases de données confidentielles et similaires, 32 semble être la bonne quantité en termes de stockage de ces drapeaux infectés. Comme nous le verrons de la mise en œuvre de ce système, 32 est en fait un nombre très pratique, car il correspond à 32 bits, un entier avec lequel vous pouvez efficacement construire ces drapeaux.

Cependant, comme nous le verrons plus tard, si vous voulez donner aux programmeurs la possibilité de contrôler les fuites d'informations, c'est-à-dire spécifier leurs propres sources d'infection et leurs propres types de fuites, alors 32 bits peuvent ne pas être suffisants. Dans ce cas, envisagez d'ajouter un support d'exécution plus sophistiqué pour indiquer plus d'espace.

En gros, lorsque vous regardez comment une infection circule dans un système, dans un sens général, elle se produit de droite à gauche. Je vais donner un exemple simple. Si vous avez une sorte d'opérateur, par exemple, vous déclarez une variable entière qui est égale à la valeur de latitude de votre emplacement: Int lat = gps.getLat (), alors essentiellement la chose située à droite du signe égal génère une valeur qui a une sorte de limite avec son infection.



Ainsi, un drapeau spécifique sera défini, qui dit: "hé, cette valeur que je rends provient d'une source confidentielle"! Donc l'infection viendra d'ici, sur le côté droit, et ira ici, à gauche, pour infecter cette partie de lat. Voici à quoi cela ressemble aux yeux d'un développeur qui écrit le code source. Cependant, la machine virtuelle Dalvik utilise ce format de registre en minuscules pour créer des programmes, et c'est en fait ainsi que la sémantique est implémentée dans la réalité.

Dans le tableau de l'un des articles de la conférence, il y a une grande liste de commandes avec une description de la façon dont l'infection affecte ces types de commandes. Par exemple, vous pouvez imaginer que vous avez une opération de déplacement qui pointe vers le dst de destination et les srs source. Dans une machine virtuelle Dalvik, sur un moteur informatique abstrait, cela peut être considéré comme des registres. Comme je l'ai dit, l'infection va du côté droit vers le côté gauche, donc dans ce cas, lorsque l'interprète Dalvik exécute les instructions du côté droit, il considère l'étiquette tache du paramètre sourse et l'affecte au paramètre dst.

Supposons que nous ayons une autre instruction sous la forme d'une opération binaire-op binaire qui fait quelque chose comme l'addition. Nous avons une destination dst et deux sources: srs0 et srs1. Dans ce cas, lorsque l'interpréteur Dalvik traite cette instruction, il prend la souillure des deux sources, les combine, puis affecte cette union à la destination dst.



C'est assez simple. Le tableau montre les différents types d'instructions que vous verrez, mais en première approximation, ce sont les moyens les plus courants de propager l'infection dans le système. Regardons quelques cas particulièrement intéressants qui sont mentionnés dans l'article. Un tel cas particulier est les tableaux.

Supposons que vous ayez une commande char c qui attribue une valeur à C. En même temps, le programme déclare un tableau char upper [] qui contiendra les lettres majuscules "A", "B", "C": char upper [] = ["A "," B "," C "]

Une chose très courante dans le code est l'indexation dans un tableau comme celui-ci, en utilisant directement C, car, comme nous le savons tous, Kernigan et Ritchie apprennent que la plupart des caractères sont des entiers. Vous pouvez donc imaginer qu'il existe un code char upperC qui indique que les versions majuscules de ces caractères "A", "B", "C" correspondent aux indices spécifiques de ce tableau: char upperC = upper [C]



Cela soulève la question de savoir quelle infection devrait obtenir un C supérieur dans ce cas. Il semble que dans les cas précédents, tout était simple avec nous, mais dans ce cas, il se passe beaucoup de choses. Nous avons un tableau ["A", "B", "C"], qui peut avoir un type d'infection et nous avons ce symbole C, qui peut également avoir son propre type d'infection. 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

MIT « ». 21: « », 2


.

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

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

Dell R730xd 2 fois moins cher? Nous avons seulement 2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?