Sie sind an Cloud Computing interessiert? Legen Sie jetzt los

Dark background with blue code overlay

Erkennen von schädlichem JavaScript mit Secure Internet Access Enterprise Secure Web Gateway

Verfasser

Jordan Garzon

May 13, 2022

Verfasser

Jordan Garzon

Verfasst von: Jordan Garzon

Einführung 

Stellen Sie sich eine Welt ohne JavaScript vor. Ich weiß gar nicht, wie oft meine Kollegen und ich im Laufe unserer Karriere schon darüber nachgedacht haben. Im Moment ist eine Welt ohne JavaScript nur schwer vorstellbar. Da ich in einem Unternehmen arbeite, das sich bereits seit einigen Jahren mit JavaScript beschäftigt, bin ich mir den Herausforderungen bewusst und weiß genau, wie verbreitet es in unserer Branche ist. JavaScript-Schutz bleibt ein wichtiger Teil unserer Mission, ob es uns gefällt oder nicht. 

JavaScript ist überall. Bei jeder Anfrage an eine Website oder App werden Dutzende von Zeilen an JavaScript-Code geladen; jeder Browser unterstützt JavaScript. Es ist so allgegenwärtig, dass es leicht als unerlässliche Technologie bezeichnet werden könnte – als Technologie, die bestimmt, wie Websites aufgebaut werden und funktionieren. Und wie wir alle wissen, gilt in puncto Sicherheit: Je wichtiger eine Technologie ist, desto mehr Möglichkeiten gibt es auch, sie böswillig einzusetzen.

Da JavaScript so allgegenwärtig ist, bietet seine gezielte Nutzung Angreifern die Möglichkeit, durch Missbrauch der riesigen Angriffsfläche, die JavaScript bietet, erheblichen Schaden anzurichten. Die potenzielle Auswirkung eines großen Vektors wurde durch die Log4j- Sicherheitslücke aufgezeigt – ein Angriffsvektor, der sofort umfassend ausgenutzt werden konnte. Log4j, eine Java-Bibliothek, bietet Protokollierungsfunktionen – eine grundlegende Funktion, die fast alle Entwickler verwenden. Das ist der Unterschied zwischen JavaScript-Schwachstellen und anderen Schwachstellen: Die enorme Präsenz von JavaScript im Produktionscode. 

Vor diesem Hintergrund stellen wir uns natürlich die Frage: „Was können wir also tun?“ Nachdem wir die Auswirkungen von Log4j gesehen hatten, wollten wir eine endgültige Antwort auf diese Frage finden und leiteten eine Untersuchung in die Wege, um schädliches JavaScript besser zu erkennen und zu verstehen . Dies führte zu dem Projekt, über das ich heute schreibe. Sicherheitsforschung ist immer unterhaltsam, und als unsere Theorie funktionierte, gingen wir einen Schritt weiter und testeten einige reale Kontextsituationen. 

In diesem Blogbeitrag möchte ich Ihnen unsere Untersuchung und die Techniken erläutern, die wir zur Identifizierung und Isolierung von schädlichem JavaScript verwendeten, um eine neue Produktfunktion aufzubauen. Der Beitrag umfasst eine Betrachtung JavaScript-bezogener Bedrohungen, einschließlich der Systemarchitektur, angewandte Algorithmen und eine Fallstudie. 

Schädliches JavaScript: die Bedrohungslage

Bevor wir uns mit dem eigentlichen Projekt beschäftigen, werfen wir einen Blick auf die Lage, die schädliches JavaScript zu solch einem bemerkenswerten Bedrohungsvektor macht. Ich habe bereits seine Verbreitung erwähnt, aber wie groß ist das Ausmaß wirklich? Dieser Faktor macht die Bedeutung des Projekts eindrucksvoll deutlich. Nachfolgend sind einige der häufigsten Angriffe aufgeführt, die JavaScript verwenden.

Browser-Exploit 

Ich muss Ihnen nicht erzählen, wie groß diese Bedrohung ist – Browser und Browser-Plugins sind ein Schlüsselelement jedes Computers. Ein gutes Beispiel findet sich in Form des Browser Exploitation Framework-Projekts, auch bekannt als BeEF. BeEF ist ein Penetrationstest-Tool, das sich auf Webbrowser konzentriert – einer der größten clientseitigen Angriffsvektoren – und das die Ausnutzbarkeit von JavaScript recht gut beleuchtet. 

Skimmer 

Skimmer sind ein prominentes Beispiel dafür, wie Cybersicherheit auch das persönliche Leben außerhalb der Unternehmenswelt beeinflussen kann. Da JavaScript das Document Object Model steuert, kann es nicht nur den generierten HTML-Code, sondern auch die zugrundeliegenden HTTP-Anfragen ändern. Das zeigt sich schon bei einer einfachen Aktion wie dem Anklicken einer Schaltfläche durch den Nutzer. 

Ein Beispiel aus der Praxis kann auf jeder Website gefunden werden, die E-Commerce anbietet. Wenn schädliches JavaScript in eine gutartige Website injiziert wird, können alle vom Skimmer erfassten Kreditkartendaten an den Angreifer weitergeleitet werden. Der bekannteste Fall war der Magecart-Angriff von 2018 auf der Website der British Airways, bei dem ca. 380.000 Kreditkartennummern gestohlen wurden. 

Skimming hat sich seit 2018 verändert. Heute wird diese Technik häufig verwendet, indem Bitcoin-Adressen auf gutartigen Websites durch die Adresse des Angreifers ersetzt werden. Dies konnten wir in den letzten Jahren bei der Lazarus-Gruppe beobachten. 

Clickjacking 

Eine gutartige Website ermöglicht zwar eine umfassende Verbreitung, ist aber in der Reichweite im Vergleich zu einem Server, über den volle Kontrolle ausgeübt wird, immer noch begrenzt. Wenn der Angreifer den Nutzer zu ihm locken kann, hat er einen Heimvorteil. Denn so hat der Angreifer viel mehr Einfluss. Sobald die Opfer in seinem Revier landen, kann der Angreifer sie dazu bringen, Malware herunterzuladen oder viele andere schädliche Aktivitäten auszuführen. Zudem kann er Informationen aus ihrer Browsersitzung abrufen.

Eine klassische Methode besteht darin, einen transparenten über einem legitimen iFrame zu erstellen, um dem Nutzer ein falsches Gefühl der Sicherheit vermittelt, wenn er darauf klickt. Dieser iFrame leitet den Nutzer dann auf den vom Angreifer kontrollierten Server um, wo unzählige schädliche Aktivitäten ausgeführt werden können.

Unbefugtes Kryptomining 

Mit dem wachsenden Trend zu Kryptowährungen hat auch das Kryptomining in den letzten Jahren viel Aufmerksamkeit bekommen. Warum nicht die CPU des Nutzers verwenden, um Kryptowährungen zu minen? Insbesondere wenn nur eine Zeile JavaScript dafür benötigt wird. Die berühmteste Bibliothek in diesem Bereich war Coinhive, die 2019 offline ging, aber seitdem natürlich durch andere wie beispielsweise CoinIMP oder CryptoLOOT.

Engine zur Erkennung von schädlichem JavaScript – Architektur und Algorithmen 

Jetzt, da ich Sie durch die aktuelle Bedrohungslage geführt habe, wollen wir uns dem eigentlichen Projekt widmen. JavaScript kann auf zwei Arten in eine Website eingefügt werden: Durch Schreiben einer JavaScript-Datei auf demselben Server oder durch Verwenden einer vorhandenen JavaScript-Datei aus einer anderen Quelle, deren Link in die HTML-Seite eingefügt wird. Auf der Proxy-Seite sehen wir dann zwei unterschiedliche HTTP-Anfragen, eine für die HTML und eine für die JavaScript-Datei. Wenn Sie eine Website aufrufen, kann Ihr Browser Hunderte von HTTP-Anfragen für die Darstellung dieser Website durchführen.

Der JavaScript-Code kann auch direkt innerhalb der HTML geschrieben werden. Dann sind keine weiteren Anfragen erforderlich, um ihn abzurufen. Bei der Erkennung von schädlichem JavaScript müssen diese beiden Methoden abgedeckt werden – und genau das haben wir geschafft.

Unsere neue Engine kann „Inline“-JavaScript-Codes extrahieren und separat scannen. Nachfolgend finden Sie einen Auszug der Quellseite der New York Times, die beide Arten von JavaScript aufweist:

Sonstige

Auszug aus dem HTML-Code der Website der New York Times(https://www.nytimes.com/)vom 2. Februar 2022

Das Akamai Secure Internet Access Enterprise Secure Web Gateway (SWG) von Akamai besteht aus verschiedenen Engines, die Traffic in Echtzeit scannen. Es ist außerdem mit unserer Threat Intelligence verbunden und wird durch kundenspezifische Algorithmen ergänzt.

Überblick über das Enterprise Threat Protector Secure Web Gateway High-level overview of the Enterprise Threat Protector secure web gateway

 

Werfen wir einen Blick auf das rote Feld „JS Models“ (JS-Modelle): 

Datenbank

Die Modelle basieren auf einer relationalen Datenbank, um Metadaten aufzubewahren und den tatsächlichen JavaScript-Code über einen Speicheranbieter zu speichern. 

Die Datenbank enthält ein Trainingsset, d. h. unsere vorklassifizierten Daten. Die gutartigen Daten stammen hauptsächlich von beliebtem JavaScript aus unserem Traffic. Die schädlichen Daten wurden aus verschiedenen Quellen bezogen: VirusTotal (VT), Erkennungen von anderen Algorithmen und Schadcode, den wir mit unserem eigenen Algorithmus erkennen. Die Datenbank wird daher ständig aktualisiert. 

In der DB ist auch das Testset enthalten, das im Grunde den Traffic enthält, den wir in den letzten Tagen über den Proxy bekommen haben.

Modell für Echtzeiterkennung

Um schädliches JavaScript in Echtzeit zu erkennen, verwenden wir YARA- Regeln, die wir auf der Edge bereitstellen. Diese Regeln werden basierend auf dem Trainingsset erstellt. Da die Erstellung von Regeln keine einfache Aufgabe ist, haben wir einen Algorithmus auf Basis dieses wissenschaftlichen Artikels erstellt, der automatisch Yara-Regeln generiert. Wir haben ihn angepasst, um JavaScript-Code anstelle von Binärcode zu klassifizieren, und haben die Logik der Regelgenerierung geändert, was bedeutet, dass wir die Engine für schädliches JavaScript auf dem SWG nach Bedarf aktualisieren können.

Beispiel für eine mit AutoYara generierte YARA-Regel Example of a YARA rule generated with AutoYara

Anreicherung von Bedrohungsinformationen durch maschinelles Lernen 

Ein bekanntes Problem, das Forscher beim Abfangen von JavaScript haben, ist die Verschleierung. Dabei handelt es sich um eine Technik (die auch von gutartigen Websites verwendet wird), die den Code verkleinert und damit in Kauderwelsch verwandelt. Or Katz hat im Oktober 2020 einen Blogbeitrag dazu geschrieben. 

Um verschleierte Codes erkennen zu können, haben wir unsere Logik in ein von JStap inspiriertes Modell integriert, das auf dem abstrakten Syntaxbaum ausgeführt wird, einer Baumdarstellung des Codes. So können wir diese Technik umgehen.

Maschinelles Lernen kann eine höhere Genauigkeit erzielen als YARA-Regeln dies können. Die Bereitstellung auf der Edge für Echtzeit-Scans ist jedoch eine Herausforderung. Am Ende haben wir uns für eine Mischung entschieden: Unser Modell wird mit dem gleiche Trainingsset trainiert, scannt den Traffic offline (in der Azure Machine Learning-Umgebung) und füllt die Threat Intelligence mit den Ergebnissen. 

Die Threat Intelligence wird bei jeder Verbindung mit dem SWG überprüft, sodass Kunden vom lernfähigen Erkennungsmodell profitieren. 

Das Modell in Aktion – eine Fallstudie

Das alles lässt sich am besten anhand eines realen Beispiels veranschaulichen. Am 8. März 2022 hat das lernfähige Modell JavaScript erkannt, das auf cigarettesblog[.]blogspot[.]com gehostet wird. 

Diese Domain zeigte am 10. März 2022 0 Erkennungen durch VT.

 

Homepage von cigarettesblog[.]blogspot[.]com am 9. März Home page of cigarettesblog[.]blogspot[.]com seen on March 9

Im folgenden Auszug ersetzt der JavaScript-Code alle HTML-Links durch schädliche URLs. 

Einer von ihnen (hxxps://myprintscreen[.]com/soft/myp0912.exe), der jetzt im Code kommentiert wurde, lädt einen Trojaner herunter (4a6ffa02ff7280e00cf722c4f2235f0e318e6cc8a2b99686ba715f1a38834), der 23 Erkennungen auf VT aufweist. Es gab einige andere URLs, die von vielen Anbietern auf VT als schädlich gekennzeichnet wurden.

Dies ist ein klassisches Verhalten von schädlichem JavaScript: Ersetzen von URLs auf den Websites, Senden von POST-Anfragen an andere Domänen (siehe Auszug unten) oder Durchführen eines Drive-by-Download-Angriffs, um Malware auf den Computer des Nutzers zu schleusen. 

 

JavaScript-Code, der am 9. März 2022 von cigarettesblog[.]blogspot[.]com extrahiert wurde JavaScript code extracted from cigarettesblog[.]blogspot[.]com on March 9, 2022

URLs:

myprintscreen[.]com/soft/myp0912.exe 

www[.]blog-hits.com

Filehash:

4a6ffa02ff7280e00cf722c4f2235f0e318e6cc8a2b9968639ba715f1a38c834 (Trojaner)

fc311d002d7139e0a58b00464731ba8d4faea4670cff9fedfb35057fe838c285 (JavaScript-Datei, von uns am 10. März hochgeladen)

Derselbe Mechanismus wurde auf penis-photo.blogspot[.]com.br (am 10. März), auf mateyhderesa[.]blogspot.com (am 13. März) und auf playboy-college-girls.blogspot.sk (14. März) erkannt.

Zusammenfassung

Wie ich bereits zu Beginn dieses Beitrags erwähnte, kann alles, was für Sicherheit wichtig ist, auch böswillig verwendet werden. Bei etwas, das so weit verbreitet ist wie JavaScript, kann das schwerwiegende Folgen haben. Es kann auch schwierig zu entschlüsseln sein; ein vorheriger Blogbeitrag zeigte, dass 25 % der Schadcodes verschleiert sind. Das ist kein unbedeutender Anteil und wenn wir bedenken, wie viel wir vom Internet sehen, ist er ziemlich repräsentativ für die Verbreitung dieses Problems.

Diese Studie begann als eine Möglichkeit, unseren Kunden mehr Sicherheit zu bieten. Daher haben wir das, was wir herausgefunden haben, in unser SWG aufgenommen. Wir haben zwei neue Modelle: YARA-basiert und auf maschinellem Lernen basiert. Das auf YARA-Regelsignaturen basierende Modell scannt jeden JavaScript-Code, der durch das SWG läuft, in Echtzeit. Das auf maschinellem Lernen basierende Modell überprüft den Traffic nochmal, um die Threat Intelligence an der Edge zu aktualisieren. Beide Modelle werden ständig aktualisiert und neu trainiert und berücksichtigen die neuesten Bedrohungen sowie das neue gutartige JavaScript, das aktuell im Web beobachtet wird. 



Verfasser

Jordan Garzon

May 13, 2022

Verfasser

Jordan Garzon