نمونه رجیستر های modbus

سلام
بخاطر سربازی واسه یه مدت نسبتا طولانی نیستم و آماده کردن مطالب تخصصی هم ممکن نیست، اما سعی میکنم مطالب ساده و کاربردی که ممکنه باهاش آشنا نباشین رو به اشتراک بزارم.

با این دورک شودان میتونین به کانفیگ های VPN برسین (اشتراک گذاریش به تعداد زیاد این روش رو منسوخ میکنه)
html:"vless" http.title:"index of"
با الگو قرار دادن این کوئری میتونین کوئری های کاستوم خودتون رو بنویسین.


خیلی وقتا نیاز به نصب لابراتورهای آفلاین نیست و تو شودان میشه پیداشون کرد مثل این مورد :
http.title:"DVWA"
و مواردی مثل bwapp و‌‌....
اینارو میتونین به عنوان easy RCE هم در نظر بگیرین.

جاهایی که دوتا CSRF token داریم یکی تو body و یکی تو cookie، معمولا یکسان بودن این دو توسط سرور چک میشه.
برای اکسپلویت نیاز به یک session fixation داریم که برای قربانی CSRF token دلخواه رو در cookie ست کنیم و فقط کافیه همون توکن رو در Body هم ارسال کنیم.

#نکته‌هایی‌از‌کتاب‌
#CSRF

General web application penetration testing methodology:


اگه تازه کارین میتونین از این متودولوژی استفاده کنین تا وقتی که متودولوژی شخصی خودتونو بسازین.
هدف: وقتی به یه domain یا subdomain رسیدین چیکار کنین.
نیازمندی ها: آشنایی با تکنولوژی های مختلف استفاده شده در web application ها و آسیب پذیری های مختلف.
ابزار های مورد استفاده:
Burp suite
Waybaclurls
dig
ffuf
Google(for Google  dork)
Arjun or x8
Wappalyzer
Nuclei
Katana
Burp suite extension:
     Logger++
     Js link finder
     Reflection
1. چک کردن تکنولوژی های سایت با افزونه wappalyzer(طبق تکنولوژی های سایت تست های خودمون رو ادامه میدیم، مثلا وقتی تارگت وردپرسه باید متودولوژی مربوط به خودش رو داشته باشیم و وقتی تکنولوژی قدیمیه مثل php میتونیم آسیب پذیری هایی مثل shell upload و sql injection رو تست کنیم در صورتی که اینارو تو Django به این صورت بهشون اهمیت نمیدیم)
2. فعال کردن افزونه foxyproxy که ترافیک های مرورگر به سمت burp suite هدایت بشه، مثل کاربر عادی با وب سایت کار میکنیم تا هم functionality های سایت رو درک کنیم هم ترافیک های وب سایت رو داشته باشیم. و همچنین از نحوه ی Authentication سایت مطلع میشیم که cookie یا token و... هست. وقتی اینارو بدونیم test case های ما تغییر میکنه، برای مثال تو token base Authentication اصلا نباید csrf رو تست کنیم. با دیدن error page ها یا cookie های بخصوص میتونیم حدس بزنیم که WAF پیش رو داریم یا ن.
3. بعد هر action باید برگردیم به برپ و request و response هارو برسی کنیم، مثلا وقتی register انجام دادیم باید بعد از بررسی درخواستشو به تب repeater بفرستیم و اسم تب رو به register تغییر بدیم که در آینده خوانا باشه.
4. دوتا اکانت تو سایت میسازیم، هدف چیه(تست های مربوط به idor و mass assignment).
5. بعد از اینکه با همه functionality های پابلیک وب سایت کار کردیم و درخواست های مهم رو به برپ ارسال کردیم، باید برگردیم سراغ برپ و سناریو هایی که واسه هر بخش داریم رو تست کنیم.(واسه این قسمت باید آسیب پذیری هارو بخوبی بلد باشیم)
6. استفاده از dig برای به دست آوردن اطلاعات مربوط به dns وب سایت، برای مثال اگه cname داشته باشه میتونیم subdomain takeover رو تست کنیم، اگه dnssec داشت میتونیم zone walking رو تست کنیم. و وقتی هم IP وب سایت رو پیدا کردیم میتونیم با روش هایی که تو پست های قبلی بهشون اشاره کردیم بررسی کنیم ببینیم این آیپی original هست یا متلعق به CDN عه. با بررسی رکورد TXT میتونیم متوجه آسیب پذیری email spoofing بشیم. با بررسی رکورد AXFR میتونیم zone transfer رو تست کنیم
7. اگه تو تکنولوژی های سایت که بدست آوردیم فریمورک و تکنولوژی های سمت JS مثل ReactJS استفاده شده بود باید فعال بودن source map رو چک کنیم.
8. بدون توجه به تکنولوژی سایت، میتونیم از Nuclei استفاده کنیم واسه اسکن آسیب پذیری های مختلف، آسیب پذیری هایی که بهمون میده duplicate میشن ولی بهمون دید میده که ممکنه چه آسیب پذیری های دیگه ای رو ممکنه داشته باشه.
9. با افزونه logger++ میایم و اطلاعات خودمون رو که تو response برمیگرده سرچ میکنیم.
`
Response.Body CONTAINS "alireza@gmail.com"
ممکنه یه API پیدا بشه که اطلاعات همه کاربرا رو به نمایش بزاره و منجر به PII بشه.
در غیر این صورت میتونیم CORS misconfiguration و cache deception رو تست کنیم اگه شرط های مورد نیاز رو داشته باشه.
10. با افزونه Reflection میتونیم پارامتر هایی که reflect میشن رو به دست بیاریم و XSS رو تست کنیم.
11. اگه WAF نبود، میتونیم با ffuf فایل و دایرکتوری فاز کنیم و به مسیر های مخفی سایت برسیم، همچنین میتونیم با استفاده از katana به صورت active فایل ها و دایرکتوری های استفاده شده تو سورس کد های سایت رو به دست بیاریم
12. با Google dork به دنبال directory listing متعلق به اون سایت باشیم که میتونیم فایل های درون اون دایرکتوری رو به صورت کامل ببینیم.
13. با Google dork به دنبال فایل های پسوند دار مثل .php .asp .jsp و... باشیم، چون اینا تکنولوژی های قدیمین و میتونیم آسیب پذیری های مختلفی رو تست کنیم.
14. با استفاده از waybackurl میتونیم فایل ها و دایرکتوری هایی که سامانه ی web archive به دست آورده رو بیرون بکشیم و ممکنه حین این کار به اطلاعات مهمی مثل backup file برسیم یا به یک فایل که functionality های مختلفی داشته باشه و باید تست بشه.
15. با js link finder مسیر هایی که تو فایل های js به دست میاد رو بررسی میکنیم.
16. گزارش هایی که Burp suite میده واسه دامنه رو بررسی میکنیم که خیلی وقتا اطلاعات مهمیه، مثل شناسایی IP داخل سورس کد(New asset) و....
17. انجام parameter fuzzing با استفاده از x8/arjun.

#bug_bounty_methodology

جاهایی که سامانه از regex استفاده میکنه، میتونیم آسیب پذیری regex dos یا redos رو تست کنیم.
برای مثال سامانه یک ایمیل از کاربر میگیره و با regex معتبر بودن آن رو چک میکنه، در حالت عادی باید وقتی به اولین match رسید، regex متوقف بشه. اما اگر این regex به دنبال یک یا چندین match باشه، نفوذگر تعداد زیادی ایمیل قرار میده و regex parser مجبوره همه رو بررسی کنه و متوقف نمیشه، در نتیجه منجر به DOS میشه.

#dos
#redos

نظریه شخصی :
با مطالعه درباره گذشته امنیت سایبری، متوجه میشیم که از اوایل به وجود آمدن اسکنر های آسیب پذیری تا نهایتا سال 2014, 2015 ، اسکنر ها نتایج خیلی مطلوبی داشتند و میشد روی ابزار ها حساب باز کرد. بعدش کم‌کم با تغییر تکنولوژی ها و پیدایش آسیب پذیری های جدید و سخت، اسکنر ها کارایی قبلی رو از دست دادن و تست نفوذ دستی ارزش پیدا کرد.
حالا دوباره طی این یکی دوسال، روند قبلی تکرار شده و ترکیب AI + اسکنر داره نتیجه مطلوبی میده‌‌‌ و اسکن دستی به نسبت گذشته کم‌کم ارزش خودشو از دست میده(طبق چیزی که بیشتر افراد فعال حوزه امنیت فکر میکنن).
حالا اگه بخوایم یه نتیجه گیری داشته باشیم از دومورد بالا، زمانی که اسکنر های مجهز به AI به نهایت پیشرفت خودشون برسن و دیگه جای رشدی وجود نداشته باشه، بازم اسکن دستی ارزش قبلی رو به دست میاره.

این فقط نظر شخصی هستش و ممکنه اشتباه باشه.

بعد یه مدت طولانی رو یه تارگت ایرانی کار میکردم، یه قسمت برای File Upload داشت که PDF هم قبول میکرد، قبلا یه PDF آماده برای تست XSS داشتم.
چند تا مشکل وجود داشت، فقط روی Google Chrome کار میکرد و Checker Function وقتی به کلمه JS و JavaScript میرسید واکنش نشون میداد و عملا جلوی آسیب پذیری گرفته میشد.
با یکم تحقیق تونستم با استفاده از OpenAction روی Firefox و سایر مرورگرا هم کدم رو اجرا کنم.
برای بایپس WAF هم کلمه های JS و JavaScript رو به صورت Unicode نوشتم و بایپس شد.
فایل PDF رو میزارم اینجا شاید بکارتون اومد.
پ.ن فایل روی ترد پارتی آپلود میشد و قابل گزارش نبود:)

مالیات جوانی پرداخت شد.
پایان احترام گذاشتن به کسایی که لیاقتشو نداشتن.


بعد یه ریکاوری فعالیت کانال به روال قبل برمیگرده.

رایتاپ آسیب پذیری Improper Access Control

چند تا Subdomain عمومی از تارگت داشتم که یکیش API بود. با استفاده از waybackurls به مسیر های زیر رسیدم.
/portal/admin/login
/portal/panel
دومی بنظرم جذاب تر میومد چون به پنل مدیریت اشاره میکرد. خود صفحه 404 میداد و تصمیم گرفتم Fuzz بندازم. چندین مسیر مختلف پیدا شد که همشون 403 میدادن و یکیش categories/ بود.

برگشتم به portal/admin/login/ و طبق عادت login/ رو از URL به register/ تغییر دادم و در کمال ناباوری صفحه ثبت نام ادمین باز شد!
با خوشحالی اطلاعاتمو وارد کردم و بعد submit منو به portal/panel/ ری دایرکت کرد و باز 403 داد.
گفتم شاید مستقیم یوزر پس رو تو صفحه لاگین وارد کنم اتفاقی بیفته و بازم 403 داد.
بعدش که ناامید شده بودم داشتم یکی یکی تب هارو نگاه میکردم و برای اونایی که هیچ سناریو و ایده ای نداشتم میبستمشون، اتفاقی دستم به F5 خورد تو یکی از صفحه ها و بعد رفرش شدن صفحه، ادمین بودم!
مسیرشو که نگاه کردم تو portal/panel/categories/ بودم و داخل پنل کاربری ایمیل و اطلاعاتی که تو portal/admin/register/ وارد کرده بودم لود شده بود. یعنی مستقیم ثبت نام میکردی 403 میداد و صفحه categories هم مستقیم بازش میکردی 403 میداد. ولی اطلاعات ثبت شده من تو صفحه portal/admin/register/ داخل categories لود میشد. میتونستم کل پست هارو ویرایش کنم و محتوای دلخواهمو بنویسم.

#writeup