Tag Archives: android

Fitbit Android App and Password Security Issue

Android 3.0 047/365I’ve been a Fitbit user for a few months now, and really love the product.  Recently, I had been reading about Android apps that don’t do a great job of protecting user information on the device itself.  Many Android apps store sensitive information in plain text, and rely on the Linux sandbox model to protect that information.  The sandbox model works well, until the device is rooted, which allows access to all of the previously secured sandboxes.

I’ve been looking at the data stored by various apps on my rooted Galaxy S3 using Root Explorer looking for apps that fail to protect sensitive information.  During one of these exercises, I discovered that the Fitbit Android app falls into this category.

In the application sandbox’s files directory, is a file called login_credentials.json.  Inside this file are my Fitbit username and password in clear text:

{“password”=”<my password>”,”login”:”[email protected]”}

If a user chooses to use the same password for the Fitbit.com service as other services (such as a bank account), the disclosure of the Fitbit.com password could be very detrimental to them.  Of course, I’m able to see this information easily because my phone is rooted.  On a non-rooted device, the application sandbox security model prevents other apps from seeing this data.  However, there have been attacks on Android devices where malware first obtains root, and then uses root to enable other malicious behavior.  If someone was determined enough, they could craft a similar malware bot that could first obtain root access and then discover other passwords on the system stored as plain text.  If a thief steals an Android device, they could root the device and harvest passwords on the system.

I first disclosed this issue to Fitbit a few weeks ago, and after a few days they notified me that they were addressing the issue.  Another day or two goes by, and the new update was already available in the Google Play store.  After seeing the new update, I launched the app, and then Root Explorer to see if the this issue was fixed.  In the new version, the login_credentials.json file was gone, and instead replaced with a file called authinfo_credentials.json.  

Root Explorer viewing the Fitbit Android app sandbox.

Root Explorer viewing the Fitbit Android app sandbox.

This file contains what appears to be a base64-encoded encrypted blob,  which likely contains my username/password.  By encrypting my credentials, this fix prevents the scenario’s that I listed above.

Fitbit doesn’t list a security-related email address on their page for reporting these kind of issues.  I had to open a trouble-ticket with support, and quickly had it escalated, in order to disclose this vulnerability.  On the positive side, I was impressed that Fitbit took this issue seriously, and issued a fix within a week of my report.  I continue to be a fan of their products, and am glad to see that they care about user security.

Use REST Web services to share data across iOS and Android apps.

REST Web Services can be a great way to share data between iOS and Android mobile apps.  I recently answered a question on Quora about this topic.  Here’s my answer:

There are several different options here.  When you want to support multiple mobile platforms, creating a simple REST api is a good way to go.  Soap-based protocols are going to be too complex, slow, and difficult to use from a mobile device.

It sounds like you already have the data being sent to a webserver.  From there you will need to store the data in a SQL database, such as MySQL or Postgresql.  When you want users to see the other scores, you can implement a simple GET request on your same web service which would query the database, and return back the scores of the other users.

When submitting the score, your app can use this GET operation to read the other scores before submitting it’s own score.

Alternatively, if you need real-time scoring updates, you can use push notifications.  Both Apple and Google have push notification capabilities in their architecture, but this will add some complexity and server requirements.  If you don’t need real-time updates, I’d suggest each app just read the other scores from the leaderboard as needed.

http://developer.apple.com/libra…

Google Cloud Messaging for Android

View Answer on Quora

Securing your app’s data on Android

Great article by SecureState’s Brandon Knight on Mobile App Security.

Securing your data is a common Android security problem.  During my development of Android apps, I’ve noticed lots of information being stored in unprotected areas of the filesystem, such as the /sdcard/Android/data folder.  For example, any file you view or cache offline from Dropbox is stored in /sdcard/Android/data/com.dropbox.android.  Given that Dropbox could be used for both personal and team-based uses, it’s easy to see that corporate data isn’t safe here either.

During the Android 2.2 days, many phones (such as my HTC EVO) had ~200MB available for apps (and storage), supplemented by micro SD.  There was no choice but to save information on the micro SD.  The newer Android phones ship with much more internal storage, meaning app developers can (and should) begin to more to saving data in the app sandbox instead of the public space.  It will take a long time before app developers change over to the new model.  In the meantime, users should be aware of what data is being stored on the micro SD and other public areas of the filesystem.

Android Developers Blog: New Google Maps Android API now part of Google Play services

I’m excited about the new Map Fragment in the latest Google Play services!  I’ve wanted to embed a Map View into one of my fragments for a while.  A lot of developers have requested this feature, and I’m glad to see it in the support library.

Android Developers Blog: New Google Maps Android API now part of Google Play services

Gson and Android

Gson is a lightweight and open-source library from Google which takes care of serializing Plain Old Java Objects (POJO’s) to JSON, and JSON to POJO’s.  Since it is written in Java and has a JAR file available, I found it can also be a great choice for the Android platform as well.  The JAR file weighs in at 190KB, so it will add a little bit of bloat to your app.  However, I think the ease of use is worth the extra space that the code takes up.  With the use of ProGuard, most of the unneeded code will be removed from your APK file anyways.

In my Android app MoPhotos, I have a need to persist some user preferences that the built-in persistence mechanisms were either too simple (preferences) or too heavy-weight (SQLite).  This particular set of preferences is a set of directories that a user has selected for my app to scan and display photos for.

To persist each directory, I first created a model class that represents the data I want to persist for each user selection:

[code lang=”java”]
public class Filesystem
{
private String uri;
private boolean enabled;
private transient List photoDirectories = null;
}
[/code]

By default, any fields in the class will be included in the serialization/deserialization results.  To add additional fields that you do not want to be persisted, use the “transient” keyword to have Gson ignore that field.

The next step was to load the JSON file when the Activity was started.  The loadFilesystemConfiguration method is called during onCreate.  With Gson, this is pretty easy:

[code lang=”java”]
private void loadFilesystemConfiguration()
{
Gson gson = new Gson(); //1
FileInputStream fis = null; 
try { 
fis = this.application.openFileInput("Filesystems"); //2
Type collectionType = new TypeToken<Collection<Filesystem>>(){}.getType(); //3 
List filesystems = gson.fromJson(new InputStreamReader(fis), collectionType); //4
if(filesystems != null) { 
this.photoFileSystems.addAll(filesystems);
}
}
catch(JsonIOException e) { …  }
catch(JsonSyntaxException e) { …  }
catch (FileNotFoundException e) { …  }
finally { 
    try { 
if(fis != null)
fis.close(); //5
}
catch (IOException e)  { …  }
}
}
[/code]

Notes for the above snippit:
//1:  Create the Gson class instance which will deserialize the JSON into our POJO’s
//2:  Open the file storing the JSON string.  By default, I am using the app’s internal file storage space to store the JSON file in a file called “Filesystems”.  The name can be anything you want.
//3:  Because I’m persisting a list of POJO’s, I needed to create this Type object to reflect the collection type needed to give Gson the proper context.
//4:  Deserialize the JSON into a List object.
//5:  Make sure you close the file in the finally block.

Serializing the list of Filesystem objects is just as simple.  In the onDestroy method, the saveFilesystemConfiguration method is called:
[code lang=”java”]
public void saveFilesystemConfiguration()
{
Gson gson = new Gson();
  String filesystemData = gson.toJson(this.photoFileSystems);  //1

FileOutputStream fos = null;
try {
fos = this.application.openFileOutput("Filesystems", Context.MODE_PRIVATE);
fos.write(filesystemData.getBytes());  //2
}
catch (FileNotFoundException e)  { …  }
catch (IOException e)  { …  }
finally {
try {
if(fos != null) fos.close();
}
catch (IOException e)  { …  }
}
}
[/code]

Notes for the above snippit:

//1:  Serialize our List array to JSON into a string.
//2:  Write the JSON string to the filesystem, using the same file name as before, located in the app’s internal storage location.

Gson turned out to be a nice way to serialize this list of objects for my app.  In fact, I ended up using this same general design in 2 other places as well.  Eventually I realized that this mechanism, coupled with a ListActivity and ArrayAdapter, could be implemented as a more general mechanism for storing lists of user preferences.  Maybe next release.

This is probably a very simple use for Gson.  I could have used a simple flat text file and read the directories line-by-line.  However, Gson does make the code a bit easier, and I learned a new skill in the process that might prove helpful for a more complex future scenario.  Gson does add a little bit of weight to your APK, so you’ll have to weigh the cost/benefits against that.

Open File Dialog in Android

Android Open File BrowserThe Android SDK does not have a file browser dialog for use by app developers.  For my app MoPhotos, I needed to allow the user to select a file from their Android system that my app can use. I was surprised to learn there is no real built-in file chooser dialog. From my experience with .NET and the Win32 API, that’s a function that you can count on being there. I did not think it would be difficult to write one myself, but I’m always looking for quicker ways to get there.

Eventually, I found a blog post by Android-er, who shows a very simple version of the mechanics behind a file open dialog. After getting my version of his code up and running, I wanted to make a few modifications to meet my needs. These modifications are:

  • Alphabetize the list of files
  • Exclude hidden files, hidden directories, and directories without read access
  • Only show files with compatible file extensions

Fortunately, this was very easy to do using standard Java API’s. Instead of calling:

[code lang=”java”]
File[] files = f.listFiles();
[/code]

I create a FileFilter to filter out the results:

[code lang=”java”]
File[] files = f.listFiles(new FileFilter() {
@Override
public boolean accept(File pathname)
{
//If a file or directory is hidden, or unreadable, don’t show it in the list.</div>
if(pathname.isHidden())
return false;

if(!pathname.canRead())
return false;

//Show all directories in the list.
if(pathname.isDirectory())
return true;

//Check if there is a supported file type that we can read.
String fileName = pathname.getName();
String fileExtension;
int mid= fileName.lastIndexOf(".");
fileExtension = fileName.substring(mid+1,fileName.length());
for(String s : supportedFileExtensions) {
if(s.contentEquals(fileExtension))
return true;
}

return false;
}
});

[/code]

The last change was to sort the files and directories alphabetically. I do the sorting operations after the list is constructed, but before the ArrayAdapter is initialized.

[code lang=”java”]
//Sort the files alphabetically.
Collections.sort(fileStringList);
Collections.sort(pathStringList);

fileListAdapter = new ArrayAdapter(this.getContext(), R.layout.open_file_entry, R.id.fileName, fileStringList);
ListView lv = (ListView) this.findViewById(R.id.pcap_files_list);
if(lv != null)
{
lv.setAdapter(fileListAdapter);
}
[/code]

So far, this code is working as intended. I don’t know if this is the most-optimal to do this, but that will be analyzed before I release this app to the market. For now, I’m still building out the basic infrastructure.