ما تحتاجون إلى معرفته عن برامج الفدية في AWS

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

في مؤتمر AWS re:Inforce، حضرت جلسة رائعة قادها كل من Kyle Dickinson وMegan O’Neil وKarthik Ram. كانت القاعة ممتلئة تمامًا، واضطر المنظم إلى رد العشرات من الحضور. هذه المقالة هي بمثابة مراجعة موجزة للجلسة، مقترنة بتجاربي وتوصياتي الخاصة بشأن برامج الفدية في AWS. وأي أخطاء أو إغفالات تقع على عاتقي وحدي، لا على عاتقهم.

أبرز النقاط:

• تستهدف جهات برامج الفدية بيئات Amazon Web Services (AWS) بصورة متزايدة، مستغلةً في الغالب الثغرات في الوصول إلى الهوية، وتكوينات التخزين، ومستوى الرؤية عبر الخدمات.
• تمثل حاويات Amazon S3 نقطة دخول شائعة، حيث يقوم المهاجمون بتشفير البيانات الحيوية أو حذفها بسبب ضعف السياسات أو عدم فرض التشفير.
• يتطلب الدفاع الفعّال ضد برامج الفدية في السحابة استراتيجية متعددة الطبقات، تشمل التحكم في الوصول، والمراقبة في الوقت الفعلي، وسير عمل للاستجابة السريعة.
• يعزز FireMon وضع أمن البيانات من خلال المراقبة المستمرة للتكوينات الخاطئة، وفرض السياسات على نطاق واسع، وتوفير رؤية تساعد الفرق على الاستجابة بسرعة أكبر لتهديدات برامج الفدية السحابية.

هل تشكّل برامج الفدية في Amazon AWS مشكلة؟

نعم. تبيّن أن برامج الفدية في AWS تمثل مشكلة أكبر مما كنت أعتقد في البداية. فهناك عملاء حقيقيون يتأثرون بها، والأمر ليس نظريًا فحسب.

كيف يعمل هجوم برامج الفدية على Amazon

سأتناول ناقل الاستغلال الأولي في السؤال التالي، ولكن هناك أربع تقنيات محتملة لهجمات برامج الفدية على Amazon:

• يخترق المهاجمون مثيلًا (غالبًا عبر التصيّد الاحتيالي لمستخدم/مسؤول، وليس دائمًا عبر الاختراق المباشر)، ثم يثبّتون برمجياتهم الخبيثة لتشفير البيانات والانتشار إلى المثيلات الأخرى التي يمكن الوصول إليها. وهذا لا يختلف في الواقع عن برامج الفدية في مركز البيانات، إذ لا ينطوي على أي عنصر خاص بالسحابة.
• ينسخ المهاجم البيانات من حاوية S3 ثم يحذف البيانات الأصلية. وهذا هو النوع الأكثر شيوعًا من برامج الفدية السحابية الأصلية على Amazon.
• تقوم جهة خبيثة بتشفير بيانات S3 باستخدام مفتاح KMS خاضع لسيطرتها. وهذا أقرب إلى النظري منه إلى الواقعي، لعوامل متعددة. فحذف كائن/حاوية أسهل بكثير من تشفيرها بأثر رجعي.
• يقوم مهاجم بشيء ما بالبيانات في خدمة تخزين أخرى لقفلها أو حذفها. وأنا أتحدث بغموض لأن هذا لم يُرصد فعليًا، ولأن معظم تلك الخدمات تتضمن قيودًا داخلية ومرونة مدمجة تجعل تنفيذ هجوم فدية أمرًا صعبًا.

تستهدف برامج الفدية حاويات AWS S3 في أغلب الأحيان، حيث ينسخ المهاجمون البيانات ثم يحذفونها. كما يمكن أن تكون المثيلات/الخوادم هدفًا للبرمجيات الخبيثة نفسها المستخدمة في مهاجمة مراكز البيانات. وهناك بضعة هجمات نظرية لا تُرصد فعليًا في الواقع.

غير أن هناك هجومًا جديدًا ببرامج الفدية على Amazon بدأ ينتشر: إذ شرعت عصابات برامج الفدية في تشفير البيانات في مكانها باستخدام التشفير من جانب الخادم في AWS بمفاتيح يوفرها العميل (SSE-C). تتيح هذه التقنية للمهاجمين تشفير الملفات مباشرةً داخل حاويات S3 الخاصة بكم دون إزالتها أو إطلاق التنبيهات المعتادة، ويستحيل الاسترداد من دون مفتاح التشفير المخصص للمهاجم.

كيف تحصل الجهات المهددة على إمكانية الوصول لتنفيذ هجمات برامج الفدية على Amazon Web Services

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

ما تسلسل هجوم برامج الفدية على S3

سأركّز على سيناريو برامج الفدية على حاويات S3 لأنه السيناريو السحابي الأصلي الذي نريد التركيز عليه.

• يحصل المهاجم على بيانات الاعتماد.
• يستخدم المهاجم بيانات الاعتماد في الاستطلاع لتحديد استدعاءات API المسموح بها والتعرف على الموارد التي يمكنه الوصول إليها.
• يكتشف المهاجم أن لديه أذونات الكتابة في S3 وصلاحيات السرد/القراءة لتحديد الحاويات. لاحظوا أن المهاجم قد لا يملك امتيازات السرد، لكن بإمكانه الحصول على أسماء الحاويات من مصادر أخرى، مثل DNS أو GitHub أو مواقع أخرى. وهذا أقل احتمالًا بكثير.
• ينسخ المهاجم البيانات أو ينقلها إلى موقع آخر، لا يكون بالضرورة داخل AWS.
• يحذف المهاجم الكائنات/الملفات المصدرية.
• يرفع المهاجم رسالة فدية (أو يرسلها بالبريد الإلكتروني).

وفي الحملات الأخيرة، بدأ المهاجمون أيضًا باستخدام سياسات S3 Object Lifecycle Management لوضع علامة على الملفات المشفّرة تمهيدًا لحذفها خلال سبعة أيام، مما يزيد الضغط لدفع الفدية. وكثيرًا ما يتركون ملف warning.txt في الدليل المتأثر يتضمن عنوان محفظة Bitcoin ومعرّف ضحية فريدًا.

ولأن كل ذلك مؤتمت، يمكن أن تبدأ العملية خلال دقيقة واحدة من كشف بيانات الاعتماد.

كيف يمكن اكتشاف برامج الفدية في Amazon S3

حسنًا، إن لم يكن بإمكانكم الانتقال مباشرةً إلى الوقاية من برامج الفدية في S3…

عادةً ما يترك المهاجم رسالة تتضمن معلومات الاتصال حتى تتمكنوا من إرسال Bitcoin إليه، وهو أمر عملي. لكن الأرجح أن معظمكم يرغب في اكتشاف المشكلة قبل ذلك. لنستعرض تسلسل هجوم برامج الفدية على Amazon S3 لنرى أين يمكننا رصد الأمر.

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

• CloudTrail، بطبيعة الحال.
• أحداث بيانات CloudTrail لأي حاويات تهمكم. وهذا يكلّف مبالغ إضافية.
• GuardDuty.
• اختياري: Security Hub. هذه أفضل طريقة لتجميع بيانات GuardDuty وخدمات أمن AWS الأخرى عبر جميع حساباتكم.
• ربما: سجلات وصول خادم S3. إذا كانت لديكم أحداث بيانات CloudTrail، فستحصلون على معظم ما تحتاجون إليه. لكن سجلات S3 مجانية الإنشاء (تدفعون مقابل التخزين فقط) وترصد بالفعل بعض الأحداث التي قد يغفلها CloudTrail (مثل عمليات المصادقة الفاشلة). كما أنها تستغرق ساعات حتى تظهر، لذا فهي غير مفيدة أثناء حادث جارٍ. اقرأوا المزيد في دليل المستخدم هذا.

والآن بعد أن تناولنا المراقبة، لننظر في الخطوات السبع لعملية الاكتشاف:

1. اكتشاف بيانات الاعتماد المكشوفة ونشاط الاستطلاع

تبدأ عملية الاكتشاف بالتعرف الذاتي أو عبر طرف ثالث على مفاتيح AWS المكشوفة علنًا أو المخترقة، وكذلك على أي نشاط مشبوه. ويتم ذلك عادةً عبر فحص مستودع شائع، مثل GitHub. Amazon Web Services عثرت ذات مرة على أحد مفاتيحي وأرسلت إليّ بريدًا إلكترونيًا. يا للخطأ.

ستكون عمليات اكتشاف استطلاع بيانات اعتماد حسابكم مفيدة هنا. ومن الخيارات المتاحة:

• نتائج GuardDuty، مثل تسريب بيانات الاعتماد. غير أن هذا ينطوي على تأخير يبلغ نحو 20 دقيقة، وهناك تقنيات للتهرب منه
• استدعاء API المسمى GetCallerIdentity ليس سيئًا دائمًا، لكنه ليس استدعاءً ينبغي أن تروه كثيرًا في حسابات الإنتاج
• ينبغي أن يطلق GetAccountAuthorizationDetails إنذارًا في كل مرة
• تعدد استدعاءات API الفاشلة الصادرة عن كيان IAM واحد

2. مراقبة تعداد S3

نبدأ الآن بالتركيز على عمليات اكتشاف برامج الفدية في AWS التي تشير إلى أن المهاجم يركّز على S3. وستلاحظون على الأرجح أن الاكتشاف المبكر في هذه المراحل قد يكون صعبًا بسبب الضوضاء، لكن تذكّروا أن هذه الوسائل ستكون أكثر جدوى في حالات مثل حسابات الإنتاج المُدارة عبر CI/CD مع وصول بشري محدود. بل قد يدفعكم ذلك إلى اعتماد المزيد من الأنماط السحابية الأصلية.

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

3. مراقبة عمليات قراءة الكائنات ونسخها

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

4. رصد الحذف الجماعي ووضع مذكرة الفدية

