Zakupy internetowe są dzisiaj codziennością. Płacimy kartami online w nadziei, że nie stanie się nic złego. I z reguły nic złego się nie dzieje. Oprócz tych przypadków, kiedy dane naszej karty trafiają w ręce przestępców, a ci zaczynają robić zakupy na nasze konto.
Czasem można w sieci trafić na porady rodzaju „płać kartą tylko w zaufanych sklepach online”. To nie jest zła porada – pomaga omijać sklepy fałszywe – lecz nie gwarantuje bezpieczeństwa danych karty, o czym kilka dni temu przekonali się klienci dużej linii lotniczej.
Dwa tygodnie, 380 000 klientów
Niecały tydzień temu linie lotnicze British Airways ogłosiły, że dane dotyczące płatności jej klientów zostały wykradzione przez przestępców. Komunikat był dość lakoniczny, ale zawarte w nim informacje pozwoliły prześledzić przebieg przestępstwa. Przede wszystkim dowiedzieliśmy się, że dane były wykradane wyłącznie między godziną 22:58 21 sierpnia 2018 a godziną 21:45 5 września 2018. To wyraźnie wskazuje, że nie mieliśmy do czynienia z włamaniem do bazy danych kart płatniczych, a raczej z atakiem umożliwiającym podsłuchiwanie danych na żywo. Dodatkowo ofiarami mogli paść zarówno klienci robiący zakupy przez stronę WWW, jak i z poziomu aplikacji mobilnej. Incydent ten wyglądał bardzo podobnie do niedawno przez nas opisywanego analogicznego problemu firmy Ticketmaster. Tam przestępcy dodali do pliku JavaScript wczytywanego z serwera firmy obsługującej czat na żywo bonusową linijkę, która pozwalała na kradzież danych kart płatniczych.
W przypadku British Airways scenariusz wydarzeń był bardzo podobny – tyle że zaatakowana domena prawdopodobnie należała do samej linii lotniczej. Firma RiskIQ, zarządzająca usługą PassiveTotal (polecamy do monitoringu, można tam było na przykład znaleźć dowody na październikowy atak na serwery KNF), skanuje każdego dnia 2 miliardy adresów WWW i zbiera zawartość znajdujących się tam plików. To bardzo pomaga w retrospektywnej analizie podobnych incydentów. Nie inaczej było i tym razem. Dzięki śledztwu RiskIQ wiemy, że 21 sierpnia 2018 doszło do zmiany zawartości jednego z plików JavaScriptu wczytywanego na głównej domenie British Airways. Była to biblioteka Modernizr pod adresem:
https://www.britishairways.com/cms/global/scripts/lib/modernizr-2.6.2
Do podmienionej biblioteki dodany był poniższy fragment kodu:
Kod po uporządkowaniu wyglądał następująco:
Jak widzicie, wykradzenie danych kilkuset tysięcy kart płatniczych nie wymaga rozbudowanych procedur. Po pierwsze kod uruchamia się, gdy użytkownik puszcza guzik myszki lub podnosi palec z ekranu dotykowego podczas procesu zatwierdzania danych płatności. Podwójny warunek pomaga obsłużyć zarówno klientów ze strony WWW, jak i z aplikacji mobilnej, która de facto jest „kontenerem” dla strony WWW używającej tej samej biblioteki.
Następnie kod zbiera wszystkie dane płatności i wysyła je na serwer kontrolowany przez przestępców (z pięknym adresem w ścieżce, wołającym „jestem prawdziwy, wszystko ok”). Co ciekawe, domena baways.com oraz jej certyfikat SSL zostały zakupione kilka dni przed rozpoczęciem ataku, co wskazuje, że przestępcy dostęp do witryny BA posiadali dłużej niż sam czas trwania ataku. Sam serwer, na który trafiały wykradane dane, znajduje się w Rumunii i jest obsługiwany przez litewską firmę hostingową. Co w tym ataku dość nietypowe – certyfikat SSL został przez przestępców zakupiony w firmie Comodo. Mogli użyć, jak większość ich kolegów po fachu, darmowego certyfikatu Let’s Encrypt, lecz pewnie skorzystanie z wersji płatnej miało obniżyć szansę wykrycia ich ataku (firmy takie jak BA nadal rzadko korzystają z bezpłatnych certyfikatów).
Jak ustrzec się przed takimi atakami
Za całą aferą stoi zapewne grupa Magecart, specjalizująca się w takich właśnie kradzieżach danych kart płatniczych, przejmowanych w procesie obsługi płatności za pomocą dodanych fragmentów JavaScriptu. Jako klienci wielkich firm, robiący zakupy w internecie, jesteśmy wobec takich ataków bezradni. Nikt nie będzie studiował setek kilobajtów zminimalizowanego JavaScriptu, by sprawdzić, czy ktoś nie czyha na dane jego karty. Możliwość uniknięcia tego rodzaju ataków leży całkowicie w rękach firm prowadzących internetową sprzedaż. Z jednej strony czas zrezygnować z zewnętrznych skryptów JS osadzanych jak popadnie (są strony, gdzie bywa ich nawet kilkadziesiąt) lub przynajmniej umieścić je w tagu IFRAME, z drugiej – czas zacząć monitorować integralność swoich stron WWW. Prosty skrypt w cronie uruchamiany co 5 minut rozwiązałby problemy obu wspominanych powyżej ataków. Takie proste, a takie trudne.
O takich i innych problemach z bezpieczeństwem stron WWW możecie posłuchać na naszym szkoleniu z bezpieczeństwa aplikacji WWW, które zaczyna się już za tydzień w Warszawie – zostały tylko 3 miejsca, na hasło „Magecart” 10% zniżki.
Komentarze
Może ktoś sprawdzić o co chodziło z tym przypuszczalnym włamem do sklepu p. Wojciecha Sumlińskiego? Jakiś kontakt z nim? Ciekawe czy to faktycznie ma związak z najnowszą książką (która jeszcze nie wyszła).
Podpowiem. To się nazywa „syndrom oblężonej twierdzy wszedł za mocno”. Plus „zrobimy sobie marketing dla półgłówków”
Dla kocopołów sumlińskoego nie chciałoby się nikomu włamywać chyba że dla beki
Złe moce sprzysięgły się przeciwko jednemu z najrzetelniejszych „dziennikarzy śledczych” jakich wydała RP xD
„Marketing dla półgłówków” (Thx maslan) najwyraźniej zadziałał skoro łyknąłeś bajkę o włamie i teraz powielasz fakenewsa prubując nakręcić sprzedaż kolejnego gniota pseudodziennikarzyny który z pisania kłamstw, oszczerstw i półprawd uczynił źródło zarobkowania.
Osobiście interesują mnie książki p. Sumlińskiego, choć uważam, że ostatnio zaczęły się trochę duplikować w tekście. Co do zawartości książek – uważam je za prawdę (lub półprawdę, ale nie kłamstwo) dlatego nie zdziwiłoby mnie gdyby ktoś chciał coś tam nagrzebać.
Zaczęły się duplikować w tekście już baaardzo dawno i zawsze była to „duplikacja zaporzyczona” od innych autorów, w szczególności amerykańskich pisarzy kryminałów. Gość uważa dziedzictwo literatury za open source i bierze garściami ?
Jakiś przykład poproszę, bo bez tego to wiesz… ;)
Masz w necie listy tego co i skąd przepisywał. Jest tego mnóstwo, ponad 20 pozycji, łącznie z wierszami swojej córki.
No dobra, ale jak doszło do tego że ten kod javascript znalazł się w tym pliku?
Skad to przupuszczenie ze to 'Magecart’? Ciekawi mnie jakie sa podstawy, sposob dzialania, kod bardzo podobny, jakies slady po ataku?
@Adam, mozesz cos napisac?
Ja od lat uzywam tylko wirtualnej karty i zasilam ja srodkami tylko jak spodziewam sie platnosci.
Polecam bardzo
Zmartwię cię. To cię nie uchroni. Te wirtualne karty są w jakiś sposób spięte z twoim głównym rachunkiem. Nie wiem jak ale mBank zaliczył w moim przypadku wpadkę. Płaciłem za bilet w AirFrance i płatność została 2 krotnie. Raz z konta karty wirtualnej a drugi raz z rachunku głównego. Błąd był po stronie linii lotniczej (2 krotnie pobrana płatność) ale za drugim razem mBank powinien odrzucić płatność! Nie zrobił tego a środki pobrał z rachunku głównego. W ramach rekompensaty dostałem za gratis rok karty za darmo. Ale pokazuje to, że te wirtualne wcale nie są bezpieczne!
W wdrożenie CSP nie rozwiązałoby tego problemu skuteczniej niż jakieś skrypty w cronie?
CSP jest jakimś tam narzędziem ograniczającym ryzyko. Swoją drogą jak bez CSP BA wogóle przeszło audyt PCI-DSS? Może najwyższa pora, żeby audytorzy też postarali się ogarnąć tematykę obrotu danych kartowych w webie?
To powiedziawszy należy przyznać, że utrzymanie naprawdę dobrej polityki CSP to spore wyzwanie, któremu nowe ficzery typu strict-dynamic tylko nieco pomagają same wprowadzając dodatkowe furtki z których atakujący może skorzystać. W tym temacie polecam sesje o CSP z tegorocznego CONFidence:
– Google’s journey with CSP ( https://www.youtube.com/watch?v=5m7IPjC2v70 )
– SS in Google’s application and bypassing CSP (https://www.youtube.com/watch?v=kouSscOiFkQ)
Jak BA przeszło audyt PCI DSS ? Odpowiem z praktyki – normalnie . Kupili najtańsza usługę lub usługę od najlepszego sprzedawcy, przyszedł audytor który nie ma zielonego pojęcia, zrobił checklistę i tyle.
Powiem tyle – na moim szkoleniu na audytora PCI DSS był koleś który zadał pytanie co to jest firewall. Jak w każdej branży są ludzie którzy kumają o co chodzi w webie i tacy co klikają listę i nie zastanawiają sie o co chodzi
Swoją drogą zadałbym inne pytanie – PCI DSS wymaga co najmniej tygodniowych skanów plików – jak oni to zrobili ze 2 tygodnie leżał podmieniony skrypt. Zakładam ze BA ma pewnie SIEMa za kilka grubych baniek a obsługuje go koleś (kolesie) którzy ślepo się gapią w monitor i albo olali temat albo go nie zauważyli. Bo jeśli ich fim tego nie złapał to mega wtopa audytora…
Chcialbym zobaczyc ten „prosty skrypt w cronie”. Zgadzam sie ze jedynym rozwiazaniem tu jest monitoring tresci, ale jest on daleko od prostego rozwiazania.
Opcja jeden, to aplikacja jest super prosta (kuzyn z gimnazjum zakodowal) – jeden serwer, jedna strona ktora sie rzadko zmienia – i pewnie wtedy albo dziala ona na roocie, albo na dziurawym serwerze z EoP, a wiec podmiana w/w crona nie stanowi problemu (plus – dziala to tylko dla bardzo malych firm)
Opcja numer dwa to duza firma, duzo maszyn, czeste zmiany tresci (nie daj boze CI) – centralny serwer ktory weryfikuje periodycznie tresc wszystkich maszyn w sieci. I wtedy zgadzam sie, trzeba monitorowac, ale nie ma to nic wspolnego z „prostym” rozwiazaniem, ktore jest w stanie w miare bezproblemowo rozpoznawac uprawnione zmiany tresci, od tych nieuprawnionych.
Ogolnie, w momencie gdy atakujacy ma mozliwosc modyfikowania plikow na serwerze to ja bym powiedzial ze game over. Mozna probowac dockerow, vm, subresource integrity, monitoring, podpisy, update’y i hardening serwera – i czasem to pomoze. Ale czasem nawet przy tych wszystkich srodkach nie.
Najprosciej to porownywac sumy kontrolne plikow. Ale te sie moga czesto zmieniac ze wzgledu na jakies updaty i w przypadku duzej ilosci plikow/ich wielkosci moze to chwile potrwac.
Ale nie skrypt na serwerze WWW, tylko gdzieś zupełnie indziej. Sprawa jest prosta – by zaatakować użytkownika trzeba mu coś dodać do tego co jest normalnie. Więc wchodzimy na stronę jako użytkownik i sprawdzamy to co widzimy i w razie gdy widzimy coś innego niż zwykle to alert. Koniec. Oczywiście „to zależy” ale w tym trybie nie ma znaczenia co skąd jest serwowane i żadnych dockerów, vmek itd. nie trzeba bo po co.
„Jako klienci wielkich firm, robiący zakupy w internecie, jesteśmy wobec takich ataków bezradni.” – ja bym jednak poradził dwie rzeczy
1) korzystanie z kart prepaidowych (revolut chociażby)
2) monitorowanie wyciągów z kart i reklamowanie dziwnych transakcji
A najlepiej jedno i drugie. To nas nie uchroni przed wykradzeniem danych karty ale uchroni przed konsekwencjami takiej kradzieży.
Revolut to świetne rozwiązanie, sam korzystam:
Zalety: Pełna kontrola nad tym jakie możliwości płatnicze posiada karta z możliwością ich zmian w czasie rzeczywistym, czyli: zbliżeniowo, pasek magnetyczny, chip, płatności online. Standardowo pasek magnetyczny i płatności online mam wyłączone. Płatności online włączam na moment przed transakcją, wyłączam moment po.
Wady: Ponieważ trzeba im wysłać skan dowodu, należy go potem uznać za skompromitowany i powinno się go wymienić. Skoro można to zrobić przez epuap na koszt Państwa nie ruszając zadka spred komputera, nie jest to duża upierdliwość.
Nie trzeba wysyłać dowodu osobistego można przesłać prawo jazdy.
Wydaje mj się, że jeszcze lepszym rozwiązaniem sprawdzania integralności plików strony niż CRON byłby system zdalny, montujący system plików np. po SSHFS i skanujący go np. w celu wyliczenia sum kontrolnych plików w celu porównania wyników z tymi oczekiwanymi. Dzięki temu przestępcy nie byli by w stanie go unieszkodliwić, bo nie byli by go nawet świadomi. Natomiast wyłączenie konta na które logował by się zdalny system od razu wzbudziło by zainteresowanie administratorów.
Rozwiązanie z SSHFS będzie bezradne w stosunku do ataków XSS. Prosty cron również może nie wystarczyć – trzeba by dołożyć analizę elementów dynamicznych (interpretacja JS).
„Jako klienci wielkich firm, robiący zakupy w internecie, jesteśmy wobec takich ataków bezradni.”
Mozna placic PayPalem. Wiele lini lotniczych na to pozwala. W tym np. Ryanair.
a pejpala zasilac z wiaderka z forsa…?
wiem ze sie da zrobic przelew na konto w pp ale jest to niepraktyczne czyli w pp i tak musisz miec karte wpisana, owszem zdecydowanie lepiej w jednym wiekszym miejscu niz w 100 ale problem caly czas pozostaje podobny, w koncu jest tylko kwestia czasu az wlamia sie do kazdej mozliwej instytucji platniczej, stad jednak dobrze by bylo nie miec kartw wcale i placic inna forma, albo jak juz miec to podawac ja tylko w systemie bankowym ktory udostepnia innynm serwisom tylko api do potwierdzenia platnosci i danych klienta ale bez podania numeru karty.
No i od długiego czasu można też podawać hash integralnosci każdego skryptu. Gdy się nie będzie zgadzał przeglądarka go nie wykona.