WEBlog de Félix Aimé

Depuis ce matin, tout le monde en parle, le Ministère de l’économie, des finances et de l’industrie a été sujet à une vaste campagne de piratage informatique ciblant – semble-t-il – des informations confidentielles liées à la présidence de la France au G20. Beaucoup de personnes – y compris moi – voient déjà la Chine comme commanditaire de cette nouvelle campagne de piratage. Revenons-donc à ce que l’on sait et ce que l’on peut déduire.

Une campagne de spear-phishing

Une campagne de spear-phishing – semble-t-il très ciblée – a été perpétrée à l’encontre de certains fonctionnaires du Ministère de l’économie, des finances et de l’industrie. Le spear-phishing est un phishing ciblé, où, contrairement à une campagne de phishing traditionnel, un travail de renseignement est fait en amont afin de connaitre sa victime, mais aussi ses liens avec d’autres acteurs de l’entité ciblée. Elle se traduit au final par l’envoi de mail(s) possédant(s) une pièce jointe ou un lien vers une page web exploitant une vulnérabilité dans le navigateur ou un des plugins du navigateur de la victime. Les campagnes de spear-phishing se décomposent en deux phases distinctes :

1. Le Renseignement : La partie la plus complexe. Il faut connaitre sa victime, dont ses liens avec d’autres acteurs du système d’information mais également son équipement logiciel. A ce jour, les liens peuvent facilement être découverts en cherchant un peu sur internet, surtout grâce aux réseaux sociaux et aux sites institutionnels (d’où l’utilité de Maltego). L’adresse email de la victime à laquelle on enverra une charge finale peut facilement être déduite grâce au nom et prénom de l’acteur. C’est toujours le même pattern du type nom.prenom ou nprenom ou prenom.nom etc. Une liste d’adresses email valides peut ainsi être facilement constituée automatiquement à l’aide d’un seul échantillon récupéré sur un site institutionnel ou dans un document administratif.

L’équipement logiciel de la victime pourra être soustrait grâce à la visite au préalable d’un des acteurs du Système d’Information sur un site internet piégé. Un petit bout de code Javascript permettra de récupérer les versions des différents plugins installés, du navigateur et du système d’exploitation. Pour les logiciels de bureautique (tels qu’MS Office), une simple visite sur le site institutionnel permettra au(x) pirates(s) de connaitre, à l’aide des méta données des documents publiés, le type et la version des logiciels utilisés (Foca, Metagoofil).

2. L’attaque : L’attaque prendra donc la forme d’un email piégé usurpant l’identité de l’un ou de plusieurs collaborateurs de la victime. Du fait des faiblesses du protocole d’envoi de mail SMTP, il est très facile d’envoyer un mail usurpant l’identité d’une personne quelconque. Cet email conduira la victime – à l’aide d’un prétexte quelconque – à ouvrir une pièce jointe piégée (un fichier PDF semble-t-il dans le cadre de l’attaque de Bercy) ou à parcourir un lien contenu dans l’email.

Une fois ce lien ou cette pièce jointe ouverte, une faille logicielle sera utilisée afin de faire exécuter du code arbitraire à distance sur l’ordinateur de la victime. Aujourd’hui, les shellcodes de papa ne sont plus utilisés. Dans le cadre de telles attaques, les shellcodes permettent de télécharger et d’exécuter un binaire (le malware). Une fois installé sur le client (l’ordinateur de la victime), le malware essayera d’être furtif afin de ne pas se faire voir par l’analyse heuristique des antivirus, mais également persistant, afin d’être exécuté à chaque redémarrage de l’ordinateur de la victime. Enfin, il enverra un petit message à un serveur sur internet (contournant le NAT en passant) pour dire « Hep, j’suis installé, j’attends tes commandes bro :D ! »

Afin d’éviter un piège, la première règle est d’en connaitre l’existence.

Les attaques de spear-phishing sont aujourd’hui celles qui ont le plus de chances de réussir en remote (à distance). De plus, même s’il existe des parades afin de contrer ce type d’attaque (comparaison entre le domaine auquel est rattachée l’adresse email usurpée et le serveur SMTP ayant envoyé l’email, créations de profils « honey-pots » ayant des adresses mail institutionnelles « honey pot », utilisation de signatures numériques) ces mesures sont loin d’être démocratisées, tant dans le public que dans le privé.

Nous n’avons aucune information sur le malware employé, si c’est du « home made » ou quelque chose que l’on trouve un peu partout sur internet (comme GhostRAT dans le cadre de GhostNet). Toujours est-il que là encore, la sécurité antivirale est un échec. La seule chose qui a fuité est la communication du malware par HTTP vers l’extérieur [NOTE 1]. Ce type de communication est aujourd’hui très démocratisé par les malwares car cela permet facilement de s’évader du réseau, tout en contournant les règles des firewalls laissant sortir les flux HTTP. Les NIDS dans ce cas ne jouent plus aucun rôle – ils fonctionnent principalement sur la base de signatures ou sur des données heuristiques (pour les scans de ports, le DNS tunneling, malwares « connus » etc.). Sachant que le flux employé était un flux « légitime » et n’ayant pas de signatures préalables, le malware pouvait communiquer avec l’extérieur tranquillement sans se faire voir.

