Description du NVD :

TripSpark VEO Transportation-2.2.x-XP_BB-20201123-184084 NovusEDU-2.2.x-XP_BB-20201123-184084 permet des entrées non sécurisées dans les paramètres du corps POST provenant des utilisateurs finaux sans les nettoyer à l'aide d'une logique côté serveur. Il était possible d'injecter des commandes SQL personnalisées dans les requêtes de recherche « Student Busing Information ».

Détail technique

La surface exposée

Les districts déploient la page « Student Busing Information » sur leur site web public afin que les parents puissent consulter l'affectation du bus d'un élève. Elle demande un numéro N d'élève et une date de naissance, et elle est intentionnellement non authentifiée.

Le champ numéro N poste sous le nom editOEN. La date de naissance poste sous cboxMonth, cboxDay et cboxYear. editOEN est le paramètre injectable.

Injection aveugle

Contrairement à de nombreuses applications ASP.NET de cette époque, cette page ne renvoie pas les erreurs de base de données. Il n'y a aucune différence visible entre une requête bien formée et une requête cassée, donc les techniques en bande sont une impasse.

Les requêtes empilées s'exécuent, ce qui est tout ce dont on a besoin.

Exploitation hors bande via xp_dirtree

master.dbo.xp_dirtree énumère un répertoire. Étant donné un chemin UNC, SQL Server s'authentifie auprès de l'hôte cible via SMB avant de le lire. Le pointer vers un écouteur transforme une injection silencieuse en injection visible :

La requête est une POST ASP.NET WebForms ordinaire, d'environ 4 700 octets, dont la majeure partie est __VIEWSTATE. Requête complète dans poc/exploited-request.http, charges utiles dans poc/payloads.sql.

Authentification capturée

Avec smbserver.py d'Impacket à l'écoute sur un hôte sur Internet public, le serveur de base de données à l'intérieur du réseau du district s'authentifie en sortie :

Deux choses méritent d'être nommées explicitement. Premièrement, il s'agit d'un formulaire non authentifié accessible sur Internet atteignant une base de données de production. Deuxièmement, ce serveur de base de données était autorisé à établir des connexions SMB sortantes vers des hôtes Internet arbitraires, ce qui a rendu l'injection aveugle observable.

Impact

Au-delà de l'injection elle-même, l'identifiant NTLMv2 capturé pour le compte de service SQL Server a été le point d'appui initial lors de l'engagement original. À partir de là, l'évaluation a escaladé jusqu'à la compromission totale du domaine et de la forêt Active Directory du client.

Les données à risque sont les dossiers de transport des élèves : noms, adresses personnelles, bus attribué, arrêt attribué, heures de prise en charge et itinéraires d'éducation spécialisée. C'est un emploi du temps indiquant où des enfants identifiables se trouveront physiquement à des heures connues.

Reproduction

Contre une instance de laboratoire que vous possédez ou que vous êtes autorisé à tester :

1. Chargez la page « Student Busing Information ».
2. Démarrez un écouteur sur un hôte que la cible peut atteindre :
   root@kitploit:~

   sudo smbserver.py c . -smb2support
   

3. Soumettez le formulaire avec la charge utile xp_dirtree de poc/payloads.sql dans le champ numéro N, en remplaçant par votre propre IP. Capturez et rejouez la POST plutôt que de taper dans le navigateur si le champ a une limite de longueur côté client, car cette limite n'existe pas côté serveur.
4. Une version vulnérable produit une authentification SMB entrante du compte de service SQL Server. Rien ne change dans la réponse HTTP.
5. La confirmation temporelle fonctionne également si vous ne pouvez pas recevoir de SMB entrant :
   root@kitploit:~

   123'; waitfor delay '0:0:10';--
   

Contenu du dépôt

Les identifiants clients dans les captures sont expurgés. Les adresses des écouteurs proviennent de l'engagement original et sont depuis longtemps obsolètes. Remplacez-les par les vôtres lors de la reproduction.

Correction

1. Requêtes paramétrées. Liez editOEN en tant que paramètre et la charge utile devient une chaîne inerte, quel que soit son contenu.
2. Validation côté serveur. Un numéro d'élève est court et numérique. Appliquez cela sur le serveur, pas dans le formulaire.
3. Privilège minimum pour le compte de base de données. Le compte derrière une page de consultation publique doit lire les affectations de bus et rien d'autre. Révoquez l'accès à xp_dirtree et aux autres procédures stockées étendues.
4. Filtrage du trafic sortant. Un serveur de base de données de district scolaire n'a aucune raison d'ouvrir des connexions SMB vers Internet. Bloquer le port 445 sortant supprime le canal hors bande.
5. Séparez le formulaire public du système de référence. La page utilisée par les parents doit interroger un réplica restreint, pas la base de données de production qui contient également les itinéraires d'éducation spécialisée.

Chronologie

Articles

• Compte personnel : https://sedriclouissaint.com/blog/tripspark-veo-sql-injection-cve-2021-3262/
• Show Up Show Out Security : https://susos.co/blog/sqlspark-sql-injection-in-tripspark-veo-transport-cve-2021-3262

Avertissement

Publié après divulgation, à des fins défensives et éducatives. N'exécutez pas ces charges utiles contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite de test. Si vous administrez un déploiement de district, l'action utile ici est de demander à votre fournisseur, par écrit, si les requêtes derrière vos formulaires publics sont paramétrées.