روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛  پیشتر تکنیک‌های تست نفوذ بر روی مِین‌فریم‌های IBM z/OS که با بسته امنیتی Resource Access Control Facility (ما در ادامه این مقاله به اختصار آن را RACF صدا خواهیم زد) محافظت می‌شوند را بررسی کردیم. در بخش دوم این پژوهش، به بررسی عمیق‌تر RACF می‌پردازیم؛ با تمرکز بر منطق تصمیم‌گیری، ساختار پایگاه داده و تعامل میان موجودیت‌های مختلف در این زیرسیستم. با ما همراه باشید.

برای تحلیل آفلاین پایگاه داده RACF، ابزاری به نام racfudit توسعه داده‌ایم که از آن برای انجام بررسی‌های ممکن و ارزیابی امنیت پیکربندی RACF استفاده خواهیم کرد. همچنین، در این مقاله روابط بین موجودیت‌های RACF  (کاربران، منابع و مجموعه‌داده‌ها) را برای شناسایی مسیرهای احتمالی افزایش سطح دسترسی کاربران در z/OS ترسیم می‌کنیم.

نکته: محتوایی که در اختیار دارید صرفاً با هدف آموزشی ارائه شده و برای کمک به متخصصانی که تست‌های نفوذ مجاز انجام می‌دهند طراحی شده است.

معماری داخلی RACF

نقش کلی

برای تحلیل دقیق RACF، ابتدا باید نقش و عملکرد اجزای آن در معماری کلی z/OS را مرور کنیم. RACF معمولاً به دو بخش اصلی شامل یک مؤلفه خدماتی و یک پایگاه داده تقسیم می‌شود. مؤلفه‌های دیگری مانند ابزارهای مدیریتی یا راهکارهای گزارش‌گیری و ممیزی نیز وجود دارند، اما برای درک کلی عملکرد RACF، تمرکز بر پایگاه داده و سرویس کافی است.

پایگاه داده RACF اطلاعات مربوط به کاربران z/OS و منابعی که برای آن‌ها کنترل دسترسی تنظیم شده را نگهداری می‌کند. مؤلفه خدماتی RACF با استفاده از این داده‌ها، بررسی‌های امنیتی لازم را هنگام درخواست سایر مؤلفه‌ها و زیرسیستم‌های z/OS انجام می‌دهد. این تعامل معمولاً از طریق رابط System Authorization Facility (به اختصار SAF)انجام می‌شود. هر مؤلفه‌ای در z/OS که بخواهد دسترسی کاربر را بررسی کند، از SAF استفاده می‌کند تا درخواست را به RACF ارسال کند. اگرچه تمرکز این متن بر RACF است، اما بسته‌های امنیتی دیگری مانند ACF2 و Top Secret نیز برای z/OS وجود دارند.

برای مثال، در زیرسیستم TSO که مشابه خط فرمان در z/OS است، هنگام ورود کاربر با شبیه‌ساز ترمینال x3270، پس از احراز هویت موفق، TSO از طریق SAF از RACF می‌پرسد آیا کاربر مجاز به دسترسی به این زیرسیستم هست یا خیر. RACF اطلاعات کاربر را از پروفایل مربوطه در پایگاه داده می‌خواند. اگر مجوز دسترسی لازم وجود داشته باشد، آن اطلاعات در بلوک کنترل ACEE در فضای آدرس نشست TSO قرار می‌گیرد. در ادامه، هر درخواست دسترسی جدید در همان نشست نیز با استفاده از داده‌های ACEE بررسی می‌شود. SAF این اطلاعات را به RACF ارسال کرده و RACF با توجه به پروفایل مربوط به منبع، تصمیم به اجازه یا رد دسترسی می‌گیرد. این فرآیند برای هر درخواست جدید در همان نشست تکرار می‌شود. بنابراین، RACF  مسئول شناسایی، احراز هویت، و مجوزدهی کاربران و همچنین مدیریت سطح دسترسی در z/OS است.

اجزای پایگاه داده RACF

تصمیم‌گیری‌های مربوط به دسترسی در z/OS بر اساس اطلاعات موجود در پایگاه داده RACF انجام می‌شود. این داده‌ها در قالب رکوردهایی به نام "پروفایل" ذخیره می‌شوند که مشخصات اشیای مختلف در z/OS را در بر دارند. چهار نوع اصلی پروفایل در تحلیل‌های امنیتی اهمیت بیشتری دارند:

• پروفایل کاربری:  شامل اطلاعاتی درباره کاربر مانند نام ورود، هش رمز عبور، ویژگی‌های خاص و عضویت در گروه‌ها
• پروفایل گروهی:  شامل اطلاعات مربوط به گروه، اعضا، مالک، ویژگی‌های خاص، زیرگروه‌ها و مجوزهای دسترسی
• پروفایل مجموعه داده:  شامل جزئیاتی درباره مجموعه‌داده‌ها، مانند مجوزها، ویژگی‌ها و سیاست ممیزی
• پروفایل منابع کلی: شامل اطلاعاتی درباره منابع دیگر، دارندگان منابع، سطح دسترسی، سیاست ممیزی و مالک

