Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)


보안 데스크톱에서 활성화되지 않은 UAC 창이 안전할까?


이에 대한 해답은 바로 "UIPI(User Interface Privilege Isolation)"에 있습니다. 그리고 물론, 그 바탕에는 MIC 설정이 존재합니다.

보안을 위해서, UAC 확인창은 별도의 보안 데스크톱에서 활성화되어져 있는 것이 기본값입니다. 하지만, 이 값은 "로컬 보안 정책"에 의해서 변경이 가능합니다. 그렇다면, 그렇게 변경된 경우에 UAC 창이 과연 안전하다고 말할 수 있을까요?

이를 위해서, 먼저 확인해 봐야 할 것이 보안 데스크톱을 사용하지 않는 경우에 UAC 확인창이 어떤 신뢰도 등급을 갖느냐인데요. 아래에서 한번 확인해 보도록 하겠습니다.




1. 우선, 예를 들기 위해 관리자 권한을 필요로 하는 응용 프로그램을 실행시킴으로써 다음 화면과 같이 UAC 확인창을 띄워 봅니다. 보안 데스크톱을 사용하지 않았으므로 화면 전환 없이 바로 윈도우 창으로 뜨게 됩니다.

uac_without_secure_desktop_1.png

2. 다음으로, 신뢰도 등급은 프로세스 레벨로 설정되기 때문에 위의 윈도우를 소유한 프로세스를 알아내야 합니다. 음... 이를 위해서 뭐 혹시 딱히 생각나는 프로그램 있으신가요? 저는...? 없습니다. 대신에 그 반대로 프로세스가 소유한 윈도우 목록을 알아내는 유틸리티를 알고 있습니다. 멋진 "신영진" 님께서 만들어 주신 "findwin.exe" 툴이 그것입니다. ^^ 해당 프로그램을 실행시켜서 ... 하나 하나 프로세스마다 찾는 방법이 있지만, 사실 뭐 저 같은 경우 이미 해당 프로세스가 consent.exe 라는 것을 알고 있기 때문에 그냥 확인 차원에서 한번 띄워봤습니다. ^^;

uac_without_secure_desktop_2.png
(참고로 소스까지 공개되어 있기 때문에, 윈도우 핸들값을 기준으로 프로세스를 반대로 찾아가는 것도 만들어 보실 수 있습니다.)

3. 프로세스 이름이 "consent.exe"라는 것도 알았으니, 예전에 설명드린 데로 나머지는 "Process Explorer"에게 맡기면 되겠군요. 아래와 같이 해당 프로세스를 찾아서,

uac_without_secure_desktop_3.png

신뢰도 등급값을 확인해 보면, 다음과 같이 "System" 등급을 가진 것을 확인할 수 있습니다.

uac_without_secure_desktop_4.png




자, 그렇다면 도대체 위에서 알아본 사항과 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" 레벨로 활성화 되기 때문에 그런 결과가 나오는 것입니다.




[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/7/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13493정성태12/19/20232855닷넷: 2185. C# - object를 QueryString으로 직렬화하는 방법
13492정성태12/19/20232491개발 환경 구성: 699. WSL에 nopCommerce 예제 구성
13491정성태12/19/20232315Linux: 63. 리눅스 - 다중 그룹 또는 사용자를 리소스에 권한 부여
13490정성태12/19/20232449개발 환경 구성: 698. Golang - GLIBC 의존을 없애는 정적 빌드 방법
13489정성태12/19/20232232개발 환경 구성: 697. GoLand에서 ldflags 지정 방법
13488정성태12/18/20232203오류 유형: 884. HTTP 500.0 - 명령행에서 실행한 ASP.NET Core 응용 프로그램을 실행하는 방법
13487정성태12/16/20232490개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행 [1]
13486정성태12/15/20232302개발 환경 구성: 695. Nuget config 파일에 값 설정/삭제 방법
13485정성태12/15/20232176오류 유형: 883. dotnet build/restore - error : Root element is missing
13484정성태12/14/20232290개발 환경 구성: 694. Windows 디렉터리 경로를 WSL의 /mnt 포맷으로 구하는 방법
13483정성태12/14/20232414닷넷: 2184. C# - 하나의 resource 파일을 여러 프로그램에서 (AOT 시에도) 사용하는 방법파일 다운로드1
13482정성태12/13/20233114닷넷: 2183. C# - eFriend Expert OCX 예제를 .NET Core/5+ Console App에서 사용하는 방법 [2]파일 다운로드1
13481정성태12/13/20232431개발 환경 구성: 693. msbuild - .NET Core/5+ 프로젝트에서 resgen을 이용한 리소스 파일 생성 방법파일 다운로드1
13480정성태12/12/20232822개발 환경 구성: 692. Windows WSL 2 + Chrome 웹 브라우저 설치
13479정성태12/11/20232472개발 환경 구성: 691. WSL 2 (Ubuntu) + nginx 환경 설정
13477정성태12/8/20232723닷넷: 2182. C# - .NET 7부터 추가된 Int128, UInt128 [1]파일 다운로드1
13476정성태12/8/20232471닷넷: 2181. C# - .NET 8 JsonStringEnumConverter의 AOT를 위한 개선파일 다운로드1
13475정성태12/7/20232535닷넷: 2180. .NET 8 - 함수 포인터에 대한 Reflection 정보 조회파일 다운로드1
13474정성태12/6/20232351개발 환경 구성: 690. 닷넷 코어/5+ 버전의 ilasm/ildasm 실행 파일 구하는 방법 - 두 번째 이야기
13473정성태12/5/20232627닷넷: 2179. C# - 값 형식(Blittable)을 메모리 복사를 이용해 바이트 배열로 직렬화/역직렬화파일 다운로드1
13472정성태12/4/20232287C/C++: 164. Visual C++ - InterlockedCompareExchange128 사용 방법
13471정성태12/4/20232420Copilot - To enable GitHub Copilot, authorize this extension using GitHub's device flow
13470정성태12/2/20232757닷넷: 2178. C# - .NET 8부터 COM Interop에 대한 자동 소스 코드 생성 도입파일 다운로드1
13469정성태12/1/20232584닷넷: 2177. C# - (Interop DLL 없이) CoClass를 이용한 COM 개체 생성 방법파일 다운로드1
13468정성태12/1/20232413닷넷: 2176. C# - .NET Core/5+부터 달라진 RCW(Runtime Callable Wrapper) 대응 방식파일 다운로드1
13467정성태11/30/20232551오류 유형: 882. C# - Unhandled exception. System.Runtime.InteropServices.COMException (0x800080A5)파일 다운로드1
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...