Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - astor

Pages: 1 ... 81 82 [83] 84 85 ... 208
1231
Quote
The telecommunications black hole exploited by the Comanchero gang and drug cartels has come to light after countries around the world - worried about terrorism and national security - threatened to ban BlackBerrys unless they were given the codes to break the encryption on emails and messages.

This is great. If the government / LE have a backdoor, then so does everyone else.

https://en.wikipedia.org/wiki/Greek_wiretapping_case_2004%E2%80%932005

https://en.wikipedia.org/wiki/SISMI-Telecom_scandal


1232
Yeah, using a random string to generate the descriptor ID should solve the issue of an attacker positioning himself as HSDirs. The random string is effectively a salt. Instead of:

descriptor-id = H(permanent-id | H(time-period | replica))

They would do:

descriptor-id = H(permanent-id | H(time-period | replica) | random string)

If the directory authorities generate the consensus random string an hour before the new GMT date, attackers won't have enough time to brute force a relay fingerprint close to the descriptor ID.

1233
Created 3 months ago:  https://trac.torproject.org/projects/tor/ticket/8244

The "rpw" that is CC'ed on that bug report is one of the authors of the paper above, so the Tor devs have privately known about this issue for three months prior to the publication of this research. The milestone is Tor 0.2.5. Version 0.2.4 should be moving to stable/final within the next few weeks, since there are only 8 tickets to resolve: https://trac.torproject.org/projects/tor/milestone/Tor%3A%200.2.4.x-final

When that happens, 0.2.5 will be available in the experimental repo. That doesn't mean it will have this feature immediately, but hopefully within a few months.

1234
LOLWUT?!?!

astor, you've tried MetaSilk, what do you think?

Doesn't really matter what I think. You (or a competent friend) can read the code and see what it does.

But yeah, I've used it, and it doesn't do anything malicious.

Frankly, the idea that SS would write malware is preposterous. He has more integrity than just about anyone.

1235
Security / Re: How does a signature work?
« on: May 25, 2013, 08:11 pm »
When it compares the two strings, it must do so in constant time to avoid the possibility of a timing attack.

Can you explain this attack?

1236
Security / Re: Where does Tor Browser store bookmarks??
« on: May 24, 2013, 08:23 pm »
If you secure deleted the entire TBB folder hierarchy and you believe that is a safe method (I don't know myself, but generally individual file overwrites are not safe), then you're good. Bookmarks are stored in /Data/profile/bookmarks.html and Data/profile/bookmarkbackups, which would have been deleted when you deleted the TBB folder hierarchy.

Keep in mind, if you're trying to eliminate all traces of the browser bundle on your computer, there may be traces outside of the TBB folder hierarchy. A Tor developer is doing forensic analysis of that, but they haven't done Macs yet. You can read about the Windows and Linux analysis here:

http://dkn255hz262ypmii.onion/index.php?topic=148291.0

Hopefully in another month she will post the results for Macs.

1237
A new paper came out with a similar but more thorough analysis. They claim to be able to identify hidden service entry guards in under 2 hours. They also propose counter-measures, which of course include layered entry guards. Here are the relevant parts.

Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization

http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

Abstract - Tor is the most popular volunteer-based anonymity network consisting of over 3000 volunteer-operated relays. Apart from making connections to servers hard to trace to their origin it can also provide receiver privacy for Internet services through a feature called "hidden services".  In this paper we expose flaws both in the design and implementation of Tor's hidden services that allow an attacker to measure the popularity of arbitrary hidden services, take down hidden services and deanonymize hidden services. We give a practical evaluation of our techniques by studying: (1) a recent case of a botnet using Tor hidden services for command and control channels; (2) Silk Road, a hidden service used to sell drugs and other contraband; (3) the hidden service of the DuckDuckGo search engine.




VII. REVEALING GUARD NODES OF HIDDEN SERVICES

In this section we present an attack to reveal the guard nodes of a hidden service when the list of the introduction points in the HS descriptor is not encrypted (for the case when the list of introduction points in encrypted see Appendix B).

To do this, we use a technique similar to that presented in section VI; control over at least two Tor non-Exit relays is needed to carry it out. In the attack, the hidden service is forced to establishes many rendezvous connections to the rendezvous point (RP) controlled by the attacker in hope that some circuits pass through the second node (the middle node) controlled by the attacker. The RP generates traffic with a special signature which can be identified by the
attacker's middle node. The steps of the attack are the same as in section VI.

Asymptotically, the probability that the attacker's middle node is chosen for the rendezvous circuit, approaches 1. Whenever the rendezvous point receives a RELAY_COMMAND_RENDEZVOUS1 with the same cookie as the attacker 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 attacker's 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.

If all the conditions are satisfied, the attacker decides that her middle node was chosen for the hidden service's rendezvous circuit and marks the previous node in the circuit as a potential guard node of the hidden service.

We implemented the attack and ran it against two hidden services operated by us. In both cases the guard nodes were identified correctly, without any false positives. In the first case, the rendezvous point received around 36 000 RELAY_COMMAND_RENDEZVOUS1 cells in 1 hour 20 minutes and the correct guard nodes were identified 8, 6, and 5 times correspondingly. In the seconds case, the rendezvous point received 16 000 RELAY_COMMAND_RENDEZVOUS1 cells in 40 minutes and the correct guard nodes were identified 5, 2, and 1 times respectively.

We also used this approach to identify the guard nodes of the botnet hidden service. Note that in the attack described in this section an attacker can use just one middle node and send the traffic signature as a client. However it requires building rendezvous circuits which makes the attack longer.  The same applies to the attack presented in section VI.


VIII. DISCUSSION AND POTENTIAL COUNTERMEASURES

We propose two countermeasures to make distributed storage of the hidden service descriptors more robust. The first of these prevents the directory authorities from learning the contents of hidden services descriptors they are serving.  This prevents hidden services from harvesting descriptors to learn more onion addresses. Our second proposed change makes the position of the responsible hidden service directories in the directory fingerprint ring unpredictable for any hidden service. This removes the opportunity of targeting hidden service directories. Henceforth attackers can no longer precompute identity keys to target hidden services for popularity measurements and to deny service to them by selectively running relays with those keys.

Harvesting can be easily prevented by making the descriptor-cookie authentication [15] mandatory for all hidden services and base32 encoding the value as part of the URL together with the permanent-id. The downside of this change is a significantly reduced usability: instead of 16 character onion addresses the user now has to deal with onion-addresses that are 42 characters long.

In order to prevent adversaries from efficiently targeting hidden service directories we propose the following changes:

For each hour, an unpredictable value is derived by the directory authorities from a shared secret. Three of these values are included in the consensus - one for each of the hours the consensus is valid.

The unpredictable value valid for the hour of the request is then included in the calculation of the descriptor ID and henceforth determines the place on the ring where the descriptor is stored. This makes it impossible for an attacker to precompute identity keys for time periods further ahead than 3 hours in the future. 

Additionally, directory authorities base the decision on whether a relay is assigned an HSDir flag on the number of past consecutive consensus documents the relay has been listed in and not on the uptime of the relay. This prevents the shadowing attack we have described.

To prevent the guard nodes being revealed, one can use an additional layer of guard nodes - guard middle nodes.  This countermeasure has already been proposed in [19] but is not implemented in Tor. Note that this measure will not protect against an attacker exploiting degree anomalies of the guard nodes as described in Section B. 

Unfortunately, we do not see how the risk of guard nodes being able to deanonymize a hidden service having chosen them can be eliminated completely. Recent work by Tariq et al. [9] suggests that the guards compromise rate can be decreased by (1) making the guard rotation interval longer and (2) by taking into account how long nodes have been part of the network when assigning Guard flags to them.  Note that this approach if not carefully implemented has a number of downsides like reduced end-user quality of experience and malicious nodes accumulating Tor users.

In regard to revealing the introduction circuits, if the attacker will not be able to collect the full list of hidden service descriptors, she will not be able to distinguish between introduction circuit of hidden services with encrypted introduction points and non-encrypted.



1238
Have you ever seen those videos of animals eating rotting fruit and getting drunk?

https://www.youtube.com/watch?v=D5E5TjkDvU0


It's possible that all sentient creatures (though I don't know to what extent wasps are sentient) like getting fucked up.

1239
Security / Re: PGP - when to use it ?
« on: May 24, 2013, 05:26 pm »
LE = law enforcement
LEA = law enforcement agency
LEO = law enforcement officer

1240
Security / Re: How does a signature work?
« on: May 24, 2013, 03:47 pm »
No, it's a separate feature from encrypting and decrypting. Your PGP program should have a "sign" button or menu option. Take a look at the GPG4USB tutorial linked in my signature. It tells you how to do it in that program. There will also be a "verify" option. One person signs a message and everyone else verifies it with his public key.

The purpose of a signature is that it proves whoever owns that PGP key wrote it. It has actually been useful in this community. DPR usually signs his messages so the community can trust his announcements. Also, there was a case where a vendor's SR and forum accounts got hacked. He had to create a separate forum account, and he was asked to post a signed message that could be verified with the public key on his profile, to prove his identity.

If you've never messed with signing and verifying, grab my public key from the link my signature and verify this message:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Astor wrote this message.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJRn4nRAAoJENAcophwbuIHnG0P/jqZzJ+/xl54n9yNQL59wMe/
mpUFtYtQa4ZiKaUmJWdGHjNbiMIx5WnYChGQGT9Dk53jMoL5bgGzV7qEul7k8tyE
Jzkf+5KZazhOTla8DAGMwZxrnRaWN5fdPh+rNKQ1uEcbYVjBhFAyM0fhiKISfeHZ
h8/Un9FIp9Q+NYJilGkTEpV1LeGspBFCn8JG1TvqYz3cCRMAJiQNiHI05fJZW+Qh
q4ChxF6LmvZ0Mh62bv2S5YGRkt0p0Z3X2ps4Y8zB0Owz/x+UEyQu+VAKMgaCmxhJ
QJsLXGwCrr0mdGo86DluRw22A3OTs5GqDglG8di04VgXAY1ZJK/Mi0+oFxCeUX+B
SsEc9ds95qwuGuHdBk3oFnscVM/OrMZBwHnGX2M66wiE0QycIefUufWJUqyEo28y
Hac8W+m7IadVyyygKmLzjS3PRMAgmFriazLYsz0NHPekC4NpS3qo+05UvxN5Gg/o
yebB68f0omKpHf84LLU1SW24kc8GhEzn/43tgic5JUo4gS+9qohQYr0uLkPBH9dt
yKN2LH4Z0pGmPzxixBh2pLBfspjWWoEqb+r30xGdiUoaiqEvFm2KR4FzVMDq/C+7
iJiDoRBVCQl6KosC6T+SDMzSQikk2WFOpbr7EF1MQL086qm7xCJmLs/w3CErFs2l
BeQCG1rHBApEO5snBxSo
=QqtJ
-----END PGP SIGNATURE-----

1241
Philosophy, Economics and Justice / Re: Reincarnation
« on: May 24, 2013, 03:55 am »
The first few posts in this thread are why masterblaster is the only troll on this forum that I kind of respect. I've thought about this for a while.

He's a genuinely intelligent person, which I gathered from some of his posts in the Security forum, and a few posts elsewhere -- those brief moments when he isn't trolling, or irrefutable logic shows through the trolling. I just can't fathom why he wastes so much time trolling this forum. What is the point MB?

1242
there are only 3 types that would buy a vendors account:
1) LE
2) scammer
3) some lazy ass - i usually dont like to generalize but lazy people are incompetent douchbags! always!

none of these 3 have honor or their word.

That's an excellent point, and I agree with you. Especially the LE threat is serious, but there doesn't seem to be anything you can do about it. Those deals happen outside of SR.

You might say, there's nothing they can do about out of escrow transactions but they ban that.

Yeah, but most of those people want to keep their accounts. So they have leverage. They can scare people by threatening them with a ban. Are one or two out of escrow transactions worth losing your account over?

Someone willing to sell their account is someone who wants to leave the game anyway. There's no leverage over them, so why pretend you have any? It'll just make you look like a fool when it happens anyway, and LE busts a bunch of people after taking over an account.

1243
It's like the "cartels". How are you going to stop it?

If a vendor sells their account and the new vendor has crap product and/or service, their reviews will tank.

Even the same vendor can drastically change in the quality of their product or service, so there's no guarantee of anything.

Either way, we have a review system, and the market will work itself out.

1244
Security / Re: best harddrive wipe software
« on: May 24, 2013, 12:50 am »
Hardware erasure is better than software erasure, so check if your hard drive has the ATA secure erase feature and use that if it does.

If it doesn't, like Christy said, DBAN it.

Also: http://dkn255hz262ypmii.onion/index.php?topic=99520.msg699299#msg699299

1245
On a related note, this is a forensic analysis that one of the Tor Project developers did, to see what kinds of traces the browser bundle leaves behind on a Windows system:

http://dkn255hz262ypmii.onion/index.php?topic=148291.msg1152452#msg1152452

What it means is that if you deleted TBB from your computer, even if LE didn't analyze the free space for deleted files, they could find evidence that it existed. However, they wouldn't find evidence of what you were browsing.

In OP's case it doesn't matter (I just thought it was useful related information), he had TBB on his computer and a link to SR. But if you want to absolutely hide your Tor use, you must extract the browser bundle on an encrypted volume, preferably a thumb drive that can be disposed of easily.

Pages: 1 ... 81 82 [83] 84 85 ... 208