Que sont les attaques par injection LDAP et comment les prévenir

Les attaques par injection de code font partie des attaques en ligne les plus courantes et les plus réussies. Applications Web, applications mobiles, programmes de bureau, API s, bases de données , les serveurs Web, etc., peuvent tous être vulnérables aux attaques par injection de code s'ils acceptent les entrées de l'utilisateur sans validation appropriée.

L’une des attaques par injection de code les plus courantes est l’injection LDAP, et c’est ce dont nous allons discuter dans cet article. Nous examinerons ce qu'est LDAP, comment fonctionne l'injection LDAP et fournirons des conseils pour atténuer cette attaque.

Qu’est-ce que LDAP ?

LDAP signifie Lightweight Directory Access Protocol. Il s'agit d'un protocole de service d'annuaire utilisé pour rechercher des listes d'annuaires dans une base de données LDAP, le plus souvent des noms d'utilisateur et des mots de passe. Comme son nom l'indique, LDAP est très léger et, de ce fait, il s'adapte très bien et est aujourd'hui utilisé par un grand nombre d'organisations.

Un annuaire LDAP est constitué d'attributs basés sur le schéma LDAP. Chaque entrée du schéma/répertoire est dotée d'un identifiant unique appelé nom distinctif (DN). Vous trouverez ci-dessous un exemple d'entrée pour l'utilisateur fictif, Johnnyny Theguy.

|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|

De nombreuses organisations utilisent LDAP pour authentification unique pour permettre aux employés d'accéder à plusieurs applications au sein du réseau d'entreprise sans qu'ils aient besoin de se connecter à chaque application. Mais au-delà de la simple validation des informations d'identification des utilisateurs, LDAP est utilisé pour répondre aux requêtes d'informations et comprend également diverses commandes utilisées pour gérer les bases de données LDAP. Et cela est logique, étant donné la quantité d’informations (au-delà des noms d’utilisateur et des mots de passe) que contiennent les bases de données LDAP, ce qui met également en évidence les dangers des attaques par injection LDAP.

Requêtes LDAP

Les requêtes LDAP soumises au serveur sont appelées filtres de recherche LDAP et sont construites à l'aide d'une notation de préfixe. Une requête LDAP typique implique généralement les éléments suivants :

• Connexion de session : L'utilisateur se connecte au serveur LDAP.
• Demande : L'utilisateur soumet une requête au serveur (une recherche d'utilisateur, par exemple).
• Réponse : Le protocole LDAP interroge l'annuaire, localise les informations demandées et les fournit à l'utilisateur.
• Achèvement : L'utilisateur se déconnecte du serveur LDAP.

Une fois dans la base de données, les utilisateurs peuvent formuler des requêtes pour exécuter des opérations sur le serveur LDAP. Vous trouverez ci-dessous une liste des opérations courantes que la base de données/le serveur LDAP peut effectuer :

• Ajouter : Utilisé pour ajouter de nouvelles données à la base de données.
• Lier (authentifier) : Utilisé pour l'authentification et le cryptage.
• Supprimer : Utilisé pour supprimer des données de la base de données.
• Rechercher et comparer : L'opération Rechercher est utilisée pour rechercher et lire des entrées.
• Modifier : Utilisé par les clients LDAP pour demander au serveur LDAP d'apporter des modifications aux entrées existantes
• Délier : Utilisé pour fermer la connexion.

Dans ses requêtes, LDAP prend en charge les métacaractères suivants :

• & ET booléen
• | OU booléen
• ! Booléen NON
• = Équivaut à
• ~= Environ
• >= Plus grand que
• <= Moins que
• * N'importe quel caractère
• () Regroupement des parenthèses

Voici quelques exemples de requêtes LDAP.

Une demande d'authentification utilisateur typique (c'est-à-dire une connexion utilisateur) ressemblerait à ceci :

|_+_|

Si les informations d'identification envoyées correspondent à celles du serveur LDAP, l'utilisateur Johnny sera authentifié.

D'autres exemples seraient :

Recherchez tous les utilisateurs qui doivent modifier leur mot de passe lors de leur prochaine connexion :

|_+_|

Cette requête renverrait une liste de tous les utilisateurs trouvés dans la base de données qui ont l'attribut pwdLastSet avec la valeur : 0.

Trouvez tous les utilisateurs avec « pass » ou « pwd » dans leur description

|_+_|

Cette requête renverrait une liste de tous les utilisateurs trouvés dans la base de données pour lesquels les attributs pass ou pwd sont répertoriés.

Injection LDAP

Maintenant que nous comprenons ce qu'est LDAP et comment il fonctionne, tournons notre attention vers l'injection LDAP.

Une attaque par injection LDAP peut être absolument dévastatrice pour votre organisation. Cela est dû à la quantité d’informations de grande valeur qu’une base de données LDAP peut contenir. Nous parlons de noms, noms d’utilisateur, mots de passe, adresses e-mail, numéros de téléphone, titres de poste, autorisations, etc.

Ajoutez à cela le fait qu’une attaque par injection LDAP peut signifier beaucoup de choses. En d’autres termes, les attaques par injection LDAP sont multi-vecteurs. Un attaquant peut exploiter un système LDAP non sécurisé de différentes manières. Ils pourraient insérer un code malveillant leur permettant de visualiser tous les noms d'utilisateur et mots de passe contenus dans la base de données. Ils peuvent également s'ajouter en tant qu'utilisateur dans la base de données LDAP avec les autorisations d'administrateur système. Un attaquant pourrait même contourner complètement l’exigence de noms d’utilisateur et de mots de passe. Le point crucial d’une attaque par injection LDAP est de fournir au serveur une requête qui incitera le serveur à valider la requête comme étant vraie ou valide.

De nombreux facteurs entrent en jeu pour faire réussir ou échouer une attaque par injection LDAP : le niveau de connaissances et de compétences de l’attaquant, les mesures de sécurité informatique de l’organisation et les informations contenues dans la base de données LDAP, par exemple. Quoi qu’il en soit, une attaque par injection LDAP réussie sera généralement une grande victoire pour l’attaquant et une souffrance considérable pour l’organisation compromise.

Examinons quelques exemples de la manière dont cela pourrait être réalisé.

Exemples d'attaques par injection LDAP

Contourner l'authentification avec le métacaractère « & »

Prenons notre premier exemple de requête ci-dessus concernant une connexion utilisateur :

|_+_|

Sur une base de données LDAP vulnérable, un acteur malveillant pourrait contourner complètement le mécanisme d'authentification en créant une requête malveillante en insérant le métacaractère & entre les attributs utilisateur et mot de passe de la requête. Cela ressemblerait à ceci :

|_+_|

Étant donné que LDAP analyse uniquement les deux premiers attributs, l'instruction devient équivalente à :

|_+_|

Si la requête ci-dessus était exécutée sur une base de données/un serveur LDAP vulnérable, le résultat serait renvoyé comme vrai et notre utilisateur malveillant « peu importe » serait authentifié.

Contourner l'authentification avec les métacaractères « * » et « | »

Utilisons un exemple similaire à celui ci-dessus (« cn » signifie nom commun) :

|_+_|

Nous pouvons obtenir la même chose que ci-dessus en utilisant les caractères * et | métacaractères. Si nous définissons la valeur du nom d'utilisateur sur |_+_|, le filtre de recherche devient :

|_+_|

Étant donné que LDAP analyse uniquement les deux premiers attributs, la requête ci-dessus est toujours renvoyée comme vraie. Cette requête permettrait à un attaquant de contourner le mécanisme d’authentification de LDAP sans validation appropriée des entrées.

Liste de tous les utilisateurs de la base de données avec '*'

La requête ci-dessous est une requête de recherche LDAP.

|_+_|

La notation de filtre de préfixe ci-dessus demande à la requête de rechercher un nœud LDAP avec le nom d'utilisateur et le mot de passe donnés. Cependant, si la base de données LDAP est vulnérable à l'injection LDAP, un attaquant pourrait remplacer le cn et le mot de passe dans l'exemple ci-dessus par *, comme ceci :

|_+_|

Cela modifierait la signification souhaitée de la requête et la base de données renverrait une liste de tous les utilisateurs.

Les risques liés à l’injection LDAP

Les dommages pouvant résulter des attaques par injection LDAP sont similaires à ceux d’autres attaques par injection. Injecter du code dans un serveur implique la capacité d’obtenir des informations et de modifier des informations. Par conséquent, les attaques par injection LDAP peuvent conduire aux événements suivants :

Fuite de données sensibles

Comme nous l'avons vu avec notre dernier exemple, il est possible de manipuler des requêtes LDAP envoyées à un serveur vulnérable pour lister des informations involontaires. Dans notre exemple ci-dessus, nous avons montré comment une requête malveillante pouvait amener la base de données à afficher la liste de tous les utilisateurs de la base de données.

Cependant, si le serveur est vulnérable à l'injection LDAP, il pourrait être manipulé pour générer d'autres données sensibles. Les bases de données LDAP ont tendance à stocker plus de données que de simples noms d'utilisateur et mots de passe, ce qui serait déjà suffisamment dommageable en cas de fuite. De ce fait, un attaquant pourrait créer des requêtes LDAP pour obtenir des informations sensibles telles que des adresses e-mail, des numéros de téléphone et même des numéros de sécurité sociale. Ainsi, en plus des comptes compromis et des accès non autorisés aux ressources de l'entreprise (qui peuvent être dévastateurs), l'injection LDAP pourrait également conduire à un vol d'identité ciblé. Hameçonnage campagnes, etc. Méchant.

Attaques par déni de service

Les attaques par injection LDAP peuvent également conduire à des attaques simples et très efficaces. attaques par déni de service (DoS) . Cette attaque peut être lancée contre l'application qui interagit avec le serveur d'annuaire ou contre le serveur d'annuaire lui-même. Si un attaquant parvient à créer suffisamment de requêtes LDAP malveillantes qui prennent beaucoup de temps et sont gourmandes en ressources, il pourrait consommer toutes les ressources disponibles et empêcher les autres requêtes de passer.

De plus, supposons que l’application ait été conçue pour conserver en mémoire toutes les entrées renvoyées par une requête de recherche. Dans ce cas, une requête destinée à renvoyer beaucoup plus d'entrées que prévu pourrait conduire l'application à consommer toute sa mémoire disponible pour traiter cette requête. Le résultat serait que l’application plante.

Fichiers modifiés et corruption des données

Nous avons vu comment une requête conçue de manière malveillante pouvait exposer des données involontaires à l'attaquant. Mais il est également possible de tromper la base de données pour qu'elle mette à jour des fichiers involontaires, soit avec du courrier indésirable, pour corrompre le fichier, soit en modifiant les mots de passe pour ceux définis par l'attaquant. Si l'attaquant peut tromper l'application en lui faisant rechercher les mauvaises entrées, il peut la tromper en mettant à jour les entrées incorrectes, ce qui pourrait entraîner une perte ou une corruption de données.

Comment prévenir les attaques par injection LDAP

Maintenant que vous connaissez les menaces, voici quelques précautions que vous pouvez prendre pour prévenir les attaques par injection LDAP.

Appliquer la validation des entrées

En d’autres termes : ne faites pas confiance aux entrées des utilisateurs. Quel que soit le type d’utilisateur (authentifié, interne ou public), considérez cette entrée comme non fiable. Si possible, empêchez vos applications de copier des données contrôlables par l'utilisateur dans des requêtes LDAP. Si cela n'est pas réalisable, assurez-vous de valider les entrées de l'utilisateur par rapport à une liste de chaînes ou de caractères autorisés. Et cette validation doit toujours avoir lieu côté serveur même si l'entrée a été préalablement validée côté client.

Vous pouvez utiliser un modèle d'expression régulière solide pour valider les entrées structurées telles que les numéros de sécurité sociale, les numéros de téléphone et les adresses e-mail. Les entrées telles que les noms d'utilisateur doivent être validées par rapport à un ensemble de caractères approuvé qui exclut les métacaractères LDAP. Les caractères qui doivent être bloqués incluent ( ) ;, * | &= et espace

Entrée d'échappement avec encodage

Échappez les chaînes d’entrée contrôlées par l’utilisateur afin que les caractères de contrôle présents dans l’entrée ne modifient pas la signification prévue du filtre de recherche LDAP. Par exemple, dans une application Java, les métacaractères d'une requête LDAP peuvent être saisis avec des barres obliques inverses comme caractères d'échappement. De cette façon, les entrées non fiables sont ajoutées à une requête de recherche sous forme de valeurs de chaîne littérale, et non sous forme de prédicats LDAP.

Il est également fortement recommandé d’utiliser les bibliothèques existantes pour s’échapper – n’écrivez pas les vôtres, car vous risqueriez d’introduire des vulnérabilités involontaires.

Mettre en œuvre le principe du moindre privilège

Le principe du moindre privilège est une politique de sécurité informatique qui stipule qu'il convient d'attribuer uniquement les droits minimaux nécessaires à un utilisateur nécessitant l'accès à une ressource. Ces droits devraient également être en vigueur pour la durée la plus courte possible. Plus précisément, le compte LDAP utilisé pour lier l'annuaire dans une application doit avoir un accès restreint. Seules les requêtes LDAP autorisées doivent être exécutées sur le serveur LDAP.

Conclure

Voilà donc les tenants et les aboutissants des attaques par injection LDAP. Elles sont plutôt malveillantes et, comme la plupart (sinon la plupart) des attaques en ligne, leurs conséquences pourraient être catastrophiques. Comme c’est souvent le cas pour ce type d’attaques, la désinfection des entrées des utilisateurs est ici la mesure d’atténuation la plus cruciale. Ne pas nettoyer les entrées de vos utilisateurs, c'est comme avoir la porte d'entrée de votre maison déverrouillée : n'importe qui peut simplement tourner le bouton et entrer. Ce n'est pas ce que vous voulez avec une application/un serveur Web. Espérons que les conseils décrits ci-dessus vous aideront à éviter ce scénario.

Comme toujours, restez en sécurité.