Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection program success depends more on prudent management decisions than on the selection of technical safeguards. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.
It seems that in my business career, I have been smashed again and again by the stupid security decisions of other folks. As I write this article, I am in the process of being smashed again, and I am getting a bit tired of simply taking it because I am too small and powerless to mean enough to the vendors who screw me for them to give a damn about providing me with the service I pay for.
The current smashing comes at the hands a company called Authorize.Net that processes (processed by the time you read this) my credit card transactions when someone points and clicks to buy something from me over the Web. It seems that on all of 7 days notice, they decided to alter the way they process credit cards so that (1) all of the CD-ROMs with order forms, (2) all of the emails I used to use to send out order forms, and (3) all of the URLs that you should legitimately be abler to order things from me thorough... NO LONGER WORK!
Yes, you've got it. They implemented a stupid security measure without bothering to ask their customers about it and it will just about put me out of business for a time. Can I sue them? Nope. The contract says they can screw me. Could I get a temporary restraining order? I could try if I had a few tens of thousands of dollars to do it with. Am I screwed? You bet I am.
OK - so their stupid security trick of the week is to use the 'referrer' field of purchases to authenticate them. This is because some rude folks are sending lots of requests in using guesses about the legitimate vendor ID (typically an abbreviation of the name of the business). So sears probably has the ID 'sears' - pretty hard to guess - right? So the rude folks send in thousands of automated purchases with phony Visa numbers that pass the validity test (a free program you can find over the Internet will generate check codes for any Visa number you want). This wreaks havoc with the system which has to process all of these and results in lots of losses associated with backing out phony charges.
Now I have only gotten one bad charge and one bad check in about 20 years of taking Visa/MC and AmEx and processing checks for goods. The bad Visa cost me $7.99 and the bad check was for $2.25, so I don't see the big issue. These days I get orders for anywhere from $99 to $1500 and at those prices I can afford to check out the buyer to at least a limited extent. But I can understand their point of view. So naturally, their solution is...
NOT to change the IDs to make them harder to guess, which would make the pure guessing of IDs incredibly complex and have no ill effects on vendors if phased in over a reasonable amount of time.
NOT to create a simple verification step (like the user answering a question or entering a word that the computer generates as a graphic) that would eliminate all of these problems without creating systemic failures.
NOT to check with vendors on how they actually use the system and create a solution that won't cause interferences with their business models.
NOT to create a failure message that allows the merchant to recover the content and customer information so that the customer can complete their order.
NOT to create a link on the failure to allow the customer to complete their purchase legitimately.
NOT any of hundreds of other techniques that would solve their particular problem without impacting the customer or vendors that - after all - pay for their service.
They decided, instead, to check that the referrer field in the request comes from a user specified URL.
Now once you think about it, you might come to be a bit concerned about this.
OK - so I have called it stupid and inconvenient and indicated that it screws me because it doesn't work in my business model. But it's not just the thousands and thousands of merchants that will be unable to do business under this model. Naturally, I was the first person to even bring it up with them as a problem. I don't like being lied to like that - but suppose it's true - that I am the only vendor affected this way. But hang on...
Most sites have a fairly large number of possible referring URLs. Take for example Amazon.Com which has a different referral for each purchase you can make. So they would want to automate entry - yes? At least then they could enter in all 200 million URLs and authorize.net could check for any of them. But no... there is no automated entry, and no bulk entry, and no email them the list entry, and indeed, it takes about 10 mouse clicks to enter a URL. My carpel tunnel syndrome started to act up as I entered one after another...
So what did they do instead? After all, I am certainly not the only one with this problem, and their computer couldn't hold all the possible referrer URLs I have. And what if someone doesn't get referred there, but gets emailed the form? What if they get it from their E: drive under Windows from my CD? The answer is simple - it won't work... But they did have wild cards right? Nope.
After a few days of abuse from customers, they actually decided that you could put in the URL of your whole site and they would accept it. Of course www.all.net and all.net and web.all.net and fc.all.net and my.all.net and ... the list is rather long... all have to be entered now - no automation - no way to get them a list - no wild cards. And the emails and CDs won't work still.
Sure is effective though - right? No way! It turns out that if you can forge the rest of the 'post' request, it's pretty darned easy to forge the referrer field. I don't want to make it too easy for the bad guys, but since the UID 'sears' probably comes from... let me guess... 'www.sears.com' - I must just be lucky... how hard will it be for the bad guys to add 'referrer: www.sears.com' to their request? I give it 24 hours... make it 2.4 hours...
So what we have here is: (1) A stupid security measure that (2) Won't work to solve the problem they are trying to solve and (3) Screw the people that send them money. I only wish I could switch to another service provider in time... but like I said - the system is designed to screw folks like me - and it sure does that well at least.
OK - so my business gets screwed again - no big deal... after all, I don't do enough business to pay for my phone calls to them. But is must be rare - right? Guess again.
The AT&T from @home changeover put me off the air for a week.
The three area code changes in 2 years lost me lots of business related to advertisements that included phone numbers to call.
The ISP changeovers that messed up the way I had my computers rigged screwed me 3 times in 2 years, causing me to have to spend gobs of time making changeovers because they decided not to retain legacy capabilities during a changeover.
I don't want to bore you with the sheer stupidity associated with being in business. All businesses undergo such things. It's just part of what makes being in business... interesting... But when it comes to stupid things that don't work screwing customers, nothing - and I mean nothing - compares with security features.
I thought I would list 5 stupid security feature failures from my extensive book of stupid security tricks for the sheer entertainment value before getting to the point of this month's article.
1) To limit password guessing, accounts get locked out after 3 tries (give or take). The net effect - a trivial denial of services attack. The first time I tried it - the attack locked out the superuser account - forcing the superuser to use a back door they had left in the system in order to bypass all protection... (see item 2)
2) To prevent denial of access to superusers, the most dangerous accounts on many machines are left with back doors. Thus the most critical accounts are more easily broken into....
3) To force users to use hard-to-guess passwords, pseudo-random generators generate password for users. But since users can't remember these passwords very often, they write them down. So the countermeasure is to provide users with lists of generated passwords to choose from. The typical user goes through several hundred of these before choosing one they think they can remember - typically something like 'loveJoy1' or 'Meg&Bob' - resulting in passwords that are just as easy to guess as most of the ones the users would have chosen on their own anyway...
4) Physical security is, of course, vital to information security. That is why locks are placed on computers like the old style IBMs to prevent someone with physical access from turning the machine on and off. Of course the box has to have air flow to keep the processor from burning out too, and naturally the air flow vents are located all about the box for air flow efficiency. The result is that the electrical wires that the power control switch control are easily reachable through the air vents with a paper clip. Naturally, as a response to this problem they decided to use a more intimidating looking lock and key system...
5) In order to assure that safety is maintained, electrically locking doors commonly have a failsafe mode that allows people locked in to exit in case of power failures. This principle was so well ingrained in the engineers of one prison that... you must know the rest by now...
I could go on, but there is such a thing as cruelty to dumb animals to be considered here.
So what's the point? Easy. Stupid security can often be avoided by a simple process. It's called get a competent person to look at the issues and give them the mandate and funding required to do the job right.
Quick fix security, security on the cheap, security by the local computer guru, rapid 'security' changes once 100,000 customers are using your service, and similar things are all doomed to failure before they begin.
Stupid security often looks good at first glance, but it really doesn't take that much effort to vet such things with competent experts. Which brings me to my last story of the month. Drat - it's too late. Remind me some time and I will tell you a story of how 4 hours of consulting time with a competent security expert saved 30% of the world's PCs from becoming trivially disabled from over the Internet. No kidding!
About The Author:
Fred Cohen is researching information protection as a Principal Member of Technical Staff at Sandia National Laboratories, helping clients meet their information protection needs as the Managing Director of Fred Cohen and Associates, and educating cyber defenders over-the-Internet as a practitioner in residence in the University of New Haven's Forensic Sciences Program. He can be reached by sending email to fred at all.net or visiting http://all.net/