Mổ xẻ thiết bị đầu cuối người dùng Starlink

 (darknavy.org)
1 điểm bởi GN⁺ 2025-05-11 | 1 bình luận | Chia sẻ qua WhatsApp
  • DARKNAVY đã tháo rời ăng-ten của Starlink Standard Actuated mua tại Singapore để phân tích sơ bộ phần cứng, firmware, chip bảo mật và khả năng giả lập
  • Phần lớn PCB của ăng-ten do RF front-end của STMicroelectronics chiếm chỗ, còn khối điều khiển cốt lõi tập trung ở một phía của bo mạch, cho thấy cấu trúc tương tự thiết bị IoT thông thường
  • Firmware Rev3 được dump bằng cách tháo eMMC ra, và phần lớn ở trạng thái không mã hóa, nên có thể xác nhận một phần chuỗi khởi động, kernel, một phần hệ thống tệp và cấu hình runtime
  • Phần mềm được trích xuất không chỉ bao gồm chức năng cho thiết bị đầu cuối người dùng mà còn có vẻ chứa cả chức năng dành cho vệ tinh và gateway mặt đất; khi khởi động, hệ thống dường như nhận diện loại thiết bị thông qua thiết bị ngoại vi phần cứng
  • Ethernet Data Recorder ghi lại các gói liên quan đến telemetry của vệ tinh và mã hóa bằng khóa phần cứng, nhưng trên UTA có 41 khóa công khai SSH được tự động đăng ký và cổng 22 luôn mở trên mạng nội bộ

Thiết bị đầu cuối người dùng Starlink và phạm vi phân tích

  • Starlink là dịch vụ internet vệ tinh quỹ đạo thấp của SpaceX; người dùng kết nối tới vệ tinh quỹ đạo gần Trái Đất thông qua thiết bị đầu cuối người dùng, rồi đi qua gateway mặt đất để truy cập Internet
  • Các thế hệ vệ tinh mới dần được bổ sung liên kết laser, cho phép một số vệ tinh giao tiếp trực tiếp với nhau
    • Giảm phụ thuộc vào trạm mặt đất, tăng hiệu quả truyền dẫn và cải thiện độ phủ toàn cầu
    • Ngay cả tại chiến trường Ukraine, nơi không có trạm mặt đất địa phương, thiết bị đầu cuối Starlink vẫn có thể gián tiếp kết nối tới gateway ở các nước lân cận thông qua liên kết giữa các vệ tinh
  • Nghiên cứu của DARKNAVY không tập trung vào toàn bộ thiết bị đầu cuối người dùng Starlink mà vào thành phần ăng-ten là User Terminal Antenna, UTA
    • Thiết bị mục tiêu là Starlink Standard Actuated mua tại Singapore
    • Còn được gọi là Rev3 hoặc GenV2

Kết quả tháo rời phần cứng

  • Một thiết bị đầu cuối người dùng Starlink hoàn chỉnh gồm hai phần: router và ăng-ten
  • PCB của UTA được tháo rời có kích thước gần tương đương với vỏ ngoài
    • Phần lớn bo mạch do các chip RF front-end do STMicroelectronics sản xuất chiếm chỗ
    • Các linh kiện điều khiển cốt lõi chủ yếu tập trung ở một phía của PCB
  • Ngoại trừ ăng-ten RF, thiết kế tổng thể của vùng lõi UTA khá giống với một thiết bị IoT thông thường
  • SoC chính là quad-core Cortex-A53 do ST tùy biến riêng cho SpaceX
    • Hiện phần cứng và datasheet của chip này là thông tin mật và chưa được công khai
  • Tại Black Hat USA 2022, TS. Lennert Wouters của KU Leuven đã trình diễn tấn công fault injection vào ăng-ten Starlink thế hệ đầu GenV1 để giành được root shell của thiết bị
    • Sau đó SpaceX đã vô hiệu hóa giao diện debug UART trên PCB thông qua cập nhật firmware để tăng khả năng chống lại kiểu tấn công fault
    • Wouters tiếp tục cải tiến cách tiếp cận và xâm nhập thành công một lần nữa

Trích xuất firmware và cấu trúc phần mềm

  • Để phân tích UTA sâu hơn, DARKNAVY đã dump trực tiếp firmware từ chip eMMC
    • Bo Rev3 không có chân debug eMMC rõ ràng
    • Họ phải tháo chip eMMC khỏi PCB rồi dùng programmer để đọc
  • Phần lớn firmware được trích xuất ở trạng thái không mã hóa
    • Chuỗi khởi động ngoại trừ BootROM
    • Kernel
    • Vùng không mã hóa của hệ thống tệp
  • Sau khi kernel khởi động, phần lớn môi trường runtime được đọc từ eMMC và bung ra thư mục /sx/local/runtime
  • Trong cấu trúc runtime, bin chứa các tệp thực thi cần cho software stack của Starlink, dat lưu tệp cấu hình, còn revision_info ghi lại phiên bản phần mềm và phần cứng hiện tại
  • user_terminal_frontend, thành phần xử lý giao tiếp với người dùng bên ngoài, được viết bằng Go; phần lớn các chương trình còn lại là tệp thực thi C++ biên dịch tĩnh không có symbol
  • Theo phân tích ban đầu dựa trên các nghiên cứu trước đó, kiến trúc network stack có phần tương tự DPDK
    • Chủ yếu các chương trình C++ trong user space xử lý gói mạng bằng cách bỏ qua kernel
    • Linux kernel chủ yếu đảm nhiệm driver phần cứng cơ bản và quản lý tiến trình
  • Phần mềm cốt lõi trích xuất từ UTA cũng bao gồm những chức năng có vẻ thuộc về vệ tinh hoặc gateway mặt đất
    • Qua reverse engineering ban đầu, hệ thống nhận diện loại thiết bị dựa trên thiết bị ngoại vi phần cứng trong quá trình khởi động
    • Sau đó nạp và thực thi logic phù hợp với loại thiết bị đó

Giả lập dựa trên QEMU

  • Để thuận tiện cho việc phân tích UTA liên tục, DARKNAVY đã xây dựng môi trường giả lập dựa trên QEMU cho firmware Rev3
  • Trong môi trường này, họ đã thành công trong việc chạy và debug một số phần mềm tương tác với thực thể bên ngoài
    • httpd
    • WebSocket
    • gRPC service

Chip bảo mật STSAFE-A110

  • Ngoài SoC chính, UTA còn được trang bị STSAFE-A110, một chip bảo mật chuyên dụng
    • Chip này tuyên bố đạt mức bảo mật CC EAL5+
    • Khác với SoC tùy biến, nó có thể được mua hợp pháp theo NDA
  • Trong firmware của UTA, chương trình user space tên stsafe_cli xử lý việc tương tác với chip này
  • Kết quả reverse engineering cho thấy STSAFE dường như chủ yếu cung cấp các chức năng sau
    • Định danh duy nhất của từng thiết bị, UUID
    • Quản lý chứng chỉ khóa công khai stsafe_leaf.pem, được cho là dùng cho xác thực liên lạc vệ tinh
    • Suy dẫn khóa mã hóa đối xứng cho truyền dữ liệu người dùng
  • Chip này đóng vai trò root of trust bổ sung, độc lập với cơ chế secure boot của SoC, phù hợp với cách thiết kế bảo mật nhúng hiện đại

Ethernet Data Recorder và khóa SSH

  • Trong quá trình phân tích, họ phát hiện một chương trình tên Ethernet Data Recorder; nếu chỉ nhìn tên và chức năng, nó có thể bị nghi là backdoor ghi lại dữ liệu người dùng
  • Kiểm tra chi tiết cho thấy chương trình này ghi lại một số gói mạng cụ thể bằng cơ chế tương tự pcap_filter
    • Ví dụ quy tắc capture bao gồm điều kiện udp and dst port 10017 cùng một số host multicast đích cụ thể
    • Dựa trên các manh mối khác trong firmware, các gói này liên quan đến telemetry của vệ tinh
  • Toàn bộ lưu lượng bị capture đều được mã hóa bằng khóa phần cứng fuse vào SoC
  • Với thông tin hiện có, khó có thể kết luận tính năng này đang thu thập dữ liệu riêng tư của người dùng
  • Trong quá trình khởi tạo thiết bị, nếu hệ thống tự nhận diện là thiết bị đầu cuối người dùng, script khởi tạo sẽ tự động ghi 41 khóa công khai SSH vào /root/.ssh/authorized_keys
    • Cổng 22 của UTA luôn mở trên mạng nội bộ
    • Việc một sản phẩm dành cho người dùng có quá nhiều khóa đăng nhập không rõ nguồn gốc như vậy là điều khá đáng chú ý

