Bluecoat's role in Syrian censorship and nationwide monitoring system #OpSyria
This second translated article is intended to update an international audience about the current situation concerning the OpSyria operation (you can read the first article here). All contents on this website are released under a Creative Commons By licence, you are free to reproduce, republish and broadcast this content as long as you provide a link to the original.
This second translated article is intended to update an international audience about the current situation concerning the OpSyria operation (you can read the first article here). All contents on this website are released under a Creative Commons By licence, you are free to reproduce, republish and broadcast this content as long as you provide a link to the original.
_____
We have already talked about Bluecoat, a company from a country that allegedly sets other countries free by bombing their populations, under the pretense that these countries own - imaginary, of course - weapons of mass destruction... yes, we are talking about the USA.
Just like France, Mickey Mouse's native country is really up to date on Internet filtering technologies. But, as these technologies are prohibited in almost every democratic country (in France, the "Code des Postes et Télécommunications" is very strict on this matter) and as companies have to find a way to sell these censorship tools, it is not uncommon that they sell a couple of these to renown dictators... - like this French CEO who, on the 13th of February 2011, was in Tripoli and sold a nation-wide monitoring device to Gaddafi, as well as a NAS large enough to entirely cache Google. [this story was published in Reflet.info in may and made the headlines of the WSJ last monday]
This angers us. And it does even more when a dictator sends his army - that is, snipers and tanks - shooting his own population.
Today, thanks to our friends from Telecomix and to the support of other hacktivists more or less affiliated with Anonymous, we are able to release new elements on BlueCoat's implication in the setting up of Syrian censorship and repression. We've studied how Syrian censorship works more closely. We suspect they use two different technologies. The first one is rather simple and reasonably efficient (but can also be easily bypassed): a filtering proxy.
Wev'e talked about the second one on Reflets.info on several occasions; it's Deep Packet Inspection (DPI), which is much more vicious than the latter. DPI enables a user to monitor internet traffic and then decide on a routing policy, in order to either intercept or block communications. DPI is not only a French specialty; the US plays an equally important role. This is, notably, explained by the fact that the market for this technology seemed particularly promising before the Arab spring... Although now it seems to be less so, as it becomes more likely that Internet filtering-related trade agreements will come to the public's knowledge.
Our friends from BlueCoat, whom we honour today, have a large number of tools dedicated to Internet censorship. These are always presented as benevolent tools which supposedly protect our kids from "PedoNazis" on the Web, or protect your Windows OS against viruses. Incidentally, in some dictatorships, DPI can also be used to eradicate any kind of opposition or to control the information flow at a very large scale... of course, this purpose is not described in marketing brochures... though it can be found in some "confidential" white papers, like the one released by Qosmos, which details the benefits of nation-wide DPI.
Some tests were directly performed from Syria, which allowed us to highlight the use of filtering proxies, as well as the possible use of Deep Packet Inspection tools by the Syrian government, by means of American technologies created by Bluecoat. We present here the tests that have been carried out. We will try to give you the main results by describing the procedure we have followed and by detailing what we observed.
Let us consider a server that we will denote "S", located in a "democratic enough" country, so that all the queries - whether TCP or UDP, and whatever their content may be - reach this machine without being altered (on the "democratic country" side, at least).
Consider also two home computers located inside the Syrian territory, connected through a standard ADSL connection and using two different ISPs:
- A computer denoted "A", connected through the main Syrian provider, Tarassul, whose entire traffic is redirected through the national ISP (from whom it depends) gateways, known as the Syrian Telecommunications Establishment (STE), directly controlled by the government - IP range 31.9.*.*.
- A computer denoted "B", using the Syrian Computer Society (SCS) provider, a public institution headed by President Bachar el-Assad (source) - IP range 77.44.*.*.
We first performed TCP connection tests from "A" to "S". Here is a summary of the results:
- Connection to the TCP port 5060 (used by the SIP protocol - we had originally planned to test secure VoIP solutions): the port is blocked (timeout on the client side and absolutely no request reaches the server)
- Connection to the TCP port 443 (as everybody knows, usually used for secure HTTP traffic) : "S" can see the connection from "A"'s IP coming in and the traffic seems to work in both directions without any problem.
- The case of port 80 is certainly the most interesting one. First, we tried to establish a basic TCP connection using Telnet and sending random data: "S" did not receive any connection query, yet, as for client "A", the connection seemed open but nothing happened, as if all data had been sent nowhere. Then we tried to use port 80 in the traditional way, i.e. using a web browser performing a standard HTTP query on the computer "A". Result: the server "S" received a connection attempt, but not from "A". It came from another IP address which was not even in the same range: 82.137.200.56. A quick search showed that this IP address belongs to... the Syrian Telecommunications Establishment... Moreover, some lines from the request received by "S" particularly drew our attention:
X-Forwarded-For: 31.9.... (IP de "A") X-BlueCoat-Via: 2C044BEC00210EB6
Well, it speaks for itself. The query was redirected through a BlueCoat equipment, which then forwarded it back to the server. And "A" did not have a chance to know it. Nothing else to say. Excepted, maybe, as bonus information, that the equipment was a BlueCoat Proxy SG-9000.
![](/system/images/attachments/07c217a0-0d8e-4a09-8911-e7d406baa006/small.jpg?1518649075#center)
What about the Syrian Computer Society? Here are the results of the tests performed from computer "B" towards "S", again:
- We once again tried to connect to ports 5060 and 5061 (the latter being usually dedicated to secure SIP): same result as for "A".
- Port 443: just like with "A", the traffic seemed to be unaltered in both directions, and the server received a connection from "B"'s IP address. Same observation for other traditional ports such as 6667 or 6669.
- Once again, the case of port 80 is the most interesting one. The first test was the same: connection from "B" to "S" and sending random data using Telnet. Result: an HTML error page stating "Bad Request" is received by "B", and absolutely no request reaches "S". The second test was also the same one: a plain HTTP request with a common browser. It leads to a similar result: "S" receives a connection request, not from "B"'s IP address but from 213.178.244.16 instead, which is not in the same range as "B"'s but is also owned by SCS. In this case too, two lines of the HTTP request seen by the server stand out:
X-Forwarded-For: 77.44.... (IP of "B") X-BlueCoat-Via: E4007B080BF520E6
Well, this time, we can say we were half-expecting it. As in the previous case, from the client's point of view, nothing indicates that our request had been redirected to a proxy. There is a slight difference, however, since the model is a BlueCoat SG-400. In addition, we have run a third test that consisted in performing an HTTP request for the page "/proxy.html" from "B", still to "S". Result: nothing received by "S", and "B" displayed a fancy HTML page explaining that the requested page was unavailable. Of course, we had not chosen the word "proxy" randomly... Therefore, the result was not so surprising, but it confirmed that some URLs were filtered.
![](/system/images/attachments/756707f0-d59b-4f04-a857-6e0cb854a3bd/small.jpg?1518649074#center)
Let us draw some conclusions from these experiments. Concerning blocking and observation policies, it is clear that the Syrian government understands that a very large majority of the Internet traffic happens on the WWW, i.e. through port 80. And most Syrians do not have the habit to use HTTPS (port 443). Most websites do not even provide a secure access. This is thus a simple and efficient way to sniff thousands of logins and passwords and to dig through webmail ad libitum. We also observed that port 5060, normally used for VoIP via the SIP protocol, is blocked.
We also know that Skype is widely used in Syria. Does the government have an interest in letting people continue to use Skype by impeding them to use better secure alternatives? The selective blocking of ports 5060 and 5061 makes this perspective possible, and we may also wonder if there is some kind of cooperation between Skype and the Syrian governement, with an aim to collect users' personal data.
However, these selective blockings could also be the result of the "default" configuration of equipment installed by the authorities. This seems also probable considering the wide-open security flaws that we came across, and which might indicate that the team in charge of the equipment installation was either in a hurry or incompetent.
From a more technical perspective, we firstly observed that the traffic routing from ADSL clients was performed depending on the requested TCP port. If the port differs from 80 and is not concerned by a blocking policy, the request goes directly to the server. If the port 80 is requested, it is redirected to a BlueCoat proxy without letting client know it.
Furthermore, the BlueCoat equipment is in charge of parsing the request and forwarding it, under the condition that it does not contain forbidden keywords or does not target a blacklisted website. In any case, the user action is stored in log files (obviously without their knowledge) - we briefly talked about it in a previous article. In a nutshell, the traffic can be monitored and altered at two levels : firstly depending on IP protocol data (requested port number), and then according to HTTP data.
Suspected presence of DPI-capable devices
The very nature of a Deep Packet Inspection equipment does not allow its detection. These equipments, connected to an Ethernet port at the very end of the national network, are not visible from outside. While we can not ascertain these equipments effective presence, we suspect the existence of a mechanism which is able to analyse the traffic on the fly and tag it, in order to apply routing, blocking, archiving rules... All of this being merrily reencapsulated thanks to the magic of the MPLS protocol.
As a simple filtering proxy does not have such superpowers to our knowledge, we could deduce the actual presence of Deep Packet Inspection tools
BlueCoat: liable or guilty ?
At the moment, we have no formal evidence that BlueCoat directly sold these equipments to the Syrian regime. The very nature of this kind of contract reveals the presence of technology integrators. BlueCoat are at the same time manufacturer and integrator, but their technologies are most probably indirectly integrated by some of their clients. However, this kind of contract often includes maintenance and training clauses, which can definitely not be ignored by the firm that provided the equipment.
This is year 2011, states and private companies are here to protect you... feel safe.