ในบทความที่แล้ว เราบอกว่าวิธีหนึ่งในการป้องกันยูทิลิตี้ที่คล้ายกับ mimikatz คือการปิดใช้งานสิทธิ์ในการดีบักสำหรับผู้ดูแลระบบโดยใช้นโยบายโปรแกรมดีบั๊ก อย่างไรก็ตาม เมื่อเร็ว ๆ นี้ปรากฏว่าหากไม่มีสิทธิ์ดีบัก (คือ SeDebugPrivilege ใน Windows) ผู้ดูแลระบบเซิร์ฟเวอร์ในพื้นที่ไม่สามารถติดตั้งหรืออัปเดต Microsoft SQL Server ได้ ประเด็นก็คือเมื่อเริ่มต้น โปรแกรมติดตั้ง SQL Server จะตรวจสอบว่ามีสิทธิ์ของ SeSecurity, SeBackup และ SeDebug หรือไม่ จำเป็นต้องเรียกใช้กระบวนการ SQL Server และรับข้อมูลเกี่ยวกับการเริ่มต้น SQL Server ที่ประสบความสำเร็จ นี่คือสิ่งที่ดูเหมือน
ระหว่างการติดตั้ง SQL Server โปรแกรมติดตั้งจะทำการตรวจสอบเบื้องต้นและระบุปัญหาบางอย่างเกี่ยวกับตั้งค่าสิทธิ์ของบัญชี .
หากคุณคลิกลิงก์ล้มเหลว คุณจะเห็นข้อความต่อไปนี้:
กฎ "ตั้งค่าสิทธิ์ของบัญชี" ล้มเหลวบัญชีที่กำลังเรียกใช้การตั้งค่าเซิร์ฟเวอร์ SQL ไม่มีสิทธิ์อย่างใดอย่างหนึ่งหรือทั้งหมดต่อไปนี้:สิทธิ์ในการสำรองไฟล์และไดเรกทอรี สิทธิ์ในการจัดการการตรวจสอบและบันทึกการรักษาความปลอดภัย และสิทธิ์ในการดีบักโปรแกรม หากต้องการดำเนินการต่อ ให้ใช้บัญชีที่มีสิทธิ์ทั้งสองนี้ สำหรับข้อมูลเพิ่มเติม โปรดดู https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx และ https://msdn .microsoft.com/en-us/library/ms813847.aspx
ตอนนี้เปิด SystemConfigurationCheck_Report.htm รายงาน.
อย่างที่คุณเห็น เมื่อตรวจสอบ HasSecurityBackupAndDebugPrivilegesCheck ผู้ติดตั้งพบว่ากระบวนการปัจจุบันไม่มีสิทธิ์อย่างใดอย่างหนึ่งต่อไปนี้:
- Security – จัดการบันทึกการตรวจสอบและความปลอดภัย
- SeBackup – สิทธิ์ในการสำรองข้อมูลไฟล์และโฟลเดอร์
- SeDebug — สิทธิ์ในการดีบักโปรแกรม
มีข้อมูลโดยละเอียดในบันทึกที่แสดงว่ากระบวนการติดตั้งไม่มีการตั้งค่าสถานะ 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
ฉันได้ตัดสินใจค้นหาวิธีแก้ปัญหาเพื่อรับ SeDebugPrivilege โดยไม่ต้องเปลี่ยนหรือปิดใช้งานนโยบายโปรแกรมดีบั๊ก ปรากฎว่ามีวิธีค่อนข้างง่ายในการข้ามนโยบายนี้หากคุณมีสิทธิ์ของผู้ดูแลระบบในพื้นที่บนเซิร์ฟเวอร์ของคุณ ความลับ เครื่องมือที่ช่วยให้จัดการนโยบายความปลอดภัยท้องถิ่นของเซิร์ฟเวอร์จะช่วยเราได้
ตรวจสอบสิทธิ์ปัจจุบัน:
whoami /priv
อย่างที่คุณเห็น ไม่มี SeDebugPrivilege ในโทเค็นปัจจุบันของผู้ใช้
ส่งออกสิทธิ์ผู้ใช้ปัจจุบันที่กำหนดโดยนโยบายกลุ่มไปยังไฟล์ข้อความ:
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS
ใช้โปรแกรมแก้ไขข้อความใด ๆ เปิด secpolicy.inf และเพิ่มสตริงลงใน [สิทธิ์พิเศษ] ส่วนที่เปิดใช้สิทธิ์ Debug Programs ให้กับกลุ่มผู้ดูแลระบบในพื้นที่
SeDebugPrivilege = *S-1-5-32-544
บันทึกไฟล์. ตอนนี้ใช้สิทธิ์ผู้ใช้ใหม่:
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS
ออกจากระบบและเข้าสู่ระบบอีกครั้งและใช้ secpol.msc ตรวจสอบให้แน่ใจว่าได้กำหนดสิทธิ์ของโปรแกรมแก้ไขข้อบกพร่องให้กับกลุ่มผู้ดูแลระบบภายในแล้ว เช่นเดียวกันแสดงในผลลัพธ์ของคำสั่ง whoami /priv:
SeDebugPrivilege Debug programs Enabled
ตอนนี้คุณสามารถเรียกใช้การติดตั้งหรืออัปเดต SQL Server ของคุณได้ แต่โปรดทราบว่า SeDebugPrivilege ถูกกำหนดไว้ชั่วคราวและจะถูกรีเซ็ตในรอบการอัปเดต GPO ถัดไป (หลังจากที่ผู้ใช้ออกจากระบบแล้ว)
คุณควรเข้าใจว่าถ้าคุณเปิดใช้งานนโยบายโปรแกรมดีบั๊ก จะไม่ปกป้องคุณจากการรับ SeDebugPrivilege โดยซอฟต์แวร์ที่เป็นอันตรายที่เจาะเซิร์ฟเวอร์ของคุณแล้วด้วยสิทธิ์ของผู้ดูแลระบบในพื้นที่ และอาจทำให้บัญชีผู้ใช้/ผู้ดูแลระบบทั้งหมดที่ทำงานบนเซิร์ฟเวอร์ประนีประนอมได้
