Despotische Demokratie in der virtuellen Welt
Marc Ruef | 01.06.2009

Ich kann mich noch sehr gut an einen Penetration Test erinnern, den ich für ein internationales Finanzinstitut durchgeführt habe. Die in Indien eingekaufte Anwendung sollte firmenweit eingesetzt werden und dort die Kommunikation zwischen den Mitarbeitern erlauben. Quasi ein Social Network, wie man es von Xing oder Facebook her kennt, sollte aufgezogen werden. Das Hinzufügen von Kontakten war genauso erwünscht wie der unkomplizierte Austausch von Nachrichten.

Meine Aufgabe bestand nun darin, wenige Wochen vor dem offiziellen Going Live zu überprüfen, ob das System sicher umgesetzt wurde. Schliesslich sollten keine erweiterten Rechte erlangt oder anderweitige Manipulationen umgesetzt werden können. Ein klassischer Penetration Test als nicht-authentisierter und als authentisierter Benutzer wurde angesetzt.

Da geografisch weit voneinander entfernt arbeitende Benutzer an Projekten zusammenarbeiten, werden ebenfalls ein Grossteil der Kurzbesprechungen im virtuellen Raum abgehalten. Dort können dann in Echtzeit Screenshots ausgetauscht und Dokumente bereitgestellt werden. Soetwas ist halt eben schon nützlich, wenn man als Security Officer in Zürich mal wieder den Entwicklern in Mumbai auf die Füsse treten muss.

Mitunter bietet die Applikation ebenfalls eine Funktion an, im Rahmen einer solchen virtuellen Sitzung eine demokratische Abstimmung durchzuführen: Sodann stellt der Sitzungsleiter oder ein definierter Moderator die Frage in den Raum, wodurch die Sitzungsteilnehmer durch das Klick auf einen Button ihre Stimme mit Ja/Nein abgeben können. Sofort nach Durchführung dieser Abstimmung werden die Stimmen ausgezählt und das Resultat präsentiert. Selbst Entscheidungen grösserer Tragweite sollen auf derartige Weise unkompliziert verabschiedet werden.

Im Rahmen meiner Prüfung habe ich einen Fehler bei der Übermittlung der Stimmenabgabe gefunden. Der Client schickt nicht nur 1 (Ja) oder 0 (Nein) als eigentliche Stimme an den Server. Stattdessen wird zusätzlich die Client-ID selbst bestimmt und mitgeschickt. Hierbei handelt es sich um die Benutzer-ID des Anwenders, der seine Stimme abgibt. Da nun die Möglichkeit besteht, dass ein Client die ID eines anderen Clients vortäuschen kann, kann er im Rahmen der Abstimmung die Stimmen der anderen Benutzer vergeben. Gebe ich anstelle meiner ID 42 die ID 23 mit, kann ich für den Benutzer 23 abstimmen.

Die Folge davon ist, dass ein manipulierter Client noch vor der legitimen Stimmabgabe der echten Clients seine manipulativen Stimmeinlagen durchsetzen kann. Die als erstes beim Server angekommene Stimme wird gezählt. Der vorgetäuschte Client kommt von diesem Prozess nichts mit, denn bei ihm wird die abgegebene Stimme angezeigt, so wie er sie selbst vergeben hat. Schon doof, wenn Server und Client mit unterschiedlichen Daten arbeiten, oder? Der Client verzichtet darauf, die effektiv auf dem Server ausgezählten Stimmen mit den eigenen Daten im lokalen Cache zu vergleichen bzw. synchronisieren.

Es stellt sich die grosse Frage, warum gerade in diesem Punkt (und einigen anderen) der Client dafür verantwortlich ist, sich selber während einer etablierten Session nocheinmal auszuweisen. Dies ist ein typisches Anfängerproblem bzw. eine bekannte Nachlässigkeit von Entwicklern, dass sie halt eben gewisse Teile des Session-Handlings an den Client auslagern. Grundsätzlich muss man sich aber immer bewusst sein, dass man den Client nie gänzlich unter Kontrolle halten kann. Es wird immer Leute geben, die Zeit und Aufwand nicht scheuen, um clientseitig einen Vorteil erarbeiten zu können. In diesem Fall besteht der Vorteil darin, vermeintlich demokratische Entscheidungen manipulieren zu können. Welcher Despot träumt nicht von dieser Möglichkeit?