아시다시피 엔클레이브에서 실행되는 코드는 기능이 심각하게 제한됩니다. 시스템 호출을 할 수 없습니다. I/O 작업을 수행할 수 없습니다. 호스트 응용 프로그램 코드 세그먼트의 기본 주소를 모릅니다. 호스트 애플리케이션 코드를 jmp하거나 호출할 수 없습니다. 호스트 애플리케이션을 관리하는 주소 공간 구조(예: 매핑된 페이지 또는 해당 페이지에 어떤 종류의 데이터가 있는지)에 대해서는 전혀 모릅니다. 운영 체제에 호스트 응용 프로그램의 메모리 일부를 매핑하도록 요청할 수 없습니다(예: /proc/pid/maps를 통해). 쓰기 시도는 말할 것도 없고 호스트 애플리케이션의 임의 메모리 영역을 맹목적으로 읽으려는 순진한 시도는 조만간(전자일 가능성이 높음) 엔클레이브 프로그램의 강제 종료로 이어질 것입니다. 이는 엔클레이브에서 요청한 가상 주소 공간 영역에 호스트 애플리케이션이 액세스할 수 없을 때마다 발생합니다.

이러한 가혹한 현실을 감안할 때 바이러스 작성자가 SGX 엔클레이브를 사용하여 악의적인 목표를 달성할 수 있을까요?

– 주소를 읽을 수 있는지 확인하기 위한 해킹
– 쓰기 가능성을 위해 주소를 조사하는 해킹
– 제어 흐름을 리디렉션하는 해킹
– 위에 나열된 세 가지 해킹은 악당에게 무엇을 제공합니까?
– 악당이 이러한 해킹을 사용하여 란조와리를 만드는 방법

위의 모든 사항을 기반으로 엔클레이브는 호스트 애플리케이션에만 서비스를 제공할 수 있으며 엔클레이브는 악의적인 애플리케이션을 포함하여 자체 주도권을 행사할 수 없다는 것이 일반적으로 받아들여집니다. 이는 엔클레이브가 바이러스 작성자에게 실질적인 가치가 없음을 의미합니다. 이러한 성급한 가정은 SGX 보호가 비대칭인 이유 중 하나입니다. 호스트 애플리케이션 코드는 엔클레이브 메모리에 액세스할 수 없지만 엔클레이브 코드는 모든 호스트 애플리케이션 메모리 주소를 읽고 쓸 수 있습니다.

따라서 악성 엔클레이브 코드가 호스트 애플리케이션을 대신하여 임의의 시스템 호출을 만들고, 호스트 애플리케이션을 대신하여 임의의 코드를 실행하고, 호스트 애플리케이션의 메모리를 스캔하고 그 안에서 남용 가능한 ROP 체인을 찾을 수 있다면 호스트 애플리케이션을 완전히 제어할 수 있습니다. 스텔스 모드. 이는 사용자 파일을 훔치고 암호화할 수 있을 뿐만 아니라 사용자를 대신하여 행동할 수도 있습니다. 예를 들어, 그를 대신하여 피싱 이메일을 보내거나 DoS 공격을 수행합니다. 스택 카나리아 및 주소 삭제와 같은 가장 현대적인 보호 메커니즘도 두려워하지 않습니다.

공격자가 위에서 설명한 제한 사항을 극복하여 악의적인 목적인 ROP 공격을 위해 SGX를 활용하는 데 사용하는 몇 가지 해킹을 보여 드리겠습니다. 호스트 응용 프로그램 프로세스로 위장한 임의 코드를 실행하거나(맬웨어에서 자주 사용되는 프로세스 비우기와 유사) 이미 만들어진 악성 코드를 위장합니다(바이러스 백신 및 기타 방어 메커니즘의 박해로부터 악성 코드를 보호하기 위해).

주소를 읽을 수 있는지 확인하기 위한 해킹

엔클레이브는 호스트 애플리케이션이 액세스할 수 있는 가상 주소 공간의 범위를 알지 못하고, 액세스할 수 없는 주소를 읽으려고 시도할 때 엔클레이브가 강제로 종료되므로 공격자는 오류에 대한 방법을 찾는 작업에 직면하게 됩니다. 주소 공간을 관대하게 스캔합니다. 사용 가능한 가상 주소를 매핑하는 방법을 찾으세요. 악당은 인텔의 TSX 기술을 오용하여 이 문제를 해결합니다. TSX의 부작용 중 하나를 사용합니다. 메모리 액세스 기능이 TSX 트랜잭션에 배치되면 잘못된 주소 액세스로 인해 발생하는 예외가 운영 체제에 도달하지 않고 TSX에 의해 억제됩니다. 유효하지 않은 메모리 주소에 액세스하려고 시도하면 전체 엔클레이브 프로그램이 중단되지 않고 현재 트랜잭션만 중단됩니다. 저것. TSX를 사용하면 엔클레이브가 붕괴 위험 없이 트랜잭션 내에서 모든 주소에 안전하게 액세스할 수 있습니다.

면 지정된 주소를 사용할 수 있습니다 호스트 애플리케이션에서는 TSX 트랜잭션이 가장 자주 성공합니다. 드문 경우지만 인터럽트(예: 스케줄러 인터럽트), 캐시 제거 또는 여러 프로세스에 의한 메모리 위치 동시 수정과 같은 외부 영향으로 인해 실패할 수 있습니다. 이러한 드문 경우에 TSX는 실패가 일시적임을 나타내는 오류 코드를 반환합니다. 이러한 경우에는 트랜잭션을 다시 시작하기만 하면 됩니다.

면 지정된 주소를 사용할 수 없습니다 호스트 애플리케이션에서 TSX는 발생한 예외를 억제하고(OS에 알리지 않음) 트랜잭션을 중단합니다. 트랜잭션이 취소되었다는 사실에 대응할 수 있도록 오류 코드가 엔클레이브 코드로 반환됩니다. 이러한 오류 코드는 해당 주소를 호스트 응용 프로그램에서 사용할 수 없음을 나타냅니다.

엔클레이브 내부에서 TSX를 조작하는 것은 악당에게 좋은 기능입니다. 대부분의 하드웨어 성능 카운터는 엔클레이브 코드가 실행될 때 업데이트되지 않으므로 엔클레이브 내에서 실행되는 TSX 트랜잭션을 추적하는 것은 불가능합니다. 따라서 TSX의 악의적인 조작은 운영 체제에서 완전히 보이지 않습니다.

또한 위 해킹은 어떠한 시스템 호출에도 의존하지 않기 때문에 단순히 시스템 호출을 차단하는 것만으로는 탐지하거나 예방할 수 없습니다. 이는 일반적으로 계란 사냥과의 싸움에서 긍정적인 결과를 제공합니다.

악당은 위에서 설명한 해킹을 사용하여 호스트 애플리케이션 코드에서 ROP 체인을 형성하는 데 적합한 장치를 검색합니다. 동시에 그는 모든 주소를 조사할 필요가 없습니다. 가상 주소 공간의 각 페이지에서 하나의 주소를 조사하는 것으로 충분합니다. 16GB의 메모리를 모두 검색하는 데 약 45분이 소요됩니다(Intel i7-6700K의 경우). 결과적으로 악당은 ROP 체인을 구성하는 데 적합한 실행 가능한 페이지 목록을 받습니다.

쓰기 가능성을 위해 주소를 조사하는 해킹

ROP 공격의 엔클레이브 버전을 수행하려면 공격자는 호스트 애플리케이션의 쓰기 가능한 사용되지 않은 메모리 영역을 검색할 수 있어야 합니다. 공격자는 이러한 메모리 위치를 사용하여 가짜 스택 프레임을 주입하고 페이로드(셸코드)를 주입합니다. 결론은 악성 엔클레이브가 호스트 애플리케이션이 스스로 메모리를 할당하도록 요구할 수 없지만 대신 호스트 애플리케이션이 이미 할당한 메모리를 오용할 수 있다는 것입니다. 물론, 그가 영토를 무너뜨리지 않고 그러한 지역을 찾을 수 있다면 말이죠.

악당은 TSX의 또 다른 부작용을 이용하여 이 수색을 수행합니다. 먼저 앞의 경우와 마찬가지로 주소의 존재 여부를 조사한 후 이 주소에 해당하는 페이지에 쓰기 가능한지 여부를 확인합니다. 이를 위해 악당은 다음 해킹을 사용합니다. 그는 TSX 트랜잭션에 쓰기 기능을 배치하고 트랜잭션이 완료된 후 완료되기 전에 트랜잭션을 강제로 중단합니다(명시적 중단).

공격자는 TSX 트랜잭션의 반환 코드를 보고 쓰기 가능한지 여부를 파악합니다. 만약 그것이 "명백한 낙태"라면, 악당은 자신이 그것을 따랐다면 녹음이 성공했을 것이라는 것을 이해합니다. 페이지가 읽기 전용인 경우 트랜잭션은 "명시적 중단" 이외의 오류로 종료됩니다.

TSX의 이러한 조작에는 악당에게 좋은 또 다른 기능이 있습니다(하드웨어 성능 카운터를 통해 추적할 수 없다는 점 외에도). 모든 메모리 쓰기 명령은 트랜잭션이 성공한 경우에만 커밋되므로 트랜잭션을 강제로 완료하면 탐색된 메모리 셀이 변함없이 유지됩니다.

제어 흐름을 리디렉션하는 해킹

전통적인 ROP 공격과 달리 엔클레이브에서 ROP 공격을 수행할 때 공격자는 공격받은 프로그램의 버그(버퍼 오버플로 등)를 이용하지 않고 RIP 레지스터를 제어할 수 있습니다. 공격자는 스택에 저장된 RIP 레지스터의 값을 직접 덮어쓸 수 있습니다. 특히 이 레지스터의 값을 자체 ROP 체인으로 대체할 수 있습니다.

그러나 ROP 체인이 긴 경우 호스트 응용 프로그램 스택의 큰 부분을 덮어쓰면 데이터가 손상되고 예기치 않은 프로그램 동작이 발생할 수 있습니다. 은밀하게 자신의 공격을 수행하려는 악당은 이러한 상황에 만족하지 않는다. 따라서 자체적으로 가짜 임시 스택 프레임을 생성하고 그 안에 ROP 체인을 저장합니다. 가짜 스택 프레임은 쓰기 가능한 임의의 메모리 위치에 배치되어 실제 스택은 그대로 유지됩니다.

위에 나열된 세 가지 해킹은 악당에게 무엇을 제공합니까?

(1) 먼저, 악성 엔클레이브를 통해 주소를 읽을 수 있는지 확인하기 위해 해킹, – 호스트 애플리케이션에서 남용 가능한 ROP 가젯을 검색합니다.

(2) 그러면 쓰기 가능성을 위해 주소를 조사하기 위한 해킹, – 악성 엔클레이브는 페이로드 주입에 적합한 호스트 애플리케이션 메모리 영역을 식별합니다.

(3) 다음으로, 엔클레이브는 단계 (1)에서 발견된 가젯으로부터 ROP 체인을 생성하고 이 체인을 호스트 애플리케이션 스택에 주입합니다.

(4) 마지막으로 호스트 애플리케이션이 이전 단계에서 생성된 ROP 체인을 발견하면 호스트 애플리케이션의 권한과 시스템 호출 기능을 사용하여 악성 페이로드가 실행되기 시작합니다.

악당이 이러한 해킹을 사용하여 란조와리를 만드는 방법

호스트 애플리케이션이 ECALL 중 하나를 통해 제어권을 엔클레이브에 전송한 후(이 엔클레이브가 악성인지 의심하지 않고), 악성 엔클레이브는 코드를 주입하기 위해 호스트 애플리케이션의 메모리에서 여유 공간을 검색합니다(해당 셀 시퀀스를 여유 공간으로 사용). XNUMX으로 채워짐). 그럼 통해 주소를 읽을 수 있는지 확인하기 위해 해킹, – 엔클레이브는 호스트 애플리케이션에서 실행 가능한 페이지를 검색하고 현재 디렉터리에 "RANSOM"이라는 새 파일을 생성하는 ROP 체인을 생성하고(실제 공격에서는 엔클레이브가 기존 사용자 파일을 암호화함) 몸값 메시지를 표시합니다. 동시에 호스트 애플리케이션은 엔클레이브가 단순히 두 개의 숫자를 추가하고 있다고 순진하게 믿습니다. 코드에서는 어떻게 보일까요?

이해하기 쉽도록 정의를 통해 몇 가지 니모닉을 소개하겠습니다.

페이로드 실행 후 호스트 애플리케이션의 정상적인 작동을 복원하기 위해 RSP 및 RBP 레지스터의 원래 값을 저장합니다.

우리는 적합한 스택 프레임을 찾고 있습니다("제어 흐름 리디렉션을 위한 해킹" 섹션의 코드 참조).

적합한 ROP 가젯 찾기:

페이로드를 주입할 장소 찾기:

우리는 ROP 체인을 구축합니다:

악성 프로그램에 대응하기 위해 설계된 인텔의 SGX 기술을 악당이 악용하여 반대 목표를 달성하는 방법은 다음과 같습니다.

출처 : habr.com