Labs: Archiv 2011
Inhaltsverzeichnis
- 29.12.2011 – Blog Digest Dezember 2011
- 22.12.2011 – scip IT Security Forecast 2012
- 14.12.2011 – Welt der Wunder – Behind the Scenes
- 09.12.2011 – Konferenzen November 2011
- 30.11.2011 – Blog Digest November 2011
- 25.11.2011 – Vortrag zu Cloud Computing an Datenschutzforum Zürich
- 16.11.2011 – Vortrag an Symposium von BKA/BLKA/Fedpol
- 10.11.2011 – Sicherheit von Cloud Computing
- 03.11.2011 – Forensik von iMessage auf iOS5
- 29.10.2011 – Hashdays 2011 Diary, Tag 2: Mein Vortrag und inspirierende Talks
- 28.10.2011 – Hashdays 2011 Diary, Tag 1: Erste Vorträge und Treffen
- 27.10.2011 – Hashdays 2011 Diary, Tag 0: Anreise und Speakers-Dinner
- 26.10.2011 – Blog Digest Oktober 2011
- 19.10.2011 – Staatstrojaner – Bedenken und Kritik
- 13.10.2011 – scip Talks & Presentations Preview: 4. Quartal 2011
- 06.10.2011 – 10 Gründe gegen Short-URLs
- 30.09.2011 – Blog Digest September 2011
- 27.09.2011 – Vortrag an BruCON 2011 in Brüssel
- 22.09.2011 – Vortrag zu Information Security und Marketing
- 14.09.2011 – Eingabeprüfung im Detail
- 08.09.2011 – Vortrag zu Real World Attacks
- 02.09.2011 – Vortrag zu Cybercrime
- 29.08.2011 – Blog Digest August 2011
- 25.08.2011 – Las Vegas 2011
- 18.08.2011 – Einführung in httprecon
- 11.08.2011 – Social Media Strategie der scip AG
- 04.08.2011 – Effizientes Portscanning mit Porteinschränkungen
- 29.07.2011 – Blog Digest Juli 2011
- 21.07.2011 – Modell zur Umsetzung von Config Reviews
- 14.07.2011 – Gedanken zum Tainted Mode in der Programmierung
- 07.07.2011 – Sicherheitsprobleme der Öffnung von Top-Level-Domains
- 30.06.2011 – Blog Digest Juni 2011
- 23.06.2011 – Präsentation zur Sicherheit in Sozialen Netzen
- 16.06.2011 – Open-Source und die Auswirkungen auf die Sicherheit
- 09.06.2011 – Technische Scan Details
- 02.06.2011 – Top 5 Stupid Captcha Implementations
- 27.05.2011 – Blog Digest Mai 2011
- 19.05.2011 – Reduzierbarkeit von Tests
- 12.05.2011 – iPhone Forensik
- 05.05.2011 – Konkrete Massnahmen in der Datencloud
- 29.04.2011 – Blog Digest April 2011
- 28.04.2011 – PlayStation Network Breach: Fakten und Gerüchte
- 21.04.2011 – Firefox-Addons für Penetration Tests
- 14.04.2011 – Kritik an Proxies als Massnahme
- 07.04.2011 – Windows 7 Hardening: Eine Übersicht
- 31.03.2011 – Blog Digest März 2011
- 23.03.2011 – Kompromittierung von RSA – Fakten und Einschätzung
- 17.03.2011 – Problem von OS Fingerprinting Kaskadierung
- 10.03.2011 – Vorstellung des Penetration Testing Execution Standard
- 03.03.2011 – HTTP Request Header Tagging
- 25.02.2011 – Blog Digest Februar 2011
- 17.02.2011 – Passwortlänge von Security Researcher
- 08.02.2011 – Shmoocon 2011 – ein kurzer Rückblick
- 04.02.2011 – Video zu Nmap NSE Vortrag an Hashdays 2010
- 31.01.2011 – Erfolgreicher Angriff gegen X-pire!
- 27.01.2011 – Blog Digest Januar 2011
- 20.01.2011 – Clientseitige Sicherheit am Beispiel der Playstation 3
- 13.01.2011 – Firewall Rule Parsing am Beispiel von SonicWALL
- 06.01.2011 – Grundlegende RFID-Sicherheit
► 29.12.2011 – Blog Digest Dezember 2011
- 1% of CMS-Powered Sites Expose Their Database Passwords (feross)
- Abusing IP Protocols to Create Covert Channels (resources.infosecinstitute.com)
- Authentication: What is a factor anyway? (securitycurve.com)
- Can you crack it – interesting challenge (blog.pi3.com.pl)
- Cisco says 70% of young workers ignore IT rules (bizjournals.com)
- Does Android Malware Exist? (securelist.com)
- Dump Windows password hashes efficiently – Part 1 (BernardoDamele)
- Facebook bans at work linked to increased security breaches (itbusiness.ca)
- hashdays: There goes 2011, here comes 2012! (blog.stfn.ch)
- HTML scriptless attacks (thespanner.co.uk)
- Image Steganography Tutorial & Concept (resources.infosecinstitute.com)
- Insecure Object Mapping (carnal0wnage.attackresearch.com)
- Lost USB keys have 66% chance of malware (GrahamCluleysBlog)
- Metasploit: Six Ways to Automate Metasploit (community.rapid7.com)
- Mobile Device Location Tracking, and Why It Matters (SpiderlabsAnterior)
- Nmap on Amazon Kindle (k0st.wordpress.com)
- Quality Coding Takes A Break For The Holidays. But Why? (threatpost.com)
- Remote control manager FAIL (skullsecurity.org)
- Rethinking Mobile Security (darkreading.com)
- Schneier on Security: Recent Developments in Full Disclosure (schneier.com)
- Security Holes In Software Decreased This Year, Early Data Shows (darkreading.com)
- Static Code Analysis (altdevblogaday.com)
- Steps to Avoid Mental Stagnation (Wh1t3Rabbit)
- Ten Best Practices For Meeting SOX Security Requirements (darkreading.com)
- The Art of Profiling Cybercriminals (darkreading.com)
- The more things change, the more they stay the same! (blog.c22.cc)
- The ‘Security’ Impact of Performance (Wh1t3Rabbit)
- Top 10 Security Mistakes SMBs Make (darkreading.com)
- Trusted Execution In Untrusted Cloud (theinvisiblethings.blogspot.com)
- Understanding Firefox and SQLite Tables for Forensics (resources.infosecinstitute.com)
- Using Facebook as a proxy (ihteam.net)
- Using Fuzzing to Spice Up a Penetration Test (pen-testing.sans.org)
- VLAN Hacking (resources.infosecinstitute.com)
- What Data Lurks on Your Old Smartphone? (foxnews.com)
- Why I Will Never Feel Threatened by Programmers in India (blog.jpl-consulting.com)
- Windows Phone SMS attack discovered, reboots device (winrumors.com)
► 22.12.2011 – scip IT Security Forecast 2012
Wie jedes Jahr möchten wir auch zum Ende von 2011 einen IT Security Forecast für das kommende Jahr 2012 machen. Nachfolgend eben jene Themen – nach Möglichkeiten in der Reihenfolge absteigender Priorität -, die sich unseres Erachtens manifestieren oder gar noch weiterentwickeln werden:
- Probleme bei Migration zu Windows 7: Erste grössere Firmen haben dieses Jahr mit dem Rollout von Windows 7 begonnen. Dabei sind vereinzelt Probleme aufgetaucht, die auch für anderen Firmen eine Herausforderung sein werden. Dazu gehört beispielsweise das punktuell veränderte Verhalten in der Registry, was bisweilen zu Inkompatibilitäten in bestehenden Lösungen führen wird. Da hiervon ebenfalls Sicherheitseinstellungen betroffen sind, ist eine durchdachte und geplante Migration von erhöhter Wichtigkeit, um das zuvor bei Windows XP erreichte Sicherheitsdispositiv nicht zu untergraben.
- Erste Exploits für Windows 8: Mit dem Erscheinen der Developer Preview wurde breitflächig das Interesse an der nächsten Windows-Generation geweckt. Die veränderte Sicherheitsarchitektur wird dazu führen, dass erste Exploits, die explizit auf Windows 8 abzielen, entwickelt werden. Ob und inwiefern sich Erkenntnisse dieser Art aus den Vorversionen übernehmen lassen, wird sich im Laufe der Zeit zeigen.
- Gezielte Angriffe auf Jailbreaks: Restriktive Systemmodelle, wie sie besonders durch Apple gross gemacht wurde, stossen zunehmends auf Widerstand. Durch die Vereinfachung von Jailbreaks und den damit erschliessbaren Vorteilen wird eine zunehmende Anzahl an Benutzern die erweiterte Freiheit für sich in Anspruch nehmen wollen. Damit wird aber auch die Angriffsfläche verschoben: Jailbreaks werden zunehmend auch für Angreifer attraktiver. Hersteller und Betreiber werden sich also darum bemühen, diese zu erschweren oder Auswirkungen von erfolgreichen Angriffen zu minimieren.
- Cloud-Security ein konkretes Thema: Das Thema Cloud-Computing galt seit 2007 als das zentrale Buzzword der Branche. Laut Google Trends hat das Thema zwar im Jahr 2011 den Zenit erreicht. Firmen fangen jedoch erst jetzt an, die Möglichkeiten von SaaS und IaaS für sich zu entdecken. Mit diesem Schritt werden aber sowohl klassische Probleme des Outsourcing wiederbelebt, als auch neue Probleme der neuen Methodiken eingeführt. Spezifische Diskussionen zu konkreten Problemstellungen werden deshalb spürbar zunehmen.
- Weitere Angriffe durch Anonymous/LulzSec: Die umstrittenen Hacker-Kollektive werden ihre hacktivistischen Bewegung fortsetzen und damit auch in kommender Zeit für Unruhe im Internet sorgen. Damit wird das Thema IT-Security auch in der breiten Masse wahrgenommen und unweigerlich zu einem zentralen Aspekt der modernen Informationsgesellschaft. Dies wird von manchen Experten als wichtige Ausgangslage für Verbesserungen in diesem mittlerweile vitalen Bereich der Menschheit verstanden.
- IPv6 wird vorangetrieben: Die nächste Generation der populären Protokollarchitektur konnte sich am vergangenen Word IPv6 Day in positivem Sinne etablieren. Damit wurde aufgezeigt, dass der Wechsel gar nicht so schwierig ist, wie das gerne behauptet wird. Viele Provider und Firmen werden sich zunehmend um die Einführung von IPv6 bemühen, wodurch sich auch das Thema Netzwerksicherheit in breiten Teilen verändern wird.
- Zunehmende Datenschutzkritik an Facebook: Die Freude an Sozialen Netzen wird zunehmend durch drohende Verletzungen des Datenschutzes getrübt. Immer mehr Benutzer werden gerade grösseren Portalen wie Facebook misstrauen und sich mittelfristig möglichst passiv verhalten oder ganz von diesen zurückziehen wollen.
- Schwierigkeiten bei SSD-Forensik: Solid-State-Drive lösen aufgrund ihrer enormen Performance klassische Festplatten zunehmends ab. Dabei bleibt ein zentraler Aspekt bis heute weitestgehend unbeachtet. Einerseits lassen sich Daten nicht verlässlich löschen (wipen), andererseits gestaltet sich die Datenwiederherstellung im Rahmen einer forensischen Analyse besonders schwierig (unzuverlässig). Diese Eigenschaften werden in kommender Zeit unter Spezialisten vermehrt für Gesprächsstoff sorgen.
► 14.12.2011 – Welt der Wunder – Behind the Scenes
Am 20. November wurde in der Sendung Welt der Wunder ein Bericht über unser Unternehmen ausgestrahlt. Darin wurde aufgezeigt, wie ein typischer Ablauf zur Prüfung der Sicherheit eines Unternehmens aussehen kann. Dabei wurde in einer ersten Phase ein breitflächiger Phishing-Angriff auf die Mitarbeiter der Redaktion angegangen, um in einer zweiten Phase eine technische Attacke auf einen exponierten Server umzusetzen. Ein Online-Stream des Beitrags kann auf der Webseite des Senders gesehen werden.
Dieser Bericht ist breitflächig auf positives Echo gestossen. Viele Leute kamen auf uns zu und wollten wissen, wie ein solcher Beitrag denn überhaupt zustande kommt. Gerne versuche ich einen kleinen Einblick hinter die Kulissen zu gewähren.
Der initiale Kontakt mit der Welt der Wunder-Redaktion kam auf Empfehlung zustande. Eine Person aus dem Umfeld des Senders hat auf meine Arbeit und unser Unternehmen verwiesen. Man hat uns dann direkt kontaktiert und wollte wissen, ob und inwiefern wir sie bei der Erstellung eines Beitrags unterstützen könnten.
In mehreren Telefongesprächen und Schriftwechseln per Email wurden die Hintergründe unserer Arbeit erläutert und Möglichkeiten diskutiert, wie sich diese für den Zuschauer nachvollziehbar skizzieren lässt. Ursprünglich sollte sich das Szenario auf das Finanzumfeld fokussieren und die relativ hohe Sicherheit der Schweizer Banken in den Mittelpunkt rücken.
Aus dramaturgischen und produktionstechnischen Gründen hat man sich dann aber darauf geeinigt, dass der Angriff auf die Redaktion von Welt der Wunder durchgeführt werden soll. Dabei wurde absichtlich ein zweistufiges Szenario ausgearbeitet, um die verschiedenen Herangehensweisen und die etwaige Beharrlichkeit von professionellen Angreifern aufzuzeigen (Stichwort: APT). Die grundlegenden Einstellungen, die den Bericht ausmachen sollten, wurden in einem mehrseitigen Drehbuch dokumentiert.
Aufgrund unseres komplexen und eng gestrickten Arbeitsalltags musste schon sehr früh ein Drehtag in Zürich ausgehandelt werden. Rund einen Monat vor der Ausstrahlung reiste die Aufnahmeleiterin und das Aufnahmeteam in die Schweiz, um den Dreh vor Ort vorzunehmen. In Rund 10 Stunden wurde der Dreh abgefertigt, die schlussendlich im finalen Beitrag nur einige wenige Minuten ausmachen sollten. Dies ist der übliche Durchschnitt, den wir auch bei Aufzeichnungen für Nachrichtensendungen (z.B. 10vor10 für das Schweizer Fernsehen) erfahren haben: Gerne wird zu viel Material gedreht, um dann im Schnitt eine möglichst hohe Auswahl an Einstellungen und Varianten zu haben. Für viele Szenen sind mehrere Aufnahmen erforderlich, um Versprecher korrigieren und verschiedene Perspektiven drehen zu können.
Die Aufnahmen in Zürich dokumentierten unsere Sichtweise als Auditoren. Das Gegenstück sollte in der Redaktion in München, die von uns angegriffen wurde, aufgenommen werden. Dies wurde unabhängig von uns gemacht und nur punktuell orchestriert (z.B. Mails vorbereitet, Telefongespräche aufgenommen, etc.). Der Zusammenschnitt dieser beiden Perspektiven sollte die Spannung und Authentizität des Beitrags gewährleisten.
Vor und während dem Dreh haben wir das Aufnahmeteam fortwährend beraten, um einen spannenden und zeitgleich plausiblen Beitrag erreichen zu können. Medienschaffende verlieren leider oftmal letzteres schnell aus den Augen und können damit ungewollt die Glaubwürdigkeit der Protagonisten mindern. In diesem Fall wurden unsere Wünsche aber weitestgehend berücksichtigt und so waren wir sehr zufrieden mit dem Endresultat. Wir denken, dass damit ein wirklich guter Beitrag entstanden ist, der ein hochkomplexes Thema leicht verständlich und unterhaltsam zusammenzufassen in der Lage ist. Aus diesem Grund möchten wir uns explizit bei Julia Nölker, dem TPC-Aufnahmeteam und der Welt der Wunder-Redaktion bedanken. Und ebenso bei Ramon Kukla, der uns ebenfalls unterstützt hat.
► 09.12.2011 – Konferenzen November 2011
Auch im November war die scip AG viel unterwegs: Sowohl an der etablierten SOURCE Barcelona wie auch an der SecurityZone in Cali, der ersten Sicherheitskonferenz in Kolumbien überhaupt, war Stefan Friedli als Speaker präsent.
SOURCE Barcelona
Die Konferenzserie SOURCE hat sich innerhalb der letzten Jahre einen guten Namen gemacht. Organisiert von Stacy Thayer und Veracode-Gründer Christien Rioux präsentiert die bewusst kleingehaltene Konferenz seit Jahren einen hervorragenden Mix aus interessantem Infosec-Business Content und ausgezeichnetem technischen Inhalt. Zum wiederholten Mal war auch Stefan Friedli der scip AG auf dem Speaker Lineup vertreten und präsentierte eine aktualisierte Version seines Talks “How not to do a penetration test”.
Joshua Corman von Akamai referierte über Anonymous und den Umgang mit dieser relativ neuen, schwer greifbaren Macht im digitalen Raum. Ryan Jones von Trustwave sprach derweil über Security Convergence und empfahl, Sicherheit als gesamtheitliches Element zu betrachten, sei es nun in physischer oder digitaler Form. Ian Amit präsentierte eine aktualisierte Version seines überaus beliebten Data Exfiltration Talks und Chris Nickerson zog bedrohlich akkurate Parallelen zwischen spanischer Kriegsgeschichte und aktuellen Infosec Themen.
Zum ersten Mal wurde auch ein komplett spanischer Track am ersten Tag präsentiert, der die lokale Industrie und Community fördern und stimulieren sollte. Auch hier konnten offensichtlich gute Speaker und solide Besucherzahlen realisiert werden, was gesamthaft als Erfolg gewertet werden darf.
Wie in den vorhergehenden Jahren war die SOURCE Barcelona ein absolut lohnenswertes Ereignis. Der Mix aus Business und Technologie macht die Konferenz relevant für eine breite Zielgruppe ohne dabei den Fokus zu verlieren. Wir hoffen, auch bei kommenden Editionen eine Rolle spielen zu dürfen.
SecZone Cali, Kolumbien
Die meisten unserer Mitarbeiter sind sich Reisen zu Konferenzen mittlerweile gewohnt. Das liegt primär daran, dass die meisten Konferenzen in Europe oder den USA stattfinden, mit einigen Abstechern in den asiatischen und arabischen Raum. Dass wir eine Einladung nach Kolumbien erhalten, ist da dann doch eher speziell.
Tatsächlich handelt es sich bei der SecZone um die erste internationale Sicherheitskonferenz in Kolumbien überhaupt. Während die Reaktionen bei anderen Konferenzen oft enthusiastisch ausfallen, so wurde uns im Vorfeld oft angeraten doch lieber niemanden ins angeblich gefährliche Kolumbien zu schicken. Ein Ratschlag, den wir nach ausführlicher Recherche ignorierten.
Nach einer knapp 24-stündigen Odyssee von Zürich nach Madrid nach Bogota endlich nach Cali im Südwesten des Landes beim Hotel angekommen stellte sich schnell heraus dass unsere Entscheidung richtig war: Überaus freundlich und kompetent wurden die Speaker des Events behandelt. Der generellen Tatsache zum Trotz, dass Cali vermutlich unsicherer ist als Zürich, wurden wir während des gesamten Aufenthaltes enorm zuvorkommend behandelt – trotz komplett fehlender Spanischkenntnisse und Stefans Haarfarbe, die in Südamerika eher als auffällig zu betrachten ist.
Das Event erregte in Kolumbien grosse Medienaufmerksamkeit und mehrere TV Teams sowie unzählige Zeitungsreporter waren mehr oder minder konstant vor Ort und versuchten Interviews der Speaker zu bekommen. Auch die Teilnehmerzahl konnte überzeugen: Die beiden Tracks (jeweils mit 250 Plätzen) waren zu jedem Zeitpunkt gut belegt und die bereitgestellten Videostreams zählten insgesamt 2800 Verbindungen. Wir werden die Videos an dieser Stelle verlinken, sobald diese verfügbar sind.
Nach einer Woche bei warmen 20-30°C, einigen Sightseeing Touren (mit konstantem Polizeischutz – reine Formsache natürlich…) und der obligaten DirtySec Party ging es dann auch schon wieder zurück in die (deutlich kühlere) Schweiz. Die Frage, ob wir wieder einen Speaker nach Kolumbien schicken würden, können wir währenddessen guten Gewissens mit einem “¡Si, claro!” beantworten.
scip AG (624 Wörter)
► 30.11.2011 – Blog Digest November 2011
- Analyzing malicious files for writing network signatures (zscaler)
- Authentication: What is a factor anyway? (securitycurve.com)
- Baking Strong Authentication Into Client Devices (darkreading.com)
- Biggest Cybercriminal Takedown in History (KrebsOnSecurity)
- Biology Rules Apply to Infosec? (blog.rootshell.be)
- Brute force attack a BIOS with Arduino (alfersoft.com.ar)
- Cloud Controls Matrix (CCM) – Cloud Security Alliance (cloudsecurityalliance.org)
- Crypteks USB™ – Inspired Design meets Ultra-Security (kickstarter.com)
- Curing the Credit Card Cancer (MartinMckeaysNetworkSecurityBlog)
- Data Loss Prevention – Without the New Blinky Boxex (Wh1t3Rabbit)
- Duqu: Questions and Answers (f-secure.com)
- Facebook: Anatomy of Self-Inflicted Javascript Injection (zscaler)
- Fighting 0days With Fundamentals (darkreading.com)
- Google Open Sources Android 4.0, Ice Cream Sandwich (Techcrunch)
- Greater choice for wireless access point owners (googleblog.blogspot.com)
- How Much Is Your Identity Worth? (KrebsOnSecurity)
- Intro to HDMoore’s Law (cognitivedissidents.wordpress.com)
- IPhone: Cracking Siri (applidium.com) [Inofficial Mirror]
- Microsoft aims to reduce Windows Update restarts (zdnet.co.uk)
- Pen Tests: Not Getting ‘In’ is an Option (darkreading.com)
- Pipal, Password Analyser (digininja.org)
- Plugging the Kiosk-sized Security Hole (darkreading.com)
- Randomness in cryptography – the devil’s in the details (GrahamCluleysBlog)
- Securing User Credentials On Mobile Devices (blogs.mcafee.com)
- Seven Annoying Attacks That Facebook Misses (barracudalabs.com)
- Study: Users Are Mad About Breaches, And They’re Not Going To Take It (darkreading.com)
- Top 15 Cloud Security Best Practices (blogs.mcafee.com)
- Traceroute-like HTTP scanner (agarri.fr)
- Want to create a really strong Password, don’t ask Google (lightbluetouchpaper.org)
- WireShnork – A Snort plugin for Wireshark (honeynet.org)
► 25.11.2011 – Vortrag zu Cloud Computing an Datenschutzforum Zürich
Mehrmals im Jahr treffen sich die Mitglieder des Datenschutzforum Schweiz, um über aktuelle Geschehnisse im Bereich der Informationssicherheit zu diskutieren. An der jüngsten Zusammenkunft in Zürich des vergangenen Dienstags wurde das Thema Sicherheit im Cloud Computing behandelt. Vor dem vorwiegend aus Juristen und Sicherheitsbeauftragten bestehenden Publikum wurden zwei Vorträge zum Thema gehalten.
Auf technischer, konzeptioneller und organisatorischer Ebene sollte ich mich als erstes zum Thema äussern dürfen. Mein Vortrag führte kurz in das Konzept des Cloud Computing ein, um danach die zentralen Risiken einer solchen Lösung aufzuzeigen. Dabei habe ich mich in erster Linie an meinen Publikationen 10 sicherheitsrelevante Gründe gegen Cloud Computing sowie Sicherheit von Cloud Computing orientiert. Die zentrale Kritik entsprechender Lösungen fusst dann auch darauf, dass die Transparenz verloren geht und damit zwangsweise weiterführende Risiken mitgezogen werden. Dabei habe ich mehrfach versucht darauf hinzuweisen, dass diese Probleme generell dem Outsourcing – und Cloud Computing ist meines Erachtens ein Subset dessen – zuzuordnen ist.
Nach eine spannenden Fragerunde war lic. iur. David Rosenthal der Zürcher Anwaltskanzlei Homburger dran (Ich habe einen Monat zuvor mit Luca Dal Molin der gleichen Kanzlei einen Vortrag an den Hashdays gehalten). In seinen Ausführungen, die auch er in erster Linie an das klassische Konzept des Outsourcings band, sollten die juristischen Aspekte der Zuständigkeit und Haftbarkeit skizziert werden. Dabei war besonders spannend zu hören, dass beim Erfüllen einer allgemein anerkannten Sorgfalt gewisse Risiken nicht immer auf Vertragspartner abgewälzt werden können. Gewisse Probleme können damit durchaus durch ein juristisches Raster fallen.
Im Anschluss gab es einen kleinen Apéro, an dem ich mich mit verschiedenen Leuten aus den unterschiedlichsten Bereichen unterhalten konnte. In erster Linie ein in der Schweiz bekannter Outsourcer konnte sich für die kontroverse Diskussion begeistern. Wir konnten uns darauf einigen, dass Cloud Computing durchaus seine Daseinsberechtigung hat. In gewissen Bereichen erschliessen sich damit grosse Vorteile. Dies setzt aber eine durchdachte Migration voraus, die gewisse Anforderungen – auch an den Kunden selbst – stellen.
► 16.11.2011 – Vortrag an Symposium von BKA/BLKA/Fedpol
Am 09./10. November 2011 fand in Wiesbaden zum zweiten Mal das Symposium Future IT – Neue Technologien statt. In Zusammenarbeit mit BKA, BLKA und Fedpol treffen sich verschiedene Einsatzkräfte aus verschiedensten Ländern, um aktuelle Entwicklungen und Bedrohungen im virtuellen Bereich zu diskutieren. Neben verschiedenen Vorträgen stehen dabei natürlich auch Diskussionen und Networking im Mittelpunkt.
Tag 1 – Internet, Cybercrime, IT-Forensik
Die Reise nach Wiesbaden sollte ich mit der Bahn bestreiten. In den 4 Stunden der Reise sollte ich mit die Möglichkeit erschaffen, auf Laptop und iPad ein bisschen zu arbeiten und meinen Vortrag nocheinmal durchzugehen. Am Vorabend des ersten Tages in Wiesbaden angekommen, fuhr ich nach Schlangenbad, einem rund 20 km von Wiesbaden entfernten Kurort. Das Kurhotel war ruhig und abgelegen – Perfekt, um ein bisschen der üblichen Hektik meines Arbeitsalltags zu entfliehen.
Am Morgen des ersten Konferenztages fuhr ich mit dem Taxi zum BKA-Hauptgebäude in Wiesbaden. Die Anmeldung verlief unkompliziert und ich konnte mich vorgängig in den Räumlichkeiten umsehen. Dabei habe ich auch schon einige Vertreter aus behördlichen Bereichen und der Privatwirtschaft kennenlernen können.
Nach der Eröffnung von Dr. Sabine Vogt (BKA Wiesbaden) hielt Prof. Dr. Michael Backes (Universität des Saarlandes) seinen Impulsvortrag. In diesem widmete er sich den soziotechnischen Problemen der heutigen Gesellschaft. In erster Linie das Thema Privatsphäre wurde illustriert. Dabei hat er sehr schön bemerkt, dass die Risiken nur aus dem Zusammenspiel zwischen Technologie, Gesetzgebung und Benutzerverhalten angegangen werden können.
Als nächstes präsentierte Gernot Galuch (SBS Research) ein aktuelles Forschungsprojekt. In Informationssammlung aus Online- quellen / Softwareprojekt DACHS wurde als erstes das Konzept von Underground-Foren, die für den Tausch und Verkauf von illegalen Inhalten (z.B. Kreditkarteninformationen), aufgezeigt. Mit der Software DACHS wird eine automatisierte Auswertung dieser Foren möglich. Durch einen Crawler werden die Daten gesammelt und in einem weiteren Schritt ausgewertet. Die Resultate werden auf einer grafischen Oberfläche dargestellt und lassen sich dort moderieren. Das System, welches ab kann dabei in Bezug auf Mustererkennung trainiert werden.
Mit einer kurzen Verzögerung fuhr Roland Kaufmann (BLKA) in seinem Vortrag Virtuelles Mobilfunklabor – VML weiter. In diesem werden die Bemühungen eines neuen Systems aufgezeigt, um forensische Untersuchungen mit einem einheitlichen System umzusetzen. Dabei wird auf eine virtuelle Umgebung gesetzt, die mit einem multi-tier Modell realisiert wird. Hierbei kommt OpenSuse Linux mit VMware zum Einsatz. Die Erfahrungen dieses Projekts werden in einem Wiki aufbereitet, das nach Möglichkeiten ins BKA-Infoportal integriert werden soll.
Nach dem Mittagessen in der BKA-Kantine war Rainer Poisel (FH St. Pölten, Institut für IT-Sicherheitsforschung), den ich schon vorgängig kennengelernt hatte, dran. In seiner eher technischen Präsentation mit dem Titel File Carving – The Next Generation führte er in die Prinzipien moderner Dateisysteme ein, um dann die Möglichkeiten der Dateiwiederherstellung aufzuzeigen. In ihrer Forschungsarbeit haben sie ein handliches Tool entwickelt, das selbst fragmentierte Dateien wieder rekonstruieren lässt.
Der nächste Vortrag wurde vom ersten Schweizer des Tages gehalten. Dr. Endre Bangerter (Berner Fachhochschule Technik und Informatik) zeigte in Malwareanalyse / Malwareforensik die grundlegende Problematik einer aufwendigen technischen Analyse von Malware auf. Dabei konzentrierte er sich auf sich während der Laufzeit selbst modifizierende Malware, die wiederum durch das fortwährende Anfertigen von Speicherabbildern untersucht werden kann.
In meine Vortrag mit dem Titel Cybercrime versuchte ich die Sicht eines Unternehmens aus der Privatwirtschaft einzubringen. Anhand von zwei Fallbeispielen habe ich aufgezeigt, welche Formen Computerkriminalität annehmen kann, wie man gegen solche als Unternehmen vorgehen kann und welche technischen sowie juristischen Widerstände dabei auftreten können.
Der letzte Vortrag des Tages wurde von Kurt Nydegger (Generalsekretariat VBS) vorgenommen. Im Beitrag mit dem Titel Cyberdefense – Strategie der Schweiz hat er die konzeptionelle und organisatorische Vorgehensweise seines Departements aufgezeigt. Dabei wurden Mechanismen wie MELANI und KOBIK, ihre Vorgehensweise und Eingliederung besprochen. Die deutschen Kollegen haben sich da in vielen Punkten wiedergefunden.
Am Abend hat man sich vor dem BKA-Hauptgebäude getroffen und ist mit einem Bus zum Brauhaus Goldener Engel in Ingelheim gefahren. Bei einem Bier und einem umfangreichen Buffet wurde sich über moderne Kriminalistik und Sport unterhalten. Alles in allem ein sehr spannender und erfolgreicher Tag mit vielen guten Vorträgen und Gesprächen.
Tag 2 – Ermittlungsunterstützung, Simulationsmodelle
Der zweite Tag begann mit der Vorstellung des Technisches Entwicklungs- und Servicezentrum Innovative Technologien durch Peter Sehr (BKA). In einem kurzen Abriss erklärte er den Auftrag und die damit verbundenen Herausforderungen des TESIT. Dazu gehören beispielsweise eine zentrale Unterstützung bezüglich modernen Technologien, Überwachung und Forensik.
Der erste Vortrag nannte sich Entwicklungsprojekt ilias-HE / Spin-offs und wurde von Rudi Heimann (Landespolizeipräsidium Hessen) gehalten. Das darin vorgestellte Projekt gewährt eine computergestützte Einsatzführung. Die Verarbeitung der Datenflut wird – das wurde im Rahmen der Führung einer Delegationsreise nach Israel erprobt – durch die effiziente Kanalisierung beherrschbar.
Michael Ulrich (LKA Sachsen-Anhalt) und Stefan Kiltz (Universität Magdeburg) erläutert im ersten Teil von Forschungsverbund Digitale Fingerspuren – Digi-Dak die Schwierigkeit der Erhebung von Fingerabdruck-Spuren. So weisen gewisse Oberflächen krasse Einschränkungen auf, wodurch eine klassische Erhebung mittels Pulver nahezu unmöglich wird. Durch die Umsetzung von digitalen 3D-Analysen werden diese Einschränkungen ausgehebelt und zusätzliche Vorteile erschlossen (z.B. Identifikation überlagerter Spuren). Damit wird ein neues Zeitalter der Spurensicherung eingeläutet.
Nach einer kleinen Pause trat Prof. Dr. Harald Schaub (IABG) mit seinem Vortrag IuK-Technik zur Unterstützung polizeilicher Arbeit – OpenInfoSys vor das Publikum. Dabei zeigte er die Möglichkeiten von Computersimulationen zur Darlegung und Analyse von Krisensituationen (z.B. militärische Konflikte, Polizeiarbeit bei Massendemonstrationen) auf.
Der letzte Vortrag wurde von Uwe Seidel (Innenministerium Baden-Württemberg) gehalten. In ViPOL – Virtuelles Training von Polizeieinsatzkräften / iPPP ergänzt er die theoretischen Ausführungen seines Vorredners um praktische Erfahrungen. Auf der Basis des niederländischen Computerspiels Quest werden virtuelle Trainingssimulationen durchgeführt.
Am Nachmittag wurde durch Dr. Sabine Vogt (BKA) eine Diskussionsrunde zum Thema Institutionalisierte Public-Private Partnership (iPPP) geführt. Mit dabei waren Peter Dathe (BLKA), Mark A. Saxer (Furrer Hugi & Partner AG), Michael Bartsch (T-Systems International GmbH) und Kurt Nydegger (VBS).
Die Rückreise mit der Bahn war einmal mehr angenehm und ich werde mit Freude an diesen Event zurückdenken. Gerne bedanke ich mich bei den Organisatoren und den Teilnehmern für ihre Unterstützung.
► 10.11.2011 – Sicherheit von Cloud Computing
Cloud Computing ist seit dem Jahr 2007 zu einem zentralen Begriff der modernen Computertechnologie geworden. Die Greifbarkeit dessen ist aufgrund unterschiedlicher und schwammiger Definitionen nicht einfach. Verschiedene Implementierungen und Produkte führen zu einem undurchsichtigen Konstrukt, das damit ebenfalls in Bezug auf die gegebene Sicherheit schwierig handzuhaben ist.
Nach einer allgemeinen Einführung in das Thema werden in diesem Artikel unterschiedliche Implementierungen aufgezeigt. Dabei werden an konkreten Produkten die Möglichkeiten und Mechanismen dieser illustriert, um im dritten Teil die damit einhergehenden Sicherheitsmerkmale und Herausforderungen an die Informationssicherheit aufzeigen zu können.
Einführung
Der Begriff des Cloud Computing und damit auch dessen Inhalt sind umstritten. Mitunter hat das Fehlen einer akkuraten Begriffsdefinition dazu geführt, dass das Thema oftmals eher als Marketing-Instrument denn als echte technologische Möglichkeit verstanden wird. Grundsätzlich ist Cloud Computing ansich nichts Neues, verbindet es doch in erster Linie klassische Aspekte von:
- Software as a Service (SaaS)
- Computing on Demand
- Distributed Computing
Und so sind es dann auch hauptsächlich wirtschaftliche Aspekte, die den Vorteil des Cloud Computing ausmachen. Skalierbarkeit und flexible Vertriebsmodelle sollen dabei helfen, die Kosten möglichst gering zu halten und ein Höchstmass an Flexibilität gewährleisten zu können. Dabei werden gerne grundlegende Aspekte der Informationssicherheit ausser Acht gelassen oder bewusst vernachlässigt. Dies ist in erster Linie auf das fehlende Verständnis für die zugrundeliegenden Mechanismen zurückzuführen.
Begriff des Cloud Computing
Der Begriff des Cloud Computing ist nicht einheitlich definiert und so finden sich dann auch unterschiedliche Formulierungen, was konzeptionell und technologisch darunter zu verstehen ist. Vielerorts wird gerne die Begriffsdefinition von Forrester Research zitiert:
Cloud Computing steht für einen Pool aus abstrahierter, hochskalierbarer und verwalteter IT-Infrastruktur, die Kundenanwendungen vorhält und falls erforderlich nach Gebrauch abgerechnet werden kann.
Diese Formulierung zeigt das grundlegende Problem des Cloud Computing auf: Es ist nicht einfachso greifbar. Sie fasst jedoch die allgemeinen Konzepte eines solchen Systems zusammen. Im Mittelpunkt steht ein Dienst, der Funktionen zur Verfügung stellt. Diese Funktionen sind modular aufgebaut, so dass sie nur bei Bedarf durch einen Kunden genutzt werden können. Damit wird es möglich, dass nur die effektive Nutzung abgerechnet wird. Der Kunde muss damit nicht für etwas bezahlen, das er nicht benutzt. Dies ist tendenziell bei eigens angeschaffter Hardware und bereitgestellten Systemen nicht der Fall.
Die administrativen Aspekte der über Cloud Computing bezogenen Dienstleistungen verschieben sich damit im Normalfall gänzlich zum Anbieter. Der Kunde muss sich nicht um die Anschaffung neuer Hardware sowie das Aufsetzen und Betreuen der Systeme kümmern. Gerade bei kleineren Unternehmen (KMU), die keine eigenständige IT-Abteilung haben oder der Unterhalt einer solchen finanziell nicht gerechtfertigt ist, können damit direkte wirtschaftliche Vorteile für sich erschliessen.
Wir pflegen eine sehr reduzierte und einfache Definition von Cloud Computing zu vertreten. Diese lautet wie folgt:
Cloud Computing ist ein modulares System, in dem Ressourcen für den Endanwender transparent sowie dynamisch zugewiesen und verarbeitet werden.
Vertriebsmodelle
Im Rahmen des Cloud Computing werden drei verschiedene Vertriebsmodelle unterschieden, die nachfolgend im Detail vorgestellt werden sollen:
- Mit SaaS werden abstrahierte Applikationen zur Verfügung gestellt.
- PaaS geht da einen Schritt weiter und gewährt den Zugriff auf Plattformen, wodurch beispielsweise Entwicklungsumgebungen realisiert werden können.
- Das Höchstmass an Eigenverantwortung wird mit IaaS erreicht, wobei eine komplette Infrastruktur und damit die dedizierte Nutzung von Hardware-Ressourcen möglich werden.
SaaS (Software as a Service)
Das Akronym SaaS steht für Software as a Service. Es handelt sich dabei um eine Dienstleistung, die ebenfalls unter dem Namen ASP (Application Service Provider) bekannt ist. Sie stellt eine im Zeitalter des Mobile Computing immer stärker vorangetriebene Art des Software-Vertriebs dar. Eine Software soll damit zentral bereitgestellt und möglichst vielen Benutzern zugänglich gemacht werden.
Der Hauptnutzen von SaaS ist das Anbieten des Zugriffs auf eine Applikationsplattform. Der zentrale Aspekt dieses Modells ist, dass der Kunde keine Kosten für Systeme, Lizenzen und Personal (Administration) aufwenden muss. Es obliegt gänzlich der Pflicht des Anbieters, dass die Plattform fachgerecht bereitgestellt werden kann. Damit wird eine klare Trennung zwischen dem traditionellen Outsourcing vorgenommen, bei dem der Kunde für Hardware und Wartung sowie weiterführende Investitionen verantwortlich bleibt.
SaaS-Clouds sind sowohl bei Anbietern als auch Kunden besonders beliebt, da sie ein minimales Mass an Komplexität erwarten. So gibt es mittlerweile eine Vielzahl populärer Dienste, die diesem Modell zuzuordnen sind. Beispielsweise können mit Apple MobileMe, Dropbox und Evernote sehr einfach und komfortabel Daten auf unterschiedlichen Systemen genutzt und bearbeitet werden.
Zur Nutzung dieser Dienste sind in der Regel proprietäre Clients erforderlich. Diese werden jenachdem für verschiedene Plattformen zur Verfügung gestellt. Die drei zuvor genannten Beispiele bieten Clients im Web (browserbasiert), als eigenständige Applikationen und für verschiedene mobile Plattformen (iPhone, Android, BlackBerry, etc.). Beim Aufstarten eines Clients wird durch diesen automatisch und für den Benutzer weitestgehend Transparent eine Synchronisation des lokalen Datenbestands des Clients und des zentralen Datenbestands beim Cloud-Anbieter vorgenommen. Fehlende Objekte werden ausgetauscht und kürzlich bearbeitete Objekte aktualisiert. Dadurch wird auf allen Endpunkten stets der gleiche aktuelle Datenbestand bereitgestellt. Im Falle von Apple MobileMe sind dies verschiedene Daten, wie zum Beispiel Adressbuch und Kalender. Dropbox gewährt die Synchronisation beliebiger Dateien. Und Evernote fokussiert sich auf multimediale Notizen (Text, Bilder, Audio, etc.).
PaaS (Platform as a Service)
PaaS steht für Platform as a Service. Dadurch wird eine ganzheitliche Plattform bereitgestellt, auf der eigene Software ausgeführt oder im Rahmen der dargebotenen Entwicklungsumgebung betrieben werden kann. Es wird also ein zusätzliches Fundament zum zuvor genannten SaaS gewährleistet.
Zwar kann auch hier der Benutzer keinen Einfluss auf die darunterliegende Infrastruktur ausüben. Jedoch erschliessen sich ihm im Gegensatz zu SaaS zusätzliche Kontrollmöglichkeiten der eingesetzten Software. Damit wird dann vor allem bei Software-Entwicklung ein Mehr an wirtschaftlicher Effizienz erreicht, denn es kann auf den Aufbau und die Betreuung umfangreicher Entwicklungsplattformen verzichtet werden. Entwickler müssen nur noch über einen Netzwerkzugang zur Cloud verfügen, um ihrer Tätigkeit nachgehen zu können. Das ständige Warten der Entwicklungsumgebung und das eigenständige Synchronisieren der Codebasis fallen damit weg. Zudem kann auf die Anschaffung kostenintensiver Client-Hardware (z.B. zur aufwendigen Kompilierung) verzichtet und stattdessen auf kostengünstige Endpunkte (Thin-Clients) gesetzt werden.
Populäre PaaS-Lösungen werden durch Microsoft Azure und Google App Engine (GAE) bereitgestellt. Microsoft sieht für ihre Umgebung die Nutzung von .NET vor, um eigene Applikationen entwickeln und ausführen zu lassen. Damit wird es für bestehende Windows-Entwickler besonders einfach, auf diese Plattform zu wechseln. Im Gegenzug fokussiert sich Google auf hochskalierbare Webapplikationen, die hauptsächlich in Python geschrieben werden oder auf Java VM lauffähig sind.
IaaS (Infrastructure as a Service)
IaaS steht für Infrastructure as a Service. Und so wird dann auch die effektive Infrastruktur durch den Cloud-Anbieter zur Verfügung gestellt. Der Kunde kann auf grundlegende Komponenten wie Rechenzeit, Speicherplatz oder Netzwerkanbindung zurückgreifen, um beispielsweise eigene Betriebssysteme und Applikationen zu betreiben.
Damit wird ein Höchstmass an Eigenverantwortung im Cloud-Umfeld verlangt. Im Gegenzug kann der dedizierte Ressourcen-Bezug in klar definierter Weise abgerechnet werden.
Der bekannteste IaaS-Dienst ist Amazon Web Services (AWS), in dem verschiedene Betriebssysteme aufgesetzt und betrieben werden können. Die Cloud wird damit quasi als dynamische Housing-Umgebung wahrgenommen, in der die eigenen Systeme integriert werden können.
Cloud-Infrastrukturen
Unabhängig der Vertriebsmodelle gibt es verschiedene Arten von Clouds. Dabei kann zwischen drei Varianten unterschieden werden:
- Private Clouds
- Öffentliche Clouds
- Hybride Clouds
Sie definieren die Art und Weise sowie welche Benutzergruppen in welcher Form auf die Dienste zugreifen können. Hierbei wird unterschieden zwischen:
- Internen Benutzer
- Externe Benutzer
Als intern werden alle Benutzergruppen angesehen, die in einer direkten Geschäftsbeziehung mit dem Unternehmen stehen. Dazu gehören alle Mitarbeiter, aber auch vertraglich gebundene Partnerunternehmen. Als extern werden alle Benutzer angesehen, die in keiner direkten Geschäftsbeziehung stehen. Die Kombination dieser Infrastrukturvarianten und der verschiedenen Benutzergruppen wird nachfolgend im Detail erklärt.
Private Clouds
Private Clouds bieten ausschliesslich Dienste für interne Benutzer an, wobei die Prinzipien des Cloud Computings durchgängig berücksichtigt werden (z.B. Skalierbarkeit, Transparenz). Sie werden entweder unternehmensintern durch eine eigene Abteilung oder durch ein nahes Partnerunternehmen bereitgestellt. So befindet sich die genutzte Hardware physisch im Besitz des Unternehmens (Inhouse) oder Partners.
Der Vorteil privater Clouds ist, dass sich die Benutzergruppe sehr klar definieren lässt. Zudem besteht – mindestens vertraglich – eine enge Vertrauensbeziehung zwischen Cloud-Anbieter und Nutzern.
Traditionsgemäss ist diese Vertrauensbeziehung aber auch als latentes Risiko zu werten, denn so wird gerne darauf verzichtet, ausserhalb und innerhalb der Cloud zusätzliche Schutzmechanismen zu implementieren. Es wird angenommen, dass die vertrauenswürdigen Benutzer sich zu benehmen wissen und keine Gefahr darstellen. Dies ist jedoch äusserst zweifelhaft und spätestens dann widerlegt, wenn die Kompromittierung eines legitimen Kontos stattgefunden hat und dieses zur Weiterführung eines Angriffs (Hopping-Attacken) missbraucht wurde.
In privaten Clouds muss also mindestens das gleiche Sicherheitsniveau erreicht werden, wie dies auch bei einer traditionellen internen Netzwerkumgebung (DMZ) der Fall war. Eine Netwzerksegmentierung samt Firewalling ist genauso wünschenswert wie eine strenge Authentisierung und umfassendes Logging für unternehmenskritische Dienste.
Öffentliche Clouds
Öffentliche Clouds bieten in erster Linie Dienste für externe Benutzer an, wobei auch hier die Prinzipien des Cloud Computings eingehalten werden. Derlei Clouds werden ebenfalls unternehmensintern oder durch ein Partnerunternehmen betrieben, wodurch sich die Hardware in ihrem physischen Besitz befindet.
Öffentliche Clouds sollten gleich wahrgenommen werden, wie alle anderen öffentlichen Dienste auch (z.B. Webseiten, Mailserver). Entsprechend findet auch hier eine Erweiterung des Perimeters statt. Dies ist natürlich mit zusätzlichen Aufwänden verbunden, die gerade bei einem komplexen und schwierig zu definierenden Konstrukt wie einer Cloud nicht einfach ausfällt.
Das Etablieren von Zugriffskontrollen (z.B. Firewalling, Authentisierung, Access Control Lists) ist zwingend erforderlich, um öffentliche Clouds in sicherer Weise betreiben und nutzen zu können. Die erfolgreiche Umsetzung einer sicheren öffentlichen Cloud erfordert deshalb ein hohes Verständnis für die eingesetzten Technologien sowie ein gewisses Mass an Flexibilität dieser. Weitsichtige Entscheide auf strategischer Ebene sind dabei also genauso wichtig wie die Berücksichtigung der zukünftigen technischen Anforderungen.
Hybride Clouds
Hybride Clouds kombinieren die Funktionalität von privaten und öffentlichen Clouds, wodurch die Dienste sowohl für externe als auch für interne Benutzer bereitgestellt werden.
Derlei hybride Konstrukte sind sicherheitstechnisch schwierig zu rechtfertigen, ja eigentlich gar zu vermeiden. So müssen in der gleichen Infrastruktur Benutzer unterschiedlicher Einstufungen zugelassen werden. Da diese voraussichtlich nicht die gleichen Zugriffsrechte beigemessen bekommen sollen, müssen unterschiedliche Regulierungen durchgesetzt werden. Dies schafft die paradoxe Situation, dass innerhalb eines Konstrukts zur Vermengung eine Trennung eingeführt wird. Eigentlich müssten also zwei Clouds – sowohl eine private als auch eine öffentliche – betrieben und klare Übergänge zwischen diesen definiert werden. Dies ist jedoch oftmals aus kostengründen nicht gewollt und deshalb die potentiellen Sicherheitsrisiken des hybriden Ansatzes bewusst in Kauf genommen. Ein Phänomen, das leider auch Voice-over-IP (VoIP) tendenziell zu schaffen macht.
Vor der Umsetzung bzw. Nutzung einer hybriden Cloud sollte eine umfassende Risikoanalyse angestrebt werden, um die potentiellen und effektiven Risiken frühstmöglich ausmachen, kalkulieren und adressieren zu können. Gerade bei grossen und schwerfälligen Konstrukten wird es sehr wichtig, die mitgeführten Sicherheitsaspekte frühstmöglich adequat zu berücksichtigen.
Externe Verwaltung
Bei extern verwalteten Clouds handelt es sich um eine spezielle Form der vorgestellten Infrastrukturtypen. Zwar befinden sich die Clouds noch immer im Besitz eines Unternehmens, wodurch in direkter oder indirekter Weise der physische Zugriff auf die Hardware gewährleistet wird. Jedoch werden die jeweiligen Komponenten durch ein externes Unternehmen betreut. Es erfolgt also ein Outsourcing des Cloud-Dienstes.
Das Angehen einer externer Verwaltung eines Cloud-Dienstes ist mit den gleichen Anforderungen verbunden, wie ein anderweitiges Outsourcing auch. Auch hier müssen vertragliche Einigungen erzielt werden, die ebenfalls technische, sicherheitsbezogene und juristische Aspekte zu berücksichtigen in der Lage sind.
Sicherheitsaspekte
Wie gezeigt wurde, kombiniert Cloud Computing eine Vielzahl unterschiedlicher, bisweilen altbekannter Konzepte. In der Euphorie der damit erschlossenen Möglichkeiten werden gerne die sicherheitstechnischen Aspekte entsprechender Lösungen vernachlässigt. Entweder werden die Risiken unbewusst übersehen oder absichtlich übergangen.
Dies ist ein grosser Fehler, denn sowohl die einzelnen Teilkonzepte als auch die Cloud als Ganzes müssen den klassischen Anforderungen der Informationssicherheit Folge leisten. Nachfolgend sollen einzelne Aspekte, ihre Gefahren und mögliche Massnahmen betrachtet werden. Dabei wird sich teilweise am Beitrag 10 sicherheitsrelevante Gründe gegen Cloud Computing orientiert.
Kontrolle
Cloud Computing ist eine spezielle Form des Outsourcings. Bei diesem werden gewisse Ressourcen oder Prozesse an den Cloud-Partner ausgelagert. Eine in zentraler Weise sicherheitskritische Eigenschaft des Outsourcings ist der Verlust der Kontrolle über die Weiterverarbeitung (z.B. Auswertung und Verkauf der anfallenden Daten).
Man sieht sich einerseits nicht mehr in der Lage, die eigenen Erwartungen durchzusetzen. Die hohen Anforderungen einer spezifischen Branche des Kunden müssen nicht zwingend denen des Cloud-Anbieters entsprechen. Eine Verschiebung der Anforderungen kann zu einer unliebsamen Angleichung und damit zur Verringerung des erwarteten Sicherheitsstands führen. Dies passiert sehr schnell, wenn der Kunde aus einem Hochsicherheitsumfeld stammt (z.B. Finanzbranche).
Andererseits hat man auch keine Möglichkeit, eine direkte Prüfung des Einhalts von Erwartungen und Abmachungen vorzunehmen. Ein Cloud-Anbieter kann sich zwar auf das Einhalten vordefinierter Anforderungen einigen. Ob und inwiefen diesen wirklich Folge geleistet wird, ist nur mit Hilfe des Dienstleisters zu eruieren. Und gerade in kritischen Situationen kann man nicht erwarten, dass sich diese in kooperativer Weise um eine Aufklärung bemühen wird.
Sollen beispielsweise in regelmässigen Abständen Sicherheitsüberprüfungen der genutzten Cloud-Infrastruktur umgesetzt werden, kann sich das als enorm aufwendig herausstellen. Auf technischer Ebene können die Komplexität der Infrastruktur und der schwierig nachvollziehbare Datenfluss dafür verantwortlich sein. Bei der Analyse von Prozessen, bei denen beispielsweise Interviews mit den zuständigen Personen geführt werden sollen, kann die fehlende Unterstützung ebenfalls zu einer schwierig überwindbaren Hürde führen.
Transparenz
Ein grundlegendes Risiko des Outsourcings ist, dass einem Partner Vertrauen entgegengebracht werden muss. Diesem wird Kompetenz beigemessen und zwecks Interaktionsmöglichkeiten Schnittstellen definiert. Da die Einsicht der Objekte bzw. Prozesse nur noch bis zu diesen Schnittstellen funktioniert, verliert die Zusammenarbeit bzw. die Weiterverarbeitung an Transparenz (z.B. Kommunikation von Incidents). Die Cloud muss ebenfalls als spezielle Form des Outsourcings von Ressourcen bzw. weiter zu verarbeitenden Daten verstanden werden.
Der Kunde sollte darum bemüht sein, ein Höchstmass an Transparenz im Zusammenhang mit der bezogenen Dienstleistung erreichen zu können. Einerseits sollten klare Anforderungen an den Cloud-Partner gestellt werden, in welcher Form und wie Einsicht in die Verarbeitung gehalten werden kann. Dazu gehören ebenfalls Einsichten in die Bereiche:
- Weiterverarbeitung von Daten
- Interne Verarbeitung von Objekten (z.B. kundenbezogene Informationen)
- Zugriffe auf Protokollierung und Logging
- Zugriffe auf Backup und Restore
- Revisionstechnische Zugriffsmöglichkeiten (z.B. zwecks Auditing)
Andererseits sollten die vereinbarten Schnittstellen klar geregelt sein, um die Übergänge wohldefiniert etablieren und sich derer sowie ihrer Einschränkungen bewusst zu sein. Nur so kann eine durchdachte Risikokalkulation umgesetzt werden.
Unabhängigkeit
Durch das Auslagern von Aufgaben und Prozessen büsst man stets ein gewisses Mass an Unabhängigkeit ein. Man ist nicht mehr alleiniger Herr über den Sachverhalt und stattdessen auf die Zuwendigkeit des Partners angewiesen. Situationen, die ein hohes Mass an Flexibilität und Dynamik erwarten, werden damit schwieriger zu bewältigen. Strategische Entscheidungen des Managements, die auf einen langfristigen Horizont ausgerichtet sind, lassen sich voraussichtlich planen. Der Umgang mit hektischen Situationen lässt sich hingegen nicht voraussagen. Zu diesen gehören beispielsweise:
- Security Incidents (z.B. elektronischer Einbruch, DDoS-Attacken)
- Ausfall von systemkritischen Komponenten (z.B. Hardware-Defekt eines Routers)
Durch das klare Definieren der Schnittstellen wird es möglich, diese möglichst effizient auszuwerten. Gerade für Szenarien, die ein hohes Mass an Flexibilität erfordern, sollten klare Abmachungen bezüglich Kompetenzbereichen samt Service Level Agreement (SLA) getroffen werden.
Diese Szenarien sollten zudem regelmässig durchgespielt und den aktuellen Geschehnissen (laufende wirtschaftliche und technische Entwicklungen) angepasst werden. Durch eine solche regelmässige Prüfung wird verhindert, dass die in den jeweiligen Situationen erforderliche Qualität nicht gewährleistet werden kann.
Trennung von Objekten
Innerhalb der Cloud können verschiedene Objekte miteinander vermengt sein. Dabei kann es sich um Daten, Systeme oder gar Kunden handeln. Eine klare Trennung von Objekten ist nicht per se ohne zusätzliche Aufwände durchgesetzt. Dies führt dazu, dass unbeabsichtigt sicherheitstechnisch unterschiedlich klassifizierte Objekte miteinander vermengt werden können.
Sind zum Beispiel Computersysteme mit unterschiedlicher Exponiertheit und Kritikalität in der gleichen Cloud gehostet und es findet die Kompromittierung eines Hosts (Sicherheitsstufe 2) statt, kann dies direkten Einfluss auf die Sicherheit des anderen Hosts (Sicherheitsstrufe 1) haben. Diese Vermengung unterschiedlicher Einstufungen resultiert in einem Herabstufen der höher gewichteten Objekte. Damit kann im schlimmsten Fall für alle Objekte lediglich das Sicherheitsniveau des am schlechtesten geschützten Objekts garantiert werden.
Um diesen Effekt der Herabstufung durch das schwächste Glied zu verhindern, sollten eine klare Formulierung der Einstufungen sowie eine strikte Umsetzung dieser stattfinden. Objekte unterschiedlicher Einstufungen sollten nicht in den gleichen Objektgruppen zusammengefasst werden. Hierbei gilt es dem gleichen Credo der hybriden Clouds zu folgen, die ihrerseits auch das Risiko einer unerwünschten Vermengung – in jenem Fall jedoch bezüglich privater und öffentlicher Benutzergruppen – mit sich führt. Als Grundsatz gilt, dass Objekte unterschiedlicher Einstufungen in Bezug auf Kritikalität und Exponiertheit nicht in ein und der Selben Objektgruppe zusammengefasst werden sollten.
Datensicherung und Datenwiederherstellung
Das Umsetzen einer Datensicherung wird beim Cloud Computing oftmals direkt durch den Anbieter selbst angeboten. Dieser ist sowohl für das Erstellen der Datensicherung (Backup) als auch für die Wiederherstellung bei einem Datenverlust (Restore) verantwortlich. In der Vergangenheit sind jedoch immerwieder Ausfälle von Cloud-Diensten bekannt geworden, bei denen sich ein Anbieter nicht oder nur ungenügend um die Datensicherung bemüht hat. Zudem kann es durch einen Kunden wünschenswert sein, dass dieser zusätzlich eine eigene Datensicherung anfertigen kann.
Die Sicherung der Daten in einer Cloud kann sich jedoch als relativ schwierig herausstellen. Dies kann schon nur alleine damit beginnen, dass oftmals nicht ganz klar ist, wo in einer Cloud die Daten genau abgelegt sind. Zusätzlich bieten viele Cloud-Dienste gar keine klaren Schnittstellen, um ein externes oder
gar autonomes Backup/Restore durchzuführen.
Verschiedene Anbieter auf dem Markt haben diese Schwierigkeiten erkannt und bieten zusätzliche Sicherungsdienste für verschiedene Cloud-Produkte und -Technologien an. Dadurch ist natürlich ein Mehr an Ausgaben zur Gewährleistung der zusätzlichen Bedürfnisse erforderlich, deren Ausbleiben in erster Linie die Umsiedlung der Daten in die Cloud gerechtfertigt hatten. Spätestens hier wird also der wirtschaftliche Vorteil der Kerndienste durch zusätzliche Bedürgnisse negiert. Zudem wird mit dem Einspannen einer neuen Lösung wiederum die unliebsame Komplexität des gesamten Konstrukts erhöht.
Es ist deshalb wichtig sich darüber Gedanken zu machen, ob und inwiefern eine eigene Datensicherungs-Strategie innerhalb einer Cloud verfolgt werden will und technologisch auch verfolgt werden kann. Mehrkosten, die bei einer solchen Lösung anfallen können, müssen in die initiale Kalkulation miteinbezogen werden, um sich vor unliebsamen zukünftigen Betriebskosten schützen zu können. Viele Lösungen, die in Bezug auf die Kostenersparnis sehr attraktiv angeboten werden, beinhalten nämlich versteckte Mehrkosten, die sich erst bei einer längeren Nutzung des Dienstes als solche zu erkennen geben.
Migrationsmöglichkeiten
In eine ähnliche Kategorie wie das Herstellen und Wiedereinspielen von Datensicherungen ist die Möglichkeit einer Migration. Bei einer solchen wird sich darum bemüht, von einem Cloud-Anbieter oder –System zu einem anderen zu wechseln bzw. eine eigene Lösung wiederzubetreiben (Insourcing). Zu diesem Zweck müssen die in der alten Cloud abgelegten Objekte ähnlich wie bei einer Datensicherung extrahiert werden, um sie dann in der neuen Cloud wieder einzuspielen. Auch hier besteht nun das Problem, dass fehlende Schnittstellen diesen Prozess massgeblich erschweren können.
Ein Cloud-Anbieter ist im Grunde gar nicht darum bemüht, für diese Zwecke effiziente Mechanismen, klare Schnittstellen und kompatible Technologien anzubieten. Denn durch das Ausbleiben dieser kann er eine Kundenbindung auf technischer Ebene erzwingen. Die Trägheit des Kunden wird verhindern, dass dieser beim Auftauchen des ersten Bedürfnisses die bestehende Geschäftsbeziehung löst und zu einem anderen Anbieter wechselt. Stattdessen wird der damit einhergehende Aufwand immensen Ausmasses gescheut werden. Dadurch erhält der Anbieter ein Mehr an Handlungsspielraum, um im Rahmen der Kundenbeziehung die zu seinen Gunsten arbeitenden Modalitäten zu diktieren. Dies kann sich also im schlimmsten Fall langfristig auf die Qualität eines Angebots (z.B. Reaktionszeiten, Kooperationsbereitschaft) niederschlagen.
Auch hier gilt es deshalb frühzeitig abzuklären, ob und inwiefern Migrationsmöglichkeiten bestehen. Nur dadurch kann ein Mindestmass an Unabhängigkeit gewährleistet werden, das dringend erforderlich ist, um den eigenen Handlungsspielraum nicht vollends zu beschneiden.
Juristische Anforderungen an den Datenschutz
Ein Hauptmerkmal des Cloud Computings ist, dass durch dieses eine transparente Dezentralisierung der Objekte (in den meisten Fällen hauptsächlich Daten) stattfinden kann. Für den Benutzer wird es irrelevant zu wissen, wo sich die von ihm bearbeiteten Daten gerade befinden. Dieses fehlende Wissen um die grundlegenden Gegebenheiten führt jedoch das Risiko der Verletzung juristischer Anforderungen mit sich. In verschiedenen Belangen ist die Verarbeitung von Daten gesetzlichen Bestimmungen unterworfen. So betrifft zum Beispiel das Thema Datenschutz sämtliche Unternehmen. Manche von ihnen sind branchenspezifischen Anforderungen unterworfen (z.B. im Finanzsektor).
Eine geografisch verschiedene Länder umfassende Cloud führt zum Beispiel das Risiko ein, dass hier plötzlich unterschiedliche juristische Rahmenbedingunen für die gleichen Datensätze gelten können. Die Datenschutzbestimmungen sind voraussichtlich nicht gleich, jenachdem in welchem Land sich die Daten gerade befinden. Alleine Deutschland und die Schweiz pflegen gänzlich unterschiedliche Anforderungen an den Schutz persönlicher Daten zu stellen.
Oder gewisse Datenschutzbestimmungen verbieten gar, dass Daten ein bestimmtes Land verlassen dürfen. Dies ist zum Beispiel oftmals bei kundenbezogenen Daten – vor allem im Finanzumfeld – der Fall. So ist es nicht ohne weiteres erlaubt, dass diese im Ausland gelagert oder über einen externen Server weitergereicht werden.
Es gilt also vor der Nutzung eines geografisch verteilten Dienstes zu klären, ob und inwiefern dessen Nutzung mit den auferlegten juristischen Bestimmungen vereinbar ist. Die Anbieter weltweit umspannender Clouds haben diese Problematik erkannt und bieten bisweilen technologische Möglichkeiten an, die geografische Verteilung der Daten zu limitieren. Amazon hat zu diesem Zweck die Availability Zones eingeführt.
Besteht keine Möglichkeit, die geografische Ausbreitung sensitiver Daten durch die Konfiguration der Cloud-Struktur einzuschränken, müssen prozesstechnische oder zusätzliche technische Mechanismen genutzt werden, um keine Verletzung der Sorgfaltspflicht anzugehen. Dies kann beispielsweise das Anonymisieren oder Verschlüsseln von Daten bei der Übermittlung in andere Länder (z.B. bei Test-Daten) der Fall sein.
Juristische Eigenverantwortung
Die juristischen Schwierigkeiten sind nicht nur in Bezug auf die Anforderungen an den Datenschutz beschränkt. Oftmals wird davon ausgegangen, dass mit einer Auslagerung in eine Cloud die juristische Eigenverantwortung vollumfänglich an den Anbieter übertragen wird. Von nun an sei dieser dazu verpflichtet, wie nationalen und branchenspezifischen Anforderungen zu erfüllen.
Dies ist jedoch Wunschdenken, denn die juristische Eigenverantwortung lässt sich oftmals nicht einfach so auf eine andere (juristische) Person übertragen. Nur weil ein Kunde (z.B. Finanzunternehmen) durch eine vertragliche Regelung ein Outsourcing zentraler Dienste an einen Cloud-Partner vornimmt, ist von nun an der Kunde nicht mehr nicht für die Sorgfaltspflicht der Datenverarbeitung verantwortlich bzw. mitverantwortlich. Jenachdem ist es dem Kunden gar nicht erlaubt, die Herrschaft über die Daten ohne weiteres weiterzugeben. Und falls eine Weitergabe dennoch möglich ist, dann muss sich jenachdem der Kunde um die Einhaltung und Prüfung der auferlegten Regeln bemühen.
Doch gerade das Durchsetzen und Kontrollieren von Anforderungen ist aufgrund der fehlenden Transparenz und Schnittstellen vieler Cloud-Anbieter nicht oder nur mit erheblichem Aufwand durchführbar. Unter dem Strich ist es in Bezug auf diese weiterführenden Probleme oftmals unbestritten, dass eine eigenständige Bearbeitung der Daten einfacher und kostengünstiger umsetzbar bliebe.
Aufbau und Wahrung von Knowhow
In den allermeisten Fällen wird die Auslagerung eines Dienstes vorgenommen, um dadurch Kosten zu sparen. So kann auf die Anschaffung teurer Hardware und den Einsatz geschulten Personals verzichtet werden. Mit einer erfolgreichen Auslagerung geht also auch oftmals ein Stellenabbau in den betroffenen Bereichen einher. Im Fall des Cloud Computing wird somit jeweils in Bereichen der IT-Administration (Administratoren, Entwickler, Support) abgebaut.
Mit dem Abbau von Personal geht aber auch immer Knowhow verloren. Sind keine Administratoren oder Entwickler mehr zugegen, wird es für ein Unternehmen immer schwieriger, das Verständnis für die genutzten Technologien zu wahren. Die Zusammenarbeit mit einem Cloud-Partner kann dadurch massgeblich erschwert werden, da dieser mit seiner Übermacht an technischem Verständnis die Ausrichtung eines Gesprächs diktieren kann. Im schlimmsten Fall kann er durch falsche oder halbwahre Aussagen die Entscheidungen des Kunden zu seinen Gunsten beeinträchtigen. Der Kunde ist auf sich alleine gestellt und kann damit nicht mehr intelligent agieren oder reagieren.
Im besten Fall sollte also trotz Nutzung von Cloud-Diensten auf den rigorosen Abbau von fachtechnischem Personal verzichtet werden. Es sollte von jedem Fachbereich mindestens eine Person bestehen bleiben, die sich in technische Gespräche einschalten und zu Gunsten des Kunden argumentieren kann. Diese Person sollte als stabstechnische Kompetenzstelle agieren und andere Bereiche durch ihr Wissen und Verständnis profitieren können.
Ist das Aufrechterhalten eines solchen Knowhow-Pools nicht möglich, muss sich auf externe Berater verlassen werden. Diese sollten bei strategisch und technisch schwierigen Situationen herbeigezogen werden, um durch ihre Empfehlungen den Handlungsspielraum des Kunden aufrechterhalten oder erweitern zu können. Nur so lässt sich frühzeitig eine Einengung durch den Cloud-Partner, zum Beispiel durch das Einwilligen von unvorteilhaften Vereinbarungen, verhindert.
Dezentralisierung
In vielen Fällen wird das Cloud Computing als Dezentralisierung verstanden. Damit wird die Möglichkeit erschlossen, dass die Datenbestände in unterschiedlichen Bereichen und verschiedenen geografischen Lokalitäten aufbewahrt bleiben. Dies wird als positiver Effekt wahrgenommen, da dadurch theoretisch eine erhöhte Ausfallsicherheit erreicht werden kann.
Dennoch entspricht Cloud Computing nicht per se einer Dezentralisierung. Genau genommen kann durch die Auslagerung in eine Cloud gar das Gegenteil stattfinden. Werden sämtliche Daten eines Unternehmens in die Cloud übertragen, stellt sie selbst einen Single Point of Failure dar. Ein Ausfall der Cloud führt nämlich ebenfalls zum kompletten Ausfall des Dienstes bzw. der Verfügbarkeit der Daten. Eine Cloud muss explizit so konstruiert sein, dass sie selbst in sich eine Dezentralisierung darbietet, um dennoch ein Mindestmass an Ausfallsicherheit (Fail-Over) gewährleisten zu können. Theoretisch kann ein als Cloud bezeichnetes Konstrukt lediglich aus einem einzigen Server (und dazugehörige transparente Schnittstellen) bestehen.
Für Angreifer wird eine Cloud als eigenständige Entität also umso interessanter. Denn weiss ein Angreifer darum, dass ein Kunde die Dienste eines spezifischen Anbieters nutzt, kann er sich auf den Angriff auf diese Cloud konzentrieren. Cloud-Anbieter tragen aus verkaufstechnischen Gründen gerne technische Details zu ihren Lösungen nach Aussen, was einem Angreifer entscheidende Vorteile verschaffen kann. Jenachdem wie die Vermengung von Kunden und die internen Zugriffsbeschränkungen des Cloud-Anbieters umgesetzt sind, kann ein Angriff dann gar einfacher ausfallen, als dies bei einer eigenständigen IT-Umgebung der Fall gewesen wäre.
Es ist deshalb wichtig abzuklären, wie die Struktur und Topologie einer Cloud genau aussieht. Dabei darf sich nicht einfach auf die Definition der undefinierten Wolke verlassen und dies als Vorteil für den Kunden – da einfacher zu verstehen – verstanden werden. Das Verständnis muss über diese PR-technische Simplifizierung hinausgehen.
Die Ausfallsicherheit innerhalb der Cloud muss sodann genauso gewährleistet sein, so wie dies bei einer dedizierten IT-Infrastruktur der Fall gewesen ist. Redundant betriebene Komponenten sind dabei genauso wichtig wie schnelle Reaktionszeiten bei Betriebsunterbrüchen.
Und auch hier ist es deshalb wichtig, dass die Vermengung von Objekten nicht rigoros zugelassen wird. Stattdessen sollte auf eine klare Trennung sowie strikte Zugriffslimitierungen gesetzt werden. Dadurch können Birthday- und Hopping-Attacken verhindert werden. Die Kompromittierung der Cloud eines Kunden hat damit nicht zwangsläufig die Kompromittierung der Cloud eines anderen Kunden zur Folge.
Zusammenfassung
Cloud Computing ist ein komplexes Thema, das sich auf verschiedene Technologien abstützt. Dabei werden bisweilen teilweise altbekannte Mechanismen miteinander kombiniert, um einen modularen und transparenten Dienst gewährleisten zu können. Auf wirtschaftlicher Ebene wird ein flexibles Kostenmodell als entscheidender Vorteil verstanden.
Dabei gibt es verschiedene Vertriebsmodelle. Beim SaaS (Software as a Service) wird eine Applikation zur Verfügung gestellt, die sich oftmals durch verschiedene Clients auf unterschiedlichen Systemen nutzen lässt. Zum Beispiel können so Datenbestände zwischen verschiedenen Plattformen synchronisiert werden. Einen Schritt weiter geht PaaS (Platform as a Service), bei der ein ganzheitliches Framework zur eigenen Entwicklung und Nutzung von Software dargeboten wird. Dieser Ansatz ist vor allem bei Entwicklungsumgebungen interessant. Umfassende Kontrolle wird hingegen erst bei IaaS (Infrastructure as a Service) erlangt, bei der ein Kunde direkten Zugriff auf Hardware-Komponenten hat und somit im Sinne eines Housing seine eigene Server-Farm betreiben kann.
Dabei unterscheidet man zwischen verschiedenen Infrastrukturformen. Eine private Cloud bietet Dienste für interne Benutzer an. Hierbei handelt es sich in erster Linie um die Mitarbeiter eines Unternehmens, denen damit ihre Arbeitswerkzeuge bereitgestellt werden. Im Gegensatz können bei einer öffentlichen Cloud auch externe Benutzer auf die Dienste zugreifen. Dies ist vor allem dann wünschenswert, wenn damit ein spezifisches Produkt verkauft und verteilt werden will. Die Kombination privater und öffentlicher Clouds wird als hybride Clouds bezeichnet.
Grundsätzlich gibt es verschiedene Sicherheitsaspekte, die bei der Umsetzung und Nutzung von Cloud Computing berücksichtigt werden müssen. Greift man auf die Dienste eines externen Cloud-Partners zurück, entspricht dies einer speziellen Form des Outsourcings. Mit diesem gehen verschiedene altbekannte Risiken – wie zum Beispiel der Verlust von Transparenz und Kontrolle – einher. Es gibt aber auch technische Risiken, wie die Schwierigkeit der Umsetzung einer eigenständigen Datenwiederherstellung oder die Durchführung einer Migration. Hinzu kommen juristische Bedenken, die gerade bei globalem Cloud Computing und in bestimmten Branchen nicht zu vernachlässigen sind. Diese Risiken müssen frühzeitig berücksichtigt und entsprechende Massnahmen ergrifen werden, um sie berechenbar und eliminierbar zu machen. Die sichere Umsetzung von Cloud Computing vermag möglich zu sein, auch wenn damit ein hohes Mass an Aufwand eingehen wird.
► 03.11.2011 – Forensik von iMessage auf iOS5
Am 12. Oktober 2011 war es so weit: Apple hat das Betriebssysten iOS5 für ihre mobilen Geräte herausgegeben. Wie es sich für ein Major-Update gehört wurde die neue Version mit eine Vielzahl an Erweiterungen bestückt. Diese sind mitunter ebenfalls aus Sicht einer forensischen Untersuchung von Interesse. In diesem Beitrag soll die Einbindung und Auswertung von iMessage diskutiert werden.
Bei iMessage handelt es sich um eine zentrale Erweiterung der Kommunikationsmöglichkeit. Kurznachrichten werden nach Möglichkeiten über den Datenkanal übertragen. Da ein solcher in der Regel weniger kostet, ist der Versand bedeutend kostengünstiger als bei einer klassischen SMS. Grosser Vorteil gegenüber bekannten Lösungen wie WhatsApp ist, dass iMessage direkt in das bestehende SMS-Nachrichtensystem integriert wurde und sich damit für den Benutzer komplett transparent verhält. Einzige Voraussetzung zur Nutzung von iMessage ist, dass sowohl Sender als auch Empfänger ein iOS-Gerät mit dieser Funktion einsetzen. Verschiedene Stellen prognostizieren der klassischen SMS damit einen ersten Todesstoss.
Die Verschmelzung von SMS und iMessage ist nicht nur in der grafischen Oberfläche, mit der sich der Benutzer auseinandersetzt, zu sehen. Auch die interne Verarbeitung wird an zentraler Stelle vorgenommen. Dies wird klar, wenn eine forensische Untersuchung eines Backups – die Grundlagen einer solchen sind im Beitrag iPhone Forensik illustriert worden – vornimmt. Von Interesse ist dabei die Datei 3d0d7e5fb2ce288813306e4d4636395e047a3d28, welche noch immer die verschickten und empfangenen Kurznachrichten bereithält. Das Kernstück dieser ist die Tabelle messages, deren Struktur für die beiden iOS-Versionen 4 und 5 nachfolgend dargestellt wird.
| ID | Name | Typ | IOS4 | IOS5 | Beschreibung |
|---|---|---|---|---|---|
| 0 | ROWID | INT | ID (innerhalb SQLite) | ||
| 1 | address | TEXT | Zieladresse/Absender (SMS) | ||
| 2 | date | INT | Datum (Unix-Timestamp) | ||
| 3 | text | TEXT | Nachrichtentext | ||
| 4 | flags | INT | Typ (0=iMessage, 2=SMS in, 3=SMS out) | ||
| 5 | replace | INT | Alte Nachricht ersetzen (0=nein) | ||
| 6 | svc_center | TEXT | unbekannt | ||
| 7 | group_id | INT | Gruppendefinition (ID) | ||
| 8 | association_id | INT | Datumszuordnung | ||
| 9 | height | INT | unbekannt | ||
| 10 | UIFlags | INT | Darstellungsmodus (5=Link, 6=Symbole) | ||
| 11 | version | INT | Version (immer 0) | ||
| 12 | subject | TEXT | Betreff (optional) | ||
| 13 | country | TEXT | Landeskürzel (ch=Schweiz) | ||
| 14 | headers | BLOB | unbekannt | ||
| 15 | recipients | BLOB | Encod. Nachrichtentext (mehrere Empfänger) | ||
| 16 | read | INT | Lesestatus Lokal (0=nein, 1=ja) | ||
| 17 | madrid_attributedBody | BLOB | unbekannt (codierter Inhalt) | ||
| 18 | madrid_handle | TEXT | Absender/Empfänger (iMessage) | ||
| 19 | madrid_version | INT | Version (Standard=0) | ||
| 20 | madrid_guid | TEXT | Weltweit eindeutige Nachrichtenidentifikation | ||
| 21 | madrid_type | INT | unbekannt (Standard=0) | ||
| 22 | madrid_roomname | TEXT | unbekannt | ||
| 23 | madrid_service | TEXT | unbekannt (Standard=Madrid) | ||
| 24 | madrid_account | TEXT | Assoziiertes Konto (e:<mail>, p:<privat>) | ||
| 25 | madrid_flags | INT | Richtung (36869=out, 12289=in) | ||
| 26 | madrid_attachmentInfo | BLOB | unbekannt | ||
| 27 | madrid_url | TEXT | unbekannt | ||
| 28 | madrid_error | INT | Fehlercode (0=ok) | ||
| 29 | is_madrid | INT | iMessage-Identifikation (SMS=0, iMessage=1) | ||
| 30 | madrid_date_read | INT | Lesedatum Lokal (Unix-Timestamp) | ||
| 31 | madrid_date_delivered | INT | Zustelldatum (Unix-Timestamp) | ||
| 32 | madrid_account_guid | TEXT | Weltweit eindeutige Kontoidentifikation |
Hierbei ist klar zu sehen, dass die Felder 17-32 bei iOS4 noch nicht vorhanden waren und erst mit iOS5 angefügt wurden. Dabei handelt es sich um die sogenannten Madrid-Felder. Verschiedene Stellen vermuten, dass Madrid der interne Codename von iMessage während der Entwicklung war. Zu einem gewissen Grad erstaunt es, dass schlussendlich nicht der offizielle Name der Funktion in den jeweiligen Komponenten seine Verwendung fand.
Apple hat versucht ein hohes Mass an Rückwärtskompatibilität gewährleisten zu können. Die altbekannten Felder wurden weitestgehend belassen. Sie wurden höchstens um zusätzliche Werte erweitert (z.B. flags kennt nun 0 für iMessages). Dabei sind ihnen aber anscheinend einige konzeptionelle Ungereimtheiten unterlaufen. Zum Beispiel speichern SMS (address) und iMessage (madrid_account) den Empfänger/Absender in unterschiedlichen Feldern. Da mit flags eine klare Trennung zwischen den Nachrichtentypen vorgenommen werden kann, wäre dies aber nicht nötig gewesen.
Danksagung
Wir möchten uns an dieser Stelle bei @pytey des iPhone DevTeam für die freundliche Unterstützung bedanken. Er hat uns dabei geholfen, die interne Funktionsweise von iOS5 besser zu verstehen.
► 29.10.2011 – Hashdays 2011 Diary, Tag 2: Mein Vortrag und inspirierende Talks
- Tag 0: Anreise und Speakers-Dinner
- Tag 1: Erste Vorträge und Treffen
- Tag 2: Mein Vortrag und inspirierende Talks
Ich wusste sehr gut, was ich da tat, als ich am gestrigen Abend frühzeitig von der Offsite Hashdays Party zurück ins Hotel ging. Schliesslich sollte ich ab 09:00 Uhr des heutigen Tages meinen Vortrag zum Thema Code-Diebstahl halten. Umso besser erschien es mir, dass Luca und ich unseren Vortrag sehr stark mittels Storytelling strukturiert und damit die ermüdeten Zuschauer nicht mit sinnlosen technischen Details bombardiert haben.
Nach einigen interessanten Diskussionen habe ich mir dann den technisch interessanten und didaktisch gut aufbereiteten Vortrag von Tobias Ospelt angeschaut. In Reversing Android Apps – Hacking and cracking Android apps is easy diskutierte er die Möglichkeiten und Auswirkungen der Analyse von Android-Smartphones und ihren Applikationen.
Nach dem Mittagessen, einmal mehr habe ich fast nur Suppe gegessen, schaute ich mir Chris John Riley mit SAP (in)security: Scrubbing SAP clean with SOAP an. Sehr unterhaltsam und bisweilen zynisch wurde die erweiterte Angriffsfläche der kostenschweren SAP-Lösung aufgezeigt. Es lässt sich nur schwerlich abstreiten, dass damit in den meisten Firmen ein massives Risiko etabliert wurde.
Danach gab es zwei inspirierende Vorträge. Einerseits David Kennedy mit Making Sense of (in)Security. Der CSO eines Fortune 1000 Unternehmens kritisiert die Unstrukturiertheit moderner Unternehmen, ja gar das irrationale Verhalten vieler CSO/CISO. Seine Empfehlung: Die heutigen Hacker müssen die CSO/CISO von morgen werden. In der Tat, tut ein solcher Hintergrund dieser zentralen Position sicher gut.
Der zweite inspirierende Talk hielt Chris Nickerson. In Compliance: An Assault on Reason kritisiert er unverhohlen die Unsinnigkeit von Compliance und damit falsch investierter Sicherheit. Man soll sich lieber wieder auf traditionelle Aspekte der Informationssicherheit besinnen und mit gesundem Menschenverstand agieren.
Die Closing Ceremony wurde dann auch mit Spannung erwartet. Schliesslich musste sie letztes Jahr aufgrund Übermüdung vereinzelter Akteure improvisiert werden. Dieses Jahr war die Ankündigung umso grösser und es wurden Preise der Gewinnspiele verteilt sowie sich auf nächstes Jahr gefreut.
Entsprechend hoffe ich, dass ich auch 2012 wieder hier in Luzern sein werden. Nun gehts aber ab an die Dirty Security Afterpart. Für die Hashdays-Teilnehmer hat das Wochenend nämlich eigentlich erst angefangen …
► 28.10.2011 – Hashdays 2011 Diary, Tag 1: Erste Vorträge und Treffen
- Tag 0: Anreise und Speakers-Dinner
- Tag 1: Erste Vorträge und Treffen
- Tag 2: Mein Vortrag und inspirierende Talks
Das Speaker-Dinner des vergangenen Abend ging feuchtfröhlich zu Ende und wie zu erwarten war, sollte das Aufstehen am ersten Konferenztag nicht wirklich einfach werden. Dennoch war ich über eine halbe Stunde zu früh, konnte mich aber deshalb umso mehr mit dem vielfältigen Badge – es wurden zusätzliche Erweiterungen zu letztem Jahr angestrebt – auseinandersetzen. Und schon bald fand die Opening Ceremony statt. Dieses Jahr ist die Farbgebung der Hashdays-Shirts wie folgt gegeben: Gelb steht dem OK zu, blau wird von den Helfern verwendet und schwarz benutzen die Besucher. Bei den Badges werden auch dieses Jahr rote Badges für die Besucher verwendet und neu kommt braun für die Speaker zum Einsatz. Und auch dieses Jahr steht ein Konferenz-GSM zur Verfügung.
Danach folgte sogleich die inspirierende Keynote von Mikko Hypponen, seines Zeichens RFO bei F-Secure und für seine langjährige und qualitativ hochwertige Arbeit bekannt. Er behandelte die aus seiner Sicht drei zentralen Angreifertypen (Cybercriminals, Hacktivits und Governments), ihre Motive und Herangehensweisen. Nicht erst seit diesem Vortrag scheint es unbestritten, dass Informationssicherheit ein zentraler Aspekt der heutigen Gesellschaft ist.
Generell war es an diesem Tag alles andere als einfach, sich jeweils für einen der beiden zeitgleich abgehaltenen Talks zu entscheiden. Ich habe mich am Morgen als erstes für Encryption and Data Ownership in Cloud Computing von Timothy ‘Thor’ Mullen entschieden. Er stellte sein Produkt zur kryptografischen Sicherung von Daten in der Cloud vor.
Danach war IPv6, the new network hackers playground von Christoph Weber und Sina Herbert von Interesse. Hierbei wurden allgemeine Angriffstechniken, die sich auf die neue Protokollgeneration übertragen lassen oder durch sie werden, besprochen. Die Möglichkeiten der Identifikation und Auswertung von potentiellen Zielsystemen steigt mit den neuen Möglichkeiten signifikant an. Mitunter ist deshalb anzunehmen, dass mit IPv6 unter dem Strich das allgemeine Niveau von Netzwerksicherheit nicht wirklich angehoben werden kann.
Nach einem kurzen Mittagessen, ich hatte nicht wirklich Hunger, interessierte mich besonders Pushing in, and pulling out slowly without anyone paying attention von Iftach Ian Amit. Im Zentrum seiner cleveren Besprechung stand die Möglichkeit, nach erfolgreicher Kompromittierung eine Exfiltrierung der Daten stattfinden zu lassen. Dabei sollten alternative Kanäle wie Altpapier und Voice-over-IP zum Tragen kommen.
Für unsere berufliche Tätigkeit von zentralem Interesse war an diesem Tag ebenfalls der Vortrag Fears, uncertainty and banking credentials von Adrian Wiesmann. Der erste Tag wurde dann von Chris Gates mit Pentesting from LOW to POWNED und Felix ‘FX’ Lindner mit Targeted Industrial System Attacks – Lessons from Stuxnet abgeschlossen. Mit diesem Lineup ist es mir eine besondere Ehre, den zweiten Vortrag mit unserem Vortrag zu eröffnen.
Schon bald gehts nun zur Offsite Hashdays Party, an der hoffentlich die spannenden Gespräche weitergehen werden…
► 27.10.2011 – Hashdays 2011 Diary, Tag 0: Anreise und Speakers-Dinner
- Tag 0: Anreise und Speakers-Dinner
- Tag 1: Erste Vorträge und Treffen
- Tag 2: Mein Vortrag und inspirierende Talks
Dieses Jahr findet zum zweiten Mal findet die Hashdays Security & Risk Conference statt. Und zum zweiten Mal habe ich die Gelegenheit, einen Vortrag zu halten, alte Bekannte zu treffen und neue Leute kennenzulernen. Mein Vortrag mit dem Titel Code Plagiarism – Technical Detection and Legal Prosecution wird am kommenden Samstag, ab 09:00 Uhr stattfinden.
Nach einem sehr kurzen Arbeitstag bin ich mit dem Zug angereist. Die Abfahrt von Zürich HB hat sich rund 20 Minuten verzögert, da die SBB einen Schaden an der Lokomotive beheben musste. Eine ungewöhnliche Situation, die mein Sitznachbar – ein Geschäftsmann aus Deutschland – ein bisschen nervös gemacht hat. Da ich jedoch wie immer genug Zeit für die Reise eingeplant hatte, hat mich das nicht weiter gestört. Ganz im Gegenteil habe ich die Ruhe genossen und die aktuellen Nachrichten auf meinem iPad via Flipboard gelesen.
Der Check-In im Radisson Blu Hotel in Luzern verlief problemlos, obwohl ich – wie üblich – meine Kreditkarte nicht herausrücken wollte. Meine Sachen schnell ins Zimmer gebracht und frisch gemacht, habe ich die Jungs im NOC besucht und mich nach dem Rechten erkundigt. Sehr zuversichtlich sei man, dass die Konferenz zu einem vollen Erfolg werden wird. Die Workshops haben jedenfalls sehr guten Anklang gefunden.
Kurz nach 19:00 Uhr gings zum Speakers Dinner, wo sich sämtliche Vortragenden und das OK der Veranstaltung zum Essen getroffen haben. Wie letztes Jahr gabs in der wunderschönen Altstadt von Luzern – im Restaurant Fritschi – ein Käsefondue. Nicht nur die Schweizer schienen Freude daran zu haben. Und zum Nachtisch gab es ein Schokoladenfondue, das hingegen bei den meisten nicht mehr viel Platz zum Verzehr gefunden hat.
Bei dieser Gelegenheit wurder über Gott und die Welt, und natürlich auch Computer und Informationssicherheit, diskutiert. Ich sass an einem Tisch, bei dem vorwiegend Pentester zugegen waren und so hat man sich halt das gemeinsame Freud und Leid geteilt: Die Flexibilität der Arbeit, das Verständnis des Kunden zum Thema und die Schwierigkeiten nachvollziehbarer Test-Resultate. Allgemeine technische Diskussionen drehten sich um iPhone/Android und Pufferüberlauf-Schwachstellen.
Zu später Stunde hat man sich dann noch in der Hotel-Bar getroffen und den unterhaltsamen Abend mit einem letzten Schluck Bier oder Whiskey besiegelt. Ich persönlich schätze die Atmosphere der Hashdays sehr, denn die gute Vorbereitung sowie die Kombination aus Professionalität und Persönlichem machen sie zu einem interessanten Anlassen. Und so freu ich mich dann auch, morgen die ersten Talks anhören und über neue Themen diskutieren zu können.
► 26.10.2011 – Blog Digest Oktober 2011
- 8 Reasons for Denial-of-Service (DoS) Attacks (28.09.2011), blog.zeltser.com
- Analyzing PDF Malware – Part 1 (23.09.2011), SpiderlabsAnterior, very good introduction
- APT – The Plain Hard Truth (23.09.2011), fasthorizon.blogspot.com, threat group evolution
- Best practices for reporting malware (11.10.2011), HelpNetSecurity
- Better Random Testing by Leaving Features Out (20.09.2011), EmbeddedInAcademia, ideas for security testing?
- Computer virus hits US Predator and Reaper drone fleet (07.10.2011), arstechnica.com, evolution of cyberwar
- Detecting Defaced Websites with OSSEC (26.10.2011), blog.rootshell.be, extended intrusion detection
- Duqu – Stuxnet 2 (19.10.2011), f-secure.com, is it really Stuxnet 2?
- Exploiting Embedded Systems (21.10.2011), devttys0.com, great 3 part series
- Exploiting Powershell’s Features (Not Flaws) (18.10.2011), Matt, exploit-monday.com
- Facebook’s URL scanner is vulnerable to cloaking attacks (07.10.2011), IDGNS staff, itworld.com
- Father Of C And UNIX, Dennis Ritchie, Passes Away At Age 70 (13.10.2011), Techcrunch, exit(0); /* Exit successfully. RIP */
- Hard Lessons about Hacking and Proxy Services (23.09.2011), Jason Lackey, blogs.cisco.com
- How Security Companies Assign Names to Malware Specimens (26.10.2011), blog.zeltser.com, CARO and CME
- Infographic: Data Breaches, A Decade Of (15.10.2011), SecurityBloggersNetwork, the age of information security
- Interesting Authentication Bypass Vulnerabilities (30.09.2011), Dan Crowley, SpiderlabsAnterior
- ModSecurity Advanced Topic of the Week: Remote File Inclusion Attack Detection (30.09.2011), Ryan Barnett, SpiderlabsAnterior
- Next Generation Encryption (25.10.2011), David McGrew, blogs.cisco.com
- Non alphanumeric code in PHP (22.09.2011), Gareth Heyes, thespanner.co.uk
- On the Success of Malware (23.09.2011), Gunter Damballa, blog.damballa.com
- Possible Governmental Backdoor found (‘case R2D2’) (08.10.2011), f-secure.com
- Pragmatism of security by obscurity? (05.10.2011), securitycurve.com, what do you think?
- Remove Unused/Testing/Debug Software From Your Site (21.10.2011), SucuriSecurity, covered in OWASP-CM-006
- ‘Right-to-Left Override’ Aids Email Attacks (26.09.2011), BrianKrebs, KrebsOnSecurity
- Scientists break card that secures homes, offices, transit (10.10.2011), Dan Goodin, go.theregister.com
- Secret iOS business; what you don’t know about your apps (19.10.2011), TroyHunt, interesting insight
- Securing Mobile Data at the Application Layer (22.10.2011), Steven Fox, blogs.mcafee.com
- Security awareness (24.09.2011), blogs.securiteam.com
- Security Management 2.0: Making the Decision (13.09.2011), securosis.com
- Social engineering with unicode filenames (24.10.2011), blog.relentless-coding.org, nice howto
- The SSD dilemma (29.09.2011), isc.sans.edu
- timing-attack-checker (25.09.2011), pentestmonkey
- Who do CISOs report to? (05.10.2011), SecurityBloggersNetwork, interesting progress
- Who Else Was Hit by the RSA Attackers? (24.10.2011), BrianKrebs, KrebsOnSecurity
- Write to learn, learn to progress (04.10.2011), Martin McKeay, MartinMckeaysNetworkSecurityBlog
► 19.10.2011 – Staatstrojaner – Bedenken und Kritik
Seit Jahren regt sich vor allem in Deutschland beachtlicher Widerstand gegen den sogenannten Bundestrojaner. Behörden der Strafverfolgung wollen ein Trojanisches Pferd einsetzen, um Computersysteme von potentiellen Tätern überwachen zu können. Damit sollen die Möglichkeiten der Quellen-TKÜ (Quellen-Telekommunikationsüberwachung) an die Gegebenheiten des Informationszeitalters angepasst werden. Argumentiert wird in erster Linie damit, dass Dezentralisierung und Verschlüsselungsmechanismen klassische Überwachungsmassnahmen verhindern.
Am 08. Oktober 2011 veröffentlichte der Chaos Computer Club Details zu einem solchen Staatstrojaner. Dieser wurde dem CCC durch einen Anwalt zugespielt, dessen Mandant einer voraussichtlich unlauteren Observation zum Opfer gefallen ist. Eine technische und konzeptionelle Analyse dieser Hintertür hat die im Raum stehende technische und juristische Kritik in praktisch allen Punkten bestätigt.
Grundsätzlich sehen wir drei Gründe, warum ein Einsatz eines Trojanischen Pferds im Rahmen einer Strafverfolgung problematisch ist:
- Tangieren der Privatsphäre: Es findet ein bisweilen unkontrollierbarer Eingriff in die Privatsphäre eines potentiellen Täters statt. Nach wie vor ist auf juristischer Ebene nicht klar geregelt, wie und in welchem Umfang eine solche Software Daten erheben darf und inwiefern etwaige Einschränkungen auf technischer Ebene durchgesetzt werden können.
- Kompromittieren der Integrität: Die Invasivität des Eingriffs, eine einmalige Besonderheit dieser Art der Überwachung, führt zu Veränderungen am Zielsystem, wodurch dessen Integrität kompromittiert und damit die forensische Auswertung in Frage gestellt wird.
- Erhöhen der Angriffsfläche: Das Einspielen zusätzlicher Software auf einem System führt immer eine Erweiterung der Angriffsfläche ein, wodurch eben dieses attackiert und längerfristig kompromittiert werden kann. Die fehlende oder fehlerhafte Qualität des Trojanischen Pferds kann zu einem kompletten Verlust der Sicherheit des Systems führen.
Dessen Problemen sind wir uns bei der Durchführung von Backdoor-Tests sehr wohl bewusst, wie wir beispielsweise im jüngsten Interview für 20 Minuten erklärt haben. Auf technischer und organisatorischer Ebene investieren wir sehr viel Aufwand, um diese Risiken zu minimieren. Dazu gehört zum Beispiel zu verhindern, dass unwillentlich private Daten gesammelt oder die Infektion einer Drittperson in Kauf genommen wird.
Dass diese Qualitätsanforderungen, die wir an uns selbst stellen, in einem Rechtsstaat ebenso für Strafverfolgungsbehörden zu gelten haben, das ist für uns eine Selbstverständlichkeit. Bevor grundlegende Dinge in dieser Angelegenheit nicht einwandfrei geklärt sind, raten wir von einem Einsatz eines solchen Bundestrojaners ab.
► 13.10.2011 – scip Talks & Presentations Preview: 4. Quartal 2011
Das Jahr neigt sich dem Ende zu, doch für die Consultants der scip AG ist das noch lange kein Grund, sich der verfrühten Jagd nach Weihnachtsgeschenken zu verschreiben. Wir denken, dass Wissenaustausch und internationales Networking ein unabdingbarer Teil unserer Industrie ist, in der technologische Aktualität und ein umfassender Erfahrungsschatz von essentieller Notwendigkeit sind. Aus diesem Grund sind unsere Mitarbeiter auch im vierten Quartal des Jahres weltweit unterwegs:
29.10.2011 | Marc Ruef @ hashdays Luzern, Zürich
Ende Oktober findet in Luzern die hashdays Konferenz statt, die führende technische Schweizer Sicherheitskonferenz. Im Lineup, das sich aus internationalen Top-Speakern wie Felix “FX” Lindner, Chris Nickerson und David Kennedy zusammensetzt, ist auch unser Marc Ruef vertreten. Gemeinsam mit Anwalt Luca Dal Molin wird Ruef in seinem Vortrag Code Plagiarism – Technical Detection and Criminal Prosecution über die Problematik von Softwareplagiarismus referieren und Einblicke in den Fall WEKA vs. ATK geben, in den er selber vor einigen Jahren aktiv involviert war.
09.11.2011 | Marc Ruef @ Future IT, Wiesbaden, Deutschland
Das Bundeskriminalamt (BKA) in Wiesbaden, das Bayerische Landeskriminalamt (BLKA) in München, die Fedpol in Bern/CH und das Anwenderzentrum (AZO) in Oberpfaffenhofen veranstalteten im November 2010 erstmals in Berlin das internationale Symposium „Neue Technologien (NT)“. Bei der erneuten Durchführung des Events wird Marc Ruef einen Vortrag mit dem Titel Computersicherheit – Cybercrime – Technisch – Juristisch halten.
09.11.2011 | Andrea Covello @ scip )talk(, Zürich
Auch unsere eigene Vortragsveranstaltung )talk(, die seit jeher dreimal im Jahr in Zürich stattfindet, geht im November in die letzte Runde in 2011. Andrea Covello der scip AG wird in seinem Vortrag die Thematik Security in Virtual Environments erläutern und in einem anschliessenden Roundtable Gespräch für fachkundige Auskunft sorgen.
14.11.2011 | Stefan Friedli @ SOURCE Barcelona, Spanien
Die SOURCE Konferenzreihe, die bereits wiederholt im scip Labs Erwähnung fand, kommt auch dieses Jahr wieder auf einen Abstecher nach Europa und ist in der spanischen Hauptstadt Barcelona zu Gast. Stefan Friedli wird im altehrwürdigen Museu Nacional D’art de Catalunya über häufige Probleme und Fallstricke im Hinblick auf Penetration Tests sprechen.
22.11.2011 | Marc Ruef @ Datenschutzforum, Zürich
Das Datenschutz Forum Schweiz unterstützt die Datenschutzdiskussion unter Interessierten aller Fachrichtungen aus der Wirtschaft, öffentlichen Verwaltungen und der Wissenschaft. An der Veranstaltung vom 22.11.2011 wird Marc Ruef einen Vortrag zum Thema Cloud Security halten. Das Thema, das bisher 2011 viele IT-Fachkräfte beschäftigte, behält seine Aktualität demnach auch im neuen Quartal. Teilnehmer dürfen eine komplett überarbeitete Version des – bereits 2010 mit grosser, positiver Resonanz, durchgeführten – Vortrags Sicherheit von Cloud Computing erwarten.
28.11.2011 | Stefan Friedli @ Security-Zone Cali, Kolumbien
Gut 10’000 km vom Hauptquartier der scip AG entfernt liegt die kolumbianische Stadt Cali in der Nähe der südamerikanischen Pazifikküste. In der Metropole, die mitunter als Hauptstadt des Salsas bekannt ist, findet Ende November die erste Sicherheitskonferenz Kolumbiens überhaupt statt. Stefan Friedli der scip AG freut sich, der Einladung der Muro Group nachkommen zu können und seinen Vortrag mit dem klangvollen spanischen Titel Pruebas de Penetración: Como hacerlo Correcto! in diesem Kontext halten zu dürfen.
06.12.2011 | Stefan Friedli @ Digicomp OpenTuesday, Zürich
Nahezu schon zum Abschluss des Jahres präsentieren wir in Zusammenarbeit mit dem OpenTuesday der Digicomp ein besonderes Event. Am Samichlaus-Tag (06.12.2011) wird Stefan Friedli in Zürich einen kurzen Workshop mit dem Titel Offensive Security 101 durchführen, wo Open Source Tools, die zu Sicherheitsprüfungen genutzt werden, anhand praktischer Beispiele erklärt werden. Interessierte Anfänger und Fortgeschrittene, die sich für die Thematik interessieren sollten diesen kostenlosen Event nicht verpassen.
Falls Sie oder Ihre Mitarbeiter an einem dieser Events teilnehmen, freuen wir uns Sie dort zu treffen. Falls Sie die Chance zu einem unverbindlichen Gespräch nutzen möchten, arrangieren wir dies gerne auf Anfrage.
Stefan Friedli | G+ (623 Wörter)
► 06.10.2011 – 10 Gründe gegen Short-URLs
Short-URLs sind in den letzten Jahren zu einem festen Bestandteil des World Wide Web geworden. Dazu beigetragen haben in erster Linie Soziale Netze und das Bedürfnis, Informationen möglichst kompakt weiterzutragen.
Durch einen URL Shortener Service wird es möglich, eine lange Webadresse in eine sehr kurze Adresse zu packen. Die kurze URL kann dann auf einem Dienst wie Twitter gepostet werden, ohne den verfügbaren Speicherplatz durch den langen Link aufzubrauchen. Durch das Klicken auf die Short-URL wird der Benutzer dann transparent zur echten langen URL weitergeleitet.
Das Nutzen von Short-URL Diensten hat jedoch auch gravierende Nachteile, die bisweilen in sicherheitsbezogene Überlegungen miteinfliessen müssen. Hier 10 Gründe, die gegen den Einsatz von Short-URLs sprechen:
- Destination unklar: Eine Short-URL wird verwendet, um auf eine echte URL weiterzuleiten. Anhand der Short-URL selbst, kann kein Rückschluss auf die echte URL gezogen werden. Wird also eine Short-URL erhalten und will auf diese geklickt werden, kann man bis zum Erreichen der finalen URL nicht sicher sein, über welche Zwischensysteme und zu welchem Ziel man geführt wird.
- Einfaches Link-Spoofing: Short-URLs funktionieren mit IDs, die kryptisch daherkommen und oftmals nicht nachvollziehbar sind. Es ist sodann auf den ersten Blick für viele nicht ersichtlich, ob es sich bei http://shorturl.example/d41m um den gleichen Link handelt, wie bei http://shorturl.example/d4lm – Dies eröffnet die Möglichkeit einfaches Link-Spoofings, wie man es von klassischen Phishing-Attacken her kennt.
- Link-Hijacking möglich: Die Dienste für Short-URLs verwendet einen Namensraum für die eindeutige Identifizierung der jeweiligen URLs. Dieser ist naturbedingt begrenzt, um den Anforderungen kurzer URLs gerecht werden zu können. Es ist bei vielen Diensten nicht klar, was nach dem Aufbrauchen des Namensraums mit alten oder lange nicht angeklickten URLs passiert. Diese könnten wiederverwendet werden, wodurch sich ein Link-Hijacking durchsetzen liesse.
- Überwachung durch Dritte: Beim Zugriff auf eine Short-URL wird immer zuerst eine Verbindung zum Anbieter des Dienstes durchgeführt, der in einem weiteren Schritt die Umleitung einleitet. Der Anbieter kann damit in den Besitz sensitiver Daten kommen und umfassende Statistiken zum Verhalten der jeweiligen Besucher anstreben. Im schlimmsten Fall kann er damit die gleiche Menge an Daten sammeln, die der Anbieter der Original-URL ebenfalls zusammentragen könnte.
- Zentraler Angriffspunkt: Die Kompromittierung eines Short-URL Dienstes kann zur automatischen Kompromittierung sämtlicher jemals ersteller und aufgerufener Short-URLs führen. Durch Redirects und Injections könnte Malware verbreitet (via @mylaocoon) oder eine Man-in-the-Middle Attacke angegangen werden.
- Abhängigkeit vom Anbieter: Der Einsatz eines Short-URL Dienstes tangiert das zentrale Konzept des Link-Austauschs im World Wide Web. Eine solche Abhängigkeit kann zu weitreichenden Problemen führen, sollte ein Anbieter plötzlich seine Geschäftsbedingungen ändern oder gar vom Markt verschwinden (Insolvenz, Übernahme, etc.). Jenachdem müsste innert kürzester Zeit eine Vielzahl an Links geändert werden, was sich unter Umständen als nahezu unmöglich gestaltet (z.B. alte Tweets lassen sich nicht mehr ändern).
- Verlust der Brandingmöglichkeit: Eine URL wird von vielen Webmastern als Visitenkarte verstanden. Im Idealfall ist sie prägnant und aussagekräftig zugleich. Werden externe Dienste eingesetzt und damit die eigenen URLs kaskadiert, führt dies zum Verlust einer Brandingmöglichkeit. Eine Adresse wie http://www.scip.ch/?kontakt wirkt bedeutend besser als http://shorturl.example/c1fa
- Verlust der Kredibilität: Mit dem Einsatz einer Short-URL geht stets die Einbusse des professionellen Auftretens einher. Eine eigene Domain macht sich halt noch immer besser, als auf einen libyschen Short-URL Dienst zu setzen. Vor allem deswegen, weil vor allem Malware- und Spam-Verteiler diese Möglichkeit der URL-Kaskadierung für sich entdeckt haben.
- Erhöhung der Komplexität: Durch den Einsatz von Short-URL Diensten wird die Komplexität des Generierens, Verteilens und Nutzens von URLs erhöht. Dies wirkt sich zwangsweise früher oder später beim Debugging von Kommunikationsproblemen aus. Jenachdem wird es dann schwierig die Quelle eines Fehlers eingrenzen zu können.
- Performanceverlust: Der Aufruf einer Short-URL hat in der Regel zur Folge, dass eine Weiterleitung zur echten URL geschieht. Dies ist bei den meisten Diensten durch einen
302 Redirectper HTTP-Header implementiert. Da dabei zuerst eine Namensauflösung für die Short-URL und die HTTP-Kommunikation zu dieser umgesetzt werden muss, bis zur echten URL weitergeleitet wird, muss mit einem kleinen Ressourcenverbrauch und Performanceverlust gerechnet werden.
Trotz dieser Bedenken setzen wir punktuell Short-URLs ein. Und zwar in erster Linie auf Twitter, um die Zeichenbeschränkung für Tweets einhalten zu können. Andernorts pflegen wir die normalen URLs für unsere Webseite weiterzugeben. Da wir beim Design dieser auf eine kurze und prägnante Struktur geachtet haben, können wir in autonomer Weise sehr effiziente Webadressen bereitstellen.
► 30.09.2011 – Blog Digest September 2011
- 10 Windows 7 commands every administrator should know (15.09.2011), Brien Posey, techrepublic.com
- 8 Reasons for Denial-of-Service (DoS) Attacks (28.09.2011), blog.zeltser.com
- 9 Convenient Lies in Information Security (09.09.2011), blog.zeltser.com
- Analyzing PDF Malware – Part 1 (23.09.2011), SpiderlabsAnterior, very good introduction
- APT – The Plain Hard Truth (23.09.2011), fasthorizon.blogspot.com, threat group evolution
- Better Random Testing by Leaving Features Out (20.09.2011), EmbeddedInAcademia, ideas for security testing?
- Circumventing malware detection (26.08.2011), norman.com
- Cultural CAPTCHAs (19.09.2011), Brian Krebs, KrebsOnSecurity
- Cultural Security: Promoting Security Policies Using Organizational Culture (06.09.2011), Steven Fox, blogs.mcafee.com
- Denial of Service (08.09.2011), book, deadliestwebattacks.com
- Diginotar declared bankrupt (20.09.2011), isc.sans.edu, bankruptcy of a CA for 1st time
- DNS hack hits popular websites: Daily Telegraph, The Register, UPS, etc (04.09.2011), Graham Cluley, GrahamCluleysBlog
- Dropping Executables with Powershell (15.09.2011), exploit-monday.com, similar approach like my Spread project
- Friends, Foes and Faceless Denizens – The Real Social Network (12.09.2011), Steven Fox, blogs.mcafee.com
- Hard Lessons about Hacking and Proxy Services (23.09.2011), Jason Lackey, blogs.cisco.com
- Is this really the ‘State of Security’? (03.09.2011), Martin McKeay, MartinMckeaysNetworkSecurityBlog
- Morto: Another reason to secure local user accounts (29.08.2011), community.rapid7.com, test if you’re vulnerable
- Non alphanumeric code in PHP (22.09.2011), Gareth Heyes, thespanner.co.uk
- On the Success of Malware (23.09.2011), Gunter Damballa, blog.damballa.com
- Post-Exploitation in Windows: From Local Admin To Domain Admin (efficiently) (11.09.2011), pentestmonkey
- Protecting against XSS (13.09.2011), Gareth Heyes, thespanner.co.uk
- Reverse shells one-liners (15.09.2011), BernardoDamele, via @ChrisJohnRiley
- ‘Right-to-Left Override’ Aids Email Attacks (26.09.2011), Brian Krebs, KrebsOnSecurity
- Security awareness (24.09.2011), blogs.securiteam.com
- SSL certificate impersonation -for shits and giggles! (04.09.2011), Chris John Riley, blog.c22.cc
- Suspected hackers arrested over Anonymous/LulzSec internet attacks (02.09.2011), Graham Cluley, GrahamCluleysBlog
- The Phantom Save (01.09.2011), FutilityCloset, same principle with infosec counter-measures?
- Timing-attack-checker (25.09.2011), pentestmonkey
- Twitter Social Networking Among Information Security People (12.09.2011), blog.zeltser.com
- Using QR tags to Attack SmartPhones (Attaging) (11.09.2011), KaoticoNeutral, not just for joking
- Who’s responsible for your online data? (14.09.2011), blog.eset.com, interesting survey
- Windows Remote Desktop Worm ‘Morto’ Spreading (12.09.2011), f-secure.com
- Writing Meterpreter Extensions (28.08.2011), scriptjunkie, scriptjunkie.us
► 27.09.2011 – Vortrag an BruCON 2011 in Brüssel
Zum dritten Mal fand vergangene Woche in Brüssel die Hackerkonferenz BruCON statt. Die scip AG war vor Ort durch Stefan Friedli vertreten, der die Konferenz am Dienstagabend mit seiner Präsentation “The 99c Heart Surgeon Dilemma: How to fix Penetration Testing” im gut besuchten Hauptsaal der Vrije Universiteit Brussel abschloss.
Im Vortrag thematisierte Friedli in erster Linie seine Arbeit am Penetration Testing Execution Standard, die ihn zur Analyse einer Unmenge von Penetration Testing Reports führte – mit teils amüsanten, teils skurrilen Inhalten. Unter dem Motto This is about bad examples wurde aufgezeigt, wo die Ursachen für gängige Probleme liegen und wie man diesen entgegentreten kann.
Die Videoaufnahmen des Vortrags sind derzeit immer noch in Bearbeitung, werden aber zu einem späteren Zeitpunkt im scip Labs-Blog veröffentlicht werden. Bis dahin verweisen wir gerne auf die Slides, die bereits online verfügbar sind.
Stefan Friedli | G+ (245 Wörter)
► 22.09.2011 – Vortrag zu Information Security und Marketing
Am 13. September 2011 fand der Anlass der Marketingleiter Zürich des Swiss Marketing (SMC) zum Thema Ist Internet Security ein Thema im Marketing? statt. Ein Erfahrungsaustausch unter Marketingleitern welcher 7 bis 8 mal pro Jahr durchgeführt wird. Im Clublokal des SIB (Schweizerisches Institut für Betriebsökonomie) in Zürich referierte unser Herr Simon Zumstein einen Abend lang zum Thema Information Security und den Berührungspunkten für Marketingleiter.
Der Vortrag hatte zum Ziel den Marketingleitern das grosse Fachgebiet der Information Security aufzuzeigen. Die während des Vortrags erzählten Geschichten bauten mit realen Fallbeispielen und dem Brückenschlag zum Marketing einen Spannungsbogen auf.
Datenverluste, Computerviren, Trojaner, Hacker, Cracker, Webattacken usw. sind in aller Munde. All das stellt eine massive Bedrohung für die Informationstechnik in Unternehmen und anderen Organisationen dar. Die Beachtung der IT-Security hat für Unternehmen wie auch für private Personen einen grossen, wirtschaftlichen Faktor, im positiven wie auch im negativen Sinne.
Die modernen Kommunikationsmittel wie zum Beispiel das iPad bieten viele Vorteile, bergen aber auch Gefahren und Risiken. Auch Web-Applikationen und Web-Services wie Facebook, Google+, YouTube, Instant Messager und Twitter stellen durch die rasante Zunahme ein immer grösseres Sicherheitsrisiko dar. Die Anwendungen können aufgrund ihrer Funktionsweise Angriffen und Bedrohungen über das Netzwerk Tür und Tor öffnen.
Wir alle haben in den letzten Wochen die Hiobsbotschaften über erfolgreiche Einbrüche und Manipulationen bei namhaften Firmen gelesen. Aber welche Gedanken und Überlegungen sind tatsächlich relevant für Marketingleiter?
Wir bedanken uns sowohl für die Einladung zum Vortrag als auch für die angeregten Unterhaltungen mit den teilnehmenden Makretingleitern. Wir haben es sehr genossen und hoffen die Aufmerksamkeit zum Thema Information Security erheblich gesteigert zu haben.
Simon Zumstein | G+ (287 Wörter)
► 14.09.2011 – Eingabeprüfung im Detail
Die Grundlage bestehender Computersicherheit wird durch die Eingabeprüfung geschaffen. Bei dieser werden frühstmöglich die Eingaben durch die Applikation validiert, um unerwünschte und unerwartete Abweichungen feststellen und auf sie reagieren zu können. In diesem Artikel werden die Grundlagen moderner, effizienter und eleganter Eingabeprüfung im Detail diskutiert. Angehende und erfahrene Entwickler können dadurch ihr Wissen verbessern, um sichere Anwendungen schreiben zu können.
Angewandte Computersicherheit im Allgemeinen und Softwaresicherheit im Speziellen sind in erster Linie von einer Eigenschaft abhängig: Der Eingabeüberprüfung. Die von einem System entgegengenommenen Daten müssen frühstmöglich, mindstens vor der effektiven Weiterverarbeitung im allgemeinen Programmzyklus, auf ihre Richtigkeit hin geprüft werden. Nur durch diese Validierung kann erkannt werden, ob der weiterführende Prozess den besonderen und eventuell unerwarteten Eigenschaften der Daten gerecht werden kann. Ist dem nicht so, sollte oder muss von einer weiteren Nutzung der damit als infiziert erkannten Daten, in der englischsprachigen Literatur werden sie infected genannt, abgesehen werden.
Eine Eingabeüberprüfung kann innerhalb der Applikation durch verschiedene Techniken realisiert werden. In dieser Abhandlung sollen anhand funktionierender Programmbeispiele aufgezeigt werden, welche Ansätze verfolgt werden können und welche Vor- sowie Nachteile sie mit sich bringen.
Grundlage der Eingabeüberprüfung
Die Grundlage der weiterführenden Diskussion ist die allgemeine Funktionsweise einer Eingabeüberprüfung. Einführend soll mit der abgedruckten Anwendung application.php, sie besteht lediglich aus 9 Codezeilen, die jeweiligen Beispiele erarbeitet werden:
$notvalidated_input = $_GET['user_input'];
if(isinfected($notvalidated_input)){
echo 'Input infected: Abort!';
exit;
}else{
echo 'Input okay: Execute...';
dosomething();
}
Hierbei handelt es sich um eine Webapplikation, welche in Zeile 01 die Eingabe der GET-Anfrage aus $_GET['user_input'] in die Variable $notvalidated_input speichert. Wie die Namensgebung erahnen lässt, sind die Ursprungsdaten durch den Benutzer definiert worden (user_input) und werden in die noch nicht geprüfte Variable (notvalidated_input) abgelegt.
Sofort nach der Entgegennahme der Eingaben soll eine Prüfung auf diese angewendet werden. Hierzu kommt die noch nicht weiter diskutierte Funktion isinfected() in Zeile 03 zum Tragen. Ihr wird als erstes und einziges Argument die noch nicht geprüfte Variable $notvalidated_input übergeben.
Liefert dieser Funktionsaufruf true zurück, entscheidet die bedingte Anweisung if, dass die Programmausführung in Zeile 04 weitergefahren wird. Dabei wird durch echo die Fehlermeldung Input infected: Abort! ausgegeben und das Programm in Zeile 05 mit exit sofort verlassen. Da die Eingabe infiziert schien, wird also auf eine weitere Ausführung gänzlich verzichtet.
Liefert die Eingabeüberprüfung hingegen ein false zurück, wird stattdessen der else-Block ab Zeile 06 ausgeführt. Dabei wird exemplarisch in Zeile 07 die Meldung Input okay: Execute... dargestellt. Die weitere Programmausführung wird durch die nicht weiter beschriebene Funktion dosomething() in Zeile 08, sie könnte eine Datenbankabfrage mittels SQL durchführen, symbolisiert.
Deklaration von isinfected()
Es soll sich von nun an auf die zentrale Funktion isinfected(), welche für die Eingabeüberprüfung zuständig ist, konzentriert werden. Verschiedene Implementierung dieser, welche massgeblich für die Sicherheit der gezeigten Anwendung verantwortlich sind, sollen behandelt werden. Schliesslich führt sie die Eingabeprüfung durch und beeinflusst in zentraler Weise die Entscheidung, ob der reguläre Programmfluss verfolgt werden will oder nicht.
Es handelt sich hier also um eine eigens geschriebene Funktion, die so nicht in der eingesetzten Programmiersprache angeboten wird. Wir können die Eigenschaften der Funktion damit selbst bestimmen. Als Eingabe werden in erster Linie prüfende Daten erwartet. Dies können interne Variablen, Rückgabewerte von Datenbanken, benutzerdefinierte GET-/POST-Variablen oder Daten von Webformularen sein. Der Aufruf von isinfected($value) führt also dazu, dass die Funktion isinfected() die Variable $value validiert.
Konnte die Eingabeüberprüfung einen unerwünschten Zustand feststellen, liefert isinfected() den boolschen Wert true (wahr) zurück. In diesem Fall weiss das Hauptprogramm, dass die geprüften Daten infiziert sind und von einer weiteren Nutzung bzw. Ausführung abgesehen werden sollte. Konnte hingegen keine potentielle Unsicherheit festgestellt werden, liefert die Funktion den boolschen Wert false (falsch) zurück. Der Nutzung der Daten steht also, vertraut man denn der Prüfung, nichts mehr im Weg. Selbstverständlich könnte eine andere Implementierung von isinfected() anstelle von true/false auch die Integerwerte 1/0 oder Zeichenketten wie Unsicher/Infiziert zurückliefern. Der Einfachheit halber und zu Gunsten der Ausführungsgeschwindigkeit wird hier jedoch auf boolsche Werte gesetzt.
Strengste Prüfung mit absolutem Vergleich
Das erste Beispiel einer Implementierung von isinfected() nutzt die strengste Form der Prüfung. Hierbei wird ein absoluter Vergleich im Rahmen einer Whitelist durchgeführt. Hierzu werden die klassischen Vergleichsoperatoren, wie sie in den meisten Programmiersprachen ohnehin angeboten werden, herangezogen:
function isinfected($notvalidated_input){
if($notvalidated_input == 'name'){
return false;
}else{
return true;
}
}
Diese Implementierung namens whitelist_strong.php umfasst lediglich 7 Zeilen. Direkt zu Beginn wird der Inhalt der übergebenen und in $notvalidated_input abgegebenen Variable mittels dem Vergleichsoperator == daraufhin überprüft, ob sie der Zeichenkette “name” entspricht (Zeile 02). Ist dies der Fall, ist die Eingabe geprüft und erlaubt. Die Funktion liefert sodann mittels dem Aufruf return den Wert false zurück und wird beendet (Zeile 03).
Ist in $notvalidated_input hingegen nicht der erwartete Wert “name” enthalten, wird der Wert true zurückgegeben und die Funktion beendet (Zeile 05). Man spricht hier von einer sogenannten Whitelist. Die bedingte Anweisung prüft nämlich anhand einer Liste, sie enthält in diesem Beispiel nur einen Eintrag, ob die Eingabe zugelassen ist. Man kann dies mit einer Gästeliste für eine exklusive Party vergleichen: Ist der Name eines Gasts nicht auf der Liste enthalten, wird ihm der Zutritt zum begehrten Anlass verwehrt.
Dieses Verfahren gilt als das Sicherste. Denn schliesslich muss eine zu jedem Zeitpunkt nachvollziehbare Situation vorherrschen, damit die Weiterführung erlaubt wird. Ist diese Situation nicht gegeben, hat man es mit etwas Unerwartetem und potentiell gefährlichem zu tun. Dies führt zwar dazu, dass vielleicht auch Gästen der Zutritt zur Party verwehrt bleibt, obschon sie eigentlich angenehme Gesprächspartner gewesen wären. Sicherheit geht hierbei jedoch vor. Eine jede hochsichere Anwendung sollte auf eine solch strinkte Implementierung einer Eingabeüberprüfung setzen.
Whitelist mit strenger Prüfung
In einigen Fällen, wie zum Beispiel bei Formularfeldern, ist es durchaus möglich, dass die Whitelist um die erwarteten Werte erweitert werden. In whitelist_form.php wird das zuvor genannte Beispiel mit der Zeichenkette name durch die zusätzlichen Felder address (Zeilen 04-05), phone (Zeilen 06-07) und mail (Zeilen 08-09) ergänzt. Wird einer dieser Werte beobachtet, ist er erlaubt und die Funktion liefert sinngemäss false zurück. Handelt es sich jedoch um eine andere und damit unerwartete Eingabe, wird wie üblich der Wert true zurückgegeben (Zeilen 10-11):
function isinfected($notvalidated_input){
if($notvalidated_input == 'name'){
return false;
}elseif($notvalidated_input == 'address'){
return false;
}elseif($notvalidated_input == 'phone'){
return false;
}elseif($notvalidated_input == 'mail'){
return false;
}else{
return true;
}
}
Blacklist mit direkter Prüfung
Es gibt Situationen, in denen ist es nicht tragbar, dass unbekannte Eingaben einfachso als infiziert deklariert werden können. Gerade bei Daten, die eine sehr komplexe und unvorhersehbare Struktur aufweisen, ist dies der Fall. Bestes Beispiel ist das Eingabefeld eines Webforums, in dem die jeweiligen Benutzer ihre Postings nach Belieben verfassen können. Es ist unmöglich innerhalb einer Whitelist zu definieren, welche Posts erwartet und erlaubt sind. Dazu müsste theoretisch jedes mögliche Posting bekannt und in der Whitelist abgespeichert werden. Je nach unterstütztem Zeichensatz und erlaubter Posting-Länge wären dies mehrere millionen Milliarden Whitelist-Einträge.
In solchen Fällen wird auf den umgekehrten Ansatz der Blacklists zurückgegriffen. Auf einer solchen schwarzen Liste sind sämtliche Eingaben vermerkt, die definitiv nicht zugelassen werden, da deren Gefährlichkeit bekannt ist. Meistens handelt es sich dabei um üblicherweise innerhalb spezifischer Attacken genutzte Muster. Man spricht hier deshalb auch von einem pattern-basierten Ansatz. In blacklist_form.php wird die Eingabe daraufhin geprüft, ob sie den Zeichenketten /etc/passswd (Zeile 02) oder /var/log/messages (Zeile 04) entspricht. Ist dem so, also die Eingabe gleich dem Blacklist-Wert, wird er nicht zugelassen und true zurückgegeben (Zeile 03 oder 05). In allen anderen Fällen, in denen also keiner der zwei gelisteten Werte gegeben ist, wird keine Infektion erwartet und damit false geliefert (Zeilen 06-07):
function isinfected($notvalidated_input){
if($notvalidated_input == '/etc/passswd'){
return true;
}elseif($notvalidated_input == '/var/log/messages'){
return true;
}else{
return false;
}
}
Dieser Ansatz weist verschiedene Probleme bezüglich Administration und Sicherheit auf. Je grösser die Blacklist wird, desto umfangreicher wird die Funktion. Schliesslich muss für jeden unerwünschten Wert eine neue bedingte Anweisung eingeführt werden. Im genannten Beispiel werden zwei wichtige Systempfade aufgelistet. Möchte man nun sämtliche dieser abdecken, müssten Duzende eingeführt werden. Die Funktion wächst damit auf mehrere Hundert Zeilen an. Hierbei den Überblick zu wahren ist fast nicht mehr möglich. Um die Programmlogik von den Nutzdaten zu trennen, wird das mit blacklist_infile.php illustrierte Modell vorgeschlagen:
function isinfected($notvalidated_input){
$disallowedstrings = file('blacklist.txt');
if(in_array($notvalidated_input, $disallowedstrings)){
return true;
}
}
Hierbei wird eine Textdatei mit sämtlichen Blacklist-Einträgen angefertigt. Diese Datei namens blacklist.txt wird in Zeile 02 durch die Funktion file() eingelesen. Hierbei wird jede Zeile der genannten Datei in das Array $disallowedstrings übertragen. In der ersten Zeile von blacklist.txt findet sich also /etc/passwd, was in $disallowedstrings[0] abgelegt wird und in der zweiten Zeile findet sich /var/log/messages, was in $disallowedstrings[1] abgelegt wird.
In Zeile 04 findet nun eine Prüfung statt, ob die übergebene Eingabe $notvalidated_input einen der im Array $disallowedstrings gespeicherten Werte enthält. Hierzu wird die Funktion in_array() genutzt, welche als ersten Parameter den Haystack (Wo soll gesucht werden?) und als zweiten Parameter die Needle (Was soll gesucht werden?) erwartet. Wird einer der Werte in Zeile 04 gefunden, wird eine Infektion durch die Blacklist erkannt, der Wert true zurückgeliefert und die Funktion verlassen. In allen anderen Fällen kann keine Infektion festgestellt werden und deshalb wird standardmässig false zurückgegeben. Die eigentliche Funktion bleibt mit 7 Zeilen sehr klein und die Blacklist kann unabhängig dieser in der übersichtlichen Textdatei (sie wird eventuell gar durch eine relationale Datenbank geschrieben) moderiert werden.
Um zu verhindern, dass ein Angreifer durch das Auslesen der Blacklist-Datei neue Strategien zum Umgehen dieser ausarbeiten kann, sollte sie nicht öffentlich zugänglich sein (z.B. durch .htaccess geschützt oder in nicht-öffentlichem Verzeichnis abgelegt).
Prüfung von Wertbereichen von Zahlen
Die bisherigen Diskussionen haben sich auf Zeichenketten als zu prüfende Werte konzentriert. Diese sind hauptsächlich die Sorgenkinder der sicheren Programmierung. Dennoch gibt es auch bezüglich der Verarbeitung von Zahlen Probleme. Nachfolgend sollen verschiedene Ansätze zur Prüfung dieser vorgestellt werden. Damit wird ebenfalls der Grundstein für die zum Schluss behandelte Prüfung von Symbolen in komplexen Zeichenketten gelegt werden.
Die meisten Programme müssen früher oder später einen Zahlenwert verarbeiten. Sei dies nun als Eingabe des Jahrgangs, einer Postleitzahl oder einer Telefonnummer. Handelt es sich um komplexe Zahlenkonstrukte, müssen diese grundsätzlich gleich wie eine Zeichenkette behandelt werden. Zum Beispiel dann, wenn ein Datum in der Schreibweise 11.02.1981 (dd.mm.YYYY) definiert wird. Schliesslich werden hier einzelne Werte (Tag, Monat, Jahr) durch den Punkt als Sonderzeichen voneinander getrennt.
Durch eine Funktion wie explode() könnten diese einzelnen Werte nun in ein eindimensionales Array $date gespeichert werden. So ist sodann in $date[0] der Tag (11), in $date[1] der Monat (02) und in $date[2] das Jahr (1981) abgelegt. Diese einzelnen Werte liessen sich nun weiterhin mit einer explizit für Zahlenwerte konstruierten Fassung von isinfected() prüfen.
function isinfected($notvalidated_input){
if($notvalidated_input < 1){
return true;
}elseif($notvalidated_input > 31){
return true;
}else{
return false;
}
}
Sodann wird mit value_validation.php eine erste Fassung der Integervariante aufgezeigt, mit der fehlerhafte Werte bezüglich des Tags eines Monats erkannt werden können sollte. Auch hier wird im ersten an die Funktion übergebenen Parameter der zu prüfende Wert definiert. Er wird in $notvalidated_input und durch eine bedingte Anweisung kontrolliert.
Zuerst wird in Zeile 02 validiert, ob die Variable kleiner als 1 ist. Da ein Monat stets mit dem Tag 1 beginnt, ist ein Tag 0 oder ein negativer Tag -1 nicht zu erwarten. Wird ein solcher falscher Wert beobachtet, dieser wird in diesem Zusammenhang als Underflow bezeichnet, wird durch return der Wert true zurückgeliefert.
Konnte kein Underflow beobachtet werden, wird in einem zweiten Schritt mit elseif in Zeile 04 geprüft, ob der Wert grösser als 31 ist. Zwar gibt es den Februar, der entweder 28 oder 29 Tage hat sowie einige andere Monat, die lediglich 30 Tage haben. Es gibt jedoch keinen Monat, der mehr Tage als 31 hat. Würde eine solche Eingabe entgegengenommen worden sein, dies wäre ein Overflow, wird ebenfalls true zurückgegeben.
In allen anderen Fällen wird durch else in Zeile 06 der Wert false zurückgegeben. Die Eingabe ist demnach grösser als 0 und nicht grösser als 31. Sie ist damit im erwarteten Bereich und wird deshalb als legitim verstanden.
Je nach eingesetzter Programmiersprache oder genutztem Codierungsverfahren kann der gezeigte Programmcode jedoch überlistet werden, um dennoch unerwartete Eingaben als legitime Werte durchgehen zu lassen. Wird anstelle eines ganzzahligen Werts ein Sonderzeichen wie % übergeben, wird dies unter Umständen nicht kleiner als 1 und auch nicht grösser als 31 erkannt. Ist die Sprache sehr liberal im Umgang mit Datentypen, wird es sich auf die Rückgabe von false im finalen else-Block beschränken.
Eine gern genutzte Methode zur Verhinderung solcher Angriffe wird als Assertion, in der deutschsprachigen Literatur auch Zusicherung genannt, bezeichnet. Vor der Prüfung der Werte wird der für eben diese erforderliche Datentyp forciert. Hierzu kommt ein Type Casting, welches von den meisten professionellen Programmiersprachen bereitgestellt wird, zum Einsatz. In value_assertion.php gezeigten Erweiterung wird hierzu in Zeile 02 die Funktion settype() verwendet, um $notvalidated_input in jedem Fall in einen Integerwert umzuwandeln.
function isinfected($notvalidated_input){
settype($notvalidated_input, 'integer');
if($notvalidated_input < 1){
return true;
}elseif($notvalidated_input > 31){
return true;
}else{
return false;
}
}
Jenachdem was für ein Mechanismus für die Typenumwandlung verwendet wird, muss mit anderen Resultaten gerechnet werden. So könnte settype() des gezeigten Beispiels aus Nicht-Zahlenwerten stets 0 generieren. Oder es könnte um eine Umwandlung in die ASCII- oder eine UNICODE-Form bemüht sein. Jenachdem wird also der weiteren Validierung gerecht geworden oder nicht. Dies hat sodann massgeblichen Einfluss auf die weitere Programmausführung.
Anstelle einer Typenumwandlung kann eine Typenprüfung genutzt werden, um etwaige Angriffe als solche zu erkennen. Die in value_typetest.php dokumentierten Erweiterung von isinfected() validiert nun als erstes mittels is_int(), ob es sich beim zu prüfendenden Objekt um einen Integerwert handelt (Zeile 02). Ist dies der Fall, wird die schon bekannte Werteprüfung in den Zeilen 03 bis 09 durchgeführt. Handelt es sich jedoch nicht um einen Integerwert, wird im else-Block der Wert true zurückgegeben (Zeilen 10-12):
function isinfected($notvalidated_input){
if(is_int($notvalidated_input)){
if($notvalidated_input < 1){
return true;
}elseif($notvalidated_input > 31){
return true;
}else{
return false;
}
}else{
return true;
}
}
Das Prüfen von Zahlenwerten wird immerwieder erforderlich. Aus diesem Grund sollte auf eine generische Form der Funktion gesetzt werden. Hierbei erwartet die in value_function.php gezeigte Implementierung drei Argumente: (1) An erster Stelle wird noch immer die zu prüfende Variable übergeben. (2) An zweiter Stelle wird hingegen in $min der minimal erwartete Wert definiert. (3) Und an dritter Stelle wird zusätzlich in $max der maximal erwartete Wert angegeben. Durch Aufrufe wie isinfected($_GET['day'], 1, 31) können nun Tage des Monats und durch isinfected($_GET['month'], 1, 12) Monate selbst geprüft werden:
function isinfected($notvalidated_input, $min, $max){
if(is_int($notvalidated_input)){
if($notvalidated_input < $min){
return true;
}elseif($notvalidated_input > $max){
return true;
}else{
return false;
}
}else{
return true;
}
}
Wertbereiche von Symbolen
In den meisten Fällen können die erwarteten Zeichen, die in einer Eingabe vorkommen können, eingeschränkt werden. Wie sich reine Zahlenwerte bezüglich ihrer Wertbereiche prüfen und einschränken lassen, wurde zuvor gezeigt. Doch auch Zeichenketten weisen in der Regel einen beschränkten zu erwartenden Zeichensatz auf.
Wird zum Beispiel in einem Formular der Name einer deutschen Automarke übergeben, sind ausschliesslich Buchstaben zu erwarten. Wird die Gross-/Kleinschreibung unterstützt, sind dies zwei Mal 24 Buchstaben des englischen Alphabets.
Bei ASCII (American Standard Code for Information Interchange) handelt es sich um eine 7-Bit-Zeichencodierung, welche durch klassische Computersysteme unterstützt wird. Die Zeichen umfassen das lateinische Alphabet in Gross- und Kleinschreibung, die zehn arabischen Ziffern sowie einige Satz- und Steuerzeichen. Sie werden dabei als eindeutiges Bitmuster abgelegt und lassen sich durch verschiedene Codierungen auswählen. So wird zum Beispiel dem Schriftzeichen A der dezimale Wert 65 bzw. der hexadezimale Wert 0x41 zugewiesen. Das Schriftzeichen B erhält 66 und 0x42 usw. Durch diese Zeichentabelle wird es möglich, dass eine einfache Eingrenzung auf einzelne Zeichenbereiche durchgesetzt werden kann:
function isinfected($notvalidated_input){
for($i=0; $i < strlen($notvalidated_input); $i++){
$symbol = ord(substr($notvalidated_input, $i, 1));
if($symbol < 65 || ($symbol > 90 && $symbol < 97) || $symbol > 123){
return true;
}
}
}
Die Implementierung symbol_validation.php von isinfected() macht sich diese Eigenschaft der ASCII-Tabelle zunutze. Durch die in Zeile 02 eingeführte for-Schleife wird jedes Zeichen der Eingabe durchgegangen. In Zeile 03 wird sodann durch die Funktion substr() das einzelne Zeichen separiert und mittels der Funktion ord() in die dezimale Darstellung des ASCII-Werts umgewandelt. Dieser wird sodann in die Variable $symbol abgespeichert.
Danach wird durch eine komplexe bedingte Anweisung geprüft, ob sich das extrahierte Symbol auch im vorgegebenen Wertebereich befindet. Ist der dezimale Wert des Zeichens kleiner als 65 bzw. grösser als 90 und kleiner als 97 bzw. grösser als 123, so ist ein unerwünschtes Zeichen gegeben. Im Bereich 65 bis 90 finden sich nämlich Grossbuchstaben und im Bereich 97 bis 122 sind Kleinbuchstaben angesiedelt. Alles andere sind entweder Ziffern, Sonderzeichen oder Steuerzeichen, die allesamt unerwünscht sind. Wird ein solches gefunden, wird die Funktion mit dem Rückgabewert true verlassen.
Die Eingabe von Mercedes würde also keine Infektion feststellen, da hier ein Grossbuchstaben sowie Kleinbuchstaben des englischssprachigen Alphabets verwendet werden. Ebenso sähe es mit Porsche und Audi aus. Wird jedoch als Automarke Dürkopp ausgewählt, führt dies zu einem Fehler. Denn der zweite Buchstabe ist ein kleingeschriebener Umlaut (ü), der von ASCII so nicht unterstützt wird und deshalb auch nicht im definierten Zeichenbereich vorkommen kann. Hierzu müsste auf den erweiterten ANSI-Zeichensatz ausgewichen werden, der ebenso regionale Sonderzeichen, wie eben die genannten Umlaute, unterstützt.
Eine solche Prüfung der Wertbereiche eignet sich besonders für das Validieren von Werten mit eingeschränktem Zeichensatz (Zahlenwerten oder Buchstaben des englischen Alphabets). Das Analysieren von Sonderzeichen ist nicht wirklich möglich, da sich diese relativ ungeordnet über die Tabelle verteilen. Zwar können mit 60 bis 62 etwaige Vergleichsoperatoren <, = und > deklariert werden. Doch die arithmetischen Grundoperatoren Addition (43), Subtraktion (45), Multiplikation (42) und Division (47) sind zum Beispiel nicht gruppiert worden.
Prüfung mittels Wertdefinitionen
Müssen neben den gruppierten Zahlenwerten und dem einfachen Alphabet ebenso Sonderzeichen unterstützt werden, sollte auf eine leicht abgewandelte Prüfung gesetzt werden. Hierbei wird grundsätzlich das Prinzip der arraygesteuerten Whitelist mit der Prüfung der Zeichenwerte kombiniert, wie am Beispiel von chars_inarray.php gezeigt werden soll:
function isinfected($notvalidated_input){
$allowedchars = array('a', 'b', 'c');
for($i=0; $i < strlen($notvalidated_input); $i++){
$symbol = substr($notvalidated_input, $i, 1);
if(!in_array($symbol, $allowedchars)){
return true;
}
}
}
Zu Beginn wird im eindimensionalen Array $allowedchars sämtliche erlaubten Zeichen abgelegt (Zeile 02). In diesem Beispiel sind dies exemplarisch die Buchstaben a, b, und c. Es können aber auch komplexere und längere Definitionen, welche zum Beispiel zur Beschreibung eines HTML-Tags erforderlich wären, eingesetzt werden. Auch hier kann der Übersichtlichkeit halber eine Trennung zwischen Logik und Daten vorgenommen werden, indem die Whitelist in einer separaten Datei wie whitelist.txt geführt und durch eine Funktion wie file() eingelesen wird.
Danach folgt die bekannte Extraktion der einzelnen Zeichen der Eingabe. Dabei werden die einzelnen Symbole durch die Funktion substr() in die Variable $symbol abgelegt (Zeile 05). Durch die schon zuvor vorgestellte Funktion in_array() wird nun geprüft, ob das untersuchte Zeichen im Array enthalten ist. Ist es nicht im Array enthalten, dies wird durch den durch das Ausrufezeichen definierten Not-Operator dargestellt, wird eine Infektion identifiziert und deshalb true zurückgeliefert.
Hierbei wird auf eine Umwandlung zum dezimalen ASCII-Wert mit ord() verzichtet. Es wäre zwar auch möglich, müsste jedoch sowohl beim Zugriff auf das Allowed-Array als auch bei der Extraktion des Zeichens aus der Eingabe durchgeführt werden. Die Zeichen werden stattdessen ohne Umwandlung in direkter Weise verglichen, was sowohl einfacher zu administrieren als auch effizienter bei der Ausführung ist.
Die Schwierigkeit dieses Ansatzes besteht darin herauszufinden, welche Zeichen innerhalb einer Eingabe legitim sind. Handelt es sich um Zahlenwerte, wie zum Beispiel bei der Angabe des Geburtsjahres, ist der Fall klar: Im Array müssen die zehn Ziffern 0-9 abgelegt werden. Werden jedoch komplexere Zeichenketten genutzt, wie zum Beispiel die Angabe eines Namens, können ebenfalls regionale Sonderzeichen (z.B. é bei französischen Namen) zum Einsatz kommen.
Die Anwendung muss also während der Entwicklung einem umfangreichen Testing unterzogen werden, um all diese Spezialfälle zu erkennen und die Funktion damit trainieren zu können. In hochsicheren Umgebung kann dies am besten so gemacht werden, indem eine rudimentäre Implementierung mit den wichtigsten Zeichen in der Whitelist bereitgestellt wird. Jedes Mal, wenn jedoch eine Infektion identifiziert wird, da das geprüfte Zeichen in der Whitelist nicht enthalten ist, wird eine Meldung an den Entwickler geschickt. Dieser kann sodann sofort entscheiden, ob es sich wirklich um ein legitimes Symbol, dessen man sich noch nicht bewusst war, handelt und es entsprechend in die Liste der erlaubten Zeichen hinzufügen. Je länger dieser Benachrichtigungsprozess geführt wird, desto besser wird die Funktionsweise der Anwendung, ohne deren Sicherheit zu verringern.
Der Einfachheit halber wird hier gerne mit dem Blacklisting-Ansatz gearbeitet. Dabei werden in das Array die nicht erlaubten Zeichen geschrieben. Die abgebildete Tabelle zeigt die jeweiligen Sonderzeichen und ihren Nutzen innerhalb einer technischen Attacke auf. Bei mit Rot markierten Feldern handelt es sich um wichtige und deshalb oft anzutreffende Angriffskatalysatoren. Die als Orange dargestellten Markierungen zeigen etwaige Erweiterungen oder als experimentell geltende Ansätze.
Partielle Prüfungen bei Zeichenketten
Zu Beginn wurde die absolute Prüfung von Eingaben vorgestellt: Entspricht eine Eingabe nicht dem Erwarteten, wird sie als infiziert betrachtet. Danach wurde eine dedizierte Prüfung einzelner Symbole besprochen: Findet sich in einer Eingabe ein unerwartetes Symbol, wird sie ebenfalls als infiziert verstanden.
Leider sind Eingabeüberprüfungen nicht immer in einer derartig einfachen Weise durchzusetzen. So gibt es Situationen, in denen Sonderzeichen erlaubt sind und andere Situationen, in denen sie eine Gefahr darstellen können. Zum Beispiel sind die Verhältniszeichen < (kleiner als) und > (grösser als) innerhalb mathematischer Betrachtungen durchaus legitim. So könnte in einem Foren-Posting zur Besprechung reeller Zahlen die erlaubte Zeichenkette 3.14 < 3.15 vorkommen.
Hingegen werden die genannten Sonderzeichen ebenfalls zur Definition von HTML-Tags, welche wiederum wichtiger Bestandteil von Cross Site Scripting-Attacken sein können, zum Einsatz kommen. Ist im Foren-Posting zum Beispiel die Zeichenkette <script>alert('xss');</script> enthalten, muss mit einem solchen Angriff gerechnet werden. Die Zeichen < und > erhalten dabei also aufgrund ihrer Meta-Funktionalität innerhalb von HTML eine gänzlich andere Bedeutung.
Durch die Prüfung von ganzen Zeichenketten soll es nun möglich werden, die Bedeutung derer zu erahnen und damit richtig zu reagieren. Betrachtet man sich die beiden Zeichenketten 3.14 < 3.15 (gutartig) und <script>alert('xss');</script> (bösartig), so fällt auf, dass die Sonderzeichen innerhalb einer speziellen Struktur zum Tragen kommen. Im erlaubten Fall wird das Zeichen eigenständig zwischen zwei Zahlenwerte gesetzt. Im unerwünschten Fall wird der Tag <script> hingegen durch die abgewandelte Darstellung </script> wieder abgeschlossen. Ohne diesen abschliessenden Tag würde der gesamte HTML-Tag nicht funktionieren. Wird also in einer Eingabe die reservierte Zeichenkette </ verwendet, muss es sich um einen abschliessenden HTML-Tag und damit um einen potentiellen Angriff handeln.
Wie gehabt soll nun in der speziellen Fassung von isinfected() im Array $disallowedstrings die unrlaubten Zeichenketten abgelegt werden (Zeile 02). Neben dem schon erklärten </ zur Identifikation von abschliessenden HTML-Tags soll zum Beispiel ebenfalls die Zeichenkette ../ sowie das Wort etc verboten werden. Ersteres ist das übliche Zeichen, welches für eine klassische Directory Traversal-Attacke eingespannt wird. Und zweiteres ist in Unix-Umgebungen das Standardverzeichnis für Konfigurationsdaten (z.B. Benutzerpasswörter), welches zusätzlich geschützt werden soll.
Die effektive Prüfung findet mit der neue vorgestellten Funktion strpos() statt. Diese erwartet zwei Parameter. Der erste ist der Ursprungswert, der analysiert werden soll. Der zweite sind die Zeichenketten, die gesucht werden sollen. Wird die gesuchte Zeichenkette in den Originaldaten gefunden, wird die Position des ersten Treffers zurückgegeben. Wird also die Zeichenkette Ruef in der Zeichenkette Marc Ruef gesucht, liefert strpos() den Wert 5 zurück. Schliesslich beginnt Ruef an der fünften Stelle. Wird hingegen Marc gesucht, liefert die Funktion den Wert 0 zurück, da dieser an der nullten Stelle gefunden wurde. Und wird Test gesucht, liefert die Funktion den boolschen Wert false zurück.
Ist die unerwünschte und gesuchte Zeichenkette in der Eingabe nicht enthalten, liefert sowohl strpos() als auch isinfected() den Wert false zurück. Konnte hingegen eine Infektion festgestellt werden, da die gesuchte Zeichenkette an einer bestimmten Position ausgemacht werden konnte, wird true zurückgegeben.
function isinfected($notvalidated_input){
$disallowedstrings = array('../', 'etc', 'script', '</');
if(strpos($notvalidated_input, $disallowedstrings) === false){
return false;
}else{
return true;
}
}
Je nach Implementierung von strpos() kann sich das Verhalten natürlich ändern. Die hier gezeigte Fassung definiert die erste Stelle eines Hits mit dem Integerwert 0. Andere Implementierungen könnten mit dem Zählen bei 1 beginnen und beim Nichtauftreten der Zeichenkette den reservierten Wert 0 anstelle false zurückgeben. Es ist also sehr wichtig zu wissen, wie die genutzte Funktion arbeitet, um keine fehlerhaften Entscheidungen treffen zu lassen. Aus diesem Grund wird hier auch der typensichere Vergleich mit dem speziellen Operator === anstelle des simplen == durchgeführt. Würde letzterer eingesetzt werden, wäre auch das Auftreten an Position 0 von PHP als false gewertet und würde dann zu fehlerhaften Zulassungen infizierter Daten führen.
Dieser Ansatz scheint sehr komfortabel zu sein, da man in übersichtlicher Weise seine Blacklist pflegen und spezielle Situationen als solche Deklarieren kann. Tatsächlich handelt es sich hier jedoch um die unsicherste Methode überhaupt. In der Blacklist müssen schliesslich sämtliche gefährlichen Zeichenkombinationen abgespeichert werden. Es ist jedoch nahezu unmöglich alle Muster, wie sie in einem Angriff Verwendung finden können, zu kennen und adequat zu dokumentieren.
Im genannten Beispiel wird etc dokumentiert, um pausch alle Zugriffe auf das Systemverzeichnis von Unix-Systemen zu verhindern. Möchte man jedoch auch noch die anderen Standardverzeichnisse berücksichtigen, wächst die Blacklist explosionsartig an. Sodann müssten ebenfalls bin, home, lib, sbin, tmp und var hinzugefügt werden. Da voraussichtlich also sowieso alle Verzeichnisse aufgenommen werden wollen, sollte besser eine Whitelist (in diesem absoluten Fall wäre sie wohl leer) eingesetzt werden.
Desweiteren gibt es oftmals Abwandlungen bekannter Angriffsmuster, die zu gleichen oder vergleichbaren Resultaten führen können. Zwar wird im Beispiel die Zeichenkette script definiert, um klassisches Cross Site Scripting mit eben diesem Tag zu verhindern. Javascript lässt sich aber auch extern referenzieren, als Event-Handler eines bestehenden Tags nutzen (z.B. <a href="test.html" onMouseOver="alert('xss');">Link</a>) oder durch andere Schreibweisen (z.B. <ScRiPt>) oder gar Codierungen deklarieren.
Zusammenfassung
Eingabeüberprüfungen sind zentraler Bestandteil der Sicherheit von Computersystemen. Durch die Validierung der an eine Software übergebenen Daten soll verhindert werden, dass diese den Anforderungen widersprechen und damit die korrekte Ausführung verhindern.
Dabei kann die Prüfung entweder mit einer Whitelist oder mit einer Blacklist umgesetzt werden. Auf einer Whitelist werden sämtliche Daten, welche legitim und deshalb zugelassen sind, aufgenommen. Nur wenn eine Eingabe diesem Kriterium, welches sich mit der Gästeliste einer Party vergleichen lässt, erfüllt, werden die Daten im regulären Zyklus weiterverarbeitet. Da dieser Ansatz sehr exakt arbeitet und keine Ausnahmen kennt, gilt er als der sicherste.
Jenachdem ist es jedoch nicht möglich von vornherein zu definieren, welche Daten erwartet sind. Zum Beispiel dann, wenn freie Textfelder (z.B. bei Foren-Posts) angeboten werden wollen. Dann lässt sich alternativ auf einen Blacklist-Ansatz setzen, bei dem verbotene Eingaben dokumentiert sind. Entspricht ein Datensatz einem solchen, wird der Zugriff verweigert. Bleibt eine Übereinstimmung aus, wird von einem legitimen Zugriff ausgegangen und die Ausführung weitergeführt. Das Problem hierbei ist, dass sich eine Blacklist nicht umfangreich und zeitnah verwalten lässt. Oftmals gibt es eine Vielzahl an abgewandelten Angriffsmustern (z.B. alternative Schreibweise oder Codierung), die durch eine starre Blacklist-Überprüfung nicht erkannt werden können.
► 08.09.2011 – Vortrag zu Real World Attacks
Die Kalaidos Fachhochschule Schweiz bietet im Rahmen Ihres Studiengangs Bachelor of Arts FH in Business Information Technology auch fachliche Informationen zum Thema Informatik Sicherheit an. Zu diesem Anlass wurde am 27. August 2011 Herr Stefan Friedli der scip AG eingeladen, ein Referat zum Thema Real World Attacks zu halten.
Die Präsentation drehte sich dabei primär um prominente Beispiele von Angriffen in den letzten 20 Monaten, wie zum Beispiel die Angriffe der Gruppe Lulzsec auf Sony oder auch die Kompromittierung der US-amerikanischen Sicherheitsfirma HBGaryFederal im vergangenen Frühjahr. Anhand konkreter Abläufe und Beispiele wurde dabei aufgezeigt, wie Risiken eingeschätzt und antizipiert werden können – oder zumindest sollten.
Die scip AG, vertreten durch Herrn Friedli, möchte sich für das Engagement der teilnehmenden Studenten und die lebhafte Diskussion bedanken und freut sich, das eine oder andere Gesicht im Rahmen unserer Tätigkeit wiederzusehen.
Stefan Friedli | G+ (154 Wörter)
► 02.09.2011 – Vortrag zu Cybercrime
Am 26. August 2011 fand die Fachtagung BVM der Schweizerischen Versicherungsgesellschaft statt. Im Auditorium des Hotel Hilton in Basel wurde einen Tag lang zum Thema Versicherungsbetrug referiert. Mitunter wurde dabei durch uns einen Vortrag mit dem Titel Cybercrime – Verbrechen im Informationszeitalter gehalten.
Die rund 100 Zuhörer stammten grösstenteils aus der Versicherungsbranche oder artverwandten Bereichen, in denen Betrugsaufklärung von Wichtigkeit ist. Zum Beispiel hatte ich die Möglichkeit mich ebenfalls mit einigen Juristen, Polizisten und technischen Sachverständigern zu unterhalten. Dabei konnte ich mitunter interessante Einsichten in das Thema Brandermittlung und IV-Betrug gewinnen.
Der erste Vortrag des Tages beschäftigte sich mit dem Umgang einer an dieser Stelle nicht näher zu nennenden Staatsanwaltschaft in Bezug auf Wirtschaftsdelikte. Dabei war es interessant zu hören, welche Prozesse angegangen und wie die vernetzten Zusammenarbeit mit Polizei und Versicherungen abläuft. Juristische Hintergründe sind bei einer erfolgreichen Betrugsaufklärung stets von zentraler Wichtigkeit.
An zweiter Stelle referierte Dr. med. Thomas Knecht. Seinerseits zuständig für forensische Psychiatrie an der Psychiatrische Klinik Münsterlingen bemühte er sich darum aufzuzeigen, inwiefern sich Täter von Wirtschaftsdelikten analysieren und kategorisieren lassen. Dabei spielt Narzissmus und Machiavellismus, dies wurde in verschiedenen Studien nachgewiesen, eine zentrale Rolle.
Nach der Mittagspause erläuterte Urs Zeiser das Prinzip der Körperssprache. Der ebenfalls aus verschiedenen Fernsehauftritten bekannte Analyst zeigte dabei an Fotos und Videobeispielen auf, welche Merkmale die Absichten und Hintergründe einer Person offenlegen lassen.
Danach folgte der Vortrag von Marc Ruef zum Thema Cybercrime. Dabei wurde anhand von zwei Fallbeispielen aufgezeigt, welche ermittlungstechnischen Möglichkeiten bestehen, um Wirtschaftskriminelle und Versicherungsbetrüger zu überführen.
Der letzte Vortrag des Tages beschäftigte sich mit Betrug im Transportwesen. Dabei wurde gezeigt, inwiefern sich Transporte und Ladungen manipulieren lassen, um Verluste und Diebstahl vorzutäuschen und damit Ersatzzahlungen zu erschleichen. Anhand verschiedener Beispiele – mitunter der sogenannten Reifen-Mafia – wurden konkrete Vorgehensweisen besprochen.
Einige der Präsentationen werden auf der Webseite des Schweizerischen Versicherungsverbands zum Download angeboten.
► 29.08.2011 – Blog Digest August 2011
- 11 Security Tips for Online Social Networking (04.08.2011), blog.zeltser.com
- CIA (01.08.2011), xkcd.com
- Circumventing malware detection (26.08.2011), norman.com
- Digital Hit Men for Hire (01.08.2011), BrianKrebs, KrebsOnSecurity
- Educating Users to Prevent Phishing Attacks (21.08.2011), blog.securestate.com, useful suggestions
- FLAMING RETORT: Hacktivism, hacking and hackers – what do these words really mean? (09.08.2011), Paul Ducklin, GrahamCluleysBlog
- Fuzzing at scale (12.08.2011), Jay, GoogleOnlineSecurityBlog
- Gartner on Vulnerability Assessment (25.08.2011), Aviram, blogs.securiteam.com
- How Antivirus Vendors Describe Their Cloud Capabilities (17.08.2011), blog.zeltser.com
- How Did You Get to that Number? (13.08.2011), Brad Arkin, blogs.adobe.com
- How to find 0-day in browsers (15.08.2011), abazhanyuk.com, nice introduction
- How to find unwanted files on workstations (15.08.2011), isc.sans.edu
- Integrating Nessus with BackTrack 5’s Tools (04.08.2011), Paul Asadoorian, blog.tenablesecurity.com
- John The Ripper Hash Formats (06.08.2011), pentestmonkey
- Local Session Snooping in PHP (10.08.2011), Haxxorse, interesting proof-of-concept
- Logs – The Foundation of Good Security Monitoring (22.08.2011), isc.sans.edu
- Metasploit Framework 4.0 Released! (01.08.2011), egypt, metasploit
- Mitigation of Apache Range Header DoS Attack (24.08.2011), Ryan Barnett, SpiderlabsAnterior
- New Attack on AES (18.08.2011), schneier, schneier.com
- Password joke named funniest at Edinburgh Fringe (25.08.2011), Graham Cluley, GrahamCluleysBlog
- Password Strength (10.08.2011), xkcd.com, reality is funny and sad :)
- Penetration Testing in the Cloud (12.08.2011), Aaron Bryson, blogs.cisco.com
- Ping is Bad (Sometimes) (08.08.2011), isc.sans.edu
- Smartphone jiggles reveal your private data (17.08.2011), newscientist.com, interesting research
- Theoretical and Practical Password Entropy (10.08.2011), isc.sans.edu
- Validity of most-common-password lists (18.08.2011), Robert Graham, erratasec.blogspot.com
- Which Apps Are Authorized to Access Your Social Networking Accounts? (04.08.2011), blog.zeltser.com
- Writing Meterpreter Extensions (28.08.2011), scriptjunkie, scriptjunkie.us
- [RFC] Vulnerability library proposal (07.08.2011), seclists.org, based on our research at @scipag
► 25.08.2011 – Las Vegas 2011
Etwa 39 Millionen Besucher zählt die Stadt Las Vegas in der Mitte der Wüste von Nevada. Die meisten von ihnen kommen wegen der Kasinos, der Shows – vielleicht noch der geographischen Nähe zum imposanten Grand Canyon. Meistens zumindest, denn jeden Sommer wird Las Vegas zum Schmelztiegel der Security Industrie.
Die Konferenzen SecurityBSides, BlackHat und DEFCON finden seit Jahren jährlich in der Hitze der Unterhaltungsmetropole statt und ziehen jährliche Tausende von Besuchern an. Die DEFCON konnte dieses Jahr einen Besucherrekord von knapp 15000 Besuchern (inkl. Tagesgästen) verbuchen, die BSidesLV war bereits Wochen vor dem Event restlos ausverkauft und auch die BlackHat verbuchte – trotz bewusst hohem Ticketpreis – solide Zahlen.
Auch die scip AG war vor Ort und hat sowohl in teilnehmender als auch in referierender Funktion an den Konferenzen teilgenommen. Einige Highlights sollen deshalb hier in kurzer Form Erwähnung finden.
Die höchste Antizipation fand dieses Jahr wohl die BSidesLV, die zum ersten Mal im (komplett gemieteten) Artisan Hotel stattfand. Die Herausforderung, eine kostenlose Alternative zur BlackHat anzubieten, wurde dabei vom Organisationsteam mit Hilfe von Sponsoren und solider Planung ausserordentlich gut gelöst. Manch einer kam zum Schluss, dass der Content an der BSidesLV überblickend problemlos mit der, massiv teureren, BlackHat mithalten kann und diesen – natürlich abhängig vom persönlichen Geschmack – sogar übertrumpfen mag.
Einer der Höhepunkte der BsidesLV war der Auftritt von Peiter “Mudge” Zatko, dem ehemaligen L0pht Mitglied, das heute in der Bundesbehörde DARPA das Bindeglied zwischen Fed und der Hackercommunity darstellt. Seine Präsentation drehte sich dementsprechend auch um diese Kooperation zwischen Regierung und Sicherheitsexperten aus der Community, speziell Hacker- und Makerspaces. Während manch einer den “alten” Mudge, der nicht für eine Regierungsbehörde arbeitet, wohl als nahbarer empfand, war der Inhalt des Vortrags durchaus interessant und, vor allem für US-basierte Spezialisten, sicher auch von solidem Informationswert.
Zeitgleich zum Vortrag von scip Mitarbeiter Stefan Friedli, präsentierte HD Moore eine neue Version des Wardialing Tools WarVox, das nun direkt in Metasploit integriert wird. So verfügt Metasploit jetzt quasi über einen kompletten VoIP Stack, was so manchem Pentester durchaus gelegen kommen dürfte.
Zur selben Zeit wurden an der BlackHat die Pwnie Awards verliehen. Der Preis, der oftmals als “Security Oscar” bezeichnet wird, wird jährlich in verschiedenen Kategorien vergeben. Der Preis für die beste Server-Side Vulnerability ging an Juliano Rizzo und Thai Duong für das ASP.NET Framework Padding Oracle. Für die beste Client-Side Schwachstelle durfte Comex, bekannt für die Webseite jailbreakme.com den Preis entgegennehmen.
Den Negativ-Award für die schlechteste Vendor Response ging, wenig überraschend, an RSA. Und auch der Preis in der Kategorie “Most Epic Fail” überraschte wenig: Sony gewann mit Abstand, was allerdings bei einem guten Dutzend Nominationen auch niemanden wundern dürfte.
Innotivative Research zeigte auch Ian Amit von der israelischen Consultingfirma Security Art. Mittels verschiedener technischer Mittel, zeigte Ian auf, wie Daten auf unkonventielle Art aus Netzwerken mit stark reduzierter Konnektivität extrahiert werden können. Dabei nutzte er unter anderen VoIP, um Daten als Sound-encondiert über eine Telefonverbindung zu extrahieren. Oder sogar physische Ausgabeformate (z.B. Drucker) in Verbindung mit OCR zur Wiederherstellung der Daten.
Ebenfalls unter der Kategorie “innovativ” zu werten, war der mutmassliche MitM Angriff auf CDMA und 4G Netze, der gerüchteweise während der gesamten Dauer der Konferenz stattfand. Während konkrete Beweise hier immer noch fehlen, häufen sich die Hinweise dass hier tatsächlich eine grossangelegte Attacke stattgefunden hat. Only in Vegas…
Wer dieses Jahr nicht live dabeisein konnte, für den gibt es traditionell die Recordings auf DVD zu erwerben. Materialen zu allen Präsentationen sind in der Regel online via Google auffindbar. Wer ungern weit fliegt, aber dennoch die neuste Research im IT-Sicherheitsbereich live präsentiert sehen möchte, dem sei an dieser Stelle die hashdays Konferenz im Oktober 2011 in Luzern ans Herz gelegt.
Stefan Friedli | G+ (684 Wörter)
► 18.08.2011 – Einführung in httprecon
Das Projekt httprecon wurde im Jahr 2007 gestartet. Hierbei handelt es sich um ein Forschungsprojekt, welches sich mit dem Identifizieren von Webserver-Implementierungen über das Netzwerk auseinandersetzt. Durch das sogenannte HTTP-Fingerprinting soll das eingesetzte Produkt identifiziert werden, wodurch zielgerichtete Attacken angestrebt werden können.
Die Windows-Implementierung von httprecon stellt nach dem Aufstarten eine grafische Oberfläche zur Verfügung. Auf dieser kann der Hostname oder die IP-Adresse des Zielsystems definiert werden. Dabei kann zwischen HTTP und HTTPS umgeschaltet und der Zielport ausgewählt werden.
Durch das Drücken des Analyze-Button wird eine Verbindung zum Ziel aufgebaut. Diesem werden verschiedene HTTP-Anfragen geschickt und die Rückantworten ausgewertet. Dabei werden standardmässig die folgenden neun Anfragen genutzt:
| Anfrage | Beschreibung | Intrusiv | |
|---|---|---|---|
| 1. | GET / HTTP/1.1 |
Normale GET-Anfrage für existente Ressource | nein |
| 2. | GET /aaa(...) HTTP/1.1 |
Lange GET-Anfrage | ja/nein |
| 3. | GET /404test.html HTTP/1.1 |
GET-Anfrage für nicht-existente Ressource | nein |
| 4. | HEAD / HTTP/1.1 |
Normale HEAD-Anfrage für existierende Ressource | nein |
| 5. | OPTIONS / HTTP/1.1 |
Normale OPTIONS-Anfrage für existierende Ressource | nein |
| 6. | DELETE / HTTP/1.1 |
Normale DELETE-Anfrage für existierende Ressource | ja |
| 7. | TEST / HTTP/1.1 |
HTTP-Anfrage für nicht-existierende Methode | nein |
| 8. | GET / HTTP/9.8 |
HTTP-Anfrage mit nicht-existierender Protokoll-Version | nein |
| 9. | GET [attack] HTTP/1.1 |
GET-Anfrage mit Angriffsstruktur (XSS, SQLi) | ja/nein |
Die Antworten werden dann auf verschiedene Merkmale hin untersucht. Dazu gehören in erster Linie:
- Statusinformationen
- Protokollname
- Protokollversion
- Statuscode
- Statustext
- Header-Werte
- Accept-Range
- Banner
- Cache-Control
- Connection
- Content-Type
- Options-Allowed
- Options-Public
- Pragma
- X-Powered-By
- Header-Struktur
- Header-Reihenfolge
- Header Grossschreibung nach Bindestrich
- Header Leerzeichen nach Aufzählung
- ETag-Quotes
- ETag-Länge
- Options-Trennzeichen
- Vary-Grossschreibung
- Vary-Trennzeichen
- Vary-Reihenfolge
Anhand dieser Merkmale wird quasi ein Fingerabdruck der Webserver-Implementierung erstellt und diese mit der lokalen Fingerabdruck-Datenbank von httprecon verglichen. Dadurch lässt sich derjenige Fingerabdruck mit der grösstmöglichen Übereinstimmung ausmachen und dadurch das eingesetzte Produkt identifizieren. Die Übereinstimmungen werden in einer Liste samt Details ausgewiesen. Weitere Informationen zur Architektur der Lösungen finden sich auf der Projekt-Webseite.
Durch die erweiterten Konfigurationseinstellungen kann das Verhalten von httprecon den eigenen Bedürfnissen angepasst werden. Zum Beispiel lassen sich die einzelnen Testzugriffe deaktivieren oder deren Attribute verändern (z.B. Zugriff auf welche Ressourcen, Nutzen welcher Methoden). Zusätzlich können neue Webserver-Implementierungen oder Abweichungen bestehender Einträge einfach in die bestehende Datenbank hinzugefügt werden. Dadurch lässt sich die eigene Datenbank beständig erweitern und optimieren. Am Schluss der Analyse können die Resultate in einen Report exportiert und damit im Rahmen einer professionellen Sicherheitsüberprüfung berücksichtigt werden.
► 11.08.2011 – Social Media Strategie der scip AG
Als Beratungsunternehmen ist es für uns wichtig die Dinge, zu denen wir referieren, auch zu verstehen. Das Thema Social Media ist dabei den letzten Jahren zu einem zentralen Bestandteil moderner Informationssicherheit für Unternehmen und Personen geworden. So verfolgen dann auch wir eine entsprechende Strategie, um mit den neu erschliessbaren Kommunikationsmöglichkeiten umgehen zu können.
Unter Social Media verstehen wir interaktive Dienste, mit denen wir mit potentiellen oder bestehenden Kunden interagieren können. Dies kann Bereitstellung von News zum Unternehmen oder Produkteinformationen beinhalten. Es kann aber auch zu einem interaktiven Dialog kommen, der eine Beratung ergänzen oder teilweise ersetzen kann.
In erster Linie gebrauchen wir Soziale Netzwerke, um Neuentwicklungen und Neuveröffentlichungen aus unserem Haus zu verbreiten. Sowohl auf Twitter als auch auf Facebook pflegen wir deshalb unsere News und Blog-Posts zu veröffentlichen. Damit wird es für Interessenten möglich, sich auf verschiedenen Wegen über die aktuellen Geschehnisse zu informieren.
Dabei agieren wir Lösungsgerecht. Dies bedeutet, dass auf Twitter wirklich nur sehr kurze News mit einem entsprechenden Link zur vollen Meldung auf der Webseite veröffentlicht werden. Auf Facebook werden hingegen auf der Unternehmensseite die gesamten Meldungen bereitgestellt. Interaktivität mit Benutzern kommt nur bei Bedarf durch sie, zum Beispiel bei konkret an uns gerichtete Fragen, zustande.
In Business Netzwerken, wie zum Beispiel Xing, sind wir mit einer kleinen Unternehmensseite vertreten. Dies ermöglicht einerseits die unternehmensinterne Kommunikation auf diesen Plattformen. Zeitgleich wird damit auch eine zentrale Anlaufstelle für Kontakte geschaffen. Auf eine Veröffentlichung von Unternehmensmitteilungen oder die Interaktivität mit dem Unternehmen als Ganzes wird dabei weitestgehend verzichtet. Nur vereinzelt pflegen unsere Mitarbeiter interessante Mitteilungen zu übernehmen.
Da wir als Firma damit in verschiedenen Sozialen Netzwerken vertreten sind, pflegen wir unsere Mitarbeiter zu ermuntern, sich ebenfalls auf diesen aktiv zu betätigen. Es ist deshalb nicht unüblich, dass – gerade unsere technischen Mitarbeiter – auf den verschiedenen Plattformen vertreten sind. Auf Xing und LinkedIn werden in der Regel Geschäftskontakte gepflegt. Dabei wird angehalten, ein Höchstmass an Diskretion bezüglich Kunden und Projekten zu wahren.
Der hauptsächliche Informationsaustausch zwischen internationalen Sicherheitsexperten findet dabei in erster Linie über Twitter statt. Unsere Mitarbeiter sind jeweils darum bemüht, ein möglichst umfangreiches Netzwerk an Spezialisten aufzubauen. Das Weiterreichen von Forschungsergebnissen oder Rückfragen bei speziellen Problemstellungen werden damit besonders effizient gelöst.
Aus diesem Grund verzichten wir auf das Einschränken der Zugriffsmöglichkeiten auf Soziale Netze. Einzig eine sicherheitstechnische Überwachung, um etwaige Angriffe und Schadcode frühzeitig erkennen und neutralisieren zu können, kommen bei uns zum Einsatz. Mit dieser offenen Strategie zeigen wir unseren Mitarbeitern, dass wir ihre Eigenständigkeit respektieren und ihr aktives Mitgestalten schätzen. Diese Vertrauensbasis hat sowohl für uns als Arbeitgeber als auch für unsere Mitarbeiter nur Vorteile schaffen können. Weitere Informationen hierzu finden sich in unserer Präsentation zur Sicherheit in Sozialen Netzen.
► 04.08.2011 – Effizientes Portscanning mit Porteinschränkungen
Sicherheitsüberprüfungen vernetzter Computersysteme hat oftmals als Grundlage das Identifizieren und Analysieren der angebotenen Dienste. Um Dienste erkennen zu können, wird die klassische Technik des Portscanning verwendet. Dabei wird eine Software eingesetzt, die sich versucht automatisiert auf die möglichen Zielports zu verbinden. Kommt eine solche Verbindung zustande bzw. wird sie nicht abgewiesen, dann wird von einem offenen Port und damit einem angebotenen Dienst ausgegangen.
Bei einem vollumfänglichen Scan für die beiden Transportprotokolle TCP und UDP werden jeweils 2^8=65’536 mögliche Ports überprüft. Der Zeitaufwand für eine solche Analyse ist – vor allem bei verbindungslosem UDP – dementsprechend zeitintensiv. Um die Wirtschaftlichkeit entsprechender Analysen aufrecht erhalten zu können, wird sich oftmals auf das Prüfen der wichtigsten Ports geeinigt und damit unpopuläre Portbelegungen ausgelassen.
Was nun ein populärer Port ist, darüber lässt sich streiten. Allgemein gesehen ist eine Portbelegung dann populär, wenn sie statistisch signifikant vertreten ist. Beispielsweise finden sich im Internet eine Vielzahl an Rechnern, die einen Webserver auf dem Standardport tcp/80 anbieten. Dies ist voraussichtlich ein populärer Port im Internet.
Das bekannte Scanning- und Auswertungsutility Nmap bietet seit 2006 den Parameter --top-ports <n> an, um lediglich die n populärsten Ports zu prüfen:
Scans the
highest-ratio ports found in nmap-services file. must be 1 or greater.
Dabei wird auf eine flache Datenbank der Portstatistiken, sie wird in der Datei nmap-services bereitgestellt, zurückgegriffen. In einer separaten Spalte wird die Auftretenswahrscheinlichkeit eines Ports in Prozent angegeben. Der populärste Port ist beispielsweise tcp/80 (http) mit einer Auftretenswahrscheinlichkeit von 0.484143%. Die nachfolgende Grafik zeigt die Abstufung der Auftretenswahrscheinlichkeit der 25 populärsten Ports (aus nmap-5.59BETA1.tar.bz2).
Nach wie vor stellt sich nun die Frage, wieviele der populärsten Ports bei einem Scan miteinbezogen werden sollen. Wird auf eine explizite Angabe mit --top-ports verzichtet, dann pflegt Nmap einfach die 1.000 populärsten Ports zu prüfen. Betrachtet man diese Werte etwas genauer, dann erkennt man das Gefälle mit der Abnahme der weniger populären Ports. Dadurch kann man nun eine Zusammenfassung der jeweils wichtigsten Ports zu den Gruppen Top3, Top7, Top16, Top24, Top29 und Top36 zusammenfassen. Dies sind also jene Abstufungen, die statistisch am ehesten Sinn machen.
| Dienst | Proto | Port | Auftreten | Top3 | Top7 | Top16 | Top24 | Top29 |
|---|---|---|---|---|---|---|---|---|
| http | tcp | 80 | 0.484143% | 1 | ||||
| ipp | udp | 631 | 0.450281% | 2 | ||||
| snmp | udp | 161 | 0.433467% | 3 | ||||
| netbios-ns | udp | 137 | 0.365163% | 4 | ||||
| ntp | udp | 123 | 0.330879% | 5 | ||||
| netbios-dgm | udp | 138 | 0.297830% | 6 | ||||
| ms-sql-m | udp | 1434 | 0.293184% | 7 | ||||
| microsoft-ds | udp | 445 | 0.253118% | 8 | ||||
| msrpc | udp | 135 | 0.244452% | 9 | ||||
| dhcps | udp | 67 | 0.228010% | 10 | ||||
| telnet | tcp | 23 | 0.221265% | 11 | ||||
| domain | udp | 53 | 0.213496% | 12 | ||||
| https | tcp | 443 | 0.208669% | 13 | ||||
| ftp | tcp | 21 | 0.197667% | 14 | ||||
| netbios-ssn | udp | 139 | 0.193726% | 15 | ||||
| ssh | tcp | 22 | 0.182286% | 16 | ||||
| isakmp | udp | 500 | 0.163742% | 17 | ||||
| dhcpc | udp | 68 | 0.140118% | 18 | ||||
| route | udp | 520 | 0.139376% | 19 | ||||
| upnp | udp | 1900 | 0.136543% | 20 | ||||
| smtp | tcp | 25 | 0.131314% | 21 | ||||
| nat-t-ike | udp | 4500 | 0.124467% | 22 | ||||
| syslog | udp | 514 | 0.119804% | 23 | ||||
| unknown | udp | 49152 | 0.116002% | 24 | ||||
| snmptrap | udp | 162 | 0.103346% | 25 | ||||
| ... | ||||||||
Bei reinen UDP-Scans, diese werden vorzugsweise sowieso eher in LANs angewendet werden, pflegen wir --top-ports 100 zu verwenden. Dadurch können wir auch populäre interne Dienste (z.B. Kerberos = Pos 88, Tacacs = Pos 86) sowie die Simple UDP Services (z.B. Echo = Pos 61, Discard = Pos 82) ausmachen. Bei TCP-Scans, die eine sehr hohe Performance benötigen, arbeiten wir in der Regel mit --top-ports 300, um auch hier teilweise eingesetzte Dienste erkennen zu können.
► 29.07.2011 – Blog Digest Juli 2011
- 4 Reasons Why Security Assessment Recommendations Get Ignored (05.07.2011), blog.zeltser.com
- 4 Tips for a Strong Executive Summary of a Security Assessment Report (30.06.2011), blog.zeltser.com
- Abusing Password Resets (11.07.2011), cktricky, carnal0wnage.attackresearch.com
- AppLocker for Containing Windows Malware in the Enterprise (21.07.2011), blog.zeltser.com
- ASP.Net 4: Change the Default Encoder (12.07.2011), James Jardine, software-security.sans.org
- Bitcoin Security Architecture: A Brief Overview (13.07.2011), blogs.cisco.com, nice summary
- Clickjacking – the practice of deceptively directing a… (11.07.2011), blog.zeltser.com
- Detecting probes through client-side filtering (20.07.2011), Chris John Riley, blog.c22.cc
- FFIEC finally releases new Guidance on Internet Banking Authentication; Better Late than Never (29.06.2011), Avivah Litan, blogs.gartner.com
- Great Cipher, But Where Did You Get That Key? (05.07.2011), David McGrew, blogs.cisco.com
- HTML 5 – XSSQL attack (11.07.2011), very interesting approach
- Javascript Obfuscation in Metasploit (08.07.2011), Egypt, metasploit.com
- Meterpreter HTTP/HTTPS Communication (29.06.2011), H.D. Moore, rapid7.com
- ModSecurity Advanced Topic of the Week: Mitigating Slow HTTP DoS Attacks (13.07.2011), Ryan Barnett
- ModSecurity SQL Injection Challenge: Lessons Learned (26.07.2011), Ryan Barnett
- Penetration testing for the home computer user (13.07.2011), Lee Munson
- Plug mouse into the computer – be compromised (01.07.2011), norman.com
- Reflections Upon Deception and Protean Security Tactics (08.07.2011), blog.zeltser.com
- So You Want to Hash a Password… (01.07.2011), deadliestwebattacks.com, great summary
- Staying undetected post-exploitation (28.07.2011), Esteban, resources.infosecinstitute.com
- Take a bow everybody, the security industry really failed this time (27.06.2011), David Maynor, erratasec.blogspot.com
- The Changing Landscape of Malware for Mobile Devices (13.07.2011), blog.zeltser.com
- The Marriage of Legal and IT (18.07.2011), blogs.rsa.com, study where itsec is pushed
- The science of password selection (18.07.2011), extraordinary research
- USB Fuzzing for the Masses (15.07.2011), labs.mwrinfosecurity.com, great howto
- Using data to protect people from malware (20.07.2011)
- When Bots Use Social Media for Command and Control (28.06.2011), blog.zeltser.com
- When Does a Suspicious Event Qualify as a Security Incident? (28.06.2011), blog.zeltser.com
► 21.07.2011 – Modell zur Umsetzung von Config Reviews
Im Rahmen verschiedener Sicherheitsüberprüfungen führen wir ebenfalls sogenannte Configuration Reviews durch. Bei diesen wird die Konfiguration einer Komponente auf ihre Sicherheit hin untersucht. Das Prinzip einer solchen Analyse sowie die einhergehenden Schwierigkeiten sollen in diesem Beitrag illustriert werden.
Gehen wir davon aus, dass ein nicht näher bestimmtes Router-Produkt untersucht werden soll. Dieses pflegt Konfigurationseinstellungen auf der Kommandozeile entgegenzunehmen. Beispielsweise wird folgendes Kommando verwendet, um eine Netzwerkschnittstelle zu konfigurieren:
Router> add interface -name=eth0 -state=ENABLED -icmp=ENABLED -mgmtAccess=DISABLED |
In gleicher Weise wird die persistente Konfiguration einer Konfigurationsdatei abgelegt, die auf die gleiche sequentielle Eingabe der unterschiedlichen Einstellungen zurückgreift. Dabei entspricht jede Zeile in der Konfiguration einer einzelnen Eingabe. Eine einzelne Eingabe weist dabei beispielsweise die folgende Struktur auf (die einzelnen Objekte werden zur Vereinfachung der Illustration voneinander getrennt dargestellt):
add interface |
-name=eth0 |
-state=ENABLED |
-icmp=ENABLED |
-mgmtAccess=DISABLED |
Solche Konfigurationseinstellungen sind bei verschiedenen Netzwerkprodukten im professionellen Sektor zu sehen. Bei add handelt es sich um ein Kommando, das verschiedene Argumente erwartet. Durch interface wird die neue Netzwerkschnittstelle hinzugefügt.
Dabei kommen nun verschiedene Parameter zum Tragen, welche eine Attributisierung des neu hinzuzufügenden Objekts zulassen. So wird mit dem Attribut -name der Name und mit -state=[ENABLED|DISABLED] der Status definiert. Zusätzlich wird mit -icmp=[ENABLED|DISABLED] die Unterstützung von ICMP-Kommunikationen und mit -mgmtAccess=[ENABLED|DISABLED] die Aktivierung des Zugriffs auf die Management-Schnittstelle spezifiziert.
addinterfacename=<name>state=[ENABLED|DISABLED]icmp=[ENABLED|DISABLED]mgmtAccess=[ENABLED|DISABLED]
Sicherheitstechnisch gesehen ist hierbei die Definition von -icmp bedenklich. Denn durch das Aktivieren dessen Unterstützung mit dem Wert ENABLED werden entsprechende protokollabhängige Angriffe möglich. Im Rahmen einer Config Review würde hier also besagte Einstellung beanstandet werden:
add interface |
-name=eth0 |
-state=ENABLED |
-icmp=ENABLED |
-mgmtAccess=DISABLED |
Um dieser Schwachstelle zu entgegnen, sollte ICMP deaktiviert werden, indem die Direktive -icmp=DISABLED zum Tragen kommt.
Viele Administratoren haben die Angewohnheit, in der Konfiguration nur jene Einstellung vorzunehmen, die sie explizit definieren wollen. Alle Einstellungen, die nicht zwingend beeinflusst werden sollen, werden ignoriert. Viele Produkte erfordern aber eine explizite Definition einer Einstellung und verwenden beim Ausbleiben einer solchen die durch den Hersteller vordefinierte Standardeinstellung. Diese sähe in diesem Fall wie folgt aus (der Standard ist durch geschweifte Klammern dargestellt):
add interface |
-name=eth0 |
-state={ENABLED} |
-icmp={ENABLED} |
-mgmtAccess={DISABLED} |
Dies bedeutet, dass wenn also eine der Parameter -state, -icmp oder -mgmtAccess nicht definiert ist, die Vorauswahl genutzt wird. In diesem Fall werden damit aber entsprechende Sicherheitsrisiken aufgetan, wenn auf die explizite Deaktivierung von ICMP verzichtet wird. Denn ohne eine Definition wird das Protokoll standardmässig unterstützt. (In diesem Beispiel weist -name keine Standardeinstellung auf. Die Angabe ist entsprechend nicht optional. Sie hat jedoch keinen Einfluss auf die sicherheitsbezogene Analyse. Wir würden ein Ausbleiben jedoch aus betrieblichen Gründen dokumentieren.)
Standardeinstellungen erschweren Config Reviews entsprechend ungemein. Denn man muss nicht nur um alle möglichen Einstellungen und die definierten Einstellungen wissen, sondern es müssen ebenfalls die abwesenden Einstellungen und ihre Standardwerte bekannt sein. Jenachdem ist es jedoch besonders aufwendig, diese Standardwerte ausfindig zu machen. Sollte der Hersteller keine Dokumentation diesbezüglich vorweisen können, muss durch eine praktische Analyse des Produkts der aktuelle Stand determiniert werden.
Der generische Ablauf einer umfassenden Config Review gestaltet sich entsprechend wie folgt (unabhängig von Produkt und Format der Konfigurationsdateien):
- Vorbereitungen
- Dokumentation aller Einstellungsmöglichkeiten
- Vermerk aller sicherheitsrelevanten Sicherheitseinstellungen
- Identifikation aller Standardeinstellungen bei optionalen/abwesenden Einstellungen
- Analyse
- Identifikation aller expliziten Einstellungen
- Identifikation aller abwesenden Einstellungen
- Ableitung der abwesenden Einstellungen zu ihren Standardeinstellungen
- Dokumentation
- Beschreibung aller gegebenen Fehleinstellungen (explizit definiert)
- Beschreibung aller fehlenden Fehleinstellungen (implizit abgeleitet)
Das Resultat einer Configuration Review eines Routing-Produkts könnte also folgendes Resultat zur Folge haben (Wir versuchen nach Möglichkeiten eine optische Darstellung von Fehleinstellungen bereitzustellen):
| Interface | State | ICMP | mgmtAccess |
|---|---|---|---|
eth0 |
ENABLED |
DISABLED |
DISABLED |
eth1 |
ENABLED |
ENABLED |
ENABLED |
eth2 |
DISABLED |
- | - |
eth3 |
DISABLED |
- | - |
Oftmals umfassen die zu untersuchenden Konfigurationsdateien mehrere hundert Zeilen mit einer Vielzahl an Anweisungen und expliziten bzw. impliziten Argumenten. Diese zu analysieren ist sodann mit einem sehr hohen Aufwand verbunden. Um die Effizienz sowie die Genauigkeit der Untersuchung zu verbessern, verwenden wir je nach Möglichkeit auf die zu untersuchenden Produkte zugeschnittene Parser (z.B. Cisco IOS/PIX/ASA, Nortel Alteon OS, Citrix Netscaler, etc.). Diese analysieren die Anweisungen und helfen entsprechend bei der Umsetzung der Schritte 2.1 bis 2.3.
Sicherheitsrelevante bzw. sicherheitskritische Objekte werden sodann gemeldet und einer manuellen Untersuchung durch den Fachspezialisten unterzogen. Dadurch kann einerseits eine hohe Verarbeitungsgeschwindigkeit (durch Automatisierung) aber auch eine umfassende Genauigkeit (durch manuelle Nachprüfung) gewährleistet werden.
► 14.07.2011 – Gedanken zum Tainted Mode in der Programmierung
Eines der Grundprinzipien von sicherheitsbezogenen Source Code Analysen basiert darauf, dass potentiell böswillige Daten erkannt und deren Verarbeitung geprüft wird. Als böswillig werden alle Daten verstanden, die aus einer nicht-vertrauenswürdigen Quelle stammen. In erster Linie sind dies Benutzereingaben, wie sie bei PHP-Skripten beispielsweise durch $_GET, $_POST, $_REQUEST, $_COOKIE und teilweise $_SERVER bereitgestellt werden. Derlei Daten werden in der englischen Literatur auch als infected, tainted, dirty, contaminated oder unclean bezeichnet.
In einer manuellen Analyse wird sodann mittels Program Slicing der Datenpfad der böswilligen Daten ermittelt. Lösungen wie codEX versuchen diese Arbeit – in diesem Fall gar sprachunabhängig – zu automatisieren. Dennoch ist immer ein gewisser Arbeitsaufwand erforderlich, um der Komplexität einer Sprache gerecht zu werden.
Manche Sprachen, allen voran Ruby und Perl, unterstützen einen sogenannten Taint Mode. Bei diesem kennzeichnet die Sprache ein Objekt als potentiell gefährlich und schränkt entsprechend die Weiterverarbeitung bei sicherheitskritischen Funktionen ein. Bei Ruby wird in der Variable $SAVE ein Wert zwischen 1 und 4 gespeichert, um als Save-Level den Grad der Einschränkungen zu bestimmen. Mit der Methode .tainted? kann sodann geprüft werden, ob ein Objekt restriktiv behandelt wird. Bei Perl 4 muss ein Skript mit /usr/local/bin/taintperl und bei Perl 5 mit /usr/local/bin/perl -T aufgerufen werden, um einen ähnlichen Effekt zu erzielen. Nachfolgende Tabelle zeigt die Einstufung durch Ruby:
| Level | Beschreibung |
|---|---|
| 0 | Es wird kein Einfluss durch den Tainted Mode ausgeführt. Dies ist die Standardeinstellung von Ruby. |
| >=1 | Es wird die Nutzung von Tainted Daten durch potenziell gefährliche Operationen verhindert. |
| >=2 | Es wird das Laden von Programm-Dateien von global beschreibbaren Orten verhindert. |
| >=3 | Alle neu erzeugten Objekte werden standardmässig als tainted markiert. |
| >=4 | Ruby teilt das Programm quasi in zwei Teile auf, wobei als tainted markierte Objekte nicht mehr verändert werden können. |
Sicherheitstechnisch interessant ist an diesem Konzept die Vererbung des Tainted-Status. Es stellt sich nämlich die Frage, inwiefern ein gesamtes Objekt oder Teile davon bei einer Übernahme in ein anderes/neues Objekt Einfluss auf den Status ausübt. Hierbei kann zwischen sieben verschiedenen Übernahmevarianten unterschieden werden:
| Übernahmetyp | Beispiel (PHP) |
|---|---|
| Komplett | $var2 = $var1; |
| Partiell | $var2 = substr($var1, 0, 1); |
| Indirekt | $vartmp = $var1; $var2 = $vartmp; |
| Manipuliert | $var2 = encode_entities($var1); |
| Konstruiert | $var2 = $var1."string\n"; |
| Berechnet | $var2 = $var1 * (1 + 2); |
| Typisiert | $var2 = intval($var1); |
Streng genommen bleibt bei jeglicher Übernahme der Tainted-Status bestehen und wird auf das neue Objekt vererbt. Dies ist natürlich nicht immer korrekt, denn so können beispielsweise Assertion, Typenumwandlungen und Encodierungen dabei helfen, grundlegende Angriffstechniken unwirksam werden zu lassen. Dennoch bleibt es in diesem Zusammenhang die Aufgabe des Programmierers, dass er die betroffenen Objekte manuell untainted. Der Tainted Mode ist damit nicht nur eine technische Stütze bei der Entwicklung, sondern auch eine psychologische Hilfe bei der Qualitätssicherung.
In jedem Fall ist die Nutzung eines solchen zu empfehlen und damit auch in anderen Sprachen – allen voran PHP (Vorschlag auf der PHP-Mailingliste) – wünschenswert. PHP hatte zwar mit dem safe_mode eine ähnliche Funktion eingeführt, dabei jedoch das Pferd rückwärts aufgezäumt: Nicht die Quelle der Daten, sondern Funktionsaufrufe als solche wurden als Grundlage für Einschränkungen verwendet. Ein unbeliebter und unnützer Effekt dieser Methode war, dass auch legitime Daten und Funktionsrufe pauschal eingeschränkt wurden. Eine gänzliche Entfernung dieser Konfigurationseinstellung mit PHP 5.3.0 bzw. 6.0 erschien sodann naheliegend (PHP kann beispielsweise mit Core Grasp um eine Art Tainted-Funktionalität erweitert werden).
► 07.07.2011 – Sicherheitsprobleme der Öffnung von Top-Level-Domains
Die Internet Corporation for Assigned Names and Numbers (ICANN) ist eine privatrechtliche Non-Profit Organisation US-amerikanischen Rechts mit Sitz im kalifornischen Ort Marina del Rey. Mitunter entscheidet ICANN über die Verwaltung von Top-Level-Domains (TLD).
Ende 2008 wurde durch ICANN die Einführung neuer Adresszonen erlaubt. Damit wird es möglich, mehr oder weniger nach Belieben eigene TLDs zu registrieren. Eine solche Anmeldung ist mit erheblichem bürokratischem Aufwand verbunden. Zudem wird eine Zahlung von 185.000 US$ erforderlich. Erschwinglich wird eine solche also nur für grössere Unternehmen.
Obwohl ICANN als Non-Profit Organisation ausgewiesen wird, lassen die Entscheidungen bezüglich TLDs Zweifel über die wahren Hintergründe aufkommen. Technische Vorteile sind nur bedingt gegeben. Es scheint eher so zu sein, dass hier monetäre Absichten den Ausgang der Wahlen entscheiden würde. Mancherorts wird behauptet, dass ICANN mit der Öffnung die Geldmaschine mal wieder angeworfen hätte.
Die Öffnung der TLDs führt aber zusätzlich neue Sicherheitsrisiken ein. Diese kommen in der allgemeinen Berichterstattung und den daraufhin geführten Diskussionen leider viel zu knapp zum Tragen. Aus diesem Grund wollen wir hier die zentralen Aspekte zusammenfassen:
- Verworrene Identifikation: Das Identifizieren von Zielen ist nicht mehr oder nur mit erheblichem Aufwand möglich. So bleibt unklar, ob nun die offizielle Webseite zum iPhone unter apple.com/iphone, iphone.com oder iphone.apple gesucht werden müsste. Dieses Problem existierte zwar schon seit jeher, wird aber durch neue TLDs nur noch verschärft.
- Ähnliche Schreibweisen: Die ähnliche Schreibweise von Domains wurde seit langem durch Angreifer missbraucht, um zum Beispiel Phishing- und Pharming-Attacken durchzuführen. So wurden Seiten wie postf1nance.ch oder creditsuisse-bank.com eingesetzt, um Opfer auf die vermeintlich legitimen Seiten zu locken. Mit neuen TLDs eröffnen sich weitere Möglichkeiten dieser Art. Dazu gehören beispielsweise
.cornanstelle von.com(via @stfn42) und.orqanstelle von.org.
- Reservierte Worte: Es gibt eine Reihe von reservierten Worten, die im DNS- und IT-Bereich anzutreffen sind. Kann sich jemand ein solches oder ein ähnliches als TDL registrieren, eröffnen sich ganz neue Zugriffs- und Angriffsmöglichkeiten. Dazu gehören beispielsweise
.localhost,.local,.www,.mail,.smtp,.popund.test.
- Zahlen täuschen IP-Adressen vor: Jenachdem welche Einschränkungen auferlegt sind, können zahlenbasierte TLDs zum Einsatz kommen und hier wiederum Verwechslungen provozieren. Eine TLD wie
.l0könne missbraucht werden, um eine Adresse wiel0.0.0.l0zu konstruieren – Die TLD besteht aus dem Buchstaben l und nicht aus der Ziffer 1. Zwar existiert .io – wird zu.IO– schon, jedoch können eine Vielzahl an Abwandlungen hiervon erstellt werden.
- Eingabeüberprüfungen funktionieren nicht mehr: Viele Eingabeüberprüfungen für Domains, vor allem solche auf der Basis regulärer Ausdrücke, werden nicht mehr oder nur noch fehlerhaft funktionieren. Dies kann einerseits nicht mehr funktionierende Applikationen zur Folge haben. Andererseits kann es in vereinzelten Fällen auch beobachtet werden, dass sich damit Einschränkungen umgehen und erweiterte Rechte erlangen lassen.
Befürworter des neuen Systems argumentieren, dass es nicht Aufgabe der Domainnamen ist, eine Authentisierung und Identifizierung vorzunehmen – Dies müsse auf anderer Ebene durchgesetzt werden. In der Tat eignet sich das Domainsystem nicht, um dieser Anforderung gerecht zu werden. Dennoch war es bis dato ein einfaches Mittel, um gerade für Laien eine rudimentäre Möglichkeit der Zielidentifikation umzusetzen. Fällt diese nun aufgrund des Bruchs der Systemstruktur komplett weg, wird es immer schwieriger sich zu orientieren.
Aus unserer Sicht bleiben die letzten Entscheidungen der ICANN bezüglich TLDs fragwürdig. Dies sowohl aus benutzertechnischer als auch aus sicherheitstechnischer Sicht. Aus diesem Grund würden wir von der Einführung der genannten Erweiterung abraten. Wir tweeten über das Thema mit dem Hashtag #tldmess. Weitere Informationen hierzu finden sich in unserem Interview für die SonntagsZeitung.
► 30.06.2011 – Blog Digest Juni 2011
- 6 Ideas for a Protean Information Security Architecture (13.06.2011), blog.zeltser.com, defense methodology
- 8 Strategic and Tactical Tips for Detecting a Website Compromise (16.06.2011), blog.zeltser.com
- A brief Sony password analysis (07.06.2011), good insight
- Comparing the PCI, CIS and FDCC Certification Standards (23.06.2011), blog.tenablesecurity.com, quick overview
- (ComputerSecurity) Conference Collecting (26.05.2011), blog.thinkst.com
- Dangerous whitespaces (09.06.2011), securelist.com, nice hiding approach
- Enterprise Security: the Ten Commandments (31.05.2011), David Harley, blog.eset.com
- FFIEC finally releases new Guidance on Internet Banking Authentication; Better Late than Never (29.06.2011), Avivah Litan, blogs.gartner.com
- Fundamental flaw in thinking: We’re responsible (09.06.2011), Martin McKeay
- Google Search By Image: Use A Snapshot As Your Search Query (14.06.2011), Jason Kincaid
- How to stop your Gmail account being hacked (02.06.2011), six good tips
- http-waf-detect – Script to detect WAF/IDS/IPS solutions (16.06.2011), seclists.org, elegant solution
- JSON Hijacking (30.05.2011), thespanner.co.uk, interesting approaches
- Meterpreter HTTP/HTTPS Communication (29.06.2011), H.D. Moore, rapid7.com
- Mobile Security – Users Just Don’t Care (21.06.2011), Tyler Shields, veracode.com
- Monitoring Social Media for Security References to Your Organization (26.05.2011), isc.sans.org
- Most Common iPhone Passcodes (13.06.2011), Daniel, amitay.us
- My Other Ride is Your Image Upload Script (13.06.2011), Dan Crowle
- New to Security? Get on Twitter (08.06.2011), Martin McKeay
- Nissan LEAF CARWINGS tells any RSS feed provider your current position, speed, direction, destination, etc. (13.06.2011), admin, seattlewireless.net
- Performance is a Feature (21.06.2011), codinghorror.com
- Recent Developments in Java Signed Applets (27.05.2011), egypt
- RSA finally comes clean: SecurID is compromised (07.06.2011), arstechnica.com, important development
- Say Hello To Linux 3.0; Linus Just Tagged 3.0-rc1 (30.05.2011), a new generation
- Shrinking vs. Slicing the Pie of Online and Computer Crime (31.05.2011), blog.zeltser.com
- Skype protocol reverse engineered, source available for download (02.06.2011), skype-open-source.blogspot.com, important research
- Take a bow everybody, the security industry really failed this time (27.06.2011), David Maynor, erratasec.blogspot.com
- The Critical Role of the Security Incident Response Coordinator (23.06.2011), blog.zeltser.com
- The Futility of Web Pen Testing (31.05.2011), deadliestwebattacks.com
- The Role of Rituals in Information Security (27.05.2011), blog.zeltser.com
- Trying to end mixed scripting vulnerabilities (16.06.2011), Chris Evans
- Trusting the Cloud (28.05.2011), Joanna, theinvisiblethings.blogspot.com
- USB Security Challenges (01.06.2011), Joanna, theinvisiblethings.blogspot.com
- vSploit – Virtualizing Intrusion & Exploitation Attributes with Metasploit Framework (20.06.2011), for IDS/IPS/log testing
- Web Application Firewalls with Mod Security (01.06.2011), resources.infosecinstitute.com, good headstart
- When Bots Use Social Media for Command and Control (28.06.2011), blog.zeltser.com
- When Does a Suspicious Event Qualify as a Security Incident? (28.06.2011), blog.zeltser.com
- Will the Real APT Please Stand Up? (17.06.2011), deadliestwebattacks.com
- Zones of Trust (13.06.2011)
► 23.06.2011 – Präsentation zur Sicherheit in Sozialen Netzen
Die vergangene Zürcher Tagung der ISSS – Information Security Society Switzerland befasste sich mit der Sicherheit in Sozialen Netzwerken. Dabei wurde ebenfalls ein Vortrag mit dem Titel Soziale Netzwerke – Vielschichtige Gefahren eines neuen Zeitalters durch mich gehalten.
Sowohl die Präsentationsfolien (PDF, 1.1MB) als auch ein Video-Mitschnitt des Vortrags (Schweizerdeutsch, 26 min) stehen Online zur Verfügung.
Soziale Netzwerke, wie zum Beispiel Facebook und Twitter, sind aus der heutigen Informationsgesellschaft nicht mehr wegzudenken. Durch den erweiterten Datenaustausch werden aber nicht nur Möglichkeiten geschaffen, sondern auch Risiken für Unternehmen, Mitarbeiter und Einzelpersonen mitgeführt.
Dieser Vortrag bespricht die verschiedenen Aspekte der Informationssicherheit im Rahmen Sozialer Netzwerke. Dabei wird einerseits auf allgemeine datenschutztechnische Risiken eingegangen. Andererseits werden technische Gefahren an konkreten Beispielen aufgezeigt und so greifbar gemacht.
► 16.06.2011 – Open-Source und die Auswirkungen auf die Sicherheit
Seit jeher wird debattiert, ob und inwiefern Quelloffenheit Einfluss auf die Sicherheit eines Produkts haben kann. Es gibt hier theoretisch drei Standpunkte, die vertreten werden können:
- Pro: Die Sicherheit offener Lösungen ist grösser als jene geschlossener Lösungen.
- Equivalent: Die Sicherheit offener und geschlossener Lösungen ist gleich.
- Contra: Die Sicherheit offener Lösungen ist kleiner als jene geschlossener Lösungen.
Generell kann gesagt werden, dass alle drei Annahmen richtig sein können. Die Aussage ist aber massgeblich vom Standpunkt und den mit ihm einhergehenden Eigenschaften abhängig. Diese können den Aussagen entsprechend wie folgt zusammengefasst werden:
- Die Sicherheit offener und geschlossener Lösungen ist gleich: Theoretisch ist es möglich, ein Produkt unabhängig von seiner Offenheit mit stetig gleicher Sicherheit zu entwickeln. Die grundlegende Qualität einer Lösung ist nämlich massgeblich von der Qualität der Umsetzung und nicht vom Modell abhängig. Genauso wie es unsichere Lösungen offener Struktur gibt, gibt es ebenso sichere Lösungen geschlossener Natur (letztere sind jedoch schwieriger zu beweisen, siehe Punkt 2).
- Die Sicherheit offener Lösungen ist grösser als jene geschlossener Lösungen: Transparenz ist ein zentraler Aspekt, um Vertrauen und damit Sicherheit zu schaffen. Die Offenheit eines Produkts hilft dabei, dieses Ziel zu erreichen. So ist es mit verhältnismässig wenig Aufwand jedem möglich, sich von der Funktionsweise und der damit einhergehenden Sicherheit einer Lösung zu überzeugen. Dadurch können Fehler effizienter und selbstständig entdeckt werden. Ein Mitteilen/Veröffentlichen dieser beschleunigt den Prozess der Identifikation und Eliminierung etwaiger Schwachstellen. Die Qualität eines offenen Produkts kann damit theoretisch schneller zunehmen, als jene eines geschlossenen Produkts. Das Zeitfenster für erfolgreiche Angriffe wird so durch die Vielzahl der Teilnehmer der Qualitätsanalyse reduziert.
- Die Sicherheit offener Lösungen ist kleiner als jene geschlossener Lösungen: Die Offenheit einer Lösung kann aber ebenso dazu beitragen, dass sich jemand die Mühe macht, gezielt nach Schwachstellen zu suchen. Indem diese weder dem Hersteller noch einer breiten Öffentlichkeit bekannt gemacht werden, kann sich damit ein Vorteil verschafft werden. Durch die unkomplizierte Einsicht in die Funktionsweise des Produkts muss weniger Aufwand in Kauf genommen werden, um die potentiellen Schwachstellen eruieren zu können. Die unmittelbare Sicherheit offener Systeme ist damit derjenigen geschlossener Systeme kurz-/mittelfristig unterlegen, sollten bisher unbekannte Schwachstellen verbleiben.
Verhalten der Fehlerquote
Gehen wir davon aus, dass ein System eine Anzahl Fehler Total hat. Diese können grösser oder gleich gross der Anzahl Fehler Unentdeckt sein. Diese können ihrerseits grösser oder gleich gross der Anzahl Fehler Entdeckt sein. Und diese können ebenfalls grösser oder gleich gross Fehler öffentlich sein:
Fehler Total ≥ Fehler Unentdeckt ≥ Fehler Entdeckt ≥ Fehler Öffentlich
Die Reihenfolge dieses Vergleichs bestimmt ebenso die Gefahr eines Fehlers. Umso entdeckter/öffentlicher er ist, desto eher kann und wird er behoben werden. Dies ist im Grunde sowohl für den Hersteller als auch für die Nutzer/Kunden von Vorteil.
In so manchen Publikationen wird davon ausgegangen, dass die Anzahl Fehler Entdeckt bzw. Fehler Öffentlich eine direkte Aussage zur Sicherheit eines Systems (und damit über die Anzahl der Fehler Total) gemacht werden kann. Dies ist jedoch, wie der Vergleich zeigt, nicht zwingend der Fall. Es kann höchstens aus den Daten der Vergangenheit ein möglicher Trend aufgezeigt werden.
Eine hohe Anzahl öffentlich gemachter Fehler ist in diesem Fall aber nicht zwingend nur ein Hinweis auf die fehlende Qualität eines Produkts. Ebenso können diese, sind sie denn behoben worden, Aufschluss über die gegenwärtig erhöhte Sicherheit geben. Gute Beispiele hierfür sind die Microsoft-Produkte IIS und Internet Explorer. Beide Lösungen sind jahrelang aufgrund der überdurchschnittlich hohen Anzahl Sicherheitslücken/Patches in der Kritik gestanden. Der gegenwärtige statistische Vergleich (siehe auch) mit konkurrierenden Produkten attestiert diesen Lösungen mittlerweile eine bessere durchschnittliche Sicherheitsqualität. Es darf sich also nicht nur auf Daten der Vergangenheit in unumstösslicher Weise verlassen werden.
Modell für hochsichere Umgebungen
Es wurde nun gezeigt, dass sowohl offene als auch geschlossene Systeme einen sicherheitstechnischen Vorteil versprechen können. Damit stellt sich nun aber die Frage, welches Modell in hochsicheren Umgebungen bevorzugt werden sollte.
Eine geschlossene Lösung kann dann empfohlen werden, wenn ein kurzfristiger Vorteil – und nur ein solcher! – erreicht werden will. Kann die Lösung durch eigene Spezialisten umfangreich geprüft werden, kann sich damit ein Vorsprung herausgeholt werden (dies kann bei den Anpassungen von DES durch die NSA vermutet werden). Die Angreifer werden jedoch längerfristig in der Lage sein, diesen aufzuholen und damit den Vorteil des geschlossenen Systems in dessen Nachteil umzuwandeln (so geschehen bei der in GSM eingesetzten Verschlüsselung A5).
Längerfristig gesehen sollten deshalb stets offenen Systemen den Vorrang gegeben werden. Durch das etwaige Mitarbeiten einer Community – vor allem in Kombination mit den eigenen Spezialisten – können Fehler schneller eliminiert werden. Das Ziel sollte sein, irgendwann – möglichst schnell – den Zustand eines möglichst sicheren Systems zu erreichen, in dem keine unbekannten und untragbaren Schwachstellen mehr existieren.
► 09.06.2011 – Technische Scan Details
Im Rahmen von technischen Sicherheitsüberprüfungen sind Analysten immer wieder vor Herausforderungen gestellt. Eine dieser ist es, eine möglichst umfassende Dokumentation der Vorgänge vorzulegen. Damit soll eine transparente Nachvollziehbarkeit erreicht werden, die sowohl dem Analysten selbst als auch dem Kunden weiterhelfen können soll. Bei Problemen und Unklarheiten kann sich nämlich direkt auf die konkreten Daten bezogen werden, wodurch Vermutungen eliminiert werden können.
Nachfolgend soll aufgegliedert werden, für welchen Prozess wir uns bei technischen Sicherheitsüberprüfungen entschieden haben.
Anfrage
Zu Beginn einer aktiven technischen Prüfung steht die Anfrage. Das ist jene Anfrage, die vom Quellsystem des Analysten zum Zielsystem des Kunden geschickt werden soll. Dies kann zum Beispiel der Zugriff von einem Webbrowser auf einen Webserver sein. Die effektive HTTP-Anfrage dieses Zugriffs wird festgehalten:
GET ../../etc/passwd HTTP/1.1 Host: www.scip.ch User-Agent: scip Web Exploit Framework/3.2
Erwartete Antwort
Eine Prüfung kann nur dann stattfinden, wenn das gegebene Resultat mit einem erwarteten Resultat verglichen werden kann. Jeder Test muss also ein definiertes erwartetes Resultat aufweisen. Im Fall der gezeigten Prüfung wird eine 404 Not Found Meldung erwartet, um diesen Angriffsvektor ausschliessen zu können. Diese Antwort sieht in ihren Grundzügen so aus:
HTTP/1.1 404 Not Found Date: Mon, 5 Apr 2010 09:40:55 GMT Server: Apache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 2270 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html
Empfangene Antwort
Im Gegensatz zur erwarteten Antwort wird nun jedoch die effektiv vom Zielsystem provozierte und damit empfangene Antwort dokumentiert. Diese kann entweder von der erwarteten Antwort abweichen oder im weitesten Sinn dieser entsprechen:
HTTP/1.1 200 Found Date: Mon, 5 Apr 2010 09:59:10 GMT Server: Apache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 2348 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/plain
Zusätzliche Details
Die zentralen Eigenschaften des Tests mögen zwar damit weitestgehend dokumentiert sein, jedoch können diese noch mit zusätzlichen Details aufgewertet werden. Dies können Zeitangaben (Start und Ende des Tests sowie durchschnittliche Antwortzeit des Servers) oder technische Details aus anderen Analysen (z.B. Anzahl Hops bis zum Zielsystem) sein.
► 02.06.2011 – Top 5 Stupid Captcha Implementations
Der grundlegende Nutzen eines Computers ist, dass repetitive Augaben automatisiert sowie grosse Datenmengen verarbeitet werden können. Gewiefte Angreifer nutzen die Möglichkeit der Automatismen, um ihre dubiosen Aktivitäten durchzusetzen.
Um zum Beispiel zu verhindern, dass fortwährend in Foren mittels Bots Werbung für Viagra und Pornoseiten gemacht werden, werden sogenannte CAPTCHA (Completely Automated Public Turing Test to tell Computers and Humans Apart) eingesetzt. Bei diesen muss der Benutzer vor dem Absenden des Formulars eine Tätigkeit durchführen, die sich nur schwer automatisieren lässt. Gängige CAPTCHA-Implementierungen erfordern, dass man den auf einem zufällig generierten Bild dargestellten Code eingibt.
Intelligent umgesetzte CAPTCHAs sind durchaus schwierig zu umgehen. Wird ein hohes Mass an Dynamik sowie komplexe Mechanismen eingesetzt, ist eine automatisierte Verarbeitung im Rahmen eines Angriffs mit sehr viel Aufwand verbunden. Dennoch sehen wir bei Web Application Penetration Tests immerwieder Implementierungen, bei denen die Entwickler offensichtlich das Konzept von CAPTCHA missverstanden haben. Die fünf lustigsten Fehler wollen wir hier zusammenfassen:
Bild erlaubt einfache OCR-Verarbeitung
Traditionelle CAPTCHA generieren ein Bild, in dem eine zufällige Zeichenkombination enthalten ist. Um eine Weiterverarbeitung durch OCR (Optical Character Recognition) zu erschweren, werden dabei unterschiedliche Schriftarten sowie zufällige Störmuster verwendet. Wird auf solche verzichtet, kann das Bild sehr einfach eingelesen und ausgewertet werden. Eine automatisierte Weiterverarbeitung ist damit sehr einfach durchsetzbar.
Statischer Zufallcode
Um einem Angreifer einen automatisierten Angriff auf das CAPTCHA zu erschweren, sollte dies bei jeder Eingabe – auch bei einer Falscheingabe – neu geladen werden. So mancher Programmierer verzichtet darauf und generiert erst bei erfolgreicher Verarbeitung der CAPTCHA-Eingabe einen neuen Zufallscode. Dies erlaubt das Umsetzen einer linearen Bruteforce-Attacke, die gerade bei kurzen CAPTCHA-Werten (4-stellig) relativ schnell zum Erfolg führen können.
Zufallscode in Dateiname
Wird ein Zufallscode generiert, sollte sich dieser nur mit erheblichem Aufwand (z.B. OCR) auslesen lassen. So mancher Programmierer macht es sich jedoch sehr einfach und legt die generierten Bilder auf dem Webserver ab (z.B. zwecks Caching). Dabei wird der eigentlich geschützte Inhalt (NX7GQ) als Dateiname (captcha_nx7gq.jpg) verwendet. Durch das simple Einlesen des Dateinamens kann auf die komplexe Weiterverarbeitung des Bildinhalts verzichtet werden.
Zufallscode ist nicht zufällig
Ein CAPTCHA entspricht weitestgehend einem Challenge-Response-Verfahren. Dies bedeutet aber auch, dass die ausgegebene Challange vermerkt bzw. die erwartete Response vorhersehbar sein muss. Auf dem Server müssen entsprechende Mechanismen implementiert sein, um dieses Tracking durchführen zu können. Manche Programmierer machen es sich besonders einfach, indem sie den Zufallscode nicht stetig wirklich zufällig ausgeben lassen, sondern mit vorhersehbaren Werten arbeiten. Zum Beispiel mit einem Funktionsaufruf von $captcha=md5($_SERVER['REMOTE_ADDR'].time());, der sich durch eine Kryptoanalyse mit endlichem Aufwand ermitteln und damit vorausberechnen lässt.
Javascript-Validierung aktiviert Send-Button
Es ist die Aufgabe eines CAPTCHA, dass die Datenannahme bzw. -weiterverarbeitung erst dann stattfindet, wenn der Zufallscode richtig zurückgegeben wurde. Manche Programmierer lagern diesen Mechanismus mittels Javascript zum Client aus und vollziehen da die Validierung der Eingabe. Indem der Send-Button des Formulars deaktiviert und erst nach der CAPTCHA-Überprüfung wieder aktiviert wird, will ein Absenden ohne richtige Eingabe verhindert werden. Durch das Manipulieren des Javascript-Codes bzw. dem Absetzen von direkten HTTP-Anfragen lassen sich solche Einschränkungen einfach umgehen.
► 27.05.2011 – Blog Digest Mai 2011
- 4 Reasons Why Computer Users Dread Installing Security Updates (19.05.2011), blog.zeltser.com
- A Brief History of Physical Memory Forensics (25.05.2011), Greg Hoglund, fasthorizon.blogspot.com
- Analyzing Malware Hollow Processes (16.05.2011), Eric Monti
- Android Security: 10 Tips and Settings (03.05.2011), Matt Mossman, resources.infosecinstitute.com
- Android Security: Take Control (12.05.2011), resources.infosecinstitute.com, good approaches
- A Spirited Peek into ViewState, Part I (13.05.2011), deadliestwebattacks.com, great insight
- Automated Vulnerability Disclosure with upSploit (11.05.2011), resources.infosecinstitute.com, useful idea
- Bug bounties vs. black (& grey) markets (25.05.2011), Chris, scarybeastsecurity.blogspot.com
- Checklists, software and software security (02.05.2011), Jim Bird, software-security.sans.org
- Comic for May 24, 2011 (24.05.2011), dilbert.com
- Complexity is killing us (14.05.2011), blogs.securiteam.com
- (ComputerSecurity) Conference Collecting (26.05.2011), blog.thinkst.com
- Creepy, the Geolocation Information Aggregator (25.05.2011), Yiannis Kakavas, resources.infosecinstitute.com
- Dropbox Lied to Users About Data Security, Complaint to FTC Alleges (13.05.2011), Ryan Singel, wired.com
- False Positives – The Dirty Secret of the Web Security Scanning Industry (24.05.2011), Ferruh Mavituna
- HitB2011AMS: A Real-Life Study of What Really Breaks SSL (20.05.2011), cupfighter.net, good summary
- How Big is Big? Some Botnet Statistics (23.05.2011), admin
- How Web Security Will Change With HTML5 (30.04.2011), mashable.com, quick summary
- IIS 7 Header Block Module – Released (13.05.2011), seclists.org, important extension
- Make noise and whisper: a solution to relay attacks (09.05.2011), lightbluetouchpaper.org, interesting approach
- Market Segmentation in Computer Attacks (29.04.2011), interesting analysis
- Metasploit Framework 3.7.0 Released! (03.05.2011), egypt
- Microsoft EMET (30.04.2011), darkoperator.com, immediate mitigations
- Monitoring Social Media for Security References to Your Organization, (Wed, May 25th) (26.05.2011), isc.sans.org
- More on Google image poisoning, (Wed, May 4th) (04.05.2011), isc.sans.org
- Plugin Spotlights: New Nessus OS Identification Plugins (29.04.2011), blog.tenablesecurity.com, HNAP, AFP and UPnP
- Selective attack with a rogue GSM/GPRS base station (05.05.2011), technical insight
- Survey finds users re-evaluating two-factor authentication options (30.04.2011), pheedcontent.com, 44% are re-evaluating
- The App-oriented UI Model and its Security Implications (21.05.2011), noreply@blogger.com (joanna), theinvisiblethings.blogspot.com
- The Death of Web Scanners (05.05.2011), book, deadliestwebattacks.com
- The OWASP Mobile Top 10 Risks for iOS Developers (24.05.2011), jeremy.allen, intrepidusgroup.com
- The RTLO unicode hole – sequence manipulation as an attack vector (13.05.2011), norman.com, very nice approach
- The Worst Information Security Advice Ever (05.05.2011), blog.zeltser.com, nice idea
- Unicode Visual Spoofing for Good: Confusable CAPTCHAs (10.05.2011), Ryan Barnett,
- What I need from pen test reports. (23.05.2011), SiteOwner
- Who’s to Secure Cloud: Vendor or User? (29.04.2011), cost savings over security
► 19.05.2011 – Reduzierbarkeit von Tests
Sicherheitsüberprüfungen sind ein komplexes Thema, das neben technischen Aspekten ebenso in philosophischer Weise (konzeptionell und organisatorisch) für Gesprächsstoff sorgen kann. Ein Aspekt, der oft diskutiert wird, ist die Reduzierbarkeit von Tests. Darunter wird gemeinhin das Folgende verstanden:
Ein Test mit einem Gesamtumfang x soll in Bezug auf Teilprozesse und/oder Zeitumfang verringert werden.
Das eigentliche Ziel einer solchen Reduktion ist in den allermeisten Fällen wirtschaftlicher Natur. Und damit wird unverzüglich ein Interessenskonflikt etabliert, denn in einer direkten Gegenüberstellung widersprechen sich Wirtschaftlichkeit und Sicherheit (ganz im Gegensatz zu langfristigen Überlegungen).
Wohl kein Tester wird aus freien Stücken den Umfang seiner Analysen einschränken wollen, da damit stets die Qualität der Betrachtungen verloren geht. Und doch gibt es Situationen, in denen der Testumfang in gegenseitigem Einverständnis reduziert werden will. Die Frage ist jedoch stets:
Wann und wieviel Reduktion ist sinnvoll?
Als Grundsatz gilt es zu bedenken, dass eine Sicherheitsüberprüfung stets nur deterministische Aussagen zur effektiv getesteten Angreifbarkeit eines Objekts machen kann. Wenn eine Prüfung x Tage dauert, dann kann nicht exakt bestimmt werden, welche Effekte ein Angreifer erzielen kann, dem x+y Tage zur Verfügung stehen. Bevor der Rahmen einer Prüfung definiert wird, sollte also die zeitliche Wichtigkeit des Schutzbedarfs bestimmt werden. Und in gleicher Weise die Aufwände, die potentielle Angreifer zu betreiben gewillt sind (z.B. Zusammentragen von Knowhow, Investieren von Geld).
Das Problem beim Reduzieren von Testreihen ist, dass sich diese nicht beliebig skalieren lassen. Erfordert das Testing für ein Objekt x Tage, dann kann nicht per se x/2 oder x-10% Tage investiert werden. Hierfür gibt es drei Gründe:
- Minimalaufwand: Unterschiedliche Tests weisen jeweils einen Minimalaufwand auf. Genauso wie man eine Fussballmannschaft nicht mit nur 5 Mann spielen lassen kann, kann man eine übliche Webapplikation nicht einfach in 2 Stunden fachgerecht überprüfen.
- Verknüpfbarkeit: Verschiedene Testreihen weisen eine Verknüpfbarkeit auf. Eine zentrale Analysetechnik von Software besteht in der Betrachtung von Eingabeüberprüfungen (Input Validation). Als Teilmenge derer fungieren beispielsweise Pufferüberlauf-Attacken und SQL-Injection. Wird auf eine dieser Angriffsklassen verzichtet, so können theoretisch auch gleich auf andere Klassen verzichtet werden.
- Gleichwertigkeit: Angriffsvektoren und -techniken weisen für sich (und manchmal auch untereinander) eine Gleichwertigkeit auf. Es gibt eine Vielzahl unterschiedlicher Angriffsvektoren für verschiedene Angriffstechniken (z.B. Cross Site Scripting-Attacken). Lediglich 80% derer zu testen ist nicht sinnvoll, da es oftmals (gerade in einem Penetration Test) keine wichtigsten Varianten gibt.
Die Folge davon ist, dass sich Sicherheitsüberprüfungen nur bruch- und damit stufenweise reduzieren lassen. Zum Beispiel können bei der Prüfung eines Internet-Perimeters sämtliche Webapplikationen ausgeschlossen und stattdessen nur ein Vulnerability Scan angesetzt werden. Halt mit dem Risiko, dass ein wichtiger Aspekt der Perimetersicherheit nicht geprüft wird. (Kein kluger Schachzug, da Applikationssicherheit immer mehr in den Fokus rückt.)
Es ist wichtig zu Beginn eines Projekts mit den Spezialisten zu diskutieren, welche Aspekte eines Tests besonders wichtig sind (z.B. hohe Exponierbarkeit) und auf welche aus wirtschaftlichen Gründen verzichtet werden kann bzw. erst in einer späteren Phase geprüft werden sollen (z.B. authentisierte Bereiche). Nur so kann gewährleistet werden, dass ein Prüfobjekt umfangreich und professionell untersucht werden kann.
► 12.05.2011 – iPhone Forensik
Die Geräte von Apple erfreuen sich einer sehr grossen Beliebtheit. Damit werden sich ebenfalls für Angreifer interessant. Ebenso wächst aber auch das Interesse für forensische Untersuchungen. Diese werden beispielsweise von Behörden angesetzt, um Details zur Nutzung eines Geräts bzw. dem Verhalten dessen Besitzers in Erfahrung zu bringen.
Lokation des iTunes-Backup
Dieser Beitrag soll das grundlegende Prinzip der iPhone Forensik aufzeigen. Es lässt sich ebenfalls auf andere Apple-Geräte mit dem iOS-Betriebssystem übertragen (z.B. iPad und iPod). Hierzu ist der phsysische Zugriff auf ein entsprechendes Gerät erforderlich. Wie bei jeder forensischen Analyse soll auch hier darum bemüht sein, das Original-Material möglichst unangetastet zu lassen, um ein unbeabsichtigtes Verändern der Informationen zu verhindern. Zu diesem Zweck wird das Gerät über den USB-Anschluss an einen Rechner angeschlossen und auf diesem über iTunes ein reguläres Backup angefertigt.
iTunes legt eine lokale Kopie sämtlicher Konfigurationseinstellungen und Anwendungsdaten des Geräts an. Dabei werden die Backups benutzerbezogen und voneinander getrennt abgelegt. Die jeweiligen Ordner sind auf den verschiedenen Betriebssystemen wie folgt eingerichtet:
- OS X:
~/Library/Application Support/MobileSync/Backup/ - WinXP:
%HOMEPATH%\Application Data\Apple Computer\MobileSync\Backup\ - Vista/7:
%HOMEPATH%\AppData\Roaming\Apple Computer\MobileSync\Backup\
Dort finden sich als Unterordner die jeweiligen Backups der verschiedenen Geräte. Die Ordnernamen entsprechen dabei 40-bit hexadezimalen Hashwert, der manchmal um einen zusätzlichen Datumswert und eine weitere Kennzeichnung erweitert wird.
Allgemeine Dateien des Backup
Innerhalb eines Backup-Ordner finden sich sämtliche zu einem Backup dazugehörigen Dateien. In der Datei Info.plist werden im XML-Format die grundlegenden Informationen des Backups bereitgestellt. Dazu gehören allgemeine Informationen zum Gerät und der synchronisierten Apps.
Die zum Backup gehörigen Dateien weisen keine Dateierweiterung auf. Stattdessen werden deren Namen aus dem SHA1-Hash Wert des original Pfad- und Dateinamens gebildet. Beispiel:
maru@debian:~$ printf 'HomeDomain-Library/SMS/sms.db' | sha1 3d0d7e5fb2ce288813306e4d4636395e047a3d28
Es ist also mit der Durchsicht der Dateien möglich herauszufinden, um was für einen Dateityp es sich handelt. Die einfachste und effizienteste Form ist das Identifizieren der Magic Number einer Datei. Hierzu können Anwendungen wie das file-Kommando für Unix oder filerecon für Windows eingesetzt werden. Mit einem iPhone aufgenommene Filme lassen sich beispielsweise anhand der Zeichenkette ftypqt, die auf einen Quicktime AVI-Container hindeuten, identifizieren. Durch das Hinzufügen der Dateierweiterung .avi kann die entsprechende Aufnahme üblicherweise in einem Videoplayer abgespielt werden.
SQLite-Datenbanken
Von ebenso grossem Interesse bei einer forensischen Untersuchung sind jedoch SQLite-Datenbanken. Diese werden üblicherweise durch Systemapplikationen und zusätzlich installierte Apps eingesetzt, um dynamische Daten abzulegen. Solche Datenbanken lassen sich daran erkennen, dass ihr Dateiinhalt mit der folgenden Zeichenkette beginnt:
SQLite format 3
Bei SQLite handelt es sich um eine Programmbibliothek, die ein relationales Datenbanksystem bereitstellt. Sie unterstützt zu grosen Teilen die in SQL-92 festgelegten SQL-Sprachbefehle. Eine SQLite-Datenbank wird jedoch in reduzierter Weise als einzelne Datei abgelegt und verzichtet deshalb auf ein Client/Server-Modell. Es gibt verschiedene Clients und Bibliotheken, mit denen auf SQLite-Datenbanken zugegriffen können werden. Der nachfolgende Screenshot zeigt beispielsweise den SQLite Database Browser, eine Freeware-Lösung für Windows. Sie ist jedoch nicht gerade für ihre Stabilität und Zuverlässigkeit, gerade bei komplexeren SQL-Abfragen, bekannt.
Da wir jedoch im Rahmen einer forensischen Analyse unsere Zugriffe bestmöglich automatisieren wollen, werden wir auf die zeilenbasierte Implementierung des SQLite-Clients zurückgreifen. Mit diesem sollen nun auf die SQLite-Dateien der jeweiligen Applikationen zugegriffen werden. Nachfolgende Tabelle zeigt die wichtigsten Dateinamen bei einer forensischen Untersuchung. Diese können bei verschiedenen iOS-Versionen voneinander abweichen. Die gezeigte Liste fokussiert sich lediglich auf die Namenskonvention von iOS4.
| Dateiname | Beschreibung | OS |
|---|---|---|
ca3bc056d4da0bbf88b5fb3be254f3b7147e639c |
Notizen | 4 |
2041457d5fe04d39d0ab481178355df6781e6858 |
Kalender | 2-4 |
31bb7ba8914766d4ba40d6dfb6113c8b614be442 |
Kontakte | 2-4 |
2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca |
Anrufe | 4 |
992df473bbb9e132f4b3b6e4d33f72171e97bc7a |
Voicemail | 4 |
3d0d7e5fb2ce288813306e4d4636395e047a3d28 |
SMS | 1-4 |
d9d4cfe3ea7c24405aebf4cca72505d5f7e53bb6 |
4 | |
be856a633d851b307e07576cb78af18911468f09 |
Notifo Messages | 4 |
6639cb6a02f32e0203851f25465ffb89ca8ae3fa |
4 | |
6a0ff24e9ae0e722d414a8489bbee4ff66e68278 |
4 | |
a099ad74dbbc2a6b536b5e3a0fe388aeb629b27b |
Shazam | 4 |
bff364619d73328930e02e7fbf268b4ff3d351cd |
Instapaper | 4 |
b89f186b6dd6235b0a5004aac852ca758d2c00bd |
Evernote | 4 |
Auslesen des Datenbankinhalts
Wir rufen nun das sqlite3-Kommando (sqlite3.exe) auf, um die Informationen zu den letzten Anrufen zusammenzutragen. Diesem übergeben wir zwei Argumente: Mit dem ersten Argument definieren wir die anzuzeigende SQLite-Datenbank 2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca und mit dem zweiten Argument ".tables" weisen wir an, dass die Namen der darin enthaltenen Tabellen ausgegeben werden sollen.
C:\>sqlite3 2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca ".tables" _SqliteDatabaseProperties data call
In der Ausgabe ist zu sehen, dass in der Datenbank die drei Tabellen _SqliteDatabaseProperties, data und call enthalten sind.
| Tabellenname | Beschreibung |
|---|---|
| _SqliteDatabaseProperties | Eigenschaften der SQLite-Datenbank |
| data | Informationen zur Datenübertragung |
| call | Liste der letzten 100 Anrufe |
Die Tabelle call beinhaltet die letzten 100 Anrufe, die über das Gerät getätigt wurden. Mit der SQL-Anweisung PRAGMA kann die Tabellenstruktur ausgegeben werden:
C:\>sqlite3 2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca "PRAGMA table_info(call);" 0|ROWID|INTEGER|0||1 1|address|TEXT|0||0 2|date|INTEGER|0||0 3|duration|INTEGER|0||0 4|flags|INTEGER|0||0 5|id|INTEGER|0||0 6|name|TEXT|0||0 7|country_code|TEXT|0||0
Die Namen der jeweiligen Felder sind selbsterklärend. Mit address wird die Telefonnummer des Gegenübers definiert. Durch date wird der Zeitpunkt des Anrufs als Unix-Timestamp und durch duration die Dauer dessen in Sekunden ausgegeben. Mit dem Schalter -csv kann sqlite3.exe angewiesen werden, die unterschiedlichen Zellen durch Kommans voneinander zu trennen. Mit dem folgenden Aufruf wird nun der ganze Inhalt der Tabelle ausgegeben, wobei eine umgekehrte Sortierung anhand des Datumswerts vorgenommen wird.
C:>sqlite3 -csv 2b2b0084a1bc3a5ac8c27afdf14afb42c61a19ca "SELECT * FROM call ORDER BY date DESC;" 3648,+41123456789,1303400162,9,4,-1,"",228 3647,+41123456789,1303284369,3,5,4066,"",228 3646,+41123456789,1303219489,0,4,-1,"",228 3645,+41123456789,1303219276,200,4,-1,"",228 3644,+41123456789,1303105423,82,5,-1,"",228 (...)
Durch Anpassungen des sQL-Statements können nun beispielsweise nicht erfolgreiche Anrufe ausgeklammert werden. Dies geschähe durch SELECT * FROM call WHERE duration>0;, denn es sollen lediglich Anrufe mit einer Dauer von mehr als 0 ausgewiesen werden. Und mit der Eingabe von SELECT AVG(duration) FROM call WHERE duration > 0; lässt sich die durchschnittliche Dauer eines Telefongesprächs ermitteln.
Zugriff auf gelöschte Objekte
Viele Apps für das iPhone sind so konzipiert, dass kleinere Nutzdaten nicht wirklich gelöscht werden. Ein gutes Beispiel hierfür sind SMS-Nachrichten. Diese lassen sich zwar auf dem Gerät als gelöscht markieren. Tatsächlich findet dabei aber jedoch nur ein Ausblenden derer statt. Sie selbst sind nach wie vor auf dem Gerät vorhanden und werden auch im iTunes-Backup geführt. Hierzu lässt kann ganz einfach er folgende Zugriff durchgeführt werden:
C:\>sqlite3 -csv 3d0d7e5fb2ce288813306e4d4636395e047a3d28 "SELECT ROWID, address, date, text FROM message ORDER BY date ASC" 1,Swisscom,1245744630,"Dies ist die erste Nachricht auf Ihrem iPhone" 2,Swisscom,1245744634,"Als Nutzer der COMBOX pro wird die Funktion Visual Voicemail auf Ihrem iPhone nicht automatisch aktiviert." 3,Swisscom,1245744641,"Falls Sie von der COMBOX pro zu Visual Voicemail wechseln möchten, wenden Sie sich bitte an unsere Gratis-Hotline 0800xxxxxx" (...)
Gerade im Rahmen einer forensischen Untersuchung können Zugriffe dieser Art von zentraler Wichtigkeit sein. Die Einfachheit dieser soll aber auch zeitgleich daran erinnern, dass sich entsprechende Datensätze mit selbigem Aufwand manipulieren lassen. Durch Anpassungen an den jeweiligen Datenbanken können Spuren verwischt, manipuliert und generiert werden. Um eine umfassende forensische Untersuchung abschliessend vorlegen zu können, sollten als nach Möglichkeiten querprüfungen mit anderen Informationsquellen vorgenommen werden. Gerade im Zusammenhang mit über das Netzwerk (WLAN/Internet oder GSM/UMTS) verschickten Daten ist die Zusammenarbeit mit dem Provider angeraten.
| Applikation | Löschverhalten | |
|---|---|---|
| Mark | Echt | |
| SMS | • | |
| Kontakte | • | |
| Notizen | • | |
An gewissen Punkten setzt das iPhone oder zusätzliche Apps Mechanismen zur Protokollierung ein. Zum Beispiel wird im Adressbuch ebenfalls eine Tabelle mit dem Namen ABRecent geführt. Diese listet die letzten Zugriffe auf die Kontakte auf. Sie ist während der Handynutzung nicht direkt einsehbar oder editierbar/löschbar. Sie eignet sich deshalb bestens, um eine forensische Untersuchung voranzutreiben.
Lokalisierung
Das iPhone weist seit der ersten Generation die Möglichkeit einer Lokalisierung auf. Zu Beginn wurde mit einem Software-Update im Januar 2008 die Möglichkeit geschaffen, die Lokalisierung mittels Trilateration über WiFi-Netze zu bestimmen. Erst mit dem iPhone 3G wurde ein echtes A-GPS eingeführt, das im 3GS um eine digitale Kompassfunktion erweitert wurde. Diese Lokalisierungsmöglichkeiten werden durch das iPhone rege genutzt, um lokationsabhängige Dienste ermöglichen oder vereinfachen zu können. Zum Beispiel kann in der Karten-App die eigene Position angezeigt werden. Viele Twitter-Clients erlauben auch das Mitschicken der eigenen Position. Und so manche Anwendung basiert praktisch vollständig auf der Möglichkeit, die eigene Position mitzugeben (z.B. Foursquare und Gowalla).
Im April diesen Jahres wurde breitflächig bekannt, dass das iPhone diese Bewegungsdaten abspeichert. Sie werden beim Anlegen eines Backups mittels iTunes, wird dieses denn ohne Verschlüsselung durchgeführt, ebenfalls auf den Computer übertragen. Die Medien sahen darin in erster Linie das Risiko, dass diese Informationen durch dritte eingesehen und missbraucht werden könnten. Später stellte sich dann heraus, dass diese Daten gar teilweise in anonymisierter Weise an Apple übertragen werden, um die Lokalisierung über WiFi zu verbessern. Der Benutzer musste hierzu innerhalb von iTunes einwilligen.
Diese Daten werden bis zur Firmware 4.3.3 in der Datei consolidated.db (4096c9ec676f2847dc283405900e284a7c815836) abgelegt. In dieser SQLite-Datenbank sind verschiedene Tabellen enthalten, die von Interesse sein können. In erster Linie interessieren die Tabellen WifiLocation (Positionierung von WLANs) und CellLocation (Positionierung von GSM-Sendemasten). Der Aufbau dieser Tabellen ist jeweils ähnlich: So wird im Feld Timestamp der Zeitpunkt der Ortung und in den Feldern Latitude und Longitude die GPS-Position vermerkt. Im Fall der WiFi-Daten ist ebenfalls im Feld MAC die MAC-Adresse des Access Points notiert. Mit der folgenden Eingabe können die letzten 5 Lokationen ausgegeben werden:
C:>sqlite3 4096c9ec676f2847dc283405900e284a7c815836 "SELECT MAC,Timestamp,Latitude,Longitude FROM WifiLocation ORDER BY Timestamp DESC LIMIT 5;"
| MAC | Timestamp | Latitude | Longitude |
|---|---|---|---|
| 0:1d:7e:2c:4d:2c | 326527281.103384 | 47.46643942 | 8.32417249 |
| 0:22:3f:93:d9:e5 | 326527281.103384 | 47.46657633 | 8.32428169 |
| 0:24:1:38:82:a2 | 326527281.103384 | 47.46638536 | 8.32389265 |
| 0:24:b2:fc:24:14 | 326527281.103384 | 47.46637845 | 8.32445275 |
| 0:1:e3:1:ad:88 | 326527281.103384 | 47.46637523 | 8.32386404 |
Mit einer entsprechenden Visualisierungs-Software für GPS-Daten kann damit ein ungefähres Bewegungsverhalten illustriert werden. Das Thema wurde mitunter deshalb so schnell von den Massenmedien aufgegriffen, weil mit dem iPhone Tracker ein einfaches Tool zur automatisierten Extrahierung und Darstellung dieser Daten genutzt wurde. Die nachfolgende Grafik, die mit einer eigenen Software angefertigt wurde, zeigt mein Bewegungsverhalten rund um Zürich Hauptbahnhof der letzten Jahre:
Apple wurde durch die grosse Medienaufmerksamkeit des sogenannten Locationgate gezwungen, diesen angeblich versehentlichen Detailreichtum an Daten einzuschränken. In der Firmware-Version 4.3.3 werden nur noch die letzten Positionen gespeichert. Diese werden zudem nicht mehr angelegt, wenn die Ortungsfunktion abgeschaltet wird. Und von einem Übertragen auf das iTunes-Backup wird generell auch abgesehen. Die Auswertung von Lokalisierungsdaten ist aber nicht nur auf diese Built-In Funktion beschränkt. Viele andere Apps legen ebenfalls Ortungsdaten ab.
Fazit
Moderne Mobiltelefone stehen in Punkto Funktionalität klassischen Computersystemen in nichts mehr nach. Dadurch wird ebenfalls eine neue Welt der digitalen Forensik, die vor allem von Ermittlungsbehörden je länger je mehr berücksichtigt werden wird, erschlossen. Das iTunes-Backup eines iPhones ist schnell angelegt und durch standardisierte Dateiformate, wie halt eben SQLite-Datenbanken, können unkompliziert auf interessante Daten zugegriffen werden. Dies reicht von herkömmlichen Objekten wie Adressbuch, SMS und Kalender. Die zusätzlichen Apps und die Möglichkeiten der Ortungsdienste lassen mit einer umfassenden Analyse jedoch ein sehr exaktes Verhalten des Benutzers rekonstruieren.
Hinweis
Aufgrund der Aktualität der Diskussion wurde dieser Artikel mitunter in der Tageszeitung 20 Minuten zitiert.
► 05.05.2011 – Konkrete Massnahmen in der Datencloud
Wir haben im scip IT Security Forecast für das Jahr 2010 festgehalten, dass die kommenden Jahre
(...) voraussichtlich ganz im Zeichen von Cloud Computing (SaaS) stehen [werden].
Diese Voraussage ist ungebrochen eingetroffen und so haben wir zum Thema eine Reihe von Publikationen veröffentlicht und Vorträge gehalten.
Im Rahmen dieser Tätigkeiten, fortwährender Gespräche und jeweiligen Kundenprojekte tat sich immerwieder die Schwierigkeit auf, das Thema Cloud-Security als solches überhaupt greifbar zu machen:
- Was ist die Cloud?
- Welche externen Gefahren existieren für die Cloud?
- Welche intrinsischen Gefahren existieren in der Cloud?
- Was macht die Cloud sicher?
Cloud Computing als solches vereinheitlicht verschiedene – teilweise altbekannte – Mechanismen und Technologien. Eine besonders populäre Art des Vertriebsmodell im Cloud Computing ist die Datencloud (Cloud Storage). Bei diesem speziellen Software as a Service (SaaS) handelt es sich um einen Dienst, der die zentralisierte, automatisierte und transparente Bereitstellung und Aktualisierung von Daten erlaubt. Bekannte Dienste dieser Art sind beispielsweise:
- Dropbox – Speichern und Austauschen von Dateien
- Evernote – Erstellen und Verwalten von Notizen
- MobileMe – Zentralisiertes Bereitstellen von Daten
- SugarSync – Sichern, Speichern, Austauschen von Dateien
Ein wichtiger Aspekt solcher Storage-Dienste in der Cloud ist, dass sie von verschiedenen Plattformen nutzbar sind. So existieren in der Regel Zugriffsmöglichkeiten über einen Webbrowser sowie Clients für unterschiedliche Betriebssysteme und mobile Geräte (Mobiltelefone, Tablets).
Für den Datenaustausch kommen oftmals klassische Kanäle, wie zum Beispiel Web (HTTP/HTTPS) zum Tragen. Umso schwieriger wird es deshalb, die Nutzungsmöglichkeit solcher Dienste im geschäftlichen Umfeld auf technischer Ebene überwachen und einschränken zu können.
In so manchen Fällen macht der Einsatz solcher Dienste Sinn. Und umso schwieriger wird es oftmals ein gänzliches Unterbinden der Nutzung vor dem Management und den Arbeitnehmern zu rechtfertigen. Anstelle einer vollumfänglichen Einschränkung kann versucht werden klare Regeln für die sichere Nutzung zu definieren. Ein kleines Beispiel:
| Cloud-Anbieter | Prio | |
|---|---|---|
| A-1 | Nur vertrauenswürdige Cloud-Anbieter nutzen | 2 |
| A-2 | Nur inländische Cloud-Anbieter/-Lokationen nutzen | 2 |
| A-3 | Keine Zugriffe externer Dienste auf die Cloud | 1 |
| Datenklassifizierung | Prio | |
| D-1 | Nur mobil erforderliche Daten in der Cloud ablegen | 1 |
| D-2 | Keine Kundendaten in der Cloud ablegen | 1 |
| D-3 | Keine geheimen Daten in der Cloud ablegen | 1 |
| D-4 | Keine sensitiven Daten in der Cloud ablegen | 2 |
| D-5 | Kundenidentifizierende Daten anonymisiert in der Cloud ablegen (Codenamen) | 2 |
| D-6 | Sensitive Daten nur verschlüsselt in der Cloud ablegen | 2 |
| D-7 | Verschlüsselte Daten in der Cloud mit mindestens AES256 ablegen | 3 |
| Zugriffsschutz | Prio | |
| Z-1 | Einsatz eines sicheren Passworts (mind. 6 Zeichen, Gross-/Kleinschreibung, etc.) | 1 |
| Z-2 | Regelmässiges Ändern des Passworts (z.B. alle 90 Tage) | 2 |
| Z-3 | Zugriffe nur über gesicherte Endpunkte (z.B. nur Firmenlaptop, kein Internet-Café) | 2 |
| Z-4 | Zugriffe nur über verschlüsselte Kanäle (z.B. HTTPS/SSL, VPN/IPsec) | 1 |
| Verwaltung | Prio | |
| V-1 | Löschen nicht mehr benötigter Daten in der Cloud | 2 |
| V-2 | Löschen nicht mehr benötigter Cloud-Konten | 3 |
| ... | ||
Ähnlich wie bei der Nutzung von Sozialen Netzwerken wird mit dem Auslassen eines absoluten Verbots verhindert, dass sich die Anwender um eine Überwindung dessen bemühen. Können sie dies nicht tun, stellt sich irgendwann Frustration und Neid gegenüber anderen, die diese neuen Dienste nutzen können, ein. Ein frustrierter Mitarbeiter ist langfristig auf allen Ebenen die grösste Gefahr für ein Unternehmen.
Mit dem Definieren klarer Richtlinien kann stattdessen der richtige und sichere Umgang mit den neuen Möglichkeiten beigebracht und durchgesetzt werden. Die Mündigkeit der Benutzer wird so gewahrt und ihnen damit einen grossen Teil der erforderlichen Wertschätzung zugetragen. Gleichzeitig kann man damit Missverständnissen und Leichtsinnigkeiten, die zu Sicherheitsproblemen führen können, vorbeugen.
► 29.04.2011 – Blog Digest April 2011
- Anatomy of an Attack (02.04.2011), blogs.rsa.com, attack vector disclosed
- Anatomy of a Twitter worm (Profile Spy) (04.04.2011), Robert Graham, erratasec.blogspot.com
- Are Megabreaches Out? E-Thefts Downsized in 2010 (19.04.2011), dataloss measuring is not easy
- Cloud Computing: 5 Topics for the Boss (20.04.2011), high-level summary of requirements
- Covert hard drive fragmentation embeds a spy’s secrets (25.04.2011), newscientist.com, clever steganography
- CSRF and Beyond (26.04.2011), deadliestwebattacks.com, very nice summary
- Detecting Cheaters (07.04.2011), schneier, schneier.com
- Filejacking: How to make a file server from your browser (with HTML5 of course) (15.04.2011), interesting approach
- Finding Security Vulnerabilities in PHP Using Grep (29.03.2011), rdewhurst, resources.infosecinstitute.com
- Introducing the Cisco IOS Software Checker (26.04.2011), blogs.cisco.com, quick identification possible
- iPhone Security: 10 Tips and Settings (28.03.2011), resources.infosecinstitute.com, nice check list
- IPv6 Security Testing (22.04.2011), Earl Carter, blogs.cisco.com
- Is APT really about the person and not the malware? (19.04.2011), fasthorizon.blogspot.com, professional attacks require professional countermeasures
- Keystroke loggers now available for iOS? (08.04.2011), Chester Wisniewski
- Making sense of RSA ACE server audit logs (29.03.2011), isc.sans.org
- Microsoft Builds Legal Weapon to Take Apart Botnets (12.04.2011), threatpost.com, times have changed
- Microsoft’s ‘Coordinated Vulnerability Disclosure’ (21.04.2011), Robert Graham, erratasec.blogspot.com
- Mobile Apps Invading Your Privacy (06.04.2011), Tyler Shields, veracode.com
- ModSecurity Advanced Topic of the Week: Integrating IDS Signatures (21.04.2011), Ryan Barnett
- Pros and Cons of ‘Secure’ Wi-Fi Access (10.04.2011), isc.sans.org
- ‘Schneier’s Law’ (15.04.2011), schneier.com, true for all security systems
- Securing IPv6 (07.04.2011), Earl Carter, blogs.cisco.com
- Software Bugs and Scientific Progress (29.03.2011), possible categorization
- SSL and the Future of Authenticity (12.04.2011), threatpost.com
- TDSS part 1: The x64 Dollar Question (19.04.2011), resources.infosecinstitute.com, very detailed analysis
- Value Loss Coverage (20.04.2011), an underrated risk
- VirusTotal plugin for IDA Pro (22.04.2011), hexblog.com, great feature
- Whitehats pierce giant hole in Microsoft security shield (19.04.2011), go.theregister.com, bypassing heap protection
► 28.04.2011 – PlayStation Network Breach: Fakten und Gerüchte
Der Elektronikkonzern Sony informierte gestern Benutzer seiner Onlinedienste Playstation Network (PSN) und Qriocity per E-Mail über einen elektronischen Einbruch, der gemäss Aussagen der Firma zwischen dem 17. und dem 19. April stattfand. Auf dem Spiel stehen gemäss offiziellen Informationen des Herstellers die Benutzer- und Kreditkartendaten von rund 70 Millionen Kunden.
Sonys Pressesprecher Patrick Seybold sagte gestern in einem Blogpost, man habe eine externe Sicherheitsfirma mit der Investigation und Mitigation des Angriffs beauftragt und arbeite derzeit am Neuaufbau der Umgebung, die mittlerweile seit über einer Woche ausser Betrieb steht. Er äussert sich weiter zu den kompromittierten Daten:
Although we are still investigating the details of this incident, we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network/Qriocity password and login, and handle/PSN online ID. It is also possible that your profile data, including purchase history and billing address (city, state, zip), and your PlayStation Network/Qriocity password security answers may have been obtained. (Quelle: PlayStation Blog)
Seybold äusserte sich ausserdem zur möglichen Kompromittierung von Kreditkartendaten, die von Benutzern hinterlegt wurden, um Inhalte online zu erwerben:
While there is no evidence at this time that credit card data was taken, we cannot rule out the possibility. If you have provided your credit card data through PlayStation Network or Qriocity, out of an abundance of caution we are advising you that your credit card number (excluding security code) and expiration date may have been obtained. (Quelle: PlayStation Blog)
Die bewusst vorsichtige Formulierung hier deutet klar darauf hin, dass eine vollständige Kompromittierung der Daten stattgefunden hat, die man aber aus PR-Gründen möglichst nicht bestätigen möchte. Kurz gesagt wurden sämtliche Daten, die der Benutzer bei der Anmeldung oder danach eingegeben hat – Name, Adresse, Geburtsdatum, Benutzername und Passwort sowie Kreditkartendaten – entwendet.
Allgemein lässt Sonys Krisenkommunikation in dieser Sache stark an der Integrität des Konzerns zweifeln: Während das Ausmass des Zwischenfalls erst gestern bekannt wurde, ist das PlayStation Network bereits seit einer guten Woche offline. Bereits am 22. April bestätigte Sony einen Zwischenfall ohne jedoch auf jegliche Details einzugehen. Während Sony seitdem konstant darauf pochte die Sache zu untersuchen, fühlten sich Kunden im Dunkeln gelassen und verschafften ihrem Unmut Luft über die Kommentarfunktion des Blogs.
Obwohl Sony zumindest bestätigt hat, dass eine Kompromittierung von Daten stattgefunden hat, bleiben die genauen Hintergründe bis dato unbekannt. Verschiedene Gerüchte ranken sich derzeit um die Gründe und die Folgen des Angriffs:
Custom Firmware (CFW) erlaubt Zugriff auf Developer Network
Der Reddit User Chesh, angeblich ein Mitglieder von psx-scene.com – eine Seite, die sich mit dem Hacking von PlayStations beschäftigt – erklärte, dass der Zwischenfall aufgrund einer Schwachstelle der PS3 Firmware namens REBUG zustande kam, die es einem Benutzer erlaubte auf Developer Netzwerke zuzugreifen:
Rebug was released on 3/31/11. First guides of how to use the dev network to get back on COD games on 4/3/11. Word of NGU users finding a way to pirate PSN content via the dev networks on 4/7/11 (basing this on posts I had to delete on the website. Update: Users have pointed out to me that these posts existed on NGU as of 4/2/11). PSN goes down on 4/20/11 (Quelle: Reddit)
Die Erklärung impliziert ebenfalls, dass Sony innerhalb der Dev Netzwerkbereiche gewisse Daten nicht validierte. “Gewisse Daten” umfasst in diesem Fall Kreditkarteninformationen beim Kauf von Inhalten, was innert kürzester Zeit zu einem Anstieg von Raubkopien geführt hätte. Die Erklärung erscheint insofern schlüssig, als dass der potenzielle finanzielle Verlust durch die Verwandlung des PSN in einen kostenfreien Selbstbedienungsladen für Sony hier gross genug wäre, um eine Abschaltung über einen derart langen Zeitraum zu rechtfertigen.
Ausnutzung von Schwachstellen im Perimeter des PSN Network
Nicht geklärt wird hier allerdings, wie es zum Einbruch kam, der einem Angreifer Zugriff auf die obengenannten Benutzerdaten gab. Eine Reihe von Chatlogs des Channels #ps3dev auf EFNET gibt Ansatzpunkte auf mögliche Schwachstellen in den eingesetzten Systemen (ungepatchte Apache-Webserver, etc.). Konkrete Informationen sind aber bislang nicht verfügbar, auch wenn entsprechende Recherchen mit grossem Elan vorangetrieben werden.
Flächendeckende Passwort Re-Use Attacken
Wir empfehlen sämtlichen PSN Benutzern, gewisse Vorsichtsmassnahmen sobald wie möglich zu treffen. Die wichtigste Massnahme dürfte es sein, einen Passwortwechsel bei Diensten durchzuführen, bei denen das selbe Passwort wie im PlayStation Network genutzt wurde. HD Moore implizierte heute morgen in einem Tweet, dass grossangelegte Password-Reuse Attacken im Gange sind:
@hdmoore (HD Moore): Rumor is the Sony PSN account database is being used to crack the associated email accounts via password reuse (and they were cleartext).
@stfn42 (Stefan Friedli): Which part is the rumor? The password reuse attack attempts, the fact they used cleartext password storage or both?
@hdmoore (HD Moore): Both (sony hasn’t officially said clear-text, even if its implied), various firms dealing with wide-scale password reuse attempts.
Ebenfalls empfehlen wir, Kreditkartenabrechnungen sehr genau zu betrachten und bei verdächtigen Belastungen sofort mit dem ausstellenden Institut (Viseca/Swisscard/...) Kontakt aufzunehmen.
Das Incident Response Team der scip AG betrachtet die Entwicklung in dieser Sache aktiv und wird gegebenenfalls über neue Entwicklung berichten.
Stefan Friedli | G+ (943 Wörter)
► 21.04.2011 – Firefox-Addons für Penetration Tests
Eine Vielzahl der Client/Server-basierten Anwendungen werden heutzutage als Webapplikationen umgesetzt. Der Grund dafür ist vielfältig. In erster Linie kann der Nutzen der etablierten Techniken nicht bestritten werden. Auf der Basis webfähiger Programmiersprachen lassen sich innert kürzester Zeit Anwendungen entwickeln, die sich komfortabel über bestehende Browser in einem Netzwerk oder über das Internet nutzen lassen.
Sodann wird es für Penetration Tester immer wichtiger, sich mit Webapplikationen auseinanderzusetzen. Die manuelle Prüfung individueller Lösungen kann jenachdem sehr aufwendig sein. Durch die Modularität des beliebten Webbrowsers Firefox ist es möglich, zusätzliche Addons zu installieren und damit den Browser für derlei Tätigkeit zugeschnittene Funktionen zu erweitern.
Nachfolgend sollen einige der nützlichsten Firefox Addons für Web Application Penetration Tests vorgestellt werden. Die gezeigte Tabelle unterscheidet je nach Anwendungszweck. In der letzten Spalte wird die Bewertung des Addons in einer Skala von 1-5 ausgewiesen.
| Allgemein / Debugging | ||
|---|---|---|
| Web Developer | Diverse Funktionalitäten für Entwickler | ★★★★★ |
| Firebug | Debugging und Anpassung von Webseiten | ★★★★★ |
| Greasemonkey | Dynamische Anpassung von Webseiten | ★★★★★ |
| Modifikation von Anfragen | ||
| Groundspeed | Modifikation von Formularen/Event-Handler | ★★★★☆ |
| Tamper Data | Modifikation von Anfragen | ★★★☆☆ |
| Modify Headers | Modifikation von Header | ★★★☆☆ |
| User Agent Switcher | Modifikation des User-Agent | ★★★☆☆ |
| RefControl | Manipulieren des Referer | ★★☆☆☆ |
| No-Referer | Deaktivieren des Referer | ★★☆☆☆ |
| X-Forwarded-For Spoofer | Manipulieren des X-Forwarded-For | ★★☆☆☆ |
| Sniffing | ||
| Live HTTP Headers | Mitlesen der HTTP-Kommunikation | ★★★★★ |
| Caching und Blocking | ||
| Adblock Plus | Entfernen von Seitenelementen | ★★★★★ |
| NoScript | Deaktivieren aktiver Inhalte | ★★★★☆ |
| BetterCache | Konfigurieren des Browser-Cache | ★★★☆☆ |
| CookieSafe | Einschränken des Cookie-Handling | ★★☆☆☆ |
| Footprinting und Auswertung | ||
| TinEye Reverse Image Search | Identifikation von Bildquellen | ★★★★☆ |
| PassiveRecon | Footprinting einer Webseite | ★★★☆☆ |
| Server Spy | Anzeigen der Server-Zeile (Banner) | ★★★☆☆ |
| Automatisiertes Testing | ||
| iMacros for Firefox | Automatisierung mittels Makros | ★★★★★ |
| HackBar | Einfache Web-Angriffe automatisieren | ★★☆☆☆ |
| SQL Inject Me | Einfache SQL-Injection automatisieren | ★★☆☆☆ |
| XSS Me | Einfache Cross Site Scripting automatisieren | ★★☆☆☆ |
| RESTTest | Manuelle Generierung von Anfragen | ★☆☆☆☆ |
Hinweis
Nicht erst seit dem Zwischenfall zu Beginn des Jahres 2010, bei dem korrupter Programmcode in Firefox-Addons vermutet wurde, ist es angeraten, a) Addons nur aus vertrauenswürdiger Quelle zu installieren, b) sie mit einer Antiviren-Lösung auf korrupten Programmcode hin zu testen sowie c) den Quelltext auf etwaige Backdoor-Mechanismen zu überprüfen.
Marc Ruef | G+ und Stefan Friedli | G+ (537 Wörter)
► 14.04.2011 – Kritik an Proxies als Massnahme
Im klassischen Firewalling werden die beiden Technologien Packet Filter und Application Gateway vorgesehen. Letztere ist durch das Anbieten dedizierter Application Level Proxies für einzelne Anwendungsprotokolle darum bemüht, eine Entkoppelung eines Dienstes vorzunehmen. Als Common Point of Trust wird das Sicherheitselement zwischen Client und Server geschaltet:
Client ↔ Proxy ↔ Server
Ein Proxy ist darum bemüht, die Unstimmigkeiten einer Kommunikation zu erkennen, einzuschränken und zu protokollieren. Wird also eine deformierte HTTP-Anfrage über einen Webproxy geschickt, sollte er entsprechend darauf reagieren können. Die Angriffsmöglichkeit gegenüber dem Zielsystem – dem eigentlichen Server -, soll durch das vorgeschaltete Element abgefangen und neutralisiert werden. Im besten Fall erreicht der Angriffsversuch also nie das angegriffene System, unabhängig von einer etwaigen Verwundbarkeit dessen:
Client → Proxy ↛ Server
Gehen wir nun davon aus, dass auf dem Server eine Schwachstelle existiert. Diese kann durch eine böswillige HTTP-Anfrage ausgenutzt werden. Ein Direktzugriff führt also zum Erfolg der entsprechenden Attacke. Der Proxy erkennt jedoch die Deformierung und kann den Angriff frühzeitig abblocken. Damit übernimmt er eine zentrale Aufgabe, die eigentlich dem Server hätte zuteil werden sollen. Denn eigentlich ist letzterer selbst dafür zuständig, sich selbst sicher anzubieten. Durch einen Proxy kann damit eine mehrschichtige Sicherheit (Multilevel Security) erreicht werden.
Mit diesem Prinzip gehen jedoch Einschränkungen einher. Weist zum Beispiel das vorgeschaltete Sicherheitslement eine Schwachstelle auf – sei dies nun eine programmtechnische Verwundbarkeit oder ein versehentlich eingeführter Fehler in den Konfigurationseinstellungen -, kann dieses seine Aufgabe nicht mehr wahrnehmen. Wird auf das Erreichen des gewünschten Sicherheitsstands auf der Applikation verzichtet, ist diese trotz Sicherheitselement – aufgrund seiner Transparenz – angreifbar. Es ist also wichtig, eine echte mehrschichtige Sicherheit zu erreichen, indem auf allen Ebenen Massnahmen angestrebt werden.
Client ↔ Proxy mit Schwachstelle ↔ Server
Das zweite Problem besteht in einem grundlegenden Missverständnis, welches Proxy-Lösungen entgegengebracht wird. Es wird oftmals fälschlicherweise per se angenommen, dass diese Angriffe pauschal erkennen und verhindern können. Tatsächlich ist es jedoch in erster Linie nur die Aufgabe des Proxies, Verletzungen der Standardisierung des eingesetzten Protokolls anhand eines wohldefinierten Prototyping zu erkennen. Dies können zum Beispiel fehlerhafte Werte in einer Header-Zeile sein.
Wird jedoch ein Angriff angestrebt, der keine Verletzungen dieser Art erfordert, kann der Proxy nicht ohne weiteres reagieren. Ein durch ihn erlaubter Zugriff wird voraussichtlich auch durch den Server als solchen wahrgenommen (das gleiche Problem haftet seit jeher Antiviren- und IDS-Lösungen an):
Client ↔ Proxy erlaubt Zugriff ↔ Server erlaubt Zugriff
Es ist wichtig zu verstehen, dass Proxies a) in erster Linie als ergänzende Massnahme im Rahmen einer mehrschichtigen Sicherheitslösung eingesetzt werden sollten und b) netzwerk- und applikationsindividuelle Anpassungen an der Installation vorgenommen werden müssen. Hierzu muss sowohl die Funktionsweise der Proxylösung als auch jene der zu schützenden Dienste umfassend verstanden und eingeschränkt werden. Oftmals ginge mit einem solch durchdringenden Verständnis ebenfalls die Möglichkeit einer umfassenden Absicherung des Endpunkts einher. Und dadurch generiert sich das klassische Dilemma:
Ein Proxy ist erst dann von echtem Nutzen, wenn er nicht mehr erforderlich wäre. q.e.d.
Ein Proxy-Element kann dann von unweigerlichem Nutzen sein, wenn keine direkte oder mittelfristige Möglichkeit besteht, den Server bzw. die darauf angebotene Applikation sicher zu machen. Zum Beispiel, weil eine geschlossene Lösung eingesetzt wird, die man nicht nach Belieben anpassen kann. Oder weil die Betreuung der betroffenen Komponenten durch eine externe Firma vorgenommen wird, und man deren Massnahmen nicht beeinflussen kann. In solchen Momenten vermag ein Proxy-Element ein gewisses Mass an Flexibilität und Unabhängigkeit zu erlangen.
Mit dem Einführen eines Proxies wird aber – abgesehen von der Gefahr einer falschen Sicherheit bei einer fehlerhaften Nutzung – ebenfalls eine zusätzliche Komplexität eingeführt. Diese kann zu Problemen im Betrieb führen, die sich ebenfalls direkt oder indirekt auf die Sicherheit der Umgebung auswirken können. Ein typisches und nicht zu unterschätzendes Beispiel ist die versehentliche Abschaltung der Proxy-Komponente, wodurch ungwollt eine unmittelbare Exponierung der (potentiell) verwundbaren Dienste stattfindet. Schon so manches Unternehmen musste in schmerzvoller Weise erfahren, dass damit die errichtete Sicherheit nur von temporärem Nutzen war.
► 07.04.2011 – Windows 7 Hardening: Eine Übersicht
Im letztjährigen scip IT Security Forecast haben wir darauf hingewiesen, dass Windows 7 in naher Zukunft eine zentrale Rolle spielen wird. Immer mehr unserer Kunden beginnen mit einer Migration, die vorzugsweise von Windows XP ausgeht (die allermeisten haben Windows Vista ausgelassen).
Im Rahmen der Einführung und Nutzung von Windows 7 stellt sich für viele Kunden die Frage, welcher Sicherheitsgewinn durch die neueste Windows-Generation gegeben sein wird. Bei der Umsetzung umfassender Hardening-Projekte für verschiedene Kunden haben wir Windows 7 intensiv analysiert und die neuen Sicherheitsfunktionen auf ihre Auswirkungen hin untersucht. Unsere Erkenntnisse wollen wir hier zusammenfassen:
- Überarbeitung der User Account Control (UAC): Die Benutzerkontensteuerung wurde mit Windows Vista eingeführt und für Windows 7 optimiert. Sie verhindert, dass normale Benutzer systemkritische Anpassungen durchführen können. Zuerst muss eine explizite Authentisierung mit administrativen Rechten geschehen, um den Zugriff umzusetzen. Gerade in Umgebungen, in denen normale Benutzer ebenfalls administrative Handlungen vollziehen können müssen, erhöht diese Hürde die Sicherheit des Systems sowohl auf technischer als auch auf psychologischer Ebene (zusätzliche Hürde).
- Einführung von AppLocker: AppLocker ist eine neue Komponente von Windows 7 Enterprise, die es Administratoren erlaubt festzulegen, welche Anwendungen im Unternehmensnetz gestartet werden können. Durch granulare Einstellungen der Group Policies (GPO) kann so verhindert werden, dass unliebsamer Code eingebracht und ausgeführt wird. Damit wird sowohl ein Exploiting durch interne Mitarbeiter als auch eine Infektion durch Malware eingeschränkt. Dieses HIPS-ähnliche Feature gilt bisher wohl mitunter als das am meisten unterschätzte.
- Einführung von BitLocker (TPM): Bei BitLocker handelt es sich um die seit Vista von Microsoft bei den Ausführungen Ultimate und Enterprise mitgelieferte Festplattenverschlüsselung. Auf einer separaten Partition nutzt BitLocker das Trusted Platform Module (TPM), um den Zugriff auf die mit AES geschützten Daten durchzuführen. Vor allem mobile Geräte können so in Bezug auf Diebstahl zusätzlich abgesichert werden. In der Registry finden sich rund 70 neue Einstellungen, die in Bezug auf BitLocker/TPM wichtig sind.
- Einführung von Windows Defender: Bei Windows Defender handelt es sich um eine freie Anti-Spyware Lösung von Microsoft. Bei Windows Vista und Windows 7 ist sie (im Gegensatz zu Windows XP und Server 2003) schon vorinstalliert und damit fest im System verankert. Durch die automatische Prüfung auf etwaige Malware können breitflächige Infektionen ohne zusätzliche Aufwände frühzeitig erkannt und verhindert werden. Gerade populäre Malware-Outbreaks sollen so eingedämmt werden können. Ein echter Ersatz für eine eigenständige Antiviren-Lösung ist dies jedoch nicht.
- Erweiterung der Security Policy Settings: Es wurden einige neue Security Policy Settings eingeführt, die sich vor allem zur Härtung bei lokalen Zugriffen eignen (z.B. Change Time Zone, Crate Symbolic Links). Aber auch erweiterte Netzwerkeinstellungen bezüglich der Unterstützung von NTLM wurden eingeführt. Dadurch können die Installation noch genauer den individuellen Bedürfnissen, vor allem in Hochsicherheitsumgebungen, angepasst werden.
- Überarbeitung der Windows Firewall: Die mit Windows XP eingeführte Windows Firewall wurde in Windows 7 komplett überarbeitet. Diese bietet nun zusätzliche Möglichkeiten an, um Netzwerkkommunikationen einzuschränken. Dabei besteht die Möglichkeit, sehr granulare Einstellungen für Applikationen (ausführbare Dateien) und Hosts/Ports vorzunehmen. Damit wird vielerorts die zusätzliche Nutzung von 3rd Party Lösungen überflüssig.
- Einführung von DirectAccess: Mit DirectAccess wird in Windows 7 Enterprise und Ultimate eine erweiterte VPN-Funktionalität dargeboten. Diese erlaubt die für den Nutzer gänzlich transparente Nutzung des VPN (Virtual Private Network), wobei noch vor dem Zugriff auf die Windows-Domäne die entsprechenden Gruppenrichtlinien angewendet werden. Ein Arbeiten ausserhalb des eigentlichen Netzwerks ist dadurch einfach und dennoch sicher möglich.
- Einführung neuer Services: Es werden einige neue Dienste eingeführt. Bei Windows 7 sind 165 Dienste im Gegensatz zu 90 Diensten bei Windows XP gegeben. Dies erhöht entsprechend die Komplexität des Hardenings. Eine interessante Funktionalität ist der neue Start-Typ
Automatic (Delayed), der eine zeitverzögerte Initiierung eines Dienstes erlaubt, um den Start des Betriebssystems zu beschleunigen.
- Erweiterung der Sicherheit von Freigaben: Die Sicherheit von Shares wurde schon bei Windows XP – im Gegensatz zu 9x/ME – massgeblich erhöht. Mit Windows Vista und Windows 7 wurden nun zusätzliche Einstellungsmöglichkeiten eingeführt, die einen dediziert restriktiven Zugriff auf entsprechende Freigaben umsetzen lassen. Die Standardeinstellungen stellen dabei einen zur Zeit vertretbaren Kompromiss aus Rückwärtskompatibilität und Sicherheit dar. Punktuelle Anpassungen können die jeweiligen Bedürfnisse priorisieren lassen.
- Umfassende Unterstützung von IPv6: Windows 7 kommt ab Installation mit einer vollumfänglichen Unterstützung von IPv6 daher. Diese ist standardmässig ebenfalls aktiviert und bietet damit ebenso ein erhöhtes Mass der Angriffsfläche bzw. Möglichkeiten zur Nutzung der IPv6-Sicherheitsfunktionen. Entsprechende Anpassungen sind im Zug eines Hardenings angeraten.
- Abschaffung einiger alter DOS-Komponenten: Einige alte Komponenten, die bei MS DOS eingeführt und aus Kompatibilitätsgründen bis heute mitgeführt wurden, wurden nun endgültig eliminiert. Dazu gehören beispielsweise einige kommandozeilenbasierte Programme, die im
SYSTEM32-Verzeichnis gelagert werden. Das manuelle Löschen oder das Durchsetzen von restriktiven Zugriffsrechten auf NTFS-Ebene fällt damit teilweise weg.
Unser gegenwärtig bei verschiedenen Kunden im Einsatz befindliches Hardening-Framework sieht 531 sicherheitsrelevante Einstellungen für Windows XP vor. Bei Windows 7 sind es zur Zeit 684 mögliche Hardening-Punkte. Diese Statistik zeigt in eindrücklicher Weise auf, dass Microsoft vielerorts um die Erweiterung der Sicherheitsfunktionalität der neuesten Windows-Generation bemüht war. Mitunter aus diesem Grund können wir unseren Kunden anraten, mittelfristig (1-3 Jahre) ein Upgrade auf Windows 7 vorzunehmen.
► 31.03.2011 – Blog Digest März 2011
- 2010 Defacements Statistics: Almost 1,5 million websites defaced, what it is happening? (01.03.2011), zone-h.org
- 20 years of innovative Windows malware (01.03.2011), infoworld.com
- Announcing the Unstable Module Tree (20.03.2011), hdm
- Application Security Debt and Application Interest Rates (25.02.2011), Chris Wysopal, veracode.com
- APT – There.. I Said It. (24.03.2011), Paul Asadoorian, blog.tenablesecurity.com
- Botnet Reputation and Content Scanning in Nessus (16.03.2011), blog.tenablesecurity.com
- Cryptographic Algorithm Transitions (2010-2011) (24.03.2011), Panos Kampanakis, blogs.cisco.com
- data loss prevention: a red herring (19.03.2011), blackcatsandsmokeandmirrors.blogspot.com
- Debugging Fundamentals for Exploit Development (28.02.2011), Bradshaw Stephen, resources.infosecinstitute.com
- Defining Penetration Testing (04.03.2011), iamit, iamit.org
- Hacking crappy password resets (part 1) (09.03.2011), Ron Bowes, skullsecurity.org
- HD Moore Reveals His Process for Security Research (22.03.2011), Jack Koziol, resources.infosecinstitute.com
- Identifying the Mobile Security Stack (24.03.2011), Tyler Shields, veracode.com
- iPhone Security: 10 Tips and Settings (28.03.2011), resources.infosecinstitute.com
- Least Priviledge in Windows (21.03.2011), Roger, infosecblog.org
- Making sense of RSA ACE server audit logs, (Tue, Mar 29th) (29.03.2011), isc.sans.org
- Metasploit Framework 3.6.0 Released! (07.03.2011)
- Nmap? In my Metasploit? It’s more likely than you’d think! (15.03.2011), todb
- Partitioning my digital life into security domains (13.03.2011), theinvisiblethings.blogspot.com
- Pwn2own considered (somewhat) harmful (12.03.2011), Michal Zalewski, lcamtuf.blogspot.com
- Risk management: what do it mean? (22.03.2011), erratasec.blogspot.com
- RSA Clients Manage Risks (23.03.2011)
- Security and efficiency (27.02.2011), blogs.securiteam.com
- Security firm RSA warns that its servers have been hacked (18.03.2011)
- Software Bugs and Scientific Progress (29.03.2011)
- SpyEye, ZeuS Users Target Tracker Sites (09.03.2011), Brian Krebs
- Stack Based Buffer Overflow Tutorial, part 1 – Introduction (09.03.2011), Bradshaw Stephen, resources.infosecinstitute.com
- Standards for Penetration Testing (18.03.2011), tmiltner, resources.infosecinstitute.com
- Stop Building HTML on the Server (24.03.2011), book, deadliestwebattacks.com
- Study: Breaches Cost $214 Per Record (09.03.2011)
- the most important infosec component (12.03.2011), Mimi Herrmann, blogs.securiteam.com
- Time Line of Major Global Cyber Incidents 2010-2011 (19.03.2011)
- Warning: OBJECT and EMBED are inherently unsafe (07.03.2011), lcamtuf.blogspot.com
- Why Multifactor Authentication Fails (15.03.2011)
- Windows Security Center: Under the Hood (21.03.2011), blog.didierstevens.com
► 23.03.2011 – Kompromittierung von RSA – Fakten und Einschätzung
Dieser Artikel wurde das letzte Mal aktualisiert am 11. Oktober 2011 19:45 Uhr
Das Unternehmen RSA Security – es ist seit 2006 Teil der EMC Corp. – ist in erster Linie durch ihre Lösung SecurID bekannt geworden. Diese gilt als das wohl populärste Produkt zur Umsetzung strenger Authentisierung. Ein Benutzer muss dabei neben Benutzername und Passwort ebenfalls einen dritten Faktor mitgeben. Dieser wird durch einen SecurID-Token erzeugt. Dabei handelt es sich um einen sechs- bis achtstelligen Zahlencode, der alle 60 Sekunden aktualisiert wird. Durch eine vorgängige Synchronisation mit dem RSA-Server wird es durch eben diesen möglich, die Legitimität der Authentisierung zu erkennen. Sieht sich ein Angreifer in der Lage Benutzername, Passwort und Token abzufangen, kann er diese Daten maximal 60 Sekunden für eine erfolgreiche Authentisierung nutzen. Danach ist der dritte Faktor, der Zufallscode des Token, nutzlos.
Zwischenfall und Veröffentlichung
Am 17. März 2011 veröffentlicht Art Coviello, CEO von RSA, auf der Unternehmenswebseite einen offenen Brief. In diesem weist er mit Bedauern darauf hin, dass eine Kompromittierung der RSA-Systeme stattgefunden hat und eine nicht näher definierte Gefahr für die SecurID-Lösungen besteht:
Recently, our security systems identified an extremely sophisticated cyber attack in progress being mounted against RSA. (...) Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products.
In diesem Zusammenhang wird der umstrittene Begriff APT (Advanced Persistant Threat) genutzt, um auf die technische Überlegenheit der Angreifer hinzuweisen. Technische Details zur Attacke oder den betroffenen Komponenten werden nicht genannt.
Tage nach der Veröffentlichung dieses Schreibens wurde durch Uri Rivner, Head of New Technologies, ein eher technischer Blog-Post herausgegeben. In diesem wird das grundlegende Vorgehen der Angreifer skizziert (Zusammenfassung):
The attacker in this case sent two different phishing emails over a two-day period. The two emails were sent to two small groups of employees; you wouldn’t consider these users particularly high profile or high value targets. The email subject line read “2011 Recruitment Plan.” (...) The spreadsheet contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (CVE-2011-0609). (...) As you know, the next step in a typical APT is to install some sort of a remote administration tool that allows the attacker to control the machine. In our case the weapon of choice was a Poison Ivy variant set in a reverse-connect mode that makes it more difficult to detect, as the PC reaches out to the command and control rather than the other way around.
So schien es, als würde wirklich jemand eine zielgerichtete Attacke gegen RSA umsetzen wollen. Die technische Umsetzung dieser war jedoch nicht besonders ausgeklügelt, da sie sich vorwiegend auf altbekannte Mechanismen und Schwachstellen verliess. Ob die Angreifer wirklich von Anfang an darum bemüht waren, technische Details zur SecurID-Lösung zu erlangen, lässt sich zur Zeit nicht sagen.
Mutmassungen und Gerüchte
Nach Veröffentlichung dieser Mitteilung wurde auf Twitter, in Blogs und den Medien sehr viel über den Fall berichtet. Aufgrund der sehr dünnen Faktenlage wurden Mutmassungen in alle Richtungen angestossen. Zuerst ging man davon aus, dass technische Details zur Umsetzung der RSA-Lösung – vielleicht sogar der Programmcode der eingesetzten Komponenten – gestohlen wurde.
Dies wäre vor allem für Mitbewerber von Interesse, die um den Nachbau oder die Herstellung von kompatiblen Komponenten bemüht sind. Für die Sicherheit der Lösung hätte dies eigentlich, wäre sie denn designtechnisch intelligent umgesetzt, keinen weitreichenden Einfluss. Denkbar wäre das Finden und Ausnutzen einer bis dato unbekannten technischen Schwachstelle.
Viel eher ist jedoch anzunehmen, dass das Root Seed File gestohlen wurde. Hierbei handelt es sich um einen 16-stelligen Code, der für die Individualisierung aller Token eingesetzt wird. Der Seed hat direkten Einfluss auf die Generierung der Codes durch das Token. RSA speichert die Zuweisung der Seeds zu Token, um eine entsprechende Authentisierung beglaubigen zu können.
Befindet sich jemand im nur Besitz dieser Seed-Daten, kann er theoretisch keinen Rückschlüss der Zuweisung zu einem Token umsetzen. Es bleibt zu hoffen, dass RSA die Seets getrennt von der Zuweisung aufbewahrt hat und sie nicht zusammen im Rahmen des Angriffs entwendet wurden.
Doch auch mit einem Seed alleine können für einen Angreifer Vorteile entstehen. Durch das Mitlesen eines legitimen Token-Codes und das Wissen dessen zugrundeliegenden Seeds kann er ein Reverse Engineering anstreben und dadurch zukünftigen Token-Codes errechnen. Damit wäre der Zeitfaktor, der als entscheidender Vorteil von SecurID-Lösungen gilt, nichtig. Befindet sich ein Angreifer einmal im Besitz eines legitimen Codes, kann er nach Belieben das Token auf mathematischer Ebene emulieren.
Ein davon betroffenes Token gilt als in der Praxis gebrochen und muss zurückgesetzt werden. Dies ist mit erheblichem Aufwand für die Nutzer und Betreiber einer SecurID-Lösung verbunden. Die Anwender müssen die Token zurückschicken, die Betreiber diese zurücksetzen und wieder ausliefern.
| Fakten | Quelle |
|---|---|
| RSA wurde Opfer eines Datendiebstahls | RSA/Coviello |
| Teile zum SecurID-System wurden entwendet | RSA/Coviello |
| Wird negative Auswirkung auf Sicherheit von SecurID haben | ⇒ Konklusion |
| Angriff wurde mit Spear-Phishing initiiert | RSA/Rivner |
| Excel-Dokument nutzte Schwachstelle in Flash (CVE-2011-0609) aus | RSA/Rivner |
| Poison Ivy wurde für Remote-Zugriff (Reverse-Connect) installiert | RSA/Rivner |
| Zwei unterschiedliche Gruppen sind in Angriff involviert | RSA Conference London |
| Erfolgreicher Angriff daraus gegen Lockheed Martin Corp | reuters.com nytimes.com |
| RSA ersetzt 40 Millionen kompromittierte SecurID-Token | RSA/Coviello |
| Mutmassungen | Quelle |
| Root Seed Files der Token wurden entwendet | nytimes.com |
| Zuweisung Seed/Token wurde entwendet | nytimes.com (teilweise) |
| Programmcode von SecurID-Komponenten wurde entwendet | ⇒ Gegenargument |
| Klonen von SecurID-Token möglich | reuters.com, wired.com |
| 0-Day Schwachstellen in SecurID wurden gefunden | slashdot.org, @indi303 |
| Erfolgreiche Angriffe daraus schon umgesetzt | nsslabs.com |
| Erfolgreicher Angriff daraus gegen L-3 Communications | wired.com |
| Angriff wurde von staatlichen Stellen orchestriert | RSA Conference London |
| Angriff auf RSA sollte Attacken auf Kunden ermöglichen | RSA Conference London |
Weiteres Vorgehen und Empfehlungen
Es ist fragwürdig, warum sich RSA in Bezug auf technische Details und Konsequenzen des Problems sehr bedeckt hält. Das Hinauszögern der durch die Kunden erwarteten Transparenz scheint lediglich den Angreifern in die Hände zu spielen. Der grosse Nachteil wird hierbei auf die Kunden abgewälzt.
Angeblich hat RSA vorgängig grössere Regierungsbehörden über den Zwischenfall informiert, damit diese grundlegende Massnahmen ergreifen können. Mittlerweile mehren sich auch die Berichte unserer Kunden, dass diese zwischenzeitlich auf die Nutzung von SecurID verzichten und stattdessen andere Mechanismen zur strengen Authentisierung einsetzen werden (z.B. Konkurrenzprodukte, SMS, TAN, etc.). EMC führt unabhängig davon einige generische Massnahmen in einem publizierten PDF-Dokument auf.
Wir raten unseren Kunden in Hochsicherheitsumgebungen ebenfalls zu diesem Schritt. SecurID-Lösungen in weniger kritischen Umgebungen sollten unter Beobachtung gestellt und bei verdächtigen Aktivitäten sofort reagiert werden. Bisher sind keine Angriffsversuche, die in verlässlicher Weise auf den genannten Datendiebstahl zurückzuführen sind, bekannt. Werden solche publik, sollte aber unbedingt sofort reagiert werden.
Update 23. März 2011 09:30 Uhr
Erweiterung der Mutmassungen bezüglich Zuweisung Seed/Token und 0-Day Schwachstellen.
Update 27. März 2011 17:15 Uhr
In der vergangenen Woche wurde unser Stefan Friedli von der Gratiszeitung 20 Minuten zum Fall interviewt. Sein Expertenkommentar ist ebenfalls online verfügbar. Ebenso wurde die Mutmassung der schon umgesetzten erfolgreichen Angriffe hinzugefügt.
Update 02. April 2011 17:15 Uhr
RSA hat einige grundlegende technische Details zur Umsetzung des Angriffs publik gemacht. Die darin enthaltenen Aussagen wurden in die Auflistung der Fakten übernommen.
Update 05. April 2011 11:30 Uhr
Der Hinweis auf das RAT-Tool Poison Ivy wurde den Fakten hinzugefügt. Zudem wurde das ursprüngliche Statement bezüglich APT (Advanced Persistant Threat) relativiert.
Update 30. Mai 2011 08:45 Uhr
Hinweis auf den vermeintlich erfolgreichen Angriff auf Lockheed Martin Corp als Mutmassung hinzugefügt.
Update 01. Juni 2011 13:50 Uhr
Hinweis auf den vermeintlich erfolgreichen Angriff auf L-3 Communications sowie die Mutmassung der Möglichkeit des Klonen von SecurID-Token hinzugefügt.
Update 06. Juni 2011 08:30 Uhr
Anpassung des Hinweis von Lockheed Martin, dass der identifizierte Angriff auf ihre Infrastruktur tatsächlich auf den Einbruch bei RSA zurückzuführen ist.
Update 07. Juni 2011 12:45 Uhr
Art Coviello erklärt in einem offenen Brief, dass die kompromittierten SecurID-Token ersetzt werden sollen.
Update 11. Oktober 2011 19:45 Uhr
Art Coviello und Tom Heiser nutzten ihre Eröffnungsansprachen zur RSA Conference in London, um Einzelheiten der Angriffe im März zu erläutern. Dabei äusserten sie die Vermutung, dass voraussichtlich staatliche Stellen hinter dem erfolgreichen Angriff stecken. Hierbei konnten zwei unabhängig voneinander agierende Gruppen als potentielle Täterschaft ausgemacht werden. Ziel des Angriffs war angeblich nicht RSA selber, sondern mittelfristig die Kunden des Unternehmens.
Update 13. Februar 2012 10:15 Uhr
Das Paper Command and Control in the Fifth Domain diskutiert die technischen Hintergründe des Angriffs. Dabei werden die Infektions- und Kommunikationswege im Detail besprochen.
► 17.03.2011 – Problem von OS Fingerprinting Kaskadierung
Im Rahmen von Sicherheitsüberprüfungen wird ist es von zentraler Wichtigkeit zu erkennen, welches Betriebssystem auf einem Zielsystem eingesetzt wird. Die Identifikation dessen wird als OS Fingerprinting bezeichnet. Mitunter bietet beispielsweise Nmap mit dem Paramter -O die Möglichkeit, eine entsprechende Auswertung vorzunehmen.
Bei vielen Tests ist zu beobachten, dass fehlerhafte oder gar keine Resultate zusammengetragen werden. Aufgrund dessen wird gerne fälschlicherweise die Möglichkeit und Zuverlässigkeit des OS Fingerprinting in Frage gestellt.
Das OS Fingerprinting, wie es heutzutage implementiert ist, basiert auf Pattern Matching. In einer Datenbank werden die Fingerabdrücke der jeweiligen Betriebssysteme festgehalten. Im Falle von Nmap ist dies in der Regel /usr/share/nmap/nmap-os.db. Umso mehr Übereinstimmungen ein Scan aufweist, umso eher kann anhand des Fingerabdrucks das System korrekt erkannt werden. Minime Abweichungen werden dabei unter Umständen vernachlässigt, um kleinere Änderungen am System bzw. dessen Konfiguration auszugleichen.
Sind bei einem Scan zu wenige Übereinstimmungen identifiziert worden, kann das System nicht richtig bzw. gar nicht erkannt werden. Das ist natürlich dann der Fall, wenn ein komplett neues und damit in der Fingerprint-Datenbank noch nicht abgebildetes System gescannt wird. In diesem Fall muss natürlich zu erst ein neuer Datensatz für dieses System angelegt werden, um es von nun an erkennen zu können.
Doch es kann auch zu Fehlinterpretationen kommen, wenn der richtige Datensatz vorhanden wäre. Und zwar dann, wenn der Fingerprint des Zielsystems durch ein Zwischensystem verändert wird. Dies ist vor allem dann der Fall, wenn das Zielsystem durch ein Firewall-Element (Paketfilter oder Application Gateway) geschützt wird.
Die nachfolgende Abbildung zeigt auf, inwiefern ein Paketfilter partiellen Einfluss auf den Fingerprint des Zielsystems haben kann. Hierbei findet eine Kaskadierung des Zielsystems und damit eine (partielle) Überdeckung des Original-Fingerprints statt.
Das Resultat einer solchen Überdeckung ist ein sehr ungenauer Fingerprint, bei dem zwei Fingerpints (Zielsystem und Zwischensystem) vermengt werden. Daraus können vier verschiedene Effekte entstehen:
- Zielsystem wird mit verminderter Genauigkeit erkannt
- Zwischensystem wird (in gewissen Punkten) als Zielsystem erkannt
- Übereinstimmung ist zu gering und daher keine Erkennung
- Vermengung führt zur falschen Identifikation eines anderen Systems
Theoretisch besteht die Möglichkeit der Sondierung der vermengten Fingerprint-Elemente. Vor allem dann, wenn der exakte Fingerprint eines der Systeme bekannt ist, kann durch das Komplement die durch das andere System definierten Fingerprint-Elemente ausgemacht werden. Bisher existieren jedoch noch keine Lösungen, dieses Problem in effizienter und automatisierter Weise anzugehen.
Dieses Problem besteht natürlich für alle Arten des Fingerprinting. Namentlich wurde es schon vor rund zwei Jahren im Artikel Erkennen von Kaskadierungen im Fingerprinting in Bezug auf Application Fingerprinting am Beispiel von HTTP-Fingerprinting aufgegriffen (siehe ebenfalls).
Doch nur weil das Problem noch nicht einheitlich gelöst wurde, heisst es nicht, dass Fingerprinting damit generell oder unter den skizzierten Umständen seinen Sinn verliert. Nach wie vor können mittels Fingerprinting eingesetzte Mechanismen erkannt werden. Durch Software-Lösungen kann dies in effizienter und automatisierter Weise geschehen, wobei in vielen Fällen eine manuelle Querprüfung empfohlen wird, um das gewünschte Mass an Genauigkeit erreichen zu können.
Fingerprinting-Mechanismen auf Basis von Pattern Matching sind stets deterministisch anzusehen. Dies bedeutet, dass mit genügend Informationen auch immer eine exakte Aussage getroffen werden kann. Im Falle von (kommerziellen) Sicherheitsüberprüfungen bedeutet dies, dass wenn genügend Zeit vorhanden ist, sich auch fehlende oder vage Fingerprint-Identifikationen optimieren lassen.
► 10.03.2011 – Vorstellung des Penetration Testing Execution Standard
Vor nicht allzulanger Zeit habe ich in einem Meeting mit einem Kunden folgenden Ausspruch gehört: “IT Sicherheit ist keine Wissenschaft”. Der Urheber wollte damit ausdrücken, dass ein gewisses Mass an gesundem Menschenverstand und geistiger Flexibilität notwendig ist, um in der Praxis knifflige Probleme in dem Sektor lösen zu können. Ohne der Wissenschaft gesunden Menschenverstand abzusprechen, versteht sich.
Tatsächlich ist unser Tätigkeitsbereich ein sonderbares Feld. Die klassische theoretische Informatik ist ein durchaus akademischer Sektor, was sich auch im Hinblick auf die Spezialisten in vielen Gebieten auswirkt. Betrachtet man aber den Bereich der Informationssicherheit, so fällt auf, dass diese Klassifizierung hier nur bedingt gilt oder sogar widerlegt wird. Viele bekannte und anerkannte Experten auf dem Gebiet kommen nicht aus einem akademischen Umfeld, sondern aus dem Hobbybereich. Viele erfolgreiche Karrierepfade bekannter Hacker und Securityexperten haben mit einem C64 (oder vergleichbaren Gerätschaften) und einem Akustikkoppler/Modem begonnen. Jahrelange “Praxiserfahrung” sind in unserer Branche oftmals mehr wert, als ein Hochschulabschluss – ein Phänomen, dass ich auch in meinem Blogbeitrag How to Hire a Hacker im August 2010 schon angesprochen habe.
Daraus ergibt sich die Frage: Wer ist denn nun qualifiziert, um ein Unternehmen im Hinblick auf IT-Sicherheit zu beraten oder einen Penetration Test durchzuführen? Durch das Fehlen von klaren Qualifikationsmerkmalen, wird die Auswahl eines Partners zu einer unabsehbaren Lotterie. Anstatt der Qualität der Arbeit wird, mangels Referenzen, die Preise der Dienstleistungen oder hohle Marketingphrasen als Entscheidungsgrundlage missbraucht. Das endet nicht selten in verlorenem Geld, verschwendeter Zeit und einem falschen Gefühl der Sicherheit – oder im schlimmsten Fall einer unsichereren Umgebung als zuvor. Scharlatane, die ein Stück vom IT-Security Kuchen möchten, existieren zuhauf.
Das jüngste und möglicherweise prominenteste Beispiel dafür, ist der Fall von LIGATT Security und Gregory Evans. Mittels Falschaussagen, Täuschung und Plagiatrie hat es Evans sogar mehrmals ins nationale Fernsehen, unter anderem auf CNN und Bloomberg geschafft. Der hohe Fall von Evans kam erst kürzlich, als Unbekannte die gesamten E-Mails des “Worlds #1 Hackers” veröffentlichten und so dessen, teils schockierend betrügerischen, Machenschaften ins Licht der Öffentlichkeit zerrten. Wieviele zahlende Kunden Evans über die Jahre hinweg mit seiner Quacksalberei zum Narren hielt, kann zu diesem Zeitpunkt nur erahnt werden.
Während der Fall LIGATT ein Extremfall ist, so passieren unglückliche Missverständnisse durchaus häufiger. Nicht zuletzt aus diesem Grund prüfen unsere Kundenberater bei der Offertstellung immer nach, dass die geforderte Dienstleistung auch wirklich dem entspricht, was der Kunde als Endresultat möchte. Ein unzufriedener Kunde, der sich über den hohen Preis eines vollumfänglichen Penetration Tests wundert, weil er eigentlich nur eine einzelne Webapplikation auf grobe Schnitzer prüfen wollte, dies aber nicht klar artikulierte, ist nicht wünschenswert.
Verschiedene Bemühungen existieren, um diesen Missständen entgegenzutreten. Im Webapplikationsbereich hat sich das Open Web Application Security Project besonders hevorgetan, dass klare Richtlinien und konkrete Guidelines zum Entwickeln und Überprüfen von Webapplikationen geschaffen hat. Während die verfügbaren Dokumentationen sicherlich weit davon weg sind, ein perfektes und unfehlbares Referenzwerk darzustellen, hat OWASP damit einen wichtigen Schritt getan: Sowohl Kunden und Entwicklern als auch Testern einen gemeinsamen Nenner zu geben, der definiert, wie Webapplikationssicherheit auszusehen hat, welche Arten von Schwachstellen existieren und wie sie entdeckt und vermieden werden können. Perfektion ist vernachlässigbar, ein klares Verständnis, um was es geht, ist hingegen essentiell.
Während OWASP für die Überprüfung von Webapplikationen auf technischer Ebene eine solide Wahl darstellt, so war ein Standard für reguläre Penetration Tests lange nicht existent. Bestehende Versuche in diese Richtung, wie sie zum Beispiel in OSSTMM (Open Source Security Testing Methodology Manual) zu sehen sind, stellen für die meisten professionellen Tester heute aber keine ernstzunehmende Variante dar.
Um diesem Problem entgegenzutreten, formierte sich bereits Ende 2010 ein Gremium von insgesamte sieben erfahrenenen, internationalen Branchenspezialisten, um einen einheitlichen und fachlich akkuraten Standard zu schaffen. Der Name ist simpel und naheliegend: Penetration Testing Execution Standard. Die Ankündigung des Pentest Standards an der vergangenen Shmoocon in Washington stiess in der Branche auf grossen Anklang.
Der Penetration Testing Standard verfolgt das Ziel, sowohl Kunden wie auch Dienstleistern eine gemeinsame Basis für die Durchführung von technisch sinnvollen und akkuraten Penetration Tests zur Verfügung zu stellen. Während ein Standard niemals alle möglichen Szenarien abdecken kann, die im Rahmen einer solchen Überprüfung auftreten, geht es hier um einen allgemein akzeptierten Grad an technischen Überprüfung, der notwendig ist, um eine akkurate und nützliche Aussage zur Sicherheit des Prüfobjektes zu treffen. In weiteren Modulen definiert der Pentest Standard höhere “Levels”, die komplexere und aufwendigere Tests beschreiben und formalisieren. Ein weiteres Ziel ist es, Abgabedokumente und Reporting im Allgemeinen zu standardisieren und den Transfer von wichtigen, oft kritischen Informationen sicherzustellen und zu verbessern.
Der Pre-Alpha Release des PTES ist seit kurzer Zeit öffentlich verfügbar. Feedback ist erwünscht und kann direkt an die Mitglieder des Boards gerichtet werden.
Stefan Friedli | G+ (889 Wörter)
► 03.03.2011 – HTTP Request Header Tagging
Der Einsatz von WAF (Web Application Firewall) hat sich in den letzten Jahren vervielfacht. Die vorgeschalteten Komponenten sind als Reverse-Proxies umfangreich darum bemüht, den Datenverkehr auf der Anwendungsschicht (Layer 7) zu untersuchen. Klassische Angriffstechniken auf Webapplikationen, zum Beispiel Cross Site Scripting und SQL-Injection, sollen damit erkannt werden.
Das Problem ist, dass ein Proxy nur mit erheblichem Aufwand die gewollte Sicherheit für eine geschützte Anwendung erreichen können. Da sie zudem nicht oder nur wenig über die interne Applikationslogik wissen, können sie gewisse Angriffstechniken gar nicht erkennen.
Um diese Einschränkung aufzuheben, wurde im Rahmen des OWASP AppSensor Project ein neuer Punkt namens RP2: External User Behavior hinzugefügt:
This information can be used by the application to contribute to its knowleage about a potential attacker. In some cases, the information could be detected by the application itself (e.g. XSS pattern black listing), but may be more effectively identified by the external device, or is not known to the application normally (e.g. requests for missing resources that the web server sees, but does not pass onto the application).
Hierbei kommt das sogenannte Request Header Tagging zum Tragen. Bei diesem wird den untersuchten HTTP-Requests zusätzliche Header-Zeilen hinzugefügt. In nachfolgendem Beispiel ist zu sehen, wie die Header X-WAF-Events und X-WAF-Score eingesetzt werden (Beispiel aus dem ModSecurity Blog):
GET /path/to/foo.php?test=1%27%20or%20%272%27=%272%27;-- HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 X-WAF-Events: TX: / 999935-Detects common comment types-WEB_ATTACK/INJECTION-ARGS:test, TX:999923-Detects JavaScript location/document property access and window access obfuscation-WEB_ATTACK/INJECTION-REQUEST_URI_RAW, TX:950001- WEB_ATTACK/SQL_INJECTION-ARGS:test X-WAF-Score: Total=48; sqli=2; xss= Connection: Keep-Alive
Die Webapplikation selbst kann nun diese Header auswerten und im Rahmen des eigenen Anwendungsstatus definieren, wie sie mit dem Zugriff umgehen will. Vielleicht sind gewisse Angriffsmuster nicht mehr eine Gefahr und damit als False-Positive zu werten. Die WAF fungiert somit nur noch als passiver Sensor, der bei der Datensammlung aus Auswertung behilflich ist. Die Logik im Umgang mit den potentiellen Angriffsversuchen wird durch die geschützte Applikation selber realisiert.
Durch diese neu eingeführte Modularität wird natürlich die Flexibilität erhöht. Ebenso kann die Performance und Skalierbarkeit besser ausfallen, da sich die Last der Analyse/Verarbeitung auf unterschiedliche Komponenten verteilen lassen.
Gleichzeitig besteht aber auch die Gefahr, dass der Datenaustausch zwischen WAF und Webapplikation nicht oder nur begrenzt funktioniert. Wichtige Daten und Alerts könnten aufgrund der erhöhten Komplexität unterwegs verloren gehen. Oder eventuell gelingt es einem Angreifer, den Transfer zwischen den beiden Komponenten zu stören. Derlei Probleme sind aber in individueller Weise von der genutzten Implementierung und dem Einsatzgebiet abhängig und werden sich erst in zukünftigen Penetration Tests zeigen.
► 25.02.2011 – Blog Digest Februar 2011
- Analysis of MBR File System Infector (17.02.2011), f-secure.com
- Analyzing the Compromise – without Going Hungry (21.02.2011), blog.tenablesecurity.com
- Apple iOS Push Notifications: Security Implications, Abuse Scenarios, and Countermeasures (07.02.2011), SANS Institute, blogs.sans.org
- Are you sure SHA-1+salt is enough for passwords? (09.02.2011), f-secure.com
- Blog Post: Breaking up the Romance between Malware and Autorun (09.02.2011), blogs.technet.com
- Browser plugins and security considerations (11.02.2011), Julien Sobrier
- Comic for February 15, 2011 (15.02.2011), dilbert.com
- Controlling the Flow of Information in the 21st Century (08.02.2011), blogs.cisco.com
- Don’t Sacrifice Security on Mobile Devices (22.01.2011), chris, eff.org
- Educating users on the safe use of whole device encryption (29.01.2011), Chester Wisniewski
- Ethics of password cracking/dissemination (24.01.2011), skullsecurity.org
- Feature: Anonymous speaks: the inside story of the HBGary hack (16.02.2011), arstechnica.com
- Feature: Black ops: how HBGary wrote backdoors for the government (19.02.2011), arstechnica.com
- Five Key Design Decisions That Affect Security in Web Applications (10.02.2011), rohitsethi, blogs.sans.org
- How To Outrun A Lion? (17.02.2011), ctrl-alt-del.cc
- HTTP headers fun, (Tue, Feb 15th) (16.02.2011), isc.sans.org
- Ignore the OWASP Top 10 in Favor of Mike’s Top 10 (19.02.2011), deadliestwebattacks.com
- IPv6 Myths (18.02.2011), Earl Carter, blogs.cisco.com
- Kaspersky Antivirus Source code leak (KAV 8 2009) (30.01.2011), unremote.org
- Measuring password re-use empirically (09.02.2011), Joseph Bonneau, lightbluetouchpaper.org
- ModSecurity Advanced Topic of the Week: Passive Vulnerability Scanning Part 1 – OSVDB Checks (23.02.2011), Ryan Barnett
- ModSecurity Advanced Topic of the Week: Real-time Application Profiling (18.02.2011)
- Old programming habits die hard (08.02.2011), Nate Lawson, rdist.root.org
- Probabilities in Random Testing (10.02.2011), regehr
- Shmoocon 2011: Defeating mTANs for profit (29.01.2011), ChrisJohnRiley, blog.c22.cc
- Shmoocon 2011: Printer to Pwnd (29.01.2011), Chris John Riley, blog.c22.cc
- Should Software Evolve? (15.02.2011)
- Societal Security (15.02.2011), schneier.com
- Some common Infosec job roles and related certifications (08.02.2011), resources.infosecinstitute.com
- SSDs prove difficult to securely erase (20.02.2011)
- Stop Exposing Yourself! (08.02.2011), blogs.adobe.com
- The Dead Giveaways of VM-Aware Malware (28.01.2011), Atif Mushtaq
- The Lure of Notoriety for Information Security Experts (23.02.2011), blog.zeltser.com
- The Piano Test for Program Verification (27.01.2011), regehr
- To Improve Mobile Security, Policies Will Need to Change (23.02.2011), blogs.mcafee.com
- Who Verifies the Verifiers? (01.02.2011), regehr
- Why Physical (Network) Security is Important? (18.02.2011), blog.rootshell.be
- Your guide to the seven types of malicious hackers (08.02.2011), Roger A. Grimes, infoworld.com
► 17.02.2011 – Passwortlänge von Security Researcher
Wir haben bisher zwei statistische Auswertungen der Passwortlänge unterschiedlicher Benutzerklassen vorgenommen:
- Einerseits waren dies normale Benutzer, bei denen eine geschechtsspezifische Aufteilung erfolgen konnte. (Quelle)
- Zusätzlich wurde nach der Veröffentlichung der Passwörter von carders.cc ein Vergleich von Crackern mit tendenziell illegalem Hintergrund vorgenommen. (Quelle)
Zu Beginn des Monats wurde eine Kompromittierung des US-amerikanischen Sicherheitsunternehmens HBGary durch die Gruppe Anonymous (siehe DDoS-Attacken im Rahmen von Wikileaks) vorgenommen. Dabei wurde ebenfalls die durch den bekannten Analysten Greg Hoglund betriebene Seite rootkit.com kompromittiert. Auf dieser wird ein Forum gehostet, in dem sich Sicherheitsspezialisten über Backdoors und Rootkits austauschen.
Eine Veröffentlichung sämtlicher Daten (z.B. 60’000 Emails des Unternehmens) hatte zur Folge, dass nun ebenfalls die gehashten Passwörter des Forums einsehbar waren. Verschiedene Analysten machten sich daran, diese Passwörter zu knacken. Dies als Datengrundlage wollten wir nutzen, um einen weiterführenden Vergleich der angestrebten Länge von Passwörtern anzugehen. Sodann können wir also an unsere vorangegangenen Analysen anknüpfen und zu normalen Benutzern und Crackern ebenfalls Security Researcher hinzufügen.
Von 71’222 Passwörtern wurden 44’497 geknackt (62.47%). Da nicht alle Passwörter der rootkit.com innerhalb nützlicher Frist geknackt werden konnten, ist die Auswertung nicht abschliessend. Es ist durchaus denkbar, dass ein Mehr an eher langen (und komplexen) Passwörtern verborgen blieb. Zudem wird von verschiedenen Benutzern des Forums berichtet, dass sie bewusst einfache Wegwerfpasswörter verwendet haben.
Auch hier sind statistisch signifikante Abweichungen ersichtlich:
- Researcher pflegen in der Regel mindestens 6-stellige Passwörter zu nutzen (36.67%). Sie setzen damit die typische Minimale Länge gegenüber Benutzern (31.35%) und Cracker (24.35%) noch etwas höher.
- Auch hier ist der typische 2er-Schritt von 6- zu 8-stelligen (23.73%) Passwörter zu bemerken. 5-stellige Passwörter sind eher untervertreten mit 20.93%.
- 8-stellige Passwörter sind bei Researcher weniger wichtig (23.73%) als bei Crackern (32.17%). Gleiches gilt für Passwörter mit einer grösseren Länge.
Dieses Verhalten lässt das Offensichtliche erahnen. Einerseits sind sich Security Researcher sehr wohl den Risiken kurzer Passwörter bewusst. Als Best Practice werden für Webforen jedoch 6-stellige Passwörter verstanden und auf tendeziell längere Passwörter – vor allem mehr als 8 Zeichen – gerne verzichtet. Das Sicherheitsverständnis ist also definitiv höher als bei normalen Benutzern, die Paranoia der Cracker ist jedoch für noch längere Passwörter in diesem Umfeld verantwortlich.
Danksagung
Vielen Dank an dazzlepod.com für das Bereitstellen der Passwortdatenbank und die freundliche Unterstützung.
► 08.02.2011 – Shmoocon 2011 – ein kurzer Rückblick
Der Regierungssitz der Vereinigten Staaten, Washington D.C., ist für seine zahlreichen nationalen Sehenswürdigkeiten bekannt. Das Weisse Haus, das Washington Monument und das Capitol sind dabei wahrscheinlich die bekanntesten unter vielen. Neben nationalen Wahrzeichen ist D.C. aber auch die Heimat einer der populärsten US-Hackerconventions, der Shmoocon. Stefan Friedli der scip AG war vor Ort.
Anreise
Die Shmoocon ist für diverse Dinge bekannt und berüchtigt. Erstens: Der Ticketvorverkauf führt aufgrund des riesigen Andrangs in der Regel zu einem Denial of Service aller involvierten Systeme und zu ebenso riesigen Klagewellen derer, die sich via Twitter darüber beschweren, kein Ticket erhalten zu haben. Zweitens: Das Austragungsdatum der Shmoocon scheint eine untrennbare Kopplung mit dem Auftreten massiven Schneefalls in D.C. zu besitzen. Während einige Besucher letztes Jahr noch Tage nach Ende der Konferenz in der Stadt festsassen, stellten sich dieses Jahr die diversen Winterstürme bereits vor Beginn der Veranstaltung ein und erschwerten den Teilnehmern die Anreise. Wer meinen Twitterfeed verfolgt weiss, dass ich von meinem verlängerten Aufwand in Frankfurt nur wenig begeistert war.
Nach erfolgreicher Anreise, den üblichen Einreiseformalitäten und einer eher halsbrecherischen Taxifahrt auf vereisten Strassen endlich am Ziel angekommen, erfolgte der Check-In im Washington Hilton problemlos. Ob man sich hier schon auf die 1600 Hacker aus allen Teilen des Landes sowie von Übersee eingestellt hatte, liess sich aus dem professionell-freundlichen Auftreten des Concierge nicht erahnen. Das Hilton war dieses Jahr zum ersten Mal der Austragungsort für die Shmoocon. Die Jahre zuvor fand die Konferenz im Mariott Hotel, einige Blocks weiter statt. Aus Infrastrukturgründen entschied man sich aber, dieses Jahr das 2010 renovierte Hilton vorzuziehen.
Nach den üblichen Run-Ins mit alten Bekannten rief erstmal die Dusche und allfällige Pläne, sich noch etwas unter des lokale Volk zu mischen fielen der Müdigkeit, die wetterbedingt 18-stündige Transatlantiktrips nun einmal so an sich haben, zum Opfer.
PTS Meeting, EFF Fundraiser, PTS Meeting
Der erste Tag der Shmoocon ist bewusst schlank gehalten: Die Registrierung öffnete erst um 13 Uhr, bis zur Keynote am frühen Abend durch Peiter “Mudge” Zatko (ehem. L0pht, @stake) wurde nur ein Track anstatt der üblichen drei geführt. Dadurch blieb genug Zeit, mit alten Freunden zu Plaudern. Während für die meisten Besucher hier vor allem das Vergnügen im Vordergrund stand, galt es für mich und die anderen Mitglieder des PTS (Penetration Testing Standard) Boards produktiv zu sein. Der Penetration Testing Standard ist ein Projekt diverser Experten, um die Definition und Methodik von Pentests zu verbessern und eine einheitlichen Standard für Kunden und Anbieter gleichermassen zu schaffen. Die Mitglieder des Boards, meine Person inklusive, verfügen allesamt über langjährige Erfahrung im Gebiet. Es überrascht daher wenig, dass die Besprechung der bisherigen Fortschritte sehr produktiv verlief und nach etwas mehr als einer Stunde mit überdurchschnittlich guten Resultaten endete. Mehr zum PTS Projekt werden wir hier im scip Labs Blog vorraussichtlich im Laufe dieses Jahres (Sommer/Herbst) veröffentlichen.
Keynote
Die Keynote der diesjährigen Shmoocon hielt, wie schon erwähnt, Peiter C. Zatko, besser bekannt als Mudge. Mudge, der als Mitglied des Think Tanks L0pht insbesondere durch seine frühe Arbeit im Hinblick auf Buffer Overflows bekannt wurde, arbeitet heute als Programmdirektor für die DARPA. Seine Keynote mit dem Titel “Analytic Framework for Cyber Security” beschäftigte sich daher auch in erster Linie mit den Bestrebungen der Agency im Hinblick auf die Cyber Security der US Regierung. Seine Ausführungen waren dabei durchaus unterhaltsam (wenn auch viele den “alten” Mudge, der nicht für eine Regierungsstelle arbeitet vermissen mögen…) und regen zum Nachdenken an. Money Quote: “If something appears irrational to you, you probably don’t understand the game”.
The Summit on the Hill: EFF Fundraiser Event
Die Electronic Frontier Foundation ist eine wohletablierte Non-Profit Organisation, die sich für die Bügerrechte im Cyberspace stark macht. Aufgrund der sich bietenden Gelegenheit, veranstaltete die EFF abends einen Fundraiser Event und lud dazu zahlreiche Gäste aus der internationalen Security Szene ein. Nach einer kurzen Shuttlefahrt vom Hilton zur Helix Lounge an der Rhode Islang Avenue, kamen wir in den Genuss einer offenen Bar und der erneuten Gelegenheit, sich mit mit alten und neuen Bekanntschaften in angenehmer Atmosphäre zu unterhalten.
Alle Talks von Tag 1
- A Paranoid Schizophrenia-based Model of Data Security – Marsh Ray
- Hacking ‘Smartwater’ Wireless Water Networks – John McNabb
- Gone in 60 Minutes: Stealing Sensitive Data from Thousands of Systems Simultaneously with OpenDLP – Andrew Gavin (Als Video verfügbar)
- Hackers for Charity – Johnny Long (Als Video verfügbar)
- ZigBee Security: Find, Fix, Finish – Ryan Speers and Ricky Melgares (Als Video verfügbar)
- Are you receiving me? Recent issues in wifi privacy – Tara Whalen (Als Video verfügbar)
Alle Talks von Tag 2
Track 1: Build it!
- Defending against Targeted attacks using Duck tape, Popsicle Sticks and Legos – Richard Rushing
- Fun with Flow – Richard Friedberg
- Yet Another Heapspray Detector – Daniel Kovach
- Exploiting the Hard-Working DWARF – James Oakles & Sergey Bratus
- INTERSECT: Combining Commercial/FOSS Tools with Custom Code to Root Out Malware – Matthew Pawloski & Fotios Lindiakos
- Project Ubertooth: Building a Better Bluetooth Adapter – Michael Ossmann (Als Video verfügbar)
- 3D Modelling and Visualization of Real Time Security Events – Dan Klinedinst
Track 2: Break it!
- Printer to PWND: Leveraging Multifunction Printers During Penetration Testing – Deral Heiland “PercX” & Pete Arznamendi “Bokojan”
- TEAM JOCH vs. Android: The Ultimate Showdown – Jon Oberheide & Zach Lanier
- Hop Hacking Hedy – Q, Atlas, Cutaway Smash und Slugs on Toast
- Printers Gone Wild! – Ben Smith
- Attacking 3G and 4G mobile telecommunications networks – Enno Rey & Daniel Mende
- Defeating mTANs for profit – Axelle Apvrille & Kyle Yang (Als Video verfügbar)
- Reverse Engineering Using the Android Emulator – Scott Dunlop
Track 3: Bring it on!
- Computer Search and Seizure – Marcia Hofmann
- Unlocking the Toolkit: Attacking Google Web Toolkit Applications – Ron Gutierrez
- Hard Drive Paperweight: Recovery from a Seized Motor! – Scott Moulton
- Tracking Flaws – Stream Reassembly Issues in Snort IPS – Ashley Thomas
- An Evite from Surbo? Probably an invitation for trouble. – Trent “Surbo” Lo
- ShmooCon Labs Goes to College – G W Ray Davidson III, PhD
- The Getaway: Methods and Defenses for Data Exfiltration – Sean V. Coyne
Specials
Alle Talks von Tag 3
Track 1: Build it!
- Half Baked: Hardware Hacking Mixed with Sweet Software Reverse Engineering – Marc Eisenbarth
- Visual Malware Reversing: How to Stop Reading Assembly and Love the Code -Danny Quist
- Own the Con – The Shmoo Group
- The Past, Present, and Future of “Something You Know” – Rick Redman, Martin Bos, Robert Imhoff, David Schuetz
Track 2: Break it!
- URL Enlargement: Is it for You? – Daniel Crowley (Als Video verfügbar) (Editors Pick)
- Malicious USB Devices: Is that an attack vector in your pocket or are you just happy to see me? – Adrian Crenshaw
- Transparent Botnet Control for Smartphones Over SMS – Georgia Weidman
Track 3: Bring it on!
- USB Autorun attacks against Linux – Jon Larimer (Als Video verfügbar)
- Hacking the Business Capability Stack: Make Corporate Bureaucracy Work for You – Javier Gonzales Sanchez
- Inside the App: All Your Data are Belong to Me – Sarah Edwards
Stefan Friedli | G+ (1499 Wörter)
► 04.02.2011 – Video zu Nmap NSE Vortrag an Hashdays 2010
Letztes Jahr hielt ich einen Talk mit dem Titel Nmap NSE Hacking for IT Security Professionals an den Hashdays in Luzern. In diesem zeigte ich unsere Herangehensweise, um mit Nmap NSE Scripting die Effizienz und Qualität von Penetration Tests zu erhöhen.
Diese Woche wurde durch die Hashdays-Organisatoren der Videomitschnitt des Vortrags auf YouTube veröffentlicht. Das Video dauert rund 35 Minuten und ist in Englisch gehalten. Die genutzten Slides sowie die angekündigten Skripte werden in diesem Labs Post besprochen und zum Download angeboten.
► 31.01.2011 – Erfolgreicher Angriff gegen X-pire!
Hinweis: Wir sehen uns aus rechtlichen Gründen nicht in der Lage das modifizierte Firefox-Addon von X-pire! mit integriertem Key-Cache zu veröffentlichen. Ein Screenshot eines erfolgreichen Angriffs mit dem erweiterten Plugin steht hier zur Verfügung.
Die letzten Wochen wurde in den deutschen Medien fortwährend von einem neuen Projekt zur Wahrung der Privatsphäre der Internet-Benutzer berichtet (z.B. Süddeutsche Zeitung, Heise). Durch das Kryptosystem X-pire! von Prof. Michael Backes sollte es von nun an möglich sein, dass im Internet bereitgestellte Bilder mit einem Verfallsdatum versehen werden.
In Fachkreisen war das Projekt – welches politisch durch die Bundesverbraucherministerin Ilse Aigner (CSU) getragen wird – schon vor Bekanntgabe von Details aus technischen, politischen, wirtschaftlichen und rechtlichen Gründen umstritten (TAZ, Die Welt). Entsprechend mit Spannung wurde die Veröffentlichung der Software erwartet. Auf der Projektseite unter x-pire.de können einige sehr allgemeine Informationen sowie das dazugehörige Firefox-Addon heruntergeladen werden.
Wir haben uns intensiv mit der Funktionsweise der Lösung auseinandergesetzt, um allfällige Schwachstellen in dieser finden und beweisen zu können. Hadmut Danisch hat in seinem umfangreichen Blog-Post mit dem Titel Idiotische Kryptographie, Made in Germany verschiedene Schwachpunkte der genutzten Ansätze zusammengefasst. Wir konzentrieren uns in diesem Beitrag auf den Ansatz des Auslesens und Wiederverwendens von legitimen Schlüsseln.
Einführung
Das Grundprinzip der Lösung besteht darin, dass ein Benutzer zuerst ein Konto erstellt. Mit diesem wird es ihm erlaubt, kostenpflichtig ein Bild mit AES256 zu verschlüsseln und diese Fassung in Internet hochzuladen. Damit ein anderer Benutzer dieses Bild einsehen kann, muss er das X-pire! Plugin installieren. Dieses fragt beim Erkennen von verschlüsselten Bildern beim Schlüsselserver an, ob das Bild schon abgelaufen ist. Ist dies nicht der Fall, wird der Schlüssel an den Client zurückgegeben, der damit das Bild entschlüsseln und anzeigen kann. Bleibt ein solches Entschlüsseln aus, wird ein Hinweis auf das Ablaufen des Bildes angezeigt. Nachfolgende Grafik illustriert das Resultat dieses Prozesses, wobei das erste Bild im Gegensatz zu den anderen beiden aufgrund des Verfallsdatums nicht mehr eingesehen werden kann:
Mit X-pire! will also durchgesetzt werden, dass ein Bild nach dem Ablauf des vordefinierten Zeitpunkts nicht mehr geladen wird. Dieses Ziel wird auf verschiedenen Ebenen verfehlt. Dass ein legitim angezeigtes und heruntergeladenes Bild weiterverarbeitet und ohne das weiterführende Zutun von X-pire! genutzt werden kann, erscheint offensichtlich (Stichwort Printscreen). Auf technischer Ebene interessanter ist jedoch der Umstand, dass durch das Auslesen und Zwischenspeichern der symmetrischen Schlüssel diese ohne zukünftige Absegnung des Schlüsselservers weiterverwendet werden können.
Auslesen der Schlüssel
Will ein mit X-pire! verschlüsseltes Bild angezeigt werden, fragt das Plugin bei keyserver.x-pire.net um den Erhalt des entsprechenden Schlüssels an. Hierzu wird der Hashwert (SHA256) des Bilds an den Server übermittelt, anhand dessen sich das Bild und der dazugehörige Schlüssel identifizieren lassen.
Die Bearbeitung des Bilds durch den damit erlangten Schlüssels wird im Firefox-Addon in \chrome\content\overlay.js umgesetzt. Von Interesse ist die Funktion Xpire.KeyServerApi.getKey(), welche für das Entschlüsseln verantwortlich ist. Sie benutzt die exportierten Funktionen der vorkompilierten Datei \components\XpireJPEG.dll (Quelltext steht nicht zur Verfügung):
lib.decryptJPEG(img.value, result.key, base64, width, height);
Das verschlüsselte Bild wird dann mit replaceFunction() umgewandelt und damit im Browser ohne weiteres Zutun des Benutzers (sofern keine CAPTCHAs aktiviert sind) angezeigt:
replaceFunction(image, "data:image/jpeg;base64," + base64.value);
In unserer modifizierten Version des Firefox-Addons wird dieser Funktionsablauf um einen Logging-Mechanismus erweitert, wodurch die Grundlage für ein Zwischenspeichern des legitimen Keys geschaffen wird. Dabei wird bei jeder erfolgreichen Umwandlung eine Alert-Box generiert, und darin auf den neu erhaltenen Key hingewiesen:
Das grundlegende Problem besteht in der Nutzung einer symmetrischen Verschlüsselung, deren Schlüssel nicht ablaufen kann. In einem weiteren Schritt sollen nun die erhaltenen Schlüssel gesammelt und in einem lokalen Cache abgelegt werden. Dadurch lassen sich diese wiederverwenden.
Wiederverwenden der Schlüssel
Durch die zuvor vorgestellte Funktion besteht die Möglichkeit, eine Liste mit den erhaltenen Schlüsseln zu erstellen. Ein Bild wird einerseits durch seinen Hash-Wert in hash.value als auch durch eine Identifikationsnummer in id.value identifiziert. Der dazugehörige Schlüssel wird in result.key abgelegt.
Durch das Speichern dieser Informationspaare können nun die Schlüssel lokal gesammelt werden. Auf der Demo-Webseite des Projekts werden drei geschützte Bilder bereitgestellt (siehe Screenshot oben), wobei durch die Datensammlung folgende Informationen zusammengetragen werden konnten:
| ID | Hash | Key | Ablaufdatum |
|---|---|---|---|
| 5 | fb1c038c912c46c41181c8cb32b39e39 6abacdb0abf1d0683b6ca3d12ee386ba |
e6f207509afa3908 da116ce61a757695 |
27.01.2011 19:00 |
| 6 | 2b4c6711793140ea5fa88c27f6135403 4f69dbdbaaae82f6c88490fcd019bd09 |
ab897fbdedfa502b 2d839b6a56100887 |
08.02.2011 19:01 |
Durch diese dynamisch angefertigte Lookup-Table wird es möglich, im weiteren Verlauf den Zugriff auch auf jene Schlüssel zu gewährleisten, die mittlerweile aufgrund des Ablaufzeitpunkt des Bilds nicht mehr durch den Schlüsselserver herausgegeben werden würden. Stattdessen wird einfach auf den lokalen Key-Cache zugegriffen und damit der Server umgangen. Auf der Projekt-Webseite wird auf diese drohende Gefahr eines Key-Store hingewiesen.
Fazit
Dieser Beitrag illustriert lediglich einen der möglichen Angriffe auf das gesamte System. Es gibt eine Vielzahl anderer Varianten, wie die Funktionsweise und Sicherheit dessen attackiert und kompromittiert werden kann. Die Lösung missachtet eine erstaunlich hohe Anzahl grundlegender Aspekte von moderner Informationssicherheit und Kryptografie (z.B. symmetrische Kryptografie verfehlt das Ziel, Wiederverwendung von Keys nicht geregelt, Revoke-Möglichkeit ausser Acht gelassen, Server als Single Point of Failure, etc.) Es ist damit in keinster Weise geeignet, gegen Angreifer mit einem minimalen Verständnis für die eingesetzten Mechanismen vorzugehen.
Die gezeigten Anpassungen im bereitgestellten Code beweisen zudem, dass ein manipuliertes Addon gleichzeitig als erfolgreiches Angriffswerkzeug eingesetzt werden kann. Der Erfolg dieses Ansatzes fusst in erster Linie darauf, dass sich die Entwickler von X-pire! darauf verlassen, dass ein Benutzer keine böswilligen Absichten hat. Dies ist jedoch Wunschdenken und blendet schlichtweg in naiver Weise die bestehenden und bestens bekannten Gefahren aus. Wir raten vom Einsatz dieser Lösung im gegenwärtigen Zustand ab.
Update 13. Februar 2011 19:25 Uhr
Verschiedene Nachrichtenportale berichten über unsere Entwicklung. Unter anderem:
- Heise – Bilder anschauen trotz ‘Internet-Radiergummi’
- Golem – X-pire: Digitaler Radiergummi angeblich unsicher
- WinFuture – Experten: Digitaler Radiergummi ist viel zu unsicher
- 20 Minuten – Wir entwickeln auch Trojanische Pferde
- ZDF Heute – Digitaler Radiergummi ausgehebelt
Zudem wurde anonym eine in C++ geschriebene und quelloffene Re-Implementierung des X-pire! Plugins veröffentlicht. Dieses lässt einfache Manipulationen und damit ebenfalls die Kompromittierung des Systems zu.
► 27.01.2011 – Blog Digest Januar 2011
- Android Trojan captures credit card details (20.01.2011), thinq.co.uk
- Bot attacks Linux and Mac but can’t lock down its booty (21.01.2011), theregister.com
- Comic for January 7, 2011 (07.01.2011), dilbert.com
- CSP, HTML5, and the aesthetics of security (22.01.2011), Michal Zalewski, lcamtuf.blogspot.com
- Detecting Malice with ModSecurity: CSRF Attacks (11.01.2011), Ryan Barnett, blog.spiderlabs.com
- Don’t Sacrifice Security on Mobile Devices (22.01.2011), chris, eff.org
- Ethics of password cracking/dissemination (24.01.2011), skullsecurity.org
- Faces of Fraud 2011: Beware Cross-Channel Threats (06.01.2011)
- How Good Does The Writing Need To Be? (18.01.2011), regehr
- How Not to Store Passwords in iOS (07.01.2011), blogs.sans.org
- Israeli Test on Worm Called Crucial in Iran Nuclear Delay (16.01.2011), nytimes.com
- January 2011: The Definitive Facebook Lockdown Guide (07.01.2011), zdnet.com
- Mobile Device Security and Android File Disclosure (19.01.2011)
- Mobile Device Users More Susceptible to Phishing Scams (06.01.2011), threatpost.com
- Nessus: Mythbusters Edition (20.01.2011), Paul Asadoorian, blog.tenablesecurity.com
- Penetration Testing Rapidly Becoming Obsolete (30.12.2010), carnal0wnage.attackresearch.com
- Security Awareness Through Proverbs (14.01.2011), blog.rootshell.be
- ‘SMS of Death’ Attacks Can Crash the Simplest of Phones (30.12.2010), Christopher Brook, threatpost.com
- Targeted attacks – going beyond the technicalities (12.01.2011), Iftach Ian Amit
- The Application Security Spending Conundrum (12.01.2011)
- The Future of Software System Correctness (10.01.2011)
- The Synergy Between Delta Debugging and Compiler Optimization (20.01.2011), regehr
- Tunisia Tracks Users with JavaScript Injection? (13.01.2011), blog.rootshell.be
- Unspecified vulnerabilities (29.12.2010)
- What are Heuristics? (30.12.2010), Aryeh Goretsky, blog.eset.com
- What’s in Your iOS Image Cache? (14.01.2011), blogs.sans.org
- WikiLeaks cable dump reveals flaws of State Department’s information-sharing tool (04.01.2011), washingtonpost.com
► 20.01.2011 – Clientseitige Sicherheit am Beispiel der Playstation 3
Die Playstation 3 von Sony ist eine der ganz grossen Nextgen-Konsolen. Seit ihrem Erscheinen im November 2006 sind rund 42 Millionen Geräte verkauft worden. Trotz dieser hohen Beliebtheit des Systems dauerte es bis Mitte 2010, bis ein Jailbreak erschienen ist. Über einen USB-Modchip sah man sich bis zur Firmware 3.41 in der Lage, Homebrew-Software ausführen zu lassen.
Doch der echte Durchbruch des PS3-Jailbreaking kam im im Dezember 2010 zustande. Die Gruppe fail0verflow kündigte am 27C3 an, dass sie den Private Key von Sony für das Signieren von Code auslesen konnten. Durch dieses Reversing war es von nun an möglich, eigenen Code zu schreiben und zu signieren, wodurch er als legitime Applikation auf einer PS3 ausgeführt werden kann. Aufgrund der Struktur dieser Schwachstelle wird es für Sony sehr schwer werden, dieses Problem mit einem üblichen Patch zu beheben. Stattdessen, wird in erster Linie versucht durch juristische Schritte dagegen vorzugehen.
Zwischenzeitlich mehren sich die Meldungen, dass durch gemoddete Konsolen unliebsame Hacks und Cheats Einzug halten. Im offiziellen Forum von Infinity Ward wird darüber berichtet, dass der Beitritt eines gehackten Modern Warfare 2-Servers zum Verlust sämtlicher Statistiken führen kann:
Hacking is getting worse and worse, i am stunned theres little to no discussion here. one of my accounts is already destroyed by joining a hacked server filling all my challenges [sic]
Dies ist natürlich ein unschöner Effekt, der das öffentliche Online-Spiel des populären Shooters nahezu zerstört (es wird das Spielen auf privaten Servern empfohlen). Trotzdem zeigt dieser Zustand auf, dass Infinity Ward einmal mehr die Sicherheitsmechanismen auf den Client – in diesem Fall die Konsolen – ausgelagert hat. Scheinbar funktioniert das Generieren und Synchronisieren der Spiel-Statistiken wie folgt:
- Benutzer spielt das Spiel und generiert damit seine Statistik auf dem Client (Konsole).
- Die Statistiken werden von der Konsole zum Server hochgeladen (überschrieben) und werden damit für alle einsehbar.
Sieht sich nun ein Spieler in der Lage diese Statistiken vor dem Upload zu manipulieren, kann direkter Einfluss auf die Weiterverarbeitung ausgeübt werden. Dadurch lassen sich bessere Statistiken erstellen (Überschreiben) oder diese zurücksetzen (Löschen).
Wäre die Sicherheit dieses Systems nicht auf den Client ausgelagert worden, sondern stattdessen ganzheitlich auf dem Server integriert gewesen, wäre dieser Angriff nicht möglich gewesen. Einmal mehr zeigt dies auf, dass clientseitige Sicherheit nicht funktionieren kann. Denn sobald der Angreifer die vollständige Kontrolle über seinen Client erlangen kann – und dies wird früher oder später der Fall sein -, wird er sämtliche Sicherheitsmechanismen umgehen können.
Dieses Axiom gilt für alle client/server-basierten Anwendungen. Traditionell ist dieses Paradigma bei Webapplikationen zu berücksichtigen. Aber auch bei Apps auf Mobiltelefonen behält es seine Richtigkeit. Die skizzierten Schwierigkeiten für Spielkonsolen sind nur eine abgewandelte Form des immerwährend gleichen Problems.
► 13.01.2011 – Firewall Rule Parsing am Beispiel von SonicWALL
Im Rahmen von Sicherheitsüberprüfungen führen wir immerwieder sogenannte Firewall Rule Reviews durch. Bei diesen wird das Regelwerk einer Firewall einer formalen, strukturellen und logischen Analyse unterzogen. Dadurch sollen ineffiziente, fehlerhafte und fehlende Regelsätze identifiziert werden. Diese Aufgabe führen wir computergestützt durch, wodurch wir ein Mehr an Effizienz und Zuverlässigkeit erreichen können.
Dabei wird das jeweilige Firewall-Regelwerk exportiert und für einen Import in unser Analysesystem vorbereitet. Hierzu wird es erforderlich, dass ein Parsing des Regelwerks vorgenommen werden kann. Durch diese Normalisierung wird die Weiterverarbeitung vereinfacht, da die Eigenschaften der unterschiedlichen Produkte nicht mehr (im Detail) berücksichtigt werden müssen.
Einführung
Nachfolgend soll exemplarisch an SonicWALL aufgezeigt werden, wie ein solches Firewall Rule Parsing aussehen kann. Als erstes wir auf dem jeweiligen SonicWALL-Gerät ein Export der Konfiguration vorgenommen (System/Settings/Export Settings). Dadurch wird eine Datei mit der Erweiterung .exp angelegt. Hierbei handelt es sich um einen mit Base64 codierten String, der relativ einfach wieder decodiert werden kann:
$file_content_raw = file_get_contents('sonicwall_ruleset.exp');
$fw_ruleset_text = base64_decode($file_content_raw);
Dadurch wird der Klartext-Zugriff auf das Firewall-Regelwerk und zusätzliche Konfigurationseinstellungen möglich. SonicWALL benutzt ein Format, bei dem die unterschiedlichen Einstellungen durch das Zeichen & voneinander getrennt werden. Jede Einstellung besitzt einen Namen und einen Wert, der durch das Gleichheitszeichen = zugewiesen wird (Auszug, manuell umgebrochen):
checksumVersion=1&zoneObjId_0=LAN&zoneObjProperties_0=1821& zoneObjCflProfile_0=0&zoneObjZoneType_0=1&zoneObjIntraZoneCom_0=1& zoneObjAvProfile_0=0&zoneObjASProfile_0=0&zoneObjGavProfile_0=0& zoneObjGscProfile_0=0&zoneObjGroupVpn_0=1&zoneObjMyIDPProfile_0=0& zoneObjEnforceWiFi_0=0&zoneObjEnforceSslvpn_0=0&zoneObjSslvpnIp_0=& zoneObjSslvpnPort_0=&zoneObjWiFiException_0=0& zoneObjWiFiExceptionHandle_0=&zoneObjRestrictVpnTrav_0=0& zoneObjAllowWPA_0=0&zoneObjSonicPointProfHandle_0=& zoneObjSonicPointOnly_0 (...)
Zusammengehörige Einstellungen werden durch eine eindeutige Identifikationsnummer ausgewiesen. Abgesehen von der ersten Einstellung gehören alle nachfolgenden Einstellungen zu einem Zonen-Objekt mit der ID 0. Diese wird durch _0 am Ende des Einstellungsnamens ausgewiesen. Diese ID ist besonders wichtig, um Zusammenhänge erkennen zu können.
Extrahierung einzelner Einstellungen
Mit der nachfolgenden Funktion werden nun die einzelnen Einstellungen extrahiert. Hierzu kommt ein dynamischer regulärer Ausdruck zum Zug, der drei dynamische Elemente enthält:
- Durch
$ruleidwird die zuvor erklärte ID angegeben. - Mit
$typewird der Typ der Konfigurationseinstellung angegeben. Dieser kann beispielsweisepolicy(Firewall-Regel),zoneObj(Zonen-Objekt),addrObj(Adress-Objekt) odersvcObj(Service-Objekt) lauten). - Danach folgt mit
$objectder Name des Objekts selber. Dies sind zum BeispielAction,SrcZone,DstZone,SrcNet,DstNetoderDstSvc.
function extract_object($ruleset, $ruleid, $type, $object){
preg_match('/'.$type.$object.'_'.$ruleid.'\=(.*?)&/s', $ruleset, $matches);
return $matches[1];
}
Mit dem Funktionsaufruf extract_object($fw_ruleset_text, 23, 'addrObj', 'Ip1') wird also der Eintrag addrObjIp1_23 angezeigt. Hier handelt es sich um die IP-Adresse der Adress-Objekts mit der ID 23. Mit einer Iteration durch das Regelwerk kann nun eine Umformulierung dessen stattfinden. Dabei sind ist vor allem der Typ policy von Interesse, denn dieser definiert die eigentlichen Firewall-Regeln (Rule-Policies, bei Cisco PIX/ASA werden sie access-list genannt). Typischerweise sind die folgenden Objekte hierbei von Interesse:
- ID – Interne Identifikation
- Action – Verfahren mit der Kommunikation (z.B.
2= ALLOW) - SrcZone – Quellzone
- DstZone – Zielzone
- SrcNet – Quellsystem
- DstNet – Zielsystem
- DstSvc – Dienst
- Comment – Optionale Kommentare
Eine naheliegende Umformung des Regelwerks ist die tabellare Darstellung, zum Beispiel in einer CSV-Datei. Die Regeln werden auf einzelne Zeilen geschrieben, wobei die gleichwertigen Definitionen in der gleichen Spalte geführt werden. Ein sehr simples SonicWALL-Regelwerk sieht umgeformt so aus:
| ID | Action | SrcZone | DstZone | SrcNet | DstNet | DstSvc |
|---|---|---|---|---|---|---|
| 1 | 2 | LAN | LAN | All LAN Management IP | HTTPS Management | |
| 2 | 2 | LAN | LAN | All LAN Management IP | HTTP Management | |
| 3 | 2 | WAN | DMZ | Webserver | HTTP | |
| 4 | 2 | LAN | WAN | Workstations | HTTP | |
| 5 | 2 | LAN | DMZ | Administrators | Webserver | SSH |
| ... | ||||||
Die ersten beiden Regeln werden standardmässig durch die SonicWALL angelegt, um die interne Administration des Geräts über das Webfrontend gewährleisten zu können. Die Regel 3 wurde manuell erstellt und lässt externe Zugriffe über HTTP auf den Webserver in der DMZ zu. Regel 4 wird genutzt, damit die internen Clients per HTTP auf das World Wide Web zugreifen können. Und Regel 5 wird verwendet, damit interne Administratoren per SSH den Webserver in der DMZ verwalten können. Leer gelassene Felder werden als ANY-Definitionen verstanden.
Auflösung von Objekt-Gruppen
Anhand dieses Beispiels sieht man ein klassisches Problem beim Parsing von Firewall-Regelwerken: Bei modernen Systeme werden (verschachtelte) Objekte verwendet. Zum Beispiel ist anhand des Namens Webserver nicht ersichtlich, welche IP-Adresse eben dieses Objekt zugewiesen bekommen hat. Gleiches gilt für die restlichen Systeme, Netzwerke und Dienste (z.B. ein Dienst mit dem Namen SSH muss nicht zwingend über tcp/22 betrieben werden).
Das Regelwerk von SonicWALL ist relativ komfortabel, denn die Objekte sind ebenfalls darin enthalten (im Gegensatz zu CheckPoint, die ihrerseits eine separate Objects-Datei verwenden). Für Zonen-Objekte muss der Typ zoneObj, für Adress-Objekte addrObj und für Dienst-Objekte svcObj ausgelesen werden. Eine Auflösung der bisher gesehenen Adress-Objekte sieht sodann wie folgt aus:
| ID | Id | IdDisp | Type | Zone | Properties | Ip1 | Ip2 |
|---|---|---|---|---|---|---|---|
| 1 | ALL LAN Management IP | All X0 Management IP | 8 | 793 | 0.0.0.0 | 0.0.0.0 | |
| 2 | Webserver | Webserver | 1 | DMZ | 14 | 192.168.0.10 | 255.255.255.255 |
| 3 | Workstations | Workstations | 8 | 14 | 0.0.0.0 | 0.0.0.0 | |
| 4 | Administrators | Administrators | 8 | 14 | 0.0.0.0 | 0.0.0.0 | |
| ... | |||||||
In diesem Fall ist nur ein System effektiv spezifiziert (alle anderen Objekte stellen Netze dar). Hierbei handelt es sich um die ID 2, bei dem der Webserver mit einer eindeutigen IP-Adresse und einer eindeutigen Zonen-Zuordnung definiert wird. Alle anderen Adress-Objekte sind undefiniert; sowohl in Bezug auf die Zone als auch auf die IP-Adressierung. Der Grund dafür ist, dass es sich hier um Objekt-Gruppen handelt. Die zu einer Gruppe gehörigen Objekte werden weiterführend in addro_ (Adress-Objekte) und so_ (Service-Objekte) dokumentiert:
| ID | atomToGrp | grpToGrp |
|---|---|---|
| ... | ||
| 5 | ZRHXP001 | Workstations |
| 6 | ZRHXP002 | Workstations |
| 7 | ZRHXP003 | Workstations |
| 8 | ZRHXP004 | Workstations |
| ... | ||
Mit der der durch diese Zwischentabelle zusammengetragenen IDs kann nun die effektive Konfiguration des jeweiligen Objekts ausgemacht werden. Hierzu wird erneut auf addrObj zugegriffen, in diesem Fall aber nur auf die Elemente des Adress-Objekts mit den IDs 5-8:
| ID | Id | IdDisp | Type | Zone | Properties | Ip1 | Ip2 |
|---|---|---|---|---|---|---|---|
| ... | |||||||
| 5 | ZRHXP001 | ZRHXP001 | 1 | LAN | 14 | 172.16.0.1 | 255.255.255.255 |
| 6 | ZRHXP002 | ZRHXP002 | 1 | LAN | 14 | 172.16.0.2 | 255.255.255.255 |
| 7 | ZRHXP003 | ZRHXP003 | 1 | LAN | 14 | 172.16.0.3 | 255.255.255.255 |
| 8 | ZRHXP004 | ZRHXP004 | 1 | LAN | 14 | 172.16.0.4 | 255.255.255.255 |
| ... | |||||||
Mit dieser erfolgreichen Auflösung kann nun die Normalisierung des Regelwerks vorangetrieben werden. Die Regel 4 (Zugriff von Workstatsions auf das Web) kann nun wie folgt aufgelöst und ausformuliert werden:
| ID | Action | SrcZone | DstZone | SrcNet | DstNet | DstSvc | Comment |
|---|---|---|---|---|---|---|---|
| ... | |||||||
| 4 | ALLOW | LAN | WAN | 172.16.0.1-4 | ANY | TCP/80 | Workstations to WWW |
| ... | |||||||
Fazit
Das Parsing eines Firewall-Regelwerks ist wichtig, um eine formale Analyse dessen durchführen zu können. Hierzu muss eine Umwandlung der jeweiligen Elemente stattfinden, wobei die interne Logik des Produkts berücksichtigt werden muss.
Die Export-Dateien von SonicWALL sind dabei relativ einfach gehalten und beinhalten alle Informationen, die zur Konfiguration des Geräts erforderlich sind. Durch verschiedene Lookup-Prozesse wird es möglich, das Firewall-Regelwerk mit all seinen Abhängigkeiten und Verschachtelungen zu verstehen.
Nur an wenigen Punkten sind die einzelnen Einstellungen schwierig verständlich oder das Parsing mit Problemen behaftet. Letzteres ist zum Beispiel beim Suffix iface der Fall, der sporadisch bei langen Konfigurationseinstellungen mit if_ abgekürzt wird. Oder die Tatsache, dass Zeitangaben bei schedObjId normalerweise einen Buchstaben für Tage verwenden, Donnerstag (TH) und Sonntag (SU) hingegen zwei Buchstaben nutzen.
► 06.01.2011 – Grundlegende RFID-Sicherheit
RFID ist durch die breite Bevölkerung spätestens mit der Einführung des elektronischen Passes in verschiedenen Länder wahrgenommen worden. Sicherheitsbedenken gegenüber der Technologie sind berechtigterweise latent vorhanden. Mit diesem Beitrag wollen wir die effektiven Gefahren einfacher RFID-Tags aufzeigen.
Hinweis: Die Standardisierung von RFID ist nicht international geregelt. Verschiedene Länder und Fachbereiche geben unterschiedliche Standards und Empfehlungen heraus. Entsprechend kann es zu Abweichungen in der Funktionsweise und im Umgang mit den jeweiligen Produkten kommen. Eine Vereinheitlichung für Inventarisierungen wurde beispielsweise mit ISO/IEC 18000: Information technology – Radio frequency identification for item management angestrebt.
Einführung
Das Akronym RFID steht für Radio Frequency Identification. Dieses System wird eingesetzt, um drahtlos Informationen zwischen einem Transponder (auch Tag genannt) und einem Lesegerät auszutauschen. Passive Transponder besitzen keine eigene Energiequelle, sondern beziehen die Energie aus dem elektromagnetischen Hochfrequenzfeld, das durch das Lesegerät generiert wird. Aktive Transponder können eigene Energiequellen, vorzugsweise werden Batterien eingesetzt, nutzen.
Jeder Tag besitzt eine eindeutige Tag-ID, die im read-only Bereich abgelegt wird. Sie wird in jedem Fall übertragen, um die Identifikation des Transponders umzusetzen. Damit wird die Hauptfunktionalität von RFID gewährleistet: Innerhalb des Systems kann dadurch eine Identifikation realisiert werden – Dies lässt sich beispielsweise für Identifikation (z.B. Kreditkarte), Inventarisierung oder Zugangssysteme benutzen.
Vortäuschen der Tag-ID
Bemerkenswert hierbei ist, dass RFID-Tags üblicherweise tatsächlich nur die ID und keine zusätzlichen Informationen bereitstellen. Die Ableitung eines Benutzernamens anhand der ID findet erst bei der späteren Verarbeitung, zum Beispiel im Rahmen eines Datenbanksystems, statt (Beispiel SQL: SELECT user_id, user_name FROM tbl_user WHERE user_id=$tag_id). Das Vortäuschen einer Identität ist in diesem Fall also in erster Linie von der Manipulation der Tag-ID abhängig. In einfachen Authentisierungssystemen werden gerne solcherlei simple HID Proximity- oder EM41XX-Tags eingesetzt.
Die produktiven Angriffsmöglichkeiten eines solchen Systems sind entsprechend primitiv: Sieht man sich in der Lage mit einem geklonten Transponder oder einer Emulation die Tag-ID eines anderen Tags vorzutäuschen, kann der erweiterte Zugriff im Rahmen des Systems stattfinden. Damit können Identitäten vorgetäuscht und die damit verbundenen Rechte geerbt werden. Das Identifizieren legitimer Tag-IDs kann durch das Abhören einer Kommunikation (Replay-Attacke) oder durch das simple Herausfinden (Bruteforce-Attacke) geschehen.
Beschreibbare Speicher
Es gibt jedoch nicht nur read-only Transponder, sondern ebenfalls solche mit beschreibbaren Bereichen. Hier kann zwischen einmalig (write-once) und mehrmals beschreibbar (read-write/write-many) unterschieden werden. Dabei ist der Datenträger mit einem erweiterten Speicherbereich ausgerüstet, der zusätzlich zur read-only Tag-ID mit erweiterter Hardware angesteuert werden kann.
Was in den erweiterten Bereichen eines Tags gespeichert wird, ist von der jeweiligen Applikation abhängig. Dies kann beispielsweise ein Benutzerzertifikat oder ein dezentralisiert ausgelagertes Passfoto sein.
Das Problem des read-write Bereich ist, dass sich dieser jenachdem manipulieren lässt. Im Beitrag RFID Viruses and Worms der Universiteit Amsterdam wird ein Szenario beschrieben, in dem der dynamische Bereich für die Verbreitung eines Virus genutzt wird:
Up until now, everyone working on RFID technology has tacitly assumed that the mere act of scanning an RFID tag cannot modify back-end software, and certainly not in a malicious way. Unfortunately, they are wrong. In our research, we have discovered that if certain vulnerabilities exist in the RFID software, an RFID tag can be (intentionally) infected with a virus and this virus can infect the backend database used by the RFID software. From there it can be easily spread to other RFID tags.
Derartige Probleme sind nicht auf die RFID-Technologie als solche zurückzuführen. Der beschreibbare Bereich des RFID-Tags wird lediglich als Träger verwendet. Durch eine fehlerhafte Weiterverarbeitung im Backend können erweiterte Rechte erlangt und Manipulationen durchgesetzt werden. Damit lassen sich nachfolgend durch das System bearbeitete RFID-Tags ebenfalls infizieren.
Im illustrierten Beispiel wird über eine SQL-Injection eine Replikation durch einen Quines-Virus durchgesetzt. Es handelt sich also grundsätzlich um ein Schnittstellenproblem, bei dem einmal mehr auf eine umfassende Eingabeüberprüfung – in diesem Fall von einem über RFID ansprechbaren Datenträger – verzichtet wird. Ein ähnliches Szenario wurde ebenfalls im Zusammenhang mit einem implantierten RFID-Chip demonstriert.
Zusammenfassung
Generell kann gesagt werden, dass RFID die allgemeinen Probleme drahtloser Kommunikationen (z.B. Abstrahlung, Interferenz) sowie die grundlegenden Gefahren von Eingabesystemen (korrupte Eingaben) vereint. Eine umfangreiche Architektur mit entsprechendem Qualitätsniveau kann diese Probleme abfangen, wobei hier jedoch – so wie dies auch bei VoIP der Fall ist – die Vorteile der kostengünstigen Lösung relativiert werden müssen. Das Erreichen des Kompromisses zwischen Wirtschaftlichkeit und Sicherheit ist also auch bei RFID eine ganz besondere Herausforderung.
- Letzte Beiträge
- Sicherheitsverantwortlichkeiten und Risikosteuerung
- Computer Forensik – Ein Überblick
- Vortrag zu Security Testing an SGRP Veranstaltung
- Staatstrojaner – Kritik am neuen Bundesgesetz
- Overview of Microsoft’s security toolkit EMET
- Blog Digest April 2013
- Wie statisch sollten Sicherheitsrichtlinien sein?
- Timing für effiziente unentdeckte Portscans
- Interpreting a Logfile with Grok
- Spamhaus DDoS mit DNS Amplification
- Archiv