macOS에서 프로세스 및 커널 확장을 보호하는 방법

안녕, 하브르! 오늘은 macOS에서 공격자의 공격으로부터 프로세스를 보호하는 방법에 대해 이야기하고 싶습니다. 예를 들어, 이는 바이러스 백신이나 백업 시스템에 유용합니다. 특히 macOS에는 프로세스를 "종료"하는 여러 가지 방법이 있기 때문입니다. 이에 대한 내용과 아래의 보호 방법을 읽어보세요.

프로세스를 "종료"하는 고전적인 방법

프로세스를 "종료"하는 잘 알려진 방법은 SIGKILL 신호를 프로세스에 보내는 것입니다. bash를 통해 표준 "kill -SIGKILL PID" 또는 "pkill -9 NAME"을 호출하여 종료할 수 있습니다. "kill" 명령은 UNIX 시대부터 알려져 왔으며 macOS뿐만 아니라 다른 UNIX 유사 시스템에서도 사용할 수 있습니다.

UNIX 계열 시스템과 마찬가지로 macOS에서는 SIGKILL 및 SIGSTOP 두 가지를 제외한 프로세스에 대한 모든 신호를 가로챌 수 있습니다. 이 기사에서는 주로 프로세스를 종료시키는 신호인 SIGKILL 신호에 중점을 둘 것입니다.

macOS 사양

macOS에서는 XNU 커널의 kill 시스템 호출이 psignal(SIGKILL,...) 함수를 호출합니다. 사용자 공간에서 psignal 함수가 호출할 수 있는 다른 사용자 작업이 무엇인지 살펴보겠습니다. 커널의 내부 메커니즘에서 psignal 함수에 대한 호출을 제거해 보겠습니다(비록 사소하지 않을 수 있지만 다른 기사에서 다루겠습니다 🙂 - 서명 확인, 메모리 오류, 종료/종료 처리, 파일 보호 위반 등) .

함수와 해당 시스템 호출로 검토를 시작하겠습니다. terminate_with_payload. 전통적인 종료 호출 외에도 macOS 운영 체제에만 적용되고 BSD에는 없는 대체 접근 방식이 있음을 알 수 있습니다. 두 시스템 호출의 작동 원리도 유사합니다. 이는 커널 함수 psignal에 대한 직접 호출입니다. 또한 프로세스를 종료하기 전에 "cansignal" 검사(프로세스가 다른 프로세스에 신호를 보낼 수 있는지 여부)가 수행됩니다. 예를 들어 시스템은 애플리케이션이 시스템 프로세스를 종료하는 것을 허용하지 않습니다.

static int
terminate_with_payload_internal(struct proc *cur_proc, int target_pid, uint32_t reason_namespace,
				uint64_t reason_code, user_addr_t payload, uint32_t payload_size,
				user_addr_t reason_string, uint64_t reason_flags)
{
...
	target_proc = proc_find(target_pid);
...
	if (!cansignal(cur_proc, cur_cred, target_proc, SIGKILL)) {
		proc_rele(target_proc);
		return EPERM;
	}
...
	if (target_pid == cur_proc->p_pid) {
		/*
		 * psignal_thread_with_reason() will pend a SIGKILL on the specified thread or
		 * return if the thread and/or task are already terminating. Either way, the
		 * current thread won't return to userspace.
		 */
		psignal_thread_with_reason(target_proc, current_thread(), SIGKILL, signal_reason);
	} else {
		psignal_with_reason(target_proc, SIGKILL, signal_reason);
	}
...
}

런칭

시스템 시작 시 데몬을 생성하고 수명을 제어하는 ​​표준 방법은 launchd입니다. 소스는 macOS 10.10까지의 이전 버전의 launchctl용이며 코드 예제는 설명 목적으로 제공됩니다. 최신 launchctl은 XPC를 통해 launchd 신호를 보내고, launchctl 로직이 XPC로 이동되었습니다.

애플리케이션이 정확히 어떻게 중지되는지 살펴보겠습니다. SIGTERM 신호를 보내기 전에 "proc_terminate" 시스템 호출을 사용하여 애플리케이션을 중지하려고 시도합니다.

<launchctl src/core.c>
...
	error = proc_terminate(j->p, &sig);
	if (error) {
		job_log(j, LOG_ERR | LOG_CONSOLE, "Could not terminate job: %d: %s", error, strerror(error));
		job_log(j, LOG_NOTICE | LOG_CONSOLE, "Using fallback option to terminate job...");
		error = kill2(j->p, SIGTERM);
		if (error) {
			job_log(j, LOG_ERR, "Could not signal job: %d: %s", error, strerror(error));
		} 
...
<>

내부적으로 proc_terminate는 이름에도 불구하고 SIGTERM을 사용하여 psignal뿐만 아니라 SIGKILL도 보낼 수 있습니다.

간접 살해 - 자원 제한

더 흥미로운 사례는 다른 시스템 호출에서 볼 수 있습니다. 프로세스_정책. 이 시스템 호출의 일반적인 용도는 파일 캐싱 활동으로 인해 시스템 속도가 크게 느려지지 않도록 인덱서가 CPU 시간 및 메모리 할당량을 제한하는 등 애플리케이션 리소스를 제한하는 것입니다. proc_apply_resource_actions 함수에서 볼 수 있듯이 애플리케이션이 리소스 제한에 도달하면 SIGKILL 신호가 프로세스로 전송됩니다.

이 시스템 호출은 잠재적으로 프로세스를 종료할 수 있지만 시스템은 시스템 호출을 호출하는 프로세스의 권한을 적절하게 확인하지 않았습니다. 실제로 확인 중 존재했다그러나 이 조건을 우회하려면 대체 플래그 PROC_POLICY_ACTION_SET을 사용하는 것으로 충분합니다.

따라서 애플리케이션의 CPU 사용 할당량을 "제한"(예: 1ns만 실행하도록 허용)하면 시스템의 모든 프로세스를 종료할 수 있습니다. 따라서 맬웨어는 바이러스 백신 프로세스를 포함하여 시스템의 모든 프로세스를 종료할 수 있습니다. 또한 흥미로운 점은 pid 1(launchctl)을 사용하여 프로세스를 종료할 때 발생하는 효과입니다. SIGKILL 신호를 처리하려고 할 때 커널 패닉이 발생합니다.

문제를 해결하는 방법?

프로세스가 종료되는 것을 방지하는 가장 간단한 방법은 시스템 호출 테이블의 함수 포인터를 바꾸는 것입니다. 불행하게도 이 방법은 여러 가지 이유로 사소하지 않습니다.

첫째, sysent의 메모리 위치를 제어하는 ​​기호는 XNU 커널 기호에만 해당되는 것이 아니라 커널 기호에서도 찾을 수 없습니다. 함수를 동적으로 분해하고 그 안의 포인터를 검색하는 등 경험적 검색 방법을 사용해야 합니다.

둘째, 테이블의 항목 구조는 커널이 컴파일된 플래그에 따라 달라집니다. CONFIG_REQUIRES_U32_MUNGING 플래그가 선언되면 구조의 크기가 변경되고 추가 필드가 추가됩니다. sy_arg_munge32. 커널이 어떤 플래그로 컴파일되었는지 확인하기 위해 추가 검사를 수행하거나 알려진 포인터에 대해 함수 포인터를 확인해야 합니다.

struct sysent {         /* system call table */
        sy_call_t       *sy_call;       /* implementing function */
#if CONFIG_REQUIRES_U32_MUNGING || (__arm__ && (__BIGGEST_ALIGNMENT__ > 4))
        sy_munge_t      *sy_arg_munge32; /* system call arguments munger for 32-bit process */
#endif
        int32_t         sy_return_type; /* system call return types */
        int16_t         sy_narg;        /* number of args */
        uint16_t        sy_arg_bytes;   /* Total size of arguments in bytes for
                                         * 32-bit system calls
                                         */
};

다행스럽게도 최신 버전의 macOS에서 Apple은 프로세스 작업을 위한 새로운 API를 제공합니다. Endpoint Security API를 사용하면 클라이언트가 다른 프로세스에 대한 많은 요청을 승인할 수 있습니다. 따라서 위에서 언급한 API를 사용하면 SIGKILL 신호를 포함하여 프로세스에 대한 모든 신호를 차단할 수 있습니다.

#include <bsm/libbsm.h>
#include <EndpointSecurity/EndpointSecurity.h>
#include <unistd.h>

int main(int argc, const char * argv[]) {
    es_client_t* cli = nullptr;
    {
        auto res = es_new_client(&cli, ^(es_client_t * client, const es_message_t * message) {
            switch (message->event_type) {
                case ES_EVENT_TYPE_AUTH_SIGNAL:
                {
                    auto& msg = message->event.signal;
                    auto target = msg.target;
                    auto& token = target->audit_token;
                    auto pid = audit_token_to_pid(token);
                    printf("signal '%d' sent to pid '%d'n", msg.sig, pid);
                    es_respond_auth_result(client, message, pid == getpid() ? ES_AUTH_RESULT_DENY : ES_AUTH_RESULT_ALLOW, false);
                }
                    break;
                default:
                    break;
            }
        });
    }

    {
        es_event_type_t evs[] = { ES_EVENT_TYPE_AUTH_SIGNAL };
        es_subscribe(cli, evs, sizeof(evs) / sizeof(*evs));
    }

    printf("%dn", getpid());
    sleep(60); // could be replaced with other waiting primitive

    es_unsubscribe_all(cli);
    es_delete_client(cli);

    return 0;
}

마찬가지로 신호 보호 방법(정책 proc_check_signal)을 제공하는 MAC 정책을 커널에 등록할 수 있지만 API는 공식적으로 지원되지 않습니다.

커널 확장 보호

시스템의 프로세스를 보호하는 것 외에도 커널 확장 자체(kext)를 보호하는 것도 필요합니다. macOS는 개발자가 IOKit 장치 드라이버를 쉽게 개발할 수 있는 프레임워크를 제공합니다. IOKit은 장치 작업을 위한 도구를 제공하는 것 외에도 C++ 클래스 인스턴스를 사용하여 드라이버를 스택하는 방법을 제공합니다. 사용자 공간의 애플리케이션은 클래스의 등록된 인스턴스를 "찾아" 커널-사용자 공간 관계를 설정할 수 있습니다.

시스템의 클래스 인스턴스 수를 감지하기 위해 ioclasscount 유틸리티가 있습니다.

my_kext_ioservice = 1
my_kext_iouserclient = 1

드라이버 스택에 등록하려는 모든 커널 확장은 IOService에서 상속되는 클래스(예: my_kext_ioservice)를 선언해야 합니다. 사용자 애플리케이션을 연결하면 IOUserClient에서 상속되는 클래스의 새 인스턴스가 생성됩니다(예: my_kext_iouserclient).

시스템에서 드라이버를 언로드하려고 할 때(kextunload 명령) 가상 함수 "boolitter(IOOptionBits 옵션)"이 호출됩니다. kextunload를 비활성화하기 위해 언로드를 시도할 때 종료 호출에서 false를 반환하는 것으로 충분합니다.

bool Kext::terminate(IOOptionBits options)
{

  if (!IsUnloadAllowed)
  {
    // Unload is not allowed, returning false
    return false;
  }

  return super::terminate(options);
}

IsUnloadAllowed 플래그는 로드 시 IOUserClient에 의해 설정될 수 있습니다. 다운로드 제한이 있는 경우 kextunload 명령은 다음 출력을 반환합니다.

admin@admins-Mac drivermanager % sudo kextunload ./test.kext
Password:
(kernel) Can't remove kext my.kext.test; services failed to terminate - 0xe00002c7.
Failed to unload my.kext.test - (iokit/common) unsupported function.

IOUserClient에 대해서도 유사한 보호를 수행해야 합니다. 클래스 인스턴스는 IOKitLib 사용자 공간 함수 "IOCatalogueTerminate(mach_port_t, uint32_t flag, io_name_t 설명);"을 사용하여 언로드될 수 있습니다. 사용자 공간 애플리케이션이 "죽을" 때까지, 즉 "clientDied" 함수가 호출되지 않을 때까지 "terminate" 명령을 호출하면 false를 반환할 수 있습니다.

파일 보호

파일을 보호하려면 파일에 대한 액세스를 제한할 수 있는 Kauth API를 사용하는 것으로 충분합니다. Apple은 범위 내 다양한 ​​이벤트에 대한 알림을 개발자에게 제공합니다. 우리에게는 KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA 및 KAUTH_VNODE_DELETE_CHILD 작업이 중요합니다. 파일에 대한 액세스를 제한하는 가장 쉬운 방법은 경로를 사용하는 것입니다. "vn_getpath" API를 사용하여 파일 경로를 가져오고 경로 접두어를 비교합니다. 파일 폴더 경로 이름 변경을 최적화하기 위해 시스템은 각 파일에 대한 액세스를 승인하지 않고 이름이 변경된 폴더 자체에만 액세스를 승인합니다. 상위 경로를 비교하고 이에 대해 KAUTH_VNODE_DELETE를 제한해야 합니다.

이 접근 방식의 단점은 접두사 수가 증가함에 따라 성능이 저하될 수 있다는 것입니다. 비교가 O(prefix*length)와 동일하지 않은지 확인하기 위해(여기서 prefix는 접두사의 수, length는 문자열의 길이) 접두사로 구축된 결정론적 유한 자동 장치(DFA)를 사용할 수 있습니다.

주어진 접두사 세트에 대해 DFA를 구성하는 방법을 고려해 보겠습니다. 각 접두사의 시작 부분에서 커서를 초기화합니다. 모든 커서가 동일한 문자를 가리키는 경우 각 커서를 한 문자씩 늘리고 동일한 줄의 길이가 XNUMX만큼 길어진다는 점을 기억하세요. 서로 다른 기호를 가진 두 개의 커서가 있는 경우 커서가 가리키는 기호에 따라 커서를 그룹으로 나누고 각 그룹에 대해 알고리즘을 반복합니다.

첫 번째 경우(커서 아래의 모든 문자가 동일함) 동일한 행을 따라 전환이 하나만 있는 DFA 상태를 얻습니다. 두 번째 경우에는 함수를 재귀적으로 호출하여 얻은 후속 상태로의 크기 256(문자 수 및 최대 그룹 수)의 전환 테이블을 얻습니다.

예를 살펴보겠습니다. 접두사 세트("/foo/bar/tmp/", "/var/db/foo/", "/foo/bar/aba/", "foo/bar/aac/")에 대해 다음을 얻을 수 있습니다. DFA. 그림에는 다른 상태로 이어지는 전환만 표시되며 다른 전환은 최종 상태가 아닙니다.

DKA 주를 통과할 때 3가지 경우가 있을 수 있습니다.

1. 최종 상태에 도달했습니다. 경로가 보호되고 KAUTH_VNODE_DELETE, KAUTH_VNODE_WRITE_DATA 및 KAUTH_VNODE_DELETE_CHILD 작업이 제한됩니다.
2. 최종 상태에 도달하지 않았지만 경로가 "종료되었습니다"(널 종결자에 도달함). 경로는 상위 경로이므로 KAUTH_VNODE_DELETE를 제한해야 합니다. vnode가 폴더인 경우 끝에 '/'를 추가해야 합니다. 그렇지 않으면 "/foor/bar/t" 파일로 제한될 수 있는데 이는 잘못된 것입니다.
3. 최종 상태에 도달하지 않았으며 경로가 끝나지 않았습니다. 이 접두사와 일치하는 접두사가 없으므로 제한 사항이 적용되지 않습니다.

결론

개발되는 보안 솔루션의 목표는 사용자와 데이터의 보안 수준을 높이는 것입니다. 한편으로 이 목표는 운영 체제 자체가 "약한" 취약점을 해결하는 Acronis 소프트웨어 제품의 개발을 통해 달성됩니다. 반면, OS 측면에서 개선할 수 있는 보안 측면의 강화를 소홀히 해서는 안 됩니다. 특히 이러한 취약점을 해결하면 제품으로서의 안정성이 높아지기 때문입니다. 이 취약점은 Apple 제품 보안 팀에 보고되었으며 macOS 10.14.5(https://support.apple.com/en-gb/HT210119)에서 수정되었습니다.

이 모든 작업은 유틸리티가 커널에 공식적으로 설치된 경우에만 수행할 수 있습니다. 즉, 외부 및 원치 않는 소프트웨어에 대한 허점이 없습니다. 그러나 보시다시피 바이러스 백신 및 백업 시스템과 같은 합법적인 프로그램을 보호하는 것에도 작업이 필요합니다. 그러나 이제 새로운 macOS용 Acronis 제품에는 시스템 언로드에 대한 추가 보호 기능이 제공됩니다.

출처 : habr.com