CVE-2026-52813 — اجتياز المسار في Gogs يؤدي إلى تنفيذ أوامر عن بُعد عبر خطافات Git (تحليل دفاعي)

بحث أمني / writeup موجّه للفريق الأزرق (الدفاعي). لا يحتوي هذا المستودع على أي PoC مسلّح. الباحثون الذين يحتاجون إلى إعادة الإنتاج يجب أن يستخدموا الـ PoC العامة المشار إليها في الاستشارة الأمنية الرسمية (advisory).

TL;DR

عندما ينشئ Gogs منظمة، نموذج الويب يحتوي على تحقق من الأحرف AlphaDashDot يمنع /، لكن REST API POST /api/v1/user/orgs لا يحتوي عليه. يستطيع المهاجم إرسال اسم منظمة يحتوي ../ عبر الـ API، متجاوزًا التحقق حتى os.MkdirAll(repoutil.UserPath(org.Name), 0777) (internal/database/org.go:165)، مما يكتب دليل المستودع في أي مسار في نظام الملفات. وبالدمج مع شجرة العمل المؤقتة لمحرر الويب في Gogs (local-r/<repo_id>/)، يمكن وضع hooks/update خبيث داخل checkout محلي لمستودع آخر، ليُنفَّذ تلقائيًا بواسطة git → RCE بصلاحيات مستخدم git.

الإصدارات المتأثرة والمعالجة

الترقية هي الوسيلة الوحيدة للإصلاح الجذري:

# Docker
docker pull gogs/gogs:0.14.3
# أو من الكود المصدري
git checkout v0.14.3 && go build

تخفيف مؤقت (عند تعذّر الترقية):

• إغلاق التسجيل المفتوح (app.ini → [service] DISABLE_REGISTRATION = true)، مما يخفض الشرط المسبق من «بدون مصادقة» إلى «يتطلب حسابًا موجودًا مسبقًا»؛
• إضافة قواعد WAF على مستوى الوكيل العكسي (nginx/Caddy/Traefik) لاعتراض الطلبات POST /api/v1/user/orgs و POST /api/v1/org/*/repos التي تحتوي الحقول username / name في جسم الطلب على .. أو / (انظر detection/)؛
• تقييد صلاحيات الكتابة لحاوية Gogs خارج /data/gogs/data/tmp/ (selinux/apparmor).

تحليل السبب الجذري

1. عدم تماثل التحقق: نموذج الويب يتحقق، الـ API لا يتحقق

نموذج الويب (internal/form/org.go، v0.14.2):

type CreateOrg struct {
    OrgName string `binding:"Required;AlphaDashDot;MaxSize(35)"` // 正则 ^[a-zA-Z0-9._-]+$
}

الـ API (internal/route/api/v1/org/org.go، v0.14.2):

// api.CreateOrgOption (go-gogs-client) 的绑定 tag:
type CreateOrgOption struct {
    UserName string `json:"username" binding:"Required"` // ← 没有 AlphaDashDot!
}

→ يمكن لحقل username في POST /api/v1/user/orgs حمل أي أحرف والوصول مباشرةً إلى طبقة قاعدة البيانات.

2. طبقة قاعدة البيانات تتحقق فقط من الأسماء المحجوزة، وليس من مجموعة الأحرف

isNameAllowed في internal/database/users.go:1532 يمنع الأسماء المحجوزة والبادئات/اللواحق فقط (مثل admin، -bot)، ولا يتحقق من مجموعة الأحرف، لذلك يمكن لـ ../ المرور.

3. مستقبل المسار (sink) بدون تطهير

internal/repoutil/repoutil.go (v0.14.2):

func UserPath(user string) string {
    return filepath.Join(conf.Repository.Root, strings.ToLower(user)) // ← 直接拼接
}

internal/database/org.go:165:

os.MkdirAll(repoutil.UserPath(org.Name), os.ModePerm) // org.Name 含 ../ → 任意路径写入

4. استغلال شجرة العمل local-r لوضع الـ hook

عندما يعالج Gogs تحرير الملفات عبر Web/API، يقوم بعمل checkout للمستودع إلى /data/gogs/data/tmp/local-r/<repo_id>/. و<repo_id> يساوي تمامًا id المستودع في قاعدة البيانات. يقوم المهاجم بـ:

1. إنشاء مستودع شخصي باسم writer، والحصول على id == n؛
2. إنشاء منظمة اختراق للمسار عبر الـ API بالاسم username = "../../../../data/gogs/data/tmp/local-r/n/nested" → يقع الدليل الفعلي داخل شجرة عمل writer؛
3. إنشاء مستودع باسم rce-x تحت هذه المنظمة → يقع في local-r/n/nested/rce-x.git؛
4. استنساخ writer، وإضافة nested/rce-x.git/hooks/update كـملف عادي ثم commit و push (فهو يقع داخل شجرة عمل writer)؛
5. تشغيل عملية ملفات على writer عبر الـ API → يعمل Gogs بـ git في local-r/n/ → ينفذ git hooks/update → RCE.

النقطة الأساسية: الـ hook الخبيث يدخل عبر push عادي كـمحتوى عادي للمستودع، ولا يتطلب تفعيل ENABLE_GIT_HOOKS — وهذا هو الفرق بينه وبين مسار «إساءة استخدام خطافات git التقليدية».

تحليل تفصيلي لفرق التصحيح (patch diff) في patch/ANALYSIS.md.

الاكتشاف

القواعد الكاملة في detection/:

• قواعد Sigma: detection/sigma/ — تغطي محاولات الهجوم (طلبات API تحتوي ../) والاستغلال الناجح (الهبوط على نظام الملفات)
• استعلامات SIEM: detection/queries.md — Splunk / Elastic / Kibana / Loki
• مؤشرات الاختراق (IOCs): detection/iocs.md — آثار في نظام الملفات، توقيعات في السجلات، وخصائص أسماء المستخدمين

الأهم من بينها قاعدتان:

1. على مستوى WAF / الوكيل العكسي: اعتراض الطلبات POST /api/v1/user/orgs و POST /api/v1/org/*/repos التي تحتوي الحقول username/name في جسم JSON على .. أو /.
2. فحص نظام الملفات: ظهور أدلة فرعية غير متوقعة تحت /data/gogs/data/tmp/local-r/*/ (nested/، rce-*.git، hooks/update).

أدوات الدفاع

• tools/check_version.py — ماسح إصدارات غير تدخّلي: يفحص عبر GET /api/v1/version ما إذا كان مثيل Gogs < 0.14.3، ويدعم الفحص الجماعي وإخراج CSV، ومناسب لجرد الأصول.

لا يوفر هذا المستودع أدوات استغلال مسلّحة. لإعادة الإنتاج، استخدم الـ PoC العامة المشار إليها في الاستشارة الرسمية (advisory) وفقط في بيئة معزولة تُنشئها بنفسك.

بيئة التجارب

قواعد detection/ تحتاج إلى التحقق على إصدار Gogs متأثر. يوفر lab/docker-compose.yml بيئة Gogs 0.14.2 معزولة ليقوم الفريق الأزرق باختبار ما إذا كانت قواعد الكشف تنطلق أم لا. لا تُعرِّضها للإنترنت العام، للاستخدام المحلي فقط.

الخط الزمني

المراجع

• الاستشارة الرسمية: https://github.com/gogs/gogs/security/advisories/GHSA-c39w-43gm-34h5
• PR الإصلاح: https://github.com/gogs/gogs/pull/8334
• OSV: https://osv.dev/vulnerability/CVE-2026-52813
• إصدار Gogs 0.14.3: https://github.com/gogs/gogs/releases/tag/v0.14.3

⚠️ حول الادعاء الخاطئ بشأن «حقن معاملات gitrebase»

يوجد على الإنترنت من وصف هذه الـ CVE بأنها "تنفيذ أوامر عن بُعد عبر حقن معاملات gitrebase في Gogs" — وهذا خطأ. لا علاقة لهذه الثغرة بـ git rebase / gitrebase، فالسبب الجذري هو اجتياز المسار في الـ API. تتوافق هذه الوثيقة مع تحليل الثغرة الفعلي.

الترخيص

MIT — انظر LICENSE.