Cloud service vulnerability analysis 0

Cloud computing security

Enterprises keep data, applications, and workloads in cloud platforms, share them across services, and change them continuously. New threats show up in the same motion. Large stores of data in public cloud services made those platforms a standing target.

Public cloud and private cloud

Public cloud

• Azure, AWS, GCP, Alibaba, NCP, and similar providers
• Broad IaaS / PaaS / SaaS offerings

Private cloud

• Used when an organization needs to build in-house (for example, for personal-data handling)
• Also used as a stepping stone before adopting a public provider
• OpenStack is the common stack

OpenStack

• Open-source cloud platform released in 2010 by Rackspace and NASA
• Imaging, networking, compute, volume, and identity are managed as separate projects
• Many pieces line up with EC2, VPC, and similar AWS roles
• Building a cloud means virtualization plus systems that manage images and volumes

https://www.openstack.org/

Nova compute service

• Core OpenStack service: talks to the hypervisor to create and manage instances
• Dashboards and clients send create/manage calls through the RESTful nova-api
• Flow continues through Nova compute into the hypervisor
• Running instances are reachable through nova-console

https://docs.openstack.org/nova/pike/user/architecture.html

AWS IAM

• Fine-grained permission and access control for AWS resources
• Configured through groups, users, roles, and policies
• Privilege escalation and credential leakage are high-value findings in cloud assessments
• Misconfigurations from the original build period often stay exposed

PBAC sketch

[사용자]
피터 - 기사     <그룹: 공격대1>
케빈 - 마법사   <그룹: 공격대1>
레이 - 힐러     <그룹: 공격대1>
 
[그룹]
공격대1         <역활: ['몬스터 잡기']>
 
[역활]
몬스터 잡기     <정책:  [일반 공격]>
 
[정책]
Allow 일반 공격 if 사용자.마법사? == True (MP Object 사용)
Allow 일반 공격 if 사용자.전사? == True (HP Object 사용)
Allow 일반 공격 if 사용자.힐러? == True (GP Object 사용)

Put users in groups for easier management. Assign roles to those groups. Scope policies so only the right users in the group can perform a role, and only against the right objects.

IAM policies

Policies are JSON and break permissions into fine-grained statements.

IAM JSON policy language grammar

EC2

• Virtual compute instances — the most common resource people create
• Backup via AMI (image) and EBS (volume)
• Highest-weight target once an attacker has a foothold from outside

S3

• Storage built around upload/download style operations
• Can host static web assets
• "S3 data breach" in incident writeups usually means leakage from here

https://s3.console.aws.amazon.com/s3/home?region=ap-northeast-2

Lambda

• Event-driven serverless compute (Python, Node.js, Go, .NET, Ruby, …)
• Internally: containers on Amazon Linux AMI plus egress control
• Composes with API Gateway, S3, SQS, SNS, and more

https://console.aws.amazon.com/lambda/home?region=ap-northeast-2

AWS attack vectors

• IAM permission problems drive a large share of incidents
• IAM leak (environment variables, instance post-exploitation, SSRF, …)
• IAM privilege escalation
• S3 data breach
• Issues in the build/deploy path (CI/CD, CodeDeploy, Terraform, …)