Sicherheitsprobleme von Kerberos
Alle aktuellen Windowsversionen sind betroffen, die derzeit neuesten (8.1 bzw. 2012 R2) jedoch (derzeit noch) nicht
*Update*Es gibt Neuigketen: Microsoft hat versucht, auf win7 und 2008 R2/2012 nachzubessern - man darf hoffen. http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871 ...
Ebenso passend zum Thema ist folgender Link: Dauerkarte für Windows-Domänen: das "golden ticket"
Vorwort: ich habe mit Frank abgeklärt, dass ich dieses Thema ansprechen darf, wenn ich diverse Dinge beachte, zum Beispiel, keine Hackertools zu verlinken. Ich möchte darum bitten, in einer ggf. entstehenden Diskussion ebenso zu verfahren.
Ich möchte mit diesem Erfahrungsbericht auf einen Umstand hinweisen, der vielen evtl. nicht bewusst ist und der auch von Microsoft nicht an die große Glocke gehängt wird.
Es geht um Schwächen bei der Implementierung von SSO bzw. Kerberos in allen MS-Betriebssystemen bis hoch zu Windows 8. [Wie sich herausstellen wird, ist bei 8.1 bzw. 2012 R2 offenbar tatsächlich endlich umgedacht worden]
Meldet man sich bei Windows an, so wird das eigene Kennwort verschlüsselt im RAM eingelagert.
Es wird immer dann vom Betriebssystem „hervorgeholt“, wenn es um Authentifizierung geht: Freigabenbenutzung, Druckerbenutzung, Mailserverbenutzung, Proxyauthentifizierung…usw.
Zusätzlich kann man einschalten, dass dieses Kennwort auch für Remotedesktopsitzungen durchgereicht wird (“RDP-SSO“), aber das ist hier nicht Thema, da man dies nicht nutzen muss. Kerberos hingegen MUSS man nutzen, sonst kann man seine Domäne gleich vergessen.
Bislang klingt das nicht sonderlich gefährlich. Leider ist einem Franzosen (le gentil kiwi) schon vor einiger Zeit (ca. 2011) aufgefallen, dass es nicht sonderlich schwierig ist, dieses Kennwort aus dem RAM zu extrahieren und zu entschlüsseln. Tatsächlich ist es sogar dermaßen einfach, dass ohne den geringsten Zeitverzug beliebig lange, komplexe Kennwörter sofort im Klartext ausgegeben werden können! Und nicht nur die eigenen…
Sobald jemand Debugrechte auf einem PC hat, kann er mittels eines einfachen Scriptkiddietools die Kennwörter sämtlicher Nutzer auslesen, die auf diesem PC angemeldet sind oder waren, seit dieser das letzte Mal eingeschaltet wurde. Man kann also sogar die Kennwörter von bereits abgemeldeten Nutzern sehen…
Die Tragweite dieses Umstandes ist immens. Wer kann dafür garantieren, dass sich seine Nutzer nicht jetzt oder später durch Exploits Debugrechte auf Ihren Rechnern verschaffen? Wer mag dafür garantieren, dass sie es nicht sogar auf allgemein genutzten „Dauerläufern“ wie Präsentationsrechnern oder gar Terminalservern schaffen und dort kurzerhand die Kennwörter ALLER (seit dem letzten Neustart) angemeldeter Benutzer abgreifen? Wer mag mit diesem Wissen dann noch an einem gemeinsam genutzten PC ein Adminkonto nutzen, das in irgendeiner Form globale Rechte in der Domäne hat? Man bedenke hierbei, dass jeder Nutzer-PC, den ein Admin wartet, hierbei unter „gemeinsam genutzter PC“ fällt.
Zudem kommt, dass somit auch ein anderes Prinzip nicht mehr gilt. Bislang galt: ein Admin konnte nie als Nutzer handeln. Er konnte zwar dessen Kennwort ändern, nicht jedoch ohne dass der Benutzer es merken würde – somit war der Administrator nicht ohne Weiteres unter Generalverdacht, sich als Nutzer ausgeben zu können (Identitätsdiebstahl) und damit Schindluder zu treiben und ungeliebte Kollegen beispielsweise zu mobben oder anderweitig zu schädigen.
Nun kann der Admin dies tun und zwar im Handumdrehen. Datenschutzrechtlich ein GAU.
Ich schreibe das hier, da ich denke, dass sich jeder Admin mit diesem Problem auseinander setzen muss. Es hinterfragt diverse gängige Arbeitsweisen bei der Administration (zumindest bei uns…, siehe beispielsweise Wer nutzt 2-Factor-Authentifizierung in seiner Windowsdomain? ).
Zumindest kann vermeldet werden, dass Microsoft offenbar reagiert und seit Windows 8.1/Server 2012 R2 andere Methoden nutzt, um das Kennwort zu sichern. Es wird sich noch zeigen müssen, ob diese nicht anderweitig ebenso einfach angreifbar sind.
*Update*Es gibt Neuigketen: Microsoft hat versucht, auf win7 und 2008 R2/2012 nachzubessern - man darf hoffen. http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871 ...
Ebenso passend zum Thema ist folgender Link: Dauerkarte für Windows-Domänen: das "golden ticket"
Vorwort: ich habe mit Frank abgeklärt, dass ich dieses Thema ansprechen darf, wenn ich diverse Dinge beachte, zum Beispiel, keine Hackertools zu verlinken. Ich möchte darum bitten, in einer ggf. entstehenden Diskussion ebenso zu verfahren.
Ich möchte mit diesem Erfahrungsbericht auf einen Umstand hinweisen, der vielen evtl. nicht bewusst ist und der auch von Microsoft nicht an die große Glocke gehängt wird.
Es geht um Schwächen bei der Implementierung von SSO bzw. Kerberos in allen MS-Betriebssystemen bis hoch zu Windows 8. [Wie sich herausstellen wird, ist bei 8.1 bzw. 2012 R2 offenbar tatsächlich endlich umgedacht worden]
Meldet man sich bei Windows an, so wird das eigene Kennwort verschlüsselt im RAM eingelagert.
Es wird immer dann vom Betriebssystem „hervorgeholt“, wenn es um Authentifizierung geht: Freigabenbenutzung, Druckerbenutzung, Mailserverbenutzung, Proxyauthentifizierung…usw.
Zusätzlich kann man einschalten, dass dieses Kennwort auch für Remotedesktopsitzungen durchgereicht wird (“RDP-SSO“), aber das ist hier nicht Thema, da man dies nicht nutzen muss. Kerberos hingegen MUSS man nutzen, sonst kann man seine Domäne gleich vergessen.
Bislang klingt das nicht sonderlich gefährlich. Leider ist einem Franzosen (le gentil kiwi) schon vor einiger Zeit (ca. 2011) aufgefallen, dass es nicht sonderlich schwierig ist, dieses Kennwort aus dem RAM zu extrahieren und zu entschlüsseln. Tatsächlich ist es sogar dermaßen einfach, dass ohne den geringsten Zeitverzug beliebig lange, komplexe Kennwörter sofort im Klartext ausgegeben werden können! Und nicht nur die eigenen…
Sobald jemand Debugrechte auf einem PC hat, kann er mittels eines einfachen Scriptkiddietools die Kennwörter sämtlicher Nutzer auslesen, die auf diesem PC angemeldet sind oder waren, seit dieser das letzte Mal eingeschaltet wurde. Man kann also sogar die Kennwörter von bereits abgemeldeten Nutzern sehen…
Die Tragweite dieses Umstandes ist immens. Wer kann dafür garantieren, dass sich seine Nutzer nicht jetzt oder später durch Exploits Debugrechte auf Ihren Rechnern verschaffen? Wer mag dafür garantieren, dass sie es nicht sogar auf allgemein genutzten „Dauerläufern“ wie Präsentationsrechnern oder gar Terminalservern schaffen und dort kurzerhand die Kennwörter ALLER (seit dem letzten Neustart) angemeldeter Benutzer abgreifen? Wer mag mit diesem Wissen dann noch an einem gemeinsam genutzten PC ein Adminkonto nutzen, das in irgendeiner Form globale Rechte in der Domäne hat? Man bedenke hierbei, dass jeder Nutzer-PC, den ein Admin wartet, hierbei unter „gemeinsam genutzter PC“ fällt.
Zudem kommt, dass somit auch ein anderes Prinzip nicht mehr gilt. Bislang galt: ein Admin konnte nie als Nutzer handeln. Er konnte zwar dessen Kennwort ändern, nicht jedoch ohne dass der Benutzer es merken würde – somit war der Administrator nicht ohne Weiteres unter Generalverdacht, sich als Nutzer ausgeben zu können (Identitätsdiebstahl) und damit Schindluder zu treiben und ungeliebte Kollegen beispielsweise zu mobben oder anderweitig zu schädigen.
Nun kann der Admin dies tun und zwar im Handumdrehen. Datenschutzrechtlich ein GAU.
Ich schreibe das hier, da ich denke, dass sich jeder Admin mit diesem Problem auseinander setzen muss. Es hinterfragt diverse gängige Arbeitsweisen bei der Administration (zumindest bei uns…, siehe beispielsweise Wer nutzt 2-Factor-Authentifizierung in seiner Windowsdomain? ).
Zumindest kann vermeldet werden, dass Microsoft offenbar reagiert und seit Windows 8.1/Server 2012 R2 andere Methoden nutzt, um das Kennwort zu sichern. Es wird sich noch zeigen müssen, ob diese nicht anderweitig ebenso einfach angreifbar sind.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 221524
Url: https://administrator.de/contentid/221524
Ausgedruckt am: 16.11.2024 um 09:11 Uhr
20 Kommentare
Neuester Kommentar
Hallo DerWoWusste,
ich habe mir das Tool gerade mal angeschaut. User: Nein, DomAdmin: Ja. Daher selbst unter Win8.1 und Server 2012R2 lässt sich so das Passwort des Domadmins noch auslesen. Ggf. aber dann nur, wenn dieser angemeldet ist.
Ich werde mir das die Tage nochmals genauer anschauen. Evtl. gibt es dagegen bereits abhilfe. Im Rahmen der o.g Disclaimers nenne ich den Link dazu nicht, da darauf auch das Hacktool zu finden ist.
LG,
Christian
ich habe mir das Tool gerade mal angeschaut. User: Nein, DomAdmin: Ja. Daher selbst unter Win8.1 und Server 2012R2 lässt sich so das Passwort des Domadmins noch auslesen. Ggf. aber dann nur, wenn dieser angemeldet ist.
Ich werde mir das die Tage nochmals genauer anschauen. Evtl. gibt es dagegen bereits abhilfe. Im Rahmen der o.g Disclaimers nenne ich den Link dazu nicht, da darauf auch das Hacktool zu finden ist.
LG,
Christian
Hallo DerWoWusste,
richtig, wie Du schon sagst, die Tools dazu gibt es bereits seit 2011, aber auch für den aktuellsten 8.1er Release gibt es eine Möglichkeit.
Davon mal abgesehen, die Pwd-Hashes waren schon immer angreifbar.
(zugegeben, nicht direkt über einen Memory-Dump; aber als Admin kann einem der Zwischenschritt mit den Tables und einem zusätzlichen AD-Controller doch ohnehin egal sein...)
Von daher: ich frage mich, warum das so bedenklich ist?
Es mag zwar mit der Katze bequemer sein, aber das Loch war schon immer da, und ich denke, das wird auch ein Weilchen so bleiben, bis sich die Authentifizierung ANDERS löst. Auch Linux speichert seine passwd ja als Hash
Lonesome Walker
richtig, wie Du schon sagst, die Tools dazu gibt es bereits seit 2011, aber auch für den aktuellsten 8.1er Release gibt es eine Möglichkeit.
Davon mal abgesehen, die Pwd-Hashes waren schon immer angreifbar.
(zugegeben, nicht direkt über einen Memory-Dump; aber als Admin kann einem der Zwischenschritt mit den Tables und einem zusätzlichen AD-Controller doch ohnehin egal sein...)
Von daher: ich frage mich, warum das so bedenklich ist?
Es mag zwar mit der Katze bequemer sein, aber das Loch war schon immer da, und ich denke, das wird auch ein Weilchen so bleiben, bis sich die Authentifizierung ANDERS löst. Auch Linux speichert seine passwd ja als Hash
Lonesome Walker
Hi!
das cracken von Hashes hängt ja doch noch von der passwort Länge ab. oder gibt es die tables schon > 10 Zeichen einfach verfügbar?
das andere Thema ist aber, dass du in vielen Firmen das password per analog Telefon "cracken" kannst. hier helfen auch Admins die ihre user dazu erziehen, dem Admin das passwort für die Softwareinstallatoon zu geben.
ev. hat das schon bei der NSA funktioniert...
http://orf.at/stories/2205651/2205652/
wie sieht das bei Zertifikaten aus - PKI?
sg Dirm
ohne den geringsten Zeitverzug beliebig lange, komplexe Kennwörter sofort im Klartext
das ist eigentlich das schlimme daran.das cracken von Hashes hängt ja doch noch von der passwort Länge ab. oder gibt es die tables schon > 10 Zeichen einfach verfügbar?
das andere Thema ist aber, dass du in vielen Firmen das password per analog Telefon "cracken" kannst. hier helfen auch Admins die ihre user dazu erziehen, dem Admin das passwort für die Softwareinstallatoon zu geben.
ev. hat das schon bei der NSA funktioniert...
http://orf.at/stories/2205651/2205652/
wie sieht das bei Zertifikaten aus - PKI?
sg Dirm
Zitat von @Dirmhirn:
das cracken von Hashes hängt ja doch noch von der passwort Länge ab. oder gibt es die tables schon > 10 Zeichen
einfach verfügbar?
das cracken von Hashes hängt ja doch noch von der passwort Länge ab. oder gibt es die tables schon > 10 Zeichen
einfach verfügbar?
Schon laaaaaange
Lonesome Walker
Zitat von @16568:
> Zitat von @Dirmhirn:
> ----
> das cracken von Hashes hängt ja doch noch von der passwort Länge ab. oder gibt es die tables schon > 10 Zeichen
> einfach verfügbar?
Schon laaaaaange
> Zitat von @Dirmhirn:
> ----
> das cracken von Hashes hängt ja doch noch von der passwort Länge ab. oder gibt es die tables schon > 10 Zeichen
> einfach verfügbar?
Schon laaaaaange
hmmm, ja da gibt es wirklich schon mehr zu finden als noch vor ein paar Jahren. :D
allerdings mit den immer wieder empfohlenen Mischungen aus Groß, Klein, Zahlen, Sonderzeichen und min 10 Zeichen - würde ich mir auf den ersten Blick noch recht sicher sein.
ich denke aber trotzdem, dass dies weniger Gefahr birgt als das einfache Auslesen aus dem RAM mit einem Tool.
Online-Dienste oder einige TByte Download sind vermutlich auch leichter nachweisbar, als ein kleines Tool.
Muss aber auch zugeben, dass ich erst vor kurzem in einem Kurs auf der Uni WPA, falsch implementiertes OTP, MD5, ... "gecrackt" habe - obwohl ich wusste, dass das möglich ist, war ich doch etwas überrascht wie extrem einfach das ganze schon geht.
nur kurze Passwörter, weil's eh wurscht ist - soweit ist es aber noch nicht - oder?!
Ist es eigentlich nicht eher das Problem, dass NTLM als Fallback für Kerberos genutzt wird - Kerberos basiert ja auf Tokken die nur eine bestimmte Zeit gültig sind, d.h. hierfür wird/müsste auch nicht das Passwort des Benutzers abgespeichert/werden.
sg Dirm
naja wenn der Benutzer sich per SmartCard mit Benutzerzertifikat und PIN anmeldet - dann ist ja eigentlich kein Passwort da, dass Windows im RAM speichern könnte.
Nein, mein Gedanke war, das für Kerberos bei Anmeldung ein Ticket erstellt wird, dass für die aktuelle Session gültig ist und mit dem man sich an div. Kerberos fähigen Ressourcen anmelden kann.
Das Passwort im Klartext (wie auch immer geheim-verwurstet) brauch ich ja nur, wenn ich mich mit dem Passwort selbst anmelden muss - da würde auch hashing nichts helfen, da man sich mit einem Hash ja nicht anmelden kann - na nona.
Ich les mal den Blog bevor ich hier mehr von mir gebe Ist auf den zweiten Blick ganz gut lesbar, obwohl ich mich in der 2. Klasse geistig von französisch verabschiedet habe ^^
> Ist es eigentlich nicht eher das Problem, dass NTLM als Fallback für Kerberos genutzt wird
...Du meinst mit "es", dass sich das Hackingtool mit NTLM-Hashen abgibt? Nein, es geht nicht auf die Hashes los. Die
Funktionsweise ist im Blog des Autors sehr ausführlich beschrieben.
natürlich ist "es" das Bööse! ...Du meinst mit "es", dass sich das Hackingtool mit NTLM-Hashen abgibt? Nein, es geht nicht auf die Hashes los. Die
Funktionsweise ist im Blog des Autors sehr ausführlich beschrieben.
Nein, mein Gedanke war, das für Kerberos bei Anmeldung ein Ticket erstellt wird, dass für die aktuelle Session gültig ist und mit dem man sich an div. Kerberos fähigen Ressourcen anmelden kann.
Das Passwort im Klartext (wie auch immer geheim-verwurstet) brauch ich ja nur, wenn ich mich mit dem Passwort selbst anmelden muss - da würde auch hashing nichts helfen, da man sich mit einem Hash ja nicht anmelden kann - na nona.
Ich les mal den Blog bevor ich hier mehr von mir gebe Ist auf den zweiten Blick ganz gut lesbar, obwohl ich mich in der 2. Klasse geistig von französisch verabschiedet habe ^^
Zitat von @certifiedit.net:
Wie gehst du denn vor? (Vielleicht vertagen wir das weg vom öffentlichen?)
Wie gehst du denn vor? (Vielleicht vertagen wir das weg vom öffentlichen?)
Och, ich finde es interessant da einfach nur "zuzuhören".
Würde mich nämlich auch interessieren.
lks
Zitat von @DerWoWusste:
Moin certifiedIT und LKS.
Habe ich nun untersucht. Das Kennwort bleibt auch bei 2012R2/8.1 genau dann auslesbar, wenn man sich am PC ohne gesteckte
Netzwerkverbindung anmeldet (Sitzungstyp "cached interactive"), bzw. ohne Verbindung zum DC. Nach dem Abmelden jedoch
verschwindet das Kennwort aus dem RAM - damit kann ich leben.
Moin certifiedIT und LKS.
Habe ich nun untersucht. Das Kennwort bleibt auch bei 2012R2/8.1 genau dann auslesbar, wenn man sich am PC ohne gesteckte
Netzwerkverbindung anmeldet (Sitzungstyp "cached interactive"), bzw. ohne Verbindung zum DC. Nach dem Abmelden jedoch
verschwindet das Kennwort aus dem RAM - damit kann ich leben.
Das ist ein verhalten, daß in den meisten Fällen tolerierbar sein sollte.
lks