¡No caigas en manos de tramposos! Telemetrio encuentra y marca estos canales 👉 Si quieres ver la etiqueta, suscríbete

P.F.K Security

Ir al canal en Telegram

APT / Exploit / Malware / ICS / OT / Vulnerability Analysis / SE

Irán88 099La categoría no está especificada

2 100

Suscriptores

+124 horas

-27 días

-130 días

229

Visitas de la publicación

~ 18024 horas

~ 28148 horas

10.90%

Tasa de compromiso

~ 1

Mensajes por día

Ads index

beta

Archivo de publicaciones

2 100

Repost from Try Hack Box

حل چلنچ دوم : Race Against Trust : THB CTF حل CTF توسط اقا احمد عزیز از اعضای کانال . @TryHackBox #CTF_THB

2 100

Repost from Try Hack Box

حل چلنچ دوم : Race Against Trust : THB CTF حل CTF توسط اقا ایمان عزیز از اعضای کانال . @TryHackBox #CTF_THB

2 100

Repost from Try Hack Box

🛡️ SAML SECURITY SERIES | PART 03 ا💥 XML Attacks : وقتی خود Parser تبدیل به Attack Surface میشه قسمت قبل رفتیم سراغ XSW (XML Signature Wrapping). حالا یه سؤال که خیلی وقت‌ ها ازش رد می‌شیم: فرض کن Signature رو بررسی کردی. درست هم Validate شد. میتونی بگی: «خب، پس SAML امنه.» نه. چون یه لایه‌ی دیگه هنوز سر جاشه: XML. اSAML شدیداً به XML وابسته است. یعنی حتی اگر منطق Authentication و Signature Validation درست پیاده‌سازی شده باشن، هنوز نحوه‌ی پردازش XML میتونه خودش یک Attack Surface باشه. اینجا اولین چیزی که ارزش بررسی داره: DTD Processing چرا؟ چون اگر XML Parser اجازه‌ی پردازش DTD یا External Entityها رو بده، ممکنه وارد یک دسته‌ی کاملاً متفاوت از حملات بشیم: 🔹 XXE — XML External Entity 🔹 XML DoS 🔹 Billion Laughs Attack این مشکلات لزوماً به Signature مربوط نیستن. حتی ممکنه Signature کاملاً معتبر باشه، ولی XML Parser رفتار ناامنی داشته باشه. پس وقتی یک SAML Endpoint جلوی شماست، فقط نپرسید: «Signature اوکیه؟» یه قدم عقب‌ تر برید. بپرسید: اXML چطور Parse میشه؟ اDTD چطور Handle میشه؟ اExternal Entityها اجازه‌ی پردازش دارن؟ اParser با XMLهای غیرعادی یا Malformed چطور رفتار میکنه؟ اینجا دقیقاً همون جاییه که طرز فکر Security Tester مهم میشه. چون هدف فقط پیدا کردن یک Payload نیست. اول باید بفهمی: اApplication دقیقاً چطور XML رو پردازش میکنه؟ یک SAML Implementation ممکنه از نظر Signature Validation کاملاً درست باشه... ولی XML Parser اون همچنان می‌تونه یک Attack Surface مستقل داشته باشه. و این دو موضوع رو نباید با هم قاطی کرد. حالا نوبت شماست فرض کن رسیدی به یک SAML Endpoint. قبل از اینکه بری سراغ Authentication Logic، فقط اجازه داری یکی از این موارد رو بررسی کنی: 1️⃣ DTD Processing 2️⃣ External Entities 3️⃣ Entity Expansion 4️⃣ رفتار Parser در برابر XMLهای غیرعادی / Malformed کدوم رو انتخاب میکنی؟ و مهم‌ تر: چرا همون یکی؟ میخوام ببینم انتخابت بر اساس Attack Surface و رفتار Applicationه... یا فقط چون اسم یک Vulnerability رو شنیدی. @TryHackBox #امنیت_سایبری #تست_نفوذ

2 100

Repost from Try Hack Box

🧩 WINDOWS INTERNALS FIELD NOTES #01 اException Handling فقط برای Crash کردن برنامه نیست وقتی یک برنامه در Windows با یک Exception مواجه می‌ شود، اولین چیزی که معمولاً به ذهنمان می‌رسد این است: «خب، برنامه خطا داد.» اما از دید یک Reverse Engineer، سؤال مهم‌تر این است: بعد از رخ دادن Exception، چه چیزی تصمیم میگیرد Execution کجا ادامه پیدا کند؟ اینجا Exception Handling وارد ماجرا می‌شود. فرض کن برنامه این دستور را اجرا می‌کند: int *ptr = NULL; *ptr = 1337; طبیعتاً CPU نمی‌تواند این Memory Access را انجام دهد و یک Exception ایجاد می‌شود. اما داستان همان‌جا تمام نمیشود. اWindows Exception را دریافت میکند و وارد یک مسیر مشخص برای پیدا کردن Handler مناسب میشود. به زبان ساده:

Instruction ↓ Exception ↓ Windows Exception Dispatcher ↓ Exception Handler ↓ Handle / Continue / Terminate

و همین مسیر ساده، یک نکته مهم دارد: اException می‌تواند روی مسیر اجرای برنامه تأثیر بگذارد. First-Chance و Second-Chance Exception در Debugging با این دو مفهوم زیاد برخورد می‌کنید. First-Chance Exception اولین مرحله‌ای است که Exception به Debugger و سپس مکانیزم Exception Handling ارائه میشود. اگر برنامه Handler مناسبی داشته باشد، ممکن است Exception مدیریت شود و Execution ادامه پیدا کند. اگر نه، Exception دوباره در مسیر Handling بررسی می‌شود. در نهایت اگر هیچ Handler مناسبی پیدا نشود: Second-Chance Exception یعنی دیگر جایی برای Handle کردن Exception باقی نمانده و معمولاً Process به پایان میرسد. برای همین وقتی در x64dbg یا WinDbg با Exception مواجه میشوید، نباید فوراً فرض کنید: «برنامه Crash کرد.» باید بپرسید: این Exception چرا ایجاد شد؟ چه کسی آن را Handle می‌کند؟ و Execution بعد از آن کجا ادامه پیدا می‌کند؟ اینجا موضوع برای Security جالب میشود یک Exception Handler می‌تواند صرفاً برای مدیریت خطا استفاده شود. اما اگر کسی عمداً Exception ایجاد کند و از Handler برای تغییر مسیر Execution استفاده کند چه؟ آن‌ وقت Exception Handling دیگر فقط یک مکانیزم Error Handling نیست. می‌تواند تبدیل شود به یک Control-Flow Primitive. در Malware و بعضی تکنیک‌ های Anti-Analysis، این رفتار می‌تواند برای سخت‌تر کردن تحلیل برنامه استفاده شود. اAnalyst ممکن است یک مسیر Execution را دنبال کند، اما بخشی از Control Flow از طریق Exception اتفاق بیفتد.

Normal Flow ↓ Instruction ↓ Exception ↓ Handler ↓ Modified Context ↓ Different Execution Flow

و این دقیقاً جایی است که باید نگاه Reverse Engineer از «چه خطایی رخ داده؟» به «این Exception چه نقشی در Control Flow دارد؟» تغییر کند. 🎯 چیزی که باید از این قسمت یاد بگیری هر Exception را Crash در نظر نگیر. وقتی در یک Binary رفتار غیرعادی دیدی، این چند سؤال را از خودت بپرس: اException از کجا Trigger شد؟ اException Code چیست؟ چه Handlerای آن را دریافت می‌کند؟ اHandler چه تغییری در Execution ایجاد می‌کند؟ آیا Instruction Pointer بعد از Handler تغییر می‌کند؟ آیا Exception بخشی از Logic برنامه است یا صرفاً Error Handling؟ @TryHackBox #WindowsInternals #ReverseEngineering #MalwareAnalysis #x64dbg #CyberSecurity

2 100

Repost from Try Hack Box

