Using a browser in incognito mode does none of the sort. You can still enter your password into it and it can be stolen just as easily. The true solution is to only browse over HTTPS, connect to a VPN or not use untrusted networks.
Note that if I can spoof an IP address, I can send you bogus DNS replies, and send you to a web server that impersonates Google/Facebook/etc. but does not require HTTPS (unless they use the strict security header). In this case you do not get a warning, just the absence of a tiny green icon.
Only if you explicitly go to https://<site> - if you type <site> directly into the address bar you might end up at http://<site> which usually redirects you to https://<site> - but if you are on a compromised network you could get an incorrect response for the address of <site> from the DNS request and therefore go to a server that servces http://<site> with a redirect to https://<something-very-similar-to-site>. If you are not paying close attention you might just assume the green highlight in the relevant part of the address bar means all is well, where you are in fact accessing something you were not expecting but which looks like what you were expecting long enough to collect some useful details (such as your account credentials) from you.
While I can't get a cert signed for facebook.com (at least not without very expensive bribes or other human factors engineering) but I could get one for faceboolc.com easily enough and if you aren't looking closely that might fool the eye. It wouldn't catch everyone, anyone going direct to https://<site> would be warned as you suggest, but it could catch some out.
Heh, well what's the fun in that? Plus their remarks make it seem that it can somehow prevent passwords from being seen which is what got me to comment in the first place.
"If you have saved your login data on any plain-HTTP site that the attacker knows of, he can use his JS shell in the news site to load the site with the login form in an iframe, then inject another JS shell into the iframe and use that to read the password that the browser fills in."
As far as I know incognito mode wont autofill those saved credentials. I think that was the point how incognito mode prevents this kind of attack.
In this attack the user doesn't have to access those HTTP sites with stored credentials by themselves while being connected to the evil network, because the injected script does that for you behind the scenes.
You are right, I wasn't. However, the solution to this is to not use passwords with plain-HTTP sites. Incognito mode will prevent a small surface of drive-by attacks, but the bigger problem if plaintext passwords in cleartext on the wire are also terrible.
How easy is it to fully automate VPN only computer usage so that everything I do comes out of a machine at Amazon EC2 for example?
Startup idea! Make a tool that automatically tunnels your connection when you are on a public wifi. Make it open source and offer a hosted service. Also interesting if you are in a country which censors the internet. The dropbox of VPNs. For marketing you offer to write articles like this but less technical for magazines ("on Page 10 learn how easy it is for hackers to steal your facebook account and how you can protect yourself").
There are a multitude of VPN services in the market already. The generally accepted "best practice" for those with VPN service is to use it everywhere (not just on the road). When you're paying monthly, most people feel incentivized to use the service as much as possible.
I've set up VyprVPN for a couple of ultra-paranoid friends, and the whole process was very smooth and end-user friendly.
I get what you're saying, but Dropbox is not a back-up service. The distinction is that Dropbox didn't exist before Dropbox. There are unique aspects of Dropbox that were new when Dropbox was introduced.
There is nothing new or unique in what you described, with the exception (maybe) of automatic initiation of VPN services when you're on "public" wifi. I would argue that this is a differentiation of little or no consequence, because there's no reason to not use a VPN all the time.
You basically described every personal VPN provider in the market as a start-up idea.
If you really want to make it safe, I'd suggest using something with virtual networking (e.g. VMware) and configure a small VM to be your gateway. That way you can have a stripped down, firewalled configuration, with nearly no possibility that a local accident or compromise can evade your traffic policies. Otherwise, if your VPN drops, you run the risk that the system might just start sending traffic out over the public Internet (after all, it has to do so to connect to the VPN).
If you're on a Mac, it's nearly plug-and-play — I use a small menubar app called sidestep[1] that automatically tunnels over SSH, but there are also a few (Viscosity comes to mind) that work in a similar fashion with OpenVPN.
There may be similar bits available for Windows, but I haven't looked into it there in some time.
It's easier (and I'm a fan as well), but setting up an OpenVPN server with pre-shared key is very easy too. It's essentially a matter of apt-getting openvpn and writing a three line config file: http://openvpn.net/index.php/open-source/documentation/misce...
One of the advantages of using SSH is that it almost always works, even in environments (think China) that actively block detected VPN connections. SSH running on port 443 looks a lot like HTTPS.
I do not know for VPN, I use ssh. It is very simple and does not require any system administration right. Install a proxy (squid) on your Amazon EC2. Install putty if you are on windows and launch it with port forward using the option -L: putty -L 3128:127.0.0.1:3128 user@host
Add the option --proxy-server=127.0.0.1:3128 on you chrome shortcut and that's it.
And even more critical, it doesn't reroute DNS queries, the default is "don't redirect DNS" in Firefox and the change must be done through about:config there's no dialog.
Bad the default isn't different when using socks :(
If you're using a protocol that sits on TCP and you push it over SSH sitting on TCP then it's going to be TCP-over-TCP. Or in other words, for the vast majority of use cases, no.
I've had success with OpenVPN. It can set up a default route so everything in channeled over the encrypted connection and it uses client certificates, so it should be solid against MITM. I always turn on OpenVPN when I'm not on a trusted network.
Is it possible to use the browser in https only mode, or at least have it force launch any https sites in a new incognito mode window so that you know it's http-only. Furthermore, it would be nice if you could disable all text inputs on http-only windows.
I know that I would be more likely to contact a site owner asking for https if it screamed at me everytime it happened.
It's time to ditch http for all but rare use cases, because almost 2014.
Yes, you can configure most browser to use proxy. So, I think, you can set the none proxy (or valid) for https and some invalid proxy ip for http, so you cannot connect to any http server.
I like BT OpenZone in the UK. It seems everyone has connected to one of these at some point so you just create an ad hoc wireless connection with the same SSID and most modern smartphones automatically connect and start trying to download mail and facebook updates.
I've been thinking about the possibility of injecting a JavaScript bitcoin miner into every page loaded through my access point. Imagine the possibilities for an open AP that's located in a very public place, like Times Square, or near a busy Starbucks (where access is slow and unreliable).
If you really wanted to take this to the evil next level, you'd just break one (or several) WPA keys on nearby APs and have your rouge injector AP act as both an open AP (to unsuspecting users) and a client (using cracked keys) to other APs, thus avoiding having to actually buy internet access for this spot. You'd essentially just need to find a place to hide and power your evil AP.
Is that even remotely lucrative? As I understand, even a $300 GPU is orders of magnitude more powerful than any CPU miner, let alone a JavaScript based one. And even a single GPU isn't remotely competitive these days compared to the GPU farms and now ASIC setups. So you'd need to inject JS into, I dunno, a million, devices to make anything worthwhile.
You could probably use WebCL, Flash or Silverlight to use the user's GPU. A quick Google shows this has been done with WebCL already: http://webcl.nokiaresearch.com/jsoclbm/
Seems like ASICs are measured in the thousands to tens or hundreds of thousands of MHashes/sec. Whereas powerful GPUs drawing ~1000 Watts don't even break 1000MH/sec. High-end laptop GPUs seem to be in the 10s of MH/sec, a quad-core Atom shows 2MH/sec, and the Galaxy SII comes in at 1.3.
The vast majority of devices connecting to public APs are not going to be high-power systems. Not to mention the time they'll spend connected is unlikely to be 24/7. Even if it was, mining will probably drain batteries pretty quickly. Plus power-saving is likely to be on for mobile devices and reduce peak perf. And if it's just injecting JS, then backgrounded tabs should get much less CPU time. And WebGL/etc. are unlikely to be running in background tabs.
If you assume a device stays connected and open for 1/4 a day, and stays for 3 days on average, and gives you 1MH/sec (seems optimistic, all things considered), 1 million devices compromised a month gives you ~$300 a month. If the assumption is that you can persistently own a machine, then you'd need less machines. But that's going beyond simple JS injection on HTML pages.
One of the winning entries from the Node Knockout competition did this[1]. They didn't give any real numbers (20kH is mentioned in the comments, but it's not clear how many devices it took for that), but it does seem like you would have to have a massive amount of devices running it.
It still has to add up to something significant if you want to make real money at it; stealing a few pennies here and there is not that lucrative. A typical recent-gen CPU mining bitcoins full-time is worth about $0.02/month. If you assume your AP is in a busy enough location that you can average 100 people connected, you'll manage to nab $2 of people's CPU time each month. To get anything significant it seems like you'd have to actually compromise the machines long-term, not just inject some JS into pages as they're browsing.
Inject something like XSS Tunnel (http://labs.portcullis.co.uk/download/XSS-Tunnelling.pdf that gives you a local proxy that you can point your local browser and then sends all of your traffic through the victim, so you'll see and use the website(s) with your victim's session), or BeeF - http://beefproject.com/ for tons of exotic XSS based exploits.
Situations like these are how I justify keeping a low power 24/7 box on at home. In situations where I don't have my own (trusted) connection, I'll just ssh tunnel a SOCKS5 proxy to my home server. I only have a residential internet connection at home, but 2mbps is surprisingly snappy for casual or emergency on the go web browsing. With boxes out there (e.g. rPi) that push power consumption far south of 10W, it makes even more sense to do this now.
Of course, it also doubles as an IRC idler/whatever else you can think of.
Next trick is to do IP-over-DNS and I'll be all set where ever I am.
iodine[1] is a fairly easy way to set that up. I just made a tunnel.mydomain.tld subdomain, pointed the NS records at my VPS and run "iodined 10.0.0.1 tunnel.mydomain.tld"
I wonder if this attack would also work on the http://www.gstatic.com/generate_204 page that Chrome uses to detect captive portals if you are accessing https pages.
It's pretty easy to set up a VPN on EC2. Probably not the BEST solution out there (the instances certainly aren't designed for that use) but better than nothing.
Really? So would you blindly copy-paste things into your shell? Then I don't need to hijack your connections, I just put malicious pastes on the website.
If you are moron enough to copy-paste the first thing you find, you are probably not reading the other users' warnings about "this answer is wrong".
The attack mentioned is to change the text when you go to copy it; that will get even people who carefully read every forum post before copying and pasting.
How many people review the snippet, copy, paste it into a text editor, re-review it, copy it, and then paste it into their shell?
Ctrl-X Ctrl-E in bash will open an editor for the current command, which is executed when the editor is exited. After the potential for exploit was publicised a few months ago, I use this every time and it's really not much more effort than just pasting into the shell. As a bonus, it means I don't have to worry about embedded newlines stopping me from tweaking the command before running it.
You can embed \x1b (escape) into a webpage. When you copy-and-paste that, it has the same effect as hitting ESC in the editor. So, I'd just have to make you copy "<evil command>#\x1b:wq\n" to also catch the case that you're using vim instead of directly pasting. However, I can't figure out a way to escape from nano.
(Tested it with the combination chromium+xterm+vim.)
I deem your point good. I didn't realize it entirely.
Still, since when I run GNU/Linux I never pasted a command line from a website into my terminal. This is just reckless. Borderline case, I understand what the example is showing me and then I apply.
Note that if I can spoof an IP address, I can send you bogus DNS replies, and send you to a web server that impersonates Google/Facebook/etc. but does not require HTTPS (unless they use the strict security header). In this case you do not get a warning, just the absence of a tiny green icon.