Bits, Bytes and my 5 cents

Nein, Google versucht sich noch nicht als Käsehersteller!
Unter dem Codewort Jarlsberg führt die Google Code University ein Projekt zum Thema Schulung in Sicherheit für Webapplikationen.

This codelab shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you’ll get a chance to do some real penetration testing, actually exploiting a real application.

Für alle die, welche dem Englisch nicht so mächtig sind: Jarlsberg ist eine Webapplikation von Google zum Thema Web Application Security. Basierend auf Python wird jedem Benutzer in einer eigenen Session eine Webseite präsentiert voll mit Sicherheitslücken von XSS über DOS bis hin zu XSRF und Path Traversal.

Neben dieser Webseite gibt es auch noch eine sehr ausführliche und gut erklärte Dokumentation zu jedem Exploit mit einer Erklärung wie man diesen auch beheben könnte (verfasst in Englisch).
Nachdem ich die Dokumentation nun mal komplett durchgearbeitet habe, muss ich sagen, es lohnt sich wirklich die 5 Seiten komplett zu lesen!
Jedoch muss ich auch sagen, in meinen Augen sind ein paar der vorgestellten Exploits ein wenig Realitätsfremd, da man z.B bei einem Pentest nur sehr wenig direkten Zugang zum Sourcecode hat.

Nichts desto trotz, wer es selbst mal ausprobieren will, und das kann ich wirklich jedem empfehlen, der klickt nun hier:

ARP steht für Address Resolution Protocol und kann anhand einer IP-Adresse die zugehörige MAC-Adresse abfragen.
Es ist dabei im OSI-Modell auf Schicht 2, der Sicherungsschicht, angesiedelt und spielt eine bedeutende Rolle für das Internetprotokoll.

Doch interessanter als das Protokoll ist was man damit machen kann
Ist in einem Netzwerk ARP freigegeben (was auch häufig der Fall ist), so kann man dies in Kombination mit einem Switch zu einer Man-in-the-Middle-Attacke verwenden.

Doch von vorne! Es gibt zwei “Probleme”:
Problem 1…
Der Client führt eine Cache, wo er eine IP- einer MAC-Adresse zuordnet. Dies wird verwendet, dass nicht vor dem Versenden eines Datenpaketes jedes mal zuerst noch eine neue Abfrage der MAC-Adresse gemacht werden muss.
Dieser Cache kann aber von einem anderen Client mit den nötigen Mitteln verändert werden. D.h. ich als Angreifer kann den Cache des Opfers so verändern, dass der IP-Adresse eines z.B. gerade eben besuchten Servers nicht mehr die tatsächliche MAC-Adresse des Servers, sondern eine beliebige zugeordnet wird.

Das alleine wäre ja noch nicht so schlimm, wäre da nicht noch Problem 2…
Hier kommt dann der Switch ins Spiel. Ein Switch hat gegenüber einem Hub einen grossen Unterschied. Ein Hub sendet den Traffic von einem Port einfach an alle anderen aktiven Ports, in der Hoffnung, dass nur derjenige den Traffic liest, welcher ihn auch angefragt hat.
Der Switch hingegen; damit der Traffic nicht jedes mal an alle Ports versandt werden muss, führt eine Zuordnungsliste, wo festgelegt wird, welches Gerät (anhand der MAC-Adresse) an welchem Port angeschlossen ist.

Auch Problem 2 wäre alleine kein Problem, doch zusammen!!
Ein Angreifer manipuliert den Cache eines Clients nun so, das die IP-Adresse des Server nicht mehr der MAC-Adresse des Server, sondern der des Angreifers zugeordnet ist.
Da der Client davon nichts mitbekommt, nimmt er die MAC-Adresse des Angreifers aus seinem Cache, in der Meinung es wäre die Adresse des Servers und schickt diese mit seinem Datenpaket zum Switch.
Der Switch nun liest die MAC-Adresse aus und erkennt die MAC-Adresse des Angreifers. Beim Vergleich mit seiner Zuordnungsliste wird das ganze Paket nun nicht mehr an den Switchport des Servers, sondern an den des Angreifers versandt.
Macht der Angreifer das gleiche nun auch noch mit dem Server, so kann er jeden Traffic zwischen einem Client und einem Server mitlesen und beliebig manipulieren.

