Re: OMIGOD CIQ HACKING THE WORLD.

[Pablo Ximenes <pablo () ximen es>]

Alright, let´s stop assuming things then. Anyhow, congrats for the great
work. Nice chat, btw.


Att,

Pablo Ximenes

2011/12/7 Dan Rosenberg <dan.j.rosenberg () gmail com>

> On Wed, Dec 7, 2011 at 10:02 AM, Pablo Ximenes <pablo () ximen es> wrote:
> > Hi,
> >
> > 2011/12/7 Dan Rosenberg <dan.j.rosenberg () gmail com>
> > > On Wed, Dec 7, 2011 at 9:09 AM, Pablo Ximenes <pablo () ximen es> wrote:
> > >
> > >
> > >
> > > 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.
> >
> > Well, let´s take a look at a simple HTTP request:
> >
> > POST /login.php HTTP/1.1
> > Host: www.example.com
> > User-Agent: Mozilla/5.0 (Windows;pt-BR; rv:1.8.0.11) Gecko/20070312
> > Firefox/1.5.0.11
> > Accept: text/xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> > Accept-Language: en-gb,en;q=0.5
> > Accept-Encoding: gzip,deflate
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > Referer: http://www.example.com/
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 22
> >
> > username=jdoe&pass=god
> >
> >
> >
> > In this case, the URL being visited is http://www.example.com/login.php
> >
> > In order to capture this URL, the eavesdropping software would have to
> open
> > up the contents of the HTTP payload, get information from the method line
> > (1st line, POST), then get information from the "Host:" line, Merge them
> > together and then assemble the original URL. Bottom line is that the
> > eavesdropping software has to look at the contents in order to assemble
> this
> > seemingly "header" information. I would say this info is content and not
> > header, even for non-HTTPS requests, don´t you think?
> >
> > Even though DNS leaks some info, as you mentioned it´s never the full
> URL.
> > Also, there´s the DNS cache, URL domain names get resolved once in a
> while,
> > and chache is used quite often.
> >
> > And that´s only for URLs, I wonder how deep they would have to digg into
> > HTTP payloads in order to get other metrics that they might be
> collecting.
> > As you already said the samgung model has direct indication of
> collection of
> > "Request type" (GET, POST, etc), "content length" (port of the request´s
> > payload), and "status code" (part of the reply´s payload!), all of which
> > would need deep inspection of HTTP payload request contents as I
> mentioned.
> >
>
> This is more of a semantic argument of what is meant by "content" and
> "header".  At the application layer, the URL is considered a header.
> At the transport or network layer, the entire HTTP payload is
> considered content.  I don't know how the law interprets this.
>
> Regardless, you're correct that they are "digging into" HTTP payloads
> to get this information: their instrumentation is in Webkit, where
> they have easy access to this information.  They never touch POST
> parameters or response bodies, but they do collect the information I
> described.
>
> > > 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.
> >
> > Assuming those metrics were intended mostly for debugging purposes, It
> is a
> > fair assumption that they were indeed colleting this info, since it´s
> very a
> > important piece of data for debugging their data network in terms of
> > application level.
>
> I don't think either of us in a position to make a guess here.  The
> profiles I looked at included almost exclusively radio and telephony
> related data and did not include URLs.  Other profiles might include
> application data like this.  So, like I said, it's definitely possible
> that URLs were being collected, but neither of us actually knows for
> sure, and I'd prefer to not make any assumptions one way or the other.
>
> -Dan
>
> > > -Dan
> >
> >
> > Att,
> >
> > Pablo Ximes
> >
> > > > > 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/