Badlock: attaque malveillante via protocoles SAMR et LSA dans Samba (CVE-2016-2118)

L'équipe Red Hat Product Security a été informée d'une vulnérabilité basée sur les protocoles SAMR et LSA utilisés dans l'infrastructure Active Directory de Microsoft Windows. Cette vulnérabilité a été assignée à CVE-2016-2118

Remarque : c'est un problème de protocole qui affecte toutes les applications utilisant ce protocole, y compris Samba - CVE-2016-2118, et Microsoft Windows - CVE-2016-0128.

Informations générales

DCE/RPC correspond à la spécification d'un mécanisme d'appel de procédure distant, qui définit les deux API, ainsi qu'un protocole « over-the-network ». Le protocole distant SAM (Security Account Manager) (de client à serveur) fournit des fonctionnalités de gestion de stores de comptes ou de répertoires contenant des utilisateurs et des groupes. Le protocole expose la "base de données du compte" pour les domaines Microsoft Active Directory locaux ou à distance. Le protocole distant Local Security Authority (politique de domaine) est utilisé pour gérer les différentes politiques de sécurité des machines et domaines. Le présent protocole, à quelques exceptions près, permet des scénarios de gestion des politiques à distance. Les protocoles SAMR et LSA sont basés sur le protocole DCE RPC 1.1.

Ces protocoles sont normalement disponibles pour toutes les installations Windows, ainsi que pour tout serveur Samba. Ils sont utilisés pour maintenir la base de données SAM (Security Account Manager). Cela s'applique à tous les rôles (par exemple, au contrôleur de domaine ou autonome ou à un membre du domaine).

Description et impact de l'attaque

Toute connexion DCE/RPC authentifiée qu'un client initie auprès d'un serveur peut être utilisée par un attaquant s'interposant à la place de l'utilisateur authentifié dans le service SAMR ou LSA sur le serveur. De ce fait, l'attaquant est alors en mesure d'accéder aux permissions lecture / écriture sur la base de données SAM (Security Account Manager), ce qui peut révéler tous les mots de passe et autres informations potentiellement confidentielles.

Le protocole d'application choisi par le client, le type d'authentification (par exemple, Kerberos ou NTLMSSP), et le niveau d'authentification (NONE, CONNECT, SIGN ou SEAL) n'ont aucune importance dans un tel cas. Un attaquant malveillant peut faire diminuer le niveau d'authentification à CONNECT et s'approprier la connexion.

Toutes les versions de paquets Samba fournies dans Red Hat Enterprise Linux server et Red Hat Gluster Storage sont affectées par cette vulnérabilité.

Versions concernées

*Une infrastructure de répertoire avec un serveur Samba comme membre de domaine est vulnérable. Un attaquant peut intercepter le trafic DCE/RPC entre le membre de domaine et le contrôleur de domaine, en se faisant passer pour le client et en bénéficiant des mêmes privilèges que l'utilisateur authentifié du compte. L'attaquant peut afficher ou modifier des secrets dans la base de données AD, y compris les hachages de mots de passe utilisateur, ou fermer des services critiques.

• Tout serveur Samba configuré en tant que serveur de fichiers ou d'impression est également vulnérable avec cette défaillance. Un attaquant malveillant peut exploiter cette défaillance pour modifier les permissions utilisateur sur les fichiers et les répertoires.

Prévention

Le risque peut être réduit si on n'utilise pas les comptes privilégiés pour accéder aux services SMB/CIFS tant qu'un correctif de paquet n'a pas été appliqué. Les comptes privilégiés ne doivent être utilisés que sur le matériel physique (console, serveur) de façon à ce que l'authentification n'implique aucune communication réseau.

Solution

Remerciements

Red Hat souhaite remercier le projet Samba d'avoir signalé ce problème. Stephan Metzmacher (SerNet) a été reconnu en amont pour avoir été le premier à signaler cet incident.

