*36C3 Vorspanngeräusche*
Herald: Heute Abend geht es in diesem Saal über Staatstrojaner, also Trojaner, also
Schadsoftware im engeren Sinne, bloß halt nicht solche von Kriminellen, sondern
solche von Unternehmen, die das professionell mehr oder weniger legal
machen. Staatstrojaner sollte man gar nicht erst bauen, wenn man sie baut,
kommen sie in die falschen Hände. Wie das passiert und wie man dann unser
Rechtssystem und unsere Gerichte nutzen kann, um etwas dagegen zu tun auf dem
vernünftigen rechtsstaatlichen Weg, das erklärt uns unser Ulf Buermeyer, der in
vielen anderen Fällen auch schon Rechtsbeistand für Clubthemen geleistet
hat. Und Thorsten Schröder ist auch dabei. Oldschool Hacker, 20 Jahre dabei, 30 Jahre
weiß ich nicht. Und hat sich das angeschaut, was da in dieser Schadsoftware
von FinFisher eigentlich drinsteckt. Großen Applaus für Ulf Buermeyer und
Thorsten Schröder. *Applaus*
Ulf Buermeyer: Hi, schön, dass ihr da seid, herzlich willkommen!
Thorsten Schröder: Hallo, hallo. U: Ja, herzlich willkommen zu „FinFisher,
See You in Court!“ Falls es der eine oder andere kennt, eine amerikanische
Bürgerrechtsorganisation hat „See you in Court!“ mal zu Donald Trump gesagt, als er
illegal versucht hat, Immigration in die Vereinigten Staaten zu verhindern. Und wir
widmen uns genau dem umgekehrten Thema, nämlich der illegalen Auswanderung von
fieser Software. Und bevor wir dazu kommen, noch ein klitzekleiner historischer
Rückblick. Keine Sorge, das wird kein krasser Juratalk, dafür bürgt schon
Thorsten. T: Ich versuch’s.
U: Aber in diesem Talk geht es um ein weiteres Kapitel im Kampf gegen digitales
Ungeziefer, und zwar eine ganz besondere Form von digitalem Ungeziefer.
T: Staatstrojaner, die wir auch schon vor ein paar Jahren mal auf einem Kongress
bereits besprochen haben. Aber eben Software, die von Staaten eingesetzt
werden, gegen Kriminelle, gegen Oppositionelle und so weiter.
U: Thorsten hat schon gesagt, das ist ein Thema, das den Club und auch mich
persönlich schon seit Jahren beschäftigt. Das Foto zum Beispiel ist vom 25C3. Da gab
es nämlich eine gute Nachricht aus Karlsruhe zu feiern. Vielleicht erinnert
sich der eine oder andere noch daran. Das Bundesverfassungsgericht hatte 2008 ein
neues Grundrecht erfunden, nämlich das Grundrecht, das wir heute kennen als das
Computer Grundrecht oder, auf schlau, das Grundrecht auf Integrität und
Vertraulichkeit informationstechnischer Systeme. Eine Bezeichnung, auf die nur
Menschen kommen können, die viel zu lange Jura studiert haben. Jedenfalls hatten wir
damals, als Conz und ich diesen Talk gemacht haben, vor dem roten Vorhang
gehofft, dass dieses Grundrecht etwas ändern würde. Aber leider müssen wir
sagen … T: Tat es nicht. Wir haben 2011 einen
Staatstrojaner gefunden, der genau diese Rechte nicht eingehalten hat.
Möglicherweise war das zu dem Zeitpunkt bei diesen Entwicklern auch noch nicht
angekommen. Diesen Trojaner hatten wir einmal auf einer Festplatte in einem
braunen Umschlag zugetragen bekommen. Ja, den haben wir dann analysiert und einen
sehr ausführlichen Bericht auch dazu verfasst und einen Talk auf dem 28c3.
U: Hier sieht man das, Jugendbildnisse von Thorsten und mir.
T: Da war ich noch richtig jung, wie man sieht. Da habe ich auch das erste Mal mit
Ulf auf einer Bühne gestanden. Lustigerweise stehen wir nur auf der
Bühne, wenn’s um Staatstrojaner geht. U: Das ist auch derselbe schwarze Pulli
bei mir, glaube ich. Ich habe den extra nochmal gewaschen.
T: Ja, da haben wir den Staatstrojaner vorgestellt und nicht nur beschrieben,
sondern auch demonstrieren können, wie der gegen diese Grundrechte verstößt, indem er
einen Rechner in eine Wanze verwandelt und somit in jedem Teil der Wohnung auch
abhören kann und man Software nachladen kann und so weiter.
U: Mit dem Software nachladen war vielleicht der krasseste Verstoß.
Eigentlich hatte das Bundesverfassungsgericht nämlich sehr
genau vorgeschrieben, was ein Trojaner so können darf und was nicht. Es hatte diese
Trojaner eben nicht grundsätzlich verboten, aber relativ hohe Hürden
aufgestellt. Und diese Hürden allerdings hat der Trojaner aus dem Hause DigiTask
damals nicht eingehalten. Thorsten und ein paar andere Leute aus dem Club hatten ja
sogar so eine Fernsteuersoftware gebaut, ihr konntet den quasi fernsteuern mit
einer kleinen Windowssoftware. T: Also eigentlich sollte dieser Trojaner
ja nur Skype abhören und vielleicht mal so ein bisschen die Chatlogs mitlesen. Bei
der Analyse ist allerdings aufgefallen, dass er weitaus mehr kann, unter anderem
auch Software nachladen, aber eben auch Screenshots anfertigen und auch
Screenshots von nicht abgeschickten Emails und Gedanken und was auch immer man in so
einen Rechner auch reintippt. U: Im Grunde genau das Gruselszenario,
das wir gerade auch beim Club immer wieder kritisiert hatten, weswegen Staatstrojaner
so gefährlich sind. Das war nun leider allerdings nicht das Ende der Debatte, wie
es sich für so einen richtigen Zombie gehört, sind Staatstrojaner einfach nicht
kaputt zu bekommen. Und so haben wir in Deutschland seit 2017 wieder eine
Rechtsgrundlage für Staatstrojaner, eine neue sogar, nämlich dieses Mal im
Strafverfahren. Das Bundeskriminalamt darf die schon viel länger einsetzen seit 2009
allerdings nur zur Abwehr von Terrorismus und diesmal wirklich. Diesmal steht es
sogar im Gesetz. Aber seit 2017 gibt’s ein neues Gesetz, das im Prinzip in den
meisten Strafverfahren erlaubt, so Trojaner einzusetzen. Deswegen hat die
Gesellschaft für Freiheitsrechte dagegen geklagt. Darüber haben wir letztes Jahr
schon kurz gesprochen, weil wir sagen, was dieser Trojaner kann, ist wieder mal
verfassungswidrig. Und wir kritisieren aber nicht nur, dass der die Grenzen nicht
einhält, die das Bundesverfassungsgericht aufgestellt hat, sondern wir fragen uns,
wie kommt der Trojaner eigentlich rein ins System? Wie kommt er eigentlich rein? Bin
ich denn etwa schon drin? Damit geht’s uns um die IT-Sicherheit insgesamt, weil wir
uns fragen, welche Sicherheitslücken werden eigentlich freigehalten, offen
gehalten, ganz bewusst, damit so ein Trojaner ins System eingespielt werden
kann. Denn nur in Ausnahmefällen haben die Behörden direkt Zugriff auf das System. In
aller Regel müssen die Trojaner aus der Ferne eingespielt werden und dazu braucht
man eben Sicherheitslücken. Deswegen die Minimalforderung der GFF in diesem
Verfahren: Das geht gar nicht! Wenn man schon eine Rechtsgrundlage für Trojaner
schafft, dann muss man auch klare Spielregeln aufstellen, welche
Sicherheitslücken eigentlich ausgenutzt werden dürfen. Denn sonst gibt es einen
großen Anreiz 0-days oder Sicherheitslücken, die dem Hersteller noch
nicht bekannt sind, geheimzuhalten. Und damit werden alle Computer
auf der Welt die Sicherheitslücke weiter aufweisen. Apropos auf der Welt:
nicht nur deutsche Behörden finden Trojaner außerordentlich sexy. Ganz im
Gegenteil. Die Weltkarte des Trojaner- Einsatzes ist bemerkenswert rot.
T: Zumindest was diese FinFisher Spyware angeht, gibt es hier vom Citizen Lab
erstellt, diese Karte, wo diese Schadsoftware schon überall gefunden bzw.
eingesetzt wurde. Das ist natürlich schön, dass wir uns in Deutschland darum bemühen,
da entsprechende Rechtsgrundlagen zu schaffen. Wenn wir das hinkriegen, dass es
so eine Rechtsgrundlage gibt oder eben diesen Schutz der Privatsphäre, dann heißt
das noch lange nicht, dass wir das Problem los sind.
U: Ganz im Gegenteil! T: Das Ding ist halt, dass gerade in
diesem Fall wir davon ausgehen können, dass diese Software, die hier weltweit
eingesetzt wird, um Leute auszuspionieren, Made in Germany ist.
U: Das ist genau das Problem. Made in Germany, aber eben nicht nur eingesetzt in
Deutschland, sondern auch in Staaten, wo es mit der Rechtsstaatlichkeit vielleicht
nicht ganz so entspannt zugeht. Denn besonders spannend sind Trojaner natürlich
für Menschen, die aus guten Gründen Stress haben mit ihrer Opposition. Zum Beispiel
hier Präsident José Eduardo dos Santos aus Angola. Der, jedenfalls nach Berichten,
auf der Kundenliste von FinFisher steht. Oder Hamad bin Isa Al Chalifa, der sich
selbst im Jahr 2002 zum König von Bahrain ausrief. Und bei der Rangliste der
Pressefreiheit aus dem Jahr 2017, herausgegeben von Reporter ohne Grenzen,
belegt Bahrain den stolzen Platz 164 von 180. Mit anderen Worten: Pressefreiheit
bedeutet in diesem Land, zu schreiben, was der Chef will. Die Presse in Bahrain
gehört zu den unfreiesten der Welt. Zensur und repressive Gesetzgebung verhindern
freien Journalismus. Sechs Blogger und Bürgerjournalisten sitzen in Haft, und das
alles wird unter anderem ermöglicht dadurch, dass gezielt versucht wird,
Menschen zu hacken, die sich kritisch äußern. Aber, die Probleme beginnen direkt
vor unserer Haustür. T: Ja, wir haben auch in Europa, bzw. den
Anwärtern für die Europäische Union, Staatslenker, die auch ein Problem haben
mit ihrer eigenen Bevölkerung und mit der Opposition. Und nun gab es da halt diverse
Unruhen. Es gab einen Putschversuch. Im Sommer 2016 gab es einen Putschversuch in
der Türkei. Die Türkei wandelte sich danach zunehmend in ein eher repressives
Regime. U: Und nach dem gescheiterten
Putschversuch wurden insgesamt mehr als 50 000 Menschen verhaftet. Mehr als 140 000
Menschen wurden aus ihren Berufen entfernt. Die Türkei ist inzwischen das
Land geworden, in dem im Verhältnis zur Bevölkerungszahl weltweit die meisten
Journalisten und Journalistinnen inhaftiert sind. Eine lupenreine
Demokratie? Zurzeit befinden sich mindestens 34 Journalisten in politischer
Gefangenschaft. Hunderte Zeitungen und andere Medienorgane wurden geschlossen.
T: Es ist auch sehr, sehr auffällig, wie dringend immer darauf hingewiesen wird,
dass die Leute, die dort inhaftiert sind, unter Terrorverdacht stehen. Jeder, der
gerade zur falschen Zeit am falschen Ort ist, wird dann auch mit diesem
Terrorismusverdacht erst einmal weggesperrt.
U: Erfreulicherweise allerdings gibt es trotz aller Repressalien auch in der
Türkei noch eine Oppositionsbewegung. Beispielsweise, das sieht man auf diesem
Bild im Sommer 2017, als Oppositionelle in der Türkei unter dem Motto adalet auf die
Straße gingen, um gegen das Regime zu protestieren. Daraufhin allerdings hatte
der türkische Geheimdienst eine besonders perfide Idee. Denn Demonstrationen gegen
den großen Meister gehen natürlich gar nicht. Deswegen stellte der Geheimdienst
eine Website ins Netz, die – das seht ihr auf dem Bild – auf den ersten Blick so
aussieht, als könnte das eine Organisations-Website der
Oppositionsbewegung sein. Das sieht ja so aus mit dem Logo und dem Bild, als wenn
das Menschen wären, die hinter diesen Protesten stünden. Und auf dieser Seite,
von der man denken könnte, es sei eine Protestwebsite, gab es dann diesen
schönen Button unten rechts, der so aussieht, als ginge es dort in den Google
Play Store. Dort wurde eine Android- Software, so eine APK-Datei, also eine
Android-Installationsdatei, zum Download bereitgehalten für einige Wochen. Das
Problem ist nur, ihr ahnt es schon: es handelte sich nicht etwa um einen
Messenger oder eine Kalender-App, mit der die Oppositionellen sich hätten
organisieren können. In Wirklichkeit handelte es sich dabei um einen Android-
Trojaner, den wir im weiteren als den adalet-Trojaner bezeichnen. Die Frage ist
nur … T: Woher kommt der Trojaner? Wir sind der
Meinung, nach aktuellem Stand, dass dieser Trojaner, der in der Türkei gegen diese
Bewegung eingesetzt wurde, dass er aus Deutschland stammt. Und wir haben einiges
an Arbeit investiert, um das auch mit vielen Belegen begründen zu können, diesen
Verdacht. U: Denn: Man kann sich das vorstellen,
Anna Biselli hat das so schön gesagt vor zwei Tagen, wenn irgendwo ein Trog ist,
dann sind die Schweine nicht weit. Und ebenso ist es bei Cyberwaffen. Wenn ein
Diktator mit Dollarbündeln wedelt, dann finden sich immer wieder zwielichtige
Software-Unternehmen, die mit solchen Trojanern Geld verdienen wollen.
Menschenrechte hin oder her. Beispielsweise die Unternehmensgruppe
FinFisher aus München. Selbstbeschreibung: Excellence in Cyber Investigation. Gegen
solche Trojaner-Hersteller vorzugehen ist rechtlich schwierig. Das Problem dabei ist
nämlich, dass solche Trojaner unter bestimmten Voraussetzungen ja legal
eingesetzt werden können. Das heißt einfach nur Trojaner zu bauen ist nicht
illegal. Das gilt ganz besonders, wenn auch deutsche Behörden zur dankbaren
Kundschaft gehören, beispielsweise nach Presseberichten von Netzpolitik.org, das
Bundeskriminalamt, aber auch das Berliner Landeskriminalamt. Mit anderen Worten:
FinFisher hat beste Beziehungen zu deutschen Behörden. Aber man darf diese
Trojaner nicht einfach so exportieren, denn sie gelten als Cyberwaffen. Der
Export von Trojanern ist zwar nicht generell verboten, aber sie stehen auf der
sogenannten Ausfuhrliste. Das bedeutet, man braucht vor dem Export von Trojanern
normalerweise eine Genehmigung der Bundesregierung. Nur die EU-Staaten und
einige weitere Länder sind von dieser Erfordernis, eine Genehmigung einzuholen,
ausgenommen. Und nun hatten wir in dem adalet-Fall einen sehr, sehr schönen Fall.
Die türkische Regierung setzt einen Trojaner gegen ihre Opposition ein. Mit
der türkischen Regierung gab es ohnehin schon Stress genug. Und dieser Trojaner
stammt nun auch noch mutmaßlich aus Deutschland. Und der Export war auch noch
illegal, weil es dafür keine Genehmigung gab. Jedenfalls sagt das die
Bundesregierung. Und daher war für uns, das heißt in diesem Fall Netzpolitik.org
zum Beispiel und die Gesellschaft für Freiheitsrechte, ganz schnell klar, das
muss ein Fall für die Staatsanwaltschaft werden. Wir haben
deswegen eine Koalition geschmiedet gegen den illegalen Export von Staatstrojanern
unter Koordination der Gesellschaft für Freiheitsrechte. Das hat da meine Kollegin
Sarah Lincoln gemacht. Reporter ohne Grenzen, Netzpolitik.org und das ECCHR aus
Berlin – das European Center for Constitutional and Human Rights – ihre
Kompetenz gebündelt, und wir haben gemeinsam eine Strafanzeige geschrieben
und sie hier in diesem Sommer eingereicht, um zu erreichen, dass die Verantwortlichen
bei der Firma FinFisher zur Rechenschaft gezogen werden. Weil wir finden, genauso
wie deutsche Waffen nicht auf der ganzen Welt mitmorden dürfen, genauso dürfen auch
nicht mit deutschen Trojanern Menschenrechte weltweit oder in diesem
Fall in der Türkei verletzt werden. *Applaus*
U: Hier haben wir nochmal den Ablauf zusammengestellt.
T: Das ist jetzt die Timeline der Anzeige bzw. wann das Sample, wir reden hier von
einem Sample, wenn wir jetzt von so einem APK, so einer Schadsoftwareinstallation
reden, wann das verbreitet wurde, das war dann im Juni 2017. Das ist definitiv nach
Einführung der Export-Richtlinien. Man kann hier mit Gewissheit sagen, dass die
Zielgruppe die Oppositionellen in der Türkei waren. Das ergibt sich aus dem
Kontext dieser Website und allem drumherum. Und ja, es gab eine Anfrage an
die Bundesregierung, die letztlich bestätigte, dass es in diesem Zeitraum
zwischen 2015 und 2017 keinerlei Genehmigungen in dieser Richtung gab.
U: Damit war für uns klar, das reicht jedenfalls für eine Strafanzeige.
Natürlich müssen noch ein paar Fakten ermittelt werden. Aber jedenfalls reicht
es, um die Staatsanwaltschaft auf diesen Fall aufmerksam zu machen. Und wir haben
auch eine ganze Reihe von Indizien, dass der Fall sehr ernst genommen wird. Im
September 2019 haben wir diese Strafanzeige dann veröffentlicht, unter
anderem auch auf Netzpolitik.org. Und wir können mit Sicherheit davon ausgehen, dass
das die Herrschaften hinter FinFisher nicht begeistert hat. Denn sie haben
Netzpolitik.org abgemahnt und dazu gezwungen, den Artikel vorzeitig vom Netz
zu nehmen. Erfreulicherweise allerdings hatte die Spendenkampagne von Netzpolitik
einigen Erfolg. Ich hoffe jedenfalls, finanziell wird sich das nicht lohnen für
die Abmahner, aber klar, der Artikel ist zurzeit nicht verfügbar, jedenfalls nicht
bei Netzpolitik. Es soll ja in diesem Internet auch Archivseiten geben. Und dort
könnt ihr ihn nach wie vor lesen in seiner vollen Schönheit. FinFisher und Kohl
schlagen zurück. Wir denken, getroffene Hunde bellen. Und außerdem lassen wir uns
davon natürlich nicht einschüchtern. Wir haben – Wir heißt in diesem Fall die
Gesellschaft für Freiheitsrechte – den Club gebeten, sich die bisherigen Beweismittel
gegen FinFisher nochmal ganz genau anzusehen und zu überlegen, ob es nicht
noch weitere Beweise geben könnte. Und das Ziel dieser Mission war, noch genauer
nachzuweisen, dass tatsächlich die Voraussetzungen vorliegen für den
Straftatbestand aus dem Außenwirtschaftsgesetz. Ja, das ist die
Norm des deutschen Rechts, die ungenehmigte Exporte unter Strafe stellt,
genaugenommen §18, Absatz 2, Nr. 1 und Absatz 5 Nr. 1 dieses
Außenwirtschaftsgesetzes. Ich erspare euch die juristischen Details. Es ist im
Einzelnen ziemlich komplex. Diese Norm verweist auf die
Außenwirtschaftsverordnung und die wiederum auf einen langen Anhang, wo dann
quasi einzelne Kategorien von Gütern aufgeführt sind, vom Kampfpanzer bis zum
Staatstrojaner kann man dann nachlesen, was man
alles nur mit Genehmigung ausführen darf. Und wir sind der Auffassung, dagegen wurde
verstoßen. Zwei rechtliche Fragen standen im Mittelpunkt unserer Bitte an den Chaos
Computer Club, doch noch einmal ganz genau, sich diese Trojaner anzuschauen.
Zwei rechtliche Fragen, oder, wie soll ich sagen, zwei Tatsachenfragen, zwei Fakten-
Fragen, die aber eine große rechtliche Bedeutung haben. Und zwar zum einen …
T: Zum einen der Herstellungszeitpunkt, was wichtig ist und relevant ist, wenn es
darum geht herauszufinden: wurde diese Software nach dem Stichtag Mitte 2015
hergestellt? U: Ja, genau.
T: Wenn wir nachweisen können, dass eine Software erst zu einem bestimmten
Zeitpunkt hergestellt wurde, dann können wir auch davon ausgehen, dass sie erst
anschließend exportiert oder verkauft oder eingesetzt wird. Und die zweite wichtige
Frage, wenn wir da jetzt mal ganz neutral an die Sache rangehen. Wer hat dieses
Sample hergestellt? Es gibt den Anfangsverdacht, dass es sich hierbei um
FinSpy von FinFischer handelt. Aber das ist eben die Frage, die geklärt werden
sollte. Und das haben wir als Chaos Computer Club dann einfach mal getan.
U: Und dazu gab es ja schon bisherige Analysen. Andere Leute haben sich auch
schon mal FinFischer-Samples oder FinSpy- Samples angeschaut. Diese Analysen waren
auch für euch der Ausgangspunkt. T: Genau, so ganz am Anfang hieß es ja
auch, vor allen Dingen könnt ihr euch nicht mal diese ganzen Analysen anschauen,
die da bisher veröffentlicht wurden, unter anderem sehr viel von Citizen Lab. Die
haben sehr viel in diese Richtung gemacht, nicht nur FinFischer Produkte werden da
von denen analysiert, sondern auch noch andere. Dann ging es eben darum, zu prüfen,
ob das alles plausibel ist, was da drin ist, ob man das alles reproduzieren kann,
ob man das Ganze dann auch nochmal als Bericht so zusammenfassen kann, dass es
für deutsche Ermittlungsbehörden und ein deutsches Gericht auch verwertbar ist.
Dazu haben wir uns dann auch noch ein Gutachten von anderen Dritten angeschaut,
die so etwas ähnliches auch schon getan haben. Da gibt es schon einen
Plausibilitätscheck aus 2018 von einer Firma. Und 2018 hat Access Now auch noch
einmal einen Bericht, eine Zusammenfassung all dessen veröffentlicht. Und jetzt für
die Klage gab es dann auch nochmal eine technische Analyse. Ganz speziell dieses
adalet-Samples. Also dem eigentlichen Gegenstand der ganzen Klage. Und wir haben
uns natürlich diese ganzen Dokumente angeguckt, haben halt geschaut, sind da
irgendwo vielleicht noch Lücken, die wir füllen können? Gibt es Dinge, die wir
ausführlicher beschreiben können, transparenter machen können? Und das war
dann letztlich die Hauptarbeit, die wir dabei geleistet haben. Wer jetzt erwartet,
dass es irgendwie total bahnbrechende Neuigkeiten gibt über irgendwelche FinSpy-
oder FinFisher Trojaner, die Leute muss ich leider enttäuschen. Wir haben halt
sehr viel der Arbeit anderer Leute verifiziert. Wir haben aber auch noch ein
paar andere Indizien gefunden, die sehr viel schwerer wiegen als manche andere
Punkte, die in den Reports vorher genannt werden.
U: Und ihr habt schon, finde ich, einige sehr, sehr spannende technische Details
noch rausgekramt, zu denen wir gleich noch kommen. Z. B diese Provisionierung, wie
werden die Trojaner eigentlich angepasst? Das fand ich schon ein sehr, sehr
spannendes technisches Detail. Ihr habt dann vorgestern war es, ne, gestern war
es, die Analyse des CCC veröffentlicht. T: Genau das haben wir gestern schon
veröffentlicht, damit man ein bisschen Material hat. Ich hoffe auch, dass es,
wenn es die Zeit erlaubt, im Anschluss an diesen Talk noch ein bisschen Q&A gibt.
Ja, wir haben einen sehr ausführlichen Bericht darüber geschrieben, wie wir das
Ganze bewerten und wie wir die einzelnen Indizien gewichten und zu was für einem
Schluss wir da gekommen sind. Was uns halt sehr wichtig war an der Arbeit: Wir haben
am Ende auch alles veröffentlicht, im Gegensatz zu all den anderen
Organisationen, die diese Arbeit auch schon und auch sehr viel Arbeit investiert
haben. Wir haben sämtliche Samples, diese Schadsoftware-Samples haben wir auf GitHub
veröffentlicht. Gibt’s nachher noch einen Link.
*Applaus* T: Es gibt auch in diesem GitHub
Repository gibt es auch sämtliche Werkzeuge und Zwischenergebnisse, die wir
in unseren Analysen erlangt haben und entwickelt haben. Mit dem Ziel, dass jeder
in der Lage ist, unsere Ergebnisse zu reproduzieren. Das heißt, ihr habt die
Samples, ihr habt die Werkzeuge und die Vorgehensweise, die wir ausführlich in
diesen 60 Seiten Bericht beschrieben haben. Und ihr könnt das alles
nachvollziehen. Transparenz von unserer Seite. Wir haben eine lückenfüllende
Zusammenfassung geschrieben. U: Und nochmal ganz kurz der „Auftrag“
Selbstverständlich kann man dem CCC keinen Auftrag geben.
Insbesondere hat die GFF den CCC natürlich nicht bezahlt. Ja, das ist
ganz wichtig zu sagen. Es ist nicht irgendwie eine gekaufte Stellungnahme,
sondern wir haben einfach nur gebeten, wenn ihr euch dafür interessiert, schaut
euch das doch mal an. Das wäre wahnsinnig hilfreich. Und ich finde in der Tat
großartig, dass der Club jetzt in der Person von Thorsten insbesondere sich die
Zeit genommen hat. Ja, das ist nochmal ganz kurz zusammenfassend der Auftrag.
Analysen verifizieren, die es schon gibt, Lücken schließen in der Indizienkette und
natürlich weitere Samples gezielt analysieren und die beiden zentralen
Fragestellungen aus rechtlicher Perspektive: Wann ist dieser adalet-
Trojaner aus der Türkei oder der in der Türkei eingesetzt wurde, hergestellt
worden und wo kommt er tatsächlich her? Ja, und das sind jetzt eine ganze Reihe
von Samples, die hier auf GitHub. T: Genau das. Hier sehen wir jetzt kurz
mal so ein Listing der Samples, die wir analysiert haben. Das sind auch die
Original Schadsoftwaredateien. Da ist also dieser Trojaner drinne, das befindet sich
gerade alles in dem GitHub Repository von Linus Neumann, mit dem ich diese ganze
Analyse durchgeführt habe. Vielen Dank auch nochmal an Linus.
*Applaus* TS: Wir haben einige Nächte verbracht mit
diesen tollen Trojanern. U: Eingesetzt wurden diese Samples eben
in Türkei, sagst du, in Vietnam und in Myanmar. Das sind so die Länder, wo wir es
wissen. T: Ja, was heißt Wissen, oder eben sehr
stark annehmen. Es ist nicht so leicht zu sagen, wo sie eingesetzt wurden, wer sie
gekauft hat. Man kann das schlussfolgern aus verschiedenen Indizien. Bei der Türkei
ist es relativ leicht, sag ich mal im Kontext gesehen, weil wir ja auch diese
Website hatten, die sich dann auch gezielt gegen die Zielgruppe richtete. Es gibt
auch Samples, wo man relativ sicher sagen kann, dass sie z. B. in Myanmar eingesetzt
wurden, weil da eine sehr bekannte, burmesische Social Platform genutzt wurde.
Also, dieser Name wurde genutzt, um dieses Sample zu verbreiten. Das ist ein klares
Indiz, dass das gegen diese Bevölkerungsgruppe ging. Bei Vietnam weiß
ich nicht genau. Diese Atrribution ist halt eh schon ein schwieriges Thema.
Genauso schwierig ist es eben herauszufinden, wo es eingesetzt wurde,
weil die ganzen Metadaten, die man dann in den Samples findet, IP-Adressen,
Telefonnummern und so weiter. Die sagen am Ende nicht viel aus.
U: Dazu sehen wir gleich noch ein bisschen mehr. Aber fangen wir doch
vielleicht an mit der ersten zentralen Frage, nämlich der Feststellung des
Herstellungszeitpunktes. Dazu habt ihr euch eine ganze Reihe Gedanken gemacht,
wie man darauf kommen könnte. T: Die zentralen Fragen waren, wann wurde
das hergestellt? Also haben wir uns all diese ganzen Samples angesehen und haben
geguckt, ob wir da Indizien finden, dass diese Software möglicherweise nach 2015
hergestellt wurde. Da gibt es verschiedene Möglichkeiten. Grundsätzlich alles, was
wir jetzt in den Binaries und in diesen Schadsoftware-Samples finden. Das ist dann
so der frühestmögliche Zeitpunkt. Wenn ich beweisen kann, dass zum Beispiel eine
Komponente dieser Schadsoftware erst im Mai 2016 überhaupt hergestellt oder
veröffentlicht wurde, dann bedeutet das natürlich auch, dass das ganze
Schadsoftware-Sample erst nach diesem Zeitpunkt hergestellt werden kann. Das ist
der frühestmöglichen Zeitpunkt. Das kann also auch durchaus sein, dass es 2017
zusammengebaut und verschickt und verkauft wurde. Das wissen wir nicht so genau.
U: Aber jedenfalls, eine Library, die noch nicht veröffentlicht war, kann nicht
eingebaut werden, ne? T: Genau deswegen haben wir sehr gezielt,
geh nochmal zurück, sehr gezielt nach solchen Artefakten von Compilern gesucht
oder irgendwelche Zeichenketten aus irgendwelchen Open-Source Produkten. Es
gibt aber auch in diesen APK-Dateien. Das sind halt so die Android-Apps, liegen als
APK vor, das ist technisch gesehen nichts weiter als ein ZIP-Archiv, was
wahrscheinlich alle von euch kennen dürften. Und in diesen Archiven liegen
dann auch Zertifikate der Entwickler, die dieses Paket veröffentlichen. Und anhand
dieser Zertifikate kann man z. B. auch einen Zeitstempel einsehen, wann dieses
Zertifikat erstellt wurde. Das sagt jetzt für unsere juristische Sichtweise nicht
besonders viel aus, weil man kann ja ein Zertifikat mit einem beliebigen
Zeitstempel herstellen. Ich kann ja sagen, ich gehe zurück in die Vergangenheit, oder
ich erstelle das in der Zukunft. Das kann man alles machen.
U: Nur warum sollte man das tun? T: Warum sollte man das tun? Vielleicht
gibt’s einen guten Grund dafür. Aber wir haben uns ja auch aus diesem Grund und
genau deshalb Samples angeschaut, die bis ins Jahr 2012 zurückreichen. Also wir
haben uns diese Trojaner-APKs angesehen, die 2012 bis 2019 in die Öffentlichkeit
gelangten. Und wir können zumindest sagen, wenn wir jetzt im Jahr 2019 sehen oder ein
Muster erkennen können, dass bestimmte Zertifikate vielleicht auch in der
Vergangenheit genutzt wurden, dann kann man sich schon fragen, ob das jetzt
plausibel ist oder nicht. Ansonsten gibt es noch öffentliche Dokumentation. Dazu
gehörte das Sample selber. Das haben wir auch nur aus dem Internet aus
verschiedenen Quellen, aber gegeben. Deswegen ist es wichtig, sämtliche 28
Samples, die wir da hatten, anzuschauen: Wann wurden die eigentlich im Einzelnen
hergestellt? U: Ein Ansatzpunkt war der
Herstellungszeitpunkt von Bibliotheken. T: Genau, hier sehen wir ein disassembly
von einem Shared Object, was da mitgeliefert wurde, das bedeutet, diese
Android-Anwendungen sind ja eigentlich nur Java-Anwendungen. Das heißt, da liegt Java
Bytecode drin und in Java hat man auch die Möglichkeit, über das Java Native
Interface auch anderen Code aufzurufen, der zum Beispiel vom Betriebssystem
bereitgestellt wird, oder eben in C, also mit anderen Programmiersprachen
entwickelte Libraries, die mitgeliefert werden und in dem Fall war; in diesem
Sample gab’s noch so Shared Object Files. Das ist halt unter Linux-Betriebssysten haben
sie die Endung .so, unter Windows gibt's ein ähnliches Konzept. Das sind dann
dynamische Bibliotheken, die als DLL mitgeliefert werden. Und in dem Fall gab
es eine Bibliothek, in der wir bestimmte Zeichenketten gefunden haben, die darauf
hindeuten, dass das definitiv erst 2016 hergestellt worden sein kann. Das sieht
man hier daran, das ist SQLite das ist ein Open-Source-Projekt, so eine Open-Source
Datenbank. Und die hinterlässt dann in diesem Kompilat diesen String. Das ist ein
Datum und irgendein Hash. Und wenn wir uns dann mal anschauen, okay, wann taucht
denn dieser String eigentlich auf? Dann können wir uns auf der Open-Source-Projekt-
Webseite anschauen, dass da tatsächlich die SQLite Version 3.13 im Mai 2016
veröffentlicht wurde. Und lustigerweise sehen wir hier genau diese Checksumme mit
genau dem gleichen String und somit können wir eigentlich 100% davon ausgehen, dass
das hier sich sicherlich niemand ausgedacht hat im Jahr 2012.
*Ulf lacht* TS: Es ist ziemlich unwahrscheinlich.
*Applaus* T: Ich hoffe ich laser dir nicht die Augen.
UB: Passt schon, ich schrei dann. Und dann habt ihr euch die
Zertifikate angeschaut, mit denen die Software signiert worden
ist, ne, die einzelnen Zertifizierungen? T: Das haben wir auch gemacht, das haben
aber auch die anderen Researcher gemacht, die sich das vor uns angeschaut haben. Die
haben das natürlich genauso analysiert. Aber wir wollten ja auch die Analysen
analysieren, und das haben wir getan. Deswegen der Vollständigkeit halber in
unserem Report natürlich auch nochmal ein Zeitstrahl. Wir haben später noch eine
schöne Tabelle, wo man das gut sehen kann. Hier sehen wir den Output, wenn man sich
dieses Zertifikat mal anschaut, was der Entwickler genutzt hat, um dieses Paket zu
signieren. Hier sehen wir, dass es erzeugt wurde im Oktober 2016. Passt also
zeitlich, wenn wir davon ausgehen, dass das Zertifikat erstellt wurde, als dieses
Sample zusammengebaut wurde. Liegt halt auch nach Mai 2016. Bis wann das gültig
ist, ist eigentlich völlig egal. Ja, das Schöne wäre jetzt eigentlich, was hätten
wir jetzt hier, wenn wir da jetzt irgendwelche Werte manipulieren, wenn wir
es zurück datieren? Schön. Dann könnten wir Researcher in die Irre führen, wenn
jetzt hier zum Beispiel stehen würde, das Zertifikat wurde 2012 erstellt. Dann
könnten wir überhaupt gar nichts darüber aussagen. So vielleicht schon eher, was
hier noch auffällig ist, das wird später noch relevant, es gibt auch diese
Fingerprints für diese Zertifikate. Das sind diese langen SHA-Werte hier. Das ist
ein kryptographischer Hash über dieses Zertifikat, über den key und der ist
einmalig. Also, wenn wir uns jetzt in den 28 Samples alle Zertifikate angucken, dann
vergleichen wir natürlich auch diesen SHA-Wert, weil das ist der Fingerprint,
das drückt das schon ganz gut aus. Das ist ein Fingerabdruck, wenn wir genau diesen
Fingerabdruck in einem anderem Sample finden, dann können wir zumindest auch
eine Aussage darüber treffen, dass beide Samples, unabhängig davon, wann sie
jeweils veröffentlicht wurden, dass beide vom gleichen Hersteller stammen. Und das
ist auch ein wichtiger Punkt für diese ganze Schlussfolgerung am Ende.
U: Zunächst mal aber können diese beiden Aspekte, die du genannt hast, die
Bibliotheken und die Zertifikate im Grunde den Schluss tragen, dass dieses adalet-
Sample jedenfalls nicht vor dem 18. Mai 2016 erstellt worden sein kann. Einfach
weil es da diese SQlite-Bibliothek noch nicht gab.
T: Genau, das ist ein so schweres Indiz, dass ich definitiv sagen kann, dass es
nicht vor Mai 2016 hergestellt worden ist. UB: Damit liegt dieses Datum jedenfalls
nach dem Inkrafttreten der Verbote, von denen ich anfangs gesprochen habe. Das
heißt also, dieses Sample wäre dann, wenn es tatsächlich in die Türkei exportiert
worden ist, unter Verstoß dagegen exportiert worden. Zweiter Aspekt
vielleicht noch wichtiger, die Feststellung der Herkunft. Was für ein
Vieh war denn jetzt eigentlich dieses adalet-Trojanerchen?
T: Dafür haben wir, wie ich sagte, Samples aus dem Zeitraum von sieben Jahren
uns angeschaut und geguckt. Was haben die für Gemeinsamkeiten? Was lässt darauf
schließen, dass die aus einem Hause stammen? Da braucht uns in dem Moment noch
gar nicht interessieren, wie dieses Haus überhaupt heißt. Uns ist nur wichtig
gewesen herauszufinden, ob die einen Zusammenhang haben. Dafür haben wir diese
Code-Signing-Zertifikate miteinander verglichen, wie ich eben schon sagte. Es
gibt noch ein paar andere Indizien übrigens, für diese Zeitgeschichte. Aber
die spielt jetzt hier keine besonders große Rolle. Der Coding-Style ist auch
eine wichtige Rolle. Wie ich schon sagte, diese APKs, diese Anwendungen, sind
eigentlich in Java programmiert. Man kann auch noch Shared-Object-Bibliotheken
daneben legen, die vielleicht in anderen Programmiersprachen entwickelt wurden.
Aber man kann sowohl im Dekompilat des Java-Codes als auch im Disassembly dieser
Bibliotheken einen gewissen Coding-Style ablesen. Man kann verschiedene
Variablennamen miteinander vergleichen, wenn keine Obfuscation am Start war. Also
Mittel, um Code-Herkunft und Code-Struktur zu verschleiern. Wir können die Code-Basis
miteinander vergleichen, also auf einer rein funktionellen Ebene. Wir können uns
anschauen. Sind die Funktionen in der einen Anwendung vorhanden, die aus dem
Jahr 2012 stammt, und sind die gleichen Funktionen auch vorhanden in der
Anwendung, die aus 2014 stammt und 2017 und so weiter? Das können wir schon
miteinander vergleichen und auch Diffs feststellen, also Unterschiede zwischen
den Versionen. So können wir von einer Evolution sprechen oder eine Beobachtung
dieser Evolution einer bestimmten Schadsoftware. Wir haben sehr stark darauf
geachtet, ob wir zum Beispiel sehen können, welche Sprache, welche
Muttersprache die Entwickler sprechen. Das sehen wir an manchen Stellen sehr
deutlich. Komme ich nachher noch mit Beispielen zu. Dann schauen wir uns auch
an, wann und wie die provisioniert wurden und ob es
da irgendwelche Ähnlichkeiten gibt. U: Provisionierung bedeutet quasi, dass
dieser Trojaner jeweils angepasst wurde für den spezifischen Einsatzzweck. Das
heißt, dieser Trojaner ist im Prinzip eine Massenware oder jedenfalls eine vielfach
eingesetzte Software. Aber für das jeweilige Land wurden dann
unterschiedliche Parameter gesetzt. Dazu kommen wir auch gleich noch. Das Spannende
dabei ist, was Thorsten gerade beschrieben hat. Das sind zunächst mal vor allem
Parallelen zwischen unterschiedlichen Samples. Das heißt, da kann man sagen,
diese Samples kommen wohl mehr oder weniger aus derselben Küche. Aber das sagt
ja zunächst mal noch nicht, welche Küche das ist. Um das sagen zu können, braucht
es noch einen zweiten Schritt, nämlich das Finden von Samples bestätigter Herkunft.
Das heißt, wenn man weiß, bestimmte Samples gehören zusammen, kommen aus
demselben Haus, und man kann dann wenigstens ein Sample oder zwei Samples
einem ganz konkreten Hersteller zuweisen. Dann gilt es, jedenfalls mit sehr hoher
Wahrscheinlichkeit, auch für alle anderen Samples aus dieser Herstellungslinie. Und
da muss man ganz ehrlich sagen, sind wir zu großer Dankbarkeit verpflichtet.
T: Ja, Phineas Fisher hatte einen größeren Batzen Daten aus dem Hause
FinFisher getragen und veröffentlicht. U: Tipp!
T: Es gibt da ein 41 Gigabyte großes File, wo sehr viele Samples drinne sind,
die wir auch analysiert haben. U: Hier sieht man das.
T: Vielen Dank nochmal Phineas Fisher! *Applaus*
U: Mit anderen Worten, es ist für diese Analyse ein großer Vorteil, dass es
bestimmte Samples gibt, die aus diesem Phineas Fisher Hack stammen und die man
mit sehr großer Wahrscheinlichkeit aufgrund vieler Indizien dieser
Firmengruppe FinFisher zuordnen kann. Das heißt, man hat 2 Anker, oder wieviele
Samples sind da drin? 2? T: Jaja.
U: Das heißt, man hat quasi 2 Ankerpunkte und kann sich dann von diesen Ankerpunkten
über den Vergleich von Samples weiter vorhangeln. Aber das ändert natürlich
nichts daran: Attribution is hard. T: Sehr hart. Wir suchen also natürlich
noch weiter nach Indizien, die auf den Urheber schließen lassen. Die
Attributierung von Schadsoftware, wenn mal irgendwie wieder der Bundestag gehackt
wurde oder irgendjemand anders, da kommen dann immer ganz schnell Leute, die sagen,
die Russen waren es, die Chinesen waren es und so weiter. Das ist alles nicht so
leicht. Wir müssen diese Attributierung allerdings auch ein Stück weit durchführen
und hangeln uns dann aber auch entlang an dem jeweiligen Kontext, zum Beispiel, wo
so ein Sample eingesetzt wurde. Wie dieses adalet-Sample zum Beispiel. Es gibt ja
grundsätzlich die Möglichkeit, das auch zu faken. Wenn ich sage, ich bin jetzt
irgendwie irgendeine Hackergruppe oder ein Konkurrent von FinFisher, dann will ich
die vielleicht in einem schlechteren Licht dastehen lassen. Und fake jetzt vielleicht
mal irgendwie Malware von denen und mache dann so False-FlagGeschichten. Das ist
natürlich alles möglich, aber in diesen einzelnen Fällen relativ unwahrscheinlich.
U: Auch sowas könnte man theoretisch faken.
T: Das kann man definitiv faken. Das ist jetzt, was wir jetzt hier sehen, die
verarbeitete Ausgabe von so einer Konfiguration, von so einer
Provisionierung. wie Ulf schon sagte, diese einzelnen Samples werden ja nicht
jedes Mal neu kompiliert und neu entwickelt. Da gibt es dann einfach
verschiedene Parameter, die für den Case des jeweiligen Einsatzes notwendig sind.
Und das wäre dann so eine Konfiguration. Da steht dann jetzt zum Beispiel, ja der
Proxy fürs nach-Hause-Telefonieren hat die IP-Adresse oder den Hostnamen. Dann sieht
man hier auch noch eine TargetID, in dem Fall adalet. Das hat, wer auch immer
diesen Trojaner zusammengebaut hat, sich ausgedacht. Dann gibt es noch
Telefonnummern, wo SMS hingeschickt werden oder wo angerufen werden kann. Und in dem
Fall kann man ganz gut sehen, dass diese Attributierung schlecht, hard ist. Denn
die IP-Adresse stammt aus Deutschland. Die Telefonnummer ist eine israelische, und
die andere Telefonnummer ist eine internationale Mehrwert-Rufnummer. Da
lässt sich jetzt noch nicht so stark darauf schließen, dass das tatsächlich von
türkischen Behörden eingesetzt wurde. U: Etwas anders sieht es aus bei der
Familie der Samples, die ihr analysiert habt. Denn da hilft euch ja das
Zertifikat, das zum Signieren verwendet wurde.
T: Genau das sind ein paar Indizien, die wir da herausgepickt haben, anhand derer
wir irgendwie bestimmte Gruppen zusammenfassen können. Also was gehört
definitiv zusammen, was nicht? Diese Liste sieht jetzt sehr wirr aus. Was hier grün
markiert ist, ist das adalet-Sample, von dem wir quasi so ausgehen. Wir wollen also
Parallelen finden zu diesem adalet-Sample. Alles, was hier rot markiert ist, hat eine
Parallele. Das stammt nämlich alles aus dem Leak von Phineas Fischer. Alles was da
oben gelb markiert ist, wurde 2012 schon mal veröffentlicht und es gibt
entsprechende Analysen und verschiedene Indizien, die darauf hinweisen, dass es
auch aus dem Hause FinFischer stammt. Wenn wir jetzt mal davon ausgehen, dass das
hier aus dem Hause FinFisher stammt, weil es in dem Leak war, dann haben wir hier
ein Sample, das nennt sich „421and“. „421“ scheint die Versionsnummer zu sein, „and“
heißt Android. Wir sehen hier, das ist dieser Fingerprint von diesem Zertifikat,
was ich vorhin noch erklärt habe. Diesen Fingerprint finden wir hier oben wieder.
Zwei Jahre vorher sind da oben schon Samples in die Öffentlichkeit gelangt, die
genau den gleichen Fingerprint haben. Und dann haben wir hier oben dieses „Andriod“.
Das ist ein Tippfehler, aber der stammt halt so von denen. Das muss ein Demo-
Sample sein. Da hat diese Firma offenbar mal gezeigt, was dieser Trojaner so kann.
Und dann haben sie den halt so provisioniert, mit Zeichenketten, also
Webserver-URLs, die auf Gamma International schließen lassen. Und es
wurde aber auch noch ein in-the-wild- Sample damit signiert, mit dem gleichen
Zertifikat. Dieses „derise“ ist das, was in Vietnam identifiziert wurde und auch
vietnamesische IP-Adressen, Telefonnummern und so weiter drinne hat. Wie gesagt
Attributierung ist schwierig, aber an dem Fall kann man auf jeden Fall sagen, dass
hier Demo-Samples und in-the-wild-Samples definitiv aus einem Hause stammen, anhand
dieser Zertifikats-Fingerprints. U: Der nächste Schritt, den ihr gemacht
habt, ist tatsächlich euch mal die Struktur der einzelnen Samples anzuschauen, also
insbesondere wie diese Software von ihrem logischen Ablauf her funktioniert.
T: Genau. Wir haben uns dann verschiedene Funktionen angeguckt und haben halt mal
geguckt „Was sehen wir so an den Funktionen?“. Ich habe ja gesagt, wir
schauen uns auch so ein bisschen diesen Coding-Style an, was für Variablen werden
da genommen, wenn wir uns Java-Code angucken können, der nicht obfuskiert ist.
Hier sehen wir zwei Samples und zwar das, was aus dem Leak stammt von 2014. Das ist
auch irgendwie so eine Art Demo. Und 2016 – also, ich sage jetzt mal 2016, weil das
definitiv noch 2016 hergestellt wurde – das adalet-Sample. Sie hatten hier so ein
Refactoring durchgeführt. Also eine Umbenennung aller Variablen und
Funktionsnamen und so weiter. Das ist ein und dieselbe Funktion, das kann man sehen,
wenn man sich den Code durchliest. Jetzt wollte ich hier aber keinen Source Code an
die Wand werfen. Deswegen habe ich hier so einen Call Flow, abgeleitet aus dem Source
Code. Das ist eine Funktion namens Run. In dem Sample von 2014 liegt das in einer
Klasse namens SMS. In dem Sample adalet legt es in einer Klasse namens s1ms, was
in Leetspeak hin geschrieben wurde. Und wir sehen hier ganz klar, dass in dieser
Funktion effektiv der gleiche Code ausgeführt wird mit ganz marginalen
Abweichungen. Das kann, zumindest nach unserer Einschätzung, definitiv kein
Zufall sein. Das heißt, das ist eine Weiterentwicklung der ganzen Samples aus
dem Jahr 2012, 2014 und jetzt auch in 2016. Das ist die Information, was wir da
rausziehen konnten. U: Und zugleich kann man ja auch Schlüsse
ziehen aus diesem Leetspeak. Denn wenn man sich überlegt: der Begriff SMS ist etwas
typisch Deutsches. Man versteht es vielleicht noch in anderen Ländern, aber
man spricht normalerweise nicht von SMS. Jedenfalls nicht im englischen Sprachraum
und insbesondere, wenn man dann noch das Verb „simsen“ sich überlegt. Also in
Leetspeak dann „S 1 M S“ wie simsen. Das ist was ganz typisch deutsches. Und ich
jedenfalls kann mir nicht so richtig vorstellen, dass ein türkischer
Programmierer mit einem Mal von "simsen" spricht.
T: Genauso wenig kann ich mir vorstellen, dass das ein englischsprachiger
Programmierer tut. Dieses Wort „simsen“ wurde irgendwann mal modern und jeder hat
es benutzt sodass es sogar in den Duden aufgenommen wurde. Und das Wort simsen
findet man halt wirklich nur im deutschen Sprachgebrauch, und es ist schwer
vorstellbar, dass jemand, der nicht Deutsch-Muttersprachler ist, dieses Wort
in einem Code verwenden würde, wenn es im Kontext um SMS abfangen geht und das Ganze
auch noch mit Leetspeak verschleiert wird. U: Aber ihr habt ja noch eine andere
Technologie, Stichwort Verschleierung, gefunden, die außerordentlich pfiffig ist,
muss man sagen. Jedenfalls ich war sehr beeindruckt, als ich diese Analyse gelesen
habe, nämlich wie eigentlich diese Daten, diese Parameter, die wir eben schon kurz
gesehen haben zur Provisionierung eigentlich in den Viren-Samples abgelegt
oder eigentlich versteckt worden. T: Da hat sich der Entwickler ein
Verfahren ausgedacht, das ist so eine Art Covered Channel, also ein versteckter
Kanal, so ein bisschen ähnlich wie Steganografie, wenn man das kennt. Ich
verstecke Informationen in Dateistrukturen, sodass man das
automatisiert oder mit bloßem Auge nicht besonders leicht erkennen kann. Was für
Konfigurationen muss man hier verstecken? Wie ich schon sagte, es gibt halt so die
Telefonnummern, die angerufen werden oder wo SMS hin geschickt werden. Es gibt IP-
Adressen, zu denen sich die Schadsoftware verbindet, damit ein Command-and-Control-
Server da übernehmen und lenken kann. Und wie lange die Maßnahme dauert et cetera.
Das alles ist in einer Konfiguration abgespeichert, die irgendwie in dieses APK
rein gedrückt werden muss. U: Und dabei ist euch aufgefallen, als
ihr euch die Samples angesehen habt, dass alle ein identisches Verfahren einsetzen.
T: Die benutzen alle das identische Verfahren. Also, wir haben das jetzt auch
nicht entdeckt. Dieses Verfahren haben andere, Josh Grunzweig beispielsweise
2012, auch schon in einem Blog-Beitrag veröffentlicht, als er FinSpy-Samples
analysiert hat. Das ist nichts bahnbrechendes Neues, aber wir konnten
zumindest jetzt einfach mal über die 7 Jahre hinweg beobachten, dass dieses
Verfahren in allen Samples eingesetzt wird. Und damit, da es eben auch kein
Standardverfahren ist, um in irgendwelchen APKs Schadsoftware zu verstecken oder
überhaupt Daten zu verstecken, können wir im Grunde genommen davon ausgehen, dass
diese Technologie wirklich von einem Hersteller stammt. Das heißt, dass all
diese Samples, diese 28 Stück, die wir uns angeguckt haben, dass die aus einem Hause
stammen. U: Und wie sieht das jetzt genau aus? Das
hier ist der Datei-Kopf. Nee, das ist nicht der Datei-Kopf sondern …
T: Das sind Teile eines … Also ein APK ist, wie ich schon sagte, technisch
gesehen nur ein ZIP-Archiv. Und in diesem ZIP-Archiv stecken Metainformationen über
die im Archiv enthaltenen Dateien. Und dafür gibt es dann diese Central Directory
Structure und verschiedene Felder. Das ist dann so ein Header. Da sind verschiedene
Bytes und Bitfelder festgelegt, die die Eigenschaften dieser im Archiv enthaltenen
Datei beschreiben. Eine wichtige Metainformation, die genutzt werden kann,
um Daten zu transportieren, ohne dass man es leicht sieht, sind diese
Dateisystemattribute. Die ZIP- Spezifikation sieht vor, dass es 2 Byte
oder 16 Bit für interne File-Attribute gibt. Und sie sieht vor, dass es 32 Bit
für die Dateisystemattribute auf dem Ziel- Betriebssystem gibt. Somit haben wir hier
6 Byte pro Central Directory Structure zur Verfügung, um Daten zu verstecken, denn
wir können da ja beliebig idiotische File- Attribute setzen. Und das ist das, was sie
gemacht haben. Die ergeben dann zwar, wenn man die Dateien entpackt, auf dem Ziel-
Betriebssystem keinen Sinn mehr, müssen sie aber auch nicht, weil die Daten gar
nicht genutzt werden. Das sind einfach irgendwelche Dummy-Dateien. Das sieht man
hier. Hier sehen wir im Hex-Editor so ein APK und diese Strukturen. Wir haben diese
Signatur, diese PKZIP-Signatur ganz am Anfang, die ist hier gelb markiert, und
ein Offset von 36 Byte später, kommen dann diese 6 Byte Dateisystemattribute. Und wer
sich so ein bisschen mit Unix oder Dateisystemen auskennt, sieht auch, dass
das jetzt hier keine Bitfelder sind für Attribute, die Sinn ergeben. Nein, was wir
hier sehen, sind BASE64 codierte Daten. Und wenn man jetzt dieses ZIP-File einmal
parst und sich alle diese CDS-Signaturen herauspickt und dann diese Dateisystem …
diese Dateiattribute aneinander hängt, anschließend diesen ganzen String, der
dabei herausfällt BASE64-dekodiert, dann fällt daraus später eine Binärdatei, die
genau die Konfiguration dieser Schadsoftware beinhaltet. Das wurde,
wie gesagt, alles schon mal dokumentiert, wir haben das jetzt einfach
alles noch einmal nachvollzogen und auf alle Samples angewendet und geguckt, was
dabei rausfällt. Das heißt dann im ersten Schritt: Wir müssen die Dateien
extrahieren. In einem zweiten Schritt müssen wir die Dateien parsen.
U: Und das Tool dazu findet sich jetzt wieder auf der Website. Das heißt, das
müsst ihr uns oder vorallem Thorsten und Linus nicht glauben. Das könnt ihr alles
selber nachprüfen, wenn ihr eines der Samples runterladet und die Tools darüber
laufen lasst. Und wir hoffen, dass auf diese Art und Weise noch weitere Samples
analysiert werden können. Das ist jetzt noch mal ein Überblick, wie sowas dann in
der Gesamtheit aussehen kann. Wir müssen ein ganz bisschen springen an der Stelle
und schauen, wo wir dann weitermachen. Genau das ist dann so eine Konfiguration,
wie sie in der Summe aussieht. T: Genau, das ist jetzt dieses „Andriod“
Beispiel, was 2012 schon auf VirusTotal gelandet ist. Hier sehen wir, wie ich
schon angedeutet habe, es gibt dann so Hostnamen, die schon den Namen beinhalten.
Ich muss aber auch nochmal dazusagen: Es hat jetzt keine besonders große
Aussagekraft, wenn man ein Sample für sich betrachtet und solche Zeichenketten da
drin findet. Denn Josh Grunzweig, der das schon 2012 in seinem Blog dokumentiert
hat, hat auch schon ein Tool veröffentlicht auf GitHub, womit man genau
so eine Konfiguration herstellen kann und in so ein APK reindrücken kann. Das heißt,
man könnte im Grunde genommen sowas auch faken.
U: Das heißt, die Aussage ist tatsächlich weniger „Was steht drin in diesen
versteckten Konfigurationsinformationen?“ Sondern die Aussage ist: Alle Samples
verwenden die gleiche Technik, die gleiche proprietäre und auch ziemlich ausgefuchste
Technik, um diese Daten zu verstecken in der APK-Datei. Und diese Gleichheit ist
die eigentliche Aussage dieser Analyse. Alle untersuchten Samples nutzen eben
diesen proprietären Mechanismus. Und du sagst, das Format wurde aber
weiterentwickelt? T: Es sieht ganz danach aus, wenn man,
sich den Inhalt dieser Binärdatei anguckt. Sie benutzen dann so eine Art Directory,
um Nummern bestimmten Funktionen oder Variablennamen zuzuweisen. Das ist auch
der Punkt, was es einfach macht, diese Konfiguration zu parsen, zu verarbeiten
und herauszufinden, welche Werte bedeuten was.
U: Diese Werte sind zum Beispiel diese hier.
T: Beispielsweise das. Im adalet-Sample gibt es, wie ich vorhin schon gezeigt
habe, verschiedene Werte, die jetzt auch nicht unbedingt auf die Türkei hindeuten.
Dann gibt es auch aus dem gleichen Zeitraum noch einen flash28-Sample, was
große Ähnlichkeiten und Parallelen mit dem adalet-Sampel aufweist. Da wird z. B. ein
Proxy aus Neuseeland genommen, ansonsten die gleiche Telefonnummer und dieses
derise-Sample hat, wie ich auch schon angedeutet habe, sämtliche Werte, die
davon relevant sind, zeigen Richtung Vietnam. Ob das etwas aussagt? Keine
Ahnung. In jedem Fall haben wir auch all das, diese ganzen Configs, die wir daraus
extrahiert haben, haben wir auch auf GitHub veröffentlicht. Das findet ihr bei
Linus in der FinSpy-Dokumentation, wo auch der Bericht und alle anderen Samples
liegen. U: Genau und vielleicht mag sich ja mal
jemand diese Telefonnummern anschauen, vielleicht kennt die ja jemand aus
irgendwelchen anderen Zusammenhängen. Das könnten noch ganz interessante
Rückschlüsse werden. Da würden wir uns über Hinweise freuen. Und insgesamt sieht
man dabei – das ist die Übersicht über die Samples, die ihr analysiert habt. Aber man
sieht, denke ich, ganz gut, dass es da so etwas wie eine Familienstruktur gibt.
T: Genau. Der einzige, der hier so ein bisschen aus der Reihe fällt, ist das Ding
hier. Das Ding, hab ich jetzt einfach mal Container genannt, weil es sonst keinen
Namen hatte. Das ist ein APK, was überhaupt keine Parallelen zu den anderen
aufweist. Aber dieses eine Sample hebt sich insofern von den anderen ab, als dass
wir das jetzt hier noch mit aufgenommen haben, das dropped, also legt, quasi eine
Schadsoftware APK überhaupt erst ab. In diesem grau markierten Sample gibt es
einen lokalen Root Kernel Exploit gegen den Linux-Kernel auf Android-Devices. Die
nutzen da die als „Dirty COW“ bekannte Schwachstelle aus, um Root auf dem Telefon
zu werden. Da liegen dann noch Werkzeuge, um persistent Root zu bleiben. Und dann
liegt da halt auch noch ein Sample, nämlich dieses hier, dieses PyawApp. Ich
weiß nicht, wie man das ausspricht. Das ist das Ding, wo wir davon ausgehen, dass
es in diesem Kontext Myanmar zugeschrieben wird. Weil Pyaw ein sehr bekanntes
soziales Netzwerk in der Region ist. U: Und die Antwort aus technischer
Perspektive. Vieles davon haben wir im Grunde schon gesagt. Aber in der
Zusammenfassung … T: Wie gesagt, sämtliche Samples, die wir
hier analysiert haben, benutzen den gleichen Mechanismus für die
Provisionierung. Diese ganzen Konfigurationen liegen in einem sehr
speziellen, Binärformat vor. Das ist kein allgemeingültiges Format, muss also
definitiv aus einem Hause stammen. Wir haben große Ähnlichkeiten auch unterhalb
des Java-Codes, wo es auch Hinweise darauf gibt, dass es aus deutschem Hause stammt.
Wir können ganz genau sagen, dass das adalet-Sample frühestens im Jahr 2016
hergestellt wurde. Und die Samples zwischen 2012 und 2014 können auch ganz
eindeutig der Firma FinFisher zugeordnet werden, weswegen da eigentlich in der
Schlussfolgerung auch klar gesagt werden kann, dass all diese Samples, die wir uns
zwischen 2012 und 2019 angeguckt haben, der Firma oder der Firmengruppe FinFisher
zuzuordnen ist. U: Und all das könnt ihr nochmal im
Detail nachlesen in der Studie des CCC, die schon veröffentlicht wurde gestern und
wie gesagt, ganz wichtig, wir möchten die eigentlich gerne noch auf Englisch
publizieren. Wir haben deswegen schon mal eine URL für ein Pad auf die Folie
geworfen. Das Pad gibt’s da nicht, das füllen wir noch aus mit einer Roh-
Übersetzung aus Google Translate. Oder vielleicht mag das auch jemand von euch
machen. T: Wir würden das gerne crowdsourcen.
U: Das ist ein bisschen die Idee dabei, weil das schon ein bisschen Arbeit ist,
und wir schaffen das einfach schnell, jetzt, während des Kongresses nicht. Aber
vielleicht hat jemand Lust uns zu helfen. Das wird die URL. Und vor allem ganz
wichtig: Check the facts! Das werden wir natürlich aus GFF-Perspektive machen. Wir
gehen davon aus, dass es auch die Staatsanwaltschaft machen wird. Aber ich
persönlich finde es großartig, dass der CCC die Tools und die ganzen Unterlagen,
die zur Analyse vorlagen, ins Netz gestellt hat. Einfach, damit man das nicht
unbedingt glauben muss, sondern dass man selber sich davon überzeugen kann.
T: Transparenz ist uns sehr wichtig. Und hier auch noch ein kleiner Gruß ans BKA
und LKA. Ihr habt diese Samples ja auch in einer ganz neuen Version. Vielleicht könnt
ihr euch das ja mal angucken, und wir sind offen für Pull-Requests.
*Applaus* U: Ein Pull-Request aus Wiesbaden? Das
wäre doch mal eine gute Idee oder eben auch aus Berlin.
T: Ihr könnt auch Tor benutzen, das ist egal.
U: Kein Problem, da sind wir ganz offen. Und das Berliner LKA könnte da auch
mitmachen. Die haben ja auch mal ein Sample gekauft, das aber nie eingesetzt.
Sie brauchen das eh nicht mehr. Insofern, das hätten sie über. Was bedeutet das
jetzt alles für das Strafverfahren? Aus unserer Perspektive als GFF: Wir haben
keine Zweifel und natürlich auch aus der Perspektive des Clubs, dass der deutsche
Trojaner FinFisher gegen die türkische Opposition eingesetzt wurde, davon sind
wir fest überzeugt. Irgendwie muss dieser Trojaner aus München in die Hände
türkischer Behörden gelangt sein oder sonst aus den Händen der Firmengruppe
FinFisher. Und diese Verstoße gegen die Exportkontrollvorschriften wären auch noch
nicht verjährt. Und deswegen liegt der Ball jetzt bei der Staatsanwaltschaft
München 1. Denn eine Frage ist noch offen: Wie genau ist eigentlich der Trojaner in
die Türkei gelangt? Wir können jetzt quasi nicht irgendwie nachweisen, da ist der
Agent mit dem schwarzen Aktentäschchen nach Istanbul gereist, oder da ist der
USB-Stick geflogen, sondern das müssten die Strafverfolger noch aufklären. Aber
wie gesagt, dafür haben wir die Strafanzeige gestellt. Dazu hat die
Staatsanwaltschaft alle Mittel. Und wir hoffen, dass sie das sehr konsequent tun
wird. Denn eins ist klar: Menschenrechte kann man nicht nur mit Kalaschnikows
verletzen, sondern selbstverständlich auch mit Staatstrojanern. Und dem muss ein Ende
gemacht werden. Vielen Dank!
*Applaus*
U: Herzlichen Dank, wir haben noch ganz ein wenig Zeit, oder?
T: Naja, eine Minute. Herald: Euer Applaus. Wunderschön!
U: Dankeschön! Herald: Wir haben leider keine Zeit mehr
für Fragen. Ich habe ganz zu Anfang vor diesem Talk erwähnt, dass es die C3 Post
gibt. Und die beiden Speaker haben erwähnt, dass sie am 28C3 einen
Datenträger bekommen haben. Damals bestimmt anders zugestellt, es gab noch
keine C3 Post. Heute bin ich Postbote, und ich darf zustellen. Ein Paket.
U: Herzlichen Dank, ach so, das ist deins. Erst nach dem Talk öffnen, machen wir,
ganz herzlichen Dank. T: Dankeschön.
*Applaus*
Herald: Und wenn ihr für einen Malware- Hersteller arbeitet, ich hoffe, dieses
Paket enthält euren Albtraum für heute Nacht. Großen Applaus für Thorsten
Schröder und Ulf Buermeyer!
*Applaus*
*Abspannmusik*
Untertitel erstellt von c3subtitles.de im Jahr 2020. Mach mit und hilf uns!