tìm hiểu và nghiên cứu giao thức kerberos và xây dựng mô phỏng quá trình xác thực khi người dùng thuộc về nhiều nhóm

Kích thước của token tăng lênkhi người dùng được thêm vào các nhóm bảo mật bổ sung, được đại diện bởi mộtSID bổ sung trong mã thông báo.Nếu người dùng là thành viên của nhóm trực tiếp ho

BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT

MÃ

*******

BÁO CÁO BÀI TẬP LỚN

TÌM HIỂU VÀ NGHIÊN CỨU GIAO THỨC KERBEROS VÀ XÂY DỰNG

MÔ PHỎNG QUÁ TRÌNH XÁC THỰC KHI NGƯỜI DÙNG THUỘC VỀ NHIỀU NHÓM

Sinh viên thực hiện:

Lã Văn Tuấn – AT1606

Tạ Thành Thái – AT1606

Lò Văn Đại – AT160609

Người hướng dẫn:

Nguyễn Thị Hồng Hà

Hà Nội, 2023

MỤC LỤC

LỜI NÓI ĐẦU

Hiện nay công nghệ thông tin đang phát triển một cách mạnh mẽ, đi kèm đó

là việc sử dụng rộng rãi các hệ thống máy tính của cả cá nhân hay các tổ chức Vì vậy các thông tin quan trọng cũng được lưu trữ ngày một nhiều, đó cũng là mục tiêu của đa số các cuộc tấn công mạng hiện nay Cũng chính vì lý do đó mà việc có các biện pháp hay áp dụng các chính sách thích hợp để đảm bảo hệ thống máy chủ của mình luôn trong tình trạng an toàn và thông tin được bảo mật

Một trong các vấn đề cần lưu ý là các vấn đề xác thực trong các hệ phân tán

là một yếu tố vô cùng quan trọng bởi vì các hệ thống phân tán không làm việc đơn

lẻ mà phải tương tác với nhau Trong quá trình tương tác đó các hệ phân tán phải

có những quá trình xác thực để đảm bảo những yêu cầu về bảo mật cũng như gia tăng quyền hạn cho các thành viên, đặc biệt để chống lại những nguy cơ bảo mật ngày càng gia tăng hiện nay

Hiện nay có rất nhiều các phương pháp xác thực người dùng được áp dụng phổ biến như: username và password, chữ ký số Trong đó Kerberos là một trong những giao thức với cơ chế bảo mật tốt, có độ tin cậy cao và là giao thức xác thực

mã nguồn được cung cấp miễn phí mà đem lại hiệu quả cao

CHƯƠNG 1: TỔNG QUAN VỀ GIAO THỨC KERBEROS

1.Giới thiệu về Kerberos

1.1 Lịch sử hình thành và phát triển

CHƯƠNG 2:

CHƯƠNG 3: XÂY DỰNG MÔ PHỎNG GIAO THỨC KERBEROS

3.1 Xác thực người dùng thuộc nhiều nhóm

3.1.1 Sự cố về Kerberos Access Token

Windows tạo Access Token cho mỗi lần đăng nhập của người dùng Các Access Token chỉ định ID tài khoản người dùng và số nhận dạng bảo mật (SID) của tất cả nhóm bảo mật mà người dùng thuộc về Kích thước của token tăng lên khi người dùng được thêm vào các nhóm bảo mật bổ sung, được đại diện bởi một SID bổ sung trong mã thông báo

Nếu người dùng là thành viên của nhóm trực tiếp hoặc theo tư cách thành viên trong nhóm khác, thì SID cho nhóm đó được thêm vào token của người dùng

Có một giới hạn tích hợp trong đó Microsoft nói rằng số lượng SID có thể được chứa trong token access bị hạn chế đến 1024

Cách Windows phân bổ bộ nhớ cho Access Token có thể gặp thêm vấn đề quyền truy cập token Kích thước mặc định của Access Token của người dùng là 4K Số lượng chính xác của bộ nhớ thành viên nhóm bổ sung (và do đó SID bổ sung) góp phần vào dung lượng bộ nhớ trong Access Token mặc định 4K ban đầu này thay đổi một chút tùy thuộc trên loại nhóm - Global, Domain Local, Built-in, Local hoặc Universal Tuy nhiên, trung bình khoảng 80 nhóm sẽ hoàn toàn lấp đầy access token có kích thước 4K bộ nhớ này Khi người dùng vượt quá con số này, Windows sẽ không tăng kích thước của token theo số lượng cần thiết cho mỗi SID

bổ sung được thêm vào Thay vào đó, Windows phân bổ 4K bộ nhớ khác, do đó nhân đôi kích thước của Access Token Tương tự, với xấp xỉ 160 tổng số thành viên nhóm, Access Token của người dùng sẽ tăng thêm một lần nữa 4K từ 8K đến 12K Dung lượng bộ nhớ nhỏ này có vẻ không phải là vấn đề, nhưng cách các ứng dụng khác nhau lưu trữ các access token này và các giới hạn được xác định xung quanh bộ nhớ của chúng, nó có thể trở thành một vấn đề quan trọng Điều này đặc

biệt đúng trong các tổ chức lớn với hàng ngàn người dùng với tiềm năng nằm trong hàng trăm nhóm

Kerberos Token size

Giá trị MaxTokenSize nên được set về mức cao nhất 64K (0x0000FFFF) Với windows server 2012 và cao hơn, Microsoft đã thay đổi giá trị mặc định của MaxTokenSize là 48K do HTTP header Kerberos ticket trong một http requests được mã hóa ở dạng Base64

Nếu set MaxTokenSize với giá trị cao hơn 48K có thể gây ra một số vấn đề với HTTP request cùng Kerberos authentication

Access token (Group Membership)

Số lượng nhóm giới hạn là 1015 (or 1010) nhóm của một người dùng Nếu như một người dùng là thành viên của nhiều hơn 1015 nhóm, người dùng sẽ gặp lỗi "STATUS_TOO_MANY_CONTEXT_IDS"

Hiện nay như bạn có thể biết, kích thước tối đa của Access token mặc định cho gói xác thực Kerberos (tức là Kerberos SSP) là 8000 byte trong Windows 2000 và là 12.000 byte trong Windows Server 2003/8

3.1.2 Các dấu hiệu sự cố kích thước Access token

Các sự cố xuất phát giới hạn Access token Kerberos có thể được chia thành hai loại:

- Với TGT khi mà người dùng đăng nhập lúc đầu quá lớn

- Vé phiên được tạo (lưu lượng TGS) khi người dùng yêu cầu quyền truy cập vào tài nguyên mạng quá lớn

Một trong những trường hợp này làm cho kích thước vé Kerberos là một vấn

đề Nhóm dấu hiệu đầu tiên là khi số lượng SID trong TGT quá lớn Có một giới hạn tích hợp về số lượng SID có thể được chứa trong Access token Giới hạn đó được giới hạn ở 1024 Mặc dù nó cho phép vượt qua con số này trong Active

Directory, nhưng hậu quả là người dùng không thể đăng nhập Những giới hạn của access token cũng có thể ảnh hưởng đến các ứng dụng khác

Sự cố access token cũng có thể gây ra từ chối các sự cố dịch vụ với Máy chủ IIS 6.0, máy chủ web của Microsoft IIS 6.0 có giới hạn request headers của máy chủ http mặc định là 16K, vượt quá mức người dùng có kích thước access token kerberos là bất cứ thứ gì vượt quá con số này Với xấp xỉ 4K bộ nhớ cho 80 nhóm, giới hạn này bị vượt quá bởi tất cả người dùng có hơn 320 SID Người dùng có access token trên 16K bị từ chối khi xác thực với máy chủ IIS 6.0

Kích thước access token quá lớn cũng có một số hậu quả khác:

1 Access token phải được đánh giá trong quá trình đăng nhập của người dùng trước khi đăng nhập có thể được hoàn thành Bởi vì điều này, khi

số lượng thành viên nhóm bảo mật tăng lên, quá trình đăng nhập mất nhiều thời gian hơn

2 Để xác định quyền truy cập, vé phiên Kerberos chứa access token của người dùng được gửi đến mọi máy tính mà người dùng truy cập Do

