Starbucks 2.6.1 Information Disclosure

2014.01.15
Risk: Low
Local: No
Remote: Yes
CWE: CWE-255


Ogólna skala CVSS: 2.1/10
Znaczenie: 2.9/10
Łatwość wykorzystania: 3.9/10
Wymagany dostęp: Lokalny
Złożoność ataku: Niska
Autoryzacja: Nie wymagana
Wpływ na poufność: Częściowy
Wpływ na integralność: Brak
Wpływ na dostępność: Brak

Title: [CVE-2014-0647] Insecure Data Storage of User Data Elements in Starbucks v2.6.1 iOS mobile application Published: January 13, 2014 Reported to Vendor: December 2013 (no direct response) CVE Reference: CVE-2014-0647 Credit: This issue was discovered by Daniel E. Wood http://www.linkedin.com/in/danielewood Product: Starbucks iOS mobile application Version: 2.6.1 (May 02, 2013) Vendor: Starbucks Coffee Company URL: https://itunes.apple.com/us/app/starbucks/id331177714 Issue: Username, email address, and password elements are being stored in clear-text in the session.clslog crashlytics log file. Location: /Library/Caches/com.crashlytics.data/com.starbucks.mystarbucks/session.clslog Within session.clslog there are multiple instances of the storage of clear-text credentials that can be recovered and leveraged for unauthorized usage of a users account on the malicious users own device or online at https://www.starbucks.com/account/signin. It contains the HTML of the mobile application page that performs the account login or account reset. session.clslog also contains the OAuth token (signed with HMAC-SHA1) and OAuth signature for the users account/device to the Starbucks service. From session.clslog: <div class="block_login"> <form action="/OAuth/sign-in" class="siren" id="accountForm" method="post"> <fieldset class="login_position"> <legend><span class="group-header">I have a Starbucks account.</span></legend> [...snip...] <li> <label for="Account_UserName" class="">Username <span class='req'>*</span></label> <span class="x"> <input class="field text medium" id="Account_UserName" maxlength="200" name="Account.UserName" tabindex="0" type="text" value="CLEARTEXT" /> </span> </li> <li> <label for="Account_PassWord" class="">Password <span class='req'>*</span></label> <span class="x"> <input class="field text medium" id="Account_PassWord" maxlength="200" name="Account.PassWord" tabindex="0" type="password" value="CLEARTEXT" /> </span> </li> 43440 $ -[AccountManager forgotPasswordEmail:withUserName:] line 1609 $ BODY STRING:[ {"emailAddress":"CLEARTEXT","userName":"CLEARTEXT"} ] Note: All references of 'CLEARTEXT' above are the cleartext values of each referenced string. Mitigation: To prevent sensitive user data (credentials) from being recovered by a malicious user, output sanitization should be conducted to prevent these data elements from being stored in the crashlytics log files in clear-text, if at all. iOS Specific Best Practices (from OWASP Mobile Top 10 - M1 Insecure Data Storage): - Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements. - Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto - If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which as stated above is trivial in some cases. - For databases consider using SQLcipher for Sqlite data encryption - For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters. - For larger or more general types of consumer-grade data, Apples File Protection mechanism can safely be used (see NSData Class Reference for protection options). - Avoid using NSUserDefaults to store senstitve pieces of information as it stores data in plist files. - Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file. References: http://try.crashlytics.com/security/ https://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/SecurityDevelopmentChecklists/SecurityDevelopmentChecklists.html#//apple_ref/doc/uid/TP40002415-CH1-SW1 https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

Referencje:

http://try.crashlytics.com/security/
https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top