© norebbo, 123RF.com

Der Schwachstellen-Scanner Open VAS ist gerade in Version 4 erschienen – Grund genug, nicht nur den Neuerungen nachzugehen, sondern auch das Programmieren eigener Plugins praktisch auszuprobieren.

Der Vulnerability-Scanner Open VAS war bereits in früheren Linux-Magazinen Gegenstand zweier Artikel ([1], [2]). Die freie Software vollzieht eine rasante Entwicklung und kommt gerade bei Version 4 an. Dieser Artikel stellt sie vor, geht auf verfügbare Clients und deren Stärken und Schwächen ein. Auch gibt er Hinweise für den praktischen Einsatz der Software und beschreibt, wie der Anwender eigene Plugins programmiert.

Die Bezeichnungen der einzelnen Open-VAS-4-Komponenten verwirren etwas. So bezieht sich die Versionsnummer nur auf die Bibliotheken (derzeit 4.0.5). Die Komponenten Scanner (3.2.4) oder Manager (2.0.4) nummerieren anders (Details siehe [3]). Leider führen die Repositories der aktuellen Linux-Distributionen zumeist nur alte Binaries, Ubuntu 11.04 beispielsweise Open VAS 2. Die Community stellt jedoch neuere Pakete ins Netz, für Debian und Ubuntu zum Beispiel per Open Suse Build Service [4].

Die Open-VAS-4-Pakete enthalten allerdings den von vielen Anwendern wegen seiner einfachen Bedienung und der lokal gehaltenen Konfigurationsdaten geschätzten nativen Open-VAS-Client nicht mehr. Wer ihn per Paketmanager versucht nachzuinstallieren, zieht sich eine veraltete Version ins System. Der aktuelle Client [2] ist Teil einer vollständig supporteten Scan-Appliance der Firma Greenbone [5] und dort zu erhalten. Interessenten können die neuesten Quellen auch aus dem Subversion-Repository des Projekts [6] holen und übersetzen.

Die Aktivität der Community, insbesondere die der Greenbone-Entwickler, ist sehr gut an der Versionshistorie im Repository zu sehen: An vielen Tagen führen die Entwickler mehrere Check-ins durch, festgestellte Bugs beheben sie oft in wenigen Stunden.

Wer gern mit frischen Versionen arbeitet, sollte den Sourcecode über Subversion beziehen. Das Paket zu schnüren ist recht einfach. Der Autor stellt dazu ein unter Ubuntu getestetes Makefile bereit [7], das die Schritte Download oder Update der Quellen, Installieren der erforderlichen Pakete sowie Erzeugung und Installation der aktuellen Version inklusive der Versionsupdates übernimmt (Listing 1). Später aktualisiert jederzeit ein »make up« die Software als Ganze.

01 # installiert erforderliche Pakete
02 make depend
03 # erzeugt und installiert Open VAS
04 make
05 # erstellt benötigte Zertifikate, Datenbank, etc.
06 make initial
07 # startet die erforderlichen Hintergrundprozesse
08 make start

Neue Protokolle

Open VAS hat beginnend mit Version 3 das Framework kräftig verändert (Abbildung 1), bleibt jedoch zu den aus Version 2 bekannten Tools und Protokollen kompatibel. Neben dem neuen Open VAS Management Protocol (OMP), das Scanprozesse zu managen hilft, und dem Open VAS Administration Protocol (OAP) zum Administrieren sind vor allem Clients und neue Dienste hinzugekommen.

So steuert der Open VAS Manager die gesamte Kommunikation innerhalb des Framework und legt alle Scan-relevanten Informationen in seiner internen SQLite-Datenbank ab. Er entlastet so die neuen, auf OMP fußenden Clients und organisiert den wechselseitigen Zugriff auf die hinterlegten Scandaten. Die Kommunikation mit dem eigentlichen Scanner, »openvassd« , erfolgt nach wie vor per Open VAS Transfer Protocol (OTP). Der Dienst Open VAS Administrator hilft dem Admin die vorgesehenen Nutzer und Zertifikate komfortabel zu verwalten.

[8])” width=”300″ height=”184″ /> Abbildung 1: Clients, Dienste und verwendete Kommunikationsprotokolle von Open VAS in Version 4. (Quelle: [8])

