การแฮ็กอุปกรณ์สมาร์ตโฮม (2024)

 (jmswrnr.com)
1 คะแนน โดย GN⁺ 2025-04-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทำรีเวิร์สเอนจิเนียริง อุปกรณ์สมาร์ตโฮมที่ใช้ ESP32 และผสานเข้ากับ Home Assistant
  • วิเคราะห์ แอปมือถือ และยืนยันการเชื่อมต่อกับ เซิร์ฟเวอร์คลาวด์
  • ดักจับ ทราฟฟิกเครือข่าย เพื่อพยายาม ควบคุมอุปกรณ์
  • ดัมพ์และวิเคราะห์ แฟลช ESP32 เพื่อพยายาม แก้ไขเฟิร์มแวร์
  • วิเคราะห์ โครงสร้างแพ็กเก็ต เพื่อทำความเข้าใจ การเข้ารหัสและเช็กซัม

บทนำ

  • ช่วงนี้กำลังพยายามเชื่อมต่ออุปกรณ์ทั้งหมดเข้ากับ Home Assistant
  • มี เครื่องฟอกอากาศ รุ่นหนึ่งที่เชื่อมต่อได้เฉพาะผ่านแอปของตัวเอง จึงพยายามแฮ็กเพื่อผสานรวมเข้าไป
  • ชี้ให้เห็นปัญหาของผลิตภัณฑ์ที่พึ่งพา การเชื่อมต่ออินเทอร์เน็ต และ บัญชีคลาวด์

แผนการ

  • ยืนยันว่า แอปมือถือ เชื่อมต่อกับเซิร์ฟเวอร์คลาวด์และสามารถควบคุมจากระยะไกลได้
  • มองหาวิธีดักจับ ทราฟฟิกเครือข่าย เพื่อควบคุมอุปกรณ์

การวิเคราะห์แอปมือถือ

  • วิเคราะห์ แอป Android และยืนยันว่าพัฒนาด้วย React Native
  • พบว่ามีการเชื่อมต่อกับเซิร์ฟเวอร์คลาวด์ผ่าน WebSocket

การตรวจสอบเครือข่าย

  • ใช้ Pi-hole เพื่อตรวจสอบ DNS query และวิเคราะห์ทราฟฟิกด้วย Wireshark
  • ยืนยันการสื่อสารระหว่างอุปกรณ์กับเซิร์ฟเวอร์ผ่าน แพ็กเก็ต UDP

การวิเคราะห์แพ็กเก็ต

  • ใช้ UDP proxy เพื่อรีเลย์ทราฟฟิกระหว่างอุปกรณ์กับเซิร์ฟเวอร์คลาวด์
  • วิเคราะห์โครงสร้างแพ็กเก็ตผ่าน Wireshark และยืนยันความเป็นไปได้ของ การเข้ารหัส

การถอดแยกทางกายภาพ

  • ถอดแยกอุปกรณ์ที่ใช้ ESP32 และดัมพ์เฟิร์มแวร์จาก ชิปแฟลช
  • ใช้ esptool อ่านข้อมูลผ่าน การเชื่อมต่อแบบซีเรียล

การวิเคราะห์แฟลช

  • ใช้ esp32knife วิเคราะห์ข้อมูลแฟลชและตรวจสอบ ตารางพาร์ทิชัน
  • พบไฟล์สำคัญใน ระบบไฟล์ FAT

การวิเคราะห์สถิติเบื้องต้น

  • ใช้ Ghidra วิเคราะห์สตริงในเฟิร์มแวร์และยืนยันการใช้ ไลบรารีเข้ารหัส
  • ใช้ไลบรารี mbedtls เพื่อทำงานตามอัลกอริทึม ECDH และ HKDF

การแก้ไขเฟิร์มแวร์

  • ใช้ Ghidra ปิดใช้งานฟังก์ชัน CapSense และ แก้ไขเฟิร์มแวร์ จนบูตอุปกรณ์ได้
  • แก้ปัญหา เช็กซัม และแฟลชเฟิร์มแวร์ที่แก้ไขแล้วได้สำเร็จ

เฮดเดอร์ของแพ็กเก็ต

  • วิเคราะห์โครงสร้างของ เฮดเดอร์แพ็กเก็ต และยืนยัน หมายเลขซีเรียล กับ ตัวระบุข้อความ
  • ทำความเข้าใจรูปแบบของ คำขอจากไคลเอนต์ และ การตอบกลับจากเซิร์ฟเวอร์