پایگاه داده RACF شامل نمونه‌های متعددی از این پروفایل‌هاست که با یکدیگر ساختاری پیچیده از روابط بین اشیاء و کاربران در z/OS ایجاد می‌کنند و مبنای اصلی تصمیم‌گیری در دسترسی به منابع هستند.

ساختار منطقی پروفایل‌های پایگاه داده RACF

هر پروفایل در پایگاه داده RACF از یک یا چند بخش تشکیل شده است. نوع بخش‌ها بسته به نوع پروفایل متفاوت است.

برای مثال، یک نمونه پروفایل کاربر ممکن است شامل بخش‌های زیر باشد:

•          BASE:  اطلاعات اصلی و الزامی کاربر در RACF؛
•          TSO:  پارامترهای نشست کاربر در زیرسیستم TSO؛
•          OMVS:  پارامترهای نشست کاربر در زیرسیستم UNIX در z/OS؛
•          KERB:  داده‌های مرتبط با سرویس احراز هویت شبکه در z/OS، مورد استفاده در پروتکل Kerberos؛
•          و بخش‌های دیگر.

هر بخش اطلاعات خاصی را نگه‌داری می‌کند و در کنار هم، ساختار کامل پروفایل را شکل می‌دهند.

انواع بخش‌ها در پروفایل‌های RACF

هر نوع بخشدر پروفایل‌های RACF با مجموعه‌ای از فیلدها مشخص می‌شود. به عنوان مثال، بخش BASE در پروفایل کاربر شامل فیلدهای زیر است:

• پسورد: هش رمز عبور کاربر
• عبارت:  هش عبارت رمزی (password phrase)
• لاگین:  نام کاربری (شناسه ورود)
• مالک:  مالک پروفایل کاربر
• تاریخ تأیید:  تاریخ ایجاد پروفایل در پایگاه داده RACF
• و فیلدهای دیگر

فیلدهای پسورد و عبارتاز نظر تحلیل امنیتی اهمیت ویژه‌ای دارند و در ادامه به‌صورت دقیق‌تری بررسی خواهند شد.

ساختار پایگاه داده RACF

پایگاه داده RACF به‌صورت یک مجموعه‌داده  با ساختاری خاص در z/OS ذخیره می‌شود. درک این ساختار برای تحلیل پایگاه داده و شناسایی روابط بین اشیاء و کاربران در z/OS بسیار مفید است. مجموعه‌داده در مین‌فریم معادل یک فایل بوده و از یک سری بلوک  تشکیل شده است.

ساختار پایگاه داده RACF

تصویر ارائه‌شده ساختار پایگاه داده RACF را نشان می‌دهد و جزئیات مربوط به بلوک‌های داده و موقعیت آن‌هارا مشخص می‌کند. از منظر تحلیل پایگاه داده RACF و تعیین روابط میان اشیاء و کاربران در z/OS، مهم‌ترین بلوک‌ها عبارتند از:

• بلوک سرآیند:شامل فراداده‌ها و اشاره‌گرهایی به سایر بلوک‌های داده در پایگاه داده است. با خواندن این بلوک، دسترسی به باقی بلوک‌ها فراهم می‌شود.
• بلوک‌های فهرست: به‌صورت لیست پیوندی ساده سازماندهی شده‌اند و اشاره‌گرهایی به تمام پروفایل‌ها و بخش‌های آن‌ها دارند؛ شامل اطلاعات کاربران، گروه‌ها، منابع و مجموعه‌داده‌ها.
• الگوها: بلوکی کلیدی که الگوهای انواع پروفایل‌ها را در خود دارد (پروفایل کاربر، گروه، مجموعه‌داده و منابع عمومی) و ساختار فیلدها را برای هر بخش تعیین می‌کند.

نیاز به ابزار تحلیلی اختصاصی

در فرآیند بررسی ساختار پایگاه داده RACF، نیاز به ابزاری احساس شد که بتواند اطلاعات مربوط به همه پروفایل‌ها را—بدون وابستگی به نسخه خاصی از RACF—استخراج کرده و داده‌ها را در قالبی قابل تحلیل به‌صورت آفلاین ذخیره کند. چنین تحلیلی تصویری جامع از روابط میان اشیاء و کاربران در یک نصب خاص از z/OS فراهم نموده و به شناسایی آسیب‌پذیری‌های امنیتی مانند افزایش سطح دسترسی یا حرکت افقی کمک می‌کند.

 

