ثغرة Zimbra CVE-2026-73570: رقّعت في يوليو؟ تحقّق إن كان أحد قد دخل قبلك

أصلحت Zimbra الثغرة CVE-2026-73570 في الإصدار 10.1.20 بتاريخ 20 يوليو 2026. تسمح الثغرة لأي شخص يستطيع إرسال بريد إلى خادم Zimbra بتشغيل أوامر shell عليه، دون تسجيل دخول ودون أي تفاعل من المستخدم، ما دامت حزمة zimbra-snmp الاختيارية مثبتة وإشعارات SNMP مفعّلة. وفي 30 سبتمبر نشرت Microsoft Threat Intelligence ما فعله المهاجمون بها: web shells، وصلاحيات root، ومفاتيح مصادقة مسروقة، وأرشيفات صناديق بريد، لدى مؤسسات في أكثر من منطقة وقطاع.

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

لماذا تهم تواريخ الترقيع هنا أكثر من المعتاد

بحسب Microsoft، فحصت أداتا مسح منفصلتان المسار المعيب بين 28 يوليو و7 أغسطس. أي بعد صدور الإصلاح في 20 يوليو وقبل الإفصاح العلني في 13 أغسطس. بمعنى آخر، كان المهاجمون يختبرون الخوادم بينما لم يكن لدى معظم المسؤولين سبب للاستعجال. والخادم الذي حصل على التحديث في أواخر أغسطس كان مكشوفًا في فترة كانت الثغرة تُستغل فيها.

كيف يعمل الهجوم، في فقرة واحدة

يراقب عفريت المراقبة في Zimbra، swatchdog، سجل البريد بحثًا عن أسطر «service status change»، وعند تفعيل إشعارات SNMP يرسل snmptrap عبر shell. أعادت Elastic Security Labs بناء السلسلة: يرسل المهاجم أمر SMTP بعنوان مشوّه، فيكتبه Postfix في /var/log/zimbra.log، وإن بدا النص كسطر حالة، يصل جزء اسم الخدمة إلى /bin/sh. والنتيجة تنفيذ شيفرة بصلاحيات المستخدم zimbra. ويحمل سجل الثغرة تقييمًا قدره 8.9 من الجهة المصدِرة.

الخطوة 1: رقّع، أو أزل المُحفِّز

1. رقِّ كل عقد Zimbra إلى 10.1.20 أو أحدث. تصف Microsoft وElastic ذلك بأنه الإصلاح الكامل الوحيد.
2. إن لم تستطع الترقية اليوم، فنصيحة Microsoft المؤقتة هي إزالة حزمة zimbra-snmp، وتعطيل إشعارات SNMP، وقصر الوصول إلى SNMP وSMTP على المضيفين الموثوقين.

لا تعتمد على اختبار استغلال سريع دليلًا على أنك آمن. وجدت Elastic أن عدة سكربتات إثبات مفهوم عامة تكتب حمولة لا يطابقها swatchdog أبدًا، فقد يجعل الاختبار الفاشل خادمًا معيبًا يبدو مرقّعًا. تحقّق من الإصدار المثبت بدلًا من ذلك.

الخطوة 2: ابحث عمّا تركه المهاجمون

هذه الفحوص مأخوذة مباشرة من السلوك الذي وصفته Microsoft. شغّلها على كل عقد صناديق البريد وعقد MTA، لا على العقدة المواجهة للإنترنت فقط، لأن المهاجمين تنقّلوا بين العقد باستخدام مفتاح SSH الخاص بـ Zimbra نفسه.

• Web shells. ابحث عن ملفات JSP لا تنتمي إلى إصدار Zimbra لديك في مجلدات تطبيقات الويب الخاصة بـ Jetty وmailboxd، بما فيها مجلدات عمل servlet. رصدت Microsoft عدة نسخ في كل خادم، ونسخًا على العقد المجاورة.
• صلاحيات sudo لحساب zimbra. شغّل sudo -l -U zimbra وابحث في /etc/sudoers و/etc/sudoers.d/ عن NOPASSWD: ALL. أنشأ المهاجمون هذا السطر تحديدًا بعد الاستيلاء مؤقتًا على ملكية /etc/pam.d/sudo، ثم أعادوا ملف PAM وأبقوا سطر sudoers.
• خدمة systemd مزيفة. تحقّق من وجود /etc/systemd/system/zimlog.service. يبدو الاسم جزءًا من Zimbra، لكن Microsoft وجدته مثبتًا يدويًا في مجلد systemd العام خارج مجلدات Zimbra، وقد غيّر المهاجمون طوابعه الزمنية لتطابق خدمات نظام أقدم، فلن يكشفه الترتيب حسب التاريخ.
• مهام cron وعمليات غريبة. راجع جداول cron للمستخدم zimbra ولـ root، وابحث عن أنبوب مسمّى في /tmp/s أو عملية openssl s_client مربوطة بـ shell، وهو ما رصدته Microsoft كـ reverse shell مشفّر.
• أدلة في السجلات. ابحث في /var/log/zimbra.log عن أسطر «Illegal address syntax» تحتوي $( أو علامات backtick أو نص «Service status change»، وفي سجلات الويب عن User-Agent باسم ZB73570 الذي استخدمته محاولات الفحص الأولى.

الخطوة 3: إن وجدت شيئًا، غيّر المفاتيح لا كلمات المرور فقط

تقول Microsoft إن المهاجمين استهدفوا أسرار Zimbra المركزية لا كلمات المرور الفردية. شغّلوا zmlocalconfig -s الذي يعرض بيانات اعتماد LDAP وMySQL وPostfix وAmavis والنسخ المتماثل، ثم استخدموا LDAP لسحب zimbraPreAuthKey وzimbraAuthTokenKey وzimbraTwoFactorAuthSecret. بمفتاح pre-auth أو مفتاح auth token يستطيع المهاجم الدخول بأي مستخدم دون معرفة كلمة مروره، لذا لا يكفي إعادة تعيين كلمات مرور المستخدمين وحدها. على خادم ثبت اختراقه، خطّط لما يلي:

1. غيّر بيانات اعتماد الخدمات التي يعرضها zmlocalconfig -s.
2. أعد توليد مفاتيح pre-auth لكل نطاق ومفتاح auth token، لكي تتوقف الرموز الموقّعة بالمفاتيح المسروقة عن العمل.
3. أعد تسجيل المصادقة الثنائية، فقد تكون الأسرار المشتركة نُسخت.
4. استبدل مفتاح SSH الخاص بـ zimbra في /opt/zimbra/.ssh/ على كل العقد.
5. اعتبر محتوى صناديق البريد مقروءًا. رصدت Microsoft إنشاء أرشيفات ونقلها إلى الخارج، وقد يترتب على ذلك واجب إبلاغ عن اختراق بحسب مكان عملك.

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

الدرس الأوسع للبريد المستضاف ذاتيًا

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

شهد الشهر نفسه تحديثات أمنية لـ Roundcube، وهو بريد ويب واسع الانتشار، منها حقن SQL قبل تسجيل الدخول يُستغل حاليًا: راجع Roundcube 1.6.20 و1.7.5.

الأسئلة الشائعة

المصادر: Microsoft Threat Intelligence (30 سبتمبر 2026)، وElastic Security Labs (23 أكتوبر 2026)، وNVD CVE-2026-73570.