20 قدم تا شکار جایزه آسیب‌پذیری پرسود

20 قدم تا شکار جایزه آسیب‌پذیری پرسود
  1. درحالت ایده آل شما برنامه را انتخاب کنید که اسکوپ گسترده تری داشته باشد. همچنین درانتخاب برنامه باگ بانتی هم به سراغ برنامه ای بروید که رنج وسیعی از آسیب‌پذیری ها را در اسکوپ خود داشته باشد.
  2. استخراج اطلاعات مربوط به دامنه ها، ایمیل سرورها و ارتباطات شبکه های اجتماعی.
  3. وارد وب سایت شوید، هر درخواست و پاسخ و آنالیزی که بدست می‌آید را بررسی کنید، تا زیرساخت هریک از اینها اعم از چگونگی کارکرد جلسات یا احراز هویت و نوع حفاظت CSRF هرکدام را به خوبی درک کنید.
  4. برای پیدا کردن خطاها و ارورها از آزمون منفی استفاده کنید. اطلاعات خطاهایی که از این طریق بدست می‌آیند برای دسترسی داشتن به مسیرهای داخلی وب سایت بسیار مفید هستند. برای درک گردش اطلاعات در نرم افزار برای پیدا کردن نوع آسیب‌پذیری های محتمل به خودتان زمان دهید.
  5. بااستفاده از اسکریپت ها برای نقاط پایانی لیست کلمات بروت فورس به شکل عمقی بررسی کنید. این کار به شما کمک می‌کند تا مسیرها یا پوشه های جدیدی که با استفاده از وب سایت قادر به پیدا کردنشان نبودید را پیدا کنید. پنل های مدیریتی خصوصی، مخازن منابعی مثل پوشه های /.git/ یا اسکریپت های test/debug هستند که فراموش شده اند و حذف نشده اند. پس ازاینکه هرحالت وب سایت را بررسی کردید حملات سمت مشتری را شروع کنید. از پی لودهای چندگانه برای گذرکردن از فیلترهای سمت مشتری استفاده کنید.
  6. زود دست بکارشوید. به محض اینکه برنامه باگ بانتی بارگذاری شد، اگر از دستتان برمی‌آید، فورا شکار را شروع کنید.
  7. به محض اینکه شکار را شروع کردید، یک جریان کاری یا تابع مشخصی از اپلیکشن را درنظر بگیرید و عمیقا روی آن کار کنید. من شخصا از باگ های سطحی یا آسیب‌پذیری های دم دستی چشم پوشی کردم. ارزش ندارد زمان خودتان را سر این چیزها هدر ندهید.
  8. اپلیکیشنی را درنظر بگیرید که به کاربران اجازه می دهد تا به سایر کاربران پیام ارسال کنند.
  9. جریان اطلاعات و درخواست های این اپلیکیشن را بااستفاده از ابزارهای پروکسی مانند Burp رصد کنید. مسلما Burp تنها ابزاری است که من برای تست نفوذ وب اپلیکیشن ها از آن استفاده می‌کنم.
  10. از آنجاییکه می‌خواهید ارسال پیام از یک کاربر به کاربر دیگر را مورد بررسی قرار دهید، دراپلیکیشن چند حساب کاربری مختلف ایجاد کنید. اگر اجازه ایجاد چند حساب کاربری ندارید، درخواست خود را به صاحب اپلیکیشن ارائه دهید. من تا به امروز در هیچ برنامه ای برای درخواست ایجاد حساب کاربری با مشکل مواجه نشده ام.
  11. اکنون اگر کمی دراین زمینه تجربه داشته باشید، با کمی سروکله زدن جریان کار و اطلاعات، متوجه این موضوع می‌شوید که آیا اتفاقات جالبی دراین میان درحال اتفاق افتادن است یانه. توضیح کامل این مساله خارج از حوصله این متن است. با تمرین زیاد خودتان کم کم قلق آن را پیدا خواهید کرد.
  12. اگر حدس تان درست بود، و مشکلی دراین میان وجود داشت، جریان کار و اطلاعات اپلیکیشن را تاجاییکه امکان دارد به اجزای کوچکتر مانند ID های تصادفی، مقادیر و … تجزیه کنید. در 80% مواقع، متوجه رفتارهای متناقض و عجیب و غریب می‌شوید.
  13. هر رفتار عجیب غریبی به معنای این نیست که شما یک باگ که ارزش گزارش کردن دارد پیدا کرده اید. این به این معنی است که شما خوش شانس هستید و به تلاش خودتان در عمق بیشتری از اپلیکیشن ادامه دهید.
  14. گاها بایستی در این زمینه پژوهش هایی که از شما خواسته شدهاست را نیز انجام دهید. مثلا بایک ایمیل سرور قدیمی روبه رو می‌شوید که در پروژه از آن استفاده شده‌است. در اینترنت به دنبال آسیب‌پذیری های احتمالی این ایمیل سرور بگردید. مسلما با یک CVE شناخته شده ای روبه می‌شوید که از آن بهره برداری شده است. از بهره برداری که پیدا کرده اید استفاده کنید و نتیجه را مشاهده کنید(به شرطی‌که تحت قرارداد و شرایط باگ بانتی عمل کنید).
  15. ممکن است درطول کار به ابزارهای خاصی نیاز پیدا کنید. درصورت امکان به تحقیق درمورد این ابزارها بپردازید. به یاد داشته باشید، ابزار Burp یک چاقوی سوییسی همه‌کاره (آچار فرانسه) است اما درصورت نیاز شما به ابزارهای خاص دیگری نیز احتیاج پیدا خواهید کرد. برای همیشه ازاین مساله آگاه باشید.
  16. پس از اینکه روی یک مورد به میزان کافی زمان گذاشتید، و دیگر چیز معناداری از آن نمی توانید بدست بیاورید، به مسیرتان ادامه دهید. پافشاری روی اهداف خیلی بزرگ قاتل انگیزه شما خواهد بود، اما این به معنی تسلیم شدن نیست. مورد کنونی را یادداشت کنی، و درصورت نیاز بعدا دوباره به آن بازگردید.
  17. چیزی که من از اکثرا نتیجه خوبی گرفته‌ام، بررسی محدودیت های پارامترها است. پارامتری را انتخاب کنید که روی جریان داده اپلیکیشن به وضوح تاثیرگذار است.

برای مثال، اگر ورودی یک فیلد مقادیر عددی است (مثلا ID)

آنگاه اگر موارد زیر اتفاق بیفتد چه اتفاق می‌افتد:

    • عدد منفی وارد کنیم؟
    • عدد را کاهش یا افزایش دهیم؟
    • یک عدد بسیار بزرگ به عنوان ورودی وارد کنیم؟
    • به جای عدد از رشته یا سمبل کاراکترها استفاده کنیم؟
    • میخواهید بااستفاده از …/ به یک دایرکتوری نفوذ کنید؟
    • بردارهای XSS را وارد کنید؟
    • بردارهای SQLI را وارد کنید؟
    • از کاراکترهای non-asci به عناون ورودی استفاده کنید؟
    • با انواع متغیر مثلا ریختن رشته ها دریک آرایه بازی کنید.
    • از کاراکترهای null یا مقدار هیچ استفاده کنید.

سپس به نتایجی که از این آزمون ها بدست می آید توجه کنید و ببینید آیا :

    • می توانید متوجه شوید که براساس خطایی که بدست آورده‌اید چه اتفاقی می‌تواند بیفتد؟
    • چیزی خراب شده یا مورد بهره‌برداری قرار گرفته‌است؟
    • این خطا روی سایر قسمت های اپلیکیشن تاثیر دارد یا نه؟
  1. روی کارآیی سایت که ثبت شده است یا تغییر آن از نسخه قبلی به نسخه فعلی تمرکز کنید. گاها قبلا از یک محصول بانتی استفاده کرده اید یا به چشمتان خورده‌است، اگر عملکرد جدیدی باشد بلافاصله متوجه آن خواهید شد. درسایر مواقع با چندبارخواندن خلاصه برنامه بانتی متوجه می شوید که داخل این خلاصه نقشه برنامه برای شما ترسیم شده است. اکثرا توسعه دهندگان به حوزه هایی اشاره می‌کنند که به نظرشان درآن حوزه ضعف دارند. تنها خواسته ما یا توسعه دهندگان از شما، موفقیت است! یک تابع جستجوی جدید، دسترسی براساس نقش و … می‌تواند یک مثال بصری باشد. یک مثال مختصر برای باگ بانتی مثلا می‌تاوند اینگونه باشد که با خواندن یک خلاصه از بانتی، متوجه ارجاعات زیادی که به API ها شده شوید یا متوجه وجود یک صفحه یا عملکرد خاصی درسایت شوید.
  2. درصورتیکه اسکوپ اجازه دهد (و شما مهارت کافی داشته باشید) اپلیکیشن های موبایلی را نیز بررسی کنید. درحالیکه شدت خطرناکی باگ های سمت مشتری درحال کاهش یافتن هستند، نقاط پایانی APIها یا وب اپلیکیشن‌های موبایل اغلب با قسمت هایی از اپلکیشن در ارتباط هست که درجریان کارهای معمولی شما با چنین اتصالاتی مواجه نشده‌اید. این به این معنی نیست که باگ های سمت مشتری قابل گزارش نیستند، منتهی این باگ ها با افزایش سطح امنیت سیستم عامل های موبایلی از اهمیت کمتری برخوردار هستند.
  3. بعدازاینکه نسبت به سایت اشراف کاملی پیدا کردید، نیاز دارید تا جریان کار موجود در اپلیکیشن را چه به‌صورت ذهنی و چه به صورت فیزیکی ثبت کنید. دراین راستا سوالات زیر را از خودتان بپرسید:
    • آیا عملکرد صفحه چیزی به کاربر نشان می‌دهد؟ (XSS، جعل محتوا و …)
    • آیا ظاهر صفحه جوری است که احتمال می‌دهید که امکان دارد داده های ذخیره شده را فراخوانی کند؟
    • (تمام injectionها، ارجاع شی غیرمستقیم، ذخیره‌سازی سمت مشتری)
    • آیا امکان دارد با سیستم فایل سرور تعامل داشته باشد؟ (Fileupload vulns,LFI و …)
    • آیا عملکرد ارزش امن‌سازی کردن را دارد؟ (CSRF، حالت درهم‌آمیخته)
    • آیا این تابع یک تابع با الویت بالاست؟ (جریان های منطقی، IDORها، افزایش و گسترش priv ها)++
    • ورودی کجا پذیرفته می‌شود و به صورت بالقوه کجا برای کاربر نمایش داده می‌شود؟
    • نقاط پایانی چه داده هایی را ذخیره می‌کنند؟
    • هر تابعی که فایل آپلود می‌کند.
    • چه نوعی از احراز هویت در آن استفاده شده‌است؟

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *