sideeffect42/rootpipetesterRootPipe (CVE-2015-1130) وPhoenix (CVE-2015-3673) أداة اختبار الثغرات الأمنية لنظام Mac OS X 10.2.8 والإصدارات الأحدث
RootPipe Tester هو تطبيق صغير يعمل على جهاز Mac الخاص بك (Mac OS X 10.2.8 أو أحدث، لكلٍّ من PowerPC وIntel) ويحاول استخدام كلٍّ من استغلالَي RootPipe (CVE-2015-1130) وPhoenix (CVE-2015-3673) لإحداث تصعيد صلاحيات (privilege escalation).
إن كان جهاز Mac الخاص بك قابلاً للاختراق يعتمد على إصدار Mac OS X الذي تشغّله، لكن نجاحه يعتمد أيضاً على التفضيلات التي قمت بتعيينها.
مع RootPipe Tester قمت بإنشاء حل بنقرة واحدة لك للتحقق من كونك عرضة للاختراق دون الحاجة إلى اختبارات ومحاولات مكثفة.
قم بتنزيل صورة القرص من صفحة الإصدارات (releases) في هذا المستودع أو قم بتجميعه بنفسك إذا كنت تفضّل.
قم بتركيب (mount) صورة القرص وشغّل التطبيق الموجود بداخلها (من الآمن تشغيل RootPipe Tester من صورة القرص).
انقر على "بدء الاختبار" ودع الاختبار يكتمل (يمكنك معرفة ما إذا انتهى من خلال "جارٍ التشغيل…" في عنوان النافذة).
للحصول على نتائج دقيقة، أنصح بإعادة تشغيل جهاز Mac وتشغيل الاختبار مرة أخرى على "تسجيل دخول جديد".
إذا اكتشف أحد اختبارات التشغيل على الأقل أن النظام قابل للاختراق، فقد ترغب في الاطلاع على قسم PANIC.
لا! حافظ على هدوئك واقرأ الدليل المناسب لإصدار نظامك.
ملاحظة: "غير قابل للاختراق" في حالة تفويض المستخدم (user authorization) تعني أن النظام إما لن يمنح الوصول أو سيعرض حوار تفويض يطلب منك المصادقة كمستخدم Administrator.
إلى حدٍّ ما يُعد هذا أيضاً تصعيد صلاحيات، لأن مجموعة admin لا تملك حقوقاً بقدر root، لكن في الإعداد الافتراضي لأمر sudo، يمكن لأي مستخدم في مجموعة "admin" الحصول على صلاحيات root بإدخال كلمة المرور الخاصة به، لذا يمكن تحقيق نفس التأثير ببساطة عبر تشغيل sudo.
قم بالترقية إلى 10.10.3 في أقرب وقت ممكن للتأكد من أن النظام يفرض الاستحقاقات (entitlements) على ملف writeconfig الثنائي بشكل صحيح. (هذا على الأقل ما تقوله Apple)
إذا تعذّر عليك الترقية إلى 10.10.3 لسبب ما، فراجع القسم الخاص بـ OS X 10.9 Mavericks.
يسمح Mavericks للمستغل بالمرور بتفويض فارغ (nil authorization)، لذا فأنت في وضع أصعب بكثير مقارنة بالإصدارات الأقدم من Mac OS X.
قد ترغب في إلقاء نظرة على can_I_suid.
نتائج الاختبار:
قابل للاختراق
يجب عليك تفعيل "طلب كلمة مرور لفتح كل لوحة من لوحات تفضيلات النظام" في لوحة تفضيلات الأمان (Security).
نتائج الاختبار:
غير قابل للاختراق
تهانينا! لديك أحد أكثر إصدارات Mac OS X أماناً (على الأقل فيما يتعلق بـ RootPipe).
على هذه الأنظمة، يعمل خيار "طلب كلمة مرور لفتح كل لوحة من لوحات تفضيلات النظام" ("طلب كلمة مرور لفتح كل تفضيل نظام آمن" في Tiger) في لوحة تفضيلات الأمان بشكل صحيح و_يجب حقاً تفعيله_!
ملاحظة: إذا كان مربع "طلب كلمة المرور" غير محدّد، سيقوم النظام بفتح لوحات التفضيلات الآمنة في كل تسجيل دخول. إذا كنت تستخدم حساب Administrator فسيجعل ذلك نظامك قابلاً للاختراق حتى تقوم يدوياً بإغلاق القفل في تفضيلات النظام بعد كل تسجيل دخول.
نتائج الاختبار:
غير قابل للاختراق
على عكس الأنظمة الأحدث، في Panther، لا يكون لمربع "طلب كلمة مرور لفتح كل تفضيل نظام آمن" في لوحة تفضيلات الأمان تأثير منع هذا الاستغلال من العمل تماماً. ما زلت أنصح بتحديده.
لتأمين نظامك، أنصحك بشدة بالتحول إلى استخدام حساب مستخدم قياسي فقط، ودائماً "إغلاق القفل" يدوياً بعد تغيير التفضيلات في تفضيلات النظام.
إغلاق تفضيلات النظام فقط لن يلغي التفويض بشكل صحيح، وسيستمر هذا الاستغلال في العمل حتى تسجّل الخروج، على الرغم من أن واجهة تفضيلات النظام تُظهر قفلاً مغلقاً لمستخدم قياسي.
نتائج الاختبار:
غير قابل للاختراق
على عكس الأنظمة الأحدث، لا يوفر Jaguar مربع "طلب كلمة مرور لفتح كل تفضيل نظام آمن" لكنه ما زال يفتح لوحات التفضيلات الآمنة عند تسجيل الدخول لجميع مستخدمي Administrator.
لتأمين نظامك، أنصحك بشدة بالتحول إلى استخدام حساب مستخدم قياسي فقط.
ملاحظة: لا يقفل Jaguar لوحات التفضيلات الآمنة عند خروج تفضيلات النظام، لذا قم دائماً بقفل اللوحات الآمنة يدوياً. إذا أخفقت في ذلك، سيستمر الاستغلال في العمل حتى تسجّل الخروج.
ملاحظة: إذا لم تستطع التحول إلى حساب مستخدم قياسي، فقد يؤدي الغرضَ برنامج AppleScript بسيط يقفل لوحات التفضيلات الآمنة كأحد عناصر تسجيل الدخول (Login Item).
ملاحظة: لن يعمل الإصدار العادي من RootPipe Tester على Jaguar. قم بتنزيل الإصدار القديم (Legacy) من RootPipe Tester إذا أردت العمل على Jaguar.
الإصدار القديم من RootPipe Tester مكافئ وظيفياً للإصدار العادي، لكنه مُجمّع باستخدام GCC 3.1 بدلاً من GCC 4.0.
نتائج الاختبار:
غير قابل للاختراق
يبدو أن استغلال Puma ممكن، لأنه يستخدم نفس الخطوات لمصادقة تفضيلات النظام ومعظم المكونات الضرورية موجودة.
الشيء الوحيد الذي يعيق الاستغلال هو أن Puma لا يمتلك SecurityFoundation.framework المستخدم في الإصدارات الأحدث للتفويض.
بدلاً من ذلك يستخدم إطاراً خاصاً (PrivateFramework) يُدعى NIInterface.framework يجب هندسته عكسياً أولاً.
الخبر الجيد على أي حال: لن يستثمر أحد وقته في استغلال قاعدة مستخدمين تكاد تكون معدومة.
لتعزيز الأمان، ما زال يُنصح باستخدام حساب مستخدم قياسي فقط _و_قفل لوحات التفضيلات الآمنة يدوياً.
ملاحظة: خذ هذه الفقرة بقليل من الحذر. لقد بذلت قصارى جهدي لمعرفة ما يحدث فعلاً، لكن بما أن كل شيء عبارة عن أطر خاصة (PrivateFrameworks)، لا يمكنك أبداً معرفة ما تقوم به هذه الدوال بشكل 100%، خاصة عبر هذا العدد الكبير من إصدارات Mac OS X التي أحاول تغطيتها.
الطريقة التي يعمل بها استغلال RootPipe هي في الأساس نفس ما تفعله تفضيلات النظام لكتابة ملفات الإعدادات (ومن هنا جاء الاسم WriteConfig) مع استثناء أن مستخدمي هذا الاستغلال يجب ألا يكونوا تطبيق تفضيلات النظام.
حتى الآن الأمر ليس فظيعاً، وفي الواقع الاستغلال بأكمله ليس فظيعاً أيضاً.
لكن دعنا ننظر إلى الكود.
// Authorization
SFAuthorization auth = [SFAuthorization authorization];
id authenticator = [Authenticator sharedAuthenticator];
[authenticator authenticateUsingAuthorizationSync:auth];
// Profit?
id sharedLiaison = [ToolLiaison sharedToolLiaison];
id tool = [sharedLiaison tool];
كما ترى، هذا كود "بالنمط القديم"، لكن المبدأ بالنسبة للنمط الجديد هو نفسه تقريباً. الأسطر الثلاثة الأولى في هذا المقطع هي للتفويض (authorization) والآخران هما المتعة الحقيقية.
إذا احتاجت لوحة تفضيلات في تفضيلات النظام إلى تنفيذ عمليات يجب تشغيلها بصلاحيات مرتفعة، فسيضع SFAuthorizationView (رمز القفل) في الزاوية السفلية اليسرى. سيتولى هذا SFAuthorizationView بعد ذلك اكتساب حق system.preferences وإتلافه.
حتى الآن كل شيء على ما يرام، لكن ما هو هذا system.preferences؟
الحقوق التي تستخدمها Apple وكيفية تكوينها تغيرت بمرور الوقت، لكن المبدأ بقي كما هو. أدناه ترى مقتطفاً من قاعدة بيانات سياسات خدمات التفويض (Authorization Services Policy Database).
system.preferences على 10.5.8
{
"allow-root" = 1;
class = user;
comment = "Checked by the Admin framework when making changes to certain System Preferences.";
group = admin;
shared = 1;
}
كما ترى، إنه حق مشترك (shared). هذا يعني أنه بمجرد اكتساب هذا الحق من قبل أي عملية، يمكن لأي عملية أخرى استخدامه طالما لم يتم إتلاف الجلسة (عند تسجيل الخروج).
هذا بحد ذاته ليس سيئاً للغاية، لأنه يتعين عليك التفويض في المرة الأولى التي يريد فيها تطبيق ما استخدام system.preferences، لكن للأسف يقوم النظام بتفويضه تلقائياً عند تسجيل الدخول (لمستخدمي Administrator).
هذا يعني أن RootPipe Tester الخاص بنا لن يضطر إلى الحصول على تفويض، ويمكنه بدلاً من ذلك استخدام تفويض النظام.
المستخدمون القياسيون في أمان، لأن النظام لا يفوض حق system.preferences عند تسجيل الدخول.
مع اكتساب التفويض المناسب، تصبح كتابة ملفات الإعدادات (أو أي ملف آخر لهذه المسألة) بصلاحيات تعسفية لعبة سهلة للغاية.
سيعمل ToolLiaison بسعادة على إعداد NSDistantObject إلى writeconfig من أجلك، وسيقوم writeconfig بكتابة الملف لك بسعادة، لأنه في منظورهما، قمت بتفويض نفسك بشكل صحيح.
تحديد مربع "طلب كلمة مرور لفتح كل لوحة من لوحات تفضيلات النظام" في تفضيلات النظام يصلح ثغرة RootPipe في جميع إصدارات Mac OS X من 10.4 إلى 10.8.
تحديد هذا المربع سيعدّل حق system.preferences ويجعل shared غير صحيح.
إذا لم يكن الحق مشتركاً، فهذا يعني أن كل عملية يجب أن تحصل على تفويض خاص بها. ولأن الحصول على التفويض يتطلب من المستخدم إدخال كلمة مرور Administrator، يمكن للمستخدم ملاحظة الهجوم.
أيضاً، مجرد تشغيل sudo سيكون له نفس التأثير، مما يجعل هذا الهجوم عديم الفائدة.
ليس حقاً. للوهلة الأولى قد يبدو كذلك، لأنه موجود في إطار خاص (PrivateFramework) يعمل بصلاحيات root ولا يقوم بمصادقة سليمة.
لكن المشكلة الحقيقية هنا هي بالأساس مشكلة تصميم سيئ. أرادت Apple ضمان أن يكون كل مستخدم Administrator قادراً على استخدام تفضيلات النظام بالكامل، وفي Unix كل شيء يحتاج إلى ملف إعداد وهذه الملفات تحتاج إلى الكتابة (في معظم الأوقات بصلاحيات root).
قد يجادل البعض بأن هذه فكرة سيئة (سأوافق على ذلك) لكنني لن أعتبرها باباً خلفياً لأن المصادقة تعمل بشكل صحيح ولكل Administrator القدرة على الحصول على صلاحيات root عبر sudo على أي حال.
المشكلة الأساسية هنا هي أن Apple فضّلت الراحة على الأمان، لكن هذا أيضاً ليس أمراً استثنائياً بالنسبة لها.