Linux Basics, Security & Hacking
willi moser (2005-12-12)


 

Wie funktioniert ein WebServer

Die Protokolle

Standardmässig sollte ein Webserver auf die Protokolle

  1. http (Port 80)
  2. https (Port 443)
  3. ftp über http(s)

antworten können. ftp ist meist über ein Modul oder einen Gyteway zum ftp Server eingebunden (Die Anfrage wird einfach weitergeleitet)

 

Die Dateiübertragung zum Client

Im Grunde ganz einfach. Der Client - (Internet Explorer, Firefox, Mozilla, Opera) fragt  http://www.mysite.com/index.html und der Webserver liefert einen Stream mit dem TEXT der angeforderten Datei an den Webbrowser.

für Programmierer: Die Erstellung eines trivialen http-servers ist eine Angelegenheit von - na sagen wir 10 Zeilen

 

Der Http-Request

Natürlich war vorstehendes nur die Minimalversion. Um mit dem Webserver kommunizieren zu können muss natürlich mehr übertragen werden können als nur die Frage nach der Seite. Das erfolgt

The remote HTTP server
allows an attacker to read arbitrary files
on the remote web server, simply by adding
dots in front of its name.

Example:
GET /../../winnt/boot.ini

 

 

Secure Socket Layer SSL
 

Am "https" erkennt Ihr Browser, dass er vom angesprochenen Server ein Zertifikat anfordern soll. Damit der Server dem Browser ein Zertifikat überhaupt zurückschicken kann, muss er sein Zertifikat von der Zertifizierungsstelle erhalten. Anschließend meldet der Server dieses Zertifikat direkt an den Browser zurück. Der Browser erhält dann vom Verzeichnisdienst der Zertifizierungsstelle die Information, ob das Zertifikat noch gültig ist. Anhand dieser übermittelten Daten kann der Browser nun überprüfen, ob er wirklich mit dem Server verbunden ist, der in der URL angegeben ist. Ist das der Fall, gibt Ihnen Ihr Browser eine entsprechende Information. Beim Internet Explorer erkennen Sie das am geschlossenen Bügelschloss. Der Netscape Navigator/Communicator signalisiert eine sichere Seite durch den intakten Schlüssel.

Anschließend verständigen sich die beiden Rechner auf einen symmetrischen Schlüssel. Diese Verständigung passiert in der sicheren asymmetrischen Verschlüsselung. Um wirklich auf Nummer sicher zu gehen, schickt Ihr Browser dem Server vor dem Beginn des eigentlichen Datenaustausches einige Testnachrichten. Diese kann der Server nur beantworten, wenn es wirklich der Server ist, der er zu sein vorgibt.

Betrachtet man noch einmal die drei Ziele der Verschlüsselung: bewirkt das SSL-Protokoll damit eine sichere Verbindung:

1. Ihre Daten sind vertraulich, weil der Inhalt Ihrer Nachrichten nur verschlüsselt über das Netz geht.
2. Die Authentizität des Servers steht fest.
3. Ihre Daten sind vor Manipulation geschützt, da wirkungsvolle Algorithmen prüfen, ob die Daten vollständig und unverändert ihren jeweiligen Empfänger erreichen.

Inzwischen hat sich SSL als Standard für die Browser-Verschlüsselung etabliert. Oft wird aber auch schon TSL verwendet. Die Abkürzung steht für "Transport Layer Security". Das steht nämlich bereits als potenzieller Nachfolger von SSL in den Startlöchern, weil es noch mehr Sicherheit bei der Kommunikation im Internet verspricht. TLS basiert auf dem noch komplizierteren Verschlüsselungsverfahren Triple-DES  (Data Encryption Standard - Datenverschlüsselungs-Standard) oder anderen Algorithmen. Es unterstützt die Verschlüsselung von E-Mails und den Identitätsnachweis für kommerzielle Online-Transaktionen.

 

Wie komme ich zu einem SSL Zertifikat

Lassen Sie sich von Ihrem Server eine Host Key erstellen (AutoSSL z.B.) Lesen Sie bitte die Dokumentationen bei Verisign und Thawte und leider müssen Sie dafür ca 200 USD p.a. ausgeben.

 

SSL Zertifikate selbst erstellen