đó, kích thước của access token có tác động trực tiếp đến lưu lượng mạng

3 Mỗi máy nhận vé Kerberos có kích thước được xác định trước trong registry LSA\Kerberos\Paramameter Nó được gọi là MaxTokenSize Cài đặt này giới hạn việc tạo access token trên Kerberos (mặc định 12.000 byte XP/Windows 2003) Khi đạt đến giới hạn bộ đệm này, nó

sẽ dẫn đến các sự cố tạo access token của Kerberosbase

4 Kích thước headers HTTP do vé phiên Kerberos lớn được truyền cũng

có thể có tác động trực tiếp đến tải lưu lượng mạng Nếu cần kích thước bộ đệm HTTP lớn hơn, băng thông mạng sẽ bị ảnh hưởng

3.1.3 Kịch bản Kerberos Token Bloat

Vấn đề này có lẽ được minh họa rõ nhất bằng một ví dụ, vì vậy chúng tôi sẽ chia sẻ

một ví dụ bao gồm 2 tình huống:

 Chủ tài khoản người dùng tên miền U từ miền A đăng nhập vào máy

Ma, trong đó máy này Ma cũng thuộc về miền A (tức là được nối miền với miền A)

 Sau đó, cùng một người dùng U này tiến hành sử dụng ứng dụng máy khách-máy chủ với thành phần máy chủ được lưu trữ trên máy Mb, trong đó máy Mb được nối với miền B

Kịch bản 1: Đăng nhập tương tác vào máy trên Miền A

Đây là những gì xảy ra khi tài khoản người dùng miền A cố gắng đăng nhập tương tác vào máy tham gia tên miền Ma

1 Chủ tài khoản người dùng tên miền U gọi Secure Attention Sequence (SAS) trên máy bằng cách nhấn Alt-Ctrl-Del

2 Sau khi gọi SAS, Winlogon chuyển sang màn hình đăng nhập và gửi GINA

để thu thập dữ liệu đăng nhập

3 GINA thu thập và trả lại dữ liệu đăng nhập của người dùng vào Winlogon, sau đó gửi dữ liệu tới LSA bằng cách gọi LsaLogonUser

4 LSA ngay lập tức chuyển đổi mật khẩu văn bản gốc của người dùng thành khóa bí mật bằng cách chuyển nó qua chức năng băm một chiều

5 LSA sau đó tạo dữ liệu xác thực trước bằng cách mã hóa dấu thời gian bằng khóa bí mật được lấy từ mật khẩu của người dùng

6 LSA sau đó gọi Kerberos SSP và gửi tin nhắn KRB_AS_REQ (bao gồm dữ liệu xác thực trước này) đến dịch vụ xác thực KDC của người dùng

7 Dịch vụ xác thực KDC, sử dụng danh tính người dùng (UPN) có trong KRB_AS_REQ để xác định vị trí người dùng trong cơ sở dữ liệu tài khoản của họ (Active Directory)

8 KDC sau đó sử dụng mật khẩu băm của tài khoản để cố gắng giải mã dữ liệu xác thực trước

9 Nếu KDC có thể giải mã thành công dữ liệu xác thực trước, thì nó sẽ tiến hành đánh giá dấu thời gian Nếu dấu thời gian vượt qua bài kiểm tra, KDC

có thể xác thực người dùng

10.Nếu người dùng được xác thực, KDC sẽ xác định tất cả các nhóm người dùng thuộc (trực tiếp hoặc gián tiếp) và đóng gói chúng trong PAC 11.KDC sau đó xây dựng TGT cho người dùng, chèn PAC này vào đó và trả lời lại bằng thông báo KRB_AS_REP, bao gồm TGT này cho người dùng 12.LSA sau đó gửi tin nhắn KRB_TGS_REQ đến dịch vụ cấp vé KDC, để yêu cầu vé phiên cho người dùng nhập học vào máy tính này

13.Vì máy tính này thuộc cùng một miền, KDC sau đó xác định tất cả các nhóm local security (trong miền này) mà người dùng thuộc về (trực tiếp hoặc gián tiếp.)

14.Sau đó, nó sao chép dữ liệu từ PAC được lưu trữ trong TGT vào PAC mới được tạo cho vé phiên này và thêm tất cả các nhóm local security miền đã xác định vào PAC này

15.Sau đó, nó tạo ra một vé dịch vụ tốt để được nhận vào máy tính này, chèn PAC mới vào đó và trả lời lại bằng tin nhắn KRB_TGS_REP, trong đó có vé dịch vụ này

16.Khi nhận được vé phiên người dùng cho máy tính này, LSA sẽ giải mã nó bằng khóa bí mật của máy tính và trích xuất PAC (chứa dữ liệu ủy quyền của người dùng.)

17.Sau đó, nó truy vấn cơ sở dữ liệu Security Accounts Manager (SAM) cục bộ

để xác định xem người dùng có phải là thành viên của bất kỳ nhóm local security nào của máy (trực tiếp hay gián tiếp.)

18.Nếu nó tìm thấy bất kỳ nhóm local security nào mà người dùng có thể là thành viên, thì nó sẽ thêm danh sách các nhóm được lấy từ PAC

19 Sau đó, nó tạo access token cho người dùng này và chuyển lại cho Winlogon

20.Winlogon sau đó tạo một trạm cửa sổ và một số đối tượng máy tính, đính kèm access token của người dùng và bắt đầu tiến trình shell được chỉ định cho người dùng này

Access token của người dùng sau đó được kế thừa bởi bất kỳ quy trình ứng dụng nào mà người dùng bắt đầu trong phiên đăng nhập Những điểm quan trọng cần lưu ý ở đây là trong quá trình tạo PAC cho vé phiên:

1 Tư cách thành viên được lấy từ PAC trong TGT

2 Chỉ những nhóm local domain thuộc miền miền máy tính (và trong đó người dùng là thành viên trực tiếp hoặc gián tiếp) mới được đưa vào Bây giờ, hãy giả sử rằng người dùng là thành viên của 10 nhóm Universal, 15 nhóm local và 25 nhóm local domain từ miền máy tính (trong trường hợp này giống như miền người dùng)

Trong trường hợp này, PAC trong vé phiên này có tất cả 50 nhóm bảo mật và kích thước token Kerberos kết quả sẽ vào khoảng 1200 + (40 * 25) + (8 * (15 + 10)) byte = 2400 byte, dựa trên công thức đề xuất của Microsoft, các chi tiết được cung cấp dưới đây

Vì 2400 byte thấp hơn giới hạn MaxTokenSize là 12000 byte, người dùng không gặp phải bất kỳ vấn đề nào với đăng nhập

Kịch bản 2: Đăng nhập mạng vào máy trên Miền B

Bây giờ chúng ta hãy giả sử rằng ngay sau khi đăng nhập, người dùng U khởi chạy phía máy khách của ứng dụng máy chủ-máy khách, phía máy chủ đang chạy trên một miền được nối với máy Mb trong miền B (tức là máy được nối với miền B.)

Giả sử rằng ứng dụng máy chủ-máy khách này sử dụng SSPI để xác thực mạng, thích sử dụng Kerberos và máy khách biết SPN của phía máy chủ của ứng

Đây là những gì xảy ra trong kịch bản này:

1 Người dùng khởi chạy phía máy khách của ứng dụng

2 Phía máy khách của ứng dụng thiết lập kết nối socket với máy chủ

3 Mỗi bên máy khách và máy chủ tiến hành gọi QuerySecurityPackageInfo() để xác định kích thước token tối đa cho Kerberos

4 Sau đó, mỗi bên máy khách và máy chủ tiến hành gọi AcquireCredentialsHandle() chuyển qua tên của gói Kerberos, để có được một điều khiển cho thông tin đăng nhập trước đó của họ

5 Sau đó, máy khách gọi LaunchizeSecurityContext() để cung cấp cho SSP cơ hội chuẩn bị token gửi đi (token này không bị nhầm lẫn với token truy nhập của windows“Windows access token”

6 Sau đó, client truyền token thông báo kết quả đến máy chủ

7 Khi máy chủ nhận được token này, nó gọi AcceptSecurityContext() để chuyển token đến SSP của nó

8 Sau khi vượt qua thành công chức năng AcceptSecurityContext() ở phía máy chủ, hệ thống sẽ tạo một phiên đăng nhập mạng mới cho máy khách

9 Phía máy chủ sau đó sẽ gọi ImpersonateSecurityContext() để yêu cầu SSP đặt token cho phiên đăng nhập của máy khách (trên máy chủ)

10 Cuối cùng, khi hoàn thành, phía máy chủ sẽ gọi RevertSecurityContext() để ngừng việc mạo danh người gọi

Bây giờ, trong trường hợp ta chưa biết các trao đổi liên quan đến Kerberos cần thiết ở đâu trong mô tả ở trên, câu trả lời là chúng được SSP tự động xử lý ở giữa các bước 5 - 8 ở trên vì SSP tóm tắt chi tiết cụ thể về giao thức

Chúng ta giả định rằng người dùng là thành viên của 10 nhóm Universal, 15

nhóm Local và 25 nhóm Local domain từ tên miền người dùng (trong trường hợp này giống như tên miền người dùng)

Bây giờ, chúng ta cũng giả sử rằng người dùng này cũng là thành viên của

300 nhóm domain local security trong miền máy chủ

Trong trường hợp này, PAC trong vé phiên này sẽ chứa tất cả 325 nhóm security và kích thước token Kerberos sẽ có khoảng 1200 + (40 * 300) + (8 * (15 + 10)) byte = 13500 byte

Vì 13500 byte vượt quá giới hạn MaxTokenSize 12000 byte, nên người dùng thực sự sẽ không thể đăng nhập và Kerberos SSP rất có thể sẽ gây ra lỗi trong khi gọi hàm AcceptSecurityContext() trên máy chủ

Kết quả cuối cùng là người dùng sẽ không thể xác thực thành công với máy chủ và nếu máy chủ này đang chạy Windows Server 2008, bạn có thể thấy thông báo sau trong nhật ký sự kiện Kerberos

3.2 Giải pháp khắc phục vấn đề

Để giảm kích thước vé Kerberos, bạn có thể:

1 Giảm số nhóm của thành viên

2 Dọn dẹp lịch sử SID

3 Giới hạn số lượng người dùng được định cấu hình để sử dụng "trusted for delegation" Tài khoản được định cấu hình để sử dụng "trusted for delegation" với các yêu cầu bộ đệm cho mỗi SID có thể tăng gấp đôi Tăng kích thước thông qua Registry key với MaxTokenSize

Khi Windows 2000 ban đầu xuất hiện, kích thước tối đa của token cụ thể của gói xác thực Kerberos được mã hóa cứng là 8000 byte trong phiên bản RTM của Windows 2000 Nó xuất hiện từ năm 2001 Microsoft đã phát hành Hotfix, cho phép quản trị viên tăng giá trị này, dựa trên Registry key có tên MaxTokenSize

Hình 3 1 Khắc phục lỗi kerberos 1

Mặc dù giá trị này về mặt lý thuyết có thể định cấu hình thành giá trị lên tới

65535 byte Một người dùng có thể trong 1.015 nhóm + 9 BuiltIn-groups = tối đa 1.024 nhóm

Ngày nay, kích thước tối đa mặc định của token cụ thể của gói xác thực Kerberos là 12000 byte trong Windows Server 2003 và Windows Server 2008 và 48.000 byte trong Windows Server 2012

Microsoft cũng đã cung cấp các cách hiệu quả để thêm Registry key này vào các máy tính trong một miền Các tùy chọn bao gồm ứng dụng tệp ADM dựa trên GPO trong Windows Server 2003, sử dụng tiện ích mở rộng phía máy khách Registry trong Windows 2008 và sử dụng cài đặt GPO mới được xác định trong Windows Server 2012

3.2.1 Đặt kích thước tối đa cho bộ đệm token Kerberos

Trong Windows Server 2012 và Windows 8, Microsoft đã giới thiệu GPO mới để giúp dễ dàng đặt khóa đăng ký này trên nhiều máy tính Cài đặt mới này nằm trong System > Kerberos và được gọi là “Set maximum Kerberos SSPI context token buffer size”