Verifone: trei lanțuri de atac până la root pe terminale POS

Ce a fost demonstrat, exact

Rezumatul oficial spune că aceeași linie de produse a fost evaluată anual, timp de trei ani. După fiecare evaluare, producătorul a corectat problemele raportate; la următoarea evaluare, cercetătorul a găsit un alt traseu până la root.

Au rezultat trei lanțuri separate, nu o singură vulnerabilitate reciclată. Două puteau porni numai cu acces la rețeaua terminalului. Cercetătorul estimează că linia analizată este instalată în peste un milion de locații, însă această cifră este estimarea autorului prezentării, nu o statistică publicată de Verifone.

Conform aceluiași rezumat, accesul obținut permitea dezactivarea grsecurity, modificarea sistemului de fișiere pentru persistență și capturarea continuă a datelor de card. Nu sunt publicate însă pașii tehnici necesari reproducerii atacului.

• ▸DEF CON 34 — Very Pwned: Hacking Verifone’s card machine three times in a row

De ce root pe un POS schimbă categoria incidentului

Un terminal de plată este o zonă de încredere: citește date sensibile, participă la autorizarea tranzacției și comunică cu infrastructura comerciantului și a procesatorului. Accesul root mută atacatorul sub controalele aplicației, acolo unde poate urmări procese, modifica fișiere și încerca să supraviețuiască unei reporniri.

Asta nu înseamnă automat că PIN-ul, cheia criptografică sau fiecare tranzacție pot fi compromise. Arhitectura exactă, criptarea punct-la-punct, elementele securizate și versiunea dispozitivului contează. Concluzia justificată este mai îngustă: cercetarea a demonstrat control privilegiat și captură continuă de informații de card în mediul testat.

Ce nu știm încă

Fără aceste elemente, un titlu de tipul „un milion de terminale compromise” ar amesteca o estimare de instalări cu dovada exploatării. Publicarea responsabilă trebuie să păstreze această distincție.

• ▸modelul sau familia exactă de terminale și reviziile hardware afectate
• ▸versiunile de firmware vulnerabile și versiunile în care fiecare lanț a fost reparat
• ▸identificatori CVE, scoruri CVSS sau advisories publice asociate
• ▸dacă ultimele dispozitive evaluate rulează încă în producție în aceeași configurație
• ▸dacă există exploatare în sălbăticie — rezumatul DEF CON nu afirmă așa ceva

Lista de verificare pentru comercianți și operatori

• ▸inventariază modelul complet, revizia hardware, firmware-ul, numărul de serie și starea de suport pentru fiecare terminal
• ▸cere furnizorului, integratorului și băncii acceptatoare o confirmare scrisă privind aplicabilitatea cercetării și firmware-ul curent
• ▸compară fiecare model cu lista PCI SSC și verifică data expirării aprobării; aprobarea nu înlocuiește patch-urile
• ▸izolează terminalele într-un segment dedicat și permite doar destinațiile, protocoalele și administrarea strict necesare
• ▸monitorizează conexiunile de ieșire, modificările neautorizate, restarturile și abaterile de la configurația de bază
• ▸verifică procedurile fizice anti-tamper și reconcilierea inventarului, inclusiv terminalele de rezervă
• ▸nu încerca să reproduci atacul pe echipamente de producție; coordonează orice test cu furnizorul și procesatorul de plăți

• ▸PCI SSC — lista oficială a dispozitivelor PTS aprobate

Aprobarea PCI nu este un număr de versiune

Lista PCI SSC le permite operatorilor să verifice producătorul, modelul, numărul aprobării și expirarea. Este un punct de control important, dar nu dovedește că terminalul instalat rulează cel mai nou firmware și nici că integrarea sa de rețea este sigură.

PCI SSC recomandă comercianților folosirea dispozitivelor aprobate și contactarea acceptatorului sau a brandurilor de plată pentru cerințele specifice. Pentru o dezvăluire fără modele publice, traseul corect este inventar exact, confirmare de la furnizor și acceptator, apoi remediere controlată.

• ▸PCI SSC — produse și soluții de securitate pentru plăți

Unde ajută monitorizarea CVE — și unde nu

Dacă producătorul publică ulterior CVE-uri și intervale de versiuni, ele pot fi corelate automat cu inventarul și prioritizate după severitate și exploatare cunoscută. Până atunci, un motor CVE nu poate inventa legătura dintre o prezentare și terminalul de pe tejghea.

Acest incident este un exemplu bun de limită sănătoasă a automatizării: MONITOR AWARELY poate urmări advisories publice, dar decizia imediată depinde de datele interne ale activului și de canalul furnizorului. Păstrează confirmările, versiunile și schimbările ca dovezi pentru evaluarea riscului de furnizor și pentru audit.