Security Audit by Cure53 - Notes
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.
PIO-01-007 Activation link spoofing via Host header
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