Défaut de sécurité Badlock dans Samba - CVE-2016-2118

Public Date: April 12, 2016, 13:45
Mis à jour October 24, 2024, 11:53 - Chinese, Simplified Anglais Japanese Korean

Est-ce que cette infomation vous a été utile ?

Resolved État
Important Impact
L'équipe Red Hat Product Security a été informée d'une vulnérabilité/RPC-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 et elle est classifiée Important. D'autre vulnérabilités, classifiées de Moderate à Critical et décrites dans Défaut de sécurité de Samba publié le 12 avril 2016 , ont également été rendues publiques.
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 des 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).

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.

Produits concernés

Ce problème est considéré comme ayant un impact classifié comme étant Important par Red Hat Product Security. D'autres vulnérabilités, classifiées Critical à Moderate, et décrites dans Défaut de sécurité de Samba publié le 12 avril 2016 , ont également été rendues publiques. Vous trouverez des informations supplémentaires sur Badlock dans Badlock: SAMR and LSA protocol man-in-the-middle attack against Samba (CVE-2016-2118) .

Les versions de produits Red Hat suivants sont concernés :

  • Red Hat Enterprise Linux 4*
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Gluster Storage 3
Toutes les versions de paquets Sambas fournis dans Red Hat Enterprise Linux server et Red Hat Gluster Storage sont affectés par cette vulnérabilité.

*Un abonnement ELS actif est exigé pour pouvoir accéder à ce correctif dans RHEL 4. Veuillez contacter l'équipe de vente de Red Hat ou bien, votre représentant commercial particulier pour obtenir plus d'informations si votre compte n'a pas d'abonnement ELS actif.

Qu'est-ce que Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS) ?

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 informationshautement confidentielles.
Le protocole d'application-choisi par le client, le type d'authentification (par exemple, Kerberos ou NTLMSSP), et leniveau d'authentification (NONE, CONNECT, SIGN, ou SEAL) n'ont aucune importance dans un tel cas. Un attaquant -qui-s'impose-au milieu cpeut faire diminuer le niveau d'authentification à CONNECT et s'approprier la connexion. Le problème Badlock a été corrigé avec une série de CVE documentées ici :

Exposition

Pour les clients qui utilisent Samba en tant que membre de domaine dans un environnement AD :

  • Comment détecter : 'security = ads' dans le fichier smb.conf ?
    • Nous vous conseillons de migrer à samba3x (3.6) sur RHEL5 ou RHEL6/samba (3.6), ou encore, RHEL7/samba (4.2)
    • La migration n'est pas automatique, elle a besoin d'être planifiée, particulièrement autour d'IDMAP car il y a eu des changements dans 3.0 -> 3.6 et 3.6 -> 4.x

Pour les clients qui utilisent Samba en tant que membre de domaine dans un environnement NT :

  • Comment détecter : 'security = domain' dans le fichier smb.conf ?
    • Nous vous conseillons de migrer à samba3x (3.6) sur RHEL5 ou RHEL6/samba (3.6), ou encore, RHEL7/samba (4.2)
    • La migration n'est pas automatique, elle a besoin d'être planifiée, particulièrement autour d'IDMAP car il y a eu des changements dans 3.0 -> 3.6 et 3.6 -> 4.x

Pour les clients qui utilisent Samba comme serveur de fichiers :

  • Comment détecter : 'security = user' ou 'security = ads' ou 'security = domain', ou 'security = standalone' et les partitions définies dans le fichier smb.conf
    • Nous vous conseillons de migrer à samba3x (3.6) sur RHEL5 ou RHEL6/samba (3.6), ou encore, RHEL7/samba (4.2)
    • La migration n'est pas automatique, elle a besoin d'être planifiée, particulièrement autour d'IDMAP car il y a eu des changements dans 3.0 -> 3.6 et 3.6 -> 4.x

Foire aux questions

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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é.
  6. Quelles versions de Samba sont corrigées ?
    • Red Hat est entrain mettre à jour les paquets (samba, samba3x, samba4) pour les versions Samba 4.2, 4.1, 4.0, 3.6, & 3.0 sur tous les produits actuellement pris en charge, y compris les dépendances, si nécessaire, comme IPA, OpenChange, et les bibliothèques libtalloc, libtdb et libevent.

Configurations concernées

Une infrastructure de répertoire avec un serveur Samba comme membre de domaine est vulnérable à cette faille. Un attaquant-intermédiaire-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.
* Tout serveur Samba configuré en tant que fichier ou serveur d'affichage est vulnérable.

Mise à jour des produits concernés

Red Hat Enterprise Linux 4 - Extended Lifecycle Support* samba (v3.0) RHSA-2016:0625
Red Hat Enterprise Linux 5 samba (v3.0) RHSA-2016:0621
Red Hat Enterprise Linux 5 samba3x (v3.6) RHSA-2016:0613
Red Hat Enterprise Linux 5.6 Long Life samba (v3.0) RHSA-2016:0623
Red Hat Enterprise Linux 5.6 Long Life samba3x (v3.6) RHSA-2016:0624
Red Hat Enterprise Linux 5.9 Long Life samba (v3.0) RHSA-2016:0623
Red Hat Enterprise Linux 5.9 Long Life samba3x (v3.6) RHSA-2016:0624
Red Hat Enterprise Linux 6 samba (v3.6) RHSA-2016:0611
Red Hat Enterprise Linux 6 samba4 (v4.0) RHSA-2016:0612
Red Hat Enterprise Linux 6.2 Advanced Update Support** samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.2 Advanced Update Support** samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 6.4 Advanced Update Support** samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.4 Advanced Update Support** samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 6.5 Advanced Update Support** samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.5 Advanced Update Support** samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 6.6 Extended Update Support samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.6 Extended Update Support samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 7 samba (v4.2) RHSA-2016:0612
Red Hat Enterprise Linux 7.1 Extended Update Support samba (v4.1) RHSA-2016:0618
Red Hat Gluster Storage 3 (EL6) samba (v4.2) RHSA-2016:0614
Red Hat Gluster Storage 3 (EL7) samba (v4.2) RHSA-2016:0614

*Un abonnement ELS actif est requis pour accéder à ce correctif dans RHEL 4. Veuillez contacter l'équipe de vente de Red Hat ou bien, votre représentant commercial particulier pour obtenir plus d'informations si votre compte n'a pas d'abonnement ELS actif.

Qu'est-ce que Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS) ?

*Un abonnement ELS actif est exigé pour pouvoir accéder à ce correctif dans RHEL 6.X AUS.

Mitigation

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.

Résolution

Nouvelle option de configuration smb.conf
Cette mise à jour introduit l'option de configuration du fichier smb.conf :
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 une authentification, mais pas d'-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 = no
Exemple : allow dcerpc auth level connect = yes

Comments