نفوذگران ایرانی OilRig، کارگزارهای وب IIS را با درِ پشتی جدیدی هدف قرار دادند.
به گزارش آی تابناک : یک گروه جاسوسی سایبری وابسته به ایران به نام OilRig از یک درِ پشتی استفاده‌می‌کند تا کارگزارهای وب خدمات اطلاعات اینترنتی (IIS) را هدف قرار دهد که در سازمان‌های دولتی و مؤسسات مالی و آموزشی خاورمیانه مورد استفاده قرار گرفته‌است.
این بدافزار که با نام RGDoor شناخته شده‌است، یک درِ پشتی ثانویه است که به عاملان حمله اجازه می‌دهد در صورت شناسایی و حذف بدافزار اولیه، دسترسی به کارگزار وب آسیب‌دیده را دوباره به دست آورند. این ابزار مخرب اولیه، شِل وب TwoFace است که گروه OilRig معتقد است حداقل از ماه ژوئن سال ۲۰۱۶ میلادی مورد استفاده قرار گرفته است.
حدوداً از سال ۲۰۱۵ میلادی، گروه تهدید OilRig به‌طور عمده سازمان‌های بخش مالی و دولتی را در آمریکا و کشورهای خاورمیانه مورد هدف قرار داده‌است. این گروه خارج از ایران فعالیت می‌کند و از ابزارهای مختلفی استفاده‌می‌کند و انبارهای مهمات خود را گسترش دهند و به‌سرعت از بهره‌برداری‌های جدید استفاده‌می‌کند.
این درِ پشتی با استفاده از ++C ایجاد شده‌است که نتیجه آن یک کتابخانه پیوند پویا (DLL) با یک تابعی به نام RegisterModule است. به همین دلیل، پژوهشگران Palo Alto معتقدند که این DLL به‌عنوان یک مؤلفه HTTP سفارشی که به‌صورت بومی کدگذاری‌شده و در IIS بارگذاری شده‌است، مورد استفاده قرار می‌گیرد و برای عاملان هیچ نمایش بصری از این شِل وجود ندارد که با آن تعامل برقرار کنند.
شرکت امنیتی Palo Alto تشریح می‌کند که این رویکرد از ویژگی‌های IIS ۷ استفاده‌می‌کند که به توسعه‌دهندگان امکان ایجاد مؤلفه‌هایی در ++C را می‌دهد تا قابلیت‌های IIS ازجمله انجام اقدامات سفارشی در مورد درخواست‌ها را گسترش دهند. این مؤلفه‌های کدگذاری‌شده به‌صورت بومی را می‌توان در رابط کاربری گرافیکی مدیریت IIS یا از طریق خط فرمان با استفاده از برنامه appcmd نصب کرد.
پژوهشگران متوجه شدند که RGDoor تابع RegisterModule را به این دلیل فراخوانی می‌کند که درخواست‌های HTTP GET ورودی را نادیده می‌گیرد، اما در تمام درخواست‌های HTTP POST، حتی درخواست‌های صادر شده در HTTPS عمل می‌کند. این بدافزار درخواست‌ها را تجزیه می‌کند که یک رشته خاصی را در فیلد کوکی HTTP جست‌وجو کند تا مشخص کند چه دستوراتی از نوع cmd$ (دستور برای اجرا) و upload$ (مسیر پرونده) و یا download$ (مسیر پرونده) برای آن صادر شده‌است.
پژوهشگران همچنین تشریح کردند که: «سپس این نمونه با ایجاد یک حلقه که متد IHttpResponse::WriteEntityChunk را تا اتمام ارسال کل اطلاعات در پاسخ‌های HTTP فراخوانی می‌کند، اطلاعات را برای عامل حمله ارسال می‌کند. اگر متد WriteEntityChunk در هر مرحله از این حلقه اجرا نشود، کد نمونه با استفاده از متد IHttpResponse::SetStatus یک پاسخ خطای کارگزار HTTP ۵۰۰ برای عامل حمله ارسال می‌کند.»
به‌دلیل اینکه IIS به‌طور پیش‌فرض مقادیر موجود در فیلدهای کوکی درخواست‌های HTTP ورودی را ثبت نمی‌کند، مکان‌یابی و تجزیه‌وتحلیل درخواست‌های ورودی مربوط به RGDoor بسیار مشکل است. علاوه‌بر آن به دلیل اینکه این مؤلفه تمام درخواست‌های POST ورودی را برای یافتن دستورات بررسی می‌کند، عامل حمله برای ارتباط با آن می‌تواند از هر آدرس اینترنتی استفاده کند.
عاملان پشت این بدافزار از شِل وب TwoFace استفاده کرده‌اند تا آن را در یک کارگزار وب IIS بارگذاری کنند و دسترسی درِ پشتی را به سامانه‌آسیب‌دیده به دست آورند. با این حال به نظر می‌رسد که هدف اصلی این ابزار، باز پس گرفتن دسترسی به کارگزار در صورت حذف شِل وب TwoFace است.
شرکت امنیتی Palo Alto به این نتیجه رسیده‌است که: «این درِ پشتی یک‌سری دستورات محدود دارد، با این حال، این سه دستور قابلیت‌های فراوانی را برای یک درِ پشتی فراهم می‌کند که به مهاجم اجازه می‌دهد تا پرونده‌ها را از کارگزار بارگیری و یا در آن بارگذاری کند و دستورات را از طریق خط فرمان اجرا کند. استفاده از RGDoor نشان می‌دهد که این گروه در نظر دارد که در صورت شناسایی و حذف شِل وب آن، دسترسی به شبکه آسیب‌دیده را دوباره به دست آورد.»
این بدافزار که با نام RGDoor شناخته شده‌است، یک درِ پشتی ثانویه است که به عاملان حمله اجازه می‌دهد در صورت شناسایی و حذف بدافزار اولیه، دسترسی به کارگزار وب آسیب‌دیده را دوباره به دست آورند. این ابزار مخرب اولیه، شِل وب TwoFace است که گروه OilRig معتقد است حداقل از ماه ژوئن سال ۲۰۱۶ میلادی مورد استفاده قرار گرفته است.
حدوداً از سال ۲۰۱۵ میلادی، گروه تهدید OilRig به‌طور عمده سازمان‌های بخش مالی و دولتی را در آمریکا و کشورهای خاورمیانه مورد هدف قرار داده‌است. این گروه خارج از ایران فعالیت می‌کند و از ابزارهای مختلفی استفاده‌می‌کند و انبارهای مهمات خود را گسترش دهند و به‌سرعت از بهره‌برداری‌های جدید استفاده‌می‌کند.
این درِ پشتی با استفاده از ++C ایجاد شده‌است که نتیجه آن یک کتابخانه پیوند پویا (DLL) با یک تابعی به نام RegisterModule است. به همین دلیل، پژوهشگران Palo Alto معتقدند که این DLL به‌عنوان یک مؤلفه HTTP سفارشی که به‌صورت بومی کدگذاری‌شده و در IIS بارگذاری شده‌است، مورد استفاده قرار می‌گیرد و برای عاملان هیچ نمایش بصری از این شِل وجود ندارد که با آن تعامل برقرار کنند.
شرکت امنیتی Palo Alto تشریح می‌کند که این رویکرد از ویژگی‌های IIS ۷ استفاده‌می‌کند که به توسعه‌دهندگان امکان ایجاد مؤلفه‌هایی در ++C را می‌دهد تا قابلیت‌های IIS ازجمله انجام اقدامات سفارشی در مورد درخواست‌ها را گسترش دهند. این مؤلفه‌های کدگذاری‌شده به‌صورت بومی را می‌توان در رابط کاربری گرافیکی مدیریت IIS یا از طریق خط فرمان با استفاده از برنامه appcmd نصب کرد.
پژوهشگران متوجه شدند که RGDoor تابع RegisterModule را به این دلیل فراخوانی می‌کند که درخواست‌های HTTP GET ورودی را نادیده می‌گیرد، اما در تمام درخواست‌های HTTP POST، حتی درخواست‌های صادر شده در HTTPS عمل می‌کند. این بدافزار درخواست‌ها را تجزیه می‌کند که یک رشته خاصی را در فیلد کوکی HTTP جست‌وجو کند تا مشخص کند چه دستوراتی از نوع cmd$ (دستور برای اجرا) و upload$ (مسیر پرونده) و یا download$ (مسیر پرونده) برای آن صادر شده‌است.
پژوهشگران همچنین تشریح کردند که: «سپس این نمونه با ایجاد یک حلقه که متد IHttpResponse::WriteEntityChunk را تا اتمام ارسال کل اطلاعات در پاسخ‌های HTTP فراخوانی می‌کند، اطلاعات را برای عامل حمله ارسال می‌کند. اگر متد WriteEntityChunk در هر مرحله از این حلقه اجرا نشود، کد نمونه با استفاده از متد IHttpResponse::SetStatus یک پاسخ خطای کارگزار HTTP ۵۰۰ برای عامل حمله ارسال می‌کند.»
به‌دلیل اینکه IIS به‌طور پیش‌فرض مقادیر موجود در فیلدهای کوکی درخواست‌های HTTP ورودی را ثبت نمی‌کند، مکان‌یابی و تجزیه‌وتحلیل درخواست‌های ورودی مربوط به RGDoor بسیار مشکل است. علاوه‌بر آن به دلیل اینکه این مؤلفه تمام درخواست‌های POST ورودی را برای یافتن دستورات بررسی می‌کند، عامل حمله برای ارتباط با آن می‌تواند از هر آدرس اینترنتی استفاده کند.
عاملان پشت این بدافزار از شِل وب TwoFace استفاده کرده‌اند تا آن را در یک کارگزار وب IIS بارگذاری کنند و دسترسی درِ پشتی را به سامانه‌آسیب‌دیده به دست آورند. با این حال به نظر می‌رسد که هدف اصلی این ابزار، باز پس گرفتن دسترسی به کارگزار در صورت حذف شِل وب TwoFace است.
شرکت امنیتی Palo Alto به این نتیجه رسیده‌است که: «این درِ پشتی یک‌سری دستورات محدود دارد، با این حال، این سه دستور قابلیت‌های فراوانی را برای یک درِ پشتی فراهم می‌کند که به مهاجم اجازه می‌دهد تا پرونده‌ها را از کارگزار بارگیری و یا در آن بارگذاری کند و دستورات را از طریق خط فرمان اجرا کند. استفاده از RGDoor نشان می‌دهد که این گروه در نظر دارد که در صورت شناسایی و حذف شِل وب آن، دسترسی به شبکه آسیب‌دیده را دوباره به دست آورد.»
منبع : افتانا
روی خط سایت ها
ارسال نظر
فیلم
جدیدترین اخبار