The Rolling Stone has an article on homegrown terrorism in the U.S., grown by task forces that are supposed to fight terrorism:
»The FBI now has more than 100 task forces devoted exclusively to fighting terrorism. But is the government manufacturing ghosts?«
Manufacturing ghosts makes a lot of sense, marketing-wise, if you are an officially appointed ghostbuster.
Vor einer Woche hatte mich eine Werbemail der Firma ClearSwift zu diesem Ad-hoc-Test inspiriert. Versprochen war Data Loss bzw. Data Leak Protection und ich wollte wissen, ob der Anbieter schnell merkt, dass jemand über ihn bloggt. Erbeten war eine schnelle Reaktion hier im Blog oder auf anderem Wege. Einen festen Termin gab es nicht, aber eine Woche sollte wohl genügen. Reaktionen gab es keine. Das könnte verschiedene Gründe haben:
Zum Mitspielen hätte man übrigens überhaupt keine Sicherheitslösung gebraucht, weil es ja Google gibt und Google gern Benachrichtigungen zu beliebigen Anfragen verschickt. Jeder, der auch nur eine Spur von Eitelkeit zu seinem Wesen zählt, hat einen Google Alert auf seinen Namen bestellt. Tja.
Heise Security weist auf die bereits erwartete TrueCrypt-Version 5.0 hin. Nicht neu ist das Lieblingsfeature aller Nerds, Plausible Deniability. Mit TrueCrypt könne man wirklich geheime verschlüsselte Daten hinter weniger geheimen verschlüsselten Daten so verstecken, dass dies unmöglich nachzuweisen sei, raunt es bei jeder Erwähnung von TrueCrypt im Netz. Über all die lästigen Details, über Angreifermodelle, Randbedingungen, Interessen und praktische Möglichkeiten, geht man für gewöhnlich hinweg.
Um so angenehmer ist es, ausgerechnet im als Trollsenke verrufenen Forum zur Heise-Meldung eine andere Sicht zu lesen. Teilnehmer Catsuit macht sich dort Gedanken, wie die scheinbare Plausibilität ganz schnell zusammenbrechen könnte, wenn der Gegner eine implizite Annahme verletzt und sich mehrfach Informationen über den Systemzustand verschafft. Ob die Erwägungen alle richtig sind, ist gar nicht so wichtig; wichtig ist, dass man mal darüber nachgdedacht hat.
Ich spende hiermit Applaus.
»Geldautomaten sind sicher«, schreiben die Zeitungen und fassen damit ein Urteil des Oberlandesgerichts Frankfurt vom 30. Januar 2008 zusammen. Geklagt hatte eine Verbraucherzentrale, es ging um Abhebungen mit geklauten Karten. Unter den Tisch fiel manchmal dieser Satz:
»Das Gericht lehnte weitere Beweiserhebungen ab, die die Verbraucherschutzzentrale zur Möglichkeit von anderen Manipulationsmöglichkeiten beantragte, z.B. zur Frage der Verwendung von auf der Karte gespeicherten Daten zur PIN-Verfikation.«
(gesehen z.B. hier.) Spontanreaktion: Aber genau auf solche Manipulationsmöglichkeiten kommt es doch an! OLG Frankfurt, Az. 23 U 38/05 weiterlesen
Burkhard Schröder schreibt in Telepolis über »Ahnungslosigkeit, Versagen und S/Mime«: Seine Versuche, mit Abgeordneten Schlüssel für den E-Mail-Verkehr zu tauschen erweisen sich als weitgehend fruchtlos. Er beklagt:
»Dass ein Abgeordneter des Bundestages keinen technischen Sachverstand besitzt, ist verzeihlich. Dass sie oder er auf auf den Sachverstand verzichtet, der ihm innerhalb des Hauses gratis angeboten wird, ist einfach nur ignorant.«
Das ist eine typische Nerd-Beschwerde. Sie impliziert zweierlei, nämlich dass verschlüsselte E-Mail im richtigen Leben irrsinnig wichtig sei, und dass das jedem spätestens dann klar werden müsse, wenn einer danach fragte. Beides ist falsch, wenn man die Wahrnehmung und Gedankenwelt eines Nichtnerds zugrunde legt.
[Notice for our international readers]
A few days ago the W3C published the first draft of HTML 5. One of the many new features struck me as a possible amplifier for insecure programming: HTML 5 extends the type attribute of the input element to support URLs, e-mail addresses, date, time, and other types. The rationale for the new types reads (emphasis by me):
»The idea of these new types is that the user agent can provide the user interface, such as a calendar date picker or integration with the user’s address book and submit a defined format to the server. It gives the user a better experience as his input is checked before sending it to the server meaning there is less time to wait for feedback.«
Now this is a really old theme in Web (in)security. The Web as a platform for programming invites errors in input validation and sanitation by giving the programmer equally powerful tools for two different domains of trust, the client and the server. Furthermore, client-side input validation does make sense and is desirable under usability considerations but cannot replace server-side enforcement.
Consequently, one all too common mistake in Web application programming is to validate or sanitize data on the client side but not on the server side where one must not rely on any assumptions regarding client behavior. At the first glance abovementioned extensions seem to provoke even more of these mistakes by improving on the client-side features, thus making them more attractive.
The new feature makes generating code easier, though, which means it may become easier to develop and use frameworks instead of hand-coding. This would be good, security-wise, as one framework usually makes fewer errors than hundreds or thousands of programmers.
At this time, both theories seem equally plausible to me. Empirical studies, anyone?
Es gibt übrigens auch Werbung, die mich nicht zu einem Spontantest anstachelt, sondern mir so gut gefällt, dass ich sie mit großem Vergnügen weiterreiche. Sogar zum Thema IT-Sicherheit. Nebenstehend ein Beispiel (Klick zum Vergrößern), das ich heute in meinem Postfach fand, eine Karte im Format A4, die auf http://friendlyadvicemachine.com/ verweist. John Cleese schaue ich mir gerne mal an, auch wenn ich beim Absender Iron Mountain vorerst nichts kaufen möchte. Die Karte ist also gut genug, um meine Aufmerksamkeit zu wecken. Und die Website zur Karte ist gut genug, um mich dabei nicht auf dumme Gedanken kommen zu lassen. Da hat sich jemand richtig Mühe gegeben. Wahrscheinlich haben die Absender auch noch einen Google-Alert auf ihren Namen gesetzt und tauchen schneller hier auf als die Datenleckstopfer von gestern, auf die ich immer noch warte.
Aus meiner SpamInbox:
»Stellen Sie sich vor, Ihre Finanzabteilung versendet versehentlich vertrauliche Business-Pläne an einen externen Emailverteiler, ein verärgerter Mitarbeiter verrät im Online-Chat Firmengeheimnisse oder ein anderer verschickt im Namen Ihres Unternehmens unseriöse Emails an Ihre Kunden.«
Tja, was mache ich denn dann? Die Mail, aus der dieses Zitat stammt, empfiehlt mir, mich rechtzeitig über die Produkte und Dienstleistungen der schreibenden Firma zu informieren. Ich würde ja einfach die Finanzabteilung feuern, wenn sie sich das so redlich verdient; verärgerten Mitarbeitern rechtzeitig genügend Angst machen; und die unseriösen E-Mails selber verschicken, um sie später dementieren zu können und so zweimal billig Aufmerksamkeit zu bekommen. Statt dessen soll ich mich also über MIMEsweeper informieren und darüber, was man im Web 2.0 damit so alles verhindern kann.
Da ich solche Probleme nicht habe und meine Hauptbeschäftigung darin besteht, die Sicherheit von allem möglichen zu testen und zu bewerten, tue ich genau das: testen. Mal schnell getestet: Data L{oss|eak} Prevention von Clearswift weiterlesen
Manche Vertreter mancher Berufe haben manchmal Dateien, die man gar nicht haben möchte. Und wenn man sie doch hat, dann möchte man sehr gut kontrollieren, was mit ihnen passiert. Jene unter unseren Leserinnen und Lesern, die sich darunter nicht sofort etwas vorstellen können, denken bitte an eine Dekompressionsbombe als vergleichsweise harmloses Beispiel. Wer damit nichts anzufangen weiß, braucht gar nicht weiterzulesen.
So eine Dekompressionsbombe in Dateiform möchte man auf gar keinen Fall aus Versehen doppelklicken. Zwar macht sie selten richtig was kaputt, aber sie nervt ganz gewaltig, wenn sie erst mal vor sich hin explodiert. Und es gibt noch andere Dinge, die man nicht versehentlich doppelklicken, andererseits aber auch nicht aus seinem Labor verbannen möchte. An die denken wir auch.
Und gleich noch ein Eintrag zum Thema Datenforensik. Im RISKS Digest vom 7. Januar 2008 (Volume 25, Issue 1) weist Fred Cohen auf die geringe Beweiskraft von HTML-Archiven hin. Konkret geht es um archive.org, auch bekannt als WayBack Machine. Das ist ein Dienst, der ab und zu Schnappschüsse von Seiten im Web nimmt und sie archiviert. Seine Nutzer können so einen Blick zurück in die Vergangenheit des Web werfen. Seiten in diesem Archiv kann Cohen nachweislich manipulieren. Seine Demonstration ist überzeugend: in einer archivierten Seite aus dem Jahr 1997 lässt er eine Grafik erscheinen, die damals noch ungeschehene Ereignisse wie 9/11 und Al Gores Nobelpreis nennt.
Der Trick ist so simpel, dass er gar keiner ist. Archiviert ist nämlich nur der HTML-Quelltext von damals. Enthält er Bildreferenzen, so zeigen diese nach wie vor auf die ursprüngliche Adresse. Jedoch garantiert nichts und niemand, dass dort noch dasselbe Bild liegt oder derselbe Server steht. Beim Anzeigen der archivierten Seite aber wird sich der Webbrowser nicht um solche Erwägungen kümmern, sondern die Referenz einfach verwenden und versuchen, von dort ein Bild zu laden. Hat er Erfolg, so zeigt er es auch an. Falls man statt eines Bildes JavaScript-Code in die archivierte Seite injizieren kann, was unter diesen Voraussetzungen nicht allzu schwer ist, dann hat man sogar den kompletten Inhalt unter Kontrolle.
Die Aussage des Archivs hängt also davon ab, unter welchen Randbedingungen man es auswertet. Einfach hinzuschauen genügt nicht. Man wird statt dessen sehr sorgfältig prüfen müssen, auf welche anderen Daten der archivierte HTML-Code verweist, welchen Einfluss diese Daten auf die Präsentation und damit den sinnlich wahrnehmbaren Seiteninhalt haben, und inwieweit sich aus dem archivierten Material eine aussagekräftige Ansicht rekonstruieren lässt. Im schlimmsten Fall, so ein Beispiel lässt sich konstruieren, genügt eine einzelne ungesicherte Referenz, das ganze archivierte Material für Beweiszwecke wertlos zu machen. Juristen dürfte das, je nach Rolle bzw. Mandat, entweder freuen oder ärgern.
Das Problem ist nicht neu, wir kennen es als das Präsentationsproblem von den digitalen Signaturen. Es betrifft viele moderne Datenformate, deren Interpretation von Randbedingungen abhängt.
Kurz verlinkt:
Christoph Wissing klärt Populäre WLAN-Irrtümer auf. IT-Experten dürften wenig Neues lernen, Laien schon.
Die Masche ist bekannt: irgendwo im Netz stößt man auf eine Website, die einen kostenlosen Sicherheitscheck verspricht. Dazu lädt man sich ein Program herunter und führt es aus. Dieses Programm findet tatsächlich eine Reihe von Sicherheitsproblemen oder behauptet das jedenfalls. Und es hört mit dem Behaupten gar nicht mehr auf, denn das Opfer soll auf jeden Fall die »Vollversion« kaufen, von der es heißt, sie könne die gefundenen Probleme beseitigen.
Seit es diesen Betrug auch für den Mac gibt, hat er sogar einen schönen Namen: Scareware.
Im Englischen kann man ohne sprachliche Verrenkungen zwischen trusted und trustworthy unterscheiden. Trotzdem kriegen es viele nicht richtig hin. Auf Deutsch ist das noch viel schwerer. Trustworthy lässt sich noch entspannt und korrekt mit vertrauenswürdig übersetzen: das bedeutet, dass etwas Vertrauen verdient, dass Vertrauen – ganz gleich, ob man es tatsächlich hat oder nicht – jedenfalls nicht enttäuscht würde. Ob jemand oder etwas vertrauenswürdig war, wissen wir zuverlässig immer erst hinterher, wenn uns das Ergebnis wovon auch immer gezeigt hat, dass unser Vertrauen gerechtfertigt war. Meine Bank zum Beispiel hat sich in der Vergangenheit als vertrauenswürdig erwiesen. Viel spricht dafür, dass sie es auch in Zukunft bleiben wird, aber hundertprozentig weiß ich das jetzt noch nicht.
Für die Zukunft muss ich meiner Bank vertrauen: ich vermute oder hoffe, dass sie sich als vertrauenswürdig erweisen wird, und handle jetzt schon so, als sei sie es. Ich könnte mich statt dessen auch bei einer anderen Instanz absichern, hätte dort aber dasselbe Problem. Meine Bank, oder die andere Instanz, ist damit trusted. Meine Sicherheit hängt davon ab, dass sie sich wie erhofft verhält. Tut sie es nicht, bricht mein Sicherheitskonzept zusammen. Ein anschauliches Beispiel gibt es hier. Der Übersetzer ist trusted, jemand vertraut ihm. Er ist aber nicht trustworthy, denn er enttäuscht dieses Vertrauen.
Für diese Rolle in der Vertrauensbeziehung hätte ich gern ein deutsches Adjektiv. Vertraut passt nicht. Abhängig ist gerichtet und genau umgekehrt: ich bin abhängig von dem, dem ich vertraue. Im Einzelfall kann man sich vielleicht in Umschreibungen retten, aber darunter leidet die Verständlichkeit. Einfach trusted zu benutzen ist auch nicht besonders schön, das Lesen macht dann keinen Spaß mehr. Betraut oder verantwortlich ginge vielleicht, wenngleich mir beides unüblich scheint. Wie lösen unsere geschätzen Leserinnen und Leser dieses Problem?
Wieder was gelernt. In der taz stand am 11. Januar der Artikel Britannien wird bombensicher! von Sam Wild. Sehr in die Tiefe geht er nicht, was die technische Seite betrifft. Dennoch erfuhr ich daraus etwas, das mir vorher nicht so klar war: gegen Bomben muss man nicht unbedingt Bunker mit dicken Betonwänden bauen.
Wie überall, wo es um Sicherheit geht, empfiehlt sich zunächst eine Analyse. Wovon bin ich oder fühle ich mich bedroht, wie wirkt die Bedrohung und welchen Einfluss haben Randbedingungen? Wenn ich die Bedrohung verstanden habe, kann ich nicht nur geeignete Maßnahmen dagegen entwerfen, sondern ich werde dann auch wissen, wie weit deren Schutz reicht oder eben nicht reicht.
»Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable.«
– Helen Keller, deafblind American author, activist, and lecturer. Quote found here.
Woran erkenne ich, wie gründlich jemand nachgedacht hat? Nun, im Netz bietet sich die jeweilige FAQ an, die Liste häufig gestellter Fragen. In der Blütezeit des Usenet und der Mailinglisten, in den 80er und 90er Jahren des letzten Jahrhunderts also, handelte es tatsächlich noch um häufig gestellte Fragen. Heute ist daraus ein Stilmittel für Online-Texte geworden und es handelt sich in aller Regel um antizipierte Fragen. Das ist gut, denn eine so entstandene FAQ gibt uns tiefen Einblick in die Gedankenwelt ihrer Autoren. Man kann sie als Lackmustest für das Problemverständnis und die Komplexität einer Lösung verwenden. Das haben wir bereits früher festgestellt. Interessanter als die Antworten sind dabei die Fragen selbst, vor allem auch die nicht gestellten.
Wahlverfahren sind ein Gebiet, auf dem so ein Lackmustest gut funktioniert. Nötig ist er: leider fühlen sich Ingenieure und Informatiker von aktuellen Themen angespornt, mal schnell ein paar Lösungsansätze zu skizzieren. Die sind dann oft nicht zu Ende gedacht; heraus kommen Kindereien wie das Bingo Voting des E.I.S.S. der Uni Karlsruhe. Als wissenschaftliche Fingerübung ist so etwas gewiss akzeptabel, aber der Öffentlichkeit präsentiert man es bereits als Lösung, für welches Problem auch immer. Sogar eine eigene Domain hat man schon reserviert, als wolle man bald eine Firma gründen und ein Produkt daraus machen. Der Heise-Ticker berichtete, und im Forum dazu stehen bereits allerlei kluge Kommentare. Wie gesagt, Diskussion und Untersuchung sind vollkommen legitim, man muss die Sache nur richtig einordnen.
Wahlcomputer: die FAQ als Lackmustest für Bullshit weiterlesen
Auf dem Wortfeld wachsen Links zu zwei Orten, an denen Airline-Insider ihre Ansichten verbreiten. Natürlich geht es dort auch um die mehr oder minder sinnvollen, auf jeden Fall aber sichtbaren Sicherheitsmaßnahmen auf Flughäfen. Das Thema scheint gerade wieder aktuell zu sein, deshalb eine erweiterte Linksammlung:
Guten Flug!
[Teil 1 – Teil 2 – Teil 3 – Teil 4]
Kluge Menschen wussten es schon vor Jahren, jetzt ist es amtlich: die rechtsverbindliche digitale Signatur ist tot. Heise berichtet:
Jede vierte Kommune will ihre Verwaltungsvorgänge entsprechend anpassen, sodass man zukünftig etwa Personalausweise oder Pässe elektronisch beantragen kann. Um die Hemmschwelle bei den Bürgern zu senken und die Nutzung zu erleichtern, wollen die Kommunen auf den Zwang zur digitalen Signatur verzichten. Ein Teil von ihnen plant weitere Service-Angebote per E-Mail, zum Beispiel das Beantragen von Beglaubigungen oder Führungszeugnissen, Gewerbe- und KfZ-Anmeldungen sowie Vorgänge zur Abfallwirtschaft.
(Hervorhebungen von mir.)
Wenn selbst die Leute vom Amt vernünftig werden und statt aufgeblasener Technikwichserei lieber etwas nehmen, das funktioniert, dann können wir das Thema getrost abhaken.
Mir passt diese Meldung vorzüglich in meinen Vortrag auf dem CAST-Workshop heute. Geplant ist ein Rundumschlag, der noch etwas weiter reicht. Ich halte den Begriff der Identität in der IT-Sicherheit für überschätzt und damit alles, was mit dem Begriff zusammenhängt: Identitätsdiebstahl, Authentisierung und so weiter. »On the Internet, nobody knows you’re a dog«, das wissen wir schon seit 1993. Langsam begreifen wir auch, dass wir das nicht ändern können, sondern damit leben müssen.
Update: Detlef Borchers berichtet auf heise.de über den CAST-Workshop.
»So, let’s see if we can figure out the economic process …
- Find some vulnerability in some widely used product.
- Create a proof-of-concept and publish it to the world (preferably before sharing it with the vendor).
- Use FUD (Fear, Uncertainty, and Doubt) to sell the services of a security consultancy startup.
- Profit!«
»Mittlerweile hat Chinas Ministerpräsident Wen Jiabao, erklärt, man werde „entschlossene Maßnahmen ergreifen, um Hacker-Angriffe auszuschließen“, berichtet dpa. Er nannte gegneüber Angela Merkel die „Bekämpfung von Störungen durch Hacker im Internet“ eine gemeinsame Aufgabe.«
(heise online – Politiker fordern Aufklärung über chinesische Trojaner-Angriffe [Update])
Ist das nun absurd (China soll unsere PCs schützen?) oder bedrohlich (Chinesische Methoden gegen Hackertoolbesitzer!) oder einfach nur ein typisches Politikerstatement ohne Sinn? Und warum hat man den sonst stets auftauchenden Hinweis unterschlagen, dass nichts zu befürchten wer nichts zu verbergen habe?
So einfach sind Sicherheitsanalysen, wenn man das Jahr 1960 schreibt und in der DDR sitzt:
»In den erstrangigen Chiffrierverkehren findet ein Blockverfahren, die sog. Staatschiffre, Anwendung. Die Schlüsselunterlagen werden von der Sowjetunion geliefert. Das Verfahren hat eine absolute Sicherheit.«
(Bericht über die Lage im Chiffrierwesen, 20. Januar 1960; Hervorhebung von mir)
Die Schlüssel kamen aus der Sowjetunion, die mussten sicher sein. Alles andere wäre undenkbar gewesen. Und vor dem großen Bruder im Osten hatte man sowieso keine Geheimnisse zu haben. Wer den Bericht zuende liest, wird allerdings merken, dass den Genossen diese Situation keineswegs angenehm war. Da die Sowjets nichts liefern wollten, was zu mehr Eigenständigkeit beigetragen hätte, erwog man sogar den Kauf von Technik aus dem Westen.
Zu finden ist diese Stilblüte in einer umfangreichen Materialsammlung über das Chiffrierwesen der DDR. Die Navigation ist ein wenig unübersichtlich, aber es gibt ein Inhaltsverzeichnis. Zu finden sind dort allerlei Beschreibungen manueller Verfahren, Dienstvorschriften und Richtlinien, Informationen über Chiffriergeräte und Lehrmaterial. Die heilige Dreifaltigkeit von Vertraulichkeit, Integrität und Verfügbarkeit findet sich dort auch wieder:
»Die Sicherheit des Nachrichtensystems kennzeichnet seine Fähigkeit, in Abhängigkeit von seiner Resistenz gegen Aufklärung und seiner Imitationssicherheit, allen Aufklärungsarten des Gegners standzuhalten und der Desorganisation, der Desinformation sowie dem nichtsanktionierten Zugriff zu Nachrichten innerhalb des Nachrichtensystems entgegenzuwirken.«
Am Ende sind die Jungs aber wohl auch nur bei DES gelandet.
Update: Umgezogen nach scz.bplaced.net.
Sicher ist sicher? 