Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Giteaは自己ホスト型のコミュニティ管理の軽量コードホスティングソリューションで、Goで書かれています。
Giteaインスタンスをローカルで実行するには、単にdockerコンテナを実行することができます：
ポート3000に接続してウェブページにアクセスします。
Kubernetesで実行することもできます：
デフォルトでは、Giteaは新しいユーザーの登録を許可します。これにより、新しいユーザーは他の組織やユーザーのリポジトリに特に興味深いアクセスを得ることはありませんが、ログインしたユーザーはより多くのリポジトリや組織を視覚化できるかもしれません。
このシナリオでは、あなたがgithubアカウントへのアクセスを取得したと仮定します。
もしあなたが組織内のユーザーの資格情報を持っている場合（またはセッションクッキーを盗んだ場合）、ただログインして、どのリポジトリに対してどの権限を持っているか、**どのチームにいるか、他のユーザーをリストし、リポジトリがどのように保護されているかを確認できます。
2FAが使用される可能性があるため、そのチェックを通過できる場合にのみ、この情報にアクセスできることに注意してください。
もしあなたが**i_like_giteaクッキーを盗むことに成功した場合**（現在SameSite: Laxで設定されています）、資格情報や2FAを必要とせずにユーザーを完全に偽装できます。
GiteaはユーザーがSSHキーを設定することを許可しており、これがコードをデプロイするための認証方法として使用されます（2FAは適用されません）。
このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで変更を行うことができますが、gitea APIにアクセスして環境を列挙するためには使用できません。ただし、ローカル設定を列挙して、アクセスできるリポジトリやユーザーに関する情報を取得できます:
ユーザーが自分の gitea ユーザー名としてユーザー名を設定している場合、https://github.com/<gitea_username>.keys で彼のアカウントに設定された 公開鍵 にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。
SSH 鍵 は デプロイ鍵 としてリポジトリに設定することもできます。この鍵にアクセスできる人は、リポジトリからプロジェクトを起動する ことができます。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル ~/.ssh/config が関連する鍵に関する情報を提供します。
こちら で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。
現在のユーザーが鍵を持っているかどうかをローカルで確認してください:
ユーザートークンについての基本情報を確認してくださいの紹介。
ユーザートークンは、GiteaサーバーにAPI経由で認証するためにパスワードの代わりに使用できます。ユーザーに対して完全なアクセス権を持ちます。
Gitea Oauthアプリケーションについての基本情報を確認してくださいの紹介。
攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある悪意のあるOauthアプリケーションを作成して、特権データやアクションにアクセスするかもしれません。
基本情報で説明されているように、アプリケーションはユーザーアカウントに対して完全なアクセス権を持ちます。
Githubには、デフォルトでリポジトリに対して書き込みアクセスを持つトークンを取得するgithub actionsがあります。これを使用してブランチ保護を回避できます。この場合は存在しないため、回避策はより制限されます。しかし、何ができるか見てみましょう：
プッシュを有効にする: 書き込みアクセスを持つ誰かがブランチにプッシュできる場合、そのままプッシュします。
制限されたプッシュをホワイトリストに追加: 同様に、このリストの一部であればブランチにプッシュします。
マージホワイトリストを有効にする: マージホワイトリストがある場合、その中にいる必要があります。
承認が0より大きいことを要求: その場合... 別のユーザーを妥協させる必要があります。
承認をホワイトリストに制限: ホワイトリストに登録されたユーザーのみが承認できる場合... そのリストにいる別のユーザーを妥協させる必要があります。
古い承認を無効にする: 新しいコミットで承認が削除されない場合、すでに承認されたPRをハイジャックしてコードを注入し、PRをマージできます。
あなたが組織/リポジトリの管理者である場合、保護を回避できます。
Webhooksは、特定のgitea情報をいくつかの場所に送信することができます。その通信を悪用することができるかもしれません。 しかし、通常、秘密がwebhookに設定されており、URLを知っている外部ユーザーがその秘密を知らない場合、そのwebhookを悪用することを防ぎます。 しかし、時には、秘密をその場所に設定する代わりに、URLにパラメータとして設定する人もいるため、URLを確認することで秘密や他の悪用できる場所を見つけることができるかもしれません。
Webhooksはリポジトリと組織レベルで設定できます。
もし何らかの方法で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 新しい管理ユーザーを作成し、アクセストークンを取得します。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
