gf

2026/03/21(土) 秋葉原電脳倶楽部 技術発表会 #29 で発表した資料です
https://akiba.connpass.com/event/385638/

Transcript

2. 発表概要  本発表では、公開情報だけを使ってGitHubユーザーの 機微情報を調査するツール GitFive の内部処理を調査する  どういうロジックで機微情報を見つけているのかを調べる  想定対象: GitHubを業務・趣味の開発で使っているエンジ ニア 免責事項 本発表は機微情報保護の勉強を目的として作成されました。 本発表の内容を不正に利用した場合、刑事罰、民事訴訟の対象となることがあります。 本発表の内容を用いたことにより起こした、いかなる損害、損失に対し著者は一切責任を負いません。
3. GitFiveが収集する 情報とやり方サマリー  パスワードなどのクリティカルなものを見つける訳では無いが、 調査の足がかりになるレベルの機微情報を取りに行っている 収集する情報 やり方 ターゲットの基本情報・SNS情報 プロフィール欄のスクレイピング アカウント名の履歴 noreplyに紐づくメアドから ターゲットのメアド ・GitHubのメアド解決機能を利用 ・Metamonモジュールによるpermutation サブアカウント noreplyに紐づくメアドのうち、ターゲットア カウントに解決できなかったもの ターゲットが使用するアカウント名 コミットログの全捜査 ユーザのホスト コミットログの全捜査 会社・組織 eメールのドメイン SSH公開鍵 github登録情報 カスタムドメイン リポジトリ内に置かれたCNAMEファイル
4. アジェンダ  背景  GitFiveの説明  GitFiveの処理ロジックの調査  まとめ
5. アジェンダ  背景  GitFiveの説明  GitFiveの処理ロジックの調査  まとめ
6. 背景: GitHubでの意図しない情報公開事例 GitHub上に公開しているリポジトリのコミットログから第三者にメール アドレスを入手され(、スカウトなどの用途で活用され)る事案が存在する  ①『OSSを公開するとメールアドレスがバレる』  https://zenn.dev/st43/articles/deaf291f860ca8  ②『GitHubからメールアドレスが漏れる仕組み』  https://tkhs0604.hatenablog.com/entry/github-email-exposure などなど。”github noreply”で検索すると色々出てくる 意図せずに公開していることもあるため、各人の注意が必要 ②の記事より。人事がコンタクトしてきたとのこと。
7. 情報収集の自動化  先の事例では人事がひたすらGitHubの公開リポジトリを cloneしてメールアドレスを地道に探していた  本人のメールアドレスであるかの確認もあるので負担の大きい作業 だったはず  このようなGitHub上のリポジトリ内の機微情報を、 体系的・自動的に収集する GitFive というツールがある
8. アジェンダ  背景  GitFiveの説明  GitFiveの処理ロジックの調査  まとめ
9. GitFiveについての基本情報  GitHub: https://github.com/mxrch/GitFive  言語: Python  その他の情報は下表のとおり 項目 内容 コミッター mxrch氏 (GHuntと同じ開発者) ライセンス MPL-2.0 最初のコミット 2022年10月 最新のコミット 2025年10月 Stars / Forks 971 / 72
10. GitFiveが試みること  GitHubで利用しているメールアドレスの特定  ユーザー名変更履歴の取得  所属組織・ドメインの推定  親しい人物の推定  など
11. インストールと実行方法  インストール  pipx 経由  $ pipx ensurepath  $ pipx install gitfive  実行方法  コマンドライン越しにGitHubにログイン  $ gitfive login  ただし本垢のGitHubアカウントとは別垢のアカウントでログインすること が推奨されている  $ gitfive user <username> これだけで、前スライドの情報抽出を試みる
12. README.md 内 デモ動画  コマンドを叩くと、アスキーアートが表示され処理開始
13. README.md 内 デモ動画  bio欄の情報が収集される
14. README.md 内 デモ動画  親しい(関連性の強い)友人の候補を列挙し、コネクション を洗い出す
15. README.md 内 デモ動画  所属組織の推測
16. README.md 内 デモ動画  GitHubに紐づくメールアドレスを特定(これがすごい)
17. README.md 内 デモ動画  ついでに過去のGitHubアカウント名義履歴も列挙
18. [備考]READMEの免責事項  Obvious disclaimer  This tool is for educational purposes only, I am not responsible for its use.  訳: 本ツールは教育目的のみです。使用による結果に対して作者は責任 を負いません。  Less obvious disclaimer  The use of this tool in an automated paid service / software is strictly forbidden without my personal agreement.Please use it only in personal, criminal investigations, or open- source projects.  訳: 有料サービス・商用ソフトウェアへの自動化利用は、作者の同意な しに固く禁じられています。個人的な調査・犯罪捜査・オープンソー スプロジェクトでのみ使用してください。
19. アジェンダ  背景  GitFiveの説明  GitFiveの処理ロジックの調査  まとめ
20. 全体ワークフロー  前述のことをどうやってやっているのか気になったので調査  ただしREADME.md内のワークフロー図は複雑だったため、 Claudeにコードリーディングさせながら理解した
21. 全体ワークフロー  最初: ターゲットのGitHubユーザー名を受け取る  Phase 1: GitHub REST APIで基本プロフィール取得  Phase 2: XRAY — リポジトリをクローンしコミット履歴 を解析しユーザのさらなる情報を収集  ユーザの過去のエイリアスや親しい知人なども  Phase 3: Metamon — 推測メールをGitHubに照合  結果の出力
22. Phase 1: プロフィール収集  GitHub REST APIでターゲットのGitHub基本情報を収集  GET /users/{username}  → 名前、ID、会社名、ブログURL、Twitter、フォロワー数 ...  GET /users/{username}/repos  → リポジトリ一覧  GET https://github.com/{username}.keys  → SSH公開鍵 ※SSH公開鍵を収集する目的: 複数のGitHubアカウントが同じ公開鍵を登録 ＝ 同一人物の可能性 ここでは取得するだけ。
23. Phase 2: XRAY — コミット履歴の徹底解析  全リポジトリをクローンして以下の解析を並列処理で実行  forkリポジトリかどうか判定(自分のリポジトリのみ対象)  自分がつくったリポジトリかどうかはGitHubのWebページをスクレイ ピングしてそこについているクラス情報から判定している  リポジトリの各コミットから以下の情報を抽出  committer の名前とメールアドレス  noreplyアドレス中のユーザー名・ID  ローカルPC名(たとえば、xxx@My-PC.local)  ターゲットのリポジトリに直接マージしたユーザのメールアドレスか ら組織を特定  john.doe@google.comだったらgoogle社勤務  いずれにせよ、プルリクを介さないコミット主は重要情報としている  抽出した情報を元に、本人のメアドかどうか、本人と関係しそうな ユーザかどうかなどを判定している(次頁) ※XRAYというモジュール名は、X線のように 「表面を透過して内部の情報を見る」ところから つけたと思われる。
24. 過去のユーザ名を取得する仕組み  GitHubのメール保護機能(noreplyアドレス)を利用  {ユーザーID}+{ユーザー名}@users.noreply.github.com  例: 12345678+alicecodes@users.noreply.github.com  IDが同じだがユーザー名が違う ＝ 改名したと判断  古) 12345678+alice@users.noreply.github.com ↓ ユーザー名変更 中) 12345678+alice_dev@users.noreply.github.com ↓ 新) 12345678+alicecodes@users.noreply.github.com  → 過去のアカウント名(alice, alice_dev)が全部収集される
25. 親しい人物の推定  有名人のフォロワーではなく、素の人間関係がないか調査  PEA(Pretty Empty Account)という概念を利用したフィルタ リングを実施  PEA:「フォロワーが少なく、スターも少ない」アカウント  身内向けの素の状態のアカウントである可能性が高い  PEA判定の条件:  (フォロワー < 20人) かつ (フォロー中 < 50人) かつ (スターほぼなし) → PEAと判定されたフォロワー・フォロー先は、 リアルの知人の可能性が高いので深堀る価値が高い
26. Phase 3: Metamon — メアド列挙と照合 収集情報からメールアドレスを列挙して、GitHubに解決させることでターゲットのメアドを照合する ① 前段のX-RAYで抽出したメアドに加え、 名前・ユーザー名・ドメインを組み合わせてメール候補を生成 john.doe@gmail.com j.doe@company.com johndoe@company.com john@company.com ... (数千パターン) ↓ ② GitFiveでログインしたアカウントに一時的なプライベートリポジトリを作成 ↓ ③ "Co-authored-by: target <①の候補メール>" でコミットをpush(このトリックは次頁) ↓ ④ コミット一覧ページをスクレイピングして照合結果を取得 ↓ ⑤ 一時リポジトリを自動削除 ※モジュール名はポケモンから。 他人のメールアドレスになりすまして GitHubに問い合わせるところからと思われる
27. Co-authored-byを利用した ターゲットのメアド特定  GitHubは Co-authored-by に書かれたメールアドレスを自動的に GitHubアカウントに紐づけて表示することを悪用  例えばCo-authored-by: target <john@company.com>の場合、 john@company.comに紐づくGitHubアカウントをGitHub側が自動でWeb ページ上で解決する  Webページをスクレイピングし、その結果に応じてでユーザ名を収集する 返ってきたユーザー名 意味 ターゲットのアカウントに一致 確定メール 別のユーザー名 サブアカウント候補 解決されない GitHubアカウントなし
28. なぜ Co-authored-by ?  コミットするコンフィグの切り替えを行う手間を省くため git config user.email "target@example.com" git commit ← このメールで1コミット作る git config user.email "next@example.com" git commit ← このメールで1コミット作る ...（1件ずつしか変えられない）  Co-authored-byなら、コミットメッセージだけを変えれ ば良い  あとは、GitHubのコミットログページをスクレイピングす れば、42件/ページ の ユーザ解決結果を取得できる  その他、レートリミットに気をつけた効率さも追求している
29. [備考]GitHubのスクレイピングについて  完全禁止というわけではない https://docs.github.com/ja/site-policy/acceptable-use-policies/github-acceptable-use-policies
30. アジェンダ  背景  GitFiveの説明  GitFiveの処理ロジックの調査  まとめ
31. [再掲]GitFiveが収集する 情報とやり方サマリー  パスワードなどのクリティカルなものを見つける訳では無いが、 調査の足がかりになるレベルの機微情報を取りに行っている 収集する情報 やり方 ターゲットの基本情報・SNS情報 プロフィール欄のスクレイピング アカウント名の履歴 noreplyに紐づくメアドから ターゲットのメアド ・GitHubのメアド解決機能を利用 ・Metamonモジュールによるpermutation サブアカウント noreplyに紐づくメアドのうち、ターゲットア カウントに解決できなかったもの ターゲットが使用するアカウント名 コミットログの全捜査 ユーザのホスト コミットログの全捜査 会社・組織 eメールのドメイン SSH公開鍵 github登録情報 カスタムドメイン リポジトリ内に置かれたCNAMEファイル
32. 所感  GitHubの仕組みに精通したハッカーが作ったツール、と いう感じがする  GitHubの仕様を考慮した収集ロジックの工夫がコードの各所に 見受けられる  開発者の技術の高さを感じる  ハッキングしているわけではないが、機微情報に狙いをすまして 情報を掘り起こしに行っている  良い用途にも悪い用途にも使える  我々としては変なコミットがないかの簡易検査として使えそう  願わくば人事にこのツールが知れ渡らないことを祈る
33. まとめ  GitFiveの仕組みについて調べた  リポジトリの全コミットを解析して、GitHubの仕様を巧みに活用 したり、独自のフィルタアルゴリズムで機微情報の自動収集を試み る  自分のOSS開発活動において、機微情報をうっかり公開し ていないかをチェックするのに使えそう
34. ご清聴ありがとうございました @meow_noisy