Ôn chút kiến thức về ADCS

Posted Oct 27, 2024

By dwgth4i

8 min read

Do dạo gần đây khá ít lab về ADCS và lại còn mới có quả ESC15 (hay còn gọi là EKUwu) nữa nên là nay ôn lại đôi chút kiến thức về ADCS, mình sẽ viết về ADCS là gì và những concept chính trong ADCS (ít nhất là đối với mình nó là quan trọng và thật sự cần nắm bắt kĩ :v)

ADCS là gì ? PKI ?

Active Directory Certificate Services (ADCS) giúp các doanh nghiệp có một cái Public Key Infrastructure (PKI) riêng của họ, giúp đỡ trongg việc secure communication, user authentication, và cả data protection.

PKI là 1 hệ thống sử dụng những digital certificates và các cơ chế mật mã sử dụng public key. PKI cho phép sử dụng các chữ kĩ số, mã hóa, xác thực, …

Một cái digital certificate sẽ gán một cái public key vào một object ví dụ như người, tổ chức, thiết bị, hoặc service. Và một cái certificate như vậy sẽ được issue và kí bởi một Certificate Authority (CA) đã được trust, để xác nhận rằng danh tính của người giữ chiếc certificate đó là chuẩn và tính toàn vẹn của chiếc public key. Như đã nói thì ngoài public key, chiếc digital certificate sẽ còn bao gồm các thông tin khác như subject name (tên của user enroll chiếc certificate này), tên của người issue chiếc cert, khoảng thời gian valid của cert, …

Lí do để sử dụng ADCS thay vì PKI:

Tích hợp chặt với AD DS (Active Directory Domain Services: Giống như một cái database chứa các user, computer, group, và các object khác), giúp cho việc quản lý cert và xác thực giữa các tổ chức trong doanh nghiệp sử dụng AD đơn giản hơn
Có cơ chế thu hồi cert được built-in là Certificate Revocation List (CRL) và Online Certificate Status Protocol (OCSP).
Một vài thứ nữa nhưng mà không biết dịch ra tiếng việt như nào cho dễ hiểu :(( mọi người có thể đọc bài viết của các anh SpecterOps tại đây (https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf)

Các yếu tố quan trọng trong ADCS

Sau đây sẽ là định nghĩa của những thuật ngữ mà có thể mọi người sẽ thấy rất nhiều khi đọc các bài nghiên cứu về ADCS:

Certificate Templates: Những template được config sẵn giống như 1 cái bản thiết kế, chỉ ra các thuộc tính và chỉ ra xem cert sẽ dùng cho mục đích gì bởi ADCS. ADCS sẽ cho chúng ta các template tiêu chuẩn cho các tác vụ như Code Signing, Web server, …
Public Key Infrastructure (PKI): Một hệ thống tích hợp với nhiều thứ cho phép ta tạo ra, quản lý, phân phát, và thu hồi những chiếc cert.
Certificate Authority (CA): Đây sẽ là thành phần issue những chiếc cert cho các user, computer, service và giám sát thời gian hiệu lực của những chiếc cert đó luôn.
Standalone CA & Enterprise CA: Standalone CA sẽ hoạt động mà không cần AD, cho phép request những chiếc cert kia một cách manual hoặc web-based. Trái lại, Enterprise CA sẽ dựa vào AD, issue cert trong tổ chức.
Certificate Signing Request (CSR): CSR là những request bởi user hay computer đến một CA nào đó để nhận về một cái cert. Trong CSR sẽ bao gồm chiếc public key thuộc về người request, subject name và các loại thông tin định danh khác. Khi CSR được submit cho CA, CA sẽ xác nhận danh tính của thực thể gửi đi (gọi là thực thể vì có thể là user, computer, service, …) và thực hiện nhiều cú check. Nếu CSR được chấp nhận, CA sẽ gửi chiếc cert bao gồm chiếc public key của thực thể request và mục đích sử dụng.
Certificate Revocation List: Đây giống như một cái nơi bao gồm các thông tin về các chiếc cert đã được vô hiệu bởi CA, đảm bảo các thực thể có thể xác nhận trạng thái đã bị thu hồi của các chiếc cert.
Extended/Enhanced Key Usage (EKU): Đây sẽ là phần mô tả các mục đích sử dụng của cert. EKU cho phép các admin định nghĩa ra các mục đích sử dụng của chiếc cert như code signing, encrypt email, smart card logon. Cũng như các template, ADCS cũng cung cấp sẵn các EKU cho các việc như Server Authentication, Client Authentication, và Code Signing, cho phép các admin tự tạo ra các EKU phù hợp với doanh nghiệp.

Certificate

Một chiếc cert như đã nói, sẽ phục vụ các mục đích như mã hóa, xác thực, … nó có bao gồm các trường như:

Subject: Danh tính của người giữ chiếc cert.
Public Key: Public key tương ứng với Subject, và đương nhiên Subject sẽ là người có chiếc Private Key đi cùng với nó.
NotBefore và NotAfter dates: Khoảng thời gian valid của chiếc cert.
Serial Number: Một mã định danh độc nhất được gán bởi CA đã issue chiếc cert.
Issuer: Cho ta biết ai đã issue cert này, thường sẽ là một CA nào đó.
SubjectAlternativeName (SAN): Đây sẽ là trường cho phép requester định nghĩa ra cái tên khác mà họ có thể dùng đi cùng với SubjectName.
Extended Key Usages (EKUs): Các OID dùng để mô tả mục đích sử dụng của certificate. Các EKU thường thấy sẽ có thể dùng để cho các tác vụ như code signing, mã hóa tệp tin, secure email, client và server authentication, smart card logon.
Signature Algorithm and Signature: Trường này để chỉ ra thuật toán sử dụng trong việc kí cert và chữ kí được kí bởi private key của issuer (thường là CA).

Việc định danh trong certificate sẽ là liên kết thực thể (tức là Subject) với 1 cặp key. Ví dụ như khi request 1 cái cert, 1 user sẽ phải gen ra 1 cặp key. Trong CSR, requester sẽ gửi đi public key và kí sử dụng private key, từ đấy mà bên phía CA biết được là danh tính requester là valid.

Certificate Authorities

Enterprise CA sẽ sử dụng các certificate template để thiết lập các setting, trong đó có bao gồm thời hạn, mục đích sử dụng, điều kiện để các thực thể có thể request được. Những setting này có thể được định nghĩa thông qua các thuộc tính, còn quyền được enroll và edit template sẽ được kiểm soát thông qua security descriptors của chúng. Ví dụ như người dùng bất kì có quyền thấp đều có thể request được certificate A.

Quá trình Enroll

Để nhận được certificate từ ADCS, client sẽ cần đi qua 1 quá trình gọi là Enrollment Process.

Tìm một Enterprise CA: Bước đầu tiên là client sẽ cần tìm một Enterprise CA dựa trên các objects ở bên trong container Enrollment Services container như ở dưới đây, ta có thể thấy thông qua ADSIEdit.msc.
Sinh ra một cặp public-private key và khởi tạo một CSR: Client sẽ sinh ra 1 cặp key và tạo ra một certificate signing request (CSR) message. Message này sẽ chứa public key cùng với các thông tin khác như tên của certificate template và subject của certificate.
Kí CSR với private key và gửi cho Enterprise CA server: Client sẽ kí CSR với private key vừa được sinh ra và gửi cho Enterprise CA server.
CA kiểm tra xem client có quyền để request hay không: CA server sẽ kiểm tra quyền request của client. Trong certificate template sẽ có trường để kiểm tra quyền cho phép các account xác thực đến có được request hay không.
CA sinh ra certificate, kí nó và nếu được cho phép thì sẽ gửi về cho client: Nếu được cho phép, CA sẽ sinh ra certificate sử dụng certificate template đóng vai trò như bản thiết kế viết sẵn những setting cho chiếc cert như là EKUs, setting của loại mật mã sử dụng. Nếu được cho phép bởi certificate template, CA sẽ dùng thêm các thông tin khác trong CSR (ví dụ như SAN) và kí chiếc certificate sử dụng private key của CA và trả về cho client.
Nhận certificate: Client nhận về và lưu trữ certificate vào Windows Certificate store và sử dụng cho mục đích mà certificate đó vốn sinh ra để làm.

Conclusion

Khả năng nếu như sau này ngồi đọc lại thấy thiếu sót ở đâu mình sẽ ngồi viết thêm, đến cuối đây thì sau khi hiểu sơ sơ về hệ thống ADCS này thì dưới đây sẽ là các chùm lỗ hổng trong hệ thống này được đánh dấu từ ESC1->ESC?, tuy bài nghiên cứu từ SpecterOps từ hơn 2 năm trước rồi nhưng đó là lúc mà các lỗ hổng về ADCS bắt đầu được mở ra, hiểu được bài nghiên cứu đó cũng tương tự với việc sau này có thể giúp ta nắm rõ hơn về cách mà các anh ấy tìm được ra và từ đó tự nghiên cứu thêm (https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf)

Abusing Certificate Templates: Mục này sẽ bao gồm các lỗ hổng do misconfig các certificate templates (ESC1, ESC2, ESC3, ESC9, ESC10)
Abusing Access Control (ESC4, ESC5, ESC7): Cần hiểu về các misconfig liên quan đến Access Control, và theo như các nghiên cứu thì đây cũng là điểm yếu tiềm năng cho các ESC trong tương lai.
NTLM Relay (ESC8, ESC11): Khai thác NTLM relay dựa vào misconfig để leo quyền.

knowledge

This post is licensed under CC BY 4.0 by the author.