Checkliste für Sicherheit im IoT

Das Internet der Dinge steckt voller Sicherheitsgefahren, wie Bruce Schneier in seinem Blog verrät. In diesem Beitrag will ich Gegen-Maßnahmen vorschlagen, die das Internet der Dinge trotzdem sicher machen.

Feststellung 1: Vernetzung bringt mehr Nutzen als Gefahren

So gefährlich das IoT auch ist: Kraftwerk-Fernwartung spart den Monteuren im Havariefall mehrere Stunden an Zeit, die sie sonst benötigen würden, erst einmal zum Kraftwerk zu fahren. Oft stehen die Kraftwerke hunderte Kilometer von den Ingeneurs-Fachfirmen entfernt. Die Verluste durch Ausfall im Havariefall lassen sich also in die Millionen beziffern.

Auch sonst bringt das IoT vielerorts mehr Nutzen als Gefahren: Funktioniert das Gerät, wird es genutzt – funktioniert es nicht mehr (weil gehackt und als Zombie missbraucht) nutzt man es eben nicht mehr.

Feststellung 2: Sichere Systeme sind möglich

Im Gegensatz zur landläufigen Meinung ist es tatsächlich möglich, sichere Systeme zu kreieren. Mann muss dazu aber gut sein. Dieselbe Meinung vertritt auch Bruce Schneier, allerdings hat er eine sehr pessimistische Einstellung, ob die IoT-Hersteller tatsächlich Maßnahmen ergreifen werden. Um dem etwas entgegenzusetzen dieser Artikel.

Feststellung 3: Deutschland ist nicht die USA

Bruce Schneier bemängelt, dass aufgrund von amerikanischen Copyright-Gesetzen Sicherheitsforschern die Hände gebunden sind. Geräte dürfen nicht analysiert werden und solange die Guten die Geräte nicht hacken dürfen, werden es die Bösen eben tun.

Das ist ein wichtiger Punkt, denn Sicherheitsforschung ist eines der Säulen eines künftigen sicheren IoT. Deutsche Sicherheitsforscher haben da weitreichendere Befugnisse als ihre amerikanische Kollegen. Sicherheit im IoT wird sich genau dann durchsetzen, wenn die Sicherheitsforschung publik genug wird, um Hersteller entweder zu Sicherheits-Updates und Viren-Reinigungen zu bewegen oder diese so zu diskreditieren, dass ihre Produkte weggeworfen werden und bestenfalls ein Verkaufsverbot bekommen.

Nichtsdestotrotz schwebt ein deutscher Sicherheitsforscher immer in der Gefahr, anwaltlich zu kontraproduktiven Schweigegeboten abgemahnt zu werden. Auch das muss sich durch neue Gesetze ändern.

Erst mal grundlegend: Keine Systeme, die ohne Firewall nicht sicher wären

Firewalls haben im IoT keinen Platz mehr. Netze müssen erreichbar sein, das ist Grundlage für ihre Nutzbarkeit. Systeme, die nur aufgrund von Abschirmung sicher sind, sind nicht mehr zeitgemäß und auch nicht wirklich sicher. Wer es nicht glaubt, darf diese Gruselgeschichte lesen, die so allerdings eine tatsächliche Bedrohung darstellt.

Wichtig ist allerdings, dass jeder Zugang zum Gerät authentifiziert sein muss. Das heißt in anderen Worten: Es muss über jeden Zugriffsweg sichergestellt sein, dass nur diejenigen auf das Gerät zugreifen dürfen, die es auch dürfen. Das sind bei den Updates der Hersteller und für die Benutzung der Inhaber bzw. Nutzer des Geräts. Alle anderen müssen draußen bleiben. In Zeiten von IPv6 heißt das auch ByeBye Telnet.

Systeme, die nur aufgrund ihrer Abschottung sicher sind, sind nicht sicher.

Maßnahme 1: Werks-Passwörter absichern

