De w3af (mon préféré…) à Skipfish en passant par Wapiti, le petit français : les fuzzers deviennent de plus en plus évolués pour déceler une très large variété de vulnérabilités ou d’information disclosures. Cependant, les applications web sont, comme toutes applications, systémiques. De ce fait, dans une grande majorité des cas, des conditions doivent souvent être remplies afin d’accéder à certaines vulnérabilités. Ces conditions (authentifications, patterns à respecter etc.), souvent additionnelles entre elles sont très largement omises par les fuzzers, ne lisant pas, sauf dans le cadre de certains PoCs, les informations contenues dans la page (tels que les names/types des champs inputs pouvant donner pas mal d’information sur la nature des données attendues en POST/GET). Ceci aboutissant le plus généralement à de faux négatifs et donc au passage à la trappe d’un très grand nombre de vulnérabilités potentielles.

Le nombre de requêtes vers une application ciblée durant une phrase de fuzzing est aussi à ne pas négliger. Ainsi, elles se comptent en dizaines de milliers, voir, centaines de milliers pour le petit dernier Skipfish laissant une trace plus que repérable dans les logs pouvant par la suite être interprétée par un IDS/IPS.

En parlant de dispositifs ajoutés un serveur web lambda nous pouvons de plus mentionner les WAF. Ces derniers ne permettront pas de déceler une vulnérabilité même si elle est présente dernière le reverse proxy et exploitable (par exemple en utilisant des attaques du type HPP, HPF ou même plus inhérentes aux services SGBD ; voir cette très bonne présentation pour plus de détails). Ce, pour la simple et bonne raison que les fuzzers sont développés pour déceler les vulnérabilités et non bypasser certaines protections tierces protégeant l’accès à ces vulnérabilités.

Bref, les tests d’intrusions sur les applications web en front-end avec un simple navigateur et quelques plugins ont encore de beaux jours devant eux, rien ne remplacera l’expérience de l’auditeur dans son travail tant dans l’analyse du code que dans une attaque en font-end. Cependant, fuzzer une application peut s’avérer utile en appoint, notamment en local.

Pour information, j’ai passé sur w3af et sur Skipfish le script php calendar avant de réaliser cet article. Voici ce qu’ils ont découverts :

[-] Skipfish :

Il a simplement découvert l’injection SQL et une XSS dans le formulaire d’authentification de la zone d’admin (et le dossier de la zone d’admin). Aucune SQL injection dans l’index de l’application ni même l’include locale présente aussi dans l’index de l’application.

[-] w3af :

Il découvre le full path disclosure lorsque la valeur de la variable lang passée en GET n’est pas celle attendue. Il découvre aussi la LFI et une XSS (que je n’avais pas vu, présente grâce à l’erreur de retour en cas de non inclusion du fichier) mais aucune SQL injection dans l’index là aussi. Il ne découvre pas la zone d’administration, donc pas d’SQL injection ou de XSS dans le formulaire d’authentification de cette dernière.

Je ferai peut-être, un audit plus complet, avec de vraies statistiques pour comparer les fuzzers avec un audit fait à la main.

PS : Merci à @wadael pour me pousser à faire des articles =)

Premièrement, j’ai un stage ! Il se fera à CEIS sur Paris pendant six mois de mi-avril à fin septembre. En gros, je suis très content d’avoir ce stage, car les missions correspondent à ce que je cherchais dans le domaine de la sécurité des systèmes d’information. Je veux remercier Nicolas Caproni (@cyber_risks) pour m’avoir éclairé sur cette offre – il sera d’ailleurs responsable de moi pendant ce stage où je ne doute pas d’apprendre un paquet de choses tout au long de ce dernier.

De plus, je voulais remercier ceux qui m’ont fait part d’offres de stages même si je les ai toutes déclinées – certaines sont arrivées récemment – car j’avais déjà mon stage à CEIS. Cependant, je vous en suis reconnaissant, cela fait toujours du bien de voir que des personnes s’intéressent à ce que l’on fait. Merci merci merci ! Il ne me manque plus qu’à enlever cette recherche de stage de mon site (grand moment d’émotion en perspective :)

En second point, je suis encore sur cet article (sorte de bilan) lié à un audit sauvage (je sais, c’est mal) que j’ai fait sur des portails web de médias français. Pourquoi ? Eh bien car je dois contacter les administrateurs, webmasters, DSI etc. pour boucher les failles qui sont bien nombreuses (et pour certaines très grosses). Cependant, ne vous attendez pas à un scoop avec les noms des médias, par respect pour leur travail, je ne divulguerait aucun nom, seule la méthodologie sera présentée. Toujours est-il qu’ils sont nombreux, et la plupart d’envergure nationale si ce n’est internationale pour certains.

Récemment, j’ai mis à jour quelques scripts sur Security Bugs Hunter au programme, des vulnérabilités que j’avais trouvées fin 2009, d’autres datant d’hier sur un simple « calendrier » dont Smashing Magazine faisait la PUB hier sur Twitter (beau #FAIL à la vue nombre de followers liés à ce compte). J’en ai encore beaucoup dans ma hotte, cependant, je ne possède pas tellement le temps de faire le tour complet de certains scripts donc je préfère attendre avant de les publier.

Pour finir, je suis en train de bosser sur la certification CISSP non pas pour la passer – si je me souviens bien, il faut avoir un minimum de cinq années d’expérience pro. en SSI et pas mal d’argent pour un indépendant – mais seulement pour apprendre de nouvelles choses dans la domaine de la sécurité. Je lis en ce moment CISSP All in one Exam guide qui possède tout le contenu lié à cette certification avec comme dans chaque livre de geek qui se respecte quelques petites blagues dans certains coins. Reste que ce petit monde de la sécurité évolue si vite que certaines notes sont déjà dépassées… mais bon, l’extrême majorité de la méthodologie, des descriptions et des sujets traités sont bons à prendre (et très bien traités !). Bref, un bouquin à avoir chez soi qui sera très bien entre Security Power Tools et Network securty hacks. L’édition poche n’existe pas, malheureusement.

Promis, je publie l’article dans quelques jours.

Et un binaire a attiré mon attention du fait de sa finition et des possibilités offertes par ce dernier dans l’analyse de flux réseaux qu’ils soient sauvegardés en pcap ou en live. Bref, son nom, NetworkMiner est un NFAT (Network Forensic Analysis Tool – à force d’avoir des acronymes partout, on en perd vite la signification) disponible depuis bien longtemps, mais pas très connu (m’enfin, je ne le connaissais pas faisant toujours l’analyse de paquets à l’aide de Wireshark).

Il permet de faire plusieurs choses intéressantes et d’accélérer ainsi le travail lorsqu’il faut se parser un flux réseau de milliers de paquets. Entre autre il permet d’avoir une vue globale des différentes stations (avec un embryon d’OS fingerprinting), équipements réseaux pro-actifs et serveurs externes sollicités durant la session de capture. De plus, il permet la récupération de fichiers transitant sur le réseau, d’images, de mots de passes, de query DNS etc.

Bref, il peut venir en compléments d’utilitaires incontournables comme Wireshark dans l’analyse de flux. De plus, ce dernier trouve tout son intérêt lorsqu’on sait qu’Meterpreter permet depuis quelques mois de récupérer facilement des flux réseaux à distance lors de pentests, sans parler de l’incontournable TCPdump, toujours utile lorsqu’on a un shell sur une box distante.

Seul problème pour les linuxiens, ce tool est disponible que sur Windows. Après, tout le monde possède un petit virtual box ayant Windows dessus. Un seul lien pour l’essayer et surtout l’adopter : NetworkMiner.

Tout d’abord, je passe la majorité de mon « temps libre » sur mes études, qui sont certes, intéressantes, mais prennent beaucoup d’heures suite à différents projets. D’ailleurs, mon principal projet cette année est de refaire le site d’SRC Bordeaux, le site de mon IUT. Au programme, (re)définition du design, de la stratégie SEO/SMO, développement de plugins wordpress propres au site internet etc.

A ce jour, je ne peux pas vous montrer ce que l’on a fait, car les maquettes, zonings, stratégies etc. n’ont pas été validés par une partie du corps enseignant. Au pire, nous devons mettre une première version du site en ligne la semaine prochaine donc keep update.

Ensuite, cette semaine, toujours à SRC a lieu un « évènement » (au niveau de l’IUT, tout est relatif) permettant aux étudiants de réaliser des sites internet pour des associations de Blanquefort. Bref, bonne semaine en perspective – j’apprécie les rencontres et le partage de connaissances. Cependant, le CMS utilisé est Joomla. Pour ceux ne connaissant pas Joomla, c’est le seul CMS où essayer de comprendre son fonctionnement prend plus de temps que de re-coder le corps à sa guise. Là aussi, keep update, le site internet que je réalise avec deux autres étudiants sera en ligne samedi vers 15h.

Point de vue recherches et épanouissement personnel, je suis en train de rédiger un papier sur les stratégies d’attaques et de défense des systèmes d’information. Intitulé « Tactiques, stratégies et guérillas informationnelles », il reprend les grands principes de la stratégie terrestre et grands courants de pensée stratégiques afin de les calquer dans un concept d’info-guerre tout en ayant une certaine abstraction technologique quand cela est possible. Ce papier est à l’heure actuelle à ses balbutiements, mais avance bien selon le temps dont je dispose pour me documenter et l’écrire (quelques heures par semaine, tout au plus).

D’ailleurs, pour ceux qui s’intéressent – tout comme moi – à la stratégie terrestre, maritime, aérienne, géographique ou même globale, je ne saurai vous recommander le « Traité de stratégie » qui n’est autre que la bible stratégique que je m’efforce à lire en long, en large, en travers et à annoter depuis quelques semaines. Tout, absolument tout est bon à prendre dedans. Sa lecture est un pur bonheur et les thèmes traités abordables – je pense – même pour des néophytes en matière de (géo)stratégie.

Pour conclure donc, n’attendez-vous pas à une réelle activité ces prochains jours, en ce moment, je suis complètement submergé par différents projets et le temps libre (le vrai) que je peux posséder, je fais tout pour le passer loin d’un PC et loin de Bordeaux avec des ami(e)s.

Nous abordons ainsi les différentes utilisations de Twitter et ses problèmes actuels, tant au point de vue financier (comment rendre ce service économiquement viable) jusqu’à la sécurité du service et de ses utilisateurs (vulnérabilités des API).

Un petit slide est d’ailleurs dédié à KreiosC2, le PoC permettant de transformer Twitter en cannal de communication pour BotNet par le 80 et ainsi bypasser quelques firewalls au passage (reste le problème de certains proxys internes aux entreprises, mais bon, on peut l’éliminer facilement ;) et puis, ce n’est qu’un PoC, onne va pas tout mettre sur un plateau.

Voici les slides (hébergées sur slideshare) :

Ce stage, je souhaite le réaliser dans le domaine de la Sécurité des Systèmes d’Information et plus spécifiquement dans le domaine des audits & tests d’intrusion (réseaux, bastions & web) ainsi que dans la veille liée à la sécurité informatique.

Je cherche – grâce à ce stage – à approfondir mes connaissances dans les méthodes d’audit et normes (ISO 27001, OSSTMM, PCI DSS, OWASP), ainsi que dans la sécurité de certains protocoles. Aujourd’hui, je possède de bonnes connaissances en audit d’applications web & bastions, en Information Gathering ainsi que dans différents domaines liés à la sécurité des systèmes d’information.

• Attaques sur réseaux & bastions
• Malware analysis
• Sécurité des clients
• Sécurité Linux
• Veille

J’espère découvrir, de par ce stage, la sphère professionnelle de cette passion que je possède depuis cinq ans maintenant et partager ainsi mes connaissances tout en apprenant de nouvelles techniques dans ce domaine.

De plus, je suis ouvert à toute proposition de stage dans d’autres domaines liées par exemple au développement web/administration de serveurs, au webdesign ou à la veille informationnelle. Vous pouvez dès aujourd’hui prendre contact avec moi par l’intermédiaire de mon site Internet et voir mon CV en cliquant sur l’icône ci-dessous :

L’ingénierie sociale un procédé d’attaques très utilisée contre les systèmes d’information permettant de récolter des informations en vue d’une attaque ou même de saboter certaines parties des SI avec – ce que j’appelle personnellement – des bombes informationnelles (j’ferai p’être un article dessus…).

Afin d’arriver à son objectif, l’attaquant pourra utiliser toutes sortes de méthodes plus ou moins axées sur les émotions, la naïveté de la personne, la falsification d’identité ou l’envoi de fausses informations en liaison le plus souvent avec des variables d’environnement propres à l’entité visée. (présentation minimaliste)

Ce domaine n’a pas tellement évolué au point de vue des procédés de récolte, de tri de l’information et des stratégies d’attaques (Qui a dit stratégie militaire ?). Cependant, avec l’ébullition actuelle des réseaux sociaux tant au plan personnel que professionnel véritables fers de lances de cette société d’information où l’on veut « tout montrer » ce domaine est en pleine révolution et n’est pas prêt de disparaitre… tout comme la connerie humaine.

Bref, c’était juste trois paragraphes pour vous mettre dans l’ambiance et vous présenter les nouvelles solutions (et non problématiques) liées à l’ingénierie sociale. En ce qui concerne le site, il s’appelle social-engineer.org.

Ce dernier est aujourd’hui bien documenté et possède différents articles de wiki, vidéos et présentations de programmes tels que le (très connu, et très cher) Maltego ou le tookit « Social Engineer Toolkit » pour le fameux Metasploit ! Je vous invite vivement à lire le wiki car il est intéressant (même si certains sujets sont très basiques.)

Seul petit point, en ce qui concerne les vidéos, il auraient pu mieux faire… mais bon, ce n’est qu’un détail =)

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.

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 =)

Aujourd’hui, de plus en plus de services et de réseaux sociaux misent sur les API pour permettre aux utilisateurs une réelle appropriation de leur service et ainsi, récolter un maximum de membres. Le piratage de Twitter n’est en aucun cas lié au « tout-API », mais aux vulnérabilités du could-computing et surtout à la capacité des administrateurs de Twitter de faire confiance à un système vulnérable en soi. D’ailleurs, je ne comprend pas encore pourquoi ils laissent aux yeux de Google (un de leurs concurents) par l’intermédiaire de GoogleDocs des documents confidentiels et extrêmement préjudiciables pour leur entreprise…

Cependant, ce piratage amène à s’intéresser aux services professionnels et amateurs développés en parallèle des sites web 2.0 grâce aux différentes API mises à disposition par les développeurs. Ces derniers présentent de nombreuses vulnérabilités, pas uniquement liées aux vulnérabilités lambda du type XSS permettant le vol de compte des membres. Elles peuvent se transformer être de véritables risques, tant pour les utilisateurs, que pour d’autres sites Internet pouvant par l’intermédiaire du piratage de ces services subir de véritables DDos ou être le relai d’attaques plus pointues.

1. Vulnérabilités

Bref, voilà ce que l’on peut dire sur les types d’attaques dont peuvent être victimes les différents services et ce que cela peut engendrer pour les victimes :

