TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 21 READS

스마트 주전자를 뜯어보니: 저가 IoT 뒤의 투야 클라우드

스마트 주전자를 뜯어보니: 저가 IoT 뒤의 투야 클라우드
SOURCE IMAGE · HACKER NEWS

장 보러 갔다가 특가 매대에서 와이파이로 제어되는 '스마트 주전자'를 발견하는 일은 이제 낯설지 않다. 한 독일 블로거는 리들(Lidl) 매장에서 이 물건을 보고, 만우절 농담으로 만들어진 HTTP 상태 코드 418 'I'm a teapot'을 떠올렸다고 한다. 그 호기심이 결국 구매로 이어졌고, IoT 기기를 한 번도 뜯어본 적 없던 그는 '물을 끓이는 하이테크 장비'를 대상으로 첫 해킹 실습에 나섰다. 이 과정은 가벼운 취미담처럼 보이지만, 오늘날 저가 스마트 가전이 실제로 어떻게 동작하는지를 보여주는 좋은 단면이다.

앱과 기기는 직접 대화하지 않는다

처음 그가 세운 가설은 단순했다. 스마트폰 앱이 주전자 안에서 돌아가는 어떤 서버나 API에 직접 접속해 명령을 주고받을 것이라는 추측이다. 실제로 주전자 받침대에 전원을 넣고 와이파이 버튼을 누르자 기기는 삐 소리와 함께 자체 개방형 액세스 포인트를 띄웠다. 다만 DHCP로 IP를 나눠주지는 않았다. 이후 리들 스마트홈 앱으로 초기 설정을 진행하니, 앱은 사용자의 와이파이 자격 증명을 받아 주전자의 임시 와이파이를 거쳐 전달했고, 주전자는 가정용 와이파이에 붙어 앱에 등록됐다. 앱에서 제공하는 기능은 끓이는 목표 온도 설정, 보온 시간, 차 종류별 사전 설정 온도 프로그램, 그리고 현재 상태와 수온 표시 정도였다. 하단에 달력 아이콘이 있었지만 예약 가동은 지원하지 않았다.

라우터(프리츠박스)의 새 기기 알림 덕분에 그는 주전자의 IP를 손쉽게 확보했고, nmap으로 포트를 훑었다. 6668번 포트로 연결 자체는 됐지만 배너가 돌아오지 않아 무엇이 돌아가는지 알 수 없었고, 브라우저로 해당 포트에 HTTP·HTTPS 접속을 시도해도 실패했다. 기기를 직접 조작할 수 있는 국지적 진입점은 사실상 막혀 있었던 셈이다.

트래픽은 전부 클라우드로 향한다

다음 단계는 중간자 공격(MITM)이었다. 그는 칼리 리눅스 가상머신에 알파 USB 와이파이 동글을 물리고 가짜 액세스 포인트를 세운 뒤, 주전자를 초기화하고 이 가짜 와이파이로 다시 설정했다. 설정은 정상적으로 끝났고 트래픽이 잡히기 시작했다. 그러나 기대와 달리 앱과 주전자가 직접 주고받는 통신은 보이지 않았다. 관측된 것은 오직 애저(Azure) 클라우드 IP를 향한 트래픽뿐이었다. 주전자는 TLS 1.2로 암호화된 연결을 통해 주기적으로 클라우드에 접속해 상태를 올리고 새 명령을 받아오는 구조로 추정됐다.

결국 앱이 온도를 바꾸라고 명령하면 그 신호는 로컬 네트워크를 가로질러 주전자로 곧장 가는 것이 아니라, 애저 클라우드를 한 바퀴 돌아 내려온다는 뜻이다. 저자는 중간자 위치를 이용해 가짜 인증서를 주전자에 내려보내 TLS를 깨고 내용을 들여다보는 방법을 구상했다. ettercap이나 bettercap으로 가능하다고 봤지만, 실제로 실행에 옮기지는 않았다.

이름 없는 기기 뒤의 투야

대신 그는 MAC 주소로 와이파이 모듈 제조사를 조회했고, 결과는 투야(Tuya)였다. 투야는 IoT를 서비스처럼 제공하는 대형 사업자다. 자사 모듈로 기기를 만들거나 완제품에 상표만 붙이고, 제어 앱을 조립하듯 구성한 뒤 백엔드로 투야 클라우드를 쓰는 방식이 가능하다. 저자의 표현대로, 손에 든 와이파이 IoT 기기가 투야 계열일 확률은 상당히 높다. 리들 브랜드로 팔리는 주전자 역시 껍데기만 리들이고 속은 투야 생태계였던 셈이다.

한국 실무자 관점에서 이 사례가 시사하는 바는 분명하다. 첫째, 저가 스마트 가전의 '스마트'는 대개 기기 자체의 지능이 아니라 외부 클라우드 의존을 뜻한다. 로컬에서 열려 있는 API가 없으니, 클라우드가 죽거나 제조사가 서비스를 접으면 앱 기능도 함께 멈출 수 있다. 둘째, 단순한 물 끓이는 기기조차 가정 내 존재와 사용 패턴을 주기적으로 해외 클라우드에 보고한다는 점은 네트워크 분리(별도 IoT VLAN)와 아웃바운드 트래픽 통제의 필요성을 상기시킨다. 셋째, 조달·보안 검토 시 표면의 브랜드가 아니라 실제 통신 목적지와 모듈 제조사를 확인해야 위험을 제대로 평가할 수 있다.

다만 이 실습에는 한계도 분명하다. 저자는 TLS를 실제로 복호화해 명령 페이로드를 확인하는 단계까지는 가지 않았고, 투야 개발자 문서를 통한 추가 분석은 기록이 여기서 끊긴다. 따라서 통신 내용의 구체적 구조나 취약점 여부는 확정된 사실이 아니라 열린 물음으로 남는다. 그럼에도 개방형 AP를 이용한 초기 설정, 클라우드 경유 제어, 화이트라벨 모듈이라는 세 가지 패턴은 오늘날 대부분의 저가 IoT에 공통으로 적용되는 구조여서, 비슷한 기기를 다룰 때 무엇부터 확인해야 하는지에 대한 실용적 체크리스트가 되어 준다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://blog.boerzel.de/de/blog/operation-smart-kettle
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...