Intrusion Uber par Lapsus$ via ingénierie sociale

Le 15 septembre 2022, Uber a découvert qu'un attaquant s'était infiltré profondément dans son réseau interne. L'intrusion était frappante non par sa complexité technique mais par le peu de technique qu'elle comportait : l'attaque reposait presque entièrement sur l'ingénierie sociale et une attaque par épuisement MFA, exécutée par un acteur prétendant avoir 18 ans et lié par la suite au groupe Lapsus$.

Comment l'intrusion s'est déroulée

L'attaquant a commencé avec les identifiants volés d'un sous-traitant, très probablement achetés sur une place de marché du dark web après que l'appareil personnel du sous-traitant eut été infecté par un maliciel. Des identifiants valides ne suffisaient toutefois pas — le compte était protégé par une authentification multifacteur. L'attaquant a donc lancé une attaque par épuisement MFA (bombardement de notifications), déclenchant un déluge de notifications d'approbation de connexion vers le téléphone du sous-traitant pendant plus d'une heure.

Lorsque les notifications n'ont pas cessé, l'attaquant a contacté le sous-traitant sur WhatsApp, se faisant passer pour le support informatique d'Uber, et a affirmé que les notifications ne s'arrêteraient que si le sous-traitant en approuvait une. À bout, le sous-traitant a approuvé une notification — et l'attaquant était dans la place.

Élévation de privilèges

Un accès initial à un seul compte de sous-traitant serait normalement un problème circonscrit. Ce qui l'a transformé en une compromission quasi totale, c'est une aubaine de déplacement latéral : l'attaquant a découvert des scripts PowerShell sur un partage réseau interne contenant des identifiants administrateur codés en dur pour le système de gestion des accès à privilèges (Thycotic) d'Uber.

Ces identifiants étaient un passe-partout. Grâce à eux, l'attaquant a obtenu l'accès à :

• l'environnement AWS d'Uber ;
• Google Workspace (G-Suite) ;
• Slack, où l'attaquant a publié un message annonçant l'intrusion à toute l'entreprise ;
• le tableau de bord de bug bounty HackerOne — exposant potentiellement des vulnérabilités non corrigées signalées à Uber ;
• des outils internes de finance et vSphere.

L'attaquant a également reconfiguré l'OpenDNS d'Uber pour afficher une image sur certains sites internes, une fioriture théâtrale caractéristique de Lapsus$.

Impact et confinement

Uber a mis ses outils internes hors ligne et déclenché son processus de réponse à incident. De manière déterminante, l'enquête de l'entreprise a conclu que l'attaquant n'avait pas accédé aux systèmes de production qui font tourner les applications d'Uber, ni à aucun compte utilisateur, ni aux bases de données stockant des informations sensibles sur les utilisateurs. Aucun vol de données de paiement ou de trajet n'a été confirmé. L'attaquant a tout de même téléchargé certains messages Slack internes et des informations issues d'un outil interne de facturation financière.

Uber a publiquement attribué l'intrusion à un acteur affilié à Lapsus$, le même groupe à l'origine des intrusions de 2022 chez Microsoft, Cisco, Samsung, Nvidia et Okta. Parmi les membres du groupe figurait l'adolescent britannique Arion Kurtaj, reconnu par la suite responsable de l'intrusion chez Uber par un tribunal londonien, entre autres.

Pourquoi c'est important

L'intrusion d'Uber est la démonstration canonique que l'authentification multifacteur n'est pas une panacée. La MFA par notification, en particulier, est vulnérable aux attaques par épuisement où le maillon faible est l'humain — et non la cryptographie. L'incident a stimulé l'adoption massive de la MFA par correspondance de numéros et des facteurs FIDO2/WebAuthn résistants à l'hameçonnage, qui ne peuvent être approuvés d'une simple pression.

Tout aussi important fut le chemin d'élévation : des identifiants administrateur codés en dur dans un script PowerShell, sur un partage de fichiers accessible, ont transformé un seul sous-traitant compromis en une intrusion à l'échelle de tout l'environnement. Le cas est désormais un exemple pédagogique standard d'hygiène de gestion des secrets — les identifiants doivent résider dans un coffre-fort doté de contrôles d'accès et de rotation, jamais dans des scripts sur un partage réseau — et du principe selon lequel un point d'ancrage initial ne devrait jamais accorder un accès permanent aux clés de tout le royaume.