🧨 WEB PENTESTING FIELD NOTES #03 یک اشتباه رایج در تست XSS یه چیزی توی Search Box وارد میکنی. بر‌ میگرده توی صفحه. بعد اولین فکری که میاد: «خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.» اینجا دقیقاً جاییه که خیلی از تست‌ ها اشتباه شروع میشن. قبل از Payload، من معمولاً یه سؤال ساده‌تر می‌پرسم: این Input دقیقاً کجا قرار گرفته؟ داخل HTML؟ داخل یک Attribute؟ داخل JavaScript؟ توی URL؟ یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی می‌خونه و وارد DOM میکنه؟ چون این: <input> به‌‌ تنهایی چیزی بهت نمیگه. مهم اینه که Application و Browser باهاش چه رفتاری میکنن. یه سناریوی ساده: تو Search میزنی: THB صفحه هم نشون میده: Search results for: THB خوبه. حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن. Input → Source → Data Flow → Sink → Context → Execution اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می‌ فهمی باید دنبال چه چیزی بگردی. حالا سه حالت اصلی XSS رو از هم جدا کن: 🔹 Reflected XSS اInput از Request میاد و در Response برمیگرده. 🔹 Stored XSS اInput ذخیره می‌شه و بعداً وقتی یک User دیگه صفحه رو می‌بینه، Render میشه. 🔹 DOM-Based XSS این یکی جالب‌ تره. ممکنه Server اصلاً چیزی از Payload نبینه. جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه. یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی. حالا یه سؤال برای خودت: فرض کن مقدار زیر رو وارد کردی: THB123 و این مقدار داخل HTML صفحه ظاهر شد. آیا همین به معنی XSS Vulnerability هست؟

اگر جوابت «بله» یا «نه» هست، دلیلش رو هم بنویس. ببینیم چند نفر واقعاً Context رو بررسی میکنن، نه فقط دنبال Payload می‌ گردن.

@TryHackBox #تست_نفوذ #امنیت_سایبری

2 100

Repost from N/a

اینم یه کادوی تولد از طرف ادمین به شما عزیزای همیشگی 😍🎁

2 100

Repost from N/a

2 100

Repost from ᴠɪᴩ

