Message-ID: <CAOXycj3fA=9wpZSj7t9qs1=3KxTi-tRkhHH5iC3-9sv_6ec5Aw@mail.gmail.com>
Date: Wed, 13 Nov 2013 10:55:22 +0100
From: Chris John Riley <chris.riley@....cc>
To: bugtraq@...urityfocus.com
Subject: LastPass Android container PIN and auto-wipe security feature bypass (CVE-2013-5113/5114)

LastPass Android container PIN and auto-wipe security feature bypass

Product: LastPass (Android)
Project Homepage: lastpass.com
Internal Advisory ID: c22-2013-02
Vulnerable Version(s): Android version 2.0.4 (and prior)
Tested Version: Android 2.0.4 (Android 4.2/4.3)
Vendor Notification: Aug 13, 2013
Public Disclosure: November XX, 2013
Vulnerability Type: Authentication Bypass Issues [CWE-592]
CVE Reference: CVE-2013-5113, CVE-2013-5114
Issue Severity: Important impact
CVSSv2 Base Score: 6.6 (AV:L/AC:L/AU:N/C:C/I:C/A:N)
Discovery: Chris John Riley ( http://blog.c22.cc )

Advisory Details:

Effected versions of LastPass on the Android platform allow
for users with limited access via the ADB (Android Debug Bridge)
interface of an Android device (USB debugging enabled, no root access
required) to perform backup and restore of applications and application
data. The ADB backup functionality requires an Android device running
the Ice-Cream Sandwich version of Android (4.x) or above.
LastPass on Android allows the user to store the lastpass.com username
and password within the Android container, and set a PIN to prevent
unauthorized access in the event the device is lost or stolen. This
PIN protection also sets an auto-wipe feature that will delete
application data after 10 false logons.
Due to the way recent versions of Android implements the backup and
restore process, both the implemented PIN protection and the enforced
auto-wipe can be avoided and entirely bypassed to allow attackers the
ability to clear or recover the PIN from application settings data
stored in LPandroid.xml.
Using a simple process, it is possible for an attacker with physical
access to a device to backup the LastPass Android container and remove
any PIN protections present on the application. It is also possible to
restore the LastPass Android container to a secondary device and
maintain live access to changes made by the user either via the
lastpass.com web interface or the original device's LastPass Android
application. This exposes not only cached username and password data
stored within the LastPass Android container acquired by an attacker, but
also any changes made after the fact.

Impact:
Attackers can extract and possibly maintain access to a user’s LastPass
data from a lost or stolen device. This effectively allows an attacker
the ability to use the recovered credentials from LastPass to perform
account takeover using the LastPass data.

Process:
1) Gain physical access to an Android device containing the LastPass
application
2) Enable USB debugging (if not already enabled)
3) Perform backup of the LastPass application using ADB
(adb backup com.lastpass.lpandroid)
4) Extract the resulting Android Backup file (using for example the
ab_unpacker.py tool available here -->
https://github.com/ChrisJohnRiley/Random_Code/tree/master/android backup
5) Edit the extracted LPandroid.xml file to remove the following values
    passwordrepromptonactive
    pincodeforreprompt
    requirepin
6) Repack the directory structure (using for example the
ab_upacker.py tool available here -->
https://github.com/ChrisJohnRiley/Random_Code/tree/master/android backup
7) Restore to either the original device or a secondary attacker
controlled Android device using ADB (adb restore edited_backup.ab)
Solution:

LastPass have released a new version to the Google Play store that
corrects these issue by disabling the ability to perform an ADB backup
of the LastPass container. It has been confirmed that the version
2.5.1 is no longer directly susceptible to this attack method.

References:
At this time LastPass have not provided an advisory discussing the issue
http://blog.c22.cc/2013/09/05/a-sneak-peak-into-android-secure-containers-2
http://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release

Vulnerability Timeline:

May, 2013 - Initial discovery of vulnerability
Aug 13, 2013 - LastPass contacted with request for secure communications
Aug 13, 2013 - Response from LastPass setting up secure communications
Aug 13, 2013 - Details reported to LastPass
Aug 13, 2013 - Clarification of issue
Aug 13, 2013 - Response from LastPass that allowBackup:false is now set
in all new releases (change already implemented in testing prior to
the report being received)
Aug 16, 2013 - CVE numbers sent to LastPass
Aug 28, 2013 - Name added to LastPass acknowledgements page
June 30, 2013 - Initial Answer from GOOD
Aug 8, 2013 - Telephone conference with GOOD (cancelled)
Sept 05, 2013 - Response that issues resolved to LastPass's satisfaction
Sept 05, 2013 - Re-Tested and advised of new bypass
Sept 05, 2013 - Blog post released demonstrating process
Sept 06, 2013 - Acceptance of risk associated with new Bypass (low risk)
Nov 13, 2013 - Advisory released (delayed)

Powered by blists - more mailing lists