scip AG

Labs: Archiv Dezember 2009

Inhaltsverzeichnis

• 28.12.2009 – scip IT Security Forecast 2010
• 17.12.2009 – iPhone Backdoor GPS Tracking Video
• 14.12.2009 – Dropbox.com – Probleme mit HTTP Header Injection
• 11.12.2009 – Bevorzugte Programmiersprachen für Exploits
• 04.12.2009 – Kritik an Nessus Attack Scripting Language

► 28.12.2009 – scip IT Security Forecast 2010

Wie jedes Jahr möchten wir auch zum Ende von 2009 einen IT Security Forecast für das kommende Jahr 2010 machen. Nachfolgend eben jene Themen – nach Möglichkeiten in der Reihenfolge absteigender Priorität -, die sich unseres Erachtens manifestieren oder gar noch weiterentwickeln werden:

• Cloud Computing: Die Jahre 2010 und 2011 werden voraussichtlich ganz im Zeichen von Cloud Computing (SaaS) stehen. Schon im Q4 2009 konnte ein signifikanter Anstieg des Themas bei Herstellern, Nachrichtenportalen und Blogs beobachtet werden. Die Sicherheit verteilter dynamischer Systeme wird eine grosse Rolle bei zukünftigen Entwicklungen und Projekten spielen. ⇒ Der Markt für Cloud Computing ist laut Google Trends noch immer im Wachstum.

• Virtualisierung: Die Virtualisierung hat langsam ihren (ersten) Höhepunkt erreicht. Die meisten Unternehmen setzen mittlerweile nach Möglichkeiten virtuelle Systeme (Betriebssysteme und VLAN) ein, um Kosten zu sparen. Dieser Effekt wird das kommende Jahr noch optimiert werden, bis so manches Unternehmen zu grossen Teilen mit virtuellen Lösungen agiert. Uns sind mittlerweile drei Schweizer Banken bekannt, die diesen Schritt vollzogen haben. ⇒ Viele unserer Kunden haben Virtualisierung mittlerweile vorbehaltlos akzeptiert.

• Mobile Security: Im Rahmen unserer Projektarbeiten konnten wir im 2009 eine hohe Anzahl an Projektbegleitungen (Coaching, Consulting und Reviews) bezüglich mobilen Geräten machen. Klassische Geräte wie HTC mit Windows Mobile und RIM BlackBerry müssen sich mittlerweile gegen Google Android und das iPhone von Apple behaupten. Alle Hersteller sind mehrdennje darum bemüht, eine vorherrschende Marktstellung im Corporate-Umfeld zu erlangen. Allen voran wird Apple versuchen durch ein Mehr an Business-Features (z.B. zentrales Policy Enforcement) die wohlwollende Aufnahme im Geschäftsbereich durchzusetzen. ⇒ Ein Markt für den Verkauf von Exploits für mobile Geräte wurde erstmals Ende März 2010 diskutiert.

• Social Networks: Die Popularität von Diensten wie Facebook und Twitter schien in 2009 ungebrochen. Mit der Zunahme von Benutzern und den durch sie bereitgestellten Datenmengen steigt die Anforderung an die Sicherheit. Ereignisse wie der Datendiebstahl bei StudiVZ oder die komplett überarbeiteten Privacy-Settings von Facebook haben dazu beigetragen, die Awareness zu diesem Thema bei allen Beteiligten zu stärken. Facebook, Twitter, Xing und StudiVZ werden auch im kommenden Jahr ein Thema bleiben. ⇒ Die deutsche Politik erkennt je länger je mehr die Risiken des fehlenden Datenschutzes und beginnt dagegen vorzugehen.

• Windows 7: Neben Windows ME gilt Windows Vista als unpopulärstes Windows-Betriebssystem. Die meisten Benutzer und Firmen haben Vista komplett ausgelassen und werden im kommenden Jahr direkt von Windows XP auf Windows 7 migrieren. Die Sicherheit des jüngsten Desktop-Systems wird damit in den Mittelpunkt des Interesses von Angreifern und Administratoren rücken. Exploits werden sich zunehmend auf Windows 7 konzentrieren und nur noch beiläufig die Eigenarten von XP berücksichtigen. ⇒ Diese Voraussage erschien etwa 1-2 Jahre verfrüht. Aus diesem Grund wird dieser Punkt in den Forecast 2011 übernommen werden.

• Weiterentwicklung von Cross Site Scripting: XSS als Angriffsform hat ihren Höhepunkt 2006 erreicht. Die Hersteller von Webbrowser versuchen durch clientbasierte Ansätze den Erfolg derartiger Attacken einzudämmen: Microsoft benutzt einen stringbasierten Filter und Mozilla setzt auf die CSP. Haben sich die neuen Browser-Versionen ersteinmal etabliert, wird punktuell eine evolutionäre Weiterentwicklung der XSS-Angriffstechnik (Evasion) zu beobachten sein. ⇒ Vereinzelte Researcher haben versucht neue, vor allem browserabhängige, Infektionsvektoren zu identifizieren.

• Documents Client Exploiting: Lange Zeit fokussierten sich Angriffstechniken auf die durch einen Server exponierten Dienste. Mittlerweile ist eine Umkehr zu beobachten, da immer mehr Angriffe mittels komplexen Dokumentenformaten auf Clients abzielen. Dieser Trend wird anhalten und sich vor allem auf PDF und Office-Dokumenten einpendeln. Die im Dezember diesen Jahres populär gewordenen Schwachstellen im PDF-Dokumentenformat wird uns die kommenden Monate noch begleiten. ⇒ Ein eigentlich alter Angriffsvektor, der im Rahmen unserer Tests schon lange genutzt wird, hat dem Problem des Document Exploiting Ende März 2010 grosse mediale Aufmerksamkeit beschert.

• Angriff dank FIFA World Cup 2010: Die kommende Fussballweltmeisterschaft in Südafrika wird für eine Vielzahl an Scam- und Spam-Mails sowie Malware-Infektionen und SEO-Attacken herhalten. Gerade im Vorfeld werden Fussballfans mit Gewinnspielen, Reisen und Tickets geködert werden, um Kompromittierungen voranzutreiben. ⇒ Erste PDF-Malware wurde Ende März 2010 gesichtet.

• Fake Antivirus: Die Entwickler von Schadcode haben dieses Jahr umfassend begonnen, die breitflächig wahrgenommene Gefahr vor Viren für ihre Zwecke zu nutzen. Durch das Anpreisen von Fake Antivirus Lösungen bewegen sie Benutzer dazu, ihre Malware in gutem Willen zu installieren. Derlei Lösungen werden immer professioneller und damit für den unbedarften Benutzer immer schwieriger als Fälschungen zu erkennen. ⇒ Die Möglichkeiten von Fake Antivirus sind mittlerweile so bekannt, dass jeder versucht davon zu profitieren. Google hat dieser aktuellen Gefahr eine umfassende Untersuchung gewidmet.

• Wieder mehr Scans durch Drittfirmen: Viele Kunden haben versucht mittels kommerziellen Lösungen (z.B. Qualys) einen eigenen Prozess für ein automatisiertes Vulnerability Scanning zu etablieren. Die meisten von ihnen haben gemerkt, dass dies nicht so einfach nebenher umzusetzen ist (trotzdem muss solides Knowhow aufgebaut und stetig gestärkt werden). Aus diesem Grund erwarten wir wieder eher vermehrt die Durchführung von Netzwerkscans durch externe Beratungsfirmen. ⇒ Viele Kunden haben ihre regelmässigen Re-Checks beibehalten und teilweise umfangreichere Scans (vor allem im internen Netzwerk) angesetzt.

Update 6. April 2010

Die schon eingetroffenen Voraussagen wurden mit entsprechenden Quellenangaben erweitert.

Update 28. November 2010

Die restlichen Voraussagen wurden ebenso bezüglich ihrem Eintreten erweitert. Lediglich im Fall von Windows 7 trat diese noch nicht wie erwartet ein. Sie wird in den nächstjähren Forecast übernommen.

Marc Ruef | G+ (1027 Wörter)

► 17.12.2009 – iPhone Backdoor GPS Tracking Video

Seit einigen Monaten sind wir darum bemüht, Applikationen zu verschiedenen Zwecken für das Apple iPhone zu schreiben. Im Rahmen des scip_Talk vom 2. September 2009 haben wir eingeladenen Kunden eine Backdoor für das iPhone vorgestellt. (Ein Thema, das Wochen später einen neuen Zenith in Bezug auf seine Popularität erreichen sollte.)

Im Rahmen der Präsentation haben wir eine Demonstration dieser Hintertür – die kein Jailbreak erfordert – vorgetragen. Im gezeigten Video kann gesehen werden, wie durch eine eingeschleuste Applikation fortwährend der aktuelle Standort des kompromittierten Geräts übermittelt werden kann. Sowohl in Echtzeit als auch als Aufzeichnung lässt sich über die GPS-Daten die Bewegung des Benutzers einsehen. Andere Funktionen, wie zum Beispiel das Mithören von Telefonaten, sind ebenso machbar.

Das Video dieser geschlossenen Veranstaltung wurde nun ebenfalls auf YouTube öffentlich gemacht. Es ist zu sehen, wie alle fünf Minuten der aktuelle Standort durch das mobile Gerät übermittelt und auf der Karte dargestellt wird.

Technische Informationen zur Umsetzung korrupten Programmcodes für das iPhone sowie andere Geräte werden in Zukunft durch uns veröffentlicht werden. Ebenso werden wir in den kommenden Wochen Details zu einer Backdoor für HTC-Geräte mit Windows Mobile publik machen.

Stefan Friedli | G+ und Marc Ruef | G+ (283 Wörter)

► 14.12.2009 – Dropbox.com – Probleme mit HTTP Header Injection

Dropbox ist ein Programm für die Betriebssysteme Mac OS X, iPhone OS, Linux und Microsoft Windows. Sein Zweck ist die Synchronisation von Daten zwischen verschiedenen Rechnern und Benutzern, sowie das einfache zur Verfügung stellen von Bildern und anderen Dateien. [Source: Wikipedia ]

Dropbox ist ein gutes Beispiel dafür, dass Cloud Computing mit relativ einfachen Mitteln durchaus nützliche Anwendungen schaffen kann. Die Möglichkeit, Daten über verschiedene Systeme hinweg synchron zu halten, ist nicht neu, wird hier aber auf simple, leicht zu implementierende Mechanismen ermöglicht.

Auch wenn der Einsatz von Dropbox für sensitive Daten nicht zur Diskussion steht, so bietet es als Medium für non-sensitive Daten durchaus seinen Reiz. Doch letzten Endes stellt sich natürlich die Frage der Sicherheit: Cloud Computing heisst ja letzten Endes nichts anderes, als Daten irgendwo am Ende der Welt auf einem System zu speichern, dessen Interna man kaum bis gar nicht kennt. Dropbox ist sich dieses Problems natürlich durchaus bewusst und schreibt daher in seiner FAQ zum Thema Sicherheit:

Nobody can see your private files in Dropbox unless you deliberately invite them or put them in your Public folder. Everything in your Public folder is, by definition, accessible to anyone. Otherwise, the only way to access the files in your Dropbox online is with your username and password.

Wird Dropbox verwendet, so gibt es verschiedene Möglichkeiten auf Daten zuzugreifen. Die einfachste und gleichzeitig eleganteste ist es, den jeweiligen Client auf dem System zu installieren und ihn mit dem eigenen Dropbox-Account zu verknüpfen. Die Client-Software erstellt daraufhin ein lokales Folder im OS-spezifischen Dokumente-Verzeichnis, in dem die Daten synchron gehalten werden. Ausserdem wird eine Shell Extension installiert, die gewisse Modifikationen und Aktionen über das Kontextmenü zulässt, wie zum Beispiel die Einsicht in ältere Versionen des Dokumentes oder der Zugriff auf Daten im Webinterface.

Will ein Benutzer, aus welchen Gründen auch immer, ein Dropbox-Verzeichnis statt über seinen lokalen Dateimanager lieber über das Webinterface auf dropbox.com steuern, so bieten sich ihm zwei Möglichkeiten: Er öffnet seinen Webbrowser, ruft dropbox.com auf, authentisiert sich und erhält so seinen Zugang. Oder: Er wählt das Verzeichnis auf und wählt die Option “Browse on Dropbox Website”, der Client generiert eine Authentisierungs-URL und das Verzeichnis öffnet sich direkt im Webbrowser.

Bei der letzteren Variante, wird die Authentisierung durch den Dropbox-Client automatisiert durchgeführt. Die aufgerufene URL ähnelt der nachfolgenden:

https://www.dropbox.com/tray_login?i=372832&t=1260625705&v=f1a9afcb67f2372780f3893d170de164f070cb84&url=c%2Fbrowse%2FPhotos%3Fns_id%3D711010

Ersetzen wir die Parameter durch Platzhalter, die ihren vermuteten Nutzen wiederspiegeln, so erhalten wir:

https://www.dropbox.com/tray_login?i={Dropbox ID}&t={Timestamp}&v={Verification String}&url={Whatever Directory you want to access}

Der Browser sendet also Authentisierungsdaten, gemeinsam mit einem Timestamp und dem Pfad des gewünschten Zielverzeichnisses an den Dropbox Server. Dieser verarbeitet diese Information nun und stellt – sofern alles geklappt hat – die entsprechenden Cookies zur Verfügung, die den Browser eine authentisierte Session ermöglichen. Ausserdem wird der Browser durch einen Location: Header direkt auf die gewünschte Zielressource weitergeleitet, die ja per uri-Parameter mitgegeben werden.

