mercredi 11 juillet 2012

RMLL Workshop reverse, writeup

Ce post de blog va donner diverses solutions aux challenges proposés par r00tBSD pendant le workshop reverse engineering des RMLL 2012. Les solutions aux exam1, exam2, exam3, exam4 sont expliquées.
Les binaires sont téléchargeables en suivant ce lien (500ko). Ce sont des binaires linux 32 bits standards. Les exams nécessitent de trouver le bon mot de passe, à la manière des keygenme classiques des challenges que l'on trouve sur internet.

1/ exam1 - cold start
Comme a dit le formateur, cet exercice n'est présent que pour vous éviter de finir à 0 points :-).
kevin@slack:~/binaries$ ./exam1
Usage: ./exam1 key
kevin@slack:~/binaries$ ./exam1 test
Bad key
kevin@slack:~/binaries$ strings exam1
 (je coupe un peu, et on observe enfin)
øÿuô
è\þÿÿY[ÉÃ
Usage: %s key
r56GoinQ
Bad key
Good key
ÿÿÿÿ
ÿÿÿÿ
(snip snip snip encore un peu...)
main
_init
kevin@slack:~/binaries$
Sans trop réfléchir on lit les strings et on tombe sur le Usage, puis une série de caractères qui ressemblent à une clé, et les deux messages "good key/bad key". Sans plus attendre:
kevin@slack:~/binaries$ ./exam1 r56GoinQ
Good key
kevin@slack:~/binaries$

[Une anecdote à ce sujet: j'ai fait un challenge ou la clé était 'printf'. Bien qu'elle soit sous les yeux, aussi clairement indiquée, on ne pense pas à l'essayer :) ]

2/ exam2 - les moteurs sont chauds
L'exam2 est basé sur le même principe sauf que lire le binaire avec strings ne donne aucune indication valable. Il faut trouver une autre solution.
2/A/ La solution rapide
Le programme ltrace permet de tracer l'appel aux librairies. Puisque l'on se doute qu'un strcmp est fait pour comparer la clé entrée au clavier de la clé valide on regarde:
kevin@slack:~/binaries$ ltrace ./exam2 toto
__libc_start_main(0x80484a4, 2, 0xbf88a804, 0x8048590, 0x8048580
strcmp("AFc6mcw", "toto")                        = -51
puts("Bad key"Bad key
)                                  = 8
+++ exited (status 0) +++
kevin@slack:~/binaries$
La solution crève les yeux.
kevin@slack:~/binaries$ ./exam2 AFc6mcw
Good key
kevin@slack:~/binaries$

2/B/ La solution du programmeur
Il existe une variable d'environnement LD_PRELOAD qui permet de surcharger l'appel des bibliothèques. Il suffit donc d'utiliser une bibliothèque qui détourne l'usage de strcmp pour en connaître ses arguments. Un man strcmp permet de connaître la structure de la fonction pour reprendre les mêmes arguments.
kevin@slack:~/binaries$ cat hijack.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int strcmp(const char *s1, const char *s2)
{
 printf(" String 1 = %s\n String 2 = %s\n ", s1, s2) ;
}
kevin@slack:~/binaries$ gcc -shared hijack.c -o hijack.so
kevin@slack:~/binaries$ LD_PRELOAD=$(pwd)/hijack.so ./exam2 toto
 String 1 = AFc6mcw
 String 2 = toto
 Bad key
kevin@slack:~/binaries$
La solution est bien évidemment identique. WIN.

3/ exam3 - on met les mains dans le cambouis
l'exam3 va obliger à regarder de l'assembleur dixit le formateur. On sort donc gdb, et l'analyse fastidieuse commence. Nous avons droit à une mini formation de la gui de metasm qui permet de résoudre très vite cet exercice. Pour cela on télécharge metasm à l'aide de hg
kevin@slack:~$ hg clone https://code.google.com/p/metasm
 (... snip)
kevin@slack:~$ cd metasm
kevin@slack:~/metasm$ export RUBYDIR=/home/kevin/metasm/
kevin@slack:~/metasm$ ruby samples/disassemble-gui.rb
On charge alors le fichier exam3 (menu file Open), on le désassemble à l'aide de la touche 'c', puis on appuye sur espace pour obtenir le graphe de fonctions, puis menu Actions->List fonctions, et on choisit le Main du programme. On obtient cela (cliquer sur l'image pour la voir en grand):
La lecture du binaire est plus aisée. Le premier bloc doit compter le nombre d'arguments. Le second bloc à gauche fait un strlen et si le résultat diffère de 9 part à la fonction loose (avec un nom pareil on se doute qu'il ne faut pas aller là-bas :) ), on sait donc déjà que le mot de passe doit faire 9 caractères première information.

