Egypt: Media censorship, Tor interference, HTTPS throttling and ads injections?

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.

• Media censorship

  • Collateral damage

• HTTPS throttling

  • Inaccessible URLs

• Attempts to block Tor

• Advertisement and malware injection

  • Third party tools (curl) showing injected content

• Circumventing censorship

• Acknowledgements

• Appendix

Media censorship

The New Arab website www.alaraby.co.uk and its mirror website www.alarabyaljadeed.co.uk has been blocked in Egypt since 2016-01-05 according to the Guardian 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:

• Blocking of www.alaraby.co.uk via HTTP

• Blocking of www.alarabyaljadeed.co.uk via HTTP

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:

• Timing out of requests to www.alaraby.co.uk via HTTPS

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:

• Blocking of https://050media.nl

• Blocking of https://33-km.ru

• Blocking of https://laracasts.com

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) 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:

• Blocking of consensus document requests to the moria1 directory authority

• Blocking of consensus document requests to the maatuska directory authority

• Blocking of consensus document requests to the tor26 directory authority

• Blocking of consensus document requests to the dizum directory authority

• Blocking of consensus document requests to the gabelmoo directory authority

• Blocking of consensus document requests to the dannenberg directory authority

• Blocking of consensus document requests to the Faravahar directory authority

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. 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. 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:

• Egypt vs DigitalOcean (download ipynb notebook)

• Egypt serving malware (download ipynb notebook)