-
On May 2, 2016, I reported, via an email to their support staff, a vulnerability contained within the Nerium International Account Center website. They did not respond to that email.
- On May 30, 2016, I sent a follow up email to their support staff inquiring if my previous email had been received and if they had an update on it, since I noticed the vulnerability was still present in their website. They did not respond to this email either.
- On June 3, 2016, because Nerium had not responded to either of my emails to their support staff, I sent a DM (Direct Message) to the Nerium Support twitter account inquiring about the status of the vulnerability I had reported. They did respond to my inquiry via twitter and after a few steps of requiring me to verify I was a Nerium customer, they stated, "Thank you. We appreciate you taking the time to share this information. We are evaluating the findings with our site architecture team." At that time, I also advised them that if this issue was not fixed in a timely manner, it had already been 32 days since my initial email, that I would publicly disclose the vulnerability.
- On June 17, 2016, I posted a public disclosure of the vulnerability. As a Nerium customer, I intentionally withheld many of the technical details of the vulnerability.
- On June 17, 2016, I received a cease and desist letter from Nerium's legal counsel requesting I take the public disclosure post down. Their cease and desist letter stated, "This statement is false, damaging, and disruptive to Nerium International’s business. A Nerium International customer cannot obtain the financial information of other customers."
- On June 18, 2016, not seeking to get involved in legalities, I have decided to comply with their request to remove the post. I do so in good faith that Nerium will fix the issue in a timely manner.
Saturday, June 18, 2016
Nerium Vulnerability Disclosure
Monday, February 24, 2014
Credit Karma iOS Vulnerability
The Credit Karma iOS application is designed to allow users to stay on
top of their credit information. The application allows user's to see
their trending credit score, accounts, balances, etc. Obviously, if this
information were to fall into the hands of unauthorized individuals, it
could create quite an identity theft problem for Credit Karma's users.
Being a devoted user of the application myself, I wanted to write this post to bring attention to this issue, not only to protect my own information, but to help others protect theirs.
I recently disclosed a security vulnerability to Credit Karma about their iOS application. The version that was identified as being vulnerable was v.1.2.2, which as of this post, was still the active version available within the Apple AppStore. Additionally, as of this writing the Credit Karma iOS application has 10,979 reviews. Based on industry studies, less than 1% of all iOS users either rate or leave reviews for the applications they have downloaded from the AppStore. Keeping this percentage in mind, this vulnerability potentially affects more than 1,000,000 Credit Karma iOS application users.
The vulnerability in question lies in the fact that the Credit Karma iOS application stores the user's credit related information, in an unencrypted format, within a locally stored Cache.db file, within cached data files and within the iOS keychain. On a non-jailbroken iOS device, the keychain storage isn't much of a concern, because the keychain itself is an encrypted storage location. However, it is quite easy to access the Cache.db file, as well as the cached data files on a non-jailbroken device using an app called, iFunBox. Additionally, on a jailbroken iOS device, it is effortless to dump the contents of the keychain, using Ptoomey3's keychain_dumper, and identify any clear-text information that is being stored within it.
If you have the Credit Karma application installed on your iPhone or iPad (running iOS 6.x or lower), your credit information, as mentioned above, is being stored within these three locations. In the event your device was stolen it would take less than 20 minutes for an attacker to jailbreak your device, install ssh, install the keychain_dumper utility and gain access to your credit information. And even less for time for an attacker to gain access to the Cache.db and cached data files. Once jailbroken, all an attacker would have to do is issue the following command:
The result of this command would reveal the following:
I have naturally chosen to not show my sensitive credit information! However, below is pseudo-info that would be found within the keychain:
Grabbing this information from a non-jailbroken device is quite easy using iFunBox. Simply extracting the "Caches" directory from the device reveals the sensitive data is also being stored within the Cache.db file, which is located on the device at /Library/Caches/com.creditkarma.mobile/Cache.db:
And within various files contained within the /Library/Caches/com.creditkarma.mobile/fsCachedData directory (these files were identified on my non-jailbroken iPad running iOS 7.0.6, but not on my jailbroken iPhone running iOS 6.x):
Contents of F6FC38F0-30F6-44CC-A25B-A4E04702E3C5 file located in /Caches/com.creditkarma.mobile/fsCachedData/
Additional data is available, but I think you get the point. As a penetration tester this would rate as a low to medium risk issue in my opinion, since it requires physical access to the device to obtain this information. However, even a lower risk vulnerabilities, can escalate and cause major issues for people.
The purpose this post is not to publicly lambast Credit Karma for this issue. I've seen much worse vulnerabilities in higher profile applications. The purpose of this post is to draw attention to the vulnerability with the hope the Credit Karma takes it seriously and fixes the issue in a timely manner.
Below is the timeline of events for this identified vulnerability:
Feb. 5, 2014 7:50pm - Notified Credit Karma of vulnerability.
Feb. 5, 2014 8:20pm - Credit Karma responded asking for details of the vulnerability.
Feb. 5, 2014 8:27pm - Details of vulnerability sent to Credit Karma.
Feb. 6, 2014 4:59pm - Contacted Credit Karma again for an update on the issue.
Feb. 6, 2014 5:05pm - Credit Karma responded with, "Just asked our engineers for an update. They're currently in a meeting, but hopefully I'll have an update for you soon."
All subsequent emails I have sent asking for an update on this issue have gone unanswered.
Update: After sending the Credit Karma twitter account a link to this post, Credit Karma finally responded to me today (Feb. 25, 2014). I asked if they had read this write up regarding the vulnerability and their response was, "Yes, I sent your post to the appropriate people and the issue was escalated within the company when you first reported it. Thanks."
I recently disclosed a security vulnerability to Credit Karma about their iOS application. The version that was identified as being vulnerable was v.1.2.2, which as of this post, was still the active version available within the Apple AppStore. Additionally, as of this writing the Credit Karma iOS application has 10,979 reviews. Based on industry studies, less than 1% of all iOS users either rate or leave reviews for the applications they have downloaded from the AppStore. Keeping this percentage in mind, this vulnerability potentially affects more than 1,000,000 Credit Karma iOS application users.
The vulnerability in question lies in the fact that the Credit Karma iOS application stores the user's credit related information, in an unencrypted format, within a locally stored Cache.db file, within cached data files and within the iOS keychain. On a non-jailbroken iOS device, the keychain storage isn't much of a concern, because the keychain itself is an encrypted storage location. However, it is quite easy to access the Cache.db file, as well as the cached data files on a non-jailbroken device using an app called, iFunBox. Additionally, on a jailbroken iOS device, it is effortless to dump the contents of the keychain, using Ptoomey3's keychain_dumper, and identify any clear-text information that is being stored within it.
If you have the Credit Karma application installed on your iPhone or iPad (running iOS 6.x or lower), your credit information, as mentioned above, is being stored within these three locations. In the event your device was stolen it would take less than 20 minutes for an attacker to jailbreak your device, install ssh, install the keychain_dumper utility and gain access to your credit information. And even less for time for an attacker to gain access to the Cache.db and cached data files. Once jailbroken, all an attacker would have to do is issue the following command:
| my-iPhone:/ root# ./keychain_dumper -g |
The result of this command would reveal the following:
| Generic Password -- Entitlement Group: 6E32BUCV22.com.creditkarma.mobile Label: 634f294286... Generic Field: (null) Keychain Data: [Sensitive Credit Information Here] |
I have naturally chosen to not show my sensitive credit information! However, below is pseudo-info that would be found within the keychain:
| Credit Score: {"lastNotificationUpdate":1391394064,"score":{"totalPercentChange":7,"prevTransRiskScore":740," Previous Credit Scores: "transRiskScore":740,"nationalPercentile":78,"nextReportUpdate":1391932800,"creditRating":"Good","history":{"1375046982":736,"1388539847":688,"1368461453":645,"1364700491":661,"1366435789":636,"1385769224":683,"1382736496":673,"1390804462":688,"1377957813":649,"1391394056":688,"1372618757":641}, Credit Inquiries, Closed Accounts: report":{"hardInquiriesPercentile":54,"derogatoryMarksDetail":"You have no derogatory marks on your credit report.","closedAccounts":29,"hardInquiries":3,"totAccountsPercentile":95, Open Accounts, Payment History, etc.: percentOnTimeGrade":"A","percentOnTimeDetail":"You have made all your payments on time.","percentOnTime":100,"derogatoryMarksGrade":"A","openAccounts":13,"history":{"1375046982":{"totAccounts":41,"ageOpenAccts":48,"derogatoryMarks":1, Account Details (for each account): email":"jdoe@gmail.com","reportDate":1391394056,"accounts":{"prevBalanceOther":0,"history":{"10":{"balanceTotal":368567," balanceOther":30,"balanceHome":314364,"balanceCC":11070,"reportDate":1366435789,"balanceStudent":20206,"balanceAuto":22897},"2":{"balanceTotal":364840 ,"balanceOther":0,"balanceHome":309695,"balanceCC":17311,"reportDate":1388539847,"balanceStudent":19663,"balanceAuto":18171},"3":{"balanceTotal": 367405,"balanceOther":1373,"balanceHome":310299,"balanceCC":17200,"reportDate":1385769224,"balanceStudent":19793,"balanceAuto":18740} "accountName":"MOHELA/DOFED"} accountName":"CAP ONE"},"3":{"accountId":41,"accountBalance":925,"type":"cc","accountImage":"https://ne.edgecastcdn.net/80033E/www.creditkarma.com/res/img/creditcards/ capOne.png" {"accountId":44,"accountBalance":6812,"type":"cc","accountImage":"/res/content/reviews/CCCitiBank211/title.jpg","accountName":"Citi Platinum Select / AAdvantage Visa Signature"} Your reported total account balance of $264,840 has decreased to $264,518 due to the following changes since Dec 31, 2013:","isAlert":false,"notificationId":633006029,"comments":null,"notificationRank":4,"table":" Account: Type: Previous Balance: New Balance: Change: CAP ONE Credit Card $864 $901 $37 ALLY FINCL Auto $1,127 $843 -$284 MOHELA/DOFED Student $565 $537 -$28 MOHELA/DOFED Student $1,098 $1,051 -$47Credit Utilization: Credit Card Limit: Open CC Debt (w/Limits): Utilization: Grade: $99,009 $90,099 91% |
Grabbing this information from a non-jailbroken device is quite easy using iFunBox. Simply extracting the "Caches" directory from the device reveals the sensitive data is also being stored within the Cache.db file, which is located on the device at /Library/Caches/com.creditkarma.mobile/Cache.db:
And within various files contained within the /Library/Caches/com.creditkarma.mobile/fsCachedData directory (these files were identified on my non-jailbroken iPad running iOS 7.0.6, but not on my jailbroken iPhone running iOS 6.x):
Contents of F6FC38F0-30F6-44CC-A25B-A4E04702E3C5 file located in /Caches/com.creditkarma.mobile/fsCachedData/
Additional data is available, but I think you get the point. As a penetration tester this would rate as a low to medium risk issue in my opinion, since it requires physical access to the device to obtain this information. However, even a lower risk vulnerabilities, can escalate and cause major issues for people.
The purpose this post is not to publicly lambast Credit Karma for this issue. I've seen much worse vulnerabilities in higher profile applications. The purpose of this post is to draw attention to the vulnerability with the hope the Credit Karma takes it seriously and fixes the issue in a timely manner.
Below is the timeline of events for this identified vulnerability:
Feb. 5, 2014 7:50pm - Notified Credit Karma of vulnerability.
Feb. 5, 2014 8:20pm - Credit Karma responded asking for details of the vulnerability.
Feb. 5, 2014 8:27pm - Details of vulnerability sent to Credit Karma.
Feb. 6, 2014 4:59pm - Contacted Credit Karma again for an update on the issue.
Feb. 6, 2014 5:05pm - Credit Karma responded with, "Just asked our engineers for an update. They're currently in a meeting, but hopefully I'll have an update for you soon."
All subsequent emails I have sent asking for an update on this issue have gone unanswered.
Update: After sending the Credit Karma twitter account a link to this post, Credit Karma finally responded to me today (Feb. 25, 2014). I asked if they had read this write up regarding the vulnerability and their response was, "Yes, I sent your post to the appropriate people and the issue was escalated within the company when you first reported it. Thanks."
Subscribe to:
Posts (Atom)