Ensuite, on peut zoomer à l'aide de CTRL molette souris, et en vue d'avion on observe cela:
(oui les cadres sont blanc, je n'ai pas de police à la bonne taille apparemment).
On se doute donc immédiatement que le programme va comparer caractère après caractère la clé entrée par l'utilisateur.
Suivons donc les blocs pas à pas:
cmp al, 41h. 
cmp signifie comparer. En code hexa, 41 est le 'A'. Nous savons donc que le A est le premier des 9 caractères du mot de passe. 
Le bloc suivant est beaucoup moins clair, c'est sans doute lié à une optimisation compilateur (?)
On va finalement sortir gdb. Tout d'abord, pour connaître l'adresse de ce cmp, on clique dessus, puis on presse la barre espace, ce qui nous amène à:
où l'on lit donc l'adresse: 0x08048521.
Nous allons donc placer un breakpoint à cette adresse, et étudier les registres edx et eax à ce moment là:
kevin@slack:~/binaries$ gdb exam3
 (snip)
(gdb) b *0x08048521
Breakpoint 1 at 0x8048521
(gdb) run Aaaaaaaaa
Starting program: /home/kevin/binaries/exam3 Aaaaaaaaa

Breakpoint 1, 0x08048521 in main ()
(gdb) info registers
eax            0x44    68
ecx            0x4c504300    1280328448
edx            0x61    97
ebx            0xb7fc2ff4    -1208209420
esp            0xbffff0e0    0xbffff0e0
ebp            0xbffff0f8    0xbffff0f8
esi            0x0    0
edi            0x0    0
eip            0x8048521    0x8048521
eflags         0x206    [ PF IF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51
(gdb)
Nous devons lancer le programme avec une clé de 9 caractères débutant par un A majuscule sinon nous sortirons avant. Une fois breakpointé, nous consultons les registres: edx vaut 0x61, ce qui correspond au a minuscule. eax vaut 0x44 qui est le D majuscule. Le deuxième caractère du mot de passe est donc le D majuscule.

En progressant de la même manière, il est possible de retrouver les 8 premiers caractères de la clé. huit? que 8? Or nous savons qu'il en faut neuf!
Petite blague du formateur, il ne faut pas chercher un 9e caractère ou une instruction oubliée. En effet, ce programme ne vérifie que les 8 premiers caractères d'une clé qui en contient 9. Ce qui signifie que n'importe quelle caractère en 9 position est valide!
kevin@slack:~/binaries$ ./exam3 AD13=xhca
Good key
kevin@slack:~/binaries$ ./exam3 AD13=xhcb
Good key
kevin@slack:~/binaries$ ./exam3 AD13=xhc9
Good key
kevin@slack:~/binaries$

[info pratique: sous linux man ascii affiche le code ascii des caractères]

4/ exam4 - sortie de piste!!
Pour cet exercice, je pense que toute la salle s'est fait berner. On est chaud, on a le gdb dégainé, le metasm-gui ouvert, donc on regarde direct le programme. Sauf que là, on a deux surprises:
Tout d'abord un graphe pas très engageant, et ensuite une absence totale de fonction main...
La solution est à portée de main. Le programme est en fait packé, il faut le dépacker pour pouvoir l'analyser. Un simple hexdump donne une première idée, un strings confirme:
kevin@slack:~/binaries$ hexdump -C exam4 | head   
00000000  7f 45 4c 46 01 01 01 03  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  e0 dd c3 00 34 00 00 00  |........àÝÃ.4...|
00000020  00 00 00 00 00 00 00 00  34 00 20 00 02 00 28 00  |........4. ...(.|
00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 10 c0 00  |..............À.|
00000040  00 10 c0 00 e0 d5 03 00  e0 d5 03 00 05 00 00 00  |..À.àÕ..àÕ......|
00000050  00 10 00 00 01 00 00 00  94 02 00 00 94 82 0c 08  |................|
00000060  94 82 0c 08 00 00 00 00  00 00 00 00 06 00 00 00  |................|
00000070  00 10 00 00 5f ac 1b b0  55 50 58 21 ff 07 0d 0c  |...._¬.°UPX!ÿ...|
00000080  00 00 00 00 2f d2 08 00  2f d2 08 00 f4 00 00 00  |..../Ò../Ò..ô...|
00000090  80 00 00 00 08 00 00 00  77 1f a4 f9 7f 45 4c 46  |........w.¤ù.ELF|
kevin@slack:~/binaries$ strings exam4 | grep UPX
°UPX!ÿ
UPX!
$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.07 Copyright (C) 1996-2010 the UPX Team. All Rights Reserved. $
ùUPX!u
UPX!
kevin@slack:~/binaries$
Une fois dépacké avec un coup de upx -d, le programme est quasiment celui de l'exam3.

5/ exam5 - explosion de moteur
Je n'ai pas fait cet exam, ni même tenté de le résoudre. Il fait crasher gdb, il fait planter metasm-gui, et selon le formateur seul edb debugger réussit à l'ouvrir après un temps très long. Peut-être un post de blog dans le futur :-)

Une explication de simple1 est à venir, étant un peu différent de ces keygenme.

mardi 10 juillet 2012

RMLL 2012 - jour 2.

1/  Utilisation malveillante des suivis de connexions - Eric Leblond
Pour pallier à la défection de Werner Koch qui devait effectuer une
présentation de Steed, le futur (ou le remplaçant) de PGP, Eric Leblond
redonne la conférence donnée au SSTIC 2012.
Ayant déjà été couvert par des live blogging du SSTIC, je repose
la clavier pour celle-ci.
La conférence est très intéressante, mais le projet STEED m'intéresse énormément. Dommage que Werner Koch n'ait pu se libérer.

2/ Browser ID - Jean-Yves Perrier
Cette conférence va traiter de Persona ou BrowserId et est présentée par un développeur mozilla. Mozilla n'est pas que Firefox, et est une fondation qui oeuvre à un web ouvert.
Il est de plus en plus obligatoire de posséder un login/pass pour pouvoir se connecter sur des sites webs. Ceci pose des problèmes de sécurité et quelques problématiques pratiques, browserId se propose de répondre à ces deux points.

Les pirates savent que les utilisateurs réemploient toujours le même mot de passe car il est difficile de mémoriser au delà de 4-5 mots de passes. Les campagnes de sensibilisation existent, mais ces méthodes continuent de prospérer.
Des modes centralisés existent, mais restent cantonnées à un navigateur alors qu'on surfe aujourd'hui depuis des navigateurs et devices différents (android, puis tablet, puis PC fixe, etc..). Persona essaye aussi de répondre à ce problème.
Facebook propose un système centralisé. De plus en plus de sites acceptent le login facebook par exemple. Toutefois cela permet à des sociétés de profiler très simplement les internautes. Persona essaye donc de proposer un login unique sans possibilité de traçabilité. OpenID répond à cette problématique de traçabilité, toutefois l'usage ne se répand pas en raison de son absence d'ergonomie, l'id ressemble pour l'utilisateur à un nom de domaine et pas vraiment à une identité. Persona va encore répondre à ce point.

Persona va donc essayer d'être bien évidemment sécurisé, simple, SSO, et lié à une identité. Mais la gestion des identités est également un procédé compliqué à mettre en oeuvre pour les sites webs. Dans toutes les bonnes pratiques il est indiqué que les mdp doivent être salés puis hachés, mais tous les sites ne le font pas. Et les sites doivent également protéger les utilisateurs contre eux mêmes (mdp trivial) ce qui est difficile à gérer techniquement. Un développeur de site web souhaite donc lui aussi un système simple sûr, respectant la vie privée, et compatible de partout.

La solution s'appelle Persona et se base sur le protocole BrowserID. BrowserID authentifie un utilisateur de manière sure et ne fait fuiter aucune information à des tiers. L'identité primaire se fait sur l'adresse e-mail en raison de la personnification de celle-ci, les utilisateurs savent généralement que l'adresse les représente. Les e-mails ont aussi l'avantage du pseudonymat :)

Trois acteurs sont au centre du système. Tout d'abord, l'utilisateur, puis le "relying party" (le site web sur lequel on se connecte par exemple), puis le provider qui va authentifier/identifier l'adresse mail. Tout d'abord, l'adresse mail doit avoir été enregistrée avec le provider d'identité (cette étape n'est à faire qu'une fois). Ensuite, une mécanique crypto se met en place pour identifier temporairement l'utilisateur sur le site.

Pour les développeurs, une effort de simplicité est fait puisqu'il faut ajouter une ligne d'include dans le code, un bouton (juste une image) et une fonction qui réagisse au clic sur le bouton. Côté code client, cela représente moins d'une quinzaine de ligne en jquery par exemple. Côté serveur il suffit d'une dizaine de lignes. L'avantage c'est surtout qu'en compromission du site web, aucun mot de passe ne peut être divulgué.

Pour la roadmap une beta va bientôt sortir. Tous les produits mozilla vont se mettre progressivement à l'utiliser (mozilla developper, bugzilla, etc..).La prochaine étape consiste à décentraliser le provider qui est browserid.org, afin d'autoriser n'importe quel serveur de mail à devenir provider. Toutefois un provider d'email ne pourra identifier que les mails de son domaine, seul browserid peut identifier n'importe quel domaine.

3/ Elections HELIOS - Stéphane Glondu
Je ne suivrai pas cette conférence, mettant les dernières modifications sur mes slides.

4/ L'accès à internet est un sport de combat - Kevin DENIS

RMLL 2012 - Workshop Reverse Engineering

RMLL Jour 2. La matinée débute par un atelier de reverse engineering proposé par rootBSD (Paul Rascagnères). L'atelier est composé d'une série de malwares à analyser. Pour la petite histoire, ces binaires sont ceux qui sont donnés lors des entretiens d'embauche de sa société (itrust.lu) .
Exercices classiques dans lequel il faut trouver un mot de passe à donner au binaire qui affiche Godd key or Bad key, ainsi qu'un algorithme de chiffrement/déchiffrement d'image png. On retrouve les outils donnés la veille pendant sa conférence (strings, ltrace, gdb).

L'atelier m'a permis de découvrir un outil: metasm. Metasm est une bibliothèque ruby facilitant l'analyse de malware. metasm est livré avec quelques outils utilisant cette bibliothèque dont une interface graphique qui permet d'afficher le graphe des fonctions. L'outil fait beaucoup d'autres choses, je vais aller me renseigner sur ce programme dont le seul défaut selon le formateur est la légèreté de la documentation (esprit de scapy es tu là? :) ).
Un autre outil à suivre est très peu connu et s'appelle edb debugger.
Le dernier exercice est un binaire qui fait crasher tous les debuggers. Typiquement l'int3 est trappée pour faire crasher gdb. Le binaire fait monter à 100% de CPU metasm sans fin, mais edb parvient, après un temps relativement long à charger le binaire. edb debugger.

Très bon workshop, bons exercices, très bonne pédagogie du formateur :-)

lundi 9 juillet 2012

RMLL (suite) - reverse engineering

Ce message est la suite de mon live blogging pour la première journée sécurité aux RMLL 2012.

5/ Reverse Engineering RootBSD
La conférence est captée en Audio Vidéo. Conférence présentée par r00tBSD aka Paul Rascagneres, mainteneur et auteur du projet malware.lu. malware.lu c'est 1.2Million de malwares et 800 utilisateurs, ainsi que des articles.

Cette présentation va montrer et décrire les outils libres utilisés pour faire du reverse, mais elle démarre par des rappels juridiques. Il semblerait que vis-à-vis de la loi française, le reverse de malware soit possible.
  • Les outils ltrace & strace: Ces outils donnent les syscalls utilisés par les binaires, mais ont toutefois le défaut de devoir lancer le binaire. Ces deux appels utilisent en fait ptrace. ptrace est lancé avant le binaire, lui donne la main et peut la reprendre à tout moment. ptrace permet vraiment de monitorer entièrement un binaire, il a notamment servi à reverser skype.
  • LD_PRELOAD: une variable d'environnement connue sous tous les unix, qui permet sous linux de donner des bibliothèques qui seront chargées en priorité (hook de librairie). Cela permet de surcharger les fonctions de librairies de l'OS. Cette méthode ne fonctionne pas sur les binaires setuid pour des raisons de sécurité.
  • SystemTap: développé par redhat, qui ressemble à dtrace de solaris. Il existe un grand nombre de sondes (réseaux, IO, etc..) et systemtap permet d'écrire des programmes qui s'appuyent sur les données de ces sondes. Sert aussi pour mesurer les perfs.
  • Wireshark: quelquefois le reverse est inutile, une simple trame réseau est suffisante.
  • Analyse de mémoire: généralement un binaire malveillant sur disque est compressé ou obfusqué et se déchiffre en mémoire. Dans une VM on peut lancer le malware, et dumper la RAM de la VM. L'analyse de dumps windows se fait avec volatility et volatilitux pour linux. Une live demo est montrée sur une machine windows. Puisque voloatility n'est pas lancé sur la machine cible, il est impossible pour le binaire malveillant de modifier les outils d'analyse.
