- بواسطة x32x01 ||
لقيت دعوة جاية لك من منصة HackProve علشان تبدأ Bug Bounty Hunting على البرامج الموجودة عندهم؟ قبل ما تتحمس وتبدأ تدور على ثغرات، خليني أحكيلك عن تجربتي الشخصية مع المنصة، وإزاي اكتشفت 3 ثغرات أمنية في أحد البرامج، لكن الردود اللي وصلتني كانت أغرب من الثغرات نفسها! 😅
التجربة دي مش مجرد كلام عن مكافآت قليلة، لكن عن طريقة تقييم الثغرات، والتعامل مع الباحثين الأمنيين، ومدى الالتزام بسياسة البرنامج المعلنة.
قررت أبدأ أشتغل على برنامج تابع لشركة NINEBOT، وفعلاً قدرت أكتشف 3 ثغرات أمنية مختلفة.
المفاجأة بقى مكنتش في اكتشاف الثغرات، لكن في طريقة الرد عليها وتقييم تأثيرها الأمني.
قدمت التقرير موضحًا الثغرة وتأثيرها، لكن الرد كان إن البرنامج حاليًا بيقبل ثغرات Stored XSS فقط!
المشكلة إن سياسة البرنامج المنشورة وقتها كانت بتوضح إن Reflected XSS من أنواع الثغرات المقبولة.
يعني الثغرة كانت ضمن النطاق المعلن، لكن الرد جه بعكس المكتوب في السياسة.
بعد النقاش، تم قبول التقرير، لكن مع تصنيفه Low Severity، ومكافأة قيمتها 10 دولارات فقط.
وده رغم إن الثغرة، بحسب الاختبار اللي قدمته، كان تأثيرها بيتجاوز مجرد تنفيذ JavaScript داخل المتصفح، ويوصل للاستيلاء على حساب المستخدم.
المشكلة بالنسبة لي مكنتش في قيمة المكافأة وحدها، لكن في عدم وضوح معايير القبول والتقييم من البداية.
من خلال الاختبار، قدرت أوصل إلى بيانات شخصية للعملاء (PII)، بالإضافة إلى سجل المحادثات بالكامل بين العميل وفريق الدعم الفني.
والموضوع مكنش مجرد قراءة بيانات!
بحسب اللي قدرت أوثقه أثناء الاختبار، كان ممكن كمان إرسال رسائل داخل المحادثة المباشرة نيابة عن العميل باستخدام واجهة API مكشوفة.
معرّف العميل المستخدم في الطلبات كان بيظهر بنمط مشابه للتالي:
وده أثار مشكلة أمنية مهمة، لأن الوصول إلى محادثات العملاء أو التفاعل معاها لازم يكون مرتبطًا بالتحقق من هوية المستخدم وصلاحياته، مش مجرد الاعتماد على معرّف المحادثة.
التأثير الأمني اللي رصدته شمل:
يعني مفيش ضرر فعلي! 😂
وده كان رد مستغربه جدًا، خصوصًا إن كشف بيانات العملاء وإمكانية التفاعل مع محادثاتهم من غير الصلاحيات المناسبة يعتبر تأثيرًا أمنيًا يستحق التقييم، حتى لو مفيش ضرر مادي حصل بالفعل.
أثناء الاختبار، اكتشفت إن التلاعب بأحد HTTP Headers كان بيسمح لي بالوصول إلى مشاريع داخلية بصلاحيات Admin، بحسب النتائج اللي ظهرت أثناء التجربة.
وده نوع من المشاكل اللي المفروض يتم التعامل معاه بعناية، لأن التطبيق مينفعش يعتمد على قيمة Header قابلة للتعديل من جهة المستخدم علشان يمنحه صلاحيات إدارية من غير تحقق مناسب على السيرفر.
قدمت التقرير الثالث، لكن المفاجأة إن الرد كان مشابه جدًا للثغرة السابقة: No actual harm
للمرة التانية، تم الرد بعدم وجود ضرر فعلي، رغم إن التقرير كان بيوضح إمكانية الوصول غير المصرح به إلى موارد داخلية.
وده لعدة أسباب واجهتها بنفسي:
لكن بالنسبة لي، الوقت اللي بيقضيه الباحث الأمني في اكتشاف الثغرة، والتحقق منها، وكتابة تقرير واضح، لازم يقابله على الأقل تقييم فني مفهوم ومتسق مع سياسة البرنامج.
راجع سياسة البرنامج كويس، وشوف أنواع الثغرات المقبولة، والاستثناءات، وطريقة التعامل مع الاعتراضات، وتجارب الباحثين الآخرين إن كانت متاحة.
أما بالنسبة لتجربتي مع HackProve، فبعد اكتشاف 3 ثغرات والحصول على الردود دي، قررت إن استثمار وقتي في برامج تانية هيكون أفضل بالنسبة لي.
ولو وصلك منهم Invite، أنصحك تراجع تجارب الباحثين وسياسة البرنامج كويس قبل ما تقرر تبدأ Hunting. 😉
وفي النهاية، مشاركة التجارب دي مهمة علشان الباحثين الأمنيين يقدروا يختاروا البرامج اللي تستحق وقتهم ومجهودهم.
التجربة دي مش مجرد كلام عن مكافآت قليلة، لكن عن طريقة تقييم الثغرات، والتعامل مع الباحثين الأمنيين، ومدى الالتزام بسياسة البرنامج المعلنة.
🔍 بداية تجربتي مع منصة HackProve
بعد ما وصلتني الدعوة ودخلت أشوف البرامج المتاحة، لقيت إن الموجود وقتها 3 برامج صينية فقط، والمكافآت المعروضة كانت متواضعة نسبيًا.قررت أبدأ أشتغل على برنامج تابع لشركة NINEBOT، وفعلاً قدرت أكتشف 3 ثغرات أمنية مختلفة.
المفاجأة بقى مكنتش في اكتشاف الثغرات، لكن في طريقة الرد عليها وتقييم تأثيرها الأمني.
🚨 الثغرة الأولى: XSS تؤدي إلى Account Takeover
أول ثغرة اكتشفتها كانت من نوع Reflected Cross-Site Scripting (XSS)، وكان ممكن استغلالها للوصول إلى الاستيلاء الكامل على حساب الضحية (Full Account Takeover) بمجرد الضغط على رابط مُجهز.قدمت التقرير موضحًا الثغرة وتأثيرها، لكن الرد كان إن البرنامج حاليًا بيقبل ثغرات Stored XSS فقط!
المشكلة إن سياسة البرنامج المنشورة وقتها كانت بتوضح إن Reflected XSS من أنواع الثغرات المقبولة.
يعني الثغرة كانت ضمن النطاق المعلن، لكن الرد جه بعكس المكتوب في السياسة.
ماذا حدث بعد الاعتراض على القرار؟
قررت أعترض على التقييم وأطلب وساطة (Mediation)، ووضحت إن رفض التقرير مش متوافق مع سياسة البرنامج المنشورة.بعد النقاش، تم قبول التقرير، لكن مع تصنيفه Low Severity، ومكافأة قيمتها 10 دولارات فقط.
وده رغم إن الثغرة، بحسب الاختبار اللي قدمته، كان تأثيرها بيتجاوز مجرد تنفيذ JavaScript داخل المتصفح، ويوصل للاستيلاء على حساب المستخدم.
المشكلة بالنسبة لي مكنتش في قيمة المكافأة وحدها، لكن في عدم وضوح معايير القبول والتقييم من البداية.
🔓 الثغرة الثانية: كشف بيانات العملاء ومحادثات الدعم الفني
الثغرة التانية كانت متعلقة بواجهة API خاصة بخدمة المحادثات والدعم الفني.من خلال الاختبار، قدرت أوصل إلى بيانات شخصية للعملاء (PII)، بالإضافة إلى سجل المحادثات بالكامل بين العميل وفريق الدعم الفني.
والموضوع مكنش مجرد قراءة بيانات!
بحسب اللي قدرت أوثقه أثناء الاختبار، كان ممكن كمان إرسال رسائل داخل المحادثة المباشرة نيابة عن العميل باستخدام واجهة API مكشوفة.
معرّف العميل المستخدم في الطلبات كان بيظهر بنمط مشابه للتالي:
Requester1767570027461وده أثار مشكلة أمنية مهمة، لأن الوصول إلى محادثات العملاء أو التفاعل معاها لازم يكون مرتبطًا بالتحقق من هوية المستخدم وصلاحياته، مش مجرد الاعتماد على معرّف المحادثة.
التأثير الأمني اللي رصدته شمل:
- كشف بيانات شخصية خاصة بالعملاء (PII).
- الوصول إلى سجل محادثات الدعم الفني.
- الاطلاع على المعلومات المتبادلة بين العميل وفريق الدعم.
- إمكانية إرسال رسائل داخل المحادثة نيابة عن العميل.
يعني مفيش ضرر فعلي! 😂
وده كان رد مستغربه جدًا، خصوصًا إن كشف بيانات العملاء وإمكانية التفاعل مع محادثاتهم من غير الصلاحيات المناسبة يعتبر تأثيرًا أمنيًا يستحق التقييم، حتى لو مفيش ضرر مادي حصل بالفعل.
🛡️ الثغرة الثالثة: الوصول إلى مشاريع داخلية بصلاحيات Admin
الثغرة الثالثة كانت مرتبطة بالتحكم في الصلاحيات (Access Control).أثناء الاختبار، اكتشفت إن التلاعب بأحد HTTP Headers كان بيسمح لي بالوصول إلى مشاريع داخلية بصلاحيات Admin، بحسب النتائج اللي ظهرت أثناء التجربة.
وده نوع من المشاكل اللي المفروض يتم التعامل معاه بعناية، لأن التطبيق مينفعش يعتمد على قيمة Header قابلة للتعديل من جهة المستخدم علشان يمنحه صلاحيات إدارية من غير تحقق مناسب على السيرفر.
قدمت التقرير الثالث، لكن المفاجأة إن الرد كان مشابه جدًا للثغرة السابقة: No actual harm
للمرة التانية، تم الرد بعدم وجود ضرر فعلي، رغم إن التقرير كان بيوضح إمكانية الوصول غير المصرح به إلى موارد داخلية.
💰 هل أنصح الباحثين الأمنيين بالعمل على HackProve؟
بناءً على تجربتي الشخصية، مش هقدر أرشح منصة HackProve للباحثين الأمنيين اللي بيدوروا على تجربة واضحة من ناحية تقييم الثغرات والمكافآت.وده لعدة أسباب واجهتها بنفسي:
- اختلاف التعامل مع ثغرة Reflected XSS عن سياسة البرنامج المنشورة وقت تقديم التقرير.
- تصنيف ثغرة XSS ذات التأثير المبلغ عنه كـ Low Severity بعد الاعتراض.
- منح مكافأة 10 دولارات فقط للتقرير الأول.
- الرد على تقريرين أمنيين مختلفين بعبارة No actual harm، رغم التأثيرات اللي تم توضيحها في التقارير.
لكن بالنسبة لي، الوقت اللي بيقضيه الباحث الأمني في اكتشاف الثغرة، والتحقق منها، وكتابة تقرير واضح، لازم يقابله على الأقل تقييم فني مفهوم ومتسق مع سياسة البرنامج.
📌 الخلاصة: اقرأ سياسة الـ Bug Bounty قبل ما تبدأ
لو ناوي تبدأ Bug Bounty Hunting على منصة جديدة، متبصش للمكافآت أو أسماء الشركات المشاركة وبس.راجع سياسة البرنامج كويس، وشوف أنواع الثغرات المقبولة، والاستثناءات، وطريقة التعامل مع الاعتراضات، وتجارب الباحثين الآخرين إن كانت متاحة.
أما بالنسبة لتجربتي مع HackProve، فبعد اكتشاف 3 ثغرات والحصول على الردود دي، قررت إن استثمار وقتي في برامج تانية هيكون أفضل بالنسبة لي.
ولو وصلك منهم Invite، أنصحك تراجع تجارب الباحثين وسياسة البرنامج كويس قبل ما تقرر تبدأ Hunting. 😉
وفي النهاية، مشاركة التجارب دي مهمة علشان الباحثين الأمنيين يقدروا يختاروا البرامج اللي تستحق وقتهم ومجهودهم.
- بواسطة x32x01 ||
بما إنهم بيقولوا إنه «مفيش ضرر فعلي»
فده رابط الـ API اللي بيكشف البيانات الشخصية للعملاء (PII)، أهو لو حد شايف إنه ممكن يستفيد منه.
https://dms-cc-us.segway-ninebot.co...oryMessages?customerId=Requester1767570027461
فده رابط الـ API اللي بيكشف البيانات الشخصية للعملاء (PII)، أهو لو حد شايف إنه ممكن يستفيد منه.
https://dms-cc-us.segway-ninebot.co...oryMessages?customerId=Requester1767570027461