Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Gruba podatność w implementacji DP3T – jednego z systemów do contact tracingu COVID
DP-3T (pisaliśmy m.in. o nim jakiś czas temu) to jedno z bardziej dojrzałych rozwiązań do tzw. contact tracingu. Tymczasem niedawno załatano taką podatność:
Missing signature validation of JWT when alg=none
Podatność występowała w jednym z komponentów backendowych całości:
When dp3t-sdk-backend is configured to check a JWT before uploading/publishing keys, it was possible to skip the signature check by providing a JWT token with
"alg":"none"
.
O co tutaj chodzi? Jeśli uploadujemy klucze [wskazujące na ew. kontakt z wirusem] to fakt ten powinien być uwierzytelniony. W tym celu można właśnie użyć JWT z odpowiednim podpisem. Jak można było ominąć podpis? W bardzo „klasyczny” sposób :-) Jak możecie zobaczyć np. tutaj:
W nagłówku widnieje algorytm podpisu – w tym przypadku jest to HS256. Jeśli teraz serwer nie jest zbyt mądry i zaakceptuje algorytm „none” (podany przez atakującego), to w ogóle nie sprawdzi podpisu tego tokenu i zaakceptuje całe żądanie HTTP (z informacjami wskazanymi przez atakującego).
Dla pewności – polskie rozwiązanie korzysta z innego systemu (tj. z API Google/Apple), a od strony stricte bezpieczeństwa wygląda naprawdę solidnie (zobacz nasz ~100 stronicowy raport z audytu bezpieczeństwa tego rozwiązania).
–Michał Sajdak
No nie wierzę, myślałem, że ta podatność umarła 10 lat temu. Dobrze widzę, że oni używają parsera JWT, w którym wystarczy użyć metody „parse” zamiast „parseClaimsJws” żeby strzelić sobie w stopę?! To by chyba warto zgłosić do samego parsera?
Można by też chyba przeszukać githuba kto wykorzystuje tą bibliotekę i kto używa tej samej metody, a potem tylko nabijać sobie CVE ;)
No w trakcie pentestów też widać ten problem czasem :]