BezeqInt cache poisoning demonstration

Update 3, 15/2/2012: Demo is closed.

Update 2, 29/1/2012: What i though was a fix is not. It looks like BezeqInt is trying to block my demo instead of fixing the problem. I can't be sure though. So i made another demo. You need to be in 109.65.*.* range now and fetch http://i.imgur.com/hggke.jpg
Original MD5: be902241dc59f19950cf4f14f6a4f33e
Poisoned MD5: 7b0e031ba89106b8cd2a988aadfedb8b

Update, 29/1/2012: Demo doesn't work anymore. Apparently BezeqInt finally fixed it, 29 days after it has been notified. I'll be checking it more thoroughly later.

As a continuation to my sneaky proxy series of post i've prepared a little demonstration of cache poisoning. I uploaded a png image to imgur.com and poisoned BezeqInt's proxy cache with a bit different file. While my proof of concept is with png image it is as easy to do it with .exe or any other type of a file.

In order to get the poisoned file from the cache you need to be in 79.18?.*.* range. Go to whatismyip.org and check if your IP starts with 79.18?... If not reboot your router until you get to this range. Next download this image http://i.imgur.com/beUai.png and check MD5 checksum.

If you are a linux/macos user run:

> md5sum beUai.png

Otherwise you can use this service to calculate the checksum by uploading the file.

md5 of the original file at imgur.com:

4a1d744319af6d598f836da5d0e3e979  beUai.png

md5 of my "poisoned" file that i forced proxy to cache:

ab5192e9077074029b35d5d15de6cf05  beUai.png

If you want to download the original file you need to be in some other range or better use a proxy abroad.

Write to me what you get.

Speed test?

As we all know now, BezeqInt has a quite invasive caching proxy. I wondered how does it affect broadband speed test applications out there. Many of us used them at least once. So i made a google search and tried a dozen of those on my 15Mbps line. You can see www.speedtest.net results on the left.

Sydney

Tokyo

New York

Wherever i download from speed is always ~15Mbps. Of course it is too good to be true. Most of the application i've tried used usual http connection to download a test file. Speedtest.net is not an exception so it wasn't a surprise when i found that all the files used in  measurements were served by BezeqInt proxy rendering the results quite meaningless. Most interesting part is that speedtest.net generates  unique urls for measurements although downloaded file is always the same. Which begs the question: how is it possible for proxy to have this file if url is completely new? Two most obvious answers: proxy has been configured that way or it learned from the usage pattern to "optimize" access to this resource. Any way results are useless because i want to measure my actual download speed from that specific location not the speed from some internal BezeqInt server.

If you want to test your download speed from certain locations i'd recommend myspeed.visualware.com. This software doesn't use the usual http port therefore doesn't go through proxy and provides results much closer to the truth.

Sneaky proxy, part 2

In my previous post i gave some details about BezeqInt no opt-out proxy. Being quite technical in nature i feel it didn't explain what is going on for a casual internet user. I hope to fix it with this post and also share some of my new findings.

This proxy stands between you and the internet, scanning your web traffic passively and even saving some of it for later use, hence "caching proxy". It uses some advanced technology to stay invisible but still able to collect and reconstruct files from the traffic passing by, namely DPI. While DPI has recently got a bad vibe in Israel, i don't believe in inherently evil technology. Technology is neither good nor evil. It's the application that may or may not violate the moral boundaries. Quite common analogy to be used while explaining DPI is the post office example. All the information post worker needs to deliver your mail is on the envelope, sending and receiving address. DPI is akin to opening the letter and inspecting its content. Mind you, this analogy is not without defects. Mail packages a routinely screened, etc. I, myself, deployed and used DPI tech in my line of work. It helps to classify traffic prior shaping, detect malicious intent, gather statistics and forensic information. All this has been done for years by private enterprises in order to better control and protect their networks.

My research shows that all three major Israeli providers (BezeqInt, Netvision, 012 Smile) reroute a usual web traffic through their DPI systems. I didn't contact Netvision, but both BezeqInt and 012 Smile refused to even acknowledge the existence of the system claiming that they abandoned such practices years ago. This is not satisfactory and in my book constitutes lying or support stuff is just as ignorant as i was prior my discovery. Even appeal to security, since the way it is done looks awfully similar to man-in-the-middle attack, produced no results. So i stopped wasting my time and money on useless phone calls and emails. Instead, having some free time lately, i concentrated on researching a bit more. The result was my "Tale of a sneaky proxy" post. Since then i made some progress and some of the findings are quite alarming.

As any other software proxies are not exempt from bugs or miscofiguration. Moreover HTTP protocol wasn't build with any kind of transparent proxies in mind, that's why your browser has proxy settings. That is especially true for caching proxies. The Internet Engineering Task Force (IETF) even has a RFC document detailing some of the common problems and workarounds (RFC3143). Given a clever implementation of the proxy at hand i guess it does avoid some of the problems but may introduce others. Most of my experiments were done using BezeqInt ADSL line so the following results and conclusions may or may not be pertinent to other ISPs.

During the exploration i had a feeling that BezeqInt proxy was quite frivolous about what content it's caching. It had no problem caching files that require authentication before downloading. Let me elaborate. You are given a link to a file that asks for username and password to download. You provide your authentication and download the file. Now guess how many copies of the file were made during transmission. Two! One for you and one for BezeqInt proxy cache. I don't think that someone's trying to steal your data. My guess would be - a plain negligence in proxy configuration. That doesn't comfort me either, though. I'd think that many BezeqInt customers would prefer to be aware of such intricacies.
But that's not the worst part of my findings. After looking at all the data i decided to run a simple "cache poisoning" scenario for one of my domains. To my dismay i've succeeded! I was able to force the proxy to cache my version of the file from my other domain. Now imagine this coupled with malicious intent. One can use BezeqInt caching proxy as distribution network for a viruses, trojans, you name it. You think you are downloading some .exe file from a trusted site, nope. It's hackers modified version of the same file that he forced the proxy to cache. You wouldn't know any better. I notified BezeqInt about my findings and i hope it will be fixed soon.

After doing all this research i find myself in a peculiar situation. I can't opt out of the system that "doesn't exist". Changing providers wont help either (may be there are other, smaller ISPs that don't do this kind of traffic surveillance). I have no idea how many customers are affected and the secrecy that this system is surrounded with doesn't give any opportunity to know exactly what has being done with all this surfing data that has being collected or not.

I still have questions that no one seems to have answers for. Should BezeqInt be allowed forcibly reroute its customers through a system like that with no opt-out mechanism? Is there any other purpose besides caching? Should be there any oversight or regulations over this system? I don't know and I'd be happy to hear from someone with insight.