Auditing the Oral-B App (v5.0.0)

Upon quickly assessing the Oral-B app (com.pg.oralb.oralbapp), the following findings have been made:

Hardcoded AES parameters (CVE-2018-5298) and twitter keys



These parameters are stored in the class OralBApplication and also get used there:



Using the twitter secrets, it's possible to create bearer tokens impersonating the Oral-B twitter application. The secrets stored in the app are application tokens only - in my tests it was not possible to authenticate in user context.

The stored AES parameters are used to encrypt and decrypt the locally stored shared preferences in the class called Preferences:


Because of the static key, an attacker can gain access to user data more easily by leveraging access to the preferences XML file.

Tracking

Upon running the app, the user automatically gets tracked. There is no opt-in required, it's enabled by default.

As you can see, third party advertising providers are allowed to gain access to the user location automatically. Unique advertising IDs are automatically assigned.


It's possible to add your dentist to the Oral-B app. This process uses a server side API to search for a specific dentist in your location. This allows Oral-B to access your location and gain information about your dentist:


Of course, facebook tracking is also enabled by default:


Last but not least, the weather functionality of course also requires and transmits your current location:



Please note no transmission of user specific brushing data has been identified. However, there is a cache that saves your last brushing sessions <:

Popular posts from this blog

Auditing NQ Contacts Backup & Restore 1.1

Image
NQ Contacts Backup & Restore is an android app that allows users to backup and restore contact data (as vcard) to/from the remote NQ server. For the audit, the android app was the primary target.  Note: The app shares its code base with NQ Mobile Security & Anti Virus  - hence the odd class names for a simple contact backup app. Lack of HTTPS usage  When logging in or transmitting data, the app communicates with the remote server via HTTP. This can be exploited in various ways. One of these is sniffing the request when a user logs in:   As you can see, the username is being transmitted in cleartext.  The password is hashed with SHA-1. An attacker can now crack the SHA-1 hash (because that's pretty easy nowadays): Additionally, an attacker could use the sniffed hash to download the stored contacts from the server directly. As described later, the attacker can also access transmitted contact data. Vulnerability type: Plaintext data tran...
Read more

Auditing WriteDiary.com (CVE-2017-15581 & CVE-2017-15582)

Image
General note: The developer and owner of both the webapp and android app has been contacted multiple times to develop a quick fix for the issues addressed in this blog post and a vulnerability concerning the webapp which isn't described here. However, no response has been received. WriteDiary consists of a webapp ( WriteDiary.com ) and an android app  (version 4.72). For the audit, the android app was the primary target. CVE-2017-15581 : Lack of HTTPS-usage, lack of user data encryption when transmitting In the "Diary with lock" (aka WriteDiary) application 4.72 for Android, neither HTTPS (check strings.xml for api_url_prod :  http ://diary.adpog.com/api2)  nor other encryption is used for transmitting data, despite the documentation that the product is intended for "a personal journal of secrets and feelings," which allows remote attackers to obtain sensitive information by sniffing the network during LoginActivity or NoteActivity execution. ...
Read more