Quelle portée de l’attaque contre Bercy ?

Jusqu’à présent, aucune information n’a fuité sur la portée réelle de l’attaque, notamment sur sa complexité. Une attaque de spear-phishing, bien que semblant complexe, est simple à mettre en oeuvre. Pour connaitre la réelle complexité de l’attaque, il nous faut savoir si les pirates informatiques ont pivoté sur d’autres postes/serveurs composant le Système d’Information de Bercy à partir « de bases avancées » composées des postes clients piratés lors de l’attaque de spear-phishing. Là, on pourra dire « woot, woot, woot » car pivoter sur un réseau est une tâche relativement complexe de l’extérieur, surtout sans se faire catcher par les NIDS.

De plus, certains indices peuvent nous amener à penser qu’un 0day sur Adobe Acrobat reader a été utilisé, même si le sujet, repris par certains médias [NOTE 2], reste très nébuleux : ne sachant pas s’ils parlaient du malware non reconnu par l’antivirus du Ministère de l’économie, des finances et de l’industrie ou de la faille utilisée permettant l’exécution de code arbitraire à distance.

Qui est derrière cette campagne ?

Les médias ne nous apportent rien sur l’origine de l’attaque, seul un indice est sorti : le(s) malware(s) communiquai(en)t avec des serveurs présents en chine. OK. Wahou, ça c’est de l’information. Enfin, il est aujourd’hui facile de mettre en oeuvre un système de proxying-international-de-la-mort-qui-tue afin de cacher la provenance d’une attaque. (Shodan, my friend, si tu m’entends ? <3)

Ma petite idée s’oriente tout de même vers la superbe PLA chinoise (désolé pour l’humour, voir : 人民解放军) et ses supers-hackers-qui-font-peur. Ceci pour la simple et bonne raison que des attaques d’espionnage de grande envergure utilisant cette technique (GhostNet & Aurora) ont été imputées aux chinois et à certaines de leurs universités. Cependant, seule une analyse par reverse engineering du malware et de(s) l’exploit(s) utilisé(s), mais aussi une coopération internationale avec la Chine (LOL) et le Canada (qui a été victime d’une campagne de spear-phishing similaire) pourra permettre d’y voir plus clair.

D’autres voix s’orientent vers les Anonymous ou un cyber-altermodialisme, là, je dis « AH AH » et vous orriente vers mon article sur la « cyberguerre » pour mieux comprendre ma réaction.

Quelques leçons à retenir

Bref, je ne vais pas faire dans la « conclusion kévin » simplifiant la vie à beaucoup de personnes du genre « aucun système n’est inviolable *FEAR* ». Non non, nous allons aller plus loin. Le premier enseignement à tirer de cette attaque c’est que les systèmes d’information sont encore trop parlants sur leurs équipements. Une simple désactivation du Javascript et une réécriture de l’user-agent à la volée par un proxy intermédiaire peut permettre d’éviter bien des soucis. Cependant, on ne vit pas au pays des bisousnours : ce type de protection est difficilement portable sur un SI composé de milliers d’hôtes[NOTE 3] ayant des besoins de compatibilité logicielle (qui a parlé des intranets développés pour IE6 ?).

Deuxième leçon : Encore beaucoup trop de SI ne sont pas équipés de solutions logicielles contre le spear-phishing telles que la mise en place d’un système de PKI (difficile à garder à jour) ou une vérification de l’appartenance d’une adresse email au domaine auquel est rattaché le serveur d’envoi. Toutefois, des solutions existent, tant open-source que propriétaires rattachées aux serveurs mail.

Troisième leçon (pour les rageux) : On ne peut pas jeter la pierre sur les équipes de l’ANSSI ou de la DCRI. Les mesures qui ont été prises suite à la découverte de l’attaque ont été appropriées à l’envergure de cette dernière. Ces dernières ont d’ailleurs – semble-t-il – envoyé de fausses informations aux serveurs de contrôles, permettant de noyer les vraies informations dans de fausses informations et ça, c’est loin d’être con. Enfin, la discrétion de cette opération est à applaudir, sachant que la découverte de l’attaque remonte à quelques mois. Cela prouve une réelle intégrité de nos services de renseignement.

Cette attaque, une opportunité pour la France ?

Cette attaque, tout en ayant démontré encore une fois la vulnérabilité des Systèmes d’Information français, peut être une véritable opportunité pour la France. La prise de conscience dans les hautes sphères du gouvernement de la vulnérabilité du système va permettre de remuer un peu le secteur, avec la mise en place de VRAIES mesures rapidement face à ce type d’attaques. Enfin, je parlerai de ce point là dans mon deuxième article consacré à la « cyber-guerre » (un mot qui n’est pas approprié pour ce genre d’attaque, on parlera plus de cyber-espionnage ou de campagne espionnage), portant pour la prochaine fois sur les doctrines et stratégiques à mettre en oeuvre par les Etats face aux attaques émanant du cyberespace.

