في 19 يوليو 2019 ، تلقى كابيتال وان بنك رسالة مفادها أن كل شركة حديثة تخاف من حدوث تسرب للبيانات. أثرت على أكثر من 106 مليون شخص. 140،000 أرقام الضمان الاجتماعي الولايات المتحدة ، مليون أرقام الضمان الاجتماعي كندا. 80،000 حساب بنكي. غير سارة ، توافق؟
لسوء الحظ ، لم يحدث القرصنة على الإطلاق في 19 يوليو. كما اتضح فيما بعد ، قام بايج تومبسون ، المعروف أيضًا باسم
Erratic ، بأداء ما بين 22 مارس و 23 مارس 2019. هذا ما
يقرب من أربعة أشهر . في الواقع ، فقط بمساعدة المستشارين الخارجيين عرفت كابيتال وان أن شيئًا ما قد حدث.
توقفت موظفة الأمازون السابقة ، وهي تواجه غرامة قدرها 250 ألف دولار وخمس سنوات في السجن ... لكن هناك الكثير من السلبية. لماذا؟ لأن العديد من الشركات التي تم اختراقها تحاول تجنب المسؤولية عن تعزيز البنية التحتية والتطبيقات الخاصة بها وسط الجرائم الإلكترونية المتزايدة.
في أي حال ، يمكنك بسهولة جوجل هذه القصة. لن ندخل في الدراما ، لكن نتحدث عن الجانب
التقني للأشياء.
أولاً ، ماذا حدث؟
في Capital One ، كان هناك حوالي 700 دلو S3 قام بنسخها Paige Thompson وتقليص حجمها.
ثانياً ، هل هذه حالة أخرى لسياسة دلو S3 مكونة بشكل غير صحيح؟
لا ، ليس هذه المرة. حصلت هنا على حق الوصول إلى خادم مزود بجدار حماية تم تكوينه بشكل غير صحيح ومن هناك أجرت العملية بالكامل.
مهلا ، كيف يكون هذا ممكن؟
حسنًا ، لنبدأ بتسجيل الدخول إلى الخادم ، على الرغم من أن لدينا بعض التفاصيل. قيل لنا فقط أن هذا حدث من خلال "جدار الحماية تكوينها بشكل غير صحيح". لذلك ، شيء بسيط مثل إعدادات مجموعة الأمان الخاطئة أو تكوين جدار حماية تطبيق الويب (Imperva) ، أو جدار حماية الشبكة (iptables ، ufw ، shorewall ، إلخ). واعترف كابيتال وان بالذنب وقال إنه أغلق الفتحة.
قال ستون إن Capital One لم تلاحظ مبدئيًا ضعف جدار الحماية ، لكنها استجابت بسرعة بمجرد اكتشافها. وقال ستون إن هذا ساعده بالطبع أن القراصنة تركوا معلومات التعريف الرئيسية المتاحة للجمهور.
إذا كنت مهتمًا بالسبب وراء عدم بحثنا في هذا الجزء ، ففهم أنه نظرًا لمحدودية المعلومات ، يمكننا التكهن فقط. هذا لا طائل منه بالنظر إلى أن الاختراق يعتمد على الفجوة التي خلفها Capital One. وإذا لم يخبرونا المزيد ، فسنقوم بسرد جميع الطرق الممكنة التي تركت بها Capital One خادمها مفتوحًا مع كل الطرق الممكنة التي يمكن أن يستخدمها شخص ما لأحد هذه الخيارات المختلفة. هذه الفجوات والأساليب يمكن أن تتراوح بين إشراف غبي إلى حد كبير وأنماط معقدة بشكل لا يصدق. بالنظر إلى مجموعة الاحتمالات ، سيتحول هذا إلى ملحمة طويلة دون استنتاج حقيقي. لذلك ، سوف نركز على تحليل الجزء الذي لدينا فيه الحقائق.لذلك الاستنتاج الأول: معرفة ما تسمح به جدران الحماية الخاصة بك
وضع سياسة أو عملية للتأكد من أن ما هو مفتوح فقط مفتوح. إذا كنت تستخدم موارد AWS ، مثل مجموعات الأمان أو قوائم التحكم في الوصول للشبكة ، فمن الواضح أن قائمة التحقق للتحقق يمكن أن تكون طويلة ... ولكن نظرًا لأن العديد من الموارد يتم إنشاؤها تلقائيًا (على سبيل المثال CloudFormation) ، يمكنك أيضًا إجراء تدقيقها تلقائيًا. سواء كان برنامج نصي مؤقتًا يقوم بمسح بحثًا عن أشياء جديدة للعيوب ، أو ما يشبه التدقيق الأمني في عملية CI / CD ... هناك العديد من الخيارات البسيطة لتجنب ذلك.
الجزء "الممتع" من القصة هو أنه إذا أغلقت Capital One الفتحة من البداية ... فلن يحدث شيء. وبالتالي ، بصراحة ، من الصدمة دائمًا أن نرى حقيقة أن شيئًا
بسيطًا جدًا يصبح السبب الوحيد لشركة اختراق. لا سيما كبيرة مثل كابيتال وان.
لذلك ، القراصنة في الداخل - ماذا حدث بعد ذلك؟
حسنًا ، بعد اقتحام مثيل EC2 ... قد يحدث الكثير. أنت تمشي على طول حافة السكين تقريبًا إذا سمحت لشخص ما بالذهاب بعيدًا. لكن كيف وصلت إلى دلو S3؟ لفهم هذا ، دعونا نناقش أدوار IAM (أدوار 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 ، يتم تحميلها بأوراق اعتماد من أدوار IAM ، إن وجدت. يبقى فقط للعمل من خلال المثيل. بالطبع ، إذا كانت سياسة الثقة الخاصة بهم مفتوحة ، يمكن للصفحة أن تفعل ذلك مباشرة.
وبالتالي ، فإن جوهر أدوار IAM هو أنها تسمح لمورد واحد بالتصرف من اسمك على موارد أخرى.
الآن بعد أن أدركت أدوار IAM ، يمكننا الحديث عما فعله Page Thompson:
- حصلت على حق الوصول إلى الخادم (مثيل EC2) من خلال ثقب في جدار الحماية
سواء أكان الأمر مجموعات أمنية / قوائم ACL أو جدران الحماية الخاصة بتطبيقات الويب الخاصة بهم ، فقد يكون من السهل للغاية سد الثقب كما هو مذكور في السجلات الرسمية.
- بمجرد وصولها إلى الخادم ، كانت قادرة على التصرف "كما لو" كانت هي الخادم
- نظرًا لأن دور خادم IAM قد سمح لـ S3 بالوصول إلى أكثر من 700 مجموعة ، فقد تمكنت من الوصول إليها
من الآن فصاعدًا ، كانت تستطيع فقط تشغيل أمر
List Buckets ، ثم أمر
Sync من AWS CLI ...
يقدر بنك كابيتال وان الأضرار الناجمة عن القرصنة بمبلغ يتراوح بين 100 و 150 مليون دولار . منع مثل هذا الضرر هو السبب في أن الشركات تستثمر الكثير في حماية البنية التحتية السحابية و DevOps وخبراء الأمن. وما مدى أهمية وفعالية التكلفة في الانتقال إلى السحابة؟ لدرجة أنه حتى في مواجهة المزيد والمزيد من قضايا الأمن السيبراني ،
نما إجمالي السوق السحابية العامة بنسبة 42 ٪ في الربع الأول من عام 2019 !
معنوي هذه القصة: تحقق سلامتك. إجراء عمليات تدقيق منتظمة ؛ احترام مبدأ أقل امتياز للسياسات الأمنية.
(يمكنك الاطلاع على التقرير القانوني الكامل هنا).