Man sagt ja, in der Theorie ist es meistens einfacher, als in der Praxis. Das Problem von ARP Spoofing ist aber, dass dies hier nicht stimmt!!
Mit nur wenigen Klicks und einem Paket aus den Ubuntu Paketquellen lässt sich mittels ARP Spoofing eine komplette Man-in-the-Middle-Attacke durchführen.
Wie genau – das soll jeder alleine herausfinden, doch das Paket dsniff könnte helfen

Da ich soeben einen neuen PC erhalten habe, musste ich mein Fedora 12, mit welchem ich mich während der Arbeit rumschlage, neu installieren.
Das ganze war ja keine wirklich grosse Sache, neu installieren, Paketliste importieren und Home-Verzeichnis kopieren.
Trotzdem gibt es ja auch noch Pakete wie VMware Workstation, welche nicht im Repository gelistet sind.
Und gerade zum Testen finde ich VMware das beste was es gibt.

Die Installation von VMware ist ja spätestens seit Workstation 7 überhaupt kein Problem mehr. Downloaden, ausführen und dem Agent folgen. Doch nach der Installation, noch vor dem ersten Start, meldet VMware Workstation, dass es gerne noch ein paar Module kompilieren und in den Kernel laden würde. Doch als nach 20 Minuten immer noch nichts passiert ist, wurde ich stutzig.

Also habe ich mir während dem Starten mal die laufenden Prozesse angesehen, und auffällig war, dass sobald VMware mit seinen Anpassungen loslegen sollte, schnelle SELinux in die Höhe…

Also habe ich SELinux mal temporär deaktiviert:

1

echo 0 >/selinux/enforce

Und man glaubt es kaum, plötzlich macht auch VMware was es sollte…
Für mich wirft sich nun die Frage auf, wieso SELinux blockiert, ohne etwas zu melden?

Will man SELinux dann wieder aktivieren reicht ein reboot oder folgender Befehl:

1

echo 1 >/selinux/enforce

Oder man macht es wie ich und setzt in der Datei /etc/selinux/config den Punkt SELINUX auf disabled:

1
2
3

# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:

Nun ist SELinux nach einem Reboot komplett deaktiviert und wird sich nie mehr einmischen.

Besonders an einem Wartungsfenster ist die Enable/Disable-Funktion von Hobbit sehr hilfreich.
Schliesslich soll Hobbit ja nicht gleich jedes mal die Kavallerie alarmieren, nur weil während ein paar Wartungsarbeiten ein Server mal nicht verfügbar ist.
Doch bevor man Funktionen per WebGUI verwalten kann, muss man sich ein Passwort und einen berechtigten User setzen.

Dazu verwendet man am einfachsten htpasswd:

1

sudo htpasswd -c /etc/hobbit/hobbitpasswd admin

Nun gibt man zwei Mal das gewünschte Passwort ein, und schon ist die Arbeit getan.
Nun kann man auf seinem Hobbitserver das WebGUI aufrufen und unter Administration > enable/disable zuerst den Server, und dann den gewünschten Server oder auch gleich alles deaktivieren. Einloggen kann man sich mit dem Benutzernamen admin und dem eben gewählten Passwort.

Weiter kann man noch einen Grund vermerken und je nach Dauer zwischen automatischem oder manuellem reaktivieren der Überwachung wählen.

Ganz praktisch ist auch der letzte Punkt, mit welchem man das Deaktivieren der Überwachung auf die Minute genau 5 Jahre im voraus planen kann