Sahte e-posta göndermek: Böyle bir şey neden mümkün ki?

Kimlik avı e-postalarını ayırt etmek, bazen yalnızca “Gönderen” alanını kontrol ederek çok kolay olabilir. Ne var ki işler her zaman bu kadar kolay yürümez; sahte bir e-postayı gerçeğinden ayırt edilemeyecek hale getirmek gerçekten de mümkündür. Bir saldırgan bunu nasıl yapacağını biliyorsa hedef alınan kuruluş gerçek bir tehlike altında demektir. Çoğu kişi, patronlarından veya en iyi müşterilerinin birinden gelmiş gibi görünen bir e-postadaki kötü amaçlı bağlantıya ya da dosyaya düşünmeden tıklayabilir. Onları bu konuda suçlayamayız, hele ki ortada e-postanın sahte olduğunu belli edecek hiçbir işaret yoksa.

Peki kusursuz bir sahte e-posta oluşturabilmek neden mümkün? Andrew Konstantinov’un 3. Chaos İletişim Kongresi‘nde, sızma testlerinde e-posta doğrulama üzerine yaptığı konuşma tam da bu soruya cevap veriyor ve e-posta sahteciliğinden korunmanın ne kadar etkili olabileceği hakkında bir takım görüşler sunuyor.

1. Problem: E-postanın akması gerekiyor

E-posta modern dünyanın vazgeçilmez bir iletişim unsuru ve her kuruluş günlük faaliyetlerinde ağırlıklı olarak e-postaya bel bağlıyor. Her şey yolunda giderken teknolojiye pek kafa yormasak da, birdenbire e-posta gelmemeye başlasa herkesin bu durumu fark edeceğinden emin olabilirsiniz. Bu nedenle, bütün e-posta sunucusu yöneticilerinin birincil önceliği, güvenilirlik. Ne olursa olsun e-postalar gönderilebilmeli ve alınabilmeli.

Buradaki çıkarım, her kuruluşun e-posta sunucusunun dünyadaki geri kalan her şeyle mümkün olduğunca uyumlu olması gerektiği. İşte sorun da burada yatıyor: E-posta standartları korkunç derecede eski.

2. Problem: Doğrulaması olmayan e-posta protokolü

Hem istemciden sunucuya hem de sunucudan sunucuya e-posta iletişimi için kullanılan ana protokol, SMTP. Bu protokol ilk defa 1982 yılında çıktı ve en son 2008’de, yani 10 yıldan uzun bir süre önce, güncellendi. Tüm eski standartlar gibi, SMTP de güvenlik açısından bir kabus.

Öncelikle tipik bir e-posta mesajınızın nelerden oluştuğuna bakalım:

• SMTP zarfı. Bu kısım, sunucudan sunucuya iletişimlerde kullanılır ve e-posta istemcilerinde asla görünmez. Gönderenin ve alıcının adreslerini belirtir.
• Başlıklar. E-posta istemcileri bu kısmı görüntüler. Bu bölüm, her e-postada gördüğünüz “Gönderen,” “Alıcı” ve “Konu” kısımlarını içerir.
• Mesaj gövdesi. E-posta metni ve diğer içerikler.

Bir e-posta mesajında neler var. Kaynak

Esas problem, standardın hiçbir doğrulama yolu sağlamaması. Hem SMTP zarfında hem de başlıkta yer alan gönderen adresi hakkındaki tüm sorumluluk, gönderenin sunucusuna ait. Daha da kötüsü, SMTP zarfındaki gönderen adresi, başlıktakiyle uyumlu olmak zorunda da değil (ve kullanıcı yalnızca ikincisini görüyor).

Ayrıca standart, her e-posta başına bir başlık sınırı koysa da, SMTP bu sınırlamayı uygulamıyor. Bir mesaj birden fazla başlık içeriyorsa e-posta istemcisinin kullanıcıya göstermek üzere bunlardan birini seçmesi yetiyor.

Buradaki tehlikeyi görmek için profesyonel bir hacker olmaya gerek yok.

E-posta protokolü, bir e-postanın gerçekten de belirtilen göndericiden geldiğinden emin olmak için hiçbir yol sunmuyor

3. Problem: Giden sahte, gelen sahte: Her ikisine de dikkat etmek lazım

Her e-posta iletişimi, işleri daha da karmaşık hale getirecek şekilde iki tarafı içeriyor; dolayısıyla bu kimlik doğrulama eksikliği problemi iki alt probleme ayrılıyor.

Bir yandan, aldığınız her e-postanın gerçekten de belirtilen adresten gönderildiğinden emin olmak istiyorsunuz. Diğer yandan, çok büyük olasılıkla başka insanların sizden gelmiş gibi görünen e-postalar gönderebilmesini de önlemek istiyorsunuz. Ne yazık ki standart, her iki konuda da yardımcı olmuyor.

SMTP protokolü o kadar sık kötüye kullanılıyor ki insanlar artık yukarıda bahsettiğimiz kusurları gidermek için yeni teknolojiler geliştirmeye başladı.

1. Düzeltme girişimi: Sender Policy Framework (SPF)

Sender Policy Framework’ün ardında yatan fikir oldukça basit: Alıcı sunucu, e-postayı gerçekten gönderen sunucu adresinin alanla ilgili gerçek e-posta sunucusu adresiyle uyup uymadığını kontrol edebiliyor olmalı.

Ne yazık ki bunu söylemesi, yapmaktan daha kolay. SMTP standardının böyle bir kontrol gerçekleştirecek bir yolu yok, dolayısıyla tüm kimlik doğrulama yöntemlerinin mevcut şeylerin üstüne eklenmesi gerekiyor. Böyle bir teknolojiyi “önerilen standart” noktasına taşımak on yıl sürdü. Bugün ilk 1 milyon sunucunun yaklaşık %55’i SPF kullanıyor; çoğu ise oldukça esnek politikalarla çalışıyor.

SPF; yanlış yapılandırmayı kolaylaştıran dağınık mimari, aynı adreste barındırılan başka sunucuları kullanarak SPF’yi atlatma gibi birçok farklı problemle de karşılaşıyor. Ancak SPF’nin en önemli kusuru, yalnızca SMTP’de belirtilen adresi kontrol edip başlıkta yer alan “Gönderen” alanını, yani kullanıcının gördüğü esas şeyi, dikkate almaması.

Sonuç:

• SPF, bir e-postanın doğruluğu kanıtlanmış bir sunucudan gelip gelmediğini kontrol etmeye yardımcı oluyor.
• Kullanıcılara gösterilen adres ise hala sahte olabiliyor.

2. Düzeltme girişimi: Alan Adı Anahtarıyla Tanımlanmış E-posta (DKIM)

Alan Adı Anahtarıyla Tanımlanmış E-posta, soruna farklı bir açıdan yaklaşıyor: DKIM, mesajın başlığını ve mesaj gövdesinin bir kısmını özel bir kod kullanarak şifreli şekilde imzalıyor; bu imza Alan Adı Sisteminde herkese açık biçimde yayından bir kod kullanılarak doğrulanabiliyor.

Bununla birlikte, DKIM’in tüm mesajı şifrelemediğini söylemekte de fayda var. Bunun yerine, şifreli şekilde imzalanmış bir ek ilave ediyor. Bu bir sorun. Şifreli kısmı değiştirmek zor, ancak imzayı tamamen silip sahte bir mesaj oluşturmak kolay. Üsteik sonuçlar tespit de edilemiyor.

DKIM uygulamak zor, çünkü işin içinde şifreli kodlar yazmak ve yönetmek gibi unsurlar var. Ayrıca, yanlış yapılandırılan DKIM, saldırganın gerçek DKIM imzasını korurken mesajın başlığını ve gövdesini tamamen değiştirebilmesine olanak tanıyor.

Sonuç:

• DKIM, mesajları dijital olarak imzalayarak alıcı sunucunun mesajın gerçekten de sizden geldiğinden emin olmasına yardımcı oluyor.
• Şifreli kod yönetimi gerektirdiği için uygulaması zor.
• Sahtekarlar sizin adınıza sahte bir e-posta hazırlarken kolayca imzayı silebiliyorlar.
• Belirli yanlış yapılandırmalar, gerçek DKIM imzaları içeren sahte mesajların gönderilebilmesiyle sonuçlanabiliyor.

3. Düzeltme girişimi: Alan Adı Temelli Mesaj Doğrulama, Raporlama ve Uygunluk Kontrolü (DMARC)

