Original-URL des Artikels: https://www.golem.de/news/schwachstellen-aufgedeckt-der-leichtfertige-umgang-mit-kritischen-infrastrukturen-1607-122063.html    Veröffentlicht: 15.07.2016 14:01    Kurz-URL: https://glm.io/122063

Schwachstellen aufgedeckt

Der leichtfertige Umgang mit kritischen Infrastrukturen

Wasserwerke lahmlegen, fremde Wohnungen überhitzen oder einen Blackout auslösen: Wer weiß, wo er suchen muss, kann all dies über das Internet tun, wie Recherchen von Golem.de und Internetwache.org ergeben haben. Und viele Betreiber wichtiger Anlagen haben keine Ahnung von der Gefahr.

Feriengäste liegen im Bett, als mitten in der Nacht das Licht angeht - ferngesteuert. Betreiber eines Wasserwerkes stellen auf einmal fest, dass ihre Kontrollinstrumente ihnen falsche Werte anzeigen. Ein Luxusapartment in Israel gerät unter die Kontrolle Fremder. Was nach schlechten Szenen aus einem Hollywood-Film klingt, sind Ergebnisse einer mehrmonatigen Untersuchung zur IT-Sicherheit von Industriesteuerungen.

Die Resultate unserer Recherchen rund zwei Monate nach dem Inkrafttreten des IT-Sicherheitsgesetzes sind erschreckend. Innerhalb von wenigen Wochen gelang es uns, Zugriff auf die Steuerungssysteme von Wasserwerken, Blockheizkraftwerken, Interfaces zur Gebäudeautomatisierung und sonstigen Industrial Control Systems (ICS) zu erlangen. Weltweit waren über 100 Systeme betroffen. Auf die meisten ließ sich ohne besondere Authentifizierung lesend zugreifen. Einige Systeme ermöglichten sogar den Zugang zu Steuerungen, darunter waren deutsche Wasserwerke. So können Angreifer nicht nur wichtige Daten kritischer Systeme auslesen, die Systeme sind auch angreifbar, können unter Umständen manipuliert, lahmgelegt oder sogar beschädigt werden. Und nicht nur die Systeme selbst sind in Gefahr, sondern auch Menschen oder Anlagen in ihrer Umgebung. Die Betreiber waren sich der weitreichenden Gefahr offenbar nicht bewusst.

Die Wasserversorgung Zehntausender unterbrechen

Von Wasserwerken sind Zehntausende Menschen abhängig. Umso überraschender, dass wir die Human-Machine-Interfaces (HMI) von vier Wasserwerken ausfindig machen konnten. Solche Interfaces dienen normalerweise der Überwachung und Steuerung von Maschinen und Anlagen vor Ort und sind Teil eines sogenannten Scada-Systems (Supervisory Control and Data Acquisition). Aus dem Internet sollten diese kritischen Systeme in keinem Fall zu erreichen sein. Wir fanden sie allerdings dort mit vergleichsweise einfachen Mitteln und erlangten so Zugriff auf ihre Administrationsoberflächen.

Drei dieser HMIs ließen sich deutschen Wasserwerken zuordnen. Zwei befinden sich in Bayern, eines davon in Neufahrn bei Freising, in unmittelbarer Nähe von München. Es versorgt täglich circa 80.000 Menschen mit Trinkwasser. Das zweite liegt im Landkreis Garmisch-Partenkirchen bei Uffingen am Staffelsee. Das dritte deutsche Wasserwerk befindet sich im Süden des Bundeslandes Niedersachsen in der Nähe der Kleinstadt Dassel.

Daten auslesen und Soll-Werte verändern, Maschinen manipulieren

