
ثغرة توليد IV غير آمن في خوارزمية AES-CFB في تطبيق Reolink لسطح المكتب
يستخدم تطبيق Reolink لسطح المكتب (الإصدار 8.18.12) خوارزمية AES-CFB لتشفير ملفات الإعدادات وغيرها من البيانات الحساسة.
ومع ذلك، فإن ناقل التهيئة (IV) المستخدم في هذه العملية يتم التعامل معه بشكل غير صحيح، مما يؤدي إلى ثغرة يمكن من خلالها للمهاجم فك تشفير بيانات الإعدادات المشفرة بسهولة.
يُظهر الكود التالي أن ناقل التهيئة (IV) يتم توليده ديناميكيًا في وقت التشغيل:
{
key: "fetchAesIv",
value: function () {
return window.napiDecrypt.getAesIv();
},
}
ومع ذلك، فإن القيمة التي يتم إرجاعها هي دائمًا نفس السلسلة النصية: bcswebapp1234567.
هذا يعني أنه على الرغم من أن ناقل التهيئة (IV) يتم توليده تقنيًا في وقت التشغيل، إلا أنه في الواقع مضمّن بشكل ثابت، ولا يوفر أي أمان إضافي.
أثناء تشغيل التطبيق، يمكن استرداد قيمة ناقل التهيئة (IV) ديناميكيًا عبر وحدة تحكم JavaScript في أدوات المطور (DevTools).
تُرجع الدالة window.napiDecrypt.getAesIv() وعدًا (Promise) يتم حله إلى سلسلة نصية ثابتة bcswebapp1234567.

يوضح هذا أن ناقل التهيئة (IV) يُعاد استخدامه في جميع عمليات التشفير، مما ينتهك أفضل الممارسات في مجال التشفير.
في أوضاع تشفير الكتل مثل CFB وCBC وOFB، يمكن أن تسمح إعادة استخدام ناقل التهيئة (IV) للمهاجم بالتنبؤ بأنماط النص المشفر، مما يعرض سرية البيانات للخطر في النهاية. لتحقيق الغرض من ناقل التهيئة (IV)، يجب توليد قيمة جديدة غير قابلة للتنبؤ بشكل ديناميكي.