Hidden Services, Current Events, and Freedom Hosting

Around midnight on August 4th we were notified by a few people that a large number of hidden service addresses have disappeared from the Tor Network. There are a variety of rumors about a hosting company for hidden services: that it is suddenly offline, has been breached, or attackers have placed a javascript exploit on their web site.
A Hidden service is a server – often delivering web pages – that is reachable only through the Tor network. While most people know that the Tor network with its thousands of volunteer-run nodes provides anonymity for users who don´t want to be tracked and identified on the internet, the lesser-known hidden service feature of Tor provides anonymity also for the server operator.
Anyone can run hidden services, and many do. We use them internally at The Tor Project to offer our developers anonymous access to services such as SSH, IRC, HTTP, and our bug tracker. Other organizations run hidden services to protect dissidents, activists, and protect the anonymity of users trying to find help for suicide prevention, domestic violence, and abuse-recovery. Whistleblowers and journalists use hidden services to exchange information in a secure and anonymous way and publish critical information in a way that is not easily traced back to them. The New Yorker's Strongbox is one public example.
Hidden service addresses, aka the dot onion domain, are cryptographically and automatically generated by the tor software. They look like this http://idnxcnkne4qt76tg.onion/, which is our torproject.org website as a hidden service.
There is no central repository nor registry of addresses. The dot onion address is both the name and routing address for the services hosted at the dot onion. The Tor network uses the .onion-address to direct requests to the hidden server and route back the data from the hidden server to the anonymous user. The design of the Tor network ensures that the user can not know where the server is located and the server can not find out the IP-address of the user, except by intentional malicious means like hidden tracking code embedded in the web pages delivered by the server. Additionally, the design of the Tor network, which is run by thousands of volunteers, ensures that it is impossible to censor or block certain .onion-addresses.
The person, or persons, who run Freedom Hosting are in no way affiliated or connected to The Tor Project, Inc., the organization coordinating the development of the Tor software and research. In the past, adversarial organizations have skipped trying to break Tor hidden services and instead attacked the software running at the server behind the dot onion address. Exploits for PHP, Apache, MySQL, and other software are far more common than exploits for Tor. The current news indicates that someone has exploited the software behind Freedom Hosting. From what is known so far, the breach was used to configure the server in a way that it injects some sort of javascript exploit in the web pages delivered to users. This exploit is used to load a malware payload to infect user's computers. The malware payload could be trying to exploit potential bugs in Firefox 17 ESR, on which our Tor Browser is based. We're investigating these bugs and will fix
them if we can.
As for now, one of multiple hidden service hosting companies appears to be down. There are lots of rumors and speculation as to what's happened. We're reading the same news and threads you are and don't have any insider information. We'll keep you updated as details become available.

EDIT: See our next blog post for more details about the attack.

I don't know how TOR would have been 'circumvented entirely' by this, when Firefox disallows connections except to the proxy being used.

Nah.... something doesn't sound right about your explanation.

Some of these javascript functions I have been reading about are a bad idea to have in the first place, so maybe this will start a discussion about paring down on/removing some javascript calls.

With an exploit like that, they can execute arbitrary code so what Firefox allows or disallows isn't important. Once an attacker can execute arbitrary code on your system, you have to assume your identity and system have been compromised.

I'm not sure what removing certain javascript calls would accomplice. You should disable Javascript anyway when using Tor.

1) TOR has NOT been attacked.

2) The attack was directed against the Windows version of Firefox v17 (version 17.0.7 excluded). It seems that versions: 18,19,20,21 were (and still are) vulnerable but have not been attacked.

3) The attack can only be successful if JavaScript is enabled, i.e.: not blocked by noscript or not turned off within the Firefox settings.

3) The attack is immediately effective, i.e. you IP is submitted by the shell code by the use of Windows-API which does not use the TOR sockets proxy. Again you ip is send in the very moment in which the exploit is successful. There is no need to wait for you until you visit the clearnet.

4) Linux, Android, MacOS, ... seem to have not been affected so far.

Is this proven? If we are running any OS other then Windows we are fine? I am running Linux should i format, and start over?

No, the attack wasn't against the client browsers, it was against the hidden servers, which has to have the javascript exploit planted on them first.

Why all the focus on the attack on the client browser, when it was the hidden servers that had to be unhidden, identified, and compromised first?

The attack on the browser is secondary.

If the servers had not been identified and compromised, we wouldn't even be having this discussion, so lets focus there.


August 04, 2013


I think the code was or is broken, they also modified the injected code a couple of times. It changed from a cleannet IP to an onion address and back again, after that they obfuscated the code and encoded the URL.

The code can be found here: http://pastebin.mozilla.org/2777139

That code is strange because it only runs if the userAgent browser version is between 17 and 18. The current Tor Browser comes up as 10.0, even though the blog post says it's based on Firefox 17 ESR. I think if you're using Tor Browser the malicious code will think it's version 10 and load "content_1.html" which is not shown.

Mine shows up as "Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0" and the code returns 17 not 10.


August 04, 2013

In reply to by Anonymous (not verified)


Are you running the 3.0 alpha of Tor Browser? What version comes up for you in help/about tor browser?

Mine shows "Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17" and I am running current stable release, which by the way have been based on ESR17 for a while.

False. This exploit in particular sniffs for Firefox-specific features.

