Des attaquants qui ont compromis Railway, un fournisseur d’hébergement cloud, ont utilisé des clés d’API de clients volées pour générer environ 740 000 dollars de frais d’IA non autorisés, a révélé l’entreprise dans un rapport d’incident publié le 10 novembre. Railway affirme qu’elle remboursera les clients concernés lorsque les fournisseurs d’IA refuseront de rembourser cette consommation frauduleuse.
L’attaque s’est produite les 20 et 21 octobre et a exploité plusieurs faiblesses de l’infrastructure, qui ont permis aux intrus d’accéder à des secrets chiffrés de clients et d’obtenir les identifiants nécessaires pour en déchiffrer certains. Railway estime que les variables d’environnement de jusqu’à 100 000 espaces de travail pourraient avoir été exposées.
L’enquête de l’entreprise a établi que les attaquants ciblaient spécifiquement les identifiants de fournisseurs d’IA, que Railway pense destinés à être revendus ou utilisés pour la distillation de modèles d’IA. Le réseau de distribution présumé et l’identité des responsables restent à confirmer.
Les attaquants ont exploité plusieurs faiblesses pour accéder aux secrets des clients
Selon le rapport d’incident de Railway, l’intrusion a commencé à 7 h 28 UTC le 20 octobre, lorsque les attaquants ont exploité une vulnérabilité inconnue de l’infrastructure de compilation de l’entreprise.
La faille a permis de s’échapper partiellement de l’isolation du système de fichiers, exposant un identifiant interne utilisé par les services de compilation de Railway.
Les attaquants ont ensuite utilisé cet identifiant pour récupérer les historiques de compilation stockés et une copie du code source interne de Railway. Ils ont examiné le code à la recherche d’autres voies d’accès et découvert une relation de confiance OpenID Connect (OIDC) mal configurée.
Le 21 octobre, les attaquants avaient obtenu des identifiants cloud temporaires, pénétré dans l’infrastructure interne et accédé à un identifiant capable de déchiffrer les variables d’environnement des clients.
Les journaux de la base de données de Railway montrent que les attaquants recherchaient spécifiquement des clés de fournisseurs d’IA. D’autres requêtes ciblaient des identifiants liés au cloud, aux bases de données et aux services de paiement.
L’entreprise a détecté une activité suspecte à 13 h 58 UTC le 20 octobre et a complètement éliminé les attaquants à 9 h 24 UTC le lendemain.
Railway affirme avoir corrigé les faiblesses exploitées et déplacé les compilations vers des machines virtuelles éphémères dédiées, dotées de contrôles d’accès plus stricts.
Combien de clients ont été concernés ?
Railway a confirmé plusieurs catégories distinctes d’exposition :
- Jusqu’à 100 000 espaces de travail : Les variables d’environnement appartenant à au plus 1,85 % des espaces de travail auraient pu être déchiffrées. Il s’agit d’une exposition potentielle maximale, et non d’un nombre confirmé de victimes.
- 1 852 utilisateurs : Les jetons de comptes liés, notamment les jetons OAuth GitHub et les identifiants d’agents d’IA utilisant leurs propres clés, ont été confirmés comme déchiffrés. Railway a réinitialisé les jetons et averti les utilisateurs concernés.
- 353 historiques de compilation : Les attaquants ont accédé à des historiques de compilation stockés contenant des informations et des secrets liés aux compilations.
- $740,000: Estimation de Railway concernant la consommation d’IA frauduleuse associée aux identifiants compromis.
Railway n’a trouvé aucune preuve que les dépôts Git des clients aient été téléchargés ou que leurs bases de données aient été consultées. L’entreprise n’a pas non plus identifié de connexions à des comptes Railway effectuées avec des identifiants volés pendant l’incident.
La compromission ressemble à d’autres attaques visant des plateformes pour développeurs. En octobre, une faille chez Zeabur a exposé des millions d’enregistrements de variables d’environnement et soulevé des inquiétudes similaires concernant les secrets stockés dans des infrastructures de développement hébergées.
Des identifiants d’IA volés ont généré une consommation non autorisée
Railway pense que les attaquants ciblaient les clés d’IA pour les distribuer par l’intermédiaire de services qui relaient ou revendent l’accès à des modèles commerciaux.
Cette activité est souvent qualifiée de LLMjacking : des identifiants d’API volés sont utilisés pour consommer des services d’IA payants sans l’autorisation du titulaire du compte.
L’enquête de Railway a identifié des requêtes non autorisées impliquant des agents de programmation et des charges de travail liées à l’entraînement de l’IA. L’entreprise soupçonne que certains identifiants ont été utilisés pour la distillation de modèles, un procédé dans lequel les sorties d’un modèle servent à en entraîner un autre.
Cependant, Railway n’a pas identifié les opérateurs des services de distribution présumés ni confirmé que les attaquants d’origine les contrôlaient.
Des risques similaires de vol d’identifiants sont apparus lors de l’attaque de la chaîne d’approvisionnement de LiteLLM, qui impliquait des paquets malveillants conçus pour dérober des jetons et des données d’infrastructure sensibles.
Railway revient sur sa position concernant les remboursements
Le 26 octobre, Railway avait initialement indiqué aux clients concernés qu’elle ne pouvait pas rembourser les frais générés par des clés d’API compromises.
Son rapport du 10 novembre présente un engagement différent : l’entreprise coordonnera les remboursements avec les fournisseurs d’IA et couvrira les pertes liées aux jetons lorsque les fournisseurs refuseront de rembourser.
Les accords annoncés par l’entreprise comprennent :
- AWS Bedrock et Google Gemini : Les remboursements ont été lancés dans le cadre des politiques antifraude existantes.
- OpenAI : Les clients doivent ouvrir des dossiers auprès du support et fournir leurs identifiants de dossier à Railway pour un examen coordonné.
- Anthropic : Railway couvrira les frais concernés pendant la poursuite des discussions avec le fournisseur.
- OpenRouter : Railway couvrira les pertes, le fournisseur maintenant sa politique de non-remboursement.
- SpaceXSI : Les demandes sont examinées individuellement dans le cadre d’un support coordonné.
Railway a demandé à ses clients de signaler les frais non autorisés. Son annonce n’établit pas que tous les clients concernés ont été remboursés.
Que doivent faire les équipes de sécurité après la faille chez Railway ?
Railway conseille à ses clients de révoquer et de remplacer les identifiants sensibles stockés sur la plateforme avant le 21 octobre, même si aucune activité suspecte n’a été détectée.
Les mesures recommandées comprennent :
- Faites tourner les identifiants exposés. Révoquez les clés d’API potentiellement compromises auprès du fournisseur émetteur et remplacez-les dans les applications qui en dépendent.
- Examinez l’utilisation et la facturation. Examinez les journaux des fournisseurs d’IA à la recherche de requêtes inattendues, de charges de travail inconnues et de frais non autorisés.
- Auditez les comptes connectés. Vérifiez les journaux d’accès de GitHub, des services cloud, des registres de conteneurs et des bases de données pour détecter toute activité suspecte.
- Restreignez les autorisations. Utilisez des identifiants aux autorisations strictement nécessaires et des clés distinctes pour les différentes charges de travail lorsque cela est possible.
- Configurez les contrôles d’utilisation. Appliquez des quotas d’API, des plafonds de dépenses et des alertes d’anomalie lorsque les fournisseurs les proposent.
- Signalez les frais frauduleux. Conservez les justificatifs de facturation et envoyez vos demandes à Railway et au fournisseur d’IA concerné.
Les équipes de sécurité doivent également vérifier que les anciennes clés ont été révoquées, et pas simplement supprimées de la configuration des applications.
Les recherches sur le vol d’identifiants facilité par l’IA ont montré que des attaquants utilisaient des outils automatisés pour découvrir et valider des identifiants exposés dans des services cloud et d’IA.
Railway affirme avoir renforcé le stockage des secrets, restreint les autorisations de déchiffrement et mis en place une journalisation centralisée des opérations de chiffrement et de déchiffrement.
L’entreprise a également signalé l’incident à l’Internet Crime Complaint Center du FBI et continue de collaborer avec des enquêteurs légistes externes.
L’enquête n’a pas établi l’identité de l’attaquant ni la destination finale des identifiants volés. Railway prévoit de publier des indicateurs de compromission supplémentaires après avoir reçu l’autorisation des forces de l’ordre.
Pour les organisations concernées, la rotation des identifiants et l’examen de la facturation côté fournisseur restent nécessaires même après la correction de l’infrastructure de Railway. Les clés d’API volées peuvent continuer à autoriser des services externes tant que ces identifiants n’ont pas été invalidés.
À lire également : une deuxième faille de Fireworks AI a exposé les transcriptions de conversations de Notion AI, prolongeant les conséquences d’une compromission d’infrastructure cloud jusqu’aux clients en aval.