Silk Road forums
Discussion => Security => Topic started by: envious on February 28, 2012, 04:14 am
-
A Database Error Occurred
Error Number: 1146
Table 'market.favorites' doesn't exist
SELECT COUNT(*) AS `numrows` FROM (`favorites`) WHERE `type` = 'user' AND `object_id` = '1444' AND `deleted` = 0
Filename: /var/www/libraries/Extras.php
Line Number: 1842
-
same...something to do with the new "Favorite vendors" feature perhaps?
-
Super weird. It does it for me too. But apparently it's only a problem on the front page. You can navigate the site just fine as long as you avoid the front page.
-
wtf im getting that too, but its not everything
-
A Database Error Occurred
Error Number: 1146
Table 'market.favorites' doesn't exist
SELECT COUNT(*) AS `numrows` FROM (`favorites`) WHERE `type` = 'user' AND `object_id` = '1444' AND `deleted` = 0
Filename: /var/www/libraries/Extras.php
Line Number: 1842
My guess would be that the table market.favorites doesn't exist, and this is causing problems with the code on line number 1,842 in the Extras.php file
-
I have URLs for a couple vendors but they take me to the error message.
-
Line Number: 1842
My guess would be that the table market.favorites doesn't exist, and this is causing problems with the code on line number 1,842 in the Extras.php file
I'm slow. Mine is only at Line 67.
-
I first got to the login page, then got the error. I tried going to SR through Wikipedia.org, and now I'm getting the database error on the index page. I can't even see the login! What's going on? I hope everything's OK. I have a lot of money in my account. :-\
-
Looks like somebody needs a DBA..
Can anyone navigate the listings by going directly to the various categories? If so, what are the URLs? Would be a decent workaround for now..
-
I have a couple of seller's URLs saved, and trying to go directly to those URLs is currently bringing up the same error. I'm sure it will be fixed in good time though.
-
ugh, the 'deleted' shit is what worries me. Hope all is well...
Hey everyone, hope your all having a good evening otherwise:)
-
yea no fun when the SR isnt workin right
-
I was logged into the SR when it happened, i was only able to navigate between my account and balance information. Once logged out it has the same message on the login page.
DPR just announced the new vendor favorites and the missing favorites table mentioned in the message might mean a quick code fix.
-
i logged off then logged back on and it seems to be working for me again
-
Interesting switch: «AND `deleted` = 0»
So... SR never actually deletes anything from DB and uses a switch instead to hide it? Nice to know...
-
All is well again captain. Thanks for the quick fix.
-
He STILL hasn't turned off showing database errors? I so do not trust this site.
-
Ok, then stop coming. I can't imagine being DPR at times like this, making great changes and running this paradise, and people are still going to give him shit no matter what. He goes out of his way constantly to make improvements and really listen to the feedback of the community, but the site showing database errors just has to be the worst thing ever.
-
I think that's not what he meant, maybe a wrong choice of words, but this site also shows that runs Apache 2.2.14 under Ubuntu with display_errors = 1 and that nothing is actually being deleted from DB when you order it to do so...
This means a poorly hardened server for Tor environment, unless you have no concern for your data, that is.
***PARANOIA ALERT BEGIN***
Let me put this to the worse scenario; let's put to option that an exploit is found for Apache 2.2.14 which allows an attacker to inject and use it as proxy, so he could make SR to fetch www.fbi.gov/sr_hook.txt, Apache would go fetch that file out of Tor dropping SR's real IP Address and, therefore, location.
Also I do prefer to be sure that when an order is put in transit my address is blanked out of the DB rather than just a fag switch saying "deleted = 1" or when or if this goes down we go along.
***PARANOIA ALERT END***
So yes, DPR has to take some shit and fix these potential holes before shit gets serious, don't you think?
-
He STILL hasn't turned off showing database errors? I so do not trust this site.
well he should probably turn that off..
-
Ok, then stop coming. I can't imagine being DPR at times like this, making great changes and running this paradise, and people are still going to give him shit no matter what. He goes out of his way constantly to make improvements and really listen to the feedback of the community, but the site showing database errors just has to be the worst thing ever.
You clearly have no idea about computer security and how helpful it is to an attacker to know the database structure. And you may note that I have never used the SR marketplace for reasons like this, but I enjoy the community.
-
i think we should all assume sr is already rooted and use our own defenses against it... technically u should be able to use sr without ever leaking personal information to sr itself. gpg + tor isolated vms etc.
-
i think we should all assume sr is already rooted and use our own defenses against it... technically u should be able to use sr without ever leaking personal information to sr itself. gpg + tor isolated vms etc.
The only way to treat something that you think is secure is to treat it like it's compromised. ;)
-
Interesting switch: «AND `deleted` = 0»
So... SR never actually deletes anything from DB and uses a switch instead to hide it? Nice to know...
not nice to know that SR didn't know to not leave error reporting on :(
-
I think it is really apparent even before this that SR doesn't know that much about running a hardened server or writing security critical code. Thing is people should be managing their own security and not care if the server is compromised, so does it really matter? Also he knows enough to configure a tor hidden service and he is using linux, so it probably isn't a horrible failure security wise.
-
I think that's not what he meant, maybe a wrong choice of words, but this site also shows that runs Apache 2.2.14 under Ubuntu with display_errors = 1 and that nothing is actually being deleted from DB when you order it to do so...
This means a poorly hardened server for Tor environment, unless you have no concern for your data, that is.
***PARANOIA ALERT BEGIN***
Let me put this to the worse scenario; let's put to option that an exploit is found for Apache 2.2.14 which allows an attacker to inject and use it as proxy, so he could make SR to fetch www.fbi.gov/sr_hook.txt, Apache would go fetch that file out of Tor dropping SR's real IP Address and, therefore, location.
Also I do prefer to be sure that when an order is put in transit my address is blanked out of the DB rather than just a fag switch saying "deleted = 1" or when or if this goes down we go along.
***PARANOIA ALERT END***
So yes, DPR has to take some shit and fix these potential holes before shit gets serious, don't you think?
I would hope that the web server is in some sort of jail and doesn't have any ability to send data outside of Tor (or to know any external IP addresses associated with the server).....but I doubt that this is the case ;)
anyway your paranoia alert was stupid because it pretty much boils down to
"let's say a vulnerability is found and somebody exploits it!!!"
well no shit sherlock ;P
lets say that the earth blows up suddenly oh noez we r all ded
SR really should be changing server location frequently though. I think that is the single biggest thing that he could do for the security of this site and the people that use it. Feds gon trace a hidden service eventually if they have not yet figured out how to do it (which kind of amazes me), but the process is going to take time...so the best thing is to constantly be changing servers location in the hopes that you change server location faster than the feds can trace a hidden service. But everyone knows if you just leave a Tor hidden server in one spot that eventually it is going to be traced.
-
Change the server location? ;D
Love the theory, but Tor doesn't work that way, you never connect to the server, you connect to the meeting point. Tor is actually too well designed to be much of a concern, just some apps can drop the real IP and be a problem.
-
Interesting switch: «AND `deleted` = 0»
So... SR never actually deletes anything from DB and uses a switch instead to hide it? Nice to know...
I remember him saying way back when, at least for messages, they don't actually get deleted from the DB until both the sending and receiving party either delete them manually or they expire after 3 months.
Of course, who knows. But that would at least be consistent with seeing the "and deleted = 0" qualifier.
-
Change the server location? ;D
Love the theory, but Tor doesn't work that way, you never connect to the server, you connect to the meeting point. Tor is actually too well designed to be much of a concern, just some apps can drop the real IP and be a problem.
Actually hidden services can be traced up to their entry guards with this attack:
http://freehaven.net/anonbib/cache/hs-attack06.pdf
and then deanonymized by anyone who compromises one of the guard nodes (easily done with a court order if they are in USA, still easily done if they are in a foreign country via a MLAT although might take a bit longer).
Hidden server should change its location periodically
-
You should start to read the articles about vulnerabilities starting by the date, and that document (and outdated attack) dates from May 2006.
That attack could succeed out of a small Tor network, as it states: «It is currently the largest anonymity network in existence, with about 450 server nodes».
ATM your server keeps "changing location" at random time by itself. The only traffic analysis was if the network was small enough for you to be able to spot it at the DS, like IP1 online last 24h, IP2 online last 8h offline now for 1h; IP1 is the server, IP2 is the client... but the network is way too big for it.
-
You should start to read the articles about vulnerabilities starting by the date, and that document (and outdated attack) dates from May 2006.
That attack could succeed out of a small Tor network, as it states: «It is currently the largest anonymity network in existence, with about 450 server nodes».
ATM your server keeps "changing location" at random time by itself. The only traffic analysis was if the network was small enough for you to be able to spot it at the DS, like IP1 online last 24h, IP2 online last 8h offline now for 1h; IP1 is the server, IP2 is the client... but the network is way too big for it.
this attack is out dated in what sense? They added entry guards so now the entry guards are traced instead of the actual server. Before this was published the actual hidden server could be traced to its IP address with this attack. Now it can be traced to its entry guards, which can be monitored to trace to the hidden server once they are identified.
-
You can use an entry guard or log directly to DS, actually I think EG to be a low not a surplus because, as you said, it can be seized and if just few clients connect there they, the clients, become too exposed.
What makes the network anonymous is its size and what makes that attack outdated is the same reason why 51% bitcoin attack isn't an issue; you can't possibly control enough nodes to do it.
-
You don't need to own many nodes to do this attack. You can force a hidden service to open an arbitrary number of circuits. If you own even a trivial amount of nodes eventually one of the +1 circuits you can force a hidden service to make will have a node that you own be part of that circuit. This attack is still entirely effective for tracing hidden services to their entry guards.
-
No you can't... not to the entry guard, not the ip, not to nothing at all. It's a silly theory, nothing else, because the RV isn't 1 node away of the entry guard and you can't possibly lure Tor to choose your node over a possible another.
They made it with half-dozen nodes but if Tor was half-dozen nodes long nobody in that network would be anonymous for starters.
-
Yip, SR really shouldn't have errors visible, giving error feedback is a great way to ensure everyone's records will/have been compromised.
Making them hidden doesn't fix potential holes, but it sure as hell makes them a whole lot harder to exploit.
-
No you can't... not to the entry guard, not the ip, not to nothing at all. It's a silly theory, nothing else, because the RV isn't 1 node away of the entry guard and you can't possibly lure Tor to choose your node over a possible another.
They made it with half-dozen nodes but if Tor was half-dozen nodes long nobody in that network would be anonymous for starters.
blah why even waste my time to argue with your stupid ass what the fuck is an RV even for starters, you use a lot of acronyms that I have never heard before , and you brute force the hidden service to make it open a ton of circuits and your nodes will be used on some of them, and the attack is still entirely feasible against the network, you are the one who has no idea what you are talking about so fuck off calling it a silly theory lol you are the silly one to try to argue about things you have zero understanding of
edit: looked up rv, you might want to just say rendezvous instead of use terminology that is not ever used in any of the literature
and you of course are not understanding how this attack works. Yes my Tor client opens a circuit to a rendezvous point when it communicates with the Tor hidden service. Yes. The hidden service also opens a circuit to the rendezvous. A hidden service opens a new circuit for every single client that connects to it. A malicious client can make a hidden service open as many new circuits as it wants to as many rendezvous nodes as it wants. The hidden service uses new nodes for its circuits. If the malicious client that forces it to open arbitrary circuits has some nodes on the network, eventually the hidden service is going to use those nodes on its path to the rendezvous. Now the malicious client sends the hidden service packets with self created timing delay pattern and at its malicious nodes it looks for this pattern to identify traffic that is being routed to the hidden service from the malicious client. Doing this for long enough (not that long) traces the fucking hidden service as soon as the first node the actual server sends data to is owned by the attacker. Tor sort of tried to fix this by adding entry guards, nodes that Tor always tries to enter traffic through if they are up selected from a much smaller pool of randomly selected nodes (3 randomly selected nodes from the total list of nodes with the entry flag, changed every 30 to 60 days by default). Unfortunately this attack is still perfectly fucking fine for tracing the hidden service to its entry guards at which point a simple trap and trace order (with a MLAT if required) is enough to deanonymize the hidden service.
Please try to read the fucking paper before making me waste my time to type an abstract of it
-
You seams to miss the point totally.
1st no system is anonymous if lacks users enough. If Tor had 5 users and one does something to put a LEA in his trail, all they would need is to sort out the 4 innocent guys. Reason why i2p and freenet are lesser anonymous than Tor.
Then, the traffic analysis of Tor is almost impossible. Even in the paper you showed they come out with a pattern crossing 6 packets sent with 7 packets received... the only way they know those 6 packets are theirs is because they sent them in the first place and knew what they were looking for as there's no way also to tell if the first node is the first node, it leaves the server encrypted already and the server may be a relaying traffic, requesting or serving... who knows?
Bottom line, your fucking "abstract" is so outdated and long shot that doesn't even figure in the list of Tor reliable attacks. To not mention you take LEA as some sort of Chinese triad or mobsters not bothering to tackle as many innocent in the way to get through... like apprehending servers at random despite they're the server or simple relays.
The most reliable attack to «deanonymize» an user or server is to use an application than can do a parallel non-Tor connection to somewhere.
The second most reliable was made by a French guy at 2011 but requires that you control 1/3rd of all nodes and will allow you to decrypt some layers. Still not that reliable, as Feds tried this method in the past with a redundant failure.
-
Can not tell if you are trolling or just stubborn and retarded. I am really tired of trying to educate people about Tor today, particularly people who you would think would know better (not you, I don't expect you to know jack shit). Traffic analysis of Tor is not almost impossible. All you need to do to deanonymize a Tor user is be able to see traffic from them and/or to them enter and exit the network (or in the case of a hidden service, reach its final destination, the hidden service server).
observing 6 packets at multiple points in the Tor network is more than enough to link them together, regardless of who sent them. This is true of all low latency networks that don't use some latency blending protocol like Alpha or Tau mixing. Actually, observation of a single packet at two points on a circuit is all that is required to break Tor anonymity: www.blackhat.com/presentations/bh-dc-09/Fu/BlackHat-DC-09-Fu-Break-Tors-Anonymity.pdf (Single cell is enough to break Tor's anonymity) although to be fair the author of that paper is just a sensationalist who pretty much re-invented the timing attack.
Regardless, yes the attacker is the one who sends the packets in this attack. Remember, to deanonymize a Tor user you only need to observe traffic to them entering the network and arriving at them also. Well, if you send packets to a hidden service you can certainly watch them enter the network. Now all you need to do is watch them arrive at their destination! Okay, now the next part of the attack is being able to watch the packets reach the destination, in this case the hidden service. How to do this?!?!
What you do is this. Every time you connect to a hidden service you tell it a rendezvous node to build a circuit to. A client can tell a hidden service to connect to as many damn rendezvous nodes as it wants, and the hidden service builds a new circuit to the rendezvous node. So what you do is add some nodes to the network, this is called a sybil attack and it is the basis for all other active attacks. Now you tell the hidden service to build an arbitrary number of circuits to an arbitrary number of rendezvous nodes. Each of these circuits consists of nodes selected from the Tor network. Now, since you own some of the nodes on the Tor network, and since you can force the hidden service to open as many new circuits as you want, eventually some of these newly created circuits are going to use nodes that you own! The only likely exception is the entry nodes of the hidden service, because it selects three nodes once every month to two months, and always enters traffic through these nodes if they are up. So unless it selects one of your nodes as its entry guards, it will never enter traffic through your nodes.
Now from the client you send a stream of packets to the hidden service down all of the opened circuits you have built to it. You introduce a specific interpacket timing pattern to your stream and now you monitor at all of your Tor nodes looking for packet strems that fit this pattern. Once you detect the pattern at one of your sybil nodes you know that they are on the path to the hidden service. Now there are a few things you can do. First of all, you own the rendezvous node and every Tor node can see the IP address of its direct neighbors. So if you detect the pattern you introduce, the first thing you can do is see if the pattern came from the rendezvous node you selected. If it did, you know that the node that detected the pattern is the third node from the hidden service, which directly connects to the rendezvous. If it didn't you know that the node is either the middle node or the entry guard of the hidden service. If the node you detect the traffic pattern in forwards that traffic on to a known Tor relay IP address, but doesn't get the traffic from the rendezvous node, you know that the node you are sending traffic to is either the hidden service and that it is a Tor relay, or that it is one of the entry guards of the hidden service. If the node you detect the traffic pattern in doesn't get the traffic from the rendezous and forwards it on to an IP address that is not a publicly listed Tor relay, you know that you are either forwarding the traffic to the hidden services IP address and that you are one of its entry guards, or you know that you are sending the traffic to a bridge that the hidden service is using as an entry guard.
Now there are a few things you can do if you determine that you may be the entry or middle node on the hidden services circuit. If you know you are either sending traffic to the hidden service IP or a bridge IP, you can try to make a bridge connection through the IP address and see if it treats it as a bridge connection. If it doesn't, you know it is the hidden services IP, if it does you know it is a bridge and the hidden service is using it as an entry guard. If you know you are the middle node and want to see if the hidden service is the relay you forward traffic on to or if it is an entry guard, there are a few things you can do. First of all, you can DDOS the node and see if there is a down time correlation between it being DDOSed and the hidden service going down. Or you can just keep doing the attack for a period of time and then use statistical analysis on the resulting dataset to come to a conclusion on if the hidden service is the relay or if the relay is an entry guard.
In either case doing this attack will quickly trace either the hidden service, if you own one of its entry guards, or all of its entry guards, at which point you can order a trap and trace on it (via MLAT if required) to get its IP address. Or if you are not an attacker powerful enough to do legal passive analysis, there are plenty of other things you can try to do to get around the entry guard. You could try to hack the entry guards. You could simultaneously DDOS the entry guards forcing the hidden service to select three new ones, and keep doing this until you run out of bandwidth to DDOS with or the hidden service selects one of your nodes as an entry guard. Or you could locate the entry guard and illegally tap it. Or you could social engineer the person who runs the entry guard into giving you access to it. Or you could blah blah blah. Harder for an attacker who can't legally order passive monitoring, but not impossible.
Bottom line, your fucking "abstract" is so outdated and long shot that doesn't even figure in the list of Tor reliable attacks. To not mention you take LEA as some sort of Chinese triad or mobsters not bothering to tackle as many innocent in the way to get through... like apprehending servers at random despite they're the server or simple relays.
The thing is they can get a positive identification of the hidden services IP address before a single server is seized.
Would you like to keep arguing with me and look more an more retarded with every post, or do you just want to admit that you were wrong (of course not, people like you never admit they are wrong they just get more and more retarded). Fair warning: I have been studying traffic analysis for several years now, if you have not then chances are you are not going to be proving me wrong.
But by all means if you want to live in some fantasy world where Tor is super anonymous and totally impossible to pwn go right on ahead, you will be in good company with the vast majority of its users and probably 98% of the people who would bother trying to attack it if they thought it was even remotely possible. Unfortunately, you guys live in a fantasy world. As far as anonymity goes Tor is a toy, the real powerful networks barely ever get further than mathematic formulas and whitepapers , largely because they require significant time delays and everybody wants low latency.
-
I agree that services can be found within TOR, but it is much more difficult than just tracing 6 packets and find their intersection. Tracing 6 TOR packets will just give the relay that they each packet enters the TOR network. After this what is required is to trace from the relays, through how many levels of relays/anonymisers they have, until they arrive at the server. This would be extremely difficult because you would only have limited access inside the TOR network, but with adequate resources/tools it is not impossible.
-
I agree that services can be found within TOR, but it is much more difficult than just tracing 6 packets and find their intersection. Tracing 6 TOR packets will just give the relay that they each packet enters the TOR network. After this what is required is to trace from the relays, through how many levels of relays/anonymisers they have, until they arrive at the server. This would be extremely difficult because you would only have limited access inside the TOR network, but with adequate resources/tools it is not impossible.
That is called a correlation not an intersection, two totally different sorts of attack. And yes it really is that easy. Researchers have done this attack against the live Tor network and traced hidden services in a matter of minutes to days prior to entry guards. Now entry guards can be traced in a matter of hours to days. When you can force the server to open as many circuits as you damn well please, it really isn't going to take that long for some of your nodes to be on the circuit enough times to enumerate the entry guards. Give me 12 high bandwidth VPS for a month and I will trace any hidden service you want to its entry guards.
from the paper
In this paper we demon-
strate attacks (not simulations) on the deployed Tor
network that reveal the location of a hidden server.
The attacks are cheap and fast: they use only a sin-
gle hostile Tor node and require from only minutes
to a few hours to locate a hidden server.
From the experimental results we can also con-
clude that we need far less data to pinpoint the lo-
cation of the Hidden Server than we gathered. A
rough estimate is that within the order of an hour or
two we should have a positive match of the location
of the hidden service using the predecessor attack.
hmm lets see how entry guards changed the attack
Experiment - Attacking Entry Guard Nodes:
Letting the Hidden Service use three permanent,
preferred entry guards we found that these nodes
combined represented all identified connections
through Alice’s node, as shown in Table 2. A
quite unexpected result, but caused by the imple-
mentation feature in Tor described earlier: we were
never Node 3, only Node 2 (Node 1 being the entry
guard).
As in our previous experiments, identifying the
entry guard nodes through our attacks never took
more than a few hours.
We have demonstrated that an attack with one
compromised node in the anonymity network takes
only minutes if the service is located at a client, or a
couple of hours when located on a server node. By
using two nodes in the network it only takes min-
utes to find the Hidden Server regardless of where
it is located.
Damn I even remembered this paper wrong, I thought it had taken them days to weeks to trace the hidden services and that they had used multiple nodes, not minutes to hours with a single node. And entry guards were the defense to this attack, and now the entry guards are traced in minutes to hours instead of the hidden service itself. Even with the significant increase in Tor network size following this attack (a few times as large) it isn't going to take longer than a week at the max to do this same attack.
Really if you guys want to argue with linked citations, quotes from traffic analysis experts and someone who has been studying this shit for years, go right ahead and knock yourselves the fuck out. What if I get a quote from one of the Tor devs saying that I am right will you believe me then? Cuz I already know that they all know this attack will trace entry guards without any problems. They also all know that FBI can trap and trace the shit out of the entry guards if they are in USA, and MLAT the shit out of them if they are in any other country, to deanonymize the hidden service. In the #tor IRC Arma, the person who implemented Tor in the first place, said that hidden services are fucked, and that is more or less a direct quote.
Please tell me geniuses what more do you need to convince you? If cited papers from world experts, full of technical details, including how this attack was carried out live against the Tor network, plus the words of someone who has been studying traffic analysis for years, plus the words of the person who implemented the fucking network in the first place, are not enough to convince you that you don't know what the hell you are talking about, then please tell me what it will take. Put up a fucking hidden service and buy me some VPS nodes and I will tell you its entry guards, will that convince you?
If you don't even know how to fucking spell *Tor* then why are you acting like you know more about it than I do?
People learning misinformation from idiots like you guys talking about shit you heard from other idiots talking about shit they heard from other idiots talking about shit they heard from DISINFO agents is why there are so many people who think Tor hidden services offer protection from anything other than Joe Blow putting a complaint in to a sites hosting provider. Actually that is going too far, it can also protect substantially from someone who can add nodes to the network but not order nodes on the network to be monitored at their ISPs after the node that has direct contact with the hidden service is identified. Entry guards boosted it up from 'Joe Blow' not being able to pwn it to 'Someone with a moderate level of computer knowledge and a little bit of money to spend on it, who gets a bit of bad luck and doesn't spend much effort on it' not being able to pwn it without a bit of extra work. It is still fully in the 'law enforcement can pwn it with little work' and 'someone with a moderate level of computer knowledge, a bit of money, a bit of luck, and a significant amount of effort, can still probably manage to fully pwn it' category.
I know I can trace hidden service to its entry guards with little work, and I know if I was law enforcement I could then order the ISP to give me the logs from the entry guard (and start logging if they are not already), since trap and trace can be done without a warrant if LE can prove that it directly relates to a criminal investigation. Guess what being able to technically prove that a trap and trace will deanonymize a targeted hidden service is more than enough legal justification to use one for the literally few seconds required to obtain the hidden services real IP address after its entry guards are identified. And if you think entry guards being outside of USA is going to help at all look up MLAT I don't have time to explain every single detail of every little thing over and over to people who are content to argue in the face of overwhelming evidence, seems like a complete waste of time to me.
Then again I shouldn't be so hard on Tor, I am not certain if the feds realize how easy it is to trace hidden services either, their traffic analysis operations are almost entirely focused on spidering P2P networks with (extremely expensive) simple spidering programs looking for CP files. Then again I wouldn't be surprised at all if they are already passively monitoring all of the interesting hidden services, with 50% of a correlation attack already done, waiting for clients to use their poisoned entry guards to deanonymize themselves. With out proper intelligence it is impossible to know their true capabilities, especially at the level where they start trying to keep the information secret / compartmentalized (for example, not something they give a shit about with the P2P spidering, the entire name and technical details of operation fairplay against the CP traders can be discovered with simple google searching and digging around academic articles on law enforcement oriented traffic analysis......but if there were an ongoing traffic analysis operation against Tor users the average agent would probably not even be aware of it....and a lot of published LE documentation shows that they struggle with much easier things than Tor, but who knows maybe it is misinfo to an extent, and who knows about the documentation that has a classification level stamped on it). Regardless I would have to assume that at least a significant number of people who would go into FBI traffic analysis would independently learn about ways to trace hidden services (I had a copy of a cyber career path guideline for FBI that shows their educational structure and if I am remembering correctly they started training agents who selected this specialty about traffic analysis after 8 years worth of other general computer and computer forensic / security / etc training). Who knows what they know, but I know that they can pwn Tor hidden services and we should assume that they know they can too.
-
Few points.
- You've convinced me that tor isn't as secure as everybody thinks.
- I still think we'll see the hidden CP sites get busted first.
- I think the level of sophistication required to conduct the attacks you refer to is only possessed at an institutional level by agencies who only concern themselves with issues of national security.
- I think the law enforcement is more concerned with funding and headlines than actually stopping clever people from buying drugs. They will continue to "attack" whoever is dumb enough to wave their dicks around and get caught. I would have to think (admittedly made up statistic to follow) that 90% of the busts that happen with regards to narcotics are from somebody getting busted and ratting somebody out. After that, 9% are from people who make stupid mistakes, and finally 1% are in the wrong place at the wrong time. When you have so many stupid drug dealers running around, it's hard to put in the effort to go after the really sophisticated ones.
Just to address what I know your first response would be, is any of that worth risking your security on? And my response would be, where does the paranoia end? Nothing is secure. Nothing. Point at something and claim it's secure, and it's only a matter of time until you're wrong. So, all we can do is evaluate risk and reward, do our best to stay as safe as possible, and it never hurts to have a few people in your pocket :)
-
kmfkewm
Let me point you your pointless fucking long trolling "I'm a noo...sorry... hacker" article and the biggest misconception/flaws/sensationalism you put there: Did you ever took a look at a fucking onion?
Let's say your IP is 1 you own 4 which happens by chance to be the rendezvous and the server is 7, at each node your packet headers will be modified, creating a new layer, by encrypting the data inflates, so instead of:
your fucking packets -> 1 -> 2 -> 3 -> 4 (your fucking packets) <- 5 <- 6 <- 7
you get:
your fucking packets -> 1 -> 2 -> 3 -> 4 (gibberish you can't understand, they don't match anything that has leave 1) <- 5 <- 6 <- 7
This is how Tor works, at each node the data is re-encrypted and changed, the headers are modified, the contents are modified, the size ain't the same anymore.
You know that your theory was used several times by FBI to try to catch those pedo sites around, don't you? Or you think you're the fucking genius who saw the light alone?!
Then you've folks who add entropy to another network weakness by doing something somewhat unsafe at Tor but much unsafer at surfacewebs these days in some countries; download torrents. They generate a huge amount of traffic in the network that could otherwise be used to trace hidden services by traffic analysis.
But still, even if Tor is safe by now, it doesn't mean in the future, near or distant, something may come up to make it unsafe, so keep using it as if it was compromised is a good way to go.
-
I didn't say you could correlate based on the actual data stream, you need to insert artifacts such as interpacket arrival patterns (or just use the patterns that naturally arise). It doesn't matter if you can't decrypt O (the packet) if you can detect the unique timing pattern between packets.
lets say you have
O----O--O-----O-------O---O-O--------O
a stream of encrypted packets that goes through multiple relays, with each relay performing decryption operations on another layer:
O----O--O-----O-------O---O-O--------O -> 1 -> P----P--P-----P-------P---P-P--------P -> 2 -> etc
Even though the content of the packets changes, the interpacket arrival characteristics are not obfuscated and they work perfectly well to determine that one stream of packets is linked to another stream of packets that was observed at another point.
by encrypting the data inflates, so instead of:
The encryption mode that Tor uses actually doesn't increase data size with additional layers of encryption.
your fucking packets -> 1 -> 2 -> 3 -> 4 (your fucking packets) <- 5 <- 6 <- 7
you get:
your fucking packets -> 1 -> 2 -> 3 -> 4 (gibberish you can't understand, they don't match anything that has leave 1) <- 5 <- 6 <- 7
You don't need to be able to understand it, you can correlate the stream based on interpacket timing characteristics. Tor is low latency it doesn't hide that pattern and it has been proven in so many different papers that I can give you a billion citations if you want.
This is how Tor works, at each node the data is re-encrypted and changed, the headers are modified, the contents are modified, the size ain't the same anymore.
The size of the packets actually stay the same because Tor uses padding. Sizes staying the same is a good thing. However the size of the stream doesn't change. Also the interpacket arrival times don't change.
You know that your theory was used several times by FBI to try to catch those pedo sites around, don't you? Or you think you're the fucking genius who saw the light alone?!
It ain't my theory its an attack that some academics came up with. I doubt that FBI tried to use this attack to catch pedo sites simply cuz if they did they would have traced them all. Another possibility is that they have traced them all and wait for you to use a poisoned entry node to deanonymize you when you visit them. Another possibility is that they don't care because they already have their man power exhausted from following up on IP addresses detected trading CP on public P2P networks. e
No I did not see the light alone but a shockingly large percentage of people seem to be incapable of understanding this attack (or anything else) even after they read the damn technical paper on it. I think anyone who downloaded that .pdf has seen the light, altho if they actually took anything from that encounter is a different question :P.
Then you've folks who add entropy to another network weakness by doing something somewhat unsafe at Tor but much unsafer at surfacewebs these days in some countries; download torrents. They generate a huge amount of traffic in the network that could otherwise be used to trace hidden services by traffic analysis.
Huh?
But still, even if Tor is safe by now, it doesn't mean in the future, near or distant, something may come up to make it unsafe, so keep using it as if it was compromised is a good way to go.
Yes it really is best to assume that Tor can be compromised. It is actually known that Tor can be compromised, but it is best to assume that the attacker who you worry about the most can pwn it.
- You've convinced me that tor isn't as secure as everybody thinks.
Indeed most people think Tor is a lot more secure than it really is.
- I still think we'll see the hidden CP sites get busted first.
I doubt they take the hidden CP sites down they will use them as honeypots first.
I think the level of sophistication required to conduct the attacks you refer to is only possessed at an institutional level by agencies who only concern themselves with issues of national security.
It really doesn't require much skill at all, you simply need to read a whitepaper and know how to work with a programming language, and have a spare node or two to add to the network.
- I think the law enforcement is more concerned with funding and headlines than actually stopping clever people from buying drugs. They will continue to "attack" whoever is dumb enough to wave their dicks around and get caught. I would have to think (admittedly made up statistic to follow) that 90% of the busts that happen with regards to narcotics are from somebody getting busted and ratting somebody out. After that, 9% are from people who make stupid mistakes, and finally 1% are in the wrong place at the wrong time. When you have so many stupid drug dealers running around, it's hard to put in the effort to go after the really sophisticated ones.
I don't think it is good to assume you are secure because nobody is there to attack you. LE job is bust people who buy and sell drugs.
Just to address what I know your first response would be, is any of that worth risking your security on? And my response would be, where does the paranoia end? Nothing is secure. Nothing. Point at something and claim it's secure, and it's only a matter of time until you're wrong. So, all we can do is evaluate risk and reward, do our best to stay as safe as possible, and it never hurts to have a few people in your pocket :)
Yup yup.
-
Pissing contest aside, very interesting discussion guys. The thought and concern brought fourth is appreciated greatly.
-
kmfkewm
Let me point you your pointless fucking long trolling "I'm a noo...sorry... hacker" article and the biggest misconception/flaws/sensationalism you put there: Did you ever took a look at a fucking onion?
Let's say your IP is 1 you own 4 which happens by chance to be the rendezvous and the server is 7, at each node your packet headers will be modified, creating a new layer, by encrypting the data inflates, so instead of:
your fucking packets -> 1 -> 2 -> 3 -> 4 (your fucking packets) <- 5 <- 6 <- 7
you get:
your fucking packets -> 1 -> 2 -> 3 -> 4 (gibberish you can't understand, they don't match anything that has leave 1) <- 5 <- 6 <- 7
This is how Tor works, at each node the data is re-encrypted and changed, the headers are modified, the contents are modified, the size ain't the same anymore.
BTW Have you ever looked at what you are calling an onion? There are not 7 hops there are 6, and the client always selects the rendezvous which can be a node it owns.
Client <-> Entry Guard <-> Middle Node <-> Rendezvous <-> Servers Final <-> Servers Middle <-> Servers Entry <-> Server
The client can force the server to open circuits to as many rendezvous as it wants
Server <-> Entry(a-c) <-> Middle1 <-> Final2 <-> Malicious RendezvousA
Server <-> Entry(a-c) <-> Middle3 <-> Final4 <-> Malicious RendezvousB
Server <-> Entry(a-c) <-> Middle5 <-> Final6 <-> Malicious RendezvousC
Server <-> Entry(a-c) <-> Middle7 <-> Final8 <-> Malicious RendezvousD
Server <-> Entry(a-c) <-> Middle9 <-> Final10 <-> Malicious RendezvousE
Server <-> Entry(a-c) <-> Middle11 <-> Final12 <-> Malicious RendezvousF
Server <-> Entry(a-c) <-> Middle13 <-> Final14 <-> Malicious RendezvousG
etc
If you own node # whatever (and even faster if you own multiple nodes) you are going to have the hidden service use it on one of the circuits it builds eventually. And you can force a hidden service to open and close as many circuits as you please, and send data for any of these circuits. I could have SR server open a thousand new circuits for me, that means it is going to have circuits leading to it with up to 2003 unique nodes being used (of course nodes can be re-used in different circuits, and probably will be, so it will not be that high most likely). And then I can send a little data through all of them, close all of them and then make it open a thousand new circuits. If SR stops opening circuits on demand it is DOSed, it can't tell my circuit creation request apart from anybody elses since we are all anonymous. And if it re-uses multiple circuits for multiple clients there will be serious linkability attacks to start worrying about.
Each of these circuits use an entry node from the smaller selected pool of 1-3 guards, but the middle and final node are taken from the total selection available in the Tor network, and each circuit created uses different nodes selected from the total available consensus. An attacker who owns some of the nodes on the network is obviously going to own some of the nodes on a circuit to the hidden server after they force it to create an arbitrary number of circuits to rendezvous points.
Now they send this pattern to the server via interpacket time delays
O-----O--O------O-O-O----O--------O----------------O-O
Even though O changes to P changes to J etc at each hop, the interpacket timing characteristics are not modified so the attacker can detect this stream of packets at any of their nodes they happen to pass through. They know they are either final, middle or entry.
Server <-> Entry <-> Middle <-> Final <-> Malicious Rendezvous
They can determine if the are final since they know the rendezvous IP address.
They can determine if they are potentially middle if they get data from a Tor relay IP address and send data to a Tor relay IP address (although it is also possible that they are entry guard and the hidden service is a relay)
They can determine if they are potentially entry if they send data to an IP address that isn't a public Tor relay (although they could also be middle and the hidden service uses a bridge for entry guard). If the hidden service uses a bridge for entry guard, it can be determined by trying to treat the identified non-Tor IP address as a bridge. If acts as a bridge, then it is the entry guard for the hidden service, if it does not then it is the hidden service and you are the entry guard.
If you never send data to a non-Tor IP address from any of your nodes, that means the hidden service is not using a bridge and that one of the IP addresses you eventually send data to either belongs to the hidden service or to one of its entry guards. You could just do the attack for long enough and see if three distinct IP addresses stick out, if so they are the hidden services entry guards. If four IP addresses are identified three of them are the entry guards and one of them is the hidden service, but if this happens one of the identified entry guards should be one of your malicious Tor nodes so you will be able to deanonymize the server. Otherwise you have traced it to its entry nodes and now you just need to pwn one of them to deanonymize the server (again, the best route for this would be a trap and trace, as far as LE level attacker goes).
-
this time is really: tl;dr
you don't get 0---0---0000---0 --> node --> 1---1---1111---1
you get:
0---0---0000---0 --> node --> -11-11--111111-111-1111---1
this means: more data than what you sent, you can't create a TCP pattern because:
1) Data inflates being encrypted
2) Other people is using those nodes
And one thing you got wrong; Tor does NOT uses necessarily 3 + 3 hops.
Here: http://thesprawl.org/research/tor-control-protocol/
have a reading on how to change and control Tor circuits.
-
Tor uses encryption mode that does not increase data size with encryption. No Tor can use up to 8 hops if you make changes to it, but it has limitation built into the network itself though preventing longer circuits. The pattern can be picked out even with others using the nodes. I don't waste any more time to argue with you about this, go do some research or keep living in your fantasy world makes no difference to me. I am fine knowing that all published research papers agree with what I say and your opinions come from some incorrect 'facts' that you have made up in your own head.
-
The only encryption algo that doesn't change data size is xor'ing. Don't tell me you think Tor XOR's data...
Whatever, I'm tired of your trolling and very long gibberish articles based on papers made by people that probably made SR ran out of MDMA stock. I'll leave you to troll alone.
-
Tor uses AES in CTR mode, keystream blocks are XORed with the plaintext to get the resulting ciphertext. https://en.wikipedia.org/wiki/Keystream
....so yes I guess I do think that Tor XOR's data????
Hm this paper looks interesting, from december 2011.
http://freehaven.net/anonbib/cache/acsac11-backlit.pdf
Traffic watermarking is an important element in many network se-
curity and privacy applications, such as tracing botnet C&C com-
munications and deanonymizing peer-to-peer VoIP calls. The state-
of-the-art traffic watermarking schemes are usually based on packet
timing information and they are notoriously difficult to detect. In
this paper, we show for the first time that even the most sophisti-
cated timing-based watermarking schemes (e.g., RAINBOW and
SWIRL) are not invisible by proposing a new detection system
called BACKLIT. BACKLIT is designed according to the obser-
vation that any practical timing-based traffic watermark will cause
noticeable alterations in the intrinsic timing features typical of TCP
flows. We propose five metrics that are sufficient for detecting
four state-of-the-art traffic watermarks for bulk transfer and inter-
active traffic. BACKLIT can be easily deployed in stepping stones
and anonymity networks (e.g., Tor), because it does not rely on
strong assumptions and can be realized in an active or passive mod-
e. We have conducted extensive experiments to evaluate BACK-
LIT’s detection performance using the PlanetLab platform. The
results show that BACKLIT can detect watermarked network flows
schemes, such as RAINBOW and SWIRL with high accuracy and few false positives.
-
CTR mode:
https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29
There you go, it adds a counter to each block, the counter is added data (not existing within the initial packet) so the packet inflates or, if full, generates more packets. It's not a huge inflation, a few bytes only, but enough for any pattern-looking system to fail.
Now, that new analysis, yes, is a concern to Tor, specially if ISP's start to do it. Currently ISP's already hook you into some SNMP traps and thus can't read through Tor data, can know you're using Tor for... something.
A good cloak would be to set up a bridge relay along with the HS, it may give the idea to someone attacking the network that you're a relay and not the HS... or make him jump to conclusions and assumptions faster.
-
The 'new analysis' is a technique for detecting packet streams that have had interpacket timing patterns intentionally added....not really a worry for Tor. The counter is XORed with the keystream block, and then the result of that is XORed with the plaintext to get the ciphertext, so there is no increase in size.
You really are either entirely clueless and refuse to admit you are wrong (so many people like this!) or you are a troll.....