Cet article a pour but d’aider à la compréhension de la problématique des vulnérabilités impactant les services RPC Windows, pour lesquelles on constate que la portée et l’étendue sont variables en fonction de la version du système Windows concerné.

Les RPC (Remote Procedure Calls) constituent un mécanisme client-serveur d’invocation de procédures à distance, initialement implémenté sur Unix. Les systèmes Windows ont très vite adopté ce mécanisme, qui a été adapté et intégré à de nombreuses couches du système d’exploitation.

Ainsi, de nombreux « services » Windows fonctionnent via les RPC, et sont ainsi accessibles à distance. A cela s’ajoute la couche DCOM, qui s’appuie sur RPC, et qui fournit une interface de plus haut niveau pour construire des services et des applications distribuées.

Vulnérabilités impactant les MSRPC

A intervalles réguliers, des vulnérabilités impactant le sous-système RPC, des services RPC ou des services DCOM ont été identifiées sur les systèmes Windows.

Ces vulnérabilités, de type débordement mémoire, présentent toutes la caractéristique de comporter des menaces d’exécution à distance, de part la nature des composants impactés.

 Voici un historique non exhaustif de vulnérabilités ayant impacté les RPC sous Windows :

Portée et étendue des vulnérabilités : variation et mitigation en fonction des droits d’accès

Partant du fait que ces vulnérabilités comportent des menaces d’exécution à distance, la problématique est ensuite de déterminer quels sont les pré-requis et les privilèges nécessaires pour pouvoir exploiter ces vulnérabilités. En effet, potentiellement, lors d’une attaque à distance, on peut imaginer que le pré-requis pour exploiter une vulnérabilité est principalement un des cas de figure suivants :

1. L’exploitation de la vulnérabilité ne nécessite aucune authentification sur le système, i.e. il est possible pour un attaquant d’exécuter du code arbitraire sur le système, de façon anonyme, et sans autre pré-requis que la visibilité du service via le réseau. C’est la menace la plus sérieuse.
2. L’exploitation de la vulnérabilité nécessite un compte valide non privilégié sur le système, permettant à un attaquant d’augmenter ses privilèges. Il s’agit là d’un pré-requis important pour commencer à mitiger la menace.
3. L’exploitation de la vulnérabilité nécessite un compte administrateur sur le système. La vulnérabilité représente alors une menace faible (voire nulle).
   

Concrètement, un système Windows va s’appuyer essentiellement sur les 4 points suivants, afin de mitiger les conséquences d’une vulnérabilité, et afin d’imposer de façon proactive des pré-requis à une exploitation réussie :

a.      Restriction des appartenances au groupe ‘Everyone’ (‘Tout le Monde’)

b.      Restriction des droits d’accès attribués au groupe ‘Everyone’ (‘Tout le Monde’)

c.       Restriction des droits d’accès attribués au compte spécial ‘Anonymous’

d.      Restriction des comptes autorisés à accéder aux services RPC / DCOM

Ces 4 éléments ont une pertinence particulière dans le cadre d’une vulnérabilité RPC :

a.      Le groupe ‘Everyone’ est censé désigner tout utilisateur sur le système. Mais l’appartenance précise à ce groupe est néanmoins sujette à caution : faut-il inclure dans ‘Everyone’ tout utilisateur, y compris un utilisateur non authentifié (‘Anonymous’) sur le système ?

b.      Quelle est l’étendue des droits d’accès attribués au groupe ‘Everyone’ ? A-t-il en particulier des droits d’exécution sur certains services RPC ?

c.       Le compte spécial ‘Anonymous’ a été initialement créé pour permettre de réaliser certaines opérations sans être authentifié sur le système, en particulier pour effectuer certaines invocations précises de services RPC (comme pour obtenir le listing des comptes présents dans un domaine) ; cela était imposé par certaines limitations conceptuelles du système sous NT4. Les droits d’accès attribués au compte ‘Anonymous’ ont donc un impact direct sur la possibilité d’exploiter une vulnérabilité sans authentification sur un service RPC vulnérable.