Um den Nutzer-Komfort der IoT-Geräte zu erhöhen, werden meist Standard-Passwörter gesetzt. Das bietet aber ein nicht kalkulierbares Sicherheitsrisiko, denn kaum ein Nutzer ändert die Passwörter wie verlangt.

Wichtigste Maßnahme der Hersteller sollte also sein: jedes Gerät bekommt ein eigenes Passwort, das in der Anleitung oder auf dem Gerät abgedruckt sein muss. Das Passwort muss mathematisch unabhängig von der Gerätenummer sein. Letzte Anforderung ist insbesondere wichtig, da sonst das Passwort ebenfalls nichts wert ist. Vodafone hat sich diese Schwäche geleistet – anschließend konnte in jedes WLAN einfach per APP eingebrochen werden.

Maßnahme 2: Updates kryptografisch signieren

Updates für IoT-Geräte können von geschickten Angreifern gefälscht werden und sind somit ein Einfallstor für Schadsoftware. Andererseits benötigen IoT-Geräte Updates, um Sicherheitslücken zu stopfen.

Updates können gerne per HTTP-Protokoll geholt werden. Allerdings muss anschließend die Integrität des geladenen Update-Archives geprüft werden. Das geschieht nach aktuellem Stand der Technik mittels kryptografischer Signaturen. Bashbundle, ein OpenSource-Projekt unserer Firma, erlaubt genau das: Ein paar Dateien, sowie ein Shell-Script werden in ein Archiv gepackt und signiert. Auf dem Ziel-Gerät hinterlegt man einige öffentliche Schlüssel von vertrauenswürdigen Update-Anbietern. Ein eingesteckter USB-Stick oder ein HTTP-Download liefern ein Paket, das anschließend geprüft wird und nach Freigabe entpackt und ausgeführt wird.

Maßnahme 3: Jeden Input validieren

Eine weit subtilere Gefahr geht von den Sicherheitslücken aus, die im Code der Geräte selbst schlummern. Pufferüberläufe sind ein ansehnliches Beispiel, wie aus unachtsamer Programmierung Angreifer plötzlich die Möglichkeit haben, durch einen Absturz des Programms die Kontrolle über den Computer zu übernehmen.

Wir selbst haben schon tausende Zeilen Fremd-Code gegen Schwachpunkte wie SQL Injections und Remote-Code-Exploits abgesichert. Grund für das Vorhandensein der Sicherheitslücken war meist die Ahnungslosigkeit oder Faulheit des Programmierers, um jede Nutzereingabe eine obligatorische Sanitierung bzw. Prüfung zu programmieren.

Programmier-Werkzeuge wie zum Beispiel unser OpenSource-Tool JSON Validator JSONType erleichtern es Programmierern ungemein, den Code zum Validieren der Nutzereingabe automatisch zu generieren.

Das war’s schon

Setzt man die oben genannten Dinge um, gibt es keinen Weg mehr, wie Kriminelle unrechtmäßig in die IoT-Geräte einbrechen können. Was Bruce Schneier hier so hochkocht ist die Unfähigkeit der Hersteller, diese paar Punkte korrekt und fehlerfrei umzusetzen. Daran können wir im Hinblick auf China nicht viel ändern. Doch vielleicht gibt es einige deutsche Hersteller, die diesen Beitrag lesen und die Marke „Made in Germany“ nach den Siemens-Skandalen auch im IoT-Bereich wieder stärken wollen.

#sepafail SEPA-Sammelaufträge mit ChipTAN-Verfahren bei der Sparkasse sind nicht sicher

Eine bequeme Art der Überweisung sind SEPA-Dateien. Eine SEPA-Datei enthält alle Überweisungs-Posten gesammelt.

Bequem, schnell und automatisch

Da die SEPA-Datei maschinenlesbar ist, können beispielsweise Buchhaltungsprogramme Gehaltsüberweisungen gebündelt ausspucken. Ein Mitarbeiter muss diese nur noch im Online-Banking hochladen und schon sind die Gehälter überweisen.

