SMB1 für Scanner netzintern sicher nutzbar? Risiken?

[Ranayna]

Btw: Uber welches Protokoll mögen die Scans denn auf dem PC landen wenn der an ist? Weil wenn ich den PC anhabe, dann kann ich am Drucker problemlos "Scan to PC" wählen.

Was passiert denn wenn du das machst?
Reagiert der Treiber? Hast du eine Scannersoftware installiert die reagiert, wenn ja, welche? Oder taucht die Datei dann in irgendeinem Ordner auf?
Bei den ersten beiden Optionen koennte es eine Software fuer Linux geben die aehnliches macht. Falls die Datei irgendwo auftaucht hast du ggf. (vielleicht durch den Treiber) schon SMBv1 und eine Dateifreigabe aktiviert bekommen.

 

[TitoP]

@Krik Ok,klingt grundsätzlich nachvollziehbar und wäre vielleicht möglich. Aber sicher auch nicht so ganz easy, weil im Netz aktiv ist der ja immer, man kann den ja jederzeit mit nem Druckauftrag ansprechen damit er dann startet und was ausdruckt.

@Ranayna Kein Plan Wie Das genau passiert. Ich denke dadurch, dass der Druckertreiber startet. Die Scans landen dann per Default im Dokument-Ordner.

 

[Krik]

Ach so, der ist immer an? Ich schalte meinen nur an, wenn ich ihn brauche. Also alle paar Wochen mal.

 

[JackForceOne]

Mal eine ganz allgemeine Frage zu SMBv1.

Im Metasploit Framework wird geschrieben, dass der Angriff CVE-2017-0146 und CVE-2017-0143 ausnutzt.

In den entsprechenden Datenbanken steht aber, dass immer nur Microsofts Implementierung von SMBv1 verwundbar ist. Wenn jetzt hier SMBv1 auf dem Pi genutzt wird, ist doch dieser Angriff gar nicht mehr durchführbar. Das Problem mit EternalBlue etc. war doch, dass auf den DCs oft SMBv1 Freigaben existieren und ein Angreifer damit Kontrolle über die Domäne übernehmen konnte. Hier ist kein Windows Betriebssystem im Einsatz. Die Leute die hier Sicherheitsbedenken haben: könnt ihr den genauen Angriff der SMBv1 auf dem Pi ausnutzt bitte beschreiben und belegen?

 

[Cool Master]

@JackForceOne

Es hat nichts mit dem OS zu tun sondern mit SMB und das läuft unter Windows, Linux und macOS. Unter Linux wird halt statt "Windows-SMB" "Samba" genutzt. Also ja, auch angreifbar wenn einige Einstellungen zum tragen kommen.

Habe mich aber mal etwas mehr eingelesen und es sollte kein Problem mehr sein da Samba gepatched ist. Ich würde trotzdem alles unter SMBv3 im Netzwerk nicht mehr erlauben und wie ich schon schrieb lieber auf (S)FPT ausweichen, falls möglich.

Unter Linux kann man es also ausnutzen wenn:

• Samba läuft
• SMBv1 aktiviert ist
• Version ungepatcht / alt
• Shares schreibbar bzw. falsch konfiguriert

Wie gesagt ich würde aber einfach SMBv1 fallen lassen. Wenn es unbedingt sein muss v2 nutzen aber v3 hat so viele Verbesserungen, dass es einfach Sinn ergibt nur noch v3 zu nutzen oder eben Alternativen wie (S)FTP.

 

[JackForceOne]

Im professionellen Umfeld würde ich von sowas auch dringend abraten.

Aber privat im LAN, SMBv1 nur auf dem Pi damit der Drucker da die Scans ablegt - meiner Meinung nach kein Problem. Man kann den Drucker sich entsorgen und einen neuen kaufen. Aber das lohnt sich nur, wenn der Schaden einer ausgenutzten Lücke in diesem Scenario hoch und die Eintrittswahrscheinlichkeit etwas größer als 0 ist.

Natürlich hat es etwas mit dem Betriebssystem zu tun. Die Windows Implementierung hatte wie in den CVE Datenbanken einsehbar ist einen Implementierungsfehler, sodass ACE möglich war:

The SMBv1 server 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, 1511, and 1607; and Windows Server 2016 allows remote attackers to execute arbitrary code via crafted packets, aka "Windows SMB Remote Code Execution Vulnerability."

Ich wüsste nicht, dass die Linux SAMBA Implementierung auch diesen Fehler hatte. Und das Samba Paket unter Linux wird auch sehr regelmäßig aktualisiert.

Auf der Annahme, dass aber auch die Linux Implementierung Samba angreifbar war basiert doch die gesamte Annahme von Leuten hier im Thread, die SMBv1 unter Linux als Sicherheitsrisiko einstufen.

SMB / Samba Implementierungen, sei es von MS oder für Linux sind natürlich nie fehlerfrei, siehe hier, aber das hatte nichts mit EternalBlue zu tun.

Ich warte immer noch auf Argumente.