ثغرة الصفر (0 يوم) هي ثغرة أمنية في برامج الكمبيوتر مقدمة أثناء عملية التطوير ولم يكتشفها المطورون حتى الآن. يمكن استغلال نقاط الضعف في يوم الصفر من قبل المتسللين ، مما يؤثر على سمعة الشركة. يجب أن يسعى المطورون إلى تقليل عدد العيوب التي تؤدي إلى هذه الثغرات. يعد PVS-Studio ، محلل الكود الثابت لرمز C و C ++ و C # و Java ، أحد الأدوات القادرة على اكتشاف مشكلات الأمان.
نقاط الضعف في اليوم صفر
مشكلة
عدم الحصانة في يوم صفر (تُعرف أيضًا باسم مشكلة عدم حصانة
0 يومًا ) هي مشكلة عدم حصانة في برامج الكمبيوتر غير معروفة أو غير موجهة لهؤلاء الذين يجب أن يكونوا مهتمين بالتخفيف من مشكلة عدم الحصانة (بما في ذلك بائع البرنامج المستهدف). حتى يتم تخفيف الثغرة الأمنية ، يمكن للمتسللين استغلالها للتأثير سلبًا على برامج الكمبيوتر أو البيانات أو أجهزة الكمبيوتر الإضافية أو الشبكة. هذا المصطلح يعني أن المطورين لا يملكون يومًا واحدًا لإصلاح الخلل لأنه لا أحد يعرف ذلك بعد. تأثرت بعض نقاط الضعف في اليوم السابق ببعض البائعين المعروفين مثل منتجات البرامج ، مثل
Adobe و
Windows و
Browser Tor وكثير غيرهم.
لقد حالفهم الحظ في العثور على ثغرة أمنية أبلغ عنها أشخاص لم يستغلوها. حالة
MacOS هي أحد الأمثلة على ذلك. في بعض الحالات الأخرى ، أنتج المطورون أنفسهم تصحيحًا ، مع إضافة ميزات جديدة ، قاموا أيضًا بتثبيت ثغرة أمنية في اليوم صفر دون معرفة ذلك.
وكان آخرون أقل حظا رغم ذلك. على سبيل المثال ، منذ وقت ليس ببعيد ، كان على Google Chrome إصلاح مشكلة عدم
الحصانة التي يمكن استغلالها لتنفيذ التعليمات البرمجية التعسفية عن بُعد.
المشكلة هي أنه لا يمكنك ضمان حماية بنسبة 100٪ ضد هذه الثغرات حيث لا يمكنك محاربة تهديد لا تعرفه حتى. ومع ذلك ، هناك طرق لجعل حدوث مثل هذه العيوب أقل احتمالا في برنامجك - سيكون هذا موضوع هذا المقال ، لكن يجب أن نلقي نظرة على بعض النظريات أولاً.
تحليل ثابت
التحليل الثابت هو طريقة للتحقق من الكود المصدري لبرنامج ما باستخدام محلل دون تنفيذ البرنامج نفسه ويمكن أن ينظر إليه على أنه مراجعة أوتوماتيكية للكود. في بعض الأحيان ، قد يكون التحليل الثابت أكثر فاعلية من مراجعة رمز النظير ، لكن لا يمكن استبداله تمامًا. حاولت أن ألخص إيجابيات وسلبيات مراجعة الكود والتحليل الثابت بالنسبة لبعضهم البعض في الجدول التالي:
CVE و CWE
نقاط الضعف الشائعة والتعرض (CVE) هي قاعدة بيانات لأوجه الضعف والتعرض لأمن المعلومات. كان غرضها الأولي تنظيم عيوب البرامج المعروفة في قائمة متماسكة. في الماضي ، كانت معظم أدوات أمن المعلومات تستخدم قواعد البيانات الخاصة بها وأسماء مثل هذه العيوب ، وكان من أجل تحقيق الفوضى وتحقيق التوافق بين الأدوات المختلفة التي طورتها شركة MITER Corporation CVE في عام 1999. ومع ذلك ، تحولت CVE إلى تكون غير كافية لتقدير أمان الكود. هناك حاجة إلى نظام آخر ، مع تصنيف أدق وأوصاف أكثر تفصيلا. هذه هي الطريقة التي ظهر بها تعداد الضعف المشترك (CWE). إذا تم سرد عيب في CWE ، فقد يتسبب ذلك في ثغرة أمنية قابلة للاستغلال والإضافة إلى قائمة CVE أيضًا. يوضح مخطط أويلر أدناه العلاقات بين المعايير.
يمكن لبعض المحللات الثابتة أن تبلغك ، على سبيل المثال ، إذا كان مشروعك يستخدم مكتبة تحتوي على ثغرة أمنية. مع العلم بذلك ، يمكنك تنزيل إصدار أحدث من المكتبة ، مع إصلاح الخلل ، لجعل الكود أقل عرضة للتهديدات الأمنية الناجمة عن خطأ في رمز شخص آخر.
نظرًا لاحتضان مجتمع المطورين لمعايير CVE و CWE ، فقد تم دعمها أيضًا من قبل العديد من أدوات أمن المعلومات بما في ذلك أجهزة التحليل الثابتة. يمكن عرض التحليلات التي تدعم هذه التصنيفات على أنها حلول SAST. يتيح SAST (اختبار أمان التطبيق الثابت) للمطورين اكتشاف نقاط الضعف في التعليمات البرمجية المصدر للبرامج في المراحل المبكرة من دورة حياة تطوير البرامج.
يعد SAST ممارسة أخرى لتقليل احتمالية حدوث ثغرات أمنية في اليوم صفر في مشروعك. يمكن للمحلل الذي يدعم معيار CWE أن يخبرك بمكان وجود ثغرة أمنية محتملة حتى تتمكن من إصلاحه لجعل تطبيقك أكثر موثوقية وأقل احتمالا أن يحتوي على تهديد لمدة 0 يوم.
هناك مجموعة متنوعة من أدوات SAST.
سأأخذ محلل
PVS-Studio كمثال لإظهار كيف يمكن لهذه الأدوات المساعدة في مكافحة الثغرات الأمنية. يتم تصنيف تحذيرات هذا المحلل على أنها CWE. بعض الأمثلة ترد أدناه.
رسالة تشخيص PVS-Studio:
CWE-561 : Dead Code (
V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
يحتوي هذا الرمز على خطأ مطبعي: شروط كلاهما
إذا تحقق عبارات المتغير نفسه. تشير الرسالة المصاحبة للاستثناء إلى أن الشرط الثاني يجب أن يتحقق من متغير
outputPath بدلاً من ذلك. جعل هذا الخطأ جزءًا من الكود غير قابل للوصول.
قد تبدو الأخطاء من هذا القبيل غير مؤذية ، لكن هذا الانطباع خاطئ. دعونا نلقي نظرة على خطأ آخر تافه وغير ضار على ما يبدو له علاقة مع بيان
غوتو مكررة.
تسبب هذا الخطأ مرة واحدة في ثغرة أمنية في نظام التشغيل iOS.
مشكلة عدم حصانة
CVE-2014-1266 : وظيفة SSLVerifySignedServerKeyExchange في libsecurity_ssl / lib / sslKeyExchange.c في ميزة "النقل الآمن" في مكون "أمان البيانات" في مكون Apple iOS 6.x قبل الإصدار 6.1.6 و 7.x قبل الإصدار 7.0.6 و Apple TV 6.x قبل الإصدار 6.0.2 ، و Apple OS X 10.9.x قبل الإصدار 10.9.2 لا يتحقق التوقيع في رسالة TLS Server Key Exchange ، والتي تسمح للمهاجمين في الوسط بانتحال خوادم SSL باستخدام تعسفي المفتاح الخاص لخطوة التوقيع أو حذف خطوة التوقيع.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
كما في المثال الأول ، أدت الصورة المكررة هنا إلى رمز يتعذر الوصول إليه: بغض النظر عن شروط العبارة
if ، سيتم تنفيذ عبارة
goto الثانية على أي حال. ونتيجة لذلك ، لن يتم التحقق من التوقيع ، وستعود الوظيفة إلى 0 ، مما يعني أن التوقيع على ما يرام ، وسيتلقى البرنامج مفتاحًا من الخادم حتى إذا فشل التحقق من التوقيع. يستخدم هذا المفتاح لتشفير البيانات التي يتم إرسالها.
وكان هذا الخطأ تافهة آثارا جذرية. يوضح الحادث سبب عدم وجود نقطة للتكهن بما إذا كان عيب CWE هذا أو ذاك خطيرًا أم لا - عليك فقط إصلاحه من أجل سلامة الشفرة.
بالمناسبة ، كان بإمكان PVS-Studio العثور على هذا الخطأ بسهولة ، حيث أبلغ عن ذلك بتحذيرين من CWE في آن واحد:
هنا مثال آخر. منذ فترة طويلة ، في عام 2012 ، تم اكتشاف مشكلة أمنية في MySQL ، والتي يمكن استغلالها بواسطة مهاجم لإدخال قاعدة بيانات MySQL. أدناه سترى جزء التعليمات البرمجية المعيبة ، حيث حدثت مشكلة عدم الحصانة.
مشكلة عدم حصانة
CVE-2012-2122 : sql / password.c في Oracle MySQL 5.1.x قبل 5.1.63 و 5.5.x قبل 5.5.24 و 5.6.x قبل 5.6.6 و MariaDB 5.1.x قبل 5.1.62 و 5.2.x قبل 5.2.12 و 5.3.x قبل 5.3.6 و 5.5.x قبل 5.5.23 ، عند التشغيل في بيئات معينة مع تطبيقات معينة لوظيفة memcmp ، يسمح للمهاجمين عن بُعد بتجاوز المصادقة عن طريق المصادقة بشكل متكرر مع نفس كلمة المرور غير الصحيحة ، والتي تؤدي أخيرًا إلى نجاح مقارنة الرمز المميز نظرًا لقيمة الإرجاع المحددة بشكل غير صحيح.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
تقوم دالة
memcmp بإرجاع قيمة type
int ، بينما ترجع الدالة
check_scramble قيمة type
my_bool ، والتي هي في الواقع
char . تحصل القيمة
int ضمنيًا على
char ، مع اقتطاع البتات الأكثر أهمية. تسبب هذا في محاولة واحدة من أصل 256 محاولة لتسجيل الدخول باستخدام كلمة مرور تعسفية لنجاح اسم مستخدم معروف.
مرة أخرى ، كان من الممكن تحييد عيب CWE هذا ومنعه من أن يصبح ثغرة CVE في وقت مبكر ، في مرحلة الترميز. على سبيل المثال ، تقارير PVS-Studio عن ذلك كـ
CWE-197 (
V642 ): خطأ اقتطاع رقمي.
راجع مقالة "
كيف يمكن لـ PVS-Studio المساعدة في اكتشاف نقاط الضعف؟ " لمزيد من القراءة حول هذا الموضوع.
استنتاج
لا يمكنك أن تكون متأكدًا بنسبة 100٪ من أن البرنامج آمن من الثغرات الأمنية التي تظهر على مدار اليوم ولكن لا يزال بإمكانك جعلها أقل عرضة للتحدث. يتم ذلك باستخدام أدوات SAST المتخصصة مثل PVS-Studio. إذا وجد أن مشروعك يحتوي على عيوب تصنف على أنها مشكلات في CWE ، فتأكد من إصلاحها. على الرغم من أن القليل من عيوب CWE ينتهي في قائمة CVE ، فإن إصلاحها يساعد في تأمين البرنامج من العديد من التهديدات المحتملة.
مراجع
- قم بتنزيل وتقييم PVS-Studio
- التقنيات المستخدمة في محلل كود PVS-Studio للعثور على الأخطاء ونقاط الضعف المحتملة
- تصنيف تحذيرات PVS-Studio وفقًا لتعداد الضعف الشائع (CWE)
- تصنيف تحذيرات PVS-Studio وفقًا لمعيار الترميز SEI CERT