01 - Defensive Security | Email Security Part 1

Practical guide to enhanicng Email Security

  1. Eng.Nour

    76187_10151208966107961_1735397375_n.jpg


    هل تعلم أن ٩٤٪ من الهجمات المتقدمة (أو ما يعرف ب APT / Advanced Persistent Threat) التي يقوم بها محترفون تبدأ عن طريق ال Email ? فطبقا لبحث قامت به شركة Trend Micro وجدت أن المدخل الرئيسي الذي يستخدمه المهاجمون خلال عملية الإختراق هو الـ Email...والسؤال هو كيف يحدث هذا؟



    [Video explaining APT Attacks]


    للإجابة على هذا السؤال يجب أن نفكر قليلا لماذا يفضل المهاجمون إستخدام الـ Email كنقطة هجوم مبدئية؟ والسبب في ذلك يرجع إلى:

    أولا سهولة إستخدامه بواسطة المهاجم فعادة يمكن لأي شخص خارج الشبكة إرسال Email لأي فرد داخل الشبكة.

    ثانيا إعتماد المهاجم على اضمحلال الوعي الأمني لدى عامة المستخدمين وبالتالي يسهل خداعهم.

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

    رابعا ضعف مستوى التأمين لدى قدر كبير من المؤسسات فيما يتعلق بالـ Email Security ليس لقلة الخبرة ولكن لصعوبة تحقيق التوازن بين تحقيق مستوى جيد من الحماية وبين عدم تأثير ذلك على الخدمة المقدمة فقد يؤدي رفع مستوى الحماية لمنع بعض Emails الغير خبيثة (False Positives) من الوصول للمستخدمين وبالتالي التأثير بالسلب على عمل المؤسسة. هذا التوازن يطلق عليه Security Vs Functionality.


    بالعودة إلى السؤال "كيف يحدث هذا؟"، فنجد أن الإجابة تنحصر لدينا في نقطتين لا ثالث لهما:

    الأولى أن يقوم المهاجم بارفاق Malicous Attachment مع الـ Email ويغري المستخدم لفتح Attachment عن طريق أساليب عديدة. بمجرد فتح/تشغيل Attachment يصبح المهاجم له كامل السيطرة على جهاز المستخدم ويستطيع استخدامه كنقطة هجوم داخلية على باقي الشبكة.

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



    وأحيانا يتم استخدام مزيج من الطريقتين السابقتين فيقوم المهاجم بإرسال رابط يقود الضحية لتحميل Malware بدلا من إرساله في المرفقات



    [Video explaining Phishing Attacks "First 2 Minutes Only"]


    لابد أن نعرف أن نجاح هذه الهجمات يعتمد بالدرجة الأولى على خداع المستخدم لإقناعه بفتح Malicous Attachment أو كتابة كلمة السر الخاصة به ولذلك يمكننا القول ببساطة أن رفع الوعي الأمني لدى المستخدمين هو أحد أهم الأساليب الفعالة ضد هذا النوع من الهجمات حتى أنه توجد شركات تقدم خدمة رفع الوعي الأمني (مثل Phishme.com و Phish5.com) عن طريق مهاجمة موظفي الشركة بالـ Phishing وتقوم بإمداد المسئول عن حماية الشبكة بإحصائيات عن مستوى الوعي لدى المستخدمين ومن تحديدا من المستخدمين يجب العمل على تحسين حس الوعي الأمني لديه.



    بعيدا عن رفع الوعي الأمني (أو ما يعرف ب Security Awareness)...ما الذي يمكننا فعله نحن المسئولون عن حماية الشبكة لحماية المستخدمين؟ كما ذكرنا سابقا فإن أمام المهاجم طريقتين وهما المرفقات والروابط. قبل التحدث عن طرق الحماية يرجى ملاحظة أن الخطوات التالية قابلة للتطبيق على ما يعرف Email Gateway وهو الـ Server المسئول عن Email Traffic ونعيد التأكيد على ضرورة أن نفهم الـ Concept بغض النظر عن الـ Vendor لنكون قادرين على تطبيق ذلك في أي مكان و باستخدام أي Technology/Vendor


    لنبدأ بالمرفقات (Attachments)...فيما يلي الخطوات التي ينصح باتباعها:


    (Whitelisted File Extensions)قم بحماية المستخدمين من المرفقات التي تمثل تهديد لشبكتك مثل EXE/BAT/PS أو ما يعرف ب Executable Files. هناك طريقتان لذلك إما عن طريق Blacklist أو Whitelist. الأولى تعني تحديد قائمة سوداء من أنواع الملفات التي سيتم منعها والسماح لأي ملف من نوع آخر خارج القائمة من المرور والثانية تعني تحديد قائمة بيضاء من أنواع الملفات المسموح بمرورها وأي ملف من نوع آخر لن يسمح له بالمرور ونصيحة عامة في هذا المجال: دائما استخدم Whitelist وليس Blacklist وذلك لوجود العديد من الطرق للتحايل على Blacklist. نعم قد تكون Whitelist أصعب قليلا في التطبيق ولكن حتما هي الأقوى.

    كيف نطبق whitelist في حالتنا ؟ يمكننا السماح فقط لملفات doc و docx و pdf بالمرور وأي رسالة قادمة بهما مرفقات من نوع آخر يتم إيقافها تلقائيا (سواء كانت EXE أو غيرها). في الحقيقة ستكون Whitelist أكبر من هذا وتشمل أنواع أخرى من الملفات ولكن لماذا لم نذكر القائمة النهائية للسهولة؟ والإجابة لأنها تختلف من مؤسسة لأخرى حسب حجم المؤسسة وطبيعة عملها فلا يوجد ما يسمى (One That Fits All) وأنت وحدك من يمكنك بناء Whitelist الخاصة بك عن طريق عمل Monitoring للمرفقات الواردة إليك لمدة ما (شهر مثلا) وبناءا عليه يمكنك تحديد ما تود السماح له بالمرور ووضعه في Whitelist الخاصة بك ومنع أي ملف من نوع أخر غير موجود في القائمة.


    Screen Shot 2017-09-07 at 3.54.24 PM.png


    (Multiple AV Engines) استخدام أكثر من AntiVirus Engine علي Email Gateway يقوم بفحص المرفقات للتأكد من خلوها من الفيروسات ويفضل هنا استخدام Engine مختلف عن Engine الموجود على أجهزة المستخدمين. فمثلا إذا كانت المؤسسة تستخدم Kaspersky على Endpoints فيفضل استخدام نوع آخر مثل McAfee على Email Gateway فبذلك تزداد فرصة إيقاف الملفات الخبيثة فإذا نجح في تخطي McAfee الموجود على Email Gateway فقد يقوم Kaspersky الموجود على Endpoints بايقافه قبل إحداث الضرر وكما نعلم فإن خداع الـ AntiVirus من أسهل ما يكون.


    (Sandboxing) يجب أن ننتبه أن الخطورة لا تكمن فقط في ملفات EXE ولكن حتى ملفات doc و pdf يمكن استخدامها بطريقة خبيثة عن طريق Macros أو ثغرات في Microsoft Word و Adobe Reader يمكن استغلالها عن طريق Exploits لذلك فوجود Whitelist لا يعني حماية كاملة ومن هنا نشأت الحاجة لاستخدام ما يعرف Sandboxing solution وهو Server تكون وظيفته فحص الـ Attachments عن طريق تشغيلها في Virtual Environment لتحديد ما إذا كانت تقوم بأي نشاط خبيث أولا والسماح لها بالمرور فقط في حالة كونها غير خبيثة. مثال لـ Sandboxing Solution هو FireEye EX



    (Quarantine Encrypted Attachments) هناك حيلة يتبعها المهاجمون في محاولة لتخطي طبقات الحماية الموجودة على Email Gateway وهي وضع الـ Attachment في مجلد وضغط هذا المجلد وحمايته عن طريق Password بحيث يصبح الملف المرفق في النهاية Password Protected وبهذه الطريقة لن تتمكن Whitelist ولا AV Engines ولا Sandboxing من فحص المرفقات لأنها محمية بكلمة سر وعادة يقوم المهاجم بكتابة كلمة السر داخل محتوى Email ويطلب من المستخدم فك المجلد المضغوط فيتمكن هو من فتح وتشغيل المرفقات ولا تتمكن طبقات الحماية من تأدية مهامها باستثناء AV Engine الموجود على الجهاز الخاص بالمستخدم لأنه سيتمكن من فحص الملف بعدما قام المستخدم بفك الضغط. حل تلك النقطة يتمثل في منع الملفات المحمية ب Password سواء كانت مضغوطة أو لا (كملف doc محمي ب Password) وعدم السماح لها بالمرور إلا بعد فحصها يدويا (Manual Inspection).


    قبل الإنتقال إلى طرق الحماية من الروابط نود أن نذكر أنفسنا بمفهوم Defense in Depth أو ما يعرف ب Layered Security ومعناه عدم الإعتماد على Technique واحد في الحماية وإنما يجب أن يكون هناك طبقات متعددة من الحماية لإحتمالية نجاح المهاجم في تخطي طبقة معينة وبالتالي نضمن وجود طبقة أخرى بعدها توقف المهاجم وإلا وجد الباب مفتوحا على مصراعيه لإختراق الشبكة فبالنظر إلى الإجراءات السابقة إذا استطاع المهاجم مثلا تخطي Whitelist باستخدام Macro داخل ملف doc فهناك فرصة أن يقوم AV Engine الأول بمنعه وإذا تخطى الأول فقد ينجح AV Engine الثاني في إيقافه وإذا تمكن من تخطيهم جميعا فقد ينجح Sandboxing من إيقافه. قد يعتقد البعض أن هذا تعقيد زائد عن اللازم ولكن صدقونا حين نقول أنه في بعض الأوقات ستكون سعيدا جدا وشاكرا حين تكتشف أن أحد هذه الطبقات تمكن من صد هجمة ما قد تكلفك الملايين.


    نقطة أخرى شائعة وهي وجود انطباع خاطئ عند الكثير بضرورة توفر الكثير من الأموال لدى المؤسسة لشراء أحدث Security Solutions وأنه لا سبيل لتحقيق مستوى حماية متقدم إلا بهذا الأسلوب. للأسف هذا عذر غير مقبول….قطعا لابد من وجود Budget جيدة ولكن المهم أن نعلم أنها ليس العنصر الوحيد ويجب أن يكون هناك توازن فبقليل من الإبداع والمرونة وإمكانية استخدام Open Source Solutions يمكن تحقيق نتائج جيدة. هناك أمثلة عديدة لكبرى الشركات للاعتماد على Open Source فيما يتعلق بمجال Security


    بالعودة للشق الثاني وهو الروابط فالإجراءات قد تكون أيسر قليلا:


    (Defang URL) وهي خاصية موجودة في معظم Email Gateways وتقوم بتحويل أي رابط داخل Email من Clickable الى Non-Clickable. فمثلا قد يقوم المهاجم بوضع رابط داخل الـ Email كالأتي http://www.google.com فيظهر للمستخدم في البداية أن هذا الرابط سيقوده إلي google.com ولكن في الحقيقة سيذهب به إلى evil.com (يمكنك الضغط على الرابط لمشاهدة ذلك). وعليه تقوم خاصية Defang باستبدال http و https في اي رابط ب hxxp و hxxps وبالتالي إذا قام المستخدم بالضغط على الرابط لن يفتح معه ويضطر لعمل Copy / Paste ليقوم بفتح الرابط وبالتالي تفشل حيلة المهاجم في توجيه المستخدم إلى موقع غير الذي يراه.


    (URL Reputation) هي أيضا خاصية موجودة في معظم Email Gateways ويقوم فيها Email Gateway بتصنيف كل الروابط الموجودة في أي Email وتقييمها من 10 إلى -10 حيث تمثل 10 أعلى تقييم جيد وتمثل -10 أسوأ تقييم. تعتمد هذه التقييمات على قاعدة بيانات كبيرة بها تصنيف للروابط طبقا لعدة عوامل مثل انتشار الرابط ووجوده من عدمه في ما يعرف بـ Blacklist URLs إذا كان تم استخدامه في هجمات سابقة وغيره الكثير من العوامل الداخلة في التقييم. بناءا على ذلك يمكنك مثلا منع جميع الروابط التي يتراوح تقييمها بين -5 و -10 كما يمكنك اضافة Tag مثل [Suspected] للـ Subject الخاص بأي رسالة بها رابط يتراوح بين 0 و -5 وبذلك تكون قد حذرت المستخدم من الروابط بطريقة تلقائية لأنه سيجد كلمة Suspected في عنوان الرسالة وأخيرا يمكنك السماح للروابط من 0 إلى 10 بالمرور.


    نقطة مهمة هنا وهي بعض الروابط قد تأخذ تقييم 0 لأنها جديدة وغير موجودة بقاعدة البيانات الخاصة بالـ Email Gateway وذلك لا يعني بالضرورة أنها غير خبيثة لذلك فإن هذه الطريقة فعاليتها محدودة ولكن كما ذكرنا سابقا….Layered Security.


    بعد أن ناقشنا نظم الحماية التي يمكن تطبيقها فيما يتعلق بالـ Attachments و URLs بقي لنا أن نتعرض لأكثر النقاط أهمية وهي Email Spoofing وتكمن أهميتها في أنها أكثر طريقة يعتمد عليها المهاجمون في خداع المستخدمين واستدراجهم لفتح/تشغيل المرفقات أو الضغط على رابط ما لسرقة الـ Passwords. هذا هو ما سنتناوله بالتفصيل في الدرس القادم إن شاء الله.

    leadjam, samir and Naqshabndi like this.