1. Een ontwerpfout in een aangepast sessie-cookie systeem van een platform voor magazijnbeheer maakte het mogelijk voor een niet-geauthenticeerde aanvaller om zich voor te doen als werknemers en beheerders. Dit gebeurde door het omzeilen van normale inlogcontroles en het accepteren van een vervalst identiteitsteken in een applicatie-specifieke sessielaag.
2. De kwetsbaarheid zat niet in Microsoft Entra ID zelf, maar in de specifieke sessielaag van de applicatie. Het getroffen platform maakte wel gebruik van Entra ID single sign-on en multi-factor authenticatie (MFA), maar vertrouwde daarnaast op een ondertekend cookie om applicatiesessies te behouden. MFA verifieert een login-gebeurtenis, terwijl sessiebeheer bepaalt wat er daarna gebeurt.
3. Dit ontwerp introduceerde een risico dat vergelijkbaar is met cookie-gebaseerde account overname aanvallen, waarbij controle over een vertrouwd sessietoken belangrijker kan zijn dan een wachtwoord. Het aparte sessiecookie diende als een alternatieve route naar de applicatie.
4. De bypass werd veroorzaakt door twee gekoppelde ontwerpfouten. De applicatie ondertekende een cookie met een hardgecodeerd geheim dat overeenkwam met de codenaam, terwijl de ondertekende waarde een publiekelijk zichtbare database-identifier van de gebruiker was. Een normaal ondertekend cookie controleert op wijzigingen door een cryptografisch geheim toe te passen dat door de server wordt bewaard op een willekeurig sessiereferentie.
5. Met een voorspelbaar geheim kon een aanvaller een cookie creëren dat de server behandelde als behorend tot een andere gebruiker. Dit maakte het mogelijk om een verzoek te doen zonder het wachtwoord van het slachtoffer, een nieuwe MFA-goedkeuring of een Entra ID-toegangstoken nodig te hebben.
6. De kwetsbaarheid werd ontdekt tijdens een beoordeling van een supply-chain magazijnbeheersysteem. Onderzoekers slaagden erin om 95 werknemersaccounts van de 241 geteste gebruikers-ID's te imiteren, inclusief accounts met verhoogde rechten.
7. Een vervalste beheerderssessie kon een API-verzoek uitvoeren dat de status van gegevens veranderde. Dit kon leiden tot blootstelling van operationele data en het optreden onder de identiteit van een legitieme werknemer. Hetzelfde vervalste cookie werkte in dit geval op zowel de API- als de administratieve applicatiehosts.
8. Onderzoekers ontdekten ook een niet-geauthenticeerde Swagger-interface die de volledige API-oppervlakte blootlegde.
9. Het betrof een falen in het vertrouwensmodel van de applicatie, niet een compromittering van de cryptografie van Entra ID. Het aangetroffen platform gebruikte RS256-ondertekende toegangstokens, schema validatie en geparametriseerde database toegang.
10. Er werden geen productiesystemen getest en de identiteiten die in het proof-of-concept werden gebruikt, waren geanonimiseerd.
11. Een prioriteit is het roteren van het gecompromitteerde sessie-ondertekende geheim en het ongeldig maken van bestaande sessies. De sessie-intrekking moet alle hosts omvatten die het cookie accepteren.
12. Teams wordt aangeraden om authenticatie- en applicatielogs te controleren op ongebruikelijke sessiecreatie, accountwijzigingen, administratieve acties of activiteiten die niet overeenkomen met de verwachte gebruiker of apparaat. Een willekeurige server-side sessiereferentie, geroteerde geheimen en zinvolle monitoring verminderen de kans dat een aanvaller een blootgestelde identifier kan omzetten in accountimitatie.
13. Ontwikkelaars wordt geadviseerd om identiteit-dragende, door de client gecontroleerde sessiewaarden te vervangen door willekeurig gegenereerde sessie-identifiers die op de server worden opgeslagen en geverifieerd.
14. Veilige, hoog-entropische geheimen moeten gescheiden en beveiligd worden bewaard voor ontwikkeling, staging en productie, en mogen nooit worden hergebruikt tussen omgevingen.
15. Organisaties wordt aangeraden om elke aangepaste laag die rond een cloud-identiteitsprovider is toegevoegd, te beoordelen.
16. Verdedigers kunnen lessen toepassen uit de "Cookie-Bite" sessiekaping techniek, inclusief het monitoren van verdachte logins, het beperken van niet-goedgekeurde browser-extensies, het afdwingen van toegang van compatibele apparaten en het toepassen van tokenbeveiliging.
17. Indien stateless tokens noodzakelijk blijven, wordt het gebruik van sterke cryptografische sleutels, vervaltermijnen en replay-beveiliging aanbevolen.