SecFault.Org

Ce speach fait à la Black Hat USA 2008 par Rafal Wojtczuk (Invisible Things Lab) a pour but de présenter deux attaques sur l’hyperviseur Xen: une dans le code de Xen et une autre dans un domaine caché. La motivation de l’auteur est de dire que dans quelques années tout le monde aura un hyperviseur par défaut sur son ordinateur. Il n’a pas faux car, par exemple, Dell commence à fournir par défaut sur ses serveurs VMWare dans une ROM donc je peux imaginer dans quelques années que dans une puce, un hyperviseur soit disponible par défaut (il faut bien les utiliser tous ces coeurs). De plus, si il est possible d’attaquer ces hyperviseurs alors on se retrouve avec le même cas de figure qu’avec le virus Bluepill.

La première méthode d’attaque est de modifier depuis le système contenant l’hyperviseur (le Linux “maitre”) la mémoire contenant les informations à propos de Xen. Normalement un tel accés est protégé, mais en utilisant une technique similaire à celle présenté à SSTIC et permettant d’éxecuter du code via un iPod, l’auteur propose ici de s’attaquer au DMA et au carte réseau pour récupérer des valeurs en mémoire. La deuxième méthode utilise la possibilité de créer des domaines (et donc des machines virtuelles) qui peuvent espionner les autres et donc modifier leur données mémoires en temps réels.

Ces deux méthodes sont bien décrites et semblent tout à fait réalisable mais Xen n’est que peu utiliser actuellement. Des attaques de ce type sur VMWare seraient intéressante à voir également mais il n’empêche que les méthodes proposées ici utilisent  des concepts généric de la virtualisation est pourrai être utiliser sur d’autres hyperviseur.

Déjà quand on commence à parler de Cloud Computing, je ne peux m’empêcher de penser au soit disant Web 2.0, un nom totalement marketing, alors est-ce le cas ici ? Déjà, on peut en douter, la présentation de cette outil a été faite lors de USENIX Security 2008 par J. Oberheide, E. Cooke, F. Johanian de l’Université du Michigan. Leur but est de combiner une dizaine d’antivirus et deux applications de détection comportementale et de fournir l’ensemble de cette détection comme un service de type Cloud Computing. Le client n’a donc qu’à installer un petit client léger pour le service et le serveur se charge des outils de détection. D’après leurs études, il est possible d’avoir une réelle meilleur détection (35% de plus) en utilisant leur méthode. Cette méthode, ils l’ont expliqué lors de leur présentation.

Pour motiver leur travail, ils sont parti de deux faits: tout d’abord, il y a de plus en plus de virus et il devient presque impossible de tous les détecter dans le meilleur délais, mais aussi, les antivirus deviennent de plus en compliquer et deviennent des vecteurs d’attaques. Leur solution se base sur deux points forts pour éviter ces problèmes: tout d’abord, l’antivirus comme un service, où chaque machine ne fait plus tourner un antivirus mais fournit le fichier à analyser et qu’un serveur ‘dans le cloud’ se charge de l’analyser. De plus, ce serveur ne fait pas tourner une version d’un antivirus mais plusieurs antivirus et outils de détection afin d’atteindre le meilleur niveau de détection. Les quatres avantagesde leur solution sont:

• une meilleur détection
• des capacités de forensic i.e. le serveur peut garder une trace de qui a analysé tel fichiers à tel heure.
• des possibilités de savoir dès l’arrivée d’une nouvelle signature qui avait été infecté et résoudre le problème (en gardant trace des fichiers que chaque client a envoyé).
• facilitation de la mise en place et de la maintenance grâce à un service déporté dans le “cloud”.

Leur architecture se découpe en trois composants majeurs: un client léger, un service web de réception des fichiers et un service d’archive et de forensic qui garde les informations à propos des fichiers analysés. Ils ont implémenté et testé ce système pendant 1 an. Dans leur papier, ils montrent clairement les chiffres de leur étude, et même si leur système est loin d’être parfait, il apporte des idées intéressantes.

Reste à voir le problèmes de la propriété privé, en effet, les fichiers sont envoyés à une entité centrale mais aussi l’importance de l’impartialité et de la sécurite de cette structure centralisée.

