Pour tout un chacun, une application qui crash est un moment d’énervement, cela arrive sans prévenir et malheureusement souvent au pire moment.
Mais pour un pentester une application qui crash peut être l’opportunité d’une élévation de privilèges.
Il n’y a pas longtemps mon client Lotus Notes a crashé et comme j’avais l’explorateur de fichiers ouvert, j’ai noté la création d’un répertoire IBM_TECHNICAL_SUPPORT avec des fichiers de debug dedans.
Ce qui est intéressant c’est que ce répertoire est créé dans le profil utilisateur, parfaitement accessible en lecture et modification :
Pour savoir si ce crash en vaut la peine, il faut déterminer le nom du processus responsable de l’écriture de ce répertoire IBM_TECHNICAL_SUPPORT.
En faisant divers tests et en observant les processus au travers de Procmon, on s’aperçoit rapidement que c’est le service nsd.exe qui en est responsable :
Et devinez sous quel compte tourne ce service ?
Sous le compte Local System !
En résumé nous avons un service qui tourne sous Local System écrivant des fichiers dans un répertoire accessible par l’utilisateur en lecture/écriture.
Nous avons donc une vulnérabilité pouvant éventuellement mener à une élévation de privilège.
Vérifions que le détournement de répertoire fonctionne.
Il faut commencer par quitter le client Notes et supprimer le répertoire IBM_TECHNICAL_SUPPORT.
Ensuite nous pouvons créer un lien symbolique vers le répertoire système C:\Windows\system32 dans lequel en tant que simple utilisateur nous ne pouvons pas évidemment pas écrire :
mklink /J <USER ROAMING PROFILE>\Domino\IBM_TECHNICAL_SUPPORT "C:\Windows\System32"
Ensuite il suffit de lancer le client Notes et de le faire crasher comme ci-dessous :
Et comme attendu, des fichiers de debug ont été créés dans le répertoire système C:\Windows\System32 !
Ce type de vulnérabilité est assez courant et peut permettre une élévation de privilège à condition de pouvoir contrôler certains paramètres comme les noms des fichiers cibles et les permissions.
Je ne suis pas allé plus loin dans l’analyse et libre à vous de creuser l’affaire, notamment avec la technique d’indirection RPC Control (exemple : https://decoder.cloud/2020/10/27/when-a-stupid-oplock-leads-you-to-system/) et pourquoi pas dénicher une nouvelle CVE et au passage un peu de cash 🙂