Alan Adı Temelli Mesaj Doğrulama, Raporlama ve Uygunluk Kontrolünün ismi çok uzun olsa da, aslında SPF’den ve DKIM’den çok daha kolay anlaşılır bir yöntem. Bu iki yöntemin ihmallerini düzelten bir uzantı gibi düşünebiliriz.

Birincisi, DMARC, alan yönetisi tarafından sunucunun hangi koruma mekanizmasının (SPF, DKIM veya her ikisi) kullanılacağını belirlemesine izin veriyor; bu da DKIM mekanizmasını büyük ölçüde düzeltiyor. İkincisi, SMTP zarfındaki gönderen adresinin yanı sıra başlığın “Gönderen” alanında belirtilen (kullanıcın gördüğü) adresi de kontrol etmeyi sağlayarak SPF’yi düzeltiyor.

Olumsuz tarafı ise DMARC protokolünün görece yeni olması, henüz tam bir standart haline gelmemiş olması (RFC 7489 bunu bir standart veya “önerilen standart” olarak değil, “Bilgisel” olarak tanımlıyor) ve kullanılması gerektiği kadar yaygın olarak kullanılmaması. 20.000 alan üzerinde yapılan bu çalışmaya göre, yalnızca %20’si 2019 itibariyle DMARC yöntemini benimsemiş ve sadece %8,4’ü katı politikalara sahip.

Ne yazık ki DMARC henüz yaygın olarak benimsenmiyor ve çoğunlukla herhangi bir politika olmaksızın kullanılıyor. Kaynak

Sonuç:

• SPF’in ce DKIM’in en önemli sorunlarını düzeltiyor.
• Henüz yeterince yaygın olarak benimsenmediği için olabileceği kadar etkili değil.

E-posta sahteciliğinden kendinizi nasıl koruyabilirsiniz

Özetlemek gerekirse: SMTP protokolü güvenlik gözetilerek tasarlanmadığı için sahte e-posta göndermek hala mümkün. Bu yüzden bir saldırganın sahte bir e-postaya herhangi bir göndericinin adresini eklemesine imkan tanıyabiliyor. Geçtiğimiz on yıllarda, SPF, DKIM ve DMARC olmak üzere bazı koruma mekanizmaları ortaya çıktı. Ancak bu mekanizmaların etkili olabilmesi için mümkün olduğunca fazla e-posta sunucusu tarafından doğru bir şekilde uygulanarak kullanılması gerekiyor. İdeal olarak internetteki her bir e-posta sunucusunda uygulanmaları gerekiyor.

Bunlara ek olarak, bazı e-posta aktarma sunucularının yapılandırma hataları sonucu mektuplara bazı eklemeler yapabileceğini, bunun da otomatik olarak DKIM kontrolünü başarısız kılabileceğini de dikkate almak gerekiyor. Ayrıca bu teknolojilerin kitlesel tehditlerle başa çıkmada yardımcı olabileceğini, ancak işletmenizi daha sofistike e-posta saldırılarından korumak için hem iş istasyonlarında hem de e-posta sunucusunda ilave koruma çözümleri kullanmanız gerektiğini de unutmamalısınız.

E-posta koruması ile ilgili bazı tavsiyelerimiz şunlar:

• En azından SPF kullanın. Düzgün yapılandırıldığından emin olun. Bununla birlikte becerikli saldırganların SPF’i atlatabileceğini unutmayın (konuşmada bu konuyla ilgili geçen ayrıntılar).
• Daha iyi koruma sağlamak için DKIM uygulayın. Biraz daha zor olabilir, ama buna değecektir. Bunun da doğru yapılandırıldığından emin olun (saldırganların arayabileceği şeylerle ilgili bazı ipuçları).
• SPF’in ve DKIM’in kötüye kullanılabilen kusurlarının çoğunu düzelttiği için en iyisi DMARC’yi benimsemektir.
• Gelen e-postalar için yapılandırmalarınızı da kontrol edin.
• Modern kimlik doğrulama mekanizmalarını destekleyen güvenlik çözümleri kullanın. Örneğin, Kaspersky Security for Mail Servers veya Kaspersky Security for Microsoft Office 365 çözümlerini kullanabilirsiniz.