Avant de s'attaquer à d'autres sujets, je pense qu'il est intéressant de parler des différents types de mission que nous effectuons. Celà peut permettre aux "non-pentesters" de cerner un peu mieux notre job! On distingue donc plusieurs catégories de tests d'intrusion. Dans ce premier billet, je vais vous parler des tests "infra".

Grosso modo, il s'agit de tester l'infrastructure du client. Les tests se déroulent généralement depuis Internet (depuis la boîte de sécu). On regarde ce qu'un éventuel pirate pourrait faire aux systèmes du client depuis son shell au brésil ;)

Pour ce type de tests, la quantité d'adresse IP à pentester varie énormément : de quelques adresses IP à plusieurs classes C. En général, pour une moyenne entreprise on tourne souvent autour d'une vingtaine de machines (up) à tester, pour un grand compte autour d'une bonne centaine.

Le nombre de jours vendus quant à lui ne varie jamais (ou très peu) ... C'est de l'ordre d'une à deux semaines, rédaction du rapport comprise. Autant vous dire que quand vous avez 100 IP, la qualité du rapport est souvent... médiocre car le travail est baclé. Enfin ça n'engage que moi.

Revenons à nos moutons, ces tests d'intrusion ne demandent pas de compétences techniques importantes. Il suffit de savoir se servir d'outils comme whois / tcptraceroute / hping / nmap / sinfp / xprobe / nc / telnet / nessus ... La plupart de ces pentests sont donc donnés aux petits jeunes qui débutent ;-)

Niveau méthologie c'est du classique. Plusieurs étapes se chevauchent donc il n'y a pas vraiment d'ordre à suivre mais plutôt des grandes lignes à se fixer :

  • Vérification de la plage auditée à coup 'whois',
  • Découverte du réseau (Ex : ping, dig, (tcp)traceroute, hping3, nmap ...),
  • Découverte des systèmes d'exploitation (Ex : SinFP, nmap, xprobe),
  • Découverte des ports / services (Ex : nmap, amap, synscan, portbunny),
  • Identification des services & découverte des versions (Ex : nmap, amap, requêtes manuelles).

Une fois ces étapes validées, on fait plaisir au client (uniquement au client) en lui faisant un joli schéma visio récapitulatif. On passe ensuite à l'étape "recherche de vulnérabilités".

Les pentesters utilisent alors des scanners automatiques comme le fameux nessus. Nessus va faire toute une série de tests système et remonter les vulnérabilités CVE qu'il a identifiées ... On lance donc ça rapidement en désactivant les tests dangereux (type dénis de service), puis on attend le joli rapport. Le pentester en valide le contenu en dégageant les faux positifs et les vulnérabilités à la con.

Une fois cette partie finie, on passe à l'audit manuel. On essaye généralement de répondre à quelques questions relativement basiques ...

  • Est ce que le système est à jour?

- Bouh j'espère qu'on a pas un vieux serveur tout pourri à poil sur le net...

  • Est ce qu'il n'y a pas des services à la con qui tournent sur le système?

- Bouh tu a laissé finger sur ton vieux solarisl!
- Encore à telnet? Faut évoluer mon pote!

  • Est ce que les services sont correctements mis à jour?

- Apache 1.3.26! Pwet!

  • Est ce que les services sont correctements configurés?

Tu as pas réussi à configurer ton snmp, tu as une communauté 'public' / 'private'?
SSLCipherSuite HIGH ça existe!

  • Est ce qu'il n'y a pas de mots de passe par défaut qui traine quelque part.

Oulalala, tu as mot de passe 'ssh' bidon! Ha non pas 'toto' quand même!

On peut également s'amuser à faire du bruteforce sur certains services d'échange ou d'administration (ftp, telnet, ssh ...). On fait de même pour les interfaces Web protégées par une authentification (basic, formulaires ...). Alalala la quête du mot de passe faible ...

Sinon on fait quoi une fois que tout est fini? On n'attaque pas les applicatifs hein! ;)
Non, on croise les doigts et on espère avoir fait toutes les captures d'écran relatives aux vulnérabilités! Elles vont être nécessaires au magnifique rapport que vous allez pondre! Puis on se donne deux/trois claques, il faut se motiver pour le commencer ...

On met alors dans notre livrable une liste des services / versions identifiées, une cartographie du réseau vu par un attaquant extérieur ainsi que des fiches de vulnérabilités (le gros du travail).

Au final, c'est l'un des tests d'intrusion les plus bidons à faire, c'est pas super sexy mais ça permet de former les nouveaux. La principale difficulté de ces tests est d'arriver à faire rentrer les scans réseau dans le peu de temps imparti.

Une bonne approche consiste à balayer rapidement les plages sur des ports communs : 21/tcp, 22/tcp, 23/tcp, 25/tcp, 80/tcp, 443/tcp, ... Des outils comme synscan, portbunny, nmap --top-ports peuvent être utilisés. Si l'un des ports est ouvert, on rescanne la machine sur les 65535 ports... Ha oui j'oubliais, pour les étourdis, faut pas oublier l'UDP ;)

Niveau résultat, il est très rare de remonter des vulnérabilités critiques durant ce type d'audit (thks to Mr Firewall & co...).

Il faut savoir que ces tests sont rarement demandés seuls, en général ils sont packagés avec des audits applicatifs qui se déroulent dans la foulée (plus de détails dans le prochain billet).