Kritik an Nessus Attack Scripting Language

Kritik an Nessus Attack Scripting Language

Marc Ruef
von Marc Ruef
Lesezeit: 10 Minuten

Der ehemals quelloffene Vulnerability Scanner Nessus galt jahrelang als treibende Kraft für automatisierte Sicherheitsüberprüfungen. Ihm liegt die Nessus Attack Scripting Language (NASL) zu Grunde, welche für das Umsetzen der Plugins verwendet wird. Diese werden eingesetzt, um (1) Daten eines Zielsystems zu sammeln und (2) anhand dieser entsprechende Schwachstellen zu identifizieren. Dieser Beitrag will explizite Kritik an den jeweiligen Schwächen der für die Plugins genutzten Skriptsprache vortragen.

Syntax

NASL benutzt einen Syntax, der sehr stark demjenigen von C ähnelt (siehe das untenstehende Beispiel). Dies bedeutet, dass zur Entwicklung oder Anpassung eines Plugins grundlegendes Programmierwissen vorhanden sein muss. Für Einsteiger, die keine Ahnung von Programmierung haben, gestalten sich erste Gehversuche deshalb nicht sonderlich einfach.

# This is an example NASL script

if(description) { script_version (“1.2”); name[“english”] = “Foo 3.1 Cross Site Scripting”; script_name(english:name[“english”]);

desc[“english”] = “ This plugin checks for the vulnerability in the Foo 3.1 server as described in CVE 200×-4321. Risk factor : High”; script_description(english:desc[“english”]); summary[“english”] = “Check for Cross Site Scripting in Bar 3.1”; script_summary(english:summary[“english”]); script_copyright(english:“This script is under GPLv3”); … exit(0); }

In Bezug auf die Definition der Sprache besteht das Problem, dass eine sehr einfache Sprachkonstruktion oftmals nicht die erforderliche Mächtigkeit mitzubringen in der Lage ist. NASL hat sich hier für ein mittlerweile archaisch anmutendes, aber dennoch sehr mächtiges Modell entschieden. So werden beispielsweise typische Kontrollstrukturen wie if und for sowie die altbekannten arithmetischen und Bit-Operatoren bereitgestellt.

Vermengung von Logik und Daten

Das grösste Problem von NASL als Idee ist, dass hier eine Vermengung zwischen Logik und Daten gegeben ist. So werden Informationen zu einem Test bzw. einer Schwachstelle als auch deren Prüfkonstrukte in einer Datei gespeichert. Für das ungeübte Auge wird es deshalb relativ schwer, sich in der Vielfalt der Daten zurecht zu finden. Die meisten Entwickler von Plugin verzichten darauf, ihre verhältnismässig kurzen Skripte zu dokumentieren.

Dieses grundlegende Problem des Vermischens von Logik und Daten zieht aber noch weitere Kreise. Die jeweiligen Datenfelder sind nicht oder nur teilweise direkt ansprechbar. Gerade in alten Plugins wird deren englische Beschreibung gerne in der Variable desc["english"] abgelegt. Darin sind aber oftmals gleich mehrere Informationen enthalten, wie das Beispiel von Plugin 11707 zeigt:

  desc[“english”] = “
 Your system seems to be infected by the Bugbear.B virus
 (its backdoor has been detected on port 81).

More information: http://www.f-secure.com/v-descs/bugbear_b.shtml Solution: Use your favorite antivirus to disinfect your system. Standalone disinfection tools also exist : ftp://ftp.f-secure.com/anti-virus/tools/f-bugbr.zip Risk factor : High”;

Hier sind eine Beschreibung des Problems, ein Link zu weiterführenden Informationen, die möglichen Gegenmassnahmen und die Risikoeinstufung der Schwachstelle enthalten. Bei solchen Plugins ist es sehr schwer, auf die einzelnen Informationen zuzugreifen. Hierzu sind erweiterte reguläre Ausdrücke in den Freitextfeldern erforderlich.

Inkonsistente Entwicklungen

Jeder kann eigene NASL-Plugins schreiben und so sind viele von ihnen durch die Community in einer offenen Lizenz bereitgestellt. Dies führte jedoch dazu, dass die Homogenität der Skripte nicht durchgängig ist. Im vorangehenden Beispiel wird Risk factor (99.49% der Fall) geschrieben, an anderen Stellen wird Risk Factor (0.51% der Fall) verwendet. Oder manchmal werden doppelte Anführungszeichen, manchmal aber auch nur einfache Anführungszeichen verwendet. Ein Parsing mit regulären Ausdrücken erfordert das Berücksichtigen einer schier unendlichen Zahl an Variationen des gleichen Konstrukts.

Dies wird noch zusätzlich erschwert, indem für manche Daten gänzlich unterschiedliche Konstrukte eingesetzt werden können. Neuere Plugins verwenden zum Beispiel die Funktion script_set_attribute() mit dem Argument risk_factor, um das Risiko auszuweisen. Zur Definition der Beschreibung einer Schwachstelle können gar drei unterschiedliche Standardmethoden verwendet werden (natürlich lassen sich auch noch eigene Konstrukte realisieren, wie zum Beispiel in Plugin 10718):

Pos Variante Häufigkeit
1. script_set_attribute(attribute: "description", "foo"); 63.40%
2. desc["english"] = "foo"; 21.85%
3. script_description(english: "foo"); 14.73%

Vermengung von Daten und Layout

Das explizite Einfügen von Whitespaces hat einen ähnlichen Effekt. Dies betrifft nicht nur Konstrukte der Skriptsprache, sondern ebenfalls die jeweiligen Daten selber. So wird oftmals mit manuellen Einrückungen (Leerzeichen/Tabs) oder neuen Zeilen (\n) gearbeitet, wie zum Beispiel Plugin 42120 illustriert:

script_set_attribute(
     attribute:"description",
     value:string(
       "The version of Adobe Reader installed on the remote host is earlier\n",
       "than 9.2 / 8.1.7 / 7.1.4.  Such versions are potentially affected by\n",
       "multiple vulnerabilities :\n",
       "\n",
       "  - A heap overflow vulnerability. (CVE-2009-3459)\n",
       "\n",
       "  - A memory corruption issue. (CVE-2009-2985)\n",
       (...)

Eine erneute Vermengung zwischen Daten und Layout, die einfach nicht mehr zeitgemäss ist. So erfordert es zusätzliche Arbeit, aus den extrahierten Daten die Layoutdefinitionen zu entfernen, um ein eigenes Layout (z.B. eine individuelle Zeilenbreite oder ein anderes Verhalten für Absätze und Listen) durchzusetzen.

Fazit

NASL hat definitiv konzeptionelle Schwachstellen, die eine effiziente Weiterentwicklung der Plugins massgeblich erschwert. Viele Dinge sind nicht, nur mit erheblichem Aufwand oder gar Glück möglich. In der jetzigen Version ist NASL langfristig zum Scheitern verurteilt. Es täte besser, wenn Logik, Daten und Layout voneinander getrennt werden. Hierzu bietet sich XML oder JSON als Container-Format an.

In ihren Release-Notes zu Nessus 4.2 weist Tenable Security darauf hin, dass man für die neue Version und das neu eingeführte .nessus Format die jeweiligen Plugins überarbeitet, optimiert und vereinheitlicht hat – Ein richtiger Schritt in die richtige Richtung:

All plugins have been converted to a new registration API splitting the different labels (synopsis, description, solution, etc. are split into different calls, which is needed for the new .nessus format). (…) Over 99.9% of plugins now (…) use a new format for consistency and easier parsing.

Der Einsatz einer relationalen Datenbank wäre, auch wenn es die Komplexität von Nessus einmal mehr erhöhen würde, eine Vielzahl an Vorteilen mit sich bringen. Das Filtern und Sortieren von Plugins wäre bedeutend einfacher und zuverlässiger. Bei professionellen Sicherheitsüberprüfungen können solche Möglichkeiten von massgeblicher Wichtigkeit sein.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Sie wollen die Resistenz Ihres Unternehmens auf Malware prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv