tezeb/accflyAccfly 카메라 취약점 공개: CVE-2020-25782, CVE-2020-25783, CVE-2020-25784, CVE-2020-25785.
2020년 초, 이전 직장에서 내부 pwn2own 스타일 이벤트에 참여할 기회가 있었습니다. 여러 대상이 있었지만, 저는 Accfly 무선 보안 카메라에 가장 관심이 있었습니다. 안타깝게도 실제 이벤트를 위해 연구를 마치지는 못했지만, 이 기기에 다른 시도가 없었기 때문에 연구를 계속 진행했습니다.
연구의 주요 초점은 원격 코드 실행(RCE)으로 이어질 수 있는 취약점이었습니다. 이 유형의 취약점은 공격자가 기기를 완전히 제어할 수 있게 해주며, 비디오 카메라의 경우 소유자의 프라이버시가 완전히 침해될 수 있습니다. 안타깝게도 기기 펌웨어에는 그러한 문제가 많이 발견되었습니다.
첫째, 기기는 어떠한 인증도 제공하지 않습니다. 결과적으로 기기에 연결할 수 있는 공격자는 자유롭게 접근하여 재구성할 수 있습니다. 가장 간단한 형태로는 기기를 계속해서 재시작하여 정당한 사용자가 전혀 사용할 수 없게 만들 수 있습니다. 이 공격의 범위는 다소 제한적입니다. 기기는 일반적으로 NAT 뒤에 있는 WiFi 네트워크 내에서 사용하도록 설계되어 인터넷에서 직접 접근할 수 없기 때문입니다. 그러나 기기와 소유자의 스마트폰 앱 간의 암호화 부재와 통신 프록시로 사용되는 벤더 서버는 WiFi NAT 제한을 뚫을 수 있는 MitM 또는 DNS 조작 공격의 기회를 제공합니다.
또한 애플리케이션은 통신에 독점 바이너리 프로토콜을 사용합니다. C와 C++이 혼합되어 구현되었으며 안전하지 않은 문자열 처리 함수로 가득 차 있는 것으로 발견되었습니다. 주 실행 파일에는 엄청난 양의 사용되지 않는 코드가 포함되어 있어, 다른 기기에서도 재사용되고 있음을 시사합니다. 이는 유지보수를 어렵게 만들고 공격 표면을 증가시킵니다. 애플리케이션은 많은 일반적인 익스플로잇 기법으로부터 보호해 줄 현대적인 보안 메커니즘을 전혀 활성화하지 않습니다. 게다가 사용자 권한을 제한하지도 않으며, 최고 권한인 root로 실행됩니다.
이 연구의 결과로 다음과 같은 네 가지 취약점이 문서화되었습니다.
CNetClientManage::ServerIP_Proto_Set 함수에서 발생하는 인증 없는 스택 기반 버퍼 오버플로우CNetClientTalk::OprMsg 함수에서 발생하는 인증 없는 힙 기반 버퍼 오버플로우CNetClientGuard::SubOprMsg 함수에서 발생하는 인증 없는 스택 기반 버퍼 오버플로우CFtpProtocol::FtpLogin 함수에서 발생하는 인증 없는 스택 기반 버퍼 오버플로우그중 세 가지에 대해 RCE 익스플로잇이 개발되어 공격자가 기기를 완전히 제어할 수 있습니다. 그러나 취약점 보고 시도에 대한 벤더의 응답이 없었기 때문에, 이 저장소에는 애플리케이션을 충돌시키는 수준의 제한된 PoC 익스플로잇만 포함되어 있습니다.
문제는 소프트웨어 버전 V3.10.73에서 발견되었으며, 본 게시 시점(2021년 1월 26일)에 제공된 최신 버전인 소프트웨어 버전 V4.15.77에서 확인되었습니다.
질문이 있으시면 이메일(git 커밋 참조) 또는 Github 이슈를 통해 주저하지 말고 연락해 주세요. 해킹해 볼 만한 흥미로운 IoT 기기가 있거나, **보안 연구원(Security Researcher)**을 찾고 있거나, 그냥 인사하고 싶다면 언제든 연락 주세요. 커피 한 잔 사주세요!
대상 기기는 함께 제공되는 모바일 앱으로 제어되는 비디오 카메라 기기입니다. 제 분석은 카메라의 네트워크 트래픽에서 시작하여 카메라 펌웨어로 이어졌습니다. 모든 통신에는 맞춤형 바이너리 프로토콜이 사용됩니다. 명령은 동일한 네트워크에 있을 때 모바일 기기로 직접 전송되거나 기기 제조업체 서버를 통과합니다. 카메라 소프트웨어 자체는 여러 포트(TCP(23456,34567) 및 UDP(34568, 34569))에서 수신 대기합니다. 네트워크 트래픽에는 암호화나 인증이 없으므로, 카메라가 네트워크에 노출되면 MitM 공격이나 직접 접근이 가능합니다. 비디오 스트림에도 인증 없이 접근할 수 있을 것으로 보이지만, 이를 시도할 만큼 독점 프로토콜을 충분히 리버스 엔지니어링하지는 못했습니다.
간단한 통신 개요 후, 다음 단계는 기기 펌웨어에 접근하는 것이었습니다. 첫 번째 시도는 기기 업데이트 프로세스를 하이재킹하여 펌웨어를 직접 다운로드하는 것이었지만, 네트워크 트래픽에서는 그러한 일이 발생하지 않았습니다. 플래시 메모리에서 펌웨어를 추출해 준 동료의 큰 도움이 없었다면 이 단계에서 막혔을 것입니다. 덕분에 이 연구를 계속할 수 있었습니다.
펌웨어는 MIPS 리틀엔디언 CPU에서 Linux를 실행하고 있는 것으로 확인되었습니다. 흥미로운 프로세스는 Alloca라는 단 하나뿐인데, 비디오 캡처를 담당하며 모든 네트워크 통신도 처리합니다. 애플리케이션은 C++로 작성되었으며 이 기기에서는 사용되지 않는 많은 코드를 포함하고 있습니다. 이는 동일한 소프트웨어가 다른 기기에서도 사용된다는 것을 나타냅니다.
이 문제는 가장 나중에 발견되었지만, 대부분의 다른 취약점이 안전하지 않은 C 언어 문자열 함수 사용에서 비롯되므로 실제 익스플로잇에 매우 중요합니다. 유사한 시나리오에서 성공적인 코드 실행에 사용할 수 있는 여러 기법이 존재하지만, 애플리케이션은 그러한 기법을 대부분 무용지물로 만드는 방식으로 제작되었습니다. 주요 문제는 Alloca의 코드와 데이터가 낮은 주소( < 0x01000000)에 정적으로 할당된다는 것입니다. 따라서 기존 코드를 재사용하려는 시도(예: ROP 등)는 프로그램 메모리에 주소를 쓸 수 있어야 하므로 유용하지 않습니다. C 언어 문자열은 \x00을 종료 문자로 사용하고 문자열 함수는 첫 번째 NULL 바이트에서 처리를 중단하므로, NULL 바이트를 하나 이상 사용할 수 없습니다. 게다가 스택 위치가 무작위화되어 있고 애플리케이션이 다중 스레드를 많이 사용하므로 다른 기법의 신뢰성이 훨씬 낮아집니다.
이 취약점은 여러 스레드 간의 데이터 공유와 안전하지 않은 strcpy 사용의 결과입니다. 이 특정 문제를 오랫동안 분석했지만, 이 게시 불과 몇 주 전까지는 이를 데이터 누출 벡터로 사용할 기회를 발견하지 못했습니다. 흥미롭게도 C++ 객체의 힙 주소 누출 덕분에 이 취약점은 원격 코드 실행도 가능하게 합니다. 그러나 이 공격은 이 보고서에 포함되지 않습니다.
Alloca 애플리케이션은 FTP를 통해 자체 업데이트할 수 있습니다. 이 작업은 필요한 사용자 이름, 비밀번호 및 파일 이름을 제공하는 서버에 의해 요청될 수 있습니다. 업데이트를 시작하는 함수는 다음과 같습니다:
strcpy에 대한 세 번의 호출은 명백히 안전하지 않으며, ftpUpgrade 객체가 동적으로 할당되므로 힙 오버플로우로 이어집니다. 안타깝게도 복사가 수행되는 순서와 ftpUpgrade 구조체 레이아웃 때문에 실제로 데이터를 누출할 스레드를 시작하는 것은 불가능합니다. 수신 패킷을 자세히 살펴보면 다음과 같은 구조를 확인할 수 있습니다:
struct ftp_upgrade_pkt {
struct pktHeader;
char username[16];
char password[16];
char filename[128];
}
반면 ftpUpgrade 객체는 다음과 같은 형태입니다:
struct CNetClientFtpUpgrade {
// ... something here
char filename[128];
char unknown[6];
char username[16];
char password[16];
CFtpDownlad *;
CNetClientConnect*;
int something[5];
bool threadRunning;
// ... and more
}
누출은 내부 포인터(CFtpDownload*, CNetClientConnect*) 중 하나가 애플리케이션에 의해 채워진 후에 발생할 수 있습니다. 또한 사용자 이름과 비밀번호는 해당 포인터가 누출 가능한 위치에 저장되기 전에 새로 생성된 객체로 (이번에는 안전하게) 다시 복사되므로, 누출은 filename에서만 발생할 수 있습니다. 결과적으로 파일 이름은 매우 길어야 하지만, strcpy의 순서와 종료 동작으로 인해 충분히 긴 파일 이름은 더 긴 사용자 이름과 비밀번호를 초래하여 결과적으로 threadRunning을 덮어쓰고 스레드가 전혀 시작되지 않게 됩니다.
이 코드가 단일 스레드였다면 할 수 있는 일이 많지 않았을 것입니다. 그러나 새로운 FtpDownload 스레드가 생성되어 DownloadFile 함수를 실행하면서 수신 패킷을 처리하는 스레드와 CNetClientFtpUpgrade 객체를 공유하므로 흥미로운 기회를 제공합니다. 외부에서 제어할 수 있는 여러 IO 작업(DNS 요청, FTP 연결 처리)이 있을 뿐만 아니라 FTP에 최대 10번 연결을 시도합니다(이것은 DownloadFile의 호출자에서 수행됩니다). 이를 통해 FtpDownload 스레드의 실행을 (IO 작업에서 차단하여) 제어할 수 있으며, 따라서 메시지 처리 스레드가 다른 요청을 처리할 시간을 확보할 수 있습니다.
요컨대 여러 업데이트 요청을 보내기만 하면 이미 실행 중인 FtpDownload 스레드가 사용하는 filename(및 기타 매개변수)을 변경하고 누출된 힙 주소를 받을 수 있습니다. 보너스로, FtpSize 함수(초록색으로 표시)는 누출된 주소가 참조하는 객체 내부의 버퍼를 사용하여 filename 자체를 저장하므로, 1단계 셸코드의 간단한 주입이 가능합니다. 여기서 유일한 제한은 strcpy 사용으로 인한 길이와 NULL 바이트 부재입니다. 기기에서 힙 주소만 누출하는 샘플 PoC가 제공됩니다.
CNetClientManage::ServerIP_Proto_Set 함수의 인증 없는 스택 기반 버퍼 오버플로우
수신 트래픽 처리에 인증이 전혀 없다는 점이 패킷 핸들러를 찾도록 이끌었습니다. 흥미로운 함수 중 하나는 ServerIP_Proto_Set입니다. DNS 확인을 위한 정적 오버라이드를 생성하는 데 사용되는 것으로 보입니다. 이 방법으로 트래픽을 리디렉션하는 방법은 찾지 못했지만, 여기에 또 다른 버퍼 오버플로우가 있습니다(주황색으로 표시).
패킷에서 직접 읽은 데이터는 sprintf 함수 내부에서 사용됩니다. 이 경우 패킷의 데이터가 16바이트 버퍼에 맞을 것이라고 가정하지만, 단순한 %s 형식을 사용하면 NULL을 포함하지 않는 한 원하는 만큼 많은 바이트를 쓸 수 있습니다.
이 취약점은 다소 제한적입니다. 스택에 많은 데이터를 쓸 수 있어 NOP-슬레드를 사용할 수는 있지만, NULL 바이트를 쓸 수는 없습니다. 단일 NULL 바이트를 쓰려고 해도 sprintf 함수 형식이 그 앞에 \n을 붙이기 때문에 실패합니다. 또 다른 장애물은 버퍼 뒤에 저장된 CMutex 객체입니다. 오버플로우 시도는 이 뮤텍스를 올바른 값(또는 적어도 CGuard 소멸자를 만족시키는 값 - 빨간색으로 표시)으로 채워야 합니다. 소멸자가 전달된 변수를 두 번 역참조한 다음 그 값을 pthread_mutex_unlock 호출에 사용하기 때문에 이것은 문제가 됩니다. 몇 가지 테스트 끝에 NULL로 채워진 버퍼가 pthread_mutex_unlock에서 올바르게 반환되기에 충분하다는 것을 발견했지만, 여전히 적절한 메모리 주소로 역참조되어야 했습니다.
정보 누출이 구해줍니다. 공격은 NULL 바이트를 포함하지 않는 힙 주소가 필요하므로 다소 복잡합니다. 다행히 기기가 원격 무인증 재시작 기능을 제공하므로 검색이 더 쉬워집니다. 매번 다른 힙 주소 공간 할당을 제공합니다. 따라서 기기를 재설정하고 적절한 주소가 발견될 때까지 주소를 누출하면 됩니다. 편리하게도 이를 통해 짧은 1단계 셸코드를 저장할 수도 있습니다. 뮤텍스 문제(포인터에 대한 포인터가 필요함)를 극복해야 하므로, 이번에는 이전에 누출된 주소를 파일 이름으로 전달하여 또 다른 주소를 누출합니다. 다음 다이어그램은 예상되는 메모리 레이아웃을 보여줍니다:
모든 것이 계획대로 진행되면 두 번째 주소를 뮤텍스로, 첫 번째 주소를 반환 주소로 전달할 수 있습니다. 그러나 PoC에서처럼 단순히 애플리케이션을 충돌시키는 데는 필요하지 않습니다.
CNetClientTalk::OprMsg 함수의 인증 없는 힙 기반 버퍼 오버플로우
기기는 양방향 음성 통신을 지원해야 합니다. 또 다른 수신 패킷 핸들러는 오디오를 수신하고 재생하는 역할을 하는 것으로 보입니다. audio_pkt_hdr 네트워크 패킷은 다음 구조로 설명됩니다:
struct audio_pkt_hdr {
struct pktHeader field_0x0;
int field_0x14
int field_0x18
int field_0x1c
char audioBuff[0x140];
}
pktHeader 구조체 필드 중 하나는 (네트워크를 통해 전송되는) 패킷의 길이입니다. 이 필드는 송신자가 자유롭게 설정할 수 있습니다. 취약한 부분은 수신 패킷 헤더에 제공된 신뢰할 수 없는 길이 값을 사용하여 수신 패킷에서 직접 데이터를 복사한다는 것입니다.