Schritt 1: Datei hochladen
Schritt 1: Datei hochladen

Dem Nutzer werden die Posten noch einmal aufgelistet, um sicherzugehen, dass die Daten korrekt sind.

Schritt 2: Daten überprüfen
Schritt 2: Daten überprüfen

Schließlich generiert man noch die TAN, um die Überweisungen abzunicken.

Schritt 3: TAN mit ChipTAN-Verfahren erzeugen
Schritt 3: TAN mit ChipTAN-Verfahren erzeugen

Ist das Verfahren nun sicher?

Auf den ersten Blick sieht alles super aus: Man lädt die Daten hoch, überprüft sie noch einmal und nickt sie dann ab. Doch der Teufel steckt im Detail.

Doch zuerst ein bisschen Vorgeschichte: Das ChipTAN-Verfahren wurde eingeführt, da Handy-TANs einige grundlegende Probleme haben: Die TANs werden zum einen über das unverschlüsselte GSM-Netz geschickt (Anmerkung: GSM ist zwar verschlüsselt, aber innerhalb von Sekunden knackbar), zum anderen reicht die Kenntnis einer TAN aus, eine beliebige Überweisung zu tätigen.

ChipTAN

ChipTAN sollte das ändern. Mit einem privaten Schlüssel auf der Karte soll mittels eines Nicht-Kompromittierten Gerätes (ChipTAN-Lesegerät) die Eckdaten der Überweisung, Betrag und Kontonummer des Empfängers, eingeben. Durch die Verrechnung der Daten in der TAN soll sichergegangen werden, dass Änderungen zwischendrin erkannt werden und User somit darauf aufmerksam gemacht werden, wenn sie beispielsweise einen Virus im System haben.

Problematisch bei der Sammelüberweisung ist nun die Menge der eingegebenen Daten. Die Sparkasse fragt mich lediglich nach der Summe aller Überweisungen, sowie der Anzahl Posten. Für einen Betrüger ist es aber fast egal, wie viele Posten und welche Summe überwiesen wird. Es sieht sogar plausibler aus, wenn eine gefälschte Überweisung genau denselben Betrag überweist wie das Original. Der Betrüger will die Empfänger-IBANs gegen eigene Konten austauschen. Das Geld muss danach zwar noch gewaschen werden (wäre doof, wenn das Konto auf seinen Namen liefe), aber das ist momentan nicht unser Problem.

Wie sieht nun der Angriff aus?

Dem Angreifer muss es gelingen, die SEPA-Datei so auszutauschen, dass Betrag und Anzahl der Posten gleich bleiben, aber der Betrüger seine eigenen Empfänger-IBANs einträgt. Im oben gezeigten Bild „Schritt 1“ findet bereits der Upload statt. Ist die Datei einmal bei der Bank hochgeladen, ist es für den Betrüger zu spät. Er muss also die Datei vor dem Upload abgreifen und abändern.

Im „Schritt 2“ sieht der Nutzer noch einmal die Buchungen aufgelistet. Da der Betrüger schon die abgeänderten Dateien hat hochladen lassen, muss dem Anwender jetzt die Richtigkeit der Daten weiterhin vorgegaukelt werden. Das geschieht, indem der Betrüger die ausgetauschten Originaldaten jetzt per Plugin im Web-Interface einsetzt. Dem User wird also vorgegaukelt, er würde an die richtigen Personen überweisen.

Im Schritt 3 der Anleitung hat der Betrüger keine Mühe mehr, da Betrag und Anzahl Posten des Sammelauftrags ja gleich bleiben.

