AWS - RDS Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Pour plus d'informations sur RDS, consultez :
AWS - Relational Database (RDS) Enumrds:ModifyDBInstance
Avec cette permission, un attaquant peut modifier le mot de passe de l'utilisateur principal, et la connexion à l'intérieur de la base de données :
Vous devrez être en mesure de contacter la base de données (elles sont généralement accessibles uniquement depuis des réseaux internes).
Impact potentiel : Trouver des informations sensibles à l'intérieur des bases de données.
Selon les docs, un utilisateur avec cette permission pourrait se connecter à l'instance de DB.
Si en exécutant SELECT datname FROM pg_database;
vous trouvez une base de données appelée rdsadmin
, vous savez que vous êtes à l'intérieur d'une base de données postgresql AWS.
Tout d'abord, vous pouvez vérifier si cette base de données a été utilisée pour accéder à un autre service AWS. Vous pourriez vérifier cela en regardant les extensions installées :
Si vous trouvez quelque chose comme aws_s3
, vous pouvez supposer que cette base de données a une sorte d'accès à S3 (il existe d'autres extensions telles que aws_ml
et aws_lambda
).
De plus, si vous avez les autorisations pour exécuter aws rds describe-db-clusters
, vous pouvez voir là si le cluster a un rôle IAM associé dans le champ AssociatedRoles
. S'il y en a un, vous pouvez supposer que la base de données a été préparée pour accéder à d'autres services AWS. En fonction du nom du rôle (ou si vous pouvez obtenir les permissions du rôle), vous pourriez deviner quel accès supplémentaire la base de données a.
Maintenant, pour lire un fichier à l'intérieur d'un bucket, vous devez connaître le chemin complet. Vous pouvez le lire avec :
Si vous aviez des identifiants AWS bruts, vous pourriez également les utiliser pour accéder aux données S3 avec :
Postgresql n'a pas besoin de changer de variable de groupe de paramètres pour pouvoir accéder à S3.
À l'intérieur d'un mysql, si vous exécutez la requête SELECT User, Host FROM mysql.user;
et qu'il y a un utilisateur appelé rdsadmin
, vous pouvez supposer que vous êtes dans une base de données mysql AWS RDS.
À l'intérieur du mysql, exécutez show variables;
et si les variables telles que aws_default_s3_role
, aurora_load_from_s3_role
, aurora_select_into_s3_role
, ont des valeurs, vous pouvez supposer que la base de données est prête à accéder aux données S3.
De plus, si vous avez les permissions pour exécuter aws rds describe-db-clusters
, vous pouvez vérifier si le cluster a un rôle associé, ce qui signifie généralement un accès aux services AWS.
Maintenant, pour lire un fichier à l'intérieur d'un bucket, vous devez connaître le chemin complet. Vous pouvez le lire avec :
rds:AddRoleToDBCluster
, iam:PassRole
Un attaquant avec les permissions rds:AddRoleToDBCluster
et iam:PassRole
peut ajouter un rôle spécifié à une instance RDS existante. Cela pourrait permettre à l'attaquant d'accéder à des données sensibles ou de modifier les données au sein de l'instance.
Impact potentiel : Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS. Notez que certaines bases de données nécessitent des configurations supplémentaires telles que Mysql, qui doit spécifier le rôle ARN dans les groupes de paramètres également.
rds:CreateDBInstance
Juste avec cette autorisation, un attaquant pourrait créer une nouvelle instance à l'intérieur d'un cluster qui existe déjà et a un rôle IAM attaché. Il ne pourra pas changer le mot de passe de l'utilisateur principal, mais il pourrait être en mesure d'exposer la nouvelle instance de base de données à Internet :
rds:CreateDBInstance
, iam:PassRole
TODO: Tester
Un attaquant avec les permissions rds:CreateDBInstance
et iam:PassRole
peut créer une nouvelle instance RDS avec un rôle spécifié attaché. L'attaquant peut alors potentiellement accéder à des données sensibles ou modifier les données au sein de l'instance.
Certaines exigences du rôle/profil d'instance à attacher (depuis ici) :
Le profil doit exister dans votre compte.
Le profil doit avoir un rôle IAM que Amazon EC2 a la permission d'assumer.
Le nom du profil d'instance et le nom du rôle IAM associé doivent commencer par le préfixe AWSRDSCustom
.
Impact potentiel : Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.
rds:AddRoleToDBInstance
, iam:PassRole
Un attaquant avec les permissions rds:AddRoleToDBInstance
et iam:PassRole
peut ajouter un rôle spécifié à une instance RDS existante. Cela pourrait permettre à l'attaquant d'accéder à des données sensibles ou de modifier les données au sein de l'instance.
L'instance DB doit être en dehors d'un cluster pour cela
Impact potentiel : Accès à des données sensibles ou modifications non autorisées des données dans l'instance RDS.
Apprenez et pratiquez le hacking AWS :HackTricks Formation Expert Red Team AWS (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Formation Expert Red Team GCP (GRTE)