Don't Overlook This Authentication Vulnerability

Discussion in 'Computer Security' started by tripwire45, Dec 8, 2003.

  1. tripwire45
    Honorary Member

    tripwire45 Zettabyte Poster

    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


    - 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 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
    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,;EN-US;215383,
    you how to enable -- and disable -- Kerberos authentication on IIS 5.
    Note: The issue that prompted the article was fixed more than a year

    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", 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-298)
    Designing Security for a Microsoft Server 2003 Network" (Microsoft
    Press). Contact her at [email protected].
    Certifications: A+ and Network+

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.