Foto: Lambakoer, Wikimedia Commons

Software enthält Fehler, Security-Experten finden sie und Sicherheitsportale listen die Schwachstellen auf. Da wäre es doch praktisch, wenn ein Werkzeug automatisch prüfen würde, ob die eigenen Rechner betroffen sind. Open VAS verspricht nicht nur Scanner, sondern auch Sicherheitsmanager zu sein .

Um ihre Netze sauber zu halten, lesen viele Systemverantwortliche die “InSecurity News” oder halten sich über Sicherheitsportale auf dem Laufenden. Wer konsequent Paketverwalter wie Debians Apt oder Open Suses Zypper einsetzt, bekommt die Patches ohnehin frei Haus. Leider kommt dieses Szenario oft einem frommen Wunsch gleich: Da gibt es im Netz Legacy-Systeme oder schlicht Anwender, die sich nicht um regelmäßige Aktualisierungen scheren.

Admins gehen daher mit Tools wie dem Portscanner Nmap auf die Suche nach unbekannten Rechnern oder ungewöhnlichen Ports. Der fahndet zwar neuerdings dank NSE-Erweiterung auch nach Diensten und Versionen, aber nicht explizit nach Lecks. Das tat erstmals der Schwachstellenscanner Nessus als Open-Source-Software. Die Ankündigung der Firma Tenable im Oktober 2005, die Software ab Version 3 künftig als Closed Source weiterzuführen [1], hat jedoch für Unmut gesorgt ([2], [3]), die Version 2 blieb konform zur GPL frei.

Dies nutzten Entwickler, um einen Fork unter dem Namen Open VAS zu starten [4]. Er zog mehr Entwickler als das vormals zentral organisierte Nessus an und kam im Juli 2007 mit einer ersten Version 0.9 heraus. Der Zweig 1.x war in vielen Belangen noch kompatibel zu Nessus, ab der Version 2.0 vom Sommer 2009 änderten die Entwickler jedoch Kommunikationsprotokolle und schrieben viele Komponenten von Grund auf neu.

Aufholjagd

Das Projekt wirbt mit über 13000 Checks auf Schwachstellen, die es Network Vulnerability Tests (NVTs) nennt. Das ist knapp die Hälfte der über 30000 Plugins, die Nessus anbietet. Eine Untersuchung des kroatischen Labors für Signale und Systeme der Universität Zagreb kommt jedoch zum Schluss, dass Open VAS gerade bei neueren Schwachstellen gut mithält, was die Erkennungsrate angeht [5].

Experimentell ist zur Zeit noch der Support der Open Vulnerability and Assessment Language (OVAL) des amerikanischen MITRE, das auch die CVE-Identifier herausgibt [6]. Red Hats Sicherheitsteam veröffentlicht beispielsweise Advisories in diesem XML-Format, die Open VAS dadurch automatisch prüfen kann.

Problemfällen auf der Spur

Um Konfigurationsfehler in einem Netz zu finden, fahndet Open VAS zunächst nach offenen Diensten. Es lassen sich sowohl ein eingebauter Portscanner als auch über Wrapper externe Werkzeuge nutzen, darunter Nmap oder spezialisierte Tools wie IKE-Scan, SNMP-Walk oder Port Bunny [7]. Sie füllen über Funktionsaufrufe eine interne Datenbank. Im nächsten Schritt startet Open VAS jeden NVT und berücksichtigt dabei Abhängigkeiten der Plugins untereinander. Ein Plugin sucht sich passende Ports heraus und prüft dort, ob seine spezifische Schwachstelle vorliegt.

Die meisten in der Spezialsprache NASL geschriebenen Tests gehen dabei vorsichtig vor und ziehen ihre Schlüsse aus Antworten des Dienstes. Einige Schwachstellen lassen sich aber nur nachweisen, indem sie eine gewisse Payload an den Dienst senden und dieser fortan nicht mehr reagiert. Solche Plugins markieren die Entwickler als »unsafe«, der Anwender muss sie gesondert aktivieren.

Die Entwickler schreiben ihre NVTs oft auf Grundlage von Advisories und fußen daher auf deren Angaben. Ein weiteres Problem sind Virtual Hosts auf einem Scannerziel: Gegenwärtig arbeiten die Entwickler erst daran, auch Schwachstellen auf virtuellen Domains aufzuspüren. Es ist aber erkennbar, dass das Projekt vornehmlich darauf zielt, wohlbekannte Schwachstellen wie in einer Checkliste abzuhaken statt nach unbekannten oder ungewöhnlichen Konfigurationen zu suchen. Insofern ist Open VAS eher als Werkzeug des Sicherheitsmanagements als ein Scanner per se zu verstehen.

