Re: [Full-disclosure] Passwords Analyser Tool
Nahu- For the most part I use pipal, however, I've used PACK in the past as well. PACK is great if you use hashcat for cracking as it generates valid masks as input files for you. http://thesprawl.org/projects/pack/ Daniel On Mar 10, 2014, at 11:45 AM, Nahuel Grisolia nahuel.griso...@gmail.com wrote: Hi all! Is there any passwords analyser open source tool out there? right now I'm running Pipal (1) and I find it very useful, but I just want to know if you are using any other alternative. Thanks! Nahu.- (1) http://www.digininja.org/projects/pipal.php ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Bank of the West security contact?
Keep this list professional guys. I hate seeing it turn into an IRC chat room. Justin, you should really stop this type of behavior, you're not doing yourself any favors. I let it go when you decided you wanted to repeatedly bash me privately over one of my CVE's posted here, however I can see it's starting to look like a pattern for you. Daniel On Feb 8, 2014, at 6:17 AM, Justin Ferguson j...@ownco.net wrote: That's not what I said when you were trolling offline. You could cite it if you'd like. its cool, i actually didnt click reply-all for a reason. you elected to go for group consensus, old one. On Sat, Feb 8, 2014 at 7:14 AM, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Feb 8, 2014 at 7:11 AM, Justin Ferguson j...@ownco.net wrote: ... You'll have to forgive me. I'm a slow learner at times. probably because, per you, you dont read webpages due to evil ToS' .. That's not what I said when you were trolling offline. You could cite it if you'd like. Jeff -- -- Am I not destroying my enemies when I make friends of them? -- Abraham Lincoln ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [CVE-2014-0647] Insecure Data Storage of User Data Elements in Starbucks v2.6.1 iOS mobile application
Friday, January 17, 2014 Updated Security Review for the new Starbucks v2.6.2 mobile iOS application After publishing my vulnerability report on the Starbucks v2.6.1 mobile iOS application, I have been in continuous communication with Starbucks. As you know, Starbucks released an updated version of the application to address these security concerns. I have evaluated the latest version of the Starbucks mobile application (v2.6.2) from the Apple App Store and conducted exhaustive retesting of the application in order to confirm whether the vulnerabilities were successfully addressed. Prior to starting the new version of the Starbucks mobile app, session.clslog was 64kb (varies on how many user actions you took prior to capturing the data) in size. After running the new version of the application, it clears the session.clslog data file effectively removing all sensitive data elements that were being previously stored. Caveats: If you install the latest Starbucks 2.6.2 app update without actually running the application, the session.clslog file remains with the sensitive data contained within it, however, as soon as you launch the new version of the application it clears session.clslog out, effectively wiping this data off your device. This behavior makes sense as the application is required to run in order to execute the programmatic functions that address the issue of a static file that was being spooled to. There is still a file, located in /Starbucks/Library/Preferences/com.starbucks.mystarbucks.plist that contains geolocation data of a users last logged geolocation. The difference here is, it is not a running log of a customers geolocation like was being stored in session.clslog. This information is only the last location where a customer has used their device. As such, I do not believe this file is a security concern as it does not aggregate geolocation data over time. Your stored geolocation is overwritten each time and cannot be used to track your movement patterns over time. In summary, Starbucks has effectively addressed the security issues that were documented in my original report published January 14, 2014, however, I do recommend that the above issue be remediated within the next release cycle of the mobile application to prevent a customers' last logged geolocation data from being stored. To address some misinformation that has been released: The application does not need to crash in order for a customer's sensitive data elements to be written to session.clslog - this happened automatically prior to v2.6.2 being released. The application can be backgrounded and the phone can be in Sleep mode by pressing the ‘Lock’ button on the top of the device and the data was written to session.clslog. During the initial testing of the application, at no point was there credit card data contained within this file, only your Starbucks Card number and balance amount. During my testing I opted not to enter a valid credit card due to personal privacy precautions, thus the resulting entry within session.clslog had a value of null. At no point were Starbucks's data servers compromised, exposing their 10 million customers to the application as some reports have suggested. This was a local exploitable vulnerability on a users device, not a remotely exploitable vulnerability on their servers or any other type of remote code execution vulnerability. The PIN bypass methods described by some outlets mention the device's PIN, in actuality it is the PIN within the Starbucks application that did not prevent access to the sensitive user data elements being stored within session.clslog. While it is still possible to access application files stored on the device, since the v.2.6.2 update, this is no longer an issue as these data elements are not being written to session.clslog in clear text as was the case with the original vulnerability. Keep in mind this is true for ANY application that uses a PIN to 'protect' your data. It is only as secure as how the data written to the device is being secured either through encryption or never saving the data to disk to begin with. A PIN only prevents someone from access the application itself, not the data being stored. If you don’t store any data or you encrypt it, you have nothing to worry about if done properly. Application sandboxing does not prevent this type of vulnerability if it is being written to the disk. - Daniel Wood On Jan 13, 2014, at 10:28 PM, Daniel Wood daniel.w...@owasp.org wrote: 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
Re: [Full-disclosure] Ubuntu, duckduckgo, and additional info
There is a reddit post regarding this. Please see http://www.reddit.com/r/Ubuntu/comments/1jek5d/why_am_i_seeing_canonical_when_i_search_using/ Daniel On Jan 14, 2014, at 6:41 AM, silence_is_b...@hushmail.com wrote: Any particular reason when setting duckduckgo as the default search and searching from the url bar we get an additional nugget of info sent? Case in point: GET /?q=add+duckduckgot=canonical HTTP/1.1 Hostduckduckgo.com User-AgentMozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Accepttext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Languageen-US,en;q=0.5 Accept-Encodinggzip, deflate DNT1 Connectionkeep-alive I didn't add canonical...so why is it there? In about:config I see distribution.id canonical Why is this being sent? Duckduckgo didn't respond, so I thought I'd ask here. Ironic... ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [CVE-2014-0647] Insecure Data Storage of User Data Elements in Starbucks v2.6.1 iOS mobile application
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
legendspan class=group-headerI 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [CVE-2013-6986] Insecure Data Storage in Subway Ordering for California (ZippyYum) 3.4 iOS mobile application
I would like to point out that the statements made in the emails from mikken.tut...@intersecworldwide.com are untrue at best, defamatory at worst. I am not going to lambast Jeff, Mikken, or Intersec Worldwide - but I will defend myself. Normally I would not respond to something like this in a public forum, however, Intersec Worldwide has forced my hand due to their untrue statements. I never signed a Non-Disclosure Agreement with Intersec Worldwide when I started my contracting work for them. Now that’s not to say I am going to start publishing all the vulnerabilities of their clients, far from it. I am stating this because prior to this email going out, I was called by Jeff Tutton the ‘CISO’ about the matter. We talked briefly for about 10 minutes on Wednesday, December 11, 2013. During this phone call I mentioned the fact that no NDA had been signed. He said he would look into this and work with his client on the matter regarding the vulnerability disclosure. I never heard back from him or anyone at Intersec Worldwide after this. I emailed Jeff/Intersec this morning when I saw Fyodor’s post and Mikken’s/Intersec email alleging I violated their NDA. I gave Jeff/Intersec until EOB today to provide the original email with the signed NDA I sent to them, however, I have yet to receive this. I asked for a copy of the allegedly signed NDA last week as well. Failure to provide a legitimate copy of my sent email with a signed NDA proves to me that they forgot to have me sign an NDA. I should not be held liable for a lapse in their own processes. If they are able to come up with a legitimate copy of the signed NDA and email with legitimate email headers - I will gracefully apologize…which won’t occur since I did not sign such a document. In this email, I also informed Jeff that I am terminating my 1099/contractor agreement with Intersec Worldwide effective immediately. Due to the mention of legal action in their email, I have now retained the services of an attorney and will be ready to see this matter to a close. Instead of focusing on the fact that information was disclosed after they had 6+ months to fix the vulnerability, they should be focusing on the positive aspect that they were able to fix the vulnerability and that it does not affect their product’s current release version. - Daniel Wood On Dec 16, 2013, at 4:50 PM, Fyodor fyo...@nmap.org wrote: On Fri, Dec 6, 2013 at 8:07 PM, Daniel Wood daniel.w...@owasp.org wrote: Title: [CVE-2013-6986] Insecure Data Storage in Subway Ordering for California (ZippyYum) 3.4 iOS mobile application Reported to Vendor: May 2013 CVE Reference: CVE-2013-6986 Apparently you touched a nerve! If the legal threats we received for archiving this security advisory on SecLists.org are any indication, ZippyYum really doesn't want anyone to know they were storing users' credit card info (including security code) and passwords in cleartext on their phones. Please remove this information from your website immediately in order at avoid further legal action. --Mikken Tutton, CEO of ZippyYum client IntersecWorldWide Of course we have ignored the threats and kept the advisory proudly posted at: http://seclists.org/fulldisclosure/2013/Dec/39 Here are the legal threats we received today and last Wednesday: -- Forwarded message -- From: Mikken Tutton mikken.tut...@intersecworldwide.com Date: Mon, Dec 16, 2013 at 1:33 PM Subject: Fwd: To: jo...@grok.org.uk, fyo...@nmap.org, hostmas...@insecure.org Dear Webmaster, We contacted you last week regarding some private information about our client that you have posted on your website, in violation of Non-Disclosure agreements we have in place with our customer Zippy Yum. We are requesting that this information be removed immediately. The information to which I am referring is located on this page of your website: http://seclists.org/fulldisclosure/2013/Dec/39 We would appreciate the courtesy of a response to our email within 48 hours so we can resolve this issue. If we do not receive a response, we will turn this matter over to our attorney for legal action. Thank you for your prompt attention to this matter. Sincerely, Mikken Tutton CEO -- Forwarded message -- From: Mikken Tutton mikken.tut...@intersecworldwide.com Date: Wed, Dec 11, 2013 at 11:03 AM Subject: Re: To: fyo...@nmap.org Cc: jo...@grok.org.uk Dear Mr. Lyon, It has come to my attention that the attached information is posted on your website about one of our clients. However, this information was released to you with out authorization and is protected by the Non-Disclosure Agreements we have in place, both with our client and also with the contractor who submitted the information to your website in violation of said NDA. Please remove this information from your website immediately in order at avoid
[Full-disclosure] [CVE-2013-6986] Insecure Data Storage in Subway Ordering for California (ZippyYum) 3.4 iOS mobile application
Title: [CVE-2013-6986] Insecure Data Storage in Subway Ordering for California (ZippyYum) 3.4 iOS mobile application Published: DATE Reported to Vendor: May 2013 CVE Reference: CVE-2013-6986 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6986 CVSS v2 Base Score: 4.9 CVSS v2 Vector (AV:L/AC:L/Au:N/C:C/I:N/A:N/E:H/RL:U/RC:C) Credit: This issue was discovered by Daniel E. Wood http://www.linkedin.com/in/danielewood Vendor: ZippyYum, LLC | http://www.zippyyum.com Application: https://itunes.apple.com/us/app/subwayoc/id510770549?mt=8 Tested Version: 3.4 File: SubwayOCKiosk.app App Name: Subway CA Kiosk Build Time-stamp: 2012-06-07_09-20-17 1. Introduction: Subway CA is a mobile application available both on iOS and Android based devices that allows customers to build and order food menu items that can be paid for through the application using a payment card such as a debit or credit card. 2. Vulnerability Description: The application stores sensitive data insecurely to cache files located within ../Caches/com.ZippyYum.SubwayOC/ directory on the device. Loading Cache.db and/or Cache.db-wal in a tool that can read sqlite databases (such as RazorSQL) will allow a malicious user to read unencrypted sensitive data stored in clear-text. Sensitive data elements found within Cache.db and Cache.db-wal: - password and encryptionKey for the application/user account - customerPassword - customerEmail - deliveryStreet - deliveryState - deliveryZip - paymentMethod - paymentCardType - paymentCardNumber - paymentSecurityCode - paymentExpMonth - paymentExpYear - paymentBillingCode - customerPhone - longitude (of device) - latitude (of device) - email 3. Vulnerability History: May 9, 2013: Vulnerability identification May 15, 2013: Unofficial vendor notification August 4, 2013: Official vendor notification via report September 20, 2013: Vulnerability remediation notification* December 7, 2013: Vulnerability disclosure *Current Version: 3.7.1 (Tested: only customerName, customerEmail, customerPhone, location, paymentCardType are in clear-text within Subway.sqlite-wal) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
