Archiv der Kategorie: Vulnerability

Scheinriese Cross-Site-Scripting

Bedrohung, Risiko, Security, Vulnerability, , ,

Wer sich mit IT-Sicherheit beschäftigt, kennt Cross-Site-Scripting (XSS) und hält es wahrscheinlich für eine Klasse schwerwiegender Verwundbarkeiten. Das ist plausibel, aber vielleicht dennoch übertrieben.

Eine Webanwendung ist anfällig für Cross-Site-Scripting, wenn Angreifer ihr HTML- und JavaScript-Code unterjubeln können, welchen der Browser eines Nutzers nicht vom echten Code der Anwendung unterscheiden kann. Damit gewinnen Angreifer die Möglichkeit, im Sicherheitskontext fremder Benutzersitzungen zu agieren. So könnte ein Angreifer beispielsweise im Namen einen angemeldeten Benutzers Daten abrufen und ändern, aber auch im Kontext der Webanwendung mit dem Benutzer interagieren – ein Man-in-the-Middle-Angriff zwischen Benutzer und Anwendung.

Große Aufmerksamkeit wird dem Cross-Site-Scripting aus mehreren Gründen zuteil:

  1. Cross-Site-Scripting-Verwundbarkeiten kommen häufig vor. Wer interaktive Webanwendungen entwickelt und nicht von Anfang an stringente Maßnahmen dagegen ergreift, wird früher oder später unweigerlich XSS-Verwundbarkeiten in seine Anwendung haben.
  2. Cross-Site-Scripting ist leicht zu erklären und zu verstehen. Die einfachsten Varianten lassen sich mit rudimentären HTML- und JavaScript-Kenntnissen unter Verwendung eines gewöhnlichen Webbrowsers demonstrieren – die ideale Fallstudie für jede Sicherheitsschulung.
  3. Cross-Site-Scripting unterläuft mehrere Sicherheitmechanismen – zum Beispiel die Same-Origin-Policy und jede Benutzerauthentisierung – und gewährt dem erfolgreichen Angreifer volle Kontrolle über jede betroffene Benutzersitzung. Verwundbarkeiten sind daher für vielfältige Ziele ausnutzbar und die Auswirkungen lassen sich kaum wegdiskutieren.

Cross-Site-Scripting taucht deshalb zu Recht von Anfang an als eigene Kategorie in den OWASP-Top-10 („The Ten Most Critical Web Application Security Risks“) auf, obwohl es sich rein technisch eigentlich um eine Spezialfall der allgemeineren Kategorie „Injection“ handelt.

✽✽✽

In einem Artikel vom 25. Oktober berichtet Golem.de, man habe in mehreren Online-Shops – allesamt Träger des „Safer Shopping“-Siegels eines bekannten Plakettenkonzerns – Cross-Site-Scripting-Verwundbarkeiten gefunden. Nahezu dieselbe Geschichte war in anderer Besetzung, aber mit demselben Protagonisten bereits neun Jahre zuvor erschienen. Das nimmt nicht Wunder, denn die technische Sicherheit der Shopsoftware gehört gar nicht zum Prüfumfang des Safer-Shopping-Siegels.

Was dies über kommerzielle Gütesiegel aussagt, deren Verfechter sich gerade zu einem neuen Anlauf formieren, sei dahingestellt. Interessanter finde ich die darin verborgene Beobachtung, dass sich offenbar eine Dekade lang niemand ernsthaft an immer wieder auftretenden Cross-Site-Scripting-Verwundbarkeiten in deutschen Online-Shops stört.

Wo Verwundbarkeiten spürbare Auswirkungen haben, also tatsächlich ausgenutzt werden, tut man für gewöhnlich etwas dagegen oder macht öffentlich Radau, falls die Verantwortlichen andere sind als die Opfer. Wo man nichts sieht und hört, gibt es hingegen augenscheinlich kein wirkliches Problem. Gewiss, dies ist nur eine Heuristik, doch sie hat eine ökonomische Grundlage: Je höher die Schäden, desto größer der mögliche Nutzen von Sicherheitsmaßnahmen; je geringer die Schäden, desto weniger lohnt sich Sicherheit.

