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

🚨 Broken Access Control – Part 1
💰 Earned $60K+ in bounties using these private techniques!


Link of video on instagram:

https://www.instagram.com/reel/DNBa3jdIX5O/?igsh=OGY4M3R4Mmd1OTZn


We're starting a new series focused on exclusive tricks and real-world exploitation of Broken Access Control vulnerabilities across different targets.
Watch the first episode now on YouTube and level up your bug bounty skills! 🔥

📺 Uploaded on our YouTube channel: pentesterlanden

Video link: https://www.youtube.com/watch?v=OrKw_j2KLSc


#BugBounty #BrokenAccessControl #CyberSecurity #InfoSec #HackingTips #PentesterLanden #EthicalHacking

Dot Suffix Bypass 🤑

Some WAFs block paths by exact hostname. Adding a trailing dot (site.com.) bypasses them — DNS treats it the same, but WAF sees it differently.

Example:
site.com/xxxxxxxxxxxxxx/file.php → 403
site.com/xxxxxxxxxxxxxx./file.php → 404
site.com./xxxxxxxxxxxxxx/file.phpfile.php → 200 ✅

This is called Host Header Normalization Bypass.
I earned $3000 bounty using this trick! 💸

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

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


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

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

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

چجوری از یه جاوا اسکریپت ساده به ادمین پنل رسیدم ✅

اولین کاری که کردم این بود که سورس صفحه رو باز کردم و روی دونه به دونه فایلای جاوا اسکریپت کلیک کردم و دنبال جاوا اسکریپ و سورسی بودم که برام سود اور باشه و بهم سر نخ بده که یه لینک چشممو تیز کرد :

https://log.sub.target.com/collectors/minimized/bundle-main.js

به ظاهر لینک نگاه کنید ادرسی که لینک شده احتمالا js مهمیه و وقتی داخلش رو باز کردم یه جاوا اسکریپت بود که به صورت پک شده و قابل خوندن نبود خب من طبق معمول سعی کردم یه .map به انتها اضافه کنم تا سورس رو به صورت پویا و خوانا ببینم ولی جواب نداد .❌

بیخیال نشدم و رفتم سراغ تست بعدی !

اینجا بهترین جا برای پیدا کردن باگه و من با این تریک باگ "افشای اطلاعات حساس" زیادی زدم و حتی میتونه دریچه ای برای باگ هایی مثل xss یا idor باشه !

برای این سناریو اولین کاری که همیشه میکنم فاز کردنه ولی چه جور فازی ؟

1 - https://log.sub.target.com/collectors/minimized/bundle-FUZZ.js

2 - https://log.sub.target.com/collectors/minimized/FUZZ-main.js

3 - https://log.sub.target.com/collectors/minimized/bundle-main-FUZZ.js

4 - https://log.sub.target.com/collectors/minimized/FUZZ.js

به چهار حالتی که که بالا میبینید دقت کنید ,هر کدوم رو انجام دادم و فاز کردم .!
کلمه کلیدی "_database" با همچین ادرسی اطلاعات + ادرس پنل ادمین رو بهم به صورت کلیر داخل کد جاوا اسکریپت نشون داد :

https://log.banana.target.com/collectors/minimized/DataBase_-main.js

ادرس پنل داخل کد جاوا اسکریپت و ساب دامینی بود که قابل حدس نبود و با هیچ اسکنر و ساب دامین فایندری پیدا نمیشد این کاملا افشای اطلاعات بود ,
پنل از من یوزر و پسورد نمیخواست و من سطح دسترسی سوپر ادمین رو داشتم و مثل ادمین سایت دسترسی ها برام کاملا باز بود !



توی این سناریو فقط با یک جاوا اسکریپت ساده تونستم یه باگ کریتیکال بزنم و فقط به کمی خلاقیت نیاز داشت . این جاوا اسکریپت توی سورس صفحه نبود و حتی با ریکان گوگل دورک + گیت هاب + وی بک یو آرال پیدا نمیشد و تنها با فاز کردن به دست میومد !

حتما اینجوری فاز کنید تا به سرنخ کلیدی برسید هیچوقت به فاز ساده با ابزار متکی نباشید و قبل از این که چهار تا کامند ران کنید کمی تحلیل کنید 🌷

@Dagen_secuirty

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

تو شرایط مناسبی این رو ننوشتم، پس اگه مشکلی داشت پیوی بگین اصلاح کنم. اگه هم استقبال شد سعی میکنم check list بهش اضافه کنم.

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

#dos
#redos

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

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