اختراق حسابات AWS لعملاء Qubole على يد قراصنة
بين 14 أكتوبر و26 أكتوبر، اخترق مهاجم حسابات AWS تابعة لعدة عملاء لشركة Qubole، وسرق أسرارًا وبيانات مخزنة، وفقًا لما أوردته شركة الأمن السحابي Wiz.
استغل المهاجم بيانات اعتماد لحساب AWS تستخدمه منصة Qubole للوصول إلى عملائها. ولم يُكشف عن الطريقة التي حصل بها المهاجم على بيانات الاعتماد هذه.
تعمل Qubole، وهي منصة بحيرة بيانات (data lake) تمتلكها Idera، داخل حسابات AWS الخاصة بعملائها. ينشئ العملاء دور IAM، وهو هوية AWS ذات صلاحيات محددة، لمنح Qubole حق الوصول.
تسمح سياسة الثقة الخاصة بالدور لحساب AWS التابع لـ Qubole بافتراض الدور، وبالتالي منح الصلاحيات اللازمة. ويجب أن يتضمن كل طلب للقيام بذلك، المعروف باسم AssumeRole، رمزًا مطابقًا من Qubole يُشار إليه باسم External ID.
أشار باحثو Wiz إلى أن معظم الأدوار التي افترضها المهاجم كانت غير مستخدمة. ومع ذلك، نظرًا لأن كل دور كان لا يزال يثق بحساب Qubole، فقد نجحت طلبات المهاجم.
على المؤسسات التي ربطت Qubole بـ AWS، بما في ذلك تلك التي لم تعد تستخدمها، مراجعة سجلات CloudTrail الخاصة بها من 1 أكتوبر فصاعدًا. ويجب أن تبحث عن طلب AssumeRole من الحساب الذي تستخدمه منصة Qubole، 805246085872، صادر من عنوان خارج AWS.
لم يؤكد الباحثون ما إذا كانت بيانات الاعتماد المخترقة قد تم تعطيلها أو ما إذا كان النشاط الخبيث قد توقف. وحتى آخر فحص، لم تصدر Qubole ولا Idera أي بيان بشأن الهجوم على مواقعهما الإلكترونية.
تفاصيل الهجوم
تضمن كل طلب AssumeRole مرتبط بالمهاجم External ID وتم قبوله، وفقًا للتحليل الفني للباحثين. تقبل AWS طلب AssumeRole لمثل هذا الدور عندما يصدر من الحساب الموثوق ويتضمن External ID الصحيح. ولا يُعامل هذا الرمز كسر، مما يسمح لأي شخص لديه حق الوصول إلى الدور برؤيته.
اكتشفت Sentra النشاط في عدة بيئات لعملائها وأنذرت الباحثين. وفي الحسابات التي جرى فحصها، بحث المهاجم عن بيانات اعتماد مخزنة، فقرأ متغيرات البيئة لوظائف Lambda، واستخرج أسرارًا من Secrets Manager، ووصل إلى قيم من SSM Parameter Store.
اختبر المهاجم بيانات الاعتماد التي عثر عليها باستخدام TruffleHog لتحديد صلاحيتها. وشملت هذه مفاتيح وصول AWS الخاصة بالضحايا، وأسرار عميل Entra ID، وبيانات اعتماد عميل Okta.
بالإضافة إلى ذلك، نسخ المهاجم بيانات من S3، فاسترجع معلومات من أي حاوية يمكن الوصول إليها بدلًا من البحث عن بيانات محددة، وفي بعض الأحيان نزّل حاويات كاملة في جلسة واحدة.
لم يربط الباحثون هذه الحملة بأي أنشطة أخرى أُبلغ عنها علنًا، مشيرين إلى أن الاستهداف لا يتوافق مع السلوك النموذجي للمجموعات المدعومة من الدول.
تسمح Qubole أيضًا للعملاء بالاتصال باستخدام مفاتيح وصول AWS بدلًا من الأدوار. ومن 8 أكتوبر إلى 11 أكتوبر، استخدم مهاجم مفاتيح وصول AWS الخاصة بالعملاء، التي يُعتقد أنها أُعدت لـ Qubole، لاختراق بيئات سحابية لعدة ضحايا. ولم يُربط هذا النشاط بإساءة استخدام AssumeRole.
توصيات للحسابات المتأثرة
تشمل إرشادات Wiz للحسابات المتأثرة مراجعة سجلات CloudTrail من 1 أكتوبر فصاعدًا بحثًا عن أي نشاط مشبوه. وتشمل المؤشرات الرئيسية التي يجب التحقق منها:
- الحساب: طلبات AssumeRole حيث يكون userIdentity.accountId هو 805246085872 وsourceIPAddress ليس عنوان AWS.
- معرّف IAM principal: AIDA3W7DIFLYOLTK63SFS. يجب التحقيق في أي نشاط من مستخدم IAM هذا.
- معرّف IAM principal: AIDAJYRRH5Y3A7AAJM2HW، عندما يكون عنوان المصدر خارج AWS.
- عناوين IP: 57.129.54[.]120 و2001:41d0:70d[:]7800::، التي استخدمها المهاجم.
- عناوين IP: 45.83.220[.]211 و185.209.199[.]73 و89.37.63[.]175، المرتبطة بـ Mullvad VPN.
- اسم الجلسة: جلسات الأدوار التي تبدأ بـ quiam-، مثل quiam-enum.
- وكيل المستخدم: TruffleHog في استدعاءات GetCallerIdentity من عناوين IP المحددة.
بالنسبة لكل جلسة مشبوهة، يجب على المؤسسات مراجعة جميع الإجراءات اللاحقة، لا سيما في Secrets Manager وSSM Parameter Store وLambda وS3.
تسجل أحداث إدارة CloudTrail كل طلب AssumeRole وسرد الحاويات، لكنها لا تحدد كائنات S3 التي قُرئت. ويتطلب ذلك أحداث بيانات S3 أو سجلات وصول الخادم، التي افتقرت إليها عدة ضحايا، مما أعاق القدرة على تحديد الكائنات التي وصل إليها المهاجم.
خطوات التخفيف
للتخفيف من المخاطر، يوصي الباحثون بالإجراءات التالية:
- تدوير جميع الأسرار والمعلمات ومتغيرات بيئة Lambda التي يمكن الوصول إليها من أي دور Qubole مخترق، وإلغاء الجلسات النشطة للدور.
- إزالة أي أدوار Qubole غير ضرورية أو استبعاد حساب Qubole من سياسة الثقة.
- حيثما ينطبق، استبدال principal :root على مستوى الحساب في سياسة الثقة بـ IAM principal المحدد الذي تستخدمه Qubole.
- إضافة شرط aws:SourceIp أو aws:SourceVpce لتقييد طلبات AssumeRole بنطاقات الشبكة الموثقة.
- إدراك أن External ID يمكن عرضه كنص عادي في CloudTrail ولا ينبغي أن يكون الضابط الوحيد.
- مراجعة صلاحيات الوصول لكل دور بائع.
- إعداد تنبيهات لطلبات AssumeRole من حسابات البائعين التي تصدر من شبكات VPN أو شركات استضافة غير مألوفة.
- تمكين التسجيل لكل حساب ومنطقة عبر مسار المؤسسة، وتفعيل أحداث بيانات S3 أو سجلات وصول الخادم لحاويات البيانات الحساسة.
المصدر: The Hacker News