Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

Volatility

Das Werkzeug mit der größten Funktionalität ist das Open-Source-Framework Volatility. Die in Python geschriebene Software wird bisher vor allem zur Analyse von Windows verwendet. Seit 2011 gibt es auch eine Version, die es ermöglicht, den Arbeitsspeicher von Linux-Systemen zu untersuchen [14]. Aktuell wird deren ursprüngliche Codebasis im Branch »scudette« überarbeitet. Ziel ist es, die Windows- und Linux-Version zu vereinen.

Eine Schwierigkeit bei der Arbeitsspeicheranalyse unter Linux ist, dass verschiedene Kernelversionen unterschiedliche Speicherlayouts aufweisen. Diese Problematik löst Volatility durch sogenannte Kernelprofile, die für jede Kernelversion eigens erstellt werden müssen. Ein Profil besteht aus der Datei »System.map« und den Debug-Informationen des verwendeten Kernels. Die Datei »System.map« , welche sich im Verzeichnis »/boot« befindet, enthält die Adressen der Datenstrukturen und Funktionen. Für das Extrahieren der Debug-Informationen aus dem laufenden Kernel muss das Werkzeug »dwarfdump« auf dem System installiert sein. Ist das der Fall, so erzeugt das Makefile im Verzeichnis »tools/linux« automatisch die Datei »module.dwarf« , welche die nötigen Informationen enthält. Abschließend müssen beide Dateien noch in ein Zip-Archiv gepackt werden: »zip ubuntu1110.zip /boot/System.map-3.0.0-19-generic module.dwarf«

Die Analysefunktionen von Volatility realisieren Plugins. Dadurch ist es Forensikern möglich, das Analyseframework sehr leicht um eigene Funktionen zu erweitern. In der ursprünglichen Version für Linux verfügte Volatility bereits über 15 verschiedene Plugins. Neben den schon aus Draugr und Volatilitux bekannten Funktionen, erlaubt es Volatility beispielsweise auch, aktive Netzwerkverbindungen anzuzeigen oder alle geladenen Kernelmodule auszugeben. Im aktuellen Branch »scudette« sind jedoch noch nicht alle Plugins neu implementiert, was beim Aufruf zu Fehlermeldungen führt.

Analysebeispiel

In diesem Abschnitt, wird die Analyse eines kompromittierten Linux-Servers mithilfe von Volatility demonstriert. Das hier verwendete Festplattenimage »victoria-v8.sda1.img« und das Arbeitsspeicherabbild »victoria-v8.memdump.img« stammen aus der Honeynet Challenge 7 – Forensic Analysis of a Compromised Server [15]. Auf Grundlage der Analyse, sollen in der Challenge folgende Fragen beantwortet werden:

  • Welche Prozesse sind auf dem System gelaufen?
  • Welcher Dienst wurde angegriffen?
  • Welche Schwachstelle wurde ausgenutzt?
  • War der Angriff auf das System erfolgreich?
  • Welche Absicht hatte der Angreifer?
  • Wurden Informationen vom Angreifer gestohlen?

Bevor mit der Untersuchung des Arbeitsspeichers begonnen werden kann, muss zunächst ein Kernelprofil erstellt werden. Im ursprünglichen Branch von Volatility für Linux war ein Profil für das betroffene System bereits enthalten. Es handelte sich dabei um eine »vtypes« -Datei, die jedoch nicht identisch mit der »module.dwarf« ist. Zwar unterstützt der aktuelle Branch Scudette auch Zip-Archive, die aus einer »vtypes« -Datei und der »System.map« des Kernels bestehen, jedoch ließ sich damit das kompromittierten Linux-System nicht fehlerfrei analysieren. Deshalb ist es an dieser Stelle notwendig, nachträglich ein neues Profil zu erstellen.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019