기억속으로 날다(Walking on Memory) : UI automation 응용프로그램을 위한 UIAccess

byung.egloos.com

Windows Integrity

Windows Vista 이후에 달라진 Security Model 중에 Windows Integrity 라는 구조가 소개되었다. 이것은 Security Reference Monitor 라는 것을 기반으로 하는 데, 이는 Object의 security descriptor의 ACL안에 접근 가능한 security access token이 갖고 있는 user 또는 group SID와의 비교에 의해서 강제적으로 제어하도록 되어 있다. 이와 같이 비교 가능한 integrity level은 security access token이 포함하며, mandatory label access control entry는 security descriptor의 system ACL에 추가되어 있다. (http://msdn.microsoft.com/en-us/library/bb625963.aspx 참조) 간단히 말해 특정 계정으로 수행되는 Process는 어떤 보안적인 integrity level이라는 것을 갖고 있는 데, 해당 process에서는 해당 integrity level보다 과한 수준의 resource에 접근할 수 없다는 구조이다. 예를 들어, Local System 계정은 SYSTEM level의 높은 Integrity 수준을 갖고 있으며, Administrators group 도 Admin level의 integrity를 갖고 있다. 일반 Standard User가 인증된 경우는 medium 수준의 level을, 그리고, everyone 계정은 low 수준의 level을 갖게 된다. 그러므로, 그에 따라 접근할 수 있는 resource도 제약이 따를 수밖에 없다. 이에 대해서 Process Explorer는 특정 Process의 Integrity 정보를 얻을 수 있다. 특정 process 속성 > Security TAB > GROUP & Flags(Integrity)).

User Interface Privilege Isolation (UIPI)

UIPI는 낮은 수준의 권한을 갖은 Application이 보다 높은 수준의 Application에서 Windows Message를 보내거나 Hooks을 Install 하거나 하는 동작을 windows subsystem에서 못하게 하는 제약사항을 말하는 용어이다. 예를 들어, WM_GETTEXT는 lover-privilege 에서 Higher-privilege window에 보낼 수있다. 단지, read type의 message는 가능하다. 하지만, WM_SETTEXT 의 경우는 안된다. 이러한 제약사항을 받는 것은 다음과 같은 것들이다.

ü (Higher rights로 수행되는 Process의) window handle validation을 시도하는 경우

ü SendMessage나 PostMessage의 경우 (이는 API level에서 Silently 하게 Drop된다.

ü Process에 붙어 Thread Hook을 사용하는 경우

ü Process의 Monitoring을 위해 Journal Hook을 사용하는 경우

ü DLL Injection을 하여는 경우

UI automation 응용프로그램을 위한 UIAccess

MSAA(Microsoft Active Accessibility)로 알려진 UI Automation Application은 User를 대신하여 다른windows applications에 대해 행위의 제어를 지원하도록 디자인된다. 그러므로, 일반적으로 UIPI에 대한 제약사항에 적용 받을 수 밖에 없는 데, 이에 대하여 적용 받지 않도록 구성할 수 있는 것이 UIAccess 에 대한 방식이다. UIAccess enabled Application을 구성하기 위해서는 다음과 같은 방법에 의해서 가능하다.

1. 먼저, 아래와 같은 manifest 가 필요하다.

<requestedExecutionLevel

level="asInvoker"

UIAccess="true" />

</requestedPrivileges>

</security>

</trustInfo>

특이한 것은 requestedExecutionLevel에 UIAccess = "true" 로 enable 되어 있다. 이것은 UIPI를 bypass 하겠다는 것이다.

2. [requirement]그리고, 반드시 digital signature를 가진 Application이여야 하며, 해당 Cert는 Local machine의 Trusted Root Certification Authorities의 Certificate store에 연결되어 있어야 한다. test를 위해서는 아래와 같은 절차와 같이 하면 된다. (참조: http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx )

1) trusted root certificate을 생성한다.

makecert -r -pe -n "CN=Test Certificate" -ss PrivateCertStore testcert.cer

certmgr.exe -add testcert.cer -s -r localMachine root

2) UIAccess application을 서명한다.

SignTool sign /v /s PrivateCertStore /n "Test Certificate"

/t http://timestamp.verisign.com/scripts/timestamp.dll

YourApp.exe

3.[requirement]또한, 해당 UIAccess enabled Application은 반드시 administrators group에 의해서 writable이 가능한 directory에 위치해야 한다. 보통은 %ProgramFiles% 나 그의 하위 폴더, 그리고, %WinDir%나 그의 하위폴더가 되겠다. 간혹, standard users의 쓰기권한 설정에 의해서 일부 폴더가 가능할 수도 있다.

추가적으로 UIAccess에 대한 몇몇 특징이 존재한다.

ü UIAccess enabled Application(EXE) 는 Standard users에 의해서 구동이 된다.

ü 하지만, UIAccess Enabled COM EXE 의 경우는 Interface를 통해서 (CoCreateInstance 등) Launch 시킬 수 없다. 그러므로, ShellExecute API등을 이용하여 구동할 수 있다.

ü UIAccess enabled Application은 High IL 을 갖게 된다. 그러므로, COM Server가 launch user 이 경우에, High IL Client나 COM Elevation Moniker(http://msdn.microsoft.com/en-us/library/ms679687(VS.85).aspx) 를 사용한 Medium IL Client 는 COM Elevation Moniker에 의해 elevation Level이 정확히 설정된 COM Server에 접근할 수 있다. 이는 반드시 COM Server가 이미 running 상태여야만 한다.

ü 만일, UIAccess enabled COM Server가 이미 running 된 상태라면, DCOM이 interactive user로 설정되어 있을 때, standard users(Medium IL)나 Administrators(Admin IL) Client에서 접근이 가능하다.