معظم المطورين يعرفون ويحبون صفحات جيثب. في حال لم تقابلهم ، تتيح هذه الخدمة إنشاء موقع ثابت من المستودع الخاص بك ، والذي سيكون متاحًا على نطاق smth.imtqy.com. هذا مناسب بشكل لا يصدق لأي إحصائيات مؤقتة أو وثائق أو مواقع بسيطة صغيرة وما إلى ذلك. لا حاجة للتفكير في نوع آخر من خادم الويب الإضافي.
هناك أيضًا فرصة لربط نطاقك بالمستودع - ثم سيكون كل شيء جميلًا جدًا. حتى أن هناك دعم SSL.
بعد هذه المقدمة القصيرة ، ننتقل إلى الموضوع الفعلي للمقالة. في الآونة الأخيرة (9 نوفمبر) كان لدي قصة مثيرة للاهتمام. أوصي بعدم قراءتها في جرعة واحدة ، ولكن توقف دوريًا وتساءل عما تعنيه جميع الملاحظات التمهيدية الواردة حاليًا. أعتقد أن تمرينًا مثيرًا للاهتمام سيخرج من هذا ، على الرغم من أن مؤامرة المخبر لم تكن طويلة جدًا وملتوية.
قررت إضافة عنوان سيرتي الذاتية إلى ملف التعريف التالي. الملخص يكمن فقط على صفحات جيثب ، لماذا لا. بدافع العادة ، نقر للتحقق مما إذا كان كل شيء يعمل ... وفجأة اكتشفت شيئًا غريبًا هناك:
فوجئت جدا. ذهبت إلى إعدادات المستودع. رأيت أنه في الوقت الحالي لا يرتبط بالنطاق الذي يجب أن يرتبط به. حاولت المفاجئة. فجأة حصل خطأ:
تم تسجيل whois.jehy.ru CNAME بالفعل. راجع https://help.github.com/articles/troubleshooting-custom-domains/#cname-already-taken لمزيد من المعلومات
توتّر قليلاً وفوجئ. بعد ذلك ذهبت لألقي نظرة فاحصة على هذه الصفحة المفاجئة. كما كان من قبل ، رأيت فقط نموذجًا قياسيًا معينًا ، وحقوق الطبع والنشر من عام 2013 وفجأة رابطًا لخريطة الموقع. يحتوي ملف sitemap على تاريخ إنشائه من التاريخ الحالي ، بالإضافة إلى مستند html ثابت مع عنوان ومحتوى يذكرنا جدًا بطريقة التحقق من google (الاسم googlef3e716e930ae1730 ، محتوى google-site-verification: googlef3e716e930ae1730.html ). هنا تم توتري بقوة ، وركضت ، وغيرت سجل NS إلى خادمي ، وبدأت أفكر في الخطأ الذي حدث.
كشفت غوغل السطحية ما يلي:
- يبدو أن اختطاف النطاق مشكلة محتملة معروفة ، وقد تم حلها بالفعل - يكفي تسجيل عنوان المستودع الخاص بك في CNAME .
- على الرغم من ذلك ، في العديد من الإرشادات حول ربط github بمجال (بما في ذلك من أهم 10 عمليات بحث) ، تتم كتابة عناوين IP مباشرة ، أو ببساطة imtqy.com.
ثم اعتقدت أنه ربما كان لدي سجل CNAME. لذا قمت بتغييره إلى الصحيح ، المرتبط بمستودعي. الآن بدا الإدخال كما يلي:
dig whois.jehy.ru +nostats +nocomments +nocmd ; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> whois.jehy.ru +nostats +nocomments +nocmd ;; global options: +cmd ;whois.jehy.ru. IN A whois.jehy.ru. 6984 IN CNAME jehy.github.io. jehy.github.io. 3384 IN A 185.199.108.153 jehy.github.io. 3384 IN A 185.199.110.153 jehy.github.io. 3384 IN A 185.199.109.153 jehy.github.io. 3384 IN A 185.199.111.153
وماذا أدهشني عندما رأيت مرة أخرى هذا الهبوط الرائع "قريباً"!
للتحقق ، لقد أجريت اختبارًا آخر:
1) بدأ test.jehy.ru سجل CNAME جديد وأشار لها بملف شخصي لـ Ryan Dahl
2) بدأ مستودع اختبار ، محددًا عليه test.jehy.ru. يبدو أن كل شيء صحيح ، وفقًا للتعليمات ، ويجب ألا يعمل التجليد. ولكن للأسف ، كانت النتيجة واضحة .
بعد ذلك ، اتصلت بالدعم الفني لجيثب من خلال نموذج غريب على الموقع . أخبروني هناك أنه يمكنهم فك ارتباط مستودع شخص آخر من نطاقي إذا قمت بإضافة سجل NS آخر إلى نفسي. فعلت ذلك ، وكتبتها ، ومن يوم الجمعة حتى يوم الاثنين لم أتلقى إجابة. ربما كان من الضروري إعادة الكتابة في هذا النموذج - لكنها كانت بالفعل أعلى من قوتي. لذا تركت موقعي الثابت على الخادم الخاص بي.
في ذلك الوقت ، كان لدي ثلاثة خيارات لما حدث:
1) قام شخص ما دون قصد بتدوين العنوان "whois.jehy.ru" في مستودعه في عام 2018 ، أثناء وضع صفحة مقصودة تحتوي على "قريبًا" اعتبارًا من عام 2013 ، حيث يكمن السبب لسبب ما في وجود html من Google لفحص الحقوق. حسنا ، بالكاد.
2) حدث بعض الخلل الجنوني. من غير المحتمل أيضًا. كرر في موقع الاختبار الثاني.
3) إما أن التركيز القائم على CNAME لم ينجح أبدًا ، أو انهار ، ويستخدم المهاجمون هذا للهجوم. حتى الآن ، بدا لي هذا الخيار الأكثر احتمالاً.
ثم تذكرت أنه في حالة ربط النطاق ، يقوم github نفسه بإنشاء ملف باسم CNAME في المستودع الخاص بك. وذهب للبحث عن من أضاف نطاقي. و - البنغو!
تم العثور على مهاجم في البحث:
هنا نطاقي:
وهنا مجموعة من الآخرين:
كما ترون ، لم يكن هذا حادثًا على الإطلاق. سرق شخص ما كمية لا بأس بها من المجالات - بما في ذلك المستوى الثاني! وقد حصل على السيطرة الكاملة على محتوياتها ، بما في ذلك التأكيد في Google على حقوق امتلاك هذه المجالات!
بالمناسبة ، يمكنك أيضًا إضافة أنه في بعض الأحيان لا يقوم الهاكر باستبدال محتوى الموقع فحسب ، بل يقوم أيضًا بتخزين المستودع الأصلي ، ثم يضيف ملفات التحقق هناك. وهكذا كان الأمر ممتعاً لمدة شهر على الأقل (لقد وجدت عمليات مرتدة من 6 أكتوبر). حسنًا ، المتابعون متشابهون هناك.
علاوة على ذلك ، افتراضاتي حول كيفية حدوث مثل هذا الهجوم ، ولماذا هو مطلوب.
1) أولاً ، يعثر المخترق على المواقع التي يتم حلها على imtqy.com. هذا سهل جدا.
2) بعد ذلك ، يقوم بتصفية تلك العناصر ، مع ترك فقط تلك التي تعرض خطأ (يبدو أن هناك 404 فقط). قد تكون هناك العديد من الحالات التي لم يتم إرفاق المستودعات فيها - قام شخص ما بتكوين المستودع ، وحذفه شخص ما ، وحصل شخص ما على إعدادات الربط (يبدو لي أن ذلك حدث عندما قمت بتغيير الفرع لصفحات github).
3) ثم ينشئ المخترق ببساطة مستودعًا جديدًا بالمحتوى الذي يحتاجه ويربطه بالمجال "المجاني". فويلا!
4) ثم كل شيء يعتمد فقط على خيال القراصنة. المدخل ووضع الروابط واعتراض البيانات والوصول إلى إدارة تطبيقات Google من خلال Google ... هناك الكثير من الخيارات.
ما فعلته بعد ذلك ، مع كل أدلة الاستخدام الضار للروابط في متناول اليد:
- موصوفة في المراسلات مع support@github.com جميع التفاصيل ؛
- مرة أخرى أعد كتابتها في نموذج الاتصال ؛
- تمت إضافة تذكرة إلى hackerone.com . يجب أن أقول أنه ينص على أن githubpages.io غير مدرج في برنامج المكافآت ، ولكن لم تكن هناك خيارات أخرى. لذلك ، كان عليّ تجاهل هذا التحذير ، وحتى الروبوت الذي نصحني بلطف بعدم إرسال هذا التقرير للأسباب نفسها.
حتى يومنا هذا ، لم يردوا على نموذج الاتصال حتى يومنا هذا ، ولكن بعد يومين أجابوني على الهاكرون. باختصار ، كان الجواب أن هذه ميزة معروفة للخدمة ، وليست نقطة ضعف ، وأن فريق البريد العشوائي منخرط في مثل هذه الأشياء. تم إغلاق التقرير باعتباره "بالمعلومات" ، لذلك أكتب عن كل ما حدث بضمير مرتاح. كما أبلغوني أنه تم حظر الحساب الذي أشرت إليه. راجعت - نعم ، لم يعد كذلك. اختفى أتباعه بعد بضعة أيام (ليس من الواضح لماذا لا على الفور).
يمكن للمرء أن ينتهي بهذا ويقول أن كل شيء على ما يرام ... ولكن في الواقع ، أنا محرج للغاية من هذا الوضع:
- لماذا ليست هذه الحسابات في الأشهر؟ هناك محتوى متطابق ، وهناك ملفات التحقق من جوجل في كل مكان ، على حساب واحد هناك الكثير من هذه المواقع ... علامات شائعة - عربة وعربة صغيرة.
- لماذا لم يتحقق فريق البريد العشوائي من المستودعات ذات الصلة؟
- لماذا ترى وهم الأمن في تعليمات ربط النطاق ، تقترح عليك تعيين اسم المستودع الخاص بك في CNAME إذا لم يؤثر ذلك على أي شيء؟
- لماذا لا توجد آلية تحذير تفيد بأن المجال الذي تم ربطه بحسابك سابقًا مرتبط الآن بآخر؟
- لماذا في github يستحيل الرد على رسائل البريد الإلكتروني من الدعم؟ أو ربما وقعت تحت نوع من التصفية؟
لكن السؤال الرئيسي الذي يزعجني هو لماذا لا يتحقق github من سجلات NS للنطاقات المدرجة في صفحات github لوجود مستودع CNAME محدد فيها؟ هذه هي أبسط عملية يمكن إجراؤها عند ربط نطاق ، ولا تستغرق وقتًا ... علاوة على ذلك ، تعطي التعليمات الشعور بأنه كان من المفترض أن تكون كذلك .... فلماذا كسر هذا الاختيار؟
بشكل عام ، أكتب هذا المنشور على أمل أنه في شكل ما سيصل إلى جيثب ، وسيتخذ الرجال إجراءً. قبل السؤال "لماذا نتحدث عنه ، سيصعد الجميع للقيام بذلك الآن" - سأجيب أن الحفرة معروفة جيدًا ومُستغلة بشكل نشط. ومن الواضح الآن أنه يتم مسح المجالات "المهجورة" باستمرار ، لذا لن يغير العديد من المشاركين الجدد الصورة.
عادة لا أفعل ذلك ، ولكن سيكون رائعًا إذا قمت بترجمة هذه المقالة ، التي وضعتها على الوسيط. نعم ، أعلم أن الهبر أصبح الآن متعدد اللغات ، ولكن طوال الوقت رأيت وظيفة ونصف باللغة الإنجليزية ، ولا أعتقد أنه يمكن لأي شخص الانتباه إليها. وعلى المستوى المتوسط ، غالبًا ما تكون هناك وظائف فنية جيدة. لذلك سيكون من الرائع أن تساعد في الانتباه إلى هذه الحفرة. إذا كان هناك أي شيء - لن أحصل على أي أموال مقابل ذلك ، فلا توجد بطاقة أمريكية ، والفائدة هي الإيثار البحت.
ماذا يمكنك أن تفكر في النهاية؟ ربما يكون من الجدير دائمًا التذكر عندما تضع شيئًا ما على قدرات الطرف الثالث. بالطبع ، على الإنترنت ، لا يوجد شيء شخصي على الإطلاق ، وكل شيء هو طرف ثالث - نطاقات "ملكك" تنتمي إلى المسجل ، وخوادم "ملكك" تنتمي إلى Google ، أو Amazon ، أو أي شخص آخر ... لا يمكن القول أن github أقل موثوقية من أي خادم "خاص" ... ولكن الخادم "الخاص بك" أقرب إلى حد ما من الجسم وأكثر قابلية للتنبؤ به. بشكل عام ، تحتاج دائمًا إلى تذكر مواردك ، وأهميتها ، والخسائر المحتملة عند اعتراضها ، وأنه في خدمات الطرف الثالث يمكن أن تكون هناك خصوصية مفاجئة للغاية للعمل.
سكرتير خاص شكرا كافين للصورة و pndpnd لترجمة المقال إلى اللغة الإنجليزية.