Dave McGowan
June 2000
The American media had a good laugh over a story that was briefly bandied about a couple of years ago. It seems that a certain manufacturer of consumer electronics had inadvertently released a batch of 'defective' video cameras to the public. These cameras had a most unusual feature: when used in a particular manner, they allowed the user to covertly film unsuspecting people sans clothing.
The press chuckled over this for a few days, particularly when noting that a recall effort by the company had not resulted in the return of very many of the faulty cameras. This is likely because the cameras were not actually defective, at least not in the normal sense of the word. In fact, they performed the normal home video camera functions quite well.
The problem was that they had an extra function. The company explained that this was due to a manufacturing defect - a bad batch of chips - and the story was quickly lost in the shuffle and forgotten. But beneath this seemingly inconsequential story of a company mishap lurked something far more sinister - a brief glimpse into Big Brother's toolbox.
It can be safely concluded that these cameras were not by any stretch of the imagination 'defective.' They actually performed exactly as designed. The problem most likely was that a batch of cameras built for military and/or intelligence purposes found their way onto the consumer market. This obviously presented a bit of a problem for the company. They could not even admit that such technology exists, let alone that they were in the business of developing and manufacturing such devices. The solution? Blame it on a manufacturing defect.
True to form, the media appeared not to notice the patently absurd nature of this pathetic attempt at a cover story. The truth is that the intelligence community has spent decades researching and enormous amounts of cash developing and refining this very type of surveillance technology, and these cameras were one of the end results of that research.
The technology that gives these devices the ability to see through clothes is, needless to say, considerably more advanced than that which is found in your everyday home video camera. You just don't get from one to the other through a manufacturing 'flaw,' just as color television wasn't miraculously born when someone botched a batch of black-and-white picture tubes.
In truth, virtually all consumer electronics - as well as non-consumer technology utilized by business and industry - begins life in the intelligence community, and only after it has outlived its usefulness there does it emerge in the public sphere, often as the newest consumer craze.
The Polaroid camera is a classic example of this. Edwin Land, as has been reported, was a long time member of the intelligence community, where his area of expertise was electronic surveillance. Among other things, he played a key role on the U-2 spy plane project and presided over the Scientific Engineering Institute, a CIA front. (1) He is of course better known as the inventor of the famed camera.
The Polaroid was actually invented long before its debut on store shelves. It should be readily apparent to readers that this breakthrough technology - at a time when no one knew of its existence - would have been of enormous value to the spy-trade, which is precisely why the spooks utilized it for an untold number of years before it was 'reinvented' as a consumer product.
And so it goes with other high-tech innovations as well, including the nifty new through-the-clothes video cameras. This particular form of invasive technology has already begun to creep into the public sphere. Not long after the camera story aired, a local newscast carried a story about a new type of security system being trialed at a U.S. airport. In place of the standard metal detector that we have all come to know and love was what could best be described as an electronic strip-search machine.
This device utilized what appeared to be the very same technology that made its debut in the 'defective' cameras. As travelers and guests passed through the scanner, the operator was viewing what was described as a very accurate representation of their nude forms. As would be expected, this innovation did not seem to be well received and the limited media coverage was promptly dropped.
The surveillance of America, however, continues. Along with the through-the-clothes technology, we now also have through-the-wall surveillance capabilities. (2) And along with the ability to see through walls comes the ability to hear through walls as well. A device known as a laser-guided microphone can be pointed at any pane of glass, allowing the user to eavesdrop upon any conversation emanating from within a windowed structure.
Though a creation of high technology, this device is actually based on a rather low-tech concept: a pane of glass acts as a speaker, of sorts, vibrating in response to the sound waves striking it from inside your home. Any flat, non-rigid, membrane-like surface in a building acts in much the same way.
The drywall that covers the walls of your home, for instance, conducts sound as well. That is how sound travels through a wall. The sound waves strike the drywall on one side of the wall, which acts much like a microphone. Through the studs in the wall (the conduit or speaker wire, so to speak) the sound is transferred to the drywall on the other side, which through vibration then serves as the speaker.
But enough with the physics lessons. The point is that any pane of glass in a building is a potential speaker. And with the use of advanced military technology, it is possible to isolate and amplify the otherwise inaudible sound waves being broadcast from that window pane.
This technology is rapidly being shared with ostensibly civilian law enforcement agencies, so that local law enforcement will soon be able to conduct what amounts to a drive-by search of your home - looking and listening in - without your consent or even your awareness, at any time they should so choose.
Equally alarming is the proliferation of allegedly private firms, dubbed 'data warehouses,' whose sole function is the collection and cataloguing of data about American citizens. The Washington Post recently described how the warehouses function: "Twenty-four hours a day, Acxiom electronically gathers and sorts information about 196 million Americans. Credit card transactions and magazine subscriptions. Telephone numbers and real estate records. Car registrations and fishing licenses. Consumer surveys and demographic details." (3)
Also readily available and fair game are medical records, financial and banking information, military records, marital records, and an array of other personal information. All of this information gathering is greatly facilitated by the technological advances that have been sold to the public as products and services that greatly benefit us as consumers.
For example, the move towards a 'cashless' society has allowed an unprecedented amount of personal data to enter the information marketplace. While it is undoubtedly a convenience to purchase virtually any good or service with an ATM or credit card, it is also quite true that doing so leaves an electronic trail that can and will be followed.
It is not just the types of products you are buying that is tracked, but where you are buying them as well. Your daily routines will, over time, show up in the ways in which you use electronic money. By databasing each transaction, your daily travels can be accurately constructed, as well as your shopping habits and various other aspects of your life.
Another great boom to the information gatherers has been the widespread popularity of the internet. I hate to be the one to break the news, but the innovation that allows you to gather information also allows others to gather information about you. The internet was, long before Al Gore or anyone else 'invented' it, a military intelligence entity. It was designed, implemented and maintained by the intelligence community to fulfill its needs, not yours. And it continues to be an apparatus of the intelligence infrastructure today.
As the Encyclopaedia Britannica tells it: "The Internet had its origin in a U.S. Department of Defense program called ARPANET (Advanced Research Projects Agency Network), established in 1969 to provide a secure and survivable communications network for organizations engaged in defense-related research ... at length the National Science Foundation (NSF), which had created a similar and parallel network called NSFNet, took over much of the TCP/IP technology from ARPANET and established a distributed network of networks capable of handling far greater traffic." (4)
The encyclopedia also notes that, contrary to the current notion that no one controls the internet, "NSF continues to maintain the backbone of the network." The same encyclopedia describes the NSF as "an independent agency of the U.S. government," though what exactly an 'independent' agency of the U.S. government is receives no explanation. Other reports have noted though that the NSF has been heavily involved in funding and conducting MK-ULTRA research. (5)
Britannica explains that the foundation was "inspired by advances in science and technology that occurred as a result of World War II; the NSF was established by the U.S. Congress in the National Science Foundation Act of 1950." What the NSF is, in other words, is one of a blizzard of intelligence fronts that were set up in the immediate aftermath of the forming of the CIA itself in 1947.
Of course, just because the beloved internet was begun as an intelligence entity and is still administered by a government agency doesn't mean that it still functions as an intelligence tool. It is worth noting, however, that the company that was primarily responsible for repackaging the internet into a civilian entity, America Online, is perhaps the most thinly veiled intelligence front ever conceived.
This can be easily verified by a visit to AOL's corporate website, where visitors learn - among other things - that the company is headquartered in Dulles, Virginia. Curious as to where this might be, I attempted to locate the city of Dulles on a couple of maps, to no avail. This, I learned, was because Dulles is actually an offshoot of Langley, Virginia.
Langley is also rather difficult to locate on a map. For the uninitiated, this is because Langley, Virginia is the home of the Central Intelligence Agency. In fact, there isn't much else in Langley, Virginia, which exists almost exclusively to provide residence to the thousands of employees of the CIA's headquarters.
And it is precisely there that you will find the home of AOL. Apparently recognizing the negative connotations of a Langley mailing address, the company essentially created a 'suburb' and named it Dulles. Dulles, by the way, is named in honor of the notorious Dulles siblings, Allen and John Foster, whose names were virtually synonymous with the U.S. intelligence infrastructure through both World Wars and much of the Cold War.
Another fact about AOL that belies its true function is the composition of its Board of Directors. Here you will find such high-level military/intelligence assets as General Colin Powell and General Alexander Haig. All of which gives a whole new meaning to that all-seeing eye that comprises the company's logo.
The ways in which we are encouraged to use the internet also belie an intelligence function. Perhaps the most popular use is for communicating via e-mail, which is rapidly replacing other modes of communication. Not coincidentally, e-mail communications are far easier to intercept than are correspondence by phone or letter, especially given that they are traveling on a network designed by spooks.
Also increasingly popular is on-line shopping, which greatly facilitates the gathering of information about your shopping and spending habits. Yet more disturbing is the push for on-line banking, which is a great idea if you don't mind your banking transactions being added to your information profile. Not that your banker isn't already sharing that information anyway. (6)
The filing of taxes online is being heavily promoted as well. Anyone who now figures their taxes with a program such as Turbotax knows that there will be a steady stream of prompts to file your tax return electronically. Probably the same result could be obtained by sending your return directly to Langley. Of course, belief in the notion that the IRS doesn't share your tax information with any other government agencies has always required a rather large leap of faith.
Perhaps the most alarming use for which the internet is now being promoted is for on-line voting. Though this may sound like an enormous benefit, particularly for those who - due to age or physical infirmity - find it difficult to get to a polling booth, it also means that the notion of secret ballot elections could soon become a distant memory.
There are other ways, as well, in which products hailed as a great boon to consumers are steadily eroding our privacy. These products invariably become ubiquitous virtually overnight, through heavy promotion and advertising coupled with rapidly falling prices. The most obvious example of this is cellular phones.
Cell phones have, of course, tremendously benefited consumers - particularly those arrogant buffoons who feel the need to trumpet their self-importance by making obnoxious calls on elevators. Yet cell phones have a dark side as well: they function as tracking devices, allowing your movements to be precisely monitored. This capacity is an integral feature of the phone: the communications satellite must know where you are in order for you to send and receive your calls.
As was reported in Rolling Stone, "In Japan, cell phones are used to track the precise whereabouts of their users (the software lets you punch in someone's phone number and gives back his location, even the floor he's on). A locational capacity is coming soon to American cell phones by order of the Federal Communications Commission." (7)
Similarly, computerized navigational systems featured in new cars serve the same purpose. And again, this is an integral feature of the technology: the precise location of your vehicle must be known for the system to work. One report noted that: "Receivers for Global Positioning System satellites will become a feature in every new car's navigational system, perhaps allowing a system 'hacker' to track your whereabouts to a centimeter's accuracy." (8)
It's not likely though that system hackers are what you need be concerned about. The spooks who launched and maintain the GPS satellites through intelligence fronts like ITT should be of some concern, however. As should the law enforcement agencies with whom this information will undoubtedly be shared.
Even without the on-board navigational system, it will soon be possible to track any vehicle. One report has noted that "Vehicle Recognition Systems have been developed which can identify a car number plate then track the car around a city using a computerized geographic information system. Such systems are now commercially available." (9)
As are facial recognition systems - powered by software "trained to measure spatial relationships among facial features and to convert that information into a mathematical map of the face." (10) "The revolution in urban surveillance will reach the next generation of control once reliable face recognition comes in. In fact, an American company Software and Systems has trialed a system in London which can scan crowds and match faces against a database of images held in a remote computer." (9)
The database is already being built, by the way. The Washington Post has reported that "A small New Hampshire company that wants to build a national database of driver's license photographs received nearly $1.5 million in federal funds and technical assistance from the U.S. Secret Service last year." (11)
The day is not far off when all of this technology will be combined to erode the last vestiges of privacy rights. As Marc Rottenberg - head of the Electronic Privacy Information Center - has noted: "People don't quite get it yet ... soon there will be computer files of facial images, and when you walk in (a building), your face will be instantly scanned by computer, so you'll be recognized by name." (7)
Picture the day when every store you enter will capture your photo (as is already the case), access a photo database via a high-speed internet connection and identify you by name, Social Security number, etc.. This identification will then be fed into another database from an information warehouse, revealing all the details of your life. Instantly.
Your shopping habits will be examined: do you normally shop in this type of store? If not, then what are you doing there? Your financial status will be examined: can you even afford to shop in this particular store? Your police record will be examined: remember that little shoplifting indiscretion in your youth?
And of course - just to be on the safe side - you might be digitally strip-searched upon entering and leaving the store as well. If you arouse too much suspicion, you might even be tracked after leaving the facility: "All these devices can be linked together and allow police to spy in real time." (6) Then again, you could opt to just stay at home and do all your shopping via the internet. If so, remember to wave to the nice policeman conducting the drive-by search of your home.
1. Gordon Thomas Journey Into Madness, Bantam, 1989
2. Hans H. Chen "New X-Ray Vision Will Let Cops See Through Walls," Sightings, July 21, 1999
3. Robert O'Harrow, Jr. "Data Firms Getting Too Personal?", Washington Post, March 8, 1998
4. Encyclopaedia Britannica Online, www.britannica.com
5. Harry V. Martin and David Caul "Mind Control," Napa Sentinel, August-November 1991
6. Edmund Sanders "Many Banks Giving State Extensive Customer Data," Los Angeles Times, July 16, 1999
7. William Greider "The Cyberscare of '99," Rolling Stone #819, August 1999
8. "Big Brother Now Has An Inc. After It," San Jose Mercury News, July 1, 1996
9. Scientific and Technical Options Assessment "An Appraisal of the Technologies of Political Control," September 1998
10. "The Digital Mugshot," Congressional Quarterly, Inc.
11. Robert O'Harrow, Jr. and Liz Leyden "U.S. Helped Fund Photo Database of Driver IDs," Washington Post, February 18, 1999
cameras.htm
Showing posts with label surveillance. Show all posts
Showing posts with label surveillance. Show all posts
Friday, February 7, 2014
Friday, August 23, 2013
Satellites can see AND LISTEN. (we've known this for years)
It's called laser spying and it was perfected in the 1970s, btw.
Guardian reveal NASA succeeded in using space telescope to decipher voices in a room. Telescope analysed the vibrations of the clothing being worn by the room occupants. This was in 2005.
http://12160.info/page/guardian-reveal-nasa-succeeded-in-using-space-telescope-to-deciph
You have to be under a tree to avoid this kind of surveillance. The thousands of leaves constantly shifting disrupt the signal, working like a kind of farraday cage.
Guardian reveal NASA succeeded in using space telescope to decipher voices in a room. Telescope analysed the vibrations of the clothing being worn by the room occupants. This was in 2005.
http://12160.info/page/guardian-reveal-nasa-succeeded-in-using-space-telescope-to-deciph
You have to be under a tree to avoid this kind of surveillance. The thousands of leaves constantly shifting disrupt the signal, working like a kind of farraday cage.
Saturday, August 10, 2013
Friday, July 19, 2013
Thursday, July 18, 2013
Wednesday, July 3, 2013
Tuesday, July 2, 2013
Motorola Is Listening: 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?
http://www.beneaththewaves.net/Projects/Motorola_Is_Listening.html
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.]
4503600105521277 1-d052e26d5bbb5b4adce7965e3e248a331765623714 BlurDevice
{"Sync":{"APP":[{"d":"sync_app_id: 31\n","q":0}]}}
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.
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.
Friday, June 28, 2013
What do you do when all is lost?
Jim Stone, 6/26/13
Remember, for now it is just the most important people getting murdered, but if it ever comes down to a hot fight against the people you can bet your shorts that the government will use murder via car crash as the ultimate option for getting rid of the resistance. They will no doubt do it en masse. The capability is there via an always on cellular internet connection. Do you really think they won't use it?
This morning I sat thinking. Wondering what I was going to write today. Wondering how on earth we could ever fix the government monster that is now so far beyond control. I thought about Hasting's car, and the obvious electronic hijacking (which I at first did not believe) because LoudLabs messed with the video for visual appeal. But the day time shot proved the crash was real once everything was verified and double checked, and that made me wonder - WHAT kind of government do we have? What kind of monsters are in power?
How did we let them put in place a system where all cars are online all the time and open to tampering all the time, and we don't even realize it in our daily lives? That allows them to play god - kill anyone they want - HOW did we allow this to happen? Perhaps THAT is why the police are now fully authorized to shoot any driver that does not stop - so the fact that the driver could not stop never becomes known. Interesting it is that we now occasionally hear about people who led the police on a massive chase, who never had any criminal history or any history at all, and families saying there is no way the now dead driver would have ever done that . . . . . . Hmmmm . . . . . .
I then thought about Snowden, who is trapped in Russia. I thought he made it to Iceland but he did not, he is sitting in a Russian air port going nowhere. Can't Russia be a little more decent? Are all the nations really screwed that bad?
I then thought about all the shillage and backstabbing Snowden is getting now. How much the MSM is attacking him, calling him a traitor, a flunkee, a loser and all manner of other insults, while the alternative press stupidly postulates that you can't get a memory stick out of an NSA facility, that he is a psy op and a tool. And why? We are now at a time where it is out in the open that cars can be hacked and crashed, and that everything we do with a computer is stolen the moment it is done, the latter compliments of Snowden. We now know that you can have no secrets, the state is GOD, and it has the power to destroy you on a whim and kill you as well. What are we to do about it?
I'd like to clear a couple things up regarding Snowden
First of all, if anyone says you can't get a memory stick out of an NSA facility, they are assuming or dreaming. Once you become a familiar face, all you do is put your security tag up to a scanner and you are in. There are no friskings, no bag checks, NADA, you are just in, and you are out just as easily. Your security clearance does the rest. Obviously if you have a large bag or suitcase or something else of that nature they are going to look as you leave, but a memory stick? COME ON NOW, don't be stupid. There are many cameras available now on Ebay that work great and look like a keychain. You could smuggle even a conventional digital camera in and out repeatedly in a pocket. If anyone says snowden is fake because of the memory stick issue they are dreaming and totally out of touch with the day to day realities of life in an NSA facility, and I know this because I worked there in a much higher position than Snowden. And Snowden a flunkee working for a contractor? DO NOT BE STUPID. That DOES NOT HAPPEN.
I'd like to make a few things perfectly clear about remote control of modern cars
ANY car with Onstar, and all other cars manufactured after 2004 can be hijacked, but some are going to be safer than others.
How they disable the brakes - Only antilock brakes can be disabled. An antilock brake system looks for wheels that are not spinning when the brake is applied, and when it senses a wheel that is not spinning it releases the brake. To hack an antilock brake system and cause it to not allow a driver to brake, all you have to do is fool it into believing none of the wheels are spinning. The brakes will not engage.
How to keep the car running with the key out - This is possible only with cars that use electronic keys. Since the ignition switch activates when it senses the correct electrical characteristics or code in the key, all you have to do is fool the ignition control module into believing the correct conditions are met. There is no mechanical disconnect with an electronic key.
How to keep the car in gear when the driver takes it out of gear - This is possible only with electronically controlled transmissions. Nowadays, all automatic transmissions are electronically controlled. If the transmission is fooled into believing it is supposed to be engaged, it won't matter where you put the selector. The solution then is (some of the time) a manual transmission, which you can take out of gear yourself and just let the engine rev until it blows, but even a few manual transmissions have electronic control now that would make that impossible. Then there is always the clutch with a manual, which you could also push, provided there is a real cable going to that clutch and not just an electronic control.
How to rev the engine to max when the driver is not pushing the gas - This is a no brainer, electronic throttle control is now as old as the hills, and common since 1980. Fool the throttle position sensor into believing it is wide open, and the manifold pressure sensor into believing the car is at 20,000 feet elevation. Everything will open right up and it's max throttle until the crash.
The safest car will have no antilock brakes, a manual transmission, and an old fashioned solid metal key. If you have such a car, even if it is manufactured after 2004, they probably won't attempt a suicide run with it because all they can do is push the gas.
Solutions to the problem if your car is not one of the safe ones - A dashboard fuel pump switch, and a dashboard switch that can cut the power to the antilock brake system. Once the antilock brake system is not functioning, the car is designed to default to mechanical brakes. Introducing a failure into the ABS system by disabling the sensors won't work, because once hacked a totally new environment in which the sensors are irrelevant is created and the fact that the sensors are disabled won't make any difference. If you want, add a third switch for the ignition system.
If I ever end up being able to buy a car again, I will take the ultimate option - put super strong tape on both sides of the plastic part of the fuse bodies, ALL OF THEM, and connect all of that strong tape from all of the fuses together to make a loop, which a rope is tied to and attached to a lawn mower pull start handle, and have that mounted to the underside of the steering column. The moment I notice the car getting wanky, I can pull the handle and rip every single fuse out at the same time. That way I won't void the warranty with any safety modifications.
It's a sad world we live in when the government can pretty much murder anyone they wish. There is no doubt Hastings was murdered, but I think that with a few precautions your modern car can be made safe against a government hack. Remember, for now it is just the most important people getting murdered, but if it ever comes down to a hot fight against the people you can bet your shorts that the government will use murder via car crash as the ultimate option for getting rid of the resistance. They will no doubt do it en masse. The capability is there, via an always on cellular internet connection. Do you really think they won't use it?
Remember, for now it is just the most important people getting murdered, but if it ever comes down to a hot fight against the people you can bet your shorts that the government will use murder via car crash as the ultimate option for getting rid of the resistance. They will no doubt do it en masse. The capability is there via an always on cellular internet connection. Do you really think they won't use it?
This morning I sat thinking. Wondering what I was going to write today. Wondering how on earth we could ever fix the government monster that is now so far beyond control. I thought about Hasting's car, and the obvious electronic hijacking (which I at first did not believe) because LoudLabs messed with the video for visual appeal. But the day time shot proved the crash was real once everything was verified and double checked, and that made me wonder - WHAT kind of government do we have? What kind of monsters are in power?
How did we let them put in place a system where all cars are online all the time and open to tampering all the time, and we don't even realize it in our daily lives? That allows them to play god - kill anyone they want - HOW did we allow this to happen? Perhaps THAT is why the police are now fully authorized to shoot any driver that does not stop - so the fact that the driver could not stop never becomes known. Interesting it is that we now occasionally hear about people who led the police on a massive chase, who never had any criminal history or any history at all, and families saying there is no way the now dead driver would have ever done that . . . . . . Hmmmm . . . . . .
I then thought about Snowden, who is trapped in Russia. I thought he made it to Iceland but he did not, he is sitting in a Russian air port going nowhere. Can't Russia be a little more decent? Are all the nations really screwed that bad?
I then thought about all the shillage and backstabbing Snowden is getting now. How much the MSM is attacking him, calling him a traitor, a flunkee, a loser and all manner of other insults, while the alternative press stupidly postulates that you can't get a memory stick out of an NSA facility, that he is a psy op and a tool. And why? We are now at a time where it is out in the open that cars can be hacked and crashed, and that everything we do with a computer is stolen the moment it is done, the latter compliments of Snowden. We now know that you can have no secrets, the state is GOD, and it has the power to destroy you on a whim and kill you as well. What are we to do about it?
I'd like to clear a couple things up regarding Snowden
First of all, if anyone says you can't get a memory stick out of an NSA facility, they are assuming or dreaming. Once you become a familiar face, all you do is put your security tag up to a scanner and you are in. There are no friskings, no bag checks, NADA, you are just in, and you are out just as easily. Your security clearance does the rest. Obviously if you have a large bag or suitcase or something else of that nature they are going to look as you leave, but a memory stick? COME ON NOW, don't be stupid. There are many cameras available now on Ebay that work great and look like a keychain. You could smuggle even a conventional digital camera in and out repeatedly in a pocket. If anyone says snowden is fake because of the memory stick issue they are dreaming and totally out of touch with the day to day realities of life in an NSA facility, and I know this because I worked there in a much higher position than Snowden. And Snowden a flunkee working for a contractor? DO NOT BE STUPID. That DOES NOT HAPPEN.
I'd like to make a few things perfectly clear about remote control of modern cars
ANY car with Onstar, and all other cars manufactured after 2004 can be hijacked, but some are going to be safer than others.
How they disable the brakes - Only antilock brakes can be disabled. An antilock brake system looks for wheels that are not spinning when the brake is applied, and when it senses a wheel that is not spinning it releases the brake. To hack an antilock brake system and cause it to not allow a driver to brake, all you have to do is fool it into believing none of the wheels are spinning. The brakes will not engage.
How to keep the car running with the key out - This is possible only with cars that use electronic keys. Since the ignition switch activates when it senses the correct electrical characteristics or code in the key, all you have to do is fool the ignition control module into believing the correct conditions are met. There is no mechanical disconnect with an electronic key.
How to keep the car in gear when the driver takes it out of gear - This is possible only with electronically controlled transmissions. Nowadays, all automatic transmissions are electronically controlled. If the transmission is fooled into believing it is supposed to be engaged, it won't matter where you put the selector. The solution then is (some of the time) a manual transmission, which you can take out of gear yourself and just let the engine rev until it blows, but even a few manual transmissions have electronic control now that would make that impossible. Then there is always the clutch with a manual, which you could also push, provided there is a real cable going to that clutch and not just an electronic control.
How to rev the engine to max when the driver is not pushing the gas - This is a no brainer, electronic throttle control is now as old as the hills, and common since 1980. Fool the throttle position sensor into believing it is wide open, and the manifold pressure sensor into believing the car is at 20,000 feet elevation. Everything will open right up and it's max throttle until the crash.
The safest car will have no antilock brakes, a manual transmission, and an old fashioned solid metal key. If you have such a car, even if it is manufactured after 2004, they probably won't attempt a suicide run with it because all they can do is push the gas.
Solutions to the problem if your car is not one of the safe ones - A dashboard fuel pump switch, and a dashboard switch that can cut the power to the antilock brake system. Once the antilock brake system is not functioning, the car is designed to default to mechanical brakes. Introducing a failure into the ABS system by disabling the sensors won't work, because once hacked a totally new environment in which the sensors are irrelevant is created and the fact that the sensors are disabled won't make any difference. If you want, add a third switch for the ignition system.
If I ever end up being able to buy a car again, I will take the ultimate option - put super strong tape on both sides of the plastic part of the fuse bodies, ALL OF THEM, and connect all of that strong tape from all of the fuses together to make a loop, which a rope is tied to and attached to a lawn mower pull start handle, and have that mounted to the underside of the steering column. The moment I notice the car getting wanky, I can pull the handle and rip every single fuse out at the same time. That way I won't void the warranty with any safety modifications.
It's a sad world we live in when the government can pretty much murder anyone they wish. There is no doubt Hastings was murdered, but I think that with a few precautions your modern car can be made safe against a government hack. Remember, for now it is just the most important people getting murdered, but if it ever comes down to a hot fight against the people you can bet your shorts that the government will use murder via car crash as the ultimate option for getting rid of the resistance. They will no doubt do it en masse. The capability is there, via an always on cellular internet connection. Do you really think they won't use it?
We ALL Know You Know
Jim Stone, 6/28/13
Where are all the street cam videos? We know you have them. What's the matter, is the video "classified?" How about all the tracking of people you do with their cell phones? And what about that always on cell connection every car was forced to have at OUR expense, via Federal mandate? Don't have any records from the car with that? Would the access of a car's computer system via the cell network NOT be an unusual event you would be all over and know about instantly? How often does THAT happen?
The more you sit in silence about Hastings death, the more we know you are the enemy, working for the enemy, and that you serve ONE purpose, to subjugate and destroy the American people on behalf of a few chosen "elite". And in doing so, you prove that you are anything but "national" security, which would protect everyone, you are instead "elite" security ensuring that a small band of tyrants is able to sleep well.
You know everyone who was on the phone in the area, who hacked Hastings car, and what cell tower provided the remote control signal. You also have the video in the car which was transmitted from it's on board camera to the controller who used it to crash the car and who the controller was, as well as a recording of every control signal sent. You knew who was setting up the assassination plot before it happened and did nothing, as well as who said what afterward. And your silence about all of this proves one thing - you serve tyranny and NOTHING else.
Perhaps We the People would support you if your work actually did something to help us. But you have proven that you are no longer our National Security Agency.
You were not always a parasite, sucking the host financially while delivering a disease, no, when I was with you just a short while ago you truthfully were working to serve the national interest. What happened to you? How could you have possibly transformed into such a monster in such a short time? When I was leaving I noticed that there were changes happening I could not figure out a reason for - how they could possibly benefit the mission or the American people. Now, after over a decade has passed I have my answer - you cut straight from being a protector to being a filthy tool of tyranny that has nothing at all to do with your originally well earned title.
Come on now, PROVE ME WRONG. WE ALL KNOW YOU KNOW, step up to the plate and show us you are not only there to destroy us.
http://jimstonefreelance.com/
Where are all the street cam videos? We know you have them. What's the matter, is the video "classified?" How about all the tracking of people you do with their cell phones? And what about that always on cell connection every car was forced to have at OUR expense, via Federal mandate? Don't have any records from the car with that? Would the access of a car's computer system via the cell network NOT be an unusual event you would be all over and know about instantly? How often does THAT happen?
The more you sit in silence about Hastings death, the more we know you are the enemy, working for the enemy, and that you serve ONE purpose, to subjugate and destroy the American people on behalf of a few chosen "elite". And in doing so, you prove that you are anything but "national" security, which would protect everyone, you are instead "elite" security ensuring that a small band of tyrants is able to sleep well.
You know everyone who was on the phone in the area, who hacked Hastings car, and what cell tower provided the remote control signal. You also have the video in the car which was transmitted from it's on board camera to the controller who used it to crash the car and who the controller was, as well as a recording of every control signal sent. You knew who was setting up the assassination plot before it happened and did nothing, as well as who said what afterward. And your silence about all of this proves one thing - you serve tyranny and NOTHING else.
Perhaps We the People would support you if your work actually did something to help us. But you have proven that you are no longer our National Security Agency.
You were not always a parasite, sucking the host financially while delivering a disease, no, when I was with you just a short while ago you truthfully were working to serve the national interest. What happened to you? How could you have possibly transformed into such a monster in such a short time? When I was leaving I noticed that there were changes happening I could not figure out a reason for - how they could possibly benefit the mission or the American people. Now, after over a decade has passed I have my answer - you cut straight from being a protector to being a filthy tool of tyranny that has nothing at all to do with your originally well earned title.
Come on now, PROVE ME WRONG. WE ALL KNOW YOU KNOW, step up to the plate and show us you are not only there to destroy us.
http://jimstonefreelance.com/
Tuesday, June 25, 2013
Sunday, June 9, 2013
Tuesday, May 28, 2013
Google Glass and face recognition software: the spys will soon be everywhere you go and it all goes back to Deep Black Servers
Amid growing privacy concerns and repeated statements from Google that its futuristic wearable computer can’t recognize faces, a California software developer has done just that, releasing facial recognition software for Google Glass.
Lambda Labs software lets anyone wearing Google Glass look up faces in a crowd against a computer database, instantly showing someone’s name and any other vital bits of data contained in the app. And even the app developer acknowledges the implications for privacy.
“We have no plans to provide a global facial recognition database,” Stephen Balaban, founder of Lambda Labs, told FoxNews.com. “That’s probably not a good idea.”
Instead, Balaban’s technology is an API intended to allow other software developers working with early versions of Glass to write their own apps.
http://12160.info/forum/topics/facial-recognition-software-coming-to-google-glass?xg_source=shorten_twitter
Lambda Labs software lets anyone wearing Google Glass look up faces in a crowd against a computer database, instantly showing someone’s name and any other vital bits of data contained in the app. And even the app developer acknowledges the implications for privacy.
“We have no plans to provide a global facial recognition database,” Stephen Balaban, founder of Lambda Labs, told FoxNews.com. “That’s probably not a good idea.”
Instead, Balaban’s technology is an API intended to allow other software developers working with early versions of Glass to write their own apps.
http://12160.info/forum/topics/facial-recognition-software-coming-to-google-glass?xg_source=shorten_twitter
Thursday, May 2, 2013
Sunday, April 28, 2013
Friday, April 5, 2013
Big Brother Telescreens everywhere you go these days.
| Subliminals do this to the mind...usually while you are eating or waiting somewhere. |
Wherever anyone goes, especially in the western world, there they are: Big flat screens on every wall positioned at every conceivable angle so you cannot turn away without facing yet another. The sound is turned up loud, so that you have to raise your voice to have a conversation. The result of this is, an annoying digital person at your table who won't shut up. It's the reason sensitive people have an urge to walk out and feel they are being invaded that the rest of the programmed clods don't perceive or feel.
But it's also something...deeper...uglier.
It's about keeping the herd's programming in constant ON mode. That way, even if you avoid TV, radio, and all that silliness, they got you when you go out into the world.
Every dentist/doctor office I've been to in the last 10 years has them and of course, they are extremely loud. When you ask if they could be turned down (or off, if you are the only person in the place; they say NO - this has happened to me dozens of times) you get the sneer and a visit from someone in charge who eyes you with suspicion.
You see, all MSM media has sub-vocal subliminal tracks buried in every song, TV show, news story, sports broadcast. This is centrally controlled.
And there are two types of brain-washing protocols. The usual, ala
Obey the government,
Trust your teachers,
question God's existence,
You are useless - hate yourself,
Satan is your God, etc
And then the weekly/monthly imbeds that are keyed to whatever social or political meme they want the herd to be programmed with. You saw the video of several dozen newscasts from monday of April this year which revealed and proved that all broadcasts are pre-arranged scripts from a single source.
So are the subliminal tracks, updated twice-weekly. Sometimes daily...
They leave nothing to chance...
So, avoid those establishments that have those many big screen programming tools. Give your business to those companies that DO NOT have that junk on each and every wall...sometimes, like Denny's, they are separated by only a few feet, there being upwards of 25 in every prison food sledge hall. Boycott those agency whores.
Your mind and your life and soul, will be very grateful you did.
Subscribe to:
Posts (Atom)

