min. 4 schwere Schwachstellen im HTTP/2 Protokoll

Sicherheitsforscher haben auf der Black Hat Conference 4 neue Angriffe gegen die serverseitigen Implementierungen des HTTP/2 Protokolls vorgestellt.

HTTP/2 soll das Netz beschleunigen, weil man mehrere Webseiten über eine bestehende Verbindung abrufen kann. Da Overhead durch ständiges Auf- und Abbauen von Verbindungen wird so vermieden. Das Problem, genau das führt jetzt zu neuen Angriffen, welche die neuen Mechanismen in einer schadhaften Weise gebrauchen. Dabei sind Angriffe möglich, die im HTTP/1.1 schon funktioniert haben, und im HTTP/2 nicht schon im Keim erstickt wurden.

Ob man dazu allerdings die Slow Read Attacke (CVE-2016-1546) zählen kann, bei der nur jeweils 1 Byte von einer Ressource angefragt wird und so legitimer Traffic vorgetäuscht wird, weiß ich allerdings nicht. Machbar ist sie jedenfalls.

Schon sehr viel spannender, die HPACK Bombe (CVE-2016-1544, CVE-2016-2525) : Dabei schickt der Client extrem komprimierte Header im Request mit, die beim Server ein Out-Of-Memory auslösen und damit ggf. einen DOS oder sogar einen Crash verursachen.  Das Ganze funktioniert nach dem ZIP-Bombenprinzip. Dabei wird aus einer unscheinbaren kleinen Datei GB an unkomprimierten Daten. Das stellt man sich als Laie so vor, daß der Kompressionsalgorithmus so funktioniert:  „AAABBBBBCCCCCCDDDDD“ wird zu 3A5B6C4D, was deutlich kürzer ist. Wenn man jetzt 1000000000A schreibt, ist das extrem kurz, wäre nach dem Auspacken aber 1 Milliarde Byte groß ( was fast, aber eben nur fast, ein GB ist 😉 ) . Hat man nun mehrere dieser Header und mehrere dieser Anweisungen muß der Server schon mehrere GB RAM aufwenden, was er nicht machen können wird, wenn das mehrfach an den Server geschickt wird. Dazu kommt dann noch die CPU Belastung durch die unnützen Dekomprimierungen.

Die Dependency Cycle Attack (CVE-2015-8659) erlaubt es dem Angreifer, die im HTTP/2 vorgesehenen Netzwerkoptimierungen zu beeinflussen und in eine Endlosschleife zu zwingen. Da es auch zum Crash kommen kann, ist es hier durchaus möglich, das der Angreifer so Code auf dem Server zur Ausfnührung bringen kann.

Die Stream Multiplexing Abuse (CVE-2016-0150)  erlaubt es dann dem Angreifer in ähnlicherweise die Datenströme der Verbindungen im Server so durcheinander zu bringen, daß  dieser abstürzt.

In aktuellen HTTP/2 Implementierungen sind diese Fehler auf  allen gängigen Webserver behoben worden, aber wer sowas wie die HPACK Bomb beim Planen seines Protokolls nicht berücksichtigt, der baut da auch unwissentlich noch mehr Designfehler ein. Wir dürfen uns also darauf freuen, an der Front in Zukunft noch einiges an originellen Angriffen erleben zu dürfen.

Diagramme und weitere Infos gibt es im Link unten.

Quelle: thehackernews.com

Tracking über Browser API des Batteriestatuses

Wie die Webseite TheHackernews.com heute berichtet, ist es Forschern der Standford University bereits in 2015 gelungen, einen Super-Super-Cookie zu nutzen, in dem sie über die Browser API der mobilen Versionen von Chrome, Opera und Firefox den Batteriestatus abgefragt haben. Durch die Kombination von angezeigter „verbleibender Zeit in Sekunden“ und dem Prozentwert der Ladung, ergeben sich bis zu 14 Millionen Kombinationen, die man Geräten zu ordnen kann.

Steve Engelhard and Arvind Narayanan von der Princeton University, konnten nun in einem Forschungsbericht  zeigen, daß diese Technik bereits von Webseiten zum aktiven Tracken von Benutzern eingesetzt wird.

Zusammen mit anderen Techniken wird es damit immer schwerer dem Online-Tracking zu entgehen. Aber natürlich kann man etwas dagegen tun, denn auch für FireFox Mobile gibt es Noscript!  Ohne Javascript kann man Browser-Api’s nicht abfragen, was dazu führt, daß man nur ohne Javascript surfen muß.

Sollte man jetzt glauben, den Webseitenbetreibern ginge nur ums das reine Tracking dabei, weit gefehlt, daß ist nur zur Verbesserung der Identifikationsrate da, denn Tracking geht über sehr viele Browsermerkmale bereits gut ( mit Javascript).

Den Batteriestatus zu kennen, verleitet Verkäufer jetzt aber dazu, abhängig vom Stand die Preise zu ändern. Der Gedanke: „Der User ist unter Stress, weil seine Batterie bald schlapp macht und daher kauft er jetzt sofort das Erstbeste zum erstbesten Preis. Suchen bei der Konkurrenz kommen wegen des Batteriestandes nicht mehr in Frage. “

Damit könnte der Verkäufer sogar recht haben. Also, was heißt das ? Bei FireFox Javascript abschalten und gleichzeitig eine neue Kampagne starten, diese API zu begraben! Das man Chrome dazu bewegen kann, ist eher unwahrscheinlich. Google lebt ja vom Tracking anderer Leute 😉

Referenzen:

INRIA Privatics Forschungsbericht
Lukas Olejnik Blog
Random Walker – OpenWPM

Quelle: thehackernews.com

Telegram: API Mißbrauch verrät Nutzung

15 Millionen Datensätze von Iranischen Telefonnutzern sind bei einem großangelegten Mißbrauch der App Telegram „verifiziert“ worden. Konkret hatten Hacker Telefonnummern Accounts zugeordnet und so geprüft, ob diese Nummer schon bei Telegram registriert ist. Dazu nutzten Sie die SMS Benachrichtigungsfunktion für neu hinzugefügte Nummern, was bedeutet, daß die SMS Verfikationen abgefangen wurden. Einige vermuten auch einen staatlichen „Checkup“ weil nur iranische Accounts betroffen sind.

Telegram wird u.a. im Iran  gern genutzt, weil Kommunikationsdaten nur verschlüsselt auf dem Telefon übertragen werden.

Quelle: slashdot.org