First Reporter: FedReporter

 

بسم الله والصلاة على رسول الله

 
نبذة بسيطة عني :

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

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

 

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

 

 

في البداية قمت يجمع المعلومات عن الهدف ( نطاقات، صفحات ، خدمات) وهكذا
اكتشفت ان لدى الهدف ثلاثة نطاقات فرعية ، وتستخدم لثلاث بنوك الكترونية تابعة لثلاث ولايات (اتلانتا،فرانسيسكو ،والفرع المركزي "نيويورك") ، هذا النطاق تحديدا يحوي على سكربت خاص يقوم بادارة خدمة العملاء ويديره الموظفين، وهو عبارة عن صفحة دخول فقط ليس هناك اي طريقة تسجيل او وسيلة فقط دخول او طلب استعادة كلمة المرور لهذا الموظف، علما ان التسجيل كان صارم جدا من قبل ادارة البنك فقط عبر ايميل خاص يتبع احد نطاقات البنك لاكثر من 120 فرع، وحصولك على هذا الايميل لا يمكن الا عن طريق فريق البنك حيث يتم حجزه واعطاءه عبر الفريق فقط ويكون تابع لاحد نطاقات البنك او فروعه ، كانت من ضمن خطط فريق الحماية لدى البنك هو ربط هذه النطاقات بنظام ايملات خاص يتبع احد فروع البنك كالتالي:

•  jhon@fed.org
• jhon@fed.at
• jhon@fed.fc

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

ناهيك انه ليس هناك اي طريقة تسجيل الكترونية فقط التسجيل واضافة ايميل لموظف عبر فريق البنك وباشراف فريق الـ IT Security وهكذا.

 

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

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

كان هذا الراس يسمى Process-Content-Value: 12345678

(ساقوم قريبا بمشاركة التكنيك المتبع الخاص بي في ايجاد مثل هذه الرؤوس الخاصة والمخفية)، من النظرة الاولى لهذا الراس تعي جيدا انه راس خاص "custom header"  تبادر الى ذهني ان هذا احد المفاتيح التي يخاطب يها التطبيق الـ back end" ،والقصد هنا هي عملية جلب محتوى تم تخزينه ويحمل القيمة على سبيل المثال 12345678 هنا يكون الرقم طويل نوعا ما ،ولكن السؤال المهم هنا كيف قام الخادم بالرد بهذا الخطأ مع العلم اني لم اقم بالتسجيل او اي عملية دخول علما ان التطبيق لا يمكن استعراض او اظهار اي محتوى او حتى الدخول على اي رابط للموقع يقوم فورا بإحالتك واعادتك الى صفحة الدخول ، وبعد البحث العميق لم اجد اي مصادر تتحدث عن هذا الراس ولكن تحليلي الاولي لهذا الراس انه لايقبل اي قيمة غير فقط ارقام افترضت هنا انه يستند على قيمة مشفرة كنوع “hexadecimal” ولا تقبل غير اي قيمة اخرى كذالك كان هناك راس يحمل الاسم data يحمل نفس الرقم لتلك الشيفرة.

عند تغييرك لاحدى تلك القيم هنا يحدث هذا الخطا عند تطابقها يحاول البرنامج في اظهار اي نقطة نهائية او صفحة ولكن في حال كونك لست logined يقوم بتحديد صلاحية الطلب ثم اعادتك لصفحة الدخول لصفحة الموظفين مطالبا ببيانات المستخدم ، حسنًا ربما الان اتضحت بعض الامور بشكل اكثر، دعونا في البداية نحاول نفهم عملية ال Processing لهذه الرؤوس من قبل الهدف،  وبما اننا هنا ليس لدينا اي معلومات او بيانات حول الكود المصدري لشيفرة التطبيق او اي معلومات نستند عليها فنحن مجبرون ان يكون اسلوبنا هنا "blackbox" فبالتالي يجب التفكير يهذا المنطق ولكن خارج الصندوق قليلًا.

حقيقة وبكل صدق لم افهم حتى اللحظة مايقوم به مطوري هذا السكربت وماذا ارادوا بادارة المحتوى بهذه الطريقة فكما قلت لكم انا مجرد هاوي ولا امتلك خبرة عالية في البرمجة مجرد اساسيات ولكن بديهيًا هنا الامر يطلب التركيز على هذا الكود ولكن دعونا نفكر جيدا انا منذ التجربة الاولى وكما اسلفت عندما استخدمت سكربتي  الخاص عبر لغة البرمجة bash script في خانة values كنت اضع لاختبار اكثر من قيمة فهناك قيمة عددية وهناك ايضا الاختبار التالي قيمة نصية فالعددية كنت آمر السكربت ان يسند الرقم 123456789 فقط كتجربة واما النصية فيسند كلمة test وهكذا دواليك ، ظهور الخطأ هنا فقط عند القيمة العددية فبالتالي استنتجت انه لايقبل هنا سوى ارقام ومن المرجع انها شفرة نوع hexadecimal فوجب علي معرفة او فهم ما الذي يقوم التطبيق باستدعائه يحوي على قيمة اثناعشرية !؟

بعد اضافة الكثير من الارقام والتجارب اكتشفت عند حدوث الخطا يكون الرد من طرف خادم اخر يحوي على تخزين سحابي كنوع CDN وفي الرد المقابل للرؤوس يظهر لي مجموعة من النطاقات “subdomain” هذه النطاقات حسب ما اتضح معي انها تتبع كامل فروع البنك وهي التي تقوم بالتخزين وادارة تلك الموارد الحيوية لكافة مواقع البنك الالكترونية من ضمنها الموقع الرئيسي.

اذا السر في صناعة هذه القيمة او هذا الهاش ، قمت بعد ذالك بعمل بحث في ارشفة الموقع لمحاولة مني التاكد من عملية "Processing" لهذه الملفات حسب مافهمته وهل نظريتي صحيحة في فهمي لسلوك التطبيق هنا ؟.

لو عدنا الى الصورة الاولى للصفحة وظهور هذا الخطأ سنلاحظ ان هناك رقم عشوائي لاي صفحة او محتوى داخل شبكة البنك هذا الرقم غالبا يكون ثايت فقط مع تغيير مسار واسم النطاق للفرع المحدد هنا ايقنت ان هذه القيمة المطلوبة في راس العمود Processions و Values المشار اليه كذالك في الراس Data.

حسنًا حتى نثبت صحة كلامي دعونا نبحث في ارشفة الموقع لجلب احدى تلك القيم المستندة في عملية عرض محتوى من قبل الخادم CDN وهل هذا صحيح ام لا هنا بعد البحث تحصلت على هذه القيم لعدد من صفحات endpoints وملفات في الموقع. 

     

 

 حسنًا هذه الارقام العشوائية هي في الاساس قيم جميعها لملفات ثابته الاختلاف فقط كما اسلفنا في امتداد الملف للنطاق التابع للفرع هنا تعبر من قبل الجانب للعميل بالتالي عند استدعائها وتخزينها من قبل جانب الخادم يقوم بقرائتها من ثم تخزينها عبر تلك القيم المعلومة من جانب الخادم كنوع hexadecimal وحتى الان هذه مجرد نظرية يجب التثبت منها لحركة وسلوك تطبيق الويب الهدف .

 

 حسنا من خلال الفلترة لمخرجات الارشفة للهدف ومسارات نقاط لانتهاء دعونا نركز على ملف او مستند غير مصرح لنا بطباعته ، حيث يقوم اطراف البنك باستدعائه دائما بكافة فروعة من داخل احد خوادم الـ CDN الثابتة، وهو عبارة عن استمارة يقوم بالعادة طباعتها احد موظفي البنك للعملاء والمراجعين وتعبئة بياناتها مع تحويل القيمة من الرقم اعلاه في المتصفح الى قيمة "hex" واسنادها الى تلك الرؤوس وسنرى النتيجة في الصورة التالية ادناه. 

 

    

 

عند طهور هذه الصفحة وعمل الخادم في الخلفية والرد علينا دون خطا يذكر كذالك دون اعادتنا الى صفحة الدخول والصلاحيات ايقنت هنا حتما ان نظريتي صحيحة تقريبا هي نفس التلاعبات التي تتم في انظمة SaaS و PaaS ولكن السؤال هنا لماذا لم تظهر محتوى الصفحة في حالنا هنا طباعة الاستمارة. الحقيقة بعد المقارنة والتحقق في الهاشات اكتشف ان قيمة الهيكس في الرؤوس تحوي على 2d وتقريبا عرفت ان التطبيق في الخلفية يقوم بإعتماد ارقام فقط مجرد حذفي لها ظهرت الاستمارة كما في الصورة التالية:

 

 

     

 نعم ياسادة لقد فعلتها، بالنظر من الوهلة الاولى لما قمنا من تحقيقه وما قمنا بعمله من سيناريو يظن البعض ان هذا الخطا مهما اختلف في مسماه الا انه عبارة عن خطا information disclosure وهو في الحقيقة ابعد من هذا حتى عندما قمت بعمل تقرير بالخطا واجهة الكثير من المشاكل مع فريق الحماية لدى البنك كذالك فريق الفرز لدى منصة H1 ولكم ان تتخيلوا اني عند ابلاغي لهذا الخطا كنت على يقين بان المشكلة اكبر من ذالك وقمت بتنبيه الفريقين قائلا لهم اني ربما استطيع بهذا السيناريو الوصول للكثير من البيانات والملفات وحتى المسارات المخزنة ومن الممكن حتى على مستوى المستخدمين والمشرفين داخل الشبكة وهذا كان رائي واصراري عليه من البداية.

 

 

 

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

 

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

 

•  عدد 75 ايميل خاص ولاكثر من فرع مع كلمات مرورها والسبب الطريقة الخاطئة ،لادارة السكربت لهذه البيانات وتخزينها

•  وصول لاكثر من مستخدم جهاز داخل البنك والحصول على بياناتهم ومساراتها تلك المستخدمين.

•  اختراق ثلاث قواعد بيانات لثلاثة فروع.

•  اوراق رسمية واستمارات مفرغة تحوي توقيع المدير العام للفرع المركزي.

اترككم مع الصور مع ملاحظة تم مسح بعض المعلومات الحساسة :

 

 

 

 

 

 

 

 

 

 الملفت في الامر ان فريق المراجعة قام باشعار فريق البنك الذي بدوره اخبر الشركة المبرمجة وفي هذه اللحظة تفاجأ الفريقين كيف استطعت طباعة هذه الاستمارة عادة لايتم الطباعة الا من داخل البنك وعبر موظفين خاصين وعلى الفور قام فريق البنك بالتخاطب معي عبر المنصة لاعيد واشرح السيناريو لهم من جديد هنا تم اعتماد هذا الخطا وتغيير الحالة الى Triaged

 

 

 

 

 

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

 

 

 

 

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

 

 

 

 

 

 

 

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

 

 

 

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

 

 

 

 

 

 

 

 

 

النهاية:

اتمنى أن قد أعجبتك اول وثيقة في موقعنا ، لإنضمام إلينا والى مجتمعنا من هنا.