Mise à jour au 08/03/2011 : Un article de l’ANSSI confirme que les assaillants ont bien utilisé un 0 day dans Adobe Acrobat Reader, d’ailleurs, un avis du CERTA a été émis début février concernant plusieurs vulnérabilités sur ce même logiciel. Ce même article confirme également un pivot sur le réseau, cependant aucune mention sur la technique utilisée est présente.

Un article du site SecurityVibes nous en apprend un peu plus. Afin d’élever leurs privilèges sur les machines – permettant de pivoter sur le(s) réseau(x), les pirates auraient utilisé des vulnérabilités dans des programmes ayant des privilèges administrateurs pendant leur exécution ou réécrit des scripts exécutés en tant que SYSTEM. Ces astuces sont vielles comme le monde mais toujours d’actualité dans beaucoup de réseaux. Elles permettent même, dans certains cas, d’élever ses privilèges verticalement sur l’Active Directory d’une l’entité. Méfiez-vous des scripts bat/vbs traînant sur les partages réseaux qui sont exécutés en tâche planifiée avec un niveau de privilèges administrateur alors que tout le monde peut les rééditer…

Enfin, il est fait allusion à la problématique des SIEM et de la remontée de certains évènements réseaux. En effet, l’attaque aurait pu être décelée peut être plus rapidement avec un système de SIEM relié à des (H/K)IDS. Restera la problématique des fameux faux positifs.

Mise à jour au 09/03/2011 : Un article d’un célèbre site internet français sur la sécurité informatique revient sur une tentative d’attaque par injection d’iframes sur le site internet de Reporters Sans Frontières, faisant beaucoup trop vite une possible liaison avec l’affaire de Bercy. Cette attaque est, contrairement à ce qui a été annoncé dans l’article, d’une toute autre mesure et ne visant pas le réseau interne de RSF. De plus, l’injection d’iframes sur le site de RSF cible les visiteurs du site et non pas l’organisation en elle-même. Le RAT diffusé par le site internet est PoisonIvy, un RAT très connu et plus maintenu par son auteur (dont son C&C est d’ailleurs faillible à un RCE).

Bien que cette attaque aie comme origine, semble-t-il, la Chine, sa très faible complexité et son amateurisme (l’utilisation de PoisonIvy) peut laisser penser à un piratage occasionnel contre les visiteurs du site internet d’RSF. Pour finir, ce n’est pas la première fois que le site internet d’RSF sert de pont à un exploit kit suite à un piratage. Il ne faut pas faire des liens entre des affaires là où il n’y en a aucun.

Mise à jour au 10/03/2011 : Selon le magazine Paris Match, la campagne de Spear Phishing serait très aboutie dans la pertinence des messages envoyés aux acteurs ciblés. Ils auraient envoyé des emails en lien à différentes réunions préparatoires au G20, ce qui peut laisser présager une taupe en interne ou une fuite d’information liée à une première attaque aboutie sur un des acteurs.

Cependant, le message indiqué dans l’article – « Vous trouverez en pièce jointe un document pour préparer la ­prochaine réunion » – est souvent utilisé dans les campagnes de Spear Phishing ou de Social Engineering à l’encontre d’entités car les réunions sont fréquentes en entreprise ou dans l’administration. Donc sans posséder plus d’informations sur ce message, nous ne pouvons pas savoir si la campagne de Spear Phishing était réellement aboutie (date/heure de la réunion, objectifs de la réunion indiqués dans le message etc.).

Mise à jour au 20/03/2011 : Quelques informations supplémentaires tirées de conférences et contacts : 1. Le malware utilisé n’a semble-t-il pas été drafté pour une attaque « one-shoot », mais était déjà existant, il a subi néanmoins quelques modifications propres à l’attaque. 2. L’ANSSI n’avait semble-t-il pas objectif de communiquer sur l’affaire. Cette affaire aurait fuité à partir de Bercy, dont les employés avaient été amenés à laisser leurs ordinateurs portables au bureau le temps d’un weekend.

Une émission de France O revient sur les attaques informationnelles avec quelques spécialistes en Intelligence Economique et cyber-criminalité. L’émission est assez bien, cependant beaucoup d’éléments techniques mis en avant sont faux et pas métrisés. (Le tout est à découvrir ici)

NOTE 1 : « On a constaté qu’un certain nombre d’informations étaient redirigées vers des sites chinois. Mais cela ne veut pas dire grand-chose » (Paris Match)

NOTE 2,3 : Dominique Lamiot : « le Cheval de Troie est arrivé via une pièce jointe PDF dans un e-mail. Il s’agit d’une faille encore non détectée par les éditeurs » [...] « Au total, 150 ordinateurs sur 170.000 postes ont été infectés » (Le nouvel Obs)

C’est après avoir effectué le dernier Network Forensics Puzzle Contest (qui d’ailleurs possède un niveau très bas pour ce contest « Ann’s AppleTV »), que j’ai parcouru le site internet afin de voir les différents tools inventés par les challengers dans le but de parser les échantillons de données réseau pcap afin de répondre aux questions des challenges.

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.

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.