الأمن السيبراني
#الذكاء_الاصطناعي
#أمن_المعلومات
درس قاسٍ: لماذا لا يجب الوثوق بأكواد الذكاء الاصطناعي؟
أصبح مصطلح "Vibe coding" - أي استخدام نماذج الذكاء الاصطناعي للمساعدة في كتابة الأكواد - جزءاً لا يتجزأ من الحياة اليومية للعديد من فرق التطوير. ورغم أنه يوفر الوقت بشكل كبير، إلا أنه قد يؤدي إلى ثقة مفرطة في النتائج، مما يفتح الباب واسعاً أمام الثغرات الأمنية الخطيرة.
تقدم تجربة شركة "Intruder" دراسة حالة واقعية حول كيفية تأثير الكود المولد بالذكاء الاصطناعي على الأمن الرقمي، وما الذي يجب على المؤسسات الحذر منه.
عندما يبني الذكاء الاصطناعي "المصيدة"
في سياق عملها لتقديم خدمات الاستجابة السريعة، قامت الشركة بإعداد "مصائد رقمية" (Honeypots) مصممة لجمع محاولات الاستغلال المبكرة للهجمات. ولأنهم لم يجدوا خياراً مفتوح المصدر يلبي احتياجاتهم تماماً لأحد هذه المصائد، لجأ الفريق إلى ما يفعله الكثيرون اليوم: استخدام الذكاء الاصطناعي لصياغة نموذج إثبات المفهوم (PoC).
تم نشر الكود كبنية تحتية ضعيفة عمداً في بيئة معزولة، ومع ذلك، أجرى الفريق فحصاً سريعاً للمنطق البرمجي قبل الإطلاق.
بعد بضعة أسابيع، ظهر شيء غريب في السجلات. الملفات التي كان يجب تخزينها تحت عناوين IP الخاصة بالمهاجمين كانت تظهر بأسماء تحتوي على سلاسل برمجية هجومية (Payloads)، مما أوضح أن مدخلات المستخدم كانت تصل إلى أماكن لم يكن من المفترض أن تصل إليها.
الثغرة التي لم يتوقعها أحد
كشف الفحص الدقيق للكود عما حدث: أضاف الذكاء الاصطناعي منطقاً برمجياً يسحب ترويسات IP التي يقدمها العميل (Client-supplied IP headers) ويعاملها على أنها عنوان IP الحقيقي للزائر.
هذا التصرف لا يكون آمناً إلا إذا كانت الترويسات قادمة من وكيل (Proxy) تتحكم فيه أنت؛ وخلاف ذلك، فهي تخضع لسيطرة العميل تماماً. هذا يعني أن زائر الموقع يمكنه بسهولة تزييف عنوان IP الخاص به أو استخدام الترويسة لحقن برمجيات خبيثة، وهي ثغرة شائعة تظهر غالباً في اختبارات الاختراق.
في هذه الحالة، وضع المهاجم حمولته داخل الترويسة، مما فسر أسماء الدلائل غير المعتادة. ورغم أن التأثير كان محدوداً هنا، إلا أن الخطأ نفسه لو استخدم في سياق آخر لكان قد أدى إلى كشف ملفات محلية (LFD) أو تزوير طلبات من جانب الخادم (SSRF).
لماذا فشلت أدوات الفحص التقليدية؟
شغّل الفريق أدوات تحليل مثل Semgrep OSS وGosec على الكود، ولم تبلغ أي منهما عن الثغرة، رغم أن Semgrep اقترحت تحسينات غير ذات صلة. هذا ليس فشلاً للأدوات، بل هو قيد في التحليل الثابت (Static Analysis).
يتطلب اكتشاف هذا الخلل فهماً سياقياً بأن ترويسات IP المقدمة من العميل يتم استخدامها دون التحقق من صحتها، وأنه لم يتم فرض حدود للثقة. هذه التفاصيل الدقيقة تكون واضحة للمختبر البشري، لكن يسهل تفويتها عند الوثوق المفرط في الذكاء الاصطناعي.
الرضا عن الأتمتة وتجربة Gemini
هناك فكرة موثقة في مجال الطيران تفيد بأن الإشراف على الأتمتة يتطلب جهداً ذهنياً أكبر من أداء المهمة يدوياً. وبما أن الكود لم يكتبه المطورون بأنفسهم، فإن النموذج الذهني لكيفية عمله لم يكن قوياً، مما أضعف عملية المراجعة.
لم تكن هذه حالة معزولة؛ فقد استخدم الفريق نموذج Gemini للمساعدة في إنشاء أدوار IAM مخصصة لخدمات AWS، وتبين أنها عرضة لتصعيد الامتيازات. حتى بعد الإشارة إلى المشكلة، وافق النموذج بأدب ثم أنتج دوراً آخر مصاباً بالثغرة نفسها. استغرق الأمر أربع جولات من التكرار وتوجيهاً بشرياً كاملاً للوصول إلى تكوين آمن.
الخلاصة للفرق التقنية
تثبت هذه التجارب أن أدوات التطوير المدعومة بالذكاء الاصطناعي تسهل على غير الخبراء إنتاج أكواد برمجية، لكنها قد تكون مليئة بالثغرات. توصي Intruder بعدم السماح لغير المطورين أو غير المختصين بالأمن بالاعتماد على الذكاء الاصطناعي لكتابة الأكواد.
وحتى بالنسبة للخبراء، يجب إعادة النظر في عمليات مراجعة الكود للتأكد من عدم تسلل هذا النوع الجديد من المشاكل، حيث يتوقع أن تصبح الثغرات الناتجة عن الذكاء الاصطناعي أكثر شيوعاً في المستقبل.
الأسئلة الشائعة
قام الذكاء الاصطناعي بإضافة منطق برمجي يثق بترويسات IP التي يقدمها العميل ويعاملها كعنوان حقيقي، مما سمح للمهاجمين بتزييف البيانات وحقن نصوص برمجية.
لأن اكتشاف هذا النوع من الثغرات يتطلب فهماً للسياق (Context) وكيفية استخدام البيانات، وهو ما تفتقده أدوات التحليل الثابت التي تبحث عن أنماط محددة فقط.
لا، أنتج Gemini أدواراً عرضة لتصعيد الامتيازات، وتطلب الأمر 4 محاولات وتوجيهاً بشرياً مستمراً للوصول إلى تكوين آمن.
التعليقات 0
سجل دخولك لإضافة تعليق
لا توجد تعليقات بعد. كن أول من يعلق!