Individualität von Sicherheit
Marc Ruef | 31.12.2006

iDieser Beitrag stellt ein Transkript von Computec Radio, Folge 2: Individualität von Sicherheit (http://www.computec.ch/download.php?view.851) dar. Die Audiofassung steht zum freien Download zur Verfügung./i

Ein individueller Angreifer bringt von sich aus eine ebenso individuelle Qualität mit. Darunter wird sein technisches Wissen sowie der innovative Umgang mit diesem, zur Erreichung eines Vorteils, verstanden. Je besser sich ein Angreifer mit einem Thema auskennt, desto effizienter und effektiver kann er sich in diesem Bewegen. Für einen Spezialisten in Bezug auf Webapplikationen ist es sodann viel einfacher, sich mit den typischen Fehlern aus diesem Bereich auseinanderzusetzen, weder wenn dies ein Viren-Programmierer oder Kryptologe tun müsste. Innert weniger Minuten könnte er, wenigstens in seinen Grundzügen, eine Webanwendung auf klassische Probleme wie Cross Site Scripting und SQL-Injection untersucht haben.

Dieser hohe Wissensstand gründet sich nicht nur alleine in der Quasi-Erinnerung an bekannte Schwachstellen. Der Angreifer, ist er denn von professioneller Klasse, wendet damit eben nicht nur altbewährtes an. Nein, er ist unter Umständen in der Lage individuell zu reagieren und sich auf neue Schwächen oder Nuancen altbekannter Schwachstellen einzustellen. Diese Innovativität im Vorgehen führt dazu, dass in Bezug auf die Gegenmassnahmen ebenso eine solche eingesetzt werden muss. Dies wurde in der letzten Folge schon erwähnt. Da der Angreifer klassische Angriffe und klassische Gegenmassnahmen als solche verstanden hat, richten sie nichts mehr gegen ihn aus. Er könnte im Fall einer Cross Site Scripting-Schwachstelle darum bemüht sein, durch das Codieren verdächtiger Zeichenketten die bestehenden Filter-Mechanismen zu umgehen. Der Entwickler oder Administrator, der seine Umgebung absichern möchte, ist in diesem Sinne also immer einen Schritt im Verzug.

Nehmen wir an, Hersteller X preist ein Produkt Y an. Dieses soll in bester Weise gegen Cross Site Scripting-Attacken schützen. Der Hersteller setzt dabei ein klassisches Blacklisting ein. Die Eingaben innerhalb der Webapplikation werden also auf reservierte und damit verbotene Zeichenketten hin untersucht. Im Falle des Cross Site Scriptings sind dies vorwiegend spitze Klammern, also das grösser als und das kleiner als Zeichen. Schliesslich bildet es die Grundlage von HTML und eingebettetem Script-Code. Tritt ein solches Sonderzeichen bei einer Eingabe auf, wird sie aus Sicherheitsgründen von Sicherheitsprodukt Y verworfen. Ein radikaler, jedoch nicht untypischer Lösungsansatz, der das Ziel des Erhöhens der Sicherheit durchaus erreichen lässt.

Der zuvor skizzierte Angreifer höheren Niveaus sieht sich nun mit dieser Lösung konfrontiert. Obschon sie es unmöglich macht, den klassischen Angriff mit dem eigenständigen script-Tag umsetzen zu lassen, ist das Spiel für ihn noch lange nicht verloren. Er könnte nun versuchen seinen Script-Code als Attribut eines bestehenden Tags einzuschleusen. Gerade Cascading Style Sheets, also CSS, bieten da eine hervorragende Basis. Da hierbei keine spitzen Klammern, höchstens vielleicht einfache oder doppelte Anführungszeichen, in der Eingabe zum Einsatz kommen müssen, kann der Filter-Mechanismus von Produkt Y nicht mehr greifen. Die vermeintliche Lösung, die mit wenig Aufwand ein hohes Mass an Sicherheit versprochen hat, wurde damit übertölpelt. Sie ist damit, wenigstens in dieser Phase des Angriffs, obsolet geworden.

Der aufmerksame Zuhörer wird sich vielleicht nun fragen, wieso der Hersteller X nicht einfach darum bemüht ist, ebenso diese Variante des Angriffs durch eine verbesserte Version seines Produkts Y abzufangen. Hierfür bieten sich zwei Antworten an. Die technisch einfachere ist: Der Hersteller ist sich des Problems gar nicht bewusst. Tja, nicht wenige "Sicherheitsfirmen" wurden nicht der Sicherheit willen sondern wegen des Geldes wegen gegründet. Der schnelle Profit steht dabei im Vordergrund und das Wissen, das für das Erarbeiten von Qualität erforderlich wäre, will gar nicht erst angehäuft werden.

Aber es gibt natürlich auch Herstellerfirmen, die sehr gute Spezialisten anstellen und die sich sehr wohl den Gefahren und ihren Variationen bewusst sind. Nicht selten wird aber durch die Firmenleitung entschieden, dass man sich gar nicht gross auf die eher selten auftretenden Angriffsvarianten konzentrieren will. In diesem Fall wird also die Entwicklungszeit gar nicht erst zur Verfügung gestellt, obschon die Risiken als solche bewusst sind.

Und schliesslich birgt ein zu sicheres Produkt auch Gefahren in sich. Nein, nicht auf wirtschaftlicher Ebene, indem sich eine Sicherheitsfirma quasi selber wegrationalisieren würde. Viel mehr bedeutet Sicherheit auch oftmals ein gewisses Mass an Einschränkungen. Und was ist nun, wenn die supersichere Einschränkung von Produkt Y für 10 % der Kunden zu streng ausfällt. Die Folge davon könnten nicht mehr funktionierende Webapplikationen sein, die halt zum reibungslosen Arbeiten die potentiell gefährlichen Eingaben als solche dringend gebrauchen. Als Hersteller einer Sicherheitslösung will man selbstverständlich nicht Gefahr laufen, die eigenen Kunden durch derartige Betriebsstörungen zu behindern und sich selber zusätzliche Arbeit mit aufwändigen Support-Calls aufzuerlegen. Die Individualität und Heterogenität des Computermarkts macht es also unmöglich, eine gleichgute Lösung für alles und jeden bereitzustellen.

Ein ausgezeichnetes Beispiel für diese defensive Philosophie seitens der Hersteller ist die Betriebssystemreihe Windows. Die US-amerikanische Firma Microsoft stellt seit jeher die Einfachheit und Produktivität des Systems in den Vordergrund, denn schliesslich hat sie massgeblich zur Popularisierung des Produkts in den letzten 20 Jahren beigetragen. Um diese Prioritäten nicht zu gefährden, werden viele Sicherheitsfunktionen standardmässig gar nicht erst aktiviert, obschon sie eigentlich mitgeliefert werden würden. Dies reicht von einer lax konfigurierten Internetverbindungsfirewall über das Fehlen der Aktivierung von automatischen Updates bis hin zu ausgeschalteten Passwort-Richtlinien. Der Administrator des Systems ist also selber verpflichtet, nachträglich in manueller Arbeit das von ihm gewünschte Mass an Sicherheit zu erreichen. Schrenkt er dabei die Funktionalität des Systems als solches ein, ist es dann aber auch seine Schuld, denn schliesslich wollte er sich ja diese mühsame Sache, die sich Sicherheit nennt, widmen.