Gitea Security
Giteaとは
Giteaは、Goで書かれたセルフホスト型コミュニティ管理の軽量コードホスティングソリューションです。
基本情報
Basic Gitea Informationラボ
ローカルでGiteaインスタンスを実行するには、dockerコンテナを実行するだけです:
ポート3000に接続してウェブページにアクセスします。
kubernetesで実行することもできます:
Unauthenticated Enumeration
Public repos: http://localhost:3000/explore/repos
Registered users: http://localhost:3000/explore/users
Registered Organizations: http://localhost:3000/explore/organizations
デフォルトではGiteaは新しいユーザーの登録を許可します。これにより、新しいユーザーが他の組織/ユーザーのリポジトリに特別なアクセス権を持つことはありませんが、ログインしたユーザーはより多くのリポジトリや組織を可視化できる可能性があります。
Internal Exploitation
このシナリオでは、githubアカウントへの何らかのアクセスを取得したと仮定します。
With User Credentials/Web Cookie
組織内のユーザーの資格情報を既に持っている場合（またはセッションCookieを盗んだ場合）、ログインして、どのリポジトリに対してどの権限を持っているか、どのチームに所属しているか、他のユーザーをリストアップし、リポジトリがどのように保護されているかを確認できます。
2FAが使用されている可能性があるため、この情報にアクセスするにはそのチェックも通過する必要があります。
i_like_gitea Cookieを盗むことができた場合（現在SameSite: Laxで設定されています）、資格情報や2FAなしで完全にユーザーを偽装することができます。
With User SSH Key
GiteaはユーザーがSSHキーを設定し、これを認証方法としてコードをデプロイするために使用することを許可しています（2FAは適用されません）。
このキーを使用して、ユーザーが何らかの権限を持つリポジトリに変更を加えることができますが、gitea apiにアクセスして環境を列挙することはできません。しかし、ローカル設定を列挙して、アクセス可能なリポジトリやユーザーに関する情報を取得することができます:
ユーザーが自分のgiteaユーザー名を設定している場合、アカウントに設定されている公開鍵にアクセスできます。_https://github.com/<gitea_username>.keys_で確認し、見つけた秘密鍵が使用できるか確認できます。
SSH keysはリポジトリにdeploy keysとして設定することもできます。このキーにアクセスできる人は誰でもリポジトリからプロジェクトを起動できます。通常、異なるdeploy keysを持つサーバーでは、ローカルファイル**~/.ssh/config**がキーに関する情報を提供します。
GPG Keys
こちらで説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
現在のユーザーがキーを持っているかどうかをローカルで確認します:
With User Token
User Tokensの基本情報についての紹介。
ユーザートークンは、パスワードの代わりに使用して、Giteaサーバーに対して認証を行うことができます。これにより、ユーザーに対して完全なアクセスが可能になります。
With Oauth Application
Gitea Oauth Applicationsの基本情報についての紹介。
攻撃者は、悪意のあるOauthアプリケーションを作成して、フィッシングキャンペーンの一環としてユーザーが受け入れる特権データ/アクションにアクセスする可能性があります。
基本情報で説明されているように、アプリケーションはユーザーアカウントに対して完全なアクセスを持ちます。
Branch Protection Bypass
Githubでは、github actionsがデフォルトでリポジトリに対して書き込みアクセス権を持つトークンを取得し、ブランチ保護をバイパスすることができます。このケースではそれが存在しないため、バイパスはより制限されます。しかし、できることを見てみましょう：
Enable Push: 書き込みアクセス権を持つ誰かがブランチにプッシュできる場合、そのままプッシュします。
Whitelist Restricted Push: 同様に、このリストの一部であればブランチにプッシュします。
Enable Merge Whitelist: マージホワイトリストがある場合、その中に入る必要があります。
Require approvals is bigger than 0: その場合、別のユーザーを妥協する必要があります。
Restrict approvals to whitelisted: ホワイトリストに登録されたユーザーのみが承認できる場合、そのリスト内の別のユーザーを妥協する必要があります。
Dismiss stale approvals: 新しいコミットで承認が取り消されない場合、既に承認されたPRをハイジャックしてコードを注入し、PRをマージすることができます。
もしあなたがorg/repoの管理者であれば、保護をバイパスすることができます。
Enumerate Webhooks
Webhooksは、特定のgitea情報をいくつかの場所に送信することができます。これを悪用することができるかもしれません。 しかし、通常はシークレットがwebhookに設定されており、URLを知っているがシークレットを知らない外部ユーザーがそのwebhookを悪用するのを防ぎます。 しかし、時々、人々はシークレットをその場所に設定する代わりに、URLにパラメータとして設定することがあり、URLをチェックすることでシークレットや他の悪用可能な場所を見つけることができます。
Webhooksはリポジトリレベルと組織レベルで設定できます。
Post Exploitation
Inside the server
もし何らかの方法でgiteaが動作しているサーバーに侵入できた場合、giteaの設定ファイルを探すべきです。デフォルトでは、/data/gitea/conf/app.iniにあります。
このファイルにはキーやパスワードが含まれています。
giteaのパス（デフォルト: /data/gitea）には、以下のような興味深い情報も見つかるかもしれません：
sqlite DB: giteaが外部DBを使用していない場合、sqlite DBを使用します。
セッションフォルダ内のセッション:
cat sessions/*/*/*を実行すると、ログインしているユーザー名が表示されます（giteaはセッションをDB内に保存することもあります）。jwtフォルダ内のjwtプライベートキー
その他の機密情報がこのフォルダ内に見つかるかもしれません。
サーバー内にいる場合、giteaバイナリを使用して情報にアクセス/変更することもできます：
gitea dumpはgiteaをダンプし、.zipファイルを生成します。gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRETは指定されたタイプのトークンを生成します（永続性）。gitea admin user change-password --username admin --password newpasswordパスワードを変更します。gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token新しい管理者ユーザーを作成し、アクセス トークンを取得します。
Last updated
