# TP-Link Tapo C200: 하드코딩 키, 버퍼 오버플로, 그리고 AI 기반 리버스 엔지니어링 시대의 프라이버시 > Clean Markdown view of GeekNews topic #25207. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25207](https://news.hada.io/topic?id=25207) - GeekNews Markdown: [https://news.hada.io/topic/25207.md](https://news.hada.io/topic/25207.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-21T01:37:05+09:00 - Updated: 2025-12-21T01:37:05+09:00 - Original source: [evilsocket.net](https://www.evilsocket.net/2025/12/18/TP-Link-Tapo-C200-Hardcoded-Keys-Buffer-Overflows-and-Privacy-in-the-Era-of-AI-Assisted-Reverse-Engineering/) - Points: 1 - Comments: 1 ## Topic Body - 저가형 **TP-Link Tapo C200 IP 카메라**의 펌웨어를 AI 기반 리버스 엔지니어링으로 분석한 결과, 다수의 **보안 취약점**이 발견됨 - 펌웨어에는 **하드코딩된 SSL 개인키**가 포함되어 있어, 동일 네트워크 내에서 **HTTPS 트래픽 복호화**가 가능함 - 분석 과정에서 **AI 도구(Grok, GhidraMCP, Cline 등)** 를 활용해 펌웨어 구조 파악과 함수 의미 분석을 자동화함 - 발견된 주요 취약점은 **버퍼 오버플로(CVE-2025-8065)** , **정수 오버플로(CVE-2025-14299)** , **WiFi 하이재킹(CVE-2025-14300)** 등으로, 일부는 인증 없이 원격 공격 가능 - 이 사례는 **AI가 보안 연구 효율성을 높이는 동시에 IoT 기기의 구조적 취약성**을 드러낸 예시로 평가됨 --- ### 펌웨어 획득 및 복호화 - Tapo Android 앱을 리버스 엔지니어링해 **TP-Link의 공개 S3 버킷**을 발견, 모든 기기의 펌웨어를 인증 없이 다운로드 가능 - 예시 명령: `aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive` - **tp-link-decrypt** 도구를 이용해 펌웨어 복호화 수행 - RSA 키는 TP-Link의 **GPL 코드 공개 자료**에서 추출 가능 - 복호화된 펌웨어는 **부트로더, 커널, SquashFS 루트 파일시스템** 구조로 구성됨 ### AI 기반 리버스 엔지니어링 - **Ghidra**와 **GhidraMCP**, **Cline**, **Anthropic Opus/Sonnet 4** 등을 활용해 펌웨어 분석 자동화 - AI가 함수의 역할을 설명하고 변수명을 의미 있게 재명명하여 **코드 가독성 향상** - 이 과정을 통해 **HTTP 핸들러, 디스커버리 프로토콜, 암호화 루틴** 등을 매핑 - 펌웨어 내 SSL 개인키가 **부팅 시 생성되지 않고 내장**되어 있음이 확인됨 - 동일 네트워크 내 공격자는 **HTTPS 트래픽 복호화** 가능 ### 주요 취약점 - **CVE-2025-8065 (ONVIF SOAP XML 파서 메모리 오버플로)** - 포트 2020의 `/bin/main` 서버에서 XML 요소 수에 대한 **경계 검사 부재** - 대량의 XML 요청 전송 시 **메모리 오버플로 및 카메라 크래시** 발생 - CVSS v4.0 점수 7.1 (High) - **CVE-2025-14299 (HTTPS Content-Length 정수 오버플로)** - 포트 443의 HTTPS 서버가 `Content-Length` 헤더를 **검증 없이 atoi()로 처리** - 32비트 시스템에서 **오버플로로 인한 크래시** 발생 - CVSS v4.0 점수 7.1 (High) - **CVE-2025-14300 (WiFi 하이재킹)** - `connectAp` API가 **인증 없이 접근 가능**, 설정 완료 후에도 활성화 - 공격자는 카메라를 **공격자 네트워크로 연결**시켜 **영상 트래픽 가로채기** 가능 - CVSS v4.0 점수 8.7 (High) - **인증 없는 WiFi 스캔 API (`scanApList`)** - 주변 WiFi의 **SSID, BSSID, 신호 세기, 보안 설정**을 반환 - Apple BSSID Locator 등으로 **정확한 GPS 위치 추적** 가능 - 원격 공격자가 **카메라의 실제 위치 식별** 가능 ### 공개 및 대응 과정 - **2025년 7월 22일** TP-Link 보안팀에 최초 보고, PoC 및 영상 포함 - **150일 경과 후(12월 19일)** 공개, 이후 TP-Link가 **보안 권고문 발표** - TP-Link는 **자체 CVE 발급 권한(CNA)** 을 보유, 자사 제품 취약점에 대한 **보고·공개 절차를 직접 통제** - 자사 웹사이트에서 **경쟁사 대비 낮은 CVE 수를 마케팅 지표로 활용**, **이해상충 구조** 지적 ### 결론 - AI 도구는 **리버스 엔지니어링 효율을 극대화**하며, 보안 연구 접근성을 높임 - 그러나 **하드코딩 키, 인증 없는 API, 취약한 파서 구조** 등은 IoT 기기의 **근본적 보안 부재**를 드러냄 - TP-Link 사례는 **AI 시대의 보안 연구와 제조사 책임의 균형 문제**를 상징적으로 보여주는 사례임 ## Comments ### Comment 48054 - Author: neo - Created: 2025-12-21T01:37:06+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46329038) - 이런 글들이 **진짜 실패 사례**와 FAANG조차 어려워하는 문제를 뒤섞어 비판하는 방식이 아쉬움 특히 “TP-Link의 펌웨어 저장소가 인증 없이 공개된 S3 버킷에 있었다”는 부분을 비판적으로 다루는 건 잘못된 접근임 오히려 **보안 은폐(security through obscurity)** 를 피한 좋은 사례라고 생각함 이런 글이 오히려 경영진에게 잘못된 ‘잠금 강화’ 지시를 내리게 할 수도 있음 - 글 자체는 읽기 쉬웠지만, **LLM이 쓴 듯한 톤**이 느껴졌음 AI가 쓴 글은 미묘한 뉘앙스가 부족하고 모든 걸 과하게 새롭거나 좋고 나쁜 것으로 단정하는 경향이 있음 나쁜 글은 아니지만, 읽을 때 주의가 필요함. 요즘 HN에 올라오는 글 대부분이 AI 도움을 받은 듯함 - “펌웨어 저장소가 공개되어 있다”는 말에 “리눅스 얘기는 하지 말자”는 농담을 던짐 - 이런 **리버스 엔지니어링 블로그**는 단순히 재미있고 교육적인 이야기 전달 방식임 나도 이런 글을 여러 번 써봤는데, 이번 글은 정말 흥미로웠음 사실 “펌웨어를 어떻게 구했는가”는 이 이야기에서 가장 덜 중요한 부분임 - 펌웨어가 공개되어 있다는 부분에서 부정적인 뉘앙스를 전혀 느끼지 못했음. 혹시 그렇게 느꼈는지 궁금함 - 펌웨어는 항상 공개되어야 한다고 생각함. 그게 맞는 방향임 - 대부분의 다른 카메라 모델도 비슷한 **보안 취약점**을 공유하고 있을 가능성이 높음 [TP-Link 커뮤니티 페이지](https://community.tp-link.com/us/smart-home/kb/detail/412852)에 따르면 C200의 최신 펌웨어는 1.4.4로 표시되어 있지만, 기사에서는 1.4.2로 언급됨 즉, 일부 업데이트는 있었지만 **보안 패치**는 반영되지 않은 듯함 - 예전에 Zyxel 제품을 분석했을 때도 같은 결론에 도달했음 많은 제조사가 **공용 하드웨어를 브랜드만 바꿔서 판매**하는 구조임 관련 분석 글: [Part 1](https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-1.html), [Part 2](https://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-2.html) - 이런 카메라는 로컬 연결에는 적합하지만, 일반 사용자에게는 여전히 **사용성 문제**가 큼 - 이런 이유로 **IoT 네트워크 분리(segmentation)** 가 필수적임 모든 스마트 카메라와 IoT 기기를 별도의 VLAN에 두고, 인터넷 접근은 방화벽을 통해 제한해야 함 TP-Link 카메라 사용자에게 권장하는 설정: 1. 라우터에서 UPnP 비활성화 2. VLAN으로 IoT 기기 분리 3. 필요한 엔드포인트만 아웃바운드 허용 4. 가능하면 **오픈 펌웨어**로 교체 5. 정기적으로 업데이트 확인 하드코딩된 키 문제는 특히 심각하며, 제품 라인 전체에 영향을 미침 - 친구의 집 네트워크를 테스트해준 적이 있는데, **PoE 인터폰 시스템**을 통해 내부망 전체에 접근할 수 있었음 그는 IoT 기기를 VLAN으로 분리하지 않았고, 알림 시스템도 없었음 결국 그날 VLAN 분리와 접근 제한의 중요성을 직접 배우게 되었음 많은 사람들이 비슷한 방식으로 내부망을 노출하고 있을 것 같음 - VLAN 설정을 단계별로 설명한 **가이드**가 있는지 묻는 사람도 있었음. 기술적으로 가능하지만 구체적인 절차가 필요함 - [Thingino](https://thingino.com/#:~:text=SC3336%2C%20WQ9001%2C%208MB-,TP%2DLink%20Tapo%20C200,-T23N%2C%20SC2336P%2C%20RTL8188FTV)가 C200을 지원한다고 함 - 하지만 실제로는 C200의 **5가지 버전 중 일부만 지원**함 정확한 칩셋을 확인하려면 [OpenIPC](https://openipc.org/)를 참고해야 함 - Thingino 커뮤니티가 만든 펌웨어는 정말 놀라움 호환되는 카메라가 있다면 꼭 시도해볼 만함 - 나는 모든 카메라를 **인터넷 차단된 VLAN**에 두고 사용함 HomeKit을 통해 로컬 접근이 가능해서 별도 앱 없이도 잘 작동함 - 이런 수준의 보안 부실은 **의도적**인 것 같을 정도임 수백만 대를 팔면서도 기본적인 취약점 검사를 안 한다는 건 이해하기 어려움 $150 이하의 Wi-Fi 카메라는 대부분 비슷한 문제를 가질 것이라 봄 진짜 안전하게 쓰려면 **비독점 Wi-Fi ↔ Ethernet 어댑터**를 직접 만들어 쓰는 수밖에 없음 - 이 카메라는 공식 사이트에서 $17.99에 판매 중임 하드웨어, 포장, 물류, 테스트, 반품 등을 빼면 남는 건 **단위당 $5 이하의 이익**임 여기에 $100,000을 추가 개발비로 쓰는 건 20,000대를 불태우는 셈임 TP-Link처럼 제품군이 많은 회사는 이런 비용이 연간 수천만 달러로 불어남 결국 **최소한의 개발만으로 출하**하는 구조임 - 일부 USB 전원 카메라는 **USB 네트워크 어댑터**를 지원함 기술적으로 익숙한 사람은 Thingino 펌웨어로 로컬 전용 환경을 구축할 수 있음 - 이런 카메라는 절대 **신뢰할 수 없는 네트워크**에 두면 안 됨. 너무나 자명한 원칙임 - “모든 Wi-Fi 카메라가 비슷한 문제를 가진다”는 말에 전적으로 동의함 - TP-Link의 **S3 펌웨어 저장소**가 언제까지 열려 있을지 모르겠음 약 990GiB 정도 되는 데이터라, 누군가 아카이브나 토렌트로 백업해두면 좋겠음 - 나는 이 카메라를 **Unifi + ONVIF**로 비중요 용도로만 사용함 별도 VLAN에 두고 인터넷 차단했는데, 다행히도 정상 작동함 - 카메라를 조사할 때 [drmnsamoliu.github.io](https://drmnsamoliu.github.io/) 사이트를 참고했음 - Ghidra와 **AWS Amazon Q**를 이용해 장난감 드론의 영상 피드를 리버스해봤음 GhidraMCP를 썼다면 훨씬 빨랐을 것 같음