Le problème de la détection et de la défense contre les DDoS est un problème aborder dans les conférences de sécurité depuis des années et malgré des solutions qui marchent plus ou moins aucune alternatives simples d’utilisation n’a jamais pu être proposé. Et pour cause, ces attaques massives sont souvent massivement distribués et donc difficile à bloquer. De plus, il ne faut pas bloquer les connexions légitimes pour permettre aux utilisateurs de continuer à accéder aux services pendant la période d’attaque. La plupart des solutions se basent sur des statistiques et un certain nombre de variables à fixer suivant le matériel des serveurs et du réseau. Ici, les 4 auteurs (J. Chou, B. Lin, S. Sen, O. Spatscheck) de l’univeristé de Californie et de AT&T proposent une solution reprenant ces principes mais permettant de limiter les dégats collatéraux (i.e. le nombre de connexion légitime qui n’aboutissent pas).

L’importance des attaques DDoS n’est plus à prouver, de nombreux cas d’attaques à plus ou moins grande échelle a déjà eu lieu avec une apogée avec l’attaque de l’Estonie mais également récemment les sites du gouvernement Géorgien. Avec des botnets de plus en plus gros (et de plus en plus simple à louer) mais également avec l’augmentation de la rapidité des connexions, il est possible de voir s’effectuer une telle attaque sur des grosses structures avec plusieurs dizaines de Gb de bande passante. Leur but est de pouvoir limiter l’impacte de tel impact en faisant une séparation en les flux de traffic et en séparant les “mauvais des bons”. Pour cela, ils utilisent un mélange de récupération de données sur le traffic, de bandes passantes répartites suivant des mesures de traffic, la mesure et le marquage de packet réseau en se basant sur la capacité d’allocution disponible et perdre des packets quand la capacité du lien réseau est dépassé.

De plus, leur méthode permet d’être totalement invisible quand il n’y a pas de DDoS et fonctionne sur le matériel qui est actuellement déployer (pas besoin d’en changer/racheter). Leur solution se base sur un algorithme (CDF-PSP) qu’ils ont développé et permet de réduire de 53% le nombre de packet perdu (soit environ 59% des flux).

Pour conclure, une présentation qui mélange aussi bien un cas pratique qui arrive tous les jours, avec des expérimentations réelles sur un grand réseau (plusieurs dizaines de Gb/s) et un bon niveau scientifique. Après leur méthode n’est applicable que par les grands ISP mais si elle est aussi efficace dans le monde réel que ce que les auteurs avancent alors cela devrait non pas résoudre mais aider à se réduire le problème des DDoS de grande ampleur.

C’est d’abord Tal Garfinkel de VMWare a DIMVA qui nous avait parlé de leur idée de créer des API pour VMWare permettant de placer l’antivirus/IDS en dehors de la machine virtuelle au niveau de l’hyperviseur, puis un renforcement de cette idée avec des détails par un autre employé de VMWare lors de la Defcon, c’est à la Black Hat USA 2008 qu’une autre société Fouteenforty Research Institute (Japan) a présenté (Junichi Murakami) leur propre Hyperviseur IPS pour les technologies de virtualisation. Le potentiel de VMWare au niveau buzz commercial et fonctionnalité de la “mort qui tue” n’est plus à prouver donc est-ce ici le cas ou non ?

L’auteur commence par montrer que maintenant, les malwares sont développées tellement dans le noyau que les antivirus/malwares/rootkits ne sont plus à un niveau supérieur à ces malwares mais au même niveau. Le combat devient donc de plus en plus compliqué voir impossible (il suffit de voir le nombre de virus étant non détecter). Après un retour assez technique sur les différentes malwares avancés sous Windows, l’auteur rappelle le fonctionnement des nouvelles techniques de virtualisation hardware comme Intel VT. Et enfin, la présentation de la solution en elle-même (uniquement Windows XP SP2 pour le moment) qui est un IPS qui tourne en dehors de l’hôte sur un hyperviseur (comme l’hôte) et qui permet de protéger le kernel mais aussi d’observer et de controller le système. Leur IPS (Viton) utilise Bitvisor, un hyperviseur Windows XP/Vista du même type que Xen et développé par une université (Tsukuba) au Japon.

Les fonctionnalités de Viton sont de pouvoir protéger et bloquer des instructions émisent par l’hôte ainsi que d’autres protections mémoires spécifiques à Windows. Mais ce qu’il ne fait pas c’est protéger les systèmes de fichiers ce qui pose bien sur un gros problème. Au final, on se retrouve avec un début d’idée, pas beaucoup de limitations réelles (mais quelques unes bien spécifiques à la manière de fonctionner actuelle des malwares) et aucune informations sur les expériences et la sur-utilisation et capacité réelle de leur solution dans un envirronement réelle.

Pour conclure, on ne peut qu’attendre de pouvoir essayer dans des cas réelles et sur des HoneyPots de tels systèmes mais également de trouver des failles et autres dans ces approches. Mais si une telle alternative à notre solution d’antivirus/HIDS se développer, c’est les grandes sociétés d’antivirus qui devront voir à moyen terme à changer leur méthode de fonctionnement. Pour le moment, cette nouvelle approche reléve plus du buzz marketing spécial BlackHat / conférence qu’une alternative réelle.

Smack qui est un système de contrôle d’accés “simple” et “simplifié” sous Linux et implémenté sous la forme d’un LSM comme SELinux est également plus léger que SELinux. Partant de ce constat et du défit au niveau sécurité que sont actuellement (et seront encore plus) les dispositifs éléctroniques, l’auteur Casey Schaufler veut montrer comment adapté Smack au monde de l’embarqué.

Je ne vais pas revenir sur ce qu’est un système MAC ou sur l’importance de l’isolation des processus les uns par rapport aux autres. Le seul petit problème de leur introduction est de dire que SELinux n’est pas adapté aux dispositifs embarqués alors qu’un papier dans la même conférence montrer le contraire mais il ne pouvait pas savoir en même temps.

Sa présentation commence par un rappel de ce qu’est Smack, de son intérêt par rapport à SELinux (plus simple, plus léger), etc ce qui n’est pas un mal vu le peu de docs disponibles pour Smack. Puis après avoir fait un rappel relativement similaire (à la présentation sur SELinux dans l’embarqué) aux problèmes qu’apporte l’embarqué, l’auteur a décidé d’orienter plus précisément son étude vers les téléphones qui est surement LE domaine à venir de Linux.

D’un point de vue sécurité, un téléphone pose de nombreux problèmes, par exemple, un utilisateur peut très bien installer un programme fait par lui ou une tierce personne. L’embarqué pose déjà des problèmes mais si en plus il est possible d’ajouter des programmes non vérifiés, la sécurité des services sur le réseau téléphonique peut ne plus être assurés (ou tout du moins pas comme les fournisseurs téléphones le voudraient i.e. par eux). Grâce à un système MAC, on peut allouer une politique spécifique à chaque application et donc limiter son accés au réseau et/ou au périphérique du téléphone (e.g. l’application de solitaire n’a pas besoin de pouvoir téléphoner).

Pour conclure, bien que Smack soit intéressant et que la sécurité dans l’embarqué soit un point essentiel de la sécurité qui risque de se développer dans les années à venir, cette présentation ne me convaint pas après la possibilité afficher par l’équipe de Fujisu de pouvoir utiliser SELinux dans l’embarqué. Leur solution fonctionne et n’est pas un bout de spécification papier, beaucoup de documentations existes déjà pour SELinux et sa qualité a déjà été testé alors que Smack est beaucoup plus jeune. Mais, c’est surement une conclusion biaisé par mon utilisation de SELinux dans mes recherches et donc mon habitude de ce dernier.

Cette présentation faite lors du Linux Symposium 2008 par deux ingénieurs de chez Hitachi Software porté sur l’importance d’augmenter la sécurité des appareils éléctroniques. En effet, de plus en plus d’entres eux sont connectés à un réseau mais ne dispose pas de réelles solutions de protection. Bien que SELinux puisse sur un PC bloqué un certain nombre d’attaque réseau, la sur-utilisation de ressource qu’il amène n’est pas compatible avec une utilisation sur un appareil éléctronique. C’est pour cela que les ingénieurs de chez Hitachi Software, Yuichi Nakamura et Yoshiki Sameshima, propose une manière de modifier SELinux pour l’adapter à ce genre de dispositifs. Premièrement, ils ont écrit un outil d’écriture de politique permettant de réduire la taille du politique. Ils ont également réduit les fonctions de SELinux pour garder uniquement le nécessaire sur un appareil éléctronique. L’ensemble du travail a été réalisé pour et su un processeur SuperH et avec le but de toujours avoir une consommation éléctrique compatible avec les utilisations de tels dispositifs éléctroniques.

Il existe un certain nombre de régles qu’il faut appliquer au CE (Appareil Electronique) qui ne sont pas valable sur un ordinateur classique. Tout d’abord, la sécurité doit marché même sans être mise à jour. De plus, il existe beaucoup de processeurs différents dans les CE (MIPS, ARM, SH, etc), il faut que le système soit compatible avec l’ensemble. Finalement, il faut que l’utilisation de  ressources soit très faible avec peu de mémoire et un processeur peut rapide. SELinux peut remplir (avec un peu de modification) l’ensemble de ces recommandations.

Mais, tout n’est pas parfait, par exemple, l’utilisation de SELinux sur un ordinateur classique amène une sur-utilisation qui est négligeable mais celle-ci ne l’est pas du tout dans le cadre d’un CE. Mais également, l’utilisation de SELinux dans le kernel amène à augmenter la taille de ce dernier de 2Mb ce qui est énorme sur des appareils disposant souvent de moins de 32Mb de ROM. Pour finir, l’utilisation de RAM par SELinux même si elle est faible, 5Mb sur un PC, est énorme pour un CE qui dispose d’uniquement 64Mb de RAM (ou moins) et qui n’a pas de swap. Il faut donc modifier SELinux pour réduire ces problèmes.

Pour réduire la taille d’utilisation de mémoire et de disque dur, les auteurs ont commencé par réduire la taille de la politique. Mais ce n’est pas si simple, en effet, la politique de référence Refpolicy est assez grosse et compliqué donc il n’est pas possible de l’utiliser dans le cadre de CE. Ils ont donc développer leur propre politique en s’aidant de SEEdit.Pour améliorer la rapidité, ils ont supprimé des fonctionnalités dans le noyau de SELinux qui ne leur sont pas utile dans le cadre d’un CE.

En faisant l’ensemble de ces modifications, ils ont été capable de porter avec succés SELinux sur des CE avec une utilisation de ressources négligeable, une taille de 200Kb, une utilisation RAM de 500Kb. En définitive, il ne leur reste plus qu’a mettre en place un support des attributs avancées (pour les labels SELinux) dans les systèmes de fichiers pour mémoire ROM (jffs2, logfs, etc) et de développer une politique stricte pour installer du SELinux sur des CE de tous les jours. C’est clairement essentielle vu le nombre de PDA, GPS, GSM, appareil divers et variés qui sont maintenant connecté au réseau sans aucune sécurité et se basant sous Linux.

James Morris de RedHat a présenté lors du Linux Symposium 2008 les avancées récentes de SELinux et il est bien placé pour en parler devant l’importance que prend RedHat dans le développement de SELinux. Après avoir rapidement rappeller ce qu’est SELinux (un système de contrôle d’accés mandataire, etc) et qu’il est supporter par de nombreuses distributions et inclut via les LSM dans le kernel Linux.

La première partie porte sur les avancées dans le support des politiques. Alors qu’au début, il existait que des politiques pour quelques services réseaux sensibles, il existent maintenant des politiques pour des centaines d’applications. L’une des premiers avancées dans le cadre des politique est la possibilité d’activer ou non une partie d’une politique en se basant sur un boolean. Cela permet de pouvoir modifier une politique sans avoir à la recharger. Par exemple, autoriser ou non l’accés aux répertoires home à un serveur FTP. Contrairement au début, où une politique monolithique décrivait l’ensemble du système, maintenant, grâce au Loadable Policy Module, il est possible de charger dynamiquement des politiques pour des applications. Il est possible donc d’avoir une politique de base puis une politique pour chaque applications et de charger les politiques d’applications quand ces dernières sont utilisées. Ils ont également facilité l’implémentation pour pouvoir utiliser de manière plus efficace le système MLS. Afin de permettre une utilité réelle du système MLS (Multi Level Security), il a été introduit un nouveau système Multi-Category Security (MCS) qui permet une utilisation de MLS par les utilisateurs finaux. Le support du schéma RBAC a également été amélioré en permettant de chargement et la définition de rôle de manière dynamique. Finalement et c’est peut être le plus important pour les utilisateurs de SELinux, la version strict (SELinux sur tout le système) et targeted (seulement SELinux sur les daemons) ont été fusionné. La version targeted est une version strict bénéficiant d’un domaine unconfined qui permet des domaines sans aucune restriction au niveau de SELinux (reste le fonctionnement du contrôle d’accés mandataire de Linux).

