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

La prise d’empreinte d’un hôte ou réseau distant est une certaine science en attaque des systèmes d’information. Le but avoué est simplement de connaitre, dans le cadre d’un hôte, son système d’exploitation ou la présence de certains équipements réseau entre l’attaquant et la cible (reverse-proxy, load-balancers, firewalls, routeurs etc.) pouvant certaines fois aboutir à un cartographie très relative du réseau visé.

Obfusquer un système d’exploitation ou même le nombre d’hôtes/sous réseaux derrière un routeur ou tout autre périphérique réseau actif est une des principales mesures à réaliser face à un possible attaquant déterminé. Comme le dit souvent l’oncle Sun Tzu, il faut avant tout aveugler l’ennemi. Un ennemi aveuglé aura du mal à avancer et son attaque sera beaucoup plus longue.

De plus, le fait d’obfusquer un système montre bien que l’administrateur n’est pas né de la dernière pluie et qu’il possède des connaissances en sécurité informatique (wahou). En outre, dans le cadre de serveurs accessibles depuis le net, cette sécurisation évitera de se faire ficher par le nouveau né SHODAN qui se base sur les bandeaux des services du type SSH, Apache, IIS, Nginx ou toute autre application un peu trop bavarde.[1]

Il existe deux types de prise d’empreinte à distance, une active et une passive. (Et une autre un peu #WTF mais pas#NSFW pour certaines attaques)

La prise d’empreinte active, la plus connue, interagit directement avec le système distant. Nous pouvons citer comme logiciels Nmap ou Xprobe permettant ainsi, – suite à l’envoi de certains paquets forgés – déterminer grâce aux réponses faites par l’host, le système d’exploitation. Ce type de scanners, bien que répandus sont souvent utilisés dans leurs fonctions standard et les fonctions avancées sont souvent oubliées pour un Scan « basique ». De plus, ces dernières permettent de reconnaitre un OS de façon plus ou moins fiable suivant le type d’équipements réseaux/sécurités ou même les spécificités du scanner…

En ce qui concerne les services tournant sur les hôtes, la technique la plus triviale consiste en la récupération de bandeaux émis par ces derniers afin de déterminer de façon plus ou moins fiable la version des services et des fois, les modules ajoutés pouvant êtres faillibles. Cette technique, bien que sa mise en œuvre soit plus que facile, peut être facilement bloquée en quelques modifications sur les fichiers de configuration de ces services.

Pour ce qui est de la reconnaissance de load-balancers, il existe un petit tool sympa se basant sur la couche application (HTTP) du modèle OSI. Ainsi, Halberd compare les entêtes HTTP reçues telles que l’heure des serveurs, l’ordre des entêtes ou même le fameux header « X-Forwarded-For » (le tout par hash notamment) afin de déterminer la possible présence de plusieurs serveurs derrière un load-balancer. Pour résumé, cette méthode est simple mais surtout très astucieuse.

Enfin, nous n’allions pas parler de fringerprinting actif distant sans parler de WAF, aujourd’hui thème à la mode, les Firewalls pour Applications Web sont disposés tels des reverse-proxy. Ces derniers, permettent principalement de contrer les attaques par Injections (JS, LDAP, SQL etc.) mais possèdent bien des spécificités permettant de les fingerprinter. Aujourd’hui, un tool sort du lot pour cela, Wafwoof permettant de fringerprinté plus de 20 WAF différents parmi le plus connu dans l’OpenSource Mod_Security d’Apache. (Qui d’ailleurs avait une petite technique d’évasion sur les SQL injections il y a quelques jours… ;)

La prise d’empreinte passive quant à elle s’inscrit lorsqu’on n’a pas un « accès direct » (pour faire simple) vers l’hôte (réseau NATé, firewallé, load-balancé, IDSé etc.). Elle peut se faire par différents moyens. Cependant, les plus connus restent la prise d’empreinte de la pile TCP/IP, les TTL des paquets reçus (façon vague de déterminer l’OS – sert pour architecture interne d’un réseau NATé – mais tout de même performante lorsqu’on a pas de tools[2]). D’autres logiciels beaucoup plus fiables mais plus complexes se basent sur l’entête TCP/IP des systèmes d’exploitation grâce à (liste non exhaustive) : la taille de la fenêtre, TTL, les flags ou même les options contenues dans l’entête (avec p0f notamment <3. Il faut pour cela que l’hôte distant se connecte à un serveur dont l’attaquant possède les droits dessus (compromis ou pas, au bon vouloir de l’attaquant) ou qu’il sniffe la connexion entre deux systèmes (donc doit être déjà présent sur un réseau).

Nous pouvons aussi réaliser le fingerprinting passif grâce aux numéros de séquence (pseudo aléatoires) contenus dans les entêtes des paquets TCP-IP. Du fait de leur randomisation non parfaite, chaque système possède sa propre « empreinte ISN » pouvant être comparable dans le temps avec d’autres empreintes ISN. Ce type de fingerprinting est très bien documenté par son créateur sur ce site internet [3]). Cette technique possède cependant des limites. Ainsi il faut un grand nombre de paquets échangés afin de posséder une bonne empreinte permettant de déterminer quel est le système distant. En outre les systèmes actuels s’orientent vers une randomisation plus fiable. Cependant, sa mise en place peut être utilisée pour déterminer le nombre de serveurs derrière un load-balancer (avec ISNprober notamment). – Ci dessous, un fingerprinting des ISN générées par Windows XP (voir [3]) :

Un « troisième type », encore plus « rock’n’rool » et beaucoup moins « matheu » peut permettre la prise d’empreinte d’un système utilisé en regardant simplement les META-DONNES des fichiers déposés sur des serveurs web ou envoyés directement par l’entité par le biais de simples emails. Ainsi, certaines applications trop bruyantes laissent des infos pouvant permettre à un attaquant de déterminer le système cible (grâce à des full path, les applications etc. contenus dans les fichiers) et les versions (les paths users diffèrent par exemple d’un WinXP à un Vista) des programmes spécialisés permettent de récupérer ses informations juteuses telles que Metagoofil (par le biais de Google) ou des fois un bon éditeur full-text fera l’affaire. Certaines informations dépassent totalement le cadre du simple fingerprinting système mais sont croustillantes à souhait (noms d’utilisateurs, paths, applications utilisées avec leur version etc.).

Cependant, pour cette dernière, il faut absolument que le fichier ai été modifié ou créé sur le poste (ou le domaine si utilisateurs) que l’attaquant veut « visiter ». Donc en d’autres termes, c’est bien pour se renseigner sur des hôtes de (sous)-réseaux d’entreprises et les logiciels employés (quoi ? le service de com’ utilise semble-t-il une version vulnérable d’OpenOffice ?), cependant, dans le cadre d’un bastion, cela ne servira totalement à rien… après tout, c’est logique. (Note : Regarder les META des communiqués de presse et etc. sur les sites institutionnels des entreprises ;)

Peut-on se protéger contre le fingerprinting ?

Comme toujours, la sécurité d’un bastion ou d’une station en particulier est beaucoup plus facile à mettre en œuvre que la sécurité d’un système d’information composée de plusieurs hôtes, réseaux, sous-réseaux, serveurs etc… Je vais vous présenter quelques pistes pour sécuriser ce petit monde, cependant, il vous faudra poursuivre par vous-même la sécurisation de vos équipements, car comme dirait papy geek « Read that fu*king manual ».

Protection des services

Ainsi, pour bien protéger les services, il faut faire taire ses applications, la plupart des services http, ftp, ssh ou autres possèdent leurs propres directives à changer dans les fichiers de configuration des services afin de réduire le bruit émi et la possibilité de reconnaissance de services à distance. On essayera de réduire un max les infos, essayant de ne plus rien divulger.

Cependant, certains services laissent encore le nom du service tout en rendant invisible sa version (c’est le cas d’Apache par exemple ou il faut aller voir dans le apache2.conf et mettre ServerTokens sur Prod – et ne pas oublier par la même occasion ServerSignature sur off ;). En ce qui concerne IIS (éh oui…) il faut simplement valeur de registre DisableServerHeader à cette adresse HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters et hop, plus de signature. Et pour finir, autant faire ça pour Nginx où la manœuvre est un peu plus complexe. Pour cela, DIY dans le code source en éditant les constantes de version dans les fichiers src/core/nginx.h & src/http/modules/perl/nginx.pm et enfin, en re-compilant le tout. Dans le cas d’autres services c’est à peu prêt les mêmes méthodes, pour savoir comment faire, il vous suffit de faire un simple « [nom du service] disable server signature » ou même « [nom du service] disable welcome message » dans google pour avoir des réponses à vos questions :)

