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)
Privoxy Proxy Authentication Credential Exposure - CVE-2013-2503
Privoxy Proxy Authentication Credential Exposure Product: Privoxy Project Homepage: privoxy.org Advisory ID: c22-2013-01 Vulnerable Version(s): 3.0.20 (and possibly prior) Tested Version: 3.0.20-1 (tested using Debian Sid) Vendor Notification: March 6, 2013 Public Disclosure: March 11, 2013 Vulnerability Type: Insufficiently Protected Credentials [CWE-522] CVE Reference: CVE-2013-2503 Risk Level: Medium CVSSv2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) Discovery: Chris John Riley ( http://blog.c22.cc ) Advisory Details: During research into browser and proxy server handling of HTTP Response Codes, an issue with the way that Privoxy handles HTTP Response code 407 "Proxy Authentication Required" was discovered. Privoxy in versions 3.0.20 (and possibly prior) ignores the presence of "Proxy-Authenticate" and "Proxy-Authorization" headers and allows these values to be passed to and from a remote server without modification. The resulting behavior could allow a malicious websites to spoof a Proxy-Authentication response appearing to originate from the Privoxy service. The Privoxy user will then be prompted for a username and password that appears to originate from the Privoxy software. Scenario: 1) A Privoxy user visits a website using a browser of their choice 2) The remote website responds to the request with a 407 "Proxy Authentication Required" HTTP response code and the appropriate "Proxy-Authenticate: Basic" HTTP response header 3) This response is passed through the Privoxy service without modification to the users browser 4) As the browser is configured to use a proxy server, the browser believes that the upstream proxy (Privoxy) has requested authentication and prompts the user for a username and password. This prompt states that the proxy server at "127.0.0.1:8118" requires authentication (this prompt may vary if Privoxy is running on a machine other than localhost and/or on a non-default port number) 5) If the user enters a username and password, the browser will send a request through Privoxy to the remote website with a "Proxy-Authorization: " HTTP request header (where XXX is a base64 encoded version of the username and password the user entered at the browsers proxy authentication prompt) 6) The remote website receives this header and can store or re-use these captured credentials Proof of Concept: http://c22.cc/POC/c22-2013-01.php The above URL will respond with a "Proxy-Authenticate: basic" header when a request is received that does no contain a "Proxy-Authorization" header. This will prompt the users browser to request a username/password from the user. If you enter a value in the username/password box and click ok, it will send a Base64 encoded version to the remote website (the server will display the response headers at the bottom of the resulting page under request headers (one of the values will be "Proxy-Authorization" with a base64 encoded version of the entered username/password). For a full walkthrough it is suggested to capture this in your favourite packet capture program and walk through the requests to view the entire process. Note --> The above POC does not store any data sent to the server, however it is suggested to use bogus credentials if testing this proof of concept. Solution: The following solution was suggested and implemented in Privoxy 3.0.21 stable. Proxy authentication headers are removed unless the new directive enable-proxy-authentication-forwarding is used. Forwarding the headers potentionally allows malicious sites to trick the user into providing it with login information. References: Privoxy 3.0.21 ChangeLog --> http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/ChangeLog?revision=1.188&view=markup Vulnerability Timeline: March 5, 2013 20:00 - Initial discovery of vulnerability March 6, 2013 14:48 > Emailed Privoxy developer list to request a security contact March 6, 2013 15:26 < Received response with dedicated security contact information March 6, 2013 16:01 > Emailed details of the vulnerability to security contact March 6, 2013 17:19 < Received response acknowledging issue. Fix indicated in upcoming release March 6, 2013 18:38 > Acknowledged receipt of email and advised of updated CVSSv2 score March 7, 2013 15:50 < Received response detailing proposed fix, including link to CVS check-in of new code March 7, 2013 18:48 > Acknowledged receipt of email March 9, 2013 16:54 > Emailed CVE number to security contact and requested information on release plans March 10, 2013 14:28 < Received confirmation of release timeline March 10, 2013 14:58 - Release of Privoxy 3.0.21 stable March 11, 2013 07:45 - Release of advisory -- -- • Chris John Riley • • http://blog.c22.cc • -- -- All emails ROT-26 encrypted --
