Vraag & antwoord
Beschrijving beveiligingsincident Entree Federatie
Geplaatst door Kennisnet op 15 november 2019 14:53:51

Beschrijving incident

Uit analyse van incidentmeldingen van 28 en 29 oktober is ons gebleken dat er in uitzonderlijke gevallen iets mis kon gaan met de authenticatieflow van de Entree Federatie. De verstoring in de authenticatieflow zorgde ervoor dat een eindgebruiker (een leerling, student, docent of medewerker) bij een dienstaanbieder (bijv. een uitgever) als een andere eindgebruiker terecht kwam dan zichzelf.

 

Hoe kon dit gebeuren?

Hypothetisch voorbeeld

Dag 1: Gebruiker A logt succesvol in en krijgt een sessie ID 12345 waarin zijn gegevens bewaard worden. Gebruiker A is klaar met het gebruik van zijn lesmateriaal, maar sluit niet zijn internetbrowser (bijvoorbeeld, klapt laptop dicht / zet op standby). Bij de Entree Federatie verloopt de sessie met sessie ID 12345 en worden de gegevens van Gebruiker A verwijderd.

Dag 2: Gebruiker B logt in en krijgt toevallig hetzelfde willekeurig gegenereerde sessie ID 12345. Het sessie ID is hetzelfde, maar bij Entree Federatie bestaat de sessie niet meer en wordt er dus een nieuwe sessie aangemaakt met sessie ID 12345 en de gegevens van Gebruiker B. Gebruiker B kan dan gewoon normaal aan de slag bij de verschillende diensten achter Entree Federatie.

Gedurende dag 2 besluit Gebruiker A weer een dienst te bezoeken die is aangesloten bij Entree Federatie. De internetbrowser van Gebruiker A ziet dan in zijn eigen geheugen nog een sessie staan met sessie ID 12345. De internetbrowser van Gebruiker A verifieert bij Entree Federatie of sessie ID 12345 nog bestaat. Binnen Entree Federatie is er een sessie met sessie ID 12345 actief. Deze is echter van Gebruiker B, maar Entree Federatie kijkt nooit naar de identiteit van een gebruiker uit privacyoverwegingen. De identiteit wordt namelijk vastgesteld binnen het systeem van de school. Omdat er echter een sessie actief is met sessie ID 12345 koppelt Entree Federatie aan de internetbrowser van Gebruiker A terug dat de sessie met sessie ID 12345 inderdaad bestaat en wordt Gebruiker A “her-authenticeert”. Gebruiker A is immers eerder al geauthenticeerd met sessie ID 12345. Echter, de sessie met sessie ID 12345 bevat nu de gegevens van Gebruiker B en op dat moment stuurt Entree Federatie Gebruiker A door naar de dienst met de gegevens van Gebruiker B. Hierdoor komt Gebruiker A bij de dienst terecht als Gebruiker B en verleent de dienst toegang tot de gegevens van Gebruiker B aan Gebruiker A.

Een belangrijke voorwaarden voor bovenstaande situatie zijn:

  1. Gebruiker A is langer dan 10 uur niet actief geweest.
  2. Gebruiker A heeft in die tijd de cookies in zijn browser niet verwijderd, door bijvoorbeeld zijn browser niet te sluiten en zijn laptop op standby te zetten.
  3. Gebruiker B heeft toevallig dezelfde sessie ID gekregen als Gebruiker A.

 

De fout zit hier in het genereren van een sessie ID. In werkelijkheid is het sessie ID een hele lange reeks van willekeurige karakters, wat het mathematisch onmogelijk maakt dat 2x dezelfde sessie ID wordt gegenereerd. Echter, door een fout in het systeem werd die kans zoveel malen groter dat het met het groeiende aantal authenticaties binnen Entree Federatie niet meer geheel onmogelijk was dat 2x hetzelfde sessie ID werd gegenereerd. De kans was nog steeds heel klein, maar met meer dan 15 miljoen authenticaties per maand was de kans dat het voor zou komen toch significant. 

 

De oorzaak van het beveiligingsincident

Het is nog onduidelijk hoe het beveiligingsincident heeft kunnen ontstaan. Het beveiligingsincident is wel opgespoord en we hebben de uitgifte van inlog sessie ID’s robuuster gemaakt, waardoor dit beveiligingsincident niet langer kan voordoen. Het nader onderzoek naar de oorzaak loopt nog.