Summary
A vulnerability in The Housing Director, an Adirondack Solutions student housing management platform popular with higher education organizations, allows access to the Application Programming Interface (API) via authentication bypass, including institutional Single Sign On (SSO).
Further Information
The REN-ISAC received notification from an external researcher of potential vulnerabilities in the API of The Housing Director. While not confirmed, other Adirondack Solutions products may be potentially impacted. The vulnerability includes three major elements.
- Unauthenticated API access/institutional SSO bypass (OWASP A07-2021 Identification and Authentication Failures)
- Weak/insufficient access control to certain records and functions (OWASP A01-2021 Broken Access Control)
- Possible (unconfirmed) arbitrary data write to backend systems (OWASP A03 Injection)
Element 1: Unauthenticated API access/institutional SSO bypass (OWASP A07-2021 Identification and Authentication Failures)
When signing onto The Housing Director login page, the researcher found that replacing the uid POST parameter with %22%22 (URL-encoded double-quotes back-to-back) in the authentication request yields user data for what appears to be an administrative account with the username “Self-Service.”
Image 1 illustrates the researcher’s request using uid %22%22.
Image 2 reflects the authentication response to uid of “” as “USERNAME” : “Self Service.”
It’s possible this “Self-Service” account is intended for administrative operations like updating employee and payment information (tax forms, wage information) and student information (registration, records, tax forms). The returned “TOKEN” string is passed along with a hash for authentication in subsequent requests. The hash is seemingly derived from the token string via client-side JavaScript. Generating that hash is left as an exercise to the reader.
Element 2: Weak/insufficient access control to certain records and functions (OWASP A01-2021 Broken Access Control)
Image 3 illustrates the HTTP request that uses the TOKEN and HASH fields in a Base64-encoded body.
Image 4 depicts the response to the request shown in Image 3.
The request is formatted like
{"t":"{\"TOKEN\":\"<tokenHere>\",\"USERID\":-2,\"HASH\":\"<hashHere>\"}","c":"thdss","m":"GetMyHousingSetup"}
which after Base64-encoding becomes
eyJ0Ijoie1wiVE9LRU5cIjpcIjx0b2tlbkhlcmU+XCIsXCJVU0VSSURcIjotMixcIkhBU0hcIjpcIjxoYXNoSGVyZT5cIn0iLCJjIjoidGhkc3MiLCJtIjoiR2V0TXlIb3VzaW5nU2V0dXAifQ==
The Base64-encoded methods such as GetMyHousingSetup or EmailRoomMate appear to not do authorization checks and allow even low-privileged student users to invoke their use against any student ID or, in the case of the EmailRoomMate, spoof emails with customized messages such as:
{"t":"{\"TOKEN\":\"<tokenHere>\",\"USERID\":-2,\"HASH\":\"<hashHere>\"}","c":"thdss","m":"EmailRoomMate","nvpairs":"[{\"Name\":\"THDSS_FROM_Email\",\"Value\":\president@somefake.edu\},{\"Name\":\"student_id\",\"Value\":<studentId>},{\"Name\":\"Use_Preferred_First\",\"Value\":-1},{\"Name\":\"FirstName\",\"Value\":\"<FirstName>\"},{\"Name\":\"LastName\",\"Value\":\"<LastName>\"},{\"Name\":\"student_email\",\"Value\":\"<fromStudentEmail>\"},{\"Name\":\"roommate_email\",\"Value\":\"<toStudentEmail>\"},{\"Name\":\"email_text\",\"Value\":\"<arbitraryBodyText>\"},{\"Name\":\"NAME_TAG\",\"Value\":\"<arbitraryTag>\"}]"}
Once Base64-encoded and POST’d to the correct API endpoint, it will send an email to the desired student from the spoofed THDSS_FROM_Email field if the domain matches an institution that uses The Housing Director (which can serve to enumerate institutions using the THD service).
Element 3: Possible (unconfirmed) arbitrary data write to backend systems (OWASP A03 Injection)
While no supporting evidence, there’s some concern that the InsertLogEntry method may allow arbitrary data in the URL field which, if true, could be used for purposes like stored XSS or attempts to inject Log4j strings:
{"t":"{\"TOKEN\":\"<tokenHere>\",\"USERID\":-2,\"HASH\":\"<hashHere>\"}","c":"thdss","m":"InsertLogEntry","nvpairs":"[{\"Name\": \"StudentID\", \"Value\":<idHere>},{\"Name\": \"LogAction\", \"Value\":\"Logged In\"},{\"Name\": \"LogActionDetails\", \"Value\":\"\"},{\"Name\": \"AppInUse\", \"Value\":\"Self-Service\"},{\"Name\": \"URL\", \"Value\":\https://<institution>.datacenter.adirondacksolutions.com/<institutionEndpoint>/navigation/student/my-screen\}]"}
Mitigation and Detection
Because this is a cloud-hosted Software as a Service (SaaS) solution, common best practices such as locking down access may be infeasible. While there appears to be some logging functionality available to the service provider (Adirondack), it’s unknown how much of that information they make available to customers. Some patches have been deployed by the vendor into the cloud service. Additionally, because this is cloud hosted, it does not qualify for a CVE identifier.
Adirondack did recently inform us that they have some self-hosted solutions, but we’ve been unable to access those environments for testing and are therefore unable to request a CVE. For self-hosted versions, it’s suggested to reach out to one’s account rep with the vendor to acquire any available patches.
Disclosure Timeline
2022-Mar-30: Collected initial information from third-party researcher
2022-Mar-30: Privately disclosed finding to vendor via support email support@adirondacksolutions.com
2022-Mar-30: Attempted to follow-up with call to support number listed on site but no answer after remaining on hold for over 5 minutes
2022-Apr-13: Sent follow-up email to vendor requesting acknowledgement of receipt
2022-Apr-21: Called phone support again and reached support agent to whom vulnerability details were directly emailed
2022-Apr-21: Received email response from vendor’s IT Director acknowledging receipt of disclosure
2022-Apr-22: Email from vendor’s IT Director sharing remediation progress on each of the issues in the disclosure
2022-Apr-25: Email from vendor’s IT Director with further progress
2022-May-05: Requested update via email and received reply that hardened sanitation checking and improved authorization checks would be in the next scheduled update
2022-May-12: Vendor’s IT Director noted that they had alerted their clients to the vulnerabilities, and some corrections have been rolled into their cloud hosted services
2022-June-06: TLP:WHITE public disclosure
Acknowledgments
Nicholas Dubois (Dragon Eye Intelligence LLC) who discovered and disclosed the issue to REN-ISAC so that it could be responsibly disclosed to the vendor and shared among the Higher Ed community. Also, credit goes to him for the proofs of concept.