This week, we had vulnerabilities in remote car control apps and GPS-enabled watches. We also take a look at the API security trends in microservices and serverless architectures, and consumer electronics.
MyCar is a remote control system that is installed in some cars under its own name or under a variety of brands, such as Carlink, Linkr, Visions MyCar, or MyCar Kia. The system has a mobile app that shows the location of your car and lets you remotely start and stop, or lock and unlock the vehicle. Needless to say, all this is done through APIs, and the APIs in question had a huge vulnerability. Individual user accounts were created with an API call that was made using admin credentials. These credentials were hard-coded inside the mobile app. Once attackers got the admin credentials from the code, they could control any car in the system.
Another GPS-enabled watch, Tic Toc Track from Australia, turned out to have flawed APIs security. The issue was again Insecure Direct Object Reference (IDOR). Attackers could use any account to get access to the APIs. After that, they could simply enumerate the ID parameter when making API calls. There was no authorization check, so each new ID gave the attackers the access to another user’s device. The attackers could access all data of any user ( including location, full names, phone numbers…), substitute the shown GPS location, call the watch, and so on.
See more stories on API security flaws in other GPS-enabled watches in issues 7, 18, 19, and 26.
Microservices and serverless architectures are leading to proliferation of APIs. They are also changing the landscape of app and API security. Ory Segal and Amit Klein have published their discussion on what this means:
- WAFs cannot make insecure apps secure.
- Security needs to start from day 1.
- Distributed nature makes analysis and protection harder, but gives new opportunities.
IoT and consumer devices
A lot of consumer devices these days are managed using mobile apps calling REST APIs and connecting through home WiFi and a cloud backend. Andrew Useckas from ThreatX writes about the risks that emerge with this approach and how to mitigate them:
- Attacks against the devices themselves
- Typically center on device identity
- Solution: use individual secure keys
- Attacks against APIs
- Emerge because the calls go through the internet
- API JSON payloads are used to start all the usual API attack scenarios, such as SQL injections, cross-site scripting…
- Solution: pay attention to the data definition quality for the API inputs (and outputs)
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy