Vorige maand kwam Okta in het nieuws omdat een hacker gebruik kon maken van een gesloten sessie. Stelen van sessies is een algemeen probleem dat niet alleen speelt binnen Okta. Okta neemt voor haar klanten nu wel maatregelen die vanaf nu ingeschakeld kunnen worden in Okta’s admin panel.

Diefstal van sessies

In veel systemen log je in en krijg je een sessie. Concreet betekent dat dat je verdere pagina’s en schermen van de applicatie kun gebruiken zonder verder in te loggen. De sessie heeft een identificatie en die wordt soms opgeslagen in een cookie. De applicatie controleert of de cookie er is en of de sessie waarnaar door de cookie gerefereerd wordt nog geldig is.

Okta kwam in het nieuws omdat het klantondersteuningssysteem van een van haar onderaannemers (Okta besteedt klantondersteuning uit aan diverse onderaannemers) een technische vastlegging bevatte van een aangemeld probleem. In zo’n vastlegging (in een HTTP Archive/HAR), worden alle HTTP requests en alle antwoorden, inclusief cookies, bewaard. Het bevatte ook de sessiecookie. Door een hack van het klantondersteuningssysteem kon de hacker het HAR-bestand stelen en dus ook de sessiecookie.

Van enkele klanten die zo’n HTTP vastlegging uploadden naar Okta zoals hierboven beschreven, is de sessie gebruikt om de Okta admin functies te gebruiken om zo verdere toegang tot achterliggende systemen te verkrijgen.

Maatregelen

Een belangrijke maatregel is kennis van het HTTP protocol en het bewustzijn dat HTTP verkeer alles bevat, inclusief authenticatie-informatie zoals gebruikersnaam en wachtwoord, maar ook uitgegeven sessietokens. Een sessietoken zat in dit geval in een cookie, maar het had ook in een HTTP body of een header kunnen zitten. Een vastlegging van alle HTTP verkeer dus dus heel vaak hooggevoelig en moet alleen met de grootste zorgvuldigheid met derden gedeeld worden. Nou zou Okta Support toch wel als een vertrouwde derde beschouwd moeten kunnen worden, maar toch.

Daarnaast geeft deze hack weer hoe belangrijk het is om goed na te denken over de maximale duur van een sessie en of gebruik van refresh tokens wel altijd ondersteund zou moeten worden. Een refresh token wordt gebruikt om - binnen de duur van de overkoepelende sessie - die overkoepelende sessie mee te kunnen verlengen. Als een hacker beschikking heeft over de (overkoepelende) access token en de refresh token, dan heeft hij theoretisch een oneindig durende sessie. Korter durende sessies waarna een gebruiker opnieuw moet authenticeren verkleinen de impact van een gestolen sessie. Het is wel een concessie in gebruiksgemak, en het nadenken hierover is dan ook een mooi voorbeeld van het gemak/veiligheids-dilemma.

Okta introduceert ‘session binding’

Okta heeft een ‘Early Access’ feature beschikbaar gemaakt in alle Okta tenants om een sessie te verbinden aan een netwerk. Als de sessie gebruikt wordt op een ander netwerk dan waar hij werd gestart, dan geldt de sessie niet meer en moet de gebruiker opnieuw aanmelden. Okta is een van de eersten die session binding introduceert in haar product.

De nieuwe optie heet “Bind Admin sessions to ASN” en vind je onder achtereenvolgens Settings en Features in het admin panel. CloudGuide initieert de komende week change requests bij haar beheerklanten om deze instelling in te schakelen.

Heb je vragen over de kwetsbaarheid van sessie(cookie)s of over de nieuwe instelling binnen Okta, neem dan contact met ons op.

Bronnen:

https://sec.okta.com/harfiles

https://www.itbrew.com/stories/2023/11/09/post-breach-okta-binds-session-tokens-to-network-location

https://www.beyondtrust.com/blog/entry/okta-support-unit-breach