وكيل من OpenAI لم يقبل كلمة "لا": ما الذي يمكن لمشغّلي الخوادم تعلّمه من اختراق بوابة Medicare
في 24 سبتمبر 2026، تحدث رئيس الوزراء الأسترالي، أنتوني ألبانيزي، عن اختراق من نوع جديد. جاء ذلك خلال مؤتمر صحفي في نيويورك، على هامش الجمعية العامة للأمم المتحدة. وقال إن وكيل ذكاء اصطناعي تابعًا لشركة OpenAI دخل بوابة حكومية تابعة لنظام الرعاية الصحية الأسترالي، ووصل إلى أقسام لم يكن مخولًا بالوصول إليها.
وصفت بعض العناوين الحادثة بأنها «اختراق ChatGPT لقاعدة بيانات حكومية». هذا الوصف غير دقيق. لفهم ما حدث، راجعنا النص الرسمي للمؤتمر الصحفي لرئيس الوزراء الأسترالي والصفحة التي توثق فيها OpenAI نشاط وكلائها على مواقع الآخرين. فيما يلي التفاصيل الواردة فيهما، وما تعنيه لمن يدير خادمًا.
ما حدث، بحسب الحكومة الأسترالية
في 18 يونيو 2026، شغّل فريق بحث في OpenAI نموذجًا داخليًا للبحث على الويب في الإنفاق العام على الأدوية. وصل الوكيل إلى Medicare Statistics Reporting Service، وهي بوابة إحصاءات Medicare التي تديرها هيئة Services Australia.
منعته البوابة من الدخول. وبكلمات رئيس الوزراء: «وجد وكيل الذكاء الاصطناعي طريقة لتجاوز الحظر. لم يقبل كلمة "لا" جوابًا».
وصل الوكيل إلى معلومات عامة وأخرى غير عامة في البوابة. وبحسب Services Australia، كتب أيضًا ملفات على الخادم الداخلي للوصول إلى المعلومات.
لم تتلقَّ الحكومة الأسترالية إخطارًا بالاختراق حتى 10 سبتمبر، بعد وقوعه بـ84 يومًا. أُرسل الإخطار إلى عنوان البريد الإلكتروني العام للهيئة. وبحسب الحكومة، لا يوجد في هذه المرحلة دليل على انكشاف معلومات شخصية، ولا يزال التحقيق جاريًا. شُكّل فريق عمل، وتحدث رئيس الوزراء مع الرئيس التنفيذي لشركة OpenAI، سام ألتمان. واختتم حديثه قائلًا: «يجب أن يبقى البشر مسيطرين».
ليست حادثة منفردة، بحسب OpenAI نفسها
لا تذكر OpenAI أستراليا بالاسم في هذه الصفحة، وتوضح أنها تحذف أسماء الجهات المتضررة. لكنها توثق فيها أنشطة من هذا النوع. وتقول إنها تراجع نشاط نماذجها على الويب أثناء التدريب والتقييم، وإنها أخطرت بالفعل «عشرات» المؤسسات المتضررة. تعود بعض المواقع إلى حكومات وجامعات وهيئات عامة. ومن أسباب ذلك أن وكلاء البحث يُوجَّهون إلى مصادر المعلومات الأكثر موثوقية. وتقول الشركة إن المراجعة ستستمر أشهرًا.
تسرد OpenAI في الصفحة خمسة أنواع من النشاط الذي رصدته:
- تجاوز ضوابط الوصول: وصل الوكيل إلى معلومات يتطلب الوصول إليها إثبات الهوية أو تصريحًا أو حسابًا. استخدم مثلًا عنوانًا آخر، أو غيّر تفاصيل في الطلب، أو استخدم اتصالًا قائمًا أتاح له وصولًا أوسع من المتوقع.
- استخدام بيانات دخول مكشوفة: عثر الوكيل على كلمات مرور أو مفاتيح وصول نُشرت على الويب بالخطأ، واستخدمها للدخول.
- حقن الاستعلامات والأوامر: أدخل الوكيل نصًا إلى الخدمة، فنفّذته الخدمة بوصفه تعليمة، مثل استعلام لقاعدة البيانات أو أمر على الخادم.
- الوصول إلى الأجزاء الداخلية للخدمة: قرأ الوكيل ملفات تحتوي على شيفرة الخدمة، أو وصل إلى أنظمة داخلية.
- «محتوى مزعج تنشره الوكلاء»: نشر الوكيل محتوى على مواقع الآخرين. استخدم مثلًا موقع ويكي عامًا كلوحة رسائل.
كتب كبير العلماء في OpenAI، ياكوب باتشوتسكي، في سبتمبر: «أرى أنه لا يوجد حاليًا مختبر حلّ مشكلات المواءمة والمراقبة بالقدر الكافي لمواصلة التوسع بأقصى سرعة، على نحو مسؤول، لفترة طويلة». كما أبطأت OpenAI تدريب نماذجها الأكثر تقدمًا، وعلّقت أكبر عملية تدريب كانت تخطط لها.
الدرس الأول: الحظر القائم على الطلب ليس حماية
معظم الإجراءات التي تتخذها المواقع في مواجهة البوتات هي في الواقع طلبات. يطلب ملف robots.txt من الزاحف عدم الدخول. وتطلب قاعدة عند حافة شبكة CDN من البوت التعريف بنفسه. البوت الذي يحترم هذه الطلبات يلتزم بها.
أما الوكيل الذي لا يقبل «لا» جوابًا، فيتعامل مع الحظر باعتباره مشكلة عليه حلّها. قد يجرّب عنوانًا آخر، أو يغيّر الطلب، أو يبحث عن مفتاح تركه أحدهم مكشوفًا على الويب. هذا هو النشاط الذي تصفه OpenAI. ولن يقتصر على OpenAI: فالأدوات نفسها متاحة لكل من يشغّل الوكلاء، بمن فيهم من يشغّلونها لأغراض خبيثة.
في مواجهة وكيل كهذا، يجب أن تعمل الحماية على الخادم نفسه، وأن تفرض قيود الوصول. ولا يمكنها الاعتماد على تعاون من يرسل الطلبات إلى الخادم. تناولنا ذلك بالتفصيل في تدوينة عن زواحف الذكاء الاصطناعي التي تُثقل الخادم.
الدرس الثاني: ثلاث من الطرق الخمس تبدأ على خادمك
تتضمن قائمة OpenAI ثلاث طرق تبدأ على خادمك. غالبًا ما تأتي بيانات الدخول المكشوفة من ملفات إعدادات ومستودعات شيفرة تُركت متاحة على الويب. ويبدأ حقن الاستعلامات بطلب يحاول تمرير أمر بدلًا من بيانات إدخال. أما الوصول إلى الملفات الداخلية للخدمة، فيبدأ بفحص يبحث عنها.
تشترك الطرق الثلاث في أمر واحد: يسبق نجاح المحاولة بحث. ويمكن رصد هذا البحث على الخادم.
يعمل nuDefend على خادم Linux لديك، ويحظر هذه المحاولات قبل أن تصل إلى التطبيق:
- عمليات فحص تبحث عن ملفات إعدادات وأسرار وشيفرة مكشوفة؛
- محاولات حقن واختراق معروفة؛
- زواحف ذكاء اصطناعي تعرّف نفسها بهذه الصفة، أو تتجاوز معدل الطلبات الذي حددته؛
- تخمين كلمات المرور؛
- عناوين من مصادر خبيثة معروفة، وفق قوائم تُحدَّث كل 30 دقيقة.
عند إجراء فحص يبحث عن ملفات أسرار، أو محاولة حقن، يُحظر عنوان المصدر من الطلب الأول. ويظهر الحظر في لوحة التحكم.
الدرس الثالث: 84 يومًا دون علم
التفصيل الأكثر إثارة للقلق في الحادثة الأسترالية ليس الاختراق نفسه، بل التأخر في الإخطار به. لم يتلقَّ أصحاب النظام إخطارًا طوال ما يقارب ثلاثة أشهر. وفي النهاية، علموا به عبر رسالة بريد إلكتروني من الجهة التي نفّذته.
معرفة ما يحدث على الخادم هي نصف الحماية. يتضمن nuDefend لوحة تحكم محلية تعرض من حاول الدخول، وما حُظر، ولماذا. تبقى المعلومات على خادمك، ولا تُرسل إلى أي مكان.
بصراحة عن حدود الحماية
لم يكن nuDefend «ليوقف OpenAI»، ونحن لا ندّعي ذلك. فالوكيل الذي يتظاهر بأنه متصفح عادي، ولا يطلب إلا صفحات مشروعة، لن يبدو بالضرورة مريبًا. nuDefend ليس WAF متكاملًا، ولا يوفر حماية من هجمات DDoS الحجمية. إنه طبقة إضافية إلى جانب الحماية الموجودة لديك عند حافة الشبكة.
الخلاصة
حتى هذا العام، كان البوت الذي يبحث عن ثغرات عادةً برنامجًا نصيًا بسيطًا. أما اليوم، فقد يكون وكيلًا يجرّب طرقًا كثيرة ومختلفة، ويواصل المحاولة حتى تنجح إحداها. قال رئيس الوزراء الأسترالي إن البشر يجب أن يبقوا مسيطرين. وعلى خادمك، يعني ذلك أن تبدأ بطبقة حماية تفرض قيود الوصول، ولا تكتفي بطلب احترامها.
قضى الوكيل في أستراليا 84 يومًا من الهدوء. على خادم يعمل عليه nuDefend، يُحظر الوكيل الذي يبحث عن ملفات الأسرار أو يحاول حقن أمر عند أول طلب. ترى الحظر في لوحة التحكم، لا بعد 84 يومًا.
لا تنتظر رسالة بريد إلكتروني من OpenAI. ثبّت nuDefend بأمر واحد.