En ce qui concerne la protection de WAF, à ce que j’ai pu lire sur ce site, que nous pouvons facilement protéger mod_security en customisant les réponses du firewall suite à certaines requêtes ou en changeant simplement la signature du serveur apache (dans les headers HTTP) en utilisant l’option SecServerSignature dans la configuration de mod_security (contenue dans apache2.conf) (voir ici). Je n’ai jamais utilisé d’autres WAF donc l’aide sera limitée à cela.

Protection des bastions & hôtes

En ce qui concerne les scans liés au SI (hosts, bastions, firewalls, passerelles etc.) beaucoup de logiciels ont étés développés il y a quelques années afin de limiter les tentatives de fingerprinting de stations comme IPpersonnality ou Fingerprint Fucker patchant le kernel afin de modifier la pile TCP/IP des systèmes Linux pour se faire passer pour d’autres systèmes ou périphériques réseaux. Aujourd’hui est développé IPMorph permettant là aussi d’obfusquer le système d’exploitation réel et de le faire passer pour un autre (plus que prometteur car permettant de tromper des logiciels de fingerprinting actifs et passifs tels que Nmap, p0f, Xprobe2, ou même SinFP). Vous trouverez une bonne documentation technique sur le site du SSTIC’09 ICI. Je ne l’ai pas encore utilisé/testé mais j’ai vraiment hâte à la suite de cette lecture :)

Concernant le réseau, un attaquant peut s’amuser aussi à déterminé l’architecture interne de ce dernier de façon très superficielle (os et équipements) à l’aide des TTL des paquets. Effectivement, certains équipements réseaux décrémentent les TTL lors du passage d’un paquet. Il est donc bon de rétablir à une valeur par défaut le champ TTL des paquets sortant du réseau. Pour cela, il existe des options pour IPtables.

Je ne sais pas si PF le fait (sale inculte – je connais que la limitation de TTL de PF), cependant, il est fort probable que comme IpTables nous pouvons le faire en cherchant un peu dans les mailinglists ou docs de PF. En ce qui concerne les autres Firewalls, à vous de voir, je ne pourrai pas trop vous aider. On peut également aller voir dans /proc/sys/net/ipv4/ip_default_ttl pour Linux et je ne sais plus quelle clé de registre pour Windows.

Ensuite, pour le reste, libre à vous pour ce qui est de la configuration des firewalls pour laisser passer certains paquets (ICMP etc.) ou non dans vos DMZ, réseaux internes etc. Je ne vais pas rentrer dans ce débat troolesque à souhait aujourd’hui.

Conclusion

Le procédé fingerprinting système/réseau est une science où chaque système/réseau possède ses particularités. Aujourd’hui, les principales attaques possèdent des contre-mesures pouvant être mises en place plus ou moins facilement par rapport à l’architecture du SI associé.

Cependant, il faut trouver comme toujours le juste milieu entre la sécurité voulue, le coup de mise en place de cette dernière et l’importance des données contenues dans le systèmes pouvant être la cible d’une tentative d’attaque (qu’elle soit bien évidement interne à l’entité ou externe.).

[1] SHODAN : Le grand jeu aujourd’hui est de trouver des tips&tricks sur Shodan shells disants ouverts (root ou non), serveurs vulnérables ou déjà compromis etc.

[2] PING/TTL : Un simple tracereoute ou un ping et roule ma poule. (Dans le cadre d’un bastion avec les requêtes ICMP vers ce dernier non dropées par un éventuel firewall.)

[3] Strange Attractors and TCP/IP Sequence Number Analysis

[4] Voir les champs /Producer /Creator et /CreationDate afin d’être sur que le PDF publié est récent, cependant, certains sont encodés demandant l’ouverture par Adobe AR ou tout autre logiciel lisant les « entêtes » des PDF.