साझा-बुनियादी ढांचे का दुरुपयोग और प्रेषक का आरोप

एक स्रोत आईपी किसी विशेष डोमेन का उपयोग करने के लिए अधिकृत ग्राहक की पहचान किए बिना परिवहन पथ की पहचान कर सकता है। साझा सेवाएँ असंबद्ध किरायेदारों को सामान्य बुनियादी ढाँचे के पीछे रखती हैं। परिवहन मूल, किरायेदार प्राधिकरण, हस्ताक्षर पहचान और मानवीय जिम्मेदारी को अलग रखें। एक वैध डोमेन हस्ताक्षर महत्वपूर्ण साक्ष्य है, लेकिन एक अपस्ट्रीम प्राधिकरण त्रुटि गलत अनुरोध को हस्ताक्षरकर्ता तक पहुंचने की अनुमति दे सकती है।

खतरे का मॉडल और ऐतिहासिक साक्ष्य बताएं

यहां जिस जोखिम पर विचार किया गया है वह एक व्यापक प्रदाता स्रोत पर भरोसा करने का रिले है, उस स्रोत को ग्राहक से बाध्य किए बिना उसके हस्ताक्षर मार्ग का उपयोग करने की अनुमति है। मॉडल में हमलावर एक ही साझा सेवा पर एक अलग किरायेदार को नियंत्रित करता है, न कि ब्रांड की निजी कुंजी को। प्रभावित परिसंपत्तियाँ अधिकृत डोमेन उपयोग और बाद के एट्रिब्यूशन की सटीकता हैं। यह एक ऐतिहासिक विफलता वर्ग है, यह दावा नहीं है कि नामित सेवा वर्तमान में असुरक्षित है।

29 जुलाई, 2024 को नाटी ताल द्वारा प्रकाशित गार्डियो लैब्स की मूल इकोस्पूफिंग रिपोर्ट, Microsoft 365 और Proofpoint रूटिंग के माध्यम से दुरुपयोग का वर्णन करती है जिसमें अनधिकृत संदेशों ने वैध प्रमाणीकरण प्राप्त किया। इसका प्रकटीकरण अनुभाग किरायेदार-विशिष्ट फ़िल्टरिंग को शमन के रूप में वर्णित करता है और किरायेदार मेटाडेटा की उत्पत्ति पर चर्चा करता है। मूल अनुसंधान. नीचे दी गई लिखित तुलना उस सीमा को दर्शाती है; यह न तो शोषण को पुन: प्रस्तुत करता है और न ही वर्तमान विक्रेता कार्यान्वयन का मूल्यांकन करता है।

एट्रिब्यूशन फ़ील्ड को अलग रखें

SMTP अवलोकन संदेश प्रबंधन का वर्णन करते हैं, जबकि DKIM एक संदेश को एक हस्ताक्षरित डोमेन के साथ संबद्ध करता है। न तो अकेले उस व्यक्ति को स्थापित करता है जिसने व्यावसायिक अनुरोध तैयार किया या अनुमोदित किया। RFC 5321 और RFC 6376. विश्वसनीय प्राप्त समय, कनेक्टिंग स्रोत, किरायेदार साक्ष्य जहां उपलब्ध हो, डोमेन से और सत्यापित हस्ताक्षर डोमेन को अलग-अलग फ़ील्ड के रूप में संरक्षित करें।

किरायेदार का साक्ष्य एक स्थापित विश्वसनीय सीमा से आना चाहिए। एक अनुमत किरायेदार का दावा करने वाला एक मनमाना संदेश हेडर सत्यापित परिवहन संदर्भ के बराबर नहीं है। Authentication-Results फ़ील्ड को इसी प्रकार एक विश्वसनीय स्रोत की आवश्यकता होती है। RFC 8601. परिनियोजन समीक्षा को यह स्थापित करना चाहिए कि कोई सेवा उस संदर्भ को कैसे प्रमाणित और संरक्षित करती है, न कि केवल यह जाँचती है कि कोई फ़ील्ड मौजूद है या नहीं।

पाँच काल्पनिक प्राधिकरण मामलों की तुलना करें

मान लें कि एक जानबूझकर व्यापक नियम स्रोत-परिवार साझा-ए से किसी भी अनुरोध की अनुमति देता है। एक प्रस्तावित संकीर्ण नियम के लिए किरायेदार-अच्छे के बराबर स्वतंत्र रूप से विश्वसनीय किरायेदार संदर्भ की भी आवश्यकता होती है। ये लिखित नियम धारणाएँ हैं, न कि रनिंग कोड या विक्रेता कॉन्फ़िगरेशन।

• केस1: साझा-ए; विश्वसनीय किरायेदार किरायेदार-अच्छा; संदेश दावा किरायेदार-अच्छा। दोनों प्रस्तावित नियम अनुरोध को स्वीकार करते हैं।
• केस 2: साझा-ए; विश्वसनीय किरायेदार किरायेदार-अन्य; संदेश दावा किरायेदार-अन्य। व्यापक नियम मानता है; किरायेदार-बाध्य नियम इनकार करता है।
• केस3: साझा-ए; विश्वसनीय किरायेदार किरायेदार-अन्य; संदेश दावा किरायेदार-अच्छा। व्यापक नियम मानता है; किरायेदार-बाध्य नियम अविश्वसनीय दावे के बावजूद इनकार करता है।
• केस4: साझा-ए; विश्वसनीय किरायेदार अनुपलब्ध; संदेश दावा किरायेदार-अच्छा। व्यापक नियम मानता है; किरायेदार-बाध्य नियम गुम साक्ष्य के लिए इनकार करता है।
• केस5: परिवार से बाहर; विश्वसनीय किरायेदार किरायेदार-अच्छा; संदेश दावा किरायेदार-अच्छा। दोनों नियम इनकार करते हैं क्योंकि स्रोत-परिवार की शर्त पूरी नहीं हुई है।

विचार प्रयोग में, एक स्वीकृत अनुरोध डाउनस्ट्रीम हस्ताक्षरकर्ता तक पहुंच सकता है। इस शिक्षण संशोधन के लिए कोई कुंजी उत्पन्न नहीं हुई, संदेश पर हस्ताक्षर नहीं किया गया, क्रिप्टोग्राफ़िक चेक रन या SMTP अनुरोध नहीं भेजा गया। प्रवेश निर्णय नहीं है DMARC फैसला या डिलीवरी का प्रमाण।

विश्वसनीय संदर्भ को उसके लेबल के बजाय सत्यापित करें

उपरोक्त विश्वसनीय-किरायेदार फ़ील्ड एक आधार है, प्रदर्शित सुरक्षा तंत्र नहीं। एक वास्तविक परिनियोजन को यह स्थापित करना होगा कि उस संदर्भ को कैसे प्रमाणित किया जाता है और संदेश-नियंत्रित ओवरराइड से संरक्षित किया जाता है, जिसमें लापता संदर्भ को कैसे संभाला जाता है। ऐतिहासिक रिपोर्ट यह साबित नहीं करती कि आज का विन्यास उजागर हो गया है। वास्तविक हस्ताक्षर प्राधिकरण का मूल्यांकन करने के लिए वर्तमान विक्रेता मार्गदर्शन और अनुमोदित मार्ग साक्ष्य का उपयोग करें; किसी मनमाने हेडर को केवल इसलिए विश्वसनीय न मानें क्योंकि उसका नाम विक्रेता फ़ील्ड जैसा दिखता है।

किसी जिम्मेदार पार्टी का नाम बताने से पहले सहसंबंध स्थापित करें

किसी घटना के लिए, मूल संदेशों को अधिकृत समय-विशिष्ट मार्ग और खाता लॉग के साथ जोड़ें। एक साझा रिले पता और वैध हस्ताक्षर प्राधिकरण दोष, खाते के दुरुपयोग या वैध प्रेषक के साथ सह-अस्तित्व में हो सकते हैं; उन स्पष्टीकरणों के लिए अलग-अलग साक्ष्य की आवश्यकता होती है। रोकथाम के निर्णयों को आरोपों से अलग रखें। जब किरायेदार-स्तरीय एट्रिब्यूशन आवश्यक हो तो अनुमोदित चैनलों के माध्यम से प्रदाता जांच का अनुरोध करें, केवल प्रासंगिक पहचानकर्ताओं और समय को साझा करें।

अवलोकन किए गए तथ्यों, विश्वास, लापता खाते के साक्ष्य और अगली जवाबदेह कार्रवाई के साथ समाप्त करें। रक्षात्मक खोज अभिनेता को अनसुलझा छोड़ते हुए एक प्रमाणित डोमेन और साझा मार्ग की पहचान कर सकती है। यह किसी कंपनी को केवल इसलिए जिम्मेदारी सौंपने से अधिक उपयोगी है क्योंकि उसके मेल में समान बुनियादी ढांचे का उपयोग किया गया है।

निष्कर्षों को साक्ष्य के भीतर रखें

उदाहरण रक्षात्मक निर्णय सहायता हैं, वास्तविक लोगों या वर्तमान प्रदाताओं के खिलाफ देखे गए आरोप नहीं। प्रमाणीकरण साक्ष्य, व्यवसाय सत्यापन और एट्रिब्यूशन को अलग से रखें। वर्तमान प्रोटोकॉल स्रोत डोमेन सत्यापन और विश्वसनीय परिणाम सीमाओं का वर्णन करते हैं; वे गुम हुए खाते के साक्ष्य उपलब्ध नहीं कराते हैं या किसी आरोप के प्रकाशन को अधिकृत नहीं करते हैं।