Mastercard DNS Yazım Hatası, Neredeyse 5 Yıl Boyunca Fark Edilmedi

 (krebsonsecurity.com)
1 puan yazan GN⁺ 2025-01-23 | 1 yorum | WhatsApp'ta paylaş
  • MasterCard, mastercard.com üzerindeki bazı trafiği yönlendiren Akamai DNS sunucu adlarından birini akam.net yerine yanlışlıkla akam.ne olarak yapılandırdı ve bu yazım hatası 30 Haziran 2020'den 14 Ocak 2025'e kadar neredeyse 5 yıl boyunca kaldı
  • Güvenlik araştırmacısı Philippe Caturegli, Nijer ülke üst seviye alan adı altındaki akam.ne alan adının kayıtlı olmadığını fark etti; 300 dolar ve yaklaşık 3 ay harcayarak alan adını alıp kötüye kullanım ihtimalini engelledi
  • akam.ne üzerinde DNS sunucusunu açınca dünyanın dört bir yanından günde yüz binlerce DNS isteği geldi ve aynı yazım hatasını yapan kuruluşlar arasında en büyük örnek MasterCard oldu
  • Bu alan adı kötüye kullanılsaydı yanlış yönlendirilen e-postaların alınması, etkilenen web siteleri için SSL/TLS sertifikaları edinilmesi ve bazı Windows kimlik bilgilerinin pasif olarak toplanması mümkün olabilirdi
  • MasterCard, “sistemler için bir risk yoktu” diyerek yazım hatasını düzeltti, ancak sonrasında Bugcrowd üzerinden LinkedIn gönderisinin kaldırılmasının istenmesi, açıklama yöntemiyle ilgili tartışma yarattı

Neredeyse 5 Yıl Boyunca Kalan DNS Yazım Hatası

  • MasterCard, mastercard.com ağındaki bazı trafiği yönlendirmek için Akamai'nin paylaşımlı 5 DNS sunucusunu kullanıyor
  • 30 Haziran 2020'den 14 Ocak 2025'e kadar bunlardan biri yanlış adla yapılandırılmıştı
    • Doğru sunucu adı akam.net ile bitmeliydi
    • Sorunlu yapılandırma akam.ne adresini işaret ediyordu
  • akam.ne, Batı Afrika'daki Nijer'in ülke üst seviye alan adı yönetim kapsamındaki bir alan adı

Araştırmacı Alan Adını Önce Aldı

  • Güvenlik danışmanlık şirketi Seralys kurucusu Philippe Caturegli bu yazım hatasını fark etti
  • Caturegli, akam.ne'nin henüz kayıtlı olmadığını düşünerek alan adını Nijer kayıt kurumu üzerinden aldı
    • Maliyet 300 dolar
    • Kayıt süreci yaklaşık 3 ay sürdü
  • DNS sunucusunu etkinleştirdikten sonra dünyanın her yerinden her gün yüz binlerce DNS isteği geldi
  • Aynı yazım hatasını yapan tek kuruluş MasterCard değildi, ancak gelen istek hacmine göre en büyük kuruluş oydu

Yazım Hatalı Alan Adının Yaratabileceği Riskler

  • Caturegli, akam.ne üzerinde bir e-posta sunucusu açsaydı mastercard.com veya diğer etkilenen alan adlarına giden yanlış yönlendirilmiş e-postaları alabilirdi
  • Erişimi kötüye kullansaydı, etkilenen web sitelerinin trafiğini alıp iletebilecek SSL/TLS sertifikaları edinme ihtimali de vardı
  • Çalışan bilgisayarlarından Microsoft Windows kimlik bilgilerinin pasif olarak alınabilmesi ihtimali de bulunuyordu
  • Caturegli bu tür eylemleri denemedi ve alan adını MasterCard'a devredebileceğini bildirdi
    • Bildirimde Krebs on Security yazarı da referans olarak yer aldı

