I am often berated by various people - usually my wife, my mother - and now, by some of Computerworld's readers. For the latter group, the issue is my lack of technical expertise. I continue to maintain that I don't need that much technical knowledge. Usually a little bit of common sense and a willingness to ask stupid questions serves just as well in my job.
To give you an idea of my level of technical knowledge, I can't program at all, in any language. I know what TCP/IP does but am a bit hazy on the differences among bridges, hubs and routers. I can never remember whether Unix uses "/" or "\."
 | | | This Week'sGlossary WAP: Wireless Application Protocol is a set of specifications, developed by Wireless Application Protocol Forum Ltd. in Mountain View, Calif., that lets developers using Wireless Markup Language build networked applications designed for handheld wireless devices. WAP 1.1 is a de facto standard, with support from more than 200 vendors, but security managers have concerns because a wireless transmission is vulnerable to an attack at the WAP gateway server. crypt(3): This Unix function for password encryption is based on the Data Encryption Standard algorithm. Considered older technology, it uses a 56-bit key, which generally isn't considered adequate by today's security standards. Here are two links to cryptography resources that Jude is researching for his ongoing smart-card project: Here is a good paper detailing cryptography's shortcomings. Here is a clear description by Steve Bellovin of the rationale behind cryptography. |
| |||
So when I'm asked to check the security of a new product to give personal digital assistants (PDA) and Wireless Application Protocol (WAP) phones access to our Microsoft Exchange mail servers, you'd be excused for thinking that I'm the wrong man for the job. I know next to nothing about WAP, and I even have problems figuring out most of the functions on my own PDA.
Despite my ignorance, I can identify three major security flaws in the product in about 10 minutes flat. When I question the vendor about these issues, it seems to take it a week to find anyone who can understand my questions, let alone give relevant answers.
I haven't yet worked out whether that means that I'm more technical than I think I am or that there's a startling lack of knowledge in the industry about anything that has to do with security.
Asking the Right Questions
The vendor - I've decided to keep it anonymous, since my point isn't to single out one company for criticism - strikes me as being in a rush to take advantage of the latest fad. When I question some of its design decisions, the most common reason given is "because it was easier that way."
For users at my company to get access to their Exchange e-mail from their PDAs, they first have to log in to our network. We've got that secured quite well. Then they have to log in to the vendor's server product - call it Server X. This server retrieves their mailboxes from Microsoft Exchange, performs a simple bit of conversion and displays it back to their PDAs in a format the device can understand.
My first question was about how you log in to Server X. Of course, Server X uses its own user identification and password - yet another one for users to remember. To check if you're the right user, it compares the password you supply when you log in with the password you originally set for your account. If they're the same, you're in. This is all relatively standard.
Of course, to be able to compare the two passwords against each other, the system has to be able to store the original password.
Storing a list of passwords is a dangerous thing: Any attacker who can get at the list can then impersonate any other user. So it encrypts the passwords using an algorithm known as a one-way function, then hides the password file. Almost every password-based system uses a close variation on this method.
However, the actual method the vendor uses to encrypt and hide the passwords is a new variant to me. It uses the crypt(3) algorithm, which has been in use since 1975 and should long since have been put out to pasture.
A stranger decision is the place the vendor chose to hide the encrypted passwords. It may sound odd, but you do need to hide passwords even after they have been encrypted.
Even one-way encrypted passwords can be attacked, so hiding them makes an attacker's life that much more difficult. The Server X vendor chose to store its encrypted passwords in what the vendor's representatives describe as a "hidden" custom attribute in Microsoft Exchange.
Microsoft has allowed for 15 custom attributes, but the designers of the dialog box provided enough space to display only 10 attributes.
One might assume that the other five are hidden. However, you can choose which 10 attributes to display. And Microsoft even provides functionality in Exchange to display any 10 of the 15 attributes by default. So they're not exactly hidden.
Stranger yet is the means by which a mailbox is retrieved from Exchange. Rather than use the individual's Exchange accounts to retrieve his mail, the system uses a single, generic Exchange account referred to as a "courier account."
The vendor even recommends that, for simplicity's sake, this courier account be given unlimited access to all Exchange mailboxes.
Security Implications
The implications of using one account are wide-reaching. Not only does it give attackers yet another powerful target account that could be used to compromise the entire e-mail system, but it also defeats Exchange's granular access control and makes a mockery of its logging capabilities.
I can allow certain people access to my folders in Exchange so that they can read some, but not all, of my mail; these privileges are stored with their user IDs. If they're accessing Exchange via this generic courier account, this whole privilege-granting process is completely bypassed.
As for logging, any significant action that I perform on an Exchange server is logged. The logs store details of the action along with the date, time and my user ID. If I do something foolish, we can use the logs to trace the action back to me. But if I'm accessing Exchange through Server X, then its courier account will show up as being responsible for the action, not me.
These weaknesses actually go well beyond just compromising the security of Server X because they actually damage the security of the Exchange server as well.
We can only hope that the vendor will fix some of these weaknesses in the next release of the product.
Whenever someone takes me to task for not being technical enough, I smile. At the moment, I know much more than I need to in order to defeat these systems.
The point I'm trying to make is that security is more about an attitude than any particular skill set. I overheard one of our engineers asking about a new piece of software the other day. She started off by asking some quite basic questions, completely unafraid of displaying her ignorance about the product. But she kept asking questions until she understood what the software did and how it did it, and she kept trying to work out the consequences of various potential system failures.
Although she does have detailed technical knowledge in her particular specialty, that confident ability to ask stupid questions and think through the answers will always be much more useful to me than her specialist knowledge.
I look forward to the day when vendors develop systems that are good enough to make me need more technical knowledge.
• This journal is written by a real security manager, whose name and employer have been disguised for obvious reasons. It's posted weekly at www.computerworld.com to help you and our security manager - let's call him Jude Thaddeus - better solve security problems. Contact Jude at jude.t@lycos.com or click on Computerworld.com's Security Watch community forum to participate in discussion topics.