Client-Vielfalt

Zu dem bisherigen GTK-Programm Open-VAS-Client gesellen sich nun weitere Scan-Clients. Mit der Serveranwendung Greenbone Security Assistant (GSA, [2]) tragen die Entwickler dem Trend zu Webanwendungen Rechnung (Abbildung 2). Der dank Qt auch unter Windows lauffähige Greenbone Security Desktop (GSD, Abbildung 3, [9]) oder das einfache Kommandozeilentool »omp« runden das kostenfreie Angebot ab.

In Version 3 noch lückenhaft, spiegeln die Desktop-Clients in Version 4 den vollem Umfang von Open VAS wider. In der praktischen Anwendung allerdings zeigt sich der klassische Open-VAS-Client deutlich einfacher anwendbar und vor allem schneller bedienbar. Große Vorteile zieht er aus seiner hierarchischen Gliederung der Scanziele in »Targets« und »Scopes« . Die einmal definierten Standardeigenschaften für den Scan reicht das System zunächst vom Target zum Scope weiter, der Administrator darf sie danach beliebig anpassen.

Dadurch kann er neue Scans sehr schnell definieren und absolvieren. Auch der Wechsel zwischen den Scanzielen und deren Ergebnissen gelingt auf Anhieb. Im Vergleich dazu gestaltet sich das Definieren der Scans beim Webclient und den Desktop-Clients umständlich. Der Bediener legt zunächst »Scan-Configs« , »Credentials« , »Scan-Targets« und »Tasks« getrennt voneinander fest. Was zunächst wie stets wiederverwendbare Bausteine aussieht, entpuppt sich beim späteren Bearbeiten der Konfiguration als Hindernis. So lassen sich beispielsweise Scan-Targets nachträglich nicht ändern und in den Scan-Tasks die Scan-Targets nicht nachträglich austauschen.

Der Bediener muss die Einträge deswegen neu definieren, was auf Dauer lästig ist. Auch das Definieren von Scanzielen über eine Datei-basierte Liste gelingt derzeit mit den neuen Clients nicht. Wer also Hunderte virtueller Hosts eines Webservers auf Schwachstellen scannen will, lernt die Vorzüge des klassischen Clients zu schätzen, der die Liste der Hosts als Textdatei akzeptiert.

Abbildung 2: Der neue Greenbone Security Assistant braucht nur einen Browser.

Abbildung 3: Der Desktop-Client Greenbone Security Desktop fußt auf Qt.

Erste Schritte

Vor dem ersten Einsatz erscheint es sinnvoll, die Datenformate von Open VAS und deren Ablageorte zu kennen. So lassen sich bereits zu Beginn die wichtigen Einstellungen für den Scanner korrekt treffen und Fehler beim Speichern sensibler Informationen vermeiden. Im klassischen Open-VAS-Client – dieser ist Gegenstand der weiteren Betrachtungen – hilft die hierarchische Struktur der Scanziele, da sie einige Voreinstellungen für weitere Scanziele direkt übernimmt.

Dieses Wissen kann der Bediener auch nutzen, um nachträglich die Hierarchie der Scanziele zu verändern – es reicht, die Ordner im Dateisystem zu verschieben. Besondere Beachtung verdient die Datei ».openvasrc« beim jeweiligen Scanziel. Hier liegen alle für diesen Scan nötigen Konfigurationen, darunter Optionen, die über die Clients nicht setzbar sind. So schaltet »log_whole_attack = no« das komplette Scan-Logging auf dem zentralen Scanserver aus.

Die Abbildungen 4 und 5 zeigen globalen Einstellungen, die der Admin vor dem Scan prüfen sollte. So sollte er beim Testen virtueller Webserver »reverse lookup« einstellen, um nicht alle Ergebnisse unter einer gemeinsamen IP zusammengefasst zu erhalten. Die Option »Safe checks« ist zunächst ein Muss – per Default ist sie leider deaktiviert –, da DoS-Scans besser nicht den Auftakt bilden. Die Anzahl parallel zu scannender Hosts sowie der zu absolvierenden Tests sollte der Admin reduzieren, um unnötige Lasten von Netz und Zielhosts fernzuhalten.

