Tor Traffic Confirmation Attack -Roger Dingledine Report SUMMARY: On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks. The attacking relays joined the network on January 30 2014, and we removed them from the network on July 4. While we don't know when they started doing the attack, users who operated or accessed hidden services from early February through July 4 should assume they were affected. Unfortunately, it's still unclear what "affected" includes. We know the attack looked for users who fetched hidden service descriptors, but the attackers likely were not able to see any application-level traffic (e.g. what pages were loaded or even whether users visited the hidden service they looked up). The attack probably also tried to learn who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service. In theory the attack could also be used to link users to their destinations on normal Tor circuits too, but we found no evidence that the attackers operated any exit relays, making this attack less likely. And finally, we don't know how much data the attackers kept, and due to the way the attack was deployed (more details below), their protocol header modifications might have aided other attackers in deanonymizing users too. Relays should upgrade to a recent Tor release (0.2.4.23 or 0.2.5.6-alpha), to close the particular protocol vulnerability the attackers used -- but remember that preventing traffic confirmation in general remains an open research problem. Clients that upgrade (once new Tor Browser releases are ready) will take another step towards limiting the number of entry guards that are in a position to see their traffic, thus reducing the damage from future attacks like this one. Hidden service operators should consider changing the location of their hidden service. THE TECHNICAL DETAILS: We believe they used a combination of two classes of attacks: a traffic confirmation attack and a Sybil attack. A traffic confirmation attack is possible when the attacker controls or observes the relays on both ends of a Tor circuit and then compares traffic timing, volume, or other characteristics to conclude that the two relays are indeed on the same circuit. If the first relay in the circuit (called the "entry guard") knows the IP address of the user, and the last relay in the circuit knows the resource or destination she is accessing, then together they can deanonymize her. You can read more about traffic confirmation attacks, including pointers to many research papers, at this blog post from 2009: https://blog.torproject.org/blog/one-cell-enough The particular confirmation attack they used was an active attack where the relay on one end injects a signal into the Tor protocol headers, and then the relay on the other end reads the signal. These attacking relays were stable enough to get the HSDir ("suitable for hidden service directory") and Guard ("suitable for being an entry guard") consensus flags: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1775 Then they injected the signal whenever they were used as a hidden service directory, and looked for an injected signal whenever they were used as an entry guard. The way they injected the signal was by sending sequences of "relay" vs "relay early" commands down the circuit, to encode the message they want to send. For background, Tor has two types of cells: link cells, which are intended for the adjacent relay in the circuit, and relay cells, which are passed to the other end of the circuit. https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l364 In 2008 we added a new kind of relay cell, called a "relay early" cell, which is used to prevent people from building very long paths in the Tor network (very long paths can be used to induce congestion and aid in breaking anonymity): http://freehaven.net/anonbib/#congestion-longpaths https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-infinite-circuits.txt But the fix for infinite-length paths introduced a problem with accessing hidden services: https://trac.torproject.org/projects/tor/ticket/1038 and one of the side effects of our fix for bug 1038 was that while we limit the number of outbound (away from the client) "relay early" cells on a circuit, we don't limit the number of inbound (towards the client) relay early cells: https://lists.torproject.org/pipermail/tor-commits/2009-July/014679.html So in summary, when Tor clients contacted an attacking relay in its role as a Hidden Service Directory to publish or retrieve a hidden service descriptor (steps 2 and 3 on https://www.torproject.org/docs/hidden-services), that relay would send the hidden service name (encoded as a pattern of relay and relay-early cells) back down the circuit. Other attacking relays, when they get chosen for the first hop of a circuit, would look for inbound relay-early cells (since nobody else sends them) and would thus learn which clients requested information about a hidden service. There are three important points about this attack: A) The attacker encoded the name of the hidden service in the injected signal (as opposed to, say, sending a random number and keeping a local list mapping random number to hidden service name). The encoded signal is encrypted as it is sent over the TLS channel between relays. However, this signal would be easy to read and interpret by anybody who runs a relay and receives the encoded traffic. And we might also worry about a global adversary (e.g. a large intelligence agency) that records Internet traffic at the entry guards and then tries to break Tor's link encryption. The way this attack was performed weakens Tor's anonymity against these other potential attackers too -- either while it was happening or after the fact if they have traffic logs. So if the attack was a research project (i.e. not intentionally malicious), it was deployed in an irresponsible way because it puts users at risk indefinitely into the future. (This concern is in addition to the general issue that it's probably unwise from a legal perspective for researchers to attack real users by modifying their traffic on one end and wiretapping it on the other. Tools like Shadow are great for testing Tor research ideas out in the lab: http://shadow.github.io/ ) B) This protocol header signal injection attack is actually pretty neat from a research perspective, in that it's a bit different from previous tagging attacks which targeted the application-level payload. Previous tagging attacks modified the payload at the entry guard, and then looked for a modified payload at the exit relay (which can see the decrypted payload). Those attacks don't work in the other direction (from the exit relay back towards the client), because the payload is still encrypted at the entry guard. But because this new approach modifies ("tags") the cell headers rather than the payload, every relay in the path can see the tag. C) We should remind readers that while this particular variant of the traffic confirmation attack allows high-confidence and efficient correlation, the general class of passive (statistical) traffic confirmation attacks remains unsolved and would likely have worked just fine here. So the good news is traffic confirmation attacks aren't new or surprising, but the bad news is that they still work. See https://blog.torproject.org/blog/one-cell-enough for more discussion. Then the second class of attack they used, in conjunction with their traffic confirmation attack, was a standard Sybil attack -- they signed up around 115 fast non-exit relays, all running on 126.96.36.199/16 or 188.8.131.52/16. Together these relays summed to about 6.4% of the Guard capacity in the network. Then, in part because of our current guard rotation parameters: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters these relays became entry guards for a significant chunk of users over their five months of operation. We actually noticed these relays when they joined the network, since the DocTor scanner reported them: https://lists.torproject.org/pipermail/tor-consensus-health/2014-January/004134.html https://gitweb.torproject.org/doctor.git We considered the set of new relays at the time, and made a decision that it wasn't that large a fraction of the network. It's clear there's room for improvement in terms of how to let the Tor network grow while also ensuring we maintain social connections with the operators of all large groups of relays. (In general having a widely diverse set of relay locations and relay operators, yet not allowing any bad relays in, seems like a hard problem; on the other hand our detection scripts did notice them in this case, so there's hope for a better solution here.) In response, we've taken the following short-term steps: 1) Removed the attacking relays from the network. 2) Put out a software update for relays to prevent "relay early" cells from being used this way. 3) Put out a software update that will (once enough clients have upgraded) let us tell clients to move to using one entry guard rather than three, to reduce exposure to relays over time. 4) Clients can tell whether they've received a relay or relay-cell. For expert users, the new Tor version warns you in your logs if a relay on your path injects any relay-early cells: look for the phrase "Received an inbound RELAY_EARLY cell". The following longer-term research areas remain: 5) Further growing the Tor network and diversity of relay operators, which will reduce the impact from an adversary of a given size. 6) Exploring better mechanisms, e.g. social connections, to limit the impact from a malicious set of relays. We've also formed a group to pay more attention to suspicious relays in the network: https://blog.torproject.org/blog/how-report-bad-relays 7) Further reducing exposure to guards over time, perhaps by extending the guard rotation lifetime: https://blog.torproject.org/blog/lifecycle-of-a-new-relay https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters 8) Better understanding statistical traffic correlation attacks and whether padding or other approaches can mitigate them. 9) Improving the hidden service design, including making it harder for relays serving as hidden service directory points to learn what hidden service address they're handling: https://blog.torproject.org/blog/hidden-services-need-some-love OPEN QUESTIONS: Q1) Was this the Black Hat 2014 talk that got canceled recently? Q2) Did we find all the malicious relays? Q3) Did the malicious relays inject the signal at any points besides the HSDir position? Q4) What data did the attackers keep, and are they going to destroy it? How have they protected the data (if any) while storing it? Great questions. We spent several months trying to extract information from the researchers who were going to give the Black Hat talk, and eventually we did get some hints from them about how "relay early" cells could be used for traffic confirmation attacks, which is how we started looking for the attacks in the wild. They haven't answered our emails lately, so we don't know for sure, but it seems likely that the answer to Q1 is "yes". In fact, we hope they *were* the ones doing the attacks, since otherwise it means somebody else was. We don't yet know the answers to Q2, Q3, or Q4.
Aug 5 the FBI snakes in Freedom Hosting and put a number of websites out of business in the Dark Web. They let the flames go out that they caught a bunch of Pedophile sites with that bust, but it does not seem so.
The Attack on the Dark Net Took Down a Lot More Than Child Porn - http://gawker.com/the-attack-on-the-dark-net-took-down-a-lot-more-than-ch-1081274609 – gAtO contribute to this article–
Aug 19 – Millions of Tor Clients start to go up in numbers. What’s this all about, we get a bunch of Tor clients just hanging around doing nothing in Tor. Some say it’s a Bot-net or something like that. Then it growns 4, 5 million Tor users and the last week or so it starts to go down again. So what is all this about all these Tor Clients and the Tor- Botnet?
Oct 3– Silk Road get’s taken down, Oh the FBI had a copy of the Silk Road servers back in June just before the AUG 5 take down of FH by the FBI. So the Feds had Silk Road all this time and this is all they can do, can’t even get a few Bitcoin wallets- what a cluster fˆ%k—//
Now you got NSA saying that Tor is cracked and the bad guys cannot use it. They claim that they can hack Tor anytime and anywhere with documents that a summer student left on how to hack the Tor network back in 2006. By the Way – most of these hacks do not work in Tor, maybe on a regular network but not on the Tor network.
So now gAtO goes in search of Tor sites and a lot of sites went down by hook or crook —BUT someone has started to replace these Tor Hidden Websites in the Tor Network – But something is FuNnY – all these sites us the same web templates -
So now you can take a walk down memory lane and see all the older Tor-Websites have gone away and new ones have magicly re-appear.
Now if this was the only place were this has happens OK sure, but at other Tor- Wiki Tor Link sites you will see the same thing – Commercial sites are all FuNnY and all the non-commercial Tor-websites are Tango Down.
So now Tor goes round and round but nobody knows what the heck is going on- In the Tor network – The Deep Dark Web run by Criminals or the FBI – you can answer these questions yourself by visiting the site –trust but Verify– – ((not me))– gAtO oUt
Silkroad Seized Coins Addresses are identifiers which you use to send bitcoins to another person.
I found what I was after – this is all the Bitcoin Wallet Address from Silk Road that the FBI has -
caveat – check your wallet number if it’s not listed then your wallet is still cool and the funds available –MaYbE!!!
UPDATE: notice that SILK ROAD account is still paying out all this money to France, Germany all over the UE – 500 BTC – 100 -BTC at a time WoW – Someone is making off with all the money from the SR account-
Unspent Outputs 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX - https://blockchain.info/unspent?active=1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX&format=html
gAtO sEe- the fact is that as always GREED is what got SilkRoad Tango Down. I been getting lot’s of slack about Tor and all that but sorry, it’s as safe as you make it. Tor gives you an edge and if you really need the privacy and do your research on Tor, you too can communicate anonymous FACT not fiction -//
Now the Bitcoin aspect of this take down is what is really cool. This take down now makes BTC more legit since they can’t say yeah it all criminals using Bitcoins, na, na, na, – I saw the first few 1 million dollars BTC transaction the other day – but still “Bitcoin Buying and Selling is a pain the A$$” my new Bitcoin book coming out in a next months just in time for the holiday seasons - gAtO oUt
On 10/04/2013 02:21 AM, Roger Dingledine wrote:
OK, I just read the Maryland complaint. It’s obvious what happened.
An FBI undercover agent contacted him, wanting to sell large quantities
of cocaine. He found a buyer, and delegated the details to his employee.
Said employee had full admin access to his servers.
His employee then provided his ACTUAL PHYSICAL ADDRESS to the undercover
FBI agent. The FBI mailed 1 Kg (very highly cut) cocaine to said
employee, and arrested him on receipt. Said employee soon told the FBI
all that he knew.
So now the FBI had access to the servers. There’s no reason to suspect
that they needed to compromise Tor to gain access, or for anything else.
There’s more drama about the murder for hire stuff, but it’s irrelevant.
gAtO hEaR _UPDATE-
Sudden rise in direct Tor users
On Tuesday 27th, Roger Dingledine drew attention to the huge increase of Tor clients running . It seems that their number has doubled since August 19th according to the count of directly connecting users . According to Roger this is not just a fluke in the metrics data. The extra load on the directory authorities is clearly visible , but it does not look that the overall network performance are affected so far . The cause is still unknown, but there are already speculations about the Pirate Browser  or the new “anti-piracy” law in Russia which is in force since August, 1st . As Roger pointed out, ?some good solid facts would sure be useful.?
Ever since the the NSA Prism program came out something else is going on in Tor. People want privacy and they will use anything they can to get it. Tor is one solution that a lot of people know about but there are other factors about the increase.
Piratebay.sx and it’s users are doing a lot more stuff with the new browser - There has not been a sustained increase in search traffic for the Pirate Browser on Google. Tor and “Tor browser” haven’t shown a spike in search, either. Could it be from users in Syria? Also note that the Google Play Store has been unblocked in Iran, allowing distribution of Orbot/Orweb in that country to phones with the Play Store app installed (partial bootstrapping problem).
Syria had a spike from 1000 to 4000 but that’s a tiny fraction of the recent increase. Iran doubled from 4000 to 8000 which is also only a part of the increase. Is there a page listing each graph by country or overlapping them all?
The Tor Project also pushed out Orbot v12 to Google Play in the last few weeks – 2 separate updates. That would not account for all of the increase, but it could have prodded enough existing users who had not used Orbot in awhile to start the app up again. We have also seen about 75,000 new installs over the last 3 months.
So we have a lot of factors as the Tor network grows larger everyday- gATo oUt
gAtO lOOkInG - at the Tor-network intelligence, how does it do what it does. Tor takes volunteers Onion-relays and organizes them into different categories they are called “flags” -
— known-flags Authority BadExit Exit Fast Guard HSDir Named Running Stable Unnamed V2Dir Valid —
Of course there are only now 10 authority flags-servers own and controlled by some of the top people in the Tor-project community. These 10 Authority-relays control all the intelligence that Tor need to run and keep everything working automatic. Every few hours these relays gather the OR-relays and depending on how long they have been turned on, how much bandwidth they have what version of Tor-software and OS they have and put this together into one document then it does a calculation and assigns flags to the 3,500 or so volunteer OR-relays throughout the world. After it’s all said and done they produce a “Consensus Document and sends this information to every HSDir -OR-relay so that clients can find hidden service websites in Tor. The HSDIR relays have all the DNS information to find Tor-hidden service -websites…//
consensus document – May-2013
valid-after 2013-05-17 12:00:00
fresh-until 2013-05-17 13:00:00
valid-until 2013-05-17 15:00:00
voting-delay 300 300
known-flags Authority BadExit Exit Fast Guard HSDir Named Running Stable Unnamed V2Dir Valid
params CircuitPriorityHalflifeMsec=30000 UseOptimisticData=1 bwauthpid=1 pb_disablepct=0
dir-source tor26 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 184.108.40.206 220.127.116.11 80 443
contact Peter Palfrader
dir-source turtles 27B6B5996C426270A5C95488AA5BCEB6BCC86956 18.104.22.168 22.214.171.124 9030 9090
contact Mike Perry <mikeperryTAfsckedTODorg>
dir-source maatuska 49015F787433103580E3B66A1707A00E60F2D15B 126.96.36.199 188.8.131.52 443 80
contact 4096R/23291265 Linus Nordberg <firstname.lastname@example.org>
dir-source dannenberg 585769C78764D58426B8B52B6651A5A71137189A dannenberg.ccc.de 184.108.40.206 80 443
contact Andreas Lehner <email@example.com>
dir-source urras 80550987E1D626E3EBA5E5E75A458DE0626D088C 220.127.116.11 18.104.22.168 443 80
contact 4096R/4193A197 Jacob Appelbaum <firstname.lastname@example.org>
dir-source moria1 D586D18309DED4CD6D57C18FDB97EFA96D330566 22.214.171.124 126.96.36.199 9131 9101
contact 1024D/28988BF5 arma mit edu
dir-source dizum E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 188.8.131.52 184.108.40.206 80 443
contact 1024R/8D56913D Alex de Joode <email@example.com>
dir-source gabelmoo ED03BB616EB2F60BEC80151114BB25CEF515B226 220.127.116.11 18.104.22.168 80 443
contact 4096R/C5AA446D Sebastian Hahn <firstname.lastname@example.org>
dir-source Faravahar EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 22.214.171.124 126.96.36.199 80 443
contact 0x0B47D56D SiNA Rabbani (inf0) <sina redteam io>
r ididnteditheconfig6 AB+dZViiymIEpTtbx+9cX5Y32i0 sjraCwjE8lzInizQ0UPqTI1AHkE 2013-05-17 10:29:13 188.8.131.52 9001 9030
s Exit Fast Running V2Dir Valid
v Tor 0.2.3.25
p accept 20-23,43,53,79-81,88,110,143,194,220,389,443,464,531,543-544,554,563,636,706,749,873,902-904,981,989-995,1194,1220,1293,1500,1533,1677,1723,1755,1863,2082-2083,2086-2087,2095-2096,2102-2104,3128,3389,3690,4321,4643,5050,5190,5222-5223,5228,5900,6660-6669,6679,6697,8000,8008,8074,8080,8087-8088,8332-8333,8443,8888,9418,9999-10000,11371,19294,19638
r MukiMukiAmaguri ADwuo9jHaHhVHIjp8/rSBaoXkj8 qZ48RT3ftleevrpO/kNy1qeBAS0 2013-05-16 18:16:19 184.108.40.206 9001 9030
s Fast HSDir Running Stable Unnamed V2Dir Valid
v Tor 0.2.2.39
p reject 1-65535
r= Version of Tor- -OS -timestamp -IP address
s= Flags of the Onion-relay
w= bandwidth that the relays has
p= Exit relay information
The 10 servers on top of the documents are the Tor- Authority the servers that have all the real power in Tor controlled by – SiNA Rabbani (inf0) <sina redteam io> – Sebastian Hahn <email@example.com> – Alex de Joode <firstname.lastname@example.org> – arma mit edu – Andreas Lehner <email@example.com> – Linus Nordberg <firstname.lastname@example.org> - Mike Perry <mikeperryTAfsckedTODorg> – Jacob Appelbaum – Peter Palfrader <email@example.com> -
These are the real master of the Tor network nah… just joking it’s in the code- gAtO oUt
There is a small set (say, around 5-10) of semi-trusted directory authorities. A default list of authorities is shipped with the Tor software. Users can change this list, but are encouraged not to do so, in order to avoid partitioning attacks.
Every authority has a very-secret, long-term “Authority Identity Key”. This is stored encrypted and/or offline, and is used to sign “key certificate” documents. Every key certificate contains a medium-term (3-12 months) “authority signing key”, that is used by the authority to sign other directory information. (Note that the authority identity key is distinct from the router identity key that the authority uses in its role as an ordinary router.)
Routers periodically upload signed “routers descriptors” to the directory authorities describing their keys, capabilities, and other information. Routers may also upload signed “extra info documents” containing information that is not required for the Tor protocol. Directory authorities serve router descriptors indexed by router identity, or by hash of the descriptor.
Routers may act as directory caches to reduce load on the directory authorities. They announce this in their descriptors.
Periodically, each directory authority generates a view of the current descriptors and status for known routers. They send a signed summary of this view (a “status vote”) to the other authorities. The authorities compute the result of this vote, and sign a “consensus status” document containing the result of the vote.
Directory caches download, cache, and re-serve consensus documents.
Clients, directory caches, and directory authorities all use consensus
documents to find out when their list of routers is out-of-date.
(Directory authorities also use vote statuses.) If it is, they download
any missing router descriptors. Clients download missing descriptors
from caches; caches and authorities download from authorities.
Descriptors are downloaded by the hash of the descriptor, not by the
relay’s identity key: this prevents directory servers from attacking
clients by giving them descriptors nobody else uses.
All directory information is uploaded and downloaded with HTTP.
[Authorities also generate and caches also cache documents produced and
used by earlier versions of this protocol; see dir-spec-v1.txt and
dir-spec-v2.txt for notes on those versions.]
gAtO ThInKiNg - a car GPS works very simple, It takes the delay time from one geo-positioned satellite and compares is to another geo-positional satellite and estimates the position of the GPS in my CAR – I think they call it satellite triangulation or something cool, it’s been done with radios to guide pilots navigate ever since they developed radios. We do it with satellite and we can use networks too.
With a simple command you can get the time it takes to crawl a website, so you have one server in the U.S one is South America, one in Europe and one in Asia and we run the same command getting the delays from each location. I bet with a little math and some basic network tools we could figure out the geo-location of any given website in Tor. One of my good mentors told me that in my crawls I was capturing timing information, we all see timing information with a simple ping command in the clear web but in Tor – UDP is unsupported so it does not work -//- we must take into account the Tor network thru-put and utilization bit that’s easy to get from a number of Tor tools.
Reverse triangulation of a network server should be easy to find with a little math, just take a good sample and the longer you wait the more data you collect and the better the chance you can find a geo-location of a website. We do this in the clear web all the time we can see bad areas of the world that are bad spammers, and other like mail from Africa Prince Scams offering you millions if you send them some money to cover the transfer, or Russian and Chinese phishing attacks. So we know geo-location and some IP are more prime to bad actors and we can draw a profile, a geo-location of a place and/or country or an ISP so not having the IP of a Tor server may not be neededto find them we could use network triangulation. “triangulated irregular network ” So the same thing can be done with networks and timing delays of data back and forth from a // client <–> Tor OR <–>server.
I got a crazy Idea that may or may-not work, but it sounds good—// so— Now if I can only find a government grant and a good math major to help out and we have a big business model to find the bad guy’s geo-location even in Tor - gAtO oUt…
gAtO iS CrAwLliNg websites-We just completed our new crawl of Tor URL that we found. We started with 2,000 URL’s and we got about 550 positives from this first run. This will change since some sites go up and down for no rhyme or reason. I went back to verify one site that my crawl picked up with all kinds of good information but later when I went back it would not come up. So this is an ongoing thing in order to map out all of Tor’s hidden service websites. From the preliminary data Pedo sites are about 18% of the sites we discovered another 4-6% guns and assassins and another 14-16% of different criminal type’s of sites or scams. So that is over 36% of the sites we found were criminal type, that is not good for anyone.
Tor is an excellent software for being private and having some level of safety but this new light is not good for the people that want to use Tor and the Dark Web to do good things and positive things. Now we see that the bad guys are all over Tor-Dark Web we hope this list will help it become better.
This list is only available to Law enforcement, governments and selected security companies, you must be verified first before you can get a hold of this list of Onion websites in Tor. This is not a free list (we have to recover our cost of r&d) and this is only the first steps we have gained over 12,000 new URL in Tor from this crawl and will be doing more crawls and adding more information to the list.
What really freaked us out was the undocumented website that are not in any hidden wiki in Tor and the number of them being put out by criminals. Now some of the other information that we collected see list below will give us a baseline like — Last-Modified: — will give us an indication of how active they are. The —Server: & Web Application:— will give us the web app they use and from the looks of things some are vulnerable to all kinds of hacking attacks. Tor websites are the same as any site and if you don’t update your website, well your vulnerable to hacking from anyone and in Tor you don’t have a clue because they are protected just like the site.
This will be an ongoing crawl for the next year or so, so expect the list to grow and as new data is collected more will be revealed about the how, and the use of Tor and who uses Tor will become not just theories but facts that we can verify - gAtO OuT
Internal URL’s -
[size_upload] => 0
[size_download] => 124
[speed_download] => 7
gATo and fRiEnDs- are am now working on the Tor-Directory Project crawling about 2000 Tor-url and getting some new information about Tor and the sites that reside in the Dark Web. Example I got a good crawl from a site and I went to double check it and now it was down, so are the sites going up and down and online just for a period of time? Are the site not available because of the browser I am using -vs- my crawler. These are some of the answers I will find out.
I expected due to the slowness of Tor to spend a lot of time running these crawls. I have now a script that I can run in about 20hr or less and scrape about 2000 sites. I thought that the slowness of Tor-Dark Web would make this a real time eater but I am wrong. Another thing is the secret Tor sites I found, I now have a fingerprint on them and these sites that hide in secret on top of being in Tor are a real interest to me and others.
The main issue is Tor is not socks-http friendly so setting up the infrastructure was a real learning curve and now I can replicate the installation so as I get more servers online this will become a little easier. Right now I am mapping the sites so I can crawl every page, the good part and bad is I am finding more and more URL that I never thought existed, so the discovery of new URL is a good thing but once again the collection becomes a real bear.
I am putting this into a db to make the search of the collected data a little easier but finding that db programing on the web is well not very user friendly but I have a good partner that is fixing all my mistakes. We will house this new Tor-only website search engine in the clear web so we can keep the speed up and well people are scared to go into Tor, so why not keep everything in the clearWeb for now.
I expect the crawls to get much longer since I now have the urls to crawl every site a little better but the information and mapping out Tor will be and invaluable tool for us. You say how about the hidden wiki, and all those sites that have Tor directory wiki sites. Well they are OK for basic stuff but I am finding new sites I never heard of and the pedophiles are all over Tor so you best beware I am putting a light on your websites and the next part will be to stop you from using Tor as a play ground for your sick crap. Tor is meant for real needs of privacy and protection and I hope my work in this will get these sick bastards to run somewhere else — gATO is watching you in Tor so beware!!!
gAtO tHiNkInG - anonymity serves different interest for different user groups; To a private citizen it’s privacy, to a business it’s a network security issue. A business needs to keep trade secrets or have IP (knowledge base data-centers), communicate with vendors securely and we all know that business need to keep an eye on there competition – the competition can check your stats
update -11-14-2012 -uscyberlabs.com Tor Hidden Service = http://otwxbdvje5ttplpv.onion gAtO built this as a test sandbox / honeypot — cool logs stats -DOWN 4 upgrade – 06-11-2013
(http://www.alexa.com/siteinfo/uscyberlabs.com) and check on how your business is doing, what keywords your using, demographics of users hitting your site—— by the way in the Tor-.onion network a web site/service cannot be monitored unless you want it…
How would a government use a ToR-network I’m asked all the time —
// if I was an (agent/business-person)state actor doing business in China (and other countries too) well I would use a ToR-.onion connection to keep my
business private from a government that is know to snoop a bit on travelers to their country. The fact is governments need anonymity for their security -think about it “What does the CIA Google for?” Maybe they us ToR??? But this is about Hidden services right.
What is a hidden service in ToR-.onion network?
SImply put it’s a web site/service, a place in the ToR network were we have a service like:
- Search Engine
- web / pop3 email
- PM Private Messages
- Drop Box’s
- Bulletin Boards BBS
- Image Boards
- Currency exchange
- Social Networks
- Micro-Blog -
Hidden Services are called hidden, because your website’s IP in ToR is hidden- they cannot see the IP of your server — they can’t track you- if they can’t find you how are they gonna hack you???? Sorry I had to say that -((more about that later)). Now how do I keep this secret (my IP) and let you the user use my services. In the normal web if your in uscyberlabs.com your on my site,— my server -you can do a whois and get my IP and geo-location— then you can attack my website with dDoS and other IP attack vectors, you also get my location so you can physically find me- my server/my website – maybe go dumpster diving in the trash and get my company secrets— mAyBe sI – nO,
Well in the ToR-.onion network you the client ask the business website if they can use the websites service / then decide and start a handshake to a rendezvous POINT to meet —we meet at an OR ((onion relay))-a rendezvous POINT) not at my server/ my IP — so your never ever on the business site/server when your in onionLand, you can’t do a whois and get my IP because we meet at an OR, you cannot find my geo-location…..
We have heard of the killings of Iranians and Syrian rebels being killed in todays news, when an Iranian rebel is fighting for his and his families life if they(the government) finds his IP or the IP of the website he visited // they will hunt that person down and the Iranian police/government will kill the whole family sometimes. So keeping an IP from someone is not an evil act it is an act of privacy for safety on both sides the client and the business.
you need to look at Figure 2 to explains this better:
Now let’s focus on R2 OR the yellow key. That’s the spot were you(your company’s hidden website) and your client meet — I know it’s a sneaky way of doing business but once again if they can’t get to your IP at least that is one attack vector that can’t be used to hack you or ddos you. OK they can still hack you but it’s software then. How it’s all done – the magic —the technical thingy to this is below —/this is just an outline of events of the client /hidden web/service protocol:
I goes something like this –
- ESTABLISH RENDEZVOUS cell
- INTRODUCE2 cell
- INTRODUCE ACK cell.
- INTRODUCE2 cell
- RENDEZVOUS1 cell
- sends a RENDEZVOUS2 cell Chat
- sends a RENDEZVOUS2 cell Blog
- RENDEZVOUS ESTABLISHED cell
1. Whenever the rendezvous point receives a RELAY_COMMAND_RENDEZVOUS1 with the same cookie as the OR sent in the RELAY_COMMAND_INTRODUCTION1 cell it logs the reception and the IP address of the immediate transmitter of the cell. At the same time, the OR middle node monitors the circuits passing through it. Whenever it receives a DESTROY cell over a circuit it checks:
1) whether the cell was received just after the rendezvous point received the RELAY_COMMAND_RENDEZVOUS1 cell;
2) if the next node of the circuit at the middle node coincides with the previous node of the circuit at the rendezvous point;
3) whether the number of forwarded cells is exactly 2 cells up the circuit and 52 cells down the circuit.
More Geek network kinda stuff::
1. Jun 03 20:50:02.100 [notice] Tor 0.2.1.0-alpha-dev (r14739) opening new log file.
2. Jun 03 20:50:11.151 [notice] We now have enough directory information to build circuits.
3. Jun 03 20:50:12.697 [info] rend_services_introduce(): Giving up on sabotage as intro point for stuptdu2qait65zm.
4. Jun 03 20:50:18.633 [info] rend_service_intro_established(): Received INTRO_ESTABLISHED cell on circuit 1560 for service stuptdu2qait65zm
5. Jun 03 20:51:18.997 [info] upload_service_descriptor(): Sending publish request for hidden service stuptdu2qait65zm
6. Jun 03 20:51:22.878 [info] connection_dir_client_reached_eof(): Uploaded rendezvous descriptor (status 200 (“Service descriptor stored”))
People ask me how can these hidden services be attacked???
It’s all the same as in the surface web you find the software the hidden service is using /// let’s say Worpress (or flatPress) if they use an old version with vulnerabilities then, that site can be hacked by traditional hacking attack vectors— gAtO can’t wait till USCyberLabs.com will have a sandbox in the .onion were we can have a honeypot for people to hack and learn from. (we need Funding for these project donate please – we will share) gAtO has not tried Backtrack 5 on ToR-.onion network – mAyBe sI -nO – uscyberlabs.com has been hacked a few times already and is consistently fighting bot’s and spammer, it goes on and on.everywhere-.-.-.-
Here are some technologies used in the ToR-.onion network:
update -11-14-2012 -uscyberlabs.com Tor Hidden Service = http://otwxbdvje5ttplpv.onion gAtO built this as a test sandbox and it turned into a honeypot — cool logs stats
Snapp BBS works fine in OnionLand - http://4eiruntyxxbgfv7o.onion/ -
PHP BBS – http://65bgvta7yos3sce5.onion/
Nginx is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. – http://ay5kwknh6znfmcbb.onion/torbook/
Anyway I hope this open up the mystery of a hidden service in ToR – it’s just a website, you go to a rendezvous point and do your business — your IP and the business IP are totally secure. No digital breadcrumbs. Now a word to the wise in the ToR-.onion network you have some very tech savvy people and some are very stupid be a critical-cyber user always -gAtO oUt.
sOrRy – AROGANT gAtO - Open letter to:zhenling - jluo -wkui - xinwenfu – at seu.edu.cn cs.uvic.ca cs.uml.edu - I wrote to you and gave you a chace to reply so her it goes for everyone to see that you rigged your lab in real life it does not work like you claim – gATO OuT – may be wrong mAyBe Si -nO
Protocol-Level Hidden Server Discovery
Since entry onion router is the only node that may know the real IP address of the hidden service— -note  The assumption was made in virtually all attacks towards the Tor network. This is reasonable because onion networks routers are set up by volunteers.
WRONG folks — So criminals work in these sterile structured surrounding – following rules and making assumptions that I’m stupid enough to not know how to control ENTRY and EXIT nodes into my Tor Website— COme on Dudes this is not school it’s the real world… otwxbdvje5ttplpv.onion here is my site now find my IP —
WHo am I – Richard Amores – @gAtOmAlO2 – I run http://uscyberlabs.com – I just finished a boot -“ The Deep Dark Web” Amazon New eBook -The Deep Dark Web – http://www.amazon.com/dp/B009VN40DU Print Book – http://www.amazon.com/The-Deep-Dark-Web-hidden/dp/1480177598 :- I do a we bit of real life research and I disagree — I go thru a proxie and a VPN in EU… before I go into Tor so the chances that you will find my IP just went up a notch or too. But I’m a legit – Security Researcher – imagine if I run Silk Road — making a bunch of Bitcoins a DAY— how many layers do they have—
how about a basic BRIDGE RELAY — and there it goes – u can’t touch this — how about a simple modification of the torrc file with these
HiddenServiceAuthorizeClient AND – HidServAuth
with these few modification the Tor site is hidden unless you have the key (HiddenServiceAuthorizeClient) in your browser/- that was generated to match the HidServAuth)-of the server– I think that your chances of finding my mean ass hidden service ip address —are ZERO…
I like what you’ll did cool analyst and you explained it great – but this puts fear into people – dissidents will maybe not use Tor because of what you guy’s say and maybe they may get caught and killed… It’s not only CRIMINALS — I know that gets grants money — but Tor is used to communicate and it allows – Freedom of Speech in Cyberspace- I’m gonna write something about this and I want to be nice so please explain why — you can say from an educational place of knowledge and allow this – “in the box” thinking that is being hacked everyday because they say— we did everything they told us to do— this is wrong and not true —
If you could get the IP of Silk Road — or better yet – PEDO BEAR the largest PEDO directory in TOR — tell me the IP and I will take it down myself— but don’t come at me saying we are right and every hacker is wrong — learn please our world is depending on your great minds —
RickA- @gAtOmAlO2 http://uscyberlabs.com
Here is the original paper —http://www.cs.uml.edu/~xinwenfu/paper/HiddenServer.pdf
A recent paper entitled Protocol Level Hidden Server Discovery, by Zhen Ling, Kui Wu, Xinwen Fu and Junzhou Luo. Paper is starting to be discussed in the Tor community. From my perspective, it is a nice attack to reveal the IP address of a hidden service. It would require resources to actually implement effectively, but for Law enforcement trying to shutdown and arrest owners of illegal websites selling drugs, weapons, or child pornography and are hiding behind Tor, it is an option. Of course that also means the capability to find anyone that might be doing something a government or large entity does not agree with. The paper is here.
This stuff reminds me of a statement a professor said to a class I was in once: “Guns are not good or bad. It depends on who is holding the gun and which end is pointed at you.”