Laravel timing attack-sårbarhed
Timing attacks kan bruges til at få adgang til følsomme oplysninger om brugere i en Laravel-applikation. I denne artikel vil vi forklare hvordan. (CVE-2022-40482)
Af Jens Just Iversen
Hvad er timing attacks?
Timing attacks er et side-channel-angreb, hvor angriberen forsøger at udlede følsomme oplysninger ved at analysere, hvor lang tid forespørgsler tager:
- Hvis en forespørgsel er langsom, betyder det, at scriptet havde mere at behandle.
- Hvis en forespørgsel er hurtig, betyder det, at der var mindre at behandle.
Ud fra disse tidsforskelle kan en angriber gætte, hvad der sker bag kulisserne – for eksempel om en bruger er registreret på siden eller ej. Dette kaldes en user enumeration-sårbarhed, og den var til stede i Laravel frem til september 2022.
CVE-nummer: CVE-2022-40482
Problemet med user enumeration
Laravel tager allerede user enumeration alvorligt i autentificering. Derfor vises kun den generiske fejlmeddelelse: "These credentials do not match our records.", når der indtastes forkerte oplysninger i en Laravel login formular.
Hvis meddelelsen i stedet havde været: "E-mailen findes ikke" eller: "Adgangskoden er forkert", ville det være hjælpsomt for brugerne – men også en kæmpe gave for angribere, der forsøger at indsamle e-mails og brugernavne.
Når en angriber har en liste over eksisterende e-mails, skal de kun gætte adgangskoder til de specifikke konti – ikke alle mulige. Det gør angrebet meget mere effektivt. Måske er angriberen endda heldig og finder lækkede adgangskoder fra databasen: haveibeenpwned, som matcher de indsamlede e-mails?
Selvom user enumeration er særligt følsomt på visse typer sider (som login til e-mail, bank mv.), er de fleste ikke direkte sårbare alene af den grund. Det bliver først problematisk, når det kombineres med andre typer angreb.
Er det så et problem?
– Ja, for de fleste effektive angreb kombinerer flere sårbarheder.
Timeless timing attacks
Da vi hos Ephort begyndte at undersøge timing attacks, fandt vi hurtigt ud af, at traditionelle timing attacks ofte er upraktiske.
White papers, konferencer og blogindlæg viste, at man har brug for meget store datasæt og avanceret statistisk analyse for at få meningsfulde resultater. Det betyder, at traditionelle timing attacks ofte ses mod hardware eller systemer, hvor mange gentagelser er muligt.
Men webapplikationer har ofte begrænsninger som throttling, max forsøg og DDoS-beskyttelse – hvilket gør traditionelle angreb svære.
Timeless timing attacks er noget andet. I stedet for at måle "wall clock"-tid udnytter de HTTP/2 multiplexing til at sende par af forespørgsler og ser udelukkende på rækkefølgen, hvori svarene kommer retur.
Multiplexing gør det muligt at sende flere forespørgsler i én netværkspakke. Serveren behandler dem hurtigt og returnerer svarene i den rækkefølge, de er færdige.
Derved elimineres netværksstøj ("jitter"), som normalt ødelægger traditionelle målinger. Resultatet: timeless timing attacks kan pålideligt måle forskelle ned til 20 mikrosekunder med kun 6 forespørgsler.
Throttling og DDoS-beskyttelse er derfor langt mindre problematiske.
Laravel og timing attacks
Da vi primært arbejder med Laravel, besluttede vi os for at undersøge, om frameworket var sårbart over for timeless timing attacks:
Login og "glemt adgangskode"-funktioner er typisk steder, hvor user enumeration via timing er muligt. Det viste sig også at være tilfældet her. Ved at gennemgå kildekoden og kigge efter "early returns" fandt vi denne metode i Illuminate\Auth\SessionGuard.php:
protected function hasValidCredentials($user, $credentials)
{
$validated = ! is_null($user) && $this->provider->validateCredentials($user, $credentials);
if ($validated) {
$this->fireValidatedEvent($user);
}
return $validated;
}
Den første linje tjekker, om brugeren findes. Hvis ikke, springes kodevalidering og event-triggering helt over.
Det betyder, at hvis brugeren ikke findes, eksekveres mindre kode, og det går lidt hurtigere. Tom Goethem og andre forskere bag timeless timing attacks har offentliggjort et værktøj, som tester, om et site er sårbart.
Ved at bruge dette værktøj mod en ny Laravel-installation kunne vi bekræfte sårbarheden. Vi gjorde følgende:
- Oprettede mange brugere i databasen.
- Én af dem var kendt af "hackeren" (oprettet som testbruger til sammenligning).
- For hver 4 logins fra scriptet lavede vi et rigtigt login for at nulstille ratelimiting.
- CSRF-beskyttelse blev deaktiveret (nødvendigt hvis sitet bruger det – ellers skal scriptet hente token).
- Scriptet sendte 5 sæt login-forespørgsler.
Hvert sæt bestod af:
- Én forespørgsel med kendt e-mail og forkert adgangskode
- Én forespørgsel med tilfældig e-mail og forkert adgangskode
Scriptet kunne meget pålideligt afgøre, at den forespørgsel med kendt e-mail tog længere tid, hvilket betød, at brugeren eksisterede. Hvis begge e-mails i et sæt var registrerede, kunne scriptet ikke skelne mellem dem → de eksisterer begge. Dermed kan hackere udtrække gyldige e-mails fra login-endpointet ved at sende request-par med én kendt og én testet e-mail.
Vi har lagt vores testscript ud på GitHub.
Løsningen
For at forhindre timing attacks bør eksekveringstiden ikke afhænge af input.
Dermed kan angriberen ikke forbinde inputdata med, hvad der faktisk sker bagved.
Vi løste problemet ved at omslutte hasValidCredentials
-koden i en såkaldt timebox – en funktion, som:
- tager et callback og en tidsgrænse
- udfører koden
- venter resten af tiden, hvis callback’et er færdigt før tid
Timebox sikrer dermed, at metoden altid tager samme tid – uanset om brugeren findes eller ej. Pull request til Laravel-repo kan ses her:
https://github.com/laravel/framework/pull/44069
Denne løsning påvirker ikke brugere med korrekt login.
Den gælder kun for fejlede logins (forkert adgangskode/e-mail).
CVE-oplysninger
Felt | Indhold |
---|---|
CVE ID | CVE-2022-40482 |
Beskrivelse | Laravel v8.x til v9.x er sårbar over for user enumeration via timeless timing attacks. Årsagen er en early return i `hasValidCredentials`-metoden i `Illuminate\Auth\SessionGuard`. |
Sårbarhedstype | Timeless Timing Attack |
Udvikler/Vendor | Laravel |
Berørte versioner | Laravel 8.x – 9.x |
Berørt komponent | `hasValidCredentials` i `Illuminate\Auth\SessionGuard.php` |
Angrebstype | Remote |
Informationslækage | Ja |
Angrebsvektor | Forespørgsler mod login-endpointet via timing |
Referencer | ephort.dk blogpost · GitHub PoC |
Er sårbarheden anerkendt? | Ja |
Opdager | ephort ApS, Jens Just Iversen |
Sig til, hvis du vil have hjælp til at beskytte din Laravel-app mod dette problem.
16. JUL 2025