Das dürfte wohl die sperrigste Überschrift sein, die mir seit Jahren eingefallen ist, aber leider wird es gleich technisch, und ich wollte das gleich zu Beginn klarstellen – zu Lasten der Schmissigkeit der eigentlich zum Lesen einladenden Schlagzeile. Worum geht es?
Zu jedem ordentlichen IT-Sicherheits-Praxisseminar gehört ein Abschnitt, in dem die Teilnehmerinnen sich aus dem Netz ein Programm herunterladen, es auf ihrem Rechner installieren und damit Erfahrungen sammeln. Wer aufmerksam mitgelesen hat, wird stutzen: Moment, warum überprüft er den Download nicht? Ist es nicht sträflicher Leichtsinn, ein Programm einfach so aus dem Netz auf die eigene Platte zu kopieren und auszuführen? Kann mir da nicht jemand Schadcode unterjubeln?
Meine polemische Antwort lautet: Ja, und du merkst es auch nicht, wenn du den Download überprüfst. Die weniger polemische Fassung: Ja, aber der Test bringt nicht so viel mehr Sicherheit, wie du vielleicht annimmst.
Den endgültigen Anlass, das Thema etwas ausführlicher zu behandeln, gab mir die Mail einer Seminarteilnehmerin, die sich den Torbrowser herunterladen und brav der Anleitung folgend anschließend kontrollieren wollte, dann aber an der Dokumentation scheiterte, die hier nicht nur das Herunterladen eines weiteren Programms, sondern auch noch die Eingabe eines für Laien unverständlichen Kommandozeilencodes vorsah. Ihre Kritik: “Verlangen die ernsthaft, dass ich Stunden damit zubringe, mir das Wissen anzueignen, um dieses eine Kommando auszuführen? Ist ein nicht verifizierter Download wirklich so gefährlich?”
Mein erster Blick galt der Dokumentation. Manchmal ist sie einfach nur unnötig kompliziert, und es gibt intuitiver zu nutzende Alternativen. Beim Torproject wurde mir aber schnell klar: Die hatten nachgedacht, und bei der von ihnen gewählten Methode fällt mir auch nichts Besseres ein. Trotzdem ist die Anleitung für Laien unbrauchbar.
Insgesamt meine ich, dass es bestimmt nicht schaden kann, die Wahrscheinlichkeit eines Schadsoftwarebefalls so gering wie möglich zu halten. Die Frage ist nur, ob die üblichen Prüfsummenchecks dabei wirklich helfen. Sehen wir uns dazu die möglichen Angriffszenarien an.
Möglichkeit 1: Der Code wurde auf dem Server manipuliert
Dieser Fall tritt immer wieder auf und dürfte das gängigste Szenario sein. Jemand verschafft sich Zugriff auf den Server und hinterlegt dort eine mit Schadcode versetzte Version des eigentlich harmlosen Programms. Die Leute laden es sich herunter, installieren es, und schon haben wir hunderte, vielleicht sogar tausende durch die Unachtsamkeit der eigenen Besitzerinnen verseuchte Endgeräte. Hätten sie doch nur den Download geprüft!
Exkurs: Was ist ein Hash?
Bevor wir uns diesem Vorwurf widmen, ein kurzer Blick, wie die serverseitig zur Abwehr dieser Gefahr vorgesehenen Mechanismen lauten. Der übliche Weg besteht in der Berechnung einer “Hash” genannten Prüfsumme, meist irgendwas mit MD5, SHA1 oder SHA256. Über das konkrete Verfahren lässt sich insbesondere bei MD5 und SHA1 streiten, weil sie als nicht mehr besonders sicher gelten, aber die Idee ist immer die gleiche: Die Programmautorinnen berechnen auf ihrer Seite den Hash und veröffentlichen ihn zusammen mit dem Download. Die Anwenderinnen stellen das Gleiche mit dem von ihnen heruntergeladenen Code an und damit sicher, dass die auf dem Server angebotene sowie die auf der Platte befindliche Software bis aufs letzte Bit identisch sind. Als Mathematiker muss ich anmerken, dass Hashes aufgrund ihrer Natur immer so genannte Kollisionen haben müssen und wir deswegen streng genommen nicht von “Sicherheit” sondern von “nach menschlichem Ermessen hinreichend hoher Wahrscheinlichkeit” reden sollten, aber das ist für diese Betrachtung nebensächlich. Wichtig ist hingegen die Frage: Wenn ich es schaffe, den auf dem Server zum Download angebotenen Code zu manipulieren, warum tausche ich dann nicht auch gleich den Hash und damit die Prüfmöglichkeit mit aus?
Eine mögliche Antwort könnte darin bestehen, den Download und den Hash auf zwei verschiedenen Systemen zu hinterlegen, so dass bei einem Angriff zwei getrennte Server übernommen werden müssen. Wer dazu nicht die Möglichkeiten hat, tauscht vielleicht nur das Programm aus und vertraut darauf, dass niemand so genau hinsieht. Das wäre doch genau ein Szenario, in dem die Hashprüfung sinnvoll ist.
Vertrauen auf die Schwarmparanoia
Noch einmal: Ich behaupte nicht, dass sie sinnlos ist. Ich sage nur, dass sie weniger bringt als es auf den ersten Blick scheint. Nehmen wir also an, dass nur das herunterzuladende Programm, nicht jedoch der Hash ausgetauscht wurde, weswegen es möglich ist, die Manipulation zu erkennen. Wie wahrscheinlich ist es, dass Laien die Ersten sind, die das bemerken? Ich bin mir sicher, dass ständig irgendwelche sicherheitsbewussten Nerds Testdownloads vornehmen, einfach als Dienst an der Gemeinschaft. Wahrscheinlich haben etliche von ihnen den Vorgang geskriptet, so dass sie sich nicht mehr selbst darum kümmern müssen. Ähnlich wie wir allgemein bei Freier Software auf die argusäugige Community vertrauen, halte ich es für angemessen, auch hier zu hoffen, dass es genug Leute gib, die genau diesen Angriffsvektor überwachen. Natürlich kann ich Laien nur zur Vorsicht ermuntern, aber hier scheint sie mir nicht zwingend geboten.
Alternative: signierte Downloads
Das Torproject geht bei der Prüfung einen interessanten Schritt weiter: Sie veröffentlichen nicht den Hash, sondern signieren den Download und publizieren die Anleitung, wie mit Hilfe des auf einem externen Systems abgelegten öffentlichen Schlüssels die Integrität des Programms sichergestellt werden kann. Eine Manipulation des Hashes ist damit ausgeschlossen.
Das ist richtig, aber genau wie oben argumentiere ich: Wenn ich den Server unter meine Kontrolle bringe, kann ich alles darauf ändern. Zur Not schreibe ich den Downloadlink um und ändere die Dokumentation so, dass zum Prüfen nicht der echte öffentliche Schlüssel der Torprojects sondern ein von mir gefälschter genutzt wird. Eine weitere Schwäche dieser Methode liegt in der Kommandozeile, an deren Nutzung hier kein Weg vorbei führt. Für Windows gibt es mehrere Programme, die es mir ermöglichen, mit einem Rechtsklick auf ein Dateisymbol dessen Hash angezeigt zu bekommen. Ich kann also auf der Windowsoberfläche bleiben. Wenn ich wie vom Torproject vorgeschlagen GnuPG nutze, muss ich auf die Kommandozeile, und ich halte nicht seit über 10 Jahren Seminare für IT-Laien, um nicht auf gesicherter Erfahrung basierend sagen zu können: Damit hänge ich bis auf maximal ein, zwei Leute die gesamte Gruppe ab. Textbefehle sind bei Microsoft ein Relikt aus DOS-Zeiten und werden heute fast nur noch von Sysadmins benutzt. Kommandozeilen sind phantastische Werkzeuge – wenn ich mit ihnen umgehen kann. Gerade aber unter Windows kommen einige schwer zu kontrollierende Parameter hinzu. Insbesondere muss ich die Dateipfade genau kennen, und die können variieren. Um sicherzustellen, dass mein Kommandozeilenbefehl in genau dieser Form funktioniert, muss ich die vorher stattfindenden Schritte auf so schmerzhaft genaue Weise beschreiben, dass ich die Meisten damit abschrecke.
Nach dem Download ist vor dem Download
Hinzu kommt bei Windows ein weiteres Problem: Die zur Downloadkontrolle nötigen Programme gehören nicht zum Lieferumfang, sondern müssen manuell nachinstalliert werden. Damit wiederum beißt sich die Katze in den Schwanz, denn nun habe ich auf einmal nicht nur ein, sondern zwei Programme, deren Integrität ich sicherstellen muss. Ich weiß, ich wiederhole mich, aber: Für Laien scheint mir der hier nötige Aufwand im Vergleich zum behandelten Risiko nicht angemessen.
Möglichkeit 2: Das Programm wird während des Downloads ausgetauscht
Wenn Sie eine Vokabel zum Angeben brauchen: Der hier geschilderte Angriff nennt sich “Machine in the Middle”, kurz “MITM”. Gemeint ist damit jemand, der zwischen dem Downloadserver und dem Endgerät sitzt und alle ausgetauschten Daten manipulieren kann. Selbst zu Zeiten, als die meisten Seiten unverschlüsselt mit HTTP und nicht wie heute verschlüsselt mit HTTPS angesprochen wurden, war dieses Szenario zwar möglich, aber aufwendig. Um möglichst viele Daten zu erwischen, musste die Verbindung nah am Server aufgetrennt werden, idealerweise im Rechenzentrum selbst oder beim Netzanbieter, der das Rechenzentrum versorgt. Die Mittel dafür haben gewöhnliche Kriminelle selten, sondern eher staatliche Akteure. Wenn ich ernsthaft mit derartigen Aktionen rechnen muss, ist das Herunterladen des Torbrowsers meine kleinste Sorge. Was mir eher schlaflose Nächte bereitete, wäre das politische System des Landes, in dem ich mich befinde.
Heute fiele ein solcher Angriff schneller auf als zu Zeiten unverschlüsselten Netzverkehrs. Wer eine SSL/TLS-verschlüsselte Verbindung auftrennt, hinterlässt zwangsläufig Spuren, weil er den Verkehr entweder unverschlüsselt weiterleitet – was auffiele – oder die Daten neu verschlüsselt, dann aber mit einem anderen Zertifikat als das des Originalabsenders – was ebenfalls auffiele. Das hier geschilderte Vorgehen nennt sich “SSL Interception” und findet häufig auf Firmenfirewalls, in öffentlichen WLANs von Seminarhäusern oder lokal bei Virenscannern statt, die meinen Browser vor dem Laden schädlicher Inhalte bewahren sollen. In jedem dieser Fälle bleibt der sich einschaltenden Seite nichts Anderes übrig, als die Originalsignatur durch eine eigene zu ersetzen, und das führt üblicherweise zu Warnmeldungen im Browser. Um dem zu begegnen, installieren Firmennetze und lokale Virenscanner eigene Zertifikatsstellen auf den Endgeräten. Damit unterdrücken sie zwar die Fehlermeldung, aber wer in das Zertifikat hineinschaut, erkennt die Manipulation. Die Frage ist: Was bringt es mir, in einem solchen Fall den Hash zu prüfen? Hier lautet meine Antwort ebenfalls: Es ist nicht falsch, aber es bringt nicht viel.
Sowohl Firmen- und WLAN-Netze als auch lokale Virenscanner sind üblicherweise so gebaut, dass sie vor allem überwachen und im von ihnen als solchen betrachteten Gefahrenfall blockieren. Entweder lassen sie Daten unverändert durch oder sie sperren. Sie tauschen nicht ein Programm aus. Anders wäre es bei einem Akteur, der im Rechenzentrum des Servers oder bei dessen Internetanbieter steht. Wer so weit vorne in den Datenstrom eingreift, hat im Zweifelsfall auch die MIttel, sich glaubwürdige Zertifikate zu beschaffen und neben dem Programm auch dessen Hash auszutauschen. Ein solcher Angriff fiele allerdings auf – wenn nicht Laien, dann aber Expertinnen, die beispielsweise mit Hilfe von “Certificate Pinning” plötzliche Änderungen bei den Signaturen bemerken. Wenn mein lokales Netz oder mein Virenscanner an meinem Datenstrom herumfummeln, bin ich zwar nicht begeistert, aber entweder habe ich die Expertise, damit umzugehen oder ich habe sie nicht und zucke ergeben mit den Schultern.
Möglichkeit 3: Auf meinem Gerät selbst findet die Manipulation statt
Einen Fall haben wir mit dem lokalen Virenscanner schon besprochen. Ein anderes Szenario bekomme ich immer wieder als Argument erzählt, und ich finde es auch nach vielen Jahren wenig überzeugend: Was ist, wenn ein trojanisches Pferd mein Gerät unter Kontrolle hat?
Ja, was wäre dann? Was wäre, wenn ich vor meiner Wohnung Natodraht ausgerollt, die Tür aus Tresorstahl gefertigt und mit Schlössern augestattet habe, mit denen ansonsten Fort Knox und Atombunker gesichert werden, meine Frau aber eine gesuchte Massenmörderin ist? Sind dann nicht meine ganzen Sicherheitsmaßnahmen wirkungslos? Natürlich sind sie das, weil sie für eine ganz andere Art von Angriff gebaut wurden. Meine Sprinkleranlage schützt mich vor Feuer aber nicht vor Erdbeben, doch dafür ist sie auch nicht konzipiert. Ich bekomme immer wieder Meldungen, Verschlüsselung X oder Messenger Y sei geknackt worden. Nach der ersten Panik sehe ich mir die Meldung genauer an, und stelle oft fest: Nicht die Verschlüsselung selbst hat ein Problem, sondern die Implementierung. Wenn ich eine Sachertorte backe, aber statt frischem Fett gebrauchtes Frittenöl nehme (fragen Sie lieber nicht, warum ich ein so spezifisches Beispiel wähle), schmeckt das Ergebnis natürlich – ungewöhnlich – aber das liegt nicht am Rezept, sondern an meiner Unfähigkeit, die beiden Packungen auseinanderzuhalten.
Viel öfter jedoch stelle ich fest, dass weder die Mathematik, noch der Algorithmus, noch dessen Implementierung kompromittiert sind, sodern dass einfach irgendein Bacherlorstudent der IT-Sicherheit ein trojanisches Pferd auf einem Testlaptop installieren und damit Bildschirmfotos anfertigen konnte. Meine Antwort auf solche Angriffszenarien lautet immer gleich: Wenn du davon ausgehen musst, dass auf deinem Rechner Spionagesoftware läuft, ist dein Hauptproblem nicht, wie du deine verschlüsselten Mails liest oder deine Downloads verifizierst. Dein Hauptproblem lautet, dass du gerade kein benutzbares System hast und du die verseuchte Maschine komplett neu aufsetzen musst. Ich frage mich, was in Köpfen von Menschen vorgeht, die argumentieren: “Och jo, mein Rechner liest meine Mails mit, zeichnet Telefonate, Videokonferenzen, Chats und Messengernachrichten auf und registriert jeden meiner Tastenanschläge, aber um mal schnell ein Programm zu prüfen, dessen Besitz mich meinen Job, im Extremfall auch mehrere Jahre Gefängnis kosten kann, reicht es aus.” Ich möchte niemanden bevormunden, aber mein Bedrohungszenario sieht anders aus.
Fazit
Es ist eine gute Sitte, Downloads zu prüfen, und gerade bei erhöhten Sicherheitsanforderungen sollten sich die Betroffenen ihrer Risiken bewusst sein. Wenn Freiheit, Gesundheit oder gar mein Überleben von der Integrität meiner Geräte abhängen, sollte ich die Zeit investieren, zu erlernen, wie ich der Gefahr untergeschobenen Schadcodes begegne. Das Gewicht, welches in der Cryptopartyszene stellenweise hierauf gelegt wird, finde ich hingegen übertrieben. Im Gegenteil – es schreckt nur unnötig ab. Ich habe in den letzten zehn Jahren hunderte, eher tausende Installationen betreut. Ich habe Signal-, Threema-, OMEMO-, Matrix-, Briar- sowie PGP-Keys und bei Bedarf auch Dowloads geprüft. Nicht einmal stieß ich dabei auf Unstimmigkeiten. Laien sind im Netz vielen Bedrohungen ausgesetzt. Manipulierte Downloads ordne ich hier weiter hinten ein.
Oh My Root 