هجمات UDP على المكالمات الجماعية في تيليجرام وما يستطيع المشرفون فعله

في 6 مايو نشر مستخدم على منصة الأخطاء الرسمية لتيليجرام تقريراً بعنوان «Report of Possible UDP/DDoS Abuse Affecting Telegram Voice Chats»، على نسخة أندرويد 12.6.4. يقول التقرير إن مجتمعات عامة تعاني تقطعاً وانفصالاً متكرراً في المكالمات الصوتية، وإن مهاجمين يستخدمون أدوات لإرسال حزم UDP أثناء المكالمة. وأضاف مشرفون آخرون تعليقات تؤكد الأعراض نفسها: صوت متقطع، وحلقات إعادة اتصال، وانهيار المكالمة.

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

كيف تبدو الهجمة من جهة المشرف

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

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

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

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

لماذا UDP، وما الذي يختلف عن TCP

المكالمة الصوتية في معظم المنصات قناتان وليست قناة واحدة. الأولى قناة تحكم وتشوير (signaling) تعمل عبر اتصال TCP عادي، وبها تعرف المنصة أنك دخلت وتخبرك أين ترسل الصوت. والثانية قناة الوسائط، وهي UDP، وفيها يسير الصوت نفسه. توثيق ديسكورد للمطورين يصف هذا البناء صراحة: اتصال WebSocket للتحكم، واتصال UDP منفصل لنقل الصوت. واختيار UDP للصوت شرحه العام أن الصوت المتأخر بلا قيمة، فلا فائدة من إعادة إرسال ما ضاع كما يفعل TCP.

وهنا مصدر الالتباس الذي قد يقع فيه من يقرأ عن الهجمة. UDP بلا اتصال، فلا يوجد فيه شيء اسمه «انضمام». لكن الانضمام يحدث في قناة التحكم، وردّ المنصة عليه هو ما يحمل وجهة الوسائط. في ديسكورد مثلاً يعيد الخادم عنوان نقطة النهاية في رسالة VOICE_SERVER_UPDATE، ثم يعيد في رسالة Ready عنوان IP ومنفذ UDP يتوقع الخادم أن يصله الصوت عليهما. كل عميل منضم يحصل على هذه المعلومات لأنه يحتاجها ليعمل. فمن دخل عرف الوجهة، سواء كان مستمعاً حقيقياً أو حساباً وهمياً.

أما الفرق بين البروتوكولين عند الهجوم فهو في المصافحة:

• TCP لا تبدأ فيه البيانات قبل مصافحة ثلاثية: SYN ثم SYN-ACK ثم ACK. المصافحة تثبت أن الطرف الآخر يستقبل الرد فعلاً، ولهذا يصعب على من زوّر عنوان مصدره أن يكمل الاتصال.
• هجوم TCP المعروف، SYN flood، لا يكمل المصافحة ويترك الخادم ينتظر اتصالات نصف مفتوحة تستهلك موارده. وبما أن هناك مصافحة، يستطيع وسيط أن يتولاها بدل الخادم: تقول Cloudflare إنها تنفذ المصافحة في سحابتها ولا تمرر الاتصال إلى الخادم الأصلي إلا بعد اكتمالها.
• UDP بلا مصافحة ولا حالة. كل حزمة رسالة مستقلة تصل وتُعالج، ولا توجد خطوة تثبت أن المرسل هو من يدّعي، فيستطيع المهاجم تزوير عنوان المصدر.
• إذا وصلت حزمة UDP إلى منفذ لا يستمع إليه برنامج، يرد الخادم بحزمة ICMP تفيد أن الوجهة غير متاحة، بحسب Cloudflare، وهذا الرد يستهلك موارد أيضاً. ولهذا تسقط Cloudflare على حافة شبكتها كل حركة UDP غير المتعلقة بـ DNS.

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

المشكلة ليست خاصة بتيليجرام

قبل أن نعمّم لا بد من فرز الموثق من المستنتج. الموثق أن بنية الصوت متشابهة في المنصات الكبرى: العميل يتلقى من المنصة وجهة وسائط ويرسل إليها عبر UDP. أما أن أسلوب الحسابات الوهمية المربوطة ببوت مستعمل على غير تيليجرام فلم أجد له تقريراً منشوراً. فالمقارنة هنا بين البنى وليست بين حوادث.

في ديسكورد، بحسب مدونة هندستها، تُسند كل قنوات الصوت في الخادم الواحد (guild) إلى خادم صوت واحد، ويُبلَّغ العملاء به. وتقول المدونة إن تعرض خادم الصوت لهجمة DDoS أمر شائع، وإنها ترصده من الارتفاع السريع في الحزم الواردة. والإجراء الذي تصفه مثير للاهتمام: يُزال الخادم المتأثر من نظام اكتشاف الخدمات، ويُختار للمجموعة خادم صوت جديد، وتُنقل إليه حالات الصوت، ويُبلَّغ العملاء بالوجهة الجديدة ليعيدوا الاتصال. وحين تنتهي الهجمة يعود الخادم إلى الخدمة. هذا بالضبط ما يفعله مشرف تيليجرام يدوياً حين ينهي المكالمة ويفتحها من جديد، مع فارق أن ديسكورد تفعله آلياً وبلا تدخل المشرف. والمدونة قديمة نسبياً، ولا أعرف إن كانت التفاصيل ما زالت كما هي.

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

النمط الثاني هو المكالمات الفردية المباشرة، وفيه يختلف من هو الهدف. بحسب TechCrunch، تستعمل تطبيقات مثل تيليجرام وسيغنال وواتساب اتصالاً مباشراً بين الطرفين في بعض الحالات، فيعرف كل طرف عنوان الآخر. وتوفر لذلك إعدادات تمرر المكالمة عبر خوادمها: خيار Never في إعداد Peer-to-Peer في تيليجرام، وخيار Always relay calls في سيغنال، وخيار حماية عنوان IP أثناء المكالمات في واتساب. وتذكر مدونة سيغنال أن الاتصال المباشر يقلل التأخير لكنه يعرّض عنوانك للطرف الآخر، وأن المكالمة القادمة من خارج جهات الاتصال تُمرَّر عبر الخادم.

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

حسابات وهمية تدخل وتخرج قبل أن تلاحظها

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

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

تقنياً، دخول المشاركين وخروجهم ليس خفياً بالكامل، لكنه ليس في الواجهة التي تراها. في واجهة تيليجرام البرمجية الأساسية (MTProto) يصف التوثيق كل مشارك بكائن اسمه groupCallParticipant، وفيه حقلان: just_joined بمعنى أن المشارك انضم للتو، وleft بمعنى أنه غادر طبقة الوسائط. وتصل هذه الكائنات في تحديثات تُرسل إلى أعضاء المجموعة. أما التطبيق فلا ينبهك لحظة الدخول، والحساب قد يدخل ويخرج بين نظرة وأخرى، فتبقى المراقبة اليدوية بلا فائدة. وفي أنواع Bot API كما تعرضها مكتباتها لا أجد حدث انضمام أو مغادرة، بل رسائل بدء المكالمة وانتهائها وجدولتها ودعوة مشاركين فقط. فالأرجح أن أي أداة تراقب الدخول والخروج تعمل بحساب مستخدم عبر الواجهة الكاملة وليس ببوت عادي، وهذا استنتاج لم أتحقق منه في صفحة Bot API الرسمية.

هل تنفع بوتات مراقبة الدخول والخروج؟

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

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

الثاني أن الحظر يأتي بعد أن يؤدي الحساب مهمته. العنوان والمنفذ يُلتقطان عند الانضمام، فحتى لو حُظر الحساب في الثانية التالية فقد حصل المهاجم على ما أراد. والحسابات الوهمية رخيصة ومتجددة، فالحظر يستنزف المهاجم قليلاً ولا يوقفه.

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

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

لماذا لا يملك المشرف حماية مباشرة

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

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

القنوات والبث المباشر في الوضع نفسه

لا تظن أن القناة بديل آمن. مشرفو القنوات يعانون من الأعراض نفسها التي يعاني منها مشرفو المجموعات، وهذا ما رصدناه، ويتسق مع التوثيق. تسمي وثائق تيليجرام المكالمة المرتبطة بمجموعة video chat، والمرتبطة بقناة livestream، لكنها تعرّفهما نوعاً واحداً من المكالمات الجماعية: يُنشأ بالطريقة نفسها phone.createGroupCall، ويُنضم إليه بالطريقة نفسها phone.joinGroupCall، ويمثله الكائن نفسه groupCall. الفرق في الاسم وفيما ترتبط به المكالمة، وليس في آلية الاتصال. فمن دخل بثاً في قناة حصل على ما يحصل عليه من دخل مكالمة مجموعة.

يبقى في التوثيق وضعان قد يغيّران الصورة نظرياً: stream mode وفيه يحمّل العميل مقاطع الوسائط على دفعات بدل اتصال WebRTC حي، و RTMP mode وفيه يبث تطبيق خارجي واحد كل الوسائط. لكن التوثيق يقول إن stream mode يُفعَّل تلقائياً مع الجمهور الكبير أو في وضع RTMP، وإن البث قد يستخدم WebRTC العادي. أي أن بثاً عادياً في قناة صغيرة أو متوسطة يعمل كمكالمة المجموعة تماماً. وبعض المشرفين يظنون أن البث أقل تأثراً، ولا نجد مصدراً يدعم ذلك، وما رصدناه عكسه. وإن كان المستمع في stream mode لا يحتفظ باتصال حي، فهذا تفسير نظري لانخفاض التعرض، وهو استنتاج لم يثبت.

ما تستطيع فعله اليوم

1. انقل المكالمة المهمة إلى مجموعة خاصة

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

2. اجعل الانضمام بموافقة

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

3. أبطل الروابط القديمة

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

4. أنهِ المكالمة وافتحها من جديد عند أول انهيار

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

5. وثّق الهجمة وأبلغ عنها

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

ما الذي يحتاج تيليجرام إلى إصلاحه

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

وإن كنت مشاركاً لا مشرفاً

إعداد Peer-to-Peer في خصوصية المكالمات يخص المكالمات الفردية، وليس مكالمات المجموعات. بحسب TechCrunch يستخدم تيليجرام اتصالاً مباشراً بين الطرفين بشكل افتراضي مع جهات اتصالك، فيعرف كل طرف عنوان الآخر، أما من ليسوا في جهات اتصالك فتمر مكالماتهم عبر خوادم تيليجرام. ويمكنك اختيار Never لتمر كل المكالمات عبر الخوادم، من الإعدادات ثم الخصوصية والأمان ثم المكالمات، وقد تتغير تسمية القائمة بين الإصدارات. هذا لا يحميك من هجوم موجّه إلى مكالمة المجموعة نفسها، لكنه يغلق باباً آخر يسهّل استهدافك شخصياً من جهة اتصال لا تثق بها.

المصادر

• Report of Possible UDP/DDoS Abuse Affecting Telegram Voice Chats، Telegram Bugs and Suggestions
• Group calls، Telegram API Documentation
• Voice، Discord Developer Documentation
• How Discord Handles Two and Half Million Concurrent Voice Users using WebRTC، Discord Blog
• UDP flood attack، Cloudflare Learning Center
• SYN flood attack، Cloudflare Learning Center
• What Is a UDP Flood Attack، VergeCloud
• Telegram is still leaking user IP addresses to contacts، TechCrunch
• PSA: Your chat and call apps may leak your IP address، TechCrunch