NTLM

윈도우 네트워크에서 NT(New Technology) LAN Manager(NTLM)는 사용자에게 인증, 무결성, 기밀성을 제공하기 위한 마이크로소프트 보안 프로토콜 제품군이다. NTLM은 마이크로소프트의 이전 제품인 LAN Manager(LANMAN)에 포함된 인증 프로토콜의 후속이다. NTLM 프로토콜 제품군은 보안 지원 제공자(SSP)에 구현되어 있으며, LAN Manager 인증 프로토콜, NTLMv1, NTLMv2 및 NTLM2 세션 프로토콜을 단일 패키지로 결합한다. 이러한 프로토콜의 시스템 내 사용 여부는 그룹 정책 설정에 따라 결정되며, 윈도우 버전에 따라 기본 설정이 다르다.

NTLM 비밀번호는 최신 하드웨어를 사용하여 매우 쉽게 무차별 대입이 가능하므로 취약한 것으로 간주된다.

프로토콜

NTLM은 챌린지-응답 인증 프로토콜로, 연결 지향 환경(비연결 지향도 유사함)에서 클라이언트를 인증하기 위해 3개의 메시지를 사용하며, 무결성이 필요한 경우 4번째 메시지를 추가로 사용한다.

  1. 첫째, 클라이언트는 서버에 네트워크 경로를 설정하고 자신의 기능을 알리는 NEGOTIATE_MESSAGE를 보낸다.
  2. 다음으로, 서버는 클라이언트의 신원을 확인하는 데 사용되는 CHALLENGE_MESSAGE로 응답한다.
  3. 마지막으로, 클라이언트는 AUTHENTICATE_MESSAGE로 챌린지에 응답한다.

NTLM 프로토콜은 두 개의 해시된 비밀번호 값 중 하나 또는 둘 다를 사용하며, 이 값들은 서버(또는 도메인 컨트롤러)에 저장된다. 솔트 처리가 부족하기 때문에 이 값들은 비밀번호와 동일한 효력을 지닌다. 즉, 서버에서 해시 값을 탈취하면 실제 비밀번호를 알지 못해도 인증할 수 있다. 두 가지 값은 LM 해시(언어에 맞는 전통적인 8비트 PC 문자셋으로 변환된 비밀번호의 첫 14자에 적용된 DES 기반 함수)와 NT 해시(리틀 엔디언 UTF-16 유니코드 비밀번호의 MD4)이다. 두 해시 값 모두 16바이트(128비트)이다.

NTLM 프로토콜은 또한 NTLM 버전에 따라 두 가지 일방향함수 중 하나를 사용한다. NT LanMan과 NTLM 버전 1은 DES 기반 LanMan 일방향함수(LMOWF)를 사용하며, NTLMv2는 NT MD4 기반 일방향함수(NTOWF)를 사용한다.

NTLMv1

서버는 8바이트 난수인 챌린지를 보내 클라이언트를 인증한다. 클라이언트는 챌린지와 클라이언트와 서버 간에 공유된 비밀(위에서 설명한 두 비밀번호 해시 중 하나)을 포함하는 작업을 수행한다. 클라이언트는 24바이트 계산 결과를 반환한다. 사실 NTLMv1에서는 보통 두 해시를 모두 사용하여 계산을 수행하고 두 개의 24바이트 결과를 모두 보낸다. 서버는 클라이언트가 올바른 결과를 계산했는지 확인하고, 이를 통해 비밀의 소유 여부와 클라이언트의 인증 여부를 추론한다.

두 해시 모두 16바이트 분량을 생성한다. 0 5바이트를 덧붙여 21바이트를 만든다. 21바이트는 7바이트(56비트) 3개로 분리된다. 각 56비트 분량은 64비트 챌린지를 DES 암호화하는 키로 사용된다. 챌린지에 대한 세 번의 암호화 결과가 합쳐져 24바이트 응답을 형성한다. LM 해시와 NT 해시를 사용한 응답이 모두 반환되지만, 이는 설정 가능하다.

C = 8바이트 서버 챌린지, 난수
K1 | K2 | K3 = NTLM-해시 | 0 5바이트
응답 = DES(K1,C) | DES(K2,C) | DES(K3,C)

NTLMv2

윈도우 NT 4.0 SP4에서 도입된 NTLMv2(윈도우 2000에서 기본 지원)는 챌린지-응답 인증 프로토콜이다. 이는 NTLMv1을 암호화적으로 강화한 대체제로 의도되었으며, 많은 스푸핑 공격으로부터 프로토콜을 보호하고 서버가 클라이언트를 인증할 수 있는 기능을 추가하여 NTLM 보안을 향상시킨다.

