[WEB SECURITY] The Pirate Bay un-SSL

Denny Roger (EPSEC) denny at epsec.com.br
Mon Oct 27 13:43:38 EDT 2008


Theory

Recently, the world saw  <https://thepiratebay.org/> The Pirate Bay offering
<http://www.slyck.com/story1691_SSL_Encrpytion_Coming_to_The_Pirate_Bay> SSL
encryption on their server. This means that your ISP won't know anymore
which torrent you are downloading, right? Wrong.
 
<http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol_over_Secure_Socket
_Layer> HTTPS is quite useless for protecting static and public content. By
static, I do mean the .torrent file itself. It is always the same. By
public, I do mean than one doesn't need any kind of authentication to pick
up the content. It's always the same, for everyone. For
<http://en.wikipedia.org/wiki/Web_crawler> crawlers, too.



So, one could easily index ( <https://thepiratebay.org/top> a portion of)
The Pirate Bay torrent database by the
<http://en.wikipedia.org/wiki/List_of_HTTP_headers> Content-Length. Then,
one could intercept some encrypted traffic between some machine(s) within
his/her network and the torrents.thepiratebay.org server. Knowing both
(encrypted) request and response lengths, it is possible to get a quite
reliable list of matches from the previously indexed torrent list.

Practice

Don't try this at work, or you might hurt yourself Eye-wink

1.       Use  <http://www.wireshark.org/> Wireshark to capture some torrent
downloads. Torrents are hosted on a separate server, which makes the task
easier yet. Just use the following capture filter: "tcp and port 443 and
host torrents.thepiratebay.org" 

2.       Now, just go with the stream Smiling("Follow TCP Stream" for the
packet you suspect belongs to the torrent download. This will create another
filter, just like "(ip.addr eq 192.168.0.10 and ip.addr eq 83.140.176.156)
and (tcp.port eq 2157 and tcp.port eq 443)") 

3.       Just save the displayed stream anywhere else (pcap1.pcap sounds
nice) 

4.       Now, use my quick&dirty
<http://sysd.org/stas/files/active/0/TPB-TLSlen.pl.txt> TPB-TLSlen.pl Perl
script to get the request/response lengths: 

perl TPB-TLSlen.pl pcap1.pcap

Yeah, I know, it is nasty. It only supports the
<http://en.wikipedia.org/wiki/Transport_Layer_Security> TLS cypher. And it
simply calls the tshark (the command line version of Wireshark) to parse
it's output. 

5.       Now, just paste the REQ and RES values
<http://sysd.org/stas/node/220?req=560&res=91888#TPB> below Laughing out
loud
(note that the REQ value is optional, setting it to 0 simply ignores the
request size for matching) 

Note that you are able to fine-tune the maximum and minimum header sizes.
For the response, the headers are almost the same all the time. The only
thing that varies is the decimal representation of the file length and age.
(Un)fortuately, the request headers do vary for different browsers and
referring pages. However, knowing the request size still helps a bit,
specially if the torrent's filename was huge Smiling

Precision

The following size distribution chart was generated using the database with
~165K torrents: 

torrent size distribution

The most common torrent size is ~14 KB, and it's easy to figure out that
such torrents represent the shared 700 MB files Smiling
There's also a major peak for the 454 bytes torrents. However, bigger
torrents are less common, thus, the size detection technique becomes more
precise. Now, the average "distance" between torrent sizes is ~44 bytes (at
least for the sample I've collected). So, adding a
<http://en.wikipedia.org/wiki/HTTP_cookie> cookie with the random size up to
128 bytes will disrupt the size matching detection a lot. The request size
disruption is even easier: the largest torrent
<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier> URI I've found
was 150 bytes-wide. Thus, padding every request URI to match 150 characters
is enough to make the requests completely indistinguishable. Joining the
pieces (the padding add-on strings are bold):

GET
/4319199/[a4e]Ghost_in_the_Shell_TV_01-26.4319199.TPB.torrent?nVM2UGfcG533un
4ym70eT2
9r0WwBLYdmFCNN+UTV/hiJ7EAXdFU5KfdWHpkB5lXaCmITsACKOPVyjmpbaOB+CrI5 HTTP/1.1

Host: torrents.thepiratebay.org

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1)
Gecko/2008070208
 Firefox/3.0.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,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: https://thepiratebay.org/recent

Cookie: language=pt_BR; country=BR;
PHPSESSID=ad6cb7e414c8dc88e0c2444f6215165a

 

HTTP/1.1 200 OK

Content-Type: application/x-bittorrent

Etag: "2198642509"

Last-Modified: Mon, 28 Jul 2008 22:28:59 GMT

Server: lighttpd

Content-Length: 91601

Date: Mon, 28 Jul 2008 22:37:56 GMT

X-Varnish: 108010229 107999438

Age: 253

Via: 1.1 varnish

Connection: keep-alive

Set-Cookie:
p=68eOfxOC7JwBYcMe1RJWC4Z5PV/lJzqJORW8KROPMH9zQhszSjFnRp2tsNWEoyabWAloneUaoz
MxYtx4hoM9MZUKE/7wGzC3ZKLEZdppG4og3W; expires=Mon, 28-Jul-2008 22:37:56 GMT;
path=/;
 domain=torrents.thepiratebay.org

 

(binary torrent data)

Solution

1.       Use a constant padding in the .torrent files. This messes things a
bit, but stills ineffective. The only advantage is not messing up with the
server Sad

2.       Patch the  <http://www.lighttpd.net/> lighttpd server so it sends a
non-lasting  <http://en.wikipedia.org/wiki/HTTP_cookie> cookie with a random
size. 

 

For more information: http://sysd.org/stas/node/220

 

 

Regards,

 

Denny Roger

 

(11) 8136.8025

www.epsec.com.br

denny at epsec.com.br

 

A EPSEC é uma empresa brasileira especializada em desenvolvimento de
campanhas de conscientização em Segurança da Informação.

 

Fundada em 2008 por profissionais com vasta experiência em projetos de alta
complexidade em Segurança da Informação, Auditoria e Controles Internos, a
EPSEC é reconhecida pelo mercado através de suas palestras inovadoras e por

sua capacidade em disseminar a cultura sobre Segurança da Informação com
alto valor agregado ao negócio de seus clientes.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20081027/c6c59ab9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 458 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20081027/c6c59ab9/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 442 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20081027/c6c59ab9/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 446 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20081027/c6c59ab9/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 9642 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20081027/c6c59ab9/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 457 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20081027/c6c59ab9/attachment-0004.png>


More information about the websecurity mailing list