HTTP/1.1 302 FOUND
Server: nginx/0.7.63
Date: Sat, 12 Dec 2009 13:48:26 GMT
Content-Type: text/html; charset=utf-8
X-Transfer-Encoding: chunked
Connection: keep-alive
set-cookie: lid=YADDAYADDAYADDAYADDAYADDAYADDA; Domain=www.dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: forumjar=YADDAYADDAYADDAYADDAYADDAYADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: taste=YADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDAYADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: jar=YADDAYADDAYADDA; Domain=www.dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: touch=YADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
set-cookie: forumlid=YADDAYADDAYADDA; Domain=dropbox.com; expires=Sun, 12-Dec-2010 13:48:26 GMT; Path=/; httponly
location: /c/browse/Photos?ns_id=711010
pragma: no-cache
cache-control: no-cache
Content-length: 324
(...)

Betrachten wir die Ausgabe, so fällt auf, dass der Wert des uri-Parameters direkt innerhalb des Location-Headers zu verwendet werden scheint. Wird dieser Wert nicht sauber verifiziert, ergibt sich daraus möglicherweise eine Schwachstelle. Überprüfen können wir dies zum Beispiel, in dem wir versuchen einen weiteren Header einzufügen, wie zum Beispiel über die nachfolgende URI, bei dem ein Zeilenumbruch (CRLF) und einen optionalen Header hinzufügen:

https://www.dropbox.com/tray_login?i=x&t=y&v=z&url=Whatever%0d%0aX-AllYourBase:%20Are%20belong%20to%20us

Der Aufruf dieser URI führt zu folgendem Ergebnissen:

HTTP/1.1 302 FOUND
Server: nginx/0.7.63
Date: Sat, 12 Dec 2009 14:04:52 GMT
Content-Type: text/html; charset=utf-8
X-Transfer-Encoding: chunked
Connection: keep-alive
set-cookie: frmtry=MQ%3D%3D; Path=/; httponly
location: /Whatever
X-AllYourBase: Are belong to us
pragma: no-cache
cache-control: no-cache
Content-length: 348

Tatsächlich wird serverseitig keine solide Validierung des Parameters uri durchgeführt. Dadurch können wir, mit dem vorgängig gezeigten Verfahren, beliebige HTTP Header im Anschluss an den Location Header injizieren. Dadurch, dass wir unsere eigenen Header nach der originalen Location-Zeile platzieren, können wir zum Beispiel beliebige Redirects vornehmen:

https://www.dropbox.com/tray_login?i=x&t=y&v=z&url=Whatever%0d%0aLocation:%20http://www.scip.ch

HTTP/1.1 302 FOUND
Server: nginx/0.7.63
Date: Sat, 12 Dec 2009 14:10:50 GMT
Content-Type: text/html; charset=utf-8
X-Transfer-Encoding: chunked
Connection: keep-alive
set-cookie: frmtry=MQ%3D%3D; Path=/; httponly
location: /Whatever
Location: http://www.scip.ch
pragma: no-cache
cache-control: no-cache
Content-length: 342

