مقدمة
في 3 سبتمبر 2026، أصدرت MikroTik تصحيحات تقريبًا في نفس الوقت لعدة فروع من RouterOS المدعومة: 7.25beta3، 7.24.2، 7.23.4، و6.49.21، وأوصت بتثبيت نسخة مصححة في أقرب وقت ممكن. وصف البائع الإصدار بأنه تحديث أمني مهم لكنه احتفظ مؤقتًا بتفاصيل الثغرات لإعطاء المسؤولين الوقت لتحديث أجهزتهم.
بعض الإصلاحات عالجت ثغرات اكتشفها سلاومير روزبيكي من CERT Polska، والتي تم الإبلاغ عنها للبائع من خلال الكشف المنسق عن الثغرات (CVD). كنا نخطط لمزامنة نشر تفاصيلها مع إصدار التحديثات، لكن النسخ الجديدة أُصدرت قبل أن نتوقع. استخدم البائع أيضًا إشعارات الدفع في تطبيق MikroTik لتأكيد الحاجة إلى الترقية.
أدى إلحاح الإعلان ونقص المعلومات المحددة حول التهديدات إلى تكهنات واسعة في منتدى MikroTik الرسمي. في الوقت نفسه، بدأ المستخدمون في نشر سجلات الأجهزة مما يشير إلى أن الهجمات قد بدأت قبل أن تصبح التصحيحات متاحة.
تحديد CVE-2026-86060
عندما أصبحت النسخ الجديدة من RouterOS متاحة، بدأنا في تحليل التصحيحات لتحديد ما إذا كان البائع قد أصلح الثغرات التي أبلغنا عنها. احتوت الحزم أيضًا على تغييرات في الآليات التي لم تشملها تقاريرنا.
تحققت النسخ المصححة من RouterOS من اسم المستخدم قبل تمريره إلى تطبيق /nova/bin/login. اقترح نطاق هذا التحقق أنه، قبل التصحيح، كان يمكن أن يؤثر اسم المستخدم على كيفية تفسير البرنامج لوسائطه. كانت الوظيفة المعاد تجميعها تبدو كما يلي:
تمت إضافة التحقق من اسم المستخدم. الشرط المميز يرفض أسماء المستخدمين التي تبدأ بشرطة (0x2d) أو فراغ (0x20).
حددنا أيضًا تغييرات في آلية Flagged، التي تكشف عن إدخالات التكوين التي قد تشير إلى اختراق. كانت هناك قاعدة جديدة تتحقق عند بدء التشغيل من وجود حساب ops ينتمي إلى المجموعة الكاملة المميزة. إذا تم استيفاء الشرط، قام RouterOS بتعطيل الحساب، وتسجيل تحذير، وتعيين حالة Flagged. قد يعني إدخال مثل هذه المؤشرات المحددة للاختراق (IoCs) أن البائع كان لديه على الأقل معرفة جزئية بالهجمات.
ثم فحصنا السجلات التي نشرها المسؤولون على منتدى MikroTik وReddit. ظهرت مدخلات مميزة في عدة تقارير:
فشل تسجيل الدخول للمستخدم -2 من 82.192.72.4 عبر ssh
تمت إضافة المستخدم ops بواسطة ssh:-2@82.192.72.4
لاحظنا تسلسلًا متناقضًا على ما يبدو في هذه السجلات: محاولة تسجيل دخول فاشلة للمستخدم -2، تليها إنشاء حساب ops ضمن نفس الجلسة.
سمح دمج هذه المعلومات مع نتائج تحليل التصحيحات لنا بتحديد ثغرة حرجة جديدة في غضون ساعة، وتعيين معرف CVE-2026-86060 لها، وتقديم التفاصيل للبائع مع نص برمجي يعمل كدليل إثبات.
بالإضافة إلى CVE-2026-67279، سمحت الثغرة للمهاجم بالحصول على امتيازات إدارية كاملة دون معرفة كلمة مرور، أو امتلاك مفتاح SSH، أو إكمال المصادقة. أطلقنا على هذه السلسلة اسم MikroTrick.
CVE-2026-67279
يوفر SSH عدة قدرات إدارية، بما في ذلك الوصول إلى الطرفية عن بُعد، وتنفيذ الأوامر، ونقل الملفات، ونفق الاتصال ضمن قناة اتصال مشفرة. يتكون البروتوكول من ثلاث طبقات متتالية:
النقل،
مصادقة المستخدم،
إدارة الاتصال والقناة.
بعد إنشاء اتصال TCP، يتفاوض العميل والخادم على الخوارزميات التشفيرية ويقومون بتبادل المفاتيح لإنشاء سر مشترك. يقوم الخادم بتوقيع معلمات التبادل بمفتاح المضيف الخاص به، مما يسمح للعميل بالتحقق من هوية الخادم. عند الاتصال للمرة الأولى، يتبع العملاء غالبًا نموذج الثقة عند الاستخدام الأول (TOFU). ثم يستمد كلا الجانبين مادة المفتاح للتواصل الإضافي من السر المشترك. من تلك النقطة، يتم تشفير اتصالاتهم وحمايتها ضد التعديل. هذه المرحلة تصادق على الخادم للعميل، ولكن ليس بعد على المستخدم للخادم.
ثم يقوم العميل بمصادقة المستخدم باستخدام واحدة من الطرق المسموح بها، مثل كلمة المرور أو المفتاح العام. إذا نجحت المصادقة، يرسل الخادم SSH_MSG_USERAUTH_SUCCESS. فقط بعد ذلك تبدأ إدارة القناة، مما يسمح للعميل بالوصول إلى قشرة، وتنفيذ أمر، أو استخدام وظائف إدارية أخرى وفقًا للامتيازات المخصصة لمستخدم SSH. يتم تحديد هذا التقسيم في RFC 4253، RFC 4252، وRFC 4254.
بعد تبادل المفتاح الأولي، يمكن لأي من الجانبين بدء تبادل آخر، يعرف باسم إعادة المفتاح. هذا يغير مفاتيح النقل دون إنهاء اتصال TCP أو تغيير حالة البروتوكولات ذات الطبقات العليا. عادةً ما تحدث إعادة المفتاح بعد نقل كمية محددة من البيانات أو مرور فترة زمنية معينة، لكن البروتوكول يسمح أيضًا بذلك قبل اكتمال مصادقة المستخدم.
تعاملت النسخ الضعيفة من خادم SSH في RouterOS مع إعادة المفتاح التي بدأت أثناء مصادقة المستخدم بشكل غير صحيح. عندما انتهت إعادة المفتاح، انتقل الخادم بلا شروط من حالة إعادة المفتاح المؤقتة إلى إدارة القناة بدلاً من استئناف المصادقة المقطوعة. ونتيجة لذلك، قبلت قناة الجلسة والطلبات المرتبطة بها على الرغم من أنها لم ترسل أبدًا SSH_MSG_USERAUTH_SUCCESS.
لم تؤسس الثغرة هوية مصدقة أو تعين أي امتيازات. ومع ذلك، سمحت للاتصال بالانتقال من مصادقة المستخدم إلى إدارة القناة، وهو ما كان شرطًا مسبقًا لاستغلال CVE-2026-86060.
CVE-2026-86060
بعد المصادقة الناجحة، يمكن للعميل فتح قناة جلسة. يسمح استغلال CVE-2026-67279 بتجاوز هذا الشرط. لإنشاء وحدة تحكم عن بُعد، يرسل العميل عادةً pty-req متبوعًا بـ shell. يقوم الخادم بإنشاء طرفية زائفة ويبدأ عملية فرعية مرتبطة بها. في RouterOS، تكون هذه العملية هي /nova/bin/login، التي يتم استدعاؤها وفقًا للنمط التالي:
/nova/bin/login -ssh -trace <trace> -h <client address> [-c <command>] <username> <policy mask>
خلال التشغيل العادي، آخر t