Actuellement, les utilisateurs d’Azure ont la possibilité de se connecter à leurs serveurs bastion via des connexions SSH et RDP avec un client natif ou en utilisant l’interface web. Cependant, il est possible d’effectuer des attaques contre les VM Azure via Azure Bastion et son client natif.
D’après la documentation de Microsoft, il existe deux options par lesquelles un utilisateur peut établir une connexion avec le client natif à un serveur bastion. Celui qui peut être utilisé par un attaquant est celui dans lequel un plus grand nombre d’options concernant la connexion peuvent être spécifiées :
az network bastion tunnel --name "" --resource-group "" --target-resource-id "" --resource-port "" --port ""Lorsque vous exécutez la commande ci-dessus, Azure CLI crée un tunnel et écoute sur un port local. C’est en se connectant à ce port local avec le client natif que l’utilisateur accède à la VM interne via le protocole utilisé (par exemple RDP).
Source: Codyburkard.com
Pour comprendre le processus d’attaque, il faut d’abord voir comment se déroule le flux de travail du client natif :
Source de l’image : Codyburked.com
Après avoir reçu une commande via l’API pour démarrer une nouvelle session, Azure Bastion effectue trois actions :
- Crée une connexion TCP entre le serveur Bastion et la VM cliente, sur le port spécifié dans la requête API.
- Il crée une nouvelle clé de session associée à ce port.
- Il accepte une nouvelle connexion websocket en utilisant la clé de session, et transfère toutes les informations de la connexion websocket à la connexion TCP de la VM interne.
Du côté client, Azure CLI effectue les opérations suivantes :
- Écoute sur un port local.
- Il accepte les nouvelles connexions sur ce port, et pour chaque connexion, il appelle l’API du service de base pour démarrer une nouvelle session, comme décrit ci-dessus.
- Il crée un nouveau thread qui transfère toutes les informations reçues sur la nouvelle connexion au tunnel websocket vers le bastion.
Ainsi, en activant cette configuration, les utilisateurs finaux peuvent communiquer directement avec la VM interne par le biais d’une connexion websocket, un processus complètement différent de celui d’un serveur de bastionnement traditionnel, qui ne communique que par le biais du protocole du service utilisé pour l’accès à distance (RDP ou SSH, dans ce cas).
En outre, le fait de pouvoir spécifier un port signifie que les services internes de la VM peuvent être analysés à l’aide d’Azure Bastion, et que les ports qui exposent des services vulnérables peuvent être accessibles et exploités par toute personne demandant une session de bastionnement pour une VM particulière.
Toutefois, pour pouvoir mener des attaques contre les VM Azure via Azure Bastion, l’utilisateur en question doit disposer d’un certain nombre d’autorisations et de conditions préalables :
- Un rôle RBAC Azure en lecture doit être attribué à la VM.
- Un rôle RBAC Azure en lecture doit être attribué à la carte réseau associée à l’adresse IP privée.
- Un rôle RBAC Azure en lecture doit être attribué au service Azure Bastion.
- Le réseau doit inclure des routes qui permettent au sous-réseau Azure Bastion de communiquer avec la VM, soit sur le même VNet, soit via un peering VNet.
Les recommandations pour prévenir ce type d’attaque comprennent la désactivation du support du client natif des services de bastionnement. Toutefois, si cela n’est pas possible, les mesures suivantes peuvent être prises pour atténuer le problème dans une certaine mesure :
- Assurez-vous que le sous-réseau sur lequel Azure Bastion est déployé possède un groupe de sécurité réseau (NSG) associé, afin que la connectivité soit limitée aux ports 3389 et 22.
- Limitez le nombre d’utilisateurs qui ont un accès RBAC en lecture à une ressource privilégiée, comme le groupe admin root.
- Incluez une règle NSG sur le sous-réseau de base qui limite la connectivité à une adresse IP spécifique ou à de petites plages de sous-réseau.
Plus d’information:
https://codyburkard.com/blog/bastionabuse/
Laisser un commentaire