เช็กซัมของแพ็กเก็ต

  • ตรวจสอบ CRC checksum เพื่อยืนยันความถูกต้องครบถ้วนของข้อมูลแพ็กเก็ต

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-04-16
ความเห็นจาก Hacker News

  • ทางออกระยะยาวคือไม่ซื้อผลิตภัณฑ์ใช้ในบ้านที่เพิกเฉยต่อการควบคุมภายในเครือข่ายท้องถิ่น

    • ถ้าจำเป็นต้องใส่รหัสผ่าน WiFi ก็จะส่งสินค้าคืน
    • หากยอมแลกความปลอดภัยและความเป็นส่วนตัวก็เป็นสิทธิ์ของแต่ละคน แต่ควรมีตัวเลือกให้ปฏิเสธได้โดยไม่เสียฟังก์ชันการใช้งาน
    • จะไม่ซื้อกล้องกริ่งประตูที่ไม่รองรับ RTSP

  • เครื่องฟอกอากาศที่เพิ่มการทำงานเมื่อคุณภาพอากาศภายในแย่ลง ไม่จำเป็นต้องมีอุปกรณ์ IoT, แอป, การสื่อสารไร้สาย หรือฮับ

    • แค่ติดตั้งเซ็นเซอร์วัดคุณภาพอากาศและจอ LCD ขนาดเล็กบนเครื่องฟอกอากาศเพื่อปรับการตั้งค่าก็เพียงพอแล้ว
    • ไฟทางเดินที่เปิดอัตโนมัติสามารถทำงานได้โดยไม่ต้องพึ่งคลาวด์, HomeAssist, WiFi, Zigbee, แอป หรือการเปลี่ยนแบตเตอรี่
    • ตลอด 10 ปีที่ผ่านมา แม้เครือข่ายล่มก็ยังทำงานได้โดยไม่มีปัญหา

  • ถึงผู้ขายอุปกรณ์ IoT ที่ใช้ ESP32:

    • การอัปเกรดอุปกรณ์อัจฉริยะเพื่อให้รวมเข้ากับระบบสมาร์ตโฮมได้ ไม่ได้ส่งผลกระทบต่ออินสแตนซ์อื่นหรือบริการคลาวด์
    • ข้อมูลผลิตภัณฑ์ที่อ่อนไหวถูกทำให้คลุมเครือหรือลบออกแล้ว

  • ถึงเจ้าของอุปกรณ์ IoT ที่ใช้ ESP32:

    • กำลังสร้างโปรเจกต์โอเพนซอร์สสำหรับถอดคลาวด์ออกจากผลิตภัณฑ์สมาร์ตโฮมและดีบัก พร้อมได้เรียนรู้ด้านเทคนิคมากมาย
    • ทุ่มเทความพยายามอย่างมากกับการเขียนโพสต์นี้ และอยากได้รับความเห็นเกี่ยวกับรูปแบบ

  • สงสัยว่าจะสามารถไล่ดูได้หรือไม่ว่าพินใดบนบอร์ดของอุปกรณ์ถูกเชื่อมต่ออยู่บ้าง แล้วแฟลชใหม่ทั้งหมดด้วย ESPHome พร้อมเขียนการตั้งค่า yaml แบบกำหนดเองได้หรือไม่

  • ทุกครั้งที่อยู่ในทีมออกแบบอุปกรณ์ IoT จะมีวิศวกรที่เน้นด้านความปลอดภัยดูแลการป้องกันบูต

    • น่าแปลกใจที่แทบไม่มีการต้านทานต่อการดัมป์เฟิร์มแวร์แล้วแฟลชกลับเข้าไปใหม่
    • สงสัยว่าทำไมถึงไม่ใช้การเข้ารหัสแฟลช

  • ข้อเสนอแนะต่อบทความ:

    • หมายเหตุเกี่ยวกับการใช้คีย์ของอุปกรณ์ ถ้าระบุให้ชัดว่าเป็นคีย์แยกตามอุปกรณ์จะเข้าใจง่ายที่สุด
    • อยากแบ่งปันความเห็นเรื่องความซับซ้อนและความเสี่ยงของการจัดการคีย์รายอุปกรณ์
    • การเข้ารหัสระดับอุปกรณ์อาจก่อปัญหามากในโรงงาน และถ้าผลิตภัณฑ์รับไหวก็ควรหลีกเลี่ยง

  • สงสัยว่าทำไมถึงไม่ใช้โซลูชันที่เป็นมาตรฐาน

    • ดูเหมือนว่าจะคุ้มค่ากว่าการสร้างโซลูชันขึ้นมาเอง

  • ไม่ค่อยพบการใช้การเข้ารหัสเฟิร์มแวร์ในอุปกรณ์ IoT ที่ใช้ ESP32

    • ถ้าอ่านเฟิร์มแวร์ไม่ได้ ก็คงสร้างใบรับรองได้ยาก
    • แต่ในขณะเดียวกันก็น่าประทับใจ

  • ความเห็นเกี่ยวกับการที่วิศวกรฝ่ายบริการตัดสินใจไม่ใช้โปรโตคอลมาตรฐานอย่าง DTLS

    • ไม่แน่ใจว่าแต่ละอุปกรณ์มี private key ที่เป็นเอกลักษณ์ของตัวเองหรือไม่
    • หากทุกอุปกรณ์ใช้ private key ของเฟิร์มแวร์ร่วมกัน ก็อาจย้อนวิศวกรรมอุปกรณ์เครื่องเดียวเพื่อทำการโจมตี MITM กับเครื่องอื่นได้

  • คนที่ใช้อุปกรณ์อัจฉริยะควรใช้ DD-WRT, OpenWrt, Tomato, Asuswrt-Merlin เพื่อแยกอุปกรณ์ไปไว้ใน VLAN ที่ถูกกักจากเครือข่ายส่วนตัว

  • ไม่ควรต้องแฮ็กผลิตภัณฑ์ที่ซื้อมาเพื่อจะใช้งานมันได้

    • เศรษฐกิจแบบ "rent-seeking" ควรถูกกำกับดูแลหรือห้ามไปเลย