Remarques supplémentaires

Le correctif de cette alerte de sécurité propose une nouvelle optionsmb.conf documentée ici :

 allow dcerpc auth level connect (G)

   Cette option contrôle si les services DCE/RPC peuvent être utilisés avec
DCERPC_AUTH_LEVEL_CONNECT, qui fournit l'authentification, mais pas l'intégrité par-message (SIGN), ni de protection de confidentialité (SCEAU).

Certaines interfaces comme SAMR, LSARPC et netlogon ont comme valeur de codification en dur par défaut 
   non; epmapper, mgmt, et rpcecho ont pour valeur de codification en dur : oui.

Le comportement peut être remplacé par le nom de l'interface (par  exemple, lsarpc, 
   netlogon, samr, srvsvc, winreg, ou wkssvc) en spécifiant
   'allow dcerpc auth level connect:interface = yes'.

Cette option prend précédence sur toute implémentation de restrictions spécifiques. Par 
   exemple :
   * Les protocoles drsuapi et backupkey exigent DCERPC_AUTH_LEVEL_PRIVACY.
   * Le protocole dnsserver exige DCERPC_AUTH_LEVEL_INTEGRITY.

   Par défaut : allow dcerpc auth level connect (G)
    Exemple: allow dcerpc auth level connect = yes

Foire aux questions

** Est-ce que je dois appliquer le correctif à la fois aux clients Samba et aux serveurs Samba dans mon infrastructure ?**

La moindre des choses est de mettre les serveurs Samba à jour. Comme Badlock est une défaillance de protocole, les serveurs et les clients à la fois peuvent être affectés, selon la configuration de l'infrastructure de Samba. Red Hat Product Security conseille à ses clients de mettre à jour les serveurs et les clients à la fois.

Est-ce que les correctifs mis à jour vont endommager mes clients existants qui exécutent des versions plus anciennes de Samba ?

Cette alerte de sécurité resserre certaines options de sécurité utilisées pour configurer Samba. Cela peut casser les configurations quand le serveur Samba est mis à jour, et que le client ne l'est pas. Il est possible de restaurer les anciennes options insécurisées pour continuer l'intéropérabilité, (par exemple, en définissant allow dcerpc auth level connect = yes dans le fichier smb.conf), mais Red Hat Product Security ne vous le conseille pas car cela introduit à nouveau les vecteurs d'attaque.

Mes instances de serveur Samba ne sont connectées à aucun domaine Windows, suis-je encore affecté ?

Oui, si un administrateur communique avec un serveur Samba en utilisant un client non sécurisé, ou s'il utilise un client sécurisé pour communiquer avec un serveur Samba non sécurisé, un attaquant peut potentiellement utiliser cela pour exploiter la défaillance.

J'ai mis à jour mes serveurs et clients Samba, est-ce que je dois démarrer quelquechose à nouveau ?

Non, une fois que la mise à jour a été appliquée à votre système, le service smb`redémarrera automatiquement.

L'encodage me protégera-t-il contre une attaque MITM ?

Le protocole SMB, par défaut, crypte uniquement les informations d'identification et décide quels fichiers sont transférés en format de texte brut. Il est recommandé que dans la sécurité et dans les scénarios privés sensibles, l'encodage soit utilisé pour protéger toutes les communications. L'encodage a été ajouté à Samba dans la version 3.2, mais uniquement pour les clients Samba. Microsoft a ajouté un support d'encodage SMB à SMB 3.0 dans Windows 8 et dans Windows Server 2012. Toutefois, ces deux types d'encodage ne protègent que les communications comme les transferts de fichiers, une fois que la négociation SMB et que les commandes sont complétées. C'est cette phase qui contient la vulnérabilité mise en évidence ci-dessus. L'encodage Samba/SMB est une bonne pratique, mais n'est pas suffisant pour protéger contre cette vulnérabilité.

Références

http://badlock.org/