[tags]Google, spam[/tags]
Today I received email from a google.com address. The sender said he had found me by doing a search on the WWW. He indicated he hoped I wasn't offended by his sending unsolicited email. However, he had a great offer for me, one that I was uniquely qualified for, and then offered a couple of URLs.

Does that sound familiar?

My first thought was that it was a 419 scam (the usual “I am the son of the crown prince of Nigeria...” letters). However, after checking out the mail headers and the enclosed URLs, it appears to be a (semi) legit letter from a Google recruiter. He was asking if I was open to considering a new, exciting position with Google.

And what exciting new position does the Google recruiter think I'm ideally suited for? Starting system administrator.....

And by the way, sending email to “abuse@google.com” gets an automated response that states, in no uncertain terms, that Google never sends spam and that I should take my complaints elsewhere.

Gee, think this is a new career possibility for me?

[posted with ecto]

[tags]cyber security reseach, PITAC[/tags]

I strongly urge you to read Jim Horning's blog entry about a recent Congressional hearing on cyber security research -- his blog is Nothing is as simple as we hope it will be. (Jim posts lots of interesting items -- you should add his blog to your list.)

I have been visiting Federal offices and speaking before Congress for almost 20 years trying to raise some awareness of the importance of addressing information security research. More recently, I was a member of the President's Information Technology Advisory Committee (PITAC). We studied the current funding of cybersecurity research and the magnitude of the problem. Not only was our report largely ignored by both Congress and the President, the PITAC was disbanded. For whatever reason, the current Administration is markedly unsupportive of cyber security research, and might even be classed as hostile to those who draw attention to this lack of support.

Of course, there are many other such reports from other august groups that state basically the same as the PITAC report. No matter who has issued the reports, Congress and the Executive Branch have largely failed to address the issues.

Thus, it is heartening to read of Chairman Langevin's comments. However, I'm not going to get my hopes up.

Be sure to also read Dan Geer's written testimony. It touches on many of the same themes he has spoken about in recent years, including his closing keynote at our annual CERIAS Security Symposium (save the dates -- March 19 & 20, 2008 -- for the next symposium).

Copyright © 2007 by E. H. Spafford
[posted with ecto]

CERIAS Reports & Papers

• "Defense Science Study Group 2004-2005 Papers 1-11"
  30 April 2007, 7:00 pm
• "Using artificial neural networks for forensic file type identification"
  29 April 2007, 7:00 pm
• "Enabling Confidentiality of Data Delivery in an Overlay Broadcasting System"
  28 April 2007, 7:00 pm
• "Feasibility of DDoS attacks using P2P Systems and Prevention through Robust Membership ...
  28 April 2007, 7:00 pm

CERIAS Weblogs

• “Verified by VISA” Issues
  3 May 2007, 3:10 pm
• More on passwords
  1 May 2007, 1:11 pm
• Quicktime flaw on Macs brings out the crazies
  27 April 2007, 1:27 pm

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!

[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.