Liquidizer/BPT11.1/Attacke

Attacke auf den Liquidizer

Bei der Liquidizerinstanz, die zur Vorbereitung auf den BPT11.1 eingesetzt wurde, kam es zu einer behaupteten Attacke. Angeblich wurden mittels einer brute-force Attacke zahlreiche Accounts geöffnet. Tatsächlich kam es zu einigen Anomalien, die durch einen derartigen Angriff hätten ausgelöst werden können. Eine quantitative Analyse des Einbruchs folgt.

Update: Vermutlich gab es keine Attacke auf den Liquidizer selbst. Möglicherweise wurden Email-Accounts geknackt oder es kam zu einer koordinierten Erzeugung von Ergebnisartefakten.

Zwar wurden mir die nachfolgenden Details der Attacke ausführlich berichtet. Da es mir aber nicht gelingt diese zu reproduzieren muss man wohl von einer sozialen statt einer technischen Attacke ausgehen.

Bekanntgabe des Einbruchs

Der Einbruch wurde am Samstag nachmittag mitgeteilt. Da die Beschreibung der Attacke sehr detailiert war und von Leuten übermittelt wurde, die sich ausgesprochen gut mit Serversicherheit auskennen, musste man sofort davon ausgehen, dass es tatsächlich eine solche Attacke gab.

Hier ist die Erklärung der Attacke auf dem Parteitag als Video

Art des Einbruchs

Der Liquidizer wurden zwei Schwächen vorgeworfen, die es Angreifern hätte ermöglichen können das System zu manipulieren. Bei der ersten handelt sich um eine brute-force Attacke, die mit hoher Wahrscheinlichkeit Zugangscodes knacken soll. Die zweite Lücke soll SQL code injections erlaubt haben. Beide Angriffe wurden behauptet und konnten bisher nicht reproduziert werden.

Brute-Force Attacke

Bei der Generierung der Invite Codes hatte ich mich zu sehr auf Google verlassen und folgenden Befehl zur Generierung verwendet:

cat /dev/urandom | tr -dc "a-zA-Z0-9" | fold -w 20 | head -n 12000

Dies ist in gewisser Weise ein Anfängerfehler, der mir eigentlich nicht hätte passieren dürfen. Ich hatte das so rausgegoogled ohne es nochmal zu überprüfen. Der richtige Zufallszahlengenerator lautet natürlich /dev/random. Das hätte zwar wesentlich länger gebraucht, hätte aber zufällige Ereignisse wie Mausbewegungen etc. mit einfließen lassen.

Hinweis Gerade schaute ich nochmal in meine .history. Tatsächlich benutzte ich urandom. Wie man sieht bin ich da kein Experte. Die Attake ist extrem mühsam. Eine geringe Anzahl von geknackten Accounts pro Tag wäre konsistent mit den Auffälligkeiten im Ergebnis.

Diese Passage ist in doppelter Hinsicht falsch. Zum einen ist urandom der "schnelle" PRNG. Zum Anderen sehe ich selbst bei der Verwendung eines PRNG mit minimalem zufälligen Seed keine sinnvolle Möglichkeit dadurch den Suchraum einzuschränken. Schon garnicht wenn ein Großteil der Bytes aus dem Strom verworfen wurden. Bei den bisher vorliegenden Informationen würde ich es ausschliessen dass über diese Lücke ein Angriff erfolgte (eigentlich ist es nicht mal eine). --eckes

Ich schließe mich an; wenn das tatsächlich mit dieser Befehlszeile (ob jetzt random oder urandom) erzeugt wurde, möchte ich funktionierenden Proof-of-Concept-Code sehen, ehe ich das glaube. Ich halte es inzwischen für möglich, dass der wirkliche Angriff darin bestand, zu behaupten, es gäbe einen Angriff, und so die Ergebnisse wertlos zu machen, ohne das eine tatsächliche Manipulation vorgelegen haben muss. Wichtig ist jetzt herauszufinden, ob die SQL-Lücke tatsächlich vorhanden war oder nicht, und falls ja, ob sie ausgenutzt wurde. --Jan

Die Verwendung von urandom war hier tatsächlich nicht das Problem. Fies und hinterhältig hat hier das Geburtstagsparadoxon zugeschlagen. Die Wahrscheinlichkeit, dass ein zufällig generierter 20 Zeichen langer String aus dem vorgegebenen Alphabet mit 62 Buchstaben mit einem der generierten 12000 Invitecodes übereinstimmt auszurechnen, überlasse ich an dieser Stelle dem geneigten Leser. Brute Force war jedoch relativ einfach möglich, da eben nicht ein bestimmter User angegriffen wurde, sondern eine Masse von 12000 Piraten. Der Invitecode mit 20 Zeichen war dementsprechend viel zu kurz oder hätte weiterer Maßnahmen zur Absicherung bedurft. --Gimli

Der geneigte Leser, der an diese Möglichkeit ebenfalls gedacht hatte, sagt: Statt 1/(62^20), was einer Sicherheit von ca. 119 Bit entspricht, "nur" noch 12000/(62^20) = 12000/704423425546998022968330264616370176 =~ 1/58701952128916501914027522051364, was einer Sicherheit von ca. 105 Bit entspricht. Mit anderen Worten: Nein, ich glaube nicht, dass das Geburtstagsparadoxon hier relevant ist. Es wird nur relevant, wenn jedes mal, wenn ein Token probiert wird (eine Person den Raum betritt) die Anzahl der gültigen Token (vorhandenen Geburtstage) wächst. AFAIK würde das die Anzahl der für einen Treffer durchschnitlich nötigen Versuche "Wurzeln", was einer Halbierung der "Bitstärke" entspricht. Selbst in dem Fall: Einen pro Tag gleich mehrfach erfolgreichen Online-Bruteforceangriff auf etwas mit immer noch > 55 Bit Sicherheit würde ich gerne sehen. Tipp: Ein Offline-Angriff auf DES (56 Bit) dauert Tage - mit Spezialhardware. --Jan

OK, sehe ich ein. Selbst wenn das Geburtstagsparadox hier ziehen würde, wären bei Wörtern mit 20 Zeichen für eine erfolgreiche Kollision mit Wahscheinlichkeit 0,5 immer noch etwa 10^18 Versuche notwendig. Das entspräche immer noch ~60 Bit und wäre somit jenseits von praktikabel und um Faktor 10^12 von den 6 Mio weg. --Gimli

SQL Code-Injection

Eine SQL Code Injection wurde behauptet, aber vermutlich nie durchgeführt. Wie mir mitgeteilt wurde bestand die Lücke in der "Suchfunktion". Die "Suchfunktion" arbeitet aber über einen lokal aufgebauten Index. Die Analyse hatte ergeben, dass es keine Möglichkeit gab Freitext an ein SQL-Statement zu übermitteln. Es handelt sich hier vermutlich um einen Fake.

Diese Attacke ist eine der gefährlichsten überhaupt, denn sie erlaubt beliebige Manipulationen der Datenbasis. Um das Risiko zu vermindern, wurde im Liquidizer keine Zeile SQL-Code geschrieben sondern ausschließlich auf ein Mapper-Framework gesetzt. Dieses Mapper Framework ist bestandteil von Liftweb und unterlief zahlreichen Sicherheitsprüfungen. Eine Injection ist hier extrem unwahrscheinlich

Dieses Framework führt dazu, das Befehle wie

Vote.findAll(By(Vote.FIELD, value))

intern umgesetzt wird zu

SELECT * FROM vote WHERE FIELD=value.

Wenn nun "value" einen Wert enthält, der von der Datenbank als Befehl verstanden wird, dann kann mit diesem Wert eine beliebige Datenmanipulation vorgenommen werden. Eigentlich sollte das Mapperframework dies verhindern und wird ja genau zu diesem Zweck eingesetzt.

