Żabka: credențiale de producție scoase la vânzare cu 5.000 €

Ce se pretinde că a fost luat

Sunt cifre din anunțul vânzătorului, nu confirmate de companie. Le tratăm ca revendicare.

• ▸541.000 de tichete Jira
• ▸229.734 de tichete de service desk IT
• ▸Codul sursă din 89 de depozite GitLab, aproape 12.000 de fișiere
• ▸Platforma de retail, microservicii de backend, aplicații frontend și componente de infrastructură

• ▸The Record — atacul prin contul unui furnizor terț

Partea gravă nu e codul, sunt cheile

Codul sursă scurs e neplăcut, dar rareori catastrofal — cine îl citește găsește logică de business, nu acces.

Anunțul pretinde însă și altceva: tokenuri GitLab de acces personal reutilizate pe toate depozitele compromise, parole de administrator de baze de date, fișiere .env cu tokenuri hardcodate și tipare de acces SSH către serverele individuale din magazine.

Asta nu mai e o scurgere de date. E o hartă plus setul de chei. Un token reutilizat pe toate depozitele înseamnă că o singură credențială compromisă deschide tot, iar tiparele de SSH către magazine sugerează o cale către sistemele fizice din puncte de vânzare.

Prețul e cel mai ciudat detaliu

Cinci mii de euro pentru credențiale de producție ale unui lanț cu peste 13.000 de magazine este, obiectiv, foarte puțin.

Sunt câteva explicații plauzibile, niciuna liniștitoare. Vânzătorul poate nu înțelege ce are. Poate contul e nou și încearcă să-și construiască reputație pe forum. Sau credențialele au fost deja rotite, iar el vinde ceva ce știe că expiră.

Pentru un cumpărător care înțelege, însă, 5.000 de euro e un preț de nimic pentru punctul de plecare al unui atac de ransomware într-un retailer de dimensiunea asta. Prețul mic nu înseamnă risc mic — înseamnă că bariera de intrare pentru următorul atacator e joasă.

• ▸Security Affairs — analiza datelor revendicate

Vectorul: contul unui furnizor, nu al tău

Żabka spune că accesul a venit prin contul unui furnizor extern de servicii. E tiparul care se repetă în tot mai multe incidente europene: nu ești spart tu, e spart cineva care are acces la tine.

Din perspectiva apărării, asta mută întrebarea. Nu „cât de bine îmi protejez eu conturile", ci „ce poate face contul furnizorului meu dacă e compromis, și aș observa?".

Un furnizor cu acces la Jira și la depozitele de cod are, de regulă, drepturi acordate la începutul colaborării și nerevizuite de atunci.

• ▸ENISA — securitatea lanțului de aprovizionare

Ce faci practic

• ▸Inventariază conturile furnizorilor: cine are acces, la ce, de când, și cine a aprobat
• ▸Aplică MFA obligatoriu pe conturile externe — sunt exact cele care scapă din politica internă
• ▸Nu reutiliza tokenuri de acces între depozite; un token per scop, cu expirare
• ▸Scanează depozitele pentru secrete hardcodate și fișiere .env comise din greșeală — există unelte gratuite care fac asta în minute
• ▸Segmentează accesul la serverele din locații: un tipar SSH uniform pe 13.000 de magazine e un singur punct de eșec
• ▸Monitorizează forumurile pentru numele companiei tale — Żabka a aflat de pe forum, nu din sistemele proprii

Ce a comunicat compania și statul

Żabka a blocat accesul, a notificat autoritatea poloneză pentru protecția datelor și informează persoanele ale căror date personale ar putea fi afectate.

Ministrul polonez al Afacerilor Digitale, Krzysztof Gawkowski, a declarat că, pe baza informațiilor transmise guvernului, breșa nu a afectat datele clienților, informațiile de plată sau operațiunile de retail.

Merită păstrată distincția: „nu au fost afectate datele clienților" e o afirmație despre ce s-a luat, nu despre ce se poate face cu ce s-a luat. Credențialele de producție rămân o problemă chiar dacă niciun client nu apare în setul de date.