KomplexitĂ€t đŸ€œđŸ€› IT Sicherheit: 2 interessante Beispiele

BeschĂ€ftigt man sich regelmĂ€ĂŸig mit IT Sicherheitsthemen – etwa in dem man jede Woche den Security Now Podcast hört – gibt es immer wieder Momente in denen man völlig davon ĂŒberzeugt ist, dass das Internet nur von Kaugummi und Klebeband zusammengehalten wird. Aber oft sind es auch Themen, die tief in die unheimlich komplex gewordenen Infrastukturen und Technologien fĂŒhren, mit denen wir tĂ€glich hantieren. Das sind zwei Beispiele aus den letzten Wochen, die ich besonders spannend fand:

Trojan Source – UTF-8 und Tricks mit dem bidi Encoding 🔀

Aus Security Now 843: Zwei britische Forscher haben ein spannendes Paper mit dem Titel ‚Trojan Source: Invisible Vulnerabilities‚ veröffentlicht, welches im Endeffekt diese Kernaussage hat:

Bei der PrĂŒfung eines Programmcodes kann man nicht mehr davon ausgehen, dass der Code, den man vor sich auf dem Bildschirm sieht, der gleiche Code ist, der spĂ€ter vom Compiler ‚gesehen‘ und in ein Programm ĂŒbersetzt wird

So wie das Trojanische Pferd auch nicht das war, was es zu sein schien…Wenn man darĂŒber einen Moment nachdenkt zieht es einem nach und nach das Fundament unter dem FĂŒĂŸen weg, auf dem die ÜberprĂŒfung von SoftwarequalitĂ€t und -sicherheit von jeher stand:

Ein Mensch schaut sich in einem Editor den Quellcode, den ein anderer Mensch – oder inzwischen auch eine Maschine – geschrieben hat, versucht ihn zu verstehen und vergleicht ihn mit der Funktion, die der Code laut Pflichtenheft oder Eigenbeschreibung oder Stack Overflow Kommentar haben soll.

Im Paper werden nun unterschiedliche Verfahren beschrieben, wie man in Quellcode, der als Unicode gespeichert ist, subtile TĂ€uschungen einschmuggeln kann. Und dabei kommt die KomplexitĂ€t moderner Zeichensatzcodierungen, die den Anspruch haben letztlich jedes relevante Schriftsystem der Welt – und möglicherweise auch extraterrestrische – korrekt darstellen zu können, uns die Quere:

Neben vergleichsweise simplen Ticks wie dem EinfĂŒgen von breitenlosen und damit unsichtbaren Leerzeichen (Zero Width Space ZWSP), die Stringvergleiche scheitern lassen können, oder der Verwendung von Homoglyphen, die etwa zur EinfĂŒhrung alternativer Methodenaufrufe genutzt werden können, sind es die Nutzungen der Bidirectional Commands und davon gibt es einen ganzen Block:

Tabelle mit den UTF-8 Zeichen fĂŒr Richtungswechsel. Quelle: https://www.w3.org/International/questions/qa-bidi-unicode-controls

Die lassen sich sogar verschachteln und Àhnlich wie bei einem Stack in der Programmierung gibt es POP Anweisungen um Verschachtelungen wieder zu beenden und damit eine Schachtelungsebene nach oben zu gehen:

Tabelle mit den UTF-8 Zeichen fĂŒr Richtungswechsel. Quelle: https://www.w3.org/International/questions/qa-bidi-unicode-controls

Gerade mit dem Isolates, die komplette Gruppen von Zeichen als gemeinsames Element behandeln, und Kombinationen von BiDi Anweisungen lassen sich leicht FĂ€lle konstruieren, bei denen etwas, dass im Quellcodeeditor so aussieht:

...
/* Wenn SicherheitsprĂŒfung bestanden, dann return; */
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

fĂŒr den Compiler hingegen so erscheint:

...
/* Wenn SicherheitsprĂŒfung bestanden, dann */ return;
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

Hier wird also aus dem scheinbaren Kommentar am Ende eine Programmanweisung, die die Logik komplett aushebelt. Das solche subtilen Änderungen manchmal weitreichende Probleme verursachen, dafĂŒr ist der goto fail;-Bug ein gutes Beispiel, den Apple vor Jahren in seinem Betriebssystem hatte. Hier sah der fehlerhafte Abschnitt so aus:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
	goto fail;

Richtig wÀre aber diese Variante gewesen:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
goto fail;

Die dritte Zeile durfte also nicht eingerĂŒckt sein. Manchmal reicht schon ein TAB um den Unterschied zu machen und in diesem Fall gab es Vermutungen, dass vielleicht jemand dafĂŒr bezahlt worden sein könnte diesen subtilen Fehler an einer entscheidenden Stelle einzubauen. Das Risiko der Entdeckung wĂ€re gering gewesen und man hĂ€tte sich leicht damit herausreden können, dass es sich um einen Tippfehler gehandelt hat. Mit Hilfe der BiDi-Trickserei wĂ€re dieser Fehler nicht einmal bei einem sehr sorgfĂ€ltigen Code Review sichtbar gewesen.

Da die Forscher bereits reale Beispiele fĂŒr die Anwendung dieser Technik gefunden haben ist das keine rein theoretische Bedrohung. Da sich solcher Code sogar per Copy-and-Paste ĂŒbernehmen lĂ€sst sind beliebte Vorgehensweisen in der modernen Softwareentwicklung ebenfalls gefĂ€hrdet. Also noch mehr gefĂ€hrdet, als sie es immer schon waren 🙈

Was kann man tun?

GrundsĂ€tzlich wird man wohl abwarten mĂŒssen bis die Werkzeuge wie Editoren, Compilier und vielleicht auch Linter sich dieses Problems annehmen. Bis dahin gibt es vielleicht diese Faustformeln:

  • Gerade in den Quellcode eingebrachte Texte wie Kommentare und Strings sind Einstiegspunkte fĂŒr diese Art von Angriff
  • Die Auswirkung der bidi-Tricksereien enden beim nĂ€chsten Zeilenumbruch. Eine einheitliche Quellcodeformatierung, die z. B. eingebettete Kommentare nicht in der gleichen Zeile stehen lĂ€sst wie Code, kann ein paar Varianten vermutlich aushebeln
  • Bei der Nutzung von fremden Programmcodes muss man noch stĂ€rker als bisher schon auf deren QualitĂ€t achten. Was immer schon notwendig, und immer schon schwierig war

HTTP Request Smuggeling đŸ§±â›ïž

Aus Security Now 846: Auch dieses Problem wird durch KomplexitÀt verursacht, aber auf einer ganz anderen Ebene: Hier geht es darum, dass zwei oder mehr hintereinander geschaltete Webserver, die am Bedienen eines Webrequests beteiligt sind, das dabei verwendete HTTP Protokoll nicht einheitlich interpretieren.

Und im Endeffekt unterschiedliche Vorstellungen davon haben, welche Webrequests sie eigentlich gerade verarbeiten.

Dieses Problem ist kein ganz neues Problem, aber heute noch relevanter, da es inzwischen gÀngige Praxis ist, dass mehr als ein Server am Ausliefern einer Seite beteiligt ist:

  • Proxy Server werden vor den eigentlichen Applikationsserver geschaltet, um die Last zu verringern
  • Webserver wie Apache oder nginx liegen vor den Applikationsservern um TLS zu terminieren oder Loginfunktionen – z. B. Shibboleth – zu ĂŒbernehmen
  • Loadbalancer sind Netzwerkkomponenten, die die Zugriffe auf nachgelagerte Server verteilen, um Lasten gleichmĂ€ĂŸig verarbeitbar zu machen
  • Dienste wie Cloudflare bieten ihren Kunden durch vorschaltete Systeme Schutz vor Denial of Service Angriffen, die eigentlichen Server sind nicht mehr direkt erreichbar
  • Und alle denkbaren Kombinationen davon….

FĂŒr die effiziente Kommunikation zwischen diesen Servern werden verschiedene Webrequests gerne hintereinander gehĂ€ngt, damit sie sich schnell ĂŒber die gleiche Verbindung ĂŒbertragen lassen.

Aber wie schafft man es dem einen Server etwas anderes vorzugaukeln, als dem spĂ€ter drankommenden Server? In dem man die zwei Optionen, die der HTTP Standard als Mittel bietet um die LĂ€nge eines Request zu definieren – und damit bei hintereinander gehĂ€ngten Requests zu definieren, wo der eine aufhört und der andere beginnt – so trickreich nutzt, dass die beteiligten Server zu unterschiedlichen Ansichten darĂŒber gelangen, wo die Grenze zwischen zwei Requests liegt. Auch wenn es laut dem Standard eigentlich klar wĂ€re, wie vorzugehen ist:

“According to the HTTP/1.1 standards, if both Content-Length and Transfer-Encoding headers are passed, Transfer-Encoding takes precedence.”

Quelle auf Medium

Auf diese Weise kann es bei anfĂ€lligen Serverkombinationen – und laut diesem Paper sind das viele – gelingen einen Zugriff auf einen Backend Server abzusetzen, der eigentlich von den davor geschalteten Servern gefiltert werden sollte. Das kann insbesondere dann relevant sein, wenn die vorgeschalteten Server das Login- und Rechtemanagement ĂŒbernehmen.

FĂŒr eine bestimmte Variante des Request Smugglings vulnerable Serverkombinationen laut diesem Paper

Auch hier ist es nicht leicht etwas zu tun. Wie immer muss man natĂŒrlich seine Server aktuell halten, so gibt es z. B. fĂŒr Tomcat inzwischen einen Patch fĂŒr CVE-2021-33037, der auch mit HTTP Request Smuggeling zu tun hat. Aber auf das Verhalten vieler Komponenten, wie z. B. Loadbalancer, hat man wenig bis keinen Zugriff.

Eine Lösung ist es vielleicht die kritischen Entscheidungen einer Applikation – also die Rechte- und Zugriffskontrolle – möglichst weit nach hinten zu verlagern, bis in die Applikationsserver. Das nimmt einem Optimierungsmöglichkeiten, aber dafĂŒr ist der Server, der am Ende die Requests verarbeitet, auch derjenige, der entscheidet welche Requests zulĂ€ssig sind.

Hafnium im Gartenshop

Die wahlweise Hafnium oder ProxyLogon genannte Gruppe von SicherheitslĂŒcken in Microsofts Exchange Servern dominierte in den letzten Wochen die IT Sicherheitsthemen. Und selbst wenn IT Profis wie die Kollegen in der Uni die LĂŒcken schnell geschlossen haben kann einen das Thema betreffen. Daran erinnert diese Mail eines Webshops, bei dem ich vor Jahren mal etwas bestellt habe, und die gestern eintraf:

Screenhot einer Mail mit der Information darĂŒber, dass der Exchange Server eines Webshops gehackt wurde

Nicht alle Admins von Exchange Servern waren schnell genug um den direkt nach Bekanntwerden der LĂŒcke einsetzenden, massenhaften Scans nach verwundbaren Servern zuvor zu kommen. Vermutlich gibt es 10.000e von Systemen, die schon mit Webshells oder anderen HintertĂŒren ausgestattet wurden (Nachtrag: manche offenbar auch gleich mehrfach). Und ein reines Patchen der Exchange LĂŒcken beseitigt diese ZugĂ€nge dann nicht mehr.

Die DSGVO zwingt nun die Betreiber zumindest im europĂ€ischen Raum dazu ihre Kund*innen ĂŒber solche VorfĂ€lle zu informieren. Und ich wĂŒrde wetten, dass das nicht die letzte entsprechende Mail war, die ich bekommen werde. NatĂŒrlich nur, wenn gehackte Betreiber sich gesetzeskonform verhalten bzw. ĂŒberhaupt entdecken, dass sie gehackt wurden.

Was kann man tun?

Bei der Gelegenheit die Erinnerung an den schönen Have i been pwned? Dienst:

https://haveibeenpwned.com/

Der benachrichtigt einen, wenn mit der eigenen Mailadresse verknĂŒpfte Kontodaten irgendwo im (Dark)Web auftauchen, oft auch verbunden mit der Information von welchem Dienst diese Daten gestohlen wurden. Ich habe in den letzten Jahren schon mehrere entsprechende Meldungen bekommen und zum GlĂŒck hatte ich bei den jeweiligen Diensten schon individuelle, nur fĂŒr den jeweiligen Dienst geltende Passworte verwendet, so dass mit den gestohlenen Zugangsdaten nicht noch weitere Konten von mir missbraucht werden konnten.

Was zum nĂ€chsten Tipp fĂŒhrt: Heute ist die Verwendung eines Passwortmanagers unumgĂ€nglich um

  • sehr sichere (also lange und komplett zufĂ€llige) und
  • fĂŒr jeden Dienst einzigartige

Logindaten zu verwenden. Wer sich dabei nicht auf die in heutigen Webbrowsern eingebauten Passwortmanager verlassen möchte, der findet hier einen aktuellen Überblick.

Wie lang darf eigentlich ein class-Attribut sein?