Analyse der Manipulation

Die folgende Analyse zeigt, welche Auswirkung die Brute-Force Attacke in den öffentlich einsehbaren Datensätzen hinterlassen hat. Durch die (behauptete) Möglichkeit beliebigen SQL-Code einzuschleusen kann man zwar keinerlei sichere Auskunft geben, aber es entstanden eine Reihe von Anomalien in den Datensätzen, die zu einem konsistenen Bild zusammengesetzt werden können:

Media:Liquidizer BPT111 attack.pdf

Seite 1

Die erste Seite zeigt einen typischen zeitlichen Verlauf einer Abstimmungshistorie. Es sind keine Anzeichen für eine Manipulation vorhanden. Zu Beginn der Abstimmung wird der Großteil der Stimmgewichte gesetzt. Das Ergebnis stabilisiert sich sehr rasch. Danach sorgen nur noch einige Taktierer für minimale Bewegungen.

Rechts sieht man die Verteilung der Stimmgewichte. Beim Liquidizer vergibt man seine Stimme nicht mit Ja und Nein, sondern verteilt ein Stimmgewicht auf wichtige und unwichtige Fragen. Normalerweise dient das Histogramm dazu um die Umstrittenheit eines Themas beurteilen zu können. Bei Kontroversen Themen werden sowohl starke Zustimmungen als auch starke Ablehnungen am äußeren Rand der Verteilung sichtbar. Bis auf gelegentliche Anstöße am Rand ergibt sich aber immer die Normalverteilung, sobald viele Leute an der Umfrage beteiligt sind.

Seite 2

Die Hacker waren mittels der Brute force Attacke, oder durch Nutzung mehrer Accounts, in der Lage eine bestimmte Anzahl an Accounts pro Zeiteinheit zu öffnen. Diese geöffneten Accounts, zu denen vermutlich sowohl existente als auch noch unregistierte zählten, wurden benutzt um zufällig bei zufällig ausgewählten Themen Stimmen hinzuzufügen.

Wie man an der Grafik sehen kann ergab sich unter anderen bei den drei Anträgen PA002, PA029, und X002 eine klar erkennbare Trendlinie, die darauf hindeutet, dass die Anzahl der pro Zeit abgegebenen Stimmen ungefähr konstant war und mit einem abgebenen Stimmgewicht von -5 Stimmeinheiten pro Tag zu buche schlug.

Auch kann man erkennen, dass die Parameter zur Bestimmung der zufälligen Stimmabgaben während der Attacke verändert wurden. Sowohl am Dienstag als auch am Donnerstag wechselte das Ziel der Attacke. Man kann klar sehen wie der Einfluss der Manipulation bei einem Antrag endet und sich in der selben Weise bei einem anderen Antrag fortsetzt.

Seite 3

Als nächstes wollen wir eine Abschätzung über die Anzahl der gehackten Accounts abgeben. Mit dem PA022 haben wir einen Antrag der eine starke Beteiligung gleich nach Versenden der Invite-Codes aufwies. Auch hier zeigt sich wieder die über die Zeit konstante Manipulation. Offensichtlich war dieser Antrag über 8 Tage ein Ziel der Attacke. Diese Attacke hatte zu einer Ergebniserhöhung von 10 Stimmeinheiten geführt.

Auch hier zeigt sich wieder, dass die Angreifer ihre Stimmgewichte zwar randomisiert abgaben, aber dies in einer menschen-untypischen Verteilung taten. Das Histogram zeigt keine Normalverteilung an. Die Abweichung zwischen einer Normalverteilung und der tatsächlich beobachteten, zeigt zusätzliche Stimmen mit Gewichten zwischen 0 und 0.2 an.

Eine grobe Daumenpeilung führt zu etwa 60 Stimmen mit einem Gewicht von etwa 0.1 und etwa 20 Stimmen mit einem Gewicht von etwa 0.2. Zusammengerechnet führt dies zu unserer Bekannten Zahl von plus 10 Stimmeinheiten. Das heißt die brute-force Attacke hatte bei diesem Antrag eine zusätzliche Stimmabgabe von ca. 80 Bots bewirkt, von denen jeder durchschnittlich 0.15 Stimmgewichte auf diese Frage abgab.

Seite 4

Eine Frage betrifft die Anonymität und die Bedeutung der Dateschutzerklärung bei dieser Analyse. Wir sehen beim Antrag PA051 dass es zwischen Dienstag Abend und Freitag früh eine auffällig starke Gegnerschaft gegen diesen Antrag gab. Da diese wieder zurückgezogen wurde, ist im Histogram nicht erkennbar, um welche Art von Anomalie es sich handelte.

Der Liquidizer respektiert die Datenhoheit der Teilnehmer wie versprochen. Ein Meinungsbild ist nur so lange gültig, wie die Beteiligten bereit sind diese Meinung zu vertreten. Sobald Beteiligte ihre Meinung ändern, oder nicht mehr bereit sind ihr Pseudonym hinter eine Forderung zu stellen, ist das Meinungsbild ungültig. Dies ist unabhängig davon, ob es vorher manipuliert war oder nicht. Dieser Ansicht kann man zustimmen oder man kann sie ablehnen. Wenig Sinn hat es jedoch über diese Frage in ihrer Abstrakten Form zu diskutieren. Jede Anwendung braucht das dazu gehörige Verfahren.

Seite 5

Im PA070 zeigt sich eine weitere Anomalie, die nicht eindeutig zugeordnet werden kann. Innerhalb des Montags kam es zu einer plötzlich starken anwachsenden Zustimmung. Diese Zustimmung wurde nicht zurückgezogen. Die Anomalie im Histogram zeigt, das es im wesentlichen 7 Piraten waren, die ihr gesamtes Gewicht auf diese Frage legten.

dies ist klar auf eine Mail (09.05.2011, 06:05 Uhr) an die Mailingliste der AG BGE zurückzuführen [1]

Es ist wieder eine philosophische Frage, die für jede Anwendung mal erwünschte und unerwünschte Effekte ergibt. Im Liquidizer können einige Piraten ihr gesamtes Gewicht auf diese Frage setzen um hier einen stärkeren Einfluss zu bewirken, wenn sie durch das begrenzte Stimmgewicht sich in anderen Fragen entsprechend zurückhalten und den Effekt auf einen Antrag begrenzen. Ob es sich hier also um 7 Piraten handelte, die sich abgesprochen haben um mehr Aufmerksamkeit auf ihr Thema zu lenken, oder ob es sich um eine Manipulation handelt kann man nicht mit Sicherheit sagen.

Dazu muss man auch nochmal betonen, dass jedes existierende Wahlsystem mit "Klüngeln", also eine abgesprochene Stimmabgabe, angreifbar ist. Der Liquidizer visualisiert ein solches Verhalten nur und macht es so transparent. Unabhängig von der Lücke, mag man kritisieren, dass die Transparenz ein solches Verhalten fördert. Wieder bitte ich darum diesen Effekt im Einzelfall zu bewerten. Alles hat Vor- und Nachteile.

Fazit

Mit der am 1. Tag des BPTs bekannt gegebenen Brute-Force-Attacke wurden vorwiegend stark deterministische Manipulationen vorgenommen, die man hätte rausrechnen können. Die am Sonntag früh zusätzlich aufgebrachte SQL-Code-Injection machte es rein theoretisch möglich jeden beliebigen Datensatz zu manipulieren und dabei auch die Zeitstempel zu fälschen. Es deutet jedoch im Moment nichts darauf hin, dass dies in großem Umfang stattgefunden hat.

