secuvera-SA-2020-01: Broken Object Level Authorization Vulnerability in OvulaRing-Webapplication

Affected Products
   OvulaRing Webapp Version 4.2.2 (older releases have not been tested)

References
   https://www.secuvera.de/advisories/secuvera-SA-2020-01.txt
   https://owasp.org/www-project-api-security/ API1:2019 Broken Object Level Authorization

Summary:
   "OvulaRing is an easy and accurate way to find out about your cycle health and to accurately determine your fertile days - developed by gynecologists and suitable for all cycle types."
   According to the privacy statement only the following data is being stored:
    - Number of current Sensor
    - Username
    - Password
   The Username is individually generated and printed on each package. To be
   able to reset the password, a user is able to save an "E-Mail-Hash". If this
   is done correctly, there is no correllation between the data measure and
   stored and personal data. The design strongly seems to follow the "privacy
   by default" rules.

   The privacy statement also declares, access to the Sensors (SNS) data is only
   granted to the individual user. This is wrong. Due to a broken object level
   authorisation, anyone with access to the application is able to access any
   sensor data.


Effect:
   Anyone with access to the application is able to read other SNS-Data. The SNS-ID
   seems to be auto incremented.

Attack:
   Login with the demo user account or demo doctors account. Use the example given to
   brute-force the SNS-IDs. A good starting point seems to be 32-00000. Increment by 1.
   If you found an SNS with data, here's a way to browse the data sets more comfortable:
   Login again as demo user or demo doctor. As soon as the users original SNS-ID is sent
   to the browser, subsitute with the one, you want to have a look at.

Example:
   GET /v3/data_series?callback=$Something&access_token=$Something&sns%5B%5D=$dDesiredSns&level=1&from=$UnixTimestamp&to=$UnixTimestamp&mode=default&fine=true
   Sends back measurepoints over the time given in the call for the SNS-ID.

Solution:
   Fixed in Version 4.2.8 

Disclosure Timeline:
   2020/07/16 vendor contacted
   2020/07/16 vendor response
   2020/07/23 vendor verified vulnerability
   2020/08/09 vendor sent informational update
   2020/10/16 vendor informed about the fixed version
   2020/11/06 public disclosure