SUID Programs Part 1

السلام عليكم ورحمة الله وبركاته

هذه المقالة تلخيص بسيط لقراءتي حول موضوع الـ Set-UID Program ، لمن أراد الاستزادة المصادر في آخر المقالة

كل ما سيتم ذكره مُتعلق بأنظمة Linux فقط وسأتطرق باذن الله للنقاط التالية :

-         الحاجة الى الـPrivileged Programs

-        كيف تعمل الـ Set-UID Program

-        Attack Surfaces of Set-UID Programs

-        Attacks Through Environment Variables

 

الحاجة الى الـ Privileged Programs

الـ Privileged Programs  كما تدل عليه الترجمة الحرفية للكلمة هي برامج تعمل بصلاحية عالية في النظام

في أنظمة لينكس يوجد منهجيتين أو لنقل نوعين من الـ Privileged Programs

الأول Privileged Daemon و كما نعلم الـ Daemon  ماهي إلا برنامج يعمل في الخلفية لكن في الحالة هذه الـ Daemon تم تشغيلها كـ root

النوع الثاني هو الـ Set-UID Program ، سنتطرق لها بتفصيل في الأجزاء القادمة

 

لمثل ماذا نحتاج هذه الـ Privileged Programs لاسيما للمستخدم العادي الذي لا يملك صلاحية عالية في النظام أساسًا؟

لتوضيح الغرض من تمكين المستخدم من تشغيل برامج بصلاحية عالية لنأخذ هذا المثال :

في أنظمة لينكس تُحفظ كلمات المرور الخاصة بمستخدمي النظام في /etc/shadow كما نعلم

وفي كل مرة يقوم المستخدم بتغيير كلمة مروره تأتي الحاجة الى تحديث هذا الملف، نَظرَه قريبه على صلاحيات هذا الملف تُظهِر لنا أن الملف لا يمكن تعديله إلا من قبل الـ root

إذا كان الملف لايمكن التعديل عليه إلا من قبل الـ root فكيف سيتمكّن بقية المستخدمين من تعديل كلمات مرورهم ؟

إعطاء صلاحية التعديل على هذا الملف للجميع ليس خيار بالطبع، فهذا يفتح باب لمشكلة أخرى وهي إمكانية أن يقوم أي مستخدم بتعديل كلمة المرور لأي مستخدم آخر ..

من أجل هذا الغرض ظهر نوع معين من البرامج ذات الصلاحية العالية يسمى بالـ Set-UID Programs

وبشكل مُختصر جدًا: هذه البرامج تُعطي المستخدم صلاحية لا يملكها في الأساس لتنفيذ مُهمة تتطلّب صلاحية أخرى (في الأغلب تكون صلاحية الـ root وإعطاء هذه الصلاحية محصور في هذا البرنامج فقط)

 

كيف تعمل الـ Set-UID Program

الـ Set-UID Programs  تحمل في خصائصها قيمة مميزه تسمى الـ Set-UID bit

كتاب: Practical Unix Security, p: 74

 

عند تشغيل أي برنامج سينظر نظام التشغيل لينكس الى هذه القيمة، فإن كانت مُفعّله فسيتم التعامل مع هذا البرنامج بشكل مُختلف عن بقية البرامج

ماذا نقصد بشكل مُختلف ؟

بدايةً يجب أن نعرف أن العمليات (Processes ) في نظام لينكس تحمل خصائص أيضًا، من ضمن هذه الخصائص ثلاثة خصائص تهمنا وهي :

-        Real User ID : هذا المتغير يمثل الـ ID الخاص بالمستخدم الذي بدأ العملية

-        Effective User ID : يمثل الـ ID الخاص بالمستخدم الذي سيتم تنفيذ العملية وفقًا لصلاحياته، بعبارة أخرى يمثل الـ access control

-        Saved User ID : هذا المتغير يُستخدم لتعطيل أو تفعيل الصلاحيات

الأن ما الذي يحدث حينما يتم تشغيل برنامج يحمل الـ Set-UID bit في خصائصه ؟

الـ Real User ID ستكون قيمته قيمة الـ ID الخاص بالمستخدم الذي قام بتشغيل البرنامج

بينما قيمة الـ Effective User ID ستكون قيمة الـ ID الخاص بالمستخدم الذي يملك البرنامج (owner) ..

بلغة أخرى: سيعمل هذا البرنامج وفقًا لصلاحيات المستخدم الذي يملكه وليس المستخدم الذي قام بتشغيله

كتاب: Practical Unix Security, p: 75

بهذه المنهجية يُتيح لينكس للمستخدم العادي تشغيل برامج بصلاحية عالية، وتكون هذه الصلاحية محدودة في عملية (Process) معينه فقط

لنعود الآن لمثالنا السابق، تعديل كلمة المرور ،

كيف يسمح النظام للمستخدمين بتعديل كلمات مرورهم في /etc/shadow مع التأكد بأن كل مستخدم يستطيع تغيير كلمة مروره فقط ؟

لحل هذه الاشكالية وُجد برنامج الـ passwd  

لو قمنا بالاطلاع على خصائص هذه الاداة/البرنامج سنجد أنه يحمل الـ Set-UID bit وفي حال تشغيله سيعمل بصلاحية الـ root

ستقوم الـ passwd بتغيير كلمة مرور المستخدم وتحديث القيم في ملف /etc/shadow عوضًا عن إعطاء الصلاحية المباشرة للمستخدم بتعديل الـ /etc/shadow

