Skip to content
KitploitKITPLOIT
ツールエクスプロイトブログ
Log in
提出
ツールエクスプロイトブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

フィードお問い合わせプライバシー© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
gitea-restore-file-open — Giteaのrestore-repoにおけるfile://ローカルファイルインクルージョン(CWE-73)の概念実証。信頼できないダンプ外のシンボリックリンクターゲットをリリース添付ファイルにコピーする。 | Kitploit
ツール/GitHubGitHub/abraxas/gitea-restore-file-open
脆弱性分析エクスプロイト情報収集セキュリティ仮想化ウェブセキュリティペネトレーションテストラボと実践
GitHubabraxas/gitea-restore-file-open

gitea-restore-file-open

Giteaのrestore-repoにおけるfile://ローカルファイルインクルージョン(CWE-73)の概念実証。信頼できないダンプ外のシンボリックリンクターゲットをリリース添付ファイルにコピーする。

リポジトリを見る
213日前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

Abraxas Labs - gitea-restore-file-open

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  gitea-restore-file-open

gitea-restore-file-open

Gitea 1.27.3 - Gitea

CVE-2026-59765 は OpenWithClient に hostmatcher HTTP クライアントを導入した。file:// ブランチはそのクライアントを無視し、os.Open を呼び出す。ダンプのリストアには DownloadFunc が存在しない。gitea_uploader.go はその後、書き換えられた file:// URL を開く。os.Open はダンプ側のシンボリックリンクを追跡する。join はダンプ配下に留まる。シンボリックリンクは留まらない。

信頼できないダンプをオペレーターがリストアすると、シンボリックリンクのターゲットがリリース添付ファイルにコピーされる。Gitea の uid として、これはサービスアカウントが読み取れる任意のファイルである。

IDCVE 未割当
CWECWE-73
CVSSMedium: 4.2 CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N
製品Gitea
影響範囲v1.27.3 (146cc3e) まで; ローカルオペレーター gitea restore-repo
認証信頼できないダンプのローカルオペレーターによるリストア
ライセンスGNU Affero GPL v3.0
ラボ127.0.0.1 のみ

攻撃者ができること

管理者に、ダンプ配下に join されたパス下にシンボリックリンクを含む信頼できないダンプ(「バックアップ」ディレクトリ、信頼できないリモートからのリストア)を渡す。リストアはターゲットファイルをリストアされたリポジトリのリリース添付ファイルにコピーする。そのリポジトリを読める者は誰でもそれをダウンロードできる。

ダンプ作成者が app.ini を指定すれば、それは認証情報の窃取である(INTERNAL_TOKEN、SECRET_KEY、JWT、DB パスワード)。ラボのオラクルは仕込んだ witness ファイルであり、app.ini ではない。これは OS LPE ではない。未認証ではない。ダンプルートの join エスケープでもない。GitHub/GitLab/Gitea からのライブマイグレーションは DownloadFunc を設定し、攻撃者の file:// を os.Open することはない。

発見の経緯

2 つのリストアマップが残されたテーブル上にあった。まず明白な方をラボで検証した。

Finding 8 はダンプルートの join エスケープであった。release.yml に絶対パスの DownloadURL を置き、FilePathJoinAbs が素朴な filepath.Join(base, "/etc/passwd") のようにダンププレフィックスを捨てることを期待した。1.27.3 ではそうならない。各 sub は filepath.Clean("/"+s) の後 filepath.Join(base, cleaned) となる。/tmp/dump + /tmp/GITEA-JOIN-OUTSIDE のレプリカ join は /tmp/dump/tmp/GITEA-JOIN-OUTSIDE のままだった。リストアは file:// をダンプ配下に書き換え、open ...: no such file or directory で失敗した。これはこのタグにおける join エスケープではない。

Finding 9 が実際に成立したものである。ダンプの外に witness ファイルを仕込み、join されたダンプ配下のパスにシンボリックリンクを置き、gitea restore-repo を実行した。リストア rc=0。リストアされたリリース添付ファイルには GITEA-FILE-OPEN-WITNESS が含まれていた。

すでに記録済みの誤った道筋: 絶対 DownloadURL によるダンプルート join エスケープ; ライブマイグレーション file:// LFI; X-Gitea-Internal-Auth(リストアは Gitea uid としての CLI であり、/api/internal ではない); リストア HTTP をリモート未認証として扱うこと(CVSS はローカル、高権限、ユーザー操作); リバースシェル。茶番である。

ラボ

cd lab
./run.sh

ターゲットは必ず http://127.0.0.1:18137 のみ。Compose は lab/dump を読み取り専用でマウントする。run.sh はコンテナ内に witness を仕込み、ダンプをビルドし、シンボリックリンクを置き、その後 gitea restore-repo を実行する。

restore-rc=0 Restore repo labadmin/restored successfully
download status=200 snippet=GITEA-FILE-OPEN-WITNESS
SUCCESS GITEA-RESTORE-FILE-OPEN

修正

OpenWithClient から file:// を削除するか、ダンプのシンボリックリンクを追跡することを拒否し、信頼できないダンプをリストアしないこと。リストアされた添付ファイルにダンプ外の witness が含まれてはならない。

参考資料

  • github.com/go-gitea/gitea タグ v1.27.3
  • uri.go · gitea_uploader.go · FilePathJoinAbs
  • 近傍で修正済み: CVE-2026-59765
  • CWE-73

ライセンス

GNU Affero GPL v3.0。LICENSE を参照。ループバックラボのみ。無保証。

ツールをダウンロード