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

• Thiết bị đầu cuối người dùng Starlink của SpaceX là phần cứng cốt lõi cho kết nối Internet vệ tinh quỹ đạo Trái Đất tầm thấp
• Khi tháo rời thiết bị đầu cuối người dùng, có thể thấy RF frontend và SoC do hãng tự thiết kế là các linh kiện chính
• Kết quả phân tích firmware cho thấy phần lớn phần mềm cốt lõi bao gồm xử lý mạng không gian người dùng bỏ qua kernel và một số chức năng mã hóa
• Chip bảo mật STSAFE-A110 đóng vai trò là gốc xác thực bổ sung, đồng thời cung cấp mã hóa dữ liệu và định danh duy nhất
• Thiết bị đầu cuối này có cấu hình nhiều khóa công khai SSH và công cụ ghi lại gói tin đáng ngờ, nhưng chưa xuất hiện dấu hiệu xâm phạm quyền riêng tư của người dùng

---

Tổng quan

• Starlink là dịch vụ Internet vệ tinh quỹ đạo Trái Đất tầm thấp do SpaceX cung cấp
• Người dùng kết nối tới vệ tinh lân cận thông qua thiết bị đầu cuối, rồi từ đó được nối ra Internet qua gateway mặt đất
• Thế hệ vệ tinh mới có thể liên lạc giữa các vệ tinh bằng liên kết laser, góp phần cải thiện độ phủ toàn cầu và hiệu quả vận hành
• Ngay cả khi không có gateway tại địa phương, thiết bị đầu cuối Starlink vẫn có thể truy cập Internet qua gateway ở quốc gia lân cận, như trường hợp Ukraine
• Bài viết này tóm lược nội dung điều tra chuyên sâu về thiết bị đầu cuối người dùng Starlink của DARKNAVY

Phân tích phần cứng

• Một thiết bị đầu cuối người dùng Starlink gồm hai phần: router và ăng-ten (UTA)
• DARKNAVY đã mua một thiết bị đầu cuối Standard Actuated (Rev3, GenV2) tại Singapore và tháo rời ăng-ten
• Kết quả cho thấy các chip RF frontend (chủ yếu do STMicroelectronics sản xuất) chiếm phần lớn diện tích bo mạch
• Khu vực điều khiển trung tâm được trang bị SoC ST tùy biến riêng cho SpaceX (quad-core Cortex-A53), nhưng thông tin datasheet không được công khai
• Tại Black Hat USA 2022, tiến sĩ Lennert Wouters từ KU Leuven đã công bố trường hợp hack thành công thiết bị đầu cuối thế hệ 1 (GenV1), sau đó SpaceX đã vô hiệu hóa giao diện debug UART bằng bản cập nhật firmware
• Tuy vậy, từng có thêm các trường hợp tiếp tục vượt qua cơ chế bảo vệ bằng phương pháp khác

Trích xuất và phân tích firmware

• DARKNAVY đã dump firmware trực tiếp từ chip eMMC
• Do bo mạch Rev3 không có chân debug eMMC riêng, họ sử dụng cách tháo eMMC rồi trích xuất dữ liệu bằng programmer
• Phần lớn firmware không được mã hóa, nên có thể thấy boot chain (trừ BootROM), kernel và một phần hệ thống tệp
• Sau khi kernel khởi động, môi trường runtime được bung ra và sử dụng tại /sx/local/runtime
• bin chứa các tệp thực thi phần mềm Starlink, dat chứa tệp cấu hình, còn revision_info chứa thông tin phiên bản
• Chương trình giao tiếp cốt lõi user_terminal_frontend được viết bằng Go, còn phần lớn các thành phần khác là binary C++ tĩnh không có symbol
• Kiến trúc network stack hoạt động tương tự DPDK, bỏ qua kernel để chương trình không gian người dùng xử lý gói tin
• Linux kernel chủ yếu được dùng cho driver phần cứng và quản lý tiến trình
• Một phần phần mềm có chứa các chức năng vốn được thiết kế cho vệ tinh hoặc gateway
• Khi thiết bị khởi động, nó xác định loại thiết bị qua các ngoại vi phần cứng rồi chỉ nạp logic tương ứng để sử dụng

