36C3 - Finfisher verklagen

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!