Researcher finds Tor exit node adding malware to binaries(threatpost.com)
threatpost.com
Researcher finds Tor exit node adding malware to binaries
http://threatpost.com/researcher-finds-tor-exit-node-adding-malware-to-binaries/109008
9 comments
"As of April 2013 this list is no longer being maintained".
Although there's an alternative mentioned in the document.
Although there's an alternative mentioned in the document.
Yeah, they stopped publicly stating they know who's naughty and who's nice, which is probably useful in avoiding playing whack-a-mole with someone determined to cause trouble. Then again, I imagine that a knowledgeable attacker would just look through their logs of who's hitting their node to figure out when they've been caught.
The research being done in Karlstad analyzing Tor, which is mentioned in the article is very interesting. I recommend looking at the Spoiled Onions project:
http://www.cs.kau.se/philwint/spoiled_onions/
They identify several exit nodes that perform injection attacks etc. Monitoring Tor exit nodes for malicious behaviuour seems to be needed.
http://www.cs.kau.se/philwint/spoiled_onions/
They identify several exit nodes that perform injection attacks etc. Monitoring Tor exit nodes for malicious behaviuour seems to be needed.
Let me be clear: unless you use end-to-end encryption (e.g.
TLS) the exit node owns you. Injection, modification, even good ole fashion spoofing, all become trivial.
I really need to start a blog on this stuff. There are so many misunderstandings around Tor and "stupid Tor tricks" like this to show off.
I really need to start a blog on this stuff. There are so many misunderstandings around Tor and "stupid Tor tricks" like this to show off.
Please do.
Cool, it's on my list. But are you the Uwe Schmidt? Because if so I'd probably have to start that blogging today :)
[deleted]
Classic MITM.
Again. This shows us why we need to operate HTTPS everywhere.
Many software download sites delivers its software over http, and don't provide a checksum or provide one over http only. This is really unacceptable yet it is common practice. (Example: Skype, ZeptoJS)
Please. If you're a dev at a company that doesn't offer HTTPS download, make it happen! If your software got patched with malware, your users will blame you.
Many software download sites delivers its software over http, and don't provide a checksum or provide one over http only. This is really unacceptable yet it is common practice. (Example: Skype, ZeptoJS)
Please. If you're a dev at a company that doesn't offer HTTPS download, make it happen! If your software got patched with malware, your users will blame you.
Discussion from yesterday on the actual article and not a news rewrite https://news.ycombinator.com/item?id=8501557
Just supporting HTTPS is great, but you really want to start redirecting HTTP requests as well. For example, this HN post links to the HTTP version of a site that not only supports HTTPS, but purchased the expensive certificate that shows up more prominently.
More and more I feel that an IP standard that uses public/private key encryption needs to be a goal that is being worked towards. Ad-hoc and optional encryption through higher level protocols are not viable long term options to protect people.
We already know that if a connection can be exploited, at some point it will be.
We already know that if a connection can be exploited, at some point it will be.
Being a bit naive about Tor, what is there to prevent an exit node operator from doing some transparent traffic manipulation and injecting tracking pixels into non HTTPs webpages?
Or playing silly games like flipping all jpegs upside down?
Or playing silly games like flipping all jpegs upside down?
Things like this is why https everywhere must be a part of the solution.
The network components - your router, whoever might have gotten root on your router, your ISP, a relayer like a proxy/Tor/etc, a router on the border of your country, the target server's ISP - all of them should be treated as potentially hostile. It's not paranoia, since for all of those steps there have been well published cases where they have been actually malicious.
The network components - your router, whoever might have gotten root on your router, your ISP, a relayer like a proxy/Tor/etc, a router on the border of your country, the target server's ISP - all of them should be treated as potentially hostile. It's not paranoia, since for all of those steps there have been well published cases where they have been actually malicious.
Nesting an encrypted connection inside the traffic being routed through tor is what you would need to protect HTTP traffic from being manipulated and/or monitored by an exit node.
So instead of doing (you -> tor -> internet), do something like (you -> tor -> VPN -> internet). To be even safer do (you -> VPN -> tor ->VPN -> Internet) that way your ISP isn't aware of tor traffic and the exit node cannot manipulate requests.
Easiest way to accomplish that is with a VM. The host has a VPN connection, force route the VM through tor (with something like Tortilla) and install a VPN client on the VM as well. This requires you anonymously set up the VPN running in the VM so there is no connection back to you, of course.
So instead of doing (you -> tor -> internet), do something like (you -> tor -> VPN -> internet). To be even safer do (you -> VPN -> tor ->VPN -> Internet) that way your ISP isn't aware of tor traffic and the exit node cannot manipulate requests.
Easiest way to accomplish that is with a VM. The host has a VPN connection, force route the VM through tor (with something like Tortilla) and install a VPN client on the VM as well. This requires you anonymously set up the VPN running in the VM so there is no connection back to you, of course.
The most difficult part in your setup is to make untraceable the VPN you run after going through Tor.
The problem is: if you believe this VPN is safe / untraceable enough, why do you even use Tor in the first place ?
The problem is that you, at some point, pay the VPN, and that is very likely to be linked to your real identity somehow.
The problem is that you, at some point, pay the VPN, and that is very likely to be linked to your real identity somehow.
Paying for the VPN anonymously is possible with Bitcoin.
The reason you tunnel it all through tor is because you can't trust the VPN not to fold if the government subpoenas them. So if the data center hosting the VPN is subpoena all they can hand over are logs of tor exit nodes. If you didn't use tor, they would get your home IP and the jig is up.
The reason you tunnel it all through tor is because you can't trust the VPN not to fold if the government subpoenas them. So if the data center hosting the VPN is subpoena all they can hand over are logs of tor exit nodes. If you didn't use tor, they would get your home IP and the jig is up.
Or my configuration when I want to stay anonymous; Me->VPN->INTERNET->TOR. You have to have access to a corporate VPN though.
Another reason why 'magic anonymity box' is actually a really tricky idea. It's a heck of a trade-off.
An alarmist blog post on Hacker News.
not sure but it seems the answer is trivial.
a public api with checksum of all www files or a http header of the checksum, ie a new http method "CHKSUM /url/file" possibley the nodes should not know if they are exit nodes, and then the checksum can be compared via 3-4 nodes.
if tor then compiled a list of nodes sending viruses the bad nodes could be cleaned out.
imo it would be nice if http had this for every page also; we could then have a browser plugin to verify checksums over https+3rd party to stop mitm attacks.
a public api with checksum of all www files or a http header of the checksum, ie a new http method "CHKSUM /url/file" possibley the nodes should not know if they are exit nodes, and then the checksum can be compared via 3-4 nodes.
if tor then compiled a list of nodes sending viruses the bad nodes could be cleaned out.
imo it would be nice if http had this for every page also; we could then have a browser plugin to verify checksums over https+3rd party to stop mitm attacks.
While I doubt the downvotes are necessary, you're misunderstanding the scope of a MITM attack.
In order to mitigate a MITM you must in some way communicate with someone else. Your checksum idea either gets routed through the malicious node, which means they could change it, or it doesn't, which means you're revealing to some third party other than the exit node what it is you're browsing, and you're also telling them who you are.
In a sense, this is what https is for, by trusting certificates you know to be valid, a malicious node won't be able to see, let alone manipulate the data being sent to you (Though obviously they will see who you're talking to.)
In order to mitigate a MITM you must in some way communicate with someone else. Your checksum idea either gets routed through the malicious node, which means they could change it, or it doesn't, which means you're revealing to some third party other than the exit node what it is you're browsing, and you're also telling them who you are.
In a sense, this is what https is for, by trusting certificates you know to be valid, a malicious node won't be able to see, let alone manipulate the data being sent to you (Though obviously they will see who you're talking to.)
[1] https://trac.torproject.org/projects/tor/wiki/doc/badRelays