mercredi 24 décembre 2014

Try Harder (review PWK/OSCP)

Ce week-end, j'ai (enfin) terminé mon cycle PWK en obtenant la certification OSCP, par conséquent j'en profite pour faire un post pour les francophones qui voudraient en savoir plus, ou qui ne connaissaient juste pas et cherchent une formation en sécurité informatique (ou alors pour les managers qui cherchent quelle formation payer à leurs employés, mais je pense qu'on peut rêver).

PWK (Pentesting With Kali)

C'est la formation de base d'Offensive-Security permettant de se familiariser avec le monde fabuleux de la sécurité informatique. Dans mon cas, je pense être déjà pas mal familiarisé avec ce domaine, dans la mesure où ça fait 15 ans que je m'y intéresse (et pas loin de 8 ans que je bosse dedans), mais j'aime bien l'idée de potasser sur des sujets sur lesquels je ne m'étais jamais trop attardé avec un objectif intéressant (la certification).

La formation

La formation en elle même est intéressante. On se retrouve avec un fichier .PDF de 350 pages accompagné d'un .rar contenant des vidéos reprenant les manipulations détaillées dans le pdf (enfin presque toutes). Le tout est watermarké avec nom/prénom/adresse, au cas où les documents fuiteraient sur internet. Vous pouvez retrouver le sommaire du cours sur le site Offensive-Security. Alors ne rêvez pas non plus, pas de techniques über eleet là dedans non plus, mais assez de contenu pour débuter dans le pentest réseau, exploiter des vulnérabilités avec metasploit ou utiliser des exploits de exploit-db (et les adapter quand ils en ont besoin), ou pivoter d'un réseau à l'autre via des tunnels et port forwards, en passant par l'exploitation de stack overflows (et juste ça) de base dans des conditions réelles (ASLR, DEP) de type appli avec au moins une dll sans ASLR sous Windows 7 avec DEP désactivé.

Lab

Jusque là, rien de trop différent d'une formation du SANS (en l'occurence, SANS 560) en mode e-learning. Sauf que là où une formation SANS se déroule en 5-6 jours (parfois avec un prof), la formation PWK se déroule généralement entièrement chez soi (enfin, là où on veut), et on a un accès VPN à un réseau comportant une cinquantaine de machines pouvant toutes être compromises, à la difficulté variable. Alors ici, pas de scénarios trop tordus comme dans un CTF : c'est une formation qui se veut pratique, basée sur des cas concrets et généralement inspirés de cas réels. En vrac, et en évitant de trop sploiler, voici quelques scénarios de machines pouvant être rootées sur ce lab :
- Du "remote root" (dans divers services)
- Des creds par défaut sur des applications diverses dont on peut tirer parti de diverses manières (ça va du ftp anonyme nous permettant de récupérer des infos intéressantes, à l'outil de ticketing qui tourne en admin et qui peut être détourné pour exécuter du code sur le système)
- Des applications web trouées (applications réelles, dont du wordpress)
- Des fausses pistes (injection SQL un peu tricky à exploiter sur une machine vulnérable à un "remote root" du système)
- La nécessité de fouiller les machines permettant d'obtenir des pistes (passwords.txt, analyse de logs http à la recherche de postes clients à compromettre, ...)
- Etc.

J'insiste sur le fait que toutes les machines sont rootables. Si on bloque, c'est qu'il nous manque une information, et qu'on a pas fait suffisamment de "reconnaissance" ("Try Harder").

Le réseau accessible via le VPN est un réseau à plusieurs niveaux. Sur le site d'offsec on retrouve un schéma réseau qui ressemble à celui auquel on a accès :
http://www.offensive-security.com/wp-content/uploads/2012/01/offsec-playground-thumb-21.jpg

- Le "starting network" qui est le réseau "public" accessible directement depuis le VPN;
- Le "starfleet network" qui correspond à un réseau "dev", accessible depuis une poignée de machines du réseau "public";
- Le "middle earth network" correspondant au réseau "IT", accessible depuis une poignée de machines du réseau "public";
- Le "grey network" correspondant au réseau "admin", accessible uniquement en passant par certaines machines du réseau "IT"

Le but de tout ça étant de se familiariser avec la notion de "rebond", car même si lors de pentests internes, on se retrouve trèèèèès souvent avec des réseaux "à plat" ou avec des erreurs de configuration qui permettent du "any to any", il est intéressant de pouvoir s'entrainer pour les quelques cas où ça ne sera pas le cas.

On dispose d'un temps allant de 1 à 3 mois pour se balader sur le réseau (le bundle 3 mois + passage de certification revient à environ 850 euros, ce qui n'est pas excessif, à comparer à 4000 euros pour une formation du SANS, surtout pour une certification qui commence doucement à être reconnue).

