في خطوة غير متوقعة، تمكنت من كشف ثغرة أمنية حرجة في نظام Paxel التابع لـ Y Combinator، والذي يستخدم لتقييم أكثر من 1.2 مليون مؤسس ومطور حول العالم. سمحت هذه الثغرة بتزوير نتائج التقييم ودفعها إلى قاعدة بيانات YC للتصنيف، بفضل غياب التحقق من صحة HMAC. والأكثر إثارة للإعجاب، أن YC استجابوا في غضون ساعتين فقط من الكشف العلني، وقام جاريد فريدمان نفسه بالإعلان عن التصحيح ودعوتي لحضور Startup School في سان فرانسيسكو هذا الصيف!
لقد قمت بإعادة كتابة هذه المقالة من مسودة سابقة كانت أقل وضوحًا. هذا الإصدار يهدف إلى تقديم القصة بتفاصيل أوضح وتنظيم أفضل، مستعرضًا رحلتي في اكتشاف هذه الثغرة وكيف قادتني إلى الانضمام لبرنامج Startup School المرموق.
بداية الرحلة: تحدي Paxel
بدأ الأمر في أوائل يونيو عندما عثرت على نموذج التقديم لبرنامج Startup School 26. هذا العام، طلبت YC من المتقدمين استخدام أداة تُدعى Paxel على أجهزتهم كجزء من عملية التقديم. كانت الأداة عبارة عن سطر أوامر بسيط يستخدم ‘curl’ لتثبيت برنامج على الجهاز، يقوم بتحليل كل سطر من التعليمات البرمجية التي كتبتها باستخدام وكيل ترميز، ثم يجمع تقريرًا ويرفعه إلى خوادم YC.
وعد الموقع الرسمي لـ Paxel بميزات مثيرة مثل ‘تصور’ عملك والحصول على سمات ممتعة. لكن فضولي دفعني لمعرفة كيف يعمل هذا النظام بالضبط. عندما يصل الفضول إلى مستوى الهوس، فإنه عادة ما ينتهي إما بفشل ذريع أو باكتشاف مذهل، وفي هذه الحالة، كان الأخير هو النتيجة.
بصراحة، أردت بشدة أن ‘أخترقه’. كنت أعلم أنني أبدأ من وضع غير مؤات في طلبي (لا أمتلك تعليمًا رسميًا من جامعات النخبة)، لكنني كنت على يقين بأن هذا سيكون طريقًا سريعًا ومؤكدًا لتأكيد قبولي. لم أكن مجرد واهم، بل أدركت أن الأمر سيكون جنونيًا إذا نجحت، لكن لم لا أجرب؟
المثير للصدمة أن أكثر من 1.2 مليون مبرمج قاموا بالفعل بتحميل تقاريرهم إلى YC عبر Paxel. أن أكون أول من يكتشف ويكسر هذا النظام كان إنجازًا حقيقيًا.
تحليل نظام Paxel
تتميز Paxel بتجربة مستخدم بسيطة للغاية، حيث يتم التعامل مع كل شيء عبر سطر واحد من الأوامر. بدأت بتحليل هذا السكريبت الخاص بالتثبيت. قمت بتقسيمه إلى وحدات منفصلة لفهم آليته.
تبين أن سكريبت التثبيت لا يعمل بمفرده. بل يقوم بتنزيل صورة Docker كاملة تستضيف تطبيق Ruby، ويقوم بفك ضغطها، وتشغيلها محليًا عبر Docker المثبت على جهاز الكمبيوتر. بالتالي، ينقسم التطبيق إلى جزأين رئيسيين:
- سكريبت التثبيت upload.sh (بحجم 302 كيلوبايت): يعالج المصادقة، ويكتشف المشاريع، ويستخرج سجل Git، ويهيئ بيئة Docker.
- تطبيق Ruby داخل صورة Docker: يدير مسار العمل الفعلي الكامل لكل مشروع.
آلية عمل تطبيق Ruby
- يجمع جميع نصوص المحادثات في وحدة عمل تسميها YC “الحلقات”. كل حلقة تمثل جميع الالتزامات (commits) وفقًا لعلاقات عامة (PRs)، أو كل التزام خلال فترة ساعتين متتالية، أو كل جلسة محادثة واحدة كحلقة فردية.
- يرفع هذه الحلقات إلى وكيل GPT-5.5 مجاني برعاية YC ومستضاف على paxel-llm.ycombinator.com (اكتشاف مثير للاهتمام).
- يستعيد ملخصًا لكل حلقة، ويدمجه مع بيانات أخرى، ثم يحمّل التقرير النهائي إلى paxel.ycombinator.com/api/v1/results.
في هذه المرحلة، اكتشفت أن كل جزء من عملي يتم تقييمه وتسجيله وتصنيفه بواسطة YC. يتم تجميع 1.2 مليون تقرير عن المبرمجين حول العالم، ويتم تقييمهم على المحاور الخمسة التالية:
- Execution_leverage (الاستفادة من التنفيذ)
- Steering (التوجيه)
- Engineering_Quality (جودة الهندسة)
- Product_thinking (التفكير المنتج)
- Planning (التخطيط)
يقوم نموذج اللغة الكبير (LLM) بتقييمك على هذه المحاور، ويخصص درجة تتراوح من 1-10، بالإضافة إلى ملاحظات نصية.
الثغرة الأمنية الكبرى: غياب توقيع HMAC
هنا وجدت أكبر نقاط الضعف. على الرغم من أن Paxel مثال جيد لتطبيق موزع/لامركزي، إلا أن هذا المسار افتقر إلى خطوة حاسمة للغاية.
وكيل LLM يُعيد رقمًا فريدًا (nonce) مع كل حلقة، ويتم مشاركة هذا الرقم بين خوادم LLM وخادم التحميل. نظريًا، يجب أن يمر هذا الرقم من LLM ─▶ إلى الجهاز المحلي ─▶ ثم إلى نقطة نهاية /v1/results، للتأكد من أن نقطة النهاية لا تقبل سوى النتائج الأصلية من LLM.
ولكن ما حدث هو أن هذا الرقم فشل في تشفير توقيع نتائج ودرجات وملاحظات LLM. على الرغم من أن الخادم تحقق من صحة الرقم (ورفض الطلبات التي تحتوي على رقم غير صالح أو مفقود)، فإن غياب التوقيع كان يعني أنه يمكن تغيير الحلقة بأكملها ونتائجها إلى أي شيء ثم تحميلها إلى YC. وقبلتها YC بالفعل!
لم يتم قبولها فحسب، بل إذا قمت بتحسين النتيجة أو تغيير الملاحظات، فإن التقرير الخاص بنفس المشروع بالضبط كان يختلف بشكل كبير، حتى لو كانت المحادثات والبيانات الأصلية متطابقة تمامًا.
أخذت الأمر خطوة أبعد وصنعت أداة أسميتها ‘Paxel-boosted’ تسمح لأي شخص بتحميل تقارير مزورة بنفس الطريقة. في غضون ساعتين فقط من إعلان YC عن التصحيح، تمكن أكثر من 20 مستخدمًا من تصنيف أنفسهم ضمن أفضل 1% عالميًا في قاعدة بيانات YC.
الإصلاح الذي تم تطبيقه
كان هناك وظيفتان أساسيتان للتشفير مفقودتين. يمكن تصنيف جميع الحقول المقبولة بواسطة /v1/results إلى ثلاث فئات:
- الحقول التي تُمرر حرفيًا من LLM إلى /v1/results: كان يجب تجميعها وتجزئتها معًا مع الـ nonce كتوقيع HMAC. هذا من شأنه التأكد من أن كل رقم nonce يرتبط فعليًا بإجابات LLM الأصلية. وهذا هو التصحيح الذي طبقته YC، تمامًا كما اقترحت.
- الحقول التي تُمرر حرفيًا من LLM إلى /v1/results ولم تُستخدم أبدًا داخل العميل: هذه الحقول كان يجب تشفيرها باستخدام تشفير EAAD (أو مفاتيح غير متماثلة عامة/خاصة) التي يمتلكها الخوادم فقط ويتم مشاركتها، بحيث لا يتمكن العميل من رؤية تفاصيل مثل درجات المحاور الخمسة وعنوان الحلقة والملاحظات. هذا الخيار اختياري ولكنه كان سيغطي أخطر التأثيرات الناتجة عن الثغرة الأمنية الأولى.
خاتمة: دعوة للمستقبل
من المحتمل أن تكون ‘نقطة الضعف’ بأكملها مجرد ‘بيضة عيد فصح’ سرية لمعرفة من يمكنه اكتشافها، أو فخًا لم يخطئ في التحقق من الصحة ولكنه كان يراقب سرًا من اكتشفها. ومع ذلك، بناءً على طبيعة نظام Paxel ومسار عمله، أرجح أن الأمر لم يكن كذلك.
الآن، بعد رد جاريد وتطبيق التصحيح، أصبحت الأداة التي طورتها لا تزال مفيدة في عرض نتائجك الأولية قبل تطبيق التصحيح. إذا كنت ستكون في سان فرانسيسكو بين 21 يوليو و6 أغسطس لحضور Startup School، فلا تتردد في التواصل معي عبر LinkedIn أو Twitter. يسعدني أن أقدم النصيحة بشأن الأماكن أو الفعاليات، وربما نجد شريكنا المؤسس التالي لنبني شيئًا يغير قواعد اللعبة.