Padlock

Security Audit by Cure53 - Notes

Thursday, Nov 10, 2016

Below are our notes on the Penetration Test report performed by Cure53 in April 2016. You can download the full test report here.

PIO-01-001 Android, iOS and Extension: Insecure PRNG usage

Fixed: https://github.com/MaKleSoft/padlock/commit/22bffa5232b0

PIO-01-002 API: Email enumeration and unauthenticated reset initiation

Fixed at time of pentest (as stated in the report).

PIO-01-003 Android: Lack of screen capture protections

Found a Cordova plugin that handles this and adds some additional protection on iOS as well: https://github.com/devgeeks/PrivacyScreenPlugin

PIO-01-005 Server: POODLE and DH key exchange weaknesses

Generated a 2048-bit Diffie-Hellman Group and installed latest security updates for openssl. As a result, padlock.io, cloud.padlock.io and cloud-dev.padlock.io all had grade A on ssllabs.com at the time of writing (2016-06-16):

https://www.ssllabs.com/ssltest/analyze.html?d=cloud.padlock.io

PIO-01-006 Android and iOS: Lack of Pinning

Unfortunately at the time of writing, there was no easy mechanism to perform certicate pinning through the Cordova framework. (See https://cordova.apache.org/docs/en/latest/guide/appdev/security/#certificate-pinning])

We will continue to investigate options to do this in the feature. However, it is important to note that, as the report states, this kind of attack is only feasible for “governments and attackers with considerable resources”. Additionally, even in the unlikely case that the ssl connection is compromised, the user data is still protected by the end-to-end aes encryption that happens offline on the device.

As the report states, the Padlock Cloud instance running at cloud.padlock.io is protected from this attack by a “configuration which makes this issue not exploitable”. The issue is further mitigated by the steps taken in resolving PIO-01-017. Finally, as an additional security measure, Padlock Cloud now supports explicitly setting the base url for activation links.

PIO-01-008 Android: Complete lack of Tapjacking mitigations

In order to solve this issue, we decided to extend the aforementioned Cordova PrivacyScreen Plugin by implementing the steps recommended in the report. Details can be found in the corresponding pull request.

PIO-01-009 Android, iOS and Extension: Permanent sync DoS

Fixed: https://github.com/MaKleSoft/padlock/commit/323817f3a655

PIO-01-010 iOS: Possible hijacking via unprotected files at rest

Solved by - as suggested in the report - “implement[ing] the NSFileProtectionComplete entitlement at the app level.”

PIO-01-011 API: Possible Denial of Service via replay

Fixed, as suggested by implementing a throttling mechanism for endpoints involving the sending of emails: https://github.com/MaKleSoft/padlock-cloud/commit/6f6b5ed44ac8

PIO-01-012 API: Email enumeration via invalid tokens

Fixed at time of pentest (as stated in the report).

PIO-01-013 Android and iOS: User information stored in clear-text

Fixed: https://github.com/MaKleSoft/padlock/commit/4b01a36ad90c

PIO-01-014 Android and iOS: Use of external clear-text http urls

Fixed: https://github.com/MaKleSoft/padlock/commit/df984cc5e06b

PIO-01-015 Android, iOS and Extension: XSS via innerHTML

Fixed: https://github.com/MaKleSoft/padlock/commit/8a0e8d26f34e

PIO-01-017 API: Possible vault takeover via activation

We followed the advice made in the report by changing the wording within the activation email for connecting new devices. In addition, Padlock Cloud now returns a ‘connection ID’ to the client and the user is then asked to compare this ID, which is also sent with the activation email, with the one displayed on the device they are connecting. If the IDs displayed in the email and the device do not match, the user is asked to not click the activation link. Asuming the user reads the email carefully and follows the instructions, this makes is impossible for an attacker to trick a user into activating an authentication token that was requested by the attacker.

Relevant commits:

https://github.com/MaKleSoft/padlock-cloud/commit/d2a6806fb887 https://github.com/MaKleSoft/padlock/commit/5dc24b31d911

Note that in the latest version of Padlock Cloud, a similar attack is not possible for the case of deleting a users data since requesting a data reset now requires authentication via a valid authentication token.

PIO-01-004 API: No error check if random fails

Fixed: https://github.com/MaKleSoft/padlock-cloud/commit/18f16fca8a2c

PIO-01-016 Missing Password Manager Best Practices

Trick a user into syncing with an attacker’s device

This is does not apply to the latest version of Padlock since the ‘device name’ field is no longer part of the connection process.

Lock the password store after a certain inactivity threshold

A proper auto-lock mechanism was introduced with the release of Padlock v1.0.

https://github.com/MaKleSoft/padlock/commit/d18892ad6355

Get The App