Nuit du Hack 2012 Quals –
Unknown text

Nuit du Hack 2012 - Unknown text - task description

Zu Beginn dieser Challenge (Unknown text) erhalten wir eine Email von Jessica, die uns mitteilt, dass sie einen unverständlichen -möglicherweise verschlüsselten- Text erhalten hat und beauftragt uns damit, weitere Informationen aus diesem Text zu gewinnen und im besten Fall zu entschlüsseln.

Ein ersten Blick auf den Text lässt uns sofort folgendes feststellen:
– bei den Buchstaben des Textes handelt es sich ausschließlich um Kleinbuchstaben
– die Verteilung der Leerzeichen zeigt, dass nur die Buchstaben verschlüsselt wurden
– die Sonderzeichen im unteren Teil lassen einen Quellcode (Assembler?) vermuten

Mein erster Gedanken bei solchen Texten geht immer in Richtung Caesar-Verschlüsselung und obwohl Wörter wie “nrnvlqqq” schon vermuten lassen, dass es sich nicht um Caesar handelt (da sonst wieder ein Wort mit drei gleichen Buchstaben am Ende entstehen würde) probieren wir es dennoch aus.
Continue reading

RuCTF 2012 Quals –
The password generator

RuCTF 2012 - The password generator - task description

Bei dieser Challenge (The password generator) geht es darum, an das Passwort eines Administrators zu gelangen. Alles, was wir kennen, sind die Kommandos, die verwendet wurden, um das Passwort zu generieren und der Hinweis auf ein “wohl bekanntes” Betriebssystem.

Beginnen wir also zunächst einmal, die angegebenen Kommandos nacheinander zu analysieren und deren Funktionsweise in einen Gesamtzusammenhang zu bringen.

cd ~

Relativ simpel – der Administrator wechselt zu Beginn der Operationen in sein Heimatverzeichnis.

vi ./.cshr

Als nächstes wir die Datei “.cshr” im Heimatverzeichnis editiert. Die gezielte Suche nach dieser Datei lässt einen Zusammenhang mit der “csh” (c-Shell) erkennen, die zumeist auf BSD-Systemen zum Einsatz kommt. Bei der Datei, die meist als “.cshrc” referenziert wird, scheint es sich um eine der Dateien zu handeln, die beim Login des Benutzers abgearbeitet werden und in der -ähnlich der “.bashrc”- Umgebungsvariablen und ähnliches gesetzt werden. Was genau hier editiert wurde, lässt sich nur erahnen.
Continue reading

RuCTF 2012 Quals –
Discern utility

RuCTF 2012 - Discern utility - task description

Die Aufgabenstellung (Discern utility) spricht von einer aufgefundenen Datei und verlangt von uns festzustellen, was der deren Inhalt beschreibt. Bei dem Dokument selbst handelt es sich nur um eine Textdatei, deren Inhalt mit 73 Zeilen recht überschaubar ist. Ein erster Blick in die Daten zeigt uns:

brk(0)                                  = 0x2335000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9bfad31000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=117316, ...}) = 0

Hierbei handelt es sich um “System Calls” (Syscalls), das heißt, rudimentäre Systemfunktionen, die im Kernel verankert sind und aus denen die Funktionalität aller komplexen Programme aufgebaut wird. Welche Syscalls ein Programm verwendet, lässt sich mit dem Werkeug “strace” herausfinden. Und genau dieses Werkzeug wurde auch hier verwendet um die Aufgabe dieser Challenge zu stellen.

Um die Aufgabe zu lösen müssen wir also herausfinden, welches Werkzeug die uns zur Verfügung gestellte strace-Ausgabe liefert. Sehen wir uns dazu die gesamte Textdatei an und versuchen, Merkmale des aufgerufenen Programmes zu identifizieren. Folgende Syscalls sollten hierbei auffallen:
Continue reading

CodeGate 2012 Quals –
forensics #3

CodeGate CTF 2012 - Forensics #3 - task description

In dieser Challenge (forensics #3) geht es darum, eine schadhafte URL ausfindig zu machen, die für die Infizierung des Zielsystem verantwortlich ist. Gemäß der Aufgabenstellung wurde die URL nach dem 9. Februar 2012 aufgerufen und die Spuren des Aufrufs möglicherweise nach der Infizierung gelöscht.

Das Entpacken der Datei liefert uns wieder ein Benutzerverzeichnis eines Windows-Systems. Es handelt sich erneut um die Daten, des uns bereits bekannten Benutzers “proneer”. Diesmal ist jedoch nicht das komplette “Users”-Verzeichnis enthalten, sondern nur die “Cookies”-Datei des Google Chrome Browsers.

rup0rt@lambda:~/forensic3$ file Cookies
Cookies: SQLite 3.x database

Eine erste Analyse der Datei zeigt uns, dass Google Chrome seine Cookies anscheinend in einer SQLite-Datenbank hinterlegt. Um diese Datei zu betrachten zu können und die darin enthaltenen Cookies auszulesen, verwenden wir das Werkzeug sqlitebrowser und erhalten eine Übersicht der insgesamt 109 gespeicherten Cookies.
Continue reading

CodeGate 2012 Quals –
forensics #2

CodeGate CTF 2012 - Forensics #2 - task description

In dieser Challenge (forensics #2) scheint es das Ziel zu sein, den Versuch eines SQL-Injection-Angriffes ausfindig zu machen. Als einzigen Hinweis erhalten wir die Information, dass der Browser beim Ausführen der SQL-Injection abgestürzt ist.

Beim Entpacken der Dateien stellen wir direkt fest, dass es sich (wieder) um das Benutzerverzeichnis eines Windows-Systems handelt. Wiederum sind es die Daten des Benutzers “proneer” (vermutlich war es sogar das selbe Archiv, wie in der Forensic #1 – Challenge).

Wonach suchen wir nun am cleversten in den Benutzerdaten? Wir wissen, dass der Browser beim SQL-Angriff abgestürzt ist und wir wissen auch – und kennen das vermutlich aus eigener Erfahrung -, dass Browser beim Schließen die letzten Sitzungen speichern und beim erneuten Öffnen dem Benutzer wieder anbieten. Unser Ziel ist es also, zuerst den verwendeten Browser zu identifizieren und in einem zweiten Schritt zu versuchen, die Aktionen der letzten Sitzung zu rekonstruieren.

rup0rt@lambda:~/forensic2/Users/proneer/AppData/Local$ ls
010 Editor           History                Temp
Adobe                IconCache.db           Temporary Internet Files
Apple                Microsoft              VirtualStore
Application Data     Microsoft_Corporation  VMware
GDIPFONTCACHEV1.DAT  Microsoft Help
Google               Mozilla
rup0rt@lambda:~/forensic2/Users/proneer/AppData/Local$ ls Google/
Chrome  CrashReports  Google Talk
rup0rt@lambda:~/forensic2/Users/proneer/AppData/Local$ ls Mozilla/
Firefox
rup0rt@lambda:~/forensic2/Users/proneer/AppData/Local$ ls Microsoft
Assistance    Feeds Cache           Office        Windows Mail
CoreCon       Internet Explorer     VisualStudio  Windows Media
Credentials   Media Player          VSA           Windows Sidebar
Event Viewer  Microsoft SQL Server  VSTAHost
Feeds         MSDN                  Windows

Ein Blick in die lokalen Anwendungsdaten zeigt uns, dass zumindest für die drei gängigsten Browser (Chrome, Firefox und Internet Explorer) Verzeichnisse existieren. Um herauszufinden, welcher zuletzt verwendet wurde, sehen wir uns die Zeitstempel der Sitzungsdateien an.
Continue reading

CodeGate 2012 Quals –
forensics #1

CodeGate CTF 2012 - Forensics #1 - task description

Das Ziel dieser Challenge (forensics #1) ist es also, eine Datei, sowie deren Größe zu finden, die vom System gestohlen wurde. Die Aufgabenstellung liefert uns die Dateien des angegriffenen Benutzers sowie die Information, dass es sich bei der gesuchten Datei um ein Excel-Dokument mit Finanzdaten handelt und auf dieses vermutlich nach 14.00 Uhr (UTC+9), also während des Diebstahls zuletzt zugegriffen wurde.

Wir entpacken also als erstes die mitgelieferte 7zip-Datei und verschaffen uns einen Überblick über deren Inhalt. Bereits beim Extrahieren fällt auf, dass es sich hauptsächlich um das Benutzerverzeichnis eines Windows-Systems handelt und hier insbesondere um den Benutzer “proneer”.

rup0rt@lambda:~/forensic1$ ls Users/
All Users  Default  Default User  desktop.ini  proneer  Public

rup0rt@lambda:~/forensic1$ ls Users/proneer/
AppData           Music             Pictures
Application Data  My Documents      PrintHood
Contacts          NetHood           Recent
Cookies           NTUSER.DAT        Saved Games
Desktop           NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TM.blf                                      
Documents         NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TMContainer00000000000000000001.regtrans-ms 
Downloads         NTUSER.DAT{6cced2f1-6e01-11de-8bed-001e0bcd1824}.TMContainer00000000000000000002.regtrans-ms 
Favorites         ntuser.dat.LOG1   Searches                                                                           
Links             ntuser.dat.LOG2   SendTo                                                                   
Local Settings    ntuser.ini        Start Menu
Templates         Videos

So, nun wissen wir entweder wo Office zuletzt verwendete Dokumente ablegt oder wir müssen das Dateisystem per Hand durchsuchen. Zuerst versuche ich mit dem Werkzeug “find” alle Excel-Dateien aufzulisten, was jedoch kein Ergebnis liefert. Also durchsuche ich im “grep” den Inhalt aller Dateien nach Hinweisen auf Excel-Dokumente.
Continue reading

PCAP Repair Tutorial (pcapfix)

In diesem Dokument wird beschrieben, wie man ein PCAP File manuell reparieren kann bzw. wie man an solch ein Problem heran geht. Wer seine Datei nicht manuell raparieren möchte, kann auch das Werkzeug “pcapfix” verwenden.

1.    Fehlerhaftes PCAP öffnen und Fehlercode analysieren

In diesem Beispiel wird die Datei “file1.pcap” verwendet.

PCAP Repair Tutorial - Wireshark broken PCAP file

Bei diesem PCAP File wird das Format nicht erkannt, was auf ersten Anblick einen fehlerhaften File Header vermuten lässt.

2.    Eigenes PCAP erstellen und mit dem fehlerhaften vergleichen

Man erzeugt als erstes ein eigenes, neues PCAP File “file2.pcap”, z.B. mit tcpdump.
Als nächstes springt man an den Anfang der Datei und untersucht das erste Paket.

PCAP Repair Tutorial - examine proper PCAP file

Der Anfang ist hier HEX: FF FF FF FF FF FF 00 30 05 7C D2 4A 08 06
Dabei handelt es sich um die MAC Adressen im Ethernet Header.
Davor würden sich noch 16 Bytes für den Packet Header ergeben, welche man in Wireshark nicht angezeigt bekommt. Jedoch sollte man diese im Hinterkopf behalten!!!
Als nächstes vergleicht bzw. sucht man diese HEX Werte im file2.pcap im Hex Editor. Diese Werte findet man relativ am Anfang des Files wieder.
Lediglich 40 Bytes sind noch voran gestellt. Dabei bestimmen 16 Bytes den Packet Header des ersten Paketes und 24 Bytes umfassen den Global Header des Files.
Continue reading