{"id":225158,"date":"2019-11-22T15:55:08","date_gmt":"2019-11-22T14:55:08","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=225158"},"modified":"2022-02-25T16:42:27","modified_gmt":"2022-02-25T15:42:27","slug":"datenleck-bei-arztpraxis-und-schwachstelle-bei-der-telekom-digitalisierungsbox","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2019\/11\/22\/datenleck-bei-arztpraxis-und-schwachstelle-bei-der-telekom-digitalisierungsbox\/","title":{"rendered":"Datenleck bei Arztpraxis und Schwachstelle bei der Telekom Digitalisierungsbox"},"content":{"rendered":"

Gerade wurden ein Datenleck aufgedeckt, bei dem ein Server einer Arztpraxis mit Tausenden an Patientendaten offen im Internet erreichbar war. Mit beteiligt, eine Digitalisierungsbox der Telekom, deren Ports (wegen einer Firmware-Schwachstelle) offen standen. In diesem Zusammenhang erreichte mich die Mail eines Blog-Lesers, der bereits vor 1,5 Jahren auf das Problem hingewiesen hat. K\u00f6nnte im Umkehrschluss bedeuten, dass in Deutschland tausende kleine Firmen und Mittelst\u00e4ndler mit dieser Konstellationen einem Sicherheitsrisiko ausgesetzt sind. Hier mal ein paar Zutaten zum Gesamtbild anger\u00fchrt.<\/p>\n

<\/p>\n

Das Datenleck in der Arztpraxis<\/h2>\n

\"\"Dem IT-Experte Cedric Fischer von der Firma CeFisystems war ein ungesch\u00fctzter Server einer Arztpraxis im Raum Hannover im Internet aufgefallen. Auf dem Server waren s\u00e4mtliche Patientendaten, darunter circa 20.000 Stammdaten, in einer Datenbank offen zug\u00e4nglich.<\/p>\n

\"Datenleck<\/a><\/p>\n

Fischer informierte die Redaktion der heise-Zeitschrift c't, die den Fall heute im Newsticker-Beitrag Warum eine komplette Arztpraxis offen im Netz stand<\/a> \u00f6ffentlich gemacht hat. \u201eIn dem konkreten Fall waren sowohl alle Daten von rund 30.000 Patienten einer Celler Arztpraxis offen im Netz auffindbar, als auch Arbeitsvertr\u00e4ge, K\u00fcndigungen, Spenden\/Schuldnerlisten etc. von und \u00fcber den Inhaber der Praxis einsehbar\", so der betreffende c't-Redakteur.<\/p>\n

Der Server ist mittlerweile zwar vom Netz genommen. Aber das ist ein Vorfall der nach der Datenschutzgrundverordnung meldepflichtig ist. Besonders brisant ist, dass hochsensible Patientendaten frei abrufbar waren.<\/p>\n

Problem: Sicherheitsl\u00fccke im Telekom-Business-Router<\/h2>\n

Im oben verlinkten heise-Artikel ist beschrieben, dass es mehrere Schritte bedurfte, um den offenen Server vom \u00f6ffentlichen Netz zu nehmen. Das hat auch mit der verwendeten Infrastruktur f\u00fcr den Internetzugang zu tun.<\/p>\n

In der Arztpraxis kam ein Telekom-Business-Router, als \"Digitalisierungs\u00adbox Premium<\/a>\" an Gesch\u00e4ftskunden vermarktet, zum Einsatz. Zu diesem Router war heise von IT-Experte Christian Zengel ein ungew\u00f6hnliches Verhalten gemeldet worden. Legt der Anwender \u00fcber das Webinterface des Business-Routers eine Port-Weiterleitung f\u00fcr HTTPS-Dienste an, wurden ungewollt mehr Ports als erwartet nach au\u00dfen hin freigegeben.<\/p>\n

Christian Zengel fand heraus, dass neben dem Standardport 443 f\u00fcr HTTPS-Weiterleitungen die Ports 440 bis 449 freigegeben wurden. Die Infrastruktur hinter dem Business-Router war also \u00fcber diesen Portbereich aus dem Internet erreichbar. Sobald Dritte, z.B. \u00fcber Suchmaschinen wie Shodan, die betreffenden IP-Adressen herausgefunden hatten, lie\u00df sich auf diese Infrastruktur zugreifen. So konnte (\u00fcber Port 445) auf die SMB-Freigaben des Servers der Arztpraxis zugegriffen werden.<\/p>\n

Bei weiteren Recherchen fiel heise auf, dass der Router auch die HTTP-Ports 80 bis 89 ungewollt freigegeben hatte. Zudem gibt es Optionen, die die Konfigurierung der Portfreigaben \u00fcber einen Router-Neustart hinaus persistent vorgeben. Vergisst man diese Einstellung, werden die Standardvorgaben bei jedem Router-Neustart zur\u00fcckgesetzt \u2013 was wohl beim Firmware-Update im Fall der Arztpraxis passiert war. Die Details hat heise ausf\u00fchrlich im Artikel<\/a> beschrieben.<\/p>\n

Gegen\u00fcber heise best\u00e4tigt die Telekom \u00fcber einen Unternehmenssprecher \u00fcber die Sicherheitsl\u00fccke beim Port-Forwarding seit Mai 2019 informiert gewesen zu sein. Unklar ist, warum diese Schwachstelle nicht umgehend mit einem Firmware-Update des Herstellers Bintec Elmeg behoben wurde. Es ist davon auszugehen, dass weitere Business-Kunden von dieser Schwachstelle betroffen sind.<\/p>\n

Das Problem bestand schon l\u00e4nger<\/h2>\n

Ich hatte die obige Geschichte heute beim schnellen \u00dcberfliegen der Nachrichtenlage gesehen und auf Beobachtung gesetzt. Gleichzeitig flatterte mir eine E-Mail von Blog-Leser Manfred S. in den Posteingang. Im Anhang war die Korrespondenz von Manfred mit der Redaktion von heise.<\/p>\n

Anmerkung: Es soll an dieser Stelle kein heise-Bashing betrieben werden. Deren Redakteure m\u00fcssen t\u00e4glich zig Mal entscheiden, ob sie ein Thema aufgreifen oder eher fallen lassen. Bekomme ich nat\u00fcrlich auch mit, wenn ich der Redaktion Themen f\u00fcr Beitr\u00e4ge vorschlage, die als Artikel abgelehnt werden, bei mir im Blog aber kr\u00e4ftig abgerufen werden. Ist kein Beinbruch und es ist Mut zur L\u00fccke gefragt. Aber ich fand die Korrespondenz von Manfred schon so interessant, dass ich einige Details hier im Blog ver\u00f6ffentliche.<\/p><\/blockquote>\n

Manfred schreibt, dass dass er schon vor 1,5 Jahren auf das Problem der falsch definierten Ports in Digi-Boxen (und vermutlich Bintec-Routern) hingewiesen habe. Manfred schreibt: 'Ich hatte damals einen Kunden mit Petya-Befall durch den Port 445' (das ist der Port, \u00fcber den SMB-Freigaben sichtbar sind und den man tunlichst nicht f\u00fcr das Internet freigeben sollte). Der Blog-Leser ist der Meinung, dass das ein riesiger Fehler ist, und gerade bei Kleinkunden und Mittelst\u00e4ndlern diese fehlerhaften Freigaben sehr h\u00e4ufig falsch eingetragen sein d\u00fcrften.<\/p>\n

Einige Details zum Problem<\/h3>\n

In seiner Korrespondenz legte Manfred bereits im Februar 2018 folgende Informationen offen. In einer ersten Mail machte er auf die offenen Ports aufmerksam.<\/p>\n

Ich weiss nicht, inwieweit das bekannt ist, aber bei der Standardkonfiguration der Telekom-Digitalisierungsbox (bintec elmeg) ist der Dienst\/Service http bzw. https standardm\u00e4\u00dfig jeweils mit den Ports 80-89 bzw. 440-449 vorbelegt. Ich dachte zuerst das ist ein Fehler auf einer bestehenden Digibox, aber nun habe ich schon einige f\u00fcr Kunden eingerichtet und dies ist auf allen Digiboxen die Voreinstellung (neben den Ports 80 und 443 haben dort aber keine anderen Ports etwas verloren).<\/p><\/blockquote>\n

Das ist also genau die Schwachstelle, die weiter oben im Text als Ursache f\u00fcr den im Internet erreichbaren Server der Arztpraxis war. Zu den Folgen schreibt Manfred:<\/p>\n

Dies hat z.B. zur Folge, wenn der https-Zugriff auf einen Webserver, SBS oder RD-Gateway eingerichtet werden soll und der Standardeintrag f\u00fcr https benutzt wird, dass neben 443 auch 440-449 (also z.B. auch SMB-Problem-Port 445) mit freigegeben wird.<\/p>\n

Ich denke, dass das schon ganz viele Klein- und Mittelst\u00e4ndler betrifft, weil \u00fcberall mit den neuen Anschl\u00fcssen Digiboxen eingerichtet werden und diese Freigaben sehr h\u00e4ufig genutzt werden. (sieht man z.B. ganz gut in dem Video http:\/\/digitalisierungsbox.bintec-elmeg.com\/premium-externer-zugriff-auf-webserver-webcam\/<\/a> bei Zeit ab 04:23 und dann siehe Ports 440-449 ab ca. 05:38).<\/p><\/blockquote>\n

In der Korrespondenz mit der heise-Redaktion wurde die Frage aufgeworfen, ob das oben verlinkte Video aus 2016 noch f\u00fcr aktuelle Firmware-Versionen gilt, oder ob es darin f\u00fcr das NAT\/Firewall-Objekt HTTPS ggf. schon eine Korrektur auf Port 443 only statt 440 bis 449 gibt. Darauf antwortete Manfred im Februar 2018:<\/p>\n

Problematische Standardkonfiguration der Telekom-Digitalisierungsbox<\/p>\n

Hallo Herr xxx,<\/p>\n

vielen Dank f\u00fcr Ihre R\u00fcckmeldung. Ja, ich kann best\u00e4tigen, dass das auch in der aktuellsten Firmware der Telekom-Digitalisierungsbox noch so ist (ich musste selber in den letzten zwei Wochen zwei neue konfigurieren).
\n[\u2026]
\nGef\u00e4hrdungspotential: ja, das ist schon richtig, dass nicht das ganze Netz offen ist. Ich habe allerdings aus meiner Praxis gesehen, dass sehr h\u00e4ufig kleine Windows-SBS-Server dranh\u00e4ngen, f\u00fcr die dann der Remote-Zugang \u00fcber 443 ge\u00f6ffnet wird (damit dann allerdings eben auch auf SMB-Port 445).<\/p>\n

Dies hatte letztes Jahr bei einem mir bekannten Fall zu einer Petya-Infizierung gef\u00fchrt. Es war lange unklar, wie der Infektionsweg gelaufen ist, erst bei der Analyse durch uns ist aufgefallen, dass irgendwann vorher der Router im Rahmen der Umstellung auf IP-Anschluss von der Telekom gegen eine Digibox ausgetauscht wurde, und hier auch vom Telekom-Techniker wieder der Eintrag f\u00fcr \"https\" gesetzt wurde (f\u00e4lschlicherweise damit auch Port 445). Daneben d\u00fcrfte es f\u00fcr jeden problematisch sein, der z.B. ein NAS oder \u00e4hnliches ohne VPN \u00fcber https zug\u00e4nglich macht (NAS macht h\u00e4ufig ebenfalls SMB\/445).<\/p>\n

Welchen Grund gibt es, standardm\u00e4\u00dfig auf einem massenhaft verbreiteten Router den Dienst \"https\" mit den Ports 440-449 zu definieren?<\/p>\n

Auszug aus z.B. RFC1700 (https:\/\/www.ietf.org\/rfc\/rfc1700.txt<\/a> ):<\/p>\n

sgcp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 440\/tcp\u00a0\u00a0\u00a0 sgcp
\nsgcp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 440\/udp\u00a0\u00a0\u00a0 sgcp
\n#
\ndecvms-sysmgt\u00a0\u00a0 441\/tcp\u00a0\u00a0\u00a0 decvms-sysmgt
\ndecvms-sysmgt\u00a0\u00a0 441\/udp\u00a0\u00a0\u00a0 decvms-sysmgt
\n#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Lee Barton barton@star.enet.dec.com<\/a>
\ncvc_hostd\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 442\/tcp\u00a0\u00a0\u00a0 cvc_hostd
\ncvc_hostd\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 442\/udp\u00a0\u00a0\u00a0 cvc_hostd
\n#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Bill Davidson billd@equalizer.cray.com<\/a>
\nhttps\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 443\/tcp\u00a0\u00a0\u00a0 https\u00a0 MCom
\nhttps\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 443\/udp\u00a0\u00a0\u00a0 https\u00a0 MCom
\n#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Kipp E.B. Hickman <kipp@mcom.com<\/a>>
\nsnpp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 444\/tcp\u00a0\u00a0\u00a0 Simple Network Paging Protocol
\nsnpp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 444\/udp\u00a0\u00a0\u00a0 Simple Network Paging Protocol
\n#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 [RFC1568]
\nmicrosoft-ds\u00a0\u00a0\u00a0 445\/tcp\u00a0\u00a0\u00a0 Microsoft-DS
\nmicrosoft-ds\u00a0\u00a0\u00a0 445\/udp\u00a0\u00a0\u00a0 Microsoft-DS
\n#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Arnold Miller <arnoldm@microsoft.com<\/a>>
\nddm-rdb\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 446\/tcp\u00a0\u00a0\u00a0 DDM-RDB
\nddm-rdb\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 446\/udp\u00a0\u00a0\u00a0 DDM-RDB
\nddm-dfm\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 447\/tcp\u00a0\u00a0\u00a0 DDM-RFM
\nddm-dfm\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 447\/udp\u00a0\u00a0\u00a0 DDM-RFM
\nddm-byte\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 448\/tcp\u00a0\u00a0\u00a0 DDM-BYTE
\nddm-byte\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 448\/udp\u00a0\u00a0\u00a0 DDM-BYTE
\n#\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Jan David Fisher <jdfisher@VNET.IBM.COM<\/a>>
\nas-servermap\u00a0\u00a0\u00a0 449\/tcp\u00a0\u00a0\u00a0 AS Server Mapper
\nas-servermap\u00a0\u00a0\u00a0 449\/udp\u00a0\u00a0\u00a0 AS Server Mapper<\/p>\n

All diese Ports (au\u00dfer 443) haben \u00fcberhaupt nichts mit dem Dienst \"https\" zu tun.<\/p><\/blockquote>\n

Nun l\u00e4sst sich das Fazit ziehen, dass diese Schwachstelle seit mindestens Februar 2018 im Telekom Business-Router bestand und eigentlich bekannt war. Das hei\u00dft im Umkehrschluss auch: Alle diese Router, die in deutschen Firmen in Betrieb sind und kein Firmware-Update erhalten haben und danach nicht in ihrer Konfigurierung \u00fcberpr\u00fcft wurden, setzen die Firmen dem Risiko aus, dass deren Server gegen\u00fcber dem Internet offen wie ein Scheunentor im Hinblick auf SMB-Freigaben sind. Die Informationen liegen also offen \u2013 falls jemand f\u00fcr die Konfiguration solcher Router verantwortlich ist, sollte er also handeln und eine \u00dcberpr\u00fcfung vornehmen.<\/p>\n

Nachtrag: Manfred schrieb mir gerade noch 'Im \u00dcbrigen f\u00e4llt mir gerade ein, dass die Telekom mittlerweile scheinbar die Kundenanschl\u00fcsse auf offene Ports abscannt und im Falle von offenen Ports die Kunden per Brief informiert (so geschehen letzte Woche bei einem Kunden mit offenem Port 8080 f\u00fcr eine alte Zeiterfassungsanwendung).'<\/p><\/blockquote>\n

Erg\u00e4nzung: Es sind wohl weitere Telekom Business-Router von dem Firmware-Bug betroffen, siehe\u00a0Weitere Telekom Business-Router mit Sicherheits-Bug (27.11.2019)<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Gerade wurden ein Datenleck aufgedeckt, bei dem ein Server einer Arztpraxis mit Tausenden an Patientendaten offen im Internet erreichbar war. Mit beteiligt, eine Digitalisierungsbox der Telekom, deren Ports (wegen einer Firmware-Schwachstelle) offen standen. In diesem Zusammenhang erreichte mich die Mail … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[426],"tags":[5535,2038,4328],"class_list":["post-225158","post","type-post","status-publish","format-standard","hentry","category-sicherheit","tag-datenleck","tag-router","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/225158","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=225158"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/225158\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=225158"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=225158"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=225158"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}