أصبح “ترميز Vibe” – باستخدام نماذج الذكاء الاصطناعي للمساعدة في كتابة التعليمات البرمجية – جزءًا من التطوير اليومي للعديد من الفرق. يمكن أن يوفر ذلك وقتًا كبيرًا، ولكنه قد يؤدي أيضًا إلى الإفراط في الثقة في التعليمات البرمجية التي ينشئها الذكاء الاصطناعي، مما يخلق مجالًا لإدخال الثغرات الأمنية.
الدخيل تُعد التجربة بمثابة دراسة حالة واقعية حول كيفية تأثير التعليمات البرمجية التي ينشئها الذكاء الاصطناعي على الأمان. إليك ما حدث وما يجب على المنظمات الأخرى مراقبته.
عندما نسمح للذكاء الاصطناعي بالمساعدة في بناء مصيدة جذب
لتسليم لدينا”https://www.intruder.io/blog/rapid-response-bridge-the-gap-to-find-exploits-faster” rel=”nofollow noopener”> الاستجابة السريعة الخدمة، قمنا بإعداد مصائد جذب مصممة لجمع محاولات الاستغلال في المراحل المبكرة. بالنسبة لأحدها، لم نتمكن من العثور على خيار مفتوح المصدر يحقق ما أردناه بالضبط، لذلك فعلنا ما تفعله الكثير من الفرق هذه الأيام: استخدمنا الذكاء الاصطناعي للمساعدة في صياغة إثبات المفهوم.
تم نشره كبنية تحتية معرضة للخطر عمدًا في بيئة معزولة، لكننا مازلنا نجري فحصًا سريعًا للسلامة قبل طرحه.
وبعد بضعة أسابيع، بدأ شيء غريب يظهر في السجلات. الملفات التي كان من المفترض تخزينها تحت عناوين IP للمهاجمين كانت تظهر مع سلاسل الحمولة بدلاً من ذلك، مما أوضح أن إدخال المستخدم كان ينتهي في مكان لم نقصده.
الضعف الذي لم نتوقع حدوثه
أظهر الفحص الدقيق للكود ما كان يحدث: أضاف الذكاء الاصطناعي منطقًا لسحب رؤوس IP التي يقدمها العميل ومعاملتها على أنها عنوان IP للزائر.
سيكون هذا آمنًا فقط إذا كانت الرؤوس تأتي من وكيل تتحكم فيه؛ وإلا فهم تحت سيطرة العميل بشكل فعال.
وهذا يعني أن زائر الموقع يمكنه بسهولة انتحال عنوان IP الخاص به أو استخدام الرأس لإدخال الحمولات، وهي ثغرة غالبًا ما نجدها في اختبارات الاختراق.
في حالتنا، قام المهاجم ببساطة بوضع حمولته في الرأس، وهو ما يوضح أسماء الدليل غير العادية. كان التأثير هنا منخفضًا ولم تكن هناك علامة على وجود سلسلة استغلال كاملة، لكنه أعطى المهاجم بعض التأثير على كيفية تصرف البرنامج.
كان من الممكن أن يكون الأمر أسوأ بكثير: لو كنا نستخدم عنوان IP بطريقة أخرى، لكان من الممكن أن يؤدي الخطأ نفسه بسهولة إلى الكشف عن ملف محلي أو تزوير طلب من جانب الخادم.
لماذا فاتها SAST؟
ركضنا”https://github.com/semgrep/semgrep” rel=”nofollow noopener”>Semgrep OSS و”https://github.com/securego/gosec” rel=”nofollow noopener”>جوزيك على الكود. ولم يتم الإبلاغ عن الثغرة الأمنية، على الرغم من أن Semgrep أبلغ عن بعض التحسينات غير ذات الصلة. وهذا لا يعد فشلًا لهذه الأدوات، بل إنه يمثل قيدًا على التحليل الثابت.
يتطلب اكتشاف هذا الخلل تحديدًا فهمًا سياقيًا لحقيقة أن رؤوس IP المقدمة من العميل تم استخدامها دون التحقق من الصحة، وأنه لم يتم فرض أي حدود للثقة.
إنه نوع من الفوارق الدقيقة التي تكون واضحة بالنسبة للإنسان، ولكن من السهل تفويتها عندما يضع المراجعون قدرًا كبيرًا من الثقة في التعليمات البرمجية التي ينشئها الذكاء الاصطناعي.
الرضا عن أتمتة الذكاء الاصطناعي
هناك فكرة موثقة جيدًا في مجال الطيران مفادها أن الإشراف على الأتمتة يتطلب جهدًا معرفيًا أكبر من أداء المهمة يدويًا. ويبدو أن نفس التأثير يظهر هنا.
نظرًا لأن الكود لم يكن خاصًا بنا بالمعنى الدقيق للكلمة – فنحن لم نكتب السطور بأنفسنا – فإن النموذج العقلي لكيفية عمله لم يكن قويًا، وعانت المراجعة.
لكن المقارنة بالطيران تنتهي عند هذا الحد. تتمتع أنظمة الطيار الآلي بعقود من هندسة السلامة، في حين أن التعليمات البرمجية المولدة بواسطة الذكاء الاصطناعي لا تتمتع بذلك. لا يوجد حتى الآن هامش أمان محدد يمكن الرجوع إليه.
لم تكن هذه حالة معزولة
لم تكن هذه هي الحالة الوحيدة التي أدى فيها الذكاء الاصطناعي بثقة إلى نتائج غير آمنة. لقد استخدمنا نموذج الاستدلال Gemini للمساعدة في إنشاء أدوار IAM مخصصة لـ AWS، والتي تبين أنها عرضة لتصعيد الامتيازات. وحتى بعد أن أشرنا إلى هذه المشكلة، وافق النموذج بأدب ثم أنتج دورًا ضعيفًا آخر.
استغرق الأمر أربع جولات من التكرار للوصول إلى تكوين آمن. ولم يتعرف النموذج في أي وقت من الأوقات على المشكلة الأمنية بشكل مستقل، بل كان يتطلب توجيهًا بشريًا طوال الطريق.
عادة ما يكتشف المهندسون ذوو الخبرة هذه المشكلات. لكن أدوات التطوير المدعومة بالذكاء الاصطناعي تسهل على الأشخاص الذين ليس لديهم خلفيات أمنية إنتاج التعليمات البرمجية، و”https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/” rel=”nofollow noopener”> الأبحاث الحديثة وقد وجدت بالفعل الآلاف من نقاط الضعف التي تقدمها هذه المنصات.
ولكن كما أوضحنا، حتى المطورين ذوي الخبرة ومحترفي الأمان يمكنهم التغاضي عن العيوب عندما تأتي التعليمات البرمجية من نموذج الذكاء الاصطناعي الذي يبدو واثقًا ويتصرف بشكل صحيح للوهلة الأولى. وبالنسبة للمستخدمين النهائيين، لا توجد طريقة لمعرفة ما إذا كان البرنامج الذي يعتمدون عليه يحتوي على تعليمات برمجية تم إنشاؤها بواسطة الذكاء الاصطناعي، مما يضع المسؤولية بقوة على عاتق المؤسسات التي تقوم بشحن التعليمات البرمجية.
الوجبات السريعة للفرق التي تستخدم الذكاء الاصطناعي
كحد أدنى، لا نوصي بالسماح لغير المطورين أو الموظفين غير العاملين في مجال الأمن بالاعتماد على الذكاء الاصطناعي لكتابة التعليمات البرمجية.
وإذا كانت مؤسستك تسمح للخبراء باستخدام هذه الأدوات، فمن المفيد إعادة النظر في عملية مراجعة التعليمات البرمجية وإمكانيات الكشف عن CI/CD للتأكد من عدم تسلل هذه الفئة الجديدة من المشكلات.
نتوقع أن تصبح الثغرات الأمنية التي يقدمها الذكاء الاصطناعي أكثر شيوعًا بمرور الوقت.
لن تعترف سوى عدد قليل من المنظمات علنًا عندما تنشأ مشكلة ما نتيجة لاستخدامها للذكاء الاصطناعي، لذا فمن المحتمل أن يكون حجم المشكلة أكبر مما تم الإبلاغ عنه. لن يكون هذا هو المثال الأخير، ونشك في أنه مثال معزول.
احجز عرضًا توضيحيًا لنرى كيف يكشف الدخيل عن حالات التعرض قبل أن تصبح انتهاكات.
مؤلف
Sam Pizzey هو مهندس أمان في Intruder. في السابق، كان مهووسًا جدًا بالهندسة العكسية، ويركز حاليًا على طرق اكتشاف نقاط الضعف في التطبيقات عن بُعد على نطاق واسع.
برعاية وكتابة”https://www.intruder.io/?utm_source=bleepingcomputer&utm_medium=p_referral&utm_campaign=global%7Cfixed%7Cindex” الهدف=”_blank” rel=”nofollow noopener”> الدخيل.