7. Juli 2010
Microsoft beispielsweise. Erst mault der Softwarehersteller ständig über Full Disclosure, d.h. wenn Sicherheitslücken komplett für jeden zugänglich veröffentlicht werden (weil die bösen Hacker die Informationen ja auch lesen können), jetzt mault der Softwarehersteller über „Null Disclosure“, d.h. über Firmen die auf gefundenen Sicherheitslücken sitzenbleiben und Details nur gegen bares heraus rücken.
Tja liebes Microsoft. Wer auf soviel Cash sitzt wie ihr muss vielleicht selbst mal ein vernünftiges Bounty-Programm („Prämien für gefundene Sicherheitslücken“) aufsetzen. Dann klappt es auch wieder mit dem „Responsible Disclosure“, d.h. außer dem Hersteller erfährt sonst niemand von der Lücke. Denn ganz ehrlich, Fehlersuche ist harte Arbeit geworden. Die Zeiten als man mit einem billigen selbstgebastelten Fuzzer noch wahre Exploitorgien finden konnte sind lange vorbei. Viele dieser Tests machen die Softwarehersteller inzwischen selbst.
Ob der Weg von VUPEN allerdings richtig ist, erst nach Lücken zu suchen und dann den Softwareanbieter unter Druck zu setzen entweder er zahlt oder die Lücken werden anderweitig veröffentlicht, muss ich allerdings bezweifeln. Und da kann ich wiederum Microsoft gut verstehen, die sich in diesem Fall vermutlich direkt erpresst vorkommen und fürchten für umfangreiche weitere Erpressungen die Tür zu öffnen.
Auf jeden Fall bleibt es spannend.
21. Juni 2010
Kann man bestimmt mal wieder brauchen, bei Ausschreibungen zum Beispiel: NNEC Core Enterprise Services.
14. Juni 2010
Ich hatte erst vor ein paar Tagen hier einen Beitrag zu Vulnerability Disclosure veröffentlicht. Die gängige Diskussion ist dabei vor allem, was ist ein „Responsible“ Disclosure also eine verantwortunsbewußte Veröffentlichung von Sicherheitslücken. Hier wird in der IT-Security Branche bekanntlich heftig gestritten. Die eine Front verlangt ausreichend (notfalls beliebig) Zeit für die Hersteller um Sicherheitslücken zu beheben, die andere Front will Lücken so schnell wie möglich veröffentlichen um Hersteller zu zwingen, auf bekannte Lücken auch tatsächlich zügig mit einem Patch zu reagieren. In der Praxis lassen viele Leute dem Hersteller zwischen 30 und 90 Tagen Zeit um einen Patch zu entwickeln und veröffentlichen dann Details zu einer Lücke, auch wenn der Hersteller nach dieser Zeit noch keinen Patch veröffentlicht hat. Das ist ein relativ guter Kompromiss zwischen beiden Lagern.
Aktuell gibt es jetzt einen Fall in dem der Entdecker einer Lücke dem Hersteller nur wenige Tage gelassen hat und schon sind wieder alle am Streiten.
Tavis Ormandy, ein Entwickler bei Google hat eine technisch interessante (weil recht komplexe) Sicherheitslücke im Hilfe- und Support-Center von Microsoft Windows entdeckt. Details zur Lücke und einen Demo-Exploit hat Tavis am 10.06. auf der Full-Disclosure Mailingliste veröffentlicht. Die Mailingliste kann jeder abonnieren und bekommt automatisch alles zugeschickt was dorthin geschickt wird. Leider ist auch viel Schrott auf der Liste, weil sie kaum moderiert wird. Microsoft wurde am 05.06. von Tavis über diese Lücke informiert und hat den Eingang am gleichen Tag bestätigt.
Tavis wirft Microsoft jetzt vor, seit 05.06. nichts mehr gehört zu haben, nimmt deshalb an, es kümmert sich keiner um die Lücke und veröffentlicht 5 Tage später den Exploit mit dem dezenten Hinweis:
„Those of you with large support contracts are encouraged to tell your support representatives that you would like to see Microsoft invest in developing processes for faster responses to external security reports.“
Und das ausgerechnet von einem Mitarbeiter von Google, der Firma die vor wenigen Wochen großmäulig Microsoft-Betriebssysteme in die Tonne getreten hat. Das hat schon ein „Geschmäckle“. Tavis begründet sein schnelles Disclosure zwar unter anderem damit, dass er vermutet die bösen Hacker würden diese Lücke bereits ausnutzen. Dafür fehlen jedoch die nötigen Beweise. Außerdem hat Tavis einen Workaround mitgeliefert, der den Angriff verhindern sollte bei dem sich jedoch herausgestellt hat, dass der Schutz nicht richtig wirksam ist.
Und nun stellt sich die berechtigte Frage, ob das Vorgehen von Tavis noch von „Responsible Disclosure“ gedeckt ist oder ob ein Google-Mitarbeiter die gute Gelegenheit genutzt hat, mit einer neuen Sicherheitslücke Microsoft eins auszuwischen und den Konzern vielleicht sogar dazu zu nötigen, einen Patch außerhalb der normalen Update-Sequenz herauszubringen. Und damit quasi als Kollateralschaden Millionen von Windows-Anwendern gefährdet. Ich weiß es nicht. Aber als Administrator bin ich über „aus der Reihe Patches“ nie besonders glücklich. Vermutlich hätte man die Kommunikation über diese Lücke klüger handhaben könne.
13. Juni 2010
Ich habe diese Woche am Dienstag in Düsseldorf auf der Hausmesse der Infinigate (IT-Security Distributor) die Keynote gehalten. Mit Wiederholung am 8. Juli in München.
Der Titel ist etwas provokant, im Hinblick auf die vielen Hersteller von IT-Security-Lösungen, die auf dieser Hausmesse ausstellen:
„Der Kampf gegen Hacker, Spam und Viren ist verloren! Das Spamaufkommen steigt seit Jahren kontinuierliche an, neue Spamfilter werden schneller überlistet als sie entwickelt werden können. Die Anzahl und Variabilität von Schadprogrammen wächst ebenso rapide. Gezielt für ein Opfer entwickelte Trojaner überlisten gängige Virenscanner, ganz im Gegenteil werden Scanner selbst Angriffsziel von Hackern. Insgesamt nehmen die Angriffe gegen IT-System weiter zu, die Schäden durch Angriffe und Industriespionage steigen. Die Sensibilisierung von Anwendern kostet immense Summen, der Nutzen bleibt zweifelhaft. In jeder Firma findet sich irgendwo ein Genie, das auf jedes Attachment klickt und sei es noch so verdächtig. Ein Plädoyer für einen neuen Umgang mit Sicherheitsrisiken.“
Im Kern geht es aber um zwei Aussagen, die sich in diesen zwei Schlüsselfolien der Präsentation wiederfinden:
In den meisten Firmen gibt es verschiedene Abteilungen und Gruppen, die neue IT-Systeme in das Firmennetz einbringen. Für Server ist meistens die IT-Abteilung zuständig, für mobile Rechner jedoch oft einzelne Abteilungen die dann Systeme einsetzen die von der IT nicht gewartet werden können (z.B. Mac OS X). Genauso schlimm sind Blackberry oder iPhone, wenn der Betrieb von der Geschäftsleitung verordnet wird ohne sich vorher um Sicherheitsthemen Gedanken zu machen. Warum ist eine Risikobewertung vor Einführung in der großen EU möglich, in einer kleinen/mittleren/großen Firma jedoch nicht?
Die zweite Folie stellt die Frage was zu tun ist, wenn es mal kracht. Jedes Auto hat heute einen Airbag (den ich noch nie gebracht habe). Solange nichts passiert ist der völlig unnötig. Erst nach dem Unfall wird der Airbag notwendig und verringert den Schaden. Seltsamerweise gehen fast alle Unternehmen davon aus, dass in ihren Netzen niemals ein Schaden auftritt, als wäre noch nie irgendwo ein Hacker eingebrochen. Obwohl uns z.B. Hannaford, Google und das Bundeskanzleramt das Gegenteil beweisen. Aber kein einziges Unternehmen das ich kenne hat einen brauchbaren „Airbag“ für die IT, also geeignete Maßnahmen zur Schadensbegrenzung.
Ich bin ja mal gespannt, wer sich davon angesprochen fühlt.
Disclaimer: Ich berate beruflich Firmen zu Sicherheitskonzepten, Risikoanalyse und Schadensbegrenzung 🙂
7. Juni 2010
Früher gab es ja immer die Diskussion, ob und wie Sicherheitslücken veröffentlicht werden sollen. Da gab es im großen und ganzen drei Schulen:
1. No Disclosure
No Disclosure bedeutet, man hält die Lücke einfach für sich selbst geheim. Kann man immer mal brauchen. Mit dem Risiko, dass natürlich jemand anderes die Lücke auch findet. No Disclosure war früher typisch bei Schadprogrammautoren. Wenn die mal eine Lücke hatten, wurden damit Schadprogramme verbreitet und irgendwann über Projekte wie das Honeynet wurde dadurch die Lücke irgendwann bekannt und gestopft.
2. Responsible Disclosure
Das war der Begriff den Firmen wie Microsoft geprägt haben, die Sicherheitslücken am liebsten vertuscht haben. Mit Responsible Disclosure sollte eine Sicherheitslücke nur dem Hersteller bekanntgegeben werden damit dieser dann beliebig lange Zeit hat die Lücke zu beheben. Ein paar Firmen wollten daraus sogar einen Standard (RFC) machen, der aber glücklicherweise dann nicht in den Standard aufgenommen wurde. Firmen wie eEye konnten zeigen, dass sich Microsoft bei „responsible“ bekanntgegebenen Lücken sehr viel länger Zeit lässt, diese zu beheben. In der Praxis hat sich eine Art Responsible Disclosure durchgesetzt, weil die Sicherheitsfirmen halt auf Aufträge der großen Softwarehersteller angewiesen sind.
3. Full Disclosure
Sicherheitslücken, möglicherweise inkl. Exploit werden auf einer öffentlichen Webseite oder Mailingliste bekanntgegeben und stehen damit Softwarefirmen genauso wie Angreifern direkt und gleichzeitig zur Verfügung. Ein Softwarehersteller muss dann natürlich schnell reagieren und einen Patch bereitstellen der möglichst keine Nebeneffekte haben darf d.h. unter Zeitdruck sorgfältig entwickelt und getestet werden muss.
Heute muss man meiner Ansicht nach andere Kriterien anwenden:
1. Free Disclosure
Sicherheitslücken bzw. Exploits werden (egal wann) auf einer kostenfreien Webseite oder Mailingliste bereitgestellt. Namentlich kann man SecurityFocus oder Metasploit nennen.
2. Disclosure über einen Exploit Broker
Eine Reihe von Agenturen kaufen Sicherheitslücken von Entwicklern auf und geben diese dann an den Herstellern weiter. ZDI (TippingPoint/3Com/HP), iDefense (Verisign) und Co. sind hier zu nennen. Ein Exploit Broker hat den Vorteil, dass man mit einem Exploit Geld verdienen kann, jedoch praktisch kein Risiko eingeht, wegen dieses Exploits auch verklagt zu werden. Gerade für einzelne Programmierer ist das eine brauchbare Alternative.
3. Kommerzielle Exploit-Software
Neben ZDI/iDefense gibt es auch Firmen wie Core oder Immunity, die Sicherheitslücken z.B. von freiberuflichen Exploitentwicklern kaufen und in ihre kommerziellen Frameworks mit aufnehmen. Dazu gibt es sogar eine „No more free bugs“ Initiative.
Mein Eindruck ist, dass sich der Trend zu kommerziell vermarkteten Sicherheitslücken in den nächsten Jahren verstärken wird. Das wird dazu führen, dass nur noch große finanzkräftige Firmen sich alle notwendigen Sicherheitslücken z.B. für Penetrationstests zusammenkaufen können. Ob das eine wünschenswerte Entwicklung ist, will ich mal offen lassen.
Literatur zum Nachlesen:
Ich bin gespannt, wie sich das weiterentwickelt.
1. Juni 2010
Sehr schöne Beschreibung, was beim Betrieb eines komplexen Netzwerks alles schief gehen kann …
Und bestätigt meine alte These, dass neben der vorbeugenden Sicherheit längst auch ein Risikomanagement und geeignete Maßnahmen für einen Sicherheitsvorfall implementiert werden müssen.
22. Mai 2010
Mobile Bank Dispenser … nur das Bild und das Original bei Flicker (leider keine CC-Lizenz, deshalb nur verlinkt)
19. Mai 2010
In der Zeit bin ich auf einen Artikel gestossen: „Auch Autos kann man hacken„.
Da beschreiben also die leet haxor amerikanischen „Sicherheitsforscher“, dass man über den Diagnose-Port des Autos Zugriff auf sensible Systeme bekommen und den Fahrer komplett abklemmen kann. Ach? Ich dachte immer, das sei die Funktion des Diagnose-Ports, Komplettzugriff auf die gesamte Elektronik/IT des Fahrzeugs zu bekommen. Und in meinem Auto versteckt sich der Diagnose-Port hinter einer Klappe unterhalb des Aschenbechers im Amaturenbrett.
Wenn ich mir jetzt vorstelle, mit sagen wir mal 180 km/h über eine deutsche Autobahn zu brettern und mitten während der Fahrt springt mir so ein amerikanischer Sicherheitsforscher durch die Tür auf den Beifahrersitz, klemmt seinen Computer an den Diagnose-Port an und übernimmt mein Fahrzeug … ja, das klingt wie eine reale Gefährdung. In Zukunft werde ich bei Geschwindigkeiten oberhalb 130 km/h vorsichtshalber die Türen verriegeln. Kann man in der Elektronik irgendwie automatisch einstellen, ist bei mir aber aktuell aus.
Sehr cool auch der Absatz: „Sie manipulierten den Testwagen auch drahtlos […]. Dafür musste das Opfer-Fahrzeug allerdings bereits mit einem entsprechenden Rechner zum Empfang der Signale verbunden sein.“ Fällt mir auch gar nicht auf, so ein Laptop auf dem Beifahrersitz. Höchstens, wenn kein Platz mehr für meinen eigenen ist.
Aber im Ernst … das ist, wie wenn man auf einem Unix-System dem amerikanischen Sicherheitsforscher das root-Passwort in die Hand drückt und der dann erstaunt feststellt, dass man damit das System kontrollieren und berechtigte Benutzer aussperren kann.
Also wenn der aktuelle Stand der IT-Sicherheitsforschung in Fahrzeugen ist, den Diagnose-Port zu entdecken, na dann gute Nacht. Das ist im Grunde schon wieder peinlich.
10. Mai 2010
Mal wieder was aus der Arbeit, weil ich zur Zeit viel mit Juniper-Geräten zu tun habe.
Juniper Networks hat ein paar Broschüren in der Reihe „Day One“ veröffentlicht, die einen Einstieg am „ersten Tag“ in ein bestimmtes Thema eröffnen sollen. Die meisten davon sind sehr spezifisch auf JUNOS zugeschnitten und deshalb für alle nicht JUNOS-Nutzer eher nutzlos. Es gibt aber eine nette Einführung in IPv6, die auch für alle anderen interessant sein könnte.
Und ein paar neue Schulungsunterlagen hat Juniper auch veröffentlicht. Darunter die kompletten Einführungsschulungen für JUNOS (IJS, JRE, TJP, OESJ), Routing (OJRE, AJRE), Switching (OJXE) und Security (JSEC). Insgesamt acht Schulungen, deren Schulungsunterlagen praktisch komplett frei (Registrierung erforderlich!) im Netz stehen.
Schade, dass die Geräte nicht günstiger sind.
8. Mai 2010
Ich hab da noch eine lange Liste von Links die ich mir mal aufgehoben habe um hier im Blog darüber was zu schreiben. Die werde ich jetzt langsam abarbeiten.
Gesichtserkennung überlisten
Auf der Defcon 17, im August letzten Jahres gab es einen Wettbewerb wie man automatische Gesichtserkennungssysteme austricksen kann. Gewonnen hat ein Cap, das mit LEDs ausgestattet ist die so pulsieren, dass Gesichtserkennungssysteme nicht mehr richtig funktionieren. Sieht lustig aus, das Teil.
Fooling Face Recognition Systems with Makeup
Zu diesem Thema gibt es übrigens schon ein wenig Sekundärliteratur: „Most faces have a dark region just above the eyes, while the cheek bones and nose bridge will appear lighter. When the algorithm detects enough such attributes, it guesses the object is a face.“ Durch geschickte Verwendung von Makeup kann man nun erreichen, dass diese Hell-Dunkel-Flächen nicht mehr korrekt erkannt werden. Cnet und The Register haben mehr dazu. Und Lady Gaga.
Äh … ja
Rémi Gaillard ist ein französischer Aktionskünstler der immer wieder Aktionen bringt bei denen einem echt nichts mehr einfällt. Der Rocky-Verschnitt im Supermarkt beispielsweise oder im Mario Kart durch Paris fahren. Hat weder was mit Gesichtserkennung noch mit IT-Security zu tun, ist aber trotzdem lustig.
Der Wert von Security-Zertifizierungen
Die meisten Zertifizierungen fragen einfach nur gelerntes Wissen ab. CISSP ist so ein Beispiel. Im Grunde kann man sich ne Woche hinsetzen und Fragen und Antworten auswendig lernen und kann dann kaum noch durchfallen. Entsprechend umstritten sind manche dieser Zertifizierungen, wie der Aufruf zum Capture The Flag Wettbewerb der diesjährigen Defcon beweist: „Those with SANS certs need not apply. CISSPs are right out. CEH holders…well, we sorta feel a little bit sorry for those that admit to holding this cert and abstain from mocking.“ Sehr schön. Ach ja, Meldeschluß ist am 20. Mai.
