Webskimming, czyli nakładki na stronach sklepów internetowych

[Grandalf]

Płacisz za zakupy kartą kredytową. Co byś jednak zrobił, gdyby po zakupie online okazało się, że Twoje konto zostało obciążone kilkoma dodatkowymi operacjami z wypłatą gotówki w Meksyku włącznie ?

Zapewne przeżyłbyś szok i niedowierzanie, bo przecież na stronie widniał znany wszystkim symbol zielonej kłódki. Przekleństwo zielonej kłódki polega na tym, że paradoksalnie oznaczenie to często obniża poziom cyberbezpieczeństwa, powodując uśpienie czujności klientów sklepów. Użytkownik strony wykorzystującej HTTPS został nauczony i przyzwyczajony do weryfikacji, czy dana strona jest oznaczona tym charakterystycznym symbolem, a sama obecność kłódki stała się dla niego ewidentnym dowodem na brak jakichkolwiek zagrożeń. Niestety rzeczywistość jest inna. Przestępcy – świadomi takiego podejścia użytkowników – wykorzystują ich nadmierną ufność w bezpieczeństwo strony w różny sposób:

• używają
  Zaloguj lub Zarejestruj się aby zobaczyć!
  Let’s Encrypt,
• umieszczają na stronie ikonkę (favicon) w kształcie kłódki,
• wstrzykują w źródło strony zainfekowany kod.

A przecież „zielona kłódka” czy też dobrze skonfigurowany serwis działający w protokole HTTPS świadczą wyłącznie o ochronie przed podsłuchaniem informacji na etapie transmisji danych (uniemożliwiają atak Man-in-the-Middle).

Szyfrowanie połączenia nie pomaga w sytuacji, kiedy dane są czytane i przekazywane przestępcom podczas ich wprowadzania do formularzy płatności online. Wielokrotnie już ostrzegaliśmy przez nakładkami na bankomaty (skimmery), które rejestrują dane o kartach celem późniejszego skopiowania. Analiza sposobów infekcji niektórych sklepów internetowych wskazuje, że przestępcy przenieśli fizyczne skimmery bankomatowe do cyberświata pod postacią webskimmerów.

Jak to działa
Klient, wykonując przelew za zakupy, wypełnia formularz płatności, w którym podaje wszystkie dane (numer karty kredytowej, datę jej ważności, numer CVV, imię i nazwisko). Płatność jest autoryzowana przez sklep w tradycyjny sposób, a cały proces zakupu przebiega prawidłowo. W przypadku użycia webskimmera strona internetowa sklepu ma wstrzyknięty kod (wystarczy jedna linijka JavaScriptu), który powoduje, że dane wpisane do formularza są wysyłane na serwer przestępców.

Jednym z głośniejszych przestępstw tego typu był atak na stronę

Zaloguj lub Zarejestruj się aby zobaczyć!

. Przez 6 miesięcy dane z kart kredytowych klientów były wykradane i przekazywane

Zaloguj lub Zarejestruj się aby zobaczyć!

. W serwisie umieszczona była jedna linijka pozornie niegroźnego kodu. Z obcego serwera pobierany był właściwy skrypt, który budował paczkę danych, kodował je w base64 i wysyłał na serwer zdalny. Holenderski badacz Willem de Grot

Zaloguj lub Zarejestruj się aby zobaczyć!

domeny i kraje, za pośrednictwem których przepływały te dane, wykazując, że przez raje podatkowe (Belize, Panamę i Seszele) trafiały one do firmy działającej na pograniczu prawa (doradztwo podatkowe) i czarnego rynku. Szacując ruch sieciowy w sklepie i dane czarnorynkowe, określił, iż skradzione karty kredytowe przyniosły cyberprzestępcom zysk na poziomie 600 000 dolarów.

Po tym odkryciu

Zaloguj lub Zarejestruj się aby zobaczyć!

postanowił sprawdzić mechanizmy płatności w innych sklepach internetowych. Skrypty (realizujące funkcjonalność skimmerów), które poddał analizie, były wielopoziomowo zaciemnione, a dodatkowo często udawały pliki znanych firm (np. UPS) lub też były wywoływane jako argumenty innych popularnych bibliotek JavaScriptu. Badania wykazały, że procederem tym zajmuje się kilka niezależnych grup przestępczych (istnieje kilka podobnych do siebie rodzin malware’u). Jeszcze do niedawna badacz publikował na GitHubie listę zainfekowanych sklepów (doszedł do niemal 6000). Mimo ostrzeżeń Willema wiele spośród nich wciąż prowadzi swą działalność bez dokonania jakichkolwiek zmian.

źródło:

Zaloguj lub Zarejestruj się aby zobaczyć!

W bieżącym roku przy użyciu identycznej metody

Zaloguj lub Zarejestruj się aby zobaczyć!

dane klientów producenta smartfonów OnePlus. Firma przyznała, że jej serwer został zainfekowany, a przekazywane dane kart kredytowych były podsłuchiwane bezpośrednio w przeglądarce i wysyłane do nieznanych przestępców. Podano, że w ten sposób przywłaszczono dane 40 tys. klientów.

Jak się bronić
Jednym z rozwiązań, które w znacznym stopniu mogą ograniczyć wiele z nadużyć, jest włączenie i właściwe skonfigurowanie polityk

Zaloguj lub Zarejestruj się aby zobaczyć!

(Content Security Policy). Korzystanie z tej warstwy ochrony uniemożliwia lub istotnie redukuje przeprowadzenie ataków XSS, wstrzyknięcie ramek lub CSS. Dobrze przygotowana polityka uniemożliwia pobranie zdalnych skryptów lub złośliwych payloadów.

W przebiegu kompletnego scenariusza ataku najtrudniejszym dla przestępców etapem wydaje się zainfekowanie serwisu sklepu. Jednakże biorąc pod uwagę, jak wiele jest programów działających ze znanymi lukami (oprogramowanie serwerów aplikacyjnych czy same aplikacje sklepów), nikogo nie powinien dziwić fakt, że liczba zainfekowanych serwisów stale rośnie.

Bezpowrotnie minęły czasy, kiedy po przejęciu kontroli nad serwisem WWW, przestępcy zmieniali treść strony głównej, umieszczając na niej wypisaną wielką czcionką informację „WEBSITE HACKED”. Obecnie celem ataków jest przede wszystkim zdobycie pieniędzy, a przestępcy wykorzystują wszelkie sposoby, by w każdej sytuacji odnieść wymierne korzyści finansowe. Po przejęciu strony starają się jak najdłużej pozostać w ukryciu i czerpać zyski lub wykorzystywać pozyskaną infrastrukturę.

Oczywiście, jeżeli przestępca uzyska całkowitą kontrolę nad serwerem i plikami serwisu, to może wyłączyć dowolną politykę ochronną, jednak wymagałoby to z jego strony dokładnej analizy. Tylko wąska grupa przestępców jest aż tak zdeterminowana, większość z nich w takiej sytuacji woli znaleźć sklep, który działa bez polityk ochronnych.

Coś więcej
Wstrzykiwanie złośliwego kodu w słabo zabezpieczone strony może mieć różny cel. Powyżej przedstawiliśmy cel finansowy (kradzież informacji o kartach kredytowych). Niedawno opisywaliśmy także bułgarskie

Zaloguj lub Zarejestruj się aby zobaczyć!

, gdzie nie udało się jednoznacznie wskazać, jaki był cel odwołań do obcych skryptów.

źródło:

Zaloguj lub Zarejestruj się aby zobaczyć!