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

비밀번호

댓글 작성자
 




... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13201정성태12/20/20225803오류 유형: 835. PyCharm 사용 시 C 드라이브 용량 부족
13200정성태12/19/20224755오류 유형: 834. 이벤트 로그 - SSL Certificate Settings created by an admin process for endpoint
13199정성태12/19/20224940개발 환경 구성: 656. Internal Network 유형의 스위치로 공유한 Hyper-V의 VM과 호스트가 통신이 안 되는 경우
13198정성태12/18/20224862.NET Framework: 2080. C# - Microsoft.XmlSerializer.Generator 처리 없이 XmlSerializer 생성자를 예외 없이 사용하고 싶다면?파일 다운로드1
13197정성태12/17/20224652.NET Framework: 2079. .NET Core/5+ 환경에서 XmlSerializer 사용 시 System.IO.FileNotFoundException 예외 발생하는 경우파일 다운로드1
13196정성태12/16/20224848.NET Framework: 2078. .NET Core/5+를 위한 SGen(Microsoft.XmlSerializer.Generator) 사용법
13195정성태12/15/20225302개발 환경 구성: 655. docker - bridge 네트워크 모드에서 컨테이너 간 통신 시 --link 옵션 권장 이유
13194정성태12/14/20225431오류 유형: 833. warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock파일 다운로드1
13193정성태12/14/20225546오류 유형: 832. error C7681: two-phase name lookup is not supported for C++/CLI or C++/CX; use /Zc:twoPhase-
13192정성태12/13/20225596Linux: 55. 리눅스 - bash shell에서 실수 연산
13191정성태12/11/20226491.NET Framework: 2077. C# - 직접 만들어 보는 SynchronizationContext파일 다운로드1
13190정성태12/9/20226975.NET Framework: 2076. C# - SynchronizationContext 기본 사용법파일 다운로드1
13189정성태12/9/20227855오류 유형: 831. Visual Studio - Windows Forms 디자이너의 도구 상자에 컨트롤이 보이지 않는 문제
13188정성태12/9/20226441.NET Framework: 2075. C# - 직접 만들어 보는 TaskScheduler 실습 (SingleThreadTaskScheduler)파일 다운로드1
13187정성태12/8/20226380개발 환경 구성: 654. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법 (2)
13186정성태12/6/20224926오류 유형: 831. The framework 'Microsoft.AspNetCore.App', version '...' was not found.
13185정성태12/6/20225896개발 환경 구성: 653. Windows 환경에서의 Hello World x64 어셈블리 예제 (NASM 버전)
13184정성태12/5/20225074개발 환경 구성: 652. ml64.exe와 link.exe x64 실행 환경 구성
13183정성태12/4/20225091오류 유형: 830. MASM + CRT 함수를 사용하는 경우 발생하는 컴파일 오류 정리
13182정성태12/4/20225810Windows: 217. Windows 환경에서의 Hello World x64 어셈블리 예제 (MASM 버전)
13181정성태12/3/20225214Linux: 54. 리눅스/WSL - hello world 어셈블리 코드 x86/x64 (nasm)
13180정성태12/2/20225290.NET Framework: 2074. C# - 스택 메모리에 대한 여유 공간 확인하는 방법파일 다운로드1
13179정성태12/2/20224621Windows: 216. Windows 11 - 22H2 업데이트 이후 Terminal 대신 cmd 창이 뜨는 경우
13178정성태12/1/20225199Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/20225874오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/20224745오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...