d.      Chaque service ou composant basé sur RPC dispose de droits d’accès. La rigueur de ces droits, en particulier pour ce qui est des droits affectés au groupe ‘Everyone’ et au compte ‘Anonymous’, a donc un impact direct sur les possibilités d’exploiter une vulnérabilité sur un service RPC vulnérable.

On comprend donc que lors de la survenue d’une vulnérabilité sur un service RPC, le niveau de configuration de ces 4 points va impacter directement les pré-requis et les privilèges nécessaires pour pouvoir exploiter la vulnérabilité.

Configurations par défaut et mitigation des risques :
Analyse comparative Windows NT4 / Windows 2000 / Windows XP / Windows XP SP2 / Windows 2003

Sur les versions successives de Windows, Microsoft a opéré des changements de configuration par défaut, afin de réduire la portée de la menace si des vulnérabilités survenaient. C’est donc sur les 4 points a,b,c et d que des restrictions ont été opérées.

Essentiellement, les grands « jalons » de la mise en œuvre par Microsoft de restrictions supplémentaires concernent les versions de Windows suivantes :

• Windows NT4,
• Windows 2000,
• Windows XP,
• Windows 2003,
• Windows XP SP2 / Window 2003 SP1.
  

Le tableau suivant récapitule les principaux changements opérés par Microsoft au fil du temps sur ces 4 paramètres.

La lecture du tableau entend que les améliorations apportées à un système sont « héritées » aux systèmes plus récents.

Ce récapitulatif montre que globalement on peut considérer que les systèmes :

• Windows 2000 et antérieures sont très permissifs. Les failles RPC seront donc assez souvent exploitables à distance par un attaquant anonyme.
• Windows XP-SP2 et 2003-SP1 sont très restrictifs. Les failles RPC seront donc rarement exploitables à distance par un attaquant anonyme.

Exemple : Analyse d’un avis de sécurité

A la lumière de ces principes, regardons le détail d’un des avis de sécurité concernés par la problématique étudiée :

Les commentaires sont fournis en italique.

- Sur les systèmes Windows 2000 le composant vulnérable est accessible à distance avec une connexion anonyme. Cette vulnérabilité permet alors à un attaquant distant, via un message spécifiquement formaté, de prendre le contrôle d'un système vulnérable.

on constate que sur Windows 2000, le service RPC incriminé peut être invoqué de façon anonyme. A partir de là, le débordement mémoire peut être exécuté, avec comme conséquence l’exécution de code avec les privilèges du service (privilèges système).

 - Sur les systèmes Windows XP SP1 le composant vulnérable est accessible à distance avec une connexion authentifiée. Cette vulnérabilité permet alors à un attaquant distant et authentifié, via un message spécifiquement formaté, de prendre le contrôle d'un système vulnérable.

 on constate que sur Windows XP antérieur au SP2, le service RPC incriminé peut être invoqué, mais pas de façon anonyme ; le droit d’accès anonyme a été retiré sur ce service, qui est en revanche accessible pour un utilisateur authentifié sur le système. A partir de là, le débordement mémoire peut être exécuté, avec comme conséquence l’exécution de code avec les privilèges du service (privilèges système).

 - Sur les systèmes Windows XP SP2 et Windows Server 2003  le composant vulnérable est accessible à distance uniquement aux utilisateurs authentifiés ayant déjà les privilèges administrateur. Cette vulnérabilité n'est donc pas exploitable à distance. Par contre, elle permet par ailleurs à un utilisateur local, via une application malveillante, d'obtenir illégalement les privilèges administrateur sur un système vulnérable.

on constate que sur Windows XP SP2 et Windows 2003, le service RPC incriminé peut être invoqué, mais uniquement si on dispose des droits d’administration. Ces systèmes bénéficient donc d’un renforcement a priori optimal des droits nécessaires à l’invocation de ce service RPC.