JavaScript może stać się warstwą ataku nawet wtedy, gdy sama strona wygląda prawidłowo.
Kod wykonywany bezpośrednio w przeglądarce użytkownika może mieć dostęp do zawartości strony (sitemap), wprowadzanych danych, informacji przechowywanych po stronie klienta a nawet komunikacji z zewnętrznymi systemami. Możliwość modyfikacji JavaScript może pozwolić atakującemu oddziaływać użytkowników serwisu, który wygląda na zaufany.
Dlaczego złośliwy JavaScript jest trudny do wykrycia?
Źródłem złośliwego kodu nie musi być bezpośrednie przejęcie samej aplikacji. Może się on pojawić wskutek uzyskania dostępu do systemu CMS, serwera www, pipeline-u CI/CD, konta administratora lub repozytorium. Również w wyniku kompromitacji zewnętrznej biblioteki, CDN, systemu reklamowego, tag managera, komponentu analitycznego albo innego dostawcy, którego skrypt jest ładowany przez administrowaną stronę.
W ten sposób powstaje szczególnie niebezpieczny scenariusz client-side supply chain attack: infrastruktura organizacji może funkcjonować prawidłowo, podczas gdy przeglądarki jej klientów pobierają i wykonują kod zmodyfikowany przez atakującego.
Jak wIDS analizuje strukturę JavaScript
Malicious JavaScript Detection analizuje kod JavaScript obecny w monitorowanych adresach URL. Identyfikuje skrypty, które wykazujące cechy charakterystyczne dla złośliwego kodu.
Do ich klasyfikacji wykorzystuje JavaScript model machine learning oparty na sieci neuronowej Graph.
To podejście wyróżnia się od metod takich jak: poszukiwania znanych hashy, nazw plików, domen C2 czy nawet charakterystycznych ciągów znaków. Tzw. „Indicators of Compromise” są niezwykle wartościowe, ale pozwalają zidentyfikować wyłącznie te zagrożenia, których cechy zostały już wcześniej rozpoznane.
Kod JavaScript można natomiast stosunkowo łatwo modyfikować i obfuskować. Atakujący może zmienić nazwy zmiennych, sposób zapisu ciągów znaków czy konstrukcję fragmentów kodu, zachowując jego zasadniczą funkcję.
wIDS analizuje również strukturę kodu. Kod JavaScript przekształcany jest przy pomocy parsera Tree-sitter do postaci AST (Abstract Syntax Tree). Pozwala to sprawdzić zależności pomiędzy konkretnymi elementami analizowanego programu. Forma AST jest następnie przekształcane do grafu, który stanowi dane wejściowe dla sieci neuronowej Graph. Model następnie uczy się reprezentacji węzłów oraz całego grafu. Poszukuje struktur charakterystycznych dla kodu złośliwego lub niebudzącego zastrzeżeń.
W efekcie przedmiotem analizy nie jest wyłącznie odpowiedź na pytanie: „Czy znamy ten konkretny złośliwy skrypt?” ale również: „Czy struktura tego kodu wykazuje cechy charakterystyczne dla złośliwego JavaScript?”
Ma to szczególne znaczenie dla wykrywania nowych wariantów malware, kodu obfuskowanego oraz złośliwych fragmentów wstrzykniętych do wcześniej prawidłowych skryptów.
Co taki sygnał oznacza dla zespołów CTI (Cyber Threat Intelligence)
Z perspektywy CTI wartością dodaną, przy wykorzystywaniu platformy wIDS jest możliwość obserwowania JavaScript z perspektywy serwisu dostarczanego użytkownikowi.
Nieautoryzowana modyfikacja nie musi dotyczyć samej strony. Na temat zagrożeń związanych z tzw. third-party app pisałem tutaj. To oznacza możliwość manipulowania na wielu podstronach, jeśli wyświetlają ten sam kod.
Ograniczenia i dalsza analiza
wIDS może wykorzystywać sitemap, aby monitorować wszystkie adresy URL serwisu, który chcemy objąć ochroną. Administratorzy często nie pamiętają o rzadko odwiedzanych stronach. Pozwala to poszukiwać złośliwego kodu również głęboko w strukturze aplikacji i w rzadko odwiedzanych miejscach, które nadal są odwiedzane. Może to być np. mało popularna ale nadal świadczona usługa, która generuje ruch.
To szczególnie ważne w przypadku bardziej ukierunkowanych ataków, gdy adwersarz chce pozostać niezauważony. Pozostałe tysiące stron mogą działać całkowicie prawidłowo podczas, gdy na jednej z nich jest złośliwy kod JavaScript.
Wykrycie takiego skryptu to dodatkowy artefakt to analiz CTI. System wIDS może go połączyć z innymi, zaobserwowanymi anomaliami, na stronie.
Zastosowana architektura GNN wykorzystuje warstwy Graph Convolutional Network, funkcję aktywacji ReLU, agregację informacji o całym grafie oraz końcową klasyfikację do jednej z dwóch klas.
W testach przeprowadzonych podczas budowy modelu, na zbalansowanym eksperymentalnym zbiorze danych obejmującym 1477 próbek każdej klasy, uzyskano około 96% dla accuracy, precision, recall oraz F1-score (wynik należy traktować jako rezultat walidacji modelu na wykorzystanym zbiorze eksperymentalnym, a nie jako gwarancje poziomu skuteczności dla dowolnego kodu JavaScript występującego w środowisku produkcyjnym).
Najważniejsze wnioski
Istotnym problemem przy analizie JavaScript jest obfuskacja.
Złośliwy kod może zostać celowo skonstruowany tak, aby utrudnić analizę statyczną, uniknąć prostych mechanizmów detekcji. Zmiana nazw zmiennych, kodowanie stringów czy inne transformacje mogą znacząco zmienić tekstową reprezentację programu bez zmiany jego rzeczywistego działania.
Podobne podejście jest wykorzystywane przez systemy bezpieczeństwa klasy enterprise. Cloudflare opisuje wykorzystanie AST i Graph Neural Networks do klasyfikowania intencji JavaScript, w tym wykrywania malware, Magecart oraz cryptominerów. Według Cloudflare reprezentacja grafowa pozwala modelowi zachować informację o strukturze programu również wtedy, gdy złośliwy fragment został wstrzyknięty do większej bazy prawidłowego kodu.
Dla wIDS oznacza to możliwość wykorzystania ML jako kolejnego niezależnego sensora zagrożeń – sensora analizującego nie reputację pliku czy domeny, lecz strukturę kodu wykonywanego w przeglądarce użytkownika.
Widoczność warstwy JavaScript powinna być traktowana jako element monitorowania powierzchni ataku aplikacji webowej, a alert ML jako sygnał wymagający korelacji z innymi danymi.
