Être hacker, ce n'est pas comme dans les films!

Les hackers… nous en voyons souvent dans les films et séries. Ces experts sont capables de détourner des satellites de la NSA avec une ficelle et un coupe-ongles (#MacGyver) ! (Image de couverture tirée du film Die hard 4)

J’ai décidé aujourd’hui de vous parler du hacking dans la "vraie vie". Je me considère moi-même comme un white hat (un hacker éthique) et je vais vous parler des méthodes courantes qu’un hacker utilise. Je me focaliserais ici sur la partie la plus simple : les sites web.

Spoiler alert : vous risquez d’être déçus, beaucoup de méthodes sont très simples.

Hacker, pour quoi faire ?

Avant de parler de méthode et vecteur d’attaque, la bonne question est de savoir pourquoi pirater?

Pour répondre à cette question, il y a de mon point de vue 2 facettes d’une même pièce à prendre en compte, les deux types de hackers.

Le white hat va tenter de trouver une faille pour la signaler. Oui, mais pourquoi la signaler ?

• Par conviction, personnellement j’ai déjà remonté des failles majeures de sécurité par altruisme, je suis pour un web plus sûr pour tous
• Parce qu’il participe à des bug bounty et recevra donc une récompense pour avoir signalé une faille (sous respect de certains critères, comme la non-divulgation sous x jours)
• Par défi, je suis aussi dans ce cas, le défi de casser, de contourner les sécurités. Le plaisir de résoudre des puzzles plus ou moins complexes

Le black hat, au contraire, lui va essayer de tirer profit de sa faille. Il existe pour ça plusieurs solutions :

• Extraire des informations et les revendre sur le marché noir, à titre d’exemple, un contact enrichi (adresse mail, mot de passe, numéro de téléphone, nom et prénom) peut se vendre quelque centimes. En prenant en compte que beaucoup de sites ont des milliers, voire des millions de contacts dans leur base, le prix monte vite
• Vendre des informations confidentielles ou des secrets industriels
• Vendre des informations de carte de crédit/PayPal, etc…
• Rendre indisponible un site. Certains proposent du DDOS "as a service", permettant par exemple de mettre hors service temporairement un concurrent pour le décrédibiliser
• Demander une rançon après avoir chiffré l’ensemble des données d’une entreprise ou d’un particulier
• Faire de la machine un zombie, utilisé dans un botnet ou pour de l’hameçonnage par mail.

Le but de cet article n’est pas d’être exhaustif, mais de vous indiquer les raisons principales.

Observer pour mieux casser

On parle souvent des hacks incroyables, mais on oublie souvent de parler des piratages plus basiques. J’ai eu l’occasion de passer la sécurité de certains sites web simplement en étant observateur. À titre d’exemple, dernièrement j’ai réussi à accéder à des données très sensibles sur un site web simplement à cause d’un souci d’affichage.

En effet, l’une des images s’était mal chargée, et j’ai eu le réflexe du bon vieux CTRL+U (Affichage de la source) !

Quelle ne fut pas ma surprise lorsque j’ai vu des erreurs PHP, dont le rendu HTML avait été masqué... Puis en remontant ces erreurs, j’ai découvert un module de debug activé sur cet environnement de production.

Via ce module de debug, j’ai pu remonter aux fichiers de configuration du site, dans lesquels il y avait les chaines de connexions aux bases de données, les informations de connexion aux serveurs FTP et bien d’autres informations, y compris des informations confidentielles.

Ceci n’est qu’un exemple, mais sachez qu’il y a beaucoup de cas dans ce genre. Observer le code source ou le comportement d’un site donne des indices sur la manière d’altérer son fonctionnement. Il est aussi possible d’observer le comportement de l’application en utilisant les outils de développement (F12). Ce qui permet d'observer les appels de type XHR, qui correspondent souvent à des appels APIs, lorsque ces derniers ne sont pas suffisamment protégés. Il est parfois possible de leur faire afficher des données d’autres clients ou des informations censées être protégées.

Dans une de mes précédentes missions, j’avais mis le doigt sur une anomalie de sécurité de ce type, en modifiant un appel API, j’arrivais à accéder à l’ensemble des informations de tous les clients enregistrés dans la base (on parlait de plusieurs millions de clients dans ce cas). Fort heureusement, j’avais identifié ce bug sur un environnement de préproduction, et le bug a été corrigé avant son passage en production.

Beaucoup de hacking se font en fait par simple opportunisme, simplement car une faille était visible. L’attaque de surface reste la méthode la plus courante !

La connaissance c’est le pouvoir

Observer, c’est bien, connaître c’est tout aussi utile. Connaître passe par plusieurs choses :

• Connaître la cible : être capable d’identifier le CMS utilisé par exemple ou le type de serveur qui permet de faire fonctionner le site
• Connaître les failles communes
• Certains vecteurs d’attaques communs : XHR, SQL Injection, etc.

Pourquoi est-ce important ? À titre de démonstration, si je veux tenter de brute force un site, savoir si je suis sur un CMS de type WordPress ou Drupal change beaucoup la donne, je ne vais pas attaquer les deux de la même manière.

De plus, je vais essayer de chercher les derniers correctifs de sécurité pour m’attaquer à ce qu’ils corrigent. En production, il est courant que les serveurs ne soient pas mis à jour dès qu’un correctif sort (sauf gros correctif de sécurité annoncé par l’éditeur auparavant).

De la même manière, savoir qu’un serveur tourne sur une version obsolète d’Apache HTTPD (par exemple une fois de plus) me permet de savoir comment je peux le compromettre pour potentiellement en prendre le contrôle.

Dans le monde du hacking, faire de la veille technologique est indispensable. Il faut se tenir au courant des dernières failles majeures, des dernières méthodes, et des techniques les plus courantes.

À titre d’exemple, dernièrement Amazon a essuyé une attaque de plusieurs Tb par seconde. Tout le monde s’est focalisé sur le volume, pourtant à l’échelle d’AWS, c’est un grain de sable. Ce qui est intéressant, c’est de comprendre le vecteur d’attaque : l’UDP reflecting. En effet, savoir comment quelqu’un a généré une telle bande passante est bien plus utile qu’un volume "putaclic".

Le bon outil pour la bonne attaque

Je ne vais bien sûr pas exposer ici tous les outils pour faire de l’attaque, ce n’est pas but, je vais simplement parler des outils communs que l’on peut utiliser assez facilement.

Détection des CMS/solutions utilisées

Je parlerais déjà de l’extension Wappalyzer. Cette extension de navigateur permet d’avoir en un coup d’œil beaucoup d’information, simplement en se basant sur les entêtes et la présence de certains fichiers clés. Voici un exemple sur ce site :

Préparer son attaque

Ici, je vois le maître incontesté, j’ai nommé le seul, l’unique, le grand MetaSploit. Ce programme, utilisable gratuitement, permet d’exploiter des payloads ou de créer les siens pour exploiter des failles connues. Un article de prise en main de l’outil arrivera bientôt sur ce blog !

Être le moins visible sur Internet

Je pense que tout le monde s’y attend, mais pour moi, je vois difficilement plus efficace que Tor pour ce point. Pourquoi Tor plutôt que du VPN ? La plupart des fournisseurs VPN enregistrent votre activité, et même s’il vous vend le fait qu’il ne le fait pas, vous ne pouvez jamais en être sûr à 100%.

Concernant Tor, il y a pour moi des alternatives fiables :

• Tor browser: le navigateur Tor officiel, basé sur Firefox
• Brave : Le navigateur orienté vie privée, qui a un mode Tor (solution que j’utilise personnellement)

Il faut prendre en compte que Tor est bloqué automatiquement sur certains sites, tout comme les VPN.

Analyse du comportement réseau

Analyser le comportement réseau peut aussi être une bonne approche, pour cela, l’outil le plus adapté est à mon sens le combo TCPDump/WireShark. Sur Windows, on pourra exploiter netsh ou les powertools de Microsoft.

L’intérêt dans ce genre de cas peut être de voir avec quel serveur on communique, quelles informations on envoie et l’on reçoit et suivant quel protocole.

Avoir un OS "boite à outils"

Pour les fainéants (comme je le suis), il est aussi possible d'exploiter directement un OS. Je vois deux candidats ici :

Kali Linux : L'OS basé sur Debian est reconnu dans la communauté de la cybersécurité, le modèle "by offensive security" n'a plus rien à prouver. Il a l'avantage de jouir d'une grosse communauté de passionnés qui l'alimente et mettent beaucoup de tutoriels autour de ce dernier. Pour ma part, c'est mon Linux principal.

Parrot Linux : Distribution basée aussi sur Debian. Cette distribution possède les mêmes avantages que Kali, un packaging tout prêt, une forte communauté. Je trouve juste que la communauté autour de produit est un peu moins présente (mais c'est simplement mon point de vue, je peux me tromper).

À noter que les deux Linux cités ci-dessus ont à peu près le même âge. Ils ont tous deux été lancés en 2013.

Des attaquants partout, que faire ?

Je l'ai déjà dit à plusieurs reprise lors de mes missions, quand on me demande comment éviter de se faire attaquer, la réponse est simple : c'est impossible !

Internet, c'est la jungle, on n'y peut pas grand-chose.

La meilleure solution reste la surveillance et la réactivité. Il faut garder en tête que des black hats vont souvent rester discrets jusqu'au moment où ils pourront lancer leurs attaques, ils peuvent attendre des mois avant de se montrer. Le but est dans ce cas d'accumuler le plus d'information, ou de s'infiltrer au plus loin dans le système d'information.

De même, beaucoup d'attaquants ne vont pas lancer une attaque à 3 Gb/seconde, ce qui n'aurait d'intérêt que d'être très visible.

Du coup, que fait-on ? Personnellement, je vois 3 axes :

• Métrologie et supervision : superviser finement une infrastructure de production est indispensable, cela permet de détecter les comportements anormaux, plus on a d'information et de recul, plus on détecte aisément les schémas qui sortent de la normale.
• Auditer régulièrement les applications : sur ce point, je ne parle pas forcément de faire appel à une société externe pour auditer la sécurité, mais plutôt d'auditer vous-même les autorisations, les flux ouverts d'une application. Est-ce qu'il est toujours nécessaire que mon application A accède à l'application B ? Est-ce qu'elle a besoin d'avoir autant d'accès, voir quand ont été faits les derniers usages, etc...
• Tester autant que possible : J'en ai déjà parlé sur ce blog, le DevSecOps doit devenir la base de vos applications, tester la sécurité dès le développement de votre application est indispensable.

Le plus compliqué restera toujours de détecter les signaux faibles, c'est-à-dire les attaques discrètes. J'ai 2 exemples en tête sur ce sujet :

• Une attaque "brute force" sur un ADFS, via un réseau botnet, qui faisait 5 tentatives par minutes, donc perdu dans le flux "normal" de plusieurs centaines voire milliers de connexions sur le même intervalle
• Une machine compromise qui était infectée par un cryptomineur, qui minait du Bitcoin en exploitant 10% du CPU

Il est aussi possible de s'équiper en conséquence. Sur AWS, le service GuardDuty fait un excellent travail pour détecter ce type de comportement.

Comme dit plus tôt, un attaquant malveillant essaiera toujours d'être le plus discret possible.

Payer les rançons ou non ?

Dernièrement, une attaque par ransomware à fait parlé d'elle. Garmin a en effet été la cible d'un cryptolocker et a été immobilisé pendant plus de 10 jours. Il semblerait que l'entreprise ait en fin de compte décidé de payer la rançon.

10.000.000 de dollars, voilà le prix de la rançon… Tout comme l'histoire du débit, le montant est anecdotique pour une entreprise de la taille de Garmin.

Pourtant, de mon point de vue, payer une rançon est toujours une mauvaise idée :

• Nous parlons de pirates informatiques, ils n'ont absolument aucune obligation de débloquer les données
• Si aujourd'hui Garmin a décidé de payer, qu'est-ce qui empêche une autre entreprise de le faire
• Il est possible qu'une autre backdoor soit présente dans le système et reverrouille l'entreprise dans quelques mois
• Payer encourage ces attaques, car cela envoie un signal qui laisse croire que c'est une méthode efficace pour se faire de l'argent

Pour conclure ce long article…

Plutôt qu'une conclusion aussi longue que cet article, je vous propose des bullets points sur les fausses idées reçues à cause du cinéma sur le hacking :

• Les hackers n'ont pas besoin 15 écrans et 8 ordinateurs
• Les hackers piratent très rarement depuis le mobile, au mieux il est utilisé en tant que vecteur d'attaque
• Pirater un système ne se fait pas en quelques secondes (sauf dans certains cas bien particuliers), et prends parfois plusieurs semaines ou mois
• Le hacking social est aussi une porte d'entrée de plus en plus courante, j'en avais d'ailleurs parlé par le passé
• Dans les films et séries, le hacking est souvent utilisé en Deus Ex Machina pour ne pas avoir à gérer une histoire trop compliquée, l'informatique est souvent vue comme une finalité et non un outil
• La plupart des films et séries qui ont des scènes de hacking me font souvent rire (mis à part Mr Robot qui est diablement réaliste)
• Je ne m'habille pas avec un hoodie à capuche pour hacker des systèmes
• Les hackers ne sont pas tous des parias du système et beaucoup passent inaperçus, ils ont juste décidé de jouer avec leurs règles sur Internet

Si vous voulez vous entrainer sans risques (et sans risque de prison), je ne peux que vous recommander l'excellent hackthebox qui vous permettra de mettre à profit vos compétences et aiguiser vos talents de hacker. Ce site met à disposition des environnements de type "bac à sable" à hacker. À noter qu'il vous faudra "hacker" le site pour pouvoir vous créer un compte.