- tor-dev - lists.torproject.org

Malicious relays and honeypots
by Gareth Owen 26 Nov '14

26 Nov '14

Hi all I wonder if it might be worth having a discussion on how to detect malicious and/or suspicious relays. To my knowledge, the project currently only scans for MITM and tries to detect larger Sybil attacks (but doesn't always act when detected). We have a lot of knowledge now about types of attacks and the unusual behaviours that might present if they are being deployed. For example: 1) Relays changing their ident every 24 hours are likely trying to be in a position to be the directory node for a HS (there are several of these relays active today). 2) Many relays being launched on sequential IP addresses, and/or with two nodes per IP - again - likely intercepting DHT publications or Sybil. 3) I have spotted several times a large number of relays in the same subnet, or adjacent /24 subnets. You could extend this to ASes. 4) Honeypot relays that try to spot unusual cells or traffic patterns traversing the tor network. For example, this could have detected the RELAY_EARLY attack if it was based on a different code base. One could define very robust and tight rules for what is permitted - flagging nodes sending unusual traffic. Additionally, PADDING cells are not currently used by the official client but are used very widely in traffic confirmation attacks - whilst intermediate relays wont be able to detect this, clients can and could flag it with an authority (via a 3-hop circuit). 5) One could scan for unusual descriptors being returned too - e.g., the descriptor is currently with in tight size bounds - but one could pad with bytes to support traffic confirmation if PADDING cells are put on the red flag list. 6) We also have the wider question of traffic tampering by exits, like the recent binary patching exit which I believe was not detected by the project. 7) And finally, Exits that only exit ports which permit tampering - e.g. the exits that only exit Bitcoin traffic for example. The question of course is where is the threshold and what does one do in the event of one of these.. Personally I am of the view that suspicious relays are not worth keeping in favour of diversity - but that view does contradict the project's I think. Best Gareth -- Dr Gareth Owen Senior Lecturer Forensic Computing Course Leader School of Computing, University of Portsmouth *Office:* BK1.25 *Tel:* +44 (0)2392 84 (6423) *Web*: ghowen.me

2 1

Re: [tor-dev] Feedback on obfuscating hidden-service statistics
by George Kadianakis 25 Nov '14

25 Nov '14

"A. Johnson" <aaron.m.johnson(a)nrl.navy.mil> writes: >>>> George and I have been working on a small proposal to add two >>>> hidden-service related statistics: number of hidden services and >>>> total hidden-service traffic. >>> >>> Great, I’m starting to focus more on this project now. Well, >>> actually I’m going on a trip for a week today, but *then* I’m >>> focusing more on this project :-) >> >> Sounds great! We're meeting every Tuesday at 16:00 UTC in #tor-dev. >> Feel free to drop by. > > Excellent. I won’t be there this coming Tuesday, but I’ll be there the next Tuesday. > >> Replicas mean that each descriptor is stored under two identifiers, so >> that's two places. Further, descriptor identifiers change once per >> day, so during a 24-hour period, there are up to four descriptor >> identifiers for a hidden service. > > That makes sense. It would be nice if the statistics would allow you > to identify how long (i.e. how many hour periods) each descriptor was > observed being published. That would allow us to figure out if there > are lots of short-lived services or fewer long-lived > services. Publishing statistics every hour would pretty much take care > of this. If you are really set on 24 hours, then perhaps you could add > the total number of published descriptors in addition to the number of > *unique* published descriptors. > > Also, my suggestion about using additive noise applies equally well to > the descriptor statistics. And multiplicative noise is a *bad idea* if > you don’t have some adjustment for small values (e.g. 10% noise of a 0 > value is 0, and 10% of 1 is only 0.1). > >> We have been thinking about many more hidden-service related >> statistics in a separate document. We're currently discussing whether >> we should turn it into a tech report, because we'll probably not want >> to implement most of those statistics. If you have remarks or more >> ideas, please feel free to edit the document. We're going to have a >> public review round for this, too, but that might not happen in the >> next week or two. >> >> https://etherpad.wikimedia.org/p/hs_stats_78281091 > > Great! I think we should go for at least a little more data in the > current proposal (what is the timeline for this, btw?). I think we > should come up with a list of statistics we might imagine gathering > and identify the subset of those that we’re comfortable gathering at > this point. For example, I think failure statistics is much more > innocuous than other data, and those would be very useful. For > example, they would help us understand how to improve the protocol is > failing, and it might help us identify misuse of hidden services > (e.g. by botnets clients stupidly looking for non-existent descriptors > or by malicious crawlers attempting to brute force descriptors). So > here are some ideas: > 1. Number of fetch requests for descriptors that don’t exist (number of fetch requests that do succeed would of course be very useful as well) > 2. Number of descriptor publishes to the wrong HSDir (actually I suspect that the HSDir doesn’t check this and wants to be accepting of any publish) > 3. Number of rendezvous circuits that never connect (from the RP perspective) > 4. Number of rendezvous circuits on which no data cells are ever sent > (CC'ed [tor-dev]) Thanks for the input Aaron! The timeline here is that we are hoping the proposal _and_ the implementation to be ready by mid-December. Then we are hoping that we can deploy the code to a few relays so that we have some data by January. So, time is tight. I'm currently OK with the two statistics in: https://people.torproject.org/~karsten/volatile/238-hs-relay-stats.txt I feel that any other statistics will need to be carefully analyzed. We should add the ideas you mentioned in the etherpad, and get them included in the tech report (which we are also hoping to have ready in some form by mid-January). The tech report is supposed to contain and analyze most of the HS statistics we can think of. It will likely contain many stats that we will never do, but also some stats that might be a good idea. The good ones we should eventually integrate to the Tor proposal and write code for. >> Thanks for the very valuable input! Let me know if the following >> draft looks okay, and I'll start another thread on tor-dev@. >> >> https://people.torproject.org/~karsten/volatile/238-hs-relay-stats-2014-11-… > > "Lab(\epsilon/C)” -> "Lap(\epsilon/C)” (that was my mistake. I think > having the added noise both parameterized and included in the reported > statistics is an idea worth thinking about. Making it a parameter > allows you to easily change it without upgrading. Including it in the > statistics would allow us to correct better for noise if different > relays might be adding different amounts of noise due to inconsistent > opinions of the noise parameter (if this should never happen, then I > guess this wouldn’t be necessary). > > So again, sorry that I’m not going to be very responsive on this for the next week. I’m really happy that you’re working on it! > > Best, > Aaron

4 6

botnets+tor
by Enkidu Mo Shiri 25 Nov '14

25 Nov '14

nowadays using tor by botnet developers is bringing risk to tor network. the use hidden service feature in tor network ,install their IRC server and by hiding behind relays,packet encryption and layers of tor, control and command botnets and use them for attacks. 1.i am researching about any possibility if i can differentiate between botnet traffic and normal tor network traffic by sniffing and analysing network traffic at gateway of my campus. 2.any idea about this technique: i run a botnet in my computer (sandbox) attach a script to it(developed by myself) ang let botneet works. the botmaster (hacker) receives botnet report( after it pass by 2 relays) and my script runs in his computer and sends me his system information. 3. have a question about tor network structure: how many nodes are between user A 9 outside tor) and user B( in internet but outside tor) ? i dont their communication will pass by two nodes(relay) but what other node? how does hidden service provide service to them? any authentication stuff? sorry if its not related to this mailing list. *Ehsan Moshiri (Enkidu)* *Digital Forensic And Penetration testing Researcher * *H/P:+96 111 2868 696* *Linkedin: http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/ <http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/>* *Facebook: Enkidu Oshiri* *wechat: Enkidu-Moshiri* *whatsapp&viber:+961112868696*

1 0

[PATCH] Pinning middle nodes for HSes: anti-guard-discovery
by George Kadianakis 25 Nov '14

25 Nov '14

Hello, inspired by the recent discussions on guard discovery, I went ahead and implemented a small patch for Tor that tries to help defend against Hidden Service guard discovery attacks. It basically allows the operator to specify a set of nodes that will be pinned as middle nodes in Hidden Service rendezvous circuits. The option only affects HS rendezvous circuits and nothing else. Of course, it doesn't fix guard discovery, it just pushes guard discovery to the next hop, so that they need to compromise two boxes to win. You can find my branch in 'sticky_mids' at https://git.torproject.org/user/asn/tor.git . (Here it is in HTTP shape: https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_m… ) I don't expect this to be merged in mainline Tor, but if any HS operators feel like they need it, here it is. I coded it fast and it seems to work for me, but please inform me of any bugs. You can use it by adding a line like this in your torrc: """ HSRendezvousMiddleNodes TorLand1 """ (BTW, I'm not advocating TorLand1, it's just a random relay name I thought of. Please use your own web of trust.)

2 2

doc/HARDENING Draft
by Libertas 24 Nov '14

24 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I thought I'd share an initial draft of doc/HARDENING. Please share any opinions or contributions you have. This was written in a little more than an hour, so it's still a work in progress. However, in the spirit of prototyping before polishing, I thought I'd share early. Here's the relevant ticket: https://trac.torproject.org/projects/tor/ticket/13703 A specific topic of conversation is how much of the advice should be in the document itself as opposed to linked sources. It could also use more OS diversity. After reading it, you can probably guess which *nix flavors I'm familiar with. Enjoy, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUc7qtAAoJELxHvGCsI27NOwsP/1bP+g4W2y1NHefR5bd+5hwo V927TXzarNneNFxfhKJsVewVnU593Ex13iHv+WgA+XM39xiK8KkhpxOaw2IpahZp pIRCk4/XX78YaEc/K3ci2AsNGFVXPBX7nm4/VOZ5qiGfo+FVeipykweF1dF+X1Wc 1wr8Q9LWKoIab+klu/BG5nG5NtwICYslbgXMvNnapHuy0Xn1+fvBx3mW9teMkJ0N Npssiy7XUqJx1XpdYNJr4XI28aHOV2p4FeCdsAgaQ1OBkOvpzMd+fw2Yb3FOiX/l 5pNCPMXFsS/+OXp1qOFKDQoOb7fEP6mY4NqdSovuJU0oWdurnHVk/X3SidALfH/L vFPdTwpCJSMLuYO7HsLLiLx6LkDtrDZ2y9+tUfpqKGAN0upXrIi5GWsbUeLcCqwY UFYdSg1GHsWJz7fU6F1vDLpGsiXU5yVqgaxfP06+nZ/smRt5sA3nlMDCZJi3BDes k0+c4+tAPZ5Yt6kJ5b1GBgxQMokDqnLm/4pb/qlp0EzDfhWpA+Un2lGdvInrz1ds VsVvbq/LLuxYylC3hlF8pNxBVMdbXycWM1w/VHtDjPZFdo9AO4CJHXeShYQa2O0W cBXdU+O59wWoxiCuEfo0O2xaJw2UIRfxauQbcp/A0rg8FKU1c2QeP2t7y8VdVC1Y SgQNVCUKYPBMCywJw9PA =yY3r -----END PGP SIGNATURE-----

1 0

Next OONI weekly meetings
by Arturo Filastò 24 Nov '14

24 Nov '14

Hello Oonitarians, Sorry for not sending this email sooner, but this week has been a bit hectic. A couple of people have said that they cannot attend the weekly meeting on thursday at 18:00, because it conflicts with another recurring appointment they have. For this reason I am going to suggest we reschedule the next OONI meetings to a date that works for everybody. Monday and Tuesdays seem to be the best option, so I am going to propose we skip next weeks meeting and instead opt for holding next weeks one on either a Monday or Tuesday at 18:00 UTC, 19:00 CET, 13:00 EST, 12:00 CST, 10:00:00 PST. How does this sound for everybody? I personally would prefer Monday over Tuesday, but if you would instead prefer Tuesday please send a reply to the ooni-dev mailing list. If nobody replies I am going to assume every Monday works for you all and the next meeting will be on Monday 24th of November. Have fun! ~ Arturo

2 2

How does a hidden service select introduction points
by Richard Dennis 24 Nov '14

24 Nov '14

Hi guys, i have been doing a bit of reading recently about hidden services, and i am just wondering how exactly a hidden service selects its introduction points, i understand there are two methods, one where the H.S picks its own set of I.P's and one where this is done for the H.S., is this correct? If so is there an algorithm for automatically selecting introduction points for a hidden service and is one method recommended over another, if so why? Finally how many introduction points does a H.S. usually have, can a larger H.S. have more I.P's to deal with the traffic or is this not advised ? Thanks for the help Rich

2 1

More consistant src/or/config.c [patch]
by grarpamp 24 Nov '14

24 Nov '14

--- src/or/config.c.orig 2014-10-19 11:13:04.000000000 -0400 +++ src/or/config.c @@ -852,12 +852,14 @@ "moria1 orport=9101 " "v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 " "128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31", - "tor26 orport=443 v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " + "tor26 orport=443 " + "v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D", - "dizum orport=443 v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 " + "dizum orport=443 " + "v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 " "194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755", - "Tonga orport=443 bridge 82.94.251.203:80 " - "4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D", + "Tonga orport=443 bridge " + "82.94.251.203:80 4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D", "turtles orport=9090 " "v3ident=27B6B5996C426270A5C95488AA5BCEB6BCC86956 " "76.73.17.194:9030 F397 038A DC51 3361 35E7 B80B D99C A384 4360 292B", @@ -867,7 +869,8 @@ "dannenberg orport=443 " "v3ident=585769C78764D58426B8B52B6651A5A71137189A " "193.23.244.244:80 7BE6 83E6 5D48 1413 21C5 ED92 F075 C553 64AC 7123", - "urras orport=80 v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C " + "urras orport=80 " + "v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C " "208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417", "maatuska orport=80 " "v3ident=49015F787433103580E3B66A1707A00E60F2D15B "

2 1

Damian's Status Report - November 2014
by Damian Johnson 23 Nov '14

23 Nov '14

Hi all. Next weekend I'm returning to ye olde isle of Vashon to feast with family, so figured I might as well send this out early. I'll be in a Thanksgiving food coma this time next week, after all... My devious scheme for November was to finish rewriting arm's graph panel and, while that certainly made progress, Stem, DocTor, and internal discussions stole the spotlight this month... -------------------------------------------------------------------------------- DocTor -------------------------------------------------------------------------------- * We now notify directory authority operators directly of issues in addition to the tor-consensus-health@ list. This should reduce duration of outages and other issues with the authorities. * We replaced turtles with longclaw. Sebastian deserves major kudos for orchestrating this. [1] * Properly fixed DocTor's OOM issues by not shelling out to send notification emails. [2] * DocTor detected a burst of relays from Google App Engine. These relays lacked any contact information so we dropped them from the network as a potential Sybil attack. [3] If you're the operator of these then please let us know! We'd be delighted to add you back in once there's a proper family and contact information. -------------------------------------------------------------------------------- Stem -------------------------------------------------------------------------------- * Ossi Herrala made delightful improvements so we parse descriptors ~10% faster [4], and now read from the '.new' files in Tor's data directory [5]. Thanks Ossi! * Expanded our descriptor tutorials with an example of persisting descriptors to disk. Thanks to mmcc for the idea [6]... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#saving… https://stem.torproject.org/tutorials/examples/persisting_a_consensus.html * Replaced quite of bit of boilerplate in Stem with a new @with_default decorator. Mmmmm, deleting code is fun... [7] * Updates to reflect changes in Tor's spec this month, including HS_DESC's new reason attribute, and validating the new consensus parameters. A couple other quick things of note is that I spruced up our volunteer page [8] and attended this month's Seattle TA3M. The later had a nice bit of serendipity in that I met Anna, a UW PhD student who's looking into our Bandwidth Authorities [8]. Best of luck Anna! That's certainly an area that could do with a lot of improvement. ;) Cheers! -Damian [1] https://trac.torproject.org/projects/tor/ticket/13296 [2] https://gitweb.torproject.org/doctor.git/commitdiff/94a2e9d [3] https://lists.torproject.org/pipermail/tor-consensus-health/2014-November/0… [4] https://trac.torproject.org/projects/tor/ticket/13821 [5] https://trac.torproject.org/projects/tor/ticket/13756 [6] https://trac.torproject.org/projects/tor/ticket/13774 [7] https://gitweb.torproject.org/stem.git/commitdiff/56a1f03 [8] https://gitweb.torproject.org/project/web/webwml.git/commitdiff/05c1b60

1 0

botnets in tor
by Enkidu Mo Shiri 22 Nov '14

22 Nov '14

Hi everyone, am new and not very sure about rules here,hope its not off-topic. im master student researcher and i am working on botnet detection. it would be appreciated if anyone can help me with : I. anyway to detect botnet trafic out of normal tor traffic? II. is this solution possible to apply? to attach a script to botnet ( so we pass reverse engineering and no mess with codes of malware) and send it back to network, let the relays and last node which is botmaster recieves the compromised botnet ,and the script report our detector machine of any time it been re-routed in tor network ( hidden service and relays and botmaster) about : ip address of receiver hosts (relays) and their computer information( os,...) and consider last hop as botmaster. after using this technic for few botnets, we can have a good view of how relays (and which relays) been used for attack bt botnet and who is botmaster : it can help tor admin to clean relays, remove that hidden service , blacklist botmaster ip address thank you *Ehsan Moshiri (Enkidu)* *Digital Forensic Student* *H/P:+96164953954 , +961124249769* *Linkedin: http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/ <http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/>* *Facebook: Enkidu Mo Shi Ri* *wechat: Enkidu-Moshiri* *Line: Enkidu.Moshiri*

1 0