Matt Erasmus came up with a great idea for taking the Security Bingo card from RSA, and making our own for the ITWeb Security Summit, and using it to generate some funds for Hackers for Charity. Last year, thanks to companies such as ITWeb, SensePost & Telspace we managed to send R15k over to HFC, and it would be nice to do it (or more) again.

Apple responded to the location logging stuff with a Q&A aimed at dispelling some of they myths all the hype has created. The only problem is, they try to dispel some of the facts too.

After several days of trying all the different solutions proposed as the story has emerged, I think I've finally got a solution that is both usable (i.e. doesn't break anything) and permanent (i.e. apply once and let dry).

My original suggestion of rubbish values + read-only didn't work, untrackerd takes up valuable memory & battery and misses nearly all the worrying data & the SQL triggers file from Tehtri also missed some data and breaks some functionality (most notably the compass). 

Update 3: I've modded Tehtri's approach and it appears to be working nicely, read this post. 

Update 2: untrackerd seems to clear out two tables only, and not the most worrying tables either (at least in my file). After 2 days of use, it didn't change a single entry in my consolidated.db (I was using v0.2). So I've ditched it. However, the guys from Tehtri Security, posted a leet idea to Full Disclosure of using triggers (I had no idea SQLite3 could do triggers). The triggers ensure that the relevant tables get auto-truncated when written to. You can download this SQL file, and apply it to consolidated.db with the command (assuming it's in the same directory):

sqlite3 consolidated.db '.read tehtris-iphone-privacy.sql'

I've checked and applied the triggers, and they seem to be functioning (I watched the file shrink as loc data was written), and location services are working. So far so good. You can either use the backup & restore method discussed below, or if jailbroken, you can scp the file off the device, apply the change and scp back, or install sqlite3 via Cydia and do it on the device.

Update 1 - Warning: This breaks location services. I didn't notice because I spoof my location to a bunch of apps, whoops. The specific aspect that breaks location services appears to be the use of the stub consolidated.db file. The read-only permission flags get ignored on an otherwise "correct" file. You can delete the file regularly and it won't cause any problems however. There is a jailbroken application, untrackerd, which will run a daemon to do it for you. When I get a chance, I'd like to extend the SBSettings GPS switch to delete the file too (i.e. delete consolidated.db on GPS switch on).

Yesterday, Pete Warden and Alasdair Allen released some research and a tool that showed that Apple has been collecting detailed location data since v4 of iOS in a file called consolidated.db. Apart from the worry of wtf Apple is collecting such detailed information, this file is available in the clear in all your iTunes backups, meaning any application on your computer can access it if you haven't encrypted your backups. To demonstrate that, Pete and Alasdair released a demo app that gives a scary amount of detail about your movements.

This is a pretty pointless entry talking about the simple crossword challenge provided by the ITWeb Security Summit.

Firefox 4 implemented the Do Not Track header. This is an option, sent via an HTTP header, to specify to a webserver that the user would like to opt-out of advertising/behavioural tracking. The news came in soon after that the AP News Registry service had implemented support for DNT. So I decided to have a quick look at what this meant. It ended up highlighting why I think DNT will never be a solution by itself, and why it's intended use may even be tenuous.

After Jacob outed the compromise at one of Comodo's resellers, I decided to see how I could best secure my browser when it comes to TLS. This is important given how fundamental TLS is to our daily online activities. The advice I currently recommend and have implemented myself in Firefox 4 consists of:

• Install HTTPS-Everywhere
• Reducing the number of trusted root CA certificates to the most frequently used
• Forcing OCSP revocation checks
• Monitoring for certificate changes

This is a brief how-to enable the same in your browser.

This is a quick note, partially for my own purposes of memory, of an idea. I tried to hit a GoToMeeting page earlier today. I didn't need to log on, just needed some basic information. The problem was it has one of those irritating cookie detector pages. Essentially, even though it doesn't need to set a cookie, it tries to, and if it can't, redirects you to "Sorry, you don't have cookies enabled."

In those situations, you need to allow the site to set a cookie, and then remove the cookie afterwards. Add-ons like CookieSafe let you use "Temporary Permissions" but those are set for much longer than a single page request. So you end up with an unnecessary cookie, potentially used for tracking that you don't need.

The cookies it sets are:

Set-Cookie: g2mVisitor=FirstVisit%3D1299181701998%26LastVisit%3D1299185151317%26RSN%3DDEFAULT; g2mSession=SessionInfo%3D200000000028062301%253A41EA01704E81824; JSESSIONID=abcldXoZn-6ZjaEQ4q95s

What I tried, was to send a fake Cookie: header, with all three of the cookie names it was looking for, but with blank values for each. It worked perfectly. They looked like:

Cookie: g2mVisitor=; g2mSession=; JSESSIONID=

My suggestion then is that CookieManagers provide a "Stub Cookie" option, where a site that wants cookies, but doesn't need them, can think it has set the cookies, but in truth just be getting blank values. It's a quick change that should have minimal impact. I had a quick look at CookieSafe's code (I can't seem to find any contact details for the author), and I'm hoping it's as easy to implement as it looks.

Time, time, time...

Come the turn of the year, many people draw up list of predictions for the next. This list is slightly different, instead of focusing on what new threats, vulnerabilities or attacks we'll see, this is a list of some things that, if not already handled should be in your security strategy for this year. Some organisations are further along than others, and this list is targeted at the average ZA organization based on my observations. (Full disclosure, some of the items relate to services my employer offers, that's just because I believe in them).

GoogleSharing is something I've written about before, and strongly believe in. It's a way of proxying connections to unauthenticated Google services in such a way that:

• Google can't work out who you are (random session cookies are used)
  
• Google can't work out that you're using a proxy
• The proxy can't see your searches (if using SSL)

However, right now it only runs in Firefox. While there are some people looking to port it to other browsers, there are some options available in the meantime, especially for mobile browsers.

While sitting is a couple of talks at BlackHat Abu Dhabi, I got to thinking about how we can improve browser defenses. Much of the problems we have are due to the same problem that has plagued systems since Captain Crunch first blew his whistle at 2600 hertz; the data and control channel are the same. Your browser can't tell the difference between attacker injected script and legitimate scripts and happily responds to both. It's what allows XSS and CSRF attacks, and even SQLi. Framebusting is a great example of this, a site owner doesn't want his page to sit in a frame, but has to compete in the arms race against attackers who want the site to be framed. What we need is some way for a site-owner to specify a security policy, that exists outside of the application. The site-owner should be able to specify that the site shouldn't be framed, and the browser respect that, without an attacker able to inject an alternate set of instructions (or at least not trivially via the actual app). Right now, even if a site-owner is aware of the problem, with a smart security team, all they can do is compete in the arms race.

There's a corollary to the problem however, third-party content. The web is made of mashups. Even single-source content providers still include a raft of third-party content, from RSS feeds, to advertising or JQuery. This introduces a whole set of potential interconnected vulnerability that a site owner can't control. If an ad provider is hacked and used to distribute malware, then the site-owner's only choice (if detected) is to remove the ad.

We need something that can give a site owner control back of their application. Something that can be specified outside of the page content. A security policy that puts all the controls we have available to us with software (enforced security policy & ability to disable features not required) back in the hand of the right people. Once we get it, there's a whole separate discussion about how to get it widely supported and implemented, but we would need to agree on what that should be first.

I've been playing with ways of nuking evercookie-style identifier dropping (note: killing the evercookie specifically is silly, I'm aiming for unknown reimplementation too) and have worked some stuff out about LSOs. LSO are Local Storage Objects, they are ways Flash and Silverlight can store info on your machine rather than the remote server. The most common uses appear to be to drop an identifier, which behaves in exactly the same way as a cookie, or to store preferences (e.g. youtube volume settings).

The following information pertains to OSX, I'll get to other OS'es but I imagine their implementations won't vary greatly.

UPDATE: An iPhone developer has turned this into an awesome little SBSetting addon. You'll still need a jailbroken phone but can install it via Cydia.

My previous experiments in killing the Evercookie in Safari sparked similar posts describing how to do the same for Chrome and Firefox. However, my second most frequent browsing platform is my iPhone, and I thought I would investigate how Apple IOS, MobileSafari & embedded WebKit fares. It does much worse. There are two problems; the first is, any app which embeds MobileWebKit has it's own stores for normal cookies, browser cache and HTML5 storage. Even if you go to your Safari settings (Settings -> Safari -> Clear {Cookies|Cache} & Settings -> Safari -> Databases -> Edit -> (delete all present) ) and delete everything, you haven't cleared the cookies, caches & stores in the other apps (e.g. even a simple cookie set for singe.za.net in Twitter.app's embedded browser, will still exist). The second problem is that, in MobileSafari, even if you do clear your MobileSafari store, the HTML5 localStorage mechanism isn't properly cleared and the evercookie reloads itself.

(Hi Slashdot & The Register readers. Make sure to check the 2nd part on killing iPhone Evercookie's too)

Samy Kamar recently released his tool, evercookie. This uses multiple persistent data stores to set unique identifiers that can be used to identify your browser to a website. While my default Firefox browsing setup is safe against it, I noticed that the "disposable" Safari instance I used was not. I sometimes use a clean Safari instance to test or access things the tinfoil on my Firefox does not let me. After each use I reset everything in it. However, I noticed that evercookie would persist. Here's how to delete it and others using the same mechanisms for Safari on OSX 10.6 (working out the same for other browsers/OS' isn't too difficult):

In his ZaCon talk, Haroon Meer worked in a fascinating comparison, by Michael Anissimov, between the fears that drove George Orwell when writing 1984, and those that drove Aldous Huxley when writing Brave New World.