Hanwha Visionのセキュリティカメラ、Web UIのログインページにGitHub管理者トークンを含んだ状態で出荷

 (hhh.hn)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • Hanwha VisionのカメラファームウェアのWeb管理UIファイル約30件に同一のGitHubトークンが含まれており、このトークンは組織内の数百のリポジトリに対して管理者権限を持っていた
  • ファームウェアのfwupgraderはハードコードされたAESキーを静的テーブルとXORして復元した後、opensslでルートファイルシステムを復号しており、キーとIVは同一モデル群で共通利用されていた
  • Viteのビルド変数がprocess.env全体に設定されていたため、CIジョブの環境変数が成果物に記録され、GITHUB_NPM_TOKENや複数の内部設定までカメラファームウェアに含まれていた
  • 約500件のファームウェアを同じ方法で調査した結果、62%を抽出でき、GitHubトークンが見つかった3件のファームウェアにはすべて同じトークンが含まれていた
  • Hanwhaは報告後12時間以内にトークンを失効させたが、CI環境全体をクライアント向け成果物に埋め込む構成は、認証情報や内部インフラ情報を製品に露出させうる

ファームウェアの入手と最初の暗号化レイヤー

  • Hanwha VisionのWebサイトではカメラモデルごとのファームウェアイメージが公開されており、ファイルをダウンロードして分析できた
  • binwalkでイメージを調べると、カメラ向けAIコンポーネントを含む別のtarballと、暗号化されたfwimage.tgzが見つかった
  • Matt BrownによるHanwhaファームウェア復号の分析に従い、HTWとモデル番号を組み合わせたパスワードを使用した
    • 分析対象ではHTWXNP-9300RWが有効だった
  • 展開したtarballの中には別方式で暗号化されたもう1つのfwimage.tgzがあり、既存の復号手順をそのまま再利用することはできなかった

fwupgraderで復号方式を復元

  • 外側のtarballに含まれるfwupgraderバイナリをGhidraとClaude Codeで分析し、実際のルートファイルシステムを抽出した
  • fwupgraderには復号方式を隠すための難読化が施されていた
    • AESキーをバイナリ内部の小さな静的キーテーブルとXORし、実行時に再構成する
    • IVはバイナリ内に平文で入っている
    • opensslコマンド断片も同じ方式でXOR難読化されていた
  • 復元されたコマンドはSHA-256とAES-256-CBCを使う次の形式だった 
    openssl enc -md sha256 -aes-256-cbc -d \  
  -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
  • キーとIVはハードコードされており、同一モデル群で共通利用されていた 
    KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0  
IV  = 53f926801b81454a4f889c9a390db6e6

ファームウェアに含まれていたGitHub管理者トークン

  • 抽出したルートファイルシステムをtrufflehogで検査すると、同一のGitHubトークンが約30件のファイルで重複して見つかった
  • このトークンはHanwhaのGitHub組織に属する数百のリポジトリに対して管理者権限を持っていた
  • カメラUIはViteでビルドされており、あるビルド変数がprocess.env全体に設定されていたため、CIジョブの環境全体が生成ファイルに記録されたことが確認された 
    var W = {  
  DATAPORT: "9090",  
  GIT_LFS_SKIP_SMUDGE: "1",  
  npm_command: "run-script",  
  KUBERNETES_SERVICE_PORT_HTTPS: "443",  
  GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",  
  npm_config_userconfig: "/home/docker/.npmrc",  
  // etc  
}
  • 実機のカメラがないため、実際に動作していたかは検証できなかった
    • 管理UIにアクセスしたユーザーへトークンがネットワーク経由で送信されていた可能性がある
    • ファイルがディスク上に存在するだけで、実際には配信されていなかった可能性も残る

CI環境に含まれていたDoDアドレス

  • 露出していた環境変数には、米国国防総省に割り当てられたIPアドレスも含まれていた
  • これらのアドレスが外部と通信しない内部サービス向けに任意使用されていたのか、Hanwhaと米国国防総省の関係に由来するのかは確認されていない
  • Hanwha VisionはSamsung Techwinとして設立された映像監視企業であり、Hanwha Groupの子会社でもある
    • 過去の製品にはK9 Thunder自走砲、K10弾薬運搬装甲車、K2 Black Pantherのサブシステム、SGR-A1警備ロボットが含まれる
    • SGR-A1は武装警備ロボットである
  • CIをHanwhaの中央組織が提供し、関連変数がグループ会社のHanwha AerospaceやHanwha Defense USAの要件で共有されていた可能性もあるが、これは未確認の推測にすぎない

全ファームウェアの調査

  • 偶然の単発事例なのか、別のトークンがさらに存在するのかを確認するため、HanwhaのWebサイトからダウンロードできるカメラファームウェアを収集した
  • 約600機種のカメラのうち、ファームウェアが提供されているモデルを対象に約500件のファームウェアを確保した
  • 同じ方法で62%を抽出できたが、残りが失敗した理由は確認できなかった
  • GitHubトークンが入っていたファームウェアは3件で、いずれも同一のトークンを含んでいた

