보안 데스크톱에서 활성화되지 않은 UAC 창이 안전할까?
이에 대한 해답은 바로 "UIPI(User Interface Privilege Isolation)"에 있습니다. 그리고 물론, 그 바탕에는 MIC 설정이 존재합니다.
보안을 위해서, UAC 확인창은 별도의 보안 데스크톱에서 활성화되어져 있는 것이 기본값입니다. 하지만, 이 값은 "로컬 보안 정책"에 의해서 변경이 가능합니다. 그렇다면, 그렇게 변경된 경우에 UAC 창이 과연 안전하다고 말할 수 있을까요?
이를 위해서, 먼저 확인해 봐야 할 것이 보안 데스크톱을 사용하지 않는 경우에 UAC 확인창이 어떤 신뢰도 등급을 갖느냐인데요. 아래에서 한번 확인해 보도록 하겠습니다.
1. 우선, 예를 들기 위해 관리자 권한을 필요로 하는 응용 프로그램을 실행시킴으로써 다음 화면과 같이 UAC 확인창을 띄워 봅니다. 보안 데스크톱을 사용하지 않았으므로 화면 전환 없이 바로 윈도우 창으로 뜨게 됩니다.
2. 다음으로, 신뢰도 등급은 프로세스 레벨로 설정되기 때문에 위의 윈도우를 소유한 프로세스를 알아내야 합니다. 음... 이를 위해서 뭐 혹시 딱히 생각나는 프로그램 있으신가요? 저는...? 없습니다. 대신에 그 반대로 프로세스가 소유한 윈도우 목록을 알아내는 유틸리티를 알고 있습니다. 멋진 "신영진" 님께서 만들어 주신 "findwin.exe" 툴이 그것입니다. ^^ 해당 프로그램을 실행시켜서 ... 하나 하나 프로세스마다 찾는 방법이 있지만, 사실 뭐 저 같은 경우 이미 해당 프로세스가 consent.exe 라는 것을 알고 있기 때문에 그냥 확인 차원에서 한번 띄워봤습니다. ^^;
(참고로 소스까지 공개되어 있기 때문에, 윈도우 핸들값을 기준으로 프로세스를 반대로 찾아가는 것도 만들어 보실 수 있습니다.)
3. 프로세스 이름이 "consent.exe"라는 것도 알았으니, 예전에 설명드린 데로 나머지는 "Process Explorer"에게 맡기면 되겠군요. 아래와 같이 해당 프로세스를 찾아서,
신뢰도 등급값을 확인해 보면, 다음과 같이 "System" 등급을 가진 것을 확인할 수 있습니다.
자, 그렇다면 도대체 위에서 알아본 사항과 UAC 확인창이 안전하냐에 대한 것과 무슨 상관이 있는 걸까요? 그 연관 고리는 바로 UIPI(User Interface Privilege Isolation)라는 것에 있습니다.
UIPI 란?
동일한 데스크톱 내에서 상호작용중인 응용 프로그램일지라도, 특정 권한으로 실행중인 프로세스와 그 보다 낮은 권한의 계정으로 실행중인 프로세스를 구분하여 보안을 적용하는 기술입니다. 이로 인해, 낮은 권한의 프로세스가 높은 권한의 프로세스로 윈도우즈 메시지를 전송하는 것을 차단하게 되는데요. (그 반대의 메시지 전송은 가능합니다.) 대략 다음과 같은 보안 제약을 수행하고 있습니다.
(낮은 권한의 프로세스로부터)
- 높은 권한의 프로세스가 소유한 윈도우 핸들의 유효성 검증을 수행하는 것을 차단
- 높은 권한의 프로세스로 SendMessage or PostMessage 전송하는 것을 차단. (반환값 자체는 성공을 가리킴)
- 높은 권한의 프로세스로 사용자 스레드 후킹하는 것을 차단
- 높은 권한의 프로세스에 대한 "Journal" 후킹하는 것을 차단
- 높은 권한의 프로세스에 대한 DLL injection 수행하는 것을 차단
위의 제약으로 인해 발생할 수 있는 예를 하나 더 들어볼까요? 지금, VS.NET 2005를 관리자 권한으로 실행해 보십시오. 그다음, 탐색기에서 txt 또는 cs 등의 확장자를 가진 파일을 끌어다가 VS.NET 2005 IDE 에 놓아 보십시오. 동작이 안되지요? 왜냐하면, "medium" 레벨의 탐색기에서 (관리자 권한으로 실행된)"high" 레벨의 VS.NET 2005에 대해 끌어다 놓기와 관련된 윈도우 메시지가 전혀 동작을 안하기 때문입니다.
그렇다고 해서 무조건 차단만 하는 것은 아니고, 다음의 자원들 같은 경우에는 높은 권한의 프로세스들과도 공유가 가능합니다.
- 화면을 제어하는 Desktop 윈도우 (낮은 권한의 응용 프로그램이 높은 권한의 응용 프로그램 윈도우 영역을 덮어서 그리는 것이 가능)
- 데스크톱 힙 - 읽기 전용의 공유 메모리
- 전역 아톰 테이블
- 클립보드
위와 같은 UIPI 보안적용으로 인해, Medium 레벨의 일반 사용자 프로세스가 System 레벨의 Consent.exe 에서 띄운 UAC 윈도우 메시지 창을 전혀 제어할 수 없게 됩니다. 이 정도면, 충분히 안전하다고 볼 수도 있겠지요. 그렇긴 한데 마이크로소프트는 보다 더 강력한 보안을 원해서인지 "보안 데스크톱"을 사용하는 것이 기본 설정으로 되어 있습니다.
위에서 설명한 것들을 간단한 코딩을 통해서 테스트를 해보는 걸로 마무리해보겠습니다.
간단하게 .NET WinForm 응용 프로그램을 만들어서 다음과 같이 코딩해 줍니다. 아래의 코드가 의도하는 것은, 5초 후에 현재 활성화되어 있는 윈도우에 "Enter"키가 입력될 수 있도록 해주는 것입니다.
[DllImport("user32.dll")]
static extern void keybd_event(byte bVk, byte bScan, uint dwFlags,
UIntPtr dwExtraInfo);
private void Form1_Load(object sender, EventArgs e)
{
ThreadPool.QueueUserWorkItem(
delegate(object objState)
{
Thread.Sleep(5000);
byte byteCode = (byte)Keys.Enter;
keybd_event(byteCode, byteCode, KEYEVENTF_EXTENDEDKEY, UIntPtr.Zero);
keybd_event(byteCode, byteCode, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, UIntPtr.Zero);
}
);
}
음... 기왕에 Lambda 표현을 공부해 봤으니, 위의 delegate 구문을 다음과 같이 바꿔보는 것도 좋겠지요.
private void Form1_Load(object sender, EventArgs e)
{
ThreadPool.QueueUserWorkItem(
objState =>
{
Thread.Sleep(5000);
byte byteCode = (byte)Keys.Enter;
keybd_event(byteCode, byteCode, KEYEVENTF_EXTENDEDKEY, UIntPtr.Zero);
keybd_event(byteCode, byteCode, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, UIntPtr.Zero);
}
);
}
이제 위의 프로젝트를 컴파일 한후, 해당 프로그램을 "표준 사용자" 권한으로 한번 실행하고, "관리자"권한으로도 한번 실행해 보십시오. 테스트를 위해서 UAC 창을 활성화시킨 후, 아무리 기다려도 UAC 창에는 "Enter"키 값이 전달되지 않는 것을 확인할 수 있습니다. 물론, 다른 응용 프로그램을 실행(medium 레벨)해서 포커스를 두시면 정상적으로 "Enter"키 값이 전달되는 것도 확인해 볼 수 있습니다.
그런데, 왜 "관리자"권한에서도 안되는지 의아하게 생각되진 않으신가요? 그것은 관리자 권한으로 실행시킨 프로세스 조차도 신뢰도 등급(MIC)으로 보면 "high"값일 뿐이고, UAC 확인창은 그보다 더 높은 신뢰도 등급을 가진 "system" 레벨로 활성화 되기 때문에 그런 결과가 나오는 것입니다.
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]