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:

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

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.

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

Und da ich mit Xymon (siehe früherer Artikel) den ClamAV Daemon überwachen kann, werden meine eigenen Server nun auch mit dem ausgestattet.

Die Installation von ClamAV ist dank den Paketquellen äußerst simpel:

1

sudo apt-get install clamav clamav-daemon

Danach kann man die Konfiguration des Daemons starten:

2

sudo dpkg-reconfigure clamav-base

Hier wird man schön durch die einzelnen Schritte geführt. Meistens waren die Standardeinstellungen schon ausreichend, dies liegt aber ganz im Ermessen des Admins:

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

Automatische Verwaltung der Konfigurationsdatei: JA
Socket-Typ: UNIX
Lokaler UNIX Socket: STANDARD
Grosszügier Umgang mit übrig geblibenen UNIX-Sockets: NEIN
eMail-Überprüfung: JA
Archiv-Überprüfung: JA
Maximale Grösse: 50
Maximale Verzeichnistiefe: 0
Symbolischen Links folgen: JA
Normalen Links folgen: JA
Zeitbeschränkung: 0
Anzahl Threads: 12
Anzahl wartende Verbidungungen: 15
Nutzung von Syslog: JA
Protokolldatei: STANDARD
Zeitangaben mitprotokollieren: JA
Zeitspanne für Selbsttest: 3600
Benutzer für Daemon: clamav
Daemon-Gruppe: root
Finish :)

Der Daemon kümmert sich nun darum, dass die Virendatenbank immer aktuell bleibt.

Leider aber ist ClamAV ein sogenannter OnDemand-Scanner, d.h. der Suchvorgang muss gestartet werden, und es wird nicht, wie üblich jede Datei vor dem Verwenden gescant.

Dem kann man jedoch mit einem Cronjob entgegenkommen, und da meine Server nur einem minimalen Risiko ausgesetzt sind, reicht dies auch vollkommen aus. Für einen Server mit High-Availability-Anwendungen sollte man sich einen “richtigen” Scanner zulegen.

Also rufe ich die Cronjobs von Root auf:

23

sudo crontab -e

Da lege ich dann einen neuen Eintrag an:

24

00 01 * * 0 sudo clamscan -ri --quiet --bell --scan-mail --phishing-sigs --phishing-scan-urls --heuristic-scan-precedence --algorithmic-detection --scan-pdf --exclude-dir=^/proc\ / #Scan Root rekursiv, show only infected files

Damit wird jeden Sonntag morgen um Punkt 01:00 Uhr ein Scan ausgelöst, welcher das gesamte Root-Verzeichnis rekursiv durchscannt.

Weiter Informationen zu Zeitangaben für Cronjobs findet man im uu.de-Wiki.

Zum Abschluss würde es mich nun aber doch noch interessieren, wie und ob ihr eure Server den schützt?

Nur leichter einzurichten bedeutet alles andere als schlechter! Wenn ich mich Entscheiden müsste zwischen Xymon (ehemals Hobbit) und Nagios, so würde ich für mich persönlich Xymon nehmen, da mich Nagios mit seinen zahlreichen Funktionen direkt überfordert.

Xymon ist mit den Funktionen nicht ganz so umfänglich, deckt aber die wichtigsten ab. So lassen sich mit Xymon Serverkomponenten wie Harddisks, CPU, Memory, Prozesse, aber auch Dienste wie FTP, SSH, SMTP, POP und vieles mehr überwachen.

Doch wenn man so tief ins System eines Servers eingreifen will, dann braucht man meistens auch einen Agent, welcher die ganzen Daten ausliest.

Dieser Agent ist für Debian-basierte Systeme in den Paketquellen verfügbar und kann wie folgt installiert werden:

1

sudo apt-get install xymon

Während der Installation wird man nach der IP des Datacollectors gefragt, welcher das Webfrontend und damit die ganzen Daten verwaltet.

Nun muss man zusätzlich auch noch Apache installieren, da, aus welchen Gründen auch immer, dieses Paket nicht als Abhängigkeit eingerichtet wurde:

2

sudo apt-get install apache2

Jetzt gilt es noch die Daten aus /etc/hobbit/web über den Browser verfügbar zu machen. Dazu kann man einen Softlink von /var/www zum Ordner mit den Xymon-Webfrontend-Daten:

3

sudo ln -s /etc/hobbit/web /var/www/hobbit

Wenn man nun die IP des Datacollectors im Browser aufruft, so wird dieser bereits automatisch überwacht. Es müssen nun also noch weitere Server zugefügt werden.

Dazu editiert man die Datei /etc/hobbit/bb-host:

4

sudo vim /etc/hobbit/bb-host

Bei mir sieht die Datei so aus:

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

# Master configuration file for Hobbit
#
# This file defines several things:
#
# 1) By adding hosts to this file, you define hosts that are monitored by Hobbit
# 2) By adding "page", "subpage", "group" definitions, you define the layout
#    of the Hobbit webpages, and how hosts are divided among the various webpages
#    that Hobbit generates.
# 3) Several other definitions can be done for each host, see the bb-hosts(5)
#    man-page.
#
# You need to define at least the Hobbit server itself here.
 
#0.0.0.0    .default.    # NOPROPRED:+apt,+libs
 
#group Servers
127.0.0.1    unix
192.168.1.1    router
192.168.1.4    iLO
192.168.1.5    VMware Server
192.168.1.6    Webserver
192.168.1.7    SVN Server
192.168.1.8    Monitoring Server
192.168.1.9    Reverse Proxy
192.168.1.10    DNS Server
192.168.1.11    LTSP Server
 
#group Dialup
#0.0.0.0    notebook.bla.net # noconn dialup

Hier definiert man unter #group Servers zuerst die IP, dann den Namen für die Beschreibung.

In der Datei /etc/hobbit/bb-services kann man Services definieren wie SSH, FTP, SMTP und vieles mehr. Die da angegebenen Standards sind für mich total ausreichend. Besonders interessant für mich, ist die Möglichkeit den ClamAV Daemon zu überwachen.

Wie sich aber die Services auch im Webfrontend anzeigen lassen, habe ich bis jetzt noch nicht herausgefunden.

Weiter gibt es noch die Möglichkeit, bei Fehlern Benachrichtigungen per Mail oder SMS zu versenden. Dazu kann man für jeden Service in der Datei /etc/hobbit/hobbit-alerts.cfg einen eigenen Verantwortlichen, die Alarmierungszeit, Mailadressen und vieles mehr definieren.

Danach zeigt einem das Webfrontend auf einen Blick für jeden Server genau an, welche Server, wo Probleme hat. Unterschieden wird dabei mit den Farben Rot, Violett, Gelb, Grün und Weiss den Zustand des Servers und diverse Symbole, welche angeben, ob ein Server erst seid kurzem oder schon länger Probleme hat.

Dazu werden automatisch Graphen mit Trends und anderen Informationen generiert. Und zu guter Letzt kann man auch noch Reports von Services und Funktionen über bestimmte Zeiträume erstellen.

Nun gilt es noch herauszufinden, wie sich Services überwachen lassen. Wer mir dazu also weiterhelfen kann, vielen Dank

Die Installation war dank einer hervorragenden Anleitung im UU.de-Wiki überhaupt kein Problem. Jedoch, da mein svn nicht öffentlich jedem zugänglich sein soll, habe ich in der /etc/apache2/mods-enabled/dav_svn.conf einen fixen User eingetragen:

<Location /svn>
    DAV svn
    SVNPath /var/local/svn
    AuthType Basic
    AuthName "svn"
    AuthUserFile /etc/apache2/dav_svn.passwd
    Require user compr00t
</Location>

Nach der Installation dann ist mir aufgefallen, das Subversion den ganzen Traffic per http transportiert, was mir nicht so wirklich zusagen wollte.

Also habe ich meinen Apache2 auf Port 443 verschoben, so dass alles per SSL gesichert wird.

Das “Umkonfigurieren” ist eigentlich überhaupt kein Problem, wenn man weiss wie Doch leider hatte ich nur eine wage Ahnung, weshalb sich das ganze über mehrere Stunden in die Länge zog.

Ich versuche hier nochmals wiederzugeben, was ich so alles rumgebastelt habe

Als erstes habe ich einen neuen Virtualhost angelegt unter /etc/apache2/sites-available/ mit dem Namen ssl und mit folgendem Inhalt gefüllt:

<VirtualHost *:443>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/svn/
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Nun wird der neue Virtualhost aktiviert und der alte deaktiviert

sudo a2ensite ssl
sudo a2dissite default

Danach wird Port 443 aktiviert. Dazu überschreibt man die Datei /etc/apache2/ports.conf mit folgendem Eintrag:

Listen 443

Jetzt fehlt noch ein Zertifikat für die gesicherte Verbindung. Dazu muss das Packet openssl installiert sein:

sudo apt-get install openssl

Nun kann man sein Zertifikat erstellen:

mkdir -p /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem\
-keyout /etc/apache2/ssl/apache.pem

Jetzt muss nur noch das Module ssl aktiviert werden:

sudo a2enmod ssl

Jetzt gilt es noch den Apache neuzustarten:

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/apache2 force-reload

Und wenn beim restart kein fail als Antwort rauskommt, so sollte ab sofort die Weboberfläche nun über https://localhost/svn verfügbar sein.

Ich hoffe mal, ich habe nichts vergessen

Als nächstes ist nun geplant, die etwas zu schlichte Weboberfläche von Subversion durch Websvn zu ersetzten.

Dabei wollte ich vorallem den SSH-Zugang besser schützen, mindestens vor automatisierten Bruteforce-Attacken.

Dabei bieten sich mir diverse Möglichkeiten:

• Keyfiles
• PermitRootLogin
• AllowUsers
• Portänderung
• fail2ban
• PortKnocking
• OTP

Als erstes habe ich mal das einloggen vom User “root” verboten. Damit sind bereits 80% aller automatisierten Attacken erfolglos.

PermitRootLogin

Dazu setzt man unter

/etc/ssh/sshd_config

hinter dem Punkt PermitRootLogin ein

no

AllowUsers

Noch besser als das Login als root zu verbieten, ist es, nur bestimmte User zuzulassen.

Dazu muss man in der Datei

/etc/ssh/sshd_config

unter dem Punkt AllowUsers alle Benutzer eingeben, welche Zugriff haben dürfen:

AllowUsers user1 user2 user3

Keyfiles

Keyfiles sind auch noch eine gute Möglichkeit um automatisierte Angriffe abzublocken. Denn, wer die passenden Keyfiles nicht hat, kann sich auch mit dem richtigen Passwort nicht einloggen.

Doch für mich persönlich sind Keyfiles eher unpraktisch, da ich mich oft von verschiedenen Maschinen aus einloggen soll, und meistens da die Keyfiles dann fehlen würden.

Portänderung

Gegen automatisierte Angriffe kann auch eine Umstellung der Ports über welche SSH (22) kommuniziert, helfen.

Das Problem jedoch, mit einem kurzen Scan kann man aufdecken, auf welchem Port SSH nun wirklich läuft.

Ändern kann man den Port unter dem Punkt

Port

in der Konfig von SSH unter

/etc/ssh/sshd_config

fail2ban

Mittels dem Tool fail2ban kann man eine IP Adresse nach einer vordefinierten Anzahl fehlgeschlagener Logins automatisch sperren.

Dies ist besonders praktisch, da ich somit nicht nur ein Mittel gegen automatisierte sondern auch gegen jegliche andere SSH Attacken habe.

Und mitels fail2ban kann man nicht nur den Zugriff auf SSH, sondern auch noch für unzählige andere Dienste wie Appache, DNS, FTP und viele mehr.

fail2ban gibt es auf den Ubuntu Packetservern über

sudo apt-get install fail2ban

Nach der Installation heisst es erst mal Einstellungen bearbeiten. Die Konfig ist unter

/etc/fail2ban/jail.conf

abgelegt.

Um den SSH Zugriff überwachen zu lassen, gilt es folgenden Textschnippsel noch zu ergänzen:

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3

Damit wird jede IP-Adresse, welche sich 3mal mit falschem Passwort einloggen will, automatisch gebannt.

Portknocking

Eine weitere, sehr effektive Massnahme ist das sogenannte Portknocking. Das beschreibt ein Verfahren, bei welchem man zuerst mit dem geheimen Zeichen anklopfen muss, bevor man sich per SSH einloggen kann.

Wird das geheime Zeichen nicht vorweg gesendet, so erscheint der Port 22 nach aussen als geschlossen.

Realisieren lässt sich dies mittels knockd, welches wiederum in den Packetquellen verfügbar ist

sudo apt-get install knockd

Konfiguriert wird das Programm über eine zentrale Datei

/etc/knockd.conf

Um knocked nun auf den SSH Port vorzubereiten, muss man die Datei mit folgenden Eintrag ergänzen:

[openSSH] sequence = 1234,1234,1234 seq_timeout = 5 command =
/sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

[closeSSH]
sequence = 1234,1234,1234
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j DENY
tcpflags = syn

Will man sich nun per SSH einloggen, so muss man zuerst mittels

knock ip 1234 1234 1234

den Port freischalten. Nach vollbrachter Arbeit wird der Port über selbiges Kommando auch wieder geschlossen.

OTP

OTP ist ein Verfahren, mittels welchem für jedes Login ein neues Passwort generiert wird. Hier bedanke ich mich bei Benjamin für den Gedankenanstoss und die ausführliche Anleitung.

Er beschreibt dabei wie OTP in Kombination mit seinem Android Handy verweden kann. Doch auch iPhone-Benützern wie mir wird mit dem Tool “OTP Generator” von Dragon Technology Ltd geholfen, welches für CHF 3.30 im Appstore verfügbar ist.

Fazit

Für mich ist fail2ban und PermitRootLogin am besten geeignet. Obwohl ich der Meinung bin, das Portknocking wohl das effektivste wäre, weiss ich noch nicht, ob ich mein “Geheimzeichen” auch von anderen Betriebssystemen aus versenden kann. Deshalb ist dieses Verfahren vorerst mal auf Eis gelegt.

OTP ist für mich schon fast wieder übertriebene Sicherheit, und der Aufwand, jedes mal ein neues Passwort zu generieren ist mir einfach zu gross.

Natürlich ist ein offener SSH Port immer ein Sicherheitsrisiko, aber mit den obig aufgezeigten Möglichkeiten, sollte man 95% aller Attacken abwehren können.

Und sonst gilt halt immer noch: Wählt ein sicheres Passwort

[Quellen: 4t2, Horst und FreiesMagazin]

Doch nun gibt es handfeste Beweise! Der Programmierer Ruben Unteregger, ehemaliger Angestellter des Schweizer Unternehmen ERA IT Solutions, packt aus.

Für den Trojaner selbst und dessen Entwicklung gilt zwar Geheimhaltungspflicht, doch die Softwarerechte sind immer noch im Besitz von Ruben, weshalb er den Sourcecode auch teilweise unter der GPL veröffentlichen konnte.

Details zu Ruben und seiner Arbeit bei ERA IT Solutions findet man in einem Interview mit ihm, welches durch Gulli zustande kam.

Der Trojaner selbst gibt es in zwei Versionen: Mini- und Megapanzer.

Der Megapanzer wurde nur Stückchenweise veröffentlicht, wogegen der Minipanzer, die abgespeckte Version, voll und ganz verfügbar ist.

Da leider ein Geheimhaltungsvertrag zwischen Ruben und seinem Ex-Arbeitgeber besteht, gibt es nur Spekulationen über den Auftraggeber und leider keine eindeutigen Beweise, dass da wirklich die Regierung mit drinhängt!

Laut Ruben bietet der Trojaner noch keinen Support für Linux, erst für Windows XP. Doch wie lange das wohl noch so bleibt?

Ich finde das ganze sehr beunruhigend, sollte da tatsächlich die Regierung mitmischen! Gleichzeitig habe ich grossen Respekt vor Ruben und vor seiner Arbeit und dem Schritt, den Code öffentlich zu machen.

Wäre es da nicht besser, wenn man alles in einem Gerät hätte?

So hat mich einer meiner Lehrer auf den richtigen PC aufmerksam gemacht: ALIX.

Dies ist

- ein voll funktionsfähiger Computer
- mit weniger Ressourcen
- kleinem Stromverbrauch
- Massen nicht grösser als ein herkömmlicher Router
- schweizer Produkt
- und (fast) beliebigt erweiter- und kombinierbar

Der PC selbst muss man sich hier zusammenstellen. Je nachdem welches Mainboard man wählt, hat man mehr oder weniger Anschlüsse. Ich habe mich für den Alix2d2 entschieden. Dieser hat zwei miniPCI, zwei USB- und zwei LAN-Anschlüsse.

Als Storage kommt eine 4GB Flash-Karte zum Einsatz, welche in den Tests mehr als gereicht hat.

Das perfekte OS nennt sich IPFire. Dies ist ein Betriebssystem auf Linuxbasis, welches man mit Addons erweitern kann. Deshalb ist es nicht nur eine klasse Firewall, sondern kann auch als VPN-, Mail-, P2P-Server und vieles mehr verwendet werden.

Doch nicht nur das, dank den zwei LAN-Anschlüssen kann das Kästchen auch als Router verwendet werden. Und wenn man sich auch noch eine WLAN-Antenne dazukauft, so darf man auch noch ein WLAN vor den Router hängen

Rundum eine eierlegende Wollmilchsau!