NTLM VS Kerberos 인증

출처: https://msdn.microsoft.com/en-us/library/aa480475.aspx

l  NTLM 단점

1) MD4기반의 약한 암호화

2) 클라이언트와 서버는 DC도움 없이 자체적으로 넌스(nonce)를 생성하는데 취약한 넌스(nonce)를 분배하면 악의적인 위장이 발생

3) 다중인증 요소가 없음 (MFA)

4) NTLM 릴레이 - MS2017-8563

           - 상호 인증이 없기 때문에 발생

           - 모든 컴퓨터에 SMB 서명을 강제로 하면 괜찮지만 모든 네트워크에 구성하기 힘듬

          

l  커버러스가 NTLM 보다 좋은점

1) 상호 인증

2) 위임 지원

 

l  exploitdb.com 취약점 개수

NTLM : 12개

Kerberos : 14개

 

l  최신 취약점 날짜

NTLM : 2017-7-11

Kerberos : 2017-7-11

NTLM 인증

NTLM은 Windows NT 및 Windows 2000 Server 작업 그룹 환경에서 사용되는 인증 프로토콜입니다. 또한 Windows NT 시스템을 인증해야하는 혼합 된 Windows 2000 Active Directory 도메인 환경에서도 사용됩니다. Windows 2000 Server가 하위 수준의 Windows NT 도메인 컨트롤러가없는 기본 모드로 변환되면 NTLM이 비활성화됩니다. 그런 다음 Kerberos v5가 엔터프라이즈의 기본 인증 프로토콜이됩니다.

NTLM 인증 메커니즘

그림 1은 NTLM 프로토콜을 보여줍니다.

그림 1. NTLM 챌린지 / 응답 메커니즘

챌린지 / 응답 메커니즘은 다음과 같습니다.

1. 사용자 요청 액세스 . 사용자가 사용자 자격 증명을 제공하여 클라이언트에 로그온하려고합니다. 로그온하기 전에 클라이언트 컴퓨터는 암호 해시를 캐시하고 암호를 삭제합니다. 클라이언트는 요청과 함께 일반 텍스트로 사용자 이름을 포함하는 요청을 서버로 보냅니다.
2. 서버가 챌린지 메시지를 보냅니다 . 서버는 challenge 또는 nonce라고하는 16 바이트의 난수를 생성하여 클라이언트에 전송합니다.
3. 클라이언트가 응답 메시지를 보냅니다 . 클라이언트는 사용자의 암호에서 생성 된 암호 해시를 사용하여 서버가 보낸 챌린지를 암호화합니다. 이 암호화 된 챌린지를 응답 형식으로 서버에 다시 보냅니다.
4. 서버가 도메인 컨트롤러에 대한 요청 및 응답을 보냅니다 . 서버는 사용자 이름, 원래의 시도 및 응답을 클라이언트 컴퓨터에서 도메인 컨트롤러로 보냅니다.
5. 도메인 컨트롤러는 사용자 인증을 위해 요청과 응답을 비교합니다 . 도메인 컨트롤러는 사용자의 암호 해시를 가져온 다음이 해시를 사용하여 원래의 챌린지를 암호화합니다. 그런 다음 도메인 컨트롤러는 암호화 된 챌린지를 클라이언트 컴퓨터의 응답과 비교합니다. 일치하는 경우 도메인 컨트롤러는 사용자가 인증되었음을 확인하는 서버를 보냅니다.
6. 서버가 클라이언트에 응답을 보냅니다 . 유효한 신임장을 가정하면, 서버는 클라이언트가 요청 된 서비스 또는 자원에 대한 액세스 권한을 부여합니다.

Kerberos 인증

Kerberos 인증은 NTLM 인증보다 다음과 같은 이점을 제공합니다.

• 상호 인증 . 클라이언트가 특정 서버의 특정 서비스와의 인증에 Kerberos v5 프로토콜을 사용하는 경우 Kerberos는 클라이언트가 네트워크의 악의적 인 코드에 의해 서비스가 가장하지 못하도록 보장합니다.
• 위임 지원 . Kerberos 인증을 사용하여 클라이언트를 인증하는 서버는 해당 클라이언트를 가장하여 클라이언트의 보안 컨텍스트를 사용하여 네트워크 리소스에 액세스 할 수 있습니다.
• 성능 . Kerberos 인증은 NTLM 인증보다 향상된 성능을 제공합니다.
• 단순화 된 신뢰 관리 . 여러 도메인이있는 네트워크에는 더 이상 복잡한 일련의 명시 적, 지점 간 신뢰 관계가 필요하지 않습니다.
• 상호 운용성 . Microsoft의 Kerberos 프로토콜 구현은 IETF (Internet Engineering Task Force)에 권장되는 표준 트랙 사양을 기반으로합니다. 따라서 Windows 2000에서 프로토콜을 구현하면 Kerberos 버전 5가 인증에 사용되는 다른 네트워크와의 상호 운용성을위한 기반이됩니다.

Kerberos 인증 메커니즘

그림 2는 Kerberos 인증 프로토콜의 간단한보기입니다.

그림 2. Kerberos 인증

클라이언트가 네트워크 서비스에 대해 인증하면 Kerberos v5 프로토콜은 다음 단계를 수행합니다.

1. 클라이언트가 KDC에서 TGT를 요청합니다 . 사용자가 사용자 자격 증명을 제공하여 클라이언트에 로그온하려고합니다. 클라이언트 컴퓨터의 Kerberos 서비스는 Kerberos 인증 서비스 요청을 KDC (키 배포 센터)로 보냅니다. 요청에는 사용자 이름, 티켓 부여 티켓 (TGT)이 요청 된 서비스 정보 및 사용자의 장기 키 또는 암호를 사용하여 암호화 된 시간 스탬프가 포함됩니다.

   참고     Windows 2000 Server 또는 Windows Server 2003 운영 체제에서 도메인 컨트롤러는 KDC 역할을하며 Active Directory는 보안 계정 데이터베이스를 호스트합니다.

2. 인증 서비스는 암호화 된 TGT 및 세션 키를 보냅니다 . KDC는 Active Directory에서 사용자의 장기 키 또는 암호를 가져온 다음 요청과 함께 전달 된 시간 스탬프를 암호 해독합니다. 타임 스탬프가 유효하면 사용자는 정품입니다. KDC 인증 서비스는 로그온 세션 키를 만들고 사용자의 장기 키를 사용하여 복사본을 암호화합니다. 그런 다음 인증 서비스는 사용자 정보와 로그온 세션 키가 포함 된 TGT를 만듭니다. 마지막으로 인증 서비스는 자체 키를 사용하여 TGT를 암호화하고 암호화 된 세션 키와 암호화 된 TGT를 클라이언트에 전달합니다.
3. 클라이언트는 TGT에서 서버 액세스를 요청합니다 . 클라이언트는 장기 세션 키 또는 암호를 사용하여 로그온 세션 키의 암호를 해독하고 로컬로 캐시합니다. 또한 클라이언트는 암호화 된 TGT를 캐시에 저장합니다. 네트워크 서비스에 액세스 할 때 클라이언트는 사용자의 이름, 사용자의 로그온 세션 키를 사용하여 암호화 된 인증 자 메시지, TGT 및 서비스 이름과 같은 정보를 사용하여 KDC 티켓 부여 서비스 (TGS)에 요청을 보냅니다 및 서버)에 액세스 할 수 있습니다.
4. TGS는 암호화 된 세션 키와 티켓을 보냅니다 . KDC의 TGS는 자체 키를 사용하여 TGT를 암호 해독하고 로그온 세션 키를 추출합니다. 로그온 세션 키를 사용하여 인증 자 메시지 (일반적으로 타임 스탬프)를 암호 해독합니다. 인증 자 메시지가 성공적으로 해독되면 TGS는 TGT에서 사용자 정보를 추출하고 사용자 정보를 사용하여 서비스에 액세스하기위한 서비스 세션 키를 만듭니다. 사용자의 로그온 세션 키를 사용하여 서비스 세션 키의 복사본 하나를 암호화하고 서비스 세션 키와 사용자 정보가 포함 된 서비스 티켓을 만든 다음 서버의 장기 키 (암호)로 서비스 티켓을 암호화합니다. 그런 다음 TGS는 암호화 된 서비스 세션 키와 서비스 티켓을 클라이언트에 보냅니다.
5. 클라이언트가 서비스 티켓을 보냅니다 . 클라이언트가 서비스에 액세스하면 서버에 요청을 전송합니다. 요청에는 서비스 세션 키와 서비스 티켓을 사용하여 암호화 된 인증 자 메시지 (타임 스탬프)가 포함됩니다.
6. 서버는 클라이언트 유효성 검증을 위해 암호화 된 시간 소인을 보냅니다 . 서버는 서비스 티켓을 암호 해독하고 서비스 세션 키를 추출합니다. 서비스 세션 키를 사용하여 서버는 인증 자 메시지 (타임 스탬프)를 해독하고 평가합니다. 인증자가 테스트를 통과하면 서버는 서비스 세션 키를 사용하여 인증 자 (타임 스탬프)를 암호화 한 다음 인증자를 다시 클라이언트로 전달합니다. 클라이언트는 타임 스탬프의 암호를 해독하고 원본과 동일한 경우 서비스가 정품이고 클라이언트가 연결을 계속 진행합니다.

Flavor	Baseline	Pros	Cons
NTLMv1	Meant for Win9X, NT 3.51	Libraries available in deprecated version of open source JCIFS	IE and Windows only, very crackable, susceptible to man-in-the-middle attacks, chatty on network
NTLMv2	Meant for NT 4.0 SP4	More secure than NTLMv1.	IE and Windows only, not a part of Java 6's implementation of SPNEGO Requires 3rd party libraries (e.g., jespa or VSJ) Chatty on network
Kerberos	Default authentication for Active Directory	Included in Java 6 implementation of SPNEGO More secure than NTLMv2 Open standard Cross platform (Windows, Linux, Unix) Cross browser (IE, Firefox) Less chatty than NTLM	Client machine must be joined to domain