이전 글에서 우리는 mimikatz와 같은 유틸리티에 대한 방어 방법 중 하나로 '프로그램 디버그(Debug Program)' 정책을 사용해 시스템 관리자의 디버그 권한을 비활성화하는 것을 소개했습니다. 그런데 최근 흥미로운 사실이 밝혀졌습니다. 디버그 권한(Windows에서는 SeDebugPrivilege)이 없으면 로컬 서버 관리자가 Microsoft SQL Server를 설치하거나 업데이트할 수 없다는 것입니다. 그 이유는 SQL Server 설치 프로그램이 시작될 때 SeSecurity, SeBackup, SeDebug 권한의 존재 여부를 확인하기 때문입니다. 설치 프로그램은 SQL Server 프로세스를 실행하고 정상적으로 시작되었는지 확인하기 위해 이러한 권한이 필요합니다. 실제 사례를 통해 자세히 살펴보겠습니다.
SQL Server 설치 시 발생하는 권한 오류
SQL Server 설치 과정에서 설치 프로그램은 사전 검사를 수행하며 설정 계정 권한(Setup account privileges)과 관련된 문제를 감지합니다.
'Failed' 링크를 클릭하면 다음과 같은 메시지를 확인할 수 있습니다:
"설정 계정 권한" 규칙 실패.SQL Server 설치 프로그램을 실행하는 계정에 다음 권한 중 하나 또는 전부가 없습니다: 파일 및 디렉터리 백업 권한, 감사 및 보안 로그 관리 권한, 프로그램 디버그 권한. 계속 진행하려면 이러한 모든 권한을 가진 계정을 사용하세요. 자세한 내용은 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 규칙을 검사하는 과정에서 현재 프로세스에 다음 권한 중 하나가 없음을 발견했습니다:
- SeSecurity – 감사 및 보안 로그 관리 권한
- 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
secedit을 이용한 SeDebugPrivilege 획득 방법
저는 '프로그램 디버그' 정책을 변경하거나 비활성화하지 않고도 SeDebugPrivilege를 얻을 수 있는 우회 방법을 찾아보기로 했습니다. 결과적으로 서버에 대한 로컬 관리자 권한만 있다면 이 정책을 비교적 쉽게 우회할 수 있다는 것을 알게 되었습니다. 바로 서버의 로컬 보안 정책을 관리할 수 있는 secedit 도구를 활용하는 것입니다.
먼저 현재 사용자의 권한을 확인합니다:
whoami /priv
위 출력 결과에서 볼 수 있듯이 현재 사용자 토큰에는 SeDebugPrivilege가 포함되어 있지 않습니다.
다음 명령으로 그룹 정책에 의해 설정된 현재 사용자 권한 설정을 텍스트 파일로 내보냅니다:
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS
텍스트 편집기로 secpolicy.inf 파일을 연 후, [Privilege Rights] 섹션에 로컬 관리자 그룹에게 프로그램 디버그 권한을 부여하는 문자열을 추가합니다.
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를 획득하는 것까지 완벽히 차단할 수는 없다는 점을 반드시 이해해야 합니다. 악성코드가 이 권한을 확보하면 서버에서 작동 중인 모든 사용자 및 관리자 계정이 탈취당할 위험에 노출될 수 있습니다. 따라서 이 정책은 여러 보안 대책 중 하나일 뿐이며, 단독으로 의존해서는 안 됩니다.