Category Archives: Vulnerability

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

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:


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. Artifacts:


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

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

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

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

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.«

( “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

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

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

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.


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

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

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.


Wenn die Bankkarte weg ist und kurz darauf Geld vom Konto verschwindet, dann treffen Sie Ihre Bank wahrscheinlich bald vor Gericht. Sie werden Ersatz fordern, die Bank wird ihn verweigern. Für solche Situationen sind Gerichte da, aber wer dort Erfolg haben will, braucht die richtige Strategie. Die Bank hat eine Strategie,  sie wird das PIN-Gambit spielen. Das PIN-Gambit geht so: Die Bank behauptet, ihre Systeme seien sicher, das Abheben von Bargeld am Automaten nur mit Kenntnis der zugehörigen PIN möglich und diese PIN nicht aus der Karte zu ermitteln. Folglich weise eine erfolgte Abhebung kurz nach dem Diebstahl darauf hin, dass der Täter die PIN gekannt haben müsse. Da die Vertraulichkeit der PIN durch den Kunden zu gewährleisten sei, müsse dieser seine Sorgfaltspflichten verletzt und die PIN irgendwo aufgeschrieben haben. Klingt bizarr, aber Richter akzeptieren so etwas und nennen es Anscheinsbeweis.

Als Prozessgegner können und müssen Sie den Anschein erschüttern, aber das ist nicht leicht, denn dazu bedarf es konkreter Beweise. Vage Schilderungen denkbarer anderer Abläufe genügen nicht. Das aber ist sehr schwer, auch wenn Sie sich korrekt verhalten und die PIN weder auf der Karte noch sonst irgendwo vermerkt haben. Die Karte ist weg, fällt als Beweis also aus. Die technischen Systeme der Bank sind vielfältig und komplex, eine gründliche Analyse auf Sicherheitsmängel könnte mehrere Sachverständigenjahre verschlingen. Wenn Sie versuchen, den Anscheinsbeweis der Bank zu erschüttern, nehmen Sie das Gambit an. Das können Sie tun, aber dann wird die Sache mühsam. Im weiteren Verlauf wird sich alles um die Frage drehen, auf welche Weise der Täter an die PIN gelangt ist, und die Beweislast liegt bei Ihnen.

Stattdessen könnten Sie direkt zum Gegenangriff übergehen. Dazu rufen Sie Vertreter der Bank in den Zeugenstand und stellen ihnen Fragen:

  • Welche PIN wurde bei den missbräuchlichen Abhebungen verwendet?
  • Erfolgte die PIN-Prüfung anhand des Magnetstreifens oder unter Verwendung des Kartenchips?
  • Woran erkennt die Bank, wenn sie eine Buchung ausführt, dass die richtige PIN eingegeben wurde?
  • Falls die Abhebung am Automaten eines anderen Instituts erfolgte, woher weiß die Bank, dass dort alles mit rechten Dingen zugeht? Woran erkennt die Bank, dass dort eine korrekte PIN-Prüfung erfolgte?
  • Führt die Bank Aufzeichnungen über Fehlversuche bei der PIN-Eingabe? Welche Aufzeichnungen liegen der Bank für den fraglichen Zeitraum vor? Sind davon alle Anwendungen des Chips erfasst, die eine PIN-Prüfung erfordern oder ermöglichen?
  • Welche Anwendungen oder Funktionen des Kartenchips erfordern oder ermöglichen eine PIN-Prüfung? Verwenden diese Anwendungen alle dieselbe PIN? Verwenden sie einen gemeinsamen Fehlversuchszähler?
  • Gibt es technische Möglichkeiten, die PIN oder den Programmcode des Kartenchips zu verändern? (Tipp: Ja, die gibt es.)
  • Gibt es eine technische Möglichkeit, eine nach mehrfacher Fehleingabe der PIN gesperrte Karte zu entsperren?
  • Wird eine Karte nach Ablauf der Geltungdauer ausgetauscht, stellt die Bank dann eine neue Karte mit derselben PIN aus? Wie ist das technisch realisiert? Wo werden die erforderlichen Informationen aufbewahrt?
  • Um den Prozess zu gewinnen, genügen diese Fragen vielleicht nicht. Eine gute Grundlage für das Gutachten eines Sachverständigen liefern sie allemal, und vor allem ändern sie den Blick auf das Problem.

    * * *

    Wenn Sie eine Rechsberatung benötigen, konsultieren Sie bitte einen Rechtsanwalt Ihrer Wahl.