🔥 با Lynis، امنیت Linux Server رو در چند دقیقه Audit کن.
بیش از ۲۰۰ بررسی انجام میدهد، از جمله:
نصب:
یا:
اجرای Audit:
برای اجرای سریع تر:
اگر فقط میخواهی SSH را بررسی کنی:
گزارش ها هم معمولاً اینجا قرار میگیرند:
برای دیدن Hardening Index:
نکته مهم:
اLynis چیزی را خودش Fix نمی کند.
سیستم را بررسی میکند، Weaknessها را پیدا میکند و برای Hardening پیشنهاد میدهد.
برای یک VPS یا Linux Server، یک Audit ساده با Lynis می تواند مواردی را نشان دهد که در بررسی دستی از قلم افتاده اند.
@TryHackBox
اLynis یک ابزار Open Source برای Security Auditing در Linux و Unix است.
بیش از ۲۰۰ بررسی انجام میدهد، از جمله:
• تنظیمات SSH
ا• Permissionها و SUID
• وضعیت Firewall
ا Kernel Parameters
پکیج ها و سرویس ها
• تنظیمات امنیتی سیستم
نصب:
apt install lynis
یا:
dnf install lynis
اجرای Audit:
lynis audit system
برای اجرای سریع تر:
lynis audit system --quick
اگر فقط میخواهی SSH را بررسی کنی:
lynis audit system --tests-from-group ssh
گزارش ها هم معمولاً اینجا قرار میگیرند:
/var/log/lynis.log /var/log/lynis-report.dat
برای دیدن Hardening Index:
grep hardening_index /var/log/lynis-report.dat
نکته مهم:
اLynis چیزی را خودش Fix نمی کند.
سیستم را بررسی میکند، Weaknessها را پیدا میکند و برای Hardening پیشنهاد میدهد.
برای یک VPS یا Linux Server، یک Audit ساده با Lynis می تواند مواردی را نشان دهد که در بررسی دستی از قلم افتاده اند.
💬 آخرین بار که Linux Server خودت را Security Audit کردی، چه موردی پیدا شد که انتظارش را نداشتی؟ تجربه ات را کامنت کن.
@TryHackBox
🔥5
دوستانی که علاقه مندان به تدریس دوره های پایه مقدماتی در زمینه امنیت سایبری و شبکه و لینوکس هستند با ایدی زیر با ما در تماس باشید :
@ThbxSupport
@ThbxSupport
پورت 23 Telnet :
کاملاً بدون رمزنگاری. نام کاربری، پسورد و تمام دستورات به صورت متن ساده ارسال میشن ..
https://x.com/KavehxNet/status/2103142796173455650
#ردتیم
کاملاً بدون رمزنگاری. نام کاربری، پسورد و تمام دستورات به صورت متن ساده ارسال میشن ..
https://x.com/KavehxNet/status/2103142796173455650
#ردتیم
X (formerly Twitter)
kaveh (@KavehxNet) on X
05 :: پورت 23 Telnet
کاملاً بدون رمزنگاری. نام کاربری، پسورد و تمام دستورات به صورت متن ساده ارسال میشن.
هنوز روی دستگاه های قدیمی شبکه، سیستم های امبدد و سرورهای لگاسی پیدا میشه.
یک موقعیت M…
کاملاً بدون رمزنگاری. نام کاربری، پسورد و تمام دستورات به صورت متن ساده ارسال میشن.
هنوز روی دستگاه های قدیمی شبکه، سیستم های امبدد و سرورهای لگاسی پیدا میشه.
یک موقعیت M…
Forwarded from P.F.K Security
📌 وقتی یک Vulnerability پیدا کردی، باید بدونی چه چیزی در خطره
فرض کنیم یک ضعف امنیتی پیدا کردی.
اینکه بگی: «این یک Vulnerability هست»
برای یک گزارش خوب کافی نیست.
باید بتونی توضیح بدی این ضعف چه اثری روی سیستم میذاره.
اینجا سه مفهوم خیلی مهم وارد ماجرا میشن:
همون چیزی که معمولاً بهش میگیم:
🔹 Confidentiality
یعنی مهاجم بتونه به اطلاعاتی دسترسی پیدا کنه که نباید بهش دسترسی داشته باشه.
مثلاً:
یک Vulnerability باعث بشه کاربری که فقط باید اطلاعات خودش رو ببینه، بتونه اطلاعات کاربران دیگه رو هم بخونه.
اینجا مشکل اصلی Confidentiality هست.
🔹 Integrity
یعنی مهاجم بتونه چیزی رو تغییر بده که نباید قادر به تغییرش باشه.
مثلاً یک ضعف باعث بشه کاربر معمولی بتونه فایل های حساس سیستم رو تغییر بده.
اینجا بحث Integrity مطرحه.
🔹 Availability
یعنی مهاجم بتونه دسترسی به سیستم یا سرویس رو مختل کنه.
مثلاً یک ورودی خاص باعث بشه سرویس Crash کنه و کاربران دیگه نتونن ازش استفاده کنن.
اینجا Impact روی Availability قرار میگیره.
🔥 یک نکته مهم
این سه مورد فقط اصطلاحات تئوری برای حفظ کردن نیستن.
وقتی یک Vulnerability پیدا میکنی، باید بتونی بگی:
«این ضعف دقیقاً چه چیزی رو تحت تأثیر قرار میده؟»
مثلاً اگر یک Vulnerability به مهاجم اجازه بده یک فایل دلخواه روی سیستم بنویسه، اولین چیزی که تحت تأثیر قرار گرفته Integrity هست.
اما نباید صرفاً بر اساس اسم Vulnerability درباره Impact تصمیم بگیری.
باید ببینی در Target واقعی چه اتفاقی می افته.
این طرز فکر بعداً موقع نوشتن PoC، Vulnerability Report و Impact Assessment خیلی به کارت میاد.
@PfkSecurity
#از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #ZeroDay #CyberSecurity
فرض کنیم یک ضعف امنیتی پیدا کردی.
اینکه بگی: «این یک Vulnerability هست»
برای یک گزارش خوب کافی نیست.
باید بتونی توضیح بدی این ضعف چه اثری روی سیستم میذاره.
اینجا سه مفهوم خیلی مهم وارد ماجرا میشن:
Confidentiality
Integrity
Availability
همون چیزی که معمولاً بهش میگیم:
CIA Triad
🔹 Confidentiality
یعنی مهاجم بتونه به اطلاعاتی دسترسی پیدا کنه که نباید بهش دسترسی داشته باشه.
مثلاً:
یک Vulnerability باعث بشه کاربری که فقط باید اطلاعات خودش رو ببینه، بتونه اطلاعات کاربران دیگه رو هم بخونه.
اینجا مشکل اصلی Confidentiality هست.
🔹 Integrity
یعنی مهاجم بتونه چیزی رو تغییر بده که نباید قادر به تغییرش باشه.
مثلاً یک ضعف باعث بشه کاربر معمولی بتونه فایل های حساس سیستم رو تغییر بده.
اینجا بحث Integrity مطرحه.
🔹 Availability
یعنی مهاجم بتونه دسترسی به سیستم یا سرویس رو مختل کنه.
مثلاً یک ورودی خاص باعث بشه سرویس Crash کنه و کاربران دیگه نتونن ازش استفاده کنن.
اینجا Impact روی Availability قرار میگیره.
🔥 یک نکته مهم
این سه مورد فقط اصطلاحات تئوری برای حفظ کردن نیستن.
وقتی یک Vulnerability پیدا میکنی، باید بتونی بگی:
«این ضعف دقیقاً چه چیزی رو تحت تأثیر قرار میده؟»
مثلاً اگر یک Vulnerability به مهاجم اجازه بده یک فایل دلخواه روی سیستم بنویسه، اولین چیزی که تحت تأثیر قرار گرفته Integrity هست.
اما نباید صرفاً بر اساس اسم Vulnerability درباره Impact تصمیم بگیری.
باید ببینی در Target واقعی چه اتفاقی می افته.
این طرز فکر بعداً موقع نوشتن PoC، Vulnerability Report و Impact Assessment خیلی به کارت میاد.
@PfkSecurity
#از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #ZeroDay #CyberSecurity
❤1
🔖 دورک های باگ بانتی
https://dorkking.blindf.com/
@TryHackBox
#dork #باگ_بانتی
https://dorkking.blindf.com/
شما چه دورک هایی استفاده میکنید ، کامنت کنید
@TryHackBox
#dork #باگ_بانتی
❤1
📚 بازخورد یکی از خوانندههای «شکار عملی باگ بانتی»
ممنون از اعتمادتون ❤️
هدف TryHackBox اینه که محتوا واقعاً در مسیر یادگیری و کار عملی به دردتون بخوره.
دوستان بازخوردها راجب کتابها زیاد هست گفتم یک چندتایی رو بزارم
ممنون از اعتمادتون ❤️
هدف TryHackBox اینه که محتوا واقعاً در مسیر یادگیری و کار عملی به دردتون بخوره.
دوستان بازخوردها راجب کتابها زیاد هست گفتم یک چندتایی رو بزارم
🔥3
یکی از methodologyهای مخفیم رو دراپ میکنم
🌀 Takeover AWS S3 Bucket
🔥 مثل حرفهای ها فوق العاده ساده اما خیلی موثر
✨ قبل از هرچیزی بیایم کل سناریو رو بفهمیم...
👀 ۱. کدوم bucketها آسیبپذیر برای takeover هستن؟
👀 ۲. تاثیر واقعی takeover یه S3 bucket چیه؟
👀 ۳. چطور S3 bucketهای potentially vulnerable رو پیدا کنیم؟
👀 ۴. چطور validate کنیم که bucket واقعاً توسط تارگت استفاده شده؟
⚡ ۱. Bucket های آسیبپذیر:
اگه تارگت قبلاً از یه S3 bucket استفاده کرده و deleteش کرده اما subdomain (CNAME) هنوز به amazonaws.com اشاره میکنه این فرصت عالی takeoverه.
⚡ ۲. تاثیر:
اگه bucket هنوز در backend یا services reference شده باشه، و تارگت فراموش کرده removeش کنه، ممکنه حتی RCE به دست بیاری. در بعضی موارد، میتونه به full system compromise منجر بشه.
⚡ ۳. پیدا کردن Bucketها (با استفاده از FOFA):
اینجا چطور با FOFA شکارشون میکنم:
🧠 FOFA Dork:
🔍 این dork subdomainهایی رو میده که به bucketهای missing یا deleted اشاره میکنن. FOFA fingerprints رو در سراسر وب index میکنه حتی برای منابع deleted پس goldmine برای پیدا کردن assetهای exposedی که تارگت فراموش کرده.
⚡ ۴. Validate کردن Ownership:
🔎 روش ۱: GitHub Recon
از GitHub dorkها مثل این استفاده کن:
یا ساده جستجو کن:
ممکنه hardcoded linkها، past commitها یا config fileهایی پیدا کنی که اثبات کنه تارگت از این bucket استفاده میکرده.
🌐 روش ۲: DNS History (همیشه موثر نیست، اما ارزش امتحان داره)
چک کن اگه bucket برای static website hosting configure شده بوده.
از این ابزارها برای چک historical DNS records استفاده کن:
اگه DNS leak یا CNAME recordهایی پیدا شد، analyzeشون کن تا proof of ownership بسازی.
🎯 پس بچهها، امیدوارم از خوندن این قطعه کوچیک متدولوژی لذت برده باشین.
@TryHackBox
#دورک #باگ_بانتی
🌀 Takeover AWS S3 Bucket
🔥 مثل حرفهای ها فوق العاده ساده اما خیلی موثر
✨ قبل از هرچیزی بیایم کل سناریو رو بفهمیم...
👀 ۱. کدوم bucketها آسیبپذیر برای takeover هستن؟
👀 ۲. تاثیر واقعی takeover یه S3 bucket چیه؟
👀 ۳. چطور S3 bucketهای potentially vulnerable رو پیدا کنیم؟
👀 ۴. چطور validate کنیم که bucket واقعاً توسط تارگت استفاده شده؟
⚡ ۱. Bucket های آسیبپذیر:
اگه تارگت قبلاً از یه S3 bucket استفاده کرده و deleteش کرده اما subdomain (CNAME) هنوز به amazonaws.com اشاره میکنه این فرصت عالی takeoverه.
⚡ ۲. تاثیر:
اگه bucket هنوز در backend یا services reference شده باشه، و تارگت فراموش کرده removeش کنه، ممکنه حتی RCE به دست بیاری. در بعضی موارد، میتونه به full system compromise منجر بشه.
⚡ ۳. پیدا کردن Bucketها (با استفاده از FOFA):
اینجا چطور با FOFA شکارشون میکنم:
🧠 FOFA Dork:
body="specified bucket does not exist" && (host="target.com" || host="target_domain_name_only") && port="443"
🔍 این dork subdomainهایی رو میده که به bucketهای missing یا deleted اشاره میکنن. FOFA fingerprints رو در سراسر وب index میکنه حتی برای منابع deleted پس goldmine برای پیدا کردن assetهای exposedی که تارگت فراموش کرده.
⚡ ۴. Validate کردن Ownership:
🔎 روش ۱: GitHub Recon
از GitHub dorkها مثل این استفاده کن:
org:target_org "target.s3.amazonaws.com"یا ساده جستجو کن:
"target.s3.amazonaws.com"ممکنه hardcoded linkها، past commitها یا config fileهایی پیدا کنی که اثبات کنه تارگت از این bucket استفاده میکرده.
🌐 روش ۲: DNS History (همیشه موثر نیست، اما ارزش امتحان داره)
چک کن اگه bucket برای static website hosting configure شده بوده.
از این ابزارها برای چک historical DNS records استفاده کن:
https://securitytrails.com
https://dnsdumpster.com
https://viewdns.info
https://www.robtex.com
اگه DNS leak یا CNAME recordهایی پیدا شد، analyzeشون کن تا proof of ownership بسازی.
🎯 پس بچهها، امیدوارم از خوندن این قطعه کوچیک متدولوژی لذت برده باشین.
کدوم FOFA dork رو برای S3 takeover تست کردی که subdomain dangling شکار کرد؟ تجربت رو کامنت کن.
@TryHackBox
#دورک #باگ_بانتی
Securitytrails
SecurityTrails | SecurityTrails: Data Security, Threat Hunting, and Attack Surface Management Solutions for Security Teams
SecurityTrails enables you to explore complete current and historical data for any internet assets. IP & DNS history, domain, SSL and Open Port intelligence made easy
🔥2🌚1
Try Hack Box
⭕ سری چالش های SE : هک انسان 1/20 📌 چالش : "تماس IT پشتیبانی" سناریو: شما درحال مهندسی اجتماعی هستید و هدفتون دسترسی به اطلاعات داخلی یک شرکت فرضی به نام "Datanova" هست. شما به عنوان یک "کارمند پشتیبانی IT" با خانم/آقای میترا شاهینی، منشی بخش مالی، تماس…
⭕ سری چالش های SE : هک انسان 2/20
📌 چالش: «مدیر در جلسه است»
سناریو:
شما از قبل می دانید:
◾ مدیر واحد مالی، «اقای فریدونی»، امروز جلسه دارد.
◾ واحد مالی برای ارسال گزارش ماهانه از یک سامانه داخلی استفاده می کند.
◾ ساعت ۱۰:۳۰ معمولاً زمان شلوغی واحد مالی است.
◾ چند نفر از کارکنان واحد IT را از صفحه LinkedIn شرکت شناسایی کردهاید.
🎯 هدف: متقاعد کردن کارمند برای انجام یک اقدام حساس در سامانه، بدون اینکه هویت شما را بهصورت مستقل Verify کند.
❓ سؤال چالش:
@TryHackBox
#مهندسی_اجتماعی
📌 چالش: «مدیر در جلسه است»
سناریو:
شما در حال انجام یک Social Engineering Assessment برای شرکت فرضی Datanova هستید.
هدف شما «آقای رضایی»، کارمند واحد مالی است.
شما از قبل می دانید:
◾ مدیر واحد مالی، «اقای فریدونی»، امروز جلسه دارد.
◾ واحد مالی برای ارسال گزارش ماهانه از یک سامانه داخلی استفاده می کند.
◾ ساعت ۱۰:۳۰ معمولاً زمان شلوغی واحد مالی است.
◾ چند نفر از کارکنان واحد IT را از صفحه LinkedIn شرکت شناسایی کردهاید.
شما با یک Pretext مشخص با اقا رضایی تماس می گیرید و خودتان را به عنوان یکی از کارکنان IT معرفی میکنید.
اما این بار هدف مستقیماً گرفتن Password نیست.
🎯 هدف: متقاعد کردن کارمند برای انجام یک اقدام حساس در سامانه، بدون اینکه هویت شما را بهصورت مستقل Verify کند.
❓ سؤال چالش:
اگر شما Social Engineer بودید:
۱. از چه Pretextی استفاده میکردید؟
۲. چطور از Authority و Urgency استفاده میکردید؟
۳. چه اطلاعاتی را قبل از تماس جمع آوری میکردید؟
۴. چه نشانه هایی باعث میشد کارمند متوجه حمله شود؟
۵. اگر شما مدافع Datanova بودید، چه Controlهایی برای جلوگیری از این حمله طراحی میکردید؟
@TryHackBox
#مهندسی_اجتماعی
🔥4
🚨 الان همه اطلاعات حساس و لو رفته تون رو از اینترنت پاک کنید.
۲۰ ساله که پروفایل میسازید، سایت میرید و رد پای دیجیتال به جا میذارید.
همه ش رو تو ۲ دقیقه پاک کنید: ↓↓
https://x.com/KavehxNet/status/2104090338293846369
۲۰ ساله که پروفایل میسازید، سایت میرید و رد پای دیجیتال به جا میذارید.
همه ش رو تو ۲ دقیقه پاک کنید: ↓↓
https://x.com/KavehxNet/status/2104090338293846369
X (formerly Twitter)
kaveh (@KavehxNet) on X
🚨 الان همه اطلاعات حساس و لو رفته تون رو از اینترنت پاک کنید
۲۰ ساله که پروفایل میسازید، سایت میرید و رد پای دیجیتال به جا میذارید.
همه ش رو تو ۲ دقیقه پاک کنید: ↓
این پست رو لایک و ریتوییت کن…
۲۰ ساله که پروفایل میسازید، سایت میرید و رد پای دیجیتال به جا میذارید.
همه ش رو تو ۲ دقیقه پاک کنید: ↓
این پست رو لایک و ریتوییت کن…
TRYHACKBOX_JIRA_Unauthenticated_Vulnerabilities.pdf
495.8 KB
📌 راهنمای فنی آسیبپذیری های Unauthenticated (JIRA) ده مورد CVE کلیدی همراه با روش تشخیص و exploitation، ویژه علاقه مندان به تست نفوذ و باگ بانتی
🆔 @TryHackBox
Github | Linkedin | YouTube | Instagram | Other
#تست_نفوذ #امنیت_سایبری #باگ_بانتی
🆔 @TryHackBox
Github | Linkedin | YouTube | Instagram | Other
#تست_نفوذ #امنیت_سایبری #باگ_بانتی
🔥3
ویندوز از هر عکسی که تا حالا پاک کردی، یه تصویر کوچک (thumbnail) نگه میداره.
این تصاویر داخل فایلی به اسم thumbcache_256.db ذخیره میشن و کارشناسان جرم شناسی دیجیتال مرتب ازشون استفاده میکنن. ۱۵ تا مخزن دیگه هم مثل این وجود داره.
اینجا میگم چطور پیداشون کنی و پاکشون کنی:
https://x.com/KavehxNet/status/2104307645696123143
این تصاویر داخل فایلی به اسم thumbcache_256.db ذخیره میشن و کارشناسان جرم شناسی دیجیتال مرتب ازشون استفاده میکنن. ۱۵ تا مخزن دیگه هم مثل این وجود داره.
اینجا میگم چطور پیداشون کنی و پاکشون کنی:
https://x.com/KavehxNet/status/2104307645696123143
X (formerly Twitter)
kaveh (@KavehxNet) on X
ویندوز از هر عکسی که تا حالا پاک کردی، یه تصویر کوچک (thumbnail) نگه میداره.
این تصاویر داخل فایلی به اسم thumbcache_256.db ذخیره میشن و کارشناسان جرم شناسی دیجیتال مرتب ازشون استفاده میکنن. ۱۵ ت…
این تصاویر داخل فایلی به اسم thumbcache_256.db ذخیره میشن و کارشناسان جرم شناسی دیجیتال مرتب ازشون استفاده میکنن. ۱۵ ت…
Forwarded from P.F.K Security
CVE یعنی چی؟
احتمالاً وقتی درباره یک آسیب پذیری میخونی، اولین چیزی که میبینی یک شماره شبیه اینه:
CVE-2020-XXXX
اما یک اشتباه رایج وجود داره:
اCVE داشتن یک مشکل، لزوماً به این معنی نیست که با یک Vulnerability واقعی طرفیم.
اCVE مخفف Common Vulnerabilities and Exposures هست.
در عمل، CVE یک شناسه یکتا برای یک مشکل امنیتی گزارش شده است.
این سیستم توسط یک ساختار فدرال از سازمانها و Vendorهای مختلف مدیریت میشه و برای هماهنگ کردن ارجاع به آسیبپذیری ها استفاده میشه.
اما اینجا یک نکته مهم وجود داره.
هر چیزی که CVE بگیره، الزاماً از نظر فنی یک آسیب پذیری قابلاستفاده نیست.
دو مثال جالب بررسی شده:
CVE-2020-19909 در curl
و
CVE-2020-21469 در PostgreSQL
در این موارد، درباره اینکه آیا واقعاً یک Security Vulnerability محسوب می
شن یا نه، اختلاف نظر وجود داشته.
دلیلش اینه که صرفاً وجود یک رفتار غیرمنتظره یا حتی یک مشکل نرمافزاری کافی نیست.
باید ببینیم آیا این مشکل واقعاً میتونه باعث یک Security Impact بشه یا نه.
اینجاست که بحث پست قبلی دوباره مهم می
شه:
Bug ≠ Vulnerability
پس وقتی یک CVE میبینی، فقط به Severity یا عدد CVSS نگاه نکن.
اول بفهم:
چه چیزی آسیب پذیره؟
اتکر چه دسترسی ای داره؟
چه چیزی میتونه Trigger بشه؟
و در نهایت چه Security Impactی ایجاد می
شه؟
یک شماره CVE به تنهایی تحلیل امنیتی انجام نمیده.
کار Researcher اینه که پشت اون شماره رو بفهمه.
📌 نکته این قسمت:
اCVE یک Reference است، نه جایگزین تحلیل فنی.
در Vulnerability Research باید از خود مشکل شروع کنی، نه از عدد CVE.
@PfkSecurity
#از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #CVE #ZeroDay #CyberSecurity #RedTeam
❤4
درود خدمت دوستان گرامی بنده اینجا روی حملات اکتیو دایرکتوری و مباحث ردتیم تمرکز خواهم کرد و سناریوها و معرفی و اطلاعات جامع در مورد پروتکل ها و موارد دیگر که تجربه بنده هست رو در اختیار شما عزیزان قرار میدهم .
@KavehOffSec
@KavehOffSec
❤4👍2👎1
🔖 فقط یه FOFA dork ساده که خودم ساختم رو دراپ میکنم تا همه نسخههای vulnerable Grafana رو که از AWS استفاده میکنن پیدا کنه این بهت کمک میکنه تمام cloud metadata رو از طریق Grafana SSRF CVE-2025-4123 بخونی.
FOFA dork:
@TryHackBox
#باگ_بانتی #دورک #fofa
FOFA dork:
app="grafana" && cloud_name="aws" && (body="Grafana v10.0.0" body="Grafana v10.0.1" body="Grafana v10.0.2" body="Grafana v10.0.3" body="Grafana v10.0.4" body="Grafana v10.0.5" body="Grafana v10.0.6" body="Grafana v10.0.7" body="Grafana v10.0.8" body="Grafana v10.0.9" body="Grafana v10.0.10" body="Grafana v10.0.11" body="Grafana v10.0.12" body="Grafana v10.1.0" body="Grafana v10.1.1" body="Grafana v10.1.2" body="Grafana v10.1.3" body="Grafana v10.1.4" body="Grafana v10.1.5" body="Grafana v10.1.6" body="Grafana v10.1.7" body="Grafana v10.1.8" body="Grafana v10.1.9" body="Grafana v10.1.10" body="Grafana v10.2.0" body="Grafana v10.2.1" body="Grafana v10.2.2" body="Grafana v10.2.3" body="Grafana v10.2.4" body="Grafana v10.2.5" body="Grafana v10.2.6" body="Grafana v10.2.7" body="Grafana v10.3.0" body="Grafana v10.3.1" body="Grafana v10.3.2" body="Grafana v10.3.3" body="Grafana v10.3.4" body="Grafana v10.3.5" body="Grafana v10.4.0" body="Grafana v10.4.1" body="Grafana v10.4.2" body="Grafana v10.4.3" body="Grafana v10.4.4" body="Grafana v10.4.5" body="Grafana v10.4.6" body="Grafana v10.4.7" body="Grafana v10.4.8" body="Grafana v10.4.9" body="Grafana v10.4.10" body="Grafana v10.4.11" body="Grafana v10.4.12" body="Grafana v10.4.13" body="Grafana v10.4.14" body="Grafana v10.4.15" body="Grafana v10.4.16" body="Grafana v10.4.17" body="Grafana v11.0.0" body="Grafana v11.0.1" body="Grafana v11.0.2" body="Grafana v11.0.3" body="Grafana v11.0.4" body="Grafana v11.0.5" body="Grafana v11.1.0" body="Grafana v11.1.1" body="Grafana v11.1.2" body="Grafana v11.1.3" body="Grafana v11.1.4" body="Grafana v11.2.0" body="Grafana v11.2.1" body="Grafana v11.2.2" body="Grafana v11.2.3" body="Grafana v11.3.0" body="Grafana v11.3.1" body="Grafana v11.3.2" body="Grafana v11.3.3" body="Grafana v11.4.0" body="Grafana v11.4.1" body="Grafana v11.4.2" body="Grafana v11.4.3" body="Grafana v11.5.0" body="Grafana v11.5.1" body="Grafana v11.5.2" body="Grafana v11.5.3" body="Grafana v11.5.4" body="Grafana v11.5.5" body="Grafana v11.5.6" body="Grafana v11.6.0" || body="Grafana v12.0.0")
کدوم نسخه Grafana رو با این FOFA dork شکار کردی که SSRF CVE-2025-4123 رو trigger کرد و metadata AWS رو leak داد؟ تجربت رو کامنت کن
@TryHackBox
#باگ_بانتی #دورک #fofa
❤5👍1
Forwarded from Try Hack Box
🔥 نکتهای برای باگ بانتی: بایپس احراز هویت
بسیاری از توسعه دهندگان بر روی محافظت های پیچیده در قسمت جلویی (فرانتاند) تمرکز میکنند، در حالی که قسمت پشتی (بکاند) را کاملاً باز می گذارند.
بررسی های سریع که نتیجه بخش هستند:
آنها را در ابتدای هر برنامه تست کنید.
علاقه خود را به این پست ها با 🔥 نشان دهید.
@TryHackBox
#باگ_بانتی
بسیاری از توسعه دهندگان بر روی محافظت های پیچیده در قسمت جلویی (فرانتاند) تمرکز میکنند، در حالی که قسمت پشتی (بکاند) را کاملاً باز می گذارند.
بررسی های سریع که نتیجه بخش هستند:
1. دسترسی مستقیم به بخش مدیریت
تلاش کنید تا به آدرس های /admin، /dashboard، /panel، /cp بدون ورود به سیستم دسترسی پیدا کنید.
اغلب، هیچ تغییر مسیری (redirect) یا بررسی احراز هویت مناسبی وجود ندارد.
2. بایپس احراز هویت دو مرحلهای (2FA)
- با تغییر درخواست، مرحلهی 2FA را دور بزنید (پارامتر 2fa را حذف کنید یا آن را روی true تنظیم کنید).
- پس از اولین مرحلهی موفق، درخواست ورود به سیستم را دوباره ارسال کنید.
- سعی کنید از پارامترهایی مانند ?bypass=1 یا پارامترهای پنهان مشابه استفاده کنید.
3. افشای توکن بازنشانی رمز عبور
بررسی کنید که آیا توکن بازنشانی رمز عبور در پاسخ JSON، کد منبع صفحه یا ایمیل تأییدیه قبل از کلیک کاربر بر روی لینک، نمایش داده میشود یا خیر.
نکتهی مهم: این باگ های "ساده" بسیار رایج تر از اکسپلویت های پیچیده هستند و اغلب منجر به آسیبپذیری های حیاتی و بانتی های خوبی می شوند.
آنها را در ابتدای هر برنامه تست کنید.
علاقه خود را به این پست ها با 🔥 نشان دهید.
@TryHackBox
#باگ_بانتی
🔥5