The Center for Education and Research in Information Assurance and Security (CERIAS)

The Center for Education and Research in
Information Assurance and Security (CERIAS)

CERIAS Blog

Page Content

This Week at CERIAS

Share:

CERIAS Reports & Papers

CERIAS Weblogs

“Verified by VISA” Issues

Share:

The premise of the “Verified by VISA” program seems fine:  request a password to allow the use of a credit card online, to lower credit card fraud (besides the problem of having to manage yet another password).  However, there were several problems with how I was introduced to the program:

  • I was unexpectedly requested to register my card after doing some shopping online on a site that allowed customer comments, and had forced me to turn on JavaScript.
  • I knew nothing about this program, and the request was presented in an authoritative manner, implying that I *had* to register or else my purchase would be denied.  (Bull!  Even though I closed my browser without completing the registration, my purchase went through)
  • I was asked for the last 4 digits of my SSN as proof of identity (!), along with information I had just provided to the online merchant (CC number, phone number, etc…)
  • There was no explanation or link to an explanation of what was going on, why VISA would want me to register my card and what was this program.

That appeared to me more like a phishing attempt, exploiting a XSS vulnerability, than anything else.  After contacting my bank, I was assured that the program was legitimate.  Visa actually has a web site where you can register your card for the program: 
https://usa.visa.com/personal/security/vbv/index.html

On that site, you will find that most links to explanations are broken.  I get a “Sorry! The page you’ve requested cannot be found.” when clicking almost all of them (I found out later that it works if you activate JavaScript).  Another issue is that you need to activate JavaScript in order to provide that sensitive information, therefore exposing your browser to exploits against the browser and to any XSS exploits (I’m not worried as much about the VISA site, which doesn’t have user-submitted content, as much as the shopping sites).  If you are not using NoScript or forget to disable JavaScript afterwards, then you expose yourself to exploits from all the future sites you will visit.  It’s irresponsible and unnecessary:  there was nothing in the JavaScript-activated forms (or in the explanations) that couldn’t have been done with regular HTML.  It’s all in the name of security…

A fundamental issue I have with this process is that commands (the registration) to reach a higher level of security are issued in-band, using the very medium and means (browser) that are semi-trusted and part of the problem we’re trying to solve (I realize that this program addresses other threats, such as the vulnerability of CC numbers stored by merchants).  Moreover, doing this exposes more sensitive credentials.  It is almost like hiring a thief as a courier for the new keys to the building, while giving him as well the key to the safe where all the keys are stored.

The Visa program also enables a new kind of attack against credit cards.  If criminals get their hands on your last 4 SSN digits (or if they guess it, it’s only 9999 brute force attempts) and your credit card number, they could register it themselves, denying you its use!  The motivation for this attack wouldn’t necessarily be financial gain, but causing you grief.  I also bet that you will have a harder time proving that fraud occurred, and may get stuck with any charges made by the criminals.

The correct way of registering for this program would be by using a trusted channel, such as showing up at your bank in person to choose a password for your credit card, or through registered mail with signatures.  However, these are not available options for me (I wonder if some banks offer this service, and if so, whether they are not simply using the above web site).  There should also be a way to decline participation in the program, and block the future registration of the card. 

In conclusion, this poorly executed program had a reverse effect on me:  I now distrust my Visa card, and Visa itself, a little bit more.

Update:  There doesn’t seem to be a limit on the number of times you can try to register a card, enabling the brute force finding of someone’s last 4 SSN digits (I tried 20 times.  At the end I entered the correct number and it worked, proving that it still accepted attempts after 20 times).  An attacker can then use the last 4 digits of your SSN elsewhere!  Let’s say, your retirement accounts with Fidelity and others that accept SSNs as user IDs. 

For more fun, I attempted to register my credit card again.  I received a message stating that the card was already registered, but I was offered the chance to re-register it anyway and erase my previously entered password simply by entering my name, the complete SSN and phone number.  Isn’t that great, now attackers could validate my entire SSN!

It gets worse.  I entered an incorrect SSN, and the system accepted it.  I was then prompted to enter new passwords.  The system accepted the new passwords without blinking…  Not only is the design flawed, but the implementation fails to properly perform the checks!

More on passwords

Share:

[tags]Passwords[/tags]
I’ve previously written about passwords in this blog (here, here and here).

I saw this post today—I think it is great!  I’m sure they will adopt this here at Purdue sometime soon.

Quicktime flaw on Macs brings out the crazies

Share:

[tags]Windows,MacOS, security flaws, patches, press coverage[/tags]
There’s been a lot of froth in the press about a vulnerability discovered in a “Hack the Mac” contest conducted recently.  (Example stories here and here.)  I’m not really sure where this mini-hysteria is coming from—there isn’t really anything shocking here.

First of all, people shouldn’t be surprised that there are security flaws in Apple products.  After all, those are complex software artifacts, and the more code and functionality present, the more likely it is the case that there will be flaws present—including serious flaws leading to security problems.  Unless special care is taken in design and construction (not evident in any widely-used system) vulnerabilities are likely to be present.

Given that, the discovery of one serious flaw doesn’t necessarily mean there are hundreds more lurking beneath the surface and that MacOS X is as bad (or worse) than some other systems.  Those bloggers and journalists who have some vulture genomes seem particularly prone to making sweeping announcements after each Apple-based flaw (and each Linux bug) is disclosed or a story about vulnerabilities is published.  Yes, there are some problems, and there are undoubtedly more yet to be found.  That doesn’t mean that those systems are inherently dangerous or even as buggy and difficult to protect as, for example, Windows XP.  Drawing such conclusions based on one or two data points is not appropriate; these same people should likewise conclude that eating at restaurants anywhere in the US is dangerous because someone got food poisoning at a roadside stand in Mexico last year!

To date, there appear to be fewer flaws in Apple products than we have seen in some other software.  Apple MacOS X is built on a sturdy base (BSD Unix) and doesn’t have a huge number of backwards compatibility features, which is often a source of flaws in other vendors’ products.  Apple engineers, too, seem to be a little more careful and savvy about software quality issues than other vendors, as least as evidenced by the relative number of crashes and “blue screen” events in their products.  The result is that MacOS X is pretty good right out of the box.

Of course, this particular flaw is not with MacOS X, but with Java code that is part of the Quicktime package for WWW browsers.  The good news is that it is not really a MacOS problem; the bad news is that it is a serious bug that got widely distributed; and the worse news is that it potentially affects other browsers and operating systems.

I have been troubled by the fact that we (CERIAS, and before that COAST) have been rebuffed on every attempt over the last dozen years to make any contact with security personnel inside Apple.  I haven’t seen evidence that they are really focused on information security in the way that other major companies such as Sun, HP and Microsoft are, although the steady patching of flaws that have not yet been widely reported outside the company does seem to indicate some expertise and activity somewhere inside Apple.  Problems such as this Quicktime flaw don’t give warm fuzzy feelings about that, however.

Apple users should not be complacent.  There are flaws yet to be discovered, and users are often the weakest link.  Malware, including viruses, can get into MacOS X and cause problems, although they are unlikely to ever be of the number and magnitude as bedevil Windows boxes (one recent article noted that vendors are getting around 125 new malware signatures a day—the majority are undoubtedly for Windows platforms).  And, of course, Mac machines (and Linux and….) also host browsers and other software that execute scripts and enable attacks.  Those who use MS Word have yet more concerns

The bottom line. No system is immune to attacks.  All users should be cautious and informed.  Apple systems still appear to be safer than their counterparts running Windows XP (the jury is out on Vista so far), and are definitely easier to maintain and use than similarly secured systems running Linux.  You should continue to use the system that is most appropriate for your needs and abilities, and that includes your abilities to understand and configure security features to meet your security needs.  For now, my personal systems continue to be a MacBook Pro (with XP and Vista running under Parallels) and a Sun Solaris machine.  Your own milage should—and probably will—vary.

I told you so

Share:

[tags]Windows, Office, malware, vulnerabilities[/tags]

This appeared in USA Today yesterday: Cyberspies exploit Microsoft Office.  This is yet more support for my earlier post.

So, are you ready to join the movement—stop sending Word documents in email?

Update 4/28: And here is yet another story of how Word files are being used against victims.

[posted with ecto]