Dans le domaine du développement (écriture de politique), audit2allow a permis de faciliter l’ajout de régle au politique dans le cas de régles denied illégitime. Mais aussi la commande audit2why qui va permettre de comprendre d’une manière plus précise les messages d’audit. SLIDE, l’éditeur de politique, est basé sous Eclipse et permet une écriture plus simple et assisté des politiques. Mais également Policy Druid qui génére une politique a partir des réponses d’un utilisateur dans une interface graphique (peut être utiliser sans connaissance de SELinux). SEEdit est un utilitaire graphique permettant d’écrire les politiques SELinux dans un langage plus simple (il est plus orienté vers le domaine de l’embarqué). SETools est un ensemble d’outils permettant d’analyser et de créer des rapports d’audit mais aussi examiner et vérifier les politiques.

SELinux s’est également étendu au réseau avec la possibilité de labeller via SELinux des packets et de pouvoir les traiter suivant les labels. Il existe des fonction avancées réseaux permettant par exemple de labeller l’ensemble des packets sur un réseau via IPSec ou Netlabel qui permet de communiquer en se basant sur CIPSO.

Les fonctions mémoires de SELinux ont également renforcé. Une évalutation de sa sécurité a également effectué ce qui a permis d’atteindre des accréditation dans le cadre des critéres communs. Afin de toujours améliorer SELinux, de nombreuses optimisations ont été faite pour améliorer sa rapidité et son fonctionnement sur des gros systèmes.

Dans le cadre des extensions de SELinux, le support du Desktop avec un bureau graphique complet est en pleinne avancement avec des composant comme le X Access Control Extension (XACE) dans Xorg qui va permettre un support complet de X sous SELinux (XSELinux). Des composants comme Gnome et DBus sont également entrain ou sont intégrés par SELinux. Dans le cadre des bases de données, PostgreSQL via SE-PostgreSQL supportent les labels SELinux à l’intérieur d’une base de données. Mais également, dans le cadre de la virtualisation des efforts sont fait pour le support de SELinux par Xen via Xen Security Module. Il faut également parlé du partage de fichiers sur le réseau via NFS qui a vu débuter un projet depuis 2007 pour créer un standart des Labels NFS (via un document IETF, des documents de RFC sont en cours d’écriture). Pour finir sur les extensions, le support d’un SELinux like sous FreeBSD est maintenant possible via SE-BSD et SE-Darwin. Un support pour OpenSolaris (FMAC) est également en développement.

Pour conclure, cette présentation montre bien que SELinux a beaucoup progressé depuis ces dernières années et qu’il est de plus en plus utilisé et utilisable dans des cas réelles. Mais il reste encore du travail à faire pour que tout le monde puisse avoir un système MAC sur son ordinateur.

Tal Garfinkel et Dan R. K. Ports (VMWare) proposent un système de machine virtuelle pour analyser le comportement complet d’un système et en détecter les parties potentiellement dangereuse. Le but est de clairement accés leur approche vers les systèmes d’exploitation qui sont utiliser pour stocker et analyser des données très sensibles comme les données banquaires ou médicales.

Certaines approches pour sécuriser de telles systèmes est de partitionner le système pour isoler les processus. D’autres proposent de faire tourner un système qui isole bien une partie ou la totalité d’un processus mais qui permet toujours une intéraction directe avec le système. Overshadow, leur prototype, a pour but d’isoler une application et ses données et de garder ces données et processus isoler même en cas de compromision du système hôte.