Eigentlich sind die Visualisierungen dazu gedacht gewesen die Bewegungen und die Konflikte zu visualisieren. Diese Tools eigenen sich aber auch dazu Manipulationen sichtbar zu machen. Für diese Analyse war kein spezieller Zugriff auf die Datenbank nötig, alle verwendetet Daten waren sowieso öffentlich zugänglich. Zur Visualisierung wurden nur im Liquidizer integrierte Ansichten verwendet, ohne auf etwaig versteckte Information in einer Datenbank zu benötigen.

Der Schaden

Es gibt drei Arten von Schäden die diskutiert werden müssen: Unmittelbare Schäden durch die Kompromittierung von Daten, Realisierte Schäden für die politische Arbeit und hypothetische Schäden bei wiederholter Attacke.

Datenkompromittierung

Wenn es eine SQL-Injection gegeben haben sollte, dann gab zwei Arten von Daten, die im Liquidizer eingegeben werden konnten, ohne dass diese sowieso sofort öffentlich werden. Die erste davon ist die Emailadresse und die zweite ist das Passwort. Passwörter werden von dem verwendeten Webframework Liftweb nur als Hash auf die Festplatte gespeichert und im Hash verglichen. Ein Rückschluss auf das eigentliche Passwort ist vermutlich aufwendiger als eine direkte Attacke. Einige Piraten haben ihre Emailadresse in das System eingegeben. Dies war eigentlich nicht notwendig, da selbst im Falle eines Passwortverlustes die Einladungsmail zum erneuten Login berechtigt. Betroffen wäre also potentiell, wer in das Emailadress-Feld des Liquidizers etwas eingegeben hat, das er sonst unter allen Umständen geheim gehalten hätte. ;-)

Politische Arbeit

Von dem Angriff betroffen waren alle Piraten, die sich auf den BPT in der Erwartung vorbereitet haben, dass die Anträge in der Reihenfolge der Zustimmung im Liquidizer behandelt werden würden. Da die Anzahl der behandelten Anträge minimal war hielt sich der reale Schaden also in Grenzen.

Hypothetischer Schaden

Angenommen der Hackerangriff wäre nicht aufgedeckt worden, welcher Schaden hätte entstehen können? Es könnten Anträge behandelt worden sein, die eigentlich kaum Aussicht auf Erfolg hätten. Und es hätte sein können, dass als wichtig erachtete Anträge unter den Tisch gefallen wären.

Dieser Schaden kann nicht so groß sein, denn auch das Alex-Müller-Verfahren führt dazu, dass durch die Eingruppierung in beliebte oder unbeliebte Themenblöcke einzelne Anträge stark nach vorne oder nach hinten rutschen.

Eine stark manipulierte Antragsreihenfolge wäre auch schnell aufgefallen, wenn die reale Zustimmung zu den Anträgen überhaupt nicht mit den Ergebnissen des Liquidizer übereingestimmt hätte. Ein GO-Antrag auf Änderung der Tagesordnung wäre und ist ja auch der Fall gewesen.

Schlusswort

Computer dürfen keine Entscheidungen treffen. Für mich sind dafür zwei Gründe gleich wichtig. Erstens, die Manipulierbarkeit der Ergebnisse. Zweitens, die fehlende Empathie Konflikte zu erkennen, die es ab und zu nötig werden lässt, von einem sturem Abzählen der Ja- und Nein-Stimmen abzuweichen.

Auch der Liquidizer wird niemals Entscheidungen treffen. Er kann nur dabei helfen, Konflikte schneller zu analysieren und Kompromisse auszuhandeln. Entscheidend dabei ist nichts weiter als die Nützlichkeit bei der Arbeit. Piraten können ihn benutzen, wenn sie wollen. Niemals darf irgendeines seiner Ergebnisse über die bewusste Entscheidungen einer menschlichen Person gestellt werden.

Nachtrag

Alle Datensätze im Liquidizer wurden inzwischen wie versprochen gelöscht.