PDA

عرض كامل الموضوع : لمحات من الخبراء للبحث عن عيوب الأمان في الكود



moody
21-07-2004, 02:53 AM
يفترض من هذه المقالة أنك على علم ببرامج Security وC# وVisual Basic.NET.


ملخص

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




تبدأ العملية باختبار البيئة التي يتم بها تشغيل الكود واضعا في الاعتبار أدوار المستخدمين الذين سيقومون بتشغيله ودراسة تاريخ موضوعات الأمان التي قد يحتوي عليها الكود. وبعد التعرف على هذا التاريخ ستكون في حاجة إلى التعرف على المخاطر التي تهدد الأمان بما فيها من الهجمات باستخدام SQL أو إدخال برنامج نصي على موقع الإنترنت أو قيام أحد المستخدمين بتغيير الكود مما يغير من البرنامج كلية. بالإضافة إلى بعض العلامات الحمراء كأسماء المتغيرات مثل :كلمة المرور" و"السر" ولكن هناك بعض أخطاء الأمان الشائعة التي يمكن البحث عنها ومعالجتها.

هناك جزءا كبيرا من الوظيفة يتضمن مراجعة أكواد الغير والبحث عن أخطاء الأمان. لا تعتبر هذه مهمة مراجعة التصميم والتهديد الذي يهدد إعداد هذه التصميمات هي المهمة الأولى في جدول الأعمال بالنسبة لي ولكنني متأكد أن من أنني سوف أرى الكثير من الأكواد.

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

في هذا المقال، أن نناقش طبيعة تهديدات الأمان التي يتعرض لها الكود مثل هجمات تدفق هجمات الأعداد. أو التعرض لهجوم من خلال خادم SQL أو قيام أحد المستخدمين بتغيير الكود مما يغير من البرنامج كلية "تجاوز المخزون المؤقت". يمكنك التعرف على المزيد عن هذه الموضوعات في بعض الكتب مثل ("Writing Secure Code" Microsoft Press®, 2002). بدلا من ذلك فسوف نلقي نظرة فاحصة على الموضوعات التي شاهدتها أثناء مراجعة الكود. قبل البدء في ذلك، أريد أن أشير إلى أن هذه هي الطريقة التي أقوم من خلالها بمراجعة الكود بالنسبة لمشكلات الأمان فهي غير ملزمة لك ولكنها تعتبر من النماذج الكاملة بالنسبة لبعض أنواع المشكلات.

هناك ثلاث طرق لمراجعة الكود وهي:

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


تخصيص الوقت والمجهود

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

هل يتم تشغيل الكود افتراضيا؟
هل يتم تشغيل الكود بالتنقل المتطور من خلالها؟
هل يتم سرد الكود في واجهة الشبكة؟
هل واجهة الشبكة غير موثقة.
هل يتم كتابة الكود بلغة C/C++؟
هل تعرض هذا الكود لأي مشكلات من قبل أم لا؟
هل تم وضع هذا المكون تحت الاختبار من قبل باحثي الأمان؟
هل يقوم الكود بمعالجة بينات خاصة أو حساسة؟
هل يمكن إعادة استخدام الكود (على سبيل المثال، DLL أو عنوان فئة C++ أو المكتبة أو التجميع)؟
على أساس نموذج التهديد، هل هذا المكون في يواجهه بيئة تهديد خطرة أو عرضه للعديد من التهديدات الخطرة؟


إذا كان لديك أحد من هذه الأشياء الموجودة في هذه القائمة، فسوف يكون عليك مراجعة الأكواد بعمق أكبر. في الحقيقة، إذا كان سرد هذه الأكواد يتم من خلال بروتوكول TCP أو بروتوكول UDP ويتم تشغيله افتراضيا، فتأكد أنك سوف تقضي كثيرا من الوقت عند مراجعة هذا الكود.

عندما أقوم بالبحث عن أخطاء الأمان، فإنني أميل إلى مراجعة ثلاث فئات رئيسية من الأكواد مثل كود C/C++ وكود تطبيقات خادم الويب مثل (ASP وASP.NET وCGI وPerl) والكود المنظم مثل (C# وبعض أكواد Visual Basic®.NET)

هناك بعض الاختلافات لكل لغة التي يجب أن تكون على دراية بها. أولا: عدد الموضوعات التي تحتوي على كود C وC++ في تجاوز المخزن المؤقت. هناك أيضا بعض الموضوعات الأخرى ولكن عند سماع كلمة تجاوز وكلمة مخزون مؤقت، في نفس الجملة فأنت تضمن وجود C وC++ حيث أن اللغات ذات المستويات العالية مثل C# وVisual Basic.NET وPerl لا تحتوي على تجاوز للمخزون المؤقت. في حالة وجود أحدهما، يكون الخطأ في بيئة وقت التشغيل ولكن ليس في الكود قيد المراجعة. تستخدم هذه اللغات في كود تطبيقات خوادم الويب وهي عرضه لأنواع أخطاء أخرى. يعتبر تجاوز المخزون المؤقت شيء غير جيد حيث أنه المهاجم يستطيع من خلاله وضع كود في العملية قيد التشغيل والتهجم عليها. لذا دعنا نتحدث عن تجاوز المخزون المؤقت أولا.



تجاوز المخزون المؤقت في C وC++

يعتبر تجاوز المخزون المؤقت من أحد الكوراث على صناعة البرمجيات ويجب القيام بأي شيء لإزالته فورا من الكود ولكن عليك أن تتأكد أنك لا تمس الكود في المقام الأول.

هناك طريقتين أستطيع من خلالهما مراجعة تجاوز المخزون المؤقت وهما. أولا تحديد كل نقاط الإدخال في التطبيق خاصة نقاط إدخال الشبكة وتتبع البيانات عند نقلها خلال الكود والتعرف على كيفية تحويل هذه البيانات. افترض في هذه الحالة أنه تم تشويه كافة البيانات. عند النظر إلى أي كود يمس هذه البيانات ويبقى هذا السؤال (هل هناك نسخة من البيانان يمكن أن تتسبب في فشل الكود؟) لكن هذه الطريقة من الطرق المضيعة للوقت. أحد التقنيات الأخرى هي البحث عن البنايات المحتلمة الخطرة وتتبع البيانات من نقطة الإدخال. على سبيل المثال، الق نظرة على هذا الكود:

void fuction(char *p) {

char buff[16];

•••



strcpy(buff,p);



•••

}

إذا رأيت كود مثل هذا الكود، فسوف تقوم بتتبع المتغير P للخلف إلى مصدره وترى مكان مجيئه هل من مكان آمن أم من مكان غير آمن وهل تم اختبار صلاحيته في النقطة التي تم فيها نسخه ثم عليك بعد ذلك التعرف على إيجاد خطأ الأمان. لاحظ أن النص ذاته لا يعتبر غير آمن أو خطر ولكنها البيانات بداخله هي التي تجعله يبدو على هذا الشكل المزعج. إذا قمت بفحص البيانات ووجدت أنها آمنة، من ثم يكون النص آمنا. أما إذا كنت مخطئ، فهناك بالتأكيد خطا أمان. أقوم أيضا بالتأكد أن احتساب حجم المخزون المؤقت صحيحا.

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

while (*s != '\\')

*d++ = *s++;

تم تقييد هذه الحلقة بواسطة الحرف في المصدر. ولم يتم تقييدها بواسطة حجم الوجهة. لقد قمت بمسح *x++ = *y++ باستخدام التعبير العادي التالي:

\*\w+\+\+\s?=\s?\*\w+\+\+

يمكن للأفراد بالطبع استخدام *x++ = *y++ أيضا، لذا فأنت في حاجة إلى مسح ذلك أيضا. أريد أن أؤكد على أن هذا البناء ليس خطرا بما أن المصدر غير موثوق به وبذلك يمكنك تحديد مدى صحة بيانات المصدر. القسم التالي هو نوع آخر من الموضوعات المرتبطة بتجاوز المخزن المؤقت التي يجب أن تكون على وعي بمدى صلاحية تدفق الأرقام.



تدفق الأرقام في C وC++

إذا لم تكن تعرف ما هو هجوم تدفق الأرقام ولا تعرف كيفية إصلاحها، يجب أن تقرأ المقالات التي تتحدث عن هذا الموضوع.

إن التهديد الفعلي للأمان هو الذي يظهر مع هذه العيوب عند تنفيذ عملية حسابية لاحتساب حجم المخزون المؤقت ويتسبب هذا الاحتساب حينئذ في التدفق أو عدم التدفق. انظر إلى هذه الأمثلة:

void func(char *b1, size_t c1, char *b2, size_t c2) {

const size_t MAX = 48;

if (c1 + c2 > MAX) return;

char *pBuff = new char[MAX];

memcpy(buff,b1,c1);

memcpy(buff+c1,b2,c2);

}

يبدو الكود على ما يرام حتى تكتشف أنه غير ذلك فإذا وضعت C1 وC2 معا وكانت النتيجة خلاف هذه (232-1). على سبيل المثال، عن نتيجة إضافة 0 × FFFFFFF0 و0 × 40 معا تكون 0 × 30 (48 علامة عشرية). عندما تستخدم هذه القيم لـ C1 وC2 يتم تمرير الإضافة إلى فحص الحجم، ويتم نسخ الكود في هذا الحين حوالي 4 GB في مخزن مؤقت بحجم 48 بايت. أنت الآن في مواجهة تجاوز للمخزن المؤقت، فالعديد من الأخطاء مثل هذا الخطأ قد تم تنفيذها مما أتاح للمهاجم وضع كود في العملية الخاصة بك.

عند مراجعة كود C وC++ لتدفق الأرقام، لقد بحثت عن كل الأمثلة عن تشغيل وظائف تخصيص ذاكرة ديناميكية جديدة مثل (alloca, malloc, calloc, HeapAlloc وما إلى ذلك) ثم تحديد كيفية احتساب حجم المخزون المؤقت. ثم أسأل أسئلة كالأسئلة التالية:

هل يمكن للقيم أن تتجمع خلاف بعض أقصى القيم؟
هل يمكن للقيم أن تتجمع خلاف رقم صفر.
هل البيانات غير مكتملة (نسخ قيمة 32 بت في قيمة 16 بت ثم نسخ حجم 32 بت)؟


هناك أحد قواعد القلب التي تم توظيفها من قبل أحد الزملاء في شركة مايكروسوفت: إذا قمت بغداء مسألة رياضية في أحد التعبيرات المستخدمة في أحد المقارنات ثم لديك الاحتمال لدفق البيانات أو إلغاء هذا التدفق. يمكن أن يكون نتيجة ذلك مضاعفة إذا تم استخدام الاحتساب لتحديد حجم المخزون المؤقت خاصة لو أن واحد أو اكثر من عناصر احتساب حجم المخزون المؤقت قد تمت مهاجمته من قبل أحد المهاجمين.



كود قاعدة بيانات الدخول في أي لغة

كقاعدة عامة، يكتب المطورين تطبيقات قواعد البيانات في لغات ذات مستويات عالية مثل C# ولغات النصوص ويكتبون بعضا من الكود بلغتي C وC++، لكن بعض الأفراد يستخدمون مكتبات فئة C وC++ مثل فئة Cdatabase في MFC.

هناك موضوعين يمكن التحدث عنهما. الأول هو سلاسل الاتصال التي تتضمن كلمات مرور hardcoded أو الاتصال باستخدام الحسابات الإدارية. أما الموضوع الثاني فهو الاحتمال للتعرض لهجوم بواسطة خادم SQL.

عندما قمت بالبحث عن الكود المنظم، أول شيء قمت به هو البحث في كل الأكواد بالنسبة لمساحة اسم بيانات النظام خاصة System.Data.SqlClient. تدق أجراس الإنذار عند رؤية هؤلاء. ثانيا، البحث عن كلمات مثل "connect" في الكود (تكون سلسلة الاتصال مرتبطة بهذه الكلمة). تحتوي سلسلة الاتصال على خاصيتين للبحث عنهما وهما: معرف الاتصال (غالبا يكون uid) وكلمة المرور وتكون غالبا (pwd). شيء ما مثل هذا يعتبر ثغرة أمان محتملة الهجوم عليها:

DRIVER={SQL Server};SERVER=hrserver;UID=sa;PWD=$esame

هناك خطأين في هذا المثال وهما. الأول، تم الاتصال كحساب sysadmin (sa). يهزم هذا مبدأ الحصول على أقل تنقل ضروري. لا يجب أن يتصل الكود بقاعدة البيانات كحساب sysadmin لأن مثل هذا الحساب يمكن أن يدمر قاعدة البيانات عندما يستخدم بواسطة الأفراد الذي لهم ميول للتخريب. ثانيا، كلمة المرور hardcoded. يعتبر هذا خطأ لسببين وهما: الأول، لأنه سيتم اكتشافه أما الثاني، ماذا إذا تم تغيير كلمة المرور؟ (يجب في هذه الحالة تحديث كلمة مرور كل العملاء)

الموضوع الثاني في التعرض لهجمات باستخدام خادم SQL. أهم نقاط المشكلة في التعرض لهجوم من قبل خادم SQL هي استخدام سلسلة لبناء بيانات SQL. عند القيام بمسح الكود، قد قمت بالبحث لرؤية المكان الذي تم به إنشاء بيانات SQL. يتضمن ذلك البحث عن كلمات مثل "update" و”select” و”insert” "exec" وأي جدول أو أسماء لقواعد البيانات التي يتم استخدامها. لقد قمت باستخدام ildasm.exe في المجموعة المنظمة تحت التدقيق لمساعدتك:

ildasm /adv /metadata /out:file test.exe

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

استخدام تسلسل السلسلة عند بناء الإجراءات المخزنة لا يعتبر حل لمعالجة الخطأ الذي حدث عند هجوم SQL. باختصار تسلسل السلسلة وبيانات SQL يعتبر شيء سيئ ولكن الأسوأ هو أن يكون بجانبهم حساب sysadmin.



كود صفحات الويب في أي لغة

من أكثر الأخطاء شيوعا في تطبيقات صفحات الويب، موضوعات النصوص عبر الموقع (XSS). بالرغم من وجود موضوعات أخرى لأبحث عنها مثل هجوم SQL والكتابة الفقيرة بالشفرة وإلا أنه مازالت أخطاء XSS شائعة. أساس قابلية XSS للسقوط هو احتمال لعرض إدخالات المستخدم غير الموثوق به في مستعرض الضحية، لذلك أقوم أولا بالبحث عن أي بناء كود يقوم بإرسال البيانات إلى المستخدم. على سبيل المثال، في ASP أقوم بالبحث عن علامات Response. Write and <%= %>. ثانيا، ابحث عن البيانات المكتوبة لكي أتعرف على مصدرها. يكون خطأ XSS موجودا إذا كانت البيانات قادمة من كيان HTTP مثل نموذج أو سلسلة استعلام ولم يتم التأكد من مدى صلاحيتها ويتم إرسالها إلى مستعرض المستخدم. المثال التالي يوضح XSS غير مألوف.

Hello,

<% Response.Write(Request.QueryString("Name")) %>

وكما ترى فإن معامل "Name" يتم إعادة إرساله إلى المستخدم بدون الفحص الأول الصالحة والمعدة جيدا.

الأسرار والشفرات في أي لغة

يميل بعض المطورين إلى تخزين البيانات السرية في الكود، مثل كلمات المرور ومفاتيح الشفرة وإنشاء الشفرات الخاصة بهم ولكن لا تقم بهذا

أقوم أنا أولا بالبحث عن أسماء المتغيرات والوظائف بالأسماء التي تتضمن "key," "password," "pwd," "secret," "cipher," and "crypt." "crypt."

تحتاج أي لمحة إلى تحليل. يمكنك غالبا الحصول على الإيجابيات الخاطئة لـ "Key" ولكن الآخرون يعتبروا جزء لا يتجزأ من البيانات السرية أو أنظمة شفرة "magic". عند البحث عن رموز الشفرة، وأقوم أيضا بالبحث عن مشغلات XOR لأنها الأكثر استخدام في الشفرة. من أسوأ الأكواد هو الكود الذي يستخدم المفتاح المضمن لتدفق بيانات XOR.

عناصر تحكم ActiveX في Visual Basic وC++

دائما ما اسأل عن الميقات الذي أقوم فيه بمراجعة عنصر تحكم ActiveX®. لماذا إذن لم تتم كتابتهم في الكود المنظم؟ فأنا اسأل هذا السؤال لأن الكود المنظم يسمح سيناريوهات الثقة الجزئية، والتي لا يقوم بها ActiveX.

ثانيا، فأنا ابحث عن كل الطرق والخصائص في عنصر التحكم (ملف IDL هو أفضل المصادر لهذا). سوف أضع نفسي في مكان المهاجم ما هو الشيء الذي سوف افعله بكل طريقة أو خاصية؟ عامة، العديد من الطرق التي تسمى بتنسيق VerbNoun مثل ReadRegistry و WriteFile و GetUserNameوNukeKey وبذلك قمت بالبحث عن الأفعال التي لها نطق شاق والأسماء (المصادر).

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

أي شيء يدخل إلى المصادر في جهاز المستخدم يكون عرضه للهجوم.

فأنا أقوم بمزيد من المراجعة إذا تم تعليم عنصر التحكم بعلامة الأمان للنص (SFS) أنها قد تكون حينئذ موجودة في مستعرض الويب بدون تحذير المستخدم. يمكنك تحديد إذا ما كان SFS في حالة تنفيذ واجهة ATL IobjectSafetyImpl أو إعداد فئات "safe for scripting" أو "safe for activation" في وقت التثبيت.

[HKEY_CLASSES_ROOT\CLSID\<GUID>\Implemented

Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}]

[HKEY_CLASSES_ROOT\CLSID\<GUID>\Implemented

Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]

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

ملخص

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

منقول

وتقبلوا خالص تحياتي 8-) 8-)