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

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

سياسة الأصل من نفس

سياسة الأصل من نفس (SOP) هي حجر الزاوية في أمن المستعرض الذي أدخلته Netscape في عام 1995. الفكرة وراءها بسيطة: يجب ألا تكون البرامج النصية من صفحات الويب لأصل واحد قادرة على الوصول إلى البيانات من صفحة ويب ذات أصل آخر. على سبيل المثال ، لا أحد يريد أن تتمكن صفحات ويب تعسفية من قراءة بريد الويب المسجلة حاليًا. بحيث يمكن تمييز مواقع الويب عن التالي ، يتم تعريف كل منها بمجموعة من البروتوكول (المخطط) ، والمضيف (اسم DNS) ، ورقم المنفذ. أي عدم تطابق في هذه الأجزاء الثلاثة يجعل الأصل مختلفًا.

على سبيل المثال ، بالنسبة لصفحة الويب: https://www.somedomain.com/sub/page.html مقارنات الأصل الممكنة هي ما يلي:

عنوان URL	حصيلة	سبب
https://www.somedomain.com:81/sub/page.html	مختلف	لا يتطابق المنفذ 81 443 (الافتراضي لـ HTTPS)
https://somedomain.com/sub/page.html	مختلف	بالضبط www.somedomain.com المباراة مطلوبة
http://www.somedomain.com:443/sub/page.html	مختلف	المخطط (البروتوكول) HTTP لا يتطابق مع HTTPS
https://www.somedomain.com/admin/login.html	نفس	يختلف المسار فقط

الهجوم: DNS Rebinding

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

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

على سبيل المثال ، إذا كان المهاجم يمتلك اسم المجال somesite.com ومندوبها إلى خادم DNS تحت سيطرة المهاجمين ، قد يستجيبون في البداية لبحث DNS مع عنوان IP عام ، مثل 172.217. 22.14 ، ثم قم بتبديل عمليات البحث اللاحقة إلى عنوان IP لشبكة محلية ، مثل 192.168.0.1 أو 127.0.0.1 (أي LocalHost). جافا سكريبت محملة من الأصل somesite.com سيتم تشغيل جانب العميل في المتصفح ، وجميع الطلبات الإضافية منه إلى somesite.com سيتم توجيهها إلى عنوان IP الجديد ، المحلي الآن. ومنذ ذلك الحين ، ستعتبر المستندات المحملة من عناوين IP مختلفة – ولكن تم حلها من نفس المضيفين – من نفس الأصل. وهذا يمنح المهاجمين القدرة على التفاعل مع الشبكة المحلية للضحية عبر جافا سكريبت في متصفح الضحية. هذا يجعل أي تطبيق ويب يعمل محليًا على نفس الجهاز أو الشبكة المحلية مثل متصفح الضحية المتاحة للبرامج النصية المحملة من somesite.com أيضاً.

أحد الصيد هو أنه إذا كان تطبيق الويب يتطلب مصادقة ، فلن يتم توفير ملفات تعريف الارتباط الخاصة به للمهاجم. منذ فتح المستخدم المستهدف في الأصل somesite.com– وعلى الرغم من أن طلبات JavaScript اللاحقة موجهة إلى عنوان الانتعاش الجديد للمهاجم ، لا يزال المتصفح يعمل في سياق somesite.com أصل. هذا يعني أن متصفح الضحية لن يستخدم المصادقة المخزنة أو سياق الجلسة لاسم الخدمة المستهدف محليًا.

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

الاستجابة: التخزين المؤقت

تحاول المستعرضات مقاومة DNS لإعادة التشويش على هذا النحو عن طريق تخزين استجابات DNS ، لكن الدفاع بعيدًا عن الكمال. نفذت بعض المتصفحات وصول الشبكة المحلية (المعروف أيضًا باسم CORS-RFC1918) ، مسودة مواصفات W3C جديدة. لقد أغلقت بعض السبل ، لكنها لا تزال تترك بعض التجاوزات ، مثل عنوان IP 0.0.0.0 على Linux و MacOS ، وبالتالي فإن سلوك إعادة صياغة DNS يعتمد على متصفح ونظام التشغيل (OS). هناك العديد من الطبقات المتورطة (ذاكرة التخزين المؤقت DNS للمتصفح ، وذاكرة التخزين المؤقت OS DNS ، ومحفزات أسماء DNS) بحيث يعتبر الهجوم غالبًا غير موثوق به ولا يعتبر تهديدًا حقيقيًا. ومع ذلك ، هناك أيضًا أدوات يمكنها أتمتة الهجمات مثل Tavis Ormandy’s خدمة إعادة صياغة DNS بسيطة أو nccgroup’s تفرد الأصل.

ضعف العالم الحقيقي

الآن دعونا نتعرف على الجوانب الفنية لضعف العالم الحقيقي الموجود في عميل BitTorrent غمر (ثابت في v2.2.0) وكيف كان يمكن استخدام DNS Rebinding لاستغلاله.

يدعم عميل BitTorrent الطوفان البدء خدمتان على التمهيد النظام: Daemon و Webui. قد يتم أيضًا بدء تشغيل خدمة تطبيق Webui Web عن طريق تمكين المكون الإضافي لـ WebUI (مثبت ، ولكن تم تعطيله افتراضيًا) في مربع الحوار تفضيلات عميل الطوفان. من المريح أيضًا تشغيل تطبيق WebUI بشكل دائم على خادم في الشبكة المحلية. لقد وجدنا اجتياز المسار في نقطة نهاية غير مصادفة لتطبيق الويب الذي سمح بقراءة الملف التعسفي.

def render(self, request):
	log.debug('Requested path: %s', request.lookup_path)
	lookup_path = request.lookup_path.decode()
	for script_type in ('dev', 'debug', 'normal'):
		scripts = self.__scripts(script_type)('scripts')
		for pattern in scripts:
			if not lookup_path.startswith(pattern): # <-- (1)
				continue

			filepath = scripts(pattern)
			if isinstance(filepath, tuple):
				filepath = filepath(0)

			path = filepath + lookup_path(len(pattern) :) # <-- (2)

			if not os.path.isfile(path):
				continue

			log.debug('Serving path: %s', path)
			mime_type = mimetypes.guess_type(path) # <-- (4)

			request.setHeader(b'content-type', mime_type(0).encode()) # <-- (5)
			with open(path, 'rb') as _file: # <-- (3)
				data = _file.read()
			return data

ال /js نقطة النهاية من مكون Webui لم يتطلب المصادقة ، لأن الغرض منه هو خدمة ملفات JavaScript لواجهة المستخدم. ال request.lookup_path تم التحقق من صحة لبدء كلمة رئيسية معروفة (1) ، ولكن كان يمكن تجاوزها مع /js/known_keyword/../... حدث اجتياز المسار في (2) ، عندما تم تسلسل المسار واستخدم لاحقًا لقراءة ملف (3). كان القيد الوحيد mimetypes.guess_type اتصل على (4) ، لأنه في حالة إرجاع نوع التمرير Noneو request.setHeader في (5) يلقي استثناء.

سمحت المسار عبر القراءة غير المصادقة لأي ملف على النظام طالما تم التعرف على نوع MIME.

حتى لو كان المهاجمون يقيدون أنفسهم على ملفات الطوفان فقط ، فإن Deluge يستخدم الملفات مع .conf الامتدادات لتخزين إعدادات التكوين مع معلومات حساسة. تم تحديد هذا التمديد على أنه text/plain بواسطة mimetypes.guess_type. طلب إلى /js/deluge-all%2F..%2F..%2F..%2F..%2F..%2F..%2F.config%2Fdeluge%2Fweb.conf، على سبيل المثال ، ستعيد هذه المعلومات مثل كلمة مرور Admin Webui SHA1 مع الملح وقائمة الجلسات. تتم كتابة الجلسات إلى الملف فقط عند إيقاف تشغيل الخدمة ، وبعد انتهاء الصلاحية الافتراضية لمدة ساعة واحدة. ولكن مع بعض الحظ ، يمكن للمهاجمين العثور على جلسة صالحة هناك لمصادقة أنفسهم على الخدمة. خلاف ذلك ، سوف يحتاجون إلى الغاشمة فرض تجزئة كلمة المرور. لأن الطوفان لا يستخدم أ خوارزمية تجزئة كلمة المرور البطيئة، يمكنهم القيام بذلك بسرعة كبيرة لكلمات مرور بسيطة أو قصيرة.

بمجرد حصول المهاجمين على جلسة مصادقة ، يمكنهم استخدام تقنية الاستغلال من CVE-2017-7178 لتنزيل وتثبيت وتشغيل مكون إضافي ضار على الجهاز الضعيف باستخدام /json نقطة نهاية ويب واجهة برمجة تطبيقات.

استغلالها

إذا كان طوفان webui استضاف خارجيا، سيكون الاستغلال واضحًا. ومع ذلك ، حتى لو كانت الخدمة متاحة محليًا فقط ، نظرًا لأنها نقطة نهاية غير مصادفة ، يمكن للمهاجمين استخدام هجوم إعادة تدوين DNS للوصول إلى الخدمة من موقع ويب مصمم خصيصًا. بالنسبة للمتصفحات التي تنفذ CORS-RFC1918 ، التي تتراوح عناوين المقاطع في مساحات عناوين مختلفة (استرجاع ، شبكة محلية ، وعناوين الشبكة العامة) ، يمكن للمهاجمين استخدام Linux و MacOS الالتفافية المعروفة- 0.0.0.0 عنوان IP– للوصول إلى الخدمة المحلية.

من أجل البساطة ، دعنا نفترض أن المهاجمين يعرفون ميناء التطبيق الضعيف (8112 افتراضيًا لـ Deluge Webui) ، على الرغم من اكتشاف أن الميناء يمكن أن يكون آليًا مع التفرد. يفتح مستخدم Webui Deluge صفحة ويب مع إيفرامات متعددة من خلال زيارة الخبيثة somesite.com. كل إطار يجلب http://sub.somesite.com:8182/attack.html. من أجل تجاوز SOP ، يجب أن يكون رقم المنفذ هو نفسه تطبيق الهجوم. قد يستجيب محلل DNS الذي تحكم المهاجمين بالتناوب مع 0.0.0.0 ، وعنوان IP الحقيقي للخادم مع وقت منخفض للغاية للعيش (TTL). عندما يحل DNS بعنوان IP الحقيقي ، يجلب المتصفح صفحة مع برنامج نصي ينتظر إدخال DNS عن طريق التحقق مما إذا كان بإمكانهم الطلب والقراءة http://sub.somesite.com:8182/js/deluge-all/..%2F..%2F..%2F..%2F..%2F..%2F.config%2Fdeluge%2Fweb.conf. إذا نجح الهجوم ، فإن البرنامج النصي سيكون قد قام بتوزيع ملف التكوين.

من أجل المصدر الكامل attack.html يرجى التحقق من هذا استشاري.

كيف تحمي نفسك بشكل استباقي من هجمات DNS

• لا يعمل Rebinding DNS لخدمات HTTPS. بمجرد إنشاء جلسة أمان طبقة النقل (TLS) somesite.com، يتحقق المتصفح من موضوع الشهادة مقابل المجال. بعد تغيير عنوان IP ، يحتاج المستعرض إلى إنشاء جلسة جديدة ، لكنه سيفشل ، لأن شهادة تطبيق الويب المنشورة محليًا لن تتطابق مع اسم المجال.
• كما ذكرنا سابقًا ، ملفات تعريف الارتباط المصادقة ل somesite.com لن يتم قبولها بواسطة تطبيق الويب الذي تم نشره محليًا. لذا تأكد من استخدام مصادقة قوية ، حتى لو كان أكثر من HTTP غير مشفرة.
• تحقق من رأس المضيف للطلب ورفض ما إذا كان لا يتطابق بدقة مع قائمة السماح بالقيم المتوقعة. سيحتوي الطلب المرتفع على المضيف somesite.com قيمة الرأس.

خذ هذا معك

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

لا تفترض أبدًا أن الخدمة آمنة لمجرد أنها “تعمل محليًا فقط”. فرض المصادقة القوية القائمة على كلمة المرور دائمًا-حتى للخدمات الداخلية أو أدوات التطوير. قد يتم كشف أي خدمة محلية دون التحكم الصارم للوصول من خلال متصفح الضحية. التحقق من صحة Host رأس. استخدم HTTPS كلما أمكن ذلك.

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

---