Tag Archives: Java

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.

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.