Mitternachtshacking

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:

• „Vulnerability trading markets and you“ by Michal Zalewski (lcamtuf):
  http://lcamtuf.blogspot.com/2010/04/vulnerability-trading-markets-and-you.html
• „Vulnerability Disclosure is Rude“ by Robert Graham:
  http://erratasec.blogspot.com/2010/04/vuln-disclosure-is-rude.html
• No More Free Bugs movement by Charlie Miller, Alex Sotirov and Dino Dai Zovi:
  http://trailofbits.com/2009/03/22/no-more-free-bugs/
• Dailydave Post by Dave Aitel:
  http://lists.immunitysec.com/pipermail/dailydave/2010-April/006100.html

Ich bin gespannt, wie sich das weiterentwickelt.