Durch Zugriffe wie unseren lassen sich umfangreich Daten aus Sensoren auslesen, beispielsweise der Wasserverbrauch einer Stadt oder sonstige Werte einer Anlage. Diese können beispielsweise für Auslandsgeheimdienste oder Terroristen von Interesse sein. Zudem konnten im Einzelfall Soll-Werte verändert oder Statistiken des Wasserwerkes manipuliert werden. Mindestens in einem dieser Wasserwerke war auch ein Zugriff auf die Pumpanlagen möglich, speziell auf die Umdrehungen pro Minute. Im schlimmsten Fall ließe sich so die Wasserversorgung von ganzen Städten und Gemeinden unterbrechen.

Solche Daten können in ICS mit vollautomatischen Steuerungen zu folgenschweren Steuerungskommandos führen, die direkte Auswirkungen auf den eigentlichen Produktions- bzw. Steuerungsprozess haben. Im Rahmen unserer Tests wurde nur die theoretische Machbarkeit dieser Operationen aufgezeigt, es wurde nicht dauerhaft manipuliert. Die in diesem Artikel vorgestellten Applikationen sind allesamt nicht mehr über das Internet erreichbar und wurden durch die Betreiber gesichert.

Wie leichtfertig viele von ihnen zuvor mit der Sicherheit ihrer Anlagen umgingen, zeigt ein näherer Blick auf die Zugriffsmöglichkeiten bei den Wasserwerken.

Systeme und Menschen in Gefahr

Bei fast allen von uns gefundenen Wasserwerken war es möglich, Störungsmeldungen ohne besondere Authentifizierung zu quittieren, also mögliche Alarme auszuschalten. Einer der Betreiber schien es sich zudem besonders bequem zu machen, indem er mögliche Meldungen durch eine Zeitsteuerung automatisch morgendlich löschen ließ.

Die Steuerung des vierten gefundenen Wasserwerks ließ sich einer Gemeinde in Nord-Italien zuordnen. In Italien (Rom) fand sich zudem ein Steuerungssystem für ein sogenanntes Fernheizwerk. Auch deutsche und österreichische Heiz-, Blockheizkraftwerke und sogar Biogasanlagen waren im Internet zugänglich.

Anfällig für DDoS-Angriffe

Diese Anlagen ließen meist nur den Lesezugriff zu oder benötigten eine Authentifizierung. Doch auch über den bloßen Zugriff können die Dienste bereits durch DoS- oder DDoS-Attacken überfordert werden, weshalb ICS immer abgeschirmt vom Internet betrieben werden sollten.

Im Darknet lassen sich sogenannte Botnetze anmieten. Sie sind ein Verbund ferngesteuerter Rechner, mit denen millionenfache Anfragen an Webserver gestellt werden können. Da HMIs von Scada-Systemen meist nur für den lokalen Betrieb und wenige Anfragen eingesetzt werden, ist davon auszugehen, dass eine Ressourcenauslastung der Server und damit eine Nicht-Erreichbarkeit des Dienstes mit diesem Mittel in kurzer Zeit möglich wäre.

Zudem war die verwendete Steuerungssoftware in früheren Versionen bereits anfällig für DoS-Angriffe. Wenn Betreiber also nicht regelmäßig die Version prüfen und updaten - und das war bei einigen Systemen der Fall, die bei der Untersuchung gefunden wurden -, wäre ein Angriff möglich, mit im Web frei verfügbaren Exploits. Ein solches Vorgehen hätte bei Industrieanlagen verheerende Folgen, denn Anlagen könnten entweder komplett funktionsunfähig, nicht mehr steuerbar oder darüber hinaus massiv beschädigt werden.

Gefahr für Menschen

"Die beschriebenen Fälle bergen erhebliche Gefahren, das darf so nicht passieren", sagte der Präsident des Bundesamts für Sicherheit in der Informationstechnik (BSI) Arne Schönbohm dem Spiegel. "Das ist, als wenn Sie die Tür zu Ihrem Haus sperrangelweit offen stehen lassen". Selbst wenn es bei einigen Betreibern nach dieser ersten Eintrittschwelle möglicherweise weitere Türen gegeben habe, handle es sich um "gefährlichen Leichtsinn". Bereits 2014 beschrieb das BSI in seinem Bericht zur IT-Sicherheitslage in Deutschland solche Gefahrenlagen. Damals gelang es unbekannten Angreifern, die Steuerung eines Hochofens in einem deutschen Stahlwerk in einen nicht mehr definierten Zustand zu bringen, so dass dieser notabgeschaltet werden musste.

In solchen Fällen und bei unseren aktuellen Funden ist nicht nur die bloße Sicherheit der vorhandenen Systeme und Anlagen gefährdet (Security), sondern auch die Sicherheit für Menschen oder Anlagen in der Umgebung (Safety). Was für Gefahren dabei entstehen und wie weitreichend der Eingriff digitaler Systeme in die reale Welt ist, das zeigt anschaulich die bis vor einige Wochen noch ungewollt im öffentlichen Internet erreichbare Gebäudesteuerung eines Smart Buildings in Israel.

Bei dem Tower handelt es sich um Millionenprojekt in Israel, in dem auch exklusive Luxuswohnungen zu mieten sind. Der Zugriff auf das System zur Gebäudeautomatisierung war unzureichend gesichert - vermutlich war die Firewall falsch konfiguriert - und innerhalb der Applikation gab es logische Fehler. So war der Zugriff auf Funktionen ohne Authentifizierung möglich, was es jedem Internetnutzer ermöglichte, sich innerhalb der Verwaltungssoftware einen Account anzulegen und diesem Administrationsrechte zu verleihen.

Totale Kontrolle über einen Tower voller Luxuswohnungen

Anschließend hatte ein Angreifer vollumfänglichen Zugriff auf die Funktionen der Gebäudeautomatisierung des Towers. Dieser Zugriff beinhaltet die Steuerung der Beleuchtung, die Bedienung von Frisch- und Abwasserpumpen, die Kontrolle der Klimaanlagen im gesamten Gebäude, den Zugriff auf den Sicherungskasten und sogar auf die Rauchmelder oder Temperaturmessgeräte der Poolanlagen. Kurzum: Es liegt eine totale Kontrolle über sämtliche smarte Bestandteile des Gebäudes vor. Die Bewohner wären somit einem bösartigen Angreifer schutzlos ausgeliefert.

Der könnte beispielsweise mitten in der Nacht einen Blackout in die Wege leiten und hat dafür gleich zwei Möglichkeiten. Zum einen, da sich die Außenbeleuchtung des Towers an den Werten zum Sonnenaufgang und Sonnenuntergang orientieren und sich über das Webinterface einstellen lassen. Zum anderen, da eine Kontrolle über den Stromkasten möglich ist und somit Sicherungen per Mausklick ausgeschaltet werden könnten.

Mit Letzterem könnte man möglicherweise auch Fahrstühle oder Alarmanlagen deaktivieren. Zwar gibt es im Gebäude eine unterbrechungsfreie Stromversorgung (USV), allerdings ist auch der Zugriff auf diese über die erwähnte Applikation möglich. Über die Kontrolle der Klimaanlagen, also über Kühlung oder Hitze, ließen sich darüber hinaus weitere Angriffe auf die Bewohner des Gebäudes durchführen.

Durch die Beobachtung der Logdateien konnten wir feststellen, dass sich diese Applikation tatsächlich in aktiver Benutzung befindet. So ließ sich beispielsweise exakt erkennen, zu welcher Zeit ein Fehlalarm eines Rauchmelders vorlag und welcher Operator diese Störungsmeldung quittiert und vermutlich behoben hatte.

Ahnungslose Hausbesitzer

Neben dieser Applikation gab es einige weitere Fälle aus dem Bereich der Gebäudeautomatisierung. Diese gehörten zu Hotels, Smart Buildings und auch Smart Homes. Bei Letzteren gab es meist keinerlei Authentifizierung. Es ließen sich also Licht, Heizung oder Jalousien direkt per Webapplikation fernsteuern oder auch einfach nur beobachten, was in den jeweiligen Gebäuden vor sich ging.

