Zero-Day-Lücke im SMB Protokoll

[ChrisRa 42]

Siehe News:

 

https://www.heise.de/security/meldung/Zero-Day-Luecke-in-SMB-Bibliothek-von-Windows-3616990.html

[DocData 85]

 

 

Um sich bis dahin abzusichern, empfiehlt das CERT, SMB zu deaktivieren oder zumindest die TCP-Ports 139 und 445 und die UDP-Ports 137 und 138 auf Firewalls zu blockieren.

 

Jetzt ernsthaft? Wer zur Hölle gibt die Ports frei (bei IPv6) oder konfiguriert dafür DNAT??

[NilsK 2,940]

Moin,

 

naja, es geht ja auch um Angriffe innerhalb eines Unternehmens. Da ist Abschalten von SMB schlicht nicht möglich ...

 

Gruß, Nils

[testperson 1,693]

Hi,

 

laut dem Artikel müsste der pöse Pursche eine "bösartige Ressource" bereitstellen und ein Client müsste darauf zugreifen.

Da müssten sich dann aber auch schon eine ganze Menge tragischer Verwicklungen ergeben oder es wurde an diversen anderen Stellen "geschlampt".

 

Gruß

Jan

[NorbertFe 2,053]

Naja diverse Man in the middle attacks der letzten Monate (UNC Hardening und Konsorten) waren deutlich aufwendiger als eine SMB Ressource hinzustellen und die Leute dorthin zu lotsen. ;)

[ChrisRa 42]

In der Praxis wohl in den meisten Unternehmen machbar. Es braucht ja nur eine LAN-Dose und einen nicht gesperrten Bildschirm. Ist allerdings die Frage, was es einem bringt, einem Client einen BSOD zu verpassen.

[MurdocX 952]

Jetzt ernsthaft? Wer zur Hölle gibt die Ports frei (bei IPv6) oder konfiguriert dafür DNAT??

 

*rheusper* Ich könnte Dir ein sicher mindestens 300 Clients und etliche Server nennen die in einem öffentlichen Netz, nur mit der Windows-Firewall, stehen.  :(

[v-rtc 88]

Danke für die Info.

[NorbertFe 2,053]

In der Praxis wohl in den meisten Unternehmen machbar. Es braucht ja nur eine LAN-Dose und einen nicht gesperrten Bildschirm. Ist allerdings die Frage, was es einem bringt, einem Client einen BSOD zu verpassen.

Zitat:

Im schlimmsten Fall könnten Angreifer sogar Schadcode auf Systeme schieben und mit Kernel-Rechten ausführen

[ChrisRa 42]

Stimmt!  :)