Labs

Die scip Labs ist unsere hauseigene Forschungsabteilung, die einerseits mit der Erarbeitung des Verständnisses für neue Technologien beschäftigt ist, andererseits eigene Entwicklungen in den technischen Bereichen Auditing, Exploiting und Forensics vorantreibt. Im Blog werden regelmässig Neuigkeiten und Forschungsberichte veröffentlicht.

► 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

Alle Einträge