Public access

Security picture of the day from a friend - or is that insecurity? Click it to magnify - yes, those are a user ID and password pair on the monitor. If you've got a great shot of a bad security practice, send it in!

Free lunch: Trust models that don't work

Both business and pleasure travelers are used to seeing bills at hotel restaurants that let you simply write down your room number and your name to charge the bill to your room. Most of us are used to seeing it, and we probably even wonder how often it is exploited.

In my case, it was exploited on a recent stay at an upscale hotel on the west coast during a conference.

My normal departure morning routine is to check the paper bill most hotels now slide under your door the morning of checkout. In my still sleepy daze, I glanced at the bill, expecting it to show a zero balance...

It carried a total of over $300 from the hotel restaurant, and a charge to my credit card for that amount.

This obviously wasn't right - I hadn't eaten in the hotel restaurant, and in fact, all the meals I had eaten had been provided as part of the conference, or by friends off site. Something odd was going on. As with most people, I first thought that there was likely a billing mistake, although the security analyst side of my brain started to ponder how a $300 charge had popped up.

A trip down to the desk and a chat with the clerk changed my initial reaction. They did, in fact have a receipt with my name, a signature, and my room number all filled out - in handwriting that wasn't mine, at a time I was in the conference, and with food for at least four people.

I would have remembered the crab and lobster, let alone the rest of the $300 of food and drinks that were signed for on that receipt.

In the end, the hotel handled it with reasonable aplomb, but I was stunned to see that there was absolutely no verification of the identity of people signing for large bills. This places the hotel itself on the losing end of transactions. If they had left the charge, I would have simply disputed it. As it was, they now have to investigate how someone got my name and room number.

A few simple controls could have prevented this:

• Check ID for anything charged to a room number.
  
• Allow people to elect to not allow anything beyond the room to be charged to their credit cards at check-in.
• Set a maximum charge limit, either by hotel policy, or for the person who pays for the room.

There is of course the danger of upsetting customers with new requirements like this, particularly at an upscale hotel where patrons are used to the service. Thus, some hotels would find that the optional security approach may be more acceptable to their patronage.

The other interesting thing about the incident is that in talking with hotel staff after the fact, one staff member had a very hard time believing that anybody would take advantage of this loophole. While I can understand that hotel staff members would generally not do this for fear of losing their jobs, I wasn't horribly surprised to find out that someone would try to take advantage of the loophole itself. In many cases, the bill would have been paid for using a corporate card, or possibly by a sponsor, and I wouldn't have ever noticed the discrepancy. The fact that the bill was mine meant that detection was much easier.

Next time you stay at a hotel, see how many times you are given the option of charging to your room - and how easily you can get access to the first initial, last name, and room number of anybody else you run into.

Open proxy honeypots

Most of us probably don't run open proxies ourselves - but if you're a higher education security analyst, you probably have at least one on campus, even if you'd prefer not to. That means that your threats may come from inside your border, and worse, that it may be open on purpose.

What do they get used for? Well, a great way to find out is to make an open proxy honeypot.

What can you do with an open proxy acting as a honeypot? Here's a great example - Ryan Barnett from the Web Application Security Consortium has a very interesting presentation available about traffic they observed through a proxy honeypot. It is well worth the read.

Most of us are headed down a road to securing the business side of our institutions, but the academic and student sides are often more problematic. We'll continue to see open proxies, both on our networks, and in use by our users. The good news is that the next time someone asks you about the dangers of open proxies, you'll have an excellent case study in hand.

Citysec - informal infosec group meetings

I haven't been to a Chisec meeting yet, but they sound like a great idea. There's also Indysec if you're a bit farther south.

Check out more on the Citysec website for the rest of the metro area infosec meetings - if there isn't one near you, maybe it is time to found a group!

RSnake and the phisherman

RSnake has a very interesting interview with a phisher on his blog.

There are a number of obviously interesting points - the high level of password re-use, the price that accounts can get, and that the anti-phishing technologies are starting to become annoying to the professional thief. I'm sure I'll be seeing the blog post quoted in more than one Powerpoint presentation this year.

What stood out to me, however, is why lithium got started - he saw an opportunity in the spam email his parents were receiving and thought that he could do it better. That's how many entrepreneurs get started, and is, in many ways how technical folks tend to think. This creates an arms race for technical superiority.

Where does RSnake's article leave us? I think it reminds us to remember that a lot of today's hacking world is built on a profit motive. While a certain crowd is definitely still in it for the fame, the more serious threats are from people who make their living stealing cycles, identities, and money.

Or, to put it another way...they get paid to do this. Is your organization treating external threats like they are professionals?

"Proprietary" encryption

Every security professional I know has heard the dreaded phrase "we use proprietary encryption" at least once in their career. Here are some of the best lines I've heard.

One vendor cited their "64 bit encryption plus three extra bits of proprietary security". Yes, they added three bits. Why stop there? Well, that was enough, right? They really, really hyped those extra bits - after all, three bits is better than two bit encryption.

Another vendor offered "proprietary encryption technologies that our programmers assure us are the very best in the industry" - however, they were completely uninterested in peer review, and would not document in any detail how their encryption was superior.

