Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)

Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)Nghiên Cứu Lỗ Hổng Tiềm Tàng Trong Hệ Thống Xác Thực Remote Desktop (LV thạc sĩ)

LỜI CAM ĐOAN

Tôi cam đoan đây là công trình nghiên cứu của riêng tôi

Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác

TP Hồ Chí Minh, ngày 24 tháng 5 năm 2017

Học viên thực hiện luận văn

Trần Huy Vũ

LỜI CẢM ƠN

Đầu tiên em xin chân thành cảm ơn: TS Nguyễn Hồng Sơn – Học Viện Công Nghệ Bưu Chính Viễn Thông đã tận tình giúp đỡ, định hướng, hướng dẫn em nghiên cứu và hoàn thành luận văn này

Em cũng xin gửi lời cảm ơn đến Quý Thầy Cô tại Học Viện Công Nghệ Bưu Chính Viễn Thông cơ sở TP Hồ Chí Minh đã tận tình giảng dạy và giúp em trang bị được những kiến thức quý giá trong quá trình tham gia học tập tại trường

Em chân thành biết ơn sâu sắc đến gia đình và bạn bè đã động viên và giúp đỡ

em hoàn thành khóa học này

TP Hồ Chí Minh, ngày 24 tháng 5 năm 2017

Học viên thực hiện luận văn

Trần Huy Vũ

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT iv

DANH SÁCH BẢNG v

DANH SÁCH HÌNH VẼ vi

LỜI NÓI ĐẦU 1

Chương 1 - TỔNG QUAN VỀ REMOTE DESKTOP 3

1.1 Giới thiệu về Remote Desktop Protocol 3

1.2 Các phương thức chứng thực trong RDP 4

1.3 Network Authentication Level (NLA) 5

1.4 Giao thức chứng thực NT LAN Manager (NTLM) sử dụng giữa client và Domain Controller (DC) 5

1.5 Tổng quan về Credential Security Support Provider (CredSSP) 12

1.6 Giới thiệu về Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO) 14

1.7 NTLM dùng trong SPNEGO 16

1.8 Các phiên bản của Remote Desktop cùng các lỗ hổng 16

Chương 2 - ĐỀ XUẤT PHƯƠNG PHÁP TẤN CÔNG MITM VỚI NLA 20

2.1 Lý thuyết hóa bài toán xác thực Remote Desktop 20

2.2 TLS/SSL proxy trong tấn công MITM với RDP 24

2.3 Tấn công Man-In-The-Middle 27

2.4 Cách tạo một RDP NLA/CredSSP server giả mạo để user kết nối tới 27

2.4 Lỗ hổng bị khai thác trong phương pháp tấn công được đề xuất 31

Chương 3 - THỰC NGHIỆM VÀ BIỆN PHÁP PHÒNG CHỐNG 33

3.1 Thực nghiệm phương pháp tấn công 33

3.1.1 Hệ thống thực nghiệm 33

3.1.2 Thực nghiệm và kết quả 36

3.2 Các phương pháp hạn chế 38

KẾT LUẬN 41

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 42

DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT

Viết tắt Tiếng anh

RDP Remote Desktop Protocol

NLA Network Authentication Level

CredSSP Credential Security Support Provider

FIPS Federal Information Process Standard

DoS Denial of Service

SAM Security Account Manager

TLS Transport Layer Security

SSL Secure Sockets Layer

SPNEGO Simple and Protected Generic Security Service

Application Program Interface Negotiation Mechanism

GSS-API Generic Security Service Application Program

Interface

ARP Address Resolution Protocol

CA Certificate Authorities

DNSSEC Domain Name System Security Extensions

DANH SÁCH BẢNG

1.1 Các mức bảo mật của RDP với các hệ điều hành Windows 4 3.1 Những máy tham gia vào mô hình tấn công 33

1.5 Khóa công khai và chữ ký của server trong registry key 17

1.7 Cảnh báo sai chứng thực của server 19 2.1 Mô hình lý thuyết của thuật toán mã hóa bất đối xứng 20

2.4 Cảnh báo không thể giải mã message từ server 23 2.5 Server sẽ ngay lập tức ngắt kết nối 23 2.6 Các thành phần trong cơ chế chứng thực TLS/SSL 25 2.7 Cảnh báo khi server certificate không có trong client CA 26

2.9 Cấu hình cho phép một máy Windows trở thành một RDP server 28 2.10 Kiểu tấn công MITM mới với RDP NLA 28 2.11 Quá trình chứng thực giữa Admin Machine và MITM 30

3.11 Cấu hình cho các lựa chọn khi server certificate không có trong trust CA 38 3.12 Kết nối sẽ bị ngắt khi kiểm tra server certificate không đúng 39

LỜI NÓI ĐẦU

Trong những năm gần đây, vấn đề bảo mật đang trở thành đề tài nóng, đặc biệt đối với các doanh nghiệp ứng dụng Công nghệ thông tin (CNTT) nhằm hỗ trợ các hoạt động kinh doanh thì vấn đề an toàn an ninh thông tin càng trở nên quan trọng Đối với nhiều doanh nghiệp vấn đề này còn mang tính sống còn như trong lĩnh vực Ngân hàng, thương mại điện tử Một sự cố về an ninh thông tin có thể gây thiệt hại nặng nề về tài chính và uy tín của doanh nghiệp

Việc xây dựng một hệ thống an ninh thông tin, xây dựng hệ thống lá chắn phòng thủ hiệu quả cho toàn bộ các chiến lược và hoạt động của một tổ chức khỏi các mối nguy hiểm, các cuộc tấn công từ bên ngoài cũng như từ chính bên trong của tổ chức trở thành vấn đề tối quan trọng được quan tâm hàng đầu của nhiều tổ chức Khi

đó các yếu tố liên quan mật thiết đến an ninh thông tin như con người, quy trình, dữ liệu, và công nghệ cần phải được xem xét kỹ lưỡng, thiết lập các chuẩn mực an toàn ngay từ đầu để tạo nền tảng vững chắc cho quá trình phát triển, cập nhật các công nghệ hiện đại, bắt kịp xu hướng, đem lại sự cải tiến, giảm chi phí và rút ngắn thời gian tiếp cận thị trường cho các doanh nghiệp và tổ chức

Nhưng để xây dựng được một hệ thống phòng thủ tốt, cần phải biết hệ thống

có những điểm yếu nào có thể bị khai thác, bị tấn công Từ đó mới có các biện pháp triển khai bản vá, cấu hình lại cho phù hợp Phải biết tấn công như thế nào, thì mới biết cách xây dựng phòng thủ sao cho an toàn hiệu quả

Chính vì thế, việc nghiên cứu các kỹ thuật, các công cụ tấn công mới luôn là một vấn đề nóng, được rất nhiều các tổ chức, cá nhân quan tâm

Luận văn nghiên cứu kỹ thuật tấn công nghe lén vào một công cụ được quản trị viên trong các hệ thống sử dụng rất nhiều, đó là công cụ Remote Desktop (RD) với Remote Desktop Protocol (RDP)

Do RD được các quản trị viên sử dụng rất nhiều trong các hệ thống, một phần

do đơn giản, dễ sử dụng, một phần đây là công cụ có sẵn trên các hệ điều hành Windows, dẫn đến có thể sử dụng mà không cần phải cài đặt bất cứ một phần mềm thứ 3 nào Một khi tấn công vào công cụ quản trị thành công, đồng nghĩa với việc tấn

công toàn bộ hệ thống, do các công cụ quản trị chứa các thông tin chứng thực của người quản trị [5]

Chính vì thế, luận văn sẽ đi từ việc Nghiên cứu phương thức chứng thực dùng trong phiên Remote Desktop: Network Authentication Level Từ đó tìm ra phương pháp tấn công nghe lén giao thức này, cùng với việc tạo ra một công cụ tấn công để tiến hành chạy thực nghiệm và sau đó đưa ra các biện pháp phòng thủ phù hợp

Luận văn gồm 3 chương với các nội dung cơ bản sau:

Chương 1: Trong chương này sẽ giới thiệu tổng quan về giao thức remote desktop, các phương thức chứng thực và những lỗ hổng đã có trước đây với remote desktop trong các hệ điều hành Windows

Chương 2: Chương 2 sẽ trình bày về phương pháp tấn công dùng cho RDP với NLA, cùng những điều kiện để có thể tấn công thành công Sau đó sẽ đưa ra các biện pháp phòng thủ đối với cách tấn công này

Chương 3: Chương 3 sẽ thực hiện chạy mô phỏng phương pháp tấn công đã trình bày ở chương 2

Mặc dù đã hết sức nỗ lực, song do thời gian và kinh nghiệm nghiên cứu khoa học còn hạn chế nên không thể tránh khỏi những thiếu sót Em rất mong nhận được

sự góp ý của các thầy cô và bạn bè đồng nghiệp để hiểu biết của mình ngày một hoàn thiện hơn

Chương 1 - TỔNG QUAN VỀ REMOTE DESKTOP

1.1 Giới thiệu về Remote Desktop Protocol

Remote Desktop Protocol (RDP) là giao thức được phát triển bởi Microsoft, giúp truy cập từ xa tới các máy tính qua mạng một cách dễ dàng và thuận tiện RDP bao gồm có 2 thành phần chính là RDP server và RDP client Khi RDP-Client kết nối tới server và hoàn thành việc chứng thực, client lúc này sẽ có quyền điều khiển server thông qua giao diện Desktop

RDP dựa trên phiên bản mở rộng của dòng giao thức ITU T.120 RDP là một giao thức đã kênh cho phép sử dụng nhiều kênh riêng biệt để thực hiện giao tiếp giữa các thiết bị và biểu diễn dữ liệu từ server, cùng với việc mã hóa dữ liệu của chuột và bàn phím truyền tới server RDP cung cấp tới 64.000 kênh riêng biệt để truyền tải dữ liệu và cung cấp cho truyền tải đa điểm

RDP cung cấp một số chức năng và khả năng như sau:

Mã hóa: RDP sử dụng mã RSA Security's RC4 để thực hiện việc truyền thông

an toàn trong mạng Người quản trị có thể cấu hình chọn mã hóa dữ liệu với khóa có

độ dài từ 56 đến 128

Chức năng tiết kiệm băng thông: RDP hỗ trợ một số cơ chế để thực hiện giảm lượng dữ liệu truyền tải qua mạng như nén dữ liệu và caching bitmaps Catching bitmaps giúp tăng hiệu suất trong môi trường mạng băng thông thấp

Roaming disconnect: User có thể ngắt kiết nối phiên remote desktop mà không cần phải log off User sẽ được tự động tái kết nối tới phiên đã ngắt trước đó khi họ đăng nhập vào hệ thống, có thể trên cùng hoặc khác thiết bị

Clipboard mapping: Users có thể xóa, copy và dán text và graphics giữa client

và server qua phiên remote desktop

Print redirection: Các ứng dụng chạy trong phiên remote desktop có thể dụng các máy in có trên client

Virtual channels: Bằng cách sử dụng kênh RDP ảo, các ứng dụng có sẵn có thể được cải tiến và các ứng dụng mới có thể được phát triển để có thêm chức năng

cần tới việc truyền thông giữa các thiết bị có trên client và các ứng dụng trong phiên remote desktop

Điều khiển từ xa/Remote control: Các nhân viên hỗ trợ có thể xem và điều khiển phiên remote desktop [22]

1.2 Các phương thức chứng thực trong RDP

Bao gồm RDP Security (Basic) sử dụng mã hóa RDP có sẵn với 4 mức mã hóa, SSL (TLS 1.0) và cuối cùng là Network Authentication Level với Credential Security Support Provider (CredSSP) Protocol

Mặc định, với RDP Security việc mã hóa kết nối sẽ dùng mức cao nhất mà cả client và server hỗ trợ Có tất cả 4 mức mã hóa như sau:

FIPS Compliant: Mã hóa dữ liệu truyền từ client tới server và từ server tới client cách sử dụng phương pháp mã hóa Federal Information Process Standard (FIPS) 140-1

High: Ở mức mã hóa này, dữ liệu từ client tới server và ngược lại sẽ được mã hóa với khóa có độ dài 128 bits

Client Compatible: Đây là mức mã hóa mặc định Việc mã hóa dữ liệu từ client tới server và từ server tới client sẽ sử dụng khóa có độ dài cao nhất mà cả client lẫn server đều hỗ trợ Đây là mức giúp cho giữa các clients và servers có độ tương thích cao nhất

Low: Dữ liệu truyền từ client tới server sẽ được mã hóa với khóa có độ dài 56 bits Dữ liệu truyền từ server tới client sẽ không được mã hóa [23]

Hình dưới đây mô tả các mức bảo mật của RDP qua các phiên bản Windows

Bảng 1.1: Các mức bảo mật của RDP với các hệ điều hành Windows

Windows 8/8.1

Windows

10

Windows

2012 RDP

NLA Y/Disable

1.3 Network Authentication Level (NLA)

NLA đòi hỏi client phải thực hiện chứng thực trước khi kết nối khi thiết lập phiên kết nối, quá trình này có tên gọi là “front authentication” [24] Ngay sau đó, server cũng phải chứng thực với client để tạo phiên kết nối Server sử dụng hệ điều hành Windows Server 2008/Vista hoặc các phiên bản sau này và client sử dụng hệ điều hành Windows XP SP3 hoặc lớn hơn đều hỗ trợ NLA

NLA đem lại 2 lợi ích lớn khi đòi hỏi phải chứng thực trước khi thiết lập phiên: giúp giảm tài nguyên trên server và giảm thiểu khả năng bị tấn công từ chối dịch vụ (DoS) [24]

NLA sử dụng Credential Security Support Provider (CredSSP) để trình báo user credentials cho server trước khi thiết lập phiên

1.4 Giao thức chứng thực NT LAN Manager (NTLM) sử dụng giữa client

và Domain Controller (DC)

NTLM là một giao thức bảo mật trong Windows NTLM được dùng trong giao thức của các ứng dụng để thực hiện việc chứng thực hoặc cung cấp phiên bảo mật khi các ứng dụng yêu cầu

NTLM là giao thức chứng thực theo kiểu challenge-response [19] Điều này

có nghĩa để chứng thực một user, server sẽ gửi một challenge cho client Client sẽ trả lời lại bằng những thông tin đã được mã hóa bao gồm: mật khẩu người dùng, client challenge và một số thông tin khác Việc tính toán chính xác thông tin phản hồi lại server đòi hỏi client phải có mật khẩu người dùng Server có thể kiểm tra thông tin phản hồi từ client bằng cách lấy mật khẩu người dùng có trên server database và tính toán phản hồi chính xác với challenge từ client

NTLM là một giao thức nhúng [19] Các tin nhắn NTLM sẽ được nhúng trong các gói tin của các ứng dụng cần được chứng thực Các giao thức ứng dụng sẽ quyết định việc encode các tin nhắn NTLM vào khi nào lúc nào và như thế nào NTLM còn giúp cho việc bảo mật phiên, đảm bảo tính toàn vẹn và bảo mật của gói tin bằng các

cơ chế signing và sealing

Hình dưới đây thể hiện dòng dữ liệu khi ứng dụng sử dụng NTLM Dòng dữ liệu thường bắt đầu bằng một số tin nhắn của ứng dụng, theo sau đó là tin nhắn của NTLM được nhúng vào trong giao thức của ứng dụng và truyền tải tới server

Hình 1.1: Dòng tin nhắn chứng thực NTLM thông thường [19]

Sau khi phiên NTLM được thiết lập, những tin nhắn của ứng dụng sau này sẽ được bảo vệ bằng phiên bảo mật NTLM Điều này được thực hiện bởi ứng dụng, bằng cách chỉ ra những yêu cầu như tính toàn vẹn, tính bảo mật trước khi phiên NTLM bắt đầu

Hình dưới đây thể hiện quá trình tương tác giữa NTLM client và NTLM server trong môi trường chứng thực tập trung

Hình 1.2: NTLM trong Active Directory/Pass-through authentication [20]

Bước 1: Client gửi tin nhắn NTLM NEGOTIATE_MESSAGE để yêu cầu chứng thực với server

Bước 2: Server gửi tin nhắn NTLM CHALLENGE_MESSAGE tới client Bước 3: Client sẽ phản hồi lại challenge bằng tin nhắn NTLM AUTHENTICATE_MESSAGE chứa server challenge đã signing bằng khóa tạo từ mật khẩu người dùng

Bước 4: Server sẽ chuyển tiếp tin nhắn phản hồi của client tới domain controller trong tin nhắn NETLOGON_NETWORK_INFO

