Webskimming

Ostrzeżenia - czyli na co uważać w necie i jak się przed tym zabezpieczyć.
serwerux1
Forumowicz
Forumowicz
Posty: 198
Rejestracja: 16 maja 2016, 12:16

Webskimming

Postautor: serwerux1 » 28 mar 2018, 18:38

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ą darmowych certyfikatów 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ę sklepu Partii Republikańskiej USA. Przez 6 miesięcy dane z kart kredytowych klientów były wykradane i przekazywane do rosyjskiego serwera. 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 prześledził 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 Willem de Groot 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.

W bieżącym roku przy użyciu identycznej metody zostały wykradzione 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 https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP (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.

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 skrypty wstrzykiwane na stronie Kancelarii Prezydenta RP, gdzie nie udało się jednoznacznie wskazać, jaki był cel odwołań do obcych skryptów.

źródło: ZTS

PS:
gdy będziemy pisać politykę CSP, przydatny się może okazać mały robot

https://addons.mozilla.org/en-US/firefo ... y-mozilla/

Oraz nieco dokumentacji

https://infosec.mozilla.org/guidelines/ ... ity-policy

https://www.html5rocks.com/en/tutorials ... ty-policy/

Wróć do „Scams,Oszustwa,Phishing,bezpieczeństwo”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość