16
FYI: Schwachstelle bei der Telekom Digitalisierungsbox (Datenleck bei Arztpraxis)
In vielen kleinen Firmen wird die Digitalisierungsbox der Telekom ( Telekom-Business-Router) für den Internetzugang verwendet. In der Firmware dieser Box gab es aber lange Zeit eine Schwachstelle (Bug bei der Portweiterleitung), die die Infrastruktur hinter der Box aus dem Internet angreifbar macht. Mir ist ein Hinweis auf einen konkreten Fall bekannt, wo eine Infektion mit Petya per SMB-Portfreigaben über diesen Weg statt gefunden haben dürfte.
Gerade ist bei heise ja ein Newsticker-Beitrag über ein Datenleck bei einer Arztpraxis in Celle publiziert worden. Ein Server war ungeschützt per Internet erreichbar und bis zu 30.000 Patientendaten konnten eingesehen werden. Das ist die eine Seite der Medaille - hätte ich hier nicht weiter thematisiert.
Zu diesem Fall erreichte mich die Mail eines Blog-Lesers, der auf ein grundsätzliches Problem im Telekom-Business-Router hinwies. Seit Jahren enthielt die Firmware der Business-Router (Hersteller Bintec Elmeg) eine Schwachstelle in der Firmware, der bei HTTPS-Portweiterleitungen mehr Firewall-Ports (Ports 80-89 bzw. 440-449) gegenüber dem Internet öffnete als erwartet. In Folge steht auch der Port 445 für SMB-Freigaben offen. Netzwerk-Shares sind dann per Internet zugreifbar.
Es scheint inzwischen ein Firmware-Update zu geben. Wer aber für eine Digitalisierungsbox der Telekom zuständig ist, sollte sich schlau machen (sofern noch nicht bekannt) und den Business-Router beim Arbeitgeber bzw. Kunden auf ungewollte Port-Freigaben/-Weiterleitungen überprüfen. Obwohl ich gerade erfahre, dass die Telekom die Router ihrer Kunden auf offene Ports prüft und ggf. per Brief informiert.
Datenleck bei Arztpraxis und Schwachstelle bei der Telekom Digitalisierungsbox
Patientendaten einer Arztpraxis offen im Netz
Gerade ist bei heise ja ein Newsticker-Beitrag über ein Datenleck bei einer Arztpraxis in Celle publiziert worden. Ein Server war ungeschützt per Internet erreichbar und bis zu 30.000 Patientendaten konnten eingesehen werden. Das ist die eine Seite der Medaille - hätte ich hier nicht weiter thematisiert.Telekom Digitalisierungsbox mit Schwachstelle
Zu diesem Fall erreichte mich die Mail eines Blog-Lesers, der auf ein grundsätzliches Problem im Telekom-Business-Router hinwies. Seit Jahren enthielt die Firmware der Business-Router (Hersteller Bintec Elmeg) eine Schwachstelle in der Firmware, der bei HTTPS-Portweiterleitungen mehr Firewall-Ports (Ports 80-89 bzw. 440-449) gegenüber dem Internet öffnete als erwartet. In Folge steht auch der Port 445 für SMB-Freigaben offen. Netzwerk-Shares sind dann per Internet zugreifbar.Es scheint inzwischen ein Firmware-Update zu geben. Wer aber für eine Digitalisierungsbox der Telekom zuständig ist, sollte sich schlau machen (sofern noch nicht bekannt) und den Business-Router beim Arbeitgeber bzw. Kunden auf ungewollte Port-Freigaben/-Weiterleitungen überprüfen. Obwohl ich gerade erfahre, dass die Telekom die Router ihrer Kunden auf offene Ports prüft und ggf. per Brief informiert.
Datenleck bei Arztpraxis und Schwachstelle bei der Telekom Digitalisierungsbox
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: 517990
Url: https://administrator.de/contentid/517990
Ausgedruckt am: 12.11.2024 um 19:11 Uhr
16 Kommentare
Neuester Kommentar
Da kann man nur hoffen das der von den Providern gewünschte Routerzwang der in letzter Zeit wieder aufflammt nicht wieder kommt! Dann hilft wie immer nur noch Router-Kaskade/Bridge-Mode.
Btw.
Telekom Digitalisierungsbox nahm es mit den Portfreigaben wohl nicht so genau
Btw.
Telekom Digitalisierungsbox nahm es mit den Portfreigaben wohl nicht so genau
Moin,
spannend wäre ja, ob die be.ip plus Kiste direkt von Bintec gleiches Verhalten aufweist.
Ich vermute mal nein. Daher frage ich mich, weshalb die DTAG dann so einen Mist da rein programmiert (lassen) hat!?
Auch interessant finde ich, dass - so zumindest der DTAG-Sprecher - man nicht eher auf das Problem mit einem Update reagiert hat und stattdessen 6 Monate bis zum Patchen braucht. Da ob man da die Telekom hinsichtlich DSGVO mit zur Kasse bitten kann? Zumindest, wenn es um den Punkt Schadensersatz geht!?
Gruß
em-pie
spannend wäre ja, ob die be.ip plus Kiste direkt von Bintec gleiches Verhalten aufweist.
Ich vermute mal nein. Daher frage ich mich, weshalb die DTAG dann so einen Mist da rein programmiert (lassen) hat!?
Auch interessant finde ich, dass - so zumindest der DTAG-Sprecher - man nicht eher auf das Problem mit einem Update reagiert hat und stattdessen 6 Monate bis zum Patchen braucht. Da ob man da die Telekom hinsichtlich DSGVO mit zur Kasse bitten kann? Zumindest, wenn es um den Punkt Schadensersatz geht!?
Gruß
em-pie
Huiuiui...
Was mich ja brennend interessieren würde: Warum betreibt eine Arztpraxis einen nach aussen offenen Webserver auf der gleichen IP wie ihren PVS Server???
Und wie kann man erklären, dass trotz der sekündlich stattfindenden Portscans irgendwelcher Bots über Monate kein größerer Schaden aufgetreten ist? Oder kommt da noch was? Es wird kaum Logs geben an denen man erkennen könnte, ob und wieviel abgeflossen ist...
Ich mache seit Jahren nach irgendwelchen Freigaben / Portweiterleitungen einen Portscan um mich zu vergewissern, dass ich nix vermurkst habe.
Sollte Best Practice werden...
VG
Buc
Was mich ja brennend interessieren würde: Warum betreibt eine Arztpraxis einen nach aussen offenen Webserver auf der gleichen IP wie ihren PVS Server???
Und wie kann man erklären, dass trotz der sekündlich stattfindenden Portscans irgendwelcher Bots über Monate kein größerer Schaden aufgetreten ist? Oder kommt da noch was? Es wird kaum Logs geben an denen man erkennen könnte, ob und wieviel abgeflossen ist...
Ich mache seit Jahren nach irgendwelchen Freigaben / Portweiterleitungen einen Portscan um mich zu vergewissern, dass ich nix vermurkst habe.
Sollte Best Practice werden...
VG
Buc
Hallo,
die schon primär fehlerhafte Idee ist ja die Portweiterleitung an sich. Mir fällt eigentlich kein Grund ein, warum man solche Weiterleitungen einrichten sollte, das Kerngeschäft einer Arztpraxis ist doch sicher nicht Websitehosting.
Zweiter Fehler: Freigaben ohne Sicherheitsbeschränkungen.
Das Dumme ist, das ich sowas durchaus einigen der Ärzte-IT-Systemhäuser zutrauen würde.
Über eine ähnlich risikoreiche Situation kann ich (aus dem Jahr 2007) berichten. Zum Glück gab es keinen Zwischenfall, allerdings einen Systemhauswechsel:
Situation damals: zwei Standorte sollten per RDP verbunden werden - die Lösung:
Seitdem finde ich es sinnvoll, den Anbieter von Praxissoftware und Infrastruktur zu trennen.
Grüße
lcer
die schon primär fehlerhafte Idee ist ja die Portweiterleitung an sich. Mir fällt eigentlich kein Grund ein, warum man solche Weiterleitungen einrichten sollte, das Kerngeschäft einer Arztpraxis ist doch sicher nicht Websitehosting.
Zweiter Fehler: Freigaben ohne Sicherheitsbeschränkungen.
Das Dumme ist, das ich sowas durchaus einigen der Ärzte-IT-Systemhäuser zutrauen würde.
Über eine ähnlich risikoreiche Situation kann ich (aus dem Jahr 2007) berichten. Zum Glück gab es keinen Zwischenfall, allerdings einen Systemhauswechsel:
Situation damals: zwei Standorte sollten per RDP verbunden werden - die Lösung:
- Windows 2003 als Arbeitsgruppenserver ohne AD.
- Telekom-Router mit Portweiterleitung auf den Praxisserver (ja, der mit den Patientendaten); der Praxisserver war VPN Endpunkt
- Zu Wartungszwecken war ein Admin-Benutzer „Server“ mit einem ziemlich einfachen Passwort eingerichtet.
Seitdem finde ich es sinnvoll, den Anbieter von Praxissoftware und Infrastruktur zu trennen.
Grüße
lcer
Hallo,
SBS2011 (z.B.)
Gruß,
Jörg
Zitat von @the-buccaneer:
Huiuiui...
Was mich ja brennend interessieren würde: Warum betreibt eine Arztpraxis einen nach aussen offenen Webserver auf der gleichen IP wie ihren PVS Server???
Huiuiui...
Was mich ja brennend interessieren würde: Warum betreibt eine Arztpraxis einen nach aussen offenen Webserver auf der gleichen IP wie ihren PVS Server???
SBS2011 (z.B.)
Gruß,
Jörg
Moin,
dann bin ich beim SBS 2011 doch wieder bei EoL seitens Microsoft zum 14.01.2020.
Gruß
VGem-e
(der es persönlich schade findet, dass diese "Wollmilchsau" von MS nicht weiter vertreiben wurde.)
dann bin ich beim SBS 2011 doch wieder bei EoL seitens Microsoft zum 14.01.2020.
Gruß
VGem-e
(der es persönlich schade findet, dass diese "Wollmilchsau" von MS nicht weiter vertreiben wurde.)
Zitat von @117471:
SBS2011 (z.B.)
Gruß,
Jörg
SBS2011 (z.B.)
Gruß,
Jörg
Nixraff??? Ich muss doch den SBS nicht ins Netz stellen damit er seinen Dienst tut???
Wenn der schön hinter verschlossenen Türen werkelt kann der noch bis zum Sanktnimmerleinstag betrieben werden.
(Was ich auch niemals empfehlen würde, da gewisse Risiken nicht mehr handhabbar werden, ich weiss...)
Buc
Hallo,
Port 443 fürs OWA.
Ich hänge immer einen Apache davor. Aber das ist sicherlich die Ausnahme.
Gruß,
Jörg
Port 443 fürs OWA.
Ich hänge immer einen Apache davor. Aber das ist sicherlich die Ausnahme.
Gruß,
Jörg
Zitat von @the-buccaneer:
Nixraff??? Ich muss doch den SBS nicht ins Netz stellen damit er seinen Dienst tut???
Zitat von @117471:
SBS2011 (z.B.)
Gruß,
Jörg
SBS2011 (z.B.)
Gruß,
Jörg
Nixraff??? Ich muss doch den SBS nicht ins Netz stellen damit er seinen Dienst tut???
TCP443 wird beim SBS2011 neben OWA auch für RWA (RDS Gateway) und SSTP verwendet.
Hallo,
Grüße
lcer
Zitat von @psannz:
TCP443 wird beim SBS2011 neben OWA auch für RWA (RDS Gateway) und SSTP verwendet.
Das ist alles keine Ausrede für das fehlende VPN.Zitat von @the-buccaneer:
Nixraff??? Ich muss doch den SBS nicht ins Netz stellen damit er seinen Dienst tut???
Zitat von @117471:
SBS2011 (z.B.)
Gruß,
Jörg
SBS2011 (z.B.)
Gruß,
Jörg
Nixraff??? Ich muss doch den SBS nicht ins Netz stellen damit er seinen Dienst tut???
TCP443 wird beim SBS2011 neben OWA auch für RWA (RDS Gateway) und SSTP verwendet.
Grüße
lcer
Hallo,
es gibt Gründe, nicht jeden via VPN reinzulassen. Nicht jede Lösung passt auf jedes Szenario.
Gruß,
Jörg
es gibt Gründe, nicht jeden via VPN reinzulassen. Nicht jede Lösung passt auf jedes Szenario.
Gruß,
Jörg
Wie praktisch, dass selbst dabei noch Fehler auftreten..... nach dem Patchen einen Werksreset, sonst geht es nicht.
https://www.heise.de/security/meldung/Nach-Datenleck-in-Arztpraxis-Weite ...
Nur mit dem neuesten Update geht es dann ohne Reset.
Man merkt immer wieder, dass in den magentafarbenen Köpfen nach wie vor nur braune stinkende Masse vorhanden ist.
https://www.heise.de/security/meldung/Nach-Datenleck-in-Arztpraxis-Weite ...
Nur mit dem neuesten Update geht es dann ohne Reset.
Man merkt immer wieder, dass in den magentafarbenen Köpfen nach wie vor nur braune stinkende Masse vorhanden ist.
Zitat von @117471:
Hallo,
es gibt Gründe, nicht jeden via VPN reinzulassen. Nicht jede Lösung passt auf jedes Szenario.
Gruß,
Jörg
Hallo,
es gibt Gründe, nicht jeden via VPN reinzulassen. Nicht jede Lösung passt auf jedes Szenario.
Gruß,
Jörg
Ist klar, aber ich würde ja auch nicht mein AD oder meinen Fileserver bei meinem Webhoster betreiben...
Ups.. oder doch? Ist ja modern... Ist ja Cloud... Alles von überall und immer... Supi!!!
In ner Arztpraxis muss höchstens der Doc von Zuhause an die Mails. Da sollte ein VPN wohl machbar sein. Selbst der SBS2011 kann L2TP/IPSec was noch als sicher gilt... Und RDP stellt man ja auch nicht ins Internet ohne weitere Absicherung. Hatten wir hier mal vor kurzem mit den Folgen...
CU
Buc
Servus,
ich habe in einigen Außenstellen auch dieses Gerät stehen, wenn auch nur zur Nutzung für Telefon und Fax.
Kann ich dann, ohne dass ich in jede Außenstelle fahren muss, prüfen, ob die automatischen Updates aktiviert sind? Und dann muss ich mir ggf. auch noch die Zugangsdaten besorgen (Tante G...gle wird hier hoffentlich weiterhelfen).
Gruß
ich habe in einigen Außenstellen auch dieses Gerät stehen, wenn auch nur zur Nutzung für Telefon und Fax.
Kann ich dann, ohne dass ich in jede Außenstelle fahren muss, prüfen, ob die automatischen Updates aktiviert sind? Und dann muss ich mir ggf. auch noch die Zugangsdaten besorgen (Tante G...gle wird hier hoffentlich weiterhelfen).
Gruß
Hallo,
das wäre eigentlich an anderes Thema...
Es gibt 2 Arten von Automatik-Updatefunktionen. Im "Normalfall" löst ein Gerät ein Update selbst aus (per http-Anfrage auf den Updateserver) - entweder manuell oder nach Zeitplan getriggert. Die Telekom-Router haben aber auch noch eine "Push"-Update-Funktion, das heißt der Provider kann sie über einen offenen Port selbst updaten. Dieser offene Port war in der Vergangenheit bereits einmal ein Sicherheitsproblem, der von externen Angreifern missbraucht werden konnte.
Empfehlung:
Von aussen kann man mittles Portscans überprüfen, ob das NAT bzw. die Firewall korrekt blockt. Dabei muss man ein paar Dinge beachten, da Portscans unter Umständen illegal sind.
Grüße
lcer
das wäre eigentlich an anderes Thema...
ich habe in einigen Außenstellen auch dieses Gerät stehen, wenn auch nur zur Nutzung für Telefon und Fax.
Kann ich dann, ohne dass ich in jede Außenstelle fahren muss, prüfen, ob die automatischen Updates aktiviert sind? Und dann muss ich mir ggf. auch noch die Zugangsdaten besorgen (Tante G...gle wird hier hoffentlich weiterhelfen).
Kann ich dann, ohne dass ich in jede Außenstelle fahren muss, prüfen, ob die automatischen Updates aktiviert sind? Und dann muss ich mir ggf. auch noch die Zugangsdaten besorgen (Tante G...gle wird hier hoffentlich weiterhelfen).
Es gibt 2 Arten von Automatik-Updatefunktionen. Im "Normalfall" löst ein Gerät ein Update selbst aus (per http-Anfrage auf den Updateserver) - entweder manuell oder nach Zeitplan getriggert. Die Telekom-Router haben aber auch noch eine "Push"-Update-Funktion, das heißt der Provider kann sie über einen offenen Port selbst updaten. Dieser offene Port war in der Vergangenheit bereits einmal ein Sicherheitsproblem, der von externen Angreifern missbraucht werden konnte.
Empfehlung:
- selbst hinfahren und Update manuell einspielen
- Überprüfen, ob das auch gelungen ist, z.B. mittels Portscan
- Provider-getriggerte Fernwartung deaktivieren
- regelmäßig den Updatestand vor Ort überprüfen
- keinen Fernzugriff auf den Router, außer mittels sicherem VPN aktivieren.
Von aussen kann man mittles Portscans überprüfen, ob das NAT bzw. die Firewall korrekt blockt. Dabei muss man ein paar Dinge beachten, da Portscans unter Umständen illegal sind.
Grüße
lcer
Reboot und erneuten Portscan nicht vergessen!
Nochmal über OpenSource nachdenken.
VG
Buc
Nochmal über OpenSource nachdenken.
VG
Buc
