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

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/
>> >
>> >
>
>

_______________________________________________
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