Dass eine „klaffende Sicherheitslücke“ (WichtigtuerExpertenjargon) dennoch nicht ausgenutzt wird, kommt häufiger vor als gedacht, denn für den Angreifer muss sich der gesamte Angriff lohnen und nicht nur im Prinzip möglich sein. Die Verfügbarkeit ausnutzbarer Verwundbarkeiten ist dabei nur ein Faktor unter mehreren. Auf den zweiten Blick zeigen sich einige Einschränkungen, die prinzipiell mögliche Cross-Site-Scripting-Angriffe auf die Nutzer von Online-Shops unattraktiv machen können.

Als Angriffsziele in einem Online-Shop kommen für ökonomisch motivierte Angreifer insbesondere das Auslösen von Transaktionen und damit Lieferungen sowie der Zugriff auf einsetzbare Zahlungsdaten (z.B. vollständige Kreditkartendatensätze) oder Kundenpasswörter in Frage. Gegen lukrative Angriffe auf der Grundlage von Cross-Site-Scripting sprechen:

  1. Der begrenzte Wirkungsbereich von Cross-Site-Scripting-Angriffen:
    Die Auswirkungen bleiben auf eine Anzahl von Benutzersitzungen und Benutzern beschränkt. Eine Rechteausweitung über die Möglichkeiten eines angemeldeten Benutzers hinaus – etwa zum uneingeschränkten Zugriff auf gespeicherte Kundendaten und Zahlungsmittel – ist von dort aus normalerweise nicht möglich.
  2. Die Gefahr, aufzufallen:
    Betrügerische Bestellungen bleiben nur dann nachhaltig möglich, wenn sie im Rauschen des normalen Shopbetriebes nicht auffallen. Bestellen jedoch auf einmal binnen kurzer Zeit Hunderte Nutzer das teuerste Produkt, wird sich darüber wahrscheinlich jemand wundern. Hinzu kommen Logfiles, in denen Cross-Site-Scripting-Angriffe wahrscheinlich Spuren hinterlassen. Anfangs weniger auffällig wäre der Zugriff auf Zahlungsdaten, deren späterer Missbrauch jedoch bald auffällt und zur Sperrung aller potenziell betroffenen Zahlungsmittel führen kann.
  3. Logistikanforderungen an den Angreifer:
    Wer sich auf fremde Rechnung Waren liefern lassen möchte, steht vor einem Problem: Er muss Lieferungen annehmen können, ohne sich erwischen zu lassen. Das wird mit jeder Wiederholung schwerer. Wer Zahlungsmittel missbraucht, steht später vor demselben Problem. Direkt das eigene Konto aufzufüllen, ist weniger schlau.
  4. Abhängigkeit von der Kooperation der Betroffenen:
    Wer Cross-Site-Scripting-Verwundbarkeiten ausnutzt, ist auf die Kooperation seiner Opfer angewiesen. Jeder betroffene Nutzer muss wenigstens einmal auf einen vom Angreifer präparierten Link geklickt oder bestimmte Funktionen des Shops besucht haben und möglicherweise in derselben Sitzung auch noch bestimmte Handlungen (z.B. Login oder Bestellvorgang mit Eingabe von Zahlungsdaten) vorgenommen haben, damit der Angriff Erfolg hat. Wer sich aktiv um diese Kooperation bemüht, fällt leichter auf. Hinzu kommt unter Umständen die Schwierigkeit, Nischenzielgruppen wie die aktiven Nutzer eines bestimmen deutschen Online-Shops überhaupt anzusprechen.

Eine Reihe denkbarer Angriffserfolge wird damit unwahrscheinlich, das unbemerkte, massenhafte Auslesen von Zahlungsdaten oder Benutzerkennungen nebst Passwörtern ebenso wie betrügerische Warenbestellungen im großen Maßstab.

Weit verbreitete und vielfältig ausnutzbare Verwundbarkeiten zu vermeiden, ist sicher dennoch eine gute Idee, schon weil sich das Gefüge der Risikofaktoren schwer überblicken lässt. Dass sich offensichtliche Nachlässigkeiten nicht in spektakulären Angriffen niederschlagen, halte ich jedoch für plausibel. Insofern liegen der Plakettenkonzern und seine Kunden möglicherweise richtig, wenn sie dem Thema Cross-Site-Scripting wenig Aufmerkamkeit widmen.

Application Layer Snake Oil

Bedrohung, English, Property Degrees, Securitoy, Security, Unterwegs, Vulnerability, , , , , , , , ,

TL;DR: The author thinks Snowden’s home security app, Haven, is snake oil regardless of the algorithms it uses. Operational security is at least as hard as cryptography and no app is going to provide it for you.

