الاستجابة لتقرير الثغرات الخاصة بتهريب عبارة البريد الإلكتروني الآمنة SMTP من Cisco

المقدمة

يقدم هذا المستند المزيد من التفاصيل حول كيفية تصرف البريد الإلكتروني الآمن من Cisco ضد نوع الهجوم الموضح في تهريب SMTP - انتحال رسائل البريد الإلكتروني في جميع أنحاء العالم، والذي تم نشره في 18 ديسمبر 2023 بواسطة SEC Consult.

وفي إطار مشروع بحثي بالتعاون مع مختبر إستشعار الضعف التابع للجنة الأوراق المالية والبورصة، اكتشف تيمو لونجين (@timolongin) تقنية إستغلال جديدة لبروتوكول آخر على شبكة الإنترنت وهو SMTP (البروتوكول البسيط لنقل رسائل البريد). يمكن للجهات الفاعلة التي تشكل تهديدا إساءة إستخدام خوادم SMTP الضعيفة في جميع أنحاء العالم لإرسال رسائل بريد إلكتروني ضارة من عناوين البريد الإلكتروني العشوائية، مما يسمح بهجمات التصيد الاحتيالي المستهدفة. وبسبب طبيعة الاستغلال نفسه، أطلق على هذا النوع من الضعف اسم تهريب SMTP.

لم تعثر Cisco على أي دليل على أن الهجوم الموضح في الورقة يمكن إستخدامه لتجاوز أي من عوامل تصفية الأمان التي تم تكوينها.

خلفية تقنية

بدون الخوض في تفاصيل حول بروتوكول SMTP وتنسيق الرسائل، من المهم النظر إلى بضعة أقسام من RFC 5322 للحصول على سياق ما.

يعرف القسم 2.1 تسلسل أحرف CRLF على أنه الفاصل الذي سيتم إستخدامه بين الأقسام المختلفة للرسالة.

تنقسم الرسائل إلى أسطر من الحروف. السطر هو سلسلة من الحروف التي يتم حدها بحرفين إعادة- رجوع وتغذية خط؛ بمعنى، حرف إعادة النقل (CR) (قيمة ASCII 13) يتبعه فورا حرف تغذية الخط (LF) (قيمة ASCII 10). (عادة ما تتم كتابة زوج تغذية خط/إعادة النقل في هذا المستند باسم "CRLF".)

والقسم 2-3 أكثر تحديدا بشأن شكل نص الرسالة. فهو يذكر بوضوح انه لا يجب ابدا ارسال حروف ال‍ CR وال‍ LF بشكل مستقل كجزء من الجسم. لا يتوافق أي خادم يفعل ذلك مع RFC.

مضمون الرسالة ببساطة خطوط من شخصيات US-ASCII. قيدان فقط على الجسم هما:

• يجب أن يظهر كلا من CR و LF معا فقط ك CRLF، ويجب ألا تظهر بشكل مستقل في الجسم.
• يجب أن تكون أسطر الحروف في النص الأساسي محدودة ب 998 حرف، ويجب أن تكون محددة ب 78 حرف، باستثناء CRLF.

ومع ذلك، فإن القسم 4.1 من ذلك المستند نفسه، في إشارة إلى الصياغة القديمة من التنقيحات السابقة ل RFC التي لم تكن مقيدة بنفس القدر، يقر بأن العديد من عمليات التنفيذ في الميدان لا تستخدم الصياغة الصحيحة.

يظهر كلا من CR و LF العاريين في الرسائل التي لها معنيان مختلفان. في العديد من الحالات، يتم إستخدام CR أو LF العاري بشكل غير صحيح بدلا من CRLF للإشارة إلى فواصل الخطوط. وفي حالات أخرى، يتم إستخدام كلا من CR و LF العارية كمجرد شخصيات تحكم أمريكية-ASCII بمعانيها التقليدية.

للتلخيص، وفقا ل RFC 5322، ستبدو رسالة SMTP منسقة بشكل صحيح كالمثال التالي:

ehlo sender.example\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <user@sender.example>\r\n
To: <user@receiver.example>\r\n
Subject: Example\r\n
\r\n
lorem ipsum\r\n
\r\n. \r\n

يحاول الورق الاستفادة من الاستثناء المذكور في القسم 4.1 من RFC لإدراج رسالة جديدة أو "تهريبها" كجزء من النص في محاولة لتجاوز التدابير الأمنية على الخادم المرسل أو المستلم. الهدف هو أن تتجاوز الرسالة المهربة عمليات التحقق الأمنية لأن تلك التحققات لن يتم تشغيلها إلا على جزء من الرسالة قبل تغذية الخط العاري. على سبيل المثال:

ehlo sender.example\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <user@sender.example>\r\n
To: <user@receiver.example>\r\n
Subject: Example\r\n
\r\n
lorem ipsum\r\n
\n. \r\n
mail FROM:<malicious@malicious.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <malicious@malicious.example>\r\n
To: <user@receiver.example>\r\n
Subject: Malicious\r\n
\r\n
Malicious content\r\n
\r\n. \r\n

سلوك بريد Cisco الآمن

عند تكوين وحدة إصغاء SMTP على بريد Cisco الآمن، هناك ثلاثة خيارات تكوين تحدد كيفية معالجة حروف CR و LF العارية.

مسح الرسائل من حروف CR و LF (افتراضي)

مع تحديد الخيار الافتراضي، يستبدل بريد Cisco الآمن جميع أحرف CR و LF العارية في الرسائل الواردة بتسلسل CRLF الصحيح.

يتم التعامل مع الرسالة التي تحتوي على محتوى مهرب، مثل تلك الموجودة في المثال، كرسالتين منفصلتين، ويتم تشغيل جميع عمليات التحقق من الأمان (مثل إطار عمل نهج المرسل (SPF) ومصادقة الرسائل المستندة إلى المجال وإعداد التقارير والمطابقة (DMARK) ومكافحة البريد العشوائي ومكافحة الفيروسات والحماية المتقدمة من البرامج الضارة (AMP) وعوامل تصفية المحتوى) بشكل مستقل على كل منها.

ملاحظة: يجب أن يكون العملاء على دراية بأنه، باستخدام هذا التكوين، قد يتمكن المهاجم من تهريب رسالة تنتحل صفة مستخدم آخر. قد يكون للمهاجم تأثير أكبر في الحالات التي يستضيف فيها الخادم الأصلي مجالات متعددة لأن المهاجم يمكن أن ينتحل مستخدم من أحد المجالات الأخرى التي تتم إستضافتها على الخادم، وسيستمر التحقق من SPF على البريد الإلكتروني المهرب.

رفض الرسائل ذات أحرف CR أو LF العارية

يفرض خيار التكوين هذا التوافق تماما مع RFC. يتم رفض أي رسائل تحتوي على أحرف CR أو LF عارية

على الرغم من أن هذا التكوين يمنع سيناريو التهريب، إلا أنه سيتسبب أيضا في إسقاط رسائل البريد الإلكتروني الشرعية الواردة من الخوادم غير المتوافقة مع RFC.

السماح بالرسائل ذات أحرف CR أو LF العارية (مهملة)

يتسبب التكوين النهائي في قيام Cisco Secure Mail بمعالجة أحرف CR و LF العارية بمعنى ASCII الخاص بها. يتم تسليم نص الرسالة كما هو، بما في ذلك المحتوى المهرب.

نظرا لمعاملة الرسالة المهربة على أنها جزء من النص الأساسي، قد لا يتم اكتشاف المرفقات المضمنة كجزء من الرسالة المهربة بواسطة بريد Cisco الآمن. قد يتسبب ذلك في حدوث مشاكل أمان على أجهزة تدفق البيانات. تم إهمال هذا الخيار ولا يجب إستخدامه بعد الآن.

التكوين الموصى به

توصي Cisco باستخدام الخيار الافتراضي "رسائل نظيفة من حروف CR و LF العارية" لأنه يوفر أفضل تسوية بين الأمان وقابلية التشغيل البيني. ومع ذلك، يجب أن يكون العملاء الذين يستخدمون هذا الإعداد على دراية بآثار الأمان فيما يتعلق بالمحتوى المهرب. يجب على العملاء الذين يرغبون في فرض التوافق مع معيار RFC إختيار "رفض الرسائل التي تحتوي على أحرف CR أو LF حقيقية"، نظرا لأنهم على دراية بمشكلات قابلية التشغيل البيني المحتملة.

في أي حالة، توصي Cisco بشدة بتكوين ميزات مثل SPF أو DomainKeys Defined Mail (DKIM) أو DMARK واستخدامها للتحقق من صحة مرسل رسالة واردة.

يعمل الإصداران 15.0.2 و 15.5.2 من AsyncOS والإصدارات الأحدث على إضافة وظائف جديدة تساعد على تحديد الرسائل التي لا تتوافق مع المعيار RFC الخاص بنهاية الرسالة وتصفيتها. إذا تم تلقي رسالة ذات تسلسل نهاية رسالة غير صالح، تضيف عبارة البريد الإلكتروني رأس ملحق نهاية رسالة غير صالح ل X-IronPort (X-Header) إلى جميع معرفات الرسائل (MIDs) ضمن هذا الاتصال حتى يتم تلقي رسالة تتوافق مع معيار RFC لنهاية الرسالة. يمكن للعملاء إستخدام عامل تصفية محتوى للبحث عن رأس "X-IronPort-Invalid-End-Message" وتحديد الإجراءات التي يجب إتخاذها لهذه الرسائل.

الأسئلة المتكررة

هل "بريد Cisco الآمن" عرضة للهجوم الموضح؟
تقنيا، نعم. عند تضمين أحرف CR و LF العارية في البريد، من الممكن التسبب في التعامل مع جزء من البريد الإلكتروني كبريد إلكتروني ثان. ومع ذلك، بما أنه يتم تحليل البريد الإلكتروني الثاني بشكل مستقل، فإن السلوك يعادل إرسال رسالتين منفصلتين. لم تعثر Cisco على أي دليل على أن الهجوم الموضح في الورقة يمكن إستخدامه لتجاوز أي من عوامل تصفية الأمان التي تم تكوينها.

توفر الورقة أمثلة عن عمليات التحقق من SPF و DKIM التي تم تجاوزها. لماذا تقول Cisco أنه لا يتم تجاوز أي عوامل تصفية؟
في تلك الأمثلة، يتم تشغيل تحققات SPF كما هو متوقع، ولكن ينتج عنها التحقق الذي تم تمريره بسبب امتلاك الخادم المرسل لعدة مجالات.

ما هو التكوين الموصى به؟
يعتمد الاختيار الأكثر ملاءمة للعميل على متطلباتهم الخاصة. الخيارات الموصى بها هي إما التكوين الافتراضي "نظيف" أو البديل "رفض".

هل يؤدي إختيار خيار الرفض إلى نتائج إيجابية خاطئة؟
تبدأ وظيفة "الرفض" تقييم التزام البريد الإلكتروني بمعايير RFC. في حالة فشل البريد الإلكتروني في التوافق مع معايير RFC، سيتم رفضه. حتى رسائل البريد الإلكتروني الشرعية يمكن رفضها إذا لم يكن البريد الإلكتروني متوافقا مع معايير RFC.

هل هناك خطأ برمجي يغطي هذه المشكلة؟
تم تصنيف معرف تصحيح الأخطاء من Cisco CSCwh10142.

كيف يمكنني الحصول على المزيد من المعلومات حول هذا الموضوع؟
ويمكن إثارة أي أسئلة للمتابعة من خلال قضية مركز المساعدة التقنية.