سناریوی حمله: ربودن syscall برای نامرئی شدن
یک ایده برای PoC
روزبه نوروزی
یک مهاجم حرفهای میداند که مدیران سیستم از ابزارهایی مانند auditd برای نظارت بر فعالیتها استفاده میکنند. auditd با نظارت بر فراخوانهای سیستمی (syscalls) کار میکند. بنابراین، یک راه هوشمندانه برای دور زدن auditd، دستکاری خود فراخوانهای سیستمی قبل از رسیدن به کرنل است. اینجاست که ptrace وارد بازی میشود.
هدف مهاجم: اجرای دستورات مخرب (مانند حذف یک فایل مهم) بدون اینکه auditd آن را ثبت کند.
مراحل حمله:
اجرای یک حامل (Carrier Process): مهاجم یک برنامه ساده را اجرا میکند. این برنامه قرار است به عنوان “ردیاب” عمل کند و فرآیند شل (مثلاً bash) را کنترل نماید.
کنترل شل با ptrace: برنامه حامل، فرآیند bash را با استفاده از ptrace(PTRACE_SYSCALL, ...) تحت کنترل خود در میآورد. این دستور به ردیاب اجازه میدهد تا درست قبل از اجرای یک فراخوان سیستمی و درست بعد از اتمام آن، اجرای فرآیند هدف (شل) را متوقف و آن را بازرسی کند.
رهگیری و تغییر فراخوان سیستمی:
مهاجم در شل کنترلشدهی خود، دستور rm /var/www/html/
backup.zip را تایپ میکند.
شل bash تلاش میکند فراخوان سیستمی unlink یا unlinkat را برای حذف فایل فراخوانی کند.
قبل از اینکه این فراخوان به کرنل برسد، برنامه حامل (که با ptrace شل را کنترل میکند) اجرا را متوقف میکند.
برنامه حامل محتوای رجیسترها را بررسی میکند و میبیند که یک فراخوان unlinkat با آرگومان /var/www/html/
backup.zip در حال اجرا است.
اینجا نقطه کلیدی است: برنامه حامل، شماره فراخوان سیستمی را در رجیستر مربوطه (مثلاً rax در x86-64) از شماره unlinkat به شماره یک فراخوان بیخطر مانند getpid تغییر میدهد!
سپس به فرآیند شل اجازه ادامه کار میدهد.
نتیجه چه میشود؟
از دید کرنل و auditd، فرآیند bash فقط فراخوان getpid را اجرا کرده است. بنابراین، auditd یک رویداد بیاهمیت را ثبت میکند (یا اصلاً ثبت نمیکند، بستگی به قوانین دارد).
اما در واقعیت، برنامه حامل که کنترل کامل روی حافظه bash دارد، مستقیماً و بدون استفاده از syscall، کد لازم برای حذف فایل را اجرا میکند یا از تکنیک دیگری برای پاک کردن آن بهره میبرد.
پایان قسمت اول
حالا این ایده بنده هست اگر نقدی براون وارد هست پذیرا هستم.
**این ایده در سیستم های هاردن شده و دارای EDR قابلیت اجرا ندارد.
#آکادمی_روزبه