Kindle Fire Security- Initial Thoughts
After a few hours of messing with the Kindle Fire, I wanted to post a few observations that jumped out almost immediately. This is the first of several posts on the Fire.
These are the “low hanging” fruits:
- Emails are all stored in the /sdcard directory and can be read by any application
- No built-in device lockout after X failed logon attempts
- Your device is shipped already tied to your account, and does not require additional authentication for activation
- User and device identifier information leak out in many public places (more in a later post)
- Other, potentially much worse problems (more in a later post)
There are a few issues that seem to be a lot worse, but we’ll save those for a rainy day. In many ways, the Fire seems rushed. Amazon got a lot right, but certainly missed some easy things.
First off, if you use the Kindle Fire’s email client, congratulations- all of your email is stored within the SD card directory. Any application can list the contents of this directory, copy the database where your email is stored, and read it. This is a significantly degraded approach compared to how Google’s Gmail client works, where emails are kept within internal storage. Internal storage = permissions protect you from non-rooted malicious apps. External storage = anyone can read it. When you plug your Fire into a computer, you have access to the /sdcard directory. The commands below show the /sdcard directories and files leading to your email, while plugged into a computer:
mannino$ pwd /Volumes/KINDLE/Android/data mannino$ ls com.amazon.email com.android.providers.media com.amazon.venezia com.cooliris.media mannino$ cd com.amazon.email mannino$ ls files mannino$ cd files/ mannino$ ls 76f24e2f-cd70-4def-9ad3-17e590d2dc96.db 76f24e2f-cd70-4def-9ad3-17e590d2dc96.db_att mannino$ sqlite3 76f24e2f-cd70-4def-9ad3-17e590d2dc96.db SQLite version 3.6.12 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .tables android_metadata folders messages attachments headers pending_commands sqlite> select * from messages; 4|0|12|1|Get Gmail on your mobile phone|1321422874000|X_GOT_ALL_HEADERS,X_DOWNLOADED_FULLfirstname.lastname@example.org;|email@example.com;||||<html> <font face="Arial, Helvetica, sans-serif"> <p> <a href=" [http://www.google.com/intl/en/mobile/default/mail.html](http://www.google.com/intl/en/mobile/default/mail.html)"> <img src=" [https://www.google.com/intl/en/mobile/images/phones.gif](https://www.google.com/intl/en/mobile/images/phones.gif)" alt="Access Gmail on your mobile phone" style="border:0px;"/> </a>
If you lose your device, someone with a lot of time on their hands will eventually brute force your password. There is no lockout function, at all. Compared to most other Android distributions that default to locking a user out after several failed attempts, this one simply doesn’t. Hence, this fails to protect you against even “casual” bad guys, assuming your password is reasonably simple.
Finally, when Amazon shipped your device, they were “kind” enough to tie it to your account. Yes, the account that is also tied to your credit card(s). After entering your wireless network key, the device will instantly bypass the part of the registration where credentials are required. So if someone snatched your device before you did, they could have went on a shopping spree, downloaded a bunch of books or music, and lived happily ever after with their content. I’m not sure about you, but when something is tied to my credit card, I’d like a little more protection. Amazon should at least require the user’s password before proceeding.
There are actually quite a few other issues, but I’m going to give Amazon some time to fix them before a public disclosure. Yes, this is a device built for consumers. Still, there are no excuses for missing the simple things.
This is the first of several posts on the Fire. So, stay tuned!