Japonya'nın ulusal bilgisayar acil durum müdahale ekibi JPCERT/CC, son dönemde artan web veri sızıntılarını iki ana nedene bağladı: kötüye kullanılan mobil uygulama API'leri ve istismar edilen bir Metabase SQL enjeksiyonu açığı dahil olmak üzere bilinen yazılım kusurları. Bu haber, Japonya'daki web veri sızıntılarının ve mobil API zayıflıklarının genellikle kullanıcıların göremediği veya kontrol edemediği sistemlerde, sunucu tarafındaki sorunlar olduğunu hatırlatması açısından faydalıdır.

JPCERT/CC'nin Japonya'daki veri sızıntılarının ardında ne bulduğu

Rapora göre JPCERT/CC, Japonya'da son dönemde artan veri sızıntılarını mobil uygulama API'lerinin kötüye kullanımına ve halk tarafından zaten bilinen güvenlik açıklarına bağlıyor. Adı geçen örneklerden biri, saldırganların istismar ettiği Metabase'deki bir SQL enjeksiyonu açığı.

Ortak nokta, bunların sıra dışı saldırılar olmaması. Bilinen kusurlar ve yeterince korunmayan arayüzler giriş noktaları. Kaynak materyalin özeti, sızıntıları bireysel kullanıcıların yaptığı herhangi bir şeye bağlamıyor ve bu, okuyucuların riski nasıl değerlendirmesi gerektiği açısından önemli: kişisel veriler, onları barındıran hizmetler tarafından ifşa edildi.

SQL enjeksiyonu ve açığa çıkan mobil API'ler kişisel verileri nasıl sızdırıyor

Bu haberi iki teknik terim yönlendiriyor, bu yüzden bunları açıkça tanımlamak faydalı olacak.

SQL enjeksiyonu, bir uygulamanın kullanıcı tarafından sağlanan girdiyi düzgün bir şekilde kontrol etmeden bir veritabanı sorgusuna aktarması durumunda ortaya çıkar. Bir saldırgan, sorguyu değiştiren bir girdi hazırlayabilir ve bu da asla görmemesi gereken verileri okumasına olanak tanıyabilir. Metabase, veritabanlarına bağlanan bir veri analizi aracıdır, dolayısıyla içindeki bir açık, alttaki kayıtları erişilebilir hale getirebilir.

Mobil API kötüye kullanımı ise benzer bir sonuca giden farklı bir yoldur. Bir mobil uygulama, bir API aracılığıyla bir şirketin sunucularıyla konuşur. Eğer bu API, kimin sorduğunu veya neyi almasına izin verildiğini düzgün bir şekilde doğrulamazsa, birisi doğrudan ona, uygulamanın dışından istekler gönderebilir ve verileri toplu halde çekebilir. Telefonunuzdaki uygulama tamamen normal görünebilirken, arkasındaki sunucu olması gerekenden fazlasını veriyor olabilir.

Her iki durumda da zayıflık, hizmeti işleten kuruluşta yatıyor. Bilinen kusurları yamamak ve API erişim kontrollerini sıkılaştırmak çözümlerdir ve her ikisi de operatörün işi, müşterinin değil.

Japon kullanıcılar ve hizmetler şimdi neyi kontrol etmeli

Kuruluşlar için raporun bilinen kusurlara yaptığı vurgu, temel bir kontrol listesine işaret ediyor:

  • Herhangi bir Metabase kurulumunun, istismar edilen SQL enjeksiyonu açığını gideren bir sürüme güncellendiğini doğrulayın.
  • Mobil uygulama API'lerini, her isteğin kimlik doğrulamasının yapıldığından ve kullanıcıların yalnızca kendi kayıtlarını alabildiğinden emin olmak için gözden geçirin.
  • Saldırganlar bunları zaten kullandığı için, kamuya açıklanan güvenlik açıklarını acil olarak değerlendirin.

Bireysel kullanıcılar için doğrudan yapılandırılacak çok az şey var, ancak kullandığınız bir hizmetin etkilendiğine dair işaretleri izleyebilirsiniz: bildirim e-postaları, beklenmedik parola sıfırlama mesajları veya yalnızca o şirketin bilmesi gereken ayrıntılara atıfta bulunan oltalama girişimleri.

Bir sızıntıdan sonra maruziyetinizi nasıl sınırlarsınız

Bir noktada açık olmakta fayda var: bir VPN bunu çözmez. Bir VPN, cihazınız ile bir VPN sunucusu arasındaki trafiği şifreler ve IP adresinizi gizler; bu, güvenilmeyen ağlarda gizlilik için faydalıdır. Bilgilerinizi saklayan bir veritabanındaki veya API'deki bir açığa karşı hiçbir şey yapmaz. Bir hizmet kayıtlarınızı sızdırırsa, verinin oraya ulaşmak için izlediği yol, nasıl ifşa edildiği açısından önemsizdir.

Yardımcı olan şey, bir sızıntı gerçekleştiğinde hasarı sınırlamaktır:

  • Her hesap için benzersiz bir parola kullanın. Bir hizmet ihlal edilirse, saldırganlar aynı kimlik bilgilerini başka yerlerde yeniden kullanamaz. Bir parola yöneticisi bunu pratik hale getirir.
  • İhlal izlemeyi açın. Birçok tarayıcı, parola yöneticisi ve bağımsız hizmet, e-postanız bilinen bir sızıntıda göründüğünde sizi uyarır.
  • Uygulamalarla daha az veri paylaşın. Hiç sağlamadığınız alanlar sızdırılamaz. İsteğe bağlı ayrıntıları atlayın ve daha düşük güvenilirliğe sahip hizmetler için ayrı bir e-posta adresi kullanın.
  • Sunulduğu yerlerde çok faktörlü kimlik doğrulamayı etkinleştirin, böylece tek başına sızdırılmış bir parola yeterli olmaz.
  • Beklenmedik mesajlara karşı dikkatli olun. Sızdırılan iletişim bilgileri genellikle hedefli oltalama girişimlerini besler.

Bu Sizin İçin Ne Anlama Geliyor

JPCERT/CC bulguları, maruziyetinizin büyük ölçüde güvendiğiniz şirketlerin sistemlerini ne kadar iyi koruduğuna bağlı olduğunu pekiştiriyor. Onların sunucularını yamayamazsınız, ancak ortada olan riski azaltabilirsiniz. Verilerinizin bir kısmının eninde sonunda bir yerde ifşa edileceğini varsayın ve bu ifşanın diğer hesaplarınızın kilidini açmadığından emin olun.

Japonya'da büyük ölçekli ifşanın nasıl göründüğüne dair yakın tarihli bir örnek için, Japonya'da 12,2 milyon müşteri e-postasını ifşa eden KDDI ihlali haberimize bakın. Tek başına e-posta adresleri önemsiz görünebilir, ancak bunlar tam da oltalama kampanyalarını besleyen türden verilerdir.

Önemli çıkarımlar

Japonya'daki mobil API kötüye kullanımı ve yamalanmamış yazılımlarla bağlantılı web veri sızıntıları hizmet tarafında bir sorundur ve bir VPN bunları çözmez. Benzersiz parolalar kullanın, ihlal izlemeyi etkinleştirin, çok faktörlü kimlik doğrulamayı açın ve uygulamalara yalnızca gerçekten ihtiyaç duydukları verileri verin. Bu alışkanlıklar bir ihlali durdurmayacak, ancak bir ihlalin sizin için çok daha büyük bir soruna dönüşmesini engelleyebilir.