Google, DKIM replay saldırısıyla spoof edildi: teknik analiz

 (easydmarc.com)
1 puan yazan GN⁺ 2025-07-27 | 1 yorum | WhatsApp'ta paylaş
  • Saldırganın DKIM replay saldırısı kullanarak Google gibi görünen bir kimlik avı e-postasını başarıyla gönderdiği bir vaka
  • E-postanın gönderen adresi ve kimlik doğrulama sonuçları gerçek bir Google resmi postası gibi göründüğünden kullanıcı kolayca kandırılabiliyor
  • Saldırgan, Google Sites kullanarak resmi destek sayfası gibi görünen bir site hazırlayıp güvenilirliği artırıyor
  • SPF, DMARC ve DKIM’in tamamı doğrulamadan geçse de, gövde ve imza başlıkları değiştirilmeden e-postanın yeniden iletilmesi saldırının temelini oluşturuyor
  • Pratik karşı önlem olarak DKIM anahtarlarının düzenli rotasyonu ve kullanıcı farkındalığının artırılması öneriliyor

Başlangıç: normal görünen bir kimlik avı e-postası

  • Sabah bir tanıdık, Google hesabına ilişkin yasal belge talebi aldığını söyleyen bir e-posta aldı
  • Gönderen, Google’ın resmi no-reply adresi olarak görünüyordu; yazım hatası, şüpheli bağlantı veya anormal alan adı olmadan son derece özenli hazırlanmıştı
  • Alıcı, bunun gerçek olup olmadığını anlamakta zorlanınca bir uzmana danıştı

E-postanın ayrıntılı analizi

  • E-posta başlıkları ve bağlantı önizlemesi sandbox ortamında incelendi
  • Gönderen adresi, markalama, dil kalitesi ve ek dosya varlığı açısından her şey normal görünüyordu
  • Ancak SPF, DKIM ve DMARC doğrulama sonuçları kontrol edildiğinde anomali işaretleri ortaya çıktı

Kimlik avı e-postalarında dikkat edilmesi gerekenler

  • Şüpheli e-postalardaki bağlantılara tıklanmaması ve talimatların uygulanmaması özellikle vurgulanıyor
  • Sandbox dışındaki bir ortamda bu e-postaya yanıt vermek veya eki açmak, bilgi sızıntısı, kurumsal e-posta ihlali, hesap ele geçirilmesi ve ağ ihlali riski taşıyor
  • Şüpheli durumlarda derhal uzman analizi istenmesi ve güvenlik ekibine bildirilmesi gerekiyor

Saldırı akışı: Google Sites kullanımı

  • Saldırı e-postasındaki bağlantı, kullanıcı giriş yapmışsa doğrudan Google Sites’a yönlendiriyor
  • Google Sites, herkesin ücretsiz oluşturabildiği resmi bir google.com alt alan adı, ancak içerik başlı başına resmi bir destek sayfası değil
  • İç wiki’ler, proje panoları, dokümantasyon ve etkinlik siteleri gibi çeşitli amaçlarla kullanılıyor; bu saldırıda olduğu gibi kötüye de kullanılabiliyor

Altyapı güveninin tehdide dönüştüğü an

  • Google Sites (2008’de kullanıma sunuldu), Google Workspace ile entegre olup kolay oluşturma ve yayınlama, SSL sertifikası ve marka güveni sağlıyor
  • Bu sayede saldırgan, ayrı bir alan adı ya da hosting olmadan resmi görünen bir kimlik avı sitesini kolay ve düşük maliyetle kurabiliyor

DKIM replay saldırısının ayrıntılı işleyişi

1. aşama: gerçek bir Google e-postasının elde edilmesi

  • Saldırgan, no-reply@accounts.google.com adresinden gelen meşru bir e-postayı aldıktan sonra, orijinal gövdeyi ve başlıkları saklıyor

2. aşama: imzalı mesajın yeniden gönderime hazırlanması

  • DKIM, e-posta gövdesinin bir kısmına ve belirli başlıklara dijital imza ekler
  • Orijinal mesaj ve imza başlıkları korunursa, yeniden iletim sırasında da doğrulama geçerliliğini korur

3. aşama: Outlook üzerinden yeniden iletim

  • Saldırgan, saldırı amaçlı e-postayı bir Outlook hesabı üzerinden gönderiyor
  • Çıkış noktası ve bazı rota bilgileri değişse de DKIM imzası geçerli kalıyor

4. aşama: Jellyfish SMTP relay sunucusunun kullanılması

  • Microsoft, postayı Jellyfish sistemi üzerinden yönlendiriyor ve böylece gönderen sunucuyla arasında mesafe oluşturuluyor

5. aşama: Namecheap PrivateEmail üzerinden iletim

  • Namecheap’in PrivateEmail hizmeti e-postayı alıp ek bir relay görevi görüyor
  • Bu süreçte yeni bir DKIM imzası ekleniyor, ancak bu imza DMARC ölçütleriyle uyumlu olmuyor
  • Buna rağmen orijinal Google DKIM imzası eşleştiği ve geçerli olduğu için DMARC denetimi geçiliyor

6. aşama: Gmail’e nihai teslimat

  • Sonuçta alıcı, Google’ın resmi e-postası gibi görünen bir mesaj alıyor
  • SPF, DKIM ve DMARC’ın tamamı doğrulamadan geçmiş görünüyor

Sahte mahkeme celbi e-postası neden tehlikeli?

  • “Mahkeme celbi” temalı e-posta, alıcıda korku, aciliyet ve kafa karışıklığı yaratıyor
  • Gerçek celp çıkarma ve tebliğ yöntemlerinden farklı; normal koşullarda fiziksel teslimat veya resmi kanallar kullanılır
  • Bu tür kimlik avı girişimleri çok ikna edici olduğundan, teknik olarak yetkin kullanıcılar bile kolayca aldanabiliyor

Sonuç ve karşı önlemler

  • Beklenmedik ve acil görünen e-postalarda her zaman doğrulama yapılmalı ve uzman müdahalesi istenmeli
  • Bağlantıya tıklamak, yanıt vermek veya herhangi bir şey çalıştırmak kesinlikle yapılmamalı
  • Güvenlik ekibinden veya olay inceleme uzmanlarından analiz talep edilmesi öneriliyor

Ek: saldırının yeniden üretilme süreci

  • Saldırgan, Namecheap üzerinden bir alan adı kaydedip ücretsiz PrivateEmail hizmeti elde ediyor
  • Ardından Google Workspace’e (ücretsiz deneme) kaydolup alan adını doğruladıktan sonra kötü amaçlı bir Google OAuth uygulaması oluşturuyor
  • App Name alanı üzerinden istenen ad ayarlanabiliyor (ör. Google Support)
  • Google’ın gönderdiği hesap bildirimi PrivateEmail’e iletiliyor; burada gönderen adresi ve yanıt adresi manipüle edilebiliyor
  • Son aşamada saldırı e-postası istenen hedefe ulaştırılıyor