Durch etwas Google-Recherche unter Verwendung der innerhalb der Applikation vorhandenen Informationen gelang es uns, ein Hotel und eines der Smart Homes exakt zuzuordnen. Bei dem Smart Home handelte sich um eine Ferienwohnung in Österreich, die für über 100 Euro pro Nacht zur Verfügung stand und auf einem Portal für Ferienwohnungen mit fünf Sternen gelistet wurde. Sofern ein Angreifer sich an der Steuerung zu schaffen gemacht hätte - es war Zugriff auf die Lichtsteuerung und Heizung möglich -, wäre das für die Gäste sicherlich ein unvergesslicher Urlaub geworden.

Es ist davon auszugehen, dass dem Besitzer des Hauses diese Gefahrenlage gar nicht bewusst war. Hausbesitzer nutzen vermutlich entweder die Applikation lokal, kennen den Fernzugriff gar nicht oder halten den Remote-Zugriff schlicht für bequem, ohne sich über Risiken durch Manipulation Gedanken zu machen.

Wie die angreifbaren Systeme gefunden wurden

Der Anfang der Untersuchungen liegt im Herbst 2015. Wir beschäftigten uns mit Industrieroutern, die unter anderem innerhalb von sogenannten ICS (Industrial Control Systems) eingesetzt werden. Im Oktober 2015 erregte eine Webapplikation zur Verwaltung der Parkdecks des Züricher Prime Towers unsere Aufmerksamkeit. Wir stellten daraufhin einige Nachforschungen an und entdeckten, dass sich innerhalb des HTTP-Headers ein gewisses Muster erkennen ließ. Aus Sicherheitsgründen und zur Abwendung von Nachahmern wird dieses hier nicht näher erläutert.

Anschließend programmierten wir ein Python-Script und nutzten das Tool zmap, um dieses Muster an beliebigen öffentlichen IP-Adressen zu testen. Dadurch gelang uns im April dieses Jahres ein erster erstaunlicher Fund, bei dem wir unseren Augen kaum trauten: Wir hatten die Administrationsoberfläche eines deutschen Wasserwerkes auf unserem Bildschirm. Diesen Fund meldeten wir an das CERT-Bund, das zum Bundesamt für Sicherheit in der Informationstechnik (BSI) gehört. Es erklärte, dass "das BSI keine Notwendigkeit [sehe], diese [Applikation] exponiert und direkt im Internet erreichbar zu betreiben".

Kritische Systeme sind betroffen

Innerhalb von 48 Stunden informierte das BSI den Betreiber und veranlasste, dass die Applikation nicht mehr aus dem öffentlichen Internet zu erreichen war. Ab diesem Zeitpunkt war uns klar, dass unsere Funde äußerst kritische Systeme betrafen, die keine Honeypots waren, also keine Lockvorrichtungen, um das Verhalten von Angreifern zu studieren. Wir hielten es für möglich, dass wir noch deutlich mehr Systeme aufspüren könnten - womit wir recht behielten.

Wir beschäftigten uns noch tiefergehender mit der genutzten Software und der Methodik zum Auffinden von weiteren Systemen. Wir schrieben ein Plugin für das Tool nmap und nutzten bestehende Scans des Projektes scans.io, wodurch sich die Suche nach Anlagen erneut erleichtern und beschleunigen ließ. Mit Hilfe der Datensätze konnte somit ein IPv4-Adressbereich von circa 4 Milliarden IPv4-Adressen des Internets auf die genannten Auffälligkeiten untersucht werden. Am Ende der Untersuchungen stand eine Liste von über 100 Systemen zur Verfügung, darunter auch die bereits angeführten Anlagen.

Schwierige Kontaktaufnahme mit den Betreibern

