في 19 يوليو/تموز 2019، تلقت شركة كابيتال وان الرسالة التي تخشاها كل شركة حديثة: خرق البيانات. لقد أثر على أكثر من 106 مليون شخص. 140 رقم ضمان اجتماعي في الولايات المتحدة، ومليون رقم ضمان اجتماعي في كندا. 000 ألف حساب بنكي. إنه أمر غير سار، ألا توافق على ذلك؟
ولسوء الحظ، لم يحدث الاختراق في 19 يوليو/تموز. كما اتضح، بايج تومسون، المعروفة أيضًا باسم شارد، ارتكبها في الفترة ما بين 22 مارس و23 مارس 2019. وهذا هو منذ ما يقرب من أربعة أشهر. في الواقع، لم تتمكن شركة كابيتال ون من معرفة أن شيئاً ما قد حدث إلا من خلال مستشارين خارجيين.
تم القبض على موظف سابق في أمازون، ويواجه غرامة قدرها 250 ألف دولار، وخمس سنوات في السجن... ولكن لا يزال هناك الكثير من السلبية. لماذا؟ لأن العديد من الشركات التي تعرضت للاختراقات تحاول التهرب من مسؤولية تعزيز البنية التحتية والتطبيقات الخاصة بها في مواجهة الجرائم الإلكترونية المتزايدة.
على أية حال، يمكنك بسهولة البحث عن هذه القصة على جوجل. لن ندخل في التفاصيل الدرامية، لكننا سنتحدث عن فني جانب من الموضوع.
أولاً، ماذا حدث؟
كان لدى Capital One حوالي 700 دلو S3 قيد التشغيل، قامت Paige Thompson بنسخها وسحبها.
ثانيًا، هل هذه حالة أخرى من سياسة دلو S3 غير الصحيحة؟
لا، ليس هذه المرة. هنا تمكنت من الوصول إلى خادم به جدار حماية تم تكوينه بشكل غير صحيح ونفذت العملية بأكملها من هناك.
انتظر، كيف يكون هذا ممكنا؟
حسنًا، لنبدأ بالدخول إلى الخادم، على الرغم من أن لدينا القليل من التفاصيل. لقد قيل لنا فقط أن ذلك حدث من خلال "جدار حماية تم تكوينه بشكل خاطئ". لذا، فإن شيئًا بسيطًا مثل إعدادات مجموعة الأمان غير الصحيحة، أو تكوين جدار حماية تطبيق الويب (Imperva) أو جدار حماية الشبكة (iptables، ufw، shorewall، وما إلى ذلك). واعترفت شركة كابيتال وان بالذنب فقط وقالت إنها سدت الفجوة.
وقال ستون إن كابيتال وان لم تلاحظ في البداية ثغرة جدار الحماية، لكنها استجابت بسرعة بمجرد أن علمت بها. وقال ستون إن ما ساعد بالتأكيد هو أن المخترق ترك معلومات تعريفية رئيسية متاحة للعامة.
إذا كنت تتساءل عن سبب عدم خوضنا في هذا الجزء بعمق، فيرجى أن تفهم أنه بسبب المعلومات المحدودة، لا يمكننا إلا التكهن. وهذا لا معنى له، نظراً لأن عملية الاختراق اعتمدت على خلل تركه بنك Capital One. وما لم يخبرونا بالمزيد، فسنقوم فقط بإدراج جميع الطرق المحتملة التي تركت بها Capital One خادمها مفتوحًا بالإضافة إلى جميع الطرق المحتملة التي يمكن لأي شخص من خلالها استخدام أحد هذه الخيارات المختلفة. يمكن أن تتراوح هذه العيوب والأساليب من إغفالات غبية للغاية إلى أنماط معقدة بشكل لا يصدق. ونظراً لمجموعة الاحتمالات المتاحة، فإن هذا من شأنه أن يتحول إلى ملحمة طويلة بلا خاتمة حقيقية. لذا دعونا نركز على تحليل الجزء الذي يحتوي على الحقائق.
الاستنتاج الأول هو: معرفة ما تسمح به جدران الحماية الخاصة بك.
إنشاء سياسة أو عملية مناسبة لضمان أن ما يجب أن يكون مفتوحًا فقط هو المفتوح. إذا كنت تستخدم موارد AWS مثل مجموعات الأمان أو قوائم التحكم في الوصول إلى الشبكة، فمن الواضح أن قائمة التحقق الخاصة بالتدقيق قد تكون طويلة... ولكن نظرًا لأن العديد من الموارد يتم إنشاؤها تلقائيًا (مثل CloudFormation)، فمن الممكن أيضًا أتمتة تدقيقها. سواء كان الأمر عبارة عن برنامج نصي تم إعداده منزليًا لفحص الكائنات الجديدة بحثًا عن ثغرات، أو شيء مثل تدقيق الأمان في عملية CI/CD... هناك الكثير من الخيارات السهلة لتجنب ذلك.
والجزء "المضحك" من القصة هو أنه لو قامت شركة كابيتال وان بسد الثغرة منذ البداية... لم يكن أي من هذا ليحدث. وهكذا، وبصراحة، من المذهل دائمًا أن نرى كيف يمكن لشيء ما أن يكون حقيقيًا. بسيطة جدًا يصبح السبب الوحيد لاختراق الشركة. وخاصةً شركة كبيرة مثل Capital One.
إذن، المخترق موجود بالداخل - ماذا حدث بعد ذلك؟
حسنًا، بمجرد اختراقك لمثيل EC2... قد يحدث الكثير من الخطأ. إنك تمشي عمليا على حافة السكين إذا سمحت لشخص ما بالوصول إلى هذا الحد. ولكن كيف وصل إلى دلاء S3؟ لفهم هذا، دعونا نناقش أدوار IAM.
لذا، إحدى الطرق للوصول إلى خدمات AWS هي أن تكون مستخدمًا. حسنًا، هذا واضح جدًا. ولكن ماذا لو كنت تريد منح خدمات AWS الأخرى، مثل خوادم التطبيقات الخاصة بك، إمكانية الوصول إلى دلاء S3 الخاصة بك؟ هذا هو ما تم تصميم أدوار IAM من أجله. وهي تتكون من عنصرين:
- سياسة الثقة - ما هي الخدمات أو الأشخاص الذين يمكنهم استخدام هذا الدور؟
- سياسة الأذونات - ما الذي يسمح به هذا الدور؟
على سبيل المثال، قد ترغب في إنشاء دور IAM يسمح لمثيلات EC2 بالوصول إلى دلو S3: أولاً، يتم تعيين سياسة الثقة على الدور الذي يمكن لـ EC2 (الخدمة بأكملها) أو مثيلات محددة "الاستيلاء" على الدور. قبول الدور يعني أنه يمكنهم استخدام أذونات الدور لأداء الإجراءات. ثانيًا، تسمح سياسة الأذونات للخدمة/الشخص/المورد الذي "تولى الدور" بالقيام بشيء ما على S3، سواء كان ذلك الوصول إلى دلو محدد... أو أكثر من 700، كما في حالة Capital One.
بمجرد وصولك إلى مثيل EC2 مع دور IAM، يمكنك الحصول على بيانات الاعتماد بعدة طرق:
- يمكنك طلب بيانات التعريف الخاصة بالمثيل في
http://169.254.169.254/latest/meta-dataمن بين أشياء أخرى، يمكنك العثور على دور IAM مع أي من مفاتيح الوصول على هذا العنوان. بالطبع، فقط إذا كنت في حالة.
- استخدم AWS CLI…
إذا تم تثبيت AWS CLI، فسيتم تشغيله باستخدام بيانات الاعتماد من أدوار IAM، إذا كانت موجودة. كل ما تبقى هو العمل من خلال المثيل. بالطبع، إذا كانت سياسة الثقة الخاصة بهم مفتوحة، كان بإمكان بايج أن تفعل كل شيء بشكل مباشر.
لذا فإن جوهر أدوار IAM هو أنها تسمح لمورد واحد بالعمل نيابة عنك على الموارد الأخرى.
الآن بعد أن فهمت أدوار IAM، يمكننا التحدث عن ما فعلته Paige Thompson:
- تمكنت من الوصول إلى الخادم (نسخة EC2) من خلال ثقب في جدار الحماية.
سواء كان الأمر يتعلق بمجموعات الأمان/قوائم التحكم في الوصول أو جدران حماية تطبيقات الويب الخاصة بهم، فمن المرجح أن يكون من السهل إغلاق الثغرة، كما هو مذكور في الوثائق الرسمية.
- بمجرد وصولها إلى الخادم، كانت قادرة على التصرف "كما لو" كانت الخادمة نفسها.
- نظرًا لأن دور IAM الخاص بالخادم سمح لـ S3 بالوصول إلى أكثر من 700 دلو، فقد تمكن من الوصول إليها.
منذ تلك اللحظة، كل ما كان عليها فعله هو تنفيذ الأمر. List Buckets، ثم الأمر Sync من AWS CLI…
. إن منع هذا النوع من الضرر هو السبب وراء استثمار الشركات بشكل كبير في حماية البنية التحتية السحابية، وDevOps، وخبراء الأمن. وما مدى قيمة وفعالية التكلفة للانتقال إلى السحابة؟ لدرجة أنه حتى في مواجهة تحديات الأمن السيبراني المتزايدة باستمرار !
العبرة من القصة: تأكد من أمنك؛ إجراء عمليات التدقيق بشكل منتظم؛ احترم مبدأ الحد الأدنى من الامتيازات فيما يتعلق بسياسات الأمن.
( (يمكنكم الاطلاع على التقرير القانوني كاملا).
المصدر: www.habr.com
