abraxas/uptime-kuma-setup-toctouUptime Kumaの初回実行時のSocket.IOセットアップにおけるTOCTOU競合の概念実証であり、未認証の攻撃者が隠しの2人目の管理者を作成し、認証を無効化できる。
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · uptime-kuma-setup-toctou
Uptime Kuma 2.5.5 - Louis Lam
初回起動時の Socket.IO setup はユーザーを COUNT し、コスト 10 で bcrypt を実行してから INSERT する。ユーザー名は UNIQUE 制約のみ。トランザクションもミューテックスも単一行制約も存在しない。すでに接続済みの 2 つのソケットがどちらも count === 0 を観測すれば、両方がハッシュ化し、両方が挿入する。余分な管理者は不可視である。ユーザー一覧 UI が存在しないためだ。
起動直後の Kuma に、運用者と同じポーリングタイミングでアクセスした第三者は、隠れた 2 人目の管理者を植え付け、認証を無効化し、自動ログインに乗じて運用者の監視対象へ到達できる。
| ID | CVE 未採番 |
| CWE | CWE-362, CWE-367 |
| CVSS | High: 7.4 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N |
| 製品 | Uptime Kuma |
| 影響範囲 | 2.5.5 (c98982a) まで、初回起動時の空の user テーブル |
| 認証 | 不要 |
| ライセンス | GNU Affero GPL v3.0 |
| ラボ | 127.0.0.1 のみ |
起動直後の Kuma に、運用者が /setup を送信するのと同じタイミングでアクセスする。Docker のデフォルトバインドは 0.0.0.0:3001。別のユーザー名で 2 つ目の user 行を挿入する。そのユーザーでログインし、disableAuth を設定し、R.findOne("user") の自動ログインに乗じて運用者の監視対象、通知、API キー、設定へ到達する。
最初の行がコミットされた後では、後続の逐次的な setup は拒否される。これは「setup が開いたまま」という話ではない。bcrypt の時間窓における競合状態である。管理者が既に存在する初期化済みインスタンスはこのバグの対象ではない。
潜在的な API キーの有効化/無効化 IDOR (UPDATE api_key SET active=? WHERE id=? に user_id がない) も、ユーザーが 2 人存在すると有効化される。これは余分な行の派生であり、ラボのオラクルではない。
まず SECURITY.md を読み、次にスキップリストを確認した。公開済みの GitHub アドバイザリ 18 件、公開されている Matomo siteId XSS、ベンダーが修正しないクラウドメタデータ SSRF である。その後、タグ 2.5.5 (c98982a) に対して 22 件の調査を実施した。auth/setup/2FA、socket IDOR、HTTP/監視対象 SSRF、SSTI の残骸、path/LFI、実ブラウザ、plugin/tailscale、ステータスページ、docker.sock、プロトタイプ汚染、push/prometheus、データベース、監視対象 exec、analytics XSS、設定、websocket CSRF、フロントエンド XSS、ジョブ、Apprise、メンテナンス、master-delta。その基準のほとんどは未公開の何も返さなかった。認証は違った。
初回ユーザー setup は公開 Socket.IO イベントである。ログイン不要。setup は COUNT(user) を実行し、次に await passwordHash.generate、そして R.store を行う。passwordHash.generate は bcrypt.hash コスト 10。これは居眠りであってロックではない。needSetup はインメモリで、接続時に "setup" を emit するためだけに使われる。書き込みパスはそれを無視して再カウントする。
スキーマはユーザー名 UNIQUE のみ。knex_init_db.js は単一行を強制しない。同じユーザー名は衝突する (SQLITE_CONSTRAINT)。異なるユーザー名は両方とも通る。
louislam/uptime-kuma:2.5.5 をループバック上で UPTIME_KUMA_DB_TYPE=sqlite を指定して起動し、v2 データベースウィザードをスキップした。bcrypt コスト 10 は競合であり、初回で保証されるものではない。run.sh はボリュームを消去してリトライする。終了コード 2 は失敗。次は空の user テーブルで再挑戦する。
成功したとき: sqlite に 1|labadmin と 2|UK-SETUP-TOCTOU-WITNESS。後続の逐次 setup: Uptime Kuma has been initialized。余分なユーザーでログインし、setSettings で disableAuth=true。再接続時の自動ログインは R.findOne("user")、つまり最小 id の運用者。prepare2FA の otpauth アイデンティティは labadmin。
近接する GHSA-23q2-5gf8-gjpp は disableAuth の再有効化がソケットを切断できないというもの。別のバグである。
記録済みの誤った道: 並行 setup 後のユーザー行が 1 つ (競合の失敗であり、パッチではない)。UK-SETUP-TOCTOU-WITNESS が存在しないのは両方のソケットが同じ名前を使ったため。ダッシュボード HTML 200 を SUCCESS とみなすこと。リバースシェル。茶番である。オラクルは sqlite の 2 行、そして id 1 としての disableAuth 自動ログインである。
cd lab
./run.sh
対象は http://127.0.0.1:18141 のみ。公式イメージ louislam/uptime-kuma:2.5.5、sqlite、初回起動。ポートをループバック外に公開しないこと。
user-rows [('1', 'labadmin'), ('2', 'UK-SETUP-TOCTOU-WITNESS')]
race-count=2 witness=True
sequential-late-setup initialized=True
setSettings-disableAuth ack ok
reconnect autoLogin=True loginRequired=False
bonus-autologin-identity operator=True id1=labadmin auto_is_id1=True
SUCCESS uptime-kuma-setup-toctou
setup を直列化する。トランザクションと単一行制約、または COUNT+INSERT を囲むミューテックス。disableAuth の自動ログインを最小 id の findOne として扱わないこと。それまでは、共有ネットワーク上で初回起動時の setup を公開しないこと。
server.js setup · password-hash.js · knex_init_db.jsGNU Affero GPL v3.0。LICENSE を参照。ループバックラボのみ。無保証。