Nach dem Auffinden der Sicherheitsrisiken entpuppte es sich als Herausforderung, die Betreiber der Anlagen ausfindig zu machen und die Informationen an den richtigen Ansprechpartner zu übermitteln. Um zu verhindern, dass Dritte den Zugriff auf entsprechende Systeme erlangten, wandten wir uns zunächst an den Hersteller der Software. Dieser war allerdings nur in geringem Maße bereit, entsprechende Informationen an seine Kunden weiterzuleiten, und sah den eigentlichen Fehler, die Erreichbarkeit der Systeme, im Verantwortungsbereich der Kunden.

Später versprach der Hersteller allerdings schriftlich, "dass wenn es Handlungsbedarf gibt, [sie] reagieren werden". Ob es wirklich zu Handlungen kam, ist nicht bekannt, da der Hersteller später nicht mehr auf unsere Anfragen reagierte.

Da es teils ohne besonderen Aufwand möglich war, in Produktionsprozesse der gefundenen Systeme einzugreifen, sahen wir die Notwendigkeit, auf CERTs (Computer Emergency Response Teams) zurückgreifen oder die Betreiber direkt zu kontaktieren, um zu erreichen, dass die Systeme überhaupt gesichert würden. Weltweit wurden mehr als zehn CERTs und einige Unternehmen informiert.

Betreiber reagieren sehr verschieden

Die Reaktionen waren dabei durchaus verschieden. Einige Betreiber meldeten sich gar nicht, nahmen allerdings die Steuerungen zeitnah offline. Andere bedankten sich kurz, sahen allerdings keine besondere Gefahr oder sprachen von geringer Relevanz. Wieder andere, etwa der Geschäftsführer eines deutschen Wasserwerkes, sprachen davon, dass es sich bei dem betroffenen System um Prozessleitrechner handle, eine Art Herzstück von Scada-Systemen, und deshalb durchaus eine Problematik daraus erwachsen würde.

Die meistens CERTs und Betreiber ließen keine Übermittlung mittels PGP-verschlüsselter E-Mail zu, andere ignorierten Hinweise zunächst oder meldeten sich, trotz Behebung der Gefahr, nicht zurück.

Weitere Sicherheitslücken in der Steuerungssoftware

Im Rahmen unserer Untersuchung entdeckten wir einige Unregelmäßigkeiten, die sich später als Sicherheitslücken innerhalb der Software herausstellten. Diese sind dem Hersteller der Software mittlerweile seit circa drei Monaten bekannt. Der Hersteller hat sich, trotz mehrfacher Anfrage, nicht zu den Lücken geäußert, lediglich erneut erwähnt, dass er handeln werde, sofern sich die Notwendigkeit ergebe. Worin der Anstoß zum Handeln noch bestehen könnte, ist unklar, denn die Sicherheitslücken sind durchaus schwerwiegend.

Eine der gefundenen Lücken ist Cross-Site-Scripting (XSS). Es ist also möglich, die Darstellung der Industriesteuerung innerhalb eines Webbrowsers beliebig zu modifizieren, indem durch Dritte und ohne Authentifizierung Scripts in die Webapplikation eingebunden werden. Dieses Angriffsszenario betrifft nicht nur über das Internet erreichbare, sondern auch im lokalen Netzwerk betriebene Systeme.

Ein Effekt wie bei Stuxnet

Mit diesem Angriffsvektor ließe sich ein ähnlicher Effekt erzielen wie mit dem auf Industrieanlagen spezialisierten Computerwurm Stuxnet: Die Human-Machine-Interfaces zeigen andere Werte an, als sie tatsächlich vorliegen - eine sogenannte Manipulation of View. Dadurch würden Fachkräfte, die diese Anlagen bedienen, möglicherweise falsche Konfigurationen vornehmen und könnten damit den physischen Anlagen, etwa Pumpen, erheblichen Schaden zufügen.

Wir fanden eine weitere Sicherheitslücke innerhalb der Software, eine sogenannte HTTP Header Injection. Mittels dieser Sicherheitslücke kann man Webapplikationen etwa dazu veranlassen, einen Download zu starten. Das Vorgehen wäre also dazu geeignet, gezielte Phishing-Angriffe gegen Mitarbeiter vorzunehmen, um letztlich sogar die gleichen Rechte wie der Operator der Anlage zu erhalten und die betroffene Anlage zu steuern.

Weiteres Problem: Lizenzmodell

Auch lizenzrechtliche Probleme können Angreifer verursachen. Das Lizenzmodell des Herstellers nutzt aktuell verbundene Messgeräte zur Bestimmung der Lizenzkosten basierend auf den Messwerten der derzeit abgerufenen Sensoren. Ist der Zugriff von außen möglich, so lassen sich die benötigten Lizenzen bis zu dem maximalen Lizenzwert des jeweiligen Lizenzpakets steigern, da sich diese nach geöffneten Browser-Fenstern und abgerufenen Datensätzen berechnen. Das Lizenzmodell beginnt mit der Stufe "micro", die dann maximal 50 geöffnete Datenpunkte beinhaltet. Damit ließen sich entweder ein Webbrowser mit 50 geöffneten Datenpunkten oder zwei Webbrowser mit jeweils 25 geöffneten Datenpunkten öffnen.

Wenn ein Angreifer einem Unternehmen schaden möchte, dessen Software im öffentlichen Internet abrufbar ist und das dazu ein kleines Lizenzpaket gewählt hat, könnte er einen Webbrowser aufrufen und die freien Datenpunkte bis zum Maximum allokieren. Die Lizenzen sind begrenzt und weiten sich nicht mit aus. Im schlimmsten Fall ließen sich also intern keine Datensätze mehr aufrufen, weil die notwendigen Lizenzen durch externe Abrufe blockiert würden.

Das Ausschöpfen des Lizenzpools würde nach Aussage des Herstellers allerdings nicht bedeuten, dass für den internen Betrieb keine ausreichenden Lizenzen mehr zur Verfügung stünden - da es "ab einer gewissen Lizenzgröße immer einen fixen, unlimitierten Arbeitsplatz" gebe. Diese genannte Verfügbarkeit der freien Lizenzen gilt, wie wir anhand von Broschüren des Produktes herausgefunden haben, allerdings nur für größere Lizenzmodelle (mehr als 150 Datenpunkte), nicht für die Lizenzmodelle "micro" (50 Datenpunkte) und "small" (150 Datenpunkte). Bei diesen Lizenzmodellen wäre ein Aufbrauchen oder Blockieren der Lizenzen durch externe Angreifer nach unserer Kenntnis also durchaus schädlich.

Wer Sicherheitslücken findet, hat Probleme

Die Übermittlung der Sicherheitslücken an den Hersteller der Software war schwieriger als angenommen. Obwohl direkter Kontakt bestand und versprochen wurde, die Sicherheitslücken in einem angemessenen Zeitraum zu validieren, ließ das Unternehmen trotz mehrfacher Nachfrage bis heute nicht von sich hören.

Im Rahmen des Projektes Internetwache.org haben wir bereits mehrfach diese Erfahrung machen müssen. Das liegt offensichtlich schlichtweg dran, dass viele Unternehmen keine klaren Prozesse für den Umgang mit übermittelten Schwachstellen haben oder sich vor schlechter PR fürchten. Tatsächlich schlagen allerdings die meisten CERTs und beispielsweise auch das BSI vor, nicht nach dem Konzept des Security by Obscurity vorzugehen.

Sie fordern Hersteller auf, stattdessen nach dem Prinzip des Coordinated Disclosure zu handeln (siehe dazu ein Paper mit dem Titel "Handhabung von Schwachstellen", PDF). Das bedeutet, dass Sicherheitsforscher mit dem Hersteller einer Software gemeinsam versuchen sollen, die Sicherheitslücken zu schließen und die Informationen nicht einseitig zu publizieren.

Einen Angriff beweisen, ohne anzugreifen

Bei der Untersuchung von Sicherheitslücken in ICS gibt es neben der Übermittlung der Lücken an den Hersteller allerdings noch einige weitere Problematiken. Wie kann man die Sicherheitslücken beweisen, ohne den Hack bis zum Ende durchzuführen? Wir konnten ja nicht alle Schalter, die wir fanden, einfach betätigen oder innerhalb von Live-Systemen Proof-of-Concepts von Sicherheitslücken erstellen, die möglicherweise massiv in Produktions- oder Steuerungsprozesse eingegriffen hätten.

Das macht das Testen von Sicherheitslücken, aber auch die Kommunikation mit Behörden und Betreibern zusätzlich kompliziert, beispielsweise wenn diese gar keine konkreten Folgen entdecken können. Zudem stellen sich auch ethische Fragen, etwa inwieweit wir in einem vernetzten Haus Systeme manipulieren dürfen, wenn wir nicht wissen, ob sich gerade Personen darin aufhalten.

Im Rahmen unserer Untersuchungen haben wir deshalb auf Manipulationen verzichtet, bei denen wir wussten, dass sich die Auswirkungen sich nicht bloß auf die informationstechnischen Systeme beschränkten. Außerdem haben wir nach Auffinden eines Systems direkten Kontakt mit offiziellen Stellen wie dem BSI oder CERTs gesucht. Dieses Vorgehen legen wir anderen Sicherheitsforschern im Sinne einer Verantwortlichkeit ebenfalls nahe.

Massive Fehlkonfigurationen

Bei den Untersuchungen konnten wir feststellen, dass die meisten gefundenen Anlagen massiv fehlerhaft konfiguriert waren. Oftmals waren die Firewalls schlichtweg schlecht oder falsch eingestellt, so dass unter Ansprache bestimmter Ports Zugriff auf Applikationen möglich wurde. Darüber hinaus war eine transportverschlüsselte Verbindung mittels SSL/TLS (HTTPs) in den meisten Fällen (mehr als 80 Prozent) nicht eingerichtet. Selbst wenn die Erreichbarkeit des Systems über das Internet also vorgesehen wäre, könnten Angreifer im gleichen Netz mittels Sniffing den Netzwerkverkehr belauschen und diese Informationen nutzen, um Kontrolle über die Steuerungen zu übernehmen.

Es ist überraschend genug, dass solche Systeme sich überhaupt im Internet finden lassen, denn eigentlich sollten diese abgeschirmt betrieben werden. Schließlich handelte es sich mitunter um öffentliche und teilweise kritische Infrastrukturen, also besonders schützenswerte IT-Systeme.

Die Hersteller sollten handeln

Es ist zudem fraglich, ob der Hersteller gegenüber den Kunden eine gewisse Informationspflicht zu erfüllen hat, wie die Software bzw. Anlage sicher zu betreiben ist. In jedem Fall zeigt sich, dass mit den vorliegenden Informationen viele Betreiber oder sogar Reseller auf die zusätzliche Sicherung der Systeme verzichten. Vermutlich fehlt ein Bewusstsein für Sicherheit, woraus sich durchaus ein Handlungsbedarf für den Hersteller ableiten lässt. Im April 2016 teilte der Hersteller der von uns untersuchten Systeme mit, dass ein Informationsdokument zu diesem Thema zurzeit in Bearbeitung sei und Mitte Mai zur Verfügung stehen werde. Auf erneute Anfrage Anfang Juni 2016 reagierte er nicht.

Auch bei vielen Systemen für das Internet of Things (IoT) zeigt sich, dass sich diese zwar sicher konfigurieren lassen, in der Standardeinstellung aber häufig ungesichert ausgeliefert werden, wie etwa das Zigbee-Türschloss. Bei der von uns untersuchten Software wird beispielsweise ein automatisches Port Binding an allen verfügbaren Netzwerkanschlüssen vorgenommen. Das bedeutet, sobald einer dieser Anschlüsse direkt in das Internet führt, dass die Applikation auch darüber abrufbar ist.

Was getan werden muss

Es gehört gar nicht so viel dazu, seine Systeme vor Angriffen wie den von uns beschriebenen zu schützen. Der wichtigste Rat: Betreiber technischer Infrastrukturen sollten darauf achten, dass die Systeme grundsätzlich nicht aus dem Internet zu erreichen sind und auch kaufmännische Netze komplett von diesen Anlagen getrennt betrieben werden. Eine solche Trennung lässt sich durch demilitarisierte Zonen (DMZ) und korrekt konfigurierte Firewalls erreichen.

Muss ein System unbedingt aus dem Internet erreichbar sein, muss es ausreichend abgesichert sein. Das Betriebssystem muss widerstandsfähig gegen Angriffe sein (Least-Privilege-Ansatz), und es sollten nur die notwendigen Dienste erreichbar sein.

Des Weiteren sollte die vorliegende Software auf einem möglichst aktuellen Stand sein und ausschließlich von Funktionsnutzern bedient werden. Mechanismen zur Authentifizierung sollten aktiv genutzt werden. Zudem ist der Einsatz von sicherer Transportverschlüsselung mit modernen Verschlüsselungsmethoden anzustreben (auch im LAN-Betrieb).

Neben diesen Tipps für technische Netze sollte auch die generelle "Best Practice" aus dem Bereich IT-Sicherheit berücksichtigt werden, wie sie beispielsweise im "ICS Security Kompendium" (PDF) des BSI zu finden sind. Dazu gehören etwa eine vernünftige Organisation der IT-Sicherheit und die Etablierung von Sicherheitsstandards. Unserer Untersuchung zeigt, wie wichtig solche Maßnahmen sind.

Auch die Hersteller haben Verantwortung

Die Ergebnisse zeigen anschaulich, wie verwundbar kritische Infrastrukturen in Deutschland und Europa tatsächlich sein können. Es ist wenig überraschend, dass die zunehmende Vernetzung und der Eingriff digitaler Systeme in die reale Welt neue Gefahren entstehen lassen. Umso wichtiger ist ein breiteres Bewusstsein zu dieser Problematik, um Bedrohungen entgegenzuwirken. Auch die Hersteller von vernetzten Geräten und Software sind in der Pflicht dafür zu sorgen, ihre Produkte nicht mit unsicheren Standardeinstellungen auszuliefern und ihre Nutzer auf mögliche Sicherheitsgefahren hinzuweisen.

Ohne neue Konzepte wie etwa den Ansatz Security for Safety, ohne Sensibilisierung von Betreibern und Nutzern und solange Hersteller ihre Produkte unzureichend testen, werden auch in Zukunft wichtige Einrichtungen und private Smart Homes diesem Risiko ausgesetzt sein.

Internetwache.org wurde 2012 von Sebastian Neef und Tim Philipp Schäfers gegründet und ist ein Projekt, das sich mit der Sicherheit von Webapplikationen und IT-Systemen beschäftigt. Im Rahmen verschiedener Untersuchungen konnten bereits gravierende Sicherheitslücken behoben und verantwortlich offengelegt werden.  (sne)


Verwandte Artikel:
Energieversorgung: Windparks sind schlechter gesichert als E-Mail-Konten   
(11.09.2017, https://glm.io/129868 )
Security: Malware mit legitimen Zertifikaten weit verbreitet   
(07.11.2017, https://glm.io/130997 )
US-Armee: Trump ordnet Denial-of-Service-Angriffe gegen Nordkorea an   
(02.10.2017, https://glm.io/130392 )
Spionage: FBI legt US-Unternehmen Kaspersky-Verzicht nahe   
(21.08.2017, https://glm.io/129593 )
Dallas: Sirenenhack um Mitternacht   
(09.04.2017, https://glm.io/127218 )

© 1997–2019 Golem.de, https://www.golem.de/