NVD description:

TripSpark VEO Transportation-2.2.x-XP_BB-20201123-184084 NovusEDU-2.2.x-XP_BB-20201123-184084 allows unsafe data inputs in POST body parameters from end users without sanitizing using server-side logic. It was possible to inject custom SQL commands into the "Student Busing Information" search queries.

Technical detail

The exposed surface

Districts deploy the "Student Busing Information" page on their public website so parents can look up a student's bus assignment. It asks for a student N Number and a birthdate, and it is intentionally unauthenticated.

The N Number field posts as editOEN. The birthdate posts as cboxMonth, cboxDay and cboxYear. editOEN is the injectable parameter.

Blind injection

Unlike many ASP.NET applications of this vintage, this page does not echo database errors. There is no visible difference between a well-formed query and a broken one, so in-band techniques are a dead end.

Stacked queries do execute, which is all that is needed.

Out-of-band exploitation via xp_dirtree

master.dbo.xp_dirtree enumerates a directory. Given a UNC path, SQL Server authenticates to the target host over SMB before reading it. Pointing it at a listener turns a silent injection into a visible one:

The request is an ordinary ASP.NET WebForms POST, roughly 4,700 bytes, most of which is __VIEWSTATE. Full request in poc/exploited-request.http, payloads in poc/payloads.sql.

Captured authentication

With Impacket's smbserver.py listening on a host on the public internet, the database server inside the district's network authenticates outbound:

Two things are worth naming explicitly. First, this is an unauthenticated internet-facing form reaching a production database. Second, that database server was permitted to make outbound SMB connections to arbitrary internet hosts, which is what made the blind injection observable.

Impact

Beyond the injection itself, the captured NTLMv2 credential for the SQL Server service account was the initial foothold on the original engagement. From there the assessment escalated to full compromise of the client's Active Directory domain and forest.

The data at risk is student transportation records: names, home addresses, assigned bus, assigned stop, pickup times, and special education routing. That is a schedule of where identifiable children will physically be at known times.

Reproduction

Against a lab instance you own or are authorised to test:

1. Load the "Student Busing Information" page.
2. Start a listener on a host the target can reach:
   root@kitploit:~

   sudo smbserver.py c . -smb2support
   

3. Submit the form with the xp_dirtree payload from poc/payloads.sql in the N Number field, substituting your own IP. Capture and replay the POST rather than typing into the browser if the field has a client-side length limit, since that limit does not exist server side.
4. A vulnerable build produces an inbound SMB authentication from the SQL Server service account. Nothing changes in the HTTP response.
5. Time-based confirmation also works if you cannot receive inbound SMB:
   root@kitploit:~

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

Repository contents

Client identifiers in the captures are redacted. The listener addresses are from the original engagement and are long dead. Substitute your own when reproducing.

Remediation

1. Parameterised queries. Bind editOEN as a parameter and the payload becomes an inert string no matter what is in it.
2. Server-side validation. A student number is short and numeric. Enforce that on the server, not in the form.
3. Least privilege for the database account. The account behind a public lookup page needs to read bus assignments and nothing else. Revoke access to xp_dirtree and the other extended stored procedures.
4. Egress filtering. A school district database server has no reason to open SMB connections to the internet. Blocking outbound 445 removes the out-of-band channel.
5. Separate the public form from the system of record. The page parents use should query a restricted replica, not the production database that also holds special education routing.

Timeline

Write-ups

• Personal account: 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

Disclaimer

Published after disclosure, for defensive and educational use. Do not run these payloads against systems you do not own or have written authorisation to test. If you administer a district deployment, the useful action here is to ask your vendor, in writing, whether the queries behind your public forms are parameterised.