Back door puts vendor on hot seat

It's not polite to poke fun at your vendors, but during a recent meeting with our Cisco reps, I couldn't resist. We had the reps in for a chat about some of Cisco's latest security products and our planned wireless LAN deployment. But my team and I had questions for them after reading news reports of a security problem with their Wireless LAN Solution Engine and Hosting Solution Engine products.

According to the stories, if you authenticate with a certain username and password coded into some versions of those products, you can take over the system. In other words, the products have a back door.

In my experience, there are three kinds of back doors: those introduced by lazy developers, those put in by clever hackers and those put in by stupid hacker/developers. As we met with the Cisco reps, I wondered which category best described their problem.

If you're a hacker and you manage to break into a box, how do you make sure you can come back when you like? The owner will likely patch the hole you used. If you add your own normal account, it might be spotted and turned off, so instead you slip in a back door. Provide the correct username and password, and you're in.

If you're a lazy developer and can't be bothered to set up and remember usernames and passwords on all of your systems, you might embed them into the development code so that you have a way into every system for debugging and fixing problems. This may be acceptable in prerelease code but should be removed from the final product.

A not-so-smart hacker/developer might leave a back door to use later. But a hard-coded username and password would be an unlikely choice for such a back door. It would be quite obvious within the code, and product managers could use even the most basic change-control systems to quickly identify who added it.

A clever hacker/developer, however, might include a subtle buffer overflow or race condition so that if it was discovered, he could say it was a programming error. Given the high number of buffer overflows in current software products, a few deliberately slipped in are hardly going to stand out.

To be fair, Cisco isn't the first company to be hit with this problem, and it did issue patches right away. During my early days in this business, back doors were a big worry. The one built into sendmail, for example, was high on every auditor's checklist. Supposedly, the program's author got tired of wasting time trying to help people who had been unable to get his software working, so he installed a back door that let him connect to the remote system by simply typing "wiz." The system would reply "Please pass, oh mighty wizard" and provide a root prompt so he could diagnose and repair e-mail delivery problems.

But Cisco really shouldn't have let this slip through. The company is a leading network security vendor, so if this problem was caused by a lazy coder, why didn't Cisco catch it in the code review? Given the apologetic faces and mumbling around the table when we poked fun at these security flaws, I'm pretty sure this has caused some changes within the Cisco product teams. I doubt that we'll be seeing this kind of problem again.

This week's journal is written by a real security manager, "Vince Tuesday," whose name and employer have been disguised for obvious reasons. Contact him at

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about SendMail

Show Comments