Qu'est-ce qui se passe vraiment dans ces rapports de vulnérabilité Lion LDAP?


8

Il suffit de lire un fil Slashdot sur la rupture LDAP sous OSX. Quelqu'un peut-il expliquer exactement ce qui est sécurisé par OpenLDAP et pourquoi autre chose que les données stockées sur une machine Lion pourraient être en danger?

Une citation de l'article:

"En tant que testeurs de stylo, l'une des premières choses que nous faisons est d'attaquer le serveur LDAP", a déclaré Rob Graham, PDG du cabinet d'audit Errata Security. «Une fois que nous possédons un serveur LDAP, nous possédons tout. Je peux accéder à n'importe quel ordinateur portable (dans une organisation) et me connecter. »

Comment passer du piratage d'un serveur LDAP mac aléatoire à la propriété de toute l'entreprise?


2
Slashdot, The Register et MacRumors sont pleins de désinformation et de battage médiatique. Prenez leurs déclarations avec un grain de sel jusqu'à ce que vous lisiez à ce sujet sur une source fiable. Ces articles sont très légers sur les détails, et il y a beaucoup de confusion quant à savoir si cela affecte quelque chose au-delà des comptes sur la machine locale . Des rumeurs circulent selon lesquelles ce problème est un «cauchemar de sécurité d'entreprise» ou pourrait permettre aux utilisateurs de posséder le serveur LDAP, mais cela semble peu probable. Les clients LDAP cassés et personnalisés n'ont rien de nouveau.
Stefan Lasiewski

C'est une bonne question. Presque chaque article que j'ai lu manque extrêmement de détails.
Zoredache

Réponses:


8

Ne vous inquiétez pas. Ce n'est pas une énorme menace pour les réseaux d'entreprise, comme le suggère cet article dans The Register .

Apple Lion est nouveau, et ce bug reçoit donc une attention disproportionnée par rapport à des défauts similaires sur d'autres systèmes d'exploitation. Voici quelques descriptions plus calmes de ce même problème:

Il s'agit d'un exploit local sur un système Apple Lion qui affecte uniquement ce système. Apple n'a pas encore fourni de détails. Voici comment je comprends le problème: si quelqu'un se connecte à un système Apple Lion une fois avec succès, alors n'importe qui d'autre peut se connecter au même système avec n'importe quel mot de passe. Il s'agit d'un problème grave pour ce système, mais les dommages sont principalement limités à ce système particulier. Malheureusement, ce système est maintenant moins fiable et peut être activé sur votre réseau.

Ce problème ne permet PAS à un pirate de posséder vos serveurs AD / LDAP, en soi. Vos serveurs AD / LDAP rejetteront toujours toute demande d'autorisation LDAP incorrecte de tout client LDAP. Pour contourner cela, il faudrait une faille majeure sur le serveur LDAP ou le protocole LDAP ou un serveur mal configuré, ce qui est un problème complètement différent du problème décrit ci-dessus.

Gardez à l'esprit que ce problème affecte uniquement les systèmes Apple Lion qui utilisent LDAP pour l'authentification. Dans la plupart des organisations, ce sera un très petit nombre de clients. Un serveur Apple Lion pourrait être plus vulnérable, mais Apple doit élaborer sur le problème et ils n'ont pas encore été très ouverts sur ce problème. Pouvez-vous imaginer RedHat retenir des informations sur une vulnérabilité connue du public pendant si longtemps?


3

Le problème de la vulnérabilité est assez bien expliqué dans l'article lié par slashdot.

Le vrai problème est qu'une fois que quelqu'un arrive sur n'importe quelle machine Lion du réseau qui utilise LDAP comme méthode d'autorisation, vous pouvez lire le contenu du répertoire LDAP. Ce qui vous donnerait accès à tous les comptes du réseau qui utilisent l'authentification centrale. De plus, il vous donne accès à tout ce qui est sécurisé par le système d'autorisation LDAP. Fondamentalement, vous possédez maintenant tout sur ce réseau.

En remarque, je suis curieux de savoir s'il s'agit d'un bogue dans l'autorisation LDAP ou dans le système d'authentification sous-jacent (probablement kerboros).

De plus, si vous n'utilisez pas LDAP comme source d'autorisation (OpenLDAP, Active Directory, NDS, etc.), cela ne vous affecte pas.

Pour répondre à votre question spécifique:

Quelqu'un peut-il expliquer exactement ce qui est sécurisé par OpenLDAP

La réponse est "Cela dépend ..." de ce que votre infrastructure informatique a configuré pour utiliser LDAP pour l'autorisation.


3
De plus, il vous donne accès à tout ce qui est sécurisé par le système d'autorisation LDAP. - Comment est-il possible de prendre un client LDAP cassé (ou un client LDAP malicieusement personnalisé) et de l'utiliser pour accéder à des ressources sécurisées par LDAP? Cela ne nécessiterait-il pas une faille dans le protocole LDAP ou sur le serveur LDAP lui-même?
Stefan Lasiewski

Pour être clair, mes questions concernent les autres ressources du réseau ("Fondamentalement, vous possédez maintenant tout sur ce réseau.").
Stefan Lasiewski

Êtes-vous sûr de pouvoir lire / sauvegarder le contenu du répertoire? Comment cela serait-il accompli? Kerberos n'est pas requis dans une configuration OSX. Un client acceptant un utilisateur non valide comme authentique ne signifie pas que le serveur l'acceptera comme authentifié. Si le serveur LDAP n'autorise pas les lectures anonymes et que l'utilisateur n'a pas fourni de mot de passe valide, comment pourraient-ils lire quoi que ce soit?
Zoredache

C'est un répertoire. Bien sûr, les utilisateurs peuvent lire des choses dans des répertoires. Pouvez-vous lire l'attribut userPassword sans liaison?
jldugger

@jldugger, Sur mon répertoire (pas OD), vous ne pouvez même pas obtenir une liste d'utilisateurs sans une liaison réussie. Je ne connais pas vraiment bien OSX, crée-t-il un ensemble d'informations d'identification par machine (comme AD), je ne le pensais pas, mais je peux me tromper. S'il n'y a pas d'informations d'identification pour la machine et qu'Apple ne fait pas quelque chose de stupide comme stocker une copie réversible du mot de passe, alors je ne sais pas comment un bogue de mise en cache du client signifie que vous obtenez un accès gratuit au répertoire.
Zoredache
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.