معهد ماساتشوستس للتكنولوجيا بالطبع "أمن أنظمة الكمبيوتر". المحاضرة 21: تتبع البيانات ، الجزء 3

معهد ماساتشوستس للتكنولوجيا. دورة محاضرة # 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكينز. 2014 سنة


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

المحاضرة 1: "مقدمة: نماذج التهديد" الجزء 1 / الجزء 2 / الجزء 3
محاضرة 2: "السيطرة على هجمات القراصنة" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 3: "تجاوزات المخزن المؤقت: المآثر والحماية" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 4: "الفصل بين الامتيازات" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 5: "من أين تأتي أنظمة الأمن؟" الجزء 1 / الجزء 2
المحاضرة 6: "الفرص" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 7: "صندوق حماية العميل الأصلي" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 8: "نموذج أمان الشبكة" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 9: "أمان تطبيق الويب" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 10: "الإعدام الرمزي" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 11: "أور / لغة برمجة الويب" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 12: الجزء 1 من أمان الشبكة / الجزء 2 / الجزء 3
المحاضرة 13: "بروتوكولات الشبكة" الجزء 1 / الجزء 2 / الجزء 3
محاضرة 14: "SSL و HTTPS" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 15: "البرامج الطبية" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 16: "هجمات القناة الجانبية" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 17: "مصادقة المستخدم" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 18: "تصفح الإنترنت الخاص" الجزء 1 / الجزء 2 / الجزء 3
محاضرة 19: "شبكات مجهولة" الجزء 1 / الجزء 2 / الجزء 3
المحاضرة 20: "أمن الهاتف المحمول" الجزء 1 / الجزء 2 / الجزء 3
محاضرة 21: "تتبع البيانات" الجزء 1 / الجزء 2 / الجزء 3

الطالب: إذن ، الدعم المعماري هو الحل المثالي؟

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



الطالب: ماذا تفعل TaintDroid بالمعلومات التي تستند إلى أذونات فرع git ، أذونات الفرع؟

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

الطالب: أتساءل عما إذا كان يمكن أن تحدث الفيضانات العازلة هنا ، لأن هذه الأشياء - المتغيرات والتهاباتها - تتراكم معًا؟

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

الطالب: أعتقد أن كل هذا يمكن التنبؤ به؟

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

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



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

الآن دعنا نعود إلى سؤالك حول كيف يمكننا تتبع التدفقات التي تتدفق عبر فروع الفرع. سيقودنا ذلك إلى موضوع يسمى التدفقات الضمنية أو التدفقات الضمنية. يحدث الدفق الضمني عادة عندما يكون لديك قيمة مصابة تؤثر على كيفية تعيين متغير آخر ، حتى إذا كان متغير الدفق الضمني لا يعين متغيرات مباشرة. سأقدم مثالًا ملموسًا.
افترض أن لديك عبارة if التي تبحث في IMEI الخاص بك وتقول: "إذا كان أكبر من 42 ، فسوف أقوم بتعيين x = 0 ، وإلا فسأعين x = 1."

ومن المثير للاهتمام ، أننا ننظر أولاً إلى بيانات IMEI السرية ومقارنتها برقم معين ، ولكن بعد تعيين x ، لا نخصص أي شيء يمكن الحصول عليه مباشرة من هذه البيانات السرية.



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

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

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



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

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

إذن ماذا يعني هذا على مستوى التنفيذ؟ هذا يعني أنه من أجل الوصول إلى هنا ، يجب أن يحتوي الكمبيوتر الشخصي على شيء مصاب ببيانات سرية. وهذا يعني أنه يمكننا القول أننا تلقينا هذه البيانات لأن جهاز الكمبيوتر مثبت هنا - x = 0 - أو هنا - x = 1.

بشكل عام ، يمكن للمرء أن يتخيل أن النظام سيجري بعض التحليلات ويكتشف أن جهاز الكمبيوتر الخاص بالتدفقات الضمنية غير مصاب في هذا المكان ، ثم ينتقل العدوى من IMEI ، وعند هذه النقطة يكون x = 0 ، الكمبيوتر مصاب بالفعل. في النهاية ، ما يحدث هو أنه إذا كان x متغيرًا يتم عرضه في البداية دون تلوث ، فنحن نقول: "حسنًا ، في هذه المرحلة x = 0 ، نحصل على العدوى من جهاز الكمبيوتر ، الذي تم بالفعل إصابة أعلاه ، في IMEI". هناك بعض التفاصيل الدقيقة هنا ، ولكن بشكل عام ، يمكنك تتبع كيفية تثبيت جهاز الكمبيوتر ثم يحاول نشر العدوى إلى المشغلين المستهدفين.

هل هذا واضح؟ إذا كنت تريد معرفة المزيد ، فيمكننا الحديث عن هذا الموضوع لأنني أجريت الكثير من الأبحاث من هذا النوع. ومع ذلك ، قد يكون النظام الذي وصفته للتو متحفظًا جدًا. تخيل أنه بدلاً من x = 1 ، هنا ، كما ذكر أعلاه ، لدينا أيضًا x = 0. في هذه الحالة ، لا معنى لإصابة x بشيء يتعلق بـ IMEI ، وبالتالي لا يمكن أن تتسرب أي معلومات من هذه الفروع.

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

الطالب: عند الخروج من العبارة if ، يمكنك أيضًا الخروج من الفرع ، وأنت تخلصك من الإصابة؟

الأستاذ: كقاعدة عامة ، نعم ، بمجرد انتهاء مجموعة المتغيرات ، سيتم تنظيف الكمبيوتر من العدوى. يتم إنشاء العدوى فقط داخل هذه الفروع من x إلى x. والسبب هو أنه عندما تنزل هنا ، فإنك تفعل ذلك بغض النظر عن IMEI.



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

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

كما قلت ، من الميزات المفيدة لـ TaintDroid أنه يحد من "كون" مصادر العدوى وامتصاص المعلومات المصابة. ولكن كمطور ، ربما تحتاج إلى تحكم أكثر دقة في علامات الإصابة التي يتفاعل معها البرنامج. لذلك ، كمبرمج ، سوف تحتاج إلى القيام بما يلي.
لذلك ، أنت تعلن بعض الباحثين عن هذا النوع وتسميته X ، ثم قم بربط الملصق به. إن معنى هذه التسمية هو أن Alice هي مالك المعلومات التي تسمح لـ Bob بعرضها ، أو أن هذه المعلومات مخصصة للعرض بواسطة Bob. لا يسمح لك TaintDroid بالقيام بذلك ، لأنه يتحكم بشكل أساسي في هذا الكون من العلامات ، ولكن كمبرمج ، قد ترغب في القيام بذلك.

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



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



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

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

على مستوى عالٍ ، يمكن أن يشهد الفحص الثابت العديد من هذه الأخطاء ، لأن مثل هذه التعليقات {Alice  Bob} x تشبه أنواعًا إلى حد ما. تمامًا كما يستطيع المترجمون التقاط الأخطاء المتعلقة بالأنواع في لغة الكتابة ، فيمكنهم العمل أيضًا مع الشفرة المكتوبة باللغة أعلاه ، قائلين إنه إذا قمت بتشغيل هذا البرنامج ، فقد تكون مشكلة. لذلك ، تحتاج إلى إصلاح طريقة عمل التسميات ، وقد تحتاج إلى إزالة السرية عن شيء ما ، وما إلى ذلك.

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



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

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

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

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

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

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



تخيل أنك بصدد محاولة الوصول إلى ملف البريد الإلكتروني الخاص بك. يولد النظام هذه العملية الجديدة ، doppelganger ، تمامًا مثل الأصل ، ولكنه الآن يقرأ البيانات التي تم تنظيفها بدلاً من البيانات الحساسة الحقيقية. بشكل أساسي ، تدير TightLip كلتا العمليتين بشكل متوازٍ وتراقبهما لمعرفة ما الذي يقومون به. , , , . , , - , , – , , , -, .



, , TightLip , . , . , , , , . , TaintDroid, , : «, , , , - ».

, , , - . TaintDroid, , - , . — , — . , , , , , .

: , - Word, , - .

: , . , . . Word. - , - , . .

: , , ? - .

: , . , , , - , . , . «» , , , .

, , , , , , , .



– , TightLip TCB, , -, . , . . , , . TightLip.
, . taint .

: , ? , ?

: ! - DG , , . , , , -, , .

, .


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? لدينا فقط 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD بسرعة 1 جيجابت في الثانية 100 TV من 249 دولارًا في هولندا والولايات المتحدة الأمريكية!اقرأ عن كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟

Source: https://habr.com/ru/post/ar433380/


All Articles