La suite de la présentation est plus tourné vers l'assembleur, les non geeks et les personnes facilement impressionnables sont priés de quitter la salle :) Quatre outils vont être évoqués.

  • Cuckoo: cuckoo est une sandbox virtualbox qui logge tout ce qu'un binaire fait (fichiers, réseaux, Base de registre windows, etc) et  produit un rapport. En fin d'analyse, la VM est restaurée. L'analyse est automatique.
  • gdb et winegdb: le debugger le plus connu. gdb permet de mettre des points de pause (breakpoints), fonctionner en pas à pas, montrer le code assembleur et beaucoup d'autres choses. Une demo sur un binaire est présenté avec mode pas à pas et présentation des registres.
  • Virtualbox et gdb: lorsque gdb ne suffit pas, il est possible de l'utiliser avec virtual box. Le conférencier fait très fort en présentant l'analyse de Flame (un virus dont vous avez entendu parler). Le conférencier fait une bonne explication en indiquant comment utiliser Flame contre lui-même en lui faisant décoder chacune des chaînes obfusquées, tout ça sans même connaître le code de déchiffrement!
  • ripper metasm: il s'agit d'un wrapper permettant d'extraire une fonction d'un malware et de trouver les arguments qui lui sont passés. Ceci permet ensuite d'inclure cette fonction dans n'importe quel programme. Ceci es très utile lorsque des opérations d'obfuscation existent dans les malwares. Les phases d'analyse de ces fonctions étant fastidieuses autant demander au malware de faire le travail lui même :)