MasterCard ve Bugcrowd'un Yanıtı

  • MasterCard birkaç saat sonra hatayı kabul etti, ancak operasyonel güvenlik açısından fiili bir risk olmadığını söyledi
    • “Sistemler için bir risk yoktu”
    • “Bu yazım hatası düzeltildi”
  • Sonrasında Caturegli'ye Bugcrowd üzerinden bir mesaj ulaştı
    • Mesajda, Caturegli'nin akam.ne'yi aldıktan sonra konuyu LinkedIn'de paylaşmasının etik güvenlik uygulamalarıyla uyumlu olmadığı ifade edildi
    • Ayrıca MasterCard'ın ilgili gönderinin kaldırılmasını istediği de yer aldı
  • Caturegli, kendisinin Bugcrowd programı üzerinden bildirim yapmadığını ve sorunu doğrudan MasterCard'a raporladığını söyledi
  • Açıklamadan önce etkilenen alan adını kaydederek kötüye kullanımı engellediğini ve bunun maliyetini de kendisinin karşıladığını belirtti

DNS Önbelleğinin Büyütebileceği Etki Alanı

  • Genel olarak kuruluşlar en az 2 yetkili DNS sunucusu kullanır, ancak yüksek istek alan kuruluşlar yük dengeleme için daha fazla DNS sunucusu alan adı kullanır
  • MasterCard 5 DNS sunucusu kullandığı için, bir saldırgan bunlardan sadece birini ele geçirirse tüm DNS isteklerinin yalnızca yaklaşık beşte birini görebilecekmiş gibi düşünülebilir
  • Ancak gerçek internet kullanıcıları Cloudflare veya Google gibi genel DNS çözücülerine dayandığı için etki daha büyük olabilir
    • Tek bir çözücünün yanlış ad sunucusuna sorgu göndermesi ve sonucu önbelleğe alması yeterlidir
    • DNS kayıtlarında uzun TTL ayarlanırsa, yanlış yönlendirmeler büyük bulut sağlayıcıları üzerinden yayılabilir
  • Caturegli, uzun TTL kullanılması halinde trafik yeniden yönlendirme kapsamının yalnızca beşte birden çok daha büyük olabileceğini düşünüyor

Sorunlu Alt Alan Adı ve Geçmiş Kayıt İzleri

  • Caturegli'nin paylaştığı ekran görüntüsünde yanlış yapılandırılan DNS sunucusu, MasterCard'ın az.mastercard.com alt alan adıyla ilişkili görünüyor
  • Bu alt alan adının tam olarak nasıl kullanıldığı belirsiz
  • Adlandırma kuralına bakılırsa Microsoft Azure bulutundaki üretim sunucularıyla ilgili bir alan adı gibi görünüyor; Caturegli, bu alan adlarının Microsoft internet adreslerine çözümlendiğini söyledi
  • akam.ne daha önce de kayıt edilmişti
    • Aralık 2016'da um-i-delo@yandex.ru e-postasını kullanan bir kullanıcı tarafından kaydedildi
    • Yandex, bu hesabın Moskova'daki “Ivan I.” kişisine ait olduğunu gösteriyor
    • DomainTools.com'un pasif DNS kayıtlarına göre alan adı 2016'dan 2018'e kadar Almanya'daki internet sunucularına bağlıydı ve 2018'de süresi doldu
  • Eski bir Cloudflare çalışanı, Caturegli'nin LinkedIn gönderisinin yorumlarında benzer bir vakayı ele alan bir rapora bağlantı verdi
    • Bazı kuruluşların AWS DNS sunucusu awsdns-06.net yerine yanlışlıkla awsdns-06.ne yazmış olabileceği bir yazım hatalı alan adı vakasıydı
    • DomainTools'a göre bu yazım hatalı alan adı da bir Yandex kullanıcısına kayıtlıydı ve aynı Alman ISP olan Team Internet üzerinde barındırılıyordu

İlgili okumalar

