يفحص هذا التقرير التشفير الذي يحمي الاجتماعات في تطبيق Zoom الرائج. وجدنا أن Zoom لديه نظام تشفير “خاص به” ، ويحتوي على نقاط ضعف كبيرة. بالإضافة إلى ذلك حددنا نقاط تثير القلق في البنية التحتية لـ Zoom ، بما في ذلك نقل مفاتيح التشفير للاجتماعات عبر الصين.

• تدعي وثائق Zoom أن التطبيق يستخدم تشفير “AES-256” للاجتماعات حيثما أمكن. ومع ذلك، نجد أنه في كل اجتماع Zoom، يتم استخدام مفتاح AES-128 واحد في وضع ECB من قبل جميع المشاركين لتشفير وفك تشفير الصوت والفيديو. لا يوصى باستخدام وضع ECB لأنه يتم الاحتفاظ بالأنماط الموجودة في النص العادي أثناء التشفير.
• يبدو أن مفاتيح AES-128 -التي تحققنا منها كافية لفك تشفير حزم Zoom التي تم اعتراضها في حركة الإنترنت- يتم إنشاؤها بواسطة خوادم Zoom ، وفي بعض الحالات ، يتم توصيلها إلى المشاركين في اجتماع Zoom عبر خوادم في الصين ، حتى عندما يكون كل المشاركين ، وشركة المشتركين في Zoom ، خارج الصين.
• على ما يبدو، فإن شركة Zoom -التي يقع مقرها في ( Silicon Valley) وادي السيليكون-، تمتلك ثلاث شركات في الصين ويتم عبر هذه الشركات الدفع لما لا يقل عن 700 موظفاً لتطوير برنامج Zoom.قد تبدو هذه الترتيبات -على المستوى الظاهري- جهداً في تحكيم العمالة؛ إذ يمكن ل Zoom تجنب دفع الأجور الأمريكية العالية و أن تستمر في البيع للزبائن في الولايات المتحدة، ما من شأنه أن يرفع هامش أرباح الشركة. ومع ذلك، فإن هذا الإجراء قد يجعل Zoom تستجيب لضغوطات السلطات الصينية.

خلفية: شركة أمريكية.. صينية الهوى؟!

تطبيق Zoom هو تطبيق شائع للمؤتمرات عن بعد، وقد زاد انتشاره بشكل كبير نظراً لأن معظم العالم يخضع للحالة الإلزامية بالعمل من المنزل على خلفية انتشار جائحة كورونا (كوفيد- 19) 

يبدو أن التصميم الشامل للتطبيق يقوم على تقليل الاحتكاك في مؤتمرات الفيديو و جعل الأشياء “تعمل فقط.”

رغم أن مقر Zoom الرئيس يقع في الولايات المتحدة، و مدرج في (NASDAQ) وهو (أحد مؤشرات أسواق الأسهم في الولايات المتحدة)، ولكن يبدو أن تطبيق Zoom الأساسي قد تم تطويره بواسطة ثلاث شركات مقرها في الصين، وكلها تحمل الاسم (软视软件) أي (“برامج روناشي”). 

شركتان من هذه الشركات الثلاثة تعود ملكيتها لشركة Zoom، في حين أن الثالثة مملوكة من قبل كيان يسمى (美国云视频软件技术有限公司) أي (شركة السحابة الأمريكية لتقنية برامج الفيديو، المحدودة) 

إعلانات التوظيف المنشورة ل”برنامج روناشي” في مدينة سوتشو، احتوت على وظائف لمبرمجي ++C ، و لمطوري تطبيقات Android أندرويد و iOS ، و كذلك لمهندسي الاختبار.

يُظهر آخر تسجيل SEC لشركة Zoom أن الشركة (من خلال الشركات التابعة لها في الصين) توظف ما لا يقل عن 700 موظفا في الصين يعملون في مجال “البحث والتطوير”. 

و يشير التسجيل كذلك إلى أن  %81 من عائدات Zoom تأتي من أمريكا الشمالية. 

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

بينما تشير التقارير إلى حظر تطبيق Zoom الأساسي (zoom.us) في الصين منذ نوفمبر 2019، و لكن هناك العديد من الشركات الصينية التابعة لجهات خارجية تبيع تطبيق Zoom داخل الصين؛ (على سبيل المثال ، zoom.cn ، zoomvip.cn ، zoomcloud.c).

أية ميزة تروق لك.. ما دامت سريعة 

ظهرت خلال السنوات البضع السابقة عدة مشاكل متعلقة بقضايا الأمان المتعلقة ب Zoom.

تضمنت هذه المشكلات ثغراتٍ غير مقصودة؛ مثل الثغرات الأمنية في ميزة مشاركة الشاشة في Zoom. كما ظهرت مخاوف أخرى متعلقة بالخصوصية؛ مثل مشاركة Zoom البيانات مع فيسبوك Facebook

لعل أبرز مشاكل الأمان المتعلقة ب Zoom تحيط بالميزات التي صممت بشكل متعمد ل”تقليل الاحتكاك” في الاجتماعات، و التي أيضا ، من خلال التصميم، تضائل من الخصوصية والأمان. 

هذا يتضمن تثبيت Zoom لخادم ويب مخفي على كمبيوترات ماك Mac  للتحايل على نافذة Safari المنبثقة، التي كان يتعين على المستخدمين النقر عليها قبل انضمامهم لاجتماع Zoom، ميزة Zoom التي تزيل مطالبة المستخدم بإدخال كلمة المرور أثناء عملية التنصيب (وبدلا عن ذلك يعرض المطالبة بكلمة مرور مضللة، لاحقا)، ميزة Zoom تهدف إلى السماح للمستخدمين من نفس الشركة أو من مستخدمي نفس مزود الخدمة (ISP) من العثور على بعضهم بسهولة، و ثم رمز Zoom الرقمي المكون من 9 أو 10 أرقام يكفي للانضمام إلى اجتماع قد تم إنشاؤه باستخدام الإعدادات الافتراضية، ما أدى إلى ظاهرة “Zoom Bombing.” 

أسئلة التشفير تحت الضوء

تتضمن وثائق Zoom بعض الادعاءات غير الواضحة حول التشفير الذي تقدمه المنصة. بعض وثائق Zoom (و كذلك التطبيق ذاته) تدعي أن Zoom يوفر ميزة الاجتماعات المشفرة من طرف إلى طرف “end-to-end”

المتعارف عليه في أوساط أمان الكمبيوتر أن مصطلح “مشفر من طرف إلى طرف” يعني بالضرورة أنه لا يمكن الوصول إليه إلا من قبل أطراف الاتصال حصراً (وليس عبر أي وسيط ينقل الاتصال). 

تشير وثائق Zoom الأخرى إلى أن برنامج الاجتماع Zoom لأنظمة تشغيل Windows و MacOS و Linux تستخدم “افتراضيًا” نظام TLS 1.2 المتوافق مع معايير الصناعة لتشفير النقل، على الرغم من أن المدونة المنشورة في سبتمبر 2014 تشير إلى أن هذا البرنامج لا يستخدم TLS.

في ردّ على هذا الالتباس، نشرت Zoom مدونة في نيسان 2020 تشرح فيها مخطط التشفير الخاص بهم. 

المنشور على المدونة يوضح أن Zoom في الوقت الراهن لا تطبق تشفير “طرف إلى طرف” كما يفهم معظم الناس المصطلح؛ و إنما Zoom استخدمت مصطلح “طرف إلى طرف” لوصف الحالة التي يُطلب فيها من جميع المشاركين في المؤتمر (باستثناء أولئك الذين يتصلون عبر شبكة الهاتف العامة) ، يلزم استخدام تشفير النقل بين أجهزتهم وخوادم Zoom.

تعريف Zoom ل “طرف إلى طرف” لا يبدو معيارياً حتى في مجال الحلول الخلاقة لمؤتمرات الفيديو.

نظراً لأن Zoom لا تطبق تشفير “طرف إلى طرف” حقيقي، فإن لديهم القدرة النظرية على فك تشفير مكالمات Zoom و مراقبتها.

ومع ذلك ، تذكر Zoom أنهم لم يبنوا أية آلية لاعتراض اجتماعات عملائهم: “لم تقم Zoom مطلقًا بإنشاء آلية لفك تشفير الاجتماعات المباشرة لأغراض اعتراض قانوني ، وليس لدينا وسائل لإدراج موظفينا أو الآخرين في الاجتماعات دون أن تظهر في قائمة المشاركين “.

مدونة Zoom المنشورة في نيسان 2020 لا تقدم تفاصيل حول كيفية اجراء عملية التشفير بالضبط، ولا توضح حتى ما إذا كانوا يستخدمون TLS أو AES-256. 

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

2. كوفيد-19: اندفاعة ذهبية لجواسيس الإنترنت

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

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

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

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

كان التنصت على هذه اللقاءات أمراً بعيد المنال للجميع، باستثناء الخصوم الرقميين الأكثر تمرساً وخبرةً.

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

هذا الوضع “الطبيعي” الجديد يعد بمنزلة منجم محتمل من الذهب للجواسيس والقراصنة الالكترونيين. نظراً إلى قيمة مختلف قطاعات العمل التي تجري اجتماعاتها عبر منصة Zoom، فإنه من المنطقي أن نتوقع فحص المنصة وتدقيقها عن كثب -بحثا عن أية ثغرة- من قبل المجموعات المنخرطة في التجسس الإلكتروني بدوافع تجارية وسياسية وكذلك من قبل المجموعات المنخرطة في الجرائم الإلكترونية.

Zoom كهدف للمخابرات

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

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

لقد وجهت مجموعة المناصرة للحقوق الرقمية “Access Now” رسالة مفتوحة إلى Zoom تطالب بتقرير شفافية، ولكن Zoom لم تفصح علنا عن معلومات مثل إحصائيات طلبات البيانات من قبل الحكومات و كيف استجابت Zoom لهذه الطلبات. 

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

3. نتائج: تشفير مخصص، خوادم صينية، مشاكل أمنية

بدلاً من استخدام بروتوكول معياري لإرسال الصوت و الفيديو، يبدو أن Zoom تطبق بروتوكول نقل البيانات الخاص بها. 

يبدو أن بروتوكول نقل البيانات الذي تتبعه Zoom هو امتداد مخصص لمعيار (RTP) (بروتوكول النقل في الوقت الحقيقي) الحالي.

بروتوكول Zoom لنقل البيانات يضيف مخطط تشفير Zoom إلى RTP بطريقة غير معتادة. 

افتراضياً، يظهر أن الصوت والفيديو يتم تشفيرهما و فك تشفيرهما في اجتماع Zoom لجميع المشاركين وذلك باستخدام مفتاح AES-128 واحد ومشترك بين المشاركين. يبدو أن مفتاح AES يتم إنشاؤه وتوزيعه على المشاركين في الاجتماع بواسطة خوادم Zoom. 

يستخدم تشفير و فك تشفير Zoom تشفير AES في وضع ECB ، والذي يعرف جيدًا بأنه فكرة سيئة، لأن وضع التشفير هذا يحافظ على الأنماط في الإدخال. توصي بروتوكولات معايير الصناعة لتشفير الوسائط المتدفقة (على سبيل المثال معيار SRTP) باستخدام AES في (Segmented Integer Counter Mode) أو وضع (f8) التي ليس لديها نفس نقاط الضعف كما هو الحال في وضع (ECB)

الشكل 5 يمثل توضيحاً كلاسيكياً لمخاطر وضع (ECB): لا يزال شكل البطريق مرئيًا في صورة مشفرة باستخدام وضع ECB. ¹

أثناء اختبارنا اجتماع Zoom مع اثنين من المستخدمين؛ أحدهما في الولايات المتحدة والآخر في كندا ، وجدنا أن مفتاح AES-128 لتشفير وفك تشفير المؤتمر قد تم إرساله إلى أحد المشاركين عبر TLS من خادم Zoom الموجود على ما يبدو في بكين، 52.81.151.250. 

يُظهر المسح أن ما مجموعه خمسة خوادم في الصين و 68 في الولايات المتحدة تعمل على نفس برنامج خادم Zoom مثل خادم بكين.

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

أثناء تحليلنا قد حددنا كذلك مشكلة أمنية في ميزة غرفة الانتظار في Zoom. وقد قيّمنا المشكلة أنها تمثل خطراً أمنياً على المستخدمين، ولذا فقد قمنا بتقصٍّ للثغرات الأمنية في استخدام Zoom. 

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

في غضون ذلك، يقدم القسم 5 توصيات للمستخدمين حول كيفية تخفيف المشكلة.

4. كيف تحرّينا

بدأنا بمراقبة حركة الانترنت المرتبطة ب Zoom باستخدام برامج Zoom على أنظمة التشغيل Windows، MacOS، و Linux.

استخدمنا  Wireshark لتسجيل حركة الانترنت الخاصة بنا أثناء انضمامنا ومشاركتنا في اجتماعات Zoom. 

معظم حركة الانترنت أثناء اجتماعاتنا على Zoom كانت تبادلاً ما بين كومبيوتراتنا و خادم تملكه Zoom على منفذ UDP 8801. 

كشف فحص آخر لحركة مرور UDP أن Zoom على ما يبدو قد صممت بروتوكول نقل خاصا بها، والذي يغطي بروتوكول RTP المعروف لنقل الصوت و الفيديو.

