دانشمندان علوم کامپیوتر دانشگاه MIT، اولین پژوهشگرانی بودند که از واژه Kerberos (یکی از قهرمان اساطیر یونانی) برای نام‌گذاری یک پروتکل احراز هویتی استفاده کردند که درون شبکه‌های کامپیوتری استفاده می‌شود. کربروس (Kerberos) یک پروتکل تحت شبکه است که در سطحی گسترده برای حل مشکل احراز هویت استفاده می‌شود. کربروس از رمزنگاری کلید متقارن و یک مرکز توزیع کلید KDC سرنام Key Distribution Center استفاده می‌کند و برای تایید هویت کاربر به مجوز ثالث مورد اعتماد نیاز دارد. کربروس به ۳ عنصر مجزا برای احراز هویت نیاز دارد و از یک سیستم رهگیری و نظارتی قدرتمند برای امن‌تر نگه داشتن محاسبات استفاده می‌کند.
کربروس چیست؟
احراز هویت کربروس در حال حاضر فناوری احراز هویت پیش‌فرض ویندوز مایکروسافت است، اما پیاده‌سازی کربروس در یونیکس، لینوکس Apple OS و FreeBSD امکان‌پذیر است. مایکروسافت نسخه کربروس خود را همراه با ویندوز ۲۰۰۰ معرفی کرد. همچنین این فناوری به یک استاندارد برای وبسایت‌ها و احراز هویت شناسایی یگانه (Single Sign-On) در پلتفرم‌های مختلف تبدیل شده است. لازم به توضیح است که کنسرسیوم کربروس این فناوری را به عنوان یک پروژه منبع‌باز نگه‌داری می‌کند. کربروس به نسبت فناوری‌های احراز هویت قبل از خود پیشرفت چشم‌گیری داشته است. رمزنگاری قدرتمند و توکن احراز هویت ثالث باعث می‌شوند تا نفوذ به شبکه توسط مجرمان سایبری با دشواری زیادی همراه باشد. این فناوری همانند سایر نمونه‌های مشابه در بخش‌هایی آسیب‌پذیر است که اگر درباره این آسیب‌پذیرها اطلاع کافی داشته باشید، دفاع در برابر هکرها امکان‌پذیر می‌شود. کربروس اینترنت را به محیطی امن‌تر تبدیل کرد و این امکان را برای کاربران فراهم کرد تا فارغ از نگران‌های امنیتی و بدون نگرانی از بابت مشکلات امنیتی در دفتر کار خود با اینترنت کار کنند.
چه تفاوتی بین کربروس و NTLM وجود دارد؟
قبل از کربروس مایکروسافت از یک فناوری احراز هویت به‌نام NTLM (NT Lan Manager ) استفاده می‌کرد که یک پروتکل احراز هویت چالش-پاسخ بود. کامپیوتر یا کنترل‌کننده دامنه گذرواژه‌ها را بررسی و هش گذرواژه را برای استفاده مداوم ذخیره می‌کرد. بزرگ‌ترین تفاوت این دو سیستم در احراز هویت ثالث و توانایی رمزنگاری قدرتمندتر کربروس است. کربروس در مقایسه با NTLM از یک لایه امنیتی اضافی در فرآیند احراز هویت استفاده می‌کند. این روزها سیستم‌های مبتنی بر NTLM را می‌توان در عرض چند ساعت هک کرد. به بیان ساده NTLM یک فناوری قدیمی و به تعبیری منسوخ شده است که نباید برای محافظت از داده‌های حساس از آن استفاده کرد.
کربروس چگونه فرآیند احراز هویت را انجام می‌دهد؟
اجازه دهید با ذکر مثالی این فرآیند را شرح دهیم. آلیس به عنوان کلاینت می‌خواهد یک ارتباط امن با سرور برقرار کند. هر دو سمت کلاینت و سرور قرار است از پروتکل Kerberos برای اطمینان از صحت هویت خود استفاده کنند.
همان‌گونه که اشاره شد Kerberos از رمزنگاری کلید متقارن استفاده می‌کند که در آن یک کلید واحد برای رمزگذاری و آشکارسازی رمز استفاده می‌شود. در مثال ما سرور باید تایید کند پیغامی که از طرف آلیس ارسال شده واقعا از طرف خود آلیس ارسال شده است. برای این‌کار کلاینت و سرور تصمیم می‌گیرند از اطلاعات یک کلید امنیتی برای تایید هویت طرف مقابل استفاده کنند. آلیس یک پیغام به سرور ارسال می‌کند.
کلاینت یک پیغام که شامل نام کلاینت به صورت متن ساده و یک تایید کننده که با استفاده از یک کلید امنیتی کدگذاری شده است را ارسال می‌کند. این پیغام تایید یک ساختار داده‌ای متشکل از دو فیلد دارد. فیلد اول نام کلاینت و فیلد دوم زمان ایستگاه کاری کلاینت است.
بعد از دریافت پیغام، سرور با رمزگشایی ساختار داده‌ای تاییدکننده به وسیله همان کلید امنیتی، اطلاعات موردنیاز درباره کلاینت را استخراج می‌کند. در ادامه سرور مهر زمانی را با زمان خودش بررسی می‌کند. اگر تفاوت در حد قابل قبول است، سرور متوجه می‌شود که پیغام احتمالا از طرف آلیس ارسال شده است. در مواردی که اختلاف زمانی وجود دارد، سرور به‌طور خودکار پیغام را رد می‌کند. تاییدکننده کاربرد دیگری نیز دارد که اجازه نمی‌دهد یک حمله بازپخشی انجام شود. حملات بازپخشی زمانی رخ می‌دهند که یک حمله‌کننده در میانه ارتباط پیغام را به سرقت می‌برد و با معرفی خود به عنوان کاربر اصلی پیغام را دومرتبه برای سرور ارسال می‌کند. برای اینکه آلیس متوجه شود که سرور پیغام او را دریافت کرده، سرور مهر زمانی آلیس را با کلید امنیتی رمزگذاری کرده و آن‌را برای کلاینت باز می‌گرداند. از آن‌جایی که سرور به جای تمام اطلاعات موجود در تایید کننده کلاینت تنها مهر زمانی را ارسال می‌کند، کلاینت می‌تواند تایید کند فرد دیگری غیر از سرور پیغام او را دریافت نکرده، زیرا تنها سرور است که می‌تواند اطلاعات مهر زمانی را رمزگشایی و استخراج کند.
چگونه کلاینت و سرور کلید امنیتی یکسان را به‌اشتراک می‌گذارند، کلاینت ممکن است بخواهد با چند سرور ارتباط برقرار کند و برای هر سرور به یک کلید نیاز دارد، سرور نیز ممکن است مجبور شود به چند کلاینت متصل شود و برای هر کلاینت به یک کلید احتیاج دارد، برای این مشکلات چه راهکاری وجود دارد؟ ذخیره‌سازی و ایمن‌سازی چند کلید در بسیاری از سیستم‌ها دشوار است. مرکز توزیع کلید (KDC ) به عنوان یک میانجی قابل اعتماد، راهکاری از طرف پروتکل کربروس برای رفع این مشکلات است. KDC از یک پایگاه داده نگه‌داری می‌کند که شامل اطلاعات حساب تمام طرفین تحت نظارت این سیستم است که کلید رمزنگاری که به صورت پنهان بین KDC و طرفین تحت نظارت حفظ می‌شود از جمله این اطلاعات است. کلید فوق، یک کلید طولانی مدت است که اعتبار زمانی آن بالا است و در ارتباطات بین KDC و طرفین تحت نظارت استفاده می‌شود.
همان‌گونه که در شکل ۳ مشاهده می‌کنید اگر یک کلاینت بخواهد با سرور ارتباط برقرار کند یک درخواست به KDC ارسال می‌کند. KDC یک کلید نشست (session key) را برای هر دو سمت سرور و کلاینت به شکل رمزگذاری شده توزیع می‌کند.
بعد از اینکه کلاینت این کلید نشست را دریافت کرد ممکن است یک پیغام را در همان لحظه یا بعد از گذشت مدت زمانی به سرور ارسال کند. در چنین شرایطی باید به دو وضعیت مهم رسیدگی شود. اگر کلاینت تصمیم بگیرد بعدا این ارتباط را برقرار کند، سرور باید کلید نشستی که از KDC دریافت کرده را به عنوان نتیجه درخواست کلاینت ذخیره کند. از طرف دیگر به دلیل ترافیک شبکه، سرور ممکن است این کلید نشست را قبل از رسیدن پیغام کلاینت از KDC دریافت نکند. برای جلوگیری از چنین وضعیتی، به جای ارسال کلید نشست به سرور، KDC یک کپی از این کلید را به شکل بلیط نشست (Session Ticket) به کلاینت ارسال می‌کند.
در پاسخ به درخواست کلاینت، KDC هر دو کپی از کلید نشست را به خود کلاینت بازمی‌گرداند. کپی کلاینت با کلید طولانی مدت کلاینت کدگذاری شده در حالی که کلید نشست سرور به شکل یک ساختار داده که Session Ticket نام دارد ارسال می‌شود. حالا کلاینت است که مدیریت این بلیط نشست را مادامی‌که به سرور برسد برعهده می‌گیرد. در چنین شرایطی اگر پیغام ارسال شده از طرف KDC به مقصد اشتباه ارسال شود مشکل خاصی رخ نمی‌دهد، زیرا کپی کلید نشست کلاینت تنها می‌تواند توسط کسی دریافت شود که از کلید امنیتی کلاینت آگاه است و کپی کلید نشست سرور نیز تنها توسط کسی قابل بازگشایی است که از کلید امنیتی سرور با خبر است. بعد از دریافت پاسخ از طرف KDC، کلاینت هر زمان بخواهد با سرور ارتباط برقرار کند یک پیغام را برای آن ارسال می‌کند.
در این فرآیند احراز هویت متقابل، کلاینت پیغامی را ارسال می‌کند که شامل تاییدکننده رمزگذاری شده با کلید نشست از طرف KDC و بلیط نشست است. حالا این بلیط نشست و تایید کننده با هم مدارک هویتی کلاینت را تشکیل می‌دهند. وقتی سرور این پیغام را دریافت کرد، با استفاده از کلید امنیتی (کلید طولانی مدت سرور) که بین سرور و KDC به‌اشتراک گذاشته شده بلیط نشست را رمزگشایی کرده و در ادامه کلید نشست را استخراج می‌کند تا با استفاده از آن تایید کننده را رمزگشایی کند.
هنوز یک نقل و انتقال مهم دیگر در این پروتکل باقی مانده است. کلید نشست کلاینت ارسال شده از طرف KDC به کلاینت با استفاده از یک کلید طولانی مدت کلاینت رمزگذاری شده است. کلید طولانی مدت کلاینت از مدارک هویتی دریافت شده که با استفاده از یک تابع هش یک طرفه برای وارد شدن به ایستگاه کاری آلیس استفاده می‌شود. به عبارت دیگر، KDC کپی کلید طولانی مدت آلیس را از رکورد کد حساب او در پایگاه داده استخراج می‌کند. برای بهبود ایمنی این کلید طولانی مدت با کلید نشست جایگزین خواهد شد. بعد از تولید یک کلید بلند مدت وقتی آلیس به ایستگاه کاری خود وارد می‌شود، یک درخواست به KDC برای کلید نشستی که برای استفاده بین کلاینت و KDC نیاز است ارسال می‌کند. به محض اینکه KDC درخواست آلیس را دریافت کرد، کلید بلند مدت آلیس را از پایگاه داده خود استخراج می‌کند و با یک بلیط نشست به‌نام (TGT) سرنام Ticket Granting Ticket پاسخ را به کلاینت باز می‌گرداند. TGT کلید نشستی است که برای استفاده KDC در زمان برقراری ارتباط با آلیس در نظر گرفته شده است. پیغام پاسخ علاوه بر TGT شامل کلید نشست برای کلاینت در زمان برقراری ارتباط با KDC است. این TGT با کلید طولانی مدت KDC رمزگذاری شده و کلید نشست کلاینت با کلید طولانی مدت کلاینت رمزگذاری شده است. حالا کلاینت باید بلیط نشست را از KDC بگیرید تا بتواند یک سرویس را از سرور درخواست کند. کلاینت یک پیغام را ارسال می‌کند که شامل TGT و تایید کننده‌ای است که با استفاده از کلید نشست به‌اشتراک گذاشته شده بین کلاینت و KDC کدگذاری شده است. برای به‌کارگیری KDC به دو بخش خدمات احراز هویت (Authentication Service) و خدمات صدور بلیط تقسیم‌بندی (Ticket-granting Service) نیاز است. به محض اینکه KDC پیغام کلاینت را دریافت کرد سرویس صدور بلیط درخواست را تایید کرده و بلیط نشست و کلید نشست را ارسال می‌کند.
کربروس هک‌پذیر است؟
بله. زیرا یکی از متداول‌ترین پروتکل‌های احراز هویت است و هکرها هم چند راه برای نفوذ به آن ابداع کرده‌اند. اغلب این هک‌ها بر مبنای آسیب‌پذیری‌ها، گذرواژه‌های ضعیف یا بدافزارها (یا برخی اوقات هر سه مورد) انجام می‌شوند. کربروس به روش‌های زیر هک می‌شود:
- رد کردن بلیط: فرآیندی که در آن یک کلید نشست جعل می‌شود و این کلید جعلی به عنوان یک مدرک هویتی معتبر در اختیار منبع قرار می‌گیرد.
- بلیط طلایی: یک بلیط که برای دسترسی مدیریتی برای کاربر صادر می‌شود.
- بلیط نقره‌ای: یک بلیط جعلی که برای دسترسی به یک سرویس صادر می‌شود.
- Credential stuffing/ Brute force: تلاش‌های خودکار پی در پی برای حدس زدن یک گذرواژه
- خنثا کردن رمزگذاری با Skeleton Key Malware: یک بدافزار که می‌تواند کربروس را دور بزند، اما حمله باید از طریق دسترسی مدیریتی انجام شود.
- حمله DCShadow: یک حمله جدید در مکانی که حمله‌کنندگان دسترسی کافی به شبکه دارند تا بتوانند از کنترل‌کننده دامنه اختصاصی خود برای نفوذ بیشتر استفاده کنند.
کربروس منسوخ خواهد شد؟
کربروس تا منسوخ شدن فاصله زیادی دارد و با وجودی که هکرها توانایی نفوذ به آن‌را دارند ثابت کرده که یک پروتکل کنترل دسترسی امنیتی قابل قبول است. اصلی‌ترین مزیت کربروس توانایی استفاده از الگوریتم‌های رمزنگاری قوی برای محافظت از گذرواژه‌ها و بلیط‌های احراز هویت است. با کامپیوترهای امروزی هر نوع حمله جست‌جوی فراگیر (Brute Force) به پروتکل رمزنگاری AES که کربروس از آن استفاده می‌کند و درهم شکستن آن به زمانی معادل با طول عمر خورشید نیاز دارد. بدون شک کربروس به هر شکلی که ارائه شود تا مدت زمان نسبتا طولانی قابل استفاده است.
منبع:شبکه-مگ