ابزارهای موجود برای تحلیل پایگاه داده RACF

در ابتدا، ابزارهای موجود بررسی شدند:

• racf2john:استخراج هش رمز عبور کاربران از فیلدپسوردبا الگوریتم‌های DES و KDFAES. اما فقط به همین فیلد محدود می‌شود و اطلاعاتی مانند«عبارت»را بازیابی نمی‌کند.
• racf2sql:  تبدیل خروجی dump پایگاه دادهایجادشده با ابزار IRRDBU00 به پایگاه داده SQLite.  اگرچه قابل جستجو با SQL است، اما تبدیل داده ممکن است اطلاعات مهم امنیتی را از بین ببرد و ابزار نیازمند فایل dump است، نه پایگاه داده خام.
• IRRXUTIL:  ابزار رسمی برای پرس‌وجو از پایگاه داده RACF، قابل استفاده با اسکریپت‌های REXX. اما برای اجرا نیاز به سطح دسترسی بالا دارد و باید روی خود مین‌فریم اجرا شود.
• racf_debug_cleanup.c:  تحلیل مستقیم پایگاه داده از کپی مجموعه‌داده، ولی تنها بخش BASE  را پردازش می‌کند و خروجی متنی ارائه می‌دهد.

هیچ‌یک از این ابزارها نیازهای ما را به‌طور کامل برآورده نمی‌کنند: برخی نیاز به اجرای مستقیم روی مین‌فریم دارند، برخی فقط اطلاعات ناقص استخراج می‌کنند، و برخی به آدرس‌ها و ساختارهای سخت‌کدشده وابسته‌اند که ممکن است در نسخه‌های مختلف RACF متفاوت باشند.

معرفی racfudit

در نتیجه، ما ابزار اختصاصی خود به نام racfudit را توسعه دادیم؛ ابزاری مستقل از سیستم‌عامل، نوشته‌شده به زبان Golang و آزمایش‌شده بر روی نسخه‌های مختلف z/OS  (1.13، 2.02، و 3.1). در ادامه به نحوه عملکرد، قابلیت‌ها و مزایای این ابزار خواهیم پرداخت.

استخراج داده از پایگاه داده RACF

برای تحلیل آفلاین، فرآیند استخراج داده به‌صورت دو مرحله‌ای انجام می‌شود:

1.      تحلیل الگوها:هر الگو ساختار یک نوع پروفایل، بخش‌های آن و فیلدهای مربوطه (نوع و اندازه) را مشخص می‌کند. این مرحله برای شناسایی ساختار پروفایل‌ها در نسخه‌های مختلف RACF ضروری است.
2.      پیمایش بلوک‌های فهرست:با استفاده از اطلاعات مرحله اول، همه پروفایل‌ها از پایگاه داده استخراج و تفسیر می‌شوند.

الگوها برای تفسیر آرایه‌های بایتی پروفایل‌ها استفاده می‌شوند و ساختار داده‌های استخراج‌شده را مشخص می‌کنند.

پایگاه داده RACF را از مین‌فریم خارج کرده و بلوک سرآیند (ICB) را می‌خوانیم تا موقعیت الگوها را بیابیم.
بر اساس الگوهای هر نوع پروفایل، الگوریتمی برای ساختاردهی نمونه‌های پروفایل تعریف می‌کنیم.
با استفاده از محتوای بلوک سرآیند، بلوک‌های فهرست را که اشاره‌گر به همه نمونه‌های پروفایل هستند، پیدا می‌کنیم. الگوریتم پردازش را بر هر نمونه پروفایل و بخش‌هایش بر اساس الگوی مربوطه اعمال می‌کنیم.
تمام نمونه‌های پردازش‌شده در حالت میانی ذخیره می‌شوند تا در آینده بتوان آن‌ها را در قالب‌های مختلف مانند متن ساده یا SQLite ذخیره کرد.
مزیت این روش، عدم وابستگی به نسخه است؛ حتی اگر ساختار الگوها و بلوک‌های فهرست در نسخه‌های مختلف RACF تغییر کند، ابزار ما داده‌ها را از دست نمی‌دهد چون ساختار هر نوع پروفایل را به‌صورت پویا از الگوهای مربوطه تعیین می‌کند. ابزار racfudit قادر است اطلاعات استخراج‌شده را به صورت پایگاه داده SQLite یا فایل متن ساده ارائه دهد.با استفاده از SQLite می‌توانید کوئری‌های SQL اجرا کنید تا خطاهای پیکربندی RACF را که ممکن است برای افزایش سطح دسترسی، حرکت افقی، دور زدن کنترل‌های دسترسی یا دیگر تکنیک‌های تست نفوذ استفاده شوند، شناسایی کنید. همچنین، مجموعه کوئری‌های SQL قابل تنظیم است تا تنظیمات فعلی RACF را با استانداردها و بهترین شیوه‌های امنیتی مقایسه کند. در ادامه چند مثال از استفاده ابزار racfudit برای کشف مشکلات امنیتی آمده است.

