Pentest d’une instance Yunohost #4 – Audit en Grey Box

PUBLISHED ON NOV 3, 2016 — SECURITY, SYSADMIN

Dans cette partie, je ne disposerai que des identifiants de l’utilisateur John Doe (johndoe/johndoe). Le but sera d’obtenir des privilèges supérieurs, autrement dit, d’obtenir les droits d’un administrateur.

Dashboard utilisateur

Une fois connecté sur son compte, l’utilisateur peut utiliser les différents services auxquels il a accès mais aussi modifier certaines informations liées à son compte. Nous pouvons changer notre nom, notre prénom et nos adresses emails, tant de paramètres qui, détournés, pourront nous permettre d’atteindre notre objectif.

Les champs d’édition du compte ont été testés, fuzzés mais aucun problème n’est apparu.

Même s’il ne semble pas y avoir de faille sur cette partie là, je conseille aux développeurs de Yunohost de définir une limite pour les nom, prénom et adresses email. Un nom trop long pourra entraîner des bugs de l’interface d’administration.

Par exemple, il sera compliqué, voir impossible, de donner accès aux applications à de nouveaux utilisateurs. En effet, le navigateur ne parviendra pas ouvrir la liste déroulante avec les utilisateurs si l’un d’eux possède un nom de 3000 caractères. Heureusement, l’administrateur pourra toujours changer le nom de l’utilisateur posant problème.

De plus, le filtrage de certains caractères spéciaux pourrait permettre de se protéger contre diverses attaques (XSS, injection LDAP, injection SQL, etc.). Même si Yunohost n’est pas faillible, cela n’est pas le cas de toutes les applications tierces que l’utilisateur pourrait utiliser.

Les applications tierces

Je ne me suis pas attardé sur l’audit des applications tierces que j’ai installé en même temps que Yunohost. Cependant, j’ai trouvé une “faille” sur DokuWiki. On pourrait considérer qu’il s’agit d’une “Stored Self XSS”. Un petit bug dans le fameux logiciel de wiki permet d’exécuter du code Javascript arbitraire. Pour ne rien vous cacher, j’étais plutôt content lorsque je l’ai découverte mais elle semble finalement bénigne car elle ne touche que l’utilisateur connecté. Dans l’exemple ci-dessous, j’ai choisi de mettre une iframe en tant que nom.

Self XSS Dokuwiki

En réalité, DokuWiki n’échappe pas correctement les nom et prénom ce qui permet, avec une simple balise , d’injecter du code HTML. Dans les sources, voilà ce que cela donne :

<script type="text/javascript">/*<![CDATA[*/var NS='';var SIG=' --- //[[johndoe@myyunohost.local|</script> <iframe src=https://exadot.fr></iframe>]] 2016/10/31 11:58//';var JSINFO = {"id":"start","namespace":""};
/*!]]>*/</script>

J’ai décidé de reporter cette “faille” en tant que simple bug à l’équipe s’occupant de DokuWiki.

Conclusion

Ce billet n’est pas long, car, au final, il y a peu à dire. Yunohost a été conçu en prenant vraiment en compte la sécurité, c’est indéniable. Évidemment, il n’est pas exempt de bug et de faille mais le système semble robuste. Je ne pourrais que conseiller d’ajouter un contrôle des données entrées dans les champs d’édition de compte pour éviter de futurs problèmes que ce soit dans Yunohost mais aussi dans les applications tierces.

J’ai commencé à étudier LuaLDAP plus en détail car s’il y a bien un point critique dans le système Yunohost, c’est bien SSOwat et, par extension, LuaLDAP. J’écrirai un billet si je trouve des choses intéressantes.