WEBlog de Félix Aimé

AIR, c’est cool. La phrase est lancée et depuis que le jour s’est levé sur le SDK d’Adobe, beaucoup de personnes se sont mises à faire leurs petits widgets personnels et autres RIA liées avec différentes API web mises à disposition par des réseaux sociaux. Cependant, la sécurité des applications AIR est encore mise de côté par une partie des développeurs, ayant pour la majeure partie aucune véritable base dans le développement d’RIA sécurisées.

Il m’arrive parfois, entre deux pages Internet de télécharger une application AIR – développée en amateur ou par une firme – afin de tester la sécurité de cette dernière se divisant en trois axes majeurs à mes yeux :

• La sécurité client (sécurité du poste de travail)
• La sécurité utilisateur (sécurité des données utilisateurs)
• La sécurité serveur (sécurité du serveur auquel est rattaché l’application)

De ces trois côtés, le constat de mes audits furtifs est lourd de conséquences, faisons donc un petit tour au pays de la sécurité des applications air et des possibilités qu’offrent ces dernières en vecteur d’intrusion.

0×01 Sécurité Client :

Le premier problème du côté client résulte dans la capacité pour une application AIR de manipuler des fichiers présent sur le disque dur, de les enregistrer, de les envoyer à travers le web, et ce, avec quelques lignes de code (une vingtaine tout au plus) et sans n’avoir aucune réelle expérience de la part du développeur.

Imaginez le problème si une personne utilise des programmes présentant des fichiers de connexions contenant des logins et mots de passes en clair (tels que FireFox – n’ayant pas la fonction « mot de passe principal d’activé », FileZilla avec son fichier star filezilla.xml ou même des fichiers de Cookies) et bien, une trappe réalisée dans une application AIR légitime pourrait envoyer le contenu de ces fichiers vers une base de donnée distante permettant ainsi au développeur de réaliser au fil du temps un petit trésor de guerre.

Évidemment, Adobe a tout prévu et avertit l’utilisateur pendant l’installation de l’application que cette dernière peut accéder à des données sur son ordinateur. Cependant, connaissant les utilisateurs et me connaissant moi-même (si-si, j’vous jure), il est assez rare pour un utilisateur de refuser l’installation d’une application venant d’être téléchargée sachant qu’elle peut accéder à des fichiers présents sur notre disque dur afin de réaliser certaines opérations. (Il est aussi assez rare de regarder l’intégralité des messages pendant une installation…)

Voyant de plus le nombre d’applications utilisées possédant ces messages à l’installation, il est sûr que l’extrême majorité des utilisateurs ne les regardent pas avant d’installer la moindre application AIR. J’ai pu vérifier cela simplement en recherchant un « top 50 » des applications AIR et en les testant une par une afin de savoir si lors de l’installation, il y avait le fameux message (et aussi un autre message avertissant que cette application n’était pas certifiée.)

Il ressort de cette mini-étude que pas moins de 20% des applications présentent les deux messages d’erreurs cités plus haut. Parmi lesquelles, des applications largement utilisées telles que TweetDeck, Spaz ou même Twhirl. Voici la liste complète :