هذه هي مرحلة "الخطر الوشيك". فالمهاجم لم يعد يستكشف فحسب، بل ينفّذ الهجوم ويحذف البيانات المنسوخة. وهنا تبدأ نتائج GuardDuty الخاصة بتسريب البيانات/التأثير في S3 بالظهور. وتذكّروا أن الأمر يستغرق 20 دقيقة على الأقل قبل التنبيه، وبحسب عدد الكائنات قد يكون هذا مؤشرًا متأخرًا. أما CloudTrail Insights، إذا كنتم تستخدمونها، فستنبّه إلى العدد الكبير من أحداث الكتابة المستخدمة لنقل البيانات.

يمكنكم بناء آليات رصد خاصة بكم لعدد كبير من عمليات الحذف. وبحسب بيئتكم وأنماط النشاط المعتادة فيها، قد يكون هذا العدد منخفضًا ويؤدي إلى تنبيه أسرع من GuardDuty. ويُعد نظام SIEM لديكم ومرشّحات مقاييس CloudWatch خيارين جيدين.

5. تحديد إساءة استخدام SSE-C (التشفير الصامت)

راقبوا التطبيق المفاجئ لرؤوس SSE-C في استدعاءات واجهات البرمجة مثل PutObject، فهو مؤشر على احتمال تشفير البيانات باستخدام مفتاح المهاجم. ونظرًا لأن AWS تسجّل تجزئة HMAC للعمليات فقط، فإن الاسترداد الجنائي المعتاد مستحيل من دون مراقبة استباقية.

6. استخدام حاويات الإنذار المبكر ورصد KMS

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

7. التصعيد والاستجابة للحوادث

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

الحماية من برامج الفدية في AWS: كيف يمكنني الحفاظ على أمان مؤسستي؟

لتنفيذ هجوم فدية ناجح على AWS، يحتاج الفاعل الخبيث إلى ثلاثة شروط:

• الوصول إلى بيانات الاعتماد
• أذونات القراءة والكتابة في S3
• القدرة على حذف كائنات لا يمكن استردادها

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

• لا تسمحوا إطلاقًا بمستخدمي IAM الذين يأتون بمفاتيح وصول ثابتة. وإذا تعذّر ذلك، فاحرصوا بالتأكيد على استخدام أدواتكم لتحديد أي مستخدمين يملكون أذونات الحذف في S3.
• اشترطوا المصادقة متعددة العوامل لمستخدمي SSO/الاتحاد. دائمًا وإلى الأبد.
• اجعلوا المسؤولين يصعّدون إلى دور IAM مختلف عندما يحتاجون إلى تنفيذ عمليات الحذف. بل يمكنكم الفصل التام بين أذونات القراءة وأذونات الحذف في دورين منفصلين.
• إذا احتاجت إحدى المثيلات إلى الوصول إلى S3، فتأكدوا من تضييق نطاق الأذونات قدر الإمكان لتقتصر على الحد الأدنى من استدعاءات واجهات البرمجة المطلوبة تجاه الحد الأدنى من الموارد.
• عطّلوا SSE-C ما لم يكن ضروريًا تمامًا. فذلك يساعد على منع هجمات التشفير الصامت التي قد تحرمكم من الوصول إلى بياناتكم من دون أي مسار للاسترداد.
• استخدموا نقطة نهاية VPC للوصول إلى الحاوية، وأضيفوا فوقها سياسة موارد تسمح بالحذف من VPC المصدر فقط. عندها لن يتمكن المهاجم من استخدام بيانات الاعتماد خارج ذلك الـ VPC.
• فعّلوا تعدد الإصدارات و/أو AWS Backup و/أو النسخ المتماثل للحاويات. كل ذلك يضمن عدم فقدانكم للوصول إلى بياناتكم. إلا إذا أفسدتم سياسات IAM لديكم إفسادًا شديدًا وتركتم المجال للمهاجم. بعض هذه الخيارات يجب تفعيله عند إنشاء الحاوية، لذا قد تحتاجون إلى عملية ترحيل لتحقيق ذلك.

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

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

ما الجديد الذي تعلمته عن برامج الفدية في S3 خلال جلسة Re:Inforce؟

لم أكن أعلم أن برامج الفدية في S3 بهذا الشيوع. كما لم أكن أعلم أن النسخ ثم الحذف هو أسلوب الهجوم المفضّل. كنت أظن أنه استخدام تشفير KMS، وبات منطقيًا تمامًا سبب كون ذلك نظريًا ونادرًا. كنت على دراية بأدوات الرصد ووسائل الدفاع، لكن متحدثي AWS أبدعوا في ربطها جميعًا بطريقة واضحة وقابلة للتطبيق. لقد تجاوزت الجلسة توقعاتي بالتأكيد.

كيف يمكن لـ FireMon مساعدة مؤسستي في الحماية من برامج الفدية في S3؟

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

احجزوا عرضًا توضيحيًا اليوم، واطّلعوا على كيفية مساعدة FireMon لكم في حماية مؤسستكم من برامج الفدية في AWS.