Série Coders Conquer Security Infrastructure as Code : Contrôle d'accès aux fonctions manquant

Voici le nouvel épisode de notre série sur l'Infrastructure as Code, des articles conçus pour aider les développeurs comme vous à atteindre un niveau supérieur de sensibilisation à la sécurité lors du déploiement d'infrastructures sécurisées au sein de votre organisation.

Au fait... comment vous en êtes-vous sorti avec le défi sur les erreurs de configuration de sécurité dans l'article précédent ? Si vous souhaitez vous attaquer dès maintenant à une vulnérabilité liée à l'absence de contrôle d'accès au niveau des fonctions, rendez-vous sur la plateforme :

(Le lien ci-dessus vous mènera au défi Kubernetes, mais une fois sur la plateforme, utilisez le menu déroulant pour choisir également parmi Ansible, CloudFormation, Terraform ou Docker. À vous de choisir.)

Presque toutes les applications déployées aujourd'hui disposent d'un mécanisme de contrôle d'accès qui vérifie si un utilisateur est autorisé à effectuer les fonctions demandées. C'est pratiquement la pierre angulaire d'une bonne sécurité, ainsi que de la fonctionnalité, lors de la création d'une application. En fait, toutes les applications web ont besoin de contrôles d'accès pour permettre aux utilisateurs ayant des privilèges différents d'utiliser le programme.

Des problèmes peuvent toutefois survenir lorsque ces mêmes fonctions de vérification du contrôle d'accès ne sont pas effectuées au niveau de l'infrastructure, ou sont mal configurées. Sans un contrôle d'accès parfaitement ordonné au niveau de l'infrastructure, l'entreprise entière est exposée aux pirates informatiques, qui peuvent utiliser cette vulnérabilité comme porte d'entrée pour de l'espionnage non autorisé ou une attaque complète.

En réalité, l'exploitation de vulnérabilités dues à une absence ou une mauvaise configuration du contrôle d'accès aux fonctions est extrêmement simple. Les attaquants n'ont même pas besoin d'être très qualifiés. Il leur suffit de connaître les commandes qui exécutent les fonctions au sein du framework supportant l'application. Si c'est le cas, ce n'est qu'une question d'essais et d'erreurs. Ils peuvent soumettre continuellement des requêtes qui ne devraient pas être autorisées, et dès que l'une d'elles réussit, le site web, l'application, le serveur ou même le réseau entier ciblé pourrait être exposé.

Comment fonctionnent les exploits liés à l'absence de contrôle d'accès au niveau des fonctions ?

Il existe plusieurs façons dont les problèmes de contrôle d'accès au niveau des fonctions peuvent s'introduire dans une organisation. Par exemple, le contrôle d'accès au niveau des fonctions peut être laissé à l'application sans être vérifié par l'infrastructure sous-jacente. Ou bien, le contrôle d'accès au niveau de l'infrastructure peut être mal configuré. Dans certains cas, les administrateurs supposent que les utilisateurs non autorisés ne sauront pas comment accéder aux ressources d'infrastructure réservées aux utilisateurs de haut niveau, en utilisant un modèle de « sécurité par l'obscurité » qui fonctionne rarement.

Pour illustrer la sécurité par l'obscurité, l'URL suivante est probablement vulnérable aux attaques :

http://companywebsite.com/app/NormalUserHomepage

Si un utilisateur authentifié utilise une technique appelée « Forced URL Browsing » (navigation forcée par URL), il pourrait tenter d'atteindre une page réservée aux administrateurs. Par exemple :

http://companywebsite.com/app/AdminPages

S'il n'existe aucune vérification côté serveur, les pages d'administration lui seront simplement affichées (si le nom correspond à la requête) et il aura alors accès à toutes les fonctions supplémentaires réservées aux administrateurs. Si le serveur renvoie une erreur « page non trouvée » à l'attaquant, celui-ci peut simplement continuer à essayer jusqu'à ce qu'il découvre le nom donné à la page d'administration.

Pour les attaquants, l'exploitation de l'absence de contrôle d'accès au niveau des fonctions suit un processus similaire. Au lieu d'essayer de parcourir des pages non autorisées, ils envoient des requêtes de fonction. Par exemple, ils pourraient tenter de créer un nouvel utilisateur avec des droits d'administrateur. Leur requête ressemblerait donc à ceci, selon le framework utilisé :

POST/action/createuser name=hacker&pw=password&role=admin

S'il n'existe aucun contrôle d'accès au niveau des fonctions, l'exemple ci-dessus aboutirait et un nouveau compte administrateur serait créé. Une fois que l'attaquant se reconnecte en tant que nouvel administrateur, il dispose des mêmes accès et permissions que n'importe quel autre administrateur sur ce réseau ou ce serveur.

Comment remédier aux contrôles d'accès aux fonctions manquants

Comme il est très facile pour les attaquants d'exploiter les vulnérabilités liées à l'absence de contrôle d'accès au niveau des fonctions, il est crucial de les détecter, de les corriger et de les prévenir. Heureusement, cela n'est pas trop difficile avec un peu de savoir-faire et une formation de base en sécurité de l'Infrastructure as Code.

La protection principale consistera à mettre en œuvre une autorisation basée sur les rôles au niveau de l'infrastructure. Ne confiez jamais cette fonction aux applications. Même si elles le font, disposer d'une autorisation côté infrastructure garantira qu'aucune faille ne subsiste. Idéalement, l'autorisation doit provenir d'un emplacement centralisé (par exemple, AWS IAM, Azure IAM, etc.) intégré aux processus de votre organisation et appliqué à chaque nouvelle application. Ces processus d'autorisation peuvent provenir du framework lui-même ou de nombreux modules externes faciles à utiliser.

Enfin, votre organisation doit adopter le concept du moindre privilège. Toutes les actions et fonctions doivent être refusées par défaut, le processus d'autorisation étant utilisé pour accorder aux utilisateurs valides la permission d'effectuer ce dont ils ont besoin. Ils ne doivent recevoir que les permissions nécessaires à l'exécution de la fonction requise, et uniquement pour la durée nécessaire.

L'absence de contrôles d'accès au niveau des fonctions peut avoir des conséquences dévastatrices. Heureusement, en intégrant de bonnes pratiques d'autorisation au niveau de l'infrastructure dans votre organisation, vous pouvez facilement empêcher ce problème de se produire.

Vous pensez être prêt à repérer une faille de contrôle d'accès en conditions réelles ? Comparez ces extraits de code Docker : l'un est vulnérable, l'autre est sécurisé.

Vulnérable :

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Sécurisé :

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

Apprenez-en plus et relevez le défi

Consultez les pages du blog de Secure Code Warrior pour obtenir plus d'informations sur cette vulnérabilité et savoir comment protéger votre organisation et vos clients contre les ravages d'autres failles et vulnérabilités de sécurité.

Et si vous l'avez manqué, vous pouvez essayer un défi de sécurité gamifié sur l'IaC sur la plateforme Secure Code Warrior pour garder toutes vos compétences en cybersécurité aiguisées et à jour.

Restez à l'écoute pour le prochain chapitre !