1. Doomi (doominow.com)
2. Klok (http://klok.mcgraphix.com/klok/downloads.html)
3. TimeLoc (www.rad3.com/timeloc/default.html)
4. AirTube (theflashblog.com/?p=363)
5. RandomWin
6. twhirl (http://www.twhirl.com)
7. Spaz (http://funkatron.com/spaz)
8. TweetDeck (tweetdeck.com)
9. DiggTop (http://gskinner.com/DiggTop/)
10. Snackr (http://snackr.net)
11. ReadAir (http://code.google.com/p/readair/)
12. WebKut (http://toki-woki.net/p/WebKut/)

Une autre vulnérabilité que je n’ai pas vérifié mais qui est plus que probable (n’ayant pas trouvé de dossier traitant de cela sur le site d’adobe) est la possibilité pour une application AIR de télécharger un binaire sur un serveur distant et ensuite de l’exécuter. Cependant, comme je l’ai dit plus haut, je n’ai fait aucune tentative sur le chargement du binaire.

Pour son exécution, AIR a appliqué certaines restrictions liées à cela mais des recherches et logiciels ont abouti à la possibilité d’exécution de binaires. Vous pouvez trouver plus d’informations sur ce topic de MediaBox. Mais aussi sur ce billet parlant notamment de programme SHU.

0×02 Sécurité Utilisateur :

Ce qui est le plus criant côté client, c’est qu’une grande partie des développeurs stockent dans des fichiers des informations sensibles sans aucun chiffrement ou même hashage de ces dernières. Ainsi, il n’est pas rare de voir ce genre de problème pour des RIA utilisant les API de certains réseaux sociaux. Nous nous retrouvons ainsi avec des bases SQLite, des fichiers XML ou d’autres types de fichiers possédant des informations en connexion à des services tiers en clair.

Pour ceux qui ne savent pas, petit rappel. Adobe à implémenté un « système de chiffrement » stockant des données chiffrées en AES-CBC 128-bit grâce aux différentes API de chiffrement liées aux systèmes d’exploitation (DPAPI pour windows, Keychain pour Mac). Cette solution, utilisée par différentes applications (notamment certains clients Twitters).

Bref, vous avez une description de cette protection à mettre en place sur la documentation officielle d’AIR élaborée par Abobe [DOC_ADOBE]. De plus, un petit tutoriel simple, mettant en place un couple login/passwd et une fonction « remember this » est également présent sur le site d’Adobe [TUTO_ADOBE] afin de mettre en place cette solution (avec les sources à télécharger). Les fichiers chiffrés sont disponibles (par exemple) sur Windows dans le répertoire ELS (Encrypted Local Store) siégeant fièrement dans le dossier AppData : \Adobe\AIR\ELS\[dossier de l'application]

(UPDATE : Un très bon diapo est dispo [ICI] =)

0×03 Sécurité serveur :

Ensuite, nous pouvons voir d’importantes vulnérabilités côté serveur pour certaines applications utilisant AIR. Il n’est pas rare, là aussi d’entrevoir des possibilités d’SQL injection dans le SGBD distant de l’application, car certains développeurs ne vérifient pas les données envoyées à partir du serveur mais à partir de l’application. (Des fois, ils ne les vérifient pas du tout…), je n’ai pas testé des Xpath injections mais il est fortement probable que cela puisse fonctionner là aussi (tout du moins au point de vue théorique.)

La vulnérabilité XSS de David Naylor – même si mon petit doigt me dit que certaines personnes l’avaient déjà :) – sur le service Twitter est aussi imputable à une mauvaise vérification de chaine de caractère envoyée à l’API de Twitter pour le nom de l’application. Il ne pas oublier de filtrer les données entrantes dans les bases de données distantes contre les injections de code exécutables en client-side – et non lors de leur récupération par un frontend, car le frontend peut, lui, être mis à jour laissant ainsi exécuter certains codes contenus dans la base de donnée. C’est la célèbre phrase : « Upgrade : to take out old bugs and put in new ones ».

Twitter n’avait pas pensé à filtrer l’intégralité des données envoyées par l’intermédiaire de l’API… ce qui se traduisit donc par un énième EPICFAIL

0×04 Conclusion :

L’internaute est toujours avide de nouveaux gadgets pouvant ouvrir certaines vulnérabilités sur le système sans même se préoccuper de certains messages d’alerte lors de l’installation des applications AIR. Ceci, comme nous avons pu le voir, pouvant laisser une certaine porte d’entrée à des informations contenues sur l’ordinateur. De plus, des recherches sont faites actuellement sur la possibilité d’exécution de binaires en AIR et j’ai une petite idée derrière la tête à ce propos.

Les développeurs de leurs côtés, laissent certaines vulnérabilités en client-side (mots de passes en clair) ou en server-side (failles web connues et re-connues) pouvant ainsi ouvrir certaines brèches, tant pour l’utilisateur (piratages de comptes) que pour le backend de l’application RIA (sans parler du site internet auquel souvent cette dernière est rattachée en vue de son téléchargement).

Les RIA sont aujourd’hui en plein développement. Beaucoup de développeurs, du fait de la facilité à mettre en œuvre ces solutions réalisent souvent sans se préoccuper de la sécurité des ces petits widgets à l’apparence inoffensifs. Il est aujourd’hui préoccupant pour les utilisateurs de prendre conscience que n’importe quelle application/widget, quelque soit sa renommée peut être un danger pour l’intégrité de ses données s’il ne fait pas attention et n’analyse pas en détails le fonctionnement de cette dernière.