Sık sorulan sorular

  • DKIM replay saldırısı: Saldırganın, geçerli DKIM imzası içeren meşru bir e-postayı ele geçirip aynı içerik ve başlıklarla yeniden göndermesi
  • SPF ve DMARC’ın engelleme sınırları: SPF yalnızca gönderen sunucuyu/IP’yi doğrular; replay saldırısında DKIM tutarlılığı varsa DMARC da geçilebilir
  • Tespit neden zor?: Gövde ve başlıklar değiştirilmeden yalnızca imza doğrulandığı için ayırt etmek güçtür
  • Saldırının Google OAuth bypass yönü: Saldırgan kötü amaçlı bir OAuth uygulaması oluşturup Google’ın gönderdiği resmi bildirimi yeniden ileterek güven oluşturur
  • Karşı önlemler: DKIM anahtarlarının düzenli rotasyonu (30 gün veya daha kısa aralıklarla) ve kullanıcı eğitimi (şüpheli bağlantılara dikkat, URL kontrolü, raporlama kültürünün yaygınlaştırılması) kritik önem taşır

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-27
Hacker News görüşleri

  • Bu soruna bir çözüm geliştiriyorum (Google ve Yahoo kökenli ortak yazarlarla birlikte çalışıyorum; güvenilir bir proje)
    Lütfen Draft: DKIM2 Motivation belgesine bakın
    Bu yöntem, kullanıcının girdiği metnin gerçekten Google tarafından gönderilmesini engellemez, ancak Google'ın gerçek bir niyeti olmadan o iletinin yeniden iletilmesini engeller
    Çünkü SMTP FROM/TO alanları korunur
    Motivasyon taslağı teknik ayrıntılar içermiyor; taslakları ilgili belgelerde görebilirsiniz
    Lütfen DKIM Working Group Documents bağlantısına bakın

    • Datatracker sitesi aday belgeleri iyi göstermediği için doğrudan bağlantıları ekliyorum
      Draft: dkim2-dns
      Draft: dkim2-header
      Draft: dkim2-modification-algebra
      Draft: dkim2-bounce-processing
      Draft: dkim2-message-examples

    • Bunun posta listelerinde veya gruplarda nasıl çalışacağını merak ediyorum
      Örneğin, dışarıdan accounts-payable@example.com adresine gelen postalar sık sık ekip üyelerine otomatik yönlendirilir
      Son alıcının sisteminde posta listesi yönlendiricisine güvenen bir ayar mı gerekir, yoksa hangi listelerde yer aldığını izleyen iç mantık mı olmalı merak ediyorum
      Asıl alıcı olan accounts-payable adresinin geçerli bir alıcı olduğunun doğrulanabilmesi gerekir

  • Bilgisayar korsanlığı suçlamasıyla gerçekten mahkûm edildikten sonra FBI'ın Google hesabımdaki tüm verileri el koyarak aldığını yaşamış biri olarak söylüyorum
    2016'da bir kez, 2018'de bir kez daha veri aldılar
    Pratikte bunu bu makaledeki gibi yapmıyorlar
    Benim deneyimime göre, Google içindeki belirli bir birime e-posta göndererek resmî iletişim yürütülüyor
    Kolluk kuvvetleri, soruşturulan kişinin durumu fark etmemesi için mümkün olduğunca dikkatli hareket ediyor

    • Merak edenler için ayrıntı vereyim
      usernotice@google.com adresinden şöyle bir e-posta alırsınız:
Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

