Bundeshack: Outlook kann nicht das einzige Problem sein – I

Mittwoch früh erhielt ich eine Nachricht von einer guten Bekannten; der Mailinhalt bezog sich auf den SZ-Artikel
http://www.sueddeutsche.de/digital/exklusiv-so-schleusten-die-hacker-daten-aus-dem-auswaertigen-amt-1.3894534
zum Hacker-Angriff auf das IVBB. Offenbar wird dieser Angriff jetzt als "Bundeshack" bezeichnet - und beschäftigt wohl einige Sicherheitsexperten in der Republik. Meine Bekannte schrieb mir, ich hätte mit meinen regelmäßig kritischen Anmerkungen zur Sicherheit heutiger IT-Infrastrukturen und im Besonderen zu MS-Produkten - wie Outlook - wohl mal wieder Recht gehabt. Das stimmt in diesem Fall aber nicht so ganz, denn tatsächlich sind mit der Sicherheit des IVBB Fachleute befasst, die die Gefahrenlage und auch die eingesetzten SW-Produkte in und auswendig kennen. Und leider verführt der SZ-Artikel dazu, das Versagen primär bei Outlook zu sehen. Das ist aber zu kurz gedacht; die im IVBB aufgetretenen Probleme müssen - wenn man mal glaubt, was die Presse kolportiert - aus meiner Sicht noch tieferliegende Ursachen haben. Was mich als IT-affinen Bürger dann eher beunruhigt ...

