Tim tanggap darurat komputer nasional Jepang, JPCERT/CC, telah mengaitkan lonjakan kebocoran data web baru-baru ini dengan dua penyebab utama: penyalahgunaan API aplikasi seluler dan cacat perangkat lunak yang diketahui, termasuk bug SQL injection yang dieksploitasi di Metabase. Kisah ini menjadi pengingat berguna bahwa kebocoran data web Jepang dan kelemahan API seluler biasanya merupakan masalah di sisi server, pada sistem yang tidak dapat dilihat atau dikendalikan oleh pengguna.

Apa yang JPCERT/CC temukan di balik kebocoran data Jepang

Menurut laporan tersebut, JPCERT/CC menghubungkan lonjakan kebocoran data Jepang baru-baru ini dengan penyalahgunaan API aplikasi seluler dan kerentanan yang sudah diketahui publik. Salah satu contoh yang disebutkan adalah cacat SQL injection di Metabase, yang telah dieksploitasi oleh penyerang.

Benang merahnya adalah bahwa ini bukan serangan eksotis. Cacat yang diketahui dan antarmuka yang kurang terlindungi menjadi titik masuknya. Ringkasan materi sumber tidak mengaitkan kebocoran tersebut dengan apa pun yang dilakukan pengguna individu, dan itu penting bagi cara pembaca berpikir tentang risiko: data pribadi terekspos oleh layanan yang menyimpannya.

Bagaimana SQL injection dan API seluler yang terekspos membocorkan data pribadi

Dua istilah teknis mendorong kisah ini, jadi penting untuk mendefinisikannya secara sederhana.

SQL injection terjadi ketika aplikasi memasukkan input yang diberikan pengguna ke dalam kueri basis data tanpa memeriksanya dengan benar. Penyerang dapat menyusun input yang mengubah kueri, yang mungkin memungkinkan mereka membaca data yang seharusnya tidak pernah mereka lihat. Metabase adalah alat analitik data yang terhubung ke basis data, sehingga cacat di dalamnya dapat menempatkan catatan yang mendasarinya dalam jangkauan.

Penyalahgunaan API seluler adalah jalur berbeda menuju hasil serupa. Aplikasi seluler berbicara dengan server perusahaan melalui API. Jika API tersebut tidak memverifikasi dengan benar siapa yang meminta, atau apa yang boleh mereka ambil, seseorang dapat mengirim permintaan langsung ke API itu, di luar aplikasi, dan menarik data secara massal. Aplikasi di ponsel Anda mungkin terlihat normal sepenuhnya sementara server di belakangnya memberikan lebih dari yang seharusnya.

Dalam kedua kasus, kelemahannya terletak pada organisasi yang menjalankan layanan. Menambal cacat yang diketahui dan memperketat kontrol akses API adalah solusinya, dan keduanya merupakan tugas operator, bukan pelanggan.

Apa yang harus diperiksa pengguna dan layanan Jepang sekarang

Bagi organisasi, penekanan laporan pada cacat yang diketahui mengarah pada daftar periksa dasar:

  • Pastikan bahwa setiap penerapan Metabase diperbarui ke versi yang mengatasi bug SQL injection yang dieksploitasi.
  • Tinjau API aplikasi seluler untuk memastikan setiap permintaan diautentikasi dan bahwa pengguna hanya dapat mengambil catatan mereka sendiri.
  • Perlakukan kerentanan yang diungkapkan secara publik sebagai hal yang mendesak, karena penyerang sudah menggunakannya.

Bagi pengguna individu, hanya sedikit yang dapat dikonfigurasi secara langsung, tetapi Anda dapat mengawasi tanda-tanda bahwa layanan yang Anda gunakan telah terdampak: email notifikasi, pesan reset kata sandi yang tidak terduga, atau phishing yang merujuk detail yang seharusnya hanya diketahui perusahaan tersebut.

Cara membatasi paparan Anda setelah kebocoran

Penting untuk bersikap langsung tentang satu hal: VPN tidak memperbaiki ini. VPN mengenkripsi lalu lintas antara perangkat Anda dan server VPN dan menyamarkan alamat IP Anda, yang berguna untuk privasi di jaringan yang tidak tepercaya. VPN tidak melakukan apa pun terhadap cacat pada basis data atau API yang menyimpan informasi Anda. Jika suatu layanan membocorkan catatan Anda, jalur yang dilalui data untuk sampai ke sana tidak relevan dengan bagaimana data itu terekspos.

Yang membantu adalah membatasi kerusakan ketika kebocoran terjadi:

  • Gunakan kata sandi unik untuk setiap akun. Jika satu layanan dilanggar, penyerang tidak dapat menggunakan kembali kredensial yang sama di tempat lain. Pengelola kata sandi membuat ini praktis.
  • Aktifkan pemantauan kebocoran. Banyak browser, pengelola kata sandi, dan layanan independen akan memperingatkan Anda ketika email Anda muncul dalam kebocoran yang diketahui.
  • Bagikan lebih sedikit data dengan aplikasi. Kolom yang tidak pernah Anda berikan tidak dapat bocor. Lewati detail opsional, dan gunakan alamat email terpisah untuk layanan dengan kepercayaan lebih rendah.
  • Aktifkan autentikasi multi-faktor di tempat yang menyediakannya, sehingga kata sandi yang bocor saja tidak cukup.
  • Berhati-hatilah dengan pesan yang tidak terduga. Detail kontak yang bocor sering menjadi bahan bakar phishing yang ditargetkan.

Apa Artinya Ini Bagi Anda

Temuan JPCERT/CC menegaskan bahwa paparan Anda sangat bergantung pada seberapa baik perusahaan yang Anda percayai memelihara sistem mereka. Anda tidak dapat menambal server mereka, tetapi Anda dapat mengurangi apa yang dipertaruhkan. Anggaplah bahwa sebagian data Anda pada akhirnya akan terekspos di suatu tempat, dan pastikan paparan itu tidak membuka kunci akun Anda yang lain.

Untuk contoh terkini tentang bagaimana paparan skala besar di Jepang terlihat, lihat liputan kami tentang pelanggaran KDDI yang mengekspos 12,2 juta email pelanggan di Jepang. Alamat email saja mungkin tampak sepele, tetapi itulah jenis data yang menjadi bahan kampanye phishing.

Poin-poin penting

Kebocoran data web Jepang yang terkait dengan penyalahgunaan API seluler dan perangkat lunak yang belum ditambal adalah masalah di sisi layanan, dan VPN tidak akan menyelesaikannya. Gunakan kata sandi unik, aktifkan pemantauan kebocoran, nyalakan autentikasi multi-faktor, dan berikan aplikasi hanya data yang benar-benar mereka butuhkan. Kebiasaan tersebut tidak akan menghentikan pelanggaran, tetapi dapat mencegahnya menjadi masalah yang jauh lebih besar bagi Anda.