Federal Grand Jury subpoena kapsamında genellikle hizmet sağlayıcının (Google vb.) sizi bilgilendirmesini engelleyen 1-2 yıllık gecikmeli bildirim talep edilir
Mahkeme celbi yalnızca genel kayıtları sağlar (fatura bilgileri, giriş kayıtları vb.); içerik (e-postalar vb.) sağlamaz
E-postalar gibi gerçek veriler için ayrıca arama emri gerekir ve Google genelde böyle bir arama emrinin uygulandığını ayrı bir bildirimle haber vermez

  • Cuma günü için bu yorum beni %10 daha uyanık hale getirdi
    Ayrıntılı arka plan hikâyesini merak ediyorum

  • İlginç
    Bunun, GDPR kapsamındaki "hesabımla ilgili tüm verileri ver" türü taleplerde hesabımın tam veri dışa aktarımına kaydedilip kaydedilmediğini ya da etiketlenip etiketlenmediğini merak ediyorum

  • Tahminimce arama emri CFAA ihlali, wire fraud veya conspiracy gibi gerekçelerle çıkarılmıştır
    Umarım iyi bir avukat tutup durumu yoluna koymuşsundur

  • Yakın zamanda ben de buna benzer bir saldırı aldım
    Saldırgan, yourgoogleaccount@google.com adresinden (özellikle gmail.com değil) bir e-posta gönderiyor, ardından Google'ın posta sunucularından gelen teslim hatası iletisini yourgoogleaccount@gmail.com adresine yönlendirip sonuna spam mesaj ekliyor
    Tüm güvenlik kontrollerinden geçiyor
    Postmaster hatası ile kimlik avı kampanyasının birleşmesi gerçekten sıra dışı
    Teknik olmayan biri kolayca kanabilir
    Benim durumumda kimlik avı içeriği inşaat aletleri kazandığımı söylüyordu

    • Ben de birkaç haftadır bunları alıyorum
      Artık Google'ın e-postayı tamamen boşladığını düşünmeye başladım

  • Yazıyı okurken çok kafam karıştı
    Saldırganın e-posta gövdesini değiştirip kimlik avı bağlantısı eklediği izlenimi verecek şekilde ayrıntılı anlatıyor, ama gerçekte buna dair kanıt ya da değişiklik yoktu
    DKIM imzası gövdenin hash'ini içerir
    Teknik olarak I= alanıyla hash kapsamını sınırlamak mümkün, ancak Google'ın kısa e-postalarda bu seçeneği kullanmadığını doğruladım (no-reply@accounts.google.com iletilerini bizzat kontrol ettim)
    Yani DKIM ve DMARC kontrollerini geçebilmesi için gövdenin değişmemiş olması gerekir; dolayısıyla kimlik avı bağlantısı da aslında Google'ın gönderdiği özgün içeriğin parçasıydı (yalnızca muhtemelen başka bir hedef alıcı için)
    Bu yüzden burada asıl mesele "yanlış yönlendirilmiş korkutucu bir e-posta" ve "DKIM replay attack" başlığı bu alana aşina olmayanlar için olduğundan çok daha ciddi duyulabilir
    Düzenleme: TFA'daki "The Takeaway?" bölümünü görünce yazının bittiğini sanmıştım, ama altındaki güncelleme bağlantının aslında Google OAuth uygulama adına yerleştirildiğini ve Google'ın e-posta şablonuna bu şekilde girdiğini açıklıyor
    Bu, saldırının en önemli kısmı ama yazının yapısı o kadar kötü ki bu ayrıntı gömülmüş ve sanki rastgele içerik enjekte edilebiliyormuş gibi yanlış bir izlenim yaratıyor
    Ek: Başka bir yorumda, e-posta ekran görüntüsünün ortadan kırpılarak Google e-posta şablonunun sabit kısmının görünmez hale getirildiği de belirtilmiş
    Saldırının kendisi düşünüldüğünden çok daha özensiz

    • Bu yazı kasıtlı olarak yanıltıcı olacak şekilde yazılmış gibi görünüyor
      Ekran görüntüsündeki parçanın e-postanın tamamı olduğu izlenimini veriyor, oysa aslında devamında insanı uyarması gereken metinler olmalıydı

    • Benim anladığım kadarıyla DKIM'in doğrulanmasının nedeni, saldırganın gerçekten Google'dan aldığı e-postayı olduğu gibi yönlendirmesi
      Asıl saldırı vektörü, Google'ın saldırganın kontrol ettiği belirli bir metni içeren bir e-posta göndermesini sağlayabilmeleri

  • Bence buradaki gerçek açık, Google OAuth uygulama adına bir URL koyabilmeniz ve bunun Google'ın kök alanından giden no-reply e-postalarında rastgele bir adrese yönelik olarak işlenmesi
    Bağlantı tıklanabilir olmasa bile, çevresindeki metin yeterince tehditkâr yapılırsa kurbanın adresi elle açma ihtimali yüksek
    DKIM bütünlüğünü koruyan yönlendirme servislerinin katman katman birikebilmesi ise ikincil ama öğretici bir nokta
    OAuth uygulama adında URL kullanımını, özellikle de google.com içeren URL'leri tamamen engellemek gerekir

  • Nihayet!
    Birkaç ay önce neredeyse aynı e-postayı aldım (Google Domains yöneticisi olarak)
    Açıkçası ben de o e-postayı çok ürkütücü buldum
    Ben de bağlantıya atlamadım; bekleyip bu dolandırıcılıkla ilgili başka referanslar aradım
    Tuhaf olan şey, tüm e-posta adreslerinin maskelenmiş olmasıydı ve maskeleme deseni benim yönettiğim adreslerle uyuşmuyordu
    E-postanın kendisi meşruydu ve Google'da arayınca gövde metni de birebir eşleşiyordu
    Benim durumumda ölmüş bir kişinin hesabıyla ilgiliydi ama gerçek durumla örtüşmüyordu
    Yine de birinin Google'ı benim öldüğüme ikna edip tüm Google hesabımı ele geçirmeye çalışıyor olabileceğinden neredeyse %100 emindim
    Çok korkutucu bir deneyimdi

  • Step 3: Saldırgan Outlook'tan e-posta gönderir
    Bildiğim kadarıyla Received: başlıklarındaki yolu spoof etmek mümkün değil
    Her sunucu kendi yol bilgisini eklemeye devam eder
    Bu yüzden e-postanın kaynağını doğrularken her zaman buna bakarım
    Google'dan gelen bir e-postanın Microsoft sunucularından geçmiş olması mümkün değildir

    • Son "Trusted" sunucunun başlığı spoof edilemez, onun öncesindeki yol ise spoof edilebilir

    • Tüm e-postaların başlıklarını gerçekten tek tek elle mi inceliyorsun merak ediyorum
      Yoksa bunu görüntüleyen ya da görselleştiren bir araç mı kullanıyorsun?

  • Gerçekten ürkütücü bir durum
    Bu yazıdan çıkarılan dersi bir akrabanıza anlattığınızı hayal edin
    Güvendiğiniz bir alan adından gelmiş olsa ve dkim/dmarc/spf sırasıyla tamamen geçmiş olsa bile her zaman şüpheci olmak gerektiğini anlatmak insanın içini karartıyor
    Ama bu saldırının yapabilecekleri aslında oldukça sınırlı
    Örneğin başkasının Gmail hesabından sahte mesaj gönderemezsiniz
    "Bir ileti yönlendirildiğinde, DKIM imzası gövde ve imzalanmış başlıklar değişmediği sürece korunur"
    Şaşırtıcı olan, To: başlığının DKIM imzasına dahil edilmediği düşüncesi
    Bence imzalama yapılandırması değiştirilmeli ya da e-posta istemcileri, ileti meşru olsa bile To değiştiğinde uyarı vermeli

    • Bu yazıdan çıkarılan dersi bir akrabana anlatmayı hayal et – her zaman şüpheci olun
      Önce dkim/dmarc/spf'nin ne olduğunu açıklaman gerekir, bu da ayrı bir dert
      Aslında bunlar kullanıcıların bilmesi gerekmeyen arka uç teknolojileri
      Bu saldırı sanıldığı kadar korkutucu değil
      Yazı biraz ürün satmak için abartılmış gibi
      To: başlığının imzaya dahil edilmemesi de aslında pek anlamlı değil
      Pratikte e-postadaki To her zaman nihai alıcıyı göstermek zorunda değildir

    • E-postada her zaman şüpheci olmak zaten uzun süredir varsayılan durum olmalıydı
      From alanına asla mutlak güvenmemek en iyisi

    • To: başlığının DKIM imzasına dahil edilmemesine şaşırdığını söylemişsin ama aslında dahil ediliyor
      Bu yüzden özgün To: değerinin korunmuş olması gerekirdi
      Yeniden üretim bölümündeki ekran görüntüsünde özgün To: adresi görünüyor
      Bu, iletinin o adrese teslim edildiği anlamına gelmiyor
      Esasen e-posta, herhangi bir To: değeri taşıyarak herhangi bir adrese teslim edilebilir

    • Benim temel tavsiyem şu: herhangi bir e-posta sizden bir eylem istiyorsa, doğrudan ilgili web sitesine gidin
      Hiçbir bağlantıya tıklamayın
      Bu daha zahmetli ama sonuçta sorunu çözer
      Özellikle bankacılık veya önemli sistemler için bu zahmete fazlasıyla değer

    • Benim iş yerimde bu tehdit modeli zaten politika haline geldi
      İnternette her şeye şüpheyle yaklaşmak iyi bir uygulamadır
      Birçok küçük işletme ve serbest çalışan hâlâ MFA gibi şeyleri kullanmıyor; kullananlar da token hırsızlığına kolayca yenik düşebiliyor
      Bu hesaplar ele geçirildiğinde, gerçekten iç kullanıcıdan geliyormuş gibi görünen kötü niyetli e-postalar gönderiliyor
      Kullanıcı açısından çok meşru görünüyor
      Bu yüzden e-postaya her zaman şüpheyle yaklaşmak gerekir

  • Yazar
    "Here is the URL from that email [...] https://sites.google.com[...]";
    Bu bağlantı zaten ilk büyük red flag
    Bence yazar bu noktayı üç paragraf sonra değil, çok daha başta vurgulamalıydı

    • Herkes google.com'un tüm alt alan adlarını bilmek zorunda değil
      Gerçek sorun (SSO'daki geçerli alan meselesinin ötesinde), Google'ın kullanıcı içeriğini ana alan adının alt alan adlarında sunması
      Drive gibi başka hizmetler de bunu yapabiliyor olabilir

    • Bu senin için red flag olabilir ama bizim anne babamız için olmayabilir

  • Genel olarak bunun e-posta güvenliğinin ne kadar kırılgan bir sistem olduğunu gösteren bir örnek olduğunu düşünüyorum
    Bu forumda çok akıllı insanlar var; bu sorunu kökten çözecek bir alternatif üretebileceklerini düşünürdünüz
    Google da böyle siteleri ana alan adı yerine hostedbygoogle.com gibi ayrı bir alan adında sunmalı
    Neden şimdiye kadar ayırmadıklarını merak ediyorum

    • Pratikte uygulanabilir tüm alternatifler, sonunda tüm kontrolün tek bir şirkete verilmesiyle sonuçlanıyor
      Bu da e-postanın geriye kalan temel değerini, yani hiçbir tarafın tamamen kontrol etmediği bir sistem olma özelliğini ortadan kaldırıyor
      Teknik sorunlar çözülebilir ama insan ve çıkar çatışmasıyla ilgili sorunlar çok daha zor
      Bu sorunu çözebilecek kaynaklara sahip olanların çoğunun, tamamen açık bir platform kurmak için bir motivasyonu yok
      Tüm parayı ve kontrolü kendileri almayacaklarsa bu çabayı göstermezler
      Öte yandan herkes de tüm kontrolü tek bir şirkete vermek istemiyor
      İşte bu yüzden bu teknik bir sorun değil, bir iş modeli sorunu
      (Metaverse'de tüm hizmetlerin avatarları ve eşyaları paylaşmasının fiilen imkânsız olmasının nedeni de aynı
      Bu teknik olarak imkânsız olduğundan değil, hak sahiplerinin buna asla izin vermeyecek olmasından kaynaklanıyor)

    • Thiel destekli yeni startup Shadowfax duyuruldu!
      Güvenli ve merkezi tekel hizmetimiz, AI ve blockchain tabanlı katmanlarla donatıldı ve e-postanın eski sisteminin yerini almaya hazırlanıyor
      Şimdiden ABD Savunma Bakanlığı'ndan ihale aldı ve 2027'ye kadar tüm federal hükümet içi ve dışı iletişimin standardı olması bekleniyor