La semaine dernière avait lieu à Barcelone, le BlackHat Europe 2011 qui est un évènement assez connu dans le monde de la sécurité informatique. J’ai eu la chance de pouvoir y participer et ce premier billet contient mon compte rendu de l’évènement.

Keynote : Bruce Schneier – Cyberwar

Cette année, c’était Bruce Schneier qui présentait la conférence plénière de ce BlackHat Europe. Pour ceux qui ne connaissent pas encore Bruce, c’est un grand monsieur spécialiste mondial en terme de cryptographie et de sécurité informatique, auteur de plusieurs ouvrages tels que Secrets & lies, Applied Cryptography ou encore Beyond Fear

Bref c’est une star dans le petit monde de la sécurité :-)

Le sujet de cette plénière était la guerre dans le cyberespace (cyberwar) :

“The world is gearing up for cyberwar. The US Cyber Command became operational in November. Nato has enshrined cyber security among its new strategic priorities. The head of Britain's armed forces said recently that boosting cyber capability is now a huge priority for the UK. And we know China is already engaged in broad cyber espionage attacks against the west. So how can we control a burgeoning cyber arms race? We may already have seen early versions of cyberwars in Estonia and Georgia, possibly perpetrated by Russia. It's hard to know for certain, not only because such attacks are often impossible to trace, but because we have no clear definitions of what a cyberwar actually is. Do the 2007 attacks against Estonia, traced to a young Russian man living in Tallinn and no one else, count? What about a virus from an unknown origin, possibly targeted at an Iranian nuclear complex? Or espionage from within China, but not specifically directed by its government? To such questions one must add even more basic issues, like when a cyberwar is understood to have begun, and how it ends.”

Un sujet vraiment passionnant et appuyé de nombreux exemples rendant cette présentation (sans slides) super intéressante. La bonne nouvelle c’est que la vidéo est accessible en ligne sur le site de l’évènement à l’adresse suivante : https://media.blackhat.com/bh-eu-11/Schneier-Keynote/BlackHat-EU-2011-Keynote-Schneier.m4v , je vous encourage à la regarder :-)

Durant l’évènement, 3 tracks avaient lieu en parallèle (2 salles réservées pour les présentations, la troisième à des ateliers plus pratiques).

Parmi les sessions auxquelle j’ai assistées et sur lesquelles j’ai pris quelques notes (retranscrites tant bien que mal :-) et enrichies avec des liens pour creuser un peu le sujet), En voici deux (un prochain billet, comprendra les notes prises dans d’autres sessions)

New age attack against apple’s IOS (and countermeasures) par Nitesh Dhanjani

Petit rappel en début de session sur Social Media, Cloud Computing et mobile

iOS et les protocol Handlers.

Petit rappel sur la gestion des protocoles (Protocol Handlers) = appel depuis le navigateur d’un autre protocole que HTTP et ouverture de l’application associée

Ex d’URLScheme :

  • maps: —> démarre Google Map
  • sms: —> démarre application SMS
  • twitter: —> démarre Twitter
  • mailto: —> démarre Mail