My all time favorite proprietary encryption line? "We didn't use the standards based encryption libraries included in our IDE because our programmers wrote a far superior 56 bit encryption scheme".

We didn't buy that product.

When vendors throw you lines like these, it is handy to have an acceptable encryption policy like the SANS example.

What are your best "proprietary encryption" stories?

If only tokens were cheap...

Token based authentication has been something that every large organization that I've worked with has considered, and often it is something that they have deployed. The problem is that the deployment has typically been very small scale, and that it was typically limited to a tiny subset of users. In organizations of every size, token cost was a major factor in deployment - either controlling size, or even the possibility of deployment.

The good news is that token cost won't be the controlling factor for small and mid-size installations much longer if Entrust's IdentityGuard Mini Token is any indicator. The list price for the token is $5. Yes, that's $5, on a one-off purchase, not in ridiculously large quantities. While I've seen the occasional note about some large purchasers pulling in pricing like this on existing tokens, you just haven't been able to buy tokens in smaller quantities for anything approaching $5.

That doesn't change the cost of the back end software, nor the cost of administrative time and implementation time. The good news is that if you were holding back because $35 tokens were too expensive to roll out, or because replacing them would cost too much when your students lost them, now they cost less than lunch - and they're even waterproof.

The gotcha? The tokens aren't available yet. The website takes you to a contact form. I'll take the wait, if this is the shape of things to come. Tokens that are priced reasonably enough to deploy system wide can help make password change policies much less onerous, and improve security if properly implemented. That's a cheap security improvement.

The importance of secondary routes

Network World is reporting that a fire caused when a homeless man threw a lit cigarette onto a mattress under a bridge has taken down Internet2 access between Boston and New York.

Yes. A burning mattress took down an important link for a major high speed network. No, this probably wasn't specifically covered in their design and operations risk assessment.

While high speed networks are expensive, this does demonstrate the vulnerability that purpose built dedicated links suffer from. If you only have one link, either because of cost or because of specialization, you need to have plans in place for when it goes down. Copper and fiber aren't invulnerable, and even when you think you're safe you can still get hit. Just when you think it is safe to cross your physical paths, someone will go dig there with a backhoe and cut your fiber.

Two stories come to my mind in which relatively unlikely events threatened or took down Internet access.

In the first, a semi hauling a backhoe went underneath a bridge that was lower than the backhoe's retracted and stored arm. The high speed impact with the bridge severed the fiber running underneath it, cutting off Internet access to a large chunk of Michigan.

In the second, a crew working on a a sewer line hit a gas line. In the process of attempting to fix the gas line, they dug and hit a fiber conduit. Fortunately, the slack in the fiber allowed it to pull just enough to remain operational, but a series of unfortunate events might have resulted in loss of Internet access for a major institution - in addition to a pretty nightmarish repair scenario with fiber and gas lines both broken.

Lessons learned? Always ask about single points of failure, identify alternate routes if possible and financially reasonable, and make sure you have an outage handling and recovery plan.

Phishes and loathes...

This post by Pascal Meunier over at CERIAS is well worth reading if you use a Visa credit card to make purchases online and the vendor uses the "Verified by Visa" program. The basic problem is that Visa's program presents itself like more of a phishing attempt than a legitimate fraud prevention tool. Worse than that, I think, is the fundamental implementation problems that Pascal notes in the update at the bottom of the article. Does anyone even test this stuff?

Update:
On the subject of phishing, it seems that banks and credit card companies still don't get it. I can find countless examples of unexpected emails from my banks that, from what I can tell are completely legitimate, but are full of "click here" and "login" links - the kinds that train the not-so-careful users to fall for phishing attacks in the first place. Maybe it's time I jumped on the ASCII ribbon campaign..

Erasing drives: This drive will self destruct in 1...2...3...

Drive wiping techniques are a frequent point of discussion in the information security community. Most IT staffers know about DBAN and there are plenty of both freeware and commercial tools out there.

If you need something different - either because the drive isn't in a system, or you want to centralize it, there are dedicated drive wiping systems like Ensconce's Digital Shredder . On the other end of the drive wiping spectrum are degaussers like these which are great for wiping drives that are no longer working, but still contain data, or for drives that you don't have interfaces for for your wiping system.

Yes, sometimes somebody shows up with a pile of Fiber Channel drives, or a Bernoulli disk, or some other for of media that you don't have a handy USB adapter for.

You can also have your drives physically destroyed - shredding and destruction companies will do this and will provide a receipt to demonstrate that they've been properly destroyed.

And then there's the drive that Ensconce Data Technology is promising. Sign me up for a self destructing hard drive!

How do you choose what is appropriate for your organization? As always, ask questions.

1. Do you have to follow any legal or statutory requirements? If so, make sure your strategy satisfies them.
   
2. Do you have internal policy requirements? If not, why don't you?
   
3. What are the security requirements of your data? Check your data handling guidelines.
4. What would exposed data cost your organization? Data recovery tools are available, and are easy enough to use that even those without significant technical knowledge can recover data from a drive if it hasn't been securely wiped.
   

With these answers in hand, you should be able to create policy - if you don't already have it, then create procedures and select appropriate technologies to support them.