🛡️ 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
#تست_نفوذ #امنیت_سایبری
🎫 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
#تست_نفوذ #امنیت_سایبری
🔥2
🌐 Web Pentesting | Field Notes - #01
قبل از اینکه Payload بفرستی، اول ببین اصلاً کجا باید بفرستی.
یکی از رایج ترین اشتباهات پنتسترهای تازهکار اینه که خیلی زود میپرن سراغ SQLi، XSS، یا اجرای یک Automated Scanner. اما یک پنتستر باتجربه، قبل از هر چیز، یک سؤال سادهتر از خودش میپرسه:
"این اپلیکیشن کجا به من اجازه میده روی رفتار سرور اثر بذارم؟"
در یک Assessment واقعی، صرفاً به فرم لاگین بسنده نکن. دنبال اینها بگرد:
یک مثال ساده:
برای یک پنتستر، این فقط یک URL نیست. id=123 یعنی احتمالاً یک Object در سمت سرور وجود داره که براساس یک Identifier پیدا میشه.
حالا سؤال اصلی اینه: سرور فقط میپرسه "چه Objectی درخواست شده؟"، یا واقعا چک میکنه "آیا این کاربر مجاز به دیدن این Object هست؟"
همین تفاوت ظریف، میتونه یک تست ساده رو به کشف یک IDOR واقعی تبدیل کنه.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
قبل از اینکه 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🔥1
📚 کتابچه Kerberos For Pentesters
📌 یک راهنمای تخصصی برای شناخت Kerberos و نحوه استفاده از آن در تست نفوذ و Red Team محیطهای Active Directory.
این کتاب از مبانی شروع میکند و تلاش میکند قبل از ورود به تکنیکهای حمله، ساختار و منطق Kerberos را برای خواننده روشن کند. در ابتدا با تاریخچه و تکامل Kerberos، معماری Kerberos v5 و اجزای اصلی آن آشنا میشوید و سپس نحوه پیادهسازی این پروتکل در Active Directory بررسی میشود.
در بخش Active Directory، موضوعاتی مانند نقش Domain Controller بهعنوان KDC، ارتباط Kerberos با حسابهای کاربری و سرویسها، TGT و Service Ticket و مکانیزم Pre-authentication مورد بررسی قرار میگیرند.
📌 توضیحات تکمیلی
📕 نمونه کتاب
📄 صفحات : ۱۷۷
💰 قیمت اصلی : ۲۶۹,۰۰۰ هزارتومان
🔥برای ۳ نفر اول : ۱۹۹,۰۰۰ هزارتومان
📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
@KavehOffSec
@TryHackBox
📌 یک راهنمای تخصصی برای شناخت Kerberos و نحوه استفاده از آن در تست نفوذ و Red Team محیطهای Active Directory.
این کتاب از مبانی شروع میکند و تلاش میکند قبل از ورود به تکنیکهای حمله، ساختار و منطق Kerberos را برای خواننده روشن کند. در ابتدا با تاریخچه و تکامل Kerberos، معماری Kerberos v5 و اجزای اصلی آن آشنا میشوید و سپس نحوه پیادهسازی این پروتکل در Active Directory بررسی میشود.
در بخش Active Directory، موضوعاتی مانند نقش Domain Controller بهعنوان KDC، ارتباط Kerberos با حسابهای کاربری و سرویسها، TGT و Service Ticket و مکانیزم Pre-authentication مورد بررسی قرار میگیرند.
📌 توضیحات تکمیلی
📕 نمونه کتاب
📄 صفحات : ۱۷۷
💰 قیمت اصلی : ۲۶۹,۰۰۰ هزارتومان
🔥
📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
@KavehOffSec
@TryHackBox
❤1
Try Hack Box
🌐 Web Pentesting | Field Notes - #01 قبل از اینکه Payload بفرستی، اول ببین اصلاً کجا باید بفرستی. یکی از رایج ترین اشتباهات پنتسترهای تازهکار اینه که خیلی زود میپرن سراغ SQLi، XSS، یا اجرای یک Automated Scanner. اما یک پنتستر باتجربه، قبل از هر چیز، یک…
🌐 Web Pentesting | Field Notes - #02
SQL Injection را با SQLmap شروع نکنید
یکی از رایج ترین اشتباهها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable».
پیش از آنکه حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید.
فرض کنید به این درخواست رسیدهاید:
اول دست نزنید.
رفتار عادی برنامه را مشاهده کنید:
کد پاسخ چیست؟
طول پاسخ چقدر است؟
چه محتوایی برمی گردد؟
خطایی دیده می شود؟
آیا پاسخ تغییر می کند؟
تفاوتی در زمان پاسخ دهی وجود دارد؟
سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید.
اگر با تغییر مقدار id، پاسخ به شکل قابل توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است.
در این نقطه باید فرضیه بسازید:
«ممکن است این پارامتر در یک کوئری پایگاهداده استفاده شود.»
حالا تست واقعی آغاز میشود.
و اینجا یک نکتهٔ حیاتی وجود دارد:
اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد.
در Blind SQL Injection ممکن است:
هیچ خطای پایگاهدادهای نبینید.
هیچ دادهای مستقیماً برنگردد.
و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد.
اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می تواند سیگنال مهمی باشد.
پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که:
«چه پیلود دیگری بزنم؟»
سؤال درست این است:
«چه چیزی را میتوانم اندازهگیری و مقایسه کنم؟»
پاسخ؟
رفتار بولین؟
طول پاسخ؟
زمان پاسخدهی؟
محتوا؟
اینجاست که مرز میان یک جمع کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود.
اSQLmap ابزار فوقالعادهای است.
اما قرار نیست بهجای شما برنامه را بفهمد.
شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریعتر کند.
اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیبپذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد.
و این برای یک پنتستر حرفهای کافی نیست.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
SQL Injection را با SQLmap شروع نکنید
یکی از رایج ترین اشتباهها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable».
پیش از آنکه حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید.
فرض کنید به این درخواست رسیدهاید:
GET /products?id=42
اول دست نزنید.
رفتار عادی برنامه را مشاهده کنید:
کد پاسخ چیست؟
طول پاسخ چقدر است؟
چه محتوایی برمی گردد؟
خطایی دیده می شود؟
آیا پاسخ تغییر می کند؟
تفاوتی در زمان پاسخ دهی وجود دارد؟
سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید.
اگر با تغییر مقدار id، پاسخ به شکل قابل توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است.
در این نقطه باید فرضیه بسازید:
«ممکن است این پارامتر در یک کوئری پایگاهداده استفاده شود.»
حالا تست واقعی آغاز میشود.
و اینجا یک نکتهٔ حیاتی وجود دارد:
اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد.
در Blind SQL Injection ممکن است:
هیچ خطای پایگاهدادهای نبینید.
هیچ دادهای مستقیماً برنگردد.
و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد.
اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می تواند سیگنال مهمی باشد.
پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که:
«چه پیلود دیگری بزنم؟»
سؤال درست این است:
«چه چیزی را میتوانم اندازهگیری و مقایسه کنم؟»
پاسخ؟
رفتار بولین؟
طول پاسخ؟
زمان پاسخدهی؟
محتوا؟
اینجاست که مرز میان یک جمع کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود.
اSQLmap ابزار فوقالعادهای است.
اما قرار نیست بهجای شما برنامه را بفهمد.
شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریعتر کند.
اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیبپذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد.
و این برای یک پنتستر حرفهای کافی نیست.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
👍6❤1
⭕ یک خط برای پیدا کردن فایل ها
@TryHackBox
#باگ_بانتی
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
#باگ_بانتی
❤5
📌 استفاده از ماشینهای مجازی برای بایپس کردن ابزارهای امنیتی
📌 مهاجمان همچنان به آزمایش با پلتفرم های مختلف مدیریت از راه دور
📌 مینی دوره #رایگان نصب و راهاندازی لابراتورهای تست نفوذ وب قسمت اول
📌 فکر میکنید، 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+
📌 مهاجمان همچنان به آزمایش با پلتفرم های مختلف مدیریت از راه دور
📌 مینی دوره #رایگان نصب و راهاندازی لابراتورهای تست نفوذ وب قسمت اول
📌 فکر میکنید، 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+
🔥 #باگ_بانتی فکر کنم این یکی برای بیشتر باگ هانترها آشنا باشه
چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده.
برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده.
برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل توجهی نداره؟
لینک گروه جهت مشارکت :
https://t.me/+XPV3S0tygl1lZGE0
TryHackBox | Ai Sec | Radio | RoadMap
چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده.
برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده.
برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل توجهی نداره؟
اگه تجربه جالبی داشتید، بدون اشاره به اسم تارگت برامون بنویسید.
لینک گروه جهت مشارکت :
https://t.me/+XPV3S0tygl1lZGE0
TryHackBox | Ai Sec | Radio | RoadMap
🔥5
ا📌 Source Code رو از نگاه یک Pentester چطور بررسی کنیم؟
وقتی توی تست نفوذ به Repository دسترسی داری، قرار نیست فقط بشینی کد رو خط به خط بخونی.
چیزی که برای من مهم تره اینه که بفهمم کجاهایی از Attack Surface از بیرون دیده نمیشن.
مثلاً یک Endpoint که از بیرون پیدا نکردیم، یک Background Job، یک File Handler یا جایی که Authorization فقط توی بعضی مسیرها انجام شده.
معمولاً کار رو اینطوری جلو میبرم:
اول یک SAST نسبتاً گسترده اجرا میکنم و چیزهایی مثل Dependencyها، Generated Code و Testها رو تا حد ممکن از نتایج کنار میذارم.
بعد دیگه قرار نیست تکتک Alertها رو باور کنیم.
برای هر مورد باید برگردیم به Code و مسیر رو دنبال کنیم:
مثلاً اگر یک Input کاربر به یک SQL Query میرسه، باید ببینیم واقعاً همین مسیر در Application قابل دسترسیه؟ داده Sanitize یا Parameterize شده؟ و در نهایت واقعاً چه اثری برای مهاجم داره؟
همین موضوع برای File Operation، Deserialization، Secrets، Access Control و Business Logic هم صدق میکنه.
یکی از اشتباهات رایج اینه که:
نه.
ممکنه کد مربوط به Test باشه، مسیر اصلاً Reachable نباشه یا قبل از رسیدن به Sink یک Security Control درست وجود داشته باشه.
برای همین Finding خوب باید یک Chain قابل اثبات داشته باشه.
از کجا شروع شد؟
کجا رفت؟
کجا به نقطه خطرناک رسید؟
مهاجم دقیقاً چه کاری میتونه انجام بده؟
و مهم تر از همه چی باید Fix بشه؟
بهنظرم ارزش Code Analysis این نیست که ۲۰۰ تا Alert تحویل بدیم.
ارزشش اینه که از بین اون ۲۰۰ مورد، چند Finding واقعی و قابل اثبات پیدا کنیم.
@TryHackBox
@TryHackBoxOfficial
@AiTHB
@RadioZeroPod
وقتی توی تست نفوذ به 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
👍7❤1
thb-ctf-01-broken-trust.zip
14.4 KB
THB CTF Team Qualification : Challenge #01
The Broken Trust
دسته: Web Pentesting
سطح سختی: Hard
پروژه: TCTQ : مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
شرکت خیالی Trustonic Corp یه پورتال داخلی کارمندی جدید راهاندازی کرده. HR، دایرکتوری بخشها، تنظیمات حساب کاربری همه پشت یه صفحه لاگین قرار گرفته و تیم فنیشون مطمئنه که آمادهی audit هست.
شما به عنوان یه پنتستر خارجی استخدام شدید. کارتون رو با هیچی شروع کنید فقط یه فرم ثبتنام ساده و ببینید یه اکانت کارمند عادی تا کجا میتونه شما رو پیش ببره.
🎯 هدف: رسیدن به پنل Administrator و گرفتن Flag.
⚙️ نحوه اجرا
سرویس روی آدرس زیر بالا میاد:
یه اکانت برای خودتون بسازید نیازی به حدس زدن یا brute-force کردن اکانت های موجود نیست.
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
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
Forwarded from رادیو زیرو پاد
📌 برگزاری جلسه ویس چت :
با درود خدمت دوستان و همراهان عزیز،
در راستای ارتقای سطح دانش فنی و آشنایی بیشتر با مباحث امنیت سایبری، قصد داریم جلسهای تخصصی و آموزشی در خصوص تست نفوذ IoT به صورت ویس چت برگزار کنیم.
🎙 مهمان ویژه:
👤 مهندس : کوشا زنجانی
📅 زمان برگزاری: پنجشنبه 1405/06/12
📍 پلتفرم: ویس چت تلگرام
🕗 ساعت : 20:00
🔖 لینک جلسه :
⁉️ موضوعات ما :
◾️بخش اول:
📌 اپیزود ۱ : IoT چیست و چگونه کار میکند؟
🔔 نکته مهم:
جهت شرکت به موقع جلسه، حتماً کانال تلگرام را چک کنید تا از این جلسه جا نمونید .
➖➖➖➖➖➖➖➖➖➖➖➖➖➖
🆔 @RadioZeroPod
🆔 @TryHackBox
با درود خدمت دوستان و همراهان عزیز،
در راستای ارتقای سطح دانش فنی و آشنایی بیشتر با مباحث امنیت سایبری، قصد داریم جلسهای تخصصی و آموزشی در خصوص تست نفوذ IoT به صورت ویس چت برگزار کنیم.
🎙 مهمان ویژه:
👤 مهندس : کوشا زنجانی
📅 زمان برگزاری: پنجشنبه 1405/06/12
📍 پلتفرم: ویس چت تلگرام
🕗 ساعت : 20:00
🔖 لینک جلسه :
⁉️ موضوعات ما :
◾️بخش اول:
📌 اپیزود ۱ : IoT چیست و چگونه کار میکند؟
🔔 نکته مهم:
جهت شرکت به موقع جلسه، حتماً کانال تلگرام را چک کنید تا از این جلسه جا نمونید .
➖➖➖➖➖➖➖➖➖➖➖➖➖➖
🆔 @RadioZeroPod
🆔 @TryHackBox
❤4
Forwarded from P.F.K Security
هر باگ، آسیب پذیری نیست.
یکی از اشتباهات رایج وقتی وارد Vulnerability Research میشیم اینه که هر رفتار عجیب یا اشتباه یک برنامه رو سریعاً بهعنوان Vulnerability در نظر بگیریم.
مثلاً فرض کن به یک برنامه یک مقدار خیلی بزرگ میدی و نتیجه محاسبه اشتباه میشه.
خب، این یک باگ هست.
اما آیا لزوماً یک Security Vulnerability هم هست؟
نه.
سؤال اصلی اینه:
آیا مهاجم میتونه از این رفتار، یک اثر امنیتی ایجاد کنه؟
اگر نه، احتمالاً فقط با یک باگ معمولی طرف هستیم.
یک مثال ساده
فرض کن یک نرمافزار تاریخ روز رو اشتباه نمایش میده.
امروز دوشنبه است، ولی برنامه نشون میده:
Friday
واضحه که برنامه درست کار نمیکنه.
اما حالا از دید یک Security Researcher نگاه کنیم.
آیا مهاجم میتونه با استفاده از این رفتار:
اطلاعاتی رو بخونه؟
اطلاعاتی رو تغییر بده؟
دسترسی بیشتری به دست بیاره؟
باعث اختلال در سرویس بشه؟
از یک Security Boundary عبور کنه؟
اگر هیچ کدوم اتفاق نیفته، احتمالاً این فقط یک Bug هست، نه Vulnerability.
پس Vulnerability چیه؟
به زبان ساده، Vulnerability یک Weakness امنیتی قابل اکسپلویت است.
این ضعف میتونه در:
Design، Implementation یا Security Control
وجود داشته باشه و مهاجم بتونه اون رو Trigger یا Exploit کنه.
تفاوت اصلی رو اینطور ببین:
Bug
برنامه کاری رو انجام میده که نباید انجام بده.
Vulnerability
همون رفتار میتونه یک Security Impact ایجاد کنه.
چرا این تفاوت مهمه؟
چون در Vulnerability Research قرار نیست هر چیزی که خراب کار میکنه رو Vulnerability اعلام کنیم.
باید بتونی یک ارتباط منطقی بین این سه مورد پیدا کنی:
Weakness → Trigger → Security Impact
مثلاً اگر فقط متوجه شدی یک ورودی خاص باعث Crash شدن برنامه میشه، هنوز نمی تونی بگی:
«پس یک Critical Vulnerability پیدا کردم.»
اول باید بفهمی:
این Crash دقیقاً چه اثر امنیتی داره؟
آیا قابل اکسپلویت است؟
آیا توسط مهاجم قابل Trigger کردنه؟
آیا روی Confidentiality، Integrity یا Availability تأثیر میذاره؟
اگر نتونی این ارتباط رو ثابت کنی، هنوز Vulnerability رو اثبات نکردی.
و دقیقاً همین جا تفاوت بین پیدا کردن یک Bug و انجام دادن Security Research مشخص میشه.
📌 تمرین
یک نرمافزار یا Web Application فرضی انتخاب کن.
سه رفتار اشتباه برای اون در نظر بگیر.
بعد برای هرکدوم بررسی کن:
باگ است یا Vulnerability؟
اگر Vulnerability است، دقیقاً چه Security Impactای ایجاد میکند؟
در پست بعدی میریم سراغ همین بخش و بررسی میکنیم:
Confidentiality | Integrity | Availability
یا همون CIA Triad.
ادامه دارد...
@PfkSecurity
#از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #ZeroDay #CyberSecurity
یکی از اشتباهات رایج وقتی وارد Vulnerability Research میشیم اینه که هر رفتار عجیب یا اشتباه یک برنامه رو سریعاً بهعنوان Vulnerability در نظر بگیریم.
مثلاً فرض کن به یک برنامه یک مقدار خیلی بزرگ میدی و نتیجه محاسبه اشتباه میشه.
خب، این یک باگ هست.
اما آیا لزوماً یک Security Vulnerability هم هست؟
نه.
سؤال اصلی اینه:
آیا مهاجم میتونه از این رفتار، یک اثر امنیتی ایجاد کنه؟
اگر نه، احتمالاً فقط با یک باگ معمولی طرف هستیم.
یک مثال ساده
فرض کن یک نرمافزار تاریخ روز رو اشتباه نمایش میده.
امروز دوشنبه است، ولی برنامه نشون میده:
Friday
واضحه که برنامه درست کار نمیکنه.
اما حالا از دید یک Security Researcher نگاه کنیم.
آیا مهاجم میتونه با استفاده از این رفتار:
اطلاعاتی رو بخونه؟
اطلاعاتی رو تغییر بده؟
دسترسی بیشتری به دست بیاره؟
باعث اختلال در سرویس بشه؟
از یک Security Boundary عبور کنه؟
اگر هیچ کدوم اتفاق نیفته، احتمالاً این فقط یک Bug هست، نه Vulnerability.
پس Vulnerability چیه؟
به زبان ساده، Vulnerability یک Weakness امنیتی قابل اکسپلویت است.
این ضعف میتونه در:
Design، Implementation یا Security Control
وجود داشته باشه و مهاجم بتونه اون رو Trigger یا Exploit کنه.
تفاوت اصلی رو اینطور ببین:
Bug
برنامه کاری رو انجام میده که نباید انجام بده.
Vulnerability
همون رفتار میتونه یک Security Impact ایجاد کنه.
چرا این تفاوت مهمه؟
چون در Vulnerability Research قرار نیست هر چیزی که خراب کار میکنه رو Vulnerability اعلام کنیم.
باید بتونی یک ارتباط منطقی بین این سه مورد پیدا کنی:
Weakness → Trigger → Security Impact
مثلاً اگر فقط متوجه شدی یک ورودی خاص باعث Crash شدن برنامه میشه، هنوز نمی تونی بگی:
«پس یک Critical Vulnerability پیدا کردم.»
اول باید بفهمی:
این Crash دقیقاً چه اثر امنیتی داره؟
آیا قابل اکسپلویت است؟
آیا توسط مهاجم قابل Trigger کردنه؟
آیا روی Confidentiality، Integrity یا Availability تأثیر میذاره؟
اگر نتونی این ارتباط رو ثابت کنی، هنوز Vulnerability رو اثبات نکردی.
و دقیقاً همین جا تفاوت بین پیدا کردن یک Bug و انجام دادن Security Research مشخص میشه.
📌 تمرین
یک نرمافزار یا Web Application فرضی انتخاب کن.
سه رفتار اشتباه برای اون در نظر بگیر.
بعد برای هرکدوم بررسی کن:
باگ است یا Vulnerability؟
اگر Vulnerability است، دقیقاً چه Security Impactای ایجاد میکند؟
در پست بعدی میریم سراغ همین بخش و بررسی میکنیم:
Confidentiality | Integrity | Availability
یا همون CIA Triad.
ادامه دارد...
@PfkSecurity
#از_روز_صفر_تا_زیرو_دی #VulnerabilityResearch #ZeroDay #CyberSecurity
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
حل چلنچ : The Broken Trust : THB CTF
سناریوی حل چالش توسط اقا آرمین عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
سناریوی حل چالش توسط اقا آرمین عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤3
thb-ctf-02-trustpay-player.zip
28.3 KB
🔐 THB CTF Team Qualification : Challenge #02 - Race Against Trust
دسته: Web Pentesting / Business Logic
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
اTrustPay یه پلتفرم پرداخت داخلیه که تو کل شرکت برای صدور Invoice و انتقال وجه بین بخشها استفاده میشه. کارمندها میتونن Invoiceهاشون رو ببینن، مرجع صورتحساب رو جستجو کنن، و موجودی حسابشون رو پیگیری کنن.
شما بهعنوان یه پنتستر خارجی استخدام شدید. یه اکانت کارمند عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره.
🎯 هدف: دسترسی به پنل Treasury و گرفتن Flag.
هیچ آسیبپذیری به تنهایی شما رو به هدف نمیرسونه. این چالش نیاز به زنجیرهکردن چند تا ضعف داره، فهمیدن اینکه چرا هر مرحله بهتنهایی کافی نیست.
⚙️ نحوه اجرا
یا
اپلیکیشن روی آدرس زیر بالا میاد:
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
دسته: 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
👍3
Try Hack Box
🌐 Web Pentesting | Field Notes - #02 SQL Injection را با SQLmap شروع نکنید یکی از رایج ترین اشتباهها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable». پیش از آنکه حتی…
🧨 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 هست؟
@TryHackBox
#تست_نفوذ #امنیت_سایبری
یک اشتباه رایج در تست 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
#تست_نفوذ #امنیت_سایبری
❤7
🧩 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 مناسب میشود.
به زبان ساده:
و همین مسیر ساده، یک نکته مهم دارد:
ا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 اتفاق بیفتد.
و این دقیقاً جایی است که باید نگاه 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
ا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
👍3❤1
Media is too big
VIEW IN TELEGRAM
📌 معرفی دوره :
THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند Vulnerability شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارتها طراحی شده است.
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد Practical
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبتنام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند Vulnerability شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارتها طراحی شده است.
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد Practical
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰
💰
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبتنام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
🔥4
Try Hack Box
🛡️ SAML SECURITY SERIES | PART 02 🎫 Signature Wrapping وقتی Signature معتبره، ولی Application چیز دیگهای رو میخونه! در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست. حالا بریم سراغ یکی…
🛡️ 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
#امنیت_سایبری #تست_نفوذ
ا💥 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
#امنیت_سایبری #تست_نفوذ