Phishing Scams Incorporate SSL Certificates 316
dettifoss writes "Netcraft reports:
`Internet "phishing" scams are incorporating the use of SSL certificates in their efforts to trick users into divulging sensitive login information for financial accounts.'
Perhaps more disturbingly: `Scammers can also configure their web server so that deceptive SSL certificates won't trigger an alert in the user's browser. "One of the SSL encoding methods is 'plain text'," Neal Krawetz from Secure Science Corporation noted in the SANS post on the issue. "Most SSL servers have this disabled by default, but most browsers support it. When plain text is used, no central certificate authority is consulted and the user never sees a message
asking if a certificate should be accepted.'"
Do people even see the lock? (Score:5, Interesting)
Of course, this does make it more likely for people who hit that nasty stage of knowing just enough about online security to be dangerous to get caught...
Re:Do people even see the lock? (Score:5, Interesting)
If the user was forced to pick a unique picture/bitmap/watermark that would be displayed on secure webpages by the browser, it could help with security. I.E. Design the browser so no ssl pages work until the user selects a unique bmp/jpeg that would be displayed as a unique overlay somewhere on the web page that allows them to verify that the page is secured.
an old timer i know (Score:5, Interesting)
solves all this by never entering any financial data anywhere on the internet. he's not a knowledgeable computer user, and he knows it. in his case, and in the case of many non technically-minded individuals, it seems much easier to simply avoid all online financial transactions.
i think his simple approach to avoiding online financial risks makes a lot of sense. many of my non-tech friends/family members might be taken in by a scam like this, and given how painful it is to explain computer things to them, from now on i'll just tell them never, under any circumstances, to enter financial data on the web.Re:It doesn't matter - but it does (Score:3, Interesting)
Now, absolutely every weakness is being found and exploited. The Internet just wasn't designed for this...
Re:Do people even see the lock? (Score:1, Interesting)
Anybody got a list of "BAD" Cert providers? (Score:5, Interesting)
If so anybody have a list of SSL providers I should be giving a second look at when the site pops up?
Look for the cute little lock! (Score:3, Interesting)
Re:Defeats the purpose of SSL? (Score:2, Interesting)
For the record, I do look for the lock icon but because of that, I do turn off the "you are connecting to a secure site/you are leaving a secure site." 9 times out of 10, I do click on the lock and verify that the URL in the cert matches the url that I am pointing to...but I do understand that I'm especially paranoid in a nerdy kinda way.
Is there a page with a demo of the technique? (Score:3, Interesting)
Re:thanks scammers! (Score:4, Interesting)
You do raise a very interesting point though. The fact that browsers don't pop up a warning for plain-text SSL could actually potentially be used to perform a man-in-the-middle attack with no-one the wiser (unless they check the issuer of the certificate manually, as they should)! That is rather scary to me, and it is serious enough that patches should be issued (not that most people apply them, but that is an entirely different story).
Re:Defeats the purpose of SSL? (Score:5, Interesting)
I presume the second half of the problem in that MS Internet Explorer allows (is this fixed?) a site to misrepresent its address in the address bar? That way the user cannot be sure that the address displayed matches that in the certificate.
Personally, I've never understood the mentality of allowing a web page to modify ANYTHING outside the boundaries of its frame. Doesn't this break the whole 'object orientedness' of a windowing display?
Re:Best strategy for fighting this (Score:5, Interesting)
Re:Best strategy for fighting this (Score:1, Interesting)
Re:The lock is not important (Score:5, Interesting)
While I'm on the topic...When I right-click and hit View Source, why can't the browser open an editor and scroll to the line of code that I right-clicked on? I know Firefox & IE don't, maybe something else does already..
In Firefox, if you highlight part of the HTML document and then right click the highlighted text and select "View Selection Source", the program attempts to load the source and go to the appropriate line(s). I've found the functionality is kind of hit-and-miss, but it's definitely what you're after.
Comment removed (Score:3, Interesting)
Re:Look for the cute little lock! (Score:5, Interesting)
like that works! my dad called me about a year or so ago. he'd only been on the 'net a couple of weeks and ran into a site that asked him to accept a certificate. he was concerned because his bank's site never asked him for acceptance... he assumed that if the site didn't ask for acceptance it wasn't a legit ssl connection. yep, exactly the opposite of how it's supposed to work.
now, you can say he didn't read the full message (and it's true, he didn't) but, really, who here actually reads all that stuff your computer throws at you? i mean, we all skip down the man page to the examples section (if there is one) don't we? and my dad's a chemical engineer - six years of math education and he's stumped by our ssl user interface.
oh dear.
Re:Do people even see the lock? (Score:1, Interesting)
That little ghost square that pops up for Volume, or eject.
having those for lock and unlocked web sites, nice and obvious and short lived reminder.
it Could even have the same bar scale as volume to indicate security level.
Re:Anybody got a list of "BAD" Cert providers? (Score:1, Interesting)
By the way, if anyone wants their key signed, I'll sign it for $10 if you think that provides any sort of security for validating the identity of a web site. Also, I have a bridge for sale. It's in New York.
Every UI I've seen for SSL, is lame (Score:5, Interesting)
I bet 99% people don't even know what the lock icon means. I bet 90%+ of Slashdotters don't really know what the lock icon means and how to interpret the meaning of the cert. What does that tell you about the quality of the user interface?
The UI is oversimplified to the point of danger. So some company that you don't know, but the guy who made your browser might know declares that the cert really belongs to who it claims to belong to. Where's the accountability? Do you know any of these signers? Do you know anything at all about their security procedures? And if you did know something about them, could you adjust how much you trust them, and have your browser use other authorities to double-check them?
That's why the cert system sucks, especially with only one signature per key. I can think of ways it might be useful, but Internet Commerce isn't one of them.
Fortunately, many many years ago, before the web even existed, someone came up with a much better way of dealing with these issues. That someone was the underrated hero Phil Zimmermann, and that something is called PGP.
Now with PGP, the user has to actually think about who they trust and deal with the concept of degrees of trust, and grandma doesn't want to have to think about crypto stuff. Boo hoo. That's too bad, because if you want accuracy, and even the capacity to be able to trust what your tools are telling you, then you have to. But some people don't care. Fine, then trust some central authority just like you do with SSL certs, and your situation is no better or no worse than it currently is now.
But at least if PGP were used, then, the applications (e.g. web browsers) would be designed with the idea in mind, that certs are of varying degrees of trustworthiness, and they would have been forced into coming up with ways of presenting this information to users. (Because just because grandma doesn't care, that doesn't mean all your users don't care. So you have to deal with the issue.) That means that problems like the one in this story, wouldn't happen, because the UI would be designed, not to tell the user if an connection were SSL, but instead to inform the user about the other side's identity and the degree of certainty of that identity. A plaintext SSL connection would say something like "0% certainty" instead of a stupid lock icon.
Now, time for a plug: the GNU TLS library. [gnu.org] These dudes made an SSL library that can use PGP certs. It's a step in the right direction. Kick ass.
Another idea for browser security - data detect (Score:4, Interesting)
Anyway, I had an idea that might be easer for users to use - instead of indicating a page is secured or not, instead let the user indicate that certain kinds of data should never be sent out over an unsecured, unverified link - any attempt to post data would result in a warning message about the information transmitted not really being protected. That would eliminate mistaken posting of data of insecure lines if people are not really paying attention to the lock (I have left up on all my browsers the warning about entering/leaving a secure page so I pretty much always know [or thought I did], but that's too annoying for most people).
You wouldn't even have to give the exact number - you could have pre-defined things like "anything that's a credit card number" or "anything with 9 digits ending with these four" or "my address". Then the browser would watch form fields and if the user tried a page submit - up would go the warning.
Enough is enough (Score:2, Interesting)
Spammers and virus writers/blackhats have joined in an unholy alliance and scammers like the ones in this article are running their schemes apparently with impunity.
Existing legislation has failed mainly because it is national and not international like the net itself. Technological means have failed as clearly shown in this article. If encryption/authentication like SSL won't work, then what will.
The dream is gone. The freewheeling internet from the late 80s and early 90s is dead and will never come back. The net can no longer remain both useful and unregulated and I will certainly opt for the usefulness over unregulation.
And no, before someone starts bashing Microsoft, running Linux won't save you. This is not a technological problem. Even if every computer in the world were running free software, the users would be the same. Yes. Those who run as root and click on every goddamn mail attachment. This is a social problem just like ignorance of the general population, scamming and vandalism are in the real world.
So what to do? Well, if the problem is the same as in the real world, use the tools we already have for controlling travel, gun ownership or who gets to drive a car or practise a profession. Age limits for net access, controlled net hardware (punishments in the same class as dealing "class A controlled substances"), tightly controlled licenses for running a business on the net and most of all a compulsory international e-identity (smartcard/bio authentication; equivalent of a passport) without which you cannot even access the net.
Re:Do people even see the lock? (Score:3, Interesting)
However... Just authenticating a site is really important! It's more likely that you'll be fooled by a hoaxed web site than that someone manages to sniff your packets or man-in-the-middle you. I don't know about most of you; but I'm on a reasonably trusted network (i.e. I know there aren't any sniffers on the LAN and once the connection's being routed you'ld have to sniff all kinds of gunk and manage to somehow, transparently get into that connection between the various routers - much harder than on a lan.)
So if I had to choose between authentication and encryption - well; I know what I would choose...
Other limits of current SSL implementation(s) (Score:5, Interesting)
Suppose your server gets rooted and a bad guy gets your private key. You have to tell everyone who might go to your web site that the old certificate is no longer valid.
The good news is that there are certificate revocation lists out there. The bad news is that Internet Explorer, as of the last version I looked at, doesn't check them by default.
Next, think about the level of understanding of PKI out there, think about the usability studies that have been done on public-key software(specifically PGP), and estimate how likely it is that most organizations could resist a social engineering attack on the secret part of their SSL cert.
The indispensable Bruce Schneier has pointed out a couple of other vulnerabilities. How does your browser know what signers make a certificate valid? It ships with a list of trusted signers. How secure is this list? It isn't. Schneier has pointed out in his newsletter that a virus could silently add an evil CA to the trusted list.
His other good point was, how much would it cost to compromise the Verisign root signing key? He talked to Verisign's CEO and they decided that for $15 million you could make a down payment on a leveraged buyout of the company. So that's an upper bound. Could you make $15 million illegally with bogus Verisign-signed certs? Could the Russian mafia raise $15 million?
I've been kind of surprised that SSL has worked as well as it has for as long as it has.
Re:Open SSL contributes to the problem... (Score:1, Interesting)
That is exactly correct, I trust self-signed certs more than I trust the ones from the CA vendors. Many people here don't trust Verisign, I don't see a reason to even use them since they don't provide what they were supposed to - a chain of trust. The distributed, self signing and peer, circle of trust seems more reasonable and useful
And I know it is not relevant here but the article is about the lock is "turned on" without any cert pop up on the client asking if you trust so-and-so. It seems to be a minor part of the overall phishing schemes and I thought I read sometime ago about a method to install non-plain text certs (possibly using javascript?) without generating a pop up when I was research some cert issues for a Java Web Start project I was working on.
People have been using pretty persistent, varied and sophisticated methods to try to spoof the e-gold site [e-gold.com] for sometime which used turing numbers and explicit warnings [e-gold.com] to check for the proper URL _and_ the lock before entering your passphrase (which has a good minimum number of characters), etc, etc and what do you know? people still get taken.
Part of the problem is that https combines the cert trust functions with the network encryption functions - there is no reason we couldn't have a connection oriented dynamic encryption standard for http that doesn't use certs.
The article is incorrect (Score:3, Interesting)
Yes, SSLv3/TLSv1 does have a NULL cipher suite, which is authentication only, and there is also support for Anonymous Diffie-Hellman key exchange (which doesn't require authentication). (See RFC 2246 [ietf.org]) But browsers don't use it. No browser, even going back to Netscape 2.0 supported NULL or ADH by default. If you wanted these cipher suites, you have to explicitly turn them on.
Go ahead, try it. Take a test Apache/mod_ssl server and change the SSLCipherSuite config line to:
SSLCipherSuite ADH:NULL
and restart the server. Now try to connect to it.
In IE, you'll get the generic "The page cannot be displayed" error. In Mozilla/Firefox, you'll get "Firefox and cannot communicate securely because they have no common encryption algorithms."
I welcome a real-world example of this "attack" that will actually work on a default-configured web browser.
Re:Do people even see the lock? (Score:2, Interesting)
"[Encrypting transactions on the Internet] is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench." -- Eugene Spafford (Purdue)
Re:Do people even see the lock? (Score:3, Interesting)
The book you want is called "translucent databases"
Think again about your assumption that one person may want to look at a whole load of data on different people, and consider what fields this actually applies to.
Credit-card numbers? No, they get sent during the transaction, and if you even need to keep them in the database, they can be encrypted with the user's password, so that next time they logon, they can use that stored CC number again.
Management stats? No, you can just update the "total x" for each transaction, without having to store x individually per-person.
There's plenty more in the book, but start thinking about which direction each piece of data is going in, and whether that's correct. Does the person's ID need to go into a table of statistics? If not, hash their name and password, so that it produces a unique identifier that can't be related to the customer without knowing their password.
Does some data need to go from the customer to the company at all, or could it just be encrypted with their password? Would it be better to just throw some information away? Start thinking about who needs to know what..
Own experience (Score:1, Interesting)
Mozilla refuses connection (no shared cipher). You have to edit SSL preferences to accept NULL encryption by hand. Then you can connect, but certificate is verified by browser. Lock icon is not the same as a typical SSL connection : it is broken and red enlighten.
IE refuses connection (no shared cipher). I quickly ran into config options but found nothing about NULL encryption
Which means NULL encryption seems to be refused by theses two popular browser using default install.
Re:Other limits of current SSL implementation(s) (Score:3, Interesting)
The good news is that there are certificate revocation lists out there. The bad news is that Internet Explorer, as of the last version I looked at, doesn't check them by default.
Both IE and Mozilla both support OCSP. Mozilla does not have it turned on out of the box either.
The indispensable Bruce Schneier has pointed out a couple of other vulnerabilities. How does your browser know what signers make a certificate valid? It ships with a list of trusted signers. How secure is this list? It isn't. Schneier has pointed out in his newsletter that a virus could silently add an evil CA to the trusted list.
Better, just change one of the existing CA entries to use the same name and a different server and cert. Even hardcore cypherpunks aren't likely to catch something like that. Ultimately the answer is going to have to be loss mitigation and harm reduction: it'd be nice to see some technology solutions (or at least assistance) applied to the pessimistic assumption that WHEN your data IS compromised at some point, there's some help other than suspending, scrubbing, and possibly having to get a brand new digital identity.
How do banks do it? (Score:2, Interesting)