فا

‫ اخبار

1 ماژول Webform Multiple File Upload

::: معرفی
::: پروژه: Webform Multiple File Upload (ماژول/ افزونه)
::: آسیب‌پذیری: اجرای کد PHP دلخواه (Remote Code Execution)
::: شماره گزارش آسیب پذیری: SA-CONTRIB-2016-040

::: توضیحات
ماژولِ Webform Multiple File Upload به کاربر اجازه می‌دهد تا چندین فایل را در یک فرم تحت وب آپلود کند. این ماژول یک آسیب‌پذیریِ اجرای کد از راه دور(RCE) دارد؛ آن‌جا که محتوای فرم از حالت serialized خارج می‌شود و در نتیجه ورودی‌های خاصی که ممکن است ارسال شوند، می‌توانند به اجرای کد PHP با توجه به libraryهای در دسترس روی سایت منجر شوند.
این آسیب‌پذیری با این واقعیت پیوند خورده است که نفوذگر می‌بایستی امکان این را داشته باشد تا فرمی که حاویِ ورودیِ Multiple File Upload است را ارسال کند. همین‌طور، سایت باید یک Object با روشی روی wake یا destroy کدِ include شده که می‌تواند برای مقاصد نامناسب استفاده شود، تعریف داشته باشد. هسته‌ی دروپال7 یک کلاس به این شکل داراست که می‌تواند برای حذفِ فایل‌های دلخواه استفاده گردد، اما کلاس‌های شخصی‌سازی شده، ممکن است حاوی متدهایی باشند که می‌توانند برای باگ RCE مورد استفاده قرار گیرند.

نکته: این آسیب‌پذیری در ماژولِ Webform Multiple File Upload(webform_multifile) وجود دارد. یک ماژول با نام مشابهی نیز وجود دارد Webform Multiple File(webform_multiple_file) که این مشکل را دارا نیست.

::: نسخه های تحت تأثیر
هسته‌ی دروپال تحت تاثیر این آسیب‌پذیری نیست. اگر شما از ماژول Webform Multiple File Upload استفاده نمی‌کنید، نیازی به انجام کاری نیست. اما نسخه آسیب پذیر این ماژول عبارتند از:
• Webform Multifile 7.x-1.x versions prior to 7.x-1.4

::: راه حل
آخرین نسخه را نصب کنید. اگر از ماژول Webform Multifile برای دروپال نسخه 7.x استفاده می‌کنید، به Webform Multiple File Upload نسخه‌ ی 7.x-1.4 آپدیت کنید.

 گزارش شده توسط Ben Dougherty
 حل شده توسطJelle Sebreghts و Peter Droogmans از پشتیبانی ماژول دروپال
 یافتن باگ در کد توسطBen Dougherty و Greg Knaddison از تیم امنیتی دروپال


2 ماژول Coder

::: معرفی
::: پروژه: Coder(ماژولِ افزودنی)
::: آسیب‌پذیری: اجرای کد PHP دلخواه (Remote Code Execution)
::: شماره گزارش آسیب پذیری: SA-CONTRIB-2016-040

::: توضیحات
ماژول Coder کدِ دروپالِ شما را برای استانداردها و دیگر بهینه‌سازی‌ها چک می‌کند. همانطور می‌تواند اشتباهات استانداردهای کدنویسی را نیز تصحیح کند و روی ماژول‌ها، یک‌سری بهینه‌سازی اساسی انجام دهد.
این ماژول به صورتِ صحیح، ورودی‌های کاربر را در فایل اسکریپتی که پسوندِ PHP دارد بررسی نمی‌کند. یک کاربرِ Login نکرده و یا نفوذگر می‌تواند به صورت مستقیم به این فایل درخواست فرستاده و کد PHP دلخواه اجرا کند.
هیچ فاکتورِ محدودکننده‌ای وجود ندارد. ماژول حتی نیاز به فعال بودن برای اکسپلویت‌شدن ندارد! وجود فایل روی سرور و این‌که از روی وب قابل دسترسی باشد کافیست.

::: نسخه های تحت تأثیر
• Coder module 7.x-1.x versions prior to 7.x-1.3
• Coder module 7.x-2.x versions prior to 7.x-2.6
هسته‌ی دروپال تحت تاثیر این آسیب‌پذیری نیست. اگر شما از ماژول Coder استفاده نمی‌کنید، نیازی به انجام کاری نیست.

::: راه حل
دو راه موجود است.
راه اول این‌است که ماژول را از همه‌ی سایت‌هایی که در دسترس عموم هستند پاک کنید:
• ماژول Coder برای استفاده در محیط توسعه ساخته شده است و قرار نیست روی سرورهایی با دسترسی عمومی قرار داشته باشد. در نتیجه، یک راه ساده این است که کل دایرکتوری ماژولِ Coder را از روی همه‌ی وب‌سایت‌های با دسترسی عمومی پاک کنید.
انتخاب دوم این است که آخرین نسخه را نصب کنید:
• اگر از ماژول Coder برای دروپال 7.x استفاده می‌کنید، به Coder نسخه‌ی 7.x-1.3 یا 7.x-2.6 آپدیت کنید.

 گزارش شده توسط Nicky Bloor
 حل شده توسطDavid Rothstein و Jim Berry از پشتیبانی ماژول دروپال
 یافتن باگ در کد توسط Michael Hess و Greg Knaddison وKlaus Purer از تیم امنیتی دروپال


3 ماژول RESTful Web Services

::: معرفی
::: پروژه: RESTful Web Services(ماژولِ افزودنی)
::: آسیب‌پذیری: اجرای کد PHP دلخواه (Remote Code Execution)
::: شماره گزارش آسیب پذیری: SA-CONTRIB-2016-040

::: توضیحات
این ماژول به شما این امکان را می‌دهد تا نهادهای دروپال را به صورت وب‌سرویسِ RESTful نمایش دهید. RESTWS صفحه‌ی پاسخِ پیش‌فرضِ نهادها را تغییر می‌دهد تا امکاناتی را به آن بیافزاید. یک آسیب‌پذیری در این رویکرد به نفوذگر اجازه می‌دهد تا با ارسالِ درخواست‌هایی با محتوایی خاص، به اجرای کد دلخواه PHP برسد. هیچ فاکتورِ محدودکننده‌ای وجود ندارد. این آسیب‌پذیری می‌تواند تحت سطح‌دسترسیِ کاربرِ معمولی سایت (بازدید‌کننده) اکسپلویت شود.

::: نسخه های تحت تأثیر
• RESTful Web Services 7.x-2.x versions prior to 7.x-2.6.
• RESTful Web Services 7.x-1.x versions prior to 7.x-1.7.
هسته‌ی دروپال تحت تاثیر این آسیب‌پذیری نیست. اگر شما از ماژول RESTful Web Services استفاده نمی‌کنید، نیازی به انجام کاری نیست.


::: راه حل
آخرین نسخه را نصب کنید.
• اگر از ماژول RESTful Web Services برای دروپال7.x استفاده می‌کنید، به RESTful Web Services نسخه‌ی 7.x-2.6آپدیت کنید.
• اگر از ماژول RESTful Web Services برای دروپال7.x استفاده می‌کنید، به RESTful Web Services نسخه‌ی 7.x-1.7آپدیت کنید.

 گزارش شده توسط Devin Zuczek
 حل شده توسط Klaus Purer و Wolfgang Ziegler از پشتیبانی ماژول دروپال
 یافتن باگ در کد توسط Greg KnaddisonوKlaus Purer از تیم امنیتی دروپال

در آوریل 2016، هنگام بررسیِ یک کمپین فیشینگِ پیامکی به نام RuMMS که هدف‌هایی از اروپا با سیستم عامل اندروید را هدف قرار می‌داد، متوجه سه کمپینِ فیشینگِ پیامکی دیگر شدیم که بنا به گزارش‌ها در دانمارک(فوریه ۲۰۱۶)، در ایتالیا(فوریه ۲۰۱۶) و در ایتالیا و دانمارک(آوریل ۲۰۱۶) پخش می‌شدند.

برخلاف کمپین RuMMS، این سه کمپین در اروپا از تکنیک‌های view overlay،همان تکنیک‌هایی که در بدافزار SlemBunk استفاده شده بود، استفاده کردند تا ورودی‌هایی مشابه با برنامه‌های گوشی برای اطلاعات ورود به نمایش بگذارند، و در ادامه کاربرانی که در جریان نبودند را گول بزنند تا اطلاعات بانکی خود را در اختیارشان قرار دهند.شکل۱ روند این‌که چطور این بدافزارهای پوششی توسط فیشینگِ پیامکی پخش می‌شدند و کاربران اندروید را آلوده می‌کردند را نشان می‌دهد.

عاملان تهدید معمولاً ابتدا سرورهای دستور و کنترل(C2) و سایت‌های میزبانیِ بدافزار را پیکربندی می‌کنند، سپس بدافزارها را بر روی سایت‌های میزبانی قرار می‌دهند و لینکی که به بدافزار هدایت می‌کند را از طریق SMS برای قربانی می‌فرستند. پس از نصب‌شدن روی دستگاه، بدافزار یک پروسه را برای مانیتور کردن این‌که کدام برنامه در حال اجرا روی صفحه‌ی کاربر(foreground) است، راه‌اندازی می‌کند. وقتی کاربر یک برنامه‌ی آشنا را روی صفحه اجرا می‌کند که بدافزار برای هدف‌قرار دادنِ آن برنامه طراحی شده است(مثلاً اپلیکیشن بانک)، بدافزار یک view برای فیشینگ در روی آن برنامه به صورت overlay(پوششی) به نمایش در می‌آورد. کاربری که در جریان این حمله نیست، با فرض این‌که از برنامه‌ی معتبری استفاده می‌کند، ورودی‌های مورد نیاز(اطلاعات کارت بانکی) را وارد می‌کند؛ که این اطلاعات به سرور C2 که توسط گردانندگان این ویروس کنترل می‌شود ارسال می‌شوند.

دریافت کامل این گزارش

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

فایل پیوست

1. مقدمه
امروزه پست‌های الکترونیکی زیادی در بین کاربران اینترنت ردوبدل می‌شود. این پست‌های الکترونیکی می‌توانند حاوی فایل‌های پیوست نیز باشند. از آن‌جا که تعداد پست‌های الکترونیکی زیاد است، توجه بدخواهان اینترنتی را به خود جلب کرده‌اند. در طی تحقیقاتی که توسط متخصصین حوزه‌ی امنیت انجام شده است، تعداد زیادی پست‌های الکترونیکی حاوی فایل‌های پیوست و یا لینک‌های مخرب جاسازیشده را شناسایی کرده است که در اغلب موارد هدفمند و برعلیه سازمان‌ها بوده‌اند.
این گزارش توسط سازمان ASD و به منظور فراهم کردن راهکاری برای کاهش خطرهای امنیتی که توسط پست‌های الکترونیکی مخرب ایجاد شده‌اند، گردآوری شده است. در این گزارش تعدادی راهکار برای کاهش چنین خطراتی ارایه شده است. قابل توجه است که هر راهکار ارایه‌شده در این گزارش، لزوما برای تمامی سازمان‌ها مناسب نیست و سازمان‌ها باید با در نظر گرفتن نیازمندی‌های کاری و محیط ریسک خود، راه‌حل کاهشی مناسبی را برای خود انتخاب کنند.
2. فیلتر کردن پیوست‌ها
پیوست‌ها در پست‌های الکترونیکی یکی از ریسک‌های امنیتی قابل توجه‌اند. فیلتر کردن پیوست‌ها، احتمال دریافت محتویات مخرب بر روی سیستم کاربر را تا حد خوبی کاهش می‌دهد. راهکارهای کاهش در مورد پیوست‌های مخرب در ادامه آورده شده‌اند. این راه‌کارها براساس تاثیری که بر روی امنیت دارند، دسته‌بندی می‌شوند.
2-1 اثربخشی امنیتی عالی
1. تبدیل قالب پیوست‌ها
تبدیل قالب پیوست‌ها به قالبی دیگر تاثیر به‌سزایی در حذف محتویات مخرب دارد. برای نمونه یکی از این تبدیلات، تبدیل فایل‌های آفیس مایکروسافت به قالب پی‌دی‌اف است.
2. لیست سفید پیوست‌ها براساس نوع فایل
در این لیست برای تعیین نوع فایل، به جای در نظر گرفتن پسوند فایل، محتویات فایل بررسی می‌شود. انواعی از فایل که اهداف کسب‌وکار مجاز و مشخصات خطر قابل قبولی برای سازمان دارند، می‌توانند در لیست سفید قرار گیرند. توصیه به لیست سفید بیشتر از لیست سیاه است، زیرا در این لیست همه‌ی انواع قابل قبول که می‌توانند از طریق پست الکترونیکی دریافت شوند، مشخص می‌شوند.
در صورتی که نوع فایل تشخیص داده شده براساس محتویات آن، با پسوند آن مغایرت داشته باشد، این مورد به عنوان یک مورد مشکوک باید مورد توجه قرار گیرد.
3. مسدود کردن پیوست‌های غیرقابل شناسایی و یا رمزگذاری‌شده
پیوست‌های غیرقابل شناسایی و یا رمزگذاری‌شده قابل اعتماد نیستند چون که محتویات پست الکترونیکی نمی‌توانند رمزگشایی و بررسی شوند. هر پیوست رمزنگاری‌شده تا زمانی که بی‌خطر تلقی نشده است، باید مسدود شود.
4. انجام تحلیل پویای خودکار برای پیوست‌ها با اجرای آن‌ها در یک جعبه‌ی شنی
تحلیل پویا، قابلیت شناسایی ویژگی‌های رفتاری را دارد. بنابراین انجام یک تحلیل پویای خودکار در یک جعبه‌ی شنی می‌تواند رفتارهای مشکوک در ترافیک شبکه، فایل‌های جدید یا تغییریافته و یا تغییرات در رجیستری ویندوز را شناسایی کند.
5. حذف پیوست‌هایی با محتویات فعال یا به طور بالقوه خطرناک
محتویات فعال مانند ماکروها در فایل‌های آفیس مایکروسافت و جاوا اسکریپت‌ها باید قبل از تحویل پیوست‌ها به کاربر، از پست‌های الکترونیکی حذف شوند. ابزارهای حذف محتویات فایل باید پیوست‌ها را برای پیدا کردن محتویات فعال نامطلوب براساس کلمات کلیدی یا به صورت اکتشافی بررسی و با بازنویسی آن‌ها اثر نامطلوبشان را خنثی کنند. هر چند که عملیات بررسی و حذف محتویات فعال در پیوست‌ها، پردازشی دشوار است.
6. کنترل یا غیرفعال کردن ماکروها در فایل‌های آفیس مایکروسافت
استفاده از ماکروها در فایل‌های آفیس مایکروسافت به شدت افزایش یافته است. از این‌رو بهتر است سازمان‌ها برنامه‌های خود را برای غیرفعال کردن همه‌ی ماکروها به صورت پیش‌فرض پیکربندی کنند و فقط ماکروهای قابل اعتماد که معمولا توسط افراد با سطح دسترسی بالا نوشته می‌شوند را بررسی کنند.

2-2 اثربخشی امنیتی خوب
1. بررسی کنترل‌شده فایل‌های آرشیو
یک فایل مخرب می‌تواند در کنار فایل‌های مجاز دیگر تشکیل یک فایل آرشیو داده و برای مقصدی ارسال شود. برای تشخیص این فایل مخرب، گیرنده باید فایل‌های آرشیو را از حالت فشرده خارج کرده و تمامی فایل‌های درون آن را از نظر مخرب و یا مجاز بودن بررسی کند.
بررسی فایل‌های آرشیو باید به صورت کنترل‌شده انجام شود تا بررسی‌کننده دچار پیمایش‌های تو در تو یا حالت منع سرویس نشود. برای نمونه بررسی محتویات پست الکترونیکی که حاوی یک فایل متنی یک گیگابایتی آرشیوشده است و این فایل فقط از فضای خالی تشکیل شده است، منابع پردازشی قابل توجهی را اشغال می‌کند. نمونه‌ی دیگر، فایل‌های آرشیو تو در تو هستند. اگر فایل آرشیوی از 16 فایل آرشیو دیگر تشکیل شده باشد و هم‌چنین هر کدام از فایل‌های آرشیو جدید نیز از 16 فایل آرشیو دیگر تشکیل شده باشند و این کار تا 6 سطح ادامه داشته باشد، بررسی‌کننده‌ی محتویات پست الکترونیکی باید در حدود یک میلیون فایل را بررسی کند. در این مواقع تنظیم کردن زمان منقضی شدن برای پردازنده، حافظه و دیسک باعث می‌شود تا اگر کاری بیشتر از زمان تعیین‌شده ادامه پیدا کرد، آن کار لغو شده و منابع به سیستم بازگردند.
از حالت فشرده درآوردن فایل‌ها از انتهای فایل آرشیو شروع شده و تا زمانی که همه‌ی فایل‌ها ایجاد شوند، ادامه پیدا می‌کند. یک فایل آرشیو مخرب می‌تواند به‌راحتی به انتهای یک فایل عکس مجاز اضافه شود و در سمت گیرنده با اسکن فایل مجاز عکس، دریافت شود. بنابراین نیاز است تمامی پیوست‌ها از حالت فشرده خارج شده و فایل‌های ایجاد شده از آن‌ها با دقت بررسی شود...

دانلود پیوست

کارگاه تخصصی یکروزه ارتقای دانش امنیت متولیان فاوای کلیه دستگاه های اجرایی و حاکمیتی استان ایلام با شرکت بیش از 110 نفر در روز دو شنبه مورخ 18/05/95، با همکاری مرکز ماهر سازمان فناوری اطلاعات ایران و اداره کل فناوری اطلاعات استان ایلام توسط مرکز اپا دانشگاه فردوسی در قالب عناوین ذیل برگزار گردید:


تهدیدات امنیتی و آزمون نفوذپذیری شبکه های سازمانی
پیکربندی امن تجهیزات و زیرساخت با رویکرد دفاع در عمق
معماری و طراحي ایمن شبکه ها و زیرساخت سازمانی
جرم یابي و پاسخگویي به حوادث امنیتی در شبکه هاي سازمانی

بنابر ادعای محققین شرکت Sucuri، در دو ماه گذشته هزاران وب‌سایتِ مبتنی بر سیستم مدیریت محتوای WordPress و Jamoola تسخیر شده‌اند تا کاربران را به سمت باج‌افزار CryptXXX هدایت کنند.

ظاهراً این کمپین آلوده‌سازی از 20 خرداد آغاز شده است. تخمین زده می‌شود که حداقل دو هزار وب‌سایت با این هدف آلوده شده‌اند؛ اما احتمالاً آمار واقعی حدود پنج برابر این مقدار است چرا که تخمین ذکر شده بر اساس اطلاعات جمع‌آوری شده از طریق اسکنرِ SiteCheck بوده که اطلاعاتی محدود در اختیار دارد.

مشخصه‌ی اصلی این حمله آن است که از دامنه‌های realstatistics[.]info و realstatistics[.]pro استفاده می‌کند تا کاربران را به صفحه‌ی فرودِ[1] مربوط به کیتِ اکسپلویتِ Neutrino هدایت کند. Neutrino که اکنون پیشروترین تهدید در میان کیت‌های اکسپلویت به حساب می‌آید، تلاش می‌کند تا از آسیب‌پذیری‌های Flash یا PDF در سیستم‌های هدف استفاده کرده و باج‌افزار CryptXXX را نصب نماید.

چند روز پیش محققین Forcepoint اعلام کردند که دامنه‌های ذکرشده، به عنوان سیستم‌های هدایت ترافیک (TDS[2]) در حمله‌های توزیع Neutrino و RIG استفاده شده‌اند. محققین نهایتاً موفق به کشف رابطه‌ی دامنه‌ها با Blackhat‑TDS شدند. این نشان می‌دهد که آن‌ها تنها کاربران معمولی را به صفحه‌ی فرود هدایت می‌کردند، در حالی که برای رنج‌های IP مربوط به بلک‌لیست خود، صفحه‌ای پاک تحویل می‌دادند (این لیست عمدتاً مربوط به IP مربوط به فروشنده‌ها، موتورهای جستجو و سرویس‌های اسکنِ وب می‌شود).

با این حال، محققین Forcepoint مشخص نکرده‌اند که شدت این حمله و روش تسخیر وب‌سایت‌ها چگونه بوده است. Sucuri عنوان کرده که شصت درصد سایت‌های آلوده از نسخه‌های قدیمی Wordpress و Jamoola استفاده نموده و هم‌چنین حمله‌گران احتمالاً از مؤلفه‌های آسیب‌پذیری همچون پلاگین‌ها و اکستنشن‌ها استفاده کرده‌اند. محققین این شرکت معتقدند که استفاده از CMS از رده خارج‌شده، معمولاً نشان‌دهنده‌ی آن است که گردانندگان وب‌سایت احتمالاً سایر مؤلفه‌های امنیتی را نیز به‌روزرسانی نکرده‌اند.

با استفاده از هزاران وب‌سایت آلوده (که برخی سایت‌های مرتبط با امنیت همچون PCI Policy Portal را نیز شامل می‌شود)، حمله‌گران می‌توانند ده‌ها هزار کاربر را همزمان مورد حمله قرار دهند که نهایتاً موجب آلودگی بسیاری از آنها به باج‌افزار CryptXXX می‌شود. چند هفته پیش محققین SentinelOne افشاء کردند که گردانندگان CryptXXX در مدت زمان سه هفته‌ای، مبلغ پنجاه هزار دلار در تنها یک آدرسِ بیت‌کوین دست یافته‌اند.

واضح است که گردانندگان حمله همواره از کیت‌های اکسپلویت حاوی بیشترین امکانات‌ترین استفاده می‌کنند. ماه پیش بلافاصله پس از اینکه Angler (که سال‌ها بالاترین کیت اکسپلویت بود) از صحنه خارج شد، حمله‌کنندگان شروع به استفاده از Neutrino کردند.

CryptXXX اکنون به مهمترینِ باج‌افزارها تبدیل شده و در دو ماه گذشته چندین آپدیت برای آن ارائه شده است. آخرین آپدیت اعمال‌شده در CryptXXX عبارت است از

  • تغییر متن درخواست باج
  • استفاده از یک سایت پرداخت جدید به نام Microsoft Decryptor

[1] Landig Page

[2] Traffic Direction Systems

مقدمهای بر NFS

NFS پروتکلی است که از طریق آن یک کاربر مشتری میتواند به فایل­‌ها، دایرکتوریها و سایر منابع پایدار شبکه که در سرویسدهنده به اشتراک گذاشته ­شده است، دسترسی حاصل نماید. این پروتکل، برای اولین بار در سال 1984 توسط شرکت Sun Microsystems ارائه شده و تا بهحال تغییرات زیادی نموده است. این پروتکل اساساً برای سیستم­‌عاملهای خانواده یونیکس کاربرد داشته و گسترش یافته است ولی اکنون به عنوان یک استاندارد برای سیستمهای ناهمگون(heterogeneous) تبدیل شده است. با استفاده از این پروتکل مشتریان میتوانند با فایلهای موجود در شبکه رفتاری مشابه با فایلهای ذخیره شده در دیسکهای ذخیرهسازی محلی داشته باشند. به عبارت دیگر این سرویس امکانی را فراهم میآورد که با استفاده از آن میتوان به فایلهای موجود در شبکه همانند فایلهای ذخیره شده در هارد دیسک معمولی دسترسی داشت و از آنها استفاده نمود.

در NFS عملیات دسترسی به فایل مشترک با رد و بدل نمودن یک­ سری پیغام در هر دو سوی سرویس‌دهنده و سرویس­‌گیرنده صورت می­‌گیرد. همان‌طورکه بیان شد، NFS از مدل Client/Server در تعریف سیستمها استفاده مینماید و باعث تحولات اساسی در سیستمهای مبتنی بر یونیکس شده است چرا که هر سیستم میتواند بهعنوان یک سرویسدهنده امکان دسترسی به فایلهای خود را به سیستم‌های دیگر بدهد.

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

فایل پیوست

DLL مخفف کتابخانه پیوند پویا و بخش های خارجی از برنامه های کاربردی است که بر روی ویندوز یا هر سیستم عامل دیگری اجرا می شود. بسیاری از برنامه های کاربردی خودشان کامل نیستند و کد را در فایل های مختلف ذخیره می کنند. در صورتی که نیاز به کد پیدا شود فایل مرتبط در حافظه بارگذاری و استفاده می شود. این کار موجب کاهش اندازه فایل برنامه کاربردی به همراه بهینه سازی استفاده ازRAM می شود. در ارتباط با DLLها حملاتی تحت عنوانDLL Hijacking مطرح است. مسیر فایل های DLL توسط سیستم عامل ویندوز تعیین شده است. به طور پیش فرض اگر برنامه ای یک فایل DLL درخواست کند، سیستم عامل در همان پوشه که در آن برنامه ذخیره شده است، جستجو می کند. اگر آنجا پیدا نشد، به دنبال پوشه دیگر می رود. اولویت هایی که برای مسیرها تعیین شده است، به ویندوز کمک می کند که در چه فولدرهایی به دنبال فایل های DLL بگردد. این دقیقا نقطه ای است که حملات DLL Hijacking وارد عمل می شود. در این گزارش به معرفی این نوع حملات و تکنیک های مورد استفاده برای کاهش و رفع آنها خواهیم پرداخت.

1- فایل DLL یا کتابخانه پیوند پویا (Dynamic Link Library)

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

با استفاده از DLL، برنامه می تواند از اجزای جداگانه تشکیل شود (ماژولار شود). برای مثال یک برنامه حسابداری می تواند به صورت ماژول به فروش برسد. هر ماژول می تواند در صورتی که نصب شده باشد، در زمان اجرا به برنامه اصلی بارگذاری شود. به دلیل این که ماژول ها جدا هستند، زمان بارگذاری برنامه سریع تر است و ماژول تنها زمانی بارگذاری می شود که قابلیتی خاص مورد نیاز است. به علاوه به روزرسانی برای اعمال بر هریک از ماژول ها آسان تر است بدون این که بر قسمت های دیگر برنامه تاثیر گذارد. برای مثال ممکن است یک برنامه حقوق داشته باشیم و نرخ مالیات در هر سال تغییر کند. زمانی که این تغییرات مربوط به یک DLL است، می توان به روزرسانی را بدون نیاز به ساخت و یا نصب دوباره برنامه اعمال کرد.

2- مزایای DLL

لیست زیر برخی از مزایای استفاده برنامه ها از DLL را نشان می دهد:

  • استفاده از منابع کمتر: زمانی که چندین برنامه کتابخانه یکسانی از توابع را استفاده می کنند، DLL میتواند کدهای تکراری که به دیسک و حافظه بارگذاری می شود را کاهش دهد .
  • ترویج معماری ماژولار: DLL به ترویج برنامه های ماژولار در حال توسعه کمک می کند. همچنین کمک می کند که برنامه های بزرگ که به چندین نسخه زبان مختلف نیاز دارند یا برنامه هایی که نیاز به معماری ماژولار دارند توسعه داده شوند. مثالی از برنامه ماژولار برنامه حسابداری است که چندین ماژول دارد که می تواند به صورت دینامیک در زمان اجرا بارگذاری شود.
  • سهولت گسترش و نصب: هنگامی که تابع درون DLL نیاز به به روزرسانی یا تعمیر دارد، برای استقرار و نصب و راه اندازی DLL نیازی نیست که برنامه مجدد به DLL لینک شود. به علاوه اگر چندین برنامه DLL مشابهی را استفاده کنند، همه برنامه ها از به روزرسانی DLL بهره مند می شوند. این موضوع هنگام استفاده از DLL طرف سوم که به طور منظم به روزرسانی یا تعمیر می شود، بسیار موثر است.

DLL Hijacking -3 چیست؟

DLL Hijacking که عموماً تحت عنوان Load Order Hijacking یا Search Order Hijacking شناخته می شود یک تکنیک دوام بدافزار برای گریز از تشخیص بوده و همچنین به عنوان یک چالش مهم برای محققان مطرح است. برطبق مقاله ای از مایکروسافت DLL Hijacking به صورت زیر تعریف می شود:

زمانی که برنامه ای به صورت پویا و بدون مشخص کردن نام مسیر کامل کتابخانه ای را بارگذاری می کند، ویندوز برای تعیین محل DLL با جستجوی مجموعه تعریف شده ای از دایرکتوری ها با ترتیب خاصی تلاش می کند. اگر حمله کننده بتواند هنگام جستجوی DLL کنترل یکی از دایرکتوری ها را به دست بگیرد، می تواند یک کپی مخرب از DLL در آن دایرکتوری قرار دهد، این اغلب با عنوان Preloading attack یا Binary planting attack شناخته می شود. اگر سیستم قبل از جستجوی دایرکتوری دستکاری شده کپی مجاز از DLL را پیدا نکند، کپی مخرب را پیدا خواهد کرد.

از آنجا که DLL ها به عنوان یک افزونه هستند و اغلب در اکثر برنامه های کاربردی در سیستم ضروری هستند، در پوشه های مختلفی در سیستم قرار گرفته اند. اگر فایل DLL اصلی با یک فایل DLLقلابی که دارای کد مخرب است، جایگزین شود به عنوان DLL Hijacking شناخته می شود. این آسیب پذیری ها در نرم افزارهایی همچون Windows Movie Maker و Windows Address Book دیده می شود. به منظور درک DLL Hijacking ابتدا بایستی نحوه بارگذاری فایل های DLL توسط ویندوز هنگامی که آدرس کامل کتابخانه داده نشده است را دانست. ویندوز نیازی ندارد که برنامه های کاربردی یک مسیر کامل برای DLL های بارگذای شونده در زمان اجرا مشخص کند. به همین علت برنامه نویسان اغلب مسیر کامل به فایل های DLLای که می خواهند استفاده کنند، مشخص نمی کنند. این می تواند منجر به این مشکل شود که DLLها را نتوان پیدا کرده و استفاده کرد. هنگامی که یک مسیرکامل ارایه نمی شود ویندوز تلاش می کند که DLL ها را در مکان هایی از پیش تعیین شده قرار دهد.

به طور پیش فرض اولین موردی که یافت می شود، اولین آیتمی است که استفاده می شود. بنابراین این امکان برای مهاجم وجود دارد که این ترتیب را با اضافه کردن یک DLL مخرب با همان نام نسخه مجاز در مکانی قبل از آن عوض کند که این باعث می شود سیستم عامل به طور ناخواسته DLL مخرب را بارگذاری کند. اگر برنامه کاربردی DLL را تنها با نام آن بارگذاری می کند (به طور مثال ntshrui.dll) ویندوز ترتیب تعریف شده از قبل را برای شناسایی و بارگذاری دنبال می کند و اولین کتابخانه پیدا شده با نام ntshrui.dll را بارگذاری می کند.

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

دایرکتوری جاری

دایرکتوری سیستم

دایرکتوری سیستم 16 بیتی

دایرکتوری ویندوز

دایرکتوری های ذخیره شده در متغیر PATH

برای مثال اگر برنامه ای (مثلاً Test.exe) DLL ای را تنها توسط نام بارگذاری کند(مثلا foo.dll ) ویندوز ترتیب جستجویی را بسته به این که SafeDllSearchMode فعال یا غیرفعال است، برای تعیین محل DLL مجاز دنبال می کند. اگر حمله کننده دانشی درباره این برنامه داشته باشد، می تواند DLL مخربی در مسیر جستجوی آن با همان نام قرار دهد و برنامه را مجبور کند که DLL مخرب را بارگذاری کند.

برنامه هایی که از مکان های ناامن اجرا می شوند برای مثال پوشه های قابل نوشتن توسط کاربر همانند پوشه Downloads یا TempDirectory تقریبا همیشه در معرض این آسیب پذیری هستند.

4- جزئیات حمله

بسته به پیکربندی سیستم، برنامه می تواند تصمیم بگیرد که ترتیب مسیرهایی که باید برای بارگذاری DLL جستجو کند، چگونه باشد. به طور پیش فرض ترتیب این جستجو به صورت زیر است :

  • مسیری که از آن برنامه کاربردی بارگذاری می شود.
  • دایرکتوری جاری
  • دایرکتوری سیستم، معمولاً C:\Windows\System32\ (تابع GetSystemDirectory برای دستیابی به این دایرکتوری فراخوانی می شود)
  • دایرکتوری سیستم 16 بیتی – هیچ تابع اختصاص داده شده برای بازیابی مسیر این دایرکتوری وجود ندارد، اما این دایرکتوری نیز جستجو می شود.
  • دایرکتوری ویندوز، تابعGetWindowsDirectorبرای دستیابی به این دایرکتوری فراخوانی می شود.
  • دایرکتوری های لیست شده در متغیر محیطی PATH

در جستجوی این مسیرها برنامه اولین DLL ای را که با آن نام پیدا کرد، استفاده می کند.

در این مورد دایرکتوری جاری مشکل است. زمانی که یک برنامه تصمیم به بارگذاری DLL از دایرکتوری جاری می گیرد می تواند به DLL Hijacking منجر شود. برای مثال اگر کاربر یک سند Microsoft word را باز می کند، Microsoft office سعی خواهد کرد که مولفه DLL آن را از مکان فایل داکیومنت بارگذاری کند. حمله کننده سپس می تواند یک DLL بدخواه در مکان سند جایگذاری کند و در نتیجه Microsoft office کد بدخواهانه را بارگذاری می کند.

با فرض این که SafeDllSearchMode فعال شده است (که به صورت پیش فرض فعال است) برای حمله استفاده از این تکنیک بسیار سخت تر است. در این صورت سیستم عامل اول بررسی می کند که آیا یک DLL با همین نام در حال حاضر در حافظه بارگذاری شده است یا آیا DLL در کلید رجیستری (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs) تعریف شده است(KnownDLLs). اگر هیچ یک از شرایط برقرار نبود ویندوز با استفاده از ترتیب زیر کتابخانه ها را بارگذاری می کند:

  • دایرکتوری که از آن برنامه بارگذاری می شود.
  • دایرکتوری سیستم (C:\Windows\System32)
  • دایرکتوری سیستم 16 بیتی (C:\Windows\System)
  • دایرکتوری ویندوز (C:\Windows)
  • دایرکتوری کار جاری ([1]CWD)
  • دایرکتوری های لیست شده در متغیرهای محیطی PATH(System و بعد از آن user)

با این وجود دایرکتوری جاری هنوز در لیست دایرکتوری ها برای جستجو است. تفاوت در اینجا در این است که برنامه در ابتدا دایرکتوری های سیستم را برای مولفه های DLL جستجو می کند، اگر پیدا نشد، سپس دایرکتوری جاری را جستجو می کند.

به عنوان یک قاعده کلی برنامه های اجرا شونده خارج از “C:\Windows\System32” که کتابخانه ای را بدون ارایه مسیر کامل بارگذاری می کنند، اهداف بالقوه هستند. توجه داشته باشید که کتابخانه درخواست شده نباید قبلاً در حافظه وجود داشته باشد یا در مقدار رجیستری KnownDlls قرار گرفته باشد.

5- پیداکردن آسیب پذیری های DLL Hijacking

پیداکردن آسیب پذیری در برنامه ها اولین قدم برای سواستفاده از آن است. روش صحیح برای این کار استفاده از Process Monitor برای دیدن این که چه زمانی برنامه جستجویی را برای فایل DLL اجرا می کند. هنگامی که Process Monitor بارگذاری می شود می توان سعی کرد که یک تابع از DLL دیگری را به کار انداخت یا این که منتظر باشید تا این که یکی به کار انداخته شود. بعد از انجام این کار، تمام آن چه که نیاز است این است که به منوی Filter رفته و فیلترهای خود را اعمال کنید.

اگر شما چیزی شبیه این ها پیدا کردید بسیار محتمل است که یک آسیب پذیری DLL Hijacking پیدا کرده باشید.

6- پیداکردن نام توابع ازDLL

برای ایجاد کردن یک DLL جدید با کد مخرب ، ابتدا بایستی نام توابعی که در آن به کار رفته است را بدانیم . در ویندوز این می تواند توسط ابزار DUMPWIN انجام شود. با DUMPWIN ما می توانیم از گزینه /EXPORTS استفاده کنیم. در زیر مثالی از خروجی dll نمونه آمده است:

Dump of file C:\example.dll

File Type: DLL

Section contains the following exports for example

00000000 characteristics

4FC31DEF time date stamp Mon Jun 05 18:32:49 2013

0.00 version

1 ordinal base

3 number of functions

3 number of names

ordinal hint RVA name

1000007BA0 output_data

2 1 00007C40 show_integer

3 2 00008940 add_integers

Summary

1000 .CRT

1000 .bss

1000 .data

1000 .edata

1000 .idata

1000 .rdata

1000 .reloc

9000 .text

1000 .tls

گزینه دیگر استفاده از یک اشکال زدا است. اشکال زداها می توانند متن آشکاری که در برنامه ها ذخیره شده است را به شما نشان دهند. ما می توانیم نام هر فایل DLL ارجاع شده و ذخیره شده، را نیز به صورت متن آشکار ببینیم.

7- دفاع در برابر DLL Hijacking

مهم ترین بخش از تعریف یک آسیب پذیری، توضیح چگونگی مقابله با آن است. مسئولیت حفاظت از کاربران به عهده خود توسعه دهندگان نرم افزار می افتد. در مورد DLL Hijacking برای اجتناب از این مشکل مسیر کامل به کتابخانه بایستی مشخص شود.

گزینه دیگر انتقال فایل های DLL به جایی است که در ترتیب جستجو زودتر چک می شود. گزینه دیگر ایجاد یک هش Checksum از فایل DLL و ذخیره آن درون خود برنامه است، بنابراین در زمان اجرا زمانی که DLL پیدا شد هش Checksum آن بایستی با هش ذخیره شده درون برنامه مطابقت کند. این روش می تواند توسط استفاده از یک روش هشینگ قوی به همراه Salt یا توسط استفاده از کلیدهای عمومی و خصوصی داخل برنامه برای رمز کردن checksum خارج از برنامه و رمزگشایی آن بهبود داده شود.

کاربران همچنین توانایی محافظت از خود با درنظر گرفتن اقدامات احتیاطی خاصی را دارند. کاربر می تواند اطمینان حاصل کند که فایل هایی که دارد باز می کند در همان دایرکتوری DLL هایی نیست که مشکوک به نظر می رسد. برای مثال اگر DLL ای به همراه عکسی که شما دانلود کرده اید بیاید، بهتر است که قبل از بازکردن عکس DLL را حذف کنید. کاربران همچنین توان تغییر کلید رجیستری CWDIllegalInDllSearch را دارند.در ضمن کاربران می توانند دو کلید رجیستری مختلف خودشان ست کنند.


[1] current working directory

کارخانه‌ی چینیِ Lenovo بار دیگر به خاطر آسیب‌پذیری در BIOS لپ‌تاپ‌های خود زیر ذره‌بین قرار گرفته است. یک محقق امنیتی به نام Dmytro Oleksiuk با نام مستعار Cr4sh اخیراً به کدی دست یافته که آسیب‌پذیریِ دسترسی‌های روزِصفر در BIOSهای Lenovo را تشدید می‌کند.

باگ UEFI، کامپیوترهای Lenovo را در معرض اجرای کدهای اجراییِ دلخواه در حالت مدیریت سیستم یا SMM[1] قرار می‌دهد. این موضوع باعث می‌شود پروتکل‌های امنیتیِ ویندوز بی‌اثر شوند. این باگ از آسیب‌پذیری حفاظت نوشتن در حافظه flash استفاده می‌کند و لذا به کاربر اجازه می‌دهد قابلیت‌هایی مثل UEFI Secure Boot و Virtual Secure Mode و Credential Guard را در کامپیوترهای Lenovo مبتنی بر ویندوز غیرفعال کند. بایستی توجه داشت که این موارد تنها خطرات کشف شده هستند و امکان اضافه شدن به این لیست در روزهای آینده وجود دارد.

لپ‌تاپ‌های سری ThinkPad به دلیل باگ‌های موجود در مدل‌های قدیمی‌ترِ X220s، به عنوان لپ‌تاپ‌هایی بسیار آسیب‌پذیر شناخته می‌شوند. مشابه این آسیب‌پذیری در BIOS قبلاً نیز در سال 2010 در برخی لپ‌تاپ‌های HP یافت شده بود لذا به نظر می‌رسد Lenovo آن آپدیتِ آسیب‌پذیرِ میان‌افزار را تنها کپی-پیست کرده است. با این حال، بنا بر ادعای Cr4sh، شرکت اینتل وجود آسیب‌پذیری در میان‌افزار را در سال 2014 شناسایی کرده و برطرف نموده است. اما این موجب برانگیخته شدن سوال دیگری می‌شود که چگونه این آسیب‌پذیری دوباره در کامپیوترهای Lenovo بروز کرده است. برخی گمانه‌زنی‌ها حکایت از این دارد که این آسیب‌پذیری بدین منظور گنجانده شده تا FBI بتواند از این طریق به جاسوسی بپردازد.

Lenovo در پاسخ به این موضوع در وب‌لاگ خود عنوان کرده که به امنیت محصولات خود پایبند است و با همکاری اینتل و IBVهای خود در حال تصحیح این آسیب‌پذیری در کوتاه‌ترین زمان ممکن هستند. از مطلب وبلاگ اینطور به نظر می‌رسد که Lenovo قصد دارد قصور در این امر را متوجه اینتل (تولیدکننده‌ی اصلی کدهای چیپ) کند و در عین حال نویسنده‌ی اصلی کد را پیدا کرده و هدف پشت این خطای مرموز در BIOS در سری‌های ThinkPad را متوجه شود.

Cr4sh جزئیاتی را برای تشخیص آسیب‌پذیریِ سیستم در برابر این موضوع در Github ارائه کرده است.


[1] System Management Mode

صفحات: 1 2 »