iran

February 2012 Progress Report

Our progress report for February 2012 is now available. It hightlights recent work with deep packet inspection and censorship circumvention in Iran and Kazakhstan. Also progress on a new tor status site based on new protocols, and general outreach and travels.

We implemented a new format this month to better reflect everything going on within Tor.

Available as a pdf with full color graphs, https://archive.torproject.org/monthly-report-archive/2012-February-Mont...

or as a plain text file for portability and readability, https://archive.torproject.org/monthly-report-archive/2012-February-Mont...

Activists in Iran and Syria targeted with malicious computer software

In February 2012 we learned that activists in Iran and Syria were targeted with two different types of malicious computer software. We received a copy of each malware, and Jonathan Tomek from ThreatGRID helped with the analysis.

How you get infected

The malicious software is spread as email attachments, and as files sent via Instant Messaging and Skype. The software looks like two completely harmless files; a Microsoft PowerPoint slide show and an image file. The malicious software will silently install itself on your computer when you open one of the files.

Malicious software, such as the two copies we analyzed, is normally designed to gather sensitive information and gain unauthorized access to a computer system. The seemingly harmless PowerPoint slide show turned out to be a keylogger, while the image file was really a backdoor, providing the attacker with full access to the system.

Both the keylogger and the backdoor will transfer data to www(dot)meroo(dot)no-ip(dot)org, on port 778. This domain name used to point to a server at a government-owned telecommunications company in Syria, but was later updated to point to a Linode server in London, UK. No-IP have since pointed the domain name to an invalid IP address (0.0.0.0).

Most anti-virus software will be able to detect and remove both the keylogger and the backdoor. You may try updating your anti-virus software, running it, and using it to remove the malware if anything pops up. However, the safest course of action is to re-install the operating system on your computer.

The EFF wrote a blog post called How to Find and Protect Yourself Against the Pro-Syrian-Government Malware on Your Computer. In the post, they recommend "that you take steps to protect yourself from being infected by not running any software received through e-mail, not installing software at all except over HTTPS, and not installing software from unfamiliar sources even if recommended by a pop-up ad or a casual recommendation from a friend.".

PowerPoint slide show: keylogger

When you first try to open the PowerPoint slide show, you will get a security warning asking if you really want to allow this file to run. The Name field points to the following executable file: C:\Program Files\Common Files\VMConvert32\wmccds.exe

If you ignore the warning and click Run, a self-extracting rar file will install the malware (the wmccds executable) onto your computer. The PowerPoint slide show will then open and you will see a series of images and some text in Farsi. The malware will not activate until you reboot your computer.

The first time you reboot, the malware will activate and start logging your keystrokes. If you are running Windows 7, you will see the same warning as mentioned above, and you have to click Run before the malware is actually activated. Older versions of Windows will not display this warning when you reboot.

The malware will modify the Windows startup script to ensure that the keylogger is always running when you are using the computer. The keylogger will affect your whole system, and it will even send the contents of your clipboard to the attacker. The Tor Browser Bundle does not protect you if you have a keylogger on your system.

Windows screen saver: backdoor

The Windows screen saver contains a type of malware that is a bit more complex than the one described above. When you run the Windows screen saver, it will start an image program and show you a picture (we saw a picture of a rifle, but that is not always the case). Meanwhile, the malicious software installs a backdoor onto your computer and opens a connection to www(dot)meroo(dot)no-ip(dot)org, using port 778.

The backdoor (1122333.exe in the Documents and Settings folder), which is similar to the DarkComet Remote Administration Tool, allows the attacker to connect to your computer and do anything that he or she wants, including logging keystrokes and acting as the system administrator. The malware will modify the Windows startup script to ensure that the connection is always open.

Obfsproxy: the next step in the censorship arms race

On Feb 9, Iran started to filter SSL connections on much of their network. Since the Tor protocol uses SSL, that means Tor stopped working too — even Tor with bridges, since bridges use SSL too.

We've been quietly developing Obfsproxy, a new tool to make it easier to change how Tor traffic looks on the network. In late 2011 Iran moved into the #2 position in global Tor user count, and several important political events are scheduled in Iran this month and next. This situation seemed like a good time to test our new tool while also helping improve Internet freedom around the world.

We started with a "Tor Obfsproxy Browser Bundle" with two test obfsproxy bridges in it, to verify that it worked in-country. Then we got over 300 volunteers running more obfsproxy bridges (even with our complex build instructions!), and picked fourteen fast stable trustworthy obfsproxy bridges for an updated bundle which we put out the morning of Feb 11. We spent the weekend fixing usability, stability, and scalability bugs, and put out another bundle on Feb 13 with new versions of Vidalia, Tor, and Obfsproxy.

Thousands of people in Iran successfully used the Obfsproxy Bundle over the weekend:

Obfsproxy users in Iran

We did some spot-checking and it seems that the new addresses on Feb 14 are mostly different from the new addresses on Feb 13; but I would guess these are mostly returning users with dynamic IP addresses, rather than actually fresh users. More importantly, these people will be thinking about Obfsproxy next time the filter cracks down — and based on current events, that next time won't be far off. Finally, even though it looks like SSL and Tor are back, I expect Iran will keep throttling SSL traffic as they've been doing for months, so the Obfsproxy bundle will still be more fun to use in Iran than the normal Tor bundles.

How does it work?

Deep Packet Inspection (DPI) algorithms classify Internet traffic by protocol. That is, they look at a given traffic flow and decide whether it's http, ssl, bittorrent, vpn, etc. Governments like Iran, China, and Syria increasingly use these tools (and they often purchase them from Western corporations, but that's a different story) to implement their country-wide censorship, either by looking for a given protocol and outright blocking it, or by more subtle mechanisms like squeezing down the bandwidth available to a given protocol to discourage its use.

Obfsproxy's role is to make it easy for Tor's traffic flows to look like whatever we like. This way Tor can focus on security and anonymity, and Obfsproxy can focus on appearance. The first thing we decided to try looking like was nothing at all: the "obfs2" module adds an encryption wrapper around Tor's traffic, using a handshake that has no recognizable byte patterns.

It won't work perfectly. For example, the traffic flows will still have recognizable timing, volume, and packet size characteristics; a good entropy test would show that the handshake looks way more random than most handshakes; and the censors could always press the "only allow protocols my DPI box recognizes" panic button. Each step in this arms race aims to force the censor to a) put more development time and DPI resources into examining flows, and b) risk more false positives, that is, risk blocking innocent users that they didn't realize they'd be blocking.

This particular new obfuscating layer isn't the most important feature of Obfsproxy. The best part is that makes it easy to design, deploy, and test other obfuscating layers without messing with the rest of Tor. There's a lot of research into trying to make traffic flows look like other protocols, so for example we could rewrite the Tor flows as valid http that the DPI engine considers harmless. That problem is harder than it sounds — and it sounds hard. But by making a separate component that only has to worry about how the traffic looks, other researchers can try out different strategies without needing to learn so much about the rest of Tor. This approach will also let us easily plug in other transports like Telex, and it will also let other circumvention projects reuse Obfsproxy so they don't have to reinvent our wheels.

Moving forward

One of the choices we faced was how widely and loudly to mention the bundle. While we think it would be hard and/or risky for attackers to block the Obfsproxy protocol, the bundle included 14 preconfigured bridge addresses, and censors could just plug those addresses into their blacklists. We started the weekend telling people to only tell their close friends, but on Sunday we opted for a broader publicity push inside the activist community for two reasons. First, the new Vidalia release (0.2.17) lets users configure their own obfsproxy bridge addresses, so if the preconfigured addresses get blocked the user can just put in new ones. Second, it became clearer that the blocking would let up in a few days once the immediate political pressure was over, and we decided it was more important to get the word out about Obfsproxy in general so these users will know about it next time.

I should point out that I don't think they were targeting Tor here. They were targeting popular websites that use SSL, like Gmail and Facebook. Tor was collateral damage because we opted to make Tor traffic look like SSL. That said, we should not forget that we are on their radar: they targeted Tor by DPI in September 2011, and the Diginotar breakin obtained a fake SSL cert for torproject.org.

The next choice we face is: what other communities should we tell? The bundle works great in China too, where their aggressive censorship has been a real hassle for us the past year or so. Some other countries in Asia appear to be newly using DPI to recognize Tor traffic (more on that in an upcoming blog post). We have more development work to do before we can keep up with the China arms race, including teaching obfsproxy bridges to automatically report their addresses to us and teaching our bridgedb service to give them out, and we need to answer research questions around getting more bridges, giving them out in smarter ways, learning when they get blocked, and making it hard for censors to find them. We also need to spread the word carefully, since the arms race is as much about not drawing the attention of the censors as it is about the technology. But the Obfsproxy Bundle works out of the box right now in every censoring country we know of, so we shouldn't be too quiet about it.

And finally, thanks go to George Kadianakis for taking Obfsproxy on as his Google Summer of Code 2011 Project; to Nick Mathewson for mentoring him and getting the Obfsproxy architecture going in the right direction; to Sebastian Hahn for spending all weekend with me fixing bugs and making packages; and to Karsten Loesing, Erinn Clark, Robert Ransom, Runa Sandvik, Nick, George, and the broader Tor community for stepping up over the weekend to help us take it from "early prototype" to "deployed software in use by 5000+ people" in 72 hours.

September 2011 Progress Report

In September 2011 we made progress in a number of areas, such as handling issues in Iran's use of DPI to block tor, new versions of Tor, Tails 0.8 release, and more.

The PDF and plaintext versions of the report can be found attached to this blog post or at our monthly report archive:

https://archive.torproject.org/monthly-report-archive/2011-September-Mon...

and

https://archive.torproject.org/monthly-report-archive/2011-September-Mon...

Iran blocks Tor; Tor releases same-day fix

The short version: Tor relays and bridges should upgrade to Tor 0.2.2.33 or Tor 0.2.3.4-alpha so users in Iran can reach them again.

Yesterday morning (in our timezones — that evening, in Iran), Iran added a filter rule to their border routers that recognized Tor traffic and blocked it. Thanks to help from a variety of friends around the world, we quickly discovered how they were blocking it and released a new version of Tor that isn't blocked. Fortunately, the fix is on the relay side: that means once enough relays and bridges upgrade, the many tens of thousands of Tor users in Iran will resume being able to reach the Tor network, without needing to change their software.

How did the filter work technically? Tor tries to make its traffic look like a web browser talking to an https web server, but if you look carefully enough you can tell some differences. In this case, the characteristic of Tor's SSL handshake they looked at was the expiry time for our SSL session certificates: we rotate the session certificates every two hours, whereas normal SSL certificates you get from a certificate authority typically last a year or more. The fix was to simply write a larger expiration time on the certificates, so our certs have more plausible expiry times.

There are plenty of interesting discussion points from the research angle around how this arms race should be played. We're working on medium term and longer term solutions, but in the short term, there are other ways to filter Tor traffic like the one Iran used. Should we fix them all preemptively, meaning the next time they block us it will be through some more complex mechanism that's harder to figure out? Or should we leave things as they are, knowing there will be more blocking events but also knowing that we can solve them easily? Given that their last blocking attempt was in January 2011, I think it's smartest to collect some more data points first.

It's too early to have cool graphs showing a drop in users and then the users coming back a day or so later. I'll plan to add these graphs once things play out more. [Update: here is the graph as of Sept 16]

Update on Internet censorship in Iran

Here's a quick update on what we're seeing from Tor clients in Iran. This is an update to https://blog.torproject.org/blog/new-blocking-activity-iran. It appears that one of the five Iranian ISPs is experimenting in blocking censorship circumvention tools; such as Tor, Freegate, Ultrasurf, and Hot Spot Shield. There have been reports that this update to censorship technologies was coming soon, https://www.azadcyber.info/articles/1560.

Previously, we had data suggesting that ssl-connections were being throttled or experiencing a forced reduced-throughput. It seems this is no longer the case. A simple IP address access list is used to stop access to the public Tor nodes, as well as many Tor bridges. An example of this blocklist on the Iranian Tor users:

and

We are seeing success in users choosing to configure their Tor clients to use a socks or https proxy and then connecting to the public Tor network. The trick here is that Iranian tor users now look to be coming from wherever the open proxy is located. A few volunteers in Europe and SE Asia have setup proxy servers restricted to Iranian IP space.

On a more technical level, here's what we were seeing last week for ssl manipulation, https://blog.torproject.org/files/https-traffic-flow.txt. What's interesting is the tor-server to client communication is with a TTL of 40. The TLSv1 Encrypted Alert is from the tor-server, except the TTL is 39. Unless the tor-server suddenly jumped one hop further from the client, something intercepted the connection and injected that packet on behalf of the tor-server.

This week we're seeing straight IP blocking after the ssl handshake starts, https://blog.torproject.org/files/ip-blocking.txt. In both cases, this is to the same tor bridge from the same tor client as before.

In a short few months, Iran has vastly improved the sophistication of their censorship technologies. Right now, the best option is to use tor through open socks/https proxies. A risk is the open proxies can see you are using tor, but cannot see the traffic passing through the open proxy, for everything is wrapped in layers of encryption by Tor. However, it appears the Iranian Potato Wall can detect Tor or not in any case by analyzing the traffic on the wire. We have reports this is true for other circumvention tools as well.

I thank the many people that have taken risks to share data with us.

New Blocking Activity from Iran

Over the past 48 hours it seems the Great Persian Firewall is updating to attempt to block a number of circumvention tools, including Tor. Iranians and their diaspora have been reporting to us that Tor, Hot Spot Shield, UltraSurf, and Freegate are all experiencing connectivity problems from inside Iran to the outside world.

Our research indicates that ssl-based communications are being throttled to 2 kilobit per second rates or simply blocked altogether. This is inclusive of basic ssh, ssl, vpns, and other proxy technologies. We're continuing to work on what's really happening and likely means to counter. The short answer is to use bridges that are not on port 443.

Some graphs to show the results on Tor from our Tor metrics portal.

Bridge users from Iran:

read more »

September 2009 Progress Report

Here's what the Tor Project accomplished in September 2009.

New Hires read more »

  • Carolyn Anhalt is our new Translation and Community Manager. Carolyn has years of experience managing and growing content translation, as well as wrangling online communities and developing volunteer moderators and support roles from the community. She’s fluent or conversant in a number of languages, such as: Russian, French, English, German, Italian, and Welsh. Carolyn’s initial goals are to grow the translator community to keep everything Tor translated, work out better translation tools for translators, and to generally assist translators.
  • Karen Reilly joins us as our Development Director. Karen has years of experience in growing both community-based and foundation-based funding, as well as helping to fulfill the mission of organizations through outreach and community-building. Karen’s initial goals are to further develop community funding, work with our current donors, help create an annual report, and expand Tor’s outreach efforts.

CIMA/NED Panel on Iran and New Media

I was invited to join a panel discussion on Iran and New Media hosted by the Center for International Media Assistance and the National Endowment for Democracy. The full 90 minute video is now online; as is my presentation.

The general overview of the panel is http://cima.ned.org/events/new-media-in-iran.html

The direct link to the video on Vimeo is http://www.vimeo.com/5496977

A number of press people talked to me afterwards, including Al-Jazeera. There were reporters from Xinhua and China Daily in the audience as well. These reporters paid close attention to anything I said about China.

I spoke about what I knew and generally tried to avoid starting international incidents. A few of my answers to questions rambled a bit.

All in all it was a great panel and I learned more about what goes on inside Iran from the different panelists.

Measuring Tor and Iran (Part two)

Two weeks ago we posted early measurements about the growth of Tor usage in Iran. Since then we have improved our math, and used more data sources. This work is part of our metrics project, where we're learning about the Tor network to improve its availability and performance while keeping our users safe. read more »

Syndicate content Syndicate content