Der Authentifizierungsdienst Kerberos ist ein komplexes Ungeheuer - was es besonders spannend macht mit ihm zu spielen. Ein Windows Active Directory bietet sich als Spielplatz besonders an, vor allem wenn alle Jubeljahre ein Goldstück wie MS14-068 gefunden wird. :) Besonders schön sind auch Angriffsvektoren wie AS-REP- und TGS-REP-Kerberoasting von User-Principals, weil sie zeigen, dass kleine Konfigurationsoptionen und -entscheidungen große Auswirkungen haben - der Grund dafür, dass Basteleien nie nachhaltig funktionieren werden.

Als ich mir vor einigen Tagen den sehenswerten Talk von gentilwiki auf der Bluehat Israel angeschaut habe ist mir zum ersten mal der Begriff kerbstorm aufgefallen:

kerbstorm im YouTube-Video

Dann hat gestern gentilwili getwittert und nach kerbstorm gefragt:

kerbstorm im YouTube-Video

... und es gab keine Antwort auf die Frage "WTF is kerbstorm". :( Zufällig hatte ich mich nach dem Talk genau das gefragt und schon eine Antwort, die für den geneigte Leserschaft ja vielleicht interessant sein könnte ( Auflösung in der letzten Zeile des Posts ;) )

Da kerbstorm im aktuellen build von kekeo noch nicht eingebaut wurde, ich absolut keine Lust darauf hatte das Tool selbst zu kompilieren, es überhaupt keine Doku gibt und der Quellcode nicht wirklich komplex ist, habe ich mich auf die Quellcodeanalyse beschränkt:

Zunächst holt sich kerbstorm alle Nutzer eine Domäne über eine RPC-Schnittstelle, von der ich bisher noch nichts gehört hatte: MS-SAMR:

numUserStatus = SamEnumerateUsersInDomain(hDomainHandle, &userEnumerationContext, USER_NORMAL_ACCOUNT, &pEnumUsersBuffer, 4*1024*1024, &userCountRetourned);

Anschließend wird für alle gefundenen Nutzer folgende AS-REQ 20 mal ($retry) an den DC geschickt:

KDC_REQ
      PVNO: 5
      MSG-TYPE: AS_REQ
              PA_DATA
                      PA-ENC-TIMESTAMP
                                      0x30, 0x36, 0xa0, 0x03, 0x02, 0x01,[...] *(statisch)*
                                      PAUSEC
              KDC_REQ_BODY
                      KDC-OPTIONS
                              reserved: false
                              forwarded:false
                              proxiable: false
                              proxy false     
                              allowed-postdate
                              postdated: false
                              unsued:false    
                              renewable: true
                              unused: false  
                              unused: false
                              opt-hardware-auth: false
                              request-anonymous: false
                              canonicalize: false     
                              constrained-delegation: false
                              disable-transisted-check: false
                              renewable-ok: true             
                              enc-tkt-in-skey:false
                              renew: false         
                              validate: false
                      CNAME                  
                              KRB_NT_PRINCIPAL
                              $username        
                              $domain  
                      SNAME         
                              PrincipalName 
                              krbtgt        
                              domain
                      TILL          
                              20370913024805Z
                      NONCE
                              1853451123
                      ETYPE
                              KERB_ETYPE_RC4_HMAC_NT

Ein wenig Hintergrund: Active Directory fordert in der Standardeinstellung beim Authentifizierungsvorgang eine so genannte Pre-Authentication: Damit ein Principal sich ein TGT vom KDC abholen kann, muss dieser zunächst beweisen, dass der Principcal das Passwort kennt. Dazu verschlüsselt der Principal den aktuellen Timestamp.

Deaktivert man diese Pre-Authentication kann ein Angreifer über eine Anfrage an den DC (AS-REQ) ein Stück Daten abfragen (den EncryptedPart der AS-REP) was mit dem Passwort des Benutzers verschlüsselt ist. Mittels dieser Daten kann ein Angreifer über BruteForce eventuell das Passwort des Nutzers zu erraten (john the ripper ist dein Freund).

In der obigen AS-REQ ist dieser verschlüsselte Timestamp statisch eingetragen. Ein AS-REQ mit falsch verschlüsseltem Timestamp zählt im AD als fehlgeschlagener Anmeldeversuch. Damit ist auch klar was kerbstorm macht: alle Nutzer im werden gesperrt indem die maximale Anzahl von fehlerhaften Passworteingaben erreicht wird.

So viele Worte für eine einfache Aussage: kerbstorm ist ein effizienter DoS-Angriff auf dein AD.