Derartige Angriffe werden häufig zu Phishing Zwecken eingesetzt, um über eine vertrauenswürdige URI (http://www.dropbox.com/...) bösartige Inhalte zu verteilen. So könnte zum Beispiel auf eine gefälschte Loginseite verwiesen werden, um in den Besitz von Authentisierungsdaten zu kommen. Auch ein Redirect auf Schadcode, zum Beispiel getarnt mit einem Namen wie DropboxUpdate_1_2.exe wäre eine mögliche Variante, mit dieser Schwachstelle auf einfachem Wege Schaden anzurichten.

Doch Redirects sind nicht alles, was sich mit einer derartigen HTTP Header Injection bewerkstelligen liesse. Über eine HTTP Response Splitting Attacke könnte eine zweite HTTP Response angehängt werden, durch die der Angreifer beliebigen Code im Kontext von www.dropbox.com zur Ausführung bringen kann. Auch diese Variante wäre zum Zwecke von Phishingangriffen denkbar, aber auch klassisches Exploiting und Session Hijacking wäre in diesem Kontext sicherlich eine denkbare Variante.

Dropbox wurde über die Schwachstelle informiert und ist um die Schliessung der serverseitigen Schwachstelle bemüht. Bis zu diesem Zeitpunkt sei empfohlen, Sessions auf dropbox.com zeitnah nach der Benutzung zu terminieren und im Hinblick auf dahingehende Links vorsichtig zu agieren.

Stefan Friedli | G+ (1103 Wörter)

► 11.12.2009 – Bevorzugte Programmiersprachen für Exploits

Gemeinhin wird unter einem Exploit ein Stück Software verstanden, das für die automatisierte oder semi-automatisierte Ausnutzung einer Sicherheitslücke genutzt werden kann. Im einfachsten Fall wird beispielsweise die IP-Adresse des Zielsystems angegeben und auf diesem durch die angegangene Sicherheitslücke erweiterte Rechte erlangt.

Durch eine statistische Auswertung aktueller Standalone-Exploits sollten Rückschlüsse auf bevorzugte Programmiersprachen gezogen werden. Hierzu wurden die ersten 9’500 Exploits, welche auf der populären Webseite milw0rm.com veröffentlicht wurden (der vermeintliche Tod von str0ke war zum Glück nur ein Hoax), untersucht.

Obenstehende Grafik zeigt die Verteilung der Popularität der einzelnen Programmiersprachen auf. Hierbei ist zu sehen, dass in ANSI C geschriebene Exploits mit 33.66% den ersten Platz belegen. Dicht gefolgt mit 30.01% von in Perl umgesetzten Exploits. Die Popularität dieser klassischen Sprachen ist noch immer – gerade im Security-Bereich – anhaltend. Viele klassische Exploits wurden damit umgesetzt und damit das Verständnis für diese Sprache fest verankert.

Auf Platz drei folgt mit 14.23% – also schon ein bisschen abgeschlagen – die eigentlich eher unerwartete Sprache PHP. Sie wird vorzugsweise im Webbereich eingesetzt und geniesst keinen sonderlich guten Ruf. Immerwieder wird ihr von vermeintlichen “Experten” angedichtet, per se zu Sicherheitslücken zu neigen. Die dann doch überdurchschnittlich hohe Popularität im Exploiting-Bereich dürfte mitunter auf die Einfachheit der Sprache dank der Vielzahl bereitgestellter Funktionen zurückzuführen sein.

Abgesehen von HTML als Seitenbeschreibungssprache scheint die restliche Wahl der Programmiersprachen effektiv den Vorlieben der jeweiligen Entwickler zu unterliegen. So ist absehbar, dass Ruby auf Grund seiner Eleganz mittelfristig in die Top 5 kommen wird. Ruby ist sowieso ein Sonderfall, da seit MetaSploit 3.0 sowohl der Core als auch die Exploit-Module in dieser Sprache geschrieben werden und damit einem breiten Publikum die Vorteile im Exploiting-Bereich nähergebracht wurde. In einem Blog-Beitrag des Projekts wird es gar als die bis dato umfassendste Ruby-Entwicklung bezeichnet:

After all, msf is far and away the biggest ruby project on the planet. HD has done an excellent job with the new module format to reduce that initial overhead (...)

Sprachen wie Java, LISP und Pascal scheinen sich hingegen wegen ihrer Schwerfälligkeit oder den veralteten Konzepten nicht für Entwicklungen auf diesem Gebiet anzubieten. Die Seitenbeschreibungssprache HTML ist dann auch ein Sonderfall, denn ihr Auftreten ist wohl einzig und allein auf die in Webbrowsern gefundenen Schwachstellen zurückzuführen. Das Umsetzen anderweitiger Exploits in HTML ist dann eben doch eine eher unpopuläre Ausnahme.

Marc Ruef | G+ (514 Wörter)

► 04.12.2009 – Kritik an Nessus Attack Scripting Language

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 200X-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):

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.

Marc Ruef | G+ (1041 Wörter)

Labs Übersicht

• Letzte Beiträge
  • Computer Forensik – Ein Überblick
  • Vortrag zu Security Testing an SGRP Veranstaltung
  • Staatstrojaner – Kritik am neuen Bundesgesetz
  • Overview of Microsoft’s security toolkit EMET
  • Blog Digest April 2013
  • Wie statisch sollten Sicherheitsrichtlinien sein?
  • Timing für effiziente unentdeckte Portscans
  • Interpreting a Logfile with Grok
  • Spamhaus DDoS mit DNS Amplification
  • Blog Digest März 2013
• Archiv
  • 2013 | 2012 | 2011 | 2010 | 2009 |

• Blog Digest

• Blogroll
  • abuse.ch
  • c22.cc
  • computec.ch
  • darkreading.com
  • infosecisland.com
  • krebsonsecurity
  • metasploit.com
  • schneier.com
  • securiteam.com
  • stfn.ch
  • zeltser.com
  • 5e4n.ch
• Syndication
  • RSS
  • Twitter