NTLMv2는 8바이트 서버 챌린지에 대해 두 개의 응답을 보낸다. 각 응답은 서버 챌린지의 16바이트 HMAC-MD5 해시, 전체/부분적으로 무작위 생성된 클라이언트 챌린지, 그리고 사용자의 비밀번호와 기타 식별 정보의 HMAC-MD5 해시를 포함한다. 두 응답은 클라이언트 챌린지의 형식에서 차이가 있다. 짧은 응답은 이 챌린지에 대해 8바이트 난수 값을 사용한다. 응답을 확인하려면 서버는 응답의 일부로 클라이언트 챌린지를 받아야 한다. 이 짧은 응답의 경우, 16바이트 응답에 8바이트 클라이언트 챌린지가 덧붙여져 이전 NTLMv1 프로토콜의 24바이트 응답 형식과 일치하는 24바이트 패키지가 된다. 비공식 문서(예: DCE/RPC Over SMB, Leighton)에서 이 응답은 LMv2로 지칭된다.

NTLMv2가 보내는 두 번째 응답은 가변 길이 클라이언트 챌린지를 사용하며, 여기에는 (1) NT Time 형식의 현재 시간, (2) 8바이트 난수 값(아래 상자의 CC2), (3) 도메인 이름, (4) 표준 형식 데이터가 포함된다. 응답에는 이 클라이언트 챌린지의 복사본이 포함되어야 하므로 길이가 가변적이다. 비공식 문서에서 이 응답은 NTv2로 지칭된다.

LMv2와 NTv2 모두 사용자의 비밀번호에 대한 NT 해시와 기타 식별 정보를 사용하여 클라이언트와 서버 챌린지를 해싱한다. 정확한 공식은 SAM 또는 AD에 저장된 NT 해시로 시작하여 HMAC-MD5를 사용하여 사용자 이름과 도메인 이름을 해시하는 것이다. 아래 상자에서 X는 서식 필드의 고정 내용을 나타낸다.

SC = 8바이트 서버 챌린지, 난수
CC = 8바이트 클라이언트 챌린지, 난수
CC* = (X, 시간, CC2, 도메인 이름)
v2-해시 = HMAC-MD5(NT-해시, 사용자 이름, 도메인 이름)
LMv2 = HMAC-MD5(v2-해시, SC, CC)
NTv2 = HMAC-MD5(v2-해시, SC, CC*)
응답 = LMv2 | CC | NTv2 | CC*

NTLM2 세션

NTLM2 세션 프로토콜은 MS-CHAPv2와 유사하다. 이는 NTLMv1의 인증과 NTLMv2의 세션 보안이 결합된 형태이다.

간단히 말해, NTLMv1 알고리즘이 적용되지만, 8바이트 클라이언트 챌린지가 8바이트 서버 챌린지에 덧붙여진 후 MD5 해싱된다는 점이 다르다. 해시 결과의 하위 8바이트가 NTLMv1 프로토콜에서 사용되는 챌린지이다. 클라이언트 챌린지는 응답 메시지의 24바이트 슬롯 중 하나에 반환되고, 계산된 24바이트 응답은 다른 슬롯에 반환된다.

이는 기존 도메인 컨트롤러 인프라를 사용할 수 있는 능력을 유지하면서도 악의적인 서버에 의한 사전 공격을 방지하는 NTLMv1의 강화된 형태이다. 고정된 X에 대해 서버는 Y=DES_K(X)를 만족하는 값 K가 위치 Y에 있도록 테이블을 계산한다. 클라이언트가 챌린지 선택에 참여하지 않으면 서버는 X를 보내고 테이블에서 응답 Y를 찾아 K를 얻을 수 있다. 이러한 공격은 레인보 테이블을 사용하여 현실화할 수 있다.

그러나 기존 NTLMv1 인프라에서는 챌린지/응답 쌍이 서버에 의해 검증되지 않고 확인을 위해 도메인 컨트롤러로 전송된다. NTLM2 세션을 사용하면 서버가 챌린지 대신 서버 챌린지와 클라이언트 챌린지의 해시를 대체하더라도 이 인프라가 계속 작동한다.

NTLMv1
  클라이언트<-서버:  SC
  클라이언트->서버:  H(P,SC)
  서버->도메인 컨트롤러: H(P,SC), SC
  서버<-도메인 컨트롤러: 예 또는 아니오

NTLM2 세션
  클라이언트<-서버:  SC
  클라이언트->서버:  H(P,H'(SC,CC)), CC
  서버->도메인 컨트롤러: H(P,H'(SC,CC)), H'(SC,CC)
  서버<-도메인 컨트롤러: 예 또는 아니오

NTLM의 가용성 및 사용

2010년부터 마이크로소프트는 애플리케이션에서 NTLM을 권장하지 않는다.

구현자는 NTLM이 AES나 SHA-256과 같은 최근의 암호화 방법을 지원하지 않는다는 점을 인지해야 한다. NTLM은 무결성을 위해 순환 중복 검사(CRC)나 MD5를 사용하며, 암호화를 위해 RC4를 사용한다.

비밀번호로부터 키를 도출하는 방식은 RFC1320 및 FIPS46-2에 명시된 대로이다. 따라서 일반적으로 애플리케이션은 NTLM을 사용하지 않는 것이 좋다.

이러한 권장 사항에도 불구하고 NTLM은 여전히 시스템에 널리 배포되어 있다. 주된 이유는 구형 시스템과의 호환성을 유지하기 위해서이다. 그러나 일부 상황에서는 피할 수 있다.

마이크로소프트는 상호 운용성(특히 RC4-HMAC 암호화 유형)을 개선하기 위해 커버로스 프로토콜 구현에 NTLM 해시를 추가했다. 한 독립 연구자에 따르면, 이러한 설계 결정으로 인해 NTLM 해시를 알 경우 도메인 컨트롤러를 속여 공격자에게 커버로스 티켓을 발급하게 만들 수 있다. 마이크로소프트는 윈도우 2000 및 이후의 액티브 디렉터리 도메인에 대해 커버로스를 선호되는 인증 프로토콜로 채택했다. 커버로스는 일반적으로 서버가 윈도우 도메인에 속해 있을 때 사용된다. 마이크로소프트는 개발자가 커버로스나 NTLM 보안 지원 제공자(SSP)를 직접 사용하지 말 것을 권장한다.

애플리케이션이 NTLM 보안 패키지에 직접 접근해서는 안 되며, 대신 Negotiate 보안 패키지를 사용해야 한다. Negotiate를 사용하면 인증 과정에 참여하는 시스템이 지원하는 경우 더 발전된 보안 프로토콜을 활용할 수 있다. 현재 Negotiate 보안 패키지는 커버로스와 NTLM 사이에서 선택한다. Negotiate는 인증 과정에 참여하는 시스템 중 하나에서 커버로스를 사용할 수 없는 경우가 아니라면 커버로스를 선택한다.

NTLM 보안 지원 제공자 사용

NTLM SSP는 다음과 같은 상황에서 사용된다.

프로토콜 버전 사용

애플리케이션 개발자나 Negotiate SSP에 의해 인증에 NTLM SSP를 사용하기로 결정된 후, 그룹 정책은 NTLM SSP가 구현하는 각 프로토콜의 사용 능력을 지시한다. 다섯 가지 인증 수준이 있다.

도메인 컨트롤러(DC)라는 용어를 사용하면 혼란스러울 수 있다. 서버 역할을 수행하고 사용자를 인증하는 모든 컴퓨터는 이 맥락에서 DC의 역할을 수행한다. 예를 들어 네트워크 로그온 중 해당 계정이 사용될 때 관리자(Administrator)와 같은 로컬 계정을 사용하는 윈도우 컴퓨터가 이에 해당한다.

윈도우 NT 4.0 서비스 팩 4 이전에는 SSP가 NTLMv1을 협상하고 상대 기기가 지원하지 않으면 LM으로 폴백했다.

윈도우 NT 4.0 서비스 팩 4부터는 클라이언트와 서버 모두 지원하는 경우 SSP가 NTLM2 세션을 협상한다. 윈도우 XP까지는 미국이 당시 암호화 기술 수출에 엄격한 제한을 두었기 때문에 비미국 컴퓨터에서 40비트 또는 56비트 암호화를 사용했다. 윈도우 XP SP3부터 업데이트를 설치하여 128비트 암호화를 추가할 수 있었고, 윈도우 7에서는 128비트 암호화가 기본값이 되었다.

윈도우 비스타 이상에서는 인바운드 인증에 대해 LM이 비활성화되었다. 윈도우 서버 2003을 포함한 이전의 윈도우 NT 기반 운영 체제는 LAN Manager(LM) 해시와 윈도우 NT 해시, 두 개의 비밀번호 해시를 저장한다. 윈도우 비스타부터는 둘 다 저장할 수 있는 기능은 있지만, 하나는 기본적으로 꺼져 있다. 이는 윈도우 비스타를 실행하는 컴퓨터가 서버 역할을 할 경우 LM 인증이 더 이상 작동하지 않음을 의미한다. 윈도우 NT 4.0 서비스 팩 4 등 이전 버전의 윈도우는 이러한 방식으로 구성될 수 있었지만 기본값은 아니었다.

취약점 및 위험

NTLM은 마이크로소프트 보안 업데이트 MS08-068에서 다루어진 반사 공격의 변형인 패스 더 해시 공격에 여전히 취약하다. 예를 들어 메타스플로이트는 많은 경우 한 컴퓨터에서 자격 증명을 획득하여 다른 컴퓨터를 제어하는 데 사용될 수 있다. Squirtle 툴킷은 웹 사이트 사이트 간 스크립팅 공격을 활용하여 NTLM을 통해 주변 자산을 공격하는 데 사용될 수 있다.

2010년 2월, Amplia Security는 NTLM 인증 메커니즘의 윈도우 구현에서 여러 결함을 발견했으며, 이는 프로토콜 보안을 깨뜨려 공격자가 파일에 대한 읽기/쓰기 권한을 얻고 원격 코드를 실행할 수 있게 했다. 제시된 공격 중 하나는 프로토콜에 의해 생성된 유사난수와 챌린지/응답을 예측하는 기능을 포함했다. 이러한 결함은 17년 동안 모든 버전의 윈도우에 존재했다. 이러한 문제를 설명하는 보안 권고문에는 완전한 개념 증명 익스플로잇이 포함되어 있었다. 이 모든 결함은 MS10-012에 의해 수정되었다.

2012년, 가능한 모든 8자 NTLM 비밀번호 해시 순열을 6시간 이내에 크래킹할 수 있음이 입증되었다.

2019년, 더 현대적인 하드웨어를 사용하여 이 시간은 약 2.5시간으로 단축되었다. 또한 8자 및 9자 NTLM 비밀번호에 대한 레인보 테이블을 사용할 수 있다. 더 짧은 비밀번호는 무차별 대입 방식으로 복구할 수 있다.

2019년, EvilMog는 NTLMv1 챌린지 응답을 hashcat 호환 크래킹 형식으로 포맷하는 ntlmv1-multitool이라는 도구를 발표했다. hashcat과 충분한 GPU 성능을 사용하면 hashcat 포럼에서 atom이 입증한 것처럼 hashcat 모드 14000으로 DES 키를 크래킹하여 알려진 평문 공격을 통해 NTLM 해시를 도출할 수 있다.

패스 더 해시 공격 및 비밀번호 크래킹에 사용되는 비밀번호와 동일한 효력의 해시는 먼저 "탈취"(해시에 접근할 수 있는 충분한 권한을 가진 시스템을 손상시키는 등의 방식)되어야 함을 유의하라. 또한 이러한 해시는 기존 NTLM 인증 중에 네트워크를 통해 전송되는 NTLMSSP_AUTH "해시"와는 다르다.

리눅스와의 호환성

리눅스를 위한 NTLM 구현에는 Cntlm과 winbind(삼바의 일부)이 있으며, 이를 통해 리눅스 애플리케이션이 NTLM 프록시를 사용할 수 있다.

FreeBSD 또한 안전하지 않은 NT-Hash 형식으로 Crypt (C)를 통한 비밀번호 저장을 지원한다.

같이 보기

각주

  1. 1 2 “Introduction”, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  2. ↑ “Session Security Details”, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  3. 1 2 Takahashi, T (2009년 12월 17일), “Reflecting on NTLM Reflection”, 《FrequencyX Blog》 (IBM Internet System Security (ISS)), 2009년 12월 31일에 원본 문서에서 보존된 문서, 2010년 8월 14일에 확인함
  4. 1 2 Claburn, Thomas (2019년 2월 14일). “Use an 8-char Windows NTLM password? Don't. Every single one can be cracked in under 2.5hrs” (영어). 《www.theregister.co.uk》. 2020년 11월 26일에 확인함.
  5. ↑ “Microsoft NTLM”, 《MSDN》 (Microsoft), 2010년 8월 15일에 확인함
  6. ↑ “Message Syntax | section 2.2”, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  7. ↑ “Connection-Oriented” 3.1.5.1판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  8. ↑ “Connectionless” 3.1.5.2판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  9. ↑ “NEGOTIATE_MESSAGE” 2.2.1.1판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  10. ↑ “CHALLENGE_MESSAGE” 2.2.1.2판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  11. ↑ “AUTHENTICATE_MESSAGE” 2.2.1.3판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  12. 1 2 “NTLM v1 Authentication” 3.3.1판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  13. ↑ “NTLM v2 Authentication” 3.3.1판, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 15일에 확인함
  14. ↑ What's New in Windows NT 4.0 Service Pack 4?
  15. ↑ 《How to enable NTLM 2 authentication》, Support, Microsoft, 2007년 1월 25일, 2010년 8월 14일에 확인함
  16. 1 2 “Security Configuration”, 《Microsoft Windows 2000 Security Hardening Guide》, TechNet (Microsoft), 2009년 3월 24일, 2010년 8월 14일에 확인함
  17. ↑ Glass, Eric, 〈NTLM〉, 《Davenport》, Source forge
  18. ↑ Varughese, Sam (February 2006). “Rainbow Cracking and Password Security”. Palisade. 2010년 6월 1일에 원본 문서에서 보존된 문서. 2010년 8월 14일에 확인함.
  19. ↑ “Security Considerations for Implementers”, 《NT LAN Manager (NTLM) Authentication Protocol Specification》 (Microsoft), 2010년 8월 16일에 확인함
  20. ↑ “Active Directory Vulnerability Disclosure: Weak encryption enables attacker to change a victim's password without being logged - Aorato”. 2014년 10월 6일에 원본 문서에서 보존된 문서. 2014년 10월 5일에 확인함.
  21. ↑ “Microsoft NTLM”. 《TechNet Library》. Microsoft. 2015년 11월 2일에 확인함.
  22. ↑ “Public Key Cryptography based User to User Authentication Overview”. 《TechNet Library》. Microsoft. 2015년 11월 2일에 확인함.
  23. ↑ “LAN Manager 인증 수준”. 《MSDN Library》. Microsoft. 2015년 11월 2일에 확인함.
  24. ↑ “Windows Authentication”. 《TechNet Library》. Microsoft. 2011년 6월 29일. 2015년 11월 2일에 확인함.
  25. ↑ Jesper Johansson. “The Most Misunderstood Windows Security Setting of All Time”. 《TechNet Magazine》. Microsoft. 2015년 11월 2일에 확인함.
  26. ↑ HD Moore. “MS08-068: Metasploit and SMB Relay”.
  27. ↑ Kurt Grutzmacher (2008년 8월 8일). 《Nail the Coffin Shut, NTLM is Dead》. Defcon 16.
  28. ↑ Hernan Ochoa and Agustin Azubel (2010년 7월 28일). 《Understanding the Windows SMB NTLM Weak Nonce vulnerability》 (PDF). Blackhat USA 2010.
  29. ↑ Hernan Ochoa and Agustin Azubel. “Windows SMB NTLM Weak Nonce vulnerability Security Advisory”.
  30. ↑ Goodin, Dan (2012년 12월 10일). “25-GPU cluster cracks every standard Windows password in <6 hours”. 아르스 테크니카. 2020년 11월 23일에 확인함.
  31. ↑ hashcat (2019년 2월 13일). “hand-tuned hashcat 6.0.0 beta and 2080Ti (stock clocks) breaks NTLM cracking speed mark of 100GH/s on a single compute device” (영어). 《@hashcat》. 2019년 2월 26일에 확인함.
  32. ↑ A Case for Modern Rainbow Table Usage
  33. ↑ “Ethical hacker Dustin Heywood, a.k.a. EvilMog: 'My mission is to make companies safer'” (캐나다 영어). 《The Globe and Mail》. 2019년 12월 9일. 2023년 10월 12일에 확인함.
  34. ↑ “Dustin Heywood: The "Evil" Hacker Using his Neurodivergent Mind for Good” (미국 영어). 《IBM Newsroom》. 2023년 10월 12일에 확인함.
  35. ↑ Heywood, Dustin (2023년 10월 11일), 《10 Nov, 2020 Updates》, 2023년 10월 12일에 확인함
  36. ↑ “How to make use of the DES KPA mode”. 《hashcat.net》. 2023년 10월 12일에 확인함.
  37. ↑ “Cntlm: Fast NTLM Authentication Proxy in C”.
  38. ↑ “NTLM authentication - MoodleDocs”.
  39. ↑ “NT MD4 password hash as new password encryption method for FreeBSD”. 《Mail-archive.com》. 2018년 12월 2일에 확인함.

외부 링크