Es ist klar, dass Scans nur nach Rücksprache mit dem zuständigen Netzadministrator stattfinden und Firewalls oder IDP-Systeme möglichst aus dem Spiel bleiben, weil diese die Ergebnisse verfälschen. Mindestens anfangs ist der »OpenVAS-Scanner« als initiierender Portscanner eine gute Wahl, bei Nmap als Portscanner sollte der Admin die erforderlichen Einstellungen vorher separat mit Nmap testen und dann übernehmen.

Die Eigenschaften der Plugins bestimmen die Oberfläche des Open-VAS-Clients, definiert über die »Prefs« -Optionen. Der Admin sollte sie nach dem Laden oder Aktualisieren der Plugins überprüfen. Er kann beispielsweise die sehr aufschlussreichen Prüfungen nach IT-Grundschutz [10] über die »Compliance Tests« aktivieren (Abbildung 4). Diese sehr komfortable Eigenschaft der Plugin-Konfiguration bietet sich natürlich auch für die eigene Plugin-Entwicklung an.

Abbildung 4: Sorgfalt bedarf es bei globalen Einstellungen im Open-VAS-Client.

Abbildung 5: Voreinstellungen für einzelne Plugins.

Ein geeignetes erstes Ziel

Als erstes Ziel (»Target selection« ) empfiehlt sich stets »localhost« auf demselben Host, wenn dort Client und Server installiert sind. Die Konfiguration der Maschine ist bekannt, mögliche Schwachstellen lassen sich leicht verifizieren und wiederholt testen. Sofern Client und Server auf verschiedenen Systemen laufen, kann natürlich auch das eigene Clientsystem als Ziel herhalten. Dabei ist aber bereits das dazwischenliegende Netzwerk mit zu berücksichtigen.

Auch die Platzierung einer eigenen virtuellen Maschine zum Testen ist empfehlenswert, weil der Admin diese unter eigener Kontrolle (etwa über Virtualbox [11]) einfach modifizieren und verschiedene Zustände über Snapshots aufbewahren kann.

Nach Auswahl der Plugins, aktuell gibt es über 21000, lässt sich der erste Scan starten. Zunächst wählt man eine ausschließlich externe Sichtweise auf das Scanziel, also noch ohne Angabe von Login-Daten des Zielsystems. Diese Sicht entspricht auch der Ausgangssituation realer Angreifer. Der Scan dauert je nach offenen Ports und aktiven Diensten von wenigen Minuten bis zu mehreren Stunden und lässt sich jederzeit abbrechen.

Nach Abschluss oder Abbruch des Scans steht der Bericht bereit, der Port- beziehungsweise Service-basiert detaillierte Informationen zum Ziel liefert. Es entstehen stets drei Typen von Informationen: »Security hole« zeigt die entdeckten potenziellen Schwachstellen, »Security note« liefert zum Beurteilen des Systems nutzbare Informationen zum Port, und unter »Log message« sind die mitunter sehr wertvollen internen Informationen der eingesetzten Plugins zu finden.

Der erste Blick richtet sich auf die allgemeinen Informationen unter »general/tcp« , insbesondere auf die zusammengefassten Parameter zum Scan wie Konfiguration, Zeitdauer et cetera.

Lücke an Lücke?

Trotz eines vermeintlich aktuell gepatchten Systems bringt der erste Scan meist einige Dutzend schwerwiegende Sicherheitslücken ans Tageslicht. Die Hauptursachen sind im unsachgemäßen Anwenden oder in der nicht immer fehlertoleranten Programmierung der verwendeten Scan-Plugins zu suchen. So liefern die Plugins zum IT-Grundschutz [10] nur dann sinnvolle Ergebnisse, wenn der Scan das Zielsystem auch intern analysiert hat, was einen erfolgreichen Login erfordert. Ohne ihn scheitern die Tests unglücklicherweise mit einem Fehlerstatus, der den Zähler für gewichtige Sicherheitslücken inkrementiert.

Daher muss der Bediener vor dem nächsten Test diese Plugins deaktivieren oder zusätzliche Angaben wie die Login-Daten machen. Ein schneller Blick auf die Statistik führt also in die Irre. Ergo: Open VAS eignet sich (noch) nicht fürs vollautomatisierte Testen und Auswerten.

False Positives

Ein sehr häufig anzutreffendes Problem besteht darin, dass Plugins vermeintlich veraltete Versionsnummern von auf dem Zielsystem installierter Software erkennen – typisch bei Systemen mit Backports [12]. Ältere, aber noch offiziell supportete Versionen kommen nämlich häufig in den Genuss von Fixes für Sicherheitslücken, die in neueren Versionen erstmals aufgefallen sind. Nicht selten erhält der nun wieder sichere Backport aber keine neue Versionsnummer, was Open VAS verwirrt. Ein Securityscanner versucht nämlich nicht die Lücken auszunutzen, sondern sucht nur nach Versionen mit bekannten Schwachstellen.

Beispiel Ubuntu 8.04 LTS Server: Open VAS beurteilt das dort verwendete Open SSH kritisch (siehe Listing 2). Wer der Version und den Patchständen aber genau hinterherrecherchiert, stellt fest, dass »ssh-2.0-openssh_4.7p1 debian-8ubuntu1.2« aktuell ist und alle Securitypatches berücksichtigt sind [13]. Solche Feinheiten überfordern die Plugins und machen es nötig, Meldungen manuell nachzuarbeiten.

01 Reported by NVT "IT-Grundschutz M5.064: Secure Shell" (1.3.6.1.4.1.25623.1.0.895064):
02
03 Ergebnisse zum IT-Grundschutz, 11. Ergänzungslieferung:
04
05 IT-Grundschutz M5.064: Secure Shell
06 Ergebnis:       nicht erfüllt
07 Details:        Es wurde auf Port 22, folgender SSH-Server gefunden: ssh-2.0-openssh_4.7p1 debian-8ubuntu1.2
08 Versionen vor OpenSSH 5.2 sind verwundbar.

Um False Positives generell zu reduzieren, kann der Admin in den »Global variable settings« unter »Report paranoia« die Option »Avoid false alarms« statt »Normal« setzen. Das hilft freilich nur, sofern die Plugins die Option auch auswerten, was derzeit leider nur rund 130 der mehr als 21000 Plugins tun. Allerdings wohnt diesem Vorgehen das Risiko inne, gelegentlich eine echte Schwachstelle zu übergehen.

Open VAS stellt zur Korrektur aller erkannten Schwachstellen einen Mechanismus in Form von Severity Overrides bereit. Damit lässt sich jede durch den Scanner generierte Meldung in der Bedeutung zwischen »Security hole« und »False positive« neu einstufen. Abbildung 6 zeigt dies am Beispiel der fehlerhaften Open-SSH-Meldung. Der Admin legt diese Overrides in der Datei »severity_overrides.xml« global ab (siehe Tabelle 1), kann sie nachträglich dort auch editieren (Listing 3) und jederzeit auf die Ergebnisse eines Berichts anwenden, da sie entsprechend ausgezeichnet sind (Abbildung 7).

Overrides beziehen sich zunächst ausschließlich auf den diesem Bericht zugrunde liegenden Host – im Beispiel 192.168.178.46. Wer dies auf eine Gruppe oder alle Hosts ausweiten will, ändert den Eintrag »host=« in der Form »192.168.178.*« . Doch Vorsicht: Dies beeinflusst stets die gesamte Regel mit der Folge, dass auch beim Vorliegen einer echten Schwachstelle Open VAS ein False Positive anzeigt. Daher sollte man alle Override-Regeln in regelmäßigen Abständen überprüfen.

01 <severity_override name="IT-Grundschutz M5.064: Secure Shell"
02        host="192.168.178.46"
03        port="general/IT-Grundschutz"
04        OID="1.3.6.1.4.1.25623.1.0.895064"
05        severity_from="Security Hole"
06        severity_to="False Positive"
07        active="true">
08        <reason>
09        Backport
10        </reason>
11 </severity_override>

Abbildung 7: Auswirkungen von Severity Override auf einen Bericht.

Abbildung 6: Mit Severity Override lässt sich jede vom Scanner generierte Meldung in der Bedeutung zwischen »Security hole« und »False positive« neu einstufen.

