Authentification interprotocolaire sous Windows et élévation de privilèges – Partie 2/2

Cette partie du registre est modifiable par tous les utilisateurs et permet de spécifier l’emplacement du répertoire où stocker les logs du service en question. Ainsi, grâce aux 2 valeurs suivantes, il est possible de faire interagir le service IpHlpSvc avec le serveur « pirate » précédemment créé :

Lire la suite

Authentification interprotocolaire sous Windows et élévation de privilèges – Partie 1/2

Plusieurs vulnérabilités d’élévation de privilèges ont été découvertes sur les systèmes Windows ces derniers temps, reposant sur un même concept. Bien qu’elles aient été rectifiées, elles révèlent en réalité un problème bien plus profond, qui lui, n’est pas corrigé. En effet, la force d’interopérabilité entre les protocoles présents sous Windows en fait aussi sa faiblesse.

Depuis toujours, nombreuses sont les vulnérabilités d’élévation de privilèges sur Windows. Bien qu’en général celles-ci sont référencées dans la base de connaissances de Microsoft (Knowledge Base), il arrive que certaines vulnérabilités ne soient pas considérées en tant que telles, dans la mesure où, sous certaines configurations, l’exploitation ne fonctionnera pas.

Lire la suite

Architecture 64 bits/ASLR : quelles conséquences pour les exploits 32 bits ? Étude de cas avec Java et le CVE-2010-0842 – Partie 2/2

En exécutant le binaire plusieurs fois, nous remarquons que le programme java n’a pas été compilé avec l’option PIE (Position Independent Code), donc le binaire est toujours chargé à la même adresse. Et cela bien qu’ASLR soit activé et que les adresses de toutes les librairies et de la pile soient aléatoires. Ce binaire à adresse fixe est une mine d’or (ou plutôt de gadgets) pour l’analyste. Voyons voir si ce binaire contient un jmp rbx (0xFF 0xE3 en hexadécimal). Pour ce faire, nous allons utiliser un des nombreux désassembleurs [4] pour obtenir une chaîne hexadécimale du binaire puis chercher ce qui nous intéresse.

Lire la suite

Architecture 64 bits/ASLR : quelles conséquences pour les exploits 32 bits ? Étude de cas avec Java et le CVE-2010-0842 – Partie 1/2

Les deux vulnérabilités CVE-2010-0842 exploitées sous Windows en 32 bits restent-elles toujours exploitables en mode 64 bits avec ASLR ? En théorie, il est bien plus difficile, voire presque impossible de les exploiter de manière réaliste. En pratique, nous verrons que c’est toujours possible facilement.

Introduction

Un des objectifs du langage Java est d’éliminer les risques liés à la gestion de la mémoire manuelle (par exemple, débordement de tampon) comme dans un langage tel que le C. En théorie, un accès direct à la mémoire n’est pas possible et Java utilise un ramasse-miette pour récupérer de la mémoire allouée, mais plus utilisée. En pratique, Java repose sur de nombreuses librairies C/C++ dont le code, lui, peut accéder directement à la mémoire. De plus, ce code risque de contenir des vulnérabilités de type débordement de tampon ce qui contredit un des objectifs de sécurité du langage Java. Dans cet article, nous allons dans un premier temps brièvement présenter l’architecture de la sécurité Java. Ensuite, nous détaillerons les deux vulnérabilités du CVE-2010-0842, trouvées dans du code C/C++, qui permettent de contourner le système de sécurité de Java. Puis, nous expliquerons comment les exploiter en mode 64 bits avec ASLR activé.

Lire la suite