[CVE-2014-0647] Insecure Data Storage of User Data Elements in S

看板Bugtraq作者時間12年前 (2014/01/15 02:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串1/1
--Apple-Mail=_AAF083C0-5277-416F-A541-307295EDBFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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.cls= log 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=92 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. =46rom session.clslog: <div class=3D"block_login"> <form action=3D"/OAuth/sign-in" class=3D"siren" id=3D"accountForm" = method=3D"post"> <fieldset class=3D"login_position"> <legend><span class=3D"group-header">I have a Starbucks = account.</span></legend> =09 [...snip...] =09 <li> <label for=3D"Account_UserName" = class=3D"">Username <span class=3D'req'>*</span></label> <span class=3D"x"> <input class=3D"field text medium" = id=3D"Account_UserName" maxlength=3D"200" name=3D"Account.UserName" = tabindex=3D"0" type=3D"text" value=3D"CLEARTEXT" /> </span> </li> <li> <label for=3D"Account_PassWord" = class=3D"">Password <span class=3D'req'>*</span></label> <span class=3D"x"> <input class=3D"field text medium" = id=3D"Account_PassWord" maxlength=3D"200" name=3D"Account.PassWord" = tabindex=3D"0" type=3D"password" value=3D"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. =09 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=92s = 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/SecurityDevelopmentCheckli= sts.html#//apple_ref/doc/uid/TP40002415-CH1-SW1 = https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_St= orage_.28M1.29 --Apple-Mail=_AAF083C0-5277-416F-A541-307295EDBFD5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS1L1MAAoJELujRlA1D0mm8cAH/2RfEcCW1oI4qDo05FMz3vhS C336ocTQmmbvXKtKKx9i78096xl/tfAZMBB3XoOZ7bxx3k78/3wgPPvESscb6V3m wD9FaT3oq/rdDnc+DywDsIYC6U4uvI90uKT6UsD/H8Uuoo2jir3J3xKeoRvaci+6 HBkEcshfzjqtLJaKrdhab8087qcOd+OfVSen6b8SLZtKXPoqESMFXJduC/eCM+Yh pSrcLY1qWsmOSV7MQ5bDv1hJQqSD3vbSli6Ajbx5gqqvjaHhZtHcW4kxlfNXRu17 dSChNS7mUec5idPl7mX8T2CSGXGar2yibVj2GztJT14E0geT6oZ5IpetXX5Hzuc= =KxF/ -----END PGP SIGNATURE----- --Apple-Mail=_AAF083C0-5277-416F-A541-307295EDBFD5--
文章代碼(AID): #1IrNjUBd (Bugtraq)