Mô phỏng

• Để phục vụ phân tích lâu dài, họ đã xây dựng môi trường mô phỏng firmware Rev3 dựa trên QEMU
• Trong môi trường này, họ đã chạy và debug thành công một số dịch vụ đối ngoại như httpd, WebSocket, gRPC
• Nhờ đó có thể lần theo nguyên lý hoạt động của các tệp thực thi và dịch vụ quan trọng

Chip bảo mật

• Ngoài SoC chính còn có chip bảo mật STSAFE-A110, được quảng bá đạt chứng nhận CC EAL5+
• Con chip này có thể mua theo NDA, và chương trình stsafe_cli trong firmware dùng để tương tác với nó
• Kết quả phân tích cho thấy các chức năng do chip STSAFE cung cấp bao gồm cấp UUID duy nhất cho thiết bị, quản lý chứng chỉ khóa công khai (stsafe_leaf.pem), dẫn xuất khóa đối xứng
• Chip này là một gốc tin cậy bổ sung tách biệt với secure boot của SoC, phù hợp với tiêu chuẩn thiết kế bảo mật nhúng hiện đại

Easter egg: Elon có đang theo dõi bạn?

• Trong quá trình phân tích, họ phát hiện chương trình Ethernet Data Recorder, làm dấy lên nghi vấn về khả năng tồn tại backdoor
• Chương trình này dường như có chức năng ghi lại gói tin, và nội bộ sử dụng cơ chế tương tự pcap_filter để bắt các gói cụ thể
• Xem các quy tắc có thể thấy đối tượng bị bắt chủ yếu là các gói UDP liên quan đến telemetry vệ tinh
• Lưu lượng bị thu thập được mã hóa bằng khóa phần cứng của SoC trước khi lưu lại
• Cho đến nay chưa xác nhận được bằng chứng cho thấy thiết bị thu thập dữ liệu quyền riêng tư của người dùng
• Trong quá trình khởi tạo, nếu thiết bị được nhận diện là đầu cuối người dùng thì 41 khóa công khai SSH sẽ được ghi vào /root/.ssh/authorized_keys, và cổng 22 luôn mở trên mạng cục bộ
• Việc một sản phẩm thương mại được cài sẵn nhiều khóa công khai không rõ nguồn gốc là điểm đáng chú ý

Kết luận và triển vọng

• Khi công nghệ vệ tinh được áp dụng trong nhiều lĩnh vực công nghiệp, các thành phần của hệ thống Internet vệ tinh như Starlink được dự báo sẽ trở thành chiến trường trọng yếu của cả tấn công lẫn phòng thủ bảo mật trong tương lai
• Do đặc thù của an ninh không gian, chỉ một sai sót cũng có thể dẫn tới mất liên lạc vĩnh viễn với đối tượng, nên cần tiếp cận hết sức thận trọng

[GN⁺]

Ý kiến trên Hacker News

• Khi khởi tạo thiết bị, nếu hệ thống nhận diện đó là terminal người dùng thì script khởi tạo sẽ tự động ghi 41 khóa công khai SSH vào tệp /root/.ssh/authorized_keys, và cổng 22 cũng luôn mở trên mạng nội bộ; điều này làm dấy lên thắc mắc vì sao lại cần tới 41 khóa, và rốt cuộc là ai không có quyền truy cập root vào terminal người dùng mà "bạn sở hữu"
  • Có lẽ là chính bạn; nghĩ nghiêm túc hơn thì chuyện này cũng không khác mấy so với việc router do ISP cung cấp có hệ thống quản trị từ xa; kể cả SpaceX không có quyền truy cập vào terminal người dùng, họ vẫn có thể giám sát lưu lượng từ vệ tinh hoặc trạm mặt đất
  • Gần đây tôi tự hỏi ai sẽ là người phù hợp nhất để kiểm tra xem có khóa SSH nào có thể bị truy dấu tới những người làm việc liên quan tới các nhiệm vụ đặc biệt của chính phủ hay không; dạo gần đây cũng có vài vụ rò rỉ đáng chú ý
  • 41 khóa có thể chỉ đơn giản là 41 instance máy chủ giống nhau ở 41 khu vực; Starlink là dịch vụ toàn cầu nên chẳng có gì quá đáng lo; nếu 41 instance đó lại dùng chung một khóa thì tôi còn thấy đáng lo hơn
  • Ở công ty hiện tại của tôi, chỉ firmware DEV hoặc QA mới được triển khai khóa SSH của lập trình viên; image production sau khi ký xong thì SSH bị tắt hoàn toàn; trên production, chẩn đoán từ xa dùng phần mềm riêng, và việc đó cũng được kiểm soát bằng quyền truy cập cùng quy trình phê duyệt của DevOps; vì vậy lựa chọn của SpaceX khiến tôi thấy khá lạ
  • Tôi là người dùng đơn lẻ mà trong authorized_keys vẫn có 25 dòng, gồm nhiều yubikey trên laptop, khóa trên iPad và iPhone, khóa secure enclave trên Mac, v.v.; tôi hình dung Starlink hẳn phải có thêm ít nhất 1-2 quản trị viên hệ thống, nên 100 khóa công khai cũng không phải con số quá kỳ lạ
  • Thực ra đây có thể là một lựa chọn khá bình thường và tốt về mặt bảo mật; thay vì để hàng triệu thiết bị đầu cuối cùng dùng một khóa hoặc chỉ vài khóa, tốt hơn là dùng nhiều khóa tách biệt theo số serial hoặc theo lô sản xuất; khóa riêng tư có thể chỉ được dùng để quản lý một số lượng nhỏ thiết bị, và việc quản lý khóa cũng có thể được phân tách
  • Tôi đoán terminal này chỉ có thể bị truy cập từ bên ngoài bằng khóa khi nó đồng thời có kết nối Internet vào mạng cục bộ; tôi cũng tò mò SSH sẽ đi qua mạng vệ tinh như thế nào, và Starlink dùng NAT hay cấu trúc mạng ra sao
• Chia sẻ liên kết tới một bài phân tích tương tự đã từng được đăng trước đây về việc tháo rời terminal người dùng Starlink
• Có người cho rằng sẽ khá thú vị nếu công khai 41 khóa công khai đó để xem chúng thuộc về lập trình viên nào
• Chia sẻ liên kết tới kho lưu trữ các bài blog liên quan đến Starlink
• Đề nghị tác giả sửa lỗi chính tả trong tiêu đề ("ternimal")
  • Khéo léo nói đùa rằng đây là một ví dụ kinh điển của vấn đề keming (khoảng cách chữ không cân đối)
• Việc mọi gói tin đều được xử lý trong userspace nghe thật đáng kinh ngạc; với lưu lượng 1Gbps (giả sử UDP 100 byte) thì sẽ là 1 triệu gói mỗi giây; CPU 1GHz chỉ có thể dùng 1000 chu kỳ cho mỗi gói; về lý thuyết là khả thi nhưng không hề dễ, đến mức kỹ sư phải viết assembly thủ công và tận dụng đủ mọi mẹo
  • Theo bài báo, cấu trúc network stack trông khá giống DPDK, với kernel bypass cho xử lý gói tin là điểm mấu chốt; trên thực tế có thể chỉ gói đầu tiên do phần mềm xử lý, còn sau khi phiên được thiết lập thì chuyển sang phần cứng; một số mẫu lưu lượng vẫn có thể tiếp tục được xử lý bằng phần mềm; tôi từng thấy cách làm tương tự ở các router modem cáp Intel Puma đời cũ
  • Với kiểu chuyển tiếp theo phong cách DPDK, việc giảm sao chép buffer thậm chí còn có thể nhanh hơn; Starlink chỉ ở mức 25-200Mbps, và kích thước gói trung bình lớn hơn 7-8 lần, nên chỉ khoảng 36 nghìn gói mỗi giây; với CPU 1GHz thì vẫn trong khả năng xử lý
  • Tôi thắc mắc vì sao xử lý gói tin trong userspace lại phải kém hiệu quả hơn trong kernel; nếu ánh xạ hàng đợi phần cứng vào userspace thì ranh giới kernel-userspace không còn quá quan trọng
  • Với Starlink, thay vì các gói UDP 100 byte thì MTU 1500 byte thông thường mới là trường hợp phổ biến
  • Xử lý gói tin trong userspace sẽ giảm các lần sao chép bộ nhớ không cần thiết nên có thể nhanh hơn rất nhiều
