Kategorie: IT Sicherheit

BoringSSL und die FIPS 140-2 Zertifizierung

ihbrune

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?

ihbrune

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

ihbrune

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

ihbrune

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

ihbrune

‚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

ihbrune

‚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

ihbrune

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/

Vortrag über 2-Faktor-Authentifizierung auf der DFN Betriebstagung

ihbrune

Wer sich für das Thema ‚2-Faktor-Authentifizierung (2FA)‘ interessiert: Ich habe auf der letzten DFN Betriebstagung einen Vortrag dazu gemacht, wie wir im Projekt BIS diese Funktion implementiert haben. Die Folien kann man jetzt auf der Tagungsseite herunterladen.

Findet sich im ‚AAI‘ Bereich und stellt daher auch Verknüpfungen zu Themen wie Identity Provider (IdP) bzw. Shibboleth her. Alternativ kann man die Folien hier im Google Drive aufrufen.

Google Authenticator App

Stichpunkte zum Vortrag

  1. Angriffe mit Identitätsdiebstählen sind heute unvermeidlich
  2. Herkömmliche Login-Formulare bieten keinen Schutz etwa gegen Attacken mit Keyloggern
  3. Einführung eines zusätzlichen Loginfaktors notwendig
  4. Entscheidung für das Time-based One-time Password (TOTP) Verfahren nach RFC 6238
  5. Implementierung von drei unterschiedlichen 2FA Verfahren
  6. Ein Identity Provider ist die ideale Stelle um diesen Aufwand zu treiben
  7. Wenigstens neu aufgesetzte Dienste sollten direkt mit einem Identity Provider geschützt werden

 

Datendiebstahl an der Uni Graz

ihbrune

An einer österreichischen Universität ist es zwischen Weihnachten und Neujahr zu einem Datendiebstahl gekommen. Man vermutet einen Innentäter, da der Täter bei der Veröffentlichung der Daten offenbar auch gegen einzelne Uni Mitarbeiter gepöbelt hat.

Die Erklärung eines Uni Mitarbeiters in dem verlinkten Radio Interview, wie die Daten gestohlen wurden und welche, ist ziemlich merkwürdig: Der Angreifer soll demnach ein ‚altes‘ Passwort verwendet und daher nur ‚alte‘ Daten erwischt haben.

Mir war bisher nicht klar, dass der Passwortstatus (‚alt‘ versus ‚aktuell‘) so einen Einfluss auf den damit möglichen Systemzugriff haben kann: Alte Passworte sollte ja eigentlich gar keinen Zugriff mehr ermöglichen. Oder gab es da ein schlecht gesichertes Backupsystem, welches eine alte Kopie von echten Daten irgendwo im Netz anbot?

In Zukunft massiver, finanzieller Schaden möglich?

Interessant ist auch der Verweis auf die kommende Datenschutzverordnung:

‚Wäre der Vorfall nach Inkrafttreten der neuen EU-Datenschutzverordnung im Frühjahr 2018 erfolgt, hätten der Uni Graz schwerwiegende Konsequenzen gedroht‘

Die meisten denken hier vermutlich an große US Konzerne, die man damit bei Datenlecks zur Kasse bitten könnte. Aber macht es Sinn von öffentlichen Einrichtungen wie hier (Steuer)Geld wieder einzusammeln? Oder rechtfertigt dieses Gesetz nun prophylaktische Investitionen der öffentlichen Hand in irgendwelche externen IT Auditierungen, zusätzliche Sicherheitsbeauftragte oder Versicherungen, die in solchen Fällen einspringen?

Leseempfehlung: ‚SPAM NATION‘ von Brian Krebs

ihbrune

Vor wenigen Tagen musste ich jemandem, der nicht viel jünger ist als ich, erklären was eigentlich Spam(mail) ist. Vielleicht ist das meine und Google’s Schuld: Ich hatte die Person schon vor langer Zeit mit einem GMail Account ausgestattet und Google’s Filter haben offenbar in all der Zeit den Posteingang frei von Spam gehalten.

Ist es wirklich schon so weit gekommen? Das nur noch wir ‚Älteren‘ uns an die Zeit erinnern, in der Spam eine echte Plage war und man beim morgendlichen Öffnen des Postfaches 90% gleich löschen konnte, weil es SPAM war? Oder ist mit dem Siegeszug der Messenger auf den Smartphones die E-Mail einfach unwichtiger geworden?

spam_nation_krebs

Egal. Meine letzte Weihnachtslektüre war für mich trotzdem sehr spannend, auch wenn die Ereignisse, die dort behandelt werden, nun schon einige Jahr her sind: Brian Krebs beschreibt hier mit sehr tiefgehenden Kenntnissen die Geschichte der Pharmawars, einer Auseinandersetzung zwischen zwei großen russischen Internetanbietern von (legalen und illegalen) Medikamenten, die insbesondere mit massiven Spamwellen beworben wurden.

Krebs beleuchtet dabei alle Teile des Spam/Pharma-Geschäfts. Das sind neben den Plattformbetreibern, den Spammern mit ihren riesigen Botnetzen und diversen anderen Akteuren dieser kriminellen Verbünde:

  • Die Käufer: Warum kaufen Leute eigentlich Medikamente bei Quellen, deren Zuverlässigkeit sie nicht kontrollieren können und wie zufrieden sind sie mit dem Service? Spoiler: Das Servicelevel dieser Dienste war offenbar ausgesprochen gut. Und die Leute, die auf die Links in Spam klicken, haben teilweise gute Gründe dazu, und sind nicht einfach ‚dumme Nutzer‘, zu denen sie die Nerds gerne erklären.
  • Die geschädigten Pharmakonzerne: Jeder kennt vermutlich Spam für Viagra / Cialis etc. Was machen eigentlich die betroffenen Konzerne, denen dadurch doch Gewinne entgehen müssten? Spoiler: Offenbar erstaunlich wenig. Denn was wäre, wenn sich herausstellt, dass die Plagiate der illegalen Shops viel billiger sind, aber chemisch nicht von den teuren Originalprodukten unterschieden werden können?
  • Die ‚Antis‘: Welche Kräfte gibt es, die sich – oft eher inoffiziell und im Schatten – der Spamflut entgegen stellen und in welchen Fällen wurden sie von den Spammern bezwungen. Spoiler: Microsoft hat in dieser Geschichte viel bewegt mit seiner hartnäckigen Verfolgung von Raubkopien, jedenfalls mehr, als die Pharmakonzerne.
  • Das russische ‚Rechtssystem‘: Interessant ist bei der detailgenauen Portraitierung der russischen Spammer und Plattformbetreiber das Umfeld, in dem sie sich bewegen (müssen). Ist das für Einflussnahmen anfällige russischen System zunächst eine Hilfe beim Aufbau der kriminellen Aktivitäten, werden diese ‚kleinen‘ Diebe später auch mal von den viel größeren Dieben im russischen Staat ausgenommen.

Brian Krebs hat dabei offenbar ungeheure Mühen bei der Auswertung von geleakten Chatlogs der Konfliktparteien aufgewendet und einen teilweise sehr persönlichen (zu persönlichen?) Kontakt zu einigen der Schlüsselfiguren aufgebaut. Auch ist er ob seiner Herkunft als Journalist – im Gegensatz zu vielen IT Leuten, die in diesen Bereich Texte produzieren – in der Lage echte Spannungsbögen zu produzieren und den roten Faden in diesem komplexen Thema nicht zu verlieren.

Und auch, wenn das Spamproblem heute reduziert scheint: Die gleichen Leute, die Botnetze für das Spamming aufgebaut haben, sind immer noch da und suchen neue Tätigkeitsfelder um die mit Pharmaverkäufen heute nicht mehr erzielbaren Einnahmen zu kompensieren.

Von mir daher 5 Sterne!