Author Archives: Linus Neumann

Die Corona-Warn-App verliert den Anschluss

Update: Ein kürzerer und prägnanterer Artikel zu diesem Thema wurde bei heise.de als Gastbeitrag veröffentlicht: Alle reden von Clustern – nur die Corona-App nicht.

Seit dem Launch der Corona-Warn-App sind bald 4 Monate vergangen. In dieser Zeit haben wir viel über das Virus gelernt. Dieses Wissen muss nun auch in der App ankommen.

Zur Erinnerung: Die App soll dabei helfen, Risiko-Kontakte zu erfassen. Als Risiko-Kontakt gilt für die App: Abstand weniger als 1,5m; Dauer länger als 15min.

Leider ist es aber bei diesem einen Entscheidungskriterium geblieben. Inzwischen wurde – ohne große Überraschung – eine Reihe von Situationen erforscht, in denen die App nicht zuverlässsig funktioniert.

Messprobleme

Als Paradebeispiel kann hier der öffentliche Nahverkehr gelten: Die “Metallröhre”, in der die Menschen sitzen, führt zu allerhand Reflektionen und Signalstörungen – und schließlich zu keinerlei korrekten Alarmierungen. Update: An der Studie werden methodische Fehler bemängelt, aber auch eine korrekt funktionierende App würde der Bahn-Situation nicht vollkommen gerecht.

Das ist besonders verhängnisvoll, weil die App in genau solchen Situationen, in denen Fremde sich nah kommen und nicht in der Lage sind, sich später zu alarmieren, für zusätzliche Abdeckung sorgen soll.

So hat die Physik dem Bluetooth-Ansatz erwartbare und auch vorher schon bekannte Grenzen gesetzt. In der Gastronomie zum Beispiel gilt unter anderem deshalb die Pflicht zur manuellen Erfassung.

Der Abstand ist nicht das Maß aller Dinge

Doch selbst wenn die Abstandsmessung perfekt wäre, würde sie dem Stand der Wissenschaft nicht gerecht: Zwei gemeinsame Stunden in einem stickigen kleinen Kellerraum mit großzügigem Abstand von drei Metern sind riskanter zu bewerten, als dreißig Minuten an der frischen Luft, bei einem Abstand von 1,50m. Die App kann den Unterschied aber nicht feststellen.

Dieser Effekt wird besonders anschaulich, wenn wir uns eine alltägliche Konferenz-Situation mit 8 Personen in einem Raum vorstellen: Maximal 2 Anwesende werden im Risikobereich von 1,50m Entfernung sein können. Wären wir als Anwesende zufrieden, deshalb keine schnelle Warnung zu erhalten?

Für Contact Tracing in der Gastronomie gibt es bisher keine akzeptable Lösung

Mitglieder des CCC haben in verschiedenen digitalen Contact-Tracing-Lösungen für die Gastronomie Schwachstellen gefunden. Die Systeme wurden oft mit der heißen Nadel gestrickt und setzten auf zentrale Erfassung.

Als sinnvolle Alternative riet ich in dem Zusammenhang zur manuellen Erfassung per Zettel. Daraufhin meldete sich eine Vielzahl an Gastronominnen bei mir, die unter den Problemen des Ansatzes litten:

  1. Viele Besucherinnen geben falsche Daten an
  2. Einige Besucherinnen gehen lieber in Lokalitäten, die es mit der Erfassung nicht so genau nehmen
  3. Oft sind die Zettel schwer leserlich
  4. Die Anzahl der Zettel kann schnell in den Bereich mehrerer hundert gehen – pro Tag
  5. Die Alarmierung jeder einzelnen Person ist mühsam und zeitaufwändig – das wiederum führt zu massiven Verzögerungen

Mit anderen Worten: Das Zettel-System scheitert an den Anforderungen der Praxis.

Es fehlt der Datentyp „Zusammenkunft“

Die beiden Beispiele Restaurantbesuch und Konferenz haben etwas gemeinsam: Sie bezeichnen die Zusammenkunft mehrerer Personen an einem Ort für einen Zeitraum. Welcher Ort das genau ist, und welche Personen genau anwesend waren, ist dabei unerheblich. Eine zentrale Erfassung verbietet sich also.

