شرح هجوم CBC Bit Flipping

التشفير لا يعني أن بياناتك آمنة من التلاعب.

يرتكب العديد من المطورين هذا الخطأ؛ حيث يعتقدون أنه إذا لم يتمكن المهاجم من قراءة البيانات، فلن يتمكن من تغييرها. هذا خطأ، فالتشفير يعالج السرية والنزاهة كمهمتين مختلفتين.

يثبت هجوم CBC Bit Flipping ذلك. يمكن للمهاجم تغيير بياناتك دون معرفة مفتاحك السري.

إليك كيفية عمل ذلك:

لا يقوم AES بتشفير البيانات كقطعة واحدة كبيرة، بل يقسمها إلى كتل (blocks) بحجم 16 بايت. في وضع CBC، ترتبط هذه الكتل معًا في سلسلة، حيث يتم دمج المخرجات المشفرة للكتلة الأولى مع النص الصريح (plaintext) للكتلة الثانية.

تخلق هذه السلسلة نقطة ضعف أثناء عملية فك التشفير. فمن أجل الحصول على النص الأصلي للكتلة 2، يقوم الخادم بفك تشفيرها ودمجها مع النص المشفر (ciphertext) من الكتلة 1.

يمكن للمهاجم استغلال ذلك:

لا يحتاج المهاجم إلى قراءة الرسالة، بل يكتفي بقلب البتات لتغيير النتيجة النهائية.

لننظر في تطبيق ويب قديم يستخدم ملفات تعريف الارتباط (cookies) المشفرة للجلسات. قد يحتوي ملف تعريف الارتباط على: userid=994;role=user;

يعترض المهاجم ملف تعريف الارتباط هذا ويقوم بقلب البتات في النص المشفر. يرسل العديد من الطلبات حتى يقبل الخادم أحدها. ولأن الخادم يتحقق فقط مما إذا كانت البيانات قابلة لفك التشفير، فإنه يعالج النص المعدل. وفجأة، يصبح النص المفكوك تشفيره: userid=994;role=admi;

أصبح لدى المهاجم الآن صلاحيات المسؤول (admin). لم يقرأ المفتاح أو ملف تعريف الارتباط الأصلي أبدًا.

الخطأ هو افتراض أن التشفير يضمن النزاهة.

لإصلاح ذلك، استخدم التشفير الموثق (Authenticated Encryption) مثل AES-GCM. فهو ينشئ علامة تشفير (cryptographic tag) تعمل مثل الختم. إذا قام المهاجم بتغيير بت واحد فقط، سينكسر الختم، وسيرفض الخادم البيانات فورًا.

إذا كان لابد من استخدام CBC، فاستخدم بنية Encrypt-then-MAC. قم بإنشاء رمز مصادقة للنص المشفر وتحقق منه قبل البدء في فك التشفير.

البيانات السرية ليست دائمًا بيانات موثوقة. أثبت دائمًا أن بياناتك لم تتغير قبل استخدامها لاتخاذ القرارات.

شرح هجوم قلب البتات في نمط CBC: لماذا لا يضمن التشفير وحده سلامة البيانات

عندما نتحدث عن التشفير، فإن الهدف الأساسي عادة ما يكون السرية (Confidentiality) — أي ضمان ألا يتمكن أحد من قراءة البيانات ما لم يكن لديه المفتاح الصحيح. ولكن هناك مفهوم آخر لا يقل أهمية وهو سلامة البيانات (Integrity) — أي ضمان أن البيانات لم يتم تعديلها أو التلاعب بها أثناء انتقالها.

الخطأ الشائع هو الاعتقاد بأن التشفير القوي يحمي البيانات من التلاعب. في هذا المقال، سنشرح لماذا لا يضمن نمط Cipher Block Chaining (CBC) سلامة البيانات، وكيف يمكن للمهاجمين استغلال ذلك عبر "هجوم قلب البتات" (Bit-Flipping Attack).

ما هو نمط CBC؟

في نمط تشفير CBC، يتم ربط كل كتلة من النص الصريح (Plaintext) بالكتلة المشفرة (Ciphertext) السابقة قبل تشفيرها. تعمل هذه العملية باستخدام عملية XOR المنطقية.

إليك كيفية عمل عملية فك التشفير في نمط CBC:

$$P_i = D_k(C_i) \oplus C_{i-1}$$

حيث أن:

(ملاحظة: بالنسبة للكتلة الأولى، يتم استخدام متجه التهيئة Initialization Vector (IV) بدلاً من $C_{i-1}$).

كيف يعمل هجوم قلب البتات (Bit-Flipping Attack)؟

تكمن المشكلة في المعادلة أعلاه. لاحظ أن النص الصريح $P_i$ يعتمد بشكل مباشر على الكتلة المشفرة السابقة $C_{i-1}$ عبر عملية XOR.

إذا تمكن المهاجم من اعتراض النص المشفر وتعديل بت (bit) معين في الكتلة $C_{i-1}$، فإن هذا التعديل سيؤدي مباشرة إلى تغيير نفس البت في الكتلة النص الصريح $P_i$ عند فك التشفير.

الخطوات:

  1. المهاجم لا يحتاج إلى معرفة المفتاح لفك التشفير.
  2. المهاجم يحدد موقع البت الذي يريد تغييره في الكتلة المشفرة $C_{i-1}$.
  3. يقوم المهاجم بقلب ذلك البت (من 0 إلى 1 أو العكس).
  4. عند فك تشفير الكتلة $C_i$ بواسطة المستلم، سيظهر النص الصريح $P_i$ مع البت المعدل.

ملاحظة هامة: التلاعب بـ $C_{i-1}$ سيؤدي إلى جعل الكتلة $P_{i-1}$ غير قابلة للقراءة (تلف في البيانات)، ولكن الكتلة $P_i$ ستتغير بدقة كما أراد المهاجم.

مثال عملي

تخيل أن لدينا رسالة مشفرة تحتوي على بيانات المستخدم التالية: role=user;id=123

لنفترض أن هذه البيانات تقع ضمن كتلة نص صريح $P_i$. إذا أراد المهاجم تغيير الصلاحية من user إلى root في الكتلة التالية $P_{i+1}$، فإنه سيقوم بتعديل الكتلة المشفرة $C_i$ المقابلة.

بما أن المهاجم يعرف النص الصريح الأصلي (user) والنص المشفر المقابل له، يمكنه حساب التعديل المطلوب في $C_i$ بحيث يؤدي عند عملية XOR مع $D_k(C_{i+1})$ إلى إنتاج كلمة root.

كيف تحمي نفسك؟

لحل هذه المشكلة، لا يكفي استخدام التشفير وحده؛ يجب استخدام التشفير الموثق (Authenticated Encryption). هناك طريقتان رئيسيتان:

1. استخدام MAC (Message Authentication Code)

يمكنك استخدام نمط Encrypt-then-MAC. في هذا النمط، تقوم بتشفير البيانات أولاً، ثم تقوم بإنشاء رمز مصادقة (مثل HMAC) باستخدام مفتاح مختلف وتلحقه بالنص المشفر. عند فك التشفير، يتحقق المستلم من صحة الرمز أولاً؛ إذا تم التلاعب بأي بت في النص المشفر، سيفشل التحقق ولن يتم فك التشفير.

2. استخدام أنماط AEAD

تعتبر أنماط AEAD (Authenticated Encryption with Associated Data) هي المعيار الحديث والأفضل. هذه الأنماط تدمج السرية والمصادقة في عملية واحدة.

الخلاصة