報告と対応

  • トークンの位置を特定できる最小限の情報を、Hanwhaの公開されているセキュリティ報告用メールアドレスへ送った
  • Hanwhaは報告後12時間以内に応答し、当該トークンを失効させた
  • GitHubトークンがファームウェアに含まれていたのは問題だが、報告の受理と対処は非常に迅速に行われた

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsのコメント

  • メーカーがサポートしつつ、必要に応じてrootfsを削除できるホワイトラベルIPカメラや、準プラグ＆プレイ製品を探している
    以前はケースすらない高価な開発キットくらいしかなかったが、今はGoodCamのような選択肢が出てきたようだ

    • オープンなファームウェアでなくても、隔離されたネットワークでONVIFを使えばかなり近いところまで行ける
      ONVIFカメラは大半のネットワークビデオレコーダー（NVR）と互換性があり、オープンソースのNVRも複数ある
      安価なPoEカメラを外部に公開しなければメーカー製ファームウェアのセキュリティはそれほど重要ではないが、VLANとネットワーク分離は非常に綿密に構成する必要がある
    • この問題を解決しようとWyrecamを作った。Wyze v3のIngenic T31をサポートしている
      安定性はApple HomeKitと同程度だが、あまり優秀とは言えない
    • Thinginoは対応カメラ一覧が明確で、SDカードでのフラッシュ対応モデルならインストールも簡単
      Sonoff Slim Gen2を2台、問題なくアップグレードできた
    • 一部のカメラはThinginoで既存ファームウェアを置き換えられ、OpenIPC対応ハードウェア一覧も参考になる
    • ストアページがStránka nenalezena、There's been a glitch...エラーを出しており、動作していないようだ

  • ファームウェアに米国防総省のIPアドレスが埋め込まれているほうが大きな問題に見え、韓国製のセキュリティ製品は避けるべきだと感じた

    • 会社によっては米国防総省のIPレンジ全体をブラックホール化し、内部アドレスとして使うこともあるので、そのケースかもしれない。それでも非常に奇妙だ
    • カナダ海軍も最近、大型案件で似たような判断をしたように見える: 検索結果
    • 米国防総省は非常に広大なIPアドレス空間を保有しているため、偶然重なった可能性も十分ある
    • 韓国製IoT製品も同様で、自分が直接扱った製品のセキュリティ方式はばかげたレベルだった
    • 自国製品でも、セキュリティ脆弱性やずさんなエンジニアリングでひどいものが多い

  • 多くのサプライヤーが危険なデフォルト値、壊れたセキュリティ、ハードコードされた値を使っている
    セキュリティを最優先にしないとしても、少なくともハードコードされた認証情報の検査のような基本的なチェックは必要だ

    • セキュリティカメラでセキュリティが優先事項ではないという事実自体が皮肉だ
    • 最も経験が浅く安い人材に仕事を任せる運用では、最低基準の検査すら期待しにくい
    • 今ではリポジトリに基本的なセキュリティ検査を行う機能を追加するだけで済むので、言い訳の余地はほとんどない

  • カメラは別VLANに入れ、そのVLANのインターネットアクセスを完全に遮断するのが最低限の対策だ

  • 以前確認したところ、多くのOBD-IIドングルが同じMACアドレスで出荷されており、その結果、複数のWebサイトのすべての情報にアクセスできた
    こうした問題は避けたくても起こり続けるものだ

    • 同じMACアドレスがどうやって全面的なアクセス権につながったのか気になる
      Webサイトがクライアント提供のMACアドレスを認証手段にしていたなら、典型的なIoTセキュリティの失敗だ

  • 製品名からセキュリティを外して、単にカメラと呼んだほうがよさそうだ

  • このブログが外部リンクアイコンを誤って使っている点が気になる

    • a[href*="://"]::afterセレクタは内部リンクがhref="/about"のような相対パスだと仮定しているが、このサイトはナビゲーションリンクにも[https://hhh.hn/about](https://hhh.hn/about)のような絶対URLを使っているため、すべてのリンクにアイコンが付いてしまう
      サイトのアドレスで始まるリンクを除外すれば解決できる: a[href*="://"]:not([href^="https://hhh.hn";])::after

  • 最近購入した室内用ムード照明は、専用アプリなしでは制御できなかった
    GoogleストアからAPKを入手して解析してみると、バックエンドやShopifyなどのAPIキーが実質そのまま入っていたが、まだそれを使って何かをしたわけではない

    • 公開キーは特別なアクセス権を与えない場合が多い
      セキュリティを気にする開発者なら、App AttestやGoogleストアの同等機能を使うだろう
    • 照明アプリにShopify APIアクセス権が必要な妥当な理由は思い浮かばない
      ただしShopifyストアのコンサルをした経験からすると、低価格のコンサルタントやデザイナーが提供するコード品質はひどいことが多いので驚きはしない
    • 見た目の都合で常に最善とは限らないが、ZigbeeやZ-Waveのようにローカル制御できるスマート機器だけを買うほうが安全だ
    • こうした情報を公開すると、業者が法的措置を取る可能性があり危険だ
      研究者を法的な結果から守ってくれる会社があったが、名前は思い出せない
    • 専用アプリなしでも最終的には制御できるはずなので、プロトコルをリバースエンジニアリングして方法を公開してほしい

  • LLMのせいでコード難読化は事実上無力化された
    難読化は作業を退屈にして妨げていただけだが、AIはそうした手間を気にしない

    • 難読化は退屈さに耐えられない軽い攻撃者にしか効果がなかった
      国家組織や犯罪ハッカー集団は、その手間を十分に引き受ける
    • 前向きに見れば、小さなローカルLLMだけでもこうした低品質コードを簡単に改善できる

  • こうしたシステムを米国の防衛産業展示会で見たことがあるので、実際にどこかで使われている可能性が高い