Bogus cryptography is often being referred to as snake oil—a remedy designed by charlatans to the sole end of selling it to the gullible. Discussions of snake oil traditionally focused on cryptography as such and technical aspects like the choice of algorithms, the competence of their designers and implementers, or the degree of scrutiny a design and its implementation received. As a rule of thumb, a set of algorithms and protocols is widely accepted as probably secure according to current public knowledge, and any poorly motivated deviation from this mainstream raises eyebrows.

However, reasonable choices of encryption algorithms and crypto protocols alone does not guarantee security. The overall application in which they serve as building blocks needs to make sense as well in the light of the threat models this application purports to address. Snake oil is easy to mask at this level. While most low-level snake oil can be spotted by a few simple patterns, the application layer calls for a discussion of security requirements.

Enter Haven, the personal security app released by Freedom of the Press Foundation and Guardian Project and associated in public relations with Edward Snowden. Haven turns a smartphone into a remote sensor that alerts its user over confidential channels about activity in its surroundings. The intended use case is apparently to put the app on a cheap phone and leave this phone wherever one feels surveillance is need; the user’s primary phone will then receive alerts and recordings of sensed activity.

Haven is being touted as “a way to protect their [its users] personal spaces and possessions without compromising their own privacy.” The app allegedly protects its users against “the secret police making people disappear” and against evil maid attacks targeting their devices in their absence. To this end, Haven surveils its surroundings through the smartphone’s sensors for noise, movement, etc. When it detects any activity, the app records information such as photos through the built-in camera and transmits this information confidentially over channels like the Signal messenger and Tor.

Alas, these functions together create a mere securitoy that remains rather ineffective in real applications. The threat model is about the most challenging one can think of short of an alien invasion. A secret police that can make people disappear and get away with it is close to almighty. They will not go through court proceedings to decide who to attack and they will surely not be afraid of journalists reporting on them. Where a secret police makes people disappear there will be no public forum for anyone to report on their atrocities. Just imagine using Haven in North Korea—what would you hope to do, inside the country, after obtaining photos of their secret police?

Besides strongly discouraging your dissemination of any recordings, a secret police can also evade detection through Haven. They might, for example, jam wireless signals before entering your home or hotel room so that your phone has no chance of transmitting messages to you until they have dealt with it. Or they might simply construct a plausible pretense, such as a fire alarm going off and agents-dressed-as-firefighters checking the place. Even if they fail to convince you, you will not be able to react in any meaningful way to the alerts you receive. Even if you were close enough to do anything at all, you would not physically attack agents of a secret police that makes people disappear, would you?

What Haven is trying to sell is the illusion of control where the power differential is clearly in favor of the opponent. Haven sells this illusion to well pampered westerners and exploits their lack of experience with repression. To fall for Haven you have to believe the  premise that repression means a secret police in an otherwise unchanged setting. This premise is false: A secret police making people disappear exists inevitably in a context that limits your access to institutions like courts or media or the amount of support you can expect from them. Secret communication as supported by Haven does not even try to address this problem.

While almost everyone understands the problems with low-level snake oil and how to detect and avoid it, securitoys and application layer snake oil continue to fool (some) journalists and activists. Here are a few warning signs:

  1. Security is the only or primary function of a new product or service. Nothing interesting remains if you remove it.
  2. The product or service is being advertised as a tool to evade repression by states.
  3. The threat model and the security goals are not clearly defined and there is no sound argument relating the threat model, security goals, and security design.
  4. Confidentiality or privacy are being over-emphasized and encryption is the core security function. Advertising includes references to “secure” services like Tor or Signal.
  5. The product or service purports to solve problems of operational security with technology.

When somebody shows you a security tool or approach, take the time to ponder how contact with the enemy would end.

An In-Depth Study of More Than Ten Years of Java Exploitation

English, Forschung, Security, Vulnerability,

My colleagues Philipp Holzinger, Stefan Triller, Alexandre Bartel, and Eric Bodden had a closer look at Java and the vulnerabilities discovered in the Java runtime environment during the last decade. They started from known exploits, identified the vulnerabilities exploited, and analyzed and grouped their root causes. Philipp’s presentation of the results at CCS’16 has been recorded and published on YouTube:

(YouTube)

The paper is also available online:

P. Holzinger, S. Triller, A. Bartel, E. Bodden: An In-Depth Study of More Than Ten Years of Java Exploitation. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS’16), Vienna, Austria, Oct. 24-28, 2016. DOI: 10.1145/2976749.2978361.

 

The Key-Under-the-Doormat Analogy Has a Flaw

Classifier Security Model, English, Security, Vulnerability, , , ,

The crypto wars are back, and with them the analogy of putting keys under the doormat:

… you can’t build a backdoor into our digital devices that only good guys can use. Just like you can’t put a key under a doormat that only the FBI will ever find.

(Rainey Reitman: An Open Letter to President Obama: This is About Math, Not Politics)

This is only truthy. The problem of distinguishing desirable from undesirable interactions to permit the former and deny the latter lies indeed at the heart of any security problem. I have been arguing for years that security is a classification problem; any key management challenge reminds us of it. I have no doubt that designing a crypto backdoor only law enforcement can use only for legitimate purposes, or any sufficiently close approximation, is a problem we remain far from solving for the foreseeable future.

However, the key-under-the-doormat analogy misrepresents the consequences of not putting keys under the doormat, or at least does not properly explain them. Other than (idealized) crypto, our houses and apartments are not particularly secure to begin with. Even without finding a key under the doormat, SWAT teams and burglars alike can enter with moderate effort. This allows legitimate law enforecement to take place at the cost of a burglary (etc.) risk.

Cryptography can be different. Although real-world implementations often have just as many weaknesses as the physical security of our homes, cryptography can create situations where only a backdoor would allow access to plaintext. If all we have is a properly encrypted blob, there is little hope of finding out anything about its plaintext. This does not imply we must have provisions to avoid that situation no matter what the downsides are, but it does contain a valid problem statement: How should we regulate technology that has the potential to reliably deny law enforcement access to certain data?

The answer will probably remain the same, but acknowledging the problem makes it more powerful. The idea that crypto could not be negotiated about is fundamentalist and therefore wrong. Crypto must be negotiated about and all objective evidence speaks in favor of strong crypto.

The misleading microscopic view

English, Property Degrees, Security, Vulnerability, Wahrnehmung

The Guardian lists 10 gross ingredients you didn’t know were in your food, ingredients like arsenic, hair, or silicone breast implant filler. Should we react with nausea and disgust? Of course not. Yummy food is yummy food, neither a just detectable trace of someting (arsenic) nor the source of an ingredient (hair) nor possible other uses of the same ingredient (breast implants) have any noticeble impact. That’s by definition: if a dose of anything has a proven adverse health impact, it will be banned from being used in food. The Guardian’s list is an example of microscopic properties that don’t matter macroscopically. Yummy food is yummy food.

We commit the same error when, in security, we look just at the software defects and neglect their security impact. All software has defects; we might easily assemble a list of 10, or 100, or 1000 defects you didn’t know were in your programs. This does not mean they’d all matter and need to be removed. A system is secure if it evokes a predictable and controlled incident profile over its lifetime. some software defects in some systems affect this incident profile in such a way that their removal matters. Others are just traces of poison, or issues appearing problematic by analogy. The problem is: we often don’t know which is which.

Something to ponder

English, Geschäft, Security, security-industrial complex, Vulnerability, ,

Which of the following statements do you agree or disagree with, and why?

  1. If you get robbed, it’s your fault. You should have carried a gun and used it to defend yourself.
  2. If your home gets burgled, it’s your fault. Your should have secured your home properly.
  3. If you get raped, it’s your fault. Your shouldn’t have worn those sexy clothes, and hey, what were you doing in that park at night?
  4. If your computer gets hacked, it’s your fault. You should have patched the computer every day and used a better password.
  5. If you get run over by a car and injured in the accident, it’s your fault. You should have worn a helmet and a high-viz jacket.
  6. If someone bullies you on the Internet, it’s your fault. You should have used a pseudonym on Facebook.

Do you agree with all, some, or none of these statements? Please elaborate in the comments. I’m not so much interested in nitpicking about the causation of certain incidents – read »your fault« as »in part your fault« if you like so. What interests me rather is the consistency or incocnsistency in our assessment of these matters. If you happen to agree with some of the statements but disagree with others, why is that?

P.S. (2014-09-05): Samuel Liles and Eugene Spafford discuss this matter more thoroughly: What is wrong with all of you? Reflections on nude pictures, victim shaming, and cyber security

Cyber-Krieg, nüchtern betrachtet

Begriffe, Forschung, IT, Security, Vulnerability, Wahrnehmung, ,

Die Süddeutsche hat James A. Lewis (vermutlich den hier) zum Thema Cyberwar interviewt. Herausgekommen ist eine Reihe vernünftiger Ansichten wie diese:

»Ein Staat würde für den Einsatz von Cyberwaffen die gleiche Art militärischer Entscheidungen vornehmen wie für jede andere Art von Waffen. Welchen Vorteil bringt es, die Stromversorgung zu kappen? Und was sind die Risiken dabei? Wenn die USA und China im südchinesischen Meer kämpfen, ist das ein begrenzter Konflikt. Wenn China zivile Ziele auf dem Gebiet der USA attackiert, ist das eine ungeheure Eskalation, die das Risiko birgt, dass die USA auf chinesischem Boden zurückschlagen. Streitkräfte werden gründlich darüber nachdenken, bevor sie einen solchen Angriff wagen. Dazu kommt, dass solche Attacken schwierig sind, und wir dazu neigen, den Schaden zu überschätzen, den sie anrichten. Ich kann mir nicht vorstellen, warum jemand sich die Mühe machen sollte, die Wasserversorgung anzugreifen.«

(sueddeutsche.de: „Wir müssen unsere Verteidigung stärken“)

Lewis betrachtet das Thema nicht im Hollywood- oder Scriptkiddie-Modus, sondern konsequent aus einer militärischen Perspektive. Militärs handeln rational, sie verfolgen taktische und strategische Ziele mit verfügbaren Mitteln und gegen die Handlungen eines Gegeners. Daraus ergibt sich auch das Angreifermodell, das der Verteidigung zugrunde liegt, wie oben im Zitat illustriert. Cyber-Krieg, so Lewis‘ Paradigma, ist keine neue Form des Krieges, die andere verdrängt, sondern eine neue Waffengattung, die den Krieg nicht grundlegend reformiert.

The Point of Penetration Testing

English, Geschäft, IT, Security, Testlabor, Vulnerability, , , , ,

I’m glad to see that the community starts to acknowledge what penetration testing really means. We never encountered the empty hands issue as we never sold the let’s-see-if-we-can-hack-it kind of a penetration test. We carry out vulnerability assessments based on whichever information we can get about a system or product, the more the better, and use testing as a means of getting more, or clarifying information. The point of a penetration test is not to find and demonstrate one or a handful of arbitrary attacks, the point of a penetraion test is to identify vulnerabilities that need attention. Sure, it is fun to give an uberhacker demo after the test, and we do that, too, if we’ve found gaping security holes. But more important in a penetration test is good coverage of the potential vulnerabilities, and a sound assessment of their importance, relative to the purpose and risk profile of a system. I even remember pentesting projects where we found only a few relatively minor issues in a low-risk website – and made our clients happy by telling them just that. There is really no need to be disappointed if a penetration test ends without a root shell. There is no point in withholding information from testers, reducing their efficiency. And there is no point in testing just the infrastructure but not the applications.

Safe and sorry

English, Security, Unterwegs, Vulnerability, , , ,

A common delusion in security engineering is the idea that one could secure a system by identifying items that need protection (assets), describing the ways in which they might be damaged (threats or attacks, which are not synonymous but often confused), and then implementing countermeasures or mitigations such that all, or the most common, or the most damaging threats are covered. The system thus becomes secure with respect to the threat model, so the reasoning. This is the model underlying the Common Criteria, and it works fine as a descriptive model. To give an example from everyday life, consider a bicycle as an asset. If your bicycle gets stolen (the threat), your damage is the value of the bicycle plus any collateral damage that the loss may cause you, such as coming late to an appointment, having to pay for a taxi or public transport instead of riding your bicycle, and having to go to the gym for workout instead of getting a workout for free on your way to work. The typical countermeasure against this threat is locking the bicycle to a fence, pole, or other appropriate object. Locking your bicycle reduces the risk of it being stolen. What could possibly go wrong? Besides the obvious residual risk of your countermeasures not being strong enough, this could go wrong:

A bicycle frame locked to a fence, wheels and other parts stolen
Safe and sorry © 2012 Sven Türpe, CC-BY 3.0

 

This (ex-)bicycle was and remains properly locked and no vulnerability in the lock or in items the lock depends on have been exploited. Yet, somebody made a fortune stealing bicycle parts, and somebody else lost a bicycle to an attack. What’s the problem? The problem is the gross simplification in the asset-threat-countermeasure model, which neglects three important factors:

  1. Adaptive adversaries. A countermeasure does not oblige the adversary to stick to the original attack plan that the countermeasure is targeted at. Security measures change the threat model. They don’t force the adversary to give up, they force the adversary to change strategy and tactics.
  2. The victim’s loss and the adversary’s gain are not necessarily the same. In the case of the bicycle above, the lock may reduce the attacker’s gain to the black market value of the removed parts. The victim’s loss is still one bicycle.
  3. Asset dependencies. Thinking of a bicycle as one asset is an abstraction. A bicycle is really a collection of assets—its parts—and an asset by itself. Such dependencies, nested assets in this case, are common.

The bicycle lock, it turns out, is not really a bicycle lock, it’s a bicycle frame lock. It protects only one sub-asset of the bicycle, and an economically motivated adversary can make a gain that seems worth the risk without breaking the lock.

Prescriptive threat modeling—threat modeling done with the aim of finding a proper set of security features for a system—needs to take these issues into account. A good threat model anticipates changes in attacker behavior due to security measures. A good threat model considers not only damages to the victim but also gains of the adversary, as the latter are what motivates the adversary. And good security engineering is biased towards security, always overestimating adversary capabilities and always underestimating the effect of security measures, systematically.

Identitätsmanagement für Dummies

Freundlich zum Nutzer, Geschäft, ID, Vulnerability,

Vergesst CardSpace, vergesst OpenID, vergesst den elektronischen Personalausweis. Den Identitäts- und Passwortmanager, auf den wir gewartet haben, gibt es in der Buchhandlung. Er läuft ohne Installation, out of the box, ja sogar ohne Strom, und hört auf den Namen Mein persönlicher Internet- und Passwort-Organizer:

Zuverlässig speichert er alle Benutzeraccounts alphabetisch sortiert für den schnellen Zugriff.

Bankdaten einschließlich des Passworts fürs Online-Banking können in einem eigenen Bereich abgelegt werden.

Eine Bedienungsanleitung erübrigt sich, dennoch ist eine Online-Hilfe mit Sicherheitshinweisen integriert.

Der Preis? Sagenhafte 7,99€. Ich habe mein Exemplar bei Hugendubel entdeckt und gekauft, bei Amazon gibt es ihn auch.

Respekt

Hackmeck, ID, Rechtsabteilung, So geht das, Vulnerability

Das fast perfekte Verbrechen. Dem Finanzamt falsche Gehaltsabrechnungen untergejubelt, später mit falschen Steuererklärungen Erstattungen kassiert und Ermittlungsverfahren gegen sich kurzerhand beendet:

»… auch eröffnete hin und wieder eine Staatsanwaltschaft ein Ermittlungsverfahren. Geschah dies, tarnte der Angeklagte sich kurzerhand als Rechtsanwalt, wies sich bei der Staatsanwaltschaft mit ebenfalls gefälschten Papieren aus, bekam seine Akten zugeschickt und vernichtete die dann genüsslich.«

(Echo Online: Einkommensteuererklärungen für erfundene Menschen)

Am Ende haben sie ihn doch gekriegt. Aber den Trick mit den Akten muss ich mir merken.

P.S.: Zwei Jahre und neun Monate gab’s dafür.

Trust Center

Begriffe, IT, Security, Vertrauen, Vulnerability, , , , ,

Nach dem Vorfall bei Diginotar − Unbekannte haben sich mehrere von Diginotar ausgestellte SSL-Zertifikate verschafft, und eines davon blieb längere Zeit unbemerkt gültig − schimpfen viele über das Geschäft der Zertifikatsaussteller und deren vorinstallierte CA-Zertifikate in Webbrowsern. Es ist einfach, Dinge für kaputt zu erklären, aber damit verbessert man nicht unbedingt die Welt. CAs heißen auch Trust Center. Das ist die bessere Bezeichnung, denn mit einem realistischen Vertrauensbegriff ergibt alles einen Sinn.

Vertrauen ist ein Vorurteil zur Reduktion sozialer Komplexität, eine Erwartung an das Verhalten anderer, die erfüllt oder auch entäuscht werden kann. Ob online oder im Alltag, ich könnte vor jeder Interaktion mit anderen gründlich prüfen, mit wem ich es zu tun habe, und  Vorsichtsmaßnahmen gegen das Scheitern ergreifen. Das wäre aber aufwändig, vor allem Im Verhältnis zur Größe und Häufigkeit von Alltagsgeschäften wie dem Kauf eines belegten Brötchens oder dem Aufbau einer SSL-Verbindung. Also lasse ich die Vorsichtsmaßnahmen weg und ersetze sie durch Vertrauen.