Arbeitsteilung

Von Nessus hat Open VAS die Client-Server-Architektur übernommen. Eine Server-Komponente koordiniert und startet die eigentlichen Scans, während ein grafischer GTK-Client die Analyse vorbereitet, konfiguriert und später die Ergebnisse visualisiert. Beide Teile kommunizieren über das spezielle Protokoll OTP, das SSL absichert, über TCP-Port 9390. Während eines Scans muss der Admin die Verbindung zwischen Client und Server aufrechterhalten, die Entwickler planen aber, das Protokoll künftig auf Rest-ful Webservices umzurüsten.

Versionsbabel bei Paketen

Neben dem Quellcode aus dem SVN-Repository [8], das die Entwicklerbibliotheken »gpgme-devel«, »gcrypt-devel«, »gnutls-devel«, »glib2«, »glib2-devel«, »glib2-data« und GTK+ 2.x für den Client benötigt, gibt es Open VAS für die meisten populären Distributionen. Unter Debian oder Ubuntu installiert der Systemverwalter die Pakete »openvas-client« und »openvas-server«. Admins sollten auf die installierten Versionen aufpassen, weil manche Distribution Clients und Server von verschiedenen Zweigen paketieren, die nicht kompatibel sind. Die Website listet die richtigen Kombinationen auf und bietet auch selbst Pakete an.

Nach der Installtion legt der Admin auf dem Server mit »openvas-useradd Name« die Benutzer für Open VAS an. Sie sind unabhängig vom darunterliegenden Betriebssystem. Leider gibt es noch keine Anbindung an einen Verzeichnisdienst, aber immerhin steht LDAP auf der Roadmap der Entwickler. Der Server fragt anschließend nach Regeln, die angeben, welche Systeme der Benutzer scannen darf. Zwar erlaubt »default accept« jeglichen Zugriff, als guter Stil gilt jedoch, beispielsweise mit

accept 192.168.1.0/24
default deny

genau jenes Netz freizugeben, das vom Programm zu untersuchen ist. Auf diese Weise ist es möglich, innerhalb einer Abteilung die Verantwortlichkeiten zu trennen oder sensible Systeme von Tests auszunehmen. Open VAS speichert diese Einstellungen im Verzeichnis »/var/lib/openvas/users/«, spätere Änderungen macht der Admin mit einem Texteditor.

Geladen und gesichert

Vor dem Start des Servers sollte der Administrator die Datenbank der Plugins mittels »openvas-nvt-sync« laden und aktualisieren. Das Skript ist ärgerlicherweise nicht in jedem Paket enthalten, daher müssen Systemverwalter es im Zweifelsfall aus dem Quellarchiv extrahieren und seine Pfade anpassen. Es lädt per Rsync von einem Server des Projekts die neusten Plugin herunter. Beim ersten Aufruf vergehen einige Minuten, bis die Software alle NVTs heruntergeladen und ihre GPG-Signatur geprüft hat.

Zurzeit kommen fast täglich neue Plugins hinzu, dazu gibt es auch Unternehmen, die auf kommerzieller Basis eigene Feeds anbieten, die gewissen Service Levels unterliegen. Das Skript ruft der Admin regelmäßig auf und startet anschließend den Server neu, da der sonst nichts vom Update mitbekommt.

Zur Absicherung der Kommunikation tunnelt Open VAS alle Daten durch SSL. Die dazu benötigten Zertifikate erzeugt der Aufruf »openvas-mkcert« auf dem Server. Die Option »-q« überspringt den darauf folgenden Wizard, allerdings enthält das daraus resultierende Zertifikat auch nicht die eindeutige Identifikation der Installation, die es andernfalls einfügt. Dieser Schritt ist nur beim Übersetzen der Quellen nötig, denn die meisten Distributionen automatisieren den Schritt. Außerdem liefern sie auch bereits Init-Skripte mit, alternativ startet der Daemon mit »openvasd -D« im Hintergrund.

Wahl der Waffen

Läuft der Server, startet der Admin den grafischen Client. Dort kann er viele Parameter einstellen, die den eigentlichen Scan beeinflussen (siehe Abbildung 1). Die Entwickler geben der Software konservative Voreinstellungen mit, die dafür sorgen, dass der Scanner Leistung und Funktionalität eines Netzes und der darin enthaltenen Rechner nicht beeinträchtigt. Die Einstellung »Concurrent Hosts« legt fest, wie viele Untersuchungsziele der Server auf einmal aufs Korn nimmt. Die Einstellung hat in erster Linie Auswirkungen auf den Server selbst.

Abbildung 1: In der allgemeinen Konfiguration stellt der Sysadmin Parameter wie parallele Hosts und parallele Tests ein. Der Client überträgt sie beim Start des Analyselaufes auf den Server, der den Scan ausführt.

Wer regelmäßig Scans durchführen möchte, sollte dem Server entweder einen eigenen Rechner spendieren oder aber andere Dienste auf eine hohe Load während des Scans vorbereiten, wenn der Admin hier hohe Werte wählt. Auf einem zweimal mit 4 GHz getakteten Intel-Dualcore mit 1,5 GByte RAM erzeugten 20 im Test parallel gescannte Hosts und vier parallele Checks eine Load von 20 für etwa 30 Minuten. Danach hatten 40 Adressen einer typischen Office-Umgebung 12472 Tests durchlaufen.

Die Einstellung »Concurrent Tests« hingegen kann sich durchaus auf die Leistungsfähigkeit des Zielsystems auswirken, ein geeigneter Wert ist die Voreinstellung »4«. Das schont auch den Netzwerkdurchsatz zwischen Server und Untersuchungsziel. Die Option »Safe Checks« weist Open VAS dazu an, sich hauptsächlich auf Banner von Diensten zu verlassen statt möglicherweise invasive Tests durchzuführen, die im schlimmsten Fall einen Dienst zum Absturz bringen oder Ressourcen beanspruchen. So ist von einigen Druckern bekannt, dass sie ohne weitere Prüfung schlicht die Testprobes ausdrucken, sodass ein Scannerlauf unnötig Papier verschwendet, wenn der Admin die Option nicht aktiviert.

An Türen rütteln

Abbildung 2 illustriert die Abwägung zwischen Verlässlichkeit und Risiken für das Untersuchungsziel, da einige Tests Dienste abstürzen lassen. Die Entwickler raten dazu, regelmäßige Durchläufe mit aktiviertem Flag wöchentlich durchzuführen und einmal im Monat die Untersuchung mit allen Tests zu fahren. Dann ist es jedoch wichtig, hinreichend Systemverwalter in Bereitschaft zu halten, die notfalls manuell eingreifen.

Abbildung 2: Systemverwalter müssen die Verlässlichkeit ihrer Analyse und die mögliche Gefahr, hervorgerufen durch »Non-Safe Checks«, gegeneinander abwägen.

Die verschiedenen Portscanner wählt der Anwender über einen eigenen Reiter. Mit der Einstellung »Port Range« konfiguriert er, welche Ports Open VAS tatsächlich überprüft. Die Voreinstellung der Software berücksichtigt nur jene, die die Datei »openvas-services« verzeichnet, das sind ähnlich wie auch bei Nmap die bekanntesten Dienste. Sie lässt aber gerade in den höheren Portregionen aus Geschwindigkeitsgründen bewusst Lücken. Um alle Ports zu testen, gibt der Admin hier »1-65535« ein.

Der Abschnitt »Advanced Plugin Configuration« bestimmt Detailparameter für die einzelnen NVTs (siehe Abbildung 3). Insbesondere der Dialog »Local Access Credentials« ist für eine Spezialität notwendig, die Open VAS von seinem Vorgänger Nessus abhebt. Die Software ist damit in der Lage, auch Schwachstellen aus der Innensicht eines Scanziels zu erkunden. Dazu greift es per SSH oder SMB auf das Zielsystem zu und prüft Anwendungszustände, die von außen nicht erkennbar sind. Dazu zählen etwa der Patchstand von Wireshark oder ob zusätzliche Software auf dem Zielsystem installiert wurde.

Abbildung 3: Open VAS integriert viele spezialisierte Security-Scanner durch Wrapper. Im Reiter »Advanced Plugins Configuration« konfiguriert der Systemverwalter die ausgewählten Werkzeuge, wie hier Nmap.

Von außen und innen

Dazu befragt Open VAS vorrangig lokale Paketmanager. Die dazu notwendigen Einstellungen führt der Systemverwalter unter »Global Settings | Options | Credentials« (siehe Abbildung 4) aus. Ab Version 2.0.2 des Clients kommt der Scanner mit einem praktischen Wizard, der Debian- oder RPM-Pakete anlegt, die in erster Linie einen User und einen zugehörigen SSH-Key schaffen, sodass sich der Open-VAS-Server auf dem Traget-System einloggen darf (siehe Abbildung 6).

Abbildung 4: Wenn sich Open VAS auf einem Zielsystem einloggen darf, prüft es dessen Sicherheit auch von innen. Dazu konfiguriert der Admin Passwörter oder öffentliche Schlüssel für SSH- oder SMB-Zugänge.

Abbildung 6: Aus den Credentials erzeugt der LSC-Wizard ein Installationspaket für die Zielsysteme.

SSH-Schlüssel erzeugt die Anwendung im RSA-PKCS#8-Format, damit auch unterschiedliche SSH-Implementationen sie akzeptieren. Der Wizard erzeugt komplette Deb- oder RPM-Pakete, die sich auf den Zielsystemen installieren lassen. Dort nutzt er dann den Security Local Auditing Daemon (SLAD), um lokal Passwortstärken zu prüfen oder Tools wie Tripwire oder Tiger zu starten [9]. Alternativ lassen sich Windows-Installer erzeugen, die ein Untersuchungsziel darauf vorbereiten, später mit einem lokalen SMB-User Tests durchzuführen.

In den »Advanced Plugin Preferences« kann der Admin vorher grundsätzlich aktivierten Modulen weitere Parameter mitgeben, etwa fragmentierte Pakete oder »NULL«-Scans aktivieren, die Nmap kennt, falls der als Scanner arbeitet. Für diese Funktionen installiert der Admin zusätzlich die Pakete »rpm«, »alien« und »nsis«, da diese leider in der Abhängigkeitsliste einiger Pakete fehlen.

Die Meute losschicken

Nach dem Start des GTK-Clients folgt ein Login beim Server (siehe Abbildung 5). Beim ersten Verbindungsaufbau überprüft der Anwender das Zertifikat des Servers und speichert es für künftige Logins. Der Client holt eine Liste erfügbarer Plugins vom Server ab und löst ihre Abhängigkeiten auf. Während dieser Zeit hängt der Client verwirrenderweise einige lange Sekunden ohne Rückmeldung der Oberfläche.

Abbildung 5: Anwender melden sich vor dem Scan beim Server über eine SSL-Verbindung an.

Nun legt der Anwender so genannte Tasks und Scopes fest. Erstere bilden eine Sammlung von Zielsystemen und können einzelne IP-Adressen oder ganze Netze umfassen. Ein Scope trifft eine Auswahl innerhalb dieser Tasks, etwa alle Geräte eines bestimmten Betriebssystems oder solche, die SSH und E-Mail als Dienste anbieten. Leider muss der Anwender sie für jeden Scan neu anlegen.

Nachdem der Anwender die beschriebenen Parameter wie Scanner, Port-Bereiche oder Login-Credentials festgelegt hat, startet ein Klick auf den mit einer kleinen Rakete versehenen Execute-Button den Analyselauf. Ein Dialog informiert über den Fortschritt des Scans (siehe Abbildung 7). Sobald Open VAS alle Ziele überprüft hat, erzeugt es einen Bericht, den die Software in drei Schweregrade einteilt (siehe Abbildung 8). Ein Klick auf einen Host expandiert die Ansicht und zeigt die Details der gefundenen Schwachstellen (siehe Abbildung 9). Das Programm exportiert den Bericht auch in den Formaten HTML, XML und PDF.

Abbildung 7: Während des Scans zeigt ein Dialog den Fortschritt der jeweiligen Analyseschritte an.

Abbildung 8: Der Scan im Kontext »Test Scans« und im Scope »Internal Testing« ist abgeschlossen. Für den Rechner »sys4« meldet Open VAS zwei Lücken, ebenso viele Warnungen sowie fünf allgemeine Hinweise.

Abbildung 9: Wer den Eintrag eines Untersuchungsergebnisses anklickt, erhält eine detaillierte Beschreibung der Hintergründe, eine Klassifikation, Links und Hinweise, wie das Problem zu beheben ist.

Falscher Alarm

Zwangsläufig meint Open VAS anfangs, Schwachstellen zu erkennen, wo keine sind, so genannte False Positives. Dies passiert insbesondere bei Web-basierten Frontends auf für Webserver unüblichen Ports. Eine weitere Ursache sind zu allgemein oder unpräzise formulierte Advisories. Open VAS kennt keine explizite Methode, um solche Fehlalarme zu vermeiden. Wenn sich der verantwortliche Admin davon überzeugt hat, dass etwa von einem bestimmten Port keine Gefahr für die Systemsicherheit ausgeht, kann er beispielsweise diesen Port vom Scan ausnehmen.

Eigene Plugins schreiben

