Qui suis-je

Je suis Juan Felipe Oz (@JF0x0r), un chercheur en sécurité passionné par la sécurité des logiciels open source. Je ne fais pas cela pour des primes, je le fais parce que je crois que les outils sur lesquels les gens comptent doivent être sûrs. Quand je trouve quelque chose, je le signale de manière responsable, je le documente correctement, et je le partage publiquement une fois corrigé.

Ce que j'ai trouvé

Lors d'une revue manuelle du code du sous-système AJAX d'osTicket, j'ai remarqué quelque chose d'anormal dans ajax.tickets.php. La fonction viewField() gère les demandes de visualisation des données de champ de ticket - et elle récupère bien l'objet ticket et valide l'existence du champ. Mais elle ne vérifie jamais si l'agent demandeur a réellement la permission d'accéder à ce ticket.

Pas de checkStaffPerm(). Pas de validation de département. Rien.

Cela signifie que tout agent authentifié, même strictement limité à un seul département, peut lire les champs de ticket de n'importe quel autre département du système, simplement en connaissant ou en devinant le ticket_id et le field_id. Ce sont des entiers séquentiels. Faciles à énumérer.

Ce qui rend cela particulièrement flagrant, c'est la comparaison avec editField(), la fonction sœur située juste au-dessus dans le même fichier. editField() appelle correctement $ticket->checkStaffPerm($thisstaff, Ticket::PERM_EDIT) et renvoie un HTTP 403 en cas de violation. Le correctif était déjà implémenté pour les écritures — il n'a simplement jamais été appliqué aux lectures.

Preuve de concept : Démonstration en direct

J'ai enregistré une démonstration complète de bout en bout de l'exploitation dans un environnement de laboratoire contrôlé :

La vidéo présente :

• Configuration du laboratoire avec deux départements isolés (Dept-A et Dept-B)
• Agent agent_a authentifié avec un accès restreint au seul Dept-A
• Élaboration de la requête non autorisée ciblant un ticket confidentiel du Dept-B
• Le serveur renvoyant HTTP 200 avec les données du champ de ticket restreint exposées
• Rejeu après le correctif montrant HTTP 403 — Permission refusée

Le script exploit.py dans ce dépôt automatise la chaîne complète (authentification → énumération → accès non autorisé aux champs) et a été utilisé lors de l'évaluation pour confirmer que le problème s'étend au-delà des tests manuels.

Impact

• Divulgation de données sensibles - tout agent peut lire les champs de ticket confidentiels dans tous les départements
• Escalade de privilèges horizontale - les limites départementales sont complètement contournées
• Énumération massive - les entiers séquentiels ticket_id / field_id rendent le scraping en masse trivial
• Violation de confidentialité multi-locataire - contredit le principe de conception fondamental du modèle d'isolation des départements d'osTicket

Le correctif

Une insertion d'une seule ligne dans viewField(), immédiatement après la récupération de l'objet ticket - ce qui reflète exactement ce que editField() fait déjà correctement. Les détails techniques complets, le diff et la décomposition CVSS se trouvent dans le rapport joint.

📄 BOLA_IDOR_osTicket_Report_v2.pdf

✅ Correctif officiel (Confirmé par l'équipe osTicket)

osTicket a confirmé le rapport et a mis en œuvre l'atténuation en ajoutant $ticket->checkStaffPerm($thisstaff) avant de résoudre/afficher le champ demandé - ce qui reflète la vérification déjà présente dans editField(). Les membres du personnel doivent désormais avoir accès au ticket parent avant de visualiser les données de champ.

osTicket recommande un court délai de mise à niveau avant de partager publiquement les étapes complètes de l'exploitation. Ce dépôt suit cette directive - voir Calendrier de divulgation ci-dessous.

Calendrier de divulgation

Fichiers dans ce dépôt

Divulgation responsable

J'ai signalé ceci en privé à l'équipe de sécurité d'osTicket avant de publier quoi que ce soit. Ce dépôt a été rendu public seulement après la fenêtre de divulgation responsable, et maintenant qu'un correctif officiel a été publié, le rapport complet est disponible. Si vous êtes un mainteneur d'osTicket et avez des questions, n'hésitez pas à me contacter directement via GitHub.

Trouvé par @JF0x0r · La sécurité open source compte.