스타링크 사용자 터미널 분해

 (darknavy.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • DARKNAVY는 싱가포르에서 구매한 Starlink Standard Actuated의 안테나를 분해해 하드웨어, 펌웨어, 보안 칩, 에뮬레이션 가능성을 예비 분석함
  • 안테나 PCB 대부분은 STMicroelectronics RF 프런트엔드가 차지하고, 핵심 제어부는 보드 한쪽에 집중돼 있어 일반 IoT 장치와 유사한 구조를 보임
  • Rev3 펌웨어는 eMMC를 탈거해 덤프했으며, 대부분이 비암호화 상태라 부트 체인 일부, 커널, 파일시스템 일부, 런타임 구성을 확인할 수 있었음
  • 추출된 소프트웨어에는 사용자 단말뿐 아니라 위성·지상 게이트웨이용으로 보이는 기능도 포함되며, 시작 시 하드웨어 주변장치로 장치 유형을 식별하는 구조로 보임
  • Ethernet Data Recorder는 위성 원격 측정 관련 패킷을 기록하고 하드웨어 키로 암호화하지만, UTA에는 41개의 SSH 공개키가 자동 등록되고 로컬 네트워크에 22번 포트가 항상 열려 있음

Starlink 사용자 터미널과 분석 범위

  • Starlink는 SpaceX의 저궤도 위성 인터넷 서비스로, 사용자는 사용자 터미널을 통해 근지구 궤도 위성에 접속하고 지상 게이트웨이를 거쳐 인터넷에 연결함
  • 새로운 세대의 위성에는 레이저 링크가 점진적으로 포함돼 일부 위성이 서로 직접 통신할 수 있음
    • 지상국 의존도를 줄이고 전송 효율을 높이며 전 세계 커버리지를 개선함
    • 현지 지상국이 없는 우크라이나 전장에서도 Starlink 사용자 터미널이 위성 간 링크를 통해 인접 국가의 게이트웨이에 간접 접속할 수 있음
  • DARKNAVY의 조사는 Starlink 사용자 터미널 전체가 아니라 안테나 구성요소인 User Terminal Antenna, UTA에 집중함
    • 대상 장비는 싱가포르에서 구매한 Starlink Standard Actuated
    • Rev3 또는 GenV2로도 불림

하드웨어 분해 결과

  • 완전한 Starlink 사용자 터미널은 라우터와 안테나 두 부분으로 구성됨
  • 분해된 UTA의 PCB는 외부 케이스와 거의 비슷한 크기였음
    • 보드 대부분은 STMicroelectronics가 만든 RF 프런트엔드 칩이 차지함
    • 핵심 제어 부품은 PCB 한쪽에 주로 모여 있음
  • RF 안테나를 제외한 UTA 핵심 영역의 전체 설계는 일반적인 IoT 장치와 상당히 유사함
  • 메인 SoC는 SpaceX를 위해 ST가 맞춤 제작한 quad-core Cortex-A53임
    • 현재 이 칩의 하드웨어와 데이터시트는 기밀이며 공개되지 않음
  • Black Hat USA 2022에서 KU Leuven의 Dr. Lennert Wouters는 1세대 Starlink 안테나 GenV1에 결함 주입 공격을 수행해 장치의 root shell을 얻는 시연을 함
    • SpaceX는 이후 펌웨어 업데이트로 PCB의 UART 디버그 인터페이스를 비활성화해 결함 공격 저항성을 높임
    • Wouters는 접근 방식을 개선해 다시 침입에 성공함

펌웨어 추출과 소프트웨어 구조

  • DARKNAVY는 UTA를 더 깊이 분석하기 위해 eMMC 칩에서 펌웨어를 직접 덤프함
    • Rev3 보드에는 명확한 eMMC 디버그 핀이 없었음
    • eMMC 칩을 PCB에서 탈거한 뒤 프로그래머로 읽어야 했음
  • 추출된 펌웨어 대부분은 암호화되지 않은 상태였음
    • BootROM을 제외한 부트 체인
    • 커널
    • 파일시스템의 비암호화 영역
  • 커널 시작 후에는 런타임 환경 대부분을 eMMC에서 읽어 /sx/local/runtime 디렉터리에 풀어놓음
  • 런타임 구조에서 bin은 Starlink 소프트웨어 스택에 필요한 실행 파일을 담고, dat는 설정 파일을 저장하며, revision_info는 현재 소프트웨어와 하드웨어 버전을 기록함
  • 외부 사용자 통신을 처리하는 user_terminal_frontend는 Go로 작성됐고, 나머지 대부분의 프로그램은 심볼이 없는 정적 컴파일 C++ 실행 파일임
  • 기존 연구를 바탕으로 한 초기 분석에서 네트워크 스택 아키텍처는 DPDK와 어느 정도 유사함
    • 주로 사용자 공간 C++ 프로그램이 커널을 우회해 네트워크 패킷을 처리함
    • Linux 커널은 기본 하드웨어 드라이버와 프로세스 관리를 제공하는 역할이 큼
  • UTA에서 추출한 핵심 소프트웨어에는 위성이나 지상 게이트웨이에 속할 것으로 보이는 기능도 포함돼 있음
    • 초기 리버스 엔지니어링상 시스템은 시작 중 하드웨어 주변장치를 기준으로 장치 유형을 식별함
    • 이후 해당 장치 유형에 맞는 로직을 로드하고 실행함

QEMU 기반 에뮬레이션

  • DARKNAVY는 UTA를 지속적으로 분석하기 쉽도록 Rev3 펌웨어용 QEMU 기반 에뮬레이션 환경을 구축함
  • 이 환경에서 외부 엔티티와 상호작용하는 일부 소프트웨어를 실행하고 디버그하는 데 성공함
    • httpd
    • WebSocket
    • gRPC 서비스

STSAFE-A110 보안 칩

  • UTA에는 메인 SoC 외에 전용 보안 칩인 STSAFE-A110이 탑재돼 있음
    • 이 칩은 CC EAL5+ 보안 등급을 주장함
    • 맞춤형 SoC와 달리 NDA 하에서 합법적으로 구매할 수 있음
  • UTA 펌웨어에서는 stsafe_cli라는 사용자 공간 프로그램이 이 칩과의 상호작용을 처리함
  • 리버스 엔지니어링 결과 STSAFE는 주로 다음 기능을 제공하는 것으로 보임
    • 각 장치의 고유 식별자, UUID
    • 위성 통신 인증에 쓰이는 것으로 추정되는 공개키 인증서 stsafe_leaf.pem 관리
    • 사용자 데이터 전송용 대칭 암호화 키 파생
  • 이 칩은 SoC의 secure boot 메커니즘과 독립적인 추가 root of trust 역할을 하며, 현대 임베디드 보안 설계 방식과 맞아떨어짐

Ethernet Data Recorder와 SSH 키

  • 분석 중 Ethernet Data Recorder라는 프로그램이 발견됐으며, 이름과 기능만 보면 사용자 데이터 캡처 백도어로 의심될 수 있음
  • 세부 확인 결과 이 프로그램은 pcap_filter와 유사한 메커니즘으로 특정 네트워크 패킷을 기록함
    • 캡처 규칙 예시는 udp and dst port 10017 조건과 특정 multicast 대상 호스트를 포함함
    • 펌웨어 내 다른 단서를 기준으로 이 패킷들은 위성 원격 측정과 관련됨
  • 캡처된 모든 트래픽은 SoC에 퓨즈된 하드웨어 키를 사용해 암호화됨
  • 현재 확보된 정보만으로는 이 기능이 사용자 프라이버시 데이터를 수집한다고 보기 어려움
  • 장치 초기화 중 시스템이 자신을 사용자 터미널로 식별하면 초기화 스크립트가 41개의 SSH 공개키를 /root/.ssh/authorized_keys에 자동 기록함
    • UTA의 22번 포트는 로컬 네트워크에 항상 열려 있음
    • 사용자 제품에 이렇게 많은 알 수 없는 로그인 키가 존재한다는 점은 눈에 띔

위성 인터넷 시스템의 보안 맥락

  • 위성 기술이 계속 발전하고 다양한 산업에 적용되면서 Starlink와 다른 위성 인터넷 시스템의 각 구성요소는 향후 공격과 방어 작전의 중요한 영역이 될 수 있음
  • 우주 보안에서는 개발자와 해커가 디지털 영역뿐 아니라 우주 물리학의 제약과도 맞서야 함
    • 한 번의 잘못된 조작으로 대상과의 연락을 영구적으로 잃을 수 있음

참고 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 초기화 때 사용자 단말로 식별되면 /root/.ssh/authorized_keys에 SSH 공개키 41개를 자동으로 넣는다니, “내” 사용자 단말에 루트 접근권이 없는 사람이 누구인지가 더 궁금해짐

    • 아마도 사용자 본인일 듯함
      좀 더 진지하게 보면, ISP가 제공한 라우터에 원격 관리 시스템을 두는 것과 크게 다른가 싶음. SpaceX가 사용자 단말에 직접 접근하지 못해도, 위성이나 지상국에서 트래픽을 캡처할 수는 있음
    • 최근 특수 정부 업무에 관여한 개인들과 이 키들 중 일부를 연결해 볼 수 있는 사람이 누가 가장 적합할지 궁금함. 좋은 유출 자료들도 좀 있었음
    • 41개가 꼭 걱정할 일은 아닐 수 있음. 41개 지역의 서버 인스턴스가 각자 키를 가진 것일 수도 있고, Starlink는 글로벌 서비스니까 자연스러움
      오히려 41개 인스턴스가 키 하나를 공유한다면 그게 더 걱정될 듯함
    • 개인 사용자 한 명인 내 authorized_keys도 25줄임. 노트북마다 다른 YubiKey, iPad와 iPhone의 키, Mac의 Secure Enclave 키가 있음
      Starlink에는 시스템 관리자도 1~2명보다는 많을 테니, 공개키 100개 정도도 합리적이라고 봄
    • 이 선택은 정말 이해가 잘 안 됨. 현재 직장에서는 개발자 SSH 키를 DEV나 QA 펌웨어가 올라간 장치에만 배포하고, 프로덕션 이미지는 서명되어 있으며 SSH는 완전히 꺼져 있음
      프로덕션 장치의 엔지니어링 문제를 진단하기 위해 별도 원격 접근 소프트웨어가 있고 REPL을 띄울 수는 있지만, 접근 제어와 DevOps 승인으로 막혀 있음

  • 비슷한 제출물의 이전 토론: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2020년 12월 2일 — 158점, 댓글 138개)

  • 공개키 41개를 올리면, 아마 어떤 개발자들이 쓰는지 확인할 수 있을 듯함

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

  • 모든 패킷이 사용자 공간에서 처리된다는 점이 놀라움
    100바이트 UDP 패킷으로 1Gbps 트래픽을 처리한다면 초당 100만 패킷을 처리해야 함. 1GHz CPU라면 패킷 하나당 1000사이클밖에 못 씀
    가능은 하지만, 엔지니어들이 어셈블리를 손코딩하고 온갖 조회 테이블 기법을 고민하는 걸 좋아하지 않는 한 쉽지는 않음

    • 보통은 초기 패킷을 소프트웨어가 처리하고, 엔드포인트가 확립되면 이후 흐름은 하드웨어로 넘어감. 특정 패턴은 항상 소프트웨어에서 처리되기도 함
      소프트웨어는 패치된 커널일 수도 있고, XDP식 커널 우회일 수도 있음. Intel Puma 케이블 모뎀 라우터/게이트웨이에서 DPDK나 유사한 것을 주변적으로 다뤄 본 경험에 따른 추정임
    • 전달 처리에서는 DPDK식 접근이 버퍼 복사를 줄여 더 빠를 수 있음
      Starlink는 25~200Mbps 정도이고 평균 패킷도 7~8배 더 크니, 많아야 초당 약 36,000패킷이라 1GHz에서도 꽤 감당 가능한 수준임
    • 커널에서 패킷을 처리하는 것보다 왜 덜 효율적이어야 하는지 모르겠음. 하드웨어 큐를 사용자 공간에 매핑하는 방식이 있고, 글에서도 시스템이 DPDK 유사 구조라고 함
      그 시점에서는 폴링 코드가 커널 안에 있느냐가 왜 중요한지 모르겠음
    • 100바이트라니? Starlink는 일반적인 1500바이트 MTU를 씀
    • 사용자 공간에서 처리하면 memcpy를 한 번 더 피할 수 있어서 훨씬 빠름

  • 제목의 오타를 고쳐 주면 좋겠음. 현재는 “Ternimal”로 되어 있음

    • 전형적인 커밍(keming) 문제임

  • 이런 일을 어떻게 시작하는지 궁금함. 역공학은 어렵고, 장비를 건드리는 장난은 정말 비싸거나 오래돼 더 이상 개발되지 않는 경우가 대부분이라 생각함. 예외는 있겠지만

    • 첫째, 물건을 산다. 둘째, 분해한다. 셋째, 침투 방법을 생각한다. 넷째, 실제로 해 본다. 다섯째, 고장 내고 욕한다
      보통은 UART가 있는데, Starlink 단말에는 UART가 없는 모양이라 이 사람은 대신 eMMC 메모리 칩을 떼어냈음. 사실상 납땜된 microSD 카드 같은 것임
    • 먼저 하드웨어 공학을 좀 배워야 할 듯함. 부품이 무엇을 하고 어떻게 다뤄야 하는지 모르면 역공학은 어려움

  • “DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware”라고 되어 있는데, GPS 같은 외부 장치에 연결되는 펌웨어를 에뮬레이션하는 자료나 이미 준비된 해법이 있는지 궁금함

    • https://android.googlesource.com/platform/external/qemu/+/2d...
      Android Emulator는 QEMU 에뮬레이터의 다운스트림이며, Android 장치 부팅 지원을 추가하고 일반적인 Android 하드웨어(OpenGL, GPS, GSM, 센서)와 GUI 인터페이스를 에뮬레이션함. Android Emulator는 여러 방식으로 QEMU를 확장함

  • 제품에서 펌웨어를 역공학 방지하려면 어떻게 보호해야 하는지 관심 있음. SpaceX가 쓴 기법을 소개하는 자료가 있을까?

    • 1단계는 암호화된 펌웨어 같은 것일 텐데, SpaceX는 아무것도 안 하거나 사후 대응만 하는 듯함. 누군가 그 핀을 이용한 공격을 공개하기 전까지 디버그 핀도 있었음
    • 최소한 보안 요소에서 추출하기 어려운 비밀값으로 rootfs를 암호화해야 함. 한 단계 더 나아가면 ARM의 TrustZone 같은 것을 써서 부트로더, 복호화, 이미지 서명 같은 민감한 작업을 숨길 수 있음
      파일시스템을 그냥 덤프할 수 있었다는 점을 보면, 글에 나온 부트로더 외에는 SpaceX가 별다른 보호를 적용하지 않은 것 같음
    • 좋은 제품을 많이 써 봤지만 펌웨어가 별로였던 입장에서, 강력하고 현실적이며 충분히 분석된 이유가 없다면 제발 그렇게 하지 않길 바람
      차라리 모두에게 이롭고 제품을 더 좋게 만드는 데 자원을 쓰는 편이 낫다고 봄. 고급 사용자에게는 제품을 수정할 수 있는 이론적 가능성, 심지어 제조사가 생각도 못 한 방식의 수정 가능성이 큰 장점이 될 수 있음
      기술적인 최종 사용자 입장에서는 이렇게 보임. 전등, 고양이 급식기, 이제는 로잉 머신까지 제대로 쓰려고 장치를 해킹해야 하는 상황에 정말 지치고 약간 우울해짐
    • Linux를 쓰고 있다면 아마 GPL 위반으로 이어질 수 있음

  • 이게 로켓과 공유하는 코드베이스 기반이라면 멋진데?

    • 더 멋지게 말하면 위성과 공유하는 코드베이스일 듯함. 아니면 위성 시뮬레이터일 수도 있고, 어쨌든 원격 측정을 보내야 하는 무언가임
    • 아니고, OpenWRT 기반임
답변달기