Egypt: Media censorship, Tor interference, HTTPS throttling and ads injections?
Leonid Evdokimov, Vasilis Ververis
2016-10-27
Country: Egypt
Probed ISPs: Noor (AS 20928), TE Data (AS 8452), Vodafone (AS 24835)
Censorship method: DPI, network throttling, TCP injections
OONI tests: HTTP Requests, Web Connectivity, Vanilla Tor
Measurement period: 2016-08-27 - 2016-10-26
We recently noticed network anomalies in Egypt and performed a study in an
attempt to understand the situation.
Our findings indicate that the Tor anonymity network appeared to be interfered
with in Egypt, while HTTPS connections to DigitalOcean’s Frankfurt data centre
were throttled. We also found that access to porn sites appeared to be
interfered with via in-band TCP packet injections of advertisement and malware
content, and that the blocking of The New Arab
website led to the blocking of specific content (such as images) of other sites
that are hosted on the same Content Distribution Network (CDN).
Below we present our findings based on network measurement tests performed over
the last two months.
The New Arab website [www.alaraby.co.uk]
(https://explorer.ooni.org/measurement/20161025T230118Z_AS36935_N4hRIq4Ya5raRq0yRrW7dRu9yxeg8m7fgbyNrOd9ugt07uQGK0?input=http:%2F%2Fwww.alaraby.co.uk)
and its mirror website www.alarabyaljadeed.co.uk
has been blocked in Egypt since 2016-01-05 according to the [Guardian]
(https://www.theguardian.com/media/2016/jan/05/saudi-arabia-uae-egypt-block-access-qatari-news-website)
news outlet. Similarly, the domain
www.alarabyaljadeed.co.uk
pointing to the same website (www.alaraby.co.uk) has also been blocked. The
ISPs have not redirected the visitors to any block page or any resource that
explains the reason of the block. Instead, they appear to have used Deep
Packet Inspection (DPI) equipment to censor the content of the website. When
requesting the HTTP version of the websites http://www.alaraby.co.uk and
http://www.alarabyaljadeed.co.uk a response from the middlebox is triggered
containing a blank webpage as is shown by the following two OONI measurements
collected on 25th of October 2016:
The request for the HTTPS version of the websites (https://www.alaraby.co.uk,
https://www.alarabyaljadeed.co.uk) times out and no response is received, as
shown in the following measurement:
Collateral damage
In addition to the censorship of the media website The New Arab, this blocking
has caused some collateral damage to other websites hosted on the same Content
Delivery Network (CDN).
The screenshots below illustrate how these websites appeared from an Egyptian
vantage point (right-side) and when accessed via Tor Browser (left-side):
HTTPS throttling
Throughout August 2016 we noticed that HTTPS connections to a number of
services using DigitalOcean’s Frankfurt data centre appeared to be presenting
network connectivity issues from two Egyptian vantage points: Noor ADSL
(AS20928) and Vodafone Egypt (ex-RAYA
Telecom, AS24835).
As part of our research we found that one way to consistently reproduce a
network interference is by sending HTTPS requests to the network sub-nets
belonging to DigitalOcean’s Frankfurt data center (including, but not limited
to 46.101.128.0/24, 46.101.172.0/24, 46.101.179.0/24 —
AS201229). Our experiment showed consistent
and heavy throttling of HTTPS services located in the network: only 3% of TCP
connection attempts succeeded.
Our latency analysis suggests that all the packets that the client was
receiving were timeout-based TCP
re-transmissions
and that a network device was consistently dropping the first occurrence of
each TCP packet.
Non-encrypted protocols on the other hand, like plain HTTP, which hosted
services in the same sub-nets were not affected. This indicates that only HTTPS
connections were throttled, while insecure HTTP connections to DigitalOcean’s
Frankfurt data centre were successful.
Based on our tests, the last sample of throttling that we observed occurred on
2016-09-01 12:30 UTC.
The complete and detailed technical analysis can be found
here.
Inaccessible URLs
The HTTPS throttling of services hosted by DigitalOcean’s Frankfurt data centre
led to the inaccessibility of various URLs. These include the following:
As well as the following URLs: https://antoniomarques.eu,
https://akombakom.net, https://anadoluefessk.org, https://alexmerkel.com,
https://alexmerkel.me, https://alexmerkel.xyz. The raw JSON OONI
measurements file (25Mb size) of these URLs can be found
here.
The above lists however are not exhaustive and more websites may have been
affected which are not listed here.
Attempts to block Tor
Two days ago, tests were run to examine the reachability of the
Tor anonymity network. The collected measurement
data indicates that the Tor process bootstrap was
disrupted
by blocking requests to directory authorities, which are designed to help Tor
clients learn the list of relays that make up the Tor network.
One of the requests that were found to be blocked is a request to download a
“consensus” document from Tor directory authorities. That request is a plain
HTTP request to the URL:
http://154.35.175.225/tor/status-vote/current/consensus.z from a networking
point of view. Connections to directory authorities are intercepted and
blocking is performed by injecting a packet that terminates the connection
abruptly (a TCP RST packet). This happens right after the server acknowledges
the request.
The injected RST packets share the same static [IP identification (IP ID)]
(https://en.wikipedia.org/wiki/IPv4#Identification) value of 0x3412 as the
injected RST packets used to block aforementioned websites that we have found to be
blocked. Usage of the same IP ID implies that the blocking infrastructure used
to censor Tor is the same (or similar) to that used to block other websites
(see the in depth technical analysis of
in-band TCP content injections).
In our testing we found 7 out of 9 directory authority consensus file requests
to be blocked:
We also found access to the now discontinued Tor directory authority urras to
be blocked
.We did not test the accessibility of the recently added Bitfroest Tor
directory authority, nor do we have samples regarding the potential blocking of
longclaw.
Also, it’s just the set of consensus URLs that are blocked, for example, the
request for /tor/status-vote/current/lack-of-consensus.z produces ordinary
404 Not found error. That implies that the blockage is explicitly targeting
Tor.
Another type of request that is blocked is the Onion Router handshake sent to
ORPort of the well-known Tor router. They appear to be blocked in the same way:
the TCP connection is interrupted by terminating the connection (with a TCP RST
packet) during the TLS handshake (after the first Client Hello from the
client).
The blocking appears to only be targeting Tor in a default configuration. This
means that it’s possible to easily circumvent such censorship by using any
Tor Bridge, including non-obfuscated ones.
Given the fact that the blocking of connections doesn’t happen all the time, a
client should be able to bootstrap a Tor connection successfully with enough
retries. This however can, in some cases, take up to a half an hour.
Moreover, OR connections are only blocked to some subset of the public Tor
network, meaning that if a client has already bootstrapped and has a cached
version of the consensus and descriptors it is likely to work properly. The
connection is not throttled as soon as it is established successfully.
This sort of Tor blockage seems to still be active in the moment of the
publication of this report.
But this is not the first time we noticed interference with the Tor network in
Egypt. Earlier this month, users reported that they couldn’t connect directly
to Tor from Egypt and had to use bridges to access it. Tor Metrics statistics
illustrate that direct
connections
to Tor were reduced on 2nd and 25th October 2016, while the use of
bridges
increased, indicating that Tor might have been blocked. It’s probably worth
noting though that only around 30% of Tor users appear to have used bridges to
circumvent potential censorship.
The following graphs below illustrate the estimated number of
directly-connecting clients and the estimated number of clients connecting via
bridges.
Advertisement and malware injection
Through our research we found false content deliberately injected by at least
one ISP in Egypt: [TE Data] (https://en.wikipedia.org/wiki/TE_Data). This ISP
accounts for 65% of the market
share and
controls over 70% of the Egyptian internet bandwidth TE Data appears to be
using DPI or similar network equipment to conduct a man-in-the-middle attack
and transparently inject content for gaining profit (affiliate advertising) or
malicious purposes (serving malware).
Our experiment showed that there was a 10% probability that mobile device users
connected via Wi-Fi to TE Data ADSL would get redirected when visiting some
porn websites. The redirection injected the URL
http://marketing-sv.com/mads.html, which serves at least two different static
web-pages redirecting to http://go.ad2upapp.com/afu.php?id=788146 either
directly or via static pages from utextads.com subdomains. This
PopUp/PopUnder advertisement network is known to be used by malware authors to
gain revenue.
During our October 2016 investigation the injector was mostly targeting mobile
[User-Agents] (https://en.wikipedia.org/wiki/User_agent). It was not limited to
iPhone and Android platforms, but also targeted BlackBerry and Symbian devices.
In August 2016 OONI Probe also captured a similar
injection
in the TE Data network. The injection was redirecting the user to
http://go.ad2upapp.com/afu.php?id=723454 that further redirects to
http://go.deliverymodo.com/afu.php?id=723454, a different advertising website
but with the same affiliate ID (723454). We also received user complains about
similar injections in transit traffic of Vodafone 3G
(AS36935) and Noor ADSL
(AS20928) pointing to the
http://adf.ly/1cqbTY, marketing-sv.com and infinitiads.com domains.
We also discovered at least one malware
sample
served by the chain of web redirects starting with the aforementioned link
during our research. Our IP TTL and network packet latency analysis confirms
that the injection is done in-band using a DPI or similar network equipment to
conduct a man-in-the-middle attack. The analysis refutes the hypothesis of an
“infected” website serving advertisements instead of content. The statistics
suggest that the injector is located within the TE Data network (not further
than that and not as close as end-user LAN) and transparently injects content
for gaining profit via affiliate advertising.
Client <--(forged packet)-- ISP's middle box <--(valid packet)-- Web server
Third party tools (curl) showing injected content
The curl output excerpts below illustrate how TE Data and Noor ISP redirected
users’ connections to porn websites through the injection of ads. It’s
important though to note that the DNS query answers of the requested domains
are legitimate, and there appears to be no sign of DNS tampering.
TE Data ISP redirected the user visiting http://xnxx.com/ (34th most visited
website in Egypt according to Alexa statistics) to
http://go.ad2upapp.com/afu.php?id=723454.
HTTP headers curl output http://xnxx.com/ in Noor ISP.
* Rebuilt URL to: http://xnxx.com/
* Hostname was NOT found in DNS cache
* Trying 141.0.174.38...
* Connected to xnxx.com (141.0.174.38) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.35.0
> Host: xnxx.com
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< Location: http://go.ad2upapp.com/afu.php?id=723454
< Connection: close
<
* Closing connection 0
Noor ISP redirected the user visiting http://xhamster.com/ (53th most visited
website in Egypt according to Alexa statistics) to http://adf.ly/1cqbTY.
HTTP headers curl output of http://xhamster.com/
* Trying 88.208.18.30...
* Connected to xhamster.com (88.208.18.30) port 80 (#0)
> HEAD / HTTP/1.1
> Host: xhamster.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< Location: http://adf.ly/1cqbTY
< Connection: close
<
* Closing connection 0
The complete and detailed technical analysis of the injected malware and
advertisements in TCP connections can be found
here.
Circumventing censorship
OONI findings in Egypt revealed the censorship of a media website, blocking of
services and malicious TCP injections of advertisements and malware content.
ISPs in Egypt appear to be using DPI, TCP injections and network throttling to
block resources, censor websites and serve advertisements and malware to
internet users.
You can bypass such censorship through the use of
Tor and the Tor
Browser. Users in
mobile networks can use
Orbot (Tor on Android) to
access the web or other mobile applications by using the VPN mode of Orbot
which enables all apps on the device to run through the Tor
network.
Acknowledgements
OONI would like to thank anonymous contributors that reported and shared
evidence to document these incidents including, but not limited to, the
cypherpunk who asked to be identified by the following hashsum:
KCB3XJW2ZVGS2A6MQKIE4NQCMJNFKIXI4KGK6CW4J2OFXFZE6RB5VB35LTLJKMM6ZQ654W57C7JLFWJBHMFH6UNO4CXIK7APUD3H33Y=
Appendix
Detailed technical analysis: