Auditing NQ Contacts Backup & Restore 1.1

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 transport
Affected Product Code Base: NQ Contacts Backup & Restore - 1.1
Affected Component: Basically every component executing network action. For the login process: ContactAccountLogin and ContactAccountSwitch
Impact: Information Disclosure of sensitive data (login data)

RC4 encryption with static key

 The app uses the RC4 stream cipher to encrypt/decrypt password stored in the android shared preferences. The file looks like this:





The decryption routine, which can be found in DataUtils, look as follows:



The stored value is base64-decoded and passed to the RC4 algorithm. The first parameter of decryptForXml is a static key, as you can see here:


Using this knowledge, it's easy to decrypt the stored password value from the shared preferences XML file:


 This makes it easier for an attacker to decrypt login data of users.

Vulnerability type: Usage of a static encryption key
Affected Product Code Base: NQ Contacts Backup & Restore - 1.1
Affected Component: NetQinSharedPreferences
Impact: Information Disclosure of login data

DES encryption with static key

When syncing user data (e.g. contacts as vcards), the app uses DES encrypted zip files, as you can see in the class ServerBackupDoing$7 :






 In the class DesCript, there are two static keys:



The key named keyByte is used to create a KeySpec, which represents the key being used to encrypt/decrypt data.


As there is no HTTPS in place, it's therefore possible for an attacker to gain access to sensitive contact data.

Vulnerability type: Usage of a static encryption key
Affected Product Code Base: NQ Contacts Backup & Restore - 1.1
Affected Component: ServerBackupDoing, DesCript
Impact: Information Disclosure of user data (contact data)

Popular posts from this blog

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

Auditing the Oral-B App (v5.0.0)

Image
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 us...
Read more