Die Corona-Warn-App kann bisher nur Abstände zwischen einzelnen Personen erfassen. Was fehlt, ist der Datentyp der Zusammenkunft. Letzte Woche habe ich einen datenschutzkonformen Ansatz dafür mit Tim Pritlove in unserem Podcast Logbuch:Netzpolitik umrissen. Nahezu zeitgleich haben Wouter Lueks, Seda Gürses, Michael Veale, Edouard Bugnion, Marcel Salathé und Carmela Troncoso ein Whitepaper veröffentlicht, das den Ansatz sauber ausformuliert.

Dezentrales Presence Tracing

Das System ist so simpel, wie datensparsam: Wie schon beim Contact Tracing gibt es keine zentrale Datensammlung darüber wer wen wann wo getroffen hat. Die Information, dass eine Person Teil einer Zusammenkunft war, wird ausschließlich auf ihrem eigenen Gerät gespeichert. Die Alarmierung erfolgt analog zum bisherigen Ansatz der CWA durch Veröffentlichung eines Codes, der für die restliche Öffentlichkeit ohne Aussage ist.

Im Folgenden spiele ich den Ablauf beispielhaft für ein konspiratives Meeting einer Gruppe von Wirecard-Managern durch – der Ablauf für ein Restaurant wäre analog.

  1. Die Zusammenkunft wird in der Corona-Warn-App angelegt. Die „Gastgeberin“ erhält einen QR-Code, den sie den anderen Personen zeigen kann. Außerdem erhält sie den Schlüssel, der nötig ist, um die Personen im Anschluss zu alarmieren.
  2. Die anderen Anwesenden scannen den QR-Code mit ihrer App. Sie speichern damit den Code dieser Zusammenkunft auf Ihrem Gerät. Ebenso wird die Uhrzeit der Anwesenheit festgehalten.
  3. Im Fall einer notwendigen Alarmierung wird der Code der Zusammenkunft (optional zusammen mit dem Risiko-behafteten Zeitraum) veröffentlicht.
  4. Wie schon beim Contact Tracing werden von der App alle veröffentlichten Codes heruntergeladen und mit den lokalen Daten abgeglichen.

In der Gastronomie könnte das Verfahren alternativ zur papierbasierten Erfassung angeboten werden. Demgegenüber hätte es nur Vorteile: eine schnelle Alarmierung ist möglich, eine zentrale Datensammlung wird vermieden, Besucherinnen müssen keine persönlichen Daten angeben. Die 10 Prüfsteine für die Beurteilung von „Contact Tracing“-Apps gelten selbstverständlich weiterhin, sind nicht verhandelbar und können von diesem Ansatz bei sauberer Umsetzung erfüllt werden.

Weiterentwicklungen wie diese sollten bei einer 20-Mio-Euro-App nicht aus der Community kommen müssen, sondern aktiv von Telekom und SAP vorangetrieben werden.

Endlich Durchsuchungen bei Gamma/FinFisher

Gamma/FinFisher stellt Staatstrojaner her – Schadsoftware, die von Geheimdiensten und Strafverfolgungsbehörden eingesetzt wird. Der Staat hackt seine Bürger – in Demokratien ist das ein heiß diskutiertes Thema. Zuletzt habe ich 2017 dazu als Sachverständiger im Rechtsausschuss des Bundestags Auskunft gegeben: Risiken für die innere Sicherheit beim Einsatz von Schadsoftware in der Strafverfolgung.

Einsatz gegen Oppositionelle

In Diktaturen wird weniger diskutiert, sondern einfach gemacht. Entsprechend häufen sich seit Jahren die Hinweise, dass Gamma/FinFisher in Staaten den Schwerpunkt seiner Kundschaft hat, die nicht für ihre Demokratien bekannt sind: In Ländern wie Bahrain, Ätiopien, Ägypten, und Türkei wurde die Software eingesetzt – natürlich nicht gegen Kriminelle, sondern gegen politische und journalistische Opposition.

Wie kann es sein, dass ein deutsches Unternehmen “Cyberwaffen” an Diktaturen der Welt exportiert? Unterliegen solche Produkte keinen Exportbeschränkungen?
Doch. Natürlich tun sie das.

Exportbeschränkungen

Und genau diese Exportbeschränkungen scheinen umgangen worden zu sein, als die Software im Sommer 2017 gegen die türkische Oppositionsbewegung eingesetzt wurde. Der Nachweis gestaltet sich aber schwierig: Die Exportrestriktionen galten erst ab dem 18. Juli 2015. Wurde die in der Türkei 2017 eingesetzte Schadsoftware vor oder nach diesem Datum geliefert? Und lässt sich überhaupt nachweisen, dass das Sample von FinFisher stammt?

Beitrag des CCC

Der Frage nach Herkunft und Lieferzeitpunkt haben Thorsten Schröder und ich uns letztes Jahr gewidmet. Durch die Analyse von insgesamt 28 FinFisher-Samples konnten wir eine Kontinuität aufzeigen, in die sich das Sample einfügt. Außerdem konnten wir das Herstellungsdatum bestimmen: Es liegt eindeutig nach dem Inkrafttreten der Exportrestriktionen. Ergänzend zu wichtigen Ergebnissen anderer Forscher wurde unsere Analyse Teil der Grundlage einer Strafanzeige gegen das Unternehmen.

Unsere Analyse “Evolution einer privatwirtschaftlichen Schadsoftware für staatliche Akteure” umfasst 60 Seiten. Die in dem Rahmen gebauten Tools und die Rohdaten (inklusive aller Samples) haben wir auf Github veröffentlicht. Auf dem 36C3 hat Thorsten die Ergebnisse in einem Vortrag präsentiert.

Durchsuchungen

Nachdem die Strafanzeige gestellt war, passierte lange Zeit nichts. Doch gestern wurde bekannt, dass in der vergangenen Woche 15 Wohn- und Geschäftsräume im In- und Ausland vom Zollkriminalamt durchsucht wurden.
Wow!

Durchsuchungen in diesem Umfang finden nicht einfach mal so statt. Der Verdacht scheint sich also tatsächlich zu erhärten. Ein Firmengeflecht aus Briefkästen in Malaysia, Bulgarien, Pakistan und Dubai wird nun untersucht. Verwaltet werden die Unternehmen zentral aus München. Wer Exportrestriktionen umgehen will, könnte mit einem solchen Netzwerk ganz gut “Hütchen spielen.”

Zum jetzigen Zeitpunkt bleibt offen, ob der ominöse “Anwalt aus München” einen juristisch wasserdichten Weg gefunden hat, die gesetzlichen Vorgaben zu umgehen. Wenn das der Fall sein sollte, muss die Gesetzgeberin nachbessern.

Weil Software nicht materiell gebunden ist, lässt sie sich über das Internet leicht in alle Länder der Welt “liefern” – meine persönliche Vermutung ist, dass die Durchsuchungen den Nachweis liefern sollen, dass an den verschiedenen Standorten mit der gleichen Code-Basis agiert wird.

Deutschland ist und bleibt stolze Kundin

Dass Gamma/FinFisher ein äußerst zweifelhaftes Unternehmen ist, wird von niemandem mehr infrage gestellt – wahrscheinlich noch nicht einmal von den ebenfalls zweifelhaften Kundinnen.

Deutsche Strafverfolgungsbehörden wissen seit 2012, dass der Funktionsumfang der Software gegen deutsches Recht verstößt. Nun kommt auch noch der Verdacht der kriminellen Umgehung von Exportrestriktionen hinzu. Und erst vor wenigen Wochen wies Amnesty International erneut den Einsatz der Software in Ägypten nach – wie so oft, gegen Oppositionelle.

Dennoch: Das Bundeskriminalamt und die Berliner Polizei sind stolze Kundinnen des Unternehmens. Wann hört Deutschland endlich auf, dieses Unternehmen auch noch mit zu finanzieren, statt dem grundrechtswidrigen, rechtswidrigen und demokratiefeindlichen Treiben endlich ein Ende zu setzen?


Acknowledgements:

Dass wir überhaupt so viel über die Machenschaften des dunklen Geflechts mit Hauptquartier in München wissen, vielen internationalen Forscherinnen, Whistleblowern, Hackern und Journalistinnen zu verdanken:

Weitere Gedanken zum Contact Tracing mit “Corona Apps”

Updates:

Logbuch:Netzpolitik

In der neuen Folge unseres Podcasts Logbuch:Netzpolitik habe ich unter anderem mit einer Reihe an Missverständnissen zu den Möglichkeiten und Grenzen sogenannter “Corona Apps” auseinander gesetzt.

Zur vollständigen Episode geht es hier: LNP339 Die Fantasie kennt keine Grenzen beim Setzen von Grenzen.

Logbuch:Netzpolitik ist werbefrei, kostenlos und kann überall abonniert werden, wo es Podcasts gibt.

Deutschlandfunk: Computer und Kommunikation

In der aktuellen Folge von Computer und Kommunikation wird der technische Stand von Entwicklung und Diskussion sehr gut von Peter Welchering und Manfred Kloiber zusammengefasst:

