내 강아지를 감시하려 했더니, TP-Link를 감시하게 됨
(kennedn.com)- 집안 강아지 관찰을 위해 Tapo 카메라를 구입했지만, 예기치 않게 TP-Link 기기와 앱의 동작 원리를 역설명함
- 온보딩 과정과 암호화 API 통신 구조를 분석하기 위해 MITM, APK 디컴파일, 암호 해독 스크립트 생성 등 다양한 기법을 사용함
- 초기 관리자 비밀번호의 발견 및 세션 키 파생 과정을 통해 암호화된 메시지를 해독하고, 디바이스와 클라우드 계정 간 신뢰성 없는 동기화 문제를 파악함
- 온보딩 전체 흐름을 분석해 주요 API 호출 과정, 계정 생성, 비밀번호 변경, Wi-Fi 연결 과정 등을 Bash 스크립트로 자동화함
- Tapo 펌웨어 보안 설계의 허점과 덜 정교한 암호화 구현, 불규칙한 계정 동기화 등, 저가형 IoT 디바이스의 특징을 지적함
프로젝트 개요
- 필자는 실내 강아지 관찰을 위해 저가형 Tapo 카메라를 구입해 사용함
- 사용 과정에서 설정의 불편함과 온라인 정보의 부족으로 인해, 제품 동작 원리를 깊이 파헤치게 되는 동기를 갖게 됨
- frigate 연동, 2way audio 활성화 등에서 예상치 못한 문제가 발생해, 클라우드 연동 없는 직접 온보딩 방법에 관심을 갖게 됨
온보딩 및 인증 구조 분석
- Tapo 카메라의 연결 절차를 분석하기 위해 MITM proxy와 frida 동적 후킹 도구를 사용해 앱과 카메라 간 트래픽을 가로챔
- 최신 앱들은 프록시 무시, certificate pinning 등 우회 저항 기능이 있으므로, 동적 도구를 이용한 방법이 유효함
- 이러한 우회 구조 세팅 후, 카메라 온보딩 플로우에서 기본 관리자 계정 login 과정을 정확하게 확인함
- 기본 로그인 API는 클라우드 계정 암호와 별개로 디바이스 고유의 기본 비밀번호로 동작함을 발견함
암호화 구조 및 기본 비밀번호 탐색
-
APK 디컴파일(JADX 사용) 및 코드 분석을 통해,
admin
계정의 기본 비밀번호(TPL075526460603
)를 확보함 - 클라우드 암호를 변경해도 이미 연동된 카메라 기기는 변경을 인지하지 못하는 점에서, 앱과 카메라 간 비밀번호 동기화가 부정확함을 확인함
- 기본 비밀번호를 알아냈으므로, 세션 키(
lsk
,ivb
) 파생 로직을 구현해 암호화 API 메시지를 실시간으로 해독 가능하게 함
mitmproxy 스크립팅 및 API 분석
- PyTapo 오픈소스 프로젝트를 참고해, 실제 Tapo 온보딩 절차의 API 흐름을 정밀히 분석함
-
tapo_decrypt_pretty.py
스크립트를 통해- 로그인 핸드셰이크 감지
- 세션 키 추출
- 암호화 API 해독 및 가독성 높은 출력, JSON 저장
- 전체 온보딩 API 호출 내역 중 유의미한 주요 과정만 추려 자동화 워크플로우를 생성함
- Wi-Fi 목록 조회(
scanApList
) - RTSP/ONVIF 계정 활성화
- 관리자 비밀번호 변경
- Wi-Fi 연결
- Wi-Fi 목록 조회(
자동화 및 결과
- Bash 스크립트(
tapo_onboard.sh
)로 위 모든 온보딩 과정을 자동 실행하게 구성함- 기본 admin 로그인
- Wi-Fi 선택 및 연결
- 카메라 피드 로고 제거
- RTSP/ONVIF 사용 허용
- 관리자 비밀번호 재설정
- 카메라 펌웨어 구조상 다음과 같은 특징 및 허점을 발견함
- 일부 API는 SHA-256 해시를 사용하나, 몇몇은 MD5 등 구식 암호 방식 유지
- 공개키가 2개 존재하며, 어떤 상황에 어느 키를 사용해야 하는지 불분명함
- 앱과 디바이스 간 비밀번호 동기화가 매우 불안정함
결론 및 소감
- Tapo 카메라 펌웨어와 API 보안 구조는 임시방편 및 덜 정교한 설계로 느껴짐
- 저가형 IoT 기기의 보안적 허점과 불완전한 온보딩 시스템 현실을 간접적으로 체험함
- 프로젝트의 궁극적인 목표였던 강아지 체크에는 성공했으며, 강아지는 소파 혹은 침대에서 자는 모습을 주로 확인함
Hacker News 의견
-
내 Frida 스크립트를 써줘서 신기함을 느낌, 해당 스크립트는 여기서 확인 가능함, 스크립트가 실제 환경에서 잘 작동하는 것 같아 기쁨을 느낌, 혹시 추가하거나 수정한 부분이 있다면 듣고 싶음
- HTTP Toolkit 정말 좋은 툴이라고 생각함, Tim의 훌륭한 작업임을 언급함
- 내가 사용해본 툴 중 Http toolkit이 최고라고 생각함, mitmproxy, proxyman, charles proxy도 써봤지만 httptoolkit이 가장 좋았고 오픈 소스임
-
참고로, 양방향 오디오를 frigate에서 사용하려면 일반적인 rtsp:// 대신 tapo:// go2rtc 설정을 메인 스트림에 적용해야 함, TP-Link는 자체 API에서만 양방향 오디오를 제공함, 이 설정을 하면 ONVIF(오픈소스 도구로 카메라 팬/틸트 컨트롤)가 안 돼서 번거로움이 있음, 두 기능을 다 쓰려면 tapo:// 스트림 읽기 중단 → onvif 클라이언트 실행/팬·틸트 조정 → onvif 종료 → tapo:// 재시작 과정을 반복해야 공격적인 워크플로우가 필요함
-
IoT 보안이 전반적으로 엉망이라고 생각함, 소비자 라우터가 네트워크 트래픽을 모두 처리하는 감사불가한 블랙박스라는 점이 특히 걱정임, 대부분의 사람들은 라우터 펌웨어가 수년간 업데이트되지 않았으며 이미 알려진 취약점이 존재한다는 사실을 모르는 경우가 많음, 네트워킹 하드웨어의 공급망 신뢰 모델이 완전히 망가졌다고 생각함
- IoT 보안이 별로라는데 공감함, 나로서는 IoT 기기가 단순히 연결만 잘 됐으면 하고, 온라인 전용 제약을 뚫는 익스플로잇이라도 사용하고 싶을 때도 있음, 하지만 클라우드 연동 IoT를 원하는 진짜 사용 사례도 있고, 그래서 처음 설정 시 기기가 사용자에게 원하는 방식을 묻고 선택된 모드로만 동작해야 한다는 생각을 함, 클라우드 MFA가 필요하면 그걸 고를 수 있고, 단순히 프로그래밍으로 조작하고 싶으면 오프라인으로 남겨둘 수 있게 해야 한다고 봄
- 사용자와 목적지 사이엔 셀 수도 없는 라우터가 존재하는데 이 라우터들을 전부 감시할 수 없음, 엔드 디바이스는 이미 라우터가 뚫렸다고 가정하고 모든 데이터를 검증, 암호화된 형태로 전송하기에, 라우터가 DDoS나 암호화폐 채굴 같은 부정 행위에 쓰이지 않는 한 보안 자체는 그다지 의미 없다고 생각함
- 대부분의 사람들은 ISP가 제공하고 설정해준 라우터를 사용하기에 사실상 블랙박스를 또 다른 블랙박스에 연결하는 셈이라고 느낌, 와이파이 연결 시 ISP가 지정한 SSID와 비밀번호를 받아 사용하는 경우를 종종 접하면서 ISP에 너무 많은 권한을 넘기고 있다는 점에 놀람을 느낌
- 일반 소비자 제품은 그렇지만 Ubiquiti나 Mikrotik 같은 prosumer-grade 하드웨어로 가면 빠른 보안 업데이트와 안정적인 펌웨어 지원이 가능하다고 생각함
-
이 블로그 글이 뛰어나게 잘 쓰였다고 느낌, 요즘 이런 스타일의 글은 LLM이 생성한 경우가 많고 읽기에 불편한 경우가 많은데, 이 글은 기술적이면서도 편안한 균형을 잘 맞춘 점이 인상적임, (표지 이미지는 AI 생성이라는 걸 알지만 글의 본질과는 무관하다고 생각함)
- 나는 uBlock Origin으로 대용량 미디어 파일을 기본적으로 차단해 자원 사용을 아낀다는 입장임, 표지 이미지는 애초에 차단당하는 경우가 많고 쓸모도 거의 없음, 요즘 사람들이 굳이 생성하는 데 자원을 쓰는 것이 안타깝게 느껴짐
-
Frida, mitmproxy 같은 도구를 Android 앱에서 계속 쓸 수 있을지 궁금함, 내년에 서명 요구사항이 적용되면 어떻게 될지 알고 싶음
- 전반적으로 가능은 하겠지만 attestation이 필요한 앱은 훨씬 더 어려워질 예정임, 지금도 Pixel처럼 OEM unlock과 루팅이 허용된 기기는 developer로 계속 활용 가능함, 다만 이 경우 기기가 unlock 여부로 마킹되어 Google attestation에 실패함, 앱을 풀고 Frida를 인젝션해 개발자 계정으로 sideload하는 방식(iOS처럼)도 가능할 거라 예상함, 하지만 이 또한 attestation 실패와 anti-tampering/anti-debugging 공격에 노출됨
- 사실 그런 변화에 직접적인 영향을 받지는 않을 것으로 예상함, 리버스 엔지니어링은 대부분 루팅된 기기와 에뮬레이터에서 진행되기 때문임, 더 드물지만 non-rooted 기기에서 Frida를 APK에 gadget 방식으로 인젝트하는 경우에는 어려워지긴 해도 여전히 개발자 모드로 APK를 빌드‧설치할 수 있는 길이 남아있다고 생각함, 이를 완전히 막으면 Android 앱 개발이 아예 불가능해질 것이기 때문에, 아마 sideload는 일반 사용자 기기에서는 차단하고 개발자 인증서 추가 방식 등은 열어둘 것 같음, 결국 실제 앱 배포가 가장 어려워지는 거고 개발/리버스 엔지니어링 용도는 가능할 것 같음, 다만 device attestation 확대가 더 큰 위협임, 루팅/비공인 기기에서 점점 더 많은 앱이 과감하게 unmodified device 여부 검사에 집착하게 될 수 있는데, 지금은 주로 대형 금융앱에서만 적용함, 그나마 신경 써야 할 사람(GrapheneOS 유저)도 적고 추가 서버 구축 등 비용이 있어 쉽게 대중화되기는 어렵지만 추후 변화가 있을 수도 있음
- 실제로 이미 Frida 활용은 쉽지 않다고 느낌, Frida를 쓰려면 루팅이 필요한데 루팅 자체가 점점 불가능한 모델이 늘어나고, 매우 강력한 루팅 탐지 SDK와 Play Integrity 대응책이 존재함
-
참고로, 관련 사례로는 The Tapo C200 연구 프로젝트와 PyTapo: Tapo 카메라용 Python 라이브러리가 있음
-
또 다른 관련 자료로, (TP-Link 펌웨어 복호화 및 C210 V2 클라우드 카메라 부트로더 분석)이 여기에 있음
-
OP의 강아지가 침대에서 바닥으로 이동하는 이유가 혹시 난방기(라디에이터) 켜짐 때문이 아닐까 추측함, 추가 센서 데이터가 필요할 것 같음
- 혹은 그냥 추운 걸 느껴서 그런 것일 수 있다고 생각함
-
이제는 하드코딩된 관리자 비밀번호 발견이 별거 아닌 시점에 도달한 것 같다고 느낌
- 하드코딩된 기본 비밀번호일 뿐 영구적인 백도어는 아니라고 이해함, 글에 나온 대로라면 온보딩 과정에서 사용자가 비밀번호를 바꾸는 구조임, 대부분의 앱이 이런 방식으로 동작함
- 설치 후 정상적인 과정에서 비번을 바꾸니 문제없다고 생각함, 지난 5년간 우리 집에 가능한 한 많은 IoT/스마트홈 기기를 구축하면서 느낀 점은 거의 모든 업체가 기능성에 의문이 드는 제품만을 팔며, 한 업체로 통일하지 않으면 스마트홈 전반 구축이 매우 어렵다는 것임, 그리고 아직은 괜찮은 업체도 개별 니즈를 모두 만족시키지 못함, 내 스마트폰엔 Ecobee, Lutron, Hue, 여러 카메라 벤더, Meross, Smart Life 등 다양한 앱들이 설치되어 있는데, 이중 Lutron과 Hue만이 허브/홈킷으로 직접 통제가 가능해 앱을 할 필요가 없음, Matter와 Thread 표준화가 된 지 오래지만 여전히 호환 기기 대신 값싼 와이파이 기반 제품이 넘쳐나고 대부분이 구려서 앱을 통해서만 관리 가능하며 클라우드 서비스로 유도하도록 만들어져 있음, 카메라 네 개나 산 건 내 탓도 있지만 사실 벤더마다 강점이 달라 소비자가 나눠 사는 것도 어쩔 수 없다고 생각함
- 변경하지 않으면 사용이 불가한 하드코딩된 관리자 비번 자체는 별 이슈라고 생각하지 않음
- 사실 이 기술에 괜히 짜증이 난 것 같음, 여기서는 문제라고 할 수 없음
- 스마트폰이야말로 원조로 적대적인 디바이스란 관점도 있음, 네트워크 기기는 적어도 상황 파악이나 발견이 이렇게 가능하다는 점이 다름
-
tapo 카메라 중 rtsp 지원 모델 정리된 레퍼런스를 구하고 싶음, c210은 그럭저럭 잘 동작하는데(클라우드 캡처는 안 됨) frigate에 연동해 사용 중임, 오늘 c402(실외형)를 구입했는데 요건 advanced 설정에 camera account가 없어 아쉬움, 저렴한 가격이 매력적이지만 기능 통일성이 부족하다고 느낌, 저렴하면서도 rtsp 스트림을 지원하고 솔라 패널도 장착된 좋은 실외 카메라가 있다면 추천 받고 싶음
- 카메라에서 rtsp:// 를 지원하지 않아도 tapo:// go2rtc 스트림 소스를 쓰는 게 가능할 것임, 내 frigate 설정을 여기 에 참고로 남겨둠