Externe und interne Sichten

Mit Open VAS lässt sich ein zu scannendes Zielobjekt unter verschiedenen Sichten betrachten:

• Aus dem öffentlichen Internet
• Aus dem internen Firmennetz, möglicherweise aus unterschiedlichen Sicherheitszonen
• Aus dem Inneren des Zielobjekts selbst nach erfolgreichem Login

Die beiden ersten Sichten unterscheiden sich lediglich in der Position des Open-VAS-Scanners und ergeben für den Scanclient zunächst keinen Unterschied. Der Open-VAS-Client kann zu beliebig vielen Scannern eine Verbindung aufbauen und sie parallel nutzen. Zu beachten sind aber die Sicherheitsrichtlinien der gegebenen Netzinfrastruktur. Selbst den eigenen Server im öffentlichen Bereich des Firmennetzes über das Internet zu scannen, kann eine Herausforderung werden.

Aus dem Innern des Zielobjekts

Sehr viel bessere Ergebnisse liefern Open-VAS-Scans, die die Möglichkeit zum Login auf dem Zielhost haben und diesen aus dem Innern heraus analysieren. Der Login sollte nicht über einen Root-Account laufen, bereits ein normaler Account liefert genug Informationen zum System und dessen Schwachstellen.

Auch die User-Passwort-Paare der Zielsysteme sind ein schützenswertes Gut. Leider gehen der Open-VAS-Manager und damit die neuen, über OMP arbeitenden Open-VAS-Clients damit nicht sonderlich pfleglich um, da sie die Paare einfach im Klartext in der SQLite-Datenbank speichern und so zumindest für den Administrator des Scanservers zugänglich machen, der ja nicht zwingend zugleich der Admin aller Zielsysteme ist. Eine einfache SQL-Anweisung in der Form

sqlite3 tasks.db 'select * fromlsc_credentials;'

gibt Personen mit Zugang zur Datenbank alle vertraulichen Informationen preis. Die Zugangsdaten verschlüsselt abzulegen löst das Problem auch nicht, da während des Scans die Daten entschlüsselt werden und der Schlüssel innerhalb der Anwendung hinterlegt wäre.

Auch der klassische Open-VAS-Client zeigt hier Schwächen, er legt die Zugangsdaten im Klartext in den lokalen Konfigurationsdateien ».openvasrc« (Tabelle 1) ab. Davor wird zwar gewarnt, aber die Klartextablage der Passphrase zum privaten Schlüssel ist keine gute Alternative. Optimal wäre, die Daten verschlüsselt zu speichern in Verbindung mit einem nicht hinterlegten Masterpasswort oder gar mit Unterstützung einer Smartcard – reichlich Entwicklungsbedarf für spätere Open-VAS-Versionen.

Wichtig ist dabei, dass der Open-VAS-Client eine geänderte Konfiguration in den Zugangsdaten immer nur beim Scan des Zielobjekts in der Datei aktualisiert. Denn selbst wenn der Admin vor dem Schließen des Programms die Zugangsdaten löscht, verbleiben diese in der Konfigurationsdatei.

Sicherheit durch Schlüssel

Um Zugangsdaten möglichst einfach auf mehrere Systeme zu verteilen und die Problematik der zentralen Zugangsdaten zu entschärfen, bieten sich asymmetrische Schlüssel an. Der öffentliche Schlüssel kommt auf die Zielsysteme. Der zugrunde liegende Account sollte ein deaktiviertes Passwort haben, sodass allein der auf dem Client verbleibende private Schlüssel den Zugang ermöglicht. Da die Passphrase sich nur im Klartext hinterlegen lässt, verzichtet man gleich darauf. Zum Schutz des privaten Schlüssels bietet sich derzeit an, ihn gesichert aufzubewahren, etwa auf USB-Stick, oder ihn nochmals mit Truecrypt, PGP oder Encryptfs zu verschlüsseln.

Da der passende öffentliche Schlüssel auch auf dem Zielsystem (in »~./.ssh/authorized_keys2« ) hinterlegt sein muss, kann der Admin des Zielsystems den Zugriff durch Hinzufügen oder Entfernen des öffentlichen Schlüssels steuern. Er könnte sogar durch ein spezielles Open-VAS-Plugin den Zugang auf einen einmaligen Scan beschränken, indem es nach dem Scan die Schlüsseldatei selbst mit

pread(cmd: "/bin/mv", argv: make_list("mv","~/.ssh/authorized_keys2","~/.ssh/authorized_keys2.bak"));

verschiebt, was einem Quasi-Einmalzugang für diesen Scan entspricht.

Das Erzeugen der Schlüsselpaare erfolgt ähnlich wie bei Open SSH und ist detailliert unter [15] beschrieben. Doch funktionieren entgegen der Open-VAS-Dokumentation derzeit nur DSA- und keine RSA-Schlüssel [16]. Das macht den Einsatz des eingebauten Tools zur Paketerzeugung (unter »Extras | LSC Credentials Manager« ) wenig empfehlenswert.

Nachdem das Schlüsselpaar (hier für den Nutzer »sshovas« ) erzeugt ist, sollten alle intern zu scannenden Systeme über »ssh -i Key-Verzeichnis/sshovas_dsa.p8 sshovas@Ziel« erreichbar sein. Zum Testen dieser Funktion genügt es, das SSH-Authorization-Plugin zu aktivieren. Nach dem Scan sollte im Bericht unter »SSH | Security Note« der Inhalt wie in Listing 4 erscheinen.

Da einige Plugins leider sprachabhängig (auf Englisch) programmiert sind – so erkennt das Plugin zum Scannen von VMware nur den Rückgabe-String »command not found« –, ist es ratsam, solche Logins mit einer englischsprachigen Umgebung auszustatten, zum Beispiel mit »LANG=us« in »~/.profile« .

01 Reported by NVT "SSH Authorization" (1.3.6.1.4.1.25623.1.0.90022):
02
03 It was possible to login using the SSH credentials supplied.
04 Hence local security check are enabled.

Eigene Sicherheitsscans programmieren

Obwohl Open VAS derzeit rund 21000 Plugins im Gepäck führt, kann es etwa zur Umsetzung firmeninterner Richtlinien nötig werden, eigene Plugins zu entwickeln. Das hat in der Skriptsprache NASL (Nessus Attack Scripting Language) zu erfolgen, zum Lernen stehen umfangreiche Literatur ([17], [18]) und die vorhandenen Plugins zur Verfügung. Den Aufbau von NASL-Plugins hat ein Linux-Magazin-Artikel [1] bereits geschildert, hier folgt nun ein konkretes Programmierbeispiel, dessen Quellcode unter [7] zum Download steht.

Das Beispiel realisiert die Umsetzung einer Sicherheitsanforderung, die das Ablegen von Klartextpasswörtern auf Subversion-Servern [19] verbietet. Das Skript soll nach Client-Konfigurationen fahnden, die es nicht explizit unterbinden, Passwörter im Klartext zu speichern. Dazu prüft es die globalen Subversion-Konfigurationsdateien in »/etc/subversion« auf das Vorhandensein der Direktiven »store-passwords = no« beziehungsweise »store-plaintext-passwords = no« . Diese Direktiven sollten nicht, wie leider bei der Standardinstallation, auskommentiert sein.

Die Angaben im Header (Description) sind für jedes Plugin verpflichtend und ermöglichen es den Clients, nach diesen Informationen zu suchen (Listing 5a). Damit wählen sie die relevanten Plugins für einen Scan aus und treffen entsprechende Voreinstellungen. Die »script_dependencies« -Angaben stellen sicher, dass Open VAS die benötigten Plugins ausführt und auf deren Ergebnisse und Vorarbeiten (in diesem Fall ein SSH-Login sowie die Liste der installierten Pakete) zurückgreifen kann.

Die Angabe einer »script_id« führt zunächst zu Problemen, da Open VAS bislang kein eindeutiges Nummernschema besitzt. Denn bislang nutzt kein Plugin die mit Version 1.0.3 eingeführten Open-VAS-IDs (OID) mit »script_oid« , sondern die einfache Nummerierung mit »script_id« . Allerdings setzt Open VAS intern das alte auf das neue Schema um (siehe Abbildung 8).

Um einen geeigneten Nummernbereich für die eigenen Plugins zu finden, schaut der Entwickler im Plugin-Verzeichnis zunächst nach bereits vergebenen Nummern:

find . -type f -print | xargs fgrepscript_id | awk -F '[()]' '{print $2}' |sort -n[...]
2000201
9000001
9999991
9999992

Auf diese Weise erhielt das Beispiel die Nummer 9999001. Die Angabe von »script_add_preference« führt dazu, dass im Open-VAS-Client unter den »Prefs« -Optionen eine eigene Checkbox zum Aktivieren des neuen Plugins auftaucht (analog zu Abbildung 5).

01 if(description)
02 {
03   script_id(9999001);
04   script_version("$Revision: 289 $");
05   script_tag(name:"risk_factor", value:"None");
06   script_name("UniBwM 1: Plaintext passwords");
07   desc ="
08   Overview : This script tests against plaintext passwords for subversion.
09   Risk factor : None";
10
11   script_description(desc);
12   script_summary("Plaintext passwords");
13   script_category(ACT_GATHER_INFO);
14   script_copyright("Copyright (C) 2010 Stefan Schwarz");
15   script_family("General");
16   script_dependencies("ssh_authorization.nasl","gather-package-list.nasl");
17   script_add_preference(name:"Launch this script", type:"checkbox", value:"yes");
18   exit(0);
19 }

Abbildung 8: Die Eigenschaften des Plugins im Open-VAS-Client.

Zum Zielsystem verbinden

In nächsten Abschnitt (Listing 5b) verbindet sich das Plugin SSH-geschützt zum Zielsystem. Leider funktioniert der Austausch übergreifender Informationen beim lokalen Testen des Plugins außerhalb des Open-VAS-Scanners nicht, da die Kommunikation der Plugins über die interne Knowledge-Base (KB) misslingt.

Also muss man für lokale Tests die SSH-Verbindung explizit aufbauen, denn die bereits bestehende über »ssh-authorization.nasl« zu nutzen ist nicht möglich, weil »ssh_login_or_reuse_connection« keinen gültigen Socket zurückliefern würde. Leider sind für den Aufbau die Verbindungsdaten im Klartext zu hinterlegen – und nach Fertigstellen des Plugins wieder zu entfernen. Hier lässt sich auch die zuvor definierte Plugin-Option »Launch this script« auswerten.

Zur Untersuchung des Zielsystems (Listing 5c) darf das Plugin beliebige Shellkommandos über »ssh_cmd« absetzen und deren Ausgaben untersuchen. Dazu stehen aber auch interne Funktionen wie »egrep« zur Verfügung [17]. Die Ausgaben des Plugins, soll heißen die Einstufung der gefundenen Sicherheitslücken, erfolgen durch »security_note« , »security_warning« oder »security_hole« .

NASL-Plugins liegen entweder in »Install-Directory/lib/openvas/plugins« oder in beliebigen Unterverzeichnissen. Das syntaktische und logische Testen des eigenen Plugins sollte außerhalb der Open-VAS-Umgebung stattfinden. Dies erledigt das Programm »openvas-nasl« (Listing 6). Dabei ist die Option »-X« erforderlich, da das Plugin nicht signiert ist. Mit »-i« findet das Skript die abhängigen Skripte im übergeordneten Verzeichnis.

Nach erfolgreichem Testlauf stellt der Entwickler das Plugin für die Clients bereit. Dazu muss er den Scan-Daemon »openvassd« mit »kill -HUP« aktualisieren. Ab jetzt erhalten alle Clients bei einem erneuten Verbindungsaufbau zum Scanner das aktualisierte Plugin. Nach Auswahl des Plugins und dem Scan des Zielsystems erscheinen die Ergebnisse im entsprechenden Report (Abbildung 9).

01 launch = script_get_preference("Launch this script");
02 if(launch == "no")
03   exit(0);
04
05 include("ssh_func.inc");
06
07 # Verbindung über ssh
08 sock = ssh_login_or_reuse_connection();
09
10 if(!sock)
11 {
12   security_note(data:"Keine SSH-Verbindung verfuegbar -> Versuche lokale Verbindung");
13   # Für lokale Tests müssen die Accountdaten im Quellcode vorhanden sein!
14   account = "myaccount";
15   password = "mypassword";
16
17   sock = open_sock_tcp(22);
18   if(!sock)
19   {
20     log_message(data:"Keine lokale Verbindung moeglich: Abbruch!");
21     exit(0);
22   }
23   ssh_login(socket:sock, login:account, password:password);
24   log_message(data:"Lokale ssh-Verbindung erfolgreich");
25 }