تحديد الفيديو المشفر

في بعض الحزم ، التي بدأت حمولتها UDP بـ 0x05100100 ، غالبًا ما كان رأس RTP يشفر قيمة من النوع 98. في هذه الحزم، يبدو أن حمولة RTP تحتوي على دفق فيديو H.264 باستخدام التنسيق في  RFC 6184. في هذا التنسيق حمولة RTP هي سلسلة من وحدات NALU (وحدة طبقة تجريد الشبكة) أو أكثر، و التي تحمل مكونات الفيديو (على سبيل المثال ، أنواع مختلفة من إطارات الفيديو والبيانات الوصفية في إعدادات جهاز فك التشفير ، إلخ).

قمنا بتجزئة بعض وحدات NALUs باستخدام المخطط من RFC لـ “وحدة التجزئة A” (FU-A). أعدنا تجميع هذه في NALUs غير المجزأة.

في RFC ، تحتوي كل وحدة NALU على “قيمة نوع” تشير إلى مكون الفيديو الذي يحمله.

في حالة Zoom، تم تعيين جميع قيم NALU على صفر ، وهو غير صالح وفقًا لمعيار RFC ، لذلك شككنا في أن حمولة NALU كانت عبارة عن تنسيق مفصل لـ Zoom.

تتكون كل حمولة NALU من قيمة نهاية كبيرة 4 بايت تبدو وكأنها تصف طولًا (كانت هذه القيم المكونة من 4 بايت أقل من ، ولكن قريبة من حجم الحزم) متبوعًا بعدد من وحدات البايت التي كانت دائمًا أدنى مضاعف لـ 16 أكبر من قيمة طول 4 بايت (أي إذا كانت قيمة طول 4 بايت بين 145 و 160 ، فستتبعها 160 بايت).

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

كشف فحص تفريغ ذاكرة لعملية Zoom خلال اجتماع عن مفتاح AES-128 في الذاكرة المرتبط بسلسلة conf.skey ، التي توقعنا أنها تعني “مفتاح سر المؤتمر”.

لاستخراج الفيديو لكل مشارك، قمنا أولاً بتجميع حزم RTP حسب قيمة SSRC (معرف مصدر التزامن) في رأس RTP. تشير كل قيمة SSRC إلى مشارك واحد. لكل SSRC ، أعدنا تجميع HAL4s NALUs المجزأة بالترتيب الصحيح باستخدام الطوابع الزمنية لـ RTP وأرقام التسلسل ، ثم قمنا بفك تشفيرها باستخدام مفتاح AES-128 في وضع ECB ، ثم قمنا بإزالة النتيجة التي تم فك تشفيرها (باستخدام قيمة طول 4 بايت) ، وأخيرًا كتبنا البيانات التي تم فك تشفيرها إلى القرص في ملف دفق H.264 خام. تمكنا من تشغيل الملف باستخدام الأمر VLC media player التالي:

$ vlc raw.h264 --demux h264

تحديد الصوت المُشفّر 

لاحظنا أيضًا حزمًا أخرى في التقاط Wireshark الخاص بنا والتي بدأت بقيمة الرأس 0x050f0100 ورأس RTP في هذه الحزم غالبًا ما يحتوي على قيمة نوع 112. في هذه الحزم ، تم زيادة الطابع الزمني لـ RTP بمقدار 640 بين الحزم التالية. 

لقد وجدنا ورقة بحثية تصف كيفية الاستدلال على نوع برامج ترميز الصوت RTP من خلال النظر إلى البيانات الوصفية المختلفة في حزم RTP ، بما في ذلك الفرق بين الطوابع الزمنية RTP في الحزم اللاحقة.

توفر الورقة إمكانية واحدة لفرق الطابع الزمني من 640 ، وهو Skype-developed SILK codec بمعدل عينة يبلغ 16000 هرتز.

لاحظنا أيضًا أن حمولات RTP في هذه الحزم يبدو أن لها تنسيق تشفير مشابه لأحمال NALU في حزم الفيديو ، على الرغم من أنها تحتوي على رأس ثنائي البايت بدلاً من أربعة بايت.

لاستخراج الصوت لكل مشارك ، قمنا أولاً بتجميع حزم RTP بواسطة SSRC. لكل مشارك (SSRC) ، أنشأنا ملف SILK ، بدءًا بالبايت السحري “#!SILK_V3”.

لكل SSRC ، قمنا بفك تشفير البايت باتباع قيمة الطول ثنائية البايت (باستخدام نفس مفتاح AES-128 في وضع ECB). قمنا بكتابة وحدات البايت التي تم فك تشفيرها ، مُلحقة بقيمة طولها بايتان (بترتيب بايتات صغيرة) من حمولة RTP.

ثم حصلنا على SILK transcoder وقمنا بنجاح بتحويل كل ملف SILK إلى ملف MP3 يحتوي على الصوت من أحد المشاركين.

$ sh converter.sh raw.silk mp3

تحديد نقل مفتاح AES 

سعينا بعد ذلك لاكتشاف كيفية اشتقاق مفتاح التشفير AES-128 للاجتماع (conf.skey). 

لاحظنا أنه قبل العدد الكبير من حركة المرور على منفذ UDP 8801 ، كان هناك بعض حركة مرور TLS بين جهاز الكمبيوتر وخوادم Zoom.

أنشأنا mitmproxy لاعتراض حركة مرور TLS وقمنا بتكوين عميل Zoom Linux لتوجيه حركة مرور TLS من خلال mitmproxy (٢)

لحسن الحظ ، يبدو أن برنامج Zoom يحذرنا من أن شهادات TLS المزيفة التي تم إنشاؤها بواسطة mitmproxy غير موثوق بها.

بعد أن وثقنا في الشهادات ، لاحظنا سلسلة من الرسائل المتبادلة بين برنامج Zoom وخوادم Zoom. في إحدى الرسائل ، أرسل لنا خادم Zoom مفتاح التشفير كما في الشكل 10.

من غير الواضح بالنسبة لنا ما إذا كانت خوادم Zoom تستخدم مولد أرقام عشوائية آمنًا للتشفير لإنشاء مفاتيح تشفير الاجتماع أو ما إذا كانت المفاتيح يمكن التنبؤ بها بطريقة أو بأخرى. أكدنا أن جميع المشاركين في اجتماع Zoom لديهم نفس قيمة conf.skey وأن هذا المفتاح لا يتغير عند انضمام المشاركين أو مغادرتهم. المفتاح ، مع ذلك ، يتغير عندما يغادر جميع المستخدمين الاجتماع لفترة من الزمن ؛ أي مشارك جديد ينضم إلى اجتماع فارغ سيتسبب في إنشاء قيمة conf.skey جديدة.

5. خاتمة: ليس مناسباً للأسرار

منتج Zoom سهل الاستخدام وقد نمت قاعدة مستخدميه بسرعة كبيرة خلال جائحة كوفيد-19 من خلال “العمل فقط”. جذبت قاعدة مستخدمي Zoom المتنامية بسرعة، إلى جانب لغة التسويق حول التشفير والأمان، العديد من المحادثات الحساسة. من المرجح أن تضع هذه الشعبية المفاجئة المنتج في مرمى وكالات الاستخبارات الحكومية و المجرمين الإلكترونيين.

إرسال مفاتيح التشفير والتشفير المشكوك فيها إلى بكين 

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

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

يأتي تقريرنا في خضمّ عدد من النتائج البحثية والدعاوى القضائية التي تحدد مخاوف أخرى محتملة متعلقة بالأمان و الخصوصية في تطبيق Zoom. 

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

كانت Zoom للتو (2 أبريل 2020) قد ذكرت أنها ستنشر مثل هذا التقرير في غضون 90 يومًا.

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

• الاتصالات الحكومية
• أنشطة تجارية أو أعمال سرية
• مزودي الرعاية الصحية الذين يتعاملون مع معلومات المريض الحساسة/ ذات خصوصية عالية
• المدافعون عن حقوق الإنسان، المحامون، الصحفيون، و آخرون ممن يعملون على قضايا حساسة

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

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

استخدم كلمات مرور Zoom، تجنب غرف الانتظار 

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

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

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

الأمان مطلوب 

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

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

ولكن كما يظهر تقريرنا، فإن هذا الافتراض هو افتراض خاطئ.

شكر وتقدير

نتقدم بالشكر لكل من ماساشي نيشهاتا ، ومايلز كينيون ، ولوتس روان. 

عمل بيل ماركزاك على هذا التقرير مدعوماً جزئيًا من قبل  Center for Long Term Cybersecurity (CLTC) at UC Berkeley و International Computer Science Institute

Footnotes

^{لاحظ أن صورة البطريق على يمين الشكل 5 هي صورة bitmap غير مضغوطة. إن كانت مضغوطة (JPEG أو PNG), سيكون من الصعب عرض شكل البطريق المشفر على اليسار.}