Reine Kopfsache : „Headless Chrome“ ist bei Entwicklern und Angreifern gleichermaßen beliebt

Der „Headless“-Mode ist eine Funktion, die es ermöglicht, eine Vollversion von Chrome laufen zu lassen und programmgesteuert zu betreiben. Dadurch lässt sich der Browser beispielsweise auch auf Servern ohne Grafikeinheit oder Display nutzen. Er arbeitet dann ohne das grafische Benutzerinterface (Graphical User Interface, GUI), also quasi ohne „Kopf“.

In diesem Modus lassen sich innerhalb von Chrome beispielsweise groß angelegte Web-ApplicationTests fahren – der Browser navigiert ohne menschlichen Eingriff zwischen Webseiten, JavascriptFunktionen werden bestätigt und Chrome generiert sogar selbstständig Reports. So etwas lässt sich allerdings auch böswillig ausnutzen, wenn ein Angreifer etwa nach Javascript sucht oder Browser-Funktionen emuliert werden sollen.

Dabei ist eine solche WebBrowser-Automatisierung an sich nicht neu: Sie wird bereits seit Längerem in dedizierten „Headless“- Browsern wie PhantomJS und NightmareJS, Test-Frameworks wie Capybara und Jasmin sowie in Werkzeugen zur Automatisierung unterschiedlicher Browser wie Selenium eingesetzt.

 Steigende Aktivität

Abbildung1 zeigt den Traffic, der durch Headless Chrome und weitere automatisierte Browser zwischen seinem Release im Juni 2017 und Juni 2018 generiert wurde. Klar erkennbar ist, dass Headless Chrome im letzten Jahr in den Traffic-Rankings am zuvor klar führenden HeadlessBrowser PhantomJS vorbeigezogen ist. Gleichzeitig ließ sich im gleichen Zeitraum beobachten, dass der Anteil am Gesamt-Traffic, der durch automatisierte Browser generiert wurde, stark angestiegen ist (vgl. Abb. 2).

Für die wachsende Beliebtheit von Headless Chrome gibt es verschiedene Gründe: Dazu gehört einerseits der Support für die neuen „Out of the Box“-Features von Chrome, die kontinuierlich neue Entwicklungen im Web-Development einführen. Ein weiterer Grund ist, dass alle wichtigen Betriebssysteme für Desktops, Server und mobile Endgeräte unterstützt werden. Andererseits bietet Headless Chrome darüber hinaus auch zahlreiche komfortable Werkzeuge für Entwickler an.

Like a Puppet on a String