Overshadow fonctionne en modifiant l’outil de monitoring des machines virtuelles. En effet, si le système hôte essaye d’accéder à un espace mémoire appartenant à une application isolée alors la mémoire est encrypté et un hash est créé pour vérifier son intégrité. Le système ne pourra donc n’y lire n’y modifer la mémoire mais pourra la manipuler (pour la mettre en swap par exemple). Pour permettre cela, une application protégé (dans un shim) communique directement avec le moniteur de machine virtuelle (VMM) via des hyper appels systèmes protégés.  Ils peuvent garantir l’isolement et l’intégrité mais pas la disponibilité car l’OS corrompu pourrait tout simplement refuser d’éxecuter le programme mais au moins aucune donnée aura été corrompu ou modifié.

Pour ce qui est des données non mémoire, comme les systèmes de fichiers, Overshadow utilise le même système que pour les données mémoires (encryption et hashage). Pour les méta-données, ils sont obligées de changer le système de gestion de méta données pour empêcher la fuite de méta-données comme les noms des fichiers. Pour cela, ils utilisent VPFS qui est un système permettant de fournir de manière sécurisé ces méta-données. Pour ce qui est des IPC (Inter Process Communication), leur système ne fonctionne pas en temps réel mais peut détecter des fuites. Ils utilisent également des fonctions permettant de détourner fork et thread_create pour y ajouter la gestion de la mémoire cryptée et empêcher des fuites entre processus. De plus, ils ont instaurer une horloge sécurisée pour éviter tout problème de temps.

Les auteurs ont aussi pensé à des options comme les répertoires sûr (Trusted Path) afin d’éviter toute modifications d’éxecutable précis (par exemple, /bin). Bien entendu, il ne faut pas qu’une application sécurisé s’appuye sur un composant système pour un processus comme l’identification sinon l’isolation ne pourra en rien régler le problème.

Pour conclure, leur système est très intéressant même si très spécifique à certaines applications où une certaine sur-utilisation est tout à fait acceptable. Même si cette solution est loin d’être parfaite, elle permet d’ajouter un niveau de sécurité qui ne serait clairement pas négligeable quand on voit la quantité de données personnelles disponible sur Internet. Mais ce système n’est pas parfait, il ne protége pas, par exemple, des failles dans l’application elle-même. Il serait très intéressant de pouvoir tester un tel système mais il semble que ce soit un prototype interne à VMWare.

Matt Miller de Leviathan Security Group a présenté lors de la USENIX Security 2008, une méthode d’intrumentation dynamique permettant de génerer des traces pouvant identifier les flux de données et trouver des chemins potentielles non voulu. Le but est donc de générer l’ensemble des intéractions possibles entre les applications et les ressources du système afin de trouver des chemins non voulu.

Pour pouvoir commencer l’analyse, il faut avoir l’ensemble des droits associés à tous les objets du système. Mais il faut également avoir une vue exacte de l’ensemble du système et des droits à chaque moment, il faut donc une double approche de récolte de ces droits pour avoir une vue réelle à chaque décision. Cette double approche est de combiner une approche statique pour les objets persistants et une approche dynamique pour les objets dynamique. En détournant un certain nombre d’appels systèmes, ils sont capable de récupérer les données nécessaires pour leur approche.

Ensuite via l’ensemble des traces récupérer, les auteurs recherchent des chemins et des séquences pouvant amener à des rupture de propriété de sécurité comme des flux de données ou des élévations de privilége. Pour le moment, il n’y a pas encore d’autres propriétés de sécurité supporter mais il travaille dessus.

Malheuresement, ce HIDS sous Windows se base sur un système de contrôle d’accés discrétionnaire et donc le graphe représentant l’ensemble du système est susceptible de souvent changer et d’être influencer par les utilisateurs. La construction du graphe en temps réel est presque impossible comme cela l’a été prouvé sous Linux.

C’est un papier très intéressant et une première implémentation d’un HIDS politique disposant de respect de propriété de sécurité sous Windows mais il reste encore beaucoup de chemins et de recherche avant de voir un prototype fonctionnel sur un système complet, du moins je le crains.