Cisco Adaptive Security Appliance Software Kerberos Authentication Bypass Vulnerability

A vulnerability in the Kerberos authentication feature of Cisco Adaptive Security Appliance (ASA) Software could allow an unauthenticated, remote attacker to impersonate the Kerberos key distribution center (KDC) and bypass authentication on an affected device that is configured to perform Kerberos authentication for VPN or local device access.

The vulnerability is due to insufficient identity verification of the KDC when a successful authentication response is received. An attacker could exploit this vulnerability by spoofing the KDC server response to the ASA device. This malicious response would not have been authenticated by the KDC. A successful attack could allow an attacker to bypass Kerberos authentication.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

Note: Configuration changes after the software upgrade are necessary to address this vulnerability. See the Details section of this advisory for additional information.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-asa-kerberos-bypass-96Gghe2sS

This advisory is part of the May 2020 Cisco ASA, FMC, and FTD Software Security Advisory Bundled Publication, which includes 12 Cisco Security Advisories that describe 12 vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: May 2020 Cisco ASA, FMC, and FTD Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2020-3125

Related:

  • No Related Posts

7022332: Kerberos Automatic Sign-on Support for IBM i

Setting Up Automatic Sign-On

Follow the suggestions in the following sections to configure the Reflection for the Web automatic sign-on feature.

System Requirements

The following are system requirements for Reflection automatic sign-on support.

IBM i

  • OS/400 (i5/OS) V5R2 or higher, with the most recent PTF package
  • IBM i Navigator to configure Network Authentication Service (NAS) and Enterprise Identity Mapping (EIM)

KDC

  • The KDC must support Kerberos 5

Microsoft Windows Client

  • Microsoft Windows 8, 7, 2000, or XP
  • User must login to a domain with a domain account

Configuring IBM i

Before configuring Reflection to use automatic sign-on, access the IBM i Navigator using an administrative ID and address these topics for the Kerberos realm and IBM i.

  • Create a Microsoft Windows user and principal for the Kerberos realm for your IBM i Server.
  • Configure NAS on your IBM i.
  • Configure an EIM Domain Controller and Domain on your IBM i.
  • Configure the EIM Domain with Identifiers and Associations for each user.

For more information on these topics, see the IBM i Information Center:

Additionally, IT Jungle has the following series of articles available on this topic:

Configuring Windows for Reflection Automatic Sign-On

This section explains how to configure Microsoft Windows so that Reflection for the Web can use the Kerberos ticket for authentication and access. If you are not running Reflection in a Microsoft Windows Domain, skip to Create a Reflection Session with Kerberos Automatic Sign-On. Otherwise, follow the steps below.

I. Configure Accounts to Use DES Encryption

The features of Kerberos that are used by Reflection for the Web require that Windows user accounts be configured to use DES encryption. By default, Windows uses RSA emulation.

To configure user accounts to use DES encryption, you need to perform the following steps on the server hosting Active Directory, for each user account. These steps can be performed by modifying group or system-wide policies.

  1. Click Start > Programs > Administrative Tools > Active Directory Users and Computers.
  2. Select an account user, right-click, and then click Properties.
  3. Click the Account tab.
  4. In the Account options scroll box, enable “Use DES encryption types for this account.”

Note: If you do not want to require pre-authentication before issuing a TGT, you must also enable “Do not require Kerberos preauthentication” for each user. However, enabling this setting decreases the security of your Kerberos configuration

II. Modify the Windows Clients to Export the Session Key

By default, Microsoft Windows Server 2003, Windows 2000 Server SP4 and Windows XP SP2 are configured not to export the TGT session key for access by other programs. As a result, the TGT obtained on Windows has a blank session key.

Follow these steps to update the Windows registry and configure Windows to allow other programs access to the TGT session key information.

Warning: Proceed with extreme caution when editing the Windows Registry. It is critical to back up the Registry before you proceed. For full details and warnings regarding editing the Windows Registry, see Microsoft Article 256986:

http://support.microsoft.com/default.aspx?scid=kb;en-us;256986

  1. Click Start > Run.
  2. In the Open field, enter regedit, and then click OK.
  3. Navigate to the Windows registry location specified below for your operating system.

For Windows 8, Windows 7, Windows Server 2003, and Windows 2000 SP4:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberosParameters

For Windows XP SP2:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlLsaKerberos
  1. If the DWORD allowTGTSessionKey already exists, skip to step 6. Otherwise, right-click Kerberos, click New > DWORD Value.
  2. Change the DWORD name to allowTGTSessionKey.
  3. Right-click allowTGTSessionKey > Modify.
  4. In the Value data field, enter 1. (The default is 0.)
  5. Exit the Windows registry.

III. Export the Updated Registry Settings to Users

Export the updated Windows registry key, and use Windows Active Directory, SMS, or any other method to push the registry updates out to the Reflection for the Web client workstations.

Create a Reflection Session with Kerberos Automatic Sign-On

Follow the steps below to create a Reflection for the Web 2011 or 2008 session with Kerberos automatic sign-on enabled.

  1. Start the Reflection for the Web management server and log in as an administrator.
  2. Click Administrative WebStation.
  3. Click Session Manager and then click Add.
  4. Select IBM 5250, enter a Session name, click Continue, and then click Launch.
  5. In the Connection (or Session) Setup dialog box, enter the fully qualified host name or IP address (for example, bluebell.wa.com), and then click Advanced (or More) Settings.
  6. In Reflection for the Web, click the “Kerberos sign-on options” button.
  7. Select the “Enable Kerberos automatic sign-on” check box, and then select the Specify realm and KDC radio button.
  8. In the Kerberos realm field, enter the fully qualified domain name (FQDN) of the Kerberos realm using all capitals. For example, FLOWERS.WA.COM.
  9. In the Kerberos KDC field, enter the KDC server’s FQDN.
  10. Click OK > OK.

Testing the Connection

To verify that your session has been successfully set up for Kerberos automatic sign-on, logon to the domain and then start up the session. You should be logged in automatically to the IBM i host.

Troubleshooting Errors

This section provides troubleshooting steps and resources for several common errors.

Error
KDC has no support for encryption type (14)
Cause
This error occurs in Windows domains if the Windows encryption method is not changed from RSA RC4 to DES or the registry is not updated to export the session key.

To view the current TGT, and determine the current encryption type or visibility, use the Microsoft Kerbtray utility. To obtain and use Kerbtray, follow these steps.

1. Download the Windows Server 2003 Resource Kit Tools from Microsoft Downloads at:

http://www.microsoft.com/downloads/details.aspx?FamilyID

=9d467a69-57ff-4ae7-96ee-b18c4790cffd

2. Install the Resource Kit.

3. Click Start > Programs > Windows Resource Kit Tools > Command Shell, and then enter
kerbtray.

4. Select the TGT you want to view, and then click the Encryption Types tab.

The encryption type is shown in the Key Encryption Type field.

Resolution
To resolve this problem, follow the steps in Configuring Windows for Reflection Automatic Sign-On.

Error
Could not load configuration file krb5.conf.
Cause
Reflection is looking for a krb5.conf file because the “Use default realm and KDC in Kerberos configuration file” radio button is selected in the Reflection for the Reflection for the Web Connection > Session Setup > More Settings dialog box.
Resolution
Provide a krb5.conf configuration file in the expected location or specify a realm and KDC for this setting.
Error
Pre authentication information was invalid (24)
Cause
User is not logged in to the domain when running the IBM i session.
Resolution
Log on to the domain and try again.

For further troubleshooting errors and details, see Sun’s Java Kerberos troubleshooting information at:

http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/tutorials/Troubleshooting.html

Related:

7021997: Using the GSSAPI Tab in Reflection and Reflection for Secure IT

Enable GSSAPI/Kerberos Authentication

By default, GSSAPI/Kerberos authentication is not enabled in Reflection Secure Shell settings. To enable GSSAPI/Kerberos as a user authentication method,

  1. Open the Reflection Secure Shell Settings dialog box.
  2. Click the General tab.
  3. Select the GSSAPI/Kerberos check box under User authentication.
View Full Size

Figure 1 – Enable GSSAPI/Kerberos in Reflection Secure Shell Settings Dialog Box
Figure 1 – Enable GSSAPI/Kerberos in Reflection Secure Shell Settings Dialog Box

GSSAPI Tab

Use the GSSAPI tab of the Reflection Secure Shell Settings dialog box to specify settings for GSSAPI/Kerberos authentication.

View Full Size

Figure 2 - Specify GSSAPI/Kerberos settings on GSSAPI tab
Figure 2 – Specify GSSAPI/Kerberos settings on GSSAPI tab

Note: Items on this tab are available only if GSSAPI/Kerberos is selected in the User authentication list on the General tab.

Use the options in the Provider section of the GSSAPI tab to specify whether GSSAPI authentication is handled by the Microsoft Security Support Provider Interface (SSPI) or the Reflection Kerberos client:

SSPI—When SSPI is selected, Reflection uses your Windows domain login credentials to authenticate to the Secure Shell server. You can select this option if you log onto a Microsoft Windows 2008 or 2003 domain. Using this setting simplifies setup; there is no need to configure the Reflection Kerberos client.

Reflection Kerberos—When Reflection Kerberos is selected, Reflection uses the Reflection Kerberos client for Kerberos/GSSAPI authentication. Before you can make connections using the Reflection Kerberos client, you must configure Reflection Kerberos. You can use the Configure button to configure Kerberos if it has not yet been configured on your system, or to modify your existing Kerberos configuration.

Delegate credentials—This setting specifies whether or not GSSAPI forwards your Kerberos ticket granting ticket (TGT) to the host. Ticket forwarding is enabled by default. Clear this setting to disable ticket forwarding.

This setting affects only Secure Shell protocol 2 (ssh2) connections.

Use Default service principal name—The service principal name is the name Reflection uses when it sends a request for a service ticket to the Kerberos Key Distribution Center (KDC). The format is hostname@realm. The hostname value is the name of the Secure Shell server to which you are connecting. The realm value depends on which GSSAPI provider you have selected:

  • If you are using Reflection Kerberos, the realm name is specified in your default principal profile.
  • If you are using SSPI, the realm name is your Windows domain name.

Use the Service principal setting to specify a non-default service principal name. If you have selected SSPI for your GSSAPI provider, you can use this setting to specify a service principal in a realm that is different from the Windows domain. Use a fully qualified host name followed by @ then the realm name, for example: myhost.myrealm.com@MYREALM.COM.

Related:

7021626: Third-Party Kerberos Software for Reflection Security Features

Kerberized Software and Servers

The companies listed below supply Kerberos server software and kerberized application servers. These products provide a complete solution for use with kerberized Reflection products.

MIT Public Domain Reference Implementation

MIT develops Kerberos 5 KDC and kerberized application servers. Reflection Kerberos provides support for the MIT Kerberos 5 reference releases, which are academic demonstration UNIX software with very limited support. Attachmate has tested and approved the krb5-1.0.x, through 1.8 releases of MIT’s Kerberos implementations. For more information, visit the MIT Kerberos web site:

Microsoft Corporation

Microsoft’s Windows 2000, 2003, and 2008 Active Directory servers use Kerberos for authentication of users on Windows operating systems and thus may be used as Kerberos KDCs. Currently, Microsoft does not provide kerberized Telnet or FTP servers. For information about Microsoft’s Kerberos implementations, visit the Microsoft web site:

Microsoft also provides information about configuring Microsoft and MIT KDCs and servers for interoperability on the following web page:

Centrify DirectControl

Centrify DirectControl provides a service that allows Kerberos applications to work transparently with Microsoft Active Directory. The Centrify site offers more information:

Quest Authentication Services

Quest Software offers Quest Authentication Services (formerly Vintela Authentication Services – VAS) for Microsoft Active Directory, integrating Unix/Linux platforms with Microsoft Active Directory. Quest Authentication Services uses Kerberos to protect user credentials. For more information, visit the Quest Software site:

CyberSafe Corporation

CyberSave offers a wide range of Kerberos products and services. The products known as TrustBroker™, previously known as Challenger and ActiveTRUST, are Attachmate tested and approved. For more information, visit the CyberSafe Corporation web site:

Hewlett-Packard Company

HP supports Kerberos and offers Kerberos Server Version 2.0 for HP-UX 11i, based on MIT Kerberos v5 Release 1.2.2. For more information, visit the HP web site:

In addition, HP offers Kerberos version 2.0 for OpenVMS Alpha version 7.2-2 and higher, based on the MIT Kerberos v5 Release 1.2.6 (plus security patches provided in Release 1.2.7 and 1.2.8). For more information, visit the HP web site:

Sun Microsystems

Sun supports Kerberos 5 and kerberized application servers with the Sun Enterprise Authentication Mechanism (SEAM) product. This is delivered with Solaris 8, 9, or 10 but can be retrofitted to Solaris 2.6 and 7 operating systems. For more information, visit the Sun web site:

IBM

IBM supports Kerberos 5 and kerberized application servers for AIX 4.3.3, and 5.x and 6.x with the Network Authentication Service version 1.x. It comes packaged with the AIX 4.3.3 Bonus Packs. For more information, visit the IBM web site:

Cygnus Solutions KerbNet

Cygnus produced Kerberos 5 KDC and kerberized application servers. Reflection Kerberos provides support for the KerbNet version 1.2 release, which was a short-lived commercial implementation of the MIT 1.0.2 reference-level UNIX software. This product is no longer available, and there is no support for it. Attachmate has tested and approved the 1.2 release of the KerbNet Kerberos implementation. Cygnus Solution has since merged with RedHat. Source and binary distributions are no longer available for download.

DCE Security Environments

The following companies provide DCE (Distributed Computing Environment) Security environments, which can provide Kerberos 5 credentials for use with Reflection Kerberos. However, these companies’ products rely on DCE RPC (Remote Procedure Call) technology alone, and do not include a kerberized Telnet or FTP server. To use these products with kerberized Reflection products, you must have a kerberized application server.

Note that only authentication is available with DCE implementations. Data stream encryption using Kerberos protocol is not supported by DCE servers.

SCO, Inc.

SCO produces Kerberos and DCE products. Their product, SCO DCE Security Server, can be used as a DCE cell security server and as a stand-alone Kerberos server. For more information, contact your local SCO channel partner or visit the SCO web site:

Evaluating Other Vendors

Other vendors provide support for DCE and Kerberos in their products. To use their products with the Reflection Kerberos client, ask for support of IETF RFC 1510 and 2942 compliant Kerberos 5 protocols, a credentials server (Key Distribution Center), and the availability of a kerberized Telnet and/or FTP server.

Related:

Configure an IPsec environment using the Kerberos authentication mechanism

Kerberos is an authentication mechanism used to authenticate a set of users by having
different security realms and by exchanging ticket over a secured or non-secured environment.
Internet Protocol Security (IPsec) is a security protocol used to establish a secured channel
over interacting systems. The IPsec security protocol allows the use of Kerberos for user
authentication and to have a secured communication channel established between two client
systems. This article explains how we can use IPsec as a security protocol to communicate
between two client systems and how we can configure IPsec with Kerberos authentication between
these systems.

Related:

Event ID 4 — Kerberos Client Configuration

Event ID 4 — Kerberos Client Configuration

Updated: November 30, 2007

Applies To: Windows Server 2008

If the client computers are joined to an Active Directory domain, the Kerberos client is configured to request ticket-granting tickets (TGTs) from the Kerberos Key Distribution Center (KDC) automatically. On successful receipt of the ticket, the Kerberos client caches the ticket on the local computer.

