Its been about 12 hours (over 12 hours now since I type slow, get side tracked easily, and ended up eating crackers) since the first security analysis has gone online from FileArchiveHaven for mobile applications.  I have to say I’m impressed with the passion of the readers and the developers and this article sure gathered more attention than expected.  This follow up article covers “whats new” from yesterday, some additional logs and details for tech types, and how you can go about checking applications yourself (its easier than you think).

So if you want to know how to do some basic testing of applications yourself, then this update might be for you!  If you want to see a bit more of the data collected, then this might be for you as well!  If you want something funny or witty then… well this article might not be for you (its probably going to be a little dry).

The Aftermath

Security Changes

Since posting the article, changes have started already.  I’ve had responses from all the developers of applications in the list, and many applications are taking steps towards further encrypting data and securing their applications where necessary.  The intent of the article was to improve security and a big thanks to all involved for making changes towards further securing the ecosystem – the attention of the article has encouraged many applications to review their network usage including how easy it is to encrypt your data over SSL in flurry.

This isn’t intended to be a one-time assessment, next week will be Android week, and I’m sure that will be an interesting data collection experience.

Official Responses

Nemory Studios has posted an official response regarding the data collected.  Although it may not include all the answers, it certainly brings increased transparency to the data and addresses some of the question in the article.  I want to commend them for providing the information – not every developer is willing to be transparent and I suspect lots of the security concerns are net-new information for him.  In some discussions with him, he has confirmed changes are coming to the application line, and I will be eagerly retesting them after the change.

In addition to this, many of the other developers in the article have also notified me they are making security improvements from the article.  This means encrypting more traffic and keeping people safer!  One thing that can always be said about BlackBerry users and developers, they never shy away from increasing security!

Logs and Information

I apologize for the delay in sharing the logs.  They contain tokens and information that could compromise accounts used for the testing that I needed to remove (and being that I’m tired, I’m sure I’ve missed some private details anyway!).

The logs can be accessed here:  http://www.filearchivehaven.com/downloads/FiddlerLogs.zip

Please note you will also need to install Fiddler and I’ve only shared logs relevant to what was shared in the article, there is a lot of logs outside of this that I didn’t clean up for distribution.

Qualifications

I’ve had a few savvy people ask about me about my qualifications and the assessment methodology.  I debated writing about my credentials, the places I’ve worked, or the many brilliant people I’ve met on the subject of security.  But at the end of the day, the reason qualifications comes up is because someone wants to trust the information being presented – and that means simply providing that information won’t do.

So my short answer is: “Don’t trust some guy on the Internet you don’t know”(tm)!  Honestly, the information gleaned in these articles is accessible by anyone comfortable working with a PC and a little bit of knowledge and the data collected and presented is on a persons personal blog.  You certainly don’t need to be an expert.  And my intent is that instead of focusing on trusting my assessment, I will show you how to build your own assessment!

How to Check An Applications Security

I’m going to skip over the obvious, which is checking the Application Security permissions on BlackBerry and jump into some simple steps for breaking down an application.

There are several ways to test an application for security risks.  This typically includes virus scanning, network use assessments, code assessments, statements from the developer or a combination of all of the above!  In the case of BlackBerry World, two levels of virus scanning is performed on submitted applications and the code is difficult to see for the average user!  So we can only rely on statements and information from the developer (i.e. Privacy Policy) and what information an application sends out to the internet.

But What About Source Code?

Well, this had to come with a disclaimer didn’t it?  I definitely recommend against looking into an applications source code.  The source code shows potential – not actual – security flaws, and may not represent what is really used in a product.  If you use or recreate anything you see, you could be in hot water as well.  However, source code viewing also includes visibility into hidden exploits and data calls that the developer may be sitting on without user knowledge (i.e. a timebomb effect or a if-this-then-that style script).  Regardless, I’m certain you would be breaking BlackBerry’s Terms of Service and even a few laws in some countries by decompiling applications.

To this point, in good conscience, I cannot share the source code, binaries, JavaScript / C++ or QML for applications that I’ve tested if theoretically I had obtained such said source code.

So, don’t do it, right?  Good!  What if you wanted to do this theoretically?  The information I’m going to share is public knowledge since the release of the BlackBerry PlayBook – and BlackBerry staff have been well informed of the risks on using their current framework.  That said, BlackBerry have left the BAR format fairly open and made no attempts to encrypt it.  Any user can rename a BAR file to a ZIP, extract the contents, and use hex-editors and text editors to access the various content streams – this will cover most usage cases.  I won’t go into any decompiling steps as smarter folks than I can write better articles on the topic, but remember that the applications are compiled for ARM on ‘UNIX’ (there are quotes on that for a reason!) and that both AIR and Unity3D have public decompilers.  Finally, HTML5 applications are in plain text – which (as you can imagine) is one of my pet peeves.

This means that theoretically you have the capability to reverse engineer the source code for applications assuming you have the BAR installers with increasing effort depending on how deep you wish to go.

Testing Network Traffic

First a really bad, quick and dirty explanation of how the Internet works.  The Internet is very much point based, where data is sent from one location to another by pushing the data between these access points.  Generally most interactions start with a series of digital handshakes in both directions and then exchange data in both directions.  Because this is a sequential exchange of data between two points and using n (unlimited) number of “go-between” zones, we can create our own zone (Proxy) between the end points and listen to the data being submitted both ways. This effectively lets you listen in to your own Internet traffic!

Just remember that the data being transmitted actually depends on the actions you do in the application and when the developer has allowed it.

Step 1:  Install a software proxy, in this case we will use Fiddler

Step 2:  Launch Fiddler.  Everything on your computer is now going through Fiddler.

Step 3:  Optional:  Filter the the traffic from your current PC

The simplest way to hide all traffic from processes on your machine is to click the icon in the Fiddler status bar that says All Processes and change it to Hide All

Step 4:  Enable a Proxy port (I recommend 8080) under Tools then Fiddler Options then Connections

Step 5:  Connect your Phone and PC to the same network (usually easiest via WiFi)

Step 6:  Under Settings > Network Connections, hold on your WiFi connection and select Edit.  Scroll down and enable Proxy.  Here you will need to enter the port above (8080) and the local IP for your machine.

Step 7:  Test that opening any website on your phone populates data in Fiddler.  If this doesn’t work, then something has gone wrong and you may need to re-examine the steps.

That’s it, your now collecting your own data!

Some friendly tips:

• Don’t leave Fiddler running all the time (it will use up some resources).
• You can use File > Save to store any interesting logs you want to review later.
• Click on the X icon and clear any entries prior to capturing data
• Be very cautious who you share data with from Fiddler as it contains authentication codes in a lot of cases and they could use this data to hack into your accounts.
• You can (in some cases anyway) use Fiddler as an HTTPS go-between by issuing a certificate and installing it to your phone to break down HTTPS communication – but don’t worry as much about that for now.  Generally speaking HTTPS is a sign the developer might be doing the right thing.
• I recommend using an Inspector with a Text View and Raw information.  If you right click on a large block of text in the Inspector, you can disable auto-truncate and you can enable word wrapping (makes it easier to read).

With Fiddler running and the data connecting, you can now launch any application on your phone and to see some of the data being submitted.  Play with the options to get used to the software and to see what its being captured.  You will also need to disable Fiddler or disable the Proxy every time you use BlackBerry World.

Now that you have the information, bounce it off other people you know that are tech savvy!  You might be surprised what you find.

Assessing the Risk

OK this section is going to be a long one.  The interesting thing about today’s age, is anyone can have a blog and post anything they like.  This makes things like an assessment methodlogy more individualized and customize, and what is extreme to one user may be perfectly acceptable for another.  I recommend building your assessment based on criteria you are comfortable with, however for the purpose of this article I tend to break data into two groups:

Acceptable use data:  Device information such as PIN, Model, OS and basic location data.  Used primarily for analytics, troubleshooting and generic enough that a person cannot be easily identified from the data itself.  This data typically has no value.

User data:  Information such as account names, login details, email addresses, gender, full name, address, phone number.  Information that can lead you to a person.  This data is typically sellable.

The assessment methodology I used for the article is as follows (general guideline) is a simple categorization:

• Compromised Considerations
  • The application submits private user data that is in plain text and can be picked up by other devices on a network.
  • The application contains (or has been said to contain) remote execution code.
  • The application can have actions acted by the developer against individuals using the application (i.e. punishing or blocking users who leave bad reviews).
  • The application is sending data to known compromised websites.
• High-Risk Considerations
  • The application connects to and stores user data on more than one site.
  • The application pulls data from more than one site unencrypted and presents it to the user including JavaScript or CSS.
• Medium-Risk Considerations
  • These applications submit non-user specific data to multiple locations, typically in plain text.
  • The application hooks into multi-user sites with individual subdomains.
• Low-Risk Considerations
  • The application connects to more than one website over HTTP that could be connected to via HTTPS.
• Clean
  • The application connects only to the service advertised.  Analytics are over HTTPS or no risk data.

Whew – That’s a Lot of Data

So there we go!

Now you know how to grab data from applications to monitor their network use…  It takes a lot of work, and understanding the information can take quite a while.  But the best way to get started is to just try and figure it out as you go.

I have to add if you find this helpful in anyway, or you have created your own assessments – don’t hesitate to leave a comment below.  I apologize for filtering the comments, but it is the only reliable way to ensure complete freedom of spam.