Sahte posta, SPF'yi atlayın | Düşman unsur Sahte E-posta saldırısını nasıl gerçekleştirebilir ve mevcut SPF uygulamasını nasıl atlayabilir? | giriş | 1#2 |.com

Mevcut makale dizimizde, SPF posta standardının, düşmanca bir unsur tarafından kolayca istismar edilebilecek yapısal bir güvenlik açığını öğreneceğiz. Bu SPF güvenlik açığının farkında olan düşman unsur, kuruluşumuzun alıcılarını Spoofing veya Phishing saldırılarından korumak için inşa edilen mevcut “SPF duvarını” atlayabilir.

SPF posta standardının yapısal güvenlik açığına işaret ettiğimiz bölümün yanı sıra, "sonraki seviyeye" geçmek ve mevcut SPF uygulamasını atlayan bir Sahte E-posta saldırısının nasıl yürütüleceğini göstermek istiyorum.

Mevcut makale serisi iki makale içermektedir.
Sonraki makale - Sahte E-posta saldırısının simülasyonu nasıl yapılır ve SPF gönderen doğrulaması nasıl atlanır? | 2#2

İyi bilinen ikilem: SPF'nin güvenlik açığını kamuoyuna açıklamalı mıyım? | Siyah şapka ve beyaz şapka

Devam etmeden önce okuyucunun aklına gelebilecek en temel direnişe değinmek istiyorum: Düşman bir varlığın örgütüme zarar vermek ve zarar vermek için kullanabileceği bu tür bilgileri yayınlamaya nasıl cesaret edersiniz?

Basit gerçek şu ki, çoğu zaman bu "düşman varlık", Sahtekarlık veya Kimlik Avı saldırılarını gerçekleştirmek için neden kullanması gerektiği ve mevcut gönderen kimliğiyle nasıl başa çıkılacağı konusunda geniş bir bilgiye ve tanımlanmış bir yola sahip profesyonel bir kişidir. SPF gibi doğrulama standardı.

Başka bir deyişle, "düşman varlığın" SPF posta standardının yapısal güvenlik açığını ortaya çıkarmak için benim yardımıma ve desteğime ihtiyacı yok. Sizi temin ederim ki bu “SPF kör noktasını” zaten biliyor ve organizasyonunuza saldırmaya karar verirse bunu kullanacak!

Kuruluşumuzun varlıklarına ve kullanıcılarımıza hizmet etmek ve onları korumakla görevlendirilmiş bir kişi olarak, bize zarar verebilecek birçok tehdit ve riskin bulunduğunu kabul edecek dürüstlüğe ve cesarete sahip olmalıyız.

Bana öyle geliyor ki, "gözlerimizi kapatmak" ve posta altyapımızın savunmasızlığını görmezden gelmek yerine, bu varoluşsal tehdidin farkında olduğum göz önüne alındığında, daha yapıcı ve olgun sorulara geçmek en iyi ruh hali olmalıdır. Posta altyapıma yönelik olarak kuruluşuma ve kullanıcılarıma daha iyi koruma sağlamak için ne yapabilirim?

Masum protokol olarak SMTP | Kısmi bir çözüm olarak sahte e-posta ve SPF

SMTP protokolünü “Masum protokol” olarak tanımlıyorum çünkü SMTP protokolünün temel amacı, e-posta mesajlarını Host A'dan Host B'ye en hızlı ve etkili şekilde aktarmaktır.

Kaynak Ana Bilgisayar (A), hedef Ana Bilgisayara (B) hitap ettiğinde ve bir SMTP oturumu başlatmayı istediğinde, hedef Ana Bilgisayar'ın (B) temel varsayımı, Ana Bilgisayar A'nın gerçekten iddia ettiği kişi olduğu yönündedir.

Bu varsayılan varsayım, görünüşte meşru bir ana bilgisayarın/alıcının kimliğini sunarak gerçek kimliklerini gizleyen düşman unsurlar tarafından istismar edilmektedir.

Zamanla bu “kimlik sorunu”, gönderenin kimliğini doğrulamalarını ve gönderenin gerçekten iddia ettiği kişi olduğundan emin olmalarını sağlayacak bir çözüm arayan kuruluşların farkındalığına ulaşıyor.

Gönderenin kimliğini doğrulama ihtiyacını karşılamak için icat edilen en popüler ve iyi bilinen posta güvenliği standartlarından biri SPF'dir (Gönderen Politikası Çerçevesi).

SPF standardı çok basit bir doğrulama testine dayanmaktadır; burada belirli bir posta sunucusunun belirli alan adlarını göndermeye veya temsil etmeye yetkili olup olmadığını doğrularız.

“Özel alan adı”, posta sunucumuzu yönlendiren gönderenin E-posta adresinde görünen alan adıdır.

Sorun, SPF mekanizmasının doğası gereği bir zayıflığa sahip olmasıdır; çünkü gönderen doğrulama prosedürü,
Posta zarfında< görünen gönderenin kimliğinin doğrulanmasıyla uygulanır. ancak < içinde görünebilecek gönderenin kimliği değilPosta başlığı.

Bu doğal zayıflık, mevcut SPF duvarımızı kolaylıkla aşabilecek ve Sahte E-posta saldırısı gerçekleştirebilecek düşmanca bir unsur tarafından istismar edilmektedir.

Ekte SPF organizasyon sitesinden bir alıntı bulunmaktadır:

Gönderen Politikası Çerçevesi (SPF), gönderen adresi sahteciliğini önlemek için teknik bir yöntem belirten açık bir standarttır. Daha doğrusu, SPF v1 veya SPF Classic olarak adlandırılan SPF'nin mevcut sürümü, mesajların teslimi için kullanılan zarf gönderen adresini korur. E-postalardaki farklı gönderen adresi türlerinin hızlı bir açıklaması için sağdaki kutuya bakın.
(Başlık gönderen adresini koruyan veya mesajı kimin gönderdiğini hiç umursamayan, yalnızca mesajı kimin gönderdiğini umursamayan başka çözümler de vardır. bunu ilk kim yazdı.)

Çoğumuzun
Posta zarfı, gibi terimler hakkında bilgi sahibi olmadığını veya yalnızca kısmen bilgi sahibi olduğunu varsayıyorum. >Posta başlığı ve gönderenin "birden fazla gönderen kimliği" kullandığı SMTP yöntemi.

Eğer gerekli sabra sahipseniz, bu yazıyı okuduktan sonra bu kavramları daha iyi anlayacağınıza söz veriyorum.

Tam açıklama adına, benim görüşüm, SPF standının bir zorunlu olduğu ve posta altyapısını kullanan her kuruluş tarafından benimsenmesi gereken gerekli bir posta güvenliği standardı olarak kabul ettiğidir. .

Temel amacım, SPF standardının “kör noktasına” dikkatinizi çekmek ve muhtemelen SPF standardı ile birlikte veya yan yana ek bir posta güvenlik standardı ve mekanizması kullanmanız gerekeceğini anlamanızı sağlamaktır.

Peki bu SPF “kör noktasının” çözümü nedir?

Bu soruyu daha geniş kapsamlı sorulara genişletmek istiyorum:

S: Kuruluşuma Adres Sahteciliği veya Kimlik Avı saldırılarına karşı tam koruma sağlamak için kullanabileceğim "mükemmel çözüm" var mı veya nedir?
C: İyi haber şu ki, “mükemmel çözüm” diye bir şey var ve bu çözüm uygulandığında kuruluşunuzun Spoofing saldırılarına karşı çok iyi bir korumaya sahip olduğundan emin olabiliriz.

Daha az iyi olan haber şu ki, kuruluşumuzu herhangi bir "kötü adamdan" koruyacak ve aynı zamanda işlerimizi kolaylaştıracak "şeffaf bir enerji kubbesi" oluşturmak için kullanabileceğimiz sihirli bir formül ya da basit bir "kırmızı düğme" yok. kullanıcının herhangi bir müdahale olmadan düzenli ve şeffaf bir şekilde "işini yapması".

Sıkıntımızın çözümü, gönderenin kimliğini doğrulamamızı sağlayan DKIM, DMARC, Exchange Online Sahte E-posta kuralları, kullanıcı farkındalığı programı vb. gibi farklı posta güvenlik standartlarının bir kombinasyonu veya "kokteyli"dir.

Böyle bir kombinasyonun uygulanması, posta altyapımızı ve kullanıcılarımızı çoğu riskten ve duvarın dışında bulunan ve içeri girmek için bir yol arayan düşman unsurlardan koruyacak sağlam ve kalın bir "koruma duvarı" inşa etmemize olanak tanıyacaktır.

Başlıca görevlerimiz şunlardır:

• Sahtecilik veya Kimlik Avı saldırıları riskini ve şu veya bu şekilde yukarıdaki tehlikeleri yaşadığımızı kabul ettik.
• Olası çözümlerin her birine ve olası çözümlerin her birinin özelliklerine (avantajlar, dezavantajlar, vb.) aşina olmak.
• Organizasyonel DNA'mıza ve organizasyona özel iş ihtiyacımıza en iyi şekilde ayak uyduracak en iyi çözüm kombinasyonunun ne olduğuna karar verin.
• Mevcut koruma mekanizmasını uygulayın ve bu çözümü benimsemek ve özümsemek için gereken süre boyunca gerekli sabrı gösterin (Öğrenim modu aşaması, test aşaması, yanlış pozitif senaryoyla uğraşma vb.).

Aşağıdaki şemada “güvenlik kokteyli” olarak tanımladığım konseptin bir örneğini görüyoruz.
Bu terimin anlamı, iki veya daha fazla posta standardının veya başka bir mekanizmanın birleşimini kullandığımız bir senaryodur. birbirini tamamlayacak Exchange kuralı gibi.

Örneğin, posta altyapınızın Exchange mimarisini temel alması durumunda,
alan adımıza sahip bir E-posta adresi kullanan, kimliği doğrulanmamış bir alıcıyı tanımlayacak + SPF gönderen doğrulama standardını uygulayacak bir Exchange kuralı kullanabiliriz. Bu, bizim alan adımıza sahip bir E-posta adresi kullanan alıcının, yetkisiz bir posta sunucusu aracılığıyla E-posta gönderdiği bir senaryoyu belirleyecektir.

Diğer bir seçenek de DKIM + SPF standardına dayanan ve olası Adres Sahteciliği saldırı senaryolarının çoğu için mükemmel koruma sağlayan DMARC posta standardını kullanmak olabilir.

Özetlemek gerekirse, tüm sorunlarınızı sihirli bir şekilde çözecek kolay ve anlaşılır bir çözüm aramayın. Mevcut risklere ve bu riske yönelik güncel çözümlere aşina olun.

Tanımlayacak ve buna göre yanıt verecek Exchange kuralının nasıl uygulanacağı hakkında daha fazla bilgi edinmek istiyorsanız, kullanabileceğiniz olası seçenekleri gözden geçiren 12 makaleden oluşan bir makale dizisi yazdım - Office 365'te E-posta Sahtekarlığı Saldırısıyla Başa Çıkmak tabanlı ortam | Giriş | Bölüm 1#12

DKIM'in Office 365'te (Exchange Online tabanlı ortam) nasıl uygulanacağı hakkında daha fazla bilgi edinmek istiyorsanız, konuyu inceleyen 5 makaleden oluşan bir makale dizisi yazdım - DKIM - Etki Alanı Anahtarları Tanımlanmış Posta | Temel giriş | Bölüm 1#5

Mevcut makale serisinin yapısı

“Düşmanca bir unsur nasıl Sahte E-posta saldırısını gerçekleştirebilir ve mevcut SPF uygulamasını nasıl atlayabilir?” başlıklı makale serisi iki makale içermektedir.

Bu makaledeki ana odak noktamız şu olacak:

1. SMTP oturumunun ve E-posta mesajının veri yapısı.
2. SPF doğrulama sürecinin uygulanma şekli.
3. Düşman unsurun mevcut SPF uygulamasını atlamak için kullanabileceği teorik yol.

Bir sonraki makalede, Sahte E-posta saldırısı gerçekleştiren ve mevcut SPF altyapımızı atlatmayı başaran düşmanca bir unsurun senaryosunu simüle ettiğimiz “nasıl ayrılır” konusunu inceleyeceğiz.

SMTP oturumunun ve E-posta mesajının veri yapısı

Meta Veriler ve E-posta mesajı

Çoğu zaman E-posta mesajı terimini kullandığımızda, E-posta mesajının içerdiği metin veya E-posta mesajının eki gibi E-posta mesajının içeriğini kastediyoruz.

Gerçekte, her E-posta mesajı, meta veriler veya “verilerle ilgili veriler” olarak tanımlanabilecek ek bir bilgi katmanı içerir.

E-posta mesajının bir parçası olarak kabul edilen meta veriler, belirli bir E-posta mesajı hakkında pek çok ayrıntı ve bilgi içerir ve
E-posta mesajının kaynak posta sunucusuyla dilenerek sona erdiği yolculuğun belgelerini içerir. hedef alıcıyı barındıran hedef posta sunucusu.

E-posta iletisi meta verileri için mantıksal bir kapsayıcı olarak posta zarfı ve Posta başlığı

SMTP protokolü, belirli bir E-posta mesajıyla ilgili meta verileri tutacak iki tür "mantıksal kap" tanımlar:

Posta zarfı ve Posta başlığı.

• Posta zarfı , göndereni ve alıcıyı temsil eden posta sunucuları tarafından kullanılır.
• Posta üstbilgisi , posta istemcisi (kullanıcı tarafından) tarafından kullanılır.

Posta Zarfına kaydedilen bilgiler

Posta zarfı aşağıdaki türde bilgileri içerir:

1. Göndereni temsil eden "kaynak posta sunucusu" hakkındaki bilgileri tutun - örneğin, SMTP oturumunu başlatan posta sunucusunun IP adresi veya kaynak posta sunucusunun desteklediği DKIM gibi belirli bir güvenlik standardına ilişkin bilgiler.
2. Posta akışına dahil olan tüm posta sunucuları hakkındaki bilgileri saklayın.
3. Gönderen + alıcı kimliğine ilişkin bilgileri saklayın - gönderenin E-posta adresi ve hedef alıcının E-posta adresi.

Posta yapısı - Posta Başlığı ve Posta Gövdesi

E-posta mesajının “posta bileşeni” iki bölümden oluşur:

1. Posta başlığı - bu, meta veri bilgilerini tutan “ek bir kapsayıcıdır”. Meta veriler için neden Posta zarfına bileşeninin basit yanıtı, gerçek hayattaki senaryoya çok benzemesidir:
Posta zarfı , E-posta mesajını A noktasından B Noktasına "taşımak" için kullanılan "geçici bir araç" olarak kabul edilir.

E-postanın ardından mesaj, alıcıyı temsil eden hedef posta sunucusu tarafından kabul edilir, posta sunucusu Posta zarfında görünen bilgileri okur. Posta başlığı bölümündeki bilgilerin çoğunu kopyalayın ve ardından “yırtma” işlemini yapın. Posta zarfı'nı ayırın.

2. Posta Gövdesi - posta gövdesi, E-postayı yazan kişi tarafından E-posta mesajına eklenen metni ve ekleri içeren kısımdır.

Posta başlığı aşağıdaki türde bilgileri içerir:

1. Belirli bir E-posta mesajının karakterleri hakkındaki Bilgileri tutun - örneğin, belirli bir E-posta mesajının karakter seti, MIME türü vb.

2. Posta zarfından kopyalanan Bilgileri saklayın. Belirtildiği gibi, Posta zarfı , E-posta iletisi teslim edilmeden önce posta sunucusu tarafından kaldırılır. hedef alıcıya.

3. "Hedef posta sunucusu", yani hedef alıcıyı temsil eden posta sunucusu tarafından gerçekleştirilen farklı güvenlik kontrolleri hakkında bilgi tutun.
Çoğu zaman, hedef alıcıyı temsil eden posta sunucuları, tasarlanmış bir güvenlik kontrolü gerçekleştirir. Sahte E-posta, kötü amaçlı yazılım içeren E-posta, spam posta vb. gibi “sorunlu postaları” tanımlamak için.

SCL (spam güven düzeyi) değeri gibi "güvenlik kontrolü sonuçları" hakkındaki bilgiler Posta başlığına kaydedilir.
Başka bir örnek, posta sunucusunun gönderenin kimliğini SPF, DKIM, DMARC vb. bir standart kullanarak doğrulamak üzere yapılandırıldığı bir senaryodur. Bu gönderen kimlik testinin sonuçları ayrıca Posta başlığına yazılacaktır.

4. Gönderici + alıcı kimliğine ilişkin bilgileri saklayın - gönderenin
E-posta adresi ve hedef alıcının E-posta adresi hakkındaki bilgiler.

Diğer isteğe bağlı senaryo, Posta zarfının gönderen\alıcı kimliklerini içereceği bir senaryodur. Posta başlığında belirtilen gönderen\alıcı kimlikleri.

Posta tabanlı altyapıdaki başlıca kimlik türleri

Bu makale boyunca "kimlik" teriminden birçok kez bahsettik.
Detaylı teknik tartışmaya girmeden, posta altyapısıyla ilgili olarak bu terimin anlamını tanımlamak önemlidir.

Posta altyapısıyla ilgili olarak "kimlik" teriminin basit tanımı şu şekilde tercüme edilebilir:

1. E-posta adresi
2. IP adresi
3. Kullanıcı kimlik bilgileri
4. Sertifika

Posta altyapısı ve SPF standardı konusuna gelince, çoğunlukla E-posta adresi kimliği ve IP adresi kimliği ile ilişkilendireceğimiz ana kimlikler olacaktır.

Gönderenlerin hedef alıcıya E-posta göndermek istediğini söylediğimizde, gönderenin E-posta adresini ve hedef alıcının E-posta adresini ilişkilendiririz.

Diğer bir “kimlik” türü ise belirli bir alıcı adına E-postayı gönderen posta sunucusunun kimliğidir. Bu durumda posta sunucusunun kimliğini, posta sunucusunun kullandığı IP adresiyle ilişkilendiririz.

Gönderenin kimliğini doğrulama ihtiyacı

Posta altyapısındaki en temel güvenlik ihtiyaçlarından biri, posta akışı oturumunda yer alan tarafların kimliğini şüpheye yer bırakmayacak şekilde veya kesin olarak doğrulama ihtiyacıdır.

Daha doğru olmak gerekirse, belirli bir kimliği doğrulamamız gerektiğini söylediğimizde, çoğu zaman bu prosedürü uygulamakla ilgilenen taraf, hedefin posta altyapısı anlamına gelen “alıcı taraf”tır. alıcı.

“Harici varlık” belirli bir etki alanını (belirli bir alıcı) temsil eden posta sunucusuna hitap ettiğinde ve kendisini farklı bir “kimlik” (belirli bir E-posta adresi veya belirli bir IP adresi) kullanarak tanıttığında, hedef alıcıyı temsil eden posta altyapısının şunları yapması gerekir: gönderenin gerçekten iddia ettiği kişi olduğunu bilin.

Örneğin, Sahte E-posta veya Sahtekarlık ve Kimlik Avı saldırılarının temeli, düşmanca bir unsurun belirli bir kuruluşun posta sunucusuna hitap etmesi ve kendisinin meşru bir kuruluş alıcısı olduğunu "iddia etmesi" kavramına dayanır.

Bu "varlığın" gerçek, meşru bir alıcı mı yoksa yetkili bir kullanıcının kimliğini kullanarak kendini kamufle eden düşmanca bir unsur mu olduğunu bilmek için, posta sunucusunun, bu bilgileri doğrulamak için bir tür "kimlik kontrolü" uygulaması gerekecektir. gönderenin kimliği.

Gönderenin kimliğini doğrulamak için en popüler yöntemlerden biri SPF standardıdır. SPF standardını kullanırken, hedef alıcıyı temsil eden posta sunucusu, "kaynak posta sunucusu"nun kimliğini doğrulayacaktır; bu, göndereni temsil eden posta sunucusunun, kaynak posta sunucusu IP'sinin IP adresini kontrol ederek "yetkili" bir adreste göründüğü anlamına gelir. liste. ”

Basit bir posta akışındaki farklı kimlikler

Bu “kimlik” kavramını açıklamak için aşağıdaki şemayı kullanalım.

Senaryomuzda A tarafı, B tarafına bir e-posta mesajı iletmek istiyor.

1. İlk kimlik (1 numara), E-postayı göndermek isteyen kullanıcıyı/alıcıyı temsil eden E-posta adresidir. Senaryomuzda bu kullanıcının kimliği - angelina@thankyouforsharing.org

2. İkinci tür kimlik (2 numara), "orijinal gönderenin" diğer gönderenler adına E-posta mesajını göndermek istediği bir senaryoda uygulanır.

Klasik bir senaryo, sekreterin, yöneticisi adına harici bir alıcıya E-posta göndermek istediği, asistan ve yöneticinin yer aldığı bir sahnedir.

Özel örneğimizde yönetici kimliği şu şekildedir: Brad@thankyouforsharing.org

3. Üçüncü kimlik (3 numara), göndereni temsil eden posta sunucusunun kimliğidir.

Posta sunucusu IP adresini belirterek kaynak posta sunucusu kimliğini ilişkilendiriyoruz.

4. Dördüncü kimlik (4 numara), hedef alıcıyı temsil eden posta sunucusunun kimliğidir.

Posta sunucusu IP adresini belirterek hedef posta sunucusu kimliğini ilişkilendiriyoruz.

Hedef posta sunucusunun SPF'yi desteklemesi durumunda, gönderenin kimliğinin doğrulama işlemi, kaynak posta sunucusu IP adresinin belirli bir alan adı (E-postada görünen alan adı) için yetkili IP olarak kayıtlı olduğunun doğrulanmasıyla gerçekleştirilir. gönderenin posta adresi).

Özel senaryomuzda, SPF doğrulama işlemi belirli bir posta sunucusunun alan adı için E-posta göndermeye yetkili olup olmadığını kontrol edecektir - thankyouforsharing.org

5. Beşinci kimlik (5 numara), hedef alıcıyı temsil eden E-posta adresidir. Örneğimizde hedef alıcı, E-posta adresiyle temsil edilir - Bob@o365pilot.com.

Gönderen ve alıcı kimliklerinin değerlerini içeren posta alanları

Bu bölümde, gönderenin ve alıcının E-posta adresinin "kimliklerini" temsil etmek için SMTP protokolü tarafından kullanılan belirli "posta alanlarını" incelemek istiyorum.

Belirtildiği gibi, standart bir E-posta mesajı iki bölümden oluşur: Posta zarfı ve
Posta başlığı.

Bu bileşenlerin her biri, gönderenin ve alıcının kimliğini temsil etmek için farklı "posta alanları" kullanır.

Mail envelope (RFC 5321)

İTİBAREN

Mail header (RFC 5322)

MAİL ŞU KİŞİDEN GELDİ

Posta zarfı - gönderenin ve alıcının değerini tutan “posta alanları”

1. Gönderenin kimliği - Posta zarfı , - MAIL FROM, gönderenin kimliğine (gönderenin E-posta adresi) ilişkin bilgileri “tutmak” için kullanılır.
2. Alıcı kimliği - Posta zarfı , - RCPT TO, alıcının kimliğine (hedef alıcının E-posta adresi) ilişkin bilgileri “tutmak” için kullanılır.

Posta başlığı - gönderenin ve alıcının değerini tutan “posta alanları”

“Posta bileşeni” ile ilgili olarak, gönderen ve alıcının kimliklerine ilişkin bilgilerin tutulduğu kısım Posta başlığıdır . .

1. Gönderenin kimliği - Posta başlığı, - adında bir "posta alanı" kullanır. FROM, gönderenin kimliğine (gönderenin E-posta adresi) ilişkin bilgileri "tutmak" için kullanılır.
2. Alıcı kimliği - Posta başlığı, - adında bir "posta alanı" kullanır. TO alıcının kimliği (hedef alıcının E-posta adresi) hakkındaki bilgileri "tutmak" için.

Posta zarfı altyapısı ile Posta üstbilgisi altyapısı arasındaki ilişki

İki farklı kimlik kümesini kullandığımız yöntem (Posta zarfı kimlikleri ve Posta başlığı kimlikleri) kafa karıştırıcı olarak değerlendirilebilir.

Şimdilik, SMTP protokolünün çeşitli iş senaryolarının ihtiyaçlarına cevap vermek için yarattığı bu “ayrılma”nın temel cevabıyla yetinelim.

Bazı senaryolarda, Posta zarfı 'ndaki gönderen ve alıcı kimlikleriyle ilgili bilgiler aşağıdakilerle aynı olacaktır: Posta başlığı ve bazı senaryolarda hayır.

Genel senaryo; Posta zarfındaki kimlikler, Posta başlığı.

En yaygın senaryo, gönderen ve hedef alıcı kimliklerinin yalnızca bir kümesini kullandığımız durumdur.

Örneğin, bir kullanıcı yeni bir E-posta adresi yazdığında, E-posta adresi MAIL FROM posta alanında otomatik olarak yapılandırılır. ve hedef alıcının E-posta adresi RCPT TO posta alanında yapılandırılır.

Hedef posta sunucusunun tüm güvenlik kontrollerini tamamlaması ve E-posta mesajını kabul etmeye istekli olması durumunda, gönderen ve alıcının kimlik bilgileri < dosyasından kopyalanacaktır.Posta zarfını Posta başlığına gönderin.

• MAIL FROM alanındaki bilgiler alanına kopyalanacaktır. Posta başlığı alanı şu şekilde adlandırılmıştır: FROM.
• RCPT TO alanındaki bilgiler alanına kopyalanacaktır. Posta başlığı alanı şu şekilde adlandırılmıştır: TO.

Başka bir senaryo: Posta zarfındaki kimlikler, Posta başlığı.

Bu senaryoda kaynağı, göndereni temsil eden farklı “kimlikler kümesi” ve hedef alıcıyı temsil eden farklı “kimlikler” vardır.

Böyle bir durumu gösterebilmek için aşağıdaki senaryoyu kullanalım:

• Suzan, John'un kişisel asistanıdır.
• John Suzan'dan müşterilerinden birine bir E-posta mesajı göndermesini istedi.

Suzan yeni bir E-posta iletisi oluşturduğunda, Suzan kimliğiyle ilgili bilgiler Posta klasörüne kaydedilecektir. MAIL FROM alanına zarf yazın.

John'un kimliğine ilişkin bilgiler FROM alanında tanımlanacaktır.

Bu senaryoda, MAIL FROM alanında depolanan bilgiler. ">Posta zarfı, Posta başlığına kopyalanmayacak çünkü FROM alanı zaten John'un E-posta adresiyle "dolduruldu".

SMTP posta akışına dahil olan "ek" kimlikler

Bu bölümde, SMTP posta akışında yer alan üç ek "kimliği" kısaca gözden geçirmek istiyorum.

Kaynak posta sunucusunun kimliği | HELO \EHLO komutu

Belirtildiği gibi “kaynak posta sunucusunun” “ana kimliği” sunucunun IP adresidir.

Kaynak posta sunucusunun başka bir posta sunucusuyla SMTP oturumunu başlattığında sağlayabileceği ek kimlik türleri şunlardır: ana bilgisayar adı + posta sunucusunun temsil ettiği etki alanı adı.

Kaynak posta sunucusunun sağlayabileceği bilgiler zorunlu bir gereklilik değil, isteğe bağlıdır.

Kaynak posta sunucusunun bu tür bir kimlik (HOST adı, temsil ettiği alan adı veya FQDN olarak tanımlanan ana bilgisayar adı + alan adı kombinasyonu) sağlamak istemesi durumunda, posta sunucusu bu bilgiyi SMTP'den sonra sağlayabilir. komut HELO (veya EHLO).

Yanıt kimliği

E-posta mesajına eklenebilecek ikinci tür “kimlik”,
adlı posta alanıdır - REPLY-TO.

Adından da anlaşılacağı gibi, bu posta alanının amacı, hedef alıcının yanıtla düğmesine "basması" durumunda kullanmasını istediğimiz belirli bir
E-posta adresi hakkında bilgi eklemektir.

Varsayılan olarak bu posta alanı boştur ve hedef alıcının yanıt seçeneğini kullanması durumunda kullanılacak varsayılan değer (E-posta adresi), TO posta alanı.

DÖNÜŞ YOLU kimliği

E-posta mesajına eklenebilecek üçüncü tür “kimlik”,
adlı posta alanıdır - RETURN-PATH.

Bu posta alanının amacı, hedef posta sunucusu tarafından "göndereni" alıcının mevcut olmaması vb. gibi bir sorun hakkında bilgilendirmek için kullanılacak E-posta adresini içerir.
Varsayılan olarak, değer RETURN-PATH posta alanının (E-posta adresi) kaynak gönderen veya kaynak posta sunucusu tarafından belirlenmedi bunun yerine hedef posta sunucusu tarafından.

Hedef posta sunucusu E-posta mesajını aldığında, E-posta adresini MAIL FROM alanından "çıkaracaktır" ve bu E-posta adresini, kopyalar. Posta başlığı

Gönderenin ve alıcının kimliğine ilişkin bilgileri “içeren” posta alanları ile ilgili olarak iki olası senaryodan biri gerçekleşebilir:

Dava 1

Kaynak posta sunucusundan gönderilen bilgilerin posta alanlarına ilişkin değerleri içermemesi durumunda - FROM ve TO, hedef posta sunucusu aşağıdaki prosedürü uygulayacaktır:

• MAIL FROM alanındaki E-posta adresini Posta başlığı FROM
• RCPT TO alanındaki E-posta adresini Posta başlığı TO
• MAIL FROM alanındaki E-posta adresini Posta başlığı RETURN-PATH

Durum 2

Kaynak posta sunucusundan gönderilen bilgilerin aşağıdaki posta alanlarından biri veya tümü için değerleri içermesi durumunda - FROM veya TO için, hedef posta sunucusu aşağıdaki prosedürü uygulayacaktır:

Posta alanlarından birinin Posta başlığına (FROM veya TO) belirli bir değer ekleyin (E-posta adresi) , bilgiler kopyalanmayacak veya başka bir deyişle, < içinde görünen değer üzerine yazılmayacaktır Posta zarfı.

Posta üstbilgisine (FROM veya TO) ve belirli bir değer içermiyor (E-posta adresi) seçeneğini belirlediğinizde, bilgiler sırasıyla Posta zarfı posta alanlarından kopyalanacaktır.

Sürecin sonunda hedef posta sunucusu tarafından uygulanacak aşağıdaki görev yer alacaktır:

• Hedef posta sunucusu Posta zarfını (Posta) kaldıracaktır. zarf, alıcıya gönderilen E-posta iletisinin bir parçası değildir).
• Hedef posta sunucusu, E-posta mesajını hedef alıcıya teslim edecektir.

SPF doğrulama süreci - ortak senaryo

Bir sonraki bölümde hedef mail sunucusunun uyguladığı SPF doğrulama sürecini kısaca gözden geçirmek istiyorum.

SPF doğrulama sürecini göstermek için aşağıdaki senaryoyu kullanalım:

• Suzan, E-posta adresini kullanan kaynak göndericidir - Suzan@thankyouforsharing.org
• E-posta adresini kullanan hedef alıcı Bob - Bob@thankyouforsharing.org

Suzan'ı temsil eden kaynak posta sunucusu, hedef alıcıyı temsil eden posta sunucusuna (Bob) adres verir.

Senaryomuzda, Posta zarfı gönderenle ilgili bilgileri içerir (MAIL FROM) ve hedef alıcı hakkında (RCPT TO) ancak Posta başlığı alanları (FROM ve < span style="color: #800080;">TO) boş.

Hedef postanın, gönderenin kimliğini doğrulamak için SPF'yi kullanacak şekilde yapılandırıldığı göz önüne alındığında, posta sunucusu aşağıdaki görevleri gerçekleştirecektir:

1. Gönderen adresinden (MAIL FROM) gönderenin alan adını temsil eden kısmı "Getir ". Senaryomuzda alan adı - thankyouforsharing.org
2. Kaynak posta sunucusunun IP adresini “bir yere yazın”.
3. DNS sunucusunu adresler ve thankyouforsharing.org etki alanının bir SPF kaydına (bir TXT kaydı) sahip olup olmadığını kontrol eder. Böyle bir kaydın mevcut olması durumunda SPF kaydının içeriğini “okuyun”.
4. Kaynak posta sunucusunun IP adresinin SPF kaydındaki IP adreslerinden biri olarak görünüp görünmediğini doğrulayın.
5. Kaynak posta sunucusunun IP adresinin listede görünmesi durumunda SPF doğrulama testi “başarılı” olarak değerlendirilir. Bunun anlamı, kaynak posta sunucusunun thankyouforsharing.org alıcılarına bir E-posta iletisi gönderme yetkisine sahip olmasıdır.

Daha karmaşık senaryo ve SPF doğrulama yönteminin güvenlik açığı

Aşağıdaki bölümde, düşmanca bir unsurun, kuruluşumuza saldırmak ve posta sunucumuz tarafından uygulanan SPF doğrulama kontrolünü atlamak için kimlik avı veya kimlik avı saldırıları uygulamak için nasıl kullanabileceğini incelemek istiyorum.

Saldırı aşağıdaki yapı taşlarına dayanmaktadır:

1. SMTP standardı | birden fazla gönderen kimliği kullanma

SMTP protokolü, E-posta mesajını hedef alıcıya gönderen öğe anlamına gelen “kaynak”ın iki farklı kimlik sağlayabileceği bir seçenek içerir:

• A göndericisinin kimliği MAIL FROM posta alanında (Posta zarfı).
• B göndericisinin kimliği FROM posta alanında (Posta başlığı).

2. SPF gönderen doğrulama süreci | MAIL FROM posta alanı ve FROM posta alanı

• SPF gönderen doğrulama işlemi yalnızca MAIL FROM'da görünen gönderenin kimliği (E-posta adresi) için uygulanır.
• SPF gönderen doğrulama işlemi, yalnızca UYGULANMAZ. #800080;">KİMDEN

Bunun anlamı, "FROM " kimliği kontrol edilmediği veya doğrulanmadığı için SPF standardının bir "kör noktaya" sahip olmasıdır. SPF doğrulama testiyle.

En büyük sorun, bu “Ölümcül Kokteyl”i bilen düşman unsurun, SPF standardının sahip olduğu bu “kör nokta”yı çok kolaylıkla istismar edebilmesidir.

SPF'nin "kör noktasından" yararlanan Sahte E-posta saldırısının DNA'sı

SPF "kör nokta"nın istismarları, düşman unsur tarafından şu şekilde uygulanır:

Bir Sahtekarlık veya Kimlik Avı saldırıları gerçekleştirirken, düşmanca unsurun temel amacı, karşı tarafın kendisi için bir şeyler yapmasını ve yapmasını sağlamaktır (bir banka hesabına para aktarmak, bir web bağlantısına tıklamak vb.).

Saldırmak istediği hedef alıcıyı somut eylemi "yapmaya" ikna etmek için, düşman unsurun gerçek kimliğini gizlemesi ve kendisini meşru bir kullanıcı/alıcı olarak sunması gerekir. Başka bir deyişle, hedef alıcının güvenebileceği bir E-posta adresi sağlayın.

Hedef alıcıyı temsil eden posta altyapısı, SPF standardı tarafından uygulanan gönderen doğrulama prosedürlerini kullandığında bile, kimlik avı veya kimlik avı saldırısı gerçekleştirmeyi başarmak için.

Bu “SPF bypass mekanizmasını” gerçekleştirmek için düşman unsur aşağıdaki adımları gerçekleştirir:

1. Sahte alan adı satın alın - Alan adının gerçek bir anlamı olmadığı için “kukla alan adı” terimini kullanıyorum. Sahte alan adının amacı, hedef alıcıyı temsil eden posta sunucusu tarafından uygulanacak SPF gönderen doğrulama işlemi için bir tuzak görevi görmektir.
2. Sahte alan adını barındıran DNS sunucusunda gerekli SPF kaydını yapılandırın.
3. Kimlik avı veya kimlik avı saldırısı gerçekleştirmek için kullandığı posta sunucusunun IP adresi anlamına gelen gerekli bilgileri ekleyin.

Sahte E-posta saldırısı şu şekilde uygulandı:

Düşman unsur, iki gönderenin E-posta adresini içeren bir E-posta oluşturur.

• İlk E-posta adresi (MAIL FROM) "meşru alan adını" (sahte alan adı) kullanıyor. Özel örneğimizde, MAIL FROM E-posta adresi “kırmızı alan” E-posta adresidir.
• İkinci E-posta adresi (FROM), saldırmak istediği alıcının alan adını kullanır. Özel örneğimizde, FROM E-posta adresi “yeşil alan”
  E-posta adresidir.

Hedef alıcıyı temsil eden posta sunucusunun SPF'yi desteklediği göz önüne alındığında, gönderen doğrulama işlemi “kırmızı E-posta adresi” (kukla alan adını kullanan E-posta adresi) doğrulanarak uygulanacaktır.

Düşman unsuru göz önüne alındığında

• Gerekli SPF kaydını oluşturun
• SPF kaydında IP adresi görünen posta sunucusunu kullanır (kukla alan adını kullanarak E-posta mesajını gönderen posta sunucusu)

SPF gönderen hassas doğrulaması başarıyla tamamlanacak.

Hedef posta sunucusu, MAIL dahil olmak üzere Posta zarfını kaldırır. FORM adresini girin ve “yeşil E-posta adresini” bırakın (FROM E-posta adresi) ).
Alıcının varış noktası açısından bakıldığında, E-posta mesajı gönderen tarafından “yeşil E-posta adresi” ile gönderilmiştir. Hedef alıcı, Posta zarfında görünen "ilk E-posta adresinin" kaldırıldığının farkında değil.

Düşman unsurun SPF doğrulama kontrolünü nasıl atladığının gösterilmesi

Düşman unsurun SPF gönderen doğrulama kontrolünü atlamak için kullanabileceği yolu gösterebilmek için aşağıdaki senaryoyu kullanalım:

Düşman bir unsur - o365pilot.com adlı şirkete saldırmayı planlıyor (Spoofing\spear Phishing saldırısını gerçekleştiriyor)

Düşman unsur ödevini yaptı ve organizasyonda hayati rol oynayan kişiler hakkında gerekli bilgileri buldu:

• Şirketin CIO'su Bob'dur ve Bob@o365pilot.com e-posta adresini kullanır.
• Şirketin CFO'su Suzan@o365pilot.com e-posta adresini kullanan Suzan'dır.

Düşman unsur Bob'a Suzan'dan geldiği anlaşılan Sahte E-posta göndermeyi planlıyor.

Düşman unsur, o365pilot.com posta altyapısının, gelen her posta için bir SPF gönderen doğrulama kontrolü uyguladığını biliyor.

Düşman öğe, SPF gönderen doğrulama kontrolünü atlayabilmek için - thankyouforsharing.org
adında sahte bir alan adı kullanır. Düşman öğe, bunu kullanacak gerekli SPF kaydını oluşturur. alan adının yetkili posta sunucusu hakkında bilgi yayınlamak için - thankyouforsharing.org

Düşman unsur, iki gönderenin E-posta adresini içeren yeni bir e-posta mesajı oluşturur:

• evil@thankyouforsharing.org
• suzan@o365pilot.com

Düşman unsurun saldırmak istediği hedef alıcı, şirketin CEO'su Bob'dur.

Düşman eleman posta sunucusu, bir SMTP oturumu başlatarak hedef alıcıyı temsil eden posta sunucusuna hitap edecek ve ondan E-posta mesajını hedef alıcıya teslim etmesini isteyecektir.

Hedef posta sunucusu, MAIL FROM'da görünen E-posta adresi için SPF gönderen doğrulama testini gerçekleştirecektir.

Senaryomuzda, posta sunucusu alan adının SPF kaydını doğrulamaya çalışacaktır - thankyouforsharing.org

SPF kaydının doğru yapılandırıldığı göz önüne alındığında, SPF gönderen doğrulama testi başarıyla tamamlanır ve hedef alıcıyı temsil eden posta sunucusu, gönderenin güvenilir olabileceğini (gönderenin meşru bir gönderen olduğunu) "beyan eder".

Hedef posta sunucusu, MAIL FROM
(evil@thankyouforsharing.org) posta alanına - DÖNÜŞ YOLU.

Hedef posta sunucusu, E-posta adresiyle ilgili bilgileri içeren Posta zarfını kaldıracaktır - evil@thankyouforsharing.org

Posta sunucusu, E-posta mesajını hedef alıcıya (Bob) iletecektir.
Bob, E-posta mesajını suzan@o365pilot.com

Güncel makale serisinin bir sonraki makalesi

Bir sonraki makalede - Sahte E-posta saldırısı nasıl simüle edilir ve SPF gönderen doğrulaması nasıl atlanır? | 2#2'de Sahte E-posta saldırısını nasıl simüle edeceğimizi ve SPF gönderen doğrulamasını nasıl atlayacağımızı öğreneceğiz.