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