Ich arbeite nicht erst seit gestern mit HTML, aber diese Frage habe ich mir nie gestellt. Der aktuelle Security Now Podcast (Folge #810) mit seiner Beschreibung der interessanten ‘Prime+Probe 1, JavaScript 0: Overcoming Browser-based Side-Channel Defenses’ Forschungsarbeit hat mich erst darauf gebracht: Darin geht es um einen Ansatz um Nutzer*innen im Webbrowser ganz ohne Javascript zu tracken und der trickreiche Ansatz um mal wieder Cache Timings als Seitenkanal zu nutzen verwendet – Achtung! – 2 Millionen Zeichen lange Klassennamen. Zitat:

CSS Prime+Probe Implementation. Figure 3 shows a code snippet implementing CSS Prime+Probe, using CSS Attribute Selectors to perform the attack. Specifically, Line 9 defines a div with a very long class name (two million characters).

Kann das sein? Warum sollte die HTML Spezifikation derart lange Namen erlauben? HĂ€tte ich vorher darĂŒber nachgedacht wĂ€re mein Tipp vermutlich bei 1024 oder maximal 32.768 Zeichen gelandet. Das sollte auch fĂŒr sehr sprechende und exzessive Anwendungen von CSS Klassennamen ausreichen, wie sie z. B. die BEM Vorgehensweise nahelegt.

HTML Code mit sehr langem class-Attribut

Aber die Antwort, warum die Spezifikation solche langen Namen erlaubt, scheint einfach zu sein: Sie macht hier ĂŒberhaupt keine Vorgabe! Demnach setzen nur die konkreten HTML Implementierungen der Webbrowser Grenzen, schon um zu verhindern, dass solche absurden Inhalte den Speicher zum ĂŒberlaufen bringen. Aber wenn es solche Grenzen gibt, dann liegen sie offenbar weit jenseits dessen, was sich ‘vernĂŒnftig’ anfĂŒhlt.

Ob die Browserhersteller angesichts solcher Tricksereien nun anfangen engere Begrenzungen zu definieren? In regulĂ€ren Webanwendungen sind jedenfalls kaum Anwendungen vorstellbar, die mehr als 1024 Zeichen fĂŒr Klassennamen verwenden. Oder?

BoringSSL und die FIPS 140-2 Zertifizierung

Vor inzwischen mehr als 3 Jahren verkĂŒndete Adam Langley in seinem Blog den Beginn der Arbeiten an BoringSSL, einem Fork von OpenSSL, der speziell auf die Anforderungen von Google zugeschnitten ist. Anlass waren die verschiedenen Probleme in SSL/TLS Implementierungen, insbesondere der Heartbleed Bug in OpenSSL, der damals fĂŒr viel Aufsehen sorgte. Mit BoringSSL schuf Google sich eine bereinigte SSL/TLS Implementierung, die schon knapp ein Jahr spĂ€ter in die großen Google Produkte Chrome & Android einging und zum Betrieb der Google Services im Netz verwendet wurde. FĂŒr Google ist das Projekt offenbar ein Erfolg, da sie damit endlich eine einheitliche Basis fĂŒr diesen sicherheitsrelevanten Code schaffen konnten, die sie nach eigenem GutdĂŒnken weiterentwickeln können.

Ist BoringSSL eine Alternative?

Wer OpenSSL einsetzt, oder LibreSSL, den anderen damals entstandenen Fork, kann sich die Frage stellen ob ein Library, welches von Google entwickelt wird, vielleicht die bessere Alternative ist? ‘Besser‘ ist dabei ein Adjektiv mit mehreren Aspekten, darunter RĂŒckwĂ€rtskompatibilitĂ€t (mit OpenSSL), StabilitĂ€t, Sicherheit, Codereife, Funktionsumfang und Lizenzierung. Google stellt auf der BoringSSL Seite dazu diese Hinweise direkt an den Anfang:

“BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.”

Das kann man nicht gerade als aktives Werben um neue NutzerInnen verstehen. In jedem Fall muss man damit rechnen einen gewissen ’Preis’ fĂŒr die Nutzung eines leistungsfĂ€higen, von einem hochkompetenten Entwicklerteam weiterentwickelten Pakets zu bezahlen, und zwar in Form vorzuhaltender eigener EntwicklerkapazitĂ€ten, damit man im Fall von Änderungen an BoringSSL in den eigenen Produkten entsprechend nachsteuern kann. Auf der anderen Seite ist heute das Risiko eines kompletten Refactorings von BoringSSL wohl eher gering, dazu ist selbst Google nicht mehr so ohne weiteres in der Lage angesichts von Millionen – oder gar Milliarden – von Android GerĂ€ten, die sich nur schwer aktualisieren lassen.

Seit ein paar Tagen gibt es eine neue Seite im BoringSSL Repository, die das Thema der FIPS Validierung behandelt. Dabei geht es nicht um das komplette Projekt, sondern um einen Teilbereich, genannt BoringCrypto. Dies könnte fĂŒr Unternehmen, die nur entsprechend zertifizierte Produkte einsetzen dĂŒrfen (Finanzbereich, etc.), noch einmal einen Stolperstein bei der Nutzung beseitigen. Aber was ist FIPS 140-2 eigentlich und verbessert es wirklich die Sicherheit von BoringSSL?

Was ist FIPS 140-2 und was macht es ‘sicher’

Der ‘Federal Information Processing Standard (FIPS) Publication 140-2’ ist ein Standard der US Regierung, der – ausgefĂŒhrt vom NIST – Anforderungen an kryptographische Module sowohl in Hardware wie auch Software definiert. Er legt damit verbindlich fest welche Anforderungen an entsprechende Module gestellt werden (z. B. in Form einer Liste der notwendigen/zulĂ€ssigen kryptographischen Algorithmen) und auch das Verfahren, ĂŒber das Anbieter entsprechender Produkte diese Zertifizierung erhalten können. Dabei wird in 4 Level unterschieden, die jeweils immer höhere Anforderungen stellen, z. B. in Bezug auf die Verhinderung bzw. Feststellung von Manipulationsversuchen.

Dieser Standard ist neben den Common Criteria wohl der wichtigste IT Sicherheitsstand weltweit. Eine FIPS Zertifizierung erhöht damit die Sicherheit eines Produkts in jedem Fall. Oder?

Die Snowden EnthĂŒllungen

Eine Anforderung im FIPS Zertifizierungsprozess ist die Garantie, dass eine zertifizierte Software sich selbst auf Konsistenz prĂŒfen kann. Siehe dazu im letzten Abschnitt mehr. Dies kann nur auf eine Weise erreicht werden, die man aus heutiger Sicht nicht mehr unbedingt als letzten Stand der sicherheitsbewussten Programmierung sehen muss. In der BoringSSL Seite zu FIPS findet sich daher an einer Stelle der Satz

‘This might make building ROP chains easier for an attacker, but so it goes.’

Ein weiterer Kritikpunkt – der z. B. in der entsprechenden OpenSSL Seite vorgebracht wird – ist die Langsamkeit des Zertifizierungsprozesses. Nun braucht eine sorgfĂ€ltige Zertifizierung ihre Zeit, aber auf der anderen Seite ist es heute wichtiger denn je bei gefundenen Fehlern schnell Bugfixes verbreiten zu können. Denn selbst nach einer Zertifizierung ist es unwahrscheinlich, dass jeder einzelne Fehler gefunden wurde. Wenn aber eine Fehlerkorrektur dann eine erneute Zertifizierung erforderlich macht vergehen schnell mal einige Monate. In dieser Zeit haben Angreifer dann ausgerechnet in den Industrien mit besonderen Sicherheitsanforderungen, die zur Nutzung FIPS-zertifizierter Lösungen gezwungen sind, ggf. leichtes Spiel.

Ein letzter, massiver Kritikpunkt entsteht allerdings aus dem mit den Snowden EnthĂŒllungen massiv gewachsenen Misstrauen gegen die US-Geheimdienste und ihre Verquickungen mit den Standardisierungsbehörden. Insbesondere betraf dieses Misstrauen damals einen in den Standard gebrachten Algorithmus zur Generierung von Zufallszahlen, der immer schon von Kryptographen misstrauisch beĂ€ugt worden war, sich nun aber als sehr wahrscheinlich mit einer bewusst konstruierten HintertĂŒr versehen erwies. Durch die langsamen Standardisierungsprozesse war es dann ein sehr zeitaufwĂ€ndiger Prozess diesen Algorithmus aus Produkten zu entfernen, bis dahin schlummerte er als potentielles Einfallstor in den als ‘sicher’ zertifizierten Produkten.

Insgesamt ist die Sache also ein zweischneidiges Schwert, und fĂŒr EntwicklerInnen eines Libraries wie BoringSSL immer mit der Frage verbunden was ihnen wichtiger ist: Ein Produkt zu entwickeln, welches nach den bekannten MaßstĂ€ben der IT Sicherheit ganz vorne ist, oder zusĂ€tzlichen, teilweise bĂŒrokratischen Aufwand auf sich nehmen um am Ende bei einem möglicherweise in Teilaspekten weniger sicheren Produkt zu landen, welches dafĂŒr dann aber in besonders sicherheitsbedĂŒrftigen Bereichen eingesetzt werden – und dort vielleicht andere, weniger gut gepflegte Lösungen verdrĂ€ngen – kann. Oder den Aufwand noch weiter zu erhöhen und parallele StrĂ€nge des eigenen Produkts zu pflegen, die beiden Anforderungen gerecht werden.

Wie macht man Software FIPS kompatibel

Aber nun wieder zurĂŒck zu der Frage welche Anforderungen eigentlich entstehen, wenn man eine C/C++ Programmierung mit den FIPS Vorgaben in Einklang bringen will?

‘FIPS-140 mandates that a module calculate an HMAC of its own code in a constructor function and compare the result to a known-good value. Typical code produced by a C compiler includes large numbers of relocations’

Wie man diesen Spagat löst, darĂŒber geht der grĂ¶ĂŸere Teil der BoringSSL Seite und er erklĂ€rt auch recht gut wie ein C/C++ Compiler im Detail vorgeht und welche Dinge man ihm abgewöhnen muss, damit dieses Ziel erreichbar wird. Möglicherweise haben die Google Leute hier nur damit begonnen die Erfahrungen nachzuhalten, die sie entweder selbst gemacht haben oder große Android Nutzer wie Samsung (PDF), die auf BoringSSL basierende Komponenten bereits in den FIPS Prozess eingebracht haben.

Zwei Jahre Android Security Rewards – Was hat sich verĂ€ndert?

Vor nun zwei Jahren hat Google mit den Android Security Rewards sein spezielles Bug-Bounty-Programm fĂŒr Android gestartet. Kurz bevor mit den ersten Stagefright SicherheitslĂŒcken die Kritik an der damaligen, desolaten Sicherheitslage Androids ein Allzeithoch erreichte. Im Android Entwicklerblog hat Google nun ein Fazit dazu gezogen, wie sich die Situation seit damals entwickelt hat. Der Post ist recht kurz, aber trotzdem in seinen Details interessant:

Android Update - Rot

Ein steter Strom von Bugreports

Man kann wohl sagen, dass dieses Bug-Bounty-Programm heute funktioniert: Im letzten Jahr sind mehr als 450 Reports eingegangen. Es vergeht damit wohl kaum ein Tag bei Google, an dem nicht eine Fehlermeldung eintrifft. Das ist zunĂ€chst einmal ein echter Erfolg, auch wenn daraus natĂŒrlich Schlagzeilen entstehen wie z. B. diese hier: „Android Was 2016’s Most Vulnerable Product.

Da Google den Android Quellcode im Android Open Source Project (AOSP) veröffentlicht kann sich hier faktisch jedeR an der Fehlersuche beteiligen und damit Geld und Anerkennung verdienen. Und tatsĂ€chlich tut dies eine große Zahl von Leuten.

In gewisser Weise bestĂ€tigt Android damit das von Open Source Verfechtern gern ins Feld gefĂŒhrte Argument, wonach die Offenheit auch gleichzeitig fĂŒr eine bessere Sicherheit sorge, weil eben viele Menschen ohne große HĂŒrden nach Fehlern suchen können. Auf der anderen Seite zeigt aber der Erfolg des Bug-Bounty-Programms auch was fĂŒr ein wichtiger Faktor der finanzielle Anreiz sein kann. Dieser Anreiz fehlt bei vielen Open Source Projekten.

Mehr Geld, mehr Bugreports?

1,1 Millionen Dollar hat Google laut dem Bericht in den letzten 12 Monaten ausgeschĂŒttet, was einer durchschnittlichen Summe von mehr als 10.000$ pro Sicherheitsforscher entsprĂ€che. NatĂŒrlich gibt es Personen / Gruppen, die durch besonders viele Meldungen herausstechen, Google selbst hebt hier das C0RE Team hervor, welches allein 118 Reports eingereicht und dafĂŒr 300.000$ erhalten hat.

Die höchsten Belohungsstufen wurden dabei aber bisher nicht erreicht, Google hebt diese Belohnungen nun auf das 4- bzw. 5-fache der bisherigen Werte. Damit könnte man nun 6-stellige Summen allein fĂŒr einen einzigen Bugreport erhalten.

Google steht hier – wie heute alle großen IT Unternehmen – in starker Konkurrenz zu staatlichen Stellen aus aller Welt, die fĂŒr ihre Geheimdienste nach ‚Cyberwaffen‘ Ausschau halten und sich dazu privater Dienstleister bedienen, fĂŒr die die Suche nach Einbruchsmöglichkeiten in populĂ€re Software zu einem profitablem GeschĂ€ft geworden ist. Hier kann man mit einem funktionierenden Exploit in das weltweit meistgenutzte Betriebssystem vermutlich noch weitaus höhere Gewinne erzielen.

Das ein hoher Belohnungspreis ein Bug-Bounty-Programm nicht automatisch erfolgreich machen muss hat der gescheiterte Versuch von Googles Project Zero gezeigt: Dieses wollte mit dem Project Zero Price ein eigenes Programm auf die Beine zu stellen, welches ebenfalls 6-stellige Summen fĂŒr hochwertige Angriffe auf Android in Aussicht stellte. Es erhielt aber keine einzige relevante Einreichung und wurde wieder eingestellt.

Ein breiter aufgestelltes Programm wie die Android Security Rewards kann da durchaus erfolgreicher sein, auch wenn bzw. gerade weil seine Belohnungsstaffelung bei deutlich kleineren Summen beginnt: Dadurch erhöht sich die Zahl der beitragenden ForscherInnen und der Versuch einzelne Fehler zu horten, bis sie sich zu einem leistungsfĂ€higeren Exploit kombinieren lassen, ist dann mit dem großen Risiko verbunden, dass jemand anderes einen der Fehler findet, die Belohnung erhĂ€lt und Google die LĂŒcke schließt.

Welche GerĂ€te sind fĂŒr sicherheitsbewusste Android NutzerInnen kaufbar?

Im Oktober 2015 – gezwungen durch das Stagefright Debakel – entschied sich Google einen lange ĂŒberfĂ€lligen Schritt zu machen: Damals begann das Programm der monatlichen Android Sicherheitsupdates. Bis dahin gab es den absurden Zustand, in dem Google Meldungen ĂŒber SicherheitslĂŒcken zwar einsammelte, aber faktisch niemand zeitnah davon profitieren konnte. Durch die neuen Updates waren zuerst nur die direkt von Google kontrollierten Android GerĂ€te wieder auf einem akzeptablen Sicherheitslevel, aber allmĂ€hlich auch die Produkte einiger anderer Hersteller.

Android Upate

Und auch darĂŒber gibt der aktuelle Blogpost Auskunft: Bei welchen Herstellern von Android GerĂ€ten ist meine Chance groß, dass diese zeitnah Sicherheitsupdates bekommen? Google sagt dabei zum einen dies:

Over 100 device models have a majority of their deployed devices running a security update from the last 90 days

Die dann gezeigte Tabelle mit konkreten GerĂ€ten lĂ€sst trotz ihrer etwas anderen Semantik (‚This table shows the models with a majority of deployed devices running a security update from the last two months‘) eigentlich nur einen Schluss zu: Wer keines der wenigen direkt von Google kommenden GerĂ€t kaufen kann oder will, der sollte zu einem Samsung GerĂ€t greifen. Samsung hat mit Abstand die grĂ¶ĂŸte Zahl von GerĂ€ten in dieser Liste und kann damit wohl als Vorbild bei der Updatepolitik gelten (wobei es hier wohlgemerkt nicht um Updates der Android Version geht, dass ist noch mal ein ganz anderes Thema).

Fazit: Auf dem richtigen Weg (aber der Weg ist noch weit)

Google ist es augenscheinlich gelungen ein lebendiges Umfeld von Sicherheitsforschern zu schaffen, die zur Android Sicherheit beitragen. Die ausgeschĂŒtteten Summen – auch wenn es sich dabei inzwischen um einen Millionenbetrag handelt – sind dabei vermutlich immer noch ‚gĂŒnstig‘. Muss man das Fazit ziehen, dass Android angesichts der weiterhin hohen Zahl von monatlichen Fehlerkorrekturen besonders unsicher ist?

Das finde ich schwer zu beurteilen, auch andere (Betriebs-)Systeme haben durchaus ansehnliche Zahlen an korrigierten Fehlern vorzuweisen und faktisch ist jeder korrigierte Fehler einer weniger, den jemand anderes schon im Geheimen gefunden und ausgenutzt haben könnte. Nur falls auch in den kommenden Jahren die Zahl der in Android gefundenen Fehler so hoch bleibt wÀre das ein sicheres Zeichen, dass mit der Codebasis bzw. der Weiterentwicklung etwas grundsÀtzlich nicht in Ordnung ist.

Weiterhin das grĂ¶ĂŸte Problem des Android Ökosystems ist aber das Fehlen von Updates fĂŒr die Masse der inzwischen mehr als 2 Milliarden GerĂ€te. Auch wenn Google die ‚mehr als 100 Modelle‘ nicht genau benennt, bei denen die Mehrheit der NutzerInnen wenigstens ein maximal 3 Monate altes Sicherheitslevel erreicht hat, kann man auf Grund der Vielzahl von Android GerĂ€ten – siehe die immer wieder gern zitierte Auswertung von OpenSignal aus dem Jahr 2015 – davon ausgehen, das dies nur ein Bruchteil der in aktiver Nutzung befindlichen GerĂ€te ist.

Auch hier muss es die Zeit erst zeigen, ob die Seamless Updates, die mit Android N eingefĂŒhrt wurden, und die in Android O mit dem Project Treble geplante stĂ€rkere Separierung von Betriebssystemteilen in der Lage sein werden eine signifikante Verbesserung zu bringen. Angesichts der gewohnt langsamen Ausbreitung neuer Android Versionen kann man von diesen Verbesserungen aber bestenfalls in einigen Jahren einen sichtbaren Effekt erwarten.

Bis dahin wird es wohl insbesondere den im Hintergrund von Google durchgefĂŒhrten PrĂŒfungen im Play Store und auf den EndgerĂ€ten ĂŒberlassen bleiben Angriffe zu verhindert.

Google baut eine eigene Root-CA auf

Vor ein paar Tagen hat Google in seinem Security Blog bekannt gegeben selbst zu einer Zertifizierungsstelle (Certificate Authority / CA) zu werden. Diese kann man unter der Adresse https://pki.goog/ erreichen. CAs sind heute entscheidende Stellen in der Public Key Infrastructure (PKI) des Webs, die erst die sichere Kommunikation z. B. zwischen Webbrowser und Webserver ermöglichen.

Welches Problem will Google damit fĂŒr sich lösen?

Google ist zum einen ein Unternehmen, welches einen enormen Bedarf an Zertifikaten hat, der durch zwei Faktoren bedingt wird:

  1. Die schiere Anzahl der zu sichernden Onlinedienste
  2. Googles schnelle Zertifikatsrotation, die Zertifikate heute nach 3 Monaten auslaufen lÀsst

Dann hat Google das Thema der IT Sicherheit wie kaum ein zweites Unternehmen im Blick und treibt es an allen Ecken voran, auch im Bereich der Zertifizierungsstellen. Gleichzeitig sind Google Zertifikate oft das Ziel bei Kompromittierungen von Zertifizierungsstellen, da Googles Dienste nun mal von vielen Nutzern besucht und damit fĂŒr Angreifer besonders wichtig sind.

Google hat hier  in den letzten Jahren ĂŒber seine Marktmacht mit Chrome als dominierendem Webbrowser und Android als dominierendem Mobilbetriebssystem immer mal wieder krĂ€ftig an den ZĂŒgeln gezogen, wenn eine CA Mist gebaut hat.

Was stimmt nicht mit mit dem heutigen System der Zertifizierungsstellen?

Das heute existierende System der Zertifizierungsstellen ist in der Lage unsere Webbrowser-Webserver-Kommunikation gegen massenhaftes Abhören zu sichern, wenigstens seit es Initiativen wie Let’s encrypt gibt, die Serverbetreibern die dazu notwendigen Zertifikate kostenfrei und mit geringem Aufwand automatisiert zur VerfĂŒgung stellen können. Die VerschlĂŒsselung ist aber nur der eine Aspekt bei einer PKI: Der andere ist die Sicherstellung der AuthentizitĂ€t meines Kommunikationspartners. Damit ist gemeint, dass ich – wenn ich z. B. auf ‘https://www.google.com’ gehe – auch tatsĂ€chlich direkt auf einer zu Google gehörenden Webseite lande, und nicht auf einer gefĂ€lschten Seite bzw. ĂŒber einen mithörenden Mittelsmann kommuniziere.

Hier kommen die CAs ins Spiel, die mir garantieren sollen, dass das Zertifikat, welches mir beim Besuch von google.com prĂ€sentiert wird, auch tatsĂ€chlich Google gehört. Eine CA kann dabei ihre Aufgabe nur erfĂŒllen, wenn sie es schafft mit ihren Wurzelzertifikaten in die gĂ€ngigen Webbrowser und Betriebssysteme aufgenommen zu werden. Damit ihr das gelingt muss sie ihre Sorgfalt bei der Vergabe von Zertifikaten beweisen.

So weit, so gut. Ein grundlegendes Problem ist dabei allerdings, dass mein Webbrowser danach zunĂ€chst jeder der mitgelieferten CAs uneingeschrĂ€nkt vertraut. Dies sind im Firefox heute mehr als 150 Zertifikate von mehr als 50 Herausgebern und jedes Zertifikat – und sogar davon abgeleitete Unterzertifizierungsstellen – ist in der Lage ein ‘gĂŒltiges’ Zertifikat fĂŒr google.com zu unterzeichnen. NatĂŒrlich muss so etwas immer mal wieder schief gehen, Beispiele siehe oben.

Google hat hier in den letzten Jahren in mehreren Schritten versucht diese Probleme zumindest teilweise in den Griff zu bekommen:

  • Certificate Pinning in Chrome: In Chrome ist ein kleines Set von CAs fest einkodiert, die prinzipiell fĂŒr Google Zertifikate ausstellen könn(t)en. Dadurch hat sich Chrome in den vergangenen Jahren immer wieder als Melder von VerstĂ¶ĂŸen gegen die Sicherheit oder die Regelungen von CAs erwiesen.
  • Dieser Ansatz ließ sich natĂŒrlich nicht auf das komplette Web skalieren, von Google kommt daher das inzwischen in einem RFC definierte HPKP, welcher aber noch nicht alle Browser unterstĂŒtzen. Auch schĂŒtzt es Benutzer nicht beim ersten Besuch einer Webseite.
  • Abkehr von SHA-1: Die Ablösung von SHA-1 als Signaturalgorithmus fĂŒr Zertifikate wurde von Google besonders aggressiv vorangetrieben.
  • Certificate Transparency (CT): Dieses Projekt beschreibt wie ein endloses Logbuch aller jemals von CAs ausgegebenen Zertifikate effizient gefĂŒhrt und online zugreifbar gemacht werden kann. Es gibt eine Implementierung von Google, aber inzwischen auch von CAs. Certificate Transparency ermöglicht es Webseitenbetreibern gezielt zu prĂŒfen ob fĂŒr ihre Webseiten illegitime Zertifikate ausgestellt wurden.
  • Chrome und CT: Google hat fĂŒr den Herbst 2017 angekĂŒndigt, dass Chrome beginnen wird bestimmte Zertifikate nur noch dann zu honorieren, wenn die Certificate Transparency verfĂŒgbar ist.

Google hat die CAs hier in den letzten Jahren teilweise vor sich hergetrieben und sich damit durchaus einiges an Kritik eingefangen. FĂŒr Google selbst ist der Aufbau einer eigenen CA vermutlich nur ein letzter Baustein in einem System, dass sie bereits mit einem Browser (Chrome), Betriebssystemen (Android, ChromeOS), Protokollen (SPDY und QUIC) und einigen der wichtigsten Internetdienste der Welt nahezu vollstĂ€ndig im Griff haben und weiterentwickeln möchten. Google schafft sich damit nun auch an dieser Stelle ein eigenes Experimentierfeld, in dem sie beweisen können, dass sich ihre Ideen fĂŒr die Zukunft des Netzes in großem Maßstab umsetzen lassen.

Wird Google Zertifikate frei anbieten bzw. verkaufen?

Abgesehen vom Vorantreiben der Internetsicherheit wird Google seine PKI sicher in Zukunft mit anderen Diensten wie der DomĂ€nenregistrierung verknĂŒpfen. Unklar ist allerdings ob sie tatsĂ€chlich zu einer CA werden wollen, die jedem Zertifikate anbietet.

Aus dem Policy Dokument der Google PKI kann man nach meinem VerstĂ€ndnis entnehmen, dass Google zumindest zur Zeit nicht mit kostenfreien Angeboten wie Let’s encrypt konkurrieren will. Ich lese das aus der Beschreibung des Verfahrens zur ÜberprĂŒfung der IdentitĂ€t von Antragsstellern bei der Zertifikatsbeantragung. Hier gibt es u. a. einen Aspekt, der eine ÜberprĂŒfung der postalischen Adresse fordert. Das ist ein ĂŒber die DomĂ€nenvalidierung der Gratisdienste hinausgehender Schritt, der sich nicht voll automatisieren lĂ€sst.

Meine Vermutung ist daher, dass Google zumindest mittelfristig nicht mit den existierenden CAs in direkte Konkurrenz treten, sondern seine CA nur fĂŒr die eigenen Dienste nutzen wird. Auch damit wird diese CA allerdings schnell zu einer der CAs werden, deren Zertifikate den grĂ¶ĂŸten Teil des Internetverkehrs sichern.

Wann werden die Google Root Zertifikate in Webbrowsern auftauchen?

Google selbst weist in seinem Blogpost darauf hin, dass es einige Zeit dauert die Wurzelzertifikate fĂŒr eine neue CA zu verbreiten. Hier mĂŒssen zunĂ€chst die großen Browseranbieter ĂŒberzeugt werden die Zertifikate aufzunehmen. Gleiches gilt fĂŒr die Betriebssystemhersteller (praktischerweise in einigen FĂ€llen die gleichen Unternehmen). Und es mĂŒssen noch viele andere Dinge wie die Updategeschwindigkeiten der jeweiligen Produkte bedacht werden. Vermutlich wird man die Zertifikate zuerst in den Google-eigenen Produkten wie Chrome, ChromeOS und Android finden können, auch wenn Google bei Mozilla den entsprechenden Prozess schon im letzten Dezember angestoßen hat.

Google ist allerdings nicht dafĂŒr bekannt Dinge, die sie unbedingt wollen, von den ZeitplĂ€nen anderer abhĂ€ngig zu machen. Daher hat man zwei bereits in Browsern und Betriebssystemen vorhandene Wurzelzertifikate gekauft und kann mit diesen schon jetzt nach eigenem GutdĂŒnken verfahren. Faktisch ist damit Google bereits zur Root CA geworden. Der vorherige Screenshot zeigt eines dieser Zertifikate in Chrome.

Was soll man von der ganzen Sache halten?

“You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.” – aduffy, 27.01.2017 auf ycombinator

Auf ycombinator findet man eine sehr ausfĂŒhrliche und meist gute Diskussion zu der Frage welche Auswirkungen dieser Schritt hat. NatĂŒrlich gibt es viele, die das zitierte Szenario eines ĂŒber alle Ebenen des Internets integrierten Konzerns fĂŒr bedrohlich / monopolistisch halten. Andere stellen die Frage warum man Google eigentlich so viel Vertrauen entgegen bringen sollte um nun auch noch ihrer CA zu trauen?

Die zweite Frage ist dabei fĂŒr mich die einfachere: Wenn ich von meinem Android Smartphone ĂŒber eine Google Suche eine Seite im Chrome Browser öffne vertraue ich Google sowieso schon sehr, sehr weitgehend. Wenn Google dann auch noch die Zertifikate verantwortet, die wenigstens die Google Dienste schĂŒtzen, fĂ€llt fĂŒr mich eine Stelle weg, der ich bisher auch noch vertrauen musste (die zuvor verwendete CA). Das ist eine Verbesserung.

Die Frage der Machtkonzentration bzw. des Monopols ist da wohl eher eine GefĂŒhlsfrage: Aus meiner Sicht hat Google das Thema der Internetsicherheit in den letzten Jahren sehr vorangebracht und ist dabei in schwierigen Fragen wie z. B. der Bestrafung von versagenden CAs mehr oder weniger auf der richtigen Seite geblieben. Mit einer eigenen CA kann Google im besten Fall demonstrieren wie eine leistungsfĂ€hige und sichere PKI aussehen kann. Ich sehe das Ganze also positiv.

Eine andere Frage ist vielleicht die, ob dadurch CAs verschwinden werden? Heute sehen sich die existierenden Zertifizierungsstellen am unteren Ende durch Let’s encrypt bedrĂ€ngt, welches fĂŒr viele Webdienste Zertifikate in vollkommen ausreichender QualitĂ€t bereitstellt. Am oberen Ende mag es in Zukunft eine Konkurrenz durch die Google CA geben, aber nicht ohne Grund haben viele LĂ€nder eigene CAs gegrĂŒndet und werden die ganz unabhĂ€ngig von einem Google Angebot betreiben. Wenn dafĂŒr einige der kleineren CAs, die möglicherweise Probleme damit haben einen seriösen Betrieb zu leisten, am Ende verschwinden, so ist das fĂŒr die Sicherheit des Internets dann eher gut.

Anti-DoS Tomcat Valve auf Github veröffentlicht

Auf Github findet sich jetzt unter dem Namen Anti-DoS Valve ein Werkzeug, welches beim Betrieb von Tomcat Servern nĂŒtzlich sein kann um diese vor Überlastungen durch böswillige Akteure im Netz zu schĂŒtzen. Dazu implementiert das Valve eine dynamische Zugriffsratenlimitierung, die sich umfangreich konfigurieren lĂ€sst. Zur Simulation der Auswirkungen unterschiedlicher Konfigurationen habe ich ein Google Drive Sheet veröffentlicht. Der Code steht unter der Apache Lizenz, kann also frei verwendet werden.

Woher kommt die Idee

Das Valve ist eine verallgemeinerte Version einer kleinen Programmierung, die ich im vergangenen Jahr kurzfristig erstellen musste, nachdem unsere Server immer mal wieder unter Überlastungen litten, die offenbar durch auf gekaperten Rechnern laufende Webcrawler verursacht wurden. Diese Zugriffe waren teilweise so aggressiv, dass sie Auswirkungen auf unsere regulĂ€ren Nutzer hatten.

Zur Begrenzung dieser unwillkommenen Zugriffe standen zunĂ€chst unterschiedliche Optionen im Raum, aber die Option ein Tomcat Valve zu implementieren setzte sich am Ende aus diesen GrĂŒnden durch:

  • Ein Valve ist durch seine Verortung im Tomcat Server nahe an der GeschĂ€ftslogik bzw. an den Leuten, die wissen was auf dem Applikationsserver lĂ€uft. Eine Verortung etwa auf Netzwerkebene hĂ€tte einen nicht unerheblichen Wissenstransfer zwischen unterschiedlichen IT Bereichen erfordert
  • Da es sich bei den Angriffen – auch böswillige Webcrawler kann man dabei als Angreifer sehen – nicht um umfangreiche (D)DoS Angriffe handelte war eine Gegenmaßnahme auf Ebene der Applikationsserver ausreichend
  • Der Aufwand fĂŒr die Programmierung des Valves war auf Grund der vorhandenen Erfahrungen vergleichsweise gering
  • Der Einsatz eines Filters mit identischer Funktion, der innerhalb der Webapplikationen eingesetzt wĂŒrde, erzeugt im Vergleich zu einem Valve einen höheren Aufwand in der Konfiguration

Was macht das Valve

Ziel ist es unwillkommene Belastungen der eigenen Server so weit begrenzen zu können, dass sie nicht mehr in der Lage sind negative Auswirkungen auf die regulĂ€ren Nutzer zu entfalten. Dabei soll die Schutzfunktion dynamisch sein, sich also selbststĂ€ndig auf neue Angreifer einstellen und diese blockieren können. Und schließlich soll der Overhead dieser zusĂ€tzlichen Filterung, die zunĂ€chst fĂŒr alle im Tomcat Server eingetreffenden Requests anspringt, möglichst klein sein. In der aktuellen Version arbeitet das Valve dabei auf der Ebene einzelner IP Adressen, fĂŒr die Limitierungen durchgesetzt werden können.

FĂŒr die konkrete Implementierung wurden dann Erfahrungen genutzt, die ich frĂŒher bei anderen Programmierungen zu Ratenlimitierungen gemacht hatte, insbesondere beim Aufbau unserer Identity Provider Infrastruktur und der dort durchgesetzten Begrenzung der Anzahl von möglichen Versuchen zum Erraten eines Passworts.

Um die Implementierung ressourcenschonend zu gestalten – insbesondere in einer DoS Situation, wo schnell abertausende von Requests in kurzer Zeit eintreffen können – wird fĂŒr die Ermittlung der aktuellen Zugriffsrate einer IP Adresse keine gleitende Auswertung gemacht, sondern es wird nur ĂŒber die Anzahl der Zugriffe innerhalb eines bestimmten Zeitintervalls (in der Programmierung Slot genannt) Buch gefĂŒhrt. Wird innerhalb eines solchen Slots die Anzahl der erlaubten Zugriffe ĂŒberschritten, so werden alle weiteren Zugriffe bis zum Ende des Slots abgelehnt. Damit nicht mit jedem neuen Slot das Spiel von vorn beginnt kann ein Anteil der in frĂŒheren Slots gezĂ€hlten Zugriffe ĂŒbernommen werden. Auf diese Weise sind sowohl die Datenhaltung im Valve wie auch Rechenaufwand gering und nehmen auch in einer Hochlastphase nicht wesentlich zu.

Über die Konfigurationsoptionen können dabei nahezu alle Eigenschaften gesteuert werden, neben dem Grenzwert der Zugriffe pro Slot auch die SlotlĂ€nge und der Umfang der aus frĂŒheren Slots ĂŒbernommenen Requestanzahlen. Mit diesem einfachen Mittel lassen sich durchaus komplexe Filterungen realisieren.

Es gibt im Valve noch weitere Optionen, ĂŒber die sich steuern lĂ€sst auf welchen Adressen die Ratenlimitierung ĂŒberhaupt wirksam werden soll (hier kann man z. B. Requests auf statische Inhalte wie JS oder CSS Dateien ausschließen um schĂ€rfere Einstellungen zu realisieren) und ob bestimmte IP Adressen oder Adressbereiche generell von einer Filterung ausgenommen werden sollen (z. B. Adressen aus dem Intranet, um interne Nutzer nie zu beeintrĂ€chtigen).

Wie legt man los

WĂ€hrend die grundsĂ€tzliche Inbetriebnahme des Valves sehr einfach ist (Clone von Github, AusfĂŒhren von Maven Install, JAR in Tomcat/lib Verzeichnis kopieren, Valve Konfiguration in server.xml ergĂ€nzen), liegt die eigentliche Herausforderung darin die fĂŒr den eigenen Anwendungsfall passenden Konfigurationsparameter zu finden. Hier gilt es die richtige Balance zu finden zwischen zu engen Einstellungen, die auch die regulĂ€ren Benutzer beeintrĂ€chtigen können, und zu offenen Parametern, die die Angreifer nicht richtig im Zaum halten können und damit auch wieder die regulĂ€ren Benutzer beeintrĂ€chtigen.

In der README findet sich ein eigener Abschnitt dazu, wie man bei der Inbetriebnahme vorgehen kann. Der Kernpunkt ist es hier ein ausreichendes Wissen ĂŒber die regulĂ€re Nutzung der eigenen Dienste zu haben, also welche Zugriffszahlen OK sind und welche ein böswilliges bzw. störendes Level erreichen. Die Auswertung der Tomcat Access Logfiles ist dabei der SchlĂŒssel. Hat man diese Werte kann man in dem Simulator Sheet vergleichen welche Auswirkungen eine bestimmte Konfiguration hat und damit prĂŒfen, ob sie in der Lage ist die Spreu vom Weizen zu trennen. Diese Knackpunkte gibt es dabei der Erfahrung nach:

  • Wie hĂ€ufig greifen Suchmaschinen zu? Gutartige Suchmaschinen zeichnen sich meist durch gleichmĂ€ĂŸige Zugriffe aus und haben keine Zugriffsspitzen. Je nach Valve Konfiguration kann es aber vorkommen, dass auch solche Zugriffsformen gesperrt werden, die dauerhaft unter den pro Slot erlaubten Zugriffsraten bleiben.
  • Dienen die eigenen Webapplikationen als Service Endpunkt, der von anderen Applikationsservern in großem Umfang genutzt wird? Wenn es sich dabei um gewollte FĂ€lle handelt, so sollte man die entsprechenden Adressen bzw. Adressbereiche grundsĂ€tzlich freischalten, damit die Valve Konfiguration nicht auf Grund solcher EinzelfĂ€lle zu offen gestaltet sein muss.
  • Wie viele Request löst ein Benutzer beim ersten Besuch (also mit leerem Cache) der eigenen Seiten aus? Hier erreichen moderne Webseiten auf Grund der vielen Komponenten hĂ€ufig erstaunliche Zahlen, wobei die Masse der Zugriffe auf statische Inhalte entfĂ€llt. Um auch hier die Valve Konfiguration nicht zu offen gestalten zu mĂŒssen ist es meist sehr sinnvoll die Zugriffe auf statische Inhalte nicht mit in die ZugriffszĂ€hlungen eingehen zu lassen. Diese Zugriffe sollten sowieso nicht die Hauptlastverursacher in einer dynamischen Webapplikation sein und die böswillige Akteure werden sie sowieso nicht abrufen.
  • Kommen regulĂ€re Benutzer in großer Zahl ĂŒber Proxies auf den eigenen Server, so dass sich hinter einzelnen IP Adressen faktisch viele Benutzer verbergen?

Auch bei sehr sorgfÀltiger Vorbereitung ist es aber notwendig zumindest in der ersten Zeit nach der Aktivierung des Valves die Logging Informationen im Auge zu behalten und zu beobachten ob Adressen gesperrt werden, die man eigentlich zulassen möchte.

Ist das Valve richtig konfiguriert kann man es in gewisser Weise ‚vergessen‘, da es danach Angriffe automatisch im Zaum halten kann. Änderungsbedarfe ergeben sich dann nur noch bei Modifikationen an den im Server installierten Anwendungen, die das Lastverhalten beeinflussen. Trotzdem sollte ein Monitoring fortgesetzt werden, schon allein um zu sehen ob Angriffe erfolgen und in welchem Umfang.

Was sind die Grenzen

Das Anti-DoS Valve kann seinem Namen nur in einem Teilaspekt des weiteren Themas (D)DoS gerecht werden. Es wird z. B. nicht bei riesigen Überflutungen helfen, die schon die Netzwerkebene ĂŒberlasten. Es hat aber seine Daseinsberechtigung in dem Bereich, der unterhalb des Angriffslevels liegt, der sich auf Netzwerkebene einfach erkennen lĂ€sst:

Im Fall unserer Server werden heute pro Tag normalerweise mehr als eine Million Requests verarbeitet. Starke Belastungen können aber schon entstehen, ohne das sich diese Zahl insgesamt vervielfacht, sofern die Zugriffe auf die entsprechenden Adressen gebĂŒndelt werden. An genau dieser Stelle kann das Valve eingesetzt werden, in dem es insbesondere die Zugriffe auf die Adressen reguliert, die geeignet sind hohe Belastungen zu erzeugen. DafĂŒr ist eine Kenntnis der entsprechenden Applikationen und ihrer sensiblen Punkte notwendig.

Die ursprĂŒngliche Version des Valves hat dabei den angestrebten Zweck bisher erfĂŒllt und sich als sehr stabil erwiesen.

Monitoring per JMX

Das Valve kann sehr weitgehend per JMX administriert und beobachtet werden. In der JConsole prÀsentiert es sich dabei so:

Auf diese Weise können KonfigurationsĂ€nderungen auch am laufenden Server durchgefĂŒhrt werden und gleichzeitig der aktuelle Status z. B. von blockierten IP Adressen beobachtet werden.

Ideen fĂŒr die Weiterentwicklung

Die bisherige Implementierung hatte das Ziel möglicht einfach gehalten zu sein und ist auf den bisherigen Einsatzzweck zugeschnitten. FĂŒr eine Verallgemeinerung der Funktion bieten sich aber eine Reihe von Erweiterungen an:

  • Testmodus: Ein Option das Valve im Server so zu betreiben, dass nur Loggings ĂŒber Blockaden erfolgen, aber keine echten Blockaden. Auf diese Weise könnten Konfigurationen zunĂ€chst risikofrei getestet werden.
  • ZĂ€hler auf Ebene von Subnetzen: Nicht nur echte DDoS Attacken verteilen ihre Zugriffe auf viele Ausgangsrechner, auch bei Webscrapern / böswilligen Crawlern kann dies beobachtet werden. Hier wĂ€re eine Verallgemeinerung der Programmierung interessant, die in der Lage ist ZĂ€hler nicht nur auf Ebene von einzelnen IP Adressen zu fĂŒhren. Die Implementierung des Monitors, der die ZugriffszĂ€hlung durchfĂŒhrt, ist bereits entsprechend verallgemeinert worden.
  • Möglichkeit mehrere Instanzen des Valves im Server nutzen zu können: Zwar kann man heute das Valve mehrfach in einem Tomcat konfigurieren, aber die Monitor Instanz ist nicht getrennt und per JMX wird nur eine Instanz des Valves gezeigt. Die Nutzung unterschiedlicher Valve-Instanzen in einem Server kann nĂŒtzlich sei falls unterschiedliche Konfigurationen fĂŒr verschiedene Webapplikationen gefahren werden sollen.
  • Verbesserungen fĂŒr den Einsatz in Serverfarmen: Heute mĂŒssen KonfigurationsĂ€nderungen an allen Servern separat erfolgen, auch gibt es keine Möglichkeit wie sich Instanzen des Anti-DoS Valves auf unterschiedlichen Servern verstĂ€ndigen können. In unserer Serverfarm beeintrĂ€chtigt uns das heute nicht, aber bei großen Farmen könnte so etwas nĂŒtzlich sein.

Falls jemand Lust hat an dem Projekt mitzumachen: Einfach melden 🙂

Analyse von Symantec Produkten durch das Project Zero

‚Today we’re publishing details of multiple critical vulnerabilities that we discovered, including many wormable remote code execution flaws‘

aus How to Compromise the Enterprise Endpoint vom 26. Juni 2016

Nicht mehr ganz taufrisch die Meldung, aber man bekommt nicht jeden Tag eine Beschreibung von wormable remote code execution flaws prÀsentiert, also von Fehlern, die Schadcode von fern ausnutzen und zur selbststÀndigen Weiterverbreitung auf andere Systeme verwenden kann.

gitter

Und wieder ist es Tavis Ormandy von Google’s Project Zero, der sich ein ‚Sicherheitsprodukt‘ vorgenommen hat und gruselige Dinge entdeckt: Dieses Mal ist das komplette Produktportfolio von Symantec betroffen (bzw. die Endverbrauchermarke ‚Norton‘).

‚Because Symantec uses a filter driver to intercept all system I/O, just emailing a file to a victim or sending them a link to an exploit is enough to trigger it – the victim does not need to open the file or interact with it in anyway.‘

Wie schon bei frĂŒheren FĂ€llen ist es wieder die Mischung aus den tiefgreifenden Rechten, die sich solche ‚Sicherheitslösungen‘ in den von ihnen ‚geschĂŒtzten‘ Systemen nehmen, der KomplexitĂ€t der dabei zu bewĂ€ltigenden Aufgaben und eines mangelhaften QualitĂ€tsmanagements, welches eine durchschlagende Wirkung erzeugt. Hier so durchschlagend, dass es einem Angreifer damit möglich gewesen sein sollte ein komplettes Unternehmensnetzwerk zu unterwandern. Und zwar nur, weil dieses Netzwerk mit zusĂ€tzlicher ‚Sicherheitssoftware‘ gesichert werden sollte.

Eine Frage der AbwÀgung

Dementsprechend ist diesem Fazit von Ormandy nicht viel hinzuzufĂŒgen:

‚Network administrators should keep scenarios like this in mind when deciding to deploy Antivirus, it’s a significant tradeoff in terms of increasing attack surface.‘

Bei privaten Nutzern ist die Frage ob man eine zusĂ€tzliche Sicherheitslösung verwendet gerade unter Windows heute noch schwieriger zu entscheiden. Ich selbst verwende keine entsprechende Software mehr, meine ChromeOS GerĂ€te haben das sowieso nicht nötig und unter Windows reicht mir der von Microsoft kommende ‚Defender‘.

Bei technisch nicht so versierten Nutzern kann so eine Software vielleicht trotzdem einen gewissen Schutz bieten, zumindest wenn diese eMaildienste verwenden, die nicht ausreichend in der Lage sind ihre Nutzer vor schĂ€dlichen AnhĂ€ngen zu schĂŒtzen, die immer noch ein wesentlicher Verbreitungsweg sind.

Auf der anderen Seite habe ich ein frisches Erlebnis mit dem Kaspersky Produkt, welches sich bei Bekannten als extrem ĂŒbergriffig und nervig erwiesen hat: Nachdem die Lizenz ausgelaufen war fing diese Software an die Nutzer beim Aufruf von GMail mit einer kaum wegklickbaren, permanent PiepsgerĂ€uche produzierenden und sich ĂŒber den Browser legenden Warnung zu nerven, wonach sie ’nicht mehr geschĂŒtzt‘ seien. Offenbar hĂ€lt man es bei Kaspersky in so einem Fall fĂŒr den besten Schutz die Nutzer gleich ganz von Nutzung ihres eMailkontos auszuschließen.

Und warum man ausgerechnet Kaspersky brauchen sollte um sein GMail Konto zu sichern und worin die konkrete GefĂ€hrdung besteht ist dabei natĂŒrlich nicht weiter begrĂŒndet worden. Eine der ersten Handlungen an diesem Rechner war es daher die entsprechende Erweiterung aus dem Chrome Browser zu entfernen.

Da sich die Bekannten auf Grund der Störungen durch die Kaspersky Software schon dazu hatten bringen lassen eine Lizenz zu kaufen habe ich das Produkt erst einmal auf dem Rechner gelassen. Allerdings gab es dazu ein paar Tage spĂ€ter die RĂŒckmeldung, dass nun auch beim eBay Zugriff plötzlich irgendeine störende Meldung erschien, die eine ’sichere Bezahlung‘ ĂŒber Kaspersky abwickeln wollte.

Wenn ich das nĂ€chste Mal dort bin, dann ziehe ich Kaspersky endgĂŒltig den Stecker….

Bericht der taz Redaktion ĂŒber einen dort erlebten Keylogger-Angriff

‚Es ist wohl reiner Zufall, dass der Keylogger am Ende entdeckt wird. Mindestens ein Jahr lang ist er zuvor im Einsatz‘

In diesem Artikel arbeitet die taz den Anfang letzten Jahres erfolgten Fund eines Keyloggers in der Redaktion umfangreich auf. Das ist aus mehreren GrĂŒnden sehr interessant, da es sich nicht nur um eine nochmalige Aufarbeitung des Ablaufs der Ereignisse und der internen Diskussionen, die sich darum entwickelten, handelt:

Was ist ein Keylogger?

Es geht zuerst um die Frage was eigentlich ein Keylogger ist (also ein Keylogger GerĂ€t und nicht eine Software) und wie man sich dagegen schĂŒtzt. Leider ist das aber ein Angriff, der zum einen von jedem ‚Idioten‘ ausgefĂŒhrt werden kann, da er keinerlei IT Knowhow erfordert. Zum anderen ist er schwer zu entdecken, da man sich schon einen betroffenen PC vor Ort sehr genau ansehen muss, damit einem so etwas auffĂ€llt. Auch hier ist der Fund nur zufĂ€llig erfolgt.

pc_von_hinten

Und schließlich ist es schwierig so einen Angriff in Zukunft zu verhindern. Der in dem Text mehrfach auftauchende Rat doch die USB Buchsen zu versiegeln oder abzuschalten geht meiner Meinung dabei in die falsche Richtung: Das Keylogger GerĂ€t wird ja zwischen Tastatur und PC gehĂ€ngt, und fĂŒr die Tastatur muss ja nun irgendeine Buchse freibleiben.

Wie kann man seine Nutzer schĂŒtzen?

Als IT Abteilung kann man eigentlich nur diese Dinge tun:

  • Möglichst viele Dienste auf eine 2-Faktor-Anmeldung umstellen. So kann ein gestohlener Zugang nicht genutzt werden
  • Ein Notlösung ist das Angebot das Passwort per Mausklick (virtuelle Tastatur) eingeben zu lassen. Allerdings werden die meisten Nutzer das hassen
  • StĂ€rkeres Monitoring von LoginvorgĂ€ngen und BenutzeraktivitĂ€ten durchfĂŒhren um so auf ungewöhnliche VorgĂ€nge aufmerksam zu werden. Das ist ein gutes Mittel, wie die in der taz nachtrĂ€glich durchgefĂŒhrten Auswertungen zeigen, aber auch komplex und hĂ€ufig sicher schwer mit dem Personalrecht zu vereinbaren
  • Bevorzugte Verwendung von GerĂ€ten ohne externe Tastatur (Laptop). Das schĂŒtzt zumindest vor ganz einfachen Angriffen
  • Die Rechte der Nutzer auf den GerĂ€ten wenn möglich einschrĂ€nken, damit nach dem Angriff per Keylogger Hardware nicht anschließend auch noch Schadsoftware installiert wird
  • RegelmĂ€ĂŸige Sichtkontrolle aller GerĂ€te (wozu natĂŒrlich niemand Zeit hat, aber vielleicht reicht schon die Drohung um einige Angreifer abzuschrecken)

Der Zwang sehr komplexe Passworte und damit einen Passwortmanager zu nutzen kann hingegen kontraproduktiv sein, da das Passwort des Passwortmanagers ggf. auch vom Keylogger mitgeschnitten wird und so alle Passworte verloren sind.

Man sieht: Ein extrem simples Mittel (50€ GerĂ€t) kann einen enormen Aufwand verursachen.

Wie kann man sich selbst schĂŒtzen

Als Nutzer von IT Systemen kann man ggf. weitere Dinge tun, um sich zumindest teilweise zu schĂŒtzen:

  • Den Rechner am Arbeitsplatz als faktisch ‚fremden‘ Rechner behandeln, Ă€hnlich wie man es in einem Internetcafe tun sollte. Und z. B. keine privaten Dinge auf dem Rechner tun, damit ein Angriff ggf. ’nur‘ die Firmenkonten betrifft. Ein Angreifer, der wie hier offenbar im wesentlichen private GrĂŒnde hat, wird dann vielleicht schnell das Interesse verlieren
  • Ggf. selbst Sichtkontrollen durchfĂŒhren, dazu z. B. die AnschlĂŒsse von Tastatur und Maus auf die Vorderseite des GerĂ€tes legen
  • Falls es die eigene IT Abteilung nicht schafft eine 2-Faktor-Anmeldung fĂŒr wichtige Accounts einzufĂŒhren kann man sich ggf. so behelfen, dass man einen YubiKey oder Ă€hnliches verwendet, auf dem man den grĂ¶ĂŸeren Teil eines sehr komplexen Passworts speichert, welches man dann unter Umgehung der normalen Tastatur in den Rechner schickt. Ggf. gibt man die letzten X Zeichen des Passworts selbst ĂŒber die normale Tastatur ein, damit ein Finder / Dieb des Keys nicht gleich den vollen Zugriff hat

GrundsĂ€tzlich gilt: Wer einmal einen solchen Angriff erlebt hat, der wird schwerlich Grenzen fĂŒr die eigene Paranoia finden und seinem Rechner nie mehr so vertrauen, wie er es vielleicht zuvor getan hat.

Wie arbeitet man so einen Fund auf?

Interessant ist dann auch die Beschreibung wie mit dem Fund des Keyloggers umgegangen wurde: Angefangen von der erfolgreichen Fallenstellung bis hin zum Sichern, Interpretieren und Aufbereiten der digitalen Beweise. Das man hier erfinderisch und technisch fit sein muss ist dabei der eine Teil, der andere ist es als IT Abteilung eine möglichst nicht anzweifelbare Kette von Indizien zu produzieren, die dann sowohl bei der internen Aufarbeitung wie auch bei der externen Bearbeitung etwa durch die Strafverfolgungsbehörden nicht gleich in sich zusammenfĂ€llt und sowohl einen selbst wie auch die grĂ¶ĂŸten Zweifler ĂŒberzeugt. Auch das scheint hier gut gelungen zu sein.

Was wenn es ein InnentÀter ist?

Und schließlich gibt es noch die menschliche Komponente, wenn wie hier ein (grĂ¶ĂŸtenteils) geschĂ€tzter Kollege sich plötzlich als jemand entpuppt, der einen offenbar in großem Stil hintergangen und aus weiterhin unklaren Motiven großflĂ€chig ausspioniert hat. Und der dabei so gar nicht dem ĂŒblichen Cliche des ‚Hackers‘ entspricht.

Es spricht finde ich dabei fĂŒr die Offenheit der taz, dass man sich der Hypothese stellt, dass der TĂ€ter vielleicht irgendeinem Übel innerhalb der Redaktion auf der Spur war. Aber letztlich bleibt aus meiner Sicht nur die Tatsache, dass hier jemand gegen jede ĂŒbliche Norm des zwischenmenschlichen Umgangs verstoßen hat, und dabei offenbar letztlich im wesentlichen die Motive eines Stalkers hatte.

Kleines Pwn2Own Fazit – Lehren fĂŒr Sicherheit im Webbrowser

In dieser Woche hat sich der jÀhrliche Pwn2Own Wettbewerb ereignet, bei dem es schon seit einigen Jahren darum geht aktuelle Browser und Betriebssysteme (und dieses Jahr erstmalig auch VMs) zu hacken.

Einige Änderungen hat es in den letzten Jahren gegeben: Bekam der erfolgreiche Hacker zunĂ€chst nur das gehackte (‚pwn‘) GerĂ€t geschenkt (‚own‘), so sind die insgesamt ausgeschĂŒtteten Preisgelder inzwischen in den 6-stelligen Bereich gegangen.

Sie vollziehen damit den Trend nach, den man allgemein beobachten kann: SicherheitslĂŒcken sind ein wertvolles Gut geworden, welches sich bei staatlichen Abnehmern bzw. den sie versorgenden Spezialisten wie VUPEN oder HackingTeam fĂŒr gutes Geld verkaufen lĂ€sst. Google, Mircosoft etc. haben daher auch die PrĂ€mien ihrer Bug Bounty Programme immer weiter angezogen.

Eine andere Änderung betrifft den Ausrichter, der nun zu Trend Micro gehört. Da die angetretenen Hacker ebenfalls zu großen Teilen zu auf IT Sicherheit spezialisierten Unternehmen gehören ist der Wettbewerb wohl noch stĂ€rker zu so etwas wie einem kleinen Familientreffen der Sicherheitsindustrie geworden.

Aber nun zu den Ergebnissen:

Chrome zeigt sich als ’sicherster‘ Browser

Von den Browsern, die die Ausrichter als Ziele genannt haben, sind alle gefallen, auch Chrome. Warum kann man Chrome trotzdem als den sichersten Browser bezeichnen? Weil eine Kombination von 4 Fehlern notwendig war, um ihn zu Fall zu bringen, davon 2 in Flash und einer im Windows Kernel. Der verbleibende Chrome Fehler war Google schon zuvor von anderer Stelle gemeldet worden, daher bekamen die Hacker nur einen Teil der Punkte fĂŒr diesen Erfolg. Insgesamt zeigt dies wohl die große Robustheit, die Chromes Sandbox erreicht hat.

bugs
Ein Bug bleibt selten allein

Warum setze ist das ’sicherster‘ oben dann trotzdem in AnfĂŒhrungszeichen? Weil Sicherheit kein Zustand ist, sondern ein Prozess, der sich immer weiterentwickelt und morgen schon wieder anders aussehen kann. Da allerdings Google das Thema Sicherheit in Chrome in den letzten Jahren immer aggressiv verfolgt hat, kann man erst einmal davon ausgehen, dass man mit Chrome auf der sicheren Seite ist und bleibt.

Auch Microsofts Edge Browser schlĂ€gt sich offenbar viel, viel besser, als es frĂŒher dem IE gelang. Anscheinend bringt der Abschied von der alten Codebasis in dieser Hinsicht einiges.

‚Mozilla’s Firefox browser was intentionally dropped from the competition due to its complete lack of a sandbox, a critical security feature which raises the bar for exploitation.‘

Traurig ist hingegen der Stand von Firefox: Zwar ist der freie Webbrowser nach StatCounter immer noch knapp der weltweit zweithĂ€ufigst verwendete Browser, aber in Kreisen ernstzunehmender Hacker wird seine Überwindung anscheinend als so lĂ€cherlich einfach angesehen, dass man damit keine Anerkennung ernten kann. Man kann wohl eigentlich niemandem mehr raten Firefox zu nutzen, jedenfalls nicht, wenn man auf Sicherheit achtet.

Flash: GefÀhrlich und zunehmend unnötig

Ein alter Bekannter in Bezug auf Sicherheitsprobleme im Webbrowser ist natĂŒrlich das Flash Plugin, welches ja schon beim Chrome Hack eine Rolle spielte und in dem noch weiteren LĂŒcken demonstriert wurden.

Ich habe meinen Chrome Browser schon vor einiger Zeit bei der PluginausfĂŒhrung auf ‚Click to play‚ umgestellt, so dass Plugins erst gestartet werden, wenn ich es explizit will. Damit ist man auf diesem Wege deutlich weniger verwundbar.

Nach meiner Erfahrung nimmt die Zahl der Flash Einbindungen im Web – zumindest in dem Teil, in dem ich mich bewege – rasch ab. Es ist glaube ich schon Wochen her, dass ich einmal einen Inhalt unbedingt sehen wollte, der nur ĂŒber Flash erhaltbar war.

Neues Angriffsziel: Die Betriebssystemkerne

Ein interessanter – und besorgniserregender – Trend bei diesem Pwn2Own Wettbewerb war die Konzentration der Hacker auf Fehler in den Betriebssystemen, an Stelle von Fehlern in den Browsern. Dies mag der Tatsache geschuldet sein, dass die Browser in Sicherheitshinsicht stark aufgerĂŒstet haben und die Hacker nun zuerst an anderen Stellen suchen, wo sie einfacher Erfolg haben. Eine Folge davon war dann, dass die erfolgreichen Exploits gleich Systemrechte erlangen konnten, also quasi allmĂ€chtig sind im kompromittierten System.

Das kann man als Argument nehmen, dass der grundlegende Ansatz von Googles ChromeOS zumindest nicht falsch ist, nĂ€mlich das ein Betriebssystem eher weniger können sollte und dafĂŒr besser gehĂ€rtet werden kann.

Wer sich die beiden Tage des Wettbewerbs in Filmform ansehen möchte, der findet das hier:

http://ingoogle.com/pwn2own-2016-windows-os-x-chrome-edge-safari-all-hacked/