11:04
13/5/2020

Kilka polskich sklepów znalazło się na liście 1236 sprzedawców, których strony zostały wykryte jako zainfekowane web skimmerem MageCart.

MageCart nie odpuszcza

Zgadujemy, że o atakach MageCart już słyszeliście. Jest to tzw. webowy skimmer, czyli kod podrzucany na stronę internetową w celu przejmowania danych o kartach kredytowych wprowadzanych przez klientów dokonujących zakupów. Grupy przestępcze posługujące się MageCartem miały pewne spektakularne sukcesy jak atak na Ticketmastera oraz atak na British Airways. Najczęściej jednak atakują sprzedawców średnich i małych. Ofiary (zarówno sklepy jak i klienci) mogą długo nie mieć świadomości, że coś złego się wydarzyło.

W czasach zarazy COVID-19 zaobserwowano wyraźny wzrost aktywności tych grup przestępczych. Samo zainstalowanie skimmera na stronie nie przeszkadza ani w w przekazaniu pieniędzy sprzedawcy ani w dostarczeniu towaru. Nawet gdy klienci zobaczą na swoim koncie nieznane płatności, nie zawsze skojarzą kradzież danych kartowych z konkretnym sprzedawcą.

Szukanie ofiar

Max Kersten postanowił zmierzyć się z tematem i namierzyć możliwie dużo stron, które mogły być zainfekowane. W wyniku swoich ostatnich badań opublikował raport pt. Backtracking MageCart infections, w którym ujął 1236 strony zainfekowane skimmerem.

Dodajmy tutaj, że Kersten walczy z tematem nie od dziś. W praktyce skimmer jest zawarty w bibliotece JavaScript, do której odwołuje się kod zaatakowanej strony. Już w styczniu br. bazując na wiedzy o wykorzystywanej do tego celu domenie oraz na narzędziu URLScan Kersten zidentyfikował kilka sklepów zaatakowanych MageCartem. Cześć z nich linkowała do domeny przestępców jeszcze w momencie opisywania odkrycia.

W ramach swojego najnowszego badania Kersten pozbierał tweety innych badaczy, którzy wspominali o domenach używanych przez grupy MageCart. To dało dobry punkt wyjścia. Następnie opracował własny skaner bazujący na danych z API UrlScan oraz na zestawie reguł pozwalających na wykrywanie złośliwych skryptów. Dodatkowo badacz opracował metodę automatycznego wysyłania powiadomień do administratorów stron wykrytych jako zainfekowane. Opierało się to na wysyłaniu powiadomień na adresy tworzone według wzoru.

info@domain.tld
contact@domain.tld
sales@domain.tld
abuse@domain.tld
security@domain.tld

Metoda powiadamiania była daleka od doskonałości, ale przy skali pracy do wykonania trudno byłoby oczekiwać od badacza “ręcznego” powiadamiania każdego sklepu. Inna rzecz, że nawet duże sklepy internetowe potrafią utrudniać kontakt z osobami odpowiedzialnymi za administrowanie stroną (coś o tym wiemy).

Więc gdzie był ten skimmer?

Koniec końców w toku badania udało się namierzyć 1236 sklepów zainfekowanych MageCartem. Mapka infekcji przedstawia się następująco.

Niestety w tym przypadku polska nie jest białą plamą. Dlatego zajrzeliśmy w wyniki badań i wyciągnęliśmy te, które wyglądają na polskie sklepy. Oto ich lista.

sklepsilvermagic.pl
hurtsilvermagic.pl
laborisfarma.pl
lazieneczka.pl
www.sukhi.pl
www.xkko.pl
4oczy.pl

Te adresy są ewidentnie polskie. Pod częścią z nich znajdziemy wciąż działające sklepy. Jeśli robiłeś zakupy na którejś z tych stron, sprawdź wyciągi ze swojego konta i lepiej uznaj, że dane Twojej karty już wyciekły. Jeśli zdarzało Ci się płacić na stronach sprzedawców zagranicznych to sprawdź czy nie ujęto domeny w raporcie Maksa Kerstena.

