9. Juni 2010
Auf der DailyDave-Mailingliste gefunden:
Auf dem „Workshop on the Economics of Information Security 2010“ hat der mir vorher nicht bekannte Sam Ransbotham ein Paper veröffentlicht mit dem Titel: „An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software“ (PDF). Zu diesem Paper gibt es auch einen Artikel auf Technology Review.
Seine Kernaussage (und ich bin sicher, ein paar Leute bei Microsoft haben das mit Freude gelesen) ist, dass Open Source Software bezüglich Sicherheitslücken die vor der Veröffentlichung gefunden werden möglicherweise einen Sicherheitsvorteil gegenüber Closed Source hat. Falls Sicherheitslücken jedoch erst nach der Veröffentlichung gefunden werden, hat Open Source den Nachteil, dass jeder die Lücken sehen und leicht analysieren kann. Angreifer werden Lücken in Open Source deshalb bevorzugt ausnutzen.
Ich halte wie Dave Aitel sowohl die These für falsch, als auch die Zahlen die er zur Untermauerung verwendet.
Argument 1: Sicherheitslücken werden von Angreifern dann ausgenutzt, wenn es sich für den Angreifer lohnt. Die meisten Angriffe auf Rechner erfolgen heute durch Software wie Adobe Flash oder den Adobe Reader über den Webbrowser auf Windows. Der Grund ist einfach. Finanziell lohnt es sich eher, einen Angriff für das Betriebssystem von 94% der Rechner im Internet zu entwickeln als für die paar Mac OS X oder Linux-Rechner, selbst wenn z.B. der Linux-Source-Code komplett vorhanden ist. Und Flash ist als Browser-Plugin am weitesten verbreitet, auch deshalb werden Exploits speziell für Flash gesucht. Obwohl Flash Closed Source ist.
Argumtent 2: Die von ihm verwendeten Zahlen stimmen einfach nicht. Man kann die Anzahl der Einträge in der National Vulnerability Database (NVD) oder irgendeiner sonstigen Schwachstellendatenbank für Open Source und Closed Source einfach nicht vergleichen. Bei Open Source ist das Standard-Fehlerbehandlungsmodell, dass wenn eine Lücke bekannt wird, für diese Lücke ein Patch entwickelt wird und in den Source-Tree eingepflegt wird. Für die nächste Lücke gibt es den nächsten Patch und auch der wird direkt eingepflegt. Weil jeder den Source-Tree ansehen kann, gibt folglich jede Lücke einen eigenen Vulnerability-Datenbankeintrag. Bei Closed Source liegt es im Interesse des Herstellers (und meist auch der Kunden), dass nicht für jede Lücke direkt ein Patch veröffentlicht wird sondern alle Lücken in einem bestimmten Programm innerhalb eines gewissen Zeitraums in einem gemeinsamen Patch veröffentlicht werden, der hoffentlich gut getestet wurde. Microsoft macht das beispielsweise sehr gerne und behebt mit einem Patch in der Regel mehrere Lücken. Natürlich steht Closed Source dann bzgl. der reinen Zahl der Einträge in einer Schwachstellendatenbank besser da. Daraus jedoch Rückschlüsse auf die Sicherheit ziehen zu wollen ist dumm und naiv.
Im Ergebnis lässt sich mal wieder nur feststellen, dass Sam Ransbotham eine weitere Chance für einen realistischen und echten Vergleich der Sicherheit von Open und Closed Source vertan hat. Eine aussagekräftige und unabhängig überprüfbare Real-World Analyse fehlt mit leider bis heute. Aber egal, gehackt wird sowieso alles 🙂
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.
5. Juni 2010
3. Juni 2010
Kommunikation mit der Bank wird immer gefährlicher. Weder Internetbanking noch Geldautomaten sind noch ausreichend sicher. Aber egal, das Risiko trägt ja bekanntlich der Kunde.
BSI-zertifizierter Kobil Kartenleser gehackt
Tja, si eine BSI-Zertifizierung ist auch nicht mehr das, was sie nie war. Der Kobil SecOVID Reader III, der vom BSI für den Einsatz nach dem strengen deutschen Signaturgesetz (SigG) zugelassen wurde, kann mit einer fremden nicht signierten Firmware geflasht werden. Und schon hat sich die Sicherheit erledigt. Und sehr schön, das Problem wurde nicht allgemein bekannt gemacht, weil es sich um „eine überschaubare Kundengruppe“ handeln soll und die die Anwendungen für Geldkarte, HBCI und Secoder nicht von der Lücke betroffen seien. Stimmt zwar nicht aber klingt besser und beruhigt die Homebanking-Kunden die ja für den Schaden haften, wenn was schiefgeht.
Mehr Geldautomaten werden manipuliert
Das Abheben von Geld am Geldautomat wird dafür auch immer unsicherer. Das BKA warnt mal wieder vor Skimming, d.h. manipulierten Geldautomaten um Kartendaten und PIN abzugreifen. „Als normaler Kunde kann man eine Manipulation im Grunde nicht erkennen“, sagte BKA-Präsident Jörg Ziercke. Und: „Viele Banken würden die Manipulationen nicht melden, weil sie sonst um ihre Reputation fürchteten“. Na toll. Aber laut AGB haftet eh der Kunde.
OCSP rettet uns auch nicht
Und für das gewöhnliche Internet-Banking gibt es auch beruhigende Nachrichten für den bösen Hacker. Das Online Certificate Status Protocol (OCSP), das vom Browser verwendet wird um die Gültigkeit von SSL-Zertifikaten zu verifizieren kann geschickt manipuliert werden. Dazu erklärt man dem Browser über eine OCSP-Statusmeldung einfach, der Server sei überlastet und der Browser solle es später nochmal probieren. Das Standardverhalten der Browser ist dann, das Zertifikat halt solange anzuerkennen.
Mobile Banking bedroht
Und für die Freunde von Mobile Banking oder Mobile TANs gibt es zum Schluß noch den Hinweis, dass zumindest im Android Market bereits eine Applikation aufgetaucht ist, die Bankzugangsdaten ausspähen sollte. Ich denke wir werden noch viel mehr in diese Richtung erleben.
Ich sollte mir mein Gehalt vielleicht wieder bar auszahlen lassen 🙂
28. Mai 2010
Die bisherige Diskussion lief auf Grund meines Beitrags mit dem Titel „Victorinox Snake Oil Crypto?„. Dort hatte ich Bruce Schneiers Warnsignal #9 vor schlechter Kryptographie zitiert:
Warning Sign #9: Cracking contests: Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don’t produce useful data.
Und ich hatte darauf hingewiesen, dass Victorinox schlecht beraten sei, die Sicherheit ihres Produkts durch zweifelhafte Wettbewerbe beweisen zu wollen. Insbesondere, wenn die Angreifer nur wenige Stunden zur Verfügung gestellt bekommen. Die echte Gefahr ist, dass man den Stick verliert (oder er geklaut wird) und der Angreifer beliebig viel Zeit hat an die Daten zu kommen. Ich schrieb damals in den Kommentaren auch, dass ich den Stick für ein eigentlich durchdachtes Produkt halte.
Diese Meinung möchte ich jetzt revidieren. Hier sind meine Indizien:
Victorinox Warning Sign #1: Falsche Testimonials
Steffen Müller, der scheinbar offiziell im Namen von Victorinox in allen möglichen Foren und Blogs kommentiert und auch Hilfestellungen im offiziellen Victorinox-Forum gibt, schrieb hier in den Kommentaren:
Prof. Tom Wearbou (Security Head Engineer of NSA) wrote: “MKI’s new Schnuffi chipset: This is not only a chapter for itself, it’s also a new chapter in data history. We got some samples about 5 months ago. After 4 months working and almost 1 Million investment in new Hardware the chipset blows the whole device up before we had a real chance to get our hand on the data… This is not a normal chipset… this is a nasty bitch! “
Ich halte diese Behauptung für frei erfunden. Ich bin mir sehr sicher, dass es keinen Prof. Tom Wearbou gibt. Google findet für diesen Namen genau zwei Seiten und beide sind Kommentare zum Victorinox-Chip. Jeder Professor muss irgendwann ein paar wissenschaftliche Veröffentlichungen haben, sonst wird man nirgends auf der Welt Professor. Diese müsste man auch finden, selbst wenn der gute Mann bei einem Geheimniskrämerladen wie der NSA arbeiten sollte. Auch Varianten des Namens führen nicht weiter. Und Google ist sehr gut darin, mir bei Tippfehlern Alternativen vorzuschlagen.
Ich ziehe diese Behauptung natürlich sofort zurück, wenn mir irgendjemand einen Nachweis für diesen Professor bzw. ein solches Schreiben geben kann.
Victorinox Warning Sign #2: MKI Schnuffi Chip
Kryptographie ist schwierig. Siehe WEP. Selbst wenn man Kryptographie richtig versteht kann man sie immernoch falsch implementieren. Ich kann mir nicht wirklich vorstellen, dass eine (zugegebenermaßen gute) Messerschmiede einen tollen neuen Chip entwickelt, den niemand zerlegen kann. Haben sie wohl auch nicht.
Mein aktueller Wissensstand ist, dass die Technologie angeblich von Martin Kuster kommen soll, dem u. a. Parrot’s Consulting in Zug gehört. Parrot’s Consulting soll wiederum zu einer MKI Group (MKI = Martin Kuster International?) der MKI Enterprises gehören. Beide Webserver residieren auf der gleichen IP-Adresse. Das Anmeldefeld auf der Webseite von MKI sieht so aus als würde es nie verwendet. So wird bei der Eingabe das Passwort im Klartext angezeigt und der Anmeldeknopf führt direkt auf eine Fehlerseite. Auf Deutsch, die Webseite der MKI Enterprises, Rancho Bernardo, CA, USA sieht aus wie eine Alibiwebseite einer Firma die es gar nicht gibt. Domaintools behauptet, auf dem Server der Earthlink gehört (webhost.earthlink.net) werden 76.694 Webseiten gehostet.
Victorinox Warning Sign #3: USB Compliance
Der USB-Stick wurde nach meinen Informationen 2009 von NTS (National Technical Systems) auf Konformität mit dem USB-Standard getestet. Das Produkt hat den Text bestanden, kann jedoch nicht USB-IF zertifiziert werden, weil die Einschaltströme außerhalb der USB-Spezifikation liegen. Ich bin mir nicht mal sicher, ob Victorinox das „Certified USB High-Speed“-Logo das sich in den Datenblättern des Sticks befindet, überhaupt verwenden darf. Auf der Webseite des USB Implementation Forums gibt es eine Datenbank der zertifizierten Produkte. Ich kann da weder „Schnuffi“ noch „MKI“ und auch nicht „Victorinox“ finden. Ich habe aber vorsichtshalber mal eine Anfrage an das USB IF geschickt.
Ansprechpartner bei Victorinox für den Test war Martin Kuster. Hersteller des Chips laut Testbericht eine „MKI Electronics Division“, für die mir Google ein „Keine Ergebnisse für „mki electronics division“ gefunden“ ausspuckt. In der USB-Zertifizierung wird übrigens nur die Signalqualität gemessen, nicht die tatsächliche Übertragungsgeschwindigkeit des Gerätes. Ein High-Speed USB-Device muss deshalb noch keine High-Speed Übertragung anbieten.
Victorinox Warning Sign #4: Martin Kuster
Ich habe eine Weile überlegt ob ich diesen Abschnitt aufnehmen soll. Immerhin wird es jetzt etwas persönlich. Aber Martin Kuster behauptet, er habe den Snuffi Chip entwickelt und die Firma die den Chip baut, gehöre auch ihm. Außerdem behauptet auch Martin Kuster, die NSA hätte seinen Chip erfolglos versucht zu hacken.
Martin Kuster verwendet für die Kommunikation anscheinend gerne mal eine E-Mail-Adresse von MSN. Ich habe den Mailheader untersucht, die Mails gehen tatsächlich über hotmail.com. Auch die IP-Adressen im Header gehören alle Microsoft. Insofern finde ich wiederum den Footer in der Mail interessant, in dem steht:
„For you safety this message and its attachments (if applicable) were scanned for virus on MKI’s main mail server in Atlanta, Georgia / USA. This may delay the mail for a view minutes. „
Ich bin mir nämlich sehr sicher, dass die Mails niemals über einen MKI-Server in Atlanta gegangen sind.
Und das Gesamtpaket mit falschen Testimonials und einem Chip von einer praktisch nicht existenten Firma sieht für meinen Geschmack nach meiner sehr persönlichen privaten Meinung nun einmal sehr komisch aus.
Oder?
Ach ja, wenn jemand einen solchen USB-Stick hat, jedes USB-Teil hat eine Vendor-ID. Ich würde gerne mal wissen, wer da wirklich als Hersteller dahintersteckt. Ich mag da ungern 70 (8 GB) bis 190 Euro (32 GB) zum Fenster rauswerfen.
20. Mai 2010
Ultracool, was für ein Hack … auf The Register:
„Feihu Xu, Bing Qi and Hoi-Kwong Lo at the University of Toronto in Canada have developed a subtle „intercept and resend attack“ where they eavesdrop on some of the quantum bits sent during a quantum key exchange but not so many as push the error rate over the 20 per sent threshold. The boffins demonstrated such a „phase remapping“ attack against commercial quantum cryptography systems from ID Quantique.“
Um das zu verstehen, muss man wissen wie Quantenkryptographie funktioniert. Die Idee ist, man verschickt polarisierte Photonen (Lichtteilchen). Polarisierte Lichtteilchen haben den interessanten Effekt, dass sie durch einen identisch ausgerichteten Polarisationsfilter durchgehen, von einem anders ausgerichteten jedoch gefiltert werden. Einige 3D-Brillen basieren auf dem Prinzip, dass ein Auge nur horizontal polarisiertes Licht erreicht, das andere Auge nur vertikal polarisiertes Licht und dadurch zwei Bilder dargestellt werden. Soweit so langweilig. Spannend ist jedoch, wenn man einen falsch ausgerichteten Polarisationsfilter verwendet, ist das Photon weg und man kann nachträglich auch nicht mehr feststellen, wie es richtig gedreht gewesen wäre. Für einen Man-in-the-Middle bringt das ein großes Problem mit sich. Ja, man kann im Prinzip die Übertragung abhören ABER der Empfänger bemerkt IMMER, wenn die Übertragung abgehört wird und kann entsprechend reagieren. Dieses Prinzip lässt sich physikalisch beweisen. Da gibt es in der modernen Physik auch keinen Weg drumherum.
Naja, fast. Das Prinzip stimmt nämlich genau genommen nur für EIN EINZELNES Photon. In der Praxis kann man aber keine einzelnen Photonen schicken, da treten viel zu viele Störungen auf. Deshalb schickt man z.B. mit einem Laser immer gleich ein ganzes Lichtbündel. Und schon stimmt die Annahme nicht mehr. Bei einem Lichtbündel ist es nämlich möglich, ein paar wenige Lichtteilchen abzuzweigen und auszulesen während der Rest unverändert weiter geschickt wird. Beispielweise mit einem halbdurchlässigen Spiegel. Die Quantenkryptographiesysteme wissen das und reagieren deshalb mit einem Fehler, wenn mehr als 20% der Photonen in einem Lichtbündel fehlen oder falsch sind.
Man kann sich das für meine Freundin Laien vielleicht so vorstellen, dass man Tischtennisbälle einen Fluss hinab schickt. Weil man nicht weiß, ob alle ankommen schickt man jeden Ball nicht einmal sondern 100 mal. Und Alarm geschlagen wird, wenn weniger als 80 Tischtennisbälle am Ziel ankommen. Der Trick ist also jetzt, weniger als 20 Bälle von jedem Schwung abzufangen und trotzdem die Nachricht zu analysieren.
Die Kanadier haben es jetzt geschafft, ihr Angriffssystem so genau einzustellen, dass es mit deutlich weniger als diesen 20% zurechtkommt.
„The ID Quantique system is not broken, they say, but requires tweaking to get over the unsafe assumption that error rates of less than 20 per cent must be due to noise and can be safely disregarded.“
Im Prinzip haben sie damit recht. Nur muss in Zukunft wohl jedes Quantenkryptosystem dort wo es eingesetzt wird auch kalibriert werden, um die Grenze herauszufinden, bis zu der Fehler typischerweise auftreten. Die Pauschalannahme von 20% ist jedenfalls nicht mehr hilfreich. Mehr auch in Technology Review.
Mal sehen wie sich das weiterentwickelt.
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.
9. Mai 2010
Symantec war einkaufen und PGP gehört jetzt Symantec. PGP, als Software von Phil Zimmermann entwickelt und als Firma mitgegründet, war lange Jahre ein Geschäftsbereich von Network Associates, wurde von NAI jedoch nicht konsequent weiterentwickelt. Die PGP-Software wurde deshalb zurückverkauft und ist jetzt bei Symantec gelandet. Zusammen mit den vorher von PGP gekauften Unternehmen Glück & Kanja Technology, Chosen Security und TC Trustcenter.
Tja, der Norton Virenscanner von Symantec heißt bei uns intern „die gelbe Gefahr“. Securityfocus … ein Schatten seiner selbst. Die ganzen Tools von Atstake wie LC5 … verschwunden. Die Symantec Firewalls (ganz früher Axent Raptor, dann Symantec Enterprise Firewall, zuletzt Symantec Gateway Security) … eingestellt.
Ich fürchte, mit PGP werde ich in Zukunft auch nicht mehr froh.
4. Mai 2010
Und mal wieder ist eine fehlerhafte Implementierung von RC4 dran schuld. Wie bei WEP. Eigentlich spannend, dass man mit einem popligen Verschlüsselungsalgorithmus den Bruce Schneier schon in Applied Cryptography abgedruckt hat so viel falsch machen kann.
19. April 2010
Nmap startet mal wieder eine Umfrage nach coolen Webseiten und Produkten:
http://nmap.org/survey/
Ihr könnt Eure Meinung zu ein paar coolen neuen Features abgeben:
Beispielsweise einen 1. April Mode: „Occasionally give bogus results to keep users on their toes“ oder eine animierte Online-Hilfe: „Animated paper clip helper to provide suggestions and advice in formulating your scan“. Zumindest das zweite kennen wir ja schon von Microsoft 🙂