Event Details

Product: Windows Operating System
ID: 4
Source: Microsoft-Windows-Security-Kerberos
Version: 6.0
Symbolic Name: KERBEVT_KRB_AP_ERR_MODIFIED
Message: The kerberos client received a KRB_AP_ERR_MODIFIED error from the server %1. The target name used was %3. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named server accounts in the target realm (%2), and the client realm (%4). Please contact your system administrator.

Resolve
Delete an unused computer account by using Active Directory Users and Computers

A Kerberos ticket is encrypted by using the client computer account’s password for the resulting encryption used on the ticket. If the computer account’s password changes during the authentication process, the ticket cannot be decrypted. This can happen if a computer account was moved to a different forest and the original computer account object was not deleted. To resolve this issue, you should use Active Directory Users and Computers to delete the original computer account that is no longer used.

Note: The computer account is identified in the event log message.

To perform this procedure, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.

To delete a computer account by using Active Directory Users and Computers:

  1. Log on to a domain controller or another computer that has the Remote Server Adminstration Tools installed.
  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  3. Locate the computer account in Active Directory Domain Services (AD DS).
  4. Right-click the computer account, and then click Delete.

Verify

To verify that the Kerberos client is correctly configured, you should ensure that a Kerberos ticket was received from the Key Distribution Center (KDC) and cached on the local computer. You can view cached Kerberos tickets on the local computer by using the Klist command-line tool.

Note: Klist.exe is not included with Windows Vista, Windows Server 2003, Windows XP, or Windows 2000. You must download and install the Windows Server Resource Kit before you can use Klist.exe.

To view cached Kerberos tickets by using Klist:

  1. Log on to the Kerberos client computer.
  2. Click Start, point to All Programs, click Accessories, and then click Command Prompt.
  3. Type klist tickets, and then press ENTER.
  4. Verify that a cached Kerberos ticket is available.
    • Ensure that the Client field displays the client on which you are running Klist.
    • Ensure that the Server field displays the domain in which you are connecting.
  5. Close the command prompt.

Related Management Information

Kerberos Client Configuration

Core Security

Related:

Event ID 27 — KDC Encryption Type Configuration

Event ID 27 — KDC Encryption Type Configuration

Updated: November 30, 2007

Applies To: Windows Server 2008

Kerberos allows certain encryption types that can be used to encrypt Kerberos tickets. Other encryption types can be configured for Kerberos clients that do not support the default encryption types.

Event Details

Product: Windows Operating System
ID: 27
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Version: 6.0
Symbolic Name: KDCEVENT_UNSUPPORTED_ETYPE_REQUEST_TGS
Message: While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5.

Resolve
Configure an available encryption type

Kerberos supports several encryption types that are used to encrypt the tickets. If you are using a non-Microsoft Kerberos client to request a ticket from a Windows-based Kerberos server, the Kerberos client must support the same encryption type. Use the event log message to determine the available encryption type and configure the Kerberos client accordingly.

Verify

To verify that the Kerberos client is configured with an available encryption type, you should ensure that a Kerberos ticket was received from the Key Distribution Center (KDC) and cached on the local computer. You can view cached Kerberos tickets on the local computer by using the Klist command-line tool.

Note: Klist.exe is not included with Windows Vista, Windows Server 2003, Windows XP, or Windows 2000. You must download and install the Windows Server Resource Kit before you can use Klist.exe.

To view cached Kerberos tickets by using Klist:

  1. Log on to a Kerberos client computer within your domain.
  2. Click Start, point to All Programs, click Accessories, and then click Command Prompt.
  3. Type klist tickets, and then press ENTER.
  4. Verify that a cached Kerberos ticket is available.
    • Ensure that the Client field displays the client on which you are running Klist.
    • Ensure that the Server field displays the domain in which you are connecting.
  5. Close the command prompt.

Related Management Information

KDC Encryption Type Configuration

Core Security

Related: