07/30/14

Tor Traffic Confirmation Attack

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.gato_signal_02

  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 50.7.0.0/16
  or 204.45.0.0/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.
10/11/13

Tor Wacky Times and the NSA

gAtO rEaD – that Tor (The Deep Dark Web) is now all messed up by the NSA, FBI and LEO so all you bad guys using the Tor network better watch out, or should they???fed_links_01

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–

fed_usCitizenship_01Aug 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?fed_rent_a_hacker01

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—//fed_cc-paypal_01

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.fed_hit_man_01

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.

fed_apple4bitcoin_01Now 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

fed_counterfiet_euro_50 fed_counterfiet_usd_01 fed_links_01 fed_mobile_steal_store_01 fed_uk_guns_01

 

 

 

 

 

 

 

 

 

 

 

 

10/4/13

Silk Road down – Tor still OK

Silkroad Seized Coins Addresses are identifiers which you use to send bitcoins to another person.

https://blockchain.info/address/1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX

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.

 

08/28/13

Tor Usage goes UP PirateBay, Iran-Syria and Google-play Orbot

USCyberLabs Stats of the Tor Network Aug-27

USCyberLabs Stats of the Tor Network

gAtO hEaR _UPDATE-

Sudden rise in direct Tor users



On Tuesday 27th, Roger Dingledine drew attention to the huge increase of Tor clients running [14]. It seems that their number has doubled since August 19th according to the count of directly connecting users [15]. According to Roger this is not just a fluke in the metrics data. The extra load on the directory authorities is clearly visible [16], but it does not look that the overall network performance are affected so far [17]. The cause is still unknown, but there are already speculations about the Pirate Browser [18] or the new “anti-piracy” law in Russia which is in force since August, 1st [19]. As Roger pointed out, ?some good solid facts would sure be useful.?

[14] https://lists.torproject.org/pipermail/tor-talk/2013-August/029582.html

[15] https://metrics.torproject.org/users.html?graph=direct-users&start=2013-05-29&end=2013-08-27&country=all&events=off#direct-users

[16] https://metrics.torproject.org/network.html#dirbytes

[17] https://metrics.torproject.org/performance.html

[18] https://lists.torproject.org/pipermail/tor-talk/2013-August/029584.html

[19] https://lists.torproject.org/pipermail/tor-talk/2013-August/029583.html



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

 

06/21/13

Tor Network Consensus Document

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

———————————————————————————-———————————————————————————-

network-status-version 3

vote-status consensus

consensus-method 17

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

client-versions 0.2.2.39,0.2.3.24-rc,0.2.3.25,0.2.4.5-alpha,0.2.4.6-alpha,0.2.4.7-alpha,0.2.4.8-alpha,0.2.4.9-alpha,0.2.4.10-alpha,0.2.4.11-alpha,0.2.4.12-alpha

server-versions 0.2.2.39,0.2.3.24-rc,0.2.3.25,0.2.4.5-alpha,0.2.4.6-alpha,0.2.4.7-alpha,0.2.4.8-alpha,0.2.4.9-alpha,0.2.4.10-alpha,0.2.4.11-alpha,0.2.4.12-alpha

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 86.59.21.38 86.59.21.38 80 443

contact Peter Palfrader

vote-digest C9B36D4CE1E4E25D313DBCB9CAB01BD6402136BB

dir-source turtles 27B6B5996C426270A5C95488AA5BCEB6BCC86956 76.73.17.194 76.73.17.194 9030 9090

contact Mike Perry <mikeperryTAfsckedTODorg>

vote-digest 2974C1E86CE7D44B2A1B304DDED4D6965C519F6C

dir-source maatuska 49015F787433103580E3B66A1707A00E60F2D15B 171.25.193.9 171.25.193.9 443 80

contact 4096R/23291265 Linus Nordberg <linus@nordberg.se>

vote-digest 4C9F8F31152829E776531350A3D0A3AB4F601FBF

dir-source dannenberg 585769C78764D58426B8B52B6651A5A71137189A dannenberg.ccc.de 193.23.244.244 80 443

contact Andreas Lehner <anonymizer@ccc.de>

vote-digest E326C020E9462BA105EC190DFBE4EA8FADA3A138

dir-source urras 80550987E1D626E3EBA5E5E75A458DE0626D088C 208.83.223.34 208.83.223.34 443 80

