CS Technologies — Evolution Vulnerabilities

TL:DR

Multiple vulnerabilities were identified within the CS Technologies Evolution software package, these vulnerabilities allow an unauthorised attacker to remotely add users, open doors, and crash the application to prevent active monitoring. These can be found in the CVEs listed below.

Proof of Concept

Multiple vulnerabilities were identified within the CS Technologies Evolution software package, these vulnerabilities allow an unauthorised attacker to remotely add users, open doors, and crash the application to prevent active monitoring. These can be found in the CVEs listed below.

CVE-2024–29836 — Broken Authentication on USER_CHANGE in Evolution Controller allows unauthenticated account creation and takeover

CVE-2024–29837 — Poor session management in Evolution Controller allows administrator functionality for unauthenticated connections

CVE-2024–29838- Unsanitised variable on DAL_ADD in Evolution Controller causes application level denial of service and crash

CVE-2024–29839 — Broken Access control on DESKTOP_EDIT_USER_GET_CARD in Evolution Controller allows unauthenticated attackers to retrieve card data values.

CVE-2024–29840 — Broken Access control on DESKTOP_EDIT_USER_GET_PIN_FIELDS in Evolution Controller allows unauthenticated attackers to retrieve PIN field values

CVE-2024–29841 — Broken Access control on DESKTOP_EDIT_USER_GET_KEYS_FIELDS in Evolution Controller allows unauthenticated attackers to retrieve keys values

CVE-2024–29842 — Broken Access control on DESKTOP_EDIT_USER_GET_ABACARD_FIELDS in Evolution Controller allows unauthenticated attackers to retrieve ABACARD values

CVE-2024–29843 — Broken Access control on MOBILE_GET_USERS_LIST in Evolution Controller allows unauthenticated user enumeration

Remediation for these issues can be done via disabling of the Web interface, which will prevent the exploitation of all issues found within these CVEs.

What the heck

Okay, if you’re like me, you want to try and learn more about how Access Controllers work, and how those systems interact, you need to purchase an Access Controller, these are usually found within the depths of your facilities, the magic box which administers access to your doors, elevators, parking garages and alike. These access controllers cost a lot of money, most vendors will charge you a whole bucket load of cash if you want to purchase one, so a lot of people just don’t look into this field. I decided to buy one, this one came with a free application to control the software.

The application is called Evolution, and is made by CS-Technologies, it’s currently in version 2.04.561 as of the time of writing, and can still be downloaded for free off their website. Normally, the way the package works is you’ll install the software on a computer which runs the server or standalone, and this will be physically connected, either via RS485 or IP (with the expansion to the board).

Once this is setup, you can administer the application either via the Host Machine, or via a client (if enabled in server mode), or their Web Interface (if enabled). This lets you administer doors, users, access levels, lifts and other controls, if you want to administer users, open, close and lockout doors, control access groups, and view event logs, the UI lets you do it.

One of the interfaces caught my interest, the Web frontend allows for a lot of routes which could be taken, and after turning on Burp Active Scan, I knew it was where I wanted to poke about, because the application crashed immediately. This lead to the first issue, an unauthenticated application crash, which can be triggered remotely, and this means logs and alarms won’t show up for anyone monitoring that system.

The first issues

Once I started poking about, I logged in and found out a web path called user_change, this normally was used to add or remove users to the application, what I realized is there were no cookies used for the application. This was very weird, because I couldn’t figure out how authentication or authorization was working, so I poked about in the user_change function, and logged in and out, and realised it was showing a logged out error.

I checked the application, and noticed the user I sent when logged out was there, the application was returning an error, but still processing the request. This was the first issue, and once I realised that, I noticed there was a variable saying who added the user, and if you changed it to a different int, it would change the UI to show a different user added them.

Normal Output when Adding a User

There was an interesting trick here, modifying the int to 0 would hide the user being added to the application from the event log, and wouldn’t show the user in the menu.

By modifying the int of our user in the request

Then we get to the weirdness of authentication and authorization, this process took me a bit to figure out, but I setup the application on a new server to verify this and tested it, finally it makes sense. The application had a bunch of URI paths which appeared, with the same structure;

ID1_Device%20Areas
ID1_Device%20Areas
ID1_Users

The structure was an ID associated with the users ID within the application, and the path to access, this meant the application was not validating a cookie, nor an IP address connecting to it, but if a user had been signed in via the Web UI. If the user was signed in, then the path could be triggered, or else it wouldn’t be accessible.

Now, you might ask, how can you tell if a user is signed in, well, the event log, which is publicly accessible via the webpage and is the root page for the website will show you who is logged in or not.

Finally, we have a set of issues all inside of the DESKTOP_EDIT_USER functions, which you can usually use to access card data and user data associated with a user, such as the Card and Facility code, pin for the user, abacard, silkey, and magstripe information when accessed.

This was an interesting endpoint, it returned data when logged in, but when logged out, it returned the data just with an error of Operator Expired but still responds with the data, all you need to do is supply a valid user ID.

This can be tied with MOBILE_GET_USERS_LIST which returns a user and if they’re enabled or disabled for a site by sending a generic request, it will return the users access type based upon a colour, and their user reference ID for their user. Once you’ve done this, you can enumerate every user for the system, find out how they enter the building, and the data needed to access it just like them.

Proofs of Concept

As of publishing, there are multiple people who host this with publicly facing web interfaces mostly port forwarded, so at this stage, I’ve opted to not publish the proof of concept. There are enough details within the CVEs to reverse engineer these issues, however it does not mean I should reduce the barrier of entry and release this exploit publicly while no patch is offered by the company.

Disclosure Timeline

Responsible Disclosure was attempted in this, there were no existing security contacts for the organization, no security.txt. and multiple calls and emails have been sent with a 90+30 day disclosure offered

1. Attempted to call CS-Technologies — Left Voice message — 10-Jan-2024
2. Called 1300 CYBER 1 to inquire, directed to General Inquiry — 11-Jan-2024
3. Submitted General inquiry form for ACSC — 11-Jan-2024
4. Automated Response Received from ACSC — 12-Jan-2024
5. Responded to ACSC Requesting Information on their policy — 12 Jan 2024
6. Email sent to info@ email address for company — 16 Jan 2024
7. Contacted via phone, answered by reception, informed they would tell head engineer to call me, no response — 23 Feb 2024
8. Working with CNA to get allocations completed — 21 March 2024
9. Email sent by CNA to company — 5 April 2024
10. 90 Day Disclosure — 15 April 2024