انگلیسی با فیلم و داستان 🔹JOIN پکیج های ناب بورسی و موفقیت 🔸JOIN آموزش حرفه ای پایتون و هوش مصنوعی 🔹JOIN خود آموزهای زبان انگلیسی 🔸JOIN موفقیت ، استخدامی ، پول پارو کن 🔹JOIN بانک تمامی پکیج های پولی رایگان 🔸JOIN مبتکر یادگیری زبان انگلیسی در منزل 🔹JOIN تست و آزمونهای آنلاین رایگان برای حسابداران 🔸JOIN آموزش ذهن و قوانین کائنات 🔹JOIN سیرتاپیاز هک و امنیت رو قورت بده 🔸JOIN گرامر کامل انگلیسی 🔹JOIN ورزش | سلامتی | باشگاه 🔸JOIN مرجع ایمووی های خاص 🔹JOIN آموزش مفتی هوش مصنوعی و 🇮‌‌🇹 🔸JOIN یادگیری انگلیسی سخت نیست 🔹JOIN مرجع اصطلاحات و اسلنگ 🔸JOIN پاب شدن تمامی پکیج های پولی‌ 🔹JOIN سیرتاپیاز برنامه نویسی رو قورت بده 🔸JOIN سیر تا پیاز انگلیسی قورت بده 🔹JOIN مرجع آهنگ‌ انگلیسی و فرانسوی 🔸JOIN یادگیری مکالمه انگلیسی در منزل 🔹JOIN بانک بزرگ استخدامی رایگان VIP 🔸JOIN سیگنال رایگان ارز دیجیتال با سود بالا 🔹JOIN کودکان دو زبانه به روش علمی 🔸JOIN خودآموز آیلتس و تافل 🔹JOIN ترفند های طلایی کامپیوتر و موبایل 🔸JOIN منبع تمام بازی های هک شده 🔹JOIN 2 ترابایت پکیج اموزشی و پولی 🔸JOIN آموزش کامل « دستورات ترموکس » 🔹JOIN اجتماع بزرگ حقوق خواندگان 🔸JOIN آموزش 0/100 اکسل، حسابداری و مالی 🔹JOIN پروکسی؛ V2RAYNG رایگان؛ VPN مود شده 🔸JOIN مرجع آموزش تخصصی روابط بین‌الملل 🔹JOIN آموزش کامل اهنگسازی - ریمیکس 🔸JOIN هر ترفندی میخوای رایگان دانلود کن 🔹JOIN آموزش تخصصی اکسل، حسابداری و بورس 🔸JOIN اموزش مفتی 0 تا 100 هک 🔹JOIN ترفندهای هوش مصنوعی عکاسی 🔸JOIN 2ترابایت پکیج هک در دسترس عموم 🔹JOIN آموزش مفتی دوره ای Sans 🔸JOIN کارپاره وقت دانشجویی با حقوق بالا 🔹JOIN پکیج های 2020 تا 2026 🔸JOIN بانک مقالات، پروپوزال، پایاننامه و رساله 🔹JOIN آموزش مفتی برنامه نویسی و امنیت 🔸JOIN مطالب و جزوه های حسابداری 🔹JOIN فول انگلیسی صحبت کن 🔸JOIN ذهن آهنین؛ مسیر رایگان موفقیت و ثروت 🔹JOIN دنیای کاریابی و استخدام 🔸JOIN آموزش مفتی برنامه نویسی (100% رایگان) 🔹JOIN کانفیگ؛پل ارگو؛فالکن؛منبع کلی فیلترشکن 🔸JOIN آموزش صفرتاصد طراحی وب + سئو 🔹JOIN آموزش پایه تا پیشرفته امنیت و هک 🔸JOIN کاریابی دانشجویی / درآمدزایی 🔹JOIN مرجع کامل آهنگ‌های سه‌بعدی (3D) 🔸JOIN منبع بیو و والپیپرهای خفن 🔹JOIN 0تا 100 اموزش ترجمه انگلیسی و مقاله ها 🔸JOIN استخدام استخدام 🔹JOIN منبع برنامه‌های مود شده اندروید 🔸JOIN استخدام سراسری دانشجویان 🔹JOIN ترانہ های نوستالژی 🔸JOIN ارزش این کانال 200میلیون تخمین شده 🔹JOIN دانستنی‌های ضروری حقوقی 🔸JOIN نکات کاربردی TOEFL و IELTS 🔹JOIN کیهانشناسی و کوانتوم 🔸JOIN آموزش هک و امنیت از سطح صفر 🔹JOIN آموزش رایگان اقتصاد و بورس از مبتدی تا حرفه‌ای 🔸JOIN آموزش تکنیک های زبان انگلیسی 🔹JOIN هنر خوانش و تحلیل متن 🔸JOIN بانک آگهی های استخدامی 🔹JOIN کسب درامد دلاری فقط اینجا 🔸JOIN صفر تا صد‌🇪‌‌🇩‌‌🇮‌‌🇹‌با موبایل 🔹JOIN آموزش جامع هک و امنیت 100% رایگان 🔸JOIN آموزش مقاله نویسی با هوش مصنوعی 🔹JOIN کانال VIP ما رایگان شد 🔸JOIN پادکست رایگان انگلیسی 🔹JOIN پکیج های قانون زندگی و توسعه فردی 🔸JOIN اموزش کاریزما و ایده رابطه 🔹JOIN فول پکیج های پولی رو رایگان دانلود کنید 🔸JOIN آرشیو جامع کتابخانه مجازی 🔹JOIN خرید مقاله، سایتیشن و ثبت اختراع 🔸JOIN

2 100

Repost from Try Hack Box

