Latest Entries »

PREVENTING USER AND HARDWARE TRACKING IN MOBILE DEVICES
by 
David Robert Stites

B.S., Purdue University, 2007

Thesis directed by Professor Rory Lewis

A thesis submitted to the Graduate Faculty of the University of Colorado at Colorado Springs in partial fulfillment of the requirements for the degree of Master of Science
Department of Computer Science

© Copyright By David Robert Stites 2012 
All Rights Reserved

Mobile devices, such as smartphones or PDAs, have become increasingly popular with consumers and often provide essential functionality in their everyday life. Usually these mobile devices contain a great deal of sensitive information such as addresses, contacts, ingoing/outgoing call logs, SMS messages and, on the latest models, a calendar, emails and potentially the user’s current location. A smartphone or mobile device today can be as powerful as a desktop or laptop in some respects and, while the latest models feature a complete OS, for many users these devices are “just phones” so there is an underestimation of the risk connected to mobile device privacy. There is a currently existing privacy problem associated with user and hardware tracking in mobile devices. Users can be tracked without their knowledge and consent and have rich profiles built about them using their hardware interface address regarding their location and preferences. This information can be potentially cross correlated to other existing datasets to build advertising profiles for these users. The mitigation to this problem using a framework to support randomly generated, disposable hardware addresses.

Full text of the document can be found here: PDF

Some new classes were introduced in Foundation.framework as part of Mac OS X 10.8 (Mountain Lion) to help ease the pain associated with performing IPC (inter-process communication) in Mac OS applications. Among them were NSXPCConnection, NSXPCListener, NSXPCListenerDelegate and NSXPCInterface. You can find the documentation inside the development portal or as part of the Xcode bundle but this post is meant to show you how easy it truly is to package up messages and send them off to other processes.

But first, a bit of background. What is IPC? Courtesy of WikiPedia, “IPC is a set of methods for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC methods are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.”

Originally, you could have done IPC in OS X using mach messages, which is how drivers traditionally communicated.

While information sharing and modularity are definitely some of the benefits of IPC, one of the biggest wins in my mind is the fact that we can perform privilege separation with IPC. Consider the following: you have wrote some code that will take some user input and crunch on it and then return a result. Note that this doesn’t have to be intensive computation, it could be as easy as interpolating an NSString. User input is a taint source, meaning that the input data is untrusted and could potentially (and perhaps unintentionally) be malicious. If your program were running in a privileged mode or had some increased set of ACLs, then if the input were able to exploit a vulnerability, then it would be able to inherit the same privilege level as the application.

Another benefit of this separation is that suppose the input causes the program to crash. If the processing were done in the main application, it would crash the entire application. If the processing is done in the daemon, then the daemon can crash and the application would still be alive and well.

I have attached a project that demonstrates NSURLConnection’s ability to say “Hello.” hello.tar.gz

Everyone knows — or at least everyone SHOULD know — that email is not a secure form of communication. It’s a lot like yelling across a parking lot. Your message is sent “in the clear” along most of the connections that lie between you and the recipient. For the times when you want to send a message that does NOT stand out in the open for others to read, StegaGram is your answer.

Double Armor
StegaGram protects your communication in two ways. First, it locks the message so that it can only be read by the person to whom you’re sending the message. Then, it hides the locked message inside a picture, so that it doesn’t even look like a locked message is being sent. As an analogy, consider keeping your valuables in a strong safe, located in your front yard. It’s a great safe, but why invite attention to the fact that you have it? Using StegaGram is like keeping that strong safe hidden in a secret panel behind a picture in your house.

No Password, No Problem
Short passwords are not very secure because they can be quickly guessed by computer programs. Long passwords are better, but can be hard to remember. We chose to avoid these problems altogether by using long strings of random numbers, known as keys. If you want more details you can read more below. Otherwise, suffice it to say that it’s stronger than a password but you don’t need to remember anything. You just need to pass a key to your friend using a QR Code — those barcode-looking squares you see all over the place.

Under the Hood
You know those cars that look cool from the outside but lack actual power and performance when driving? Yeah, that’s not us. StegaGram is clean and easy to use, but also employs the latest methods of cryptography and steganography. In fact, our initial version was denied for public distribution because it was too strong. We had to tone it down a bit. As for our hiding methods, they don’t just avoid detection by the human eye. We use a technique that passes well under the radar of digital analysis programs which search for anomalies in histograms.

For the Nerds
StegaGram uses a combination of asymmetric cryptography and an optimized version of the Graph-Theoretic approach to steganography. The asymmetry of the cryptographic keys allows for a distributed authentication model, similar to that used in the PGP community. Our initial version uses 2048-bit RSA encryption. As for the key exchange, the QR-Code method prevents the classic ‘Man-in-the-Middle Attack’ used against the Diffe-Helman pattern, because there is no communication over a network during the exchange. In addition, our steganographic algorithm preserves first-order statistics, unlike most other freely-available steganographic software. For more details, take a look through our research paper.

Fine Print
This application was created for academic and recreational purposes, and comes with no guarantees or warrantees for its information protection. It’s pretty burly, as mentioned above, but is used at your own risk. Thank you to Alex Renger for the idea of StegaGram and for the steganographic algorithm. Thank you to Dr. Yue from the University of Colorado at Colorado Springs for his teaching and support.

Please enjoy the slides from previous Meetups.

 

Buffer Overflows

A Survey on Mobile Device Security

SQL Injections

I got to thinking about passwords last night because I couldn’t sleep and I wanted to clarify something.  Many people have asked me, “If you use numbers and special characters add to the “hardness” of a password?”

Initially I say “No, but it adds to the key space” (key space is the total number of possibilities that an attacker must try).  What I actually mean to say is “Yes, it does increase the “hardness” of the password (and increases the key space), but it is not strictly necessary to use.”

One of the tips I like to use is to create a password that is composed of several words that you like or are particularly memorable.  For example, you could probably look around your office or home and do this.  Looking around me, I could choose projectorchocolateglobemarker (you could choose something else that is easier to remember and I probably would too, but this is just an example).

Consider this: if a password was composed of lower case, upper case, numbers and special characters, that would be 72 characters to chose from.  If your mean system administrator said that your password had to be composed of 8 characters combining those 4 types of characters, then the total number of combinations would be ~7.22 x 10^14 (assuming a password length of 8 characters).  That’s a lot of possible combinations a cracker/hacker must try!

Now consider the password where I ran the words together (projectorchocolateglobemarker).  This would be resistant to a dictionary attack.  A dictionary attack uses a targeted technique of successively trying all the words in an exhaustive list called a dictionary (from a pre-arranged list of values).  Commonly, these pre-arranged lists are actually words from a dictionary because people are lazy and they will make their password is easy to remember (not through any fault of their own but humans are notoriously bad at remembering things that doesn’t make sense or they have no connection to).   While those individual words (projector, chocolate, globe and marker) would all be in the dictionary, the concatenation of them would not.  While we have fewer total characters to choose from (26 lower case characters), the total number possible combinations for the password would be orders of magnitude larger.  In fact, it would be ~1.052 x 10^41.  That is a much larger key space!

Now, if you haven’t glossed over by now, consider a computer that could do 1 key attempt per microsecond (which is certainly not out of the realm of possibilities), that is about 1 million key attempts (to crack) per second.  The first password would take 722M seconds (22 years), the second would take ~10^27 years.  Clearly, we can see which is more secure (and I didn’t need a lot of characters to do it).  These longer, harder passwords, are also more immune to what we call “rainbow table” attacks.

A lot of the password stuff is what is called “security theater.”  Security theater is a term that describes security countermeasures intended to provide the feeling of improved security while doing little or nothing to actually improve security.  Having a system administrator create policies that don’t make sense (such as the crazy combinations of letters, numbers, special chars) when the password is far less secure is an example of security theater.  Bruce Schneier uses it a lot to describe TSA security.

Another way to create a memorable password is to think of a memorable phrase such as “my sister likes to eat juicy orange every day”.  Then, take the first letter of each word and combine them to make your password.  In this example, your password would be msltejoed.

Lastly, I wanted to mention one last tip.  If a user could setup a policy that would lock out after a certain number of failed attempts, such as 3, this is the most secure way to do a pass-worded system because it wouldn’t allow an attacker to do a “brute force” attack where they try all the different types of keys.

All code owned and written by David Stites and published on this blog is licensed under MIT/BSD.