Sunday, August 11, 2013

Life, Liberty and the Pursuit of Understanding

As it turns out, self discovery and education is a lifelong pursuit.  Following a stint as a Senior Network Engineer I discovered that the traditional buttoned-down IT world was no longer in the cards for me. Thus,I embarked on a nontraditional path of education and enrichment in the many disciplines of the security world, android development and of course, python geekery.  This blog serves as a journal depicting this pursuit and getting back to what I do best - learning through exploration.

My prior education rap sheet reads like a New Jersey Greek Diner menu; voluminous and varied with something for everyone.  The offerings include:  Catholic, Public, Quaker Friends, Private college prep and Liberty based/Democratic schools.  By far, my two favorites are the Quaker Friends School and the Liberty based School. During my time at these two schools, I learned what it truly means to be responsible for my own education.  You get out what you put in - an elegant reciprocity.

In the immortal words of Calvin and the intrepid Hobbes:

Getting started with database-backed content storage on Android

Introduction

In this tutorial I will cover some of the fundamentals of developing, implementing solid design design processes for database-backed storage in Android applications. 

This will cover simply the basics with a future post introducing some amazing ActiveAndroid style ORM libraries that will give extensive control over your stored data.


This tutorial assumes you are familiar with databases (generally) as well as the pretty straightforward syntax of SQLite. Feel free to review the query documentation for SQLite on their website here.



Fundamentals

To begin with, you will need to think about what data it is that you are storing, how you want to represent this data across different tables and, lastly, how you want to abstract the stored data in Java classes.

For this tutorial, let us assume a pretty straight forward example: storing a list of movies. Each movie has the following attributes:

  • Title
  • Genre
  • Rating (1 - 5)
  • Description
Each one of these attributes will become a column in our 'movies' table. If we were going to create such a table by hand we would likely use a query like this:

CREATE TABLE IF NOT EXISTS movies (
    _id INTEGER PRIMARY KEY, 
    title TEXT NOT NULL UNIQUE,
    genre TEXT,
    rating INTEGER,
    description TEXT);

It's important to realize the _id column specification. Many of the aspects of content providers in Android assume that the PRIMARY KEY 'ID' column will be called '_id'. We will get into this more later but suffice to say; '_id' is a good choice for the name.

The other columns are pretty straight forward and I included a constraint that no two entries can have the same 'title' value and that this value must not be NULL (can't think of a movie without a title).

With this information and the above SQLite statement, we can begin creating our application's contract class. This class will be a final class that defines the interface and structure of our actual schema.

This class should go something like this:

public final class MovieContract {
    public MovieContract() { }

    public static abstract class MovieEntry implements BaseColumns {
        public static final String TABLE_NAME = "movies";
        public static final String COLUMN_TITLE = "title";
        public static final String COLUMN_GENRE = "genre";
        public static final String COLUMN_RATING = "rating";
        public static final String COLUMN_DESCRIPTION = "description";
    }
}

Next we will create a class that inherits from SQLiteOpenHelper. This class handles most of the heavy lifting involved with opening and managing a SQLite database. Our should look something like this:

public class MovieDbHelper extends SQLiteOpenHelper {
    public static final int DATABASE_VERSION = 1;
    public static final String DATABASE_NAME = "movies.db";

    private static final String SQL_CREATE_MOVIES_DB = 
        "CREATE TABLE " + MovieEntry.TABLE_NAME + " (" +
        MovieEntry._ID + " INTEGER PRIMARY KEY, " +
        MovieEntry.COLUMN_TITLE + " TEXT NOT NULL UNIQUE, " +
        MovieEntry.COLUMN_GENRE + " TEXT, " +
        MovieEntry.COLUMN_RATING + " INTEGER, " +
        MovieEntry.COLUMN_DESCRIPTION + " TEXT)";

    private static final String SQL_DROP_MOVIES_DB =
        "DROP TABLE IF EXISTS " + MovieEntry.TABLE_NAME;

    public MovieDbHelper(Context context) {
        super(context, DATABASE_NAME, null, DATABASE_VERSION);
    }

    public void onCreate(SQLiteDatabase db) {
        db.execSQL(SQL_CREATE_MOVIES_DB);
    }

    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        // Drop old table and recreate when the version is incremented
        db.execSQL(SQL_DROP_MOVIES_DB);
        onCreate(db);
    }

    public void onDowngrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        // Provides us an opportunity to 'roll back' changes between version. We will 
        // simply drop and recreate the database all together.
        onUpgrade(db, oldVersion, newVersion);
    }
}

