Echipa națională de răspuns la incidente de securitate cibernetică din Japonia, JPCERT/CC, a asociat recenta creștere a scurgerilor de date web cu două cauze principale: API-urile de aplicații mobile abuzate și vulnerabilitățile software cunoscute, inclusiv un bug de injecție SQL exploatat în Metabase. Povestea este un memento util că scurgerile de date web din Japonia și slăbiciunile API-urilor mobile sunt de obicei probleme de partea serverului, în sisteme pe care utilizatorii nu le pot vedea sau controla.

Ce a descoperit JPCERT/CC în spatele scurgerilor de date din Japonia

Conform raportului, JPCERT/CC leagă recenta creștere a scurgerilor de date din Japonia de abuzul API-urilor aplicațiilor mobile și de vulnerabilități care erau deja cunoscute public. Unul dintre exemplele menționate este o vulnerabilitate de injecție SQL în Metabase, pe care atacatorii au exploatat-o.

Firul comun este că acestea nu sunt atacuri exotice. Vulnerabilitățile cunoscute și interfețele slab protejate sunt punctele de intrare. Rezumatul materialului sursă nu leagă scurgerile de ceva ce au făcut utilizatorii individuali, iar acest lucru contează pentru modul în care cititorii ar trebui să gândească riscul: datele personale au fost expuse de serviciile care le dețineau.

Cum scurg datele personale injecția SQL și API-urile mobile expuse

Doi termeni tehnici stau la baza acestei povești, așa că ajută să-i definim clar.

Injecția SQL are loc atunci când o aplicație transmite date furnizate de utilizator într-o interogare de bază de date fără a le verifica corespunzător. Un atacator poate construi date de intrare care modifică interogarea, ceea ce îi poate permite să citească date pe care nu ar trebui să le vadă niciodată. Metabase este un instrument de analiză a datelor care se conectează la baze de date, astfel încât o vulnerabilitate în el poate pune înregistrările subiacente la îndemână.

Abuzul API-urilor mobile este o rută diferită către un rezultat similar. O aplicație mobilă comunică cu serverele unei companii printr-un API. Dacă acel API nu verifică corespunzător cine întreabă sau ce are voie să recupereze, cineva poate trimite cereri direct către el, în afara aplicației, și poate extrage date în masă. Aplicația de pe telefonul tău poate părea perfect normală în timp ce serverul din spatele ei oferă mai mult decât ar trebui.

În ambele cazuri, slăbiciunea se află la organizația care operează serviciul. Remedierea vulnerabilităților cunoscute și strângerea controalelor de acces ale API-urilor sunt soluțiile, iar ambele sunt responsabilitatea operatorului, nu a clientului.

Ce ar trebui să verifice acum utilizatorii și serviciile japoneze

Pentru organizații, accentul raportului pe vulnerabilitățile cunoscute indică o listă de verificare de bază:

  • Confirmați că orice implementare Metabase este actualizată la o versiune care remediază bug-ul de injecție SQL exploatat.
  • Revizuiți API-urile aplicațiilor mobile pentru a vă asigura că fiecare cerere este autentificată și că utilizatorii pot recupera doar propriile înregistrări.
  • Tratați vulnerabilitățile divulgate public ca urgente, deoarece atacatorii le folosesc deja.

Pentru utilizatorii individuali, există puțin de configurat direct, dar puteți urmări semnele că un serviciu pe care îl folosiți a fost afectat: e-mailuri de notificare, mesaje neașteptate de resetare a parolei sau phishing care face referire la detalii pe care doar acea companie ar trebui să le cunoască.

Cum să-ți limitezi expunerea după o scurgere

Merită să fim direcți într-un punct: un VPN nu rezolvă acest lucru. Un VPN criptează traficul dintre dispozitivul tău și un server VPN și îți maschează adresa IP, ceea ce este util pentru confidențialitate pe rețele nesigure. Nu face nimic în privința unei vulnerabilități într-o bază de date sau un API care îți stochează informațiile. Dacă un serviciu îți scurge înregistrările, ruta pe care au ajuns datele acolo este irelevantă pentru modul în care au fost expuse.

Ce ajută cu adevărat este limitarea pagubelor atunci când are loc o scurgere:

  • Folosește o parolă unică pentru fiecare cont. Dacă un serviciu este compromis, atacatorii nu pot refolosi aceleași credențiale în altă parte. Un manager de parole face acest lucru practic.
  • Activează monitorizarea scurgerilor. Multe browsere, manageri de parole și servicii independente te vor alerta când e-mailul tău apare într-o scurgere cunoscută.
  • Partajează mai puține date cu aplicațiile. Câmpurile pe care nu le-ai furnizat niciodată nu pot fi scurse. Sari peste detaliile opționale și folosește o adresă de e-mail separată pentru serviciile cu încredere redusă.
  • Activează autentificarea multi-factor acolo unde este oferită, astfel încât o parolă scursă singură să nu fie suficientă.
  • Fii precaut cu mesajele neașteptate. Detaliile de contact scurse alimentează adesea phishingul țintit.

Ce înseamnă acest lucru pentru tine

Constatările JPCERT/CC întăresc faptul că expunerea ta depinde în mare măsură de cât de bine își întrețin sistemele companiile în care ai încredere. Nu poți repara serverele lor, dar poți reduce miza. Presupune că unele dintre datele tale vor fi expuse eventual undeva și asigură-te că acea expunere nu deblochează celelalte conturi ale tale.

Pentru un exemplu recent al modului în care arată expunerea la scară largă în Japonia, consultați relatarea noastră despre breșa KDDI care a expus 12,2 milioane de e-mailuri ale clienților din Japonia. Adresele de e-mail singure pot părea minore, dar sunt exact tipul de date care alimentează campaniile de phishing.

Concluzii cheie

Scurgerile de date web din Japonia legate de abuzul API-urilor mobile și software neactualizat sunt o problemă de partea serviciului, iar un VPN nu le va rezolva. Folosește parole unice, activează monitorizarea scurgerilor, activează autentificarea multi-factor și oferă aplicațiilor doar datele de care au cu adevărat nevoie. Aceste obiceiuri nu vor opri o breșă, dar pot împiedica ca una să devină o problemă mult mai mare pentru tine.