Trong bài viết trước, chúng tôi đã nói rằng một trong những cách bảo vệ chống lại các tiện ích giống như mimikatz là vô hiệu hóa đặc quyền gỡ lỗi dành cho quản trị viên hệ thống bằng cách sử dụng chính sách Chương trình gỡ lỗi. Tuy nhiên, gần đây hóa ra rằng nếu không có đặc quyền gỡ lỗi (đó là SeDebugPrivilege trong Windows), quản trị viên máy chủ cục bộ không thể cài đặt hoặc cập nhật Microsoft SQL Server. Vấn đề là khi khởi động, trình cài đặt SQL Server sẽ kiểm tra xem có các đặc quyền SeSecurity, SeBackup và SeDebug hay không. Nó cần chạy quy trình SQL Server và nhận thông tin về việc khởi động thành công SQL Server. Đây là những gì nó trông như thế này.
Trong quá trình cài đặt SQL Server, trình cài đặt thực hiện kiểm tra sơ bộ và xác định một số sự cố với Thiết lập đặc quyền tài khoản .
Nếu bạn nhấp vào liên kết Không thành công, bạn có thể thấy thông báo sau:
Quy tắc “Thiết lập đặc quyền tài khoản” không thành công. Tài khoản đang chạy SQL Server Setup không có một hoặc tất cả các quyền sau:quyền sao lưu tệp và thư mục, quyền quản lý kiểm tra và nhật ký bảo mật và quyền gỡ lỗi chương trình. Để tiếp tục, hãy sử dụng tài khoản có cả hai quyền này. Để biết thêm thông tin, hãy xem https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx và https://msdn .microsoft.com / en-us / library / ms813847.aspx.
Bây giờ, hãy mở SystemConfigurationCheck_Report.htm báo cáo.
Như bạn có thể thấy, khi kiểm tra HasSecurityBackupAndDebugPrivilegesCheck quy tắc, trình cài đặt nhận thấy rằng quy trình hiện tại không có một trong các đặc quyền sau:
- SeSecurity - quản lý nhật ký kiểm tra và bảo mật
- SeBackup - quyền sao lưu các tệp và thư mục
- SeDebug - đặc quyền gỡ lỗi các chương trình
Có một số thông tin chi tiết trong nhật ký cho thấy rằng quá trình cài đặt không có cờ SeDebug.
(09) 2017-12-12 11:15:13 Slp: Initializing rule : Setup account privileges (09) 2017-12-12 11:15:13 Slp: Rule is will be executed : True (09) 2017-12-12 11:15:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck (09) 2017-12-12 11:15:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege. (09) 2017-12-12 11:15:13 Slp: Evaluating rule : HasSecurityBackupAndDebugPrivilegesCheck (09) 2017-12-12 11:15:13 Slp: Rule running on machine: rom-sql10 (09) 2017-12-12 11:15:13 Slp: Rule evaluation done : Failed
Tôi đã quyết định tìm kiếm giải pháp thay thế để nhận SeDebugPrivilege mà không cần thay đổi hoặc tắt chính sách chương trình Gỡ lỗi. Hóa ra có một cách khá dễ dàng để bỏ qua chính sách này nếu bạn có đặc quyền quản trị viên cục bộ trên máy chủ của mình. Secedit công cụ cho phép quản lý các chính sách bảo mật cục bộ của máy chủ sẽ giúp ích cho chúng tôi.
Kiểm tra các đặc quyền hiện tại:
whoami /priv
Như bạn có thể thấy, không có SeDebugPrivilege trong mã thông báo hiện tại của người dùng.
Xuất các quyền của người dùng hiện tại do chính sách nhóm thiết lập sang tệp văn bản:
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS
Sử dụng bất kỳ trình chỉnh sửa văn bản nào, hãy mở secpolicy.inf và thêm một chuỗi vào [Quyền đặc quyền] phần cho phép các đặc quyền của Chương trình gỡ lỗi cho nhóm quản trị viên cục bộ.
SeDebugPrivilege = *S-1-5-32-544
Lưu các tập tin. Bây giờ hãy áp dụng các quyền của người dùng mới:
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS
Đăng xuất và đăng nhập lại và sử dụng secpol.msc đảm bảo rằng các đặc quyền của Chương trình gỡ lỗi được chỉ định cho nhóm quản trị viên cục bộ. Điều tương tự được hiển thị trong kết quả của lệnh whoami / priv:
SeDebugPrivilege Debug programs Enabled
Bây giờ bạn có thể chạy cài đặt hoặc cập nhật SQL Server của mình. Nhưng hãy nhớ rằng SeDebugPrivilege được chỉ định tạm thời và nó sẽ được đặt lại vào chu kỳ cập nhật GPO tiếp theo (sau khi người dùng đã đăng xuất).
Bạn nên hiểu rằng nếu bạn bật chính sách Gỡ lỗi chương trình, nó sẽ không hoàn toàn bảo vệ bạn khỏi bị phần mềm độc hại xâm nhập vào máy chủ của bạn với quyền quản trị viên cục bộ và nó có thể xâm phạm tất cả tài khoản người dùng / quản trị viên làm việc trên máy chủ.