Not too bad so far right? With this class in place, we already have all the instrumentation we need to have Android create and open our database. Next we need to figure out how to add to, select from and otherwise modify the data in the database.


Making your database useful

Given our SQLiteOpenHelper class, we can now actually get a handle to the database within our activities code using:

MovieDbHelper mDbHelper = new MovieDbHelper(getContext());

To start with, let's create a private method that inserts a movie for us:

private long insertMovie(String title, String genre, int rating, String description) {
    SQLiteDatabase db = mDbHelper.getWritableDatabase();

    ContentValues values = new ContentValues();
    values.put(MovieEntry.COLUMN_TITLE, title);
    values.put(MovieEntry.COLUMN_GENRE, genre);
    values.put(MovieEntry.COLUMN_RATING, rating);
    values.put(MovieEntry.COLUMN_DESCRIPTION, description);

    long newRowId = db.insert(MovieEntry.TABLE_NAME, null, values);
    return newRowId;
}

Here we get a writable handle to our database, use the ContentValues class to package our column values and simply insert. The return value of db.insert(...) will determine what the _id value is for this new row or -1 if the insert failed.

Next we will, at some point, certainly need to query (or SELECT) data from the database. We will create a 'Movie' class to represent movies in the database as well as another private method for querying the database:

public class Movie {
    public final String title;
    public final String genre;
    public final int rating;
    public final String description;

    public Movie(Cursor data) {
        title = data.getString(data.getColumnIndexOrThrow(MovieEntry.COLUMN_TITLE));
        genre = data.getString(data.getColumnIndexOrThrow(MovieEntry.COLUMN_GENRE));
        rating = data.getInt(data.getColumnIndexOrThrow(MovieEntry.COLUMN_RATING));
        description = data.getString(data.getColumnIndexOrThrow(MovieEntry.COLUMN_DESCRIPTION));
    }
}

In this class, the constructor method takes a single Cursor argument which provides all of the our stored database information. From here, we can extrapolate which column represents which data field.


Managing your data

Now that we can insert data and query the existing records. We will need to implement the ability to delete records as well as update existing records. The paradigm for doing such is actually fairly similar to the insertion and querying functions.

To delete a record (or all records). We will use something like the following:

private boolean deleteMovie(long _id) {
    SQLiteDatabase db = mDbHelper.getWritableDatabase();    

    int c = db.insert(MovieEntry.TABLE_NAME, String.format(MovieEntry._ID + "= %d", _id), null);

    // The integer 'c' will represent how many rows have been deleted. 
    // It should be one in this case

    return (c == 1);
}

As you can probably tell, by modifying the second argument to db.insert(...) you could also specify something like:

MovieEntry.COLUMN_TITLE + "=" title

Keep in mind, you can have the SQLiteDatabase class automatically escale '?' arguments as follows:

int c = db.insert(MovieEntry.TABLE_NAME, MovieEntry.COLUMN_TITLE + "= ?", new String[] { title });

This helps protect unsanitized input from SQL injection attacks and is highly recommended unless you are explicitly specifying the attributes yourself.

This would allow you to delete all rows that match the specified 'title' column.

Now that we can delete entries, let's look into updating existing record. This is much like creating a new entry but we have another argument allowing us to specify which records should match. Check the documentation for update as well.

Here is an example:


private boolean deleteMovie(long _id, ContentValues newValues) {
    SQLiteDatabase db = mDbHelper.getWritableDatabase();    

    int c = db.update(MovieEntry.TABLE_NAME, newValues, String.format(MovieEntry._ID + "= %d", _id), null);

    // The integer 'c' will represent how many rows have been updated.
    // In this case it should only be one 

    return (c == 1);
}