قد لا يزال يتبادر السؤال في ذهنك مثلي: إذا كانت أداة الـ passwd تعمل بصلاحية الـ root فكيف لا يستطيع المستخدم العادي تغيير كلمة مرور الـ root أو بقية المستخدمين ؟

الاجابة على هذا السؤال توضّح نقطة مهمة جدًا وهي التي تحدث حولها العديد من المشاكل الأمنية المتعلقة بالـ Set-UID Programs

برنامج الـ passwd سيعمل ضمن صلاحيات الـ root كما عرفنا

وجميع ماكُتب من أكواد في هذا البرنامج سيعمل ضمن هذه الصلاحية، فإن تمّت كتابة البرنامج بطريقة ضعيفه مثل عدم التحقق من كلمة مرور المستخدم الحالية (المستخدم الذي قام بتشغيل الأداة) سيكون بإمكان أي مستخدم تغيير كلمة المرور للـ root أو بقية المستخدمين .. وغيرها من المشاكل

لكن مطورين الأداة أخذوا في الحسبان أن هذا البرنامج سيتم تشغيله من قبل مستخدمين أقل صلاحية لكن لأجل مهمة تتطلب صلاحية أعلى، لذلك يوجد العديد من الـ checks ضمن الكود ..

بالامكان الرجوع لصفحة الأداة وفهم آلية عملها .. لكن بشكل مختصر ، لن يستطيع أي مستخدم استغلال الـ passwd لرفع صلاحياته لأن البرنامج بُني بطريقة تتيح للمستخدم تحديث كلمة مروره هو فقط وليس غيره -إلا إن وجد الباحثين مشكلة في البرنامج نفسه-

-        أعتقد هذا الكود الخاص بالأداة للمهتمين 😁

 

Attack Surfaces of Set-UID Programs

عرفنا سابقًا أن الـ Set-UID Programs تُتيح للمستخدم العادي صلاحيات عالية ضمن حدود عملية معينة (Process ) فقط وعرفنا أيضًا أن إمكانية تصعييد الصلاحيات وإستغلال الـ Set-UID Programs مُعتمد بشكل كبير على الكود ومايفعله البرنامج في الأساس .. لكن هل هذا وحده ما يفتح باب للإختراق في الـ Set-UID Programs ؟

في الحقيقة لا .. يوجد عوامل أخرى تؤثر على الـ Set-UID Programs وبالامكان إستغلال هذه العوامل بطريقة تسمح للمستخدم العادي من تصعييد صلاحياته والحصول على صلاحية الـ root

الصورة التالية تُلخّص أبواب الإختراق هذه

كتاب: Computer Security, p: 12

3 –  Environment Variables  : هذه النقطة التي تهمنا في هذه المقالة

 

Attacks Through Environment Variables

قبل أن نعرف كيف تؤثر الـ Environment Variables في الـ Set-UID Programs ماهي الـ Environment Variables في الأساس؟

هي متغيرات باسماء معروفه تحمل قيم معينة (name-value pairs )، هذه المتغيرات ترتبط بـ Process معينة، بالتالي ستؤثر في طبيعة عمل هذه العملية أو البرنامج

الـ Environment Variables في لينكس عدة، ولسنا بصدد سردها هنا ، لكن أحد هذه المتغيرات متغير الـ PATH

هذا المتغير يُخزّن المسارات الخاصة بالـ executable ويستخدمه الـ shell interpreter للوصول الى المسار الخاص بالبرنامج بالتالي تشغيله

حتى نعرف كيف يتم استغلال الـ Environment Variables  وتصعييد الـصلاحيات في الـ Set-UID Programs لنأخذ هذا المثال

الكود التالي لبرنامج بسيط الغرض منه عمل ls لكن لأنه يحمل الـ Set-UID bit سيتم تنفيذ الـ ls  بصلاحية الـ root

 

 

نلاحظ أننا قمنا بتنفيذ الـ ls عبر الـ system

وإن قرأنا بتفصيل عن هذه الدالة سنجد أنها في الأساس تقوم بتشغيل برنامج الـ sh ومن ثم تمرير الـ command

-        كتبت بتفصيل عن هذه الدالة وكيف تعمل هنا

اذًا الـ ls سيتم تنفيذها عبر الـ sh  ونلاحظ أننا في الكود لم نستخدم المسار الكامل ( absolute path ) انما مررنا فقط اسم البرنامج

وهنا تكمن المشكلة .. سنستطيع التأثير على الـ shell interpreter عبر تغيير قيمة الـ PATH واستبدالها بأي برنامج نريده ..

بالتالي عند تشغيل البرنامج في الكود السابق لن يقوم باستخدام الـ ls الافتراضية ، انما سيقرأ قيمة المسار الخاص بهذه الأداة من الـ PATH

سيكون الاستغلال كالتالي

الذي يتم تنفيذه بالفعل هو الـ /bin/bash وليس الـ ls لكن أعدنا تسمية البرنامج بـ ls وقمنا بتغيير قيمة الـ PATH قبل تشغيل البرنامج .. وعند تشغيله نلاحظ أنه بالفعل تم تنفيذ الـ /bin/bash  وحصلنا على الـ root

 

ختامًا، أود الإشارة بأن هذه المقالة تمّت كتابتها خلال دراسة هذه المواضيع، فكل ما تم ذكره هنا قد يحتمل الخطأ، لكن بالإمكان العودة إلى المراجع التي إستندت عليها هذه المقالة

وإن أصبت فمن توفيق الله وحده، وإن أخطأت فمن نفسي والشيطان

 

 

المراجع:

كتب:

-        Computer Security - A hands-on Approach

-        Practical Unix Security