NTLM vs Kerberos
Last updated
Last updated
NTLM (New Technology LAN Manager) là một giao thức xác thực. Đây là giao thức mặc định được sử dụng trong các phiên bản Windows cũ, nhưng vẫn được sử dụng cho đến ngày nay. Nếu vì lý do nào đó Kerberos không thành công, NTLM sẽ được sử dụng thay thê.
NTLM hoạt động theo cơ chế thách thức/phản hồi.
Băm LM dễ bị tấn công và mã băm LM ( AAD3B435B51404EEAAD3B435B51404EE) nghĩa là LM không được sử dụng.
Kerberos là phương pháp xác thực mặc định, trong khi NTLM chỉ được sử dụng trong một số điều kiện nhất định: vắng mặt Active Directory, không tồn tại tên miền, Kerberos hoạt động không bình thường do cấu hình không đúng hoặc khi kết nối được thử sử dụng địa chỉ IP thay vì tên máy chủ hợp lệ.
Các gói xác thực NTLM có thể được nhận dạng bằng tiêu đề "NTLMSSP".
Các giao thức LM, NTLMv1 và NTLMv2 được hỗ trợ bởi tệp hệ thống msv1\_0.dll.
Kiểm tra và định cấu hình giao thức sử dụng:
secpol.msc -> Local policies -> Security Options -> Network Security: LAN Manager authentication level. Có 6 cấp độ (from 0 to 5).
Đặt lever = 5:
Possible values:
Một user truy cập vào client computer và cung cấp domain name, user name, và password. The client tính giá trị băm của mật khẩu và loại bỏ mật khẩu thực tế. The client gửi username đến server (in plaintext).
Server tạo một 16-byte random number, gọi là challenge, và gửi nó trỏ lại client.
The client mã hóa thử thách này bằng giá trị băm của mật khẩu người dùng và trả kết quả cho the server. Đây gọi là response.
Server gửi 3 thông tin sau đến domain controller: - User Name - Challenge đã gửi đến client - Response vừa nhận được từ client
DC sử dụng username để lấy giá trị băm mật khẩu của người dùng. Nó so sánh encrypted challenge với response của (ở bước 4). Nếu chúng giống hệt nhau, xác thực thành công và DC sẽ thông báo cho server.
Server sẽ gửi thông tin appropriated response trở lại client.
Local NTLM authentication Scheme: Xác thực giống như đã đề cập trên nhưng máy chủ biết hàm băm của người dùng cố gắng xác thực bên trong tệp SAM . Vì vậy, thay vì hỏi DC, máy chủ sẽ tự kiểm tra xem người dùng có thể xác thực hay không.
Kerberos là một giao thức thực. Đây là giao thức xác thực mặc định trên các phiên bản Windows kể từ W2k, thay thế cho NTML.
Client or user muốn truy cập dịch vụ
AP (Application Server) cung cấp dịch vụ
KDC (Key Distribution Center) phát hành ticket, được cài đặt trên DC (Domain Controller). Nó được hỗ trợ bởi AS ( Authentication Service), dịch vụ này phát hành TGT.
User key được lấy từ hàm băm NTLM của người dùng.
Service key được lấy từ mã băm NTLM của chủ sở hữu dịch vụ, có thể là tài khoản người dùng hoặc máy tính.
Session key được thương lượng giữa người dùng và KDC.
Service session key được sử dụng giữa người dùng và dịch vụ.
TGS ( Ticket Granting Service) là ticket mà người dùng có thể sử dụng để xác thực với một dịch vụ. Ticket được mã hóa bằng khóa dịch vụ.
TGT (Ticket Granting Ticket) là vé được trình lên KDC để yêu cầu TGS. Vé này được mã hóa bằng khóa KDC .
PAC (Privilege Attribute Certificate) là một cấu trúc được bao gồm trong hầu hết mọi vé. Cấu trúc này chứa các đặc quyền của người dùng và được ký bằng khóa KDC.
Sevices có thể xác minh PAC bằng cách giao tiếp với KDC, mặc dù điều này không xảy ra thường xuyên. Tuy nhiên, xác minh PAC chỉ bao gồm việc kiểm tra chữ ký của nó, mà không kiểm tra xem các đặc quyền bên trong PAC có đúng không.
Hơn nữa, client có thể tránh việc đưa PAC vào trong phiếu bằng cách chỉ định nó trong trường KERB-PA-PAC-REQUEST của ticket request.
Messages
KRB_AS_REQ : Được sử dụng để yêu cầu TGT tới KDC.
KRB_AS_REP : Được sử dụng để chuyển TGT bởi KDC.
KRB_TGS_REQ : Được sử dụng để yêu cầu TGS tới KDC, sử dụng TGT.
KRB_TGS_REP : Được sử dụng để phân phối TGS bởi KDC.
KRB_AP_REQ : Được sử dụng để xác thực người dùng với một dịch vụ bằng cách sử dụng TGS.
KRB_AP_REP : (Tùy chọn) Được dịch vụ sử dụng để xác định chính nó so với người dùng.
KRB_ERROR : Thông báo để thông báo tình trạng lỗi.
Ngoài ra, ngay cả khi không phải là một phần của Kerberos mà là NRPC (Netlogon Remote Protocol), AP vẫn có thể tùy chọn sử dụng tin nhắn KERB_VERIFY_PAC_REQUEST để gửi đến KDC chữ ký của PAC và xác minh xem chữ ký đó có chính xác không.
Đầu tiên, người dùng phải nhận được TGT từ KDC. Để đạt được điều này, phải gửi KRB_AS_REQ:
A encrypted timestamp with client key, to authenticate user and prevent replay attacks
Username of authenticated user
The service SPN associated with krbtgt account
A Nonce generated by the user
Sau khi nhận được yêu cầu, KDC xác minh danh tính người dùng bằng cách giải mã timestamp. Nếu thông điệp đúng, thì nó phải phản hồi bằng KRB_AS_REP:
Username
TGT, which includes:
Username
Session key
Expiration date of TGT
PAC with user privileges, signed by KDC
Some encrypted data with user key, which includes:
Session key
Expiration date of TGT
User nonce, to prevent replay attacks
Sau khi hoàn tất, người dùng đã có TGT, có thể được sử dụng để yêu cầu TGS và sau đó truy cập vào các dịch vụ.
Để yêu cầu TGS, thông điệp KRB_TGS_REQ phải được gửi tới KDC:
Encrypted data with session key:
Username
Timestamp
TGT
SPN of requested service
Nonce generated by user
Sau khi nhận được thông điệp KRB_TGS_REQ , KDC trả về TGS bên trong KRB_TGS_REP :
Username
TGS, which contains:
Service session key
Username
Expiration date of TGS
PAC with user privileges, signed by KDC
Encrypted data with session key:
Service session key
Expiration date of TGS
User nonce, to prevent replay attacks
Cuối cùng, nếu mọi thứ diễn ra tốt đẹp, người dùng đã có TGS hợp lệ để tương tác với dịch vụ. Để sử dụng nó, người dùng phải gửi đến AP một thông điệp KRB_AP_REQ :
TGS
Encrypted data with service session key:
Username
Timestamp, to avoid replay attacks
Sau đó, nếu quyền của người dùng là đúng, thì có thể truy cập vào dịch vụ. Nếu đúng như vậy, điều này thường không xảy ra, AP sẽ xác minh PAC với KDC. Và nếu cần xác thực lẫn nhau, nó sẽ phản hồi người dùng bằng thông báo KRB_AP_REP
Cuộc tấn công Pass The Hash (PTH) phổ biến bao gồm việc sử dụng mã băm của người dùng để mạo danh người dùng cụ thể
Nếu kẻ tấn công lấy được mã băm của bất kỳ người dùng nào, hắn có thể mạo danh người đó để truy cập vào KDC và sau đó truy cập vào một số dịch vụ.
Có thể lấy được ticket bằng cách thực hiện tấn công Man-In-The-Middle, do Kerberos được gửi qua TCP hoặc UDP. Tuy nhiên, kỹ thuật này không cho phép truy cập vào khóa phiên.
Tốt hơn là nên lấy TGT, vì TGS chỉ có thể sử dụng cho một dịch vụ. Ngoài ra, cần lưu ý rằng thời hạn sử dụng của vé là 10 giờ, sau đó chúng sẽ không sử dụng được nữa
Hơn nữa, ngay cả khi người dùng thay đổi mật khẩu, vé vẫn sẽ có hiệu lực. TGT chỉ có thể bị vô hiệu nếu hết hạn hoặc tài khoản krbtgt thay đổi mật khẩu.
Silver Ticket cũng tương tự, tuy nhiên, ticket được xây dựng lần này là TGS. Trong trường hợp này, cần có khóa dịch vụ, được lấy từ tài khoản chủ sở hữu dịch vụ. Tuy nhiên, không thể ký đúng PAC nếu không có khóa krbtgt. Do đó, nếu dịch vụ xác minh PAC, thì kỹ thuật này sẽ không hoạt động.
Như đã thấy ở trên, TGS được mã hóa bằng khóa dịch vụ, được lấy từ hàm băm NTLM của tài khoản chủ sở hữu dịch vụ. Thông thường, chủ sở hữu của các dịch vụ là máy tính mà các dịch vụ đang được thực thi. Tuy nhiên, mật khẩu máy tính rất phức tạp, do đó, không hữu ích khi cố gắng bẻ khóa chúng. Điều này cũng xảy ra trong trường hợp tài khoản krbtgt, do đó, TGT cũng không thể bẻ khóa được.
Tuy nhiên, trong một số trường hợp, chủ sở hữu dịch vụ là một tài khoản người dùng bình thường. Trong những trường hợp này, việc bẻ khóa mật khẩu của họ khả thi hơn. Hơn nữa, loại tài khoản này thường có các đặc quyền rất hấp dẫn. Ngoài ra, để có được TGS cho bất kỳ dịch vụ nào, chỉ cần một tài khoản miền bình thường, do Kerberos không thực hiện kiểm tra ủy quyền.
Sau đó, KDC sẽ phản hồi bằng tin nhắn KRB_AS_REP , trong đó có chứa một số thông tin được mã hóa bằng khóa người dùng. Do đó, tin nhắn này có thể được sử dụng để bẻ khóa mật khẩu người dùng.
How can we identify when we are using NTLM or Kerberos?
Có thể xác nhận xác thực đang được sủ dụng bằng cách thu thập dấu vết fiddler.
Trong fiddler trace, có thể thấy các yêu cầu được thực hiện trong Inspectors/Headers:
Kerberos:
NTLM:
Nếu yêu cầu bắt đầu bằng Kerberos và fails, NTLM sẽ đươc sử dụng thay thế. Chúng ta cũng có thể thấy phản hồi trong Headers:
Yêu cầu Kerberos:
Cả máy khách và máy chủ đều cần chạy W2k hoặc các phiên bản mới hơn và nằm trên cùng một miền hoặc miền đáng tin cậy.
Cần phải có SPN(service principal name) trong AD cho tài khoản miền đang sử dụng để chạy dịch vụ mà máy khách đang xác thực.
NTLMv1 hashes có thể bị bẻ khóa trong vài giây với máy tính ngày nay vì chúng luôn có cùng độ dài và không được thêm muối. NTLMv2 là một cải tiến, vì độ dài của nó thay đổi và hàm băm được thêm muối, tuy nhiên nó vẫn không an toàn lắm. Mặc dù hàm băm được thêm muối trước khi gửi, nhưng nó được lưu dưới dạng chưa được thêm muối trong bộ nhớ của máy.
Hơn nữa, khi chúng ta nói về NTLM, chúng ta đang nói về cơ chế thách thức/phản hồi, cơ chế này khiến mật khẩu có nguy cơ bị bẻ khóa ngoại tuyến khi phản hồi thách thức.
Sử dụng NTLM đối mặt với các nguy cơ NTLM Replay Attack, NTLM pass-the-hash attack...
Kerberos cung cấp một số lợi thế so với NTLM:
An toàn hơn: Không có mật khẩu được lưu trữ cục bộ hoặc gửi qua mạng.
Hiệu suất tốt nhất
Hỗ trợ phân quyền: Máy chủ có thể đóng vai trò là máy khách và sử dụng ngữ cảnh bảo mật của máy khách để truy cập tài nguyên.
Quản lý sự tin cậy đơn giản hơn: Tránh nhu cầu phải có mối quan hệ tin cậy ngang hàng trên nhiều môi trường miền.
Hỗ trợ MFA (Multi Factor Authentication)
Tuy nhiên NTLM vẫn được phát triển qua từng phiên bản HĐH và được xem như một giao thức ‘backup’. Nếu Kerberos không xác thực được người dùng, hệ thống sẽ cố gắng sử dụng NTLM để thay thế.
KDC or krbtgt key được lấy từ mã băm NTLM của tài khoản
Note: timestamp chỉ cần thiết nếu người dùng yêu cầu preauthentication, đây là điều phổ biến, ngoại trừ trường hợp cờ được đặt trong tài khoản người dùng.
Có thể trích xuất mã băm của người dùng từ các tệp SAM trong máy trạm hoặc tệp NTDS.DIT của DC, cũng như từ bộ nhớ quy trình lsass (bằng cách sử dụng ), nơi cũng có thể tìm thấy mật khẩu dạng văn bản thuần túy.
là về việc lấy một vé người dùng và sử dụng nó để mạo danh người dùng đó. Tuy nhiên, ngoài vé, cần phải lấy cả khóa phiên để sử dụng vé.
Một giải pháp thay thế là lấy ticket từ bộ nhớ tiến trình lsass, nơi cũng lưu trữ khóa phiên. Quy trình này có thể được thực hiện với .
Mục tiêu của là xây dựng một TGT. Về vấn đề này, cần phải có được mã băm NTLM của tài khoản krbtgt. Sau khi có được, có thể xây dựng một TGT với người dùng và đặc quyền tùy chỉnh.
g là một kỹ thuật tận dụng TGS để crack the user accounts passwords offline.
tương tự như Kerberoasting, cũng theo đuổi việc bẻ khóa mật khẩu của tài khoản.
Nếu thuộc tính được đặt trong tài khoản người dùng, thì có thể xây dựng thông báo KRB_AS_REQ mà không cần chỉ định mật khẩu.
