2
Inszenierung von Sicherheitslücken: Das lange Warten auf Badlock
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 301787
Url: https://administrator.de/contentid/301787
Printed on: April 26, 2024 at 15:04 o'clock
2 Comments
Latest comment
Moin.
Es ist doch ziemlich Wurst, ob das nun eine dramatische Lücke war, oder nicht. Wir leben mit dem Wissen, dass Microsoft Regierungen mit dem Wissen über Angreifbarkeit versorgt, damit diese das ausnutzen können - was will man noch mehr dazu sagen? Wer seine Systeme direkt mit dem Internet reden lässt, ist selber Schuld.
Und wen dann noch wirklich interessiert, worum es bei einem Exploit geht, hat allergrößte Mühe, die Details zu finden. Auch auf den Securityseiten sind die Beschreibungen schwammig bis zum Abwinken. Keiner, wirklich niemand scheint durchzublicken und oder willens, ein konkretes Beispiel für einen Angriffsablauf zu beschreiben.
Beispiel gefällig? Nehmen wir Badlock, hier die Windowssektion, nicht Samba. http://badlock.org/ betitelt
Schauen wir mal weiter auf http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0128
Dritte schreiben dann (z.B. http://www.theregister.co.uk/2016/04/12/badlock_bug_windows_samba/ )
Sicherheitsadvisories und damit verbundene Artikel sind meist einfach nur noch Theater. Grausam.
Wozu das führt ist Verblendung, Gleichgültigkeit und Unaufmerksamkeit bei den Admins.
Kleiner Test eben zum Thema Gleichgültigkeit und Unaufmerksamkeit:
Frage (ganz ernst gemeint): wer hier gibt zu, nicht zu wissen, dass bei einem Patch aus 2015 manuelle Nacharbeit nötig war, um die Domänensicherheit zu gewährleisten?
[Ich werde die Auflösung noch nennen]
Es ist doch ziemlich Wurst, ob das nun eine dramatische Lücke war, oder nicht. Wir leben mit dem Wissen, dass Microsoft Regierungen mit dem Wissen über Angreifbarkeit versorgt, damit diese das ausnutzen können - was will man noch mehr dazu sagen? Wer seine Systeme direkt mit dem Internet reden lässt, ist selber Schuld.
Und wen dann noch wirklich interessiert, worum es bei einem Exploit geht, hat allergrößte Mühe, die Details zu finden. Auch auf den Securityseiten sind die Beschreibungen schwammig bis zum Abwinken. Keiner, wirklich niemand scheint durchzublicken und oder willens, ein konkretes Beispiel für einen Angriffsablauf zu beschreiben.
Beispiel gefällig? Nehmen wir Badlock, hier die Windowssektion, nicht Samba. http://badlock.org/ betitelt
Badlock, a crucial security bug in Windows and Samba
Aha, in beidem. Weiter unten folgt dann:Who is affected?
Affected versions of Samba are
...
von Windows keine Rede mehr. Äh...?Affected versions of Samba are
...
How can I fix my systems?
Please apply the patches provided by the Samba Team...
Auch in dieser Sektion keine Rede mehr vom Windowspatch. Klasse.Please apply the patches provided by the Samba Team...
Schauen wir mal weiter auf http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0128
The SAM and LSAD protocol implementations in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 do not properly establish an RPC channel, which allows man-in-the-middle attackers to perform protocol-downgrade attacks and impersonate users by modifying the client-server data stream, aka "Windows SAM and LSAD Downgrade Vulnerability" or "BADLOCK."
Aha, Impersonation also. Und wer ist wann wie betroffen? Schauen wir auf den verlinkten https://technet.microsoft.com/en-us/library/security/ms16-047.aspxMy application or product uses the SMB protocol, does this issue affect me?
No. Only applications and products that use the SAM or LSAD remote protocols are affected by this issue. The SMB protocol is not vulnerable.
Gut. Weiter zum verlinkten https://support.microsoft.com/en-us/kb/3148527No. Only applications and products that use the SAM or LSAD remote protocols are affected by this issue. The SMB protocol is not vulnerable.
An elevation of privilege vulnerability exists in the Security Account Manager (SAM) and Local Security Authority (Domain Policy) (LSAD) remote protocols when they accept authentication levels that do not protect these protocols adequately. The vulnerability is caused by the way the SAM and LSAD remote protocols establish the Remote Procedure Call (RPC) channel. An attacker who successfully exploited this vulnerability could gain access to the SAM database
Oho. Der Angreifer kann von remote an die SAM ran? Also auch an die des Domänencontrollers und dann... alle Konten benutzen? Aber der Threat level ist dennoch nicht critical sondern nur "important"?Dritte schreiben dann (z.B. http://www.theregister.co.uk/2016/04/12/badlock_bug_windows_samba/ )
In fact, it would be extremely difficult for cybercriminals to exploit the Badlock vulnerability. The attacker would need to be already inside the network and past any security mechanisms. He must be in a place in which he can sniff and intercept the traffic and would need administrative credentials to access resources required for network interception from inside the network.
OK, ein Mitarbeiter könnte also jederzeit rumsniffen, er braucht nur lokale Adminrechte und kann dann einen Domänencontroller hops nehmen? Oder nicht? Welche "resources required for network interception" wären das, Switches? BITTE GENAUER, Microsoft und Co. KG.Sicherheitsadvisories und damit verbundene Artikel sind meist einfach nur noch Theater. Grausam.
Wozu das führt ist Verblendung, Gleichgültigkeit und Unaufmerksamkeit bei den Admins.
Kleiner Test eben zum Thema Gleichgültigkeit und Unaufmerksamkeit:
Frage (ganz ernst gemeint): wer hier gibt zu, nicht zu wissen, dass bei einem Patch aus 2015 manuelle Nacharbeit nötig war, um die Domänensicherheit zu gewährleisten?
[Ich werde die Auflösung noch nennen]
1
So, für alle, die's abonniert haben sollten und noch eine Lösung erwarten:
https://blogs.technet.microsoft.com/askpfeplat/2015/02/22/guidance-on-de ...
https://blogs.technet.microsoft.com/askpfeplat/2015/02/22/guidance-on-de ...
1