إرهاق MFA واختطاف الجلسات: الهجمات التي تتجاوز التحقق الثنائي 2FA

فعّلتَ التحقق الثنائي 2FA وطمأنت مجلس الإدارة بأن الشركة محمية. الحقيقة أنها ليست كذلك. توقف المهاجمون عن مصارعة شاشة تسجيل الدخول لديك وبدأوا بالقفز فوقها. كلمة المرور ما زالت مهمة، لكن التقنيتين الأكثر نجاحاً اليوم، إرهاق MFA واختطاف الجلسات، تتعاملان مع عاملك الثاني على أنه مطب سرعة، لا جدار.

لماذا لم يعد 2FA كافياً

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

تحوّلان اثنان كسرا النموذج:

• الإنسان أُرهق. المصادقة القائمة على إشعارات push تطلب من شخص أن يضغط "موافقة". والناس يوافقون على أشياء طوال اليوم. تعلّم المهاجمون تحويل هذا الانعكاس الشرطي إلى سلاح.
• الجلسة أصبحت هي الغنيمة. بمجرد أن تُصادِق، يسلّم الخادم متصفحك رمز جلسة session token. هذا الرمز، لا كلمة مرورك، هو ما يثبت هويتك في كل طلب يلي تسجيل الدخول. اسرق الرمز وستتجاوز كلمة المرور وطلب MFA وكل شيء.

الهجومان يشتركان في سبب جذري واحد: المصادقة حدث، أما الوصول فحالة مستمرة. نحن ننفق بسخاء على الحدث ولا ننفق شيئاً تقريباً على الحالة التي تعيش بعده ساعات أو أياماً. ومع تسارع التحول الرقمي للشركات في تونس والمنطقة، من البنوك إلى منصات الدفع والتجارة الإلكترونية، أصبح الحساب السحابي هو المقر الفعلي للشركة، وأصبحت الجلسة المسروقة تعادل مفتاح ذلك المقر. إذا أردت النسخة الأعمق من هذه الحجة، اقرأ طرحنا حول بنية انعدام الثقة Zero Trust. الخلاصة المختصرة: لا تثق أبداً بجلسة لمجرد أن تسجيل دخول واحداً نجح يوماً ما.

إرهاق MFA، أو ما يُعرف بقصف الإشعارات push bombing

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

في النهاية يحدث أحد ثلاثة أمور:

1. يضغط المستخدم "موافقة" ليُسكت الضجيج.
2. يفترض المستخدم أن قسم تقنية المعلومات يجري صيانة فيوافق.
3. يتصل المهاجم منتحلاً صفة الدعم الفني، أو يراسل الموظف على WhatsApp بالطريقة نفسها التي يتواصل بها فريق الدعم فعلاً في كثير من شركاتنا، ويقوده خطوة بخطوة نحو الموافقة.

هذا هو الهجوم بأكمله. لا ثغرة يوم صفري ولا برمجية خبيثة. إنه ينجح لأن إشعار "موافقة / رفض" المجرد لا يحمل أي سياق، والموافقة عليه لا تكلّف المستخدم شيئاً.

إصلاحات تغيّر المعادلة فعلاً

• مطابقة الأرقام number matching. تعرض شاشة تسجيل الدخول رقماً من خانتين يجب على المستخدم إدخاله في التطبيق. المهاجم الذي لا يرى شاشة تسجيل الدخول لا يستطيع توفير الرقم. هذا وحده يقتل مسار الموافقة العمياء.
• سياق داخل الإشعار. اعرض الموقع الجغرافي والتطبيق وعنوان الـ IP. عبارة "تسجيل دخول من لاغوس إلى تطبيق الرواتب لديك" أصعب بكثير من أن تُقبل بضغطة عابرة مقارنة بزر موافقة فارغ.
• تحديد المعدل والقفل عند تكرار الإشعارات. ثلاثة إشعارات مرفوضة أو متجاهَلة خلال نافذة قصيرة يجب أن تجمّد الإشعارات الجديدة وتنبّه فريق الـ SOC لديك. قصف الإشعارات صاخب بطبيعته، فاكشف الحجم.
• التخلي عن push كلياً للحسابات عالية القيمة. مطابقة الأرقام رقعة إصلاح، أما العوامل المقاوِمة للتصيد فهي العلاج (التفاصيل أدناه).

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

اختطاف الجلسات: سرقة الرمز وتجاوز تسجيل الدخول

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

هناك ثلاثة مسارات شائعة نحو الرمز.

1. تصيد الخصم في المنتصف AiTM

هذه هي التقنية الكامنة وراء معظم عمليات تجاوز MFA الحديثة. يشغّل المهاجم وكيلاً عكسياً reverse proxy (عدد من العُدد الجاهزة مثل Evilginx جعلت الأمر متاحاً بنقرات معدودة) بين الضحية والموقع الحقيقي.

سير الهجوم:

1. تنقر الضحية على رابط تصيد، وصلنا كثير منها اليوم عبر WhatsApp أو رسائل SMS لا عبر البريد فقط، فتهبط على وكيل المهاجم الذي يبدو مطابقاً تماماً للموقع لأنه يمرّر الموقع الحقيقي حرفياً.
2. تكتب الضحية كلمة المرور، فيمررها الوكيل إلى الموقع الحقيقي.
3. يرسل الموقع الحقيقي طلب MFA، فتكمله الضحية. مطابقة الأرقام أو TOTP أو SMS: كلها تتحقق، لأن إنساناً حقيقياً يسجّل الدخول فعلاً.
4. يُصدر الموقع الحقيقي ملف تعريف ارتباط جلسة صالحاً، فيلتقطه الوكيل أثناء العبور.
5. يستورد المهاجم ملف تعريف الارتباط في متصفحه الخاص، وها هو في الداخل، مُصادَقاً بالكامل، وقد استوفى MFA سلفاً.

الضحية فعلت كل شيء بشكل صحيح وخسرت رغم ذلك. لهذا السبب فإن "لدينا MFA" ليست إجابة عن سؤال "هل نحن مقاومون للتصيد؟".

2. برمجيات infostealer وسرقة ملفات تعريف الارتباط

لا حاجة إلى وكيل إذا كنت تستطيع قراءة قرص الضحية. برمجيات infostealer (مثل RedLine وLumma وبقية هذا السوق) تلتقط مخازن ملفات تعريف الارتباط في المتصفح والرموز المحفوظة وملفات الجلسات المحلية، ثم تُباع الغنيمة. يحمّل المشتري جلستك الحية ويدخل مباشرة. لا طلب كلمة مرور ولا MFA، لأن الرمز مسكوك سلفاً.

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

3. سرقة الرموز في تدفقات OAuth والـ API

رموز refresh token طويلة العمر وتطبيقات OAuth سيئة الضبط منجم ذهب صامت. رمز refresh مسروق يمكنه سكّ رموز access جديدة لأسابيع. والرموز مفرطة الصلاحيات تحوّل تسريباً واحداً إلى وصول شامل للمستأجر بأكمله. إذا كانت منصتك تُصدر رموزاً لتكاملات طرف ثالث، فكل واحد منها اعتماد قد لا تقوم بتدويره أصلاً. نتعمق في النطاقات والتدوير في أفضل ممارسات أمن الـ API.

الدفاع الذي يصمد فعلاً: MFA المقاوِم للتصيد

إليك الحقيقة غير المريحة. مطابقة الأرقام تنفع ضد الإرهاق، لكنها لا تفعل شيئاً ضد AiTM، لأن الإنسان لا يزال يسلّم اعتماداً حقيقياً إلى موقع حقيقي عبر وكيل. لهزيمة AiTM تحتاج إلى عامل مربوط بالأصل origin لا يمكن تمريره عبر وسيط.

هذا العامل هو FIDO2 / WebAuthn، في صورة مفاتيح مرور passkeys أو مفاتيح أمان عتادية.

لماذا يقاوم AiTM: المُصادِق يوقّع تحدياً يتضمن الأصل (النطاق الحقيقي). الوكيل المستضاف على نطاق مقلَّد يُنتج أصلاً خاطئاً، فلا يصح التوقيع. لا يوجد رمز يمكن تصيده، ولا ملف تعريف ارتباط يمكن خداع الإنسان لتمريره. التشفير ببساطة يرفض العمل خارج النطاق الشرعي.

إن كنت ستقرأ مقالاً مرافقاً واحداً فليكن مفاتيح المرور passkeys والمصادقة بلا كلمات مرور. بالنسبة للمسؤولين وفرق المالية وكل من يملك وصولاً إلى بيئة الإنتاج، يجب أن يكون MFA المقاوِم للتصيد إلزامياً لا اختيارياً.

Priority order for MFA strength:
  1. FIDO2 / passkeys / hardware keys   (phishing-resistant, beats AiTM)
  2. Number-matched push + context      (beats fatigue, not AiTM)
  3. TOTP authenticator apps            (phishable via proxy)
  4. SMS / voice OTP                     (phishable + SIM-swap risk)

