SMTP Smuggling
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
इस प्रकार की भेद्यता इस पोस्ट में मूल रूप से खोजी गई थी जहां यह समझाया गया है कि ईमेल को अंतिम रूप देने के समय SMTP प्रोटोकॉल की व्याख्या में असमानताओं का शोषण करना संभव है, जिससे एक हमलावर को वैध ईमेल के शरीर में अधिक ईमेल को स्मगल करने की अनुमति मिलती है, जिससे प्रभावित डोमेन के अन्य उपयोगकर्ताओं (जैसे admin@outlook.com) का अनुकरण किया जा सकता है, SPF जैसी सुरक्षा को बायपास करते हुए।
यह इस कारण से है कि SMTP प्रोटोकॉल में, ईमेल में भेजे जाने वाले संदेश का डेटा एक उपयोगकर्ता (हमलावर) द्वारा नियंत्रित किया जाता है जो विशेष रूप से तैयार किए गए डेटा को भेज सकता है जो पार्सर्स में भिन्नताओं का शोषण करता है जो रिसेप्टर में अतिरिक्त ईमेल को स्मगल करेगा। इस मूल पोस्ट से इस चित्रित उदाहरण पर एक नज़र डालें:
इस भेद्यता का शोषण करने के लिए, एक हमलावर को कुछ डेटा भेजने की आवश्यकता होती है जिसे आउटबाउंड SMTP सर्वर केवल 1 ईमेल समझता है लेकिन इनबाउंड SMTP सर्वर सोचता है कि कई ईमेल हैं।
शोधकर्ताओं ने खोजा कि विभिन्न इनबाउंड सर्वर विभिन्न वर्णों को ईमेल संदेश के डेटा के अंत के रूप में मानते हैं जो आउटबाउंड सर्वर नहीं करते।
उदाहरण के लिए, डेटा का सामान्य अंत \r\n.
है। लेकिन यदि इनबाउंड SMTP सर्वर \n.
का भी समर्थन करता है, तो एक हमलावर बस उस डेटा को अपने ईमेल में जोड़ सकता है और नए ईमेल को स्मगल करने के लिए SMTP कमांड को इंगित करना शुरू कर सकता है जैसे कि पिछले चित्र में।
बेशक, यह केवल तभी काम कर सकता है यदि आउटबाउंड SMTP सर्वर इस डेटा को संदेश डेटा के अंत के रूप में नहीं मानता है, क्योंकि उस मामले में यह केवल 1 के बजाय 2 ईमेल देखेगा, इसलिए अंत में यह असंगति है जिसका इस भेद्यता में शोषण किया जा रहा है।
संभावित असंगति डेटा:
\n.
\n.
यह भी ध्यान दें कि SPF बायपास किया गया है क्योंकि यदि आप admin@outlook.com
से user@outlook.com
के ईमेल से एक ईमेल स्मगल करते हैं, तो प्रेषक अभी भी outlook.com
है।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)