Ich habe im Jahr 2003 ein Shell Script geschrieben und veröffentlich mit dem man unter RedHat und Derivaten (nach Prüfung vermutlich auf allen Linux'en lauffähig) automatisiert selbstsignierte SSL Zertifikate erstellen kann.

http://www.moser-willi.at/doc/howto/docs/AutoSSL/index.html  ( Englische Dokumentation)

 

 

Die Konfiguration des Apache Webservers

 

Grundlagen - Pfade

Die Konfigurationsdateien sind im Verzeichnis etc/httpd/(conf) [httpd.conf]  und conf.d/ zu finden. Das Webserver-Verzeichnis unter /var/www. Leider gibt es unter den Linux-Distributionen zu wenig Standards. Das Webserver-Verzeichnis kann unter /var, /usr/var, /user/local oder /home zu finden sein und httpd, apache oder inetpub heißen. Das Dokumentenverzeichnis html oder htdocs.

im Falle von RedHat 7.2 sind die Pfade /etc/httpd/conf/httpd.conf, /var/www und var/www/html.

 

Grundlagen - httpd.conf

Bei RedHat kann die httpd.conf prinzipiell mit defaultwerten übernommen werden. Wichtig ist allerdings dass der  FQDN (Fully Qualified Domain Name) am DNS-Server richtig eingetragen ist

.

Wichtige Direktiven

# Der Servertypo sollte standalone sein und beim Starten des Rechners automatisch
# über die etc/rc.d/init.d runlevels eingebunden sein.

ServerType standalone

 

# ist NUR das Verzeichnis wo der Webserver seine Konfigurationsdateien findet.

ServerRoot "/etc/httpd"

 

# Der Server kann an beliebige Netzwerkkarten gebunden werden. * bedeutet alle

BindAddress *

Port 80

 

# ist nur eine Textinformation die bei Fehlerseiten ausgegeben wird.

ServerAdmin webmaster@net.co.at

 

# hier sollte unbedingt der  FQDN (Fully Qualified Domain Name) stehen. Bitte unbedingt Apache Dokumentation
# dazu LESEN!!!!

ServerName net.co.at

 

#  Das Verzeichnis in dem die bereitgestellten WebDokumente (HTML-Seiten) liegen

DocumentRoot "/var/www/html"

 

# Nachstehend die Direktiven zur Einrichtung des gesamten Webspaces Directory / = /var/www
# Danach stehen in der httpd.conf die Direktiven zur Einrichtung des DocumentRoot
# betreffend der Einrichtung von Zugriffs-Restriktiven (.htaccess) bitte die gesonderte Dokumentation lesen.

# First, we configure the "default" to be a very restrictive set of
# permissions.
#
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>

 

# betreffend der Einrichtung von Zugriffs-Restriktiven (.htaccess) bitte die gesonderte Dokumentation lesen.

AccessFileName .htaccess

 

# Es ist möglich über die Deklaration von sogenannten AliasNamen direkt über z.B: http://localhost/icons auf
# das entsprechende Verzeichnis  zugreifen zu können und den Zugriff z.B. mit htAccess Direktiven zu beschränken.

 Alias /icons/ "/var/www/icons/"

<Directory "/www/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

 

# Über die nachstehende Deklaration des Home-Directories kann über http://localhost/~benutzername auf das
# Unterverzeichnis /public_html des Benutzerverzeichnisses öffentlich zugegriffen werden. das heißt damit hat
# jeder unter Linux angelegte Benutzer automatisch eine Hompage

# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>

 

Was ist name-based virtual hosting?

Im DNS sind mehrere DomainNamen auf die gleiche IP-Adresse eingetragen.  Der Apache Webserver erkennt über den Aufruf # der Webseite die gewünschte Domain und stellt diese dem Aufrufer zur Verfügung.

Wie geht das?
Durch die nachfolgende Deklaration  wird dem Webserver das Verzeichnis /var/www/hosts/%0/html
als das Dokumentenverzeichnis der jeweiligen Domain bekanntgegeben
über die Variable %0 wird der entsprechende Domainname den der aufrufende Browser übergeben hat erkannt und von
z.B.  /var/www/hosts/%0/html  in /var/www/hosts/www.net.co.at/html umgewandelt.

somit wird dann die index.html im Verzeichnis
/var
        /www
                /hosts
                        /www.net.co.at
                                                /html
                                                        index.html
 angesprochen.

 Das Verzeichnis www.net.co.at dient als "Webspace" der Domain.
 

# Use name-based virtual hosting.
#
NameVirtualHost *
 

</VirtualHost>

<Virtualhost *>
    Servername %0
    Serveradmin hostmaster@net.co.at
    VirtualDocumentRoot /var/www/hosts/%0/html
    VirtualScriptAlias /var/www/cgi-bin
    CustomLog logs/access_log combined
    <Directory />
        AllowOverride All AuthConfig
    </Directory>
</Virtualhost>

ACHTUNG: Folgende Direktiven sollten eingestellt sein

BindAddress *
NameVirtualHost *
UseCanonicalName Off

 

Den Webserver starten

Mit dem Aufruf setup an der console wird die sysinitv gestartet. Gehen Sie zum Menüpunkt  "system services" und aktivieren Sie httpd. Dann wird Apache beim nächsten systemstart gestartet.

In /etc/rc.d/init.d/ können Sie Apache mit dem Befehl ./httpd start starten.

Zum testen können Sie unter der X-Console mit http://localhost die Testseite aus dem Webbrowser aufrufen.

 

Die Webserver Logs

finden Sie im Verzeichnis /var/log/httpd es sind dies:

Üblicherweise sind diese nur mehr im ECLF (Extended Common Log Format)
Weitere Informationen  unter 3.0 Auditing und Logfile Analyse

 

 

SSL Man in the Middle Angriff

Das SSL-Protokoll wird in vielen Webseiten zur Verschlüsselung der Benutzerdaten verwendet und galt bisher als relativ sicher. Zwar hat Serge Vaudenay bereits letztes Jahr ein theoretisches Konzept für Angriffe auf symmetrische Algorithmen vorgestellt, die auf dem Cipher Block Chaining (CBC) basieren, aber dazu waren zwei Voraussetzungen nötig: Es müssen Fehlerpakete vom Server erzeugt werden.

Die Session wird nicht durch einen Fehler unterbrochen, weil ansonsten eine neue Session mit neuem Key aufgebaut wird.

  1. Der Angreifer startet dabei einen Man-in-the-Middle-Angriff und fängt den Block ab.
  2. An den Server schickt er einen Versuchsblock, den er aus dem Original-Block erzeugt hat.
  3. Die (ebenfalls verschlüsselte) Antwort des Servers ist entweder eine Fehlermeldung, dass die Länge nicht stimmt (PAD) oder dass der Message Authentication Code (MAC) nicht stimmt. Im letzteren Fall weiß der Angreifer, dass er gut geraten hat und mit dem nächsten Byte im Block weitermachen kann.

Welche der beiden Fehlermeldungen nun tatsächlich aufgetreten ist, kann der Angreifer nach Angaben der Wissenschaftler ermitteln, indem er das durchschnittliche zeitliche Antwortverhalten des Servers beobachtet. Bei MAC-Fehlern dauert es nämlich etwas länger, da zusätzliche Anweisungen zur Validierung des MAC nötig sind, die bei einem PAD-Fehler erst gar nicht ausgeführt werden.

Nun kann der Angreifer Logins von Anwendungen, die immer wieder dasselbe Paket schicken, angreifen und nach und nach das Passwort ermitteln. Dankbares Opfer ist zum Beispiel eine E-Mail-Anwendung, die sich per IMAP am Server anmeldet. Hier erhält der Hacker eine Vielzahl von Sessions, da der Client sich sehr häufig authentisieren muss.

Den Wissenschaftlern von Lausanne ist es so gelungen, innerhalb einer Stunde die IMAP-Benutzerdaten einer Outlook-Clients zu ermitteln.

Die Entwickler von OpenSSL haben schon auf die Mitteilung aus Lausanne reagiert und die Versionen 0.9.7 und 0.9.6 so gepatcht, dass dieser Angriff nicht mehr möglich ist, weil die MAC-Validierung ganz einfach trotzdem durchgeführt wird, auch wenn vorher bereits ein PAD-Fehler aufgetreten ist.

Weitere Informationen:

            http://sicherheitskultur.at/man_in_the-middle.htm
            http://www.heise.de/security/artikel/44824

 

Die Patch Climbing Attacke

Der Verzeichnispfad am Rechner : /home/www/hosts/www.moser-willi.at/html/index.html
Der Webspace des HTTP-Servers : http://www.moser-willi.at/index.html
Die Path-Climbing Attack . http://www.moser-willi.at/../../../../icons_apache_1.3.zip

War übrigens nicht nur für Microsoft beim IIS ein Thema ist:

Sehr geehrter Herr Moser,
wir möchten uns für diese Eindringversuche entschuldigen. Nach einem Systemcheck konnten wir ein trojanisches Pferd (backdoor.iiscrack.dll) entdecken und eliminieren. Nach Einspielen der neuesten Microsoftpatches sollte unser System nun immun sein. Vielen Dank für Ihre Informationen ...

Wie gut dass es Leute gibt die HoneyPots haben
Ich hatte übrigens geplant einen Service einzurichten der solche Meldungen analysiert und automatisch die Firma informiert bzw. aktiv als Angreifer tätig wird und bei vulnerability die Firma informiert - das zahlt aber leider niemand!

Das war eine  ziemlich böse Sache war denn die Path Climbing Attack beim IIS ermöglichte das Ausführen von ProgrammCode dieses Trojaners. im Zuge dessen entdeckte ich auch Path Climbing Attacks wie die in der

RUS-CERT-Meldung
[MS/Generic, IIS] Neuer Wurm nutzt mehrere Schwachstellen zur Verbreitung aus (Update)

(2001-09-18 19:56:30+02)

genau beschrieben wird.

Dummerweise ist bekannt leider auch zumeist vergessen. Es gibt brandneue Meldungen dass ein Webserver namens AliBaba genau dieses Problem noch vor kurzem.

 

Unicode und Metachars

IIS Remote-Control 1.0
Microsoft Windows
Microsoft Visual Basic
Dieses Utility nutzt die altbekannte Unicode-Schwachstelle im MS IIS 4.0 und 5.0 aus, um auf dem Webserver über spezielle GET-Anfragen spezifische Kommandos ausführen zu lassen. Die grafische Oberfläche lässt einen Remote-Zugriff zu, wie man diesen von modernen Remote-Control-Programmen wie NetBus oder BackOrifice kennt. Viele typische Kommandos lassen sich über das Manü und mit der Hilfe kleiner Wizards ausführen. Ebenso lassen sich komplizierte und geskriptete Attacken, wie zum Beispiel das Ziel für Distributed Denial of Service-Angriffe nutzen, umsetzen.
 

 

Webserver Denial Of Service

IIS Content Length DoS 1.0
Microsoft Windows
Microsoft Visual Basic
Dieses Utility ist ein proof-of-concept Exploit, der eine Denial of Service-Schwachstelle des MS IIS 5.0 bei der Verarbeitung überlanger Content-Length Zeilen im HTTP-Header ausnutzt.

 

Email Form Spamming

Leider sind die Programmierer of schlampig bzw denken sich nichts dabei wenn ein Webformular unter einer Programmiersprache mit

http://www.spamdomain.com/formmail.qap?to=victim@spam.of&subject=Hey%20YOU&message=Denken%20Sie%20sich%20was%20aus

erreichbar ist. Aber allen wenn Sie den String sehen sollten Sie wissen was los ist.
Jetzt ruf ich die Seite 2 Mio Mal von 20 Rechnern aus auf und schon "isser hin"

        Sein Mailserver sollte eigentlich die SMTP Connection behandeln und geht ein
        und sein Webserver verträgt die vielen Anfragen schon gar nicht

ganz zu schweigen von der Spamzunahme von 75 auf 78%

 

Verzeichniszugriff mit htpasswd

Eine hervorragende Methode um die meisten vom Zugriff auf die Verzeichnisse abzuhalten. Das knacken ist aber relativ einfach. Ein Programm das mit exzellenten Passwortlisten und Benutzernamen einfach solang http Aufrufe macht bis es drin ist. Es gibt keinen Schutz und diese Methode ist auch nicht dazu gedach besondere Sicherheit zu bieten. Das macht der Webserver der im Regelfall NIEMANDEN höher als sein eigenes HomeDir ist gehen läßt.

Webserver - Berechtigungen mit htaccess einrichten

 

Vulnerabilites des Apache 2.0

http://httpd.apache.org/security/vulnerabilities_20.html


Linux Basics, Security & Hacking
willi moser (2005-12-12)