Eigene Plugins lassen sich mit der Nessus Attack Scriping Language (NASL) schreiben. Listing 1 zeigt ein Beispiel für einen Test auf die Schwachstelle CVE-2009-3023, einen Stack Overflow in Microsofts IIS-FTP-Server. Der »description«-Block enthält beschreibende Metadaten: Die Kategorie setzt der Entwickler mit »script_category()« in Zeile 46 und ermöglicht damit das Filtern bei verschiedenen Scopes. Die Zeilen 51 bis 55 legen Voraussetzungen fest, die der NVT zum Ablauf benötigt. Der Open-VAS-Server sorgt dafür, die Programme in der richtigen Reihenfolge aufzurufen.

01 desc = "MS IIS FTPd NLST stack overflow
02 
03 The Microsoft IIS FTPd service may be
04 vulnerable to a stack overflow via the NLST
05 command. On Microsoft IIS 5.x this
06 vulnerability can be used to gain remote
07 SYSTEM level access, whilst on IIS 6.x it
08 has been reported to result in a denial
09 of service.
10 
11 Whilst it can be triggered by authenticated
12 users with write access to the FTP server,
13 this check determines whether anonymous users 
14 have the write access necessary to trigger it
15 without authentication.
16 
17 We recommend you mitigate in the described
18 manner on the following platforms:
19 
20   - Microsoft IIS 5.x
21   - Microsoft IIS 6.x
22 
23 We recommend you mitigate in the following
24 manner:
25 
26 Filter inbound traffic to 21/tcp to only
27 known management hosts and consider removing
28 directories writable by 'anonymous'.
29 
30 Solution: We are not aware of a vendor
31 approved solution at the current time.
32 
33 See also: http://securityfocus.com/bid/36189
34 
35 Risk factor: High";
36 if (description) {
37     script_id(100952);
38     script_cve_id("CVE-2009-3023");
39     name = "MS IIS FTPd NLST stack overflow";
40     script_name(name);
41     script_description(desc);
42     summary = "Determines whether Microsoft
43  IIS FTPd is accessible and whether anonymous
44  users have write access";
45     script_summary(summary);
46     script_category(ACT_GATHER_INFO);
47     family = "FTP";
48     script_family(family);
49     copyright = "(c) Tim Brown, 2009";
50     script_copyright(copyright);
51     script_dependencie("find_service.nes",
52                "secpod_ftp_anonymous.nasl",
53           "ftp_writeable_directories.nasl");
54     script_require_keys("ftp/writeable_dir");
55     script_require_ports("Services/ftp", 21);
56     exit(0);
57 }
58 
59 include ("ftp_func.inc");
60 
61 port = 21;
62 if (!get_port_state(port)) {
63     exit(0);
64 }
65 
66 if (!get_kb_item("ftp/writeable_dir")) {
67     exit(0);
68 }
69 
70 banner = get_ftp_banner(port);
71 if (!banner) {
72     exit(0);
73 }
74 if ("Microsoft FTP Service (Version 5.0)"
75     >< banner) {
76     security_hole(port);
77 } else {
78     if ("Microsoft FTP Service" >< banner) {
79         security_warning(port);
80     }
81 }

Der darauf folgende Block definiert den eigentlichen Check. Er testet, ob der FTP-Port offen ist (Zeile 62) und ob das abhängige Plugin »ftp_writeable_directories.nasl« ein schreibbares Verzeichnis entdeckt hat. Dann enthält die Wissensdatenbank den Schlüssel »ftp/writeable_dir« und der NVT holt das Banner vom Dienst. Enthält dies den Substring mit der verwundbaren Version, markiert Open VAS das Scanziel als verwundbar (Zeilen 74 bis 81) ansonsten mit einer Warnung. Andere Funktionen bauen Pakete zusammen oder extrahieren Daten aus empfangenen Datenblöcken.

Auf dem Weg zu einem nützlichen Werkzeug

Das unter der GPL entwickelte Open VAS nimmt sowohl Netzwerk- als auch Systemadministratoren viel Arbeit ab, um den Überblick ihrer Systeme aus Sicherheitssicht zu behalten. Wer jedoch glaubt, mit der Software ein Tool gefunden zu haben, das ohne weiteres Zutun alle Schwachstellen findet, wird enttäuscht. Um Open VAS nutzbringend einzusetzen, ist viel Vorbereitung und Feinabstimmung notwendig.

Das sich entwickelnde Projekt wirkt lebhafter als sein eher zentral geführter Vorgänger Nessus, kann aber noch nicht an dessen Vielfalt an Plugins heranreichen. Obwohl einsetzbar, muss der Anwender über die eine oder andere Holperigkeit, etwa fehlende Skripte in für Distributionen zusammengestellten Paketen oder manchmal merkwürdig skalierende GUI-Widgets, hinwegsehen. Setzt es ein Systemverantwortlicher regelmäßig ein und studiert die erzeugten Berichte, profitiert das Netz ohne Zweifel davon.