03.07.2009 | Autor / Redakteur: Mike Chapple / Stephan Augsten
In den vorangegangenen Kapiteln des Nessus-Lehrgangs ging es darum Nessus zu installieren, zu konfigurieren und einen einfachen Security-Scan zu starten. Bisher kamen die Signaturen aber alle aus der großen Datenbank von Tenable Network Security. In diesem dritten Teil unseres Nessus-Tutorials widmen wir uns maßgeschneiderten Attacken auf interne Applikationen mithilfe der Nessus Attack Scripting Language.
Die Signaturen von Tenable Network Security sind zweifelsohne eine großartige Quelle für die aktuellsten Schwachstellen-Informationen, und sie bieten Schutz gegen die meisten Bedrohungen von außen. Dennoch gibt es ein Szenario, das bei diesem Datenbank-Ansatz nicht berücksichtigt ist: individuelle Applikationen die innerhalb des Unternehmens geschrieben wurden und die bekanntermaßen Schwachstellen haben.
Stellen wir uns vor, wir haben eine maßgeschneiderte Web-Monitoring Applikation namens Killer-App, die eine bekannte Schwachstelle in einem Verzeichnis namens „killerapp.asp“ hat. Diese Applikation lief auf jedem Server der Netzwerk-Umgebung – bis sich herausstellte, dass es eine kritische Schwachstelle es anonymen Anwendern erlaubt, die Server abzuschalten.
Zwar wurde die Applikation danach entfernt, dennoch ist zu vermuten, dass sie auf einigen Servern noch immer installiert ist. Glücklicherweise kann die Nessus Attack Scripting Language (NASL) verwendet werden, um eine maßgeschneiderte Nessus „Attacke“ zu entwickeln, oder ein Prüfprogramm, das die Datei „killerapp.asp“ aufspürt.
Auf der folgenden Seite steht das komplette NASL-Script für dieses Szenario. Im Anschluss werden wir es auseinandernehmen, um die Struktur von NASL zu erklären.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2022784)