Slashdot Mirror
Phishing Scams Incorporate SSL Certificates
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.'"
Based on my experiences helping neophytes do web work, my guess is that 90% of the web-using public doesn't even notice the little key icon, and don't know what a security certificate is even when the dialog to accept one appears. All they usually look at is the web page itself... especially on a browser like Safari where the lock is a small icon in the title bar that escaped me the first time I went looking for it. It might be interesting to have some usability folks do an eye movement analysis to see if the average user's eye ever tracks to the lock icon during normal browsing.
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...
(Disclaimer: I am probably biased, since we issue
SSL certificates
on our website.)
This article is a good example of yet another reason why the old advice of
"make sure the site you are dealing with has an ssl certificate, and you
should be fine" is no longer entirely true.
To be more confident you are dealing with a reputable/accountable merchant/site, you
should not only make sure that they have an SSL certificate, but you
should also actually click on the lock (or however it is done in the browser
you use) and look at the certificate.
The reason the advice used to be valid, is that traditionally, to get an SSL
certificate, you had to provide documents to prove you are who you say you
are, i.e. DUNS #, articles of incorporation, business license, DBA, bank statement,
passport, driver's license, whatever. That is still true for most of the
certificate authorities, but it isn't always true. Some of the new certificate
authorities don't actually ask to see documents before issuing the
certificate, instead, they merely make sure that you have control of the
domain by sending an email to the listed contacts. In some cases, they also
place a phone call to a number you provide them (I fail to see how this does
anything, but..). Certificate authorities that do this will issue the
certificate to "Domain control validated, organization not validated" as the
organization (or similar text to that effect) rather than to the actual name
of the company the certificate is for. These certificates are
perfectly fine for making sure things
are encrypted, however, they make the certificate useless for getting an idea
about the legitimacy of who you are dealing with. They also don't tend to
carry the warranties that other ones do (and for good reason, who would
underwrite that procedure?).
SSL Certificate
Average Joe doesn't have any idea what encryption is or why it's important. Average Joe just wants to point, click, and buy. Hell, I rarely pay attention to it.
Isn't it more likely that people were suckered in not because of the SSL trick but rather simply from "scam" or mimic pages instead?
---
Never criticize religion on Slashdot. You will be modded down for "Troll" no matter how factual it is.
What, is this going to trick another 1% of so called "technically adept" people *COUGHmcseCOUGH* into giving their online bank login info over a freakin' website? Who ever ASKS YOU for your login information?! They reset it, and they have you reset it upon login.
Ooooh... Wait a minute. That could be a NEW strain of e-mails... Just takes a little more HTML craftmanship to code a fake E-Mail with a "reset" password, you log into the evil website with it, and enter in your "new" (which would most likely be your old one again, for most people) info. Scary!
It is pitch black. You are likely to be eaten by a grue.
Wasn't the entire point of SSL was to be encrypted? Who's bright idea was it to put plain text in SSL in the first place, much less give browsers support for it?
If I understand correctly, phishing comes into play when users are sent an e-mail with a bogus link. Probably something like "we've detected fraudulent use of your account, please follow this link to verify your information" etc. etc.
There is no reason to follow links in e-mail to get to a site that you regularly use. If you doubt the authenticity of an e-mail from, say, American Express, just visit the site as you usually do, through a bookmark. After logging in you should be able to access the necessary info.
Don't worry, I make sure to type all of my URL's now including onces such as:l d=0&mode=thread&commentsort=0&op=Reply
http://slashdot.org/comments.pl?sid=99888&thresho
Sometimes they take a while but it pays off!
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.You can create self-signed certs just as easily with Microsoft's certificate managment tools.
Users are conditioned to click Yes/OK to *any* dialog box that gets in their way, without reading it.
I think you'd be better off asking why the existing laws against fraud and deceptive trade practicees aren't enforced.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Sad thing is, it's getting harder and harder to be able to give them basic advice.
At the rate things are going, you pretty well have to know all the same tricks the spammers/scammers do...
I mean, just the other day, I got a message from PayPal about my account. Oops, I don't have one... Okay, so that would've been my first clue, but it was faked well enough to pass Hotmail's spam filter, and it looked official, like I really had had an account suspended.
So I check the email source, because I know better. Sure enough, it's using the %00 bug to catch IE users. Assuming they would know to look for where the link actually pointed, instead of where it claimed to.
In the mean time, I went to the page. Sure enough, it wants every bit of information imagineable. All the other links off it link to actual PayPal pages... the status bar at the bottom is left blank via JavaScript. So the inobservant and gullible would be hosed...
Naturally, I feed it totally fake information (might as well give them more false data... shouldn't harm anyone, should only help get them caught, I hope), just to see what it does. Sure enough, redirects you to another actual part of the PayPal site. I sent off a LART to the hosting provider's abuse email. No response. I don't consider that a good sign.
Note that no SSL was required here. Just official-looking pages. Granted, I didn't fall for it, but I know more about these exploits than Joe Average. Joe Average probably wouldn't know what was wrong with %00 in a URL if he saw it.
This is sad, too. I've taught classes on this, and I try to teach the class as much as they are capable of understanding. Even so, it's getting to the point where I feel like they need to know at least as much as I do just to avoid these stupid scams. There's a new one made up every day, it seems, and I spend a lot of time just keeping up with what the lowlifes are doing...
So the point of all this? We practically need a "scam report" type of newspaper for the general public. Not to mention a primer detailing the older tricks in the book... not to mention some way to get the average public to read them both.
It is illegal under current laws (Wire fraud, misrepresentation, etc). The hard part is catching them, also there are jurisdiction issues. I mean really there was no need for new murder laws when guns came about. This is fraud, and oftentimes theft plain vanilla crime, but with a new delivery method. Also to be honest, most DAs would probably rather go after child porn then something so unlikely to get there names in the paper as white collar credit card scams
I'd do something interesting, but my server can't handle a slashdotting.
Ok if the bad guys can get certs from slime certificate houses then I can delete said certificates or mark them untrustworthy. Will I then get warning about the certificate being invalid and that should prompt me to take a closer look.
If so anybody have a list of SSL providers I should be giving a second look at when the site pops up?
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
finally an affordable way to use SSL certificates on our sites without "unsigned certificate" warnings or having to pay Verisign $895/year for each certificate!
"One of the SSL encoding methods is 'plain text'," I could have had my own certs with no browser barking for all this time ? Damm Years ago I tried the "Please install my certificate thing" It worked for a while but stupid customers kept asking questions (I am sorta joking) Now I find out I could have configured my server to avoid many of these authority issues ?
Let me give you an example. Suppose you're in the nation of Grand Fenwick, and bank with the National Grand Fenwick Bank. I, who live in Mordor, decide to target customers of the National Grand Fenwick Bank, and set up a fake website at http://123.456.789.0/gf.php[1] that mimics their logon screen. I then send out millions of emails to lure customers of NGFB to my website.
Within minutes of these emails being sent, the Powers That Be at NGFB know about the fraud that's being committed in their name. They know what host is hosting the scam. They know (or can easily find out) where the host is located physically. BUT:
- How do they know whether that host is a willing or unwitting party to the fraud?
- How do they prove it, if it's willing?
- If it's unwilling, how do they track down the perpetrator?
- Assuming they can track down the perpetrator, how do they take said perp into custody?
It just so happens that the host is my own, and I'm listed as the registrar. Alas, alack, there is no extradition treaty between Mordor and Grand Fenwick, so all they can do is shout threateningly across the ocean at me, whilst I mock their puny and powerless attempts to bring me to justice.There are too many levels of proof needed to bring a conviction, and even if they're all satisfied, if the perpetrator is in a country such as Russia, all hope goes out the window. In fact, all it takes is one layer -- me hiring a Russian to obtain these details -- to protect me (as long as I'm careful about how I use those details).
The police and fraud departments are aware of these issues, and they're trying to resolve them. Unfortunately, political problems get between the problem and the solution. Things aren't helped when it takes me a half hour to alert the bank and/or police of a currently active fraudulent site...
[1] Yes, I know this is an invalid IP address. You're missing the point.
I for one object to blaming all this on Phish. I'm sure that Mr. Anastasio et al. have no connection to this illegal and extremely harmful activity.
It defaults to poping up a warning that you are using low grade encryption. Plain text qualifies!
RTFA or quit trolling. The problem is not the SSL certificates or who creates them, but the browsers accepting a "plain" encryption scheme when setting up the secure channel. I haven't actually seen this but it's entirely within reason that a "plain text" encryption was available in the SSL libraries for debugging communications in SSL apps.
I think it should be fairly simple to update the browsers so they require some encryption by default. Voila. Problem solved and we don't have to kill OpenSSL or "pay a root certificate authority" for the privilege of having encryption.
This is fine by me. Everything up to that point doesn't need to be encrypted. However, the only way to verify that the form (i.e. credit card #) will be sent over HTTPS is to View Source and look for the POST line. And this makes verifying certificates and encryption methods even harder.
Would it make sense for a tooltip over the Submit button to show the destination of the POST? Or at least whether it's secure? How about some useful items on the right-click menu?
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..
I don't care if you're using 2048-bit encryption to purchase that new GeForce - if SuperDealUpgradeStore so much as leaves the wrong port open on the firewall or uses a simple password and doesn't check logs, you're hosed.
As the saying goes: "Security is a process, NOT a product."
If a protocol can be weakened by someone generating a long bit-string, then that protocol isn't worth much in the first place.
Public knowledge of SSL (incarnated in the openSSL source) is not the problem. Rather, the problem is twofold:
Uncomprehending users End users don't understand PKI, for the most part. They don't understand the implications and assumptions which underly the system. By default, the X.509 architecture means that they end up implicitly trusting the root Certificate Authorities installed by their browser provider (which means they are implicitly trusting their browser provider and we know who that usually is...) Untrustworthy Hierarchy in X.509 The hierarchical nature of SSL's PKI means that even for those people who understand how it works, they are still strongly compelled to trust some large CAs. Sadly, many of the large CAs have abandoned their ideal role of actually establishing and verifying identity. They seem to now see themselves as yet another middleman who deserves a cut of any transaction without providing a service. How many times have you seen a CA whose policy for establishing identity amounts to "Please send us a fax on company letterhead" ? Who can't send a fax on "company letterhead" these days?I would be willing to pay a good CA for actual verification, even as a client, if i could be sure that they were actually verifying the folks they issued certificates to. But it would need to be big enough to be able to certify a large number of sites to be worthwhile...
The non-hierarchical nature of the web of trust model of PKI is so much better than X.509, so it would fix the untrustworthy hierarchy issue above. But, even more than X.509, it expects all the end users to understand the basic ideas of PKI, not just "look for the little lock and click those dialogs as soon as they come up". sigh...
Well, these 'phishers' would make up a url.. something like http://www.eonlinebank.com (and then, insert a bunch of spaces)@theirsite.com/
Their site would be an exact replica meant to steal your information. So, firms would beat into their customers to look for the 'lock' or the https:// before a URL to make sure that it was the right site.
With plain text encoding on an https site, you still get the comfort factor of the lock (i think), and the https://, so once again, the morons who don't look at the complete URL are going to be victimized.
IE had a bug where a certian control code would make the second part of the url (the @and everything after it) completely invisible. This has been fixed.
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.
2 1337 4 u!
To enable the Debug menu see this tip.
http://www.rootstrikers.org/
Interesting post, but I'm glad it wasn't designed to protect people against hostile hosts. If it was, we'd probably not have the internet as we know it today. Somebody would have raised a scare early on, and the government would have heavily regulated it.
Now, after the fact, engineers can design useful protocols to work on top of or in conjunction with the internet to help solve the problem of hostile hosts. IPsec, SSL, PGP, firewalls, ssh, and fancy switches/routers all help to protect people from abuse.
And now, we have a high degree of internet freedom. We can pretty much do what we want with our bandwidth. People will get mad and hunt you down if you crack systems, violate copyrights or send spam, but aside from that, it's pretty much free. And even with all this freedom, it just requires a little persistance to prevent your machine from getting hacked.
Social scientists are inspired by theories; scientists are humbled by facts.
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. These dudes made an SSL library that can use PGP certs. It's a step in the right direction. Kick ass.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The whole text/SSL thing is very disturbing, I thought I knew quite a bit about SSL having generated my own keys and installed certs and done some other things, but I had never found this dark corner.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You don't have a real PKI (public-key infrastructure) unless you've got some way to revoke compromised certificates.
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.
No it doesn't. It underscores the need to make browsers that aren't quite so bloody stupid, and do things like always displaying the real URL (gasp!) and not allowing Javascript to open new windows without the normal user interface security features (or a big yellow border saying 'Javascript window'). In fact, it might be a good idea to always have a grey border of a few pixels between the contents of a page and the user interface widgets surrounding it.
They may have a point on the SSL certificates, but the whole PKI thing seems a complete crock anyway... Verisign, Thawte and the like are not exactly the world's most trusted institutions. Maybe in the case of banks and other high-security sites it should be possible to pick up a free CD from your local branch or from your country's financial regulator containing the public keys. Then there would need to be a simple and foolproof way to import this key into your browser.
-- Ed Avis ed@membled.com
Cuz if the guy is a slimeball who found your wallet lost on the street and decided to have some fun on you it's all to easy for him to do that. Whenever I use my credit card in person I'm never asked to prove my identity. One time awhile back a boss I had asked me to fill his truck and use his card and to call if they gave me any trouble. They swiped the card without even looking at it.
Hell, even if it's you using your own card...people are really careless and only seem to have concerns about using their card on the 'net. Too may people out there verbally broadcast their credit card info to strangers over the phone who solicit them for donations to feed the starving Africans, or hand their cards to the attendant at the full-service station when they fill their vehicles, or willingly give it to the waitress when they have lunch at Denny's, or whatever else.
I dated a diner waitress once, and know the types of losers who ended up as permanent pump jockeys from summer jobs as a teenager. I have personally witnessed those environments. In both situations many (if not most in some cases) of those employees are poorly educated, poorly paid, perennially broke, dopey chronic potheads. Also, some call centres are also pretty lax and will hire anyone who will stay long enough to learn how to use the predictive dialer system. AND WE TRUST THESE PEOPLE WITH OUR CREDIT CARDS!
Because of that I NEVER buy anything, book a room or hire a car over the phone...I go online so my credit card number is at least encrypted (and I hope that the computer jockeys are at least a bit more trustworthy than a call centre operator). I NEVER give my credit card to a waitress or a pump jockey--if I use my card at all I go to the cashier and have them swipe it electronically. Authorisation is instant and the receipt they retain doesn't show the whole number anymore (I also NEVER use the old "click-clack" impression machines either).
Sounds paranoid? Well, it's far easier to exploit those common real-world events than to set up an internet phishing expedition. C.C. fraud on the INTERNET? Even if your number was sent in the clear it's typically in transit for less than a second, and could only be aniffed out by people with access to special equipment. Sure you have to be careful about encryption and authentication but (for now) online transactions are still mostly safe. Much less bother for criminals to pursue other opportunities.
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) 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.
I tried to duplicate this, with no success using either of the abovementioned browsers.
I tried using
openssl s_server -nocert -ciphers eNULL:aNULL:NULL -www
as well as
openssl s_server -cert mycert.crt -ciphers eNULL:aNULL:NULL -www
In both cases, both browsers refused to connect, saying that there were no shared algorithms (Firefox), or simply giving a error page (IE).
In all cases, openssl gave me messages similar to
332:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c
Perhaps this does not qualify as "most browsers", but I'm sceptical of this report.
In a related note, you can put a lock icon on a web page with out using ssl at all. Take a look at the Chase Bank Homepage. They put a lock in the login box, making users think that the login box is secure, however, it's not completely secure because it's on an unsecured page. While indead, for most people, the login information will go straight to chase secure servers, it is possible to hack the users session. How? Easy, just modify the chase.com homepage before the user gets it. Either through DNS, proxy or xss. Whatever you do, don't login to your bank account from the chase homepage.
-- these are only opinions and they might not be mine.