Japán nemzeti számítógépes vészhelyzeti reagáló csapata, a JPCERT/CC a webes adatszivárgások közelmúltbeli növekedését két fő okra vezette vissza: a mobilalkalmazás-API-kkal való visszaélésre és ismert szoftverhibákra, köztük egy kihasznált SQL-injekciós hibára a Metabase-ben. A történet hasznos emlékeztető arra, hogy a japán webes adatszivárgások és a mobil API-k gyengeségei általában szerveroldali problémák, olyan rendszerekben, amelyeket a felhasználók nem látnak és nem irányítanak.

Amit a JPCERT/CC Japán adatszivárgásai mögött talált

A jelentés szerint a JPCERT/CC Japán közelmúltbeli adatszivárgási hullámát a mobilalkalmazás-API-kkal való visszaéléshez és a már nyilvánosan ismert sebezhetőségekhez köti. Az egyik megnevezett példa a Metabase SQL-injekciós hibája, amelyet a támadók kihasználtak.

A közös szál az, hogy ezek nem egzotikus támadások. Ismert hibák és gyengén védett interfészek a belépési pontok. A forrásanyag összefoglalója nem köti a szivárgásokat semmihez, amit az egyes felhasználók tettek, és ez fontos abból a szempontból, hogyan kell a olvasóknak a kockázatra gondolniuk: a személyes adatokat az azt tároló szolgáltatások tették ki.

Hogyan szivárogtatnak személyes adatokat az SQL-injekció és a szabadon elérhető mobil API-k

Két technikai kifejezés hajtja ezt a történetet, ezért érdemes őket egyszerűen meghatározni.

Az SQL-injekció akkor történik, amikor egy alkalmazás a felhasználó által megadott bemenetet megfelelő ellenőrzés nélkül adja át egy adatbázis-lekérdezésnek. A támadó olyan bemenetet készíthet, amely megváltoztatja a lekérdezést, ami lehetővé teheti számára olyan adatok olvasását, amelyeket soha nem lenne szabad látnia. A Metabase egy adatelemző eszköz, amely adatbázisokhoz csatlakozik, így a benne lévő hiba a mögöttes rekordokat is elérhetővé teheti.

A mobil API-kkal való visszaélés egy másik út hasonló eredményhez. Egy mobilalkalmazás egy API-n keresztül kommunikál egy vállalat szervereivel. Ha az az API nem ellenőrzi megfelelően, ki kérdez, vagy mit jogosult lekérni, valaki közvetlenül küldhet kéréseket neki, az alkalmazáson kívül, és tömegesen hívhat le adatokat. A telefonodon lévő alkalmazás teljesen normálisnak tűnhet, miközben a mögötte lévő szerver többet ad ki a kelleténél.

Mindkét esetben a gyengeség a szolgáltatást üzemeltető szervezetnél van. Az ismert hibák javítása és az API hozzáférés-vezérlésének szigorítása a megoldás, és mindkettő az üzemeltető feladata, nem az ügyfélé.

Mit kell most ellenőrizniük a japán felhasználóknak és szolgáltatásoknak

A szervezetek számára a jelentésnek az ismert hibákra helyezett hangsúlya egy alapvető ellenőrzőlistára mutat:

  • Győződjön meg arról, hogy minden Metabase-telepítés olyan verzióra van frissítve, amely kezeli a kihasznált SQL-injekciós hibát.
  • Vizsgálja felül a mobilalkalmazás-API-kat, hogy minden kérés hitelesítve legyen, és a felhasználók csak a saját rekordjaikat kérhessék le.
  • Kezelje sürgősként a nyilvánosan közzétett sebezhetőségeket, mivel a támadók már használják azokat.

Az egyéni felhasználók számára kevés közvetlenül beállítható dolog van, de figyelheti azokat a jeleket, amelyek arra utalnak, hogy egy Ön által használt szolgáltatás érintett: értesítő e-mailek, váratlan jelszó-visszaállítási üzenetek vagy olyan adathalász kísérletek, amelyek olyan részletekre hivatkoznak, amelyeket csak az adott vállalat ismerhet.

Hogyan korlátozza a kitettségét egy szivárgás után

Érdemes egy pontban egyenesnek lenni: a VPN nem oldja meg ezt. A VPN titkosítja a forgalmat az eszköze és egy VPN-szerver között, és elrejti az IP-címét, ami hasznos az adatvédelem szempontjából nem megbízható hálózatokon. Semmit sem tesz egy olyan adatbázis vagy API hibája ellen, amely az Ön adatait tárolja. Ha egy szolgáltatás kiszivárogtatja a rekordjait, az, hogy az adat milyen útvonalon jutott oda, irreleváns abból a szempontból, hogyan került ki.

Ami segít, az a kár korlátozása, amikor egy szivárgás bekövetkezik:

  • Használjon egyedi jelszót minden fiókhoz. Ha egy szolgáltatást feltörnek, a támadók nem tudják újra felhasználni ugyanazokat a hitelesítő adatokat máshol. Egy jelszókezelő ezt kivitelezhetővé teszi.
  • Kapcsolja be a szivárgásfigyelést. Számos böngésző, jelszókezelő és független szolgáltatás értesíti Önt, amikor az e-mail-címe ismert szivárgásban jelenik meg.
  • Osszon meg kevesebb adatot az alkalmazásokkal. Azok a mezők, amelyeket soha nem adott meg, nem szivároghatnak ki. Hagyja ki az opcionális adatokat, és használjon külön e-mail-címet az alacsonyabb bizalmi szintű szolgáltatásokhoz.
  • Kapcsolja be a többtényezős hitelesítést, ahol elérhető, hogy egy kiszivárgott jelszó önmagában ne legyen elegendő.
  • Legyen óvatos a váratlan üzenetekkel. A kiszivárgott kapcsolattartási adatok gyakran táplálják a célzott adathalászatot.

Mit jelent ez Önnek

A JPCERT/CC megállapításai megerősítik, hogy az Ön kitettsége nagymértékben attól függ, mennyire jól tartják karban rendszereiket azok a vállalatok, amelyekben megbízik. Nem tudja javítani a szervereiket, de csökkentheti azt, ami kockázatban van. Tegyük fel, hogy az adatai egy része végül valahol ki fog szivárogni, és gondoskodjon arról, hogy ez a szivárgás ne nyissa ki a többi fiókját.

A Japánban tapasztalható nagyszabású kitettség közelmúltbeli példájáért lásd a KDDI-szivárgásról szóló tudósításunkat, amely 12,2 millió ügyfél e-mail-címét tette ki Japánban. Az e-mail-címek önmagukban jelentéktelennek tűnhetnek, de pontosan az ilyen adatok táplálják az adathalász kampányokat.

Fő tanulságok

A mobil API-kkal való visszaéléshez és a nem javított szoftverekhez kötődő japán webes adatszivárgások szolgáltatóoldali probléma, és a VPN nem oldja meg őket. Használjon egyedi jelszavakat, kapcsolja be a szivárgásfigyelést, aktiválja a többtényezős hitelesítést, és csak azt az adatot adja meg az alkalmazásoknak, amelyre valóban szükségük van. Ezek a szokások nem állítják meg a szivárgást, de megakadályozhatják, hogy az sokkal nagyobb problémává váljon Ön számára.