Neutraler und sachlicher im Ton als der SZ-Beitrag ist der kommentierende Artikel bei Heise (s. https://www.heise.de/security/meldung/Bundeshack-Daten-sollen-ueber-Outlook-ausgeleitet-worden-sein-3987759.html?xing_share=news). Dort wird zu Recht festgestellt, dass die Informationen der SZ mehr Fragen aufwerfen, als sie beantworten.

Ich fasse nachfolgend und in einem weiteren Artikel ein paar eigene Gedanken zum Thema "Bundeshack" zusammen. Ich hoffe, das hilft, eben jene Fragen besser zu erkennen, die sich nach dem SZ-Artikel aufdrängen. Meine Argumente sind dabei weitgehend unabhängig von der Frage "MS oder nicht" - und deshalb hoffentlich auch für Linux-Freunde interessant. Kommentare könnt ihr gerne per Mail an mich schicken.

Verschlüsselte Kommunikationsverbindungen ins Internet - und ihre zwei Seiten

Zunächst wollen wir die Grund-Information des SZ-Artikels - nämlich, dass die Hacker Mails (ggf. über Manipulationen von Outlook) zur Kommunikation mit einer Schad-Software und zum Transfer von geheimen Informationen nach außen genutzt haben - genauer einordnen. Als Voraussetzung ist dazu, für den einen oder anderen vielleicht überraschenderweise, ein Blick auf Datenverschlüsselung erforderlich.

Ich gehe mal davon aus, dass der Leser mit mir einig ist, dass ein essentielles Problem von Angriffen auf Behördennetze ein nachfolgender unkontrollierter Abfluss von Daten an Unbefugte ist. (Das ist natürlich nur ein Bedrohungsaspekt von Hacker-Angriffen; andere blende ich hier aber mal aus). Der illegale Zugriff auf Daten betrifft u.a. geheime Informationen der Exekutive sowie der Legislative, die z.Z. auch im Behördennetz hängt, aber ggf. auch Daten der Judikative. In keinem Fall kann man wollen, dass Hackern ein unbefugter Zugriff auf geheimzuhaltende Daten von Behörden (wie etwa dem Auswärtigen Amt) gelingt und diese nach außen transferiert werden. Wie erfolgt denn eigentlich ein unbemerkter Daten-Transfer von einem gehackten Gerät (PC, Notebook, Smartphone, ...) und aus einem Firmen/Behörden-Netzwerk nach außen an irgendwelche Empfänger im Internet? Wieso ist das überhaupt möglich?

Antwort: U.a. wegen zu großen Freiräumen für elektronische Kommunikation am Arbeitsplatz und ausgerechnet auch noch durch ein wichtiges IT-Sicherheits-Element - nämlich Verschlüsselung. Wie das?

Als ich vor Jahren mal an einem Projekt in einer öffentlichen Institution arbeitete, hatte ich eine erbitterte "Diskussion" mit einer hoch positionierten - und politisch gut verdrahteten - Führungskraft zum Thema HTTPS. Es gab im Zuge der Auseinandersetzung sogar eine schriftliche Beschwerde: Ich könne doch wohl nicht am Vormittag HTTPS-Verbindungen fordern und am Nachmittag HTTPS in einem anderen Kontext als problematisch darstellen. Tja, ... kann ich doch ... Es ging dabei nämlich um zwei ganz verschiedene Dinge: Am Vormittag wurde HTTPS als (halbwegs) sicheres Verbindungsprotokoll diskutiert, das es Kunden/Bürgern ermöglichen sollte, über das Internet auf einen künftig zu betreibenden Web-Service der Institution zuzugreifen. Am Nachmittag aber waren verschlüsselte Web-Verbindungen von den Arbeitsplatz-PCs der Behörden-Angestellten aus zu Web-Mail-Diensten privater Anbieter im Internet das Thema. Letzteres war erlaubt ...

Mancher sicherheitsbewusster Leser wird schon jetzt den Kopf schütteln ... Ich hatte damals (am Nachmittag) diese "Policy" als ideale Möglichkeit für korrupte, unzufriedene oder schlicht böswillige Mitarbeiter charakterisiert, unkontrollierbar und auch im Nachhinein nur äußerst schwer nachweisbar interne, geheimzuhaltende Daten nach außen abfließen zu lassen.

Meine Kritik stieß damals leider auf völliges Unverständnis. Man müsse seinen Mitarbeitern/innen doch wohl vertrauen können ... Nun ja, ich sehe das von Haus aus anders. Zudem sind bei Sicherheitsthemen nicht nur die Mitarbeitermotivation sondern auch Gefahrenpotentiale zu berücksichtigen, die durch das unbedarfte Handeln von Mitarbeitern im Kontakt mit dem Internet ungewollt auftreten können (s.u.). Unabhängig davon: Der Versuch, einem Politiker den Unterschied

  • zwischen den Gefahrenpotentialen ausgehender verschlüsselter Verbindungen vom Arbeitsplatz-PC eines Angestellten (oder dortiger Programme) ins Internet einerseits
  • und den Gefahren bei der Behandlung von Daten eingehender verschlüsselter Verbindungen zu vom Betreiber kontrollierten Webservern in einer gesicherten Zone andererseits

zu vermitteln, erwies sich im Nachgang jedenfalls als unerwartet, ja geradezu verblüffend schwierig...

Den Lesern dieses Linux-Blogs ist dagegen natürlich klar, dass Verschlüsselung ab einem Endgerät (PC, Notebook, ...) und aus einem Verwaltungsnetz heraus zu externen Servern ein echtes Problem darstellt. Grund: Niemand kann dann mehr kontrollieren, was über eine solche Verbindung an ggf. unbefugte Empfänger im Internet übertragen wird. Zumindest nicht ohne Zusatzmaßnahmen. Man erkennt bei etwas Nachdenken unschwer, dass Sicherheit durch Verschlüsselung immer eine Frage der Autorität über die verschlüsselten Daten ist und zum zweischneidigen Schwert werden kann:

Als Privatperson sollte ich unzweifelhaft der Herr meiner Daten sein - und z.B. auf einer Verschlüsselung in der Kommunikation mit Behörden bestehen. Als Behörde habe ich stellvertretend die Autorität über die mir vom Bürger anvertrauten Daten erlangt - und muss durch Sicherheitsmaßnahmen u.a. Folgendes garantieren:

  • Behörden müssen kontrollieren können, dass zu schützende Daten nur Befugte erreichen und von Unbefugten nicht eingesehen werden können.
  • Behörden müssen dafür sorgen, dass zu schützende Daten im Transfer zu Befugten verschlüsselt werden, wenn dabei öffentliche Netze passiert werden.

Hierbei gibt es aber Risiken (u.a. durch böswillige Mitarbeiter), denen durch Maßnahmen zu begegnen ist. Die Autorität über Datenflüsse nach außen und über evtl. zu schützende Inhalte kann ich aus Gründen der Risikoeindämmung in der IT nicht an einzelne Mitarbeiter oder Programme am Arbeitsplatz-PCs abtreten. Erforderlich ist vielmehr eine unabhängige, unbestechliche Kontrolle darüber, welche elektronischen Daten über welche Kanäle nach außen wandern. Das ist zumindest meine Erwartung an Behörden in demokratisch verfassten Staaten. Unkontrollierter Abfluss von geheim zu haltenden Daten von Arbeitsplatz-PCs aus geht gar nicht. Und eine durchgehende Verschlüsselung durch Mitarbeiter vom Arbeitsplatz zu Empfängern im Internet erweist sich hier gerade als Problem, da die Verschlüsselung i.d.R. irreversibel ist und auch im Nachhinein keine Inhalts- und Berechtigungskontrolle zu dem Transfervorgang mehr möglich ist.

Das gilt u.a. für Mail-Verschlüsselung in Mail-Anwendungen am Arbeitsplatz genauso wie für HTTPS-Verbindungen zu irgendwelchen Web-Servern. Betroffen sind potentiell aber auch andere Netzwerk-Protokolle. Die nach außen übermittelten verschlüsselten Inhalte sind in allen Fällen auch im Nachhinein nur schwer zu - wenn überhaupt - zu ermitteln. Ggf. durch die Koinzidenz von Zeitstempeln bei Datei-Zugriffen und darauf anschließendem Mailversand. Zeitstempel liefern aber nur Indizien. Ein rechtskräftiger Beweis lässt sich daraus nur schwerlich ableiten, wenn man die Verschlüsselung nicht knacken kann. Gut verschlüsselter Inhalt an illegitime Empfänger ist halt immer noch gut verschlüsselt.

Wenn man dann noch die Aufnahme verschlüsselter Verbindungen zu vom Arbeitsplatz zu beliebigen Zieladressen im Internet zulässt, wird das Problem immens:

Nicht nur ein böswilliger Mitarbeiter kann über einen verschlüsselten Kanal von einem Endgerät aus geheime Daten nach außen schleusen. Über verschlüsselte Verbindungen kann man sich ggf. auch Malware unkontrolliert einhandeln, bevor ein lokaler Virenscanner die eliminieren kann. Und - noch schlimmer: Prinzipiell kann natürlich auch jede Malware (Schad-Software), die man sich irgendwie und irgendwann mal durch Unachtsamkeit eingefangen hat, einen verschlüsselten Verbindungskanal nach außen nutzen, um Informationen an externe Empfänger zu senden.

Vertrauen in Mitarbeiter ist eine Sache; unerkannte Malware, die mit der Nutzerkennung des Anwenders ausgehende Verbindungen zu Systemen im Internet aufnimmt, ein andere.

Nun wird der eine oder andere Leser sagen: Aber wir haben ja Firewalls!? Tja, schon - aber der transferierte Inhalt wurde ja schon im Browser am Arbeitsplatz mit einem zwischen Browser und Zielserver ausgehandelten Schlüssel verschlüsselt. Die Firewall kann die Legitimität der Verbindung damit in keinem Fall mehr am Inhalt festmachen. Höchstens und vielleicht noch am Adressaten. Aber auch ein legitimer Adressat kann illegitime Inhalte über verschlüsselte Verbindungen erhalten.

Nächste Frage: Warum sind verschlüsselte Verbindungen in der öffentlichen Verwaltung dann überhaupt sinnvoll und erlaubt? Hatte ich weiter oben nicht gerade selbst verlangt, dass Kommunikation über das Internet verschlüsselt werden muss? Liegt hier nicht ein Widerspruch vor?

Gute Frage! Betrachten wir zunächst mal eine Privatperson: Die braucht Verschlüsselung, um über das Internet sicher mit anderen Diensteanbietern (in der "Cloud") kommunizieren zu können. Man denke dann z.B. an die Notwendigkeit der Verschlüsselung von Daten im Online-Banking, aber - und ebenso wichtig - an die Notwendigkeit, die Identität eines Webservers feststellen zu können, um nicht auf vorgegaukelte Webseiten hereinzufallen, die dem Original täuschend ähnlich sehen. Auf privaten PCs/Notebooks/Smartphones wird eine dortige "Personal Firewall" deshalb also kaum HTTPS-Verbindungen nach außen blocken. Im Gegenteil sind Privatpersonen eher dazu zu ermuntern, HTTPS wann und wo immer möglich zu nutzen.

Das gilt für Privatpersonen. Im Grunde aber doch auch für Behörden?

Wir dürfen bei der Beurteilung den oben diskutierten Punkt nicht übersehen: Die Tatsache, dass verschlüsselte Verbindungen von Nutzer-Geräten nach außen zu Web- und Dienste-Servern der "Cloud" in unserer internet-dominierten Welt so (überleben-) wichtig sind, dass sie zumindest auf normalen PCS, Smartphones, etc. nicht ohne weiteres geblockt werden können, ist aber eben auch ein erheblicher Schwachpunkt moderner web-orientierter IT und macht einmal eingefangene Schad-Software so erfolgreich und gefährlich:

Der Mensch wird einerseits als Schwachstelle für das Einschleusen von Malware genutzt; die Malware nutzt danach verschlüsselte Verbindungen vom Gerät des Anwenders zu Computern im Internet, welche direkt oder wiederum über Schad-Software durch den Angreifer kontrolliert werden. Was dabei alles vom eigenen PC, aus dem umgebenden Firmen- oder Behördennetz nach außen übertragen wird, können wir dann leider nicht mehr kontrollieren.

Darin besteht die problematische, "dunkle" Seite von Verschlüsselung in bestimmten Arbeitsumgebungen. Kann man diese negative Seite und andererseits die positive Seite von Verschlüsselung bei Behörden überhaupt in Einklang bringen?

Verschlüsselung und Closed Source

Mal (nicht) ganz nebenbei: Unter dem Gesichtspunkt "unkontrollierter Datenabfluss" stellt "Closed Source-Software", die regelmäßig verschlüsselte Verbindungen zu Herstellern und deren Servern aufnimmt, von Haus aus ein großes Problem dar. Auch da haben wir überhaupt keine Chance zu prüfen, was da von unseren Systemen nach außen abfließt. Für mich ist das ein entscheidender Grund dafür, warum der Einsatz von Closed Source Software und Betriebssystemen im öffentlichen Verwaltungsbereich grundsätzlich ein Fehlgriff ist.

Die Umkehrung der Bedrohungsverhältnisse

Nicht nur ein böswilliger Mitarbeiter, sondern auch jede Art von Schad-Software wird typischerweise versuchen, vom "beherbergenden" System aus verschlüsselte Kommunikationskanäle von innen nach außen (!) zu Systemen im Internet aufzubauen, die unter Kontrolle des Angreifers liegen. Der nachfolgende Kommunikationsfluss erfolgt in beide Richtungen; er kann dabei sowohl Kommandos zur Steuerung der Schad-SW (und nach einer Rechteeskalation ggf. des gesamten umgebenden Systems) beinhalten oder aber den Transfer von Informationen zum Angreifer in ganz unterschiedlicher Form.

Früher betrachtete man die Absicherung von Netzen als Aufgabe, zu deren Lösung man einen "Schutzwall" um das eigene Netz aufbaut, der von außen kommende Angriffs- und Eindring-Versuche blockt. Das war schon immer ein unzureichendes Bild. Der Angriff auf IT-Strukturen erfolgt nicht nur von außen nach innen; mit "Social Engineering" und dem Ausnutzen mentaler Schwachpunkte von Menschen gelingt die Platzierung von Malware im Zeitalter von "Bring your own device" auch in Firmen immer irgendwann. Der wirkliche Angriff läuft danach aber sozusagen eher ungeblockt von innen nach außen. Modetrends wie "Bring your own Device (BYOD)" und das Nutzen von Cloud-Diensten lassen zudem die Grenzen zwischen Firmen- und Behörden-Netzen und dem Internet immer weiter verschwimmen. Wenn System-Administratoren meinen, sie müssten in der heutigen Zeit vor allem den Datenverkehr von außen nach innen kontrollieren, irren sie gewaltig. Die Überwachung des Verbindungsaufbaus von innen nach außen und die Überwachung zugehöriger Datenströme ist in bestimmten Netzen noch wichtiger. Übrigens: UDP-basierte Multimedia-Anwendungen, die mit Internet-Diensten kommunizieren, stellen dabei ein besonderes Problem-Umfeld dar und haben in sicheren IT-Umgebungen meiner Meinung nach nichts verloren. Das betrifft im besonderen Skype und dessen Ableger für Firmen.

Leider ignorieren das viele Firmen ... Auch manche Behörden erheben eine Policy zur Erlaubnis verschlüsselter Verbindungen vom Arbeitsplatz-PC ins Internet geradezu zum mitarbeiterfreundlichen Prinzip .. und verlieren dabei jegliche Kontrolle über den Datenabfluss.

Verschlüsselte Verbindungen - ein Dilemma?

Unsere bisherige Diskussion hat bislang ein Dilemma beschrieben:
In einem Behördennetz mit Geheimhaltungsbedarfen sind verschlüsselte Verbindungen/Mails zwischen User-Endgeräten und Servern im Internet ein großes Problem. Andererseits erscheint Verschlüsselung im Datenaustausch über das Internet geradezu als Pflicht ... (Tatsächlich werden ausgehende verschlüsselte Verbindungen ins Internet in vielen Netzen - u.a. denen von Behörden - erforderlich und werden von sog. Perimeter-Firewalls oft auch zugelassen.)

Das Dilemma gipfelt in der Frage: Sollte man Verwaltungsangestellten die Aufnahme verschlüsselter Verbindungen von Netzen, in denen geheimzuhaltenden Informationen gelagert sind, nach außen überhaupt erlauben? Eigentlich kann die Antwort nach dem bisher Ausgeführten nur "Nein" lauten.

Was ist also tun? Der entscheidende Punkt besteht darin, die Irreversibilität von Verschlüsselung ab dem Arbeitsplatz zu vermeiden.

Im Fall hoher Sicherheitsbedürfnisse wird man daher im Regelfall Verschlüsselung nicht direkt von den Endgeräten der Anwender aus zulassen. Das Ziel typischer Lösungsansätzen ist es vielmehr, die Kommunikation über aktive Server des eigenen Netzes zu leiten, bevor ein irreversibler Verschlüsselungsprozess einsetzt. Zentrale Sicherheits-Appliances auf Servern, die im eigenen Netz platziert sind und die die Kommunikation nach außen herstellen, müssen dabei die Kontrolle über die über die ausgehende Verbindung sowie die ausgetauschten Daten und Inhalte behalten.

Entsprechende Lösungsansätze bestehen im Fall von E-Mail darin, Mailverschlüsselung erst ab einem und über einen zentralen Mailserver zuzulassen und automatisiert sowie in Abhängigkeit von den Empfängeradressen durchzuführen. Die Verbindung zwischen Enduser-PC und Mailserver verbleibt dabei unverschlüsselt - oder wird mit eigenen Schlüsseln geregelt, die an den zentralen Servern eine Entschlüsselung der Inhalte erlauben. Die eigenen Server behalten dabei die Kontrolle über die transferierten Inhalte in beide Richtungen. Nicht besonders datenschutzfreundlich bzgl. der Mitarbeiter? Die Frage ist eher, ob private verschlüsselte Mails in Verwaltungsnetzen, in denen hohe Sicherheitsbedarfe gegeben sind, überhaupt etwas zu suchen haben.

Im Fall von HTTP / HTTPS bestehen Lösungswege darin, ausgehende HTTPS-Verbindungen und andere verschlüsselte Verbindungen von User-Geräten entweder zu verbieten oder aber zwischengeschaltete Web-Proxy-Server einzusetzen, die die Verschlüsselung/Entschlüsselung sozusagen als legitimierte "Man-in-the-Middle"-Instanz übernehmen. Proxys müssen dabei die Zertifikate der Zielserver prüfen, den Inhalt der ausgetauschten Datenströme analysieren, protokollieren, etc.. Der User kann dabei evtl. sogar in Richtung Proxy verschlüsseln, aber eben mit Schlüsseln, die mit dem Proxy ausgehandelt werden und nicht mit Schlüsseln für Zielserver im Internet. Der Proxy kann daher Inhalte des Datenstrom entschlüsseln und behält so die Kontrolle über die ausgetauschten Inhalte. Letztere verschlüsselt er dann automatisch neu im Rahmen einer separat aufzubauenden Verbindung mit dem Zielserver im Internet. (Ein verschmerzbarer Nachteil ist, dass der Anwender selbst die Gültigkeit von Zertifikaten der Empfangsstelle nicht direkt kontrollieren kann.)

IVBB und verschlüsselte Verbindungen

Gem. SZ und Heise-Artikel sind verschlüsselte Verbindungen von Anwendern aus dem IVBB nach außen verboten. Gut so! Genau richtig! Das entspricht meinen Erläuterungen von oben. Worin besteht dann das beim Bundeshack laut SZ aufgetretene Problem?

Mail als Kommunikationskanal zu Schad-SW ?

Nun kennen professionelle Angreifer/Hacker/Geheimdienste vermutlich die Verschlüsselungspolitik im IVBB genau. Sie werden sich also intensiv Gedanken darüber gemacht haben, wie sie "Kommunikationskanäle" von einer einmal auf einem angegriffenen IVBB-Gerät implantierten Schad-SW nach außen aufbauen können. Das "unauffällige" und "elegante" Vorgehen, wie die SZ einen Sicherheitsfachmann zitiert, besteht nun wohl darin, ein Mail-Programm als Kommunikationskanal zu nutzen.

Das ist allerdings viel naheliegender als die Presse das darstellt. E-Mail-Kommunikation wird in Organisationsnetzen womöglich noch weniger unterbunden und von den Zieladressen her eingegrenzt als HTTPS- und HTTP-Verbindungen. Behörden müssen ja auch mit anderen Institutionen des öffentlichen Lebens und ggf. sogar Bürgern kommunizieren. Das ist Teil ihrer Aufgabe.

Ein- und ausgehende dienstliche Mails von und zu Mitarbeitern in Behörden werden aber (hoffentlich) auf die dabei transferierten Inhalte geprüft - u.a. durch Virenscanner - und in besonders sicherheitslastigen Umgebungen (hoffentlich) auch durch intelligentes Scannen der textuellen Inhalte: Eingehende Texte u.a. wegen Spam, ausgehende Texte in Kombination mit der Empfängeradresse u.a. wegen illegitimer Inhalte. Voraussetzung ist wiederum, dass eine evtl. Verschlüsselung der Mails erst ab einem eigenen Ausgangsserver (SMTP-Server) erfolgt.

Was aber, wenn ein Angreifer in den Inhalten einlaufender Mails (durch einfache Sprach- oder Buch-Codes) gar keine Malware oder Spam-Inhalte, sondern gestückelt und über den Text verteilt Kommandos an eine SW unterbringt? Und umgekehrt eine Schad-Software oder ein böswilliger Mitarbeiter ausgehende Geheiminformationen illegalerweise in scheinbar harmlosen Texten oder Bildern einer Mail verbirgt - und die geheimzuhaltenden Informationen nur stückweise über mehrere Mails an unbefugte Empfänger überträgt? So, dass das mengenmäßig nicht auffällt? Dann haben Virenscanner ein Problem. Und wird dann zusätzlich nicht auf "seltsame" Empfangs- und Zieladressen reagiert, so gibt es ein absehbares Sicherheitsloch.

Es braucht dann theoretisch nur noch zwei Zutaten für ein Sicherheits-Desaster:

  1. Die bereits vorhandene, implantierte Schad-SW muss eingehende Mails und/oder deren Anhänge auslesen können.
  2. Die Schad-SW muss eigene Mails kodieren und über zentrale Server zu Zieladressen, die der Angreifer kontrolliert, verschicken können - ohne dass das auffällt.

Wie konnte der Datenabfluss über Mails nach außen eigentlich gelingen?

Der SZ-Artikel hebt vor allem auf die Methodik ab, dass von den Angreifern E-Mails zur Steuerung einer ansonsten autonom lebenden Schad-SW, die in diesem Fall offnbar keine aktiven Verbindungen nach außen aufnahm, genutzt wurde. Ja, das ist in der Tat bemerkenswert - und sollte zu einer anderen Einstellung gegenüber dem Aufbau von Arbeitsplätzen in sicherheitsrelevanten Bereichen führen. Darauf komme ich im zweiten Artikel zurück.

Aber viel naheliegender und kritisch zu betrachten ist doch folgender Punkt:
Der Schaden ist vor allem dadurch entstanden, dass Informationen nach außen geschleust werden konnten. Wir hatten aber festgestellt, dass man in sicherheitsrelevanten Netzen die Kontrolle über alle auslaufende Datenströme und deren Inhalte behalten muss. Deswegen wurde ja im IVBB gerade - zumindest gemäß der SZ - der Aufbau verschlüsselter Verbindungen nach außen unterbunden. Nun würde man annehmen, dass das dann auch für den E-Mail-Kanal gilt. Sprich:

  1. Alle Mails gehen ausschließlich über einen eigenen zentralen Mail-Versand-Server (SMTP-Server). Der direkte Versand von Mails mittels eines Mail-Clients vom Arbeitsplatz aus über andere (externe) SMTP-Server wird durch Firewalls strikt unterbunden.
  2. Der eigene Versandserver kann die Identität des Senders nicht nur anhand der IP-Adressen des Arbeitsplatz-PCs sondern auch über elektronische Signaturen an den Mailinhalten feststellen. Die intern verwendeten Signaturschlüssel sind natürlich durch Passwörter geschützt ...
  3. Der eigene Mailserver kann den Mailinhalt und den Inhalt von Anhängen analysieren, bevor vor dem Versand nach außen eine ggf. erforderliche Verschlüsselung in Richtung Adressat erfolgt. Bereits am Arbeitsplatz-PC verschlüsselte Inhalte werden vor dem Versand erkannt und nicht akzeptiert.
  4. Alle Klartext-Inhalte ausgehender Mails (und deren Anhänge) werden zumindest auf Schlüsselbegriffe und versteckte Botschaften hin analysiert. Die Möglichkeit von kodierten Botschaften in Multimediadateien (Steganographie) wird in Betracht gezogen und geprüft (statistische Analyse oder Vergleiche mit Originalen aus definierten offiziellen Datei-Depots. Unbekannte Multimediadateien werden eliminiert.)
  5. Der zentrale Versandserver prüft die Mail-Adresse des Adressaten auf Auffälligkeiten - und stoppt die Mail gegebenenfalls. In diesem Zusammenhang sind von Mitarbeitern ggf. explizite Deklarationen und Freigaben von Ziel-Adressaten in zentralen Listen/Datenbanken einzufordern.

Nun drängt sich - unabhängig von Problemen mit Outlook - der Verdacht auf, dass an einem dieser Punkte etwas schief gegangen sein muss. Oder, dass meine - hoffentlich einsichtige Haupt-Annahme - nicht stimmt und zentrale Mail-Versand-Server und dortige Prüfungen durch die Schad-Software umgangen werden konnten. Was beides peinlich wäre, da alle genannten Punkte grundsätzlicher Natur sind. Entsprechende Schwachpunkte hätten dann ja auch bereits Menschen - z.B. korrupte Angestellte - ausnutzen können. Zu allen oben genannten Punkten fallen einem natürlich noch weitere Unterpunkte und Fragen ein.

Zum ersten Punkt ist zu sagen, dass eine Perimeter-Firewall einen Mailversand über IVBB-externe SMTP-Server natürlich unterbinden muss. Davon ist hoffentlich auszugehen?

Bei Punkt 2 kommt die Frage ins Spiel, wie die Schad-SW überhaupt die ausgehenden Mails konstruiert hat - mit oder ohne Nutzung bzw. steuernde Manipulation von Outlook? Wenn letzteres: Wieso war/ist das überhaupt möglich und zugelassen? Und wieso wird überhaupt ein so anfälliger und durch Dritt-Software unter Windows manipulierbarer Mailclient wie Outlook in einem Netz mit hohen Sicherheitsbedarfen eingesetzt?

Falls die Schad-Software ihre Mails aber autonom verfasst hat: Wieso und wie konnte sie interne Signatur-Schlüssel erfassen? Oder werden im IVBB gar keine internen Signaturen zur Authentizitätsfeststellung der Verfasser vor dem Versand verwendet?

Punkt 4 ist fundamental, aber in der Praxis ggf. problematisch. Aber daran hängt doch irgendwie alles! Das Thema muss sich doch jemand bereits gründlich durchdacht haben - zumindest beim BSI. Ein gestückelter Datenabfluss über versteckte Nachrichten in Texten und Multimedia-Dateien ist doch ein Grund-Risiko, das sich zur Behandlung durch technische Maßnahmen geradezu aufdrängt. Erst recht, wenn man schon richtigerweise ein Verbot verschlüsselter Verbindungen nach außen gegenüber Mitarbeitern durchsetzt, um ausgetauschte Inhalte kontrollieren zu können.

Punkt 5 ist ebenfalls fundamental. Mailversand zu x-beliebigen ungeprüften Empfangsadressen in der Welt erscheint irgendwie als ein "No Go". Dass es in diesem Kontext nicht reicht zu prüfen, ob es zu einer Mailadresse auch schon mal einen Eingang gab, liegt auf der Hand. Die Gültigkeit einer Adressaten-Adresse muss sich an viel mehr Kriterien festmachen.

An dieser Stelle schließt sich eine weitere interessante Unterfrage an: War die Zieladresse vielleicht gar eine bekannte? Wenn ja, dann würde das bedeuten, dass auch die dortigen Systeme unter Kontrolle von Angreifern liegen und der Hack insgesamt viel größere Ausmaße hat als bislang gedacht.

Zusammenfassend müssen sich die Betreiber des IVBB folgende Fragen gefallen lassen :

  • Wie konnten Mails mit kritischen Inhalten überhaupt an den Angreifer versandt werden? Welche Lücken wurden da ausgenutzt? Sind diese Lücken ggf. von allgemeinem öffentlichen Interesse, weil sie mit Schwachpunkten der SW Outlook und/oder bestimmter Mailserver zu tun haben?
  • Wieso und wie haben andere befreundete Geheimdienste das mitbekommen? Waren die in der Lage die Mails abzufangen und die Kritikalität der Inhalte zu erkennen? Wieso? Und wieso die IVBB-Betreiber nicht?
  • Im Kontext von E-Geovernment in Deutschland tauchen regelmäßig die Themen "verschlüsselnde OSCI-Infrastruktur" (s. Wikipeadia zu Online-Services-Computer-Interface), "Virtuelle Poststelle des Bundes", "Governikus-Server" (https://www.governikus.de/anwendung-des-it-planungsrates/faqs-zur-anwendung-governikus/ und Governikus-Portfolioueberblick-Juni2017-Einzelseiten.pdf) u.a. in der Funktion als sichere Mail-Gateways ins Internet auf. Wie passen die offenbar vorhandenen Lücken und Defizite eigentlich damit zusammen?

Bzgl. des letzten Punkts ist auch interessant, dass 2017 Sicherheitslücken im OSCI-Transport-Protokoll festgestellt wurden.

Es sollte nun hinreichend klar geworden sein, dass es beim Bundeshack nicht allein um Schwächen von Outlook geht.

Nachtrag 23.03.2018:
Zwei Nachrichten passen gut zum Kern der obigen Ausführungen:
http://www.sueddeutsche.de/digital/attacke-auf-auswaertiges-amt-die-geschichte-eines-cyber-angriffs-1.3917502
Tja, irgendwie peinlich, dass ein ausländischer Nachrichtendienst verdächtige Mails aus dem eigenen Netz entdeckt. Dass einer eigenen Überwachung gesetzliche Hindernisse im Wege stehen könnten, dürfte wohl bei Scans nach selbst versandten Mails, eigenen IP-Adressen und zugehörigen Mustern kein Argument sein.

Bzgl. des Bezugs zu proprietärer Software ist folgender Artikel interessant:
https://www.heise.de/ix/meldung/Bund-will-Windows-10-ueber-Bundesclient-sicher-nutzen-koennen-3907088.html
Ich finde es beunruhigend, wenn man Desktop-Systeme von Spezialkräften aus Sicherheitsgründen so hinbiegen lassen muss, dass sie für die Verwaltung geeignete sind und eine Überwachung von Datenströmen zwischen Clients und Servern (s.o.) überhaupt erlauben.

Im nächsten Beitrag befasse ich mich ein wenig mit der Frage, ob ein Standard-Arbeitsplatz, bei dem Mail, Dateibearbeitung, Internet-Browsing durch Programme einer Desktop-Umgebung abgewickelt werden, überhaupt noch zeitgemäß und höchsten Sicherheitsanforderungen in Behörden angemessen ist.

Spectre und Torvalds harsche Kritik an David Woodhouse – ein Kommentar von der Peanut-Gallery

Ich verstehe nicht viel von Kernel-Details. Wenn aber die Medien mal wieder kritische Äußerungen von L. Torvalds zu den Anti-Spectre-Maßnahmen von Intel und/oder zu Vorschlägen einzelner Kernel-Entwicklern zu Top-IT-Meldungen aufblasen, dann lohnt sich ein genauerer Blick in die aktuell ablaufende Diskussion. Das führt dann manchmal zu überraschenden Ergebnissen:

Während ich die generelle Kritik an Intels Verhalten in den letzten Monaten seit Bekanntwerden von Meltdown/Spectre nachvollziehen kann, finde ich die zum Teil persönliche Kritik am (ehemaligen Intel-) Entwickler David Woodhouse völlig daneben.

Es geht in der interessierten Öffentlichkeit manchmal unter, dass die kolportierte Äußerung "complete and utter garbage" in einer Diskussion zu Vorschlägen von David Woodhouse auch mit persönlichen Anwürfen verbunden wurde. Dazu sollte man sich den Text unter https://lkml.org/lkml/2018/1/21/192 mal genau ansehen. Das kann man als Betroffener durchaus auch persönlich nehmen.

Ich habe dazu eine klare Meinung: Der Ausbruch von Torvalds ist in seinen personenbezogenen Facetten respektlos - und angesichts des Einsatzes und der Beiträge von David Woodhouse zur aktuellen Diskussion auch unangemessen.

Ich kann jedem nur raten, die gesamte Diskussion unterhalb von https://lkml.org/lkml/2018/1/20/163 und auch vorhergehende Diskussionsbeiträge genau zu studieren. Ich habe mir das gestern mal angetan. Ich verstehe nur Grundzüge der technischen Argumentation. Aber es bleibt der Eindruck,

  • dass es ein spezielles Spectre-Problem mit Skylake CPUs gibt, dessen Konsequenzen für Verteidigungsmaßnahmen nicht abschließend geklärt sind. David Woodhouse hat entsprechenden Sorgen beharrlich Ausdruck verliehen - und sie nicht beiseite wischen lassen. [Ich nutze mehrere Skylake-CPUs; die sind noch nicht so alt - und ich wäre schon daran interessiert, dass evtl. Probleme systematisch aufgearbeitet werden....]
  • dass die Vorschläge, neue ggf. kritikwürdige Features in Intels Microcode zu nutzen, um auf die sichere Seite zu gelangen, zumindest als an-/abschaltbare Option denjenigen Administratoren Zeit verschaffen würden, die auf einigen exponierten Server-Systemen Sicherheit vor Performance priorisieren müssen.
  • dass David Woodhouse die negativen Performance-Aspekte der vorgeschlagenen Maßnahmen zu keinem Zeitpunkt aus dem Auge verloren hatte und die Vorschläge auch lediglich als zwischenzeitliche Ansätze verstand.
  • dass die neuen Vorschläge von I. Molnar erst nach den (oder aufgrund der ?) Diskussionsbeiträge von David Woodhouse kamen.

Ich will und kann technische Details der Diskussion nicht wirklich bewerten. Temporäre Optionen vorzuschlagen, die Sicherheit vor Performance setzen, ist aber sicher legitim. Dieser Ansatz verdient eine ruhige, sachliche Analyse hinsichtlich aller Vor- und Nachteile. Fundamentalkritik an den Microcode-Angeboten von Intel sollte dabei aus meiner Sicht nicht auf die persönliche Ebene runtergezogen werden.

Umso erstaunlicher fand und finde ich die Antwort von David Woodhouse (siehe https://lkml.org/lkml/2018/1/22/598) auf Torvalds emotionsgeladenen Ausbruch! Hut ab vor den dortigen, ausgewogenen Kommentaren:

Aus meiner Sicht verdient der Antworttext einen ggf. noch zu erfindenden Preis

  • für Contenance und das Dämpfen unproduktiver Emotion,
  • für die Bereitstellung gegliederter Information,
  • für ruhige, sachliche Argumentation.

Respekt vor David Woodhouse! Viele andere wären vor einer öffentlich transportierten Kritik von Torvalds eingeknickt oder hätten die Fassung verloren. Hier hat dagegen jemand seine Überzeugung vertreten und seinen Sorgen auch nach dem Medienzirkus um Torvalds Worte nachhaltig und in angemessenem Ton Ausdruck verliehen. In unserer aller Interesse - auch wenn ein Torvalds das vielleicht aus technischen Gründen und Aversionen gegenüber Intel nicht so sehen mag.

Nun bin ich als normal Linux-Sterblicher auch nur Mitglied der "Peanut Gallery" - wie D. Woodhouse selbst das nennt :-). Vielleicht gefällt ihm folgende Ansicht einer Peanut aber trotzdem:

Gerade wir Linuxer müssen froh sein um standfeste Leute, die auch mal gegen den Strom schwimmen - selbst wenn das dann höhere Emotionswellen bei den Ober-Gurus verursacht. Ohne engagierte Leute, die ihre fachlichen und technischen Ansichten ohne Scheu vor Kritik vertreten, wäre die Open Source-Bewegung nur wenig wert ... Polternde Gurus und Helden allein garantieren den nachhaltigen Erfolg von Produkten und Ideen nämlich nicht ....

Gerne nehme ich andere Meinungen unter unter Facebook (https://www.facebook.com/linuxdiver/ oder https://www.facebook.com/ralph.monchmeyer) entgegen.

Meltdown und Spectre – Lehren aus dem Desaster? – III – Browser, Open Source?

Eines der aus meiner Sicht hohen Gefährdungspotentiale von Spectre lässt sich womöglich daran festmachen, dass zumindest in der Theorie Angriffe auch mit Hilfe von Javascript geführt werden können. Es lohnt sich an dieser Stelle deshalb, ein wenig über Browser im Lichte von Spectre nachzudenken. Ich ergänze diesen Beitrag zudem durch ein paar Überlegungen zu Open Source im Kontext der neuen Bedrohungen.

Der Browser als Einfallstor - nicht erst seit Meltdown/Spectre

Sehr "schön" ist in diesem Zusammenhang die Seite 13 in https://meltdownattack.com/meltdown.pdf, in der gezeigt wird, wie Passwörter aus dem Firefox-Passwortspeicher ausgelesen werden können. Es gibt dazu auch ein nettes Video. Zugriffe auf Passwortspeicher sind allerdings auch mit Angriffsmustern gemäß Spectre möglich. Zwar kann man Cache-Analysen wie in den Originalveröffentlichungen diskutiert, womöglich von Seiten der Browser-Hersteller unterbinden. Man darf gespannt sein, wann die Barrieren für spezifischen Seitenkanal-Angriffsvariante, die genaue Zeitmessungen erfordern, durch Ausnutzen anderer Seitenkanalwirkungen des Prozessor-Cachings umschifft werden können. Die aktuelle Ausgangslage verspricht jedenfalls ein lustiges Jahr 2018 ...

Das Angreifen von Browser-Subprozessen, zu denen Javascript-Programme keinen Zugang erhalten dürfen, ist an sich schon eine kritische Sache. Globaler betrachtet offenbart sich durch Meltdown/Spectre aber nur einmal mehr, dass die Anwendung "Browser" ein Angriffstor mit potentieller Tiefenwirkung für alle Betriebssysteme darstellen:

Aus Security-Perspektive sind Browser eigentlich als Anwendungen zu betrachten, die sich jederzeit in Schadcode-Implantations-Zentren verwandeln können.

Konnte man sich als Linuxer auf PCs bislang gegen landläufige Angriffsvektoren im Kontext von Browsern dadurch schützen, dass man Browser-Applikation dediziert in Containern oder besser noch virtuellen Maschinen unter KVM laufen ließ, so werden solche Konzepte durch die Prozessor-Schwachstellen ausgehebelt. Das gilt analog für Chrome/Chromium, die die Browserprozesse in separate Namespaces des Linux-Systems einbetten - und damit eine ähnliche Isolation wie Container erreichen.

Wenn aber selbst die Isolierung von Browsern unter Linux in eigenen Namespaces (s. Google) oder Containern aufgrund von kommenden Spectre-Angriffen nicht mehr hinreichend sein wird, um andere Systemprozesse und deren Datenkontexte zu schützen - tja, was dann?

Ursachen der Javascript-Misere

Eine interessante Frage ist zudem: Wem oder was haben wir eigentlich diese Misere von Angriffspfaden über Browser und Javascript zu verdanken?

Wenn man ehrlich ist, ist für viele Webseiten Javascript gar nicht zwingend erforderlich. Trotzdem wird es im Übermaß eingesetzt. Das liegt u.a. daran, dass sich viele Probleme leichter mit JS als mit CSS-Tricks lösen lassen. Nun wäre das nicht so schlimm, wenn sich das JS-Angebot auf das für die Funktionalität einer Seite Notwendige beschränken würde und die JS-Codes aus einer Quelle stammen würden. Das ist aber wegen der in viele Webseiten integrierten Werbung heute nicht mehr der Fall; s.u.. Zudem lässt leider auch das W3C immer JS-Funktionen zu, die potentiell problematisch werden können.

Ins Feld geführt wird regelmäßig auch ein Performance-Aspekt: Interaktionen des Users mit Webseiten sollen nicht zu einem Nachladen neuer (ggf. auf Servern per Script generierter) HTML-Seiten führen, sondern im Browser selbst abgehandelt werden. Hätten wir Gigabit-Netz, wäre dieses Argument nicht unbedingt schlagend. So aber sind Nutzer für viele Seiten tatsächlich gezwungen, Javascript anzuschalten.

Eine andere Ursache ist die Werbeindustrie mit ihren Tracking-Verfahren. Auf vielen Seiten sind die Quellen von integrierten JS-Codes von Dritt- und Viert-Firmen zur Analyse des Nutzerverhaltens derart unübersichtlich verteilt, dass man die betreffenden Seiten am besten gleich wieder schließt. Eien Analyse aller integrierten Codes ist in der Praxis unmöglich. AdBlocker helfen auch da nur bedingt.

Zudem ist der normale Nutzer im Westen ist inzwischen so stark an "kostenfreie" SW gewöhnt worden, dass er alle potentiellen Gefahren ignoriert. Zu was das am Smartphone führt sieht man ja bei der Installation vieler APPs und den dafür angeforderten Zugriffsrechten auf Speicher, Kontaktverwaltung und Kalender sowie Devices (Kamera, GPS, Mikrophon, ...) - die Sicherheit bleibt dabei auf der Strecke. Die meisten Benutzern erlauben ihren ach so geliebten Apps den Zugriff auf fast alle Devices und Daten. So gibt es inzwischen denn auch Browser-Plugins, die auf diverse Elemente eines PCs (wie etwa den Desktop) zugreifen können ... Eine Todsünde ...

Ein weiterer wichtiger Grund ist aber auch der gottverdammte Cloud-Gedanke:
Applikationen und deren Daten sollen aus dem Internet von Provider-Servern geladen und lokal in Browsern mit maximaler Funktionalität ausgeführt werden - angeblich zum Komfort des Nutzers. Beispiel: Browserbasierte Office-Anwendungen. Der laufende Datenaustausch mit Cloud-Speichern erfordert dabei Ajax-Technologien und damit Javascript zwingend. Schöne neue Welt ...

Es ist klar, dass diese Entwicklungen zusammen immer mehr ausführbaren Code im Browser erfordern - und dass solcher Code auch immer mehr Möglichkeiten und ggf. Rechte zur Manipulation lokaler Speicherinhalte bekommen muss.

Diese Entwicklungen werden in Kombination mit den nun bekannten Schwachstellen von Prozessoren zu einer immensen Gefahr. Staaten wie z.B. China zeigen bereits unverblümt, was sie mit den aktuellen technischen Möglichkeiten erreichen wollen: Die Kontrolle der eigenen Bürger. Warum das nicht auch auf Nutzer von APPs bzw. Webseiten, die im Auftrag von kontrollierten Firmen im Westen erstellt werden, ausweiten? Spectre liefert interessierten staatlichen Organisationen mit hinreichenden Ressourcen ganz neue Angriffspunkte, um Informationen über uns alle zu sammeln ... Das Schlimme ist, dass es bis zu einer neuen Prozessorgeneration noch kein zuverlässiger Schutz absehbar ist. Die Geister, die wir alle in unserer Gier, laufend und in allen Lebensbereichen "online" zu sein, gerufen haben, sie wenden sich nun gegen uns. Wir sollten alle beginnen, völlig neu über unsere Nutzung des Internets nachzudenken.

Open Source - Chance oder Gefahrenquelle im Spectre-Kontext?

In einem früheren Beitrag hatte ich erwähnt, dass das Umsetzen von Spectre in massenhaft nutzbare Angriffsformen die intime Kenntnis von Anwendungen und Betriebssystemen verlangt - sowie natürlich hinreichende Entwicklerkapazität mit diesen Kenntnissen. Wo ist das am meisten gegeben? Bei den Herstellern von Anwendungen und Betriebssystemen, aber natürlich auch bei staatlichen Organisationen.

Nun könnte man argumentieren, dass gerade Open Source hier ein Nachteil sei. Das Argument ist mir in Diskussionen tatsächlich schon begegnet: Schließlich eröffne ja gerade die Offenlegung der Betriebssystem- und der Anwendungscodes Hackern die Möglichkeit, sich tief einzuarbeiten und passende Code-Segmente für transiente Codeblöcke in Spectre-Angriffen auszuwählen. Stimmt - das Ausnutzen von Schwachstellen in Open Source Anwendungscode ist tatsächlich auch unabhängig von Spectre schon passiert. Aber:

Das vorgebrachte Argument gilt natürlich noch viel mehr für die Hersteller proprietärer Software und Betriebssysteme. Die dortigen Entwickler müssen sich ja gar nicht mehr einarbeiten - die kennen ihre Umgebung ja schon! Und wir als Benutzer haben bei proprietärem Code keine Chance nachzuprüfen, ob die Hersteller oder evtl. korrupte Mitarbeiter solcher Unternehmen durch Elemente ihrer Betriebssystem- oder Anwendungs-SW künftig nicht gezielt globale Schwachstellen wie Spectre ausnutzen (werden) - zu welchem Zweck auch immer. Es gibt keine wirkliche Verteidigung dagegen.

Aus den Forschungsergebnissen zu Meltdown/Spectre wird zudem klar, dass Spectre-basierte Angriffe so gut wie keine Spuren im angegriffenen System hinterlassen würden. Ein Eldorado für hinreichend skrupellose Ersteller proprietären Codes.

Aus diesen Gründen ist eine essentielle Konsequenz aus den Erkenntnissen zu Spectre und Meltdown:

Ein Umsteigen auf Open Source-Systeme ist mehr denn je notwendig! Für Privatpersonen, Unternehmen, aber auch Institutionen der öffentlichen Verwaltung.

Dieses Argument gilt dabei in ganz besonderem Maße für die öffentliche Verwaltung, die immer im Interesse der Bürger (hier Datenschutz und Datensicherheit) handeln sollte. Spectre und Meltdown lassen deshalb die Entscheidung der Stadt München, künftig auf proprietäre SW zu setzen, nicht nur unter Kosten- und Abhängigkeitsgesichtspunkten als grundfalsch erscheinen. Diese Entscheidung ist vor allem unter dem Aspekt der Sicherheit in Frage zu stellen. Gerade dann, wenn die Stadt - wie seit Jahren bekundet - verstärkt auf E-Government setzen will.

An dieser Stelle sei abschließend auf folgende Artikel verwiesen, der das Thema Datenschutz und Microsoft noch unter einem ganz anderen Gesichtspunkt beleuchtet:
http://www.handelsblatt.com/politik/international/datenschutz-in-gefahr-ende-des-internets-wie-wir-es-heute-kennen/20876998.html

Man kombiniere das dort Beschriebene einmal mit den Möglichkeiten von Spectre. Das alles ficht aber wohl die Mitglieder des Stadtrates nicht an. Die Mitarbeiter eines Beratungsunternehmens mit Hauptsitz in Dublin, welches nicht für Linux-Affinität bekannt ist, und vor allem die Chefs eines Betriebssystemherstellers aus Übersee können sich dagegen ein paar Sektgläser füllen und sich gratulieren. Ein neuer Trinkspruch von IT-lern soll ja sein: Prosit Meltdown ...

Nebenbei: Besagtes Beratungsunternehmen hat seit letztem Jahr auch die Aktienmehrheit beim größten deutschen Internetdienstleister erworben. Ein Schelm, wer da anfängt, über künftige Outsourcing-Möglichkeiten zu spekulieren ...

Im nächsten Beitrag wende ich mich weiterem Fallout von Spectre/Meltdown zu - nämlich Servern, Virtualisierung und wiederum Cloud-Diensten.