Motorola Is Listening
article by Ben Lincoln
In June of 2013, I made an interesting discovery about the Android phone (a Motorola Droid X2) which I was using at the time: it was silently sending a considerable amount of sensitive information to Motorola, and to compound the problem, a great deal of it was over an unencrypted HTTP channel.
If you're in a hurry, you can skip straight to the Analysis - email, ActiveSync, and social networking section - that's where the most sensitive information (e.g. email/social network account passwords) is discussed.
Update 2 (2013-07-02 @ 08:03) - potential device security concern
I realized this morning that there may be a more significant problem. See Potential (untested) device security concern, below.
Update 1 (2013-07-02 @ 05:30) - Android, the Droid X2, and Blur
This article has gotten a lot more attention than I expected.
A clarification I'd like to make (because there seems to be a lot of confusion about this) is that the Droid X2 does not use Motorola's "Blur"/"MotoBlur" user interface. That's one of the reasons I picked that model specifically back in 2011 - it seemed to be running something very close to the stock version of Android.
The email client, web browser, text-messaging app, and so on look like the ones that were included on the G1 I had previously, which is about as close to "stock Android" as you can get with a carrier-installed OS. Based on my research, it seems that they've all been modified to silently send data to and/or through the Blur web-service back-end, but there's no indication to the user that this is the case unless they do the sort of network capture that I did. There is no prompt to create or use a Blur user ID - the phone uses a randomly-generated Blur account for all of the behind-the-scenes activity described below.
I would be very interested in trying this same test with more recent Motorola phones, because there's definitely the perception out there that Blur has been phased out, and I think it's much more likely that it's just the UI on their phones that's been changed, as opposed to removing the underlying Blur functionality.
If you're still unsure why I think this is a problem, ask yourself this: if you bought a desktop PC running Windows, then discovered two years later that the hardware manufacturer had installed modified versions of standard Windows software like Outlook Express and Internet Explorer which - without any indication to the user - sent your passwords to, and routed other traffic through servers owned by the PC manufacturer instead of connecting directly to the actual websites and mail servers, would you be OK with it? If not, then why are you when it's a phone instead of a desktop PC?
Technical notes
The screenshots and other data in this article are more heavily-redacted than I would prefer in the interest of full disclosure and supporting evidence. There are several reasons for this:
There is a considerable amount of binary, hex-encoded, and base64-encoded data mixed in with the traffic. As I have not performed a full reverse-engineering of the data, it's hard for me to know if any of these values are actually sensitive at this time, or in the future when someone more thoroughly decodes the protocol.
My employer reminds its employees that publicly identifying themselves as employees of that organization conveys certain responsibilities upon them. I do not speak for my employer, so all information that would indicate who that employer is has been removed.
I would rather not expose my personal information more than Motorola has already.
Discovery
I was using my personal phone at work to do some testing related to Microsoft Exchange ActiveSync. In order to monitor the traffic, I had configured my phone to proxy all HTTP and HTTPS traffic through Burp Suite Professional - an intercepting proxy that we use for penetration testing - so that I could easily view the contents of the ActiveSync communication.
Looking through the proxy history, I saw frequent HTTP connections to ws-cloud112-blur.svcmot.com mixed in with the expected ActiveSync connections.
ActiveSync Configuration Information
ActiveSync configuration information being sent to Motorola's Blur service.
As of 22 June, 2013, svcmot.com is a domain owned by Motorola, or more specifically:
Motorola Trademark Holdings, LLC
600 North US Highway 45 Attn: Law Department
Libertyville IL 60048
US
internic@motorola.com +1.8475765000 Fax: +1.8475234348
I was quickly able to determine that the connections to Motorola were triggered every time I updated the ActiveSync configuration on my phone, and that the unencrypted HTTP traffic contained the following data:
The DNS name of the ActiveSync server (only sent when the configuration is first created).
The domain name and user ID I specified for authentication.
The full email address of the account.
The name of the connection.
As I looked through more of the proxy history, I could see less-frequent connections in which larger chunks of data were sent - for example, a list of all the application shortcuts and widgets on my phone's home screen(s).
Analysis - email, ActiveSync, and social networking
I decided to try setting up each of the other account types that the system would allow me to, and find out what was captured.
Facebook and Twitter
For both of these services, the email address and password for the account are sent to Motorola. Both services support a mechanism (oAuth) explicitly intended to make this unnecessary, but Motorola does not use that more-secure mechanism. The password is only sent over HTTPS, so at least it can't be easily intercepted by most third parties.
Most subsequent connectivity to both services (other than downloading images) is proxied through Motorola's system on the internet using unencrypted HTTP, so Motorola and anyone running a network capture can easily see who your friends/contacts are (including your friends' email addresses), what posts you're reading and writing, and so on. They'll also get a list of which images you're viewing, even though the actual image download comes directly from the source.
Facebook and Twitter data sent to Motorola's Blur service
Facebook password
Facebook friend information
Facebook wall post by friend
Facebook wall post by self
Silent Signon
Twitter password
Twitter following information
Twitter post
Twitter posts are also read through Blur
You know your software is trustworthy and has nothing to hide when it has a function called "silent signon".
Photobucket and Picasa
For both services, email address and password are sent to Motorola over HTTPS.
For Photobucket, username and image URLs are sent over unencrypted HTTP.
For Picasa, email address, display name, friend information, and image URLs are sent over unencrypted HTTP.
During my testing of Photobucket, the photo was uploaded through Motorola's system (over HTTPS). I was not able to successfully upload a photo to Picasa, although it appeared that the same would have been true for that service.
Photobucket and Picasa data sent to Motorola's Blur service
Photobucket password
Photobucket user ID and friend information
Picasa password
Picasa name and friend information
Photo uploads (to Facebook, Photobucket, etc.)
When uploading images, the uploaded image passes through Motorola's Blur servers, and at least some of the time is uploaded with its EXIF data intact. EXIF data is where things like GPS coordinates are stored.
The full path of the original image on the device is also sent to Motorola. For example, /mnt/sdcard/dcim/Camera/2013-06-20_09-00-00_000.jpg. Android devices name phone-camera images using the time they were taken with millisecond resolution, which can almost certainly be used as a unique device identifier for your phone (how many other people were taking a picture at exactly that millisecond?), assuming you leave the original photo on your phone.
Data sent to Motorola's Blur service when uploading photos
Full local path
EXIF data
Service username and tags
Youtube
Email address and password are sent to Motorola over HTTPS.
Email address is also sent to Motorola over unencrypted HTTP, along with some other data that I haven't deciphered.
I didn't have time to create and upload a video, so I'm not sure what else might be sent.
Youtube data sent to Motorola's Blur service
Youtube password
Email address
Exchange ActiveSync
Domain name, username, email address, and name of the connection are sent over unencrypted HTTP. When a new connection is created, the Exchange ActiveSync server's DNS name is also sent.
Exchange ActiveSync data sent to Motorola's Blur service
EAS initial setup
IMAP/POP3 email
Email address, inbound/outbound server names, and the name of the connection are sent over unencrypted HTTP. There is a lot of other encoded/encrypted data included which I haven't deciphered.
IMAP account data sent to Motorola's Blur service
IMAP configuration
One of the few screenshots I can leave some of the important details visible in - in this case, because the account in question is already on every spam list in the world.
Yahoo Mail
Email address is sent over unencrypted HTTP. This type of account seems to be handled in at least sort of the correct way by Motorola's software, in that a request is made for an access token, and as far as I can tell, the actual account password is never sent to Motorola.
Photobucket and Picasa data sent to Motorola's Blur service
Yahoo Mail address
Flickr
Similar to the Yahoo Mail results, but actually one step better - an explicit Flickr prompt appears indicating what permissions Motorola's system is asking for on behalf of the user.
Flickr
Permission screen
The Flickr integration behaves the way every other part of Motorola's Blur service should.
GMail/Google
Interestingly, no data seemed to be sent to Motorola about this type of account. Unfortunately, if anyone adds a Youtube or Picasa account, they've sent their GMail/Google+ credentials to Motorola anyway.
Also interestingly, while testing Picasa and/or Youtube integration, Motorola's methods of authenticating actually tripped Google's suspicious activity alarm. Looking up the source IP in ARIN confirmed the connection was coming from Motorola.
Google: on guard against suspicious vendors
Suspicious activity detected
Source of the suspicious activity confirmed
Firefox sync
No data seems to pass through Motorola's servers.
News / RSS
RSS feeds that are subscribed to using the built-in News application are proxied through Motorola's servers over unencrypted HTTP.
Photobucket and Picasa data sent to Motorola's Blur service
RSS / News sync
Other data
Every few minutes, my phone sends Motorola a detailed description of my home screen/workspace configuration - all of the shortcuts and widgets I have on it.
Home screen configuration and other data sent to Motorola's Blur service
Home screen configuration
Universal account IDs
"Universal account IDs"? Is that why I only see some data sent the very first time I configure a particular account on my phone?
Analysis - "check-in" data
As I was looking through the data I've already mentioned, I noticed chunks of "check-in" data which was a binary upload, and I thought I'd see if it was in some sort of standard compressed format. As it turns out, it is - the 0x1F8B highlighted below is the header for a block of gzip-compressed data.
GZip compressed-data header embedded in check-in data
GZip header (0X1F8B)
What is contained in this data are essentially debug-level log entries from the device. The battery drain and bandwidth use from having the phone set up like this must be unbelievable.
Most of the data that's uploaded is harmless or low-risk on its own - use statistics, and so on. However, this is another mechanism by which Motorola's servers are collecting information like account names/email addresses, and the sheer volume and variety of other data makes me concerned that Motorola's staff apparently care so much about how I'm using my phone. If this were a corporate-owned device, I would expect the owning corporation to have this level of system data collection enabled, but it concerns me that it's being silently collected from my personal device, and that there is no way to disable it.
Information that is definitely being collected
The IMEI and IMSI of the phone. These are referred to as MEID and MIN in the phone's UI and on the label in the battery compartment, but IMEI and IMSI in the logs. I believe these two values are all that's needed to clone a phone, if someone were to intercept the traffic.
The phone number of the phone, and carrier information (e.g. Verizon).
The barcode from inside the battery compartment.
Applications included with the device as well as installed by the user.
Statistics about how those applications are used (e.g. how much data each one has sent and received).
Phone call and text message statistics. For example, how many calls have been received or missed.
Bluetooth device pairing and unpairing, including detailed information about those devices.
Email addresses/usernames for accounts configured on the device.
Contact statistics (e.g. how many contacts are synced from Google, how many Facebook users are friends of the account I've configured on the device).
Device-level event logs (these are sent to Google as well by a Google-developed checkin mechanism).
Debugging/troubleshooting information about most activities the phone engages in.
Signal strengths statistics and data use for each type of radio included in the device. For example, bytes sent/received via 3G versus wifi.
Stack memory and register dumps related to applications which have crashed.
For Exchange ActiveSync setup, the server name and email address, as well as the details of the security policy enforced by that EAS server.
Information that may be being collected
The terms-of-use/privacy policy for the Blur service (whether you know you're using it or not) explicitly specify that location information (e.g. GPS coordinates) may be collected (see Speaking of that privacy policy..., below). I have not seen this in the data I've intercepted. This may be due to it being represented in a non-obvious format, or it may only be collected under certain conditions, or it may only be collected by newer devices than my 2-year-old Droid X2.
While I have no conclusive evidence, I did notice while adding and removing accounts from my phone that the account ID number for a newly-added account is always higher than that for any accounts that existed previously on the device, even if those accounts have been deleted. This implies to me that Motorola's Blur service may be storing information about the accounts I've "deleted" even though they're no longer visible to me. This seems even more likely given the references in the communication to "universalAccountIds" and "knownAccountIds" referenced by GUID/UUID-like values.
Check-in data being sent to Motorola
Application use stats
Basic hardware properties
Bluetooth headset use-tracking
Data use, SMS text, contact, and CPU stats
Label in the battery compartment of my phone
BlurID, IMEI and barcode (from label), IMSI and phone number
EAS setup information
EAS policy elements
Email and Disk Stats
Event logs (these are also captured by Google)
Image upload bug
Logging of newly-installed applications
Missed calls
I told you it was syncing every nine minutes!
Possible client-side SQL injection vulnerability
Radio and per-application stats (e.g. CPU use by app)
Register and stack memory dump
Sync App IDs: 10, 31, 80
Sync App IDs: 40, 70, 20, 2, 60, and 5
System panic auto-reboot
The "sync app ID" information will become more important in the section about XMPP. The system panic messge has all of the regular boot information as well as the reason for the OS auto-reboot (in my case, apparently there is a problem with the modem).
Analysis - Jabber / XMPP stream communication
In some of the check-in logs, I saw entries that read e.g.:
XMPPConnection: Preparing to connect user XXXXXXXXXXXXXXXX to service: jabber-cloud112-blur.svcmot.com on host: jabber-cloud112-blur.svcmot.com and port: 5222
XMPPConnectionManager I:onConfigurationUpdate: entered
XMPPConnectionManager I:onConfigurationUpdate: exiting
WSBase I:mother told us it's okay to retry the waiting requests: 0
NormalAsyncConnection I:Connected local addr: 192.168.253.10/192.168.253.10:60737 to remote addr: jabber-cloud112-blur.svcmot.com/69.10.176.46:5222
TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Wrote out 212 bytes of data with 0 bytes remaining.
TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 202 bytes into buffer
TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 262 bytes into buffer
TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Wrote out 78 bytes of data with 0 bytes remaining.
TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 1448 bytes into buffer
TLSStateManager I:org.apache.harmony.nio.internal.SocketChannelImpl@XXXXXXXX: Read 2896 bytes into buffer
XMPPConnection I:Finished connecting user XXXXXXXXXXXXXXXX to service: jabber-cloud112-blur.svcmot.com on host: jabber-cloud112-blur.svcmot.com and port: 5222
By running a network capture, I was able to confirm that my phone was regularly attempting this type of connection. However, it was encrypted using TLS, so I couldn't see the content of the communication at first.
The existence of this mechanism made me extremely curious. Why did Motorola need yet another communication channel for my phone to talk to them over? Why were they using a protocol intended for instant messaging/chat? The whole thing sounded very much like a botnet (which often use IRC in this way) to me.
Intercepting these communications ended up being much more work than I expected. XMPP is an XML-based protocol, and cannot be proxied by an HTTP/HTTPS proxy, so using Burp Suite or ZAP was out. My first thought was to use Mallory, an intercepting transparent proxy that I learned about in the outstanding SANS SEC 642 class back in the March of 2013. Mallory is a relatively new tool, and is somewhat finnicky to get set up, but I learned a lot doing so. Unfortunately, XMPP is not a protocol that Mallory can intercept as of this writing.
The VM that I built to run Mallory on still proved useful in this case, as I was eventually able to hack together a custom XMPP man-in-the-middle exploit and view the contents of the traffic. If you'd like to know more about the details, they're in the Steps to reproduce - XMPP communication channel section further down this page.
This channel is at least part of the Motorola Blur command-and-control mechanism. I haven't seen enough distinct traffic pass through it to have a good idea of the full extent of its capabilities, but I know that:
The XMPP/Jabber protocol is re-purposed for command-and-control use. For example, certain types of message are sent using the field normally used for "presence" status in IM.
The values exchanged in the presence fields appear to be very short (five-character) base64-encoded binary data, followed by a dash, and then a sequence number. For example, 4eTO3-52, Ugs6j-10, or t2bcA-0. The base64 value appears to be selected at boot. The sequence number is incremented differently based on criteria I don't understand (yet), but the most common step I've seen is +4.
As long as the channel is open, the phone will check in with Motorola every nine minutes.
At least one type of Motorola-to-phone command exists: a trigger to update software by ID number.
At least three such ID numbers exist: 31, 40, and 70 (see the table below). Each of these trigger an HTTP post request to the blur-services-1.0/ws/sync API method seen in the previous section, and the same IDs are logged in the check-in data.
The stream token and username passed to the service are the "blurid" value (represented as a decimal number) which shows up in various places in the other traffic between the phone and Motorola.
ID Name Purpose Data Format Observed In Testing?
2 BlurSettingsSyncHandler Unknown JSON No
5 BlurSetupSyncHandler Unverified - called when a new type of sync needs to be added? gpb Yes
10 BlurContactsSyncHandler Syncs contact information (e.g. Google account contacts) gpb No
20 SNMailSyncHandler Unverified - probably syncs private messages from social networking sites gpb No
31 StatusSyncHandler Syncs current status/most-recent-post information from social networking sites gpb Yes
40 BlurSNFriendsSyncHandler Syncs friend information from social networking sites gpb Yes
50 NewsRetrievalService Syncs news feeds set up in the built-in Motorola app gpb Yes
60 AdminFlunkySyncHandler Unverified - sounds like some sort of remote-support functionality gpb No
70 FeedReceiverService Unknown gpb Yes
80 SNCommentsSyncHandler Syncs status/comment information from social networking sites gpb Yes
The "gpb" data format is how that type of binary encoding is referred to internally by the client logs. I believe it is similar (possibly identical) to Google's "protocol buffer" system.
Here is an example session, including the SYNC APP command being sent by the server. Traffic from the client is represented in red. Traffic from the server is coloured blue.
[Communication after this point takes place over the encrypted channel which the client and server have negotiated.]
XMPP communication channel
XMPPPeek in action
App ID 31 (social networking status) sync
App ID 40 (friends) sync
App ID 50 (news) sync
App ID 80 (social networking comments and status) sync
A few examples of the sync operations triggered by the XMPP communication channel.
While I have seen very little sensitive data being sent as a result of this mechanism, Motorola's privacy policy/terms-of-service related to this system makes me more concerned. There is literally no reason I can think of that I would want my phone to check in with Motorola every nine minutes to see if Motorola has any new instructions for it to execute. Is there some sort of remote-control capability intended for use by support staff? I know there is a device-location and remote wipe function, because those are advertised as features of Blur (apparently even if you didn't explicitly sign up for Blur).
Speaking of that privacy policy...
I honestly can't remember if I explicitly agreed to any sort of EULA when I originally set up my phone. There are numerous "terms of service" and "privacy policy" documents on the Motorola website which all seem designed to look superficially identical, but this one in particular (the one for the actual "Motorola Mobile Services" system (AKA "Blur")) has a lot of content I really don't like, and which is not present in the other, similar documents on their site that are much easier to find. For example, it specifically mentions capturing social networking credentials, as well as uploading GPS coordinates from customers' phones to Motorola.
It is specific to "Motorola Mobile Services", and I know I didn't explicitly sign up for that type of account (which is probably why my phone is using a randomly-generated username and password to connect). I also know that even if I was presented with a lengthy statement which included statements about storing social media credentials, that happened when I originally bought the phone (about two years ago). Should I not have been at least reminded of this when I went to add a social networking account for the first time? Or at a bare minimum, should my phone not let me view any document I allegedly agreed to? The only reason I know of that particular TOS is because I found it referenced in a Motorola forum discussion about privacy concerns.
In any case, here are some interesting excerpts from that document (as of 22 June, 2013). All bold emphasis is mine. I am not a lawyer, and this is not legal advice.
Using the MOTOROLA MOBILE SERVICES software and services (MOTOROLA MOBILE SERVICES) constitutes your acceptance of the terms of the Agreement without modification. If you do not accept the terms of the Agreement, then you may not use MOTOROLA MOBILE SERVICES.
Motorola collects and uses certain information about you and your mobile device ... (1) your device's unique serial number ... (5) when your device experiences a software crash ... (1) use of hardware functions like the accelerometer, GPS, wireless antennas, and touchscreen; (2) wireless carrier and network information; (3) use of accessories like headsets and docks; (4) data usage ... Personal Information such as: (1) your email and social network account credentials; (2) user settings and preferences; (3) your email and social network contacts; (4) your mobile phone number; and (5) the performance of applications installed on your device. ... MOTOROLA MOBILE SERVICES will never collect the specific content of your communications or copies of your files.
The document makes a promise that the content of communications are not collected, but I have screenshots and raw data that show Facebook and Twitter messages as well as photos passing through their servers.
The agreement specifies "when your device experiences a software crash", not "memory dumps taken at the time of a software crash", which are what is actually collected.
Motorola takes privacy protection seriously.
MOTOROLA MOBILE SERVICES only collects personal information, social network profile data, and information about websites you visit if you create a MotoCast ID, use the preinstalled web browser and/or MOTOROLA MOBILE SERVICES applications and widgets like Messaging, Gallery, Music Player, Social Networking and Social Status. If you use non-Motorola applications for email, social networking, sharing content with your friends, and web browsing, then MOTOROLA MOBILE SERVICES will not collect this information. Even if you decline to use the preinstalled browser or the MOTOROLA MOBILE SERVICES applications and widgets, your device will continue to collect information about the performance of your mobile device and how you use your mobile device unless you choose to opt out.
In non-Motorola builds of Android, most/all of those components are still present, but none of them send data to Motorola. Some people might think it was extremely deceptive to add data collection to those components but not make user-visible changes to them that mentioned this. Oh, and of course the OS is still collecting massive amounts of data even if you don't use the modified basic Android functionality.
MOTOROLA MOBILE SERVICES only collects and uses information about the location of your mobile device if you have enabled one or more location-based services, such as your device's GPS antenna, Google Location Services, or a carrier-provided location service. If you turn these features off in your mobile device's settings, MOTOROLA MOBILE SERVICES will not record the location of your mobile device.
So what you're saying is that all I have to do to prevent Motorola from tracking my physical location is disable core functionality on my device and leave it off permanently? Awesome! Thanks so much!
The security of your information is important to Motorola.
When MOTOROLA MOBILE SERVICES transmits information from your mobile device to Motorola, MOTOROLA MOBILE SERVICES encrypts the transmission of that information using secure socket layer technology (SSL).
Except when it doesn't, which is most of the time.
However, no data stored on a mobile device or transmitted over a wireless or interactive network can ever be 100 percent secure, and many of the communications you make using MOTOROLA MOBILE SERVICES will be accessible to third parties. You should therefore be cautious when submitting any personally identifiable information using MOTOROLA MOBILE SERVICES, and you understand that you are using MOTOROLA MOBILE SERVICES at your own risk.
As a global company, Motorola has international sites and users all over the world. The personal information you provide may be transmitted, used, stored, and otherwise processed outside of the country where you submitted that information, including jurisdictions that may not have data privacy laws that provide equivalent protection to such laws in your home country.
You may not ... interfere with anyone's ... enjoyment of the Services
Uh oh.
That document does mention that anyone who wants to opt-out can email privacy@motorola.com. If you have any luck with that, please let me know.
Why this is a problem
While I'm sure there are a few people out there who don't mind a major multinational corporation collecting this sort of detailed tracking information related to where their phone has been and how it's been used, I believe most people would at least like to be asked about participating in this type of activity, and be given an option to turn it off.
I can think of many ways that Motorola, unethical employees of Motorola, or unauthorized third parties could misuse this enormous treasure trove of information. But the biggest question on my mind is this: now that it is known that Motorola is collecting this data, can it be subpoenaed in criminal or civil cases against owners of Motorola phones? That seems like an enormous can of worms, even in comparison to the possibilities for identity theft that Motorola's system provides for.
How secure is Motorola's Blur web service against attack? I'd be really interested to test this myself, but made no attempt to do so because I don't have permission and Motorola doesn't appear to have a "white hat"/"bug bounty" programme. It would be a tempting target for technically-skilled criminals, due to the large volume of Facebook, Twitter, and Google usernames and passwords stored in it.
The fact that the phone actively polls Motorola for new instructions to execute and then follows those instructions without informing its owner opens all of these phones up to automated takeover by anyone who can obtain a signing SSL certificate issued by one of the authorities in the trusted CA store on those phones. Some people may consider this far-fetched, but consider that certificates of that type have been mistakenly issued in the past, and the root certificate for at least one of the CA's responsible for that type of mistake (TURKTRUST) were installed on my phone at the factory.
Potential (untested) device security concern
I didn't make the connection until two days after posting the original version of this article, but I believe there is an even-more-significant problem with the way my device is behaving:
As discussed above, although the command-and-control and some of the device-to-Motorola communication take place over encrypted channels, most of the communication (at least in terms of number of connections to Motorola) is over unencrypted HTTP. That communication is triggered by commands sent over the (encrypted) XMPP channel.
Let me say that again, in a slightly different way:
Commands are being received over a trusted, encrypted channel, but those commands order the device to perform actions across an untrusted, unencrypted channel.
Theoretically, this should mean that it's possible to interfere with the unencrypted channel without having to compromise the encrypted channel at all. The only reason I can think of that this wouldn't work would be if Motorola's developers had used some sort of signing mechanism for the unencrypted HTTP traffic.
If no such additional protection exists, then it should be possible to set up a transparent proxy which forwards on SSL communication to Motorola without attempting to intercept it, while modifying or replacing the contents of the unencrypted HTTP communication. At a minimum (again, assuming there is no additional protection of the HTTP data) this should allow things like RSS feed and social media content to be changed before it reaches the user's phone.
If all of this actually works (and this is a big "if"), and such a transparent proxy is combined with e.g. Jasager, then an attacker could set up the Jasager wireless AP in a public place and simply wait for owners of Motorola devices to pass through the area. Anyone whose device received a sync command (over the encrypted XMPP channel) of the type that allowed the (currently theoretical) attack would have their device (or at least data on that device) automatically compromised.
My guess is that someone is already working on this (e.g. for causing grief for attendees at DefCon or Black Hat), but I thought I'd mention it in case no one else had made the same connection yet.
Again, this is entirely theoretical at this point. If I can find conclusive evidence either way, I'll make another update to this article.
Is there anything good to be found here?
Motorola does appear to be using reasonably-strong authentication for the oAuth login to their system - the username seems to be a combination of the IMEI and a random number (16 digits long[2], in the case of my phone's username), and the password is a 160-bit value represented as a hex string. This would be essentially impossible to attack via brute-force if the value really is random. Due to its length, I'm concerned it's a hash of a fixed attribute of the phone, but that's just a hunch. The non-oAuth components (e.g. XMPP) use the Blur ID as the username, and that is all over the place, e.g. in virtually every URL (HTTP and HTTPS) that the client accesses on the Blur servers.
When uploading images to social networking sites, the Motorola software on the phone sometimes strips the EXIF tags (including geolocation tags) before uploading the image to Motorola. So at least they can't always use that as another method for determining your location.
Finally, both the XMPP and HTTPS client components of the software do validate that the certificates used for encrypted communication were issued by authorities the phone is configured to trust. If the certificate presented to either component is not trusted, then no encrypted channel is established, and data which would be sent over it is queued until a trusted connection can be made. If someone wants to perform a man-in-the-middle attack, they're going to need to get their root CA cert loaded on the target phones, or obtain a signing cert issued by a trusted authority (e.g. TURKTRUST).
At least their software checks SSL cert validity
Untrusted cert - HTTPS client
Untrusted cert - XMPP client
Has anyone else discovered this?
In January of 2012, a participant in a Motorola pre-release test discovered that Motorola was performing device-tracking after a Motorola support representative mentioned that the tester had reset his phone "21 times", and a forum moderator directed him to the special, hard-to-find Motorola privacy policy discussed above.
To my knowledge, this article is the first disclosure of anything like the full extent of the data Motorola collects.
What I am going to do as a result of this discovery
As of 23 June 2013, I've removed my ActiveSync configuration from the phone, because I can't guarantee that proprietary corporate information isn't being funneled through Motorola's servers. I know that some information (like the name of our ActiveSync server, our domain name, and a few examples of our account-naming conventions) is, but I don't have time to exhaustively test to see what else is being sent their way, or to do that every time the phone updates its configuration.
I've also deleted the IMAP configuration that connected to my personal email, and have installed K-9 Mail as a temporary workaround.
I'm going to figure out how to root this phone and install a "clean" version of Android. That will mean I can't use ActiveSync (my employer doesn't allow rooted phones to connect), which means a major reason I use my phone will disappear, but better that than risk sending their data to Motorola.
I'll assume that other manufacturers and carriers have their own equivalent of this - recall the Carrier IQ revelation from 2011.
Which other models of Motorola device do this?
Right now, I have only tested my Droid X2. If you have a Motorola device and are technically-inclined, the steps to reproduce my testing are in the section below. If you get results either way and would like me to include them here, please get in touch with me using the Contact form. Please include the model of your device, the results of your testing, and your name/nickname/handle/URL/etc. if you'd like to be identified.
Steps to reproduce - HTTP/HTTPS data capture
There are a number of approaches that can be used to reproduce the results in this article. This is the method that I used. Of course, the same testing can be performed in order to validate that non-Motorola devices are or are not behaving this way.
Important: I strongly recommend that you do not modify in any way the data your phone sends to Motorola. I also strongly recommend that you do not actively probe, scan, or test in any way the Blur web service. The instructions on this page are intended to provide a means of passively observing the traffic to Motorola in order to understand what your phone may be doing without your knowledge or consent.
Connect a wireless access point to a PC which has at least two NICs.
Use Windows Internet Connection Sharing to give internet access to the wireless AP and its clients.
Set up an intercepting proxy on the PC. I used Burp Suite Professional for the first part of my testing, then switched to OWASP ZAP (which is free) for the rest, since I used a personal system for that phase. Make sure the proxy is accessible on at least one non-loopback address so that other devices can proxy through it.[1]
Configure a Motorola Android device to connect to the wireless AP, and to use the intercepting proxy for their web traffic (in the properties for that wireless connection).
Install the root signing certificate for the intercepting proxy on the Motorola Android device. This allows the intercepting proxy to view HTTPS traffic as well as unencrypted HTTP.
Power the Motorola Android device off, then back on. This seems to be necessary to cause all applications to recognize the new trusted certificate, and will also let you intercept the oAuth negotiation with Motorola./li>
Configure and use anything in the Account section of the device.
Use the built-in Social Networking application.
Take a picture and use the Share function to upload it to one or more photo-sharing services.
Leave the device on for long enough that it sends other system data to Motorola automatically.
Steps to reproduce - check-in data decompression
If you'd like to decompress one of these gzipped data packages, there are also a number of approaches available, but this is the one I used:
Export the raw (binary) request from your intercepting proxy's proxy history. In ZAP, right-click on the history entry and choose Save Raw -> Request -> Body. In Burp Suite, right-click on the history entry and choose Save Item, then uncheck the Base64-encode requests and responses box before saving. Note: you cannot use the bulk export feature of either tool for this step to work - both of them have a quirk in which exporting individual requests preserves binary data, but exporting in bulk corrupts binary data by converting a number of values to 0x3F (maybe it's some Java library that does that when exporting as ASCII?).
Open the exported data in a hex editor (I use WinHex). Remove everything up to the first 0x1F8B in the file. See example screenshot below.
Save the modified version (I added a .gz extension for clarity). See example screenshot below.
Decompress the resulting file using e.g. the Linux gzip -d command, or e.g. 7-zip.
Open the decompressed file in a text editor that correctly interprets Unix-style line breaks (I used Notepad++, partly because it shows unprintable characters in a useful way, and there is some binary data mixed in with the text in these files).
Examine the data your phone is sending to Motorola.
Manually removing extra data so the file will be recognized as gzipped
GZip header (0X1F8B)
Hex editor view of the data
Hex editing complete
Steps to reproduce - XMPP communication channel
This section requires more technical skill and time to replicate than the other two. Right now, it assumes that you have access to a Linux system that is set up with two network interfaces and which can be easily configured to forward all network traffic from the first interface to the second using iptables. If you have a system that is set up to run Mallory successfully already (even though you won't be using Mallory itself here), that would be ideal. I am preparing a detailed ground-up build document and will release that shortly.
In the meantime, assuming you have such a system and some experience using this sort of thing, download XMPPPeek and you should have the tool you need.
Generate an SSL server certificate and private key (in PEM format) with the common name of *.svcmot.com. I made all of the elements of my forged cert match the real one as closely as possible, but I don't know how important this is other than the common name.
Load the CA cert you signed the *.svcmot.com cert with onto your Motorola Android device. Again, I used a CA cert that matched the human-readable elements of the one used by the real server, but I don't know how important that is in this specific case.
You may need to explicitly install the forged *.svcmot.com cert onto your Motorola Android device as well.
Run the shell script from the XMPPPeek page to cause all traffic from the internal interface to be forwarded to the external interface, with the exception of traffic with a destination port of 5222, which should be routed to the port that XMPPPeek will be listening on.
Start XMPPPeek and wait for your phone to connect.
I used a VirtualBox VM with a virtual NIC which was connected for internet access, and a USB NIC which I connected to an old wireless access point. So my phone connected to that AP, which connected through the man-in-the-middle system, which connected to the actual internet connection. I configured the phone to also proxy web traffic through OWASP ZAP so that I could match up the XMPP traffic with its HTTP and HTTPS counterparts.
Footnotes
1. For example, with the default Windows ICS configuration, you can bind the proxy to 192.168.137.1:8071.
2. Mine starts with a 4, but does not pass a Luhn check, in case you were curious.
Last updated: 02 July 2013
Copyright 2009-2013 Ben Lincoln, except where explicitly noted.
