Date: Wed, 7 Dec 2011 12:20:22 -0300
From: Pablo Ximenes <pablo@...en.es>
To: Dan Rosenberg <dan.j.rosenberg@...il.com>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: OMIGOD CIQ HACKING THE WORLD.

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@...il.com>

> On Wed, Dec 7, 2011 at 10:02 AM, Pablo Ximenes <pablo@...en.es> wrote:
> > Hi,
> >
> > 2011/12/7 Dan Rosenberg <dan.j.rosenberg@...il.com>
> >>
> >> On Wed, Dec 7, 2011 at 9:09 AM, Pablo Ximenes <pablo@...en.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@...il.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/
> >> >
> >> >
> >
> >
>

Content of type "text/html" skipped

_______________________________________________
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