▲

스마트 홈 디바이스 해킹 (2024)

 (jmswrnr.com)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • ESP32 기반 스마트 홈 기기를 리버스 엔지니어링하여 Home Assistant와 통합함
  • 모바일 앱을 분석하여 클라우드 서버와의 연결을 확인함
  • 네트워크 트래픽을 가로채어 기기 제어를 시도함
  • ESP32 플래시를 덤프하고 분석하여 펌웨어 수정을 시도함
  • 패킷 구조를 분석하여 암호화 및 체크섬을 이해함

소개

  • 최근 Home Assistant에 모든 기기를 연결하려는 시도를 하고 있음
  • 특정 공기청정기가 자체 앱 외에는 연결되지 않아 이를 해킹하여 통합하려고 함
  • 인터넷 연결과 클라우드 계정에 의존하는 제품의 문제점을 지적함

계획

  • 모바일 앱이 클라우드 서버와 연결되어 원격 제어가 가능함을 확인함
  • 네트워크 트래픽을 가로채어 기기를 제어할 수 있는 방법을 모색함

모바일 앱 분석

  • Android 앱을 분석하여 React Native로 개발되었음을 확인함
  • WebSocket을 통해 클라우드 서버와 연결됨을 발견함

네트워크 검사

  • Pi-hole을 사용하여 DNS 쿼리를 확인하고 Wireshark로 트래픽을 분석함
  • UDP 패킷을 통해 기기와 서버 간의 통신을 확인함

패킷 분석

  • UDP 프록시를 사용하여 기기와 클라우드 서버 간의 트래픽을 중계함
  • Wireshark를 통해 패킷 구조를 분석하고 암호화 가능성을 확인함

물리적 분해

  • ESP32 기반의 기기를 분해하여 플래시 칩에서 펌웨어를 덤프함
  • esptool을 사용하여 시리얼 연결을 통해 데이터를 읽어옴

플래시 분석

  • esp32knife를 사용하여 플래시 데이터를 분석하고 파티션 테이블을 확인함
  • FAT 파일 시스템에서 중요한 파일들을 발견함

초기 정적 분석

  • Ghidra를 사용하여 펌웨어의 문자열을 분석하고 암호화 라이브러리 사용을 확인함
  • mbedtls 라이브러리를 사용하여 ECDH 및 HKDF 알고리듬을 구현함

펌웨어 수정

  • Ghidra를 통해 CapSense 기능을 비활성화하고 펌웨어를 수정하여 기기를 부팅함
  • 체크섬 문제를 해결하여 수정된 펌웨어를 성공적으로 플래시함

패킷 헤더

  • 패킷 헤더의 구조를 분석하여 시리얼 번호와 메시지 식별자를 확인함
  • 클라이언트 요청과 서버 응답의 패턴을 파악함

패킷 체크섬

  • CRC 체크섬을 확인하여 패킷 데이터의 무결성을 검증함
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 장기적인 해결책은 지역 제어를 무시하는 가정용 제품을 구매하지 않는 것임

    • WiFi 비밀번호가 필수라면 제품을 반품할 것임
    • 보안과 프라이버시를 희생하고 싶다면 개인의 선택이지만, 기능 손실 없이 거부할 수 있는 옵션을 제공해야 함
    • RTSP를 지원하지 않는 도어벨 카메라는 구매하지 않을 것임

  • 공기청정기가 실내 공기질이 떨어질 때 작동을 강화하는 것은 IoT 기기, 앱, 무선 통신, 허브가 필요하지 않음

    • 공기청정기에 공기질 센서와 작은 LCD를 부착해 설정을 조정하면 충분함
    • 복도 조명이 자동으로 켜지는 것은 클라우드, HomeAssist, WiFi, Zigbee, 앱, 배터리 교체 없이 동작함
    • 지난 10년간 네트워크가 다운되어도 문제 없이 작동함

  • ESP32 기반 IoT 기기 판매자에게:

    • 스마트 홈 시스템과 통합하기 위해 스마트 기기를 업그레이드하는 것은 다른 인스턴스나 클라우드 서비스에 영향을 주지 않음
    • 민감한 제품 데이터는 모호화되거나 삭제됨

  • ESP32 기반 IoT 기기 소유자에게:

    • 스마트 홈 제품의 클라우드 제거 및 디버깅을 위한 오픈 소스 프로젝트를 생성하며 기술적 측면을 많이 배움
    • 이 게시물 작성에 많은 노력을 기울였으며, 형식에 대한 피드백을 받으면 좋겠음

  • 기기의 보드에서 어떤 핀이 연결되어 있는지 파악하고 ESPHome으로 완전히 플래시하고 사용자 정의 yaml 구성을 작성할 수 있을지 궁금함

  • IoT 기기 설계 팀에 있을 때마다 보안에 중점을 둔 엔지니어가 부트 보호를 담당했음

    • 펌웨어를 덤프하고 다시 플래시하는 것에 저항이 없었다는 것이 놀라움
    • 플래시 암호화를 하지 않는 이유가 궁금함

  • 기사에 대한 피드백:

    • 장치 키 사용에 대한 노트는 장치별로 키가 있는 것이 가장 명확함
    • 장치별 키 관리의 복잡성과 위험에 대한 피드백을 공유하고 싶음
    • 장치 암호화는 공장에서 많은 문제를 일으킬 수 있으며, 제품이 감당할 수 있다면 무시하는 것이 좋음

  • 표준화된 솔루션을 사용하지 않은 이유가 궁금함

    • 자체 솔루션을 만드는 것보다 비용 효율적일 것 같음

  • ESP32 IoT 기기에서 펌웨어 암호화를 사용하는 경우가 드물었음

    • 펌웨어를 읽을 수 없으면 인증서를 만들기 어려웠을 것임
    • 그러나 동시에 인상적임

  • 서비스 엔지니어들이 DTLS 같은 표준 프로토콜을 구현하지 않기로 결정한 것에 대한 의견

    • 각 기기가 고유한 개인 키를 가지고 있는지 확실하지 않음
    • 모든 기기가 동일한 펌웨어 개인 키를 공유하면 단일 기기를 역설계하여 다른 기기에 MITM 공격을 할 수 있음

  • 스마트 기기를 사용하는 사람들은 DD-WRT, OpenWrt, Tomato, Asuswrt-Merlin을 사용하여 기기를 개인 네트워크와 분리된 VLAN에 격리해야 함

  • 구매한 제품을 사용하기 위해 해킹할 필요가 없어야 함

    • "렌트 시킹" 경제는 규제되거나 금지되어야 함
답변달기