يمكن إسناد كتابة الكود للذكاء الاصطناعي، لكن من يُؤتمن على أمان أسماء النطاقات؟

بقلم: ياجين

في 31 أكتوبر، تم اختراق مواقع أكثر من عشرة مشاريع DeFi تباعًا. أحد المشاريع المتضررة، Kintsu، نشر على X[1] أن نطاقه الذي تم شراؤه عبر Vercel تعرض للاختراق على مستوى المسجل. هناك مصطلحان رئيسيان في هذا البيان: أحدهما Vercel، والآخر هو المسجل. لنبدأ بـ Vercel.

Vercel هي منصة لنشر المواقع الإلكترونية. يقدم المطورون الكود الذي كتبوه إليها، وتتولى هي بناء الموقع وإطلاقه، ثم توصيل صفحات الويب للمستخدمين عبر خوادم موزعة حول العالم. Vercel هي أيضًا الشركة التي تقف وراء إطار العمل الأمامي Next.js[2]، الذي يحظى بشعبية كبيرة بين المطورين، ومعظم المشاريع المذكورة هذه المرة تستضيف صفحاتها على Vercel. بالإضافة إلى استضافة المواقع، تبيع Vercel أيضًا النطاقات، مما يتيح للمستخدمين شراء النطاقات وإدارة إعدادات DNS من نفس الواجهة الخلفية.

من البيانات التي وجدناها، لم يتم تعديل كود هذه المشاريع المستضافة على Vercel؛ ما تغير هو المكان الذي يشير إليه النطاق.

هذه الحادثة تستحق اهتمام كل مزود خدمة تطبيقات، وخاصة مزودي خدمات الأصول الرقمية. في العامين الماضيين، انتشرت البرمجة بالذكاء الاصطناعي (vibe coding)، والتي تتضمن وصف المتطلبات باللغة الطبيعية والسماح للذكاء الاصطناعي بكتابة البرنامج. هذا يخفض بشكل كبير عتبة تطوير التطبيقات: مع كتابة الذكاء الاصطناعي للكود، وتقديمه إلى منصات النشر مثل Vercel أو Netlify أو Cloudflare للإطلاق بنقرة واحدة، وشراء نطاق على المنصة، يمكن الحصول على موقع لائق في بضع دقائق فقط.

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

01 كيف يتم العثور على عنوان URL

الآن دعونا ننظر إلى ما أشار إليه Kintsu بـ "المسجل". لفهم ما يفعله المسجل، نحتاج أولاً إلى معرفة كيف يتم العثور على عنوان URL. يمكننا التفكير في موقع الويب كمتجر. اسم النطاق هو اسم المتجر، مثل example.com؛ وعنوان IP للخادم هو رقم الشارع للمتجر. المستخدمون يتذكرون اسم المتجر فقط، لذا يحتاج شخص ما إلى ترجمة اسم المتجر إلى رقم الشارع، وتسمى عملية الترجمة هذه "تحليل النطاق".

تتضمن عملية الترجمة ثلاثة أدوار.

السجل (Registry) يعمل كمكتب تسجيل مركزي. كل نوع من اللواحق له سجل خاص به، مثل .com و .xyz و .finance وغيرها. السجل يتذكر شيئًا واحدًا فقط: أين يقع "مكان السؤال" لنطاق معين.

المسجل (Registrar) يعمل كوسيط يقوم بالمهام نيابة عن المستخدمين. لا يمكن للأشخاص العاديين الذهاب مباشرة إلى السجل للتسجيل؛ يجب أن يمروا عبر مسجل لشراء نطاق أو تجديده أو تعديل معلومات التسجيل. يمكن للمستخدمين تحديد "مكان السؤال" المسؤول عن نطاقهم في واجهة المسجل الخلفية.

خادم الأسماء (Nameserver) هو "مكان السؤال". لديه جدول يحدد أي اسم متجر يتوافق مع أي رقم شارع. كل صف في هذا الجدول يسمى سجل تحليل. عندما نتحدث عن "تغيير التحليل"، فإننا نشير إلى تغيير هذا الجدول على خادم الأسماء.

بعد أن يدخل المستخدم عنوان URL في المتصفح، يسأل المتصفح أولاً السجل المركزي: أين مكان السؤال لهذا المتجر؟ ثم يسأل مكان السؤال: ما هو رقم الشارع؟ أخيرًا، يجد المتجر وفقًا لرقم الشارع ويفتح صفحة الويب.

المتصفح يسأل أولاً السجل، ثم خادم الأسماء، وأخيرًا يجد المتجر برقم الشارع.

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

طريقتان: تغيير الجدول في مكان السؤال، أو استبدال مكان السؤال بالكامل بمكان يسيطر عليه المهاجم.

02 من يدير النطاق الذي تم شراؤه بنقرة واحدة

بفهم السجل والمسجل وخادم الأسماء، يمكننا الآن النظر إلى منصات النشر مثل Vercel. منصات النشر مسؤولة عن تشغيل البرامج المكتوبة عبر الإنترنت. لتسهيل الأمور على المستخدمين، قامت العديد من منصات النشر بدمج شراء النطاقات وإدارة DNS في واجهتها الخلفية، مما يسمح للمستخدمين بالتفاعل فقط مع المنصة من شراء النطاق إلى إطلاق الموقع.

ومع ذلك، خلف المنصة، لا تزال جميع الأدوار المذكورة سابقًا موجودة. بعض المنصات هي مسجلون بحد ذاتها، بينما تعمل أخرى نيابة عن المستخدمين للعثور على مسجلين؛ Vercel تنتمي إلى الفئة الأخيرة. تحققنا من نطاق Kintsu، والمسجل المدرج في السجل هو Name.com، وليس Vercel نفسها.

