ชำแหละเทอร์มินัลผู้ใช้ Starlink

 (darknavy.org)
1 คะแนน โดย GN⁺ 2025-05-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เทอร์มินัลผู้ใช้ Starlink ของ SpaceX เป็นฮาร์ดแวร์หลักของการเชื่อมต่ออินเทอร์เน็ตผ่านดาวเทียมวงโคจรต่ำของโลก
  • เมื่อลองถอดแยกชิ้นส่วนอุปกรณ์ผู้ใช้ จะพบว่า RF front-end และ SoC ที่ออกแบบเอง เป็นชิ้นส่วนสำคัญ
  • จากการวิเคราะห์เฟิร์มแวร์ พบว่าซอฟต์แวร์แกนหลักส่วนใหญ่มี การประมวลผลเครือข่ายใน user space แบบ bypass kernel และฟังก์ชันการเข้ารหัสบางส่วน
  • ชิปความปลอดภัย STSAFE-A110 ทำหน้าที่เป็นรากความเชื่อถือเพิ่มเติมสำหรับการยืนยันตัวตน รวมถึงการเข้ารหัสข้อมูลและการให้ตัวระบุเฉพาะ
  • เทอร์มินัลนี้มีการตั้งค่า SSH public keys จำนวนมากและมีเครื่องมือบันทึกแพ็กเก็ตที่ชวนให้สงสัย แต่ยังไม่พบหลักฐานการละเมิดความเป็นส่วนตัวของผู้ใช้

ภาพรวม

  • Starlink คือ บริการอินเทอร์เน็ตผ่านดาวเทียมวงโคจรต่ำ ที่ให้บริการโดย SpaceX
  • ผู้ใช้เชื่อมต่อกับดาวเทียมใกล้เคียงผ่านเทอร์มินัล จากนั้นจึงเชื่อมสู่อินเทอร์เน็ตผ่านเกตเวย์ภาคพื้นดิน
  • ดาวเทียมรุ่นใหม่ใช้ ลิงก์เลเซอร์ เพื่อสื่อสารกันระหว่างดาวเทียม ซึ่งช่วยเพิ่มทั้งการครอบคลุมทั่วโลกและประสิทธิภาพ
  • แม้ไม่มีเกตเวย์ในพื้นที่ เช่นในกรณีของยูเครน ก็ยังสามารถให้อุปกรณ์ Starlink เชื่อมต่ออินเทอร์เน็ตผ่านเกตเวย์ของประเทศข้างเคียงได้
  • บทความนี้สรุปการตรวจสอบเชิงลึกของเทอร์มินัลผู้ใช้ Starlink โดย DARKNAVY แบบย่อ

การวิเคราะห์ฮาร์ดแวร์

  • เทอร์มินัลผู้ใช้ Starlink หนึ่งชุดประกอบด้วยสองส่วนคือ เราเตอร์ และ เสาอากาศ (UTA)
  • DARKNAVY ซื้อเทอร์มินัล Standard Actuated (Rev3, GenV2) ในสิงคโปร์และ ถอดแยกเสาอากาศ
  • ผลการถอดแยกพบว่า ชิป RF front-end (ส่วนใหญ่ผลิตโดย STMicroelectronics) กินพื้นที่บนบอร์ดไปมาก
  • ในส่วนควบคุมหลักมี ST SoC แบบคัสตอมเฉพาะของ SpaceX (quad-core Cortex-A53) ติดตั้งอยู่ แต่ข้อมูลดาต้าชีตไม่เปิดเผยสู่สาธารณะ
  • ในงาน Black Hat USA 2022 ดร. Lennert Wouters จาก KU Leuven ได้นำเสนอกรณีการแฮ็กเทอร์มินัลรุ่นแรก (GenV1) สำเร็จ และหลังจากนั้น SpaceX ได้ปิดใช้งาน UART debug interface ผ่านการอัปเดตเฟิร์มแวร์
  • อย่างไรก็ตาม เคยมีการข้ามกลไกความปลอดภัยสำเร็จอีกครั้งด้วยวิธีเพิ่มเติม