• Có người bày tỏ sự tò mò không biết nên bắt đầu reverse engineering loại thiết bị này như thế nào; reverse engineering vốn khó, mà đa số ví dụ lại quá cũ hoặc quá đắt nên khó áp dụng
  • Trước hết cần học về hardware engineering; nếu không biết công dụng hay đặc tính của linh kiện thì bản thân việc reverse engineering cũng rất khó
  • Bước một là tự mua sản phẩm về rồi tháo ra; bước hai là nghĩ cách đột nhập sau khi đã tháo; bước ba là thật sự thử; bước bốn là thất vọng vì làm hỏng nó; thường thì người ta vào bằng cổng UART, nhưng Starlink có vẻ không có, nên đã có trường hợp tháo chip nhớ eMMC ra để phân tích
• Hỏi liệu có tài liệu tham khảo hoặc giải pháp sẵn có nào cho việc mô phỏng firmware kết nối với thiết bị ngoài (GPS, v.v.) trong môi trường giả lập dựa trên QEMU hay không
  • Nêu ví dụ rằng trong nhánh QEMU fork của Android có mô phỏng nhiều loại phần cứng và giao diện GUI như OpenGL, GPS, GSM, cảm biến, v.v.
• Có người muốn học cách bảo vệ firmware khỏi reverse engineering, và tự hỏi có tài liệu nhập môn nào về các kỹ thuật mà SpaceX sử dụng hay không
  • Bước 1 là các biện pháp như mã hóa firmware; có vẻ SpaceX cũng không chủ động phòng thủ quá mạnh mà chỉ liên tục vá khi có phát hiện mới; trước đây thậm chí còn có cả chân debug
  • Rất nhiều sản phẩm tôi từng dùng có mức độ hoàn thiện phần firmware khá thấp; ngoài mục đích bảo mật thực sự thì xin đừng khóa chặt mọi thứ một cách vô ích, mà hãy dùng nguồn lực vào việc có ích cho tất cả; với power user, việc có thể tự sửa thiết bị đôi khi còn là lợi thế; nếu không có nguy cơ xâm phạm thực sự nghiêm trọng, tôi mong đừng tốn thời gian vào những thứ vô bổ; thật đáng tiếc, đôi khi còn thấy chán nản, vì thực tế là đủ loại thiết bị vẫn phải bị hack lại mới dùng đúng nhu cầu
  • Tối thiểu thì cần mã hóa root filesystem và sử dụng bí mật từ một chip bảo mật thật sự khiến việc trộm hoặc trích xuất trở nên khó khăn; nếu muốn nâng mức bảo mật cao hơn nữa, có thể dùng ARM TrustZone để cô lập các tác vụ nhạy cảm như bootloader, giải mã, ký image; việc có thể dump filesystem dễ dàng tự nó đã cho thấy SpaceX không dùng biện pháp bảo vệ thực chất nào, chỉ bootloader được bảo vệ còn mọi thứ khác đều lộ ra
• Có người thấy thú vị và tự hỏi liệu thiết bị này có dùng chung codebase với tên lửa hay không
  • Điều còn ngầu hơn theo tôi là nó có thể dùng chung codebase với vệ tinh, hoặc ít nhất là với một bộ mô phỏng vệ tinh, vì còn phải gửi đủ loại telemetry
  • Thực tế thì nó dựa trên OpenWRT