セキュリティ
セキュリティカメラがログインページにGitHubの管理者トークンを仕込んでいた
My security camera shipped a GitHub admin token in its login page (hhh.hn)
要約
筆者はセキュリティカメラのファームウェアを解析中に、意図せずGitHubの管理者トークンを発見した。このトークンは、カメラのUI構築に使用されるViteのビルドプロセスで、CI環境の全環境変数が誤ってファイルに書き込まれた結果、含まれてしまったものと推測されている。Hanwha Visionは迅速に対応し、トークンは失効された。
全文翻訳
セキュリティカメラについてもう少し考えていました。AXISが各カメラでLinuxアプリケーションを簡単に実行できるようにプッシュし始めたため、これらはエンタープライズ環境ではるかに深刻なターゲットとなり、脆弱性や認証情報管理などの観点からそのように管理する必要があります。ある人が、私には新しく聞こえる会社、Hanwha(Vision)について言及しました。サイトを見て、各モデルのカメラでアクセス可能なファームウェアブロブを見つけました。これは常に嬉しい発見です。画像を調べてbinwalkに投げ込み、それが単なるrootfsであることを期待しましたが、中にはAI関連の別のtarballと、binwalkが暗号化されているとフラグを立てたfwimage.tgzがありました。Matt Brownがこれらのカメラに関する記事を書いているのを見つけ、それが役立ちました。基本的にパスフレーズはHTW +モデル番号なので、HTWXNP-9300RWが機能しました。それらは今ではもっと多くのことをしているようです。なぜなら、そのtarballの中には別のfwimage.tgzがありましたが、それは暗号化されており、同じスキームではなかったので、Matt Brownと同じセットアップを再利用することはできませんでした。Hanwhaがより高度なことをしている、例えばキーをハードウェアに焼き込んでいる(これは明らかに完璧ではありませんが、少なくともカメラを所有している必要があります)と考えて、諦めるしかないと思いました。しかし、その外側のtarballにはfwupgraderバイナリがあったので、それをGhidraに投げ込んで調べ始めました。2023年であれば調べていたでしょうが、Claude Codeにそれを任せて、美味しい夕食を作り、パートナーと時間を過ごし、少し後に戻ると、説明と良いrootfsが得られました。Hanwhaは、実際のrootfsを復号する方法を隠すために、fwupgraderに難読化を組み込んでいました。AESキーは、バイナリ内の小さな静的キーテーブルとXORされ、実行時に再構築されます(IVはプレーンテキストでそこにあります)。fwupgraderはopenssl CLIにシェルアウトするだけで、コマンドフラグメントも同じようにXORで難読化されています。再構築されたコマンドは次のようになります。
openssl enc -md sha256 -aes-256-cbc -d \
-K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
キーとIVはハードコードされている(モデルライン全体で同じ)ため、ここに公開します。
KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0
IV = 53f926801b81454a4f889c9a390db6e6
これで、通常通り調査できる完全なrootfsが得られました。
truffles
ついに中身を見ることができるようになったので、すぐにtrufflehogを実行して、何か明白なものがないか確認しました。すると、約30個のファイルにGitHubトークンが重複して含まれていました。トークンがアクセスできるリポジトリを確認したところ、彼らのGitHub組織の数百のリポジトリに対する管理者権限を持っていました。これは、組織がファームウェアにGitHubトークンを仕込むのは初めてではありませんが、それは別のブログ記事の物語です。
なぜこの組織はトークンを30個ものファイルに入れたのでしょうか?彼らはこれらのカメラのUIをviteで構築しており、変数の1つがビルド時に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にアクセスした人は誰でも、このGitHubトークンがネットワーク経由で送信されていた可能性があり、(うまくいけば)悪意のある誰かがそれに気づいたということはないでしょう。あるいは、ディスク上に残っただけで、実際には提供されなかったのかもしれません。
環境には他にも…興味深いデータがありました。
IPアドレスを含むいくつかの環境変数がありましたが、それらは米国国防総省に割り当てられています。
SWARM_MASTER_NFS_ADDRESS: 55.101.212.23
OTEL_ELASTIC_URL: http://55.101.212.21:5601/<snip>
CIMIP: 55.101.211.213
うーん…これは単なる偶然でしょうか?それとも、内部サービスのためにIP空間を使用する人が、それと決してやり取りしないことを知っている(これは狂った慣行です…)という奇妙なケースの一つでしょうか?それとも、Hanwhaは米国国防総省とより直接的に結びついているのでしょうか?
Hanwha VisionのWikipediaページを見てみましょう。
Hanwha Vision(韓国語:한화비전)、Samsung Techwinとして設立、はビデオ監視会社です。Hanwha Groupの子会社です。過去の製品には、K9サンダー自走砲、K10弾薬補給車、K2ブラックパンサー用サブシステム、歩哨ロボットSGR-A1などがあります。
ああ…なるほど…。高校の頃にSGR-A1について読んだのを覚えています。まさか、キャリアの後半で、その製造元の「王国の鍵」を偶然見つけることになるとは思いませんでした…私の人生は時々奇妙です。
SPECULATION WARNING
それでも、これらはアメリカのデバイスではありませんし、そのようなものでもありません。Hanwha Visionはなぜ国防総省に関連するものが必要なのでしょうか?彼らのCIは、親会社であるHanwhaの中央チームによって提供されており、姉妹会社であるHanwha Aerospaceのニーズのために共有プラットフォームにこれらのエントリがCI環境変数に含まれているのでしょうか?あるいは、彼らが他の大型で恐ろしい鋼鉄機械を製造している姉妹会社、Hanwha Defense USAのためでしょうか?
さらに掘り下げてみると
これが単なる偶然ではなく、ファームウェアに数百もの異なるGitHubトークンが含まれていないことを確認したかったので、Hanwhaのウェブサイトをスクレイピングして見つけられるすべてのカメラのファームウェアをダウンロードしました。約500個のファームウェア(カメラは約600個以上ありましたが、すべてにファームウェアがリストされているわけではありませんでした)を入手し、上記と同じアプローチで62%を抽出できました。そして、そのうち3つだけがGitHubトークンを含んでおり、すべて同じトークンでした。他のものが機能しなかった理由はよくわかりませんが、満足するには十分な結果です。
disclosure
トークンがどこにあるかを特定するのに十分な情報を含む非常に短いメールをHanwhaに送りました。彼らはセキュリティ問題の報告用の良い公開メールアドレスを持っています。彼らは12時間以内に返信し、トークンが失効されたことを通知してくれました。もちろん、彼らは決してGHトークンをそこに含めるべきではありませんでしたが、これほど迅速な対応と解決が得られたことはありません。
私たちは本当にこれらの間違いを頻繁にするのをやめなければなりません。どうやって安心して眠ればいいのでしょうか?
ありがとう、コンピュータ。また次回。