Quelltext der Seite Liquidizer/BPT11.1/Attacke

=Attacke auf den Liquidizer=

Bei der Liquidizerinstanz, die zur Vorbereitung auf den BPT11.1 eingesetzt wurde, konnte mittels eine brute-force Attacke  zahlreiche Accounts geöffnet werden. Eine quantitative Analyse des Einbruchs folgt.

==Art des Einbruchs==

Der Liquidizer wies zwei Schwächen auf, die es Angreifern ermöglichten das System zu manipulieren. Der erste ermöglichte es mittels einer brute-force Attacke mit hoher Wahrscheinlichkeit Zugangscodes zu knacken. Die zweite Lücke erlaubte SQL code injections und beruht auf einen Fehler in einer der verwendeten Libraries.

===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/random | 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. Bei einer so großen Anzahl an Passwörtern reicht die Größe des Zufallszahlenraumes nicht aus um echte Zufallszahlen zu erzeugen. Als mindest Maßnahme hätte man /dev/urandom verwenden müssen. Das hätte zwar wesentlich länger gebraucht, hätte aber zufällige Ereignisse wie Mausbewegungen etc. mit einfließen lassen.

: 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). --[[Benutzer:Eckes|eckes]]

===SQL Code-Injection===

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 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. Ich werde den Fehler nochmal genauer untersuchen und weiterleiten.

==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 die 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 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'' [http://news.piratenpartei.de/showthread.php?tid=50046] 

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 [[Bundesparteitag 2011.1|BPT]]s 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===

Es 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.