lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=jzaqwOhANXg50m0aEAyu+NsZXEw@mail.gmail.com>
Date: Mon, 25 Apr 2011 13:33:28 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Laurent OUDOT at TEHTRI-Security <laurent.oudot-ml@...tri-security.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Disabling iPhone Tracking ? Do it Yourself
	(DiT?DiY)

> So, for those who are forced to live with the file "consolidated.db"
> itself, TEHTRI-Security proposes to patch this Apple file, and to add
> some lines of hacking inside it. We found that by adding SQL TRIGGERS
> inside the file itself, we can totally get rid of the tracking issues.
I can envision it now.... A room full of lawyers formulating a
strategy to classify the SQL TRIGGERS as a DRM circumvention tool so
they can bring a PATRIOT Act like response.

Jeff

On Mon, Apr 25, 2011 at 12:09 PM, Laurent OUDOT at TEHTRI-Security
<laurent.oudot-ml@...tri-security.com> wrote:
> Disabling iPhone Tracking ? Do it Yourself (DiT?DiY) :-)
>
> * Situation
>
> An iPhone iOS4 built-in tracking feature was recently discussed publicly
> as sharp people, Alasdair Allan and Pete Warden, created an opensource
> application called iPhone Tracker (
> http://petewarden.github.com/iPhoneTracker/ )
>
> A file called "consolidated.db", that exists on iPhones and 3G iPads,
> contains enough information to map users movements thanks to tracking
> capabilities containing interesting stuff, like MAC Addresses of Access
> Points, GSM details, etc.
>
> Since it became more public (and beyond the fact that it was already
> known..), tons of people are thinking that it could be a malicious
> feature from Apple. Here in this blog, we won't focus on political or
> strategic answers (
> http://www.wired.com/images_blogs/gadgetlab/2011/04/applemarkeybarton7-12-10.pdf
> ).
>
> We just want to play our role: looking at technical security issues in
> this world of never-ending growing dependencies between humans and
> technologies. By the way, we don't want to repeat excellent analysis
> that already exist on many places over the web.
>
> So, let's try to think about a solution for owners of iPhones who need
> strong privacy.
>
>
> * Disabling the threat on Jailbroken iDevices
>
> There are multiple tiny technical problems discussed on the Net with
> this file "consolidated.db". This happens to be an Sqlite file, like
> many other files of the iPhone and the iPad.
>
> A solution has been proposed to the owners of jailbroken iPhones,
> through a nice tool called "Untrackerd" (
> http://apt.thebigboss.org/onepackage.php?bundleid=com.rpetrich.untrackerd&db=
> ).
> Once installed, a standard Unix process called "/usr/bin/untrackerd"
> runs in the background, and tries to regularly destroy parts of the
> consolidated.db file. More exactly, it will try to focus on SQL actions
> like:
> DELETE FROM CellLocation WHERE Timestamp ..
> DELETE FROM WifiLocation WHERE Timestamp ..
>
> The problem is that most iPhone owners don't jailbreak their fetish
> device. So, this solution would not help in that case. Of course, having
> a jailbroken iPhone device is really powerful and you have many ways to
> disable those location tracking issues, as it's just a Unix fight
> between you (root) and some processes and files, with nothing hidden or
> complex.
>
> Could we have something for standard end-users with no jailbreak ?
>
>
> * Trying to disable the threats on non-jailbroken iPhones
>
> A nice proposition was published by Dominic White on his blog (
> http://singe.za.net/blog/archives/1029-Quick-note-on-the-iPhone-Location-Tracking-Disclosure.html
> ). Basically, he explains that you can take the latest backup of your
> iPhone, open this file to extract the unwanted "consolidated.db" file.
> Then if you modify it, re-insert it in the backup, and ask iTunes to do
> a recovery of your iPhone on this latest (modified) backup, you'll have
> fake data on a non jailbroken iPhone !
>
> This is a quite good article, with technical details about how to play
> with the backup issues and files extractions, etc.
>
> To quote this blog again, one limitation would then be that you would
> have to do all those steps regularly, in order to clean the new location
> data that gets written on the iPhone. What a pain..
>
>
> * Disabling iPhone Tracking, Do it Yourself :-)
>
> Here is our humble solution for non-jailbroken iPhones. On such a
> device, we can't delete/shred the consolidated.db file. We can't add
> programs on the iPhone (for classical end-users) that would add
> security. We can't modify permissions on the file system. We can't do so
> many things, as it's a non-jailbroken iPhone.
>
> So, for those who are forced to live with the file "consolidated.db"
> itself, TEHTRI-Security proposes to patch this Apple file, and to add
> some lines of hacking inside it. We found that by adding SQL TRIGGERS
> inside the file itself, we can totally get rid of the tracking issues.
>
> Our technique is quite simple: each time the iPhone tries to insert data
> into this (malicious?) database, "consolidated.db", we delete any
> entries of the tables. How can we do that, as we have no evil process
> running on a non-jailbroken iPhone ? As we wrote previously, there is a
> SQL Feature, well known by hackers, which is called TRIGGERS. It's a way
> to have an automatic action played each time a specific database event
> is seen.
>
> At TEHTRI-Security, we used TRIGGERS tons of time for our penetration
> tests in highly sensitive environment with customers who wanted to see
> if automatic evil things could happen in their databases, ERP, etc. Here
> it's cool to see that TRIGGERS can also be used for positive things, as
> it might help those of you who really need to avoid privacy issues.
>
> SQLite3 TRIGGER Patch examples:
> create trigger privacy_in_WifiLocationHarvest after insert on
> WifiLocationHarvest begin delete from WifiLocationHarvest; end;
> create trigger privacy_in_LocationHarvest after insert on
> LocationHarvest begin delete from LocationHarvest; end;
>
> Of course, you could also wait the future Apple feature that will
> propose you to delete the cache of locations of your iPhone. But if you
> don't want to wait, and if you want to destroy those lines of data each
> time the iPhone tries to write them, then you can try our solution.
>
> Of course, TEHTRI-Security cannot be taken responsible for anything bad
> that would happen because of false manipulations on your devices. Do
> things carefully and of course follow the laws & licenses issues in your
> countries.
>
> Here are the steps that can be followed:
>
> 1- Download http://www.tehtri-security.com/tehtris-iphone-privacy.sql
>
> 2- Rebuild your own consolidated.db file by applying our previous SQL file
> Example:
> sqlite3 consolidated.db '.read
> /Users/idev/iphone/tehtris-iphone-privacy.sql'
>
> 3- Deploy this new patched "consolidated.db" file containing our TRIGGER
> tricks that will delete anything from this database, each time the
> iPhone moves even the smaller finger..
>
> Non-Jailbroken devices: use iTunes recovery as explained before (check
> the blog of Dominic White for the whole process).
>
> Jailbroken devices: if you prefer our solution, that does not run a new
> process in the background (compared to the "untrackerd" solution) with
> live automatic deletion, you just have to copy the new patched
> consolidated.db
> $ scp consolidated.db
> root@...r-jailbroken-iphone:/private/var/root/Library/Cache/locationd/consolidated.db
>
> We hope this tiny article will help some people seeking for native easy
> solutions with standard tools, who would need a stronger level of
> privacy. Of course, this is just a quick article with most pointers to
> the needed concepts. You'll have to dig yourself if you want to build
> your own stuff based on our TRIGGER Patch solution.
>
> Notice that TEHTRI-Security has landed in Singapore this week, to join
> the awesome SyScan 2011 event leaded by Thomas Lim in his team. Last
> year, at SyScan 2010, we published 13 0days, with ways to counter-attack
> exploit-kits (tools like Eleonore, Zeus, SpyEye..). This year, we will
> focus on tricks and attacks related to web clients, etc
> (http://www.syscan.org), smartphones, etc. There will be many other
> tremendous talks given by sharp speakers dealing with IT Security and
> smartphones (like S.Esser!).
>
> Should be a hot week here. Do not hesitate to join us here in Singapore,
> especially if you want more information about privacy issues on phones,
> attack/defense issues, etc.
>
> [SNIP]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