• Vol de session permettant, selon le type de configuration du service, de poster certaines informations à la place de l’internaute. Et peut-être, de pouvoir de fil en aiguille s’identifier totalement sur le site source produisant l’API à la place de l’internaute.

• Attaque MIM, récupération des identifiants. Une large partie des services utilisant les API de certains réseaux sociaux demandent à l’internaute de s’identifier sur leur site – pour pouvoir, par exemple, poster un message à la place de l’internaute automatiquement -. Cependant, ces identifications sur certains services (une majorité) n’utilisent pas un protocole sécurisé -SSL- pour transmettre les identifiants du client vers leur serveur, permettant ainsi l’interception de ces derniers dans un réseau local. Ainsi, cela permet de contourner pour un pirate le https mis en place par certains réseaux sociaux pendant l’identification de leur membre.

• Vulnérabilités lambda des services web Entre SQLi, XXS, CSRF, failles « d’upload », includes locales, injections dans des fichiers etc. Nous pouvons trouver de tout sur les services rattachés aux APIs de certains réseaux sociaux. Ceci permettant de faire un peu ce que l’on veut (ouverture d’un shell, mise en place d’une backdoor sur les différents serveurs, piratage des bases de données etc.). Cependant, les pirates auront – je pense – une attention toute particulière pour backdoorer les mécanismes d’identification des membres afin de récupérer les identifiants de ces derniers. Ils attaqueront – suivant leurs envies – ensuite les sessions des membres sur le réseau social promulguant les API, mais également testeront les mots de passes récoltés sur différents sites où les membres se sont sans doute inscrits ainsi que sur les webmails. D’autres s’amuseront peut-être avec la récupération des identifiants à inonder les services de micro-blogging de messages…

