damian89/extended-ssrf-searchماسح ssrf ذكي يستخدم طرقًا مختلفة مثل parameter brute forcing في post و get...
تبحث هذه الأداة عن SSRF باستخدام إعدادات محددة مسبقًا في أجزاء مختلفة من الطلب (المسار، المضيف، الرؤوس، معاملات POST و GET).
قم بإعادة تسمية ملف example.app-settings.conf إلى app-settings.conf وضبط الإعدادات. أهم إعداد هو رابط الاستدعاء callback url. أوصي باستخدام Burp Collaborator. ثم يمكنك إضافة روابطك إلى config/url-to-test.txt. هنا يقبل البرنامج النصي النطاقات وكذلك الروابط مع المسار ومعاملات الاستعلام. إذا أردت، يمكنك إضافة ملفات تعريف الارتباط الخاصة بك إلى config/cookie-jar.txt وإضافة رؤوس إضافية لطلباتك. قائمة القوة الغاشمة brute force list المستخدمة في طلبات POST و GET صغيرة حاليًا، لا أعتقد أن إضافة 2000 معلمة أمر ذكي. يجب أن نركز على تلك التي لديها أعلى احتمالية لأن تكون ضعيفة. إذا كنت لا تعتقد ذلك، فقط أضف قائمتك الخاصة!
هذه الأداة لا تتوقع أي وسيط عبر CLI، لذا فقط اكتب:
python3 extended-ssrf-search.py
من الممكن تعيين العديد من الخيارات والإعدادات، لذا إليك بعض الشروحات.
ملف الإعدادات الرئيسي هو "app-settings.conf"، كل شيء يجب أن يتم في هذا الملف! بالإضافة إلى ذلك، هناك بعض الملفات الأخرى التي تسمح بتعيين بيانات أكثر تعقيدًا مثل الرؤوس والروابط وملفات تعريف الارتباط.
config/cookie-jar.txt
استخدم هذا الملف لإضافة سلسلة ملفات تعريف الارتباط. عادةً ما أقوم بنسخ السلسلة التي تراها في كل طلب Burp. يرجى فقط نسخ قيمة رأس "Cookie:". يوجد مثال للإدخال في الملف الافتراضي.
config/http-headers.txt
يحدد هذا الملف رؤوس HTTP التي تتم إضافتها إلى الطلب ومعالجتها (يتم إضافة الحمولة payload إلى كل رأس). أهم الرؤوس موجودة بالفعل في الملف. لكن لا تتردد في إضافة المزيد.
config/parameters.txt
تتوفر للأداة خيار القوة الغاشمة brute force لمعاملات GET و POST. في هذه الحالة، سيتم استخدام تلك المعاملات (بالإضافة إلى تلك الموجودة في سلسلة الاستعلام). يتم إعطاء كل معامل الحمولة كقيمة. أهمها موجود بالفعل في ذلك الملف.
config/static-request-headers.txt
تتم إضافة هذه الرؤوس إلى كل طلب، لكنها لن تتم معالجتها. إنها ثابتة. هذا هو أفضل مكان لإضافة رؤوس التفويض أو bearer cookies. سطر واحد لكل (مفتاح: قيمة)!
config/urls-to-test.txt
هذا هو الملف الذي تحتاجه! يرجى إضافة روابطك للمسح هنا. التنسيقات التالية مسموح بها:
عند اكتشاف الحالة الأخيرة، يتم إضافة "http://" في البداية. هذه الأداة مصممة للعمل مع قائمة جيدة من الروابط. طريقة جيدة للحصول على واحدة هي تصديرها باستخدام Burp. عندها ستحصل على قائمة صحيحة من الروابط. كل ما عليك فعله هو إضافة ملفات تعريف الارتباط الخاصة بك.
يحدد ملف app-settings.conf سير عمل البرنامج. إنه أهم ملف، يمكنك تفعيل/تعطيل الوحدات المختلفة فيه.
CallbackHost
الرابط/المضيف الذي يتم إرسال جميع طلبات DNS و HTTP إليه - عادةً ما أستخدم Burp Collaborator هنا، لكن DNSBin أو الخادم الخاص بك هو أيضًا مثالي.
HTTPMethod
يحدد طريقة الطلب. الخيارات الصالحة هي: GET, POST, PUT, DELETE, PATCH, GET, OPTIONS القيم غير الصالحة ستسبب أخطاء جسيمة لأن http.client يمنع الطرق الأخرى! لا أتحقق إذا فعلت شيئًا خاطئًا هنا ;)
HTTPTimeout
بعض الطلبات قد تستغرق وقتًا طويلاً. هنا يمكنك تحديد الحد الأقصى لوقت التنفيذ لطلب واحد. أوصي بقيم بين 2 و 6 ثوانٍ.
MaxThreads
كلما زاد عدد الخيوط threads، زادت سرعة النص البرمجي - لكن نظرًا لأننا نتعامل مع الكثير من الاتصالات، عادةً ما أبقي هذا أقل من 10 على جهازي الشخصي وحوالي 30 على VPS الخاص بي.
ShuffleTests
خاصة عند التعامل مع قائمة كبيرة من الروابط، تعيين هذا إلى "true" سيخلط جميع الاختبارات التي تم إنشاؤها. بهذه الطريقة لن يتم استهداف نفس المضيف كثيرًا. إذا كنت تمسح مضيفًا واحدًا فقط، فلا يهم.
GetChunkSize
عند العمل مع قوائم معاملات أكبر، قد يكون هذا مفيدًا ويمنع الأخطاء 400 التي تشير إلى حجم الكيان كبير جدًا.
يمكن تفعيل كل نقطة إدراج (تعيين إلى true/1) أو تعطيلها (تعيين إلى false/0)
InPath
المثال يظهر طلب GET، لكن اعتمادًا على إعداداتك، قد يكون هذا أيضًا POST, PUT, DELETE, ...
GET [INJECT HERE PAYLOAD] HTTP/1.1
...
InHost
المثال يظهر طلب GET، لكن اعتمادًا على إعداداتك، قد يكون هذا أيضًا POST, PUT, DELETE, ...
GET /path HTTP/1.1
Host: [INJECT HERE PAYLOAD]
...
InAdditionalHeaders
المثال يظهر طلب GET، لكن اعتمادًا على إعداداتك، قد يكون هذا أيضًا POST, PUT, DELETE, ...
GET /path HTTP/1.1
...
X-Forwarded-For: [INJECT HERE PAYLOAD]
InParamsGet
هنا الطريقة ثابتة على GET.
GET /path?[INJECT HERE PAYLOAD] HTTP/1.1
...
InParamsPost
هنا الطريقة ثابتة على POST.
POST /path HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: XXX
[INJECT HERE PAYLOAD]
InParamsPostAsJson
هنا الطريقة ثابتة على POST.
POST /path HTTP/1.1
...
Content-Type: application/json
Content-Length: XXX
[INJECT HERE JSON-PAYLOAD]
في الإعدادات الافتراضية، تحاول هذه الأداة فقط تشغيل طلبات HTTP عبر SSRF. لكن من الممكن أيضًا استخراج البيانات باستخدام DNS، عندما يتم حقن أمر OS. الحمولة الأكثر شيوعًا هي "$(hostname)". هناك بعض الخيارات التي تسمح باستخدام هذا النوع من الهجوم بالإضافة.
UseExecPayload
باستخدام هذا الإعداد، يمكنك تفعيل/تعطيل هذا السلوك.
ExecPayload
هنا يمكنك تعريف الحمولة الخاصة بك، مثلاً $(uname -a)
لتسهيل التعريف، يتم إلحاق أو إضافة مجموعة من المضيف الحالي والطريقة (في شكل مختصر، انظر Tests.py) إلى الحمولة.
Position
الخيارات الصالحة هي "append" و "prepend"!
إذا تم اختيار "append"، فستبدو الحمولات هكذا:
....burpcollaborator.net/www.attacked-domain.com-testmethod
http://....burpcollaborator.net/www.attacked-domain.com-testmethod
إذا تم اختيار "prepend"، فستبدو الحمولات هكذا:
www.attacked-domain.com-testmethod.burpcollaborator.net
http://www.attacked-domain.com-testmethod.burpcollaborator.net/
من الممكن أيضًا استخدام نفق tunnel، مثلاً "127.0.0.1:8080" (Burp Proxy)، لمراقبة كل حركة المرور داخل Burp.
Active
تعيين هذا إلى "true" سيجبر النص البرمجي على استخدام اتصال موصل بالنفق.
Tunnel
قم بتعيين خادم البروكسي الخاص بك هنا "ip:port".
النتيجة هي التالية، عند فتح Burp يمكنك مشاهدة سجل HTTP الخاص بك:
يرجى فقط إنشاء مشكلة issue ووضع علامة عليها كطلب ميزة.
هل أعجبتك هذه الأداة؟ هل ساعدتك في الحصول على مكافأة bounty؟ هل تريد رد الجميل/دعمي؟ لم لا!