오래된 프레임워크에 새로운 트릭 가르치기 Windows UI Automation의 위험성
편집 및 추가 설명: 트리샤 하워드(Tricia Howard)
핵심 요약
Akamai 보안 연구원 토머 펠레드(Tomer Peled)는 Microsoft의 UI Automation 프레임워크를 활용하고 남용하는 새로운 방법을 탐구했고, EDR(Endpoint Detection and Response)을 회피하는 공격 기법을 발견했습니다.
이 기법을 악용하기 위해서는 사용자가 UI Automation을 사용하는 프로그램을 실행하도록 설득해야 합니다. 이로 인해 명령이 은밀하게 실행되어 민감한 데이터를 수집하거나 브라우저를 피싱 웹사이트로 리디렉션하는 등의 일이 발생할 수 있습니다.
이 기법의 탐지는 EDR을 비롯한 여러 가지 측면에서 어려움이 있습니다. 이 기법에 대해 테스트한 모든 EDR 기술은 악성 활동을 발견하지 못했습니다.
이 기술은 운영 체제 XP 이상 버전을 사용하는 모든 Windows 엔드포인트에서 사용할 수 있습니다.
이 블로그 게시물에서는 UI Automation 프레임워크를 공격에 활용(악용)하는 방법에 대해 전체적으로 설명하고 각 남용 기법에 대한 개념 증명(PoC)을 제시합니다. 또한 탐지 및 방어 옵션도 제공합니다.
서론
글쓰기를 직업으로 하는 사람들은 받아쓰기 및 문법 검사 소프트웨어를 좋아합니다. 보안 리서치를 직업으로 하는 사람들은 무언가를 망가뜨리고 그것에 대해 글을 쓰는 것을 좋아합니다. 그래서 몇 달 동안 이런 글쓰기 보조 툴에 대한 광고를 본 후, Akamai는 이것들을 가지고 조금만 손을 봐서 어떤 것을 찾을 수 있을지 알아보기로 했습니다.
구체적으로 말하자면, Akamai는 애플리케이션이 다른 애플리케이션의 사용자 인터페이스(UI)를 원격으로 조작할 수 있는 방법을 이해하고 싶었습니다. Akamai가 발견한 것은 사람들이 여전히 XP를 실행한다는 사실을 알게 된 것만큼 충격적이었습니다. UI Automation 프레임워크라는 아주 오래된 프레임워크에 의해 처리된다는 것을 발견했습니다.
이 프레임워크는 장애가 있는 사람들이 컴퓨터를 더 쉽게 사용할 수 있도록 돕기 위해 Windows XP 시대에 고안되었습니다. 텍스트 확대, 텍스트 소리 내어 읽기, 심지어 클릭 시뮬레이션(일부 상황)과 같은 작업을 돕기 위해 높은 권한이 부여되었습니다. 이 UI Automation을 수행하려면 화면에 표시되는 거의 모든 UI 요소를 조작할 수 있는 권한이 필요합니다. 이는 의도된 목적을 고려할 때 당연한 일입니다. 이 기술은 할 수 있다는 지시를 받은 것만 수행합니다.
여기에서 바로 UI Automation을 악용할 경우 공격자가 미칠 수 있는 영향을 파악하기 위한 리서치 여정이 시작되었습니다.
공격자가 UI Automation을 악용해 데이터를 유출하고, 인터넷 브라우징을 조작하고, 명령을 실행하고, 심지어 WhatsApp이나 Slack과 같은 채팅 애플리케이션에서 메시지를 읽고 쓸 수도 있다는 사실을 발견했습니다. 그리고 이 모든 것이 Akamai가 테스트한 모든 EDR 벤더사에 의해 탐지되지 않았습니다.
이 블로그 게시물은 이 프레임워크의 작동 방식부터 그 기능을 악용하는 방법까지 이 프레임워크에 관해 알아야 할 모든 것을 알려줄 것입니다. 마지막으로 블루팀을 위한 탐지 및 방어 옵션에 관해 설명하겠습니다.
COM을 통한 UI Automation과의 상호 작용
UIA(UI Automation) 프레임워크는 다른 애플리케이션의 요소와 상호 작용하기 위해 IPC(Interprocess Communication) 메커니즘으로 COM(Component Object Model)을 활용합니다.
COM은 Microsoft가 다른 프로그램들이 작성된 언어나 컴파일된 언어에 관계없이서로 통신할 수 있도록 설계한 프레임워크입니다. 개발자는 COM 프레임워크를 사용하면 COM 오브젝트라고 불리는 구성요소를 만들 수 있습니다. 이러한 오브젝트들은 이름, UUID(Universally Unique Identifier), 그리고 로직 및 기타 설정 가능한 값을 포함하는 바이너리와 함께 Windows 엔드포인트에 등록됩니다.
UIA와 상호 작용하기 위해 사용자는 표에 나와 있는 것처럼 CUIAutomation 클래스 UUID와 UIAutomation 인터페이스 UUID를 사용해 ‘CoCreateInstance‘ 함수를 호출함으로써 COM 오브젝트를 생성합니다.
CUIAutomation UUID |
ff48dba4-60ef-4201-aa87-54103eef594e |
UIAutomation 인터페이스 UUID |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
COM 오브젝트를 생성하는 동안, 시스템은 레지스트리에 지정된 DLL을 로드합니다. 이 경우에는 ‘UIAutomationCore.dll‘입니다.
이 중 어떤 것이 익숙하게 들리십니까? 예리한 분은 이 모든 것이 MS-RPC에 대한 Akamai의 광범위한 검토와 유사하다는 것을 눈치챘을 것입니다. COM은 RPC를 기초로 사용하기 때문에 유사합니다.
UI Automation - Hello World
공격자들이 이 프레임워크를 어떻게 악용할 수 있는지에 대해 알아보기 전에 UIA와 일반적으로(C++로) 상호 작용하는 방법을 검토해 보는 것이 좋습니다. 이를 통해 이 프레임워크의 구축 과정에서 무엇이 잘못되었는지 파악할 수 있는 배경지식을 얻을 수 있습니다. GitHub에서 UIA와 상호 작용하는 방법을 검토할 수 있습니다.
UIA 오브젝트가 생성되면, 해당 DLL이 사용자의 애플리케이션과 UI 요소가 있는 다른 모든 프로세스에 로드됩니다.
원격 프로세스 UI 변경에 대한 이벤트 핸들러를 추가하기 전까지는 다른 어떤 일도 일어나지 않습니다. 아래의 예는 현재 사용자에게 열려 있는 툴팁의 변경 사항에 대한 핸들러를 설정하는 방법을 보여줍니다.
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
이 작업이 완료되면, UIA는 Akamai 애플리케이션과 통신하는 원격 프로세스에 ‘서버’를 열 것입니다(그림 1). 그들 사이에 전송되는 데이터는 원격 프로세스의 모든 UI 요소에 대한 정보입니다.
그림 1: UI 요소가 있는 모든 프로세스에 로드되는 UIA DLL
Microsoft의 문서에 따르면, 다음 핸들러 프로토타입은 UIA가 기대하는 표준 핸들러입니다.
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
핸들러 내부에서 ‘sender.get_CurrentName‘ 함수를 (열거나 다른 방법으로) 호출함으로써 UI의 전면에 표시된 정확한 애플리케이션을 식별할 수 있습니다. 이제 어떤 애플리케이션이 포커스 상태인지 정확히 파악할 수 있으므로, 그 애플리케이션에 대한 읽기/쓰기를 시도할 수 있습니다.
이를 위해서는 모든 요소( sender 요소의 하위 요소)를 반복하면서 UI 값을 읽거나 텍스트값을 변경하거나 호출 가능한 요소를 검색해 ‘Invoke’ 함수를 호출함으로써 읽기/쓰기를 원하는 요소를 찾아야 합니다(그림 2).
그림 2: 높은 수준에서 요소를 찾고 조작하는 프로세스
악성 활동을 위한 UI Automation 남용
지난 섹션에서 UIA를 남용하는 방법 에 대해 이야기했으니, 이번에는 남용을 통해 가능한 악성 활동에 대해 이야기해 보겠습니다. 이를 보여주기 위해 세 가지 예를 통해 설명하겠습니다.
- 메시지 읽기 및 쓰기
- 민감한 데이터 훔치기
- 명령 실행
메시지 읽기 및 쓰기
모든 메시징 애플리케이션에는 UIA를 사용해 접속할 수 있는 다양한 종류의 UI 요소가 포함된 GUI(Graphical User Interface)가 있습니다. 그림 3은 여러분에게 친숙하게 느껴질 수 있는 Slack의 GUI의 예입니다.
그림 3: Slack의 일반적인 모습
GUI 내에서 사용할 수 있는 작업은 대화 선택(화면 뒤에서 버튼으로 구축됨)부터 메시지 읽기(텍스트 블록)까지 다양하므로 상호 작용할 수 있는 항목이 많습니다.
공격자가 이러한 애플리케이션의 UI 창에 ‘연결’할 수 있게 되면, 원하는 대화에 대한 클릭을 (UI 버튼 요소를 통해) 시뮬레이션하고 입력할 수 있습니다. 거기에서 대화를 읽고 데이터를 빼내거나 메시지를 작성하는 UI 요소를 찾거나, TextArea 요소의 텍스트 값을 변경하고, 전송 버튼 클릭을 시뮬레이션할 수 있습니다.
물론, 이런 종류의 조작은 화면에도 반영되기 때문에 공격자의 입장에서 많은 부분이 우연에 맡겨지게 됩니다. 좀 더 은밀한 접근 방식은 현재 열려 있는 대화에서 읽기 전용으로 데이터를 수집하는 것입니다(그림 4).
그림 4: Slack에서 메시지 읽기
수동적인 접근 방식을 취하지 않고 은밀하게 유지하는 또 다른 옵션은 UIA의 캐싱 메커니즘을 사용하는 것입니다. 현재 화면에 표시되어 상호 작용할 수 있는 UI 요소 외에도 더 많은 요소가 미리 로드되어 캐시에 저장됩니다. 또한, 화면에 표시되지 않는 메시지를 읽거나 텍스트 상자를 설정하고 화면에 반영되지 않은 채로 메시지를 보내는 등 이러한 요소와 상호 작용할 수도 있습니다.
이 블로그 게시물이 공개되기 전에는 확인할 수 없었지만, 캐싱 메커니즘을 사용하면 컴퓨터가 잠겨 있는 동안에도 이러한 요소들과 상호 작용할 수 있습니다.따라서 사용자가 전혀 모르는 사람으로 남아 있을 수 있습니다.
민감한 데이터 훔치기
UIA를 사용(악용)하는 가장 파괴적인 방법 중 하나는 신용카드 정보를 도용하는 것입니다.
사용자가 온라인 상점에 접속하면, 공격자는 핸들러를 설정해 UI 요소의 변화를 프로그래밍 방식으로 감청할 수 있습니다. 일단 변화가 이루어지면(즉, 신용카드 정보가 입력되면), 공격자는 나중에 유출하기 위해 UI 요소에서 텍스트를 추출할 수 있습니다(그림 5).
그림 5: 브라우저에서 신용카드 정보 수집하기
명령 실행
브라우저에서 흔히 발생하는 또 다른 공격 경로는 피싱과 브라우저 리디렉션입니다.
공격자는 firefox/chrome/edge UI 창을 필터링해 검색창 UI 요소를 검색하고 원하는 값으로 설정해 클릭을 시뮬레이션할 수 있습니다 (그림 6). 좀 더 은밀하게 하려면, 현재 표시된 웹 페이지가 새로 고침 되거나 변경되는 순간을 기다려 다른 웹 사이트로 변경되는 것을 눈에 덜 띄게 할 수 있습니다.
이렇게 하면 공격자가 사용자가 제어하는 악성 사이트로 사용자를 리디렉션할 수 있습니다. 거기에서 브라우저 악용(예: BeEF(Browser Exploitation Framework) 사용), 드라이브 바이 공격, 피싱 또는 인증정보 수집을 위한 정상적인 사이트 위장 등 그 가능성은 사실상 무한합니다.
그림 6: 사용자를 BeEF로 리디렉션
UI Automation의 잠재적 영향
이전 섹션에서 논의한 공격은 수십 년 동안 다양한 형태로 존재해 왔으며, 대부분의 방어 툴은 이러한 공격을 탐지하고 대응하는 방법을 알고 있습니다.
그러나 위에서 논의한 모든 것은 UI Automation의 기능 으로 간주됩니다. 이는 애플리케이션의 의도된 목적에 따라 결정됩니다. 이러한 권한 수준은 애플리케이션을 사용하기 위해 반드시 존재해야 합니다. 이것이 UIA가 Defender를 우회할 수 있는 이유입니다. 즉 애플리케이션은 평소와 다른 것을 발견하지 못합니다. 실제로, Akamai가 테스트한 어떤 EDR도 이러한 행동을 악성적인 것으로 간주하지 못했습니다. 아마도 같은 이유 때문일 것입니다. 어떤 것이 버그가 아닌 기능으로 간주되면, 머신의 로직은 그 기능을 따르게 됩니다.
이 때문에 이 프레임워크는 공격자에게 매우 유리한 것으로 간주되며, 따라서 이 공격 기법을 다루기 위해 인식을 더 높여야 합니다.
추가 리서치
DCOM을 통한 UIA
DCOM(Distributed COM)은 머신 간에 COM 오브젝트를 원격으로 호출하는 방법입니다. 이론적으로 DCOM을 통해 UIA에 원격으로 접속할 수 있어야 합니다. 그러면 지금까지 논의한 모든 공격이 피싱/로컬 접속 요구 사항 없이 실행될 수 있습니다.
분석 과정에서, UIA의 COM 오브젝트가 기본적으로 DCOM을 허용하도록 설정되어 있지 않다는 사실을 알게 되었습니다. 이로 인해 설정 오류를 제외하고는 공격의 가능성이 크게 줄어듭니다.
UIA 자체는 DCOM을 통해 사용할 수 없지만 이와 관련된UIAutomationCrossBitnessHook COM/DCOM 오브젝트를 발견했습니다. 이 오브젝트는 원격 활성화 및 실행을 위해 권한이 필요하지 않습니다.
DLL을 역으로 돌려보니 인터페이스에 UI 관리자를 설정하는 기능과 설정 해제하는 기능, 두 가지 기능이 포함되어 있었습니다. 다른 원격 기능은 없는 것 같아서, 이것을 사용해 데이터를 읽거나 쓰는 것은 불가능했지만, 향후 리서치에 좋은 대상이 될 수 있을 것 같습니다.
UIA 네임드 파이프
이 글의 앞부분에서 UIA가 원격 프로세스에서 ‘서버’를 연다고 언급했습니다. 이 서버와 클라이언트는 배후에서 네임드 파이프를 사용해 구축됩니다. 명명 규칙은 UIA_PIPE라는 상수 문자열 뒤에 프로세스 ID와 다른 식별자가 붙는 것으로 구성됩니다(그림 7).
그림 7: 공격자 애플리케이션 내부의 UI 네임드 파이프
이제부터가 무서운 부분입니다. 네임드 파이프는 원격 연결을 수용할 수 있습니다. 이 경우 매우 위험합니다. 공격자가 네트워크를 통해 UI 요소를 조작할 수 있기 때문입니다. 그러나 원격 서버에서 연결을 시도했을 때 ACCESS_DENIED 오류가 발생했습니다.
이는 Microsoft가 네임드 파이프를 생성할 때 PIPE_REJECT_REMOTE_CLIENTS 플래그를 설정했기 때문입니다. 이것은 해당 파이프를 통해 원격으로 UIA에 접속할 수 없다는 것을 의미하지만, 여전히 로컬에서는 사용할 수 있습니다. (프로세스 ID나 식별자를 추측하지 않고) 해당 파이프를 열거하고 접속하는 것이 가능하기 때문에 특권 상승 공격이나 가장 공격의 길을 열어줄 수 있습니다. 하지만 이 내용은 이번 분석의 범위에 속하지 않습니다.
탐지/방어
Microsoft는 이 프레임워크가 더 높은 권한을 가진 애플리케이션과 상호 작용해서는 안 된다는 것을 인식 하고 있습니다. 따라서 기본적으로 UI Automation 프레임워크를 사용하는 애플리케이션은 중간 신뢰 수준에서 실행되며 더 높은 권한을 가진 프로세스에 접속할 수 없습니다. 이 문제는 requestedExecutionLevel.uiAccess 키가 true로 설정된 매니페스트 파일이 있는 서명된 애플리케이션을 사용해 우회할 수 있습니다.
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
탐지 측면에서는 관리자가 UIAutomationCore.dll의 사용을 모니터링할 수 있습니다. 이전에 알려지지 않은 프로세스에 로드된 경우, 우려할 만한 정당한 이유가 발생합니다.
마찬가지로, 네트워크 관리자는 UIA가 엔드포인트에서 연 네임드 파이프를 모니터링할 수 있습니다. 이는 UIA 사용의 또 다른 지표가 될 수 있으며, 다음 osquery를 사용해 모니터링할 수 있습니다.
SELECT DISTINCT pid, name, proc.path FROM process_memory_map AS pmm JOIN processes AS proc USING(pid) WHERE pmm.path LIKE '%uiautomationcore.dll'
로딩 프로세스 - UIAutomationCore.dll
WITH uia_pipes AS (SELECT name AS pipe_name, SUBSTR(name, 10, INSTR(SUBSTR(name, 10), '_')-1) AS pid FROM pipes WHERE name LIKE 'UIA_PIPE_%' ) SELECT DISTINCT pid, name AS process_name, path, pipe_name FROM uia_pipes JOIN processes USING(pid)
UI Automation 네임드 파이프를 연 프로세스
결론
이 분석은 선의를 위해 만들어진 기술이 악성 목적으로 이용될 수 있다는 것을 보여주는 안타까운 사례입니다. UI Automation 프레임워크는 장애가 있는 사람들에게 도움이 될 수 있지만, 공격자가 스파이웨어를 모방할 수 있는 기회도 제공합니다.
UIA를 악용하는 것이 다른 공격보다 더 어려울 수 있지만, EDR이 이를 탐지할 수 없다는 사실은 UIA를 매우 매력적인 공격 표면으로 만들 수 있습니다. Microsoft는 공격자에 대한 매력을 줄이기 위해 UIA에 몇 가지 제한을 두었지만, 공격자는 적절한 기술을 통해 여전히 이를 이용할 수 있습니다. 이 블로그 게시물을 통해 이 공격 기법에 대한 인식을 높이고 블루팀이 이러한 공격 기법으로부터 스스로를 방어하는 데 도움이 되기를 바랍니다.
