이 저장소에는 2020년 8월에 수행한 Tiandy의 IPC/NVR 펌웨어 연구 결과가 포함되어 있습니다. 관리자 비밀번호를 원격으로 복구하고 장치에 대한 루트 액세스 권한을 획득하는 데 사용할 수 있는 두 가지 취약점을 발견했습니다.
이 저장소에는 2020년 8월에 수행한 Tiandy의 IPC/NVR 펌웨어(이 장치는 OMNY라는 이름으로도 판매됨) 연구 결과가 포함되어 있습니다. 이 "연구"는 완전하지 않지만, 관리자 비밀번호를 원격으로 복구하고, telnet을 활성화하고, root 비밀번호를 변경하는 여러 방법을 발견했습니다.
정확히 어떤 버전이 영향을 받는지 말하기는 어렵습니다. 최신 버전만 다운로드할 수 있기 때문입니다. 다음의 다운로드 가능한 모든 버전이 영향을 받습니다:
DVRS_V9.12.7.20200422
DVRS_V11.7.4.20200721
NVSS_V13.6.1.20200723
NVSS_V22.1.0.20200722
장치마다 서로 다른 브랜치가 있을 뿐만 아니라, 웹 API와 같은 일부 구성 요소는 별도로 버전 관리되고 업그레이드됩니다. 웹 API에서 펌웨어 버전 번호와 관계없이 2019년 중반 이후 출시된 버전에서만 동작하는 인증 우회를 발견했습니다. 영향을 받는 버전에 대해 더 아는 것이 있으면 도움을 주시면 감사하겠습니다.
저는 여기서 전체 공개를 하지만, 이는 합리적입니다. 벤더 패치(그들이 응답이 없어 가능성은 낮지만)가 문제를 사라지게 하지는 못할 것입니다. 특히 온라인 장치 중 최신 펌웨어를 실행하는 장치는 거의 없기 때문입니다. 실제 취약점은 그러한 장치들이 인터넷에 노출되어 있다는 것입니다. 그리고 이것은 Tiandy가 아니라 최종 사용자가 해결해야 할 문제입니다.
보너스로, 펌웨어 언패커와 RTSP/RTMP를 통해 스트림에 접근하는 방법에 대한 정보도 포함했습니다(매뉴얼에서 찾는 것은 행운이 필요할 겁니다).
먼저 스크립트를 소개합니다:
그런 다음 이 스크립트가 무엇을 하는지, 왜 그런지 간략히 설명합니다. 코드를 반복하지는 않지만, 코드를 이해할 수 있을 만큼의 충분한 맥락을 설명하려고 합니다:
마지막으로, 다소 기술적인 내용입니다:
Python 3과 PyCrypto가 필요합니다.
먼저 recover.py를 시도하세요. 이 방법은 포트 3001에 접근할 수 있어야 합니다:
python3 recover.py [HOST]
모든 것이 잘 진행되면 관리자 자격 증명이 출력됩니다.
해당 포트에 접근할 수 없다면 웹 포트가 동작할 수도 있습니다. 다음 URL이 필요합니다:
python3 cgi_recover.py http://123.45.67.89
python3 cgi_recover.py https://123.45.67.89
위 방법이 모두 동작하지 않으면 telnet이 활성화되어 있는지 확인하세요. 활성화되어 있다면 다음 해시를 크랙하여 장치를 직접 루팅할 수 있습니다:
support:$1$$AErA9BQgLjrxTJB1748k71:501:501:Linux User,,,:/home/support:/bin/sh
(실제로 크랙하면 꼭 PR을 열어 주세요 :D)
구형 V7 NVR 펌웨어에서는 명령을 직접 실행할 수 있습니다:
python3 ftpupdate.py [host] [adminpass] '[cmd]'
하지만 출력이 없습니다. 더 쉽게 하기 위해 다음 축약형을 포함했습니다:
python3 ftpupdate.py [host] [adminpass] adduser [username] [password]
이 명령은 uid 0을 가진 사용자를 추가합니다.
먼저 다음 명령으로 telnet을 활성화합니다:
python3 telnet.py [host] [adminpw]
또는 최신 장치의 경우:
python3 cgi_recover.py [host] telnet
그런 다음 /etc/passwd를 덮어쓸 수 있습니다(작동 방식을 알고 있다고 가정합니다). 먼저 filetransport.py를 시도하세요(NVR용):
python3 filetransport.py [host] [adminpass] put /etc/passwd <[source_file]
이 명령은 피드백이 없으므로 로그인을 시도하여 테스트해야 합니다...
filetransport.py가 동작하지 않는 IPC 모델의 경우 upgrade_rw.py를 시도하세요:
python3 upgrade_rw.py [url] [adminpass] /etc/passwd <[source_file]
(이것도 피드백이 없습니다)
마지막으로, 더 최신 장치의 경우 웹 API를 통해서도 가능합니다:
python3 cgi_recover.py [url] write /etc/passwd <[source_file]
위 방법이 모두 동작하지 않았다면(로그인이 가능한지 확인), /etc/passwd 대신 /config/etc/passwd를 덮어쓰며 모든 방법을 다시 시도하세요. 일부 펌웨어 버전에서는 /etc/passwd가 해당 파일에 대한 심볼릭 링크입니다. 마지막으로 /tdfs/etc/passwd 덮어쓰기도 시도할 수 있지만, 그 후에는 장치 재부팅이 필요할 수 있으므로 재부팅하려면 다음 명령을 사용하세요:
python3 reboot.py [host] [adminpass]
구형 V7(IPC 및 NVR) 펌웨어는 영향을 받지 않는 것으로 보이지만, 관리자 비밀번호가 있다면 NVR의 경우 인증된 RCE(ftpupdate.py)를 사용할 수 있고, IPC의 경우 upgrade-rw.py 스크립트를 사용하여 /etc/passwd를 덮어쓸 수 있습니다.
NVR 펌웨어의 이후 버전(V9 및 V11)에는 기본 계정이 있으며, "수동적" 권한 상승과 결합하면 관리자 비밀번호를 복구할 수 있습니다. 그런 다음 filetransport.py를 사용하여 /etc/passwd를 덮어쓸 수 있습니다.
IPC 펌웨어에는 기본 계정이 없지만 또 다른 복구 방법인 PSW 방식이 나타납니다. 이는 보안이 전혀 없는 비밀번호 복구 메커니즘입니다. V9 이후 모든 다운로드 가능한 펌웨어 버전에 존재합니다. filetransport.py는 NVR에서만 동작하지만, upgrade_rw.py는 업그레이드 메커니즘을 사용하여 IPC에서 동일한 목적을 달성하므로 여전히 루트 권한을 얻을 수 있습니다.
2019 펌웨어는 또 다른 공격 벡터, 즉 웹 API를 사용한 인증 우회를 도입했습니다. 인증 없이 구성 파일을 내보내면 비밀번호를 복구하고 임의의 파일을 덮어쓸 업그레이드 패키지를 준비할 수 있습니다.
취약점에 대해 말하자면, 총 4가지가 있습니다:
참고로 "클라우드" 기능, 즉 장치를 열거하여 인터넷에 노출되지 않은 장치에 연결할 수 있는지 여부(Xiongmai 장치의 경우처럼)는 조사하지 않았습니다.
구형 버전에서는 telnet이 기본적으로 활성화되어 있으며 /etc/passwd 파일에서 다음을 확인할 수 있습니다:
support:$1$$AErA9BQgLjrxTJB1748k71:501:501:Linux User,,,:/home/support:/bin/sh
(root 비밀번호는 동적으로 업데이트되며, 저도 이 해시를 크랙하지 못했으므로 풀 리퀘스트는 언제나 환영입니다 :D)
support 사용자(실제로 모든 펌웨어 버전에 존재함)는 권한이 없어 보일 수 있지만, 물론 이 사용자는 Admin 비밀번호를 읽고 /etc/init.d의 world-writable init 스크립트를 덮어쓰거나 새로 만들 수 있는 충분한 권한을 가지고 있습니다 :)
개념적으로 이 방법은 정말 간단합니다. 로그인 패킷을 보내고 응답을 읽기만 하면 됩니다. 그게 전부입니다. "로그인 성공" 응답에는 우리의 권한과 관계없이 모든 사용자의 자격 증명이 포함되어 있기 때문입니다. V7에서도 마찬가지였지만, 실제로 이 방법이 유용해진 것은 NVR 펌웨어에 기본 계정이 도입된 이후입니다. 제거할 수 없는 "Default" 계정에는 원격 권한이 없으므로 그 계정으로는 아무것도 할 수 없습니다. 음, 관리자 비밀번호를 읽는 것 외에는요...
사소해 보이지만 구현은 그렇게 사소하지 않았습니다. 통신에는 맞춤형 프로토콜이 사용되며, 비밀번호는 서버가 전송한 키로 DES를 사용해 암호화되지만 비트가 반전되어 있습니다(가장 어려웠던 부분이 이것을 알아내는 것이었습니다). 키 유도가 없기 때문에 도청자는 모든 것을 쉽게 복호화할 수 있습니다. 그럼에도 불구하고 여전히 비트가 반전되어 있다는 것을 알아내거나 전체를 처음부터 다시 구현해야 합니다...
구현은 recover.py 파일의 recover_with_default 함수를 참조하세요.
바이너리를 분석하다 보면 이 메커니즘을 눈치채지 않기가 어렵습니다. 그 목적은... 비밀번호 복구를 가능하게 하는 것이며, 실제로 그 일을 잘 해냅니다. 너무 잘 한다고 해야 할까요...
무슨 일이 벌어지고 있는 걸까요? 이것은 비밀번호 복구 메커니즘으로 의도된 것 같습니다. 아마도 벤더가 장치 소유자가 자신의 비밀번호를 복구할 수 있는 방법을 제공하기 위해 만든 것으로 보입니다.
흐름이 다음과 같았을 것이라고 추측할 수 있습니다:
모든 것이 좋아 보이지만 한 가지 빠진 것이 있습니다... 보안은 어디에 있나요? 결론적으로 아무데도 없습니다. 이 패킷을 보내고 보안 코드를 유도하여 접근 가능한 모든 장치의 비밀번호를 복구하는 것을 막을 수 있는 것은 없습니다.
저는 이것이 놀랍습니다. 보안을 무너뜨리는 메커니즘의 결함이 있어서가 아니라, 보안 자체가 전혀 존재하지 않기 때문입니다. 고칠 것도 없지만, 그렇다고 이것이 명백한 백도어처럼 보이지도 않습니다. 이 메커니즘은 로그에 흔적을 남기고, 각각 이전보다 더 정교한 3가지 서로 다른 유도 방식을 가지고 있습니다. 이것은 실제로 구현하는 데 시간이 걸렸습니다...
다시 이 방법으로 돌아가서, 이 방법이 동작하려면 장치에 연결된 전화번호/이메일이 있어야 합니다. 구형 버전을 살펴보면 관리자만 이 작업을 할 수 있음을 알 수 있었지만, 이후 우회 방법을 찾았습니다. 놀랍게도 신형 펌웨어에서는 인증 없이 장치 이메일을 변경하는 것이 명시적으로 가능하기 때문에 더 이상 우회가 필요하지 않습니다. 제 생각에 바로 _이곳_이 백도어가 있으려던 곳입니다 :)
기술적인 측면에서 이 메커니즘은 실제로 상당히 복잡하며 리버스 엔지니어링과 재구현이 가장 어려운 부분이었습니다. 이 메커니즘에는 3가지 버전이 있으며, 각 버전은 보안 코드를 유도하는 데 서로 다른 알고리즘을 사용합니다. 비트가 반전된 DES 외에도 하드코딩된 키를 사용하는 맞춤형 치환 암호가 포함됩니다. 하지만 Tiandy가 아무리 노력해도 하드코딩된 키를 사용하는 대칭 암호화를 안전하게 만들 수 없기 때문에 이 모든 것은 헛수고입니다.
제가 관찰한 한 가지는 보안 코드가 1분마다 변경되기 때문에, 3단계의 패킷과 5단계의 패킷 사이에 보낸 시간이 아무리 짧더라도 코드가 변경되면 원래 프로세스가 실패할 가능성이 있다는 것입니다. 이를 고려하여 제 스크립트는 코드가 유효하지 않은 것으로 판명되면 프로세스를 재시도합니다.
이메일(소유할 필요가 없는)을 설정하는 과정을 포함한 전체 프로세스는 recover.py 파일에 구현되어 있습니다.
이 취약점은 "현대적인" 웹 인터페이스("지도"가 있는 인터페이스. 호주가 다소 왜곡되어 보이지만 저는 그 지도를 좋아합니다)를 갖춘 최신 펌웨어 버전(2019년 이후)에서 동작합니다.
이 우회는 간단합니다. 대부분의 API 엔드포인트는 인증이 필요하지만 일부 예외가 있습니다. 그러나 인증을 건너뛸지 여부를 확인하는 부분과 활성화할 엔드포인트를 매칭하는 부분이 서로 다른 곳에 구현되어 있습니다. 대부분의 경우 URL 경로가 주어진 문자열과 정확히 일치할 때 인증이 건너뛰어지므로 안전합니다.
하지만 최신 버전에서는 URL 경로 어딘가에 Record/DownLoad 및 ID= 문자열이 존재하기만 하면 활성화되는 또 다른 예외가 도입되었습니다.
전체 경로가 일치하는 엔드포인트의 경우 여전히 안전합니다. Security/users가 그러한 엔드포인트 중 하나이므로 비밀번호를 직접 복구할 수는 없습니다. 운 좋게도 구성 내보내기 엔드포인트는 URL 경로가 주어진 문자열로 시작하는지 확인(strncmp 사용)하여 선택되므로, 경로에 해당 문자열을 추가하기만 하면 구성 파일을 내보낼 수 있습니다.
이 결함을 이용한 비밀번호 복구는 cgi_recover.py에 구현되어 있습니다.
이론적으로 관리자는 펌웨어를 업그레이드할 수 있으며, 펌웨어는 서명도 암호화도 되어 있지 않습니다. 하지만 맞춤형 펌웨어 패키지를 정말로 준비해야 할까요? 때로는 필요 없습니다. 때로는 필요하며, 저는 실제로 구현할 만큼 미친 사람이었습니다...
비밀번호가 있다면 사용할 수 있는 명령 주입 취약점이 있으며, 그것이 ftpupdate.py 스크립트입니다. 여기서 발생하는 일은 장치에 ftp를 통해 업그레이드를 가져오도록 지시하고 ftpget이 해당 작업을 수행하는 데 사용된다는 것입니다. 놀랍지 않게도 우리의 매개변수는 system() 함수로 직접 전달됩니다.
NVR 펌웨어에서 바이너리 프로토콜에는 이름 그대로의 기능을 수행하는 FILETRANSPORT 명령이 있습니다. 사실 더 할 말은 없습니다. SDK를 다운로드하여 동일한 명령을 사용할 수 있기 때문입니다. 물론 저는 이를 재구현하고 싶었으므로 작동 방식을 보려면 filetransport.py를 참조하세요.
하지만 IPC 모델에는 이 명령이 없습니다. 그렇지만 앞서 말했듯이 우리는 언제든지 펌웨어를 업그레이드할 수 있습니다. 전체 플래시를 준비하는 것은 비현실적이지만, Tiandy의 업그레이드 패키지는 개별 파일을 교체할 수 있게 해주며, 이것이 바로 우리에게 필요한 것입니다(펌웨어 언패킹 참조).
하지만 그렇게 간단하지 않습니다. "box" 파일 형식에는 일부 메타데이터가 있고 그 다음에 파일 배열이 있습니다. 첫 번째 파일의 이름은 ProductModule이어야 하며 일치하는 장치 매개변수를 포함해야 합니다. 그렇지 않으면 업그레이드가 진행되지 않습니다. 매개변수의 값뿐만 아니라 매개변수 자체도 필요합니다. 또한 메타데이터 부분(box 파일 버전 포함)도 검증됩니다.
이것을 수동으로 조립하는 것은 비현실적으로 보이지만 다행히 다른 방법이 있습니다. 구성 파일 내보내기는 업그레이드 유형 필드가 없다는 점을 제외하고 일치하는 모든 메타데이터와 ProductModule 파일이 포함된 동일한 "box" 파일 형식을 사용합니다.
저는 이 필드를 채우는 방법을 알아낼 수 있었고, 따라서 이 프로세스를 구현할 수 있었습니다. 이 메커니즘은 NVR 펌웨어에도 존재하지만 동일한 방식으로 작동하지는 않습니다. 그러나 NVR에는 앞서 설명한 FILETRANSPORT 명령이 있으므로 더 분석할 필요가 없습니다.
upgrade_rw.py 스크립트는 업그레이드 프로세스를 활용합니다. 하지만 이름은 그 이상을 암시합니다... 구성 파일을 내보낼 때 내보낼 파일을 이름으로 지정하는데, 놀랍지 않게도 모든 파일이 동작하므로 box를 다운로드한 다음 펌웨어를 추출하는 데 사용된 것과 동일한 코드로 해당 파일을 읽을 수 있습니다.
내보내기와 업그레이드 모두 웹 API를 통해서도 수행할 수 있습니다. 이 경우 임의의 파일을 읽을 수는 없습니다. API가 더 안정적으로 보이기 때문에 여전히 이것을 구현하고 싶었습니다. cgi_recover.py를 참조하세요.
FTP를 지원하는 모델에서는 사용자 비밀번호에 셸 명령을 주입하는 것이 가능할 수도 있습니다(사용자가 FTP로 로그인할 수 있도록 해당 사용자를 추가하는 명령이 실행될 때).
Tiandy 장치는 포트 3001이 열려 있습니다. 이것은 비웹 방식이 동작하는 데 필요한 포트입니다. 최신 모델은 포트 554 외에도 포트 9100에서 RTSP를 제공하며, 포트 1935에서도 RTMP를 제공합니다. IPC 모델은 ONVIF에 포트 8082를 사용합니다. HTTP와 HTTPS는 표준 포트에서 실행됩니다.
구형 웹 인터페이스(우리가 사랑하는 ActiveX 기술 사용)를 사용하는 장치는 HTTP 응답에 다음 중 하나를 포함합니다:
<title>Net Video Browser</title>
tdvideo.css
신형 웹 인터페이스(이번에는... Flash 사용)를 사용하는 장치는 응답에 다음을 포함합니다:
res/app-0.1.0.css
(Last-Modified 헤더는 정확한 출시 날짜를 우리에게 알려줍니다)
HTTPS가 항상 활성화되어 있는 것은 아니지만 인증서로도 이러한 장치를 식별할 수 있습니다. 모든 장치에 사용되는 인증서는 단 두 개뿐이며 다운로드한 펌웨어에서 찾을 수 있으므로 핀 고정은 무용지물입니다.
구형 인증서:
C=CN, ST=Tianjin, O=Tiandy Tech, CN=dvr_ui
신형 인증서:
C=CN, ST=Tianjin, L=Tianjin, O=Tiandy Tech Ltd, CN=NetDevice
그건 그렇고... HTTPS 지원은 별도의 stunnel 프로세스를 통해 구현됩니다. 이것은 동작하지만, 놀랍지 않게도 프로세스에서 IP 주소가 손실되므로 로그에는 항상 127.0.0.1로 표시됩니다.
Tiandy는 자사 장치가 RTSP와 RTMP를 지원한다고 주장합니다. 멋지지만 매뉴얼에서 찾을 수 없는 것은 이러한 프로토콜을 실제로 사용하는 방법입니다. 필요한 RTSP 및 RTMP URL을 찾을 수 없기 때문입니다. 다행히도 분석 과정에서 얻은 부산물로 이 정보를 갖고 있으므로 공유할 수 있습니다.
NVR의 경우:
채널 C(1부터 시작)의 라이브 스트림을 스트림 유형 S(1, 2, 3)로 시청하려면:
rtsp://username:password@host/C/S
IPC의 경우:
스트림 유형 S로 라이브 스트림을 시청하려면:
rtsp://username:password@host/S
RTMP URL은 요청을 인증하기 위해 맞춤형 해시가 필요하므로 그렇게 간단하지 않습니다. 그러나 RTMP를 사용하면 녹화된 콘텐츠를 재생할 수도 있습니다.
라이브 스트림의 URL은 다음과 같습니다:
rtmp://host/live/C/S/authstring
여기서 C는 채널, S는 스트림 유형입니다.
재생용 URL은 다음과 같습니다:
rtmp://host/vod/START-STOP/C/S/authstring
여기서 START와 STOP은 모두 유닉스 타임스탬프입니다.
authstring은 다음과 같이 계산됩니다:
base64("username:"+md5("username:password")+":unix_timestamp")
rtmpauth.py 도구가 이를 생성할 수 있습니다:
python3 rtmpauth.py username password
이 타임스탬프는 검사되며 차이가 2일을 초과할 수 없으므로 제한 사항이 있습니다:
펌웨어 업그레이드는 서명도 암호화도 되지 않은 독점 "box" 파일 형식으로 패킹됩니다. 이 형식은 언패커의 관점에서 실제로 매우 간단합니다. 건너뛰는 헤더가 있고 언패킹할 파일 배열이 있으며, 각 파일에는 파일 이름과 크기(두 번)가 포함된 고정 크기 헤더가 있고 그 다음에 데이터가 이어집니다.
unbox.py 도구는 파일을 box 파일과 같은 이름의 디렉터리 또는 지정된 디렉터리로 언패킹합니다:
python3 unbox.py [box_file]
python3 unbox.py [box_file] [target_dir]
이 도구는 사용하기에 안전해야 합니다(이 문장을 쓴 다음 도구를 다시 확인해 보니 취약점을 발견했습니다... 어이쿠). 절대 경로는 상대 경로로 변환되고, ..는 __로 대체되며 심볼릭 링크가 없기 때문입니다.
.box 안의 파일이 또 다른 .box인 경우가 있으므로 이 도구를 두 번 실행해야 할 때도 있습니다.