As stated before, you should try to make use of the of the whereArgs argument and allow it to populate your '?' arguments provided to the whereClause argument when possible and certainly when from untrusted sources.


In Conclusion

In closing, I hope this helps better illustrate the somewhat unique way that Android applications handle working with SQLite databases. As I said before, I will provide another article in the future about some of the many amazing things ORM-based / ActiveRecord libraries such as those provided by ActiveAndroid provide. Please let me know what you think, and thank you for reading.


Further Reading

Android SQLite Database & Content Provider - Tutorial (By Lars Vogel) - Great overview of the fundamentals and basic implementations of database-backed content storage

Saving Data in SQL Databases (Android Developers Guide) - Nice overview with rich examples of the right way to persist data using SQLite databases

Friday, August 9, 2013

A taste of things to come


A Taste of Things to Come

For the past few weeks, I've been pondering what the face of evolving malware in the coming months will be, particularly Android-based malware. As with all malware, the level of sophistication seems to be increasing but it seems the complexity seen in Android malware isn't really that, well, complex. In my opinion, it's only a matter of time until someone "gets it right" and builds a highly effective Trojan or rootkit for the platform.


Yesterday

As with any platform, Android has had it's share of malicious software but, in the grand scheme of things, it seems to be fairly ineffectual overall. That being said, some of these existing threats have compromised the security of thousands of user's devices, exposing sensitive information to attackers. My point is simply that in the arms race of the mobile security world, it seems things are poised to become much worse if someone commits more effort to building a comprehensive tool to commit such crimes.

The first example of such a piece of software that I want to bring up is actually the result of work between Indiana University and the U.S. Navy (yeah) that is presented as a proof of threat describing a new type of 'visual malware' called PlaceRaider. This inventive tool would aid a wise burglar by helping build a 3D view of the target location, recording sensitive information that the device's camera and microphone pick up. Scary, even if a little far fetched for the average burglar. In the whitepaper, they go into detail about some means to defend against such 'visual malware' but all of them require changes to the way Android operates in a fairly fundamental way and that are unlikely to happen. You can find a write up on PlaceRaider here and the whitepaper directly here.

The next concept is a tool that could monitor the keystrokes using the built in 3-axis accelerometer in most any Android device. This piece of hardware is responsible for detecting things like rotation, linear acceleration (shaking) and pitch. The concept was original conceived at Georgia Tech College and targeted the iPhone but the idea translates to pretty much any mobile device. Simply put, by detecting the subtitle pitch changes of the device whilst the keyboard is up, one can fairly accurately compute which key of the onscreen keyboard was pressed. To clarify, if you were to press a button on the screen, the X, Y and Z-axis values from the accelerometer would provide a fairly unique value that nearly identifies where on the screen the press occurred. Quite a novel use of a crucial sensor in my opinion. You can read more about the iPhone concept from GA Tech and here.

Today

Along with threats like this, there are a number of other examples of similar concepts as well as some that utilize things like the NFC functionality of devices equipped with such hardware.

What is troubling is that there seems to have been little to no response among the vendors in the security community. I presume mostly because there isn't much that can be done to mitigate these threats. Nevertheless, I seems paramount for mobile antivirus vendors to take this emerging landscape into account when they are designing their software. 


Tomorrow

I'm no psychic but it seems inevitable to me that emerging threats will start to increase in complexity and soon enough someone will create a piece of malicious software for Android that is both novel in implementation and design. The threats today seem to be poorly written and require the user to do clearly unsafe things (like permit the application to be a device administrator via the scary-looking dialog built into Android). Beyond that, they seem to lack any real decisive goal.

Here are a few things that occur to me as feasible and, to my knowledge, not in existence.


#1) The 4G botnet

Imagine, if you will, a distributed network of compromised Android devices. Given the specs of most devices today, along with the 4G speeds most have access too, it seems feasible to build a Android-based botnet or something distributed of the sort. Such a network of compromised hosts could provide a significant source for a large DDoS attack that might be launched across the cellular networks. To my knowledge, the high-speed cellular wireless networks haven't experienced being the intermediate path for a large denial of service attack. Thus, I'm not sure how well they would fair. Providers put a lot of work into handling such problems in traditional networks but I wonder how they would fair in the wake of the traffic produced by say, five thousand diversely located compromised phones launching an attack. Now, I'm not suggesting to build such a tool to test it, simply pointing out a possibly overlooked weakness. I say 'possibly' because I don't have any real information about what capacity and stress testing has been done across these networks, though I would love to hear from someone who does.


#2) Sensor Thief

Given the diverse number of interesting (well, for graphing junkies such as myself) sensors available on different devices it seems plausible for one to build a rootkit which monitors and reports back all sorts of information from the GPS, accelerometer and many other sensors available on the Android platform. Some of these values include barometric pressure, temperature, magnetic field levels, proximity, light levels and even humidity. For the most part these are probably of little concern to most users who might discover they are the victim of such a rootkit but even something like the barometer, depending on it's sensitivity and the physical location, might be able to be used to detect when the user has placed their phone down and left the room- giving a would be thief the location of the device as well as some assurance the owner isn't around. It's more theoretical but technically when a door is opened or closed in most environments there is a slight change in air pressure. Even if the sensor isn't able to detect such a change, it can certainly provide an indication if the device is inside or outside since there is a large enough variance between the outside air pressure and that inside a building.

However, some of these sensors, such as the barometer, are only available on a select number of devices. Of all of my Android devices, only my old Motorola Xoom has a barometer sensor and, sadly to my inner graphing geek, not my primary tablet an Asus Transformer Infinity TF700.

But I digress, that is a simple concept threat that seams pretty realistic to me.

Without building blueprints for the perfect Android nightmares, here are a few other general concepts that might be seen in the not to distant future:

  • Makeing use of the generally unrecognized fact that Android is simply running on Linux
  • Utilize a zero-day exploit to run code covertly whilst still providing some apparent 'value' to the user of the device (i.e. a game or simple content provider) -- This will provide validity to the otherwise nefarious activity generated by such a package
  • With enough permissions or, worse yet, root access it could also subvert otherwise legitimate applications with on-the-fly modifications to the Application APK files or even the Dalvik interpreter or Java VM that provide application functionality for the whole system.


Prevention is the best defense

A lot of these sound fairly far-fetched given the landscape of malicious software out there for Android devices but I honestly think the bar has been set pretty low thus far. It seems new threats that come out require the user to grant the application administrative access then, with all that access, they poorly do rather mundane malicious activities. Given that, the 'antivirus' or 'anti-malware' utilities out there don't live up to the reputations of their desktop counterparts. That isn't to say there aren't decent products out there like avast Mobile Security but simply that even the good security tools don't expect to contend with threats like those described above.

Now I'm the type of guy who dumps the DEX file from an application and goes to town on it. However, short of manual reverse engineering efforts, it seems the security software out there for Android doesn't have much more than pretty basic heuristic-based analysis and definitions to go on. I don't think there are really any polymorphic variants of existing threats but it seems inevitable. Unless the authors of new malicious software kindly publish a whitepaper along with it, I'm not sure how or how long until antivirus vendors will get their hands on it if it is not as obtuse as today's malware. It seems like it might be difficult as a vendor to get a good picture of the evolving treat landscape and thus are forced to respond reactionary with new definitions. Most modern desktop antivirus products combat this problem by allowing the user to participate in some sort of 'community network' where new samples are anonymously shared with the vendor. This gives the vendors a real world view of new mobile threats and seems very valuable to me.


In Closing

Lastly, I would like to hear what others think about this. This is all just from my own perspective and, to anyone who might wish to provide some insight from the security vendor's perspective, I would love to hear about it!

Thursday, August 8, 2013

The Android Developer vs. The One-Click Crackers

As the developer sees it:

"I mean it's only 99 cents we're talking about. No one would go to the trouble... Would they?"