Mais l'analyse dynamique n'est pas le seul mode d'analyse car quelquefois les malwares détectent les environnements de debugs. Il faut donc effectuer des analyses statiques du code. metasm permet de faire de l'analyse statique. Une courte demo est faite, puisque tout ceci sera revu dans le workshop de mardi matin. Dans les questions est posé la question d'Ida. Le conférencier indique qu'Ida est encore au dessus des outils libres bien que metasm progresse bien.

Je ne ferais pas de suivi demain matin, étant au workshop reverse engineering.

RMLL2012 - Suricata - nmap v6 - NAXSI

Je suis aux RMLL 2012 en train de suivre le track sécurité. Voici un live blogging des trois premières conférences.

1/ Suricata Eric Leblond
Suricata est une sonde IDS/IPS. La conférence est présentée par Eric Leblond développeur de Suricata, contributeur netfilter et membre de la fondation suricata au sein de l'OISF (www.openinfosecfoundation.org , organisation "non-profit"). Suricata est né de la lourdeur des 400000 lignes de codes de Snort. Il a été décidé de réécrire une nouvelle lib d'analyse plutôt que de continuer à modifier Snort. La Fondation est financée à l'orgine par le gouvernement US, mais les décisions restent communautaires. Le but de l'OISF est d'obtenir de nouvelles technologies d'IDS: performances accrues, utilisation de l'accélération hardware et multi OS (linux BSD, windows). Les challengers sont BRO et Snort. (Et l'orateur précise que même si suricata dérive de Snort, il est bien plus performant que son aîné :) )

Dans les fonctionnalités, Suricata fait nativement de l'IPv6, multi-thread, sait monter à 40GBp/s, et reconnait les flux indépendamment des ports. Suricata reconnaît les modes captures classiques, pcap, AF_PACKET, PF_RING pour l'IDS. Concernant l'IPS NFQUEUE, et ipfw. Les sorties sont en fastlog, unified log, prelude. De manière très simplifiée, Suricata fait le lien entre ce qui se passe sur le réseau et l'ajout d'une ligne dans les logs. La configuration de Suricata se fait par des règles inspirées par la syntaxe de Snort.
Suricata possède une librairie HTTP (libHTP )dont le rôle est de parser facilement les flux HTTP qui représentent la grande majorité du trafic réseau. Un exemple donné présente un parsing permettant de bloquer le chat de facebook. Pour ce faire, Suricata sait reconstruire les flux afin de  les normaliser pour les parser en évitant les problèmes réseaux  (fragmentation, etc.. ) Suricata sait poser des variables, les incrémenter et faire des choix en relation à leurs valeurs.

La version 1.3 sortie le week-end précédent les RMLL (bravos aux développeurs, même s'il s'agit plus d'un hasard :) ) amène plusieurs nouveautés. Tout d'abord, la libHTP permet une axtraction des fichiers téléchargés. Ceci permet une analyse plus fine dans les règles. Par exemple prévenir lors du download d'un fichier exe windows, ou le stocker pour analyse ultérieure. L'extraction de fichiers est à ce jour limité à HTTP, même si le mail devrait être supporté. Ensuite, Suricata sait analyser les handshakes SSL à l'aide d'une base de code maison, openssl étant trop gros pour être audité. Le parser SSL vient de l'ANSSI (Pierre Chifflier). Les règles permettent de trier selon le DN ou l'ISSUER, bientôt le fingerprint du certificat, ou les tailles de clés. Le parser ne gère actuellement que le premier certificat de la chaîne SSL. Les certificats ne peuvent pas non plus encore être stockés à la manière de HTTP. Enfin, la 1.3 vient avec des perfs accrues, notamment dans le cas de multicores.

La conférence finit par la roadmap, dans laquelle vient l'IP et la DNS reputation, SCADA et le geoip. C'est un produit librement utilisable, il existe des liveCD, et
des infos, voir le site de suricata.

2/ nmap v6 Henri DOREAU
On ne présente plus nmap (15 ans déjà!) qui est un scanner de port dans lequel est ajouté un système de reconnaissance d'applications et d'OS. Il intègre aussi un moteur de script et des outils compagnons. La communauté est très vivante et remonte beaucoup de statistiques et de  scripts NSE (aujourd'hui plus de 400 scripts). nmap est aussi une star du cinéma ! le site contient la liste (longue) dans lequel nmap apparaît :).

Les scripts NSE sont des scripts LUA. 4 modes d'exécutions sont présent. Les prerules, qui est lancé avant le scan nmap, le service, lié au service, host, lié à l'host, et les postrules qui servent surtout à réaggréger les résultats. Un script a deux fonctions de base: la rule qui renvoie un booléen indiquant s'il doit se lancer ou non, et une action qui est lancée si le booléen est vrai. les scripts ont plusieurs bibliothèques permettant des renormalisations des résultats ou des modes d'affichages. NSE est monothread, avec différentes manières pour simuler du parrallélisme afin de faciliter la vie des scriptwriters. Les scripts sont écrits pour ne pas avoir de dépendances. Exemple:
nmap --script samba-vuln-cve-2012-1182 <target>
nmap --script "http-* and not brute" <target>
le site http://nmap.org/nsedoc listes les scripts actuels, par catégorie.

La seconde amélioration concerne IPv6. Toutes les fonctionnalités de nmap sont portées en IPv6 (si tant que ça ait du sens) et toutes les plateformes ont cette amélioration. Certains points ont été simples à porter, comme le scan TCP, d'autres ont du être entièrements réécrits comme la détection d'OS. IPv6 devient important et nmap a voulu le supporter, surtout par le fait que tous les OS majeurs sont dual stacks. Il existe des scripts de découvertes d'hôtes pour éviter de scanner des plages entières IPv6. Le passage a IPv6 a été l'occasion de plusieurs nettoyages de codes et améliorations.

Les autres améliorations concernent plusieurs points de moindres importances (en terme de nombre de slides :) ). Tout d'abord la plage des 1000 ports classiques a évolué suite aux remontées utilisateurs. Une autre amélioration concerne nping qui ressemble à hping2 en plus évolué. nmap signifie network mapper, mais il ne fait des cartes que depuis la version 6 :) Zenmap propose d'afficher une carte représentant les réseaux scannés (15 ans pour mériter son nom, bel effort de nmap :) ). Une autre grosse amélioration concerne le web, grâce au Gsoc. C'est une première implémentation, pas encore au niveau des scanners webs habituels, mais c'est un début..

La roadmap du produit concerne la lib HTTP qui doit évoluer (SPDY?). L'outil compagnon ncat doit aussi être revu. NSE va continuer d'évoluer pour être de plus en plus puissant, les outils compagnons devraient s'y voir adjoints. Une combinaison des scans IPv4 et IPv6 est à l'étude. Un travail est en cours pour scanner au travers de relais, ou SSH. Et NSE pourrait se voir adjoindre un Updater pour synchroniser l'ensemble des scripts, leur base évoluant très vite.

3/ NAXSI Didier CONCHAUDRON Sébastien BLOT
D'une part le web est partout. D'autre part, les vulnérabilités web existent en plus grand nombre. Ces failles touchent tout le monde, aussi bien les petits hébergeurs que les grosses compagnies. Ces failles modifient l'aspect du site jusqu'à l'exfiltration de données. On constate que le niveau moyen des développements webs n'est pas très bon, et cet état de fait persiste, d'où l'augementation des attaques. Les statistiques fournies montrent bien l'étendue du problème. La première cause de ces failles vient généralement de la faiblesse du code, ainsi que de la non connaissance des mécanismes de sécurité des
développeurs. (Je rappelle que la conférence est faite par une équipe de pentesteurs)

La solution classique consiste à corriger le code. Et lorsque le patch du code est impossible, il faut alors mettre un WAF. "WAF est à HTTP ce qu'un firewall à OSI layer2".

NAXSI vient d'une idée de Thibault Koechlin, de NBS systems. Le problème des WAF classiques sont le prix trop elevés pour les WAF commerciaux, et mod_security est trop faible en performances. Enfin, il faut du temps pour garder les signatures à jour. NAXSI est basé sur nginx, bonne performances, sans mise à jour (que de la reconfiguration).

NAXSI a un ruleset de base sur lesquelles seront construites les règles pour protéger un site. NAXSI contient 35 règles (SQLi, XSS, etc..) qui ont une pattern, un score, des matchs zones et un Id. Ce set réduit de règles et une naïveté dans les regexp (pas de reconstructions, pas de sessions, etc) permet de grandes perfs, mais oblige à un apprentissage pour une création de liste blanche. NAXSI a un très faible overhead en terme de perfs comparés à un nginx 'brut'. NAXSI fonctionne aussi seulement en mode IPS ou il logge uniquement les attaques.

NAXSI est connu pour avoir protégé le site de Charlie Hebdo alors qu'il était massivement attaqué. Cela lui a permis un test haute performance puisqu'à l'époque 80% du trafic était malveillant.

4/ Lemon LDAP Clément OUDOT.
Je ne suis pas cette conférence.