Zusammengefasst muss der Betrüger einen Virus entwickeln, der ein Browser-Plugin ins System einschleust, das den Upload abfängt und auswechselt, sowie die angezeigten Kontrolldaten noch einmal durch die alten Daten ersetzt. Den Virus in ein Firmennetzwerk einzubringen dürfte keine große Hürde sein und beispielsweise mit Social Engineering gemacht werden können. Der technisch unversierten BWL-Aushilfskraft wird eine E-Mail untergeschoben, in der beispielsweise eine Mahnung oder eine Rechnung steht. Da sie die Anweisung hat, Rechnungen zu verbuchen, ist es recht wahrscheinlich, dass sie den Anhang öffnen wird.

Wie müsste man das System der Sparkasse anpassen?

Der Knackpunkt bei Sammelüberweisungen ist die Integrität der SEPA-Datei. Anstatt den Betrag und die Anzahl der Posten bei der ChipTAN-Eingabe abzufragen, sollte stattdessen eine Prüfsumme eingegeben werden, die bestätigt, dass die SEPA-Datei nicht verändert wurde. Diese Prüfsumme muss der Nutzer selbst berechnen. Das klingt nicht gerade User-freundlich. Geht man aber davon aus, dass die Anwender von SEPA-Dateien eher Unternehmensberatungen und Steuerbüros sind und die SEPA-Dateien automatisch generiert werden, kann die Software, die die SEPA-Datei generiert, die Prüfsumme gleich mit ausspucken.

Als Empfehlung für ein Prüfsummenverfahren würde ich hier SHA-256 anbringen. Allein durch die Verwendung in Bitcoin und ähnlichen Blockchains sind tausende Goldgräber damit vertraut, zu versuchen, SHA-256 zu knacken. Dass es niemanden gibt, der massenhaft Bitcoin-Blöcke absahnt, beweist, dass SHA-256 extrem sicher ist.

Warum ist der Fail fatal?

Was mich an der Sache stört ist, dass die Sparkasse bei Einzelüberweisungen so sehr acht gibt und Betrag und Kontonummer prüft, selbst bei den kleinsten Beträgen. Wenn es hingegen um Millionenbeträge geht bei Gehaltsüberweisungen, ist die Sicherheit auf einmal nicht mehr gegeben.

Zudem gibt es in vielen Firmen eine katastrophale Sicherheitslage, die Betrüger nur so einlädt, das Netzwerk zu kompromittieren. Überall, wo mehrere Personen als Einfallstor dienen, wird dadurch die Sicherheit geschwächt.

Inwieweit die Sparkasse darauf reagieren wird, weiß ich nicht. Die Sache zuerst der Sparkasse zu melden war für mich von Anfang an keine Option. Am Schalter hätte man mich komisch angeschaut und ein direkter Kontakt in die Sicherheits- und IT-Abteilung war mir zu viel Rechercheaufwand. Zudem gab es in der Vergangenheit zu viele Sicherheitsforscher, die nach ihrer diskreten Meldung entweder ignoriert wurden, mit 25 €-Gutscheinen abgespeist wurden oder gar rechtliche Probleme bekommen haben, weil ihnen die Forderung nach einer Belohnung fürs Finden der Lücke als Erpressung ausgelegt wurde.

Zudem gehe ich davon aus, dass bei der Sparkassen-IT keine Idioten arbeiten. Ich denke eher, dass diese Sicherheitslücken für mehr User-Komfort in Kauf genommen wurden. Die Entscheidung kommt schließlich von Oben und nicht von den Fachexperten. Die Frage ist nur, ab welcher Verlustsumme es sich für die Sparkasse lohnt, in mehr Sicherheit zu investieren. Jedoch könnte man die verfälschten SEPA-Dateien auch den Firmen zuschreiben, womit die Verluste eher bei den Kunden der Sparkasse lägen – also null Handlungsbedarf.

Das Problem sitzt noch tiefer

Angenommen, der Rechner wäre kompromittiert und ich generiere meine SEPA-Datei aus einem Programm, das auf dem kompromittierten Rechner läuft – dann ist doch die komplette Sicherheit der Bank unnütz.

