Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Pokazali jak zrobić kartą zbliżeniową transakcje kilka razy powyżej limitu – bez podania PINu. Jako bonus – wyciąganie pieniędzy z Android Pay + „klonowanie” kart zbliżeniowych
Idzie nowe. Jeśli ktoś chce mocno technicznie się wgryźć w temat można zacząć od tego wprowadzenia (EMV dla opornych ;) Może też się przydać nasza relacja w temacie ataków klasy pre-play.
W każdym razie praca o charakterze z jednej strony akademickim, z drugiej strony praktycznym pokazuje ataki na komunikację bezprzewodową (z terminalem) zarówno kart Visa jak i Mastercard – wbrew pozorom te komunikacje są różne. Główna analiza została wykonana z wykorzystaniem NFC Proxy. Karta po lewej, terminal po prawej – NFC proxy po środku; wgląd w komunikację na komputerze powyżej ;)
NFC Proxy
Co można zrobić? Będąc w sytuacji MiTM (czyli umieszczając bezprzewodowo urządzenie pomiędzy kartą a terminalem) możemy wpływać na pewne parametry realizując… transakcje powyżej limitu wymagającego podanie PINu. W UK limit ten wynosi 30 GBP, a udało się wykonać transakcje nawet na 100 GBP (badacze nie piszą nic o większych kwotach…). Co więcej taka kwota została realnie „ściągnięta” z konta – więc transakcja przeszła wszystkie weryfikacje po drodze. Jeśli ktoś chce bardziej technicznie ;) proszę:
„CVM required” and „CDCVM performed” are substituted using the NFC proxy. Payment of £31.00 is successfully made without cardholder verification.
Atak ten powiódł się na karty Visa.
Kolejny atak został wykonany na Android Pay. Tutaj może być jeszcze „zabawniej” bo limit płatności telefonem bywa naprawdę duży. Oczywiście tylko przy małych płatnościach (<50 PLN) nie ma konieczności odblokowywania telefonu. Ale właśnie ten fragment można obejść.
Badacze wskazują na ukryte NFC proxy pomiędzy telefonem a terminalem. Modyfikacja w locie raptem jednego parametru – i nagle do zrobienia dużej płatności wystarczy aby ekran telefonu był aktywny (np. ktoś mógłby zadzwonić na dany telefon). Czyli sytuacja jakbyśmy płacili < 50 PLN:
For small transactions the Android device simply needs to have an active screen. This makes it possible to carry out electronic theft from a victim’s wallet as long as NFC is active on the device and the screen is active. The screen can be activated by any number of methods. These methods can include requesting Bluetooth pairing, calling the phone, or pressing the volume keys. By proxying data between the Android device and the terminal, a transaction exceeding the CDCVM limit for Google Pay can go through.
Proxy na telefon
Tutaj też ponownie realnie udało się wykonać płatność telefonem powyżej limitu „bez dodatkowej akceptacji na telefonie”.
Na deser badacze zaserwowali atak klasy pre-play. W skrócie chodzi o to, że atakujący może w pewnym sensie bezprzewodowo „sklonować” kartę. Płacisz bezprzewodowo w miejscu gdzie ktoś „lekko” zmodyfikował terminal (w bardziej czarnym scenariuszu ktoś przykłada Ci do kieszeni urządzenie klasy NFC relay). Teraz ta transakcja może być odtworzona wiele razy (i zaakceptowana!). Bez sensu? Spośród 31 kart różnych banków, atak udał się na 18-stu (karty Visa oraz Mastercard).
–ms
Nie działa link do emv dla opornych
Czyli znów warto uruchomić zestaw dziurkacz/nożyk do tapet na swojej karcie. Tym bardziej, że banki wciskają zbliżeniówki na siłę i jest problem z wyłączaniem, mi osobiście zdarzyło się też, iż mimo zapewnień banku (specjalnie dopytywałem o to) po wznowieniu karty nowa miała te płatności znów włączone, podczas gdy stara miała wyłączone – bank oficjalnie zapewnia, iż wznawianie karty nie zmienia ustawień płacenia zbliżeniowego – jak ktoś miał wyłączone to dalej tak powinno być – u mnie jednak okazało się to ściemą.
Heh, a Konieczny mówił, że nie ma się co bać o forsę przy zbliżeniówkach… Jednak do czasu.
Tak, jest chargeback. I sobie tak chargebackujcie regularnie, śledząc co dnia wyciąg.
karty Visa oraz Mastercard są najpopularniejsze, więc najczęściej są atakowane.
Podobnie jak na PC na Windowsa jest znacznie więcej różnego robactwa, niż na inne systemy
„The vulnerabilities we describe in this document involve kernel 1”
Tak, tak, kernel C-1 ;)
Całe szczęście, że dalsza część publikacji nie ma takich „kwiatków” (pomijając parę stron listowania konfigu dla DRLi – bez wyjaśnienia co i po co to właściwie jest).
Że issuerzy ATC nie kontrolują, że UN nie – smutna rzeczywistość, zwłaszcze że są do tego wytyczne. Część rzeczy wyłapią organizacje (kiedyś raport z MC dostaliśmy, że UN-y nie są za bardzo losowe, okazało się, że to ATMy z czasów, gdy robiono je z monitami CRT i drukarkami igłowymi, „mało losowymi” liczbami losowymi się posługiwały), ale takich rzeczy jak np. to, że issuerzy niektórzy nie sprawdzają AC – takie coś nawet w tym roku osobiście widziałem (do tego była niedawno draka w Niemczech z „klonowaniem” kart EMV, gdzie posłużono się metodą brazylijską – a to działa tylko, gdy issuer nic nie sprawdza) – to już nie wyłapią.
Ciekawe czy dla ichnich testów „relayowania” z kartami MC działało RRP, niedawno się okazało, że jest z tym problem i MC zezwoliło na wyłączenie sprawdzania (aktualna specyfikacja już powinna problem z RRP rozwiązać). Ale testy, z tego co widzę, robione były w 2018, a upublicznienie problemu z RRP i zezwolenie na wyłączenie to bodajże pierwszy kwartał 2019.