جمع‌آوری هش‌های رمز عبور

یکی از اهداف اصلی تست نفوذ، به‌دست آوردن فهرستی از مدیران و راهی برای احراز هویت با اعتبارنامه‌های آن‌هاست. این کار می‌تواند برای حفظ دسترسی، حرکت به سمت سایر مین‌فریم‌ها یا حتی تغییر مسیر به سرورهای با سیستم‌عامل‌های دیگر مفید باشد. معمولاً مدیران در گروه SYS1 و زیرگروه‌های آن قرار دارند. نمونه کوئری زیر هش‌های رمز عبور  و عبارات رمزیکاربران دارای دسترسی ویژه در گروه SYS1 را بازیابی می‌کند.
البته برای ورود به سیستم باید این هش‌ها کرک شوند تا رمزهای واقعی بازیابی شوند که در ادامه بیشتر توضیح داده می‌شود.

جستجوی کنترل ناکافی UACC در مجموعه‌داده‌ها

پارامتر [1]UACC   سطح دسترسی پیش‌فرض به مجموعه‌داده را مشخص می‌کند و برای کاربرانی است که دسترسی خاصی تعریف نشده است. کنترل ناکافی بر مقدار UACC می‌تواند ریسک بزرگی باشد، به خصوص اگر دسترسی‌هایی با سطح بالا مانند UPDATE یا بالاتربرای مجموعه‌داده‌های حساس یا کتابخانه‌های APF تنظیم شده باشد، که امکان افزایش سطح دسترسی را فراهم می‌کند.
کوئری زیر به شناسایی مجموعه‌داده‌هایی با دسترسی ALTER پیش‌فرض کمک می‌کند، که به کاربران اجازه خواندن، حذف و تغییر مجموعه‌داده را می‌دهد.
توجه کنید که فیلد UACC فقط در پروفایل‌های مجموعه‌داده‌ها نیست و در پروفایل‌های دیگر نیز وجود دارد. کنترل ضعیف این فیلد می‌تواند به نفوذگر اجازه دسترسی به منابع را بدهد.

روابط پروفایل‌های RACF
همانطور که پیش‌تر گفته شد، بین موجودیت‌های مختلف RACF روابطی وجود دارد. برخی روابط به صورت صریح تعریف شده‌اند؛ مثلاً نام کاربری ممکن است در فیلد اعضا (USERID) پروفایل یک گروه ثبت شده باشد. اما روابط ضمنی نیز وجود دارند؛ برای مثال اگر گروه کاربری به یک مجموعه‌داده دسترسی UPDATE داشته باشد، همه اعضای آن گروه به طور ضمنی دسترسی نوشتن به آن مجموعه‌داده دارند. این نمونه‌ای ساده از روابط ضمنی است. در ادامه به روابط پیچیده‌تر و خاص‌تر در پایگاه داده RACF می‌پردازیم که تست‌کننده نفوذ می‌تواند از آن‌ها سوءاستفاده کند.

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

فیلدهای پروفایل کاربر

• SPECIAL:  نشان می‌دهد کاربر مجوز اجرای تمام دستورات RACF را دارد و کنترل کامل روی همه پروفایل‌های پایگاه داده RACF دارد.
• OPERATIONS:  نشان‌دهنده دسترسی مجاز کاربر به منابع محافظت‌شده RACF در کلاس‌های مختلف مانند DATASET و TAPEVOL است؛ در تست نفوذ معمولاً به معنای دسترسی کامل به مجموعه‌داده‌ها است.
• AUDITOR:  اجازه دسترسی به اطلاعات حسابرسی را نشان می‌دهد.
• AUTHOR:  سازنده کاربر است و دارای برخی مجوزها مانند تغییر رمز عبور کاربر می‌باشد.
• REVOKE:  نشان می‌دهد که کاربر قادر به ورود به سیستم است یا خیر.
• Password TYPE:  نوع هش رمز عبور (DES یا KDFAES)  را مشخص می‌کند و بر اساس نحوه ذخیره‌سازی رمزها ایجاد می‌شود.
• Group-SPECIAL : نشان‌دهنده کنترل کامل کاربر بر پروفایل‌های موجود در حوزه گروه یا گروه‌های مشخص شده است.
• Group-OPERATIONS:  دسترسی مجاز کاربر به منابع محافظت‌شده RACF در کلاس‌های مشخص شده در حوزه گروه یا گروه‌ها.
• Group-AUDITOR:  اجازه دسترسی به اطلاعات حسابرسی در حوزه گروه یا گروه‌ها.
• CLAUTH (class authority):اجازه ایجاد پروفایل در کلاس یا کلاس‌های مشخص را می‌دهد و امکان واگذاری مجوزهای مدیریتی را فراهم می‌کند.
• GROUPIDS:  فهرست گروه‌هایی که کاربر عضو آن‌هاست.
• UACC : مقدار UACC برای پروفایل‌های جدیدی که کاربر ایجاد می‌کند را تعریف می‌کند.

فیلدهای پروفایل گروه

• UACC: مقدار UACC برای پروفایل‌های جدیدی که کاربر هنگام اتصال به گروه ایجاد می‌کند.
• OWNER: سازنده گروه که دارای مجوزهای خاصی نسبت به گروه و زیرگروه‌های آن است.
• USERIDS:  فهرست کاربران گروه که ترتیب آن اهمیت دارد.
• USERACS:  فهرست اعضای گروه همراه با مجوزهای دسترسی آن‌ها به گروه؛ ترتیب اهمیت دارد.
• SUPGROUP:  نام گروه بالاتر (گروه اصلی).

فیلدهای پروفایل منابع عمومی و مجموعه‌داده‌ها

•          UACC:  مجوزهای دسترسی پیش‌فرض به منبع یا مجموعه‌داده را تعیین می‌کند.
•          OWNER:  سازنده منبع یا مجموعه‌داده که مجوزهای خاصی دارد.
•          WARNING:  نشان می‌دهد که آیا منبع یا مجموعه‌داده در حالت هشدار است یا خیر.
•          USERIDS:  فهرست شناسه‌های کاربری مرتبط با منبع یا مجموعه‌داده که ترتیب آن اهمیت دارد.
•          USERACS:  فهرست کاربران دارای مجوز دسترسی به منبع یا مجموعه‌داده که ترتیب اهمیت دارد.

رابطه‌های زنجیره‌ای پروفایل‌های RACF
فیلدهای ذکر شده در بالا نشان‌دهنده وجود رابطه‌هایی بین پروفایل‌های RACF هستند. این روابط را مشابه نام‌هایی که در ابزار BloodHound  (ابزاری محبوب برای تحلیل اشتباهات پیکربندی در Active Directory)  استفاده می‌شود، نام‌گذاری کرده‌ایم. در ادامه چند نمونه از این روابط آمده است (لیست کامل نیست):

•          Owner:  موضوع مالک شیء است.
•          MemberOf:  موضوع عضو شیء است.
•          AllowJoin:  موضوع اجازه دارد خود را به شیء اضافه کند.
•          AllowConnect:  موضوع اجازه دارد شیء دیگری را به شیء مشخص اضافه کند.
•          AllowCreate:  موضوع اجازه ایجاد نمونه‌ای از شیء را دارد.
•          AllowAlter:  موضوع دارای مجوز ALTER روی شیء است.
•          AllowUpdate:موضوع دارای مجوز UPDATE روی شیء است.
•          AllowRead:  موضوع دارای مجوز READ روی شیء است.
•          CLAuthTo: موضوع اجازه ایجاد نمونه‌هایی از شیء طبق فیلد CLAUTH را دارد.
•          GroupSpecial:‌موضوع کنترل کامل روی تمام پروفایل‌های محدوده تاثیر شیء طبق فیلد group-SPECIAL دارد.
•          GroupOperations:  موضوع مجوز انجام عملیات خاص روی شیء طبق فیلد group-OPERATIONS را دارد.
•          ImpersonateTo:  موضوع به شیء اجازه انجام عملیات به نمایندگی از خود را می‌دهد.
•          ResetPassword:  موضوع به شیء دیگر اجازه تنظیم مجدد رمز عبور یا عبارت رمز شیء مشخص را می‌دهد.
•          UnixAdmin:  موضوع به شیء در z/OS UNIX امتیازاتِ «اَبَر کاربر»می‌دهد.
•          SetAPF:  موضوع به شیء دیگر اجازه تنظیم فلگ APF روی شیء مشخص را می‌دهد.

این روابط به عنوان یال‌هایی در گراف ارتباطات موضوع-شیء استفاده می‌شوند. در ادامه نمونه‌هایی از روابط ممکن بین انواع پروفایل‌ها آورده شده است.

پیش از بررسی مثال‌های این زنجیره‌ها، بهتر است به یک ویژگی جالب و خاص دیگر در روابط بین موجودیت‌های پایگاه داده RACF بپردازیم.

روابط ضمنی پروفایل‌های RACF
مشاهده کردیم که فیلدهای group-SPECIAL، group-OPERATIONS  و group-AUDITOR در پروفایل کاربری دارای ویژگی جالبی هستند. اگر در یکی از این فیلدها گروهی برای کاربر مشخص شده باشد، دامنه نفوذ آن گروه به دامنه نفوذ کاربر نیز گسترش پیدا می‌کند.

مثلاً فرض کنید کاربر USER1 در فیلد group-SPECIAL، گروه GROUP1 را دارد. اگر GROUP1 مالک GROUP2 باشد و GROUP2 هم مالک USER5 باشد، آنگاه USER1 روی USER5 امتیازاتی به دست می‌آورد. این فقط مربوط به دسترسی به داده‌ها نیست؛ USER1 عملاً مالک USER5 می‌شود. یک ویژگی منحصر به فرد در z/OS این است که این سطح از دسترسی به USER1 اجازه می‌دهد حتی رمز عبور USER5 را تغییر دهد، حتی اگر USER5 دارای ویژگی‌های ویژه‌ای مثل SPECIAL، OPERATIONS، ROAUDIT، AUDITOR یا PROTECTED باشد.

در این سناریو، کاربر TESTUSR در فیلد group-SPECIAL گروه PASSADM را دارد. این گروه PASSADM  مالک کاربر OPERATOR است. بنابراین دامنه نفوذ TESTUSR گسترش یافته و کنترل بر OPERATOR را به دست می‌آورد. اگر اطلاعات ورود TESTUSR به دست مهاجم بیفتد، او به حساب OPERATOR دسترسی پیدا می‌کند. کاربر OPERATOR به منبع IRR.PASSWORD.RESET دسترسی READ دارد که اجازه می‌دهد رمز عبور هر کاربری که دسترسی ویژه ندارد را تغییر دهد.

داشتن امتیازات بالا در z/OS UNIX اغلب برای نفوذ به mainframe کافی است. این امتیازات می‌توانند از طریق موارد زیر به دست آیند:

•          دادن دسترسی READ به منبع BPX.SUPERUSER در کلاس FACILITY؛
•          دادن دسترسی READ به منابع UNIXPRIV.SUPERUSER.* در کلاس UNIXPRIV؛
•          تنظیم مقدار UID روی ۰ در بخش OMVS پروفایل کاربر.

برای مثال، کاربر DFSOPER به منبع BPX.SUPERUSER دسترسی READ دارد و در z/OS UNIX امتیاز ویژه دارد، اما فیلدهای ویژه مانند SPECIAL، OPERATIONS، AUDITOR، ROAUDIT و PROTECTED برایش تنظیم نشده‌اند. بنابراین کاربر OPERATOR می‌تواند رمز DFSOPER را تغییر دهد. این امکان، زنجیره اقدامات زیر را برای دستیابی به امتیازات بالا روی mainframe فراهم می‌کند:

۱دریافت و استفاده از اطلاعات ورود TESTUSR؛
۲تغییر رمز OPERATOR و ورود با آن حساب؛
۳تغییر رمز DFSOPER و ورود با آن حساب؛
۴دسترسی به Shell زOS UNIX با امتیازات بالا.

ما یک رابطه ضمنی دیگر در پروفایل RACF کشف کردیم که باعث ارتقاء امتیازات کاربر می‌شود.

در مثال دیگری، کاربر TESTUSR دسترسی READ به منبع OPERSMS.SUBMIT از کلاس SURROGAT  دارد. این یعنی TESTUSR می‌تواند از رابطه ImpersonateTo، با هویت OPERSMS تسک ایجاد کند. کاربر OPERSMS عضو گروه HFSADMIN است که به منبع TESTAUTH از کلاس TSOAUTH دسترسی READ دارد. این منبع مشخص می‌کند که آیا کاربر می‌تواند برنامه یا کتابخانه‌ای را به صورت APF-authorized اجرا کند یا نه. برای اینکار فقط دسترسی READ لازم است. بنابراین، اگر دسترسی APF به اشتباه تنظیم شده باشد، OPERSMS  می‌تواند امتیازات خود را به بالاترین سطح ارتقا دهد. این زنجیره یک مسیر از کاربر کم‌امتیاز TESTUSR به دسترسی‌های کامل رویمین‌فریمرا نشان می‌دهد. در حال حاضر، ابزار racfudit این ارتباطات را تنها به صورت دستی و با اجرای مجموعه‌ای از کوئری‌های SQLite قابل شناسایی می‌کند؛ اما برنامه داریم که فرمت خروجی‌های جدید مثل ادغام با پایگاه داده Neo4j اضافه کنیم تا بتوان زنجیره‌ها را به صورت خودکار و گرافیکی نمایش داد.

هش‌های پسورد در RACF

برای افزایش امتیازات و دسترسی به مین‌فریم، نیاز به اطلاعات ورود کاربران دارای امتیاز داریم. قبلاً از ابزار خود برای استخراج هش‌های پسورد استفاده کردیم. اکنون به اصول سیاست پسورد در z/OS می‌پردازیم و روش‌های بازیابی پسورد از هش‌های جمع‌آوری‌شده را مرور می‌کنیم.

روش‌های اصلی احراز هویت پسورد در z/OS که بر اساس RACF هستند، عبارت‌اند از: PASSWORD و PASSPHRASE.

• PASSWORD:  پسوردی است که به صورت پیش‌فرض از کاراکترهای ASCII شامل حروف بزرگ انگلیسی، اعداد و کاراکترهای خاص (@#$) تشکیل شده و طول آن حداکثر ۸ کاراکتر است.
• PASSPHRASE:  عبارت پسوردی است با سیاست پیچیده‌تر که اجازه استفاده از ۱۴ تا ۱۰۰ کاراکتر ASCII را می‌دهد، شامل حروف کوچک و بزرگ انگلیسی، اعداد و مجموعه‌ی وسیع‌تری از کاراکترهای خاص (@#$&*{}=,.;’+/).

هش‌های هر دو نوع PASSWORD و PASSPHRASE در پروفایل کاربر در بخش BASE، در فیلدهای PASSWORD و PHRASE ذخیره می‌شوند. دو الگوریتم رمزنگاری برای تولید این مقادیر استفاده می‌شوند: DES و KDFAES.

قابل ذکر است که اصطلاحات «هش پسورد» و «هش عبارت پسورد» برای وضوح به کار می‌روند. در الگوریتم‌های DES و KDFAES، اطلاعات کاربری به صورت متن رمزنگاری شده ذخیره می‌شوند و نه هش به معنای کلاسیک آن. با این حال، ما همچنان از این اصطلاحات مطابق مستندات IBM استفاده می‌کنیم.

الگوریتم DES

در حالت استفاده از الگوریتم DES، مقدارهای PASSWORD و PHRASE در RACF به صورت رمزنگاری کلاسیک DES محاسبه می‌شوند.

• داده ورودی  نام کاربری است که اگر کوتاه‌تر از ۸ کاراکتر باشد، با فضای خالی پر می‌شود تا به طول ۸ برسد.
• کلید رمزنگاری، پسورد کاربر است که اگر کوتاه‌تر از ۸ کاراکتر باشد، مشابه پر می‌شود.

PASSWORD
نام کاربری با کلید پسورد تحت الگوریتم DES رمزنگاری می‌شود و نتیجه ۸ بایتی حاصل در فیلد PASSWORD پروفایل ذخیره می‌گردد. در نظر داشته باشید که هم نام کاربری و هم رمز عبور با کدگذاری EBCDIC ذخیره می‌شوند. برای مثال، نام کاربری USR1 در EBCDIC به صورت e4 e2 d9 f1 40 40 40 40است که در آن بایت 0x40به عنوان پرکننده (padding) برای رساندن طول داده به ۸ بایت استفاده شده است.

با توجه به فضای کلید کوچک و پیچیدگی محاسباتی کم الگوریتم DES، بازیابی این پسوردها بسیار سریع انجام می‌شود. مثلاً حمله brute-force با استفاده از کلاستری از کارت‌های گرافیک NVIDIA 4090 کمتر از پنج دقیقه زمان می‌برد. ابزار hashcat دارای ماژولی با شناسه هش ۸۵۰۰ (Hash-type 8500) برای شکستن پسوردهای RACF رمز شده با DES است.

PASSPHRASE

رمزنگاری PASSPHRASE کمی پیچیده‌تر است و شرح کامل الگوریتم آن به‌صورت عمومی در دسترس نیست. اما تحقیقات ما ویژگی‌های جالبی را نشان داده است:

• طول هش نهایی در فیلد PHRASE برابر طول عبارت پسورد اصلی است.
• داده‌ای که با الگوریتم DES رمزنگاری می‌شود، بعد از رمزنگاری به همان طول داده‌ی اصلی (ورودی) کوتاه می‌شود و قسمت‌های اضافه‌ای که برای پرکردن  اضافه شده‌اند حذف می‌گردند. یعنی نتیجه رمزنگاری دقیقاً به اندازه طول داده اصلی باقی می‌ماند و پرکردن در خروجی لحاظ نمی‌شود.. این طراحی می‌تواند باعث برخورد  و تایید نادرست در شرایطی خاص شود. مثلاً اگر عبارت پسورد اصلی ۱۷ بایت باشد، در سه بلوک رمزنگاری می‌شود، بلوک آخر ۷ بایت پر شده و پس از رمزنگاری این بایت‌های اضافه حذف می‌شوند. در چنین حالتی هر عبارتی که ۱۷ بایت اول رمزنگاری شده آن با مقدار PHRASE مطابقت داشته باشد، معتبر شناخته می‌شود.
• دومین ویژگی مهم این است که مقدار فیلد«عبارت»نیز توسط الگوریتم DES محاسبه می‌شود، اما از مد زنجیره بلوک اختصاصی IBM استفاده می‌کند که ما به صورت غیررسمی به آن "حالت سفارشی IBM"می‌گوییم.

با توجه به این محدودیت‌ها، می‌توان از ماژول hashcat مخصوص DES برای بازیابی ۸ کاراکتر اول عبارت پسورد استفاده کرد. در برخی سناریوهای عملی، بازیابی ابتدای عبارت پسورد به حدس باقی قسمت‌ها کمک کرده است؛ به‌خصوص وقتی پسوردهای ضعیف دیکشنری استفاده شده‌اند. برای مثال اگر ۸ کاراکتر اول "Admin123" بازیابی شود، و طول کل عبارت پسورد ۱۵ کاراکتر باشد، احتمالاً پسورد کامل چیزی مانند "Admin1234567890" است.

KDFAES

محاسبه پسوردها و عبارات پسوردی که با الگوریتم KDFAES ساخته شده‌اند، به مراتب پیچیده‌تر از DES است. KDFAES الگوریتم اختصاصی IBM است که از رمزنگاری AES استفاده می‌کند. کلید رمزنگاری با استفاده از تابع PBKDF2 و تعداد مشخصی تکرار هش از پسورد استخراج می‌شود.

 

PASSWORD

مرحله اول مشابه الگوریتم محاسبه PASSWORD مبتنی بر DES است. در این مرحله، نام کاربریرمزگذاری شده با EBCDIC و در صورت کوتاه بودن با پرکننده به ۸ بایت رسانده شدهبا استفاده از الگوریتم DES و رمز عبور به عنوان کلید، رمزنگاری می‌شود. خروجی این مرحله یک بلوک ۸ بایتی است که به عنوان کلید برای مرحله دوم (هشینگ) استفاده می‌شود.

در مرحله دوم، یک الگوریتم اختصاصی IBM مبتنی بر PBKDF2-SHA256-HMAC اجرا می‌شود. در این مرحله، یک رشته ۱۶ بایتی تصادفی  به همراه کلید ۸ بایتی حاصل از مرحله اول، وارد الگوریتم می‌شوند. سپس داده‌ها به‌صورت تکراری با استفاده از PBKDF2-SHA256-HMAC هش می‌شوند. تعداد تکرارها با دو پارامتر تنظیم شده در RACF تعیین می‌شود: عامل حافظه  و عامل تکرار.

خروجی مرحله دوم یک هش ۳۲ بایتی است که به عنوان کلید رمزنگاری AES در مرحله سوم استفاده می‌شود.

در مرحله سوم، نام کاربری با استفاده از کلید AES (خروجی مرحله دوم) رمزنگاری می‌شود و خروجی نهایی ۱۶ بایت داده رمز شده است.8بایت اول این خروجی به انتهای فیلد PWDX در بخش BASE پروفایل کاربر اضافه می‌شود و ۸ بایت دوم در فیلد PASSWORD در همان بخش قرار می‌گیرد.

رمزنگاری هش عبارت عبور با الگوریتم KDFAES شباهت‌های زیادی به رمزنگاری هش کلمه عبور دارد. طبق منابع عمومی، تفاوت اصلی در کلیدی است که در مرحله دوم استفاده می‌شود. برای کلمه عبور، داده‌های مشتق‌شده از رمزنگاری DES نام‌کاربری استفاده می‌شود، در حالی که برای عبارت عبور، هش SHA256 آن به کار می‌رود. در تحلیل ما فرآیند دقیق هش کردن عبارت عبور مشخص نشد — به‌ویژه اینکه آیا پرکردن (منظور همان پدینگ[2] است)، کلید مخفی یا موارد دیگر در این فرآیند استفاده می‌شود یا خیر.

همچنین، هنگام استفاده از عبارت عبور، فیلدهای PHRASE و PHRASEX به جای PASSWORD و PWDX به ترتیب، هش نهایی را ذخیره می‌کنند و مقدار PHRASEX ساختار مشابهی دارد.

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

امیدواریم اطلاعات ارائه شده به دارندگان مینفریم کمک کند تا خطرات بالقوه مرتبط با پیکربندی‌های نادرست مجموعه امنیتی RACF را بهتر درک و ارزیابی کرده و اقدامات کاهش مناسبی انجام دهند. انتقال به الگوریتم KDFAES  و استفاده از عبارات عبور، کنترل مقادیر UACC، بررسی دسترسی به کتابخانه‌های APF، پیگیری منظم زنجیره‌های روابط کاربران و سایر موارد ذکر شده در مقاله می‌تواند به طور قابل توجهی وضعیت امنیتی زیرساخت شما را با کمترین تلاش ارتقا دهد.

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

 

[1] Universal Access Authority

[2] Padding

 

 کسپرسکی آنلاین (ایدکو)

کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.