tl;dr 🔗

The parking company OnePark had a security issue that made it possible to systematically iterate through and change the username and password for all of their customers. By logging in afterwards one could collect personal data and even register your car's licence plate to be paid by that account.

Summary 🔗

Who:	OnePark
Severity level:	Medium
Reported:	November 2017
Reception and handling:	Fair
Status:	Fixed
Reward:	A thank you
Issue:	Information leak with personal information

Background 🔗

OnePark is one of Norway's biggest parking companies. They have many parking lots where they use automatic number-plate recognition (ANPR). You can just park your car, and then after picking it up you have 48 hours to go online to pay your bill. You don't even have to do any registration up front.

I got a tip that OnePark sends out the passwords for their accounts in clear text - and that is just never a good sign. So I decided to take a quick peek at their site.

Approach (technical stuff) 🔗

I took a look at OnePark's site with Vivaldi developer tools running. I created an account (you can create as many as you'd like using just an e-mail address) and looked at the communication with the server.

Most stuff looked good, but I hesitated when I saw that the web form for updating the user profile actually sent the user's ID back. The user ID was that classic integer that we so often see and therefore - when there's a vulnerability - opens up for an enumeration attack.

I didn't want to destroy anyone else's data so I created myself a another new account and tested by passing that user ID in when doing a profile update with a third e-mail address and a new password. The site didn't complain, and voilà - I was able to log in to the other account with that e-mail address and password. 🐱‍💻

But of course, now the data was all replaced by mine. So I removed all other form fields than the username (e-mail address) and password from the profile update request. This worked just fine.

Inside the other person's profile it was now possible to get hold of all the personal data, including any licence plate numbers and see if there was payment information added to the profile. The payment information was securely stored at a third-party site.

Since the user ID was an integer one could easily have set up a script to steal all the data. And not only that, one could also of course do vandalism by updating/removing the data. What's more - if one's a bit bold - one could register the licence plate of the car and remove it after the parking was paid for. I did not check if this would be easily spotted and trackable for either the customer or OnePark.

Security issues

One could systematically go through all customers and retrieve the following information: - Full name - Full address - Phone number - Licence plate numbers It was also possible to register any car's licence plate to be paid for with any account. In addition initial and reset passwords were sent in clear text by e-mail.

Reception and handling 🔗

Day zero 🔗

I found a contact form where I described the issue with the account takeover.

I got an automatic reply that they had received the e-mail.

Day 10 🔗

I got a phone call (even though I didn't give them my phone number) from one of the chiefs of the company that apparently was responsible for OnePark's web solution.

He thanked me a lot and clearly was proud that they had fixed the issue in just three hours. Three hours? Well, my message took 9.5 days to reach the people that could actually fix the issue.

While the handling of this company was good, OnePark seems to have quite a way to go on how to receive and handle issues around their online security.

Just after the phone call I also received an e-mail from the same chief - again thanking me and telling how they dealt with the issue.

Conclusion 🔗

Just like the security issue with the power company Norgesnett this is a case where the authorization check for updating the profile fails. And because of the usage of an integer as user ID it was possibly to systematically exploit the issue.

It is quite common for software developers to trust the authentication, but then forgetting the authorization check and user input sanitization.

And yet again we can see our personal data open for anyone to steal…