신한카드 2,3개월 (5만원↑)7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22개월 (100만원↑, SK pay 결제 시) KB국민카드 2,3,4,5,6,7개월 (5만원↑)8,9,10,11,12,13,14,15,16,17,18,19,20,21,22개월 (100만원↑, SK pay 결제 시) 비씨카드 2,3,4,5,6,7개월 (5만원↑)우리카드 2,3,4,5,6,7개월 (5만원↑)하나카드 2,3,4,5,6,7,8개월 (5만원↑)농협[NH페이]카드 2,3,4,5,6,7,8개월 (5만원↑)12개월 (100만원↑, SK pay 결제 시) SC은행리워드카드 2,3,4,5,6,7개월 (5만원↑)귀뚜라미보일러 IoT 온도 조절기작년즈음 귀뚜라미보일러에서 Wi-Fi를 통해 스마트폰 제어가 가능한 온도 조절기를 발매했다는 소식을 들었습니다만, 어느새 기억에서 잊혀져가고 있다가, 최근 클리앙의 한 사용기를 보고 구형 보일러에서도 사용이 가능하다는 것을 알게 되었죠. 그런데 해당 사용기에서 MITM (Man in the middle, 중간자 공격)에 취약하다는 언급이 클리앙 새로운 소식의 뉴스로 등장하게 되면서, 유저들의 수 많은 질타를 받게 됩니다.
Philips의 Hue, Xiaomi의 Home Gateway를 사용하고 있는 중인데, 국내 IoT 제품들의 완성도를 구경해보고도 싶고, 무엇보다 최근에 발견한 Homebridge라는 Node.js 기반 Homekit API 에뮬레이션 서버에 붙여보고 싶은 욕심이 들더라고요. 그래서.. 질렀고, 어제 수령해서 설치했습니다. 개봉기패키지는 A4 크기의 소설책 한권 수준의 크기입니다. 보일러 및 온도 조절기에 따라 신형 (NCTR-10WIFI)
/ 순간식 (CTR-15WIFI) / 저탕식 (CTR-15WIFI) 로 구분됩니다. 저는 순간식 모델입니다. 패키지 구성은 온도 조절기 본체, 백플레이트, 백플레이트 고정 나사, 설명서가 전부입니다. 기존 온도 조절기가 설치되어 있는 모습니다. (좌하단) 기존에 설치된 온도 조절기는 CTR-5700PLUS 모델인데, 이 모델은 보일러 모델에 따라 순간식/저탕식이 나뉩니다. 백플레이트는 기본적으로 장착된 상태인데, 탈거한 모습입니다. 캐패시터가 꽤 눈에띄네요. 옆을 보면 본체 하우징을 탈거할수 있는 홈이 보입니다. 궁금한걸 못참는 공돌이라 설치 전에 후다닥 뜯어봅니다. 궁금헸던 MCU와 Wi-FI 칩셋은 디스플레이 아래에 위치하고 있습니다. 좌상단에 두번째 통신 채널 혹은 디버깅용 포트로 추정되는 홀이 보이네요. 역시나 캐패시터가 눈에 띕니다. 설치기안전을 위해 절연장갑을 착용하고, 기존에 사용중이던 온도 조절기는 전원버튼을 눌러서 끕니다. 온도조절기를 위쪽으로 밀어 백플레이트에서 본체를 탈거합니다. 본체에 표시된 극성을 잘 메모해둡니다. (근데 저는 메모했는데도 실수했습니다 ㅋㅋㅋ) 신기하게도 두 온도조절기에 적혀있는 QA 담당자로 추정되는 분의 이름이 똑같습니다 ㅎㅎ 제 것은 얇은 단심으로 된 전선인데, 많이 꼬아진 상태로 스트레스를 많이 받았는지 살짝 움직이니 끊어져버렸습니다. 나사를 풀어 기존 온도조절기에 고정된 전선을 빼냅니다. 새 온도조절기와 기존 온도조절기의 크기가 다르기 때문에 백플레이트도 교체해야합니다. 기존 백플레이트 탈거 후 새로운 백플레이트를 설치합니다. 새 온도조절기와 결선을 하기 전에, 기존 전선의 길이가 애매해서 정리하기로 합니다. 두가닥 전선의 길이를 니퍼로 깔끔하게 맞춰줍니다. 각 전선은 연결을 위해 와이어 스트리퍼로 피복을 다시 벗겨냅니다. 드라이버를 사용하면 쉽게 빠지지 않는 접속부를 쉽게 꺼낼 수 있습니다. 온도 조절기와 기존 전선을 연결합니다. 쨔잔! 연결 즉시 전원이 잘 들어오는걸 확인할 수 있습니다. 백플레이트와 결합합니다. 설치가 잘 되었습니다. (이때까지만 해도 연동에서 말썽을 일으킬 줄은 상상도 못했습니다….) 연동기연동을 위한 AP 모드 진입은 쉽습니다. 전원을 끈 상태에서 예약설정/수온설정 버튼을 5초간 누르고 있으면… 설정을 위한 AP 모드로 진입합니다. 현재 상태에서는 검색은 되나 접속이 되지 않습니다. 30초정도 기다리면 AP모드
활성화를 의미하는 파란 안테나 아이콘이 LCD 우상단에 표시됩니다. 물론 호기심이 발동해 바로 연동 관련 설정을 진행하지 않았습니다 (…) 호기심 발동일단 AP 모드에서 어떤 포트가 열려있는지 궁금했습니다. 설정을 위한 AP Mode라 하더라도 AP Mode는 이름 그대로 Access Point Mode이므로 Wi-Fi 되는 디바이스면 다 붙을수 있지요. DHCP로 192.168.200.2 ~
192.168.200.254 대역을 할당해서 쓰네요. 80번이 열려있네요. 아마 시스템 관련 설정페이지겠지요. curl으로 빠르게 훑어보면… 역시나 디바이스 관련 설정이 있습니다. 브라우저에서 보면 이렇습니다. lwIP를 서버로 쓰고 있네요. lwIP는 BSD 라이선스인데 별도로 저작권자 표기를 발견하지는 못했습니다. 더 볼 것이 없어서 스킵을 하려고 하는데…. 문제 발생호스트, 그러니까 온도 조절기가 먹통이 되는 사태가 발생했습니다. 다량의 패킷을 쏴서 그런지 먹통이 된 것 같네요. 전원버튼을 눌러서 전원을 끄고 다시 AP 모드에 진입을 수십번 반복했지만, 파란색 안테나 아이콘이 뜨지 않습니다. 아무리 생각해봐도 기기에 붙어있는 ‘전원 버튼’ 은 실제로 온도 제어기의 전원을 제어하는 것은 아닌 것 같아서, 이 상황에서 확실히 온도 제어기를 껐다가 다시 켜는 방법은 연결된 보일러를 끄는 것이라 유일하다고 판단을 했는데… 백플레이트 뜯어내서 연결된 전선을 끊고 다시 연결할까 생각해봤지만… 그랬더니 예상대로 AP모드가 잘 활성화가 되었습니다. 근데 이번에는 아이폰에서 공유기 연결을 위한 초기 설정이 안됩니다. 차단기 내리고 다시 설정… 을 몇번 반복하다가 그냥 노는 안드로이드 단말 찾아서 설정하니 한방에 붙네요. 허탈했습니다…. 공유기에 정상적으로 붙으면 이렇게 PASS 텍스트가 찍힙니다. 회원가입후 기기 등록까지 완료되면 최종적으로 이런 화면이 표시됩니다. 패킷 훔쳐보기개인적으로 insecure/suspicious 하다고 판단되는 장비들은 별도의 Bridged AP로 고립시키고, 대강 요런 모습입니다. 저렇게 Raspberry pi (무려 1세대 Model B 모델!)에 iptime N300UA를 붙여서 Soft AP를 만든것이죠. App에서 오고 가는 HTTP/HTTPS 패킷들은 주로 Charles Proxy를 통해 쉽고 간편하게 훔쳐볼 수
있고, AP 모드에서 초기 연동 설정을 하기 이전에 온도 제어기 - 서버간 패킷 훔쳐보기(공유기 연결 이전에 캡쳐를 시작했기 때문에, DHCP로 IP를 받아오고, ARP 응답을 하는 것이 보입니다.) 초기 공유기와 연결이 되면, TCP를 통해 서버에 기기 등록 관련 메세지를 즉시 보냅니다. 재미있는 점은, 별도로 DNS 질의를 하지 않는다는 것입니다. 온도 제어기와 서버간 TCP 패킷은 암호화 되어있지 않습니다. (다시 Xiaomi와 비교해보자면, Xiaomi는 Message Header는 암호화 되어 있지 않지만, message body는 AES-128-CBC로 암호화되어 오고갑니다.) 또 재미있는것은, 인터넷 연결 상태를 확인하기 위해 2분마다 google.com 의 A 레코드를 조회하는 DNS Query를 보낸다는 것입니다. 어쩄거나 패킷이 암호화 되어 있지 않은 상태이기 때문에, 패킷의 구조나 명령 종류에 대해서는 패킷을 분석해보면 쉽게 알아낼 수 있을것입니다. 다르게 생각해보자면, 내부망에 침입이 가능한 경우 API를 통해서가 아니라 직접 디바이스로 명령 패킷을 보낼 수도 있다는 것이겠지요 :) 패킷 수준의 분석은 일단 충분한 정보를 얻었다고 판단해 여기까지 진행하고, HTTP(S) API를 살펴보기로 합니다. 애플리케이션 - 서버간 HTTP(S) 요청/응답 훔쳐보기애플리케이션 - 서버간 사용하는 API는 크게 두가지로 나뉩니다. 첫번째는, iOS App과 구버전 Android App에서 사용하는 HTTP API 업데이트된 안드로이드 앱 - HTTPS API 뜯어보기위에서 초기 연동에 문제가 있어서 안드로이드 앱을 사용했기 때문에, Charles Proxy로 가로챈 Request입니다. HTTPS Protocol을 확인할 수 있습니다. HTTP에서 HTTPS로 변경은 되었으나, POODLE Attack 위험이 있는 SSLv3을 지원하고 있습니다. 또한, HSTS 헤더가 존재하지 않기 때문에 별도의 루트 인증서 설치 없이도 SSL MITM이 쉽게 가능합니다. 회원가입에서 사용하는 주소검색 API는 여전히 HTTP를 사용합니다.
좀 아쉬운건, 아이디/비밀번호를 보내는 의미를 알 수 없는 분리된 API 3개가 존재한다는 것입니다. 위 이미지는 회원가입 이후 로그인시 날아가는 요청들인데, 각 역할은 다음과 같습니다.
개인적으로는 1~3을 굳이 분리할 필요가 있나 생각이 듭니다. 단일 API로 통일해도 충분했을 것 같은데 말이죠 :) 디바이스로 보낼 명령은 단일 API를 사용하는 것 같습니다. JSON payload 내 HTTPS 요청과 응답 역시 시간을 들여 분석해보면 더 자세한 것을 알 수 있을것입니다. iOS 앱 - HTTP API 뜯어보기iOS 앱에서 사용하는 HTTP API를 위와 같은 방법으로 살펴보았으나,
이외에는 큰 차이가 없어 자세히 기술하지는 않습니다. 다음 할일어느정도 내부를 뜯어보았으니, 이 다음은 Homebridge plugin을 만들어 Homekit에 붙여볼 차례입니다. 이 부분은 진행인 작업이고, 완료되면 별도 포스트로 찾아뵙도록 하겠습니다! |