Exemple de Safari sur Mac OS X où aucune demande de permission n’est faite auprès de l’utilisateur ==> Demander à l’utilisateur son accord est (serait) une bonne idée. D’après le speaker, seule l’application Kindle a un traitement différent en terme de protocol Handler (kindle://)

Le speaker indique que des sites malveillants (ou compromis) peuvent par exemple forcer un appel Skype (avec skype:// dans une iframe par exemple).

Skype est désormais inclus dans BeEF (Browser Exploitation Framework)

Vidéo de démonstration :

Le speaker indique l’historique de sa découverte du problème avec Skype et Safari sur iOS depuis son premier contact auprès d’Apple (le 19 octobre 2010), puis la prise de contact avec les équipes de Skype, puis l’annonce par Apple le 8 février 2011 d’une mise à jour prochaine d’iOS (4.3?) permettant un meilleur contact de l’utilisation des protocol handlers.

Question ouvertes par le speaker sur le sujet :

Est ce qu’une liste des URLSchemes exposés devrait être exposé aux utilisateurs avancés ou administrateur ?

Est-ce que l’interface de Safari avec les Applications devrait proposer une demande d’autorisation à l’utilisateur avant d’emmener l’utilisateur dans l’application ?

De nombreuses URLScheme non documentés sont utilisées / présentes dans de nombreuses applications (ex: Facebook.app) qui du coup ne sont accessible que via reverse engineering de l’application iPhone/iPad

Informations complénmentaires : Reverse Engineering iPhone AppStore Binaries
http://dvlabs.tippingpoint.com/blog/2009/03/06/reverse-engineering-iphone-appstore-binaries

Le speaker a ensuite donné des conseils pour gérer de manière plus sécurisée les URLSchemes notamment : faire attention à une attaque par Ricochet dans laquelle un site Web externe peut abuser d’une application intermédiaire

Exemple : <iframe src=”some_other_app://you://boom”>

UI Spoofing on the iPhone

L’idée ici est de faire apparaitre une interface se faisant passer pour la barre d’adresse de Safari (qui elle disparait automatiquement) afin de tromper l’utilisateur. On est donc ici dans une configuration idéale pour une attaque de type phishing. Ce type d’attaque pourrait être intégrer dans les phishing kit simplement en détectant le user-agent de Safari sur iOS.

Intercepting HTTP(s) trafic

Un exemple marrant d’interception et de modification des données échangées : le projet “Upside Down Ternet) : http://www.ex-parrot.com/pete/upside-down-ternet.html qui est un proxy interceptant les flux HTTP et qui retourne les images avant de les envoyer au navigateur :-)

L’utilisation d’un proxy HTTP (faisant aussi de l’inspection SSL via du MTIM) tel que Burp de PortSwigger peut causer des messages d’avertissement en cas de non correspondance entre le common name du certificat et le nom de domaine accédé (normal). Si c’est votre proxy (que vous utilisez pour analyser les communications), pensez à installer le certificat de la CA dans l’iPhone/iPad.

Ainsi avec ce type de proxy interceptant le HTTP et HTTPS (c’est également possible avec des produits tels que Microsoft Forefront TMG 2010), il est possible d’analyser un peu les informations transmises par les applications installées sur le smartphone / la tablette d’Apple.

Le speaker a ensuite donné des exemples de fuite d’informations dans des applications (Pandora qui transmet l’age de l’utilisateur à doubleclick, OpenTable qui envoie l’age, le code postal, la localisation à des tierces parties)

Ensuite le speaker a abordé l’idée de Man In The Middle pour intercepter et révéler des informations provenant des réseaux sociaux (Facebook en exemple). Sans aller jusqu’au Man in The Middle, des applications tels que FireSheep (extension à Firefox) permettent déjà ce genre d’opération sur les flux en clair, le MiTM étant l’évolution pour les communications chiffrées avec ces réseaux sociaux

D’où les recommandations du speaker :

  • Utiliser SSL
  • Auditer vos applications et applications tierces
  • Essayer de ne pas transmettre des données à des services tiers (régies, services Analytics)

Bref du classique mais il est bon de rappeler régulièrement les basiques ;-)

Autres points sur lesquel faire attention

Ne pas envoyer d’informations confidentielles (ex: données sensibles de son entreprise) via les notifications Push des Applications.

Savoir que lorsqu’un utilisateur appuie sur le bouton de l’iPhone/iPad pour sortir de l’application, l’animation de fermeture utilise une capture d’écran et le fichier image associé peut contenir des informations sensibles. Et ce fichier n’est pas protégé.

Note finale sur cette session : en cherchant quelques informations complémentaires, je suis tombé sur quasiment les mêmes slides que ceux jouées lors du BlackHat Europe 2011, mais provenant du SANS APPSEC SUMMIT 2011. Donc cela complète plutôt bien mes notes (ou l’inverse ;-))

Hacking and Securing Next Generation iPhone and iPad Apps
http://software-security.sans.org/downloads/appsec-2011-files/dhanjani-hacking-securing-next-gen.pdf

 

Escaping from Microsoft Windows Sandboxes par Tom Keetch (twitter : tkeetch)

“an assesment of Internet Explorer, Adobe Reader and Google Chrome”

Le sujet de cette session était d’expliquer les mécanismes de Sandboxing ainsi que la manière de s’en échapper (ou plutôt les axes de recherches pour trouver des exploits permettant de s’en échapper).

Sandboxes ont pour objectif de limiter l’impact d’exploit sur les applications (limiter est ici le mot important, on est tous d’accord qu’aucun mécanisme n’apporte une sécurité absolue)

2 intérêt aux mécanismes de Sanboxing:

  • Augmenter le coût de l’exploitation
  • Baisser la valeur de la cible

D’où l’idée de rechercher des exploit “peu couteux” pour les chercheurs en sécurité.

