The talk given at H2HC 2011 in Sao Paulo has caused a lot of reactions and interests in our work (especially this night from a TOR developper whose mail was far more constructive and positive than previous ones). It is probably time to go ahead the recent stupid buzz and reactions. To put things into perspective, people must know that we did choose to enter this buzz and wait until our talk and that forthcoming in PacSec 2011. We expect to be more constructive in this way.
We perfectly understand the concerns of the TOR community. Be sure that contrary to stupid allegations it is not our intent not to contribute for more security in TOR (but honestly first emails from the TOR foundation were more on strong requirement mode -- not to say intimidation -- than with a real collaboration spirit ensuring the interests of conferences organizers). We are not easy men and we do like everything close to intimidation. And we do not like useless buzz.
People first must know and be convinced that we do not have anything against TOR. This network is just the only real public case on which we can test the concept of dynamic trapdoors and publish something with the expectation to be useful and constructive at the very final end.
As far as vulnerabilities are concerned -- TOR community is concerned with potential bugs --, in fact we cannot speak of sotware vulnerabilities. The TOR code is rather very well and securely written. Our attack relates more to the conceptual designs and of the exploitation of different aspects on which those designs rely on. We worked at a higher level by considering the TOR network as a critical infrastructure and we have developped operational cyberwarfare scenarios (these approaches are part of the research topics our our lab). to take the control over TOR as would do rogue non-democratic countries , terrorists or reduced sized groups of bad guys.
We manage to force 3-node circuits to go through a few nodes -- with very high probability -- we have compromised in an initial step with malware using malicious cryptography techniques installing dynamic cryptographic backdoors. To do that, most of the time we just turn protection mechanisms in place (for instance to prevent large DDoS) back against TOR itself. The TCP reset attack cannot be avoided since it exploit a part of the TCP implementation. Most the techniques we used (local and targeted congestion path, spinning technique ou TCP reset) cannot really be avoided. It is a problem of conceptual design both for TOR but also for the protocols it relies on (mostly TCP). It is a common approach in cyberattacks to turn protections set up by the target... against the target! Awful indeed but really efficient.
So we do not want to criticize TOR uselessly since the problem is not TOR in itself only. This network is a first solution intending to provide some sort of secure environment that must be followed by other generation of OR or other similar solutions. But since we now are very convinced that it is effectively possible to take control over TOR when working both a low and high level at the same time (this is the reason why we needed to have a precise and complete map of all the OR even the hidden ones; and we manage to find all hidden nodes, China or any other bad guys are able to do it as well). Nowadays hacking techniques and methods still have only a limited and reduced view (instance of binaries or of systems) but they did not apply yet what military world is using: large, high level views to organize, plan and conduct coordinated attacks, combining several technical bricks and tools.
So, we are currently preparing all stuff (source code , paper, slides) and as soon as they are ready we will send them to the TOR foundation and make them publicly available. We already made suggestions to a few TOR developpers. Seun is currently working to adapt the attack to the recent update (that corrects partly the spinning technique). He is very confident at succeeding in this.
Seun should prepare a Phd and we intend to provide new approaches to enable and propose some sort of third generation of TOR that would contribute to solve the present conceptual problems. Part of the solution would be to use steganography to provide TRANSEC aspects. But we should also propose to protect the code loaded in memory to limit the techniques of dynamic cryptographic trapdoors. And we have many other ideas coming from malicious cryptography techniques we have recently developped.
Once again, the very final goal of our work is to provide a better solution at the end. That is why we did not want to enter the buzz and stay aside to go on working
We hope that people will understand
To finish I would like to thank people at H2HC (Rodrigo, Filipe and all the very nice guys I have met) as well people from PacSec (Dragos and his team) for their confidence and trust. We owe very much to them
Have a nice (hacking) day to all
E.F.
People first must know and be convinced that we do not have anything against TOR. This network is just the only real public case on which we can test the concept of dynamic trapdoors and publish something with the expectation to be useful and constructive at the very final end.
As far as vulnerabilities are concerned -- TOR community is concerned with potential bugs --, in fact we cannot speak of sotware vulnerabilities. The TOR code is rather very well and securely written. Our attack relates more to the conceptual designs and of the exploitation of different aspects on which those designs rely on. We worked at a higher level by considering the TOR network as a critical infrastructure and we have developped operational cyberwarfare scenarios (these approaches are part of the research topics our our lab). to take the control over TOR as would do rogue non-democratic countries , terrorists or reduced sized groups of bad guys.
We manage to force 3-node circuits to go through a few nodes -- with very high probability -- we have compromised in an initial step with malware using malicious cryptography techniques installing dynamic cryptographic backdoors. To do that, most of the time we just turn protection mechanisms in place (for instance to prevent large DDoS) back against TOR itself. The TCP reset attack cannot be avoided since it exploit a part of the TCP implementation. Most the techniques we used (local and targeted congestion path, spinning technique ou TCP reset) cannot really be avoided. It is a problem of conceptual design both for TOR but also for the protocols it relies on (mostly TCP). It is a common approach in cyberattacks to turn protections set up by the target... against the target! Awful indeed but really efficient.
So we do not want to criticize TOR uselessly since the problem is not TOR in itself only. This network is a first solution intending to provide some sort of secure environment that must be followed by other generation of OR or other similar solutions. But since we now are very convinced that it is effectively possible to take control over TOR when working both a low and high level at the same time (this is the reason why we needed to have a precise and complete map of all the OR even the hidden ones; and we manage to find all hidden nodes, China or any other bad guys are able to do it as well). Nowadays hacking techniques and methods still have only a limited and reduced view (instance of binaries or of systems) but they did not apply yet what military world is using: large, high level views to organize, plan and conduct coordinated attacks, combining several technical bricks and tools.
So, we are currently preparing all stuff (source code , paper, slides) and as soon as they are ready we will send them to the TOR foundation and make them publicly available. We already made suggestions to a few TOR developpers. Seun is currently working to adapt the attack to the recent update (that corrects partly the spinning technique). He is very confident at succeeding in this.
Seun should prepare a Phd and we intend to provide new approaches to enable and propose some sort of third generation of TOR that would contribute to solve the present conceptual problems. Part of the solution would be to use steganography to provide TRANSEC aspects. But we should also propose to protect the code loaded in memory to limit the techniques of dynamic cryptographic trapdoors. And we have many other ideas coming from malicious cryptography techniques we have recently developped.
Once again, the very final goal of our work is to provide a better solution at the end. That is why we did not want to enter the buzz and stay aside to go on working
We hope that people will understand
To finish I would like to thank people at H2HC (Rodrigo, Filipe and all the very nice guys I have met) as well people from PacSec (Dragos and his team) for their confidence and trust. We owe very much to them
Have a nice (hacking) day to all
E.F.