20
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 221524
Url: https://administrator.de/knowledge/sicherheitsprobleme-von-kerberos-221524.html
Ausgedruckt am: 21.12.2024 um 12:12 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
Schön, dass das Thema auf Interesse trifft.
@certifiedit
@lonesome Walker
@Dirmhirn
@certifiedit
ich habe mir das Tool gerade mal angeschaut. User: Nein, DomAdmin: Ja
Haben User Debugrechte? Natürlich nicht. Deshalb geht es nicht. Ich weise nur darauf hin, dass sobald User sich diese verschaffen, dem GAU nicht viel im Wege steht.Ich werde mir das die Tage nochmals genauer anschauen. Evtl. gibt es dagegen bereits abhilfe
Bin sehr gespannt, was Du Dir unter Abhilfe vorstellst. Da keine Hashes angegriffen werden, sondern der RAM, müsstest Du zur Abhilfe Windows dazu bringen, den RAM nicht mehr zu benutzen, bzw. jemanden mit Debugrechten nicht mehr den kompletten RAM auslesen lassen. Da wirst Du nichts finden, außer, dass die runterladbare Variante von Virenscannern gestoppt werden kann.@lonesome Walker
auch für den aktuellsten 8.1er Release gibt es eine Möglichkeit.
Ja? Der Franzose scheint diese nicht zu kennen. Er hatte einst geschrieben, dass 8.1 es anders macht, aber nicht konsequent anders. Jedoch kann ich mit der aktuellen Version nichts in 8.1 RTM ausrichten.Davon mal abgesehen, die Pwd-Hashes waren schon immer angreifbar
Hier werden keine Hashes angegriffen.@Dirmhirn
wie sieht das bei Zertifikaten aus - PKI?
Wie meinst Du das?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.
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 ^^
Falsch verstanden. User Password bekomme ich nicht mehr (elevated Rights Console), Admin Paswort bekomme ich aber als Rückgabe.
Wie gesagt, noch nicht durch gearbeitet.
Wie gesagt, noch nicht durch gearbeitet.
Du nutzt es auf 8.1 RTM? Bei mir geht da nix außer der Hashes. Kein Plaintextkennwort mehr, auch nicht das eigene.
Jup, 8.1 RTM. Doch, ist aber arg versteckt, da eine ziemliche Menge null Infos ausgegeben wird.
Hm?
Also Plaintext wird mir nichts ausgegeben. Die Ausgabe wird in eine Textdatei geleitet und durchsucht, von daher kann ich es schlecht übersehen. Seltsam.
Also Plaintext wird mir nichts ausgegeben. Die Ausgabe wird in eine Textdatei geleitet und durchsucht, von daher kann ich es schlecht übersehen. Seltsam.
Wie sieht deine Umgebung aus? Ich hab es in meiner Testumgebung (AD, Srv2012R2, Win8.1) probiert, dort hat es mir das Domänen Admin Passwort ausgegeben.
8.1 und 2008 Server. Bin mir recht sicher, dass der DC keine Geige spielt, hatte schon mal getestet mit 8.1 und 2012 R2 preview. Aber ich prüf das nochmal, sobald ich meine virtuelle Domäne aktualisiert habe.
Meine Testumgebung ist nun wie Deine. Das Kennwort wird nicht ausgegeben, nicht am Client, nicht am Server... wie hast Du das geschafft? 
Du sprichst nicht zufällig nur vom Hash des Kennwortes?
Weitere Infos für Interessierte: http://www.infoworld.com/d/security/windows-81-stops-pass-the-hash-atta ... und http://technet.microsoft.com/en-us/library/dn408190.aspx
Du sprichst nicht zufällig nur vom Hash des Kennwortes?Weitere Infos für Interessierte: http://www.infoworld.com/d/security/windows-81-stops-pass-the-hash-atta ... und http://technet.microsoft.com/en-us/library/dn408190.aspx
Würde mich freuen, wenn ich HASH wie Plaintext lesen könnte, aber ist wohl nicht so.
Wie gehst du denn vor? (Vielleicht vertagen wir das weg vom öffentlichen?)
Wie gehst du denn vor? (Vielleicht vertagen wir das weg vom öffentlichen?)
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
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.
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.
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
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"
Ebenso passend zum Thema ist folgender Link: Dauerkarte für Windows-Domänen: das "golden ticket"
Ich stoße gerade mal wieder auf das Thema, es war etwas untergegangen, seit wir alle Clients auf 8.1 aktualisiert haben.
Der Patch für Win7 (und vermutlich auch 2008R2) funktioniert, verhindert jedoch lediglich, dass das für Kerberos gespeicherte Passwort im Klartext sichtbar wird. wdigest und tspkg zeigen weiterhin das Klartextkennwort... auf win7, nicht auf 8.1
Die Mechanismen wdigest und tspkg muss man noch von Hand abschalten, einfach rauslöschen aus HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
+Reboot
Der Patch für Win7 (und vermutlich auch 2008R2) funktioniert, verhindert jedoch lediglich, dass das für Kerberos gespeicherte Passwort im Klartext sichtbar wird. wdigest und tspkg zeigen weiterhin das Klartextkennwort... auf win7, nicht auf 8.1
Die Mechanismen wdigest und tspkg muss man noch von Hand abschalten, einfach rauslöschen aus HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
+Reboot
