WebDe A222

Developer, PenTester |
#eCPPT #eJPT #eWPT

[Abdulaziz @stuipds]

We have released a detailed research of our time focusing on Unifi Applications.

The research include Several SQL Injections, OS command Injection, and Path Traversal that awarded us over $42,000.

Hope you enjoy reading it !

https://t.co/0mWiWGsg1g

[مقرراتي | Moqraraty @moqraraty]

مواد الترم الأول نزلت في مقرراتي 🔥

سواء توّك تبدأ الجامعة أو راجع لترم جديد، أضف أرقامك المرجعية ورتّب جدولك من بدري.

https://t.co/rEpstcpzxk

[Black Hat MEA @Blackhatmea]

أكبر ساحة لاختبار قدراتك السيبرانية بانتظارك
سجل في منافسات التقط العلم 🚩 ضمن #BHMEA26 ، وانضم إلى نخبة العقول السيبرانية في واحدة من أكبر ساحات التحدي

سجل الآن: https://t.co/fEkhVyQXOu

[James Kettle @albinowax]

We've launched a new @WebSecAcademy topic on exploiting AI-powered security scanners! Learn how to use indirect prompt injection to steal data, cause damage & trigger exploit chains!

[Het Mehta @hetmehtaa]

OWASP just dropped APTS

A governance standard for autonomous pentesting platforms.

Not a methodology.
A control layer.

Focus: scope enforcement, safe autonomy, manipulation resistance, accountability.

As AI-driven testing scales, this is the guardrail the industry needed.

https://t.co/QWqzCANA6N

[Cloudflare Developers @CloudflareDev]

Introducing the new /crawl endpoint - one API call and an entire site crawled.

No scripts. No browser management. Just the content in HTML, Markdown, or JSON.

[Hack The Box @hackthebox_eu]

Don’t chase every bug. Go after the ones that sting 🐝
The @owasp Top 10 2025 Track just dropped on HTB Labs and HTB Enterprise Platform! You’ll tackle 10 hands-on web app Challenges, mapped to the latest OWASP Top 10 risks, with difficulties from Very Easy to Medium.

You’ll practice spotting the weak points, turning findings into real exploits, and building the mindset you need to assess modern web apps the way attackers do.
Jump in, clear the track, and sharpen the skills that actually show up in real-world testing: https://t.co/WKrSagPGQw

#HackTheBox #OWASPTop10 #WebAppSec #AppSec #PenTesting #EthicalHacking #RedTeam

[مقرراتي | Moqraraty @moqraraty]

الترم الثاني بدأ… رتّب جدولك بسرعة🔥

Google Play: https://t.co/Tcl6KtbhnM
App Store: https://t.co/JvyUXLZrA6

[Omar Alzughaibi @Omarzzu]

كيف قدرنا نكتشف ثغرة؟

🔴Chaining Fortinet WAF Bypass and Microservice Architecture Exploitation to Compromise 6+ Internal Domains

With @Mohnad @stuipds

مساكم الله بالخير جميعا , مقالة اليوم عن استغلال عدة ثغرات وصلنا من خلاله بتحكم كامل على احد اكبر الشركات

- بيانات +40 ألف موظف وشركات متعاقدة (بكامل التفاصيل)

- فصل أي موظف وإغلاق بصمة الوجه وبطاقات الدخول للفروع

- Fortinet WAF bypass through path Confusion

- Microservice Compromise Lateral Movement to 10+ Internal Domains

# البداية

في بداية فحصنا طلعنا عدة ثغرات، وبعد وقت من الفحص صادفنا Error

والواضح من الخطأ إنه قاعد يستقبل الـ username كبراميتر ويحطه بالـ URL path الى Internal domain

فالي قاعد يصير إنه يستقبل المدخل من المستخدم،
والـ front-end API يرسل طلب

والـ back-end API يأخذ القيمة ويحطه بالمسار، ومن خلاله يرجّع معلومات المستخدم.

وبديهي أول سؤال بيجي ببالك هل ممكن نشوف معلومات شخص آخر؟

والإجابة ايه بمجرد ما نسوي path traversal راح نتخطى عملية التحقق الي تكون من ال front-end API ونجيب معلومات أي مستخدم بشكل كامل

لكن هذا ما يهمنا، كان هدفنا الأساسي إننا نوصل إلى Internal domain

وبعد عدة محاولات، توصلنا إلى إننا نوصل إلى مسار داخلي ويحتوي على Swagger Documentation تحتوي على مسارات لأكثر من عملية.