On doit documenter la méthode de compromission des machines dans un rapport, en essayant de fournir le plus de détails possibles (screenshots, copies de term, exploits, etc). A titre personnel, je me suis organisé en prenant des notes et des screenshots à chaque étape. Je me retrouve à la fin avec un rapport "de lab" d'une centaine de pages.

Exam / challenge

Vient ensuite l'épreuve ultime: passer l'exam OSCP. Il est un peu spécial, et généralement ça impressionne les gens comme la "piscine epitech", dans le sens où il est annoncé comme un examen de 2x24 heures consécutives. A noter que le staff d'offensive security y fait référence comme le "challenge OSCP".

- 24 heures d'examen à proprement parler où on accède à un réseau comprenant 5 serveurs rapportant entre 10 et 25 points (10, 2x20 et 2x25), totalisant 100 points (70 sont requis pour obtenir la certification). Seule une partie des points est obtenue en cas de compromission partielle (on a tous les points si on lit un fichier accessible au root/admin, sinon un autre fichier, accessible avec un compte non-privilégié rapporte qu'une partie des points en gros)
- 24 heures pour rédiger un rapport de pentest, en anglais, relatif à ces 5 machines.

Si on se retrouve avec un peu moins de 70 points, le rapport des 3 mois de "lab" sera évalué par le staff d'offensive-security, et en fonction de sa qualité, ils accorderont (ou pas) les quelques points manquants.

Il existe un certain nombre de restrictions durant le "challenge" :
- l'utilisation de Metasploit est fortement réglementée. Concrètement il est possible de l'utiliser pour compromettre UNE machine, parmi TROIS sur lesquelles c'est permis (si ensuite il n'existe qu'un exploit Metasploit pour compromettre une machine, c'est que c'est ici qu'il sera le plus judicieux de l'utiliser). Cela est valable aussi bien pour les exploits en remote, que pour les élévations de privilèges locales au travers de Meterpreter.
- l'utilisation de Meterpreter est autorisée en tant que payload/outil de prise de contrôle à distance, mais pas les fonctions telles que "getsystem".
- les scanners de vulnérabilités un peu bourrins à la Nessus/OpenVAS, NeXpose, w3af, ... ainsi que les outils un peu trop automatisés (genre sqlmap) ne sont pas non plus autorisés. En revanche, il est parfaitement possible d'utiliser nmap et tous ses plugins, ainsi que burp.

Le pool de machines choisies est assez hétérogène, et il y a même une machine disposant d'un logiciel pour lequel il existe une vulnérabilité publique (un stack overflow basique exploitable à distance) nécessitant le développement d'un exploit en partant d'un poc provoquant un crash (la génération du shellcode ainsi que la recherche d'un eip pointant sur ce dernier étant donc à la charge du challenger).

Evidemment, tout doit être documenté dans un rapport "d'exam" à remettre au staff d'offsec par e-mail, avec des screenshots prouvant la compromission des machines (en gros un id/ifconfig/cat flag.txt ou son équivalent Windows).

Ensuite on reçoit un mail au bout de quelques jours, avec le verdict. On ne connait pas le nombre de points qu'on a obtenu, on sait juste si on passe ou pas. J'ai envoyé mon rapport Lundi dans la journée, mardi à 15h j'avais une réponse.

Quoi étudier en attendant ?

