Keycloak: oczekiwania vs. rzeczywistość w autentykacji x509
Krzysztof Wasilewicz - 26 czerwca 2024
Czy powinniśmy zawsze polegać na rzeczach oczywistych?
Chcielibyśmy podzielić się zaskakującym doświadczeniem w pracy z serwerem autoryzacyjnym Keycloak. Dla jednego z klientów skonfigurowaliśmy w Keycloak metodę autentykacji x509, czyli autentykację za pomocą certyfikatu. Spodziewaliśmy się, że Keycloak sprawdzi certyfikat w sposób kompleksowy. Niestety, jak wykazali nasi pentesterzy, rzeczywistość okazała się inna.
Przypadkowe odkrycie: Słabości w autentykacji x509 Keycloak
W metodzie autentykacji klientów x509 Keycloak nie przeprowadza kryptograficznej weryfikacji certyfikatu, lecz ogranicza się do sprawdzenia pola „Subject DN”. Co więcej, system nie kontroluje, czy certyfikat nie wygasł lub nie został unieważniony. Oznacza to, że możliwe było uzyskanie tokena dostępu przy użyciu dowolnego certyfikatu z odpowiednim „Subject DN”, niezależnie od jego autentyczności.
To odkrycie było dla nas dużym zaskoczeniem, ponieważ zakładaliśmy, że serwer autoryzacyjny sprawdza zarówno ważność certyfikatu, jak i jego zgodność z kluczem publicznym. Oczywiście, taka sytuacja stworzyła poważne zagrożenie bezpieczeństwa, umożliwiając potencjalnym intruzom uzyskanie nieautoryzowanego dostępu.
Implementacja pluginu dla zwiększenia bezpieczeństwa
Aby zaradzić temu problemowi, zaimplementowaliśmy dodatkowy plugin, który gwarantuje pełną weryfikację certyfikatu kryptograficznie. Plugin ten kontroluje nie tylko „Subject DN”, ale także integralność certyfikatu, jego podpis cyfrowy oraz ważność, zapewniając, że tylko prawdziwe, autoryzowane certyfikaty mogą być używane do autentykacji klienta.
Dzięki temu rozwiązaniu przywróciliśmy pełne bezpieczeństwo naszego systemu autoryzacji i zapewniliśmy, że metoda autentykacji x509 działa zgodnie z naszymi oczekiwaniami.
Przegląd wersji i dokumentacji Keycloak
W celu zgłębienia problemu przeprowadziliśmy analizę. Przejrzeliśmy Keycloak Release Notes’y i zrobiliśmy testy innych wersji Keycloak. Gdy rozpoczynaliśmy projekt, używaliśmy Keycloak w wersji 22. Obecnie jest dostępna wersja 25, ale metoda autentykacji x509 nadal nie zapewnia 100% bezpieczeństwa.
Komunikacja z twórcami: Wyzwania i odpowiedzi
Skontaktowaliśmy się z twórcami Keycloak, przekazując im te cenne informacje i zwracając uwagę na istotną podatność. Ku naszemu zdumieniu, otrzymaliśmy odpowiedź jeszcze tego samego dnia. Autorzy stwierdzili, że według nich to nie jest podatność, gdyż w dokumentacji Keycloak opisano, że odpowiedzialność za weryfikację PKIX path leży po stronie warstwy przed Keycloackiem. Poinformowali nas również, że weryfikują dodatkowe rzeczy takie jak wygaśnięcie certyfikatu, unieważnienie, czy też jego użycie. Natomiast ważny w tym miejscu jest kontekst, gdyż te rzeczy istotnie są robione, ale w innym flow, tzw. Browser flow, w którym mamy do czynienia z użytkownikiem. Natomiast we flow klienta autentykator x509 sprawdza wyłącznie wartość “Subject DN”.
Odnosząc się do dokumentacji Keycloak, należy zaznaczyć, że jest ona dość przestarzała. Twórcy systemu zdają sobie sprawę z tych niedoskonałości i planują aktualizację dokumentacji, na co wskazuje otwarty ticket na Githubie:
https://github.com/keycloak/keycloak/issues/27699
Dlaczego warto sprawdzać nawet oczywiste elementy systemu
Mam nadzieję, że nasze doświadczenie pomoże innym, którzy mogą napotkać podobny problem. Ten przypadek nauczył nas, że warto zawsze sprawdzać nawet takie elementy systemu, które wydają się oczywiste i bezproblemowe.
Autor:
Krzysztof Wasilewicz
Senior Backend Developer/Project Leader.
Krzysztof to znakomity programista backendowy oraz project leader w stadzie Lwów.
Specjalizuje się w tworzeniu oprogramowania dla sektora finansowego,
skupiając się na nowoczesnych technologiach płatniczych.
Comments