Wykrycie zainfekowanych stron to jedno, atrybucja ataku to drugie. Max Kersten nie podjął się prób określenia jakie grupy przestępcze stały za poszczególnymi atakami. Jak wspomnieliśmy bardzo często ofiarami webskimmerów są sklepy mniejsze bo nie nadążają one z aktualizowaniem swoich stron. Przestępcy mają do dyspozycji automaty skanujące strony pod kątem podatności i wstrzykujące skimmery gdzie jest to możliwe. Trudno doszukiwać się w takich działaniach ujednoliconych metod.

Staraliśmy się przeszukać listę domen pod katem adresów możliwie polskich z końcówkami innymi niż .pl, ale nic takiego nie rzuciło nam się w oczy. Odnotowaliśmy natomiast, że ofiarą nierzadko padały sklepy optyczne. Przypominamy więc, że przy okazji zakupów u optyka online możecie ujawnić dane swojej karty nawet bez skimmera. Nie róbcie tego.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

26 komentarzy

Dodaj komentarz
  1. Oczywiście nikt nie ustawi Content Policy, bo po co? To tylko wrażliwe dane klientów, nie ma się co nimi przejmować.
    Jeden nagłówek CP i nie byłoby problemu.

    • Jest tyle rzeczy do poustawiania. A jasnej instrukcji co ustawić, dlaczego i jak nie ma.
      Biznes najpierw musi zarabiać. Wiele firm informatycznych nawet mających 20-30 osób nie ma nikogo od bezpieczeństwa. Czego ty oczekujesz ?

    • Ile znasz firm, które mają poprawnie zaimplementowane CSP? Ten “jeden nagłówek” to czasami kilka miesięcy pracy.

    • To zobacz sobie ile elementow ze stron 3cich waznych dla biznesu znajduje sie na przecietnej stronie sklepu. 70% skryptow tak naprawde nie jest twoich. Nie jestes w stanie zaimplementowac CSP dla wszystkiego. Chyba lepszym sposobem jest monitorowanie anomalii i zachowania skryptow. Sorry za brak polskich znakow.

    • Nawet, jeśli 70% skryptów “nie jest Twoich”, to to jest Twój problem, żeby zabezpieczyć stronę/aplikację. Jeśli Twój vendor JSów nie daje dobrych skryptów (konkretna wersja o konkretnym hashu), to zmień vendora. A na przykład Google Tag Manager potrafi dynamicznie wstawiać skrypty z poprawnymi atrybutami CSP.

  2. Ciekawe dlaczego w artykule ani razu nie pada nazwa Magento…

  3. Chciałbym nieśmiało zauważyć, że cały ten problem bierze się li tylko stąd, że płatność kartą, jako bodaj jedyna, wymaga przekazania danych tejże karty bezpośrednio do sklepu (jeśli nie korzysta się z pośrednika płatności). To oczywiście ułatwia implementację płatności po stronie sklepu (czyli także obniża jej koszty), ale za to naraża klientów (i sam sklep) na takie wpadki.
    No ale karty są przecież najbezpieczniejszą metodą płatności w sieci… ;-)

  4. Po jakiego grzyba sklepy on-line przyjmują dane kart bezpośrednio na swoich stronach??? We wszystkich sklepach (bez wyjątku), które honorują płatność kartą powinno być przekierowanie na stronę agenta rozliczeniowego typu Przelewy24, PayU, DotPay, eCard itp. Tam klient podaje dane karty a sklep otrzymuje tylko status transakcji. Agent rozliczeniowy to instytucja koncesjonowana przez KNF, spełniająca liczne wymogi kapitałowe, techniczne i organizacyjne, ubezpieczona od OC i podlegająca regularnym audytom.

    • Z prostego. Pośrednik bierze prowizję, np przelewy 24 biorą 1.9%

    • @Mateusz
      Jak sklep zbierze dane karty bezpośrednio na swojej stronie to co dalej z nimi robi? No chyba musi je gdzieś wysłać bo jak nie to od kogo dostanie kasę? Oczywiście wysyła do agenta rozliczeniowego a więc prowizji tak czy inaczej nie uniknie. Tylko że w tym przypadku sklep niepotrzebnie ma styczność z danymi karty.

    • To się nazywa seamless payment workflow. I często sami pośrednicy płatności wystawiają API obsługi płatności bezpośrednio na stronie sklepu – od API też zależy, czy będzie ono wymagało przetwarzania danych karty przez backend na serwerze, czy pośle dane karty pośrednikowi ajaxem i zwróci sklepowi tylko status, czy też w ogóle będzie miało posta iframe’u.

    • No to właśnie coś takiego jak “seamless payment workflow” powinno raz na zawsze zniknąć. Dane karty powinny być podawane tylko i wyłącznie na stronie agenta rozliczeniowego koncesjonowanego przez KNF (lub inny organ właściwy w danym kraju).

      Dodam, że na stronach niektórych agentów rozliczeniowych jest możliwe również inicjowanie płatności cyklicznych np. za abonamenty. Klient po podaniu danych karty wraca na stronę sprzedawcy a ten otrzymuje od agenta specjalny unikatowy ciąg znaków przypisany do karty tzw. token. Kiedy kolejny raz sprzedawca chce obciążyć tę samą kartę, wysyła do agenta przez API token i kwotę. Tokena może użyć tylko ten sprzedawca i tylko u tego agenta rozliczeniowego, u którego karta została zarejestrowana na potrzeby cyklicznych obciążeń. Dla reszty świata token jest bezużyteczny więc może sobie spokojnie wyciekać z bazy. Pełnych danych karty sklep nawet na oczy nie widzi.

    • Bo chcą wiedzieć więcej o kliencie. Dlatego jedynym sposobem prawidłowego zakupu jest paczka pobraniowa na fałszywe dane – prawdziwy jedynie adres lub mniej pewne: wszystkie dane fałszywe i paczkomat.

    • tak, a książki powinne być wydawane tylko przez akredytowane przez rząd danego Państwa specjalne agencje, np. Główny Urząd Kontroli Jakości Wydawnictw i Instytucji Artystycznych.
      Czy widzisz już tę… demagogię?

    • @cenzor i uzurpator
      Czy nie akredytowany wydawca książek zbiera dane, które służą od pobierania pieniędzy z twojego konta?

  5. najpierw trzeba wiedzieć o co chodzi, większość ludzi kupuje gotowe rozwiazania i nie ma pojęcia o ich działaniu. Żeby nie hejtować to większość też nie wie jak dokładnie działa samochód a jeździ i jest ok

  6. A gdzie o zaletach kart płatniczych i o tym, że zawsze można robić chargeback i miło spędzać czas przy czytaniu wyciągów (a kto nie ma aplikacji i powiadomień, ten baran)?

  7. “sklepsilvermagic.pl
    hurtsilvermagic.pl
    laborisfarma.pl
    lazieneczka.pl
    http://www.sukhi.pl
    http://www.xkko.pl
    4oczy.pl”

    Serio trzeba być osłem, żeby podawać dane karty w sklepach o takej nazwie.

    • a np. morele.net to nagle jakas super domena? xD

  8. Większość, jak nie wszystkie podane strony stoją na Magento 2. Skrypty doklejane są przez cmsa Magentowego

  9. Ahh te nazwy. Znowu same takie warte zaufania :p
    Laboris troche odstawia peleton na plus, chociaz ta farma przez f – dziwne polaczenie…

    Nie, ze nigdy nie kupuje w malych sklepach czy ogolnie w necie na karte, ale czy naprawde wszedzie trzeba placic w ten sposob?

  10. Przegapiliście ewidentnie polski http://www.alkoholeswiata.com (który ciągle działa).

  11. A to Rząd nie zapewnia bezpieczeństwa danych kart ustawą tak jak w przypadku głosowania zdalnego?

    • Dobre :) !

  12. Sam kupowałem w 4oczy oprawki w lipcu 2019. Płatność była realizowana przez Tpay.com. Płaciłem pewnie KK Citi, na wyciągach nic dziwnego nie ma – jak myślicie, po takim czasie powinno być już ok?
    Swoją drogą tak teraz patrzę, że www zmieniła właściciela. Jak kupowałem towar to firma stojąca za www to: CODEGLADE SP. Z O.O. ul. BARWNA 24/1, 72-006 Mierzyn, a teraz jest WML SP. Z O.O. UL. FLISACZA 47, 74-100 GRYFINO. A jednak… ludzie stojący w KRS Ci sami. Kapitał spółki minimalne 5k. Hmmm.

  13. […] (tj. wstrzykiwanie na strony kodu wyłudzającego dane kart) z użyciem takich narzędzi jak Magecart. Sprzyjają temu słabe zabezpieczenia mniejszych sklepów online. Z drugiej strony trzeba […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: