كيف يمكن للمهاجم استخدام بيانات تعريف المثيل لخرق تطبيقك في AWS

22 مارس، 2022

بقلم ثياغا فاسوديفان - نائب الرئيس لإدارة المنتجات ، Skyhigh Security

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

ومع ذلك ، في كل بيئة سحابية ، سواء كانت Amazon Web Services (AWS) أو Azure أو Google Cloud ، هناك فئة جديدة من المخاطر. تنبع التهديدات السحابية الأصلية من متطلبات السياق والتكوين الجديدة التي لديك في بيئة سحابية. تاريخيا ، تركت الإعدادات الافتراضية مثل الوصول العام إلى كائنات التخزين البيانات الحساسة في العراء ، ويسهل سرقتها من قبل أي شخص يزحف إلى نقاط الضعف هذه.

من السهل ارتكاب الأخطاء في بيئة جديدة ، مع تقديم إعدادات جديدة باستمرار حيث يتم إضافة إمكانات جديدة بواسطة موفري الخدمات السحابية. تكوين بيئة السحابة الخاصة بك هو دائما مسؤوليتك. لا تتحكم AWS وغيرها في كيفية استخدامك لخدماتها. إنها قالب يمكنك البناء منه.

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

مثال على ذلك هو الخرق الذي عانت منه Capital One منذ ما يقرب من ثلاث سنوات حيث تمكن المهاجم من الوصول إلى أرقام الضمان الاجتماعي من 100 مليون فرد أمريكي وأرقام التأمين الاجتماعي من 6 ملايين فرد كندي. استخدم المهاجم العديد من التقنيات للوصول إلى البيانات ، ولكن التعلم الرئيسي من الهجوم هو أن ميزة الأمان المصممة لحماية الوصول إلى الأجهزة الافتراضية - Elastic Compute Cloud أو مثيلات EC - أضافت المهاجم. تسمى الميزة خدمة بيانات تعريف المثيل أو IMDS.

هجمات البيانات الوصفية للمثيل

تم إصدار الإصدار الأول من IMDS (IMDSv1) في عام 2012 للسماح بطريقة أكثر أمانا لمثيلات EC2 للتفاعل مع خدمات AWS الأخرى. بدلا من ترك مفاتيح AWS على المثيل، يمكن للعملاء الآن جعل مثيل EC2 يستعلم عن خدمة البيانات الوصفية للحصول على بيانات الاعتماد وإجراء استدعاءات AWS API إلى خدمات AWS الأخرى. على سبيل المثال، إذا حصل مثيل EC2 على بعض بيانات العميل، فيمكنه استخدام IMDSv1 لتخزين تلك البيانات في حاوية Amazon Simple Storage Service (S3). كانت هذه هي القدرة الدقيقة التي استخدمها المهاجم لسحب المعلومات الحساسة من حاوية S3 المستخدمة لتخزين المعلومات حول عملاء Capital One.

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

خلال مرحلة تطوير هذا التطبيق ، واجه الفريق تحديا. كان من المفترض أن تكون معظم الموارد الموجودة في السحابة الافتراضية الخاصة (VPC) مخفية عن الإنترنت. كان المورد الوحيد في VPC المخصص للعرض العام هو لوحة القيادة.

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

بالنسبة لفريق علماء الأوبئة ، كان الوكيل العكسي حلا أساسيا وأنيقا يعمل بشكل مثالي لحالة الاستخدام الخاصة بهم. ما لم يدركوه هو أنه وضعهم لخرق هائل.

تم تعيين مثيل الحساب الذي يقوم بتشغيل الوكيل العكسي لدور IAM مع إذن للوصول إلى حاوية S3 الخاصة به. تم الحصول على بيانات اعتماد الوكيل العكسي للوصول إلى S3 من بيانات تعريف المثيل.

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

من خلال الوكيل العكسي ومن بيانات تعريف المثيل، كشف المهاجم عن بيانات اعتماد إلى حاوية تخزين S3 الخاصة بالفريق.

الآن ، مع الوصول إلى حاوية S3 ، يمكن للمهاجم سرقة البيانات الحساسة للغاية التي قام الفريق بتخزينها لتطبيقه. قام المهاجم ببساطة بمزامنة حاوية S3 المستهدفة مع حاوية S3 الخاصة به في حساب AWS آخر، وكانت البيانات ملكا له.

هذا النوع من الهجوم هو مجرد واحد من 43 تقنية وصفتها MITRE في إطار عمل ATT &CK للبيئات السحابية: https://attack.mitre.org/matrices/enterprise/cloud/

كيف تخفف AWS من هجمات البيانات الوصفية للمثيل

لتحسين أمان هذه الخدمة ، أصدرت AWS IMDSv2 ، والتي تضيف عدة طبقات جديدة من الحماية.

في IMDSv2 ، يتم حظر المستخدمين الخارجيين من تلقي بيانات الاعتماد ، مما يسمح فقط لموارد التطبيق بتلقيها. اقرأ المزيد عن طبقة الحماية هذه و IMDSv2 هنا: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

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

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

كيف يمكن أن تساعد حماية التطبيقات الأصلية Skyhigh Cloud

في Skyhigh Security، لدينا العديد من الطرق التي يمكن أن تساعدك في اكتشاف مثل هذه الهجمات ومنعها. منصة حماية التطبيقات الأصلية Skyhigh Cloud (CNAPP) هي منصة الأمان السحابية الأصلية الخاصة بنا والتي تتيح لك مراقبة التكوينات وتحديثها في AWS وAzure وGCP إلى جانب مجموعة واسعة من إجراءات الأمان الإضافية التي يمكنك القراءة عنها هنا.

باستخدام تكامل واجهة برمجة التطبيقات المباشر مع AWS، تراقب Skyhigh CNAPP باستمرار Amazon CloudWatch - وهي خدمة مراقبة التطبيقات والبنية التحتية - للإشارة إلى إصدار IMDS الذي تستخدمه في كل مثيل EC2.

عندما تسجل CloudWatch مثيلا نشطا باستخدام IMDSv1 ، يقوم Skyhigh CNAPP بإنشاء حادث أمني ، يخطرك بتحديث التكوين الخاص بك إلى IMDSv2 ، مما سيمنع الوصول غير المصرح به إلى بيانات الاعتماد الخاصة بك من قبل المستخدمين الخارجيين.

من أفضل الممارسات فرض IMDSv2 على مثيلات EC2 لجميع التعليمات البرمجية المحلية والمستخدمين. بمجرد تحديد أنه يجب استخدام IMDSv2 ، لن يعمل IMDSv1 بعد الآن. لدى AWS إرشادات خطوة بخطوة حول كيفية تكوين مثيلاتك لاستخدام IMDSv2 هنا.

بالإضافة إلى مثال الهجوم هذا ، يتيح لك Skyhigh CNAPP تنفيذ سلسلة من أفضل الممارسات لحماية تطبيقاتك السحابية الأصلية:

• قم بتدقيق التكوينات الخاصة بك باستمرار. باستخدام Skyhigh CNAPP، يمكنك فحص قوالب AWS CloudFormation قبل دخولها مرحلة الإنتاج، ثم اكتشاف أي "انحراف" في تكويناتك بمرور الوقت. يتيح لك ذلك اكتشاف التكوينات الخاطئة وفرض نموذج أقل امتيازا للحصول على إذن المورد.
• فرض انعدام الثقة. استخدم انعدام الثقة كمنهجية ، حيث يسمح فقط لموارد محددة بالعمل والتواصل مع بعضها البعض. كل شيء آخر محظور.
• البحث عن الثغرات الأمنية في التعليمات البرمجية. خاصة مع نماذج توزيع البرامج المفتوحة مثل Docker ، من المهم مراقبة موارد التطبيق الخاصة بك بحثا عن نقاط الضعف بشكل مستمر.
• كشف الحالات الشاذة والتهديدات. باستخدام تحليلات سلوك المستخدم والكيان (UEBA)، يمكنك تقييم ملايين الأحداث السحابية للكشف عن النشاط الشاذ والتهديدات الحقيقية مثل سرقة بيانات الاعتماد.
• قم بتشغيل DLP على كائنات التخزين. تماما مثل أي خدمة سحابية أخرى تعاقب عليها أو شبكتك أو نقاط النهاية ، داخل AWS يمكنك ويجب عليك تصنيف بياناتك داخل S3 وتشغيلها data loss prevention لوقف محاولات التسلل.

تواصل معنا للتحدث عن تنفيذ هذه التدابير في مؤسستك.