Gitea Security
Gitea とは
Gitea は、Goで書かれた 自己ホスト型のコミュニティ管理された軽量なコードホスティング ソリューションです。
基本情報
pageBasic Gitea Informationラボ
ローカルで Gitea インスタンスを実行するには、単に Docker コンテナを実行すればよいです:
ポート3000に接続してウェブページにアクセスします。
また、Kubernetesで実行することもできます：
認証されていない列挙
パブリックリポジトリ：http://localhost:3000/explore/repos
デフォルトでは、Giteaは新しいユーザーの登録を許可しています。これにより、新しいユーザーは他の組織/ユーザーのリポジトリに比べて特に興味深いアクセス権を得ることはできませんが、ログインしたユーザーはより多くのリポジトリや組織を視覚化できるかもしれません。
内部悪用
このシナリオでは、GitHubアカウントへのアクセス権を取得したと仮定します。
ユーザー資格情報/ Web Cookieを使用
もし組織内のユーザーの資格情報をすでに持っている場合（またはセッションCookieを盗んだ場合）、ログインして、どのような 権限を持っているか、どのリポジトリに対して、どのチームに所属しているか、他のユーザーをリストし、リポジトリがどのように保護されているかを確認できます。
2FAが使用されている場合があるため、そのチェックをパスできる場合にのみこの情報にアクセスできます。
i_like_gitea cookieを盗むことに成功した場合（現在はSameSite: Laxで構成されています）、資格情報や2FAを必要とせずにユーザーを完全になりすますことができます。
ユーザーSSHキーを使用
GiteaはユーザーがSSHキーを設定できるようにしており、これはコードをデプロイするための認証方法として使用されます（2FAは適用されません）。
このキーを使用すると、ユーザーが特定の権限を持つリポジトリで変更を行うことができますが、これを使用してgitea apiにアクセスして環境を列挙することはできません。ただし、ローカル設定を列挙して、アクセス権を持つリポジトリとユーザーに関する情報を取得することができます。
ユーザーが自分のgiteaユーザー名を設定している場合、彼がアカウントで設定した公開鍵にアクセスできます。_https://github.com/<gitea_username>.keys_で、見つけたプライベートキーが使用できるか確認できます。
SSHキーはデプロイキーとしてリポジトリに設定することもできます。このキーにアクセス権限がある人は、リポジトリからプロジェクトを起動できます。通常、異なるデプロイキーを持つサーバーでは、ローカルファイル**~/.ssh/config**が関連するキーに関する情報を提供します。
GPGキー
こちらで説明されているように、時にはコミットに署名する必要があるか、発見される可能性があります。
現在のユーザーが持っているキーをローカルで確認するには、以下をチェックしてください：
ユーザートークンを使用する場合
ユーザートークンは、Giteaサーバーに対してAPI経由で認証するために、パスワードの代わりに使用できます。これにより、ユーザートークンはユーザーに完全なアクセス権を与えます。
OAuthアプリケーションを使用する場合
Gitea OAuthアプリケーションに関する基本情報を確認する。
攻撃者は、悪意のあるOAuthアプリケーションを作成して、ユーザーの特権データ/アクションにアクセスし、おそらくフィッシングキャンペーンの一環としてそれらを受け入れるユーザーの特権データ/アクションにアクセスする可能性があります。
基本情報で説明されているように、このアプリケーションはユーザーアカウントに対して完全なアクセス権を持ちます。
ブランチ保護のバイパス
Githubには、デフォルトでリポジトリに対して書き込みアクセス権を持つトークンを取得するgithub actionsがあり、これを使用してブランチ保護をバイパスできます。この場合、それが存在しないため、バイパスはより制限されています。しかし、以下のことができるかどうかを見てみましょう：
プッシュを有効にする：書き込みアクセス権を持つ人がブランチにプッシュできる場合、単にプッシュします。
ホワイトリスト制限プッシュ：同様に、このリストの一部であれば、ブランチにプッシュできます。
マージホワイトリストを有効にする：マージホワイトリストがある場合、そのリストに含まれている必要があります。
承認が0より大きい場合：その場合... 別のユーザーを妥協させる必要があります。
承認をホワイトリストに制限する：ホワイトリストされたユーザーのみが承認できる場合... そのリストに含まれる別のユーザーを妥協させる必要があります。
ステール承認を無視する：承認が新しいコミットで削除されない場合、既に承認されたPRを乗っ取ってコードを注入し、PRをマージできます。
組織/リポジトリの管理者であれば、保護をバイパスできることに注意してください。
Webhookの列挙
Webhookは、特定のGitea情報を一部の場所に送信できます。その通信を悪用する可能性があります。 ただし、通常、webhookには取得できない秘密が設定されており、その秘密を知っているがURLを知らない外部ユーザーがwebhookを悪用するのを防ぐでしょう。 ただし、一部の場合、人々は秘密をその場所に設定する代わりに、URLのパラメータとして設定します。そのため、URLをチェックすると、秘密やさらに悪用できる場所を見つけることができるかもしれません。
Webhookはリポジトリと組織レベルで設定できます。
ポストエクスプロイテーション
サーバー内部
何らかの方法で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新しい管理者ユーザーを作成し、アクセストークンを取得します
最終更新