هذا النهج "الشامل" مريح للغاية، لكن الجانب السلبي هو أن المستخدمين غالبًا لا يعرفون أن نطاقهم له مسجل ومن غير المرجح أن يهتموا بالأمان على مستوى المسجل. بالنسبة لـ Vercel، في واجهتها الخلفية وواجهتها[3]، يمكن تعديل خادم الأسماء، ويمكن أيضًا الحصول على رمز التفويض لنقل النطاق. بمعنى آخر، من يحمل حساب المنصة أو أذونات واجهتها يمكنه تغيير توجيه النطاق أو حتى نقل النطاق بعيدًا.

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

في عصر الذكاء الاصطناعي، أصبحت "النقرة الواحدة" "صفر نقرة". أداة سطر الأوامر الخاصة بـ Vercel[4] تدعم الآن البرامج النصية ومساعدي الذكاء الاصطناعي لشراء وتجديد النطاقات دون تدخل بشري. توفر Vercel أيضًا واجهة MCP لمساعدي الذكاء الاصطناعي (طريقة قياسية لمساعدي الذكاء الاصطناعي لاستدعاء الأدوات الخارجية)، مع 28 أداة متعلقة بالنطاقات وDNS[5]. هذا يعني أنه عندما يخبر المطور الذكاء الاصطناعي، "ساعدني في إطلاق الموقع وإعداد نطاق"، يمكن للذكاء الاصطناعي التعامل مع شراء النطاق وتغييرات التحليل نيابة عنه.

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

في جملة واحدة، أكمل الذكاء الاصطناعي شراء النطاق وإعداد التحليل للمطور.

03 أين أجرى المهاجم التغييرات

وفقًا للتقارير العامة[6]، في 31 أكتوبر، ارتفع عدد المواقع المستهدفة إلى أكثر من عشرة. بالإضافة إلى Kintsu، هناك مشاريع DeFi مثل StonkFun و Pickle و Echelon و Origami و Fluxbeam و Stakepoint و SupSwap و Longbow و SHPRD و ApeX DeFi.

معلومات تسجيل النطاق عامة، ويمكن لأي شخص الاستعلام عنها. تحققنا من نطاقات 11 من هذه المشاريع ووجدنا أن جميع مسجليها هم Name.com، مع وجود تعديلات في السجل لـ 7 منها في 31 أكتوبر. حتى الساعة 6 مساءً بتوقيت بكين في 31، كانت 5 نطاقات لا تزال تشير إلى خوادم المهاجمين.

استخدم المهاجمون الطريقتين المذكورتين سابقًا. pickle.finance[7] و stakepoint.app لا يزال لديهما جدول على خادم أسماء Vercel يسرد عنوان خادم Vercel الخاص، مما يشير إلى أن مكان السؤال الأصلي كان يجب أن يكون على Vercel؛ ومع ذلك، تم تغيير مكان السؤال المسجل في السجل إلى خادم أسماء Name.com حوالي الساعة 1 صباحًا بالتوقيت العالمي في 31، مع رقم الشارع الجديد 31.56.52.52.

في حالة أخرى، fluxbeam.xyz و supswap.xyz و apexdefi.xyz كان مكان السؤال الأصلي لديهم في Name.com، ولم يتغير تسجيل السجل منذ فبراير أو مايو من هذا العام، ومع ذلك فإن الجدول في مكان السؤال الآن يسرد أيضًا رقم الشارع 31.56.52.52، مما يشير إلى أن الجدول نفسه تم تعديله. هذا العنوان مسجل تحت شركة تدعى Snowcore[8]، ونطاق IP مسجل في هولندا، ولا علاقة له بـ Vercel.

عناوين URL لمشاريع مختلفة تم توجيهها جميعًا إلى نفس العنوان الذي يسيطر عليه المهاجم.

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

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

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

04 المفاتيح ليست مجرد كلمات مرور

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

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

هناك طرق أكثر لتسريب الرموز مما يدركه الكثيرون:

• كتابتها في الكود أو ملفات التكوين. إذا تم كتابة رمز في الكود، أو تقديمه إلى مستودع عام، أو حزمه في الواجهة الأمامية، يمكن لأي شخص رؤيته.

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

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

• الوصول إلى الإضافات والتكاملات المختلفة. في كل مرة يتم فيها دمج خدمة طرف ثالث، يوجد مكان آخر للاحتفاظ بالمفاتيح.

الرموز التي يمكنها تغيير أسماء النطاقات قد تتسرب من هذه الأماكن.

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

05 لماذا تعتبر المواقع التي تتضمن أصولًا مخترقة خطيرة بشكل خاص

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

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

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

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

مهما كانت الأنظمة الخلفية والعقود محكمة، طالما تم اختراق حلقة واحدة في هذا المسار، سيسلم المستخدمون أصولهم على صفحة مزيفة.

06 توصيات لمزودي خدمات التطبيقات ومزودي خدمات الأصول الرقمية

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

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

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

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

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

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

07 كلما كان الإطلاق أسهل، زادت الحاجة إلى معرفة من يحمل المفاتيح

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

هذه المراحل غالبًا غير مرئية ونادرًا ما يتم التفكير فيها، لكن في نظر المستخدمين، هي جزء من الخدمة تمامًا مثل الكود الذي كتبه مزود الخدمة. إذا فشلت أي حلقة، سيحمل المستخدمون مزود الخدمة المسؤولية.

بينما تقوم الأدوات بالمزيد نيابة عنا، هل ما زلنا نفهم بوضوح أي المفاتيح سلمناها؟