tl;dr: Calamp which provides the backend for a lot of really well known car alarm systems had a misconfigured reporting server that gave direct access to most of its production databases, allowing anyone to access and modify all data.
Oh father , what have you done?
So their mobile app was extra cool.It had ssl connection and ssl pinning so I had to use my usual unpinning process to get ANYTHING.After a couple of hours of testing stuff and trying several random known tricks we always hit a wall. After that, we tried to login on their webpage and tried again any trick that came to mind. Once again everything was correctly returned or we did not have authorization to see it.
Dead ends everywhere
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Calamp.com server
Then we noticed that the app was not connecting solely to mysmartstart.com domain but mostly to a third party domain (https://colt.calamp-ts.com/). Again with ssl pinning and all proper bells and whistles. This panel seemed to be the frontend for Calamp.com Lender Outlook service. We tried our user created from the viper app, to login and it worked! This was a different panel which seemed to be targeted to the companies that have multiple sub-accounts and a lot of vehicles so that they can manage them.We tried creating a sub-account and tried escalating to our parent account but despite the feeling that I had this was another dead end. We tried directly accessing other ids and everything else we could think of but everything was correctly secured.And then it hit us…
Reporting server
All the reports were provided by another server, dedicated for that ,running tibco jasperreports® software.None of us were familiar with that so we had to improvise. Removing all the parameters we found out that we were already logged in with a limited user that had access to A LOT of reports.We had to run all those reports for our vehicles right? Well the ids for the user was passed automatically from the frontend but now we had to provide them from the panel as an input.And…well..we could provide any number we wanted.
So we could see all the reports for all the vehicles (including location history). NOT ANOTHER TRACKMAGEDDON PLEASE! Then George saw that there were also data sources with usernames (but masked passwords and no way for us to export them , as we were a limited user). We could not create a report or an adhoc or pretty much anything else, but we could copy paste existing ones and edit them so we can do pretty much anything.We could also edit the report and add arbitrary XSS to steal information but this was not something that we (or anyone in their right lawful mind) would want to do. Then it hit us again! Inputs were raw sql queries!
Running on all their production databases (yes it was not only colt that used that report server but connect device outlook also, a database that we did not touch at any point). So we created a new input with a select * with our user whose id we already knew and we got back data. I then changed the password via the mobile app reran the query and saw another hash. We tried an update query with the old hash and yeap the account was accessible with the old password via the mobile app.Full account takeover and device manipulation. At that point we stopped as we had to report everything. But first I had to call my father. When I told him what I could do without his username/password he answered “Well you could have just asked for them”…
Reporting the vulnerability
Now this was rather tricky (and colamp.com promised that they will fix that by updating their policy so that researchers can have a direct way of reaching out to them with any vulnerabilities -now available at https://www.calamp.com/bug-report/ -).Below are the dates of communication.We were rather pushy on this as this was a full takeover of A LOT OF CARS (both directed and viper apps have each over half a million downloads on android app store and the connect database was also exposed which controls a large number of IoT devices).
- 2018–05–01: Sent support request requesting proper disclosure steps
- 2018–05–01: Asked via twitter dm on @calamp for an email to sent report
- 2018–05–02: Reached out via linkedin to a cybersecurity employee at calamp for direction on proper disclosure
- 2018–05–02: Reached out to CERT which guided us to the proper communication channel
- 2018–05–02: Calamp answered and acknowledged issue
- 2018–05–03: Calamp updated us that their are working on a fix
- 2018–05–12: Calamp notified us that it was patched and after verification we are releasing this.
Exploitation of the bug
- Well the very obvious just change the user password to a known one go to the car, unlock, start and leave.
- Get all the reports of where everyone was
- Stop the engine while someone was driving ?
- Start the engine when you shouldn’t.
- Get all the users and leak.
- As we haven’t actually seen the hardware we might be able to pass can bus messages though the app ?
- Get all the IoT devices from connect database or reset a password there and start poking around.
- Really the possibilities are endless…
Was my smartstart / vehicle / IoT vulnerable?
We honestly have no idea how many companies (or vehicles) use this backend service. It seems that all the brands that are at directed.com website were using that backend so it is somewhat safe to assume that they were vulnerable. It also seems that a lot of companies use the telematic cloud of calamp.com (both for vehicles , fleet management and IoT) so you will have to reach out to your operator and ask them as calamp stated that they coordinated directly with their customers.
Postmortem
If you are an end user try to buy only well known products that you believe will have quality in all aspects and will be updated once a vulnerability is found.This (like hakvision) is another example of things that you did to be more secure and ended up making you more vulnerable.
If you are a company, please for the love of whatever is holy create a security@ email and monitor it.Write down a proper vulnerability disclosure policy and stick with it.When creating users always have least privilege principle in mind! Reporting user could and should have only read only access. And never trust any input from the user, or think that the user will use your app in your intended way.