أمان جاد: تم الهجوم على Microsoft Office 365 بسبب ضعف التشفير

لسنا متأكدين تمامًا مما نسميه الآن ، لذلك أشرنا إليه في العنوان بالاسم المختلط مايكروسوفت أوفيس 365.

(يتم الآن استخدام اسم "Office" باعتباره الاسم الجماعي لتطبيقات معالجة النصوص وجداول البيانات والعرض التقديمي والتعاون في Microsoft قضي على خلال الشهر أو الشهرين المقبلين ، ليصبح ببساطة "Microsoft 365".)

نحن على يقين من أن الأشخاص سيستمرون في استخدام أسماء التطبيقات الفردية (كلمة, Excel, باور بوينت والأصدقاء) ولقب الجناح Office لسنوات عديدة ، على الرغم من أن الوافدين الجدد على البرنامج ربما ينتهي بهم الأمر بمعرفته على أنه 365، بعد حذف بادئة Microsoft في كل مكان.

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

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

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

بالطبع ، إذا قمت بتضمين كلمة المرور في نص البريد الإلكتروني ، فلن تكسب شيئًا ، ولكن إذا كنت حذرًا قليلاً بشأن مشاركة كلمة المرور عبر قناة مختلفة ، فقد اشتريت لنفسك بعض الأمان والأمان الإضافي ضد المحتالين و snoops و ne'er-do-wells للوصول بسهولة إلى المحتوى السري.

OME تحت دائرة الضوء

او هل انت

وفقًا الباحثين في شركة الأمن السيبراني الفنلندية WithSecure ، يمكن أن تتمتع بياناتك بحماية أقل بكثير قد تتوقعها بشكل معقول.

الميزة التي استخدمها المختبرين هي ما يشيرون إليه تشفير الرسائل في Office 365الطرق أو OME لفترة قصيرة.

لم نقم بإعادة إنتاج تجاربهم هنا ، لسبب بسيط وهو أن Office الأساسي ، آسفًا ، منتجات 365 لا تعمل محليًا على Linux ، الذي نستخدمه للعمل. لا تحتوي الإصدارات المستندة إلى الويب من أدوات Office على نفس مجموعة الميزات مثل التطبيقات الكاملة ، لذلك من غير المرجح أن تتوافق أي نتائج قد نحصل عليها مع الطريقة التي قام بها معظم مستخدمي الأعمال في Office ، ah ، 365 بتكوين Word و Excel و Outlook والأصدقاء على أجهزة الكمبيوتر المحمولة التي تعمل بنظام Windows.

كما وصفه الباحثون:

يتم الإعلان عن هذه الميزة للسماح للمؤسسات بإرسال واستقبال رسائل البريد الإلكتروني المشفرة بين الأشخاص داخل وخارج مؤسستك بطريقة آمنة.

لكنهم يشيرون أيضًا إلى ما يلي:

لسوء الحظ ، يتم تشفير رسائل OME في وضع تشغيل دفتر الترميز الإلكتروني (ECB) غير الآمن.

وأوضح البنك المركزي الأوروبي

لشرح.

العديد من خوارزميات التشفير ، ولا سيما خوارزميات معيار التشفير المتقدم أو AES ، التي تستخدمها OME ، هي ما يُعرف باسم منع الأصفار، والتي تدمج أجزاء كبيرة من البيانات في وقت واحد ، بدلاً من معالجة البتات أو البايتات الفردية بالتسلسل.

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

تستهلك خوارزمية AES الأساسية ، على سبيل المثال ، 16 بايت إدخال نص عادي (128 بت) في المرة الواحدة ، وتقوم بتشويش تلك البيانات تحت مفتاح تشفير لإنتاج 16 بايت إخراج نص مشفر.

(لا تخلط مقاس الكتله مع حجم المفتاح - يمكن أن يبلغ طول مفاتيح تشفير AES 128 بت أو 192 بت أو 256 بت ، اعتمادًا على مدى احتمالية عدم رغبتك في تخمينها ، ولكن جميع أحجام المفاتيح الثلاثة تعمل على كتل 128 بت في كل مرة يتم فيها "تحريك الخوارزمية".)

ما يعنيه هذا هو أنك إذا اخترت مفتاح AES (بغض النظر عن الطول) ثم استخدمت تشفير AES مباشرة على قطعة من البيانات ...

…ثم في كل مرة تحصل فيها على نفس جزء الإدخال ، ستحصل على نفس جزء الإخراج.

مثل كتاب الشفرات الضخم حقًا

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

(لا يمكن أبدًا إنشاء "دفتر رموز" كامل في الحياة الواقعية ، لأنك ستحتاج إلى تخزين قاعدة بيانات تتكون من 2¹²⁸ إدخالات 16 بايت لكل مفتاح ممكن.)

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

على سبيل المثال ، الملفات التي تملأ أقسام البيانات بشكل روتيني بحيث تصطف على حدود 512 بايت (حجم قطاع مشترك عند الكتابة على القرص) أو بحدود 4096 بايت (حجم وحدة تخصيص شائع عند حجز الذاكرة) غالبًا ما تنتج ملفات بها مسافات طويلة من صفر بايت.

وبالمثل ، ستحتوي المستندات النصية التي تحتوي على الكثير من النماذج المعيارية ، مثل الرؤوس والتذييلات في كل صفحة ، أو تكرار اسم الشركة بالكامل ، على عدد وافر من التكرارات.

في كل مرة يصادف فيها مقطع نص عادي متكرر حد 16 بايت في عملية تشفير AES-ECB ، فإنه سيظهر في الإخراج المشفر بالضبط نفس النص المشفر.

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

في ما يلي مثال يستند إلى مقال نشرناه منذ ما يقرب من تسع سنوات عندما أوضحنا سبب استخدام Adobe المشهور حاليًا لتشفير وضع ECB لـ "تجزئة" كلمات مرور مستخدميها ليست فكرة جيدة:

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

في هذا المثال ، كل بكسل في الملف الأصلي يأخذ 4 بايت بالضبط ، لذا فإن كل 4 بكسل من اليسار إلى اليمين في بيانات الإدخال يبلغ طولها 16 بايت ، وهو ما يتماشى تمامًا مع كل كتلة تشفير AES 16 بايت ، وبالتالي إبراز "تأثير البنك المركزي الأوروبي".

---

مطابقة أنماط النص المشفر

والأسوأ من ذلك ، إذا كان لديك وثيقتان تعلم أنه تم تشفيرهما بنفس المفتاح ، وكان لديك نص عادي لأحدهما ، فيمكنك حينئذٍ البحث في النص المشفر الذي لا يمكن قم بفك تشفيرها ، وحاول مطابقة أقسام منها بأنماط في النص المشفر الذي تقوم به يمكن فك.

تذكر أنك لست بحاجة إلى مفتاح "فك تشفير" المستند الأول إذا كان لديك بالفعل في شكل غير مشفر - وهذا معروف ، على نحو غير مفاجئ ، باسم هجوم نص واضح.

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

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

• تم إرسالها جميعًا إلى نفس المستلم ، إذا كانت هناك تحية مشتركة في أعلى كل واحدة.
• الرجوع إلى نفس المشروع ، إذا كانت هناك سلسلة نصية تعريفية فريدة تظهر باستمرار.
• لديهم نفس التصنيف الأمني ​​، إذا كنت حريصًا على التركيز على الأشياء التي من الواضح أنها "أكثر سرية" من البقية.

ماذا ستفعلين.. إذًا؟

لا تستخدم وضع البنك المركزي الأوروبي!

إذا كنت تستخدم كتلة تشفير ، فاختر ملف كتلة وضع التشغيل التشفير على ما يلي:

• يتضمن ما يُعرف باسم IV ، أو متجه التهيئة ، يتم اختياره بشكل عشوائي وفريد ​​لكل رسالة.
• يرتب عمدا عملية التشفير بحيث تخرج المدخلات المتكررة بشكل مختلف في كل مرة.

إذا كنت تستخدم AES ، فإن الوضع الذي ربما تريد اختياره هذه الأيام هو الخدمات المعمارية والهندسية-جي سي إم (وضع Galois Counter Mode) ، والذي لا يستخدم فقط IV لإنشاء دفق بيانات تشفير مختلف في كل مرة ، حتى إذا ظل المفتاح كما هو ، ولكنه يحسب أيضًا ما يعرف بـ رمز مصادقة الرسالة (MAC) ، أو المجموع الاختباري للتشفير ، في نفس الوقت الذي يتم فيه خلط البيانات أو تفكيكها.

لا يعني AES-GCM أنك تتجنب أنماط النص المشفر المتكررة فحسب ، بل يعني أيضًا أنك ستنتهي دائمًا بـ "المجموع الاختباري" الذي سيخبرك ما إذا كانت البيانات التي قمت بفك تشفيرها للتو قد تم العبث بها على طول الطريق.

تذكر أن المحتال الذي لا يعرف ما يعنيه النص المشفر في الواقع قد يكون قادرًا مع ذلك على خداعك للثقة في فك تشفير غير دقيق دون أن يعرف (أو يهتم) نوع الإخراج غير الصحيح الذي ينتهي به الأمر.

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

بدلاً من ذلك ، استخدم ملف تيار الشفرات التي تنتج تدفق مفاتيح شبه عشوائي لكل بايت يسمح لك بتشفير البيانات دون الحاجة إلى معالجة 16 بايت (أو أيًا كان حجم الكتلة) في وقت واحد.

يحول AES-GCM بشكل أساسي AES إلى تشفير دفق ويضيف مصادقة في شكل MAC ، ولكن إذا كنت تبحث عن تشفير دفق مخصص مصمم خصيصًا للعمل بهذه الطريقة ، فنحن نقترح دانيال بيرنشتاين شاشا 20 بولي 1305 (الجزء Poly1305 هو MAC) ، كما هو مفصل في RFC 8439.

أدناه ، أظهرنا ما حصلنا عليه باستخدام AES-128-GCM و ChaCha20-Poly1305 (تجاهلنا رموز MAC هنا) ، جنبًا إلى جنب مع "صورة" تتكون من 95,040،330 بايت RGBA (72 × 4 بمعدل XNUMX بايت لكل بكسل) من مُنشئ Linux kernel pseudo-random.

تذكر أنه لمجرد أن البيانات تبدو غير منظمة لا يعني أنها عشوائية حقًا ، ولكن إذا لم تبدو عشوائية ، ومع ذلك تدعي أنها مشفرة ، فقد تفترض أيضًا أن هناك بعض الهياكل المتبقية ، وأن التشفير هو مشتبه فيه:

ما يحدث بعد ذلك؟

وفقًا لـ WithSecure، لا تخطط Microsoft لإصلاح هذه "الثغرة الأمنية" ، على ما يبدو لأسباب تتعلق بالتوافق مع الإصدارات السابقة مع Office 2010 ...

تتطلب الإصدارات القديمة من Office (2010) AES 128 ECB ، ولا تزال مستندات Office محمية بهذه الطريقة بواسطة تطبيقات Office.

... و ...

لم يتم اعتبار تقرير [باحثو WithSecure] مطابقًا لشروط الخدمات الأمنية ، كما أنه لا يعتبر انتهاكًا. لم يتم إجراء أي تغيير في الرمز وبالتالي لم يتم إصدار CVE لهذا التقرير.

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

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

---

كيف صنعنا الصور في المقالة ابدأ بـ sop330.png ، والذي يمكنك إنشاؤه بنفسك عن طريق اقتصاص شعار SOPHOS الذي تم تنظيفه من أعلى صورة ، وإزالة الحد الأزرق البالغ 2 بكسل ، والحفظ بتنسيق PNG.  يجب أن ينتهي حجم الصورة بحجم 330 × 72 بكسل.
 قم بالتحويل إلى RGBA باستخدام ImageMagick: $ convert sop330.png sop.rgba الإخراج هو 330 × 72 بكسل × 4 بايت / بكسل = 95,040،XNUMX بايت.
 === تشفير باستخدام Lua ومكتبة LuaOSSL (لدى Python ارتباط OpenSSL مشابه جدًا): - تحميل البيانات> fdat = misc.filetostr ('sop.rgba')> fdat: len () 95040 - إنشاء كائنات مشفرة> aes = openssl.cipher.new ('AES-128-ECB')> gcm = openssl.cipher.new ('AES-128-GCM')> cha = openssl.cipher.new ('ChaCha20-Poly1305') - تهيئة كلمات المرور و IVs - يحتاج AES-128-ECB إلى كلمة مرور 128 بت ، ولكن لا يحتاج IV - يحتاج AES-128-GCM إلى كلمة مرور 128 بت و 12 بايت IV - يحتاج ChaCha20 إلى كلمة مرور 256 بت و a 12 بايت IV> aes: تشفير ('THEPASSWORDIS123')> gcm: تشفير ('THEPASSWORDIS123'، 'andkrokeutiv')> cha: encrypt ('THEPASSWORDIS123THEPASSWORDIS123'، 'qlxmtosh476g') - تشفير بيانات الملفات الثلاثة باستخدام > aesout = aes: final (fdat)> gcmout = gcm: final (fdat)> chaout = cha: final (fdat) - ينتج تشفير تيار إخراج بايت بايت ، - لذلك يجب أن يكون النص المشفر بطول النص العادي > gcmout: len () 95040> chaout: len () 95040 - لن نستخدم رموز MAC من GCM و Poly1305 هنا ، - ولكن ينتج كل تشفير "مجموع اختباري" 128 بت (16 بايت) - يستخدم لمصادقة فك التشفير بعد انتهائه - لاكتشاف ما إذا كان نص التشفير المدخل تالفًا أو تم اختراقه - (يعتمد MAC على المفتاح ، لذلك attacker can't forge it)> base.hex (gcm: getTag (16)) a70f204605cd5bd18c9e4da36cbc9e74> base.hex (cha: getTag (16)) a55b97d5e9f3cb9a3be2fa4f040b56ef - إنشاء صورة 95040 / عشوائي> r ملف مختلف. حجم الإدخال مع حجم الكتلة> ملف تعريف مختلف (aesout: sub (1، # fdat)، 'aes.rgba')> ملف تعريف متنوع (gcmout، 'gcm.rgba')> ملف تعريف مختلف (chaout، 'cha. rgba ')> misc.strtofile (rndout،' rnd.rgba ') === لتحميل الملفات في عارض الصور العادي ، قد تحتاج إلى تحويلها مرة أخرى إلى تنسيق PNG بدون فقدان البيانات: $ convert -depth 8-size 330x72 aes .rgba aes.png $ convert -depth 8-size 330x72 gcm.rgba gcm.png $ convert -depth 8-size 330x72 cha.rgba cha.png $ convert -depth 8-size 330x72 rnd.rgba rnd.png === نظرًا لأن عملية التشفير تؤدي إلى تشويش كل البايتات الأربعة في كل بكسل RGBA ، الصورة الناتجة لها شفافية متغيرة (A = alpha ، اختصار لـ tranparency).
 قد يقرر عارض الصور الخاص بك عرض هذا النوع من الصور بخلفية رقعة الشطرنج ، والتي تبدو مربكة وكأنها جزء من الصورة ، لكنها ليست كذلك.  لذلك استخدمنا اللون الأزرق Sophos من الصورة الأصلية كخلفية للملفات المشفرة لتسهيل عرضها.  وبالتالي فإن تدرج اللون الأزرق الكلي ليس جزءًا من بيانات الصورة.