Petit point sur la sécurité des applications AIR et de leurs utilisateurs

septembre 17th, 2009

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.

Tags: , , , , , , , , , , ,
Posted in Développement (divers), Sécurité des systèmes d'information | No Comments »

Petit moment de rire.

septembre 16th, 2009

J’interrompe ma journée pour rigoler un coup. Ce matin, j’ai envoyé un commentaire sur le blog de Korben à propos d’un article qui présentait le site – aujourd’hui très connu – Securitytube. Bref, sur ce commentaire, j’ai mis mon nom et aussi l’adresse de mon site en lien et une personne est venue est s’est amusée à essayer d’injecter des quotes dans mon formulaire de mail.

J’en rigole encore car cette personne n’a pas compris semble-t-il que les formulaires de contact sont fait pour envoyer des mails et n’ont aucune interaction avec la base de donnée (à tel point que j’ai pensé que c’était un fuzzer…). Oui, il existe des failles liées aux headers mail mais pas de quoi faire ressortir des informations juteuses… Alors, quand elle a testée cette soit disant vulnérabilité… et bien cela m’a envoyé un mail #FAIL.

Bref, le meilleur du meilleur, dans tout cela, c’est que cette personne est unE employéE d’une société s’occupant de réseaux informatiques et télécoms mettant notamment en place des solutions de sécurité. Bref, la prochaine fois, demandez moi, ce sera plus facile pour me « pirater ».

Comme je disais sur Twitter : Note à I*S informatique, franchement arrêtez, c’est trop marrant… les quotes dans les champs mail ça sert à rien… par contre, les bons proxys, cela peut servir…

De plus, si vous voulez me pirater, passez par le Mutu, je pense que cela sera plus facile (n’ayant pas d’argent pour me prendre un dédié). Car, à part un pauvre Wordpress ayant deux plugins qui se battent en duel, il n’y a rien à voir.

Posted in Sécurité des systèmes d'information | 2 Comments »

Requête POST en cross-domain « presque-sans » JavaScript.

août 27th, 2009

Il y a encore quelques mois, on me disait qu’il était impossible de réaliser une requête POST automatiquement sans passer par de l’Ajax ou un Framework javascript tiers. (notez que celles en GET nécessitaient simplement un appel vers la page demandée par l’intermédiaire d’une image mal formée, un embed, ou une feuille de style etc.)

Cette histoire de POST pouvait poser quelques problèmes lors de lorsqu’un script appelait des variables en POST et que PHP était configuré sans les register_globals (donc à off). Ainsi, nous devions forcément passer par une requête POST afin de faire passer les variables, cela incluait alors, dans le cadre d’attaques CSRF l’utilisation d’ajax dans une page afin de perpétrer l’attaque et d’envoyer les données au script.

Gros problème, les navigateurs empêchent les requêtes ajax POST en cross domain pour des raisons évidentes de sécurité. Et puis, j’ai eu une idée, pourquoi ne pas passer par un formulaire HTML pur et de le valider sur un évènement ? Là était la réponse ! =) Il suffit simplement de réaliser une page contenant un formulaire et une image qui ne se charge pas contenant l’évènement (non DOM) onerror , par exemple, quelque chose dans ce genre :

<form id="form" action="[vers la page vuln aux CSRF]" method="POST">
<input name="test1" type="hidden" value="valeur test 1" />
<input name="test2" type="hidden" value="valeur test 2" />
</form>
<img src="xxxx" onerror="form.submit()" />

Et hop, vous avez votre requête POST, cross domain sans utiliser de l’Ajax =) Vous voulez voir ce que cela donne ? Allez par ici -> [ -]

Pour conclure, nous pouvons dire que le code est simple, très simple, voir même trop simple. Nous pourrions un peu le customiser afin que l’envoi des données soit invisible pour l’utilisateur, mais je reste dans le cadre d’un PoC, donc pas de choses très méchantes ici.

De plus, cette technique reste assez limitée dans l’efficacité qu’aurai pu avoir une requête à dose de javascript, car cela permet de faire autre chose bien plus élaborées… et surtout de récupérer certaines informations lorsque nous sommes sur le même domaine… (arf, le cross domaine, les navigateurs n’aiment pas cela et nous pouvons les comprendre… ah si, ie6 et < aiment ça, mais c’est une autre histoire…)

Tags: , , , , , ,
Posted in Sécurité des systèmes d'information, Tips&tricks | No Comments »

Security bugs hunter =)

août 25th, 2009

Depuis quelques semaines à raison d’une à deux heures par jour, je me suis lancé dans un petit projet histoire de me faire un peu la main avec jQuery et la programmation objet en PHP5. J’ai donc décidé, dans le cadre d’un audit (un script troué de partout dont je dévoilerai le nom dans quelques temps) de réaliser un script permettant l’indexation des failles trouvées lors d’audit d’applications WEB.

Ce script s’appelle Security Bugs Hunter et permet donc l’indexation de vulnérabilités suivant des scripts, avec la possibilité d’enregistrer le code vulnérable, le Proof of Concept de la vulnérabilité, des combos de vulnérabilités etc. Il possède par ailleurs un système de membres ayant plusieurs permissions, permettant ainsi au super administrateur de les régler suivant la confiance qu’il possède envers les abonnés.

Bref, le script aujourd’hui est beau certes, mais très pauvre en fonctionnalités (au pire, c’était juste pour me faire la main sur jQuery pour passer ensuite à autre chose…). Bref, je pense rajouter différentes petites choses telles que la possibilité d’Uploader l’application à auditer (et d’indexer ensuite par versions), de rechercher dans son code des vulnérabilités potentielles à grand coup de Regex (ce qui va ralentir un max.) et différentes choses.

Si vous voulez voir ce que cela donne, c’est par ici. Je mettrai le code source à télécharger dans quelques jours, histoire de bien le commenter et de l’alléger avec un peu de docs. (en y allant, vous gagnerez des 0dayz sur un script =)

Tags: , , , , , , , ,
Posted in Développement (divers), Sécurité des systèmes d'information | No Comments »

Jolicloud, installation sur VMware et premières impressions

août 21st, 2009

Jolicloud est un système d’exploitation orienté web basé cloud computing et réseaux sociaux, multimédia. Il est développé sur une base Ubuntu et est depuis quelques temps disponible en version Alpha (privée) permettant ainsi à diverses personnes de le tester, de déceler des bugs et de dire leur avis sur le système. Bref, le système en lui-même est sympa même si je trouve qu’il ressemble encore trop à Ubuntu sans parler de quelques défauts dans le graphisme (qui j’espère vont changer, car le menu sur fond noir est vraiment moche). Au pire ce n’est qu’une alpha donc il y a encore du temps avant sa vraie sortie donc je ne m’inquiète pas trop pour cela.

Personnellement, j’ai installé jolicloud sur une VMware permettant ainsi de faire différents tests sans réellement l’installer en dur et pouvoir ainsi facilement faire des tests réseaux, sécurité (je vous en parlerai plus tard, après que certaines découvertes soient corrigées) etc. Donc, vu que beaucoup de personnes se demandent comment l’installer sur une VMware et bien je vais vous montrer comment faire (c’est simple…). Mais le mieux est tout de même de le tester sur un netbook, afin de voir réellement la qualité de ce dernier comparé aux autres « Netbook os ».

Donc pour l’installer sur une VMware, vous créez tout d’abord une nouvelle machine avec un Linux 2.6 lambda, environ 512Mo de mémoire vive histoire que cela aille vraiment vite pendant le Boot. Après avoir créé votre machine, vous allez dans les préférences (settings) afin de changer les options de disques durs, vous supprimez l’ancien que vous avez créé. Enfin, vous en rajoutez un avec l’option « use physical disk » et sélectionnez votre clé USB, si vous ne savez pas laquelle c’est, vous avez juste à en sélectionner un puis ensuite regarder la taille du disque. Puis vous refaites un autre disque dur virtuel.

Et voilà, maintenant, vous allez pouvoir booter Jolicloud sur votre clé USB depuis VMware (mais aussi toutes les distributions Linux liveUSB).

Tags: , , , , , ,
Posted in Tips&tricks | 3 Comments »