Bước 5: DC sẽ kiểm tra và phản hồi lại trong tin nhắn NETLOGON_VALIDATION_SAM_INFO4 Nếu chứng thực thành công, tin nhắn trả về sẽ chứa dữ liệu chứng thực cùng với privilege attribute certificate (PAC) của user Nếu chứng thực thất bại, kết quả trả về sẽ là từ chối truy cập

Tùy vào hỗ trợ của Client và server, mà NTLM v1 hay NTLM v2 sẽ được sử dụng

Đoạn mã giả dưới đây thể hiện việc thuật toán signing và tạo khóa phiên trong NTLM v1 [19]

Khai báo các biến:

ClientChallenge – Tin nhắn có độ dài 8 bytes tạo ra bởi client

LmChallengeResponse – Tin nhắn LM response trả về cho server Được tạo ra bởi client

NegFlg, User, UserDom – Cờ thể hiện tương thích giữa client và server, tên user và tên domain

NTChallengeResponse - NT response trả về cho server, được tính toán bởi client

Passwd – Mật khẩu của user Nếu mật khẩu dài hơn 14 ký tự, LMOWF v1 sẽ không được dùng Nếu mật khẩu có độ dài nhỏ hơn 14 ký tự, các ký tự 0 sẽ được thêm vào cho đúng độ dài 14

ResponseKeyNT – Biến tạm để lưu trữ kết quả hàm NTOWF()

ResponseKeyLM – Biến tạm để lưu trữ kết quả hàm LMGETKEY

CHALLENGE_MESSAGE.ServerChallenge – Tin nhắn challenge độ dài 8 bytes tạo ra bởi server

Z(M)- Hàm tạo mảng có độ dài M ký tự

Define NTOWFv1(Passwd, User, UserDom) as MD4(UNICODE(Passwd))

EndDefine

Define LMOWFv1(Passwd, User, UserDom) as

ConcatenationOf( DES( UpperCase( Passwd)[0 6],"KGS!@#$%"),

DES( UpperCase( Passwd)[7 13],"KGS!@#$%"))

EndDefine

Set ResponseKeyNT to NTOWFv1 (Passwd, User, UserDom)

Set ResponseKeyLM to LMOWFv1 (Passwd, User, UserDom)

Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,

CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)

As

If (User is set to "" AND Passwd is set to "")

Trường hợp xảy ra khi có anonymous authentication

Set SessionBaseKey to MD4(NTOWF)

Đoạn mã giả dưới đây thể hiện thuật toán signing và tạo khóa phiên trong NTLM v2 [19]

Ý nghĩa các trường và các biến:

NegFlg, User, UserDom - Cờ thể hiện tương thích giữa client và server, tên user

và tên domain

Passwd - Mật khẩu của user

LmChallengeResponse - LM response trả về cho server sau khi nhận được server challenge

Được tạo ra bởi client

NTChallengeResponse - NT response trả về cho server sau khi nhận được server challenge

Được tạo ra bởi client

ClientChallenge - Tin nhắn challenge độ dài 8 bytes tạo ra bởi client và gửi cho server

CHALLENGE_MESSAGE.ServerChallenge - Tin nhắn độ dài 8 bytes tạo ra bởi server

ResponseKeyNT - Biến tạm lưu giữ kết quả NTOWF()

ResponseKeyLM - Biến tạm lưu giữ kết quả LMGETKEY

ServerName - Tên server

KeyExchangeKey - Biến tạm lưu giữ kết quả KXKEY

HiResponserversion - Version trả về từ server, độ dài 1 byte Luôn có giá trị 1 Responserversion - Version trả về từ client, độ dài 1 byte Luôn có giá trị 1 Time - 8-byte little-endian time in GMT.p

Z(M) - Hàm tạo mảng M ký tự

Define NTOWFv2(Passwd, User, UserDom) as HMAC_MD5(

MD4(UNICODE(Passwd)), UNICODE(ConcatenationOf( Uppercase(User), UserDom ) ) )

EndDefine

Define LMOWFv2(Passwd, User, UserDom) as NTOWFv2(Passwd, User,

UserDom)

EndDefine

Set ResponseKeyNT to NTOWFv2(Passwd, User, UserDom)

Set ResponseKeyLM to LMOWFv2(Passwd, User, UserDom)

Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,

CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)

As

If (User is set to "" && Passwd is set to "")

Trường hợp đặc biệt xảy ra anonymous authentication

Set temp to ConcatenationOf(Responserversion, HiResponserversion,

Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4))

Set NTProofStr to HMAC_MD5(ResponseKeyNT,

ConcatenationOf(CHALLENGE_MESSAGE.ServerChallenge,temp))

Set NtChallengeResponse to ConcatenationOf(NTProofStr, temp)

Set LmChallengeResponse to ConcatenationOf(HMAC_MD5(ResponseKeyLM, ConcatenationOf(CHALLENGE_MESSAGE.ServerChallenge,

Interactive NTLM authentication qua mạng thường bao gồm 2 thành phần: client system, nơi mà user yêu cầu chứng thực, và domain controller, nơi những thông tin liên quan đến user’s password được lưu giữ Noninteractive authentication, xảy ra khi người dùng sau khi đã đăng nhập nhưng cần được cấp quyền để truy cập tới các tài nguyên như các ứng dụng trên server thường bao gồm 3 thành phần: client, server

và domain controller thực hiện việc chứng thực thay cho server [25]

Những bước sau đây tóm lược các bước chứng thực của NTLM noninteractive Tại bước đầu tiên khi người dùng cung cấp thông tin chứng thực NTLM là một phần của quá trình chứng thực interactive

Bước 1: Bước này thuộc về quá trình chứng thực interactive Người dùng truy cập tới máy client và cung cấp các thông tin chứng thực như domain name, user name, password Máy client lúc này sẽ thực hiện việc mã hóa một chiều mật khẩu và sau đó xóa mật khẩu người dùng khỏi bộ nhớ

Bước 2: Client gửi username tới server dưới định dạng plaintext

Bước 3: Server tạo ra một dãy 16 byte ngẫu nhiên, dãy này được gọi là challenge hay nonce, và gửi cho client

Bước 4: Client mã hóa challenge bằng hash của password

Bước 5: Server gửi username, challenge đã gửi cho client, và response của client tới domain controller

Bước 6: Server dùng username nhận được để lấy hash mật khẩu của user từ Security Account Manager (SAM) database Và sử dụng password hash đó để mã hóa challenge

Bước 7: Domain Controller thực hiện so sánh kết quả mã hóa ở bước 6 và challenge nhận được (kết quả của bước 4) Nếu kết quả giống nhau, việc chứng thực

sẽ thành công

1.5 Tổng quan về Credential Security Support Provider (CredSSP)

CredSSP cho phép ứng ứng dụng có thể ủy nhiệm thông tin người dùng từ client tới server một cách bảo mật Trong RDP, CredSSP được dùng để gửi mật khẩu người dùng hay mã PIN đến server để thiết lập phiên remote một cách bảo mật

CredSSP được sử dụng để ngăn chặn việc người dùng gửi thông tin chứng thực tới những unauthorized server (ví dụ như những sever đang nằm dưới quyền điều khiển của các attacker) Mặc dù client có thể chứng thực thành công với server, nhưng không có nghĩa là server có thể tin tưởng để gửi thông tin của người dùng tới (server giả mạo)

CredSSP là một giao thức hỗn hợp dựa trên những giao thức bảo mật chuẩn khác Đầu tiên CredSSP sử dụng giao thức bảo mật tầng vận chuyển (Transport Layer Security/TLS Protocol) để tạo ra một kênh mã hóa giữa CredSSP client và CredSSP server Lúc này, client vẫn đang còn được xem là anonymous Tất cả những gói tin sau này sẽ được chuyển đi trong kênh mã hóa này Sau đó, CredSSP sẽ dùng Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO) để chứng thực người dùng và server trong kênh TLS được

trước đó Client mã hóa khóa public của server với khóa trên và gửi cho server Server kiểm tra liệu đó có đúng là khóa public đã được dùng trong TLS handshake và trả lời lại cho client (đồng thời mã hóa khóa public và trả lại cho client) Cuối cùng, client

sẽ gửi thông tin chứng thực được mã hóa bằng khóa lấy từ phiên chứng thực SPNEGO

Tất cả dữ liệu truyền thông giữa client và server sau này được mã hóa bên trong kênh TLS Điểm mới trong CredSSP là việc đóng gói SPNEGO tokens trong kênh TLS, cùng với việc gắn TLS và giao thức SPNEGO

Hình dưới đây thể hiện sự truyền thông giữa CredSSP client và CredSSP server

Hình 1.3: Truyền thông giữa CredSSP client và CredSSP server [17]

Từ bước 1 tới bước 4, client và server hoàn thành việc thiết lập phiên TLS Khi phiên TLS được thiết lập xong, tất cả các gói tin của giao thức CredSSP lúc này

sẽ được truyền trong kênh TLS

Tại bước 5 và 6, client và server sẽ thực hiện việc chứng thực lẫn nhau và cùng tạo ra một khóa phiên chung

Tại bước 7 và 8, khóa công khai X.509 certificate của server khi thực hiện thiết lập phiên TLS được kiểm tra liệu có đúng là của server(không phải là của “man-in-the-middle” attacker)

Quá trình kiểm tra sẽ diễn ra như sau: CredSSP client sẽ dùng khóa phiên SPNEGO để mã hóa server certificate mà server đã dùng để thiết lập phiên TLS với client Sau đó gửi certificate đã mã hóa này cho CredSSP server Server sau khi nhận được sẽ tiến hành giải mã certificate này với khóa phiên SPNEGO và kiểm tra certificate này có đúng với certificate đã dùng để tạo kết nối với client hay không Nếu đúng, server sẽ thêm 1 vào certificate này, mã hóa bằng khóa phiên SPNEGO và gửi lại cho client

Client sau khi nhận được certificate mã hóa từ server sẽ tiến hành giải mã và kiểm tra, nếu đúng, việc chứng thực được coi như hoàn tất

Bước 9, client gửi thông tin chứng thực của mình tới server trong kênh được

mã hóa và bảo vệ bởi TLS và SPNEGO

Điều này có nghĩa, để có thể MITM giữa client và server, attacker cần phải có hoặc server SSL certificate hoặc phải có password của người muốn remote Có 1 trong 2 điều này chứng tỏ attacker đã kiểm soát được server và không cần phải thực hiện MITM nữa Dẫn đến với NLA, tấn công MITM gần như bất khả thi và hiện tại chưa có nghiên cứu nào đưa ra phương pháp tấn công MITM với NLA

1.6 Giới thiệu về Simple and Protected Generic Security Service

Application Program Interface Negotiation Mechanism (SPNEGO)

SPNEGO là một bản mở rộng của Microsoft cung cấp cơ chế trao đổi dữ liệu cho Generic Security Service Application Program Interface (GSS-API) [18] SPNEGO cung cấp một khung chung cho hai bên tham gia việc chứng thực để có thể cùng xác định một cơ chế chứng thực chung, và để làm cho giao thức bảo mật trở nên trong suốt với các giao thức của ứng dụng sử dụng SPNEGO

SPNEGO là một giao thức bảo mật sử dụng cơ chế chứng thực API API là một tập các API và các phương thức được sử dụng cho việc chứng thực Điều này làm cho việc tương tác giữa giao thức của các ứng dụng và các giao thức chứng

GSS-thực được đơn giản hóa Trong mô hình này, các giao thức ứng dụng cần phải đảm bảo việc truyền tải các gói tin được tạo ra bởi các giao thức chứng thực Các gói tin này, thường được gọi là các security token, sẽ thực hiện quá trình chứng thực Các giao thức ứng dụng sẽ không thể biết được bên trong các gói tin này có gì, chỉ đơn giản là truyền các gói tin này đi

Giao thức ứng dụng ban đầu sẽ gọi tới các giao thức chứng thực có trên client, security token sẽ được tạo và trả lại cho ứng dụng gọi tới Giao thức ứng dụng sẽ chuyển các tokens này tới server, nhúng cùng với các gói tin của giao thức ứng dụng

Ở phía server, giao thức ứng dụng của server sẽ trích xuất các security tokens này và gửi cho giao thức chứng thực của server Giao thức chứng thực của server lúc này sẽ

xử lý các tokens và hoặc tạo ra phản hồi, hoặc xác định quá trình chứng thực đã hoàn tất Nếu có thêm các security tokens khác được tạo ra, giao thức ứng dụng phải gửi lại cho client và tiếp tục phiên xử lý

Việc trao đổi các security tokens sẽ được diễn ra liên tục cho tới khi một bênh xác định việc chứng thực thất bại hoặc cả 2 bên xác định hoàn thành chứng thực Nếu chứng thực thất bại, giao thức ứng dụng sẽ ngắt kết nối và trả về mã lỗi Nếu chứng thực thành công, giao thức ứng dụng có thể chắc chắn rằng định danh của bên mình muốn kết nối là chính xác Việc quyết định chứng thực thành công hay thất bại hoàn toàn do giao thức chứng thực xử lý và quyết định, điều này tạo ra sự đơn giản cho giao thức ứng dụng

Sau khi chứng thực hoàn tất, các dịch vụ bảo mật phiên cũng có thể được sử dụng Giao thức ứng dụng có thể gọi tới giao thức chứng thực để thực hiện ký/sign hoặc mã hóa các tin nhắn gửi đi như là một phần đi cùng với giao thức ứng dụng Hoạt động của các dịch vụ bảo mật phiên cũng diễn ra tương tự, giao thức ứng dụng

có thể xác định phần nào của tin nhắn sẽ được mã hóa, và giao thức ứng dụng cần phải gửi kèm theo security token cho mỗi tin nhắn Điều này đảm bảo tính toàn vẹn

và tính bảo mật cho các tin nhắn

Dòng dữ liệu trao đổi trong SPNEGO sẽ diễn ra như sau:

1.8 Các phiên bản của Remote Desktop cùng các lỗ hổng

Hiện nay với một số điều kiện nhất định, có thực hiện việc tấn công MITM với Remote Desktop Protocol

Ví dụ như Windows 2000 Terminal Server,Windows 2000 Advanced Server, Windows Server 2003 và Windows XP, khóa private dùng trong mã hóa phiên được dùng như một hằng số và luôn có sẵn trên các máy client Với khóa private có sẵn này, hackers có thể nghe lén giải mã những thông tin được mã hóa trong phiên remote của admin [8]

Mặc định, dữ liệu trong phiên RDP sử dụng RDP Security sẽ mã hóa dữ liệu truyền thông giữa client và server theo thuật toán mã hóa RC4 Khóa mã hóa sẽ lần lượt theo 3 mức: high(128 bits), medium(56 hoặc 40 bits), low(56 hoặc 40 bits, nhưng chỉ mã hóa dữ liệu truyền từ client tới server) Khóa này sẽ được client và server chia

sẻ với nhau qua thuật toán mã hóa bất đối xứng RSA

Trong quá trình trao đổi và thiết lập khóa phiên, server sẽ gửi cho client certificate được lấy từ registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\Certificate

Hình 1.5: Khóa công khai và chữ ký của server trong registry key [8]

Phần modulus(n) của khoá công khai hoàn toàn giống với khóa RSA2 có trong trường LSA Secret “L$HYDRAENCKEY” của server Và phần chữ ký chính là thông tin được dùng để client xác nhận server

Chữ ký trong trườn hợp này được tạo ra bằng cách thực hiện thuật toán hash(md5) khóa công khai của server và mã hóa hash này bằng thuật toán bất đối xứng(RSA) sử dụng khóa private của server Về phía client, chữ ký sẽ được kiểm tra bằng cách giải mã bằng thuật toán bất đối xứng sử dụng khóa công khai của server

và so sánh với hash khóa công khai của server mà client đã tính toán Nếu 2 hash này giống nhau, server sẽ được client xác nhận

Microsoft sử dụng một khóa private được hard-coded trong thư viện mstlsapi.dll, và khóa này có trên tất cả các máy Windows Cấu trúc của cặp khóa hard-coded này như sau:

Hình 1.6: Cặp khóa có trên các máy Windows [8]

Với việc biết trước cặp khóa public-private này, attacker có thể giả mạo được chữ ký và tiến tới việc giả mạo được server

Portcullis Labs [21] cũng phát triển một công cụ nghe lén đóng vai trò như một RDP proxy để thực hiện việc relay qua lại giữa client và server trong phiên RDP

Hai vấn đề lớn về security đối với RDP là tấn công brute force dựa trên từ điển

có sẵn và man in the middle (MITM) [1] [2] [6] [9] Tuy nhiên tấn công MITM luôn mang lại hiệu quả tốt hơn khi brute force tạo ra độ noise rất lớn trong network [14],