لا تنشر المستوى الأعلى وحده على الجميع دفعة واحدة. انشره أولاً للحسابات التي سيُنهي اختراقها ربعك المالي. ولاحظ أن رموز SMS التي لا تزال بنوك وخدمات كثيرة في المنطقة تعتمد عليها تقبع في أسفل السلم، مع خطر إضافي هو الـ SIM-swap.

حماية الجلسة نفسها

الـ MFA المقاوِم للتصيد يحمي تسجيل الدخول. يبقى عليك حماية الرمز بعد إصداره، لأن البرمجيات الخبيثة وأخطاء الضبط يمكنها التقاطه مباشرة.

اربط الرمز بالجهاز

أقوى ضابط هو ربط الرمز token binding: اربط الجلسة تشفيرياً بالجهاز الذي صادَق، بحيث يصبح ملف تعريف الارتباط المسروق عديم الفائدة على أي جهاز آخر. آليتان يجب أن تعرفهما:

• DPoP (إثبات الحيازة Demonstrating Proof of Possession) لتدفقات OAuth. العميل يثبت حيازته مفتاحاً خاصاً في كل طلب. الرمز المنسوخ بلا مفتاح ميت عند الوصول.

POST /api/orders HTTP/1.1
Authorization: DPoP eyJ...access_token...
DPoP: eyJ...signed_proof_bound_to_request_and_key...

• الجلسات المربوطة بالجهاز في طبقة المتصفح. معايير ناشئة (تُسوَّق غالباً باسم device bound session credentials) تجدّد ملفات تعريف الارتباط باستخدام مفتاح محفوظ على الجهاز، بحيث تنتهي صلاحية أي ملف مُسرَّب بسرعة ولا يمكن إعادة استخدامه في مكان آخر.

حصّن ملفات تعريف الارتباط بالطريقة المملة

معظم سرقات الجلسات تستغل تعاملاً متراخياً مع ملفات تعريف الارتباط. الإعدادات الافتراضية مهمة:

Set-Cookie: session=...;
  HttpOnly;          // لا يستطيع JavaScript قراءته، يكسر السرقة عبر XSS
  Secure;            // لا يُرسل أبداً عبر HTTP غير المشفر
  SameSite=Lax;      // يقيّد الإرسال عبر المواقع، يقلّص CSRF
  Path=/;
  Max-Age=3600       // عمر قصير، نطاق ضرر صغير

خاصية HttpOnly وحدها توقف فئة واسعة من تهريب ملفات تعريف الارتباط عبر ثغرات XSS. إذا كان ملف تعريف ارتباط جلستك قابلاً للقراءة من JavaScript، فأصلح هذا قبل أي شيء آخر في هذه الصفحة.

قلّص ما يمكن أن يفعله رمز مسروق

• أعمار قصيرة لرموز access. دقائق لا ساعات. افرض إعادة التحقق المتكررة.
• تدوير رموز refresh مع كشف إعادة الاستخدام. كل عملية تجديد تُصدر رمزاً جديداً وتُبطل القديم. إذا عاد رمز قديم إلى الظهور فتلك سرقة: اقتل عائلة الجلسات بأكملها.
• نطاق مقيّد لكل رمز. أقل الصلاحيات لكل رمز. الرمز المُسرَّب للقراءة فقط حادثة. أما الرمز المُسرَّب بصلاحيات مطلقة فهو اختراق كامل.

اكشف الاختطاف الذي لم تستطع منعه

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

• التقييم المستمر للوصول CAE (Continuous Access Evaluation). بدلاً من الوثوق بالرمز حتى انتهاء صلاحيته، أعد فحص الشروط في زمن شبه حقيقي. إعادة تعيين كلمة مرور، أو تعطيل حساب، أو موقع مشبوه: اسحب الجلسة في منتصفها، لا في الساعة التالية.
• السفر المستحيل وشذوذ الأجهزة. جلسة في سوسة الساعة 14:00 وأخرى في مانيلا الساعة 14:10 ليستا لموظف في طريقه إلى العمل. علّمها، أو اطلب تحققاً إضافياً، أو اقتلها.
• انحراف الـ user agent والـ IP داخل الجلسة الواحدة. الرمز الذي يقفز من بصمة حاسوب الشركة المحمول إلى خادم سحابي عشوائي رمز مسروق. أطلق تنبيهاً عند هذا التحول.
• سجّل دورة حياة الجلسة، لا تسجيلات الدخول فقط. إصدار الرموز وتجديدها وسحبها كلها تنتمي إلى قياساتك التشغيلية. لا يمكنك التحقيق فيما لم تسجّله أصلاً. اقرن هذا بالصورة الأشمل في قابلية الملاحظة: السجلات والمقاييس والتتبعات.

