Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Sicherheitsprobleme von Kerberos

Erfahrungsbericht Sicherheit

Mitglied: DerWoWusste

DerWoWusste (Level 5) - Jetzt verbinden

08.11.2013, aktualisiert 03.02.2015, 6973 Aufrufe, 20 Kommentare, 8 Danke

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: http://www.administrator.de/link/-240291.html
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 http://www.administrator.de/frage/wer-nutzt-2-factor-authentifizierung- ... ).

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.

Mitglied: certifiedit.net
09.11.2013 um 11:06 Uhr
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
Bitte warten ..
Mitglied: 16568
09.11.2013 um 11:33 Uhr
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
Bitte warten ..
Mitglied: Dirmhirn
09.11.2013, aktualisiert um 12:23 Uhr
Hi!

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
Bitte warten ..
Mitglied: 16568
09.11.2013 um 14:42 Uhr
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


Lonesome Walker
Bitte warten ..
Mitglied: Dirmhirn
09.11.2013 um 15:43 Uhr
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

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
Bitte warten ..
Mitglied: DerWoWusste
11.11.2013, aktualisiert um 15:35 Uhr
Schön, dass das Thema auf Interesse trifft.

@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.
Bitte warten ..
Mitglied: Dirmhirn
11.11.2013 um 15:51 Uhr
Zitat von DerWoWusste:
> wie sieht das bei Zertifikaten aus - PKI?
Wie meinst Du das?
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.

> 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!
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 ^^
Bitte warten ..
Mitglied: certifiedit.net
11.11.2013 um 16:23 Uhr
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.
Bitte warten ..
Mitglied: DerWoWusste
11.11.2013 um 16:37 Uhr
Du nutzt es auf 8.1 RTM? Bei mir geht da nix außer der Hashes. Kein Plaintextkennwort mehr, auch nicht das eigene.
Bitte warten ..
Mitglied: certifiedit.net
11.11.2013 um 17:13 Uhr
Jup, 8.1 RTM. Doch, ist aber arg versteckt, da eine ziemliche Menge null Infos ausgegeben wird.
Bitte warten ..
Mitglied: DerWoWusste
11.11.2013 um 18:11 Uhr
Hm?

Also Plaintext wird mir nichts ausgegeben. Die Ausgabe wird in eine Textdatei geleitet und durchsucht, von daher kann ich es schlecht übersehen. Seltsam.
Bitte warten ..
Mitglied: certifiedit.net
11.11.2013, aktualisiert um 18:21 Uhr
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.
Bitte warten ..
Mitglied: DerWoWusste
11.11.2013 um 20:21 Uhr
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.
Bitte warten ..
Mitglied: DerWoWusste
12.11.2013, aktualisiert um 10:13 Uhr
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
Bitte warten ..
Mitglied: certifiedit.net
12.11.2013 um 10:30 Uhr
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?)
Bitte warten ..
Mitglied: Lochkartenstanzer
12.11.2013 um 10:47 Uhr
Zitat von certifiedit.net:
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
Bitte warten ..
Mitglied: DerWoWusste
13.11.2013, aktualisiert um 08:29 Uhr
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.
Bitte warten ..
Mitglied: Lochkartenstanzer
13.11.2013 um 11:46 Uhr
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.

Das ist ein verhalten, daß in den meisten Fällen tolerierbar sein sollte.

lks
Bitte warten ..
Mitglied: DerWoWusste
06.06.2014, aktualisiert 03.02.2015
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: http://www.administrator.de/link/-240291.html
Bitte warten ..
Mitglied: DerWoWusste
09.10.2014, aktualisiert um 20:53 Uhr
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
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Erkennung und -Abwehr
Studie: TLS-Proxies bringen Sicherheitsprobleme

Link von agowa338 zum Thema Erkennung und -Abwehr ...

Heiß diskutierte Inhalte
Windows Server
DHCP Server switchen (25)

Frage von M.Marz zum Thema Windows Server ...

SAN, NAS, DAS
gelöst HP-Proliant Microserver Betriebssystem (14)

Frage von Yannosch zum Thema SAN, NAS, DAS ...

Grafikkarten & Monitore
Win 10 Grafikkarte Crash von Software? (13)

Frage von Marabunta zum Thema Grafikkarten & Monitore ...

Windows 7
Verteillösung für IT-Raum benötigt (12)

Frage von TheM-Man zum Thema Windows 7 ...