Don't Overlook This Authentication Vulnerability

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I got this as an e-mail from these folks:

Here's the article by Security Guru Roberta Bragg:

Don't Overlook This Authentication Vulnerability
**By Roberta Bragg

It's a puzzle. Sometimes I feel like a research scientist fast on the
track of some new disease. There's a missing factor, but I'm close to
making an important discovery. Then, in one horrifying moment, I
realize I've got the first symptoms of the disease. Will I discover the
cure, or die too soon?

I've been getting that feeling a lot lately. There's significant
progress in the development of recommended security controls (see the
new "Security Paper of the Week" entry below) and I'm cheered, then I

read:

- Cisco announces a flaw whereby the Wireless Encryption Privacy (WEP)
key is passed in the clear for some versions of Aironet

- The Linux kernel, it seems, has a huge security issue that may impact
all Linux releases

- Installing SharePoint Services 2.0, Windows Server 2003 and Exchange
2003 disables Kerberos and allows Outlook Web Access (OWA) users to
read each other's mail. What?

Yup, apparently that particular combination creates a problem. Kerberos
gets disabled and authentication falls back to NTLM. Microsoft tells us
it's not NTLM that causes the problem; it's using NTLM when Kerberos
isn't enabled. At any rate, my purpose here isn't to call attention to
this particular vulnerability (see
www.microsoft.com/exchange/support/ek23owa.asp for specific information
and a workaround. No doubt a security patch will be forthcoming). It's
to ask the question: To which vulnerability announcements should you
pay attention?

My first inclination is to ignore all three listed above. I'm not
responsible for any Linux boxes or Cisco Aironet right now, and none of
my customers are using that particular Exchange combination. And, well,
I've got enough other vulnerability issues to deal with at the moment.
I'd be willing to bet that you make the same type of decision all the
time. Like me, you ignore vulnerability reports that don't appear to
impact your systems. Sometimes, however, our subconscious is our savior
-- it got me up at 2 a.m. and made me look a little further. What I
found out scares me.

Oh, it's not what I feared about Microsoft vulnerabilities that woke me
up in a cold sweat last night; it's that I think I've found where this
vulnerability might impact me, and I almost ignored it. See, according
to the Microsoft documentation, this problem occurs because Kerberos
gets disabled; that causes OWA requests to be incorrectly handled. The
normal Windows-Integrated authentication process negotiates Kerberos or
NTLM, depending on the capabilities of the client. Apparently, there's
no problem with this process. The problem happens if the negotiation
doesn't occur, because Kerberos is disabled.

So I'm thinking, Where else might Kerberos get disabled, and what
additional software might then "incorrectly handle" authentication
requests? You should start looking for potential vulnerabilities in
custom-written IIS apps. If you've disabled Kerberos to make these
applications work, you might have a problem -- or not. I don't know.
I'm just suggesting that you do tests. Possible situations where you
might have disabled Kerberos could include:

- You're running applications written for IIS 6.0 that use application
pool identities. Application pool identities are accounts used by IIS
applications, configured to run in worker process isolation mode. By
default, such an application will use the Network Service account, but
they can be configured to use a Windows account you've created. If
you're running multiple Web sites on a single server, you probably did
so. For more information on application pool identities, see
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prod
technol/windowsserver2003/proddocs/standard/ca_cfgwrkridentity.asp (cut
and paste this, and any other, URLs that break into your browser).

If your application uses such an account, and you haven't configured a
Service Principal Name (SPN) for the account, you may have disabled
Kerberos authentication to make your system work. Coincidentally, if
you didn't disable Kerberos, but set up the application pool identity
with an SPN, you may have also had to make the IIS server and
application pool identity trusted for delegation. That may pose its own
security issues.

- You disabled Kerberos authentication on the Web server (IIS 5 or 6).
Knowledge Base 215383,
http://support.microsoft.com/default.aspx?scid=kb;EN-US;215383,
tells
you how to enable -- and disable -- Kerberos authentication on IIS 5.
Note: The issue that prompted the article was fixed more than a year
ago.

So what if you don't use IIS 6 or write custom applications for it?
Well, are any commercial applications you're using that might have
disabled Kerberos? Would they tell you if they were? You can find out
by using the instructions included at the Exchange URL mentioned above.
You should note that, even if they're doing so, there may not be a
problem. But I know I'd take a closer look. And I know I'm going to
take more time examining whether I should evaluate an announced
vulnerability. I wonder if any other wireless access points send the
WEP key in the clear?

*Announcing: A new feature to this column. It's called "The Security
Article of the Week." This section will merely be a simple notification
of something you may want to read. It could be a new book, a new
standard or a really super article. It will never be a vulnerability
announcement or a putdown of any company. It will simply be a title,
where to find it, and a single sentence about the article/book. I'll
start off with this week's announcement, but I welcome your suggestions
for inclusion here. I'll include your name as contributor only if you
specifically ask me to do so. Otherwise, I'll leave it off as per
Security Watch policy. I will read, or at least skim, proposed
articles, so if I can't locate it, it won't be mentioned. Please don't
send it to me in an e-mail: I don't open attachments. But do let me
hear from you, and remember to include the URL.

Security Article of the Week: Read and send in your comments to NIST on
"Recommended Security Controls for Federal Information Systems",
http://www.csrc.nist.gov/publications/drafts.html. This is
a 200-plus-
page draft of the controls that will be recommended for U.S. Federal
information systems.

-- Roberta Bragg, MCSE: Security, CISSP, Security+, and contributing
editor for MCP Magazine, owns Have Computer Will Travel, Inc., an
independent firm specializing in information security and operating
systems. Her newest books are "Network Security: The Complete
Reference" (McGraw Hill), and "MSCE Training Kit (EXAM 70-29
Designing Security for a Microsoft Server 2003 Network" (Microsoft
Press). Contact her at [email protected].