Apps im Kampf gegen COVID-19 und ihre Risiken

„Corona-Apps“: Sinn und Unsinn von Tracking

Updates:

Über eine technisch gestützte Rückverfolgung von Corona-Infektionen werden zur Zeit verschiedene Debatten heiß geführt. Es begann mit der Weitergabe von Bewegungsdaten durch Mobilfunkanbieter an das Robert-Koch-Institut und natürlich ließen auch Gesetzesänderungen zum vollumfänglichen Location-Tracking nicht lang auf sich warten.

Im Folgenden erkläre ich, warum Location-Tracking völlig ungeeignet ist, und welche Methoden stattdessen zielführend sein könnten. Wichtig ist immer, Sinn und Ziel einer solchen App nicht aus den Augen zu verlieren:

Wenn bei einer Person zum Zeitpunkt t eine Infektion festgestellt wird, soll sie in der Lage sein, ihre Kontakte der letzen t–14 Tage darüber zu informieren. Nicht mehr, aber auch nicht weniger. Primäres Ziel sollte also sein, die Kontakte reliabel zu erfassen.

Datentypen

In der Debatte werden die Begriffe „Standortdaten“, „Bewegungsdaten“ und „Kontaktdaten“ wild gemischt. Zunächst müssen wir also klären, wovon überhaupt die Rede ist.

1. Standortdaten: Person x war zum Zeitpunkt t an Ort A

Problem 1: Die räumliche Auflösung via GPS ist ziemlich ungenau.
Ob sich zwei Personen nah genug gekommen sind, um einander zu infizieren, oder ob sie mehrere Meter voneinander entfernt waren, lässt sich anhand der Genauigkeit von GPS einfach nicht entscheiden – eine Unmenge an false positives wäre die Folge.

Problem 2: Da wir uns bewegen, entsteht natürlich eine sehr lange Liste für jede Person. Die Länge der Liste richtet sich dabei nach der Frequenz der Erfassung. Noch dazu sind die Daten personengebunden. Da wir uns zurzeit weitestgehend isolieren, wäre der größte Teil der erfassten Daten zudem noch absolut irrelevant!

Fazit: Standortdaten sind aufgrund ihrer Ungenauigkeit schlichtweg ungeeignet. Schon das allein disqualifiziert sie, so dass wir die immensen Datenschutz- und Grundrechtsverletzungen gar nicht erst zu diskutieren brauchen.

2. Bewegungsdaten: In Zeitraum Δt haben sich n Personen von Bereich A in Bereich B bewegt.

Bewegungsdaten sind also im Gegensatz zu Standortdaten räumlich und zeitlich geringer aufgelöst. Sie sollten darüber hinaus über mehrere Personen aggregiert sein, so das die Identifikation der Bewegungen einzelner nicht möglich sein sollte.

Anwendungszweck: Diese Art Daten eignen sich gut zur Messung der Effektivität von Maßnahmen zur Senkung der Mobilität.Das ist im weitesten Sinne das, was von den Mobilfunknetzen an das RKI gegeben wird – ein Anspruch also, für den es eine seit Jahren existierende Lösung gibt. Diese Lösung wurde kommerziell übrigens allen angeboten, die bereit sind, dafür zu bezahlen. Das RKI ist in der Reihe der Abnehmer vermutlich noch der am wenigsten problematische.

Problem 1: Je nach zeitlicher und räumlicher Auflösung sind diese Daten ggf. von einer böswilligen Anwenderin durchaus de-anonymisierbar. 

Problem 2: Für das Identifizieren von Kontakten sind die Daten nicht geeignet.

3. Kontaktdaten: Person a und Person b hatten zum Zeitpunkt t für einen Zeitraum länger als Δt Kontakt.

Dies ist der einzige relevante Messwert, um den es hier wirklich gehen soll. Wo dieser Kontakt stattgefunden hat, oder an welchem Ort a und b davor und danach waren, ist absolut uninteressant. Wieso sollte das also überhaupt erfasst werden?

Halten wir fest: alles, was erfasst werden muss, sind Kontaktdaten.

Datenspeicherung

Viele vorgeschlagene Konzepte sehen eine zentrale Speicherung von Standort- oder Bewegungsdaten vor. Hierbei würde eine Unmenge an irrelevanten Daten (kein Kontakt) gespeichert. Darüber hinaus ist eine zentrale Datenhaltung aus offensichtlichen Gründen abzulehnen: IANAL; aber nicht nur unterliegen wir hier dem Bereich der DSGVO, sondern auch den besonderen Anforderungen für sensible Gesundheitsdaten.

Die offensichtliche Anforderung ist also, sämtliche Daten dezentral und anonym vorzuhalten – und zwar auf eine Weise anonymisiert, die auch keine Deanonymisierung zulässt.

Es ergeben sich folgende Anforderungen:

  • Dezentralität: Jede Person sammelt nur Daten für sich selbst. Diese werden nicht automatisiert weitergegeben.
  • Anonymität:
    • Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung anderer.
    • Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung der Person selbst.
  • Datensparsamkeit: Nur im Infektionsfall kann eine Person ihre Daten weitergeben. Auch in diesem Fall geben die Daten aber weder die Identität der infizierten Person, noch die Identität ihrer Kontaktpersonen preis.

Als Mitglied der Jury des Hackathons „Wir vs Virus“ hatte ich die Freude, eine Reihe von Einreichungen zu begutachten, die eine kluge Lösung gefunden haben, diese Anforderungen zu vereinen. Zur Veranschaulichung stark vereinfacht möchte ich sie hier einmal grob darstellen:

  1. Mein Handy sendet in regelmäßigen Abständen mittels Bluetooth Low Energy Beacon einen zufälligen Code aus. Dieser Code ändert sich regelmäßig, bspw. alle 30 Minuten.
  2. Empfängt mein Handy den Code eines anderen Handys, wird anhand der Signalstärke der Abstand geschätzt. Ist der Abstand gering genug, speichert mein Handy diesen Code. Da sich der Code der anderen Person bald wieder ändern wird, hat mein Handy keine personengebundenen Daten erfasst und ist auch nicht in der Lage, die andere Person längere Zeit zu tracken.
  3. Werde ich als infiziert diagnostiziert, veröffentliche ich an zentraler Stelle alle Codes, die ich je gesendet habe auf einem zentralen Server. Hier werden auch die Codes von allen anderen Menschen veröffentlicht, die diagnostiziert wurden.
  4. Alle anderen Nutzer laden regelmäßig die veröffentlichten als „infiziert“ markierten Codes herunter. Diese Codes sind ohne jede Aussage über Ort, Zeit oder Personen. Sie haben nur Informationswert für jene Personen, mit denen ich Kontakt hatte.
  5. Der Abgleich der veröffentlichten mit den lokal auf meinem Handy gespeicherten Codes ermöglicht das Berechnen meiner Exposition. Dabei ist es unerheblich, ob ich 10 Stunden mit einer infizierten Person verbracht habe, oder jeweils 20 halbe Stunden mit unterschiedlichen infizierten Personen. Selbst das kann aus den Daten nicht rekonstruiert werden.
  6. Auf dem zentralen Server befinden sich keinerlei Daten darüber, welche Personen infiziert sind, wo sie sich wann aufgehalten haben, oder welche Personen sie wo getroffen haben.

Trotzdem haben wir auf diese weise den Datensatz bester Qualität, weil genau nur unsere Kontakte aufgezeichnet wurden – jene Daten also, auf die es wirklich ankommt.

Elegante Lösungen

Diesen Anforderungen entsprechen folgende Einreichungen zum Hackathon „Wir vs. Virus“, die alle mittels Bluetooth ausgetauschte, zeitlich beschränkte Codes nutzen. Ich verlinke sie hier ohne Anspruch auf Vollständigkeit, weil ich nicht weiß ob ich alle Einreichungen zu diesem Thema reviewed habe:

Für Menschen ohne Smartphone würde sich mit leichten Abstrichen in eine QR-Code-Lösung anbieten, bei der die Privatsphäre der Personen zumindest gegenüber wohlmeinenden Kontakten sichergestellt werden könnte – natürlich fehlt dem QR-Code aber die Benachrichtigungsfunktion: Tracking Infection Awareness Alert (IAA)

Wir lernen also: Die Daten der höchsten Qualität und Aussagekraft lassen sich vollständig anonym und dezentral erfassen. Ein wunderschönes Beispiel, wie wir ohne zentralisierte Massenüberwachung sogar ein besseres Ergebnis bekommen – und dabei entspannt und frei weiterleben können, ohne der Corona-Krise gleich noch eine selbstverschuldete Grundrechtskrise folgen zu lassen.

Mein Lob, meine Anerkennung und mein Glückwunsch gilt den „Wir vs Virus“-Teams!

Der Teufel steckt im Detail

Natürlich muss aber auch angemerkt werden, dass nur minimale Änderungen ausreichen würden, die Anonymität oder Dezentralität zu zerstören. Beispielsweise, den Code nicht regelmäßig zu ändern, oder alle Codes immer zentral zu erfassen. Selbstverständlich kann so eine App ausschließlich auf freiwilliger Basis verbreitet werden. Wenn die hier skizzierten Anforderungen kompromisslos erfüllt sind, hätte ich aber keinerlei Bedenken, die App zu nutzen – und ich denke dass es vielen Menschen ähnlich ginge.

Medienberichte

In den Tagesthemen konnte ich gestern diese Gedanken zum Teil ausführen:

Continue reading

Hirne Hacken #36C3

Beim 36C3 habe ich einen Vortrag über menschliche Faktoren der IT-Sicherheit gehalten:

Die überwältigende Mehrheit der erfolgreichen Hacks in freier Wildbahn setzen auf menschliche Faktoren. Wie können wir Systeme und Interfaces gestalten, um diese Schwachstellen zu mindern?

Ob Ransomware oder Phishing, APT-Angriffe oder Stalking: Die am häufigsten ausgenutzte Schwachstelle ist der Mensch.

Ein Problem, das nur wenig Forschung tatsächlich angehen will. Stattdessen begnügen wir uns damit, den Usern Dummheit zu unterstellen und menschliche Faktoren der IT-Sicherheit “out of scope” zu sehen.

Der Vortrag wurde aufgezeichnet und ist bei YouTube und auf media.ccc.de verfügbar:

Der Vortrag kann unter diesem Link anonym bewertet werden.
Ausführlicheres Feedback und Anregungen nehme ich auch gern direkt entgegen.

Analyse des Staatstrojaners FinSpy #36C3

In den letzten Monaten haben Thorsten Schröder und ich endlich mal wieder ein kleines CCC-Projekt zusammen gemacht, das wir beim Congress endlich der Öffentlichkeit präsentieren konnten: Wir haben den Staatstrojaner Finspy in der Android-Version analysiert.

Anlass ist die Strafanzeige der Gesellschaft für Freiheitsrechte. Wie immer ist das Ganze ein bisschen eskaliert und am Ende haben wir nicht einen, sondern 28 Versionen des Staatstrojaners analysiert und die Samples natürlich auf Github veröffentlicht, um der Community weitere Analysen zu ermöglichen.

Der Fall ist politisch pikant, weil auch deutsche Strafverfolger FinSpy kaufen und einsetzen, während diese Schadsoftware aus völlig unerklärlichen Gründen immer wieder in autoritären Regimen beim Einsatz gegen demokratische Kräfte entdeckt wird. Die Zusammenhänge sind in diesem Tagesschau-Beitrag gut erklärt.

Tagesschau-Beitrag vom 28. Dezember 2019 (auch auf YouTube)

Es ist immer eine große Freude und Ehre, mit Thorsten zu arbeiten.
Ich freue mich, dass es sich gelohnt hat:

Thorsten hat die Ergebnisse beim 36C3 zusammen mit Ulf Buermeyer (Gesellschaft für Freiheitsrechte) präsentiert:

Pressespiegel (Auswahl)

Wann, wenn nicht wir* | Sicherheit in selbst-organisierenden Systemen

Wann, wenn nicht wir*” erscheint am 4. September 2019 im Verlag S. Fischer. Das Buch versammelt Fakten über bereits sichtbare Folgen der Klimakrise und ruft zum Handeln auf. Für alle nachvollziehbar, konkret und undogmatisch erklärt es, wie sich das Rebellieren organisieren lässt: Von der gewaltfreien Kommunikation über das Errichten von Straßenblockaden und die Vorbereitung anderer Protestaktionen bis hin zum Kochrezept für mehrere hundert Menschen.

Das Handbuch von, zu und für Extinction Rebellion ruft zu massenhaftem gewaltfreien zivilen Ungehorsam gegen die Klimakrise und das Massenaussterben auf. Ich habe einen kurzen Beitrag über sichere digitale Vernetzung beigesteuert:

Sicherheit in selbst-organisierenden Systemen

