Earlier this year I started to look at food deliveries, more specifically fresh and local vegetables and fruits. There are quite a few companies that provide that service in Germany. Really nice.
I found a local one that delivers to my home. They offer a convenient web shop where I registered.
The weird part was the registration confirmation: they did set the initial password to my post-code. That immediately caught my attention. The user names are numeric and seem to be incrementing. That can’t be good. So I wrote a small piece of python code that just enumerates users and tries to login with post-codes from the area. And bingo, I got quite a few successful logins. I did verify one of them by looking at the user profile of the poor person that did not change their password. And yes, I could see personal data.
Since my goal was not to steal data I stopped there and did concentrate at the API again. I did some googling to see if there are similar shops. And yes, actually quite a few. They are all provided by oekobox-online.de. A quick check of a arbitrary other shop in another part of Germany proved that the same method of guessing the postcode and just enumerating the user-ids also worked to perform a successful login.
The API is actually well documented by the vendor:
I personally think that a verbose API answer like in the table below adds to the problem. This allows the attacker to first figure out if a user-id is valid before starting to guess the password. Instead the API should just return success of fail, but now why it failed.
The tblocked response was also not well implemented. First of all, it took quite a while for me to be blocked. And even if one is blocked, logins with the correct username/password combo still work.
Contacting the vendor
I did contact the vendor the same day (06.01.2021) and received an answer less than 24 after that. This seems to be one of the few cases where responsible disclosure actually works.
The communication was friendly even though we have quite different opinions about the actual issue. The vendor was already aware of it, but because customers like the easy workflow did not change it.
Nevertheless, a few weeks later (02.02.2021) I received a mail with promising news:
- Affected customers have been informed
- The rate-limit is now better enforced
- Login via user-ID will be disabled soon. Only logon via email-address will be possible
- Better passwords will be enforced step-by-step in the next weeks
To be honest, I did not check if all of that is actually properly implemented now. I am to lazy for that.