XZバックドア：時刻、呪われた時刻、そして欺瞞
(rheaeve.substack.com)- xz/liblzma tarballのバックドアをめぐり、Jia TanのGitコミットのタイムゾーンと作業パターンが、実際の活動地域を推定する手がかりとして使われている
- コミット時刻は
GIT_AUTHOR_DATEとGIT_COMMITTER_DATEで操作可能だが、時刻全体をもっともらしく合わせるより、タイムゾーンだけを変える方法のほうが容易だった可能性が高い - Jia Tanのコミット440件の大半はUTC+08で記録されていたが、一部のUTC+02・UTC+03の記録は、東欧式の冬時間・夏時間の切り替えと一致する
- 2022年10月6日と2023年6月27日のタイムゾーン切り替えは、実際の移動で説明するには間隔が短すぎ、単なる旅行だった可能性を弱めている
- 一部の+0200コミットは、Lasse Collinが
git amで適用したパッチと見られ、メールによるパッチの流れではタイムゾーン情報の信頼性が下がるという限界がある
xzバックドアと分析対象
- xz/liblzma tarballで見つかったバックドアは、自由ソフトウェアのエコシステムにおける信頼を大きく揺るがした事件として受け止められている
- バックドアは、xzの長期メンテナーだったJia Tanが仕込んだ可能性があると見られている
- Jia Tanについては、コミュニティ内でも名前以外にほとんど情報がなく、その名前も本当ではない可能性がある
- 分析対象は、JiaT75のGitHubでの活動と、xzリポジトリのコミットタイムスタンプ
- 出発点となった公開投稿は、oss-securityメーリングリストの投稿
Gitタイムスタンプを偽造しにくい理由
- Gitのコミット時刻は、
GIT_AUTHOR_DATEとGIT_COMMITTER_DATE環境変数で変更できる - まだプッシュしていないコミットなら、amendで後から日付を修正することも可能
- しかし、もっともらしい時刻データの偽造にはいくつもの制約が伴う
- 未来に作成したように見えるコミットをプッシュすると疑いを招く可能性がある
- オンラインでの議論より古く見えるコミットも不自然
- こうした制約を避けるにはコミットを保留する必要があり、プロジェクト開発が遅れる可能性がある
- 実際の時刻を調整する代わりにタイムゾーンだけを変更すれば、計算やコミット遅延なしに、より簡単に欺ける
UTC+08の記録とUTC+02/03の可能性
- Jia Tanのコミットの大半である440件は、UTC+08のタイムスタンプとして残っている
- UTC+08は中国CSTである可能性が高いが、インドネシア、フィリピン、西オーストラリアも同じタイムゾーンに属する
- Jia Tanという名前は、アジア人、特に中国人のように見せるためのシグナルだった可能性がある
- 実際の活動地域は、UTC+02の冬時間 / UTC+03の夏時間の地域だった可能性が示されている
- その地域には東欧のEET、イスラエルのISTなどが含まれる
- UTC+08の記録をUTC+02/03基準で補正すると、通常は午前9時から午後6時まで働いていたパターンになる
- 補正しない場合、火曜の深夜0時や午前1時に作業していた形になり、やや不自然になる
タイムゾーン切り替えから見えた手がかり
- 一部のコミットは、Jia Tanがタイムゾーン変更を忘れた結果かもしれない
- UTC+02のコミット3件とUTC+03のコミット6件が確認されている
- UTC+02は2月と11月の冬時間と一致する
- UTC+03は6月、7月、10月初旬の夏時間と一致する
- これは東欧の夏時間切り替え、つまり10月最終週末以降は+0200、3月最終日曜日以降は+0300というパターンと一致する
- このタイムゾーンは、Lasse CollinとHans Jansenのタイムゾーンとも同じように見える
- 4月2日の更新では、Joey Hessの指摘を反映し、こうした事例の多くがLasse Collinをcommitterとするコミットだと付け加えている
- ただし、LasseがコミットしたJiaのすべてのコミットで同じ現象が出ているわけではなく、多くは+0800で記録されている
- したがって、+02/03コミットがミスなのか、単なるワークフローの変化なのかは明確ではない
実際の移動とは考えにくい間隔
- UTC+08居住者が時々UTC+02/03地域へ飛行機で移動していたという説明は、細かなタイムスタンプとはうまく合わない
- 2022年10月6日には、21:53:09 +0300のコミットの後に17:00:38 +0800のコミットがある
- 2つのコミットの間隔は約11時間
- 中国から東欧または中東までは純粋な飛行時間だけで少なくとも10〜12時間かかり、直行便が少ないため、さらに長くなる可能性が高い
- 2023年6月27日には、23:38:32 +0800のコミットに続いて17:27:09 +0300のコミットがある
- 2つのコミットの差は数分程度
- こうした切り替えは、Jia Tanが実際にはUTC+08 CST地域にいなかった可能性を裏付ける
祝日と平日の作業パターン
- 祝日のパターンも、中国より東欧側とよりよく一致するように見える
- 中国の祝日一覧は、Bank of China Indonesiaの2023年祝日案内を参照している
- 中国の祝日として挙げられた日にも作業記録がある
- 2023年9月29日：中秋節
- 2023年4月5日：清明節
- 2023年1月22〜27日など：春節期間
- 東欧の祝日に関しては、12月25日のクリスマス、12月31日と1月1日の新年に作業した記録はないと見られている
- Jiaの最も多い作業曜日は、火曜86回、水曜85回、木曜89回、金曜79回
名前とパッチ適用の注意点
- “Jia Cheong Tan”が実名だとすれば、中国で使われる漢字名の有効なローマ字表記とは言えず、マレーシアのような東南アジア系の表記に近いという指摘がある
- “Cheong”という綴りは現代中国では使われておらず、中国式の英語表記では名前の文字を続けて書く傾向があるという例も示されている
- 例は“Yangqing Jia”であって、“Yang Qing Jia”ではない
- ただし、2つの+0200コミット
de5c5e4、e446ab7aはcommitterがLasse Collinであり、Jiaがメールで送ったパッチをgit amで適用したものと見られる - 当該コミットと隣接する一部のコミットは同じタイムスタンプを持っており、これはパッチファイルの束を
git amで適用した場合と一致する - パッチがメールでやり取りされる場合、タイムゾーン情報に依存しにくくなるため、この分析の一部は弱まる
1件のコメント
Hacker Newsの意見
国家支援攻撃だったなら、コードやメーリングリストへの投稿を書く人／部署とは別に、その成果物がインターネットに出る時刻やタイムスタンプを「プロジェクト設定に合った物語」と一致させるチームがいた可能性は十分にある
ときには意図的に「ミス」を入れて、実際の所在地ではなく、捜査官に別の選ばれた場所を示唆した可能性もある
別の記事[1]でも、突然現れたアカウント群が切迫感を作り出し、管理権の移譲を早めた可能性が指摘されていた
[1] https://connortumbleson.com/2024/03/31/watching-xz-unfold-fr...
via: https://news.ycombinator.com/item?id=39888854
該当部分は「Progress will not happen until there is new maintainer」で検索すればよい
特定の場所から活動しているように見せかけ、同時に複数人に見えないように装うことも含まれる
東欧出身ではないと思うが、UTC+0200/+0300を見ると、ヨーロッパではフィンランド、バルト三国、ウクライナ、ルーマニア、モルドバ、ギリシャあたりが該当する
少し南に下がると、イスラエルを含む中東のかなり広い地域も含まれる
ただしフィンランドでは通常7月が好まれるので、やや一般的ではない
見たところ辻褄は合っているように見える
とくにIDFのUnit 8200はかなり有名な評判がある
他国に能力がないという意味ではないし、この攻撃がNSAやGCHQ級のリソースを必ず必要とするものにも見えない。実際には一匹狼が1人だった可能性もあるが、それでも注目に値する
事実上無限のリソースと動機を持つ勢力は、責任を特定の方向へ向けるために偽旗作戦を仕組むことができる。彼らは痕跡を消すのが非常にうまく、最も熟練したセキュリティ研究者でさえ、誰が責任者なのかについて知識に基づく推定にたどり着くまでに数か月、あるいは数年かかることがある
だから「誰がやったのか」を突き止めようとするのは、時間の無駄に近い
教訓はこうだ：運用環境にはいかなる理由でも最先端の未検証ソフトウェアを入れないこと、組織のペネトレーションテスターは定期的にスタックを壊してみて、その結果を組織とパッケージメンテナーに知らせるべきこと、自由・オープンソースのメンテナーは、とくにセキュリティに敏感な新しいコードをリリースごとに監査すべきこと、そしてメンテナーに寄付すべきこと
幸いstableには入らず、システム内でセキュリティ版チェルノブイリが起きる寸前まで行って、かろうじて回避された程度だ
特定の勢力が責任者だと皆を説得しようとする人々がいて、そこには地政学的な目的がある。たとえば米国で人気Webアプリの外国人所有を禁止しようという議論がある状況で、そのような法律で利益を得る政府や企業にとって、中国風の名前のGitHubユーザーが、PRCから来たように見えるタイムスタンプで攻撃ベクターをコミットしていたら、どれほど都合がよいだろうか
仮に実際に中国本土の誰かだったとしても、国家の支援を受けていたなら、起訴や犯罪人引き渡し要請が出ても米国の保安官に引き渡される可能性はほとんどない。むしろ、より大きな組織情報が敵に渡らないよう「口封じ」されることさえあり得る
ボンド映画的な陰謀を除けば、その知識を実務に適用できる場面はあまりない。ユーザーがどこから来ているかはたいてい既に分かっているし、地域ブロックもできる。そうでなければ、その地域から来る他の脅威に備えるべきだ
GMT+8、名前の構成（中国語／混合方言風の名前 + Hokkienの姓）、そしてシンガポールのVPN出口やホスティングサーバーに見える場所から接続していたという状況証拠[1]は、本物であれ偽装であれ、シンガポール人としてのアイデンティティとすべて一致する
そのため、[1]の出典が「名前が偽物っぽく聞こえる」と見たことも、ある程度割り引いて受け取るべきだ。中国本土の人々がディアスポラの華人コミュニティを常によく知っているとは限らない
言及された祝日の多くもシンガポールの祝日[2]ではない。1月24日は祝日だったが、「勤務日に働く」というパターンを当てはめるには、1月22日は日曜日なのに働いたことになっている
Jia Tanの文章、とくにより古い文章をもっと見ると興味深そうだ。シンガポール人、中国本土人、複数のスラブ語話者、英語ネイティブを区別するのに使える、かなりはっきりした言語習慣があるかもしれない
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdo...
[2] https://www.mom.gov.sg/employment-practices/public-holidays
もちろんサンプルは非常に少ないので、そこから読み取りすぎることはできない
シンガポール人のほぼ10%がTanという姓を持つ
[1] [https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_f...](https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_frequency.png)
事案の深刻さはいったん脇に置くと、この事件の推理小説のような側面に完全に引き込まれている
インターネットが「誰が、どうやって、なぜ」を突き止めていく過程が面白い
何年も前から、まさにこういう理由でターミナルの
gcをTZ=UTC0 git commitに割り当てているシステム時刻や git の設定を変える必要がない。グローバル設定でもっと良い方法があるかもしれないが
悪意があるわけでもない。よく旅行するので、公開リポジトリに旅行日程を漏らしたくない
タイムゾーンを UTC に合わせるだけでなく、時刻を 00:00 に設定して、コミットには日付情報だけが残るようにしている。git コミットに永久に保存される情報は日付程度で十分で、正確なコミット時刻を漏らす必要はないと思う
alias git='TZ=UTC0 git'手動の手順が必要だし、位置情報サービスも使っていない
Jia は気の毒だね。2年も作業したものが全部水の泡になった
Jia、これを読んでいるなら、打たなかったシュートは100%外れるということを覚えておいてほしい。顔を上げろ、兄弟
「誰が早朝に定期的に働くんだ？」
私
「ハッカーなら午後と深夜に働くほうがずっとありそうだ」
ここでハッカーを若者に置き換えると、もっと当たっていそう
私は41歳で、この10年で午前7時前に起きていた日は20日あるかないかだ。今でもコンピューターの仕事に耐えている理由の半分は、たいていの日に午前11時〜午後7時のスケジュールで働いても成果を出せる数少ない職業だからだ
朝型の人も夜型の人もいる。誰にでも自分のリズムがあり、評価するようなことではないが、年を取れば自然に変わる、あるいは変わるべきものでもない
c/hacker/younger personってこの文法は何？sed置換のs/a/b/は知っているけど、cで始まるのは知らない朝は「朝型人間」を相手にするような邪魔が多く、昼食後から夕方までは割り込みがずっと少ない
ランダムな電話やメールが入る8時間勤務より、邪魔されない4時間のほうがはるかに多くの仕事ができる。もう若者でもないが、邪魔がなく、数時間かけて合間に考えておいた後なら半分の時間で終えられるので、夜にやる仕事もある
平穏な朝を過ごせているならうらやましい
「2023年6月27日火曜日に、23:38:32 +0800 と 17:27:09 +0300 の2つのコミットが見える。計算すると、この2つのコミットの間には約9時間の差がある」
でも 17:27:09 +0300 は 22:27:09 +0800 だから、2つのコミットは約1時間差では？
「さらに決定的なのは、2022年10月6日に 21:53:09 +0300 のコミットの後に 17:00:38 +0800 のコミットが見える。これはわずか数分差だ！」
違う。これはほぼ10時間差だ
筆者が2つの分析を誤って入れ替えて書いたか、タイムゾーン計算がかなり苦手なのだと思う
アメリカ人、あるいはまったく別の地域の人が、中国人のふりをしている東欧人のふりをしていたらどうだろう？
何かを偽装するなら、少なくとももう一段階迂回を入れていたはずだ
そういう構成なら、このような漏れがあっても大したことにはならない
原文の著者の一人です。今後の分析に使えそうなアイデアを多く得ましたし、よく出た4つの反論に答えるとこうです
1人だったのか複数人だったのかは不明だという点には同意します。ただ、チームだったとしても、タイムゾーンからのアプローチはそのチームがどこにいたのかを示し得ます。活動時間が世界中に分散したチームというより、通常の勤務時間のように見えすぎるからです
コミット時刻が変更されていた、あるいは時刻予約スクリプトでコミット／アップロードされていた可能性も当然あります。それでも実際に大きなタイムゾーン差を隠すには非常に大きな遅延を入れる必要があり、現実的には難しいと思います。xz は真空状態で開発されたわけではなく、Issue 登録やメーリングリスト投稿のようなオンライン上の出来事に反応しながら開発されていたからです
2つの例は実際に取り違えて書いていました。10時間ほど差があるとした2つの時刻は実は数分差で、数分差とした時刻は10時間ほど差があります。更新予定です
最後に、UTC+2/3 が東欧だけでなく中東の一部も含むという点もその通りです。この点も記事の更新で明確にしました