امروز: شنبه، 31 شهریور 1397

سامانه‌های تک‌ورودی در بخش کنترل دسترسی خود دارای یک ویژگی هستند که یک کاربر با وارد کردن یک باره‌ی نام کاربری و گذرواژه‌ی خود می‌تواند به شبکه‌ای از سامانه‌ها دسترسی داشته باشد. یک رفتار متعارف در کتابخانه‌های مبتنی بر زبان نشانه‌گذاریِ اعلان امنیتی (SAML) باعث شده چندین آسیب‌پذیری در پیاده‌سازی سامانه‌های تک‌ورودی بوجود بیاید.


 

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

 

پژوهش‌گران اعلام کردند در پیاده‌سازی‌های مختلف از SAML این آسیب‌پذیری دارای شناسه‌های مختلف بوده که در ادامه این شناسه‌ها اعلام شده است.

پیاده‌سازی پایتون در برنامه‌ی OneLogin با شناسه‌ی CVE-۲۰۱۷-۱۱۴۲۷

پیاده‌سازی روبی در برنامه‌ی OneLogin با شناسه‌ی CVE-۲۰۱۷-۱۱۴۲۸

پیاده‌سازی js در برنامه‌ی Clever با شناسه‌ی CVE-۲۰۱۷-۱۱۴۲۹

برنامه‌ی OmniAuth-SAML با شناسه‌ی CVE-۲۰۱۷-۱۱۴۳۰

برنامه‌ی Shibboleth با شناسه‌ی CVE-۲۰۱۸-۰۴۸۹

برنامه‌ی Duo Network Gateway با شناسه‌ی CVE-۲۰۱۸-۷۳۴۰

 

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

در پاسخ احراز هویت SAML دو مولفه‌ی بسیار مهم وجود دارد: اعلان و امضاء. مولفه‌ی اعلان بیان می‌کند که این کاربر با این NameID احراز هویت شده است. مولفه‌ی امضاء نیز این اطمینان را می‌دهد که NameID که احراز هویت شده، هنگام انتقال از ارائه‌دهنده‌ی شناسه و سوریس شخص ثالث، دست‌کاری نشده و تغییر داده نشود. اگر مهاجم بتواند NameID را تغییر دهد و هیچ امضایی برای بررسی صحت آن وجود نداشته باشد، این نتیجه‌ی مخربی به دنبال خواهد داشت.

دلیل وجود این آسیب‌پذیری، برخی از رفتارهای غیرقابل‌ پیش‌بینی در کتابخانه‌های XML مانند lxml در پایتون و یا REXML در روبی است. نظرات نیز می‌توانند در بخش امضاء گنجانده شوند اما فرآیند کانونیزاسیون در کتابخانه‌های SAML تمایل دارد تا تمامی متن بعد از دریافت یک رشته‌ی مشخص را حذف کند تا مقدار NameID مشخص شود.

 

پژوهش‌گران در ادامه با یک مثال توضیح می‌دهند که یک مهاجم با دسترسی به حساب کاربری مانند user@user.com.evil.com می‌تواند NameID را به user@user.com تغییر دهد. مهاجم ۷ نویسه‌ی <!----> را قبل از عبارت .evil.com قرار می‌دهد. این مسأله باعث می‌شود تا فرآیند کانونیزاسیون در این کتابخانه، بخش .evil.com را نادیده گرفته و حساب کاربری که احراز هویت می‌شود و مجوز دریافت می‌کند، user@user.com خواهد بود.

تمامی پیاده‌سازی‌های سامانه‌ی تک‌ورودی تحت تاثیر این آسیب‌پذیری قرار نگرفته‌اند ولی اکثریت این مشکل را دارند. تمامی چیزی که یک مهاجم به آن نیاز دارد یک حساب واقعی است که با استفاده از آن بتواند نام کاربری را به صورت نام کاربریِ هدف خود قرار دهد و کمی دانش فنی تا پاسخ‌های SAML را دریافت و ویرایش کرده و از طریق مرورگر ارسال کند.

 

برای کاهش خطرات این آسیب‌پذیری هرکدام از بخش‌ها باید راه‌کار متناسب با خود را ارائه دهد از ارائه‌دهندگان شناسه گرفته تا پیاده‌سازی‌های SAML و کتابخانه‌های XML. پژوهش‌گران امنیتی اشاره کرده‌اند آنچه‌ که می‌تواند این مشکل را به‌طور پایه‌ای حل کند این است که باید احراز هویت چندمرحله‌ای وجود داشته باشد. نکته‌ای که وجود دارد این است که حتی اگر احراز هویت دومرحله‌ای هم وجود داشته باشد و ارائه‌دهنده‌ی شما عملیات احراز هویت مرحله‌ی ۲ را انجام دهد، باز هم مهاجم خواهد توانست آن را دور بزند و به‌عبارت دیگر این احراز هویت چندگانه باید در مکان‌های مختلفی انجام شود.


منبع: news.asis.io