La session a débuté sur une explication des mécanismes utilisés dans les différentes solutions de sandboxing

The practical Sandboxing Methodology :

  • Restricted Access Token
  • Deny-only SID (discretionary)
  • Low Integrity (Mandatory)
  • Privilege Stripping (Capability) : enables a service to run with least privilege
  • Job object restrictions
  • Windows Station Isolation
  • Desktop Isolation

Informations complémentaires  

Puis le speaker a pris différents produits (IE, Adobe X Reader et Chromium) pour détailler les différentes implémentation de sandboxes

Le mode protégé d’Internet Explorer

Limitations

  • Disponible uniquement sur Windows Vista et Windows 7
  • Protège uniquement l’intégrité du système et non la confidentialité
  • N’implémente pas toutes les méthodes de sandboxing (Restricted Token, Windows or Desktop Isolation)
  • Accès complet aux ressources Windows Station (Clipboard…)

sandboxe escape route :

  • UAC launch
  • Trusted Broker attach
  • Generic PMIE (Protected Mode Internet Explorer)

Informations complémentaires :

Adobe X Reader

Make use of Chromium sandboxing and IPC Framework (BSD Licence)

Le rendu du PDF est sandboxé mais il demeure encore des faiblesses (accès au Clipboard…).

Limitations:

  • Implémentation partielle des Jobs Objects Restrictions
  • N’implémente pas toutes les méthodes de sandboxing (pas de Windows ou de Desktop Isolation)
  • Ne protège pas l’accès au Clipboard

Les documents suivants détaillent bien ce sandboxing :

Chromium

Applique toutes les bonnes méthodologies de Sandboxing. Apparait plus sécurisé comme sandboxing mais aussi beaucoup plus compliqué

Les plug-ins / extensions tierces parties ne sont pas sandboxés (à l’exception de Flash dans les dernières versions de Chromium)

GPU process n’est pas sandboxé dans Chrome (c’est planifié pour une future version)

Informations complémentaires :

Cheap Exploit Vector #1  (fonctionne pour tous)

BNO Namespace squatting

Réponse du MSRC (MS) : sera fixé dans IE9 ou version ultérieure (Gloups). Une des raisons évoquées par le MSRC étant que le mode protégé ne doit pas être vu comme une frontière de sécurité.

 Cheap Exploit Vector #2 (spécifique à Chromium)

NPAPI Interface Exploit

NPAPI est une API conçue à l’origine pour interfacer le navigateur avec des plug-ins. Dans cette communication navigation / plug-in, les deux parties s’approuvent mutuellement. Dans les faits : si on trouve un bug dans un plug-in (ce qui est fort probable vu la quantité de plug-in), il devrait être possible d’utiliser NPAPI pour s’échapper de la Sandbox.

A noter : d’après les informations sur le site de Google, les plug-ins utilisant NPAPI nécessiteraient une revue manuelle (humaine) avant d’être acceptées dans le Chrome Web Store ou la gallerie d’extension. Vu le nombre d’extensions existant, je doute qu’il y ait chez Google une armée de développeurs spécialisé dans la revue de code sécurisé (mais ce n’est que mon opinion ;-))

Informations complémentaires :

 Cheap Exploit Vector #3

Handle Leaks

ex: Adobe Reader X Handle Leaks

 Cheap Exploit Vector #4

Clipboard attack : dans le mode protégé d’IE ou dans Acrobat Reader X, le clipboard est partagé entre la sandbox et le reste de la session utilisateur. Il est donc possible de lire du contenu dans ce clipboard mais aussi d’y mettre du contenu malveillant et de faire consommer ce contenu par une application qui fait confiance au Clipboard.

Conclusion de cette session : 

Les mécanismes de bac à sable (sandbox) permettent déjà aujourd’hui de limiter le risque en rendant les exploits plus difficiles (à trouver et/ou à exécuter). Ces mécanismes vont continuer leur évolution car en parallèle, les hackers continuent à chercher et inventer de nouvelles façon de s’échapper de ces sandboxes.

Un autre compte-rendu de cette session qui devrait compléter mes notes (que je sais incomplètes car ce n’est pas facile de suivre le speaker et aussi de prendre des notes :-)) : http://www.corelan.be/index.php/2011/03/17/blackhat-europe-2011-day-01/ 

 Voilà c’est la fin de ce premier billet de compte-rendu du Black Hat 2011. D’autres devraient suivre prochainement :-)

Stanislas Quastana