function isFF() {
return (document.getBoxObjectFor != null || window.mozInnerScreenX != null || /Firefox/i.test(navigator.userAgent));

Unless, of course, your UA switcher also disables document.getBoxObjectFor and window.mozInnerScreenX, which most don't. Not sure why they check for multiple signs of Firefox, when just checking for window.mozInnerScreenX would do.

I use Proxomitron, which can both spoof the UA, and filter arbitrary bits of javascript, or turn it off entirely. Gutting javascript isn't however as secure as turning it off entirely.

That looks like it targets the Tor Browser 3.0 alpha build (which is based on Firefox 17 ESR). The latest Tor Browser identifies as version 10 in which case it loads "content_1.html" that is not shown in your link.

Same version which JonDoFox uses - no surprise here.
The exploit seems to work on Windows only and may be limited to FF v17 because of a JS update on new Firefox versions or because the FF codebase changed to much. The exploitation of payload delivery by heapspraying is relatively strong bound to the targeted executable so again no surprise here.

A few sites were warning about the bad script in TORmail. Also, not the dude you're responding to, though I'm interested in hearing their response as well.


August 04, 2013


The fallout from the captured data should be entertaining, depending on your point of view. The plain text data and relationships found in tormail will generate a huge number of links to real people.

If you consider hundreds of destroyed lives to be entertainment, then yes.

I truely hope a number of non pedos are caught up by this, perhaps those people will have hated pedos too, but will now get to feel what it's like to be one. Perhaps they'll also realise why its never a good idea to support the persecution of minorities. One day, they might just come knocking on your door.

Freedom took a great blow today, in the name of *saving the children*, the battlecry of oppressive governments for a long time. You will not rid the world of people you hate, by ostracising them and destroying small numbers of them. If you bought the line that this has anything to do with hunting pedos, I feel sorry for your misunderstanding of their push to control all information, using this as their get out clause.

I suggest you look up Rick Falkvinges excellent piece on why possession/distribution of CP should be decriminalised (not production mind you). http://falkvinge.net/2012/09/11/child-porn-laws-arent-as-bad-as-you-thi…

This attack has helped no one, harmed many, and damaged one of the last areas people can be free from government control. Having known one person destroyed by laws like these, I can tell you it doesn't just harm the convicted, but their families and friends too. It creates homeless, jobless and hopeless people, new burdens on the state where once productive individuals existed. In the worst cases, it creates corpses, suicide is a common outcome from CP raids, usually because the people caught were perfectly decent, honest and hardworking individuals, now faced with no future and no hope, essentially a social death penalty.

So by all means, continue to support the criminalisation of possession, watch as your freedoms are eroded away with that as the excuse, watch as people you know and love are destroyed by the laws you support and finally, watch as censorship becomes the default stance of the web, as is happening in some EU locations right now. But at least it was entertaining to watch, right?


August 04, 2013


I tested the shellcode in an isolated VM and faked the connect() call to succeed. But it crashes after gethostbyname. Did someone examine this any further? To which IP is the UUID forwarded?

Was your VM on linux ? A lot of people are saying it's only windows based, but on my ubuntu machine the user agent and version matched to run the exploit.

It maybe passed the server-side injected script, but the iframe script it loads specifically checks your useragent for "Windows NT" so I doubt it ran.

Can someone varify this? I am using an ubuntu machine and used TBB to just access TorMail and was instead given a pink background with a table and it showed me the exclamation mark, and seemed like something was wrong. I dont do anything wrong on tormail so i tried to access tormail through the onionsite.onion.to (that web2tor site- obviously i would never unless its to check if tormail is down) on google chrome and got the site is down message...Do you think I should format, using a linux machine?

I'm sure the parameters are filled in elsewhere, which could be why it's crashing. Did you run all of the script or just the code in variable magneto? Because magneto is appended to a bunch of other random hex strings, then copied into the big array view[] and then various globals are copied into various offsets in view[].

I only ran magneto and stepped through with OllyDbg in a VM.
I actually came across the IP, i just forgot to cast to sockaddr_in of the connect() call. The IP is: and they used the port 5000. It makes 5 tries to connect.
Then it gets the hostname with gethostname().
Then it gets all the local IPs and associated hostnames with gethostbyname.
Since i have no network adapter, i dont know how all this info was used in the following.
Then it cooks cooks up a HTTP GET String with the UUID provided by the javascript as parameter and it appends the local hostname in the Host: field.
Then it tries to get the MAC-Adress with SendARP() and puts it in a cookie field named "ID", which i faked the return to confirm.
Then it sends everything away with send().
And after that it even does a closesocket(). After that it probably tries to gracefully exit the shellcode somehow without crashing the target, i can't really tell.
Maybe i'll try to examine this in a real exploiting situation with all the javascript stuff and the vulnerable tor browser.

Really good info, I think you're on to something. That IP is one digit off from an earlier version of the server-side javascript that opened an iframe and sent the UUID to Both the IP's belong to a Verizon business account in the western Washington D.C. suburbs. Where both FBI and CIA headquarters are located.

Are you sure it's port 5000? I looked at the same block of code earlier and vaguely remember it being 0x00 0x50, i.e. port 80 in network byte order.


August 04, 2013


I don't understand WHY in the world the default setting on the TOR bundle is to "Allow global scripts". Since JavaScript is the most common mechanism for privacy-busting exploits, it should be disabled by default, don't you think?

"Since JavaScript is the most common mechanism for privacy-busting exploits"


"it should be disabled by default, don't you think?"

No, it doesn't follow.

You might as well say that a web browser is the "most common mechanism for privacy-busting exploits" so you should not use one.

You have to consider what you lose by disabling JS. And you lose a lot.


August 04, 2013


That code is strange because it only runs if the userAgent version is between 17 and 18. The current Tor Browser comes up as 10.0 in the user agent, even though the blog post says it's based on 17 ESR. I think if you're using Tor Browser the malicious code will think it's version 10 and load "content_1.html" which is not shown.

The current TorBrowserBundle comes up as 17.0 in the user agent.

> Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0

Tested with "tor-browser-gnu-linux-...-2.3.25-10-dev.tar.gz"


August 04, 2013


Before FH went down i was already wondering what the future of Tor is after the Snowden revelations. How secure is the Tor network if the USA en UK are buffering the whole internet transit for days and can inspect traffic passing between nodes, shouldn't the project avoid relays and nodes in those countries? Can the nodes be changed to insert random traffic to make it mode difficult to snoopers? And now that FH went down it is important to understand what happened, even if FH has been hacked the admin could take it down but hasn't. There is speculation that the admin has been arrested, if it is true it would be even more important to understand what happened and how. I'm surprides that there hasn't been any statements from the Tor Project about all the illegal snooping that USA and UK are doing and how it affects the project and if there are any risks.

Doesn't seem Tor Project has been taking things all that seriously. Not even since Snowden, and now this. We need a whole new international project run by some people much more serious about privacy and internet freedom. Tor is dead! Now let's replace it with something better!

There is nobody on the planet better at what they do, then the people behind the Tor project. If you want better tools, stop fucking crying and start do peer review & develop or stfu.

It is you, who piss on his own privacy for so long, not Tor project.

"How secure is the Tor network if the USA en UK are buffering the whole internet transit for days and can inspect traffic passing between nodes, shouldn't the project avoid relays and nodes in those countries?"

They aren't buffering traffic "for days," if they were TCP connections would never complete. They'd time out all the time.

"...shouldn't the project avoid relays and nodes in those countries?"

Several of the Snowden docs have evidence that the NSA is sharing COMINT with the intelligence agencies of other countries in an agreement of reciprocity. On the chance that the NSA missed some traffic, a friendly intel agency may have grabbed it instead and given it to them. So, this wouldn't help.

"Can the nodes be changed to insert random traffic to make it mode difficult to snoopers?"

That is in the Tor FAQ.

I can't help but wonder if this is part of an effort to dissuade people using Tor and other such services by a) inducing learned helplessness and b) mistrust of any and all providers of such services because most people don't seem to understand that there is no such thing as perfect security.

> They aren't buffering traffic "for days,"

Actually he certainly means:
they are keeping a copy of the whole traffic for a few days


August 04, 2013


If wonder if the exploit got around the bundled NoScript Add-on if it's set up properly? If so, how?

Also, what happened to the Tor button I used to see near the top-left of the browser? That's been gone from the Tor firefox browser since 2.3.25-10.

No, it doesn't. I modified the Java Script that tries to load that site into the IFrame by replacing the original address by one of my own server. Then I watched tail -f -n 10 /var/log/apache2/access.log.
When Java Script was enabled in NoScript, a GET request showed up. When I deactivated Java Script in NoScript, it didn't. And yes. I emptied the cache and even restarted TBB so it wouldn't load from cache.


August 04, 2013


So what do you guys have to say about having NoScript allow all Scripts globally in the default settings? Isn't now the time to see and accept that this was a really really stupid decision on your side?
A lot of users trust you and think JS is deactivated by default while you ignore that fact and betray them.

Same here, I guess I looked for it briefly to deactivate it the first time but didn't see it since I'm not used to the setting, and thought it wouldn't matter or forgot about it later.

You could set up NoScript to have JS disabled by default. Then when visiting a Website with Java Script for the first time, let a message pop up informing the user and then ask what to do. Keep JS disabled for better anonymity or enable JS for the price of anonymity.
But as it is now, it is utterly dangerous. I'm quite tech savvy, but even I forgot to disable JS in NoScript for one or two days after I updated my TBB every now and then. Now imagine Average Joe who doesn't even know the difference between Java and JS, stumbling over all sorts of sites in the world, assuming that he'll be safe because he thought the Tor Project guys knew best what's the safest possible config.

Perhaps it would be more secure, but it wold be bad for the user's anonymity because after a few days of browsing with TBB and making exceptions in NoScript, people would have a very distinct whitelists which an exit node could use to fingerprint every user. Besides, I'm sure that people accessing FH (for example, but it would be the same for any site) would have JavaScript whitelisted for that site and the exploit would have succeeded anyway.

Only if the whitelists were sent to the websites AND the cookies and other things were allowed to stay between 'visits'.

Which, in the default setup of TBB, it's in private mode, which clears all that stuff between closings and openings of the browser.

Private mode would not prevent exit nodes and web site admins, for example, from being able to observe distinct patterns with regard to which sites were allowed to execute scripts and which were not.

Cookies and cache are all but irrelevant here.