Hier gibt es mehrere Arten, wie die SEPA-Datei entstehen kann. Zum einen kann eine externe Partei, wie z.B. der Steuerberater die SEPA-Datei erstellen und mir die SHA256-Summe auf sicherem Wege zukommen lassen. Es müssten schon beide Parteien infiziert sein und der Virus zusätzlich auf die Software des Steuerberaters spezialisiert sein, um den Angriff durchführen zu können.

Doch selbst, wenn die SHA-256-Summe auf meinem kompromittierten Rechner erstellt wurde, kann man speziell die Wirtschaftlichkeit einer Viren-Entwicklung betrachten: Es gibt 3-4 verbreitete Browser, aber hunderte Buchhaltungsprogramme, sowie tausende Individuallösungen, die SEPA-Dateien erstellen. Wenn die Banken also ihre Pflicht tun würden, wäre schon einmal ein Risikofaktor ausgeschalten.

Weitere Design-Schwächen des ChipTAN-Verfahrens

Es gibt zwar noch einige andere Dinge, die mich am ChipTAN-Verfahren stören, aber ich gehe mal davon aus, dass die Bedrohungslage recht überschaubar ist und dass die Sparkasse für ihre fehlende Sicherheit schön selbst haften wird (um keinen Skandal zu provozieren – rechtlich müsste sie nicht, da sich in vielen Fällen von verseuchten Computern gar nicht nachweisen lässt, ob nun der Nutzer oder der Virus die Aktion getätigt hat).

Einzelüberweisung sind so ein Stein des Anstoßes: Es wird der Betrag und die Kontonummer abgefragt, nicht aber die Bankleitzahl (bzw. der Anfang der IBAN). Überrede ich nun eine Bank, ein Konto zu eröffnen, das dieselbe Kontonummer hat wie ein Zahlungsempfänger meines Opfers, kann ich leicht per Browser-Plugin die Bankleitzahl der Überweisung austauschen und erhalte das Geld selbst. Das Opfer wird zuerst nichts merken, da Kontonummer ja stimmt und der Betrag auch – nur der Empfänger wird sein Geld nicht sehen.

Eine weitere Design-Lücke, die wesentlich tiefer liegt, ist die Schlüsselerzeugung. Ich bekomme meine EC-Karte von der Bank zugeschickt. Der private Schlüssel auf dem Chip wird nicht von mir generiert. Demzufolge wäre bei einer bestätigten Überweisung nachweisbar entweder ich oder meine Bank der Urheber. Eine TAN ist also nicht der eindeutige Beweis, dass eine Überweisung von mir autorisiert wird, da sie die Bank als signierenden Part nicht ausschließen kann. Das wäre erst möglich, wenn ich den Schlüssel selbst generieren dürfte und in den Chip einbrennen darf. Dass das aus Usability-Gründen nicht geht und die Chip-Schreibgeräte ebenfalls kompromittiert sein könnten, lassen wir mal außen vor.

Dieser Artikel soll keine Rüge gegen die Sparkasse allein sein. Ich kann mir vorstellen, dass andere Banken dieselben Fehler machen oder dass die Banken gar nur Standards umsetzen (die sie natürlich selbst mit beeinflusst haben).

Fazit

Ich hoffe, dass ich nie einen Virus haben werde, der sich auf die Verfälschung von SEPA-Dateien spezialisiert. Ansonsten wären die finanziellen Folgen heftig. Ich hoffe, dass, bis die Sparkasse den Fehler behoben hat, Linux noch nicht so verbreitet ist, dass es Drive-By-Viren gibt, die auf meinem System Unheil anrichten können. Sollte es doch dazu kommen, muss ich wohl Sammelüberweisungen sein lassen und alle Posten einzeln einhacken.

Was ist die vielbesagte Blockchain?

Viele reden darüber, doch nur wenige wissen, wie sie funktioniert.

Die Blockchain ist eine Kette von Blöcken

Doch was ist ein Block und was genau ist Verkettung? Doch dazu erst ein Exkurs in die Geschichte der Blockchain: Der Bitcoin.

Eine dezentrale Währung, die auch ohne Zentralbank eine kontrollierte Geldmenge im Umlauf hält?

Genau das war das Ziel, mit dem Bitcoins geschaffen wurden. Es sollte eine Art Geld geschaffen werden, das folgende Eigenschaften besitzt:

  • Es gibt eine definierte Geldmenge im Umlauf. Niemand darf Geld erfinden oder fälschen können.
  • Geld muss von jemandem besessen werden können. Diesem darf das Geld nicht enteignet werden.
  • Wer im Besitz von Geld ist, soll in der Lage sein, dieses einer beliebigen Person überweisen zu können.
  • Es muss eine möglichst faire Ausschüttung des Anfangs-Geldbestands geben.

Bitcoins realisieren das so:

  • Geld besitzt, wer den privaten kryptografischen Schlüssel (vergleichbar mit einem Passwort) zu seinem Konto besitzt.
  • Mit einer Überweisung markiert man eigenes Geld mit dem öffentlichen kryptografischen Schlüssel eines fremden Kontos (vergleichbar mit einem Schnappschloss, zu dem man selbst den Schlüssel nicht hat, sondern nur der Empfänger)
  • Die Anfangs-Geld-Ausschüttung findet in der Anfangsphase statt. Es werden alle 10 Minuten 100 Bitcoin ausgeschüttet. Nach einigen Monaten nur noch 50, nach weiteren Monaten nur noch 25 bis die gesamte Umlaufmenge ca. 17 Mio Bitcoin beträgt.
  • Die Anfangs-Geld-Ausschüttung, sowie die Buchführung über alle Überweisungen (und damit die Nachvollziehbarkeit der Kontostände) werden in Blöcken gespeichert. Die Anfangs-Geld-Ausschüttung bekommt der, der den Block erstellt.
  • Es gibt ein mathematisch schwierige Rätsel, das ein Computer berechnen soll. Wer eine solche Rätsel-Lösung findet, darf einen Block erstellen (und erhält dadurch die Anfangs-Ausschüttung, sowie alle Transaktionsgebühren der Überweisungen, die er in den Block aufnimmt)
  • Auf diese Weise wird garantiert, dass alle 10 Minuten Überweisungen abgewickelt werden und weiteres Geld ausgeschüttet wird. Die Ausschüttung wird statistisch gesehen je nach Rechenleistung der Teilnehmer verteilt.

Was macht Blockchains so einzigartig?

Eine Blockchain ist, wie oben genannt, eine Kette von Blöcken. Ein Block besteht aus einer Nutzlast, wie beispielsweise der Liste von Überweisungen, die bestätigt wurden. Eine Klinik nutzt die Blöcke beispielsweise, um Patientenbefunde zu zementieren. Eine spätere Änderung am Befund ist dadurch für alle nachvollziehbar. Die Verkettung entsteht dann daraus, dass jeder Block jeweils seinen Vorgänger-Block bestätigt. Das funktioniert, indem eine Prüfsumme (auch Hash genannt) vom vorherigen Block erstellt wird. Wird der vorherige Block geändert, würde also der nächste Block auf die Änderung hinweisen. Durch die Verkettung der Blöcke ist die Vergangenheit dadurch umso schwerer änderbar, je mehr Blöcke darauf folgen.

Blockchains machen einen Ereignisverlauf nachvollziehbar

Durch die Verkettung der Blöcke ist es fast unmöglich, die Kette zu manipulieren, wenn bereits Blöcke angehängt wurden. Neue Blöcke werden von den Blockchain-Nutzern nämlich nur akzeptiert, wenn sie die Richtigkeit der kompletten Vergangenheit bestätigen.

Ein Betrüger könnte also die Welt gestalten, wiedie-wiede-wie sie ihm gefällt, er würde damit allerdings allein dastehen. Alle anderen Nutzer der Blockchain haben den Blockverlauf als Beweis, wie es tatsächlich geschehen ist.