การดึงและวิเคราะห์เฟิร์มแวร์

  • DARKNAVY ดัมป์เฟิร์มแวร์โดยตรงจาก ชิป eMMC
  • เนื่องจากบอร์ด Rev3 ไม่มีขา debug สำหรับ eMMC แยกต่างหาก จึงใช้วิธี ถอด eMMC ออกแล้วใช้โปรแกรมเมอร์ดึงข้อมูล
  • เฟิร์มแวร์ส่วนใหญ่ไม่ได้เข้ารหัส ทำให้มองเห็น boot chain (ยกเว้น BootROM), kernel และบางส่วนของไฟล์ซิสเต็ม
  • หลัง kernel บูตแล้ว จะคลายสภาพแวดล้อมรันไทม์ไปที่ /sx/local/runtime เพื่อใช้งาน
  • ใน bin มีไฟล์ปฏิบัติการของซอฟต์แวร์ Starlink, ใน dat มีไฟล์ตั้งค่า และใน revision_info มีข้อมูลเวอร์ชัน
  • โปรแกรมสื่อสารหลัก user_terminal_frontend พัฒนาด้วย Go ส่วนที่เหลือส่วนใหญ่เป็นไบนารี C++ แบบ static ที่ไม่มีสัญลักษณ์
  • สถาปัตยกรรม network stack มีลักษณะคล้าย DPDK โดย bypass kernel และให้โปรแกรมใน user space เป็นผู้จัดการการประมวลผลแพ็กเก็ต
  • Linux kernel ใช้หลัก ๆ สำหรับไดรเวอร์ฮาร์ดแวร์และการจัดการโปรเซส
  • ซอฟต์แวร์บางส่วนมีฟังก์ชันที่เดิมออกแบบมาเพื่อ ดาวเทียมหรือเกตเวย์
  • ตอนบูตอุปกรณ์จะระบุประเภทจากอุปกรณ์ต่อพ่วงฮาร์ดแวร์ แล้วโหลดเฉพาะลอจิกที่เกี่ยวข้องมาใช้

การอีมูเลชัน

  • เพื่อการวิเคราะห์อย่างต่อเนื่อง มีการสร้าง สภาพแวดล้อมอีมูเลชันเฟิร์มแวร์ Rev3 บนพื้นฐาน QEMU
  • ในสภาพแวดล้อมนี้ สามารถรันและดีบักบริการภายนอกบางส่วน เช่น httpd, WebSocket, gRPC ได้สำเร็จ
  • ทำให้สามารถติดตามหลักการทำงานของไฟล์ปฏิบัติการและบริการสำคัญได้

ชิปความปลอดภัย

  • นอกเหนือจาก SoC หลัก ยังมีชิปความปลอดภัย STSAFE-A110 ซึ่งอ้างว่าผ่านการรับรอง CC EAL5+
  • ชิปดังกล่าวสามารถซื้อได้ภายใต้ NDA และโปรแกรม stsafe_cli ในเฟิร์มแวร์ใช้โต้ตอบกับชิปนี้
  • จากการวิเคราะห์ พบว่าฟังก์ชันของชิป STSAFE ได้แก่ การกำหนด UUID เฉพาะเครื่อง, การจัดการใบรับรองกุญแจสาธารณะ (stsafe_leaf.pem), การสร้าง symmetric key เป็นต้น
  • ชิปนี้เป็น รากความเชื่อถือเพิ่มเติม ที่แยกจาก secure boot ของ SoC และสอดคล้องกับแนวทางการออกแบบความปลอดภัยของระบบฝังตัวสมัยใหม่

Easter egg: Elon กำลังจับตาดูคุณอยู่หรือไม่?

  • ระหว่างการวิเคราะห์พบโปรแกรม Ethernet Data Recorder ทำให้เกิดข้อสงสัยเรื่อง ความเป็นไปได้ของ backdoor
  • โปรแกรมนี้ดูเหมือนมีฟังก์ชันบันทึกแพ็กเก็ต และภายในใช้ กลไกคล้าย pcap_filter เพื่อจับแพ็กเก็ตบางประเภท
  • จากกฎที่พบ จะเห็นว่าเป้าหมายการดักจับส่วนใหญ่คือ แพ็กเก็ต UDP ที่เกี่ยวข้องกับ telemetry ของดาวเทียม
  • ทราฟฟิกที่จับได้จะถูกเข้ารหัสและเก็บไว้ด้วย hardware key ของ SoC
  • จนถึงขณะนี้ยังไม่พบหลักฐานว่ามีการเก็บข้อมูลด้านความเป็นส่วนตัวของผู้ใช้
  • ในกระบวนการเริ่มต้นระบบ หากอุปกรณ์ถูกระบุว่าเป็นเทอร์มินัลผู้ใช้ จะมีการบันทึก SSH public key จำนวน 41 รายการลงใน /root/.ssh/authorized_keys และพอร์ต 22 จะเปิดสู่เครือข่ายโลคัลตลอดเวลา
  • การที่มีการลงทะเบียน public key ที่ไม่ทราบที่มาจำนวนมากในผลิตภัณฑ์เชิงพาณิชย์ถือเป็นประเด็นที่น่าสนใจ