01 # Test, ob subversion überhaupt installiert ist
02 svn_version = ssh_cmd(socket:sock, cmd:"svn --version", timeout:120);
03 if(egrep(pattern:"Version", string:svn_version))
04 {
05   # Subversion ist installiert
06   # Information als Security-Note ausgeben
07   security_note(data:"Subversion ist installiert: " + svn_version);
08
09   # Auswertung der Konfigurationsfiles
10   svn_config1 = ssh_cmd(socket:sock, cmd:"fgrep 'store-passwords = no' /etc/subversion/config", timeout:120);
11   svn_config2 = ssh_cmd(socket:sock, cmd:"fgrep 'store-plaintext-passwords = no' /etc/subversion/servers", timeout:120);
12
13   if(egrep(pattern:"# ", string:svn_config1))
14   {
15     # Wert ist auskommentiert, Security-Warung ausgeben
16     security_warning(data:"store-passwords = no sollte in /etc/subversion/config auskommentiert sein!");
17   }
18   if(egrep(pattern:"# ", string:svn_config2))
19   {
20     # Wert ist auskommentiert, Security-Hole ausgeben
21     security_hole(data:"store-plaintext-passwords = no sollte in /etc/subversion/servers auskommentiert sein!");
22   }
23 }
24 ssh_close_connection();
25 exit(0);

01 [...]
02 Keine SSH-Verbindung verfuegbar -> Versuche lokale Verbindung
03 [5231] plug_set_key:internal_send(0)['1 SentData/(null)/NOTE=Keine SSH-Verbindung verfuegbar -> Versuche lokale Verbindung;
04 ']: Socket operation on non-socket
05 [5231] plug_set_key:internal_send(0)['3 Success/(null)=1;
06 ']: Socket operation on non-socket
07 Lokale ssh-Verbindung erfolgreich
08 [5231] plug_set_key:internal_send(0)['1 SentData/(null)/LOG=Lokale ssh-Verbindung erfolgreich;
09 ']: Socket operation on non-socket
10 [5231] plug_set_key:internal_send(0)['3 Success/(null)=1;
11 ']: Socket operation on non-socket
12 Subversion ist installiert: svn, Version 1.6.6 (r40053)
13 übersetzt Dec 12 2009, 05:04:54
14 [...]
15 store-passwords = no sollte in /etc/subversion/config auskommentiert sein!
16 [5231] plug_set_key:internal_send(0)['1 SentData/(null)/INFO=store-passwords = no sollte in /etc/subversion/config auskommentiert sein!;

Abbildung 9: Der Open-VAS-Client zeigt die Scanresultate, die das eigene Plugin zusammengetragen hat.

Fazit

Open VAS 4 erweist sich als sehr leistungsfähiges Werkzeug zur Schwachstellenanalyse. Insbesondere die sehr große und ständig wachsenden Anzahl von Plugins verbunden mit der Möglichkeit, selbst welche zu entwickeln, machen Open VAS zu einem Programm, das für die Sicherheit vieler Serverumgebungen von großem Nutzen sein kann.

Wie bei jedem leistungsfähigen Tool erfordert die Handhabung eine gewisse Erfahrung, besonders wegen der sehr zahlreichen False Positives beim Scan. Die neuen Clients der Version 4 tragen dem Trend zu Webanwendungen und zu grafischen Übersichten über Dashboards Rechnung. Durch ein zentrales Management sind diese in der Lage, zeitgesteuerte Scans nach einem Master-Slave-Konzept durchzuführen, die Nutzer über ein zentrales LDAP zu authentifizieren und zu autorisieren und eignen sich damit für große und administrativ verteilte Netze. Nur das zentrale, unverschlüsselte Speichern der Zugangsdaten der zu scannenden Systeme bildet eine Schwachstelle.