J'anticipe, au niveau de la littérature recommandée avant de s'engager là dedans :
- Le support de cours PWK fourni par Offensive-Security
De plus, la connaissance préalable d'au moins un langage de programmation est fortement recommandée, ne serait-ce que pour être capable de comprendre comment modifier un exploit qui ne fonctionne pas (avec un bonus pour le C dans le cas d'exploits de 1865 qui ne compilent plus sur un gcc récent).

Concernant l'investissement personnel...il faut être prêt à sacrifier quelques soirées, mais pas toutes. Cela dit, passer une dizaine d'heures par semaine sur cette formation n'est pas insurmontable. Tout dépend de là où on part, et de l'objectif que l'on se fixe. Pour l'exam, 24 heures c'est largement suffisant, n'imaginez pas qu'il faille préparer un stock de redbull. Il est faisable en beaucoup moins.

Conclusion

Globalement, si d'un point de vue technique je n'ai pas appris grand chose, ça m'a au moins motivé à persévérer (le fameux "try harder"), dans la mesure où chaque machine est pwnable. Si on y arrive pas, c'est qu'il nous manque une info pour continuer. Ca force donc à élargir le champ de recherche, ce qui sera forcément bénéfique dans le cadre de véritables pentests.

vendredi 19 décembre 2014

Support de SSLv2 dans sslscan (sous Linux)

Sslscan c'est beau et magique, mais depuis que les distributions GNU/Linux packagent des versions d'OpenSSL sans support sslv2, une partie des fonctionnalités de sslscan ne fonctionnent plus.
Evidemment, Internet regorge de tutos expliquant comment recompiler et packager la libssl sous diverses distributions Linux de warlordz (j'ai rien contre Kali, au contraire) pour ajouter le support sslv2 et recompiler sslscan.
Sur mon laptop, je n'utilise pas Kali (enfin si, dans une VM), j'ai juste un dossier dans lequel j'ai tous mes outils compilés par mes soins, et généralement plus ou moins up2date à la dernière version du repository git/svn/etc. Voici comment je me suis démerdé. L'avantage c'est que le reste de mes applis n'utilise pas une version de la libssl supportant SSLv2.

$ cd bordel/
$ wget https://www.openssl.org/source/openssl-1.0.1j.tar.gz
$ tar -xzf openssl-1.0.1j.tar.gz
$ cd openssl-1.0.1j/
$ ./config
$ make
$ cd ..
$ git clone https://github.com/rbsec/sslscan.git
$ cd sslscan/
$ gcc -o sslscan sslscan.c ../openssl-1.0.1j/libssl.a ../openssl-1.0.1j/libcrypto.a -I ../openssl-1.0.1j/include/ -DVERSION=\"1.9.8-rbsec\" -ldl

Ouais bon le coup du -DVERSION c'est parce que le Makefile l'ajoute à la compilation, et vu qu'ici on compile direct comme des gorets ...
Le reste c'est juste la compilation de la dernière version d'OpenSSL (en lib statique, le comportement par défaut) et la compilation en linkant sslscan avec les versions statiques de la libssl et la libcrypto. Comme ça pas de dépendance à cette libssl (sinon on peut aussi compiler OpenSSL en lib dynamique, suffit de "./config shared", compiler avec les LDFLAGS qui vont bien et modifier le LD_LIBRARY_PATH à chaque utilisation de sslscan ... assez lourd quoi).

Ensuite on a plus qu'à lancer notre sslscan :

meik@eleet ~bordel/sslscan $ ./sslscan --ssl2 xxx.xxx.xxx.xxx:443
Version: 1.9.8-rbsec
OpenSSL 1.0.1j 15 Oct 2014

Testing SSL server xxx.xxx.xxx.xxx on port 443

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
Compression disabled

  Heartbleed:
All TLS protocols disabled, cannot check for heartbleed.

  Supported Server Cipher(s):
Accepted  SSLv2    128 bits  RC4-MD5
Accepted  SSLv2    112 bits  DES-CBC3-MD5

  Preferred Server Cipher(s):
SSLv2    128 bits  RC4-MD5

  SSL Certificate:
Signature Algorithm: sha1WithRSAEncryption
RSA Key Strength: 2048

Maintenant plus d'excuses.