3. Mai 2010
Fefe rantet gerne mal in alle möglichen Richtungen und meistens hat er ja recht. In einem konkreten Fall möchte ich ihm aber widersprechen und zwar wenn es um den Sicherheitsbeauftragten von Facebook geht. Der hat laut Heise in einem Interview festgehalten:
„Kelly gab bei Facebook die Devise aus, dass das Sammeln von Informationen über Attacken und die dahinter stehenden Kriminellen wichtiger ist als das Stopfen sämtlicher Lücken.“
Daraus hat Fefe sich zu folgender Aussage verstiegen:
„Der Polizist ist gewohnt, Verbrecher zu verfolgen. Wenn er die Lücken alle fixt, dann ist er aus seiner Sicht arbeitslos. Also kann er das nicht tun. Stattdessen wird er sich zusammenrationalisieren, dass das eh nicht geht, und seine Ressourcen für Honeypots und ähnlichen Mumpitz ausgeben.“
Das ist in diesem Zusammenhang meiner Ansicht nach völliger Quatsch. Ich kann mir gut vorstellen, dass der Code von Facebook inzwischen so komplex ist, dass sie gar nicht mehr alles sicher programmiert kriegen. Das ist wie mit Windows. Microsoft kriegt da auch nicht alle Fehler raus, ganz im Gegenteil. Und noch schlimmer ist, mit jeder Iteration können neue Fehler und ganz neue Fehlerklassen auftreten, die bisher niemand berücksichtigt hat. Beispielsweise durch den PHP-Compiler. Stefan Esser, der gerade wieder den Month of PHP-Bugs ausgerufen hat, kennt sich da am besten aus. Der findet Fehler in PHP, an die vorher niemand gedacht hat. Völlig neues kreatives Zeug.
Genau deshalb ist es extrem wichtig, dass man nicht nur Fehler schließt sondern auch neue Fehler und Probleme erkennen kann, bevor sie echten Schaden auslösen. Das genau ist effizientes Risikomanagement. Ob man dazu Honeypots braucht sei dahingestellt, wichtig ist aber, den Sicherheitsvorfall möglichst schnell zu erkennen und einzudämmen. Mein Lieblingssatz dazu lautet: „All Control Is Damage Control„.
Oder wie das Donald Rumsfeld mal formuliert hat:
„There are known knowns. These are things we know that we know. There
are known unknowns. That is to say, there are things that we know we
don’t know. But there are also unknown unknowns. There are things we
don’t know we don’t know.“
Und auf die müssen wir auch achten, nicht nur auf die Lücken!
15. April 2010
So langsam wird das ja mein Lieblingsthema hier im Blog: IT-Sicherheit und Vertrauen. Wem vertrauen wir und warum? Lässt sich das überhaupt rational begründen? Manches kommt mir schon seltsam vor. Trust Center beispielsweise führen im Namen schon die Bezeichnung „Trust“. Gerade so, als wäre es zwingend notwendig darauf hinzuweisen, dass man diesen Centern doch bitte auch vertrauen soll. Ein normaler, vernünftiger Mensch würde das nämlich nicht tun.
Der aktuelle Anlass um mal wieder über Trust Center zu polemisieren ist die Art und Weise, wie manche Zertifizierungsstellen die Identität eines Antragsstellers überprüfen. Dazu muss man wissen, dass sich in der Praxis vier (genauer 4,5) Klassen der Identitätsprüfung herausgebildet haben:
- Class 0: keine Überprüfung des Antragsstellers. Hier wird ein Zertifikat ausgestellt, ohne den Antragsteller überhaupt zu prüfen. In der Praxis wird das nur für Testzertifikate gemacht, die sich nicht gegen eine bekannte CA verifizieren lassen.
- Class 1: Überprüfung der E-Mail Adresse. Das ist praktisch für E-Mail-Zertifikate. Man schickt einen Antrag an die Zertifizierungsstelle und die schickt das Zertifikat an die angegebene E-Mail Adresse zurück. Wenn man das empfangen kann ist es offensichtlich korrekt. Eine weitere Überprüfung ist nicht notwendig. Das ist sehr günstig und effizient aber halt nur eingeschränkt sicher.
- Class 2: Überprüfung der Organisation anhand von irgendwelchen Unterlagen. Hier wird geprüft, ob es z.B. die Organisation des Antragstellers tatsächlich gibt, ob die Domain eines Webservers tatsächlich dem Antragsteller gehört, usw. Allerdings nur auf Basis öffentlich zugänglicher Dokumente. Beispielsweise kann ich für mitternachtshacking.de ein Zertifikat beantragen mit dem Namen der in DeNIC als Eigentümer der Domain registriert ist aber nicht auf einen anderen Namen.
- Class 3: Überprüfung der Organisation mit Kontaktaufnahme. Hier wird in der Regel die Organisation geprüft und zum Antragsteller direkt Kontakt aufgenommen. Die meisten deutschen Zertifizierungsstellen machen das beispielsweise durch PostIdent. Bei den amerikanischen Beutelschneidern weiß ich das gar nicht. Meistens gibt es da ein Fallback auf Class 2.
- Die letzte halbe Klasse ist dann das „Extended Verification“ von Verisign. Ich denke das kommt auch dadurch, dass es in den USA kein PostIdent oder vergleichbar gibt und für Class 3 dann eigentlich nur eine etwas erweiterte Class 2 Prüfung stattfindet. Mit dem „Extended Verification“ wird dann halt ein wenig mehr geprüft. Wenn überhaupt.
Soweit ist das ja ok. Allerdings setzt bereits eine Class 2 Verification einen gewissen Aufwand voraus. Unter Umständen kann man das nicht komplett automatisieren sondern muss manuell prüfen, ob die ganzen Daten übereinstimmen. TC Trustcenter hat sich bei mir da mal verdient gemacht (das ist jetzt ausnahmsweise nicht ironisch), weil sie es abgelehnt haben ein Zertifikat auszustellen in dem die Daten nicht 100% mit den Unterlagen übereingestimmt haben. (Ursache war, dass wir am umziehen waren und ich das Zertifikat schon mal auf die neue Anschrift ausgestellt haben wollte).
Der eine oder andere Zertifizierungsstellenbetreiber ist deshalb auf folgenden Trick gekommen, den Aufwand zu minimieren:
Man definiert ein paar sogenannter „System-E-Mail-Adressen“, die per Definition (par ordre de mufti) in jedem Mailsystem vorhanden sein müssen und die dann vertrauenswürdig sind, weil die nur vom Betreiber des Mailsystems und damit vom Eigentümer der Domain genutzt werden können.
Das ist eine mutige Annahme. Darunter befinden sich nämlich auch so Adressen wie:
- administrator@domain.org
- admin@domain.org
- info@domain.org
- hostmaster@domain.org
- root@domain.org
- ssladmin@domain.org
- sysadmin@domain.org
- webmaster@domain.org
- info@domain.org
- postmaster@domain.org
und teilweise noch abwegigere wie
- ssladministrator@domain.org
- it@domain.org
- dnsadmin@domain.org
In irgendwelchen nie gelesenen RFCs sind tatsächlich alle diese E-Mail Adressen für besondere Zwecke mal reserviert worden. Die meisten Mailsysteme und praktisch alle Administratoren wissen aber nichts davon. Und wenn dann ein normaler Anwender eine dieser Mailadressen hat, kann er damit beispielsweise SSL-Zertifikate für die Domain beantragen obwohl er dafür gar nicht berechtigt sein sollte.
Aufgeflogen ist das ganze jetzt mal wieder, weil Kurt Seifried beim Freemail-Anbieter Portugalmail die nicht gesperrte E-Mail Adresse ssladministrator@portugalmail.pt registriert hat und damit erfolgreich ein SSL-Zertifikat für die Domain portugalmail.pt bei RapidSSL bekommen hat. Übrigens mal wieder eine 100%ige Tochter von Verisign. Dokumentiert ist das in einem Bugreport bei Mozilla der fordert, RapidSSL aus den vertrauenswürdigen Zertifizierungsstellen zu entfernen sowie in einem Artikel im Linux Magazine.
Passieren wird aber mal wieder nichts, weil sich die Mozilla Foundation nicht mit dem mächtigen Konzern Verisign anlegen will. Und RapidSSL hat ja auch verkünden lassen, Zertifikate nur noch bei einigen wenigen Mailadressen einfach so rauszuschicken. Klingt ganz toll, löst nämlich das darunterliegende Problem nicht: Erschreckend vielen Zertifizierungsstellen ist es offensichtlich einfach viel zu teuer die eigentlich geforderte korrekte Überprüfung des Antragstellers auch durchzuführen. Statt dessen wird da gemauschelt und geschummelt was das Zeug hält. Eigentlich gehört das ganze Sicherheitskonzept von SSL entsorgt und neu entworfen.
Und darum heißen diese Firmen ja auch Trust Center, sonst würde denen schließlich niemand vertrauen.
24. März 2010
„Oh mein Gott, wir werden alle störben“ ((C) by Fefe). Ach nein, Irrtum. Ist ja nur eine Prophezeiung von Gartner. Die Wahrsager mit der Glaskugel behaupten, dass im Jahre 2012 60% der virtualisierten Server weniger sicher sind als die Systeme die sie ersetzen.
Wie das? Werden alle Linux-Server durch Windows ersetzt? Oder umgekehrt? Liegt es daran, dass nur noch schlecht ausgebildete Administratoren auf den Markt kommen? Sogenannte Daudministratoren? Nein, die Virtualisierung ist schuld!
„So argumentieren die Marktforscher an mehreren Stellen mit der Möglichkeit, dass ein Angreifer über Sicherheitslücken in der Virtualisierungssoftware aus einer VM ausbrechen und den Hypervisor oder andere VMs auf dem selben Server erfolgreich attackieren könnte.“
Aha … VMware ist also Schuld. No shit Sherlock ((C) by Fefe). Nun gut, eigentlich ist das nichts sonderlich neues. Aber schön, dass die Glaskugelleser von Gartner das auch schon bemerkt haben.
Und die Lösung? Die könnte von Captain Obvious ((C) by Fefe) kommen. Einfach IT-Sicherheit von Anfang an im Planungs- und Designprozess berücksichtigen, dann klappt’s auch mit der Nachbarin Virtualisierung. Und dafür verlangt Gartner Geld …
19. März 2010
Diesen Link zu Coding Horror habe ich schon länger archiviert, als Nachtrag zu meinem DoS-Artikel kann ich ihn endlich verwenden.
Rate Limiting, d.h. die Beschränkung von gleichzeitig ausgeführten Operationen z.B. Datenbankabfragen in einer Webapplikation kann ebenfalls als Maßnahme gegen Denial-of-Service Angriffe genutzt werden. Das Problem ist nur, zu wissen wann „zu viel“ wirklich zu viel ist. Was ist normales Verhalten (das sich im Laufe der Zeit ändern kann) und was ist ein tatsächlicher Angriff?
Jeff Atwood visualisiert das Problem mit einem Schild an der Eingangstür eines Ladens:
All the signs have various forms of this printed on them: Only 3 students at a time in the store please
Die Vorstellung ist aber auch zu lustig:
- Couldn’t three morally bankrupt students shoplift just as effectively as four?
- How do you tell who is a student? Is it based purely on perception of age?
- Do we expect this rule to be self-enforcing? Will the fourth student walk into the store, identify three other students, and then decide to leave?
Das kann gar keine präzise Wissenschaft sein 🙂
18. März 2010
In Neuss war wie jedes Jahr die Architecture, die Hausmesse von Ingram Micro. Ich hatte wie die letzten Jahre auch die Einführungs-Livehacking Präsentation und habe einen kleinen Mix aus verschiedenen Themen vorgeführt … ein wenig Industrispionage mit Hardware-Keyloggern, ein wenig Abhören von unverschlüsselter Datenkommunikation und ein wenig zu Rootkits, die sich im System einnisten. Nichts besonders spektakuläres aber ein ganz amüsanter Mix, wie ich fand. Das Feedback war jedenfalls gut.
Hier die Präsentation (PDF).
Nächstes Jahr ist mal wieder Sprachkommunikation dran. Ich möchte VoIP und DECT abhören und mal sehen, was dann der Stand von GSM ist.
Ansonsten war der Vortrag von Matthias Leu sehenswert. Ich hoffe den gibt es irgendwann online. Matthias gräbt gerne die Security Trends der nächsten Jahre aus, er hat da echt eine Nase für. Und die Übersicht falscher Virenscanner war lustig 🙂
14. März 2010
Mich hat folgende Anfrage erreicht:
Ich bin dabei eine Seminararbeit zum Thema Methoden und Konzepte zur Mitarbeitersensibilisierung schreiben. Nun meine Frage: Gibt es hierzu einschlägige und gute Literatur?
Ich tue mir da ein wenig schwer. Viel Material das ich verwende habe ich mir selbst ausgedacht oder ist im Rahmen von Projektarbeiten entstanden. Aktuell arbeite ich gerade wieder für und mit einem Kunden an mehreren Filmen, Fotostories und einer Plakataktion zur Mitarbeitersensibilisierung.
Mir fiel so spontan deshalb gar nicht viel ein (Reihenfolge ohne Wertung):
- Bücher
- Broschüren und Artikel
- Webseiten
- Öffentliche Dokumente
Das sind im großen und ganzen die Sachen die ich gelesen haben. Über Ergänzung in den Kommentaren würde ich mich freuen.
Voraussetzung zur Aufnahme in diese Liste ist natürlich, dass es sich um öffentliche, frei zugängliche und zitierfähige Dokumente sind. Irgendwelche Pressemitteilungen und Werbeflyer von Firmen helfen nicht weiter. Reine Firmenwerbung ohne Inhalte in den Kommentaren wird von mir deshalb auch nach Gutdünken gelöscht.
12. März 2010
Ich überlege gerade für einen Freund, wie man eine Beschreibung von Denial-of-Service Angriffen (DDoS ist nur ein Randthema) und möglichen Gegenmaßnahmen sinnvoll gliedern kann. Meine Idee geht dazu, die verschiedenen Angriffsebenen als Gliederungspunkt heranzuziehen, weil man auf Netzwerkebene halt andere Gegenmaßnahmen hat und braucht als auf Anwendungsebene.
- Einleitung
- Definitionen
- DoS im Systembetrieb
- Redundante Netzverbindungen
- Redundante Stromversorgung
- Sonstige Hardware-Fehler
- DoS in der Netzwerkkommunikation
- DoS auf Layer 2 (ARP, …)
Praktisch irrelevant, da Angreifer vor Ort sein müssten
- DoS auf Layer 3/4 (Smurf, Fraggle, Land, SYN-Flooding, …)
Praktisch irrelevant, da von Firewalls zuverlässig erkannt und im OS gefixt (SYN-Flooding)
- DoS auf Betriebssystemebene
- OS resource exhaustion (RAM, CPU, …)
Mehr eine Frage der Kapazitätsplanung
- Implementierungsprobleme
Lösung könnte ein OS-Wechsel oder Stack-Tuning bringen
- DoS auf Anwendungsebene
- Application resource exhaustion (Memory Allocation, …)
Programmierfehler, Code Analyse hilft
- Sonstige Fehler in Anwendungen
Logikfehler, Concurrency, …
- DoS auf sonstigen Ebenen
- Benutzeraccounts blockieren
DoS gegen Sicherheitsmaßnahmen
- Überlastung durch überraschendes Benutzerverhalten
„Heise-DoS“, Frage der Kapazitätsplanung
- Distributed DoS
- DDoS auf Netzwerkebene
- DDoS auf Betriebssystemebene
- DDoS auf Anwendungsebene
- Gegenmaßnahmen
- Schutz auf Layer 2
- Schutz auf Layer 3/4
- Schutz auf Betriebssystemebene
- Schutz auf Anwendungsebene
- Kosten/Nutzen-Relation
Ist das sinnvoll? Habe ich was wichtiges vergessen?
Nachtrag:
Ideen von Tobias bereits eingearbeitet.
10. März 2010
F-Secure hat festgestellt, dass der Adobe Reader die gefährdetste Anwendung ist. Fast 49 Prozent aller Client-Side Angriffe richten sich gegen den Reader oder das Reader-Plugin im Browser. Auf Platz zwei mit rund 39 Prozent folgt Microsoft Word. Es wird also Zeit, über Alternativen nachzudenken. Mehr bei F-Secure.
(via The Register)
6. März 2010
Nur kurz erwähnt: Google hat einen Beitrag „Best Practices for Verifying and Cleaning up a Compromised Site“ online gestellt.
Ein paar Tipps sind sicher hilfreich, ob ich meine Webseite aber deshalb unbedingt bei Google registrieren muss weiß ich nicht. Das alte „komplett löschen und vom letzten sicheren Backup wiederherstellen“ ist meiner Meinung nach immer noch die beste Methode.
24. Februar 2010
„Don’t just shorten your URL, make it suspicious and frightening.“ 🙂
Beispielsweise diese:
Und wenn diese URL nicht funktioniert, dann vielleicht diese?
oder doch besser was harmloseres?
Passende URLs gibt’s bei http://www.shadyurl.com/. Klingt lustig, hat aber durchaus einen ernsten Hintergrund.
