ทดสอบเจาะระบบอุปกรณ์ IoT

อุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ตไม่ได้มีจุดที่ต้องดูแลแค่จุดเดียว แต่มีถึงห้าชั้น ทั้ง firmware ที่รันอยู่บนชิป, สัญญาณวิทยุและ traffic บนเครือข่ายที่มันคุยด้วย, บอร์ด hardware ที่มี debug port, companion app ที่ลูกค้าของคุณติดตั้ง และ cloud backend ที่มันติดต่อกลับไป ทั้งหมดนี้เป็นส่วนหนึ่งของผลิตภัณฑ์เดียวกัน และผู้โจมตีจะเลือกเจาะชั้นที่อ่อนที่สุด งาน pentest เว็บแอปมองแค่ชั้นเดียว network scan มองอีกชั้นหนึ่ง แต่ทั้งคู่ไม่ได้ไล่ตามเส้นทางจาก debug header ที่บัดกรีติดบอร์ด ไปยัง hardcoded secret ใน firmware แล้วต่อไปถึง cloud API ที่ key นั้นปลดล็อกได้ เส้นทางครบวงจรแบบนี้แหละคือจุดที่ผลิตภัณฑ์ IoT พังจริง และเป็นสิ่งที่การทดสอบเจาะระบบ IoT ถูกออกแบบมาให้เดินไล่ เราประเมินทั้งอุปกรณ์เทียบกับ OWASP IoT Top 10 และเพราะผลิตภัณฑ์ IoT ต่างกันมหาศาล เราจึงตกลงความลึกของแต่ละชั้นกับคุณก่อนเริ่มทดสอบ

ห้าชั้นที่เราทดสอบ

พื้นผิวการโจมตีของผลิตภัณฑ์ IoT กระจายอยู่ในห้าชั้น ไม่ใช่ทุกอุปกรณ์จะมีครบทั้งห้า บางตัวไม่มี debug port บางตัวไม่มี companion app เราจึงกำหนด scope แต่ละชั้นตามสิ่งที่อุปกรณ์ของคุณมีจริง

• Firmware — เราดึง firmware ออกมา ไม่ว่าจะด้วย flash memory dump, การเจาะผ่าน JTAG หรือแกะจาก update package แล้ว unpack และวิเคราะห์ file system จากนั้น reverse-engineer ตัว binary เพื่อหาสิ่งที่ผู้ผลิตคิดว่าจะไม่มีใครได้เห็น ทั้ง hardcoded secret และ credential, cryptography ที่อ่อนหรือเขียนขึ้นเอง, debug functionality ที่เผลอเปิดทิ้งไว้ และ backdoor การวิเคราะห์ firmware คือจุดที่สมมติฐานความเชื่อใจของอุปกรณ์ถูกเขียนลงไปจริง และมักเป็นจุดที่กลายเป็นผิดพลาดบ่อยที่สุด
• Network communication — เราดูว่าอุปกรณ์คุยกับอะไรบ้าง ทั้งกับ peer, ตัว controller และ backend นั่นหมายถึงการค้นหา open port, การทำ packet analysis กับ network protocol ที่ใช้อยู่ และการทดสอบเชิงรุก ทั้งการแก้ไขข้อความระหว่างทาง, การเจาะช่องโหว่ของ protocol, replay attack ที่ส่งคำสั่งซึ่งดักจับไว้ซ้ำ และในกรณีที่อุปกรณ์พึ่งการเชื่อมต่อไร้สาย ก็ทดสอบการโจมตีแบบ jamming ที่เล่นงาน availability คำถามคือผู้โจมตีที่อยู่บนเครือข่ายเดียวกัน หรืออยู่ในระยะสัญญาณวิทยุ จะอ่าน ปลอม หรือ replay สิ่งที่อุปกรณ์ส่งออกไปได้หรือไม่
• Hardware — เราตรวจตัวอุปกรณ์จริง ทั้ง interface ที่เปิดออกมา, debug port และ test point บนบอร์ดที่ตั้งใจไว้ให้โรงงานใช้ แต่กลับหลุดออกไปถึงมือผู้ใช้ การเข้าถึงทางกายภาพมักทำให้เกราะป้องกันอื่นพังพร้อมกันหมดในทีเดียว debug port เดียวอาจยอมส่ง firmware หรือ root shell ให้เลย เราจึงไล่ดูว่าผู้โจมตีที่มีอุปกรณ์อยู่ในมือเข้าถึงอะไรได้บ้าง รายละเอียดขึ้นอยู่กับบอร์ดของคุณ และเราตกลงกันตอน scoping
• Application — แทบทุกผลิตภัณฑ์ IoT มีซอฟต์แวร์ที่ผู้ใช้สัมผัสจริง ทั้ง companion app บนมือถือ และบ่อยครั้งก็มี web application ที่อุปกรณ์เปิดให้ใช้หรือต้องพึ่งพา เราทดสอบส่วนนี้ด้วย methodology เดียวกับงาน mobile application และ web application แบบเดี่ยว ๆ ของเรา รวมถึง reverse-engineer companion app เพื่อดูว่ามันยืนยันตัวตนอย่างไร เก็บอะไรไว้ และเชื่อใจอะไรบ้าง
• Cloud infrastructure — อุปกรณ์อัจฉริยะจะปลอดภัยได้แค่เท่ากับ cloud ที่มันไว้ใจ เราประเมิน backend ที่อุปกรณ์เชื่อมต่อ ทั้งตัว cloud environment และ API ที่อุปกรณ์กับแอปเรียกใช้ โดยใช้ methodology ของ cloud security assessment device API ที่อ่อน หรือ backend ที่ตั้งค่าผิด อาจเปิดโปงอุปกรณ์ทั้ง fleet พร้อมกันได้ ไม่ว่า hardware จะแข็งแรงแค่ไหนก็ตาม

ขั้นตอนการทำงาน

ทุกงานเดินผ่าน phase เดียวกัน คุณจึงรู้ตลอดว่าโครงการอยู่ตรงไหน และขั้นถัดไปคืออะไร

1. กำหนด scope อุปกรณ์ — เราวางแผนที่ของผลิตภัณฑ์ร่วมกับคุณ ทั้งว่ามีชั้นไหนบ้าง, มี debug port ให้ใช้งานไหม, มี companion app หรือ web interface ที่ host อยู่บนอุปกรณ์หรือเปล่า และพึ่ง cloud service กับ API ตัวไหนบ้าง เพราะผลิตภัณฑ์ IoT ต่างกันมาก ตรงนี้คือจุดที่เราตกลงความลึกของแต่ละชั้นตามอุปกรณ์และข้อจำกัดของคุณ พื้นผิวที่จะไม่ทดสอบถูกตัดสินตรงนี้ ไม่ใช่ไปเจอตอนจบ
2. วิเคราะห์ firmware และ hardware — เราได้ firmware มา (flash dump, JTAG หรือ update package) unpack file system แล้ว reverse-engineer หา secret, crypto ที่อ่อน และ backdoor พร้อมตรวจ interface และ debug port บนบอร์ดว่าเปิดเผยอะไรบ้าง
3. ทดสอบเครือข่ายและ protocol — เราค้นหา open port, ดักจับและวิเคราะห์ traffic ของอุปกรณ์ แล้วทดสอบ network protocol ที่ใช้อยู่เชิงรุก ทั้งการแก้ไขข้อความ, การเจาะช่องโหว่ protocol, replay และเมื่อเกี่ยวข้องก็ jamming เพื่อดูว่าผู้โจมตีบนเครือข่ายหรือในระยะสัญญาณวิทยุทำอะไรได้บ้าง
4. ทดสอบ application และ cloud — เราทดสอบ companion app และ web interface ที่มี พร้อมประเมิน cloud backend และ API ตาม methodology ฝั่ง mobile, web และ cloud ของเรา เพื่อให้ชั้นเหล่านี้ได้ความลึกเทียบเท่างานเฉพาะทาง
5. รายงานผล — เราเขียนทุก finding พร้อมผลกระทบ, Risk Level และเส้นทางทำซ้ำ เพื่อให้วิศวกรของคุณเห็นชัดว่าเราทำอะไรไปบ้าง
6. Retest — พอทีมของคุณแก้ปัญหาเสร็จ เรา retest เพื่อยืนยันว่าแต่ละจุดปิดได้จริง แล้วอัปเดตรายงานให้ตรงกับผลลัพธ์

สิ่งที่คุณจะได้รับ

ทุกรายงานมีอย่างน้อยเท่านี้

• Executive summary — ภาพความเสี่ยงระดับธุรกิจ เหมาะกับผู้บริหารและ auditor
• Finding จัดตาม Risk Level — ทุกประเด็นให้ระดับ Critical, High, Medium หรือ Low เพื่อจัดลำดับการแก้ได้อย่างเป็นกลาง
• Reproduction / POC ประกอบทุก finding — ขั้นตอน, คำสั่ง และ payload ที่ทำซ้ำปัญหาได้ ไม่ว่าจะอยู่ชั้นไหน วิศวกรของคุณไม่ต้องเดาว่าเราทำได้ยังไง
• คำแนะนำการแก้ไข — วิธีแก้ที่ใช้ได้จริง ผูกกับอุปกรณ์และสถาปัตยกรรมของคุณ ไม่ใช่ boilerplate จาก scanner
• Retest ยืนยันผล — finding ถูกตรวจซ้ำหลังคุณแก้ แล้วอัปเดตรายงานให้สะท้อนรายการที่ปิดไปแล้ว

ทีมและใบรับรอง

การทดสอบดำเนินการโดยทีมภายในของเราที่ถือใบรับรองระดับวงการ รวมถึง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ใบรับรองที่ได้มาจากการสอบภาคปฏิบัติอย่างเข้มข้น พื้นฐานสาย offensive security เดียวกับที่หนุนงานทดสอบ application และ network ของเรา คือสิ่งที่ทีมเอามาจับงาน reverse engineering firmware และวิเคราะห์ hardware ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

การทดสอบ IoT ของเราตั้งอยู่บน OWASP IoT Top 10 เพื่อให้ finding ตรงกับ framework ที่ทีมพัฒนาและ auditor ของคุณรู้จักอยู่แล้ว เพราะงาน IoT พาดผ่านหลายศาสตร์ ชั้น app และ cloud จึงอิงมาตรฐานเบื้องหลังงาน mobile application, web application และ cloud security assessment ของเราด้วย การทดสอบเจาะระบบบอกคุณว่าผลิตภัณฑ์พังตรงไหนในวันนี้ แต่เมื่ออุปกรณ์ต้องคงความปลอดภัยตลอดอายุการใช้งาน มันกลายเป็นโจทย์ความปลอดภัยที่กว้างขึ้น และทีม consulting ของเราช่วยคุณจัดการเรื่องนี้ได้