CVE-2026-14871 - BOLA / IDOR في osTicket ajax.tickets.php

انتهاك تفويض المستوى الكائن (BOLA): مرجع غير مباشر غير آمن للكائن (IDOR)
include/ajax.tickets.php ← دالة viewField()
تم الإبلاغ بواسطة @JF0x0r · 27 مارس 2026
الحالة: تم الإصلاح - تم إصدار التصحيح في osTicket v1.17.8 / v1.18.4

نظرة سريعة

من أنا

أنا خوان فيليبي أوز (@JF0x0r)، باحث أمني شغوف بأمان المصادر المفتوحة. لا أفعل هذا من أجل المكافآت، بل أفعله لأنني أعتقد أن الأدوات التي يعتمد عليها الناس يجب أن تكون آمنة. عندما أجد شيئًا، أبلغ عنه بمسؤولية، وأوثقه بشكل صحيح، ثم أشاركه علنًا بمجرد إصلاحه.

ما وجدته

أثناء إجراء مراجعة يدوية للكود للنظام الفرعي AJAX في osTicket، لاحظت شيئًا غير طبيعي في ajax.tickets.php. تتعامل دالة viewField() مع الطلبات لعرض بيانات حقول التذاكر - وهي تسترد كائن التذكرة وتتحقق من وجود الحقل. لكنها لا تتحقق أبدًا مما إذا كان الوكيل الطالب لديه الإذن بالوصول إلى تلك التذكرة.

لا يوجد checkStaffPerm(). لا يوجد التحقق من القسم. لا شيء.

هذا يعني أن أي وكيل موثّق، حتى لو كان مقيدًا بشكل صارم بقسم واحد، يمكنه قراءة حقول التذاكر من أي قسم آخر في النظام، فقط من خلال معرفة أو تخمين ticket_id و field_id. هذه أعداد صحيحة متسلسلة. من السهل تعدادها.

ما يجعل هذا واضحًا بشكل خاص هو المقارنة مع editField()، الدالة الشقيقة التي توجد فوقها مباشرة في نفس الملف. تقوم editField() بشكل صحيح باستدعاء $ticket->checkStaffPerm($thisstaff, Ticket::PERM_EDIT) وتعيد HTTP 403 عند المخالفة. كان التصحيح مطبقًا بالفعل على عمليات الكتابة — ولكن لم يتم تطبيقه أبدًا على عمليات القراءة.

إثبات المفهوم: عرض حي

سجلت عرضًا توضيحيًا كاملاً للاستغلال من البداية إلى النهاية في بيئة مختبرية خاضعة للتحكم:

يسير الفيديو من خلال:

• إعداد المختبر مع قسمين معزولين (Dept-A و Dept-B)
• الوكيل agent_a الموثّق مع وصول مقصور على Dept-A فقط
• صياغة الطلب غير المصرح به الذي يستهدف تذكرة سرية في Dept-B
• الخادم يعيد HTTP 200 مع كشف بيانات حقل التذكرة المحظورة
• إعادة التشغيل بعد التصحيح تظهر HTTP 403 — تم رفض الإذن

يقوم سكربت exploit.py في هذا المستودع بأتمتة السلسلة الكاملة (المصادقة ← التعداد ← الوصول غير المصرح به إلى الحقل) وتم استخدامه أثناء التقييم لتأكيد أن المشكلة تتجاوز الاختبارات اليدوية.

التأثير

• كشف البيانات الحساسة - يمكن لأي وكيل قراءة حقول التذاكر السرية عبر جميع الأقسام
• تصعيد امتياز أفقي - يتم تجاوز الحدود بين الأقسام تمامًا
• التعداد الجماعي - الأعداد الصحيحة المتسلسلة ticket_id / field_id تجعل الكشط الجماعي تافهًا
• انتهاك سرية متعدد المستأجرين - يتعارض مع مبدأ التصميم الأساسي لنموذج عزل الأقسام في osTicket

الإصلاح

إدراج سطر واحد في viewField()، مباشرة بعد استرداد كائن التذكرة - يعكس تمامًا ما تفعله editField() بالفعل بشكل صحيح. التفاصيل التقنية الكاملة، والفرق، وتفصيل CVSS موجودة في التقرير المرفق.

📄 BOLA_IDOR_osTicket_Report_v2.pdf

✅ التصحيح الرسمي (تم التأكيد من قبل فريق osTicket)

أكد osTicket التقرير وقام بتنفيذ التخفيف عن طريق إضافة $ticket->checkStaffPerm($thisstaff) قبل حل/عرض الحقل المطلوب - مما يعكس التحقق الموجود بالفعل في editField(). يجب أن يكون للموظفين الآن وصول إلى التذكرة الأصلية قبل عرض بيانات الحقل.

يوصي osTicket بفترة ترقية قصيرة قبل مشاركة خطوات الاستغلال الكاملة علنًا. يتبع هذا المستودع هذه التوجيهات - انظر الجدول الزمني للإفصاح أدناه.

الجدول الزمني للإفصاح

الملفات في هذا المستودع

.
├── README.md                        # هذا الملف
├── BOLA_IDOR_osTicket_Report_v2.pdf # تقرير الإفصاح التقني الكامل
├── exploit.py                       # سكربت أتمتة إثبات المفهوم
└── PoC_osTicket.mov                 # نسخة محلية من فيديو العرض التوضيحي

الإفصاح المسؤول

أبلغت عن هذا بشكل خاص إلى فريق أمان osTicket قبل نشر أي شيء. تم جعل هذا المستودع عامًا فقط بعد انتهاء فترة الإفصاح المسؤول، والآن بعد أن تم إصدار التصحيح الرسمي، تتوفر الكتابة الكاملة. إذا كنت أحد القائمين على osTicket ولديك أسئلة، فلا تتردد في التواصل مباشرة عبر GitHub.

تم العثور عليه بواسطة @JF0x0r · أمان المصادر المفتوحة مهم.