تزوير الطلبات من جانب الخادم (SSRF): استغلال البيانات الوصفية السحابية

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

في هذا المقال الفني المتعمق، تبحث Cayvora Security في كيفية استخدام SSRF كسلاح لاستغلال خدمات البيانات الوصفية لحالة السحابة (IMDS)، وتجاوز جدران الحماية الداخلية، واستخراج بيانات اعتماد IAM شديدة الحساسية.

آليات عمل SSRF

تستوعب تطبيقات الويب الحديثة الروابط (URLs) بشكل متكرر لجلب صور الملفات الشخصية، أو استيراد البيانات، أو التفاعل مع خطافات الويب (webhooks). إذا كان خادم التطبيق يثق بسذاجة في الرابط المقدم:

# نقطة نهاية مبنية ببايثون Flask غير آمنة
@app.route('/fetch_image')
def fetch_image():
    url = request.args.get('url')
    # الخادم يقوم بطلب للرابط بدون أي تحقق!
    response = requests.get(url) 
    return response.content

إذا قدم المهاجم http://localhost:6379/ (المنفذ الافتراضي لـ Redis)، فسيقدم خادم الويب طلبًا إلى قاعدة بيانات Redis الداخلية الخاصة به، متجاوزًا تمامًا جدران الحماية الخارجية.

استغلال البيانات الوصفية السحابية (IMDS)

النتيجة الأكثر كارثية لـ SSRF في البيئات السحابية هي استغلال خدمة البيانات الوصفية للمثيل (IMDS). توفر IMDS لمثيلات EC2 بيانات الاعتماد المؤقتة الديناميكية لدور IAM المرتبط بالمثيل. يمكن الوصول إلى الخدمة عبر عنوان IP ثابت وغير قابل للتوجيه: 169.254.169.254.

استغلال IMDSv1 في أنظمة AWS

إذا كان التطبيق قيد التشغيل على AWS ويستخدم IMDSv1، فيمكن للمهاجم استخراج أوراق الاعتماد من خلال SSRF بسيط.

1. العثور على اسم الدور: يقدم المهاجم عنوان URL التالي: http://169.254.169.254/latest/meta-data/iam/security-credentials/ يستجيب الخادم باسم دور IAM، مثال: S3-Admin-Role.

2. استخراج بيانات الاعتماد: يُلحق المهاجم اسم الدور بعنوان URL: http://169.254.169.254/latest/meta-data/iam/security-credentials/S3-Admin-Role يجلب الخادم الضعيف البيانات الوصفية ويعيد استجابة JSON شديدة الحساسية:

{
  "Code" : "Success",
  "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token" : "IQoJb3JpZ2luX2VjEJv..."
}

يقوم المهاجم الآن باستيراد بيانات الاعتماد هذه ويتولى هوية S3-Admin-Role، مما يتيح له قراءة/كتابة دلاء S3 وتدمير البنية التحتية.

تجاوز مرشحات وفلاتر SSRF

حتى عند الإغلاق، يتجاوز المهاجمون عوامل التصفية باستخدام: 1. تشفير IP البديل: العشري http://2852039166/ و السداسي العشري http://0xA9FEA9FE/ 2. إعادة ربط DNS (DNS Rebinding): يسجل المهاجم مجالًا يتم حله أولاً إلى عنوان IP شرعي لتخطي التحقق، ثم إلى عنوان IP الداخلي عندما يطلب الخادم المورد فعلياً.

كيفية تأمين الأنظمة

1. فرض IMDSv2 عبر حسابات AWS

قدمت AWS خدمة IMDSv2 للتخفيف من هجمات SSRF. وهي تتطلب ترويسة HTTP مخصصة وتعتمد على طلب نوع PUT للحصول على رمز مميز قبل الاستعلام عن البيانات الوصفية. لتعطيل الهجوم بالكامل يجب إيقاف الاصدار الأول:

aws ec2 modify-instance-metadata-options     --instance-id i-1234567890abcdef0     --http-tokens required

2. التحقق الصارم من الروابط (URL)

استخدم قائمة سماح صارمة للمجالات المقبولة وتأكد من أن عنوان IP الذي تم حله لا يقع ضمن نطاقات IPv4 الخاصة أو نطاق الارتباط المحلي (169.254.0.0/16).

الخاتمة

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