I recently wrote about a German politician who successfully fought to get location data from his mobile provider.

A commenter said mobile devices have to be in constant contact with the provider, so there is bound to be location data. Fair enough, but my hope was to focus on why data is stored and why users are not made aware so they can opt-in or out.

Perhaps the following example will be more clear, as it removes the network and service-model entirely. Last year it was publicly disclosed that the Apple iPhone keeps a record of movement in a local database.

iPhoneTracker is an application that can read the database of locations stored on your iPhone as well as the backups made with iTunes.

You should see something like this:

-rw-r–r– 00000000 00000000 28082176 1297319654 1297319654 1282888290 (4096c9ec676f2847dc283405900e284a7c815836)RootDomain::Library/Caches/locationd/consolidated.db

That text in brackets just before ‘RootDomain::’ is the name of the actual file on disk that holds the location data. Since it’s an SQLite database file, you can use any standard SQLite browser, I’m using this Firefox plugin:

https://addons.mozilla.org/en-US/firefox/addon/sqlite-manager/

Open up the file, choose the ‘CellLocation’ table, and you can browse the tens of thousands of points that it has collected. The most interesting data is the latitude, longitude location and the timestamp. The timestamp shows the time in seconds since January 1st 2001.

Apple is not a provider, and there is no (yet) known use of this information. Yet their mobile devices by default store a detailed database of your locations. They even back it up, so you can monitor any Apple iPhone user’s movements just by reviewing their iTunes sync data.

Why is Apple collecting this information?

It’s unclear. One guess might be that they have new features in mind that require a history of your location, but that’s pure speculation. The fact that it’s transferred across devices when you restore or migrate is evidence the data-gathering isn’t accidental.

[…]

By passively logging your location without your permission, Apple have made it possible for anyone from a jealous spouse to a private investigator to get a detailed picture of your movements.

I guess the advantage over the German politician is that you don’t have to sue Apple to see your data. The disadvantage is that the privacy laws directed at providers do not apply. You have been tracking yourself, but just didn’t know it.

Apple conveniently left it in plain-text format for anyone (e.g. a provider) to read and sell. Some of it might be askew because it is using tower triangulation instead of GPS but I would wager they could easily upgrade the accuracy.

I recommend anyone with an iPhone (or iPad) download the application and create their own “What six months of your life looks like to Apple” web page. Even more fun could be to write an application that pollutes the database with exotic location data to show an iPhone going on virtual vacations.

Updated to add: Apple’s name for the location tracking file is “consolidated.db”, the same name as a radical anti-fascist industrial band from the late 1980s. Hat tip to Jeremy Allaire for mentioning them to me. Ha, how far Apple has come since then, when we used to consider ourselves so alternative and secure on a Mac. I’m sure it’s total coincidence; that and the fact that disposableheroesofhiphoprisy.db was far too obvious.

Dan Goodin points out the correlation in The Reg

The security breach at the Oak Ridge National Laboratory is at least the second time since 2007 that computers have been hacked when employees were duped by phishing emails. The most recent compromise was initiated by messages that were manipulated so that they appeared to come from the lab’s Human Resource Department, The Knoxville News Sentinel reported.

According to a follow-up post, a link included in the fraudulent email, which first entered the lab’s systems on April 7, exploited a critical vulnerability in IE that Microsoft fixed last Tuesday. It was the same bug that fetched a security researcher a $15,000 prize in the recent Pwn2Own hacking contest.

The Pwn2Own exploit was announced March 10, 2011.

Microsoft has fortified IE with a security sandbox that isolates it from more sensitive parts of the operating system, so Fewer had to exploit a design flaw in to break out.

“The (sandbox) escape I found was pretty easy, to be honest,” he said. “Surprisingly so.”

In all, he said it took him about six weeks of full-time research to find the bugs and write working exploits for them.

So, six weeks to write a working “use-after-free bug” exploit from scratch and then less than three weeks from release to breach of a “top-secret” facility.

There definitely is some need for analysis of the social engineering aspects of the attack, but another really interesting angle is related to how Microsoft left customers exposed for a month before it released the patch for the Pwn2Own vulnerability — Security Bulletin MS11-018, April 12, 2011.

Arturo Bejar, who used to lead the security team at Yahoo!, has revealed that Facebook has been struggling to prevent accounts from being hijacked.

We’re also starting to introduce Two Factor Authentication, a new feature to help prevent unauthorized access to your account. If you turn this new feature on, we’ll ask you to enter a code anytime you try to log into Facebook from a new device. This additional security helps confirm that it’s really you trying to log in.

First, it’s great to see Arturo writing publicly. Second, he leaves out details about the “code”. Will he advocate for the same “seal” system as Yahoo!, which was (I can explain, if you ask for details) begrudgingly modeled after financial services sites?

Here’s my suggestion. Facebook, unlike Yahoo! or the financial services sites, has a wealth of second-factor data to mine and manipulate for this system. The code could be represented as a six-by-six block of images from a user’s friends during login. It might look something like this image that I totally just invented from scratch and off the top of my head:

A user then has to correctly identify three people they know in the images by name in order to login (the other six are random). If they don’t recognize their own friends, they are denied access. Aha! Oh, wait, that would mean Facebook users would have to know the people they are “connected” to or have legitimate information in their profile…meh, nevermind.

Also, I noticed that Yahoo! now lets users login using a Facebook or Google ID. Facebook could also address this issue by requiring users to login using their Yahoo! or Google ID, since those sites both already offer two-factor authentication. I’m kidding of course. Google would never allow a user ID to be federated with Facebook.

I have to say I am impressed. Barracuda Networks has come forward on their blog with a simple and clear explanation for the breach — three basic mistakes in security management.

This latest incident brings home some key reminders for us, including that:

• You can’t leave a Web site exposed nowadays for even a day (or less)
• Code vulnerabilities can happen in places far away from the data you’re trying to protect
• You can’t be complacent about coding practices, operations or even the lack of private data on your site – even when you have WAF technology deployed

I agree with them 120%. That level of disclosure is commendable on its own as a sign of honesty and root-cause analysis. However what really impresses me is that they then recommend their product and end up with a very subtle sales spin. The breach analysis could be taken as an example of how to use a control to reduce the risk of security management mistakes.

The Barracuda Web Application Firewall in front of the Barracuda Networks Web site was unintentionally placed in passive monitoring mode and was offline through a maintenance window that started Friday night (April 8 ) after close of business Pacific time.

In other words the incident review suggests that their WAF would have blocked the attacks when configured properly. Don’t you want to buy a WAF now?

The breach is subtly boiled down to an “unintentional” decision to put control in maintenance/passive mode (OWASP Risk A6-Security Misconfiguration). It exposed their database to automated vulnerability scans from the Internet. They might have caught the vulnerability themselves if they had run the same scans earlier (OWASP Risk A1-Injection); or they might have prevented data exposure by keeping it better isolated and segmented. Both of these are covered in their announcement but at the end of the day they are selling WAFs. So it is interesting to hear in this context from them that their product could have blocked the blind SQL injection that caused their breach.