الطرق العديدة للحصول على بيانات الاعتماد في AWS

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

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

AWS SDK يحدد عدد من الطرق التي يمكن من خلالها الحصول على أوراق الاعتماد.

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

2. سيكون المكان التالي الذي يجب أن تبحث فيه SDK هو المتغيرات البيئية. AWS Lambda، الذي تم إصداره في عام 2014 للتنفيذ بدون خادم، يضع بيانات اعتماد جلسة دور IAM في متغيرات البيئة باستخدام المتغيرات AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY، و AWS_SESSION_TOKEN (مستندات). قبل إصدار أدوار IAM في عام 2012، كانت بيانات مستخدم EC2 (http://169.254.169.254/latest/user-data) تم استخدامه أحيانًا لتخزين بيانات الاعتماد، وغالبًا ما يتم تعيينها كمتغيرات بيئة قبل الاستخدام.

3. سوف تقوم AWS SDK بعد ذلك بالبحث في الملفات ~/.aws/credentials و ~/.aws/config لأوراق الاعتماد. مسارات الملفات الأقدم التي قد يستخدمها SDK هي /etc/boto.cfg و ~/.boto.

4. نصل الآن إلى خدمة البيانات الوصفية للمثيلات (IMDS)، ولكنها ليست مجرد عنوان IP واحد كما يعتقد البعض.

كانت أدوار IAM أولاً تم إنشاؤه لمثيلات EC2 مرة أخرى في عام 2012، ويتضمن طلب HTTP GET إلى http://169.254.169.254/latest/meta-data/iam/security-credentials/ لمعرفة اسم دور IAM، وطلب لاحق للحصول على بيانات اعتماد الجلسة. في عام 2019، تم إصدار AWS IMDSv2 والذي أجرى بعض التغييرات على هذا (طلب PUT، واستجابة التحدي، ومدة البقاء، ورأس HTTP)، لتحسينه. يمكن أيضًا الوصول إلى هذا المضيف السحري عبر IPv6 عبر العنوان [fd00:ec2::254]. يدعم LightSail هذه الآلية نفسها للحصول على بيانات اعتماد الدور.

خدمات الحاويات في AWS، مثل ECS وEKS، استخدم متغير البيئة AWS_CONTAINER_CREDENTIALS_RELATIVE_URI جنبا إلى جنب مع عنوان IP 169.254.170.2 لتنفيذ HTTP GET إلى عنوان URL مثل http://169.254.170.2/v2/credentials/00000000-0000-0000-0000-000000000000. تعمل هذه التقنية نفسها أيضًا مع أجهزة SageMaker Notebooks وApp Runner وCodeBuild وBatch. قام نيك جونز بتوثيق الكثير من هذا وأكثر في منشور مدونته مفاتيح وصول AWS – مرجع.

يمكن أيضًا العثور على عنوان URL هذا من خلال متغير البيئة AWS_CONTAINER_CREDENTIALS_FULL_URI والذي يستخدمه CloudShell وIoT Greengrass 2.0 للوصول إلى خدمة تعمل على المضيف المحلي ويتطلب أيضًا تعيين رأس HTTP Authorization لقيمة متغير البيئة AWS_CONTAINER_AUTHORIZATION_TOKEN.

هويات جراب EKS يعمل بالمثل، ولكنه يستخدم عنوان IP 169.254.170.23 (أو [fd00:ec2::23] لـ IPv6). يستخدم هذا أيضًا المتغير AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE (افتراضيًا تم تعيينه على /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token) الذي يقوم بتعيين رأس HTTP Authorization إلى قيمة هذا الملف. يظهر هذا في AWS SDK هنا. يمكن العثور على بحث سابق أجراه Wiz حول هذه الميزة هنا.

إيرسا تم إصدار (أدوار IAM لحسابات الخدمة) قبل EKS Pod Identities، ويستخدم OIDC بدلاً من ذلك. تحتوي الحاوية على متغيرات البيئة AWS_WEB_IDENTITY_TOKEN_FILE و AWS_ROLE_ARN مجموعة، والتي تستخدم لإجراء مكالمة مجهولة إلى sts:AssumeRoleWithWebIdentity. بشكل افتراضي، سيكون ملف الرمز المميز في /var/run/secrets/eks.amazonaws.com/serviceaccount/token.

تصف الملاحظات الواردة أعلاه حول SDK طرق الحصول على دور IAM “العادي” لـ EC2 أو موارد أخرى، لكن هل تعلم أن EC2 يمكن أن يكون له دوران IAM مخصصان له؟

يتضمن AWS Systems Manager (SSM) وظيفة للوكيل لتشغيلها على موارد الحوسبة الخاصة بك والتي يمكنها بعد ذلك إدارتها عن طريق القيام بأشياء مثل تنزيل البرامج النصية وتنفيذها. قد يجد العملاء أنه من المفيد للوكيل الوصول إلى حاوية S3 أو الحصول على امتيازات AWS أخرى.

لتجنب فرض تعديل دور IAM المرتبط بجميع EC2s في الشركة للحصول على الامتيازات التي يريد شخص ما تعيينها لهذا الوكيل، أصدرت AWS التكوين الافتراضي لإدارة المضيف (DHMC). يجب تمكين هذه الميزة حتى تتمكن المنطقة من استخدامها. افتراضيًا، يستخدم هذا دور IAM مسمى AWSSystemsManagerDefaultEC2InstanceManagementRole ولديه سياسة AWS Managed IAM AmazonSSMManagedEC2InstanceDefaultPolicyولكن يمكن تغيير اسم الدور وإضافة المزيد من الامتيازات.

تستخدم هذه الميزة http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance ووصف بعض الخطوات الإضافية هنا في بحث أجراه إيدان ستيل. تتضمن الخطوات الإضافية للحصول على الاعتمادات إنشاء زوج مفاتيح يتم تخزينه فيه /var/lib/amazon/ssm/Vault/Store/EC2RegistrationKey.

التنشيط الهجين لمدير الأنظمة يعتمد أيضًا على وكيل SSM، ويستخدم لإدارة موارد الحوسبة داخل بيئة محلية أو موارد أخرى غير تابعة لـ AWS. يتم استخدام هذه التقنية نفسها أيضًا بواسطة ECS Anywhere وهي جزء من IoT Greengrass. يتم تنشيط الوكيل باستخدام رمز التنشيط ومعرف التنشيط، ثم يقوم بإنشاء الملفات /var/lib/amazon/ssm/Vault/Store/RegistrationKey و /var/lib/amazon/ssm/Vault/Store/InstanceFingerprint والتي يتم استخدامها بعد ذلك للحصول على أوراق الاعتماد. يعد الوصول إلى هذه الملفات كافيًا للحصول على بيانات الاعتماد. سيقوم وكيل SSM بعد ذلك بتخزين بيانات الاعتماد هذه /var/lib/amazon/ssm/credentials أو /root/.aws/credentials.

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

مطلق سراحه في عام 2022، تعد هذه الخدمة أحدث طريقة، في وقت كتابة هذا التقرير، توفرها AWS للموارد غير التابعة لـ AWS للوصول إلى أدوار IAM. ويستخدم أيضًا شهادات X.509 ويعمل في البداية فقط مع تلك الملفات المخزنة على القرص. في سبتمبر 2023أضافت AWS إمكانات PKCS#11، بحيث يمكن استخدام وحدات التشفير لتخزين الشهادات بدلاً من ذلك. إذا تم استخدام ذلك، فسيكون هناك عملية الاعتماد التي يمكن استدعاؤها للحصول على أوراق الاعتماد.

Cognito هي خدمة لهوية العميل وإدارة الوصول. ويقدم واجهة برمجة التطبيقات تسمى GetCredentialsForIdentity الذي تم تمرير معرف الهوية، وهو مجرد منطقة وقيمة GUID، وسيُرجع بيانات اعتماد جلسة AWS.

Datasync هي خدمة AWS للحفاظ على مزامنة موقعي تخزين، مثل التأكد من أن حاوية S3 تحتوي على نفس الملفات الموجودة في الدليل المحلي على الخادم. على الرغم من أنه لا يبدو أنه يحصل على بيانات اعتماد دور IAM، إلا أنه قادر على الوصول إلى كائنات حاوية S3 من خلال آلية غير موثقة. داخل /usr/local/aws-storage-gateway/var/ سوف يستخدم الملفات cert.pem و keypair.pem للمصادقة على AWS (بعض المناقشة هنا)، وسيستخدم وكيل مزامنة البيانات تلك العناصر لمزامنة حاوية S3 والدليل المحلي.

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