• Hijacking des URLs Cette vulnérabilité pèse surtout sur les shorteners d’URL du type bit.ly ou tinyurl.com. Imaginez ce que peut ressentir un site internet étant pointé par des millions d’URLs potentiellement cliquables plusieurs fois par des utilisateurs. Le problème est à relever et la sécurité des shorteners d’URL est aujourd’hui un point critique auquel il faut faire très attention. D’ailleurs, ce problème est déjà arrivé au service Cligs, re-dirigeant deux millions d’URL vers un seul site… qui n’a pas tardé à tomber. Voir un article à ce sujet ici ou là.

2. Contre-mesures

Les contre-mesures à appliquer sont assez simples pour les utilisateurs de réseaux sociaux, utilisez au minimum des services bâtis sur les API de certains services web, surtout quand ces derniers demandent une identification n’étant pas sécurisée. Il faut aussi essayer de deviner quels services sont susceptibles de garder dans leurs bases de données vos mots de passes en clair (cela est déductible assez facilement, si vous vous inscrivez à un service qui agit régulièrement sur votre Twitter sans votre intervention (transposition de flux RSS etc.)).

Pour ce qui est des développeurs de services reposant sur des API, engager un hacker/pirate/spécialiste (rayez la mention inutile) reste la meilleure solution afin de tester les différentes vulnérabilités qui peuvent siéger dans le système. Après libre à eux de le faire ou non, cependant la qualité de service risque à tout moment de passer à la trappe si des audits de sécurité ne sont pas faits régulièrement sur les différentes sphères du système d’information régissant le webservice. (acteurs, physique, application).

3. Conclusion

Tout comme les plugins pour les CMS, les services utilisant des API de certains sites communautaires répandent leurs vulnérabilités au grès de leurs créations augmentant ainsi les risques de rendre tout un système vulnérable. Cependant, ces vulnérabilités (et c’est là toute la chose) ne se concentrent pas au seul site internet du service utilisant l’API d’un énième site communautaire, mais peuvent être utilisés contre les utilisateurs des sites communautaires et contre d’autres sites internet.

Je pense que Twitter – même si la sécurité n’est pas leur fort – (ou d’autres sites communautaires) devraient avoir le droit de jeter un coup d’oeil sur les sources des scripts et des serveurs sur lesquels reposent les services utilisant leur API. C’est tout de même les utilisateurs du site internet diffusant les API les premiers attaqués. Bref, j’espère que cette petite parenthèse vous à un peu informé sur les risques du « tout-API » même si je n’ai pas énuméré l’intégralité des failles (ce qui est en soit impossible). Je prédis cependant une hausse significative des piratages de comptes utilisateurs par l’intermédiaire de ces services dans les prochains mois. D’ici là, prenez garde à vous ! NIARK :D