🔐 THB CTF Team Qualification : Challenge #02 - Race Against Trust دسته: Web Pentesting / Business Logic سطح سختی: Hard پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox 📖 سناریو اTrustPay یه پلتفرم پرداخت داخلیه که تو کل شرکت برای صدور Invoice و انتقال وجه بین بخش‌‌ها استفاده میشه. کارمندها میتونن Invoiceهاشون رو ببینن، مرجع صورت‌حساب رو جستجو کنن، و موجودی حسابشون رو پیگیری کنن. شما به‌عنوان یه پنتستر خارجی استخدام شدید. یه اکانت کارمند عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره. 🎯 هدف: دسترسی به پنل Treasury و گرفتن Flag. هیچ آسیب‌پذیری به‌ تنهایی شما رو به هدف نمیرسونه. این چالش نیاز به زنجیره‌کردن چند تا ضعف داره، فهمیدن اینکه چرا هر مرحله به‌تنهایی کافی نیست. ⚙️ نحوه اجرا

docker compose up --build

یا

./start.sh

اپلیکیشن روی آدرس زیر بالا میاد:

http://localhost:8002

فرمت فلگ : THB{ } ارسال فلگ : @Unique_exploitbot قوانین و توضیحات تکمیلی @TryHackBox #CTF_THB

2 100

Repost from Try Hack Box

حل چلنچ : The Broken Trust : THB CTF سناریوی حل چالش توسط اقا آرمین عزیز از اعضای کانال . @TryHackBox #CTF_THB

2 100

Repost from Try Hack Box

THB CTF Team Qualification : Challenge #01 The Broken Trust دسته: Web Pentesting سطح سختی: Hard پروژه: TCTQ : مسیر پذیرش تیم CTF TryHackBox 📖 سناریو شرکت خیالی Trustonic Corp یه پورتال داخلی کارمندی جدید راه‌اندازی کرده. HR، دایرکتوری بخش‌ها، تنظیمات حساب کاربری همه پشت یه صفحه لاگین قرار گرفته و تیم فنی‌شون مطمئنه که آماده‌ی audit هست. شما به‌ عنوان یه پنتستر خارجی استخدام شدید. کارتون رو با هیچی شروع کنید فقط یه فرم ثبت‌نام ساده و ببینید یه اکانت کارمند عادی تا کجا میتونه شما رو پیش ببره. 🎯 هدف: رسیدن به پنل Administrator و گرفتن Flag. ⚙️ نحوه اجرا

docker compose up --build

سرویس روی آدرس زیر بالا میاد:

http://localhost:8001

یه اکانت برای خودتون بسازید نیازی به حدس‌ زدن یا brute-force کردن اکانت‌ های موجود نیست. فرمت فلگ : THB{ } ارسال فلگ : @Unique_exploitbot قوانین و توضیحات تکمیلی @TryHackBox #CTF_THB

2 100

استخراج تنظیمات IcedID https://txc.gitbook.io/documentation/writeups/icedid-config-extraction @PfkSecurity

2 100

Repost from Try Hack Box

ا📌 Source Code رو از نگاه یک Pentester چطور بررسی کنیم؟ وقتی توی تست نفوذ به Repository دسترسی داری، قرار نیست فقط بشینی کد رو خط‌ به‌ خط بخونی. چیزی که برای من مهم‌ تره اینه که بفهمم کجاهایی از Attack Surface از بیرون دیده نمیشن. مثلاً یک Endpoint که از بیرون پیدا نکردیم، یک Background Job، یک File Handler یا جایی که Authorization فقط توی بعضی مسیرها انجام شده. معمولاً کار رو اینطوری جلو میبرم: اول یک SAST نسبتاً گسترده اجرا میکنم و چیزهایی مثل Dependencyها، Generated Code و Testها رو تا حد ممکن از نتایج کنار میذارم. بعد دیگه قرار نیست تک‌تک Alertها رو باور کنیم. برای هر مورد باید برگردیم به Code و مسیر رو دنبال کنیم:

Entry Point → Data Flow → Validation → Dangerous Sink

مثلاً اگر یک Input کاربر به یک SQL Query میرسه، باید ببینیم واقعاً همین مسیر در Application قابل دسترسیه؟ داده Sanitize یا Parameterize شده؟ و در نهایت واقعاً چه اثری برای مهاجم داره؟ همین موضوع برای File Operation، Deserialization، Secrets، Access Control و Business Logic هم صدق میکنه. یکی از اشتباهات رایج اینه که:

SAST Alert = Vulnerability

نه. ممکنه کد مربوط به Test باشه، مسیر اصلاً Reachable نباشه یا قبل از رسیدن به Sink یک Security Control درست وجود داشته باشه. برای همین Finding خوب باید یک Chain قابل اثبات داشته باشه. از کجا شروع شد؟ کجا رفت؟ کجا به نقطه خطرناک رسید؟ مهاجم دقیقاً چه کاری میتونه انجام بده؟ و مهم‌ تر از همه چی باید Fix بشه؟ به‌نظرم ارزش Code Analysis این نیست که ۲۰۰ تا Alert تحویل بدیم. ارزشش اینه که از بین اون ۲۰۰ مورد، چند Finding واقعی و قابل اثبات پیدا کنیم. @TryHackBox @TryHackBoxOfficial @AiTHB @RadioZeroPod

2 100

Repost from Try Hack Box

🔥 #باگ_بانتی فکر کنم این یکی برای بیشتر باگ‌ هانترها آشنا باشه چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده. برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده. برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل‌ توجهی نداره؟

اگه تجربه جالبی داشتید، بدون اشاره به اسم تارگت برامون بنویسید.

لینک گروه جهت مشارکت : https://t.me/+XPV3S0tygl1lZGE0 TryHackBox | Ai Sec | Radio | RoadMap

2 100

Repost from Try Hack Box

📌 استفاده از ماشین‌های مجازی برای بایپس کردن ابزارهای امنیتی 📌 مهاجمان همچنان به آزمایش با پلتفرم‌ های مختلف مدیریت از راه دور 📌 مینی دوره #رایگان نصب و راه‌اندازی لابراتورهای تست نفوذ وب قسمت اول 📌 فکر می‌کنید، xss نمی‌ تواند در اندپوینت .html فعال شود؟ 📌 کجا می‌ توان به صورت قانونی LLM را هک کرد؟ 📌 درک معماری های سندباکس 📌 بررسی تهدیدها : OWASP Top 10 برای LLM 📌 بازنشانی رمز عبور منقضی شده حساب دامنه از طریق null-session و SAMR 📌 جستجو برای فایل‌های رمزگذاری شده 📌 نشت اطلاعات حساس و عدم وجود مجوز از طریق اندپوینت API 📌 دستورات کاربردی و سریع برای Host & Network Discovery و Service Enumeration و Web Enumeration 📌 بایپس احراز هویت از طریق Forged Session Cookie 📌 هک سیستم ‌های SCADA : پیداکردن سیستم ‌های SCADA با استفاده از Censys ا📌 AMSI Bypass و چالش‌های اجرای PowerShell در محیط‌های ویندوزی 📌 نکته‌ای برای باگ بانتی: بایپس احراز هویت 📌 دورک های مفید برای باگ هانترها 📌 جمع‌ آوری اطلاعات سریع‌ تر 📌 100 آسیب پذیری وب 📌 یه Google Dork ساده، ولی با ... 📌 شروع دوره #رایگان Network+

2 100

Repost from Try Hack Box

$⭕ یک خط برای پیدا کردن فایل‌ ها subfinder -d domain.com -silent | \ while read host; do \ for path in /config.js /config.json$

⭕ یک خط برای پیدا کردن فایل‌ ها

subfinder -d domain.com -silent | \
while read host; do \
 for path in /config.js /config.json /app/config.js /settings.json /database.json /firebase.json /.env /.env.production /api_keys.json /credentials.json /secrets.json /google-services.json /package.json /package-lock.json /composer.json /pom.xml /docker-compose.yml /manifest.json /service-worker.js; do \
  echo "$host$path"; \
 done; \
done | httpx -mc 200

@TryHackBox #باگ_بانتی

2 100

برای پیدا کردن یک Vulnerability، چقدر باید از داخل نرم‌ افزار بدونی؟ فرض کن قراره یک نرم‌ افزار رو از نظر امنیتی بررسی کنی. سه حالت داری :

1. Black-box به سورس‌ کد دسترسی نداری و نرم‌افزار رو از بیرون بررسی میکنی. ورودی‌ ها رو تغییر میدی، رفتار برنامه رو میبینی و دنبال حالتی میگردی که نتیجه غیرمنتظره‌ای ایجاد کنه.باید از روی رفتار برنامه، درباره اتفاقاتی که داخلش می‌ افته فرضیه بسازی. 2. Gray-box بخشی از اطلاعات داخلی رو در اختیار داری. مثلاً مستندات فنی، اطلاعات معماری یا دسترسی محدود به بعضی بخش‌ های سیستم. این اطلاعات کمک میکنن مسیر بررسی رو دقیق‌ تر انتخاب کنی. 3. White-box اینجا میتونی به سورس‌ کد یا اطلاعات داخلی کامل‌ تری دسترسی داشته باشی. میتونی مسیر اجرای برنامه رو دنبال کنی، نحوه اعتبارسنجی ورودی‌ ها رو بررسی کنی و ببینی داده‌ها چطور به بخش‌ های حساس میرسن. این رویکرد در Code Review اهمیت زیادی داره.

اما یک نکته رو فراموش نکن: دسترسی بیشتر، به‌ تنهایی به معنی پیدا کردن Vulnerability نیست. حتی با دسترسی کامل به سورس‌ کد، باید بدونی دنبال چه الگویی بگردی و چطور فرضیه‌ات رو آزمایش کنی. از طرف دیگه، Black-box هم لزوماً به معنی بررسی سطحی نیست. بعضی ضعف‌ ها فقط با آزمایش دقیق رفتار نرم‌افزار مشخص میشن. پس انتخاب روش به هدف تحقیق، اطلاعات در دسترس و ابزارهایی که داری بستگی داره. @PfkSecurity #از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #CodeReview #CyberSecurity #ZeroDay

2 100

Repost from Try Hack Box

🌐 Web Pentesting | Field Notes - #02 SQL Injection را با SQLmap شروع نکنید یکی از رایج‌ ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می‌ کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable». پیش از آن‌که حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید. فرض کنید به این درخواست رسیده‌اید:

GET /products?id=42

اول دست نزنید. رفتار عادی برنامه را مشاهده کنید: کد پاسخ چیست؟ طول پاسخ چقدر است؟ چه محتوایی برمی‌ گردد؟ خطایی دیده می‌ شود؟ آیا پاسخ تغییر می‌ کند؟ تفاوتی در زمان پاسخ‌ دهی وجود دارد؟ سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید. اگر با تغییر مقدار id، پاسخ به شکل قابل‌ توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است. در این نقطه باید فرضیه بسازید: «ممکن است این پارامتر در یک کوئری پایگاه‌داده استفاده شود.» حالا تست واقعی آغاز می‌شود. و اینجا یک نکتهٔ حیاتی وجود دارد: اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد. در Blind SQL Injection ممکن است: هیچ خطای پایگاه‌داده‌ای نبینید. هیچ داده‌ای مستقیماً برنگردد. و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد. اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می‌ تواند سیگنال مهمی باشد. پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که: «چه پیلود دیگری بزنم؟» سؤال درست این است: «چه چیزی را میتوانم اندازه‌گیری و مقایسه کنم؟» پاسخ؟ رفتار بولین؟ طول پاسخ؟ زمان پاسخ‌دهی؟ محتوا؟ اینجاست که مرز میان یک جمع‌ کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود. اSQLmap ابزار فوق‌العاده‌ای است. اما قرار نیست به‌جای شما برنامه را بفهمد. شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریع‌تر کند. اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیب‌پذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد. و این برای یک پنتستر حرفه‌ای کافی نیست. @TryHackBox #تست_نفوذ #امنیت_سایبری

2 100

Repost from Try Hack Box

🌐 Web Pentesting | Field Notes - #01 قبل از اینکه Payload بفرستی، اول ببین اصلاً کجا باید بفرستی. یکی از رایج‌ ترین اشتباهات پنتسترهای تازه‌کار اینه که خیلی زود میپرن سراغ SQLi، XSS، یا اجرای یک Automated Scanner. اما یک پنتستر باتجربه، قبل از هر چیز، یک سؤال ساده‌تر از خودش میپرسه: "این اپلیکیشن کجا به من اجازه میده روی رفتار سرور اثر بذارم؟" در یک Assessment واقعی، صرفاً به فرم لاگین بسنده نکن. دنبال این‌ها بگرد:

URL / Query Parameters JSON Body Headers و Cookies File Upload Search و Filters Export / Download Password Reset API Endpoints Admin Functions Redirect Parameters

یک مثال ساده:

Code
GET /profile?id=123

برای یک پنتستر، این فقط یک URL نیست. id=123 یعنی احتمالاً یک Object در سمت سرور وجود داره که براساس یک Identifier پیدا میشه. حالا سؤال اصلی اینه: سرور فقط میپرسه "چه Objectی درخواست شده؟"، یا واقعا چک میکنه "آیا این کاربر مجاز به دیدن این Object هست؟" همین تفاوت ظریف، میتونه یک تست ساده رو به کشف یک IDOR واقعی تبدیل کنه.

🎯 طرز فکر یک پنتستر: Input → Processing → Authorization → Output → Impact

@TryHackBox #تست_نفوذ #امنیت_سایبری

2 100

Repost from Try Hack Box

🛡️ SAML SECURITY SERIES | PART 02 🎫 Signature Wrapping وقتی Signature معتبره، ولی Application چیز دیگه‌ای رو میخونه! در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست. حالا بریم سراغ یکی از معروف‌ ترین مشکلات امنیتی SAML: XML Signature Wrapping یا XSW اسمش شاید کمی پیچیده به نظر برسه، ولی ایده‌ی اصلیش خیلی ساده‌ تره. فرض کنید یک SAML Response داریم. داخل این Response یک Assertion وجود داره. روی این Assertion هم یک Digital Signature قرار گرفته. اپلیکشن باید مطمئن بشه که: ا🔐 Signature واقعاً معتبره. 📄 داده‌ای که Signature روی اون قرار گرفته، همون داده‌ایه که باید بررسی بشه. 📌 در نهایت، همون Assertion وارد فرآیند Authentication میشه. حالا مشکل کجاست؟ وقتی بین چیزی که Signature شده و چیزی که Application پردازش میکنه ارتباط درستی وجود نداشته باشه. در بعضی پیاده‌سازی‌ های آسیب‌پذیر، مهاجم میتونه ساختار XML رو طوری تغییر بده که Signature همچنان معتبر باقی بمونه. اما Application در ادامه، Node یا Assertion دیگری رو پردازش کنه. یعنی: اSignature معتبره. اما چیزی که Application بهش اعتماد میکنه، لزوماً همون چیزی نیست که Signature شده. به زبان ساده تر هم که : Signed Data ≠ Processed Data و دقیقاً همینجا مشکل امنیتی شکل میگیره. بسته به Implementation و شرایط موجود، این مسئله میتونه به موارد زیر منجر بشه: 🔹 Authentication Abuse 🔹 Privilege Escalation 🔹 Identity Validation Bypass اما یک نکته مهم دیگه هم وجود داره. اXSW فقط یک تکنیک واحد نیست. برای این حمله Variantهای مختلفی وجود داره که معمولاً با نام‌ های XSW1 تا XSW8 شناخته میشن. تفاوت این Variantها عمدتاً به نحوه‌ی قرار گرفتن و پردازش Nodeهای XML مربوط میشه. 🎯 حالا سؤال: اگر یک SAML Response داشته باشیم و Signature اون کاملاً معتبر باشه، آیا میتونیم با اطمینان بگیم Authentication امنه؟ یا باید بررسی کنیم که: اپلیکشن دقیقاً کدوم Node رو بعد از Validation پردازش میکنه؟ اگر جای یک پنتستر بودید، چطور مطمئن می‌شدید: اSigned Data همون Processed Data هست؟ نظرتون رو بنویسید 👇 @TryHackBox #تست_نفوذ #امنیت_سایبری