ومن خلال المسارات اللي وصلنا لها، قدرنا نطلع ثغرات حرجة وكثيرة جدًا، مثل ما راح نستعرض لكم الحين (;

[نادي أمن المعلومات @CCISinfosecclub]

🥁🥁🥁
بعد منافسة حماسية وإبداع مبهر من المشاركين في مسابقتنا 💪
يسعدنا نعلن عن الفائزين 🎯!
مبروووك للفائزين! 👏👏
وشكر كبير لكل من شارك وأبدع — وجودكم هو سر نجاحنا 💙
ترقبوا فعالياتنا القادمة… الجايات أقوى بإذن الله 🚀
#امن_المعلومات #CTF @CCIS_IMAMU @TuwaiqClubs

[Rakan Al-Tome @rxx2me]

📝 WALLS Crypto Challenge Write-up

شكراً للمنظمين على المسابقة الرائعة والتحديات القيمة 💙

🔗 https://t.co/Ni9ZbIoRtU

#InfoSec_CTF #CTF #CyberSecurity #WriteUp

[نادي أمن المعلومات @CCISinfosecclub]

الوقت : 25 اكتوبر - (12ظهرًا-7م)
الموقع: عن بعد
عدد القروب: 3-4 اعضاء
ينتهي التسجيل : يوم الاربعاء 22 اكتوبر - 11:59م
والسحب راح يكون عن طريق الهاشتاق #infosec_CTF متحمسين نشوف ابداعاتكم🤩!
@CCIS_IMAMU @TuwaiqClubs
#CTF
https://t.co/1M1WgoFV3G

[WebDe A222 @WebDeA222]

@SAlobaylan الله يبارك فيك صالح،
الصدق إلى الآن مدري، فالغالب بترك ine شوي و بجرب شي جديد مثل crtp اوcbbh

[WebDe A222 @WebDeA222]

ال��مدلله 🙏

#eCPPT #ine #eCPPTv3

[Nasser Albarrak @nass3r000]

من ثغرة بسيطة الى وصولي للشبكة الداخلية لجهة كبير

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

قلت خلني امخمخ عليه، يمكن احصل شي…

بديت أختبرها بتكنيكات بسيطة، فا جربت HTML Injection بكود بسيط بصفحة البروفايل:

<h1>Test</h1>

وفعلاً… تفاجأت إن الكود اشتغل وانطبع كـ H1 داخل ملف الـ PDF

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

🔴 محاولة الوصول لمواقع داخلية للجهة 🔴

هنا جاتني فكرة اني احاول اوصل لمواقع داخلية مثل localhost لكن اول ما جربته ط��ع لي 403

حاولت اسوي fuzzing بس ما نفع كلهم يعطوني نفس النتيجة 403، وجربت اسوي brute force للبورتات لكن برضو ماضبطت

وقتها قلت خلني اسوي wordlist فيها كل ال internal ips لعلي اوصل لموقع داخلي

بعد ما بديت أجرب، واجهتني مشكلة إن الموقع ياخذ تقريبًا ٣ دقايق عشان يرد إذا الـ IP غير شغال. وأنا عندي لستة كبيرة فيها عدد كبير من الـ IPs، فا لما جربتهم بشكل سريع الموقع علق وصار بطيييء جدًا، فالفكرة ما كانت عملية نهائيًا.

فجتني فكرة ثانية، قلت خلني اعرف السيرفر اللي يسوي generate للـ pdf، فا حطيت رابط burp collaborator داخل iframe، وفعلًا قدرت احصل ip السيرفر:

ومن هنا قدرت اطلع الـ subdomain المرتبط بالـ ip
(https://t.co/qspGONMEop):

لاحظت ان الدومين مختلف لكن لنفس الجهة، ومربوط داخليًا وما اقدر اوصله من جهازي.

🔴 اكتشاف باقي الخدمات الداخلية 🔴

سويت Subdomain Enumeration على نفس الدومين القديم، وطلعت لي لستة كبيرة من السب دومينز. لاحظت إن بعضهم أقدر أوصل ل�� من جهازي، وبعضهم لا. فقلت الفلترة هي الحل..

فلترت السب دومينز اللي “ما أقدر” أوصل لهم، لان غالبًا السيرفر اللي يسوي الـ PDF يقدر يوصلهم بما إنهم داخل نفس الشبكة.

جربت السب دومينز واحد واحد، والمفاجأة كانت ٤ منهم اشتغلوا !

لكن كانت تطلع لي صفحة بيضاء.. مافيها شي يذكر 🫠

🔴 الوصول لمواقع داخلية للجهة🔴

فا جت فكرة ببالي طالما اني قدرت اوصل للمواقع فا معناها فعليًا فيه موقع شغال فا ليش ما اجرب اسوي fuzzing بعد الsubdomains

https://t.co/eLFg9Q4aL3

وفعلًا ضبط معاي، وقدرت اوصل للصفحات التالية:

- نظام ال Login الداخلي للموظفين
- صفحة تحتوي على بيانات الاقسام بالعناوين وأرقام الجوال
- Internal API documentation
- Control panel website

طبعًا اقدر اسوي استغلال اكثر، ولكن في حالتي كان اللي وصلت له كافي لأثبات خطورة الثغرة.

وبالنهاية، شكرًا لكم على وقتكم وقراءتكم…

[Omar Alzughaibi @Omarzzu]

Session-Based Validation Bypass via Trusted Parameter Override

🔴GET /v1/user/profile/userDetails → Pulls my data based on my JWT session token.

🔴GET /v1/user/profile/userDetails?userId=victim-id
→ The app ignores the session and trusts the userId param which leads to exposing victim’s data

The logic prioritizes userId from the request over the authenticated session, leading to session confusion and broken access control.

#bugbountytips #websecurity

[Omar Alzughaibi @Omarzzu]

كيف قدرت اخترق واتحكم سيرفر جهة حساسة بشكل كامل.

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

طبعا حرصا على هوية الجهة عدلت على السناريو بعض الشيء

نسمي بالله ونتطرق للثغرة بشكل مختصر

اثناء فحصي للجهة لاحظت شيء غريب والي هو انه بعض المسارات ترجع بيانات بالرغم ان المسار غير صحيح

على سبيل المثال أحد المسارات الموجودة

GET /static/main.js

لكن اذا حذفت السلاش "/" مثل كذا

GET /staticmain.js

الي راح يصير بيرجع نفس الرد من السيرفر

الأمر كان غريب والي بسببه فكرت وبحثت عن سبب التصرف الغريب هذا

وبعد بحث واستنتاج عن السبب هذا اتضح لي انه عبارة عن خطأ في اعدادت Nginx,

وعمر كيف الخطأ قاعد يصير؟

والسبب يرجع لغلطة في اعدادت nginx.conf ، (ملف اعدادات) وهذا يخلي السيرفر يستقبل المسار بشكل خاطئ

وعشان تكون الصورة اوضح

السيرفر كان يعامل staticmain.js/ كأنه static/main.js/

لأنه أول ما يشوف static/ يضيف / بعده بشكل مباشر وتصير /static/

بسبب alias operation الي قاعدة تصير بمجرد ماتكتب static/ راح يضيف / بعده بشكل مباشر وتصير /static/

فتصير كأنك كتبت static/main.js/

# استغلال الخطأ الى ثغرة حرجة

وهذا الشي يفتح لنا باب لثغرة تسمى ب off-by-slash اللي تقدر من خلالها ممكن توصل لملفات حساسة.

مافهمت عمر كيف ممكن الخطأ هذا يسببب بثغرة توصل الى ملفات حساسة؟

ممكن ماوضحت الفكرة للبعض لكن الحين بنعرف كيف الخطأ البسيط هذا يسبب بثغرة بحرجة

وعشان تكون الصورة اوضح هذا مثال على الأعدادات المصابة الى nginx

والصورة توضح إعدادات Nginx كانت معرفه alias على static/ بدون سلاش "/" بنهاية المسار

ولكن بعملية ال alias او عملية تحويل المسار يتم تحويلة الى /static/ (يتم أضافة / بالنهاية وتصير القيمة /static/)

فصار السيرفر أول ما يشوف أي مسار يبدأ بـ static/ يضيف بعده / بشكل تلقائي،

فـ اذا ارسلنا /staticmain.js/ اعتبره كأنه داخل مجلد static ويفسّره على أنه static/main.js/. وهنا تصير ثغرة off-by-slash

وهنا يصير الخطأ الفادح انه السيرفر يستقبل المسار بدون / بالنهاية لكن يتم اضافة / بعملية ال alias (عملية تحويل المسار)

# استغلالي للثغرة والوصل الى RCE وتحكم كامل بالجهة

بعد مافهمت وش قاعد يصير وكيف قاعد تتم العملية هذي بال server-side

عرفت انه كا�� بأمكاني اطلع برا السياق المحدد بالمسار واوصل الى ملفات داخلية

مافهمت عمر شلون تصير الطريقة؟

بما ان ال / يتم اضافته بعد static/ بشكل مباشر معناته يمدي نضيف /.. ونطلع من المسار المحدد

ولأن عملية ال normalization تتم بعد URI rewriting via alias في nginx

بالتالي من الممكن نوصل لملفات داخلية بأستغلال الخلل هذا

ومالكم بالطويلة

بعد مافهمت الي قاعد يصير اول شيء جاء ببالي اني اسوي fuzzing او تخمين مسارات بالشكل هذا static../FUZZ/

وسبب اني بسوي fuzzing بالشكل هذا static../FUZZ/
وليس كذا static/../FUZZ/

لأنه مثل ماشرحت فوق انه يتم اضافة / بشكل مباشر بعد static/ لذلك سويت fuzz بالطريقة هذي

وفعلا بعد ماسويت fuzzing وصلت لعدة نتائج وأغلبه كان ملفات لأعدادات مافيها شيء حساس

ولكن احد الملفات رجعت بيانات ولكن مب اي بيانات (;

والي كانت تسرب الباسورد للأدمن مع اسم المستخدم ك clear-text!

باللحظة هذي كانت فرحة قوية الى ان جربت أستعمل المعلومات بموقع الجهة ولكن للأسف ماكانت مسجلة.

بعد العديد من المحاولات البائسة, فكرت انه ممكن يكون الحساب ل��دمة داخلية فقط ولا أقدر استفيد منه

لكن ماوقفت وحاولت اجيب اي login portal تخص الجهة بكل الطرق واجرب فيها المعلومات الي وصلت له.

وفعلا بعد بحث ورا بحث, لقيت احد ال login portals من خلال google dorking وجربت ال Admin credentials

والنتيجة؟ بالفعل قدرت ادخل ال Portal, والفرحة كانت بعد ما شفت ال Control Panel كان فيها Command shell

غير الصلاحيات الحساسة الأخرى الي وصلت له يكفي Shell page as PoC (;

والي من خلالة كنت قادر اتحكم بسيرفر الجهة بشكل كامل (;

[Abdulaziz @stuipds]

Race Condition Led to Admin Takeover

خطأ مبرمج سمح لنا نخترق حساب الادمن !

بالبدايه رجعت لكم بمقالة جديدة انا و @0xAbady

قبل مانبدا اغلبكم اكيد عارف وش هو الrace condition

بس الي اغلبه مايعرف انه فيه نوع اسمه
time-of-check to time-of-use

طيب بسم الله خلونا بالبدايه نشرحها

تخيل إنك مبرمج كسلان او مستعجل، وجاك شغل لازم تتحقق فيه من صلاحيه المستخدم

بدل ما تحط نظام تحقق (authorization) مضبوط، تسوي شي بسيط وسهل اسمه “time-of-check”

وش تسوي؟ تروح للباك اند وتقول: “اوكي، اذا جاني طلب من ايميل اسمه [email protected]، خلني اشوف هل فعلاً هذا المستخدم سوى تسجيل دخول قبل شوي من خلال ال��قت مابين ريكويست تسجيل الدخول وريكويست الOTP validation يتحقق بالtimestamp؟”.

فاذا سجل دخوله فعلا، تقول: "تمام، خلني اسمح له"

ممتاز طيب اغلبكم الحين يقول وين المشكله ياعبدالعزيز؟

المشكلة كلها هنا انك تحققت من الشرط، لكنك ما ربطتها بسيشن او توكن، فصار فيه وقت فاصل بين التحقق والاستخدام كذا صار ال"time of use"

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

وبرضو في حالتنا راح اشرح كيف استغليناها لصالحنا

وهذا هو “Time Of Check To Time Of Use”

[مقرراتي | Moqraraty @moqraraty]

مع تغيير نظام حساب الغيابات في الجامعة،
مافيه أحد مريح راسه مثل مستخدمين مقرراتي 🌟

بضغطة زر:
- تسجل غيابك
- تعرف كم غياب عندك
- ينبهك اذا قربت تخلص غياباتك!

جرب مقرراتي وخل الغياب تحت السيطرة 🔥
https://t.co/wOkirMMWuq

[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 نقدر ندخل حساب المستخدم بشكل كامل من دون أي تفاعل منه!

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

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