CERIAS Weblogs » 2007 » May

Jim Horning suggested a topic to me a few weeks ago as a result of some email I sent him.

First, as background, consider that phishing and related frauds are increasingly frequent criminal activities on the WWW. The basic mechanism is to fool someone into visiting a WWW page that looks like it belongs to a legitimate organization with which the user does business. The page has fields requesting sensitive information from the user, which is then used by the criminals to commit credit card fraud, bank fraud or identity theft.

Increasingly, we have seen that phishing email and sites are also set up to insert malware into susceptible hosts. IE on Windows is the prime target, but attacks are out there for many different browsers and systems. The malware that is dropped can be bot clients, screen scrapers (to capture keystrokes at legitimate pages), and html injectors (to modify legitimate pages to ask for additional information). It is important to try to keep from getting any of this malware onto your system. One aspect of this is to be careful clicking on URLs in your email, even if they seem to come from trusted sources because email can be spoofed, and mail can be sent by bots on known machines.

How do you check a URL? Well, there are some programs that help, but the low-tech way is to look at the raw text of a URL before you visit it, to ensure that it references the site and domain you expected.

But consider the case of short-cut URLs. There are many sites out there offering variations on this concept, with the two I have seen used most often being “TinyURL” and “SnipURL”. The idea is that if you have a very long URL that may get broken when sent in email, or that is simply too difficult to remember, you submit it to one of these services and you get a shortened URL back. With some services, you can even suggest a nickname. So, for example, short links to the top level of my blog are <http://tinyurl.com/2geym5>, <http://snipurl.com/1ms17> and <http://snurl.com/spafblog>.

So far, this is really helpful. As someone who has had URLs mangled in email, I like this functionality.

But now, let’s look at the dark side. If Jim gets email that looks like it is from me, with a message that says “Hey Jim, get a load of this!” with one of these short URLs, he cannot tell by looking at the URL whether it points somewhere safe or not. If he visits it, it could be a site that is dangerous to visit (Well, most URLs I send out are dangerous in one way or another, but I mean dangerous to his computer. :-)). The folks at TinyURL have tried to address this by adding a feature so that if you visit <http://preview.tinyurl.com/2geym5> you will get a preview of what the URL resolves to; you can set this (with cookies) as your default. That helps some.

But now step deeper into paranoia. Suppose one of these sites was founded by fraudsters with the intent of luring people into using it. Or the site gets acquired by fraudsters, or hijacked. The code could be changed so that every time someone visits one of these URLs, some code at the redirect site determines the requesting browser, captures some information about the end system, then injects some malicious javacode or ActiveX before passing the connection to the “real” site. Done correctly, this would result in largely transparent compromise of the user system. According to the SnipURL statistics page, as of midnight on May 30th there have been nearly a billion clicks on their shortened URLs. That’s a lot of potential compromises!

Of course, one of the factors to make this kind of attack work is for the victim to be running a vulnerable browser. Unfortunately, there have been many vulnerabilities found for both IE and Firefox, as well as some of the less well-known browsers. With users seeking more functionality in their browsers, and web designers seeking more latitude in what they deliver, we are likely to continue to see browser exploits. Thus, there is likely to be enough of a vulnerable population to make this worthwhile. (And what browser are you using to read this with?)

I should make it clear that I am not suggesting that any of these services really are being used maliciously or for purposes of fraud. I am a happy and frequent user of both TinyURL and SnipURL myself. I have no reason to suspect anything untoward from those sites, and I certainly don’t mean to suggest anything sinister. (But note that neither can I offer any assurances about their motives, coding, or conduct.) Caveat emptor.

This post is simply intended as commentary on security practices. Thinking about security means looking more deeply into possible attack vectors. And one of the best ways to commit such attacks is to habituate people into believing something is safe, then exploiting that implicit trust relationship for bad purposes.

Hmm, reminds me of a woman I used to date. She wasn’t what she appeared, either…. But that’s a story for a different post.

[posted with ecto]

In my last post, I ranted about a government site making documents available only in Word. A few people have said to me “Get over it — use OpenOffice instead of the Microsoft products.” The problem is that those are potentially dangerous too — there is too much functionality (some of it may be undocumented, too) in Word (and Office) documents.

Now, we have a virus specific to OpenOffice. We’ve had viruses that run in emulators, too. Trying to be compatible with something fundamentally flawed is not a security solution. That’s also my objection to virtualization as a “solution” to malware.

I don’t mean to be unduly pejorative, but as the saying goes, even if you put lipstick on a pig, it is still a pig.

Word and the other Office components are useful programs, but if MS really cared about security, they would include a transport encoding that didn’t include macros and potentially executable attachments — and encourage its use! RTF is probably that encoding for text documents, but it is not obvious to the average user that it should be used instead of .doc format for exchanging files. And what is there for Excel, Powerpoint, etc?

Earlier, I wrote about the security risks of using Microsoft Word documents as a presentation and encoding format for sending files via email (see posts here and here). Files in “.doc” format contain macros, among other things, that could be executable. They also have metadata fields that might give away sensitive information, and a lot of undocumented cruft that may be used in the process of exploiting security. It is no wonder that exotic exploits are showing up for Word documents. And only today it was revealed that the latest version of Office 2007 may not have even gotten the most recent patch set.

Want to find some vulnerabilities in Word? Then take a look at the list of US-CERT alerts on that software; my search returns almost 400 hits. Some of these are not yet patched, and there are likely many as-yet unpatched flaws still in there.

Clearly, the use of Word as a document exchange medium is Bad (that’s with a definite capital B). People who understand good security practices do not exchange Word files unless they are doing collaborative editing, and even then it is better to use RTF (if one continues to be beholden to Microsoft formats). Good security hygiene means warning others, and setting a good example.

Now, consider that DHS has released BAA07-09 to solicit research and prototypes to get fixes for current cyber infrastructure vulnerabilities. I could rant about how they claim it is for R&D but is really a BAA for further product development for fundamentally flawed software that cannot be fixed. But that isn’t the worst part. No, the BAA is only available as Word documents!

Can you say “irony”? This is the agency charged with helping guide us to a more secure infrastructure? If so, electronically KYAG.

Update: A response from Dr. Douglas Maughn at DHS points out that the site I indicated for the BAA is actually FedBizOps rather than DHS. The DHS posting site actually has it in PDF…although the FedBizOps link is the one I’ve seen in several articles (and in a posting in SANS NewsBites).

Of course, it would be great if DHS could get the folks at FedBizOps to clean up their act, but at least in this case, DHS — or rather, DHSARPA — got it right. I stand corrected.

One of our students who works in biometrics passed along two interesting article links. This article describes how a password-protected, supposedly very secure USB memory stick was almost trivially hacked. This second article by the same author describes how a USB stick protected by a biometric was also trivially hacked. I’m not in a position to recreate the procedure described on those pages, so I can’t say for certain that the reality is as presented. (NB: simply because something is on the WWW doesn’t mean it is true, accurate, or complete. The rumor earlier this week about a delay in the iPhone release is a good example.) However, the details certainly ring true.

We have a lot of people who are “security experts” or who are marketing security-related products who really don’t understand what security is all about. Security is about reducing risk of untoward events in a given system. To make this work, one needs to actually understand all the risks, the likelihood of them occurring, and the resultant losses. Securing one component against obvious attacks is not sufficient. Furthermore, failing to think about relatively trivial physical attacks is a huge loophole — theft, loss or damage of devices is simple, and the skills to disassemble something to get at the components inside is certainly not a restricted “black art.” Consider the rash of losses and thefts of disks (and enclosing laptops) we have seen over the last year or two, with this one being one of the most recent.

Good security takes into account people, events, environment, and the physical world. Poor security is usually easy to circumvent by attacking one of those avenues. Despite publicity to the contrary, not all security problems are caused by weak encryption and buffer overflows!

[posted with ecto]

I recently blogged about some unsolicited email I received from a recruiter at Google. Much to my surprised, I was shortly thereafter contacted by two senior executives at Google (both of whom I know). Each apologized for the contact I had received; one assured me he would put in a positive recommendation if I wanted that sys admin position.

I have been assured that there will be some re-examination made of how these contacts are made. So, score one for my blog changing the world! Or something like it.

[posted with ecto]

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]

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!

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.