Unbekannte ohne Interaktionshistorie bekommen ein Basisniveau an Vertrauen zugeordnet, das begrenzt ist: einem Fremden im Park werde ich gerne drei Jonglierbälle im Wert von ca. 20 Euro borgen, nicht aber mein Fahrrad. Wiederholte erfolgreiche Interaktion lässt das Vertrauen wachsen. Wer ein paarmal im Park mit mir jongliert und meine Bälle nicht an Hunde verfüttert hat, bekommt unter Umständen höhere Werte anvertraut. Ich verborge auch mein Fahrrad, nur nicht an jeden. Enttäuschtes Vertrauen wird unmittelbar zerstört, wenn die Enttäuschung bemerkt wird. Es kann danach dauerhaft zerstört bleiben oder erneut aufgebaut werden, möglicherweise von einem niedrigeren Startniveau als bei Unbekannten.

Vertrauen lässt sich böswillig ausnutzen. Dazu muss sich der Angreifer lediglich anders verhalten als sein Opfer es erwartet und dabei im Verfügungsrahmen des ihm entgegengebrachten Vertrauens bleiben. Ein unseriöser Spendensammler auf der Straße nutzt das Basisvertrauen gegenüber Unbekannten, während ein Anlagebetrüger oft bewusst Vertrauenspflege betreibt, um größere Summen anvertraut zu bekommen. Solche Vertrauensbrüche sind verboten und werden verfolgt. Unsere Gesellschaft hält Vertrauen für so nützlich, dass sie seine böswillige Ausnutzung bestraft. Auf diese Weise erleichtert sie uns das Vertrauen ineinander und damit die soziale und ökonomische Interaktion.

Analoge Vorgänge beobachten wir im Zusammenhang mit Diginotar und anderen SSL-CAs. Den vorinstallierten CAs zu vertrauen, erleichtert unseren Alltag. Unser Vertrauen bleibt begrenzt, Bankgeschäfte zum Beispiel mit ihrem vergleichsweise hohen Verlustpotenzial stützen sich nicht alleine auf SSL, sondern verwenden weitere Mechanismen. Das Vertrauen in Diginotar ist aufgrund des Vorfalls nun zerstört. Vasco als Mutterfirma hat die Wahl, die Investition abzuschreiben oder neues Vertrauen aufzubauen, vorzugsweise unter neuem Namen, um scheinbar unbelastet beim Basisniveau anfangen zu können.

Das einzige gefährliche Trugbild, das ich hier sehe, ist die falsche Perfektionserwartung, die aus vermeintlichen Sicherheitsversprechen folgt. Browser mit vorinstallierten CA-Zertifikaten geben kein Sicherheitsversprechen, sondern sie ermöglichen Vertrauen, nicht mehr und nicht weniger. Wer an der Verwendung von CA-Zertifikaten wirklich etwas verbessern möchte, der sollte daran arbeiten, Vertrauensbrüche schnell und verlässlich erkennbar zu machen. Das halte ich für das eigentliche Problem: ich bekomme nur zufällig und unsystematisch mit, wie sich eine CA verhält.

(Das war zuerst ein Kommentar auf Google+, passt aber besser hier ins Blog.)

IT-Sicherheit im Jahr 2011

Freundlich zum Nutzer, IT, Security, Vulnerability,

So funktioniert IT-Sicherheit im Jahr 2011:

»Laut der Verfügung, die heise online vorliegt, dürfen die Kartenlesegeräte für die elektronische Gesundheitskarte eGK nur in einer kontrollierten Einsatzumgebung aufgestellt werden, in der sie nicht länger als 30 Minuten unbeaufsichtigt sind. (…) Kann ein „kontrollierter 30 Minuten-Bereich“ nicht garantiert werden, müssen die Terminals alle 30 Minuten auf Unversehrtheit kontrolliert werden.«

(Heise online: BSI verärgert Ärzte)

Unsere Systeme sind sicher, solange jemand daneben steht und sie bewacht. Und dieser Jemand soll der Benutzer sein, dem wir die Technik aufdrängen.