full-disclosure - [FD] secuvera-SA-2020-01: Broken Object Level Authorization Vulnerability in OvulaRing-Webapplication

Open Source and information security mailing list archives

Message-ID: <cc6904b3ba794c17922f4c53ddad0496@TclanGroupware.secuvera.de>
Date: Fri, 6 Nov 2020 10:29:03 +0000
From: Tobias Glemser <tglemser@...uvera.de>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: [FD] secuvera-SA-2020-01: Broken Object Level Authorization
 Vulnerability in OvulaRing-Webapplication

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

Mit freundlichen Grüßen

 Tobias Glemser

+49 7032/9758-15 (Telefon)
+49 7032/9758-30 (Fax)
--
#secuvera: cyber: talk: Wöchentliche kostenfreie Webinare. Nächste Themen:
- Senden Sie Ihre Wünsche an info@...uvera.de
https://www.secuvera.de/cyber-talk
#Socialmedia
https://twitter.com/secuveragmbh
https://www.linkedin.com/company/secuvera-gmbh
https://de-de.facebook.com/secuveragmbh

#Rechtliche Informationen
secuvera GmbH
Siedlerstraße 22-24
71126 Gäufelden/Stuttgart
www.secuvera.de

Registergericht: Amtsgericht Stuttgart HRB 241704
Geschäftsführer: Tobias Glemser, Reto Lorenz

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives