Sigorta primi hesaplayıcısının kötüye kullanıldığı sigorta şirketi hack vakası

 (eaton-works.com)
1 puan yazan GN⁺ 2024-01-18 | 1 yorum | WhatsApp'ta paylaş
  • Eicher Motors sigorta primi hesaplayıcısı alt alan adında Microsoft kurumsal bulut kimlik bilgileri açığa çıktı ve TTIBI’nin noreply e-posta hesabına giriş yapılabildi
  • Söz konusu e-posta gönderim API’si kimlik doğrulama olmadan e-posta gönderiyordu; sunucu hata yanıtındaki gönderim günlükleri base64 ile kodlanmış parolayı ortaya çıkardı
  • Açığa çıkan hesapta müşterilere gönderilmiş 657.000 e-posta, yaklaşık 25 GB boyutunda sigorta poliçesi PDF’leri, müşteri bilgileri, parola sıfırlama bağlantıları ve OTP’ler bulunuyordu
  • Hesapta iki aşamalı kimlik doğrulama yoktu; Microsoft kurumsal dizini, SharePoint ve Teams gibi diğer bulut kaynaklarına da erişilebiliyordu
  • Savunmasız API, bildirimin ardından 2 aydan uzun süre geçtikten sonra kimlik doğrulama isteyecek şekilde düzeltildi; 27 Ocak 2024 itibarıyla e-posta hesabının parolası da değiştirildiği için artık giriş yapılamıyor

Eicher sigorta primi hesaplayıcısından başlayan TTIBI ihlali

  • Eicher Motors sistemleri incelenirken Toyota Tsusho Insurance Broker India, kısaca TTIBI’ye ait noreplyeicher@ttibi.co.in Microsoft e-posta hesabının açığa çıktığı görüldü
  • TTIBI, Japonya merkezli Toyota Tsusho Insurance Management Corporation bünyesinde faaliyet gösteren Hindistanlı bir sigorta brokerıdır ve 2008’de kurulmuştur
  • Eicher Motors, Hindistanlı bir otomotiv üreticisidir; Royal Enfield Motors motosikletlerini ve Volvo Group ile ortak girişimi olan VE Commercial Vehicles’ın ticari araçlarını üretir
  • İki şirket arasında sigortayla ilgili bir iş ortaklığı vardı ve TTIBI sitesinde Eicher’a özel bir alt alan adı bulunuyordu

Açığın keşfedilme yolu

  • MY EICHER Android uygulaması analiz edilirken API arayüzü Java sınıfında sigorta primi hesaplayıcısı URL’si bulundu
  • Sigorta primi hesaplayıcısı web sitesinin kaynak kodunda istemci taraflı bir e-posta gönderim mekanizması yer alıyordu
  • Kodda Bearer Authorization kullanımına dair izler bulunduğu için kimlik doğrulama gerekiyor gibi görünüyordu; ancak doğrudan API isteği oluşturulduğunda 401 Unauthorized yerine e-posta gerçekten gönderildi
  • Sunucu hata yanıtı, e-posta gönderim günlüklerini de döndürüyordu ve bunların içinde base64 ile kodlanmış parola bulunuyordu

noreply hesabında kalan veriler

  • noreplyeicher@ttibi.co.in, otomatik e-posta gönderimi için kullanılan bir noreply hesabıydı; ancak TTIBI’de gerçekten giriş yapılabilen bir hesaptı
  • Bu hesapta müşterilere gönderilen tüm e-posta kayıtları duruyordu
    • Toplam 657.000 e-posta
    • Yaklaşık 25 GB
    • Müşteri bilgileri
    • Sigorta poliçesi PDF’leri
    • Parola sıfırlama bağlantıları
    • OTP’ler
  • OTP’ler ve parola sıfırlama bağlantıları da görülebildiğinden, müşteri sigorta hesaplarının ele geçirilmesinde kötüye kullanılabilecek bilgiler içeriyordu
  • Aynı hesapla Microsoft bulut kaynaklarına da erişilebiliyordu
    • Kurumsal dizin
    • SharePoint
    • Teams

Açığın etkisini büyüten güvenlik hataları

  • İstemci taraflı e-posta gönderim özelliği

    • İstemcinin konu, gövde ve alıcıyı kontrol edebildiği bir e-posta gönderim özelliği, kötü amaçlı e-posta gönderimi için suistimal edilebilir
    • E-postalar gerçek hesaptan gönderildiği için e-posta itibarının zarar görmesine ve phishing saldırılarına yol açabilir

  • API kimlik doğrulamasının eksik olması

    • Ön yüzde kimlik doğrulama token’ı kullanımına dair izler vardı, ancak sunucu token’ı gerçekten kontrol etmiyordu
    • Sunucu token’ı doğrulasaydı bu saldırının engellenmesi mümkün olabilirdi

  • Aşırı ayrıntılı API hata yanıtları

    • API işleme sırasında hata oluştuğunda istemciye fazla bilgi döndürülüyordu
    • Bu vakada hata yanıtı parolayı doğrudan açığa çıkardı

  • İki aşamalı kimlik doğrulamanın olmaması

    • Microsoft hesabına girişte iki aşamalı kimlik doğrulama veya başka bir giriş doğrulama istemi yoktu
    • İki aşamalı kimlik doğrulama olsaydı başarılı giriş yapmak zorlaşabilirdi

  • E-postaların saklanması

    • Hesabın gönderip aldığı tüm e-postalar saklandığı için büyük miktarda müşteri bilgisine kolayca erişilebildi
    • Bir saklama politikası olsaydı müşteri verilerinin açığa çıkmasının etkisi azaltılabilirdi

Müdahale ve mevcut durum

  • 17 Ocak 2024 itibarıyla TTIBI’nin açığı öğrenmesinin üzerinden 5 aydan fazla geçmişti, ancak e-posta hesabının parolası hâlâ değiştirilmemişti
  • 27 Ocak 2024 güncellemesine göre e-posta hesabının parolası değiştirildi ve artık söz konusu hesaba giriş yapılamıyor
  • Savunmasız API sonunda kimlik doğrulama gerektirecek şekilde düzeltildi
  • Anormal Microsoft oturum açma uyarıları olup olmadığı doğrulanmadı; uyarılar varsa görmezden gelinmiş veya kontrol edilmemiş olabilir

Bildirim zaman çizelgesi

  • TTIBI, Toyota’nın HackerOne güvenlik açığı açıklama programı kapsamında olmadığı için Hindistan CERT-In birimine bildirildi
  • 7 Ağustos 2023: CERT-In’e açığın ayrıntılı raporu gönderildi
  • 8 Ağustos 2023: CERT-In bir vaka kimliği oluşturdu ve TTIBI ile iletişime geçeceğini bildirdi
  • 1 Eylül 2023: Sürece dair durum güncellemesi istendi
  • 6 Eylül 2023: CERT-In, açığı TTIBI’ye ilettiğini ve ek güncellemeleri paylaşacağını bildirdi
  • 8 Ekim 2023: Etkilenen web sitesi kapatıldı, ancak savunmasız API durduğu için CERT-In bilgilendirildi
  • 11 Ekim 2023: CERT-In, TTIBI’nin açığı düzelttiğini söyledi; ancak kontrol sonucunda açığın hâlâ mevcut olduğu görüldü
  • 18 Ekim 2023: E-posta gönderim API’si kimlik doğrulama isteyecek şekilde değiştirildi ve açık düzeltildi
  • Sonrasında bug bounty ödülü olup olmadığını teyit etmeye yönelik yazışmalar sürdü, ancak TTIBI yanıt vermedi ve vaka 22 Aralık 2023’te kapatıldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-18
Hacker News yorumları

  • Hintli değilim ama Tata tarzı büyük IT şirketlerinde çalışan biri olarak bu bana fazlasıyla gerçekçi geliyor
    Burada işi ucuza kapatınca ödüllendirilen bir yönetim kültürü, geliştiricinin inisiyatifini ya da kendini gerçekleştirmesini bastıran bir kültür büyük rol oynuyor
    ABD’de böyle bir şey görsem hemen ayrılırdım, ama bunlarda işten ayrılırsan 90 günlük maaş geri alınıyor, dolayısıyla fiilen seçenek yok
    Yöneticilerin çoğu teknik geçmişe sahip değil; duymak istediklerini duyuyor, yanlış olduğunu söyleyenleri duymak istemiyorlar
    Bunun aynı ekip ya da aynı şirket tarafından yapılmış bir sonuç olduğunu varsaymak bile yanlış olabilir; çünkü geliştiricileri ciddi biçimde silolara ayırıyorlar: API geliştiricisi, Office 365 geliştiricisi, frontend geliştiricisi gibi çok dar uzmanlıklara bölüyorlar ve kişi “sertifikalı” olmadığı alanlara dokunmuyor
    100 milyon dolarlık proje toplantılarında bile SendGrid maliyeti üzerine ciddi ciddi kavga ediliyor; sonunda da “SendGrid deneyimi” olmadığı için bir geliştiricinin bunun Office 365 ile yapılabileceğini söylemesi gibi bir noktaya geliniyor
    Güvenlik ekibinin bütçesi, “zaten güvenli olması gerektiği” gerekçesiyle ilk kesilen kalem oluyor; güvenlikten sorumlu diye işe alınmış yeğen yaşındaki kişiye anlatsan da hükümet ya da biri dava açmayacaksa neden uğraşalım tavrına dönüşüyor
    Geliştiriciler geliştirmeye teşvik edilmiyor; biletleri kapatmayı ve soru sormamayı öğreniyorlar
    Hindistan’daki zeki geliştiricilerle çalışıyorum, ama bu bir inovasyon kültürü değil; çağrı merkezi gibi muamele görmek. Senaryonun dışına çıkma, dar bir problem alanında kal, başarısız olmadığın sürece kazanıyorsun gibi

    • 90 günlük maaş geri alma gibi şeyler sendikalar ve işçi hakları olmadığında ortaya çıkan sonuçtur
      Yakında bize de gelebilir

  • 2000’lerin ortaları-sonlarında muhatap olduğum Honda bağlantılı bir otomobil bayisi, finans başvurularını artan sayısal ID’lerle saklıyordu
    Bildirmedim ama SSN, doğum tarihi, ad, adres gibi New Jersey sakinlerine ait birçok hassas bilgiye bakabiliyordum
    O zamanlar bug bounty fiilen yoktu, CFAA ise vardı; bu yüzden bildirmedim
    Kendi başvurumu sildirdim ama açık, yeni sisteme geçilene kadar yıllarca kaldı; yeni sistem de açık görünüyor gibiydi
    Sonrasında o bayiyle iş yapmadım; bugün de otomobil bayileri ve finans başvuruları konusunda çok dikkatliyim. Biraz daha pahalı olsa bile genellikle finansmanı başka yerden alıyorum

  • Güvenlik hatasının kendisi korkunç, ama deneyimsiz bir geliştiriciye anlayış sınırının çok ötesinde bir iş verilmiş olması bunu bir ölçüde açıklıyor gibi
    Fakat gizli müşteri belgelerinin bir e-posta hesabında saklanmasına nasıl onay verildiğini hiç anlayamıyorum
    Bu, bu işi nasıl yürüteceğini bilen sorumlu kimsenin olmadığı anlamına gelir; bir yan kuruluş ya da dış kaynak ortağıysa da kimsenin hiç denetim yapmadığı anlamına gelir
    Hem şirket sahipleri hem de bu işi ona veren taraf açısından cezai ihmale yakın bir davranış

    • Bu düzeyde bir yetkinlikle, birinin onay vermiş olma ihtimali de düşük görünüyor
      Muhtemelen posta sunucusunda gönderilmiş postaları saklama özelliği vardı ve “noreply” adresi için gerçek bir hesap kullanma yönündeki aptalca kararın yan ürünü olarak ortaya çıktı
    • Oldukça büyük bir emlak aracılık sisteminde tüm giden e-postaların paylaşılan bir hesaba gizli kopya atıldığını ve herkesin bunu Outlook’a senkronize ettiğini görmüştüm
      Denetim kaydı, hata ayıklama aracı ve veritabanı yedeği işlevi görüyordu
      Çalışanların tüm müşteri bilgilerini yeni işlerine götürdüğünü öğrendikten sonra ancak değiştirdiler

  • “5 aydan fazla geçmesine rağmen TTIBI açığı bildiği halde e-posta hesabının parolasını değiştirmediyse”, umarım en azından hata günlüklerinden Base64 parolayı çıkarmışlardır
    Kesin yapmışlardır. Değil mi?

  • Etkisi kelimenin tam anlamıyla tüm SharePoint ve Outlook’a erişim düzeyinde devasa, ama yolun istemci tarafı JavaScript’e bakmak kadar basit olması onu oldukça sıra dışı bir açık yapıyor
    Küçük bir nokta: ekran görüntülerinde hassas bilgiler için bulanıklaştırma yerine siyah bloklarla kapatma yönteminin daha iyi olduğunu düşünüyorum. Tedbirli olmaktan zarar gelmez

    • Günümüzde bulanıklaştırma işlevi, gerçek metni bulanıklaştırmak yerine sadece bulanık görünmesini sağlayan bir işlem olabilir

  • “Teşekkür mektubu” ile biten yapı yüzünden bu tür açıkların çoğu white hat’ler tarafından bildirilip kamuya açıklanmıyor; hacker’lar tarafından aktif biçimde suistimal ediliyor
    Müşteri kişisel verileriyle ilgili belirli bir seviyenin üzerindeki güvenlik ihmali yönetimi için şirketleri sorumlu tutan yasal bir çerçeve olmalı

    • Avrupa’da zaten böyle bir şey var, adı da GDPR

  • Hindistan’da veri sızıntısından daha büyük sorunlar var
    Bunlardan biri istikrarlı elektrik arzı
    Hindistan’da yeterli elektrik olup da hacklenmenin başlıca endişe olduğu günü bekliyorum
    Her ay 100 bin km fiber optik döşeniyor, her gün 350 adet 5G baz istasyonu kuruluyor

  • İzleme e-postası endpoint’inin fiilen bir iletişim işçisi/ajan/runner gibi tasarlanıp sonra kendi haline bırakılarak sürekli şiştiğine de bakmak lazım
    Bu, e-posta kullanımının izlenmediği ve “bu e-posta takma adının depolama maliyeti neden diğerlerinin birkaç katı?” gibi anormal davranışları arayan tamamlayıcı kontrollerin de olmadığı anlamına geliyor
    “noreply hesabı müşterilere gönderilen tüm kayıtları potansiyel olarak içerdiğinden kuruluşun en önemli hesabı olabilir” sözü işin özü

  • “Hindistan genelinde önde gelen bir sigorta brokeri” yetkin geliştirici çalıştıracak paraya sahip değilse, müşterileri riske atan birçok ciddi sorunu bulup sorumlu biçimde bildiren kişiye en azından üç beş kuruş vermeli
    Ama bunu yapmadılar; hatta ele geçirilmiş e-posta hesabının parolasını hâlâ sıfırlamamış olmaları inanılır gibi değil
    Böyle davranan bir şirkete bir şeyi düzgün yapacağı konusunda nasıl güvenilebilir?
    Toyota Tsusho Insurance Broker India, vebadan kaçar gibi uzak durulması gereken bir şirket gibi görünüyor

    • Benzer düzeyde bir beceriksizliği bizzat gördüm
      Bu, birinin önemli bir güvenlik uyarısını aktif olarak görmezden gelmesi değil; ne dediğinizi anlamadığı bir durum
      İşlettiği ortamı ya da karşı karşıya olduğu görevi temelden kavramıyor; kullandığınız teknik terimler kendisi ya da ekibi için hiçbir şey ifade etmediğinden sadece ortadan kaybolmanızı umuyor
      “Kafa karıştıran e-postalar göndermeyi bırakın. Önemli işlerimiz var” tavrı
      Çözmek için organizasyon düzeyinde üst yönetimin değiştirilmesi gerekir; IT sorumlusu ve elinin değdiği her şey gitmeli
    • Alternatiflerin çok az olması büyük olasılık; zaten bu sorunu doğuran şey de muhtemelen baştan bu

  • Sorunun bir kısmı, bu gelen kutusunu fiilen “ücretsiz” bir SMTP hesabı gibi kullanıp giden e-posta maliyetinden kaçınmaya çalışmalarında
    SES gibi bir şey kullanılsaydı, bu hesabın gönderilmiş/gelen kutusunda bu kadar çok hassas bilgi olmazdı
    SES 1.000 e-posta başına 0,10 dolar ile çok ucuz

    • Teknik olarak doğru, ama burada SES kullanmanın gerçek maliyeti muhtemelen geliştirme süresi olurdu
      Gönderilen tüm e-postaları saklamak ve geliştirici olmayan iş birimi çalışanlarının geçmiş mesajları görüp arayabileceği bir arayüz yapmak gerekirdi
      Bu “ücretsiz” SMTP yaklaşımının tüm işlevlerini kullanıyorlardıysa geliştirme ve bakım maliyeti epey yüksek