Les cyberattaques ciblant les informations d’identification des ressources telles que les jetons de session sont en augmentation.
Des cas récents très médiatisés tels que les fuites de code source des référentiels GitHub de Slack en janvier 2023, CircleCI en janvier 2023, et avant cela, les comptes GitHub en avril 2022 et Okta en décembre 2022, témoignent de cette tendance. Dans ce court article, nous passons brièvement en revue l’attaque et expliquons comment l’utilisation d’environnements de développement conteneurisés (CDE) en ligne et sécurisés est un excellent moyen de protéger votre processus DevOps et de mettre en œuvre une infrastructure de développement de code robuste pour prendre en charge les pratiques DevSecOps.
Les jetons de session sont le mécanisme général utilisé pour identifier et authentifier les utilisateurs dans les applications Web telles que GitHub. Ils stockent un identifiant unique pour la session d’un utilisateur et lui permettent de se connecter et d’utiliser l’application. Stocké côté client, si un utilisateur malveillant s’empare d’un token, il peut être utilisé pour récupérer des données et effectuer des actions sur l’application web. C’est ce qui s’est passé dans les cas ci-dessus. Par exemple, pour CircleCI, les machines ont été compromises à l’aide de logiciels malveillants qui contournaient les solutions antivirus.
Dans les cas ci-dessus, le vol de jetons a entraîné des fuites de code source car ils ont été utilisés pour accéder aux référentiels de code. Les fuites de code ont de graves conséquences pour les organisations, notamment des risques de sécurité, le vol de propriété intellectuelle, des atteintes à la réputation, des problèmes juridiques et des pertes financières. Mais plus généralement, toute application web utilisée par l’organisation, y compris celles contenant des informations personnelles, est accessible selon la même technique. Ainsi, les victimes peuvent être condamnées à de lourdes amendes par les régulateurs.
Comment fonctionnent les attaques Oauth via des jetons de session volés ?
Le vol de jetons de session résulte souvent d’une attaque de phishing réussie – voir (1) dans le diagramme suivant. L’attaque infecte l’appareil de la victime avec un logiciel malveillant qui effectue le vol.
Une fois infecté, le logiciel malveillant vole un jeton de session en le capturant pendant son transit lors de sa transmission entre le client et le serveur ou en injectant un code malveillant dans l’application côté client pour voler le jeton de l’appareil de l’utilisateur. Le jeton est ensuite exfiltré vers un serveur distant contrôlé par l’attaquant. Cela se produit pendant les étapes (2) à (5) ci-dessous.
Une fois en possession du jeton – voir (6) et (7) – le pirate contourne efficacement l’authentification multifacteur (MFA) et démarre une session illégitime. En plus d’accéder à des informations propriétaires, le jeton pourrait lui permettre d’élever les privilèges sur l’application cible avec des résultats potentiellement désastreux. Ensuite, le pirate peut effectuer des actions privilégiées telles que modifier ou supprimer des données ou même modifier les configurations du système.
Empêcher le vol de jetons de session est une tâche difficile, notamment en raison de l’étendue de la surface d’attaque, c’est-à-dire de tous les endpoints utilisés par les développeurs. Les surveiller de près est intimidant pour les petites et les grandes entreprises.
Les CDE et la gestion des informations d’identification empêchent les attaques de jetons à grande échelle
Les environnements de développement conteneurisés (CDE) sont généralement des conteneurs Docker ou Podman qui définissent des environnements de développement complets sous forme de code. Les développeurs peuvent utiliser des CDE sur leurs ordinateurs portables pour isoler les dépendances de code et rendre les applications facilement portables.
Plus récemment, des fournisseurs tels que Microsoft et Google ont commencé à proposer des CDE accessibles en ligne (par opposition aux CDE installés localement). Ils constituent le moyen idéal pour déployer un processus DevOps efficace. Les CDE en ligne sont particulièrement pratiques pour les entreprises dont la main-d’œuvre est répartie ou distante. Les CDE sont accessibles via un IDE cloud tel que Microsoft Visual Studio Code, un terminal ou un IDE installé localement qui prend en charge les CDE distants.
Cependant, pour les organisations qui ont besoin d’un processus DevSecOps efficace, la plate-forme de gestion de CDE basée sur Kubernetes que nous avons développée ici chez Strong Network va encore plus loin et propose des CDE en ligne avec une sécurité intégrée contre l’exfiltration de données. Cela inclut notamment un mécanisme d’authentification unique (SSO) pour les ressources des développeurs telles que les référentiels GIT, les services réseau, etc. La sécurité intégrée combinée à l’accès en ligne omniprésent des CDE permet à DevSecOps de fonctionner à grande échelle, quel que soit l’emplacement du développeur. Notre plate-forme est la seule plate-forme dotée d’un tel mécanisme et est disponible sur tous les principaux services cloud.
Étant donné que les développeurs sont fréquemment ciblés par le phishing et d’autres techniques d’ingénierie sociale, dès le départ, l’utilisation de CDE en ligne pour le développement supprime les données de développement de leurs ordinateurs portables. Par conséquent, le code source du conteneur est hors de portée des logiciels malveillants installés localement. Cependant, les jetons doivent être traités séparément,
Voici comment nos CDE (via leur sécurité intégrée) sont un mécanisme efficace pour contrecarrer le vol de jetons de session.
Premièrement, ils laissent des jetons aux ressources de l’organisation hors de portée des développeurs et de leur environnement.
La protection des jetons nécessite une approche à multiples facettes en raison de la diversité des informations d’identification utilisées pour authentifier l’interaction entre les développeurs et les outils tout au long du processus DevOps. Dans ce cas, nous nous concentrons sur les outils de gestion de référentiel de code basés sur GIT.
Nous devons d’abord protéger le jeton de session renvoyé à la suite d’une authentification basée sur les informations d’identification avec MFA. Ce jeton est conservé sous le contrôle de l’organisation à l’aide d’une authentification déléguée via un fournisseur d’identité (pensez à Azure AD ou Okta), conjointement avec l’accès à l’application Web, par exemple GitHub, via l’isolement du navigateur distant et la liste blanche d’URL.
Nous utilisons une version sécurisée du navigateur Chrome dans le cadre de notre plate-forme pour authentifier l’utilisateur auprès de GitHub et conserver le jeton de connexion isolé dans le navigateur. Même s’il existait un moyen de compromettre le navigateur distant, la liste blanche des URL accessibles empêchera une infection.
Une fois que le développeur est authentifié auprès de l’application de référentiel de code, nous devons protéger les informations d’identification utilisées pour pousser et extraire le code à l’aide du protocole GIT. Ces opérations peuvent être effectuées à l’aide de clés SSH ou de jetons OAuth. Dans les deux cas, nous gardons ces informations d’identification hors de portée des développeurs via l’utilisation d’un mécanisme de proxy qui détermine les droits de contrôle d’accès via un modèle RBAC pour l’utilisateur et les autorisations associées au CDE. Ce mécanisme à deux niveaux ci-dessus prend soin de protéger les informations d’identification du référentiel contre les fuites et est illustré de manière simple dans le diagramme ci-dessous.
Nous avons maintenant besoin d’un moyen de protéger le jeton de connexion de l’interface utilisateur Web de notre plate-forme. Cette plate-forme donne accès aux espaces de travail du développeur, aux applications de navigateur sécurisées et à d’autres outils. Voici donc la deuxième partie de la recette :
Nous surveillons l’accès à l’interface utilisateur Web Strong Network avec une attestation client dynamique
Une façon d’empêcher le vol du jeton pour notre application est de déterminer avec un certain degré de confiance que le client utilisant le jeton est celui qui l’a demandé à l’origine. Ceci est appelé attestation client et fonctionne en mesurant une série de «signaux» provenant des clients qui permettent au back-end de déterminer la légitimité des demandes.
Bien sûr, un attaquant très motivé et ingénieux pourrait être en mesure de contourner l’attestation en reproduisant la bonne empreinte. Cependant, cela nécessiterait une analyse du mécanisme basé sur le client (donc un accès complet à celui-ci), en plus de lever la clé utilisée pour chiffrer la charge utile de l’attestation (ce qui n’est pas trivial si la cryptographie en boîte blanche est utilisée). Si cette entreprise complexe réussit et que l’attaquant accède à notre plate-forme via un jeton volé, les informations d’identification aux ressources de l’organisation sont toujours hors de portée (voir le schéma ci-dessous).
Et même dans le cas où l’utilisateur malveillant arrive sur notre plateforme, le mécanisme de menace interne en place détectera tout comportement anormal du développeur. Un tel comportement consisterait, par exemple, à compresser l’intégralité de la base de code et à l’envoyer à un serveur non reconnu.
Nous espérons que ce court article a été utile et informatif, en particulier en montrant comment les plateformes de développement de code en ligne qui fournissent des CDE sont une première ligne de défense pour les ressources des organisations, à condition que les bons mécanismes de sécurité soient en place.
Dans notre série de blogs sur la sécurité, nous continuerons à discuter de certains des piratages récents et à explorer comment notre plate-forme de CDE sécurisés en ligne peut constituer une première ligne de défense pour les organisations soucieuses de la sécurité.