Neben dem Zusammenkommen in den Aktionen im öffentlichen Raum ist die digitale Kommunikation die Grundlage für unsere Vernetzung und Zusammenarbeit. Das Internet ist das perfekte Werkzeug für Überwachung, Kontrolle und Macht – und gleichzeitig das perfekte Werkzeug für ihr Gegenteil: Dezentrale Vernetzung, Befreiung und soziale Veränderung. Es liegt an uns, das befreiende Potenzial der Dezentralität auszuschöpfen, Ihre Schwächen zu kennen, und uns gegen zentralisierte Überwachung zu schützen.
Aus technischer und sozialer Sicht birgt aber auch die Dezentralität einige Risiken – insbesondere im Digitalen: Die größte technische Gefahr besteht in den massenhaften digitalen Spuren, die wir hinterlassen. Das größte soziale Risiko ist die Unterwanderung.

Continue reading

Hack und Back vom BND?

In der vergangenen Woche wurden erstmals die konkreten Pläne der Bundesregierung bekannt, in den Cyber-Krieg zu ziehen. Ich sehe in diesem Vorgehen 3 Kernprobleme:

  1. Spontanes Hacking auf Befehl geht nicht – ein Hack braucht lange Vorbereitung, im Zweifelsfall muss die Infiltration schon lange erfolgt sein, bevor der Befehl zur Sabotage ausgeführt wird.
  2. Ein Hack setzt bekannte Schwachstellen voraus – diese müssen geheim gehalten werden und auf allen Systemen ungepatcht sein. So werden wir alle einem Risiko ausgesetzt, auf das Wannacry nur ein Vorgeschmack war.
  3. Schadenabwehr durch Gegenangriff funktioniert nicht – Es fällt auch der Bundesregierung schwer, einen Fall zu konstruieren, in dem ein Gegenangriff zu signifikanter Schadenminderung oder gar -abwehr beigetragen hat oder hätte.

Von den 3 Problemen möchte die Bundesregierung nur dem ersten begegnen: Weil spontane Hacks nicht funktionieren, sollen die Offensiv-Kapazitäten beim BND angesiedelt werden. Der BND würde damit von der reinen Spionage zur Sabotage übergehen, von der NSA zur CIA werden. Begriffe wie “Hackback”, “Abwehr” oder “Verteidigung” sind dabei nicht zutreffend, weil die Infiltration der Zielsysteme bereits vorher erfolgt. In Logbuch:Netzpolitik Folge 248 haben wir dafür den Begriff “Hack & Back” eingeführt.

Ausführlich haben wir das Thema mit Frank Rieger in “LNP272 Alles zerfragen” behandelt. In der aktuellen Folge von Logbuch:Netzpolitik gehen wir auf die aktuellen Entwicklungen ein. Teile meiner Kritik durfte ich bei Deutschlandfunk Nova und in der Tagesschau vertreten:

Tagesschau-Beitrag vom 29. Mai 2019 (auch auf YouTube)

Links:

Lehren aus den Doxing-Angriffen

Nach dem öffentlichen Bekanntwerden konnten Täter und Mittäter hinter den ausführlichen Datenveröffentlichungen im “Doxing-Adventskalender” sehr zügig dingfest gemacht werden. Nun ist es Zeit, daraus die richtigen Lehren zu ziehen.

War das ein Superhack?

Nein. Es ist auch nichts, worauf man stolz sein könnte.

  1. “Nur” 50 der 1.000 betroffenen Personen wurde wirklich gehackt – der Rest der Daten stammte aus diesen illegalen Zugriffen und vermutlich aus weiteren Recherchen.
  2. Das Vorgehen war simpel, hatte keine besondere technische Komponente und
  3. der Täter verstand es nicht, seine Spuren zu verwischen um sich nicht erwischen zu lassen.

Das bedeutet aber auch:

Continue reading

Menschliche Faktoren der IT-Sicherheit

Für die Ausgabe 11/12.2018 von Report Psychologie habe ich einen Beitrag über die menschlichen Faktoren beim Hacking beigesteuert:

Wenn Hacker Menschen hacken

»Unser System ist unhackbar«, hören wir diverse Hersteller von Software oder Hardware immer wieder betonen. Und immer und immer wieder werden sie eines Besseren belehrt, sobald Fachkundige mit gutartiger oder bösartiger Motivation diese Aussage auf die Probe stellen.
Wie aber funktioniert eigentlich dieses Hacken? In der Breite der Gesellschaft herrscht über diese Frage eine ausgeprägte Unkenntnis, in deren Schatten sich allerlei mythische Theorien breitmachen…

Ein PDF des Artikels gibt es hier zum Download.

Have you been wp-gdpr-compliance’d?

An ugly vulnerabilty in the wordpress plugin wp-gdpr-compliance was recently discovered and reported by Mikey Veenstra of wordfence. Please read his very comprehensive write-up of the vulnerability and its IOC right after updating to the latest version to be safe.

Since I was also using the plugin, this vulnerability was giving me a headache today. Based on wordfences report, I wrote a quick and dirty shellscript to search for indicators of compromise on the various wordpress hosts I am sadly administrating. As usual, please do not run the script without thouroughly checking und understanding what it does. You will likely need to modify constants and paths.

Also, please make sure you stay up to date and on top of things while other researchers discover more indicators of compromise and develop better detection techniques. Continue reading

Damit es der Russe(TM) nicht macht: CCC hackt die Bundestagswahl

Zusammen mit Thorsten Schröder und Martin Tschirsich habe ich mir in den letzten Wochen die zur Organisation,  Erfassung, Berechnung, grafischen Präsentation, Meldung und statistische Nachbereitung von Wahlen verwendete Software PC-Wahl angeschaut.

Dabei ist uns einer Reihe an Sicherheitslücken aufgefallen, die sich zu drei unterschiedlichen praktikablen Angriffszenarien auf die Bundestagswahl kombinieren lassen. Die Ergebnisse haben wir in einem 23-seitigen Bericht zusammengefasst und die im Rahmen der Analyse entwickelten Angriffe auf github veröffentlicht.

Darüber berichtet die ZEIT auf Papier und online darüber, ebenso wie Spiegel Online und netzpolitik.org. In Logbuch:Netzpolitik 228 berichten wir darüber hinaus ausführlich und in lockerer Atmosphäre von der Analyse.

„Es ist einfach nicht das richtige Bundestagswahljahrtausend, um in Fragen der IT-Sicherheit bei Wahlen ein Auge zuzudrücken“, sagte Linus Neumann. „Wirksame technische Schutzmaßnahmen sind teilweise seit Jahrzehnten verfügbar. Es ist nicht nachvollziehbar, warum diese keine Anwendung finden.“

 

Continue reading

Austellungseröffnung “Wahlcomputer” im Heinz-Nixdorf-Forum

Im Heinz-Nixdorf-Forum zu Paderborn wurde heute die Ausstellung “Helfer oder Fälscher – Computer im Wahleinsatz” eröffnet.

Zu diesem Auftakt habe ich keinen kurzen Vortrag über Wahlcomputer gehalten, in dem ich (hoffentlich) leicht verständlich gemacht habe, warum der Einsatz von Computern als Wahlgeräte eine ziemlich dumme Idee ist.

Abschließend nehme ich noch kurzen Bezug auf verbleibende Sorgen, wie DER RUSSE(TM) die Bundestagswahl 2017 – laut BSI – hacken könnte.

Eine Aufzeichnung gibt es hier, bei Vimeo und auch bei Youtube.

[embedyt] https://www.youtube.com/watch?v=eqk4oAeUu1U[/embedyt]

Zu Gast im SWR Forum zum Bundestagswahlkampf

Mit der Einflussnahme auf Wahlen beschäftige ich mich seit einem Jahr ausführlich.
Nicht nur im Logbuch:Netzpolitik behandeln wir das Thema regelmäßig – auch im Bundestag musste ich inzwischen mehrmals dazu Rede und Antwort stehen.

Am Mittwoch habe ich im SWR mit

  • Dr. Jeanette Hofmann, Professorin für Internetpolitik an der Freien Universität Berlin
  • Robert Heinrich, Wahlkampfmanager Bündnis90/Die Grünen

darüber diskutiert. Moderiert wurde die Sendung von Claus Heinrich.

Anzeigen bei Google, persönliche Tweets mit Hilfe von Big-Data, die Abwehr von Fake-News. Noch nie wurde in Deutschland von den Parteien so viel in digitale Medien investiert wie bei diesem Bundestags-Wahlkampf. Für die meisten Politiker heißt das experimentieren im “Neuland”. Lohnt sich der Aufwand? Welche Online-Strategien sind bei welchen Zielgruppen erfolgreich? Führt das “Like” bei Facebook tatsächlich zum Kreuz bei der Wahl? In den USA haben Hacker den Ausgang der Präsidentenwahl über sogenannte Social Bots beeinflusst. In Deutschland wollen alle Parteien auf diese Meinungsroboter verzichten. Reicht das aus, um den Wahlkampf im Netz vor Manipulation zu schützen?

Die Sendung gibt es hier auch direkt zum Download.