FrontPoint and Alarm.com – The Digital Security Eval

Most of the folks using the GE Simon XT for their home security systems are amazed that they can use their Android, iPhone, or Blackberry to remotely lock their homes. I was curious as to what was actually being passed. I loaded my OpenWRT router with tcpdump and did some basic dumps on a br0 interface to see what all was being passed. A few quick points:

  • The phones use a single address to communicate with: 209.222.135.16
  • This resolves to alarm.com, but communicates via the IP address rather then domain name. This causes certificate conflicts as the cert is tied to alarm.com Not a big deal, but it does open up the ability to MitM a little easier
  • All communications to and from is via HTTPS
  • Alarm.com is in Ashburn VA! Local folks

I would post the *.pcap, but they are as exciting as a HTTP request through SSL can be. I didn’t go the route of setting up a private CA and doing sslsniff. This was just a quick verification I wasn’t handing my home over to script kiddies.

Next I took a look at the storage on the Android phone. Most of the files associated to the app can be found in /data/data/com.alarm.alarmmobile.android. The directory printout:

# pwd/data/data/com.alarm.alarmmobile.android

# ls -la

drwxr-x–x    1 app_108  app_108      2048 Mar 18 03:26 .

drwxrwx–x    1 system   system        2048 Mar 18 13:22 ..

drwxrwx–x    1 app_108  app_108      2048 Mar 15 18:43 cache

drwxrwx–x    1 app_108  app_108      2048 Mar 15 19:29 databases

drwxrwx–x    1 app_108  app_108      2048 Mar 15 18:42 files

drwxr-xr-x    1 system   system        2048 Mar 18 03:26 lib

drwxrwx–x    1 app_108  app_108      2048 Mar 18 13:51 shared_prefs

It appears the app stores the authentication with an AUTH token as seen in

/data/data/com.alarm.alarmmobile.android/shared_prefs/SESSION_INFO_PREFERENCE_KEY.xml

<map><string name=”SESSION_INFO_SEAMLESS_LOGIN_TOKEN_KEY”>*******************</string>

<int name=”SESSION_INFO_CUSTOMER_ID_KEY” value=”***” />

</map>

Next I moved into the databases directory and took a look at the contents. webview.db hosted the majority of the information:

sqlite> select * from sqlite_master;
table|android_metadata|android_metadata|3|CREATE TABLE android_metadata (locale TEXT)
table|cookies|cookies|4|CREATE TABLE cookies (_id INTEGER PRIMARY KEY, name TEXT, value TEXT, domain TEXT, path TEXT, expires INTEGER, secure INTEGER)
index|cookiesIndex|cookies|5|CREATE INDEX cookiesIndex ON cookies (path)
table|formurl|formurl|6|CREATE TABLE formurl (_id INTEGER PRIMARY KEY, url TEXT)
table|formdata|formdata|7|CREATE TABLE formdata (_id INTEGER PRIMARY KEY, urlid INTEGER, name TEXT, value TEXT, UNIQUE (urlid, name, value) ON CONFLICT IGNORE)
index|sqlite_autoindex_formdata_1|formdata|8|
table|httpauth|httpauth|9|CREATE TABLE httpauth (_id INTEGER PRIMARY KEY, host TEXT, realm TEXT, username TEXT, password TEXT, UNIQUE (host, realm) ON CONFLICT REPLACE)
index|sqlite_autoindex_httpauth_1|httpauth|10|
table|password|password|11|CREATE TABLE password (_id INTEGER PRIMARY KEY, host TEXT, username TEXT, password TEXT, UNIQUE (host, username) ON CONFLICT REPLACE)
index|sqlite_autoindex_password_1|password|12|

All in all the application looks pretty secure. The token is the weak-link. Given some more time I might try and see what calls are exchanged from the phone to their web service.

Updated: