Czym jest kerberos?

Kerberos to protokół uwierzetelniania i autoryzacji stworzony na MIT. Używany jest w windowsie w AD. Kerberos jest używany kiedy użytkownik chce otrzymać dostęp do usługi (aplikacji) w sieci. Dzięki niemu użytkownik nie musi wpisywać cały czas swojgo hasła. Protokół ten był również projektowany z myślą o tym aby hasło klienta nie musiało być przesyłane przez sieć podczas prób autoryzacji i uwierzetelniania.

Działanie

Kerberos składa się z trzech komponentów – „głów” jak Cerber:

• Klienta.
• Usługi.
• Centrum Dystrubułowania Kluczy (KDC) – Key Distribution Center.

Warto zauważyć że KDC jest kontrolerem domeny (DC) w Active Directory (AD).

Proces

Proces składa się z trzech kroków:
– Usługi Autoryzacyjnej (AS) – Authentication Service:
– – Klient uwierzetelnia się do KDC.

– Bilet umorzliwiający korzystanie z biletu (TGT) – Ticket-Granting Ticket:
– – Klient prosi KDC o bilet do korzystania z usługi/aplikacji.

– Żądanie Aplikacji (AP) – Application Request:
– – Klient używa biletu aby móc skorzystać z usługi.

W praktyce KDC jest również kontrolerem domeny, a on zawiera wszystkie informacje domenowe, wliczając to hasła innych usług, maszyn i użytkowników. Poza kontrolerem domeny, każdy zna tylko swoje hasła.

Przykład

Authentication Service (AS)

KRB_AS_REQ: Kerberos Authentication Service Request

Mamy użytkownika Kowalskiego, najpierw wysyła prośbę o TGT do Kontrolera Domeny (DC). TGT, które żąda Kowalski jest zbiorem zaszyforwanych informacji zawierający:

• klucz sesji.
• informacje o użytkowniku.
  (grupy, id, nazwa)

Aby przeprowadzić bezpiecznie żądanie Kowalski prześle do KDC swoją nazwe oraz dokładny czas żądania zaszyfrowany zhaszowaną wersją swojego hasła. (hasła kowalskiego)

KDC sprawdzi nazwe kowalskiego i zidentyfikuje czy istnieje w bazie danych wewnątrz KDC. Baza danych zawiera nazwę oraz zhashowaną wersje hasła użytkownika.

Jeżeli znajdzie nazwę kowalskiego, spróbuje odszyfrować dokładny czas żadania, jeżeli mu się to nie uda to kowalski użył złego hasła i go nie uweirzetelni.

Jeżeli natomiast uda się KDC ma pewność że to rzeczywiście z Kowalski doszło do komunikacji. Wtedy wygeneruje unikalny klucz sesji, przypisze go do tego użytkownika i ustawi mu czas jak długo będzie mógł z niego korzystać.

KRB_AS_REP: Kerberos Authentication Service Response

KDC odeśle z powrotem do kowalskiego:

• klucz sesji: zaszyfrowany hasłem kowalskiego.
• TGT, zawierający informacje takie jak:
  • Nazwa użytkownika (kowalski).
  • Czas trwania klucza
  • Wygenerowany klucz sesji
  • Privilage Attribute Certificate (PAC), który zawiera dużo informacji o dostępach grupach itp.

TGT będzie zaszyfrowane kluczem (hasłem) KDC, przez to tylko i wyłącznie KDC będzie mogło odszyfrować i przeczytać zawartość tego biletu.

TGT uważany jest za publiczną informacje i równie dobrze może zostać przechywcoana podczas fazy uwierzetelniania. Nie ukrywamy faktu że się komunikujemy, ani nie ukrywamy wiadomości, natomiast samą zawartość tej wiadomości już ukrywamy.

Kowalski otrzymawszy klucz sesyjny zaszyfrowany swoim hasłem oraz TGT którego odszyforwać już nie może, odszyfrowywuje tylko klucz sesji.

Ticket-Granting Service (TGS)

Teraz gdy już użytkownik został uwierzetelniony, kowalski posiada własy klucz(hasło) oraz limitowany klucz sesji który tylko on zna, ale także posiada zaszyfrowane TGT przez KDC (które posiada również ten klucz sesyjny.

KRB_TGS_REQ: Kerberos Ticket-Granting Service Request

Gdy kowalski chce użyć usługi/aplikacji na serwerze, wyśle on najpierw kilka informacji do KDC żeby KDC mogło odesłać bilet do usługi.

A są to następujące informacje:

• TGT.
• Usługe wraz z hostem na której się znajduje (cifs/SERV01).
• Uwierzytelniacz, który zawiera:
  • jego nazwę.
  • aktualny czas żadania.

Uwierzytelniacz zaszyfrowany jest kluczem sesji.

Uwierzytelniacz jest wysyłany aby upewnić się że kowalski wysyła żądanie a nie kto inny. Aby to sprawdzić KDC porówna zawartość TGT i uwierzytelniacza. Przez to że KDC mogło jedynie odczytać zawartość TGT mamy pewność że nie było one zmieniane. KDC odczyta zawartość TGT wraz z nazwą użytkownika i powiązanym kluczem sesji.

Wtedy odszyfruje on zawartość uwierzytelniacza która była zaszyfrowana kluczem sesji. Jeżeli odszyfrowanie się uda to dane w uwierzetelniaczu zgadzają się z danymi w TGT, wtedy wiemy że kowalski jest tym za kogo się podaje. KDC dzięki temu procesowi wie że ten kto wykonał to zapytanie posiada TGT oraz wiedzę o kluczu sesji.

KRB_TGS_REP: Kerberos Ticket-Granting Service Response

Teraz kiedy KDC było wstanie potwierdzić że użytkownik to rzeczywiście kowalski, odeśle mu informacje potrzebne do żadania aplikacji/usługi, a są to:

• Bilet, zawierający:
  • nazwe usługi i hosta (cifs/SERV01)
  • nazwę użytkownika (kowaslki)
  • PAC
  • nowe klucze sesyjne (które są ważne przez ograniczony czas oraz umożliwiają tylko na komunikacje pomiędzy kowalskim a aplikacją/usługą)
    
    Bilet ten jest zaszyfrowany kluczem (hasłem) usługi/aplikacji.
• Nowe klucze sesyjne.

A natomiast i bilet i nowe klucze sesyjne są zaszyfrowane pierwszym kluczem sesji, który był wymieniony pomiędzy klientem a KDC.

Kowalski po otrzymaniu tej wiadomości będzie w stanie odszyfrować pierwszą warstwę (jak cebule) aby dostać się do kluczy sesyjnych stworzonych w celach komunikacji z aplikacją/usługą oraz do biletu zaszyfrowaengo przez klucz (hasło) aplikacji/usługi. Bilet ten nazywa się TGS.

Application Request (AP)

Teraz sytuacja wygląda tak:

KRB_AP_REQ: Kerberos Application Request

Kowalski wygeneruje teraz nowy uwierzytelniacz ale zaszyfruje go nowym kluczem sesji, wraz z biletem TGS z poprzedniego etapu. Jest to ten sam proces co z KDC.

KRB_AP_REP

Aplikacja/usługa otrzymuje bilet TGS i go deszyfruje włanym sekretem(kluczem/hasłem). Wtedy tylko usługa zna swój sekret i może spać spokojnie że TGS jest autentyczne. TGS posiada klucz sesji, który użyje do deszyfrowania uwierzetelniacza. Po przez porównanie TGS’a i zawartości uwierzetelniacza usługa może być pewna wiarygodności użytkownika.

Podsumowując cały proces wygląda tak:

Teraz skoro już wiemy jak działa Protokół Kerberosa to przejdźmy do najciekawszej części.

Hacking Kerberosa

Tu na starcie wspomnę że łamanie zabezpieczeń informatycznych, włamywanie się do infrastruktury sieci, bez zgody administratora może skończyć się odpowiedzialnością karną, zakłócanie działania sieci również. Dzielę się wiedzą w celach edukacyjnych i hobbistycznych, ponieważ gdy znamy techniki atakujących jesteśmy lepiej się przed nimi ochronić. Nie odpowiadam za konsekwencje czynów czytelnika, wykorzystania tej wiedzy tutaj przedtawionej w złych celach.

Dodam, że działania tutaj przedstawione były zadaniem CTF – Capture The Flag na stronie root-me.org. Wszytko odbywało się w środowisku testowym i żadne zabezpieczenia realnych systemów nie zostały złamane.

O to treść zadania:

Musimy odzyskać hasło podejrzanego użytkownika który połączył się usługą przy pomocy Kerberosa. Na start otrzymujemy plik pcapng – zrzut pakietów z wiresharka.

A zatem jak się za to zabrać?

Powtórzmy zatem szybko etapy kerberosa:
– KER_AS_REQ: Klient wysyła nazwę i timestamp zaszyfrowane swoim hasłem.
– KER_AS_REP: KDC wysyła klucz sesji (szyfr hasłem Klienta) oraz TGT (szyfr KDC).
– KER_TGS_REQ: TGT, usługa, uwierzytelniacz (szyfrowany kluczem sesji)
– KER_TGS_REP: (nazwa klienta, pac, nazwa usługi, klucze sesyjne do usługi: szyfrowane kluczem usługi), klucze sesyjne do usługi (szyfrowane kluczem sesji).
– KER_AP_REQ: jak TGS REQ ale z aplikacją.

A zatem z wszystkich etapów iteresuje nas ten pierwszy gdzie przesyłane są informacje szyfrowane hasłem klienta, bo to właśnie jego hasło musimy odzyskać.

Wireshark

Odpalamy plik .pcapng w wiresharku aby zrobić rekonesans.

Jak widzimy mamy pięknie przedstawiony każdy etap komunikacji protokołem kerberosa pomiędzy Klientem a KDC.

Interesuje nas w szczególności AS-REQ.

I pięknie teoria pokrywa nam się z praktyką! Jak widać na zdjęciu w pakiecie posiadamy zaszyfrowany timestamp z jego nazwą. Teraz posiadając hash, który został zaszyfrowany hasłem klienta jesteśmy wstanie za pomocą hashcata i wordlisty odzyskać jego hasło! (w dużym uproszczeniu hashcat będzie sprawdzał po kolejno każde hasło w wersji zhashowanej i porównywał go z hashem kerberosa.

Hashcat

Hashcat to bardzo fajne, przydatne i rozbudowane narzędzie do „odzyskiwania haseł” do jego użycia będziemy potrzebować wybrać odpowiednie argumenty, tak jak z całej skrzynki z narzędziami wybieramy np. młotek czy śrubokrent, a nie całą skrzynkę do wbicia jednego gwoździa.

Kluczowe w hashcat’cie jest wybranie odpowiedniego rodzaju hashu (opcja -m). W przypadku odzyskiwania hasła z hashu kerberosa 5, Pre-Auth, musimy użyć -m 19900. Przypominam że odzyskujemy hasło z zadania w środowisku testowym!

Polecam zapoznać się z stroną hashcata: https://hashcat.net/wiki/doku.php?id=example_hashes

Jak można zauważyć hashcat wymaga hashu w określonej formie: $krb5pa$18$user$domain$hash. Jeżeli chcemy od biedy możemy wszystkie te dane wypisać samemu z pakietu, wystarczy je poszukać. Na szczęście nie ma co sobie utrudniać roboty i skorzystamy z skryptu do odzyskania hasha z środowiska testowego z zadania.

Jak widać program zrobił to za nas a obsługa była bardzo prosta, wystarczyło podać plik z pcap’em oraz który pakiet chcemy sparsować {as_req, as_rep, tgs_rep}.

Teraz pozostaje napisać polecenie hashcata wraz z wordlistą oraz hashem w odpowiedniej formie. Warto również posiadać komputer wyposażony w kartę graficzną lub generalnie w dużą moc obliczeniową ponieważ odzyskiwanie haseł jest bardzo zasobożerny. Im mocniejszy sprzęt posiadamy tym szybciej odzyskamy hasło. (dlatego kiedy powstanie komputer kwantowy będzie wielki problem)

Teraz warto pójść na kawę albo posiedzieć z rodziną ; ).
I po długim czasie mamy nasz efekt:

Jakże ambitne hasło: kittycat12 (na samej górze)

UPN?

W teori to koniec, mamy hasło użytkownika ale wiedza dla wiedzy, nigdy nie szkodzi. Format flagi to: RM{userPrincipalName:password}. Czym jest to UPN? UPN to nic innego jak User Principal Name – i jest to nazwa logowania dla użytkownika w standardzie RFC 822. Po prostu nazwa użytkownika z domeną ubrana ładnie w słowa: użytkownik@domena.pl. Możemy to kojarzyć z maili lub z Active Directory.

A więc finalnie nasza flaga to: RM{william.dupon@catcorp.local:kittycat12}

Przemyślenia

Kerberos sam w sobie jest bardzo dobrze skonstruowanym protokołem i ciężko jest odzyskać z niego hasło. Jednak jest takie przysłowie że: „każdy system jest podatny, po prostu jeszcze nie znaleziono sposobu na niego”.

Tak naprawdę to czy uda nam się złamać hash użytkownika zależy tylko i wyłącznie od jego hasła. Jeżeli hasło to było by czymś prostym lub znajdywało by się w jakiejś wordliście i ewentualne zasady (tak zwane rule) trafiały by na to hasło. To stosunkowo łatwo jest odzyskać z niego hasło. Jednakże tylko odzyskaliśmy jego hasło i nazwę użytkownika a samej zawartości pakietów nie udało mi się jeszcze odszyfrować. Jeszcze ;).

Myślę cały proces skłonił do przemyśleń i ustawienia w końcu silniejszego hasła do serwisów z których korzystamy. Bo jak widać odzyskanie hasła nie jest takie ciężkie w przypadku łatwych haseł.

Kerberos ma też pewne mankamenty takie jak golden ticket, silver ticket, kerberoasting. Ale spokojnie je też zbadam ale w kolejnym artykule ;). Na dziś to tyle.

Jak zwykle, dla zainteresowanych dodatkowa lektura:

• https://en.hackndo.com/kerberos/
• https://ericesquivel.github.io/posts/kerberos
• https://www.rfc-editor.org/rfc/rfc4120.html