Dieser Tipp ist nicht neu, aber mein Leidensdruck war nicht so groß, dass ich aktiv danach gesucht hätte. Das Verhalten von Firefox bei formal ungültigen SSL-Zertifikaten lässt sich etwas weniger nervig gestalten:
(gefunden hier, Erklärung da).
Damit spart man sich ein paar unnötige Mausklicks.
Lehrreiches Scheitern:
»A Webmail service that touts itself as hack-proof and offered $10,000 to anyone who could break into the CEO’s e-mail has lost the challenge.
(…)
The hacking team of Aviv Raff, Lance James and Mike Bailey set up the attack by sending an e-mail to the company’s CEO Darren Berkovitz. When he opened the e-mail, the team exploited an XSS flaw to take control of the account.«(Zero Day: StrongWebmail CEO’s mail account hacked via XSS)
Die 10.000 Dollar hätten sie auch gleich bei einem fähigen Security-Tester anlegen können, dann hätten sie für dasselbe Geld wahrscheinlich mehr über ihre Irrtümer gelernt. Allzu weit kommt man mit diesem Betrag zwar nicht, aber die Tester arbeiten wenigstens bis zum Ende des Geldes weiter, statt mit dem ersten gefundenen Problem den Preis abzuräumen. Damit sinkt auf lange Sicht der Preis pro gefunder Verwundbarkeit, während er bei einer Folge von Hackerwettbewerben vielleicht sogar steigen würde.
Erinnert sich noch jemand an die Story von vor sechs Wochen, derzufolge es mit einem manipulierten Nokia 1100 möglich sei, Kurznachrichten an GSM-Teilnehmer abzufangen? Kriminelle würden bis zu 25.000 Euro für ein solches Gerät bieten, weil auf diese Weise mTAN-Sendungen abzufangen seien. Glauben wollte das keiner so recht.
Inzwischen macht die Meldung die Runde, der Firma UltraScan – die das Thema damals in die Nachrichten brachte – sei es gelungen, die Sache (ein einzges Mal) nachzuvollziehen. Von löschbarem ROM in einigen Modellen der Serie aus dem Bochumer Nokia-Werk ist die Rede und von Schlüsseln für eine verschlüsselte Firmware, die in falsche Hände geraten seien. Dann wird es wirr: man könne durch Firmware-Hacking neben der IMEI, die das Gerät identifiziert, auch die IMSI, die Identität der SIM-Karte, manipulieren – wozu man allerdings eine SIM-Karte klonen müsse, was aber trivial sei.
Alles verstanden? Ich auch nicht. Und die Websites von Ultrascan erwecken nicht gerade den Eindruck hoher Kompetenz und Seriosität.
Microsoft hat den .NET Messenger für Nutzer in Kuba, Syrien, Iran, Sudan und Nordkorea gesperrt. Diese Länder unterliegen einem Embargo der Vereinigten Staaten; US-Firmen dürfen mit ihnen keine Geschäfte machen. Manche finden das hirnrissig (das ist es auch, aber es ist Gesetz), während andere die Umsetzung für hirnrissig halten. Microsoft benutzt nämlich einfach die im Profil hinterlegte Landeseinstellung des Nutzers, und die ist frei wählbar.
Diese Implementierung ist aber nicht hirnrissig, sondern vollständig rational und typisch für Compliance-Probleme. Security dreht sich um die Lösung eigener Probleme, die Durchsetzung eigener Interessen mit technischen und organisatorischen Mitteln. Diese Mittel sollen – im Rahmen des jeweils vertretbaren Aufwandes – effektiv sein, also böswillige Angriffe tatsächlich abwehren. Dabei besteht ein direkter Zusammenhang zwischen den erwarteten Schäden durch Angriffe und dem vertretbaren Aufwand.
Compliance hingegen erfordert die Wahrung fremder Interessen, auferlegter Regeln und Anforderungen. Zu eigenen Interessen eines Unternehmens werden sie erst aufgrund angedrohter Zwangsmaßnahmen. Effektivität ist auch hier das Ziel, aber maßgeblich sind nun nicht mehr die direkten Auswirkungen, sondern die angedrohten. Die sind willkürlich festgelegt.
Ein Unternehmen, das Compliance erzielen möchte beziehungsweise muss, wird deshalb jeweils zum einfachsten und billigsten Mittel greifen, das die angedrohten Zwangsmaßnahmen genügend zuverlässig abwehrt. Dieses Mittel muss keinen realen Effekt haben. Es muss lediglich die Kontrolleure zufriedenstellen. Die Lösung von Microsoft für das Compliance-Problem des Messengers leistet dies vermutlich.
Das tatsächliche Problem ist damit vorerst gelöst. Ob Kubaner, Sudanesen oder Nordkoreaner mit dem .NET Messenger chatten, ist dagegen nur ein Scheinproblem. Ohne Compliance-Zwänge wäre es Microsoft einfach egal. Aus geschäftlicher Sicht gäbe es keinen Grund darüber auch nur nachzudenken.
Großes Palaver unter IT-Verantwortlichen. Es geht um die unternehmensweit auf allen Arbeitsplätzen eingesetzte Antivirus-Software. Beim Zugriff auf eine bestimmte interne Web-Anwendung verursacht sie Performance-Probleme. Jemand hat vorgeschlagen, gezielt für diese Situation und nur dafür eine Teilfunktion des Virenscanners zu deaktivieren.
Im Grunde genommen ist man sich einig und hält den Vorschlag für ein Sakrileg. Sicherheitsmechanismen zu deaktivieren komme überhaupt nicht in Frage. Rationale Erwägungen über das Risiko sowie über Sinn, Zweck und Wirkung der Maßnahme spielen keine Rolle. Statt dessen versucht man einander zu übertreffen im Ringen um die schönste Begründung. Der Tenor: wenn man bei der Sicherheit einmal einen Kompromiss mache, gehe sicher bald das Abendland unter.
In diesem Fall war es nicht allzu schwer, den Weg zurück zu einer sachlichen Betrachtung zu weisen. Wovor ein Antivirus-Programm schützt beziehungsweise eben nicht schützt, ist schnell erklärt, und was danach an Szenarien übrig bleibt, gehört in die Kategorie Movie Plot.
Ich hätte aber schon gerne ein Werkzeug, eine Methode, um den Verzicht auf eine Sicherheitsmaßnahme nicht nur im Einzelfall gut zu begründen. So etwas brauchen wir dringend, denn Verantwortliche entscheiden selten unvoreingenommen. Für sie ist eine Maßnahme stets besser als keine Maßnahme. Kommt es wider Erwarten zu einem Vorfall, dann wird er in der befürchteten Interpretation trotz der ergriffenen Maßnahmen geschehen, aber wegen der nicht ergriffenen.
Wie also begründet man sauber, dass man eine verfügbare Sicherheitsmaßnahme nicht ergreift, ohne sich auf phantasievolle Kosten- und Risikoschätzungen zu stützen?
(via)
Foreign Policy net.effect: 10 easy steps to writing the scariest cyberwarfare article ever (via 1 Raindrop)
Auch auf dem Gebiet der IT-Sicherheit bemüht sich Deutschland, seinem Ruf gerecht zu werden. Felix C. Freiling kommentiert in DuD 4/2009 eine Untersuchung über die Inhalte von IT-Sicherheitsvorlesungen:
»Bemerkenswert ist, dass die erste Gruppe, die vorrangig offensiv lehrt, ausschließlich aus deutschen Universitäten besteht.«
Hand hoch, wer jetzt überrascht ist.
A few days ago Oliver presented his 10 essential Web site checks. Except for a few very basic things I didn’t see security on his list, so here are a few essential security checks for your Web site. You will have to scale them to your needs; the Web site of your local juggling club won’t need the same level of security as an Internet business built around a Web application.
Homework assignment: pick one item and expand it into another list of 10.
My colleague Jan is going to present our paper Attacking the BitLocker Boot Process at Trust 2009 (Oxford, 6th – 8th April). The paper is an improved version of the draft we presented at ETISS.
BitLocker is the volume encryption function built into recent versions of MS Windows. It is capable of using a Trusted Platform Module if the PC has one. Our paper describes five attack scenarios that using the TPM does not prevent from succeeding. Some are based on particular features of BitLocker while others rely on the implementation of authenticated booting that is currently used in Trusted Computing.
All five scenarios seem suitable for targeted attacks and require that the attacker can access the target system twice. Executing such attacks is thus roughly as complex as installing a hardware keylogger in the system and returning later to retrieve the sniffed password along with the encrypted data – or just the machine in a condition that permits decrypting the data on disk.
What makes our attacks interesting is the fact that they can be implemented in software. Ideally, Trusted Computing should reliably prevent such attacks from succeeding. However, a TPM does not prevent software from being modified. The TPM only compares measured states with stored reference data. This leaves several holes. For instance one can temporarily modify software and later restore the reference state, or modify boot components before the reference state is determined and stored inside the TPM. While such actions are useless in an opportunisitc attack where the attacker just grabs an unattended machine unprepared, a dedicated attacker might take advantage of them.
Update 2009-12-03: There is a more comprehensive explanation in a later post.
My dear fellow attention whores,
Can we please stop inventing new bullshit terms for each and every variant of a variant of an attack scenario? Sure, at times we need new terms naming new concepts. Spam is an example, phishing is another. I don’t complain about these. What bothers me is our tendency to modify these general terms every time some slight modification of the concept appears: from spam to spit, from phishing to pharming, hishing, sishing, or wishing. Other than the useful terms for generic concepts, these creations make our lives harder, not easier. They are confusing us and others.
Why this rant? I got a call this morning from a journalist. She wanted to know everything about whaling. WTF? It turned out she really wanted to know everything about GhostNet and the security issues and attack strategies involved. But she didn’t say so and she seemed fixated upon whaling, which, I have to admit, sounds sort of cool and interesting. However, it lead to a failure in communication. She failed to get across her actual need for information, confusing me with a meaningless term that she had picked up somewhere. I failed to get across to her that I do know my share of computer security and that I might actually be able to answer some of her questions.
Coining new terms isn’t wrong per se. But names are like money. Producing too many makes them all worthless.
Yours sincerely,
Sven
*) Letter-style rant. 😛
Kürzlich deutete ich in ein paar Nebensätzen die Möglichkeit an, Computerwahlen nicht tatsächlich zu fälschen, sondern eine Fälschung lediglich zu behaupten. Die Intransparenz wesentlicher Abläufe würde dafür sorgen, dass solche Anschuldigungen zwar nicht per se glaubwürdiger, aber schwerer zu widerlegen wären. Nun tut die CIA genau dies für einige der üblichen Verdächtigen, darunter zum Beispiel Venezuela. Kann ja sein, dass die Berichte alle korrekt sind, aber wenn ein Geheimdienst etwas verbreitet, weiß man nie so genau, was die Ziele sind und wieviel vom Gesagten wahr ist.
Stuart King has blogged a list of his top 5 information security annoyances:
By and large I agree with his list, not least because he seems to have annoyed a few of those who are overconfident about risk trivia and business school quadrant diagrams.
I’d like to add to the list two of my own favorite annoyances:
Kryptologie-Nerds mit ausgeprägter Paranoia dürfte die Lösung nicht überzeugen, weil sie grundsätzlich niemandem trauen und jeder hinter ihnen her ist, aber die Idee ist trotzdem gut:
»Die PrivacyBox soll es in erster Linie Journalisten, Bloggern und anderen Publizierenden ermöglichen, eine vorratsdatenfreie (und auch anonyme) Kontaktmöglichkeit für Informanten anzubieten. Sie steht aber auch weiteren Interessierten offen.«
Die PrivacyBox stellt als Grundfunktion gerichtete anonyme Kommunikation über ein Web-Interface zur Verfügung. Der Empfänger ist nur durch ein Pseudonym gekennzeichnet, der Sender liefert seine Nachricht über ein Web-Formular ab. Krypto-Voodoo mit TOR und PGP ist optional möglich, wird aber nicht erzwungen. Das ist Sicherheit für normale Menschen. Wir brauchen mehr davon.
Was der TÜV – eigentlich die TÜV, denn unter dieser Dachmarke macht sich ein etwas unübersichtliches Firmengeflecht breit – so alles zertifiziert, wissen aufmerksame Leserinnen dieses Blogs bereits. Die technische Seite habe ich damals nicht explizit diskutiert. Das nimmt mir jetzt ein anderer ab und schafft es bis in den Heise-Ticker mit dem Hinweis: TÜV-Siegel schützt nicht vor Cross Site Scripting. Damit haben wir schon zwei Dinge beisammen, vor denen ein TÜV-Siegel nicht schützt, ausnutzbare Fehler in der Technik und zweifelhafte Geschäftsmodelle. Geht da noch was?
Klar geht da noch was. Vor bekloppten Konzepten schützen TÜV-Siegel nämlich auch nicht. Bekloppte Konzepte, damit meine ich zum Beispiel die Idee, irgendeiner Wald-und-Wiesen-(bzw. Titten-und-Schwänze-)Website zur Altersverifikation ausgerechnet die PIN vom Online-Banking auszuhändigen. Darf’s vielleicht noch eine TAN-Liste sein? Sofortident nennt sich dieses Verfahren und dahinter steckt dieselbe Firma, die sich bereits die Sofortüberweisung nach ähnlichem Schema ausgedacht hat. Technisch gesehen geht die PIN nicht an die Titten-Website, sondern an Sofortident, aber der Sicherheitsgewinn dadurch ist marginal. Und wer pappt sein Siegel drauf? Einer von den TÜVs natürlich:
Formal ist das sicher alles korrekt, der TÜV hat ja nur den Datenschutz (== die Einhaltung gesetzlicher Anforderungen an die Erhebung und Verarbeitung personenbezogener Daten) geprüft und mehr wird nicht behauptet. Das macht es aber noch lange nicht zu einer guten Idee, Leuten beim Pornogucken die Banking-PIN abzuknöpfen. Selbst wenn die Sofortler ihre Technik im Griff haben und sich an ihre Zusicherungen halten, wogegen es derzeit keinerlei Anhaltspunkte gibt, bleiben zwei Probleme. Erstens vermischt das Verfahren, ähnlich wie Giropay, Kontexte, die man besser getrennt hält. Online-Banking und Altersverifikation haben nichts miteinander zu tun und das Online-Banking ist hinreichend sensibel, um dabei zu bleiben.
Zweitens gewöhnt es den eifrigen Nutzer daran, seine Banking-PIN bei allen möglichen Gelegenheiten zu allen möglichen Zwecken einzusetzen. Das kann auch dann zum Problem werden, wenn aus ganz anderen Gründen ein Schaden eintritt, etwa wenn sich der Sofort*-Nutzer eine Schadsoftware einfängt und daraufhin Geld von seinem Konto verschwindet. Wenn die Bank dann erfährt, was ihr Kunde mit seiner PIN so alles getan hat, dürfte ihr Kulanz schwer fallen. Ein TÜV-Siegel macht dann auch keinen Eindruck.
Der Schaden durch einen Angriff und der Gewinn des Angreifers sind weitgehend unabhängig voneinander. Dass ein Datensatz 57 Cent kostet, sagt deshalb wenig über den Schaden aus, den eine Datenpanne verursacht. Der ist vielleicht viel größer:
»Die durchschnittlichen Kosten einer Datenpanne lagen demnach in Deutschland 2008 bei etwa 112 € pro einzelnem Datensatz. Die Gesamtkosten einer Datenpanne beliefen sich bei den von Ponemon untersuchten Firmen stets im 6-7stelligen Bereich pro Ereignis.«
(Blog zur IT-Sicherheit:
Gibt es eine Rendite der IT-Sicherheit?)
Was heißt das nun? Steht dem Angreifer ein Hebel zur Verfügung, wenn er es vor allem auf den Schaden und nicht auf seinen Nutzen abgesehen hat? Oder dient dieser Hebel vor allem dem Verteidiger, der nur den geringen Gewinn des Angreifers unattraktiv machen muss, um einen viel höheren Schaden zu verhindern?
»If Al Quaeda managed to shut World of Warcraft down, productivity would skyrocket.«
Marcus Ranum explains the differences between crime, terrorism and war and why he thinks the idea of cyberwar is stupid.
(via)
Ein Nachtrag zu meinem Passwort-Post neulich:
Im aktuellen Risks Digest 25:60 findet sich ein Hinweis auf ein Paper mit dem Titel Do Strong Web Passwords Accomplish Anything? das ähnlich argumentiert und außerdem die unterschiedlichen Perspektiven einzelner Nutzer und einer ganzen Organisation betrachtet. Die Autoren weisen am Ende aber auch darauf hin, dass ihr Paper nicht dazu gedacht ist, Verhaltensregeln für Benutzer abzuleiten.
Nach dem Urteil des Bundesverfassungsgerichts zum Einsatz von Wahlcomputern tauchte ein altes Argument wieder auf: Wahlen mit Stift und Papier ließen sich doch auch fälschen. Der Blogger Zettel, der das Urteil für weltfremd hält, formuliert es so (via):
»Kein Bürger kann den Wahlvorgang „zuverlässig nachvollziehen“, wenn mit Bleistift oder Kugelschreiber Formulare markiert werden. Er müßte dann kontrollieren können, daß die Urne bei Öffnung des Wahllokals leer war; er müßte nicht nur der Auszählung mit Argusaugen folgen können, sondern auch bei der telefonischen Übermittlung der Wahlergebnisse zugleich im Wahllokal und in der Zentrale sitzen, in der die Ergebnisse gesammelt werden.«
Außerdem meint er, in einer funktionierenden Demokratie kämen groß angelegte Wahlfälschungen ohnehin nicht vor oder wir verhielten uns zumindest so und vertrauten dem Staat, statt die Wahlen gründlich zu prüfen. Kontrollierbarkeit von Wahlen weiterlesen
Heise zitiert Hartmut Isselhorst, Leiter der BSI-Abteilung „Sicherheit in Anwendungen, kritischen Infrastrukturen und in Netzen“, zur Veröffentlichung des BSI-Lageberichts zur IT-Sicherheit:
»In der IT seien in Analogie zur Straßenverkehrsordnung nicht nur Sicherheitsgurte, sondern auch eine regelmäßige technische Überwachung nötig. Wer dazu selbst nicht in der Lage sei, könne zum Beispiel einen Sohn damit beauftragen.«
(Heise:
BSI-Lagebericht: IT braucht Sicherheitsgurte und TÜV)
Und jetzt überlegen wir alle zusammen, an welcher Stelle die Analogie zusammenbricht. Tipp: es sind zwei Sätze und wenn ich Mutti eine Plakette aufs Nummernschild ihrer roten Rennsemmel klebe, gültet das nicht.
Sicher ist sicher? 