Workflow for Mobile App Testing

Since the publication of the Starbucks mobile iOS app vulnerability, I have received many questions by journalists, security researchers and other people interested in understanding what occurs during a mobile app security assessment and exactly just how much work is involved.

I am currently working on analyzing a few applications from the App Store that I will be publishing findings about due to their vulnerabilities.  Hopefully within a weeks time I will have a write-up complete that uses one or more of these apps as examples.   Everyone loves pretty pictures :)


DW

Musings on Starbucks

Much has happened since I posted the original research on the Full Disclosure mailing list regarding Starbucks and how their mobile application was logging sensitive user data elements in clear text.

Many people have contacted me regarding the reporting timeline and the details of such.  Unfortunately many individuals are also posting incorrect information on the matter so I thought I would address these issues, and many others here.

I originally reached out to Starbucks on December 6, 2013 to their customer service.  Over the next month I traded communications back and forth with Starbucks' Customer Service department with ultimately leaving the ball in their court regarding contacting me with a follow-up on what I deemed important if not critical sensitive information.  Unfortunately, this never happened and here we are.  On January 13, 2014 I published some (but not all) of my findings regarding the application on Full Disclosure.  The information was picked up by the media and before I knew it, it made it onto national and international headlines.  

This led to Starbucks expressing interest in speaking with me privately.  I reached out to a PR official at Starbucks directly to let them know I was willing to attempt lines of communication again.  Long story short, I've been in communication with Starbucks throughout the past week and have tested their latest release of the updated application to confirm that the security vulnerability was remediated appropriately.  You can read Starbucks' original post that was updated with the new iOS mobile app here.

There has been a lot of media sensationalizing the Starbucks iOS mobile app vulnerability.  I've seen articles written with titles claiming Starbucks was hacked, that it's related to Neiman Marcus and Target, and that 10 million customers data was at risk.  All this is unequivocally not true.  In my latest update on the matter I address this and many other incorrect conclusions drawn by the media.  

Probably the biggest issue I have with the entire situation were the quotes I've read about the vulnerability being "theoretical" in nature.  This was not a theoretical vulnerability, it was a very real issue.  I think the term was applied due to the perceived complexity of the attack to exploit the vulnerability.  In all honesty, it isn't difficult to pull of and it's not unheard of to have your phone stolen while you're out and about, or leave it on a table somewhere.  While the chance of someone knowing where to look for this information or how to even do it is very slim in nature, I cannot in good faith say it couldn't happen.  This by no means should be downplayed and classified as "theoretical" in nature. 

With that said, I want to thank everyone - my wife, family, friends and colleagues for being supportive during the past week; the media that was accurately reporting events, and Starbucks.  I believe Starbucks had acted in good faith to address this issue in a timely manner to push a security fix out so soon after this was reported on.  Starbucks was forced to learn some hard lessons with this incident, however, I believe they will take this in stride and only improve upon the areas they were lacking in.

Daniel Wood

Adobe Data Mining and Ethics

Several days ago I released a script to aid security researchers and organizations in identifying if their account(s) were in the recent Adobe account database leak.  I had originally aided several organizations in identifying more accounts they had not known about and figured others could use this as well on their own.

You can grab it here: https://github.com/securitycrush/adobextract

Adobe sent out notifications to potentially compromised accounts, however, since they originally stated the number of accounts were roughly 2.9 million, and now we know the potential amount of accounts are closer to 150 million (minus dupes, fakes, etc); I figured having an independent way of verifying is probably a good idea.

This script will parse through the original leaked database file within users.tar.gz, which uncompressed is approximately 9GB in size for user supplied TLD's.  I have included a sample domains.txt as well as roughly the Top 500 (U.S.) sites from Alexa, as of October 6, 2013.  These text files are for mass data mining, however, you can trim them down to only your organization's owned domains or however else you would like to use them.

I've received several questions from individuals concerned stating that a script like this could be used for both good and nefarious purposes.  This is true with any tool; it all depends on the purpose and motivation of the user.  The leaked database is already floating around on publicly available forums, chat rooms, and twitter - so that danger is not just limited to scripts like these.  The information that can be mined from this database leak could allow security researchers to obtain better name, username, and password lists to aid in password auditing or conducting phishing exercises (all legally authorized); or could allow potentially malicious actors to conduct the same types of audits and 'attacks'.  Again, it's all based upon the motivations of the user.

Hopefully, those within the infosec community will find it useful and even tweak it to their own needs.  It's meant to be a starting point and not a finished product.  Over time I will bake more features in it, however, I won't be adding needless features just to bloat it.

UPDATE:  Several developers and researchers have adapted my code and idea for their own projects to provide these types of services to users as well.  Great!


Daniel Wood

Intro to Cryptography (Part 3)

XOR, otherwise known as the logical operation exclusive disjunction or just “exclusive or” in short; is a type of logical operation for two operands that will always result in the value of TRUE if at least one of the operands holds a TRUE value.  If you've taken algebra, this should be somewhat familiar to you…at least in principle.

A XOR cipher (additive) encryption is extremely resistant to brute force attacks which makes it a great method, however, it does have some inherent weaknesses due to the use of patterns.  Compression can help prevent pattern susceptibility.

To demonstrate this, we can look at what we would call a Truth Table (related to what is called a Cayley Table).

XOR Truth Table

Input Output
 A B
 0 0    0
 0 1    1
 1 0    1
 1 1    0

The XOR of A and B can be written out several ways; A⊗B, A XOR B, or A≠B

Binary XOR has two operands (or inputs) like the above Truth Table; where the inputs to a binary XOR table can only be 0 or 1.  The singular output of the combination of each pair of inputs likewise can only be a 0 or 1 (this is binary).To demonstrate this, let’s take two inputs, A and B, and denote the output as C below.

A     B C
0 XOR 0 0
0 XOR 1 1
1 XOR 0 1
1 XOR 1 0

As mentioned above, we are of course using only 0’s and 1’s for carrying out this binary operation.  If we have two binary numbers that we want to conduct a XOR for we would have something like the following:

binary 1 - 10110110
              XOR
binary 2 - 11001101
Result     01111011

Applying XOR to real world use.  A string of text can be used as an input into the XOR operation by applying bitwise XOR to every character within the string using an encryption key.  Decrypting the XOR’d string, you reapply the XOR with the encryption key used and it will remove the cipher from your string - thus decrypting your plain-text.

Example:

Let’s say we have our password, which will be “password”

Converting our password to 8-bit ASCII binary:

01110000 01100001 01110011 01110011 01110111 01101111 01110010 01100100

Our password (sic) is made up of 8 characters, as you can see in the above binary, there are 8 groupings of 8 digits.  As we know, 8-bits = 1 byte.  This gives us an 8-byte password (64-bits).  Now we want to encrypt our password with our encryption key.  For the sake of this example, I will inverse our password, making our encryption key “drowssap”:

Converting our key to 8-bit ASCII binary:

01100100 01110010 01101111 01110111 01110011 01110011 01100001 01110000

Now that we have our plain-text password string to encrypt with our key, we will use XOR to encrypt it:

Input:  01110000 01100001 01110011 01110011 01110111 01101111 01110010 01100100
Key:    01100100 01110010 01101111 01110111 01110011 01110011 01100001 01110000
Result: 00010100 00010011 00011100 00000100 00000100 00011100 00010011 00010100

The result is now our encrypted text.  To decrypt our text we will just carry out the XOR again against the key, this time our Input will be our encrypted string:

Input:  00010100 00010011 00011100 00000100 00000100 00011100 00010011 00010100
Key:    01100100 01110010 01101111 01110111 01110011 01110011 01100001 01110000
Result: 01110000 01100001 01110011 01110011 01110111 01101111 01110010 01100100

Resulting in -bit ASCII that when converted back to plaintext = “password”

As you should be able to deduce, the XOR operator is vulnerable to attack using a know-plaintext attack of plaintext XOR ciphertext = encryption key.

This concludes part 3 of Intro to Cryptography.  In part 4, we will go into the basics of Public Key Infrastructure (PKI), implementations of PKI and perhaps introduce another topic.  If there’s anything you want to see in this series, please leave a comment and let me know if you need help understanding anything I’m covering.