It seems simple enough, write a nifty app that does something novel put a few non-intrusive ads in it to entice regular users to upgrade to your 'ad free' version for a price that could easily be covered by the coins in most readers couches. This model has flourished despite there having been sites offering cracked or simply full copies of these pay applications for free to downloaders, from the beginning of the Android platform. But who is really going to go to all that trouble to break my application and release it for free if we are only talking about $0.99? I mean, would they?

As the cracker sees it:

"These developers pump out deceptively marketed applications that cost the user to basically load a web page in this 'application'.. what nerve."


I'm afraid it’s been happening since the dawn of paid computer applications and, will continue well beyond the Android platform. From my view, it appears there are two main types of application crackers: the well-read, creative and, to a certain extent, respectful cracker and the fly-by-night ‘one-click crackers’ who love using tools made by others that do processes they do not really understand for their own benefit. The latter has had little luck in the desktop cracking world due to the complexity of compiled binaries versus the android application which is, at best, a zipped up file (that is also a zip file) which contains instructions (Dalvik virtual machine opcodes) that can, more or less, be reversed back to a pretty readable version of the original Java source code. Yup, that easy most of the time.

Well that’s a shame but so what to do?

Not much there is to do. Users should use new technologies to keep their applications up to date with the most available software protection mechanisms and throwing a crafty trick or two in there to thwart the auto-magic tools seems like it’s enough to raise the challenge of cracking your application to the level it might just be worth the $0.99. That being said, that won’t stop it from showing up on www.downl0ad-st0len-apkz.biz. Even so, who cares? If you’re app is priced fairly, protected cleverly and often updated (requiring the pirates to go through this whole process again) it seems logical that would help any potential revenue impact. All in all, I can say for certain Google is not the correct group to blame here. Putting the responsibility of policing the internet to ensure crappy software licensing paradigms are enforced sounds absurd to me and, if you want to go all solder of fortune on these pirates, maybe the concerned developer should pursue these bandits.

I have a few ideas that might make the matter a bit more interesting for all involved that I will put up as I flesh them out but I really want to hear from both sides; I disagree that the pirate doesn't have a voice in the matter. I mean, ultimately, they are the ones who spend most of their time dealing with any protection mechanism? What project sprint would be complete without their user stories? :)

Thursday, July 26, 2012

The 'hacker' in today's society

People as words

The terms associated with the security community have long been hotly debated by the community members themselves. The 'media' (whoever that actually is) has had a field day by scaring the otherwise generally non-technical viewers who further misconstrue the term 'hacker' to mean 'that shady looking guy who is going to steal my money'. I've heard it a hundred times from different members of the security community and I'm sure we all will continue to but why?


The paradigm shift

For those readers who might remember, at the end of the phone phreaking days, the same sort of motivation shift appeared to be occurring. Back in the days of 2600Hz tones and schematics for interesting devices made by those reverse engineering an otherwise black-box system such as the phone system the motivations were much simpler and amatuer: the passionate drive to understand how something truly works. In the past few years, this motivation has given way to a much more contemporary one: money.

This has been posited by others (see the first chapter of Gray Hat Hacking: The Ethical Hacker's Handbook) namely, that understanding the true motivation an attacker has is paramount to understanding what that attack is capable of and, simply put, how they think. I think this is an important point to keep in mind for the security professional today. If you do not understand your opponent, how can you defend yourself against him?


The distinction

Given this, what is the best way to solve this otherwise mundane vocabulary problem? The word 'hacking' has been hijacked by contemporary society but by using instead 'criminal hacker' or something of the sort, it becomes much more clear which group of people are being referred to.


Conclusion

There is a lot of great information out there about how to protect your network assets, mitigate complex threats and anything else technical you could think of but much of it falls on deaf ears (or is simply lost among the noise of voices of others screaming for security). None of this helps the next victim of a financially motivated criminal hacker if he doesn't understand that the attacker isn't going to be mounting an attack that might be more appropriately launched against a government but instead will sneak in, attempt to accomplish their financially motivated goal and sneak out.

Thoughts?