Slashdot Mirror
The Problems of Web Surfing in Public Places
Krishna Dagli writes to mention a New York Times article about the dangers of public web surfing. The article looks at the sloppy habits people have when using public terminals, and the issues that using a wireless signal in a public place. From the article: "Michael Sellitto, a graduate student studying international security at Harvard, said that even though he encrypted any sensitive data on his laptop, he planned to sign up for a service like HotSpotVPN to add another level of security when he is traveling, especially when using poorly protected networks at cafes and hotels. 'The problem is, the really good people have written sniffer programs so that the less-sophisticated people have access to the same technology,' Mr. Sellitto said. 'Say a Microsoft Word document gets transmitted. The sniffer program will collect that and someone could open it up on their computer.'"
Has there ever been a documented case of people having their credit card details stolen by eavsdropping over an unsecured transmission? Not keyboard sniffing the user's machine or hacking the receiving servers database. An actual, verified case of cc number theft.
I'm not asking because it can't be done. Obviously unsecured wireless networks are very easy to monitor. But the issue here is I'm constantly amazed at the focus people have on the security of transmission, rather than spyware on their machines or the potential security of end servers which seem to me to be a lot more vulnerable and ripe for attack on the kind of scale that's actually useful to criminals.
Often the same people will happily hand over their credit cards to be taken out the bank of a resturaunt, fax or phone cc details through to businesses or throw out printed receipts with their full details (and signature).
Why this obsession with HTTPS?
One of these days I'm moving to Theory - everything works there
http://catb.org/jargon/html/writing-style.html has a pretty good explanation.
Hackers tend to use quotes as balanced delimiters like parentheses, much to the dismay of American editors. Thus, if "Jim is going" is a phrase, and so are "Bill runs" and "Spock groks", then hackers generally prefer to write: "Jim is going", "Bill runs", and "Spock groks". This is incorrect according to standard American usage (which would put the continuation commas and the final period inside the string quotes); however, it is counter-intuitive to hackers to mutilate literal strings with characters that don't belong in them. Given the sorts of examples that can come up in discussions of programming, American-style quoting can even be grossly misleading. When communicating command lines or small pieces of code, extra characters can be a real pain in the neck.
Consider, for example, a sentence in a vi tutorial that looks like this:
Then delete a line from the file by typing "dd".
Standard usage would make this
Then delete a line from the file by typing "dd."
but that would be very bad -- because the reader would be prone to type the string d-d-dot, and it happens that in vi(1), dot repeats the last command accepted. The net result would be to delete two lines!
[...]
Interestingly, a similar style is now preferred practice in Great Britain, though the older style (which became established for typographical reasons having to do with the aesthetics of comma and quotes in typeset text) is still accepted there. Hart's Rules and the Oxford Dictionary for Writers and Editors call the hacker-like style 'new' or 'logical' quoting. This returns British English to the style many other languages (including Spanish, French, Italian, Catalan, and German) have been using all along.
Well - I am not sure I would call it obvious. Experimentally I had two PC's on the same LAN segment. One was running ettercap the other I used for browsing. Ettercap was configured to do ARP poisoning and track SSL sessions with dynamic certificate generation. From the other PC I logged on to my so-called secure banking and ettercap had absolutely NO problem whatsoever in getting my username and password. From a user perspective the only HINT that something was wrong was that the cert was self signed (all the data in the cert was a replica of the original - just self signed).
Yes - if I had started the attack in the middle of a session it would probably have been obvious, but no - since ettercap was running before I even started logging on - there was no warnings of any kind - just a request from my browser if I wanted to accept the cert or not. Even looking at the cert for Joe Six-pack I would bet it looked pretty ok. You would need to understand the technology behind certificated to know that a self signed certificate is not secure - and honestly - while you and I might do that, how many users of on-line banking know? I am fairly sure that most - if not all - non-IT educated people would readily accept such a cert and therefore in reality browse in the open.
Regarding pop-ups on man in the middle attacks. Well - obviously I went through quite a lot of testing - mostly because I wanted to know what was possible and - if possible - how to prevent it. I did experience a few switches (and that is 2 to be exact out of at least 15 I tried with) that for some reason was not prone to the ARP poisoning, BUT I in those cases the attempt just quietly failed. In all other cases - ettercap happily sniffed just about any connection I tried to make without any hint on the client. The truly scary part is that ettercap can run pretty much unattended and just log whatever passwords it comes across, so I would say it was/is pretty viable to bring a laptop to a Starbucks and let it run for a few hours while I had a cup of coffee - then go home and see what I got. From the ettercap manual:
SSL MITM ATTACK
While performing the SSL mitm attack, ettercap substitutes the real ssl
certificate with its own. The fake certificate is created on the fly
and all the fields are filled according to the real cert presented by
the server. Only the issuer is modified and signed with the private key
contained in the 'etter.sll.crt' file. If you want to use a different
private key you have to regenerate this file.
The key here is that I do not agree with you that the chances of someone being there and ready is pretty small. Someone doesn't need to be ready - just run an application and wait - that is ALL it takes.
So why is this not rampant (as someone else was commenting). Well - I wouldn't know. What I do know is that I just selected ettercap from the standard list of Debian packages and did no configuration whatsoever. I wouldn't know if it run on Windows or if it is hard to install and/or use. I guess in the Starbucks scenario I mentioned, the hard part would be the wep keys, last time I checked that still did require some knowledge and wasn't fully automated, but once on a shared network it does not require much skills.