contact 4096R/4193A197 Jacob Appelbaum <jacob@appelbaum.net>

vote-digest 9D6CB9D0890C4BF18D12BBB4F26F5BC762B081C3

dir-source moria1 D586D18309DED4CD6D57C18FDB97EFA96D330566 128.31.0.34 128.31.0.34 9131 9101

contact 1024D/28988BF5 arma mit edu

vote-digest 21FCEA71FE6597E39E586721F7DA65C3A74A4EA1

dir-source dizum E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 194.109.206.212 194.109.206.212 80 443

contact 1024R/8D56913D Alex de Joode <adejoode@sabotage.org>

vote-digest 0787DE217B45ED8895701D679F02E755A257AF4F

dir-source gabelmoo ED03BB616EB2F60BEC80151114BB25CEF515B226 212.112.245.170 212.112.245.170 80 443

contact 4096R/C5AA446D Sebastian Hahn <tor@sebastianhahn.net>

vote-digest EEECD55223C97CACF7655D897782B61B64C1CF03

dir-source Faravahar EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 154.35.32.5 154.35.32.5 80 443

contact 0x0B47D56D SiNA Rabbani (inf0) <sina redteam io>

vote-digest EE92CA0F3820E3BAFC22C41DFD107D4F4B34E542

r ididnteditheconfig6 AB+dZViiymIEpTtbx+9cX5Y32i0 sjraCwjE8lzInizQ0UPqTI1AHkE 2013-05-17 10:29:13 128.8.24.14 9001 9030

s Exit Fast Running V2Dir Valid

v Tor 0.2.3.25

w Bandwidth=14

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 119.25.52.227 9001 9030

s Fast HSDir Running Stable Unnamed V2Dir Valid

v Tor 0.2.2.39

w Bandwidth=38

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 <tor@sebastianhahn.net> – Alex de Joode <adejoode@sabotage.org> – arma mit edu – Andreas Lehner <anonymizer@ccc.de> – Linus Nordberg <linus@nordberg.se> -  Mike Perry <mikeperryTAfsckedTODorg> – Jacob Appelbaum – Peter Palfrader <jacob@appelbaum.net> -

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.]

03/10/13

Finding the Bad Guy’s in Tor -triangulated irregular network

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.

triangulated irregular network  -So now apply this to the Tor bad guy’s websites- a hidden service!math_clouadTag

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…

03/9/13

Tor Website 36% are Criminals Sites

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.

Crawling Tor Hidden Service - websites

Crawling Tor Hidden Service – websites

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

 [url] 

    [content_type]

    [http_code]

    [header_size]

    [request_size]

    [filetime]

    [ssl_verify_result]

    [redirect_count]

    [total_time]

    [namelookup_time] 

    [connect_time]

    [pretransfer_time]

    [size_upload] => 0

    [size_download] => 124

    [speed_download] => 7

    [speed_upload]

    [download_content_length] 

    [upload_content_length]

    [starttransfer_time]

    [redirect_time]

    [certinfo] 

Cache-Control

Expires: 

Pragma: 

HTTP

Server:

Crawl Date:

Content-Type: 

Content-Length:

Last-Modified:

Connection:

Accept-Ranges:

Proxy-Connection: 

Set-Cookie:

Content-Length: 

Accept-Ranges:

Web Application:

 

03/7/13

Mapping Tor Websites

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!!!

 

11/14/12

What Are ToR Hidden Service?

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 Servicehttp://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
  • Directories
  • web / pop3 email
  • PM Private Messages
  • Drop Box’s
  • Re-mailers
  • Bulletin Boards BBS
  • Image Boards
  • Currency exchange
  • Blog
  • E-Commercce
  • 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
  • INTRODUCE1
  • 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

TorStatusNet – http://lotjbov3gzzf23hc.onion/   is a microblogging service. It runs the StatusNet microblogging software, version 0.9.9, available under the GNU Affero General Public License.

FlatPress is a blogging engine like -Wordpress blog http://flatpress.org/home/   – http://utup22qsb6ebeejs.onion/ -

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.

11/13/12

Protocol-Level Hidden Server Discovery -WRONG

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 

zhenling@seu.edu.cn
jluo@seu.edu.cn
wkui@cs.uvic.ca
xinwenfu@cs.uml.edu

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 [3] 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 —

later,
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.”