Und nicht zuletzt war das (Beta-) Release von Puppeteer ein paar Monate nach dem ursprünglichen Headless-Release ein wichtiger Faktor für die hohe Beliebtheit von Headless Chrome: Puppeteer ist eine NodeJs-Library, die vom Chrome-Team entwickelt wurde und eine High-Level-Programmierschnittstelle (API) bereitstellt, um sowohl Headless- als auch Vollversionen von Chrome zu steuern (https://developers.google.com/web/tools/puppeteer/). Die erste „Stable Version“ wurde im Januar 2018 veröffentlicht.

Puppeteer ist mittlerweile eine gängige Methode, um Chrome zu kontrollieren. Es bietet vollumfänglichen Zugang zu sämtlichen Browserfunktionen und – was am wichtigsten ist – kann Chrome auch auf einem Remote-Server im vollen Headless-Modus laufen lassen. Diese Funktion ist sowohl für Automatisierungs-Teams als auch für böswillige Zwecke sehr nützlich. So können Angreifer beispielsweise ohne große Schwierigkeiten eine Infrastruktur aufsetzen, die aus einer Vielzahl von Nodes besteht, auf denen Headless Chrome läuft, und die sich von einer einzelnen zentralen Komponente (Puppeteer) steuern lässt. Unabhängig von Puppeteer kann man Chrome aber auch mithilfe von Webdriver- und Automatisierungs-Frameworks wie Selenium automatisieren oder mittels direkten Zugangs über die Kommandozeile nutzen. Hierbei sind zwar ein paar der Funktionen von Chrome eingeschränkt, das Command-LineInterface (CLI) bietet aber dennoch genügend Flexibilität, um Automatisierungen in beinahe beliebigen Programmiersprachen einzubinden, nicht nur in NodeJS und Javascript.

Zwei einfache Beispiele für Kommandozeilenbefehle an Headless Chrome sind etwa zur Erstellung eines Screenshots

chrome –headless –disable-gpu –screenshot –window-size=1920,1080 https://www.kes.info/

oder zur Abfrage des DocumentObject-Model (DOM) einer Website

chrome –headless –disable-gpu –dump-dom https://www.imperva.com/

Bis vor kurzem war auch in Sachen bösartiger Aktivitäten PhantomJS der führende automatisierte Browser – auch hier hat jedoch Chrome mittlerweile klar den „Angreifer-Spitzenplatz“ erobert, wobei jeweils rund die Hälfte des Traffics auf Headless- und Non-HeadlessAusführungen entfällt (vgl. Abb. 3)

Kopflos ins Verderben

Bei genauerer Betrachtung des bösartigen Traffics sind zwar keine spezifischen Trends erkennbar, die eine Bevorzugung von Headless Chrome durch Angreifer für spezielle Techniken wie Cross-Site-Scripting (XSS), SQL-Injection oder zur Ausnutzung von Exploits erkennen lassen. Dennoch zeigen sich gelegentliche Ausschläge, die Versuche gezielter Angriffe auf spezifische Seiten darstellen – beispielsweise mittels Vulnerability-Scannern oder der Ausnutzung neu veröffentlichter Schwachstellen mithilfe der sogenannten „Spray and Pray“-Technik, sprich einer Art ungezieltem, breit gestreutem „Dauerfeuer“ in der Hoffnung, dabei zufällig auch das eine oder andere spannende Ziel zu treffen.

Die Suche nach Schwachstellen per Browser ist dabei zwar auch nicht wirklich neu, aber durchaus raffiniert: Denn sie kann dabei helfen, einige Validierungsmechanismen zu umgehen, die auf Legitimationsprüfungen des Clients basieren. Abbildung 4 zeigt eine Statistik von Angriffen mithilfe von Headless Chrome, die sich im vorigen Jahr in Web-Application-Firewall-(WAF)- Events von Imperva niedergeschlagen haben.

Betrachtet man den Traffic des vergangenen Jahres, so findet man keine Distributed-Denial-ofService-(DDoS)-Attacken, die von Botnetzen auf Headless-Chrome-Basis ausgingen. Dies ist aber eigentlich auch nicht besonders verwunderlich, denn im Allgemeinen werden automatisierte Browser, besonders Headless Chrome, eher selten für DDoS-Angriffe genutzt. Der Hauptgrund hierfür ist die niedrige RequestRate an die Server, welche solche Browser generieren können. Gerade Chrome kann immer erst dann den nächsten Request abschicken, wenn die vorausgegangene Serverantwort verarbeitet wurde. Daher ist die Rate im Vergleich zu einfachen Scripts, die einfach ein Request nach dem anderen abfeuern, ohne sich um die Antworten zu kümmern, extrem niedrig.

Nichtsdestotrotz lassen sich tagtäglich über 10 000 einzigartige IP-Adressen beobachten, die bösartige Aktivitäten wie Scraping, Sniping, Carding oder Blackhat-SEO betreiben, bei denen eine JavascriptPrüfung notwendig ist, um sie durchzuführen.

Korrekter Kopfball

Headless Chrome wird aber nicht nur von Angreifern genutzt, sondern auch von verschiedenen legitimen Diensten. So gibt es Dutzende bekannter Web-Tools, die auf den Browser setzen, um auf Websites zuzugreifen – einige ihrer Einsatzzwecke:

• Suchmaschinen nutzen Headless Chrome, um Seiten zu rendern und dynamischen Content sowie Index-Daten aus Single-PageWeb-Applications zu generieren.
• SEO-Tools benutzen den Browser, um Websites zu analysieren und besser zu promoten.
• Monitoring-Tools setzen auf Headless Chrome, um die Leistung von Websites zu messen und die Javascript-Execution-Zeit von WebApplikationen zu prüfen
• Online-Test-Tools rendern Seiten und vergleichen sie mit vorherigen Versionen, um Regressionen oder Verzerrungen beim BenutzerInterface nachzuverfolgen.

Gegenmaßnahmen

Die Frage, ob man Headless Chrome und andere automatisierte Browser blockieren sollte oder nicht, ist dementsprechend nicht einfach zu beantworten. Die Antwort lautet: ja und nein. Der Einsatz von Headless Chrome als solches deutet ja nicht automatisch auf böse Absichten hin, wie die bereits beschriebenen vertrauenswürdigen Szenarien und Dienste zeigen, die für den WebsiteZugriff auf dieses Tool zurückgreifen.

Allerdings ist es ein großes Stück Arbeit, sämtliche legitimen Dienste auf eine Whitelist zu setzen. Daher sollte man die Entscheidung, Headless-Chrome-Anfragen zu blocken oder durchzulassen, möglichst immer im Einzelfall innerhalb eines „intelligenten“ Sicherheitssystems entscheiden – auf Grundlage der Absichten und des Verhaltens der jeweiligen IP- und Session-Daten. Solange eine Anfrage (bzw. Payload) nicht eindeutig bösartig ist, bleibt zunächst zu empfehlen, einzelne Anfragen an eine Website durchzulassen und das Verhalten weiter zu analysieren. Erst danach sollte eine Entscheidung fallen, ob geblockt werden soll oder nicht.

Um solche Entscheidungen zu treffen, lassen sich verschiedene Hilfsmittel und Informationen nutzen: etwa die Reputation einzelner IP-Adressen, ihre Korrelation mit anderen Erkenntnissen, fortschrittliche Heuristik oder Machine-LearningAlgorithmen. Dies führt auf lange Sicht in den meisten Fällen zu deutlich besseren Ergebnissen als eine aggressive Blockierstrategie.

Dima Bekerman ist Application-Security-Research-Manager bei Imperva.

Literatur

[1] Eric Bidelman, „Getting Started with Headless Chrome“, Google Developer Update, April 2017, https://developers.google.com/web/updates/2017/04/headless-chrome