عندما ينطلق تنبيه، تحتاج إلى استجابة متمرَّن عليها: اسحب الجلسات، ودوّر الرموز، وافرض إعادة تسجيل مقاوِمة للتصيد. اكتب هذا كله قبل أن تحتاجه. يغطي دليل الاستجابة للحوادث لدينا خطوات سحب الرموز التي تنساها معظم الفرق حتى الثالثة فجراً.

إطار قرارات يمكنك تطبيقه هذا الربع

لا يمكنك فعل كل شيء دفعة واحدة. رتّب الأولويات حسب نطاق الضرر.

1. اجرد الوصول المتميز. المسؤولون والمالية وبيئة الإنتاج وكل من يستطيع تحريك أموال أو بيانات. هذه هي فئتك الأولى.
2. افرض MFA المقاوِم للتصيد على الفئة الأولى. مفاتيح مرور passkeys أو مفاتيح عتادية. بلا استثناءات، وبلا خيار احتياطي عبر TOTP لهذه الحسابات.
3. فعّل مطابقة الأرقام وسياق الإشعار لبقية المستخدمين. هذه رقعتك ضد الإرهاق للشريحة الواسعة.
4. اجعل نظافة ملفات تعريف الارتباط والرموز سياسة رسمية. HttpOnly وSecure وSameSite وأعمار قصيرة وتدوير refresh مع كشف إعادة الاستخدام. تحقق منها في مراجعة الكود، لا في صفحة wiki.
5. فعّل CAE وكشف شذوذ الجلسات. توقف عن الوثوق بالرموز طوال عمرها الكامل.
6. تمرّن على السحب. نفّذ تمريناً نظرياً يُفترض فيه أن رمزاً سُرق. قِس الوقت اللازم لقتل كل الجلسات. إذا كنت لا تعرف هذا الرقم، فالرقم نفسه هو الثغرة.

النمط واضح: امنع ما تستطيع منعه بالتشفير، واحتوِ ما لا تستطيع بجلسات قصيرة العمر ومربوطة وقابلة للسحب.

قائمة تدقيق ذاتي سريعة

• الحسابات ذات الصلاحيات تستخدم FIDO2 / passkeys، لا push ولا TOTP.
• مطابقة الأرقام وسياق تسجيل الدخول مفعّلان لكل المستخدمين.
• ملفات تعريف ارتباط الجلسات تحمل HttpOnly وSecure وSameSite.
• رموز access تنتهي خلال دقائق، ورموز refresh تخضع للتدوير.
• إعادة استخدام رمز refresh تُطلق سحباً كاملاً للجلسات.
• ربط الرموز (DPoP أو جلسات مربوطة بالجهاز) مطبَّق على الـ API الحساسة.
• CAE أو ما يعادله يسحب الجلسات عند أحداث الخطر في منتصفها.
• إصدار الجلسات وتجديدها وسحبها مسجَّلة وقابلة للتنبيه.
• أجريتَ تمرين سحب جلسات حياً وموقوتاً خلال آخر 90 يوماً.

إذا أردت أن تعرف كيف تصمد هذه الضوابط أمام مهاجم حقيقي، فهذا بالضبط ما يختبره تكليف احترافي. راجع مدخل إلى اختبار الاختراق لترى كيف يُنفَّذ سيناريو AiTM وسرقة الرموز من البداية إلى النهاية.

كيف تساعدك Innovation T

نحن نبني ونحصّن طبقة المصادقة التي تشحنها الفرق فعلاً: نشر مفاتيح المرور passkeys، وMFA مقاوِم للتصيد للوصول المتميز، وربط الرموز، وتدوير رموز refresh، وكشف شذوذ الجلسات موصولاً بسجلاتك. لا عروض تقديمية، بل ضوابط عاملة، مختبَرة ضد الهجمات نفسها المذكورة أعلاه.

إذا كان نظام 2FA لديك على بُعد وكيل مقنع واحد من استيلاء كامل على الجلسات، فدعنا نختبره تحت الضغط ونغلق الفجوة. اطّلع على خدماتنا أو تواصل مع الفريق وسنرسم لك أقصر طريق من "لدينا MFA" إلى "نحن مقاومون للتصيد".