-

Bug Hunter & CTF Player

[Omar Alzughaibi @Omarzzu]

لي فترة افكر بفكرة يكون فيه شرح للمقالات الي انزله كمقاطع قصيرة تشرح فكرة الأستغلال والثغة بشكل عام

فسويت فديو تجريبي للمقالة الأخيرة "Request Smuggling"

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

هذا الفديو عطونا ارائكم.

https://t.co/WJZpUxFO5r

[Omar Alzughaibi @Omarzzu]

Just dropped a new article! Check out how I uncovered

🔴Request smuggling that led to a JWT exposure (0-click ATO)

https://t.co/KLXmImuz8x

Enjoy the read!

#bugbounty #bugbountytips

[- @0x_itto]

@MO_SM0ker @Omarzzu الله يسعدك تسلم❤️

بالنسبه لسؤالك بعد ما استغلينا الثغره قدرنا نشوف اي ريكوست يجي بعدنا سواء كان على endpoint الـ comment او اي endpoint ثاني في الموقع

[Omar Alzughaibi @Omarzzu]

كيف ثغرة سمحت لنا ندخل حساب أي شخص؟

كيف قدرنا انا و @0x_itto نكتشف ثغرة

🔴Request Smuggling Exposes JWT — Enables 0-Click ATO!!

والي سمحت لنا نتحكم بحساب أي شخص بشكل كامل بدون أي تفاعل من المستخدم!

مسيتم بالخير جميعاً

اليوم بنتكلم عن احد الثغرات الممتعة والغريبة اللي اكتشفناها أثناء فحصنا لأحد المواقع.

من خلال استغلالنا لهالثغرة، قدرنا نوصل لحساب أي شخص بدون اي تفاعل من الشخص!

ونسمي بالله ونبدا نفصّل لكم القصة كاملة

# Request Smuggling?

بالبداية وش يعني Request Smuggling؟

قبل لا ندخل بالتفاصيل، لازم نوضح

وش يعني Request Smuggling؟ وكيف تصير؟

الحين كلنا نعرف إن الريكوست الواحد يمر على أكثر من عملية زي

- CDN
- Load Balancer
- Reverse Proxy

وهذي عبارة عن Front-End Servers

وهم باختصار السيرفرات اللي تستقبل الريكوست أول، قبل لا توصله للسيرفر الرئيسي (Back-End Server)

هالشي بحد ذاته طبيعي وممتاز وله فوائد من ناحية البنية والتطوير.

لكن المشكلة تبدأ لما الـ Front-End و الـ Back-End يفهمون/يعالجون الريكوست بطرق مختلفة

بمعنى الـ Front-End يقرأه بطريقة، والـ Back-End يفسره بطريقة ثانية.

وهنا تصير الكارثة!