บทสรุปและแนวโน้ม

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

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

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

 
GN⁺ 2025-05-11
ความเห็นจาก Hacker News
  • ระหว่างรีเซ็ตอุปกรณ์ พบว่าสคริปต์เริ่มต้นจะเขียน SSH public key จำนวน 41 คีย์ลงในไฟล์ /root/.ssh/authorized_keys โดยอัตโนมัติ หากระบบตรวจพบว่าเป็น user terminal และพอร์ต 22 ก็เปิดไว้กับเครือข่ายภายในเสมอ ทำให้อดสงสัยไม่ได้ว่าการใส่คีย์มากถึง 41 คีย์มีความหมายอะไร และสุดท้ายก็ชวนให้ตั้งคำถามว่า ใครบ้างที่ไม่มีสิทธิ์ root access บน user terminal ที่ “คุณเป็นเจ้าของ”
    • อาจจะเป็นคุณเอง ถ้าคิดแบบจริงจังขึ้นมา มันก็ไม่ได้ต่างจากการที่ ISP วางระบบ remote management ไว้ในเราเตอร์ที่ให้ลูกค้ามากนัก ต่อให้ SpaceX ไม่มีสิทธิ์เข้าถึง user terminal โดยตรง ก็ยังสามารถมอนิเตอร์ทราฟฟิกจากฝั่งดาวเทียมหรือสถานีภาคพื้นดินได้อยู่ดี
    • ช่วงนี้ก็ชวนสงสัยว่าใครน่าจะเป็นคนที่เหมาะที่สุดในการตรวจดูว่ามี SSH key ที่ติดตามตัวตนได้สำหรับผู้ที่เกี่ยวข้องกับงานรัฐบาลพิเศษหรือไม่ แถมช่วงนี้ก็มีข้อมูลรั่วดี ๆ ออกมาด้วย
    • คีย์ทั้ง 41 คีย์อาจเป็นเพียง server instance เดียวกันใน 41 รีเจียนก็ได้ Starlink เป็นบริการระดับโลกอยู่แล้ว จึงไม่ใช่เรื่องที่น่ากังวลเป็นพิเศษ ถ้า 41 อินสแตนซ์นั้นแชร์คีย์เดียวกันต่างหากที่น่ากังวลกว่า
    • ที่บริษัทปัจจุบัน จะปล่อยเฉพาะ developer SSH key ไปยังเฟิร์มแวร์ DEV หรือ QA เท่านั้น ส่วน production image หลังเซ็นแล้วจะปิด SSH ไปเลย สำหรับการวินิจฉัยระยะไกลบนโปรดักชันจะใช้ซอฟต์แวร์แยกต่างหาก และก็ยังถูกควบคุมด้วยสิทธิ์การเข้าถึงและขั้นตอนอนุมัติจาก DevOps ด้วย เลยรู้สึกแปลกใจกับแนวทางที่ SpaceX เลือก
    • ฉันเป็นผู้ใช้คนเดียว แต่ใน authorized_keys ก็ยังมีอยู่ 25 บรรทัด เป็นคีย์จาก yubikey หลายตัวของแล็ปท็อป คีย์จาก iPad และ iPhone รวมถึงคีย์ secure enclave ของ Mac ปนกันไป เลยนึกภาพว่า Starlink น่าจะมีผู้ดูแลระบบเพิ่มอีกอย่างน้อย 1-2 คน ดังนั้น public key 100 คีย์ก็ไม่ได้ดูแปลกอะไรนัก
    • ตรงกันข้าม นี่อาจเป็นทางเลือกที่ธรรมดากว่าที่คิดและดีในเชิงความปลอดภัยด้วยซ้ำ แทนที่อุปกรณ์นับล้านเครื่องจะใช้คีย์เดียวกันทั้งหมดหรือใช้เพียงไม่กี่คีย์ การแยกใช้หลายคีย์ตาม serial number หรือช่วงเวลาการผลิตย่อมดีกว่า private key ก็อาจถูกใช้เพื่อดูแลอุปกรณ์เพียงกลุ่มเล็ก ๆ และยังสามารถแยกการจัดการคีย์ออกจากกันได้ด้วย
    • เดาว่าจะเข้าถึงจากภายนอกด้วยคีย์ได้ก็ต่อเมื่อ terminal นี้เชื่อมต่ออินเทอร์เน็ตผ่านเครือข่ายท้องถิ่นด้วยเท่านั้น และก็สงสัยเหมือนกันว่าการเชื่อมต่อ SSH จะวิ่งผ่านเครือข่ายดาวเทียมอย่างไร รวมถึงสงสัยว่า Starlink ใช้ NAT และโครงสร้างเครือข่ายแบบไหน
  • แชร์ลิงก์บทความก่อนหน้านี้เกี่ยวกับการแกะ Starlink user terminal ในหัวข้อคล้ายกัน
  • คิดว่าน่าจะสนุกดีถ้านำ public key ทั้ง 41 คีย์มาเปิดเผย แล้วลองดูว่านักพัฒนาคนไหนเป็นผู้ใช้
  • แชร์ลิงก์ archive ของบล็อกโพสต์เกี่ยวกับ Starlink
  • ขอให้ผู้เขียนแก้คำสะกดผิดในชื่อเรื่อง (ternimal)
    • มีการแซวอย่างมีไหวพริบว่านี่เป็นตัวอย่างคลาสสิกของปัญหา keming (ระยะห่างตัวอักษรไม่สมดุล)
  • รู้สึกประหลาดใจที่แพ็กเก็ตทั้งหมดถูกประมวลผลใน userspace หากเป็นทราฟฟิก 1Gbps (อิง UDP ขนาด 100 ไบต์) ก็จะเท่ากับหนึ่งล้านแพ็กเก็ตต่อวินาที CPU 1GHz จะมีงบเพียง 1000 cycles ต่อแพ็กเก็ต ตามทฤษฎีอาจเป็นไปได้ แต่ไม่ง่ายเลย เป็นระดับที่วิศวกรต้องเขียน assembly ตรง ๆ พร้อมงัดทุกเทคนิคออกมาใช้
    • ตามงานวิจัย ระบุว่าโครงสร้าง network stack ดูคล้าย DPDK และหัวใจสำคัญคือการจัดการแพ็กเก็ตแบบ kernel bypass ในทางปฏิบัติซอฟต์แวร์อาจจัดการเฉพาะแพ็กเก็ตแรก แล้วหลังจาก session ถูกสร้างขึ้นจึงส่งต่อให้ฮาร์ดแวร์จัดการต่อได้ บางแพตเทิร์นอาจยังคงให้ซอฟต์แวร์จัดการต่อไปด้วย เคยเจอแนวทางคล้ายกันนี้ในเราเตอร์เคเบิลโมเด็มตระกูล Intel Puma รุ่นเก่า
    • สำหรับการ forwarding แบบ DPDK style การคัดลอกบัฟเฟอร์ลดลง จึงอาจเร็วกว่าเสียอีก Starlink อยู่ที่ระดับประมาณ 25-200Mbps และเมื่อขนาดแพ็กเก็ตเฉลี่ยใหญ่กว่าราว 7-8 เท่า ก็จะอยู่ที่ประมาณ 36,000 แพ็กเก็ตต่อวินาที ซึ่งเป็นปริมาณที่ CPU 1GHz พอรับมือได้
    • สงสัยว่าทำไมการประมวลผลแพ็กเก็ตใน userspace ถึงจะมีเหตุผลให้ด้อยประสิทธิภาพกว่าการทำใน kernel เพราะถ้าแมป hardware queue เข้าสู่ userspace ได้ การแบ่งระหว่าง kernel-userspace ก็แทบไม่สำคัญแล้ว
    • ในกรณีของ Starlink น่าจะใช้ MTU ปกติขนาด 1500 ไบต์ มากกว่าจะเป็น UDP packet ขนาด 100 ไบต์
    • เมื่อประมวลผลแพ็กเก็ตใน userspace จะลด memory copy ที่ไม่จำเป็นลงได้มาก จึงเร็วกว่าอย่างชัดเจน
  • แสดงความสงสัยว่าควรเริ่มต้น reverse engineering อุปกรณ์แบบนี้อย่างไร เพราะ reverse engineering เป็นเรื่องยาก และตัวอย่างจำนวนมากก็มักเก่าหรือแพงจนตามทำได้ยาก
    • ต้องเรียนรู้ hardware engineering ก่อน เพราะถ้าไม่รู้หน้าที่หรือคุณลักษณะของชิ้นส่วนต่าง ๆ การทำ reverse engineering เองก็ยากมาก
    • อย่างแรกคือต้องซื้อสินค้ามาแล้วแกะ อย่างที่สองคือต้องคิดว่าจะเจาะเข้าไปอย่างไร อย่างที่สามคือลองทำจริง อย่างที่สี่คือสิ้นหวังเมื่อพบว่าพังไปแล้ว โดยปกติมักเริ่มเข้าผ่านพอร์ต UART แต่ดูเหมือน Starlink จะไม่มี จึงมีกรณีศึกษาที่ถอดชิปหน่วยความจำ eMMC ออกมาวิเคราะห์แทน
  • ถามว่ามีเอกสารอ้างอิงหรือโซลูชันพร้อมใช้สำหรับการจำลองเฟิร์มแวร์ในสภาพแวดล้อม emulation บน QEMU โดยเชื่อมต่อกับอุปกรณ์ภายนอก เช่น GPS หรือไม่
    • ยกตัวอย่างว่าใน Android QEMU fork มีการ emulation ฮาร์ดแวร์หลากหลายชนิดและ GUI interface เช่น OpenGL, GPS, GSM และเซ็นเซอร์ต่าง ๆ
  • อยากเรียนรู้วิธีปกป้องเฟิร์มแวร์จาก reverse engineering และสงสัยว่ามีเอกสารเบื้องต้นเกี่ยวกับเทคนิคที่ SpaceX ใช้หรือไม่
    • ขั้นแรกคือมาตรการอย่างการเข้ารหัสเฟิร์มแวร์ และดูเหมือนว่า SpaceX เองก็ไม่ได้ป้องกันเชิงรุกเป็นพิเศษ แต่ค่อนข้างแก้เป็นจุด ๆ เมื่อมีคนค้นพบปัญหา แต่ก่อนยังมี debug pin อยู่ด้วย
    • ผลิตภัณฑ์จำนวนมากที่เคยใช้งานมักมีงานด้านเฟิร์มแวร์ที่ยังไม่สมบูรณ์นัก นอกเหนือจากเหตุผลด้านความปลอดภัยแล้ว ก็อยากให้เลิกล็อกทุกอย่างโดยไม่จำเป็นและเอาทรัพยากรไปใช้ในทางที่เป็นประโยชน์กับทุกคนมากกว่า ถ้า power user ปรับแต่งอุปกรณ์เองได้ กลับอาจเป็นข้อดีด้วยซ้ำ ถ้าไม่ได้มีความเสี่ยงการละเมิดร้ายแรงจริง ๆ ก็ไม่อยากให้เสียเวลาไปกับเรื่องไม่จำเป็นแบบนี้ โลกที่เราต้องคอยแฮ็กอุปกรณ์ต่าง ๆ ให้ตรงกับความต้องการของตัวเองอยู่เสมอนั้นน่าเสียดายและบางทีก็ชวนหดหู่
    • อย่างน้อยที่สุดก็ควรเข้ารหัส root filesystem โดยใช้ข้อมูลลับจาก secure chip จริงที่ขโมยหรือดึงออกมาได้ยาก หากต้องการยกระดับความปลอดภัยขึ้นอีก ก็สามารถใช้ ARM TrustZone เพื่อแยกงานอ่อนไหวอย่าง bootloader, การถอดรหัส, image signing ออกไปได้ การที่ filesystem ถูก dump ออกมาได้ง่าย ๆ เองก็หมายความว่า SpaceX ไม่ได้ใช้มาตรการป้องกันที่มีผลในทางปฏิบัติ มีเพียง bootloader ที่ได้รับการปกป้อง ส่วนอย่างอื่นเปิดโล่ง
  • รู้สึกสงสัยว่าอุปกรณ์นี้อาจใช้ codebase เดียวกับจรวดหรือไม่ และรู้สึกว่าน่าสนใจดี
    • ส่วนที่รู้สึกว่าเท่ยิ่งกว่าคือมันอาจแชร์ codebase กับตัวดาวเทียมหรืออย่างน้อยก็กับตัวจำลองดาวเทียม เพราะต้องส่ง telemetry หลายประเภท
    • ความจริงแล้วมันใช้ OpenWRT เป็นฐาน