1 yorum

 
GN⁺ 2025-01-23
Hacker News görüşleri

  • Bu vakadaki gibi herkese açık kaydedilebilen nameserver'lar, dangling DNS sorununun görece nadir bir alt türü sadece; daha yaygın olan durum ise alan adının doğrudan saldırganın ele geçirebileceği bir bulut sağlayıcısı IP adresine eşlenmiş olmasıdır
    Bulut servisleri çok geniş bir kapsama sahip ve çoğu zaman küresel görünürlükleri zayıf olduğundan, bulut kullanan şirketlerin alt alan adlarından bir yerlerde böyle bir zafiyete sahip olma ihtimali yüksektir
    Bug bounty programları çoğu zaman “subdomain takeover”u topluca kapsam dışı bırakıyor, ancak bulunduğunda kolayca istismar edilebiliyor ve bu tür yapılandırma hataları nedeniyle hassas bilgilerin sızdığı iç ve açık veriler de var
    Mevcut zafiyet açıklama ortamı, şirketlerin gerçek bir zafiyeti kabul etmekten kaçınmasını fazlasıyla kolaylaştırıyor ve iyi niyetli araştırmacıların etik ve hukuki kısıtlar nedeniyle sağlayıcının istediği düzeyde kanıt sunmasını zorlaştırıyor
    Bu tür zafiyetlerle gerçekten TLS sertifikası çıkarılabilmesi riskinin de olduğundan az değerlendirildiği görülüyor
    [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
    [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
    [3] https://pauley.me/post/2022/cloud-squatting/
    [4] https://arxiv.org/pdf/2204.05122

    • Yalnızca IP değil, “kuruluşun artık kontrol etmediği paylaşımlı bulut kaynaklarını işaret eden DNS kayıtları” da devasa bir kategori oluşturuyor ve şirket ne kadar büyükse o kadar yaygın görülüyor
      Örneğin serbest bırakılmış bir S3 bucket'ını işaret eden CNAME, Azure Website/WebApp instance'ları, elastik olmayan IP'leri işaret eden A kayıtları, artık kuruluşun AWS hesabına ait olmayan Route53 nameserver'ları, silinmiş/devre dışı bırakılmış Heroku/Shopify/GitHub Pages hesapları ya da kapanmış bir transactional email sağlayıcısının alan adını işaret eden MX kayıtları buna dahil
      Bunun nedeni, BT'nin dağınık yapısı yüzünden ne yaptığını tam bilmeyen kişilerin altyapı kurması, söküm sırasında DNS'in unutulması, çok sayıda iştirak/marka/bölgesel organizasyon nedeniyle politika keşfi ve zorlamasının zorlaşması, ülke bazlı çok sayıda web sitesi ve uygulama bulunması ve güvenlik ekibine bildirilmeden dış hizmet sağlayıcıların kullanılmasının birikmesidir
      Bu alanda çalışan bir İsrailli siber güvenlik şirketinde Field CTO olarak görev yapıyorum; daha dün büyük bir bilgisayar parçası şirketi ve onun domain'i/PageRank'i/link'leri kullanılarak “işletilen” yaklaşık 12 Endonezya kumar sitesi hakkında konuştum ve bu tür konuşmalar her hafta tekrarlanıyor
    • Bug bounty'nin tüm “subdomain takeover” vakalarını geçersiz sayması fazla kaba bir yaklaşım; ayrım, domain'in ne kadar kolay ele geçirilebildiğine göre yapılmalı
      “Bir şekilde google.com'u ele geçirirsen Google kullanıcılarını tehlikeye atabilirsin” geçerli bir güvenlik zafiyeti değildir, ama burada olduğu gibi kayıtlı olmayan ya da süresi dolmuş bir domainin ele geçirilmesi ihlale yol açabiliyorsa bunun geçerli bir zafiyet sayılması gerekir
    • Bug bounty bildirimleri FCC gibi devlet kurumlarına da otomatik raporlanıp ilgili şirket e-postası CC'ye eklenirse daha etkili olabilir
      Şirketin bildirimi reddetmesi için açık kanıt sunması gerekir ve bu bildirimden kaynaklanan bir istismarın kanıtlanması ya da şirketin değişiklik yapıp rapordaki yeniden üretim adımlarının artık çalışmaması durumunda ödemenin yapılması veya para cezası uygulanması sağlanabilir
    • Bir kripto para borsasında, uygulama seviyesi kontrol olmadan daha hızlı load balancer'a erişebilen IP adresleri allowlist üzerinden yönetiliyordu
      Çok sayıda bulut IP'si tahsis edip tekrar tekrar eski IP'leri bularak normalden çok daha fazla kapasite elde ettiler ve daha yüksek rate limit ile istek gönderdiler
      Artık işe yarayacağını sanmıyorum; şimdi herkesin bildiği bir yöntem oldu

  • Bu hikâyede Bugcrowd kısmı beklenmedik
    E-posta ekran görüntüsü “Platform Behavior Standards Team”den gelmiş gibi görünüyor; eğer öyleyse Bugcrowd platform dışı davranışları da düzenlemeye çalışarak platform standartlarını aşırı geniş yorumlamış ya da Mastercard resmi Bugcrowd çalışanı gibi davranmış demektir
    İki ihtimal de pek kabul edilebilir değil
    [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

    • Bug bounty platformlarının, sorumlu açıklamayı teşvik etmekten çok onu kontrol altına almak ve engellemek için var olduğuna dair bir yorum var
      Bu iddiayı sık sık dile getiren biri görse muhtemelen daha iyi açıklayabilir
    • Üslup da ciddi biçimde kötü
      Sanki kişi zaten hatalı bulunmuş gibi yazılmış ve seçenekler sadece buna uymak ya da neden yanlış olduğunu daha ayrıntılı istemekle sınırlı
      Aslında hatalı olmadığını açıklama fırsatı yok
    • Benim deneyimime göre BugCrowd, raporun gerçekten şirkete ulaşmasını geciktirmek ve süründürmek için elinden gelen her şeyi yapıyor
      Şirket açısından bu, bounty ödemesini ve iç inceleme maliyetini azaltırken hukuken de makul bir inkâr edilebilirlik sağlıyor
    • Burada Bugcrowd çalışanları da vardır herhalde; o e-postayı açıklayabilirler

  • “Gerçek bir tehdit yoktu” türü bir yaklaşım, güvenlik araştırmacılarını bir dahaki sefere bu şirkette ya da başka şirketlerde etkiye dair daha fazla kanıt toplamak için daha derinlere sızmaya itebilir
    Şirket sözcüsünün “sorun yok” diyebilmesini istiyorsanız, etki küçültülse bile araştırmacının kabul edeceği kadar ödeme yapmanız gerekir
    Araştırmacı zaten doğru davranmış gibi görünmesine rağmen haberi bastırmak için araştırmacıya baskı yapılması, kredi kartı şirketinin buna neden ihtiyaç duyduğu, yoksa bunun PR ekibinin görevini yanlış anlamasından mı kaynaklandığı ya da bilgi güvenliği hatasının nihai sorumlusunun kendi görev süresinde rezil olmamak için şirket kaynaklarını mı kullandığı sorusunu doğuruyor

    • Bir nedeni var
      güvenlik araştırmacılarının sonuçları açıklamaktan korkmasını istiyorlar

  • Birkaç yıl önce Ukrayna'da çevrimiçi işlemlerin tamamı ya da çoğu masterpass adlı bir hizmet üzerinden doğrulanmak zorundaydı; bu da Mastercard tarzı bir 3DS gibi görünüyordu
    Ancak kurumsal web sitelerinde sıkça olduğu gibi SSL sertifikasının süresi doldu ve o anda belirli türdeki MasterCard kartlarıyla yapılan çevrimiçi işlemlerin tamamı ya da çoğu tamamen durdu
    Mastercard bir yıldan uzun süre sertifikayı yenilemedi; ne benim gibi müşterilerin ne de bankanın BT departmanının tüm iletişim çabaları işe yaradı ve daha sonra hizmeti sessizce kapattılar
    İnceleyince hizmetin Microsoft ekosisteminde (IIS) yazıldığı, sertifika zincirinin daha önce hiç duymadığım ara sertifikalar yüzünden anormal derecede uzun olduğu ve Ukrayna'dan epey uzaktaki bir üçüncü dünya ülkesinde barındırıldığı görüldü

    • masterpass, Mastercard'ın 3DS sürümü ve işlem şüpheli olduğunda dünya çapında kullanılıyor
      Mastercard'ın bakış açısından, o ülkedeki işlemler tamamen yerel taraflar arasında olsa bile bunların temelde şüpheli görüldüğü anlaşılıyor
      ABD'de süresi dolmuş halini hiç görmedim ve ülkelere göre trafiği nasıl işlediklerini bilmiyorum ama trafik Mastercard'a değil başka bir yere yönlendirilmiş gibi geliyor

  • akam.ne alan adının 2016'da Yandex e-posta kullanan Moskova'daki “Ivan I.” adına kaydedilmiş olması, 2016–2018 arasında Almanya'daki bir sunucuya bağlanması ve sonra süresinin dolması rahatsız edici
    Benzer şekilde, AWS DNS sunucusu awsdns-06.net yerine awsdns-06.ne yazan kurumları hedeflemiş görünen bir typo-domain'in de bir Yandex hesabına kaydedildiği ve aynı Alman ISP'si Team Internet'te (AS61969) barındırıldığı kısmı özellikle şüpheli

    • “Ivan I.” büyük olasılıkla Rusça sahte yaygın isim Ivan Ivanov anlamına geliyor; İngilizcedeki “John Smith” gibi

  • “Bu erişim kötüye kullanılsaydı etkilenen web sitelerinin trafiğini alıp iletebilecek SSL/TLS sertifikaları edinilebilirdi” sözü ile “sistemlerimiz için hiçbir risk yoktu” sözü aynı anda doğru olamaz
    Her iki tarafın da yalan söylemek ya da abartmak için teşviki var

    • Taraflardan birinin milyarlarca dolarlık yalan/abartı teşviki var; diğer taraf ise bütün gün sofistike saldırganların en kötü senaryolarını düşünüyor
      Konu bir CS:GO sunucusu olsaydı sofistike saldırganın en kötü saldırısı abartı sayılabilirdi ama dünyanın en büyük ödeme işleme şirketlerinden birinden bahsederken bu abartı değildir
    • Sertifikaların nasıl verildiği hakkında azıcık bilgi sahibi olan biri, araştırmacının haklı olduğunu ve MasterCard'ın saçmaladığını görebilir
      10 dakikalık araştırma bile aynı sonuca götürür
    • Etki yoksa onun yakaladığı DNS sorgularının tam listesini yayımlamasına izin versinler
      Bunu yapmamalarının nedeni, listenin kötü niyetli aktörlere altyapı hakkında ipuçları verecek olmasıdır
      MasterCard ya yalan söylüyor ya da bilgisiz ve beceriksiz
    • Asıl mesele büyük ölçüde az.mastercard.com'un gerçekte ne olduğu ve ne işe yaptığına bağlı
      x@mastercard.com adresine giden e-postaları alacağı iddiası doğru görünmüyor; bu sadece ne işe yaradığı bilinmeyen bir alt alan adı
      TLS muhtemelen mümkün olurdu ama risk bu alan adının ne olduğuna bağlıdır ve mastercard.com ziyaretçilerini doğrudan etkileyecek gibi görünmüyor
    • SSL/TLS sertifikası denince akla önce ACME tabanlı sertifika sağlayıcıları geliyor
      Alan adının DNS kontrolüne sahip olmak yeterli; TXT kaydıyla ya da kontrol ettiğiniz bir HTTP sunucusuna istek gönderilmesini sağlayarak doğrulama yapılabilir

  • Bunun Mastercard'ın büyük bir hatası olduğu açık ama asıl üst düzey alan adına sadece bir harf uzaklıktaki alan adlarının var olmasına izin vermek de başlı başına bir hata gibi görünüyor
    Örneğin .com ile .co, .net ile .ne; sorun çıkarmaya davetiye çıkaran bir yapı
    Bu tür alan adları olmasaydı ne kaydedilebilirlerdi ne de hatalı DNS istekleri herhangi bir yere giderdi

    • Pek de öyle değil
      Yazım hatası sadece üst düzey alan adında değil, ismin herhangi bir yerinde olabilir; ayrıca yazım hatası olmasa bile popüler site adlarından 1 bit farklı alan adlarını kaparak çeşitli bilgisayar hatalarından trafik elde eden bitsquatting diye bir şey var
      Bunun örneklerini veren makaleler de mevcut
      [1] https://en.wikipedia.org/wiki/Bitsquatting
      [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
    • Büyük bir şirketse bu sorunu Markmonitor ile çözeceklerini düşünürdüm
      Temelde düzenleme mesafesi 1 olan typo-domain'leri mümkün olduğunca birlikte kaydetme yaklaşımı
      Wikipedia'ya göre Akamai, Markmonitor müşterilerinden biri; dolayısıyla bu alan adının önceden alınmamış olması şaşırtıcı
    • Asıl soru, Niger ve Colombia'nın ISO 3166-2 kodları konusunda ne yapılacağı
    • Hassas bir telefon numarasından sadece tek hane farklı telefon numaralarının var olmasından ne farkı var, bilmiyorum
    • ISO 3166-1 alpha-2 üst düzey alan adları kesinlikle faydalı ama adres alanının doğası gereği tek harf farkıyla çok sayıda yazım hatası ortaya çıkıyor
      Ülke kodu olmayan alan adları da ülke kodu üst düzey alan adlarının bir harfi eksik biçimleriyle çakışabildiğinden çok büyük fark yok
      Yine de bu tür yapılandırma hataları iyi bir DNS denetim aracı tarafından yakalanabilir
      Kayıtlı name server'lardan birinin çözümlenememesi ya da name server'ların aynı zone seri numarasını veya gerçek yanıtları döndürmemesi gibi işaretler verir
      .is içinde alan adı kaydetmek için çalışan 2 name server sağlamak gerekiyordu ama .com artık bu kadar sıkı değil

  • O alan adı akamai'ye devredilmeliydi
    Aynı adrese başka istekler de geliyor ve akamai'nin bunu sorumlu biçimde ele alması gerekir

  • “Kendimizi araştırdık ve yanlış bir şey bulmadık” klasik bir tepki
    Mastercard, dünya genelinde en az 3,4 milyar markalı karta sahip ve 2024'ün 3. çeyreğinde dünya çapında 44,3 milyar kredi, banka kartı ve nakit işlemi işleyen milyarlarca dolarlık halka açık bir şirket
    Hata yaptığını kabul etmek piyasada kısa vadeli zarar getirebilir ama inkâr kültürü şirket kültürünü çürütür
    ClownStrike'dan farkı yok ve yağmacı, asalak kredi/banka kartı ağlarının da biraz kaos yaşamasının zamanı geldi

  • “Yazım hatası düzeltildi ve sistem için bir risk yoktu” türü açıklamalar hep aynı; bu tür beyanlar gerçekten sinir bozucu

    • Onların hesabı herhalde şöyledir
      Sorunu kabul edersek hissede milyonlarca dolar buharlaşabilir, ama inkâr edersek sadece birkaç tuhaf tip biraz daha sızlanır
      İhlal kanıtı yoksa bir şeyi zorlamak zordur, ihlal kanıtı varsa da hapse gidersin
    • Asıl anlamı daha çok şu: “BT departmanında hiçbir şeyden haberi olmayan bir çalışanla konuştuk; o çalışanın açığa çıkmış bir sorunu bulmamak için kişisel teşviki vardı ve 15 saniye içinde bunun nasıl suistimal edilebileceğini aklına getiremedi”
      Bir konuda gerçekten bilgili olan biri, bir şeyin suistimal edilemeyeceğini kesin olarak söyleyecek kadar kendini güvende hissetme noktasına neredeyse hiç gelmez