ما مدى خطورة هذه الثغرة الأمنية الجديدة في ASP.NET وكيف يمكنني حلها؟



4 Answers

فهم الحشو أوراكل الهجمات

لنفترض أن تطبيقك يقبل سلسلة مشفرة كمعلمة - سواء كانت المعلمة عبارة عن ملف تعريف ارتباط أو معلمة url أو أي شيء آخر غير جوهري. عندما يحاول التطبيق فك تشفيرها ، هناك 3 نتائج محتملة -

  1. النتيجة 1 : تم فك تشفير السلسلة المشفرة بشكل صحيح ، وتمكن التطبيق من فهمها. بمعنى ، إذا كانت السلسلة المشفرة رقم حساب 10 أرقام ، بعد فك التشفير وجد التطبيق شيئًا مثل "1234567890" وليس "abcd1213ef"

  2. النتيجة 2 : كانت الحشوة صحيحة ، ولكن بعد فك تشفير السلسلة التي تم الحصول عليها كانت رطانة لا يمكن أن يفهمها التطبيق. على سبيل المثال ، تم فك تشفير السلسلة إلى "abcd1213ef" ، لكن التطبيق كان يتوقع أرقامًا فقط. ستعرض معظم التطبيقات رسالة مثل "رقم حساب غير صالح".

  3. النتيجة 3 : كانت الحشو غير صحيحة ، وألقى التطبيق نوعًا من رسائل الخطأ. تعرض معظم التطبيقات رسالة عامة مثل "حدث خطأ ما".

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

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

ما الذي يمكن فعله لمنع ذلك؟

  1. أبسط شيء - يجب ألا يتم إرسال أي شيء حساس إلى العميل ، مشفر أو غير مشفر. يبقيه على الخادم.

  2. تأكد من أن النتيجة 2 والنتيجة 3 في القائمة أعلاه تظهر نفسها تمامًا للمهاجم. يجب أن تكون هناك طريقة لمعرفة واحد من الآخر. هذا ليس كل ذلك بسهولة ، على الرغم من - يمكن للمهاجم التمييز باستخدام نوع من الهجوم توقيت.

  3. كخط دفاع أخير ، يكون لديك جدار حماية تطبيق ويب. يحتاج هجوم oracle padding إلى جعل عدة طلبات تبدو متشابهة تقريبًا (تغيير بت واحد في كل مرة) ، لذا يجب أن يكون من الممكن لـ WAF التقاط هذه الطلبات ومنعها.

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

Question

لقد قرأت للتو على شبكة الإنترنت حول ثغرة أمنية اكتشفت حديثا في ASP.NET. يمكنك قراءة التفاصيل هنا.

تكمن المشكلة في الطريقة التي تنفذ بها ASP.NET خوارزمية تشفير AES لحماية سلامة ملفات تعريف الارتباط التي تنتجها هذه التطبيقات لتخزين المعلومات أثناء جلسات المستخدم.

هذا شيء غامض بعض الشيء ، ولكن هنا جزء مخيف:

تستلزم المرحلة الأولى من الهجوم بضعة آلاف من الطلبات ، ولكن بمجرد نجاحها ويحصل المهاجم على المفاتيح السرية ، يكون التخفي كليًا. معرفة التشفير المطلوبة أساسية جدًا.

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

لذا ، إذا كان جميع مطوري ASP.NET يخشون هذه التقنية التي يمكن أن تمتلك أي موقع ASP.NET في ثوانٍ أم ماذا؟

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

شكرا لإجاباتك!

تحرير: اسمحوا لي تلخيص الردود التي حصلت عليها

لذلك ، هذا هو في الأساس نوع الهجوم "الحشو أوراكل". @Sri قدمت تفسيرا كبيرا حول ماذا يعني هذا النوع من الهجوم. إليك فيديو مروع حول المشكلة!

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

  • في حالة وجود مفتاح جهاز التطبيق ، يمكن للمهاجم فك تشفير ملفات تعريف الارتباط المصادقة.
  • والأسوأ من ذلك ، يمكنه إنشاء ملفات تعريف ارتباط مصادقة باسم أي مستخدم. وبالتالي ، يمكن أن يظهر كأي شخص في الموقع. يتعذر على التطبيق التفريق بينك وبين الهاكر الذي أنشأ ملف تعريف ارتباط مصادقة يحمل اسمك لنفسه.
  • كما أنه يسمح له بفك تشفير (وكذلك إنشاء) ملفات تعريف الارتباط للجلسة ، على الرغم من أن هذا ليس بنفس خطورة السابقة.
  • ليس خطيرًا: يمكنه فك تشفير ViewState المشفر للصفحات. (إذا كنت تستخدم ViewState لتخزين بيانات واثقة ، فلا يجب عليك القيام بذلك على أي حال!)
  • غير متوقع تمامًا : مع معرفة مفتاح الآلة ، يمكن للمهاجم تنزيل أي ملف تعسفي من تطبيق الويب الخاص بك ، حتى تلك التي لا يمكن تنزيلها عادةً! (بما في ذلك Web.Config ، وما إلى ذلك)

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

الآن ، دعونا نركز على هذه القضية.

الحل

  • تمكين customErrors وإنشاء صفحة خطأ واحدة تتم إعادة توجيه جميع الأخطاء إليها. نعم ، حتى 404 . (قال ScottGu أن التفريق بين 404 و 500s ضروري لهذا الهجوم.) أيضا ، في Application_Error الخاص بك أو Error.aspx وضع بعض التعليمات البرمجية التي تجعل تأخير عشوائي. (إنشاء رقم عشوائي ، واستخدام Thread.Sleep للنوم لفترة طويلة.) وهذا سيجعل من المستحيل للمهاجم أن يقرر ما حدث بالضبط على الخادم الخاص بك.
  • أوصى بعض الأشخاص بالرجوع إلى 3DES. نظريًا ، إذا كنت لا تستخدم AES ، فإنك لا تواجه الضعف الأمني ​​في تنفيذ AES. كما اتضح ، لا ينصح بهذا على الإطلاق .

بعض الأفكار الأخرى

  • يبدو أن not everyone يعتقد أن الحل جيد بما فيه الكفاية.

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




المنظمة البحرية الدولية ، لا يوجد منع شامل لهذا ، يجب التعامل معها على أساس كل حالة على حدة:

not




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

فقط أريد الحصول على بعض الحقائق مباشرة:

  1. لا يسمح لك الهجوم بالحصول على مفتاح الماكينة مباشرة. ومع ذلك ، فإنه يشبه إلى حد كبير ما كان عليه ، حيث أنه يسمح بفك تشفير الرسائل ، وتعديل إعادة / تشفير الرسائل الجديدة.
  2. طريقة الحصول على المفاتيح الفعلية باستخدام قدرتها على تعديل إعادة / تشفير كما في 1 والحصول على web.config. للأسف هناك أسباب تجعل البعض يضعون هذه المفاتيح في web.config على مستوى الموقع (مناقشة مختلفة) ، وفي نموذج الفيديو يستفيدون من كونه التقصير في DotnetNuke.
  3. للحصول على web.config كل ما يشير إلى أنهم يستخدمون webresources.axd و / أو scriptresources.axd. اعتقدت أن هذه تعمل فقط مع الموارد المضمنة ، ولكن يبدو أن الأمر ليس كذلك.
  4. إذا كان التطبيق هو asp.net MVC لا نحتاج حقًا إلى webresources.axd و / أو scriptresources.axd ، لذا يمكن إيقاف تشغيلها. نحن أيضا لا نستخدم Viewstate. ومع ذلك ، فإنه غير واضح بالنسبة لي إذا كان أي من ميزات asp.net الأخرى يعطي معلومات مختلفة مع الحل البديل في مكان ، أي لا أعرف ما إذا كان الحشو يعطي نتائج غير صحيحة في الخطأ أثناء الحشو نتائج صحيحة في بطاقة مصادقة تم تجاهلها (لا أعرف إذا كانت الحالة الخاصة به أم لا) ... يجب أن ينطبق التحليل نفسه على ملف تعريف الارتباط للجلسة.
  5. أدوار caches الموفر عضوية asp.net "في ملفات تعريف الارتباط ، إيقاف ذلك.

حوالي 1 ، afaik الرسائل المشفرة لا يمكن أن تكون حاجة 100 ٪ التعسفية لتحمل قطعة صغيرة من القمامة في مكان ما في الرسالة ، حيث يوجد كتلة واحدة في الرسالة التي فك تشفير القيمة التي لا يمكن السيطرة عليها.

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

المزيد على:

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

تم توقيع ملف تعريف الارتباط الخاص بالمصادقة ، ومن المعلومات الموجودة في الورق ، لن يكون بمقدورهم إنشاء ملف تعريف ارتباط موقّع إذا لم يصلوا إلى المفاتيح الفعلية (كما فعلوا في الفيديو قبل تزوير ملف تعريف الارتباط auth cookie).

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




هنا هو استجابة MS. كل ذلك يتلخص في "استخدام صفحة خطأ مخصصة" ولن تتنازل عن أي أدلة.

تصحيح
هنا بعض معلومات أكثر تفصيلا من سكوتجو.







Related