ليش؟ لأن فيه سوء تفاهم بينهم، وهنا بالضبط تصير الثغرة وهذا الي نبغاه كـ bug hunters (;

فبكل اختصار، ثغرة Request Smuggling تصير بسبب نقطة وحدة

عدم التوافق بين الـ Front-end Servers (CDN, Proxy, Load Balancer) وبين الـ Back-end Server

# Discovey

في اثناء فحصنا لأحد المواقع بعد بحث قدرنا نكتشف شيء غريب نوعا ما والي هو..

لما نرسل request ونتلاعب بالـ Content-Length و Transfer-Encoding headers

ولاحظنا شيء مو طبيعي

والي هو يكون فيه تأخير بالرد والتأخير ماكان طبيعي مثل مانشوف بالصورة

الريسبونس صار يتأخر، ويعطينا Timeout، مثل ما تشوفون بالصورة.

وهالشي يوضح إن فيه اختلاف بالتعامل مع الريكوست:

والواضح ان الـ Front-end كان يستخدم Content-Length

والـ Back-end يستخدم Transfer-Encoding

ولو ما تعرف وش وظيفة هالهيدرز (Headers) ببساطة هي اللي تعرف نهاية الـ Request Body او نهاية الطلب المرسل

فبما إن كل سيرفر يتعامل معه بطريقة مختلفة، صار فيه تعارض/confusion

والنتيجة؟ ثغرة Request Smuggling

و النوع هنا (CL.TE)

يعني الـ Front-end يعتمد على Content-Length
والـ Back-end يعتمد على Transfer-Encoding

فبسبب عدم التوافق هنا بين السيرفرين للهيدزر نتج لنا الاتي

وبكذا تأكدنا انه فعلا كان فيه request smuling وخلصنا أول واهم خطوة

والان نتقل للجزء الأصعب والي هو الأستغلال

# Exploiting the smuggle to smuggle (;

الان ننتقل الى الجزء الأصعب والي هي هو الأستغلال

زي ما نعرف، استغلال الـ Request Smuggling يختلف من موقع لموقع،

ومو دايم يكون له أثر قوي، بس حنا ما وقفنا.

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

الموقع كان فيه function تسمح للمستخدمين يعلّقون على أي منشور

فجتنا فكرة... وش يصير لو حاولنا نستغل الـ request smuggling على post-comment function؟ (تعليق المنشور)

وجربنا نسوي له smuggle باستخدام نفس الـ CL.TE technique.

والصورة توضح كيف صار الاستغلال...

مثل ما تشوفون، استغلينا request smuggling على post-comment،

والـ backend استقبل الريكوست كأنه ريكوستين مفصولين.
الصفر 0 يمثل نهاية الـ request على حسب chunked format اللي يفهمه الـ backend.

فصار ريكوست post-comment معلّق في الـ backend،
وأي ريكوست يجي بعده راح يعتبره تكملة للـ request الأول،
وبكذا يدمجهم كلهم كأنه ريكوست واحد.

وش الضرر ياعمر؟

الـ request حق الضحية (اللي جا بعدنا) يطلع داخل الكومنت ،
بما فيه الـ Authorization header واللي يحتوي على الـ JWT token 🤯

يعني باختصار:
0-click Account Takeover (ATO)

وعشان نتأكد؟ نشوف الصورة هذي

باستغلالنا للـ request smuggling، قدرنا نـ smuggle أي ريكوست ينرسل بعدنا،

وبكذا نقدر نشوف الـ JWT token حق أي مستخدم يزور الموقع بعدنا بدون ما يسوي شيء!

ومن خلال ال JWT token نقدر ندخل حساب المستخدم بشكل كامل من دون أي تفاعل منه!

والي هنا وصلنا لختام المقالة اتمنى المقالة نالت على اعجابكم!

وانتظرونا للمقالة الجاية 🔥

[- @0x_itto]

How I solved The Other Side CTF https://t.co/onsh26KhKi
#فوازير_سايبر

[- @0x_itto]

How I solved Pr1v CTF https://t.co/PddxotDIKS
#فوازير_سايبر

[- @0x_itto]

How I Solved CTF Call Me https://t.co/q6yJSKcuxz
#فوازير_سايبر

[- @0x_itto]

I just completed @Pentesterlab's Recon Badge!!!

[- @0x_itto]

الصراحه CTF رهيب مرهه أكثر شيء عجبني فيه هو أنه "واقعي" مو اشياء تستغرب منها لانك مستحيل تقابلها في real website بس استفدت منه كثير وتعلمت أشياء جديده خصوصا في التحدي الثاني اللي كان ممتع مرهه #فوازير_سايبر

[- @0x_itto]

كيف قدرت احل Out of Reach CTF

اولاا الموقع كان مكون من ثلاث صفحات: login-Register-وProfile بالبداية توقعت أن الثغرة تتعلق ب JWT فجربت كل attack أعرفه على JWT لكن ماضبط معي): ضيعت وقتي كثير في هالشيء وبعدين استوعبت اني لازم اركز على شيء ثاني

[- @0x_itto]

جربت أحط 169.254.169.254 وهذا هو internal IP اللي تستخدمه AWS كـ metadata service وبكذا قدرت اجيب الفلاق 🤭

[- @0x_itto]

I just completed @Pentesterlab's yellow badge!!!

[- @0x_itto]

@Omarzzu الله يسعدك تسلم❤️

[- @0x_itto]

كيف قدرت احل تحدي Pull The Door
التحدي كان عبارة عن موقع بسيط فيه ثلاث صفحات: login-sign up-profile بعد ما تسجل الموقع يعطيك ID خاص فيك في الرابط، مثل:

profile?id=123