Die in About Security #207 beschriebenen Angriffe sind ein aktuelles Beispiel, wie ein Angreifer eine gerade erst entdeckte Schwachstelle ausnutzen kann, bevor sie beim Opfer überhaupt bekannt ist.

Verstecken als Gegenmaßnahme?

Wie schützt man sich vor Angriffen auf solche Schwachstellen? Im Prinzip klingt das unmöglich - wie soll man sich vor etwas schützen, das man gar nicht kennt? In About Security #206 wurden einige Möglichkeiten beschrieben, wie eine Identifizierung des Webservers zumindest erschwert wird. Das "nicht erkannt werden" bietet aber keinen wirksamen Schutz und ähnelt mehr dem Sankt-Florian-Prinzip: "Lieber Angreifer, lass meinen Webserver in Ruhe und greif die an, die Du leichter erkennen kannst!" Das klappt vielleicht bei Angreifern, die es nur auf irgend einen Server abgesehen haben, ist aber wirkungslos, wenn der eigene Server bereits als Ziel auserkoren wurde und es nur noch um das "wie kommt man rein" geht. Die in About Security #207 beschriebenen Angriffe funktionieren unabhängig davon, ob sich der Server korrekt als ein betroffener IIS-Server oder z.B. als "Plattfußindianer 1,314 auf PDP/11" identifiziert. Ist die Schwachstelle vorhanden, kann sie auch ausgenutzt werden. Im Zweifelsfall kann der Angreifer also einfach eine Reihe von Exploits für verschiedene Webserver ausprobieren, irgend einer davon wird schon funktionieren.

"Klein machen"

Wenn verstecken nicht hilft, hilft "sich klein machen" auch nicht, jedenfalls im Kinderspiel. Bei Webservern sieht das etwas anders aus. "Klein machen" bedeutet in diesem Fall, nur die wirklich verwendeten Funktionen zu aktivieren und nur die dafür wirklich benötigten Erweiterungen zu installieren. Um zum Beispiel aus About Security #207 zurück zu kommen: Die Schwachstelle kann nur ausgenutzt werden, wenn WebDAV aktiviert ist. Dabei gibt es drei Möglichkeiten:

• WebDAV wird nicht benutzt und ist auch nicht aktiviert
  In diesem Fall ist der Server nicht angreifbar - die Schwachstelle ist nicht vorhanden
• WebDAV wird benutzt und ist deshalb aktiviert
  In diesem Fall ist der Server angreifbar, und evtl. kann nicht mal der Workaround "WebDAV deaktivieren" eingesetzt werden, weil das den normalen Betrieb zu sehr stört
• WebDAV wird nicht benutzt, ist aber aktiviert
  Die ist der ungünstigste Fall: Der Server ist angreifbar, obwohl das gar nicht notwendig wäre

Wie man am dritten Punkt sieht, trägt das Deaktivieren nicht genutzter Funktionen und Erweiterungen sehr zur Sicherheit des Webservers bei: Es reduziert die Angriffsfläche auf das zum Betrieb notwendige Minimum. Jede nicht benötigte Funktion oder Erweiterung kann einem Angreifer helfen, während man selbst nichts davon hat.

Während das "Tarnen" des Webservers nur vor zufälligen Angriffen "schützt", ist das Deaktivieren bzw. Deinstallieren nicht benötigter Funktionen und Erweiterungen ein effektiver Schutz auch vor gezielten Angriffen auf/über Schwachstellen darin.

Aber was ist mit Angriffen auf die benötigten Funktionen und Erweiterungen? Außer der sicheren Konfiguration des Webservers, um die es später noch geht, gibt es dafür nur eine Lösung: Man muss ständig über neu entdeckte Schwachstellen informiert sein, um mögliche Workarounds umzusetzen oder vorhandene Patches zu installieren, bevor ein Angreifer die Schwachstellen ausnutzen kann

Wissen, was der Angreifer weiß...

... ist nicht vollständig möglich. Es besteht immer die Möglichkeit, das Opfer einer bisher nicht bekannten Schwachstelle zu werden. Aber realistisch betrachtet, ist die Gefahr für einen normalen Webserver sehr gering. Es gibt sehr viele Webserver, aber nur sehr wenige 0-Day-Exploits. Und nach den ersten paar Einsätzen sickert ein 0-Day-Exploit durch, und die Schwachstelle wird bekannt. Sofern man nicht gerade einen aus welchen Gründen auch immer für einen Angreifer mit einem 0-Day-Exploit besonders interessanten Webserver betreibt, wird man kaum das erste Opfer einer 0-Day-Schwachstelle werden. Und vor bereits bekannten Angriffe kann man sich schützen. Dazu muss man sich regelmäßig über neu gefundene Schwachstellen in der eingesetzten Software informieren. Dazu dienen die bereits in About Security #207 aufgeführten Informationsquellen:

• Mailinglisten wie Bugtraq und Full-Disclosure, wobei die nicht moderierte Liste Full-Disclosure sehr viel Müll enthält. Dort gibt es aber immer mal wieder wichtige Informationen deutliche früher als auf der moderierten Bugtraq-Liste.
• Die Exploit-Archive von milw0rm und packet storm sind ein gutes Indiz für das Gefahrenpotential einer Schwachstelle. Gibt es erst mal die ersten fertigen Exploits, kommen bald auch die Skript-Kiddies.
• Eine aktuelle Übersicht über veröffentlichte Schwachstellen gibt es z.B. im Bereich "Security aktuell" auf entwickler.de oder von SecurityFocus.
• Aktuelle Meldungen über laufende Angriffe gibt es z.B. beim Internet Storm Center, insbesondere im Handler's Diary, und bei der Shadowserver Foundation.

Wird in der selbst eingesetzten Software eine Schwachstelle gemeldet, gilt es, einen Angriff darüber zu verhindern. Wie, ist ein Thema der nächsten Folge, in der auch weitere Angriffe vorgestellt werden.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #206: Schwachstellen-Suche: Webserver identifizieren
• About Security #207: Schwachstellen-Suche: Webserver angreifen
• About Security #208: Schwachstellen-Suche: Webserver schützen