Bối cảnh bảo mật của hệ thống internet vệ tinh

  • Khi công nghệ vệ tinh tiếp tục phát triển và được ứng dụng trong nhiều ngành, từng thành phần của Starlink và các hệ thống internet vệ tinh khác có thể trở thành khu vực quan trọng cho các chiến dịch tấn công và phòng thủ trong tương lai
  • Trong bảo mật không gian, nhà phát triển và hacker không chỉ phải đối mặt với lĩnh vực số mà còn với những ràng buộc của vật lý không gian
    • Chỉ một thao tác sai cũng có thể khiến họ mất liên lạc với mục tiêu vĩnh viễn

Tài liệu tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-11
Các ý kiến trên Hacker News

  • Việc khi khởi tạo, nếu được nhận diện là thiết bị đầu cuối người dùng thì tự động thêm 41 khóa công khai SSH vào /root/.ssh/authorized_keys khiến tôi càng tò mò hơn rằng ai mới là người không có quyền truy cập root vào thiết bị đầu cuối “của tôi”

    • Có lẽ là chính người dùng
      Nói nghiêm túc hơn, việc này khác nhiều lắm không so với chuyện đặt hệ thống quản trị từ xa trên router do ISP cung cấp? Ngay cả khi SpaceX không thể truy cập trực tiếp vào thiết bị đầu cuối người dùng, họ vẫn có thể bắt lưu lượng từ vệ tinh hoặc trạm mặt đất
    • Tôi tự hỏi ai là người phù hợp nhất để liên hệ một số khóa này với những cá nhân gần đây có tham gia các công việc đặc biệt của chính phủ. Cũng đã có vài dữ liệu rò rỉ khá tốt
    • 41 khóa chưa chắc đã là chuyện đáng lo. Có thể là các instance máy chủ ở 41 khu vực mỗi cái có khóa riêng, và Starlink là dịch vụ toàn cầu nên cũng tự nhiên
      Ngược lại, nếu 41 instance đó dùng chung một khóa thì điều đó có lẽ mới đáng lo hơn
    • authorized_keys của tôi, chỉ là một người dùng cá nhân, cũng có 25 dòng. Có YubiKey khác nhau cho từng laptop, khóa của iPad và iPhone, khóa Secure Enclave trên Mac
      Starlink hẳn cũng có nhiều quản trị viên hệ thống hơn 1–2 người, nên khoảng 100 khóa công khai tôi vẫn thấy hợp lý
    • Lựa chọn này thật sự khó hiểu. Ở chỗ làm hiện tại, chúng tôi chỉ triển khai khóa SSH của developer lên thiết bị chạy firmware DEV hoặc QA, còn image production được ký và SSH bị tắt hoàn toàn
      Có phần mềm truy cập từ xa riêng để chẩn đoán vấn đề kỹ thuật trên thiết bị production và có thể mở REPL, nhưng bị chặn bằng kiểm soát truy cập và phê duyệt DevOps

  • Thảo luận trước đây về một bài gửi tương tự: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (ngày 2 tháng 12 năm 2020 — 158 điểm, 138 bình luận)

  • Nếu đưa lên 41 khóa công khai, có lẽ có thể xác định được developer nào đang dùng chúng

  • https://web.archive.org/www.darknavy.org/blog/a_first_glimps...

  • Điều đáng ngạc nhiên là mọi gói tin đều được xử lý trong user space
    Nếu xử lý lưu lượng 1Gbps bằng các gói UDP 100 byte thì phải xử lý 1 triệu gói mỗi giây. Với CPU 1GHz, mỗi gói chỉ có 1000 chu kỳ
    Có thể làm được, nhưng sẽ không dễ trừ khi các kỹ sư thích viết tay assembly và suy nghĩ đủ loại kỹ thuật bảng tra cứu

    • Thường thì phần mềm xử lý các gói ban đầu, và khi endpoint đã được thiết lập thì các luồng sau đó được chuyển sang phần cứng. Một số mẫu nhất định cũng luôn được xử lý bằng phần mềm
      Phần mềm có thể là kernel đã được vá, hoặc có thể là kiểu bypass kernel như XDP. Đây là suy đoán dựa trên kinh nghiệm từng động chạm ở mức ngoại vi đến DPDK hoặc thứ tương tự trên router/gateway modem cáp Intel Puma
    • Trong xử lý chuyển tiếp, cách tiếp cận kiểu DPDK có thể nhanh hơn nhờ giảm sao chép buffer
      Starlink khoảng 25–200Mbps và kích thước gói trung bình cũng lớn hơn 7–8 lần, nên nhiều lắm cũng chỉ khoảng 36.000 gói/giây, mức khá chịu được ngay cả ở 1GHz
    • Tôi không hiểu vì sao nó nhất thiết phải kém hiệu quả hơn xử lý gói trong kernel. Có cách ánh xạ hàng đợi phần cứng vào user space, và bài viết cũng nói hệ thống có kiến trúc giống DPDK
      Đến mức đó rồi thì tôi không rõ việc mã polling nằm trong kernel có gì quan trọng
    • 100 byte sao? Starlink dùng MTU 1500 byte thông thường
    • Xử lý trong user space có thể tránh thêm một lần memcpy, nên nhanh hơn nhiều

  • Mong họ sửa lỗi chính tả trong tiêu đề. Hiện đang là “Ternimal”

    • Đây là vấn đề keming điển hình

  • Tôi tò mò không biết bắt đầu làm việc kiểu này thế nào. Reverse engineering rất khó, và tôi nghĩ đa phần việc nghịch thiết bị thường hoặc cực đắt, hoặc đã quá cũ nên không còn được phát triển nữa. Dù chắc vẫn có ngoại lệ

    • Thứ nhất, mua món đồ. Thứ hai, tháo nó ra. Thứ ba, nghĩ cách xâm nhập. Thứ tư, thật sự thử làm. Thứ năm, làm hỏng rồi chửi thề
      Thường thì sẽ có UART, nhưng có vẻ thiết bị đầu cuối Starlink không có UART, nên người này thay vào đó đã tháo chip nhớ eMMC ra. Về cơ bản nó giống một thẻ microSD được hàn vào
    • Có lẽ trước tiên cần học một chút kỹ thuật phần cứng. Nếu không biết linh kiện làm gì và phải xử lý chúng thế nào thì reverse engineering sẽ khó

  • Có câu “DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware”, tôi tò mò liệu có tài liệu hay giải pháp dựng sẵn nào để mô phỏng firmware kết nối với thiết bị bên ngoài như GPS không

    • https://android.googlesource.com/platform/external/qemu/+/2d...
      Android Emulator là downstream của trình giả lập QEMU, bổ sung hỗ trợ khởi động thiết bị Android và mô phỏng phần cứng Android phổ biến (OpenGL, GPS, GSM, cảm biến) cùng giao diện GUI. Android Emulator mở rộng QEMU theo nhiều cách

  • Tôi quan tâm nên bảo vệ firmware trong sản phẩm như thế nào để chống reverse engineering. Có tài liệu nào giới thiệu các kỹ thuật SpaceX đã dùng không?

    • Bước 1 chắc là thứ như firmware được mã hóa, nhưng SpaceX có vẻ hoặc không làm gì, hoặc chỉ phản ứng sau sự cố. Trước khi ai đó công bố tấn công dùng các chân đó, thậm chí còn có cả chân debug
    • Tối thiểu nên mã hóa rootfs bằng một bí mật khó trích xuất từ secure element. Đi thêm một bước nữa thì có thể dùng thứ như TrustZone của ARM để ẩn các tác vụ nhạy cảm như bootloader, giải mã, ký image
      Việc có thể dump thẳng filesystem cho thấy, ngoài bootloader được nhắc trong bài, có vẻ SpaceX không áp dụng biện pháp bảo vệ đáng kể nào
    • Từ góc nhìn của một người đã dùng nhiều sản phẩm tốt nhưng firmware lại tệ, xin đừng làm vậy nếu không có lý do mạnh, thực tế và đã được phân tích đầy đủ
      Tôi nghĩ tốt hơn là dùng nguồn lực vào những việc có lợi cho mọi người và làm sản phẩm tốt hơn. Với người dùng nâng cao, khả năng về mặt lý thuyết có thể chỉnh sửa sản phẩm, thậm chí chỉnh theo cách nhà sản xuất chưa từng nghĩ đến, có thể là một ưu điểm lớn
      Từ góc nhìn người dùng cuối có kỹ thuật, chuyện này trông như sau: tôi thật sự mệt mỏi và hơi chán nản khi phải hack thiết bị để dùng đèn, máy cho mèo ăn, và giờ là cả máy chèo thuyền cho ra hồn
    • Nếu đang dùng Linux thì có thể dẫn đến vi phạm GPL

  • Nếu cái này dựa trên codebase dùng chung với tên lửa thì hay đấy?

    • Nói cho ngầu hơn thì có lẽ là codebase dùng chung với vệ tinh. Hoặc cũng có thể là trình mô phỏng vệ tinh; dù sao cũng là thứ phải gửi telemetry
    • Không, nó dựa trên OpenWRT