Re: OMIGOD CIQ HACKING THE WORLD.

[Dan Rosenberg <dan.j.rosenberg () gmail com>]

On Wed, Dec 7, 2011 at 9:09 AM, Pablo Ximenes <pablo () ximen es> wrote:
> Hi,
>
> 2011/12/7 Dan Rosenberg <dan.j.rosenberg () gmail com>
> > And I was really hoping I wouldn't get dragged into another discussion
> > on this...
>
>
> Well, if it serves of any consolation, discussions are good for making
> things more clear, I´d assume. Sorry, though.

No worries, I was only (mostly) kidding.  Glad to clear things up.

> > On Wed, Dec 7, 2011 at 7:55 AM, Pablo Ximenes <pablo () ximen es> wrote:
> > > Hi All,
> > >
> > > Based on what I read from the post, basically Rosenberg recognises he
> > > has no
> > > clue about what happens with the rest of affected phone models:
> > >
> > > "One important thing to note is that this represents the metrics that
> > > are
> > > submitted to the CarrierIQ application by the code written by Samsung.
> > > The
> > > list of available metrics are carrier specific, but will remain constant
> > > on
> > > a given handset model. The subset of this data that is actually recorded
> > > and
> > > collected is at the discretion of the carrier, and is based on the
> > > profile
> > > installed on the device." (Dan Rosenberg)
> > >
> > >
> > > So the eavesdropped data with respect to the rest of affected phones
> > > could
> > > be anything for all he knows, including contents of SMS's and visited
> > > pages.
> >
> > This is not accurate.  I have not enumerated the locations on every
> > phone where OEMs have modified the Android framework to submit metrics
> > to the CarrierIQ agent running on the phone.  This means I don't know
> > what subset of metrics that CIQ supports is actually being submitted
> > to the agent on every phone.  However, I have reverse engineered the
> > actual CarrierIQ binaries on a wide variety of phones (the agent code
> > is actually fairly similar across the board), so I have a very good
> > idea of the total set of supported metrics (regardless of what's
> > actually being submitted) looks like.  And surprise, there is no
> > metric that contains fields for SMS bodies or web page contents.
>
> Glad you made yourself more clear this time. :) Suggestion: why don´t you
> publish the full set of metrics found on your investigation? That would make
> your research report even more complete.

I think publishing that level of detail about a piece of commercial
software would be approaching legally questionable in terms of the
DMCA.  You'll just have to take my word for it that the *vast*
majority of metrics supported are not only benign, but horribly
boring.

> > Food for thought: why would a carrier double their bandwidth
> > utilization for SMS in order to violate federal wiretapping law and
> > get a second copy of the text message *that they already have*?
>  Good point! But that´s not the case for encrypted HTTP data, though.

True.  But also imagine the cost-benefit ratio of your carrier
doubling every user's data plan to get that HTTP data.  The costs
would be astronomical.

> > > And about collecting every URL (even https ones) that is visited. Forget
> > > about the legality, let's go directly to the privacy implications.
> > > For instance, if you do that for a simple Facebook session, there's a
> > > huge
> > > amount of very private information being collected (fixed URLS that
> > > reveal
> > > photos, etc;  ajax URLs that reveal juicy IDs, among other things).
> > > Also, I
> > > don't think anybody would want to have their complete web history in the
> > > hands of anyone without their express consent.
> >
> > Agreed.  It will be interesting to see whether or not this information
> > is actually being collected, since I've only shown that it's
> > *possible* for it to be collected, not that it actually is.
> >
> > > Going back to the legality, even if the URL is just the begining of an
> > > HTTP
> > > negotiation process, it doesn't mean that URLs are not payloads legally.
> > > In
> > > many countries only layers 4 (transport) and bellow (TCP info, IP data,
> > > etc)
> > > would be considered header information and all the rest would be
> > > considered
> > > payload, incluing the URL. If what Rosenberg claims is that a URL is not
> > > considered payload to the law, I thing he might have to review his
> > > concepts.
> > > In Brazil, for instance, capturing the URL alone in this scenario would
> > > constitute a crime of illegal wiretapping.
> >
> > I never made this claim.  I explicitly state that the legality of this
> > needs to be investigated, since to my knowledge, it's an open legal
> > question in the United States.
>
> Well, it wasn´t clear to me, that´s why I used a "IF"  when questioning your
> claims. Maybe I should have made it Bigger. :)
>
> Since we are on that, there´s one question I think you could answer. Are
> URLs content or header information in your opinion? (kind of the main point
> I was raising doubts about)

That's a good question.  As you've mentioned, the URL falls within the
HTTP request, the entirety of which is protected by SSL.  So I would
argue that the URL is content that should remain secret in an SSL
session.  I haven't made up my mind whether the same applies to
non-HTTPS URLs.  The issue is further complicated by the fact that
perhaps the domain (without query parameters) that's being requested
shouldn't be considered secret since this is readily available by
looking at DNS.

Please note that I'm not a lawyer, so I don't know the wording of any
laws related to this sort of thing.  Also remember that it remains to
be seen whether URL data is/was being collected at all, which is
obviously a key piece of information with regards to the legal issues
at hand.

-Dan


> > Regards,
> > Dan
>
>
> Regards,
>
> Pablo Ximenes
>
> > > Regards,
> > >
> > > Pablo Ximenes
> > >
> > > 2011/12/6 Christian Sciberras <uuf6429 () gmail com>
> > > > Or not...
> > > >
> > > > http://vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/
> > > >
> > > > On the other hand, where that l33t hacker Drew (aka xD 0x41)?
> > > > Thought he'd enlighten us with more of his awesome hacking powers on
> > > > this
> > > > issue.
> > > >
> > > > _______________________________________________
> > > > Full-Disclosure - We believe in it.
> > > > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > > > Hosted and sponsored by Secunia - http://secunia.com/
> > >
> > >
> > >
> > > _______________________________________________
> > > Full-Disclosure - We believe in it.
> > > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > > Hosted and sponsored by Secunia - http://secunia.com/

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