what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Starbucks 2.6.1 Information Disclosure

Starbucks 2.6.1 Information Disclosure
Posted Jan 14, 2014
Authored by Daniel E. Wood

Starbucks mobile application version 2.6.1 stores user credentials in the clear.

tags | exploit, info disclosure
advisories | CVE-2014-0647
SHA-256 | f357262cd9b2c84a1496c59559c4d8a36bac082c31aa8a2cd66a36eea00f39b0

Starbucks 2.6.1 Information Disclosure

Change Mirror Download
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, Apple’s 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

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close