تتعرض Polymarket لثاني خرق أمني بقيمة ملايين الدولارات في غضون أربعة أشهر

استأنفت Polymarket التداول في 29 أكتوبر بعد أن عطل مزود طرف ثالث مخترق سوق التنبؤ الدولي. وشكل هذا الحادث ثاني خرق أمني بقيمة ملايين الدولارات لـ Polymarket خلال أربعة أشهر. ووضعت سجل الحوادث الرسمي لـ Polymarket بداية قيود التداول عند 18:05 بالتوقيت العالمي الموحّد وحلّها عند 19:05 بالتوقيت العالمي الموحّد. وقالت Polymarket إن المشكلة تم إصلاحها، كما تم إخطار السلطات القضائية. كما وعدت Polymarket بتعويض كامل للمستخدمين المتضررين.

قدّرت شركة تحليلات البلوكشين Bubblemaps أن خرق 29 أكتوبر أثر على أكثر من 700 مستخدم من مستخدمي Polymarket و compromis حوالي 3.46 مليون دولار من الأصول. قام المهاجمون بتبادل حوالي 2.7 مليون دولار مقابل POL ونقلوا الأموال خارجًا. بقيت 750,000 دولار أخرى على Polymarket عند إجراء التقييم.

كشفت Polymarket في 25 يونيو أن موردًا مخترقًا قد مكّن حقن نص ضار. وقالت Polymarket إن الاعتماد المتأثر تم إزالته، ووعدت برد كامل للأموال. أبلغت Source Defense عن خسائر بلغت حوالي 3 ملايين دولار نتيجة الهجوم في يونيو. وتعقبت Source Defense عملية التسليم إلى علامة تسويقية كانت تجلب مكتبة هوية خارجية، والتي استبدلها المهاجم بمُسحب مخصص لـ Polymarket. وقال باحثو Source Defense إن حمولة يونيو استهدفت المحافظ التي تحتوي على أكثر من 100,000 دولار وسعت مرارًا وتكرارًا للحصول على تفويض رقمي. وتمت الموافقة على التفويض عبر مُعيد الإرسال الخاص بـ Polymarket، الذي يقدم الإجراءات الموقعة.

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

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

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

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