رخنه امنیتی UPnP در پروتکل‌های SSDP-SOAP-UPnP

سلام

Security Flaw in Universal Plug and Play (UPnP)
Unplug. Don’t Play.
(Copyright 2012-2013 Rapid7, Inc.)

مقدمه از خودم!

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

چکیده عملکرد:

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

پروتکل UPnP از مشکلات امنیتی اساسی رنج می برد که بسیاری از آنها در طی ۱۲ سال گذشته برجسته شده اند. تصدیق هویت موضوعی است که به ندرت توسط کارخانه های سازنده دستگاهها پیاده سازی می شود. مباحث مربوط به امتیازات  و دسترسی ها نیز اغلب در شبکه های غیر قابل اعتمادو… رها شده است. در این مقاله تمرکز ما روی دستگاه های شبکه و برنامه هایی است که قابلیت UPnP روی آن فعال است.

سلام

Security Flaw in Universal Plug and Play (UPnP)
Unplug. Don’t Play.
(Copyright 2012-2013 Rapid7, Inc.)

مقدمه از خودم!

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

چکیده عملکرد:

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

پروتکل UPnP از مشکلات امنیتی اساسی رنج می برد که بسیاری از آنها در طی ۱۲ سال گذشته برجسته شده اند. تصدیق هویت موضوعی است که به ندرت توسط کارخانه های سازنده دستگاهها پیاده سازی می شود. مباحث مربوط به امتیازات  و دسترسی ها نیز اغلب در شبکه های غیر قابل اعتمادو… رها شده است. در این مقاله تمرکز ما روی دستگاه های شبکه و برنامه هایی است که قابلیت UPnP روی آن فعال است.

آمار و نمودارهای این مقاله از نتایج مربوط به اسکن طی پنج ماه و نیم بدست آمده است. از تاریخ ۱ ژوئن تا ۱۷ نوامبر ۲۰۱۲ در هر هفته یکبار به تمام آدرس های IPv4 قابل مسیریابی درخواست کشف UPnP ارسال شد. نتیجه این پویش شناسایی بیش از ۸۱ میلیون آدرس IP یکتا بود که به درخواست کشف UPnP پاسخ دادند. در گام بعدی مشخص شد که حدود ۱۷ میلیون از این سیستم ها جهت سیستم احراز هویت در UPnP از پروتکل SOAP یا همان UPnP Simple Object Access Protocol استفاده می کردند. این سطح از دستگاه هایی که در معرض این موضوع هستند باعث افزایش امیدواری محققان و البته هکرها  خواهد شد.

دراین مقاله تمام سیستم های متصل به اینترنت که قابلیت UPnP روی آن ها فعال است مورد بررسی قرار می گیرد. در این مقاله مشاهده می کنید که بیش از ۱۵۰۰ فروشنده و ۶۹۰۰ محصول حداقل از یکی از رخنه های امنیتی مربوط به UPnP رنج می برند. بیش از ۲۳ میلیون سیستم در مقابل اجرای یک کد ساده از راه دور آسیب پذیر بوده اند که در همین مقاله در مورد آن صحبت خواهیم کرد.

گروه Rapid 7 برای نمایش در معرض آسیب بودن دستگاه های سازنده و پروژه های متن باز با CERT/CC کار می کند. متاسفانه بیشتر شرکت های سازنده مسایل امنیتی سیستم ها را رها کرده اند و ترجیح می دهند بعد از کشف آسیب پذیری آن را اصلاح کنند. به همین دلیل گروه Rapid 7 پیشنهاد می کند که UPnP را به صورت کلی برای دستگاه های متصل به اینترنت غیر فعال کنید. گروه Rapid 7 مجموعه ای از ابزارهای را به صورت رایگان برای اهدافی چون شناسایی سیستم های UPnP-فعال فراهم کرده است. از قبیل نرم افزار رایگان ScanNow برای UPnP، ماژول برای فریم ورک MetaSploit و به روز رسانی برای پلتفرم Nexpose.

آمار به صورت خلاصه:

۲۲% از آدرس های IPv4 عمومی به درخواست اکتشاف UPnP از اینترنت پاسخ دادند.
۸۱ میلیون آدرس IP به درخواست اکتشاف UPnP پاسخ دادند. کمی بیشتر از تعداد تمام IPهای ثبت شده در کانادا می باشد.
۲۰% از این ۸۱ میلیون سیستم از API مربوط به SOAP در اینترنت استفاده می کردند. این سرویس به نفوذگر اجازه می دهد تا جای خود را در سیستم هدف و پشت فایروال باز کند.
۴ کیت توسعه نرم افزاری برای محاسبه و کشف ۷۳% از تمام UPnP های کشف شده در مثال ها کافی است.
۳۳۲ محصول از MiniUPnP نسخه ۱.۰ استفاده می کنند که تخریب و اکسپلویت از راه دور دارد. بیش از ۶۹% از تمام MiniUPnPهای شناسایی شده از نسخه ۱.۰ یا قدیمی تر از آن استفاده می کند.
۲۳ میلیون از موارد شناسایی شده از نسخه ای libupnp استفاده می کردند که سیستم را در معرض اجرای کد از راه دور قرار می دادند.
۱ بسته UDP جهت اکسپلویت مربوط به آسیب پذیری هر ۸ عدد libupnp شناسایی‌شده استفاده می شود که این بسته قابل استراق سمع است.

اقدام فوری

با توجه به سطح بالایی از موارد در معرض و پتانسیل تأثیرات مربوط به حملات موفق گروه Rapid 7 به شدت پیشنهاد می کند که قابلیت UPnP را در تمام سیستم ها و دستگاه هایی که با بیرون ارتباط برقرار می کنند غیر فعال کنید.

فراهم کنندگان سرویس های اینترنت ISPها

ISP ها باید تمام ابزارهایی که به مشتریان سرویس می دهد را جهت اطمینان از غیر فعال بودن UPnP در واسط های WAN بازبینی کنند.

اگر یکی از ابزارها تحت تأثیر آن بود یکی از راه حل های زیر به کار می آید:

• قرار دادن به روزرسانی تنظیماتی که UPnP را در قسمت سرویس دهی غیرفعال کند.
• قرار دادن به روزرسانی نرم افزارهایی که قابلیت UPnP را از روی دستگاه ها حذف کند.
• جایگزینی ابزارهای مشتری با دستگاه هایی که به صورت امن پیکربندی شده اند.
• پیاده سازی ACL شبکه برای پورت ۱۹۰۰ در UDP و پورت های خاص TCP.

تجارت:

شرکت ها باید مطمئن شوند که UPnP برای دستگاه های متصل به اینترنت غیرفعال است. گروه Rapid 7 نرم افزار ScanNow UPnP را به عنوان ماژولی برای MetaSploit به منظور مشخص کردن آسیب پذیری سرویس UPnP فراهم کرده است. اگر ابزاری پیدا کردید که گزینه UPnP روی آن فعال است بهترین کار این است که آن را غیر فعال کنید و در صورتی که این اجازه را نمی دهد از دستگاه جایگزین استفاده کنید که اجازه غیرفعال سازی آن را فراهم کند.

بسیاری از دستگاه های متصل به شبکه در کنار فایروال قابلیت UPnP را فعال کرده اند؛ از قبیل پرینترهای شبکه، دوربین های آنلاین، سیستم های ذخیره سازی و سرورهای رسانه ای و هر دستگاهی که قابلیت UPnP روی آن فعال است. در این گونه موارد فروشندگان می‌بایست جهت به روز رسانی آن اقدام کنند. اگر UPnP را نمی توانستید غیر فعال کنید و فروشنده ی آن هم فایل به روز رسانی ارائه نمی کرد خردمندانه ترین کار این است که این دستگاه را از سایر بخش های متصل به اینترنت جدا کنید.

کاربری خانگی و همراه

این کاربران باید از غیرفعال بودن UPnP روی مسیریاب خانگی و دستگاه های پهنای باند همراه اطمینان حاصل کنند. ابزار رایگان ScanNow UPnP از Rapid 7 می تواند جهت آشکار سازی دستگاه های مربوطه کمک شما باشد. اگر امکان غیرفعال سازی UPnP وجود نداشت می‌بایست با فروشنده آن دستگاه تماس گرفته و جهت فایل بروز رسانی اقدام کنید. اگر فایل به روز رسانی وجود نداشت باید کاربر دستگاه های آسیب پذیر را با دستگاه های فاقد UPnP جایگزین کرده و یا حداقل با دستگاه هایی آن را عوض کنند که قابلیت غیرفعال سازی UPnP در آن ها وجود داشته باشد.

---

مقدمه

UPnP پروتکل استانداردی جهت تسهیل ارتباط بین کامپیوترها و دستگاه های متصل به شبکه است. این پروتکل به صورت پیش فرض روی میلیون ها سیستم فعال است شامل روترها، پرینتر ها، سرورهای مدیا، تلویزیون های هوشمند و سرورهای ذخیره کننده شبکه… پشتیبانی از UPnP به صورت پیش فرض روی سیستم عامل مایکروسافت، مک و بسیاری از توزیع های لینوکس فعال است.

پروتکل UPnP از تعدادی از مشکلات امنیتی بنیادی رنج می برد که بسیاری از آن ها طی ۱۲ سال گذشته مورد توجه قرار گرفته است. تصدیق هویت روی دستگاه های سازنده به ندرت پیاده سازی شده است. قابلیت امتیازبندی نیز اغلب در شبکه های غیرقابل اعتماد و پیاده سازی نرم افزارهای UPnP همراه با رخنه ها و آسیب پذیری های فراوان عرضه شده است. تمرکز این مقاله روی دستگاه های شبکه و برنامه هایی است که UPnP را فعال کرده اند.

تمرکز این مقاله روی سه نوع اصلی از این مشکلات است:

1. رخنه های برنامه نویسی در پیاده سازی پروتکل اکتشاف UPnP یا همان SSDP می تواند به صورت بدخواهانه باعث Crash  و از کار افتادن سرویس ها و اجرای کدهای مخرب گردد.
2. واسط کنترل کننده UPnP  یا SOAP شبکه های خصوصی را در معرض حملات از بیرون شبکه مثل اینترنت و ربایش اطلاعات حساس قرار می دهد.
3. رخنه های برنامه نویسی در پیاده سازی UPnP HTTP و SOAP باعث از کار افتادن سیست و اجرای کدهای مخرب می گردد.

Univarsal Plug & Play

پروتکل UPnP جهت تسهیل در کشف و کنترل دستگاه های شبکه طراحی شده است. این قابلیت ها در دستگاه های مختلف، متفاوت عمل می کند اما به طور عام شامل کنترل پورت های ورودی، نگاشت روترهای خانگی، تسهیل در تعیین هویت پرینترهای تحت شبکه و مدیریت سرویس های مدیا از قبیل جریان های تصویری می شود. برنامه ها از UPnP جهت دسترسی و پیکربندی سرویس های متصل به شبکه استفاده می کنند. برای مثال یک برنامه مربوط به BitTorrent ممکن است از UPnP جهت تعیین هویت آدرس IP عمومی شبکه و هدایت خودکار اتصالات وارد شونده به روتر در کامپیوتری که برنامه BitTorrent در آن در حال اجراست، استفاده کند. مثال بعدی مربوط به ویزارد Add Device در ویندوز مایکروسافت است. این wizard از پروتکل UPnP جهت تعیین هویت دستگاه های تحت شبکه از قبیل اسکنرها و پرینترها در شبکه های محلی استفاده می کند. UPnP جهت شناسایی و مدیریت این دستگاه ها استفاده می شود. این مدیریت شامل مواردی همچون خالی کردن صف پرینت و یا آغاز یک اسکن می شود.

UPnP از دو سرویس متفاوت تشکیل شده است.

1. پروتکل شناسایی سرویس ساده (SSDP=Simple Service Discovery Protocol) که به پورت UDP 1900 گوش می دهد و مسئولیت آن اعلان سرویس های فعال و پاسخگویی به درخواست های شناسایی (discovery) است.
2. دومین کامپوننت UPnP سرویس HTTP است. در طول روند شناسایی، پروتکل SSDP جهت تعیین محل سرویس UPnP HTTP و فایل توصیف سرویس برای سیستم خواسته شده استفاده می شود. فایل توصیف سرویس (Servicec Description File) یک سند XML است که به وسیله سرویس UPnP HTTP  میزبانی می شود. پورت مربوط به این سرویس از نوع TCP بوده و با توجه به فروشنده آن متفاوت است و معمولاً مقداری تصادفی دارد و در واقع پاسخ شناسایی SSDP محل جاری این سرویس را مشخص می کند.

علاوه بر آن جهت فراهم آوردن فایل توصیف کننده سرویس، سرویس HTTP  از واسط SOAP نیز میزبانی می کند. SOAP یک راه برای سایر سیستم های روی شبکه جهت فراخوانی تعریف مجموعه ای از توابع فراهم می کند. تمام توابع مفید و کاربردی UPnP به وسیله فراخوانی APIهای SOAP پیاده شده است که برای مشاهده دسته بندی و توضیحات آن باید به پروفایل مربوط به دستگاه مراجعه فرمایید. هر پروفایل تعدادی از سرویس ها را پیاده سازی کرده است که شامل مجموعه ای از رفتارها، توابع و متغیرها می شود. به صورت کلی این پروفایل شامل دستگاه های Gateway اینترنت، پرینترها و سرویس های مدیا می شود.

دستگاهی که قصد استفاده از دستگاه های UPnP-فعال را دارد ابتدا باید یک درخواست SSDP M_SEARCH به شبکه محلی ارسال کند. سیستم هایی که یک سرویس SSDP محلی را اجرا می کنند ممکن است بتوانند به سادگی به کش دستگاه های موجود درخواست ارسال کنند که پاسخ می تواند بیانگر XML مربوط به محل HTTP از توصیف کننده دستگاه باشد. این XML شامل جزییاتی از اطلاعات مربوط به دستگاه و لیست سرویس های پشتیبانی‌شده، می شود. زمانی که device discription ها بدست می آید و لیست سرویس ها پیدا می شود درخواست دیگری با هدف بدست آوردن فایل XML مربوط به توصیف کننده سرویس ها ارسال می شود که در آن فعالیت های فعال، پارامترهایی که اتخاذ کرده و فرمت پاسخ را مشخص می کند. در نهایت برنامه یک درخواست SOAP ارسال می کند. (به منظور مشخص کردن URL مربوط به سرویس هدف) نوع فعالیت SOAP در قسمت هدر HTTP و پارامترهای ورودی به عنوان سند XML در قسمت body ارایه می شود. سپس دستگاه این درخواست را اجرا کرده و پاسخ را به صورت سند XML دیگری بازخواهد گرداند.

---

نتایج تحقیقات

این مقاله بر اساس نتایج آزمایشاتی است که در نیمه دوم سال ۲۰۱۲ انجام شده است. هدف این پژوهش بدست آوردن تعداد سیستم های UPnP-فعالی است که در معرض سرویس SSDP در اینترنت قرار دارند. در گام بعدی هدف ما نمایش تعداد سیستم هایی است که علاوه بر SSDP سرویس SOAP را نیز فعال کرده اند و در نهایت مشخص کردن نقاط ضعف امنیتی در بیشتر پیاده سازی های UPnP.

فراوانی استفاده از سرویس SSDP در UPnP

سرویس SSDP در UPnP به دلیل شناسایی دستگاه های داخل شبکه از بیرون طراحی شده است. این سرویس، اطلاعاتی راجع به نسخه و جزییاتی پیرامون پیکربندی شبکه را از طریق پورت UDP 1900 نمایش می دهد. جستجوهای ما نشان می دهد که سرویس SSDP در خصوص هزاران محصول به صورت نادرست پیکربندی شده است. نتایج حاکی از شیوع سرویس SSDP در اینترنت است. بیش از ۸۱ میلیون آدرس IP یکتا که در معرض سرویسی SSDP قرار دارد در اینترنت یافت شد.

فراوانی استفاده از سرویس SOAP در UPnP

سرویس SOAP در UPnP دسترسی به دستگاه هایی را فراهم و عملکرد آن ها را کنترل می کند که نباید در شبکه های غیر قابل اعتماد به آن دسترسی داشت. مثل ایجاد و بازکردن یک حفره در فایروال. یافته های ما نشان می دهد بیش از ۱۵۰۰ فروشنده دستگاه شبکه و ۶۹۰۰ دستگاه سرویس SOAP را به صورت نادرست پیکربندی کرده اند. تحقیقات ما نشان می دهد که در حدود ۱۷ میلیون آدرس IP یکتا در اینترنت در معرض SOAP قرار دارند.

UPnP بیشتر بر ۴ نوع پیاده سازی تمرکز دارد

بیش از ۷۳% از تمام UPnP های شناسایی شده از یکی از ۴ مدل کیت توسعه نرم افزاری یا همان Softwaer Development Kit یا همان SDK مشتق شده است. این SDKها عبارتند از:

1. SDK پرتابل برای دستگاه های UPnP
2. MiniUPnP
3. یک پشته تجاری که توسط Broadcom توسعه داده شده است.
4. یک کیت تجاری دیگر که البته نتوانستیم به توسعه دهنده ای خصوصی برای آن برسیم.

تمرکز شدید در استفاده از این نوع پیاده سازی‌ها ذاتاً باعث افزایش تأثیرات مخرب هر نوع آسیب پذیری ای می شود که در هر کدام از آن ها پیدا شود (به دلیل شیوع استفاده از آن ها)

دستگاه های تحت شبکه ای که از پیاده سازی UPnP تاریخ گذشته بهره می برند

دستگاه های UPnPیافت شده که از Portable SDK یا کتابخانه های MiniUPnP استفاده می کنند هر دو نسخه ی کتابخانه ی برنامه را در پاسخ SSDP نمایش می دهند. تحلیل های ما بیانگر این موضوع است که اکثر دستگاه ها از کتابخانه های UPnPای استفاده می کنند که برای بیش از ۴ سال پیش است. در بسیاری از موارد نیز حتی دستگاه هایی که اخیراً تولید شده اند هنوز از کتابخانه های UPnP تاریخ گذشته استفاده می کنند.

آسیب پذیری قابل اکسپلویت در Portable SDK برای دستگاه های UPnP با پارسر SSDP

تمام دستگاه های UPnP-فعال با Portable SDK که از پارسر SSDP بهره می برند دارای هشت نوع اکسپلویت آسیب پذیر از راه دور هستند. اگرچه که بیشتر سیستم هایی که تمام این آسیب پذیری ها را اجرا می کردند از نسخه های منسوخ استفاده می کنند اما تحقیقات نشان می دهد که حتی در جدیدترین نسخه های آن نیز تعداد دو آسیب پذیری از نوع سرریز بافر از راه دور وجود دارد.

بیش از ۲۵% از سیستم هایی که از سرویس SSDP استفاده می کنند از این برنامه بهره می برند  (که در حدود ۲۳ میلیون می شود. این موضوع با CVEهای زیر تعیین شده است.)

آسیب پذیری مربوط به CVE-2012-5958 و CVE-2012-5959 تمام نسخه های Intel SDK و تمام نسخه های Portable SDK تا نسخه ۱.۶.۱۸ را تحت تأثیر قرار می دهد.

سرریز بافر قابل اکسپلویت در MiniUPnP هندلر SOAP

کتابخانه MiniUPnP دارای یک اکسپلویت مربوط به سرریز بافر از راه دور در SOAP است. این آسیب پذیری در نسخه ۱.۱ درست شده است اما هنوز بیش از ۱۴% از سرویس های SSDP از نسخه MiniUPnP 1.0 استفاده می کنند.  این آسیب پذیری تا حدودی محدود به این موضوع است که نفوذگر می بایست به نقطه پایانی SOAP دسترسی داشته باشد. [در تحقیقات مشخص شده است که] بیش از ۳۳۰ محصول از نسخه قدیمی MiniUPnP استفاده کرده و نقطه پایانی SOAP را به صورت عمومی در اینترنت به معرض نمایش قرار می دهند. این موضوع در CVE-2012-0230 تعیین شده است.

آسیب پذیری DOS در MinuUPnP در پارسر SSDP

در کتابخانه MiniUPnP تعدادی از پارسرها جهت هندلر SSDP وجود دارد که آسیب پذیر اند. این آسیب پذیری در نسخه ۱.۴ درست شده است ولی در نسخه‌های قبل از آن، به نفوذگر اجازه می داد تا پروسه ای که از کتابخانه MiniUPnP بهره می برد را متوقف ساخته (terminate) و به آن پایان دهد. این موضوع در CVE-2012-0229 مشخص شده است.

---

روش شناسی

آمار موجود در این مقاله از جمع آوری داده ها طی زمان پنج ماه و نیم (از تاریخ ۱ ژوئن تا ۱۷ نوامبر ۲۰۱۲) بدست آمده است. درخواست های UPnP SSDP M-SEARCH به تمام آدرس های IPv4 در شبکه اینترنت و تقریبا هر هفته یکبار ارسال شده است. بیش از ۹۳ میلیون یافته یکتا و منحصر به دست آمد که ترکیبی از آدرس های IP و نسخه های سرویس دهنده های UPnP SSDP می باشد. این یافته ها در مجموع ۸۱ میلیون آدرس IP منحصر به فرد را پوشش می دهد. اگرچه که برخی از این یافته ها از سایرین شامل اطلاعات بیشتر و مفیدتری بودند اما در مجموع بسیاری از آن ها اطلاعاتی شامل سیستم عامل، نام کتابخانه UPnP و حتی در بیشتر موارد نسخه مربوط به این کتابخانه را  باز می گرداند. رشته ی عمومی مربوط به هدر سرویس دهنده های SSDP در پاسخ به صورت زیر نمایش داده می شود:

علاوه بر هدر سرویس دهنده،  هدر location که در پاسخ SSDP بازگردانده می شود شامل سه نوع اطلاعات کلیدی می باشد. آدرس IP نمایش داده شده در این URL می بایست با آدرس IP داخلی روتر مکاتبه کند که اغلب این اتفاق صورت نمی گیرد. شماره پورت و مسیر deivce descriptor نیز می بایست به عنوان روش اضافی جهت شناسایی یک دستگاه خاص استفاده شود.

اسکن تکمیلی که در دسامبر ۲۰۱۲ صورت گرفت با این هدف بود که مشخص کند چه تعداد از دستگاه های UPnP-فعال در اینترنت در معرض خطر استفاده از واسط  SOAP قرار دارند.

علاوه بر آن در این اسکن فروشنده ها و محصولاتی که device descriptor را به صورت صفحه XML باز می گرداندند؛ مشخص شد. برای انجام این اسکن، از ۲.۲ میلیون سیستمی که پاسخ UPnP داده بودند و زیرشبکه آن ها کلاس C (/24) subnet بود تعداد ۱۵۰,۰۰۰ تا به صورت تصادفی انتخاب شدند. این ۱۵۰,۰۰۰ زیرشبکه شامل فضای جستجویی روی ۳۸.۴ میلیون آدرس IP می شد و تمام آن ها را از نظر نمایش نقطه پایانی UPnP SOAP مورد بررسی قرار دادیم که در نهایت تعداد بیش از یک میلیون دستگاه با این ویژگی شناسایی شد. از نسبت یافته ها در میان ۲.۲ میلیون زیر شبکه می توان با تخمین خوبی به تعداد دستگاه هایی که در شبکه اینترنت نقطه پایانی UPnP SOAP را در معرض نمایش گذاشته اند، رسید. نتیجه این تخمین برابر با ۱۷.۲۵ میلیون آدرس IP می باشد.

جهت مشخص کردن تعداد سیستم هایی که IP آن ها تغییر کرده است، دیتابیس شناسایی SSDP به صورت ماهانه فضای ورودی ها را مورد تحلیل قرار داده و IPهایی را که در ماه های مختلف استفاده شده اند را به عنوان IPهایی که تغییر کرده اند شناسایی و آن ها را کنار می گذارد.

بیش از ۶۵ میلیون آدرس IP منحصر به فرد در کمتر از یک ماه دارای مشخصات سرویس دهنده UPnP یکسانی در پاسخ بودند. با توجه به داشتن این نرخ بالا از یافته ها مقادیر وابسته از آمار در این بخش بیش از موارد قطعی و مستقل حائز اهمیت است.

 

---

توزیع داده ها

چارت زیر بیانگر توزیع ۹۳ میلیون مورد شناسایی شده ی یکتا با SDKها و کتابخانه های UPnP شناخته‌شده، است.یافته کلیدی این است که تعداد نسبتا کمی از کتابخانه ها، بخش زیادی از پیاده سازی UPnP را در معرض نمایش قرار می دهند.

فروشنده هایی که در نمودار Unkown SDK 1 علامت گذاری شده اند دستگاه های آن ها از شرکت های D-Link, TP-Link و سایر فروشنده ها تهیه شده بود. این قسمت به خودی خود قابل شناسایی نیست. در این SDK به صورت عمومی از رشته “Custom/1.0 UPnP/1.0 Proc/Ver” استفاده می شد. ویژگی رایج در این SDK این بود که همگی  از یک listener از نوع HTTP در پورت TCP 5431 استفاده می کردند. توجه: این قسمت از متن در مقاله‌ی اصلی نیست و من می‌خواستم بدونم که چه کسایی تا اینجای مقاله رو خوندند. لطفا اگر الان دارید این جمله رو می‌خونید به من یک ایمیل بزنید و بگین که ما کل مقاله رو خوندیم. امیدوارم حداقل یک نفر پیدا شه که ایمیل بزنه.

فروشنده هایی که در نمودار Unkown SDK 2 علامت گذاری شده، به وسیله ترکیبی از فروشنده های دستگاه های شبکه کوچکتر مورد استفاده قرار می گرفت و شناسایی آن ها نیز سخت تر بود. در این SDK به صورت عمومی از رشته “System/1.0 UPnP/1.0 IGD/1.0” استفاده می شد. ویژگی مشترک بین آن ها این بود که جهت گوش ایستادن HTTP از پورت TCP 80 استفاده می کردند. شنونده HTTP به صورت کلی از طریق اینترنت به ندرت پاسخگوست که به همین دلیل شناسایی جزییات را برای ما سخت می کرد.

نحوه توزیع نسخه های مختلف Portable SDK برای دستگاه های UPnP

بیش از ۲۵% از موارد شناسایی شده (۲۳.۶ میلیون) جهت پیاده سازی UPnP از Intel SDK بهره گرفته اند. یک نوع از پیاده سازی آن مربوط به Portable SDK در دستگاه های (UPnP (libupnp می باشد. نسخه های استفاده شده در این ۲۳.۶ میلیون مورد به تفکیک در زیر نمایش داده شده است.

بیش از ۱۲ میلیون مورد از موارد شناسایی شده از نسخه Portable SDK 1.3.1 در دستگاه های UPnP استفاده می کردند. این در حالی است که ۵.۵ میلیون دیگر از همان پیاده سازی پیش فرض Inter SDK v1.2 استفاده می کردند.

نحوه توزیع نسخه های مختلف: MiniUPnP

دومین جایگاه بر اساس فراوانی مربوط به کتابخانه MiniUPnP می شود که ۲۱% از کل موارد شناسایی‌شده، از آن استفاده می کنند.

بیش از ۱۳ میلیون مورد شناسایی شده از نسخه MiniUPnP v.10 استفاده می کنند. این خروجی شگفت آور به این دلیل است که تا ژانویه ۲۰۰۸ نرم افزار MiniUPnP تنها دارای نسخه ۱.۰ بود. اگر چه که در آوریل ۲۰۰۸ نسخه ۱.۱ آن عرضه شد اما در پاسخ SSDP اصلاً این نسخه وجود نداشت.

یک توضیح احتمالی این است که بسیاری از از سیستم های شناسایی شده با نسخه ۱.۰ در واقع یک پیش نسخه از آن را اجرا می کنند و به همین دلیل آن را به عنوان نسخه مورد استفاده نشان می دهد. تعدادی از نسخه های آزمایشی نیز بین سال ۲۰۰۵ و ۲۰۰۸ عرضه شد که تمام آن ها در گزارش مربوط به سرویس SSDP و SOAP به عنوان نسخه ۱.۰ شناسایی می شوند. این موضوع توسط توسعه دهندگان MiniUPnP تایید و تصدیق شده است.

---

آسیب پذیری ها

* Interl/ Portable SDK برای دستگاه های (UPnP (libupnp

اکثر پیاده سازی های UPnP شناخته در دستگاه های UPnP بر اساس Intel SDK بوده است. Intel SDK به عنوان یک مرجع پیاده سازی ساخته شد و در حال حاضر به یک پروژه‌ی متن باز تحت عنوان Portable SDK for UPnP device یا libupnp تبدیل شده است.

نکته کلیدی و قابل توجه این است که این «کد» قدیمی است. اولین Intel SDK در سال ۲۰۰۱ عرضه شد و رایج ترین نسخه آن یعنی Portable SDK v1.3.1 در سال ۲۰۰۶ عرضه شد. سومین نسخه رایج آن یعنی ۱.۶.۶نیز بیش از چهار سال است که عرضه شده است. (یعنی یا ۲۰۰۸ یا ۲۰۰۹) سن و سال این کدها و تعداد دستگاه هایی که این ها را در خود نصب کرده اند به خودی خود بیانگر بستری برای رخنه های امنیتی‌ای هسند که در گذشته نیز یافت شده است. پیش از این مقاله تاکنون هیچ CVE مشخص کننده یا OSVDB جهت شناسایی رخنه های امنیتی موجود در نرم افزار libupnp ساخته نشده بود. این را به خاطر داشته باشید که بیش از یک چهارم سیستم هایی که بر اساس libupnp کار می کنند از نسخه ای از SDK بهره می برند که آن ها منسوخ شده است و بیش از نیمی از آن ها از نسخه ای از libupnp استفاده می کنند که حداقل برای شش سال پیش است (مقاله در سال ۲۰۱۳)

* آسیب پذیری پروتکل SSDP یا همان Simple Service Discovery Protocol

در زمان بررسی کدهای اصلی libupnp به ۸ آسیب پذیری رسیدیم. اگرچه تمام این رخنه ها در نسخه های مختلف قابل استفاده نیست اما CVE-2012-5958 و CVE-2012-5959 بیانگر شرایط قابل اکسپلویت پارسر SSDP روی تمام نسخه های Intel SDK و تمام نسخه های پایین تر از  1.6.18 برنامه Portable SDK می باشد.

در نسخه ۱.۳.۱ از Portable SDK در دستگاه های UPnP، کد پارسر SSDP در آدرس upnp/src/ssdp/ssdp_serve.c وجود دارد. تابع unique_service_name() /*function وظیفه پارس درخواست های SSDP وارد شونده و پرکردن فیلدهای ساختار جهت نمایش و ارائه یک رخداد را دارد. در قطعه کد زیر رخنه های امنیتی برنامه کاملا قابل رویت است و آن را با رنگ زرد برجسته کرده ایم. توجه داشته باشید که متغیر cmd به رشته ای اشاره دارد که پایان آن از راه دور و خارج از کد مشخص می شود. ساختار Evt -که مخفف event یا همان رخداد است- شامل یک بافر رشته ای با طول مشخص شده و ثابت بوده و به وسیله فراخوانی تابع در پشته ذخیره می شود.

حداقل در ۷ جای مختلف در نسخه ۱.۳.۱ از این کد، سر ریز بافر رخ داده است که تمام این موارد می توانند باعث ایجاد اخلال در پشته شوند. همچنین به صورت بالقوه پتانسیل اجرای کدهای بدخواهانه را فراهم می کنند. در بیشتر موارد برنامه هایی که به کتابخانه libupnp لینک می شوند در سطح دسترسی و کاربرای root ایجاد می شوند و این در حالی است که اقداماتی که به وسیله SOAP API اجرا می شوند نیز به آن (root) احتیاج دارند. (مثل مدیریت قوانین مربوط به فایروال و…)

در زیر آخرین نسخه منتشر شده از libupnp در زمان نوشتن این مقاله یعنی نسخه ۱.۶.۱۷ را مشاهده می کنیم:

همان طور که می بینیم کد به صورت کامل بازنویسی شده است اما هنوز در سه قسمت و دقیقا در همان جاهای قبلی، از سر ریز بافر رنج می برد. تابع ()strncpy بر اساس اندازه ی فاصله بین دو رشته در درخواستی که نفوذگر آن را ارائه داده است، آن طول را بدون اینکه با سایز بافر مقصد مقایسه و چک کند؛ عبور می دهد.

CVE-2012-5958 با درخواستی شبیه زیر به وقوع می پیوندد:

M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:uuid:schemas:device:AAAA[…]AAAA: anything
Man:”ssdp:discover”
MX:3

قابلیت اکسپلویت:

دلیل و چیزی که باعث مخرب بودن این آسیب پذیری می شود، محتوایی است که در این کُد فراخوانی می شود. نفوذگر می تواند به صورت مستقل و مستقیم بسته های استراق سمع شده UDP را به آدرس IP داخلی سیستمی که این کد روی آن در حال اجراست، ارسال کرده و باعث اخلال در پشته برنامه شود. این کتابخانه ورودی ها را به حدود ۲,۵۰۰ بایت محدود کرده که البته این فضا برای بدافزارها و کدهای مخرب بیش از اندازه مورد نیاز هم هست.

در ادامه هشداری را مشاهده می کنیم. پارسر مربوط به HTTP در صورتی که شرایط مشخص شده برقرار نشده باشد درخواست را نادیده می گیرد. رشته ای که توسط نفوذگر برای هدر “ST” ارسال می شود؛ باید جهت جلوگیری از بازگرداندن خطا کد مربوط به ()scanner_get_token موجود در httpparser.c را توسط تابع ()unique_service_name اجرا کند و کار این تابع پردازش هدر “ST” است. این تابع بر حسب شرایط رفتار متفاوتی را از خود ارائه می دهد.

1. بایت های بین 0x20 و 0x7e به صورت کلی پذیرفته می شوند.
2. بایت های بالاتر از 0x7e باید درون کوتیشن ” قرار گیرد.
3. بایت های 0x20 یا دقیقاً 0x7f نباید در درون کوتیشن قرار گیرد.

این شرایط، اکسپلویت را دشوار می‌نماید؛ به خصوص در پلتفرم های غیر از X86 که طول دستورالعمل ها را درست و گزینه‌های کدینگ را محدود کرده اند از قبیل ARM,MIPS,PPC. استفاده از  تکنیک دستکاری بیت های رزرو شده ممکن است جهت بهبود طول دستورالعمل های پلتفرم یاری رسان باشد.

در تمام پلتفرم های لینوکس جدید مواردی چون تصادفی کردن لایه فضای آدرس [ASLR]، عدم اجرای بیت ها در یک صفحه مشخص و بایت های NULL در آدرس تصاویر باعث پیچیده تر شدن اکسپلویت می شود. قابل تذکر است کُد زیر به عنوان بایت NULL شناخته شده و به معنی دستور “پایان” در عملیات کپی رشته در TempBuf است:

اما با توجه به نوع کامپایلر، مقدار محلی متغیر “n” ممکن است توسط تابع ()strncpy رونویسی شود. این مورد به نفوذگر اجاره می دهد که کاراکتر پایانی را در هرجایی که اراده کند، قرار دهد. این مورد در پلتفرم های MIPS از نوع little-endian برخلاف روترهای خانگی بر اساس لینوکس های تجاری قابل استفاده بوده و این امکان را فراهم می کند که آدرس باینری میزبانی که در حال استفاده است را بازگرداند. حتی در برخی موارد می توان بایت NULL را در آدرس قرار داد.

علاوه بر آن تکنیک رونویسی بخشی ممکن است در پلتفرم little-endian قابل استفاده باشد اما انجام چنین کاری از کنترل پشته ای که جهت تکنیک ROP یا همان return-oriented programming به معنای (برنامه نویسی بازگشت گرا)  مورد نیاز است، جلوگیری می کند. در نهایت در برخی از پلتفرم ها ممکن است بتوان به سادگی آدرس heap مربوط به درخواست را پیش بینی کرد و سپس آن را در داده هایی که توسط پارسر HTTP پردازش نمی شود، باز گرداند.

MiniUPnP

جایگاه  دوم در پیاده سازی UPnP مربوط به MiniUPnP است. یک پیاده سازی کامل برای UPnP که نه تنها پردازش شبکه را مدیریت می کند بلکه می تواند قوانین فایروال و سایر سرویس های SOAP را نیز مدیریت کند.

آسیب پذیری مربوط به SDDP

در خصوص هندلر SSDP از MiniUPnP دو مورد مرتبط با هم شناسایی شده است. که البته این موارد در نسخه ۱.۴ اصلاح شده است اما هنوز به عنوان یک مشکل امنیتی مستند نشده است. CVE-2013-0229 در این خصوص است.

در سورس کد MiniUPnP v1.0 کد مربوط به پارسر SSDP که در فایل minissdp.c وجود دارد توسط تابع ()ProcessSSDPRequest و به شکل زیر پیاده سازی شده است:

کد موجود در این قسمت به گونه ای طراحی شده است که بسته هایی با طول بالاتر از ۱۵۰۰ بایت را دریافت کرده و آن را به صورت خط به خط تا زمانی که به پیش وند “:ST” برسد پویش کند. مشکل از دو مورد زیر نشأت می گیرد:

1. مورد اول که مهم و برجسته هم هست این است که حلقه while زمانی که بافر به پایان می رسد را چک نمی کند. اگر درخواست بدون وجود عبارت \r\n به پایان برسد، حلقه عمل خواندن را حتی بعد از اتمام رسیدن محل بافر ادامه می دهد. سرانجام یا به یک r\n\ جعلی و غیر حقیقی می رسد یا زمانی که ظرفیت پشته تکمیل می شود، دچار فروپاشی سیستم یا همان crash می شود.
2. دومین و سومین مورد مبهم زمانی است که حلقه ها دچار مشکلی مشابه زمانی که آن ها در یافتن نقطه و مرز پایانی بافر شکست می خورند، می شوند. حلقه ی اول که بعید است دچار مشکل شود اما حلقه دوم تا زمان یافتن r\ یا n\ با افزایش طول رشته بافر کار ادامه خواهد یافت.

زمانی که مورد اول به وقوع بپیوندد ظاهراً دیمون مربوطه از کار افتاده و نتیجه آن DOS خواهد بود. در خصوص مورد دوم می توان از ساخت رشته ای طولانی و مضحک “ST” و با هدف رسیدن و گذشتن از مرز پایانی بافر استفاده کرد. اما در دنیای حقیقی این یک موضوع قابل توجه نیست، چراکه هنگامی که رشته “ST” در درون ()snprintf قرار می گیرد، این تابع ورودی ها را به بافری با سایز ۵۱۲ بایت محدود می کند.

بنابراین تأثیر واقعی این دو مورد به عنوان تهدیدی بالقوه جهت حملات DOS مورد نظر قرار گرفته می شود. مثال زیر نمونه ای از فروپاشی سیستم در سرویس SSDP با نسخه ۱.۰ موجود در MiniUPnP v1.0 می باشد.

M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:uuid:schemas:device:MX:3< no CRLF >

آسیب پذیری هندلر SOAP

سرریز بافر پشته از راه دور، در هندلر SOAPAction از سرویس HTTP موجود در MiniUPnP v.10 شناسایی شد. تمام نسخه های بعد از MiniUPnP v1.0 در برابر این آسیب پذیری مقاوم هستند اما این موضوع را به خاطر داشته باشید که ۶۷% از سیستم های شناسایی شده که MiniUPnP در آن ها در حال اجراست هنوز از نسخه های آسیب پذیر آن استفاده می کنند. CVE-2013-0230 در این خصوص است.

کد زیر مربوط به ()ProcessHTTPPOST_upnphttp در upnphttp.c است:

 متد ExecuteSoapAction از قطعه کد زیر تشکیل شده است:

1. اولین مورد مربوط به هدر SOAPAction در جایی است که از علامت هش (#) و کوتیشن استفاده شده است. اگر هش فراموش شود می تواند نتیجه اش در خواندن  اشاره گر NULL باشد و نتیجه آن از کار افتادن سرویس است. اگر کوتیشن فراموش شود می تواند نتیجه اش مقداری منفی برای methodlen (طول متد) باشد که در این صورت ()strchr مقدار NULL را بازخواهد گرداند.
2. ()memcpy ممکن است از دو طریق مختلف دچار خرابی شود:

• اولین مورد زمانی است که کوتیشن در هدر SOAPAction فراموش شود. این مورد باعث می شود که ()memcpy طول منفی ای را عبور داده و در صورت تبدیل آن به unsigned int، تبدیل به یک مقدار مثبت بسیار بزرگ خواهد شد. اکسپلویت بر اساس این سناریو بسیار دشوار است مگر اینکه اشاره گر هندلر سیگنال، در حافظه مجاور اشاره گر مقصد ذخیره شود.
• رویکرد در این قسمت به این صورت است که طول را بیش از ۲۰۴۸ بایت قرار می دهند. این مورد باعث سرریز بافر پشته به روش قدیمی می شود که تنها چند کاراکتر را ممنوع می کند و در عوض تعداد داده های تقریبا نامحدودی را می توان برای کار با آن داشت.

پاسخ فروشنده

Thomas Bernard از پروژه MiniUPnP به خاطر یافته های گروه با ما تماس گرفت و بازخورد خوبی را از چرک نویس های قبلی این مقاله گرفت. [به طوری که] دو مورد ذکر شده در بالا به ترتیب در سال ۲۰۰۹ و ۲۰۰۸ اصلاح شد. علاوه بر موارد بالا چند مورد مهم‌تر نیز شناسایی و گزارش شده است. این مقاله زمانی که برای MiniUPnP وصله یا همان patch ارائه کنند به روز خواهد شد.

[!!یعنی چی؟ یعنی اینکه به ادعای نویسنده هنوز یه سری آسیب پذیری وجود داره که واسه ی اونا هنوز وصله نیومده!!]

پیوست:

دانلود مقاله Security Flaw in Universal Plug and Play از گروه امنیتی Rapid 7 به زبان اصلی در قالب PDF

مترجم: تمدن