Approuvé par quelqu'un d'autre : identifier l'acteur derrière une revendication sub
Le défi
Un remboursement de 240 000 euros a été approuvé à 03h11 un dimanche. Le journal d'audit des paiements désigne Dele Okonkwo, directeur financier, qui dormait dans un autre fuseau horaire et dont l'ordinateur portable était dans le coffre d'un hôtel. Son compte n'a pas été compromis : aucune connexion à 03h11, aucun nouvel appareil, aucune demande d'authentification multifacteur échouée, rien. Le journal d'audit dit la vérité sur le jeton qu'on lui a donné. Voici ce jeton, exactement tel qu'il est arrivé à l'API de paiement. Quelqu'un d'autre s'y trouve. Nommez-le.
Ce que tu vas apprendre
- Lire chaque revendication d'une charge utile JWT, y compris les objets imbriqués
- Distinguer le sujet d'un jeton de l'acteur qui l'utilise
- Reconnaître les valeurs amr comme preuve de la façon dont une session a été créée
- Expliquer pourquoi un journal d'audit qui n'enregistre que sub attribue à tort les actions déléguées
- Décrire les contrôles qu'une identité mal attribuée contourne silencieusement
Compétences testées
Prérequis
- Ce qu'est un JWT et le fait que sa charge utile est encodée, et non chiffrée
Comment ça marche
Un jeton répond normalement à une seule question : qui est-ce. La délégation en ajoute une seconde, et les deux réponses ne sont pas les mêmes. sub est le sujet, l'identité dont les permissions seront utilisées pour la requête. act est l'acteur, l'identité qui la pilote réellement. Les consoles support, les outils break-glass d'astreinte et les agents automatisés produisent tous des jetons avec les deux, et le format est standardisé précisément pour cette raison.
Rien de tout cela n'est en soi une attaque. Le jeton est correctement signé, l'API de paiement le valide correctement, et le remboursement passe avec l'autorité du directeur parce que c'est exactement à cela que sert la délégation. La défaillance est en aval : un journal d'audit qui n'enregistre que sub transforme l'action d'un agent du support en action du directeur, de façon permanente et convaincante.
Ce que coûte cette mauvaise attribution, c'est chaque contrôle indexé sur l'identité. Les règles de double approbation, la revue hors horaires, la détection d'anomalies sur les comptes privilégiés et l'investigation elle-même se basent toutes sur un nom. Donnez-leur le mauvais nom et elles s'accordent toutes à dire que rien d'inhabituel ne s'est produit, ce qui est exactement ce que l'équipe Harbourline a constaté en cherchant.
Erreurs fréquentes
- Répondre d.okonkwo. C'est
sub, l'autorité empruntée. Le journal d'audit le disait déjà, et c'est ce qui a rendu l'incident déroutant. - Chercher une signature falsifiée. Le jeton est valide. Supposer que chaque énigme de jeton est une falsification est justement l'habitude que celle-ci est conçue pour briser.
- S'arrêter aux revendications que vous reconnaissez.
iss,aud,sub,expsont toutes ordinaires. La réponse se trouve dans la revendication qui est un objet. - Répondre console.harbourline.example. C'est l'origine de la délégation, pas celui qui l'a effectuée.
Comment s'en protéger
Enregistrez les deux identités, et traitez l'autorité déléguée comme son propre niveau de privilège.
- Enregistrez
act.subà côté desubdans chaque événement d'audit, et affichez-le dans l'interface que les gens lisent réellement. Si le champ est absent du schéma de journalisation, il sera absent de l'investigation. - Ne laissez pas la délégation hériter de l'ensemble complet des permissions. Un agent du support agissant en tant que directeur devrait pouvoir lire et reproduire, pas approuver un paiement.
- Plafonnez la valeur et la portée des sessions déléguées, exigez le consentement du sujet à chaque session, et faites-les expirer en quelques minutes.
- Alertez sur les sessions déléguées qui effectuent des actions privilégiées en dehors des horaires. Ce remboursement aurait déclenché les deux conditions.