Une société française qui fait ce qu’on appelle le « buzz » en ce moment, s’est amusée à réaliser – et l’idée, faut l’admettre, est très loin d’être bête – des captchas publicitaires. En gros, l’astuce est de recopier un superbe slogan publicitaire pour valider un formulaire – le captcha – histoire qu’il s’imprime bien dans notre mémoire. Cool, n’est-ce pas ?

Un captcha, qu’est ce que c’est ?

Un captacha est – pour faire simple – un système utilisé pour sécuriser un formulaire web (pour envoyer des commentaires, par exemple) contre le spam. En effet, le spam est généré par des programmes informatiques qui peuvent valider des formulaires automatiquement et donc, envoyer des messages en masse. Les captchas servent donc pour différencier un robot (un programme informatique) d’un humain (avec une réelle intelligence). Vous en avez tous vu, cela ressemble à ceci :

Aujourd’hui, il existe plusieurs types de captchas avec des niveaux de sécurité et de complexité différents. Voici une liste que je pense exhaustive : Des captchas full texte ; « drag’n’drop » (si, si : fail) ; audio ; vidéo ; à challenge ; images ; texte dans une image et de texte – bien déformé – dans une image.

Et les publicitaires arrivèrent.

L’idée de réaliser des Captchas publicitaires, d’un point de vue annonceur – et surtout psychologique, n’est assurément pas bête du tout. Cependant, on peut en dire autre chose d’un point de vue sécurité : la fonction première et réelle d’un tel système.

En effet, lier des slogans publicitaires à des captchas est aujourd’hui une mauvaise idée. Je m’explique. Tout d’abord, le service actuel (et je veux bien croire qu’il ne soit pas assez développé) ne propose pas des milliards de possibilités de publicités, contrairement à une chaine de caractères randomisée, ou, pour une meilleure interprétation mais un rendu moins significatif, les mots du dictionnaire.

Ainsi, il est possible, pour ce qu’on appelle « un pirate informatique » (en fait, dans ce cas là, un autre annonceur voulant spammer à ma méthode « old shool », sic.) de savoir, par le hash de cette dernière, quelle est l’image publicitaire qui est chargée. Voici un petit bout de code pour ce faire :

import re,hashlib,urllib2

server = "http://showcase-left.v1.api.adyoulike.com"

# hash => word to resolv.
resolv = {"c2dfef15b77b7e6e0802f186d805e524" : "meche lover"}

# Fonction lachement repris de :
# http://blog.nexua.org/python-a-day-1-remote-md5sum/
# Moi, j'l'aime bien.
def remote_MD5_sum(url, max_file_size=100*1024*1024):
    remote = urllib2.urlopen(url)
    md5 = hashlib.md5()
    total = 0

    while True:
        data = remote.read(4096)
        total += 4096

        if not data or total > max_file_size:
            break

        md5.update(data)

    return md5.hexdigest()

# Recuperation de la key
connMain = urllib2.urlopen(server + "/showcase/")
key = re.findall('/challenge/(.*)"><',connMain.read())[0]

# Recuperation du token
connToken = urllib2.urlopen(server + "/challenge/" + key)
token = re.findall('token : \'(.*)\',',connToken.read())[0]

# Recuperation MD5
hash = remote_MD5_sum(server+ "/image/" +token)

print "Token   : " + token
print "Key     : " + key
print "MD5     : " + hash
print "Phrase  : " + (resolv[hash])

Possédant une sortie à la con du type :

Token   : TfypawK258aYR2gpKpLqKqM_6cgEQ7hD
Key     : CMllh3nYbWscfzGE7g2ob10E3IDhWoff
MD5     : c2dfef15b77b7e6e0802f186d805e524
Phrase  : meche lover

Ce contournement pourrait lui-même être contourné sans changer l’image d’origine, tout simplement en la bourrant de commentaires Exifs randomisés à chaque appel de cette dernière. Toutefois, cette protection ne suffirait pas car elle pourrait elle-aussi contournée facilement en calculant l’entropie ou la valeur RVB de certaines zones de l’image. Bref, sauf changer à chaque génération le slogan de la publicité, ou la publicité (visuelle) elle-même – ce qui va à l’encontre même du principe de publicité, il est alors impossible de réaliser un système sûr, basé sur une publicité : même pas besoin d’OCR les enfants !

De l’avenir des Captchas publicitaires.

Comme nous l’avons vu, cette idée, bien que sympa pour certains annonceurs aux premiers abords, possède un réel problème de sécurité. Régies publicitaires, ne vous inquiétez pas, l’entropie et les hashs fonctionnent aussi pour des captchas en flash, audios ou vidéos. Enfin, après avoir déformé le street-art en street marketing, les créations artistiques en affiches de publicité, la publicité s’attaque maintenant à des dispositifs de sécurité, stoppons-cela.

Les vacances de Noël sont passées et j’ai un scoop à vous proposer : nous sommes en 2011. Wahou. L’année 2011 rime pour moi avec l’abandon des études pour vivre de mes propres ailes et je n’ai qu’un mot à la bouche : ENFIN ! Cependant, il faut déjà finir cette licence, finir mon stage et trouver quelque chose de stable sur Paris pour l’année.

Vous l’aurez donc deviné : je fais un stage sur Paname me permettant de décompresser un peu. Bon c’est assez ric-rac point de vue argent, car je dois payer deux loyers et le train à cause de cette connerie d’alternance. De toute façon, chercher un stage en Full-sécurité aux alentours de Maubeuge revient à partir en quête du St Graal : cette ville est loin de tout. Je ne comprends pas comment on peut faire une telle formation dans une ville aussi reculée et morte économiquement. *ça, c’est dit.*

La progression des cours

En ce qui concerne les cours, ils commencent à être bon voir même très bon. Au programme, un très bon training sur Scapy de quelques jours, du reversing basique de binaires ELF sous forme de crackme sous gdb, des cours de synergologie/manipulation sous un angle théâtral et encore quelques cours de vulnérabilités « web » et physiques. Les prochaines semaines devraient être principalement consacrées aux vulnérabilités systèmes, ça risque d’être bien sympa également.

Et TinyRAT alors ?

Concernant le projet TinyRAT, ce dernier est terminé. Malheureusement nous ne sommes pas allés jusqu’où on voulait, car une partie du groupe s’est complètement désolidarisée du projet à tel point qu’on a dû le finir à deux.

Du côté client, une grande partie du code reste à faire contre la lutte heuristique mais également sur la persistance du binaire dans un environnement bien configuré (Accès au registre désactivé etc.). Le serveur de commandes quant à lui est fini et prêt à être sujet à quelques modifications futures suivant ce que voudra faire le client (Screenshots, envoi/réception de fichiers etc). Les notes finales sur le projet sont bonnes, mais le résultat aurait pu être encore mieux avec l’investissement de l’autre partie du groupe dans le projet. (Je ne vous cache pas que j’ai vraiment la haine sur ce point-là).

Les certifications

La grande question en suspens pendant les derniers épisodes était celle des certifications. Eh bien j’ai quelques nouvelles ! C’est donc de 170 à 220 euros la certification. A ce prix-là, je me suis dit qu’il était mieux d’en passer deux, CEH et ECSA. La première va surement être facile à passer, après, pour la deuxième Ich Allah, car en passer deux à la suite…

Et puis, vu que ce ce n’était pas assez de travail, j’ai décidé de me mettre en parallèle à apprendre le Chinois traditionnel sur Paris, dans le but de compliquer la chose… Sur ce, Keep update !

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.