چگونه بدافزار RTF می‌تواند تشخیص بر مبنای امضای ایستا را دور بزند؟!

قالب RTF یکی از انواع قالب‌های سند است که به وسیله مایکروسافت ایجاد شده و به صورت گسترده بیش از ۲۹ سال است که در سامانه‌ها و بسترهای زیادی مورد استفاده قرار می‌گیرد. قالب RTF بسیار انعطاف‌پذیر و در نتیجه پیچیده است. این کار باعث می‌شود تا ایجاد یک تجزیه‌کننده‌ی RTF امن، امری چالش‌برانگیز شود. برخی از آسیب‌پذیری‌های مشهور نظیر CVE-۲۰۱۰-۳۳۳۳ و CVE-۲۰۱۴-۱۷۶۱ در اثر خطا در پیاده‌سازی منطق تجزیه‌ی RTF رخ می‌دهند.
اما در واقع بدافزارهای RTF محدود به آسیب‌پذیری‌هایی که از تجزیه‌کننده RTF استفاده می‌کنند، نمی‌شود. فایل‌های RTF می‌توانند شامل آسیب‌پذیری‌های دیگری باشند که به تجزیه‌کننده‌ی RTF مربوط نیست، زیرا قالب RTF از تعبیه اشیائی در خود نظیر OLE و تصاویر پشتیبانی می‌کند. آسیب‌پذیری‌های CVE-۲۰۱۲-۰۱۵۸ و CVE-۲۰۱۵-۱۶۴۱ دو نمونه از این موارد معمول هستند. علت ریشه‌ای آن‎ها در تجزیه‌کننده‌ی RTF قرار ندارد و مهاجمان می‌توانند از این آسیب‌پذیری‌ها از طریق دیگر قالب‌های پرونده نظیر DOC و DOCX بهره‌برداری کنند.
نوع دیگری از بدافزارهای RTF از هیچ نوع آسیب‌پذیری استفاده نمی‌کند. این نوع تنها شامل پرونده‎های اجرایی آلوده‌ی جاسازی شده است و قربانی را برای اجرای این نوع پرونده‎های مخرب فریب می‌دهد. به این شکل مهاجمان می‌توانند این بدافزار را از طریق رایانامه، گسترش دهند که معمولاً ابزاری برای ارسال مستقیم این پرونده‎ها نیست.
بسیاری از نویسندگان بدافزار ترجیح می‌دهند تا از RTF به عنوان یک ابزار حمله استفاده کنند، چرا که RTF قالبی است که برای ابهام‌سازی مناسب است. به این ترتیب، بدافزارها می‌توانند به راحتی از خطر تشخیص توسط امضاهای ایستا همچون YARA و Snort فرار کنند. به این دلیل در دوران ما که دوران بهره‌برداری‌های اسکریپت است، همچنان حجم گسترده‌ای از حملات بر پایه‌ی RTF را مشاهده می‌کنیم.
در این پست، به بررسی برخی از ترفندهای معمول که توسط اسناد مخرب RTF برای فرار از تشخیص داده شدن، استفاده می‌شوند، پرداخته شده است.

ابهام سازی معمول
ادر این قسمت به استراتژی‌های مختلف ابهام‌سازی RTF پرداخته خواهد شد.
CVE-۲۰۱۰-۳۳۳
این آسیب‌پذیری که در سال ۲۰۰۹ به وسیله‌ای Team۵۰۹ گزارش شد، یک حفره‌ی سرریز پشته است. بهره‌برداری از این حفره بسیار آسان و با کارایی بالا صورت می‌گیرد به طوری‎که هنوز هم هفت سال بعد از کشف شدن از آن استفاده می‌شود. اخیراً مهاجمان با بهره‌گیری از این آسیب‌پذیری به یکی از سفارت‌های هندوستان حمله کرده‌اند.
علت اصلی این آسیب‌پذیری این بود که تجزیه‌کننده‌ی RTF مایکروسافت دارای یک سرریز بافر در پشته در فرایند تجزیه‌ی ویژگی‎های شکل pFragments بود. ساختن هنرمندانه‌ی یک سند RTF مخرب برای بهره‌گیری از این آسیب‌پذیری به مهاجمان اجازه می‌داد تا کدهای دلخواه را از راه دور بر روی سامانه قربانی اجرا کنند. بنابراین مایکروسافت این آسیب‌پذیری را وصله کرد، اما بسیاری از نسخه‌های قدیمی نرم‌افزار آفیس مایکروسافت در معرض این تهدید قرار داشتند به طوری‌که نرخ انجام آن بسیار بالا بود.
۱_۳۴
تجزیه‌کننده‌ی RTF مایکروسافت آفیس فاقد مرزهای مناسب، هنگامی کپی داده‌های منابع در بافر محدود در پشته است. الگوی این بهره‌برداری می‌تواند به شکل زیر خلاصه شود:
۲_۲۷
به دلیل اینکه pFragments به ندرت به شکل پرونده‎های RTF دیده می‌شود، بسیاری از شرکت‌ها به راحتی این کلمات کلیدی و تعداد بیش از اندازه‌ی بعد ازsv\ را می‌توانند ببینند تا از این آسیب‌پذیری با استفاده از قواعد YARA یا Snort جلوگیری کنند. این شیوه برای نمونه‌هایی کار می‌کند که مبهم نشده‌اند، و شامل نمونه‌هایی می‌شود که به وسیله‌ی متااسپلویت ساخته شده‌اند. با این حال، این کار در جهان واقعی همچون تشخیص مبتنی بر امضاء کافی نیست. برای مثال، RTF مخربی که به سفارت هند حمله کرد نمونه‌ی خوبی است که نشان‎دهنده‌ی عدم کارایی تشخیص مبتنی بر امضاء است. شکل زیر سند RTF را در ویرایشگر هگز نشان می‌دهد. این شکل به دلیل محدودیت فضا ساده شده است. تعداد زیادی از نشانه‌های ساختگی همچون {} در نمونه‌ی اولیه وجود داشتند.
۳_۱۸

همانطور که مشاهده می‌کنید، کلمه کلیدی pFragments به قطعات زیادی تقسیم شده است و به واسطه‌ی آن می‌تواند از تشخیص بسیاری از سامانه‌های تشخیص مبتنی بر امضاء عبور کند. برای مثال بسیاری از محصولات ضد بدافزار نتوانستند در اولین ارائه‌ی آن به VirusTotal به شناسایی آن بپردازند. در واقع نه تنها، تکه‌های sn\ با یکدیگر ترکیب می‌شوند، تکه‌های sv\ نیز با همدیگر ترکیب خواهند شد. مثال زیر این ابهام را توضیح می‌دهد:
۴_۱۰
می‌توان انواع ایده‌های متفاوت با نمونه فوق را به کار برد تا بر تشخیص مبتنی بر امضاء غلبه کرد.
به ترکیب x۰D. و x۰A\ توجه کنید، آن‎ها r\ و n\ هستند و تجزیه‌ کننده‌ی RTF به سادگی آنها را نادیده می‌گیرد.

اشیاء جاسازی شده
کاربران می‌توانند انواع مختلفی از اشیاء را، همچون اشیاء کنترل کننده‌ی OLE در درون یک پرونده RTF جاسازی کنند. این کار باعث می‌شود که بهره‌برداری از آسیب‌پذیری‌های مرتبط با OLE مانند CVE-۲۰۱۲-۰۱۵۸ و CVE-۲۰۱۵-۱۶۴۱ در پرونده‎های RTF امکان‌پذیر شود. علاوه بر بهره‌برداری‌ها، دیدن پرونده‎های اجرایی نظیر VBS ،CPL ،PE و JS جاسازی شده در پرونده‎های RTF نیز غیرمعمول نیست. این پرونده‎ها نیاز به برخی از روش‎های مهندسی اجتماعی برای فریب کاربران برای اجرای اشیاء تعبیه شده دارند. حتی برخی از راه‌حل‌های پیشگیری از اتلاف داده (DLP) که پرونده‎های PE را در درون این اسناد تعبیه کرده‌اند، مشاهده شده است. این یک روند بد است، چرا که عادات بدی را در کاربران پرورش می‌دهد.
در ابتدا قواعد و نحوه‌ی جاسازی اشیاء تعبیه شده، بررسی شده است:

۵_۵
<objtype> مشخص کننده‌ی نوعی شیء است. objocx\ رایج‌ترین نوع استفاده شده در اسناد مخرب RTF برای تعبیه اشیاء کنترلی OLE است. در ادامه به توضیح مثالی پرداخته شده است. داده‌های سمت راست بعد از objdata\ یک داده‌ی محلی OLE۱ هستند که به شکل زیر تعریف می‌شوند:
۶_۶
مهاجمان ممکن است سعی کنند تا عناصر مختلفی را در درون <data> قرار دهند تا از تشخیص مبتنی بر امضای ایستا فرار کنند. در ادامه برخی از مثال‌ها برای فهم بهتر این ترفندها بررسی شده است:
الف- برای مثال binN\ می‌تواند با SDATA# جابجا شود.
داده‌هایی که درست بعد از binN\ قرار دارند جزو داده‌های باینری خام هستند. در مثال پیش رو شماره ۱۲۳ به عنوان داده‌ی باینری در نظر گرفته می‌شود و از این رو به شکل مقادیر هگز ۳۱۳۱۲۳۳ در حافظه ترجمه می‌شود.

۷_۵
یک مثال دیگر به شکل زیر است:

۸_۲
اگر سعی شود تا atoi یا atol را با رشته پارامترهای عددی که به شکل قرمز در جدول بالا هستند، فراخوانی شود، ۰x۷fffffff گرفته خواهد شد، در حالی‎که مقدار درست باید ۳ باشد.
این کار به این علت رخ می‌دهد که bin\ یک پارامتر عددی، عدد صحیح با امضای ۳۲ بیتی را می‌گیرد. شما باید تصور کنید که تجزیه کننده‌ی RTF، برای تبدیل رشته‌ی عددی به یک عدد صحیح atoi یا atol را فراخوانی می‌کند. تجزیه‌کننده‌ی مایکروسافت ورد از این توابع اجرایی استاندارد زبان C استفاده نمی‌کند.
به جای آن تابع atoi در تجزیه‌کننده‌ی RTF مایکروسافت ورد به صورت زیر اجرا می‌شود:

۹_۰
ب- کاراکترهای خالی (۰x۰D (\n) ،۰x۰A (\r) ،۰x۰۹ (\t نادیده گرفته می‌شوند.
و …

نتیجه‎گیری
مهاجمان با قالب RTF و عملکردهای داخلی مایکروسافت، آشنا هستند و خود را با آن پیچیده‌تر می‌کنند. آنها موفق شده‌اند که از این تکنیک‌های ایجاد ابهام استفاده کنند تا از تشخیص توسط سامانه‌های مبتنی بر امضای سنتی فرار کنند. درک این نکته که چگونه مهاجمان ابهام را ایجاد می‌کنند می‌تواند به نوبه خود به ما کمک کند تا تشخیص خود را از چنین بدافزارهایی بهبود ببخشیم.

منبع: asis

درباره نماد امنیت وب

“نماد امنیت وب” به عنوان یکی از شرکت های پیشتاز در زمینه امنیت نرم افزار و سرویس های تحت وب، با ارائه سرویس های امنیتی برای تمامی کسب و کار ها و دارای نمایندگی شرکت Acunetix (اکوانتیکس) بعنوان محبوب ترین اسکنر امنیتی black box در دنیا، ایمنی وب سایت شما را در مقابل حمله هکر ها تضمین می کند.