استخدام كلود لتقليل سطح الهجوم في الشيفرة البرمجية

كريس رولف

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

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

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

طرق تقليل سطح الهجوم في قواعد الشيفرة البرمجية

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

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

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

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

أردنا أن نفهم مدى قدرة Claude على استخدام هذه الأوصاف الثلاثة لسطح الهجوم لاكتشاف مشكلات حقيقية في قواعد أكواد كبيرة ومعقدة. قمنا بتحليل 25 مشروعًا مفتوح المصدر (تمثل أكثر من خمسة ملايين سطر من التعليمات البرمجية)، مكتوبة بلغات تشمل C وC++ وJava وPHP وPython. أنشأ Claude قائمة جرد تضم أكثر من 17,000 خيار تهيئة عبر هذه المشاريع. ومن بينها، ارتبط 3,842 بتهيئة عنصر تحكم أو ميزة ذات صلة بالأمان.

لأغراض بحثنا، قسمنا مشاريع المصادر المفتوحة هذه إلى ثلاث فئات واسعة:

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

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

نتائج Claude

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

أولًا، وجد Claude أن جميع المشاريع الإحدى عشرة المقيّدة (gated) كانت تحتوي على شيفرة يمكن الوصول إليها دون قصد (رغم أن هذه الشيفرة لم تكن نسبة كبيرة من إجمالي أسطر الشيفرة في أي من تلك المشاريع). وتحديدًا، اكتشف Claude 93 سطح وصول غير ضروري قبل المصادقة في الإعداد الافتراضي لمجموعة المشاريع المقيّدة، و37 موقعًا تُنفَّذ فيه الشيفرة أو يُسجَّل فيه الحالة قبل المصادقة، و61 تركيبة إعداد تُضعف بصمت ضبطًا أمنيًا قبل المصادقة قام به المسؤول. لم تكن أي من هذه المشكلات قابلة للاستغلال الفوري من تلقاء نفسها، لكنها تُنشئ سطح هجوم أكبر بكثير من الضروري.

ثانيًا، أنتج عمل Claude في التخفيف من مشكلات تفاعل الإعدادات بعضًا من أكثر النتائج إثارة للاهتمام وتأثيرًا (عبر جميع أنواع المشاريع). عثر Claude على 162 تركيبة إعداد حساسة أمنيًا تم قبولها دون خطأ أو تحذير ودون أي توثيق للسلوك المتوقع لتفاعلها. وفي 94 من تلك الحالات، أوقف التركيبة ضبطًا أمنيًا بصمت. أما الحالات الـ 68 الأخرى فكانت تتعارضات في آليات الأمان ذاتها (مثلًا: بقاء مستمع أو مسار تسجيل دخول قابلًا للوصول رغم أن الإعداد يشير إلى أنه معطّل؛ أو تعارض إعدادين ويكون الإعداد ذو الأولوية هو ما يعتمد على ترتيبهما في ملف الإعدادات؛ أو حماية قام بضبطها المسؤول لا تفعل شيئًا بينما تظل شفرتها قابلة للوصول). ورغم أن بعض هذه التركيبات الإعدادية قد يكون غير قياسي أو نادر الاستخدام، لا شيء يمنع مسؤول هذه المشاريع من إعداد الشيفرة ونشرها بهذه الطريقة.

كما عثر Claude على نمط محدد ظهر بشكل مستقل في أربعة مشاريع غير مرتبطة ببعضها. ويعمل هذا النمط كما يلي: يكتب المسؤول قاعدة وصول للعملاء عن بُعد باستخدام اسم مضيف أو نمط بدل (wildcard pattern) بدلًا من عنوان IP. وعند اتصال عميل، يقارن الخادم تلك القاعدة باسم مضيف العميل. وما إذا كان الخادم قد تعرّف على اسم المضيف من الأساس يتوقف على خيار منفصل يتحكم في عمليات البحث العكسي عن DNS (والتي كانت معطلة في إعدادات معظم المشاريع). وبما أن عمليات البحث معطلة، يكون لدى الخادم عنوان IP الخاص بالعميل فقط، ويقارن القاعدة بهذا العنوان كنص عادي. لكن نمط اسم المضيف لا يمكن أبدًا أن يطابق عنوان IP. وهذا يعني أن قاعدة الرفض لن تُفعَّل أبدًا، وبالتالي تفشل القائمة في وضع مفتوح (fail open). تذكر بعض المشاريع المتأثرة في وثائقها أن قواعد أسماء المضيفين تعتمد على تمكين عمليات البحث في DNS، لكن لا أحد منها ينص على أن قائمة رفض مكتوبة بهذه الطريقة ستكون لها سلوكية الفشل المفتوح.

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

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

دراسة حالة: OpenSSH

والمفاجئ أن المشروع الذي حقق كلود أكبر انخفاض في سطح الهجوم، عند قياسه كنسبة مئوية من إجمالي أسطر الكود، كان OpenSSH. OpenSSH هو قاعدة كود بلغة C عالية الجودة توفر وصولاً بعيدًا آمنًا. تتبّع كلود مسارات الإدخال لخدمة SSH في إصدار 10.4 ووجد ما يقارب 4,500 سطر من الكود الجديد والتجريبي لخوارزمية ML-DSA-44، وهي خوارزمية توقيع ما بعد الكم، يمكن لعميل غير مُصادق الوصول إليها في الإعداد الافتراضي. خوارزمية ML-DSA غير مفعّلة افتراضيًا، لكن الكود كان قابلًا للوصول على أي حال، حتى عندما يستبعد المسؤول الخوارزمية صراحةً. كانت الخدمة تحلل نوع المفتاح الذي يرسله العميل أيًا كان (وفي حالة الشهادات، كانت تتحقق أيضًا من توقيع CA المضمّن). وبعد ذلك فقط كانت تتحقق مما إذا كان نوع المفتاح هذا مسموحًا. لا يوجد سبب وجيه لكي يكون هذا الكود المعقد غير الآمن من حيث الذاكرة قابلًا للوصول عندما لم يتم تفعيله في الإعدادات. تلك الـ4,500 سطر من كود ML-DSA-44 تمثل حوالي 16% من كود ما قبل المصادقة الخاص بـOpenSSH نفسه في sshd افتراضي. أبلغنا مطوري OpenSSH بذلك مع تصحيحات. نقل إصدار 10.5 الفحص إلى ما قبل التحليل.

ثم لاحظ كلود ثغرتين في فحص الإصدار 10.5. الأولى كان عدم تطابق بين ما ادّعاه العميل وما أرسله فعليًا. كان الفحص ينظر إلى اسم الخوارزمية المعلن عنه من العميل، لكن المحلل كان يُختار بناءً على سلسلة نوع مضمّنة داخل كتلة المفتاح. يمكن للعميل أن يعلن عن ssh-ed25519، وينجح في الفحص، ثم يرسل مع ذلك مفتاح ML-DSA سيتم تحليله.

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

أزال هذا الإصلاح ما يقارب خُمس كود OpenSSH الذي كان بإمكان عميل غير مُصادق الوصول إليه سابقًا في بناء افتراضي. وكان تقريبًا كل ذلك هو كود ML-DSA الجديد، الذي أصبح الآن غير قابل للوصول حتى لعميل يكذب بشأن نوع مفتاحه أو يخفي مفتاح CA من نوع ML-DSA داخل شهادة مقبولة فيما عدا ذلك. لا تزال الشهادات الموقعة بخوارزمية CA مسموح بها تُحلَّل وتُتحقَّق، لكن الفحص يجري الآن قبل التحليل. أصدر المشرفون التغييرات الموصوفة هنا في الإصدار 10.6.

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

الخلاصة

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

لقد جمعنا تقنيات تقليل سطح الهجوم التي وصفناها أعلاه في مهارة Claude واحدة قابلة لإعادة الاستخدام، ونعمل على دمجها في OSS-Scanner. تجري المهارة ثلاث جولات على قاعدة الكود. تبدأ كل جولة من جديد (بنافذة سياق فارغة)، باستثناء قطعة سياق قصيرة تتلقاها من الجولة السابقة.

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

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

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